Patent 9350649

Derivative works

Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.

Active provider: Google · gemini-2.5-flash

Derivative works

Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.

✓ Generated

Defensive Disclosure for US Patent 9350649

This document outlines defensive disclosures intended to establish prior art for derivative variations of the inventions described in US Patent 9350649, thereby making future incremental improvements by competitors obvious or non-novel. These disclosures are organized by independent claim and a set of derivation axes.

Core Claim 1: RCG Device with VoIP and Prioritized Voice over Single POTS Line

Claim 1 Recap: A Residential Communications Gateway (RCG) device comprising a POTS connection from a LEC, a modem for a continuous internet connection over the POTS line, a processor, at least two telephone output ports (at least one with a unique telephone number), a wireless interface for home networking, wherein the processor provides VoIP services for connected telephones and prioritizes voice data over other data packets for transmission via the continuous internet connection.

1. Material & Component Substitution

Derivative 1.1: Fiber-Optic POTS Emulation with Solid-State Relays

  • Enabling Description: The traditional copper POTS line interface (e.g., SLIC/CODEC) is replaced by a fiber-optic to electrical interface module, emulating POTS signaling and impedance characteristics over an Optical Network Terminal (ONT) or similar fiber access device. The modem function is adapted to operate over a virtualized POTS channel provisioned on the fiber link, maintaining an always-on IP connection. Mechanical relays for lifeline functionality are substituted with solid-state relays (e.g., MOSFET-based switches) capable of microsecond switching times, ensuring rapid failover to the emulated POTS lifeline path. The wireless interface utilizes Gallium Nitride (GaN) power amplifiers for enhanced efficiency and range in 802.11ax/be transceivers.
  • Mermaid Diagram:
    graph TD
    A[Fiber Optic Line (FTTH)] --> B{ONT/Fiber-POTS Emulation Module}
    B --> C(Virtualized POTS Line)
    C --> D[Solid-State SLIC/CODEC]
    D --> E(DSP Engine)
    E --> F(Main CPU - Processor)
    F --> G[Software Modem (V.92 Emulation)]
    G --> H(VoIP Module)
    H --> I(Prioritization Engine)
    I --> J[Fiber-Optic Network Interface]
    F --> K[Solid-State Relay Lifeline Switch]
    K --> C
    F --> L[802.11ax/be Wireless Module w/GaN PA]
    L --> M(Wireless Home Network)
    D --> N[Telephone Output Ports]
    J --> O(Internet/Service Provider Network)

Derivative 1.2: Liquid Crystal Polymer Enclosure with Integrated Antennas and MEMS Microphone Array

  • Enabling Description: The RCG device chassis is constructed from Liquid Crystal Polymer (LCP) composites, enabling thinner form factors and improved RF transparency for integrated antenna structures. The 802.11 wireless interface utilizes embedded LCP-based patch antennas, minimizing external protrusions and improving signal integrity. The microphone component of the speakerphone feature (if present) is replaced by a Micro-Electro-Mechanical Systems (MEMS) microphone array, offering superior noise cancellation and beamforming capabilities for enhanced voice quality. The internal interconnects use flexible printed circuits (FPCs) with silver nanowire conductors for reduced size and improved electrical performance.
  • Mermaid Diagram:
    classDiagram
    class RCG_Device {
        +LCP_Chassis chassis
        +Embedded_LCP_Antennas antennas
        +MEMS_Microphone_Array micArray
        +Flexible_PCBs internalConnections
        +POTS_Interface potsInterface
        +Soft_Modem modem
        +Main_CPU processor
        +DSP_Engine dsp
        +VoIP_Module voip
        +Wireless_Module wireless
        +Telephone_Ports telephonePorts
    }
    RCG_Device --o LCP_Chassis
    RCG_Device --o Embedded_LCP_Antennas
    RCG_Device --o MEMS_Microphone_Array
    RCG_Device --o Flexible_PCBs

2. Operational Parameter Expansion

Derivative 1.3: Industrial-Grade RCG for Remote Site Monitoring with Satellite Backhaul

  • Enabling Description: The RCG is adapted for industrial environments, operating within a temperature range of -40°C to +85°C, with IP67 ingress protection. The POTS modem operates at a lower but robust speed (e.g., V.34 at 28.8 Kbps) over long-haul copper lines (up to 20 km) to connect remote sensors and control systems. The "always-on" connection is maintained via a primary POTS dial-up and a secondary low-bandwidth satellite modem (e.g., Iridium SBD) for redundancy in remote areas. Voice prioritization algorithms are enhanced to guarantee real-time data transmission for critical alarms (e.g., Modbus over IP) alongside voice, using adaptive forward error correction (FEC) for noisy POTS channels. The device operates with a lower power consumption profile, primarily solar-powered with battery backup.
  • Mermaid Diagram:
    flowchart TD
    A[Remote Industrial Site] --> B(Industrial RCG)
    B --> C{POTS Line (Long Haul)}
    C -- Primary Data/VoIP --> D(Local Class 5 Office)
    D --> E(Service Provider Network)
    B --> F{Satellite Uplink/Downlink}
    F -- Secondary Data --> G(Satellite Network)
    G --> E
    B --> H[Ruggedized Telephone Interface]
    B --> I[RS-485/Ethernet for Industrial Sensors]
    I --> J(Modbus/SCADA Devices)
    E --> K(Internet)
    subgraph Industrial RCG Operations
        B_CPU[Main CPU] --> B_MODEM[POTS Modem (V.34)]
        B_CPU --> B_SAT[Satellite Modem (Iridium SBD)]
        B_CPU --> B_VOIP[VoIP Engine w/Adaptive FEC]
        B_CPU --> B_PRIO[Prioritization for Voice/Alarms]
        B_CPU --> B_TEMP[Temp. Mgmt (-40°C to +85°C)]
        B_CPU --> B_POWER[Solar/Battery Power Management]
    end

