Derivative works — US Patent 6502135

Defensive Disclosure for U.S. Patent 6,502,135

Title: Systems and Methods for Dynamic Network Topology Obfuscation and Resilient Communication

Publication Date: April 26, 2026

Abstract: This disclosure describes a series of derivative methods and systems that build upon the foundational concepts of agile network protocols for secure communications. The described variations are intended to enter the public domain to serve as prior art for future inventions in the field of network security. These methods expand upon the concept of using pseudo-randomly changing network identifiers to create secure communication links, applying these principles to different technological domains, integrating them with emerging technologies, and exploring novel operational modes. The core principle is the obfuscation of network endpoints and communication pathways through synchronized, algorithmically-driven variations in network parameters, thereby increasing the difficulty of interception, traffic analysis, and denial-of-service attacks.

Analysis of Core Claim 12: Transparent Creation of a Secure Communication Link

Original Concept: Intercepting a domain name system (DNS) request on a first computer via a proxy, determining if a secure link is required for the requested domain, and if so, transparently establishing a virtual private network (VPN) where data packets include values that vary according to a pseudo-random sequence.

Derivative Variations on Claim 12

1. Material & Component Substitution

Variation 1.1: Hardware-Based Agility Trigger

Enabling Description: Instead of a software proxy intercepting DNS requests, this variation utilizes a dedicated network interface card (NIC) or a Trusted Platform Module (TPM) with specialized firmware. The hardware itself inspects outgoing packets at the data link layer for DNS requests (UDP/TCP port 53). Upon detecting a request matching a pre-configured policy list of secure domains stored in a protected hardware memory region, the NIC's firmware initiates the agile VPN protocol directly, negotiating the pseudo-random sequence with the destination. This offloads the interception and decision-making from the host operating system, making it more resistant to software-level tampering and reducing CPU overhead. The NIC would use its own processor and memory to manage the hopping sequences and moving window of valid addresses.

Diagram:

sequenceDiagram
    participant UserApp as User Application
    participant OS_Kernel as Operating System Kernel
    participant SecureNIC as Secure Hardware NIC/TPM
    participant Network as Public Network
    participant SecureDNS as Secure DNS Resolver

    UserApp->>OS_Kernel: Initiate DNS Lookup (e.g., bank.com)
    OS_Kernel-->>SecureNIC: Construct DNS packet for port 53
    activate SecureNIC
    SecureNIC->>SecureNIC: Inspect packet destination and policy
    Note over SecureNIC: Policy dictates bank.com requires agility
    SecureNIC->>SecureDNS: Initiate Agile Handshake (Pre-DNS)
    SecureDNS-->>SecureNIC: Agree on pseudo-random seed & algorithm
    SecureNIC->>SecureDNS: Send DNS request over agile channel
    deactivate SecureNIC
    SecureDNS-->>SecureNIC: Return IP over agile channel
    SecureNIC-->>OS_Kernel: Pass resolved IP to network stack
    OS_Kernel-->>UserApp: Return IP address

Variation 1.2: WebAssembly (WASM) Based Interception Proxy
- Enabling Description: The proxy functionality is implemented as a sandboxed WebAssembly module executed within the browser or a runtime environment. Instead of a system-level proxy, this WASM module intercepts DNS requests initiated by web applications (e.g., via the fetch API). It consults a policy delivered via a secure channel (e.g., HTTPS) to determine if the target domain requires a secure link. If so, the WASM module establishes a user-space VPN tunnel using WebRTC data channels or a WebSocket connection, where the signaling messages used to establish the peer connection contain the parameters for the pseudo-random sequence generation. This approach confines the security mechanism to the application layer and avoids the need for elevated system privileges.
- Diagram:
```
graph TD
    A[Web Application] -- DNS Request --> B{WASM Proxy};
    B -- Policy Lookup --> C[Secure Policy Server];
    C -- Policy (JSON/Protobuf) --> B;
    B -- Secure Link Needed? --> D{Establish Agile VPN};
    D -- WebRTC/WebSocket Handshake --> E[Remote Peer];
    E -- Agility Parameters --> D;
    A -- Data --> D;
    D -- Encapsulated & Hopped Packets --> E;
```

2. Operational Parameter Expansion

