DCT
5:24-cv-01972
Datanet LLC v. Dropbox Inc
Key Events
Amended Complaint
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Datanet LLC (Nevada)
- Defendant: Dropbox Inc. (Delaware)
- Plaintiff’s Counsel: Heim, Payne & Chorush, LLP; Messner Reeves LLP
- Case Identification: 6:22-cv-01142, W.D. Tex., 01/11/2023
- Venue Allegations: Venue is alleged based on Defendant’s principal place of business being located in Austin, Texas, within the district, along with a significant physical presence, advertising, and revenue derived from sales to citizens within the district.
- Core Dispute: Plaintiff alleges that Defendant’s Dropbox file hosting and backup service infringes three patents related to methods for real-time file archiving, multi-stage storage management, and version restoration.
- Technical Context: The technology concerns automated file backup and version control, a foundational feature of modern cloud storage services used for both personal and enterprise data protection.
- Key Procedural History: The asserted patents originated with IPCI, Inc., which developed the technology for a product named "AccuSafe" that was never commercially sold. IPCI assigned the patent portfolio to Plaintiff Datanet LLC in 2018. The complaint notes that the ’478 and ’850 patents were granted term extensions. This filing is a First Amended Complaint.
Case Timeline
| Date | Event |
|---|---|
| 2000-09-21 | Earliest Priority Date for ’478, ’348, and ’850 Patents |
| 2007-01-01 | Defendant Dropbox Inc. was founded |
| 2008-09-01 | Defendant launched its Dropbox service to the public |
| 2013-06-25 | U.S. Patent No. 8,473,478 Issued |
| 2015-12-22 | U.S. Patent No. 9,218,348 Issued |
| 2018-09-20 | IPCI, Inc. assigned the Patent Portfolio to Datanet LLC |
| 2020-03-10 | U.S. Patent No. 10,585,850 Issued |
| 2023-01-11 | First Amended Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 8,473,478 - "Automatic Real-Time File Management Method and Apparatus"
The Invention Explained
- Problem Addressed: The patent describes conventional backup systems (manual, scheduled-based, mirroring) as flawed because they were often complex for users, failed to capture data altered between backup points, and required the backup storage medium to be available and online to function (’478 Patent, col. 1:62–col. 2:35).
- The Patented Solution: The invention proposes a system that automatically captures an "archive file" at the moment a change to an "operating file" is initiated (e.g., upon a save command) (’478 Patent, col. 5:15-24). This archive file is first stored in a temporary location (e.g., an "input buffer"), its location is tracked in a database, and a "smart data management" component later migrates the file through various storage locations to a final, permanent destination, a process that can occur even if the final destination is temporarily offline (’478 Patent, col. 5:30-50, Fig. 1).
- Technical Importance: This approach aimed to provide continuous, "real-time" data protection with minimal performance impact and without the risk of data loss between discrete backup intervals (’478 Patent, col. 2:64-67).
Key Claims at a Glance
- The complaint asserts independent claims 1 (method) and 6 (article of manufacture).
- Independent Claim 1 requires:
- Detecting an instruction by an operating system to perform an operation on a file.
- Creating an archive file and storing it in a "temporary first storage location" that is "temporally proximate" to the operation.
- Searching the temporary location for the archive file in response to a "first event."
- Moving the archive file to a "second storage location" (a "permanent storage location") in response to a "second event."
- Using a database to track the location of the archive file as it moves between temporary, intermediate, and permanent storage locations.
- The complaint reserves the right to assert other claims, including dependent claims (Compl. ¶60).
U.S. Patent No. 9,218,348 - "Automatic Real-Time File Management Method and Apparatus"
The Invention Explained
- Problem Addressed: As a continuation of the ’478 Patent, this patent addresses the same problems of data loss between backup intervals and the complexities of prior backup systems (’348 Patent, col. 1:62–col. 2:35).
- The Patented Solution: The invention is substantively the same as the ’478 Patent, describing a system that captures file versions in response to instructions from a "resident program" and manages their migration from temporary to permanent storage (’348 Patent, Abstract; col. 4:52-56). The claims are structured differently, detailing a multi-step process for archiving files.
- Technical Importance: The technology provides a framework for robust, automated file versioning that is resilient to network or storage unavailability (’348 Patent, col. 3:1-4).
Key Claims at a Glance
- The complaint asserts independent claims 15 (method) and 29 (non-transitory medium).
- Independent Claim 15 requires a method comprising steps (a) to (d):
- (a) Detecting an instruction by a "resident program" to perform an operation on a file.
- (b) Creating an archive file and storing it in a "temporary storage location."
- (c) Identifying the presence of the archive file in the temporary location in response to a "first event."
- (d) Transmitting the archive file to a "second storage location" (intermediate or permanent) in response to a "second event," where the first and second events are different.
- The complaint reserves the right to assert other claims (Compl. ¶84).
U.S. Patent No. 10,585,850 - "Automatic Real-Time File Management Method and Apparatus"
- Technology Synopsis: This patent, also in the same family, focuses on the user-facing process of restoring a file. It describes a method where a user is presented with a collection of previous file versions stored remotely. The user can then select and preview a version before retrieving it from the remote location and replacing the current local version, a technique the complaint alleges saves resources by avoiding unwanted restorations (’850 Patent, Abstract; Compl. ¶33).
- Asserted Claims: The complaint asserts independent claim 10 (method).
- Accused Features: The accused features are Dropbox's version history and file restoration functionalities, which allegedly allow users to view, preview, and restore previous versions of a file stored on Dropbox's servers (Compl. ¶¶106, 108).
III. The Accused Instrumentality
Product Identification
- The "Dropbox" file hosting and backup service (Compl. ¶2).
Functionality and Market Context
- The complaint describes Dropbox as a file storage system that provides encrypted cloud storage for over 700 million users (Compl. ¶¶37, 38). Its core functionality involves a client application that monitors a local "Dropbox folder" on a user's device. When a change is detected (e.g., a new file or an edit to an existing file), the service automatically synchronizes the change with the user's account on Dropbox's servers (Compl. ¶60, chart). The service is alleged to use a local cache for temporary storage before moving files to permanent "Block Storage Servers" (Compl. ¶60, chart; Compl. ¶84, chart). It also offers a "version history" feature that allows users to preview and restore previous file versions for up to 180 days (Compl. ¶¶49, 51).
IV. Analysis of Infringement Allegations
’478 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| In a computing device, a method for archiving files comprising: | The Dropbox service runs on computing devices like computers and phones, providing a method for file archiving. | ¶60 | col. 4:26-28 |
| detecting an instruction by an operating system to perform an operation on an operating file; | Dropbox monitors for file changes and detects the instruction to save modifications to a file. | ¶60 | col. 5:15-18 |
| creating an archive file from the operating file and storing the archive file in a temporary first storage location temporally proximate to the operation being performed on the operating file and responsive to detecting the instruction; | In response to a save instruction, Dropbox creates an archive file from the operating file and temporarily stores it in a local cache. | ¶60 | col. 5:30-34 |
| searching the first temporary storage location for the archive file responsive to the occurrence of a first event; | After storing the file in the cache, Dropbox (acting on an internal message or timer, the "first event") searches the cache for the archive file. | ¶60 | col. 5:47-52 |
| moving the archive file to a second storage location responsive to a second event, the second storage location being a permanent storage location; | In response to determining the file has changed (the "second event"), Dropbox moves the archive file from the cache to its Block Storage Server, the alleged permanent storage location. | ¶60 | col. 6:6-9 |
| after storing the archive file in the first temporary storage location, updating a database...; ...updating the database...; ...updating the database... | Dropbox is alleged to use a number of databases (e.g., sync_history.db, filecache.dbx) to track the location of the archive file as it is stored in the cache, moved to intermediate locations, and finally stored on the Block Storage Server. |
¶60 | col. 5:25-30 |
’348 Patent Infringement Allegations
| Claim Element (from Independent Claim 15) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| (a) the step of detecting an instruction by a resident program in a computing device for performing an operation on an operating file; | The Dropbox application monitors for file changes and, in response to an instruction to save a file, performs an operation such as breaking the file into blocks. | ¶84 | col. 4:52-56 |
| (b) the step of creating an archive file from the operating file and storing the archive file in a temporary storage location temporally proximate to the operation...; | Shortly after a change is made, Dropbox creates an archive file and stores it in a local cache, the alleged temporary storage location. | ¶84 | col. 5:30-34 |
| (c) the step of identifying presence of the archive file in the temporary storage location responsive to the occurrence of a first event; | After storing the file in the cache, an internal message or timer (the "first event") causes Dropbox to search the cache and identify the presence of the archive file. | ¶84 | col. 6:3-5 |
| (d) the step of transmitting the archive file to a second storage location responsive to a second event...an intermediate or a permanent storage location... | After determining the archive file is different from what is already saved (the "second event"), Dropbox transmits the file to an output buffer, another cache, or its Block Storage Server (the "second storage location"). | ¶84 | col. 6:49-54 |
Identified Points of Contention
- Architectural Mapping: A central question will be whether Dropbox’s distributed storage architecture maps onto the specific multi-stage storage model claimed in the patents. The litigation may focus on whether the client-side "cache" functions as the claimed "temporary first storage location" and whether the "Block Storage Server" is the "permanent storage location," and if the data flow between them matches the claimed sequence of moving and transmitting steps.
- Triggering Event: The nature of the "instruction" that triggers the archiving is a potential point of dispute. The court may need to determine if the file system notifications monitored by the Dropbox client constitute "detecting an instruction by an operating system" (’478 patent) or an "instruction by a resident program...for performing an operation" (’348 patent) as required by the claims.
- Functional Evidence for ’850 Patent: For the ’850 patent, infringement will depend on specific evidence of the accused functionality. The complaint provides a screenshot of a "Version history" interface to support its allegations (Compl. p. 23). A key question will be whether this interface and the underlying system meet all limitations of claim 10, such as providing a "presentable representation" for preview and retrieving a "restorable representation" from a remote network. A screenshot of a confirmation dialog is also provided to support the allegation of a "selection to restore" a file (Compl. p. 24).
V. Key Claim Terms for Construction
Term for ’478 Patent: "temporally proximate"
- Context and Importance: This term defines the required timing relationship between a file operation (like a save) and the creation of the archive file. The validity of the "real-time" infringement theory depends on whether Dropbox's synchronization process is "proximate" enough to the file change event.
- Evidence for a Broader Interpretation: The specification describes the capture occurring "just before and/or just after the operation is performed on the operating file" (’478 Patent, col. 5:18-21), language that could support a reading that covers any automated capture triggered by a user's save action.
- Evidence for a Narrower Interpretation: The specification also states, "Preferably, the operating file is captured within a few clock cycles of the detection of the instruction" (’478 Patent, col. 5:22-24). This language may be used to argue for a much stricter, near-instantaneous timing requirement that a cloud-based synchronization service may not meet.
Term for ’348 Patent: "resident program"
- Context and Importance: This term identifies the entity that initiates the action leading to file archival. Practitioners may focus on this term because its construction will determine whether the Dropbox client application, which monitors file system activity, qualifies as the "resident program" that performs the claimed operation, or if it merely reacts to operations performed by other programs.
- Evidence for a Broader Interpretation: The patent defines "Resident Program" as "an operating system (OS) or other program that has control over file operations such as... 'save'..." (’348 Patent, col. 4:52-56). This explicit inclusion of an "other program" could support construing the term to include an application like the Dropbox client.
- Evidence for a Narrower Interpretation: The claim requires "detecting an instruction by a resident program... for performing an operation on an operating file." An argument could be made that the Dropbox client does not issue the instruction for the operation (e.g., the save is issued by Word), but rather detects the result of the operation, potentially creating a mismatch with the claim language.
VI. Other Allegations
- Indirect Infringement: The complaint alleges active inducement under 35 U.S.C. § 271(b). It asserts that Defendant provides customers with instructions, marketing materials, technical support, and user documentation (with URLs provided) that encourage and facilitate the use of the accused infringing features, such as computer backup and version restoration (Compl. ¶¶70, 92, 114).
- Willful Infringement: Willfulness is alleged based on Defendant’s knowledge of the patents, which the complaint asserts exists at least from the filing and service of the original complaint in the case (Compl. ¶¶68, 90, 112). No specific allegations of pre-suit knowledge are made.
VII. Analyst’s Conclusion: Key Questions for the Case
- A central issue will be one of architectural mapping: can Plaintiff demonstrate that the architecture of the Dropbox service, with its client-side cache and cloud-based servers, corresponds to the specific multi-stage "temporary," "intermediate," and "permanent" storage locations, and the database-tracked file migration process, as recited in the claims of the ’478 and ’348 patents?
- A key legal question will be one of definitional scope: can the trigger for Dropbox’s synchronization—the detection of a file system change event—be construed to meet the claim requirement of "detecting an instruction by an operating system" (’478 patent) or "by a resident program" (’348 patent) for performing an operation on a file?
- A primary evidentiary question for the ’850 patent will be one of functional implementation: does the Dropbox "version history" feature, as shown in the complaint's visual evidence, perform each discrete step of the claimed restoration method, particularly the "presenting" of a "presentable representation" for preview, as those terms are likely to be construed by the court?