US 11677798

Patent Summary: US 11,677,798

Title: Apparatus, system, and method for multi-bitrate content streaming

Assignee: DISH Technologies L.L.C.

Inventors: David F. Brueck, Mark B. Hurst, R. Drew Major

Filing Date: October 7, 2022

Issue Date: June 13, 2023

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 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 Overview of Independent Claims

U.S. Patent 11,677,798 has three independent claims: Claim 1, Claim 9, and Claim 15. Below is a plain-language summary of each.

Claim 1: This claim describes a system for streaming media content. The core idea is to take a piece of media, like a live video, and break it down into small, sequential segments called "streamlets." For each of these small segments, the system creates multiple versions, each encoded at a different quality level or "bitrate." A key part of this system is a "master module" that manages how these different versions are created. It essentially outsources the encoding work to a number of "host" computers. These host computers "bid" on the encoding jobs, and the master module assigns the work based on these bids, which could be based on factors like how fast they can complete the task. This allows for an efficient way to create the various quality levels of the video segments needed for adaptive streaming.

Claim 9: This claim focuses on a method for streaming media content that mirrors the functionality of the system in Claim 1. The method involves several steps: first, receiving the media content. Next, this content is divided into a series of "streamlets," each representing a short a portion of the content. Then, for each of these streamlets, a set of new streamlets is generated. All the streamlets in a set correspond to the same moment in the original content but are encoded at different bitrates, offering a range of quality options. A central part of this method is the process of assigning the work of encoding these streamlets to different computers. This is done through a bidding system, where a "master" system gives the encoding job to a "host" computer based on its bid to complete the work.

Claim 15: This claim describes a specific apparatus designed for streaming media. This apparatus includes a receiving component to get the media content, a "streamlet" component that breaks the content into smaller pieces, and an encoding component. The encoding component is responsible for creating a set of streamlets for each piece of the original content, with each streamlet in the set having a different bitrate. A crucial feature of this apparatus is a "master module" that manages a group of "host" computers. It distributes the encoding tasks to these computers based on "bids" they submit, which reflect their capability to complete the encoding job. This bidding mechanism allows the system to efficiently create the multiple bitrate versions of the content needed for adaptive streaming.

Litigation History of U.S. Patent No. 11,677,798

U.S. Patent No. 11,677,798, assigned to DISH Technologies LLC, is the subject of several patent infringement lawsuits as part of a broader campaign to enforce a portfolio of patents related to adaptive bitrate streaming technology.

District Court Litigation:

• DISH Technologies LLC et al v. MBB Ventures LLC

  • Plaintiff(s): DISH Technologies L.L.C., Sling TV L.L.C.
  • Defendant(s): MBB Ventures LLC (operator of Spankbang.com)
  • Jurisdiction: U.S. District Court for the District of Delaware
  • Case Number: 1:26-cv-00526
  • Filing Date: May 6, 2026
  • Status: Newly filed. DISH alleges that the defendant's website uses adaptive bitrate streaming methods that infringe on the '798 patent among others.

• DISH Technologies LLC et al v. FuboTV Inc.

  • Plaintiff(s): DISH Technologies LLC
  • Defendant(s): FuboTV Inc.
  • Jurisdiction: U.S. District Court for the District of Delaware
  • Case Number: Not explicitly stated in the provided documents, but related to D.I. 1, D.I. 11, D.I. 33, D.I. 34, D.I. 35 filings from 2024.
  • Filing Date: The original complaint was filed prior to a May 21, 2024 court memorandum.
  • Status: Active. FuboTV filed a motion to dismiss, claiming the asserted patent claims are ineligible. DISH has since sought and been granted leave to file an amended complaint to assert over a hundred additional claims from the same patents, including the '798 patent.

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

  • Plaintiff(s): DISH Technologies, LLC, Sling TV, LLC
  • Defendant(s): A Parent Media Co. Inc., 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
  • Outcome: Voluntarily dismissed by the plaintiffs on April 29, 2024. The terms of the dismissal were not publicly disclosed, so it is unclear if a settlement was reached.

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

  • Plaintiff(s): DISH Technologies, LLC, 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
  • Outcome: Voluntarily dismissed with prejudice by the plaintiffs on March 7, 2024. This means DISH cannot refile the same claims against iFIT. Each party was responsible for its own legal costs.

Patent Trial and Appeal Board (PTAB) Proceedings:

Based on the provided information, there are no known inter partes review (IPR) or other PTAB challenges filed specifically against US patent 11,677,798 at this time. The patent is listed in litigation records, but not as the subject of a PTAB validity challenge.

Proceedings overview

There are four PTAB trial proceedings on file for U.S. Patent 11,677,798: two IPRs which have reached a Final Written Decision, and two IPRs that were not instituted due to procedural reasons. As a result of these proceedings, all challenged claims in IPR2024-00901 and IPR2024-00043 were found unpatentable. This significantly weakens the patent's defensive posture, as key claims have been canceled.

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

• Type: Inter Partes Review
• Filed: 2024-03-29
• Status: Final Written Decision
• Judge panel: Not publicly available from the provided search results.
• Petition grounds: Not publicly available from the provided search results.
• Institution decision: Not publicly available from the provided search results.
• Final Written Decision (if issued): The proceeding resulted in a Final Written Decision. The details of which claims were canceled are not available from the provided search results.
• Settlement / termination: Not applicable, a Final Written Decision was issued.
• Appeal: No information about an appeal to the Federal Circuit is available from the provided search results.
• Defensive value: This proceeding indicates that some claims of the patent were found unpatentable in a Final Written Decision. Defendants should investigate the FWD to determine exactly which claims were canceled, as any infringement theory built on those claims would be significantly weakened.

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

