DCT
2:23-cv-02165
Ameranth Inc v. DoorDash Inc
Key Events
Amended Complaint
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Ameranth, Inc. (Delaware)
- Defendant: DoorDash, Inc. (Delaware); Eat'N Park Restaurants, LLC (Pennsylvania); Eat'N Park Hospitality Group, Inc. (Pennsylvania)
- Plaintiff’s Counsel: Pribanic & Pribanic; Stamoulis & Weinblatt LLC
- Case Identification: 2:23-cv-02165, W.D. Pa., 09/17/2024
- Venue Allegations: Plaintiff alleges venue is proper in the Western District of Pennsylvania based on Defendant DoorDash’s operation of a physical "DashMart" store in Pittsburgh, the deployment of its "Bbot" mobile ordering technology at local restaurants, and its employment of a Pittsburgh-based engineering team. Venue over Eat'N Park is based on its restaurant locations within the district.
- Core Dispute: Plaintiff alleges that Defendant’s food delivery platform, backend architecture, and associated technologies infringe patents related to intelligent, distributed web server networks for the hospitality industry.
- Technical Context: The technology concerns backend server architectures designed to manage communications and data synchronization across distributed networks that include multiple, disparate user devices, aiming to solve technical challenges of consistency, availability, and fault tolerance.
- Key Procedural History: The complaint notes that claims from older patents in the same family were previously invalidated under 35 U.S.C. § 101 (Alice). Plaintiff alleges the currently asserted "Network Patents" are materially different, claim priority to a 2005 continuation-in-part application, and are directed to non-abstract technical improvements to backend computer systems that solve recognized technological problems such as the CAP Theorem Challenge.
Case Timeline
| Date | Event |
|---|---|
| 2005-07-26 | Priority Date for ’415 and ’587 Patents |
| 2013-01-01 | DoorDash begins food delivery venture |
| 2020-08-05 | DoorDash announces DashMart stores |
| 2021-01-01 | Pittsburgh DashMart store opens |
| 2023-12-12 | U.S. Patent No. 11,842,415 Issues |
| 2023-12-19 | U.S. Patent No. 11,847,587 Issues |
| 2023-12-22 | Plaintiff files initial complaint |
| 2024-09-17 | Plaintiff files amended complaint |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 11,842,415 - "Intelligent Web Server With Multi-Modes of Contact, Multi-Communications Protocols, Multi-User and Parallel Operational Capabilities for Use in a Hospitality Market Comprising"
The Invention Explained
- Problem Addressed: The patent’s background describes the technical hurdles preventing the widespread adoption of integrated, computerized systems in the hospitality industry, particularly the lack of a solution for synchronizing data between a central server, web interfaces, and multiple different wireless handheld devices in real-time ('415 Patent, col. 2:5-12, 2:32-47). The complaint contextualizes this as the "CAP Theorem Challenge" in distributed computing—the difficulty of concurrently achieving data consistency, system availability, and partition tolerance (fault tolerance) (Compl. ¶¶40, 62-63).
- The Patented Solution: The invention is an "improved and intelligent web server computer" system that acts as a central hub for hospitality applications ('415 Patent, col. 19:41-43). It uses a specific "Middleware/Framework Communications Control Software" (MFCCS) architecture to manage communications between a master database and two or more different wireless handheld computers, each with different operating systems ('415 Patent, col. 19:62-20:10; Fig. 10). The system is programmed with "rule based intelligence" to automatically choose primary and alternate communication modes (e.g., Wi-Fi, cellular, text message) to ensure tasks are completed, even if one mode fails, thereby improving efficiency and reliability ('415 Patent, col. 20:20-42).
- Technical Importance: This architectural approach was designed to provide the reliability and data integrity needed for mission-critical hospitality tasks (like ordering and reservations) to be managed across a complex network of fixed and mobile devices ('415 Patent, col. 2:55-60).
Key Claims at a Glance
- The complaint asserts independent claims 1 and 9 of the ’415 Patent (Compl. ¶135).
- Independent Claim 1 includes these essential elements:
- An improved and intelligent web server computer with multi-mode/protocol/user capabilities.
- At least one hospitality software application integrated with the server.
- A master database with a predefined file structure and an API that "intelligently learns, updates and stores multiple communication modes of contact" and user preferences.
- A "Middleware/Framework Communications Control Software (MFCCS)" with a "centralized system layer architecture" to enable communication with two or more different wireless handheld computers with different operating systems.
- At least one external software API to integrate non-hospitality applications.
- The web server is programmed with executable instructions to:
- Choose and apply a primary communication mode for a task.
- Automatically choose and execute an alternate communication mode upon failure of the primary mode.
- Apply "rule based intelligence" to avoid re-attempting a failed communication mode for a set period, thereby improving efficiency.
- The complaint does not explicitly reserve the right to assert dependent claims.
U.S. Patent No. 11,847,587 - "Intelligent Backoffice and Handheld/Mobile Computing Network With Varying, Multi-Modes of Contact, and Parallel Capabilities for Use in Completing Remotely Initiated Hospitality Tasks in the Hospitality Market Comprising:"
The Invention Explained
- Problem Addressed: Similar to the ’415 patent, this invention addresses the need for a reliable, distributed computing network for hospitality services that integrates backend servers with mobile devices ('587 Patent, col. 1:35-41). It specifically focuses on the challenges of completing tasks that are initiated remotely.
- The Patented Solution: The patent claims a distributed computing network composed of "distributed and linked backoffice servers" that are "continuously synchronized in real time" ('587 Patent, col. 21:49-53). Like the ’415 Patent, this network uses an MFCCS layer to manage communication with different handheld mobile computers ('587 Patent, col. 22:15-24). The system is programmed with instructions to "choose and apply varying modes of contact during the same remotely initiated hospitality task" to ensure its completion and can also automatically contact other entities if a task cannot be completed with the first one ('587 Patent, col. 22:34-45, 21:65-22:2).
- Technical Importance: This invention provides a resilient network architecture for services where tasks are initiated from mobile devices and must be reliably processed by a distributed backend system, with built-in logic for handling communication failures or unavailability ('587 Patent, Abstract).
Key Claims at a Glance
- The complaint asserts independent claims 1 and 7 of the ’587 Patent (Compl. ¶143).
- Independent Claim 1 includes these essential elements:
- A network of distributed and linked backoffice servers that are continuously synchronized in real-time and managed via a web interface.
- One or more hospitality software applications linked with the servers, with versions for different handheld/mobile computers.
- A master database comprising multiple linked and continuously synchronized real-time databases throughout the network, where applications learn and apply varying modes of contact.
- Middleware/Framework Communications Control Software (MFCCS) with a centralized system layer architecture to enable communication with the different handheld computers.
- At least one external API for integrating non-hospitality applications.
- The network is enabled to automatically contact other entities if a task cannot be completed with a first entity.
- The network is programmed with instructions to "choose and apply varying modes of contact during the same remotely initiated hospitality task" to execute and support its completion.
- The complaint does not explicitly reserve the right to assert dependent claims.
III. The Accused Instrumentality
- Product Identification: The accused instrumentalities are the DoorDash food delivery platform and its underlying technology, including the DoorDash website and mobile applications for consumers, "Dashers," and merchants; the "DashMart" convenience stores; and the "Bbot Mobile Ordering" technology (Compl. ¶¶2, 22). The complaint focuses on the platform's backend architecture (Compl. ¶135, 143).
- Functionality and Market Context: The DoorDash platform is a three-sided marketplace connecting consumers, restaurants/merchants, and delivery drivers ("Dashers") (Compl. ¶139). A diagram in the complaint illustrates the basic workflow: a customer places an order, which DoorDash sends to the merchant for preparation and to a Dasher for pickup and delivery (Compl. ¶118, "Life Cycle of a Delivery Order" figure). The complaint alleges that as DoorDash scaled, it transitioned from a "code monolith" to a "multi-layered microservice architecture" in 2019 to solve technical problems of reliability and scalability (Compl. ¶¶119-120). Plaintiff alleges this microservice architecture, which DoorDash internally refers to as its "Iguazo" platform, is the infringing system (Compl. ¶¶138, 140). A system diagram titled "The Big Picture" is presented as a depiction of this accused architecture (Compl. p. 82).
IV. Analysis of Infringement Allegations
The complaint incorporates by reference preliminary claim charts as exhibits, but these exhibits are not included in the provided document. The following summary is based on the narrative allegations and visual evidence within the complaint itself.
U.S. Patent No. 11,842,415 Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| An improved and intelligent web server computer with multi-modes of contact... | DoorDash's backend server platform, which the complaint alleges was re-architected into a "multi-layered microservice architecture" to solve technical problems. | ¶¶119, 120 | col. 19:41-47 |
| a master database... wherein the API intelligently learns, updates and stores multiple communication modes of contact... | DoorDash's "central data platform" or "central data lake," which allegedly collects data from all sources (apps, CRM, transactions) to create a "360 degree picture" for optimization and personalization. | ¶¶139, 147 | col. 19:51-61 |
| Middleware/Framework Communications Control Software, (MFCCS) which enables via its centralized system layer architecture... | DoorDash's "Iguazo" platform, depicted as a layered framework that processes and routes data between external clients (consumers, restaurants) and internal services. | ¶¶140, 148, p. 82 | col. 19:62-20:10 |
| at least one external software API... | The Iguazo platform's alleged use of APIs for "food importation inputs from the restaurants on the far left (i.e. their external clients)." | ¶82, p. 82 | col. 20:11-18 |
| ...programmed with instructions... to automatically choose and execute alternate communication modes of contact... upon failure of the primary... | The complaint alleges DoorDash's re-architecture was intended to improve "reliability and developer velocity," suggesting a system designed to handle failures and ensure task completion. | ¶121 | col. 20:20-42 |
- Identified Points of Contention:
- Scope Questions: A central question may be whether DoorDash’s modern, distributed "microservice architecture," as depicted in the "The Big Picture" diagram (Compl. p. 82), can be characterized as having the "centralized system layer architecture" required by the claimed "MFCCS."
- Technical Questions: The complaint alleges DoorDash's system performs intelligent functions like choosing alternate communication modes upon failure. A point of contention may be what evidence exists that the accused system performs this specific, rule-based logic, rather than employing more general fault-tolerance mechanisms common to modern distributed systems.
U.S. Patent No. 11,847,587 Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| a network of distributed and linked backoffice servers that are continuously synchronized in real time... | DoorDash's distributed microservices platform, which the complaint alleges was designed to facilitate millions of deliveries per day and improve reliability through a re-architecture. | ¶¶119, 121 | col. 21:49-53 |
| a master database comprising multiple linked and continuously synchronized in realtime databases throughout the network... | The "central data platform" that allegedly aggregates data from "all sides of the marketplace" into "one central place" to ensure data accessibility and consistency. | ¶¶139, 147 | col. 22:1-14 |
| Middleware/Framework Communications Control Software (MFCCS) which enables via its centralized system layer architecture... | DoorDash's "Iguazo" microservice architecture, which the complaint alleges is a layered platform connecting its various applications and backend services. | ¶¶120, 148, p. 82 | col. 22:15-24 |
| ...the network is further enabled to automatically contact one or more other entities when the remotely initiated hospitality task cannot be completed with a first entity... | The alleged functionality of the DoorDash platform to coordinate between customers, merchants, and Dashers. If a merchant cannot fulfill an order, the system must interact with other parties (the customer, other merchants, etc.). | ¶118, p. 58 | col. 21:65-22:2 |
- Identified Points of Contention:
- Scope Questions: The claim requires servers to be "continuously synchronized in real time." The analysis may turn on whether this term can be construed to read on the data consistency models (which often involve trade-offs, as noted by the complaint's reference to the CAP theorem) used in large-scale commercial platforms like DoorDash.
- Technical Questions: The infringement allegation for automatically contacting "other entities" when a task fails with a "first entity" is functional. A key question will be what specific evidence demonstrates that the accused platform performs this sequential, contingent logic as claimed, rather than as a general byproduct of its marketplace operations.
V. Key Claim Terms for Construction
The Term: "Middleware/Framework Communications Control Software (MFCCS)"
- Context and Importance: This term defines the core architecture of the invention. The infringement case appears to depend heavily on mapping DoorDash's "multi-layered microservice architecture" onto this claimed element. Practitioners may focus on whether "MFCCS" is limited to the specific 2005-era system shown in the patent figures or can be interpreted more broadly.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The claims describe the MFCCS functionally as software with a "centralized system layer architecture" that enables a web server to communicate with different handhelds, suggesting any architecture performing this function could be covered ('415 Patent, col. 19:62-20:10).
- Evidence for a Narrower Interpretation: The specification repeatedly ties the MFCCS to the specific system diagram in Figure 10 ('415 Patent, col. 5:10-12). The complaint itself alleges Figure 10 shows the "layered architecture" of the MFCCS, which could suggest its structure is limited to that depiction (Compl. ¶73).
The Term: "intelligently learns, updates and stores"
- Context and Importance: This term from claim 1 of the ’415 Patent defines the "intelligence" of the claimed system. The dispute will likely focus on the degree and type of "learning" required to meet this limitation.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification describes this in the context of storing and applying user preferences and operational parameters, such as "set periods of time" or "prior preferences," which could encompass relatively simple data storage and retrieval logic ('415 Patent, col. 19:55-61).
- Evidence for a Narrower Interpretation: The term "learns" could be interpreted to require a specific adaptive or machine-learning-like capability that goes beyond merely storing and applying predefined rules or historical data.
The Term: "continuously synchronized in real time"
- Context and Importance: Found in claim 1 of the ’587 Patent, this term is critical to defining the performance of the distributed network. Its construction will be central to determining if DoorDash's architecture, which operates at massive scale, meets this requirement.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent's goal is to keep all components "in equilibrium at any given time," suggesting that "real time" could mean without user-perceptible lag, rather than requiring instantaneous, strict data consistency ('587 Patent, col. 2:39-41).
- Evidence for a Narrower Interpretation: The term "continuously" and "in real time" could be argued to require a high degree of data consistency that is technically distinct from the "eventual consistency" models often used in large-scale microservice architectures to maintain availability and performance—a trade-off explicitly raised by the complaint's discussion of the CAP Theorem (Compl. ¶40).
VI. Other Allegations
- Indirect Infringement: The complaint alleges that DoorDash induces infringement by providing "on-line technical documentation, instructions, and technical support" that instruct customers and end-users on how to use the accused platform in a manner that infringes the patents (Compl. ¶158). Similar allegations are made against Eat'N Park regarding its instructions for using the DoorDash platform (Compl. ¶160).
- Willful Infringement: The willfulness allegation is based on post-suit knowledge. Plaintiff claims Defendants have been on notice of the patents since receiving the initial complaint on January 16, 2024, and have "not altered their infringing conduct" since that date (Compl. ¶¶152, 155-156).
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of architectural scope: can the "Middleware/Framework Communications Control Software (MFCCS)" claimed in patents with a 2005 priority date, and illustrated with a corresponding system diagram, be construed to cover a modern, large-scale "microservice architecture" developed over a decade later?
- A second central question will be one of definitional precision: does the term "continuously synchronized in real time" require a strict data consistency model, or can it encompass the "eventual consistency" models commonly used in modern distributed systems to balance the trade-offs between consistency, availability, and partition tolerance?
- Finally, a key evidentiary question will be one of functional proof: does the complaint's high-level assertion that the accused system performs "intelligent" and "automatic" failure handling translate into concrete evidence that DoorDash's platform executes the specific, rule-based decision logic required by the claims, as opposed to employing general, conventional fault-tolerance techniques?