Derivative works — US Patent 9560177

Defensive Disclosure for US Patent 9560177

This document outlines derivative variations and combination prior art scenarios for US patent 9560177, titled "Network system and network flow tracing method." The goal is to generate defensive disclosures that render future incremental improvements by competitors obvious or non-novel, based on the core inventive concept of duplicating a packet header for encapsulation within a switch to enable flow tracing through header translating units (NAT/NAPT) in a software-defined networking (SDN) environment like OpenFlow.

The analysis focuses on variations of the core mechanism described in independent claims 1, 7, 13, and 19. Since these claims largely cover the same inventive concept from apparatus, system, method, and computer-readable medium perspectives, the derivatives will apply broadly across these claim types.

Derivative Variations

1. Material & Component Substitution

Derivative 1.1: FPGA-Accelerated Encapsulation Module

Enabling Description: A switch apparatus (Claim 1) or communication system (Claim 7) is implemented where the encapsulating module (21-1, 21-2) functionality, specifically the packet identification, header duplication, and encapsulation/decapsulation logic, is offloaded to a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC) integrated directly into the network interface controller (NIC) or switch fabric. The FPGA/ASIC contains hardwired logic blocks or reconfigurable logic cells programmed in Hardware Description Language (HDL) (e.g., VHDL, Verilog) to perform header parsing, buffering, duplication, and re-assembly at line rate, significantly reducing latency and increasing throughput compared to a software-based processor execution (Claim 1, processor configured to execute instructions). The control apparatus (Claim 7) would load specific bitstreams or configurations to the FPGA/ASIC to define encapsulation targets and header duplication rules. This substitution maintains the core method (Claim 13) but optimizes the "duplicating a part of a header" and "encapsulating" steps for high-performance network segments.

flowchart TD
    A[Received Packet] --> B{Packet Identification (FPGA)};
    B -- Is Encapsulation Target? --> C{Duplicate Header Logic (FPGA)};
    C --> D[Encapsulated Packet];
    D --> E[Switch Fabric Output];
    F[Control Apparatus] --> G[FPGA/ASIC Configuration];
    G --> B;
    G --> C;

Derivative 1.2: eBPF-Managed Encapsulation

Enabling Description: The switch apparatus (Claim 1) or communication method (Claim 13) leverages extended Berkeley Packet Filter (eBPF) programs for dynamic, in-kernel packet processing. Instead of traditional flow table entries directly controlling hardware, the control apparatus (Claim 7) compiles and loads eBPF programs into the kernel of the switch's operating system. These eBPF programs intercept packets at a specified hook point (e.g., XDP or TC), identify encapsulation targets based on predefined maps (e.g., hash maps for flow identifiers), duplicate relevant header fields (e.g., sk_buff manipulation in Linux kernel), and perform generic routing encapsulation (GRE) or Virtual Extensible LAN (VXLAN) tunneling. Decapsulation and header information extraction are also performed by eBPF programs, transmitting metadata via perf_event_output to user-space agents for relay to the controller. This substitutes the direct "processor executing instructions" for a more flexible, programmable, and efficient kernel-level packet processing mechanism.

sequenceDiagram
    participant P as Packet Ingress
    participant S as Switch Kernel (eBPF)
    participant U as User Space Agent
    participant C as Controller
    P->>S: Packet Received
    S->>S: Identify Target (eBPF Map Lookup)
    alt Encapsulation Target
        S->>S: Duplicate Header (eBPF Program)
        S->>S: Encapsulate Packet (GRE/VXLAN)
        S->>U: Send Metadata (perf_event_output)
    else Not Target
        S->>S: Forward Packet
    end
    S->>P: Packet Egress
    U->>C: Header Translation Data
    C->>S: Update eBPF Maps/Programs

Derivative 1.3: Quantum-Resistant Encapsulation Protocol

