Invalidity dossier

US 10609062

Rule-based network-threat detection

Current assignee: Centripetal Networks, LLC

Added 8/30/2026, 12:47:08 AM

At a glanceNo PTAB challenges4 lawsuits on fileasserted by Centripetal Networks, LLCSoftware 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

US Patent 10,609,062 — "Rule-based network-threat detection"

I searched for the exact number 10609062 (no auto-correction). The identifier is confirmed across Google Patents, the USPTO PTACTS IPR petition records, Unified Patents, PatSnap/PACER, and PTAB docket databases as US10609062B1 — "Rule-based network-threat detection."

Bibliographic data (authoritative per the provided Google Patents record)

  • Title: Rule-based network-threat detection
  • Patent / Publication No.: US10609062B1
  • Application No.: US16/706,388 — filed December 6, 2019 (a Continuation; chain: 14/690,302 → 15/827,477 (10,193,917) → 16/217,720 → 16/706,388)
  • Issue / Publication date: March 31, 2020
  • Earliest priority date: April 17, 2015 (application 14/690,302)
  • Assignees: Filed by Centripetal Networks LLC; assignment recorded to CENTRIPETAL NETWORKS, INC. (March 10, 2020); name change back to CENTRIPETAL NETWORKS, LLC (January 20, 2023). Current listed assignee: Centripetal Networks, LLC (Google Patents adds its standard "may be inaccurate" caveat).
  • Inventors: David K. Ahn; Keith A. George; Peter P. Geremia; Pierre Mallett, III; Sean Moore; Robert T. Perry; Jonathan R. Rogers
  • Examiner: Darren B. Schwartz (per Unified Patents)
  • Status: Listed as Active; anticipated expiration ~April 2035.
  • ⚠️ Minor data discrepancy: Unified Patents lists priority 2015-04-16, application date 2019-12-05, grant 2020-03-30, expiration 2035-04-16. Google Patents (the authoritative text you supplied) lists 2015-04-17 / 2019-12-06 / 2020-03-31 / 2035-04-17. I have flagged rather than reconciled these.

Abstract (verbatim)

"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)

The patent has 20 claims. Based on the IPR2022-01535 petition and claim charts (USPTO PTACTS records, RPX, Patexia), the independent claims appear to be claims 1 (method), 8 (method), 15 (apparatus), and 18 (computer-readable medium). ⚠️ I reconstructed these from IPR exhibits rather than the granted claims PDF, so treat the exact wording with moderate confidence:

  • Claim 1 (method): A packet-filtering device (1) receives filtering rules keyed to network-threat indicators, (2) receives packets including a first and second packet, (3) determines the first packet satisfies a rule, (4) applies the rule's operator to allow the first packet to proceed, (5) communicates the identifying indicators plus data that the packet was allowed, (6) causes display of that information in an interface portion tied to the rule, (7) receives a user-driven update to the rule, (8) modifies the rule's operator to block matching packets, then (9) blocks a subsequently-received second packet and (10) communicates/displays that it was blocked.
  • Claim 8 (method): Per the dependent claims (12–13), each threat indicator corresponds to a respective network threat; for each packet satisfying a rule the device generates a packet-log entry identifying the rule and the allow/block outcome, updates a packet-flow log (which consolidates entries) to reflect the determination and outcome, determines an ordering of the network threats from the flow-log data, and communicates data indicative of that ordering.
  • Claim 15 (apparatus): A packet-filtering device with processor(s) and memory storing instructions that carry out the claim-1-style flow (receive rules → receive packets → allow first matching packet and report it → display in an interface → receive a user update → modify the operator to block → block the second matching packet and report it). Dependent claims 16–17 add displaying the allow/block data in a user interface and generating a packet-log entry containing a threat identifier.
  • Claim 18 (computer-readable medium): One or more non-transitory computer-readable media storing instructions that, when executed by a packet-filtering device's processor(s), cause the device to perform the same receive → allow/report → user-update → modify-operator → block/report sequence.