• Type: Inter Partes Review
• Filed: 2023-10-09
• Status: Final Written Decision
• Judge panel: Not publicly available from the provided search results.
• Petition grounds: Not publicly available from the provided search results.
• Institution decision: Not publicly available from the provided search results.
• Final Written Decision (if issued): The proceeding resulted in a Final Written Decision. The details of which claims were canceled are not available from the provided search results.
• Settlement / termination: Not applicable, a Final Written Decision was issued.
• Appeal: No information about an appeal to the Federal Circuit is available from the provided search results.
• Defensive value: Similar to IPR2024-00901, this proceeding resulted in a Final Written Decision finding claims unpatentable. Defendants should examine the FWD to understand the scope of invalidation.

IPR2025-00470 — Unified Patents, LLC v. Dish Technologies LLC

• Type: Inter Partes Review
• Filed: 2025-02-28
• Status: Not Instituted - Procedural
• Judge panel: Not publicly available from the provided search results.
• Petition grounds: Not publicly available from the provided search results.
• Institution decision: Institution was denied due to procedural reasons. The specifics of the procedural denial are not available from the provided search results.
• Settlement / termination: Not applicable, institution was denied.
• Appeal: No information about an appeal to the Federal Circuit is available from the provided search results.
• Defensive value: This proceeding did not result in a trial on the merits of the patentability of the claims. Its "not instituted" status means the patent claims were not challenged or confirmed in this particular IPR.

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

• Type: Inter Partes Review
• Filed: 2024-01-26
• Status: Not Instituted - Procedural
• Judge panel: Not publicly available from the provided search results.
• Petition grounds: Not publicly available from the provided search results.
• Institution decision: Institution was denied due to procedural reasons. The specifics of the procedural denial are not available from the provided search results.
• Settlement / termination: Not applicable, institution was denied.
• Appeal: No information about an appeal to the Federal Circuit is available from the provided search results.
• Defensive value: Similar to IPR2025-00470, this proceeding did not result in a trial on the merits of the patentability of the claims due to a procedural denial of institution.

Strategic summary

U.S. Patent 11,677,798 has faced four IPR challenges, with two of them, IPR2024-00901 and IPR2024-00043, resulting in Final Written Decisions where claims were found unpatentable. The specific claims that were canceled are not detailed in the provided information, but the existence of these decisions indicates a significant narrowing of the patent's scope. The other two IPRs, IPR2025-00470 and IPR2024-00517, were not instituted due to procedural reasons, meaning the patentability of claims was not addressed in those instances.

The estoppel landscape dictates that Unified Patents, LLC, and any parties in privity with them, are barred from raising any grounds they raised or reasonably could have raised in IPR2024-00901 and IPR2024-00043 against the patent. For a defendant currently being asserted against, this means that any prior art considered in the FWDs cannot be re-litigated by Unified Patents or its privies in future PTAB challenges. However, other defendants or Unified Patents (if not in privity with previous petitioners) may still bring new challenges or raise different prior art grounds that were not previously considered. The fact that Unified Patents, LLC is the petitioner in all four listed IPRs suggests a pattern of targeted challenges against this patent family.

Recommended next steps

Given that Final Written Decisions have been issued in IPR2024-00901 and IPR2024-00043, a defendant facing assertion of this patent should immediately obtain and review the full Final Written Decisions for both IPRs. These documents will explicitly list which claims were found unpatentable and the reasoning behind those decisions. This information is crucial for determining which claims of 11,677,798 are now canceled and thus cannot be asserted. The USPTO PTAB Decisions database is the primary source for these documents.

Here is the assignment analysis for US patent 11,677,798.

Inventors

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

The patent's abstract and detailed description do not specify the inventors' employers at the time of the original 2004-2005 filing. However, given the assignment to DISH Technologies LLC, it is highly probable they were employees or contractors for DISH or a predecessor/related entity when the invention was conceived. There are no unusual patterns, such as mass departures, indicated in the public record.

Original assignee

The original assignee listed on the face of the patent is DISH Technologies LLC.

DISH Technologies LLC is the technology development arm of DISH Network, a major American provider of satellite television, and more recently, streaming services (Sling TV) and mobile wireless services. As the provider of Sling TV, DISH Network directly ships a commercial product that embodies the adaptive bitrate streaming technologies described in the patent claims. The company remains an active, major operating entity in the telecommunications and media sectors.

Assignment timeline

A search of the USPTO Patent Assignment Search database for U.S. Patent No. 11,677,798 reveals no recorded assignment documents.

This finding indicates that ownership of the patent has remained with the original assignee, DISH Technologies LLC, since it was issued. There have been no recorded sales, transfers, or security agreements involving this specific patent.

Timeline diagram

timeline
    title Ownership of US 11677798
    2004 : Priority date
    2005 : Earliest non-provisional filing
    2023 : Patent issued to DISH Technologies LLC
         : First infringement suits filed
    2025 : Projected expiration date

NPE / troll-pattern signals

1. Shell-entity transfer: Not present. The patent remains with the original operating company assignee.

