DCT
2:22-cv-01424
WAG Acquisition LLC v. Amazon.com Inc
Key Events
Complaint
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: WAG Acquisition, LLC. (New Jersey)
- Defendant: Amazon.com, Inc., Amazon Web Services, Inc., and Amazon.com Services LLC (Delaware)
- Plaintiff’s Counsel: Haley & Olson, P.C.
- Case Identification: 6:21-cv-815, W.D. Tex., 08/06/2021
- Venue Allegations: Plaintiff alleges venue is proper because Defendants maintain regular and established places of business in the district, including large facilities in Austin, Texas, and have committed acts of infringement there, such as configuring and managing AWS servers used for distributing streaming video.
- Core Dispute: Plaintiff alleges that Defendant’s Amazon Streaming Services infringe three patents related to improving the delivery of streaming media over the Internet to reduce buffering and interruptions.
- Technical Context: The technology concerns methods for delivering streaming media content by breaking it into serially-identified chunks and having a client "pull" them from a server at a rate faster than playback to ensure a smooth user experience.
- Key Procedural History: The complaint states the patents-in-suit were developed by Plaintiff's predecessor, SurferNETWORK. No other procedural history, such as prior litigation or administrative challenges to the patents, is mentioned in the complaint.
Case Timeline
| Date | Event |
|---|---|
| 2000-09-12 | Earliest Priority Date for ’824, ’594, and ’636 Patents |
| 2017-08-08 | U.S. Patent No. 9,729,594 Issues |
| 2017-08-22 | U.S. Patent No. 9,742,824 Issues |
| 2017-09-12 | U.S. Patent No. 9,762,636 Issues |
| 2021-08-06 | Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 9,742,824 - “Streaming Media Delivery System”, issued August 22, 2017
The Invention Explained
- Problem Addressed: The complaint identifies two key problems with prior art internet streaming: significant "buffering" delays before playback could start, and subsequent "stuttering" interruptions if the internet connection was disrupted (Compl. ¶15). The patent specification refers to these interruptions as "dropouts" caused by transmission delays and losses inherent in many Internet protocols (’824 Patent, col. 1:35-41).
- The Patented Solution: The invention proposes a server-side method to solve this problem. Media content is broken into discrete "media data elements" which are serially identified (Compl. ¶17). A client system requests these elements by their identifiers in a "pull" model. The server responds by sending the requested elements at a data rate more rapid than the media's playback rate, allowing the client's buffer to accumulate a reserve of data that protects against interruptions (’824 Patent, Abstract; col. 2:48-51).
- Technical Importance: This approach was designed to create an "Instant On" user experience for internet streaming, making it more competitive with the immediacy and continuity of traditional broadcast media like radio and television (Compl. ¶16).
Key Claims at a Glance
- The complaint’s allegations focus on independent claim 1 (Compl. ¶25).
- Essential elements of claim 1 include:
- A method for distributing a pre-recorded program from a server system.
- Supplying media data elements that are serially identified to indicate a time sequence.
- Storing the elements in a data structure on the server.
- Receiving requests from a user system that specify the serial identifiers of the desired elements.
- In response, sending the requested elements over a data connection that has a data rate "more rapid than the playback rate" of the media.
- The selection of elements to send is done "without depending on the server system maintaining a record of the last media data element sent to the requesting user systems."
- The complaint also makes allegations corresponding to dependent claims, such as the use of a reliable transmission protocol like TCP (Compl. ¶28).
U.S. Patent No. 9,729,594 - “Streaming Media Delivery System”, issued August 8, 2017
The Invention Explained
- Problem Addressed: The patent addresses the same problems of buffering and playback interruptions in early streaming media as the ’824 Patent (Compl. ¶15; ’594 Patent, col. 1:35-41).
- The Patented Solution: This patent claims the client-side (media player) implementation of the streaming solution. The media player sends requests for serially identified data elements, receives them over a connection that is faster than the playback rate, and stores them in its local memory (buffer). Crucially, as the player plays back the media from its buffer, it "automatically send[s] additional requests for subsequent media data elements... as required to maintain about a predetermined number of media data elements in the memory" (’594 Patent, Claim 1; Compl. ¶38). This client-driven logic regulates the data flow to ensure its own buffer remains sufficiently full.
- Technical Importance: By placing control of the data flow with the client, this method allows the player to proactively manage its own buffer and avoid interruptions, contributing to the "Instant On" experience and sustained playback (Compl. ¶¶16, 19).
Key Claims at a Glance
- While not specifying a claim number, the complaint’s allegations for the ’594 patent map directly to independent claim 1 (Compl. ¶38).
- Essential elements of claim 1 include:
- A method for operating a media player to receive and play a program.
- Sending requests for serially identified media data elements.
- Receiving the requested elements over a data connection with a data rate "more rapid than the playback rate."
- Storing the received elements in the player's memory.
- Playing the elements in series from memory.
- Automatically sending additional requests for subsequent elements as required to "maintain about a predetermined number of media data elements in the memory of the media player during playing."
- The complaint alleges infringement of one or more claims of the patent (Compl. ¶40).
U.S. Patent No. 9,762,636 - “Streaming Media Delivery System”, issued September 12, 2017
- Technology Synopsis: The ’636 Patent adapts the core streaming technology for live audio or video programs rather than pre-recorded ones. The patented method involves a server system receiving a continuous, digitally encoded stream from a live source in real time, supplying serially-identified media data elements from that stream, and sending them to user systems in response to client requests (Compl. ¶¶46, 48). As with the other patents, the data connection rate is alleged to be more rapid than the playback rate to avoid interruptions (Compl. ¶48).
- Asserted Claims: The complaint asserts infringement of at least claim 1 (Compl. ¶46).
- Accused Features: The accused functionality is Amazon's distribution of live video programs, such as for Amazon Prime Video, using services that include AWS MediaLive and AWS Elemental Media Package to encode and format live streams for distribution via the CloudFront CDN (Compl. ¶47).
III. The Accused Instrumentality
Product Identification
The accused instrumentality is the "Amazon Streaming Services" platform (Compl. ¶2). This platform is alleged to include Amazon’s CloudFront CDN service as well as processing front-end services like AWS Elemental MediaConvert, AWS Elemental MediaStore, AWS MediaLive, and AWS Media Package (Compl. ¶¶2, 25, 47). Amazon Prime Video is identified as a service that uses this infringing infrastructure (Compl. ¶25).
Functionality and Market Context
The Amazon Streaming Services platform is alleged to provide both pre-recorded ("video on demand") and live streaming for Amazon itself and for third-party content originators (Compl. ¶¶2, 25). The complaint alleges that the platform operates by encoding media into "media data elements" (e.g., mp4 format), assigning them serial numeric identifiers, and storing them (Compl. ¶¶25-27). Client devices then send "GET" requests for these elements by their identifiers, and the server system sends the corresponding elements over a data connection alleged to be faster than the media's playback rate (Compl. ¶27). The complaint alleges Defendants use this technology for their "substantial financial benefit" to achieve responsive and stable media delivery (Compl. ¶2).
IV. Analysis of Infringement Allegations
U.S. Patent No. 9,742,824 Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| reading, by at least one computer of the server system, the pre-recorded audio or video program from the computer-readable media | Defendants distribute pre-recorded "video on demand" (VOD) programs that are digitally stored in and read from their server systems. | ¶24 | col. 19:6-9 |
| supplying... media data elements representing the program... each... having a playback rate | The system provides media data elements (e.g., in video/mp4 format) that each comprise a digitally encoded portion of the program and have a corresponding playback rate. | ¶26 | col. 19:10-14 |
| serially identifying the media data elements, said serial identification indicating a time sequence of the media data elements | The media data elements are serially identified by numeric identifiers that indicate a time sequence. The complaint provides a screenshot showing requests for video segments with incrementing numeric IDs. | ¶26, p. 11 | col. 19:15-18 |
| 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 controlled by the server system before being sent. | ¶27 | col. 19:19-21 |
| receiving requests at the server system... for one or more of the media data elements... each received request specifying one or more serial identifiers | The server system receives "GET" requests from user systems for media data elements identified by their numeric identifiers. The complaint’s screenshot shows a request for a video segment ending in ID 7081219. | ¶27, p. 11 | col. 19:22-28 |
| sending, by the server system, the one or more media data elements... to the requesting user systems corresponding to the requests | The server system sends the media data elements having the serial identifiers that correspond to the client requests. | ¶27 | col. 19:30-34 |
| wherein the data connection between the server system and each requesting user system has a data rate more rapid than the playback rate | In observed streaming sessions, the server-to-user data connection consistently had a data rate more rapid than the playback rate of the media elements being sent. | ¶27 | col. 19:35-39 |
| the one or more media data element sent are selected without depending on the server system maintaining a record of the last media data element sent | The media data elements are selected for sending without the server system depending on a record of the last element it had sent to that specific user. | ¶27 | col. 19:43-47 |
U.S. Patent No. 9,729,594 Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| sending requests from the media player to the media source... for one or more serially identified media data elements | Software on the user's media player device sends requests (e.g., HTTP GET requests) for media data elements that are identified by a serial identifier. | ¶38 | col. 15:36-46 |
| receiving each of the requested media data elements... wherein the data connection has a data rate more rapid than the playback rate | The media player receives the requested media data elements over a data connection having a data rate more rapid than the playback rate. | ¶38 | col. 15:47-53 |
| storing the received media data elements in a memory of the media player | The software instructions cause the media player to store the received media data elements in its memory. | ¶38 | col. 15:54-56 |
| playing the received media data elements in series from the memory of the media player | The software instructions cause the media player to play the received media data elements back in series from its memory. | ¶38 | col. 15:57-59 |
| 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 | As elements are played, the media player automatically sends more requests for subsequent elements as needed to maintain a predetermined number of elements in its memory during playing. | ¶38 | col. 15:60-67 |
Identified Points of Contention
- Scope Questions: A potential issue for the ’824 Patent is the scope of the negative limitation "without depending on the server system maintaining a record of the last media data element sent." Defendants may argue that their servers maintain some form of session state or progress tracking for users that constitutes a "record," and that the selection of which chunk to pre-fetch or prepare "depends" on this record, thereby placing their system outside the claim's scope.
- Technical Questions: For the ’594 Patent, a central evidentiary question will be whether the accused client-side software performs the specific function of "automatically sending additional requests... to maintain about a predetermined number of media data elements in the memory." The complaint makes this allegation based on observation (Compl. ¶38), but discovery into the software's actual logic will be required to determine if it actively monitors and maintains a specific buffer level, or if it uses a different, simpler logic for requesting future chunks that does not meet this claim limitation.
V. Key Claim Terms for Construction
The Term: "without depending on the server system maintaining a record of the last media data element sent" (’824 Patent, Claim 1)
Context and Importance: This negative limitation is central to defining the patented "pull" architecture, distinguishing it from "push" systems where the server dictates the data flow. The infringement analysis for the ’824 patent will hinge on whether Amazon's servers operate in this purely responsive, stateless manner with respect to individual client progress.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation (of what infringes): The specification contrasts the invention with systems where "the timing for the media frames is controlled by the server" (’824 Patent, col. 2:9-10). This may support an interpretation where any system in which the client—not the server—is the primary driver of requests for specific, identified data segments would fall within the claim, regardless of other session data the server might track.
- Evidence for a Narrower Interpretation (of what infringes): The specification describes a system where the user computer is responsible for determining what data it needs next, for example by maintaining a record of the last element received (’824 Patent, col. 4:10-15). A defendant could argue this implies a server that is completely ignorant of a client's playback state, and that any server which tracks user progress for any reason (e.g., QoS, session continuity) is "maintaining a record" on which subsequent data delivery "depends."
The Term: "maintain about a predetermined number of media data elements" (’594 Patent, Claim 1)
Context and Importance: This term defines the core logic of the client-side buffer management. Whether the accused media players perform this specific function, as opposed to a more generalized pre-fetching or time-based requesting scheme, is a critical technical question for infringement.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification describes the goal of keeping the user's buffer filled to a "predetermined level" to avoid dropouts (’594 Patent, col. 1:51-53). This might support a construction where any automated client-side requesting logic that has the effect of keeping the buffer generally full would meet the limitation.
- Evidence for a Narrower Interpretation: The claim language "maintain about a predetermined number" suggests an active process of monitoring the quantity of elements in the buffer and issuing requests specifically to keep that quantity at or near a set target. A defendant may argue that a simpler system, such as one that always requests the next five seconds of content whenever it has less than ten seconds buffered, does not "maintain" a "predetermined number" in the specific manner required by the claim.
VI. Other Allegations
- Indirect Infringement: The complaint does not plead separate counts for indirect infringement. However, the allegations regarding the ’594 Patent state that Defendants provide JavaScript software to users which "causes the user's media consuming device... to make requests" in an infringing manner (Compl. ¶36). These factual allegations could potentially form the basis for a future claim of induced infringement.
- Willful Infringement: The complaint contains no explicit allegations of willful infringement.
VII. Analyst’s Conclusion: Key Questions for the Case
This case appears to center on the specific technical implementation of Amazon's widely used streaming architecture. The key questions for the court will likely be:
- A core issue will be one of architectural functionality: Does Amazon's server system for VOD operate in the stateless, client-driven "pull" manner required by the '824 patent's negative limitation, or does it "maintain a record" of user progress on which data selection "depends"?
- A key evidentiary question will be one of algorithmic equivalence: Does the client-side software used in Amazon's streaming services contain the specific buffer-management logic claimed in the '594 patent—actively working to "maintain about a predetermined number" of data elements in memory—or does it employ a different technical method to achieve a similar outcome?
- A central question of claim scope will be how broadly to interpret the patents' core concepts. Can the patented methods, which describe a novel approach to solving early internet buffering issues, be read to cover the sophisticated, adaptive bitrate streaming technologies that are now common, or is there a fundamental mismatch in technical operation?