DCT

1:22-cv-01290

Digi Portal LLC v. Getaround Inc

Key Events
Complaint
complaint

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 1:22-cv-01290, D. Del., 09/30/2022
  • Venue Allegations: Venue is alleged to be proper in the District of Delaware because the Defendant is a Delaware corporation and therefore resides in the district.
  • Core Dispute: Plaintiff alleges that Defendant’s car-sharing website and service infringe five U.S. patents related to the dynamic generation of customized web pages for users.
  • Technical Context: The patents address foundational methods for efficiently serving personalized web content to a large number of simultaneous users, a key technical challenge in the growth of the early consumer internet.
  • Key Procedural History: The complaint notes that the five asserted patents, all originally assigned to Yahoo! Inc., share an identical specification and claim priority back to the same 1997 application. Plaintiff also alleges that patents from this family were cited during the prosecution of over 700 other patents, suggesting a potential awareness of the technology in the field. The complaint references prosecution history arguments made to distinguish prior art, focusing on the unconventional nature of storing real-time data locally on a page server and determining template retrieval location based on user request frequency.

Case Timeline

Date Event
1997-06-12 Priority Date for all Patents-in-Suit
1999-11-09 U.S. Patent No. 5,983,227 Issues
2007-01-30 U.S. Patent No. 7,171,414 Issues
2009-07-21 U.S. Patent No. 7,565,359 Issues
2013-01-08 U.S. Patent No. 8,352,854 Issues
2017-04-18 U.S. Patent No. 9,626,342 Issues
2022-09-30 Complaint Filed

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

U.S. Patent No. 8,352,854 - "Dynamic Page Generator"

  • Issued: January 8, 2013
  • Asserted Claims: Independent claims 1, 8, 15; Dependent claims 2, 9 (Compl. ¶27)

