US 11582343

Here's a concise summary of US Patent 11582343:

Title: Devices and methods for multipath communications

Assignee: Competitive Access Systems Inc.

Inventor: Eric M. DeLangis

Filing Date: August 15, 2022

Issue Date: February 14, 2023

Abstract: The patent describes broadband communication devices and methods that use at least two separate communication paths to the network, such as the Internet. These devices can receive data concurrently or separately over these paths. The bandwidth is increased by combining the separate communication paths. The devices utilize packetized data with Voice over Internet Protocol (VoIP) technologies integrated with RF (Radio Frequency) communication technologies.

Plain-Language Overview of Independent Claims:

• Claim 1: This claim describes a residential gateway (RCG) device designed for multipath communication. It includes a POTS (Plain Old Telephone Service) line interface to connect to a conventional telephone network, a modem to establish a network connection over the POTS line, and a wireless interface (like 802.11b/g) for wireless communication. The RCG has a processor that manages all these components. This processor is configured to monitor the wireless interface for other compatible RCGs or wireless access points. When detected, it can use the wireless interface to establish a multilink data connection that combines the bandwidth of multiple POTS lines from different RCGs, or to connect directly to a broadband wireless access point. This allows for increased data transfer speeds.

• Claim 11: This claim focuses on a method for providing multipath communication using the RCG device. The method involves connecting the RCG to a POTS line and a telephone. It then establishes a modem connection over the POTS line for network access. The RCG monitors its wireless interface for other compatible RCGs or wireless access points. Upon detection, the method involves initiating a multilink PPP (Point-to-Point Protocol) session by combining the POTS lines of multiple RCGs or connecting directly to a broadband wireless access point via the wireless interface to achieve higher bandwidth data transfer.

CAFC 2026 Dockets:
A search of CAFC 2026 dockets for patent US11582343 did not yield specific results. However, the Google Patents information indicates that the patent family has ongoing litigation, including several US district court cases filed in 2024 and 2025, and one PTAB (Patent Trial and Appeal Board) case filed in 2025. There are no specific CAFC cases identified in the provided information for 2026.

US Patent 11582343 is involved in several litigation cases, as detailed in the patent's information on Google Patents. The information regarding plaintiffs, defendants, and precise filing dates for all cases is not fully available in the provided text.

Here is a summary of the known litigation:

• Jurisdiction: North Carolina Eastern District Court

  • Case Number: 5:24-cv-00505
  • Status: Critical (from Google Patents)
  • Source: District Court
  • Filing Date: Not explicitly stated, but inferred as 2024 from the case number.
  • Plaintiff(s)/Defendant(s): Not provided in the patent text.

• Jurisdiction: California Northern District Court

  • Case Number: 5:25-cv-04595
  • Source: District Court
  • Filing Date: Not explicitly stated, but inferred as 2025 from the case number.
  • Plaintiff(s)/Defendant(s): Not provided in the patent text.

• Jurisdiction: PTAB (Patent Trial and Appeal Board)

  • Case Number: IPR2025-01370
  • Outcome/Current Status: Not Instituted - Procedural
  • Filing Date: Not explicitly stated, but inferred as 2025 from the case number.
  • Petitioner: Not provided in the patent text.

• Jurisdiction: Texas Northern District Court

  • Case Number: 4:25-cv-00948
  • Source: District Court
  • Filing Date: Not explicitly stated, but inferred as 2025 from the case number.
  • Plaintiff(s)/Defendant(s): Not provided in the patent text.

• Jurisdiction: North Carolina Eastern District Court

  • Case Number: 4:24-cv-00130
  • Source: District Court
  • Filing Date: Not explicitly stated, but inferred as 2024 from the case number.
  • Plaintiff(s)/Defendant(s): Not provided in the patent text.

• First worldwide family litigation filed

  • URL: https://patents.darts-ip.com/?family=34423280&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=[US11582343](/patent/US11582343)(B2)
  • Details: Specific case number, plaintiff(s), defendant(s), jurisdiction, filing date, and outcome are not provided in the patent text for this entry, only that it is the "First worldwide family litigation filed."

• Jurisdiction: California Northern District Court

  • Case Number: 3:25-cv-04595
  • Source: District Court
  • Filing Date: Not explicitly stated, but inferred as 2025 from the case number.
  • Plaintiff(s)/Defendant(s): Not provided in the patent text.

• Jurisdiction: Texas Eastern District Court

  • Case Number: 4:25-cv-00886
  • Source: District Court
  • Filing Date: Not explicitly stated, but inferred as 2025 from the case number.
  • Plaintiff(s)/Defendant(s): Not provided in the patent text.

Proceedings overview

There is one AIA trial proceeding on file for US Patent 11582343. The sole proceeding, IPR2025-01370, resulted in a discretionary denial of institution, meaning no claims were challenged on the merits. This outcome suggests a strengthened defensive posture for the patent owner, as the patent has survived an initial challenge without any claims being invalidated.

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

• Type: Inter Partes Review
• Filed: 2025-08-01
• Status: Discretionary Denial — The PTAB declined to institute the IPR based on procedural grounds, rather than on the merits of the patentability challenge.
• Judge panel: Not publicly available without accessing the specific PTAB filing, which is beyond the scope of this tool.
• Petition grounds: Specific claims, prior art references, and statutory bases (e.g., § 102 for anticipation, § 103 for obviousness) challenged by Red Hat, Inc. are not explicitly detailed in the provided information or readily available from general public searches without access to the petition itself.
• Institution decision: Denied. The institution was procedurally denied on 2026-03-25. The specific reasoning for the "Discretionary Denial - Procedural" is not available in the provided data or general Google Patents information. Such denials often relate to issues like parallel litigation, petition defects, or strategic timing, per Fintiv or other discretionary rules.
• Final Written Decision (if issued): Not applicable, as institution was denied.
• Settlement / termination: Not applicable, as institution was denied.
• Appeal: Not applicable, as there was no Final Written Decision to appeal.
• Defensive value: The discretionary denial means the patent claims were not reviewed on their merits in this IPR. While not a finding of patentability, it means the patent owner successfully fended off this particular challenge, and the claims remain formally unchallenged by this IPR. Any future defendant would need to consider the specific grounds raised in this petition and the PTAB's reasoning for denial if they wish to pursue a similar IPR strategy.

Strategic summary

Currently, no claims of US11582343 have been canceled or found unpatentable through AIA trial proceedings. The single IPR filed, IPR2025-01370, resulted in a discretionary denial of institution, meaning the PTAB did not proceed to a full review of the patentability of the challenged claims. Consequently, all claims of US11582343 remain UNTESTED on their merits in the PTAB context.

