US 11470138

Patent Details

• 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: May 18, 2020 (Application No. 16/876,579)
• Issue Date: October 11, 2022
• Abstract: An apparatus for multi-bitrate 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 a set of streamlets having a unique bitrate, 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.

Plain-Language Summary of Independent Claims

Based on the provided patent text for US 11,470,138, I am unable to locate the specific claims section to provide a plain-language summary of each independent claim. Authoritative analysis requires the full text of the claims as granted by the USPTO.

Litigation and Administrative Review of U.S. Patent No. 11,470,138

As of May 8, 2026, U.S. Patent No. 11,470,138, assigned to DISH Technologies LLC, is the subject of multiple legal disputes, including district court litigations and challenges at the Patent Trial and Appeal Board (PTAB).

District Court Litigation

DISH Technologies LLC and its subsidiary Sling TV LLC have asserted this patent in several infringement lawsuits against various companies in the streaming media and technology sectors.

• DISH Technologies LLC et al. v. iFIT Health & Fitness, Inc.

  • Plaintiff(s): DISH Technologies, LLC and Sling TV, LLC
  • Defendant(s): iFIT Health & Fitness, Inc.
  • Jurisdiction: U.S. District Court for the District of Delaware
  • Case Number: 1:23-cv-00963
  • Filing Date: September 1, 2023
  • Status: The case was voluntarily dismissed with prejudice by DISH and Sling TV on March 7, 2024. Each party was ordered to bear its own costs and fees.

• DISH Technologies LLC et al. v. fuboTV Media Inc.

  • Plaintiff(s): DISH Technologies L.L.C. and Sling TV L.L.C.
  • Defendant(s): fuboTV Media Inc.
  • Jurisdiction: U.S. District Court for the District of Delaware
  • Case Number: 1:23-cv-00986
  • Filing Date: September 6, 2023
  • Status: Active. FuboTV Media filed a motion to dismiss, arguing the asserted patent claims are ineligible. In response, DISH sought to amend its complaint to include over a hundred additional claims from the same patents. A court hearing was held on March 25, 2024, and on May 7, 2024, DISH filed a motion for leave to file a First Amended Complaint.

• DISH Technologies LLC et al. v. A Parent Media Co. Inc. et al.

  • Plaintiff(s): DISH Technologies, LLC and Sling TV, LLC
  • Defendant(s): A Parent Media Co. Inc. and A Parent Media Co. USA, Inc.
  • Jurisdiction: U.S. District Court for the District of Delaware
  • Case Number: 1:23-cv-01000
  • Filing Date: September 8, 2023
  • Status: The case was voluntarily dismissed by DISH and Sling TV on April 29, 2024, without a ruling on the merits. The specific terms of the dismissal were not made public.

• DISH Technologies LLC et al. v. WebGroup Czech Republic A.S. et al.

  • Plaintiff(s): DISH Technologies LLC and Sling TV LLC
  • Defendant(s): WebGroup Czech Republic A.S. and NKL Associates SRO
  • Jurisdiction: U.S. District Court for the District of Utah
  • Case Number: 2:23-cv-00553
  • Filing Date: August 22, 2023
  • Status: Active. The defendants filed a motion to transfer venue.

• DISH Technologies LLC et al. v. Spankbang.com (MBB Ventures LLC)

  • Plaintiff(s): DISH Technologies LLC and Sling TV LLC
  • Defendant(s): MBB Ventures LLC (operator of Spankbang.com)
  • Jurisdiction: U.S. District Court for the District of Delaware
  • Case Number: Not specified in the provided information.
  • Filing Date: May 2026
  • Status: Recently filed. The lawsuit alleges infringement of patent 11,470,138 and others related to adaptive bitrate streaming technology.

Patent Trial and Appeal Board (PTAB) Proceedings

The validity of US patent 11,470,138 has also been challenged through inter partes review (IPR) petitions filed with the PTAB.

• Aylo Freesites Ltd. v. DISH Technologies L.L.C.

  • Case Number: IPR2024-00044
  • Status: A petition for inter partes review was filed. The current status of this proceeding is "Final Written Decision" according to the provided information.

• fuboTV Media Inc. f/k/a fuboTV Inc. v. DISH Technologies L.L.C.

  • Case Number: IPR2024-00901
  • Status: This IPR is related to U.S. Patent No. 11,677,798 B2, which is often litigated alongside 11,470,138. The search results do not specify if patent 11,470,138 is directly part of this IPR, but it is a related proceeding to the district court case against FuboTV.

The extensive litigation and administrative challenges indicate that U.S. Patent No. 11,470,138 is a significant asset for DISH Technologies, which the company is actively enforcing. The pattern of litigation followed by voluntary dismissals in some cases may suggest that settlements are being reached.

Proceedings overview

As of May 29, 2026, U.S. Patent No. 11,470,138 has been challenged in two inter partes review (IPR) proceedings at the PTAB. One proceeding, IPR2024-00044, reached a Final Written Decision, while IPR2025-00469 was not instituted due to procedural reasons.

IPR2024-00044 — Aylo Freesites Ltd. v. DISH Technologies L.L.C.

• Type: Inter Partes Review
• Filed: The precise filing date for the petition is not explicitly provided in the patent text, but the status indicates "Final Written Decision" for IPR2024-00044.
• Status: Final Written Decision
• Judge panel: Not publicly available in the provided text.
• Petition grounds: Not publicly available in the provided text.
• Institution decision: Not publicly available in the provided text.
• Final Written Decision (if issued): The provided text indicates that IPR2024-00044 reached a "Final Written Decision" but does not specify the claim-level outcome or the panel's reasoning.
• Settlement / termination: Not publicly available in the provided text.
• Appeal: Not publicly available in the provided text.
• Defensive value: Without the claim-level outcomes of the Final Written Decision, the defensive value of this proceeding for a defendant is unclear. If claims were invalidated, it could significantly weaken an assertion.

IPR2025-00469 — Petitioner: [Not specified] v. DISH Technologies L.L.C.

