Quartz Auto Tech LLC v. Lyft Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Quartz Auto Technologies LLC (Maryland)
  • Defendant: Lyft, Inc. (Delaware)
  • Plaintiff's Counsel: Ciccarelli Law Firm
• Case Identification: 1:26-cv-00925, W.D. Tex., 04/13/2026
• Venue Allegations: Plaintiff alleges venue is proper because Defendant conducts substantial business in the district, including offering ride-hailing services in Austin, El Paso, San Antonio, and Waco; recruiting drivers; and maintaining regular and established places of business in Austin and San Antonio.
• Core Dispute: Plaintiff alleges that Defendant's Lyft ride-hailing platform infringes a patent related to the management of mobile objects and a scalable service platform for providing customized, event-driven processes to those objects.
• Technical Context: The technology addresses the challenge of managing large-scale fleets of connected mobile objects, such as vehicles in a ride-hailing network, by providing a method to deliver specific services to individual objects without overwhelming a central server architecture.
• Key Procedural History: The complaint relies heavily on testimony and exhibits from a prior litigation involving Defendant Lyft over a related parent patent (U.S. Patent No. 9,460,616) in the same district, suggesting that discovery and claim construction from that case may inform the current proceedings. The asserted patent was originally assigned to IBM and acquired by Plaintiff through a series of assignments.

Case Timeline

Date	Event
2015-12-16	'384 Patent Priority Date
2018-08-07	U.S. Patent No. 10,043,384 Issued
2018-09-01	Defendant's San Antonio facility operational since at least September 2018
2019-09-30	'384 Patent transferred from IBM to Daedalus Group, LLC
2020-01-01	Defendant's Austin facility operational since in or around January 2020
2020-02-14	'384 Patent assigned to Plaintiff Quartz Auto on or about this date
2026-03-09	Date Plaintiff alleges Defendant had knowledge of the '384 patent
2026-04-13	Complaint Filing Date

II. Technology and Patent(s)-in-Suit Analysis

U.S. Patent No. 10,043,384 - Management of Mobile Objects and Service Platform for Mobile Objects

• Patent Identification: U.S. Patent No. 10,043,384 ("the '384 Patent"), issued August 7, 2018. Compl. ¶10

The Invention Explained

• Problem Addressed: The patent background describes the problem of server overload that occurs as the geographic area and number of mobile objects (e.g., vehicles) in a network expand, which increases the volume of data beyond a server's processing capabilities. It also notes the desire to provide different, customized information and services to individual automobiles and drivers in real-time. '384 Patent, col. 1:12-29
• The Patented Solution: The invention proposes a system architecture comprising a "mobile object server" and a "registration server." The mobile object server handles basic, common processes for a fleet of mobile objects. The registration server enables "first additional processes"-specialized, more complex services-to be registered and associated with a specific mobile object. These additional processes are invoked by the mobile object server only when a predefined "call-up condition" is satisfied, allowing for customized, event-driven functionality without burdening the entire system. '384 Patent, abstract '384 Patent, col. 2:32-52
• Technical Importance: This architecture provides a framework for creating scalable and customizable service platforms for large networks of connected devices, a key technical challenge in fields like ride-hailing, logistics, and fleet management. Compl. ¶14

Key Claims at a Glance

• The complaint asserts system claims 1-9, method claims 10-12, and computer program product claims 13-15, with a primary focus on independent system claim 1. Compl. ¶27 Compl. ¶28
• The essential elements of independent claim 1 are:
  • A "mobile object server" that receives GPS-based location data from multiple "mobile objects" and performs processes via "mobile object agents."
  • A "registration server" that registers a "first additional process" (distinct from a common "first basic process") for a specific mobile object, associating this additional process and a "call-up condition" with that object's agent.
  • The "mobile object server" calls up the "first additional process" when the "call-up condition" is met.
• The complaint explicitly asserts dependent claims by referencing ranges that include them. Compl. ¶27

III. The Accused Instrumentality

Product Identification

The accused instrumentality is the "Lyft Platform," defined as the combination of Lyft's server-side network and infrastructure, the Lyft Driver application, and the Lyft Rider application. Compl. ¶¶15-16

Functionality and Market Context

The Lyft Platform is a ride-hailing system that coordinates transportation between drivers and riders. Compl. ¶15 The complaint alleges it operates using a server architecture that includes a "front proxy" (identified as "Envoy") which acts as an intermediary between the mobile apps and various backend microservices. Compl. ¶30 This platform continuously collects GPS location data from driver and rider mobile devices to enable core functions like dispatch, navigation, and ETA calculations. Compl. ¶¶31-33 The complaint highlights specific features as relevant to the infringement allegations: "Smart Trip Check-In," which monitors for unusual ride activity like unexpected route changes or incorrect drop-offs, and the "Heatmap" feature, which provides customized navigation to guide drivers to high-demand areas. Compl. ¶44 Compl. ¶49 A diagram from a Lyft presentation illustrates an architecture where a "front proxy" communicates with a "discovery service," which manages a list of other available services. Compl. p. 22

IV. Analysis of Infringement Allegations

'384 Patent Infringement Allegations

