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];