Derivative 1.4: High-Frequency, Multi-Channel RCG for Broadcast Quality Audio

  • Enabling Description: This RCG variant targets professional audio applications, supporting high-fidelity voice transmission up to 20 kHz bandwidth (well beyond typical POTS voiceband) through advanced CODECs (e.g., Opus in wideband mode) and a custom high-speed data-over-POTS solution. The "POTS" connection here implies a dedicated, high-quality copper pair with a specialized modem operating at frequencies up to 1 MHz, providing burst data rates significantly higher than V.92 for studio-quality audio streaming. Multiple concurrent voice channels (e.g., 6-8 channels) are supported with guaranteed low-latency (sub-20ms) and jitter-free performance, using strict QoS (Quality of Service) and packet scheduling. The wireless interface supports low-latency 60 GHz (802.11ad/ay) for uncompressed audio streaming within a local studio environment.
  • Mermaid Diagram:
    sequenceDiagram
    participant User_Phone as User Phone (High-Fidelity)
    participant HFRCG as High-Frequency RCG
    participant DSP as DSP Engine (Opus WB)
    participant CustomModem as Custom POTS Modem (>V.92)
    participant SPNet as Service Provider Network
    participant FarEnd as Far-End Recipient

    User_Phone->>HFRCG: Off-hook/Dial (Analog Audio)
    HFRCG->>DSP: Convert to Wideband Digital Audio
    DSP->>HFRCG: Packetize (RTP) with QoS markers
    HFRCG->>CustomModem: Prioritize & Transmit (Custom Protocol over POTS)
    CustomModem->>SPNet: High-Speed Packet Stream
    SPNet->>FarEnd: Route to Far-End Recipient

    Note over HFRCG,SPNet: Concurrent Multi-Channel Audio
    Note over HFRCG: Low Latency 60GHz Wireless for Local Streaming

3. Cross-Domain Application

