US 11349787

An analysis of U.S. Patent 11,349,787 reveals a system for enabling real-time, anonymous communication between a user on a website and one or more responders who may be using different communication platforms. The patent is assigned to Disintermediation Services Inc., a company that has been involved in litigation related to this patent family.

Patent Details:

• Title: Two-way real time communication system that allows asymmetric participation in conversations across multiple electronic platforms
• Assignee: Disintermediation Services Inc
• Inventors: John Patrick Francis DANDISON, James Allen Johnson, Paul Joseph Lyman Schottland
• Filing Date: January 11, 2022
• Issue Date: May 31, 2022
• Abstract: The patent describes methods and systems for a web browser of an unauthenticated user to receive a communication as part of a conversation. A conversation identifier is established based on this initial communication. The system then identifies a first responder, their communication protocol, and their address. The initial communication is forwarded to the responder, and their reply is received. This reply is then mapped back to the web browser using the conversation identifier and sent to the user.

Independent Claims Overview:

The patent asserts two independent claims, one for a system and one for a method, which are foundational to the invention.

• Claim 1 (System): This claim outlines a system with an electronic processor that facilitates a web-based conversation. The process begins when an unauthenticated user on a webpage initiates a communication request. A "first responder" sends an information request to the user to start the conversation. When the user responds, the system generates a unique conversation identifier. It then stores the initial request and the user's response, linking them with this identifier. If the user's web browser later requests the conversation history, the system uses the conversation ID to retrieve the stored messages and send them to the browser.

• Claim 17 (Method): This claim details the operational steps a processor would take to execute the communication system. It mirrors the functionality of Claim 1, describing the actions of receiving a communication request from an anonymous user, having a "first responder" initiate a conversation, receiving the user's reply, creating a unique identifier for the conversation, and storing the messages with that ID. The method also includes retrieving and transmitting the conversation history to the user's browser upon request.

Litigation and CAFC Docket:

While a direct search of the U.S. Court of Appeals for the Federal Circuit (CAFC) 2026 dockets for this specific patent number did not yield immediate results, the assignee, Disintermediation Services Inc., has been a party in various patent infringement lawsuits involving the technology described in this patent family. A conclusive determination of any specific 2026 CAFC proceedings would necessitate a direct search of official court dockets.

Litigation Involving U.S. Patent 11,349,787

As of April 28, 2026, the assignee of U.S. Patent 11,349,787, Disintermediation Services, Inc., has been actively asserting this patent in litigation against various companies. Below is a summary of known legal cases involving this specific patent.

---

Disintermediation Services, Inc. v. Perq Software, LLC

• Plaintiff: Disintermediation Services, Inc.
• Defendant: Perq Software, LLC
• Jurisdiction: U.S. District Court for the Southern District of Indiana
• Case Number: Information not publicly available in search results.
• Filing Date: March 21, 2023
• Status/Outcome: The complaint alleges that Perq Software's AI leasing assistant and website conversion tools infringe on U.S. Patent 11,349,787 and U.S. Patent 11,418,466, either literally or under the doctrine of equivalents. Disintermediation Services, Inc. is seeking declaratory judgments, damages, pre- and post-judgment interest, attorney fees, and a compulsory ongoing license fee. The current status of this case is pending.

---

Disintermediation Services, Inc. v. LiveAdmins, LLC

• Plaintiff: Disintermediation Services, Inc.
• Defendant: LiveAdmins, LLC
• Jurisdiction: U.S. District Court for the Northern District of Illinois
• Case Number: 1:2022cv06539
• Filing Date: 2022
• Status/Outcome: The case is ongoing. Court documents indicate proceedings as of May 16, 2024, but the ultimate outcome has not yet been determined.

---

Intercom, Inc. v. Disintermediation Services, Inc.

• Plaintiff: Intercom, Inc.
• Defendant: Disintermediation Services, Inc.
• Jurisdiction: U.S. District Court for the District of Delaware
• Case Number: 1:2025cv00619
• Filing Date: 2025
• Status/Outcome: This is a more recent case, and as of the last docket retrieval on September 9, 2025, it is still in the early stages of litigation.

---

Additional Litigation Context

Disintermediation Services, Inc. has been involved in numerous patent infringement lawsuits concerning the patent family to which the '787 patent belongs. The "Litigation" section of the Google Patents page for U.S. Patent 11,349,787 lists multiple cases filed across various U.S. District Courts, including in Texas, Michigan, Ohio, California, Pennsylvania, and Indiana. These cases suggest a broad and active enforcement campaign by the patent holder. While a detailed status for each case requires a direct PACER search, the volume of litigation indicates the patent's significance to its owner.

Proceedings Overview

As of May 30, 2026, a review of the USPTO Open Data Portal and supplementary web searches indicates that there are no active or concluded AIA trial proceedings (Inter Partes Review, Post-Grant Review, or Covered Business Method review) on file for U.S. Patent 11,349,787. This means the patent has not been subjected to PTAB challenges regarding the validity of its claims.

Strategic Summary

