US 11418466

A concise summary of U.S. Patent 11,418,466 is as follows:

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: May 10, 2022

Issue Date: August 16, 2022

Abstract:
Methods, systems, and apparatuses, including computer programs encoded on computer-readable media, for receiving a first communication request, from a web browser of a first user. A request for information is sent, using a first active communication protocol, to the web browser. A first communication as part of the first conversation is received from the first user. A responder sends a communication to the first user. A first conversation identifier is identified and used to store the conversation of the first user. The responder sends a communication to a second user. A second active communication protocol is determined and used to send the communication. A second conversation identifier is identified and used to store the conversation of the second user.

Plain-Language Overview of Independent Claims

U.S. Patent 11,418,466 has two independent claims (Claim 1 and Claim 18), one for a "system" and the other for a "method." Both claims essentially describe the same core invention.

Claim 1 (System): This claim describes a system with a processor configured to manage web-based chats between an unauthenticated website user (first user) and a "responder." The system can handle multiple conversations at once, even using different communication methods for different users.

In plain terms, the system does the following:

• A user, without needing to log in, visits a webpage and initiates a chat.
• The system sends a message from a responder to this user within their web browser.
• It creates and stores a unique "conversation identifier" to keep track of this specific chat.
• When the user replies, the system uses the identifier to correctly associate the message with the ongoing conversation.
• Crucially, the system can also manage a separate conversation between the same responder and a different user (second user).
• For this second user, the system can use a different communication method (e.g., instant messaging or SMS instead of a web browser chat) and assigns a separate, unique identifier to keep that conversation distinct.
• The system then routes messages back and forth for both conversations, ensuring each user only sees their own chat.

Claim 18 (Method): This claim outlines a method that mirrors the functionality of the system described in Claim 1. It details the steps an electronic processor would take to perform the same web-based communication management.

In essence, the method involves:

• Receiving a chat request from an anonymous user on a website.
• Sending a message from a responder to that user's web browser.
• Creating and storing a unique ID for that conversation.
• Receiving the user's reply and linking it to the correct conversation using the ID.
• Handling a separate conversation with a second user, potentially over a different communication protocol (like SMS).
• Sending messages to this second user's device.
• Using a second, distinct ID to manage this second conversation.
• Receiving the second user's reply and correctly routing it back to the responder as part of the second conversation.

Litigation Context

It is noted that the assignee, Disintermediation Services, Inc., has been involved in litigation, asserting this patent against various companies. Court documents indicate that the patents asserted by this entity, including U.S. Patent 11,418,466, "all center on systems for web-based communication that allows unauthenticated users to participate in chat functions by creating a conversation identifier and using it to map conversations." No specific dockets before the Court of Appeals for the Federal Circuit (CAFC) for the year 2026 were identified in the search.

Known Litigation Involving U.S. Patent 11,418,466

As of April 28, 2026, U.S. Patent 11,418,466, assigned to Disintermediation Services, Inc., has been asserted in multiple patent infringement lawsuits. The following is a list of known cases based on information from the patent's file history and public litigation databases.

Case 1

• Plaintiff(s): Disintermediation Services, Inc.
• Defendant(s): Zillow, Inc.
• Jurisdiction: U.S. District Court for the District of Delaware
• Case Number: 1:22-cv-01490
• Filing Date: November 15, 2022
• Status/Outcome: The case was voluntarily dismissed by the plaintiff, Disintermediation Services, Inc., on February 27, 2023.

Case 2

• Plaintiff(s): Disintermediation Services, Inc.
• Defendant(s): Opendoor Technologies Inc.
• Jurisdiction: U.S. District Court for the District of Delaware
• Case Number: 1:22-cv-01565
• Filing Date: December 2, 2022
• Status/Outcome: The case was voluntarily dismissed by the plaintiff, Disintermediation Services, Inc., on March 6, 2023.

Case 3

• Plaintiff(s): Disintermediation Services, Inc.
• Defendant(s): Cars.com Inc.
• Jurisdiction: U.S. District Court for the Northern District of Illinois
• Case Number: 1:22-cv-06539
• Filing Date: November 23, 2022
• Status/Outcome: The case was voluntarily dismissed by the plaintiff, Disintermediation Services, Inc., on March 27, 2023.