• Type: Inter Partes Review
• Filed: The precise filing date for the petition is not explicitly provided in the patent text, but the status indicates "Not Instituted - Procedural" for IPR2025-00469.
• Status: Not Instituted - Procedural
• Judge panel: Not publicly available in the provided text.
• Petition grounds: Not publicly available in the provided text.
• Institution decision: Not Instituted - Procedural. The provided text states the status as "Not Instituted - Procedural". This indicates that the PTAB did not proceed with a full review, likely due to a technical or procedural deficiency in the petition itself, rather than a judgment on the merits of the patentability arguments.
• Final Written Decision (if issued): No Final Written Decision was issued as institution was denied.
• Settlement / termination: Not publicly available in the provided text.
• Appeal: Not publicly available in the provided text.
• Defensive value: This proceeding offers no direct defensive value as no claims were invalidated, and the institution was denied on procedural grounds, not on the merits of the prior art. It does not prevent future IPR challenges on substantive grounds.

Strategic summary

U.S. Patent No. 11,470,138 has faced challenges at the PTAB, with one inter partes review (IPR2024-00044) reaching a Final Written Decision. However, the provided information does not detail which claims, if any, were cancelled or sustained in that decision. A second IPR (IPR2025-00469) was not instituted due to procedural reasons, meaning the claims were not substantively reviewed in that instance.

The lack of detailed outcomes for IPR2024-00044 makes it difficult to ascertain which claims of US 11,470,138 are now canceled versus sustained versus untested. To fully understand the estoppel landscape and which prior-art grounds are still available for a defendant, the contents of the Final Written Decision for IPR2024-00044 would need to be reviewed. The information does not indicate if the same petitioner filed multiple IPRs or if the patent owner pursued PTAB appeals aggressively. There is no indication of a defensive aggregator like Unified Patents in the chain of PTAB proceedings.

Recommended next steps

To understand the full defensive value and the status of claims for a defendant, the Final Written Decision for IPR2024-00044 needs to be thoroughly reviewed. This document would specify which claims were found unpatentable and provide the PTAB's reasoning. A defendant facing assertion of this patent should:

• Obtain and analyze the full Final Written Decision for IPR2024-00044 to determine the exact claim-level outcomes. This decision would be publicly available on the USPTO PTAB Decisions portal.
• Based on the FWD, assess the validity of any claims being asserted against them. If asserted claims were canceled, this forms a strong basis for defense.
• Consider the procedural denial of IPR2025-00469 as a technicality, which does not preclude new, well-formed IPR petitions against the patent.

Inventors

The inventors listed on U.S. Patent 11,470,138 are:

• David F. Brueck
• Mark B. Hurst
• R. Drew Major

At the time of the original invention (priority date April 30, 2004), the inventors were associated with Move Networks, Inc., a pioneer in adaptive bitrate streaming technology. R. Drew Major was a co-founder of Novell, and later founded Move Networks. The technology and associated patent portfolio were later acquired by DISH Network. There are no unusual patterns, such as mass departures, associated with the inventors. The transfer of the intellectual property occurred as part of a corporate acquisition of the technology.

Original Assignee

The "Current Assignee" listed on the patent face is Dish Technologies LLC. This entity is the research and development subsidiary of DISH Network Corporation, a major U.S. provider of satellite television, and a direct-to-consumer streaming provider through its subsidiary, Sling TV.

DISH and its subsidiaries ship products and services that embody the claims of the patent, most notably the Sling TV service and the DISH Anywhere streaming platform, both of which rely on adaptive bitrate streaming technology. DISH Network is an active, publicly traded operating company.

Assignment Timeline

A search of the USPTO Patent Assignment Database for U.S. Patent No. 11,470,138 reveals two assignments, which formally vest the rights from the inventors to the current assignee.

• 2020-05-18 (executed) / recorded 2020-05-18 — Reel 054707/0401

  • Conveyance: Assignment of Assignors Interest
  • Assignor: David F. Brueck, Mark B. Hurst, R. Drew Major
  • Assignee: Dish Technologies L.L.C.
  • Correspondent: Thomas W. Cook, McAfee & Taft A Professional Corporation, 10th Floor, Two Leadership Square, 211 N. Robinson, Oklahoma City, OK 73102.
  • Context: Standard assignment from the named inventors to their employer/successor-in-interest, recorded on the same day the application for this patent was filed.

• 2021-04-05 (executed) / recorded 2021-04-05 — Reel 058316/0927

  • Conveyance: Assignment of Assignors Interest
  • Assignor: Mark B. Hurst, R. Drew Major
  • Assignee: Dish Technologies L.L.C.
  • Correspondent: Thomas W. Cook, McAfee & Taft A Professional Corporation, 10th Floor, Two Leadership Square, 211 N. Robinson, Oklahoma City, OK 73102. This is the same correspondent as the prior assignment.
  • Context: A confirmatory or "clean-up" assignment from two of the inventors to the same assignee, likely to ensure the chain of title is clean for all assets in the patent family.

Timeline Diagram

timeline
    title Ownership of US 11470138
    2004 : Priority Date (Move Networks)
    2005 : First non-provisional application filed
    2010 : DISH Network acquires Move Networks assets
    2020 : Application for '138 patent filed
         : Inventors assign rights to Dish Technologies
    2021 : Confirmatory assignment recorded
    2022 : Patent Issued to Dish Technologies
    2023 : DISH begins asserting patent in litigation

NPE / troll-pattern signals

1. Shell-entity transfer: Not present. The assignee, Dish Technologies LLC, is the R&D subsidiary of DISH Network, a large, well-known operating company. The patent remains with its originating corporate family.

2. Known asserter in the chain: Not present. While DISH is an active litigant, it is an operating company asserting its own patents, not a Non-Practicing Entity (NPE). It does not appear on public lists of patent trolls.

3. Repeat correspondent across the chain: Present, but not indicative of NPE activity. The same correspondent, Thomas W. Cook of McAfee & Taft, appears on both assignments (Reel 054707/0401 and 058316/0927). This represents standard corporate practice where a company uses a consistent outside counsel for its patent portfolio management.

4. Cascading transfers: Not present. There are no rapid, sequential transfers through multiple LLCs. The chain of title is a simple, two-step transfer from the inventors to the operating company.

5. Pre-litigation transfer: Not present. The assignments were recorded in 2020 and 2021 to perfect title, well before the litigation campaign began in August 2023. These actions are consistent with corporate IP hygiene, not a transfer for the purpose of litigation.

