Derivative works — US Patent 11240183

Defensive Disclosure for U.S. Patent 11,240,183

Publication Date: April 28, 2026
Subject: Derivative Implementations and Obvious Variations of Asymmetric, Multi-Protocol Communication Systems.

This document discloses a series of methods, systems, and architectural variations related to the core concepts described in U.S. Patent 11,240,183. The purpose of this disclosure is to establish prior art for subsequent or incremental inventions in this domain. The following descriptions are intended to be enabling for a person having ordinary skill in the art (POSITA).

Axis 1: Material & Component Substitution

1.1. Derivative: Decentralized Identity (DID) & Verifiable Credential (VC) Based Routing

Enabling Description: This variation replaces the centralized server and conversation identifier (CID) with a decentralized identity framework based on W3C standards for DIDs and VCs. An unauthenticated user interacts with a web application that functions as a temporary DID wallet. The "first responder" is a smart contract or automated service that, upon receiving the user's initial communication (e.g., answers to a form), issues a temporary, anonymous Verifiable Credential containing the conversation topic and a unique nonce. The user's application then presents this VC to a decentralized network of "second responders." Responders can verify the credential's authenticity and, if their service criteria match the VC's claims, initiate a secure, peer-to-peer communication channel (e.g., using DIDComm). The conversation is mapped via the VC's nonce, and the responder's DID remains pseudonymous, preserving anonymity.

sequenceDiagram
    participant UserApp as User Application (Web)
    participant FirstResponder as VC Issuing Service
    participant DIDLedger as Verifiable Data Registry
    participant SecondResponder as Service Provider

    UserApp->>FirstResponder: Initial communication (query)
    activate FirstResponder
    FirstResponder->>DIDLedger: Register temporary DID/VC
    FirstResponder-->>UserApp: Issue anonymous Verifiable Credential (VC)
    deactivate FirstResponder

    UserApp->>SecondResponder: Present VC to request service
    activate SecondResponder
    SecondResponder->>DIDLedger: Verify VC authenticity
    SecondResponder-->>UserApp: Open secure DIDComm channel
    UserApp->>SecondResponder: Conversation continues...
    deactivate SecondResponder

1.2. Derivative: Distributed Pub/Sub Messaging Backbone

Enabling Description: This architecture eliminates a monolithic central server in favor of a distributed publish-subscribe messaging system, such as one built on IPFS Pubsub, MQTT, or Apache Kafka. The unauthenticated user's browser, via a gateway, publishes their initial message to a general, high-level topic (e.g., /support/initial_requests). A "first responder" bot, subscribed to this topic, receives the message and replies with a clarifying question. The user's answer is analyzed by the bot, which then directs the user to publish subsequent messages to a more specific, fine-grained topic (e.g., /support/billing/tier1). "Second responders" (specialized agents) are subscribed only to these specific topics. The Conversation Identifier (CID) is the hash of the initial message or a session UUID that is included in the message payload. Anonymity is maintained as subscribers to a topic do not know the identity of publishers.

graph TD
    A[User via Web Gateway] -- 1. Publishes initial query --> B(Topic: /support/initial_requests);
    C[First Responder Bot] -- 2. Subscribed to topic --> B;
    C -- 3. Publishes clarifying question --> B;
    A -- 4. Publishes answer --> B;
    C -- 5. Analyzes answer & determines new topic --> D(Topic: /support/billing/tier1);
    C -- 6. Instructs user to switch to new topic --> A;
    A -- 7. Publishes ongoing conversation --> D;
    E[Second Responder] -- 8. Subscribed to specific topic --> D;
    E -- 9. Publishes reply --> D;

Axis 2: Operational Parameter Expansion

2.1. Derivative: Massive-Scale, Resilient System for Emergency Response

Enabling Description: This system is designed for massive, concurrent ingestion of requests during a large-scale emergency. Initiators use low-bandwidth web clients or SMS. The "first responder" is a globally distributed network of serverless functions (e.g., Cloudflare Workers) at the edge, which performs Natural Language Processing (NLP) for initial triage and categorization. Instead of routing to a single agent, the categorized request and a generated CID are published as a message to a geo-partitioned, high-throughput message queue (e.g., Apache Pulsar). "Second responders" are pools of human agents using a client application that pulls messages from their assigned regional queue partition. This decouples ingestion from processing, allowing the system to absorb millions of requests per minute without dropping traffic, prioritizing availability and durability over low latency. The conversation is stateful within the message payload itself.

