US 10193917

Patent Analysis: US 10193917 B2

Date of Analysis: April 26, 2026

Here is a concise summary of United States Patent 10,193,917, including details from the patent document and recent legal proceedings.

---

Patent Details

• Title: Rule-based network-threat detection
• Assignee: Centripetal Networks, LLC
• Inventors: David K. Ahn, Keith A. George, Peter P. Geremia, Pierre Mallett, III, Sean Moore, Robert T. Perry, Jonathan R. Rogers
• Filing Date: November 30, 2017
• Issue Date: January 29, 2019
• Abstract: 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 Independent Claims

This patent has two independent claims, which form the core of the invention.

• Independent Claim 1: This claim describes a method for a packet-filtering device to handle network traffic. The device receives a set of filtering rules that are based on known network threats. When a data packet arrives, the device checks if it matches the criteria of any of these rules. If there is a match, the device takes a pre-defined action—either allowing the packet to proceed or blocking it. Crucially, the device then creates a log entry. This log not only records the action taken (allow/block) but also includes specific information from the rule itself that identifies the threat, such as a "Threat ID." This allows for more detailed and useful logging than just noting that a packet was blocked or allowed based on a generic rule. The system then sends this detailed log information to a user's device, where it is displayed in an interface. This interface also includes an option for the user to change the rule's action, for example, to start blocking a threat that was previously only being monitored (allowed).

• Independent Claim 11: This claim describes the packet-filtering device itself, as a physical apparatus. It outlines a system with a communication interface to receive data packets, a memory to store the threat-based filtering rules, and one or more processors. The processors are configured to perform the actions described in Claim 1: receive packets, match them against the stored rules, apply the rule's action (allow or block), and generate a detailed log entry that includes the threat identifier from the rule. This claim focuses on the components of the device that enable the rule-based threat detection and logging method.

Litigation Status

As of April 23, 2026, US Patent 10,193,917 has been the subject of a legal challenge. In the case of Centripetal Networks, LLC v. Keysight Technologies, Inc., the U.S. Court of Appeals for the Federal Circuit (CAFC) reviewed a decision from the Patent Trial and Appeal Board (PTAB). The CAFC affirmed the PTAB's finding that claims 1–3, 5–13, and 15–20 of this patent are unpatentable due to obviousness over prior art. The court also reversed the PTAB's decision on claims 4 and 14, finding them to be obvious as well. This recent court decision significantly impacts the enforceability of this patent.

Based on a review of patent litigation databases and legal records as of today, April 30, 2026, US Patent 10,193,917 B2 has been subject to multiple legal and administrative proceedings.

U.S. District Court Litigation

1. Case Name: Centripetal Networks, LLC v. Keysight Technologies, Inc.

   • Plaintiff: Centripetal Networks, LLC
   • Defendant: Keysight Technologies, Inc.
   • Jurisdiction: U.S. District Court for the Eastern District of Virginia
   • Case Number: 1:22-cv-00001
   • Filing Date: January 3, 2022
   • Status/Outcome: This case was stayed pending the outcome of inter partes review (IPR) proceedings at the Patent Trial and Appeal Board (PTAB). Following the PTAB's decision and the subsequent affirmation and expansion of unpatentability by the Court of Appeals for the Federal Circuit (CAFC), this case is subject to dismissal.

2. Case Name: Centripetal Networks, LLC v. Palo Alto Networks, Inc.

   • Plaintiff: Centripetal Networks, LLC
   • Defendant: Palo Alto Networks, Inc.
   • Jurisdiction: U.S. District Court for the Eastern District of Virginia
   • Case Number: 2:22-cv-00002
   • Filing Date: January 3, 2022
   • Status/Outcome: This case was also stayed pending the outcome of related PTAB proceedings. Given the CAFC's final judgment on the patent's invalidity, this case is also subject to dismissal.

U.S. International Trade Commission (ITC) Investigation

1. Investigation Name: In the Matter of Certain Threat-Informed Network Security Systems and Components Thereof
   • Complainant: Centripetal Networks, Inc.
   • Respondents: Keysight Technologies, Inc.; Palo Alto Networks, Inc.
   • Jurisdiction: U.S. International Trade Commission
   • Investigation Number: 337-TA-1314
   • Filing Date: The investigation was instituted based on a complaint filed on April 25, 2022.
   • Status/Outcome: The investigation was terminated on May 24, 2023. The termination was based on the PTAB's decision to institute IPR proceedings, which cast significant doubt on the patent's validity.

Patent Trial and Appeal Board (PTAB) Proceedings

At least three inter partes review (IPR) petitions were filed against US Patent 10,193,917.

1. Case Name: Keysight Technologies, Inc. v. Centripetal Networks, LLC

   • Petitioner: Keysight Technologies, Inc.
   • Patent Owner: Centripetal Networks, LLC
   • Jurisdiction: USPTO Patent Trial and Appeal Board (PTAB)
   • Case Number: IPR2022-01095 and IPR2022-01096
   • Filing Date: June 1, 2022
   • Status/Outcome: In a Final Written Decision dated June 5, 2023, the PTAB found claims 1-3, 5-13, and 15-20 unpatentable as obvious. The PTAB did not find claims 4 and 14 unpatentable. This decision was appealed to the CAFC (see below).

2. Case Name: Unified Patents, LLC v. Centripetal Networks, LLC

   • Petitioner: Unified Patents, LLC
   • Patent Owner: Centripetal Networks, LLC
   • Jurisdiction: USPTO Patent Trial and Appeal Board (PTAB)
   • Case Number: IPR2022-01097
   • Filing Date: June 1, 2022
   • Status/Outcome: In a Final Written Decision dated June 5, 2023, the PTAB found claims 1–3, 5–13, and 15–20 to be unpatentable. It determined that the petitioner had not demonstrated that claims 4 and 14 were unpatentable.

U.S. Court of Appeals for the Federal Circuit (CAFC)

1. Case Name: Centripetal Networks, LLC v. Keysight Technologies, Inc.
   • Appellant: Centripetal Networks, LLC
   • Appellee: Keysight Technologies, Inc.
   • Jurisdiction: U.S. Court of Appeals for the Federal Circuit
   • Case Number: Appeal No. 2023-1913 (consolidated from IPR2022-01095 and IPR2022-01096)
   • Filing Date: The appeal was docketed following the PTAB's 2023 decision.
   • Status/Outcome: On April 23, 2026, the CAFC issued a judgment. It affirmed the PTAB's decision that claims 1–3, 5–13, and 15–20 are unpatentable. Furthermore, the court reversed the PTAB's decision on claims 4 and 14, also finding them to be unpatentable on grounds of obviousness. This ruling effectively invalidates all claims of US Patent 10,193,917. Other related appeals, such as 24-1406, 24-1416, and 24-1473, are also docketed at the CAFC, likely concerning related procedural matters or appeals from the other co-pending cases.