6. Bankruptcy fire-sale: Not present. The assignment chain does not involve a bankruptcy proceeding.

7. Privateering: Not present. DISH is asserting the patent directly (via its subsidiaries) rather than transferring it to a third-party NPE to sue on its behalf.

8. Defensive aggregator (anti-NPE): Not present. The patent is held by DISH for assertive purposes and has not been transferred to a defensive organization.

Verdict

• Operating-company assertion

The ownership history is straightforward and does not exhibit any characteristics of NPE or "patent troll" activity. The patent originated with inventors at Move Networks, whose assets were acquired by DISH Network. The assignment chain shows a clean transfer of rights from the inventors to DISH Technologies LLC, the R&D arm of DISH. The subsequent litigation campaign is being waged directly by DISH and its subsidiary (Sling TV) against competitors in the video streaming market. This is a clear case of an operating company enforcing its own intellectual property rights.

This analysis can be verified by reviewing the records at the USPTO Patent Assignment Search.

Prior Art Analysis for U.S. Patent No. 11,470,138

This analysis reviews prior art references cited during the prosecution of U.S. Patent No. 11,470,138 ("the '138 patent"). The independent claims (1, 14, and 19) of the '138 patent generally describe a method, system, and apparatus for streaming media by:

1. Segmenting media content into sequential "streamlets."
2. Encoding each streamlet into a set of streamlets, where each streamlet in the set corresponds to the same time index but has a unique bitrate.
3. Utilizing a "master module" to assign encoding jobs to a plurality of "host computing modules."
4. Basing the assignment on an "encoding job completion bid" received from the host modules.

For a prior art reference to anticipate a claim under 35 U.S.C. § 102, it must disclose, either expressly or inherently, every limitation of the claim. The most significant and potentially novel limitation in the '138 patent claims appears to be the use of an "encoding job completion bid" from host modules to a master module for the assignment of encoding tasks.

---

1. U.S. Patent No. 6,985,958 B2 (Zimmer et al.)

• Full Citation: US 6,985,958 B2, "Method and system for providing content adaptation in a content distribution network," filed by S. Zimmer et al., and assigned to AT&T Corp.
• Dates: Filed May 1, 2002; Published Jan. 10, 2006.
• Brief Description: This patent describes a system within a Content Distribution Network (CDN) that adapts content to suit the capabilities of a requesting client device. It discloses intercepting a content request, determining the client's capabilities, and then selecting a pre-stored, appropriately formatted version of the content or directing the request to a content adaptation server to transcode the content in real-time. The system aims to optimize delivery by matching content versions to client device characteristics (e.g., screen size, processing power, network connection).
• Potential Anticipation of US 11,470,138 Claims:
  • This reference teaches the concept of having multiple versions of content available for different network conditions and client types, which is foundational to adaptive bitrate streaming. It addresses the "why" (adapting to client needs) but is less specific on the "how" of the '138 patent's encoding architecture.
  • Anticipation Analysis: Zimmer et al. does not appear to anticipate the claims of the '138 patent. While it discusses transcoding and selecting content versions, it does not disclose the specific architecture of segmenting content into "streamlets" and, critically, lacks any teaching of a distributed encoding system where a master module assigns jobs to host modules based on a "completion bid." The job allocation mechanism, a key element of the '138 patent's claims, is absent.

---

2. U.S. Patent No. 8,650,318 B2 (Riedl et al.)

• Full Citation: US 8,650,318 B2, "System and method for directing a client to a content source," filed by S. Riedl et al., and assigned to Smooth-Flow, LLC.
• Dates: Filed Sep. 28, 2009; Published Feb. 11, 2014.
• Brief Description: This patent details a method for directing a client device to an optimal content source (e.g., a server in a CDN) from which to stream media. The system uses a "manifest file" that lists multiple content sources. The client can then test the performance of these sources (e.g., by measuring latency or throughput) and select the best one. It also describes segmenting media files into chunks for adaptive streaming, allowing the client to switch between bitrates based on network conditions by requesting chunks from different quality versions of the stream.
• Potential Anticipation of US 11,470,138 Claims:
  • This reference clearly discloses segmenting media into chunks and creating multiple versions at different bitrates for adaptive streaming. This aligns with elements 1, 2, 3, and 4 of the '138 patent's independent claims.
  • Anticipation Analysis: Riedl et al. does not anticipate the claims of the '138 patent. The focus of this prior art is on the client-side selection of an optimal content source (server), not on the server-side process of encoding the content. It does not describe or suggest a distributed encoding architecture with a master module, host modules, and a bidding process for assigning encoding jobs. The core server-side encoding method of the '138 patent is not taught.

---

3. U.S. Patent Application Pub. No. 2003/0055986 A1 (Zaslavsky et al.)

• Full Citation: US 2003/0055986 A1, "System and method for fast-start, variable-rate streaming of media over a network," filed by G. Zaslavsky et al.
• Dates: Filed Sep. 19, 2001; Published Mar. 20, 2003.
• Brief Description: This application describes a method for streaming media where a file is encoded at multiple bitrates. The server stores the media in a "multi-rate" file containing data for different quality levels. A client requests the media, and the server sends an initial portion at a low bitrate for a "fast start." Subsequently, based on available bandwidth, the server can switch to sending data from higher or lower bitrate versions of the file to adapt to network conditions. The technology focuses on providing a seamless viewing experience despite fluctuating bandwidth.
• Potential Anticipation of US 11,470,138 Claims:
  • This reference teaches the creation and use of multiple, parallel streams of the same content at different bitrates to enable adaptive streaming. It is highly relevant to the general concept of adaptive bitrate technology.
  • Anticipation Analysis: Zaslavsky et al. does not anticipate the claims of the '138 patent. The application describes the result of an encoding process (a multi-rate file) and its use in streaming, but it does not disclose the specific method of creation claimed in the '138 patent. There is no disclosure of segmenting the content into discrete "streamlets" that are then assigned for encoding via a master/host architecture using a "completion bid" system. The novel encoding infrastructure is not present.

---

4. U.S. Patent Application Pub. No. 2003/0110287 A1 (Traversat et al.)