The Invention Explained

  • Problem Addressed: The patent describes the technical problem of generating customized web pages for many users without the system becoming slow or unscalable ('854 Patent, col. 1:42-43). Prior methods, such as Common Gateway Interface (CGI) scripts, required polling various external servers for data (e.g., stock quotes, sports scores) for each user request, creating significant delays and performance bottlenecks as user numbers grew ('854 Patent, col. 1:43-58). Other approaches that streamed data to the user's local machine clogged networks and resulted in outdated information ('854 Patent, col. 1:59-67).
  • The Patented Solution: The invention proposes a system where a "user template" is created by combining a "global front page template" with a user's specific configuration data ('854 Patent, col. 3:58-62; Fig. 2). This user template is then populated with live data that is stored locally on the page server in a "shared memory" region ('854 Patent, col. 4:4-11). This architecture avoids repeated, time-consuming calls to external data sources for each page request. To further enhance efficiency, the system stores these user templates in two types of locations—a persistent user configuration database and a faster cache—with the retrieval location being determined by the frequency of the user's requests ('854 Patent, col. 5:23-38, col. 6:49-59).
  • Technical Importance: This server-side architecture for efficiently combining static templates with locally cached live data was a key enabler for the first generation of large-scale personalized web portals (Compl. ¶12).

Key Claims at a Glance

The essential elements of independent claim 1 are:

  • receiving a user request for a customized page;
  • receiving a template program that is unique to the user and based on user configuration information, which is supplied by the user and includes user demographic information;
  • wherein the template program is received from one of at least two locations, with the specific location being determined from the frequency of the user request for the customized page;
  • receiving an advertisement selected in accordance with the user demographic information;
  • executing the template program using the selected advertisement to generate the customized page; and
  • providing the customized page to the user.

U.S. Patent No. 5,983,227 - "Dynamic Page Generator"

  • Issued: November 9, 1999
  • Asserted Claims: Independent claim 2 (Compl. ¶45)

The Invention Explained

  • Problem Addressed: The '227 Patent, which shares its specification with the '854 Patent, addresses the same technical problem: the inefficiency and lack of scalability in prior art systems for generating customized web pages for large audiences ('227 Patent, col. 1:39-44).
  • The Patented Solution: The method claimed involves a page server that obtains both user preferences and real-time information from external sources ('227 Patent, col. 19:50-55). Crucially, the system then "stor[es] the real-time information in a storage device" local to the page server, such as a shared memory ('227 Patent, col. 20:4-5, col. 4:4-11). This local data store is used as input for a user-specific "template program"—formed by combining a generic template with the user's preferences—to generate and serve the customized page in real-time response to a user's request ('227 Patent, col. 20:6-19). This avoids the latency of fetching live data from external sources for every individual page view.
  • Technical Importance: This method provided a scalable framework for early internet portals to offer personalized content without compromising server response times.

Key Claims at a Glance

The essential elements of independent claim 2 are:

  • obtaining user preferences indicating items of interest;
  • obtaining real-time information from information sources;
  • storing the real-time information in a storage device;
  • combining the user preferences and a template to form a template program specific to the user;
  • receiving a user request for a customized page;
  • executing the template program using the stored real-time information to generate the customized page; and
  • providing the customized page to the user in real-time response to the request, wherein the page includes at least one item of real-time information.

U.S. Patent No. 7,171,414 - "Dynamic Page Generator"

  • Patent Identification: U.S. Patent No. 7171414, issued January 30, 2007.
  • Technology Synopsis: This patent, sharing the same specification, claims a method for providing a customized page by storing real-time data in a shared local storage device, which allows a page server to build the page without making requests to other servers (Compl. ¶60). The method also involves receiving a user-specific template program from one of at least two locations, where the location is determined by the frequency of the user's requests for the page (Compl. ¶61).
  • Asserted Claims: Claims 1 and 3 (Compl. ¶62).
  • Accused Features: The Getaround.com server's alleged use of a network-coupled system to provide customized search result pages based on user preferences, using locally stored real-time car availability information and user-specific templates retrieved from different locations based on access frequency (Compl. ¶62, ¶63, ¶67).

U.S. Patent No. 7,565,359 - "Dynamic Page Generator"

  • Patent Identification: U.S. Patent No. 7565359, issued July 21, 2009.
  • Technology Synopsis: This patent claims a computer-readable medium containing instructions for generating customized pages. The instructions combine user preferences with a generic template to form a user-specific template, which is then executed using real-time information stored in a shared local storage device to generate the final page (Compl. ¶78).
  • Asserted Claims: Claim 10 (Compl. ¶79).
  • Accused Features: The computer-readable media (e.g., server hard drives) used by Getaround, which allegedly store instructions for generating customized search result pages according to a user's specific parameters and preferences (Compl. ¶80, ¶81).

U.S. Patent No. 9,626,342 - "Dynamic Page Generator"

  • Patent Identification: U.S. Patent No. 9626342, issued April 18, 2017.
  • Technology Synopsis: This patent claims a method performed by a server that generates a unique template program from user-specific information and a generic template. The server then executes this program to create a customized web page that includes real-time information, serves the page, and responds to subsequent requests by retrieving the template program from one of at least two locations based on request frequency (Compl. ¶95, ¶98).
  • Asserted Claims: Claims 1 and 7 (Compl. ¶93).
  • Accused Features: The Getaround.com servers' alleged generation and execution of user-specific template programs to create and serve customized car search results pages containing real-time availability data (Compl. ¶95, ¶96, ¶99).

III. The Accused Instrumentality

Product Identification

  • The Getaround.com website, its associated backend servers, and the car-sharing service it provides (Compl. ¶27).

Functionality and Market Context

  • The Accused Instrumentality is a web-based platform that allows users to rent cars from owners. The complaint alleges that when a user logs in or performs a search, the system generates customized web pages (Compl. ¶28, ¶46). These pages allegedly display content tailored to the user, such as the user's name and search results reflecting real-time car availability (Compl. ¶48, ¶51). The complaint asserts that this customization is achieved by collecting and utilizing user-supplied data, including demographic and location information, to personalize content and select targeted advertisements (Compl. ¶28, ¶30). The complaint includes a screenshot from Getaround's privacy policy detailing the collection of identifying information such as age and address (Compl. p. 14). It further alleges the system uses a combination of generic templates and user-specific data to create executable template programs (e.g., JavaScript) that render the final customized page in a user's browser (Compl. ¶29, ¶49).

IV. Analysis of Infringement Allegations

U.S. Patent No. 8,352,854 Infringement Allegations

Claim Element (from Independent Claim 1) Alleged Infringing Functionality Complaint Citation Patent Citation
receiving a user request for a customized page The system receives requests when a user initiates a login or performs a vehicle search on getaround.com. ¶28 col. 4:12-14
receiving a template program that is unique to the user and based on user configuration information...the user configuration information including user demographic information After a user logs in, the system allegedly uses a JavaScript-based template program that is unique to the user, built from user-supplied data like name, location, and search preferences. ¶29 col. 3:28-39
wherein the template program is received from one of at least two locations, the location determined from the frequency of the user request for the customized page The system allegedly retrieves template components from different locations (e.g., a main server, a CDN server, or local browser cache), with the source being determined by how frequently the user accesses the page. ¶17, ¶29 col. 6:49-59
receiving an advertisement selected in accordance with the user demographic information The system allegedly uses collected demographic and location data to implement and serve targeted advertisements. A screenshot of Getaround's privacy policy is provided to show the collection of such data (Compl. p. 14). ¶30 col. 5:39-45
executing the template program using the selected advertisement to generate the customized page The system allegedly executes JavaScript templates that integrate the selected advertisement to generate the customized page displayed to the user. ¶31 col. 4:4-11
providing the customized page to the user The Getaround.com servers provide the generated page, with integrated advertisements, for display in the user's browser. ¶32 col. 1:51-52

Identified Points of Contention

  • Scope Questions: A central question may be whether Getaround's use of standard web technologies like CDNs and browser caching constitutes receiving a "template program" from a location "determined from the frequency of the user request," as required by the claim. The analysis may focus on whether Getaround employs a specific, user-frequency-driven logic for selecting a retrieval location, or a more general caching strategy.
  • Technical Questions: The complaint alleges that after a user logs in, a user-specific template is used, as evidenced by the display of the user's name (Compl. p. 19). A question for the court may be what evidence shows that this template is retrieved from different locations based on that specific user's login frequency.

U.S. Patent No. 5,983,227 Infringement Allegations

Claim Element (from Independent Claim 2) Alleged Infringing Functionality Complaint Citation Patent Citation
obtaining user preferences, wherein a user's user preferences indicate items of interest to that user The system obtains user preferences when a user inputs search parameters such as location, date, time, and vehicle type. ¶47 col. 3:28-39
obtaining real-time information from information sources The system allegedly obtains real-time car availability information from a multitude of databases or other information sources. ¶48 col. 4:18-24
storing the real-time information in a storage device The complaint alleges that the obtained real-time car availability information is pulled from the information source and stored, at least temporarily, on the getaround.com web/API server and/or the user's computer. ¶48 col. 2:8-14
combining the user preferences for the user and a template to form a template program specific to the user The system allegedly combines a generic webpage template with user-specific data (from login information and search inputs) to create a user-specific, executable template program. The complaint provides a screenshot of underlying code described as a "General template used to generate webpage" (Compl. p. 38). ¶49 col. 3:58-62
receiving, from a user and at the server, a user request for a customized page... The system receives a request when a user logs in or submits a search on the getaround.com website. ¶50 col. 4:12-14
executing the template program specific to the user using the real-time information stored in the storage device...to generate the customized page The system allegedly executes the user-specific template program, using the stored real-time car availability data as input, to generate a customized search results page. ¶51 col. 4:4-11
providing the user with the customized page...performed in real-time response...wherein the customized page includes at least one item of real-time information The system delivers a customized webpage showing available cars in real-time. A screenshot of a search results page is provided as evidence (Compl. p. 34). ¶52 col. 20:13-19

Identified Points of Contention

  • Scope Questions: The interpretation of "storing the real-time information in a storage device" may be a key issue. The dispute could turn on whether temporarily holding data retrieved via an API call for the immediate purpose of rendering a single page meets this limitation, or if the claim requires pre-populating a more persistent, local data store as described in the patent's "shared memory" embodiment.
  • Technical Questions: What evidence demonstrates that the "real-time information" (e.g., car availability) is first "stored" and then separately used as "input" to the template program, as opposed to being fetched and rendered in a single, integrated step, which is common in modern web applications?

V. Key Claim Terms for Construction

  • The Term: "template program ... received from one of at least two locations, the location determined from the frequency of the user request for the customized page" ('854 Patent, Claim 1)
  • Context and Importance: This limitation is central to distinguishing the '854 patent from more generic dynamic page generation methods. The infringement analysis will likely depend on whether Getaround's use of geographically distributed CDNs and local browser caching—common tools for improving general website performance—satisfies the claim's requirement for a frequency-based decision specific to a user's request for a customized page.
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The specification states that for "infrequent users, the user template is stored in a user configuration database, whereas for frequent users the user template may also be stored in cache" ('854 Patent, col. 6:51-54). This language directly links the storage location (database vs. cache) to the frequency of use.
    • Evidence for a Narrower Interpretation: The patent describes a specific architecture where a name server directs a given browser to the same page server to "allow for more efficient caching" ('854 Patent, col. 3:10-14). A party could argue this context limits the claim to a system that actively manages template location based on tracked user frequency, not a passive, universal caching system that incidentally stores popular assets.
  • The Term: "storing the real-time information in a storage device" ('227 Patent, Claim 2)
  • Context and Importance: The viability of the infringement theory for the '227 patent may hinge on the breadth of this term. Practitioners may focus on this term because modern web architectures often retrieve real-time data "just-in-time" via APIs, which may differ from the patent's explicit description of pre-loading a comprehensive set of "live data" into a local "shared memory."
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The Abstract states that "live data used to fill the templates [is] stored local to the page server." This could be argued to encompass any form of temporary server-side storage or caching, however brief, that occurs before the page is sent to the user ('227 Patent, Abstract).
    • Evidence for a Narrower Interpretation: The detailed description explains that the goal is to "eliminat[e] the need to make requests from other servers for portions of the live data" by providing access to a "large region of shared memory which contains all of the live data needed to fill any user template" ('227 Patent, col. 2:8-11). This language may support a narrower construction requiring a comprehensive, pre-populated local data repository rather than transient storage of data fetched on-demand.

VI. Other Allegations

  • Indirect Infringement: The complaint does not plead specific facts to support claims of induced or contributory infringement, focusing its allegations on Getaround's direct operation of the accused system.
  • Willful Infringement: The prayer for relief seeks treble damages for willful infringement (Compl. p. 98, ¶g). However, the complaint's substantive counts only allege that the Defendant had constructive notice of the patents by operation of law, without pleading facts that would suggest pre-suit knowledge of the patents or egregious conduct (Compl. ¶38, ¶54, ¶72, ¶86).

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

  • A core issue will be one of architectural equivalence: do the modern, distributed web architecture and on-demand data retrieval methods allegedly used by Getaround function in the same way as the specific server-centric architecture described in the 1997-priority-date patents, which teach a system centered on a pre-populated, local "shared memory" for all real-time data?
  • A second central question will be one of definitional scope: can claim terms such as a template's location being "determined from the frequency of the user request" and the "storing" of real-time information be construed broadly enough to read on common, general-purpose web optimization techniques like content delivery networks and transient API data caching?
  • A key evidentiary question will be one of causality and specificity: what evidence can be presented to demonstrate that Getaround's system retrieves templates from different locations specifically because of an individual user's request frequency, as opposed to a general system policy, and that it "stores" real-time data as a distinct step before executing a template program?