Derivative works — US Patent 11418466

Defensive Disclosure and Prior Art Generation

Title: Systems and Methods for Stateful, Multi-Protocol, Asynchronous Communication with Anonymous and Progressively Authenticated Entities
Publication Date: April 29, 2026
Reference Patent: U.S. Patent 11418466
Summary: The following technical disclosures describe systems, methods, and architectures that extend, modify, and combine the core concepts of managing distinct, stateful communication sessions with unauthenticated entities across heterogeneous communication protocols. These disclosures are intended to enter the public domain as prior art.

1. Component and Protocol Substitution Derivatives

1.1. Derivative: Serverless Function and Edge-Computed Session Management

Enabling Description: This variation replaces the centralized server architecture (implied in patent 11418466) with a serverless, function-as-a-service (FaaS) architecture deployed on a global content delivery network (CDN) with edge computing capabilities. When a first user (initiator) sends a communication request from a web browser, an edge function is triggered. This function generates a UUIDv4 as the first conversation identifier and stores the session state in a globally replicated, low-latency key-value store (e.g., Cloudflare KV, AWS DynamoDB Global Tables).
A second user, communicating via a different protocol like SMS, sends a message to a registered number. This triggers a separate FaaS function via a webhook from an SMS gateway (e.g., Twilio). This function uses the user's phone number as an initial key to look up or create a second conversation identifier in the same global key-value store. Responder communications are also handled by dedicated FaaS functions that fetch the appropriate session context, determine the target protocol (web browser via WebSocket or SMS via gateway API), and dispatch the message. This architecture eliminates single-point-of-failure servers and dramatically reduces latency by processing sessions at the network edge closest to the users.

Mermaid Diagram:

sequenceDiagram
    participant Browser as User 1 (Web)
    participant Edge as Edge Function
    participant KV as Global Key-Value Store
    participant Responder
    participant SMS_GW as SMS Gateway
    participant Phone as User 2 (SMS)

    Browser->>Edge: First communication request (HTTP)
    Edge->>Edge: Generate ConversationID_1
    Edge->>KV: storeSession(ConversationID_1, {protocol: 'ws'})
    Edge->>Responder: Notify(ConversationID_1, message)

    Phone->>SMS_GW: Second communication (SMS)
    SMS_GW->>Edge: Webhook with message + Phone_Number
    Edge->>KV: findSession(PhoneNumber)
    alt Session not found
        Edge->>Edge: Generate ConversationID_2
        Edge->>KV: storeSession(ConversationID_2, {protocol: 'sms', phone: PhoneNumber})
    end
    Edge->>Responder: Notify(ConversationID_2, message)

    Responder->>Edge: Reply(ConversationID_1, reply_msg)
    Edge->>KV: getSession(ConversationID_1)
    Edge->>Browser: Push message via WebSocket

1.2. Derivative: Communication via Protocol Buffers over gRPC

Enabling Description: This derivative replaces the general concept of "active communication protocols" with a high-performance framework using Protocol Buffers (Protobuf) for data serialization and gRPC for communication. The first active communication protocol between the web browser and the server is gRPC-Web, which allows for efficient, strongly-typed, bidirectional streaming. The second active communication protocol for a different user (e.g., a native mobile application) is native gRPC over HTTP/2. A first conversation identifier is created for the gRPC-Web session. When the responder communicates with a second user via the mobile app, the system identifies the user's gRPC channel and uses a second conversation identifier to route the Protobuf-serialized message. This approach provides strict schema enforcement, high performance, and automatic code generation for clients in multiple languages, making it superior to loosely-typed JSON over REST for real-time applications.

Mermaid Diagram:

graph TD
    subgraph User 1
        A[Web Browser with gRPC-Web Client]
    end
    subgraph User 2
        B[Mobile App with Native gRPC Client]
    end
    subgraph Backend
        C{gRPC Server/Proxy}
        D[Session Manager]
        E[Persistent Data Store]
    end
    subgraph Responder
        F[Responder Application]
    end

    A -- Protobuf over gRPC-Web --> C
    B -- Protobuf over gRPC --> C
    C <--> D
    D -- Stores/Retrieves Session --> E
    D -- ConversationID_1/ConversationID_2 --> C
    C <--> F

2. Operational Parameter Expansion Derivatives

2.1. Derivative: Massive-Scale IoT Command and Control

Enabling Description: This derivative applies the core concept to an industrial Internet of Things (IIoT) context, managing millions of concurrent, unauthenticated sessions with resource-constrained devices. A "user" is a headless device in the field (e.g., a soil moisture sensor). A device initiates a first communication request using a lightweight protocol like MQTT or CoAP. The server, acting as an MQTT broker, assigns a first conversation identifier to the device's session, associating it with the device's unique client ID. A "responder" is an automated control system that sends commands (the "request for information").
A second device, perhaps from a different manufacturer, communicates using a different protocol, such as UDP packets sent to a specific port. The system's UDP listener ingests these packets, creates a second conversation identifier, and associates it with the device's source IP address and port. The control system can thus manage distinct, command-and-control conversations with millions of devices across disparate, low-power, and unreliable networks.

