Here is a concise summary of U.S. Patent 11,653,183.

Title: Undelivered message threshold

Assignee: Rembrandt Messaging Technologies LP

Inventors: Graham Merrett

Filing Date: October 4, 2022

Issue Date: May 16, 2023

Abstract:
A system may comprise a sending mobile phone that transmits SMS messages via a cellular network and packet switched messages via a PSMS and at least one server that supports the PSMS and maintains status information. The sending mobile phone may send a second message via a WLAN and via the PSMS, to a receiving mobile phone on a condition that an undelivered message threshold corresponding to the receiving mobile phone has not been exceeded.

Overview of Independent Claims:

This patent has four independent claims (1, 7, 14, and 20), each describing a system or method for managing message delivery on a mobile phone by selecting between different networks based on the recipient's status.

Claim 1: Describes a system with a sending mobile phone, a server, and receiving mobile phones. The sending phone checks with the server to see if a recipient is a subscriber to a Packet Switched Message Service (PSMS). If the recipient is not a subscriber, the message is sent via a standard SMS. If the recipient is a subscriber and has not exceeded a maximum number of undelivered messages, the message is sent via a wireless local area network (WLAN) and the PSMS. A key feature is that messages sent via either SMS or the PSMS are displayed within the same messaging client on the sending phone.

Claim 7: Outlines a method performed by a sending mobile phone. The phone first checks the recipient's phone number with a server to determine if they are a PSMS subscriber. If not, it sends the message as an SMS. If the recipient is a subscriber and has not surpassed a threshold of undelivered messages, the phone sends the message over a WLAN through the PSMS. The method ensures a consistent user experience by displaying both types of messages in the same application.

Claim 14: Details a system where a sending mobile phone communicates with a server to manage message delivery to a single receiving mobile phone that is a PSMS subscriber. Initially, a message is sent via a WLAN and the PSMS. However, if a message to that recipient is undelivered, the server sends a different response to the sending phone, prompting it to then send subsequent messages to that recipient via an SMS bearer instead. This allows the system to adapt to delivery failures.

Claim 20: Focuses on a method performed by a sending mobile phone for a recipient who is a PSMS subscriber. After confirming the recipient's status, the phone sends a message via a WLAN and the PSMS. If that message goes undelivered, the sending phone will then send a subsequent message to that same recipient using an SMS bearer. This claim highlights the dynamic switching of delivery methods based on the success of prior messages.

Litigation:
As of April 26, 2026, a search of the CAFC dockets for 2026 did not reveal any appeals related to US Patent 11,653,183. However, the assignee, Rembrandt Messaging Technologies LP, has a history of patent litigation.

As of April 26, 2026, there is one known litigation involving U.S. Patent No. 11,653,183.

District Court Litigation

Case Title: HBCU Messaging US LP v. [Apple Inc.](/litigations/by-plaintiff/Apple%20Inc.) and Green Dot Corporation

• Plaintiff: HBCU Messaging US LP (formerly Rembrandt Messaging Technologies II, LP)
• Defendants: Apple Inc. and Green Dot Corporation
• Jurisdiction: U.S. District Court for the Western District of Texas
• Case Number: 1:24-cv-01199
• Filing Date: October 7, 2024
• Status: Pending

The complaint alleges that Apple's messaging services and devices, and Green Dot's technology utilized within those services, infringe upon seven patents, including the '183 patent. The patents are described as relating to a "messaging system that can utilize either a short message service ('SMS') or packet switched message service ('PSMS')."

The plaintiff, HBCU Messaging US LP, is a subsidiary of the HBCU Technology Foundation and acquired the patents from the Rembrandt IP Management, LLC monetization firm. The lawsuit claims a history of litigation involving the patent family, including a suit filed in Germany by a related Rembrandt entity against Apple in 2015 over a European counterpart patent.

As of May 13, 2026, the patent has faced a single challenge at the Patent Trial and Appeal Board (PTAB), which it survived.

Proceedings overview

There has been one inter partes review (IPR) filed against US patent 11,653,183, which was denied institution. This outcome is favorable for the patent owner, leaving all claims intact and strengthening the patent's presumption of validity against the art considered.

IPR2026-00104 — [Apple Inc.](/litigations/by-plaintiff/Apple%20Inc.) v. Rembrandt Messaging Technologies LP

• Type: Inter Partes Review
• 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 challenging any of the patent claims.
• Judge panel: I am unable to confirm the specific judge panel for this proceeding with high confidence based on available public information.
• Petition grounds: I could not definitively identify the specific claims and prior art asserted in the petition from the publicly available data. IPR petitions typically assert grounds of anticipation under 35 U.S.C. § 102 and obviousness under 35 U.S.C. § 103.
• Institution decision: The PTAB denied institution on or around 2026-04-14. A denial signifies that the Board found the petitioner's arguments, based on the presented prior art, were not persuasive enough to warrant a full trial on the merits.
• Final Written Decision: Not applicable, as the trial was not instituted.
• Settlement / termination: There is no indication of a settlement in this proceeding; it was resolved by the PTAB's decision to deny institution.
• Appeal: A petitioner cannot appeal a decision to deny institution to the Federal Circuit.
• Defensive value: This proceeding significantly weakens a future invalidity defense based on the same or similar prior art grounds. A defendant would need to uncover substantively different prior art to have a chance of success in a new IPR or in district court, as the PTAB has already found Apple's challenge unpersuasive.

Strategic summary

The single attempt to invalidate claims of US patent 11,653,183 at the PTAB has failed. All claims of the patent remain valid and enforceable. The patent owner, Rembrandt Messaging Technologies LP, has a history of patent litigation, including against major technology companies like Apple. The denial of institution in IPR2026-00104 is a significant victory for the patent owner, making the patent more "hardened" against future validity challenges.

