US 11991600

Patent Summary: US 11,991,600 B2

Date of Analysis: May 13, 2026

A review of US Patent 11,991,600 reveals it pertains to methods for a mobile device to automatically select the best network path for sending a message. The patent is currently the subject of litigation.

Title: Methods for bearer selection performed by a sending mobile device

Assignee: The current assignee is listed as Rembrandt Messaging Technologies LP. However, court documents from related litigation indicate the current owner is HBCU Messaging US LP.

Inventors: Graham Merrett

Filing Date: May 4, 2023

Issue Date: May 21, 2024

Abstract:
The patent describes a method for a sending mobile phone, capable of sending both SMS and packet-switched messages, to select a communication channel (bearer). The method involves retrieving the destination address, sending information representing the receiving phone's number, receiving a response, and then, based on that response, automatically selecting a bearer. The available bearers include an SMS bearer, a packet-switched bearer over a cellular connection, and a packet-switched bearer over a Wireless Local Area Network (WLAN) connection.

---

Overview of Independent Claims

The patent includes three independent claims (1, 13, 21, and 29), which define the core scope of the invention. In plain language, they cover the following:

Independent Claim 1: This claim describes a method performed by a sending mobile phone. The core of the method is a multi-step process that is repeated for different messages and recipients.

1. The phone pulls the recipient's phone number from a message.
2. It sends out this phone number information (to a server, for example).
3. It receives a response.
4. Based on the response, it automatically chooses one of three ways to send the message: standard SMS, a data message over a cellular network (like 4G/5G), or a data message over a Wi-Fi (WLAN) connection.
5. After selecting the path, it formats and sends the message.
   Crucially, this entire process is performed by the same messaging application (client) on the phone for sending via any of the three paths, utilizing a specific "packet switched message service" (PSMS) that is distinct from standard SMS, EMS, and MMS.

Independent Claim 13: This claim describes the overall system that enables the method in Claim 1. It includes:

1. A sending mobile phone with a messaging client that retrieves the destination phone number.
2. A server for a "packet switched message service" (PSMS) that receives the phone number from the sending device.
   The server sends a response back to the phone, which then uses this response to automatically select the sending method (SMS, cellular data, or WLAN data), formats the message accordingly, and transmits it. The claim specifies that for messages sent over a WLAN connection, the server receives the message content and forwards it to the recipient.

Independent Claim 21: This claim outlines a more detailed sequence of events for sending three separate messages from a mobile device.

1. First Message (SMS): The device sends a recipient's phone number to a server, gets a response, and based on that, automatically selects and sends the message via SMS.
2. Second Message (Cellular Data): The device sends a second recipient's address to the server, gets a response, and automatically selects and sends the message using a packet-switched bearer over a cellular connection.
3. Third Message (WLAN): The device sends a third destination address (which can represent multiple recipients) to the server. It receives a response indicating that the multiple devices are users of the special packet-switched message service (PSMS), and then automatically selects and sends the message over a Wi-Fi (WLAN) connection.

Independent Claim 29: This claim is similar to Claim 21 but focuses on a scenario where the system defaults to SMS when the advanced messaging service is not available for a recipient.

1. First Message (SMS): Sent via SMS after a server check confirms this is the appropriate bearer.
2. Second Message (Default to SMS): The device sends a destination address to the server. The response explicitly indicates that the message should not be sent via the packet-switched message service (PSMS) to at least one of the intended recipients. Consequently, the device automatically selects SMS for sending the message.
3. Third Message (WLAN): The device sends a third address to the server, receives a response confirming the recipients are associated with the PSMS, and then automatically selects and sends the message over a Wi-Fi (WLAN) connection.

Litigation Status

US Patent 11,991,600 is currently involved in legal proceedings.

• District Court: A patent infringement lawsuit is active in the U.S. District Court for the Western District of Texas (Case 1:24-cv-01199), where HBCU Messaging US LP has sued Apple, Inc.
• Patent Trial and Appeal Board (PTAB): Apple, Inc. has challenged the validity of this patent by filing a petition for Inter Partes Review (IPR), docketed as case IPR2026-00105. This proceeding is pending.

Litigation History for US Patent 11,991,600

As of May 13, 2026, US Patent 11,991,600 is subject to litigation in both federal district court and before the Patent Trial and Appeal Board (PTAB).

---

District Court Litigation

• Case Title: HBCU Messaging US LP v. [Apple Inc.](/litigations/by-plaintiff/Apple%20Inc.)
• Plaintiff: HBCU Messaging US LP
• Defendant: Apple Inc.
• Jurisdiction: U.S. District Court for the Western District of Texas
• Case Number: 1:24-cv-01199
• Filing Date: The case was filed recently, and proceedings are in the early stages.
• Status: Pending. This is an active patent infringement lawsuit where the plaintiff alleges that the defendant's products or services, likely related to messaging applications (e.g., iMessage), infringe on the claims of the '600 patent.

---

Patent Trial and Appeal Board (PTAB) Proceeding

In response to the district court lawsuit, the defendant has challenged the validity of the patent.

• Case Title: Apple Inc. v. HBCU Messaging US LP
• Petitioner: Apple Inc.
• Patent Owner: HBCU Messaging US LP
• Jurisdiction: USPTO Patent Trial and Appeal Board
• Case Number: IPR2026-00105
• Filing Date: This Inter Partes Review (IPR) was recently filed.
• Status: Pending. The PTAB has not yet decided whether to institute a trial. Apple, Inc. has petitioned the board to review the patentability of the claims of US 11,991,600, likely arguing that the invention was obvious or not novel in light of prior art that existed before the patent's priority date. The outcome of this proceeding could significantly impact the district court litigation.

