DCT
2:23-cv-00097
Security First Innovations LLC v. Google LLC
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Security First Innovations, LLC (Virginia)
- Defendant: Google LLC (Delaware)
- Plaintiff’s Counsel: The Law Offices of Charles B. Molster, III PLLC; Irell & Manella LLP
- Case Identification: 2:23-cv-00097, E.D. Va., 03/10/2023
- Venue Allegations: Plaintiff alleges venue is proper in the Eastern District of Virginia because Google maintains a regular and established place of business in Reston, Virginia, and operates data centers within the district that are central to the accused infringing technology.
- Core Dispute: Plaintiff alleges that Defendant’s Google Cloud system, specifically its Encryption At-Rest technology, infringes four patents related to methods for securely parsing, encrypting, and storing data across multiple storage devices.
- Technical Context: The technology concerns advanced data security for cloud computing, where data is split into chunks and encrypted with multiple layers of keys before being distributed across storage infrastructure.
- Key Procedural History: The complaint states that the asserted patents were originally owned by Security First Corporation ("SFC"), which was established in 2002. Plaintiff SFI acquired the patents in 2022. The complaint also notes that SFC's technology has been licensed by companies including Unisys and IBM.
Case Timeline
| Date | Event |
|---|---|
| 2004-10-25 | Earliest Priority Date for ’116 and ’140 Patents |
| 2005-11-18 | Earliest Priority Date for ’854 and ’609 Patents |
| 2010-01-01 | Accused Google Cloud Storage Launch Date (approx.) |
| 2013-08-01 | Accused Google Cloud Server-Side Encryption Launch Date (approx.) |
| 2016-05-10 | ’140 Patent Issued |
| 2019-10-22 | ’854 Patent Issued |
| 2021-07-20 | ’609 Patent Issued |
| 2021-11-16 | ’116 Patent Issued |
| 2023-03-10 | Complaint Filing Date |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 10,452,854 - Secure Data Parser Method And System
The Invention Explained
- Problem Addressed: The patent's background describes how typical public-key cryptographic systems are "highly reliant on the user for security" (’854 Patent, col. 1:60-62). It notes that unsophisticated users often store private keys insecurely on hard drives or backup systems, making them susceptible to compromise (Compl. ¶21; ’854 Patent, col. 1:64-2:8).
- The Patented Solution: The invention proposes a multi-layered security method where a data set is first split into multiple portions, or "shares" (’854 Patent, col. 79:1-8). Each share is then encrypted with its own distinct encryption key. To add another layer of security, these distinct encryption keys are themselves encrypted using an "external key." The encrypted shares are then stored, along with data indicative of their respective encryption keys, across a plurality of different storage devices (Compl. ¶22; ’854 Patent, Abstract). This method ensures that compromising a single storage device or even discovering all the encrypted shares is insufficient to reconstruct the original data without also having the external key (’854 Patent, col. 79:66-80:4).
- Technical Importance: This approach provided a method to enhance data security in distributed systems, such as cloud storage, by moving beyond simple encryption of a whole data set and adding structural security through data splitting and multi-level key management (Compl. ¶¶ 13, 27).
Key Claims at a Glance
- The complaint asserts independent Claim 1 (’854 Patent, col. 83:15-84:22; Compl. ¶68).
- The essential elements of Claim 1 include:
- receiving an external key from an external storage system,
- generating a plurality of data chunks based on the data set,
- distributing the data set into a plurality of shares,
- accessing a plurality of distinct encryption keys,
- encrypting each of the shares with a respective one of the plurality of distinct encryption keys,
- performing an encryption operation based on the external key to further secure the plurality of data chunks; and
- storing with the plurality of data chunks data indicative of at least one of the distinct encryption keys on a plurality of different storage devices.
U.S. Patent No. 11,068,609 - Secure Data Parser Method And System
The Invention Explained
- Problem Addressed: The patent addresses the same security vulnerabilities in prior art cryptographic systems as the related ’854 Patent, focusing on the risks of user-managed private keys and the need for more robust security in mobile and distributed environments (’609 Patent, col. 1:62-2:40; Compl. ¶21).
- The Patented Solution: The invention describes a method executed by a processor that involves a two-tiered key system. The system receives a "first key" (e.g., a master or key-encrypting key) from a storage system. It then generates chunks of data and encrypts each chunk with a distinct "second key" (e.g., a data encryption key). A cryptographic operation is then performed based on the "first key" to further secure the data chunks, such as by encrypting the "second keys" with the "first key." Finally, the encrypted data chunks are stored in memory along with data indicative of their respective "second keys" (’609 Patent, Abstract; col. 2:48-61).
- Technical Importance: The claimed method provides a technical framework for a hierarchical key management system that improves security and efficiency in large-scale storage environments by separating data encryption from key encryption (Compl. ¶¶ 27-28).
Key Claims at a Glance
- The complaint asserts independent Claim 1 (’609 Patent, col. 83:13-84:31; Compl. ¶90).
- The essential elements of Claim 1 include:
- executing code by a processor to perform:
- receiving a first key from a storage system,
- generating a plurality of data chunks based on a data set,
- encrypting each respective data chunk with a respective second key, wherein each of the respective second keys are distinct from each other;
- performing a cryptographic operation based on the first key to further secure the plurality of data chunks; and,
- storing, in a memory coupled to the processor, at least one data chunk of the plurality of data chunks with data indicative of at least one of the distinct encryption keys on at least one storage device.
U.S. Patent No. 11,178,116 - Secure Data Parser Method And System
- Patent Identification: U.S. Patent No. 11,178,116, "Secure Data Parser Method And System," issued November 16, 2021 (Compl. ¶105).
- Technology Synopsis: This patent claims a method for securing a data set by distributing it into a plurality of data chunks, where no single chunk is sufficient to reconstruct the original data. Each chunk is encrypted with a respective key, and the invention centrally involves "obfuscating each of the plurality of different encryption keys" before separately storing each data chunk together with one of the obfuscated keys on different storage devices (Compl. ¶¶ 114, 117, 118).
- Asserted Claims: Independent Claim 1 is asserted (Compl. ¶111).
- Accused Features: The complaint alleges that Google's process of encrypting Data Encryption Keys (DEKs) with a Key Encryption Key (KEK) constitutes the claimed "obfuscating" step, and that storing these "wrapped" DEKs with the data chunks across Google's storage infrastructure infringes the patent (Compl. ¶¶ 117-118).
U.S. Patent No. 9,338,140 - Secure Data Parser Method And System
- Patent Identification: U.S. Patent No. 9,338,140, "Secure Data Parser Method And System," issued May 10, 2016 (Compl. ¶123).
- Technology Synopsis: This patent claims a secure storage network comprising physical storage devices that store a plurality of data "shares" associated with a "session key." A key feature of the claimed system is its configuration to "present to a client device a virtual disk" that is mapped to the physical storage devices "such that physical locations of the shares are hidden from the client device" (Compl. ¶135).
- Asserted Claims: Independent Claim 1 is asserted (Compl. ¶129).
- Accused Features: The complaint accuses Google Drive, alleging that it presents a virtual disk in the form of a file directory to the user, while the underlying encrypted data chunks (the "shares") are stored on a plurality of physical devices in Google's data centers, with the actual storage locations hidden from the client device (Compl. ¶¶ 135-136). The complaint provides a screenshot of the Google Drive user interface as an example of the accused "virtual disk" (Compl. p. 48).
III. The Accused Instrumentality
Product Identification
- The complaint primarily accuses the Google Cloud system, specifically its Google Cloud Storage service and its "Encryption At-Rest" functionality (Compl. ¶¶ 1, 33). For the ’140 Patent, the accused instrumentality is Google Drive (Compl. ¶129).
Functionality and Market Context
- The complaint alleges that Google's Encryption At-Rest system operates by breaking customer data into "chunks" for storage (Compl. ¶39). Each chunk is encrypted at the storage level with an individual Data Encryption Key (DEK). These DEKs are then themselves encrypted, or "wrapped," by a Key Encryption Key (KEK). The KEKs are stored centrally in a service Google calls "Keystore" (Compl. ¶¶ 40-41). The complaint includes a diagram from Google's website illustrating this process of chunking data, encrypting it with a DEK, and distributing the chunks across Google's storage infrastructure (Compl. p. 13). To decrypt data, the system retrieves the wrapped DEK, sends it to the Keystore to be unwrapped using the KEK, and then uses the returned plaintext DEK to decrypt the data chunk (Compl. ¶42). The complaint alleges this encryption is a critical security feature for Google's customers (Compl. ¶¶ 37-38).
IV. Analysis of Infringement Allegations
U.S. Patent No. 10,452,854 Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| receiving an external key from an external storage system, | Google's system uses a Key Encryption Key (KEK) which is stored in a repository Google calls "Keystore," which the complaint alleges is an external storage system. The system receives the KEK from the Keystore to perform cryptographic operations. | ¶71 | col. 79:66-80:4 |
| generating a plurality of data chunks based on the data set... | Google's system breaks user data into "subfile chunks for storage." | ¶73 | col. 57:2-3 |
| distributing the data set into a plurality of shares, wherein each of the shares comprises less than all of the data set, | The complaint equates the "chunks" with the claimed "shares," alleging that Google distributes the data set into a plurality of these chunks, each containing less than the full data set. | ¶75 | col. 57:2-3 |
| accessing a plurality of distinct encryption keys, | Google's system accesses a plurality of distinct Data Encryption Keys (DEKs), stating that "two chunks won't have the same DEK." | ¶76 | col. 58:8-14 |
| encrypting each of the shares with a respective one of the plurality of distinct encryption keys, | Each data chunk (share) is encrypted with its own individual DEK. | ¶77 | col. 57:5-7 |
| performing an encryption operation based on the external key to further secure the plurality of data chunks; and | The system encrypts (wraps) each DEK using a KEK (the alleged external key). This is presented as the further securing operation. A diagram shows a "Request for unwrapping DEK" sent to the Keystore, which holds the KEK (Compl. p. 29). | ¶78 | col. 79:66-80:4 |
| storing with the plurality of data chunks data indicative of at least one of the distinct encryption keys on a plurality of different storage devices. | The system stores the wrapped DEKs with the data chunks and distributes these chunks across its storage systems, which are alleged to be a plurality of different storage devices. A diagram illustrates this distribution across multiple "Google's storage infrastructure" blocks (Compl. p. 30). | ¶79 | col. 57:5-7 |
Identified Points of Contention
- Scope Questions: A primary question may be whether Google's "Keystore" qualifies as an "external storage system" under the patent's definition, given that it is part of the integrated Google Cloud platform. The resolution may depend on whether "external" implies logical, physical, or organizational separation.
- Technical Questions: The analysis may focus on whether storing a wrapped DEK "with" the data chunk meets the claim limitation of storing "data indicative of" the encryption key. Plaintiff alleges it does, as the wrapped DEK is necessary to locate and decrypt the key needed for the data chunk (Compl. ¶79).
U.S. Patent No. 11,068,609 Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| receiving a first key from a storage system, | The system is alleged to receive a "first key" in the form of a KEK from the Keystore, which is alleged to be a "storage system." | ¶94 | col. 62:1-4 |
| generating a plurality of data chunks based on a data set... | Google's system generates a plurality of data chunks by breaking user data into "subfile chunks for storage." | ¶96 | col. 57:2-3 |
| encrypting each respective data chunk ... with a respective second key, wherein each of the respective second keys are distinct from each other; | Each data chunk is encrypted with an individual and distinct "second key" in the form of a DEK. | ¶98 | col. 58:8-14 |
| performing a cryptographic operation based on the first key to further secure the plurality of data chunks; and, | The system performs a cryptographic operation by encrypting (wrapping) the DEKs with the KEK (the "first key"). | ¶99 | col. 62:1-4 |
| storing, in a memory coupled to the processor, at least one data chunk ... with data indicative of at least one of the distinct encryption keys on at least one storage device. | The system stores the DEKs with the data chunks across Google's storage infrastructure, which the complaint alleges meets this limitation. The complaint provides a diagram showing a data chunk and its corresponding DEK stored together in a "Google's storage infrastructure" block (Compl. p. 38). | ¶100 | col. 57:5-7 |
Identified Points of Contention
- Scope Questions: Similar to the ’854 patent, a central issue may be the interpretation of "storage system" and whether the request/response interaction with the Keystore constitutes "receiving" a key in the manner claimed.
- Technical Questions: The construction of the final "storing" limitation will be critical. The parties may dispute whether the accused architecture—where data chunks and their associated wrapped DEKs are stored in distributed systems—maps onto the specific claim language requiring storage "in a memory coupled to the processor...on at least one storage device."
V. Key Claim Terms for Construction
’854 Patent, Claim 1
- The Term: "external storage system"
- Context and Importance: This term is crucial because the infringement theory for the '854 patent hinges on classifying Google's "Keystore" as an "external storage system" from which the KEK is received. Practitioners may focus on this term because its definition will determine whether Google's integrated, multi-component cloud architecture can be mapped onto the claim's requirement for an "external" element.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification discusses the problem of users storing keys on devices accessible via "an open computer system, such as, for example, the Internet," which suggests that "external" could refer to any system accessible over a network, even within the same provider's infrastructure (’854 Patent, col. 1:65-67).
- Evidence for a Narrower Interpretation: The background focuses on user-controlled devices like a "hard drive" or "smartcard," which could imply that "external" means outside the control of the primary data processing system, potentially narrowing the term to exclude an integrated component like Keystore (’854 Patent, col. 1:64-2:32).
’609 Patent, Claim 1
- The Term: "storing, in a memory coupled to the processor, at least one data chunk...with data indicative of...encryption keys on at least one storage device"
- Context and Importance: The precise relationship between the processor's memory and the storage device where the chunk and key data are stored is central to this limitation. Practitioners may focus on this term because Google's distributed architecture, where processing and storage are physically separate but logically connected, presents a complex fact pattern for this claim language.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent's general description of a "secure data parser" that can be integrated into "any suitable system for securely storing...data" suggests the claim is intended to cover a wide variety of architectures, including distributed ones (’609 Patent, Abstract). The term "coupled" can be interpreted broadly to mean communicatively linked, not necessarily physically adjacent.
- Evidence for a Narrower Interpretation: Specific embodiments in the specification might depict a more traditional architecture where the processor, memory, and storage are more tightly integrated components of a single server or device. Such depictions could be used to argue for a narrower construction that does not read on a massively distributed cloud system.
VI. Other Allegations
- Indirect Infringement: The complaint does not provide sufficient detail for analysis of indirect infringement.
- Willful Infringement: The complaint does not contain allegations of willful infringement.
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of architectural definition: Can a logically separate but fully integrated component of a single cloud platform, such as Google's "Keystore," be legally construed as an "external storage system" as required by the '854 patent? The case may turn on whether the court defines "external" based on logical function versus unified ownership and operation.
- A key evidentiary question will be one of functional mapping: Does Google's practice of storing an encrypted key ("wrapped DEK") alongside an encrypted data chunk satisfy the claim requirement of storing "data indicative of" an encryption key? This raises the question of whether an encrypted, unusable key still serves the indicative function contemplated by the patent.
- For the '140 patent, a central question will be one of virtualization: Does a client-side user interface like Google Drive, which abstracts away the physical complexity of distributed cloud storage, constitute a "virtual disk" that "hides" the physical locations of data shares in the manner claimed by a patent conceived before the widespread adoption of such sophisticated abstraction layers?