Enabling Description: The network system (Claim 7) employs a quantum-resistant cryptographic encapsulation protocol for the additional header (Claim 1), specifically for securing the integrity and confidentiality of the duplicated header when sensitive flow tracing is required. Instead of standard GRE or VXLAN, the encapsulation involves a post-quantum cryptography (PQC) layer. For instance, the duplicated header (First Header) could be hashed using a collision-resistant PQC algorithm (e.g., a hash from the NIST PQC standardization process) and included as a metadata field in the outer (Second) header's options or a custom tunneling protocol. Alternatively, the entire encapsulated packet could be encrypted with a PQC key exchange mechanism (e.g., CRYSTALS-Kyber) and a symmetric PQC cipher, ensuring that only authorized encapsulating modules and controllers can extract or verify the original flow information, even against future quantum computing attacks. The switch processor (Claim 1) would execute PQC algorithms for secure header manipulation.

classDiagram
    class Packet {
        +OriginalHeader
        +Payload
    }
    class EncapsulatedPacket {
        +OuterHeader (PQC-Secured)
        +InnerOriginalHeader
        +Payload
    }
    class SwitchProcessor {
        +PQCKeyExchange()
        +PQCHash(data)
        +PQCEncrypt(data, key)
    }
    Packet --|> EncapsulatedPacket : is encapsulated by
    SwitchProcessor ..> Packet : processes
    SwitchProcessor ..> EncapsulatedPacket : generates/decapsulates

2. Operational Parameter Expansion

Derivative 2.1: Hyperscale Data Center Flow Tracing

Enabling Description: The network system (Claim 7) operates within a hyperscale data center environment managing millions of concurrent flows and dynamic virtual network overlays. The switch apparatus (Claim 1) is designed to handle packet rates exceeding 1 Terabit per second (Tbps) with header duplication and encapsulation performed within 100 nanoseconds latency. This requires highly optimized packet processing pipelines, potentially utilizing specialized network processing units (NPUs) with deep packet inspection (DPI) capabilities and parallel processing cores. The control apparatus (Claim 7) employs machine learning algorithms to predict high-value flows for encapsulation, dynamically adjusting the "target of encapsulation" rules based on real-time traffic analytics and policy enforcement. The "additional header" (Claim 1) is compacted to minimize overhead, potentially using bitmasking or delta encoding for redundant fields.

graph TD
    A[Ingress 1Tbps Traffic] --> B(NPU Pipeline);
    B --> C{Flow Identify & Rule Match};
    C -- Encapsulation Target --> D{Header Duplicate & Encapsulate (100ns)};
    D --> E[Egress Packet];
    C -- Not Target --> F[Forward Packet];
    E --> G[Controller (ML-driven Policy)];
    G --> C;

Derivative 2.2: Ultra-Low Latency Financial Trading Networks

Enabling Description: The network flow tracing method (Claim 13) is applied to ultra-low latency financial trading networks where propagation delay is critical (e.g., sub-microsecond latency requirements). The "part of a header" to be duplicated (Claim 13) includes precise timestamping information from a network time protocol (NTP) synchronized clock source, accurate to picoseconds, captured at the ingress switch. The encapsulation process is executed with minimal jitter and deterministic latency guarantees by dedicated hardware elements. The "additional header" contains not only the original header but also a high-resolution sequence number and a cryptographic nonce, ensuring replay protection and precise ordering for audit trails. The header translation data transmitted to the controller (Claim 14) includes the original and translated headers along with ingress/egress timestamps and latency measurements, enabling precise analysis of trading flow delays induced by network appliances.

sequenceDiagram
    participant S_IN as Ingress Switch
    participant NAT as Header Translating Unit
    participant S_OUT as Egress Switch
    participant C as Controller
    S_IN->>S_IN: Receive Packet (H1, P)
    S_IN->>S_IN: Timestamp T1 (Picosecond)
    S_IN->>S_IN: Duplicate H1 as H_INNER
    S_IN->>S_IN: Encapsulate (H1, (H_INNER, P))
    S_IN->>NAT: Transmit Encapsulated Packet
    NAT->>NAT: Translate Outer H1 to H2
    NAT->>S_OUT: Transmit (H2, (H_INNER, P))
    S_OUT->>S_OUT: Receive Packet
    S_OUT->>S_OUT: Timestamp T2 (Picosecond)
    S_OUT->>S_OUT: Decapsulate, Extract H_INNER, H2
    S_OUT->>C: Send Header Translation Data (H1=H_INNER, H2, T1, T2)
    S_OUT->>S_OUT: Replace H_INNER with H2, Forward (H2, P)

