Derivative works — US Patent 11991601

Defensive Disclosure and Prior Art Generation

RE: U.S. Patent 11,991,601 “Wireless messaging method and server”
Publication Date: May 13, 2026

This document serves as a defensive publication of derivative concepts and technical variations related to the art described in U.S. Patent 11,991,601 (hereafter 'the '601 patent'). The purpose is to place these concepts into the public domain, thereby establishing them as prior art to preclude future patenting of these or similar obvious variations by third parties. The disclosures herein build upon the core method of dynamic bearer selection for messaging based on recipient subscriber status, as outlined in the claims of the '601 patent.

Section 1: Derivative Works Based on Core Method (Claim 1)

The core method involves a mobile device downloading a client, authenticating via SMS, and then dynamically selecting between a packet-switched bearer (e.g., WLAN) for fellow subscribers and a circuit-switched bearer (SMS/EMS) for non-subscribers.

1.1. Material & Component Substitution

Derivative 1.1.1: USSD-Based Authentication and Status Check

Enabling Description: The authentication process, instead of using the SMS protocol, utilizes Unstructured Supplementary Service Data (USSD). When the client program is first launched, it generates a unique device identifier and sends a USSD message (e.g., *123*<auth_identifier>#) to a service number. The messaging server receives this request in real-time via the mobile network's HLR/VLR, authenticates the device's phone number (MSISDN) instantly, and adds it to the subscriber list. Subsequent checks for a recipient's status are also performed via a USSD query, which provides a synchronous, low-latency response indicating subscriber status without consuming the user's SMS inbox. This is more efficient for machine-to-machine checks than the store-and-forward nature of SMS.

Mermaid Diagram:

sequenceDiagram
    participant Client as Mobile Client
    participant MSC as Mobile Switching Center
    participant Server as Messaging Server
    Client->>MSC: Initiate USSD Session (*123*AuthID#)
    MSC->>Server: Forward USSD Request (MSISDN, AuthID)
    Server->>Server: Validate AuthID, Add MSISDN to Subscribers
    Server-->>MSC: USSD Response (Success)
    MSC-->>Client: Display/Process USSD Response
    Client->>MSC: Initiate USSD Query (*124*RecipientMSISDN#)
    MSC->>Server: Forward USSD Query
    Server->>Server: Check Subscriber List for RecipientMSISDN
    Server-->>MSC: USSD Response (Is_Subscriber: true/false)
    MSC-->>Client: Process Response to Select Bearer

Derivative 1.1.2: Data Transport Using Protocol Buffers over QUIC

Enabling Description: The message content sent over the packet-switched bearer is not formatted as an XML ASCII string but is instead serialized using Google's Protocol Buffers (Protobuf). This provides a more compact and efficient binary format, reducing latency and bandwidth consumption. The transport protocol used is QUIC (Quick UDP Internet Connections) instead of TCP. This further reduces connection establishment latency and provides multiplexing without head-of-line blocking, making it superior for real-time messaging, especially on mobile networks with frequent connection interruptions. The fallback to SMS/EMS for non-subscribers remains unchanged.

Mermaid Diagram:

graph TD
    A[Message Content Generation] --> B{Serialize with Protobuf};
    B --> C[Establish QUIC Session];
    C --> D[Transmit Protobuf Datagrams];
    D --> E[Recipient Client];
    E --> F{Deserialize Protobuf};
    F --> G[Display Message];

1.2. Operational Parameter Expansion

Derivative 1.2.1: High-Frequency M2M Communication in Vehicular Networks

Enabling Description: The messaging method is applied to a Vehicle-to-Everything (V2X) network at an industrial scale. Each vehicle acts as a "mobile wireless device." The "client program" is embedded in the vehicle's Telematics Control Unit (TCU). Vehicles subscribe to a central traffic management service. When a vehicle needs to send a critical safety message (e.g., "hard braking event"), it queries the recipient vehicle's status. If the recipient is a subscriber with an active 5G URLLC (Ultra-Reliable Low-Latency Communication) connection (the packet-switched bearer), the message is sent as a rich data packet containing precise GPS coordinates, deceleration curves, and LIDAR point-cloud data. If the recipient vehicle is not a subscriber or is only reachable via a legacy DSRC (Dedicated Short-Range Communications) or C-V2X on a 4G network (the "SMS bearer" equivalent), the TCU formats a basic, standardized safety message with only the event type and location.

Mermaid Diagram:

stateDiagram-v2
    state "Vehicle A (Sender)" as A
    state "Vehicle B (Recipient)" as B
    [*] --> A
    A --> CheckRecipient: Hard Braking Event
    state CheckRecipient <<fork>>
        CheckRecipient --> Subscriber: If B is on 5G URLLC
        CheckRecipient --> NonSubscriber: If B is on legacy DSRC/4G
    Subscriber --> SendRichData: Send full sensor data via 5G
    NonSubscriber --> SendBasicAlert: Send standardized alert via DSRC
    SendRichData --> B
    SendBasicAlert --> B
    B --> [*]

1.3. Cross-Domain Application

Derivative 1.3.1: Aerospace - Satellite Constellation Tasking

Enabling Description: The method is used for communication between a ground station and a constellation of Earth observation satellites. The "client" is on the ground station. When a new imaging task is submitted, the ground station must command a specific satellite. It first checks the satellite's status with a constellation management server. If the satellite is capable and has an active high-bandwidth Ka-band link (the packet-switched bearer), the server sends a detailed command packet including precise orbital adjustments, sensor calibration settings, and a complex imaging schedule. If the satellite is in a power-saving mode or only has a low-bandwidth S-band telemetry link available (the SMS bearer equivalent), the ground station sends a highly compressed, essential command (e.g., "Image_Grid_XYZ_Now") which the satellite's onboard system expands using pre-stored parameters.

Mermaid Diagram:

sequenceDiagram
    participant GroundStation
    participant ConstellationManager
    participant Satellite
    GroundStation->>ConstellationManager: Query Satellite Status (ID: Sat-01)
    ConstellationManager-->>GroundStation: Response (Status: Active, Link: Ka-Band)
    GroundStation->>Satellite: Send Detailed Tasking Packet (Ka-Band)
    alt Satellite S-Band Only
        GroundStation->>ConstellationManager: Query Satellite Status (ID: Sat-02)
        ConstellationManager-->>GroundStation: Response (Status: Low Power, Link: S-Band)
        GroundStation->>Satellite: Send Compressed Command (S-Band)
    end

Derivative 1.3.2: AgTech - Smart Irrigation System

Enabling Description: The system manages communication between a central farm server and various irrigation controllers in fields. The farm server checks if a specific controller is a "subscriber" to the farm's private LoRaWAN network (the packet-switched bearer). If so, it sends a detailed irrigation schedule with variable flow rates based on real-time soil moisture sensor data. If a controller is older or in a location only covered by public cellular IoT networks like NB-IoT or LTE-M (the SMS bearer equivalent), the server sends a simple on/off command with a fixed duration, which is less efficient but ensures basic functionality. The authentication is done when a new controller is installed, sending its hardware ID via an NB-IoT message to register with the server.

Mermaid Diagram:

graph TD
    subgraph Farm Server
        A[New Schedule] --> B{Check Controller Status};
    end
    subgraph Field Controller
        C[Controller X]
        D[Controller Y]
    end
    B -- LoRaWAN Subscriber --> E[Format Rich LoRaWAN Packet];
    E --> C;
    B -- NB-IoT Only --> F[Format Simple NB-IoT SMS];
    F --> D;
    C --> G[Execute Variable Flow Schedule];
    D --> H[Execute Simple On/Off];

1.4. Integration with Emerging Tech

Derivative 1.4.1: AI-Optimized Predictive Bearer Selection

Enabling Description: The client program integrates a lightweight, on-device machine learning model. Instead of querying the server for every message, the model predicts the recipient's subscriber status and likely network availability based on historical communication patterns, time of day, user location (with consent), and current network performance telemetry. The model outputs a probability score for packet-switched success. If the score is above a configurable threshold (e.g., 95%), the client sends the message via the packet-switched bearer without a preliminary check, reducing latency. If the score is low, it defaults to SMS. The model is continuously updated (federated learning) based on the actual success/failure of message deliveries, improving its accuracy over time.

Mermaid Diagram:

flowchart LR
    A[Compose Message] --> B[Input to ML Model: Recipient, Time, Location];
    B --> C{Predict PS_Success_Prob};
    C -- Prob > 0.95 --> D[Send via Packet-Switched];
    C -- Prob <= 0.95 --> E[Send via SMS Bearer];
    D --> F{Delivery Success?};
    E --> F;
    F -- Yes/No --> G[Update On-Device ML Model];

Derivative 1.4.2: Blockchain-Managed Decentralized Subscriber List

Enabling Description: The subscriber list is not maintained by a central server but on a permissioned blockchain (e.g., Hyperledger Fabric). When a user authenticates, a transaction is written to the distributed ledger, mapping their phone number's hash to their public key and subscriber status. To check a recipient's status, the client program queries a node of the blockchain. This provides a tamper-proof, decentralized, and auditable record of subscribers, removing the single point of failure and control of a central server. Messages on the packet-switched bearer can be encrypted using the recipient's public key retrieved from the ledger.

Mermaid Diagram:

sequenceDiagram
    participant ClientA as Sending Client
    participant BlockchainNode
    participant ClientB as Receiving Client
    ClientA->>BlockchainNode: Query hash(ClientB_PhoneNumber)
    BlockchainNode-->>ClientA: Return Record {is_subscriber: true, pub_key: '...'}
    ClientA->>ClientA: Encrypt message with ClientB_pub_key
    ClientA->>ClientB: Send encrypted packet-switched message

1.5. The "Inverse" or Failure Mode

Derivative 1.5.1: Graceful Degradation to Ad-Hoc Mesh Network

Enabling Description: When the client program cannot connect to the central messaging server to verify a recipient's status (due to a server outage or lack of internet), it enters a "degraded" mode. In this mode, it uses local peer-to-peer networking technologies like Wi-Fi Aware or Bluetooth Mesh to discover other clients in the vicinity. It broadcasts a Bloom filter containing the hashes of its intended recipients' phone numbers. Nearby clients check this filter against their own number's hash. If there's a match, the recipient's client responds, and a direct device-to-device link is established for packet-switched messaging, bypassing both the server and the cellular network. If no peer is found after a timeout, the client falls back to sending a standard SMS.

Mermaid Diagram:

stateDiagram-v2
    state "Online" as Online
    state "Degraded" as Degraded
    state "P2P Discovery" as P2P
    state "SMS Fallback" as SMS
    [*] --> Online
    Online --> Degraded: Server Unreachable
    Degraded --> P2P: Initiate P2P Broadcast
    P2P --> Degraded: Peer Found, Direct Connection
    P2P --> SMS: Timeout, No Peer Found
    Degraded --> Online: Server Reachable Again
    SMS --> Online: Server Reachable Again

Section 2: Combination with Open-Source Standards

Combination 2.1: Integration with RCS Universal Profile

Enabling Description: The subscriber check mechanism of the '601 patent is implemented as a proprietary capability extension within the open Rich Communication Services (RCS) standard. A standard RCS client, upon initiating a chat with a contact, performs the standard SIP OPTIONS query to determine RCS capabilities. In addition, it performs a background HTTPS query to the '601 patent's server to check for "premium subscriber" status. If the recipient is a premium subscriber, the client enables an extension in the application/vnd.gsma.rcs-ft-http+xml message body, allowing it to send proprietary, interactive objects (e.g., polls, payment requests) that are rendered by the recipient's client. If the recipient is only a standard RCS user, these options are disabled, and only standard RCS features (chat, file transfer) are used. If the user has no RCS capabilities, the client falls back to SMS as per the standard.

Mermaid Diagram:

sequenceDiagram
    participant SenderClient
    participant RCSServer
    participant ProprietaryServer
    participant RecipientClient
    SenderClient->>RCSServer: SIP OPTIONS for Recipient
    RCSServer-->>SenderClient: Standard RCS Capabilities
    SenderClient->>ProprietaryServer: HTTPS GET /status?id=Recipient
    ProprietaryServer-->>SenderClient: {is_premium: true}
    SenderClient->>RecipientClient: RCS Message with Proprietary Payload

Combination 2.2: Federation via XMPP (Jabber) with SMS Gateway

Enabling Description: The packet-switched messaging backbone is implemented using the open and federated XMPP (Extensible Messaging and Presence Protocol) standard. Each user's identifier is their phone number mapped to a JID (Jabber ID), e.g., +15551234567@messaging.com. When a user sends a message, the client first attempts to resolve the recipient's JID via standard XMPP server-to-server federation. If the recipient's server is found and the user is online, the message is delivered via XMPP. If the JID is not resolvable or the user is offline (as per XMPP presence), the sender's XMPP server (acting as the "message server" from the '601 patent) forwards the message to an integrated SMS gateway, which then delivers the content as a standard SMS to the recipient's phone number. The initial authentication is also handled by the XMPP server, which sends an SMS with a one-time code to verify ownership of the phone number before creating the JID.

Mermaid Diagram:

graph TD
    ClientA[Client A] --> ServerA[Server A (XMPP)];
    ServerA --> B{Recipient JID Resolvable?};
    B -- Yes --> ServerB[Recipient Server B (XMPP)];
    ServerB --> ClientB[Client B];
    B -- No --> SMSGW[SMS Gateway];
    SMSGW --> C[Deliver as SMS to Phone Number];

Combination 2.3: End-to-End Encryption using the Signal Protocol

Enabling Description: The method from the '601 patent is combined with the open-source Signal Protocol for end-to-end encryption. The message server, in addition to storing subscriber status, also acts as a key distribution server, storing users' public pre-keys, as is standard in Signal Protocol implementations. When a client checks a recipient's status and confirms they are a subscriber, it also fetches the recipient's public key bundle from the server. It then establishes an encrypted session using Signal's Double Ratchet Algorithm and sends the message payload over the packet-switched bearer. The server only sees encrypted blobs and cannot read the message content. If the recipient is not a subscriber, the client falls back to sending the message as a standard, unencrypted SMS or EMS message, explicitly warning the user that the communication is not secure.

Mermaid Diagram:

sequenceDiagram
    participant ClientA
    participant Server
    participant ClientB
    ClientA->>Server: Get status & key bundle for ClientB
    alt Subscriber
        Server-->>ClientA: {is_subscriber: true, keys: [...]}
        ClientA->>ClientA: Establish Signal Protocol Session
        ClientA->>ClientB: Send E2E Encrypted Message
    else Not a Subscriber
        Server-->>ClientA: {is_subscriber: false}
        ClientA->>ClientA: Display "Unsecure SMS" Warning
        ClientA->>ClientB: Send Plaintext SMS Message
    end