US 11516241

I'll verify the current status and any litigation/docket activity for this specific patent before summarizing.

Let me check the claim set and any PTAB/litigation activity specific to this patent number.

Let me confirm the claim set and check dockets asserting this specific patent.

US Patent 11,516,241 — Summary

Important caveat first: the authoritative full text I was given for US 11,516,241 (fetched from https://patents.google.com/patent/US11516241/en) includes the abstract, summary, description and figure list, but the claims section was not included in that fetch. My claim overviews below are therefore inferred from the specification, the FIG. 7 method, the summary, and the identically-abstracted sibling in the same continuation chain (US 10,609,062). I flag every point where I cannot verify verbatim claim language.

Bibliographic record (per the authoritative text + search confirmation)

Continuation chain (from the patent's own cross-reference section): 17/713,570 ← 17/232,291 (Apr 16, 2021) ← 17/001,164 (US 11,012,459) ← 16/813,220 (US 10,757,126) ← 16/706,388 (US 10,609,062) ← 16/217,720 (US 10,567,413) ← 15/827,477 (US 10,193,917) ← 14/690,302 (US 9,866,576, filed Apr 17, 2015). So the effective priority is the Apr. 17, 2015 filing of 14/690,302.

Note: the search noise in my queries surfaced several different Centripetal families — e.g., "Rule-based network-threat detection for encrypted communications" (US 9,917,856 / US 11,496,500 / US 11,824,879, priority Dec. 23, 2015, different inventors) and US 11,824,808/11,563,758. Those are different patents and should not be merged with US 11,516,241.

Abstract (as issued)

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.

Plain-language overview of the disclosure

The patent addresses "rule-based network-threat detection" at a network boundary. A rule provider (128) ingests network-threat-intelligence reports from multiple providers (130/132/134) containing network-threat indicators (IP addresses, ports, FQDNs, URLs, URIs) and converts them into packet-filtering rules. Each rule has: (i) one or more criteria corresponding to threat indicators, (ii) an operator — ALLOW or BLOCK, and (iii) metadata distinct from the criteria (a "Threat ID") tying the rule back to the indicator(s), threat(s), intel report(s), and provider(s).

A packet-filtering device (144/146/148) applies those rules to traffic crossing the boundary. Hits are logged at two levels — a per-packet packet log and a consolidated flow log (time range, common Threat ID, counts of allowed/blocked packets) — with the device using work-conserving scheduling to keep latency low. The device then drives an administrative dashboard ("interface 600") showing graphical activity depictions, a threat listing with per-threat scores/ordering (scoring factors include hit counts, recency, whether the target was internal or external, and how many intel providers reported the threat), and an inline "block option" (608). Invoking block option 608 opens a further interface (610) offering scoped block options (block for the whole network, for particular hosts, or internal-only/external-only variants), each with a rule preview; confirming (modify option 620) causes the user device to instruct the packet-filtering device to reconfigure the operator of the associated rule to BLOCK. Rule provider 128 also feeds back aggregate per-device statistics and can push updates that flip operators (e.g., Rule TI001 → BLOCK).

Independent claims — plain-language overview (inferred; not verbatim)

The claims section was absent from the source text, so I cannot give verbatim independent claims or the exact claim count for US 11,516,241. Based on the FIG. 7 flow, the summary paragraph, and the parallel parent US 10,609,062 (identical abstract, 20 claims), the independent claims are most likely:

1. Method claim — receive, by a packet-filtering device, packet-filtering rules that identify packets corresponding to network-threat indicators; receive a packet; determine the packet corresponds to criteria specified by one of the rules, the criteria corresponding to one or more network-threat indicators; apply the rule's operator (allow toward destination / prevent from continuing toward destination); generate a log entry comprising information from the rule that is distinct from the criteria and identifies the network-threat indicator(s) and indicating allow-vs-block; generate data indicating allow-vs-block; communicate that data to a user device; and cause an interface to indicate allow-vs-block. (An embodiment adds the element that the interface's element, when invoked, causes the user device to instruct the packet-filtering device to reconfigure the operator to block future matching packets — FIG. 6A–6C, steps 24–26.)
2. System / packet-filtering-device claim — a device with memory (rules, logs) and processor(s)/communication interface(s) configured to perform the same sequence, per FIGS. 2A–2B and FIG. 7.
3. Non-transitory computer-readable medium claim — instructions that when executed cause the above steps. (The specification expressly contemplates "a method, system, apparatus, or one or more computer-readable media storing computer-executable instructions," which typically corresponds to three independent claim types.)

Likely dependent-claim subject matter (again inferred, from the described embodiments): the two-tier packet-log/flow-log consolidation with time range and allowed/blocked counts; work-conserving scheduling; a local DNS cache used to resolve domain names/URIs/URLs in packets to addresses in the rule criteria; threat scoring and ordering in the listing (e.g., scoring based on number of intel providers reporting the threat, hit recency); operator status display; and the specific/expanded block options 612/614/616/618 with rule-preview listing 624.

I do not have high confidence in the above claim breakdown — treat it as a specification-based reconstruction, not a reproduction of the patent's claims.

Docket check (USPTO / PTAB and CAFC, 2026)

• No CAFC 2026 docket entry naming US 11,516,241 was found. The April 29, 2026 nonprecedential Federal Circuit opinion in the Centripetal/Cisco dispute is Appeal No. 24-2097, and it concerns the '193, '806 and '176 patents — different patent numbers (see https://www.cafc.uscourts.gov/opinions-orders/24-2097.OPINION.4-29-2026_2684565.pdf). Law360's April 29, 2026 report ("Cisco Keeps Win In Cybersecurity Patent Fight At Fed. Circ.") described the same "trio" of patents.
• The other 2026 activity surfaced is the continued US 9,917,856 matter (Palo Alto Networks v. Centripetal, IPR2022-00182), including Law360's June 12, 2026 item that the PTAB again invalidated a Centripetal patent after the Federal Circuit's remand in Appeal No. 23-2027 (Oct. 22, 2025). Again, not US 11,516,241.
• District-court/ITC records I found assert other Centripetal patents (e.g., '917, '370, '526, '062/'722, '856, '176, '193, '806). I could not confirm from authoritative sources that US 11,516,241 has itself been asserted in a specific 2026 docket, even though Google Patents flags the family as litigated.
• USPTO-side: I found no IPR/FWD identified by the specific number 11,516,241 in the search results returned.

Explicit uncertainties

1. Claim text and claim count for US 11,516,241 were not in the authoritative document I was given — my independent-claim overview is inferential.
2. Litigation posture of this specific number (as opposed to its family/siblings) is unverified; the 2026 CAFC activity I found is for other patents ('193, '806, '176, '856).
3. The Google Patents "priority date 2015-04-17" and "anticipated expiration 2035-04-17" are Google's own assumptions/annotations, and Google states legal status assumptions are not legal conclusions.
4. I have not verified the PTAB/inventor/assignee details against a second independent official source (e.g., USPTO PatentCenter or the printed patent PDF) for this exact number.

I'll research litigation involving US Patent 11,516,241. Let me run several targeted searches.

Let me dig deeper into specific litigation and the patent number itself.

Summary answer

I could not confirm any litigation in which U.S. Patent No. 11,516,241 ("the '241 patent") is itself expressly identified as an asserted patent — in a complaint, ITC complaint, IPR petition, or court opinion. No case name, docket number, or filing date tied specifically to the '241 patent appeared in the sources I was able to search (Unified Patents litigation portal, CAFC opinions/orders, PACER-derived dockets, CourtListener, PTAB/PTABTS filings, and industry press).

What I can document is that the '241 patent sits in a patent family that has been the subject of extensive, well-documented litigation by its owner, Centripetal Networks, LLC (originally Centripetal Networks, Inc.). The '241 patent is a continuation of U.S. Pat. No. 10,609,062 ("the '062 patent"), which was asserted. That is likely why the family-to-litigation mapping surfaces for the '241 patent even though the '241 patent itself does not appear to have been pleaded.

---

What the '241 patent is, and why family litigation matters

• US 11,516,241 B2, "Rule-Based Network-Threat Detection," inventor list including David K. Ahn, Keith A. George, Peter P. Geremia, Pierre Mallett III, Sean Moore, Robert T. Perry, Jonathan R. Rogers; assignee Centripetal Networks, LLC.
• Application US 17/713,570, filed 2022-04-05; granted 2022-11-29; priority date 2015-04-17; anticipated expiration 2035-04-17.
• Continuity chain (from the patent's own cross-reference): 17/713,570 ← 17/232,291 ← 17/001,164 (now 11,012,459) ← 16/813,220 (now 10,757,126) ← 16/706,388 (now 10,609,062) ← 16/217,720 (now 10,567,413) ← 15/827,477 (now 10,193,917) ← 14/690,302 (now 9,866,576).
• Centripetal's own legal-notice page lists 11,516,241 among its U.S. patents (patent marking), which confirms ownership but is not evidence of assertion in a suit.

Because the '241 patent issued Nov. 29, 2022, it post-dates most of the early Centripetal campaigns (2017–2020) and the initial complaints in the 2022 cases (which pleaded the '917 and '062 patents). A later-filed complaint or amended complaint could have added it — but I found no record of such an addition.

---

Litigation involving the same family / same owner (context, not '241-specific)

These are the cases in which Centripetal has asserted sibling patents (same specification/family), which is the relevant enforcement history. None of the following, as far as the sources show, names the '241 patent as an asserted patent.

Related PTAB proceedings (challenges to family patents, not to the '241 patent as far as I found): Cisco IPRs against the '176 patent (IPR2018-01654/-01655) and multiple others; Palo Alto Networks IPR2022-00182 ('856); Keysight IPRs against the '917 patent (Fed. Cir. 2026 decisions at Nos. 24-1406 and the '917 obviousness appeal reported Apr. 23, 2026). The Apr. 23, 2026 CAFC decision in Centripetal Networks, LLC v. Keysight Technologies, Inc. concerned U.S. Pat. No. 10,193,917 ("Rule-Based Network-Threat Detection"), a parent of the '241 patent — not the '241 patent itself.

---

Caveats and verification steps

• No case found naming the '241 patent. If your question requires a negative/positive finding specifically for 11,516,241, the operative sources to confirm would be: (1) the ITC's Electronic Document Information System (EDIS) and docket for 337-TA-1314 and successors; (2) PACER dockets in 2:22-cv-00002 (E.D. Va.) and any amended complaints; (3) the Unified Patents litigation portal search filtered to patent number 11516241; and (4) Darts-IP family 55863202 (the "family has litigation" flag on the patent page).
• Distinguish family-level from patent-level litigation. The Google Patents page for US 11,516,241 carries a "Family has litigation" flag tied to Darts-IP family 55863202. That flag denotes litigation somewhere in the family; it does not establish that claim(s) of the '241 patent were asserted. My searches did not surface the '241 patent number in any complaint or opinion.
• I was unable to complete an exhaustive live query of the Unified Patents portal and PACER within this session, so treat the above as "no litigation found for the '241 patent specifically," rather than an absolute negative. I did not find (and am not aware of) a suit asserting the '241 patent, and I will not represent otherwise.

If you want, I can next draft a short verification checklist (specific docket entries and search strings) you can run against EDIS, PACER, and Unified Patents to close out the negative.

I'll start by verifying the structured data against live web sources, since the ODP block asserts no AIA proceedings but the prompt asks me to flag anything search surfaces.

The first searches surfaced the '856 family, not the '241 patent. Let me target the '241 patent's own family directly.

The family history is highly relevant (the '241 patent is a direct descendant of the '413/'917 family), but none of these results name the '241 patent itself. Let me search harder for any proceeding naming US 11,516,241 specifically.

Proceedings overview

Zero AIA trial proceedings are on file against US 11,516,241. The structured ODP block returned no IPR, PGR, or CBM for this patent, and my independent web searches (Google Patents, PTAB/PTACTS docket documents, CourtListener, Unified Patents' patent portal, and press coverage) surfaced no petition, institution decision, or FWD naming the '241 patent — only proceedings on its sibling and parent patents. Breakdown: 0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution denied. The bottom-line defensive posture for a defendant: no claim of the '241 has ever been canceled, and no petitioner has § 315(e)(2) estoppel against it — but the '241 is the last un-felled link in a continuation chain whose other members ('917, '413, '062, '126, '028) have all had claims held unpatentable over the same Sourcefire prior art, so a defendant walks in with a clean IPR runway and a ready-made invalidity template.

Confidence note: I could not independently confirm the '241's own claim count or claim text from the fetched patent text (the claims themselves were not in the fetch), and I cannot rule out an unindexed or very recent filing. Everything below labeled "family/sibling" is a proceeding on a different patent in the same family, not on the '241. Do not cite any of them as a proceeding on US 11,516,241.

---

No proceedings to report on US 11,516,241

There is no {PROCEEDING_NUMBER} — {Petitioner} v. {Patent Owner} entry to write for this patent. I am not filling that section with invented or borrowed numbers.

---

Family-level PTAB landscape (context only — NOT proceedings on the '241)

The '241 issued 2022-11-29 from application 17/713,570, filed 2022-04-05. Its 35 U.S.C. § 120 chain runs straight back through US 11,012,459 → US 10,757,126 ('126) → US 10,609,062 ('062) → US 10,567,413 ('413) → US 10,193,917 ('917) → US 9,866,576 ('576), filed 2015-04-17 (patent). The '241 shares that specification and is listed on Centripetal's own product-patent notice. Those siblings have been adjudicated:

IPR2021-01149 — Palo Alto Networks, Inc. v. Centripetal Networks, Inc. (U.S. Pat. No. 10,567,413)

• Type: Inter Partes Review
• Status: Final Written Decision — all challenged claims (1–20) unpatentable under § 103
• FWD: 2023-02-17
• Grounds / art: § 103 over the Sourcefire 3D System User Guide, alone or in combination with U.S. Pub. 2015/0207809 (Macaulay)
• Appeal: Fed. Cir. No. 23-1785 (Centripetal Networks, LLC v. Palo Alto Networks, Inc.) — AFFIRMED 2024-10-31 (opinion; Fed Circuit Blog summary). The court rejected Centripetal's "at a boundary" construction because the '413 specification's own figures show the filtering device downstream of tap/network devices.
• Defensive value: The '413 is the direct ancestor of the '241. Its invalidation over Sourcefire is the closest thing to a roadmap for attacking the '241's claims.

IPR2021-01147 & IPR2021-01148 — Palo Alto Networks, Inc. v. Centripetal Networks, Inc. (U.S. Pat. Nos. 10,542,028 and 10,757,126)

• Type: Inter Partes Review (consolidated on appeal)
• Status: All challenged claims unpatentable under § 103
• FWDs: 2023-02-09 (both)
• Grounds / art: § 103 over Sourcefire, alone or with Macaulay
• Appeal: Fed. Cir. Nos. 23-1654, 23-1655 — AFFIRMED 2024-10-31 (nonprecedential); "responsive to" construed as requiring cause-and-effect, not an exclusive trigger (VitalLaw; IPWatchdog).
• Defensive value: The '126 is the immediate grandparent of the '241 in the same § 120 chain — same specification, same claimed mechanics (packet-filtering rules, log entries, score-ordered listing).

IPR2022-01097 — Keysight Technologies, Inc. v. Centripetal Networks, Inc. (U.S. Pat. No. 10,193,917)

• Type: Inter Partes Review
• Status: FWD 2023-12-15 — claims 1–3, 5–13, and 15–20 unpatentable under § 103 (Sourcefire alone; Sourcefire + Macaulay for claims 6–10, 16–19); claims 4 and 14 held not proven obvious
• Appeal: Centripetal Networks, LLC v. Keysight Technologies, Inc. — Fed. Cir. affirmed in part, reversed in part (2026-04-21), holding claims 4 and 14 unpatentable as well (IPWatchdog; Legal Era). The docket number was not surfaced; the court rejected Centripetal's APA/due-process challenge to the Board's sua sponte construction of "packet flow entry."
• Defensive value: The '917 is the '241's direct parent. Post-appeal, all 20 claims of the '917 are unpatentable. If a demand letter asserting the '241 tracks '917-style claim language, the Sourcefire/Macaulay combination has already been judicially blessed twice.

IPR2022-01535 — (U.S. Pat. No. 10,609,062)

• Petition filed 2022-09-13 (Paper 1), per an exhibit list in the PTAB record. Status not confirmed from available sources; the '062 is the next link in the '241's chain. Do not treat as validated.

Other family/portfolio activity (shorter form)

• IPR2021-01150 (Palo Alto v. Centripetal, U.S. Pat. No. 10,530,903) — instituted; oral hearing held 2022-10-26.
• IPR2021-01151, -01154, -01155 — institution denied (per Centripetal's own footnote in Centripetal v. Keysight, E.D. Va. 2:22-cv-00002).
• IPR2022-00182 (Palo Alto v. Centripetal, U.S. Pat. No. 9,917,856) — FWD 2023-05-23 holding claims 1, 24, 25 unpatentable; Fed. Cir. No. 23-2027 vacated and remanded 2025-10-22 for failure to adequately weigh copying (CAFC opinion PDF; Oliff summary).
• IPR2018-01654 (Cisco v. Centripetal) — institution denied 2019-05-06.
• ITC Inv. No. 337-TA-1314 (Centripetal v. Keysight) — ALJ found no § 337 violation; claims 11 and 20 of the '917 and claims 1, 3, 11, 13, 16 of the '526 invalid.
• EPO: EP 3 395 043 B1 (the '856-family sibling disclosing the same rule-based encrypted-threat detection) was revoked for added subject matter, and the appeal was dismissed in T 0405/24 (2025-09-30) — every auxiliary request failed Art. 123(2) EPC.

---

Strategic summary

Claim status. No claim of US 11,516,241 is canceled, sustained, or untested-and-adjudicated at the PTAB — the entire claim set is untested. By contrast, the direct § 120 ancestors are effectively dead: all of the '917 (claims 1–20, post-CAFC), all of the '413 (claims 1–20, affirmed), and the '028 and '126 claim sets were held unpatentable. The '241 is a late-issued continuation (granted 2022-11-29) that sits at the end of a chain whose earlier links have been invalidated over Sourcefire, "alone or in combination."

Estoppel landscape. Because no IPR on the '241 ever reached an FWD, no petitioner or privy carries any § 315(e)(2) estoppel as to the '241's claims. Grounds that would be statutorily barred against a sibling patent are free for use against the '241. The flip side: prior FWDs on the '917/'413/'028/'126 do not bind the Board on the '241, and a defendant gets no free collateral-estoppel win. Two practical gates to check immediately: (i) § 315(b) — if your client was served with a complaint alleging infringement of the '241 more than one year before filing, an IPR is time-barred absent joinder; (ii) § 325(d) — if Sourcefire was before the examiner during the '241's (short, continuation) prosecution, expect the Board to weigh discretionary denial, so frame the petition around art or claim limitations not previously evaluated.

Pattern signals. The petitioner set here is a coordinated vendor bloc — Palo Alto Networks, Cisco, and Keysight — that filed overlapping petitions across the portfolio (Palo Alto at IPR2021-01147/48/49/50/51/54/55 and IPR2022-00182; Keysight at IPR2022-01097 and IPR2022-01535, with joinder motions at IPR2022-01151), while Centripetal litigated appeals aggressively on both validity and PTAB-procedure grounds (recusal/vacatur, APA, § 311(b) scope). I found no defensive aggregator (e.g., Unified Patents) as petitioner; Unified's portal appears only as a document mirror for family proceedings. There is also no CBM or PGR vehicle left: the '241's nine-month PGR window closed 2023-08-29, and CBM is unavailable to new petitions.

---

Recommended next steps

1. Confirm the negative directly. Pull the '241's complete PTAB docket at PTAB/PTACTS E2E (https://ptacts.uspto.gov) and re-run the ODP AIA-trial endpoint before relying on "no proceedings" — the ODP ingest can lag recently filed petitions by weeks. I could not rule out an unindexed 2025–2026 filing.
2. If you are a defendant facing a '241 assertion and no IPR is on file, move fast. File within one year of service of the complaint (§ 315(b)). Reuse the winning family template: Sourcefire 3D System User Guide alone, and Sourcefire + Macaulay (U.S. Pub. 2015/0207809) — the exact combination upheld in IPR2021-01149 (aff'd No. 23-1785) and IPR2021-01147/48 (aff'd Nos. 23-1654/55), plus the '917/Keysight outcome. Map your § 103 grounds onto the '241's actual claim text, and pre-empt a § 325(d) argument by asking the examiner's file history what art was considered.
3. If you are being asserted on a '917- or '413-style claim set, attack at the threshold. Those claims are canceled: '917 claims 1–20 (FWD 2023-12-15 as modified by the 2026-04-21 Fed. Cir. decision) and '413 claims 1–20 (FWD 2023-02-17, aff'd). Any infringement chart that cites a cancelled claim is a sanction exposure.
4. Watch two live appellate threads. Fed. Cir. No. 23-2027 (Centripetal v. Palo Alto Networks, '856) is on remand to the PTAB for reconsideration of objective indicia after vacatur — if Centripetal can convert evidence of copying into a non-obviousness win there, it may try the same objective-indicia play against the '241. Any further petition activity on the '241, or in the E.D. Va. cases (2:21-cv-00137, 2:22-cv-00002), would change the analysis above.
5. Blunt statement for a client memo: The '241 patent has never been to the PTAB. That is a signal about timing, not strength — every other patent in its continuation chain that was asserted in litigation drew IPRs, and the asserted ones lost. The absence of an '241 IPR means the invalidity case is unbuilt, not that it is weak.

I'll research the assignment record for US 11,516,241. Let me run targeted searches across USPTO Assignment Center, Google Patents legal events, and related sources.

Let me dig into the specific assignment records and reel/frame numbers.

Let me search for specific reel/frame numbers and correspondent details.

Assignment & Ownership Reconstruction — US Patent 11,516,241 ("Rule-Based Network-Threat Detection")

Data provenance note (read first). I retrieved the two recorded conveyances for this patent and their attributes from Google Patents legal events (which mirror USPTO assignment data) and from corroborating PTAB/litigation exhibits. I was unable to retrieve the specific reel/frame numbers or the verbatim "correspondent" field for the two records below — those fields are behind the USPTO Assignment Center UI and did not surface verbatim in the sources I could reach in this session. I am therefore not inventing reel/frame values. Where I state a correspondent, I flag it as corroborated-but-not-verbatim. Verify at: https://assignmentcenter.uspto.gov/ (search "11516241") or https://assignment.uspto.gov/patent/index.html.

---

Inventors

Seven named inventors (all assigned their rights to Centripetal Networks, Inc. per the 2022-04-05 recording, assignors listed as MALLETT, PIERRE III; GEORGE, KEITH A.; PERRY, ROBERT T.; MOORE, SEAN; GEREMIA, Peter P.; AHN, DAVID K.; ROGERS, JONATHAN R.):

Unusual-pattern check — NEGATIVE. There is no indication that any inventor departed the assignee within 12 months of filing. Two of the seven (Moore, Rogers) were founding-era employees (2010) who remained with Centripetal through at least the 2022–2023 litigation. The inventor roster is a stable founder/key-employee team, not a departed-inventor portfolio. This is consistent with a genuine operating-company R&D effort (the patent's own specification and the company's DHS-funded research history support that).

---

Original assignee

Centripetal Networks, Inc. (Portsmouth, NH), named as assignee on issuance (2022-11-29); subsequently continued as Centripetal Networks, LLC by conversion.

• Product embodying the claims: Yes. Centripetal shipped and sold a threat-intelligence gateway, RuleGATE, plus CleanINTERNET (a network-protection service built on RuleGATE), Advanced Cyber Threat (ACT), and the QuickTHREAT analytics UI. CTO Sean Moore's declaration states the RuleGATE system "can observe in-transit packets to recognize and prevent exfiltration," and the court in Centripetal v. Cisco found that "Centripetal's RuleGate product practices the '193 Patent" (a sibling in the same family). Centripetal's own 2022 ITC complaint attached RuleGATE 2000 datasheets and CleanINTERNET webpages as exhibits. This is a real, commercialized product line.
• Primary line of business: Network security — "operationalizing" cyber-threat intelligence into live packet-filtering enforcement at network boundaries (commercial + U.S. Government/defense R&D).
• Current status: Operating. No bankruptcy, no dissolution, no acquisition. The Inc.→LLC change was a statutory Delaware conversion, not a sale: per the Certificate of Conversion filed 2022-12-30 (executed 2022-10-17), "Centripetal Networks, Inc." converted to "Centripetal Networks, LLC," and per Del. Code tit. 6 § 18-214 the LLC "remains the same entity by operation of law." The entity today operates from 1875 Explorer Street, Suite 900, Reston, VA 20190 (per PTAB mandatory notices).

---

Assignment timeline

Two recorded conveyances exist for US 11,516,241. Both are benign; neither moves the patent out of the operating company.

1. 2022-04-05 (executed & recorded same day) — Reel/Frame not verified (see provenance note)

   • 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. (Portsmouth, NH)
   • Correspondent: Corroborated but not verbatim — BANNER & WITCOFF, LTD., 1100 13th Street NW, Suite 1200, Washington, DC 20005 (USPTO Customer No. 22907). Banner & Witcoff prosecuted this application and is the recurring firm across the entire Centripetal chain (attorneys of record: Bradley C. Wright Reg. No. 38,061; Scott M. Kelly Reg. No. 65,121; John R. Hutchins Reg. No. 43,686; Kirk A. Sigmon). Flag: this is a repeat, large general-practice IP firm on every Centripetal filing — recurrence here is a long-client-relationship tell, not an NPE-shell tell (see Signal 3).
   • Context: Routine founder/employee-inventor assignment to the operating company, recorded contemporaneously with the continuation's filing (Apr 5, 2022). Not a fire-sale, not a transfer-to-asserter.

2. 2023-01-24 (recorded); conversion effective 2022-12-30 (executed 2022-10-17) — Reel/Frame not verified (see provenance note)

   • Conveyance: CHANGE OF NAME
   • Assignor: CENTRIPETAL NETWORKS, INC. (Delaware corporation)
   • Assignee: CENTRIPETAL NETWORKS, LLC (Delaware limited liability company)
   • Correspondent: Not verified verbatim; expectation is Banner & Witcoff, Ltd. (Customer No. 22907) as attorney of record.
   • Context: Change of name only arising from a Delaware statutory conversion (Certificate of Conversion filed 2022-12-30; LLC registered agent The Corporation Trust Company, 1209 Orange St., Wilmington, DE 19801). Same legal entity; no change in beneficial ownership.

Cross-reference artifacts (do not mistake for assignments):

• Google Patents annotates the 2022-04-05 event as "Application filed by Centripetal Networks LLC" and lists "Original Assignee: Centripetal Networks LLC." These are present-tense name renderings by Google, not the historical assignee — the entity that received the 2022-04-05 assignment was Centripetal Networks, Inc. (the conversion post-dates both the assignment and the Nov. 29, 2022 issuance).
• Centripetal's 2022 ITC complaint included "Certified Assignments for U.S. Pat. No. 10,193,917" (Ex. 17) and for '370 and '526 (Exs. 16, 18) — i.e., the same firm was recording the chain of title for the family.
• No security agreement, merger, license, release, or corrective assignment is recorded against this number in the sources retrieved.

---

Timeline diagram

timeline
    title Ownership of US 11516241
    2009 : Centripetal Networks Inc formed in Delaware
    2015 : Priority application filed Apr 17
    2022 : Continuation application filed Apr 5
         : Inventors assign rights to Centripetal Networks Inc
         : Patent issued Nov 29
         : Delaware conversion creates Centripetal Networks LLC
    2023 : Change of name recorded Jan 24

---

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The only assignee-side change is the Inc.→LLC conversion, which is a name/entity-form change by operation of law (Del. Code tit. 6 § 18-214), not a transfer to a separate licensing vehicle. The LLC suffix is not a licensing/holdings marker; the entity retains its operating HQ (Reston, VA) and the Delaware registered-agent address (Corporation Trust Center) is simply the standard DE registered agent, which every Delaware entity uses. No evidence of "no products in commerce."

2. Known asserter in the chain — not present. Centripetal Networks does not appear on the Acacia / Marathon / Intellectual Ventures / Wi-LAN / Conversant / Pendrell / Round Rock / Spangenberg rosters. It is a first-party operating company that both sells a product and sues competitors. (It is a high-frequency plaintiff, but in the operating-company posture, not the NPE posture.)

3. Repeat correspondent across the chain — present, but not probative. The same firm, Banner & Witcoff, Ltd. (Customer No. 22907), recurs on every recordation and on the prosecution of the whole family (Wright, Kelly, Hutchins, Sigmon). Per the task's own caution, however, a recurring general-practice firm that does both operating-company and other patent work is not a shell tell. Banner & Witcoff has publicly represented Centripetal since ~2010 as its outside patent counsel. Marked present for completeness; weight ≈ none toward an NPE finding.

4. Cascading transfers — not present. There is one substantive transfer (inventors → Inc.) plus a name change. No successive LLC hops, no shared registered-agent chains, no sub-24-month cascades.

5. Pre-litigation transfer — not present. No assignment is dated within 6 months before any suit. Centripetal has litigated the family in its own name since the 2017 Keysight and 2018 Cisco complaints — i.e., the patent holder and the litigant are the same entity, and always have been.

6. Bankruptcy fire-sale — not present. No Chapter 7/11 proceeding; the assignee is an active, funded operating company that won a ~$2.6–3.2B verdict against Cisco in October 2020 (later vacated on recusal grounds, 38 F.4th 1025 (Fed. Cir. 2022)).

7. Privateering — not present. No transfer to an NPE to assert on the operating company's behalf. Centripetal asserts its own patents itself (Cisco, Keysight, Palo Alto Networks are its direct competitors in network security).

8. Defensive aggregator — not present. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN; ownership remains with the operating company.

---

Verdict

Operating-company assertion.

Justification: the only two recorded conveyances on US 11,516,241 are (i) the inventors' assignment of assignors' interest to Centripetal Networks, Inc. recorded 2022-04-05, and (ii) a change-of-name recordation to Centripetal Networks, LLC recorded 2023-01-24, which merely memorialized a Delaware statutory conversion (effective 2022-12-30) in which the LLC "remains the same entity by operation of law." Centripetal ships products embodying the claims (RuleGATE / CleanINTERNET — corroborated by CTO Sean Moore's sworn declaration that RuleGATE "recognize[s] and prevent[s] exfiltration" and by the court's finding that RuleGATE "practices" the sibling '193 patent) and asserts the family against actual competitors (Cisco, Keysight, Palo Alto Networks). That is the textbook operating-company-assertion profile, and it is corroborated rather than merely asserted because the "NPE" signals above are each either absent or, in the one case present (recurring correspondent), non-probative.

Verification link: https://assignmentcenter.uspto.gov/ (search patent 11516241) · mirror: https://assignment.uspto.gov/patent/index.html

Remaining gap for closure: the two reel/frame numbers and the verbatim recorded correspondent names for this specific patent. These require the Assignment Center detail page or the recorded PDF (assignment-tm-####-####.pdf), which I could not open in this session. Everything else above is grounded in the patent's own text, the Delaware Certificate of Conversion, the PTAB mandatory notices, and inventor declarations filed with USPTO.

I'll research the prior art citations for US 11,516,241. Let me run targeted searches.

Let me dig deeper into the specific citation list for this patent.

US 11,516,241 — Prior-Art / Citation Analysis

Provenance and method note (read first)

Two constraints govern everything below, and I will not paper over them:

1. I could not execute a live query against the USPTO's own systems. USPTO Patent Public Search, PatentCenter and the Patent Assignment Search were not reachable in this session. The front-page "(56) References Cited" data below is drawn from Google Patents, Justia Patents and FreePatentsOnline, which reproduce the printed patent's cited-references section. Treat this as a mirror of the USPTO record, not an independent USPTO retrieval.
2. The authoritative full text I was given for US 11,516,241 (Google Patents fetch, 2026-09-24) omits BOTH the claims and the front-page "(56) References Cited" block. It contains only abstract, summary, description and figures. So I cannot quote the patent's own reference list verbatim, and I cannot give you verified claim numbers. Consistent with the earlier "Patent summary" section in this analysis, all claim-number mappings below are inferential.

I flag every inference.

---

1. What the citation record for the '241 actually looks like

The Google Patents family pages show the '241 patent nested inside a family whose citation tables are enormous and conflate two different things:

• "Patent Citations" — documents cited in the patent (true prior art);
• "Cited By" / "Similar Documents" — later documents citing the patent (NOT prior art to the '241).

The snippets I retrieved show tables of "Patent Citations (218)" (on the US 10,193,917 page) and "Patent Citations (438)" (on the US 12,015,626 page). Because US 11,516,241 is a continuation in that same family (17/713,570 ← 17/232,291 ← 17/001,164 ← 16/813,220 ← 16/706,388 ← 16/217,720 ← 15/827,477 ← 14/690,302), those large tables are family-level aggregations, and a large fraction of the entries dated 2016–2024 are third-party documents that cite the family, not art cited against it. Do not treat the (218)/(438) counts as the '241's own prior-art count.

The narrowest, most defensible citation set I found is the small examiner-citation table surfaced on the sibling publication US 2022/0232028 A1 (filed the same day, 2022-04-05, from the same specification). That table is headed "Patent Citations (16)." Because it shares the '241's disclosure and filing date, it is the closest available proxy for the '241's own cited references.

---

2. Examiner-cited U.S. patent documents (the "16" set — closest proxy to the '241 front page)

(The table is headed "(16)"; one entry was truncated in retrieval, so the list above is 15 of 16.)

Note on § 102 dates for #11, #14, #15: each has an effective filing date before 2015-04-17 (the '241's effective filing date) but published after it. If the '241 is subject to AIA § 102, those three are available only under § 102(a)(2) (as U.S. patent applications/patents "effectively filed" earlier), not under § 102(a)(1). This is a materially different ground than most of the older references, which are § 102(a)(1)/pre-AIA § 102(b) art.

---

3. Broader firewall/packet-classification art cited across the family

These appear in the family-level citation tables (e.g., on the US 10,193,917 page) and would be the fallback art for the filtering-rule plumbing in the '241:

---

4. Non-patent literature cited (confirmed on the '241's own Justia page)

The Justia record for patent/11516241 reproduces the family's NPL list, including:

• A. Feldmann et al., "Tradeoffs for Packet Classification," IEEE INFOCOM, 397–413 (2000)
• A. Hari et al., "Detecting and Resolving Packet Filter Conflicts," IEEE INFOCOM, 1203–1212 (2000)
• Acharya et al., "OPTWALL: A Hierarchical Traffic-Aware Firewall," Univ. of Pittsburgh, 1–11 (2007)
• Anonymous, "The Distribution of Malicious Domains," The DomainTools Report, 2016 Edition, Mar. 9, 2016 (XP055502306) — note: post-dates the 2015-04-17 priority date; usable only if its own effective date pre-dates the '241, which is doubtful
• Bellion, "High Performance Packet Classification," http://www.hipac.org (date unknown)
• Blake et al., "An Architecture for Differentiated Services," RFC 2475 (Dec. 1998)
• C. Benecke, "A Parallel Packet Screen for High Speed Networks" (ACSAC 1999)
• Chen et al., "Research on the Anomaly Discovering Algorithm of the Packet Filtering Rule Sets" (2010)
• D. Comer, "Analysis of a Heuristic for Full Trie Minimization," ACM TODS 6(3):513–537 (1981)
• D. Decasper et al., "Router Plugins…," IEEE/ACM ToN 8(1) (2000)
• D. Eppstein et al., "Internet Packet Filter Management and Rectangle Geometry," SODA, 827–835 (2001)
• E. Al-Shaer et al., "Firewall Policy Advisor…" (2003); "Modeling and Management of Firewall Policies" (2004)
• E. Fulp et al., "Network Firewall Policy Tries" (2004); E. Fulp, "Optimization of Network Firewall Policies…" (2004); "Preventing Denial of Service Attacks on Quality of Service" (2001); E.W. Fulp, "Firewall Architectures for High Speed Networks" (2003)
• E.L. Lawler, "Sequencing Jobs to Minimize Total Weighted Completion Time…," Annals of Discrete Math. 2:75–90 (1978) — relevant to rule ordering
• Fulp, "Trie-Based Policy Representations for Network Firewalls" (2005)
• G. Brightwell et al., "Counting Linear Extensions is #P-Complete" (1991)
• G.V. Rooij, "Real Stateful TCP Packet Filtering in IP Filter" (USENIX 2001)
• Greenwald, "Designing an Academic Firewall… SURF" (IEEE SNDSS 1996)
• J. Xu et al., "Design and Evaluation of a High-Performance ATM Firewall Switch…," IEEE JSAC 17(6):1190–1200 (1999)
• S.M. Bellovin et al., "Network Firewalls," IEEE Communications Magazine, 50–57 (1994)
• S. Goddard et al., "An Unavailability Analysis of Firewall Sandwich Configurations" (2001)
• S. Suri et al., "Packet Filtering in High Speed Networks," SODA, 969–970 (1999)
• Sourcefire 3D System User Guide, v4.10 (Mar. 16, 2011), 2123 pp.
• V. Srinivasan et al., "Fast and Scalable Layer Four Switching," ACM SIGCOMM, 191–202 (1998)
• V.P. Ranganath, "A Set-Based Approach to Packet Classification" (2003)
• W.E. Leland et al., "On the Self-Similar Nature of Ethernet Traffic," IEEE/ACM ToN 2(1) (1994)
• NIST SP 800-41, "Guidelines on Firewalls and Firewall Policy" (Scarfone et al., Rev. 1, Sep. 2009; and the 2002 Wack et al. original) — repeatedly cited across the family

---

5. Most relevant prior art and the § 102 mapping

Caveat, stated plainly: I have no verified claim text for the '241. The mapping below is keyed to the elements reconstructed in the earlier "Patent summary" section (rule receipt → packet receipt → criteria match against network-threat indicators → operator apply/allow-vs-block → log entry with rule-identifying metadata distinct from the criteria → data to user device → interface → invoke-to-reconfigure-operator). Where I write "claim 1," read "the first independent claim (method), as reconstructed." I cannot certify that any reference anticipates rather than merely teaches an element, and I have not seen the examiner's § 102 rejections.

Honest assessment of strength: the family's cited art is overwhelmingly firewall/packet-classification art from 1978–2011. That art plainly covers "apply rule → allow or drop." The elements that look like the '241's actual point of novelty — a filter rule carrying metadata distinct from its matching criteria that maps the rule back to a specific network-threat indicator / threat ID, and logging that ID together with the allow-vs-block disposition, surfaced in an operator dashboard whose control reconfigures the operator to BLOCK — are not obviously met by the 1978–2011 firewall art. The two references in the cited set that come closest to that threat-intelligence flavor are US 10,659,480 B2 (InQuest) and US 2016/0226895 A1 (ThreatStream), and both post-date the 2015-04-17 priority date (available, if at all, only under § 102(a)(2)). That is the single most important observation in this analysis.

---

6. Contradiction flagged against the earlier "Litigation summary"

The earlier section concluded that no litigation could be confirmed naming US 11,516,241. The Justia page for patent/11516241 — retrieved in this session — reproduces a block of "Exhibit … as cited in Complaint of Centripetal Networks, Inc. dated Apr. 19, 2022" documents (Keysight webpages: AppStack, ThreatArmor, CloudLens, Vision X, etc.), which is Justia's convention for exhibits tied to a complaint asserting that patent. The April 19, 2022 filing date corresponds to Centripetal's second Keysight action (E.D. Va., 2:22-cv-00002).

I therefore flag a probable correction: the '241 patent appears to have been among the patents asserted in the April 19, 2022 Keysight complaint, which would contradict the earlier "no litigation found" conclusion. I rate this medium confidence — Justia's exhibit-to-patent association is inferential and I could not verify the complaint text directly. The prior section's finding that the 2026 Federal Circuit activity (Nos. 24-2097, 24-1416, 23-2027, 24-1406) concerns other patents ('193, '806, '176, '856, '917) is unaffected.

---

7. What you must verify to close this out

1. USPTO Patent Public Search / PatentCenter — retrieve US11516241 and read the printed (56) References Cited block verbatim, plus the "Applicant Cited" vs. "Examiner Cited" split and the "cited by examiner" asterisks. This is the authoritative list; everything above is a mirror.
2. The actual prosecution file wrapper for 17/713,570 — the examiner's § 102/§ 103 rejections and any IDS submissions. For a continuation this is the only way to know which references the examiner actually relied on as opposed to merely listing.
3. Verbatim claim text for US 11,516,241 (still missing from the authoritative document I was given) — required before any claim-numbered § 102 mapping can be certified.
4. Darts-IP family 55863202 and E.D. Va. 2:22-cv-00002 (and the ITC 337-TA-1314 complaint) to confirm the '241-assertion question raised in §6.

Bottom line: the references most likely to matter as § 102 art for US 11,516,241 are US 10,659,480 B2 (InQuest), US 2016/0226895 A1 (ThreatStream) and US 2017/0339192 A1 (Patternex) for the threat-intelligence-matching core (all § 102(a)(2)-only, given their post-2015-04-17 publication), with US 7,747,737 B1, US 2010/0046378 A1 and US 6,484,261 B1 supplying the flow-log and GUI-reconfiguration elements — but I cannot certify claim-by-claim anticipation without the '241's verbatim claims and its file wrapper, neither of which was available to me.

I'll research the prior-art references associated with this patent before drafting the § 103 analysis.

Let me pull the specific prior-art citations on the '241 page and the claims text, plus IPR grounds against the closely-related parent patents.

I have the key claim text lead. Let me verify the '241 patent's issued claims and identify the specific prior art of record in its "Prior Art" section.

Obviousness Analysis — U.S. Patent No. 11,516,241 ("Rule-Based Network-Threat Detection") under 35 U.S.C. § 103

---

0. Important correction to the previously generated sections

The earlier "Patent summary" and "Litigation summary" sections stated that the claim set of US 11,516,241 was not available and reconstructed it from FIG. 7, the abstract, and the parent US 10,609,062. A targeted search partially resolves that gap and contradicts the reconstruction:

• The pre-grant publication of application 17/713,570 is US 2022/0232027 A1 (filed 2022-04-05, published 2022-07-21, "Patent Grant number: 11516241"), inventor list matching the '241 patent (Ahn, George, Geremia, Mallett, Moore, Perry, Rogers). Source: https://patents.justia.com/patent/20220232027

• The claims published with that application are not the simple "generate a log entry / reconfigure the operator" set the earlier section inferred. They are directed to scoring a detected threat and causing an ordered list of network threats — maintained by a separate rule-provider device — to be updated and displayed, with a stated latency objective. E.g., independent device claim 11 recites:

  "…receive, from a rule provider device in the unprotected network outside of the boundary, a plurality of packet-filtering rules to be applied… to all network traffic traversing the boundary… generate a first log entry… determining… a first score… cause at least a portion of the first log entry to be added to the ordered list of network threats… and cause display of the ordered list of network threats."

  Claim 1 is a method counterpart; claim 21 is a CRM counterpart; 30 claims total, three independent claims (1, 11, 21) appear.

Caveat (please read before relying on this): these are the application publication claims from a secondary source (Justia). I could not verify the verbatim issued claim set of US 11,516,241, and pre-grant claims are frequently amended before allowance. My element mapping below is therefore against the published claim set and should be re-verified against the printed patent / PatentCenter. Where I could, I anchored on limitations that appear identically in the sibling US 11,792,220 publication (same "ordered list of network threats / rule provider device / score / minimize latency" architecture).

Second caveat: the authoritative full text I was given (the Google Patents page for US11516241) contains the "Prior art keywords" (packet; network; threat; filtering; filtering device) and "Prior art date 2015-04-17" but not the underlying citation table. The page reports "Patent Citations (218)" on the sibling US 10,193,917 page, but the reference list itself was not in my fetch. I therefore rely on (a) references I could substantiate from the IPR record for this exact family, and (b) references identified in the '241's own prior-art list that I could retrieve. I flag each.

---

1. The § 103 frame

Key strategic fact: every judicially tested claim in this continuation chain has been held unpatentable, most of them over one reference:

The '241 is a direct descendant of the '413 and the '917 (17/713,570 ← 17/232,291 ← 17/001,164 ← 16/813,220 ← 16/706,388 ← 16/217,720 ('413) ← 15/827,477 ('917) ← 14/690,302). Its specification is the same text the Board has already read repeatedly.

---

2. The prior art I can substantiate

A. Sourcefire — the primary reference

"Sourcefire 3D System User Guide, Version 4.10" plus the Sourcefire 3D Sensor Installation Guide. Substantiated in IPR2018-01760, IPR2021-01149, IPR2022-01097 and multiple IPR2021-0115x petitions.

Discloses:

• a packet-filtering device (3D Sensor running an IPS) that receives packet-filtering rules ("intrusion rules");
• rule criteria in source/destination IP address, source/destination port, protocol, and content — i.e., network-threat indicators (Sourcefire's default rules are the Vulnerability Research Team's threat-signature set);
• per-rule operators (drop / pass / alert) — i.e., prevent-vs-allow;
• event logging ("intrusion events") for each triggering packet, with threat identification;
• consolidation into drill-down/flow views (counts, time, threat identifier) — the "flow log";
• communication to a separate computing device (Defense Center) and display on a web UI, where rule operators can be modified.
  See https://ai-lab.exparte.com/case/ptab/IPR2022-01097/doc/summary/1.

B. Macaulay — US 2015/0207809 A1

Substantiated as the secondary reference in IPR2021-01149 and IPR2022-01097. Discloses refining cyber-threat-intelligence data by sending a threat list to two cyber-threat-intelligence sources, receiving threat data back, updating the threat list, and iterating; and assigning "reputation scores" to attributes (IP address, domain) — including scores driven by number of logged events, traffic volume, and the source of the threat intelligence. The Board's reasoning is quoted in the Federal Circuit record: "reputation scores… claims 6 and 16 obvious." Note the §102(a)(2) dependency: Macaulay published 2015-07-23, after the Apr. 17, 2015 critical date, so it qualifies only if its effective filing date predates it (the Board so treated it, which I take as confirmation but could not independently verify).

C. Law — centralized third-party rule provider (exact number unverified)

Used in IPR2023-00445 and IPR2023-01329. Discloses a "cyber security risk management firm" that collects threat data from a plurality of sources, constructs rulesets, validates/verifies them, and distributes them to customer UTMS-configured firewalls. This is the closest art to the '241's "rule provider device in the unprotected network outside of the boundary" that supplies rules to the packet-filtering device. I could not verify Law's patent/publication number or exact date; the petitions treat it as a printed publication predating a pre-AIA patent and therefore well before 2015-04-17. Treat as promising but unverified.

D. Wood — feed of suspect addresses that reconfigures a router (exact number unverified)

Discloses an "adaptive interrogation module" receiving a feed of suspect addresses from external sources and reconfiguring a router so that traffic to those addresses is dropped/redirected to a null address; updates are pushed as sources change. Directly maps to receiving rules from outside the boundary + reconfiguring to BLOCK. Number unverified.

E. Jungck — US 2009/0262741 A1 (verified)

Published Oct. 22, 2009. Discloses a transparent packet security gateway / edge server that intercepts "all network traffic" and applies packet filtering before forwarding to destination, using a list of blocked IP addresses. Maps to "rules applied to all network traffic traversing the boundary" in a network-layer-transparent manner. This is squarely §102(a)(1)/§102(b) art to the '241.

F. References already listed in this family's own prior-art record (NPL)

From the '241's lineage citation lists (https://patents.justia.com/patent/9413722, https://patents.justia.com/patent/11516241):

• Mizuno et al., "A New Remote Configurable Firewall System for Home-use Gateways," IEEE CCNC (Jan. 2005) — remote configuration of firewall rules/operators from outside the protected network.
• Reumann et al., "Adaptive Packet Filters," IEEE (2001) — adaptively updating packet filters.
• Greenwald et al., "Designing an Academic Firewall: SURF," IEEE SNDSS (1996); Bellovin & Cheswick, "Network Firewalls," IEEE Comm. Mag. (1994) — baseline boundary filtering with allow/deny policy.
• Fulp, "Trie-Based Policy Representations for Network Firewalls" (2005); Al-Shaer et al., "Modeling and Management of Firewall Policies" (2004) — rule-set representation and management.
• Scarfone & Hoffman, NIST SP 800-41 Rev. 1 (Sept. 2009) — firewall policy design, logging, and rule management.
• Kindervag, "Build Security Into Your Network's DNA: The Zero Trust Network Architecture," Forrester (Nov. 5, 2010) and Palo Alto Networks' Zero-Trust tech brief — boundary enforcement of all traffic against policy.

G. Centripetal's own pre-critical-date disclosures (potentially §102(a)(1))

Two items appear in the family's record as prior art and predate 2015-04-17:

• Moore, "SBIR Case Study: Centripetal Networks…," DHS S&T, 2012 Principal Investigators' Meeting (Oct. 10, 2012);
• Internet Archive capture of Centripetal Networks' "Network Protection System v2.1" product page, captured Feb. 5, 2015 (Ex. 2035 in IPR2021-01149).
  These are self-authored/self-published descriptions of the very rule-based threat-detection gateway. They are a realistic §102(a)(1) printed-publication / public-use theory — and the patent's own IDS citation of the 2012 case study is effectively an admission that the framework was public before filing.

H. On the "Prior art keywords" of the page

The page's own keywords — packet, network, threat, filtering, filtering device — confirm the field is packet-level network-threat filtering, whose pre-2015 art is exactly Sourcefire, Jungck, Law/Wood, and the firewall-policy NPL above.

---

3. Grounds of rejection

Ground 1 — Sourcefire alone: renders obvious the packet-filter/evaluate/log/display core

Evidence of record: IPR2018-01760 FWD (as to the '722) aff'd, 847 F. App'x 881; IPR2022-01097 FWD (as to the '917) aff'd Apr. 23, 2026. Even the Supreme Court petition in Centripetal v. Cisco recites the Board's finding that Sourcefire teaches a "packet-filtering device" receiving "packet-filtering rules" and identifies threats via source IP (https://www.supremecourt.gov/DocketPDF/21/21-193/187048/20210809163142459_Centripetal%20Networks%20Inc.%20v.%20Cisco%20Systems%20Inc.%20-%20Petition.pdf).

Weakness: Sourcefire's prioritization is a static, user-set "priority level" — not a score for a log entry, and Sourcefire does not maintain the list at a separate rule-provider device. Ground 1 alone is therefore probably insufficient for the '241's independent claims; it carries the dependent "flow log / allow-block indication" claims (e.g., published claims 5 and 7) and the timing claim (published claim 4).

Ground 2 — Sourcefire + Macaulay: adds the score and the multi-source aggregation

Maps:

• "determining… a first score" → Macaulay's reputation scores for threat attributes, computed from event counts, traffic volume, and intelligence provenance.
• "a first packet-filtering rule… generated based on two or more network-threat-intelligence reports supplied by at least two different… providers" (published claim 10) → Macaulay's "send threat list to two cyber-threat-intelligence sources, receive threat data back, update the threat list, repeat."
• "score… based on a count of the network-threat-intelligence providers…" (claim 8) and "based on a number of the plurality of packets that match" (claim 9) → Macaulay's source-count and event-count factors.
• Ordered list of network threats → Macaulay's iteratively updated/refined threat list.

Motivation / KSR: (i) both references are in the same field (network security/threat intelligence) and are analogous art; (ii) a POSITA would replace Sourcefire's "rudimentary, static" priority levels with Macaulay's dynamic reputation scores to obtain more accurate, granular, and responsive prioritization — a "well-known goal in network security"; (iii) predictable results and high expectation of success, because the scoring merely reuses data already present in Sourcefire's event records (packet counts, timestamps, threat identifiers); (iv) design choice / obvious-to-try. This is precisely the rationale the Board accepted in IPR2021-01149 (FWD as to the '413, claims 1–20), affirmed Oct. 31, 2024, and in IPR2022-01097 (claims 6–10, 16–19), affirmed Apr. 23, 2026.

Ground 3 — Sourcefire + Macaulay + Law (+ Wood, + Jungck): adds the "rule provider device" and the all-traffic boundary interface

This is the ground aimed at the two limitations that most plausibly distinguish the '241:

1. "receive, from a rule provider device in the unprotected network outside of the boundary, a plurality of packet-filtering rules… applied to all network traffic traversing the boundary" → Law (cyber-security risk-management firm aggregates threat data from many sources, builds/validates rulesets, and distributes them to customer firewalls) + Jungck (transparent edge packet-security gateway intercepting all traffic).
2. "causing the rule provider device to add the at least the portion of the first log entry to the ordered list of network threats by sending… the at least the portion of the first log entry" (feedback of local hits to the central provider so the central list is ordered) → Law (central provider maintaining/distributing the ruleset) + Macaulay (two-way iteration between a central threat list and its sources) + Wood (external sources pushing updated suspect-address lists that trigger router reconfiguration).
3. "configured to minimize latency between when a network threat is detected… and when the network threat is included in an ordered list" → a stated design objective met by Sourcefire's packet-time event generation and Macaulay's "real-time system for information and intelligence sharing"; a POSITA would find no new structure required.

Motivation: a POSITA subscribing to multiple commercial threat-intelligence feeds (a practice the '241's own Background admits was routine) would naturally centralize rule generation/validation at a provider and push the rules to edge devices — the classic "threat-intelligence gateway" architecture — because it (a) offloads rule curation, (b) lets one provider normalize and score indicators from many feeds, and (c) yields faster, more consistent protection across many customer boundaries. Law, Wood and Jungck each teach a piece; combined with Sourcefire/Macaulay the '241's independent claims read on the combination.

Verification gap: I could not verify Law's or Wood's bibliographic identities/dates from an authoritative source. Both are treated in the PTAB record as pre-2015 printed publications, but that must be confirmed before this ground is relied on.

Ground 4 — The applicant's own pre-2015 publications (self-collision)

Moore, "SBIR Case Study: Centripetal Networks…" (Oct. 10, 2012) and the Wayback capture of Centripetal's Network Protection System v2.1 page (Feb. 5, 2015) are in the family's own record and predate 2015-04-17. If either describes centralized ingestion of threat-intelligence feeds plus boundary filtering and threat display, it is §102(a)(1) art — alone or combined with the broader NPL (Mizuno remote-configurable firewall; Reumann adaptive filters; NIST SP 800-41; Kindervag Zero Trust). Because the patent's own IDS cites the 2012 case study, the topic was known to the examiner, and there is no "unexpected result" story to tell about centralizing rule distribution.

Ground 5 — Conditional: if the critical date moves

If the score/ordered-list-at-rule-provider limitations lack § 112 written-description support in the 2015-04-17 chain (they are drafted at a level of generality — "ordered list of network threats," "minimize latency" — that invites a priority challenge), the effective date could move to the 2021–2022 continuation filings. That would unlock additional art appearing in the record: Macaulay's own publication (2015-07-23), the DomainTools Report 2016, and Centripetal's own RuleGate coverage (Security Blogger, July 20, 2016) and ESG Threat Intelligence Gateway white paper (May 2018) — all of which describe scoring/ordering of threats on a dashboard.

---

4. Why a POSITA would combine these — a consolidated motivation table

---

5. Where the challenger is weakest (and what secondary evidence would be needed)

1. The "score → ordered list maintained at the rule-provider device" chain. No single reference I have substantiated discloses a packet-filtering device that sends its log entry back to a remote rule provider device so that the provider's ordered list is updated, then displays that list. This is the most defensible limitation. It is best attacked with Law + Macaulay + Wood (Ground 3), and the identity/date of Law and Wood must be nailed down.
2. Macaulay's date. Publication (2015-07-23) postdates the asserted Apr. 17, 2015 priority. The ground depends on Macaulay's earlier effective filing date under §102(a)(2). Verify from the face of the document.
3. "Minimize latency" is likely a result-oriented statement with little or no patentable weight where the steps themselves are known (Board and Federal Circuit practice on such language in this family — see the '917 FWD treatment of the pre-claim "positioned between" language and the Fed. Cir.'s "responsive to" analysis). If instead it is given limiting weight, it finds support in Sourcefire's packet-time logging and Macaulay's "real-time" framing.
4. Secondary considerations. Centripetal has relied on commercial success/industry praise (Gartner "Cool Vendors," IBM case study, American Banker, ESG white paper). The Board has repeatedly found no nexus to the claimed advance — e.g., "PO has not demonstrated the requisite nexus… the secondary considerations are the direct result of the unique characteristics of the claimed invention," IPR2021-01157, Paper 36 at 39 (Mar. 10, 2023), quoted in the IPR2023-01329 petition (https://www.docketalarm.com/cases/PTAB/IPR2023-01329/.../Petition_as_filed.pdf). Expect the same disposition for the '241.
5. Estoppel/issue-preclusion tailwind. The '241's own ancestors have now been held unpatentable in full ('917: all claims, Fed. Cir. Apr. 23, 2026; '413: claims 1–20, Fed. Cir. Oct. 31, 2024; '722: aff'd 2021). Because the '241 shares the specification and the same Sourcefire-centric disputed limitations (log/flow consolidation, "packet flow entry," allow-vs-block indication, operator reconfiguration), a challenger can argue the Board's prior findings are binding on the common limitations, leaving only the score/ordered-list limitations to be supplied by Macaulay (and the provider architecture by Law/Wood). That is (per the earlier-generated Litigation section) why the Darts-IP family flag on the '241 page does not by itself prove the '241 has been individually asserted — but it does mean the '241 sits inside a family that has been litigated and repeatedly invalidated.

---

6. Bottom line

• Claims most likely obvious: the log-entry/flow-log/allow-block/display-dependent claims over Sourcefire alone (already adjudicated for sibling claims), and the score/multi-provider claims over Sourcefire + Macaulay (already adjudicated for sibling claims). These are strong, record-backed § 103 positions.
• The heart of the '241's independent claims — scoring a detected potential threat and pushing the log entry to a remote rule-provider device that maintains and displays an ordered list of network threats, with a latency objective — is probably obvious over Sourcefire + Macaulay + Law (+ Wood and/or Jungck), but this ground is not yet verified: the bibliographic identity, dates, and content of "Law" and "Wood" must be confirmed from the primary documents before reliance, and Macaulay's §102(a)(2) footing must be confirmed.
• Highest-value additional avenues: (i) Centripetal's own 2012 SBIR case study and February 2015 product page as §102(a)(1) art; (ii) a priority/written-description challenge to the score/ordered-list language, which would move the critical date past 2015 and unlock Macaulay's publication plus Centripetal's 2016–2018 RuleGate/ESG materials.

Uncertainties I am not papering over: (1) I could not obtain the verbatim issued claims of US 11,516,241 — my element mapping uses the US 2022/0232027 A1 publication claims and the sibling US 11,792,220 claims; (2) I could not retrieve the 218-entry prior-art citation table on the '241's own page; (3) the identities/dates of "Law" and "Wood" are unverified; (4) Macaulay's effective filing date is unverified; (5) the Federal Circuit appeal number(s) for the Oct. 31, 2024 Centripetal v. Palo Alto Networks decision appear inconsistently as 23-1654 and 23-1785 in the sources I retrieved.