Derivative works — US Patent 11336597

Here is the comprehensive "Defensive Disclosure" document for US Patent 11,336,597, designed to establish prior art against future incremental inventions.

Defensive Publication & Prior Art Disclosure

Title: Systems and Methods for Dynamic, Multi-Protocol, and Decentralized Communication Routing for Anonymous Participants
Publication Date: April 28, 2026

Abstract: This publication discloses a series of enhancements, alternative implementations, and novel applications of a system that facilitates communication between an unauthenticated user on a first platform and one or more responders on disparate platforms. The disclosures herein build upon the concept of a multi-stage responder handoff (e.g., from an automated first responder to a human second responder) by introducing variations in architecture, operational parameters, cross-domain use cases, and integration with emerging technologies. These disclosures are intended to enter the public domain and serve as prior art for any future patent applications in this domain.

Derivative Set 1: Architectural & Component Substitutions

1.1. Decentralized Responder Network via Distributed Hash Table (DHT)

Enabling Description: The centralized server architecture for storing and matching responder criteria is replaced with a decentralized model using a Distributed Hash Table (DHT) based on the Kademlia algorithm. Each responder client, upon becoming available, computes a hash of its expertise keywords (e.g., "tax law," "New York," "Spanish") and availability schedule. It then stores its contact information (e.g., xmpp:expert@domain.com) and a signed timestamp at the DHT node(s) corresponding to these hashes. When an unauthenticated user initiates a request, the intermediary server hashes the user's query terms and queries the DHT to find the closest nodes, retrieving a list of available, relevant responders. The "first responder" can be a bot that helps the user refine their query to generate more effective hashes for the DHT lookup. This architecture eliminates the central database as a single point of failure and censorship.

Mermaid Diagram:

sequenceDiagram
    participant User
    participant Intermediary
    participant DHT Network
    participant ResponderA
    participant ResponderB

    User->>Intermediary: Start Conversation (Topic: "Tax Law")
    Intermediary->>Intermediary: Hash("Tax Law") -> Key
    Intermediary->>DHT Network: find_node(Key)
    DHT Network-->>Intermediary: Return Peers (ResponderA, ResponderB)
    Intermediary->>ResponderA: Route User Message (SMS)
    ResponderA-->>Intermediary: Reply (SMS)
    Intermediary-->>User: Display Reply

1.2. Serverless Function-Based Architecture

Enabling Description: The entire communication proxy is implemented using a serverless, event-driven architecture (e.g., AWS Lambda). A request from the user's web browser triggers an API Gateway endpoint, which invokes a receiveRequest function. This function creates a conversation ID and places the request onto a message queue (e.g., SQS). A findFirstResponder function is triggered, which invokes a chatbot service. The chatbot's interaction is managed by a manageFirstResponse function. Once the user is qualified, the chat service emits a qualifedUser event to a topic (e.g., SNS). A findSecondResponder function subscribes to this topic, queries a database (e.g., DynamoDB) for an expert, and invokes a protocol-specific routeMessage function (e.g., sendSMS, sendEmail). Replies are sent to dedicated endpoints that invoke a receiveReply function, which uses the conversation ID to push the message back to the user via a WebSocket connection.

Mermaid Diagram:

graph TD
    A[User Browser via API Gateway] --> B(Lambda: receiveRequest);
    B --> C{Message Queue};
    C --> D(Lambda: processRequest);
    D --> E[First Responder: Chatbot Service];
    E --> F(Lambda: manageFirstResponse);
    F -- Qualified --> G{Event Topic};
    G --> H(Lambda: findSecondResponder);
    H --> I[Responder DB];
    H --> J(Lambda: routeToResponder);
    J -- SMS/Email --> K[Second Responder];
    K -- Reply --> L(Lambda: receiveReply);
    L -- via WebSocket --> A;

1.3. Localized Edge-Compute First Responder

Enabling Description: To minimize initial latency, the "first responder" function is deployed as a lightweight containerized application on a global edge computing network (e.g., Cloudflare Workers or Fastly Compute@Edge). When a user initiates a chat, their request is routed to the nearest edge node. This edge application provides the initial automated chat interaction, gathering necessary information. Once the user is qualified, the edge application makes a single API call to the centralized "second responder" routing system, passing the conversation ID, transcript, and qualified topic. The central system then takes over routing to the human expert, while the user's connection remains with the low-latency edge node for message display.

Mermaid Diagram:

sequenceDiagram
    participant User
    participant EdgeNode
    participant CentralRouter
    participant SecondResponder

    User->>EdgeNode: Initiate Chat
    EdgeNode->>User: First Responder Interaction (Low Latency)
    User->>EdgeNode: Provides Info
    EdgeNode->>CentralRouter: Request Second Responder (Payload: ConvID, Transcript)
    CentralRouter->>SecondResponder: Route Message
    SecondResponder-->>CentralRouter: Reply
    CentralRouter-->>EdgeNode: Forward Reply
    EdgeNode-->>User: Display Reply

Derivative Set 2: Operational Parameter Expansion

