US 10567343

Based on my searches of the USPTO record (via Google Patents, Docket Alarm copies of the issued patent, and PTAB filings) and the CAFC docket, here is a concise summary of US 10,567,343 B2 (patent number 10567343). Note that I was unable to retrieve any CAFC docket entries dated in 2026 itself; the appeal identified below was filed in October 2024 and the most recent docket entry I could confirm is from December 2024.

Summary — US Patent 10,567,343 B2

Abstract (verbatim)

"Aspects of this disclosure relate to filtering network data transfers. In some variations, multiple packets may be received. A determination may be made that a portion of the packets have packet header field values corresponding to a packet filtering rule. Responsive to such a determination, an operator specified by the packet filtering rule may be applied to the portion of packets having the packet header field values corresponding to the packet filtering rule. A further determination may be made that one or more of the portion of the packets have one or more application header field values corresponding to one or more application header field criteria specified by the operator. Responsive to such a determination, at least one packet transformation function specified by the operator may be applied to the one or more of the portion of the packets."

Plain-language overview of the independent claims

The patent has three independent claims — claim 1 (method), claim 8 (apparatus), and claim 15 (non-transitory computer-readable media) — which are substantively parallel. In plain terms, each claims:

1. Receiving packets — a computing system receives a plurality of packets (conceptually split into a first portion and a second portion).
2. First-stage (packet-header) filtering — based on a packet header field value (e.g., the classic 5-tuple: protocol type, source/destination IP, source/destination port), the system determines whether each packet satisfies a first criterion specified by one or more packet-filtering rules.
3. Applying an operator — for the first portion of packets that match, the system applies one or more operators specified by the matching packet-filtering rule (e.g., an ALLOW, BLOCK, HTTP-EXFIL, or REQUIRE-TLS operator).
4. Second-stage (application-header) filtering — based on an application header field value (e.g., an HTTP method, TLS version, or RTP value), the system determines a second portion of packets satisfying a second criterion specified by the operator.
5. Transformation / exfiltration prevention — for the second portion of packets that match the application-level criterion, the system applies at least one packet transformation function configured to prevent an exfiltration operation, where the transformation function indicates whether each packet is allowed to continue toward its destination (i.e., allow vs. block/drop).

Dependent-claim highlights (common to all three independent claims)

• Claims 2/9/16: the first portion includes a packet header field value indicating a protocol type associated with a particular type of data transfer.
• Claims 3/10/17: the first portion includes a destination port number associated with a particular type of data transfer.
• Claims 4/11/18: HTTP methods — GET packets are allowed; PUT, POST, or CONNECT packets are blocked.
• Claims 5/12: requests for specified resource data (e.g., GET-style reads) are allowed, while requests to submit data to be processed by a specified resource are blocked.
• Claims 6/13/19: drop packets of a particular data-transfer type when they carry a particular Transport Layer Security (TLS) version value (the spec describes blocking TLS 1.0 while allowing TLS 1.1/1.2).
• Claims 7/14/20: drop packets of a particular data-transfer type when they carry a particular Real-time Transport Protocol (RTP) value.

Litigation / proceeding status (from Unified Patents, Justia, and Docket Alarm)

• PTAB IPRs involving this patent:
  • IPR2023-01353 (Palo Alto Networks, Inc. v. Centripetal Networks, LLC) — filed Sept. 5, 2023; instituted Mar. 13, 2024; Final Written Decision, status "Appealed"; terminated Aug. 5, 2024.
  • IPR2023-00446 (Palo Alto Networks) — Final Written Decision.
  • IPR2021-01155 (Palo Alto Networks) — not instituted (denied on the merits).
• District court: multiple cases in the Eastern District of Virginia (e.g., 2:21-cv-00137, 1:21-cv-00313, 1:22-cv-00001, 2:22-cv-00002) involving Centripetal against Cisco, Keysight, and Palo Alto Networks; a post-trial JMOL order in 2:21-cv-00137 was entered in late 2024 (granted in part/denied in part, reasons sealed).
• CAFC appeals: 25-1052 (lead) and 25-1103 (cross-appeal) — Keysight Technologies, Inc. v. Centripetal Networks, LLC, docketed at the Federal Circuit on October 24, 2024 (appeal received Oct. 18, 2024; certified list served Dec. 3, 2024; consolidated with 25-1052 as lead). I did not find any 2026-dated CAFC docket entries for this appeal in my searches — the latest entry I confirmed is December 5, 2024 — so any 2026 briefing, argument, or decision activity could not be verified and should be checked against PACER.

Confidence notes / uncertainties

• High confidence on the bibliographic data (title, inventor, assignee, dates, abstract, claims) because it comes from the issued patent text (via Google Patents and copies of the certified patent in PTAB exhibits).
• Medium confidence on current litigation status: the CAFC appeal numbers (25-1052 / 25-1103) are confirmed, but I could not confirm whether the appeals are still pending or were decided in 2025–2026, and I found no 2026-specific CAFC docket entries. Verify current status via PACER before relying on it.
• Minor discrepancy noted: one aggregator (Unified Patents) lists the priority date as 2013-03-11, whereas the patent and USPTO records state 2013-03-12; I have used the patent's own date.

Based on my searches, US Patent 10,567,343 ("Filtering network data transfers," owned by Centripetal Networks) has been involved in the following known litigations and administrative proceedings. I have listed them by forum.

District Court Litigation (E.D. Va.)

1. Centripetal Networks, Inc. v. Palo Alto Networks, Inc.

• Plaintiff: Centripetal Networks, Inc. (later Centripetal Networks, LLC)
• Defendant: Palo Alto Networks, Inc.
• Jurisdiction: U.S. District Court, Eastern District of Virginia
• Case numbers: Originally filed as 1:21-cv-00313 (Alexandria Division) on March 12, 2021; intradistrict-transferred to the Norfolk Division as 2:21-cv-00137
• Patents: The '343 patent was among 13 asserted patents (docket lists: 10091246; 10503899; 10530903; 10542028; 10567343; 10567413; 10567437; 10659573; 10735380; 10749906; 10757126; 10785266; 10931797)
• Status/outcome: Jury trial; on January 31, 2024 a Virginia federal jury found Palo Alto Networks infringed all four patents tried and awarded Centripetal $151.5 million (Law360, Jan. 31, 2024). On October 2024, the court (Judge Elizabeth W. Hanes) ruled on post-trial motions: PAN's Motion for Judgment as a Matter of Law was granted in part and denied in part, PAN's Motion for a New Trial was denied, and other pending motions were denied (PACER Docket, Case 2:21-cv-00137, ECF Nos. 900, 906, 970). The detailed reasoning was filed under seal. The case is now on appeal at the Federal Circuit (see below).

2. Centripetal Networks, Inc. v. Keysight Technologies, Inc.