Litigation / CAFC status (as found in searches)

  • IPR2022-01535 (Keysight Technologies, Inc. v. Centripetal Networks, Inc.): Petition filed Sept. 13, 2022; institution granted Apr. 18, 2023; Final Written Decision issued ~Apr. 16, 2024 determining all challenged claims (1–20) unpatentable (obviousness over Sourcefire, alone or with Macaulay). (https://ipverse.greyb.com/ptab-web/cases/case-details/IPR2022-01535; https://services.patexia.com/lawsuits/Keysight-Technologies-Inc-v-Centripetal-Networks-Inc-id-[181074](/patent/181074))
  • CAFC appeal No. 24-1929 (Centripetal Networks, LLC v. Keysight Technologies, Inc. — appeal of that FWD): per PACER records, voluntarily dismissed under Fed. R. App. P. 42(b) on January 14, 2025, each side bearing its own costs; no merits ruling on validity/claim scope. (https://portal.unifiedpatents.com/litigation/Court%20of%20Appeals%20for%20the%20Federal%20Circuit/case/24-1929; PatSnap/PACER summary)
  • CAFC 2026 dockets: I found no 2026 CAFC docket specific to patent 10609062 — the only CAFC appeal of this patent (24-1929) was dismissed in January 2025. The CAFC decisions in 2026 involving Centripetal v. Keysight (e.g., No. 24-1406, decided Apr. 23, 2026, on the sibling '917 patent 10,193,917; and No. 24-1416, ITC/domestic-industry case on the '370 patent 9,264,370) concern related patents in the family, not the '062 patent itself. (IPWatchdog, VitalLaw/Law360, LegalEra)
  • ⚠️ Status caveat: Because the FWD found all challenged claims unpatentable and the appeal was voluntarily dismissed (no reversal), the PTAB decision was not overturned on appeal. Some third-party commentary asserts the patent "remains fully enforceable" since the dismissal was procedural with no merits ruling — but I could not confirm from these sources whether a certificate of cancellation has issued or the precise current claim status. I recommend verifying the current claims against USPTO Patent Center / the PTAB docket before relying on enforceability.
  • District-court cases involving the family are also on record (Virginia Eastern District Court, 2:22-cv-00002 and 1:22-cv-00001; Darts-ip "first worldwide family litigation"), per the Google Patents litigation listing.

Bottom line: US10609062B1 is a Centripetal Networks "rule-based network-threat detection" patent (method/apparatus/medium claims 1, 8, 15, 18) covering a packet filter that applies threat-indicator rules, logs allow/block outcomes, and lets a user flip a rule's operator from ALLOW to BLOCK through a UI. Its only CAFC appeal (24-1929) was voluntarily dismissed in January 2025; no 2026 CAFC docket specific to this patent was found.

Generated 8/31/2026, 12:49:38 AM

Cases on file (4)

Group view →

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

Lawsuits filed per year

2022: 3 cases3'22'232024: 1 case'24
Cases asserting US 10609062, by filing year.

Litigation summary

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

✓ Generated

Based on the searches performed (current as of April 26, 2026), here is the known litigation specifically involving US patent 10,609,062 ("Rule-based network-threat detection"). I have limited this list to matters tied to the '062 patent itself and excluded the many related-family cases (e.g., 2017 E.D. Va. case 2:17cv383 on the '370/'722 patents; CAFC Nos. 24-1406 and 24-1416 on the '917 and '370 patents) that do not involve this patent number.

1. IPR2022-01535 — Keysight Technologies, Inc. v. Centripetal Networks, Inc. (PTAB)

  • Plaintiff/Petitioner: Keysight Technologies, Inc.
  • Defendant/Patent Owner: Centripetal Networks, Inc.
  • Jurisdiction: USPTO Patent Trial and Appeal Board (PTAB)
  • Case number: IPR2022-01535
  • Filing date: September 13, 2022 (petition for inter partes review of US Patent No. 10,609,062)
  • Institution: April 18, 2023
  • Outcome/Status: Final Written Decision (April 16, 2024) determining all challenged claims (1–20) unpatentable under 35 U.S.C. § 318(a). Panel: Judges John Lee (author), Brian J. McNamara, John P. Pinkerton. Patent owner appealed (see No. 2); the Board docketed the Federal Circuit mandate on January 29, 2025.
  • Sources: ipverse.greyb.com (IPR2022-01535 case details and docket); services.patexia.com (case ID 181074); Docket Alarm.

2. CAFC Appeal No. 24-1929 — Centripetal Networks, LLC v. Keysight Technologies, Inc.

  • Plaintiff/Appellant: Centripetal Networks, LLC (holder of US10609062B1)
  • Defendant/Appellee: Keysight Technologies, Inc.
  • Jurisdiction: U.S. Court of Appeals for the Federal Circuit
  • Case number: 24-1929 (docketed from the June 7, 2024 Notice of Appeal of the IPR FWD)
  • Filing date: Notice of Appeal filed June 7, 2024; appeal docketed 2024
  • Outcome/Status: Voluntarily dismissed under Fed. R. App. P. 42(b) — the dismissal order states: "The proceeding is DISMISSED under Fed. R. App. P. 42(b)… Each side shall bear their own costs." Per prior PACER research, dismissal was entered January 14, 2025, and the mandate issued January 29, 2025. The dismissal was procedural — no merits ruling on validity or claim scope — so the PTAB's all-claims-unpatentable FWD was not overturned on appeal.
  • Sources: PatSnap litigation summary (quoting PACER docket for case 24-1929); Unified Patents litigation portal (CAFC 24-1929); IPVerse PTAB docket ("Fed Circuit mandate," Jan. 29, 2025).

3. E.D. Va. Case 2:22-cv-00002 — Centripetal Networks, Inc. v. Keysight Technologies, Inc.

  • Plaintiff: Centripetal Networks, Inc. (now Centripetal Networks, LLC)
  • Defendant: Keysight Technologies, Inc.
  • Jurisdiction: U.S. District Court for the Eastern District of Virginia, Norfolk Division (2:22-cv-00002-AWA-DEM; Judge Arenda Wright Allen / Magistrate Judge Douglas E. Miller)
  • Filing date: January 1, 2022 (Complaint for Patent Infringement)
  • Outcome/Status: Stayed. Per Keysight's SEC Form 10-Q: "The lawsuit before the Federal District Court in Virginia is stayed pending the finalization of appeals of the ITC findings and validity challenges." Google Patents lists this case on the '062 patent's litigation page, though the complaint analysis I could access for this case centered on the related '370 and '917 family patents (the '062 is a continuation in the same chain). I could not confirm from the available sources precisely which of the eight asserted Centripetal patents in this action included '062.
  • Sources: Docket Alarm (doc. 10, E.D. Va.); Ex Parte/ai-lab complaint analysis for 2:22-cv-00002; Google Patents litigation listing; Keysight 10-Q.

4. E.D. Va. Case 1:22-cv-00001 — Centripetal Networks LLC v. Keysight Technologies Inc.

  • Plaintiff: Centripetal Networks, Inc. / Centripetal Networks, LLC
  • Defendant: Keysight Technologies, Inc.
  • Jurisdiction: U.S. District Court for the Eastern District of Virginia (filed in Alexandria Division; intradistrict transfer to Norfolk Division on January 4, 2022)
  • Case number: 1:22-cv-00001
  • Filing date: January 1, 2022 (Complaint for Patent Infringement)
  • Outcome/Status: Appears to be the companion Alexandria-docketed case to 2:22-cv-00002 (the docket documents cross-reference "Case No. 1:22-CV-00001"), transferred to Norfolk; stayed alongside the related Virginia action pending appeal outcomes, per Keysight's 10-Q.
  • Sources: Unified Patents litigation portal (Virginia Eastern District Court case 1:22-cv-00001, initial civil docket 01-01-2022); Docket Alarm; Google Patents litigation listing.

Important caveats (flagged, not reconciled)

  • Validity status of the '062 patent: The PTAB FWD found all claims (1–20) unpatentable, and the only CAFC appeal (24-1929) was voluntarily dismissed with no merits ruling. I could not confirm from these sources whether a certificate of cancellation has actually issued or the exact current claim status at the USPTO. Verify on USPTO Patent Center / the PTAB docket before relying on enforceability.
  • District-court patent list: Google Patents associates E.D. Va. cases 1:22-cv-00001 and 2:22-cv-00002 with the '062 patent, but the accessible complaint analysis focused on the '370 and '917 patents. Treat the specific inclusion of '062 in those complaints as probable but not fully verified.
  • No 2026 CAFC docket specific to '062 was found. The Federal Circuit decisions in 2026 involving Centripetal/Keysight (e.g., April 2, 2026 affirmance on patent 10,284,526; April 23, 2026 ITC decision; January 2026 oral argument on ITC/PTAB findings) concern other patents in the family, not 10,609,062 itself. The only CAFC appeal of this patent (24-1929) was dismissed in January 2025.

Generated 8/31/2026, 4:45:51 AM

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, LLC

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

I have strong confirmation of IPR2022-01535. Let me verify the FWD panel and exact holdings, check for any other PTAB proceedings on this patent, and confirm the post-appeal claim status (certificate of cancellation).

Proceedings overview

One proceeding is on record for US10609062B1: IPR2022-01535 (Keysight v. Centripetal), which ran to a Final Written Decision on 2024-04-16 invalidating all 20 challenged claims (claims 1–20). Breakdown by status: 0 active, 20 claims invalidated (all of them), 0 claims sustained, 0 settled, 0 institution denied. ⚠️ Flag: the USPTO ODP block in this prompt reports no AIA proceedings on file, but web sources conclusively document IPR2022-01535 — treat ODP as stale on this patent. Bottom line for a defendant: all 20 claims have been canceled at the Board and the patent owner's appeal was voluntarily dismissed — if a demand letter cites US10609062B1, the asserted claims have no surviving validity case and the infringement theory is effectively dead.


IPR2022-01535 — Keysight Technologies, Inc. v. Centripetal Networks, Inc.

  • Type: Inter Partes Review (35 U.S.C. § 311)
  • Filed: 2022-09-13
  • Status: Structured data (ODP): none on file (stale — see flag above). PTAB docket sources: "Final Written Decision" / terminated 2024-04-16. Plain-English gloss: completed in full — institution granted, FWD issued, appeal filed and voluntarily dismissed.
  • Judge panel: Per Patexia — Administrative Judges John Lee (author of the Final Written Decision), Brian J. McNamara, John P. Pinkerton. ⚠️ A secondary aggregator (docketupdate) lists "Brian McNamara, Kevin Turner, and Norman Beamer." The oral-hearing transcript confirms APJ McNamara sat on the panel (multiple "JUDGE MCNAMARA" exchanges). I could not independently reconcile the two panel listings; Patexia is more specific (it names the FWD author) and is preferred, but verify against the FWD's signature block before relying.
  • Petition grounds: All claims 1–20, on a single ground: obviousness under 35 U.S.C. § 103 over the Sourcefire 3D System User Guide Version 4.10 (a printed publication). The petition's central argument invoked collateral estoppel from the FWD in IPR2018-01760 (parent patent 9,413,722, the terminally-disclaimed '722 patent), affirmed by the Federal Circuit — arguing Sourcefire's teachings were already bindingly adjudicated against materially identical claims. (This supersedes the earlier summary note of a "Macaulay" combination: the petition and reply, per the docket exhibits, press Sourcefire alone, with collateral estoppel as an independent basis, not a second reference.)
  • Institution decision: Granted, 2023-04-18, on all challenged claims (Paper 9, "Granting Institution of Inter Partes Review, 35 U.S.C. § 314"). The Board rejected discretionary denial under § 325(d) / Advanced Bionics: although Sourcefire was before the Examiner, the Examiner had not evaluated it against the Board's affirmed '722 FWD findings, which the panel treated as material error (Becton Dickinson factors 3, 5). The institution decision also found the "network-threat indicator" construction was the same under the Phillips standard applied here and the BRI standard used in the '722 IPR (per petitioner's oral-argument summary of the decision).
  • Final Written Decision: Issued 2024-04-16 — caption verbatim: "JUDGMENT — Final Written Decision Determining All Challenged Claims Unpatentable, 35 U.S.C. § 318(a)." The petition challenged claims 1–20 (independents 1, 8, 15, 18; dependents 2–7, 9–14, 16–17, 19–20), and the FWD held all challenged claims unpatentable — i.e., claims 1–20, with no claim held patentable. I do not have the FWD's full reasoning text to quote beyond the judgment caption; the contested issue on the record was the "responsive to a determination ... based on one or more network-threat indicators" limitation — Patent Owner argued Sourcefire's rules trigger on packet contents rather than network-threat indicators, and Petitioner (supported by the '722 estoppel findings) argued Sourcefire's rule headers/arguments are themselves network-threat indicators (e.g., IP addresses) that satisfy and trigger the rules. The outcome: Petitioner prevailed on all claims.
  • Settlement / termination: No settlement. The proceeding terminated by the FWD on 2024-04-16. (A Board paper dated 2025-01-29 appears on the docket, consistent with post-mandate processing; no settlement terms exist to report.)
  • Appeal: Yes — appealed. Patent Owner Centripetal Networks, LLC filed a Notice of Appeal on 2024-06-07 (Paper 27); the Federal Circuit docketed it as No. 24-1929 on 2024-06-11 (initially treated as a companion to Centripetal appeals 24-1406 and 24-1416 on related family patents). Disposition: voluntarily dismissed on 2025-01-14 under Fed. R. App. P. 42(b), nonprecedential order: "The parties having so agreed, it is ordered that: (1) The proceeding is DISMISSED under Fed. R. App. P. 42(b). (2) Each side shall bear their own costs." The mandate issued. There was no merits ruling — the FWD was neither affirmed nor reversed.
  • Defensive value: Maximum value. The Board canceled every claim of the patent, and the patent owner walked away from the appeal. The statutory consequence under 35 U.S.C. § 318(b) is that the Director must enter a certificate canceling claims 1–20 (I could not verify the certificate's entry date in Patent Center — confirm before relying in court). Any infringement theory built on claims 1–20 is gone; a plaintiff asserting this patent post-FWD is asserting canceled claims.

Strategic summary

Canceled vs. sustained vs. untested. Every claim of US10609062B1 — claims 1–20 — was challenged, instituted, and found unpatentable in IPR2022-01535. Nothing was sustained and nothing remains untested. The FWD covers the independent method claims (1, 8), the apparatus claim (15), and the computer-readable-medium claim (18), plus all dependents (2–7, 9–14, 16–17, 19–20). The only remaining technical step is the Director's certificate of cancellation (and confirmation that no post-dismissal event — e.g., a petition for rehearing or a late mandate issue — disturbed the FWD; nothing in the docket sources indicates any). Practically, the patent has been reduced to zero enforceable claims, subject only to verification of the certificate.

Estoppel landscape. Under 35 U.S.C. § 315(e)(2), Keysight and its real parties in interest/privies are estopped in the parallel E.D. Va. litigation and the ITC from asserting any § 102/§ 103 ground they raised or reasonably could have raised in the IPR — effectively the Sourcefire ground and any art combinable with it. For a new defendant not in privity with Keysight, that estoppel does not apply: prior-art grounds remain technically available, but the practical calculus has inverted — the Board has already found the entire claim set obvious over Sourcefire, and Centripetal declined to appeal, so any challenger can ride a fully-developed, litigated record (petition, POR, replies, expert testimony, oral-hearing transcript) rather than build a new case. The "responsive to / based on network-threat indicators" claim-construction battle was lost by Centripetal at the Board, which will make re-litigating the same limitation in another forum difficult as a factual matter even where collateral estoppel does not formally bind.

Pattern signals. This IPR was one petition in a coordinated Keysight campaign against the Centripetal family: Keysight filed IPRs on 8 of 11 patents Centripetal asserted in E.D. Va. (2:22-cv-00001/2:22-cv-00002) and in the parallel ITC matter, including sibling-patent IPRs on 10,193,917 (IPR2022-01097) and 10,681,009 (IPR2022-01421, the Director-remand case). The '062 petition was deliberately built on collateral estoppel from the '722 parent's FWD (IPR2018-01760) — i.e., the same Sourcefire reference had already felled a terminally-disclaimed ancestor, so the '062 outcome was largely predetermined once the Board rejected § 325(d). There is no defensive aggregator (e.g., Unified Patents) as petitioner here — Keysight is a commercial adversary — though Unified Patents has separately tracked the family's litigation. Centripetal's pattern is to litigate aggressively (E.D. Va., ITC, repeated CAFC appeals — including the 2026 CAFC decisions in 24-1406 and 24-1416 on related patents), so the voluntary dismissal of 24-1929 is a notable signal: for this patent, Centripetal chose not to contest the invalidation on appeal.


Recommended next steps

  1. If you are a defendant facing assertion of US10609062B1: point the plaintiff to the FWD and the dismissal. The operative documents are the FWD in IPR2022-01535 (Paper 26, PTAB 2024-04-16 — "Determining All Challenged Claims Unpatentable, 35 U.S.C. § 318(a)") and the CAFC order in No. 24-1929 (2025-01-14, dismissing under Rule 42(b) with each side bearing its own costs). Both are public:
  2. Verify the certificate of cancellation on USPTO Patent Center (patent 10,609,062) before filing anything that relies on the claims being formally canceled, and check the PTAB E2E docket for any post-2025-01-29 Board action. My sources did not confirm the certificate's entry date.
  3. No active proceedings — there are no institution deadlines, oral-hearing dates, or FWD due dates to track. If Centripetal ever re-issues or re-asserts claims through a continuation of this family, note that the Sourcefire ground and the '722/'062 collateral-estoppel chain are now the established winning playbook, and the § 315(e)(2) bar applies only to Keysight and its privies — not to you.

Generated 8/31/2026, 4:46:29 AM

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

    Pierre Mallett, III, Keith A. George, Robert T. Perry, Sean Moore, Peter P. Geremia, David K. Ahn, Jonathan R. RogersCentripetal Networks, Inc.

  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

Inventors

All seven named inventors appear on the issued patent and on the family's patent cover pages as employees/assignors to Centripetal Networks, Inc., Portsmouth, NH (US) (see e.g. the "(71) Applicant: Centripetal Networks, Inc." front pages of sibling patents US 10,567,413, US 10,757,126, and US 10,542,028 reproduced in PTAB/district-court exhibits):

Inventor Residence at filing Employer
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.
Robert T. Perry Ashburn, VA Centripetal Networks, Inc.
Jonathan R. Rogers Hampton Falls, NH Centripetal Networks, Inc.

Pattern check: No unusual pattern. The identical seven-inventor team persists across the "rule-based network-threat detection" family through at least 2024 (e.g., US 12,015,626, granted 2024-06-18, per PatentLeaderboard). No mass departure from the original assignee within 12 months of filing — the tell that usually precedes a portfolio fire-sale is absent.

Original assignee

  • Entity of record on the issued patent: Centripetal Networks, Inc., Portsmouth, NH. Unified Patents also lists "Original Assignee: Centripetal Networks Inc" and "Parent Company: Centripetal Networks LLC."
  • ⚠️ Discrepancy to flag: Google Patents' legal-events tab says the application (16/706,388) was "filed by Centripetal Networks LLC" (2019-12-06), while the granted patent and Unified Patents name Centripetal Networks, Inc. This is consistent with a corporate-name conversion between filing and grant, but the underlying corporate documents could not be pulled this session — verify against USPTO Patent Center if it matters.
  • Products: Yes — Centripetal ships network-security products embodying the claimed technology (threat-intelligence-driven packet filtering / policy-enforcement gateways; its litigation and ITC Investigation 337-TA-1314 "Certain Computer Network Security Systems…" concern these products). It has also been an ITC complainant, per PTAB Ex. 2015 in IPR2022-01535.
  • Line of business: Network security (rule-based packet filtering, threat-intelligence gateways).
  • Current status: Operating. Per PatentsView (via PlainPatent), the assignee holds 119 granted US patents (2015–2025), with grants accelerating from 23 (2015–2019) to 96 (2020–2025). The recorded name change to Centripetal Networks, LLC (2023-01-20) is a change of name, not an exit.

Assignment timeline

I attempted to pull reel/frame and correspondent data from the USPTO Assignment Center, but the center was not directly queryable in this session, and no third-party index surfaced reel/frame numbers or correspondents for this patent. What follows is the complete recorded chain as corroborated by Google Patents' legal-events feed and Unified Patents (i.e., only two events — a routine employer assignment and a name change). I am not fabricating reel/frame fields; treat those two fields as unverified pending an Assignment Center lookup at https://assignmentcenter.uspto.gov/ or https://assignment.uspto.gov/patent/index.html#/patent/search.

  • Executed ~2019–2020 / recorded 2020-03-10 — Reel/Frame: not retrievable this session

    • Conveyance: Assignment of Assignors Interest
    • Assignor: Pierre Mallett, III; Keith A. George; Robert T. Perry; Sean Moore; Peter P. Geremia; David K. Ahn; Jonathan R. Rogers (the seven inventors)
    • Assignee: CENTRIPETAL NETWORKS, INC.
    • Correspondent: not retrievable this session
    • Context: Standard inventor→employer assignment for the continuation application, recorded three weeks before grant (2020-03-31). Not a market transfer.
  • Executed / recorded 2023-01-20 — Reel/Frame: not retrievable this session

    • Conveyance: Change of Name
    • Assignor: CENTRIPETAL NETWORKS, INC.
    • Assignee: CENTRIPETAL NETWORKS, LLC
    • Correspondent: not retrievable this session
    • Context: Corporate name change only; no change in beneficial ownership and no consideration.

Finding: If the Assignment Center confirms only these two events (as Google Patents indicates), then the original assignee still owns the patent. No security agreement, license, merger, or third-party assignment appears in any source I could reach (Google Patents legal events, PatentsView, PTAB/IPR records, PACER summaries, PatSnap).

Timeline diagram

timeline
    title Ownership of US 10609062
    2015 : Filed by Centripetal
    2020 : Patent issued
         : Inventors assign to Centripetal Inc
    2023 : Name change to Centripetal LLC
    2024 : IPR finds claims unpatentable
    2025 : CAFC appeal dismissed

(Litigation rows 2024–2025 are context — IPR2022-01535 Final Written Decision 2024-04-16; CAFC 24-1929 voluntary dismissal 2025-01-14. They are not ownership events.)

NPE / troll-pattern signals

  1. Shell-entity transfer — NOT PRESENT. No transfer of the patent to a licensing-only LLC. The sole LLC event (2023-01-20) is recorded as a Change of Name of the same entity, and the assignee holds 119 granted patents and sells products. A name suffix alone is not a finding, and here there is no "IP Holdings"-type transferee at all.
  2. Known asserter in the chain — NOT PRESENT. Neither the assignor (inventors) nor assignee (Centripetal Networks, Inc./LLC) matches Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Conversant, Vringo, Pendrell, Innovatio, MPHJ, Round Rock, or any Unified/RPX high-frequency NPE list I can reach. Centripetal is an operating company that litigates in its own name against competitors.
  3. Repeat correspondent across the chain — UNKNOWN. Correspondent of record could not be retrieved this session. No finding either way; do not infer.
  4. Cascading transfers — NOT PRESENT. Only two recorded events over ~3 years (inventor assignment + name change). No chained LLCs, no shared registered-agent address pattern, no rapid-fire reassignments.
  5. Pre-litigation transfer — NOT PRESENT. The 2020-03-10 assignment is the routine employer assignment tied to grant; the first district-court actions naming this patent (E.D. Va. 1:22-cv-00001, 2:22-cv-00002, filed 2022) and the Keysight IPR (2022-09-13) came ~2 years later — far outside any 6-month window.
  6. Bankruptcy fire-sale — NOT PRESENT. Centripetal is not (and has not been) in Chapter 7/11; no trustee or auction sale.
  7. Privateering — NOT PRESENT. No evidence of transfer to a third-party NPE asserting on Centripetal's behalf. Centripetal asserts directly (e.g., against Cisco, Palo Alto Networks, Keysight, Ciena, LookingGlass).
  8. Defensive aggregator (anti-NPE) — NOT PRESENT. The chain terminates at Centripetal Networks, LLC — an operating company — not RPX, AST, LOT, Unified, or OIN. The patent has not been neutralized by a defensive aggregator (though it has been challenged: IPR2022-01535 FWD of 2024-04-16 found all claims unpatentable — a validity event, not an ownership event).

Verdict

Operating-company assertion.

The recorded chain is clean: inventors → Centripetal Networks, Inc. (2020-03-10, routine employer assignment) → Centripetal Networks, LLC (2023-01-20, change of name only). The current assignee is a New Hampshire cybersecurity company with products in commerce and 119 granted patents, which sues actual competitors (Cisco, Palo Alto Networks, Keysight, Ciena, LookingGlass) in its own name — the classic operating-company assertion profile, with zero shell transfers, cascades, privateering, or defensive-aggregator terminus. Two caveats: (1) reel/frame and correspondent fields could not be verified from the USPTO Assignment Center this session and should be confirmed at https://assignmentcenter.uspto.gov/ before relying on the chain; and (2) enforceability is separately impaired by the IPR2022-01535 Final Written Decision (all claims unpatentable; CAFC appeal 24-1929 voluntarily dismissed 2025-01-14) — but that is a validity matter, not an NPE-ownership matter.

Generated 8/31/2026, 4:46:26 AM

Prior art

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

✓ Generated

I was able to gather partial but useful data before hitting the search-step limit. Below is my analysis with explicit confidence flags where the exact front-page citation list could not be fully retrieved.


Prior Art Analysis — US 10,609,062 B1 ("Rule-based network-threat detection")

1. What I searched and what I could verify

  • Verified: The IPR2022-01535 petition record (USPTO PTACTS) confirms that the most relevant prior art for the '062 patent is Sourcefire 3D System User Guide, Version 4.10 (petitioner's EX-1004), relied on (alone or with a secondary reference "Macaulay," EX-1008+ per the petition exhibit list) for obviousness of all claims 1–20. The PTAB Final Written Decision (April 2024) found all challenged claims unpatentable over Sourcefire.
  • Verified: The Google Patents page for the parent patent US 10,193,917 B2 lists 218 patent citations; the '062 patent (a continuation of the '917 chain) shares much of this body of art.
  • Partially verified (flag): I could not retrieve the complete "Patent Citations" section of the '062 patent itself in a single fetch. The reference list below comes from the Unified Patents portal page for US-10609062-B1 (which lists cited references with their priority dates) and the Justia page for 10609062 (which lists non-patent literature). Treat the exact composition of the front-page citation list with moderate confidence; the priority dates shown are effective filing dates of the cited references.