Variation 2.1: Millisecond-Scale Address Mutation for High-Frequency Trading (HFT)
- Enabling Description: This variation applies the agile protocol to an HFT environment where latency is critical. The "pseudo-randomly varying values" are not full IP addresses, which would disrupt TCP sessions, but rather specific fields within the packet header, such as the IPv6 Flow Label or an Encapsulating Security Payload (ESP) sequence number. The hopping sequence operates on a sub-millisecond timescale, with a new value used for every 10-100 packets. The "moving window of valid addresses" is maintained in the FPGA-based network cards common in HFT, allowing for line-rate packet validation (<< 1 microsecond per packet). Synchronization of the sequence is maintained via a dedicated, out-of-band channel using a high-precision clock signal (e.g., PTP or GPS-disciplined oscillator).
- Diagram:
```
stateDiagram-v2
    [*] --> Sync_Clock
    Sync_Clock --> Generating_Sequence: High-precision timer tick
    Generating_Sequence: Calculate next N flow labels
    Generating_Sequence --> Transmitting: Populate moving window
    Transmitting --> Receiving: Send burst of packets with new labels
    Receiving --> Transmitting: Acknowledge window shift
    state Transmitting {
        direction LR
        [*] --> Packet_1
        Packet_1 --> Packet_2: Use FlowLabel[i]
        Packet_2 --> Packet_n: Use FlowLabel[i+1]
    }
    state Receiving {
        direction LR
        [*] --> Validate_Packet_1: Check FlowLabel against window
        Validate_Packet_1 --> Validate_Packet_2: Accept/Reject
    }
```
Variation 2.2: Low-Power Wide-Area Network (LPWAN) Agility
- Enabling Description: For resource-constrained IoT devices on an LPWAN (e.g., LoRaWAN), full IP address hopping is infeasible due to power and bandwidth limitations. This variation adapts the protocol by hopping a much smaller device identifier within the application-layer payload. A central network server pre-provisions each device with a unique pseudo-random number generator (PRNG) seed. Upon waking, the device calculates the next valid identifier in its sequence based on the current time slot (derived from a network beacon). It transmits a small data packet (e.g., 51 bytes) with this identifier. The network server, knowing the seeds for all devices, computes the expected identifiers for all devices in that time slot and accepts the message. This provides lightweight endpoint authentication and obfuscation with minimal overhead. The "moving window" on the server side accounts for clock drift and transmission delays.
- Diagram:
```
flowchart TD
    subgraph IoT Device (Low Power)
        A[Wake from Sleep] --> B{Sync to Network Beacon};
        B --> C[Get Current Time Slot];
        C --> D[Calculate Next ID from Seed + Time];
        D --> E[Transmit Payload + Hopped ID];
    end
    subgraph Network Server
        F[Receive Packet] --> G{For each registered device...};
        G --> H[Calculate Expected ID from Seed + Time];
        H --> I{Is received ID in valid window?};
        I -- Yes --> J[Accept & Process Packet];
        I -- No --> K[Reject Packet];
    end
    E --> F;
```

3. Cross-Domain Application

