Derivative works — US Patent 11582343

As a Senior Patent Strategist and Research Engineer specializing in Defensive Publishing, I present the following defensive disclosure document for US Patent 11582343. The objective is to establish prior art for foreseeable incremental improvements, thereby rendering them obvious or non-novel. The derivatives are based on the core independent claims of the '343 patent, which describe a Residential Gateway (RCG) device and a method for multipath communication, notably through POTS line aggregation via a wireless interface or direct broadband wireless access.

Defensive Disclosure for US Patent 11582343

This document discloses various derivative embodiments and operational paradigms of the "Devices and methods for multipath communications" described in US Patent 11582343. These disclosures aim to cover obvious extensions and modifications that a person having ordinary skill in the art (PHOSITA) would reasonably envision given the state of technology and the problem statement addressed by the '343 patent.

Claim 1 Derivatives: Residential Gateway (RCG) Device

Original Claim 1 Summary: An RCG device for multipath communication with a POTS line interface, modem, wireless interface (e.g., 802.11b/g), and a processor configured to monitor the wireless interface for other RCGs or access points to establish a multilink data connection (combining multiple POTS lines) or connect directly to a broadband wireless access point.

1. Material & Component Substitution

Derivative 1.1: Fiber-Optic/VDSL-Enabled RCG with Millimeter-Wave Wireless Backhaul

Enabling Description: This derivative replaces the legacy POTS modem interface with a multi-standard xDSL (e.g., VDSL2, G.fast) transceiver module or a dedicated Fiber-Optic Network Termination (ONT) module, providing higher-speed wired access to the dwelling. The 802.11b/g wireless interface is upgraded to a high-frequency millimeter-wave (mmWave) wireless module (e.g., 802.11ad/ay or 5G NR FR2) capable of multi-gigabit speeds for local RCG-to-RCG aggregation or direct backhaul to a mmWave access point. The processor features a dedicated network function virtualization (NFV) accelerator for dynamic instantiation of network slices and real-time QoS management across diverse physical layers. Power over Ethernet (PoE) or Power over Fiber (PoF) is integrated for simplified deployment.
```
graph TD
    A[External Fiber/Copper Drop] --> B(Fiber/xDSL ONT/Transceiver)
    B --> C{RCG Processor (NFV-accelerated)}
    C --> D(mmWave Wireless Module)
    D --> E[Other RCGs / mmWave AP]
    C --> F(Internal LAN Switch / Wi-Fi 6E)
    F --> G[Local Devices]
    B --(Optional)--> H[POTS Line Interface (Lifeline Only)]
```

Derivative 1.2: GaN-Based RF Front-End and Li-Fi Interface with Flexible OLED Display

Enabling Description: This RCG incorporates Gallium Nitride (GaN) power amplifiers and low-noise amplifiers in its RF front-end for improved efficiency and higher transmit power on the wireless interface (e.g., Wi-Fi 6/7). Instead of, or in addition to, traditional RF wireless, the device integrates a Light Fidelity (Li-Fi) module for secure, high-speed indoor communication. The Li-Fi interface utilizes high-bandwidth LED lighting fixtures for data transmission and photodiodes for reception. The user interface features a flexible Organic Light Emitting Diode (OLED) display that can conform to surfaces or be rolled for portability, enhancing user interaction while reducing power consumption. The modem for the POTS line uses an advanced DSP-based softmodem architecture for improved performance under line impairments.
```
graph TD
    A[POTS Line Interface] --> B(DSP Softmodem)
    B --> C{RCG Processor}
    C --> D(GaN RF Front-End + Wi-Fi 7 Module)
    C --> E(Li-Fi Transceiver Module)
    E --> F[LED Light Fixture / Photodiode]
    C --> G(Flexible OLED Display)
    D --&gt; H[Wireless Devices (RF)]
```

2. Operational Parameter Expansion

Derivative 2.1: Ultra-Low-Power RCG for Remote Agricultural/Environmental Monitoring (Sub-1GHz & Satellite)

