DCT
1:22-cv-02272
Route Guidance Systems LLC v. Grubhub Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Route Guidance Systems LLC (Delaware)
- Defendant: Grubhub Inc. (Delaware)
- Plaintiff’s Counsel: Devlin Law Firm LLC
- Case Identification: 1:22-cv-02272, N.D. Ill., 05/02/2022
- Venue Allegations: Venue is asserted based on Defendant Grubhub maintaining an established place of business, including its corporate headquarters, in Chicago, within the Northern District of Illinois.
- Core Dispute: Plaintiff alleges that Defendant’s Grubhub Driver App and associated back-end systems infringe a patent related to methods for efficiently providing vehicle route guidance from a central computer.
- Technical Context: The technology concerns centralized navigation systems that calculate routes on a server and transmit them to vehicles, focusing on minimizing communication channel usage to improve system scalability and reduce costs.
- Key Procedural History: The complaint does not mention any prior litigation, Inter Partes Review (IPR) proceedings, or licensing history related to the patent-in-suit.
Case Timeline
| Date | Event |
|---|---|
| 2001-05-04 | ’876 Patent Priority Date |
| 2005-07-12 | ’876 Patent Issued |
| 2022-05-02 | Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 6,917,876 - "Route Guidance for Vehicles"
- Patent Identification: U.S. Patent No. 6,917,876, "Route Guidance for Vehicles," issued July 12, 2005 (the “’876 Patent”).
The Invention Explained
- Problem Addressed: The patent describes prior art route guidance systems as inefficient because they required a continuous, open communication channel between a central computer and an in-vehicle device for the entire duration of a trip (Compl. ¶13-14). This limited the number of vehicles a system could support, particularly given the low-bandwidth wireless networks (e.g., 2G) available at the time of the invention (Compl. ¶13).
- The Patented Solution: The invention proposes a system where route guidance data is calculated by a central computer and transmitted to the vehicle over a communication channel that is opened only for a "short burst" and is then "closed" until another transmission is needed (’876 Patent, col. 1:64-2:2). This on-demand communication model is intended to reduce network usage and running costs, thereby allowing a central server to support many more vehicles concurrently (Compl. ¶14, ¶18).
- Technical Importance: By optimizing the use of the communication channel, the invention aimed to overcome the scalability limitations of earlier centralized navigation systems (Compl. ¶20).
Key Claims at a Glance
- The complaint asserts independent claims 1 (system) and 26 (method) (Compl. ¶33).
- Independent Claim 1 (System Claim) Elements:
- a central computer adapted to calculate route guidance data
- means for supplying the vehicle with the route guidance data, providing a channel of communication which is opened to transmit said route guidance data to the vehicle in a short burst and is then closed, so that transmission to the vehicle via said channel ceases, unless and until a need for further transmission arises
- means for receiving the route guidance data
- means for presenting respective instructions to the vehicle
- The complaint notes that infringement is of "at least claims 1 and 26," reserving the right to assert other claims (Compl. ¶33).
III. The Accused Instrumentality
Product Identification
- The "Accused Instrumentalities" are identified as the "Grubhub Driver App, along with associated hardware and/or software, including but not limited to Grubhub's back-end servers and related computer systems operated by Grubhub that work in conjunction with the Grubhub Driver App" (Compl. ¶33).
Functionality and Market Context
- The complaint describes the accused system as providing centralized route guidance to Grubhub's drivers (Compl. ¶16). It alleges that this functionality is a core component of the Grubhub platform, which relies on a large network of drivers who use the app-based system to navigate to restaurants and customer locations (Compl. ¶16). The complaint alleges that improvements in the efficiency of such route guidance technology significantly improve the scalability and usability of platforms like Grubhub's (Compl. ¶16). No probative visual evidence provided in complaint.
IV. Analysis of Infringement Allegations
The complaint references exemplary claim charts in an attached "Exhibit 2," which was not included in the provided court filing (Compl. ¶33). The following analysis is based on the narrative allegations within the complaint.
’876 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| a central computer adapted to calculate route guidance data providing a route for the vehicle to the desired destination | Grubhub's back-end servers calculate routes for drivers to take to their destinations (Compl. ¶33). | ¶33 | col. 4:62-65 |
| means for supplying the vehicle with the route guidance data calculated by the central computer, providing a channel of communication which is opened to transmit said route guidance data to the vehicle in a short burst and is then closed, so that transmission...ceases, unless and until a need for further transmission...arises | Grubhub's system allegedly uses an on-demand, intermittent communication channel between its servers and the Driver App to transmit route data in short bursts, which improves system scalability by not requiring a permanently open channel (Compl. ¶18-20, ¶33). | ¶18, ¶33 | col. 1:64-2:2 |
| means for receiving the route guidance data calculated by the central computer | The Grubhub Driver App, operating on a driver's mobile device, receives the route guidance data from Grubhub's central servers (Compl. ¶33). | ¶33 | col. 5:9-11 |
| means for presenting respective instructions to the vehicle as to the route to be taken to the desired destination | The Grubhub Driver App presents driving instructions to the driver based on the received route data (Compl. ¶33). | ¶33 | col. 5:12-14 |
- Identified Points of Contention:
- Scope Questions: A central question may be whether the communication protocols of a modern, "always-on" smartphone application (the Grubhub Driver App) can be characterized as a channel that is "opened" and then "closed" in the manner described by the patent. The defense may argue that modern apps maintain a persistent or semi-persistent data connection, which differs from the "closed" channel envisioned by the inventors in the context of 2G-era technology.
- Technical Questions: The analysis may focus on what constitutes a "short burst." The court may need to determine if standard packet-based data transmissions in a modern mobile network meet this limitation, or if the term implies a more specific type of time-limited data session distinct from continuous background connectivity.
V. Key Claim Terms for Construction
- The Term: "a channel of communication which is opened to transmit said route guidance data to the vehicle in a short burst and is then closed, so that transmission to the vehicle via said channel ceases, unless and until a need for further transmission... arises"
- Context and Importance: This limitation is the core of the asserted invention, distinguishing it from prior art that allegedly required a permanently open channel. The entire infringement case rests on whether the Grubhub system's operation falls within the scope of this term. Practitioners may focus on this term because its interpretation will likely determine whether technology developed two decades after the patent's priority date infringes.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification states that a particular advantage is that "the transmission channel need not be kept permanently open" (’876 Patent, col. 2:21-23). Plaintiff may argue this language supports a broad construction where any non-permanent, on-demand data transmission for route guidance qualifies, regardless of the underlying network technology.
- Evidence for a Narrower Interpretation: The specification discusses the invention in the context of overcoming limitations of a "data-call" where a driver would "initiate a data-call from the in-vehicle device" that remained open until terminated (Compl. ¶14). The patent also describes the channel as one where "transmission to the vehicle via said channel ceases" (’876 Patent, col. 2:1-2). A defendant could argue this implies a complete termination of the communication session, unlike modern apps which may remain connected for status updates or other background data even when not actively receiving route instructions.
VI. Other Allegations
- Indirect Infringement: The complaint alleges induced infringement under 35 U.S.C. § 271(b), stating that Grubhub provides the Accused Instrumentalities to its "partners, drivers, clients, customers/subscribers, and end users" and provides materials and services that instruct them to use the system in an infringing manner (Compl. ¶35-36). The complaint also pleads contributory infringement under § 271(c), alleging the Accused Instrumentalities are material components not suitable for substantial non-infringing use (Compl. ¶37).
- Willful Infringement: The complaint alleges that Grubhub's infringement is willful, asserting that Grubhub had knowledge of the ’876 Patent and its infringement "at least as early as the filing of this Complaint" (Compl. ¶34, ¶38). This frames the willfulness claim as being based on post-suit conduct.
VII. Analyst’s Conclusion: Key Questions for the Case
This dispute appears to center on the application of patent claims, drafted in the context of early-2000s mobile technology, to a modern, app-based service ecosystem. The key questions for the court will likely be:
- A core issue will be one of technological translation: Does the claim term "a channel... opened... in a short burst and is then closed," which was conceived to solve problems in circuit-switched and early packet-switched networks, read on the fundamentally different "always-on" communication architecture of a modern smartphone app operating on a 4G/5G network?
- A key evidentiary question will be one of operational fact: What evidence will show that the communication channel between Grubhub's servers and its Driver App actually "ceases" in a manner consistent with the claims, as opposed to merely becoming idle or entering a low-power state while maintaining a persistent underlying connection for other platform-related functions?