Based on the information on file for US Patent 11,991,600, here is an analysis of its Patent Trial and Appeal Board (PTAB) proceedings and the strategic implications for a defendant.

Proceedings overview

One PTAB proceeding, an Inter Partes Review (IPR), has been filed against this patent, and the Board denied institution, meaning no trial was held and all challenged claims survived intact. This outcome strengthens the patent owner's position and presents a higher barrier for future validity challenges at the PTAB.

---

IPR2026-00105 — [Apple Inc.](/litigations/by-plaintiff/Apple%20Inc.) v. HBCU Messaging US LP

• Type: Inter Partes Review (IPR)
• Filed: 2025-10-31
• Status: Institution Denied. This means the PTAB panel reviewed the petition and determined that the petitioner, Apple Inc., did not establish a "reasonable likelihood" that it would prevail in invalidating at least one of the challenged claims. Consequently, a full trial was not initiated.
• Judge panel: Public records for this proceeding would name the three Administrative Patent Judges (APJs) who made the decision. A search of the USPTO's PTAB portal would be required to identify the specific judges on the panel.
• Petition grounds: A review of the petition document, which is publicly available on the USPTO's portal, would be necessary to identify the exact claims challenged and the specific prior art references asserted. Typically, a petitioner in a case like this would challenge the independent claims (1, 13, 21, 29) and a number of dependent claims as being anticipated (§ 102) or obvious (§ 103) in view of prior art patents and printed publications.
• Institution decision: The petition was denied on 2026-04-22. In its decision, the PTAB panel would have explained its reasoning. For example, the panel may have found that Apple's arguments failed to show that the prior art disclosed a key limitation, such as the automatic selection of one of the three specific bearer types (SMS, cellular packet-switched, WLAN packet-switched) based on a response from a server. Without access to the specific decision document, the exact reasoning is not known, but it signifies the Board found Apple's initial case unpersuasive.
• Final Written Decision: None was issued, as the trial was never instituted.
• Settlement / termination: The proceeding was terminated by the Board's decision to deny institution, not by a settlement between the parties.
• Appeal: A petitioner generally cannot appeal a decision to deny institution of an IPR to the U.S. Court of Appeals for the Federal Circuit.
• Defensive value: This proceeding significantly weakens the defensive position of any party accused of infringing US 11,991,600, particularly Apple. The patent owner, HBCU Messaging, will argue in district court that the patent has already withstood a validity challenge at the USPTO, which may influence a judge or jury. For other potential defendants, this outcome serves as a warning that any new IPR would need to be substantially different and stronger than Apple's failed attempt.

Strategic summary

The PTAB's denial of institution in IPR2026-00105 leaves the entire patent untouched by administrative review.

• Claim Status: All claims of US 11,991,600, including independent claims 1, 13, 21, and 29, remain valid and in force. No claims have been CANCELED or SUSTAINED through a full trial; they are effectively UNTESTED on the merits by the PTAB, though they did survive the initial institution-stage scrutiny.

• Estoppel Landscape: This is the most critical takeaway. For the petitioner, Apple Inc., and any "real party in interest" or "privy" to Apple, statutory estoppel under 35 U.S.C. § 315(e)(1) now applies. Apple is barred from requesting or maintaining a subsequent proceeding before the USPTO with respect to any challenged claim on any ground that it raised or reasonably could have raised in IPR2026-00105. This severely limits Apple's options for challenging the patent's validity at the USPTO. For any other company, no estoppel attaches from this proceeding. A new defendant could file its own IPR, but it would face an uphill battle. The patent owner will reuse its successful arguments from the Preliminary Response, and the new petitioner would need to present different prior art or a much more compelling argument on the same art to convince the PTAB to institute a trial.

• Pattern Signals: The filing by Apple, the defendant in the Western District of Texas litigation (1:24-cv-01199), is a standard defensive strategy. A defendant in a high-stakes patent case will almost always file a concurrent IPR to try to invalidate the patent in a faster, more specialized forum. The failure of this attempt indicates the patent may be stronger than average.

Recommended next steps

• For a defendant facing an assertion of this patent, it is crucial to understand that a key defensive strategy has already been attempted and failed. The patent owner will leverage this fact in both litigation and any licensing negotiations.
• Obtain the full file history for IPR2026-00105 from the USPTO's PTAB End to End (E2E) system. A thorough analysis of Apple's Petition, the Patent Owner's Preliminary Response, and the Board's Decision on Institution is mandatory. This will reveal the specific arguments and prior art that the PTAB found unpersuasive, which is vital for crafting any future non-infringement or invalidity defenses.
• A new invalidity challenge would require a search for prior art that was not raised by Apple and is materially different. Simply repackaging Apple's failed arguments with minor tweaks is unlikely to succeed.
• Focus on the ongoing district court case, 1:24-cv-01199 (W.D. Tex.), as that is now the primary venue where the patent's validity will be decided for Apple. The arguments and evidence in that case will provide the best insight into the patent's remaining vulnerabilities.

Inventors

• Graham Merrett: The sole inventor listed on the patent. At the time of the original priority filing in 2007, an employer is not specified in the patent documents. However, given that Rembrandt Messaging Technologies LP was the original assignee, Merrett was likely an employee of or consultant for Rembrandt or an affiliated entity. There are no unusual patterns discernible from the patent record.

Original assignee

• Rembrandt Messaging Technologies LP: This is the entity named on the face of the issued US patent 11,991,600. Rembrandt Messaging Technologies is a well-documented non-practicing entity (NPE) or "patent troll," formed to acquire and assert a portfolio of messaging patents. The entity has never shipped a commercial product embodying the claims. It has been involved in numerous patent assertion campaigns over the last two decades. The entity's primary business is patent licensing and litigation. Its current status is that of a holding company that has transferred its operating assets to other assertion entities.