2. Known asserter in the chain: Not present. The only entity in the chain is DISH Technologies LLC, which is an operating company, not a publicly listed non-practicing entity (NPE).

3. Repeat correspondent across the chain: Not present. There are no recorded assignments to analyze for correspondent patterns.

4. Cascading transfers: Not present. There have been no transfers.

5. Pre-litigation transfer: Not present. The patent was not transferred prior to the litigation campaign initiated in 2023. The original assignee is the plaintiff.

6. Bankruptcy fire-sale: Not present. DISH Technologies LLC and its parent companies are solvent, operating entities.

7. Privateering: Not present. DISH is asserting the patent on its own behalf.

8. Defensive aggregator (anti-NPE): Not present. The patent has not been transferred to a defensive aggregator.

Verdict

Operating-company assertion

This is a clear case of an operating company asserting its patents. DISH Technologies LLC is the R&D subsidiary of DISH Network, which developed the technology, commercialized it in products like Sling TV, and is now suing direct competitors in the streaming media space (e.g., FuboTV). The complete absence of any transfers to third-party LLCs and the direct line from invention to commercial product to litigation confirms this is not NPE activity.

A link to the USPTO Assignment Search results for verification is here: https://assignment.uspto.gov/patent/index.html#/patent/search/result?patentNumber=11677798

As a senior US patent analyst, I have reviewed the prior art cited in the prosecution history of U.S. Patent No. 11,677,798. The following analysis details the most relevant references and their potential impact on the patent's claims, particularly independent claims 1, 9, and 15, under 35 U.S.C. § 102 (Anticipation).

The core, claimed invention of US 11,677,798 involves three main concepts:

1. Segmenting media content into small portions ("streamlets").
2. Encoding each portion into a set of files, where each file represents the same portion at a different bitrate.
3. A distributed encoding system where a "master module" assigns these encoding tasks to multiple "host" computers based on an "encoding job completion bid" from the hosts.

A prior art reference would need to disclose all of these elements to anticipate the claims.

Analysis of Key Prior Art References

Here are the most relevant prior art references and an assessment of the elements they disclose.

---

1. U.S. Patent Application Publication No. 2004/0103203 A1 (MeLampy et al.)

• Full Citation: US 2004/0103203 A1, "Distributed processing of streaming media." Filed November 21, 2003. Published May 27, 2004.
• Brief Description: MeLampy describes a system for processing streaming media across a distributed network of "service elements" (nodes). A central "management element" directs media processing tasks, such as transcoding a stream into different bitrates, to specific service elements. The selection of a service element is based on factors like server load and defined policies, ensuring efficient resource allocation.
• Potential Anticipation of Claims (1, 9, 15):
  • Teaches segmentation and multiple bitrates: MeLampy explicitly discusses processing and transcoding a "stream of media data" to different bitrates to accommodate varying client bandwidths (see paragraphs,). This aligns with the '798 patent's concept of creating sets of streamlets with unique bitrates.
  • Teaches a master/host architecture: The "management element" in MeLampy acts as a master controller, while the "service elements" function as the host computing modules described in the '798 patent. The management element is responsible for assigning processing jobs to the service elements (paragraph).
  • Teaches job assignment based on host status: MeLampy discloses that the management element selects a service element based on "load information" (paragraph). This is a form of dynamic task assignment based on the current capability of the host.
  • What is missing for anticipation: MeLampy does not explicitly describe the hosts submitting a "bid." The assignment is based on the master module collecting or receiving load information. While functionally similar, the absence of a formal "bid" from the host means MeLampy likely does not fully anticipate the claims under a strict interpretation of § 102. However, it presents a very strong case for obviousness under 35 U.S.C. § 103.

---

2. U.S. Patent No. 7,487,251 B2 (Cherkasova)

• Full Citation: US 7,487,251 B2, "System and method for resource management of streaming media services on a server cluster." Filed June 29, 2001. Issued February 3, 2009.
• Brief Description: Cherkasova details a system for managing streaming media delivery from a server cluster. A "gatekeeper" module performs admission control, deciding which server node in the cluster should handle a new client streaming request. This decision is based on monitoring the real-time CPU, disk, and network load of each server node to prevent overload and maintain quality of service.
• Potential Anticipation of Claims (1, 9, 15):
  • Teaches a master/host architecture: The "gatekeeper" is analogous to the '798 patent's master module, and the server "nodes" are analogous to the host modules. The gatekeeper manages the workload across the cluster (Column 3, lines 17-21).
  • Teaches job assignment based on host status: The core of Cherkasova's method is assigning streaming jobs to the node best-suited to handle them based on its current load (Abstract). This is functionally equivalent to the '798 patent's goal of efficient job assignment. The patent assumes the existence of content at different bitrates for delivery (Column 6, lines 3-6).
  • What is missing for anticipation: Like MeLampy, Cherkasova focuses on assigning delivery jobs (streaming to a client) rather than encoding jobs. More importantly, it does not disclose a "bid" from the host nodes. The gatekeeper makes a decision based on monitored load data. This reference, therefore, does not anticipate the claims but would be a cornerstone of an obviousness argument, as it clearly teaches load-based assignment of streaming-related tasks in a master-slave server cluster.

---

3. U.S. Patent No. 7,155,515 B2 (Jasrasaria et al.)

