Invalidity dossier

US 10757126

Rule-based network-threat detection

Current assignee: Centripetal Networks, Inc.

Added 8/30/2026, 4:49:29 AM

At a glanceNo PTAB challenges4 lawsuits on fileasserted by Centripetal Networks, Inc.Software Technology & Computing Systems (T)

Active provider: DeepSeek · deepseek-v4-flash

Auto-generating section 1 of 2: Extensions…

Each section takes ~30-60s with web-search grounding. Keep this tab open — sections will fill in below as they complete.

Patent summary

Title, assignee, inventors, filing/issue dates, abstract, and a plain-language overview of the claims.

✓ Generated

I'll research the current status of US 10,757,126, including any 2026 docket activity, and verify the claim structure.

Let me pull the specific claim language and check for any 2026 activity tied to this patent number.

I have Claim 1 verbatim. Let me confirm the other independent claims (e.g., claim 11) and the current docket status.

Summary — U.S. Patent No. 10,757,126 B2

Search-scope note first: I searched for the specific identifier 10757126. The Google Patents record and USPTO-derived feeds (RPX/INSIGHT, Docket Alarm/PTAB E2E) all resolve to the same document. My search of CAFC 2026 activity surfaced no 2026 proceeding specific to the '126 patent. The 2026 Federal Circuit decisions I found involve other Centripetal patents — US 10,284,526 ('526) (No. 24-2246, decided Apr. 2, 2026), US 10,193,917 ('917) (Nos. 24-1406/24-1473, week ending Apr. 24, 2026), and a UPC appeal involving EP 3 652 914 (Centripetal Limited v. Palo Alto Networks, allocation order Mar. 23, 2026). None of those is the '126. I also encountered a result captioned "Decided: July 21, 2026" (Keysight v. Centripetal, No. 25-1053, re US 11,012,474) — that date is after today's stated date, so I treat it as an anomalous/mislabeled hit and do not rely on it.


Bibliographic data

Field Value
Patent number US 10,757,126 B2
Title Rule-based network-threat detection
Application no. 16/813,220
Filing date March 9, 2020
Issue/grant date August 25, 2020
Earliest priority April 17, 2015 (parent app. 14/690,302, now US 9,866,576)
Continuation chain 16/813,220 ← 16/706,388 (Dec. 6, 2019) ← 16/217,720 (now US 10,567,413) ← 15/827,477 (now US 10,193,917) ← 14/690,302 (now US 9,866,576)
Inventors David K. Ahn (Winston-Salem, NC); Keith A. George (Fort Royal, VA); Peter P. Geremia (Portsmouth, NH); Pierre Mallett, III (Herndon, VA); Sean Moore (Hollis, NH); Robert T. Perry (Ashburn, VA); Jonathan R. Rogers (Hampton Falls, NH)
Assignee (as issued) Centripetal Networks, Inc., Portsmouth, NH (name changed to Centripetal Networks, LLC, recorded Jan. 20, 2023)
Claims 20 total
Primary class H04L 63/1425 (traffic logging/anomaly detection); also H04L 63/0227, 63/0263
Legal status flag "Active" on Google Patents — a docket-level artifact; it does not reflect claim enforceability (see below)

Abstract (as printed)

A packet-filtering device may receive packet-filtering rules configured to cause the packet-filtering device to identify packets corresponding to network-threat indicators. The packet-filtering device may receive packets and, for each packet, may determine that the packet corresponds to criteria specified by a packet-filtering rule. The criteria may correspond to one or more of the network-threat indicators. The packet-filtering device may apply an operator specified by the packet-filtering rule. The operator may be configured to cause the packet-filtering device to either prevent the packet from continuing toward its destination or allow the packet to continue toward its destination. The packet-filtering device may generate a log entry comprising information from the packet-filtering rule that identifies the one or more network-threat indicators and indicating whether the packet-filtering device prevented the packet from continuing toward its destination or allowed the packet to continue toward its destination.


Independent claims — plain-language overview

Confidence note: I verified independent claim 1 verbatim (RPX/INSIGHT claim text, cross-confirmed against Palo Alto Networks' IPR2021-01148 demonstratives, which reproduce "[1.pre]–[1.e1]" of "'126, Claim 1"). I did not retrieve verbatim text for any further independent claims of the '126. The earlier-generated sections of this analysis assume independent claims 1 and 11; my searches confirmed claim 1 only, so I flag claim 11 as reported-but-unverified rather than asserting it.

Claim 1 — a method (independent)

Plain language, in sequence:

  1. Receive indicator-based rules from a rule provider. A "packet filtering device" receives, from a separate "rule provider device," a set of packet-filtering rules that make the device spot packets matching any of a set of network-threat indicators. Two important qualifications are written into the claim: the rules were generated by the rule provider device based on network-threat-intelligence reports supplied by one or more independent threat-intelligence providers, and the indicators must be "unique Internet host addresses or names."
  2. First packet matches → allow, and report back. If a first packet satisfies a first rule based on the indicator(s) specified by that rule, the device applies that rule's operator to allow the packet onward, and communicates back to the rule provider device data saying the packet was allowed.
  3. Receive an update from the rule provider. The device then receives an update to at least one rule.
  4. Reconfigure the rule ("allow" → "block"). Based on that update, the device modifies the first rule so that it now prevents packets matching those same indicators from proceeding to their destinations.
  5. Second packet matches the modified rule → block, and report back. If a second packet satisfies the modified rule, the device prevents it from proceeding and communicates back to the rule provider device that the packet was blocked.

The distinctive thrust of claim 1 is thus a closed feedback loop between the enforcement device and the rule provider: the filtering device reports allow/block outcomes upstream, receives a rule update in response, reconfigures its own operator from allow to block, and reports the resulting block — all rooted in rules derived from independent threat-intelligence feeds and in unique Internet host addresses or names as the indicators.

Claim 11 — reported as the other independent claim (unverified)

The IPR record and the earlier-generated sections treat claim 11 as a parallel independent claim (device/media-style) covering the same core subject matter as claim 1, with claims 2–10 depending from claim 1 and 12–20 depending from claim 11. I could not verify claim 11's verbatim text for the '126 specifically, so treat this structural description as an inference from the 20-claim set and family practice, not as a confirmed quotation.

Dependent claims (character only)

Per the specification/summary, dependents add the log-generation and flow-log consolidation features (a packet log entry containing rule-derived information that identifies the threat indicator and states whether the packet was allowed or blocked; a flow log consolidating packet-log entries with a time range and counts), scoring/ordering of threats (e.g., by number of hit packets, recency, how many intelligence providers supplied the indicators, provider reliability), and user-interface features for displaying outcomes and reconfiguring an operator via a block option.


Cross-reference: flagging a contradiction with the earlier-generated sections

The previously-generated Prior Art and Obviousness sections reconstructed claim 1 as culminating in "generating a log entry … identifying the one or more network-threat indicators … indicating allow/block" and as directed to "communicating data … to a user device." That reconstruction does not match the issued '126 claim 1, which instead recites the allow → report-to-rule-provider → receive update → reconfigure-to-block → block → report loop, with no log-entry step in the independent claim. The log-entry language appears in the '126's abstract, specification, and dependent claims (and in the independent claims of sibling family members). The earlier sections likely drew their claim-1 reconstruction from a sibling patent in the same family (e.g., US 10,193,917 or US 10,609,062). The conclusions in those sections (Sourcefire-based § 103 obviousness of claims 1–20; CAFC affirmance) are unaffected — but the element-by-element mapping for claim 1 should be corrected against the verbatim text above.


Current status (for completeness; consistent with earlier sections)

  • IPR2021-01148 (Palo Alto Networks v. Centripetal): Final Written Decision Feb. 9, 2023 held all claims 1–20 unpatentable under § 103 over the Sourcefire 3D System User Guide v4.10 (alone, and with U.S. 8,042,149).
  • CAFC Nos. 23-1654 / 23-1655: affirmed Oct. 31, 2024 (nonprecedential; Taranto, J.), upholding the "responsive to" construction.
  • E.D. Va. 2:21-cv-00137: the Court granted Centripetal's motion to dismiss the causes of action involving the PTAB-invalidated patents — including the '126 — under Rule 41(a)(2) (Dkt. 969).
  • Not verified: whether a USPTO certificate of cancellation for claims 1–20 has issued post-affirmance. Confirm at the PTAB E2E / USPTO Patent Center before pleading cancellation.

Sources: RPX/INSIGHT patent page for US10757126B2 (claim text) — https://insight.rpxcorp.com/patent/US10757126B2; Google Patents record for US10757126B2 (supplied full text — bibliographic, abstract, priority chain); IPR2021-01148 Petitioner's Demonstratives (Docket Alarm, Ex. 1099) — https://www.docketalarm.com/cases/PTAB/IPR2021-01148/ ; CAFC opinion, Centripetal Networks, LLC v. Palo Alto Networks, Inc., Nos. 23-1654/23-1655 (Oct. 31, 2024) — https://www.lit-ip.aoshearman.com/siteFiles/48136/[IP]%2023-1654.OPINION.10-31-2024_2412048.pdf ; IPWatchdog (Oct. 31, 2024) — https://ipwatchdog.com/2024/10/31/cafc-affirms-several-ptab-findings-centripetals-network-security-patent-claims-obvious/ ; E.D. Va. order, Dkt. 969, 2:21-cv-00137 — https://www.docketalarm.com/cases/Virginia_Eastern_District_Court/2--21-cv-00137/ .

Generated 9/21/2026, 11:21:02 PM

Cases on file (4)

Group view →

Specific litigation cases in our database that name US patent 10757126. The free-form analysis below may also discuss cases beyond this list.

Litigation summary

Past and pending lawsuits — plaintiffs, defendants, jurisdictions, outcomes, and notable rulings.

✓ Generated

I'll search litigation databases for cases involving US patent 10,757,126.

Let me pin down each district court case and its status.

Now let me check the other E.D. Va. cases to see which actually asserted the '126 patent.

Litigation Involving U.S. Patent No. 10,757,126

Verification note: I ran patent-keyed searches (the literal string 10757126) against Docket Alarm's "search court records on patent:(10757126)" index, the Google Patents litigation feed for US10757126B2, Unified Patents/PTAB records, and CAFC opinions. Two district-court cases and one CAFC appeal are confirmed to involve this exact patent. Four additional E.D. Va. dockets appear as family-level litigation links on the Google Patents page but are not confirmed as asserting the '126 patent specifically — I flag them separately rather than merging them in. I did not auto-correct any number; where a docket plausibly refers to a sibling patent ('028, '413, '917, '526, '370, '266, '009) I say so.


1. Confirmed litigation

Case A — Centripetal Networks, LLC (fka Centripetal Networks, Inc.) v. Palo Alto Networks, Inc.

Field Value
Plaintiff Centripetal Networks, Inc. (later Centripetal Networks, LLC, fka)
Defendant Palo Alto Networks, Inc.
Court / jurisdiction U.S. District Court for the Eastern District of Virginia (Norfolk Division)
Case No. 2:21-cv-00137 (2:21-cv-00137-EWH-LRL)
Filed March 12, 2021
Judges District Judge Elizabeth W. Hanes; Magistrate Judge Lawrence R. Leonard
Patents asserted Twelve, including US 10,757,126; the Docket Alarm patent-keyed docket shows the case's patent field listing 10,091,246; 10,503,899; 10,530,903; 10,542,028; 10,567,343; 10,567,413; 10,567,437; 10,659,573; 10,735,380; 10,749,906; 10,757,126; 10,785,266; 10,931,797
Counsel Centripetal: Kramer Levin Naftalis & Frankel LLP (James R. Hannah et al.); PAN: Ropes & Gray LLP (Douglas Hallward-Driemeier et al.)

Outcome / current status:

  • Jury verdict for Centripetal — $151,500,000 (reasonable royalty). This is reported in a Korean IP Office (KIPO) compilation of the top-10 U.S. patent damages awards of 2024, which lists "E.D. Va. 2:21-cv-00137 Centripetal Networks v. Palo Alto Networks … $151,500,000 … 원고승 [plaintiff win] … Reasonable Royalty." ⚠️ I could not verify from my sources which of the twelve asserted patents supported that verdict — the '126 patent's own claims were separately held unpatentable (below), so the verdict and the '126 patent are not necessarily coextensive.
  • Post-judgment motions included competing JMOL/attorney's-fee motions; the court granted a joint motion to bifurcate post-judgment motions related to attorneys' fees (Dkt. 990, E.D. Va.) and a motion to seal (Dkt. 1011, Nov. 15, 2024).
  • CAFC appeal — Nos. 2025-1167 and 2025-1168, consolidated as appeal and cross-appeal (caption: Centripetal Networks, LLC v. Palo Alto Networks, Inc.). On December 11, 2024 the court deactivated the appeals pending resolution of outstanding Fed. R. App. P. 4(a)(4) motions; on December 22, 2025 the district court docketed an "ORDER of USCA reactivating appeal under FRAP 4(a)(4) [25-1167]" (Dkt. 1017). A memorandum order (Dkt. 1016, Dec. 19, 2025) precedes it.
  • Current status (as of April 26, 2026): district-court case still live on post-judgment matters; the consolidated CAFC appeal (2025-1167/1168) was reactivated and is pending. Note PAN's SEC annual report disclosure states "Trial is set for February 17, 2026" in connection with this matter — I could not confirm what issue that trial setting covers (likely a remanded/remaining issue rather than the original liability trial). Treat that date as unverified in context.

'126-specific overlay: In parallel, PAN petitioned for IPR2021-01148 on the '126 patent; the PTAB's Final Written Decision (Feb. 9, 2023) held all claims 1–20 unpatentable, and the CAFC affirmed on Oct. 31, 2024 in Centripetal Networks, LLC v. Palo Alto Networks, Inc., Nos. 2023-1654, 2023-1655 (mandate issued Dec. 9, 2024). So the '126 patent's own claims did not survive, regardless of the district-court verdict.


Case B — Centripetal Networks, Inc. v. LookingGlass Cyber Solutions, Inc. et al.

Field Value
Plaintiff Centripetal Networks, Inc.
Defendants LookingGlass Cyber Solutions, Inc.; Gilman Louie; Alsop Louie Management LLC; Alsop Louie Capital 2, L.P.; Alsop Louie Partners 2, LLC
Court / jurisdiction U.S. District Court for the Eastern District of Virginia
Case No. 1:21-cv-01051
Filed September 14, 2021
Claims Patent infringement plus breach of contract, breach of fiduciary duty, and abetting breach of fiduciary duty
Accused product CloudShield Eclipse (network detection and response / inline enforcement platform)
Status Closed (per UniCourt, docket last updated May 31, 2023)

'126 nexus: Docket Alarm's patent-keyed search on patent:(10757126) returns this docket among its results, i.e., the '126 patent was part of the asserted set in this case. The complaint (Dkt. 1) alleges infringement of multiple Centripetal patents.

⚠️ Related docket flag: Google Patents also lists E.D. Va. 3:21-cv-00597, and the complaint PDF at 3:21-cv-00597 is captioned "Centripetal Networks, Inc. v. LookingGlass Cyber Solutions, Inc. et al" with the identical "Complaint for Patent Infringement, Breach of Contract, Breach of Fiduciary Duty, and Abetting Breach of Fiduciary Duty." This appears to be either a parallel/refiled or transferred companion to 1:21-cv-01051 (different division) rather than a separate defendant set. I could not resolve the 1:21-cv-01051 ↔ 3:21-cv-00597 relationship from my sources.


CAFC Appeal — Centripetal Networks, LLC v. Palo Alto Networks, Inc., Nos. 2023-1654 & 2023-1655

Not a district-court case, but it is the appellate litigation over this patent:

  • Appeals from: PTAB IPR2021-01147 (US 10,542,028) and IPR2021-01148 (US 10,757,126).
  • Decided: October 31, 2024 — nonprecedential; the panel (Judge Taranto) affirmed the Board's obviousness findings as to all claims 1–20 of the '126 patent, upholding the "responsive to" construction. Opinion available at CourtListener.
  • Mandate issued: December 9, 2024.
  • 2026 check: No new CAFC docket activity on the '126 FWD surfaced in my searches. The only 2026 CAFC decisions involving Centripetal that I found concern different patents: Centripetal Networks, LLC v. Keysight Techs., Inc., No. 24-1406 (Fed. Cir. Apr. 23, 2026) (US 10,193,917 — "Rule-Based Network-Threat Detection," affirmed in part/reversed in part) and No. 24-1416 (Fed. Cir. Apr. 23, 2026) (ITC/Section 337, US 9,264,370 and US 10,193,917). The April 2, 2026 decision likewise concerned US 10,284,526, not '126.

2. Google Patents "family litigation" links NOT confirmed as '126 cases

The Google Patents record for US10757126B2 links four E.D. Va. dockets and one CAFC docket. Of these, only 2:21-cv-00137 and 1:21-cv-01051 are confirmed by patent-keyed search. The remainder are unverified at the patent level:

Docket What I could establish Confidence
2:21-cv-00137 Centripetal v. Palo Alto Networks — '126 asserted Confirmed
1:21-cv-01051 Centripetal v. LookingGlass et al. — '126 appears in patent-keyed results High
3:21-cv-00597 Same LookingGlass complaint caption; likely companion/refile of 1:21-cv-01051 Unverified as a '126 case specifically
1:21-cv-00313 Parties/patents not determined in this session Unknown
CAFC 23-1655 Appeal of IPR2021-01148 ('126) — confirmed Confirmed

Important negative findings (avoid false positives):

  • Centripetal v. Keysight Technologies, 2:22-cv-00002 (E.D. Va., filed Jan. 2022) and the ITC Section 337 investigation 337-TA-1314 ("Certain Computer Network Security Systems…") asserted US 9,264,370; 10,193,917; 10,284,526 — not the '126 patent. The accompanying Keysight IPRs (IPR2022-01421 on US 10,681,009; IPR2023-00445 on US 10,785,266; and the '413/'526/'917 IPRs) likewise do not involve the '126 patent.
  • Centripetal v. Cisco Systems, 2:18-cv-00094 (E.D. Va.) predates the '126 patent's August 25, 2020 issuance and does not involve it.
  • The '856 patent appeals (Palo Alto Networks v. Centripetal, No. 23-2027, Fed. Cir. Oct. 22, 2025, vacated and remanded on copying evidence) concern US 9,917,856, not '126.

3. Summary table

# Case Parties Court Case No. Filed Status
1 Centripetal v. Palo Alto Networks Centripetal Networks (LLC/Inc.) v. Palo Alto Networks, Inc. E.D. Va. (Norfolk) 2:21-cv-00137 2021-03-12 Verdict for Centripetal, $151.5M; post-judgment motions ongoing; CAFC appeal 2025-1167/1168 reactivated 2025-12-22 — pending
2 Centripetal v. LookingGlass Centripetal Networks, Inc. v. LookingGlass Cyber Solutions, Inc.; Gilman Louie; Alsop Louie entities E.D. Va. 1:21-cv-01051 2021-09-14 Closed (patent + contract/fiduciary claims)
3 (companion to #2?) Caption identical to #2 E.D. Va. 3:21-cv-00597 ~2021 Relationship to #2 unresolved
4 IPR2021-01148 appeal Centripetal Networks, LLC v. Palo Alto Networks, Inc. CAFC 2023-1654 / 2023-1655 2023 Affirmed all claims 1–20 unpatentable (Oct. 31, 2024); mandate Dec. 9, 2024

4. Gaps I could not close

  1. Which patents supported the $151.5M E.D. Va. verdict — unverified. Do not assume the '126 patent drove that award; its claims were canceled in IPR2021-01148.
  2. 1:21-cv-00313 — parties and asserted patents unknown; it appears on the Google Patents litigation list but I could not retrieve its docket content.
  3. 3:21-cv-00597 vs. 1:21-cv-01051 — near-certain companion filings, but the procedural relationship (refile, transfer, or parallel) is unconfirmed.
  4. The Feb. 17, 2026 trial setting in PAN's SEC disclosure — I could not confirm which case, patent, or issue it covers.
  5. Post-CAFC cancellation certificate for the '126 patent — I did not verify that the USPTO has formally issued the certificate canceling claims 1–20; that would be the cleanest evidentiary anchor for any defendant.

Bottom line: Litigation touching US 10,757,126 is confined to Centripetal's E.D. Va. campaign — principally Centripetal v. Palo Alto Networks, 2:21-cv-00137 (verdict for Centripetal, on appeal) and Centripetal v. LookingGlass, 1:21-cv-01051 (closed) — plus the PTAB/CAFC track that canceled all 20 claims of this patent (IPR2021-01148; Fed. Cir. Nos. 2023-1654/1655, affirmed Oct. 31, 2024).

Generated 9/21/2026, 11:21:00 PM

Proceedings on file (0)

All PTAB activity →

AIA trial proceedings (IPR / PGR / CBM) filed at the USPTO Patent Trial and Appeal Board against this patent. Sourced from the USPTO Open Data Portal and refreshed every six hours; each proceeding number deep-links to the PTAB E2E docket.

Current assignee: Centripetal Networks, Inc.

No PTAB proceedings on file. This patent has not been challenged via IPR, PGR, or CBM. The absence is itself a signal — well-asserted patents eventually attract IPRs. The LLM analysis below may surface filings the ODP feed hasn’t indexed yet.

PTAB challenges

AIA trial proceedings at the USPTO Patent Trial and Appeal Board — IPR, PGR, and CBM. Petitioners, judge panels, claim-level invalidation outcomes from Final Written Decisions, and Federal Circuit appeals. The single most important defensive datapoint after litigation history.

✓ Generated

Proceedings overview

The USPTO Open Data Portal ingest currently shows zero AIA trial proceedings on file for US 10,757,126, but that appears to be an ingest gap: web search conclusively surfaces one IPR — IPR2021-01148 — Palo Alto Networks v. Centripetal, which ran to a Final Written Decision invalidating all 20 claims (1–20), affirmed by the Federal Circuit. Breakdown by status: 0 active, 1 with claims invalidated (all claims), 0 settled, 0 institution-denied, 0 claims sustained. Bottom line for a defendant: the '126 patent is dead — every claim was held unpatentable under § 103 and the PTAB's decision was affirmed on appeal; a demand letter citing US 10,757,126 has no viable infringement theory left.


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

  • Type: Inter Partes Review
  • Filed: 2021-07-13
  • Status: Final Written Decision (proceeding terminated 2023-02-09). Note: the structured ODP block reports "no AIA trial proceedings" — that is an ingest gap; this proceeding is confirmed by the PTAB docket (Paper 40), Patexia/Docket Alarm trackers, and the Google Patents metadata for the patent, which itself flags "PTAB case IPR2021-01148 filed (Final Written Decision)."
  • Judge panel: Kevin F. Turner (author of the FWD), Brian J. McNamara, Lynne E. Pettigrew
  • Petition grounds: Claims 1–20 under 35 U.S.C. § 103(a) — Ground 1: obviousness over the Sourcefire 3D System User Guide Version 4.10 ("Sourcefire") alone; Ground 2: obviousness over Sourcefire in view of U.S. Patent No. 8,042,149 ("Judge"). Supported by the Declaration of Dr. Wenke Lee (Ex. 1003). Sourcefire's public accessibility as prior art was already established in the earlier IPR2018-01760 (affirmed by the CAFC in Centripetal Networks, Inc. v. Cisco Systems, Inc., 847 F. App'x 869/881 (Fed. Cir. 2021)).
  • Institution decision: Instituted on 2022-02-10 as to all challenged claims (all 20 claims on both grounds).
  • Final Written Decision (Paper 40, dated 2023-02-09): All challenged claims 1–20 held unpatentable. The Judgment states verbatim: "we determine that Petitioner has shown, by a preponderance of the evidence, that claims 1–20 ('the challenged claims') of U.S. Patent No. 10,757,126 B2 (Ex. 1001, 'the '126 Patent') are unpatentable." There were no surviving claims — no independent claim and no dependent claim was held patentable. The core holding: Sourcefire's 3D Sensor intrusion rules, which trigger operators and log/communicate events when a packet matches rule-header IP addresses (network-threat indicators) plus optional rule-option criteria, rendered every claim obvious.
  • Settlement / termination: None — no settlement. The case proceeded through oral hearing (November 1, 2022) to a full merits FWD; terminated upon issuance of the FWD on 2023-02-09.
  • Appeal: Centripetal appealed; the '126 appeal was docketed as Centripetal Networks, LLC v. Palo Alto Networks, Inc., No. 2023-1655 (Fed. Cir.), consolidated with No. 2023-1654 (the companion IPR2021-01147 on the sibling '028 patent). On 2024-10-31, a nonprecedential panel (Judge Taranto) affirmed the Board. Centripetal's arguments — that the Board failed to construe "responsive to," misread the "based on one or more network-threat indicators" language, erred in finding Sourcefire taught the "responsive to" limitation, and misconstrued "comprising" — were all rejected; the court held "responsive to" permits the applying/communicating steps to be triggered by a determination based on network-threat indicators in combination with additional criteria, and that Sourcefire taught that limitation. Opinion: Centripetal Networks, LLC v. Palo Alto Networks, Inc., Nos. 23-1654, 23-1655 (Fed. Cir. Oct. 31, 2024) (available at CourtListener).
  • Defensive value: Maximum possible. All 20 claims of US 10,757,126 are canceled — any infringement theory built on this patent is dead. The unpatentability finding is final after CAFC affirmance, so the patent is unenforceable against anyone, and Centripetal is collaterally estopped from relitigating the Sourcefire-based obviousness issues it actually litigated.

Strategic summary

Claim status — CANCELED vs. SUSTAINED vs. UNTESTED. Every claim of US 10,757,126 — independent claims 1, 11 (and any other independents in the 20-claim set) and all dependents 2–10, 12–20 — was challenged in IPR2021-01148 and all 20 were held unpatentable under § 103 in the FWD (Paper 40, 2023-02-09), with the Federal Circuit affirming in full on 2024-10-31. There are zero surviving claims and zero untested claims. The patent is, in practical enforcement terms, an empty shell. This is not a "hardened" patent that survived review — it is the opposite: a patent whose entire claim set was wiped out and affirmed on appeal. Note the patent's "Active" legal-status flag on Google Patents is a docket-level artifact and does not reflect claim enforceability.

Estoppel landscape. Under 35 U.S.C. § 315(e)(2), Palo Alto Networks and its privies are estopped from raising (in PTO or district court) any ground they raised or reasonably could have raised in IPR2021-01148 — i.e., § 103 challenges over Sourcefire alone or Sourcefire + Judge against claims 1–20. That matters little here because the claims are already canceled. For a new defendant not in privity with PAN, § 315(e)(2) imposes no bar, but you don't need your own IPR: the final, appeal-affirmed FWD gives you a ready-made invalidity defense, and collateral estoppel runs against the patent owner on the litigated Sourcefire issues (PAN pressed exactly that issue-preclusion argument in the CAFC appeal). Any remaining § 102/§ 103 ground not involving the Sourcefire family would still be available if the patent owner somehow attempted a revival theory — but with all claims canceled, the practical answer is that no validity ground is needed.

Pattern signals. This is one proceeding in a coordinated, multi-patent attack by Palo Alto Networks on Centripetal's "Rule-Based Network-Threat Detection" family: IPR2021-01147 (US 10,542,028), IPR2021-01148 (US 10,757,126, at issue here), IPR2021-01149 (US 10,567,413), and later IPR2022-00182 (US 9,917,856), plus the earlier Cisco-driven IPR2018-01760 on sibling US 9,413,722. Centripetal has litigated and appealed aggressively — it took both IPR2021-01147/01148 appeals to the CAFC (affirmed), and in a related '856 appeal (No. 2023-2027) it won a vacatur-and-remand in October 2025 — so patent owner persistence is the norm. On the defensive side, the Unified Patents branding in the Google Patents metadata is the data-source attribution for the PTAB/ litigation feeds, not an indication that Unified Patents was the petitioner; the petitioner here was Palo Alto Networks. The broader takeaway: this family has been systematically dismantled by IPR, with the '126 patent being the clearest case of total claim cancellation.


Recommended next steps

  • If you're a defendant being asserted against under US 10,757,126: the claims are gone. Cite the Final Written Decision — Palo Alto Networks, Inc. v. Centripetal Networks, Inc., IPR2021-01148, Paper 40 (P.T.A.B. Feb. 9, 2023) ("we determine that Petitioner has shown, by a preponderance of the evidence, that claims 1–20 … are unpatentable") — and the CAFC affirmance, Centripetal Networks, LLC v. Palo Alto Networks, Inc., Nos. 23-1654, 23-1655 (Fed. Cir. Oct. 31, 2024) (nonprecedential), available at CourtListener. The PTAB decision docket (Paper 40, 2023-02-09) is viewable via USPTO PTAB E2E / PRPS and the district-court copy at Docket Alarm (EDVA 2:21-cv-00137, Dkt. 322-2). Demand dismissal or judgment on the pleadings; if the demand letter cites this patent, the assertion should be withdrawn.
  • Check the PTAB certificate / reexamination record. Confirm the certificate of cancellation issued after the CAFC affirmance (the USPTO should have canceled claims 1–20 in the patent file) so you can plead claim cancellation with precision.
  • No active proceedings are pending on this patent, so there are no institution-deadline, oral-hearing, or FWD-due milestones to track. The statutory one-year trial clock (from the 2022-02-10 institution to the 2023-02-09 FWD) has long run.
  • Caveat on the data discrepancy. The ODP block in this prompt reports no PTAB activity — that is contradicted by the public record (including Google Patents' own metadata for this patent). Treat the ODP result as an ingest gap; the proceeding above is real, documented, and outcome-final. No certiorari petition or further appeal activity on the '126 FWD was found as of the current date, and the CAFC's affirmance (October 2024) stands as the terminal event.

Generated 8/30/2026, 6:47:22 PM

Ownership chain (2)

Asserters network →

Structured records extracted from the assignment-history narrative below. Each entity links to its full ownership-network profile.

  1. ? · recorded 2020-03-10 · Assignment

    MALLETT, PIERRE, III; GEORGE, KEITH A.; PERRY, ROBERT T.; MOORE, SEAN; GEREMIA, PETER P.; AHN, DAVID K.; ROGERS, JONATHAN R.Centripetal Networks, Inc.

    acquisition

  2. ? · recorded 2023-01-20 · Change of Name

    Centripetal Networks, Inc.Centripetal Networks, Inc.

    change of name only

Assignment history

Inventors, original assignee, and the chain of ownership recorded with the USPTO — including the correspondent attorney who recorded each assignment, since shell-LLC chains often share one repeat-player attorney even when the entity names look unrelated. Surfaces NPE / patent-troll patterns: shell-entity transfers, known asserters in the chain, repeat correspondent fingerprints, pre-litigation assignments, and bankruptcy fire-sales.

✓ Generated

I'll research the assignment record for US 10757126 by cross-referencing USPTO Assignment Center, Google Patents legal events, and public NPE directories.

I was unable to pull the exact reel/frame numbers or correspondent names from the USPTO Assignment Center in this session (search results did not surface the raw assignment records). Below is the record reconstructed from the primary sources I could verify — Google Patents legal-event feed (which mirrors USPTO assignment records), the issued patent front page, the IPR exhibit copy of the patent, and public litigation records — with the gaps flagged explicitly rather than filled in.

Inventors

All seven inventors are named on the issued patent (front page, confirmed in IPR2021-01148 Exhibit 1001):

Inventor Residence on record Employer at filing (determinable)
David K. Ahn Winston-Salem, NC Centripetal Networks, Inc.
Keith A. George Fort Royal, VA Centripetal Networks, Inc.
Peter P. Geremia Portsmouth, NH Centripetal Networks, Inc.
Pierre Mallett, III Herndon, VA Centripetal Networks, Inc.
Sean Moore Hollis, NH Centripetal Networks, Inc. (CTO)
Robert T. Perry Ashburn, VA Centripetal Networks, Inc.
Jonathan R. Rogers Hampton Falls, NH Centripetal Networks, Inc.

Pattern note: all seven inventors assign to the same applicant (Centripetal Networks, Inc., Portsmouth, NH) in a single collective assignment — this is a normal in-house inventor team filing, not the "all inventors depart within 12 months before a fire-sale" pattern. No unusual pattern present.

Original assignee

  • Entity on the issued patent (73): Centripetal Networks, Inc., Portsmouth, NH (the front page of US 10,757,126 B2 lists the applicant/assignee as Centripetal Networks, Inc.).
  • Line of business / product: Operating cybersecurity company. Shipped commercial products embodying the technology — notably CleanINTERNET managed security services and related network-threat-detection gateways (CleanINTERNET is cited as an exhibit in Centripetal's own 2022 complaint against Keysight; Deloitte 2019 Technology Fast 500 ranking #93 is cited in the same litigation record). The company is a direct competitor of Cisco, Palo Alto Networks, Keysight, and LookingGlass.
  • Current status: Operating. Converted/renamed from Centripetal Networks, Inc. to Centripetal Networks, LLC per a recorded CHANGE OF NAME (2023-01-20, per Google Patents legal events). Privately held; no SEC filings I can confirm. Note the metadata quirk: Google Patents labels the 2020-03-09 filing as "filed by Centripetal Networks LLC" while the patent front page and the 2020-03-10 assignment name Centripetal Networks, Inc. — consistent with the entity later operating under the LLC name.

Assignment timeline

USPTO Assignment Center records: I could not retrieve the raw reel/frame entries or the correspondent of record in this session (the Assignment Center's search interface was not reachable via my search tools, and the indexed mirror did not surface the underlying records). What follows is the assignment chain as reflected in Google Patents' legal-event feed and the patent's own assignment history. Verify reel/frame and correspondent at https://assignmentcenter.uspto.gov/ before citing. I have not fabricated reel/frame numbers.

  • 2020-03-10 recorded (execution date not retrievable; assignment of the continuation application 16/813,220 filed 2020-03-09)

    • Conveyance: Assignment of Assignors' Interest
    • Assignor: MALLETT, PIERRE, III; GEORGE, KEITH A.; PERRY, ROBERT T.; MOORE, SEAN; GEREMIA, PETER P.; AHN, DAVID K.; ROGERS, JONATHAN R. (all seven inventors)
    • Assignee: CENTRIPETAL NETWORKS, INC.
    • Correspondent: not retrievable in this session
    • Context: standard inventor-to-employer assignment for the continuation application that matured into the '126 patent. Not a transfer to any third party.
  • 2023-01-20 recorded (per Google Patents legal events)

    • Conveyance: Change of Name
    • Assignor: CENTRIPETAL NETWORKS, INC.
    • Assignee: CENTRIPETAL NETWORKS, LLC
    • Correspondent: not retrievable in this session
    • Context: internal reorg / entity-name conversion only. The same entity continues to own the patent; no change in beneficial ownership, no transfer to an outside party.

Important: If the Assignment Center shows only these two events (plus, possibly, a 2015-era inventor assignment on the parent application 14/690,302 that I could not verify), that is itself a finding: the original operating assignee still owns the patent after a mere name change, with no NPE transfer at any point.

Timeline diagram

timeline
    title Ownership of US 10757126
    2015 : Parent application filed
    2020 : Continuation filed
         : Inventors assign to Centripetal Inc
         : Patent issued Aug 2020
    2021 : First infringement suits filed
    2023 : Name change to Centripetal LLC

NPE / troll-pattern signals

  1. Shell-entity transfer — not present. The assignee is Centripetal Networks, which ships commercial products (CleanINTERNET, network-threat-detection gateways) and is a named competitor in the security-appliance market. The "LLC" in the current name is the operating company post-conversion, not a licensing-only shell. No "IP / Holdings / Licensing / Ventures" shell appears in the chain.

  2. Known asserter in the chain — not present (with a caveat). Centripetal is a high-frequency plaintiff (sued Cisco, Palo Alto Networks, Keysight, LookingGlass, among others), but it is an operating company, not an entity on the Acacia/Marathon/IV/IPNav/Wi-LAN-class NPE lists. Unified Patents and RPX track Centripetal's patents because they are heavily challenged (IPR2021-01148, IPR2018-01760, PGR2021-00108), not because Centripetal is classified as an NPE.

  3. Repeat correspondent across the chain — unclear. I could not retrieve the correspondent of record for either recorded event this session. This is the one signal I'd flag for verification at the Assignment Center; based on available data there is no evidence of a repeat-player NPE recording attorney.

  4. Cascading transfers — not present. Only two recorded events over the patent's life: inventors→Centripetal Inc. (2020) and Inc.→LLC name change (2023). No chained LLC transfers.

  5. Pre-litigation transfer — not present. The first infringement suits naming the '126 patent were filed in 2021 (e.g., Centripetal Networks, LLC v. Palo Alto Networks, Inc., 2:21-cv-00137, E.D. Va., filed 2021-03-12; Centripetal Networks, Inc. v. LookingGlass Cyber Solutions, Inc. et al., 1:21-cv-01051, filed 2021-09-14). The only post-issuance recorded event (2023 name change) came after the litigation began, and the 2020 assignment is the standard inventor-to-employer conveyance executed with the continuation filing — not an arrangement to enable standing or venue.

  6. Bankruptcy fire-sale — not present. Centripetal Networks has not filed for bankruptcy; no trustee-sale or §363 assignment appears in the chain.

  7. Privateering — not present. Centripetal asserts in its own name against direct competitors (Cisco, Palo Alto, Keysight, LookingGlass) and sells competing products. There is no operating-company-to-NPE handoff.

  8. Defensive aggregator (anti-NPE) — not present. The chain terminates at Centripetal Networks, LLC, not at RPX/AST/LOT/Unified/OIN.

Verdict

Operating-company assertion.

The chain is a plain two-step record — seven inventors assigned to Centripetal Networks, Inc. on the 2020 continuation filing, followed by a 2023 change-of-name to Centripetal Networks, LLC — with no transfer to any shell, NPE, aggregator, or third party at any point. Centripetal is a product-shipping cybersecurity vendor (CleanINTERNET and related threat-detection gateways) that is asserting the '126 patent against actual competitors (Palo Alto Networks in 2:21-cv-00137; also Cisco, Keysight, and LookingGlass in the same E.D. Va. campaign), which is the classic operating-company assertion profile. The only caveat is the unverified correspondent of record on the two recorded events; check reel/frame and correspondent at https://assignmentcenter.uspto.gov/ (search by patent number 10,757,126) to close that gap — if a repeat recording attorney appears on both entries, revisit signal 3, but even then the operating-company product and competitor-suit evidence would dominate the verdict.

Generated 8/30/2026, 6:47:18 PM

Prior art

Earlier patents, publications, and products that may anticipate or render the claims unpatentable.

✓ Generated

The first search returned a false positive (a different US 10,757,126 family — a memory circuit). The second surfaced the Unified Patents "Patent Art (297)" list and the IPR context (Sourcefire 3D System). Let me pull the actual citations listed on the face of US10757126B2 from Google Patents and USPTO.

I now have the IPR context (Sourcefire 3D System User Guide + U.S. 8,042,149 "Judge" as the petition's asserted art). Now I need the "References Cited" list printed on the face of US10757126B2 itself. Let me pull that from Google Patents/USPTO.

I've reached the tool-call limit for this task, so I'll compile the answer from the verified materials I retrieved: (1) the actual front page of US 10,757,126 B2 (the "References Cited" section as printed in the patent, obtained via the IPR2021-01148 Exhibit 1001 PDF), (2) the IPR petition (Docket Alarm), (3) the CAFC opinion (23-1654/23-1655, Oct. 31, 2024), and (4) Unified Patents' "Patent Art" list. I flag completeness and confidence issues explicitly rather than fabricating titles.


Prior Art for US 10,757,126 B2 ("Rule-Based Network-Threat Detection")

0. Scope and completeness caveats (read first)

  • The front page of US 10,757,126 B2 lists a "References Cited" section with ~40+ U.S. patent documents plus foreign patent documents and non-patent literature. My retrieval of that front page (Exhibit 1001 in IPR2021-01148) was truncated at "8,009,…", so the list below is the portion I verified verbatim from the patent face. Unified Patents catalogs 297 items of "Patent Art" against this patent, which is a broader universe (including examiner citations and cited-by art) than the face-of-the-patent list.
  • No reference was found to anticipate the claims under § 102 in any final agency or court decision. The PTAB's Final Written Decision (Feb. 9, 2023, Paper 40) held claims 1–20 unpatentable as obvious under § 103 over the Sourcefire 3D System User Guide alone (Ground 1) and over Sourcefire + U.S. 8,042,149 "Judge" (Ground 2) — not anticipated. The CAFC affirmed (Appeal Nos. 2023-1654/2023-1655, Oct. 31, 2024). So my § 102 assessments below are analyst judgments about potential anticipation, not holdings.
  • The patent is post-AIA (effective filing date April 17, 2015), so § 102(a)(1)/(a)(2) (AIA) applies; the IPR references were characterized as § 102(a)(1) prior art.

1. The two most relevant references (the art actually litigated against claims 1–20)

1a. Sourcefire 3D System User Guide, Version 4.10 ("Sourcefire")

  • Full citation: Sourcefire, Inc., Sourcefire 3D System User Guide, Version 4.10 (Apr. 2011), distributed on CD-ROM with each 3D System appliance sold/offered for sale from April 2011 through at least March 2013 (IPR2021-01148, Ex. 1004; public-accessibility established via Ex. 1031, Ex. 1052/1053).
  • Publication/filing date: Prior art under post-AIA § 102(a)(1); the CAFC (affirming the PTAB in the earlier IPR2018-01760) expressly held Sourcefire was publicly accessible as of April 2015 and qualifies as a printed publication. Not a patent — a user guide.
  • Brief description: Enterprise threat-management system ("3D Sensor" with an Intrusion Prevention System component). Uses customizable "intrusion rules" to analyze network traffic; rule criteria correspond to packet source/destination information (e.g., source and destination IP addresses and ports — the Board found IP addresses are undisputedly "network-threat indicators") and optionally packet-content criteria. When a packet matches all conditions of a rule, the rule triggers and dictates an "intrusion action" (allow/drop/etc.) and generates/logs an "intrusion event." The Board found this teaches receiving packets, determining a packet satisfies a rule based on network-threat indicators, applying an operator (allow/block), and communicating/logging information responsive to that determination.
  • § 102 anticipation potential (claims): Claims 1–20. The Board's § 103 finding over Sourcefire alone shows the reference discloses nearly the entire claim set; the only reason the holding was § 103 rather than § 102 is that the record was framed as obviousness. A § 102 anticipation case would turn on whether every limitation (particularly the log entry "comprising information from the packet-filtering rule that is distinct from the criteria" that "identifies the one or more network-threat indicators," and the user-device interface update) is expressly or inherently disclosed in the single user guide. The CAFC's affirmance of the "responsive to" construction (action based on threat-indicator source information in combination with other criteria) materially strengthens a potential § 102 theory because the trigger condition is not limited to indicator-only matching. Highest-risk single reference for anticipation of claims 1–20.

1b. U.S. Patent No. 8,042,149 B2 ("Judge")

  • Full citation: U.S. 8,042,149 B2, issued Oct. 18, 2011 (IPR2021-01148, Ex. 1005). Inventor surname Judge (assignee not verified in my sources).
  • Publication/filing date: Issued Oct. 18, 2011 → prior art under post-AIA § 102(a)(1) and § 102(a)(2) (per the petition).
  • Brief description: Cited in Ground 2 of the IPR petition in combination with Sourcefire. (I did not retrieve the patent's full text; based on its use in the petition it supplies rule/network-threat-intelligence functionality asserted to fill gaps in Sourcefire. Title and detailed content not verified — treat description as placeholder.)
  • § 102 anticipation potential: Standing alone, low-to-moderate for any single claim — it was asserted as a combination reference (§ 103, Ground 2), which strongly suggests it alone was not considered to disclose the full combination. Potential anticipation would need a showing it alone discloses all elements of a claim, which the IPR record did not assert.

2. Face-of-the-patent "References Cited" — U.S. patent documents (verified from the patent front page, partial list)

Format: Patent No. (Inventor, printed issue date) — title/description — § 102 assessment. Where I could not verify a title from the retrieved sources, I say so rather than guess. All of these are pre-AIA-effective-dates and thus § 102(a)(1)/102(a)(2) (AIA) prior art relative to the April 17, 2015 effective filing date.

# Citation (as printed) Brief description § 102 anticipation potential (claims 1–20)
1 US 6,098,172 A (Coss et al., Aug. 2000) Network traffic measurement and analysis. Title not independently verified. Low — traffic metering, not the claimed rule/operator/log-indicator combination.
2 US 6,147,976 A (Shand et al., Nov. 2000) Packet processing/routing. Title not verified. Low.
3 US 6,226,372 B1 (Beebe et al., May 2001) — Securelogix "Tightly Integrated Cooperative Telecommunications Firewall and Scanner with Distributed Capabilities" (verified via Unified Patents). Firewall + vulnerability scanner with distributed policy enforcement. Moderate — discloses filtering rules and logging; lacks the network-threat-indicator-rule + allow/block + distinct-info log + user-device update combination.
4 US 6,279,113 B1 (Vaidya, Aug. 2001) Firewall/security. Title not verified. Low.
5 US 6,317,837 B1 (Kenworthy, Nov. 2001) Firewall configuration. Title not verified. Low.
6 US 6,484,261 B1 (Wiegel, Nov. 2002) Rule-based packet filtering / graphical specification of filtering rules. Title not verified. Moderate — rule criteria over packet fields; no threat-indicator intelligence or allow/block logging to a user device as claimed.
7 US 6,611,875 B1 (Chopra et al., Aug. 2003) Title not verified. Low.
8 US 6,662,235 B1 (Callis et al., Dec. 2003) Network management/security. Title not verified. Low.
9 US 6,678,827 B1 (Rothermel et al., Jan. 2004) Likely security/key-management related. Title not verified. Low.
10 US 6,826,694 B1 (Dutta et al., Nov. 2004) Firewall/security. Title not verified. Low-to-moderate.
11 US 6,907,042 B1 (Guchi, Jun. 2005) Title not verified. Low.
12 US 6,971,028 B1 (Lyle et al., Nov. 2005) Packet processing. Title not verified. Low.
13 US 7,059,581 B1 (Nagai et al., Aug. 2006) Security. Title not verified. Low.
14 US 7,095,716 B1 (Ke et al., Aug. 2006) Title not verified. Low.
15 US 7,107,613 B1 (Chen et al., Sep. 2006) Security/firewall. Title not verified. Low.
16 US 7,143,438 B1 (Coss et al., Nov. 2006) Related to traffic measurement family (see #1). Low.
17 US 7,152,240 B1 (Green et al., Dec. 2006) Title not verified. Low.
18 US 7,185,368 B2 (Copeland, III, Feb. 2007) Attack detection/defense (Copeland has multiple network-security patents). Title not verified. Moderate — IDS-style rule matching; lacks claimed threat-indicator-rule/log/UI combination.
19 US 7,215,637 B1 (Ferguson et al., May 2007) Likely denial-of-service detection/prevention. Title not verified. Low-to-moderate.
20 US 7,225,269 B2 (Watanabe, May 2007) Title not verified. Low.
21 US 7,227,842 B1 (Ji et al., Jun. 2007) Title not verified. Low.
22 US 7,237,267 B2 (Rayes et al., Jun. 2007) Title not verified. Low.
23 US 7,263,099 B1 (Woo et al., Aug. 2007) Title not verified. Low.
24 US 7,296,288 B1 (Hill et al., Nov. 2007) Title not verified. Low.
25 US 7,299,353 B2 (Le Pennec et al., Nov. 2007) Title not verified. Low.
26 US 7,331,061 B1 (Ramsey et al., Feb. 2008) Title not verified. Low.
27 US 7,478,429 B2 (Lyon, Jan. 2009) Title not verified. Low.
28 US 7,499,412 B2 (Matityahu et al., Mar. 2009) Title not verified. Low.
29 US 7,539,186 B2 (Aerrabotu et al., May 2009) Title not verified. Low.
30 US 7,610,621 B2 (Turley et al., 2009) "System and method for behavior-based firewall modeling" — verified via Google Patents' citation page for US 7,610,621 (it appears in the citation network of the Centripetal family). Behavior-based firewall rule generation. Moderate-to-high among the cited patents — rule-based firewall with behavioral modeling; still would need the network-threat-indicator-derived rules, distinct-info log entries, and user-device block/allow interface update to anticipate.
31 US 7,684,400 B2 (Govindarajan et al., Mar. 2010) Title not verified. Low.
32 US 7,710,385 B2 (Ilnicki et al., May 2010) Title not verified. Low.
33 US 7,721,084 B2 (Salminen et al., May 2010) Title not verified. Low.
34 US 7,792,775 B2 (Matsuda, Sep. 2010) Title not verified. Low.
35 US 7,814,158 B2 (Malik, Oct. 2010) Title not verified. Low.
36 US 7,814,546 B1 (Strayer et al., Oct. 2010) Title not verified (Strayer is associated with BBN network-security work, e.g., botnet/attack detection). Low-to-moderate.
37 US 7,815,794 B2 (Wittman, Oct. 2010) Title not verified. ⚠️ Do not confuse with US 7,818,794 B2 ("Data Traffic Filtering Indicator," InterDigital), which appears in Unified Patents' art list but is a different number. Low.
38 US 7,849,502 B1 (Bloch et al., Dec. 2010) Title not verified. Low.
39 US 7,913,303 B1 (Rouland et al., Mar. 2011) Title not verified (Rouland is associated with Sourcefire-family IDS work). Moderate — IDS rule matching/logging; lacks claimed threat-indicator-rule + UI update combination.
40 US 7,954,143 B2 (Aaron, May 2011) Title not verified. Low.
41 US 8,004,994 B1 (Darisi et al., Aug. 2011) Title not verified. Low.
42 US 8,009,… (list truncated in retrieved exhibit) Additional references not retrieved; the front page continues beyond this point (including foreign patent documents and NPL). n/a — unretrieved.

3. Additional art in the citation network (Unified Patents "Patent Art" list, 297 items — sampled)

These are associated with the patent's art landscape (some may be cited-by or examiner art rather than face-of-patent citations). Notable samples verified from the Unified Patents portal:

  • US 8,726,379 B1 (Norse Networks, "Systems and Methods for Dynamic Protection from Electronic Attacks," priority Jul. 14, 2011) — dynamic threat protection; moderate anticipation potential for threat-indicator-driven filtering claims.
  • US 9,124,552 B2 ("Filtering Network Data Transfers," priority Mar. 11, 2013) — moderate.
  • US 2015/0052601 A1 (Univ. of North Carolina, "Methods, Systems, and Computer Readable Media for Rapid Filtering of Opaque Data Traffic," priority Mar. 29, 2012) — moderate.
  • US 2006/0212572 A1 (Cisco, "Protecting Against Malicious Traffic," priority Oct. 16, 2000) — moderate.
  • US 2005/0229246 A1 (Intel, "Programmable Context Aware Firewall with Integrated Intrusion Detection System," priority Mar. 30, 2004) — moderate-to-high — context-aware firewall with integrated IDS is close to the claimed combination.
  • US 2010/0115621 A1 (Magenta Security, "Systems and Methods for Detecting Malicious Network Content," priority Nov. 2, 2008) — moderate.
  • EP 1 677 484 A2 (Microsoft, "Method and System for Distributing Security Policies," priority Nov. 18, 2004) — moderate.
  • Others (US 2005/0024189 A1, US 2006/0104202 A1, US 2008/0005795 A1, US 2004/0131056 A1, US 2011/0277034 A1, US 2006/0136987 A1, US 9,154,446 B2, US 7,818,794 B2, US 2005/0141537 A1, US 2013/0007257 A1, US 2002/0016858 A1) — low-to-moderate individually.

4. § 102 anticipation analysis — bottom line

  1. No court or Board decision has found any reference anticipates claims 1–20 under § 102. The operative invalidity finding is § 103 obviousness of all claims 1–20 over the Sourcefire 3D System User Guide v4.10 alone (and over Sourcefire + Judge), affirmed by the CAFC on Oct. 31, 2024.
  2. Strongest potential § 102 case: the Sourcefire 3D System User Guide v4.10, because the Board found it discloses nearly every element (packet reception, rule criteria = network-threat indicators (IP addresses), determination, responsive applying of an operator, and responsive communication/logging). A § 102 theory would require proving Sourcefire alone expressly or inherently discloses the remaining details — chiefly (a) a log entry containing information from the rule "distinct from the criteria" that identifies the threat indicator, and (b) data communicated to a user device indicating allow/block, with an interface element for reconfiguring the operator. The CAFC's affirmance of the Board's "responsive to" construction (indicator plus other criteria) removes a major obstacle to such a theory.
  3. Among cited U.S. patents, none is a clean single-reference anticipation candidate on the retrieved record; the closest families are US 7,610,621 (behavior-based firewall modeling), US 6,226,372 (Securelogix integrated firewall/scanner), US 2005/0229246 (Intel context-aware firewall w/ IDS), US 7,913,303 (Rouland/Sourcefire-family IDS), and US 8,726,379 / US 9,124,552 (threat-intelligence-driven filtering). Each plausibly reads on subsets of the independent method claims but would need element-by-element mapping to establish § 102 anticipation of any single claim.

5. Key uncertainties

  • The front-page reference list is incomplete in my retrieval (cut off at US 8,009,…); the complete list (including foreign patents and NPL) requires the full USPTO/Google Patents citations tab or the complete Exhibit 1001 PDF.
  • Titles for ~25 of the 41 retrieved U.S. references were not verified from retrieved sources; I marked them as such rather than guessing.
  • Exact verbatim claim language of claims 1–20 was not fully retrieved in prior analysis; § 102 mapping above is at the level of the claim features summarized from the specification and IPR record.

Sources: Google Patents record for US10757126B2 (supplied full text); IPR2021-01148 Exhibit 1001 (patent front page, References Cited); IPR2021-01148 Petition (Docket Alarm, Grounds 1–2: Sourcefire Ex. 1004; Judge Ex. 1005); PTAB Final Written Decision (Feb. 9, 2023, Paper 40); CAFC Opinion, Centripetal Networks, LLC v. Palo Alto Networks, Inc., Appeal Nos. 2023-1654/2023-1655 (Oct. 31, 2024); Unified Patents patent page for 10757126 (Patent Art list); IPWatchdog and A&O Shearman summaries (Oct. 31/Nov. 5, 2024).

Generated 8/30/2026, 6:48:14 PM

Obviousness

Combinations of prior art that suggest the claimed invention would have been obvious under 35 U.S.C. § 103.

✓ Generated

I have strong initial results. Let me dig deeper into the specific obviousness grounds asserted in IPR2021-01148, the Judge reference (US 8,042,149), and the claims of the '126 patent to map the combinations.

Obviousness Analysis — U.S. Patent 10,757,126 B2 ("Rule-Based Network-Threat Detection")

Scope and evidence base

This analysis evaluates whether the claims of US 10,757,126 B2 ("the '126 patent") would have been obvious under 35 U.S.C. § 103, based on the prior-art record developed in the PTAB's inter partes review IPR2021-01148 (Palo Alto Networks, Inc. v. Centripetal Networks, Inc.) and the Federal Circuit's affirmance on appeal (Appeal No. 2023-1655).

Important caveat on claim text. The verbatim claims of the '126 patent were not included in the supplied patent excerpt and were only partially recoverable from IPR exhibits (e.g., Docket Alarm Exhibit 1035, the claim-comparison chart) and the Board/CAFC opinions. The element-by-element mapping below is therefore a reconstruction from (a) the common specification, (b) the CAFC's quotations of the "responsive to" limitation and the "receiving … packet-filtering rules configured to cause the packet-filtering device to identify packets corresponding to at least one of a plurality of network-threat indicators" limitation, and (c) the parties' IPR briefing. The legal conclusions (grounds, references, Board holdings, CAFC affirmance) are well-documented and reliable.


1. The asserted prior-art combinations (as actually litigated)

The petition in IPR2021-01148 (Docket Alarm, "Petition for Inter Partes Review," IPR2021-01148) relied on two statutory grounds, both under § 103, against all claims 1–20:

Ground Statute Claims Prior Art
1 § 103 1–20 Sourcefire 3D System User Guide v4.10 ("Sourcefire"), alone
2 § 103 1–20 Sourcefire + U.S. Patent No. 8,042,149 ("Judge")

Primary reference: Sourcefire 3D System User Guide Version 4.10 (Ex. 1004)

  • Status: Printed publication under § 102(a)(1); the user guide shipped on CD-ROM "included with each [Sourcefire] 3D System appliance sold, and offered for sale, from April 2011 through at least March 2013," i.e., publicly accessible well before the earliest priority date (April 17, 2015).
  • Estoppel effect: The Federal Circuit had already affirmed, in IPR2018-01760, that Sourcefire was publicly accessible before April 2015 and qualifies as a printed publication, estopping Centripetal from re-litigating that issue (Petition § 1(a); EX1053, 886–87).
  • Disclosure relevant to the claims:
    • A packet-filtering device — the 3D Sensor with IPS.
    • Packet-filtering rules — "intrusion rules" specifying "source and destination IP addresses," "source and destination ports," and "keywords and their parameters and arguments," allowing users to, e.g., "restrict packet inspection to the packets originating from specific IP addresses" (Board Decision, as quoted in the CAFC opinion).
    • Network-threat indicators — the Board construed this term as "an indicator that represents the identity of a resource associated with a network threat" and found that the IP addresses in Sourcefire's rule headers satisfy it; the CAFC noted these IP addresses are "undisputedly 'network-threat indicators.'"
    • Determination + responsive operator application — a packet must match all conditions of a rule to trigger the rule; the rule then "performs the operator specified in the rule" (intrusion actions). The Board found this satisfies the claimed "responsive to" determination limitation because the operator is applied when the packet matches the rule based on the IP-address indicators "as well as other criteria."
    • Logging/communication — Sourcefire generates events/alerts for the management console, providing the claimed communication of whether traffic was allowed or blocked.

Secondary reference: Judge — U.S. Patent No. 8,042,149 (Ex. 1005)

  • Status: Issued October 18, 2011 (McAfee, Inc.); prior art under §§ 102(a)(1) and 102(a)(2).
  • Disclosure relevant to the combination: Judge is directed to "systems and methods for receiving information related to messaging threats, processing the information, and generating rules and policies in response to those threats" — i.e., an automated rule-provider/threat-intelligence aggregation function that ingests external threat information (viruses, spam, attacks) and generates/propagates filtering rules and policies, deployed with firewalls at the network perimeter.

(For completeness: the parallel IPR2021-01149 against the family patent '413 used Sourcefire + US 2015/0207809 "Macaulay" — a real-time threat-agent information-sharing system with reputation scoring — but that is not the combination at issue for the '126 patent.)


2. Legal framework

Obviousness under § 103 is assessed per Graham v. John Deere Co., 383 U.S. 1 (1966): (1) the scope and content of the prior art; (2) differences between the prior art and the claims; (3) the level of ordinary skill in the art; and (4) objective indicia of non-obviousness. Under KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), a combination of familiar elements according to known methods is likely obvious when it yields predictable results, and a POSITA has the creative ability to combine prior-art teachings. The Board applied this framework and found all claims 1–20 obvious; the CAFC affirmed (Oct. 31, 2024).

Level of ordinary skill: The parties' experts (Dr. Wenke Lee for the petitioner) defined a POSITA as someone with a technical degree and several years of experience in computer networking and network security — the precise formulation is in Ex. 1003 (Lee Decl. ¶¶ 1–252), but the operative skill level is that of a network-security engineer familiar with intrusion-detection/prevention systems, firewalls, and rule-based packet filtering.


3. Why the combination renders the claims obvious

(a) Claim 1-type method (reconstructed)

Claim element (reconstructed) Sourcefire disclosure
Receiving, by a packet-filtering device, packet-filtering rules configured to identify packets corresponding to network-threat indicators 3D Sensor receives intrusion rules specifying source/destination IP addresses (network-threat indicators), ports, and keywords
Receiving a packet 3D Sensor receives network traffic at the network boundary
Determining that the packet satisfies criteria specified by a rule Rule-matching engine requires the packet to match all conditions in the rule header/options
Responsive to the determination, applying an operator (ALLOW/BLOCK) Intrusion rules "trigger" and perform the specified intrusion action (operator) when all conditions match
Generating a log entry with information from the rule, distinct from the criteria, identifying the threat indicator, and indicating allow/block Rule-triggered events with rule identity/threat information; the Board found Sourcefire's rules are "written to identify specific network threats on the basis of the source IP address being a suspicious one"
Communicating data indicating allow/block to a user device Events/alerts forwarded to the Sourcefire Defense Center management console

The Board's key findings (quoted in the CAFC opinion) were that Sourcefire teaches a packet-filtering device (3D Sensor with IPS), packet-filtering rules with IP-address criteria, a determination that a packet satisfies a rule based on those IP addresses (i.e., network-threat indicators), and application of the operator and communication of information responsive to that determination. Under the Board's construction — affirmed by the CAFC — "responsive to" permits the operator application and communication to be triggered by the rule match based on the indicators in combination with other criteria, which is exactly how Sourcefire's rules operate.

(b) What Judge adds (Ground 2)

The principal gap Centripetal pressed in its Preliminary Response was that Sourcefire does not itself disclose rules generated by a rule-provider device based on network-threat-intelligence reports (the "rule provider" / threat-intelligence aggregation feature of the specification). Judge fills precisely that gap: Judge teaches receiving threat-related information from external sources, processing it, and generating rules and policies in response to those threats, then deploying them at perimeter firewall/IDS systems. Thus:

  • Sourcefire supplies the enforcement plane: a packet-filtering device applying ALLOW/BLOCK operators to packets matching threat-indicator rules, with logging and alerting.
  • Judge supplies the intelligence-to-rule plane: automated conversion of threat intelligence into filtering rules/policies distributed to network security devices.

(c) Motivation to combine — the core § 103 inquiry

A POSITA would have been motivated to combine Sourcefire and Judge for reasons the Board accepted and the CAFC upheld:

  1. Same field, same problem. Both references address enterprise network security against malicious traffic: Sourcefire is an IPS/IDS appliance line; Judge describes firewalls and IDS "deployed at the perimeter of corporate networks" and the need to defend against evolving attacks. Combining them is a classic integration of a rule-generation layer (Judge) with a rule-enforcement layer (Sourcefire).

  2. Known, predictable benefit. Automating the deployment of up-to-date threat-intelligence-derived rules into an enforcement engine was a known technique in the art (see the family specification itself, which describes subscribing to network-threat services and translating indicators into filtering rules). Under KSR, combining known prior-art elements "according to known methods to yield predictable results" is obvious. The Board found no teaching away — and the CAFC held that the Board's Syntex misstatement (treating a sufficient condition for teaching away as a necessary one) was harmless because the Board applied the correct rule in substance.

  3. No "necessary bridge" problem. Unlike the separate Palo Alto Networks v. Centripetal case concerning the '903 patent (23-1636), where the CAFC faulted the Board for not explaining a "necessary bridge" between packet correlation and notification, here the bridge is direct and unremarkable: Judge's output (rules/policies from threat reports) is precisely the input Sourcefire's rule engine consumes. A POSITA would understand the combined system as a standard threat-intelligence-driven IPS architecture.

  4. Reasonable expectation of success. Both references use rule-based filtering with operator semantics (allow/block/alert) on IP-address criteria. Integrating Judge's rule-generation into Sourcefire's rule engine requires only conventional interfacing, giving a reasonable expectation of success. The Board rejected Centripetal's contrary argument (PO Preliminary Response § VI.E).

(d) Dependent claims (3–20, including host/destination refinements and scoring/log features)

The dependent claims refine the method with variations such as: first/second packets sharing a common host; packets originating in the second (external) network destined for a common host in the first network; scores/orderings of threats based on packet-hit counts, recency, provider count, and reliability; flow-log consolidation; and operator reconfiguration via a user interface. Sourcefire's rule engine inherently supports such variations (rules keyed to source/destination addresses, ports, protocols; event logging with rule identifiers), and the "responsive to" holding — that the claimed action may be based on indicators combined with other criteria — covers the multi-criteria host/destination limitations. Where Sourcefire alone might not explicitly teach the scoring/ordering and consolidated flow-log refinements, those are conventional data-processing features (aggregating log entries, ranking alerts by recency/severity) that a POSITA would implement as a matter of routine design, and the Board's Ground 2 combination with Judge (which teaches processing threat information into ranked/prioritized policies) supplies any residual motivation.

(e) Secondary considerations do not overcome the prima facie case

Centripetal relied on objective indicia (commercial success of its RuleGATE product, industry praise). The Board gave this evidence no substantial weight because:

  • Centripetal presented no evidence that RuleGATE was coextensive with the claims (Fox Factory requirement);
  • the praise evidence was not tied to specific claim limitations, and the expert testimony supporting it was conclusory.

The CAFC affirmed. Accordingly, the objective-indicia factor does not rescue the claims.


4. Conclusion

Under the actual litigated record:

  • Ground 1 (Sourcefire alone) renders claims 1–20 obvious: Sourcefire discloses every element of the reconstructed independent method claims under the Board's (affirmed) constructions of "network-threat indicator" and "responsive to," including the packet-filtering device, indicator-based rules, determination, operator application, log generation with rule-identifying information, and communication of allow/block data.
  • Ground 2 (Sourcefire + Judge) independently renders the claims obvious: Judge supplies the rule-provider/threat-intelligence-report-to-rule generation functionality that Centripetal argued was missing from Sourcefire alone, with a clear motivation to combine (same field, same problem, predictable integration of rule generation with rule enforcement, reasonable expectation of success, and no teaching away).

The PTAB's Final Written Decision (Feb. 9, 2023) invalidated all challenged claims as obvious, and the Federal Circuit affirmed (Oct. 31, 2024, Appeal 2023-1655), expressly upholding the "responsive to" construction that underpins the Sourcefire mapping. No 2026 docket activity has surfaced that disturbs this result.

Residual uncertainties: (1) verbatim claim language for claims 2–20 is reconstructed from IPR exhibits and opinions, so the element-by-element mapping for the dependent claims is inferred rather than claim-exact; (2) the Patexia docket page does not display the "claims instituted/invalidated" breakdown, though the FWD and CAFC opinions confirm all claims 1–20 were at issue and found obvious.

Key sources: IPR2021-01148 Petition (Docket Alarm); PO Preliminary Response (Docket Alarm, Nov. 12, 2021); CAFC opinion, Centripetal Networks, LLC v. Palo Alto Networks, Inc., No. 23-1655 (Oct. 31, 2024) (CourtListener / A&O Shearman PDF); IPWatchdog, "CAFC Affirms Several PTAB Findings that Centripetal's Network Security Patent Claims are Obvious" (Oct. 31, 2024); Google Patents record for US 8,042,149 B2; Unified Patents and Patexia docket pages for IPR2021-01148.

Generated 8/30/2026, 6:47:38 PM

Extensions

Patent term adjustments, term extensions, continuations, divisionals, family members, and expiration dates.

Not generated yet. Click Generate to call the active LLM provider with the configured prompt.

Derivative works

Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.

Not generated yet. Click Generate to call the active LLM provider with the configured prompt.

Keep exploring

More patents asserted by Centripetal Networks, Inc.

Other patents in Software Technology & Computing Systems (T)

See all Software Technology & Computing Systems (T) patents →

This patent in court (4)

4 tracked lawsuits name US 10757126.