Derivative works

Defensive Disclosure and Prior Art Derivations for US 12,301,628

Document ID: DPD-2026-0426-001
Publication Date: May 1, 2026
Subject: Defensive Publication regarding "Correlating network event anomalies using active and passive external reconnaissance to identify attack information."
Related Art: U.S. Patent 12,301,628 B2

This document discloses novel variations, extensions, and applications of the methods and systems described in US Patent 12,301,628 B2. The intent of this publication is to place these concepts into the public domain, thereby establishing them as prior art.

---

Derivations Based on Independent Claim 1: Method

The core method involves creating a cyber-physical graph (CPG), modeling normal behavior, detecting anomalies, generating a behavior graph, and traversing it to find an attack's origin. The following are derivative implementations and applications.

Axis 1: Material & Component Substitution

1.1. In-Memory CPG with Probabilistic Data Structures

• Enabling Description: For high-velocity, low-latency environments like high-frequency trading or industrial control systems (ICS), the CPG is implemented not in a persistent graph database but as an in-memory data structure using a combination of Adjacency Lists and Hash Maps for O(1) average time complexity for node and edge lookups. To manage the immense scale and reduce memory footprint, node properties and edge weights are stored using probabilistic data structures. For example, HyperLogLog is used to estimate the cardinality of connections from a given node, and Bloom filters are used to quickly test for the existence of specific user permissions or vulnerability flags without storing the full data set. Anomaly detection thresholds are dynamically adjusted based on the memory pressure and the calculated error rates of the probabilistic structures.
• Mermaid Diagram:

  graph TD
      A[Data Stream: NetFlow, Syslog, etc.] --> B{Stream Processor: Flink/Kafka};
      B --> C[CPG Builder];
      C --> D{In-Memory Graph<br>Adjacency Lists + HashMaps};
      C --> E{Probabilistic Metadata<br>HyperLogLog: Connection Cardinality<br>Bloom Filter: Asset Properties};
      D -- Query --> F[Anomaly Detection Engine];
      E -- Query --> F;
      F -- Anomaly Found --> G[Behavior Graph Constructor];
      G -- Traverses --> D;
      G --> H[Output: Attack Path];
  

1.2. Relational Database Implementation with Recursive CTEs