Variation 3.1: Automotive - Vehicle-to-Everything (V2X) Communications
- Enabling Description: In a V2X network, vehicles and infrastructure nodes transparently establish agile communication links to broadcast safety messages (e.g., collision warnings). A vehicle's Telematics Control Unit (TCU) acts as the proxy. When it needs to communicate with a nearby vehicle or a roadside unit (RSU), it does not use its permanent MAC address or IP address. Instead, it generates a temporary, pseudo-random identifier based on a shared secret provisioned by a regional vehicle authority and synchronized via GPS time. All vehicles in a geographic area share the same algorithm. A receiving vehicle validates incoming messages by checking if the sender's identifier falls within a moving window of valid identifiers for the current time epoch. This prevents message spoofing and tracking of a vehicle's movements by its network identifiers.
- Diagram:
```
classDiagram
    class VehicleTCU {
        +permanentID: string
        -regionalSecret: key
        -gpsTime: timestamp
        +generateTemporaryID()
        +broadcastSafetyMessage(message)
        +receiveMessage(message)
    }
    class RoadsideUnit {
        -regionalSecret: key
        -gpsTime: timestamp
        +validateMessage(message): bool
    }
    VehicleTCU --|> V2X_Node
    RoadsideUnit --|> V2X_Node
    class V2X_Node {
        <<interface>>
        validateMessage()
    }
```
Variation 3.2: AgTech - Secure Irrigation Control Network
- Enabling Description: An agricultural technology system uses the agile protocol to secure communications between a central irrigation controller and thousands of wireless soil moisture sensors and valve actuators distributed across a large farm. The gateway controller, upon receiving a DNS request for its management domain, initiates an agile session over a 900 MHz mesh network. Each sensor/actuator node has a pre-shared key. The "varying data value" is a compact message authentication code (MAC) appended to each command or sensor reading, calculated using the shared key and a synchronized counter value (the sequence). The controller broadcasts a new counter value periodically. Any command received by a valve actuator with an invalid MAC (not matching the expected value based on the current counter) is ignored. This prevents attackers from issuing fraudulent commands (e.g., "open all valves") by replaying old messages or spoofing the controller.
- Diagram:
```
sequenceDiagram
    participant Controller as Central Controller
    participant Sensor as Soil Sensor
    participant Actuator as Valve Actuator

    Controller->>all: Broadcast new Counter Value (CV)
    loop Every Minute
        Sensor->>Controller: Reading + generateMAC(Reading, SharedKey, CV)
        Controller->>Actuator: Command + generateMAC(Command, SharedKey, CV)
        activate Actuator
        Actuator->>Actuator: Validate MAC(Command, SharedKey, CV)
        Note right of Actuator: If valid, execute command. Else, discard.
        deactivate Actuator
    end
```
Variation 3.3: Consumer Electronics - Smart Home Device Onboarding
- Enabling Description: When a new smart home device (e.g., a lightbulb) joins a home network, it uses an agile protocol for secure onboarding. The user's smartphone, acting as the proxy, scans a QR code on the device. The QR code contains a one-time secret. The phone intercepts the device's initial attempt to contact its cloud service via DNS. Instead, it establishes a local agile link over Wi-Fi Direct or Bluetooth LE. The "pseudo-randomly varying value" is a changing channel or frequency hopping pattern, synchronized using the one-time secret from the QR code. Over this secure, temporary link, the phone safely provisions the device with the home Wi-Fi credentials and a permanent device certificate, after which the agile link is torn down. This prevents eavesdropping on Wi-Fi credentials during the vulnerable setup phase.
- Diagram:
```
flowchart LR
    A[User scans QR code on Bulb] --> B(Phone obtains one-time secret);
    C[Bulb powers on, broadcasts setup beacon] --> D{Phone intercepts beacon};
    D -- Uses secret --> E[Establish Agile Wi-Fi Direct Link];
    subgraph Agile Link (Frequency Hopping)
        E -- Securely transmit --> F[Wi-Fi Credentials & Certificate];
    end
    F --> G[Bulb connects to Home Wi-Fi];
    G --> H(Agile Link Terminated);
```

4. Integration with Emerging Tech