The estoppel landscape remains largely unchanged due to the discretionary denial. Since institution was denied, the petitioner (Red Hat, Inc.) and its privies are not estopped under § 315(e)(2) from raising any ground that was raised or reasonably could have been raised in the IPR. This is because estoppel typically only applies after a final written decision on the merits. Therefore, a defendant currently facing assertion of this patent could potentially still challenge the patent using the same prior art and grounds as Red Hat, Inc., provided they meet the statutory requirements for filing a petition.

Regarding pattern signals, the fact that Red Hat, Inc. filed the IPR suggests it may be a target of assertion or seeking to clear the path for its products. The "Discretionary Denial - Procedural" status indicates the PTAB invoked its discretion, possibly due to factors like parallel district court litigation (which Google Patents indicates is ongoing for this patent family) or the stage of litigation, rather than a weakness in Red Hat's underlying unpatentability arguments. The patent owner, Competitive Access Systems Inc., successfully avoided a merits review in this instance.

Recommended next steps

Since IPR2025-01370 was denied institution, there is no Final Written Decision to link to or specific claims that have been invalidated. The patent claims are all currently presumed valid.

For a defendant facing assertion of US11582343, it would be crucial to:

1. Obtain and review the petition for IPR2025-01370: Understand the specific claims challenged and the prior art and grounds raised by Red Hat, Inc.
2. Review the PTAB's decision for IPR2025-01370: Understand the specific procedural reason for the discretionary denial to determine if those issues could be avoided in a new petition. This will likely involve checking the USPTO PTAB E2E system for the full decision.
3. Analyze the ongoing litigation: As the Google Patents information indicates multiple district court cases, understanding the claims asserted in those cases and the corresponding defenses raised will be vital. The denial of IPR institution might be linked to these concurrent litigations.

Inventors

The sole named inventor for US Patent 11582343 is Eric M. DeLangis. It is highly probable that Eric M. DeLangis was employed by Competitive Access Systems Inc., which is listed as both the original and current assignee, at the time of the original priority filing (October 15, 2002) and at the filing of this continuation patent (August 15, 2022).

Original assignee

The entity named on the issued patent is Competitive Access Systems Inc. There is no evidence from available search results to suggest that Competitive Access Systems Inc. currently ships a product embodying the claims of US11582343. Instead, Competitive Access Systems Inc. is identified as a Patent Assertion Entity (NPE) by Unified Patents. Its primary line of business appears to be patent licensing and litigation. The company is currently operating and is actively involved in patent litigation, with several US district court cases filed in 2024 and 2025, and a PTAB case filed in 2025.

Assignment timeline

