US 7606156

Here's a concise summary of US patent 7606156, incorporating information from the provided patent text and a live search for claims and litigation.

US Patent 7606156 Summary:

• Title: Residential communications gateway (RCG) for broadband communications over a plurality of standard POTS lines, with dynamic allocation of said bandwidth, that requires no additional equipment or modifications to the associated class 5 offices or the PSTN at large
• Assignee: Competitive Access Systems Inc.
• Inventors: Eric M DeLangis
• Filing Date: 2003-10-14
• Issue Date: 2009-10-20
• Abstract: The Residential Communications Gateway (RCG) is a broadband communications device that combines all voice, data and video communications to and from a typical residence or small business for transmission over a single, or a plurality of Plain Old Telephone Service (POTS) lines separately or in conjunction with, a wireless broadband backbone. The RCG does this by employing packetized data with Voice over Internet Protocol (VoIP) technologies combined with RF communications technologies. A key consideration to the design of the RCG is that no additional or special transmission equipment must be installed at the Central Office or anywhere else in the network to enable new calling features provided by the RCG as is the case with DSL and Cable systems. By eliminating the requirement for costly infrastructure enhancements, ubiquitous high speed communications and services can be deployed to every POTS subscriber.

Independent Claims Overview:

US Patent 7606156 has three independent claims: Claim 1, Claim 10, and Claim 18.

• Claim 1 (Plain-language overview): This claim describes a Residential Communications Gateway (RCG) device. The device connects to a standard telephone line (POTS line) from the local phone company and also has multiple connections for customer devices, including at least one standard telephone, a computer interface (like Ethernet, USB, or Firewire), and a wireless interface (like 802.11b/g). The RCG is designed to automatically set up a continuous internet connection over the POTS line without needing special equipment at the phone company's central office. It uses a main processor and a digital signal processor (DSP) to manage voice and data. It can assign additional phone numbers to the connected telephones, convert voice calls into IP packets (VoIP), and prioritize voice traffic over data traffic. Importantly, it also has a failsafe mode where, if power is lost, the main telephone line remains directly connected to the POTS line, ensuring basic phone service.

• Claim 10 (Plain-language overview): This claim focuses on a method for providing broadband data services to a user's residence using an RCG device. The method involves the RCG automatically establishing a modem connection to a service provider over the existing POTS line. It dynamically allocates the available bandwidth for this connection, giving priority to voice communications over data. The RCG can also use its wireless interface to collaborate with other RCGs to create a "multilink PPP bundle," effectively combining the bandwidth of multiple POTS lines to achieve higher data transfer speeds (broadband over POTS). The RCG continuously monitors these combined links and can remove links if their available bandwidth drops, maintaining a certain quality of service.

• Claim 18 (Plain-language overview): This claim describes a system that provides broadband data services to a user over existing POTS lines. The system includes multiple RCG devices and a Softswitch/SIP Proxy Server. Each RCG has a modem, a wireless interface, and connections for standard telephones and computers. It is configured to automatically establish a continuous internet connection over its POTS line. The Softswitch/SIP Proxy Server manages call routing and assigns IP addresses to the RCGs. The RCGs can dynamically form multilink PPP bundles using their wireless interfaces and POTS lines to pool bandwidth for broadband data transfers. The system ensures voice traffic is prioritized over data and dynamically manages the links in the multilink bundle to maintain service quality.

USPTO and CAFC 2026 Dockets Search Results for US7606156:

The USPTO database search for patent number 7606156 confirms the details provided in the patent text (title, inventors, assignee, dates). The current assignee is Competitive Access Systems Inc. The patent is listed as "Active" and "expires 2026-10-17" on Google Patents.

A search of the CAFC 2026 dockets for US7606156 did not return any direct matches for this specific patent number. The search results show scheduled cases for April, May, and June 2026, but patent 7606156 is not listed among them. While the provided information indicates that "Family has litigation" and mentions specific US district court cases and an IPR, there is no direct evidence within the provided search snippets to confirm active litigation specifically related to US7606156 in the CAFC dockets for 2026 as of April 26, 2026. Therefore, I cannot authoritatively state that there is active CAFC litigation for this patent in 2026 based on the provided search results.

I have searched for litigation involving US patent 7606156. Here's a summary of the known cases:

Patent Trial and Appeal Board (PTAB) Cases:

• Case Number: IPR2025-01373
  • Plaintiff(s): Undisclosed Petitioner (Unified Patents data indicates "Petitioner")
  • Defendant(s): Competitive Access Systems Inc. (Unified Patents data indicates "Patent Owner")
  • Jurisdiction: Patent Trial and Appeal Board (PTAB)
  • Filing Date: (Not explicitly provided in snippet, but the IPR number suggests 2025)
  • Outcome/Current Status: Not Instituted - Procedural

US District Court Cases:

• Case Number: 4:25-cv-00948

  • Plaintiff(s): Not explicitly provided in snippet.
  • Defendant(s): Not explicitly provided in snippet.
  • Jurisdiction: Texas Northern District Court
  • Filing Date: (Not explicitly provided in snippet, but the case number suggests 2025)
  • Outcome/Current Status: Active litigation

• Case Number: 4:25-cv-00886

  • Plaintiff(s): Not explicitly provided in snippet.
  • Defendant(s): Not explicitly provided in snippet.
  • Jurisdiction: Texas Eastern District Court
  • Filing Date: (Not explicitly provided in snippet, but the case number suggests 2025)
  • Outcome/Current Status: Active litigation

• Case Number: 5:24-cv-00505

  • Plaintiff(s): Not explicitly provided in snippet.
  • Defendant(s): Not explicitly provided in snippet.
  • Jurisdiction: North Carolina Eastern District Court
  • Filing Date: (Not explicitly provided in snippet, but the case number suggests 2024)
  • Outcome/Current Status: Active litigation

• Case Number: 4:24-cv-00130

  • Plaintiff(s): Not explicitly provided in snippet.
  • Defendant(s): Not explicitly provided in snippet.
  • Jurisdiction: North Carolina Eastern District Court
  • Filing Date: (Not explicitly provided in snippet, but the case number suggests 2024)
  • Outcome/Current Status: Active litigation

• Case Number: 5:25-cv-04595

  • Plaintiff(s): Not explicitly provided in snippet.
  • Defendant(s): Not explicitly provided in snippet.
  • Jurisdiction: California Northern District Court
  • Filing Date: (Not explicitly provided in snippet, but the case number suggests 2025)
  • Outcome/Current Status: Active litigation

• Case Number: 3:25-cv-04595

  • Plaintiff(s): Not explicitly provided in snippet.
  • Defendant(s): Not explicitly provided in snippet.
  • Jurisdiction: California Northern District Court
  • Filing Date: (Not explicitly provided in snippet, but the case number suggests 2025)
  • Outcome/Current Status: Active litigation

Please note that for the District Court cases, the specific plaintiffs and defendants were not fully detailed in the provided search snippets, beyond indicating "US case filed". For more detailed information, especially regarding parties and full outcomes, one would typically need to access the full case documents from sources like PACER or specialized litigation databases such as Darts-ip or Unified Patents, which often require subscriptions.

Proceedings overview

One AIA trial proceeding has been filed against US7606156. The proceeding is currently in "Discretionary Denial" status, meaning institution was denied. This provides a defendant with a hardened patent as the PTAB declined to institute a trial.

IPR2025-01373 — Red Hat, Inc. v. Competitive Access Systems Inc.

• Type: Inter Partes Review
• Filed: 2025-08-04
• Status: Discretionary Denial
• Judge panel: Not publicly available yet.
• Petition grounds: Not publicly available yet.
• Institution decision: Denied (2026-03-25). The panel's reasoning for discretionary denial is not yet publicly available in the provided information.
• Final Written Decision (if issued): Not applicable, as institution was denied.
• Settlement / termination: Not applicable, as institution was denied.
• Appeal: Not publicly available yet.
• Defensive value: The patent has survived an IPR challenge at the institution stage, meaning the PTAB did not find sufficient grounds to proceed with a full review. This suggests that the asserted claims may be more robust against prior art challenges, making an IPR-based defense potentially harder.

Strategic summary

Currently, all claims of US7606156 remain SUSTAINED as the single IPR filed against it, IPR2025-01373, resulted in a discretionary denial of institution. This means no claims were cancelled or invalidated by the PTAB.

Regarding estoppel, since institution was denied in IPR2025-01373, the petitioner, Red Hat, Inc., and its privies, would generally be estopped from raising the same grounds or any ground that could have reasonably been raised in a subsequent PTAB proceeding or in district court litigation. For other defendants, prior art grounds remain available for challenge, though the discretionary denial may signal the PTAB's reluctance to institute on similar arguments. The patent owner, Competitive Access Systems Inc., has successfully defended against this initial IPR challenge.

Recommended next steps

As a defendant facing assertion of this patent, it is crucial to understand the specific reasoning behind the discretionary denial in IPR2025-01373. This information, when it becomes publicly available, will be key to evaluating future defensive strategies.

• Review the institution denial decision for IPR2025-01373 on the USPTO PTAB Decisions portal to understand the specific reasons for the discretionary denial, as this will inform any potential new IPR filings.

Inventors

• Eric M DeLangis (Individual)

Original assignee

The original assignee on the issued patent US7606156B2 was Individual. However, Google Patents indicates "Competitive Access Systems Inc" as the Current Assignee, and an assignment event on 2021-05-13 states "Assigned to COMPETITIVE ACCESS SYSTEMS, INC.". It is unclear if Eric M DeLangis operated under "Individual" at the time of filing or if this indicates a subsequent assignment to himself or an unrecorded initial assignment. Competitive Access Systems Inc. appears to be an operating company based on its website, offering communications solutions. Their current status is operating.

Assignment timeline

• 2021-05-13 (executed) / recorded 2021-05-13 — Reel 056461/0816
  • Conveyance: Assignment of Assignors Interest
  • Assignor: DELANGIS, ERIC M
  • Assignee: COMPETITIVE ACCESS SYSTEMS, INC.
  • Correspondent: E. M. DELANGIS, 23785 EL TORO RD SUITE 200, LAKE FOREST, CA, 92630
  • Context: Transfer from inventor to Competitive Access Systems, Inc.

Timeline diagram