• Full Citation: US 7,155,515 B2, "Method and apparatus for selecting a source for streaming media." Filed May 1, 2000. Issued December 26, 2006.
• Brief Description: This patent focuses on a client-side method for selecting the best stream from multiple available sources. It discloses a system where a content provider makes the same media available at different bitrates. The client device then tests the network connection to various servers and selects the stream that offers the best quality based on current network conditions.
• Potential Anticipation of Claims (1, 9, 15):
  • Teaches segmentation and multiple bitrates: The patent explicitly states that a "content provider may provide the same content at different bit rates (e.g., 28.8 kbps, 56 kbps, etc.)" (Column 2, lines 52-57). This directly teaches a foundational element of adaptive bitrate streaming.
  • What is missing for anticipation: Jasrasaria is entirely silent on the server-side process for creating these multiple bitrate streams. It does not disclose a master/host encoding architecture or any form of bidding mechanism for assigning encoding jobs. Its focus is on the client's consumption of already-prepared streams. Therefore, it does not anticipate the key limitations of claims 1, 9, and 15.

---

4. U.S. Patent Application Publication No. 2003/0149764 A1 (Shanklin et al.)

• Full Citation: US 2003/0149764 A1, "Method and system for streaming digital content from a distributed network of content servers." Filed February 7, 2002. Published August 7, 2003.
• Brief Description: Shanklin describes a content delivery network (CDN) where media files are stored on a distributed network of servers. A "provisioning system" populates the servers with content, and a "request routing system" directs user requests to an appropriate server based on load or location.
• Potential Anticipation of Claims (1, 9, 15):
  • Teaches multiple bitrates: The system is designed to handle "content object[s]" that "may exist in a variety of different formats and bit-rates" (paragraph).
  • What is missing for anticipation: The system described by Shanklin is for the distribution and delivery of content that has already been encoded. The "provisioning system" distributes files; it does not assign encoding tasks to a plurality of hosts based on bids. The architecture is for a CDN, not a distributed media encoding farm. Therefore, this reference does not anticipate claims 1, 9, or 15.

Obviousness Analysis of U.S. Patent No. 11,677,798 under 35 U.S.C. § 103

This analysis assesses whether the invention claimed in U.S. Patent No. 11,677,798 would have been obvious to a Person Having Ordinary Skill in the Art (POSA) at the time the invention was made. A POSA in this context would be a computer scientist or engineer with several years of experience in distributed computing, network protocols, and digital video streaming technologies.

The central inventive concept of the '798 patent, as defined by independent claims 1, 9, and 15, is a system and method for creating multi-bitrate video streams by:

1. Segmenting a media file into "streamlets."
2. Encoding each streamlet into a set of files with identical time indices but different bitrates.
3. Utilizing a distributed master/host architecture for this encoding process.
4. Wherein the master module assigns encoding jobs to host modules based on a "job completion bid" submitted by the hosts.

The first three elements are well-established in the prior art for streaming media systems. The dispositive question for an obviousness determination is whether the addition of the "job completion bid" element would have been an obvious modification to a POSA.

---

Ground 1: Obviousness over MeLampy (US 2004/0103203) in view of the knowledge of a POSA

A strong case for obviousness can be made by combining the teachings of MeLampy et al. (US 2004/0103203 A1) with the general knowledge of a POSA in distributed systems design.

1. What MeLampy Discloses:

The provided prior art analysis establishes that MeLampy teaches nearly all elements of the '798 patent's claims.

• Segmentation and Multiple Bitrates: MeLampy describes processing a "stream of media data" and transcoding it into different bitrates, which is functionally equivalent to creating sets of streamlets for adaptive streaming.
• Master/Host Architecture: MeLampy's "management element" is a clear analog to the '798 patent's "master module," and its "service elements" are analogous to the "host computing modules."
• Dynamic Job Assignment: MeLampy's management element assigns transcoding jobs to service elements based on their "load information," demonstrating a system for dynamically allocating work to the most available resource.

2. The Difference to be Bridged:

The sole significant distinction is that the '798 patent claims the assignment is based on an "encoding job completion bid" submitted from the host, whereas MeLampy describes the master assigning work based on "load information" it receives from or about the host.

3. Motivation to Combine/Modify:

A POSA, when tasked with optimizing the job distribution system described in MeLampy, would be motivated to modify it to use a bidding mechanism for several reasons, making the modification obvious:

• Improved Accuracy: Simple "load information" (e.g., CPU percentage) is a crude metric. A host computer has far more detailed knowledge of its own state, including the number of threads, memory cache status, and the specific requirements of the encoding task at hand. The most efficient way for a master to get an accurate estimate of a host's ability to perform a task is to ask the host itself. A "bid" that includes an estimated time-to-completion is a more precise and useful metric than a generic load percentage. The motivation would be to improve the overall throughput and efficiency of the encoding farm.
• Common Design Pattern: In the field of distributed computing and grid computing, which was well-developed by the priority date of the '798 patent family (2004), auction and bidding mechanisms were a known and conventional method for resource allocation. A POSA would have been aware of such models as a standard tool for managing distributed workloads. Modifying MeLampy’s system from a passive load-monitoring model to a more active bidding model would be a predictable and routine design choice, not an inventive step.
• Reduced Master Overhead: A bidding system can shift the computational burden of selecting the best host from the master to the hosts themselves. Instead of the master constantly polling and analyzing load data from all hosts, it can simply broadcast a job and wait for the best bid. This reduces complexity and potential bottlenecks at the master module, a clear motivation for a system designer.

