Derivative works — US Patent 10193917

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.