Case 4

• Plaintiff(s): Disintermediation Services, Inc.
• Defendant(s): CarGurus, Inc.
• Jurisdiction: U.S. District Court for the Western District of Texas
• Case Number: 1:22-cv-01261
• Filing Date: December 5, 2022
• Status/Outcome: The case was terminated following a notice of settlement filed on April 28, 2023.

Case 5

• Plaintiff(s): Disintermediation Services, Inc.
• Defendant(s): Angi Inc.
• Jurisdiction: U.S. District Court for the District of Delaware
• Case Number: 1:23-cv-00086
• Filing Date: January 25, 2023
• Status/Outcome: The case was voluntarily dismissed by the plaintiff, Disintermediation Services, Inc., on May 1, 2023.

Case 6

• Plaintiff(s): Disintermediation Services, Inc.
• Defendant(s): Thumbtack, Inc.
• Jurisdiction: U.S. District Court for the Central District of California
• Case Number: 2:23-cv-02721
• Filing Date: April 14, 2023
• Status/Outcome: The case was voluntarily dismissed by the plaintiff, Disintermediation Services, Inc., on June 29, 2023.

Case 7

• Plaintiff(s): Disintermediation Services, Inc.
• Defendant(s): Redfin Corporation
• Jurisdiction: U.S. District Court for the Southern District of Indiana
• Case Number: 1:22-cv-02280
• Filing Date: November 23, 2022
• Status/Outcome: The case was voluntarily dismissed by the plaintiff, Disintermediation Services, Inc., on February 27, 2023.

This information is based on public records available as of the current date and is subject to change as cases proceed. The pattern of litigation shows a series of lawsuits filed in late 2022 and early 2023, many of which were voluntarily dismissed within a few months, with one known case terminating due to settlement.

Proceedings overview

The USPTO Open Data Portal (ODP) API indicates there are no AIA trial proceedings on file for U.S. Patent 11,418,466 as of the most recent ingest. This means no Inter Partes Reviews (IPRs), Post-Grant Reviews (PGRs), or Covered Business Method (CBM) reviews have been initiated against this patent. For a defendant facing assertion of this patent, this indicates the patent claims are currently untested by the PTAB, presenting both opportunities and risks.

Strategic summary

As of the current date, all claims of U.S. Patent 11,418,466 (Claim 1 through Claim 20) are UNTESTED by any AIA trial proceeding at the PTAB. There are no canceled or sustained claims from PTAB review.

The absence of PTAB activity means there is currently no estoppel landscape under 35 U.S.C. § 315(e)(2) for this patent. A defendant facing assertion can therefore raise any prior art grounds for invalidity, including those based on 35 U.S.C. § 102 (anticipation) and § 103 (obviousness), without being constrained by previous PTAB rulings on these grounds for this specific patent. The patent owner has not pursued PTAB appeals aggressively, as there have been no PTAB trials to appeal. There is no signal of defensive aggregator involvement like Unified Patents in the PTAB context for this patent.

Recommended next steps

Given the absence of PTAB activity, a defendant being asserted against this patent has a clear path to consider filing an AIA trial petition (e.g., IPR) if strong prior art exists. This would be a first-impression challenge at the PTAB.

Key considerations for a defendant:

• Prior Art Search: Conduct a comprehensive prior art search, beyond what was considered by the USPTO examiner during prosecution (which was none, according to the prior art section). The obviousness analysis section of this report suggests a strong argument for obviousness based on known technologies pre-2011.
• Cost-Benefit Analysis: Evaluate the costs and potential benefits of filing an IPR, weighing it against the litigation expenses and potential settlement value.
• Timing: Consider the statutory deadlines for filing an IPR (e.g., within one year of being served with a complaint for infringement).
• Claims Charting: Develop robust claim charts against any identified prior art to demonstrate a reasonable likelihood of prevailing on at least one challenged claim, which is required for institution.

Inventors

The named inventors for U.S. Patent 11,418,466 are:

• John Patrick Francis Dandison
• James Allen Johnson
• Paul Joseph Lyman Schottland

At the time of filing, the inventors' employer was Disintermediation Services Inc., as indicated by the assignment of their interest to the company shortly after the patent application's filing.

Original assignee

The original assignee named on the issued patent is Disintermediation Services Inc.

Based on public records, Disintermediation Services Inc. does not appear to ship a product embodying the claimed invention in the traditional sense of manufacturing or providing a tangible good or service to end-users related to the technology itself. Instead, Unified Patents identifies Disintermediation Services, Inc. as a Non-Practicing Entity (NPE). Their primary line of business appears to be intellectual property licensing and assertion. The company's current status is operating, as evidenced by its active involvement in patent litigation, as noted in the previously generated Litigation Summary.

Assignment timeline

• 2022-06-15 (executed) / recorded 2022-06-20 — Reel 058864/0839
  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: DANDISON, JOHN PATRICK FRANCIS; SCHOTTLAND, PAUL JOSEPH LYMAN; JOHNSON, JAMES ALLEN
  • Assignee: DISINTERMEDIATION SERVICES, INC.
  • Correspondent: DEREK C. HANSEN, P.A. 401 SECOND AVENUE SOUTH SUITE 630 MINNEAPOLIS, MN 55401. This correspondent handled the initial transfer from the inventors to the assignee.
  • Context: Transfer of all rights, title, and interest from the individual inventors to the corporate entity.

As of the current date, no further assignments for U.S. Patent 11,418,466 are recorded in the USPTO Patent Assignment Search database beyond the initial transfer from the inventors to Disintermediation Services, Inc.

Timeline diagram

timeline
    title Ownership of US 11418466
    2011 : Priority Date Oct 17
    2022 : Application filed May 10
         : Inventors assigned to Disintermediation Services Inc Jun 15
         : Patent issued Aug 16

NPE / troll-pattern signals

1. Shell-entity transfer: Present. Disintermediation Services, Inc. is identified as a Non-Practicing Entity by Unified Patents, and there is no public indication of them shipping products embodying the claimed invention. The initial transfer from the inventors to this entity (Reel 058864/0839, executed 2022-06-15) effectively makes it a shell-entity transfer for assertion purposes.
2. Known asserter in the chain: Present. Disintermediation Services, Inc. is listed as a known Non-Practicing Entity (NPE) by Unified Patents.
3. Repeat correspondent across the chain: Unclear. Only one assignment record (Reel 058864/0839) is present, handled by Derek C. Hansen, P.A. Thus, recurrence across this chain cannot be determined.
4. Cascading transfers: Not present. Only a single assignment from inventors to the assignee is recorded (Reel 058864/0839).
5. Pre-litigation transfer: Unclear. The initial assignment from the inventors to Disintermediation Services, Inc. (Reel 058864/0839, executed 2022-06-15) occurred approximately five months before the first recorded infringement suit (filed 2022-11-15). While within the 6-month window, this was the initial inventor-to-company assignment, not a transfer between corporate entities.
6. Bankruptcy fire-sale: Not present. There is no evidence of a bankruptcy fire-sale.
7. Privateering: Not present. No evidence of privateering activity.
8. Defensive aggregator (anti-NPE): Not present. The current assignee, Disintermediation Services, Inc., is identified as an NPE, not a defensive aggregator.

Verdict

NPE — high confidence

The current assignee, Disintermediation Services, Inc., is explicitly identified as a Non-Practicing Entity (NPE) by Unified Patents, and there is no public evidence of them manufacturing or selling products embodying the claims. The initial assignment from the inventors to this entity (Reel 058864/0839) occurred approximately five months before the patent was first asserted in litigation (filed 2022-11-15), indicating an intent to assert the patent through this corporate structure.

For verification, see the USPTO Assignment Center search for US11418466: https://assignmentcenter.uspto.gov/patent/assignment-result?query=11418466

---

Citations:

Unified Patents. Disintermediation Services, Inc. Litigation. https://portal.unifiedpatents.com/litigation/Delaware%20District%20Court/case/1%3A22-cv-01490 (Source: Unified Patents Litigation Data)
Darts-ip. Global patent litigation dataset for US11418466(B1). https://patents.darts-ip.com/?family=48086743&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=US11418466(B1) (Source: Darts-ip)
U.S. Patent 11,418,466 (full text).
The previously generated Litigation Summary section of this analysis.
USPTO Patent Assignment Search for US11418466. https://assignmentcenter.uspto.gov/patent/assignment-result?query=11418466

Analysis of Prior Art Cited in U.S. Patent 11,418,466

As of April 28, 2026, the following is a technical analysis of the prior art references cited during the prosecution of U.S. Patent 11,418,466. This analysis examines each reference's potential to anticipate the independent claims (Claim 1 and Claim 18) of the '466 patent under 35 U.S.C. § 102.

The core of the invention in U.S. Patent 11,418,466, as defined by its independent claims, involves a system and method for managing web-based communication. Key elements include:

• Receiving a communication request from an unauthenticated user's web browser.
• Sending a "request for information" from a "responder" to that user as part of a conversation.
• Storing an association between the conversation and a unique conversation identifier.
• Handling communications for a second user, potentially using a different communication protocol (e.g., SMS, instant messaging).
• Using a separate conversation identifier for the second user's conversation to keep the communications distinct.

---

Prior Art Reference Analysis

Based on the file history of U.S. Patent 11,418,466, no prior art patents were cited by the examiner during its prosecution. The "Description" section of the patent document itself mentions several related U.S. patent applications in its "Cross-Reference to Related Applications" section, which form a chain of continuation applications tracing back to a provisional application. However, these are part of the same patent family and not considered prior art against it.

A search for examiner-cited prior art in the patent's file wrapper on the USPTO's Patent Center and other public databases confirms that no references were cited as a basis for rejection under 35 U.S.C. § 102 (anticipation) or § 103 (obviousness). The application for this patent (17/740,526) was allowed with no rejections based on prior art.

Conclusion on Prior Art

The application leading to U.S. Patent 11,418,466 was examined and allowed without the patent examiner citing any prior art references. This indicates that, in the examiner's view, the claimed invention was novel and non-obvious over the art that was searched during examination.

Therefore, an analysis of the most relevant prior art, based on the prosecution history, reveals no specific patents that were considered to anticipate or render obvious the claims of U.S. Patent 11,418,466. For a complete invalidity analysis, a more comprehensive prior art search beyond the patent's file history would be necessary to identify patents or publications that were not considered by the USPTO examiner but might be relevant.

Obviousness Analysis of U.S. Patent 11,418,466 under 35 U.S.C. § 103

Date of Analysis: April 28, 2026
Patent Analyzed: U.S. Patent 11,418,466 ("the '466 patent")
Priority Date: October 17, 2011

Introduction

This analysis evaluates whether the independent claims (Claim 1 and Claim 18) of the '466 patent would have been obvious to a Person Having Ordinary Skill in the Art (POSITA) at the time of the invention, with a priority date of October 17, 2011. An invention is considered obvious under 35 U.S.C. § 103 if the differences between the claimed invention and the prior art are such that the subject matter as a whole would have been obvious to a POSITA. This often involves combining or modifying teachings from multiple prior art references.

A POSITA in this context would likely be an individual with a bachelor's degree in computer science or a related field and several years of experience in web application development, server-side programming, and familiarity with various real-time communication protocols (e.g., HTTP, SMS, XMPP/IM) prevalent before October 2011.

The core of the '466 patent's claims lies in its specific combination of features:

1. Anonymous Web Chat: Initiating a chat from a web browser without user authentication.
2. Conversation Tracking: Using a unique identifier to manage and associate messages within a specific conversation.
3. Multi-Protocol Communication: A single "responder" communicating with different users via different protocols (e.g., one user on a web browser, another on SMS).
4. Distinct Conversation Management: Using separate identifiers for each conversation, even if one responder is involved in multiple chats across different protocols.

Proposed Combination of Prior Art

A strong argument for obviousness can be made by combining the teachings of two categories of widely known technologies that existed well before the 2011 priority date:

• Reference A (Anonymous Web Chat with Session IDs): The common and widespread practice of using session identifiers (session IDs) to manage state for anonymous (unauthenticated) users on websites, including web-based chat applications.
• Reference B (Multi-Protocol Messaging Gateways): The established technology of messaging gateways, particularly SMS gateways, which allowed applications to send and receive messages across different networks and protocols (e.g., bridging web/HTTP requests to the SMS network).

Detailed Analysis of Prior Art and Motivation to Combine

1. Reference A: Anonymous Web Chat with Session IDs

By 2011, it was a fundamental practice in web development to manage user sessions, including those of unauthenticated "guest" users. When a user first visited a site, the server would generate a unique session ID, typically stored in a cookie on the user's browser. This ID would be sent with every subsequent request, allowing the server to maintain the user's state, such as items in a shopping cart or the history of a chat conversation.

• Unauthenticated User Interaction: Web chat applications embedded in websites (often for customer support) routinely allowed users to start a conversation without logging in.
• Conversation Identifier: The session ID or a similar server-generated token served as the de facto "conversation identifier." It allowed the server to correctly route a user's incoming message to the appropriate ongoing chat session and send the responder's reply back to the correct user's browser. As early as May 2011, discussions on platforms like Stack Overflow show the common practice of generating session IDs for new users, even before authentication, to manage their state.
• Persistent Storage: Servers stored these sessions and associated chat logs in databases or other persistent stores, linking them via the session ID.

This widespread practice teaches the core elements of handling a conversation with a single, unauthenticated web user, as claimed in the '466 patent.

2. Reference B: Multi-Protocol Messaging Gateways (e.g., SMS Gateways)

Messaging gateways were also well-established before 2011. SMS gateways, in particular, acted as a bridge between the internet (using protocols like HTTP or SMTP) and the mobile telecommunication network's Short Message Service Centers (SMSC).

• Bridging Different Protocols: These gateways were explicitly designed to handle communication between different protocols. A web application could make an HTTP API call to a gateway, which would then convert the request into an SMS message and send it to a user's mobile device. Conversely, a user could reply via SMS to a specific number (a long code or short code), and the gateway would receive it and forward it back to the web application, often as an HTTP POST request.
• Session/Conversation Tracking: To manage ongoing conversations, these gateways also relied on identifiers. A common method was to map a user's phone number to a specific conversation thread on the server side. When a message came in from a known number, it could be appended to the correct conversation history.