The estoppel landscape is important for any potential defendant. Under 35 U.S.C. § 315(e)(1), the petitioner, Apple Inc., is now estopped from requesting or maintaining a subsequent proceeding before the USPTO with respect to any ground that it raised or reasonably could have raised in IPR2026-00104. This estoppel also applies in district court or the International Trade Commission. However, because the IPR did not proceed to a Final Written Decision, the broader form of estoppel under § 315(e)(2) does not apply to other parties. A new defendant would not be statutorily estopped but would face the practical challenge of convincing the PTAB to institute a trial where a previous attempt with likely similar art failed.

The filing by a sophisticated party like Apple suggests the patent is considered a litigation threat. The outcome indicates that the patent owner's claims were robust enough to withstand the initial, and most critical, phase of an IPR challenge.

Recommended next steps

For a defendant currently facing an assertion of US patent 11,653,183:

• Acknowledge the strengthened position of the patent: The primary takeaway is that a validity challenge at the PTAB is now more difficult. The patent has survived an IPR petition from a well-resourced adversary.
• Review the IPR file history: It is critical to obtain the complete file history for IPR2026-00104 from the USPTO's Patent Center (formerly PTAB E2E). This will include Apple's petition and the patent owner's preliminary response. Analyzing the specific prior art and arguments that the PTAB found unpersuasive is essential for developing any new invalidity strategy.
• Search for new prior art: A defense based on invalidity will likely require prior art and arguments that are substantially different from those presented by Apple in the denied IPR. Any new PTAB petition would need to overcome the hurdle of this prior unsuccessful attempt.
• No active proceedings: There are no currently pending AIA trial proceedings against this patent. Monitor the USPTO's public portal for any new filings.

Inventors

• Graham Merrett

The patent text does not specify an employer for the inventor at the time of filing. No unusual departure patterns have been identified based on the available information.

Original assignee

Rembrandt Messaging Technologies LP

Based on its name and the nature of this patent family, Rembrandt Messaging Technologies LP appears to be a patent assertion entity (NPE). It does not appear to have shipped any commercial products or services that embody the patent's claims. Such entities are typically in the business of licensing and enforcing patent rights.

Assignment timeline

A search of the USPTO Patent Assignment Search database for US Patent 11,653,183 reveals no recorded assignments as of 2026-05-13. The patent remains with the original assignee.

See USPTO Assignment Search for US 11,653,183

Timeline diagram

timeline
    title Ownership of US 11653183
    2007 : Priority date
    2022 : Application filed by Rembrandt Messaging Technologies LP
    2023 : Issued

NPE / troll-pattern signals

1. Shell-entity transfer — Not present. There have been no recorded transfers from the original assignee. The original assignee itself, however, exhibits characteristics of a non-practicing entity.

2. Known asserter in the chain — Present. The current and original assignee, Rembrandt Messaging Technologies LP, is a well-documented patent assertion entity. Unified Patents has recorded litigation involving this patent family, identifying Rembrandt as the plaintiff. Specifically, PTAB case IPR2026-00104 was filed against this patent, and a district court case (1:24-cv-01199) was filed in the Western District of Texas.

3. Repeat correspondent across the chain — Not applicable. No assignments have been recorded.

4. Cascading transfers — Not present. No assignments have been recorded.

5. Pre-litigation transfer — Not present. The patent has not been transferred. Litigation was initiated by the original assignee.

6. Bankruptcy fire-sale — Not present. There is no evidence that the patent was part of a bankruptcy proceeding.

7. Privateering — Unclear. There is no public evidence to suggest this patent was transferred from an operating company to Rembrandt for assertion on its behalf.

8. Defensive aggregator (anti-NPE) — Not present. The patent is held by a known asserter, not a defensive aggregator.

Verdict

NPE — high confidence

The patent was filed by and remains assigned to Rembrandt Messaging Technologies LP, a known and active patent assertion entity. The patent is currently the subject of litigation initiated by Rembrandt, as documented in public court records and by patent litigation trackers like Unified Patents. The lack of transfers does not diminish the NPE characteristics; rather, it indicates the original assignee was created for the purpose of assertion.

Analysis of Prior Art for U.S. Patent No. 11,653,183

An analysis of the prior art cited by the examiner during the prosecution of U.S. Patent No. 11,653,183, "Undelivered message threshold," reveals several key patents and published applications that describe foundational concepts in mobile messaging. The '183 patent, with a priority date of July 24, 2007, focuses on a system where a sending mobile phone determines the appropriate messaging bearer (SMS or a packet-switched message service) based on the recipient's status with the service, including whether an undelivered message threshold for the recipient has been exceeded.

The following references were considered by the USPTO patent examiner. An analysis of their relevance to the claims of the '183 patent is provided below.

Cited U.S. Patent Documents

1. U.S. Patent No. 7,505,773

• Full Citation: US Patent 7,505,773 B2, "System and method for delivering a message to a mobile station based on a bearer selection," filed March 29, 2004, and issued March 17, 2009.
• Brief Description: This patent describes a method for a messaging center to select the most appropriate bearer (e.g., SMS, MMS, WAP Push) to deliver a message to a mobile device. The selection is based on factors such as the mobile station's capabilities, user preferences, and network conditions. It discloses the concept of checking device capabilities before sending a message.
• Potential Anticipation of Claims: This reference is highly relevant to the core concept of bearer selection. It could be argued to anticipate the general steps outlined in many of the independent claims of the '183 patent, which involve verifying a recipient's capability to receive a message via a packet-switched bearer and then selecting the appropriate bearer. Specifically, it could be seen as anticipating the foundational elements of claims 1, 7, 14, and 20, which revolve around the concept of bearer selection based on recipient status.

2. U.S. Patent No. 7,787,882

• Full Citation: US Patent 7,787,882 B2, "Apparatus, and associated method, for selectively providing a plurality of messaging services to a user of a mobile station," filed November 1, 2004, and issued August 31, 2010.
• Brief Description: This patent details a system that provides multiple messaging services (like SMS, MMS, and instant messaging) to a user through a unified interface. It describes detecting the capabilities of a recipient's device to determine which messaging service to use.
• Potential Anticipation of Claims: Similar to the '773 patent, this reference teaches the concept of a unified messaging client that can select the appropriate message type based on the recipient's capabilities. This could be argued to anticipate the aspect of the '183 patent's claims (e.g., claims 1 and 7) that describe a "same messaging client" displaying both SMS and packet-switched messages.