Currently, all claims of U.S. Patent 11,349,787 remain untested by the PTAB. There are no claims that have been canceled or sustained through IPR, PGR, or CBM proceedings. This implies that the patent has not been narrowed by these administrative challenges, and its full scope as granted by the USPTO remains intact from a PTAB perspective.

Since there are no PTAB proceedings, the estoppel landscape under 35 U.S.C. § 315(e)(2) is not applicable to this patent. For a defendant facing assertion of this patent, any prior-art grounds, whether previously cited during prosecution or newly discovered, are still available for potential invalidity challenges in district court or, if applicable, through a future PTAB petition.

The absence of PTAB activity is a notable signal. Patents that are actively asserted in district court litigation often become targets for IPRs by defendants seeking to challenge validity in a more expedited and often less expensive forum. While the patent family has been involved in multiple district court litigations (as outlined in the "Litigation summary"), the '787 patent itself has not yet attracted a PTAB challenge, according to the available data. This could indicate various factors, such as pending litigation discovery not yet yielding strong PTAB prior art, or strategic decisions by defendants to focus on other invalidity avenues or settlement.

Recommended Next Steps

Given that no PTAB activity exists for U.S. Patent 11,349,787, a defendant facing assertion of this patent should consider the following:

• Prior Art Search: Conduct a comprehensive prior art search to identify strong invalidity references that could form the basis of an IPR petition. The prior art cited during the patent's prosecution (e.g., US 9,413,812; US 8,364,741; US 8,930,480; US 2011/0040854 A1) provides a starting point, but a new, more targeted search may reveal stronger, uncited references.
• IPR Feasibility Analysis: If robust prior art is identified, perform a thorough analysis to determine the strength of an IPR petition against the asserted claims, considering the legal standards for institution and final written decision at the PTAB.
• Timing Considerations: Be mindful of the one-year statutory bar for IPR petitions, which generally prohibits a petitioner from filing an IPR more than one year after being served with a complaint alleging infringement of the patent.
• Litigation Strategy Integration: Coordinate any potential PTAB strategy with the ongoing district court litigation strategy, weighing the benefits of PTAB review against potential Fintiv discretionary denials (though recent policy shifts may impact this) and the impact of PTAB proceedings on the district court schedule.

Inventors

• John Patrick Francis DANDISON (Employer at filing: Disintermediation Services Inc.)
• James Allen Johnson (Employer at filing: Disintermediation Services Inc.)
• Paul Joseph Lyman Schottland (Employer at filing: Disintermediation Services Inc.)

All inventors were employed by the original assignee, Disintermediation Services Inc., at the time of filing.

Original assignee

The entity named on the issued patent is Disintermediation Services Inc.

Disintermediation Services Inc.'s primary line of business, as suggested by the patent title and related litigation, revolves around "disintermediation" in communication, aiming to cut out middlemen in various industries by enabling direct real-time communication between parties. While the term "disintermediation" itself refers to removing intermediaries, Disintermediation Services Inc. appears to be an entity that asserts patents related to this concept rather than a company directly shipping products embodying the claims as a core business. There is no clear evidence of Disintermediation Services Inc. directly marketing or selling a product or service named "Two-way real time communication system that allows asymmetric participation in conversations across multiple electronic platforms" or a similar commercial offering. Instead, their activity primarily appears to be patent assertion. For example, recent reports identify Disintermediation Services, Inc. as a frequent filer in patent litigation against various companies, often categorized as a Non-Practicing Entity (NPE).

The current status of Disintermediation Services Inc. is operating, as evidenced by its ongoing involvement in litigation as recent as 2025 and 2026.

Assignment timeline

• 2022-04-19 (executed) / recorded 2022-04-19 — Reel 059535/0081
  • Conveyance: Assignment
  • Assignor: DANDISON, JOHN PATRICK FRANCIS, SCHOTTLAND, PAUL JOSEPH LYMAN, JOHNSON, JAMES ALLEN
  • Assignee: Disintermediation Services, Inc.
  • Correspondent: GILLAM & SMITH, L.L.P., 303 SOUTH BROADWAY, SUITE 210, TYLER, TX, 75702. This correspondent also appears in the Perq Software and Kroger litigation.
  • Context: Transfer of inventors' interest to the original assignee.

Timeline diagram

timeline
    title Ownership of US 11349787
    2011 : Provisional application filed
    2012 : Earliest non-provisional application filed
    2022 : Inventors assigned to Disintermediation Services Inc
         : Patent issued

NPE / troll-pattern signals