• Plaintiff: Centripetal Networks, Inc. (later LLC)
• Defendant: Keysight Technologies, Inc.
• Jurisdiction: U.S. District Court, Eastern District of Virginia
• Case numbers: Originally filed as 1:22-cv-00001 on January 1, 2022; also docketed as 2:22-cv-00002 (Norfolk Division; judges Arenda L. Wright Allen and Douglas E. Miller)
• Patents: The '343 patent is listed by Google Patents as associated with this case (2:22-cv-00002), alongside other Centripetal patents. Note: the complaint analysis I found focuses on the '370, '917, and '526 patents, so I cannot confirm from my search results alone which specific claims/patents were ultimately asserted in this action.
• Status/outcome: Ongoing/related to parallel ITC Investigation No. 337-TA-1313 (Certain Computer Network Security Equipment and Systems) in which an ALJ Initial Determination (Aug. 8, 2023) found no Section 337 violation, with invalidity findings on several Centripetal patents; the ITC action and the district case were coordinated. The district case (2:22-cv-00002) was stayed and later addressed in connection with the ITC proceedings (Docket No. 65, Sept. 8, 2023). I could not confirm a final merits disposition of the district case as of the search date.

PTAB / Inter Partes Review Proceedings

3. Palo Alto Networks, Inc. v. Centripetal Networks, Inc. — IPR2021-01155

• Petitioner: Palo Alto Networks, Inc.
• Patent Owner: Centripetal Networks, Inc.
• Filing date: July 6, 2021
• Challenged claims: Claims 1–20 of the '343 patent
• Status: Institution denied (decision Jan. 20, 2022) — the Board did not institute review ("Not Instituted – Merits" per Google Patents). Judges: Jon M. Jurgovan, Bryan F. Moore, Lynne E. Pettigrew.

4. Keysight Technologies, Inc. v. Centripetal Networks, LLC — IPR2023-00446

• Petitioner: Keysight Technologies, Inc.
• Patent Owner: Centripetal Networks, LLC
• Filing date: Petition filed January 6, 2023 (Ex. 1001 is US Patent 10,567,343)
• Status: Instituted; Patent Owner's Request for Director Review of the institution decision was denied (Oct. 3, 2023); Google Patents lists the proceeding status as Final Written Decision (I could not confirm the exact FWD date or merits outcome from my searches).

5. Palo Alto Networks, Inc. v. Centripetal Networks, LLC — IPR2023-01353

• Petitioner: Palo Alto Networks, Inc.
• Patent Owner: Centripetal Networks, LLC
• Filing date: September 5, 2023
• Institution: Granted March 13, 2024
• Status: Final Written Decision issued; proceeding terminated August 5, 2024; the FWD has been appealed to the Federal Circuit (status listed as "Final Written Decision – Appealed"). I could not confirm the merits of the FWD from my searches.

Federal Circuit Appeals

• Appeal No. 25-1052 (Court of Appeals for the Federal Circuit) — listed by Google Patents as litigation involving the '343 patent. Most likely the appeal of the Palo Alto Networks IPR2023-01353 Final Written Decision and/or the district court judgment in 2:21-cv-00137, but I could not confirm the exact underlying case.
• Appeal No. 25-1103 (Court of Appeals for the Federal Circuit) — likewise listed by Google Patents as litigation involving the '343 patent; exact underlying case not confirmed from my searches.

Notes / Caveats

• The Centripetal v. Cisco case (2:18-cv-00094, E.D. Va.) is not a '343 patent case — the '343 patent did not issue until Feb. 18, 2020, after that litigation's asserted patents (e.g., 9,203,806; 9,560,176; 9,686,193; 9,917,856) were already in suit.
• I could not confirm from my searches whether the '343 patent remains asserted in the Keysight district action (2:22-cv-00002 / 1:22-cv-00001) or the precise scope of the two CAFC appeals; those specific details would require a PACER/docket review.
• The legal status of the '343 patent itself is Active, with anticipated expiration March 12, 2033 (per USPTO/Google Patents).

If you need, I can drill into PACER/CAFC dockets to pin down which specific appeals (25-1052, 25-1103) correspond to which underlying case, and the merits outcomes of IPR2023-00446 and IPR2023-01353.

Proceedings overview

The USPTO ODP block in this prompt reports no AIA trial proceedings on file for US10567343, but web search confirms three proceedings that ODP has not yet indexed — two inter partes reviews that reached Final Written Decisions (both appealed to the Federal Circuit) and one earlier PAN petition denied at institution. Breakdown: 0 active; 2 proceedings with claims invalidated (IPR2023-00446 and its joinder IPR2023-01353, which share one FWD canceling 18 of 20 claims); 0 claims fully sustained (though claims 5 and 12 survived); 0 settled; 1 institution denied (IPR2021-01155). Bottom line for a defendant: the patent has been gutted — claims 1–4, 6–11, and 13–20 are canceled per the 2024-08-05 FWD, and only the narrow dependent claims 5 and 12 remain standing — any demand letter built on the canceled claims has no basis.

IPR2023-00446 — Keysight Technologies, Inc. v. Centripetal Networks, LLC

• Type: Inter Partes Review
• Filed: 2023-01-06
• Status: Final Written Decision – Appealed (FWD issued 2024-08-05; Centripetal appealed; Keysight cross-appealed)
• Judge panel: Not confirmed in my sources for this case number specifically; the parallel joinder decision in IPR2023-01353 (Paper 21) was decided by Kevin F. Turner, Aaron W. Moore, and Steven M. Amundson, and the proceedings shared a single FWD.
• Petition grounds: All claims 1–20 (independent claims 1, 8, and 15) challenged under 35 U.S.C. § 103(a) as obvious over the Sourcefire 3D System User Guide v4.10 in combination with the "Emerging Threats" Snort rule set file (Ex. 1020), supported by the declaration of Dr. Stuart Staniford.
• Institution decision: Instituted on 2023-08-07 (Paper 9) on all challenged claims and all asserted grounds. The Board rejected Centripetal's § 325(d)/discretionary-denial arguments; Centripetal's request for Director review was denied on 2023-10-03 (Paper 14).
• Final Written Decision: Issued 2024-08-05. The panel found, by a preponderance of the evidence, that claims 1–4, 6–11, and 13–20 are unpatentable — i.e., 18 of 20 claims, including all three independent claims (1, 8, 15) — while claims 5 and 12 were not proved unpatentable and survived. The FWD's key evidentiary holding: the "Emerging Threats" rule set file is a "printed publication" under § 102(b) based on Wayback Machine accessibility (Dec. 2, 2010), its status as a known clearinghouse for Snort rules, and petitioner expert testimony. Verbatim from the FWD: "we conclude that Petitioner has demonstrated by a preponderance of the evidence that claims 1–4, 6–11, and 13–20 of the challenged claims are unpatentable." (FWD PDF at ptablitigationblog.com; also docketed in E.D. Va. 2:21-cv-00137 at Doc. 993, Ex. 2.)
• Settlement / termination: No settlement. Trial completed on schedule (PO Response 2023-10-30; Petitioner Reply 2024-01-05; oral hearing 2024-05-06; FWD 2024-08-05).
• Appeal: Yes. Centripetal appealed — CAFC 25-1052, Centripetal Networks, LLC v. Keysight Technologies, Inc., filed 2024-10-11 — and Keysight cross-appealed as 25-1103 (filed 2024-10-24); the two were consolidated with 25-1052 as lead (Justia CAFC docket). Per Keysight's later SEC filings, oral argument was held in January 2026 on the USPTO findings invalidating 18 of 20 claims of this patent; I could not confirm a final disposition as of this search, so treat the FWD as on appeal but currently effective against the parties.
• Defensive value: This is the centerpiece. Claims 1–4, 6–11, and 13–20 are canceled — no infringement theory can rest on them. The surviving claims 5 and 12 (dependent, requiring "a request for specified resource data") are the only assertable claims left, and they are narrow. Related district-court litigation (Centripetal v. Keysight, 2:22-cv-00002, E.D. Va., filed 2022-01-01) is stayed pending the appeal.

