Patent 11991234
Obviousness
Combinations of prior art that suggest the claimed invention would have been obvious under 35 U.S.C. § 103.
Active provider: Google · gemini-2.5-pro
Obviousness
Combinations of prior art that suggest the claimed invention would have been obvious under 35 U.S.C. § 103.
An obviousness analysis under 35 U.S.C. § 103 for US Patent 11,991,234 requires a review of prior art that existed before the earliest priority date of April 30, 2004. Based on the patent's description, the core innovations appear to be:
- Segmentation: Breaking media content into small, time-indexed segments ("streamlets").
- Multi-bitrate Encoding: Creating multiple versions of each segment at different bitrates.
- Distributed Encoding: Using a master-host system to assign encoding jobs based on bids to parallelize the creation of these multi-bitrate segments.
- HTTP-based Delivery: Serving these segments as static files via standard web servers, allowing a client to request them dynamically.
A person of ordinary skill in the art (POSITA) in 2004 would likely have been a computer scientist or engineer with experience in digital video compression, network protocols, and distributed computing systems. An argument for obviousness would contend that the key elements of patent '234 were known in the art and a POSITA would have been motivated to combine them.
Potential Obviousness Combinations
1. Combination of HTTP-Based Streaming and Multi-Bitrate Files
A foundational argument for obviousness could be constructed by combining the established concept of HTTP-based "progressive downloading" with the known practice of providing media files in multiple bitrates.
Prior Art Evidence:
- HTTP Progressive Download: By 2004, using standard web servers (HTTP) to deliver media was common. This is often referred to as "progressive download," where a file is downloaded and can start playing before the download is complete. The patent itself acknowledges this, stating, "Another technology, known as ‘progressive downloads,’ attempts to combine the strengths of the [streaming and downloading] technologies."
- Multiple Bitrate Offerings: It was standard practice for content providers like Apple (QuickTime) and RealNetworks (RealPlayer) to offer users multiple versions of the same video file, each encoded for a different connection speed (e.g., "Click here for 56k modem" vs. "Click here for Broadband"). A user would manually select the appropriate file before playback began.
Motivation to Combine:
The primary motivation would be to automate the manual selection process and adapt to changing network conditions during playback, a known problem with streaming. A POSITA would recognize that if a large file could be delivered via HTTP, then breaking that file into smaller, independent pieces would allow a client player to make new decisions about which bitrate to request at the beginning of each piece. This would address the latency and buffering issues inherent in single-file streaming when network quality fluctuates. The motivation is to improve the user experience by eliminating buffering and manual quality selection.Explanation:
A POSITA would start with the concept of serving a video file from a web server. Knowing that different users have different bandwidths, they would encode the video at low, medium, and high bitrates. The next logical step to improve playback resilience would be to break the video into, for example, 10-second chunks. A simple playlist file (like a precursor to a M3U8 manifest) could then list the URLs for each chunk for each bitrate. A client could be programmed to download the first low-bitrate chunk to start quickly, and if the download was fast enough, it could request the next chunk from the medium-bitrate set. This combination directly leads to the core idea of adaptive bitrate streaming over HTTP, as claimed in patent '234, by combining two widely known practices to solve a well-understood problem.
2. Combination of Distributed Computing Principles and Video Encoding
The claim element related to a "master module" assigning encoding jobs to "host computing modules" based on "bids" can be seen as an application of well-established distributed computing principles to the specific problem of video encoding.
Prior Art Evidence:
- Distributed Computing/Load Balancing: By 2004, distributed computing frameworks and load-balancing systems were common in high-performance computing and large-scale web services. Concepts like job scheduling, resource allocation, and using metrics (like processor load or completion time estimates) to distribute tasks across a network of computers were well-understood. The Beowulf cluster concept, for instance, which used commodity hardware for parallel processing, was popular in the 1990s.
- Video Encoding as a Computable Task: Video encoding is a computationally intensive and easily parallelizable task. The encoding of one segment of video does not depend on the encoding of the next segment (though it does depend on the content of previous frames for delta compression).
Motivation to Combine:
The motivation here is speed and efficiency. As described in patent '234, multi-pass encoding of live video is impossible with traditional, monolithic systems because the entire file isn't available (Figure 5b discussion). However, by segmenting the video into "streamlets," each streamlet becomes an independent encoding job. A POSITA tasked with creating a system to encode a live event into multiple bitrates as quickly as possible would naturally turn to parallel processing. Using a master-worker (or master-host) architecture is a standard design pattern for such problems. The "bidding" process described in claim 1 is simply a dynamic load-balancing mechanism; the master assigns the next job to the worker that reports it is most ready or predicts the fastest completion time. This is a common strategy to optimize throughput in a heterogeneous computing environment where hosts may have different capabilities or current workloads.Explanation:
A POSITA would recognize that encoding a single two-second video segment into three different bitrates is a self-contained, repeatable task. To prepare a two-hour movie, thousands of these tasks must be completed. To do this quickly, especially for a live stream, doing them in parallel is the only feasible solution. The inventor's choice of a master module that assigns jobs to hosts based on their "bid" (i.e., their reported availability and processing power) is an obvious implementation of standard distributed computing principles. The motivation is to reduce the delay between the live event and its availability for streaming, a key business driver for online media. Combining a standard distributed computing model with the task of video encoding to solve a speed/efficiency problem would likely be considered obvious.
Conclusion on Obviousness
A strong argument can be made that the claims of US Patent 11,991,234 are obvious under 35 U.S.C. § 103. The invention combines known elements to solve a known problem. The practice of offering multiple bitrate files and the use of HTTP for content delivery were commonplace. Segmenting a file to allow for more granular control is a simple and logical step. Applying established parallel processing and load-balancing techniques to the computationally-heavy task of video encoding is a straightforward engineering solution to the problem of timely content preparation. Therefore, a POSITA in 2004 would have been motivated to combine these existing technologies and would have had a reasonable expectation of success in creating a system for adaptive multi-bitrate streaming over HTTP.
Generated 5/8/2026, 6:45:21 PM