Claim Element (from Independent Claim 1)	Alleged Infringing Functionality	Complaint Citation	Patent Citation
a mobile object server operable to receive car probe data containing location data from a GPS from each of a plurality of mobile objects within a geographic space; and perform a process associated with each mobile object, wherein the mobile object server is operable to perform processes by mobile object agents associated with the plurality of mobile objects;	The Lyft Platform includes a "mobile object server" (e.g., the "front proxy" or "Envoy" server) that receives GPS location data from driver and rider mobile devices ("mobile objects"). This server performs processes, such as real-time map matching, associated with each mobile device's app ("mobile object agent").	¶¶30-32; ¶36; ¶38	col. 2:35-43
a registration server operable to register a first additional process that is to be performed in addition to a first basic process common to the plurality of mobile objects, wherein the first additional process is associated with one mobile object... wherein the registration server is operable to register the first additional process with one mobile object agent... and wherein the registration server is operable to register the first additional process and a call-up condition by the one mobile object agent;	Lyft's "discovery service" allegedly functions as the "registration server." It registers "additional processes" like the "Smart Trip Check-In" or "Heatmap" navigation features, which provide customized functionality for a specific driver/rider. These processes are triggered by "call-up conditions," such as detecting a ride has deviated from its route or a driver has left a high-demand zone.	¶¶42-45; ¶49; ¶52-53	col. 2:43-49
and the mobile object server is operable to call up the first additional process in response to the call-up condition being satisfied during performance of the one mobile object agent.	The Lyft platform allegedly calls up the additional process when the condition is met. For example, it triggers the "Smart Trip Check-In" notification (the additional process) upon detecting a "Far Drop-Off" (the call-up condition). It also triggers new turn-by-turn navigation when a driver leaves a heatmap zone.	¶65	col. 2:49-52

Identified Points of Contention

• Scope Questions: A central dispute may arise over whether Lyft's "discovery service," which is described as a component in a microservices architecture that allows services to find each other Compl. ¶43, meets the claim definition of a "registration server" that registers a "first additional process" for a specific "mobile object agent." The defense may argue that Lyft's system is a conventional service discovery architecture, not the specific registration system claimed in the patent.
• Technical Questions: Claim 1 requires the registration server to register the "call-up condition by the one mobile object agent." The complaint alleges that detecting a rule violation, such as a far drop-off, is the call-up condition. Compl. ¶53 A key question for the court will be whether the evidence shows the mobile app (the agent) registers this condition with the server, or if the server unilaterally applies a predefined rule (e.g., a distance threshold) to the location data it receives from the app. A slide in the complaint depicting the "Far Drop-Off Rule" notes a specific distance of ">800m" from the selected destination, which may suggest a server-side, rather than agent-registered, condition. Compl. p. 25

V. Key Claim Terms for Construction

"registration server"

• Context and Importance: Plaintiff explicitly equates this term with Lyft's "discovery service." Compl. ¶¶42-43 The viability of the infringement case hinges on whether this component of Lyft's microservices architecture falls within the scope of this claim term.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The specification describes the registration server's function in general terms, stating it "is operable to register a first additional process." '384 Patent, col. 17:1-3 This language could support an interpretation that covers any server component that makes new, non-basic processes available to mobile objects.
  • Evidence for a Narrower Interpretation: Claim 1 requires the registration server to register the additional process "with one mobile object agent." '384 Patent, col. 28:13-16 This, along with architectural diagrams like Figure 15 which show the registration server (310) as a distinct component interacting with other servers, could be used to argue for a specific structural and functional role that is narrower than a general-purpose service discovery mechanism.

"call-up condition"

• Context and Importance: This term defines the trigger for the specialized "additional process." The infringement theory depends on mapping events like route deviations or leaving a bonus zone to this term. Compl. ¶65 A critical aspect is the claim's requirement that the condition is registered "by the one mobile object agent."
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The patent provides several examples of conditions, such as a vehicle moving a certain distance from a parking spot (theft detection) or moving outside a contractually limited driving region. '384 Patent, col. 20:5-18 This variety supports a broad interpretation of what constitutes a "condition."
  • Evidence for a Narrower Interpretation: The language "register the... call-up condition by the one mobile object agent" '384 Patent, col. 28:17-18 is highly specific. Practitioners may focus on this term because it suggests the agent (the software on the mobile device) is the entity that defines and provides the condition to the registration server. This could be interpreted to require more than the server simply applying its own rules to data it receives from the agent. Evidence in the complaint, such as source code defining the FarFromDropoffRule with a specific meter threshold, may be argued to show a server-defined, not agent-registered, condition. Compl. p. 26

VI. Other Allegations

Indirect Infringement

The complaint primarily alleges direct infringement, advancing theories of single-entity infringement (where Lyft performs all steps) and joint infringement (attributing drivers' actions to Lyft). Compl. ¶¶71-73 The joint infringement allegations are based on Lyft's alleged direction and control over its drivers, requiring them to use the Lyft Driver app in a specific manner to participate in the service. Compl. ¶¶74-75

Willful Infringement

The complaint alleges willful infringement based on Defendant's knowledge of the '384 Patent as of March 9, 2026, when it was allegedly served with a permanent injunction motion, and its subsequent continued use of the Lyft Platform without obtaining a license or designing around the patent. Compl. ¶¶81-83

VII. Analyst's Conclusion: Key Questions for the Case

• A core issue will be one of architectural equivalence: can the patent's "registration server," which registers specific "additional processes" for individual mobile agents, be construed to read on Lyft's "discovery service," a component of a modern microservices architecture that facilitates communication between various backend services? The outcome may depend on whether the court views this as a functional equivalent or a fundamentally different, conventional technology.
• A second key question will be one of locus of control: does the claim language "register the... call-up condition by the one mobile object agent" require the mobile app itself to define and transmit the trigger rule to the server? Or is it sufficient for the server to apply its own predefined rules (e.g., a distance threshold for a "far drop-off") to data received from the app? The case may turn on this distinction between an agent-registered condition and a server-applied rule.