Derivative 2.3: Satellite Constellation Mesh Networks

Enabling Description: The network system (Claim 7) consists of a mesh of low Earth orbit (LEO) satellites forming an inter-satellite link (ISL) network. Each satellite functions as a switch apparatus (Claim 1) where the processor and storage are radiation-hardened components. Due to dynamic topology and varying link qualities, header duplication and encapsulation rules (Claim 1) are frequently updated by a ground-based control apparatus (Claim 7) via secure command uplinks. The "additional header" includes satellite orbital parameters, beamforming metadata, and a redundant coding scheme to ensure reliability over high-bit-error-rate ISL connections. Flow tracing is critical for link budget analysis, constellation resource allocation, and anomaly detection. The encapsulation is performed using a custom space-optimized tunneling protocol over optical or radio frequency ISLs.

graph LR
    GroundControl --> SatelliteA(LEO Switch A);
    GroundControl --> SatelliteB(LEO Switch B);
    SatelliteA -- ISL --> SatelliteB;
    SatelliteA -- Encapsulation & Tracing --> SatelliteB;
    subgraph LEO Satellite Network
        SatelliteA --> SatAppliance(Space-borne NAT/NAPT);
        SatAppliance --> SatelliteB;
    end

3. Cross-Domain Application

Derivative 3.1: Autonomous Vehicle Network Diagnostics

Enabling Description: In an autonomous vehicle's internal network (e.g., Automotive Ethernet, CAN bus over IP), the vehicle's central gateway acts as a switch apparatus (Claim 1). It has a processor that identifies packets (e.g., sensor data, control commands) from various Electronic Control Units (ECUs). When a packet is identified as critical for diagnostics (e.g., LiDAR data, brake command) and passes through an internal translation unit (e.g., IP to proprietary bus protocol bridge, or internal NAT for legacy ECU integration), a part of its header (e.g., source ECU identifier, command ID, timestamp) is duplicated and encapsulated. This allows the vehicle's diagnostic control unit (acting as the control apparatus, Claim 7) to trace the exact original source and content of commands and data flows through internal translation layers without modifying individual ECUs or proprietary buses. This is vital for debugging, compliance, and post-incident analysis.

flowchart LR
    ECU1(LiDAR ECU) --> Gateway(Switch Apparatus);
    ECU2(Brake ECU) --> Gateway;
    Gateway --> TranslationUnit(Internal NAT/Protocol Bridge);
    TranslationUnit --> Actuators(Wheel Motors, Brakes);
    Gateway -- Encapsulate & Trace Flow --> DiagnosticUnit(Control Apparatus);

Derivative 3.2: Smart Grid SCADA Communication Integrity

Enabling Description: Within a Smart Grid's Supervisory Control and Data Acquisition (SCADA) network, intelligent electronic devices (IEDs) and Remote Terminal Units (RTUs) communicate with a central control center. A network gateway at a substation acts as a switch apparatus (Claim 1). This gateway monitors SCADA packets (e.g., Modbus/TCP, DNP3 over IP) that might undergo NAT/NAPT translation by secure network appliances (e.g., firewalls) before reaching the control center. For critical control commands (e.g., trip breaker, change setpoint), the gateway duplicates a portion of the packet's SCADA header (e.g., function code, register address, IED ID) and encapsulates it. The control center's network monitoring system (control apparatus, Claim 7) receives the header translation data, allowing it to verify the original command parameters even after passing through security appliances, ensuring command integrity and aiding in forensic analysis of cyber-physical attacks or misconfigurations without modifying the SCADA devices or firewalls.

graph TD
    IED_RTU(Substation IED/RTU) --> SubstationGateway(Switch Apparatus);
    SubstationGateway --> Firewall(Header Translating Unit);
    Firewall --> ControlCenter(SCADA Control Apparatus);
    SubstationGateway -- Encapsulated SCADA Flow --> ControlCenter;

Derivative 3.3: High-Throughput Genomic Sequencing Data Pipelines