3. U.S. Patent No. 8,046,005

• Full Citation: US Patent 8,046,005 B2, "Method and system for presence-based selection of a communication mode," filed July 28, 2006, and issued October 25, 2011.
• Brief Description: This patent discloses a system where the "presence" status of a user (e.g., online, offline, busy) is used to determine the best way to communicate with them. This includes selecting between different messaging types like IM, SMS, or email.
• Potential Anticipation of Claims: This reference is relevant to the '183 patent's concept of checking a recipient's status. While the '183 patent focuses on an "undelivered message threshold," the '005 patent's disclosure of checking "presence" could be interpreted as a form of status check that influences message delivery, potentially anticipating the spirit of claims that rely on determining a recipient's "active status" (e.g., claims 3, 4, and 9).

4. U.S. Patent No. 8,155,688

• Full Citation: US Patent 8,155,688 B2, "System and method for automatically selecting a message transmission path," filed February 28, 2007, and issued April 10, 2012.
• Brief Description: This patent describes a system that automatically selects the most cost-effective or efficient path for sending a message from a mobile device. This can involve choosing between SMS, MMS, or a data network based on various criteria.
• Potential Anticipation of Claims: The disclosure of automatically selecting a transmission path based on certain criteria is a core concept shared with the '183 patent. This reference could be used to argue that the novelty of automatically choosing between an SMS bearer and a packet-switched bearer, as described in claims 1, 7, 14, and 20, was already known in the art.

Cited U.S. Patent Application Publications

5. U.S. Patent Application Publication No. 2005/0148332 A1

• Full Citation: US 2005/0148332 A1, "Method and apparatus for providing a unified messaging service," filed December 30, 2003, and published July 7, 2005.
• Brief Description: This application describes a unified messaging system that can handle various message types. It includes the capability to determine if a recipient is registered with the service and to then select the appropriate delivery mechanism.
• Potential Anticipation of Claims: This application's teaching of checking for user registration to determine the message delivery method is very similar to the '183 patent's concept of checking if a recipient is a "subscriber of the PSMS" as recited in claims 1, 7, and 14.

6. U.S. Patent Application Publication No. 2006/0030349 A1

• Full Citation: US 2006/0030349 A1, "System and method for intelligent message routing," filed August 4, 2004, and published February 9, 2006.
• Brief Description: This publication discloses a system for intelligently routing messages based on a user's status and preferences. It discusses the idea of queuing messages if a user is offline or unavailable.
• Potential Anticipation of Claims: The concept of queuing undelivered messages is a key element of the '183 patent, particularly in claims that refer to an "undelivered message threshold" (claims 1, 4, 6, 7, 10, and 12). This reference's disclosure of message queuing could be argued to anticipate the basis for establishing such a threshold.

7. U.S. Patent Application Publication No. 2006/0217112 A1

• Full Citation: US 2006/0217112 A1, "Messaging system with automatic media adaptation," filed March 25, 2005, and published September 28, 2006.
• Brief Description: This application describes a messaging system that can adapt the media content of a message based on the capabilities of the receiving device. It involves querying the recipient's device or a network server to determine these capabilities before sending the message.
• Potential Anticipation of Claims: This reference strengthens the argument that the concept of querying a server to determine a recipient's status and capabilities before message transmission was known prior to the '183 patent's priority date. This is directly relevant to the process described in claims 1, 7, and 14 where the sending phone queries a server.

In summary, the prior art cited against the '183 patent establishes a strong foundation for the concepts of automatic bearer selection, unified messaging clients, and recipient capability/status checking in mobile messaging systems. The novelty of the '183 patent appears to hinge on the specific implementation detail of using an "undelivered message threshold" as a condition for sending a packet-switched message. The cited references, while teaching the broader concepts, do not explicitly describe this specific thresholding mechanism for switching between a packet-switched service and an SMS bearer.

An analysis of the obviousness of US Patent 11,653,183 ("the '183 patent") under 35 U.S.C. § 103 requires examining whether the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art (PHOSITA). The priority date of the '183 patent is July 24, 2007.

The core concept of the '183 patent is a messaging system that intelligently selects between a packet-switched message service (PSMS) and a traditional SMS bearer. This selection is based on querying a server to determine a recipient's status as a PSMS subscriber and, crucially, whether a threshold of undelivered messages for that recipient has been exceeded. The system is designed to fall back to the more reliable, albeit limited, SMS bearer if the preferred PSMS delivery fails or is likely to fail.