• Full Citation: US 2003/0110287 A1, "Scalable Media Streaming System," filed by B. Traversat et al., and assigned to Sun Microsystems, Inc.
• Dates: Filed Dec. 6, 2001; Published Jun. 12, 2003.
• Brief Description: This application describes a peer-to-peer (P2P) system for streaming media. A media file is divided into multiple segments, and these segments are distributed across numerous peer devices in the network. When a client wants to view the content, it retrieves different segments from different peers simultaneously. The system also describes how peers can form "groups" to share segments efficiently, and it includes a mechanism for peers to advertise which segments they have available.
• Potential Anticipation of US 11,470,138 Claims:
  • This reference teaches segmenting a media file for distributed delivery. It also involves a distributed network of "peers" (which could be analogized to "hosts").
  • Anticipation Analysis: Traversat et al. does not anticipate the claims of the '138 patent. Its focus is on the distribution and retrieval of already-encoded media segments in a P2P network, not the initial encoding process. It does not teach creating sets of streamlets with unique bitrates for each time index. Most importantly, it completely lacks the claimed master/host architecture where hosts "bid" for encoding jobs. The peer discovery and segment advertising in this reference is for content delivery, not for load-balancing an encoding farm.

Based on the provided prior art, here is an analysis of the obviousness of U.S. Patent No. 11,470,138 ("the '138 patent") under 35 U.S.C. § 103.

Obviousness Analysis Under 35 U.S.C. § 103

A patent claim is unpatentable under 35 U.S.C. § 103 if the differences between the claimed invention and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art (a "POSITA"). This analysis considers whether a POSITA would have been motivated to combine the teachings of multiple prior art references to arrive at the claimed invention with a reasonable expectation of success.

The independent claims of the '138 patent generally recite a system and method for creating adaptive bitrate media streams by:

1. Segmenting media content into "streamlets."
2. Encoding these streamlets into sets, where each set corresponds to a specific time index and contains versions at multiple, unique bitrates.
3. Using a master/host distributed architecture for the encoding process.
4. Assigning encoding jobs based on a "completion bid" from the host modules to dynamically balance the workload.

The combination of these elements, particularly the distributed encoding architecture managed by a bidding system, would have been obvious to a POSITA at the time of the invention (priority date April 30, 2004). This can be demonstrated by combining the teachings of U.S. Patent Application Pub. No. 2003/0055986 A1 (Zaslavsky) with well-established principles of distributed computing and load balancing that would have been known to a POSITA.

---

Proposed Combination of References

A strong case for obviousness can be made by combining:

• Zaslavsky (US 2003/0055986 A1) as the primary reference, which teaches the fundamental concepts of multi-bitrate adaptive streaming.
• The established and well-known principles of distributed computing architectures (e.g., master/worker or "farm" systems) and dynamic load balancing, which represent common knowledge for a POSITA in the relevant field of computer science and network systems.

1. Base Teachings from Zaslavsky

Zaslavsky discloses a system for "fast-start, variable-rate streaming of media over a network." Its teachings directly cover the first two core elements of the '138 patent's claims:

• Multi-Bitrate Encoding: Zaslavsky explicitly teaches encoding a media file at multiple bitrates to create a "multi-rate" file. This is the same concept as the '138 patent's "set of streamlets" having unique bitrates.
• Adaptation and Segmentation: Zaslavsky describes a server sending initial portions of content at a low bitrate and then switching to higher or lower bitrates based on network conditions. This inherently implies that the media file is structured or can be accessed in segments or portions corresponding to different quality levels, which is analogous to the '138 patent's "streamlets" with identical time indices.

Zaslavsky establishes the "why" and "what" of adaptive bitrate streaming but does not specify the underlying server-side architecture for how the computationally-intensive encoding is performed. A POSITA, tasked with building a scalable system based on Zaslavsky's teachings, would immediately face the problem of how to efficiently generate these multi-rate media files for a large content library or for live events.

2. Motivation to Combine with Distributed Computing Principles

The '138 patent's claimed solution to the encoding challenge—a distributed master/host system with a bidding mechanism—is not a novel concept but rather the application of standard, well-known computer science principles to the problem disclosed by Zaslavsky.

• Motivation for a Master/Host Architecture: Video encoding is a notoriously CPU-intensive and time-consuming process. By 2004, it was a common and obvious practice to parallelize such "embarrassingly parallel" tasks across multiple computers to improve speed and throughput. Using a "farm" of encoder machines (the "hosts") managed by a central controller (the "master") was a standard architecture for tasks like 3D rendering, scientific computing, and large-scale data processing. A POSITA tasked with building a robust encoding system as required by Zaslavsky's method would have been motivated to use a distributed master/host architecture for the predictable benefits of:

  • Scalability: Easily add more host machines to increase encoding capacity.
  • Speed: Encode a single piece of content into multiple bitrates simultaneously, or process multiple content files in parallel.
  • Reliability: If one host fails, the master can reassign its job to another, as described in the '138 patent's specification (FIG. 5a).

• Motivation for a "Completion Bid" Mechanism: Once a master/host architecture is chosen, the question of how to assign jobs becomes paramount. The hosts in an encoding farm may be heterogeneous (different processor speeds, memory) or may have varying dynamic workloads. A simple round-robin assignment would be inefficient. A POSITA would have been well-aware of dynamic load-balancing techniques to solve this exact problem.

  The "encoding job completion bid" is a specific implementation of a well-known dynamic load-balancing strategy. In this strategy, worker nodes (hosts) provide the master with information about their current state, such as CPU load, available memory, or an estimate of how long a given task will take. The master uses this information to dispatch jobs to the most suitable host. The '138 patent's description of a bid based on "current encoding job completion percentage, average job completion time, processor speed, and physical memory capacity" is a textbook example of the factors used in such load-balancing algorithms.

  A POSITA would have been motivated to implement this type of bidding or status-reporting mechanism for the obvious and predictable benefit of maximizing the encoding farm's overall efficiency and throughput. It is a straightforward engineering choice, not an inventive leap.

Conclusion

The independent claims of the '138 patent appear obvious over Zaslavsky in view of the general knowledge of a Person of Ordinary Skill in the Art regarding distributed computing and dynamic load balancing.