Enabling Description: In a large-scale genomic sequencing facility, raw sequencing data (e.g., FASTQ, BAM files chunked into packets) are streamed from sequencers to high-performance computing (HPC) clusters for analysis. A specialized network switch (Claim 1) handling these data flows might encounter header translating units (e.g., specialized storage network gateways, data format converters performing header-like metadata translation). For tracing the provenance and integrity of specific genomic data streams, a portion of the original packet header (e.g., sample ID, sequencer run ID, read group) is duplicated and encapsulated. The bioinformatics workflow management system (control apparatus, Claim 7) uses this tracing method to monitor the flow of data through various network and processing stages, verifying that the correct original sample data reaches its intended analytical pipeline even if network addresses or internal identifiers are translated along the way.

flowchart TD
    Sequencer(Genomic Sequencer) --> DataSwitch(Switch Apparatus);
    DataSwitch --> StorageGateway(Header Translating Unit);
    StorageGateway --> HPC_Cluster(Bioinformatics Control Apparatus);
    DataSwitch -- Encapsulated Genomic Data Flow --> HPC_Cluster;

4. Integration with Emerging Tech

Derivative 4.1: AI-Driven Dynamic Encapsulation Policy Optimization

Enabling Description: The network system (Claim 7) integrates an AI-driven optimization engine with the control apparatus (Claim 7). This AI engine continuously analyzes network telemetry, application performance metrics, and historical flow tracing data (header translation data from Claims 2, 8, 14, 20). Using reinforcement learning or predictive analytics, the AI dynamically adjusts the "target of encapsulation" rules (Claim 1) in real-time. For instance, if the AI detects an emerging bottleneck or an anomaly pattern indicative of a specific application flow misbehaving after passing a NAT, it automatically updates the rules in upstream switches to encapsulate and trace only that problematic flow, minimizing overhead. This optimizes resource utilization by encapsulating only when and where necessary, adapting to changing network conditions and threat landscapes.

graph TD
    A[Network Telemetry] --> B(AI Optimization Engine);
    C[Header Translation Data] --> B;
    B --> D{Dynamic Encapsulation Rules};
    D --> E[Control Apparatus];
    E --> F[Switch Apparatus (Flow Tables)];
    F -- Packet Processing --> A;
    F -- Encapsulation --> C;

Derivative 4.2: IoT Sensor-Triggered Contextual Flow Tracing

Enabling Description: The network system (Claim 7) is deployed in an industrial IoT environment. IoT sensors (e.g., environmental, machine health) are integrated such that their state changes can trigger network flow tracing. The control apparatus (Claim 7) receives real-time alerts from IoT platforms. If a critical sensor reading (e.g., abnormal temperature, machine fault) is detected, the control apparatus correlates this with active network flows related to that IoT device or associated control systems. It then instructs the relevant switch apparatuses (Claim 1) to immediately begin duplicating headers and encapsulating packets for those specific IoT-related flows. The "additional header" (Claim 1) may also include the IoT sensor ID and trigger event timestamp. This provides contextual network visibility, allowing operators to diagnose whether a network translation issue contributed to the IoT anomaly.

stateDiagram
    state "Normal Operation" as Normal
    state "IoT Anomaly Detected" as Anomaly
    state "Contextual Tracing Active" as Tracing
    state "Tracing Data Analysis" as Analysis

    Normal --> Anomaly : IoT Sensor Alert
    Anomaly --> Tracing : Controller Activates Encapsulation Rules
    Tracing --> Analysis : Header Translation Data Sent
    Analysis --> Normal : Issue Resolved / Tracing Deactivated
    Tracing --> Anomaly : Continued Anomaly

Derivative 4.3: Blockchain-Verified Header Translation Log

Enabling Description: The network system (Claim 7) incorporates a blockchain-based immutable ledger for storing header translation data. After the encapsulating module (Claim 1) extracts the original and translated headers (Claims 2, 6, 8, 11, 12, 14, 17, 18), this "header translation data" is hashed (e.g., SHA-256) and cryptographically signed by the switch apparatus (using a private key associated with the switch). The signed hash, along with a timestamp and a reference to the block of data, is then submitted as a transaction to a permissioned blockchain network (e.g., Hyperledger Fabric) managed by the control apparatus (Claim 7) or a distributed network of trusted nodes. This creates an auditable, tamper-proof record of all header translations, crucial for regulatory compliance, security forensics, and non-repudiation in multi-party network environments, ensuring the integrity of the flow tracing information.