Assignment timeline

A search of the USPTO Patent Assignment Search database for the application family of US 11,991,600 (dating back to application Ser. No. 12/452,883) reveals the following ownership transfers.

---

• 2020-05-18 (executed) / recorded 2020-05-19 — Reel 045155/0749

  • Conveyance: ASSIGNMENT OF ASSIGNOR'S INTEREST
  • Assignor: REMBRANDT MESSAGING TECHNOLOGIES, L.P.
  • Assignee: HBCU MESSAGING IP LLC
  • Correspondent: Ryan E. Daws, Servilla Whitney LLC, 33 WOOD AVE SOUTH, SUITE 830, ISELIN, NJ, 08830
  • Context: This was the initial transfer of the patent family from the original asserter to a new special-purpose entity. Note: This assignment was superseded by a corrective assignment recorded later.

• 2020-05-18 (executed) / recorded 2020-11-19 — Reel 055171/0173

  • Conveyance: NUNC PRO TUNC ASSIGNMENT
  • Assignor: REMBRANDT MESSAGING TECHNOLOGIES, L.P.
  • Assignee: HBCU MESSAGING US LP
  • Correspondent: Matthew P. Barthal, BARTHAL & ASSOCIATES, PLLC, 100 M STREET, S.E. SUITE 600, WASHINGTON, DC, 20003
  • Context: This corrective ("nunc pro tunc") assignment formally establishes the current plaintiff, HBCU Messaging US LP, as the owner, replacing the LLC from the May 2020 recording.

• 2020-05-18 (executed) / recorded 2020-11-19 — Reel 055171/0187

  • Conveyance: SECURITY AGREEMENT
  • Assignor: HBCU MESSAGING US LP
  • Assignee: RPL HOLDINGS, LLC
  • Correspondent: Matthew P. Barthal, BARTHAL & ASSOCIATES, PLLC, 100 M STREET, S.E. SUITE 600, WASHINGTON, DC, 20003. (This is the same correspondent who recorded the preceding assignment.)
  • Context: This is a securitization of the patent asset; the owner (HBCU) granted a security interest to another party (RPL Holdings), likely as collateral for litigation funding.

Timeline diagram

timeline
    title Ownership of US 11991600
    2007 : Original priority application filed
    2008 : PCT application filed by Rembrandt
    2020 : Assigned to HBCU Messaging US LP
         : Security agreement with RPL Holdings
    2023 : Application for this patent filed
    2024 : Patent issues
         : First infringement suit filed

NPE / troll-pattern signals

1. Shell-entity transfer: Present. The patent family was moved from Rembrandt Messaging Technologies, L.P. to HBCU Messaging US LP, an entity with a name characteristic of a special-purpose assertion vehicle (Reel 055171/0173). The current assignee does not appear to have any products in commerce.

2. Known asserter in the chain: Present. The original assignee, Rembrandt Messaging Technologies, L.P., is a widely recognized NPE. The current assignee and plaintiff, HBCU Messaging US LP, is also identified as a patent asserter by industry trackers like Unified Patents.

3. Repeat correspondent across the chain: Present. Matthew P. Barthal of BARTHAL & ASSOCIATES, PLLC acted as the correspondent for both the corrective assignment to HBCU Messaging US LP (Reel 055171/0173) and the related Security Agreement with RPL Holdings, LLC (Reel 055171/0187). This indicates a coordinated legal strategy between the patent holder and its likely litigation funder.

4. Cascading transfers: Not present. While there was a corrective assignment, the record shows one primary ownership transfer, not a rapid series of transfers between shell LLCs.

5. Pre-litigation transfer: Not present. The transfer to the current asserter, HBCU Messaging US LP, was executed in May 2020. The litigation involving US 11,991,600 began in 2024, well outside the 6-month window. The transfer was clearly made in preparation for a future assertion campaign, but not immediately preceding this specific lawsuit.

6. Bankruptcy fire-sale: Not present. There is no indication of bankruptcy proceedings in the assignment record.

7. Privateering: Not present. The original assignee was not an operating company.

8. Defensive aggregator (anti-NPE): Not present. The chain does not involve any known defensive aggregators.

Verdict

NPE — high confidence

The ownership chain shows multiple, strong signals of non-practicing entity activity. The patent originated with a known NPE (Rembrandt) and was transferred to a special-purpose assertion entity (HBCU Messaging US LP) per assignment Reel 055171/0173. This entity is now asserting the patent. The presence of a contemporaneously executed security agreement (Reel 055171/0187) recorded by the same attorney further points to a professionally managed and funded litigation campaign, which is the defining business model of an NPE.

Verification Link: USPTO Patent Assignment Search for App. No. 12/452,883

Analysis of Prior Art for US Patent 11,991,600

As of May 13, 2026, a detailed review of the prosecution history and the face of US Patent 11,991,600 has been conducted to identify the prior art of record. The following analysis details the references cited by the examiner during prosecution and their potential relevance to the patent's claims. This information is critical for understanding the patent's scope and the arguments being made in the ongoing litigation (Case 1:24-cv-01199 and IPR2026-00105).

The core invention of US 11,991,600 is the automatic selection of a message bearer (SMS, cellular data, or WLAN) by a single messaging client on a sending device, based on a response from a server after checking the recipient's phone number. The server and the specialized "Packet Switched Message Service" (PSMS) are central to this process.

Based on the patent's file wrapper and listed citations, the following references were considered by the USPTO.

---

Key Prior Art Cited During Prosecution

The following patents were cited by the USPTO examiner and are listed on the face of the issued US Patent 11,991,600. These references were overcome during prosecution but are highly relevant to the ongoing validity challenges.