2.1. Nanoscale Lab-on-a-Chip (LOC) Diagnostic Routing

Enabling Description: The system manages asynchronous tasks on a microfluidic "lab-on-a-chip" device. The "unauthenticated user" is a biosensor that detects the presence of a specific protein and sends a signal via an I2C bus. The "first responder" is the LOC's onboard microcontroller, which runs an initial signal classification algorithm. If the signal is ambiguous, the microcontroller (first responder) identifies a "second responder"—a different set of sensors optimized for a secondary assay (e.g., fluorescence detection). It opens a microfluidic valve to route the sample to the second location and triggers the second sensor array. The response from the second array is mapped back to the initial event using a timestamp-based conversation ID.

Mermaid Diagram:

stateDiagram-v2
    [*] --> Sensor1_Detects_Analyte
    Sensor1_Detects_Analyte --> MCU_FirstResponse: I2C Signal
    MCU_FirstResponse: Classify Signal
    MCU_FirstResponse --> Ambiguous: Signal Unclear
    Ambiguous --> RouteToSensor2: Open Valve
    RouteToSensor2 --> Sensor2_SecondResponse: Activate Assay
    Sensor2_SecondResponse --> Report_Result
    MCU_FirstResponse --> Clear: Signal Classified
    Clear --> Report_Result
    Report_Result --> [*]

2.2. High-Frequency Trading (HFT) Anomaly Routing

Enabling Description: The system is implemented in hardware (FPGA) for ultra-low latency market data processing. The "initiator" is a pattern-matching module that detects a potential arbitrage opportunity in the market data stream (sub-microsecond). The "first responder" is a pre-trade risk check module on the same FPGA, which verifies the trade against compliance and risk limits in nanoseconds. If the check passes, it identifies the "second responder"—a specific execution algorithm module. It forwards the trade parameters to the execution module via a direct memory interface. The execution module's fill/reject report is the "reply," which is mapped back to the original opportunity event using a unique hardware-generated identifier.

Mermaid Diagram:

graph TD
    subgraph FPGA
        A[Market Data Ingest] --> B{Pattern Matcher};
        B -- Opportunity Detected --> C[First Responder: Risk Check];
        C -- Check OK --> D[Second Responder: Execution Algo];
        D --> E[FIX Gateway Out];
        E -- Fill Report --> F{Response Mapper};
        C -- Check Fail --> F;
        B -- No Match --> A;
    end
    F --> G[Log];

Derivative Set 3: Cross-Domain Applications

3.1. Aerospace: In-Flight Anomaly Reporting

Enabling Description: The system is embedded in an aircraft's In-Flight Entertainment (IFE) and cabin management network. A passenger pressing the "call attendant" button on their seat initiates the request. The "first responder" is the central IFE server, which presents options on the user's screen ("Drink," "Assistance," "Medical"). Based on the selection, the system identifies the appropriate "second responder." A "Drink" request is routed to the galley's crew terminal (e.g., via a message on their tablet). A "Medical" request is routed simultaneously to all crew terminals and logged with high priority in the cabin log. The crew member's acknowledgment of the request on their terminal is the "reply," which turns off the call light at the user's seat.

Mermaid Diagram:

flowchart LR
    User(Seat 14B) -- Call Button --> IFE_Server{First Responder};
    IFE_Server --> Screen[Display Options];
    User -- Selects 'Medical' --> IFE_Server;
    IFE_Server -- High Priority --> Galley_Terminal(Second Responder 1);
    IFE_Server -- High Priority --> Cockpit_Terminal(Second Responder 2);
    Galley_Terminal -- Ack --> IFE_Server;
    IFE_Server -- Update Status --> User_Light_Off(Seat Light Off);

3.2. AgTech: Precision Agriculture Irrigation Management

Enabling Description: The system is a cloud service connected to a farm's LoRaWAN network. A soil moisture sensor ("initiator") reports a dry condition. The LoRaWAN network server ("first responder") receives this data and validates it against data from adjacent sensors and weather forecast data to rule out a sensor fault. If the dry condition is confirmed, the server identifies the "second responder"—the irrigation controller for that specific zone. It sends a command via MQTT to the controller to begin a watering cycle. The controller's confirmation that the cycle has started is the "reply," which updates the system dashboard.

Mermaid Diagram:

sequenceDiagram
    participant Sensor
    participant LoRaWAN_Server as First Responder
    participant Weather_API
    participant Irrigation_Controller as Second Responder

    Sensor->>LoRaWAN_Server: Report Low Moisture
    LoRaWAN_Server->>Weather_API: Check Rain Forecast
    LoRaWAN_Server->>LoRaWAN_Server: Validate Data
    LoRaWAN_Server->>Irrigation_Controller: MQTT: start_cycle(zone=4)
    Irrigation_Controller-->>LoRaWAN_Server: MQTT: ack(zone=4)

Derivative Set 4: Integration with Emerging Technologies

4.1. AI-Driven Predictive Responder Selection

