DCT
1:23-cv-04244
Kove Io Inc v. Google LLC
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Kove IO, Inc. (Delaware)
- Defendant: Google LLC (Delaware)
- Plaintiff’s Counsel: Reichman Jorgensen Lehman & Feldberg LLP
- Case Identification: 1:23-cv-04244, N.D. Ill., 11/14/2023
- Venue Allegations: Plaintiff alleges venue is proper because Defendant is registered to do business in Illinois, maintains regular and established places of business in the district, and has committed the alleged acts of infringement in the district.
- Core Dispute: Plaintiff alleges that Defendant’s cloud storage products, Google Spanner and Google Colossus, infringe patents related to managing and retrieving data location information in distributed networks.
- Technical Context: The technology concerns foundational methods for organizing, locating, and scaling data storage across large networks of servers, which is a core component of modern cloud computing infrastructure.
- Key Procedural History: The complaint notes that in 2004, the MIT Technology Review recognized the distributed data storage technology described in the patents as a top emerging technology.
Case Timeline
| Date | Event |
|---|---|
| 1999-09-14 | U.S. Patent No. 7,103,640 and U.S. Patent No. 7,814,170 Priority Date |
| 2000-06-02 | U.S. Patent No. 7,233,978 Priority Date |
| 2006-09-05 | U.S. Patent No. 7,103,640 Issues |
| 2007-06-19 | U.S. Patent No. 7,233,978 Issues |
| 2010-10-12 | U.S. Patent No. 7,814,170 Issues |
| 2023-11-14 | First Amended Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 7,814,170 - “Network Distributed Tracking Wire Transfer Protocol”
The Invention Explained:
- Problem Addressed: The patent addresses the inefficiency of storing and retrieving data in rapidly growing distributed networks (Compl. ¶¶11-12). Conventional systems relied on centralized or hierarchical indices to track data locations, which became performance bottlenecks and were impractical for the scale envisioned for "cloud" storage (Compl. ¶¶12-13).
- The Patented Solution: The invention describes a system that separates the data from its location information, storing the latter in a dedicated "data location server network" (Compl. ¶29). To find a piece of data, the system applies a hash function to the data's unique "identifier string." The result of the hash determines which of the multiple location servers in the network holds the pointer to the actual data, thereby distributing the lookup workload and enabling scalability (’640 Patent, col. 15:1-15).
- Technical Importance: This distributed lookup architecture provided a method for managing data locations at massive scale, a foundational concept for the high-performance, hyper-scalable cloud storage systems that are now ubiquitous (Compl. ¶15).
Key Claims at a Glance:
- The complaint asserts independent claims 1 (against Google Spanner) and 15 (against Google Colossus) (Compl. ¶¶28, 39).
- Claim 1 (System Claim) Essential Elements:
- A data repository for storing a data entity identified by an identifier string.
- A data location server network with multiple servers storing data location information.
- The portion of location information on a given server is based on a hash function used to organize the location information across the servers.
- Each location server is configured to determine the correct location server based on applying the hash function to the identifier string.
- Claim 15 (Method Claim) Essential Elements:
- Correlating identifiers with network locations where corresponding data entities are stored.
- Receiving a location query from a client at a location server.
- Determining which location server holds the requested information.
- Sending a location response message if the server includes the information.
- Sending a redirect message if the server fails to include the information, where the redirect message identifies which server does include the information.
- The complaint alleges infringement of "one or more claims," thereby reserving the right to assert dependent claims (Compl. ¶27).
U.S. Patent No. 7,233,978 - “Method and Apparatus for Managing Location Information in a Network Separate From the Data to Which the Location Information Pertains”
The Invention Explained:
- Problem Addressed: As distributed systems grow, the servers that manage location information can themselves become bottlenecks, limited by their storage capacity and transaction processing rates (’978 Patent, col. 2:10-15).
- The Patented Solution: The patent discloses a method for scaling the location server system itself. When a "performance criterion" (such as a capacity or transaction limit) on a first location server is met, the system transfers a portion of that server's identifier-location mapping data to a second location server. This process allows the location management infrastructure to expand dynamically to handle increasing load (’978 Patent, col. 2:16-32).
- Technical Importance: This method provides a mechanism for the metadata or location layer of a distributed system to scale, ensuring that the system for finding data can keep pace with the growth of the data itself (Compl. ¶60).
Key Claims at a Glance:
- The complaint asserts independent claim 17 (Compl. ¶59).
- Claim 17 (Method Claim) Essential Elements:
- Providing a transfer protocol to transport identifier and location information.
- Storing location information formatted according to the protocol at a first location server.
- Receiving and storing new identifier-location pairs at the first location server.
- Transferring a portion of the identifiers and associated locations to a second data location server when a performance criterion of the first location server reaches a predetermined performance limit.
- The complaint reserves the right to assert other claims (Compl. ¶58).
U.S. Patent No. 7,103,640 - “Network Distributed Tracking Wire Transfer Protocol”
- Patent Identification: U.S. Patent No. 7,103,640, “Network Distributed Tracking Wire Transfer Protocol,” issued September 5, 2006 (Compl. ¶18).
- Technology Synopsis: This patent describes a method for a client to retrieve data location information in a distributed network. It specifically addresses the scenario where a client requests location information from a first server that does not possess it. In response, the first server transmits a "redirect message" to the client, which contains information the client can use to calculate the location of a second, correct server to which it can re-send the query (’640 Patent, col. 2:33-51).
- Asserted Claims: The complaint asserts independent claim 10 (Compl. ¶78).
- Accused Features: The complaint alleges that when a client of Google's Accused Products has stale or incorrect cached location data for a BigTable "tablet," its request fails, and the system's client library is instructed to "recursively move[] up the tablet location hierarchy" to find the correct server. This process is alleged to be the claimed redirect method (Compl. ¶¶88, 90).
III. The Accused Instrumentality
- Product Identification: Google Spanner and Google Colossus (collectively, the "Accused Products") (Compl. ¶22).
- Functionality and Market Context:
- The complaint describes Google Spanner as a "globally-consistent, scalable relational database" that manages metadata for Google Cloud storage services by dividing user data into chunks called "splits" distributed across servers (Compl. ¶¶23, 32). The complaint provides a diagram illustrating how user data, such as records in a "Singers" table, is partitioned by key ranges and mapped to different Cloud Spanner Servers (Compl. p. 11).
- Google Colossus is identified as the underlying distributed file storage system for Spanner and other Google services. It is alleged to use a distributed metadata model and Google's BigTable database to manage and store metadata for files, enabling massive scalability (Compl. ¶¶24, 42-43). The complaint alleges these products are critical infrastructure that power Google Cloud's revenue growth (Compl. ¶25). A diagram in the complaint illustrates the "Spanner server organization," showing how components like a "zonemaster," "location proxy," and "spanserver" work together within different zones (Compl. p. 14).
IV. Analysis of Infringement Allegations
’170 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| a data repository configured to store a data entity, wherein an identifier string identifies the data entity | Google Spanner stores user data ("data entities") in distributed databases. These data entities are identified by primary keys ("identifier strings"). | ¶32 | col. 1:51-53 |
| a data location server network comprising a plurality of data location servers, wherein data location information for a plurality of data entities is stored in the data location server network | Google Spanner operates a network of servers, including "spanservers" and "location proxies," that store information about the location of data "splits." | ¶¶34-35 | col. 1:33-36 |
| the portion of the data location information included in a corresponding one of the data location servers is based on a hash function used to organize the data location information across the plurality of data location servers | Google's documentation instructs users to employ "application-level sharding" by including a hash of an original ID in the primary key to distribute data evenly across servers and avoid "hotspots." | ¶¶33, 37 | col. 15:1-15 |
| each one of the data location servers is configured to determine the at least one of the plurality of data location servers based on the hash function applied to the identifier string | Spanner's "fast lookup service" allegedly uses the hashed ID portion of the primary key to locate the specific split and server that owns the requested data. | ¶38 | col. 15:1-15 |
- Identified Points of Contention:
- Scope Questions: A potential dispute may arise over whether Google's "application-level sharding," described as a user-implemented schema design technique, satisfies the claim requirement for a system where the servers use a hash function to organize the location information. A court may have to determine if a documented best practice that the system is built to leverage meets the claim language.
- Technical Questions: Regarding the allegations for Claim 15 against Colossus, a key question will be whether a client library's internal, programmatic response to a cache miss (i.e., recursively traversing a tablet location hierarchy) constitutes "sending a redirect message" from a server that "fails to include the location information," as required by the claim (Compl. ¶48).
’978 Patent Infringement Allegations
| Claim Element (from Independent Claim 17) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| A method of scaling at least one of capacity and transaction rate capability in a location server in a system having a plurality of location servers | The Accused Products (Colossus/BigTable) scale by adding servers ("nodes"), which balances the workload of handling data queries. | ¶¶60, 70 | col. 2:16-19 |
| providing a transfer protocol configured to transport identifier and location information | The process of moving a "tablet" (which stores key-to-value mappings) between servers in Colossus is alleged to be the claimed transfer protocol. | ¶¶61-62 | col. 2:20-23 |
| transferring a portion of the identifiers and associated locations to a second data location server when a performance criterion of the first location server reaches a predetermined performance limit | The Accused Products perform "load balancing" by moving tablets between servers when a tablet grows "too large" or to balance server load, which is alleged to be transferring location information based on a performance criterion. | ¶70 | col. 2:29-32 |
- Identified Points of Contention:
- Scope Questions: A central question may be the construction of "transferring a portion of the identifiers and associated locations." The complaint notes that in BigTable, "rebalancing tablets... happens quickly, because the actual data is not copied. Bigtable simply updates the pointers for each node" (Compl. ¶48). The court will likely need to decide if updating pointers in a metadata layer is equivalent to "transferring" the location information itself.
- Technical Questions: The analysis may focus on whether automated system behaviors like splitting a tablet that has "grown too large" or "balancing tablet-server load" meet the claim's requirement of reaching a "predetermined performance limit."
V. Key Claim Terms for Construction
Term: "hash function used to organize the data location information" (’170 Patent, Claim 1)
- Context and Importance: The infringement theory for the ’170 Patent relies on Google Spanner's use of "application-level sharding," where users are encouraged to include a hash in a primary key. The construction of this term will be critical to determining if a system that supports a user-defined hashing scheme for load distribution meets the claim element, which requires the hash to be "used to organize" the information.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent specification describes using a "hashpjw" function for selecting a server from a table, suggesting a system-level use of hashing for routing and distribution (’640 Patent, col. 15:1-15).
- Evidence for a Narrower Interpretation: The specification's primary example of hashing relates to server redirection after an initial query fails, not necessarily the initial organization and storage of the location data itself (’640 Patent, col. 13:28-44).
Term: "predetermined performance limit" (’978 Patent, Claim 17)
- Context and Importance: Infringement of the ’978 Patent is based on the allegation that Google's systems transfer location data via load balancing. The case may turn on whether dynamic, automated processes like splitting a tablet that has "grown too large" or rebalancing server load fall within the scope of a "predetermined performance limit."
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The claim language is general and does not specify the nature of the limit, which could support a reading that includes dynamic thresholds for load or data size.
- Evidence for a Narrower Interpretation: The term "predetermined" could be interpreted to require a specific, fixed threshold (e.g., a server is 95% full) rather than the more fluid, algorithmic triggers that may govern modern cloud load-balancing. The specification does not appear to provide a specific definition.
VI. Other Allegations
- Indirect Infringement: The complaint alleges induced infringement for all asserted patents. The allegations are based on Google's publication of extensive technical documentation, developer guides, tutorials, and white papers that allegedly instruct and encourage users to implement the Accused Products in an infringing manner, for example by using hashed primary keys to achieve load balancing (Compl. ¶¶50-53, 72, 92).
- Willful Infringement: The complaint does not plead facts specifically supporting a claim of willful infringement, such as pre-suit knowledge of the patents. The prayer for relief for each count requests a finding that the case is "exceptional" and an award of attorneys' fees under 35 U.S.C. § 285 (Compl. ¶56.B, ¶75.B, ¶95.B).
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of definitional scope: can claim terms rooted in the patent's specific architecture, such as a server "sending a redirect message," be construed to cover the operations of a modern cloud system's internal client library, which programmatically handles a cache miss by traversing a data hierarchy?
- A key evidentiary question will be one of functional causality: does the alleged infringement of the ’170 Patent arise from the inherent configuration of Google's system, or from optional, user-driven "application-level" design choices that Google merely recommends for performance optimization?
- The case may also turn on a question of technical equivalence: does the process of "rebalancing" data in Google's systems by updating pointers to change a tablet's server assignment constitute "transferring... identifiers and associated locations," or is there a fundamental operational difference from what is described and claimed in the ’978 Patent?