1. Shell-entity transfer — unclear. While Disintermediation Services Inc. has been identified as a frequent filer in patent litigation and an NPE by third-party reports, the initial assignment is from the inventors to the company that is also the original assignee on the patent. This single assignment does not explicitly show a transfer from an operating company to a shell entity. However, the nature of Disintermediation Services Inc.'s business as primarily patent assertion suggests it operates as an NPE.
2. Known asserter in the chain — present. Disintermediation Services Inc. is identified as the current assignee and has been involved in extensive patent litigation, often characterized as a Non-Practicing Entity (NPE). The Google Patents page for US11349787 lists multiple litigation cases involving Disintermediation Services Inc. across various district courts.
3. Repeat correspondent across the chain — present. The correspondent listed for the assignment on 2022-04-19 (Reel 059535/0081) is GILLAM & SMITH, L.L.P. This firm is also identified as counsel for Disintermediation Services, Inc. in patent litigation, such as against Perq Software and The Kroger Co..
4. Cascading transfers — not present. There is only one recorded assignment for this patent from the inventors to the original assignee.
5. Pre-litigation transfer — unclear. The assignment from the inventors to Disintermediation Services, Inc. occurred on 2022-04-19, shortly before the patent issued on 2022-05-31. While the patent family has been involved in litigation since at least 2022, the specific first lawsuit naming this patent directly after this assignment would need to be pinpointed for a definitive "present" finding. However, the timing is suggestive.
6. Bankruptcy fire-sale — not present. No indication of bankruptcy proceedings for the assignor or assignee.
7. Privateering — unclear. While Disintermediation Services Inc. asserts patents, there is no public information to confirm if it is asserting on behalf of an operating company against competitors.
8. Defensive aggregator (anti-NPE) — not present. The current assignee is an asserter, not a defensive aggregator.

Verdict

NPE — high confidence

This verdict is driven by Disintermediation Services Inc. being the sole recorded assignee (Reel 059535/0081) and its extensive history as a patent plaintiff identified as a Non-Practicing Entity. The consistent use of GILLAM & SMITH, L.L.P. as correspondent for both the assignment and subsequent litigation further reinforces this pattern.

USPTO Assignment Center search page: https://assignmentcenter.uspto.gov/

Analysis of Prior Art Cited in U.S. Patent 11,349,787

An examination of the file history of U.S. Patent 11,349,787 reveals the prior art references that were cited by the USPTO patent examiner during the prosecution of this patent and its parent applications. These references are crucial for understanding the landscape of existing technology at the time the invention was evaluated and for assessing the patent's validity. Below is an analysis of the most relevant cited patents, outlining their key features and their potential to anticipate the claims of the '787 patent under 35 U.S.C. § 102.

---

U.S. Patent No. 8,364,741 B2

• Full Citation: US 8,364,741 B2, "System and method for providing a communications portal"
• Assignee: Avaya Inc.
• Publication Date: January 29, 2013 (Filed: July 23, 2008)
• Brief Description: This patent discloses a system for managing communications between external users (e.g., customers on a website) and internal users (e.g., agents). It describes establishing a communication session, such as a chat, initiated by an external user. The system can route the communication to an appropriate agent and allows for the exchange of messages. It specifically mentions creating a "portal" that can handle various communication types and route them accordingly.
• Potential Anticipation of Claim(s) 1 and 17: This reference is highly relevant. It describes a system that receives a communication from a user, establishes a session, and connects them with a responder ("agent"). This appears to teach the core elements of receiving a communication request from a web browser, associating it with a conversation, and connecting it to a responder, as outlined in claims 1 and 17. The concept of a "portal" managing the session is analogous to the '787 patent's server determining a "conversation identifier" and mapping communications.

---

U.S. Patent No. 8,930,480 B2

• Full Citation: US 8,930,480 B2, "Method and apparatus for a universal translator for text messaging"
• Assignee: IMForward, LLC
• Publication Date: January 6, 2015 (Filed: June 15, 2011)
• Brief Description: This patent details a system that acts as a universal translator between different text messaging platforms (e.g., AOL Instant Messenger, Yahoo Messenger, SMS). A user can send a message from one service, and the system routes it to a recipient on a different service, translating the protocol as needed. The system maintains user profiles and routing information to ensure messages are delivered correctly between otherwise incompatible platforms.
• Potential Anticipation of Claim(s) 1 and 17: This patent is relevant to the '787 patent's concept of bridging different communication modes. While the '787 patent focuses on a web browser initiating contact with a responder on a potentially different platform (like SMS), the '480 patent describes the core functionality of a central server translating between different real-time communication protocols. Dependent claims of the '787 patent, which specify different communication protocols (like SMS), are particularly relevant here. The '480 patent's system inherently requires identifying users and conversations to route messages, which aligns with the "conversation identifier" element of claims 1 and 17.

---

U.S. Patent No. 9,413,812 B2

• Full Citation: US 9,413,812 B2, "System and method for facilitating communication across a plurality of communication platforms"
• Assignee: LivePerson, Inc.
• Publication Date: August 9, 2016 (Filed: December 21, 2012)
• Brief Description: The '812 patent describes a system that facilitates communication between a website visitor and an agent. It explicitly details a visitor engaging a chat window on a website, with the system routing the chat to an available agent who may be using a different communication tool. The system handles session management and ensures messages are relayed correctly. A key aspect is the ability to transfer the conversation to a different medium, such as from web chat to SMS, if the user leaves the website.
• Potential Anticipation of Claim(s) 1 and 17: This reference strongly anticipates the core ideas of the '787 patent. It discloses receiving a communication from a "web browser of a user" (claims 1 and 17), routing it to a responder ("agent"), and managing the conversation across different platforms. The system's ability to maintain the conversation even when the user moves to a different communication mode (e.g., SMS) strongly suggests the use of a persistent "conversation identifier" to link the messages, directly anticipating a key element of the independent claims.

---