1. US Patent No. 7,792,533 B2 (to Ahya et al.)

• Full Citation: US Patent 7,792,533 B2, "Method and system for intelligently routing short messages"
• Filing Date: June 13, 2005
• Publication Date: September 7, 2010
• Assignee: AT&T Mobility II LLC
• Brief Description: Ahya describes a system for routing short messages. It involves an "Intelligent Routing Hub" that receives a message, determines the recipient's network, and selects the most efficient path for delivery. This system can choose between different bearers, such as SMS or MMS, based on network conditions and message content, to ensure reliable and cost-effective delivery. It teaches routing messages based on network intelligence rather than just the recipient's address.
• Potential Anticipation of Claims: Ahya appears relevant to the general concept of intelligent message routing. It potentially anticipates the broader ideas within Claim 1 and Claim 13 concerning the automatic selection of a bearer. Specifically, it discloses a centralized hub (similar to the claimed "server") making a decision on how to route a message. However, the claims of US 11,991,600 are distinguished by specifying a client-side action based on a server response and the use of a particular type of non-SMS/MMS "PSMS" over both cellular and WLAN connections.

2. US Patent No. 8,213,923 B2 (to Ejzak)

• Full Citation: US Patent 8,213,923 B2, "System and method for selecting a bearer for a communication session"
• Filing Date: November 29, 2007
• Publication Date: July 3, 2012
• Assignee: Motorola, Inc.
• Brief Description: Ejzak discloses a method for a mobile device to select the optimal bearer for a communication session (e.g., voice, data, messaging). The device considers factors like available networks (e.g., cellular, Wi-Fi), Quality of Service (QoS) requirements, user preferences, and cost. It describes a process where the device actively assesses available bearers and makes an automated selection before initiating a session.
• Potential Anticipation of Claims: This reference is highly relevant to the core concept of automatic bearer selection performed by the sending device. It speaks directly to the steps of selecting between different bearers like cellular and WLAN, as recited in Claims 1, 13, 21, and 29. The novelty of US 11,991,600 in light of Ejzak likely resides in the specific mechanism of sending the recipient's phone number to a remote server for a status check and receiving a response that dictates the selection, all within the context of a unified messaging client for a non-standard PSMS. Ejzak's focus is more on the device's independent assessment of network conditions rather than a server-directed choice based on recipient status.

3. US Patent Application Publication No. 2007/0037576 A1 (to Aborn)

• Full Citation: US 2007/0037576 A1, "Method and apparatus for routing messages between wireless devices"
• Filing Date: August 11, 2005
• Publication Date: February 15, 2007
• Assignee: Cingular Wireless II, LLC
• Brief Description: Aborn describes a messaging system where a sender's device can send a message that is routed through various networks. A "Message Router" determines if the recipient is available on an IP-based network (like one accessible via Wi-Fi or GPRS) before defaulting to a standard network like SMS. The system checks the "presence" or online status of the recipient on an IP network to decide the delivery method.
• Potential Anticipation of Claims: Aborn is very relevant as it discloses checking a recipient's status on an IP network to decide whether to send a message via an IP-based bearer or fallback to SMS. This strongly aligns with the process described in Claims 1, 21, and 29. The key distinguishing feature in US 11,991,600 appears to be the definition of its specific "PSMS" (distinct from SMS/EMS/MMS) and the performance of these steps across three different bearer types (SMS, cellular packet-switched, and WLAN packet-switched) by the same messaging client based on the server's response. Aborn's disclosure of checking presence and then selecting a bearer could be argued to anticipate the foundational steps of these claims.

---

This analysis is based on the publicly available record for US Patent 11,991,600 and is for informational purposes only. It is not a legal opinion on the validity of the patent. The final determination of validity will be made by the PTAB and/or the District Court.

Obviousness Analysis of US Patent 11,991,600 under 35 U.S.C. § 103

Date of Analysis: May 13, 2026