Enabling Description: This RCG is designed for remote, off-grid deployments in agricultural or environmental monitoring. It operates at extremely low power (milliwatts), powered by integrated solar panels and long-duration solid-state batteries. The POTS line is replaced by a low-bandwidth, low-power, sub-1GHz wireless transceiver (e.g., LoRaWAN or Sigfox) for terrestrial long-range data collection. The primary long-haul backhaul is achieved via a low-Earth orbit (LEO) satellite modem (e.g., Starlink, Iridium SBD) for global connectivity in areas without terrestrial infrastructure. The processor, an ultra-low-power microcontroller, aggregates sensor data (temperature, humidity, soil pH) and opportunistically transmits over either the sub-1GHz mesh or satellite link, prioritizing emergency alerts.
```
graph TD
    A[Environmental Sensors] --> B(Ultra-Low-Power Microcontroller)
    B --> C(LoRaWAN/Sigfox Transceiver)
    B --> D(LEO Satellite Modem)
    C --&gt; E[LoRaWAN Gateway / Other RCG Nodes]
    D --&gt; F[Satellite Constellation]
    G[Solar Panel] --> H(Battery Management)
    H --> B
```

Derivative 2.2: Industrial-Scale RCG Array for Smart City Infrastructure (Terahertz & Quantum Key Distribution)

Enabling Description: This RCG operates as a node in a city-wide mesh network, designed for industrial-scale deployment, handling massive data flows from smart city sensors and devices. Communication occurs at terahertz (THz) frequencies for ultra-high-bandwidth, short-range point-to-point links between RCGs on lampposts or buildings. For critical control plane communication and secure data aggregation, it integrates a quantum key distribution (QKD) module, generating and distributing encryption keys using quantum properties to ensure unconditional security against eavesdropping. Wired backhaul to the core network is provided via redundant 100Gbps optical fiber connections.
```
graph TD
    A[Smart City Sensors / Devices] --> B(Industrial RCG Processor)
    B --> C(Terahertz (THz) Transceiver)
    B --> D(Quantum Key Distribution Module)
    D --> E[Quantum Network Node]
    C --&gt; F[Other RCG Nodes (THz)]
    B --> G(100Gbps Optical Fiber Interface)
    G --> H[City Core Network]
```

3. Cross-Domain Application

Derivative 3.1: Medical Wearable RCG for Continuous Patient Monitoring

Enabling Description: This RCG is integrated into a wearable medical device (e.g., a smart patch or wristband). It aggregates physiological data from multiple on-body sensors (ECG, glucose, blood pressure, oxygen saturation). The device uses a low-power Bluetooth Low Energy (BLE) connection for local data collection. For remote transmission, it intelligently selects between an integrated cellular modem (e.g., LTE-M, NB-IoT) for continuous background updates and a local Wi-Fi interface (802.11ax) for high-bandwidth data bursts when a trusted Wi-Fi network (e.g., at home or hospital) is available, prioritizing critical alerts over the most reliable path. A secure, encrypted tunnel is maintained to a cloud-based health monitoring platform.
```
graph TD
    A[On-Body Sensors] --> B(Wearable RCG Microcontroller)
    B --> C(Bluetooth Low Energy (BLE))
    C --> A
    B --> D(Integrated Cellular Modem)
    B --> E(Wi-Fi 6 (802.11ax) Module)
    D --&gt; F[Cellular Network]
    E --&gt; G[Local Wi-Fi AP]
    F & G --> H[Cloud Health Platform]
```

Derivative 3.2: AgTech RCG for Precision Agriculture Drone/Sensor Swarm Management

Enabling Description: This RCG functions as a mobile base station for precision agriculture, deployed on autonomous ground vehicles or drones. It manages a swarm of agricultural sensors (soil moisture, nutrient levels, crop health imaging) and smaller drones via a robust, frequency-hopping mesh wireless network (e.g., custom 900MHz ISM band protocol or LoRa mesh). For backhauling aggregated data, the RCG dynamically selects between a private 5G mmWave network (if available on the farm) or a satellite uplink (e.g., VSAT terminal) for large data uploads like hyperspectral imagery. The system optimizes route planning for data collection and resource deployment.
```
graph TD
    A[Agricultural Sensors / Mini-Drones] --> B(AgTech RCG Processor)
    B --> C(Frequency-Hopping Mesh Wireless (900MHz))
    C --> A
    B --> D(Private 5G mmWave Module)
    B --> E(VSAT Satellite Uplink)
    D --&gt; F[Private 5G Network Infrastructure]
    E --&gt; G[Geostationary Satellite]
    F & G --> H[Cloud Analytics / Farm Management System]
```