A search of the USPTO Patent Assignment Search database for US patent 11582343 (https://assignmentcenter.uspto.gov/) yielded no recorded assignments for this patent after its issuance. Therefore, the original assignee, Competitive Access Systems Inc., remains the current recorded assignee.

Timeline diagram

timeline
    title Ownership of US 11582343
    2002 : Priority date
    2022 : Filed by Competitive Access Systems Inc
    2023 : Issued
    2024 : Litigation started by CAS

NPE / troll-pattern signals

1. Shell-entity transfer — Not present. No transfers have been recorded for this specific patent. However, Competitive Access Systems Inc., the original and current assignee, is identified as an NPE (Patent Assertion Entity) by Unified Patents.
2. Known asserter in the chain — Present. Competitive Access Systems Inc. is identified as an NPE by Unified Patents. They are the current assignee and have initiated multiple infringement lawsuits.
3. Repeat correspondent across the chain — Not present. No assignments are recorded in the chain for this patent.
4. Cascading transfers — Not present. No assignments are recorded in the chain for this patent.
5. Pre-litigation transfer — Unclear. No transfers are recorded for this patent, so the timing relative to litigation cannot be assessed. However, litigation involving this patent and related patents, initiated by Competitive Access Systems Inc., began in 2024 and 2025.
6. Bankruptcy fire-sale — Not present. There is no indication of bankruptcy or a sale in bankruptcy proceedings for Competitive Access Systems Inc. in the provided information.
7. Privateering — Not present. No transfers from an operating company to an NPE acting on its behalf are recorded.
8. Defensive aggregator (anti-NPE) — Not present. There is no transfer to a defensive aggregator in the chain.

Verdict

NPE — high confidence
This verdict is based on the direct identification of Competitive Access Systems Inc. as a Patent Assertion Entity (NPE) by Unified Patents. Furthermore, Competitive Access Systems Inc. is actively engaged in patent infringement litigation concerning US11582343 and related patents, with cases filed in 2024 and 2025. The lack of recorded assignments on the USPTO Assignment Center (https://assignmentcenter.uspto.gov/ ) indicates the patent has remained with this entity since issuance.

To identify the most relevant prior art for US Patent 11582343, I will access the USPTO patent database. The USPTO provides a Patent Public Search tool for this purpose. Prior art includes any information publicly known before the effective filing date of a U.S. patent application, such as U.S. patents and published patent applications, foreign patents, journal articles, and websites.

I will now search the USPTO database for patent number 11582343 and then examine the "References Cited" section of the patent document to identify prior art. For each cited reference, I will extract the full citation, publication/filing date, a brief description, and determine which claims it potentially anticipates under 35 U.S.C. § 102.

Since I do not have direct access to the USPTO database for live searching, I will proceed by stating how the prior art would be identified and analyzed based on the provided patent text, which includes a "Prior art keywords" section and "RELATED APPLICATIONS" section. The "RELATED APPLICATIONS" section lists patents which this patent is a continuation of, and these patents would inherently be prior art.

Based on the provided patent text for US11582343, the "RELATED APPLICATIONS" section lists the following as directly related and therefore potential prior art:

• U.S. patent application Ser. No. 17/120,549

  • Full Citation: U.S. patent application Ser. No. 17/120,549, filed on Dec. 14, 2020, patented as U.S. Pat. No. 11,418,641.
  • Publication/Filing Date: December 14, 2020
  • Brief Description: This is a continuation of several earlier applications, ultimately claiming priority to a provisional application from October 15, 2002. As a direct antecedent in the patent family, it would cover similar ground regarding multipath communications devices and methods, including the use of POTS, wireless interfaces, and bandwidth aggregation.
  • Potential Anticipated Claims: Given it's a direct continuation, it is highly likely to anticipate all claims (Claim 1, Claim 11, and any other dependent claims) of US11582343 under 35 U.S.C. § 102, as the subject matter would be substantially similar or identical.

• U.S. patent application Ser. No. 15/161,787

  • Full Citation: U.S. patent application Ser. No. 15/161,787, filed May 23, 2016, patented as U.S. Pat. No. 10,868,908.
  • Publication/Filing Date: May 23, 2016
  • Brief Description: Another continuation in the same patent family, also related to devices and methods for multipath communications, likely detailing the RCG, its interfaces, and its ability to combine communication paths.
  • Potential Anticipated Claims: Similar to the above, this would likely anticipate all claims (Claim 1, Claim 11, and any other dependent claims) of US11582343 under 35 U.S.C. § 102.

• U.S. patent application Ser. No. 14/512,414

  • Full Citation: U.S. patent application Ser. No. 14/512,414, filed Oct. 11, 2014, patented as U.S. Pat. No. 9,350,649.
  • Publication/Filing Date: October 11, 2014
  • Brief Description: As part of the same continuation chain, this patent application would also describe the core concepts of the RCG, its various communication interfaces (POTS, wireless), and its functionality for aggregating bandwidth.
  • Potential Anticipated Claims: It is expected to anticipate all claims (Claim 1, Claim 11, and any other dependent claims) of US11582343 under 35 U.S.C. § 102.

• U.S. patent application Ser. No. 13/531,294

  • Full Citation: U.S. patent application Ser. No. 13/531,294, filed Jun. 12, 2012, patented as U.S. Pat. No. 8,861,349.
  • Publication/Filing Date: June 12, 2012
  • Brief Description: This application details the multipath communication devices and methods.
  • Potential Anticipated Claims: Likely to anticipate all claims (Claim 1, Claim 11, and any other dependent claims) of US11582343 under 35 U.S.C. § 102.

• U.S. patent application Ser. No. 12/581,852

  • Full Citation: U.S. patent application Ser. No. 12/581,852, filed Oct. 19, 2009, patented as U.S. Pat. No. 8,228,801.
  • Publication/Filing Date: October 19, 2009
  • Brief Description: This patent application is part of the lineage of US11582343, focusing on similar multipath communication technologies.
  • Potential Anticipated Claims: It is expected to anticipate all claims (Claim 1, Claim 11, and any other dependent claims) of US11582343 under 35 U.S.C. § 102.

• U.S. patent application Ser. No. 10/686,375

  • Full Citation: U.S. patent application Ser. No. 10/686,375, filed Oct. 14, 2003, patented as U.S. Pat. No. 7,606,156.
  • Publication/Filing Date: October 14, 2003
  • Brief Description: This application is a key antecedent, further detailing the RCG and its core functionalities for providing voice and data services over POTS lines and wireless connections.
  • Potential Anticipated Claims: Likely to anticipate all claims (Claim 1, Claim 11, and any other dependent claims) of US11582343 under 35 U.S.C. § 102.

• U.S. Provisional Application Ser. No. 60/418,521

  • Full Citation: U.S. Provisional Application Ser. No. 60/418,521, filed Oct. 15, 2002.
  • Publication/Filing Date: October 15, 2002 (Priority Date for US11582343)
  • Brief Description: As the priority document, this provisional application would lay the foundational description for the RCG, its architecture, and its methods for multipath communication, including the use of POTS lines, modems, and wireless interfaces to aggregate bandwidth.
  • Potential Anticipated Claims: This provisional application serves as the ultimate priority document and is expected to anticipate all claims (Claim 1, Claim 11, and any other dependent claims) of US11582343 under 35 U.S.C. § 102, as the later patents are continuations of this foundational disclosure.

In addition to these direct continuations, a thorough prior art search would also involve examining the "References Cited by Examiner" and "References Cited by Applicant" sections typically found in a full patent document. These sections would list other patents and non-patent literature considered relevant during the prosecution of the patent. Without direct access to these sections of US11582343 at the USPTO, I cannot list them here.

Obviousness Analysis of US Patent 11582343 under 35 U.S.C. § 103

This analysis assesses the obviousness of US Patent 11582343 (the "'343 patent") based on the information provided within the patent text, particularly its discussion of prior art and background. The priority date of the '343 patent is October 15, 2002. Any prior art considered for an obviousness analysis must predate this date.

The '343 patent's independent claims (Claim 1 and Claim 11) describe a Residential Gateway (RCG) device and a method for multipath communication. The core functionalities involve utilizing a POTS line and modem for network access, a wireless interface (e.g., 802.11b/g) to either:

1. Establish a multilink data connection by combining multiple POTS lines from a plurality of RCG devices, or
2. Establish a direct connection to a broadband wireless access point.

The motivation for such combinations stems directly from the problems identified in the '343 patent's Background of Invention. These include the 56 Kbps bandwidth limitation of POTS lines, the high costs and limited deployment of DSL and cable modems, and the challenges faced by Competitive Local Exchange Companies (CLECs) in offering competitive broadband services without significant infrastructure investments.

Prior Art References (as described or implied by the patent itself, pre-October 15, 2002):

• POTS lines and modems: Standard technology for residential telephone service and dial-up internet access.
• VoIP services: Known, but suffered from Quality of Service (QoS) issues over the public internet and were primarily targeted at corporate markets due to complexity for average users.
• DSL and cable modems: Provided high-speed internet but required "expensive infrastructure enhancements" and were "difficult to deploy and too complicated for the average user."
• Wireless LANs (802.11b/g): Identified as a preferred embodiment for wireless communication, indicating its general availability and suitability for "wireless home networking" by the priority date.
• Multilink PPP (RFC 1990): Explicitly referenced in the patent for configuring a multilink bundle. RFC 1990 was published in 1996, well before the priority date.
• IP Routers/Processors: Generic components for managing network traffic and "house keeping and traffic routing tasks."
• Broadband wireless access points (Wi-Fi hotspots): The patent mentions RCGs communicating with "802.11a Neighborhood Access Point— 93 device (such as that used in WI-FI networks)" implying awareness of such infrastructure.

Obviousness Argument for Claim 1 and Claim 11:

A person having ordinary skill in the art (PHOSITA) in 2002 would have been motivated to combine the above-mentioned prior art elements to address the acknowledged deficiencies in residential broadband access and to enable CLECs to offer more competitive services.

Combination 1: Multilink Data Connection by Combining Multiple POTS Lines from Multiple RCGs via Wireless Interface

• Elements:

  • POTS line interface (40) and Modem (41): These were standard components for providing network access over a POTS line.
  • Multilink PPP (RFC 1990): This protocol was a known standard for aggregating bandwidth from multiple physical links (e.g., multiple dial-up modems) into a single logical connection to increase data transfer rates.
  • Wireless Interface (36, 802.11b/g): 802.11 wireless technology was known for local area networking and peer-to-peer communication within a residence or local area.
  • Processor (19): A standard component in networking devices for control, monitoring, and routing.

• Motivation for Combination: The patent explicitly states the desire to "transfer large files such as video files over the POTS lines to a residence" and acknowledges the "maximum of 56 Kbps due to the design of the digital Class 5 office linecards." Faced with this bandwidth limitation and the high costs of DSL/cable infrastructure, a PHOSITA would have been motivated to find ways to increase bandwidth using existing POTS lines. The established Multilink PPP protocol offered a clear technical solution for aggregating bandwidth from multiple lines.

  The challenge then becomes how to efficiently coordinate multiple POTS lines from potentially different residences for a single user or application. The widespread adoption of 802.11 wireless networks by 2002 provided an obvious solution for local device discovery and inter-device communication. A PHOSITA would readily conceive of using a wireless interface to:

  1. Monitor for other compatible devices (RCGs): This is analogous to how standard 802.11 devices discover other access points or peers.
  2. Coordinate the establishment of a multilink PPP session: Using the wireless link to negotiate and manage the joining of multiple POTS lines (each connected to a modem in an RCG) into a combined Multilink PPP bundle (per RFC 1990) would be a logical engineering choice to overcome the "last mile" bandwidth bottleneck without requiring new physical wiring to aggregate the lines. The patent itself describes this function, stating that the RCG "employs an 802.11 b/g wireless interface to configure a multilink PPP bundle— 87 (per RFC 1990) comprised of the POTS lines connected to up to 32 RCGs." This demonstrates that the individual components and the underlying protocol were known and their combination to solve a known problem would be obvious.

Combination 2: Direct Connection to a Broadband Wireless Access Point via Wireless Interface

• Elements:

  • RCG device with POTS line interface (40), Modem (41), and Wireless Interface (36): As described above, these are standard elements for a residential communication device.
  • Broadband wireless access points (e.g., 802.11a/b/g Wi-Fi hotspots): These were known to provide high-speed internet access in various locations and could be connected to high-bandwidth backbones.

• Motivation for Combination: The patent explicitly discusses providing "Broadband networking for home computers and appliances as well as wide area networking using... a direct wireless connection to a wireless access point." Furthermore, it notes that "an RCG can communicate directly with a local 802.11 Network Access Point— 93 that is connected to the PSTN or another carrier's network via some sort of high bandwidth backbone." Given the desire for alternative broadband service routes to relieve congestion on Class 5 offices and provide higher speeds than POTS, a PHOSITA would be motivated to enable a residential gateway device equipped with a wireless interface to connect directly to any available broadband wireless access points.

  The functionality of "monitoring a wireless interface... for a presence of... wireless access points" and, "responsive to detecting the presence... initiating... a direct connection to a broadband wireless access point via the wireless interface" describes standard operation for any 802.11-equipped device seeking network connectivity (e.g., a laptop scanning for Wi-Fi networks and connecting to one). Integrating this standard capability into a residential gateway device that already features a wireless interface for other purposes (like local home networking or RCG-to-RCG communication) would be an obvious design choice to offer flexible and high-speed internet access when such broadband wireless access points are available. The patent acknowledges that "an RCG has an alternative broadband service route in addition to the multilink option," indicating this was a recognized and desirable alternative or supplementary mode of operation.

Conclusion on Obviousness:

Claims 1 and 11 of US Patent 11582343 describe a device and method that combine known elements in a manner that would have been obvious to a PHOSITA in 2002. The patent's own background section clearly articulates the problems (POTS bandwidth limitations, high cost/limited reach of DSL/cable, need for CLEC competitiveness) and points to the existence of the core technological components (POTS modems, 802.11 wireless, Multilink PPP, and broadband wireless access points). The motivations for combining these elements—to provide higher bandwidth, more flexible, and cost-effective broadband solutions for residential users and CLECs—are clearly evident from the problems the patent seeks to solve. The combination represents a predictable use of known technologies to achieve a desired outcome, falling within the realm of obviousness.

To provide a comprehensive answer regarding patent term adjustments (PTA), patent term extensions (PTE), continuation/divisional applications, related family members, and the projected expiration date for US Patent 11582343, I will leverage the information from the Google Patents listing and the USPTO's public data resources.

The USPTO does not directly calculate patent expiration dates for the public but provides tools and guidance for estimation. Patent term is generally 20 years from the earliest filing date of the application, with potential adjustments.

Patent Term Adjustment (PTA)

Patent Term Adjustment (PTA) adds time to the patent term to compensate for certain delays caused by the USPTO during the prosecution of a utility or plant patent application. These delays include:

• "A delay": USPTO failing to issue an office action within 14 months, respond to an applicant's reply within 4 months, or issue a patent within 4 months of the issue fee payment.
• "B delay": The application being pending for more than three years.
• "C delay": Delays due to interference, secrecy orders, or successful appellate review.

Applicant-caused delays can reduce PTA.

The Google Patents page for US11582343 does not explicitly state the PTA awarded. To determine the exact PTA, one would typically need to examine the Issue Notification Letter or the patent's file wrapper on the USPTO Patent Center.

Patent Term Extension (PTE)

Patent Term Extension (PTE) is available for patents claiming certain human drug products, medical device products, animal drug products, and food or color additive products. It compensates for time lost while awaiting premarket government approval from a regulatory agency like the FDA.

Based on the title and abstract ("Devices and methods for multipath communications"), US Patent 11582343 does not appear to cover subject matter eligible for Patent Term Extension under 35 U.S.C. § 156, as it is not related to a product requiring regulatory approval like drugs or medical devices. Therefore, it is highly unlikely that US11582343 has received or is eligible for any PTE.

Continuation Applications, Divisional Applications, and Related Family Members

The patent text explicitly states: "This application is a continuation of U.S. patent application Ser. No. 17/120,549 filed on Dec. 14, 2020, soon to be patented as U.S. Pat. No. 11,418,641, which is a continuation of U.S. patent application Ser. No. 15/161,787 filed May 23, 2016, now patented as U.S. Pat. No. 10,868,908, which is a continuation of U.S. patent application Ser. No. 14/512,414 filed Oct. 11, 2014, now patented as U.S. Pat. No. 9,350,649, which is a continuation of U.S. patent application Ser. No. 13/531,294 filed Jun. 12, 2012, now patented as U.S. Pat. No. 8,861,349, which is a continuation of U.S. patent application Ser. No. 12/581,852 filed Oct. 19, 2009, now patented as U.S. Pat. No. 8,228,801, which is a continuation of U.S. patent application Ser. No. 10/686,375 filed Oct. 14, 2003, now patented as U.S. Pat. No. 7,606,156, which claims priority to U.S. Provisional Application Ser. No. 60/418,521, filed Oct. 15, 2002, all of which are incorporated by reference herein."

This chain of applications indicates that US11582343 is part of a large patent family, specifically a series of continuation applications. A continuation application is a follow-up application that shares the same specification as its parent but typically claims a different invention, and it must be filed while the parent application is still pending.

The related family members, based on the provided text, are:

• U.S. Pat. No. 11,418,641 (from Ser. No. 17/120,549)
• U.S. Pat. No. 10,868,908 (from Ser. No. 15/161,787)
• U.S. Pat. No. 9,350,649 (from Ser. No. 14/512,414)
• U.S. Pat. No. 8,861,349 (from Ser. No. 13/531,294)
• U.S. Pat. No. 8,228,801 (from Ser. No. 12/581,852)
• U.S. Pat. No. 7,606,156 (from Ser. No. 10/686,375)
• U.S. Provisional Application Ser. No. 60/418,521

The patent text does not mention any divisional applications. Divisional applications result from an original application that claimed more than one invention, where the applicant chose to pursue separate inventions in separate applications.

It is also worth noting that as of March 16, 2026, application number 90/016,048, identified as a "Re-Examination" application for US11582343, was filed and its status is "Reexam Preprocessing Completed -- Released to Assigned GAU" as of March 20, 2026. This indicates that the patent is currently undergoing re-examination by the USPTO.

Projected Expiration Date

A U.S. utility patent filed on or after June 8, 1995, expires 20 years from its earliest effective filing date, which includes the filing date of any earlier application to which it claims priority under 35 U.S.C. §§ 120, 121, or 365(c).

US11582343 claims priority to U.S. Provisional Application Ser. No. 60/418,521, filed on October 15, 2002. This is the earliest effective filing date for the patent family.

Therefore, the base patent term of 20 years for US11582343 would extend from October 15, 2002.

Base expiration date: October 15, 2002 + 20 years = October 15, 2022.

However, the Google Patents entry for US11582343 shows a "Publication date" of 2023-02-14 and an "Anticipated expiration" of 2023-10-14. It also lists the "Legal status" as "Expired - Lifetime". This immediately contradicts the 20-year term from the priority date. The contradiction might be due to a terminal disclaimer or the patent's effective filing date being tied to a different application within the family that has a later filing date, or a complex PTA calculation.

Given the information that the "Anticipated expiration" was October 14, 2023, and the current legal status is "Expired - Lifetime", it strongly suggests that the patent has already expired. The USPTO's statement that it "does not calculate expiration dates for patents" means that the "Anticipated expiration" on Google Patents is an estimate.

Without accessing the full patent file wrapper to check for any terminal disclaimers (which can shorten a patent term) or precise PTA calculations, it's difficult to pinpoint the exact reason for the 2023-10-14 expiration date. However, the legal status explicitly states "Expired - Lifetime", indicating the patent is no longer in force.

In summary:

• Patent Term Adjustment (PTA): Not explicitly stated on Google Patents. Requires access to USPTO file wrapper for precise details.
• Patent Term Extension (PTE): Highly unlikely, as the patent does not cover eligible subject matter (e.g., pharmaceuticals).
• Continuation Applications: US11582343 is explicitly stated as a continuation in a long chain of applications, ultimately tracing back to U.S. Provisional Application Ser. No. 60/418,521, filed October 15, 2002.
• Divisional Applications: No divisional applications are mentioned in the provided text.
• Related Family Members: U.S. Pat. No. 11,418,641, U.S. Pat. No. 10,868,908, U.S. Pat. No. 9,350,649, U.S. Pat. No. 8,861,349, U.S. Pat. No. 8,228,801, U.S. Pat. No. 7,606,156, and U.S. Provisional Application Ser. No. 60/418,521.
• Projected Expiration Date: The "Anticipated expiration" listed on Google Patents was October 14, 2023, and the current legal status is "Expired - Lifetime". This indicates the patent has already expired.

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

---

Defensive Disclosure for US Patent 11582343

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

Claim 1 Derivatives: Residential Gateway (RCG) Device

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

---

1. Material & Component Substitution

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

• Enabling Description: This derivative replaces the legacy POTS modem interface with a multi-standard xDSL (e.g., VDSL2, G.fast) transceiver module or a dedicated Fiber-Optic Network Termination (ONT) module, providing higher-speed wired access to the dwelling. The 802.11b/g wireless interface is upgraded to a high-frequency millimeter-wave (mmWave) wireless module (e.g., 802.11ad/ay or 5G NR FR2) capable of multi-gigabit speeds for local RCG-to-RCG aggregation or direct backhaul to a mmWave access point. The processor features a dedicated network function virtualization (NFV) accelerator for dynamic instantiation of network slices and real-time QoS management across diverse physical layers. Power over Ethernet (PoE) or Power over Fiber (PoF) is integrated for simplified deployment.

  graph TD
      A[External Fiber/Copper Drop] --> B(Fiber/xDSL ONT/Transceiver)
      B --> C{RCG Processor (NFV-accelerated)}
      C --> D(mmWave Wireless Module)
      D --> E[Other RCGs / mmWave AP]
      C --> F(Internal LAN Switch / Wi-Fi 6E)
      F --> G[Local Devices]
      B --(Optional)--> H[POTS Line Interface (Lifeline Only)]
  

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

• Enabling Description: This RCG incorporates Gallium Nitride (GaN) power amplifiers and low-noise amplifiers in its RF front-end for improved efficiency and higher transmit power on the wireless interface (e.g., Wi-Fi 6/7). Instead of, or in addition to, traditional RF wireless, the device integrates a Light Fidelity (Li-Fi) module for secure, high-speed indoor communication. The Li-Fi interface utilizes high-bandwidth LED lighting fixtures for data transmission and photodiodes for reception. The user interface features a flexible Organic Light Emitting Diode (OLED) display that can conform to surfaces or be rolled for portability, enhancing user interaction while reducing power consumption. The modem for the POTS line uses an advanced DSP-based softmodem architecture for improved performance under line impairments.

  graph TD
      A[POTS Line Interface] --> B(DSP Softmodem)
      B --> C{RCG Processor}
      C --> D(GaN RF Front-End + Wi-Fi 7 Module)
      C --> E(Li-Fi Transceiver Module)
      E --> F[LED Light Fixture / Photodiode]
      C --> G(Flexible OLED Display)
      D --> H[Wireless Devices (RF)]
  

---

2. Operational Parameter Expansion

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

• Enabling Description: This RCG is designed for remote, off-grid deployments in agricultural or environmental monitoring. It operates at extremely low power (milliwatts), powered by integrated solar panels and long-duration solid-state batteries. The POTS line is replaced by a low-bandwidth, low-power, sub-1GHz wireless transceiver (e.g., LoRaWAN or Sigfox) for terrestrial long-range data collection. The primary long-haul backhaul is achieved via a low-Earth orbit (LEO) satellite modem (e.g., Starlink, Iridium SBD) for global connectivity in areas without terrestrial infrastructure. The processor, an ultra-low-power microcontroller, aggregates sensor data (temperature, humidity, soil pH) and opportunistically transmits over either the sub-1GHz mesh or satellite link, prioritizing emergency alerts.

  graph TD
      A[Environmental Sensors] --> B(Ultra-Low-Power Microcontroller)
      B --> C(LoRaWAN/Sigfox Transceiver)
      B --> D(LEO Satellite Modem)
      C --> E[LoRaWAN Gateway / Other RCG Nodes]
      D --> F[Satellite Constellation]
      G[Solar Panel] --> H(Battery Management)
      H --> B
  

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

• Enabling Description: This RCG operates as a node in a city-wide mesh network, designed for industrial-scale deployment, handling massive data flows from smart city sensors and devices. Communication occurs at terahertz (THz) frequencies for ultra-high-bandwidth, short-range point-to-point links between RCGs on lampposts or buildings. For critical control plane communication and secure data aggregation, it integrates a quantum key distribution (QKD) module, generating and distributing encryption keys using quantum properties to ensure unconditional security against eavesdropping. Wired backhaul to the core network is provided via redundant 100Gbps optical fiber connections.

  graph TD
      A[Smart City Sensors / Devices] --> B(Industrial RCG Processor)
      B --> C(Terahertz (THz) Transceiver)
      B --> D(Quantum Key Distribution Module)
      D --> E[Quantum Network Node]
      C --> F[Other RCG Nodes (THz)]
      B --> G(100Gbps Optical Fiber Interface)
      G --> H[City Core Network]
  

---

3. Cross-Domain Application

Derivative 3.1: Medical Wearable RCG for Continuous Patient Monitoring

• Enabling Description: This RCG is integrated into a wearable medical device (e.g., a smart patch or wristband). It aggregates physiological data from multiple on-body sensors (ECG, glucose, blood pressure, oxygen saturation). The device uses a low-power Bluetooth Low Energy (BLE) connection for local data collection. For remote transmission, it intelligently selects between an integrated cellular modem (e.g., LTE-M, NB-IoT) for continuous background updates and a local Wi-Fi interface (802.11ax) for high-bandwidth data bursts when a trusted Wi-Fi network (e.g., at home or hospital) is available, prioritizing critical alerts over the most reliable path. A secure, encrypted tunnel is maintained to a cloud-based health monitoring platform.

  graph TD
      A[On-Body Sensors] --> B(Wearable RCG Microcontroller)
      B --> C(Bluetooth Low Energy (BLE))
      C --> A
      B --> D(Integrated Cellular Modem)
      B --> E(Wi-Fi 6 (802.11ax) Module)
      D --> F[Cellular Network]
      E --> G[Local Wi-Fi AP]
      F & G --> H[Cloud Health Platform]
  

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

• Enabling Description: This RCG functions as a mobile base station for precision agriculture, deployed on autonomous ground vehicles or drones. It manages a swarm of agricultural sensors (soil moisture, nutrient levels, crop health imaging) and smaller drones via a robust, frequency-hopping mesh wireless network (e.g., custom 900MHz ISM band protocol or LoRa mesh). For backhauling aggregated data, the RCG dynamically selects between a private 5G mmWave network (if available on the farm) or a satellite uplink (e.g., VSAT terminal) for large data uploads like hyperspectral imagery. The system optimizes route planning for data collection and resource deployment.

  graph TD
      A[Agricultural Sensors / Mini-Drones] --> B(AgTech RCG Processor)
      B --> C(Frequency-Hopping Mesh Wireless (900MHz))
      C --> A
      B --> D(Private 5G mmWave Module)
      B --> E(VSAT Satellite Uplink)
      D --> F[Private 5G Network Infrastructure]
      E --> G[Geostationary Satellite]
      F & G --> H[Cloud Analytics / Farm Management System]
  

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

• Enabling Description: This RCG is designed for robust operation on maritime assets (buoys, cargo containers, autonomous vessels). It collects telemetry from onboard sensors (GPS, weather, water quality, motion). For local data relay and short-range asset tracking, it employs a robust sub-gigahertz wireless link (e.g., 433MHz or 868MHz ISM band with spread spectrum). For primary communication, it features an always-on Inmarsat or Iridium satellite modem. When within range of shore-based infrastructure, it automatically switches to a high-speed Long-Range Wi-Fi (e.g., 802.11ah HaLow) or cellular (e.g., 5G CBRS) link for efficient data offloading, prioritizing safety and navigation alerts.

  graph TD
      A[Onboard Sensors (GPS, Weather)] --> B(Maritime RCG Processor)
      B --> C(Sub-GHz Wireless Link)
      C --> D[Other Maritime Assets / Local Sensors]
      B --> E(Inmarsat/Iridium Satellite Modem)
      B --> F(Long-Range Wi-Fi / 5G CBRS Module)
      E --> G[Satellite Network]
      F --> H[Shore-based Network / Cellular Tower]
      G & H --> I[Fleet Management / Monitoring Center]
  

---

4. Integration with Emerging Tech

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

• Enabling Description: This RCG integrates an embedded AI/ML inference engine (e.g., a TinyML-capable neural network accelerator) that continuously monitors network conditions (latency, jitter, packet loss, bandwidth utilization) across all available links (POTS, local wireless mesh, broadband wireless AP, cellular dongle). The AI model predicts future network congestion and dynamically reconfigures the multilink bundle (e.g., using MPTCP at the transport layer, or proprietary link aggregation protocols at lower layers) by adding or removing links, adjusting traffic priorities, and selecting optimal routing paths to maintain user-defined QoS for applications like 4K video streaming or real-time gaming. It can also preemptively establish new links if predicted congestion requires it.

  graph TD
      A[Network Monitoring (Latency, Jitter)] --> B(AI/ML Inference Engine)
      C[Application QoS Requirements] --> B
      D[Available Links (POTS, Wi-Fi, 5G)] --> B
      B --> E{Dynamic Link Aggregation Module}
      E --> F[POTS Modem]
      E --> G[Wireless Module]
      E --> H[Cellular Module]
      I[Traffic Manager] --> E
      B --> I
  

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

• Enabling Description: This RCG acts as an intelligent IoT gateway, integrating a secure element (e.g., Trusted Platform Module) and a blockchain client. It collects data from a diverse array of local IoT sensors (Zigbee, Z-Wave, Thread, Matter) and performs edge computing tasks like local analytics and anomaly detection. Data destined for the cloud is bundled into cryptographically signed transactions, verified against a private or public blockchain ledger to ensure data integrity and provenance before transmission over aggregated POTS lines or broadband wireless. This provides immutable records of sensor readings for applications such as smart home insurance or verified environmental compliance. Multi-signature schemes can be enforced for critical device control commands.

  graph TD
      A[IoT Sensors (Zigbee, Z-Wave)] --> B(IoT RCG Processor)
      B --> C(Edge Compute / Analytics)
      B --> D(Secure Element / Blockchain Client)
      D --> E[Blockchain Ledger]
      B --> F[Multilink POTS / Broadband Wireless]
      F --> G[Cloud Services]
      D --> G
  

---

5. The "Inverse" or Failure Mode

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

• Enabling Description: This RCG is designed for robust operation during power outages or network failures. It features a tiered power management system including a supercapacitor bank for short-term backup and an auxiliary low-power long-duration battery. Upon detection of primary power loss, it enters a "graded degradation" mode:

  1. Stage 1 (Partial Power Loss): Disables high-bandwidth data aggregation, maintaining only essential voice (VoIP over POTS) and critical alert data (e.g., security system, medical alert). Wireless interface operates in a low-power beaconing mode to preserve battery and allow peer discovery.
  2. Stage 2 (Extended Power Loss): Wireless interface is fully disabled. RCG reverts to a "lifeline-only" mode, bypassing internal circuitry for direct POTS voice communication, as per the original patent, but also activating a small, integrated e-ink display to provide emergency instructions or battery status.
  3. Emergency Protocol: During severe network outages, the RCG activates a pre-configured emergency communications protocol (e.g., sending short bursts of critical data via a low-bandwidth satellite link or amateur radio packet network if equipped) to a designated emergency contact or service.

  stateDiagram-v2
      [*] --> Normal_Operation
      Normal_Operation --> Power_Loss : Primary Power Lost
      Power_Loss --> Graded_Degradation_Stage1 : Detect Power Loss
      Graded_Degradation_Stage1 --> Graded_Degradation_Stage2 : Battery Threshold Low
      Graded_Degradation_Stage2 --> Lifeline_Only : Battery Critical
      Lifeline_Only --> Emergency_Comm_Protocol : Local Network Unavailable
      Emergency_Comm_Protocol --> Lifeline_Only : Emergency Sent
      Lifeline_Only --> Normal_Operation : Power Restored
      Graded_Degradation_Stage1 --> Normal_Operation : Power Restored
      Graded_Degradation_Stage2 --> Normal_Operation : Power Restored
  
      state Normal_Operation {
          Full_Bandwidth_Aggregation
          All_Services_Active
      }
      state Graded_Degradation_Stage1 {
          VoIP_over_POTS_Only
          Critical_Alerts_Data
          Low_Power_Wireless_Beacon
      }
      state Graded_Degradation_Stage2 {
          Wireless_Disabled
          POTS_Voice_Only
          eInk_Display_Active
      }
      state Lifeline_Only {
          Direct_POTS_Bypass
      }
      state Emergency_Comm_Protocol {
          Low_Bandwidth_Satellite/Amateur_Radio
      }
  

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

• Enabling Description: This RCG offers a "Guest Mode" for temporary users or devices, implementing strict bandwidth caps and limited functionality. In this mode, the RCG prevents the guest from initiating or participating in multilink PPP bundles, thus protecting the primary user's aggregated bandwidth. Guest wireless access is provided through a separate VLAN with an enforced Quality of Service (QoS) profile that guarantees minimal impact on primary user services. Data from guest devices is anonymized or sandboxed locally, without being aggregated or contributing to the primary user's data usage statistics. The wireless interface can create an isolated "guest Wi-Fi" SSID with configurable access duration and data limits.

  graph TD
      A[RCG Processor] --> B{Access Control Module}
      B --> C[Primary User Network]
      C --> D(Full Bandwidth / Multilink)
      B --> E[Guest Network (VLAN)]
      E --> F(Bandwidth Capped / Isolated)
      G[Wireless Interface] --> H[Primary SSID]
      G --> I[Guest SSID]
      H --> C
      I --> E
      A --> J(Local Storage for Guest Data Sandboxing)
  

---

Claim 11 Derivatives: Method for Multipath Communication

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

---

1. Material & Component Substitution (Method perspective)

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

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

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

---

2. Operational Parameter Expansion (Method perspective)

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

• Enabling Description: This method is employed by an RCG acting as a mobile command post in an emergency response scenario. The RCG's processor continuously monitors and ranks available network links: high-bandwidth (e.g., 5G mmWave cellular, Starlink satellite), medium-bandwidth (e.g., CBRS private LTE, bonded DSL over available copper), and low-bandwidth (e.g., LoRaWAN, amateur radio data). Depending on the severity of the emergency and the type of data (e.g., real-time video, critical health metrics, SMS alerts), the RCG dynamically allocates traffic to the best available path or initiates a multilink aggregation session across a combination of heterogeneous links. This includes opportunistic "scavenging" of unused bandwidth from neighboring RCGs (or similar mobile nodes) via a secure, ad-hoc wireless mesh network.

  flowchart TD
      A[Emergency RCG Activated] --> B{Monitor Available Links}
      B --> C{Rank Links by Bandwidth, Latency, Reliability}
      C --> D{Evaluate Data Priority & Type}
      D --> E{Decision: Single Link or Multilink Aggregation?}
      E -->|Single Link| F[Transmit over Best Link]
      E -->|Multilink Aggregation| G[Identify Candidate Links (Heterogeneous)]
      G --> H{Initiate Aggregation Protocol (e.g., MPTCP, custom L2 bundling)}
      H --> I[Transmit Data over Bundled Links]
      I --> J[Cloud/Command Center]
      subgraph Link Monitoring
          K[5G mmWave]
          L[Starlink Satellite]
          M[CBRS Private LTE]
          N[Bonded DSL]
          O[LoRaWAN]
          P[Amateur Radio Data]
          Q[Neighboring RCGs (Ad-Hoc Mesh)]
      end
      B --> K & L & M & N & O & P & Q
  

---

3. Cross-Domain Application (Method perspective)

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

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

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

  sequenceDiagram
      participant RCG as Industrial RCG
      participant S as Industrial Sensors
      participant C1 as Cellular Network 1
      participant C2 as Cellular Network 2
      participant L as Licensed Radio Link
      participant V as VSAT Satellite
      participant H as Central Control Hub
  
      RCG->>S: Collect Encrypted Data
      RCG->>RCG: Aggregate & Prioritize Data
  
      RCG->>L: Monitor Licensed Radio Link
      alt If Licensed Radio available & data is control
          RCG->>L: Transmit Control Commands
          L->>H: Deliver Control Commands
      end
  
      RCG->>C1: Monitor Cellular 1
      RCG->>C2: Monitor Cellular 2
      alt If Bulk Data & multiple Cellular available
          RCG->>RCG: Initiate Multilink VPN over C1+C2
          RCG->>C1: Transmit Data (Link 1 of Bundle)
          RCG->>C2: Transmit Data (Link 2 of Bundle)
          C1->>H: Deliver Data
          C2->>H: Deliver Data
      end
  
      RCG->>V: Monitor VSAT Link
      alt If Terrestrial Links Fail
          RCG->>V: Transmit Critical Data (Fallback)
          V->>H: Deliver Critical Data
      end
  

---

4. Integration with Emerging Tech (Method perspective)

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

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

  sequenceDiagram
      participant IR as Initiating RCG
      participant RR1 as Remote RCG 1
      participant RR2 as Remote RCG 2
      participant BC as Blockchain Network
      participant DS as Data Source (URL)
  
      IR->>IR: Detect need for more bandwidth
      IR->>BC: Broadcast Bandwidth Request (Smart Contract Trigger)
      RR1->>RR1: Check local bandwidth (AI-driven)
      RR1->>BC: Offer Bandwidth (Smart Contract Proposal)
      RR2->>RR2: Check local bandwidth (AI-driven)
      RR2->>BC: Offer Bandwidth (Smart Contract Proposal)
  
      IR->>IR: Evaluate Offers (from BC)
      IR->>BC: Accept RR1's Offer (Smart Contract Execution - Funds Locked)
  
      IR->>RR1: Send Multilink Init (Wireless)
      RR1->>DS: Add link to Multilink PPP
      DS-->>RR1: Data Flow Started
      RR1->>IR: Relay Data (Wireless)
  
      IR->>BC: Attest to Data Delivery (Smart Contract Trigger)
      BC->>RR1: Release Payment (from locked funds)
      note right of BC: Transaction Recorded
  

---

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

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

• Enabling Description: This method is for an RCG operating in an adversarial environment where overt communication paths are monitored or susceptible to jamming. When the RCG detects compromised primary links (e.g., through active probing, high interference, or pre-programmed threat models), it initiates a "covert channel" mode. Instead of directly aggregating bandwidth, it utilizes multiple low-bandwidth, difficult-to-detect communication methods, potentially including:

  1. Steganographic data embedding: Hiding data in seemingly innocuous regular traffic (e.g., embedding critical alerts into DNS queries or NTP traffic patterns over a POTS modem, or modulating data into ambient Wi-Fi noise).
  2. Frequency hopping / spread spectrum on unlicensed bands: Using a custom, rapidly changing frequency hopping pattern on an ISM band wireless link to evade detection and jamming.
  3. Encrypted one-time pad burst transmissions: Storing encrypted data and sending it in very short, high-power bursts over an irregular schedule, potentially leveraging multiple remote RCGs as relays, with each relay adding a layer of encryption and using different, hard-to-trace paths.
     The goal is to maintain minimal, but highly resilient, communication rather than high bandwidth.

  stateDiagram-v2
      [*] --> Normal_Communication
      Normal_Communication --> Adversarial_Mode : Detect Link Compromise / Jamming
      Adversarial_Mode --> Steganographic_Channel : High Surveillance
      Adversarial_Mode --> FHSS_Covert_Link : Active Jamming
      Adversarial_Mode --> Burst_Transmission_Relay : Severe Network Outage
  
      state Normal_Communication {
          Multilink_PPP
          Broadband_AP_Direct
      }
      state Adversarial_Mode {
          Data_Prioritization
          Encryption_Emphasis
      }
      state Steganographic_Channel {
          Hiding_Data_in_DNS/NTP_traffic
          Modulating_data_into_ambient_Wi-Fi_noise
      }
      state FHSS_Covert_Link {
          Custom_Frequency_Hopping_Pattern
          Spread_Spectrum_Transmission
      }
      state Burst_Transmission_Relay {
          One_Time_Pad_Encryption
          Short_High_Power_Bursts
          Multi_Hop_RCG_Relay
      }
  

---

Combination Prior Art Scenarios with Open-Source Standards

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

1. RCG with OpenWrt for Multilink PPP Orchestration:

   • Description: An RCG device (as described in Claim 1) is implemented using commodity hardware running the open-source OpenWrt firmware. The core logic for "monitoring the wireless interface for other compatible RCGs" and "establishing a multilink data connection" or "connecting directly to a broadband wireless access point" is realized through custom scripts and daemon processes integrated into OpenWrt's networking stack. Specifically, the multilink PPP functionality leverages Linux's native PPP daemon capabilities, extended with wireless-aware discovery (e.g., using iw commands to scan 802.11 networks) and dynamic link management algorithms (e.g., adjusting pppd parameters) that could be exposed via OpenWrt's LuCI web interface or ubus API. This demonstrates that the control and routing aspects could be implemented on readily available, modifiable open-source platforms.
   • Relevance: This combination makes the software implementation details for managing such a system obvious to a PHOSITA familiar with open-source router operating systems.

2. Multi-Path TCP (MPTCP) for Enhanced Data Aggregation:

   • Description: The method of Claim 11, which involves "initiating a multilink PPP session by combining the POTS lines of multiple RCGs," is extended to utilize the open-source Multipath TCP (MPTCP) protocol (standardized in RFC 6824, though development and research existed prior). Instead of bundling links solely at Layer 2 (PPP), the RCGs' operating system kernel (e.g., Linux, which has MPTCP support) is configured to establish MPTCP sessions. This allows a single TCP connection to leverage multiple underlying network paths simultaneously, effectively aggregating bandwidth from different POTS lines (each connected to a different RCG and thus appearing as a distinct network interface) and/or a direct broadband wireless connection. The RCG's processor (Main CPU 19) would manage the MPTCP subflows based on real-time path characteristics.
   • Relevance: MPTCP is a well-known open standard for aggregating heterogeneous paths. Applying it to the RCG's described multipath communication problem provides a clear, non-novel extension for transport-layer bandwidth aggregation and resilience.

3. RCG with FreeRADIUS for Centralized Authentication and Bandwidth Policy:

   • Description: The RCG (Claim 1) and its method of establishing network connections (Claim 11) relies on a "username/password verification server." An open-source FreeRADIUS server is deployed by the service provider to handle authentication, authorization, and accounting (AAA) for both the POTS modem connections and the wireless access point connections (e.g., WPA2 Enterprise authentication for 802.11). FreeRADIUS can be configured with dynamic policies, allowing the service provider to centralize control over which RCGs can participate in multilink bundles, the allowed aggregate bandwidth, and to authenticate individual POTS line usage. This integrates the RCG's connection establishment with a widely adopted open-source authentication framework.
   • Relevance: The use of open-source AAA servers like FreeRADIUS for network access control is a standard practice, making its integration with the RCG's connection management an obvious design choice for network operators.