DCT
3:22-cv-05772
WAG Acquisition LLC v. Google LLC
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: WAG Acquisition, L.L.C. (New Jersey)
- Defendant: Google LLC (Delaware) and YouTube, Inc. (Delaware)
- Plaintiff’s Counsel: Haley & Olson, P.C.; Liston Abramson LLP
- Case Identification: 6:21-cv-00816, W.D. Tex., 08/06/2021
- Venue Allegations: Plaintiff alleges venue is proper in the Western District of Texas because Defendants maintain regular and established places of business, employ technical staff, and operate Google Global Cache servers within the district, where acts of infringement are alleged to have occurred.
- Core Dispute: Plaintiff alleges that Defendants’ YouTube Streaming Services infringe three patents related to methods and systems for improving the delivery of streaming media by transmitting media data in serially-identified chunks at a rate faster than playback to avoid buffering and interruptions.
- Technical Context: The technology addresses latency and reliability issues prevalent in early internet streaming by shifting from a server-paced delivery model to a client-driven "pull" model, designed to provide a more seamless user experience comparable to traditional radio or television.
- Key Procedural History: The complaint does not reference any prior litigation, inter partes review proceedings, or specific licensing history concerning the patents-in-suit.
Case Timeline
| Date | Event |
|---|---|
| 2000-09-12 | ’824, ’594, and ’636 Patent Priority Date |
| 2017-08-08 | U.S. Patent No. 9,729,594 Issued |
| 2017-08-22 | U.S. Patent No. 9,742,824 Issued |
| 2017-09-12 | U.S. Patent No. 9,762,636 Issued |
| 2021-08-06 | Complaint Filing Date |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 9,742,824 - "Streaming Media Delivery System"
(Issued August 22, 2017; the "’824 Patent")
The Invention Explained
- Problem Addressed: The patent’s background section describes the problem of "dropouts" in internet streaming, where transmission delays and data loss cause playback interruptions, and notes that conventional pre-buffering techniques result in significant initial wait times for the user without eliminating subsequent interruptions. (Compl. ¶¶15-16; ’824 Patent, col. 1:35-2:42).
- The Patented Solution: The invention proposes a server-side system that sends media data to the user at a rate "more rapid than the playback rate." This allows the user's buffer to be filled quickly at startup and replenished during playback, creating a data surplus that protects against network interruptions. The system achieves this by responding to requests for specific, serially-identified media data elements from the client. (Compl. ¶18; ’824 Patent, Abstract; col. 4:55-67).
- Technical Importance: This client-pull approach, where the flow of data is regulated by client requests for identifiable chunks rather than paced by the server, was designed to improve the speed and reliability of streaming media to be competitive with traditional broadcast media. (Compl. ¶¶17-19).
Key Claims at a Glance
- The complaint asserts infringement of at least Claim 1. (Compl. ¶25).
- Independent Claim 1 of the ’824 Patent recites a server-side method with the following essential elements:
- Reading a pre-recorded audio or video program from computer-readable media.
- Supplying media data elements representing the program, each having a playback rate.
- Serially identifying the media data elements to indicate a time sequence.
- Storing the media data elements in a data structure.
- Receiving requests from a user system for one or more media data elements, specified by their serial identifiers.
- Sending the requested media data elements to the user system, where the data connection has a data rate more rapid than the playback rate of the elements being sent.
- The complaint does not explicitly reserve the right to assert dependent claims but makes allegations relevant to them, such as the use of a reliable transmission protocol like TCP. (Compl. ¶27).
U.S. Patent No. 9,729,594 - "Streaming Media Delivery System"
(Issued August 8, 2017; the "’594 Patent")
The Invention Explained
- Problem Addressed: The patent addresses the same technical problems of startup delays ("pre-buffering") and playback interruptions ("dropouts") in streaming media as its family member, the ’824 Patent. (Compl. ¶¶15-16; ’594 Patent, col. 1:35-2:42).
- The Patented Solution: The ’594 Patent describes the client-side counterpart to the server system. It claims a media player that sends requests for serially-identified media data elements, receives them over a connection that is faster than the playback rate, and stores them in memory. Crucially, as the media is played, the player "automatically send[s] additional requests for subsequent media data elements" as needed to maintain a target buffer level ("a predetermined number of media data elements in the memory"). (Compl. ¶20; ’594 Patent, Abstract; col. 16:1-33).
- Technical Importance: This solution places the intelligence for managing the data flow and buffer state with the client, allowing the client to proactively "pull" data to prevent its buffer from depleting, thereby ensuring uninterrupted playback. (Compl. ¶20).
Key Claims at a Glance
- The complaint asserts infringement of at least Claim 1. (Compl. ¶35).
- Independent Claim 1 of the ’594 Patent recites a client-side method with the following essential elements:
- Sending requests from a media player for one or more serially identified media data elements.
- Receiving the requested media data elements via a data connection having a data rate more rapid than the playback rate.
- Storing the received media data elements in the media player's memory.
- Playing the received media data elements in series from memory.
- Automatically sending additional requests for subsequent media data elements as required to maintain about a predetermined number of media data elements in memory during playback.
- The complaint makes allegations relevant to dependent claims, such as maintaining a record of the last element received and using a reliable transmission protocol. (Compl. ¶37).
U.S. Patent No. 9,762,636 - "Streaming Media Delivery System"
(Issued September 12, 2017; the "’636 Patent")
- Technology Synopsis: The ’636 Patent claims a server-side method for distributing live audio or video programs. The system receives a continuous, real-time stream from a live source, supplies media data elements representing the program with serial identifiers, stores them, and responds to client requests by sending the elements over a data connection faster than the playback rate. (Compl. ¶44; ’636 Patent, Abstract).
- Asserted Claims: The complaint asserts infringement of at least Claim 1. (Compl. ¶44).
- Accused Features: The accused features are the components of the YouTube Streaming Services responsible for distributing live video programs, which allegedly use "sq" identifiers for time-sequencing media data elements. (Compl. ¶44).
III. The Accused Instrumentality
Product Identification
- The accused instrumentality is identified as the "YouTube Streaming Services." (Compl. ¶2).
Functionality and Market Context
- The complaint alleges that this service delivers both pre-recorded and live streaming video to a wide range of devices. (Compl. ¶2). The server-side functionality involves storing media, breaking it into "chunks" identified by serial identifiers (e.g., "rn" or "sq"), and sending these chunks in response to client "GET" requests. (Compl. ¶¶25-26, 44). The client-side functionality is allegedly embodied in software, such as JavaScript files, that causes a user's device to request these chunks, manage a local buffer, and automatically request more data as needed to ensure continuous playback. (Compl. ¶¶35-36). The complaint provides visual evidence of a streaming request allegedly showing an "rn identifier" used to request a specific video segment. (Compl. p. 10).
IV. Analysis of Infringement Allegations
’824 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| reading...a pre-recorded audio or video program from...computer-readable media; | YouTube Streaming Services distribute pre-recorded video programs that are digitally stored in and read from its server systems. | ¶25 | col. 4:55-58 |
| supplying...media data elements representing the program, each...comprising a digitally encoded portion of the program and having a playback rate; | Media data elements comprise a digitally encoded portion of the program (e.g., video/mp4) with a corresponding playback rate. | ¶25 | col. 4:58-61 |
| serially identifying the media data elements, said serial identification indicating a time sequence... | The media data elements are serially identified by "rn" identifiers, which indicate a time sequence. A provided screenshot shows a request captured mid-stream for a video segment with an "rn identifier 102." | ¶25, p. 10 | col. 4:61-64 |
| storing the media data elements in a data structure under the control of the server system; | The media data elements are stored in a data structure under the control of the server system. | ¶26 | col. 4:64-65 |
| receiving requests...for one or more of the media data elements stored in the data structure, each...specifying one or more serial identifiers... | The server system receives "GET" requests from user systems for media data elements identified by an "rn" number. | ¶26 | col. 5:1-4 |
| responsive to the requests, sending...the one or more media data elements having the...specified serial identifiers...wherein the data connection...has a data rate more rapid than the playback rate... | Responsive to requests, the server sends the corresponding media data elements. The data connection of the server to the user system has a data rate more rapid than the playback rate, and each sending is at a transmission rate as fast as the connection will allow. | ¶26 | col. 5:4-10 |
’594 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| sending requests from the media player...for one or more serially identified media data elements... | JavaScript software provided by Defendants causes the media player to send HTTP GET requests for media data elements identified by a serial identifier. | ¶36 | col. 16:5-15 |
| receiving each of the requested media data elements via the data connection, wherein the data connection has a data rate more rapid than the playback rate... | The instructions cause the media player to receive the requested media data elements over a connection having a data rate more rapid than the playback rate, receiving them as fast as the connection allows. | ¶36 | col. 16:16-22 |
| storing the received media data elements in a memory of the media player; | The instructions cause the media player to store the received media data elements in its memory. | ¶36 | col. 16:23-25 |
| playing the received media data elements in series from the memory of the media player; and | The instructions cause the media player to play the received media data elements back in series from its memory. | ¶36 | col. 16:26-28 |
| as the received media data elements are played, the media player automatically sending additional requests for subsequent media data elements...as required to maintain about a predetermined number of media data elements in the memory...during playing. | As elements are played, the instructions are executable to cause the media player to automatically send additional requests for subsequent elements as required to maintain about a predetermined number of media data elements in its memory during playing. | ¶36 | col. 16:28-33 |
Identified Points of Contention
- Scope Questions: A central question may be whether the identifiers used by YouTube (e.g., "rn", "sq") function as the "serial identifiers" contemplated by the patents. The patents describe these identifiers as enabling a client-pull system where discrete chunks are requested in a specific time sequence. The dispute may focus on whether YouTube's architecture operates on this discrete, chunk-by-chunk request model or involves a more continuous flow with different rate-adaptive mechanisms.
- Technical Questions: For the ’824 Patent, the complaint alleges that data element selection occurs "without depending on the server system maintaining a record of the last media data element that had been sent." (Compl. ¶26). This alleges a "stateless" server selection process. A key question will be what evidence demonstrates that the YouTube servers select data elements based solely on the incoming request's serial identifier, without reference to any session state or record of prior transmissions to that user.
- Technical Questions: For the ’594 Patent, the infringement theory rests on the client-side software "automatically sending additional requests... to maintain about a predetermined number of media data elements in the memory." (Compl. ¶36). The analysis may turn on whether the accused JavaScript code contains logic that actively monitors the buffer level and issues new requests specifically to maintain a target quantity of data elements, as opposed to other buffering strategies (e.g., requesting a fixed look-ahead time or adapting to network conditions).
V. Key Claim Terms for Construction
The Term: "serially identifying the media data elements" (’824 Patent, Claim 1)
- Context and Importance: This term is fundamental to the patents' proposed client-pull architecture. Its construction will determine whether YouTube’s use of identifiers like "rn" and "sq" falls within the claim scope. The definition will be critical to distinguishing the claimed invention from prior art streaming protocols and from potentially non-infringing adaptive streaming methods.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification states that the system operates by "assigning identifiers to the sequential media data elements." (’824 Patent, col. 4:1-3). This general language could support an interpretation that any system of identifiers indicating a time sequence meets the limitation.
- Evidence for a Narrower Interpretation: The detailed description links the identifiers to a system where pointers are maintained to track the "last media data element that has been sent to that user" and the client requests the next element in sequence, suggesting a specific, state-tracked, sequential request-response mechanism. (’824 Patent, col. 7:23-30; col. 11:7-14). This could support a narrower construction requiring more than just time-stamped data chunks.
The Term: "automatically sending additional requests... as required to maintain about a predetermined number of media data elements in the memory" (’594 Patent, Claim 1)
- Context and Importance: This term defines the core client-side intelligence of the ’594 Patent. The infringement analysis hinges on whether the accused YouTube player's software contains this specific buffer-management logic. Practitioners may focus on this term because it requires a specific technical operation: monitoring the quantity of buffered data elements and issuing requests for the purpose of maintaining that quantity.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification describes a system where, as data is played out, "the next sequential data elements are received from the server in such a fashion as to approximately maintain the predetermined number of data elements in the user's buffer." (’594 Patent, col. 6:64-col. 7:2). This could be read to cover any automated request logic that results in a relatively stable buffer level.
- Evidence for a Narrower Interpretation: The claim language "as required to maintain" suggests a causal link—that the requests are sent because they are needed to keep the buffer at a certain level. This could be interpreted to require a specific algorithm that measures the number of elements in the buffer and triggers requests to replenish it to a "predetermined number," as opposed to a simpler scheme that, for example, always requests data five seconds ahead of the current play position.
VI. Other Allegations
- Indirect Infringement: The complaint does not contain specific factual allegations supporting induced or contributory infringement, such as knowledge of the patents and intent to cause infringing acts. The counts are pleaded only as direct infringement under 35 U.S.C. § 271(a). (Compl. ¶¶23, 33, 42).
- Willful Infringement: The complaint does not allege that Defendants had pre-suit or post-suit knowledge of the patents-in-suit or that they engaged in egregious conduct that would support a claim for willful infringement.
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of functional operation: does the YouTube Streaming Service operate on the discrete, client-driven, chunk-request model described in the patents? The case may depend on evidence showing whether YouTube's servers are "stateless" in responding to requests and whether its client players actively manage their buffer by requesting specific, serially-identified data chunks to maintain a predetermined quantity, as the claims require.
- A second key question will be one of definitional scope: can the term "serially identifying," in the context of a 2000-priority-date patent family, be construed to cover modern adaptive bitrate streaming protocols? The outcome may turn on whether YouTube's use of segment identifiers is functionally equivalent to the claimed system for enabling a client to "pull" data, or if it represents a distinct, non-infringing technological approach to stream management.