graph LR
    subgraph Edge Ingestion
        U1(User 1) --> FN1(Serverless Function);
        U2(User 2) --> FN2(Serverless Function);
        U3(User N) --> FN3(Serverless Function);
    end
    subgraph Message Bus
        FN1 -- NLP Triage --> Q1(Pulsar Geo-Partition 1);
        FN2 -- NLP Triage --> Q2(Pulsar Geo-Partition 2);
        FN3 -- NLP Triage --> Q1;
    end
    subgraph Responder Pools
        Q1 --> R1(Agent Pool Region 1);
        Q2 --> R2(Agent Pool Region 2);
    end

2.2. Derivative: Ultra-Low Latency Industrial Control Handoff

Enabling Description: This system is architected for hard real-time industrial environments where handoff latency is critical. An unauthenticated initiator is a remote diagnostic client monitoring a physical asset. The "first responder" is a local edge controller executing a control loop. The "first communication" is a sensor reading that deviates from a predicted model. The edge controller determines it cannot resolve the anomaly within its programmed logic and must hand off to a human supervisor (the "second responder"). The conversation is ended locally, and the full state vector (sensor data, model deviation, CID) is encapsulated in a UDP packet and forwarded over a high-priority QoS network or a WebRTC data channel to the supervisor's console. The total handoff time from detection to reception by the supervisor must be under 50 milliseconds. The supervisor's reply is a control command sent back over the same channel, which the edge controller executes.

sequenceDiagram
    participant DiagClient as Diagnostic Client
    participant EdgeController as First Responder
    participant Supervisor as Second Responder

    loop Real-time Monitoring
        DiagClient->>EdgeController: Sensor Data
    end
    EdgeController->>EdgeController: Detects Anomaly (Deviation > Threshold)
    Note over EdgeController: Handoff required, <50ms budget
    EdgeController->>Supervisor: UDP Packet (State Vector + CID)
    activate Supervisor
    Supervisor-->>EdgeController: Control Command Packet (e.g., 'Shutdown')
    deactivate Supervisor
    EdgeController->>DiagClient: Execute command & relay status

Axis 3: Cross-Domain Application

3.1. Derivative: Aerospace - Autonomous Drone Swarm Anomaly Management

Enabling Description: A drone in a swarm acts as the "initiator." Its onboard flight controller ("first responder") continuously runs diagnostics. Upon detecting an anomaly (e.g., excessive IMU drift), it answers an internal query, confirming the fault. This local conversation ends. The drone then broadcasts a help request containing the fault code and its unique drone ID (the CID) to the swarm's decentralized network. A specialized "second responder" drone—a designated 'mechanic' drone with advanced diagnostic software—receives the request. It establishes a direct, low-latency communication link, analyzes the full telemetry, and sends back a corrective action (e.g., 'recalibrate IMU in-flight' or 'initiate safe landing protocol'). The communication is routed via drone IDs, so the mechanic drone's specific address is abstracted away.

stateDiagram-v2
    [*] --> Healthy: Power On
    Healthy --> AnomalyDetected: IMU Drift > Threshold
    AnomalyDetected: Flight Controller (First Responder) confirms fault
    AnomalyDetected --> RequestingHelp: Broadcasts help request (CID=DroneID)
    RequestingHelp --> ReceivingAid: 'Mechanic' Drone (Second Responder) connects
    ReceivingAid --> Healthy: Corrective command received and executed
    ReceivingAid --> SafeLanding: 'Land' command received
    SafeLanding --> [*]

Axis 4: Integration with Emerging Tech

4.1. Derivative: AI-Optimized Responder Selection

Enabling Description: This system enhances the selection of the "second responder" using a pre-trained AI model (e.g., a transformer-based classifier or a reinforcement learning agent). The "first responder" is a conversational AI that elicits the user's problem and extracts key entities, intent, and sentiment. This structured data forms an input vector for the AI model. The model's output is a ranked list of the most suitable "second responders," factoring in their skills, current availability, language, and historical success rates for similar problems. The system then routes the conversation (with CID and history) to the top-ranked, available responder. This replaces static, rule-based routing with dynamic, performance-optimized routing.