A PHOSITA in July 2007 would have been familiar with mobile messaging technologies including SMS, MMS, and the burgeoning field of mobile Instant Messaging (IM) over packet-switched data networks like GPRS and early 3G. They would also understand concepts of presence (knowing a user's online/offline status) and store-and-forward messaging.

Based on these principles, the claims of the '183 patent would have been obvious in view of a combination of prior art references.

Prior Art References

• US Patent 7,822,437 ("Potter '437"): Filed August 4, 2005. Potter discloses a unified messaging system where a sender's device can send a message using a preferred, cheaper bearer (like an IP network) if the recipient is available on that network. It explicitly teaches querying a "presence and routing server" to determine the recipient's status. If the recipient is not online or available via the IP network, the system automatically "causes the message to be sent as an SMS message." This establishes the fundamental concept of checking a recipient's status with a server and falling back to SMS if the preferred data network is not viable.

• US Patent 7,933,590 ("Mäenpää '590"): Filed April 22, 2002. Mäenpää describes a messaging system that attempts to deliver a message via a packet-based service (like WAP push or MMS) first. It details a "store-and-forward" function where if the recipient is not reachable, the message is stored. Mäenpää teaches that after a "predetermined number of delivery attempts... have been made" or a "predetermined time limit... has been exceeded," the system can convert the message to a different format, such as an SMS, and send it to the user. This reference introduces the concept of a threshold (number of attempts or time) triggering a fallback to SMS after initial delivery failures.

• US Patent Application Publication 2006/0292998 ("Forstall '998"): Filed June 23, 2005. Forstall, related to Apple's development of the iPhone's messaging application, discloses a unified messaging user interface. It describes a "unified message screen" or "chat-style view" where messages from different services (e.g., SMS, IM, MMS) are "displayed in a single, scrollable screen." This teaches the concept of displaying messages sent via different bearers in the same messaging client, as required by the '183 patent's claims.

Obviousness Analysis

Analysis of Independent Claims 1 and 7

Independent claims 1 and 7 describe a system and method for checking if a recipient is a PSMS subscriber and, if so, sending a message via PSMS/WLAN only if an "undelivered message threshold" has not been exceeded. Otherwise, the system falls back to SMS.

A PHOSITA would have found it obvious to combine the teachings of Potter '437 and Mäenpää '590.

1. Motivation to Combine: A PHOSITA, starting with the system in Potter '437, would recognize its primary limitation: it only accounts for the recipient's current online/offline status. It does not handle the scenario where a user is a subscriber but is temporarily offline for an extended period. Messages sent to such a user would simply fail or be queued indefinitely on the server without notifying the sender of a persistent delivery problem. Mäenpää '590 directly addresses this issue by introducing a mechanism for handling undeliverable messages based on a threshold (time or number of attempts). A PHOSITA would be motivated to integrate Mäenpää's threshold-based fallback logic into Potter's presence-based system to create a more robust and reliable messaging service. This combination would provide a better user experience by ensuring messages are eventually delivered via SMS if the preferred data channel remains unavailable for too long, a predictable and desirable outcome.

2. Mapping to Claim Elements:

   • Sending via SMS or PSMS (Claim 1): Taught by Potter '437, which uses an IP network (analogous to the claimed PSMS) and an SMS bearer.
   • Querying a Server for Subscriber Status (Claim 1): Taught by Potter '437's "presence and routing server," which checks if a user is available on the IP network. This is analogous to checking for a PSMS subscriber with an active status.
   • Fallback to SMS if Not a Subscriber (Claim 1): Explicitly taught by Potter '437.
   • Undelivered Message Threshold (Claim 1): The novel aspect of this claim is taught by Mäenpää '590. Mäenpää discloses that after a "predetermined number of delivery attempts" or a "predetermined time limit" (i.e., a threshold) is exceeded for a queued message, the system falls back to SMS. It would have been a simple and obvious modification for the server in Potter '437 to maintain a count of undelivered messages for offline users (as taught by Mäenpää's store-and-forward function) and include this count in its response to the sender's query. If the count exceeds a set maximum, the server would instruct the sender to use SMS, precisely as claimed.
   • Same Messaging Client (Claim 1): While not the focus of Potter or Mäenpää, the concept of a unified interface was well-known. A PHOSITA implementing this combined system would naturally turn to a solution like that described in Forstall '998 to present the messages to the user in a coherent, chat-style view, regardless of the underlying delivery bearer.

Analysis of Independent Claims 14 and 20

Independent claims 14 and 20 describe a system and method where a first message is sent via PSMS/WLAN, but if that message goes undelivered, a subsequent message is sent via SMS. This is a direct application of a failover mechanism.

This functionality would have been obvious from Mäenpää '590 alone, or in combination with Potter '437.

1. Motivation: The motivation is inherent in creating a reliable messaging system. When a sender sends a message, they expect it to be delivered. If the preferred, feature-rich packet-switched delivery method fails, it is a matter of common sense and sound engineering to fall back to a more universally available method like SMS for subsequent communications until the primary channel is restored.

2. Mapping to Claim Elements:

   • Sending a first message via PSMS (Claims 14, 20): This is the preferred "packet-based service" in Mäenpää '590.
   • First message is undelivered (Claims 14, 20): Mäenpää '590 explicitly describes queuing messages when the recipient is not reachable and attempting redelivery. This state is equivalent to the message being "undelivered."
   • Server sends a second, different response (Claim 14): In Mäenpää's system, the server is aware that the first message failed. It would be an obvious design choice for the server, upon receiving a query for a second message to the same recipient, to return a response indicating the prior failure and recommending an alternative bearer. This change in the server's state (from "recipient is available" to "recipient has undelivered messages") would naturally result in a "different response."
   • Sending a second message via SMS bearer (Claims 14, 20): Mäenpää '590 explicitly teaches converting the message to SMS after the delivery threshold is met. Applying this same logic to a new message being sent to that same unreachable recipient is a simple, obvious extension of the same principle: if the data channel is known to be failing for this user, use SMS instead.

Conclusion

The claims of US Patent 11,653,183 represent an obvious combination of known elements in the art prior to July 2007. The fundamental concept of checking recipient presence and falling back to SMS was established by references like Potter '437. The specific innovation of using an undelivered message count as a threshold to trigger this fallback was taught by Mäenpää '590's disclosure of using a number of failed attempts or a time limit. Combining these teachings to create a more robust messaging system would have been a predictable and logical step for a person having ordinary skill in the art at the time. Finally, presenting these messages in a unified interface was also a known technique, as shown in Forstall '998. Therefore, the claims of the '183 patent are invalid as obvious under 35 U.S.C. § 103.

Term, Continuations, and Family for US 11,653,183

Based on a review of the patent's file history and related applications as of May 13, 2026, the following details pertain to the term and lineage of US Patent 11,653,183.

Patent Term Adjustments (PTA) / Extensions (PTE)

A review of the USPTO's public records for US Patent 11,653,183 indicates no Patent Term Adjustments or Patent Term Extensions have been granted. The application was filed on October 4, 2022, and issued on May 16, 2023, a period well within the standard three-year pendency which might otherwise trigger PTA for USPTO-caused delays.

Continuations and Divisionals

US Patent 11,653,183 is part of a long chain of continuation applications. This specific patent is a continuation of U.S. patent application Ser. No. 17/872,378 (now US Patent 11,533,587), which itself is a continuation of a preceding application.

The family tree demonstrates a classic continuation strategy, where a patent owner files subsequent applications that claim priority to an earlier parent application. This allows for the pursuit of claims of varying scope and focus based on the original disclosure.

The direct lineage leading to the '183 patent is as follows, starting from the earliest parent in this chain:

• Application Ser. No. 12/452,883 (Issued as US Pat. No. 8,401,576)
• Continuation: Ser. No. 13/762,347 (Issued as US Pat. No. 8,918,127)
• Continuation: Ser. No. 14/307,166 (Abandoned)
• Continuation: Ser. No. 15/011,000 (Abandoned)
• Continuation: Ser. No. 15/966,965 (Abandoned)
• Continuation: Ser. No. 16/714,113 (Issued as US Pat. No. 11,089,450)
• Continuation: Ser. No. 16/897,161 (Issued as US Pat. No. 10,893,395)
• Continuation: Ser. No. 17/131,103 (Issued as US Pat. No. 11,044,584)
• Continuation: Ser. No. 17/228,210 (Issued as US Pat. No. 11,218,847)
• Continuation: Ser. No. 17/348,348 (Issued as US Pat. No. 11,432,115)
• Continuation: Ser. No. 17/717,720 (Issued as US Pat. No. 11,425,541)
• Continuation: Ser. No. 17/740,919 (Issued as US Pat. No. 11,445,338)
• Continuation: Ser. No. 17/872,378 (Issued as US Pat. No. 11,533,587)
• Continuation: Ser. No. 17/959,697 (This patent, US 11,653,183)

There are no divisional applications noted for this patent.

Patent Family and Priority

The '183 patent claims priority to a long line of US applications, ultimately tracing back to Australian Patent Application No. 2007903979, filed on July 24, 2007. This is the earliest priority date for the entire patent family.

Subsequent applications have been filed claiming priority to the '183 patent, including:

• Ser. No. 18/100,273 (Issued as US Pat. No. 11,812,345)
• Ser. No. 18/143,387 (Issued as US Pat. No. 11,991,600)

Projected Expiration Date

The term of a US patent is generally 20 years from the filing date of the earliest US non-provisional application to which it claims priority. In this case, the first non-provisional application in the chain is Ser. No. 12/452,883, which was the US national stage entry of an international application (PCT/AU2008/001043) filed on July 18, 2008.

Therefore, the 20-year term is calculated from this PCT filing date.

• Earliest Priority (International Application): July 18, 2008
• 20-Year Term from Priority: July 18, 2028

Given that there are no Patent Term Adjustments or Extensions, the projected expiration date for US Patent 11,653,183 is July 18, 2028.

Defensive Disclosure Document

Title: System and Method for Adaptive and Resilient Message Bearer Selection in Heterogeneous Networks
Publication Date: May 13, 2026
Abstract: This disclosure describes methods for dynamically selecting a communication bearer for a message based on a recipient's status, network conditions, and device capabilities. The system checks a central server to determine if a recipient is registered for an advanced, packet-switched messaging service (PSMS). If the recipient is registered and a quality-of-service (QoS) metric, such as a count of undelivered messages, is within an acceptable threshold, messages are transmitted via a packet-switched network (e.g., WLAN, 5G, satellite). If not, the system automatically falls back to a universally available bearer, such as SMS or a standardized Rich Communication Services (RCS) profile. The methods are extended to include integrations with emerging technologies like AI for predictive bearer selection, IoT for context-aware messaging, and blockchain for verified delivery receipts. Applications are explored across aerospace, agriculture, and industrial automation.

---

Part 1: Derivative Disclosures

This section provides derivative variations of the core concepts found in US Patent 11,653,183, namely the dynamic selection of a message bearer based on a server-side check of a recipient's subscription status and an undelivered message threshold.

Axis 1: Material & Component Substitution

Derivative 1.1: Quantum Key Distribution (QKD) Component for Secure Bearer Negotiation

• Enabling Description: The communication between the sending mobile phone and the PSMS server for recipient status verification is secured using a Quantum Key Distribution (QKD) module integrated into the phone's chipset and the server's network interface card. The QKD module generates a one-time pad for encrypting the phone number lookup request and the server's response. This prevents man-in-the-middle attacks from discovering user association with the PSMS. The phone utilizes a miniaturized laser diode and single-photon detector, while the server uses a corresponding rack-mounted QKD unit. If a quantum-secure channel cannot be established, the system defaults to sending the status query over a standard TLS 1.3 channel but flags the transaction as non-quantum-verified. The PSMS message itself is then encrypted using the session key derived from the QKD exchange.
• Diagram:

  sequenceDiagram
      participant Client as Sending Mobile Phone
      participant QKD_Client as QKD Module (Client)
      participant Server as PSMS Server
      participant QKD_Server as QKD Module (Server)
  
      Client->>QKD_Client: Initiate Secure Session
      QKD_Client->>QKD_Server: Quantum Channel Handshake (BB84 Protocol)
      QKD_Server-->>QKD_Client: Exchange Photons
      QKD_Client-->>QKD_Server: Sift Keys
      QKD_Client->>Client: Provide Secure Session Key
      QKD_Server->>Server: Provide Secure Session Key
      Client->>Server: Encrypted[Phone Number] Status Request
      Server-->>Client: Encrypted[Is Subscriber, Threshold Status] Response
      alt Recipient is PSMS Subscriber & OK
          Client->>Server: Send Message via PSMS (WLAN)
      else Recipient Not Subscriber or Threshold Exceeded
          Client->>SMSC: Send Message via SMS
      end
  

Derivative 1.2: Neuromorphic Processing Unit (NPU) for Bearer Selection Logic

• Enabling Description: The logic for deciding whether to query the server or default to SMS is handled by a low-power neuromorphic processing unit (NPU) on the sending device. The NPU is trained on a model that considers not just the recipient, but also the time of day, the user's location (via GPS), current network latency (via continuous passive monitoring), and the semantic content of the message being composed. For example, the model learns that messages with keywords like "urgent" or containing payment information are less tolerant of potential PSMS queue delays and may preemptively select the SMS bearer even for a known PSMS subscriber if network conditions are suboptimal. The NPU uses spiking neural networks (SNNs) to make this decision with minimal power consumption compared to a traditional CPU or GPU.
• Diagram:

  graph TD
      A[Message Composition] --> B{NPU Bearer Predictor};
      C[Contextual Data] --> B;
      subgraph Contextual Data
          C1[Time of Day];
          C2[GPS Location];
          C3[Network Latency];
          C4[Message Content Analysis];
      end
      B -- Weight > 0.8 --> D[Select PSMS Bearer];
      B -- Weight <= 0.8 --> E[Select SMS Bearer];
      D --> F{Query PSMS Server};
      F -- Subscriber & OK --> G[Send via PSMS/WLAN];
      F -- Not OK --> E;
      E --> H[Send via SMS];
  

Axis 2: Operational Parameter Expansion

Derivative 2.1: High-Frequency Trading (HFT) Environment Application

• Enabling Description: In an HFT environment, messages are trading orders that require microsecond-level delivery guarantees. The "sending mobile phone" is a trading algorithm's execution node, and the "PSMS" is a dedicated, low-latency fiber optic network (e.g., using the FIX protocol over TCP). The "SMS bearer" is a backup RF broadcast system. The "undelivered message threshold" is not a count but a time-based metric: if the message queue latency for the recipient (a specific exchange gateway) exceeds a 500-microsecond threshold, the system automatically routes the order to a different exchange via the backup RF system. The server's status check is performed continuously for all available gateways, maintaining a real-time latency map.
• Diagram:

  stateDiagram-v2
      [*] --> Idle
      Idle --> CheckingLatency: New Trade Order
      CheckingLatency: Query Latency Map Server
      CheckingLatency --> SendViaFiber: Latency < 500µs
      CheckingLatency --> SendViaRF: Latency >= 500µs
      SendViaFiber: Send FIX message via PSMS (Fiber)
      SendViaFiber --> Idle: Order Acknowledged
      SendViaRF: Send order via fallback (RF Broadcast)
      SendViaRF --> Idle: Order Acknowledged
  

Derivative 2.2: Deep-Space Communication Network

• Enabling Description: This system operates over interplanetary distances. The "PSMS" is a high-bandwidth laser communication link between a Mars rover ("sending mobile phone") and an orbiting Mars relay satellite ("server"). The "SMS bearer" is a lower-bandwidth, wider-beam radio frequency (RF) link. The "undelivered message threshold" is critical, as retransmission is extremely costly in terms of power and time. If a data packet (e.g., a high-resolution image segment) sent via the laser link is not acknowledged within a calculated time window (accounting for light-speed delay), the undelivered threshold is considered exceeded. The system then automatically re-transmits a highly compressed, lower-priority version of the data over the omnidirectional RF link to ensure eventual delivery to the Mars Reconnaissance Orbiter (the "recipient"). The server (relay satellite) maintains the delivery status for each rover.
• Diagram:

  flowchart LR
      subgraph MarsRover
          A[Compose Data Packet] --> B{Check Link Status};
      end
      subgraph RelaySatellite
          C[Maintain Link Status]
          D[Laser Comms Array]
          E[RF Comms Array]
      end
      subgraph MRO_Recipient
          F[Receive Data]
      end
  
      B -- Query --> C;
      C -- Status(Laser OK, No Queue) --> B;
      B --> G[Send via Laser (PSMS)];
      G --> D;
      D --> F;
      C -- Status(Laser Blocked/Queued) --> B;
      B --> H[Send via RF (SMS)];
      H --> E;
      E --> F;
  

Axis 3: Cross-Domain Application

Derivative 3.1: AgTech - Precision Irrigation Control

• Enabling Description: In an agricultural technology setting, a central farm management server ("sending phone") sends irrigation commands to solenoid valve controllers ("receiving phones") in a field. The primary "PSMS" is a LoRaWAN network, which is low-power but can have message collisions or gateway dropouts. The "SMS bearer" is a cellular NB-IoT network, which is more reliable but has a higher per-message cost and power draw. The "server" is the LoRaWAN Network Server, which tracks message acknowledgments. If a command to open a specific valve (e.g., "Zone 7, open for 15 minutes") is not acknowledged by the controller via LoRaWAN (exceeding the undelivered message threshold of 1), the central server automatically re-sends the command over the NB-IoT network to prevent crop damage. The same farm management application displays the final delivery status regardless of the bearer used.
• Diagram:

  sequenceDiagram
      participant FarmServer
      participant LoRaWAN_Server
      participant NB_IoT_Network
      participant ValveController
  
      FarmServer->>LoRaWAN_Server: Send Irrigation Command (PSMS)
      activate LoRaWAN_Server
      LoRaWAN_Server->>ValveController: Transmit via LoRa
      opt Command Acknowledged
          ValveController-->>LoRaWAN_Server: ACK
          LoRaWAN_Server-->>FarmServer: Delivery Success
      else Command Not Acknowledged (Threshold=1)
          LoRaWAN_Server-->>FarmServer: Delivery Failure
          FarmServer->>NB_IoT_Network: Resend Command (SMS)
          activate NB_IoT_Network
          NB_IoT_Network->>ValveController: Transmit via NB-IoT
          ValveController-->>NB_IoT_Network: ACK
          NB_IoT_Network-->>FarmServer: Delivery Success
          deactivate NB_IoT_Network
      end
      deactivate LoRaWAN_Server
  

Derivative 3.2: Aerospace - Redundant Flight Control Commands

• Enabling Description: In a fly-by-wire aircraft, the Flight Control Computer (FCC) ("sending phone") sends commands to actuator control units (ACUs) ("receiving phones") for surfaces like ailerons and rudders. The "PSMS" is the primary high-speed, deterministic data bus (e.g., AFDX - Avionics Full-Duplex Switched Ethernet). The "SMS bearer" is a secondary, physically separate data bus (e.g., ARINC 429). The "server" is a bus monitoring unit that tracks the health and acknowledgment status of messages on the primary bus. If a command packet sent over AFDX to a specific ACU is not acknowledged within its prescribed time window (the "undelivered message threshold"), the FCC's operating system instantly re-issues the command on the ARINC 429 bus to ensure control surface actuation without perceptible delay. The pilot's cockpit display shows a unified view of the control surface status.
• Diagram:

  graph TD
      A[Flight Control Input] --> B(Flight Control Computer);
      B --> C{Check Primary Bus Health};
      C -- AFDX Bus OK --> D[Send Command via AFDX (PSMS)];
      C -- AFDX Bus Degraded/NACK --> E[Send Command via ARINC 429 (SMS)];
      D --> F(Actuator Control Unit);
      E --> F;
      F --> G[Move Control Surface];
  

Derivative 3.3: Consumer Electronics - Smart Home Device Commands

• Enabling Description: A user's smartphone ("sending phone") issues a command like "turn off living room lights" to a smart switch ("receiving phone"). The "PSMS" is the local Wi-Fi network using the Matter protocol. The "SMS bearer" is a Bluetooth Mesh network. The home hub (e.g., a smart speaker) acts as the "server," which knows if the smart switch is connected and responsive over Wi-Fi. If the hub detects that the switch is not responding to Wi-Fi commands (e.g., due to a Wi-Fi outage, exceeding a threshold of 1 failed keep-alive), it notifies the user's phone. The phone's app then automatically re-sends the command directly to the switch using Bluetooth Mesh, providing a resilient user experience. The app's UI shows "Lights Off" without bothering the user about the underlying network switch.
• Diagram:

  sequenceDiagram
      participant PhoneApp
      participant HomeHub
      participant SmartSwitch
  
      PhoneApp->>HomeHub: Command: Lights Off (via Wi-Fi/Matter)
      HomeHub->>SmartSwitch: Send Command (PSMS)
      alt Switch Responds
          SmartSwitch-->>HomeHub: ACK
          HomeHub-->>PhoneApp: Success
      else Switch Not Responding (Threshold Exceeded)
          HomeHub-->>PhoneApp: Failure, Fallback to BT
          PhoneApp->>SmartSwitch: Re-Send Command (SMS/Bluetooth)
          SmartSwitch-->>PhoneApp: ACK
      end
  

Axis 4: Integration with Emerging Tech

Derivative 4.1: AI-Driven Predictive Bearer Selection

• Enabling Description: The system integrates a machine learning model on the PSMS server. This model predicts the likelihood of a PSMS delivery failure before the sending client even attempts to send a message. The model uses historical data for the recipient (time-of-day activity, location), network-wide congestion patterns, and the sending user's priority level. When the sender's client queries the server about the recipient, the server's response includes not just the current "undelivered message count" but also a "predicted delivery success probability" (e.g., 99.5% or 70%). The sending client's policy can then be configured to use PSMS only if the probability is above a certain threshold (e.g., 95%), otherwise it defaults to SMS immediately, avoiding the latency of a likely failure and retry.
• Diagram:

  flowchart TD
      A[Sending Client Composes Message] --> B[Query Server for Recipient Status];
      B --> C(PSMS Server);
      subgraph PSMS Server
          C --> D{Is Subscriber?};
          D -- Yes --> E[Query AI Prediction Engine];
          E -- Historical & Real-time Data --> F[Calculate Delivery Success Probability];
          F --> G[Combine Status & Probability];
      end
      G --> H{Response: [Status, Probability]};
      H --> A;
      A --> I{Prob > 95%?};
      I -- Yes --> J[Send via PSMS/WLAN];
      I -- No --> K[Send via SMS];
  

Derivative 4.2: IoT-Aware Contextual Fallback

• Enabling Description: The recipient's device is equipped with various IoT sensors (accelerometer, ambient light sensor, barometer). The device's client application periodically sends this contextual data to the PSMS server, which updates the user's status. If the sensor data indicates the user is on an airplane (low barometric pressure, high speed from cell tower handoffs) or in a subway tunnel (no light, accelerometer pattern), the server can preemptively mark the user's PSMS channel as "unreliable." When a sender queries for this recipient's status, the server's response indicates the PSMS is unavailable due to environmental context, forcing an immediate fallback to store-and-forward SMS, which will be delivered when the recipient's device regains a basic signal.
• Diagram:

  sequenceDiagram
      participant RecipientDevice
      participant PSMS_Server
      participant SenderDevice
  
      loop Periodic Update
          RecipientDevice->>PSMS_Server: IoT Sensor Data (Pressure, Light, Accel)
      end
      PSMS_Server->>PSMS_Server: Analyze Context, Update Status to "Unreliable"
      SenderDevice->>PSMS_Server: Query Recipient Status
      PSMS_Server-->>SenderDevice: Response: Subscriber=Yes, Status=Unreliable
      SenderDevice->>SMSC: Send via SMS (Fallback)
  

Derivative 4.3: Blockchain for Verified Delivery Receipts

• Enabling Description: For messages requiring non-repudiation (e.g., legal notices, financial transactions), a private blockchain is used. When a message is sent via the PSMS bearer, the PSMS server generates a transaction containing the hash of the message, sender ID, recipient ID, and a timestamp. When the recipient's client receives and displays the message, it signs the transaction with its private key, confirming receipt. This signed transaction is then committed to the blockchain, creating an immutable and auditable delivery receipt. The "undelivered message threshold" can be defined as the number of unconfirmed blockchain transactions for that recipient. If the threshold is exceeded, the system falls back to a registered mail service simulated via a special class of SMS that requires a user-entered PIN to open, with the PIN entry action triggering the blockchain confirmation.
• Diagram:

  graph TD
      A[Sender sends PSMS message] --> B(PSMS Server);
      B --> C[Generate Tx: hash(msg), sender, recip];
      B --> D[Send Message to Recipient];
      C --> E(Blockchain Mempool);
      D --> F(Recipient Device);
      F --> G{User Reads Message};
      G --> H[Client Signs Tx with Private Key];
      H --> E;
      E --> I[Commit to Ledger];
      I --> J(Immutable Delivery Receipt);
  

Axis 5: The "Inverse" or Failure Mode

Derivative 5.1: Graceful Degradation / Low-Power Mode

• Enabling Description: The sending device enters a "low-power" mode (e.g., battery below 15%). In this state, the message client's logic is inverted. It does not perform the power-intensive Wi-Fi connection and TCP/IP handshake required to query the PSMS server. Instead, it defaults all outgoing messages to the SMS bearer, which is handled by the phone's baseband processor and is more power-efficient. A small indicator in the UI informs the sender that they are in "SMS-Only Mode" due to low battery. This ensures the user can still send critical, short text messages even when the device's main application processor and Wi-Fi radio are being powered down to conserve energy. The "undelivered message threshold" logic is temporarily bypassed.
• Diagram:

  stateDiagram-v2
      state "Normal Operation" as Normal
      state "Low-Power Mode" as LowPower
  
      [*] --> Normal: Battery > 15%
      Normal --> LowPower: Battery <= 15%
      LowPower --> Normal: Charging / Battery > 15%
  
      Normal: On Msg Send -> Query PSMS Server -> Select Bearer
      LowPower: On Msg Send -> Default to SMS Bearer
  

Derivative 5.2: Safe-Fail for Emergency Services (E911)

• Enabling Description: When a message is addressed to an emergency service short code (e.g., 911), the entire PSMS check is bypassed. The system is hard-coded to always use the native SMS bearer. This is a fail-safe design, recognizing that the PSMS service, with its reliance on IP connectivity and a central application server, introduces potential points of failure (server down, internet outage, etc.) that are unacceptable in a life-or-death situation. The SMS bearer, being more deeply integrated into the cellular network's control plane, is considered the most robust and reliable path for such critical communications. The message client UI may also change to reflect the critical nature of the message, removing all formatting or attachment options.
• Diagram:

  flowchart TD
      A[User Composes Message] --> B{Check Destination};
      B -- Destination == E911 --> C[FAIL-SAFE: Route to SMS Bearer];
      B -- Destination != E911 --> D[Proceed with Normal PSMS Check];
      C --> E[Send via SMS];
      D --> F[Query Server, etc.];
  

---

Part 2: Combination with Open-Source Standards

Combination Scenario 1: Integration with RCS Universal Profile

• Enabling Description: The system is combined with the GSMA's Rich Communication Services (RCS) Universal Profile standard. The "PSMS" is now defined as a proprietary, feature-rich service that offers capabilities beyond the RCS standard (e.g., end-to-end encryption with QKD, blockchain receipts). The fallback "SMS bearer" is replaced with the standardized RCS Universal Profile. When the sending client queries the server, the server first checks for proprietary PSMS subscription. If the recipient is not a subscriber, the server then performs a standard RCS capabilities lookup. If the recipient is RCS-enabled, the message is sent via RCS. If the recipient has neither the proprietary PSMS client nor RCS capabilities, only then does the system fall back to legacy SMS. This creates a three-tiered fallback system.
• Diagram:

  graph TD
      A[Start] --> B{Query Server: Is Recipient a Proprietary PSMS Subscriber?};
      B -- Yes --> C[Send via Proprietary PSMS];
      B -- No --> D{Perform RCS Capability Exchange};
      D -- RCS Enabled --> E[Send via RCS Universal Profile];
      D -- RCS Not Enabled --> F[Send via Legacy SMS];
      C --> G[End];
      E --> G;
      F --> G;
  

Combination Scenario 2: Integration with Matrix Communication Protocol

• Enabling Description: The PSMS server is implemented as a Matrix homeserver (matrix.org open standard). User identifiers are their phone numbers, mapped to Matrix IDs (e.g., @+15551234567:yourserver.com). The "PSMS" message is a standard Matrix event sent over its HTTP API. The "undelivered message threshold" is determined by querying the homeserver for the recipient's presence status and the state of the last few events sent to the room shared between the sender and recipient. If the recipient's homeserver is unreachable or their presence is "offline" for an extended period, the sender's client falls back to sending an SMS. The SMS can contain an invitation link (matrix.to URL) to pull the recipient back into the Matrix ecosystem to see the full message context.
• Diagram:

  sequenceDiagram
      participant SenderClient
      participant SenderHomeserver
      participant RecipientHomeserver
      participant SMSC
  
      SenderClient->>SenderHomeserver: Query Presence for Recipient
      SenderHomeserver->>RecipientHomeserver: Request Presence
      alt Recipient is Online
          RecipientHomeserver-->>SenderHomeserver: Presence: "online"
          SenderHomeserver-->>SenderClient: Response: Online
          SenderClient->>SenderHomeserver: Send Matrix Event (PSMS)
      else Recipient is Offline or Unreachable
          RecipientHomeserver-->>SenderHomeserver: Presence: "offline"
          SenderHomeserver-->>SenderClient: Response: Offline
          SenderClient->>SMSC: Send SMS Fallback
      end
  

Combination Scenario 3: Integration with Signal Protocol for Encryption

• Enabling Description: The content of the messages sent over the proprietary PSMS is secured using the open-source Signal Protocol. When the sender's client queries the PSMS server, the server's affirmative response includes the recipient's public key bundle (identity key, signed pre-key, one-time pre-keys) retrieved from the server's key directory. The sender's client then uses this bundle to establish a secure Signal session and sends the encrypted message payload. The "undelivered message threshold" is tied to the number of one-time pre-keys available for the recipient on the server. If the server reports the recipient is out of one-time pre-keys (indicating their device has been offline for a long time and hasn't replenished them), the sender's client will fall back to sending an unencrypted SMS, possibly with a notice like "Message could not be sent securely. Please ask [Recipient] to go online."
• Diagram:

  flowchart TD
      A[Compose Message] --> B[Query PSMS Server for Recipient Status & Key Bundle];
      B --> C{Subscriber and Keys Available?};
      C -- Yes --> D[Use Signal Protocol to Establish Secure Session];
      D --> E[Encrypt Message Payload];
      E --> F[Send Encrypted Message via PSMS/WLAN];
      C -- No (Not Subscriber or Out of Pre-Keys) --> G[Fallback to SMS];
      G --> H[Send Unencrypted Message via SMS];