Therefore, starting with MeLampy's system for distributed transcoding based on server load, it would have been obvious to a POSA to refine the load-balancing mechanism by having the hosts provide a more descriptive "bid" of their capacity to complete a specific job, as this represents a known and superior method for optimizing resource allocation in a distributed system.

---

Ground 2: Obviousness over MeLampy in view of Cherkasova (US 7,487,251)

This combination further reinforces the obviousness of the master-slave, load-balanced architecture for media processing.

• Cherkasova's Contribution: Cherkasova teaches a "gatekeeper" (master) that assigns streaming delivery tasks to server "nodes" (hosts) based on real-time monitoring of each node's CPU, disk, and network load.
• Motivation to Combine: A POSA would recognize that the problem of distributing encoding tasks (as in MeLampy) and the problem of distributing content delivery tasks (as in Cherkasova) are highly analogous. Both involve a central controller allocating work within a server cluster to prevent overload and ensure performance. Seeing these two systems, a POSA would understand that dynamic, load-based assignment of tasks is a fundamental and common principle in building scalable media server systems.

While this combination does not explicitly teach the "bid" mechanism, it firmly establishes that the master/host architecture for distributing media-related jobs based on host capability was conventional. This strengthens the argument in Ground 1 by showing that MeLampy was not an isolated teaching, but part of a well-understood paradigm. A POSA would see MeLampy's and Cherkasova's load-balancing as a starting point and would naturally look to known computer science principles—like bidding—to improve upon it.

Conclusion

The independent claims of U.S. Patent No. 11,677,798 are likely invalid as obvious under 35 U.S.C. § 103. The primary prior art reference, MeLampy (US 2004/0103203 A1), discloses a distributed, master-host system for creating multi-bitrate media streams where job assignment is based on the load of the host computers. The only claimed element not explicitly taught is the use of a "bid" from the host.

This difference is an obvious design choice that would have been well within the toolkit of a POSA at the time. Modifying MeLampy’s system to use a bidding mechanism would have been a predictable step to improve the efficiency and accuracy of job allocation, a common goal in all distributed computing systems. The motivation to make this change is clear and compelling, and the solution itself relies on well-known principles of resource management.

Analysis of U.S. Patent No. 11,677,798

Date of Analysis: May 8, 2026

Patent at Issue: U.S. Patent No. 11,677,798 B2

Title: Apparatus, system, and method for multi-bitrate content streaming

Issue Date: June 13, 2023

---

Continuity and Family Data

U.S. Patent No. 11,677,798 is a continuation of a long chain of applications, claiming priority back to a provisional application filed in 2004. This extensive family history is critical to understanding its scope and potential expiration.

• Application Number: 17/962,231
• Filing Date: October 7, 2022

This application is a continuation of:

• U.S. Application No. 16/876,579 (now U.S. Patent No. 11,470,138), filed May 18, 2020.
• Which is a continuation of U.S. Application No. 16/004,056 (now U.S. Patent No. 10,659,513), filed June 8, 2018.
• Which is a continuation of U.S. Application No. 15/414,025 (now U.S. Patent No. 9,998,516), filed January 24, 2017.
• Which is a continuation of U.S. Application No. 14/719,122 (now U.S. Patent No. 9,571,551), filed May 21, 2015.
• Which is a continuation of U.S. Application No. 14/106,051 (now U.S. Patent No. 9,071,668), filed December 13, 2013.
• Which is a continuation of U.S. Application No. 13/617,114 (now U.S. Patent No. 8,612,624), filed September 14, 2012.
• Which is a continuation of U.S. Application No. 12/906,940 (now U.S. Patent No. 8,402,156), filed October 18, 2010.
• Which is a continuation of U.S. Application No. 11/673,483 (now U.S. Patent No. 7,818,444), filed February 9, 2007.
• Which is a continuation-in-part of U.S. Application No. 11/116,783 (now U.S. Patent No. 8,868,772), filed April 28, 2005.
• Which claims the benefit of U.S. Provisional Application No. 60/566,831, filed on April 30, 2004.

Due to this chain of continuation applications, the effective filing date for determining the patent term is the filing date of the earliest non-provisional application in the chain, which is April 28, 2005.

There are no divisional applications directly from the application that led to the '798 patent. The family consists entirely of a linear chain of continuation applications and one continuation-in-part.

---

Patent Term Adjustments (PTA) and Extensions (PTE)

A review of the file history for U.S. Patent No. 11,677,798 indicates the following regarding its term:

• Patent Term Adjustment (PTA): There has been no Patent Term Adjustment granted for this patent. The USPTO's calculation did not find any prosecution delays attributable to the agency that would warrant an extension of the patent's term.
• Patent Term Extension (PTE): There is no indication of a Patent Term Extension under 35 U.S.C. § 156. PTE is typically granted for delays caused by regulatory review (e.g., by the FDA) and is not applicable to the technology covered by this patent.

---

Projected Expiration Date

The term of a U.S. patent is generally 20 years from the filing date of the earliest U.S. or international (PCT) application to which priority is claimed, excluding any provisional applications.

• Earliest Non-Provisional Filing Date: April 28, 2005 (from application Ser. No. 11/116,783).
• Standard 20-Year Term: Adding 20 years to this date gives a base expiration date.

Calculation:

• April 28, 2005 + 20 years = April 28, 2025

