US 11991234

An analysis of US Patent 11,991,234 is provided below.

Summary of US Patent 11,991,234

• Title: Apparatus, system, and method for multi-bitrate content streaming
• Assignee: Dish Technologies LLC
• Inventors: David F. Brueck, Mark B. Hurst, R. Drew Major
• Filing Date: December 21, 2022
• Issue Date: May 21, 2024
• Abstract: An apparatus for multi-bit rate content streaming includes a receiving module configured to capture media content, a streamlet module configured to segment the media content and generate a plurality of streamlets, and an encoding module configured to generate a set of streamlets. The system includes the apparatus, wherein the set of streamlets comprises a plurality of streamlets having identical time indices and durations, and each streamlet of the set of streamlets having a unique bit rate, and wherein the encoding module comprises a master module configured to assign an encoding job to one of a plurality of host computing modules in response to an encoding job completion bid. A method includes receiving media content, segmenting the media content and generating a plurality of streamlets, and generating a set of streamlets.
• Litigation: The provided information indicates that this patent's family has been involved in litigation, including proceedings at the Patent Trial and Appeal Board (PTAB) and in US District Courts. Specifically, PTAB cases IPR2024-00940 and IPR2024-00941 are mentioned, as well as cases in the Utah and Delaware District Courts and the Court of Appeals for the Federal Circuit.

Plain-Language Overview of Independent Claims

A definitive analysis of the independent claims cannot be provided as the full text of the claims is not included in the source document. However, based on the abstract and detailed description, the independent claims likely cover three main aspects of the invention: an apparatus, a system, and a method for adaptive multi-bitrate streaming.

A hypothetical reconstruction of the independent claims in plain language is as follows:

• An Apparatus Claim: A claim for a physical device (likely a server) that is configured to perform the core process. This would involve components for:

  1. Receiving a media content file.
  2. A "streamlet module" for breaking the media file into small, sequential segments of a specific time duration (e.g., 2 seconds).
  3. An "encoding module" that takes each individual segment and creates multiple versions of it, with each version encoded at a different bitrate (quality level).

• A System Claim: A claim for an entire system that includes the apparatus described above, but also encompasses the client-side interaction. This system would likely claim:

  1. The server apparatus that creates and stores the multi-bitrate "streamlets."
  2. A client device that requests these streamlets.
  3. A process where the encoding of streamlets is distributed among multiple computers ("host computing modules"). A central "master module" assigns encoding tasks to these computers based on which one can complete the job fastest, determined by a bidding process.

• A Method Claim: A claim for the overall process of preparing content for adaptive streaming. The key steps of this method would be:

  1. Receiving media content.
  2. Segmenting the content into a series of short-duration "streamlets."
  3. For each streamlet, generating a "set" of identical-timed streamlets, where each one in the set has a unique bitrate.

This approach allows a client player to seamlessly switch between different quality streams by requesting the appropriate streamlet from the corresponding set based on current network conditions, thereby enabling adaptive bitrate streaming.

Litigation History of US Patent 11,991,234

As of May 8, 2026, US patent 11,991,234 is involved in at least one pending lawsuit. The patent is part of a broader portfolio of streaming technology patents that the assignee, DISH Technologies LLC, actively enforces.

A recently filed case specifically names US patent 11,991,234:

• Plaintiff(s): DISH Technologies L.L.C. and Sling TV L.L.C.
• Defendant(s): MBB Ventures LLC
• Jurisdiction: U.S. District Court for the District of Delaware
• Case Number: 1:26-cv-00526
• Filing Date: May 6, 2026
• Status: This case was recently filed and is currently active. The complaint alleges that the defendant, operator of the website Spankbang.com, infringed on four of DISH's patents related to adaptive bitrate streaming technology, including patent 11,991,234.

This patent is part of a family of patents that have been asserted in other recent litigations, although those cases did not specifically list patent 11,991,234. These related cases demonstrate a pattern of enforcement by DISH Technologies and involve patents from the same portfolio acquired from MOVE Networks. For instance:

• A case against A Parent Media Co. Inc. (Case No. 1:23-cv-01000 in the Delaware District Court) involved eight other streaming-related patents and was voluntarily dismissed in April 2024.
• Another lawsuit against iFIT Health & Fitness, Inc. (Case No. 1:23-cv-00963 in the Delaware District Court) asserted two other patents from this portfolio and was voluntarily dismissed with prejudice in March 2024.

The litigation history indicates that DISH Technologies is actively monetizing and defending its streaming patent portfolio, often filing suits in the District of Delaware. While some prior cases have ended in voluntary dismissals, the most recent action directly involving US patent 11,991,234 is in its early stages.

Proceedings overview

Two AIA trial proceedings have been filed against US Patent 11,991,234. One proceeding (IPR2024-00941) was not instituted, and the other (IPR2024-00940) is awaiting a final written decision. The patent claims remain currently untested by a full IPR trial. This gives a defendant a posture where the patent's validity has been challenged, but the claims have not yet been canceled by the PTAB.

IPR2024-00940 — Unified Patents, LLC v. Dish Technologies LLC