Mermaid Diagram:

flowchart LR
    subgraph Device Fleet 1
        D1(Device A) -- MQTT --> Broker
    end
    subgraph Device Fleet 2
        D2(Device B) -- UDP --> Listener
    end
    subgraph Cloud Platform
        Broker -- assigns ConversationID_1 --> SM
        Listener -- assigns ConversationID_2 --> SM
        SM(Session Manager) <--> PDS(Persistent Device Store)
    end
    subgraph Control System
        CS(Automated Responder)
    end
    CS -- Command for Device A --> SM
    SM -- Routes via MQTT --> D1
    CS -- Command for Device B --> SM
    SM -- Routes via UDP --> D2

3. Cross-Domain Application Derivatives

3.1. Derivative: Aerospace - Autonomous Drone Swarm Coordination

Enabling Description: In this application, a ground control station (the "responder") communicates with a swarm of autonomous drones. A first user is a drone communicating over a primary, high-bandwidth C-band link (first active communication protocol). The drone initiates a connection, and the ground station system assigns a first conversation identifier to track its telemetry and command-response state.
If a drone in the swarm loses its primary C-band link due to jamming or atmospheric conditions, its onboard logic fails over to a second active communication protocol, such as a low-bandwidth Iridium satellite link. This is treated as a new communication request from a second user (or the same user on a new channel). The system assigns a second conversation identifier and links it to the original drone ID, allowing the ground control station to continue sending critical commands (e.g., "return to base") over the backup channel. The system seamlessly manages communication across heterogeneous, intermittently available networks, ensuring resilient swarm control.

Mermaid Diagram:

stateDiagram-v2
    [*] --> Active_C_Band
    Active_C_Band: Drone sends telemetry via C-Band.
    Active_C_Band: GCS uses ConversationID_1.
    Active_C_Band --> Link_Loss: Jamming or Signal Obstruction

    Link_Loss --> Active_Satellite: Failover to Iridium
    Active_Satellite: Drone sends minimal telemetry via Satellite.
    Active_Satellite: GCS uses ConversationID_2.
    Active_Satellite --> Active_C_Band: Primary Link Re-established

    state Link_Loss {
        direction LR
        [*] --> Failing
        Failing --> Connection_Dropped
    }

3.2. Derivative: AgTech - Precision Irrigation and Pest Control

Enabling Description: A farm management platform acts as the "responder" communicating with in-field devices. An in-field sensor array (first user) for monitoring soil moisture initiates a request via a LoRaWAN network (first active communication protocol). The platform's LoRaWAN gateway receives the data, and the backend application creates a first conversation identifier for that sensor array.
Separately, an autonomous pest-control drone (second user) communicates using a local Wi-Fi mesh network (second active communication protocol) when it's near a field-installed access point. The platform receives the drone's status request and assigns it a second conversation identifier. The platform can now send distinct commands: a request for a moisture reading to the sensor array via LoRaWAN, and a command to dispense pesticide to the drone via Wi-Fi, all managed through the same backend logic but using different identifiers and protocols.

Mermaid Diagram:

sequenceDiagram
    participant Sensors as LoRaWAN Sensor Array
    participant Drone as Wi-Fi Drone
    participant Platform as Farm Mgt. Platform
    participant Responder as Farmer/Automated Logic

    Sensors->>Platform: Moisture data (LoRaWAN)
    Platform->>Platform: Create ConversationID_A for Sensors
    Platform->>Responder: Notify: New Sensor Data

    Drone->>Platform: Status update (Wi-Fi Mesh)
    Platform->>Platform: Create ConversationID_B for Drone
    Platform->>Responder: Notify: Drone is Online

    Responder->>Platform: Command: Spray Field X (for Drone)
    Platform->>Drone: executeSpray(fieldX) via Wi-Fi

    Responder->>Platform: Command: Get new reading (for Sensors)
    Platform->>Sensors: requestReading() via LoRaWAN

4. Integration with Emerging Technology Derivatives

4.1. Derivative: AI-Driven Responder Matching and Sentiment Analysis

Enabling Description: This derivative integrates an AI inference model into the communication flow. When the system receives the first communication request from an unauthenticated user, the message content is passed to a natural language processing (NLP) model. The AI performs two functions: 1) It analyzes the sentiment and intent of the message. 2) It extracts keywords and compares them against a skills-based profile database of available responders. The system then routes the request to the optimal responder (e.g., a technical expert for a product question, a de-escalation specialist for an angry user). The first conversation identifier is associated not only with the user's session but also with metadata generated by the AI model (sentiment score, intent tags). This allows for advanced analytics and automated quality-of-service monitoring.

Mermaid Diagram:

flowchart TD
    A[User Request Received] --> B{Pass to NLP Model};
    B --> C[Extract Intent & Keywords];
    B --> D[Analyze Sentiment];
    C --> E{Query Responder Database};
    E --> F[Select Optimal Responder];
    D --> G[Tag Conversation w/ Sentiment Score];
    F & G --> H[Assign ConversationID and Route to Responder];