Derivative 3.3: Maritime RCG for Offshore Asset Tracking and Environmental Monitoring

Enabling Description: This RCG is designed for robust operation on maritime assets (buoys, cargo containers, autonomous vessels). It collects telemetry from onboard sensors (GPS, weather, water quality, motion). For local data relay and short-range asset tracking, it employs a robust sub-gigahertz wireless link (e.g., 433MHz or 868MHz ISM band with spread spectrum). For primary communication, it features an always-on Inmarsat or Iridium satellite modem. When within range of shore-based infrastructure, it automatically switches to a high-speed Long-Range Wi-Fi (e.g., 802.11ah HaLow) or cellular (e.g., 5G CBRS) link for efficient data offloading, prioritizing safety and navigation alerts.
```
graph TD
    A[Onboard Sensors (GPS, Weather)] --> B(Maritime RCG Processor)
    B --> C(Sub-GHz Wireless Link)
    C --> D[Other Maritime Assets / Local Sensors]
    B --> E(Inmarsat/Iridium Satellite Modem)
    B --> F(Long-Range Wi-Fi / 5G CBRS Module)
    E --&gt; G[Satellite Network]
    F --&gt; H[Shore-based Network / Cellular Tower]
    G & H --> I[Fleet Management / Monitoring Center]
```

4. Integration with Emerging Tech

Derivative 4.1: AI-Optimized RCG with Dynamic Link Aggregation and Predictive QoS

Enabling Description: This RCG integrates an embedded AI/ML inference engine (e.g., a TinyML-capable neural network accelerator) that continuously monitors network conditions (latency, jitter, packet loss, bandwidth utilization) across all available links (POTS, local wireless mesh, broadband wireless AP, cellular dongle). The AI model predicts future network congestion and dynamically reconfigures the multilink bundle (e.g., using MPTCP at the transport layer, or proprietary link aggregation protocols at lower layers) by adding or removing links, adjusting traffic priorities, and selecting optimal routing paths to maintain user-defined QoS for applications like 4K video streaming or real-time gaming. It can also preemptively establish new links if predicted congestion requires it.
```
graph TD
    A[Network Monitoring (Latency, Jitter)] --> B(AI/ML Inference Engine)
    C[Application QoS Requirements] --> B
    D[Available Links (POTS, Wi-Fi, 5G)] --> B
    B --> E{Dynamic Link Aggregation Module}
    E --> F[POTS Modem]
    E --> G[Wireless Module]
    E --> H[Cellular Module]
    I[Traffic Manager] --> E
    B --> I
```

Derivative 4.2: IoT Gateway RCG with Secure Edge Compute and Blockchain Verification

Enabling Description: This RCG acts as an intelligent IoT gateway, integrating a secure element (e.g., Trusted Platform Module) and a blockchain client. It collects data from a diverse array of local IoT sensors (Zigbee, Z-Wave, Thread, Matter) and performs edge computing tasks like local analytics and anomaly detection. Data destined for the cloud is bundled into cryptographically signed transactions, verified against a private or public blockchain ledger to ensure data integrity and provenance before transmission over aggregated POTS lines or broadband wireless. This provides immutable records of sensor readings for applications such as smart home insurance or verified environmental compliance. Multi-signature schemes can be enforced for critical device control commands.
```
graph TD
    A[IoT Sensors (Zigbee, Z-Wave)] --> B(IoT RCG Processor)
    B --> C(Edge Compute / Analytics)
    B --> D(Secure Element / Blockchain Client)
    D --> E[Blockchain Ledger]
    B --> F[Multilink POTS / Broadband Wireless]
    F --> G[Cloud Services]
    D --&gt; G
```

5. The "Inverse" or Failure Mode

Derivative 5.1: Fail-Safe RCG with Graded Degration and Emergency Communications Protocol