1. Zaslavsky teaches the core concept of creating multi-bitrate media files that are implicitly segmented for adaptive streaming.
2. A POSITA, seeking to implement Zaslavsky's system on a large scale, would have found it obvious to use a standard master/host distributed architecture to handle the computationally expensive encoding process for reasons of speed, scalability, and reliability.
3. To optimize the performance of such a distributed system, the POSITA would have found it obvious to implement a dynamic load-balancing mechanism, such as the claimed "completion bid," to intelligently distribute encoding jobs to the most available or powerful hosts.

Combining these known elements would have yielded the system described in the '138 patent with a high degree of predictability and a reasonable expectation of success. Therefore, the claimed invention would have been obvious under 35 U.S.C. § 103.

Patent Term and Family Analysis for U.S. Patent No. 11,470,138

Patent Term Adjustments (PTA) and Extensions (PTE)

• Patent Term Adjustment (PTA): There is no Patent Term Adjustment (PTA) indicated for U.S. Patent No. 11,470,138. PTA is granted to compensate for delays caused by the USPTO during the patent prosecution process. The absence of a PTA suggests the patent was prosecuted and issued within the standard timeframes set by the USPTO.
• Patent Term Extension (PTE): There is no Patent Term Extension (PTE) for this patent. PTE is typically granted for patents covering products that undergo a lengthy pre-market regulatory review, such as pharmaceuticals, and is not applicable to this technology.

Continuity and Family Data

U.S. Patent No. 11,470,138 is part of a large family of patents and applications, stemming from a provisional application filed in 2004. The patent's term is determined by the filing date of the earliest non-provisional application in its family chain.

• Application Details:

  • Application Number: 16/876,579
  • Filing Date: May 18, 2020

• Continuity Chain (Parent Applications): This patent is a continuation of a long series of prior applications. The direct parent and the originating non-provisional application are key to determining its term:

  • This application is a continuation of U.S. Application No. 16/004,056 (filed June 8, 2018).
  • ...which is a continuation of U.S. Application No. 15/414,025 (filed Jan. 24, 2017), now U.S. Patent No. 9,998,516.
  • ...which is a continuation of U.S. Application No. 14/719,122 (filed May 21, 2015).
  • ...which is a continuation of U.S. Application No. 14/106,051 (filed Dec. 13, 2013), now U.S. Patent No. 9,071,668.
  • ...which is a continuation of U.S. Application No. 13/617,114 (filed Sep. 14, 2012), now U.S. Patent No. 8,612,624.
  • ...which is a continuation of U.S. Application No. 12/906,940 (filed Oct. 18, 2010), now U.S. Patent No. 8,402,156.
  • ...which is a continuation of U.S. Application No. 11/673,483 (filed Feb. 9, 2007), now U.S. Patent No. 7,818,444.
  • ...which is a continuation-in-part of U.S. Application No. 11/116,783 (filed April 28, 2005), now U.S. Patent No. 8,868,772. This is the earliest non-provisional application in the chain.

• Provisional Priority: The chain claims the benefit of U.S. Provisional Application No. 60/566,831, filed on April 30, 2004. Provisional application filing dates are not used to calculate the 20-year patent term.

• Child Applications: As of May 8, 2026, there are subsequent continuation applications that claim priority to the '138 patent's lineage, indicating the assignee, DISH Technologies LLC, continues to pursue protection for this technology. These include:

  • U.S. Application No. 17/962,231 (filed Oct. 7, 2022), now U.S. Patent No. 11,677,798.
  • U.S. Application No. 18/069,450 (filed Dec. 21, 2022), now U.S. Patent No. 11,991,234.
  • U.S. Application No. 18/667,985 (filed May 17, 2024), now U.S. Patent App. Pub. No. 2024/0333783 A1.

• Divisional Applications: No divisional applications were identified in the prosecution history provided in the patent document.

Projected Expiration Date

The term of a U.S. patent filed on or after June 8, 1995, is 20 years from the earliest non-provisional filing date to which it claims priority.

1. Earliest Non-Provisional Filing Date: The earliest non-provisional application in the priority chain is U.S. Application No. 11/116,783, which was filed on April 28, 2005.
2. Calculation: April 28, 2005 + 20 years = April 28, 2025.
3. Adjustments: As there are no Patent Term Adjustments or Extensions, the calculated date stands.

The projected expiration date for U.S. Patent No. 11,470,138 is April 28, 2025. The "Expired - Lifetime" status noted on the Google Patents page appears to be an error, as the patent term has not yet concluded based on its priority date.

Based on my analysis of U.S. Patent 11,470,138, and in my capacity as a Senior Patent Strategist and Research Engineer, I have generated the following defensive disclosure. The purpose of this document is to publicly disclose foreseeable variations, extensions, and applications of the '138 patent's teachings, thereby placing them into the public domain and establishing them as prior art.

Disclaimer: The priority date for the patent family of US 11,470,138 is April 28, 2005. The calculated expiration date for this patent is April 28, 2025. As the current date is May 8, 2026, the specific patent has expired. This disclosure is provided for defensive purposes against any existing or future related patents in this family or similar inventions by third parties.

Defensive Disclosure of Derivative Inventions

The core concepts disclosed in US 11,470,138—segmenting media into streamlets, creating multi-bitrate sets, and using a master/host architecture with a bidding mechanism for distributed encoding—can be extended in several ways. The following descriptions detail these extensions.

---

Axis 1: Material & Component Substitution

This axis explores substituting the computational and infrastructural components of the described system.

1.1. Heterogeneous Hardware Acceleration Encoding