4.2. Derivative: Blockchain for Verifiable, Immutable Conversation Audits

Enabling Description: For use in regulated industries (e.g., finance, healthcare), this derivative uses a blockchain to create a tamper-proof audit trail of conversations. When a first communication is received, the system generates the first conversation identifier. The message itself, along with a timestamp and the responder's identifier, is cryptographically hashed. This hash is then recorded as a transaction on a private, permissioned blockchain (e.g., Hyperledger Fabric). The first conversation identifier acts as a primary key for querying the blockchain ledger. This ensures that all interactions are immutable and can be independently verified by auditors without compromising the privacy of the full message content, which can be stored off-chain in an encrypted database. The on-chain record proves that a communication occurred at a specific time between specific parties, and the hash guarantees its integrity.

Mermaid Diagram:

graph LR
    subgraph Off-Chain
        UC(User Communication)
        RS(Responder System)
        DB[(Encrypted DB)]
    end
    subgraph On-Chain
        BC(Permissioned Blockchain)
        LT[Ledger Transactions]
    end
    UC --> RS
    RS -- 1. Stores Message --> DB
    RS -- 2. Hashes Message + Metadata --> HASH
    HASH -- 3. Records as Transaction --> BC
    BC --> LT
    Auditor -- Verifies Hash --> BC

5. "Inverse" or Failure Mode Derivatives

5.1. Derivative: Graceful Protocol Degradation Mode

Enabling Description: This system is designed to handle network instability or server overload by gracefully degrading the communication protocol. A user starts a conversation in their web browser using a WebSocket (first active communication protocol), which offers a rich, real-time experience. The system monitors the connection quality (e.g., ping/pong latency, packet loss). If the quality drops below a predefined threshold, or if server load exceeds 80% capacity, the system automatically switches the user's session to a less resource-intensive protocol. It sends a final message via the WebSocket instructing the client-side code to switch to long-polling HTTP (second active communication protocol). The server maintains the first conversation identifier but now services the user through stateless HTTP requests instead of a persistent WebSocket connection. This ensures the conversation can continue, albeit with higher latency, preventing a total service outage during periods of stress.

Mermaid Diagram:

stateDiagram-v2
    state "High Performance (WebSocket)" as HP {
        [*] --> Connected
        Connected: Real-time messaging
        Connected: Low latency
    }
    state "Degraded Mode (HTTP Long-Polling)" as LP {
        [*] --> Polling
        Polling: Higher latency messaging
        Polling --> Polling: Receives message or timeout
    }

    HP --> LP: Network Quality Degrades or Server Load High
    LP --> HP: Network Quality Restored

6. Combination Prior Art with Open-Source Standards

6.1. Combination with Matrix Protocol for Federated, E2E-Encrypted Chat

Enabling Description: The system acts as a specialized "bridge" or "application service" within the open, federated Matrix communication network. An unauthenticated web user's first communication request is received by the system. Instead of creating a proprietary session, the system uses the Matrix Client-Server API to dynamically create a new, temporary Matrix user account (e.g., @guest-12345:_server.com) and a new encrypted chat room. The first conversation identifier is the Matrix internal room ID (!randomstring:_server.com). A human or bot responder, who has a permanent Matrix account, is invited to this room. All communications are now end-to-end encrypted and can be relayed across the global Matrix federation. For a second user on a different protocol like SMS, the system performs a similar function, bridging the SMS messages into a different Matrix room with its own unique room ID (second conversation identifier).

6.2. Combination with WebRTC for Post-Handshake Peer-to-Peer Media

Enabling Description: The system described in patent 11418466 is used as a signaling server to bootstrap a peer-to-peer WebRTC connection. An unauthenticated web user initiates a chat. The system creates a first conversation identifier and manages the initial text-based handshake between the user and a responder. If the user and responder agree to escalate to a voice or video call, they exchange WebRTC session descriptions (SDP) and ICE candidates through the existing, server-brokered chat channel. Once the signaling is complete, a direct, peer-to-peer, encrypted media connection is established between the user's browser and the responder's browser using the WebRTC standard. The central server is no longer in the path of the media stream, saving bandwidth and improving privacy, but it can still use the first conversation identifier to manage the associated text chat or terminate the session.

6.3. Combination with OpenID Connect for Progressive Authentication

Enabling Description: The system allows a conversation to begin with an unauthenticated user, creating a first conversation identifier to manage the anonymous session. During the conversation, the user may be prompted to log in to access more features (e.g., view order history). The user clicks a "Login" button, which initiates an OpenID Connect (OIDC) authentication flow with a third-party Identity Provider (e.g., Google, Okta). Upon successful authentication, the OIDC provider returns an ID Token to the system. The system then associates the pre-existing anonymous session (identified by the first conversation identifier) with the user's now-verified, persistent identity (e.g., their OIDC sub claim). The conversation continues seamlessly, but the user is now authenticated, and the system can provide personalized services. This creates a "progressive authentication" workflow built on an open standard.