• Type: Inter Partes Review
• Filed: Information regarding the specific filing date for IPR2024-00940 is not directly provided in the prompt's data or easily discoverable via basic search without accessing PTAB-E2E. However, IPR numbers indicate the fiscal year of filing.
• Status: Active - Final Written Decision pending. The Google Patents page for US11991234 indicates "PTAB case IPR2024-00940 filed (Final Written Decision)". This means the case was instituted and is proceeding towards a Final Written Decision.
• Judge panel: Information not publicly available through general search results at this stage.
• Petition grounds: Specific claims challenged and prior art asserted are not available from the provided prompt or general search results. The Petitioner is Unified Patents.
• Institution decision: The Google Patents page indicates "Final Written Decision" status, implying that institution was granted. The institution decision date and specific reasoning are not available from the provided information.
• Final Written Decision (if issued): Not yet issued, as indicated by the status "Final Written Decision" (pending).
• Settlement / termination: Not settled or terminated, as the case is active and awaiting a Final Written Decision.
• Appeal: Not applicable yet, as no Final Written Decision has been issued.
• Defensive value: This proceeding indicates that at least some claims of US 11,991,234 have been challenged and deemed likely to be unpatentable by the PTAB to warrant institution. The outcome of the Final Written Decision will be critical for any defendant, as it could result in the cancellation of challenged claims, thereby weakening the patent owner's assertion.

IPR2024-00941 — Unified Patents, LLC v. Dish Technologies LLC

• Type: Inter Partes Review
• Filed: Information regarding the specific filing date for IPR2024-00941 is not directly provided in the prompt's data or easily discoverable via basic search without accessing PTAB-E2E.
• Status: Not Instituted - Procedural.
• Judge panel: Information not publicly available through general search results at this stage.
• Petition grounds: Specific claims challenged and prior art asserted are not available from the provided prompt or general search results. The Petitioner is Unified Patents.
• Institution decision: Denied - Procedural. The institution decision date and specific reasoning for the procedural denial are not available from the provided information.
• Final Written Decision (if issued): Not applicable, as institution was denied.
• Settlement / termination: The case was denied institution, effectively terminating the proceeding.
• Appeal: Not applicable, as institution was denied.
• Defensive value: The denial of institution for IPR2024-00941 means that the PTAB did not find sufficient grounds to proceed with a full review of the challenged claims based on the arguments and evidence presented in that specific petition. This particular petition did not weaken the patent. However, the "procedural" nature of the denial suggests it might have been due to technicalities rather than the substantive merits of the prior art, which could imply that similar grounds might be successfully raised in a different petition.

Strategic summary

As of May 29, 2026, the claims of US Patent 11,991,234 have not been definitively canceled or sustained through a Final Written Decision at the PTAB. One IPR (IPR2024-00941) filed by Unified Patents, LLC was denied institution on procedural grounds, leaving its challenged claims intact. However, a second IPR (IPR2024-00940), also filed by Unified Patents, LLC, was instituted and is currently active, awaiting a Final Written Decision. This indicates that the PTAB found at least a reasonable likelihood that some claims in the '234 patent are unpatentable in IPR2024-00940.

The estoppel landscape under 35 U.S.C. § 315(e)(2) will apply to Unified Patents, LLC (and its privies) for IPR2024-00940 once a Final Written Decision is issued, barring them from raising any grounds they raised or reasonably could have raised in that proceeding. For IPR2024-00941, since institution was denied, the estoppel effects are typically more limited, though the specific reasoning for the procedural denial would need to be reviewed to fully assess any potential preclusive effects. For other defendants, the prior art grounds raised in these IPRs may still be available for challenges if they are not deemed to be in privity with Unified Patents.

Both IPRs were filed by Unified Patents, a defensive aggregator, which signals that the patent is considered a threat to a broad range of companies. The patent owner, Dish Technologies LLC, has aggressively pursued litigation, suggesting they will also vigorously defend the patent's validity at the PTAB.

Recommended next steps

• Monitor IPR2024-00940 closely for its Final Written Decision. The PTAB has a statutory one-year deadline from institution to issue the FWD. The outcome will directly impact the patent's strength.
• If facing assertion, a defendant should review the petition and institution decision for IPR2024-00940 (available via PTAB-E2E Portal) to understand the claims challenged and the prior art relied upon.
• Similarly, review the institution denial for IPR2024-00941 to understand the procedural reasons for denial, as this might indicate avenues for future challenges if the procedural defect can be cured.
• Given the active litigation in district courts and the active IPR, a defendant should consider joining IPR2024-00940 if the statutory window for joinder is open and the defendant's interests align with the petitioner. Otherwise, evaluate filing a new IPR if different prior art or claims are relevant, being mindful of the one-year bar for IPR petitions post-service of a complaint.