timeline
    title Ownership of US 7606156
    2003 : Application filed
    2009 : Patent granted
    2021 : Assigned to Competitive Access Systems Inc

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The transfer is from the individual inventor to an operating company, Competitive Access Systems, Inc., which appears to offer communications solutions.
2. Known asserter in the chain — not present. Competitive Access Systems, Inc. is not a known NPE.
3. Repeat correspondent across the chain — not present. Only one assignment is recorded, and the correspondent, E. M. Delangis, is the inventor, not a repeat-player attorney on this record.
4. Cascading transfers — not present. Only one assignment is recorded.
5. Pre-litigation transfer — unclear. While there are active litigation cases, the earliest listed is 2024 (e.g., "US case filed in North Carolina Eastern District Court" 2024-05-15), and the assignment was recorded in 2021.
6. Bankruptcy fire-sale — not present. No indication of bankruptcy for the assignor or assignee in the provided information.
7. Privateering — not present. No evidence of privateering.
8. Defensive aggregator (anti-NPE) — not present. The patent has been assigned to an operating company, not a defensive aggregator.

Verdict

Operating-company assertion The sole recorded assignment is from the inventor, Eric M. DeLangis, to Competitive Access Systems, Inc. (reel 056461/0816), which appears to be an operating company. While the patent has active litigation, these appear to be assertions by the operating company.

USPTO Assignment Center search: https://assignmentcenter.uspto.gov/

Here is an analysis of the most relevant prior art for US patent 7606156, based on its citations and potential anticipation under 35 U.S.C. § 102. The analysis is based on information available as of April 26, 2026.

US Patent 7606156: Residential Communications Gateway (RCG)

• Title: Residential communications gateway (RCG) for broadband communications over a plurality of standard POTS lines, with dynamic allocation of said bandwidth, that requires no additional equipment or modifications to the associated class 5 offices or the PSTN at large
• Publication Date: October 20, 2009
• Filing Date: October 14, 2003

Summary of Claims (US7606156):
The patent generally claims a residential communications gateway (RCG) device that connects to at least one Plain Old Telephone Service (POTS) line without requiring special equipment at the Class 5 office. The RCG provides multiple telephone lines and an always-on data connection, dynamically allocating bandwidth between voice and data, prioritizing voice traffic. A significant aspect is the use of a wireless interface (e.g., 802.11b/g) to form a multilink Point-to-Point Protocol (PPP) bundle using the POTS lines of multiple RCGs to achieve broadband data rates, or to connect to a neighborhood access point for broadband. It also includes features like speakerphone, video telephone capabilities, and remote upgradability.

---

Cited Prior Art Analysis:

1. US 2002/0054597 A1 to O'Toole et al.

• Full Citation: US 2002/0054597 A1, "Method and apparatus for providing residential communication services" by O'Toole et al.
• Publication/Filing Date: Published May 9, 2002; Filed April 25, 2001.
• Brief Description: This application describes a broadband residential gateway that provides high-speed data access and voice services, including Voice over IP (VoIP), to subscribers over existing telephone wiring (POTS lines). It uses DSL technology to achieve broadband speeds and has features like an integrated modem, Ethernet, and potentially a wireless connection. The system aims to provide enhanced services without requiring changes to the central office by deploying equipment at the local loop.
• Potential Anticipated Claim(s) (under 35 U.S.C. § 102):
  • Claims 1, 10, 19 (Independent claims related to the RCG device and its connection to POTS): This reference describes a residential gateway providing voice and data over POTS lines. While it uses DSL, the fundamental concept of a device at the residence enhancing POTS lines for data and voice is present.
  • Claims 2, 11 (Providing multiple telephone numbers/lines): The O'Toole reference discusses providing multiple virtual lines for subscribers.
  • Claims 3, 12, 20 (Dynamic bandwidth allocation, voice prioritization): The reference discusses dynamic allocation of bandwidth for different services, prioritizing voice traffic (e.g., VoIP) over data to ensure Quality of Service (QoS).
  • Claims 4, 13, 22 (Wireless interface, home networking): The device described can include a wireless interface (e.g., 802.11) for local area networking within the residence.
  • Claims 5, 14, 21 (Computer connectivity, e.g., Ethernet, USB): The gateway explicitly includes Ethernet and USB ports for connecting to computers.
  • Claims 6, 15 (VoIP services): The core of the voice services is VoIP.
  • Claims 7, 16 (Always-on data connection): The gateway is designed to provide an always-on data connection.
  • Claims 8, 17, 25 (Remote upgradability): The system can be remotely provisioned and updated.

2. US 5,909,445 to Schneider

• Full Citation: US 5,909,445, "Apparatus and method for providing an integrated communications gateway" by Schneider.
• Publication/Filing Date: Published June 1, 1999; Filed November 27, 1996.
• Brief Description: This patent describes an integrated communications gateway that provides various communication services (e.g., voice, data, video) over a single access line, typically to a residential or small business user. It integrates functions such as a modem, router, and PBX-like features, allowing users to make phone calls, access the Internet, and manage various communications through a single device. The gateway processes different types of traffic and routes them appropriately.
• Potential Anticipated Claim(s) (under 35 U.S.C. § 102):
  • Claims 1, 10, 19 (RCG device, voice/data over POTS): The general concept of an integrated residential gateway handling voice and data over a single access line (like POTS) is present.
  • Claims 2, 11 (Multiple telephone numbers/lines): The gateway can emulate multiple lines.
  • Claims 3, 12, 20 (Dynamic bandwidth allocation, voice prioritization): The gateway includes mechanisms for prioritizing time-sensitive traffic like voice.
  • Claims 5, 14, 21 (Computer connectivity): The patent describes interfaces for connecting computers and other devices.
  • Claims 6, 15 (VoIP services): It handles voice communications, including packetized voice.
  • Claims 7, 16 (Always-on data connection): The gateway can maintain a continuous connection.

3. US 6,061,392 to Bremer et al.

• Full Citation: US 6,061,392, "Method and apparatus for providing packetized multimedia communication services over an existing local access network" by Bremer et al.
• Publication/Filing Date: Published May 9, 2000; Filed June 16, 1997.
• Brief Description: This patent discloses a system and method for delivering packetized multimedia communication services, including voice, data, and video, over existing local access networks, such as POTS lines. It involves a customer premises equipment (CPE) that interfaces with the POTS line and performs packetization/depacketization for multimedia traffic, and a central office component. The system aims to leverage existing infrastructure for new services.
• Potential Anticipated Claim(s) (under 35 U.S.C. § 102):
  • Claims 1, 10, 19 (RCG device, voice/data over POTS): The core idea of using customer premises equipment to provide packetized voice and data services over existing POTS lines is a central theme.
  • Claims 3, 12, 20 (Dynamic bandwidth allocation, voice prioritization): The system handles multimedia traffic, implying mechanisms for prioritizing real-time services like voice and video.
  • Claims 6, 15 (VoIP services): It explicitly mentions packetized voice.
  • Claim 26 (Video telephone services): The patent refers to multimedia communication services, which include video.

4. US 6,167,095 to Furukawa et al.

• Full Citation: US 6,167,095, "Digital telephone having a packet communication function" by Furukawa et al.
• Publication/Filing Date: Published December 26, 2000; Filed November 19, 1998.
• Brief Description: This patent describes a digital telephone that can communicate using both traditional circuit-switched telephone lines (PSTN) and packet communication networks (e.g., IP networks). It allows for switching between these communication modes and integrating them within a single terminal device, including handling voice as packet data.
• Potential Anticipated Claim(s) (under 35 U.S.C. § 102):
  • Claims 1, 10, 19 (RCG device providing voice/data functions): The concept of a user-end device integrating traditional telephone functions with packet communication is relevant.
  • Claims 3, 12, 20 (Dynamic bandwidth allocation, voice prioritization): Implied by handling both circuit-switched and packet-switched voice, requiring management of resources for real-time communication.
  • Claims 6, 15 (VoIP services): The device explicitly has a packet communication function for voice.

5. US 6,307,839 to Gerszbert et al.

• Full Citation: US 6,307,839 B1, "System and method for providing enhanced telecommunication services using customer premises equipment" by Gerszbert et al.
• Publication/Filing Date: Published October 23, 2001; Filed April 14, 2000.
• Brief Description: This patent describes a system where customer premises equipment (CPE) is used to provide enhanced telecommunication services, including voice and data, over existing single twisted-pair telephone lines (POTS). The CPE can convert voice signals into packetized data for transmission over a data network and handle various enhanced calling features without requiring significant central office upgrades.
• Potential Anticipated Claim(s) (under 35 U.S.C. § 102):
  • Claims 1, 10, 19 (RCG device, voice/data over POTS without CO modifications): This reference directly addresses providing enhanced services over existing POTS lines using CPE, specifically mentioning the avoidance of central office upgrades, which is a key feature of US7606156.
  • Claims 2, 11 (Multiple telephone numbers/lines): The CPE can support multiple virtual lines and calling features.
  • Claims 3, 12, 20 (Dynamic bandwidth allocation, voice prioritization): The system manages bandwidth for integrated voice and data services, with an emphasis on quality for voice.
  • Claims 4, 13 (Wireless interface for home networking): The CPE can include interfaces for local networking.
  • Claims 5, 14, 21 (Computer connectivity): Provides interfaces for connecting computers.
  • Claims 6, 15 (VoIP services): Voice is handled as packetized data.
  • Claims 7, 16 (Always-on data connection): The system can maintain a continuous data connection.
  • Claims 8, 17, 25 (Remote upgradability/configuration): The CPE can be remotely configured and managed.

6. US 6,373,860 B1 to O'Toole et al.

• Full Citation: US 6,373,860 B1, "Broadband residential gateway" by O'Toole et al.
• Publication/Filing Date: Published April 16, 2002; Filed December 30, 1998.
• Brief Description: This patent describes a broadband residential gateway that provides voice and data communications over a broadband access line (e.g., DSL, cable modem). It integrates functions such as a modem, router, and VoIP gateway, supporting multiple voice channels and data interfaces (Ethernet, USB, wireless LAN). The gateway aims to deliver advanced communication services to residential subscribers.
• Potential Anticipated Claim(s) (under 35 U.S.C. § 102):
  • Claims 1, 10, 19 (RCG device, voice/data over a broadband connection): This patent describes a residential gateway providing integrated voice and data services.
  • Claims 2, 11 (Multiple telephone numbers/lines): The gateway supports multiple voice channels.
  • Claims 3, 12, 20 (Dynamic bandwidth allocation, voice prioritization): It manages different types of traffic for QoS.
  • Claims 4, 13, 22 (Wireless interface, home networking): The device includes a wireless LAN interface (e.g., 802.11).
  • Claims 5, 14, 21 (Computer connectivity): Provides Ethernet and USB interfaces.
  • Claims 6, 15 (VoIP services): It acts as a VoIP gateway.
  • Claims 7, 16 (Always-on data connection): Provides continuous data access.
  • Claims 8, 17, 25 (Remote upgradability/configuration): The gateway is designed for remote configuration and management.
  • Claim 26 (Video telephone services): It mentions support for video conferencing.