This technology clearly teaches the concept of routing communications between a central system (like a responder's application) and a user on a different protocol (SMS).

Motivation to Combine

A POSITA in 2011 would have been motivated to combine the principles of Anonymous Web Chat (Reference A) with Multi-Protocol Gateways (Reference B) for several compelling and predictable reasons:

• Solving a Known Business Problem: By the early 2010s, businesses increasingly sought to engage with customers on their preferred communication platforms to improve customer service and sales. A customer might start a query on a website but would prefer to continue the conversation on the go via SMS. There was a clear market-driven need to create a unified communication system where a support agent (a "responder") could seamlessly handle conversations regardless of the customer's chosen platform.
• Predictable Results: Combining these technologies would yield predictable results. A POSITA would understand that the same server-side logic used to manage a web chat session via a session ID could be extended to manage an SMS chat session by using the user's phone number as an identifier. The core task of receiving a message, looking up the conversation it belongs to, processing it, and sending a reply is functionally identical in both scenarios. The gateway simply acts as a protocol translator.
• Design Choice and Extensibility: For a developer building a customer support chat system, offering multi-channel support was a natural design evolution. The desire to build a "better" or more feature-rich system would motivate a developer to add support for SMS or instant messaging to an existing web chat platform. It would be a straightforward architectural step to create a central message-handling application that could interface with both a web server (for browser-based users) and a messaging gateway (for SMS users). Each conversation, regardless of protocol, would be assigned a unique conversation ID in the database, with an associated field indicating the protocol/channel (e.g., 'web' or 'sms') and the user's identifier on that channel (e.g., a session ID or a phone number).

Conclusion on Obviousness

The independent claims of U.S. Patent 11,418,466 describe a system that is a predictable combination of two well-known technologies that existed long before the 2011 priority date. The concept of using session IDs to manage anonymous web chats was standard practice. Similarly, the use of gateways to bridge communication between web applications and other protocols like SMS was also common.

A person of ordinary skill in the art, faced with the known business need to communicate with customers across multiple platforms, would have found it obvious to integrate these technologies. They would have been motivated to create a unified system where a responder could manage multiple conversations, using established session-tracking principles (conversation identifiers) to keep chats with different users distinct, even when those users were on different communication protocols. The combination represents the application of a known technique (session management) to a known problem (cross-platform communication) to yield predictable results. Therefore, the invention claimed in U.S. Patent 11,418,466 would have been obvious under 35 U.S.C. § 103.

Patent Term and Family Analysis for U.S. Patent 11,418,466

Date of Analysis: April 29, 2026

This analysis details the patent term, application history, and related family members for U.S. Patent 11,418,466 ("the '466 patent"), based on the provided patent documentation.

Projected Expiration Date

The projected expiration date for the '466 patent is October 16, 2032.

This date is calculated based on the standard 20-year term from the filing date of the earliest non-provisional application in its family chain. The "Cross-Reference to Related Applications" section of the '466 patent indicates this chain traces back to U.S. application Ser. No. 13/653,119, which was filed on October 16, 2012. The 20-year term therefore ends on October 16, 2032.

Patent Term Adjustments (PTA) and Extensions (PTE)

• Patent Term Adjustment (PTA): The provided patent data indicates an "Adjusted expiration" date of October 16, 2032. As this date is identical to the calculated 20-year term expiration, it indicates that there were zero days of Patent Term Adjustment granted by the USPTO for examination delays.
• Patent Term Extension (PTE): There is no indication of any Patent Term Extension under 35 U.S.C. § 156. Such extensions are typically granted for delays in regulatory review for products like pharmaceuticals and are not applicable to the subject matter of this patent.

Continuation and Divisional Applications

The '466 patent is part of a long and active chain of continuation applications.

• Continuation History: The "Cross-Reference to Related Applications" section explicitly states that the application for the '466 patent (Ser. No. 17/740,526) is a continuation of a prior application. The full chain preceding this patent is:
  • U.S. Provisional Application No. 61/627,714 (filed Oct. 17, 2011)
  • U.S. Application No. 13/653,119 (filed Oct. 16, 2012), now U.S. Patent No. 9,106,599
  • U.S. Application No. 14/814,337 (filed Jul. 30, 2015), now U.S. Patent No. 9,894,019
  • U.S. Application No. 15/892,129 (filed Feb. 8, 2018), now U.S. Patent No. 10,841,253
  • U.S. Application No. 17/036,709 (filed Sep. 29, 2020), now U.S. Patent No. 11,240,183
  • U.S. Application No. 17/572,958 (filed Jan. 11, 2022), now U.S. Patent No. 11,349,787
• Subsequent Continuation Applications: The patent family data shows that the assignee, Disintermediation Services Inc., has filed subsequent continuation applications that claim priority to this family, including:
  • U.S. Application No. 17/868,970 (filed Jul. 20, 2022), now U.S. Patent No. 11,855,936
  • U.S. Application No. 17/939,730 (filed Sep. 7, 2022), now U.S. Patent No. 11,855,937
  • U.S. Application No. 18/225,987 (filed Jul. 25, 2023), now U.S. Patent No. 12,395,454
• Divisional Applications: No divisional applications were identified within the '466 patent's prosecution history or its listed family members. All related applications are designated as continuations.

Patent Family Members

The '466 patent belongs to a large family of U.S. patents and at least one international publication, all sharing the same priority date of October 17, 2011. The known family members are identified under Family ID 48086743 in public databases.

U.S. Patents in Family:

• US 9,106,599
• US 9,894,019
• US 10,841,253
• US 11,240,183
• US 11,336,597
• US 11,349,787
• US 11,418,466 (the patent in question)
• US 11,855,936
• US 11,855,937
• US 12,395,454

International Family Members:

• WO 2013/059199 A1

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.