Derivative works — US Patent 11991600

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.