---

Overall Assessment of Prior Art Relevance:

The most relevant prior art appears to be US 2002/0054597 A1 and US 6,307,839 B1 (Gerszbert et al.), both of which focus on providing enhanced residential communication services (voice, data, sometimes video) over existing POTS lines using customer premises equipment without requiring central office modifications. This is a critical distinction that US7606156 emphasizes. While US2002/0054597 A1 specifically mentions DSL, the core idea of a CPE improving POTS capabilities for voice and data is very close.

The unique aspect of US7606156, which these prior arts might not fully anticipate, is the multilink PPP bundle over a plurality of POTS lines from multiple RCGs via a wireless interface to achieve aggregated broadband speeds, as described in claims 9, 18, and 23. While individual prior arts may teach aspects of residential gateways, VoIP, wireless networking, and even dynamic bandwidth allocation, the specific combination of using a wireless ad-hoc network between multiple residential gateways to aggregate multiple standard POTS lines into a single, higher-bandwidth multilink PPP connection for a requesting RCG appears to be a distinguishing feature that would require a detailed claim-by-claim analysis against each piece of prior art.

The following obviousness analysis is performed under 35 U.S.C. § 103, based on the provided patent text for US7606156, and relying on the general technical landscape described within the patent's background and summary as of its priority date (2003-10-14). The full content of the cited prior art documents is not available, so this analysis assumes their general technical relevance based on their patent numbers and the problems US7606156 aims to solve.

Cited Prior Art References (from US7606156):