Enabling Description: This RCG is designed for robust operation during power outages or network failures. It features a tiered power management system including a supercapacitor bank for short-term backup and an auxiliary low-power long-duration battery. Upon detection of primary power loss, it enters a "graded degradation" mode:
1. Stage 1 (Partial Power Loss): Disables high-bandwidth data aggregation, maintaining only essential voice (VoIP over POTS) and critical alert data (e.g., security system, medical alert). Wireless interface operates in a low-power beaconing mode to preserve battery and allow peer discovery.
2. Stage 2 (Extended Power Loss): Wireless interface is fully disabled. RCG reverts to a "lifeline-only" mode, bypassing internal circuitry for direct POTS voice communication, as per the original patent, but also activating a small, integrated e-ink display to provide emergency instructions or battery status.
3. Emergency Protocol: During severe network outages, the RCG activates a pre-configured emergency communications protocol (e.g., sending short bursts of critical data via a low-bandwidth satellite link or amateur radio packet network if equipped) to a designated emergency contact or service.
```
stateDiagram-v2
    [*] --> Normal_Operation
    Normal_Operation --> Power_Loss : Primary Power Lost
    Power_Loss --> Graded_Degradation_Stage1 : Detect Power Loss
    Graded_Degradation_Stage1 --> Graded_Degradation_Stage2 : Battery Threshold Low
    Graded_Degradation_Stage2 --> Lifeline_Only : Battery Critical
    Lifeline_Only --> Emergency_Comm_Protocol : Local Network Unavailable
    Emergency_Comm_Protocol --> Lifeline_Only : Emergency Sent
    Lifeline_Only --> Normal_Operation : Power Restored
    Graded_Degradation_Stage1 --> Normal_Operation : Power Restored
    Graded_Degradation_Stage2 --> Normal_Operation : Power Restored

    state Normal_Operation {
        Full_Bandwidth_Aggregation
        All_Services_Active
    }
    state Graded_Degradation_Stage1 {
        VoIP_over_POTS_Only
        Critical_Alerts_Data
        Low_Power_Wireless_Beacon
    }
    state Graded_Degradation_Stage2 {
        Wireless_Disabled
        POTS_Voice_Only
        eInk_Display_Active
    }
    state Lifeline_Only {
        Direct_POTS_Bypass
    }
    state Emergency_Comm_Protocol {
        Low_Bandwidth_Satellite/Amateur_Radio
    }
```

Derivative 5.2: Limited-Functionality "Guest Mode" RCG with Bandwidth Caps and Anonymous Access

Enabling Description: This RCG offers a "Guest Mode" for temporary users or devices, implementing strict bandwidth caps and limited functionality. In this mode, the RCG prevents the guest from initiating or participating in multilink PPP bundles, thus protecting the primary user's aggregated bandwidth. Guest wireless access is provided through a separate VLAN with an enforced Quality of Service (QoS) profile that guarantees minimal impact on primary user services. Data from guest devices is anonymized or sandboxed locally, without being aggregated or contributing to the primary user's data usage statistics. The wireless interface can create an isolated "guest Wi-Fi" SSID with configurable access duration and data limits.
```
graph TD
    A[RCG Processor] --> B{Access Control Module}
    B --> C[Primary User Network]
    C --> D(Full Bandwidth / Multilink)
    B --> E[Guest Network (VLAN)]
    E --> F(Bandwidth Capped / Isolated)
    G[Wireless Interface] --&gt; H[Primary SSID]
    G --&gt; I[Guest SSID]
    H --&gt; C
    I --&gt; E
    A --> J(Local Storage for Guest Data Sandboxing)
```

Claim 11 Derivatives: Method for Multipath Communication

Original Claim 11 Summary: A method for providing multipath communication using an RCG device, comprising connecting the RCG to a POTS line and telephone, establishing a modem connection over POTS, monitoring the wireless interface for other RCGs or access points, and upon detection, initiating a multilink PPP session (combining POTS lines of multiple RCGs) or a direct connection to a broadband wireless access point.

1. Material & Component Substitution (Method perspective)

Derivative 11.1: Method using Satellite Modems for Multilink Aggregation in Remote Areas

Enabling Description: This method replaces POTS lines with multiple LEO satellite modem connections as the primary "last mile" links. The RCG, equipped with multiple satellite modems and directional antennas, establishes individual satellite links. Instead of an 802.11b/g wireless interface for local RCG-to-RCG coordination, a dedicated mesh radio (e.g., custom 2.4GHz FHSS) coordinates the aggregation. The processor then initiates a multilink PPP session by dynamically bundling these independent satellite modem connections, managing varying latency and packet loss inherent in satellite communications, to provide aggregated broadband services to a remote location.