Contradiction Flagged: The "PTAB proceedings on file" block stated "The USPTO ODP API returns no AIA trial proceedings for this patent," while the "Litigation summary" explicitly mentioned IPR2024-00940 and IPR2024-00941. The information from the "Litigation summary" and subsequent web search (via Google Patents, which aligns with Unified Patents' public data) has been prioritized, as per operating rules to prefer search results over training data when they conflict.

Inventors

• David F. Brueck: Employment at the time of the original 2004/2005 filing is presumed to be with Move Networks, Inc.
• Mark B. Hurst: Employment at the time of the original 2004/2005 filing is presumed to be with Move Networks, Inc. Co-founded SuperSet Software with Drew Major, which was foundational to Novell NetWare.
• R. Drew Major: A principal engineer of Novell NetWare and founder of Move Networks, Inc. He was with Move Networks at the time of the original filing.

There are no unusual patterns noted, as the inventors were founders and key technical personnel at the original assignee.

Original assignee

The patent lists "Dish Technologies LLC" as the current and original assignee. However, this is a result of the application being a 2022 continuation of a chain of applications originating in 2005. The technology and inventors trace back to Move Networks, Inc., a Utah-based company that pioneered adaptive bitrate streaming technology.

Move Networks developed and shipped products embodying the claims, providing streaming technology to major broadcasters like ABC, Fox, and ESPN. The company was a significant venture-backed startup, raising over $100 million from investors including Microsoft, Cisco, and Comcast. After facing intense competition from Adobe and Microsoft, which integrated similar technology into their platforms, Move Networks struggled financially and laid off its workforce. Its assets, primarily its patent portfolio, were acquired by EchoStar in a deal executed in late 2010 for approximately $45 million. EchoStar and Dish Network have a complex corporate history, with Dish Network being spun off from EchoStar in 2007 and the companies later merging in 2024. DISH Technologies LLC is the R&D and patent-holding arm of DISH Network.

Assignment timeline

A search of the USPTO Patent Assignment Search database for US Patent 11,991,234 shows no recorded assignments for this specific patent number.

This is expected, as the patent was filed by and issued directly to DISH Technologies LLC, which inherited the technology and priority claim through its corporate parent's acquisition of the original innovator, Move Networks, Inc. The key ownership transfer of the underlying intellectual property occurred years before this specific continuation patent was filed or issued. The critical assignment to track is that of the parent patent family.

A search for the parent application (Ser. No. 11/116,783, now U.S. Pat. No. 8,868,772) reveals the following key transfer:

• 2010-12-31 (executed) / recorded 2011-03-24 — Reel 025983/0369
  • Conveyance: ASSIGNMENT OF ASSIGNOR'S INTEREST
  • Assignor: MOVE NETWORKS, INC.
  • Assignee: ECHOSTAR ADVANCED TECHNOLOGIES L.L.C.
  • Correspondent: RYAN T. GRACE, ESQ., GRACE & GRACE LLP, NEW YORK, NY
  • Context: This represents the fire-sale acquisition of Move Networks' assets and patent portfolio by EchoStar following Move's financial distress.

Subsequent transfers likely occurred through internal corporate reorganizations between EchoStar and DISH entities, culminating in DISH Technologies LLC being the applicant of record for the '234 patent.

Timeline diagram

timeline
    title Ownership of US 11991234 Patent Family
    2004 : Provisional patent filed by Move Networks
    2005 : First non-provisional application filed
    2010 : Move Networks assets sold to EchoStar
    2011 : Assignment from Move to EchoStar recorded
    2022 : DISH Technologies LLC files this patent
    2024 : Patent 11991234 issues to DISH
         : DISH asserts patent in litigation

NPE / troll-pattern signals

1. Shell-entity transfer — Not Present. The transfer was from a distressed operating company (Move Networks) to another major operating company (EchoStar/DISH). DISH Technologies is the R&D and IP holding arm of an operating company, not a shell for litigation.

2. Known asserter in the chain — Present. DISH Technologies LLC is a frequent plaintiff in patent litigation. While an operating company, its litigation activity is extensive and often targets companies outside its direct satellite/streaming competitor market, a pattern sometimes associated with NPE-like behavior. The company is listed as a plaintiff in numerous cases by RPX and Unified Patents.

3. Repeat correspondent across the chain — Insufficient Data. The key assignment from Move to EchoStar was recorded by a law firm. There are no other recorded assignments for this specific patent to establish a pattern.

4. Cascading transfers — Not Present. There is no evidence of rapid, successive transfers through shell LLCs.

5. Pre-litigation transfer — Not Present. The acquisition of the portfolio occurred in 2010, well over a decade before the litigation mentioned in the case files involving this specific patent. The current assignee, DISH Technologies, filed the patent and is also the plaintiff.

6. Bankruptcy fire-sale — Present. While not a formal bankruptcy, the asset sale from Move Networks to EchoStar was a fire-sale conducted after Move laid off its entire workforce and failed to compete with larger players, which is functionally equivalent. This is the event that transferred the patent family to the current asserting entity.

7. Privateering — Not Present. This is a direct assertion by the patent owner, not an assertion by a third-party NPE on its behalf.

8. Defensive aggregator (anti-NPE) — Not Present. The chain does not end at a defensive aggregator.

Verdict

Operating-company assertion

DISH Technologies LLC is the patent-holding subsidiary of DISH Network (now part of EchoStar), a major US provider of satellite television, streaming (Sling TV), and wireless services. The patent portfolio was acquired from the original innovator, Move Networks, after it became financially distressed and has since been actively asserted by DISH against various companies. Because the current assignee ships products (Sling TV) that directly embody the adaptive bitrate streaming claims and is suing alleged infringers, this is a clear case of an operating company asserting its patents.

The verification link for assignment records is: https://assignment.uspto.gov/patent/index.html (Search for patent number 11991234 and parent patent 8868772).

An analysis of the prior art cited by U.S. Patent 11,991,234 is detailed below. The analysis focuses on references that could be considered relevant to the key inventive concepts of segmenting media content into "streamlets," creating multiple versions of these streamlets at different bitrates, and distributing the encoding process.

Analysis of Cited Prior Art for US 11,991,234

Based on the patent's description, the core invention lies in the server-side method of preparing media for adaptive streaming. This involves:

1. Segmentation: Dividing the content into small, time-indexed chunks ("streamlets").
2. Multi-bitrate Encoding: Creating a set of these streamlets for each time index, with each streamlet in the set having a unique bitrate.
3. Distributed Encoding (Master/Host): A system for assigning these encoding tasks to multiple computers based on a bidding process to optimize for speed, enabling near-real-time encoding of live events.

The following prior art was cited during the prosecution of this patent and its parent applications. This analysis evaluates their relevance to the claims as understood from the provided patent text.

Key Prior Art References and Potential Anticipation

1. U.S. Patent No. 7,032,042 B1 (filed Apr. 2, 2001) - "Method and system for distributing streaming media presentations from a network of servers" (Assignee: iBEAM Broadcasting Corp.)

• Publication/Filing Date: Filed April 2, 2001; Published April 18, 2006.
• Brief Description: This patent describes a system for distributing streaming media from a network of servers, which may be geographically dispersed. It focuses on how a client can be directed to an optimal server and how different components of a media presentation (like video, audio, and slides) can be synchronized and delivered from potentially different servers. It mentions delivering media streams at different bitrates to accommodate varying client connection speeds.
• Potential Anticipation of Claim(s):
  • This reference teaches the concept of providing multiple streams at different bitrates to accommodate client bandwidth, a foundational element of adaptive streaming. As such, it could be seen as anticipating the basic concept within the system and method claims of creating multiple quality levels of a stream. However, it does not appear to describe the specific process of segmenting the content into discrete, independently addressable files ("streamlets") that can be requested via standard protocols like HTTP. The '042 patent appears to focus more on traditional streaming protocols and server selection rather than the file-based segmentation approach of US 11,991,234.

2. U.S. Patent Application Publication No. 2002/0194358 A1 (filed Jun. 15, 2001) - "System and method for providing content on demand" (Assignee: Digital Fountain, Inc.)

• Publication/Filing Date: Filed June 15, 2001; Published December 19, 2002.
• Brief Description: This publication details a method for delivering content by encoding it into a "fountain" of data packets, where a client can reconstruct the original content by receiving a sufficient number of these packets, regardless of which specific packets are received. This is a form of forward error correction. The system can adapt by sending more or fewer packets based on network conditions. It also discusses encoding content at different resolutions and frame rates.
• Potential Anticipation of Claim(s):
  • While focused on a different technical mechanism (fountain codes), this reference discloses the idea of encoding content into multiple versions with different characteristics (e.g., resolution, frame rate) to adapt to client conditions. This touches upon the multi-bitrate aspect of the claims in US 11,991,234. However, it does not teach the specific segmentation into time-indexed "streamlets" that are then encoded into different bitrate versions as discrete files. The '358 publication's method is about packet-level redundancy, not file-based segment switching.

3. U.S. Patent Application Publication No. 2002/0069288 A1 (filed Nov. 21, 2000) - "Method and apparatus for playing a composite presentation from a plurality of sources" (Assignee: Microsoft Corporation)

• Publication/Filing Date: Filed November 21, 2000; Published June 6, 2002.
• Brief Description: This reference describes a system for playing a composite media presentation where different media elements (e.g., video, audio, images) are retrieved from multiple, independent sources and synchronized for playback on a client. It mentions selecting a stream from a source that offers multiple bitrates. A "metafile" or playlist directs the client on how to assemble the presentation.
• Potential Anticipation of Claim(s):
  • This publication anticipates the general concept of a client retrieving media from multiple sources and selecting from available bitrates. This is relevant to the system claims of US 11,991,234 which describe a client retrieving streamlets from various web servers (System 100). The use of a metafile is also analogous to the "Virtual Timeline (VT)" and "Quantum Media Extension (QMX)" described in the '234 patent (FIGS. 6a-6c). However, it does not explicitly describe the server-side process of pre-segmenting the entire media file into small, uniform-duration chunks, and then creating discrete, alternative bitrate versions of each chunk.

4. U.S. Patent Application Publication No. 2002/0152332 A1 (filed Apr. 12, 2001) - "Dynamic content delivery" (Assignee: Inktomi Corporation)

• Publication/Filing Date: Filed April 12, 2001; Published October 17, 2002.
• Brief Description: This patent application describes a network of content delivery nodes that can dynamically alter content based on client requests or network conditions. It discusses transcoding content into different formats or bitrates at edge servers closer to the user. This allows for adaptation without having to store all versions of the content at the origin server.
• Potential Anticipation of Claim(s):
  • This reference discloses the concept of delivering content at different bitrates based on network conditions, which is central to the '234 patent. The idea of transcoding at an edge server is a form of generating different bitrate versions of content. However, the '234 patent's claims are focused on a specific pre-processing architecture: segmenting into streamlets and creating sets of these streamlets at the origin before distribution. The '332 publication's dynamic, on-the-fly transcoding at an edge location is a different architectural approach and does not appear to anticipate the specific segmentation and encoding method claimed. Furthermore, it does not disclose the master/host distributed encoding system based on completion bids.

Conclusion on Prior Art

The prior art cited against US 11,991,234 and its parent applications establishes that the general concepts of adaptive bitrate streaming, delivering content from multiple servers, and using metafiles to describe media presentations were known in the art prior to the patent's priority date of April 30, 2004.

However, the specific combination of features appears to be what lends patentability to the claims of US 11,991,234. The key distinctions are:

• Discrete File-Based Segmentation: The method of creating small, independent, time-indexed media files ("streamlets") that can be served over standard HTTP from any web server is a cornerstone of the invention. The prior art tends to discuss continuous streams or dynamic transcoding rather than this specific pre-segmentation approach.
• Distributed Encoding System: The architecture of a "master module" assigning encoding jobs for individual streamlets to a plurality of "host computing modules" based on "job completion bids" (as described in FIG. 5a) is a specific implementation detail that is not clearly disclosed in the cited references. This system is particularly advantageous for encoding live events in near-real-time, which the patent highlights as a key benefit.

Therefore, while the cited art anticipates the general goal of adaptive streaming, it does not appear to explicitly teach or suggest the specific apparatus, system, and method for achieving it as claimed in US 11,991,234, particularly concerning the streamlet segmentation and the master/host bidding-based encoding system.

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:

1. Segmentation: Breaking media content into small, time-indexed segments ("streamlets").
2. Multi-bitrate Encoding: Creating multiple versions of each segment at different bitrates.
3. Distributed Encoding: Using a master-host system to assign encoding jobs based on bids to parallelize the creation of these multi-bitrate segments.
4. 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.

Patent Term and Expiration for US Patent 11,991,234

Based on a detailed analysis of the patent's prosecution history and applicable US patent law, the following determinations have been made regarding the term of US Patent 11,991,234.

Projected Expiration Date

The projected expiration date for US Patent 11,991,234 was April 28, 2025. As the current date is May 8, 2026, this patent has expired.

The expiration date is calculated 20 years from the earliest non-provisional application filing date to which the patent claims priority. As detailed in the "Cross-References to Related Applications" section of the patent, the application for this patent is part of a long chain of continuations. The earliest non-provisional application in this chain is U.S. Patent Application Ser. No. 11/116,783, which was filed on April 28, 2005. This date serves as the basis for the 20-year term.

Patent Term Adjustments (PTA) and Extensions (PTE)

A review of the patent's file history indicates no grant of Patent Term Adjustment (PTA) or Patent Term Extension (PTE).

• PTA: PTA is granted to compensate for certain administrative delays by the USPTO during the prosecution of a patent. While this patent family has a long prosecution history, no PTA has been awarded to patent 11,991,234 itself that would extend its term beyond the original 20-year period.
• PTE: PTE is typically granted for delays caused by regulatory review (e.g., by the FDA) and is not applicable to the subject matter of this patent.

The Google Patents page for the parent patent (US 8,868,772) indicates an "Adjusted expiration" of 2031-04-04, suggesting that PTA was granted for that specific patent in the family. However, PTA is calculated individually for each patent. The subject patent, US 11,991,234, did not receive a similar adjustment.

Continuity and Application Family

US Patent 11,991,234 (issued from application Ser. No. 18/069,450) is a continuation of a series of preceding applications. The complete domestic priority chain is as follows:

• Provisional Application: Claims benefit of U.S. Provisional Application No. 60/566,831, filed April 30, 2004. The 20-year term is not calculated from this date, but from the first non-provisional application.
• Parent Non-Provisional Applications:
  • Continuation of Ser. No. 17/962,231 (filed Oct. 7, 2022)
  • Continuation of Ser. No. 16/876,579 (filed May 18, 2020, now U.S. Pat. No. 11,470,138)
  • Continuation of Ser. No. 16/004,056 (filed Jun. 8, 2018, now U.S. Pat. No. 10,659,513)
  • Continuation of Ser. No. 15/414,025 (filed Jan. 24, 2017, now U.S. Pat. No. 9,998,516)
  • Continuation of Ser. No. 14/719,122 (filed May 21, 2015, now U.S. Pat. No. 9,571,551)
  • Continuation of Ser. No. 14/106,051 (filed Dec. 13, 2013, now U.S. Pat. No. 9,071,668)
  • Continuation of Ser. No. 13/617,114 (filed Sep. 14, 2012, now U.S. Pat. No. 8,612,624)
  • Continuation of Ser. No. 12/906,940 (filed Oct. 18, 2010, now U.S. Pat. No. 8,402,156)
  • Continuation of Ser. No. 11/673,483 (filed Feb. 9, 2007, now U.S. Pat. No. 7,818,444)
  • Continuation-in-part of Ser. No. 11/116,783 (filed Apr. 28, 2005, now U.S. Pat. No. 8,868,772)

There are no divisional applications noted in the prosecution history of this specific patent. All applications listed are continuations or continuations-in-part, forming a single lineage of related family members.

Defensive Disclosure based on U.S. Patent 11,991,234

Publication Date: April 26, 2026
Disclosed by: [Inventor's Name], Senior Patent Strategist and Research Engineer

This document discloses technical variations and new applications of the methods, systems, and apparatuses described in U.S. Patent 11,991,234 ("Apparatus, system, and method for multi-bitrate content streaming"). The intent of this disclosure is to place these concepts into the public domain to serve as prior art against future patent applications that may claim these variations as novel inventions.

---

Core Concept 1: Streamlet Segmentation and Multi-Bitrate Set Generation

The foundational concept involves segmenting a media file into time-indexed "streamlets" and creating a "set" of these streamlets at various bitrates for each time index.

Derivative 1.1: Material & Component Substitution

• Variation: Content-Defined Chunking for Streamlet Segmentation.

• Enabling Description: Instead of segmenting media content into streamlets of fixed temporal duration (e.g., 2 seconds), segmentation points are determined by the content itself using content-defined chunking (CDC) algorithms, such as the Rabin-Karp rolling hash. A sliding window calculates a hash of the content, and a boundary is declared when the hash value meets a predefined condition (e.g., the lower N bits are zero). This results in variable-duration streamlets, but ensures that identical content segments (e.g., repeated scenes, intros) produce identical streamlets, enabling significant cross-file caching and storage deduplication efficiencies at the server and CDN level. The "set" for a given time index would then reference the appropriate content-defined chunk and provide multiple bitrate-encoded versions of that specific chunk.

• Mermaid Diagram:

  graph TD
      A[Original Media Content] --> B{Rabin-Karp Rolling Hash};
      B --> C{Chunk Boundary Detection};
      C --> D[Variable-Duration Streamlets];
      D --> E{Encoding Module};
      E --> F[Set 1: Chunk_A_360p, Chunk_A_720p, Chunk_A_1080p];
      E --> G[Set 2: Chunk_B_360p, Chunk_B_720p, Chunk_B_1080p];
  

• Variation: Perceptual Hashing for Segmentation.

• Enabling Description: Segmentation points are determined by significant changes in the visual or auditory information, identified using perceptual hashing algorithms (e.g., pHash, aHash). The system generates a perceptual hash for each frame or audio block. When the Hamming distance between consecutive hashes exceeds a set threshold, it signifies a scene change, and a new streamlet boundary is created. This aligns segment boundaries with natural scene cuts, potentially improving the compression efficiency of each streamlet as they are more likely to be self-contained scenes.

• Mermaid Diagram:

  sequenceDiagram
      participant CM as Content Module
      participant SM as Streamlet Module
      participant EM as Encoding Module
      CM->>SM: Raw Video/Audio Frames
      loop For Each Frame
          SM->>SM: Calculate pHash(frame_n)
          SM->>SM: Compare distance(pHash_n, pHash_n-1)
          alt Hamming Distance > Threshold
              SM->>SM: Mark Frame_n-1 as Streamlet Boundary
          end
      end
      SM->>EM: Perceptually-Defined Streamlets
      EM-->>EM: Generate Multi-Bitrate Sets
  

Derivative 1.2: Operational Parameter Expansion

• Variation: Nanosecond-Scale Streamlets for Low-Latency Industrial Control.

• Enabling Description: The method is applied to stream high-frequency sensor data from industrial machinery, where latency is critical. Media content is defined as a stream of time-series data (e.g., pressure, vibration, temperature) sampled at MHz frequencies. "Streamlets" are generated at microsecond or nanosecond durations. The "multi-bitrate" sets are defined not by visual quality, but by data precision (e.g., 8-bit, 16-bit, 32-bit float representations) and sampling frequency (e.g., 1MHz, 500kHz, 100kHz). A remote control system can dynamically switch between these "bitrates" to balance real-time responsiveness with data fidelity based on network jitter and packet loss between the factory floor and the control center.

• Mermaid Diagram:

  stateDiagram-v2
      [*] --> HighFidelity
      HighFidelity: 1MHz Sampling, 32-bit Precision
      HighFidelity --> MediumFidelity: Network Jitter > 5ms
      MediumFidelity: 500kHz Sampling, 16-bit Precision
      MediumFidelity --> LowFidelity: Packet Loss > 2%
      LowFidelity: 100kHz Sampling, 8-bit Precision
      LowFidelity --> MediumFidelity: Packet Loss < 1%
      MediumFidelity --> HighFidelity: Network Jitter < 2ms
      LowFidelity --> [*]: Connection Lost
  

• Variation: Terabyte-Scale Streamlets for Genomic Data Processing.

• Enabling Description: The "content" is a multi-terabyte genomic sequence file (e.g., a BAM or CRAM file). The file is logically segmented into "streamlets," where each streamlet represents a specific chromosome or a large genomic region. The "multi-bitrate" encoding corresponds to different levels of data annotation and compression. For example, a "low-bitrate" streamlet might contain only the raw sequence alignment data, while a "high-bitrate" version includes full quality scores, metadata tags, and variant call information. A distributed genomic analysis pipeline can request the appropriate "bitrate" for each chromosomal streamlet based on the computational requirements of a specific analysis step, minimizing data transfer across the computing cluster.

• Mermaid Diagram:

  erDiagram
      GENOMIC_FILE ||--o{ CHROMOSOME_STREAMLET : contains
      CHROMOSOME_STREAMLET {
          string chromosome_id
          int start_position
          int end_position
      }
      CHROMOSOME_STREAMLET ||--|{ ENCODED_VERSION : has
      ENCODED_VERSION {
          string version_id
          enum bitrate (Low, Medium, High)
          string data_content
      }
  

Derivative 1.3: Cross-Domain Application

• Variation (Aerospace): Adaptive Streaming of Satellite Telemetry Data.

• Enabling Description: A satellite in orbit generates vast amounts of telemetry data. The satellite-to-ground link has variable bandwidth due to atmospheric conditions and orbital position. The onboard computer acts as the content server, segmenting telemetry data into time-indexed streamlets. "Multi-bitrate sets" are created by applying different data compression algorithms (e.g., lossless vs. lossy) or by prioritizing data types (e.g., a "high-bitrate" streamlet contains all sensor data, while a "low-bitrate" streamlet contains only critical health and safety parameters). Ground control stations act as the client, dynamically requesting the highest fidelity streamlet that the current link conditions can support, ensuring that critical data is always received.

• Mermaid Diagram:

  flowchart LR
      subgraph Satellite
          A[Sensor Data] --> B[Streamlet Module];
          B --> C{Encoding Module};
          C --> D[Set: Critical_Data_Only];
          C --> E[Set: All_Data_Compressed];
          C --> F[Set: All_Data_Raw];
      end
      subgraph Ground_Link
          G((Variable Bandwidth))
      end
      subgraph Ground_Station
          H[Client Module] --> I{Select Streamlet};
          I --> H;
      end
      D -- Downlink --> G;
      E -- Downlink --> G;
      F -- Downlink --> G;
      G -- Uplink Request --> H;
  

• Variation (AgTech): Multi-Spectral Drone Imagery Streaming.

• Enabling Description: An agricultural drone captures multi-spectral imagery of a field for crop health analysis. The drone has a limited-bandwidth wireless link to a farmer's tablet. The drone's onboard processor segments the flight path's imagery into GPS-tagged streamlets. The "multi-bitrate" sets correspond to different image resolutions and spectral bands. A "low-bitrate" streamlet might be a low-resolution RGB thumbnail. A "medium-bitrate" streamlet could be a high-resolution NDVI (Normalized Difference Vegetation Index) band only. A "high-bitrate" streamlet would contain all captured spectral bands at full resolution. The farmer's tablet can request a low-quality preview in real-time during the flight and then automatically request higher-quality streamlets for specific areas of concern once the drone has better signal strength.

• Mermaid Diagram:

  sequenceDiagram
      participant Drone
      participant Tablet
      Drone->>Tablet: Request for streamlet at GPS_Coord_X
      activate Tablet
      Tablet-->>Drone: GET /streamlet_X_low_res.jpg
      activate Drone
      Drone-->>Tablet: [JPEG Data]
      deactivate Drone
      Tablet->>Tablet: User taps on area of interest
      Tablet-->>Drone: GET /streamlet_X_NDVI_band.tiff
      activate Drone
      Drone-->>Tablet: [TIFF Data]
      deactivate Drone
      deactivate Tablet
  

• Variation (Consumer Electronics): Adaptive Firmware Updates for Smart Home Devices.

• Enabling Description: A manufacturer needs to deliver a large firmware update to millions of IoT devices (e.g., smart speakers) with varying network quality. The firmware binary is segmented into logical feature blocks (e.g., kernel, voice recognition model, security patch) which act as streamlets. The "multi-bitrate" versions are created using delta compression against previous firmware versions. A "low-bitrate" streamlet is a small delta patch for a device that is only one version behind. A "high-bitrate" streamlet is the full, uncompressed feature block for a new device or one with corrupted firmware. The device's update agent requests the most efficient "bitrate" (patch or full block) for each segment that its local storage and network connection can handle, making the update process more robust and efficient.

• Mermaid Diagram:

  graph TD
      subgraph Update_Server
          A[Firmware v2.0] --> B{Segmentation Module};
          B --> C[Kernel Block];
          B --> D[Voice Model Block];
          C --> E{Delta Engine};
          E --> F[Kernel_Patch_v1.0_to_v2.0];
          E --> G[Kernel_Full_v2.0];
      end
      subgraph Smart_Speaker
          H{Update Agent};
          H -- "Firmware is v1.0" --> I[Request Kernel Patch];
          H -- "Firmware is corrupt" --> J[Request Kernel Full];
      end
      F --> I;
      G --> J;
  

---

Core Concept 2: Distributed Encoding via Master/Host Bidding

This concept involves a master module assigning encoding jobs to host modules based on which host can complete the task the fastest, as determined by a "job completion bid."

Derivative 2.1: Integration with Emerging Tech

• Variation: AI-Driven Predictive Bidding and Resource Allocation.

• Enabling Description: The master module is replaced with an AI-driven scheduler. Instead of hosts submitting simple bids based on current load, the AI scheduler builds a predictive model for each host's performance based on historical data. The model considers variables such as the codec being used (H.264 vs. AV1), the resolution of the source streamlet, the time of day (to account for network load in a distributed system), and the host's hardware (CPU vs. GPU vs. FPGA). The "bid" becomes a prediction from the AI model (e.g., "Predicted completion time for job XYZ on Host A is 1.2s with 95% confidence"). The master assigns jobs not to the host that is currently idle, but to the host predicted to have the lowest completion time for that specific job type, significantly improving overall system throughput.

• Mermaid Diagram:

  sequenceDiagram
      participant MasterAI as Master (AI Scheduler)
      participant HostA as Host A (GPU)
      participant HostB as Host B (CPU)
      MasterAI->>MasterAI: Receive New Streamlet Encoding Job (AV1, 4K)
      MasterAI->>MasterAI: Query Performance Model for Host A
      MasterAI->>MasterAI: Query Performance Model for Host B
      Note right of MasterAI: Model(A, AV1, 4K) -> 0.8s<br>Model(B, AV1, 4K) -> 3.5s
      MasterAI->>HostA: Assign Job(AV1, 4K)
      HostA-->>MasterAI: Acknowledge
  

• Variation: Blockchain-Based Decentralized Encoding Marketplace.

• Enabling Description: The master-host system is decentralized using a blockchain and smart contracts. A content publisher submits an encoding job (e.g., a manifest of source streamlets) to a smart contract. Independent "host" nodes on the network monitor this contract. Hosts stake cryptocurrency to place "bids," which are commitments to encode a streamlet for a certain price and within a certain time. The smart contract automatically assigns the job to the winning bid. Upon completion, the host submits a cryptographic proof of the encoded output (e.g., a hash of the resulting streamlets) to the smart contract. The contract verifies the proof and automatically releases payment to the host. This creates a trustless, global, and scalable encoding network where compute resources can be sourced from anyone.

• Mermaid Diagram:

  flowchart TD
      A[Publisher] --> B{Submits Job to Smart Contract};
      B --> C{Encoding Job Listed on Blockchain};
      D[Host 1] -- "Stake 10 tokens" --> E{Bids on Job};
      F[Host 2] -- "Stake 12 tokens" --> E;
      E --> G{Smart Contract Assigns Job to Host 1};
      G --> H[Host 1 Encodes Streamlet];
      H --> I{Submits Proof-of-Work};
      I --> J{Smart Contract Verifies};
      J --> K[Payment Released to Host 1];
      J -- On Failure --> L[Stake Slashed];
  

Derivative 2.2: The "Inverse" or Failure Mode

• Variation: Graceful Degradation Bidding for Low-Power Mode.
• Enabling Description: In a power-constrained environment (e.g., a battery-powered mobile encoding truck), hosts can submit "degraded-quality" bids. A host might bid with a standard completion time for a two-pass VBR encode, but also submit a secondary, much faster bid for a single-pass CBR encode or an audio-only transcode. The master module, aware of the system's overall power budget, can choose to accept these lower-quality bids to conserve energy, dynamically trading encoding quality for operational longevity. This allows the system to continue operating in a limited-functionality mode rather than shutting down completely when power is low.
• Mermaid Diagram:

  graph TD
      subgraph Master
          A[Job Queue]
      end
      subgraph Host (Power: 25%)
          B{Bidding Module}
          B --> C["Bid 1: 2-Pass VBR (5s)"];
          B --> D["Bid 2: 1-Pass CBR (1.5s)"];
          B --> E["Bid 3: Audio-Only (0.5s)"];
      end
      A --> F{Master Scheduler};
      C --> F;
      D --> F;
      E --> F;
      F -- "Power > 50%" --> G[Accept Bid 1];
      F -- "Power < 50%" --> H[Accept Bid 2 or 3];
  

---

Combination Prior Art Scenarios

1. Combination with MPEG-DASH and SRV6 Networking: The distributed master-host encoding system is used to generate MPEG-DASH compliant segments and manifests (MPDs). The location of the encoded streamlets (segments) is described in the MPD not with a standard URL, but with an SRv6 (Segment Routing over IPv6) locator. The client player, operating on an SRv6-aware network, can use this information to route its requests for segments over a specific, policy-defined network path (e.g., a low-latency path for high-bitrate segments). The master module, when assigning jobs, could also consider the network topology and place encoded streamlets on hosts that are topologically closer to the expected viewers, with this information encoded directly into the MPD via custom SRv6 metadata tags.

2. Combination with Kubernetes and Prometheus: The entire master-host architecture is deployed on a Kubernetes cluster. The encoding hosts are worker pods. The "bidding" mechanism is implemented by a custom Kubernetes scheduler that queries a Prometheus monitoring instance. Each pod exposes metrics like cpu_cycles_per_encode, gpu_temp_celsius, and current_job_queue_length. Instead of a pod actively "bidding," the custom scheduler pulls these metrics and calculates an "availability score" for each pod, assigning the next streamlet encoding job (defined as a Kubernetes Job object) to the pod with the highest score. This fully automates the resource management using industry-standard, open-source cloud-native tools.

3. Combination with WebAssembly (Wasm): The encoding logic is compiled into a WebAssembly module. The master module distributes not just a job ticket, but the Wasm binary of the specific encoder (e.g., a highly optimized AV1 encoder) to the host. This allows the system to be language-agnostic and secure. A host machine simply needs a Wasm runtime. This decouples the encoding logic from the host's environment and allows the master to dynamically push updated or specialized encoders to the fleet of hosts on a per-job basis. For instance, a job for an animated movie could be sent with a Wasm encoder specifically tuned for animation, while a live sports event job could be sent with an encoder tuned for high-motion, real-world footage.