Derivative 1.5: AgriTech RCG for Remote Sensor Networks and Voice Alerts

  • Enabling Description: An RCG adapted for agricultural use, connecting to remote farm locations via existing POTS lines. It aggregates data from various IoT sensors (soil moisture, temperature, pH, livestock trackers via LoRaWAN or Zigbee gateways) connected to its wireless interface. The continuous POTS internet connection provides a low-cost data backhaul for telemetry. The VoIP capability is used for automated voice alerts to farmers (e.g., "Field 7 moisture critical") and for direct voice communication with on-site staff using ruggedized telephones. The prioritization ensures urgent alerts and voice calls are delivered even during periods of heavy sensor data transmission.
  • Mermaid Diagram:
    graph LR
    A[Soil Sensors] -- LoRaWAN/Zigbee --> B(AgriTech RCG)
    C[Livestock Trackers] -- LoRaWAN/Zigbee --> B
    D[Weather Station] -- LoRaWAN/Zigbee --> B
    B -- POTS Modem (Always-On) --> E(LEC PSTN)
    E --> F(Service Provider Network)
    F -- VoIP Call --> G[Farmer's Phone (Voice Alerts)]
    B -- Data Backhaul (Prioritized) --> F
    F --> H[Cloud Analytics Platform]
    subgraph AgriTech RCG
        B_CPU[Processor]
        B_MODEM[POTS Modem]
        B_WIRELESS[LoRaWAN/Zigbee/802.11]
        B_VOIP[VoIP Module]
        B_TELEPHONES[Ruggedized Tel Ports]
        B_SENSORS[Sensor Data Aggregation]
        B_ALERTS[Automated Alert Engine]
        B_CPU -- Manages --> B_MODEM
        B_CPU -- Manages --> B_WIRELESS
        B_CPU -- Manages --> B_VOIP
        B_CPU -- Manages --> B_TELEPHONES
        B_CPU -- Processes --> B_SENSORS
        B_CPU -- Triggers --> B_ALERTS
    end

Derivative 1.6: Maritime RCG for Ship-to-Shore Communication

  • Enabling Description: A ruggedized RCG designed for small vessels, leveraging existing maritime satellite phone (e.g., Inmarsat FleetBroadband) or HF/VHF radio connections as its "POTS-like" always-on data link. The device integrates specialized radio modems (e.g., PACTOR for HF, custom data link for VHF) that provide a continuous, though often intermittent, internet connection. Multiple internal telephone ports allow crew members to make VoIP calls to shore, with critical communications (e.g., distress calls) prioritized over general internet traffic (weather updates, email). The wireless interface supports internal ship Wi-Fi for crew devices. The "unique telephone numbers" correspond to internal extensions on the vessel.
  • Mermaid Diagram:
    stateDiagram-v2
    state "RCG_Maritime_Offline" as Offline
    state "RCG_Maritime_Connecting" as Connecting
    state "RCG_Maritime_Online_Limited" as OnlineLimited
    state "RCG_Maritime_Online_Full" as OnlineFull

    [*] --> Offline
    Offline --> Connecting: User Init / Auto Retry
    Connecting --> Offline: Connection_Failed
    Connecting --> OnlineLimited: Low_Bandwidth_Link_Est
    OnlineLimited --> OnlineFull: High_Bandwidth_Link_Est
    OnlineFull --> OnlineLimited: Bandwidth_Degrades
    OnlineLimited --> Offline: Link_Lost
    OnlineLimited --> OnlineLimited: Prioritized_VoIP_Active
    OnlineFull --> OnlineFull: Prioritized_VoIP_Active
    OnlineLimited --> OnlineLimited: Data_Tx_Limited
    OnlineFull --> OnlineFull: Data_Tx_Full

    state "Internal_VoIP_Service" as VoIPService {
        state "Internal_Call" as InternalCall
        state "Shore_Call_Prioritized" as ShoreCallPrioritized
    }
    OnlineLimited --> VoIPService
    OnlineFull --> VoIPService
    VoIPService --> ShoreCallPrioritized: Critical_Comm_Detected
    ShoreCallPrioritized --> InternalCall: Critical_Comm_Ended
    InternalCall --> VoIPService: Call_Ended

4. Integration with Emerging Tech

Derivative 1.7: AI-Optimized Adaptive Bandwidth RCG with Real-Time Performance Monitoring

  • Enabling Description: This RCG integrates an embedded AI/ML inference engine that continuously monitors network conditions (latency, jitter, packet loss) on the POTS-based internet connection and local wireless network. The AI dynamically adjusts voice codec selection, VoIP packetization, and data traffic shaping policies in real-time to maintain optimal QoS for voice while maximizing data throughput. IoT sensors within the RCG chassis monitor internal temperature, power consumption, and component health. This real-time data feeds the AI model, which can predict potential hardware failures or network degradation and proactively adjust operational parameters or trigger alerts.
  • Mermaid Diagram:
    flowchart TD
    A[POTS Line] --> B(Modem/DAA)
    B --> C{Packet Data Flow}
    C --> D[Main CPU w/AI Inference Engine]
    D --> E[VoIP Module (Adaptive Codec/Pkt)]
    D --> F[Traffic Shaper/Prioritization Unit]
    D --> G[802.11 Wireless Interface]
    H[IoT Sensors (Temp, Power, Health)] --> D
    D -- Real-time Feedback Loop --> D
    D --> I[External Network]
    E --> I
    F --> I
    G --> J[Local Wireless Devices]
    J --> D

    subgraph AI Optimization Process
        D_MONITOR[Monitor Network & Device Metrics]
        D_ANALYZE[Analyze Performance & Predict Issues (AI)]
        D_ADJUST[Adjust Codec, Packetization, QoS Policies]
        D_LEARN[Update AI Model from Outcomes]
        D_MONITOR --> D_ANALYZE
        D_ANALYZE --> D_ADJUST
        D_ADJUST --> D_LEARN
    end

Derivative 1.8: Blockchain-Secured Decentralized RCG Network with Smart Contract-Based Bandwidth Allocation

  • Enabling Description: RCGs within a community form a peer-to-peer mesh network via their wireless interfaces, where bandwidth sharing (as described in Claim 15's multilink PPP bundle concept) is governed by blockchain-based smart contracts. Each RCG has a unique cryptographic identity on a permissioned blockchain. When an RCG requests additional bandwidth from neighboring RCGs for a large data transfer, a smart contract mediates the request, verifying availability and recording usage. Payment for shared bandwidth (e.g., in utility tokens) is automatically processed via the blockchain. VoIP calls are routed and prioritized, with call metadata (not content) cryptographically signed and hashed onto the blockchain for auditable QoS enforcement and dispute resolution.
  • Mermaid Diagram:
    sequenceDiagram
    participant RCG_A as Initiating RCG (Node A)
    participant RCG_B as Remote RCG (Node B)
    participant RCG_C as Remote RCG (Node C)
    participant Blockchain as Blockchain Network
    participant ServiceProvider as Service Provider Network

    RCG_A->>RCG_B: Request Bandwidth Share (Wireless)
    RCG_A->>RCG_C: Request Bandwidth Share (Wireless)
    RCG_B->>Blockchain: Propose Bandwidth Lease (Smart Contract)
    RCG_C->>Blockchain: Propose Bandwidth Lease (Smart Contract)
    Blockchain-->>RCG_A: Confirmation (if conditions met)
    RCG_A->>ServiceProvider: Initiate Multilink PPP Session (via A, B, C POTS)
    ServiceProvider-->>RCG_A: Data Stream via Multilink PPP
    Note over RCG_A,RCG_B: RCG_B relays data to RCG_A (Wireless)
    Note over RCG_A,RCG_C: RCG_C relays data to RCG_A (Wireless)
    RCG_A->>Blockchain: Record Bandwidth Usage & Payment (Smart Contract Event)
    RCG_A->>ServiceProvider: VoIP Call (Prioritized over POTS)
    ServiceProvider-->>Blockchain: Log QoS Metrics for Call (Hashed Metadata)

5. The "Inverse" or Failure Mode

Derivative 1.9: Low-Power Sentinel Mode RCG with Emergency Satellite Beacon

  • Enabling Description: In the event of a total power outage or primary POTS line failure, the RCG transitions into a "Sentinel Mode," operating on a minimal internal battery or supercapacitor for an extended duration (e.g., weeks). In this mode, the primary modem and wireless interface are shut down. The device periodically attempts to establish a very low-bandwidth, non-IP emergency connection over the POTS line (if partially restored, e.g., for analog voice calls) or via an integrated satellite emergency beacon (e.g., using a COSPAS-SARSAT compatible module). The single telephone output port (POTS 1) provides basic analog lifeline service directly to the incoming POTS line, overriding any VoIP functionality. The processor only monitors for incoming analog calls on POTS 1 and transmits pre-configured emergency messages or GPS coordinates (if available) via the beacon or low-speed modem.
  • Mermaid Diagram:
    stateDiagram-v2
    state "Operational" as Operational
    state "Failsafe_Lifeline" as FailsafeLifeline
    state "Sentinel_Mode" as SentinelMode

    Operational --> FailsafeLifeline: Power_Loss_RCG / POTS_Failure_Modem
    FailsafeLifeline --> Operational: Power_Restored / POTS_Restored
    FailsafeLifeline --> SentinelMode: Battery_Low / Extended_Outage
    SentinelMode --> Operational: Power_Restored_Full
    SentinelMode --> SentinelMode: Low_Power_Beacon_Active

    state Operational {
        RCG_CPU_Full --> Modem_AlwaysOn
        RCG_CPU_Full --> VoIP_Active
        RCG_CPU_Full --> Wireless_Active
        POTS1_Port --> VoIP_Path
    }

    state FailsafeLifeline {
        POTS1_Port --> Direct_POTS_Line
        RCG_CPU_Minimal --> Monitor_POTS_Line
        Modem_Inactive
        VoIP_Inactive
        Wireless_Inactive
    }

    state SentinelMode {
        RCG_CPU_UltraLow --> Emergency_Beacon_Module
        RCG_CPU_UltraLow --> Monitor_POTS_Line_Low_Power
        Emergency_Beacon_Module --> Transmit_GPS_Alert
        POTS1_Port --> Direct_POTS_Line
        Battery_Monitor
    }

Derivative 1.10: Limited-Functionality "Guest Mode" RCG for Secure, Metered Access

  • Enabling Description: The RCG incorporates a "Guest Mode" where the wireless interface provides limited, isolated network access for visitors, completely segregated from the main home network and critical voice services. This mode could enforce bandwidth caps, time limits, or content filtering. The VoIP service is restricted to a single, temporary guest line, or disabled entirely. The "always-on" POTS internet connection intelligently meters data usage from guest devices, and if a pre-defined threshold is met, it can dynamically reduce guest bandwidth, or prompt for authentication for continued use. This ensures the primary user's voice QoS and data allocation are not impacted by guest usage. Authentication could be handled by a captive portal.
  • Mermaid Diagram:
    graph TD
    A[POTS Line] --> B(Modem/DAA)
    B --> C{Internet Connection}
    C --> D[Main CPU/Router]
    D --> E[VoIP Engine (Primary)]
    D --> F[POTS Output Ports (Primary Users)]
    D --> G[802.11 Wireless Module]
    G --> H[Primary Home Network (WPA3)]
    G --> I[Guest Network (Captive Portal)]
    I --> J[Guest Devices]

    subgraph Main CPU Logic
        D_PRIO[Voice/Primary Data Prioritization]
        D_QOS[QoS Enforcement]
        D_GUEST_ISOL[Guest Network Isolation]
        D_GUEST_METER[Guest Data Metering/Throttling]
        D_CPU[Processor]
        D_CPU -- Manages --> D_PRIO
        D_CPU -- Manages --> D_QOS
        D_CPU -- Enforces --> D_GUEST_ISOL
        D_CPU -- Controls --> D_GUEST_METER
        D_CPU -- Routes --> E
        D_CPU -- Routes --> F
        D_CPU -- Controls --> G
    end

Core Claim 8: Method for Providing Multipath Communication Services

Claim 8 Recap: A method for providing multipath communication services using an RCG device, comprising establishing a continuous, always-on internet connection through a POTS line; offering multiple telephone output ports (at least one with a unique telephone number); providing VoIP services for connected telephones over the continuous internet connection; and prioritizing voice packets over other data packets for transmission over the continuous internet connection.

1. Material & Component Substitution

Derivative 8.1: Method using Software-Defined Radio (SDR) for POTS Modem and Virtualized SLIC

  • Enabling Description: The method involves replacing discrete modem and SLIC/CODEC hardware with a software-defined radio (SDR) module and a powerful general-purpose processor (GPP) running a real-time operating system. This method dynamically configures the SDR to emulate various POTS modem standards (e.g., V.92, V.34, or proprietary higher-speed modulation schemes) over the physical POTS line. The "POTS output ports" are virtualized SLIC instances managed by the GPP, interacting with analog telephone devices via a simple Digital-to-Analog Converter (DAC) and amplifier array. Voice packet prioritization is implemented as a kernel-level queueing discipline within the GPP's network stack.
  • Mermaid Diagram:
    flowchart LR
    A[Physical POTS Line] --> B(Software-Defined Radio Module)
    B --> C(General-Purpose Processor w/RTOS)
    C -- Emulates V.92 --> C_MODEM[Software Modem Stack]
    C -- Emulates SLIC --> C_SLIC[Virtualized SLIC Instances]
    C_MODEM -- Establishes --> D[Always-On IP Connection]
    C_SLIC -- Connects --> E[DAC/Amp Array]
    E --> F[Analog Telephone Handsets]
    C -- Provides --> G[VoIP Service (Software)]
    G -- Prioritizes --> D
    D --> H[Internet/Service Provider]
    subgraph GPP Processes
        C_MODEM
        C_SLIC
        G
        I[Kernel-level QoS/Prioritization]
        J[Network Stack]
    end
    C --> I
    I --> J
    J --> D

2. Operational Parameter Expansion

Derivative 8.2: Method for Ultra-Low Latency Telepresence over Short-Haul POTS Links

  • Enabling Description: This method optimizes the RCG operation for ultra-low latency, full-duplex voice and low-resolution video telepresence over short-haul (e.g., intra-building, campus-level) copper POTS wiring. The "always-on" connection employs a custom symmetrical data-over-POTS modulation achieving 2-4 Mbps over short distances, with highly aggressive packetization (e.g., 5ms VoIP packets) and forward error correction (FEC) to minimize perceived latency below 50ms. Voice packets are given absolute priority, with video packets dynamically adjusted in resolution and frame rate to fill remaining bandwidth. The multiple telephone ports are used for dedicated telepresence stations with integrated screens and cameras, each assigned a unique internal extension number.
  • Mermaid Diagram:
    graph TD
    A[Short-Haul Copper POTS] --> B(Custom High-Speed POTS Modem)
    B --> C{RCG Device}
    C --> D[Processor (Low Latency RTOS)]
    D --> E[VoIP/Video Engine (5ms Pkts, FEC)]
    D --> F[Traffic Prioritization (Absolute Voice Priority)]
    D --> G[Multiple Telepresence Ports]
    G --> H[Integrated Telepresence Stations]
    E -- Ultra-Low Latency Stream --> I[Remote Telepresence Endpoint]
    F -- Prioritized Data --> I
    subgraph RCG Device
        C
        D
        E
        F
        G
    end

3. Cross-Domain Application

Derivative 8.3: Method for Remote Healthcare Monitoring and Teleconsultation via Legacy Home POTS

  • Enabling Description: A method applied in elderly care or remote patient monitoring. The RCG, connected to a legacy POTS line, establishes an always-on data link for transmitting vital signs data from wearable sensors (via Bluetooth LE to the RCG's wireless interface) to a central healthcare platform. The method allocates a dedicated "teleconsultation" VoIP channel on one of the unique telephone ports. This channel has stringent QoS guarantees, prioritizing live voice and low-bandwidth video for doctor-patient consultations over routine vital sign uploads. In an emergency, an automated voice call can be placed, and the system can override all other traffic to ensure the emergency call's completion.
  • Mermaid Diagram:
    sequenceDiagram
    participant Patient as Patient Residence
    participant RCG as RCG Device
    participant POTS as POTS Line
    participant SPNet as Service Provider Network
    participant Healthcare as Healthcare Platform
    participant Doctor as Doctor's Terminal

    Patient->>RCG: Wearable Sensor Data (BTLE)
    RCG->>POTS: Establish Always-On IP Link
    POTS->>SPNet: Continuous Data Stream
    SPNet->>Healthcare: Transmit Vital Signs (Lower Priority)

    Doctor->>SPNet: Initiate Teleconsultation Call (VoIP)
    SPNet->>POTS: Route Call to RCG
    POTS->>RCG: Incoming Call
    RCG->>RCG: Prioritize Voice/Video over Vital Signs
    RCG->>Patient: Ring Teleconsultation Phone Port
    Patient->>Doctor: Live Teleconsultation (High QoS VoIP/Video)

    Note over Patient,Doctor: Emergency Voice Call (Highest Priority)
    RCG->>SPNet: Place Emergency Call
    SPNet->>Doctor: Emergency Alert/Call

4. Integration with Emerging Tech

Derivative 8.4: Method for Adaptive Edge Computing with Federated Learning for Network Load Prediction

  • Enabling Description: The RCG method integrates federated learning at the network edge. Each RCG continuously monitors its local network traffic patterns, including VoIP call duration, data transfer volumes, and wireless client activity. This local data is used to train a local AI model for predicting future bandwidth demands and potential network congestion. Instead of sending raw data, only the model updates are shared (federated learning) with a central server, ensuring privacy. The RCG's processor then uses these local predictions, combined with aggregated global model insights, to proactively adjust bandwidth allocation, pre-buffer streaming data, and dynamically prioritize VoIP packets based on predicted real-time load, minimizing latency and improving QoS for voice.
  • Mermaid Diagram:
    graph LR
    subgraph RCG_A
        A1[Local Traffic Monitor] --> A2[Local AI Model Training]
        A2 --> A3[Bandwidth Predictor]
        A3 --> A4[Dynamic QoS Adjuster]
        A4 --> A5[POTS Modem]
        A5 --> A6(Internet)
    end

    subgraph RCG_B
        B1[Local Traffic Monitor] --> B2[Local AI Model Training]
        B2 --> B3[Bandwidth Predictor]
        B3 --> B4[Dynamic QoS Adjuster]
        B4 --> B5[POTS Modem]
        B5 --> B6(Internet)
    end

    A2 -- Model Updates --> C[Central Federated Learning Server]
    B2 -- Model Updates --> C
    C -- Global Model Insights --> A3
    C -- Global Model Insights --> B3

    A5 -- Prioritized VoIP/Data --> A6
    B5 -- Prioritized VoIP/Data --> B6

5. The "Inverse" or Failure Mode

Derivative 8.5: Method for Prioritized Data Evacuation During Impending Network Failure

  • Enabling Description: This method anticipates an impending network outage (e.g., detected instability on the POTS line, upstream carrier alerts). The RCG's processor, upon receiving or detecting such signals, initiates a "data evacuation" procedure. It temporarily suspends all non-critical data transfers and reserves maximum available bandwidth on the POTS connection (prioritizing it even over active voice calls, with user warning/override) to quickly transmit critical, pre-identified data files (e.g., local backups, security logs) to a designated offsite storage before total connectivity loss. Voice services are either temporarily degraded, rerouted to a cellular backup (if available), or provided with a minimal guaranteed bandwidth. Once critical data is evacuated or the connection fails completely, the RCG enters a low-power monitoring state.
  • Mermaid Diagram:
    stateDiagram-v2
    state "Normal_Operation" as Normal
    state "Imminent_Failure_Detection" as ImminentFailure
    state "Data_Evacuation_Phase" as DataEvacuation
    state "Low_Power_Monitoring" as LowPower

    [*] --> Normal
    Normal --> ImminentFailure: Detect_POTS_Instability / Receive_Outage_Alert
    ImminentFailure --> DataEvacuation: Initiate_Data_Evacuation
    DataEvacuation --> LowPower: Critical_Data_Transferred / Connection_Lost
    LowPower --> Normal: Network_Restored / User_Intervention

    state Normal {
        VoIP_High_Priority
        Data_Normal_Priority
    }

    state DataEvacuation {
        Data_Evacuation_Highest_Priority
        VoIP_Degraded_or_Suspended
        Warning_Issued_to_Users
        Critical_Files_Identified
    }

Core Claim 15: RCG Device with Multilink PPP Bundle for Combined Bandwidth

Claim 15 Recap: A Residential Communications Gateway (RCG) device comprising a POTS connection from a LEC, a modem for a continuous internet connection over the POTS line, a processor, at least two telephone output ports (at least one with an additional unique telephone number), and a wireless interface associated with the processor, configured to communicate with other RCG devices, the RCGs being configured to form a multilink PPP bundle to combine the internet bandwidth from the POTS lines connected to the RCG devices.

1. Material & Component Substitution

Derivative 15.1: Software-Defined Networking (SDN) Managed RCG Cluster with Li-Fi Backhaul

  • Enabling Description: The multilink PPP bundle functionality is replaced by a Software-Defined Networking (SDN) controller residing on one RCG (or a dedicated cluster manager), managing a group of RCGs as an SDN-enabled cluster. The "wireless interface" for inter-RCG communication is augmented or replaced with a Li-Fi (Light Fidelity) module, providing secure, high-bandwidth optical wireless communication within a localized physical area (e.g., adjacent apartments, office spaces). The SDN controller dynamically provisions virtual links over both the Li-Fi and individual POTS connections, creating a flexible multipath TCP (MPTCP) or similar aggregate data path, rather than PPP. The modems themselves are programmable DSP-based units capable of adapting modulation schemes for optimal throughput on each POTS line.
  • Mermaid Diagram:
    graph TD
    A[POTS Line 1] --> RCG1(RCG Node 1)
    B[POTS Line 2] --> RCG2(RCG Node 2)
    C[POTS Line N] --> RCGn(RCG Node N)

    RCG1 -- Li-Fi Backhaul --> RCG_SDN_Ctrl(SDN Controller RCG)
    RCG2 -- Li-Fi Backhaul --> RCG_SDN_Ctrl
    RCGn -- Li-Fi Backhaul --> RCG_SDN_Ctrl

    RCG1 -- MPTCP/Aggregated Path --> Internet
    RCG2 -- MPTCP/Aggregated Path --> Internet
    RCGn -- MPTCP/Aggregated Path --> Internet

    subgraph SDN Controller RCG
        RCG_SDN_Ctrl_Proc[Processor]
        RCG_SDN_Ctrl_Software[SDN Controller Software]
        RCG_SDN_Ctrl_Topology[Network Topology Manager]
        RCG_SDN_Ctrl_Flow[Flow Rule Engine]
        RCG_SDN_Ctrl_Proc -- Runs --> RCG_SDN_Ctrl_Software
        RCG_SDN_Ctrl_Software -- Manages --> RCG_SDN_Ctrl_Topology
        RCG_SDN_Ctrl_Software -- Configures --> RCG_SDN_Ctrl_Flow
        RCG_SDN_Ctrl_Software -- Monitors --> RCG1
        RCG_SDN_Ctrl_Software -- Monitors --> RCG2
        RCG_SDN_Ctrl_Software -- Monitors --> RCGn
    end

2. Operational Parameter Expansion

Derivative 15.2: Geo-Distributed RCG Cluster for High-Throughput Data Ingestion

  • Enabling Description: A cluster of RCG devices is deployed across a wide geographic area (e.g., a city block, multiple rural homes), each connected to its local POTS line. The "multilink PPP bundle" is extended to operate as a geo-distributed data ingestion pipeline, where the RCGs collaboratively aggregate data from distributed sensors or edge devices. The wireless communication between RCGs is long-range Wi-Fi (e.g., 802.11ah HaLow) or even directional millimeter-wave links, enabling communication over kilometers. The system dynamically forms and dissolves PPP bundles based on real-time data ingestion requirements, optimizing for throughput for large file transfers (e.g., drone footage, scientific data) while maintaining lifeline VoIP services.
  • Mermaid Diagram:
    erDiagram
    RCG_Node ||--o{ POTS_Line : "connects to"
    RCG_Node {
        NodeID
        GeoLocation
        POTS_Bandwidth_Available
        Long_Range_Wireless_Status
        Current_Data_Ingestion_Rate
    }
    POTS_Line {
        LineID
        Max_Bandwidth
        Current_Utilization
    }
    RCG_Cluster {
        ClusterID
        Leader_RCG_NodeID
        Aggregate_Bandwidth
        Active_PPP_Bundles
    }
    Data_Source {
        SourceID
        Data_Type
        Volume
    }

    RCG_Node ||--|{ RCG_Cluster : "belongs to"
    RCG_Cluster ||--o{ PPP_Bundle : "manages"
    PPP_Bundle {
        BundleID
        Member_RCG_Nodes
        Destination_URL
        Total_Bandwidth
    }
    Data_Source ||--o{ RCG_Node : "feeds data to"

3. Cross-Domain Application

Derivative 15.3: Autonomous Vehicle Network (AVN) RCG for Redundant Telemetry Backhaul

  • Enabling Description: RCGs are integrated into autonomous vehicles (AVs) or roadside units (RSUs). The "POTS line" is reinterpreted as a legacy wired communication port on the AV/RSU, capable of establishing a dial-up connection to an emergency or fallback network over a standard copper pair when wireless broadband (5G/V2X) is unavailable or compromised. Multiple AV-RCGs (in different vehicles or RSUs) form a "multilink PPP bundle" using short-range, high-reliability wireless vehicle-to-vehicle (V2V) or vehicle-to-infrastructure (V2I) communication (e.g., IEEE 802.11p/bd). This bundle aggregates available wired "POTS" bandwidth from several nodes to create a robust, redundant backhaul for critical telemetry data, system diagnostics, or even low-latency teleoperation commands in situations where primary wireless links fail.
  • Mermaid Diagram:
    graph LR
    AV1[Autonomous Vehicle 1 (AV-RCG 1)] -- Wired Backup Link --> RSU1(Roadside Unit 1)
    AV2[Autonomous Vehicle 2 (AV-RCG 2)] -- Wired Backup Link --> RSU2(Roadside Unit 2)
    AV3[Autonomous Vehicle 3 (AV-RCG 3)] -- Wired Backup Link --> RSU3(Roadside Unit 3)

    AV1 -- V2V/V2I (802.11p/bd) --> AV2
    AV2 -- V2V/V2I (802.11p/bd) --> AV3
    RSU1 -- High-Speed Network --> ControlCenter(AV Control Center)
    RSU2 -- High-Speed Network --> ControlCenter
    RSU3 -- High-Speed Network --> ControlCenter

    subgraph Multilink PPP Bundle (Wireless & Wired Aggregation)
        AV_PPP[AV-RCG PPP Aggregation]
        AV_PPP --> ControlCenter
    end
    
    AV1 -- Forms Link --> AV_PPP
    AV2 -- Forms Link --> AV_PPP
    AV3 -- Forms Link --> AV_PPP

    Note over AV_PPP: Aggregates Wired Backup Links from AV-RCGs via V2V/V2I

4. Integration with Emerging Tech

Derivative 15.4: Quantum-Secured Multilink RCG with Distributed Ledger for Resource Allocation

  • Enabling Description: The multilink PPP bundle establishment and resource allocation (bandwidth requests/grants) among RCGs are secured using quantum-resistant cryptography. Each RCG integrates a quantum key distribution (QKD) module for establishing highly secure, unbreakable communication channels for signaling. The distributed ledger technology (DLT) from Derivative 1.8 is extended for managing available POTS bandwidth from each RCG as a tradable resource, validated and recorded on the ledger. Smart contracts automatically execute resource leases and adjust the composition of the multilink PPP bundle based on availability, QoS requirements, and dynamic pricing models derived from the DLT. The processor orchestrates these QKD and DLT interactions, ensuring that sensitive negotiation data (e.g., link performance, RCG identities) is protected.
  • Mermaid Diagram:
    sequenceDiagram
    participant RCG_X as RCG X
    participant RCG_Y as RCG Y
    participant DLT as Distributed Ledger (Blockchain)
    participant QKD_Network as QKD Network

    RCG_X->>RCG_Y: Request Bandwidth (Encrypted via QKD)
    RCG_X->>QKD_Network: Establish Secure QKD Link
    RCG_Y->>QKD_Network: Establish Secure QKD Link
    QKD_Network-->>RCG_X: Quantum Keys
    QKD_Network-->>RCG_Y: Quantum Keys

    RCG_X->>DLT: Propose Bandwidth Requirement (Signed w/Q-Resistant Sig)
    RCG_Y->>DLT: Offer Available Bandwidth (Signed w/Q-Resistant Sig)
    DLT->>DLT: Execute Smart Contract (Match/Allocate)
    DLT-->>RCG_X: Contract Confirmation
    DLT-->>RCG_Y: Contract Confirmation

    RCG_X->>RCG_Y: Multilink PPP Session Setup (Encrypted w/Q-Resistant Keys)
    RCG_X->>DLT: Log Bandwidth Utilization (for Auditing/Billing)

5. The "Inverse" or Failure Mode

Derivative 15.5: Decentralized Emergency Multilink Mesh Network (DEMMN) from Failing RCGs

  • Enabling Description: In a widespread disaster (e.g., regional power outage, internet backbone failure), individual RCGs detect catastrophic loss of external connectivity. Instead of relying on a central authority, they spontaneously form a Decentralized Emergency Multilink Mesh Network (DEMMN) using their wireless interfaces (e.g., 802.11s mesh networking protocol). If any RCG within the mesh still has a functional POTS line (even if degraded or intermittent), this line is automatically designated as an "emergency egress point." The remaining RCGs in the mesh dynamically form a "multilink PPP bundle" over the combined available POTS bandwidth of all such egress points, prioritizing emergency voice calls and short, critical text messages (e.g., via a lightweight messaging protocol like MQTT-SN over the mesh) to external services. Non-essential data is dropped, and power consumption is minimized across the mesh.
  • Mermaid Diagram:
    graph TD
    RCG1[RCG 1 (Failing)] -- Mesh Link --> RCG2[RCG 2 (Degraded POTS)]
    RCG1 -- Mesh Link --> RCG3[RCG 3 (Failing)]
    RCG2 -- Mesh Link --> RCG4[RCG 4 (Operational POTS)]
    RCG3 -- Mesh Link --> RCG4
    RCG5[RCG 5 (Failing)] -- Mesh Link --> RCG4

    RCG2 -- Egress Point (Degraded) --> POTS_B(POTS Line B)
    RCG4 -- Egress Point (Operational) --> POTS_D(POTS Line D)

    POTS_B -- Aggregated --> Emergency_Network(Emergency Services Network)
    POTS_D -- Aggregated --> Emergency_Network

    subgraph DEMMN Functionality
        RCG_Mesh[RCG Mesh (802.11s)]
        RCG_Mesh -- Aggregates --> Multilink_Bundle(Emergency Multilink PPP Bundle)
        Multilink_Bundle --> Emergency_Network
        Multilink_Bundle -- Prioritizes --> Voice_Calls[Emergency Voice Calls]
        Multilink_Bundle -- Prioritizes --> Text_Msgs[Critical Text Messages]
    end

    RCG1 -- Member --> RCG_Mesh
    RCG2 -- Member --> RCG_Mesh
    RCG3 -- Member --> RCG_Mesh
    RCG4 -- Member --> RCG_Mesh
    RCG5 -- Member --> RCG_Mesh

Combination Prior Art Scenarios

Here are three scenarios combining aspects of US9350649 with existing open-source standards, demonstrating how the patent's teachings could be rendered obvious or non-novel in combination:

  1. US9350649 + OpenWrt/LEDE for Router Management and VoIP Provisioning:

    • Description: A person skilled in the art, seeking to implement a Residential Communications Gateway (RCG) as described in US9350649 (Claim 1), would find it obvious to use the open-source router operating system OpenWrt/LEDE. OpenWrt provides a complete Linux-based firmware for embedded devices, already supporting modem drivers (for POTS modems if available), network stack management, Wi-Fi drivers (802.11b/g/n/ac/ax), and QoS/traffic shaping capabilities. The VoIP services could be easily provisioned using open-source SIP server software like Asterisk (which can be compiled and run on OpenWrt) or a lightweight SIP client/proxy. The prioritization of voice packets (as per Claim 1 and 8) is a standard feature of Linux QoS frameworks (e.g., tc with HTB queuing disciplines) that are readily available and configurable in OpenWrt. Furthermore, the handling of multiple virtual telephone lines can be managed via chan_dongle or similar modules for Asterisk integrated with hardware SLICs, making the concept of multiple unique telephone numbers over a single gateway obvious.
    • Standard: OpenWrt/LEDE (Router OS), Asterisk (VoIP PBX).

  2. US9350649 + Linux Kernel MultiPath TCP (MPTCP) for Bandwidth Aggregation:

    • Description: Given the RCG's concept of aggregating bandwidth (Claim 15) using a multilink PPP bundle, a person skilled in the art would find it obvious to achieve a similar or superior result by replacing PPP with MultiPath TCP (MPTCP), which is integrated into the Linux kernel and available as an open-source standard. MPTCP allows a single TCP connection to use multiple network paths simultaneously, effectively combining bandwidth. An RCG (or a cluster of RCGs) running a Linux-based OS could use MPTCP to aggregate data traffic over its primary POTS modem connection (representing one path) and additional connections formed via other RCGs' POTS lines (via wireless relay and their respective modems, acting as additional paths). This setup leverages existing kernel functionality for robust, efficient, and transparent bandwidth aggregation, making the multilink PPP approach non-novel. The wireless interface would facilitate the establishment of IP connectivity between RCGs, over which MPTCP subflows would be established.
    • Standard: Linux Kernel MultiPath TCP (MPTCP).

  3. US9350649 + FreeRADIUS for Dynamic RCG-to-RCG Service Authorization:

    • Description: The process described in US9350649 (Claim 15) for RCGs to request and grant bandwidth services from other RCGs in a multilink PPP bundle could be implemented using the open-source FreeRADIUS server. A central or designated RCG (or a cloud-based service provider component) acting as a RADIUS server could authenticate and authorize bandwidth requests from initiating RCGs to remote RCGs. When an initiating RCG sends a multilink PPP service request to a remote RCG, the remote RCG could act as a RADIUS client, querying the central FreeRADIUS server to verify the initiating RCG's credentials and determine its authorization to use the remote RCG's bandwidth, based on predefined policies or even dynamic load balancing. This provides a robust, extensible, and standards-compliant framework for managing shared network resources among RCGs, making the ad-hoc authorization described in the patent obvious.
    • Standard: FreeRADIUS (Authentication, Authorization, and Accounting protocol implementation).

Generated 6/12/2026, 2:15:34 AM