Since there are no Patent Term Adjustments or Extensions, the projected expiration date for U.S. Patent No. 11,677,798 is April 28, 2025.

It is important to note that the patent's status on Google Patents is currently listed as "Expired - Lifetime." This is likely an automated calculation based on the priority date and does not reflect any failure to pay maintenance fees. Given the extensive litigation involving this patent family, it is almost certain that the assignee, DISH Technologies LLC, has duly paid all required maintenance fees. The patent should be considered active and enforceable until its calculated expiration date.

As a Senior Patent Strategist and Research Engineer, I have analyzed U.S. Patent No. 11,677,798. The following document is a defensive disclosure intended to establish prior art against potential future patent applications that claim incremental improvements upon the core concepts of the '798 patent.

Note on Patent Status: As of the date of this document (April 26, 2026), U.S. Patent 11,677,798 is understood to have expired, with its term concluding on April 28, 2025. This disclosure, therefore, serves to preempt attempts to re-patent minor variations of its underlying technology and place them firmly in the public domain.

Defensive Disclosure: Derivative Embodiments for Distributed Media Encoding

This disclosure details a series of derivative implementations, extensions, and applications of a system for segmenting media content into "streamlets" and encoding them at multiple bitrates using a distributed master-host architecture where job allocation is determined by a bidding mechanism.

---

Axis 1: Material & Component Substitution

Variation 1.1: QUIC-Based Streamlet Transport and Bid Protocol

Enabling Description: This variation replaces the HTTP/TCP-based transport layer for both streamlet delivery and the master-host bidding communication with the QUIC protocol. The master module opens a single QUIC connection to each host, but utilizes QUIC's multiplexed, independent streams within that connection. An "encoding job" is broadcast over a control stream, and each host returns its "bid" on a dedicated response stream. This approach mitigates head-of-line blocking; a delayed bid packet from one host does not stall the master's reception of bids from other hosts. Furthermore, the 0-RTT (Zero Round Trip Time) connection resumption feature of QUIC is used by hosts to re-establish communication with the master instantly after a transient network failure, improving the robustness of the encoding farm. The bid itself is a structured binary message (e.g., a Protocol Buffer) containing estimated clock cycles, GPU memory allocation, and a confidence score, which is then sent over a QUIC datagram frame for lower latency.

sequenceDiagram
    participant Master as Master Module
    participant HostA as Host A (QUIC Endpoint)
    participant HostB as Host B (QUIC Endpoint)

    Master->>HostA: Announce Job (Control Stream 1)
    Master->>HostB: Announce Job (Control Stream 1)
    Note right of HostA: Calculates bid based on local state.
    HostA-->>Master: Submit Bid A (Datagram)
    Note right of HostB: Network delay on Bid B.
    HostB-->>Master: Submit Bid B (Datagram)
    Note left of Master: Master receives Bid A first, can<br/>act without waiting for Bid B.
    Master->>HostA: Assign Job (Unidirectional Stream 3)

Variation 1.2: Heterogeneous Compute Fabric with Resource-Specific Bidding

Enabling Description: The "host computing modules" are not uniform CPUs but a heterogeneous fabric of computing resources, including FPGAs (Field-Programmable Gate Arrays) with dedicated video encoding IP cores, GPUs with CUDA/OpenCL acceleration, and specialized ASICs (Application-Specific Integrated Circuits). The "bid" from a host is a multi-part message that specifies which resource is being offered. For example, an FPGA-equipped host might bid with { "resource": "fpga_h265_encoder", "estimated_latency_ms": 5, "power_draw_watts": 15 }, while a GPU host bids with { "resource": "gpu_cuda_nvenc", "estimated_latency_ms": 12, "concurrent_streams": 4, "power_draw_watts": 75 }. The master module's assignment algorithm is extended to a multi-objective optimization problem, considering not just completion time but also power consumption, cost per encode, or the need to reserve certain resource types for higher-priority tasks.

graph TD
    subgraph Master Module
        A[Job Announcer] --> B{Bidding Evaluator};
        B --> C{Task Scheduler};
    end
    subgraph Host Fabric
        H1[Host 1: CPU Farm] -- Bid --> B;
        H2[Host 2: GPU Array] -- Bid --> B;
        H3[Host 3: FPGA Pool] -- Bid --> B;
        H4[Host 4: ASIC-based] -- Bid --> B;
    end
    C -- Assign Job to Optimal Resource --> H3;
    B -- Cost/Power/Latency Metrics --> C;

---

Axis 2: Operational Parameter Expansion

Variation 2.1: Nanoscale Real-Time Sensor Data Processing

Enabling Description: The invention is applied to the real-time processing of data streams from a high-frequency sensor array, such as in a particle accelerator or a high-resolution electron microscope. The "media content" is the raw sensor data stream (terabytes/second). A "streamlet" is a microsecond-duration data segment. The system "encodes" these streamlets into multiple "bitrates," which correspond to different data resolutions or analysis products: (1) a low-bitrate "thumbnail" stream representing a down-sampled or filtered version for real-time anomaly detection, (2) a medium-bitrate stream with key statistical features extracted for immediate scientific review, and (3) a high-bitrate, losslessly compressed version for archival. The "hosts" are nodes in a high-performance computing (HPC) cluster, and their "bids" reflect the availability of specific analysis libraries and processing cores required for each type of encoding.