• Enabling Description: The "host computing modules" are not limited to general-purpose CPUs. The encoding farm is composed of a heterogeneous mix of hardware accelerators. Host modules can be comprised of Graphics Processing Units (GPUs) using CUDA or OpenCL for massively parallel H.264/H.265/AV1 encoding, Field-Programmable Gate Arrays (FPGAs) configured with specific video processing pipelines for ultra-low latency, or Application-Specific Integrated Circuits (ASICs) designed for high-density, power-efficient encoding. The "encoding job completion bid" from each host includes metadata specifying its hardware type (CPU, GPU, FPGA, ASIC), the specific codecs it can accelerate, and its current thermal and power-draw state. The master module's scheduler is specifically designed to parse these bids and match the encoding job (e.g., a request for an AV1 streamlet) to the most appropriate hardware type (an AV1-capable ASIC or GPU), rather than a less-efficient CPU-based host.
• Mermaid Diagram:

  graph TD
      subgraph Master Module
          A[Job Queue: Streamlet_N]
          B[Scheduler]
      end
      subgraph Host Farm
          H1(CPU Host) -- "Bid: {type:CPU, load:75%, est_time:250ms}" --> B
          H2(GPU Host) -- "Bid: {type:GPU, load:40%, est_time:80ms}" --> B
          H3(FPGA Host) -- "Bid: {type:FPGA, latency:15ms, codec:H265}" --> B
      end
      A --> B
      B -- "Assign Job N to most efficient" --> H2
  

1.2. RDMA-based Inter-Node Communication

• Enabling Description: The network communication between the master module and the host computing modules is implemented over a high-throughput, low-latency fabric like InfiniBand or RoCE (RDMA over Converged Ethernet) instead of a standard TCP/IP stack. The master module transfers raw streamlet data directly into the memory of the target host module using Remote Direct Memory Access (RDMA) write operations, bypassing the host's CPU and operating system kernel. This significantly reduces data transfer latency and CPU overhead on the hosts. The "bid" from a host can include its RDMA buffer availability and queue depth, allowing the master to select hosts that can ingest the next job with the least network overhead.
• Mermaid Diagram:

  sequenceDiagram
      participant Master
      participant HostA
      participant HostB
  
      Master->>HostA: RDMA Write (Streamlet N)
      Note right of Master: Bypasses HostA Kernel
      Master->>HostB: RDMA Write (Streamlet N+1)
      Note right of Master: Bypasses HostB Kernel
      HostA-->>Master: RDMA Read (Bid with RDMA buffer status)
      HostB-->>Master: RDMA Read (Bid with RDMA buffer status)
      Master->>Master: Select best host based on RDMA stats
  

---

Axis 2: Operational Parameter Expansion

This axis defines the technology's operation under extreme conditions or at different scales.

2.1. Nanoscale Genomic Sequence Encoding

• Enabling Description: The system is adapted for real-time genomic sequencing and analysis. The "media content" is a raw DNA or RNA sequence feed from a nanopore sequencer. The "streamlet module" segments this continuous data stream into chunks of a predetermined number of base pairs (e.g., 10,000 bp). The "encoding module" does not perform video compression but rather different forms of bioinformatics analysis at varying computational costs. For example, a "low bitrate" streamlet is a simple base-calling and quality score calculation, while a "high bitrate" streamlet involves a full gene annotation, variant calling, and alignment to a reference genome. The master module assigns these analysis "encoding" jobs to a high-performance computing (HPC) cluster. A host's "bid" is based on its current queue of analysis tasks, available memory for holding the reference genome, and access speed to genomic databases.
• Mermaid Diagram:

  flowchart LR
      A[Sequencer Data Stream] --> B{Streamlet Module<br/>(10k base pairs)};
      B --> C[Raw Streamlet<br/>(seq_1.fasta)];
      C --> D{Master Scheduler};
      D -- Job: Basic QC --> E1[Host 1<br/>(Low-power CPU)];
      D -- Job: Full Annotation --> E2[Host 2<br/>(GPU Bio-Cluster)];
      E1 -- "Bid: {mem:1GB, time:1s}" --> D;
      E2 -- "Bid: {mem:128GB, time:30s}" --> D;
      E1 --> F1[Low-Bitrate Result<br/>(seq_1.qc)];
      E2 --> F2[High-Bitrate Result<br/>(seq_1.vcf)];
  

2.2. Cryogenic Supercomputer-Based Encoding

• Enabling Description: The encoding process is performed within a cryogenic computing environment to manage heat dissipation from an extremely dense array of processors. The "host modules" are superconducting processors or quantum annealing processors operating near absolute zero. The "encoding job completion bid" is critically dependent on the processor's quantum state or superconducting stability. The bid includes not just processing load but also qubit decoherence time estimates, thermal flux measurements from cryo-coolers, and the energy cost of performing the computation. The master module's algorithm is optimized not for speed alone, but for a multi-objective function that minimizes both processing time and the heat generated, thereby preserving the stability of the cryogenic environment. This is applicable for encoding streams with quantum-resistant encryption or performing physics simulations where the "video" is a visualization of the simulation data.
• Mermaid Diagram:

  graph TD
      subgraph Room Temperature
          A[Master Module]
      end
  
      subgraph Cryostat (-273°C)
          H1(Superconducting<br/>Processor A)
          H2(Superconducting<br/>Processor B)
          S1[Thermal Sensor]
          S2[Qubit Stability Sensor]
      end
  
      A -- Encoding Job --> H1;
      S1 -- Thermal Flux --> H1;
      S2 -- Decoherence Rate --> H1;
      H1 -- "Bid: {est_time: 1ns, heat_mW: 5, stable: 99.8%}" --> A;
      H2 -- "Bid: {est_time: 1.2ns, heat_mW: 3, stable: 99.9%}" --> A;
  

---

Axis 3: Cross-Domain Application

This axis describes applications of the core mechanism in unrelated industries.

3.1. Aerospace: Distributed Satellite Imagery Processing

• Enabling Description: A constellation of Earth observation satellites acts as a distributed processing network. A "master" satellite or ground station segments a large target area (e.g., the Amazon rainforest) into geographical tiles. Each tile is a "streamlet." The "encoding" process involves applying different analytical models to the raw sensor data for each tile: a "low bitrate" version could be simple cloud detection, "medium" could be vegetation indexing (NDVI), and "high" could be a machine-learning-based deforestation detection model. Nearby satellites in the constellation act as "hosts." A host satellite's "bid" is based on its available processing power, remaining battery life, current orientation (is the target tile in view?), and the quality of its inter-satellite communication link. The master assigns processing jobs to the most suitable satellites to generate an analytical map in near-real-time.
• Mermaid Diagram:

  graph TD
      subgraph Ground Station / Master Satellite
          M[Master Scheduler]
      end
  
      subgraph LEO Constellation
          Sat_A[Satellite A<br/>Processor: Idle<br/>Battery: 90%]
          Sat_B[Satellite B<br/>Processor: Busy<br/>Battery: 60%]
          Sat_C[Satellite C<br/>Processor: Idle<br/>Battery: 85%]
      end
  
      M -- Job: Tile_734 Analysis --> Sat_A
      M -- Job: Tile_735 Analysis --> Sat_C
  
      Sat_A -- "Bid: {CPU: 10%, Batt: 90%, Link: 1Gbps}" --> M
      Sat_B -- "Bid: {CPU: 95%, Batt: 60%, Link: 100Mbps}" --> M
      Sat_C -- "Bid: {CPU: 15%, Batt: 85%, Link: 1Gbps}" --> M
  
      Sat_A -.-> Sat_C
      Sat_A -.-> Sat_B
  