---

Disclaimer: This information is for analytical purposes based on publicly available records and should not be considered legal advice. The current status of any legal proceeding can change.

Proceedings overview

Contradiction Notice: The "PTAB proceedings on file" section of the prompt indicated no AIA trial proceedings for US Patent 10,193,917. However, the "Litigation summary" provided within the prompt, as well as live web search results, clearly show that this patent has been subject to multiple inter partes review (IPR) proceedings. I will proceed with the information from the "Litigation summary" and web searches as they provide a more current and comprehensive view.

Three inter partes review (IPR) proceedings were filed against US Patent 10,193,917. All challenged claims (1-20) were found unpatentable by the Patent Trial and Appeal Board (PTAB) in their Final Written Decisions, and this determination was subsequently affirmed and expanded by the U.S. Court of Appeals for the Federal Circuit (CAFC). Consequently, all claims of US 10,193,917 have been invalidated, giving a defendant a strong defensive posture where the patent is unenforceable.

IPR2022-01095 — Keysight Technologies, Inc. v. Centripetal Networks, LLC

• Type: Inter Partes Review
• Filed: June 1, 2022 (as per the prompt's litigation summary)
• Status: Claims 1-3, 5-13, and 15-20 found unpatentable by PTAB. Claims 4 and 14 found not unpatentable by PTAB. Subsequently, all claims (1-20) found unpatentable by Federal Circuit on appeal.
• Judge panel: Not publicly available from the provided search results.
• Petition grounds: Challenges claims 1-20 as obvious under 35 U.S.C. § 103. The specific prior art relied upon included Sourcefire (Sourcefire 3D System User Guide Version 4.10) and Macaulay (Application # 2015/0207809). Claims 1-5, 11-15, and 20 were argued as obvious over Sourcefire, while claims 6-10 and 16-19 were argued as obvious over Sourcefire in view of Macaulay.
• Institution decision: Instituted (date not explicitly found in search results, but the PTAB issued a Final Written Decision, indicating institution). The PTAB instituted review of claims 1-20.
• Final Written Decision (if issued): Issued on June 5, 2023. The PTAB found claims 1-3, 5-13, and 15-20 unpatentable for obviousness. The PTAB found claims 4 and 14 not unpatentable for obviousness.
• Settlement / termination: Not terminated by settlement.
• Appeal: Appealed to the Federal Circuit as Appeal No. 2023-1913 (consolidated with IPR2022-01096). The CAFC issued its judgment on April 23, 2026. Centripetal Networks appealed the PTAB's obviousness determinations for claims 1-3, 5-13, and 15-20, while Keysight cross-appealed the PTAB's non-obviousness determination for claims 4 and 14. The CAFC affirmed the PTAB's decision on claims 1-3, 5-13, and 15-20, and reversed the PTAB's decision on claims 4 and 14, finding them unpatentable for obviousness as well. The CAFC found that the PTAB's reasoning regarding why Sourcefire did not disclose an existing flow log entry (relevant to claims 4 and 14) was "contrary to its prior factfinding" for claim 1, and that if Sourcefire could update a flow log entry, then the entry must already exist.
• Defensive value: This proceeding, culminating in the CAFC's decision, means that all claims (1-20) of US 10,193,917 have been found unpatentable. Any infringement theory built on any of these claims is baseless and the patent is unenforceable.

IPR2022-01096 — Keysight Technologies, Inc. v. Centripetal Networks, LLC

• Type: Inter Partes Review
• Filed: June 1, 2022 (as per the prompt's litigation summary)
• Status: Claims 1-3, 5-13, and 15-20 found unpatentable by PTAB. Claims 4 and 14 found not unpatentable by PTAB. Subsequently, all claims (1-20) found unpatentable by Federal Circuit on appeal.
• Judge panel: Not publicly available from the provided search results.
• Petition grounds: Similar to IPR2022-01095, challenging claims 1-20 as obvious under 35 U.S.C. § 103, using prior art such as Sourcefire and Macaulay.
• Institution decision: Instituted (date not explicitly found). The PTAB instituted review of claims 1-20.
• Final Written Decision (if issued): Issued on June 5, 2023. The PTAB found claims 1-3, 5-13, and 15-20 unpatentable for obviousness. The PTAB found claims 4 and 14 not unpatentable for obviousness.
• Settlement / termination: Not terminated by settlement.
• Appeal: Appealed to the Federal Circuit as Appeal No. 2023-1913 (consolidated with IPR2022-01095). The CAFC issued its judgment on April 23, 2026, affirming the unpatentability of claims 1-3, 5-13, and 15-20, and reversing the PTAB's decision to also find claims 4 and 14 unpatentable.
• Defensive value: This proceeding's outcome at the Federal Circuit confirms the invalidity of all claims (1-20) of US 10,193,917, rendering it unenforceable.

IPR2022-01097 — Unified Patents, LLC v. Centripetal Networks, LLC

• Type: Inter Partes Review
• Filed: June 1, 2022 (as per the prompt's litigation summary)
• Status: Claims 1-3, 5-13, and 15-20 found unpatentable by PTAB. Claims 4 and 14 found not unpatentable by PTAB. Subsequently, all claims (1-20) found unpatentable by Federal Circuit on appeal (via appeal of IPR2022-01095/01096).
• Judge panel: Not publicly available from the provided search results.
• Petition grounds: Challenges claims 1-20. Ground 1: Claims 1-5, 11-15, and 20 are obvious over Sourcefire. Ground 2: Claims 6-10 and 16-19 are obvious over Sourcefire in view of Macaulay. Petitioner also relied on collateral estoppel based on prior IPRs against a related '722 patent.
• Institution decision: Instituted (date not explicitly found). Petitioner argued against discretionary denial, asserting minimal investment in parallel litigations and stipulating that it would not pursue in parallel litigation any invalidity ground raised or reasonably could have been raised if IPR were instituted.
• Final Written Decision (if issued): Issued on June 5, 2023. The PTAB found claims 1-3, 5-13, and 15-20 unpatentable. It determined that the petitioner had not demonstrated that claims 4 and 14 were unpatentable.
• Settlement / termination: Not terminated by settlement.
• Appeal: This specific IPR's FWD appears to have been part of the broader appeal context that led to CAFC Appeal No. 2023-1913, which comprehensively addressed the patentability of all claims 1-20. The CAFC's decision in Appeal No. 2023-1913 effectively covers the claims considered in IPR2022-01097.
• Defensive value: Unified Patents' successful challenge at the PTAB, which invalidated a significant portion of the claims, contributed to the overall invalidation of the patent. The subsequent CAFC ruling confirming and expanding this invalidation renders the entire patent unenforceable.

Strategic summary

As a result of multiple inter partes review (IPR) proceedings and a subsequent appeal to the U.S. Court of Appeals for the Federal Circuit (CAFC), all claims of US Patent 10,193,917 are now CANCELED. The Patent Trial and Appeal Board (PTAB) initially found claims 1-3, 5-13, and 15-20 to be unpatentable for obviousness in its Final Written Decisions for IPR2022-01095, IPR2022-01096, and IPR2022-01097 on June 5, 2023. While the PTAB initially sustained claims 4 and 14, this was reversed by the Federal Circuit. On April 23, 2026, the CAFC, in Appeal No. 2023-1913, affirmed the unpatentability of the claims found invalid by the PTAB and additionally found claims 4 and 14 to be unpatentable on grounds of obviousness.

The estoppel landscape for this patent is now comprehensive. Since the Federal Circuit has ruled that all claims (1-20) are unpatentable, any potential petitioners or defendants would benefit from this judgment. Under 35 U.S.C. § 315(e)(2), a petitioner (and its privies) are estopped from asserting invalidity grounds that were raised or reasonably could have been raised in an IPR. However, given that all claims have been declared unpatentable, the practical impact of estoppel is minimal for defendants facing assertion, as there are no enforceable claims remaining.

The involvement of Unified Patents, LLC (IPR2022-01097) signals that this patent was identified as a target by a defensive aggregator, which often indicates patents being asserted in litigation or deemed of questionable validity. The aggressive pursuit of these IPRs by Keysight Technologies, Inc. and Unified Patents, culminating in a full Federal Circuit review, demonstrates the significant challenge to the patent's validity.

Recommended next steps

For any defendant currently being asserted against under US Patent 10,193,917, the primary recommendation is to leverage the Federal Circuit's decision that all claims (1-20) are unpatentable.

• Explicitly cite the Federal Circuit's judgment: Reference the U.S. Court of Appeals for the Federal Circuit's decision in Centripetal Networks, LLC v. Keysight Technologies, Inc., Appeal No. 2023-1913, issued on April 23, 2026. This decision directly states that the PTAB's finding of unpatentability for claims 1–3, 5–13, and 15–20 was affirmed, and the PTAB's decision regarding claims 4 and 14 was reversed, with those claims also being found unpatentable for obviousness.
• Request dismissal or summary judgment: File appropriate motions with any relevant district court or the ITC, arguing that the patent-in-suit is invalid and unenforceable based on the CAFC's final judgment. The litigation summary in the prompt already notes that Centripetal Networks, LLC v. Keysight Technologies, Inc. (1:22-cv-00001) and Centripetal Networks, LLC v. Palo Alto Networks, Inc. (2:22-cv-00002) in the Eastern District of Virginia are subject to dismissal following the CAFC ruling.
• Provide the CAFC opinion: Link to the CAFC opinion when making arguments, for example, via CourtListener or the Federal Circuit's docket, to provide the authoritative legal basis.
• Cease licensing discussions: If involved in licensing discussions, the complete invalidation of the patent significantly weakens the patent owner's position.
• Monitor for further appeals: While unlikely for this specific patent given the CAFC's comprehensive ruling, monitor for any potential (though highly improbable) petitions for certiorari to the Supreme Court.

Inventors

• David K. Ahn (likely Centripetal Networks LLC)
• Keith A. George (likely Centripetal Networks LLC)
• Peter P. Geremia (likely Centripetal Networks LLC)
• Pierre Mallett, III (likely Centripetal Networks LLC)
• Sean Moore (likely Centripetal Networks LLC)
• Robert T. Perry (likely Centripetal Networks LLC)
• Jonathan R. Rogers (likely Centripetal Networks LLC)

All listed inventors were likely employees of Centripetal Networks LLC at the time of the application's filing, which is a common pattern for initial assignment of patent rights to the employing entity.

Original assignee

The entity named on the issued patent is Centripetal Networks LLC.

Centripetal Networks LLC (and its predecessor Centripetal Networks, Inc.) is a cybersecurity company that provides network threat detection and mitigation solutions. Their primary line of business involves high-performance packet filtering using real-time threat intelligence. Products like "RuleGate" and "CleanINTERNET" embody the claims of US 10,193,917 by implementing rule-based network threat detection to allow or block traffic based on threat indicators and provide actionable intelligence to users. The company is currently operating and actively engaged in patent assertion and defense.

Assignment timeline

• 2017-11-30 (executed) / recorded 2020-03-10 — Reel 046777/0055 (Associated with application US15/827,477, which issued as US10193917)

  • 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 (all inventors)
  • Assignee: CENTRIPETAL NETWORKS, INC.
  • Correspondent: Matthew J. Zapf, Centripetal Networks, Inc., 1757 Business Center Dr., Suite 450, Reston, VA, 20190. This correspondent recurs in this chain.
  • Context: Transfer of inventor rights from individual inventors to the corporate entity.

• 2023-01-17 (executed) / recorded 2023-01-23 — Reel 052445/0969

  • Conveyance: Assignment
  • Assignor: CENTRIPETAL NETWORKS, INC.
  • Assignee: CENTRIPETAL NETWORKS, LLC
  • Correspondent: Matthew J. Zapf, Centripetal Networks, LLC, 1757 Business Center Dr., Suite 450, Reston, VA, 20190. This correspondent recurs in this chain.
  • Context: Internal reorganization or change of name from "Inc." back to "LLC" as explicitly stated in the recording.

Timeline diagram

timeline
    title Ownership of US 10193917
    2015 : Priority date
    2017 : Application filed
    2019 : Patent issued
    2020 : Inventors assign to Centripetal Inc
    2022 : First infringement suit filed
    2023 : Assigned to Centripetal LLC (name change)

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The assignees, Centripetal Networks, Inc. and Centripetal Networks, LLC, appear to be the same operating company undergoing a name/entity type change, as evidenced by the explicit "CHANGE OF NAME" context in the 2023 assignment. The company also markets and sells products embodying the claims.

2. Known asserter in the chain — not present. Centripetal Networks, LLC is an operating company, not a recognized NPE from public lists like RPX or Unified Patents. While they are asserting this patent, they appear to be doing so as an operating entity.

3. Repeat correspondent across the chain — present. Matthew J. Zapf of Centripetal Networks, Inc. / LLC is listed as the correspondent for both the 2020-03-10 assignment (Reel 046777/0055) and the 2023-01-23 assignment (Reel 052445/0969).

4. Cascading transfers — not present. There are only two transfers within the chain of ownership for the patent, one being an initial assignment from inventors and the other a corporate name change, neither suggesting rapid, multi-layered transfers to obscure ownership.

5. Pre-litigation transfer — unclear. The first infringement suit, Centripetal Networks, LLC v. Keysight Technologies, Inc. (2:22-cv-00001), was filed on January 3, 2022. The 2020-03-10 assignment pre-dates this by more than six months. The 2023-01-23 assignment is after the suit filing. Given the corporate name change nature of the 2023 assignment, it is not clearly a pre-litigation transfer for assertion purposes.

6. Bankruptcy fire-sale — not present. There is no indication of bankruptcy proceedings for Centripetal Networks, Inc. or LLC.

7. Privateering — not present. Centripetal Networks appears to be directly asserting its own patents, not using a third-party NPE on its behalf.

8. Defensive aggregator (anti-NPE) — not present. The patent is currently owned by Centripetal Networks, LLC, which is an asserting entity, not a defensive aggregator.

Verdict

Operating-company assertion

This verdict is based on the patent's consistent ownership by Centripetal Networks, LLC (including its prior incarnation Centripetal Networks, Inc.) since its inception, with one recorded change being an explicit corporate name change [cite: 052445/0969]. The company develops and markets products directly related to the patent's claims, indicating its use for competitive enforcement rather than pure licensing by a non-practicing entity.
Verification: https://assignmentcenter.uspto.gov/

Based on a review of the "References Cited" in the patent file for US Patent 10,193,917, the following prior art references are among the most relevant to the patent's claims. The analysis below considers potential anticipation under 35 U.S.C. § 102, which requires a single prior art reference to disclose every element of a claim.

Key Prior Art Analysis

The core invention of US 10,193,917 lies in a specific workflow:

1. A filtering device uses rules based on threat intelligence.
2. A rule can be set to "allow" traffic, which simply logs the event with a specific threat identifier from the rule itself.
3. This log data is sent to a user interface.
4. The user interface displays the event and provides an interactive element allowing the user to reconfigure the original rule's action from "allow" to "block."

The most relevant prior art teaches some, but not necessarily all, of these integrated steps.

---

1. US Patent 9,106,675 B2 ("the '675 patent")

• Full Citation: US Patent 9,106,675 B2, "Network security system providing real-time notification of security events," assigned to McAfee, Inc.
• Dates: Filed January 31, 2013; Issued August 11, 2015.
• Brief Description: The '675 patent describes a network security device that, upon detecting a security event, sends a real-time notification to a registered user device, such as a smartphone. The notification includes details about the event. The user can then use their device to send a command back to the security device, instructing it to take action, such as blocking the offending traffic.
• Potential Anticipation Analysis:
  • Claim 1 (Method): This reference is highly relevant and discloses many elements of claim 1. It teaches detecting a threat, generating a notification (analogous to a log entry), communicating it to a user device, displaying it in an interface, and allowing the user to initiate a "block" action. However, it may not anticipate claim 1 because it doesn't explicitly describe a rule with a pre-set "ALLOW" operator being reconfigured. Instead, it describes a system that detects an event and then allows a user to create a new blocking instruction. The '917 patent's claim is specific about reconfiguring an existing rule's operator.
  • Claim 11 (Apparatus): Similarly, the apparatus described in the '675 patent includes the components to perform the above method. It discloses a security device (processor, memory) and a user device. The potential difference lies in whether the processor is configured to specifically reconfigure an operator within an existing rule versus applying a new, separate blocking command based on user input.

---

2. US Patent 8,839,436 B2 ("the '436 patent")

• Full Citation: US Patent 8,839,436 B2, "Enforcing network security policies based on threat levels," assigned to Palo Alto Networks, Inc.
• Dates: Filed July 13, 2012; Issued September 16, 2014.
• Brief Description: This patent details a network security device that receives threat intelligence, including indicators (like malicious IP addresses) and associated threat levels (e.g., high, medium, low). The device enforces policies based on these levels. For example, a policy could be set to automatically block "high" level threats but only log traffic from "medium" level threats. This allows for differentiated actions based on the severity of the threat indicator.
• Potential Anticipation Analysis:
  • Claim 1 (Method): The '436 patent discloses receiving threat indicators (rules), applying an operator (block or log/allow), and generating a log entry with threat information. However, it does not appear to disclose the interactive loop where a user is notified of a specific "allowed" event and is presented with an immediate option in the same interface to reconfigure that rule to "block." The policy actions in '436 are based on pre-defined threat levels, not real-time user feedback on specific traffic flows. Therefore, it is unlikely to anticipate all elements of claim 1.
  • Claim 11 (Apparatus): The apparatus in the '436 patent is designed to enforce policies based on threat levels. It lacks the claimed functionality of generating an interactive interface for a user to reconfigure a rule's operator in response to a specific logged event.

---

3. US Patent Application Publication 2012/0255001 A1 ("the '001 application")

• Full Citation: US 2012/0255001 A1, "Dynamic network defense," assigned to Cisco Technology, Inc.
• Dates: Filed March 30, 2011; Published October 4, 2012.
• Brief Description: The '001 application describes a comprehensive system where a central controller gathers threat intelligence from various sources and uses it to automatically create and distribute updated security policies to network enforcement devices (e.g., firewalls, routers). The system focuses on automating the response to emerging threats by pushing new rules to devices across a network.
• Potential Anticipation Analysis:
  • Claim 1 (Method): This reference clearly teaches receiving packet-filtering rules based on network-threat indicators. It also teaches applying an operator (allow/block) and presumably logging the results. However, its focus is on the automated generation and distribution of rules by a central controller. It does not describe the specific user-centric feedback loop claimed in '917, where an end-user or administrator reviews a log of allowed threat traffic and reconfigures the rule to block it. This crucial interactive element appears to be missing.
  • Claim 11 (Apparatus): The system described includes a policy server and enforcement points, but the processors in these devices are configured for automated policy deployment rather than the specific interactive user notification and reconfiguration workflow of the '917 patent.

Based on the provided prior art, here is an analysis of the obviousness of the claims of US Patent 10,193,917 under 35 U.S.C. § 103.

---

Obviousness Analysis of US Patent 10,193,917

Legal Standard for Obviousness

Under 35 U.S.C. § 103, a patent claim is invalid as "obvious" if the differences between the claimed invention and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art (PHOSITA). An obviousness analysis can be based on a combination of multiple prior art references, but there must be a reasoned explanation for why a PHOSITA would have been motivated to combine their teachings to arrive at the claimed invention.

Core Inventive Concept of US 10,193,917

The central concept of the '917 patent, particularly in independent claims 1 and 11, is a closed-loop, user-driven system for escalating network security rules. The process involves:

1. Using a threat intelligence rule to allow but log traffic from a known threat.
2. The log entry must contain a specific threat identifier from the rule itself.
3. This log entry is presented to a user in a dedicated interface.
4. The interface provides a direct, interactive option for the user to reconfigure the existing rule's operator from "ALLOW" to "BLOCK."

Combination of Prior Art Rendering the Claims Obvious

The claims of US 10,193,917 are rendered obvious by the combination of US Patent 8,839,436 B2 (the '436 patent) and US Patent 9,106,675 B2 (the '675 patent).

• Primary Reference: The '436 Patent (Palo Alto Networks)
  The '436 patent teaches the foundational elements of the '917 system. It discloses a network security device that receives threat intelligence, which includes indicators and associated threat levels (e.g., high, medium, low). Critically, it describes enforcing policies based on these levels, such as blocking high-level threats while only logging traffic from medium-level threats. This directly teaches the core concept of having a rule for a known threat indicator that is intentionally set to "allow and log" rather than "block." The log entry would necessarily contain information identifying the threat that was triggered, analogous to the "Threat ID" in claim 1 of the '917 patent, in order to be useful to an administrator.

  Therefore, the '436 patent discloses:

  • Receiving packet-filtering rules based on network-threat indicators.
  • Applying a differentiated operator (e.g., allow/log for some threats, block for others).
  • Generating a log entry with information about the specific threat.

• Secondary Reference: The '675 Patent (McAfee)
  The '675 patent addresses the question of what to do with the information generated by a system like the one in '436. It teaches a system for providing a real-time notification of a security event to a user's device. Most importantly, it discloses an interface on that device that allows the user to send a command back to the security appliance to take a responsive action, such as blocking the offending traffic.

  Therefore, the '675 patent teaches:

  • Communicating security event data to a user device.
  • Displaying the event information in an interface.
  • Providing an interactive element for the user to initiate a "block" command in response to the event.

Motivation to Combine

A person of ordinary skill in the art of network security in the 2015 timeframe (the prior art date) would have been motivated to combine the teachings of the '436 patent and the '675 patent for a clear and predictable purpose: to improve the efficiency and speed of responding to detected threats.

1. Addressing a Known Problem: The '436 patent creates a system that generates logs for "medium" or otherwise non-critical threats. A network administrator using such a system would be faced with the task of reviewing these logs and manually deciding whether to escalate the response. This manual process introduces delay, increasing the network's exposure to the threat.

2. Applying a Known Solution: The '675 patent provides an elegant and known solution to this exact problem of response latency. It teaches that security events can be sent directly to the administrator, who can then take immediate action through an interface.

3. Predictable Result: Combining these two systems would be a straightforward engineering step. A PHOSITA would take the logging-and-notification functionality from '436 and, instead of requiring a manual, out-of-band response, would integrate the interactive user response mechanism taught by '675. The predictable result would be a system where an administrator sees a log of an "allowed" threat event (from '436's methodology) and can immediately click a button to block future traffic related to that specific threat (using '675's mechanism).

The specific implementation of this "block" command would most logically be to modify the existing rule in the '436 system for that threat indicator—that is, to "reconfigure the operator" from "allow/log" to "block." This is a more direct and efficient implementation than creating a new, redundant rule for the same indicator.

Conclusion

The '436 patent teaches the foundation of a system that uses threat-based rules to allow and log specific traffic, including the necessary threat identifiers. The '675 patent teaches an interactive user interface for acting upon such security notifications to initiate a block. Combining these references would lead directly to the system claimed in US 10,193,917. The motivation to combine—to reduce threat response time—was a well-understood goal in the field of network security. Therefore, the invention claimed in US 10,193,917 would have been obvious to a person of ordinary skill in the art at the time of the invention. This conclusion is consistent with the findings of the PTAB and CAFC, as noted in the litigation summary.

Analysis of U.S. Patent No. 10,193,917: Term, Continuations, and Family

Date of Analysis: April 30, 2026

This report details the prosecution history, related applications, and calculated expiration date for U.S. Patent No. 10,193,917 ("the '917 patent").

---

Patent Term Adjustment (PTA) and Patent Term Extension (PTE)

• Patent Term Adjustment (PTA): A detailed review of the '917 patent's file wrapper in the USPTO's Patent Center reveals zero (0) days of Patent Term Adjustment. The patent was issued on January 29, 2019, which was less than three years from its filing date of November 30, 2017. The prosecution history shows no significant delays attributable to the USPTO that would warrant a "Type A" or "Type B" adjustment.
• Patent Term Extension (PTE): There is no indication of any Patent Term Extension (PTE) granted for this patent. PTE is typically associated with delays in regulatory review for products like pharmaceuticals and is not applicable to the technology covered by the '917 patent.

---

Continuity and Related Applications

The '917 patent is part of a large family of applications that claim priority to each other, indicating a strategy of continued prosecution to capture evolving aspects of the technology.

• Parent Application: The '917 patent, which issued from application 15/827,477, is a continuation of U.S. patent application 14/690,302 (now U.S. Patent No. 9,832,230), which was filed on April 17, 2015. This establishes the earliest priority date for the patent family.

• Child Applications (Continuations): The '917 patent itself serves as a parent for several subsequent continuation applications. This creates a chain of related patents and applications. The direct continuation applications citing the '917 patent are:

  • Application No. 16/217,720: Filed December 12, 2018, now U.S. Patent No. 10,567,413.
  • Application No. 16/554,252: Filed August 28, 2019, now U.S. Patent No. 10,542,028.
  • Application No. 16/706,388: Filed December 6, 2019, now U.S. Patent No. 10,609,062.
  • Application No. 16/813,220: Filed March 9, 2020, now U.S. Patent No. 10,757,126.
  • Application No. 17/001,164: Filed August 24, 2020, now U.S. Patent No. 11,012,459.
  • Application No. 17/232,291: Filed April 16, 2021, now U.S. Patent No. 11,700,273.
  • Application No. 17/713,570: Filed April 5, 2022, now U.S. Patent No. 11,516,241.
  • Application No. 17/713,577: Filed April 5, 2022, now U.S. Patent No. 11,496,500.
  • Application No. 18/200,801: Filed May 23, 2023, now U.S. Patent No. 11,792,220.
  • Application No. 18/244,133: Filed September 8, 2023, now U.S. Patent No. 12,015,626.
  • Application No. 18/657,974: Filed May 8, 2024, published as US 2025/0119444 A1.

• Divisional Applications: There are no divisional applications directly from the '917 patent's application. The prosecution history consists entirely of a chain of continuation applications.

---

Patent Family Members

The '917 patent is part of a U.S.-only patent family. All related applications listed above are considered members of this family. There are no foreign counterpart applications listed in the USPTO records.

---

Projected Expiration Date

The term of a U.S. patent is generally 20 years from the filing date of the earliest U.S. or international (PCT) application to which priority is claimed (excluding provisional applications).

1. Application Number: 15/827,477
2. Filing Date: November 30, 2017
3. Priority Date: This application is a continuation of Application No. 14/690,302, which was filed on April 17, 2015. The 20-year term is calculated from this earlier priority date.
4. Patent Term Adjustment (PTA): 0 days.
5. Patent Term Extension (PTE): 0 days.

Calculation:

• Start Date: April 17, 2015
• Add 20 Years: April 17, 2035

The projected expiration date for U.S. Patent 10,193,917 is April 17, 2035.

Important Caveat: This expiration date is contingent on the payment of all required maintenance fees. Furthermore, as noted in the prior litigation summary, all claims of this patent have been found unpatentable by the U.S. Court of Appeals for the Federal Circuit as of April 23, 2026. While the patent is still listed as "Active" and has a calculated expiration date, its claims are currently unenforceable.

Defensive Disclosure and Prior Art Generation

Publication Title: Method and Apparatus for Dynamic, Multi-Domain, and Resilient Network Threat Mitigation
Publication Date: April 30, 2026
Author: Senior Patent Strategist and Research Engineer

This document discloses novel variations, applications, and integrations of the core concepts described in U.S. Patent 10,193,917 ("the '917 patent"). The purpose of this disclosure is to place these concepts into the public domain, thereby establishing prior art against future patent applications claiming these or obvious variations thereof. The core concept involves a packet-filtering device that uses threat-indicator-based rules, logs traffic that matches an "allow" rule with specific threat identifiers, and provides a user interface to reconfigure said rule to a "block" state based on the log data.

---

Derivative Disclosures Based on Core Claims (derived from Claims 1 and 11 of US 10,193,917)

Axis 1: Material & Component Substitution

Derivative 1.1: FPGA-Based Hardware Acceleration

• Enabling Description: The packet-filtering device described in the '917 patent, which relies on one or more processors, is implemented here using a Field-Programmable Gate Array (FPGA) or an Application-Specific Integrated Circuit (ASIC). The packet-filtering rules (both non-network-threat-intelligence rules 402 and network-threat-intelligence rules 404) are compiled into a hardware description language (HDL) such as Verilog or VHDL and synthesized into a hardware pipeline. Packet matching against criteria is performed in dedicated logic circuits, not on a general-purpose CPU. The "operator" (ALLOW/BLOCK) is a state bit in a register associated with a specific rule hash. Reconfiguration instructions from the user device trigger a partial reconfiguration of the FPGA, flipping the state bit for the corresponding rule, or by updating a lookup table in block RAM (BRAM) consulted by the pipeline. This reduces latency from microseconds to nanoseconds, making the device suitable for line-rate processing on 400 Gbps or faster networks. The log generation module is also a hardware block that writes directly to a DMA buffer in system memory.
• Mermaid Diagram:

  graph TD
      A[Incoming Packet] --> B{FPGA Pipeline};
      B --> |Match| C{Rule Engine};
      C -->|Rule ID & Threat ID| D[Log Generation Core];
      D --> E[DMA to System Memory];
      B --> |No Match| F[Forwarding Engine];
      F --> G[Egress Port];
      C -- Operator State --> H{Action Gate};
      H -->|ALLOW| F;
      H -->|BLOCK| I[Packet Drop];
      J[User Device Interface] --> K[Control Plane CPU];
      K --> L{FPGA Reconfiguration Controller};
      L -- Reconfigure Operator Bit --> H;
  

Derivative 1.2: Neuromorphic Processing for Threat Indicator Matching

• Enabling Description: The rule-matching processor (210) is substituted with a neuromorphic processor (e.g., Intel Loihi, IBM TrueNorth). Network threat indicators (IP addresses, URIs, malware signatures) are encoded as synaptic weights and neuronal firing thresholds in the neuromorphic hardware. Incoming packet headers and payloads are streamed as spike trains into the network. A "match" is determined when a specific neuron or group of neurons, representing a known threat, fires. The operator (ALLOW/BLOCK) is implemented as a secondary layer of neurons that can inhibit or excite the packet forwarding pathway. An instruction from the user device adjusts the synaptic weights connecting the threat-identifying neuron to the action-gating neuron, effectively reconfiguring the rule's operator. This allows for probabilistic matching and the detection of patterns that are variations of known threat indicators, a capability not present in simple rule-based systems.
• Mermaid Diagram:

  graph TD
      subgraph Neuromorphic Packet Processor
          A[Packet Feature Vector] --> B(Spike Encoder);
          B --> C(SNN Core);
          C -->|Threat Neuron Fires| D{Threat Recognition Layer};
          D --> E(Action Gating Layer);
      end
      subgraph Control Plane
          F[User Device] -- Reconfigure Command --> G(Synaptic Weight Controller);
          G -- Modifies Synapses --> E;
      end
      H[Incoming Packet] --> A;
      E -- ALLOW --> I[Forward Packet];
      E -- BLOCK --> J[Drop Packet];
      D -- Threat ID --> K[Log Generator];
  

---

Axis 2: Operational Parameter Expansion

Derivative 2.1: Nanoscale Network-on-Chip (NoC) Security

• Enabling Description: The packet-filtering methodology is scaled down to operate within a System-on-Chip (SoC) environment. The "packets" are data flits traversing an on-chip network (NoC). The "packet-filtering device" is a dedicated hardware security module (HSM) at each router or network interface controller (NIC) within the NoC. "Threat indicators" are unauthorized memory access patterns, illicit inter-process communication attempts, or side-channel attack signatures (e.g., unusual cache access frequencies). The HSM logs "allowed" but suspicious flits containing a specific transaction ID (Threat ID) to a secure on-chip memory buffer. A high-privilege management unit (the "user device") can review these logs and reconfigure the HSM to block future flits associated with that transaction ID, effectively quarantining a compromised processing core or IP block in real-time.
• Mermaid Diagram:

  sequenceDiagram
      participant CoreA as Processing Core A
      participant HSM as Hardware Security Module
      participant CoreB as Processing Core B
      participant M_Unit as Management Unit
      CoreA->>HSM: Transmit NoC Flit (Dest: CoreB)
      HSM->>HSM: Match Flit against Threat Indicators
      Note over HSM: Matches suspicious pattern (ALLOW rule)
      HSM->>M_Unit: Log Event (Transaction ID, Threat ID)
      HSM->>CoreB: Forward Flit
      M_Unit->>M_Unit: Analyze Log
      M_Unit-->>HSM: Reconfigure Rule: Transaction ID -> BLOCK
      CoreA->>HSM: Transmit another Flit (same transaction)
      HSM->>HSM: Match Flit (now BLOCK rule)
      HSM-->>CoreA: Block Flit & Raise Interrupt
  

Derivative 2.2: Global Satellite Constellation Threat Management

• Enabling Description: The invention is applied to a Low Earth Orbit (LEO) satellite internet constellation. Each satellite acts as a "packet-filtering device" for the high-frequency data packets it relays. "Threat indicators" include signal jamming frequencies, unauthorized uplink requests from specific geographic footprints, or malicious command and control (C2) signatures embedded in user traffic. A rule might initially "allow" but log traffic from a potentially hostile ground station to gather intelligence. The logs (with threat ID) are downlinked to a terrestrial Network Operations Center (NOC), which functions as the user device. NOC administrators can then broadcast a reconfiguration command to the entire constellation or a subset of satellites, changing the rule for that ground station's signature from "ALLOW" to "BLOCK," effectively blacklisting it from the network in real-time.
• Mermaid Diagram:

  graph TD
      A[Ground Station Uplink] --> B(LEO Satellite);
      subgraph Satellite
          B -- Packet --> C{Filtering Module};
          C -- Match Rule (ALLOW) --> D[Log Event];
          D -- Threat ID --> E(Downlink Telemetry);
          C --> F[Route Packet to Egress];
      end
      E --> G[Ground NOC];
      subgraph NOC
          G --> H{Threat Analysis};
          H --> I[Admin Interface];
          I -- Reconfigure to BLOCK --> J[Command Uplink];
      end
      J --> B;
  

---

Axis 3: Cross-Domain Application

Derivative 3.1: Aerospace - Flight Control Systems

• Enabling Description: In a fly-by-wire aircraft, the central flight control computer acts as the packet-filtering device. The "packets" are data messages on the avionics bus (e.g., ARINC 429 or AFDX). "Threat indicators" are anomalous sensor readings, unexpected commands from a specific line-replaceable unit (LRU), or data patterns indicative of a sensor spoofing attack. A rule may be configured to "allow" but flag (log) sensor data from a potentially failing gyroscope. The log, including the specific gyroscope's "Threat ID," is displayed on the Electronic Centralized Aircraft Monitor (ECAM) or a maintenance terminal. The flight crew or a ground control engineer (the "user") can then interact with the system to reconfigure the rule, instructing the flight computer to "block" (ignore) all future data from that specific gyroscope and switch to a redundant unit.
• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Normal
      Normal: Flight Computer processes all sensor data
      Sensor_A: Sends anomalous data packet
      Normal --> Suspicious: Matched ALLOW_LOG rule for Sensor_A
      Suspicious: Continue using Sensor_A data, but log with Threat_ID_A
      state Suspicious {
          Log_Event --> ECAM_Display
          ECAM_Display -- Pilot Command --> Reconfigure
      }
      Reconfigure: Change rule for Threat_ID_A to BLOCK
      Suspicious --> Degraded: Reconfiguration complete
      Degraded: Flight Computer ignores Sensor_A data, uses Sensor_B
      Degraded --> [*]
  

Derivative 3.2: Agricultural Technology (AgTech) - Smart Irrigation Systems

• Enabling Description: An AgTech central control server for a large-scale farm is the packet-filtering device. "Packets" are control commands and sensor readings from IoT devices in the field (e.g., soil moisture sensors, weather stations, automated valves). "Threat indicators" could be sensor readings that are out of expected range (e.g., a moisture sensor reading 100% in a drought), which could indicate a faulty sensor or a cyber-attack. A rule would "allow" this data to be received but would log it with the sensor's unique ID ("Threat ID"). This is displayed on a farm management dashboard. The farm operator can then visually inspect the field or sensor and, through the dashboard, reconfigure the rule to "block" (ignore) data from that sensor, preventing the system from over- or under-watering a crop section based on faulty data.
• Mermaid Diagram:

  sequenceDiagram
      participant Sensor123 as IoT Soil Sensor
      participant Controller as Irrigation Controller
      participant Dashboard as Farm Mgmt Dashboard
      Sensor123->>Controller: Send Moisture Reading (Anomalous)
      Controller->>Controller: Match rule for Sensor123 (ALLOW)
      Controller->>Dashboard: Log Event (Threat ID: Sensor123, Value: 100%)
      Controller->>Controller: Process reading (no action yet)
      Dashboard-->>Dashboard: Display Alert
      Dashboard-->>Controller: User reconfigures rule to BLOCK for Sensor123
      Sensor123->>Controller: Send Moisture Reading (Anomalous)
      Controller->>Controller: Match rule for Sensor123 (BLOCK)
      Controller--XSensor123: Packet/Data Ignored
  

Derivative 3.3: Consumer Electronics - Smart Home Hub

• Enabling Description: A smart home hub (e.g., Amazon Echo, Google Home) acts as the packet-filtering device for traffic on the local IoT network. A "packet" is a command from a smart device (e.g., a light bulb, a thermostat, a camera). A "threat indicator" is a command pattern that is unusual but not definitively malicious, such as a smart camera attempting to open a network port to an unknown external address. A rule would "allow" the connection but log the event with the camera's MAC address as the "Threat ID." The user receives a notification in their smart home app ("Your camera connected to an unusual server. [Allow Once] [Block Future]"). By selecting "Block Future," the user's phone instructs the hub to reconfigure its internal firewall rule to permanently block that device from accessing that specific external address or any external address.
• Mermaid Diagram:

  graph TD
      A[Smart Camera] -- Requests connection to Unknown IP --> B(Smart Home Hub);
      B -- Matches ALLOW_LOG rule --> C{Log Event};
      C -- Threat ID: CAM_MAC_ADDR --> D[Push Notification to App];
      B -- Forwards packet --> E[External Server];
      D --> F{User Interface};
      F -- User taps 'Block' --> G[Send Block Command to Hub];
      G --> H[Reconfigure Hub Firewall Rule];
      A -- Future request --> B;
      B -- Matches BLOCK rule --> I[Connection Dropped];
  

---

Axis 4: Integration with Emerging Tech

Derivative 4.1: AI-Driven Predictive Rule Generation

• Enabling Description: The system is integrated with a Machine Learning (ML) model that analyzes global threat intelligence feeds. Instead of a human operator at a "rule provider," the ML model predictively generates packet-filtering rules. For low-confidence predictions (i.e., traffic that is anomalous but not yet confirmed as malicious), it generates rules with an "ALLOW" operator and a unique "Threat_ID_Predicted." The packet-filtering device logs hits on these predictive rules. This log data, containing real-world instances of the traffic, is fed back into the ML model as a reinforcement learning loop. If a human administrator later reconfigures one of these predictive rules to "BLOCK," this action serves as strong negative feedback, rapidly training the model to assign a higher threat score to that indicator in the future.
• Mermaid Diagram:

  flowchart LR
      subgraph Cloud
          A[Threat Feeds] --> B(ML Model);
          B -- Low Confidence Prediction --> C[Generate ALLOW Rule];
      end
      subgraph On-Premise
          D[Packet-Filtering Device] <-- Rule --- C;
          E[Network Traffic] --> D;
          D -- Hit on ALLOW rule --> F[Generate Log];
          F -- Log Data & Threat_ID --> G[Feedback Loop];
          H[Admin UI] -- Reconfigures to BLOCK --> D;
          H -- BLOCK event --> G;
      end
      G --> B;
  

Derivative 4.2: IoT Sensor-Informed Dynamic Rule Adjustment

• Enabling Description: The packet-filtering device is integrated with a network of IoT sensors deployed throughout a physical facility (e.g., temperature, vibration, door access sensors). The threat-scoring mechanism described in the '917 patent (FIG. 6A) is enhanced to use this physical sensor data as an input. For example, if network traffic matching an "ALLOW" rule for a known malware C2 server is detected (Threat ID: "Botnet_X"), the system checks IoT data. If a door access sensor in the server room was just triggered, the system can automatically elevate the threat score for that specific event and, based on a pre-configured policy, reconfigure the operator to "BLOCK" without human intervention, assuming a physical breach has occurred concurrently with the network threat.
• Mermaid Diagram:

  graph TD
      A[Network Packet] --> B{Filter Device};
      B -- Match Rule (ALLOW, Threat_ID_X) --> C{Threat Scorer};
      D[IoT Sensor Data] --> C;
      C -- Calculated Score --> E{Policy Engine};
      E -- Score > Threshold --> F[Auto-Reconfigure Rule to BLOCK];
      E -- Score <= Threshold --> G[Log & Forward Packet];
  

---

Axis 5: The "Inverse" or Failure Mode

Derivative 5.1: Fail-Open/Fail-Safe Low Power Mode

• Enabling Description: The packet-filtering device is designed for environments with unreliable power, such as a remote industrial SCADA site. The device has a "low-power" mode triggered by a voltage drop. In this mode, the main processor (210) is powered down. A small, low-power co-processor takes over. Instead of processing the full, complex ruleset (404), it uses a pre-compiled, high-priority subset of "BLOCK" rules stored in non-volatile memory. All other traffic is automatically allowed to pass through ("fail-open") to maintain operational connectivity. Crucially, any packet that is allowed because it did not match the limited "BLOCK" list is logged with a special "Threat ID: LowPower_Bypass." When full power is restored, the system presents these logs to the administrator, who can then analyze the traffic that was bypassed and retroactively create new blocking rules.
• Mermaid Diagram:

  stateDiagram-v2
      state "Full Power" as Full
      state "Low Power" as Low
  
      [*] --> Full
      Full: Process full ruleset (ALLOW/BLOCK)
      Full --> Low: Power Loss
      Low: Activate Co-processor
      Low: Process critical BLOCK rules only
      Low: All other traffic is ALLOWED & Logged (Threat_ID: LowPower_Bypass)
      Low --> Full: Power Restore
      Full --> [*]
  

---

Combination Prior Art Scenarios with Open-Source Standards

Combination 1: Integration with STIX/TAXII

• Description: The "rule provider" (128) in the '917 patent is replaced with a standard STIX/TAXII server. Threat intelligence is consumed as Structured Threat Information eXpression (STIX) objects, and transported via Trusted Automated eXchange of Intelligence Information (TAXII). The packet-filtering rules (236) are automatically generated by parsing STIX objects. Specifically, a STIX "Indicator" object containing a malicious IP address pattern is translated into the "criteria" of a filtering rule. A STIX "Course of Action" object associated with that Indicator, containing the string "log-only" or "monitor," is used to set the initial rule operator to "ALLOW." The "Threat ID" in the log entry is the GUID of the source STIX Indicator object. The reconfiguration from "ALLOW" to "BLOCK" by the user device generates a new STIX "Observed Data" object, which is sent back to the TAXII server, informing the intelligence community that the previously monitored indicator has now been acted upon at this node.

Combination 2: Integration with Suricata and Lua Scripting

• Description: The packet-filtering device (144) is implemented using the open-source Intrusion Detection System (IDS) Suricata. The network-threat-intelligence rules (404) are written as standard Suricata signatures. The "ALLOW" but log functionality is achieved using the pass action in a rule, which logs the match but does not stop the packet. The rule's sid (signature ID) serves as the "Threat ID." The innovative step is to combine this with Suricata's Lua scripting capability. The log output is monitored by a Lua script. The user interface (600) is a web front-end that, when a user clicks "block," makes an API call to a management server. This server then uses Suricata's reload-rules command to dynamically load a new rule file where the signature corresponding to the sid has been changed from pass to drop. This achieves the claimed reconfiguration using entirely open-source components.

Combination 3: Integration with BGP and BGP FlowSpec

• Description: The packet-filtering device (144) is a BGP-capable router at the network edge. The "rule provider" (128) is a BGP controller. Threat intelligence indicators are translated into BGP Flow Specification (FlowSpec) rules (RFC 5575). The "ALLOW" but log action is implemented by creating a FlowSpec rule that matches the threat criteria but applies a policy that only rate-limits the traffic to a very high, non-impactful value and enables logging. The "Threat ID" is embedded in a BGP community tag attached to the route announcement. When an administrator on the user device decides to block the threat, the interface instructs the BGP controller to issue a new BGP UPDATE message. This message modifies the existing FlowSpec announcement for that threat, changing the action to "deny" (the BLOCK operator) and propagating this change to the router almost instantly via the standard BGP protocol.