flowchart TD
    A[User's Initial Text] --> B{Conversational AI<br/>(First Responder)};
    B -- Extracts Features --> C[Input Vector<br/>(Intent, Entities, Sentiment)];
    C --> D{AI Routing Model<br/>(Reinforcement Learning Agent)};
    D -- Chooses Best Responder --> E[Route to Responder X via SMS];
    D -- Chooses Best Responder --> F[Route to Responder Y via XMPP];
    D -- Chooses Best Responder --> G[Route to Responder Z via Email];

4.2. Derivative: Blockchain-Audited Secure Handoff

Enabling Description: This variation is designed for highly regulated interactions (e.g., financial advice, telehealth). The conversation flow is managed by a smart contract on a permissioned blockchain (e.g., Hyperledger Fabric). The CID is the initial transaction hash. The "first responder" (a bot or triage agent) records the initial query on the ledger. When a "second responder" (a certified professional) is identified, the smart contract executes a state change, transferring "ownership" of the conversation to the second responder's public key. All subsequent messages are encrypted with the appropriate key and their hashes are logged to the chain. This creates an immutable, auditable, and non-repudiable record of the entire conversation and the handoff, while preserving the content's privacy and the responder's off-chain anonymity.

classDiagram
    class SmartContract {
        +string conversationId
        +address initiator
        +address firstResponder
        +address secondResponder
        +enum status { INITIATED, HANDOFF, CLOSED }
        +initiate(string initialQuery)
        +handoff(address newResponder)
        +logMessage(bytes32 messageHash)
    }
    class User {
        +publicKey
        +interactsWith()
    }
    class Responder {
        +publicKey
        +isCertified()
    }
    User -- "1" SmartContract
    Responder -- "2" SmartContract

Axis 5: The "Inverse" or Failure Mode

5.1. Derivative: Graceful Degradation to Asynchronous Ticketing

Enabling Description: The system is designed with a failover mode for when no real-time "second responders" are available. After the "first responder" (automated or human) gathers the initial information, it queries the responder pool. If it receives no acknowledgments within a set timeout (e.g., 60 seconds), the system's mode flips from "real-time chat" to "asynchronous ticketing." It sends a message to the user's web browser: "All agents are currently busy. Your request has been saved as ticket # [CID]. We will email you a reply." The entire conversation history is then packaged and sent to a standard email-based ticketing system (e.g., Zendesk, Jira Service Desk), ensuring the request is not lost and setting a correct expectation for the user.

stateDiagram-v2
    state "Real-time Mode" as Realtime
    state "Asynchronous Mode" as Async

    [*] --> Realtime: Conversation starts
    Realtime --> Realtime: First responder gathers info
    Realtime --> Handoff: Querying responder pool
    Handoff --> Realtime: Responder acknowledges
    Handoff --> Async: Timeout (no acks)
    Async: Save conversation to ticket system, notify user
    Async --> [*]: Ticket Created

Combination Prior Art Scenarios

Combination with IETF MLS (Messaging Layer Security): The system operates within an MLS group chat protocol. The initiator and a server bot ("first responder") form an initial two-member group. Based on the initiator's input, the server bot invites a suitable expert ("second responder") into the group and then removes itself. The conversation's state, including its unique ID, is the MLS group's state. The handoff is an atomic add and remove operation in the group, creating a new epoch. This provides end-to-end encrypted, forward-secret communication directly between the initiator and the second responder after the handoff, with the server mediating only the initial setup.
Combination with Mastodon/ActivityPub: A specialized ActivityPub server (a "HelpDesk instance") acts as the communication backbone. A user posts a request ("first communication") which is a Create Note activity directed at a bot ("first responder"). The bot replies with a Question activity. The user's answer triggers the bot to Announce (boost) the original post to a curated list of followers—the "second responders." A second responder replies to the boosted post. The HelpDesk instance intercepts this reply and routes it back to the original user's web session, using the original Note's URI as the CID. The second responder's real account handle is replaced with a generic one (e.g., "Support Agent").
Combination with WebRTC and STUN/TURN: The system leverages WebRTC for peer-to-peer communication, obviating the need for the central server to proxy message content. The "first responder" is a signaling server that sets up an initial WebRTC DataChannel between the user's browser and itself. After gathering information via this channel, it identifies a "second responder." The signaling server then initiates a new peer connection negotiation between the user's browser and the second responder's WebRTC-enabled client, using STUN/TURN to traverse NATs. Once the peer-to-peer DataChannel is established between them, the initial connection to the signaling server is terminated. The CID is the unique ID of the WebRTC session. This maintains anonymity (peers only see transient IP:port pairs) and moves the data load off the central infrastructure.