IPR2023-01353 — Palo Alto Networks, Inc. v. Centripetal Networks, LLC

• Type: Inter Partes Review (joinder)
• Filed: 2023-09-05 (petition plus motion for joinder to IPR2023-00446)
• Status: Final Written Decision – Appealed (terminated 2024-08-05, the same date as the joint FWD)
• Judge panel: Kevin F. Turner, Aaron W. Moore, Steven M. Amundson (institution/joinder decision, Paper 21).
• Petition grounds: Identical to the Keysight IPR — claims 1–20 under § 103(a) over Sourcefire + Emerging Threats, relying on substantially the same evidence; Patent Owner acknowledged the grounds were identical.
• Institution decision: Instituted and joinder granted on 2024-03-13 under 35 U.S.C. § 315(c) / 37 C.F.R. § 42.122, because the petition was "substantively identical" to the already-instituted Keysight IPR and PAN was joined as a co-petitioner.
• Final Written Decision: No separate FWD — PAN was joined to IPR2023-00446, and the 2024-08-05 FWD in that proceeding resolved both petitions. Same claim-level outcome: claims 1–4, 6–11, 13–20 unpatentable; claims 5 and 12 survive.
• Settlement / termination: No settlement. Terminated upon issuance of the joint FWD.
• Appeal: Covered by the same CAFC appeals, 25-1052 (lead) and 25-1103 (cross-appeal), which list both IPR2023-00446 and IPR2023-01353 as originating cases (RPX Insight).
• Defensive value: Confirms Palo Alto Networks is estopped under § 315(e)(2) on the Sourcefire/Emerging Threats grounds and locks in the same 18-claim cancellation. For PAN's own litigation (Centripetal v. Palo Alto Networks, 2:21-cv-00137, E.D. Va.), PAN has already used this FWD in the district court to strip the asserted claims.

IPR2021-01155 — Palo Alto Networks, Inc. v. Centripetal Networks, Inc.