Variation 4.1: AI-Driven Predictive Path Obfuscation
- Enabling Description: The agile networking protocol is integrated with an AI-based threat intelligence platform. The AI model continuously analyzes global network traffic patterns to predict likely attack vectors and reconnaissance probes. When a DNS request is intercepted for a high-value domain, the proxy not only establishes a VPN but also uses the AI's output to select the parameters for the pseudo-random sequence. For example, if the AI predicts a high likelihood of a DDoS attack from a specific geographic region, the address hopping algorithm is biased to select IP addresses from netblocks that are topologically distant from the predicted attack source, and the hop frequency is increased dynamically. The moving window size is also adjusted based on the AI's real-time assessment of network jitter and packet loss.
- Diagram:
```
graph TD
    A[Client DNS Request] --> B{Proxy Intercept};
    B --> C[AI Threat Intelligence Platform];
    C -- Real-time Risk Score & Topology Data --> B;
    B --> D{Select Agile Parameters};
    D -- Seed, Algorithm, Hop Rate --> E[VPN Tunnel Module];
    E -- Agile VPN Established --> F[Destination Server];
```
Variation 4.2: IoT Sensor-Triggered Network Agility
- Enabling Description: A secure facility's network integrates the agile protocol with its physical security system (IoT sensors). The network operates in a standard, static IP configuration by default. However, if an IoT sensor (e.g., a door tamper sensor, a geofence breach detector) is triggered, it sends an authenticated alert to a central security controller. The controller immediately instructs all network nodes (clients, servers) to switch to an agile communication mode. The trigger event itself contains the seed for the pseudo-random sequence, ensuring that only nodes that received the specific alert can communicate. This creates an "on-demand" VPN that isolates the network segment under potential physical threat, preventing an intruder who gains physical access from easily scanning or accessing the network.
- Diagram:
```
stateDiagram-v2
    state "Static IP Mode" as Static
    state "Agile IP Mode" as Agile

    [*] --> Static: Network Normal
    Static --> Agile: IoT_Sensor_Alert(seed)
    Agile --> Agile: Communication via Hopped IPs
    Agile --> Static: All_Clear_Signal
```
Variation 4.3: Blockchain-Managed Agility Policies
- Enabling Description: The policies determining which domain names trigger a secure agile link are managed on a private or permissioned blockchain. A central administrator (or a decentralized autonomous organization - DAO) proposes a new policy (e.g., "add secure.corp.com to the agile list"). This policy change is a transaction that must be validated by multiple nodes before being committed to an immutable block. Client proxies query a blockchain node via a lightweight client to retrieve the latest authoritative policy set. This provides a tamper-proof, auditable trail of all policy changes and prevents a single compromised server from pushing malicious policies (e.g., disabling security for a specific domain) to clients. The blockchain's block hash can also be used as a seed for the pseudo-random sequence, ensuring all clients are synchronized to the same sequence based on the latest state of the distributed ledger.
- Diagram:
```
erDiagram
    POLICY {
        string domainName
        string policyType
    }
    BLOCK {
        int blockID
        string blockHash
        timestamp time
    }
    TRANSACTION {
        int txID
        string payload
    }
    BLOCK ||--o{ TRANSACTION : contains
    POLICY ||..|| TRANSACTION : is_payload_of
```

5. The "Inverse" or Failure Mode

Variation 5.1: Graceful Degradation under DDoS Attack
- Enabling Description: This variation is designed to maintain system availability during a high-volume packet flood (DDoS) attack. When the proxy or gateway detects an incoming packet rate exceeding a critical threshold, it enters a "degraded agility" mode. In this mode, instead of hopping individual source/destination IP addresses, it hops entire /24 subnets. It communicates a new pair of source/destination subnets to the legitimate client via an authenticated, out-of-band channel (e.g., an SMS message or a pre-established secure websocket). The client and server then use any valid IP within those subnets. This makes it computationally harder for the attacker to adapt their flood to the new network space. While security is reduced (as the address space is more predictable), core connectivity for legitimate users is preserved until the attack subsides.
- Diagram:
```
graph TD
    A[Normal Operation: IP Hopping] --> B{DDoS Detected?};
    B -- No --> A;
    B -- Yes --> C[Enter Degraded Mode];
    C --> D[Switch to Subnet Hopping];
    D --> E[Transmit new /24 subnets to client via OOB channel];
    E --> F[Resume communication on new subnets];
    F --> G{Attack Mitigated?};
    G -- No --> D;
    G -- Yes --> A;
```
Variation 5.2: Low-Functionality "Beacon" Mode
- Enabling Description: A mobile device or sensor with limited battery life uses this mode to conserve power. Instead of maintaining a full agile VPN, the device remains in a low-power sleep state. Periodically, it wakes and transmits a single, authenticated "beacon" packet. The "pseudo-randomly varying value" is the UDP source port from which the beacon is sent. The device and a server share a synchronized list of valid source ports for the next transmission window. If the server needs to send a command to the device, it replies to the beacon's IP and hopped source port immediately. If no reply is received within a short timeout, the device returns to sleep. This allows the server to maintain "assured availability" of the device without the overhead of a persistent connection, only establishing a full data link when necessary.
- Diagram:
```
sequenceDiagram
    participant Device as Mobile Device
    participant Server as Cloud Server
    loop While Idle
        Device->>Device: Sleep(t)
        Device->>Server: Send Beacon (from hopped UDP port)
        alt Server has data for Device
            Server-->>Device: Send Command
            Device->>Device: Process Command
        else No data
            Device->>Device: Timeout, return to sleep
        end
    end
```