• US 2002/0054597 (O'Toole et al.)
• US 5,909,445 (Schneider)
• US 6,061,392 (Bremer et al.)
• US 6,167,095 (Furukawa et al.)
• US 6,307,839 (Gerszbert et al.)
• US 6,373,860 (O'Toole et al.)

Understanding the Novel Aspects of US7606156:
US7606156 introduces a Residential Communications Gateway (RCG) that aims to provide broadband voice, data, and video services over existing Plain Old Telephone Service (POTS) lines without requiring any additional or special transmission equipment at the Central Office (Class 5 offices) or in the Public Switched Telephone Network (PSTN) at large. Key inventive features highlighted in the independent claims (1, 10, 18) and the patent summary include:

1. Integrated Gateway Device: An RCG combining IP routers, Class 5 circuit switches, and wireless LANs in a modem-like device.
2. VoIP over POTS without CO upgrades: Enabling advanced voice and data services by packetizing voice (VoIP) and using existing POTS lines, thus avoiding expensive infrastructure enhancements.
3. Dynamic Bandwidth Allocation: Prioritizing voice traffic over data traffic on the POTS connection to ensure Quality of Service (QoS) for real-time voice communications.
4. Multilink PPP Bundle for Broadband over POTS: Leveraging an 802.11b/g wireless interface to connect multiple RCGs and combine their individual POTS line bandwidth using Multilink Point-to-Point Protocol (PPP) (per RFC 1990) to achieve higher data transfer speeds. This bundle is dynamically managed, with RCGs joining or leaving based on local bandwidth demands.
5. Lifeline/Failsafe Operation: The primary POTS port (POTS 1 Port 30) provides uninterrupted basic telephone service directly to the incoming POTS line from the LEC if the RCG loses power.
6. Remote Upgradability: The RCG supports unassisted remote upgrades for features, bug fixes, or entirely new operating systems.

Obviousness Analysis under 35 U.S.C. § 103:

A patent claim is obvious if "the differences between the claimed invention and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art." This requires identifying (1) prior art elements, (2) differences between the claims and the prior art, (3) a motivation to combine or modify the prior art, and (4) a reasonable expectation of success.

At the priority date of US7606156 (October 14, 2003), a Person Having Ordinary Skill in the Art (POSITA) in telecommunications and networking would have been familiar with:

• VoIP Technology: The patent mentions IETF RFC2543 for SIP message handling, indicating SIP-based VoIP was a known standard. The concept of packetizing voice for transmission over IP networks was well-established.
• Wireless LANs (802.11b/g): The 802.11b/g standard for wireless local area networks was ubiquitous for home networking at the time.
• POTS Limitations: The 56 Kbps bandwidth limitation of standard POTS lines due to Class 5 office linecard design and T-carrier based transmission schemes was a known challenge.
• Multilink PPP (RFC 1990): The patent explicitly references RFC 1990, indicating Multilink PPP as a known protocol for aggregating multiple physical links into a single logical link to increase bandwidth.
• Residential Gateways/Routers: Devices combining modem functionality, routing capabilities, and multiple interfaces (Ethernet, USB, wireless) for home connectivity were commercially available.
• Quality of Service (QoS): The importance of prioritizing real-time traffic like voice over data traffic to maintain call quality in packet-switched networks was a known principle.
• Failsafe/Lifeline Functionality: Ensuring basic telephone service during power outages was a common safety feature in telecommunications equipment connected to POTS lines.
• Remote Management/Upgrades: The ability to remotely configure and upgrade network devices was a desirable and increasingly common feature for service providers.

Given this background, we can identify motivations to combine known elements to arrive at the RCG's functionality.

Potential Combinations and Motivations:

1. Combination of a Residential Gateway, VoIP over POTS, and Dynamic Bandwidth Allocation (Addressing Independent Claims 1 and 10, broadly):

• Prior Art Elements: A POSITA would be aware of residential gateways (e.g., DSL/cable modems with integrated routers and wireless capabilities), VoIP systems using IP networks, and standard POTS modems (e.g., 56k modems). Prior art like Schneider (US 5,909,445) or Bremer et al. (US 6,061,392), without knowing their specifics, could plausibly describe aspects of integrating communications or routing.
• Differences (US7606156 vs. Prior Art): The key difference is the RCG's ability to provide multiple phone lines (VoIP) and broadband data over existing POTS lines without requiring any additional infrastructure changes at the Class 5 office. Also, the explicit dynamic bandwidth allocation giving priority to voice over data in a packetized POTS connection.
• Motivation to Combine: The patent explicitly states the problems: CLECs struggling to compete due to high infrastructure costs of DSL/cable and LECs' control over the "last mile." A POSITA would be strongly motivated to find a way for CLECs to offer competitive services (multiple lines, broadband) over the existing POTS infrastructure, thereby significantly reducing deployment costs. Integrating VoIP capabilities into a home gateway device connected to a POTS line, and enabling multiple virtual lines, would be a clear solution to offer enhanced voice services. Furthermore, given the real-time nature of voice, a POSITA would recognize the necessity of prioritizing voice packets over less time-sensitive data packets to maintain acceptable call quality when sharing limited bandwidth over a POTS modem connection, applying known QoS principles. The development of standards like SIP (RFC2543) and advancements in DSPs (as seen in DSP Engine 33 of US7606156) would provide the necessary tools.
• Reasonable Expectation of Success: The technical components (POTS modems, DSPs, embedded CPUs, 802.11 transceivers) were well-understood. Integrating these into a single device and applying known networking protocols like SIP and dynamic QoS mechanisms would be within the skill of a POSITA.

2. Combination of Multilink PPP with Wireless Inter-RCG Communication for Bandwidth Aggregation (Addressing Independent Claims 10 and 18, specific to "broadband over POTS"):

• Prior Art Elements: Multilink PPP (RFC 1990) was a known standard for aggregating bandwidth from multiple physical links. 802.11b/g wireless networking was common for peer-to-peer and infrastructure-based home networking. Modems for connecting over POTS lines were standard.
• Differences (US7606156 vs. Prior Art): The novelty here lies in using a wireless interface (802.11b/g) between multiple RCGs in different residences to coordinate and establish a Multilink PPP bundle over their respective POTS lines, effectively pooling bandwidth for a single data transfer.
• Motivation to Combine: The primary motivation for a POSITA would be to overcome the severe 56 Kbps bandwidth limitation of individual POTS lines to offer "broadband" speeds without requiring costly DSLAM-like infrastructure. Recognizing that Multilink PPP could aggregate bandwidth, and observing the increasing prevalence of wireless home networks (802.11), a POSITA would be motivated to leverage this local wireless connectivity between neighboring RCGs to create a cooperative "virtual multilink bundle." This approach would allow RCGs to "borrow" unused POTS bandwidth from nearby units, thereby achieving higher aggregated speeds (e.g., 1.79 Mbps inbound as stated in the patent) for large file transfers or streaming, as a means to provide competitive "broadband" services. The patent itself highlights that "The RCG gets around the 56 Kbps POTS limitation as well as the DSL problems by using the standard POTS lines as they are, and not requiring any additional equipment to be installed at the Class 5 end of the POTS line." This stated problem and solution directly points to the motivation for a POSITA to combine these elements.
• Reasonable Expectation of Success: Multilink PPP protocols and 802.11 wireless communication were mature technologies. Implementing the coordination logic within the RCGs to negotiate bandwidth sharing and manage the multilink bundle dynamically (e.g., removing links when local demand increases) would be a complex but achievable engineering task for a POSITA with expertise in networking protocols and embedded systems. The dynamic monitoring and adjustment of bandwidth based on local demand is a practical necessity for resource sharing and would be an obvious design choice.

3. Integration of Failsafe (Lifeline) Mode and Remote Upgradability into a Residential Gateway (Addressing Independent Claim 1):

• Prior Art Elements: Failsafe mechanisms for basic POTS line connectivity were common in devices that connect to the PSTN, ensuring emergency services. Remote software/firmware upgrades were also a known practice for network devices and consumer electronics.
• Differences (US7606156 vs. Prior Art): The RCG specifically integrates these features into a single, comprehensive residential communications gateway providing both enhanced VoIP/data and traditional POTS services.
• Motivation to Combine: For a POSITA designing a device that could potentially replace or augment primary telephone service, providing a lifeline (failsafe) connection to the existing POTS line during power outages would be a critical safety and regulatory requirement. Similarly, to manage and maintain a widely deployed network of RCGs and to offer evolving features, remote upgradability would be a highly desirable, if not essential, operational capability for a service provider, allowing for efficient bug fixes and feature enhancements without requiring technician visits. These are standard engineering considerations for robust and maintainable telecommunications equipment.
• Reasonable Expectation of Success: Both failsafe hardware logic and remote software update mechanisms were well-understood and implemented in various electronic devices by the priority date.

Conclusion:

While the detailed contents of the cited prior art patents are not available, the background section of US7606156 clearly outlines the problems the invention sought to solve: the high cost and deployment difficulties of existing broadband solutions (DSL/cable), the static limitations of POTS, and the need for CLECs to offer more competitive services.

A person having ordinary skill in the art at the time of the invention (2003) would have been motivated to combine known technologies such as:

• VoIP and packet switching (e.g., as suggested by IETF RFC2543).
• Residential gateway hardware integrating various interfaces (POTS modem, Ethernet, USB, 802.11 wireless).
• Dynamic Quality of Service (QoS) principles for prioritizing voice over data.
• Multilink PPP (RFC 1990) for aggregating bandwidth.
• 802.11 wireless networking for local device communication.
• Standard failsafe (lifeline) mechanisms for POTS connections.
• Remote management and upgrade capabilities for network devices.

The motivation for these combinations would stem from the desire to provide high-bandwidth, feature-rich communication services over existing, ubiquitous POTS infrastructure without requiring costly central office upgrades, thereby enabling broader and more economical deployment by service providers like CLECs. While specific implementations might vary, the general inventive concepts of the RCG, particularly the integration of VoIP, wireless, dynamic QoS, and especially the novel application of multilink PPP across wirelessly connected residential gateways to aggregate POTS bandwidth, would likely be considered obvious to a POSITA seeking to overcome the stated technical and economic challenges in the telecommunications market at the time.

To determine the patent term adjustments (PTA), patent term extensions (PTE), continuation applications, divisional applications, related family members, and the projected expiration date for US patent 7606156, I will use information directly from the USPTO and general patent law principles.

Patent Term Adjustments (PTA):
Patent Term Adjustment (PTA) extends a patent's term to compensate for certain delays caused by the USPTO during the prosecution of a utility or plant patent application. This adjustment is added to the standard 20-year patent term (from the earliest filing date). The USPTO's system automatically calculates PTA, which is typically noted on the patent's issue notification. Without direct access to the official USPTO file wrapper for patent 7606156, the exact PTA cannot be definitively stated.

Patent Term Extensions (PTE):
Patent Term Extension (PTE) is available for patents on certain human drugs, food or color additives, medical devices, animal drugs, and veterinary biological products. It aims to restore some of the patent term lost due to delays in premarket government approval from regulatory agencies like the FDA. Based on the nature of US patent 7606156, which describes a "Residential Communications Gateway," it does not fall into the categories of products eligible for PTE. Therefore, it is highly unlikely that US7606156 has received any patent term extensions.

Continuation and Divisional Applications:

• A continuation application allows an applicant to pursue claims based on the same specification and drawings as a previously filed "parent" application, provided the parent application is still pending. It typically contains new claims but shares the same priority date as the parent.
• A divisional application is filed when an applicant wants to pursue claims that were originally presented in a parent application but were required by the USPTO to be withdrawn or canceled due to unity of invention rules. A divisional application also shares the same priority date as the parent.

To identify specific continuation or divisional applications for US patent 7606156, one would typically examine the "Related U.S. Application Data" section on the front page of the patent or search the patent family in a USPTO database. The provided patent text for US7606156 indicates: "This first non-provisional patent applications makes claim to the Provisional Application for patent filed Oct. 15, 2002 and titled Residential Communications Gateway, of the same inventorship and with the express mail label no EF 100339383 US." This confirms a priority claim to a provisional application (filed 2002-10-15), but it doesn't explicitly list subsequent continuation or divisional applications. However, Google Patents lists a "priority to US10/686,375" on 2003-10-14, which is the filing date of US7606156, and then several additional priority claims: "priority to US12/581,852" on 2009-10-19, "priority to US13/531,294" on 2012-06-22, "priority to US14/512,414" on 2014-10-11, "priority to US15/161,787" on 2016-05-23, "priority to US17/120,549" on 2020-12-14, and "priority to US17/887,922" on 2022-08-15. These subsequent priority claims indicate the presence of continuing applications in the patent family.

Related Family Members:
The patent family includes US20050078690A1 (an earlier publication of the same application as US7606156B2). Additionally, the listed priority claims to subsequent applications (US12/581,852, US13/531,294, US14/512,414, US15/161,787, US17/120,549, US17/887,922) indicate that these are likely related utility patent applications, such as continuations or divisional applications, that share a common priority to the original filing of US7606156 (or its underlying provisional application).

Projected Expiration Date:
For U.S. utility patents filed on or after June 8, 1995, the patent term generally expires 20 years from the earliest filing date of the application (or the earliest non-provisional application in a chain of priority).

• Earliest non-provisional filing date: October 14, 2003 (for US10/686,375, which became US7606156).
• Base patent term: 20 years from October 14, 2003 = October 14, 2023.

However, Google Patents indicates the patent's legal status as "Active, expires 2026-10-17". This discrepancy suggests that there has been a Patent Term Adjustment (PTA). PTA is added to the 20-year term to compensate for USPTO delays.

Therefore, the projected expiration date for US patent 7606156 is October 17, 2026, which includes an adjustment likely due to USPTO delays during prosecution.

Here is a comprehensive Defensive Disclosure document for US patent 7606156, aimed at rendering future incremental improvements obvious or non-novel.

---

Defensive Disclosure for US7606156 Derivatives

This document describes various derivative works and technical disclosures based on the core inventive concepts of US Patent 7606156, "Residential communications gateway (RCG) for broadband communications over a plurality of standard POTS lines, with dynamic allocation of said bandwidth, that requires no additional equipment or modifications to the associated class 5 offices or the PSTN at large." The aim is to defensively publish these variations to establish prior art, thereby precluding future patenting of incremental improvements by competitors.

The core claims of US7606156 (Claims 1, 10, and 18) describe a Residential Communications Gateway (RCG) device, a method for providing broadband data services using RCGs, and a system comprising multiple RCGs and a Softswitch/SIP Proxy Server. For the purpose of this disclosure, we will focus on Claim 1 (the RCG device) and Claim 10 (the method for broadband services) as representative of the inventive core.

Derivatives of Claim 1: A Residential Communications Gateway (RCG) Device

Claim 1 describes an RCG device comprising:

• An incoming POTS port for connection to a standard telephone line.
• At least one telephone output port for connecting to a standard telephone.
• At least one computer interface (e.g., Ethernet, USB, Firewire).
• A wireless interface (e.g., 802.11b/g).
• A modem/DAA for establishing a continuous internet connection over the POTS line without central office equipment modifications.
• A main processor and a digital signal processor (DSP) for managing voice and data.
• Functionality to assign additional telephone numbers, convert voice to IP packets, prioritize voice traffic, and a failsafe mode for the primary POTS port.

1.1. Material & Component Substitution

Derivative 1.1.1: Software-Defined Radio (SDR) Modem for PSTN Interface

• Enabling Description: The conventional Modem/DAA (Data Access Arrangement) is replaced by a Software-Defined Radio (SDR) module connected directly to the incoming POTS line. This SDR module comprises a high-resolution analog-to-digital converter (ADC), a digital-to-analog converter (DAC), a field-programmable gate array (FPGA) or a powerful digital signal processor (DSP) for baseband processing, and a host microcontroller (e.g., ARM Cortex-M4 or M7). The SDR dynamically reconfigures its modulation schemes (e.g., V.92, V.34, V.22bis) via firmware updates, optimizing line conditions for enhanced data rates or robust lifeline voice service under degraded line quality, potentially extending beyond standard modem speeds if coupled with advanced line coding techniques. The FPGA/DSP handles real-time signal processing, filtering, and echo cancellation, offloading the main CPU.

• graph TD
      POTS_Line -- Analog Signal --> ADC
      ADC -- Digital Stream --> FPGA_SDR
      FPGA_SDR -- Baseband Processing --> DSP_SDR
      DSP_SDR -- Data/Voice Packets --> Host_MCU
      Host_MCU -- Control & Data --> Main_CPU
      Main_CPU -- Data/Voice --> Network_Interfaces
      Host_MCU -- Status & Config --> Display_Keypad
      DAC <-- Digital Stream -- DSP_SDR
      POTS_Line <-- Analog Signal -- DAC
      style ADC fill:#f9f,stroke:#333,stroke-width:2px
      style DAC fill:#f9f,stroke:#333,stroke-width:2px
      style FPGA_SDR fill:#ccf,stroke:#333,stroke-width:2px
      style DSP_SDR fill:#ccf,stroke:#333,stroke-width:2px
      style Host_MCU fill:#afa,stroke:#333,stroke-width:2px
      style Main_CPU fill:#afa,stroke:#333,stroke-width:2px
      style Network_Interfaces fill:#ffc,stroke:#333,stroke-width:2px
      style Display_Keypad fill:#fee,stroke:#333,stroke-width:2px
  

Derivative 1.1.2: GaN-based RF Front-End for Multi-Gigabit Wireless Interface

• Enabling Description: The 802.11b/g wireless interface is upgraded to a multi-gigabit wireless module utilizing Gallium Nitride (GaN) based power amplifiers and low-noise amplifiers in its RF front-end. This enables operation across higher frequency bands (e.g., 60 GHz for 802.11ad/ay or sub-THz for future standards) with significantly improved power efficiency and linearity. The GaN components facilitate extended range and higher data throughput, crucial for robust inter-RCG wireless links and broadband access point connections. The module would employ advanced MIMO (Multiple-Input Multiple-Output) and beamforming techniques, managed by a dedicated baseband processor, to optimize signal integrity and capacity.

• graph TD
      Main_CPU -- Data --> Baseband_Processor
      Baseband_Processor -- Digital RF --> ADC_DAC_RF
      ADC_DAC_RF -- Analog RF --> LNA_GaN -- Amplified Signal --> PA_GaN
      PA_GaN -- Transmit --> Antenna_Array
      Antenna_Array -- Receive --> LNA_GaN
      LNA_GaN -- Low Noise Amp --> ADC_DAC_RF
      ADC_DAC_RF -- Digital RF --> Baseband_Processor
      style Main_CPU fill:#afa,stroke:#333,stroke-width:2px
      style Baseband_Processor fill:#ccf,stroke:#333,stroke-width:2px
      style ADC_DAC_RF fill:#f9f,stroke:#333,stroke-width:2px
      style LNA_GaN fill:#eef,stroke:#333,stroke-width:2px
      style PA_GaN fill:#eef,stroke:#333,stroke-width:2px
      style Antenna_Array fill:#ccc,stroke:#333,stroke-width:2px
  

1.2. Operational Parameter Expansion

Derivative 1.2.1: Industrial-Grade RCG for Extreme Environment Deployment

• Enabling Description: The RCG is hardened for industrial and outdoor environments, operating reliably across extreme temperatures (-40° C to +85° C), high humidity, and vibration. This involves using conformal coatings on PCBs, industrial-grade components (capacitors, resistors, semiconductors rated for extended temperature ranges), and a passively cooled, sealed enclosure (e.g., IP67 rated). Power delivery is enhanced for wider input voltage ranges and surge protection. The wireless module's antenna is external and rated for outdoor exposure. Firmware includes robust error correction and self-healing mechanisms for prolonged autonomous operation.

• graph TD
      Power_Input[Power Input (Wide Range, Surge Protected)] --> Power_Supply_Industrial
      Power_Supply_Industrial --> Main_CPU_Industrial
      Main_CPU_Industrial -- Control --> DSP_Engine_Industrial
      DSP_Engine_Industrial -- Voice/Data --> SLIC_CODEC_Industrial
      SLIC_CODEC_Industrial -- Analog --> POTS_Interface_Industrial
      Main_CPU_Industrial -- Data --> Wireless_Module_Industrial
      Wireless_Module_Industrial -- RF --> External_Antenna_IP67
      Main_CPU_Industrial -- Data --> Computer_Interfaces_Industrial
      POTS_Interface_Industrial -- Lifeline --> Incoming_POTS_Line
      style Main_CPU_Industrial fill:#afa,stroke:#333,stroke-width:2px
      style DSP_Engine_Industrial fill:#ccf,stroke:#333,stroke-width:2px
      style SLIC_CODEC_Industrial fill:#f9f,stroke:#333,stroke-width:2px
      style POTS_Interface_Industrial fill:#ffc,stroke:#333,stroke-width:2px
      style Wireless_Module_Industrial fill:#ffc,stroke:#333,stroke-width:2px
      style Computer_Interfaces_Industrial fill:#ffc,stroke:#333,stroke-width:2px
      style Power_Supply_Industrial fill:#eee,stroke:#333,stroke-width:2px
      style External_Antenna_IP67 fill:#ccc,stroke:#333,stroke-width:2px
  

Derivative 1.2.2: Ultra-Low Latency RCG for Real-Time Control Applications

• Enabling Description: The RCG is optimized for ultra-low latency operation, critical for real-time control systems (e.g., remote robotics, industrial automation). This involves using a real-time operating system (RTOS) on the main CPU, hardware-accelerated packet processing (e.g., dedicated network processing units or FPGAs for SIP/RTP handling), and direct memory access (DMA) for data transfers between components, bypassing CPU overhead. Voice compression algorithms with minimal processing delay (e.g., G.711, low-latency Opus codecs) are prioritized, and jitter buffers are minimized. Inter-RCG wireless links leverage time-sensitive networking (TSN) extensions of Ethernet over wireless to ensure deterministic packet delivery.

• graph TD
      Realtime_App -- Control Signal --> RTOS_Main_CPU
      RTOS_Main_CPU -- Packetization --> HW_Packet_Processor
      HW_Packet_Processor -- Low Latency --> Modem_DAA_Optimized -- POTS --> Network
      RTOS_Main_CPU -- Data --> Wireless_TSN -- Multi-RCG --> Other_RCGs
      HW_Packet_Processor -- Demultiplex --> DSP_Engine_Optimized
      DSP_Engine_Optimized -- Low Latency Voice --> SLIC_CODEC
      SLIC_CODEC -- Analog Voice --> Phone_Ports
      style RTOS_Main_CPU fill:#afa,stroke:#333,stroke-width:2px
      style HW_Packet_Processor fill:#ccf,stroke:#333,stroke-width:2px
      style Modem_DAA_Optimized fill:#f9f,stroke:#333,stroke-width:2px
      style Wireless_TSN fill:#ffc,stroke:#333,stroke-width:2px
      style DSP_Engine_Optimized fill:#ccf,stroke:#333,stroke-width:2px
      style SLIC_CODEC fill:#f9f,stroke:#333,stroke-width:2px
  

1.3. Cross-Domain Application

Derivative 1.3.1: RCG for Remote Agricultural Sensor Networks

• Enabling Description: An RCG configured for agricultural applications functions as a central hub for a mesh of IoT sensors (e.g., soil moisture, temperature, drone data uplinks) across a farm. It uses its wireless interface (e.g., LoRaWAN, Wi-Fi HaLow 802.11ah) to collect data from these sensors. The aggregated sensor data is then transmitted over the existing POTS line (or multiple aggregated POTS lines) to a remote agricultural management platform for analysis and automated irrigation/fertilization control. Voice communication over POTS is maintained for farm personnel, with priority given to emergency alerts from sensors.

• graph TD
      Agri_Sensors -- LoRaWAN/Wi-Fi HaLow --> RCG_Agri_Hub
      RCG_Agri_Hub -- Aggregated Data --> POTS_Modem
      POTS_Modem -- POTS Line --> Cloud_Agri_Platform
      RCG_Agri_Hub -- VoIP --> Farm_Phones
      Agri_Drones -- Wireless Uplink --> RCG_Agri_Hub
      style RCG_Agri_Hub fill:#afa,stroke:#333,stroke-width:2px
      style POTS_Modem fill:#f9f,stroke:#333,stroke-width:2px
      style Cloud_Agri_Platform fill:#ace,stroke:#333,stroke-width:2px
      style Agri_Sensors fill:#ccf,stroke:#333,stroke-width:2px
      style Agri_Drones fill:#ccf,stroke:#333,stroke-width:2px
      style Farm_Phones fill:#ffc,stroke:#333,stroke-width:2px
  

Derivative 1.3.2: RCG for Maritime Vessel Communications

• Enabling Description: The RCG is adapted for maritime use on smaller vessels, integrating with satellite communication systems and acting as a local hub. It connects to the vessel's satellite modem (e.g., Inmarsat BGAN, Iridium Certus) as its primary WAN link, with a fallback to POTS emulation via cellular (if within range) or emergency HF radio data links. The RCG provides onboard VoIP phones for crew communication and a wireless LAN (e.g., 802.11ac/ax) for tablets/laptops. Dynamic bandwidth allocation prioritizes emergency calls, navigation data, and critical engine telemetry over crew internet access.

• graph TD
      Vessel_Sensors -- NMEA/Ethernet --> RCG_Maritime
      Crew_Phones -- VoIP --> RCG_Maritime
      Crew_Laptops -- WLAN --> RCG_Maritime
      RCG_Maritime -- Primary WAN --> Satellite_Modem
      Satellite_Modem -- Satellite Link --> Maritime_Network
      RCG_Maritime -- Secondary WAN (Fallback) --> Cellular_Modem
      Cellular_Modem -- Cellular Link --> PSTN_or_Internet
      RCG_Maritime -- Emergency WAN (Data) --> HF_Radio_Modem
      HF_Radio_Modem -- HF Link --> Emergency_Services
      style RCG_Maritime fill:#afa,stroke:#333,stroke-width:2px
      style Satellite_Modem fill:#f9f,stroke:#333,stroke-width:2px
      style Cellular_Modem fill:#f9f,stroke:#333,stroke-width:2px
      style HF_Radio_Modem fill:#f9f,stroke:#333,stroke-width:2px
      style Maritime_Network fill:#ace,stroke:#333,stroke-width:2px
      style PSTN_or_Internet fill:#ace,stroke:#333,stroke-width:2px
      style Emergency_Services fill:#ace,stroke:#333,stroke-width:2px
  

1.4. Integration with Emerging Tech

Derivative 1.4.1: AI-Optimized RCG with Predictive QoS

• Enabling Description: The RCG integrates an embedded AI/ML inference engine (e.g., using a dedicated neural processing unit or optimized CPU cores). This AI analyzes historical and real-time network conditions, traffic patterns, and application requirements to predict bandwidth demands and proactively adjust QoS parameters. For example, before a scheduled high-bandwidth video conference, the AI could pre-emptively reserve additional multilink PPP bandwidth or prioritize that specific application's traffic over recreational data, minimizing latency and jitter. It also learns optimal voice codec selection based on line quality.

• graph TD
      Network_Traffic_Sensors -- Real-time Data --> AI_Inference_Engine
      AI_Inference_Engine -- Predictive Analysis --> QoS_Manager
      QoS_Manager -- Control --> Modem_DAA_Ports
      QoS_Manager -- Control --> Wireless_Interfaces
      User_Input -- Preferences --> AI_Inference_Engine
      AI_Inference_Engine -- Learning --> Historical_Data_DB
      POTS_Line_Quality -- Monitoring --> AI_Inference_Engine
      style AI_Inference_Engine fill:#afa,stroke:#333,stroke-width:2px
      style QoS_Manager fill:#ccf,stroke:#333,stroke-width:2px
      style Modem_DAA_Ports fill:#f9f,stroke:#333,stroke-width:2px
      style Wireless_Interfaces fill:#ffc,stroke:#333,stroke-width:2px
      style Historical_Data_DB fill:#eee,stroke:#333,stroke-width:2px
  

Derivative 1.4.2: RCG with Blockchain-Verified Service Level Agreements (SLAs)

• Enabling Description: The RCG's operational parameters, service provider agreements, and dynamic bandwidth allocations are managed and verified using a distributed ledger technology (DLT), specifically a permissioned blockchain. Each RCG, upon registration, has a unique digital identity linked to its service contract. QoS parameters and bandwidth commitments (e.g., for multilink PPP participation) are codified as smart contracts on the blockchain. When an RCG requests or offers bandwidth, the transaction is recorded and validated against its smart contract, ensuring fair compensation or compliance. This decentralizes trust and provides an auditable record of service delivery and resource usage.

• graph TD
      RCG_Device -- Service Request --> Blockchain_Node
      Blockchain_Node -- Validate --> Smart_Contract_SLA
      Smart_Contract_SLA -- Verify --> DLT_Network
      DLT_Network -- Authorization --> RCG_Resource_Manager
      RCG_Resource_Manager -- Allocate Bandwidth --> Modem_Wireless
      RCG_Device -- Resource Usage --> Blockchain_Node
      Blockchain_Node -- Record --> DLT_Network
      Service_Provider_Network -- Monitor --> DLT_Network
      style RCG_Device fill:#afa,stroke:#333,stroke-width:2px
      style Blockchain_Node fill:#ccf,stroke:#333,stroke-width:2px
      style Smart_Contract_SLA fill:#ffc,stroke:#333,stroke-width:2px
      style DLT_Network fill:#ace,stroke:#333,stroke-width:2px
      style RCG_Resource_Manager fill:#f9f,stroke:#333,stroke-width:2px
      style Modem_Wireless fill:#f9f,stroke:#333,stroke-width:2px
      style Service_Provider_Network fill:#eee,stroke:#333,stroke-width:2px
  

1.5. The "Inverse" or Failure Mode

Derivative 1.5.1: RCG with Graceful Degradation and Data Prioritization During Partial Failure

• Enabling Description: The RCG incorporates sophisticated self-diagnostics and a multi-tiered graceful degradation mechanism. Upon detection of a power anomaly (e.g., brownout), network congestion, or component failure (e.g., wireless module degradation), the RCG automatically enters a degraded mode. In this mode, it prioritizes critical services: first, lifeline POTS voice (if the primary port is affected), then emergency data packets (e.g., medical alerts, security system alarms) over VoIP, and finally, best-effort data traffic. Non-essential services (e.g., large file downloads, streaming video) are automatically throttled or paused to conserve resources and maintain essential communications. The user is notified via the display and an audible alert about the degraded status and active service prioritizations.

• stateDiagram-v2
      [*] --> Normal_Operation
      Normal_Operation --> Power_Anomaly: Detect Power Loss/Brownout
      Normal_Operation --> Network_Degradation: Detect Congestion/High Latency
      Normal_Operation --> Component_Failure: Detect Module Error
      Power_Anomaly --> Failsafe_Lifeline: Activate Failsafe Logic
      Network_Degradation --> Degraded_Mode_Data_Priority: Throttle Non-Essential Data
      Component_Failure --> Degraded_Mode_Voice_Only: Disable Data, Maintain Voice
      Degraded_Mode_Data_Priority --> Failsafe_Lifeline: Severe Degradation
      Degraded_Mode_Voice_Only --> Failsafe_Lifeline: Complete Failure
      Failsafe_Lifeline --> [*]: Power Restored / Service Recovered
      Degraded_Mode_Data_Priority --> Normal_Operation: Conditions Improve
      Degraded_Mode_Voice_Only --> Normal_Operation: Component Repaired
  

Derivative 1.5.2: RCG in Privacy-by-Design "Stealth Mode"

• Enabling Description: This RCG variant operates with a "Stealth Mode" focused on privacy and minimal detectable footprint. In this mode, the wireless interface's transmission power is dramatically reduced to cover only the immediate vicinity of the device, or it operates solely via directed beamforming to specific, authenticated clients, minimizing RF leakage. MAC address randomization is frequently employed, and unnecessary network protocols or services are disabled. For multilink PPP, participating RCGs use anonymized session IDs and encrypt all inter-RCG metadata. The device proactively scans for unauthorized surveillance attempts and notifies the user, potentially disconnecting non-critical network links.

• graph TD
      User_Activate_Stealth -- Trigger --> RCG_Privacy_Core
      RCG_Privacy_Core -- Configure --> Wireless_Module_Stealth
      Wireless_Module_Stealth -- Low Power TX --> Local_Clients
      Wireless_Module_Stealth -- Beamforming --> Authenticated_Clients
      RCG_Privacy_Core -- Randomize --> MAC_Address_Randomizer
      RCG_Privacy_Core -- Encrypt --> Multilink_Data_Crypto
      Multilink_Data_Crypto -- Secure Link --> Other_RCGs_Stealth
      RCG_Privacy_Core -- Disable Unused --> Network_Services_Manager
      RCG_Privacy_Core -- Monitor --> RF_Spectrum_Monitor
      RF_Spectrum_Monitor -- Alert --> User_Notification_System
      style RCG_Privacy_Core fill:#afa,stroke:#333,stroke-width:2px
      style Wireless_Module_Stealth fill:#ccf,stroke:#333,stroke-width:2px
      style MAC_Address_Randomizer fill:#f9f,stroke:#333,stroke-width:2px
      style Multilink_Data_Crypto fill:#ffc,stroke:#333,stroke-width:2px
      style Other_RCGs_Stealth fill:#ace,stroke:#333,stroke-width:2px
      style Network_Services_Manager fill:#eee,stroke:#333,stroke-width:2px
      style RF_Spectrum_Monitor fill:#ffc,stroke:#333,stroke-width:2px
  

---

Derivatives of Claim 10: Method for Providing Broadband Data Services

Claim 10 describes a method for providing broadband data services to a user's residence, comprising:

• An RCG automatically establishing a modem connection over an existing POTS line.
• Dynamically allocating bandwidth, prioritizing voice over data.
• Using a wireless interface to collaborate with other RCGs to create a multilink PPP bundle over aggregated POTS lines for broadband.
• Continuously monitoring multilink PPP links and dynamically removing links if available bandwidth drops below a threshold to maintain QoS.

2.1. Material & Component Substitution

Derivative 2.1.1: Method Utilizing Visible Light Communication (VLC) for Inter-RCG Links

• Enabling Description: The wireless interface (802.11b/g) for inter-RCG collaboration is replaced with a Visible Light Communication (VLC) module. This method involves RCGs equipped with high-speed LED transceivers and photodiode receivers, communicating line-of-sight. VLC provides secure, high-bandwidth short-range links, particularly useful in dense urban environments to avoid RF interference and provide alternative communication pathways. The multilink PPP bundle is established using these VLC links, with each RCG's POTS line contributing bandwidth. Link quality monitoring for dynamic removal would also incorporate optical signal strength and error rates specific to VLC.

• graph TD
      Initiating_RCG -- VLC Link (LED Tx) --> Remote_RCG_1
      Remote_RCG_1 -- VLC Link (Photodiode Rx) --> Initiating_RCG
      Initiating_RCG -- VLC Link --> Remote_RCG_N
      Remote_RCG_N -- VLC Link --> Initiating_RCG
      Initiating_RCG -- Multilink PPP --> POTS_Line_Initiator
      Remote_RCG_1 -- Multilink PPP --> POTS_Line_1
      Remote_RCG_N -- Multilink PPP --> POTS_Line_N
      POTS_Line_Initiator -- Aggregated --> Broadband_Service
      POTS_Line_1 -- Aggregated --> Broadband_Service
      POTS_Line_N -- Aggregated --> Broadband_Service
      style Initiating_RCG fill:#afa,stroke:#333,stroke-width:2px
      style Remote_RCG_1 fill:#ccf,stroke:#333,stroke-width:2px
      style Remote_RCG_N fill:#ccf,stroke:#333,stroke-width:2px
      style POTS_Line_Initiator fill:#f9f,stroke:#333,stroke-width:2px
      style POTS_Line_1 fill:#f9f,stroke:#333,stroke-width:2px
      style POTS_Line_N fill:#f9f,stroke:#333,stroke-width:2px
      style Broadband_Service fill:#ace,stroke:#333,stroke-width:2px
  

Derivative 2.1.2: Method Utilizing Powerline Communication (PLC) for Local Network Access

• Enabling Description: Instead of or in addition to a traditional modem/DAA over the POTS line, the RCG establishes an always-on data connection using Powerline Communication (PLC) over the existing electrical wiring infrastructure. The RCG incorporates a G.hn or HomePlug AV2 compliant PLC modem. This method dynamically allocates bandwidth between voice (routed via VoIP over the PLC backbone to a central aggregation point) and data. Multiple RCGs within the same electrical grid segment can form a multilink PPP bundle by aggregating their PLC connections, effectively creating a "broadband over powerline" service that can then connect to a wider internet backbone.

• graph TD
      RCG_1 -- PLC Link --> Power_Grid_Segment
      RCG_2 -- PLC Link --> Power_Grid_Segment
      RCG_N -- PLC Link --> Power_Grid_Segment
      Power_Grid_Segment -- Aggregated Data --> Central_PLC_Aggregator
      Central_PLC_Aggregator -- Broadband Link --> Internet
      RCG_1 -- Voice Calls --> Central_PLC_Aggregator
      RCG_2 -- Voice Calls --> Central_PLC_Aggregator
      RCG_N -- Voice Calls --> Central_PLC_Aggregator
      style RCG_1 fill:#afa,stroke:#333,stroke-width:2px
      style RCG_2 fill:#ccf,stroke:#333,stroke-width:2px
      style RCG_N fill:#ccf,stroke:#333,stroke-width:2px
      style Power_Grid_Segment fill:#f9f,stroke:#333,stroke-width:2px
      style Central_PLC_Aggregator fill:#ace,stroke:#333,stroke-width:2px
      style Internet fill:#eee,stroke:#333,stroke-width:2px
  

2.2. Operational Parameter Expansion

Derivative 2.2.1: Massively Scaled Multilink PPP with 1000+ RCGs in Urban Core

• Enabling Description: The multilink PPP bundle concept is scaled to accommodate over 1000 RCGs within a dense urban environment. This requires a robust, self-organizing mesh networking protocol (e.g., using 802.11s or proprietary mesh extensions) for inter-RCG communication, capable of managing hundreds of potential links. The central Softswitch/SIP Proxy Server is augmented with distributed database and load balancing capabilities to handle the registration and dynamic allocation for this scale. The method includes advanced algorithms for route optimization, redundant link management, and intelligent traffic steering across the massive multilink bundle, prioritizing critical infrastructure data (e.g., smart grid sensors, emergency services) over standard voice and data.

• graph TD
      RCG_Cluster_A -- Mesh Network --> RCG_Cluster_B
      RCG_Cluster_B -- Mesh Network --> RCG_Cluster_C
      RCG_Cluster_A -- POTS Links --> Softswitch_Distributed
      RCG_Cluster_B -- POTS Links --> Softswitch_Distributed
      RCG_Cluster_C -- POTS Links --> Softswitch_Distributed
      Softswitch_Distributed -- Aggregated Broadband --> Core_Network
      subgraph Urban Cluster
          RCG_A1 -- 802.11s --> RCG_A2
          RCG_A2 -- 802.11s --> RCG_A3
          RCG_A1 -- POTS --> SIP_Proxy_A
          RCG_A2 -- POTS --> SIP_Proxy_A
          RCG_A3 -- POTS --> SIP_Proxy_A
      end
      subgraph Distributed Softswitch
          SIP_Proxy_A -- Load Balancer --> SIP_Proxy_B
          SIP_Proxy_B -- Database Sync --> Central_Control_Plane
      end
      style RCG_Cluster_A fill:#afa,stroke:#333,stroke-width:2px
      style RCG_Cluster_B fill:#ccf,stroke:#333,stroke-width:2px
      style RCG_Cluster_C fill:#ccf,stroke:#333,stroke-width:2px
      style RCG_A1 fill:#eef,stroke:#333,stroke-width:2px
      style RCG_A2 fill:#eef,stroke:#333,stroke-width:2px
      style RCG_A3 fill:#eef,stroke:#333,stroke-width:2px
      style Softswitch_Distributed fill:#ace,stroke:#333,stroke-width:2px
      style SIP_Proxy_A fill:#ffc,stroke:#333,stroke-width:2px
      style SIP_Proxy_B fill:#ffc,stroke:#333,stroke-width:2px
      style Central_Control_Plane fill:#f9f,stroke:#333,stroke-width:2px
  

Derivative 2.2.2: Ultra-High-Frequency (UHF) Multilink PPP for Rural Long-Range Links

• Enabling Description: For rural deployments with sparse RCG density, the wireless interface for inter-RCG collaboration is replaced with an Ultra-High-Frequency (UHF) transceiver (e.g., operating in license-free ISM bands like 900 MHz or 2.4 GHz, but with enhanced power and antenna gain for extended range). This allows RCGs to form multilink PPP bundles over distances of several kilometers, overcoming terrain obstacles more effectively than standard 802.11. The method employs advanced forward error correction (FEC) and adaptive coding and modulation (ACM) to maintain stable data rates over long, potentially noisy, wireless links. Dynamic link management accounts for signal strength fluctuations and atmospheric conditions over these longer distances.

• graph TD
      Initiating_RCG -- UHF Wireless --> Remote_RCG_1
      Remote_RCG_1 -- UHF Wireless --> Remote_RCG_2
      Remote_RCG_2 -- UHF Wireless --> Remote_RCG_N
      Initiating_RCG -- Multilink PPP --> POTS_Line_A
      Remote_RCG_1 -- Multilink PPP --> POTS_Line_B
      Remote_RCG_2 -- Multilink PPP --> POTS_Line_C
      Remote_RCG_N -- Multilink PPP --> POTS_Line_D
      POTS_Line_A -- Aggregated --> Rural_Broadband_Hub
      POTS_Line_B -- Aggregated --> Rural_Broadband_Hub
      POTS_Line_C -- Aggregated --> Rural_Broadband_Hub
      POTS_Line_D -- Aggregated --> Rural_Broadband_Hub
      style Initiating_RCG fill:#afa,stroke:#333,stroke-width:2px
      style Remote_RCG_1 fill:#ccf,stroke:#333,stroke-width:2px
      style Remote_RCG_2 fill:#ccf,stroke:#333,stroke-width:2px
      style Remote_RCG_N fill:#ccf,stroke:#333,stroke-width:2px
      style POTS_Line_A fill:#f9f,stroke:#333,stroke-width:2px
      style POTS_Line_B fill:#f9f,stroke:#333,stroke-width:2px
      style POTS_Line_C fill:#f9f,stroke:#333,stroke-width:2px
      style POTS_Line_D fill:#f9f,stroke:#333,stroke-width:2px
      style Rural_Broadband_Hub fill:#ace,stroke:#333,stroke-width:2px
  

2.3. Cross-Domain Application

Derivative 2.3.1: Broadband Aggregation for Remote Telemedicine Diagnostics

• Enabling Description: This method applies the multilink PPP aggregation to remote telemedicine. An RCG in a patient's home aggregates multiple POTS lines (potentially including those of neighbors participating in the bundle) to create a high-bandwidth link for transmitting large medical diagnostic files (e.g., high-resolution radiology images, live endoscopic video, volumetric scans). Voice communications for teleconsultation are prioritized, but the aggregated data link ensures rapid, reliable transfer of bandwidth-intensive data for timely diagnosis by specialists located remotely. Dynamic link management ensures QoS for critical data streams, adding more links if a diagnostic upload is initiated.

• graph TD
      Patient_RCG -- Aggregated POTS --> Telemedicine_Cloud
      Neighbor_RCG_1 -- Wireless --> Patient_RCG
      Neighbor_RCG_2 -- Wireless --> Patient_RCG
      Patient_RCG -- Medical Data Uplink --> Telemedicine_Cloud
      Patient_RCG -- Teleconsultation VoIP --> Telemedicine_Cloud
      Medical_Devices -- Local Network --> Patient_RCG
      style Patient_RCG fill:#afa,stroke:#333,stroke-width:2px
      style Neighbor_RCG_1 fill:#ccf,stroke:#333,stroke-width:2px
      style Neighbor_RCG_2 fill:#ccf,stroke:#333,stroke-width:2px
      style Telemedicine_Cloud fill:#ace,stroke:#333,stroke-width:2px
      style Medical_Devices fill:#ffc,stroke:#333,stroke-width:2px
  

Derivative 2.3.2: Dynamic Bandwidth Pooling for Smart City Sensor Backhaul

• Enabling Description: RCGs are deployed across a smart city infrastructure (e.g., embedded in streetlights, traffic signals, public utility boxes), each connected to a legacy POTS line. These RCGs form a dynamic wireless mesh network to pool their individual POTS bandwidth into a shared multilink PPP bundle. This aggregated bandwidth is then used as a backhaul for smart city sensors (e.g., air quality monitors, noise sensors, traffic cameras, smart parking sensors) that communicate with the RCGs via short-range wireless (e.g., BLE, Zigbee, 802.11ax). The method dynamically prioritizes critical sensor data (e.g., emergency alerts, environmental hazard readings) over routine telemetry, optimizing the limited POTS bandwidth for urban data collection.

• graph TD
      Smart_Sensors_A -- Wireless --> RCG_A_SC
      Smart_Sensors_B -- Wireless --> RCG_B_SC
      RCG_A_SC -- Wireless Mesh --> RCG_B_SC
      RCG_B_SC -- Wireless Mesh --> RCG_C_SC
      RCG_A_SC -- POTS --> Smart_City_Platform
      RCG_B_SC -- POTS --> Smart_City_Platform
      RCG_C_SC -- POTS --> Smart_City_Platform
      RCG_C_SC -- Wireless Mesh --> RCG_A_SC
      style RCG_A_SC fill:#afa,stroke:#333,stroke-width:2px
      style RCG_B_SC fill:#ccf,stroke:#333,stroke-width:2px
      style RCG_C_SC fill:#ccf,stroke:#333,stroke-width:2px
      style Smart_Sensors_A fill:#ffc,stroke:#333,stroke-width:2px
      style Smart_Sensors_B fill:#f9f,stroke:#333,stroke-width:2px
      style Smart_City_Platform fill:#ace,stroke:#333,stroke-width:2px
  

2.4. Integration with Emerging Tech

Derivative 2.4.1: AI-Driven Multilink PPP Orchestration with SDN/NFV

• Enabling Description: The multilink PPP method is integrated with Software-Defined Networking (SDN) and Network Function Virtualization (NFV) principles. An AI-powered SDN controller dynamically orchestrates the formation and management of multilink PPP bundles across RCGs. The RCGs themselves expose APIs to the controller, allowing for programmatic control over their POTS modems and wireless interfaces. NFV allows for virtualized network functions (e.g., firewalls, deep packet inspection, traffic shapers) to be instantiated and chained on demand, either within a powerful RCG or at an edge aggregation point, optimizing resource utilization and providing flexible, dynamic network services over the aggregated POTS bandwidth.

• graph TD
      AI_SDN_Controller -- Orchestrate --> RCG_Network_APIs
      RCG_Network_APIs -- Control --> RCGs_as_NFV_Nodes
      RCGs_as_NFV_Nodes -- Multilink PPP --> Virtual_Network_Functions
      Virtual_Network_Functions -- Data Plane --> Aggregated_POTS_Backbone
      AI_SDN_Controller -- Monitor --> Realtime_Traffic_Analytics
      Realtime_Traffic_Analytics -- Feedback --> AI_SDN_Controller
      style AI_SDN_Controller fill:#afa,stroke:#333,stroke-width:2px
      style RCG_Network_APIs fill:#ccf,stroke:#333,stroke-width:2px
      style RCGs_as_NFV_Nodes fill:#ffc,stroke:#333,stroke-width:2px
      style Virtual_Network_Functions fill:#f9f,stroke:#333,stroke-width:2px
      style Aggregated_POTS_Backbone fill:#ace,stroke:#333,stroke-width:2px
      style Realtime_Traffic_Analytics fill:#eee,stroke:#333,stroke-width:2px
  

Derivative 2.4.2: Multilink PPP with Quantum Key Distribution (QKD) for Secure Sessions

• Enabling Description: To enhance the security of the multilink PPP bundle, particularly for sensitive data transfers (e.g., financial transactions, confidential corporate communications), Quantum Key Distribution (QKD) is integrated into the inter-RCG wireless communication. Each RCG involved in the bundle utilizes a QKD module to establish a shared, provably secure cryptographic key with other participating RCGs. This quantum-generated key is then used to encrypt the multilink PPP data payload and control plane messages. This ensures that even if traditional cryptographic methods are compromised, the integrity and confidentiality of the aggregated broadband session are maintained by the principles of quantum mechanics.

• graph TD
      Initiating_RCG -- Quantum Channel (Wireless/Optical) --> Remote_RCG_1
      Remote_RCG_1 -- QKD Protocol --> Shared_Quantum_Key
      Shared_Quantum_Key -- Encrypt --> Multilink_PPP_Data_Tunnel
      Multilink_PPP_Data_Tunnel -- Over POTS --> Secure_Broadband_Connection
      Initiating_RCG -- Control Channel --> Remote_RCG_1
      style Initiating_RCG fill:#afa,stroke:#333,stroke-width:2px
      style Remote_RCG_1 fill:#ccf,stroke:#333,stroke-width:2px
      style Shared_Quantum_Key fill:#ffc,stroke:#333,stroke-width:2px
      style Multilink_PPP_Data_Tunnel fill:#f9f,stroke:#333,stroke-width:2px
      style Secure_Broadband_Connection fill:#ace,stroke:#333,stroke-width:2px
  

2.5. The "Inverse" or Failure Mode

Derivative 2.5.1: Multilink PPP Method with "Bandwidth-Shedding" for Critical Services

• Enabling Description: This method focuses on extreme robustness and prioritization during network duress. Instead of simply dropping multilink PPP links when bandwidth degrades, a "bandwidth-shedding" algorithm is implemented. This algorithm dynamically identifies and sheds non-essential data streams (e.g., software updates, bulk downloads, recreational browsing) from the multilink bundle, freeing up capacity for predetermined critical services (e.g., emergency VoIP calls, vital IoT telemetry, remote control signals) to maintain their QoS. The shedding process is tiered, with progressively less important traffic being deprioritized or paused, providing a granular degradation experience rather than an abrupt service outage.

• stateDiagram-v2
      state "Normal Operation" as Normal
      state "Mild Congestion" as Mild
      state "Moderate Congestion" as Moderate
      state "Severe Congestion" as Severe
      state "Emergency Mode" as Emergency
  
      [*] --> Normal
  
      Normal --> Mild: (Link Utilization > 70%)
      Mild --> Moderate: (Link Utilization > 85%)
      Moderate --> Severe: (Link Utilization > 95%)
      Severe --> Emergency: (Critical Service QoS Degradation)
  
      Mild --> Normal: (Link Utilization < 70%)
      Moderate --> Mild: (Link Utilization < 85%)
      Severe --> Moderate: (Link Utilization < 95%)
      Emergency --> Severe: (Critical Service QoS Restored)
  
      state "Normal" {
          Voice_QoS_High: Voice Calls (Priority 1)
          Critical_Data_QoS_High: Critical Data (Priority 2)
          Best_Effort_Data: Best Effort Data (Priority 3)
      }
  
      state "Mild" {
          Best_Effort_Data: Throttled (Priority 3)
          Voice_QoS_High
          Critical_Data_QoS_High
      }
  
      state "Moderate" {
          Best_Effort_Data: Paused (Priority 3)
          Voice_QoS_High
          Critical_Data_QoS_High: Bandwidth Ensured
      }
  
      state "Severe" {
          Best_Effort_Data: Dropped (Priority 3)
          Non_Critical_VoIP: Throttled (Priority 2.5)
          Critical_Data_QoS_High
          Emergency_VoIP_Guaranteed: Emergency Voice (Priority 1)
      }
      
      state "Emergency" {
          All_Non_Emergency_Traffic: Dropped
          Emergency_VoIP_Guaranteed
          Critical_Safety_Data_Guaranteed: Critical Safety Data (Priority 1)
      }
  

Derivative 2.5.2: Multilink PPP in "Data-Only Failsafe" Mode for Public Safety

• Enabling Description: In this mode, the multilink PPP method prioritizes specific, authenticated data streams for public safety or disaster response when voice communications are compromised or overloaded. If an RCG (or a cluster of RCGs) detects a local emergency (e.g., via IoT sensors, manual input, or network-wide alert), it can activate a "data-only failsafe" mode. In this mode, all voice traffic not explicitly designated as emergency communication is suppressed or downgraded. The aggregated POTS bandwidth is then exclusively or predominantly allocated to transmitting critical data such as emergency service requests, location tracking data, environmental hazard readings, or disaster victim manifests, ensuring that essential digital information reaches response teams even under severe network stress.

• sequenceDiagram
      participant RCG_A as RCG A (Public Safety)
      participant RCG_B as RCG B (Neighbor)
      participant Softswitch as Softswitch/SIP Proxy
      participant Internet as Internet/Public Safety Network
  
      RCG_A->>RCG_A: Detects Local Emergency
      RCG_A->>RCG_A: Activates "Data-Only Failsafe"
      RCG_A->>Softswitch: Request Emergency Data Prioritization
      Softswitch-->>RCG_A: Acknowledge & Configure
      RCG_A->>RCG_B: Request Multilink PPP (Data-Only Failsafe, High Priority)
      RCG_B-->>RCG_A: Accepts (Voice Suppressed)
      RCG_A->>RCG_B: Establish Multilink PPP for Public Safety Data
      RCG_A->>Internet: Transmit Critical Data (High Priority)
      RCG_B->>Internet: Transmit Critical Data (High Priority)
      Note over RCG_A,Internet: All non-emergency voice/data suppressed
  

---

Combination Prior Art Scenarios

Here are at least three "Combination Prior Art" scenarios where the principles of US7606156 can be combined with existing open-source standards.

1. RCG Functionality Integrated with OpenWrt for Enhanced Home Networking

• Combination: US7606156's RCG capabilities (VoIP over POTS, dynamic bandwidth allocation, multilink PPP over wireless, failsafe lifeline) combined with a router running OpenWrt, an open-source Linux distribution for embedded devices.
• Enabling Description: An RCG hardware platform, based on common SoC architectures (e.g., MIPS, ARM) found in consumer routers, is loaded with a custom OpenWrt firmware. This firmware includes modules for:
  • POTS Interface Driver: To manage the Modem/DAA (e.g., leveraging hso_modem or similar kernel modules) and SLIC/CODEC for analog phone ports.
  • SIP/RTP Stack: Utilizes standard VoIP libraries (e.g., PJSIP, reSIProcate) for call handling and packetization.
  • QoS/Traffic Shaping: Implements tc (Traffic Control) utilities and netfilter rules in the Linux kernel to prioritize VoIP packets (e.g., using DiffServ or custom queues) over other data traffic.
  • Multilink PPP Daemon: Integrates pppd with a custom chat script and wireless interface monitor. The OpenWrt device acts as the initiating RCG, forming a virtual network interface that aggregates multiple POTS modem connections from other OpenWrt-enabled RCGs discovered via 802.11 wireless (using standard hostapd/wpa_supplicant functionality).
  • Lifeline Failover Script: A kernel module or udev script detects power loss or Modem/DAA failure and triggers a relay to directly connect POTS 1 Port 30 to Incoming POTS Port 40.
    This combination provides a highly configurable and extensible RCG that leverages mature open-source networking stacks.

• graph TD
      POTS_In --> Modem_DAA_Driver
      Modem_DAA_Driver -- PPP Connection --> Kernel_Network_Stack
      Kernel_Network_Stack -- QOS_Rules --> Traffic_Control
      Traffic_Control -- Priority --> VoIP_Stack
      VoIP_Stack -- SIP/RTP --> Phone_Ports
      Kernel_Network_Stack -- Data --> Computer_Interfaces
      WLAN_Driver -- 802.11 --> Wireless_Interface
      Wireless_Interface -- RCG Discovery --> Other_OpenWrt_RCGs
      Multilink_PPP_Daemon -- Manage Links --> Kernel_Network_Stack
      Power_Monitor -- Detect Failure --> Lifeline_Failover_Script
      Lifeline_Failover_Script -- Trigger --> Hardware_Relay
      Hardware_Relay -- Direct Connect --> POTS_In
      subgraph OpenWrt Firmware
          Kernel_Network_Stack
          Modem_DAA_Driver
          VoIP_Stack
          Traffic_Control
          Multilink_PPP_Daemon
          Lifeline_Failover_Script
      end
      style OpenWrt_Firmware fill:#eee,stroke:#333,stroke-width:2px
  

2. VoIP Services with Asterisk for Advanced Telephony Features

• Combination: US7606156's RCG's multi-line VoIP and call routing features combined with the open-source telephony engine Asterisk (or FreeSWITCH).
• Enabling Description: An RCG is implemented with a powerful embedded processor capable of running a full Linux distribution, where Asterisk is installed. The RCG's DSP Engine 33 and SLIC/CODEC Interface 27 are exposed to Asterisk as DAHDI (Digium/Asterisk Hardware Device Interface) channels. Asterisk handles all aspects of call processing, including:
  • Multiple Telephone Numbers: Each POTS port on the RCG is configured as an extension within Asterisk, allowing flexible routing, call waiting, caller ID, etc.
  • Custom Call Routing: Asterisk's dialplan defines complex call routing logic for local, long-distance, and international calls, as well as internal RCG-to-RCG VoIP calls over the aggregated broadband link.
  • Voice Messaging/Conferencing: Asterisk provides integrated voicemail, IVR (Interactive Voice Response) systems, and conferencing capabilities directly from the RCG.
  • SIP Proxy Functionality: Asterisk can register with external SIP proxy servers or act as a local SIP registrar for IP-based phones within the home network.
    The RCG's modem connection provides the underlying IP transport for Asterisk, with QoS rules (as described in US7606156) ensuring voice priority. This setup demonstrates a robust, feature-rich, and entirely open-source driven RCG for advanced residential telephony.

• graph TD
      POTS_Ports -- Analog --> SLIC_CODEC
      SLIC_CODEC -- DAHDI Channels --> Asterisk_Engine
      Asterisk_Engine -- SIP/RTP --> Modem_DAA_Interface
      Modem_DAA_Interface -- IP Network --> Internet_PSTN
      Asterisk_Engine -- Dialplan/Features --> VoIP_Clients_LAN
      Asterisk_Engine -- Call Routing --> Other_RCGs_via_IP
      subgraph RCG Device
          SLIC_CODEC
          Modem_DAA_Interface
          Asterisk_Engine
      end
      style RCG_Device fill:#eee,stroke:#333,stroke-width:2px
  

3. RCG Data Aggregation with MQTT and Apache Kafka for IoT Integration

• Combination: US7606156's RCG's data aggregation and routing capabilities combined with MQTT (Message Queuing Telemetry Transport) for IoT messaging and Apache Kafka for real-time data streaming.
• Enabling Description: An RCG is configured to act as an IoT gateway. Its wireless interface (e.g., 802.11, Zigbee, LoRa) connects to various smart home or environmental IoT sensors. The RCG runs an embedded MQTT broker (e.g., Eclipse Mosquitto) to collect data from these sensors. This aggregated telemetry is then streamed over the RCG's single or multilink PPP aggregated POTS broadband connection to a remote Apache Kafka cluster. Kafka is used for scalable, fault-tolerant ingestion and processing of the high-volume, real-time sensor data. The RCG ensures that public safety or critical infrastructure sensor data (e.g., fire alarms, leak detectors) are prioritized over other non-critical data streams (e.g., room temperature, light levels) using the dynamic bandwidth allocation mechanism described in US7606156.

• graph TD
      IoT_Sensors_A -- Wireless (MQTT) --> RCG_IoT_Gateway
      IoT_Sensors_B -- Wireless (MQTT) --> RCG_IoT_Gateway
      RCG_IoT_Gateway -- Multilink PPP --> Kafka_Producer
      Kafka_Producer -- Data Stream --> Apache_Kafka_Cluster
      Apache_Kafka_Cluster -- Analytics/Storage --> Cloud_Platform
      RCG_IoT_Gateway -- Voice Calls --> PSTN_Internet
      style RCG_IoT_Gateway fill:#afa,stroke:#333,stroke-width:2px
      style IoT_Sensors_A fill:#ccf,stroke:#333,stroke-width:2px
      style IoT_Sensors_B fill:#ccf,stroke:#333,stroke-width:2px
      style Kafka_Producer fill:#ffc,stroke:#333,stroke-width:2px
      style Apache_Kafka_Cluster fill:#ace,stroke:#333,stroke-width:2px
      style Cloud_Platform fill:#eee,stroke:#333,stroke-width:2px