• Type: Inter Partes Review
• Filed: 2021-07-06
• Status: Institution Denied (2022-01-20) — not appealable
• Judge panel: Jon M. Jurgovan (author), Bryan F. Moore, Lynne E. Pettigrew
• Petition grounds: All claims 1–20, including a Sourcefire-based ground with Mantripragada for certain dependent claims (the precise statutory mix as pleaded in the petition, with the Board's § 325(d) analysis focused on the Sourcefire + Mantripragada combination).
• Institution decision: Denied on 2022-01-20 under 35 U.S.C. § 325(d) applying the Advanced Bionics framework: Sourcefire had been submitted in an IDS and considered by the Examiner during prosecution of the '343 patent; Mantripragada was found cumulative to Buck (US 2002/0186683 A1), which the Examiner had considered; and Patent Owner's prosecution argument that the "packet transformation function … to prevent an exfiltration operation" distinguished the claims was the same argument it made against the petition. The panel found PAN had not shown the Office erred in a manner material to patentability.
• Settlement / termination: N/A — no trial was instituted.
• Appeal: None (institution denials under § 314/§ 325(d) are not appealable).
• Defensive value: Negative precedent for PAN, not a defense for anyone else. It shows the § 325(d) shield that protected the patent in 2022 did not survive the better-developed 2023 petition — the same Sourcefire art, paired with Emerging Threats and backed by a printed-publication showing, went on to invalidate 18 claims. Do not rely on § 325(d) as a defense today; the Board has already rejected that path for this art.

Strategic summary

Claims now CANCELED vs. SUSTAINED vs. UNTESTED. All 20 claims have now been tested in IPR. Canceled (18): claims 1–4, 6–11, and 13–20, including every independent claim (1, 8, 15), per the 2024-08-05 FWD in IPR2023-00446/IPR2023-01353 (obviousness over Sourcefire + Emerging Threats). Sustained (2): claims 5 and 12 — narrow dependent claims requiring that the application header field value indicate "a request for specified resource data" that is allowed, versus "a request to submit data to be processed by a specified resource" that is blocked. Untested: none. Every claim has been through at least one IPR (IPR2021-01155 challenged all 20 but was denied institution on § 325(d); the 2023 proceedings retried all 20 on the merits).

Estoppel landscape. Under § 315(e)(2), Keysight (IPR2023-00446) and Palo Alto Networks (IPR2021-01155 and IPR2023-01353), and their privies, are barred from raising in district court or ITC any ground they raised or reasonably could have raised in these IPRs — effectively the § 102/§ 103 universe centered on Sourcefire and Emerging Threats. For a new defendant not in privity with Keysight or PAN, there is no estoppel: you may still raise Sourcefire/Emerging Threats grounds and, more usefully, fresh art. The surviving claims 5 and 12 were upheld on the specific Sourcefire/Emerging Threats combination, so a new IPR against claims 5 and 12 should lead with different references (e.g., the Buck/Mantripragada line the Board discussed in IPR2021-01155, or Ahn/Stolfo) and avoid the § 325(d) trap by pairing art the Examiner never saw with a clear material-error showing. Note also the litigation context: the E.D. Va. cases (2:21-cv-00137 against PAN, 2:22-cv-00002 against Keysight) and the related ITC investigation are stayed or being narrowed around this FWD.

Pattern signals. Palo Alto Networks is a repeat petitioner (IPR2021-01155 denied, then IPR2023-01353 joined and succeeded) and Keysight filed the lead IPR — both are industry competitors defending Centripetal's E.D. Va. and ITC assertions, not a defensive aggregator like Unified Patents. Centripetal is litigating aggressively across the PTAB, E.D. Va., ITC, and the Federal Circuit and has appealed both FWDs (CAFC 25-1052/25-1103) rather than settling. The absence of any settlement, combined with 18 of 20 claims dead, signals a patent owner fighting to preserve a two-claim patent whose commercial value is now concentrated entirely in claims 5 and 12.

Recommended next steps

• If you are a defendant facing assertion of US10567343: put the FWD in front of the court immediately. The decision — Keysight Technologies, Inc. and Palo Alto Networks, Inc. v. Centripetal Networks, LLC, IPR2023-00446, Paper 30 (P.T.A.B. Aug. 5, 2024) — is public on PTAB E2E/P-TACTS and mirrored at https://www.ptablitigationblog.com/wp-content/uploads/2024/10/IPR2023-00446-FD.pdf. Quote the disposition: "claims 1–4, 6–11, and 13–20 of the challenged claims are unpatentable." Any infringement theory built on those claims is sanction-bait. Demand letters or complaints citing claims 1, 8, 15, or their dependents other than 5 and 12 should be met with a motion to strike/dismiss and a Rule 11 analysis.
• The only live claims are 5 and 12. Build your non-infringement position around the "request for specified resource data" / "request to submit data" dichotomy the Board implicitly credited. If you are not Keysight or PAN, you are not estopped — a § 311 petition against claims 5 and 12 using art outside the Sourcefire/Emerging Threats combination is a viable, low-cost pressure point, but file before any litigation stays lapse and watch the § 325(d) cumulative-art trap.
• Watch the pending appeal. CAFC 25-1052 (lead) / 25-1103 (cross-appeal) were argued in January 2026; I could not confirm a disposition as of this search. Until the mandate issues, the FWD is technically on appeal — but the PTAB's claim cancellations are already being given effect in the stayed district court cases, and the estoppel and prior-art value of the FWD does not depend on the appeal's outcome.
• If you are facing this patent outside the Keysight/PAN ecosystem and want a clean record: the ODP still lists no PTAB proceedings for this patent, which is a data-ingest lag — do not let opposing counsel argue "no IPR has ever been filed." The three proceedings above are documented on PTAB E2E, DocketAlarm, Patexia, and RPX, and the FWD itself (Paper 30) references the earlier denied IPR2021-01155 at Exhibit 2004.

Inventors

• Sean Moore (Hollis, NH) — sole inventor named on US 10,567,343 B2. He is the founder/CEO of Centripetal Networks, the company that filed the application; his employer at the time of filing (2013–2017) was Centripetal Networks, Inc. (Portsmouth, NH / Herndon, VA).
• Pattern note: the broader Centripetal family includes a multi-inventor cast (e.g., David K. Ahn, Keith A. George, Peter P. Geremia, Pierre Mallett III, Sean Moore, Robert T. Perry, Jonathan R. Rogers — see Ex. 2020 in IPR2021-01148, which lists a different Centripetal patent), but this patent names Moore alone. There is no pattern of inventors departing the original assignee within 12 months of filing; Moore remains with the company (now Centripetal Networks, LLC) through today's litigation, so the classic "inventor exodus → portfolio fire-sale" tell is not present.

Original assignee

• Centripetal Networks, Inc. (Reston/Herndon, VA; formerly Portsmouth, NH) is the assignee named on the issued patent (Google Patents backfills the current name "Centripetal Networks LLC"; Unified Patents records "Original Assignee: Centripetal Networks Inc").
• Line of business: operating cybersecurity vendor. It designs and sells packet-filtering network-security appliances (CleanINTERNET, PacketIQ/RuleGATE product lines) — i.e., it does ship products embodying the claimed two-stage packet/application-header filtering.
• Current status: operating, under the renamed entity Centripetal Networks, LLC (1875 Explorer Street, Suite 900, Reston, VA 20190). Not acquired, not dissolved, not in bankruptcy. It has been actively enforcing its own portfolio in EDVA (e.g., 2:18-cv-00094 against Cisco; 2:21-cv-00137 against Keysight; 1:21-cv-00313 / 2:21-cv-00002 against Palo Alto Networks), at the ITC (Inv. No. 337-TA-1314), and defending IPRs (IPR2021-01155, IPR2023-00446, IPR2023-01353).

Assignment timeline

I could not retrieve reel/frame numbers for this patent: the USPTO Assignment Center (assignmentcenter.uspto.gov) is a scripted application that my search tools could not query directly, and no third-party index I could reach publishes the reel/frame for this specific patent. The two recorded post-filing events below are confirmed from Google Patents legal events (which mirror USPTO assignment records) and from Centripetal's own PTAB/CAFC filings. Reel/frame numbers are unverified — do not cite them without checking Assignment Center directly.

• ~2013 (executed, at original filing) / recorded date not independently verified — Reel unverified

  • Conveyance: original assignment of rights from the inventor (the later 2018 recordation is the confirmatory counterpart)
  • Assignor: Sean Moore
  • Assignee: Centripetal Networks, Inc.
  • Correspondent: not verified (prosecution counsel of record on the patent is Banner & Witcoff, Ltd., a conventional operating-company prosecution firm — no NPE pattern)
  • Context: normal inventor→employer assignment at filing of the priority application (13/795,822).

• 2018-10-29 (recorded) — Reel unverified (Google Patents legal event: "Assigned to CENTRIPETAL NETWORKS, INC. — ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MOORE, SEAN")

  • Conveyance: Assignment of Assignors' Interest (confirmatory assignment)
  • Assignor: Sean Moore
  • Assignee: Centripetal Networks, Inc.
  • Correspondent: not verified
  • Context: routine confirmatory inventor→company recordation on the continuation application (15/614,956); internal, not a transfer of ownership.

• 2023-01-20 (recorded) — Reel unverified (Google Patents legal event: "Assigned to CENTRIPETAL NETWORKS, LLC — CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: CENTRIPETAL NETWORKS, INC.")

  • Conveyance: Change of Name
  • Assignor: Centripetal Networks, Inc.
  • Assignee: Centripetal Networks, LLC
  • Correspondent: not verified
  • Context: corporate name change / conversion only. Centripetal disclosed to the PTAB on 2023-01-19 that "due to a change of corporate name on December 30, 2022," the real party in interest changed from Centripetal Networks, Inc. to Centripetal Networks, LLC at the same Reston, VA address, and that it would "be filing a recordation of the name change for the patent at the USPTO shortly" (IPR2022-00182, Patent Owner Notice, 2023-01-19) — exactly matching the 2023-01-20 recorded event.

No security agreement, license, merger, or third-party transfer involving this patent surfaced in any source I could reach. If the Assignment Center shows additional records (e.g., lender security interests), they were not verifiable from my available sources.

Timeline diagram

timeline
    title Ownership of US 10567343
    2013 : Filed by Centripetal Networks Inc
    2018 : Confirmatory assignment from inventor
    2020 : Patent issued
    2022 : Corporate name change to LLC
    2023 : Name change recorded at USPTO

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The assignee is Centripetal Networks, Inc./LLC, an operating company with a physical headquarters (1875 Explorer Street, Reston, VA), employees, products, and litigation conduct consistent with a product vendor. No "IP / Holdings / Licensing" shell LLC appears anywhere in the chain.
2. Known asserter in the chain — not present. No Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Conversant, Vringo, Pendrell, or Spangenberg entity appears. Centripetal is a product company that happens to be a high-frequency plaintiff against competitors — the opposite of the classic NPE list.
3. Repeat correspondent across the chain — unclear (insufficient data). Only two recorded events exist and both are internal to the same company (inventor→employer confirmatory; corporate name change). I could not verify correspondent names for either recordation, so no recurrence pattern can be established — but there is also no cross-entity chain over which a repeat correspondent would be suspicious.
4. Cascading transfers — not present. Two recordations, 4+ years apart, both within the same corporate entity. No chained LLCs, no common-principal shell ladder.
5. Pre-litigation transfer — not present as an NPE signal. The 2023 name-change recordation occurred while litigation was ongoing (Cisco EDVA case 2:18-cv-00094; IPR2022-00182), but it is a corporate name change at the same address — a standing/housekeeping recordation, not an arrangement to enable assertion by a new entity.
6. Bankruptcy fire-sale — not present. Centripetal has not filed for bankruptcy, and no trustee or bankruptcy-court transfer appears in the chain.
7. Privateering — not present. The direction is inverted: the operating company itself is asserting against competitors (Cisco, Palo Alto Networks, Keysight). There is no operating-company-to-NPE handoff.
8. Defensive aggregator (anti-NPE) — not present. The chain terminates at the operating company, not at RPX, AST, LOT, Unified Patents, or OIN.

Verdict

Operating-company assertion.

The recorded chain consists solely of (a) a confirmatory inventor→employer assignment (recorded 2018-10-29, assignor Sean Moore to Centripetal Networks, Inc.) and (b) a corporate name change (recorded 2023-01-20, Centripetal Networks, Inc. → Centripetal Networks, LLC), with the latter confirmed by Centripetal's own PTAB notice of real-party-in-interest change effective 2022-12-30 at the same Reston, VA address. The current owner ships packet-filtering security appliances that practice the claimed two-stage filtering and has asserted this very patent against actual competitors in EDVA and the ITC (e.g., 2:21-cv-00137, IPR2023-00446, IPR2023-01353). No shell entity, known NPE, cascading transfer, or fire-sale appears in any verified record.

Caveat: reel/frame numbers for both recordations could not be independently verified from my available sources (the USPTO Assignment Center was not directly searchable), so the assignment entries above rest on Google Patents legal-event data and PTAB/CAFC filings. Verify at https://assignmentcenter.uspto.gov/ (search Patent No. 10567343) before relying on the exact recordation dates or adding reel/frame citations.

The initial searches surfaced partial citation data. Let me now dig into the specific prior-art references, including those used in the IPR challenges against this patent.

The IPR filings are proving to be the richest source for identifying the most relevant prior art. Let me pull the Final Written Decision for IPR2023-00446 and get the full cited-reference list.

Prior Art Analysis — US Patent 10,567,343 B2 ("Filtering Network Data Transfers")

0. Analytical framework and threshold caveats

Effective priority date / statutory regime. The '343 patent is a continuation of App. 14/625,486 (→ US 9,686,193 B2), which is a continuation of App. 13/795,822 (filed March 12, 2013; → US 9,124,552 B2). Because the chain was filed before March 16, 2013, the applicable framework is pre-AIA 35 U.S.C. §§ 102/103 (the PTAB applied pre-AIA § 103 in IPR2023-00446 for this exact reason). For pre-AIA § 102(b), the critical date for a "printed publication" is one year before the effective filing date — i.e., March 12, 2012; for § 102(a)/(e), the relevant date is the invention date (assumed, per the petitions, to be the March 12, 2013 filing date).

Threshold caveat — no § 102 anticipation holding exists on the record. Every validity challenge to the '343 patent that I could verify was brought under 35 U.S.C. § 103(a) (obviousness), not § 102 (anticipation):

• IPR2023-00446 (Keysight + Palo Alto Networks): § 103(a) over Sourcefire 3D System User Guide v4.10 + Emerging Threats rule set, claims 1–20; Final Written Decision (Aug. 5, 2024) held claims 1–4, 6–11, 13–20 unpatentable (claims 5 and 12 survived).
• IPR2021-01155 (Palo Alto Networks): § 103 over Sourcefire (claims 1–6, 8–13, 15–19) and Sourcefire + Mantripragada (US 2009/0103524 A1) (claims 7, 14, 20); institution denied (Jan. 20, 2022) under § 325(d) because Sourcefire was already considered during prosecution and Mantripragada was cumulative.
• IPR2023-01353 (Palo Alto Networks): instituted Mar. 13, 2024; Final Written Decision (Aug. 5, 2024), now on appeal.

Accordingly, my "potentially anticipates under § 102" statements below are analyst assessments (single-reference element coverage), not findings from any tribunal. A true § 102 case would require one reference to disclose every claim element arranged as claimed; on the record, the closest art needed a combination (Sourcefire + Emerging Threats) for the PTAB's unpatentability conclusions.

1. Tier 1 — The references at the core of the IPR challenges (most relevant)

1.1 Sourcefire 3D System User Guide, Version 4.10 ("Sourcefire")

• Full citation: Sourcefire, Inc., Sourcefire 3D System User Guide, Version 4.10 (non-patent literature; Ex. 1004 in IPR2023-00446 / IPR2023-01353).
• Dates: Publicly accessible at least as early as April 2011 (distributed on CD-ROM/DVD with each Sourcefire 3D System appliance — 3D Sensor, Defense Center — and downloadable from Sourcefire's password-protected support site). Held to be a printed publication under § 102(b) (Fed. Cir. finding in the related IPR2018-01760 litigation, on which PAN invoked collateral estoppel).
• Description: User guide for the Sourcefire 3D next-generation IPS/IDS platform. It describes rule-based inspection of network traffic, including (i) packet-header (5-tuple–style) filtering rules, (ii) application-layer protocol detection (HTTP, and other application protocols), (iii) operators/actions (allow, drop/alert) applied to matching traffic, and (iv) rule sets configurable to block malicious or exfiltration-type traffic. This is the single closest reference to the '343 patent's two-stage (packet-header → application-header) filter-plus-operator architecture.
• § 102 potential: The PTAB never found Sourcefire alone to anticipate; the IPR grounds were § 103. Sourcefire alone plausibly covers the elements of claims 1–3, 8–10, 15–17 (receiving packets; matching on packet-header field values such as protocol type and destination port; applying an operator to the matched portion). Its coverage of the "application header field criteria specified by the operator" and "packet transformation function configured to prevent an exfiltration operation" limitations is contested — indeed, in the parent-family IPR2018-01559 (against the '193 patent), the Board denied institution because Sourcefire had not been shown to teach the claimed operator. So a standalone § 102 case against any '343 claim is weak-to-plausible at best and unproven.

1.2 Emerging Threats rule set ("Emerging Threats")

• Full citation: Emerging Threats open Snort rule set — emerging-all.rules for Snort 2.8.4, available at https://rules.emergingthreats.net/open/snort-2.8.4/emerging-all.rules (Ex. 1020 in the IPRs).
• Dates: Wayback Machine capture of December 2, 2010; held by the PTAB in IPR2023-00446 to be publicly accessible and a printed publication under § 102(b) (well-indexed, searchable, known to skilled artisans as a clearinghouse for Snort rules).
• Description: A large corpus of machine-readable intrusion-detection/prevention rules, including rules keyed to HTTP methods and other application-protocol header values, and rules whose actions (e.g., drop) implement exfiltration-type protections. In the IPR, it supplied the rule-set/operator content that, with Sourcefire, rendered the challenged claims obvious.
• § 102 potential: As a rule corpus rather than a system description, it is not a realistic standalone anticipatory reference for the system/method claims; its role was to fill gaps (drop-rule operators, application-header criteria) left by Sourcefire. No claim is plausibly anticipated by Emerging Threats alone.

1.3 US 2009/0103524 A1 ("Mantripragada")

• Full citation: U.S. Patent Application Publication No. 2009/0103524 A1 to Mantripragada, published April 23, 2009 (Ex. 1007 in the IPR2021-01155 petition).
• Description: Used by the petitioner specifically to supply the Real-time Transport Protocol (RTP) disclosure needed for dependent claims 7, 14, 20 (dropping packets of a particular data-transfer type when they carry a particular RTP value), in combination with Sourcefire. (Note: I could not independently verify the application's title/inventor from my search results; the "Mantripragada" designation and April 23, 2009 publication date are from the PTAB/petition record and should be checked against USPTO PAIR.)
• § 102 potential: Relevant only to claims 7, 14, 20, and only for the RTP limitation; the IPR treated it as a secondary reference (Sourcefire + Mantripragada under § 103). No § 102 case.

2. Tier 2 — Most relevant patent references cited on the face of the '343 patent (examiner citations)

The patent's References Cited section lists 261 documents. I verified the highest-relevance subset (those most on-point for the two-stage packet-header/application-header filter architecture). Dates below are (priority/filing date → publication date) per the Google Patents citation table.

(I deliberately omit items where I could not verify the title/content with confidence rather than risk fabricating them.)

HTTP-method dependent claims (4/11/18). Among face citations, the references most on-point for the HTTP-method allow/block behavior (GET allowed; PUT/POST/CONNECT blocked) are the application-inspection references (2.1 Zuk; 2.2 CA; 2.9 Trend Micro), plus the IPR combination of Sourcefire + Emerging Threats (which the PTAB found to cover claims 4, 11, 18 under § 103). No single face citation is documented to disclose the exact GET-vs-PUT/POST/CONNECT rule as claimed.

TLS dependent claims (6/13/19). The REQUIRE-TLS operator (block TLS 1.0; allow 1.1/1.2) was addressed in the IPR through Sourcefire + Emerging Threats, which the PTAB found to cover claims 6, 13, 19. I found no face citation specifically on TLS-version-based dropping that I can verify with confidence.

RTP dependent claims (7/14/20). The only reference in the record specifically supplying RTP detection is Mantripragada (US 2009/0103524 A1) (Tier 1.3), used in the IPR2021-01155 combination.

3. Tier 3 — Family/commonly-owned and other notable citations

• US 9,203,806 B2 (Rule swapping in a packet network, Centripetal; priority date 2013-01-11 — before the '343 patent's 2013-03-12 priority date). This is a § 102(a)/(e) candidate as to the '343 patent (filed earlier, published 2015-12-01), but it is commonly owned and was not relied on as prior art; it covers rule-swapping in packet networks, a related but distinct feature set.
• US 9,137,205 B2 / US 9,565,213 B2 (Methods and systems for protecting a secured network, Centripetal; priority date 2012-10-22). Also pre-'343-priority-date and thus technically § 102(e)-class art for the same owner; discloses dynamic security policies and packet filtering. Not relied on as prior art in the IPRs.
• US 9,124,552 B2 (parent of the '343 patent) and US 9,686,193 B2 (grandparent-adjacent continuation): not § 102 prior art (same priority date); however, their IPR history is highly relevant context — IPR2018-01436 and IPR2018-01437 found all claims of the '552 and '713 family patents unpatentable over Sourcefire, while IPR2018-01559 (against the '193 patent) was denied institution for failure to show Sourcefire taught the claimed operator. This is why Sourcefire is the dominant reference in the art.
• US 7,032,031 B2 and US 8,370,936 B2 (Exs. 1008/1019 in the IPR exhibit lists): background references on packet filtering / network security included in the IPR record. I could not verify their titles or content with confidence from my searches; verify via USPTO before relying on them.

4. Bottom line

1. Most relevant prior art: (a) Sourcefire 3D System User Guide v4.10 — the closest single reference, forming the backbone of every IPR challenge; (b) Emerging Threats rule set — the combination reference that, with Sourcefire, drove the PTAB's § 103 unpatentability findings for claims 1–4, 6–11, 13–20; (c) Mantripragada (US 2009/0103524 A1) — the RTP supplement for claims 7, 14, 20.
2. No § 102 anticipation has been established for any claim; every instituted ground was § 103(a). The closest plausible § 102 arguments (Sourcefire alone) would target claims 1–3, 8–10, 15–17, but the record (IPR2018-01559; IPR2021-01155 denial) shows the operator/application-header/exfiltration-prevention limitations are the contested elements that Sourcefire alone does not clearly disclose.
3. Unverified items to confirm before use: the full title/inventor details of Mantripragada (US 2009/0103524 A1) and of US 7,032,031 B2 / US 8,370,936 B2; the complete 261-item face-citation list (I could only verify the high-relevance subset); and the current status of the IPR2023-00446 and IPR2023-01353 FWD appeals (CAFC 25-1052 / 25-1103) as of 2026.

I have good ground-truth on the IPR posture. Let me dig further into the actual winning prior-art combination and the Final Written Decision details, plus the Emerging Threats rule set content.

Obviousness Analysis — US Patent 10,567,343 B2 ("Filtering network data transfers")

Analyst: Technical patent analyst | Date of analysis: April 26, 2026 | Statute: 35 U.S.C. § 103 (pre‑AIA § 103(a) applies, given the March 12, 2013 priority date)

I. Scope and key ground truth from the record

Before constructing the § 103 analysis, I flag the most important evidentiary fact confirmed by this search round: the PTAB has already adjudicated the obviousness of all 20 claims of US 10,567,343 B2 in IPR2023-00446 (joined by IPR2023-01353), on a single § 103 ground: "Sourcefire 3D System User Guide Version 4.10" in view of "Emerging Threats" (a Snort rule set). The Final Written Decision (Paper 30, entered August 5, 2024) held claims 1–4, 6–11, and 13–20 unpatentable as obvious and declined to find claims 5 and 12 obvious. That decision is on appeal to the Federal Circuit (appeals 25-1052 and 25-1103; both originate from IPR2023-00446 and IPR2023-01353 per RPX). I could not confirm any merits disposition of those appeals as of this date, so the PTAB findings below are the most authoritative current ground truth on obviousness of this patent.

This analysis therefore (A) reconstructs the adjudicated winning combination, then (B) develops alternative combinations from the 261 references cited in the patent's own "Citations" section, which would support additional § 103 grounds.

II. Legal framework

Obviousness under § 103 requires applying the Graham factors: (1) scope and content of the prior art; (2) differences between the prior art and the claims; (3) level of ordinary skill in the art; (4) objective indicia of non-obviousness. Under KSR Int'l Co. v. Teleflex, Inc., 550 U.S. 398 (2007), a combination of known elements is obvious when a skilled artisan would have had reason to combine them with a reasonable expectation of success, including when the combination yields only predictable results, when it is "obvious to try" a finite set of identified solutions, or when the improvement is merely the union of known techniques in a known field.

Level of ordinary skill (POSA): As applied in the IPR (Pet. and Dr. Staniford Decl., Ex. 1003), a POSA at the relevant time would have had a B.S. or equivalent in computer science/engineering and several years of experience in network security, including firewall/IPS/IDS design and rule-based packet filtering. I adopt that formulation.

III. The claims in issue (recap)

Independent claims 1 (method), 8 (apparatus), 15 (non-transitory media) are parallel. Each requires: (i) receiving a plurality of packets; (ii) determining, based on a packet header field value, whether packets meet a first criterion of packet-filtering rule(s); (iii) applying, to the matching "first portion," operator(s) specified by the matching rule; (iv) determining, based on an application header field value, a "second portion" meeting a second criterion specified by the operator; and (v) applying to that second portion at least one packet transformation function configured to prevent an exfiltration operation that indicates whether each packet is allowed to continue toward its destination. Dependent claims add: protocol type (2/9/16); destination port (3/10/17); HTTP methods — GET allowed, PUT/POST/CONNECT blocked (4/11/18); "request for specified resource data" allowed vs. "request to submit data to be processed" blocked (5/12); dropping packets of a data-transfer type carrying a particular TLS version value (6/13/19); and dropping packets carrying a particular RTP value (7/14/20).

IV. Primary combination (the adjudicated ground): Sourcefire 3D System User Guide v4.10 + Emerging Threats rule set

References (as defined in IPR2023-00446):

• Sourcefire = Sourcefire 3D System User Guide Version 4.10 (Ex. 1004). The 3D Sensor's Intrusion Prevention System (IPS) is a Snort-based, inline, packet-by-packet filtering engine. Each intrusion rule has a rule header specifying action, protocol, source IP, source ports, direction, destination IP, and destination ports (i.e., the classic 5-tuple), and a rule body of keywords/arguments for application-layer inspection. Rule actions are pass (allow), alert (pass + event), or drop (block). Keywords include http_method (specifies HTTP request methods for the HTTP preprocessor to inspect in addition to GET and POST; Sourcefire at 568) and ssl_version with arguments sslv2, sslv3, tls1.0, tls1.1, tls1.2 (Sourcefire at 827–828), which invoke the SSL preprocessor to extract version information from TLS Record Protocol headers. Inline deployments drop packets when a rule's state is "Drop and Generate Events"; users import custom rule sets (initially disabled) and tune each rule to alert or drop.
• Emerging Threats = the rule set at https://web.archive.org/web/20101202025325/http://rules.emergingthreats.net/open/snort-2.8.4/emerging-all.rules (Ex. 1020), publicly accessible by December 2, 2010 — the PTAB held it a printed publication (well-known clearinghouse for Snort rules, formerly "Bleeding Snort"; Wayback Machine copy; corroborated by fact and expert testimony). Two rules were central:
  • Rule 2003021 (SSLv3/TLS exfiltration rule): rule header checks a 5-tuple (home network, any port → external network, port range) and the rule body matches a TLS/SSL record header version value (e.g., content 170301 for TLS 1.0/SSLv3). The PTAB credited that the rule "is hoping to find exfiltration of some kind of encrypted data, or prevent loss of data via the use of outdated insecure versions of SSL/TLS," and that "the operator in rule 2003021 is very similar to the 'Require-TLS' operator of the '343 patent."
  • Rule 2010234 (HTTP POST exfiltration rule): outbound connections on HTTP ports; GET requests do not trigger (allowed through); POST requests (e.g., to URL /semn.php?data=) trigger and are blocked — a "request to submit data to be processed by a specified resource."

Element-by-element mapping (independent claims 1, 8, 15)

The Board's reasoning on the independent claims: Sourcefire supplies the two-stage architecture (rule-header 5-tuple filter → rule-body application-layer keyword filter → pass/drop action), and Emerging Threats Rule 2003021 supplies a ready-made rule whose operator is "very similar to the 'Require-TLS' operator" and which "prevents an exfiltration operation." That combination was held to teach all limitations of claims 1, 8, and 15. See FWD IPR2023-00446.

Dependent claims

• Claims 2/9/16 (protocol type): Sourcefire's IP protocol field is part of every rule header's 5-tuple; Emerging Threats rules specify a protocol in the rule header. Found obvious.
• Claims 3/10/17 (destination port): Destination port is part of both references' rule headers (e.g., $HTTP_PORTS, port 80/443). Found obvious.
• Claims 4/11/18 (HTTP GET allow; PUT/POST/CONNECT block): Sourcefire's http_method keyword and HTTP preprocessor inspect HTTP methods beyond GET/POST; a POSA would write a rule identifying PUT/POST/CONNECT as exfiltration vectors (the '343 patent itself concedes PUT/POST were known exfiltration methods, 7:21–23, 7:55–60) and set the rule to drop; Emerging Threats supplies HTTP rules implementing this. Found obvious.
• Claims 6/13/19 (drop on particular TLS version): Emerging Threats Rule 2003021 matches a TLS/SSL record header version value; obvious to employ that value to drop packets in the Sourcefire+Emerging Threats combination. Found obvious.
• Claims 7/14/20 (drop on particular RTP value): Emerging Threats includes a rule detecting a buffer-overflow attack; a POSA "would have understood that RTSP conditions could be detected to drop packets based on an analogous rule." Found obvious (note the claim says "real-time transport protocol value," and the Board credited the RTSP/analogous-rule reasoning).
• Claims 5/12 (resource-data request vs. submit-data request): NOT found obvious. The Board's reason: the Petition relied on a different rule (Rule 2010234) for these claims than for the independent claims (Rule 2003021), and "The Petition does not, however, provide any explanation why one of ordinary skill in the art would have utilized both rules or how both rules would have functioned together. The different rules of Emerging Threats are, in effect, different embodiments." This is the limitation Keysight challenges on cross-appeal (25-1103).

Motivation to combine (why a POSA would combine)

The PTAB accepted, and the record strongly supports, the following motivation rationale:

1. Same field, same product paradigm. Sourcefire's IPS is a Snort engine; Snort's standard deployment model is an engine plus a third-party ruleset (VRT, Bleeding Snort/Emerging Threats). A POSA by 2010 "would have downloaded text (ASCII) files of rules from Emerging Threats to load into Snort devices, such as Sourcefire" (Staniford Decl. ¶ 164), imported them (disabled by default), and tuned each rule to "alert" or "drop" — precisely the workflow documented in Sourcefire ("Select Rule State > Drop and Generate Events").
2. Known problem, known solution elements. HTTP-mediated exfiltration was a known problem (the '343 patent's own Background concedes this); blocking HTTP PUT/POST while allowing GET was known (e.g., the stateful-inspection firewall in Ex. 1008, US 7,032,031, which "allowed the FTP 'GET' command but disallowed the 'PUT' command," 4:31–41; HTTP methods in IDS rules as early as 1997, Ex. 1028). Combining a rule engine with a rules database that encodes those detections yields the predictable benefit of blocking exfiltration.
3. Two-stage filtering is the inherent structure of Snort rules. As the Board's institution analysis and petitioner's hearing demonstratives showed, a Snort/Emerging Threats rule is a first-stage 5-tuple check (rule header) followed by a second-stage application-header check (rule body keywords) and an allow/drop action — the same structure as the claimed method. Configuring which packets a rule applies to is "just normal operation of an IPS or IDS."
4. No unexpected results. Nothing in the record shows the claimed combination produces new functionality beyond the sum of a rule engine and its rules; the FWD's finding of obviousness follows KSR's "predictable variation" and "obvious to try" rationales.

Practical takeaway: The Sourcefire + Emerging Threats ground is not merely a plausible theory — it is the ground on which the PTAB actually invalidated 17 of 20 claims, and the only claims that survived (5/12) survived on a procedural gap in the petitioner's evidence (failure to explain co-enabling two different rules), not on a substantive teaching deficiency.

V. Alternative combinations using the patent's own cited art ("Citations (261)")

The '343 patent's citation list supplies ample secondary art for independent § 103 grounds. (I treat the citation list as the patent's own prior-art record; publication dates are those shown in the patent's citation table, all pre-2013.)

Combination B — Classic L3/L4 packet filter + application-layer inspection (independent claims)

• Primary: US 6,147,976 A ("Fast network layer packet filter," Cabletron/Shand et al., filed 1996, granted 2000) — a packet filter that extracts source/destination addresses and protocol/port information (5-tuple equivalents via source/destination domain identifiers and protocol domain identifiers), indexes a filtering matrix, and forwards or discards the packet per a filtering flag. This teaches receiving packets, first-criterion packet-header filtering, and an allow/block transformation function (forward/drop).
• Secondary: US 6,279,113 B1 (dynamic signature inspection-based intrusion detection), US 6,097,172 A (firewall with proxy reflection), US 2003/0154399 A1 (Zuk, multi-method gateway-based network security — Check Point-style application-layer inspection), US 2003/0005122 A1 (IBM, in-kernel content-aware service differentiation), US 2002/0165949 A1 (high-speed policy discrimination in packet-filtering firewalls), EP 1006701 A2 (Lucent, adaptive re-ordering of packet filter rules), US 2003/0123456 A1 (Denz, tree-like packet filtering).
• Mapping: US 6,147,976 supplies stage 1 (header-based filtering + forward/drop). Any of the application-inspection references supplies stage 2 (inspect application-layer header values, e.g., HTTP method, and allow/block accordingly). Zuk and IBM '512 are especially apt because they disclose content/application-aware decisions within a gateway/firewall, i.e., the same device performing both stages.
• Motivation: Firewalls and IDS/IPS had been converging toward multi-layer (L3/L4 + L7) inspection for a decade before 2013; combining a fast header classifier with a signature/content inspector to catch application-layer attacks was the standard industry trajectory (stateful inspection + deep packet inspection). A POSA would combine them with a reasonable expectation of success because each component was proven and the interfaces (rule tables, pass/drop actions) were standard.

Combination C — HTTP-method filtering (claims 4/11/18, and the concept underlying 5/12)

• Primary: US 2003/0005122 A1 (IBM, in-kernel content-aware service differentiation — differentiates HTTP methods/URLs in-kernel); US 7,032,031 (stateful-inspection firewall distinguishing FTP GET from PUT, cited in the IPR as Ex. 1008); US 2003/0018591 A1 (packet filtering system and methods); US 6,097,172 A (proxy reflection).
• Mapping: A rule specifying HTTP destination port 80 (first criterion), an operator that inspects the HTTP method field (second criterion), and allow/block per method (GET vs. PUT/POST/CONNECT) is directly taught by a stateful firewall that permits GET-type commands but denies PUT-type commands, extended to HTTP methods — a trivial application of a known policy primitive to a known protocol.
• Motivation: Preventing data exfiltration via HTTP write methods was a known objective; web-usage policies distinguishing "read" (GET) from "write" (PUT/POST) were conventional. This is a textbook KSR predictable-variation case.

Combination D — TLS-version filtering (claims 6/13/19)

• Primary: US 2002/0083345 A1 (Halliday, secure communication over unstable public connections — TLS session handling); US 2004/0010712 A1 (Hui, integrated VPN/firewall system); Sourcefire's own ssl_version keyword (sslv2/sslv3/tls1.0/tls1.1/tls1.2) is itself prior art; Emerging Threats Rule 2003021; I. Ristic, SSL/TLS and PKI History (IPR Ex. 1026); Dierks & Rescorla TLS RFC (IPR Ex. 1038).
• Mapping: The '343 patent's REQUIRE-TLS-1.1-1.2 operator (block 1.0, allow 1.1/1.2) is exactly the Sourcefire ssl_version rule-keyword model plus the Emerging Threats rule. Because the TLS Record Protocol version field is unencrypted (the patent concedes this), reading it in the application header and blocking a particular version is a direct, obvious application.
• Motivation: Blocking obsolete/insecure SSL/TLS versions (SSLv2, SSLv3, TLS 1.0) was a known security practice by 2010–2013 (e.g., POODLE-era mitigations were anticipated by rule sets like Emerging Threats). A POSA enforcing a policy "allow only TLS 1.1–1.2" would set a drop rule keyed on the version field — the claimed function.

Combination E — RTP/RTSP-value filtering (claims 7/14/20)

• Primary: US 2002/0186683 A1 (Buck, firewall gateway for voice-over-IP telephony — handles RTP media streams at a gateway); Emerging Threats RTSP/RTP buffer-overflow detection rules (per the FWD, "Emerging Threats detects a buffer overflow attack and … RTSP conditions could be detected to drop packets based on an analogous rule"); US 2002/0121888 A1 (Syvanne, security gateway element).
• Mapping: A gateway that inspects RTP/RTSP application headers and drops packets matching a particular RTP value (e.g., an exploit signature) is a routine extension of VoIP-aware firewalling, which by 2013 already filtered RTP/RTSP/SIP at the application layer.
• Motivation: Protecting networks from RTP/RTSP-based attacks was a known gateway function; the patent itself acknowledges a "packet filter [that] rapidly detect[s] if an IP packet contains a Real-time Transport Protocol (RTP) application packet" was a contemplated use — i.e., the specification concedes the desirability was known.

VI. The weakest claims and the strongest counterarguments

1. Claims 5/12. These are the only claims the PTAB declined to invalidate, and the reason was evidentiary, not substantive: the petitioner never explained why a POSA would enable both Rule 2003021 (used for the independent claims) and Rule 2010234 (used for claims 5/12) in the same system, or how they would interact. On the merits, the "request for specified resource data" vs. "request to submit data to be processed" dichotomy maps onto GET vs. POST, which the prior art (US 7,032,031; Emerging Threats Rule 2010234; HTTP-method IDS rules) indisputably distinguishes. A petitioner who supplies the missing co-enablement/rationale analysis (and who characterizes the claimed "resource data" language as a functional description of GET/POST semantics, per the specification's own HTTP-EXFIL pseudocode) would have a strong path. This is the live battleground on cross-appeal 25-1103.
2. "Configured to prevent an exfiltration operation." This is functional/statement-of-purpose language. The FWD found Rule 2003021 "prevents an exfiltration operation," treating the drop action on an SSLv3 exfiltration rule as satisfying it. The same reasoning applies to any drop action on a rule whose signature is an exfiltration vector.
3. Secondary considerations. Centripetal has historically pressed commercial success, copying, and long-felt need. In the closely related Centripetal IPRs (e.g., the '722 patent IPR affirmed by the CAFC on October 31, 2024), the Board found the objective-indicia evidence "not entitled to substantial weight" for lack of coextensiveness. That precedent will likely cut against Centripetal here. Note, however, the Federal Circuit's December 16, 2024 precedential opinion in the related '903 patent appeal (25-1052's sibling case involving Paxton/Sutton/Ivershen) vacated a Board no-obviousness finding for an inadequate motivation-to-combine analysis — the lesson for any challenger is to ensure the motivation rationale is explicit, tied to the combination (not references read in isolation), and supported by expert testimony, as the Sourcefire/Emerging Threats ground already is.

VII. Conclusion and confidence

Bottom line: On the current record, the independent claims and the great majority of dependent claims of US 10,567,343 B2 have been adjudicated obvious over Sourcefire + Emerging Threats, and independent analysis of the patent's own cited art supports multiple additional § 103 combinations. The only substantive weak point is dependent claims 5 and 12, which survive solely because the IPR petitioner failed to articulate why a POSA would enable two different Emerging Threats rules together — a gap that is curable on a future challenge. Claims 5 and 12 (and the status of the CAFC appeals) are the items to watch.

Confidence notes: High confidence on the FWD holdings, claim groups, and references (verified from the FWD PDF and the Patent Owner's Notice of Appeal). Medium confidence on the current CAFC status — I confirmed the appeal numbers and originating IPRs (RPX: 25-1052 filed 10/11/2024; 25-1103 filed 10/24/2024, both from IPR2023-00446 and IPR2023-01353) but could not verify whether the Federal Circuit has decided either appeal as of April 26, 2026; check PACER/CAFC for current status.