3.2. Agriculture Technology: Swarm Robotics for Crop Analysis

• Enabling Description: A swarm of autonomous drones is deployed over a large agricultural field. The "master" is a base station computer. The "media content" is the entire field, which the master divides into GPS-defined sectors ("streamlets"). Each drone is a "host." The "encoding" job is to fly to a sector, capture multi-spectral imagery, and process it locally to generate different "bitrates" of data: "low bitrate" is a simple hydration level, "medium bitrate" is a nitrogen deficiency map, and "high bitrate" is a machine learning model that identifies specific insect infestations. A drone's "bid" to process a sector is a function of its proximity to the sector, current battery level, onboard processing capacity, and the quality of its wireless link back to the base station. The master assigns sectors to drones to optimize for total field coverage time and data richness.
• Mermaid Diagram:

  erDiagram
      DRONE ||--o{ SECTOR : "processes"
      MASTER_STATION ||--|{ SECTOR : "assigns"
      MASTER_STATION }|--|| DRONE : "receives bid from"
  
      DRONE {
          string DroneID
          int BatteryLevel
          string GpsPosition
          int CpuLoad
      }
  
      SECTOR {
          string SectorID
          string GpsCoordinates
          string Status
      }
  
      MASTER_STATION {
          string MasterID
          string JobQueue
      }
  

3.3. Financial Services: Real-Time Risk Model Execution

• Enabling Description: A financial institution uses this system for real-time portfolio risk analysis. The "media content" is the live market data feed (e.g., OPRA options feed). The "streamlet module" divides the feed into 100-millisecond time slices. For each slice, the "encoding module" runs multiple risk models in parallel. A "low bitrate" model is a simple calculation of portfolio Delta. A "medium bitrate" model is a Value at Risk (VaR) calculation. A "high bitrate" model is a complex Monte Carlo simulation. The "hosts" are servers in a distributed computing grid. A host's "bid" reflects its current CPU load, memory availability for loading the portfolio state, and network latency to the source market data. The "master" (a risk management server) assigns the model execution jobs to the fastest available hosts to provide traders with sub-second risk updates.
• Mermaid Diagram:

  sequenceDiagram
      participant MarketFeed
      participant MasterRiskServer
      participant AnalyticsHost1
      participant AnalyticsHost2
  
      MarketFeed->>MasterRiskServer: Market Data (t=0ms to 100ms)
      MasterRiskServer->>AnalyticsHost1: BID REQ
      MasterRiskServer->>AnalyticsHost2: BID REQ
      AnalyticsHost1-->>MasterRiskServer: BID RESP (Low Load)
      AnalyticsHost2-->>MasterRiskServer: BID RESP (High Load)
      MasterRiskServer->>AnalyticsHost1: RUN MonteCarlo(Data_t0)
      AnalyticsHost1-->>MasterRiskServer: Result_MonteCarlo
  

---

### **Axis 4: Integration with Emerging Tech**

This axis describes integrating the core patent concepts with modern technologies.

#### **4.1. AI-Driven Predictive Load Balancing**

*   **Enabling Description:** The master module is enhanced with an AI-based predictive scheduling engine, replacing the simple reactive bidding system. It uses a trained machine learning model (e.g., a recurrent neural network or gradient boosting model) to predict the completion time for a given encoding job on each host. The model's features include not only the host's reported stats (the "bid") but also historical performance on similar jobs, the time of day (to account for external network traffic patterns), the complexity of the source streamlet (measured by spatial and temporal information metrics), and even the ambient temperature of the data center. The master no longer waits for bids but proactively assigns jobs to the host the model predicts will provide the optimal balance of speed, cost, and quality, even before the host becomes fully available.
*   **Mermaid Diagram:**
    ```mermaid
    graph TD
        subgraph MasterModule
            A[Job Queue] --> B{ML Scheduler}
            C[Host Performance DB] --> B
        end

        subgraph Hosts
            H1[Host 1]
            H2[Host 2]
        end

        B -- "Predicts H1 is optimal" --> D[Assign Job to H1]
        D --> H1
        H1 -- "Performance Data" --> C
    ```

#### **4.2. IoT-Aware Edge Encoding**

*   **Enabling Description:** The system is deployed on a distributed network of Internet of Things (IoT) edge devices (e.g., smart cameras, industrial sensors). These devices act as both capture points and "hosts". The "master" module runs in the cloud or on a regional gateway. An edge device captures a video "streamlet" and then submits a "bid" to encode it. The bid is enriched with IoT-specific metrics: its power status (mains or battery), local network quality (Wi-Fi, 5G, LoRaWAN), and on-device resource contention from other running applications. The master module can decide to have the device encode its own streamlet (self-hosting) if it has sufficient resources, or it can offload the raw streamlet to another, more powerful nearby edge device that submitted a better bid, optimizing for battery life and network data usage across the entire IoT deployment.
*   **Mermaid Diagram:**
    ```mermaid
    stateDiagram-v2
        state "Idle" as Idle
        state "Capturing" as Capturing
        state "Bidding" as Bidding
        state "Encoding" as Encoding
        state "Offloading" as Offloading

        [*] --> Idle
        Idle --> Capturing: Start Event
        Capturing --> Bidding: Streamlet Ready
        Bidding --> Encoding: Master Assigns Self
        Bidding --> Offloading: Master Assigns Peer
        Encoding --> Idle: Complete
        Offloading --> Idle: Complete
    ```

#### **4.3. Blockchain-Verified Encoding for Royalty Reporting**

*   **Enabling Description:** The system is augmented with a private blockchain for creating an immutable audit trail of the encoding process. When a host completes an encoding job for a streamlet, it generates a proof-of-work that includes a hash of the source streamlet, a hash of the output encoded streamlet, the parameters of the winning "bid," and the actual time taken. The master module validates this proof and records it as a transaction on a distributed ledger. This provides a transparent, tamper-proof record of which content was encoded, at what quality levels, and by which computational resource. This is used for automated royalty payments in a multi-publisher content system, where different publishers are billed for the computational resources used to encode their content, and royalties are paid to content owners based on the number of streamlets encoded.
*   **Mermaid Diagram:**
    ```mermaid
    flowchart TD
        A[Start Encoding Job for 'Content A'] --> B{Host X Wins Bid};
        B --> C[Host X Encodes Streamlet S1];
        C --> D{Generate Proof:<br/>- hash(S1_raw)<br/>- hash(S1_encoded)<br/>- bid_params<br/>- timestamp};
        D --> E[Master Validates Proof];
        E --> F((Blockchain Ledger));
        F -- "Transaction Recorded" --> G[Trigger Royalty Payment<br/>to Owner of 'Content A'];
    ```
---

### **Axis 5: The "Inverse" or Failure Mode**

This axis describes designing the system for graceful degradation or safe failure.

#### **5.1. Graceful Degradation via "Best-Effort" Encoding Tier**

*   **Enabling Description:** The system operates in a "best-effort" or "low-power" mode during periods of high load or energy constraints. In this mode, the master module alters its job assignment criteria. It will only solicit bids for and assign jobs to encode the lowest-bitrate streamlet (e.g., 240p audio-only). Higher-quality streamlets are temporarily skipped. If all hosts report high load (i.e., all "bids" exceed a predefined time threshold), the master module will not assign the encoding job at all. Instead, it instructs the origin server to serve a pre-generated "Sorry, this quality is temporarily unavailable" slate image or loop the previously successful streamlet. This ensures the core service remains available at a minimum quality level and prevents cascading failures from overloading the encoding farm.
*   **Mermaid Diagram:**
    ```mermaid
    graph TD
        A{System Load High?} -- Yes --> B{Enter Low-Power Mode}
        B --> C{Master only requests bids for 240p streamlet}
        C --> D{All Bids > Threshold?}
        D -- Yes --> E[Serve 'Unavailable' Slate]
        D -- No --> F[Assign 240p job to best host]
        A -- No --> G[Normal Operation]
    ```

#### **5.2. Proactive Redundant Encoding for Fault Tolerance**

*   **Enabling Description:** To ensure high availability for critical live events, the master module implements a policy of proactive redundancy. When a new streamlet job arrives, the master does not assign it to the single best host based on its bid. Instead, it assigns the *same encoding job* to the top *two* hosts that submitted acceptable bids. The hosts race to complete the job. The first host to return the encoded streamlet has its result written to the primary streamlet database. The result from the second host is discarded. This "inverse" of pure efficiency-based assignment protects against a single host failing or becoming unexpectedly slow during a critical encoding task. The system pays a power and resource cost for the redundant work, but gains a significant increase in resilience and a reduction in the "long tail" of high-latency streamlet delivery.
*   **Mermaid Diagram:**
    ```mermaid
    sequenceDiagram
        participant Master
        participant Host_A
        participant Host_B
        participant Database

        Master->>Host_A: Encode Streamlet_X (Primary)
        Master->>Host_B: Encode Streamlet_X (Redundant)
        Host_A-->>Master: Result_X
        Master->>Database: Write Result_X
        Host_B-->>Master: Result_X
        Master->>Master: Discard redundant result
    ```
---

### **Combination Prior Art with Open-Source Standards**

#### **1. Combination with FFmpeg and Bash**

*   **Enabling Description:** A content delivery system uses the master/host architecture of the '138 patent where the "hosts" are standard Linux servers running the open-source FFmpeg multimedia framework. The "master" is a central server running a scheduler script (e.g., in Bash or Python). When a new video file arrives, the master segments it into 2-second chunks. For each chunk, it polls the host servers. Each host runs a script that calculates its "bid" by checking `1-minute load average` from `/proc/loadavg` and available RAM from `free -m`. The master receives these bids and assigns the job to the host with the lowest load by issuing a remote `ssh` command. The command executes `ffmpeg` with specific parameters to create multiple output files at different bitrates (e.g., `ffmpeg -i chunk_1.ts -b:v 500k chunk_1_500k.ts -b:v 1M chunk_1_1M.ts`). This combines the patent's bidding logic with ubiquitous, open-source tools.

#### **2. Combination with Kubernetes and Prometheus**

*   **Enabling Description:** The encoding system is deployed as a cloud-native application on a Kubernetes cluster. The encoding application is packaged as a Docker container. The "master module" is implemented as a Kubernetes Custom Controller. The "host modules" are pods that can be scaled horizontally. The open-source monitoring tool Prometheus scrapes metrics from all pods in real-time. The "encoding job completion bid" is not actively sent by the pods; instead, the master controller queries the Prometheus API to get the current CPU utilization, memory usage, and network I/O for each encoder pod. Based on these real-time metrics, the controller creates a Kubernetes `Job` and uses node affinity rules to schedule it onto the pod/node that is currently the most under-utilized, thereby achieving dynamic load balancing without a direct "bid" message from the hosts themselves.

#### **3. Combination with DASH.js and WebRTC Data Channels**

*   **Enabling Description:** The client-side player, using the open-source DASH.js library, is modified to provide real-time network performance feedback to the content server infrastructure. In addition to standard HTTP requests for media segments, the client opens a WebRTC data channel back to a "feedback aggregator" service. The client sends frequent updates on its measured bandwidth, buffer health, and dropped frame count over this channel. This feedback data is used by the '138 patent's master encoder module as a key input for its job assignment logic. The master can prioritize encoding bitrates that are in high demand by currently active clients or deprioritize bitrates that clients are reporting they cannot sustain. This creates a feedback loop from an open-source client directly influencing the behavior of the proprietary server-side encoding farm.