Enabling Description: The second responder selection logic is replaced with a pre-trained transformer-based AI model (e.g., BERT). The model is trained on millions of past conversations and their outcomes (e.g., resolution time, user satisfaction). When a user completes the interaction with the "first responder" (chatbot), the entire transcript is vectorized and fed into the AI model. The model outputs a ranked list of available second responders, each with a predicted "success probability." The system routes the request to the responder with the highest score. The model continuously re-trains on new conversations, adapting to changes in responder skill and user query patterns.

Mermaid Diagram:

graph TD
    A[User Transcript] --> B(Vectorize Text);
    B --> C[AI Prediction Model];
    C --> D{Ranked List of Responders};
    D -- Top Ranked --> E(Route to Best Responder);
    subgraph Feedback Loop
        F[Conversation Outcome] --> G(Update Training Data);
        G --> H(Re-train Model);
    end
    E --> F;

4.2. Blockchain for Verifiable Conversation Audits

Enabling Description: For regulated industries, the system logs conversation events to a permissioned blockchain (e.g., Hyperledger Fabric). The initiation of a conversation creates a genesis block for that conversation's unique asset ID. Each subsequent message—from user to system, system to responder, and back—is a transaction that is cryptographically signed by the processing component and added to the chain. The identity of the user and responder are replaced by pseudonymous one-time-use keys, preserving anonymity. This provides a tamper-proof, immutable audit trail for regulators without storing sensitive PII on the blockchain itself.

Mermaid Diagram:

erDiagram
    CONVERSATION ||--o{ BLOCK : contains
    CONVERSATION {
        string conversationID PK
        datetime startTime
    }
    BLOCK {
        string blockHash PK
        string conversationID FK
        string previousHash
        datetime timestamp
        string eventPayload
        string signature
    }

Derivative Set 5: Inverse & Failure Mode Operation

5.1. Graceful Degradation to Asynchronous Ticketing

Enabling Description: The system includes a real-time availability check for second responders. If the routing logic queries the responder database and finds zero available responders who match the criteria, it triggers a "degradation" workflow. The "first responder" (chatbot) is dynamically reconfigured with a new dialogue tree. It informs the user that no live agents are available and presents a form to collect the user's email address and a more detailed problem description. Upon submission, the system packages the chat transcript and the form data, creates a ticket in an external helpdesk system (e.g., Zendesk) via API, and uses the new ticket number as the persistent conversation identifier.

Mermaid Diagram:

stateDiagram-v2
    state "Real-time Chat" as Chat
    state "Asynchronous Ticketing" as Ticket

    [*] --> Chat
    Chat: User interacts with First Responder
    Chat --> Chat: Second Responders available
    Chat --> Ticket: No Second Responders available

    Ticket: Collect user email and details
    Ticket --> [*]: Ticket created in Helpdesk

Combination Prior Art with Open-Source Standards

1. Combination with Matrix Protocol

Enabling Description: The system is implemented as a Matrix Application Service. An unauthenticated user on a website uses a client that communicates with the Application Service, which creates a new, encrypted Matrix room for the session. The Application Service's user ID (the "first responder") automatically joins and greets the user. After analyzing the user's initial messages, the Application Service uses the Matrix protocol to invite the appropriate human expert (identified by their Matrix ID, e.g., @expert_jane:company.com) into the room as the "second responder." The conversation continues within the standard, end-to-end encrypted Matrix room, with the Application Service bridging messages if the second responder uses a different protocol (e.g., SMS, via a separate bridge). The Matrix Room ID (!randomstring:company.com) serves as the permanent, globally unique conversation identifier.

2. Combination with ActivityPub Protocol (Fediverse)

Enabling Description: The system functions as a customer support bridge for the Fediverse. A company runs an ActivityPub server with a dedicated support actor (e.g., @support@brand.com). A user on a web form initiates a request. The system converts this request into a new Create activity containing a Note object and posts it to the support actor's outbox, addressed only to the support actor itself (making it private). A "first responder" service monitors this outbox, processes the Note, and then forwards it to the appropriate "second responder" (e.g., @tech_support@brand.com) by sending an Announce activity. The URI of the original Note object serves as the conversation identifier, and all replies use the inReplyTo field, creating a federated, yet privately routed, conversation thread.

3. Combination with SIP and ENUM

Enabling Description: The system is an advanced SIP Proxy that leverages ENUM for dynamic routing. When a web user starts a chat, the system allocates a temporary E.164 number (a phone number) from a pool to serve as the conversation ID. The "first responder" is a SIP-based chatbot (a User Agent Client). When the user needs to be escalated, the system performs an ENUM query on the allocated number. The ENUM record, pre-populated by the responder, returns a set of URIs for that responder's preferred contact methods (e.g., sip:expert@company.com, mailto:expert@company.com, sms:+15551234567). The system selects the appropriate URI based on presence information (e.g., the SIP agent is online) and forwards the message via the corresponding gateway (e.g., a SIP-to-SMS gateway). All subsequent messages are routed using the allocated E.164 number as the identifier.