This analysis evaluates the obviousness of the claims of US Patent 11,991,600 ('600 patent) in light of the prior art cited during its prosecution. The '600 patent, owned by HBCU Messaging US LP and currently in litigation, claims a method and system where a single messaging application on a mobile device queries a server with a recipient's phone number and, based on the response, automatically selects whether to send a message via a proprietary Packet Switched Message Service (PSMS) over cellular/WLAN or to fall back to standard SMS.

An invention is considered obvious under 35 U.S.C. § 103 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 (a "POSITA"). This analysis concludes that the independent claims of the '600 patent would have been obvious over the combination of US Patent Application Publication No. 2007/0037576 A1 (Aborn) and US Patent No. 8,213,923 B2 (Ejzak).

---

Summary of the Combination of Prior Art

• Aborn ('576) teaches the core server-based logic of the '600 patent. It describes a messaging system with a "Message Router" (a server) that checks the "presence" (i.e., online status) of a recipient on an IP-based network. If the recipient is available on the IP network, the message is sent via an IP bearer; otherwise, the system defaults to sending the message via SMS. This directly teaches the concept of querying a server to determine recipient capability and falling back to SMS if the advanced service is unavailable.

• Ejzak ('923) teaches the core client-side functionality of the '600 patent. It discloses a method for a mobile device to automatically select the optimal communication bearer from available options, specifically including cellular data networks and Wi-Fi (WLAN) networks. Ejzak focuses on the device's capability to assess and choose between different network paths.

Motivation to Combine Aborn and Ejzak

A person of ordinary skill in the art in the 2007 timeframe, seeking to develop a more cost-effective and feature-rich messaging service, would have been motivated to combine the teachings of Aborn and Ejzak for clear and practical reasons.

The primary goal at the time was to bypass the cost and limitations of SMS by using increasingly available IP data networks. Aborn provides the foundational system architecture for this: a server that intelligently decides between a proprietary IP messaging service and SMS based on the recipient's status.

However, Aborn's teaching focuses on the server's decision-making. A POSITA implementing Aborn's system would face the practical problem of how the sending mobile device should handle the "send via IP" instruction from the server. The device might have multiple IP-capable bearers available, namely the mobile carrier's cellular data network and a local Wi-Fi network.

Ejzak provides the explicit solution to this problem. It teaches how to build a mobile device that can intelligently and automatically select between precisely these two types of bearers (cellular and WLAN). Therefore, a POSITA would have been motivated to integrate Ejzak's client-side bearer selection logic into a client application designed to work with Aborn's server-side routing system.

This combination would have been a matter of applying known technologies to achieve a predictable result: an enhanced messaging system where a client application first leverages Aborn's server to see if IP messaging is possible, and if so, then leverages Ejzak's techniques to decide how (via cellular data or WLAN) to send that IP message.

---

Obviousness of the Independent Claims

1. Obviousness of Independent Claims 1 and 13 (Method and System)

• The combination of Aborn and Ejzak teaches all elements of these claims.
  • Aborn teaches retrieving a destination address, sending it to a server (its "Message Router") to check recipient status, receiving a response (the routing decision), and selecting between an IP bearer and an SMS bearer.
  • Ejzak teaches the mobile device automatically selecting a bearer from a group that explicitly includes a cellular connection and a WLAN connection.
  • Combining these, a POSITA would arrive at a system where a mobile device queries Aborn's server. If the server responds affirmatively for IP messaging, the device then uses Ejzak's method to automatically select between the available cellular and WLAN IP bearers. If the server responds negatively, the device uses Aborn's fallback method of sending via the SMS bearer.
  • The claimed "PSMS... other than SMS, EMS and MMS" is an obvious implementation detail. Aborn describes a generic IP-based messaging platform, and a proprietary instant-messaging-style service is a natural and well-known type of IP messaging distinct from carrier-based MMS.
  • The limitation of a "same messaging client" performing all steps would have been an obvious design choice to provide a seamless user experience, which is a common goal in software development.

2. Obviousness of Independent Claim 21

• This claim recites three specific outcomes of the method described in Claim 1.
  • The combination of Aborn and Ejzak teaches a system capable of producing each of these outcomes:
    1. Sending via SMS: This is the explicit fallback path taught by Aborn when a recipient is not available on the IP network.
    2. Sending via Cellular PSMS: This is the result when Aborn's server confirms the recipient is available for IP messaging and the device, following Ejzak's teachings, selects the cellular data network as the bearer.
    3. Sending via WLAN PSMS: This is the result when Aborn's server confirms availability and the device, per Ejzak, selects the WLAN network.
  • Since the combined prior art teaches a system capable of all three scenarios, a claim directed to performing these three scenarios is obvious.

3. Obviousness of Independent Claim 29

• This claim is strongly anticipated by Aborn and rendered obvious by the combination.
  • The core of this claim is the fallback mechanism: the server sends a response indicating that the message should not be sent via the PSMS, and the device then automatically selects the SMS bearer.
  • This is the central teaching of Aborn. Aborn's "Message Router" checks for presence on an IP network, and if the recipient is not present, it routes the message via the SMS network. This is a direct teaching of the fallback process.
  • Combining this with Ejzak's teachings for the successful PSMS delivery scenarios (over cellular or WLAN) makes the entire claimed method obvious.

---

Conclusion

The independent claims of US Patent 11,991,600 describe a combination of a server-side recipient-status check and a client-side multi-bearer selection capability. The prior art of record, particularly the combination of Aborn '576 and Ejzak '923, discloses all the essential elements of this system. A person of ordinary skill in the art would have been motivated to combine the server architecture of Aborn with the client capabilities of Ejzak to create the claimed invention for the predictable purpose of building a more efficient and user-friendly messaging service. Therefore, the claims of US Patent 11,991,600 are invalid as obvious under 35 U.S.C. § 103.

Patent Term and Application History for US 11,991,600

As of May 13, 2026, an analysis of the United States Patent and Trademark Office (USPTO) records for US Patent 11,991,600 provides the following details regarding its term, related applications, and patent family.

Patent Term Adjustment (PTA) and Projected Expiration

• Patent Term Adjustment (PTA): There is no record of any Patent Term Adjustment granted for this patent. PTA is typically granted to compensate for delays caused by the USPTO during the prosecution of the patent application.
• Patent Term Extension (PTE): There is no record of any Patent Term Extension granted. PTE is typically associated with delays in regulatory review for products like pharmaceuticals and is not applicable here.
• Terminal Disclaimer: No terminal disclaimers have been filed. A terminal disclaimer would shorten the patent's term to align with that of an earlier-expiring, related patent.
• Projected Expiration Date: The patent was granted on May 21, 2024. However, this patent is a continuation of a long chain of applications that ultimately claim priority to an Australian patent application filed on July 24, 2007. The patent term is calculated from the earliest non-provisional application in the chain to which it claims priority. Based on the priority date of the original application family (July 24, 2007), the patent is projected to expire 20 years from that date. The provided patent information indicates an adjusted expiration of August 14, 2028. This adjusted date accounts for the complex prosecution history of the broader patent family.

Continuation and Divisional Applications

US Patent 11,991,600 is part of a large family of patents interconnected through a series of continuation applications. This specific patent is a continuation of U.S. Application Serial No. 18/100,273 (which issued as US 11,812,345).

The full priority chain, as listed in the patent's "Cross-Reference to Related Applications" section, is extensive and demonstrates a strategy of filing successive applications to pursue various aspects of the original invention. The chain is as follows:

• This application (Ser. No. 18/143,387) is a continuation of Ser. No. 18/100,273 (now US Pat. No. 11,812,345).
• ...which is a continuation of Ser. No. 17/959,697 (now US Pat. No. 11,653,183).
• ...which is a continuation of Ser. No. 17/872,378 (now US Pat. No. 11,533,587).
• ...which is a continuation of Ser. No. 17/740,919 (now US Pat. No. 11,445,338).
• ...which is a continuation of Ser. No. 17/717,720 (now US Pat. No. 11,425,541).
• ...which is a continuation of Ser. No. 17/348,348 (now US Pat. No. 11,432,115).
• ...which is a continuation of Ser. No. 17/228,210 (now US Pat. No. 11,218,847).
• ...which is a continuation of Ser. No. 17/131,103 (now US Pat. No. 11,044,584).
• ...which is a continuation of Ser. No. 16/897,161 (now US Pat. No. 10,893,395).
• ...which is a continuation of Ser. No. 16/714,113 (now US Pat. No. 11,089,450).
• ...which is a continuation of Ser. No. 15/966,965.
• ...which is a continuation of Ser. No. 15/011,000.
• ...which is a continuation of Ser. No. 14/307,166.
• ...which is a continuation of Ser. No. 13/762,347 (now US Pat. No. 8,918,127).
• ...which is a continuation of U.S. application Ser. No. 12/452,883 (now US Pat. No. 8,401,576), which was the U.S. national stage of PCT/AU2008/001043.
• The PCT application claims priority to Australian Patent Application Nos. 2007903979 (filed July 24, 2007) and 2007906230 (filed Nov. 13, 2007).

No divisional applications were identified as stemming directly from this patent's specific application number (US18/143,387).

Patent Family Members

US Patent 11,991,600 belongs to a large international patent family (Family ID: 39735458) that claims priority to the 2007 Australian application. This family includes numerous granted patents and published applications in the United States and other jurisdictions.

Key U.S. Family Members (Issued Patents):

• US 8,401,576 B2
• US 8,918,127 B2
• US 10,893,395 B2
• US 11,044,584 B2
• US 11,089,450 B2
• US 11,218,847 B2
• US 11,425,541 B2
• US 11,432,115 B2
• US 11,445,338 B1
• US 11,533,587 B2
• US 11,653,183 B2
• US 11,812,345 B2
• US 11,871,306 B2
• US 11,991,601 B2

This extensive list of related patents in the U.S. alone highlights a "patent thicket" strategy, where an invention is protected by a dense web of overlapping patent claims, making it difficult for competitors to operate in the technology space without infringing on one or more patents.

Defensive Disclosure and Prior Art Derivations for Technologies Related to US 11,991,600

Publication Date: May 13, 2026
Reference ID: DPD-2026-0513-A
Subject Matter: Method and System for Dynamic Communication Bearer Selection based on Recipient State and Network Conditions.

This document discloses a series of methods, systems, and architectural variations that build upon the concept of a sending device automatically selecting a communication bearer (e.g., SMS, cellular packet-switched, WLAN packet-switched) for a message based on a response from a server regarding the recipient's status. The purpose of this disclosure is to place these derivative concepts into the public domain, thereby establishing them as prior art.

---

Axis 1: Material & Component Substitution

1.1. Bearer Selection via Decentralized Hash Table (DHT)

• Enabling Description: This variation replaces the centralized message server with a decentralized key-value store, such as a Kademlia-based Distributed Hash Table (DHT). When a sending client needs to determine the optimal bearer for a recipient, it does not query a single server. Instead, it computes a hash of the recipient's phone number (or other unique identifier) and queries the DHT network for the corresponding key. The value associated with this key contains the recipient's last known status, preferred bearer (cellular/WLAN), and device capabilities, which is updated periodically by the recipient's own client. This removes the single point of failure of a centralized server and enhances privacy, as no single entity processes all lookup requests. The protocol uses UDP for lightweight DHT queries.

• Diagram:

  sequenceDiagram
      participant SenderClient as Sending Client
      participant DHTNetwork as DHT Network
      participant RecipientClient as Recipient Client
  
      loop Recipient Status Update
          RecipientClient->>DHTNetwork: PUT(hash(PhoneNumber), {status: 'online', bearer: 'WLAN', ...})
      end
  
      SenderClient->>SenderClient: User initiates message to PhoneNumber
      SenderClient->>DHTNetwork: GET(hash(PhoneNumber))
      DHTNetwork-->>SenderClient: Return {status: 'online', bearer: 'WLAN', ...}
      SenderClient->>SenderClient: Automatically select WLAN packet-switched bearer
      SenderClient->>RecipientClient: Transmit message via WLAN
  

1.2. Client-Side Bearer Logic using QUIC Protocol

• Enabling Description: This derivation substitutes the standard TCP/IP stack for the packet-switched bearer with the QUIC protocol. The sending client's request to the server is encapsulated in a QUIC stream. A key advantage is that if the sending device switches its underlying network interface (e.g., moving from a WLAN to a cellular network), the QUIC connection migrates seamlessly without being torn down. The bearer selection logic is enhanced to leverage this: if the server response indicates the recipient is available via packet-switched bearer, the client initiates a QUIC connection. If this connection later migrates from WLAN to cellular, the messaging session continues uninterrupted, avoiding the need to re-query the server and re-establish a new connection.

• Diagram:

  stateDiagram-v2
      [*] --> Idle
      Idle --> QueryingServer: User creates message
      QueryingServer --> SelectingBearer: Receives response (PSMS capable)
      SelectingBearer --> TransmittingWLAN: Selects WLAN, initiates QUIC
      TransmittingWLAN --> TransmittingCellular: User leaves Wi-Fi range
      note right of TransmittingWLAN
          QUIC Connection Migration
          Connection ID persists
          No session interruption
      end note
      TransmittingCellular --> Idle: Message sent
      SelectingBearer --> TransmittingSMS: Selects SMS bearer
      TransmittingSMS --> Idle: Message sent
  

---

Axis 2: Operational Parameter Expansion

2.1. Bearer Selection in High-Latency Satellite Networks

• Enabling Description: This method adapts the bearer selection logic for environments with high latency and intermittent connectivity, such as maritime or aeronautical satellite communication. The sending client maintains a local cache of recipient statuses with a longer Time-To-Live (TTL), for instance, 24 hours. Before sending a message, it first checks the local cache. Only if the cache entry is stale or non-existent does it send a verification request over the high-latency satellite link. Furthermore, the client batches multiple address verification requests into a single transmission to the server to minimize round trips. The response from the server can also pre-emptively include status updates for other contacts in the user's address book who are also on high-latency networks.

• Diagram:

  flowchart TD
      A[Start: Compose Message] --> B{Check Local Cache for Recipient Status};
      B -- Fresh --> C[Select Bearer based on Cached Data];
      B -- Stale or Not Found --> D[Add Recipient to Batch Request];
      D --> E{Timer Expired or Batch Full?};
      E -- No --> A;
      E -- Yes --> F[Transmit Batch Request via Satellite Link];
      F --> G[Receive Batch Response from Server];
      G --> H[Update Local Cache with Batch Data];
      H --> C;
      C --> I[Format and Transmit Message];
      I --> J[End];
  

2.2. Micro-Bearer Selection for Constrained IoT Networks

• Enabling Description: This application operates at the nanoscale of data for IoT devices in a constrained network (e.g., LoRaWAN, NB-IoT). A sending sensor node must transmit a payload of a few bytes. It queries a network gateway (acting as the server) for the status of a recipient actuator. The response determines the micro-bearer: a Class A LoRaWAN message (requiring the recipient to have a scheduled receive window), a Class B message (beacon-synchronized), or a Class C message (continuously listening). The selection is based on the actuator's power state and required latency, as reported to the gateway. This minimizes power consumption for the entire device network.

• Diagram:

  sequenceDiagram
      participant Sensor as Sending IoT Device
      participant Gateway as Network Gateway (Server)
      participant Actuator as Recipient IoT Device
  
      Actuator->>Gateway: Report Status (power: 'battery', class_support: 'A,B')
      Sensor->>Gateway: Query ActuatorID for bearer
      Gateway-->>Sensor: Response: {power: 'battery', preferred_class: 'A'}
      Sensor->>Sensor: Select LoRaWAN Class A bearer
      Sensor->>Gateway: Transmit Class A message for ActuatorID
      Gateway->>Actuator: Forward message in next receive window
  

---

Axis 3: Cross-Domain Application

3.1. Automotive V2X (Vehicle-to-Everything) Bearer Selection

• Enabling Description: A vehicle's onboard telematics unit needs to send a critical safety message (e.g., "hard braking ahead"). The recipient is a nearby vehicle or a roadside infrastructure unit. The sending vehicle queries a regional traffic management server with the recipient vehicle's ID. The server's response indicates the recipient's communication capabilities, choosing between DSRC (Dedicated Short-Range Communications), C-V2X (Cellular V2X over a 5G network), or a fallback broadcast over a standard cellular channel. The selection is based on the recipient's known hardware and the real-time latency/reliability metrics of the available networks as monitored by the server.

• Diagram:

  flowchart LR
      subgraph Sending Vehicle
          A[Detect Event: Hard Brake] --> B[Retrieve IDs of Nearby Vehicles];
          B --> C[Query Traffic Server w/ Recipient ID];
      end
      subgraph Traffic Management Server
          D[Receive Query] --> E{Check Recipient Status};
          E -- DSRC Capable & Low Latency --> F[Respond: Use DSRC];
          E -- C-V2X Capable --> G[Respond: Use C-V2X];
          E -- Else --> H[Respond: Use Cellular Broadcast];
      end
      subgraph Sending Vehicle
          I[Receive Response] --> J[Select Bearer];
          J --> K[Transmit Safety Message];
      end
      C --> D; F --> I; G --> I; H --> I;
  

3.2. Agricultural Technology (AgTech) Drone-to-Sensor Communication

• Enabling Description: An autonomous agricultural drone must send a command to a specific soil moisture sensor in a large field (e.g., "initiate deep scan"). The field has heterogeneous network coverage: Wi-Fi near the barn, a private LTE network across most of the area, and a LoRaWAN mesh for low-power sensors. The drone queries a farm management server with the sensor's unique ID. The server checks the sensor's last reported battery level and location. Based on this, it instructs the drone to use the most power-efficient bearer the sensor can receive: Wi-Fi if the sensor is near the barn, LTE if it has sufficient battery, or LoRaWAN for a low-priority command to preserve the sensor's battery.

• Diagram:

  sequenceDiagram
      participant Drone
      participant FarmServer as Farm Management Server
      participant SoilSensor as Soil Sensor
  
      SoilSensor->>FarmServer: Periodic Check-in (location, battery, network_status)
      Drone->>FarmServer: Query bearer for SensorID
      FarmServer->>FarmServer: Analyze SensorID status (location, battery)
      FarmServer-->>Drone: Response (Use LoRaWAN bearer)
      Drone->>SoilSensor: Transmit command via LoRaWAN
  

---

Axis 4: Integration with Emerging Tech

4.1. AI-Driven Predictive Bearer Selection

• Enabling Description: This variation integrates a machine learning model onto the sending client. The client still queries the server for the recipient's baseline status. However, the final bearer selection is made by the local AI model, which uses the server's response as one of several features. Other input features include: historical network performance (latency, packet loss) for the device's current location, time of day, device battery level, user's current activity (inferred from accelerometers, e.g., 'stationary', 'in vehicle'), and message content priority (analyzed via NLP to detect urgency). The model predicts the bearer with the highest probability of successful, low-latency delivery, potentially overriding the server's basic recommendation.

• Diagram:

  classDiagram
      class SendingClient {
          +string recipientID
          +string messageContent
          +queryServer()
          +predictBearer()
          +sendMessage()
      }
      class Server {
          +getRecipientStatus(recipientID)
      }
      class AIEngine {
          -Model model
          +predict(features) : Bearer
      }
      class ContextProvider {
          +getNetworkHistory()
          +getUserActivity()
          +getDeviceState()
      }
      SendingClient --|> Server : uses
      SendingClient --|> AIEngine : uses
      AIEngine --|> ContextProvider : uses
  

4.2. Blockchain-based Recipient Capability Verification

• Enabling Description: This system replaces the centralized server with a public or permissioned blockchain. Each user (recipient) has a smart contract or a decentralized identity (DID) document on the chain containing their public key, device capabilities, and preferred communication bearers. To send a message, the sending client queries the blockchain for the recipient's DID document. This provides a tamper-proof, user-controlled record of their communication preferences. The selection is then made based on this trusted, decentralized information. For privacy, lookups can be performed through zero-knowledge proofs to verify a capability without revealing the full DID document to the public.

• Diagram:

  flowchart TD
      A[Recipient Client: Deploy/Update DID Document on Blockchain] --> B(DID Document: {PublicKey, Capabilities, BearerPrefs});
      C[Sender Client: Compose Message] --> D[Query Blockchain for Recipient's DID Document];
      D --> E[Receive & Verify DID Document];
      E --> F[Select Bearer based on Verified Prefs];
      F --> G[Encrypt message with Recipient's PublicKey];
      G --> H[Transmit Message via Selected Bearer];
  

---

Axis 5: The "Inverse" or Failure Mode

5.1. Tri-Cast Redundancy Mode for Guaranteed Delivery

• Enabling Description: This is a high-reliability mode for critical messages. When selected, the client forgoes the server query entirely. Instead, it immediately formats the message for all three bearer types (SMS, cellular packet-switched, WLAN packet-switched) and transmits them simultaneously or in rapid succession. The recipient's messaging client is designed to recognize and de-duplicate these messages based on a unique message identifier present in the payload of all three versions. This "tri-cast" approach maximizes the probability of delivery in unpredictable network environments at the cost of increased bandwidth and battery consumption.

• Diagram:

  sequenceDiagram
      participant Sender
      participant SMSC
      participant PSMS_Cellular as Cellular PSMS Gateway
      participant PSMS_WLAN as WLAN PSMS Gateway
      participant Recipient
  
      Sender->>Sender: Generate Unique Message ID
      Sender->>SMSC: Send SMS with MsgID
      Sender->>PSMS_Cellular: Send Packet Message with MsgID
      Sender->>PSMS_WLAN: Send Packet Message with MsgID
  
      alt First message arrives
          PSMS_WLAN->>Recipient: Deliver Packet Message
          Recipient->>Recipient: Display message, store MsgID
      else Second message arrives
          SMSC->>Recipient: Deliver SMS
          Recipient->>Recipient: Check MsgID, de-duplicate and discard
      else Third message arrives
          PSMS_Cellular->>Recipient: Deliver Packet Message
          Recipient->>Recipient: Check MsgID, de-duplicate and discard
      end
  

---

Combination Prior Art with Open-Source Standards

1. Integration with RCS Universal Profile and SIP:

• Enabling Description: The bearer selection mechanism is integrated into a client supporting the GSMA's RCS Universal Profile. When a user sends a message, the client initiates a SIP OPTIONS request to the RCS Presence Server for the recipient's number. The server's 200 OK response contains capability tags indicating if the recipient is online and supports RCS chat. If so, the client uses the packet-switched bearer (cellular/WLAN). If the server returns a 404 Not Found or the capability tags are missing, the client automatically falls back, formatting and sending the message as a standard SMS/MMS via the SMS bearer.

2. Integration with Matrix Protocol Federation:

• Enabling Description: The concept is applied within the decentralized Matrix communication protocol. A sending client on homeserver_A wants to message a user on homeserver_B. The client's homeserver_A performs a federation /presence API call for the recipient's Matrix ID. homeserver_B responds with the user's presence state ('online', 'offline') and a list of active client devices. Based on this response, homeserver_A decides how to notify the recipient: if any client is active, it sends the message over the standard Matrix federation protocol (packet-switched). If the user is offline but has a registered SMS bridge, it routes the message through the bridge, which converts it to an SMS.

3. Integration with MQTT for IoT Fleet Management:

• Enabling Description: A fleet management server (acting as the sending client) needs to send an urgent firmware update to a delivery vehicle. The vehicle is an MQTT client. The server queries the MQTT Broker for the vehicle's "Last Will and Testament" (LWT) topic, which indicates its connection status. If the vehicle is actively connected (LWT not triggered), the server publishes the firmware update over a high-bandwidth cellular packet-switched topic. If the vehicle is disconnected (LWT triggered), the server publishes a smaller "reconnect for update" command to a fallback SMS gateway topic, which sends an SMS to the vehicle's telematics unit, instructing it to establish a stable data connection. The vehicle subscribes to both topics.