U.S. Patent Application Publication No. 2011/0040854 A1

• Full Citation: US 2011/0040854 A1, "Unified Social Messaging"
• Applicant: Research In Motion Limited
• Publication Date: February 17, 2011 (Filed: August 13, 2009)
• Brief Description: This application describes a "unified" messaging system where a user can manage messages from multiple different services (e.g., social media, instant messaging, email) in a single interface. A central server receives messages from various sources, associates them with the correct user and conversation thread, and presents them in a consolidated view. This involves mapping identifiers from different services to a single, unified conversation.
• Potential Anticipation of Claim(s) 1 and 17: The '854 application teaches the principle of a central system that receives communications from disparate sources and maps them to a specific conversation thread. This is analogous to the '787 patent's server receiving a response from a "first responder" via a protocol like SMS or email and mapping it back to the web browser conversation using a "conversation identifier." The concept of unifying different message types into a single conversation is a foundational element of claims 1 and 17.

Obviousness Analysis of U.S. Patent 11,349,787 Under 35 U.S.C. § 103

Based on the prior art cited during the prosecution of U.S. Patent 11,349,787 and its parent applications, the independent claims of the '787 patent appear to be obvious under 35 U.S.C. § 103. An invention is considered obvious if the differences between the claimed invention and the prior art are such that the invention as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art (PHOSITA). The following analysis presents combinations of the provided prior art references that would render the claims obvious.

The core elements of independent claims 1 and 17 of the '787 patent are:

1. Receiving a communication request from a web browser of an unauthenticated user.
2. Connecting the user with a responder who may use a different communication protocol.
3. Determining and using a conversation identifier to track and associate all messages in the conversation.
4. Persistently storing the conversation linked to the identifier.
5. Retrieving the stored conversation upon a subsequent request from the user's web browser.

---

Combination 1: U.S. Patent No. 9,413,812 (LivePerson) in view of U.S. Patent No. 8,930,480 (IMForward)

This combination of references would have rendered the claimed invention obvious to a PHOSITA. LivePerson ('812) provides the foundational system, and IMForward ('480) provides a known method for implementing a key feature.