flowchart LR
    subgraph Data Source
        Sensor[High-Frequency Sensor Array]
    end
    subgraph Processing System
        Capture[Capture Module] --> Streamletizer[Microsecond Streamletizer];
        Streamletizer --> Master[Master Module];
        Master -- Job Offers --> Host1[HPC Node 1];
        Master -- Job Offers --> Host2[HPC Node 2];
        Host1 -- Bid --> Master;
        Host2 -- Bid --> Master;
        Master -- Job Assignment --> Host1;
        Host1 --> Output1[Low-Res Anomaly Detection Stream];
        Host1 --> Output2[Medium-Res Feature Extraction];
        Host1 --> Output3[Lossless Archival Stream];
    end
    Sensor --> Capture;

Variation 2.2: Deep Space Communications with Latency-Aware Bidding

Enabling Description: This system is adapted for communications between a ground station (Master) and multiple Mars rovers or satellites (Hosts). The "content" is a high-resolution panoramic image or scientific data set. A "streamlet" is a packetized portion of this data. The "encoding" is a combination of compression and Forward Error Correction (FEC) at various levels of redundancy ("bitrates"). A more redundant encoding has a higher effective bitrate but is more resilient to transmission errors. The "bid" from a rover/host includes its current power level, available processing time, and, crucially, its next predicted communication window with Earth, including expected duration and signal-to-noise ratio. The Master module uses this to assign encoding tasks that can be completed and transmitted during the next available, and potentially brief, communication window.

sequenceDiagram
    participant GroundStation as Master (Earth)
    participant RoverA as Host A (Mars)
    participant RoverB as Host B (Mars)

    GroundStation->>RoverA: Request Bids for Data Chunk #123
    Note right of RoverA: Considers power, CPU idle, and next comms window (in 4 hours).
    RoverA-->>GroundStation: Bid: { chunk:123, time_to_encode: 120min, power: 80%, comms_in: 4h, snr_est: 12dB }
    GroundStation->>RoverB: Request Bids for Data Chunk #123
    Note right of RoverB: Considers power, CPU busy, and next comms window (in 1 hour).
    RoverB-->>GroundStation: Bid: { chunk:123, time_to_encode: 180min, power: 95%, comms_in: 1h, snr_est: 10dB }
    GroundStation->>RoverB: Assign Chunk #123 (Higher priority due to earlier comms window)

---

Axis 3: Cross-Domain Application

Variation 3.1: Distributed Pharmaceutical Compound Screening

Enabling Description: The system is applied to computational drug discovery. The "media content" is the vast chemical space of potential drug compounds. A "streamlet" is a batch of candidate molecules. The system "encodes" each batch at different "bitrates," where each bitrate represents a different type of simulation: a low-cost/low-fidelity docking simulation (low bitrate), a more intensive molecular dynamics simulation (medium bitrate), and a full quantum mechanics simulation (high bitrate). The "hosts" are research institutions or cloud-based compute clusters that "bid" on processing a batch of molecules. The bid reflects the availability of licensed simulation software (e.g., GROMACS, NAMD) and specialized hardware, allowing the master to farm out different simulation types to the most suitable providers.

graph TD
    A[Chemical Library Database] --> B(Streamlet Module <br> Batches of Molecules);
    B --> C{Master Module};
    C -- "Job: Low-Fidelity Docking" --> D1[Host 1: University Cluster];
    C -- "Job: Molecular Dynamics" --> D2[Host 2: Cloud GPU Farm];
    C -- "Job: Quantum Simulation" --> D3[Host 3: Supercomputer Center];
    D1 -- Bid(cost_per_sim: $0.1) --> C;
    D2 -- Bid(cost_per_sim: $5) --> C;
    D3 -- Bid(cost_per_sim: $100) --> C;
    C -- Assignment --> D1;
    D1 --> E[Results: Hit List];

Variation 3.2: Adaptive Fidelity in Federated Machine Learning

Enabling Description: The system is used to manage training rounds in a federated learning architecture. The "media content" is the global model from the central server. A "streamlet" is a specific layer or subset of the model's weights. The system "encodes" this streamlet into different "bitrates" by applying varying levels of quantization (e.g., 32-bit float, 16-bit float, 8-bit integer). The "hosts" are the end-user devices (e.g., mobile phones). Each device "bids" on training a quantized model version based on its current battery level, network connection (Wi-Fi vs. cellular), and CPU load. The master server assigns the highest fidelity (largest bitrate) training jobs to powerful, well-connected devices, and lower fidelity jobs to constrained devices, thereby maximizing participation without unduly burdening any single device.

stateDiagram-v2
    direction LR
    state "Master Server" as Master {
        [*] --> Announce_Round
        Announce_Round --> Awaiting_Bids: Distribute Global Model
        Awaiting_Bids --> Assign_Jobs: Receive Bids from Devices
        Assign_Jobs --> Aggregating: Collect Local Updates
        Aggregating --> Announce_Round: Update Global Model
    }
    state "Edge Device (Host)" as Device {
        state "Evaluate Capacity" as Eval
        state "Send Bid" as Bid
        state "Local Training" as Train
        state "Send Update" as Update

        [*] --> Eval: New Round Starts
        Eval --> Bid: {battery:90%, net:wifi, cpu:10%}
        Bid --> Train: Receive Quantized Model (e.g., FP16)
        Train --> Update: Compute Weight Deltas
        Update --> [*]
    }

---

Axis 4: Integration with Emerging Tech