Combination Prior Art Scenarios

Combination 1: Integration with DNSSEC (Domain Name System Security Extensions)
- Enabling Description: The determination of whether to create a secure link is integrated with the DNSSEC validation process. An open-source DNS resolver like BIND or Unbound is modified. When a client requests a domain, the resolver performs standard DNSSEC validation to verify the authenticity of the DNS records. A new, custom resource record (e.g., a TXT record with a specific format like _agilevpn.example.com IN TXT "enabled=true; alg=sha256; seed_uri=...") is defined. If this record is present and the entire DNS response is cryptographically validated by DNSSEC, the resolver signals the client's proxy (as described in the '135 patent) to initiate the agile VPN. This combines the transport-layer security of agile networking with the DNS-layer authenticity provided by DNSSEC, ensuring that the policy to enable the VPN is itself authentic and not spoofed.
- Diagram:
```
flowchart TD
    A[Client] -- DNS Query for www.example.com --> B[DNSSEC-aware Resolver];
    B -- Fetches Records --> C[Authoritative DNS Server];
    C -- Signs Records with Private Key --> C;
    C -- Returns RRSIG + A + TXT records --> B;
    subgraph Resolver
        B1[Validate RRSIG with Public Key] --> B2{Signature Valid?};
        B2 -- Yes --> B3[Check for _agilevpn TXT Record];
        B3 -- Yes --> B4[Signal Client Proxy to start Agile VPN];
    end
    B --> A;
```
Combination 2: Integration with QUIC (Quick UDP Internet Connections)
- Enabling Description: The agile protocol is implemented over the QUIC transport protocol. QUIC, an open standard from the IETF, provides encrypted, stream-multiplexed transport over UDP. In this combination, the "pseudo-randomly varying value" is the QUIC Connection ID (CID). Clients and servers negotiate a synchronized algorithm for generating future CIDs. During a session, either party can issue a NEW_CONNECTION_ID frame, instructing the peer to start using a new CID from the pre-agreed sequence for subsequent packets. Routers and firewalls would see packets for the same logical connection appearing to come from different connection identifiers, obfuscating the session while leveraging QUIC's built-in encryption, congestion control, and resistance to head-of-line blocking.
- Diagram:
```
sequenceDiagram
    participant Client
    participant Server
    Client->>Server: Initial QUIC Handshake (establishes agility algorithm)
    Client->>Server: QUIC packets with ConnectionID_1
    Server->>Client: QUIC packets with ConnectionID_A
    Server->>Client: NEW_CONNECTION_ID frame (propose ConnectionID_B)
    Client->>Server: Acknowledge, switch to sending to ConnectionID_B
    Client->>Server: QUIC packets with ConnectionID_2
    Note over Client,Server: External observer sees multiple unrelated UDP flows
```
Combination 3: Integration with WireGuard
- Enabling Description: The simple and open-source WireGuard VPN protocol is used as the underlying secure tunnel, but it is modified to support agile addressing. A small daemon runs alongside the standard WireGuard process. This daemon is responsible for managing the agility algorithm. Periodically, or upon a trigger, the daemon uses a control interface (e.g., wg-quick scripting hooks) to change the Endpoint IP address in the peer configuration of the WireGuard interface. The agility daemon on the server side simultaneously updates its firewall rules to accept incoming WireGuard packets from the new client IP address. The public keys (PublicKey) remain the same, providing continuous cryptographic identity, but the underlying routable IP endpoints change according to the pseudo-random sequence, combining WireGuard's cryptographic strength with the network-level obfuscation of the '135 patent.
- Diagram:
```
graph BT
    subgraph Client Machine
        A[Agility Daemon] -- "wg set wg0 peer... endpoint=NEW_IP" --> B[WireGuard Interface (wg0)];
        C[User Traffic] --> B;
    end
    subgraph Server Machine
        E[Agility Daemon] -- "firewall-cmd --add-source=NEW_IP" --> D[Firewall];
        F[WireGuard Interface (wg0)] --> D;
    end
    B -- Encapsulated UDP Packet --> G((Internet));
    G --> D;
    A -- Sync Channel --> E;
```