• Base Reference: LivePerson ('812 patent)
  The LivePerson patent discloses a comprehensive system that teaches the majority of the '787 patent's claimed elements. It describes a system for facilitating communication between a website visitor (an unauthenticated user) and an agent (a responder). The communication is initiated through a chat window on the website. Critically, LivePerson explicitly teaches the ability to transfer the conversation to a different medium, such as from web chat to SMS, if the user leaves the website. To accomplish this, the system must inherently use a persistent session identifier—the "conversation identifier" claimed in the '787 patent—to link the messages across different platforms and maintain conversational context. This system therefore teaches the core concepts of receiving a request from a web browser, connecting to a responder, managing the session with an identifier across different communication platforms, and storing the conversation to enable this continuity.

• Secondary Reference: IMForward ('480 patent)
  The IMForward patent teaches a method and apparatus for a "universal translator for text messaging" that allows seamless communication between users on different and incompatible messaging platforms (e.g., SMS, AOL Instant Messenger, Yahoo Messenger). It provides the specific technical details for a server-side system that can receive a message in one protocol, translate it, and forward it to a recipient using another protocol.

• Motivation to Combine:
  A PHOSITA, starting with the system described by LivePerson, would be motivated to enhance its cross-platform capabilities. The LivePerson system already establishes the need to communicate across different platforms (web chat to SMS). A PHOSITA seeking to build a more robust and flexible version of this system—one that allows responders to use a wide variety of communication tools beyond just SMS—would naturally look for known solutions for protocol translation. The IMForward patent provides exactly this solution: a universal translation engine.

  The motivation is commercial and practical: to increase the efficiency and flexibility of the customer service agents (responders). By integrating the universal translation technology of IMForward into the LivePerson framework, agents would not be limited to a specific application or protocol but could use their preferred real-time communication tool. This combination of a web-based chat portal (LivePerson) with a multi-protocol communication bridge (IMForward) directly results in the system claimed in the '787 patent, where a web user communicates with a responder on a different platform, and a central server manages the conversation. This would have been a predictable and obvious improvement to a PHOSITA at the time.

---

Combination 2: U.S. Patent No. 8,364,741 (Avaya) in view of U.S. Patent No. 9,413,812 (LivePerson)

This combination demonstrates that even from a more foundational starting point, the claimed invention would have been an obvious next step.

• Base Reference: Avaya ('741 patent)
  The Avaya patent discloses a foundational "communications portal" for managing interactions between external users on a website and internal agents. It teaches the core elements of establishing a communication session (e.g., a chat) initiated by a website user and routing that communication to an appropriate agent. This provides the basic framework for claims 1 and 17: a server that receives a communication from a web browser and connects it to a responder.

• Secondary Reference: LivePerson ('812 patent)
  As described previously, the LivePerson patent teaches a specific and powerful improvement to such a basic system: ensuring conversation continuity when a user leaves the website by transferring the conversation to another medium like SMS. This solves a known problem in the field of online customer support.

• Motivation to Combine:
  A PHOSITA tasked with improving the Avaya communications portal would face the well-known business problem of abandoned chat sessions. When a user closes their browser or navigates away, the conversation is lost, leading to a poor customer experience. The LivePerson patent provides a direct and explicit solution to this problem. It would have been obvious for a PHOSITA to enhance the Avaya system by incorporating the continuity feature described by LivePerson.

  This combination would involve modifying the Avaya portal to:

  1. Assign a persistent identifier to each conversation, not just a temporary session ID.
  2. Incorporate logic to bridge communications to other platforms (like SMS), as taught by LivePerson.
  3. Store the conversation history to allow it to be seamlessly continued on the new platform.

  The result of this combination is a system that receives a web request, routes it to a responder, and maintains the conversation using a persistent identifier across multiple platforms—the very essence of the '787 patent's claims. The element of retrieving the conversation upon the user's return is a trivial and predictable extension of this functionality; if the conversation is stored for continuity, making it visible to the user upon their return via a session cookie is a standard feature for user convenience, not an inventive step. Therefore, combining the foundational portal of Avaya with the known continuity-enhancing features of LivePerson would render the claims of the '787 patent obvious.

Patent Term and Genealogy of U.S. Patent 11,349,787

This analysis details the patent term, application history, and related family members for U.S. Patent 11,349,787, based on its prosecution history and official records as of April 28, 2026.

---

Projected Expiration Date

The projected expiration date for U.S. Patent 11,349,787 is October 16, 2032.

A U.S. patent's term is typically 20 years from the filing date of the earliest non-provisional application in its family. The "CROSS REFERENCE TO RELATED APPLICATIONS" section of the '787 patent specification confirms that its earliest non-provisional parent application is U.S. Application No. 13/653,119, which was filed on October 16, 2012. The projected expiration date is calculated from this date.

Patent Term Adjustment (PTA) and Patent Term Extension (PTE)

• Patent Term Adjustment (PTA): The listed "Adjusted expiration" date of October 16, 2032, corresponds exactly to the 20-year term from the earliest non-provisional filing date. This indicates that there were no significant delays during the patent's prosecution that would have resulted in a grant of Patent Term Adjustment.
• Patent Term Extension (PTE): There is no indication that the patent has been granted any Patent Term Extension. PTE is typically associated with delays in regulatory review for products like pharmaceuticals and is not applicable to the technology described in this patent.

---

Continuation and Divisional Applications

U.S. Patent 11,349,787 is part of a long chain of continuation applications, which all claim priority to the same original provisional and non-provisional applications. No divisional applications are mentioned in the prosecution history.

The direct lineage of the '787 patent is as follows, starting from the earliest application:

1. U.S. Provisional Application No. 61/627,714: Filed October 17, 2011.
2. U.S. Application No. 13/653,119: Filed October 16, 2012 (now U.S. Patent No. 9,106,599). This is the earliest non-provisional application from which the patent term is calculated.
3. Continuation - U.S. Application No. 14/814,337: Filed July 30, 2015 (now U.S. Patent No. 9,894,019).
4. Continuation - U.S. Application No. 15/892,129: Filed February 8, 2018 (now U.S. Patent No. 10,841,253).
5. Continuation - U.S. Application No. 17/036,709: Filed September 29, 2020 (now U.S. Patent No. 11,240,183).
6. Continuation - U.S. Application No. 17/572,958: Filed January 11, 2022 (the application that matured into the subject U.S. Patent No. 11,349,787).

---

Related Patent Family Members

The patent family for U.S. Patent 11,349,787 is extensive and includes multiple granted patents and pending applications, all sharing the same priority date of October 17, 2011. This demonstrates a strategic approach by the assignee to build a broad portfolio around the core invention. The known family members are listed below.

Patent/Application Number	Filing Date	Status / Notes
US 9,106,599 B2	October 16, 2012	Granted (Original Parent Patent)
US 9,894,019 B2	July 30, 2015	Granted (Continuation)
US 10,841,253 B2	February 8, 2018	Granted (Continuation)
US 11,240,183 B2	September 29, 2020	Granted (Continuation)
US 11,336,597 B1	January 11, 2022	Granted
US 11,349,787 B2	January 11, 2022	Subject Patent (Granted, Continuation)
US 11,418,466 B1	May 10, 2022	Granted (Continuation)
US 11,855,936 B2	July 20, 2022	Granted (Continuation)
US 11,855,937 B2	September 7, 2022	Granted (Continuation)
US 12,395,454 B2	July 25, 2023	Granted (Continuation)

Defensive Disclosure and Prior Art Derivations for U.S. Patent 11,349,787

Date of Disclosure: April 28, 2026
Disclosing Party: (Fictional) Advanced Technology Research Collective
Subject Matter: Derivative implementations and extensions of the system described in U.S. Patent 11,349,787, intended to enter the public domain and serve as prior art against future patent applications on similar technologies.

---

1. Material & Component Substitution

Derivative 1.1: Volatile In-Memory Cache with Ephemeral Identifiers

• Enabling Description: This variation replaces the "persistent data store" (as claimed in Claim 1) with a volatile, in-memory distributed cache system like Redis or Memcached. The "conversation identifier" is generated with a short Time-To-Live (TTL), for example, 300 seconds. If the conversation is inactive beyond the TTL, the identifier and all associated messages are purged automatically. This architecture is optimized for high-throughput, ephemeral conversations where long-term storage is undesirable, such as for one-time password verification or temporary support chats. The system uses a CRDT (Conflict-free Replicated Data Type) model to ensure eventual consistency across cache nodes without relying on a central persistent database for the live conversation data.

• Mermaid Diagram:

  sequenceDiagram
      participant User as Web Browser (Unauthenticated)
      participant Server as Communication Gateway
      participant Cache as Redis Cluster (Volatile)
      participant Responder as Responder's Device
  
      User->>Server: POST /initiate_request
      Server->>Cache: SETEX conv_id_123 300 "session_data"
      Server-->>User: 200 OK (with conv_id_123)
      Server->>Responder: PUSH "New request from anonymous user"
      Responder-->>Server: POST /reply (conv_id_123)
      Server->>Cache: APPEND conv_id_123 "responder_msg"
      Server-->>User: SSE/WebSocket PUSH "responder_msg"
      Note over Cache: After 300s of inactivity, key "conv_id_123" is auto-purged.
  

Derivative 1.2: Serverless Architecture with Function-as-a-Service (FaaS)

• Enabling Description: This implementation replaces a monolithic server processor with a serverless architecture using cloud functions (e.g., AWS Lambda, Google Cloud Functions). Each step of the communication flow—receiving the initial request, generating an ID, routing to a responder, and processing replies—is handled by a separate, stateless function. The state (conversation history) is maintained in a high-performance NoSQL database like DynamoDB or Firestore, which is accessed by each function using the conversation identifier as the primary key. This component substitution provides extreme scalability and cost-efficiency, as compute resources are only consumed during active message processing. The communication protocol between functions is managed via a message queue like SQS or Pub/Sub.

• Mermaid Diagram:

  flowchart TD
      A[Web Browser] -- HTTPS Request --> B(API Gateway)
      B -- Triggers --> C{ReceiveRequest Function};
      C -- Writes to --> D[NoSQL DB: Create Conversation];
      C -- Publishes to --> E[Message Queue: New Request Topic];
      F{RouteToResponder Function} -- Subscribes to --> E;
      F -- Reads from --> D;
      F -- Sends via SMS/Email Gateway --> G[Responder];
      G -- Replies via Webhook --> B;
      B -- Triggers --> H{ProcessReply Function};
      H -- Writes to --> D[NoSQL DB: Append Message];
      H -- Publishes to --> I[Message Queue: New Reply Topic];
      J{NotifyUser Function} -- Subscribes to --> I;
      J -- Pushes via WebSocket --> A;
  

---

2. Operational Parameter Expansion

Derivative 2.1: High-Frequency, Low-Latency Industrial Control Application

• Enabling Description: This derivative applies the core invention to a high-frequency industrial control environment. An unauthenticated remote diagnostic tool (the "initiator") communicates with a protected SCADA system (the "responder") through the gateway. The "conversation" consists of telemetry data points and control commands exchanged at a rate exceeding 100 Hz. The conversation identifier is a high-entropy token valid for a single session. The system operates under strict low-latency constraints (<10ms round trip). To achieve this, the server uses a real-time operating system (RTOS) and communicates with both endpoints using a lightweight binary protocol over UDP instead of HTTP. The persistent store is a time-series database (e.g., InfluxDB) optimized for high-speed writes and queries.

• Mermaid Diagram:

  stateDiagram-v2
      [*] --> SessionInit
      SessionInit: Remote Tool sends UDP packet with API key
      SessionInit --> Handshake: Gateway validates key, generates session token
      Handshake --> Streaming: Gateway opens UDP channels to Tool and SCADA
      state Streaming {
          direction LR
          [*] --> Telemetry
          Telemetry: SCADA sends data point
          Telemetry --> Command: Gateway forwards to Tool
          Command: Tool sends control command
          Command --> Telemetry: Gateway forwards to SCADA
      }
      Streaming --> SessionEnd: Timeout or explicit close packet
      SessionEnd --> [*]
  

Derivative 2.2: Large-Scale Asynchronous Civic Engagement Platform

• Enabling Description: The system is scaled to handle millions of concurrent, slow-burn conversations between citizens (initiators) and government agencies (responders). A citizen can anonymously submit a civic issue report from a web portal. The system generates a conversation ID and routes the report to the appropriate municipal department's work queue. The conversation may last for weeks or months. The "responder" is not a single person but a team, and responses are asynchronous (e.g., via email or a dedicated portal update). The data store is a distributed ledger or blockchain to ensure a tamper-proof public record of the interaction without revealing the citizen's identity, using zero-knowledge proofs to validate user status (e.g., "is a resident of this district") without PII disclosure.

• Mermaid Diagram:

  erDiagram
      CITIZEN ||--o{ REPORT : submits
      REPORT {
          string reportID
          string conversationID
          string issue_details
          timestamp created_at
      }
      REPORT ||--|{ MESSAGE : contains
      MESSAGE {
          string messageID
          string content
          string author_role (citizen, agency)
          timestamp sent_at
      }
      REPORT ||--|{ AGENCY_QUEUE : routed_to
      AGENCY_QUEUE {
          string queueID
          string department_name
      }
      CONVERSATION_LEDGER {
          string conversationID
          string reportID
          string encrypted_message_hash
          string block_hash
      }
      REPORT }|--|| CONVERSATION_LEDGER : is_recorded_on
  

---

3. Cross-Domain Application

Derivative 3.1: Aerospace - Anonymous In-Flight Anomaly Reporting

• Enabling Description: An in-flight system (e.g., an Electronic Flight Bag used by a pilot or cabin crew) acts as the unauthenticated initiator. When a non-critical anomaly is observed (e.g., a software glitch in the entertainment system, unusual cabin noise), the crew member can submit a report through a dedicated interface. The system, hosted on a ground server via a satellite link, anonymizes the report's origin (masking the specific aircraft tail number) and assigns a conversation ID. It then routes the report to the relevant ground-based engineering team (the responder) via their standard enterprise messaging tool (e.g., Slack, Microsoft Teams). The engineers can ask for clarifying details, and the responses are routed back to the EFB interface, allowing for a real-time, anonymous dialogue to diagnose the issue without creating an official, discoverable maintenance log until necessary.

• Mermaid Diagram:

  sequenceDiagram
      participant EFB as In-Flight EFB
      participant SatLink as Satellite Comms
      participant Gateway as Ground Server
      participant MaintTeam as Engineering Slack Channel
  
      EFB->>SatLink: Encrypted Report
      SatLink->>Gateway: Submit Anomaly(payload)
      Gateway->>Gateway: Generate ConvID, Anonymize Source
      Gateway->>MaintTeam: Post("New Anonymous Report: [details]...")
      MaintTeam->>Gateway: ReplyInThread("Query: [question]...")
      Gateway->>SatLink: RouteReply(ConvID, payload)
      SatLink->>EFB: Display Message
  

Derivative 3.2: AgTech - Field-Scout to Agronomist Communication Bridge

• Enabling Description: A farmer or field scout uses a low-connectivity mobile device to send an MMS message containing a photo of a distressed crop to a specific phone number. This is the "communication request." The gateway server receives the MMS, extracts the image and any text, creates a conversation ID, and stores the originating phone number. It then uses image recognition AI to classify the potential issue (e.g., "pest," "fungus," "nutrient deficiency") and routes the request to a pool of available agronomists who have indicated expertise in that area. The agronomist receives the request via email. Their email reply is parsed by the gateway, associated with the conversation ID, and sent back to the farmer's device as an SMS message, creating a seamless, anonymous consultation channel.

• Mermaid Diagram:

  flowchart TD
      subgraph Farmer in Field
          A[Mobile Device] -- MMS with photo --> B((Gateway Phone Number))
      end
      subgraph Cloud Platform
          B -- Ingests MMS --> C{Conversation Gateway}
          C -- Creates ConvID & Stores Number --> D[Database]
          C -- Sends Image to --> E[AI Image Recognition]
          E -- Returns "Pest Issue" --> C
          C -- Queries for Expert --> D
          D -- Returns Agronomist_Email --> C
          C -- Sends Email --> F{Agronomist}
      end
      subgraph Agronomist
          F -- Replies to Email --> G((Gateway Email Inbox))
      end
      subgraph Cloud Platform
          G -- Ingests Reply --> C
          C -- Matches ConvID --> D
          D -- Retrieves Farmer_Number --> C
          C -- Sends SMS --> H((SMS Gateway))
      end
      H -- SMS --> A
  

Derivative 3.3: Consumer Electronics - Anonymous IoT Device Support

• Enabling Description: A smart appliance (e.g., a Wi-Fi-enabled refrigerator) detects an internal fault. It sends a diagnostic code as a "communication request" to a manufacturer's server. The server, acting as the gateway, generates a conversation ID and routes the request to a support technician's mobile app via a push notification. The user is "unauthenticated" in that they have not logged into a support portal; the device's unique hardware ID is the initiator. The technician can send a series of simple commands (e.g., "initiate defrost cycle," "run compressor test") back through the gateway. These commands are translated into the device's specific control protocol and executed. The device returns a success/fail code, which is sent back to the technician's app, allowing for remote diagnostics without the consumer needing to be involved or provide any personal information.

• Mermaid Diagram:

  classDiagram
      class IoT_Device {
          +hardwareID
          +sendDiagnostics()
          +executeCommand()
      }
      class GatewayServer {
          +createConversation(hardwareID, diagCode)
          +routeToTechnician(conversationID)
          +translateCommand(command)
          +processResult(result)
      }
      class TechnicianApp {
          +viewRequest(conversationID)
          +sendCommand(command)
          +receiveResult(result)
      }
      IoT_Device "1" -- "1" GatewayServer : communicates via
      TechnicianApp "1" -- "1" GatewayServer : communicates via
  

---

4. Integration with Emerging Tech

Derivative 4.1: AI-Optimized Responder Routing and Triage

• Enabling Description: This derivative enhances the gateway with an AI-driven triage and routing engine. When the initial communication request is received, its content (text, images) is fed into a multi-modal AI model. The model performs sentiment analysis, intent recognition, and topic classification. Based on this analysis, the system routes the request not just based on pre-defined rules, but on which responder has the highest probability of resolving the issue efficiently, calculated from their historical performance data, current workload, and sentiment compatibility. The AI also generates a suggested first response for the chosen responder, streamlining the process.

• Mermaid Diagram:

  graph LR
  A[Initiator] --> B(Gateway);
  B -- Raw Request --> C(AI Triage Engine);
  C --> D{Sentiment Analysis};
  C --> E{Intent Recognition};
  C --> F{Image Classification};
  subgraph Responder DB
      G[Responder Profiles]
      H[Performance History]
  end
  C -- queries --> G;
  C -- queries --> H;
  C -- Generates Routing Score --> I(Optimal Responder);
  B -- Routes Request to --> I;
  C -- Generates Suggested Reply --> I;
  I --> B;
  B --> A;
  

Derivative 4.2: Blockchain-Verified Anonymous Conversations

• Enabling Description: The system is integrated with a public blockchain to provide an immutable, auditable record of conversations while preserving anonymity. When a conversation is initiated, a unique cryptographic keypair is generated for the initiator. The conversation ID is the public key. All messages are signed by the initiator's private key (held client-side) and hashed. The message hash, a timestamp, and the responder's message hash are stored as a transaction on the blockchain. This allows any third party to verify the integrity and timeline of the conversation without knowing the content of the messages or the identities of the participants. This is applicable to legally sensitive anonymous reporting (e.g., whistleblower platforms) or high-value negotiations.

• Mermaid Diagram:

  sequenceDiagram
      participant Initiator
      participant Gateway
      participant Responder
      participant Blockchain
  
      Initiator->>Gateway: Initiate Request
      Gateway->>Initiator: Provide new Keypair (Public=ConvID)
      Initiator->>Gateway: Send Message (signed with PrivateKey)
      Gateway->>Responder: Forward Message
      Responder->>Gateway: Send Reply
      Gateway->>Blockchain: RecordTransaction(ConvID, hash(InitiatorMsg), hash(ResponderMsg))
      Blockchain-->>Gateway: Transaction Confirmed
      Gateway->>Initiator: Forward Reply & TxID
  

---

5. The "Inverse" or Failure Mode

Derivative 5.1: Graceful Degradation to Asynchronous Mode

• Enabling Description: This derivative defines a "safe failure" mode for the system under high load or partial network outage. The gateway constantly monitors its own performance (e.g., message queue length, latency). If a threshold is breached, it automatically switches from a real-time (WebSocket/SSE) mode to a store-and-forward asynchronous mode. The initiator's web interface is dynamically updated to inform them that "Live chat is experiencing high volume. Your message has been received and you will be notified via this page when a response is available." The gateway queues the message and delivers it to the responder when resources permit. This prevents message loss and manages user expectations, providing a limited but reliable functionality instead of a total system failure.

• Mermaid Diagram:

  stateDiagram-v2
      state "Normal Operation (Real-time)" as Realtime
      state "Degraded Operation (Async)" as Async
  
      [*] --> Realtime
      Realtime --> Async: on HighLoad_Event
      Async --> Realtime: on LowLoad_Event
  
      Realtime: Messages pushed via WebSockets. Latency < 2s.
      Async: UI displays "Responses may be delayed." Messages are queued and delivered on a best-effort basis. Initiator must poll for updates.
  

---

Combination Prior Art with Open-Source Standards

1. Combination with Matrix Protocol: The system is implemented as a "bridge" in the decentralized Matrix communication network (matrix.org). An unauthenticated web user interacts with a client hosted on a specific homeserver. The gateway acts as a Matrix bridge that receives messages in this temporary, anonymous room and "puppets" a user on an external network (e.g., SMS, XMPP, or a proprietary API), forwarding messages back and forth. The conversation ID is the Matrix internal room ID. This leverages an existing, open-source, federated communication standard to achieve the core functionality, making the specific combination obvious to anyone skilled in both web development and federated messaging.

2. Combination with WebRTC: The gateway server's initial role is limited to brokering a connection. The unauthenticated user's browser sends a request to the gateway. The gateway finds a responder and securely exchanges signaling messages (using an open protocol like SIP or a custom JSON-based one) between the user's browser and the responder's client to establish a direct, peer-to-peer, encrypted DataChannel using the WebRTC standard. The conversation itself happens directly between the peers, minimizing server load. The "conversation identifier" is the set of credentials used to establish the WebRTC session. This combines the patent's concept with a standard W3C protocol for peer-to-peer communication.

3. Combination with ActivityPub: The system is designed as a service within the federated social web (Fediverse) using the ActivityPub standard. An anonymous user's action on a webpage generates a "Create" activity with an "Article" object, which is sent to a dedicated service actor's inbox. This service actor (the gateway) then forwards this activity to a relevant responder (another actor in the Fediverse). Replies are handled as "inReplyTo" activities. The conversation ID is the URI of the initial "Create" activity object. This applies the patent's centralized anonymous routing concept to a standardized, decentralized social networking protocol.