2. Most relevant prior art overall (litigation-validated)

2.1 Sourcefire 3D System User Guide, Version 4.10 (printed publication)

  • Citation: Sourcefire 3D System User Guide, Version 4.10 (Sourcefire, Inc.), available at scribd.com/document/96860221 (petitioner's EX-1004 in IPR2022-01535); also relied on in the predecessor IPR2018-01760 on the related '722 patent (US 9,413,722).
  • Date: Published/available well before the earliest priority date (April 17, 2015); qualifies as prior art under pre-AIA § 102(b) and post-AIA § 102(a)(1) as a printed publication.
  • Description: Describes Sourcefire's 3D Sensor / intrusion prevention system (IPS) operating inline at a network boundary (e.g., between EXTERNAL_NET and HOME_NET). It discloses rule-based packet filtering: intrusion rules with rule-header criteria (source/destination IP, ports, protocol), actions (e.g., alert, drop/block, allow), rule triggering when a packet's header/content satisfies the criteria, logging of triggered events, and rule-management interfaces. The IPR record expressly maps Sourcefire to: packet-filtering rules based on network-threat indicators (IP addresses, signatures); allowing/blocking packets; determining a first packet satisfies a rule; communicating information (alerts/logs) responsive to the determination; and reconfiguring rules.
  • § 102 assessment: The Board did not find literal anticipation; it found obviousness (§ 103) over Sourcefire alone or with Macaulay. For a pure § 102 anticipation case, Sourcefire's strongest targets are the method claims (1 and 8), the apparatus claim (15), and the medium claim (18) — but only if every element (including the user-driven reconfiguration of the operator from ALLOW to BLOCK and the interface display of allow/block status) is found in a single embodiment, which the IPR record suggests is the weak point for literal anticipation. Realistically, Sourcefire is best characterized as rendering the claims obvious, not strictly anticipating, under the IPR's own findings.

2.2 "Macaulay" (secondary IPR reference)

  • Citation: Referenced in IPR2022-01535 as a secondary reference (petitioner's exhibit list includes EX-1008 = U.S. Pat. No. 7,032,031 "Jungck," and the "Macaulay" reference appears in the prior IPR2018-01760 record as well). ⚠️ I could not verify the full Macaulay citation (number/title) in this session — flag for verification against the PTAB petition before relying on it.
  • Date: Pre-2015 (per its use in the 2018 IPR).
  • Description (as characterized in the IPR): Used to supply any elements not found in Sourcefire, principally aspects of automated or user-triggered rule/operator reconfiguration in network-threat detection.
  • § 102 assessment: Not a standalone anticipation reference in the IPR; relied on in combination under § 103. Its role is to cover the operator-reconfiguration/update elements of claims 1, 8, 15, 18.

3. Cited patent references on the face of the '062 patent (per Unified Patents listing)

The following are the references listed on the Unified Patents page for US-10609062-B1, with priority dates as shown. Descriptions are from the reference titles; I have not re-verified each document's full text.

Reference Priority date Title / description § 102 relevance
US 2002/0049899 A1 (Firenet Technologies) 1998-08-31 Network Attached Device with Dedicated Firewall Security — dedicated firewall appliance at a network boundary Potentially anticipates elements of claims 1, 15 (boundary packet filtering); lacks threat-indicator rule logging/UI reconfiguration
US 6,611,875 B1 (PMC-Sierra) 1998-12-30 Control System for High Speed Rule Processors — hardware rule processing for packet filters Relevant to claims 15, 18 (device/medium for rule-based filtering)
US 2003/0051026 A1 2001-01-18 Network Surveillance and Security System Relevant to claims 1, 8 (surveillance-based threat detection)
US 2003/0154297 A1 (Panasonic) 2002-02-07 Gateway Apparatus and Its Controlling Method Boundary gateway filtering; relevant to claim 1
US 2004/0172557 A1 (NEC) 2002-08-19 Attack Defending System and Attack Defending Method Threat/attack defense with rules; relevant to claims 1, 8
US 2008/0080493 A1 (Verizon) 2006-09-28 Secure and Reliable Policy Enforcement Policy enforcement on packets; relevant to claims 1, 15
US 2010/0211678 A1 (Verizon) 2000-11-27 External Processor for a Distributed Network Access System Distributed access control; relevant to claims 15, 18
US 2010/0199346 A1 2009-02-01 System and Method for Determining Semantic Equivalence Between Access Control Lists Rule/policy comparison; relevant to rule-management aspects of claim 8
US 2011/3017852 A1 (Masergy) 2011-10-09 Detecting Emergent Behavior in Communications Networks Network behavior/threat detection; relevant to claims 1, 8
US 2013/0104236 A1 (Albeado) 2011-10-13 Pervasive, Domain and Situational-aware, Adaptive, Automated, and Coordinated Analysis and Control of Enterprise-wide Computers, Networks, and Applications… Enterprise-wide threat analysis + automated mitigation; relevant to claims 1, 8, 15
US 2013/0246925 A1 (Magenta Security) 2009-03-24 System and Method for Managing Data and Policies Policy management; relevant to claim 8
US 2014/0337613 A1 (iBoss) 2013-05-07 Selectively Performing Man in the Middle Decryption Traffic inspection; tangential to claims 1, 15
US 2015/0135325 A1 2013-11-12 Packet Capture and Network Traffic Replay Packet capture/logging; relevant to claim 8 (log generation)
US 2015/0244734 A1 (Accenture) 2014-02-24 Automated Intelligence Graph Construction and Countermeasure Deployment Threat-intelligence-driven countermeasure deployment; relevant to claims 1, 8 (rule update/deployment)
US 2015/0256431 A1 2014-03-06 Selective Flow Inspection Based on Endpoint Behavior and Random Sampling Flow inspection; tangential to claims 1, 8
US 2015/0350229 A1 2014-05-28 Network Threat Detection and Mitigation Using a Domain Name Service and Network Transaction Data DNS-based threat detection/mitigation; relevant to claims 1, 8
US 2015/0341389 A1 (NTT) 2013-01-29 Log Analyzing Device, Information Processing Method, and Program Log analysis; relevant to claim 8 (log/flow-log processing)
US 8,042,167 B2 ⚠️ Title not verified in this session
US 7,954,143 B2 (AT&T) 2006-11-12 Methods, Network Services, and Computer Program Products for Dynamically Assigning Users to Firewall Policy Groups Firewall policy assignment; relevant to claims 1, 8
US 2017/0272469 A1 (VMware) 2016-03-14 Using Private Threat Intelligence in Public Cloud ⚠️ Not § 102 prior art — its priority date (Mar. 2016) is after the '062 patent's earliest priority date (Apr. 17, 2015); it is a later-cited reference, not anticipatory art.

Additional references from the parent '917 patent's 218-citation list that carry into this family's art (per the Google Patents search snippet): US 6,279,113 B1 (dynamic signature-inspection intrusion detection), US 6,098,172 A (firewall with proxy reflection), US 7,143,438 B1 (firewall with multiple-domain support), US 6,226,372 B1 (Securelogix cooperative telecom firewall/scanner), US 6,148,976 A (Cabletron), US 6,484,261 B1 (Cisco), and EP 1,006,701 A2 (adaptive re-ordering of data-packet filter rules). These are most relevant to the filtering-rule mechanics of claims 1, 15, 18.


4. Non-patent literature cited (per Justia page for 10609062)

  • Frahim et al., Cisco ASA: All-in-One Firewall, IPS, and VPN Adaptive Security Appliance — commercial firewall/IPS rule operation; relevant to claims 1, 15.
  • A. Feldmann et al., "Tradeoffs for Packet Classification," IEEE INFOCOM, 397–413 (2000) — packet classification; claims 15, 18.
  • A. Hari et al., "Detecting and Resolving Packet Filter Conflicts," IEEE INFOCOM, 1203–1212 (2000) — rule conflict handling; claim 8.
  • Acharya et al., "Optwall: A Hierarchical Traffic-Aware Firewall" (2007) — firewall rule optimization; claims 15, 18.
  • Anonymous, "The Distribution of Malicious Domains," DomainTools Report, 2016 Edition (Mar. 9, 2016) — ⚠️ published March 2016, i.e., after the Apr. 17, 2015 priority date; not § 102 prior art for the earliest claims.
  • Blake et al., "An Architecture for Differentiated Services," RFC 2475 (Dec. 1998) — QoS classification; tangential.
  • Benecke, "A Parallel Packet Screen for High Speed Networks" (1999) — parallel packet filtering; claims 15, 18.
  • Chen et al., "Research on the Anomaly Discovering Algorithm of the Packet Filtering Rule Sets" (2010) — rule-set anomaly detection; claim 8.
  • E. Al-Shaer et al., "Firewall Policy Advisor for Anomaly Discovery and Rule Editing" (2003) — firewall policy editing; relevant to the user-rule-reconfiguration element of claims 1, 8.
  • E. Fulp et al. (various, 2001–2005) — firewall policy optimization (tries, DAGs, ordered sets); claims 15, 18.
  • D. Comer, "Analysis of a Heuristic for Full Trie Minimization" (1981), D. Decasper et al., "Router Plugins" (2000), D. Eppstein et al., "Internet Packet Filter Management and Rectangle Geometry" (2001) — data-structure/classification background; claims 15, 18.

5. Bottom-line § 102 assessment per claim group

  • Claims 1, 8 (methods), 15 (apparatus), 18 (medium): The single most relevant reference is Sourcefire (EX-1004), which the PTAB found discloses essentially the entire rule-based packet-filtering/allow-block/logging framework — but the Board ultimately held the claims obvious (§ 103), not anticipated (§ 102), with Macaulay supplying the operator-reconfiguration/update elements for claims where Sourcefire alone was insufficient. A strict § 102 anticipation case against claims 1, 8, 15, or 18 would need a single reference disclosing the user-interface-driven flip of the rule operator from ALLOW to BLOCK and the subsequent blocking of a second packet — the element most likely to defeat literal anticipation by Sourcefire.
  • Most promising § 102 candidates from the face citations: US 2015/0244734 A1 (Accenture, countermeasure deployment) and US 2013/0104236 A1 (Albeado, coordinated automated mitigation) are the closest face-cited references to the "user-triggered rule reconfiguration to block" element; US 2015/0350229 A1 and US 2003/0051026 A1 are the closest to the threat-indicator-driven detection/logging elements of claims 1 and 8.

6. Caveats

  1. Exact front-page citation list: I verified the reference population from Unified Patents and Justia but could not pull the complete, authoritative "Patent Citations" section of the '062 patent itself before the search limit; the parent '917 patent carries 218 citations, so the '062 list is a subset I have only partially enumerated.
  2. "Macaulay" citation unverified: The full number/title of the Macaulay reference used in IPR2022-01535 was not confirmed in this session; verify against the PTAB petition (EX-1008+ exhibit list) before citing it.
  3. Post-priority-date references: US 2017/0272469 A1 (VMware) and the DomainTools 2016 report post-date the Apr. 17, 2015 priority date and cannot be § 102 prior art.
  4. § 102 vs. § 103: The only merits determination on record (IPR2022-01535 FWD) is obviousness, not anticipation; the § 102 assessments above are analytical inferences, not PTAB findings.

Generated 8/31/2026, 4:46:29 AM

Obviousness

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

✓ Generated

Obviousness Analysis — U.S. Patent 10,609,062 ("Rule-Based Network-Threat Detection")

Preliminary note on sources

The "Prior Art" section of the Google Patents page you supplied (the face-of-patent citation list) was truncated in the fetched text — the provided record jumps from the Detailed Description to the Classification fields, so the examiner's "References Cited" list is not reproduced there. I have therefore grounded this analysis in the prior-art record that is actually operative for this patent: the art relied upon in IPR2022-01535 (Keysight Technologies, Inc. v. Centripetal Networks, Inc.), the Final Written Decision of April 16, 2024 holding all challenged claims (1–20) unpatentable under 35 U.S.C. § 103, and the parallel PTAB/CAFC record for the near-identical sibling patent US 10,193,917 (CAFC No. 24-1406, decided April 23, 2026). Where I rely on claim text that was reconstructed from IPR exhibits rather than the granted claims PDF (per the earlier summary), I flag it.


1. Legal framework and the person of ordinary skill

Under Graham v. John Deere (383 U.S. 1 (1966)), obviousness turns on (i) the scope and content of the prior art, (ii) the differences between the prior art and the claims, (iii) the level of ordinary skill in the art, and (iv) secondary considerations. KSR Int'l Co. v. Teleflex Inc. (550 U.S. 398 (2007)) confirms that a combination of known elements is obvious when it yields a predictable result, when the prior art provides a design incentive or market pressure to combine, and when the combination is "the combination of familiar elements according to known methods" — it need not be the combination the patentee would have preferred.

Level of ordinary skill (as articulated in the Keysight IPR expert declaration, Ex. 1068, Staniford Decl.): a person with a bachelor's degree in computer science, computer/electrical engineering, or equivalent, and roughly 2–5 years of experience in network security, including packet filtering, intrusion detection/prevention systems (IDS/IPS), network protocols, and threat intelligence. The same person would be familiar with Snort-style rule engines, since Sourcefire's IPS is built on Snort.


2. The claims in issue

Independent claims 1 (method), 8 (method), 15 (apparatus), and 18 (computer-readable medium) (reconstructed from IPR exhibits; moderate confidence on exact wording). The common inventive skeleton:

  • A packet-filtering device receives packet-filtering rules based on network-threat indicators (NTIs);
  • a first packet satisfying a rule is allowed to proceed under the rule's operator, and data identifying the NTIs and the allow outcome is communicated and displayed in a user interface;
  • a user-initiated update reconfigures the operator to block; a subsequently received matching packet is blocked, and that outcome is also communicated/displayed.

Dependent claims add: packet-log entries identifying the rule/outcome (claims 2–4); a packet-flow log consolidating entries (claims 5–7, 13–14); an ordering/score of network threats derived from the flow log (claims 6–10, 16–19, 20), with scoring based on packet-hit counts, timing, destination, provider identity/number of providers, threat type, geographic information, anonymous proxies, and actors.


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

  • Status as prior art: a commercial user guide for the Sourcefire 3D System (the Snort-based IPS). Its printed-publication status was litigated and affirmed by the Federal Circuit in Centripetal Networks, Inc. v. Cisco Systems, Inc., Nos. 20-1635, 20-2057 (Fed. Cir. 2021), in the context of the terminally-disclaimed family patent US 9,413,722. It long predates the April 17, 2015 priority date.
  • What it discloses (as found by the Board in IPR2018-01760 and applied in IPR2022-01535):
    • The Sourcefire 3D Sensor is a "packet-filtering device" that inspects traffic at a network boundary.
    • Intrusion rules are the claimed "packet-filtering rules": each rule has a rule header containing criteria — source/destination IP addresses, source/destination ports, protocol — and a rule-options section with keywords/arguments. The Board construed "network-threat indicator" as "an indicator that represents the identity of a resource associated with a network threat" and found Sourcefire teaches rules that identify packets "corresponding to, for example, specific source IP addresses" — i.e., IP addresses used as NTIs (Board Decision, 2020 WL 2549613, at *9).
    • Operators/actions: rules trigger when packet data "matches all the conditions specified in a rule," and each rule specifies an action — "alert" (which allows the packet to continue while logging it) or "drop"/"deny" (which blocks it) — the claimed ALLOW/BLOCK operators.
    • Log entries: a triggered rule generates an "intrusion event" — "a record of the date, time, the type of exploit, and contextual information about the source of the attack and its target," including the rule that triggered and the action taken. This maps to the claimed "log entry comprising information from the packet-filtering rule that identifies the network-threat indicators and indicating whether the device prevented or allowed."
    • User interface: the Defense Center console displays intrusion events with the triggering rule, source/destination, and action, and permits an administrator to edit a rule's state/action (e.g., from "alert" to "drop") and re-deploy it, after which the updated rule governs subsequent packets. This maps to the claimed interface display and the user-driven reconfiguration of the operator from allow to block.

Collateral estoppel: In IPR2022-01535, Keysight argued — and the Board agreed in instituting — that the Board's findings on Sourcefire in the '722 IPR (IPR2018-01760, Paper 41), affirmed by the Federal Circuit, collaterally estops Centripetal from relitigating Sourcefire's teachings, since the '062 claims are not materially different from the '722 claims in view of that reference.


4. Sourcefire alone renders independent claims obvious (the adjudicated ground)

The FWD held all challenged claims 1–20 unpatentable over Sourcefire alone. The element-by-element theory:

Claimed limitation (claim 1) Sourcefire disclosure
Packet-filtering device receives packet-filtering rules based on network-threat indicators 3D Sensor receives/deploys intrusion rules; rule headers use IP addresses/ports as NTIs
Receives a first packet satisfying the rule; applies operator to allow it Rule triggers on header criteria; "alert" action logs and allows the packet
Communicates information identifying the NTIs and that the packet was allowed Intrusion-event record and Defense Center console display identifying rule/indicators and action
Interface displays the allow outcome Console event views; event details show action taken
Receives a user update to the rule; modifies operator to block Rule editor changes state from "alert" to "drop" and re-deploys
Blocks a subsequently received matching packet; communicates/displays block Updated rule drops matching traffic; subsequent events record the drop

The one feature Centripetal fought hardest — the "explicit progression" of allow-first, then user-flips-to-block — was found by the Board to be exactly what Sourcefire's rule-state editing teaches: Sourcefire explicitly contemplates running rules in "alert" mode to observe events and then reconfiguring them to "drop." The Federal Circuit, in the parallel '917 appeal (No. 24-1406), rejected the identical argument, holding that Sourcefire's "responsive to" relationship — applying the operator and communicating information because the rule was triggered — satisfies the claimed causal chain, and that the PTAB's findings were supported by substantial evidence. There is no limitation in the claims requiring a different reference to supply the block-after-allow progression.

The "Sourcefire rules need content matching" argument fails under § 103. Centripetal argued that every identified Sourcefire rule requires matching more than an IP address (e.g., payload keywords), so no rule is "based on" an NTI. The Board and Federal Circuit rejected this: (i) Sourcefire's own rule headers contain "arguments that dictate when the rule triggers," so an IP-address criterion alone can trigger a rule; (ii) even if rules also inspect other data, "based on" does not preclude additional criteria; and (iii) this is an obviousness, not anticipation, inquiry — Sourcefire teaches a flexible rule engine that can allow or block based on known-bad IP addresses (a point reinforced by exhibits in the IPR, e.g., Jungck, US 7,032,031, and the Spafford/Eichin worm papers, showing the long-known practice of blocking traffic based on threat indicators).


5. Secondary references for the dependent-claim limitations

Because the FWD already found every claim obvious over Sourcefire alone, the combinations below are the alternative/backstop grounds that the parallel proceedings developed for the dependent limitations — and they were the grounds the PTAB and CAFC used for the nearly identical '917 claims:

(a) Sourcefire + Macaulay (US 2015/0207809 A1, "Macaulay")

Used in the sibling IPRs (e.g., IPR2021-01149, Palo Alto Networks v. Centripetal, on US 10,567,413; and the '917 IPR) for the score/ordering and flow-log-update claims (the '062 analogs of claims 6–10/16–19).

  • What Macaulay adds: a reputation/risk-scoring engine that computes a score for each "traffic attribute" (IP address, ASN, domain — i.e., network-threat indicators) based on (i) the number of cyber-threat-intelligence sources that flagged the attribute, (ii) the identity/origin of those sources (external vs. internal; law-enforcement seed data weighted highest), (iii) destination information, and (iv) threat type, geographic info, anonymous proxies, actors. Macaulay also teaches updating scores over time based on the number of logged events pertaining to the attribute.
  • Motivation to combine (articulated in the Palo Alto/Keysight petitions and adopted in the PTAB/CAFC analyses):
    • Same field: both are network-security/threat-intelligence systems; Macaulay is expressly directed at aggregating cyber-threat intelligence to score network threats, and Sourcefire is the canonical IPS that consumes such intelligence.
    • Complementary deficiencies: Sourcefire's "priority" value is a static, manually assigned field; Macaulay supplies a dynamic, multi-source consensus score. A POSITA seeking to help administrators triage the flood of intrusion events would replace or augment Sourcefire's static priority with Macaulay's computed reputation score — a "straightforward and predictable modification" of Sourcefire's existing UI (Petition, IPR2021-01149).
    • Explicit teaching: Macaulay discloses scoring based on "the number of cyber threat intelligence sources that have revealed the particular instance of the particular traffic attribute as a potential threat" — the exact limitation (scoring based on number of network-threat-intelligence providers) in the '062 dependent claims — and updating scores based on "the number of logged events pertaining to the particular instance," matching the claimed flow-log-driven updates.
    • Reasonable expectation of success: integrating a scoring module into Sourcefire's console is a routine software-engineering task; the CAFC (April 23, 2026) found the PTAB's obviousness determinations over Sourcefire alone and Sourcefire+Macaulay for the '917 claims supported by substantial evidence.

(b) Sourcefire + Macaulay + Maestas (US 9,342,691 B1, "Maestas")

For the dependent claims requiring scoring based on geographic information (and other categorical factors).

  • What Maestas adds: an "aggregate risk score" for network connections that incorporates, among other factors, the risk associated with IP addresses originating from certain geographic areas.
  • Motivation to combine: once a POSITA has adopted Macaulay's multi-factor scoring, adding geographic origin — an express risk factor in Maestas, and a factor the '062 specification itself lists (ITAR/OFAC countries) — is a predictable refinement of the scoring algorithm, not a new inventive step. The combination was the explicit Ground 2 in IPR2021-01149 (claims 3, 13, 18), characterized as "a predictable design choice with a high expectation of success."

(c) Jungck (US 7,032,031 B2) and the historical worm/intelligence literature

Jungck (Ex. 1008 in IPR2022-01535) and the Leiner "Brief History of the Internet," Spafford's Internet-Worm analysis, and Eichin & Rochlis (Ex. 1007, 1009, 1010) were cited in the IPR to establish the background knowledge that (i) network devices at boundaries filter packets based on addresses/ports, and (ii) blocking traffic associated with known malicious sources was decades-old practice by 2015. These references primarily rebut any argument that Sourcefire's teachings were not understood as NTI-based filtering and that the allow→user-update→block workflow was unconventional.


6. The "why combine" analysis, consolidated

A POSITA as of April 17, 2015, would have had multiple, mutually reinforcing reasons to arrive at the claimed invention:

  1. Known problem: IDS/IPS consoles generated voluminous alerts; administrators needed to (i) observe events in a "monitor/allow" mode, (ii) triage them, and (iii) convert high-confidence detections into blocking rules. Sourcefire's own user guide documents this exact workflow (alert → review events → change rule state to drop → redeploy), which is the entire claimed progression.
  2. Known solution components: every element — rule-based packet filtering on IP/port criteria, allow/block operators, event logging, console display, rule-state editing — was individually known and present in Sourcefire. The combination is "the combination of familiar elements according to known methods" yielding a predictable result (KSR).
  3. Design incentive to improve triage: the static-priority limitation of Sourcefire's event triage created an express incentive to adopt Macaulay's dynamic reputation scoring; the '062 dependent claims' scoring features are precisely the union of Macaulay's factors (provider count/identity, destination, threat type, geography, proxy, actor) applied to Sourcefire's logged events.
  4. Prior Board/CAFC findings (collateral estoppel and persuasion): the same Sourcefire teachings were already held to render the materially identical '722 claims obvious, affirmed on appeal; the same Sourcefire (alone and with Macaulay) was held to render the near-identical '917 claims obvious, affirmed in part and reversed in part in favor of obviousness by the Federal Circuit on April 23, 2026.

7. Secondary considerations

The Board considered and rejected Centripetal's objective-indicia evidence in the '722 IPR (and the CAFC affirmed): the purported industry praise for Centripetal's RuleGATE product was not shown to be coextensive with the claimed subject matter, and the expert statements were conclusory (Board Decision, 2020 WL 2549613, at *17–*20). No nexus was established. That reasoning carries directly to the '062 claims, which are drawn to the same subject matter.


8. Procedural status and caveats

  • IPR2022-01535: Petition filed Sept. 13, 2022; institution April 18, 2023; Final Written Decision April 16, 2024 — all challenged claims 1–20 found unpatentable under § 103 over Sourcefire alone (Board: Lee, McNamara, Pinkerton).
  • CAFC appeal 24-1929: voluntarily dismissed January 14, 2025 under Rule 42(b) — no merits reversal of the FWD. Because the FWD was not overturned, the claims stand cancelled unless a certificate of cancellation has not yet issued; I could not confirm from the available sources whether the USPTO certificate has formally issued — verify against USPTO Patent Center/PTAB docket before relying on the patent's current status.
  • Related April 23, 2026 CAFC decision (No. 24-1406): on the sibling '917 patent (10,193,917), the Federal Circuit affirmed obviousness of claims 1–3, 5–13, 15–20 over Sourcefire alone or Sourcefire+Macaulay and reversed the PTAB's only non-obviousness findings (claims 4, 14), holding all claims unpatentable. Given the '062 and '917 claims are materially the same, this decision is highly persuasive — if not preclusive — authority that the '062 claims are obvious over Sourcefire (and Sourcefire+Macaulay).
  • ⚠️ Data discrepancy (unchanged from the prior summary): Unified Patents lists priority 2015-04-16/filing 2019-12-05/grant 2020-03-30; Google Patents lists 2015-04-17/2019-12-06/2020-03-31. This does not affect the obviousness analysis because Sourcefire (published ~2010–2011) and Macaulay (filed 2014, published 2015) both predate either priority date, and Maestas (US 9,342,691, issued 2016) and Jungck (US 7,032,031, issued 2006) are prior art on the operative 2015 filing date under pre-AIA § 102(a)/(b)/§ 103.

Conclusion

Claims 1–20 of US 10,609,062 are obvious under 35 U.S.C. § 103. The strongest, already-adjudicated ground is Sourcefire 3D System User Guide v4.10 alone, which discloses every element of the independent claims — NTI-based packet-filtering rules, allow/block operators, event logging, console display, and user-driven rule reconfiguration from allow to block — a conclusion the PTAB reached in IPR2022-01535 and that the Federal Circuit reached for the identical subject matter in the sibling '917 patent (No. 24-1406, April 23, 2026). For the dependent scoring/flow-log claims, the combinations Sourcefire + Macaulay (US 2015/0207809 A1) and Sourcefire + Macaulay + Maestas (US 9,342,691 B1) render those limitations obvious: a POSITA would have been motivated to replace Sourcefire's static priority with Macaulay's dynamic, multi-source reputation scoring (and Maestas's geographic risk factor) to improve alert triage — a predictable combination of known elements in the same field, with a reasonable expectation of success and no weighty secondary considerations to rebut the case.

Generated 8/31/2026, 4:46:52 AM

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 Keysight Technologies, 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 10609062.