flowchart TD
    A[Encapsulating Module (Decap)] --> B[Generate Header Translation Data];
    B --> C[Hash & Sign Data (Switch)];
    C --> D[Submit Transaction to Blockchain];
    D -- Block Added --> E[Immutable Translation Log];
    E --> F[Controller (Audit/Verify)];

5. The "Inverse" or Failure Mode

Derivative 5.1: Graceful Degradation of Tracing Functionality

Enabling Description: The switch apparatus (Claim 1) implements a graceful degradation mechanism for the network flow tracing method (Claim 13) under high network load or resource contention. Instead of failing outright or dropping packets, the controller (Claim 1) is configured to dynamically adjust the granularity or frequency of header duplication and encapsulation. For example, under overload, the system might switch from full header duplication to only duplicating a critical flow identifier (e.g., flow hash, source/destination IP pair). Alternatively, it might engage in statistical sampling, encapsulating only 1% of identified target packets instead of 100%. The "additional header" could also be truncated to minimal essential fields. This ensures that some level of flow tracing data is still collected, prioritizing network throughput while providing diagnostic insights, albeit at reduced detail.

stateDiagram
    state "Full Tracing (Normal)" as Full
    state "Reduced Header Detail" as ReducedHeader
    state "Packet Sampling" as Sampling
    state "Minimal Essential Fields" as Minimal
    state "No Tracing (Critical Overload)" as Off

    Full --> ReducedHeader : High Load / Resource Contention
    ReducedHeader --> Sampling : Further Load Increase
    Sampling --> Minimal : Severe Load Increase
    Minimal --> Off : Critical Overload / Fail-Safe
    Off --> Minimal : Load Decreases
    Minimal --> Sampling : Load Decreases
    Sampling --> ReducedHeader : Load Decreases
    ReducedHeader --> Full : Load Decreases

Derivative 5.2: Privacy-Preserving Selective De-Encapsulation

Enabling Description: The network system (Claim 7) is designed for environments requiring strict privacy compliance (e.g., GDPR, HIPAA). The egress encapsulating module (Claim 1) performs "privacy-preserving selective decapsulation" based on policies set by the control apparatus (Claim 7). When decapsulating an encapsulated packet (Claims 4, 10, 16), it inspects the "additional header" (the duplicated original header). If specific fields (e.g., sensitive personal data in the payload, certain port numbers) within this inner header match a privacy rule, those fields are immediately anonymized, masked, or redacted before the header translation data is sent to the controller (Claim 2, 8, 14, 20). Only non-sensitive or aggregated tracing information is forwarded, ensuring that end-to-end flow tracing can occur for network diagnostics without compromising user privacy.

sequenceDiagram
    participant S_OUT as Egress Switch (Encapsulating Module)
    participant C as Controller (Policy Engine)
    participant L as Local Anonymizer
    S_OUT->>S_OUT: Receive Encapsulated Packet
    S_OUT->>S_OUT: Decapsulate, Extract Original Header H_INNER
    S_OUT->>C: Request Privacy Policy for H_INNER
    C-->>S_OUT: Privacy Policy (e.g., Mask IP)
    S_OUT->>L: Apply Anonymization/Masking to H_INNER
    L-->>S_OUT: Anonymized H_INNER
    S_OUT->>C: Send Header Translation Data (Anonymized H_INNER, Translated H_OUTER)

Derivative 5.3: Low-Power/Standby Mode with Event-Driven Tracing

Enabling Description: The switch apparatus (Claim 1) operates in a power-constrained environment (e.g., remote edge device, battery-powered network sensor). In its default "low-power" or standby mode, the header duplication and encapsulation functions are disabled to conserve energy. The switch's processor (Claim 1) only performs basic packet forwarding. However, upon a specific trigger event (e.g., detection of a predefined anomaly signature, remote command from the control apparatus, or scheduled diagnostic window), the system transitions to an "event-driven tracing" mode. In this mode, the processor (Claim 1) re-enables the encapsulation logic for a limited duration or for a specific subset of flows. Once the diagnostic period is over or the anomaly subsides, the system reverts to low-power mode, disabling intensive tracing operations. The recording medium (Claim 19) would store instructions for managing these power states and dynamic rule activation.

