1:21-cv-07249
Diatek Licensing LLC v. Vimeocom Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Diatek Licensing LLC (Texas)
- Defendant: Vimeo.com, Inc. (Delaware)
- Plaintiff’s Counsel: Kent & Risley LLC
- Case Identification: 1:21-cv-07249, S.D.N.Y., 08/27/2021
- Venue Allegations: Venue is alleged to be proper because Defendant is registered to do business in New York, has a principal place of business in the district, and has allegedly committed acts of infringement there.
- Core Dispute: Plaintiff alleges that Defendant’s video streaming services, which utilize the HTTP Live Streaming (HLS) protocol, infringe patents related to enabling "trick mode" functionality (e.g., fast forward, rewind) for digital video.
- Technical Context: The patents address methods for efficiently accessing and displaying video during special playback modes, a foundational feature for modern digital video recorders (DVRs) and on-demand streaming platforms.
- Key Procedural History: The complaint does not mention any prior litigation, Inter Partes Review (IPR) proceedings, or licensing history related to the patents-in-suit.
Case Timeline
| Date | Event |
|---|---|
| 1999-11-22 | U.S. Patent No. 7,079,752 Priority Date |
| 2000-11-20 | U.S. Patent No. 7,079,752 Application Filing Date |
| 2003-11-14 | U.S. Patent No. 8,195,828 Priority Date |
| 2004-11-12 | U.S. Patent No. 8,195,828 Application Filing Date |
| 2006-07-18 | U.S. Patent No. 7,079,752 Issue Date |
| 2012-06-05 | U.S. Patent No. 8,195,828 Issue Date |
| 2021-08-27 | Complaint Filing Date |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 7,079,752 - "Process for Recording a Scrambled MPEG Stream," Issued July 18, 2006
The Invention Explained
- Problem Addressed: The patent addresses the difficulty of implementing "trick modes" like fast forward and rewind on scrambled or encrypted digital video streams. Performing these functions typically requires fast access to specific data (e.g., key frames), which is hindered when the entire stream is encrypted and must be descrambled sequentially ('752 Patent, col. 4:21-31).
- The Patented Solution: The invention proposes a process where, in parallel with recording the main scrambled video stream, the system performs a temporary descrambling specifically to "extract therefrom additional data" needed for trick modes, such as pointers to the start of images ('752 Patent, col. 4:38-44). This "additional data" is then recorded, for example in a separate accompanying file, allowing a playback device to quickly access trick mode information without having to descramble the main video file ('752 Patent, col. 5:19-27).
- Technical Importance: This approach enabled the development of DVR-like features for encrypted content, a critical step in the transition from analog to digital video recording and conditional access systems.
Key Claims at a Glance
- The complaint asserts at least independent claim 1 (Compl. ¶22).
- Claim 1 Essential Elements:
- A process for recording a scrambled digital video stream on a recording medium.
- The process includes the steps of:
- descrambling the scrambled data of the stream to extract additional data corresponding to information required by a "trick mode" function (e.g., fast forward, rewind).
- recording these additional data on the recording medium.
- The complaint does not explicitly reserve the right to assert dependent claims.
U.S. Patent No. 8,195,828 - "Method for Discontinuous Transmission, in Sections, of Data in a Network of Distributed Stations...," Issued June 5, 2012
The Invention Explained
- Problem Addressed: Standard web protocols like the HTTP-GET method were originally designed for continuous, complete file transfers. This makes them ill-suited for streaming video trick modes, which inherently require a discontinuous transmission of data (i.e., jumping from one key frame to another while skipping the frames in between) ('828 Patent, col. 2:13-24).
- The Patented Solution: The invention extends the HTTP-GET method to support trick modes. It proposes that a client appliance can send an HTTP-GET request that includes additional parameters specifying a "playback speed parameter and an initial position" ('828 Patent, col. 10:22-24). In response, the source appliance (server) transmits only the selected video frames required for the trick mode in a discontinuous fashion, for example using a "chunked transfer encoding mode" where each chunk contains a selected frame ('828 Patent, col. 10:31-48).
- Technical Importance: The invention describes a way to adapt a ubiquitous and simple web protocol (HTTP) to provide advanced, non-linear playback control for video streams, a core requirement for modern video-on-demand services.
Key Claims at a Glance
- The complaint asserts at least independent claim 1 (Compl. ¶27).
- Claim 1 Essential Elements:
- A method for discontinuous transmission, in sections, of encoded video data in a network.
- The method comprises the steps of:
- creating an HTTP GET request for a fast search operation, with the request stating a "playback speed parameter" and an "initial position."
- transmitting the HTTP GET request to a source appliance.
- receiving a response from the source appliance that provides "discontinuous transmission, in sections, of selected video frames" using an "extended HTTP chunked transfer encoding mode."
- The complaint does not explicitly reserve the right to assert dependent claims.
III. The Accused Instrumentality
Product Identification
The complaint accuses Defendant's services that utilize "HLS for delivery of content" (Compl. ¶22, ¶27). HLS, or HTTP Live Streaming, is a widely used adaptive bitrate streaming protocol.
Functionality and Market Context
HLS functions by segmenting a video stream into short chunks and creating a text-based manifest file (a playlist) that lists these chunks in order. A client player downloads the manifest and then requests the individual video chunks via standard HTTP. This segmented architecture allows for functions like seeking and changing bitrates. The complaint alleges this functionality, used by Vimeo for its customers and viewers, infringes the patents-in-suit (Compl. ¶22, ¶27). No probative visual evidence provided in complaint.
IV. Analysis of Infringement Allegations
The complaint references preliminary claim charts in Exhibits C and D, which were not attached to the publicly filed document. Therefore, the infringement allegations are summarized below in prose based on the complaint's narrative.
'752 Patent Infringement Allegations
The complaint alleges that Vimeo's use of HLS infringes at least claim 1 of the '752 patent (Compl. ¶22). An infringement theory would likely argue that the HLS manifest file (e.g., an M3U8 playlist) corresponds to the claimed "additional data." The creation of this manifest file on a server would be alleged to be the "recording" step. The process of generating the manifest, which requires indexing the video stream to identify segment boundaries, would be mapped to the claimed step of "descrambling...to extract" the necessary trick-mode information.
- Identified Points of Contention:
- Scope Question: A primary issue may be whether the generation of an HLS manifest file during a video transcoding and packaging workflow constitutes "descrambling...to extract" data as contemplated by the patent, which describes the process in the context of a real-time recording from a broadcast stream ('752 Patent, col. 4:53-62).
- Technical Question: What evidence does the complaint provide that Vimeo's process for creating HLS manifests involves the specific step of descrambling a scrambled stream to extract trick mode data, as opposed to creating the manifest from an unscrambled source or as an integrated part of the encoding process?
'828 Patent Infringement Allegations
The complaint alleges that Vimeo's utilization of HLS infringes at least claim 1 of the '828 patent (Compl. ¶27). This theory would likely contend that when a user initiates a trick mode (e.g., seeking forward in a video), the client player's subsequent requests for non-contiguous video segments from the HLS manifest equate to the claimed "HTTP GET request" that "stat[es] a playback speed parameter and an initial position." The server's delivery of only those requested segments would be alleged to be the claimed "discontinuous transmission...using an extended HTTP chunked transfer encoding mode."
- Identified Points of Contention:
- Scope Question: Does a standard HLS client's request for a specific
.tssegment URL from a manifest file meet the claim limitation of an "HTTP GET request...stating a playback speed parameter and an initial position"? The patent appears to describe these parameters as explicit fields within the request itself ('828 Patent, Fig. 2). - Technical Question: Does the HLS protocol, as implemented by Vimeo, use an "extended HTTP chunked transfer encoding mode" as specifically taught by the patent, or does it rely on a series of standard, independent HTTP GET requests for discrete files, a mechanism that may differ from the patented method?
- Scope Question: Does a standard HLS client's request for a specific
V. Key Claim Terms for Construction
'752 Patent, Claim 1: "descrambling of said scrambled data of said stream so as to extract therefrom additional data"
- Context and Importance: This term is the central active step of the invention. The infringement analysis for the '752 patent will depend on whether Vimeo's process for generating HLS manifests can be properly characterized by this language.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent specification does not limit the "descrambling" to a single, specific algorithm. A party could argue that any process that accesses a protected or proprietary video format to produce a separate navigation file (like a manifest) falls within the scope of this term.
- Evidence for a Narrower Interpretation: The specification describes the process in the context of a "conditional access control system" that "temporarily allow[s]...descrambling of the stream" during a recording phase ('752 Patent, col. 5:4-9). A party could argue this limits the term to a specific scenario involving temporary decryption for extraction, rather than a general-purpose video transcoding workflow where the source may not be "scrambled" in the same sense.
'828 Patent, Claim 1: "HTTP GET request...stating a playback speed parameter and an initial position"
- Context and Importance: The infringement case for the '828 patent hinges on whether the communications between a Vimeo client and server during trick play can be mapped to this specific request format.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: A party might argue that a sequence of client actions and requests, taken as a whole, effectively "states" the user's desired speed and new position to the server, even if the parameters are not in a single, formatted HTTP GET request.
- Evidence for a Narrower Interpretation: The patent specification provides an explicit example of the request format, showing
AV_SPEED: forward_3andAV_STARTTIME: 01.02.03.02as distinct lines in the HTTP header ('828 Patent, Fig. 2). A party will likely argue that the claim requires these explicit parameters to be present in the request itself, distinguishing it from standard HLS, where a client typically requests a URL from a manifest without such added parameters.
VI. Other Allegations
- Indirect Infringement: The complaint does not plead specific facts to support a claim for either induced or contributory infringement, such as identifying specific instructions to third parties or components with no substantial non-infringing use.
- Willful Infringement: The complaint makes a request for enhanced damages but does not allege any facts to support a claim of willful infringement, such as pre-suit knowledge of the patents or egregious conduct (Compl. ¶ E).
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of technical mapping: Does the functionality of the industry-standard HLS protocol, as implemented by Vimeo, align with the specific method steps recited in the patent claims? This will likely involve a detailed comparison of how HLS manages trick-play versus the processes for creating an "accompanying file" ('752 patent) or sending a parameterized "HTTP GET request" ('828 patent).
- The case may also turn on definitional scope: Can claim terms rooted in the technological context of the early 2000s, such as "descrambling" a broadcast stream for a local recording ('752 patent) and a novel proposal for extending HTTP GET requests ('828 patent), be construed broadly enough to cover the distinct architecture and operation of a modern, standardized, server-side video streaming protocol like HLS?