• Enabling Description: The CPG is implemented in a standard SQL-based Relational Database Management System (RDBMS). Nodes (entities) and edges (relationships) are stored in separate tables. For example, a nodes table with (node_id, node_type, properties_json) and an edges table with (edge_id, source_node_id, target_node_id, relationship_type, weight). Graph traversal, including the backward temporal analysis of the behavior graph, is performed using Recursive Common Table Expressions (CTEs). This approach leverages the ubiquity and transactional integrity of RDBMSs. The "normal behavior model" is stored in materialized views, which are periodically refreshed, containing aggregated statistics (e.g., average daily connections, standard deviation of data transfer size) for each node pair.
• Mermaid Diagram:

  erDiagram
      NODES {
          int node_id PK
          varchar node_type
          json properties
      }
      EDGES {
          int edge_id PK
          int source_node_id FK
          int target_node_id FK
          varchar relationship_type
          float weight
      }
      NORMAL_BEHAVIOR_MODEL {
          int source_node_id FK
          int target_node_id FK
          varchar metric_name
          float avg_value
          float std_dev
      }
      NODES ||--o{ EDGES : has_source
      NODES ||--o{ EDGES : has_target
      NODES ||--o{ NORMAL_BEHAVIOR_MODEL : source_of
      NODES ||--o{ NORMAL_BEHAVIOR_MODEL : target_of
  

---

Axis 2: Operational Parameter Expansion

2.1. Nanoscale Biological System Monitoring

• Enabling Description: The method is applied to model and monitor intracellular protein-protein interaction (PPI) networks. Nodes in the CPG represent individual proteins, protein complexes, or genes. Edges represent known biochemical interactions (e.g., phosphorylation, binding, gene regulation) with weights derived from experimental confidence scores. "Reconnaissance" involves ingesting data from high-throughput screening, mass spectrometry, and gene expression assays to build a baseline model of normal cellular function. An "anomalous event" could be the unexpected expression of an oncogene or a change in phosphorylation cascade timing, triggered by a pathogen or a chemical agent. The system then generates a behavior graph of the anomalous pathway and traverses it backward to identify the potential root-cause protein or genetic mutation responsible for the pathological state.
• Mermaid Diagram:

  graph LR
      subgraph "Cellular Environment"
          P1(Protein A)
          P2(Protein B)
          G1(Gene X)
          P3(Enzyme C)
      end
  
      subgraph "Pathological Event"
          style Anomaly fill:#f99,stroke:#333,stroke-width:2px
          Anomaly(Oncogene O Activation)
      end
  
      G1 -- Expresses --> P1
      P1 -- Binds --> P2
      P2 -- Activates --> P3
      P3 -- Phosphorylates --> P1
      Anomaly -- Up-regulates --> G1
  
      subgraph "Behavior Graph (Traceback)"
          style Traceback fill:#ccf,stroke:#333,stroke-width:2px
          G1_T(Gene X)
          P1_T(Protein A)
          P2_T(Protein B)
          Anomaly_T(Oncogene O)
  
          P2_T -- Was Activated By --> P1_T
          P1_T -- Was Expressed By --> G1_T
          G1_T -- Was Up-regulated By --> Anomaly_T
      end
  

2.2. Global-Scale Supply Chain Logistics

• Enabling Description: The CPG maps the entire global supply chain of a multinational corporation. Nodes represent suppliers, factories, warehouses, shipping vessels, individual shipping containers (with IoT trackers), and destination ports. Edges represent logistical relationships (e.g., "supplies_parts_to", "transports_from_to", "stored_at"). The normal behavior model is built from years of historical shipping data, bills of lading, and real-time GPS feeds. An anomaly could be a container deviating from its standard shipping lane, a supplier's factory going offline unexpectedly, or a sudden spike in customs clearance times at a specific port. The system correlates this event with other data (e.g., weather patterns, geopolitical news feeds, other shipment delays) to build a behavior graph of the disruption's impact. It then traces the dependencies backward to identify the root cause—be it a storm, a labor strike, or a material shortage—and proposes rerouting or sourcing alternatives.
• Mermaid Diagram:

  sequenceDiagram
      participant Supplier A
      participant Factory B
      participant Vessel C
      participant Port D
      participant CPG_System as CPG System
  
      CPG_System->>+Vessel C: Monitor GPS Ping
      activate Vessel C
      Note right of Vessel C: Normal Route
      Vessel C-->>-CPG_System: Position(lat, lon)
      CPG_System->>+Vessel C: Monitor GPS Ping
      activate Vessel C
      Note right of Vessel C: ANOMALY: Deviation > 50nm
      Vessel C-->>-CPG_System: Position(lat_new, lon_new)
      CPG_System->>CPG_System: 1. Identify Anomaly
      CPG_System->>CPG_System: 2. Correlate with other nodes (Container #123, Destination Port D)
      CPG_System->>CPG_System: 3. Generate Behavior Graph (Impact on Port D ETA)
      CPG_System->>CPG_System: 4. Traceback: Query external data (weather, news) for cause.
      CPG_System-->>Port D: Alert: Shipment for Factory B delayed. Predicted Cause: Tropical Storm.
  

---

Axis 3: Cross-Domain Application

3.1. Aerospace: Satellite Constellation Health Management

• Enabling Description: The system monitors a low-Earth orbit (LEO) satellite constellation. The CPG represents each satellite as a node, with sub-nodes for key components (power, comms, propulsion, payload). Edges represent communication links and orbital proximity. Passive reconnaissance involves collecting continuous telemetry (voltages, temperatures, fuel levels, data throughput). Active reconnaissance involves periodic diagnostic pings. A normal behavior model captures orbital decay rates, solar panel degradation, and battery charge cycles. An anomaly could be a sudden drop in battery voltage on one satellite. The system correlates this with solar flare alerts (external data), the satellite's position relative to the sun, and the status of neighboring satellites. The behavior graph shows the potential impact on network coverage. Tracing back might reveal the cause isn't the battery itself but a malfunctioning sun-tracking sensor (the root cause), allowing for a targeted software patch.
• Mermaid Diagram:

  graph TD
      subgraph CPG
          Sat1(Satellite 1)
          Sat1_Pwr(Power Subsystem)
          Sat1_Comm(Comms Subsystem)
          Sat1_Sun(Sun Sensor)
          Sat1 -- contains --> Sat1_Pwr & Sat1_Comm & Sat1_Sun
  
          Sat2(Satellite 2)
          Sat1 -- CommLink --> Sat2
      end
  
      subgraph DataFeeds
          Telemetry(Real-time Telemetry)
          SpaceWeather(NOAA Space Weather)
      end
  
      Telemetry --> AnomalyDetector
      SpaceWeather --> AnomalyDetector
  
      subgraph Analysis
          AnomalyDetector -- Low Voltage on Sat1_Pwr --> CorrelationEngine
          CorrelationEngine -- Analyzes CPG --> BehaviorGraph
          BehaviorGraph -- Traces back --> RootCause(Faulty Sat1_Sun Sensor)
      end
  

3.2. AgTech: Smart Farm Pest and Disease Outbreak Forensics

• Enabling Description: The CPG models a large-scale agricultural operation. Nodes include fields, crop sections, individual IoT soil sensors, irrigation valves, weather stations, and drone imaging platforms. Edges represent physical adjacency, water flow, and data connectivity. The "normal behavior model" is built from multispectral imagery, soil moisture readings, and historical yield data, defining healthy crop growth patterns. An anomaly is detected when a drone's NDVI (Normalized Difference Vegetation Index) scan reveals a localized area of crop stress. The system correlates this with data from nearby soil sensors (e.g., high salinity), irrigation valve logs (e.g., stuck valve), and weather data (e.g., lack of rain). The behavior graph maps the potential spread to adjacent crop sections. The dependency tree is traversed backward, identifying that the crop stress anomaly was preceded by an irrigation valve failure two days prior, pinpointing the root cause.
• Mermaid Diagram:

  flowchart TD
      A[Drone NDVI Scan] --> B{Anomaly Detection};
      B -- "Crop Stress in Sector 7B" --> C[Correlation Engine];
      D[Soil Moisture Data] --> C;
      E[Irrigation Valve Logs] --> C;
      F[Weather Data] --> C;
      C -- "Correlates Stress with Zero Water Flow" --> G[Generate Behavior Graph];
      G -- "Models Spread to Sector 7C" --> H[Impact Assessment];
      G -- "Trace Dependency Tree" --> I[Root Cause Identification];
      I --> J((Root Cause: Valve 7B Stuck Closed on 2026-04-29));
  

3.3. Finance: Algorithmic Trading Fraud Detection

• Enabling Description: The system models a financial trading environment. The CPG's nodes represent traders, trading algorithms (bots), accounts, specific securities (stocks, options), and market data feeds. Edges represent transactions, account ownership, and data access. The normal behavior model is established by analyzing historical trading patterns, order sizes, and execution speeds for each algorithm and trader. An anomaly is a series of trades that deviate significantly, such as a bot executing a high volume of wash trades or a series of orders placed just before a major news announcement (insider trading pattern). The system correlates the anomalous trades with other network events, such as a trader accessing sensitive research files (another node) just before the trades. The behavior graph maps the flow of funds and information. The system can then trace back from the illicit trade, through the algorithm, to the compromised user account and the preceding data access event, identifying the point of origin of the fraudulent activity.
• Mermaid Diagram:

  sequenceDiagram
      participant Trader_X as "Trader X"
      participant Research_DB as "Research Database"
      participant Trading_Bot as "Algo Bot Alpha"
      participant Stock_ABC as "Security ABC"
      participant Anomaly_Engine as "Anomaly Engine"
  
      Trader_X ->> Research_DB: Accesses M&A report (Event 1)
      Anomaly_Engine ->> Anomaly_Engine: Log Event 1
      Trader_X ->>+ Trading_Bot: Places large BUY order for ABC (Event 2)
      Trading_Bot ->>- Stock_ABC: Execute Trade
      Anomaly_Engine ->> Anomaly_Engine: Detect ANOMALY (Trade precedes news)
      Anomaly_Engine ->> Anomaly_Engine: Correlate Event 2 with Event 1 (Temporal Proximity)
      Anomaly_Engine ->> Anomaly_Engine: Build Behavior Graph: Trader -> DB -> Bot -> Trade
      Anomaly_Engine ->> Anomaly_Engine: Traverse backward from Event 2 to Event 1
      Anomaly_Engine -->> Compliance_Officer: Alert: Potential Insider Trading. Origin: Trader X access of M&A report.
  

---

Axis 4: Integration with Emerging Tech

4.1. Integration with Generative AI for Predictive Attack Path Modeling

• Enabling Description: The system integrates a Generative Adversarial Network (GAN) or a Large Language Model (LLM) trained on cybersecurity incident reports and the organization's CPG. The "Reconnaissance Engine" not only builds a model of normal behavior but also feeds the CPG structure into the AI. The AI's "generator" component proposes hypothetical, multi-stage attack paths that are plausible but have not yet been observed. The "discriminator" component, using the normal behavior model and known vulnerabilities, scores these paths for feasibility. The system constantly simulates these AI-generated attacks on the CPG, identifying the most likely future points of failure. Anomaly detection is then enhanced to look for early indicators matching the initial stages of these high-probability, predicted attack vectors.
• Mermaid Diagram:

  graph TD
      subgraph Existing_System
          CPG[Cyber-Physical Graph]
          ReconEngine[Reconnaissance Engine]
          AnomalyEngine[Anomaly Engine]
      end
  
      subgraph AI_Module
          Generator[Generative AI: Proposes Attack Paths]
          Discriminator[Discriminator AI: Validates Paths]
          ThreatDB[Threat Intelligence DB]
  
          ThreatDB -->|Training Data| Generator
          CPG -->|Current State| Generator
          Generator -- Hypothetical Path --> Discriminator
          CPG -- Constraints --> Discriminator
          Discriminator -- Validated Path --> PredictiveAlerts
      end
  
      ReconEngine --> CPG
      CPG --> AnomalyEngine
      PredictiveAlerts[High-Probability Attack Paths] --> AnomalyEngine
      AnomalyEngine -- Detects Match --> Alert
  

4.2. Integration with IoT and Edge Computing for Real-Time Physical Security

• Enabling Description: The CPG is extended to include thousands of IoT devices as nodes: cameras with computer vision, smart locks, motion sensors, and temperature sensors in a data center. Edges represent physical zones, network connections, and power lines. Edge computing gateways pre-process sensor data, generating localized "micro-anomalies" (e.g., motion detected in a restricted area after hours). These events are sent to the central system, which correlates them. A network anomaly (e.g., a server's management port being accessed) occurring simultaneously with a physical anomaly (e.g., the smart lock on that server's rack being forced open) creates a high-confidence, correlated cyber-physical incident. The behavior graph now includes physical and digital nodes, and tracing back can pinpoint a physical breach as the root cause of a digital attack.
• Mermaid Diagram:

  graph TD
      subgraph DataCenter
          ServerRack[Server Rack 42]
          SmartLock[Smart Lock]
          MotionSensor[Motion Sensor]
          Server[Server 42-U12]
  
          ServerRack -- Contains --> SmartLock & MotionSensor & Server
      end
  
      subgraph EventStreams
          IoT_GW[Edge Gateway]
          NetFlow_Stream[Network Flow]
      end
  
      SmartLock -- Lock Forced Event --> IoT_GW
      MotionSensor -- Motion Detected --> IoT_GW
      NetFlow_Stream -- Mgmt Port Access --> Central_Engine[Central Analysis Engine]
      IoT_GW -- Physical Anomaly --> Central_Engine
  
      Central_Engine --> Correlator{Correlates Physical & Network Anomalies}
      Correlator --> Traceback[Traceback Engine]
      Traceback --> RootCause((Physical Breach at Rack 42))
  

4.3. Integration with Blockchain for Immutable Auditing

• Enabling Description: Every significant state change, detected anomaly, and administrative action within the system is recorded as a transaction on a private, permissioned blockchain (e.g., Hyperledger Fabric). The hash of the CPG's state is periodically written to the blockchain, creating a tamper-proof "snapshot" in time. When an anomalous event is detected, its details (timestamp, affected nodes, event logs) are committed to the ledger. The subsequent generation of the behavior graph and the results of the traceback analysis are also recorded as linked transactions. This creates a cryptographically-secured, non-repudiable audit trail for forensic investigations. Regulators or auditors can be given read-only access to the blockchain to verify the integrity of the security monitoring and response process without accessing the live operational system.
• Mermaid Diagram:

  sequenceDiagram
      participant CPG_Engine
      participant Anomaly_Detector
      participant Blockchain_Ledger
  
      CPG_Engine->>CPG_Engine: State Change (e.g., New Device Added)
      CPG_Engine->>Blockchain_Ledger: Transaction: 'State Hash Update'
  
      loop Continuous Monitoring
          Anomaly_Detector->>Anomaly_Detector: Detects Anomalous Event
          Anomaly_Detector->>Blockchain_Ledger: Transaction: 'Anomaly Record' (Immutable)
          Anomaly_Detector->>CPG_Engine: Request Correlation Analysis
          CPG_Engine->>CPG_Engine: Generate Behavior Graph & Traceback
          CPG_Engine->>Blockchain_Ledger: Transaction: 'Forensic Analysis Result'
      end
  
      Auditor->>Blockchain_Ledger: Query Ledger for Incident XYZ
      Blockchain_Ledger-->>Auditor: Return Tamper-Proof Incident Timeline
  

---

Axis 5: The "Inverse" or Failure Mode

5.1. Graceful Degradation under DDoS Attack

• Enabling Description: The system is designed to operate in a "low-power" or degraded mode when its own monitoring and analysis components are under a Denial-of-Service (DoS) or Distributed Denial-of-Service (DDoS) attack. When the rate of incoming events exceeds a predefined processing threshold, the system automatically triages. It ceases detailed analysis for low-criticality nodes in the CPG (e.g., guest Wi-Fi devices, marketing web servers) and focuses all computational resources on a "crown jewels" subset of nodes (e.g., domain controllers, financial databases, SCADA controllers). The "normal behavior model" is temporarily simplified to use basic statistical thresholds instead of complex machine learning models. The behavior graph generation is limited to a depth of 2-3 hops from the anomalous node to conserve resources, providing a "good enough" picture for immediate response while under duress.
• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Normal_Ops: System Start
      Normal_Ops: Full CPG Analysis / ML Models / Deep Tracing
      Degraded_Mode: 'Crown Jewels' CPG Subset / Simple Thresholds / Shallow Tracing
  
      Normal_Ops --> Degraded_Mode: Event Rate > Threshold (DDoS Attack)
      Degraded_Mode --> Normal_Ops: Event Rate < Threshold (Attack Subsides)
  

5.2. "Honeypot" Triggered Forensic Quarantine Mode

• Enabling Description: This version is designed to fail safely by actively luring attackers. The CPG includes special "honeypot" nodes—decoy servers and databases that appear valuable but are heavily instrumented. The normal behavior model defines any interaction with these honeypot nodes as a high-confidence anomaly. Upon detection of such an event, the system does not just alert; it enters a "Quarantine Mode." It uses the behavior graph not to trace the origin, but to project the attacker's next likely moves based on the CPG's connectivity. It then dynamically reconfigures network ACLs and firewalls to create a "digital isolation bubble" around the compromised entry point and the honeypot, severing their connections to real production systems. This contains the threat while allowing security teams to observe the attacker's methods in a safe, sandboxed environment. The system prioritizes forensic data capture over maintaining service availability for the affected (and now isolated) network segment.
• Mermaid Diagram:

  flowchart TD
      A[Attacker Probes Network] --> B(Accesses Decoy DB<br/>'Honeypot Node');
      B --> C{High-Confidence Anomaly Triggered};
      C --> D[Enter Quarantine Mode];
      D --> E[Project Attacker's Next Hops via CPG];
      D --> F[Start Forensic Packet Capture];
      E --> G[Dynamically Reconfigure Firewall ACLs];
      G --> H((Isolate Attacker & Honeypot in Sandbox));
      H --> I[Alert Security Operations Center];
  

---

Combination Prior Art Scenarios with Open-Source Standards

1. Combination with STIX/TAXII and OpenCTI

• Description: The system's reconnaissance engine is enhanced to natively ingest and process threat intelligence from any STIX (Structured Threat Information eXpression) formatted feed via a TAXII (Trusted Automated eXchange of Intelligence Information) client. The ingested intelligence—such as malware hashes, attacker IP addresses, and known TTPs (Tactics, Techniques, and Procedures)—is used to enrich the CPG. Nodes representing network assets are automatically tagged with known vulnerabilities, and new "threat actor" nodes are added to the graph. When an anomaly is detected, the correlation engine specifically checks if the anomalous behavior matches any of the TTPs associated with known threat actors. The entire system is integrated with an OpenCTI (Open Cyber Threat Intelligence) platform, which serves as the primary repository for both internal CPG data and external STIX intelligence, creating a unified view of internal state and external threats.

2. Combination with OSQuery and Sysmon

• Description: The creation and real-time updating of the "normal behavior model" are driven by data collected from a fleet of endpoints running OSQuery and Sysmon. OSQuery agents are configured to periodically query the state of endpoints (e.g., running processes, open network sockets, browser plugins, logged-in users) and feed this structured data into the CPG module, creating highly detailed nodes for each host. Sysmon provides a continuous stream of granular event logs (process creation, network connections, file modifications). The Directed Computational Graph Engine uses this high-fidelity endpoint data to build extremely precise behavioral baselines. An anomaly is detected when a process (e.g., powershell.exe) initiates a network connection to an unusual external IP, a behavior directly observed from Sysmon data that deviates from the OSQuery-established baseline. The traceback can then follow the process creation chain within the Sysmon logs to identify the parent process that initiated the malicious activity.

3. Combination with OpenTelemetry and Jaeger

• Description: In a microservices or cloud-native environment, the CPG is constructed using topology data from an OpenTelemetry collector. Each microservice, container, and API endpoint becomes a node in the graph. The edges are not just network connections but represent distributed traces collected via OpenTelemetry, showing the exact call stack and data flow between services for a given transaction. The "normal behavior model" defines acceptable latency, error rates, and call patterns between services. An anomaly is detected when a trace shows an unexpected service call (e.g., an authentication service being bypassed) or a significant latency spike. The behavior graph is a visual representation of the anomalous distributed trace. The "traversing the behavior tree backward" step is equivalent to using a distributed tracing tool like Jaeger to find the specific service and code span that initiated the faulty or malicious transaction, providing a direct link from the observed anomaly to its root cause in the application code.