stateDiagram
    state "Low-Power Idle (Tracing Disabled)" as Idle
    state "Event-Driven Tracing Active" as Active

    Idle --> Active : Trigger Event Detected
    Active --> Idle : Tracing Duration Expired / Event Resolved
    Idle --> Idle : Basic Packet Forwarding
    Active --> Active : Encapsulation & Tracing for Specific Flows

Combination Prior Art Scenarios

Here are three scenarios combining US patent 9560177 with existing open-source standards to generate further prior art:

1. US9560177 + OpenFlow (NPL1) + RFC 7348 (VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks)

Combination: A network system (Claim 7) operating on OpenFlow (NPL1) principles and switches (Claim 1) utilizes VXLAN (RFC 7348) as the encapsulation protocol for the "additional header."
Enabling Description: An OpenFlow controller (as the control apparatus) provisions rules (Claim 1) in OpenFlow switches (switch apparatus). For flows designated as "targets of encapsulation," the switch's encapsulating module (software or hardware) duplicates the original packet's Layer 2, 3, and 4 headers. This duplicated header, along with the original payload, is then encapsulated within a VXLAN header and UDP/IP header. The VXLAN Network Identifier (VNI) in the VXLAN header can be used to tag the flow tracing context. The external IP header of the VXLAN tunnel is subject to translation by a NAT/NAPT unit. Upon reception, a downstream OpenFlow switch, also configured by the controller, performs VXLAN decapsulation, extracts the original duplicated headers, and transmits this pre-translation information (original header, translated outer VXLAN IP header) to the controller for flow tracing. VXLAN is explicitly designed for network overlays and provides a clear mechanism for encapsulating inner frames, making its application for carrying a duplicated original header a straightforward extension in an OpenFlow context.

2. US9560177 + RFC 1701 / RFC 2784 (Generic Routing Encapsulation - GRE) + IETF IPFIX (IP Flow Information Export) Protocol

Combination: A network system (Claim 7) uses GRE (RFC 1701 / RFC 2784) for packet encapsulation (Claim 1) and sends the generated "header translation data" (Claims 2, 8, 14, 20) to the controller using the IPFIX protocol.
Enabling Description: Within an OpenFlow-managed network, an upstream switch apparatus (Claim 1) is instructed by the controller (Claim 7) to duplicate the original IP header of a target packet. This duplicated header and payload are then encapsulated using GRE. The outer GRE header contains the dynamically translated IP header. A downstream switch apparatus, after receiving the GRE encapsulated packet that has passed through a NAT/NAPT, performs GRE decapsulation. It then constructs IPFIX flow records. These records include observed data fields for both the original (inner) IP header and the translated (outer) IP header (before decapsulation). These IPFIX records, containing the pair of pre- and post-translation headers as "header translation data," are then exported to the controller (acting as an IPFIX collector) for comprehensive flow tracing and analysis. This combines standard tunneling with a standard flow telemetry export mechanism.

3. US9560177 + IEEE 802.1Q (VLAN Tagging) + RFC 863 (Discard Protocol)

Combination: A switch apparatus (Claim 1) uses IEEE 802.1Q VLAN tags in the duplicated header for granular flow identification, and the "additional header" (the duplicated part) is sometimes redirected to a network tap implementing the Discard Protocol (RFC 863) for debugging.
Enabling Description: The network system (Claim 7) handles Layer 2 traffic with IEEE 802.1Q VLAN tagging. When a switch apparatus (Claim 1) receives an Ethernet frame, its processor identifies the frame based on rules that can include VLAN ID. For encapsulation targets, the switch duplicates a "part of a header" that specifically includes the original Ethernet header and its 802.1Q tag. This duplicated information is then encapsulated (e.g., within an outer Ethernet frame or a simple tunneling protocol). In a diagnostic scenario, instead of sending the full header translation data to the controller, the encapsulated packet's duplicated header (the "additional header") is sometimes extracted and redirected to a special debugging port configured as a network tap. This tap is designed to simply "discard" (RFC 863 behavior) the redirected duplicated header for high-volume, quick-check diagnostics where storage/processing of full records is undesirable. This allows for simple presence detection of specific flows without full processing overhead, particularly useful for basic connectivity and translation verification.