sequenceDiagram
    participant A as RCG (Initiating)
    participant B as RCG (Remote 1)
    participant C as RCG (Remote N)
    participant S as Satellite Constellation
    participant D as Destination URL
    
    A->>A: Detect need for high bandwidth
    A->>A: Scan for remote RCGs via Mesh Radio
    A->>B: Request Sat Modem Link (Mesh Radio)
    B->>B: Check local Sat Modem availability
    B-->>A: Offer Sat Modem Link (Mesh Radio)
    A->>C: Request Sat Modem Link (Mesh Radio)
    C->>C: Check local Sat Modem availability
    C-->>A: Offer Sat Modem Link (Mesh Radio)
    A->>D: Initiate Multilink PPP Session (via A's Sat Modem)
    D-->>A: Multilink PPP Session ID (Magic Number)
    A->>B: Send Multilink Init Packet (Mesh Radio)
    B->>S: Establish Sat Modem Connection
    B->>D: Request to add link to Multilink PPP (with Magic Number)
    D-->>B: Acknowledge Link Addition
    A->>C: Send Multilink Init Packet (Mesh Radio)
    C->>S: Establish Sat Modem Connection
    C->>D: Request to add link to Multilink PPP (with Magic Number)
    D-->>C: Acknowledge Link Addition
    D->>S: Send Data Packets to B & C
    D->>S: Send Data Packets to A
    S->>B: Relay Data Packets
    S->>C: Relay Data Packets
    S->>A: Relay Data Packets
    B->>A: Relay Data Packets (Mesh Radio)
    C->>A: Relay Data Packets (Mesh Radio)
    A->>A: Reassemble Data Packets

2. Operational Parameter Expansion (Method perspective)

Derivative 11.2: Method for Dynamic Link Allocation Across Heterogeneous Networks in Emergency Response

Enabling Description: This method is employed by an RCG acting as a mobile command post in an emergency response scenario. The RCG's processor continuously monitors and ranks available network links: high-bandwidth (e.g., 5G mmWave cellular, Starlink satellite), medium-bandwidth (e.g., CBRS private LTE, bonded DSL over available copper), and low-bandwidth (e.g., LoRaWAN, amateur radio data). Depending on the severity of the emergency and the type of data (e.g., real-time video, critical health metrics, SMS alerts), the RCG dynamically allocates traffic to the best available path or initiates a multilink aggregation session across a combination of heterogeneous links. This includes opportunistic "scavenging" of unused bandwidth from neighboring RCGs (or similar mobile nodes) via a secure, ad-hoc wireless mesh network.
```
flowchart TD
    A[Emergency RCG Activated] --> B{Monitor Available Links}
    B --> C{Rank Links by Bandwidth, Latency, Reliability}
    C --> D{Evaluate Data Priority & Type}
    D --&gt; E{Decision: Single Link or Multilink Aggregation?}
    E --&gt;|Single Link| F[Transmit over Best Link]
    E --&gt;|Multilink Aggregation| G[Identify Candidate Links (Heterogeneous)]
    G --> H{Initiate Aggregation Protocol (e.g., MPTCP, custom L2 bundling)}
    H --> I[Transmit Data over Bundled Links]
    I --&gt; J[Cloud/Command Center]
    subgraph Link Monitoring
        K[5G mmWave]
        L[Starlink Satellite]
        M[CBRS Private LTE]
        N[Bonded DSL]
        O[LoRaWAN]
        P[Amateur Radio Data]
        Q[Neighboring RCGs (Ad-Hoc Mesh)]
    end
    B --&gt; K & L & M & N & O & P & Q
```

3. Cross-Domain Application (Method perspective)

Derivative 11.3: Method for Secure Data Backhaul in Remote Industrial IoT Deployments

Enabling Description: This method describes an RCG deployed in a remote industrial setting (e.g., oil & gas pipeline monitoring, remote mining operations). The RCG is connected to a local industrial sensor network (e.g., WirelessHART, ISA100.11a). It aggregates encrypted sensor data locally. The method involves:

Continuously monitoring for available communication paths, which include multiple cellular connections (different carriers for redundancy), a dedicated licensed radio link (e.g., MAS, WiMAX), and a satellite VSAT link.
Prioritizing the licensed radio link for real-time control commands due to its low latency and guaranteed QoS.
For bulk sensor data and video streams, initiating a secure, encrypted multilink VPN tunnel over multiple cellular connections, dynamically adding or removing cellular links based on signal strength and congestion.
Falling back to the VSAT link for all critical data if terrestrial links fail, maintaining a minimum guaranteed bandwidth for operational continuity.

sequenceDiagram
    participant RCG as Industrial RCG
    participant S as Industrial Sensors
    participant C1 as Cellular Network 1
    participant C2 as Cellular Network 2
    participant L as Licensed Radio Link
    participant V as VSAT Satellite
    participant H as Central Control Hub

    RCG->>S: Collect Encrypted Data
    RCG->>RCG: Aggregate & Prioritize Data

    RCG->>L: Monitor Licensed Radio Link
    alt If Licensed Radio available & data is control
        RCG->>L: Transmit Control Commands
        L->>H: Deliver Control Commands
    end

    RCG->>C1: Monitor Cellular 1
    RCG->>C2: Monitor Cellular 2
    alt If Bulk Data & multiple Cellular available
        RCG->>RCG: Initiate Multilink VPN over C1+C2
        RCG->>C1: Transmit Data (Link 1 of Bundle)
        RCG->>C2: Transmit Data (Link 2 of Bundle)
        C1->>H: Deliver Data
        C2->>H: Deliver Data
    end

    RCG->>V: Monitor VSAT Link
    alt If Terrestrial Links Fail
        RCG->>V: Transmit Critical Data (Fallback)
        V->>H: Deliver Critical Data
    end

4. Integration with Emerging Tech (Method perspective)

Derivative 11.4: Method for Blockchain-Verified Bandwidth Resource Sharing using Smart Contracts

Enabling Description: This method enables RCGs to participate in a decentralized bandwidth marketplace. When an initiating RCG requires additional bandwidth for a multilink PPP session, it broadcasts a request on a local blockchain-enabled network. Remote RCGs, after assessing their local bandwidth availability (via an AI/ML-driven resource scheduler), respond with an offer governed by a smart contract specifying price, duration, and QoS guarantees. The initiating RCG selects an offer, and a microtransaction is recorded on the blockchain. Data relay through participating RCGs is continuously monitored, and successful data transfer is cryptographically attested to and recorded on the blockchain, triggering payment release from the smart contract. This decentralizes the "service provider" role and monetizes idle bandwidth.

sequenceDiagram
    participant IR as Initiating RCG
    participant RR1 as Remote RCG 1
    participant RR2 as Remote RCG 2
    participant BC as Blockchain Network
    participant DS as Data Source (URL)

    IR->>IR: Detect need for more bandwidth
    IR->>BC: Broadcast Bandwidth Request (Smart Contract Trigger)
    RR1->>RR1: Check local bandwidth (AI-driven)
    RR1->>BC: Offer Bandwidth (Smart Contract Proposal)
    RR2->>RR2: Check local bandwidth (AI-driven)
    RR2->>BC: Offer Bandwidth (Smart Contract Proposal)

    IR->>IR: Evaluate Offers (from BC)
    IR->>BC: Accept RR1's Offer (Smart Contract Execution - Funds Locked)

    IR->>RR1: Send Multilink Init (Wireless)
    RR1->>DS: Add link to Multilink PPP
    DS-->>RR1: Data Flow Started
    RR1->>IR: Relay Data (Wireless)

    IR->>BC: Attest to Data Delivery (Smart Contract Trigger)
    BC->>RR1: Release Payment (from locked funds)
    note right of BC: Transaction Recorded

5. The "Inverse" or Failure Mode (Method perspective)

Derivative 11.5: Method for Adversarial Environment Communication with Covert Channel Establishment

Enabling Description: This method is for an RCG operating in an adversarial environment where overt communication paths are monitored or susceptible to jamming. When the RCG detects compromised primary links (e.g., through active probing, high interference, or pre-programmed threat models), it initiates a "covert channel" mode. Instead of directly aggregating bandwidth, it utilizes multiple low-bandwidth, difficult-to-detect communication methods, potentially including:
1. Steganographic data embedding: Hiding data in seemingly innocuous regular traffic (e.g., embedding critical alerts into DNS queries or NTP traffic patterns over a POTS modem, or modulating data into ambient Wi-Fi noise).
2. Frequency hopping / spread spectrum on unlicensed bands: Using a custom, rapidly changing frequency hopping pattern on an ISM band wireless link to evade detection and jamming.
3. Encrypted one-time pad burst transmissions: Storing encrypted data and sending it in very short, high-power bursts over an irregular schedule, potentially leveraging multiple remote RCGs as relays, with each relay adding a layer of encryption and using different, hard-to-trace paths.
  The goal is to maintain minimal, but highly resilient, communication rather than high bandwidth.
```
stateDiagram-v2
    [*] --> Normal_Communication
    Normal_Communication --> Adversarial_Mode : Detect Link Compromise / Jamming
    Adversarial_Mode --> Steganographic_Channel : High Surveillance
    Adversarial_Mode --> FHSS_Covert_Link : Active Jamming
    Adversarial_Mode --> Burst_Transmission_Relay : Severe Network Outage

    state Normal_Communication {
        Multilink_PPP
        Broadband_AP_Direct
    }
    state Adversarial_Mode {
        Data_Prioritization
        Encryption_Emphasis
    }
    state Steganographic_Channel {
        Hiding_Data_in_DNS/NTP_traffic
        Modulating_data_into_ambient_Wi-Fi_noise
    }
    state FHSS_Covert_Link {
        Custom_Frequency_Hopping_Pattern
        Spread_Spectrum_Transmission
    }
    state Burst_Transmission_Relay {
        One_Time_Pad_Encryption
        Short_High_Power_Bursts
        Multi_Hop_RCG_Relay
    }
```

Combination Prior Art Scenarios with Open-Source Standards

Here are three scenarios combining the principles of US11582343 with existing open-source standards, demonstrating the obviousness of further developments:

RCG with OpenWrt for Multilink PPP Orchestration:
- Description: An RCG device (as described in Claim 1) is implemented using commodity hardware running the open-source OpenWrt firmware. The core logic for "monitoring the wireless interface for other compatible RCGs" and "establishing a multilink data connection" or "connecting directly to a broadband wireless access point" is realized through custom scripts and daemon processes integrated into OpenWrt's networking stack. Specifically, the multilink PPP functionality leverages Linux's native PPP daemon capabilities, extended with wireless-aware discovery (e.g., using iw commands to scan 802.11 networks) and dynamic link management algorithms (e.g., adjusting pppd parameters) that could be exposed via OpenWrt's LuCI web interface or ubus API. This demonstrates that the control and routing aspects could be implemented on readily available, modifiable open-source platforms.
- Relevance: This combination makes the software implementation details for managing such a system obvious to a PHOSITA familiar with open-source router operating systems.
Multi-Path TCP (MPTCP) for Enhanced Data Aggregation:
- Description: The method of Claim 11, which involves "initiating a multilink PPP session by combining the POTS lines of multiple RCGs," is extended to utilize the open-source Multipath TCP (MPTCP) protocol (standardized in RFC 6824, though development and research existed prior). Instead of bundling links solely at Layer 2 (PPP), the RCGs' operating system kernel (e.g., Linux, which has MPTCP support) is configured to establish MPTCP sessions. This allows a single TCP connection to leverage multiple underlying network paths simultaneously, effectively aggregating bandwidth from different POTS lines (each connected to a different RCG and thus appearing as a distinct network interface) and/or a direct broadband wireless connection. The RCG's processor (Main CPU 19) would manage the MPTCP subflows based on real-time path characteristics.
- Relevance: MPTCP is a well-known open standard for aggregating heterogeneous paths. Applying it to the RCG's described multipath communication problem provides a clear, non-novel extension for transport-layer bandwidth aggregation and resilience.
RCG with FreeRADIUS for Centralized Authentication and Bandwidth Policy:
- Description: The RCG (Claim 1) and its method of establishing network connections (Claim 11) relies on a "username/password verification server." An open-source FreeRADIUS server is deployed by the service provider to handle authentication, authorization, and accounting (AAA) for both the POTS modem connections and the wireless access point connections (e.g., WPA2 Enterprise authentication for 802.11). FreeRADIUS can be configured with dynamic policies, allowing the service provider to centralize control over which RCGs can participate in multilink bundles, the allowed aggregate bandwidth, and to authenticate individual POTS line usage. This integrates the RCG's connection establishment with a widely adopted open-source authentication framework.
- Relevance: The use of open-source AAA servers like FreeRADIUS for network access control is a standard practice, making its integration with the RCG's connection management an obvious design choice for network operators.