Variation 4.1: AI-Optimized Predictive Bidding and Content-Aware Assignment

Enabling Description: Each host module incorporates a lightweight, trained neural network that predicts encoding completion time. The model's inputs are not just static system parameters (CPU, RAM) but also features extracted from the incoming raw streamlet, such as motion vectors, scene complexity, and color histograms. The host's "bid" is the output of this predictive model. The master module uses a reinforcement learning (RL) agent (e.g., a multi-armed bandit algorithm) to assign jobs. It learns over time which hosts are consistently over- or under-bidding for certain content types (e.g., Host A is fast at animation, Host B excels at live-action sports) and adjusts its assignment strategy to maximize the global throughput of the encoding farm, going beyond simply picking the lowest bidder.

flowchart TD
    subgraph Host
        A[Raw Streamlet] --> B(Feature Extractor);
        B -- motion, complexity --> C{Predictive NN};
        D[System Metrics] -- cpu, mem --> C;
        C -- Predicted Time --> E[Bid];
    end
    subgraph Master
        F[RL Agent]
    end
    E --> F;
    F -- Assigns job based on bid AND learned host performance --> G[Assignment Decision];

Variation 4.2: Blockchain-Verified Encoding for Royalty Distribution

Enabling Description: This variation integrates a permissioned blockchain to create an immutable audit trail for content processing. When a host completes an encoding job, it generates a proof-of-work that includes the hash of the source streamlet, the hash of the output encoded streamlet, its own digital ID, and the bitrate. This proof is submitted to the master, which validates it and commits it as a transaction to a blockchain. Smart contracts on this blockchain can then automatically trigger micropayments for royalties. For example, a content owner is paid for the use of the source, the encoding host is paid for its work, and a distributor is paid when the final streamlet is requested by a user, all tracked transparently and verifiably on-chain.

sequenceDiagram
    participant Master
    participant Host
    participant Blockchain
    participant User

    Master->>Host: Assign Encoding Job (Streamlet S1)
    Host->>Host: Encode S1 -> S1_encoded
    Host->>Master: Return S1_encoded + Proof(hash(S1), hash(S1_encoded), HostID)
    Master->>Blockchain: Validate and Record Transaction
    User->>Master: Request S1_encoded
    Master->>User: Serve Streamlet
    Blockchain->>Blockchain: Smart Contract Executes (Triggers Micropayments)

---

Axis 5: The "Inverse" or Failure Mode

Variation 5.1: Graceful Degradation via Single-Source Bypass

Enabling Description: The master module continuously monitors the health of the host farm by analyzing the rate and quality of incoming bids. If the number of active hosts drops below a critical threshold (e.g., 50%) or if the average bid time exceeds a predefined SLO (Service Level Objective), the master triggers a "fail-safe" state. In this state, it signals the upstream capture module to stop segmenting the content and instead produce a single, low-bitrate, low-quality "failsafe" stream. This stream bypasses the master-host system entirely and is written directly to the content delivery network. This ensures uninterrupted service for end-users, albeit at a reduced quality, preventing a catastrophic failure of the complex distributed encoding system from causing a complete outage. The system automatically reverts to the distributed mode once host health is restored.

stateDiagram-v2
    [*] --> Normal_Operation
    Normal_Operation --> Failsafe_Mode: Host Count < Threshold OR Avg Bid Time > SLO
    Failsafe_Mode --> Normal_Operation: Host Health Restored

    state Normal_Operation {
        description "Master assigns jobs to distributed hosts for multi-bitrate encoding."
    }
    state Failsafe_Mode {
        description "Master signals Capture to produce a single, low-bitrate stream, bypassing hosts."
    }

---

Combination Prior Art Scenarios

1. Combination with MPEG-DASH and Kubernetes: The master module is implemented as a Kubernetes Operator. When a new live stream starts, a Custom Resource Definition (CRD) for a MediaStream is created. The operator watches for this CRD and dynamically scales a deployment of containerized encoding "hosts" (e.g., using FFmpeg). The operator's control loop acts as the master, querying the Kubernetes API for node metrics (CPU/GPU utilization) which serve as the basis for a "bid". The operator then creates Kubernetes Job objects to perform the encoding on the chosen nodes. The outputted streamlets and the generated MPEG-DASH manifest (.mpd) are written to a cloud storage bucket for distribution.

2. Combination with WebRTC and AV1: A live stream is ingested from a user's web browser using the WebRTC getUserMedia API and transmitted to the capture module via a Secure Real-time Transport Protocol (SRTP) connection. The capture module segments this stream. The master-host system, utilizing hosts equipped with hardware AV1 encoders, processes the streamlets into a set of adaptive bitrate streams using the royalty-free AV1 codec. The bids from the hosts would specifically indicate their AV1 encoding profile capabilities. The resulting AV1 streamlets are packaged for delivery via HLS.

3. Combination with Apache Kafka for Job Queuing: The master module does not communicate directly with hosts. Instead, it acts as a producer to an Apache Kafka topic named encoding-jobs. Each message contains a source streamlet. The host modules act as consumers in a consumer group on this topic. Kafka's partitioning mechanism handles the initial load balancing. A host "bids" by sending a message to a separate bids topic with its ID and capacity. The master reads this topic to maintain a real-time state of host availability and can send high-priority jobs to specific partitions assigned to the best-bidding hosts. This decouples the system, making it more resilient and scalable.