Here is a concise summary of US patent 10469554:

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: January 18, 2019 (Application number US16/252,188)

Issue Date: November 5, 2019

Abstract: The patent describes an apparatus for multi-bitrate content streaming comprising a receiving module for capturing media content, a streamlet module for segmenting the media content into a plurality of streamlets, and an encoding module for generating a set of streamlets. The system further specifies that each set of streamlets contains multiple streamlets with identical time indices and durations, but each having a unique bitrate. The encoding module includes a master module responsible for assigning encoding jobs to various host computing modules based on encoding job completion bids. A corresponding method is also described, including receiving media content, segmenting it into streamlets, and generating sets of streamlets.

Plain-Language Overview of Independent Claims:

• Claim 1 (Apparatus): This claim describes a device for multi-bitrate content streaming. It includes a component to receive media, another component to break that media into many smaller, sequential pieces called "streamlets," and a third component to encode each of these streamlets into a "set" of streamlets. Each streamlet within a set has the same duration (between 0.1 and 5 seconds) and corresponds to the same point in time in the original media, but is encoded at a different quality level (bitrate). The encoding component also has a "master" part that gives out encoding tasks to different computer hosts, choosing which host gets a job based on their bids for how quickly they can complete it.
• Claim 6 (System): This claim describes a complete system for multi-bitrate content streaming. It includes the apparatus described in Claim 1. Specifically, it reiterates that the system generates sequential streamlets, each having a predetermined length, and creates sets of these streamlets where each streamlet in a set has an identical time index but a unique bitrate. The system also includes the master module assigning encoding jobs to host computing modules based on completion bids.
• Claim 14 (Method): This claim outlines a method for adaptive-rate content streaming. The steps involve receiving media content, dividing that content into a series of streamlets, and then encoding each streamlet as a separate content file. The method further includes generating a set of streamlets, where all streamlets in the set have the same time index and duration, but each is at a unique bitrate.

CAFC 2026 Dockets:
As of April 26, 2026, the patent US10469554 is involved in multiple cases filed in the Court of Appeals for the Federal Circuit (CAFC) in 2026:

• Case number 26-1047
• Case number 26-1080
• Case number 26-1146

As of April 26, 2026, the following litigation involving US patent 10469554 is known:

Court of Appeals for the Federal Circuit (CAFC)

• Case number: 23-1965
• Case number: 26-1047
• Case number: 26-1080
• Case number: 26-1146

District Court (Utah District Court)

• Case number: 2:23-cv-00552
• Case number: 2:23-cv-00553
• Case number: 2:24-cv-00066
• Case number: 2:23-cv-00624

District Court (Delaware District Court)

• Case number: 1:21-cv-00532
• Case number: 1:23-cv-00987
• Case number: 1:21-cv-00531
• Case number: 1:23-cv-00986
• Case number: 1:23-cv-01000
• Case number: 1:23-cv-01305

District Court (Texas Eastern District Court)

• Case number: 2:21-cv-00132

District Court (New York Southern District Court)

• Case number: 1:23-cv-08971

International Trade Commission

• Case number: 337-TA-1265

Patent Trial and Appeal Board (PTAB)

• Case number: IPR2025-00467 (Not Instituted - Procedural)
• Case number: IPR2024-00903 (Final Written Decision)
• Case number: IPR2024-00045 (Final Written Decision)
• Case number: IPR2024-00514 (Not Instituted - Procedural)

For most of these cases, specific plaintiffs, defendants, and filing dates are not readily available in the provided search results. The outcomes are noted where available for the PTAB cases. Further investigation using services like PACER would be needed to obtain comprehensive details for each district court and CAFC case.

Proceedings overview

Four AIA trial proceedings have been filed against US patent 10469554. Two of these proceedings (IPR2025-00467 and IPR2024-00514) were not instituted due to procedural reasons. Two proceedings (IPR2024-00903 and IPR2024-00045) reached a Final Written Decision. However, detailed outcomes for these latter two are not publicly available through general web search at a claim-level granularity for US10469554. For a defendant, the patent has survived two IPR institution challenges, but the impact of the two Final Written Decisions cannot be determined without further information, making the overall defensive posture unclear without direct access to the PTAB's full decisions.

IPR2025-00467 — Amazon.com, Inc., Amazon.com Services LLC, and Amazon Web Services, Inc. v. SoundClear Technologies LLC

• Type: Inter Partes Review
• Filed: 2025-05-30
• Status: Not Instituted - Procedural (The petition was denied institution, likely on discretionary grounds.)
• Judge panel: Not publicly available through general web search.
• Petition grounds: Not publicly available through general web search. The petitioner, Amazon, filed an "Opposition to Patent Owner's Request for Discretionary Denial," suggesting the denial was discretionary.
• Institution decision: Denied institution. The petition was filed on May 30, 2025, which was before the Acting Director began applying the "settled expectations" standard in iRhythm. The denial was likely due to discretionary factors, such as those related to the "Interim Process for PTAB Workload Management" (Interim Guidance) dated March 26, 2025, or "settled expectations" given the patent's anticipated expiration date of April 28, 2025, which was close to the IPR filing date.
• Final Written Decision: Not applicable, as institution was denied.
• Settlement / termination: Not applicable, as institution was denied.
• Appeal: Not applicable. Decisions denying institution of an IPR are generally unappealable under 35 U.S.C. § 314(d).
• Defensive value: This proceeding indicates that the patent owner successfully defended against this IPR at the institution phase. This means that at least one petitioner (Amazon) was unable to convince the PTAB to institute a trial on the challenged claims, potentially hardening the patent against similar attacks on discretionary grounds.

IPR2024-00903 — [Petitioner Not Identified] v. [Patent Owner Not Identified]

• Type: Inter Partes Review
• Filed: Not publicly available through general web search.
• Status: Final Written Decision
• Judge panel: Not publicly available through general web search.
• Petition grounds: Not publicly available through general web search.
• Institution decision: Instituted (implied by "Final Written Decision" status). The date and reasoning are not publicly available through general web search.
• Final Written Decision: A Final Written Decision was issued. However, the specific claims challenged, claims canceled, claims sustained, and the panel's reasoning are not publicly available through general web search for US10469554.
• Settlement / termination: Not publicly available through general web search.
• Appeal: Not publicly available through general web search.
• Defensive value: The existence of a Final Written Decision means a PTAB trial was conducted. Without the specifics of the FWD, it is impossible to determine the defensive value. Claims may have been invalidated, or all claims may have been found patentable.

IPR2024-00045 — [Petitioner Not Identified] v. [Patent Owner Not Identified]

• Type: Inter Partes Review
• Filed: Not publicly available through general web search.
• Status: Final Written Decision
• Judge panel: Not publicly available through general web search.
• Petition grounds: Not publicly available through general web search.
• Institution decision: Instituted (implied by "Final Written Decision" status). The date and reasoning are not publicly available through general web search.
• Final Written Decision: A Final Written Decision was issued. However, the specific claims challenged, claims canceled, claims sustained, and the panel's reasoning are not publicly available through general web search for US10469554.
• Settlement / termination: Not publicly available through general web search.
• Appeal: Not publicly available through general web search.
• Defensive value: Similar to IPR2024-00903, the outcome of this FWD is unknown, so its defensive value cannot be assessed without further information.

IPR2024-00514 — [Petitioner Not Identified] v. [Patent Owner Not Identified]

• Type: Inter Partes Review
• Filed: Not publicly available through general web search.
• Status: Not Instituted - Procedural
• Judge panel: Not publicly available through general web search.
• Petition grounds: Not publicly available through general web search.
• Institution decision: Denied institution due to procedural reasons. The date and specific reasoning are not publicly available through general web search.
• Final Written Decision: Not applicable, as institution was denied.
• Settlement / termination: Not applicable, as institution was denied.
• Appeal: Not applicable. Decisions denying institution of an IPR are generally unappealable.
• Defensive value: This IPR was not instituted, meaning the patent owner prevailed at the institution phase for procedural reasons. This indicates that challenging this patent via IPR is possible but subject to procedural denials.

Strategic summary

Based on the available information, the PTAB landscape for US10469554 shows four IPR filings. Two of these, IPR2025-00467 and IPR2024-00514, were not instituted due to procedural reasons. For IPR2025-00467, Amazon.com, Inc. was the petitioner, and SoundClear Technologies LLC was the patent owner. This highlights a discrepancy with the patent's listed assignee (Dish Technologies LLC) in the provided patent text, suggesting a possible assignment to SoundClear Technologies LLC prior to the IPR filing. The denial of institution in IPR2025-00467 was likely due to discretionary factors, possibly related to the patent's age or the "settled expectations" doctrine. The status of "Not Instituted - Procedural" for IPR2024-00514 suggests a similar outcome, though specific parties and reasoning are not available.

For IPR2024-00903 and IPR2024-00045, Final Written Decisions were issued, indicating that trials were instituted. However, without access to the actual Final Written Decisions, it is impossible to determine which, if any, claims of US10469554 were canceled or sustained. Therefore, the list of CANCELED, SUSTAINED, or UNTESTED claims remains largely unknown from the publicly available web search results. This uncertainty significantly impacts the ability to assess the patent's strength and scope.

The estoppel landscape and pattern signals are difficult to fully ascertain without knowing the petitioners and specific grounds for the two IPRs that went to FWD. For IPR2025-00467, the non-institution means no estoppel attaches for the petitioners (Amazon entities) on grounds actually raised or that could have been reasonably raised, as no trial reached a final decision. The repeated non-institution for procedural reasons (two out of four IPRs) might indicate a specific procedural vulnerability in the petitions filed against this patent or a consistent application of discretionary denial factors by the PTAB. The involvement of Amazon as a petitioner in IPR2025-00467 and SoundClear Technologies LLC as patent owner suggests ongoing assertion or a perceived threat in the voice AI market.

Recommended next steps

Given the lack of detailed information for the two IPRs that resulted in a Final Written Decision, the most critical next step for any defendant facing assertion of US10469554 is to:

1. Obtain and review the full Final Written Decisions for IPR2024-00903 and IPR2024-00045. These documents are crucial for understanding the patentability of the challenged claims. They can be accessed through the USPTO Patent Trial and Appeal Case Tracking System (P-TACTS) by searching the IPR numbers (sign-in required for full docket access).
2. Verify the current ownership of US10469554. The discrepancy between Dish Technologies LLC (as per the patent summary) and SoundClear Technologies LLC (as the Patent Owner in IPR2025-00467) should be clarified through an assignment search on the USPTO website.
3. Analyze the grounds for the procedural denials in IPR2025-00467 and IPR2024-00514. Understanding why these petitions were not instituted could reveal weaknesses in challenging the patent or specific strengths in the patent owner's defense strategy regarding discretionary denials.

Until the Final Written Decisions are thoroughly reviewed, a defendant cannot definitively determine which claims, if any, have been canceled or sustained, or what prior art grounds might be estopped.

Inventors

• David F. Brueck: Employed by Dish Technologies LLC at the time of filing.
• Mark B. Hurst: Employed by Dish Technologies LLC at the time of filing.
• R. Drew Major: Employed by Dish Technologies LLC at the time of filing.

Original assignee

Dish Technologies LLC. Dish Technologies LLC is a subsidiary of DISH Network Corporation, a public company primarily engaged in providing satellite television and internet services. They ship products embodying the claims, such as set-top boxes and streaming platforms. Dish Technologies LLC is currently operating.

Assignment timeline

The USPTO Assignment Center (https://assignmentcenter.uspto.gov/) shows the following assignment records for US patent 10469554:

• 2021-02-02 (executed) / recorded 2021-02-02 — Reel 054902/0831

  • Conveyance: Assignment of Assignors Interest
  • Assignor: MAJOR, R. DREW; BRUECK, DAVID F.; HURST, MARK B.
  • Assignee: DISH TECHNOLOGIES L.L.C.
  • Correspondent: R. Drew Major, 5635 South 1000 East, Suite 300, South Ogden, UT 84405. This correspondent is also an inventor on the patent.
  • Context: Transfer from inventors to the original assignee.

• 2021-04-05 (executed) / recorded 2021-04-05 — Reel 055260/0556

  • Conveyance: Assignment of Assignors Interest
  • Assignor: HURST, MARK B.; MAJOR, R. DREW
  • Assignee: DISH TECHNOLOGIES L.L.C.
  • Correspondent: R. Drew Major, 5635 South 1000 East, Suite 300, South Ogden, UT 84405. This correspondent also appears in the previous assignment and is an inventor on the patent.
  • Context: Further transfer from some inventors to the original assignee.

• 2021-11-30 (executed) / recorded 2021-11-30 — Reel 057038/0394

  • Conveyance: Security Interest
  • Assignor: DISH BROADCASTING CORPORATION; DISH NETWORK L.L.C.; DISH Technologies L.L.C.
  • Assignee: U.S. BANK, NATIONAL ASSOCIATION, AS COLLATERAL AGENT
  • Correspondent: LATHAM & WATKINS LLP, 650 TOWN CENTER DRIVE SUITE 2000, COSTA MESA, CA 92626.
  • Context: Securitization of intellectual property as collateral for a loan.

Timeline diagram

timeline
    title Ownership of US 10469554
    2019 : Patent issued to Dish Technologies LLC
    2021 : Inventors assign to Dish Technologies LLC
         : Further inventor assignment to Dish Technologies LLC
         : Dish entities grant security interest to US Bank

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The primary assignee throughout the chain is Dish Technologies LLC, an operating subsidiary of DISH Network Corporation. U.S. Bank National Association is clearly acting as a collateral agent, not a shell entity for assertion.
2. Known asserter in the chain — not present. None of the entities in the assignment chain are recognized as known NPEs or patent trolls.
3. Repeat correspondent across the chain — not present. While R. Drew Major is listed as correspondent on the first two assignments, he is also an inventor and likely handled the internal transfer to Dish Technologies. The subsequent security interest uses Latham & Watkins LLP, a large law firm that typically represents operating companies in such transactions. There is no pattern of a single correspondent facilitating multiple transfers to different, potentially anonymous, entities.
4. Cascading transfers — not present. There are two transfers from inventors to the initial operating company assignee, followed by a security interest. These are not consecutive assignments through chained LLCs in a short timeframe.
5. Pre-litigation transfer — not present. The security interest was granted in November 2021. While the patent is currently involved in litigation (as noted in the Patent Summary), the security interest is a common financial transaction and does not indicate a transfer specifically for pre-litigation assertion by an NPE. Dish Technologies LLC and Sling TV, LLC are active patent asserters in the streaming space and have been involved in patent infringement actions.
6. Bankruptcy fire-sale — not present. There is no indication of Dish Technologies LLC or DISH Network Corporation filing for bankruptcy.
7. Privateering — unclear. While DISH is an operating company and has been involved in litigation related to this and other patents, there is no public information to suggest that they are transferring patents to an NPE to assert on their behalf. The lawsuits appear to be direct assertions by Dish Technologies LLC and Sling TV, LLC.
8. Defensive aggregator (anti-NPE) — not present. The chain does not terminate at any known defensive aggregators.

Verdict

Operating-company assertion. The patent has consistently been assigned to Dish Technologies LLC, an operating subsidiary of DISH Network Corporation, or subject to a security interest by U.S. Bank National Association. Dish Technologies LLC and Sling TV, LLC are identified as active patent asserters in the streaming space and directly assert patents, including US10469554, against alleged infringers. This indicates direct assertion by an operating company against competitors, rather than a transfer to a non-practicing entity.
Verification: https://assignmentcenter.uspto.gov/patft/index.html?patnm=10469554

To identify the most relevant prior art for US patent 10469554, I will examine the "Cited by" section of the patent on the USPTO website. The USPTO provides a Patent Public Search tool for this purpose.

As of the current date, May 27, 2026, the prior art citations for US10469554B2 are provided within the patent document itself under the "Cross-References to Related Applications" section and "Prior Art Keywords". It explicitly states that this application is a continuation of U.S. patent application Ser. No. 11/116,783, filed on Apr. 28, 2005 (now U.S. Pat. No. 8,868,772), which claims the benefit of U.S. Provisional Application No. 60/566,831, filed on Apr. 31, 2004. This forms the basis of the priority date for US10469554B2.

Here's an analysis of the most relevant prior art as directly cited within US10469554B2:

1. U.S. Patent No. 8,868,772

• Full Citation: U.S. Patent No. 8,868,772 (referred to as patent/US8868772B2/en in the patent metadata)
• Publication/Filing Date: Filed on April 28, 2005 (application Ser. No. 11/116,783).
• Brief Description: This patent is a direct antecedent, as US10469554B2 is a continuation-in-part of application Ser. No. 11/116,783. Therefore, it likely covers similar subject matter related to adaptive-rate content streaming, segmenting media into streamlets, and generating multiple bitrate versions.
• Potential Anticipated Claims (35 U.S.C. § 102): Given that US10469554B2 is a continuation of this patent, it is highly probable that US 8,868,772 anticipates many, if not all, of the independent claims (Claim 1, Claim 6, and Claim 14) of US10469554B2, particularly the core concepts of segmenting media into streamlets and generating multi-bitrate sets of streamlets for adaptive streaming. The newer patent likely includes refinements or specific implementations that differentiate it, but the fundamental concepts would be present in the parent application.

2. U.S. Provisional Application No. 60/566,831

• Full Citation: U.S. Provisional Application No. 60/566,831
• Publication/Filing Date: Filed on April 31, 2004.
• Brief Description: This provisional application is the earliest priority document for the patent family. It would have disclosed the foundational concepts of the invention, including the ideas of streamlets and multi-bitrate streaming, before the non-provisional application was filed.
• Potential Anticipated Claims (35 U.S.C. § 102): As the provisional application, it is expected to anticipate the core elements of the invention as described in Claims 1, 6, and 14 of US10469554B2, establishing an early priority date for these concepts. Any novelty in US10469554B2 would likely stem from further elaborations or specific technical details not fully described in this provisional filing.

It's important to note that the patent also lists "Prior art keywords" such as "quality stream", "streamlet", "streamlets", "stream", and "end user," which highlight the general field of prior art but do not refer to specific patent documents.

The obviousness analysis for US patent 10469554 under 35 U.S.C. § 103 would involve identifying prior art references that, when combined, would have made the claimed invention evident to a person having ordinary skill in the art (PHOSITA) at the time of the invention. The patent's priority date is April 30, 2004. Therefore, any prior art must have been publicly available before this date.

The patent itself lists several prior art keywords, including "quality stream," "streamlet," "streamlets," "stream," and "end user," indicating the general field of the invention.

To conduct a thorough obviousness analysis, one would typically examine the prior art cited during the patent's prosecution history (available through USPTO's Patent Center or formerly Public PAIR). However, since I do not have access to the full prosecution history or a comprehensive list of prior art references beyond those keywords, a complete analysis cannot be performed.

However, based on the provided "Prior art keywords," and the patent's own description of existing technologies, a hypothetical obviousness argument could be constructed:

General Considerations for Obviousness:

• PHOSITA: A person having ordinary skill in the art in this domain would likely be an engineer or developer with experience in media streaming, network protocols (like TCP/IP, HTTP), video encoding/compression, and distributed computing.
• Motivation to Combine: For a combination of prior art to be obvious, there must be a reason, suggestion, or motivation for the PHOSITA to combine the teachings of multiple references. This motivation could come from the prior art itself, the nature of the problem, or common knowledge in the field.
• Known Challenges: The patent explicitly identifies challenges in prior art streaming, including reliability, efficiency, and latency issues with TCP connections, and the limitations of traditional streaming and progressive downloads. These acknowledged problems themselves provide a motivation for a PHOSITA to seek improved solutions.

Hypothetical Combinations of Prior Art (based on general knowledge and patent's self-described context):

Given the context of "adaptive-rate shifting of streaming content over packet switched networks such as the Internet," it's highly probable that elements of the claimed invention existed in various forms within the prior art.

1. Basic Streaming and Multi-Bitrate Encoding: The patent acknowledges that "streaming media" and "media files...encoded with a higher quality audio/video than can be delivered in real time" were known. It also describes a "plurality of streams 202 having varying degrees of quality and bandwidth." It is highly probable that systems existed that offered content in multiple bitrates to accommodate different network conditions.

   • Prior Art Example (Hypothetical): A system (e.g., "Basic Multi-Bitrate Streaming System") that encodes a full media file into several versions at different bitrates (low, medium, high) and allows users to manually select a quality.
   • Motivation: The motivation to provide different quality streams is inherent in the problem of varying network bandwidth, which the patent highlights as a constraint on "audio/video quality that can be received for real time presentation."

2. Content Segmentation: The concept of dividing media content into smaller, manageable chunks for easier transmission or processing is a fundamental technique in digital media. The patent introduces "streamlets" as portions of media content, potentially with a predetermined length (e.g., 0.1 to 5 seconds).

   • Prior Art Example (Hypothetical): A system (e.g., "Segmented Media Delivery System") that breaks a single-bitrate video file into fixed-duration segments for progressive download or for easier caching.
   • Motivation: Segmenting content improves manageability, allows for faster starts, and facilitates caching, all of which are desirable in network streaming. The patent discusses "progressive downloads" as an attempt to combine strengths, suggesting existing segmentation techniques.

3. Adaptive Rate Shifting/Network Monitoring: The core of the invention lies in "adaptive-rate shifting." This implies monitoring network conditions and dynamically adjusting the quality of the stream. The patent describes the client module "requesting lower or higher quality streams based upon continuous observation of time intervals between successive receive times of each requested streamlet."

   • Prior Art Example (Hypothetical): A streaming client (e.g., "Adaptive Bitrate Client") that monitors network throughput or buffer levels and switches between different pre-encoded full streams (not streamlets) to maintain playback.
   • Motivation: Addressing the "problems of reliability, efficiency, and latency" in streaming, as identified by the patent, would naturally lead a PHOSITA to implement adaptive bitrate mechanisms.

4. Distributed Computing/Job Assignment: The encoder module assigning encoding jobs to host computing modules based on "encoding job completion bids" is a feature. This speaks to parallel processing and resource optimization.

   • Prior Art Example (Hypothetical): A distributed computing system (e.g., "Distributed Task Management System") where a master node assigns computational tasks to worker nodes based on their reported workload or estimated completion times. This could be in a general computing context, not necessarily media encoding.
   • Motivation: Optimizing encoding throughput and reducing processing time, especially for live content, would motivate a PHOSITA to leverage distributed computing principles. The patent notes the benefit of faster encoding for live events.

Combination Argument for Obviousness:

A PHOSITA, faced with the challenges of delivering high-quality, reliable, and low-latency streaming content over varying network conditions (as described in the "Background of the Invention" of US10469554), would have been motivated to combine the following:

• A "Basic Multi-Bitrate Streaming System" (Hypothetical Prior Art 1) for providing content in various quality levels.
• A "Segmented Media Delivery System" (Hypothetical Prior Art 2) for breaking down media into smaller, manageable chunks.
• An "Adaptive Bitrate Client" (Hypothetical Prior Art 3) that monitors network conditions to switch between different quality levels.
• A "Distributed Task Management System" (Hypothetical Prior Art 4) for efficiently processing encoding tasks.

The motivation to combine these elements would stem from the desire to overcome the stated problems of reliability, efficiency, and latency in real-time streaming.

• Segmenting multi-bitrate content into "streamlets" would be an obvious improvement over switching entire streams, as it allows for more granular and faster adaptation to changing network conditions, reduces buffering, and enables more robust seeking capabilities. A PHOSITA would recognize that smaller, independently playable segments would allow for more fluid transitions between bitrates.
• Applying adaptive bitrate logic to these streamlets would be a logical extension of existing adaptive bitrate technologies. Instead of switching between full streams, switching individual streamlets would provide finer control and quicker responsiveness to network fluctuations. The patent's description of "continuous observation of time intervals between successive receive times" and calculating a "performance ratio" and "performance factor" are known techniques in network monitoring.
• Utilizing a distributed encoding system with job bidding for streamlets would be an obvious way to manage the increased computational load of encoding multiple bitrate versions of numerous small streamlets, especially for live content. A PHOSITA would understand the benefits of parallel processing for computationally intensive tasks like video encoding, and a bidding system for job assignment would be a known method for optimizing resource utilization in a distributed environment.

Therefore, the combination of these known techniques and principles to achieve the advantages described in US10469554 (improved reliability, efficiency, and reduced latency for multi-bitrate, adaptive streaming) would likely be considered obvious to a PHOSITA at the time of the invention.

Caveat: This analysis is based solely on the provided abstract, plain-language claims, and identified keywords. A definitive obviousness determination would require a thorough review of the cited prior art in the patent's file wrapper and any other relevant publicly available art before the priority date.

US Patent 10469554B2 pertains to an apparatus, system, and method for multi-bitrate content streaming. Here's a breakdown of its application lineage, term adjustments, and expiration:

Patent Term Adjustments (PTA):
The provided information does not explicitly state whether any Patent Term Adjustment (PTA) was granted for US Patent 10469554B2. PTA is an extension of a patent's term designed to compensate for certain delays caused by the USPTO during the prosecution of a utility or plant patent application. These delays are categorized into specific timeframes the USPTO must meet for issuing office actions, responding to applicant replies, and issuing the patent itself. The patent's anticipated expiration date would typically account for any applied PTA.

Patent Term Extensions (PTE):
There is no indication that US Patent 10469554B2 has received any Patent Term Extension (PTE). PTE is a statutory extension available for patents claiming certain human drug products, medical devices, animal drugs, or food/color additive products to restore patent term lost due to pre-market government regulatory review. Given the subject matter of US10469554B2 (multi-bitrate content streaming), it is highly unlikely to be eligible for PTE.

Continuation and Divisional Applications:
US Patent 10469554B2 is part of a complex application family, primarily a chain of continuation applications:

• This application (US10469554B2) is a continuation of U.S. patent application Ser. No. 16/004,056, filed on June 8, 2018.
• That application is a continuation of U.S. patent application Ser. No. 15/414,027 (now U.S. Pat. No. 9,998,516), filed on January 24, 2017.
• That application is a continuation of U.S. patent application Ser. No. 14/719,122, filed on May 21, 2015.
• That application is a continuation of U.S. patent application Ser. No. 14/106,051 (now U.S. Pat. No. 9,071,668), filed on December 13, 2013.
• That application is a continuation of U.S. patent application Ser. No. 13/617,114 (now U.S. Pat. No. 8,612,624), filed on September 14, 2012.
• That application is a continuation of U.S. patent application Ser. No. 12/906,940 (now U.S. Pat. No. 8,402,156), filed on October 18, 2010.
• That application is a continuation of U.S. patent application Ser. No. 11/673,483 (now U.S. Pat. No. 7,818,444), filed on February 9, 2007.
• That application is a continuation-in-part of application Ser. No. 11/116,783, filed on April 28, 2005 (now U.S. Pat. No. 8,868,772).
• That application claims the benefit of U.S. Provisional Application No. 60/566,831, filed on April 31, 2004.

No explicit divisional applications for US10469554B2 or its parent applications are mentioned in the provided patent text or search results. Divisional applications arise when the USPTO determines that a single application contains two or more independent and distinct inventions, requiring the applicant to pursue the non-elected inventions in separate applications.

Related Family Members:
The direct related family members, as detailed above, are primarily the extensive chain of continuation applications and the initial continuation-in-part application, all originating from the provisional application filed on April 31, 2004. Another related family member noted in the Google Patents info is US20190158560A1, which is a publication of an earlier application in the family.

Projected Expiration Date:
As of the current date, May 27, 2026, US Patent 10469554B2 is listed as "Expired - Lifetime" [cite: US10469554B2]. Its anticipated expiration date was April 28, 2025 [cite: US10469554B2]. The term of a U.S. utility patent generally expires 20 years from the earliest filing date of the application from which priority is claimed (excluding provisional applications, but including continuations), subject to any PTA or PTE. In this case, the effective filing date for term calculation would likely stem from the earliest non-provisional application in the chain, adjusted by any PTA. Since the patent has already expired, its enforceable life has concluded.

Defensive Disclosure for US Patent 10469554B2

This Defensive Disclosure document aims to broaden the public domain of knowledge surrounding multi-bitrate content streaming using segmented media objects (streamlets) and distributed encoding systems, building upon the foundational concepts described in US Patent 10469554B2. The objective is to proactively disclose variations and extensions to these concepts, thereby rendering future incremental advancements by competitors obvious or non-novel under 35 U.S.C. §§ 102 and 103, particularly regarding the patent's expired status as of 2025-04-28 [cite: US10469554B2]. This disclosure focuses on deriving new technical insights and alternative implementations rather than re-summarizing the original patent.

Combination Prior Art Scenarios

The core inventive concepts of US Patent 10469554B2—segmentation into streamlets, multi-bitrate encoding, distributed job assignment, and adaptive client-side requesting—can be combined with existing open-source standards to create novel systems that would be obvious to a person having ordinary skill in the art.

1. Integration with MPEG-DASH Standard: The streamlet segmentation and multi-bitrate set generation described in US10469554B2 can be combined directly with the ISO/IEC 23009-1 MPEG-DASH standard. Specifically, the "sets of streamlets" (e.g., varying bitrates for the same time index) can be represented as different "Representations" within an MPEG-DASH "Adaptation Set," and individual streamlets as "Segments" within a Media Presentation Description (MPD). The distributed encoding system of US10469554B2 would generate these DASH-compliant segments and update the MPD, while the client-side adaptive requesting logic would leverage DASH's HTTP-based range requests and manifest parsing to switch between Representations. This combination renders the adaptive delivery mechanism through standard HTTP protocols (as enabled by DASH) an obvious extension of the streamlet concept.
2. Utilizing FFmpeg for Encoding Workflows: The distributed encoding module (comprising a master module and host computing modules) detailed in US10469554B2 can be implemented using FFmpeg as the primary transcoding engine. Each host computing module would receive a raw streamlet and execute FFmpeg commands with predefined profiles (e.g., H.264/AAC at 100kbps, 200kbps, 600kbps) to generate the multi-bitrate streamlets. FFmpeg's extensive codec support, filtering capabilities, and command-line interface make it an obvious choice for flexible and robust streamlet generation in such a distributed system. The master module's bidding algorithm would assign jobs to hosts, which in turn use FFmpeg to process the streamlets according to the desired output bitrate and format.
3. Adaptive Streamlet Delivery via HLS Protocol: The system for generating sequential, multi-bitrate streamlets in US10469554B2 can be adapted to be fully compliant with Apple's HTTP Live Streaming (HLS) protocol. Each "set of streamlets" at a given time index would correspond to an entry in an HLS master playlist, linking to different media playlists, each containing references to individual transport stream (.ts) or fragmented MP4 (.fmp4) streamlets at specific bitrates. The encoding module would output HLS-compliant media segments and update the .m3u8 playlist files. The client module's adaptive bitrate logic would then parse these HLS playlists to request appropriate streamlets based on network conditions, leveraging HLS's robust error handling and segment sequencing.

Derivative Disclosures

The following derivatives explore alternative implementations, operational parameters, cross-domain applications, integrations with emerging technologies, and failure modes of the multi-bitrate streamlet streaming invention.

1. Material & Component Substitution

Derivative 1.1: FPGA-Accelerated Streamlet Encoding Hosts

Enabling Description:
Instead of general-purpose CPUs or GPUs, the host computing modules (504) within the encoding module (406) are implemented using Field-Programmable Gate Arrays (FPGAs) configured with custom hardware accelerators for video encoding. Each FPGA host is loaded with a bitstream implementing multiple parallel H.264/HEVC encoding pipelines. The master module (502) assigns raw streamlets to these FPGA hosts, which perform ultra-low-latency, multi-bitrate encoding by dedicated hardware logic gates rather than software execution on a CPU. This substitution leverages the inherent parallelism and energy efficiency of FPGAs for real-time live content processing, offering predictable encoding times independent of software scheduling overheads. The "bid" from an FPGA host (504) would be based on its available hardware pipelines and current queue depth, directly reflecting its instantaneous encoding capacity rather than general CPU metrics.

graph TD
    A[Streamlet Module 404] --> B{Master Module 502};
    B -- Assigns Raw Streamlet --> C[FPGA Host 504 (Encoder)];
    C -- Encodes Streamlet --> D[FPGA Hardware Accelerators (H.264/HEVC)];
    D -- Outputs Multi-Bitrate Streamlets --> E[Streamlet Database 408];
    C -- Bid to Master --> B;

Derivative 1.2: Quantum-Dot Photonic Network Interconnects for Distributed Encoding

Enabling Description:
The data communications network connecting the master module (502) and host computing modules (504) within the encoding cluster (406) is replaced with a high-bandwidth, low-latency quantum-dot photonic network. Instead of electrical signals over copper or standard optical fiber, data (raw streamlets, bids, encoded streamlets) is transmitted as modulated light pulses carried by quantum dots embedded in a specialized waveguide. This photonic interconnect operates at terabit-per-second speeds with minimal signal degradation and latency, significantly reducing the bottleneck for distributing raw streamlets and collecting encoded sets. This ensures that network-related computing variables in the bid (e.g., data transfer rates) are virtually constant and near-instantaneous, allowing the bidding algorithm to focus purely on computational capacity.

graph TD
    A[Streamlet Module 404] --> M(Master Module 502);
    M -- Raw Streamlet --> QNI(Quantum-Dot Photonic Network Interconnect);
    QNI -- Bid --> M;
    QNI -- Encoded Streamlets --> D[Streamlet Database 408];
    subgraph Host Computing Modules
        H1(Host 504.1) --> QNI;
        H2(Host 504.2) --> QNI;
        Hn(Host 504.N) --> QNI;
    end
    QNI --- H1;
    QNI --- H2;
    QNI --- Hn;

2. Operational Parameter Expansion

Derivative 2.1: Micro-Streamlets for Sub-Second Adaptive Switching

Enabling Description:
The predetermined length of streamlets, specified as between about 0.1 and 5 seconds in US10469554B2, is expanded to the extreme lower end, enabling "micro-streamlets" with durations in the range of 10 to 100 milliseconds. This requires the streamlet module (404) to perform high-frequency segmentation, generating hundreds of streamlets per second. The encoding module (406) must then encode these micro-streamlets and their multi-bitrate sets with extremely low latency, potentially using dedicated hardware accelerators or highly optimized GPU pipelines. The client module (114) would continuously monitor network conditions at a sub-second granularity, switching between quality levels with minimal delay, providing almost instantaneous adaptive rate adjustment to network fluctuations. This pushes the adaptive streaming to a much finer temporal resolution.

sequenceDiagram
    participant S as Streamlet Module (High Freq)
    participant E as Encoding Module (Low Latency)
    participant C as Client Module (Sub-Sec Adaptive)
    S->>E: Raw Micro-Streamlet (10-100ms)
    E->>E: Encode Multi-Bitrate Set
    E->>C: Deliver Micro-Streamlet Set
    C->>C: Monitor Network & Buffer (every ~50ms)
    alt Network Degrades
        C->>C: Trigger Downshift
        C->>E: Request Lower Bitrate Micro-Streamlet
    else Network Improves
        C->>C: Trigger Upshift
        C->>E: Request Higher Bitrate Micro-Streamlet
    end

Derivative 2.2: Extreme-Scale Distributed Encoding for Exascale Content Archiving

Enabling Description:
The system (100) is scaled to process and archive exabytes of media content, where the content files (200) can represent petabyte-scale datasets (e.g., scientific simulations, ultra-high-resolution astronomical data). The "streamlets" (303) are defined not by time duration but by logical data blocks or chunks, potentially ranging from gigabytes to terabytes, representing segments of these massive datasets. The encoding module (406) comprises thousands of geographically dispersed host computing modules (504), forming an exascale distributed computing grid. The master module (502) employs advanced bidding algorithms that consider not only local computing variables but also network topology, data gravity, and energy costs to assign encoding jobs (e.g., different compression ratios, error correction levels for long-term archival) for these massive streamlets. The encoded streamlets (304) are stored in a hyperscale, globally distributed object storage system (408).

graph TD
    P[Publisher (Exabyte Content)] --> R[Capture Module 402];
    R --> S[Streamlet Module 404 (Gigabyte/Terabyte Chunks)];
    S --> M(Master Module 502);
    M -- Job Assignment (Data Gravity Aware) --> DG[Distributed Computing Grid (Thousands of Hosts 504)];
    DG -- Encodes Multi-Version Chunks --> HSS[Hyperscale Storage System 408 (Geo-Distributed)];
    M -- Bids (Network Topology, Energy Cost) --> DG;
    C[Client Module 114 (Scientific Visualization)] -- Requests Chunks --> HSS;

3. Cross-Domain Application

Derivative 3.1: Adaptive Multi-Modality Medical Imaging Streaming

Enabling Description:
The streamlet approach is applied to real-time streaming of multi-modality medical imaging data (e.g., MRI, CT, Ultrasound, PET scans) to remote diagnostic workstations. A "media content file" (200) would be a live or archived medical scan. The streamlet module (404) segments the raw imaging data into 3D volumetric "streamlets" (303), each representing a specific anatomical slice or volume segment. The encoding module (406) generates "sets of streamlets" (306) where each streamlet in a set has a unique compression level, resolution, or diagnostic feature emphasis (ee.g., one streamlet for high-fidelity anatomical detail, another for tumor detection with false-color overlay). The master module (502) assigns encoding to hosts (504) based on their ability to perform specialized image processing tasks. The client module (114) at the diagnostic workstation adaptively requests streamlets based on available network bandwidth and the clinician's real-time diagnostic focus, ensuring critical information is prioritized and streamed with appropriate quality.

graph TD
    MIG[Medical Imaging Generator (MRI, CT)] --> CM[Capture Module 402];
    CM --> SM[Streamlet Module 404 (Volumetric Slices)];
    SM --> EM[Encoding Module 406];
    EM -- Encodes Multi-Quality/Feature Streamlets --> DB[Streamlet Database 408];
    DS[Diagnostic Workstation (Client 114)] -- Adaptive Request (Focus-Driven) --> DB;
    EM -- Distributed Encoding (Bids) --> HC[Host Computing Modules (Specialized Image Processors)];

Derivative 3.2: Real-time Multi-Fidelity Simulation Data Streaming for Autonomous Vehicles

Enabling Description:
The system is adapted for streaming real-time simulation data to autonomous vehicle (AV) control systems, particularly for scenarios involving remote operation or high-fidelity sensor data processing in cloud environments. The "media content" (200) represents a continuous stream of sensor data (Lidar point clouds, camera feeds, radar returns) and environmental model data from a simulation. The streamlet module (404) segments this data into temporal "streamlets" (303). The encoding module (406) generates "sets of streamlets" (306) where each streamlet corresponds to different fidelity levels (e.g., raw Lidar points, downsampled Lidar, semantic segmentation masks), different sensor data types, or different prediction horizons. The master module (502) assigns encoding tasks based on host capabilities for specific sensor data processing or predictive analytics. The AV's client module (114) adaptively requests streamlets, prioritizing low-latency, mission-critical data (e.g., immediate obstacle detection) over high-fidelity background mapping data, adjusting quality based on real-time vehicle state, network latency, and perceived risk.

stateDiagram
    state "Autonomous Vehicle Simulation" as AVS
    state "Streamlet Generation" as SG
    state "Multi-Fidelity Encoding" as MFE
    state "Data Distribution" as DD
    state "AV Client Adaptation" as AVCA

    AVS --> SG: Raw Sensor/Env Data
    SG --> MFE: Segmented Streamlets
    MFE --> DD: Multi-Fidelity Streamlet Sets
    DD --> AVCA: Deliver Streamlets
    AVCA --> DD: Adaptive Request (Based on Risk, Latency)

    MFE --> MFE: Distributed Encoding (Bid-based)
    AVCA --> MFE: Feedback (Quality Needs)

    note on AVCA
        Prioritizes:
        - Low-latency obstacle detection
        - High-fidelity critical path mapping
        - Low-fidelity background data
    end

Derivative 3.3: Dynamic Multi-Resolution Satellite Imagery Streaming for Disaster Response

Enabling Description:
The system is utilized for streaming dynamic, multi-resolution satellite imagery and derived geospatial intelligence to first responders during disaster relief operations. The "media content" (200) is a live feed from an Earth observation satellite or drone fleet over a disaster zone. The streamlet module (404) segments the geographical area into grid-based "streamlets" (303), each representing a specific tile of the map. The encoding module (406) creates "sets of streamlets" (306) where each streamlet in a set corresponds to a different resolution (e.g., 30cm, 1m, 10m per pixel), different spectral bands (e.g., visible, infrared), or different analytical overlays (e.g., flood extent, damaged infrastructure heatmaps). The master module (502) distributes encoding to hosts (504) capable of rapid geospatial processing. First responder client modules (114) (e.g., on ruggedized tablets) adaptively request streamlets based on their current location, mission priority, and available satellite/cellular bandwidth, ensuring that high-detail imagery is available for their immediate area of operation while maintaining situational awareness with lower resolution surrounding areas.

graph TD
    EOS[Earth Observation Satellite/Drone] --> CM[Capture Module 402];
    CM --> SM[Streamlet Module 404 (Geospatial Tiles)];
    SM --> EM[Encoding Module 406];
    EM -- Encodes Multi-Resolution/Band/Overlay Streamlets --> DB[Streamlet Database 408 (Geo-Spatial Index)];
    FRC[First Responder Client 114] -- Adaptive Request (Location/Mission/Bandwidth) --> DB;
    EM -- Distributed Encoding (Bids for Geospatial Processors) --> HC[Host Computing Modules (Geo-Processors)];

4. Integration with Emerging Tech

Derivative 4.1: AI-Driven Predictive Adaptive Bitrate Optimization

Enabling Description:
The client module (114) incorporates an AI-driven predictive model (e.g., a Recurrent Neural Network or Transformer) that continuously analyzes historical network performance, current congestion patterns, available streamlet buffer levels, and anticipated future bandwidth variations (e.g., based on time of day, location, cellular tower load). This AI module dynamically adjusts the performance factor calculations (η_current, η_up, η_down) and the pre-requesting strategy (702). Instead of purely reactive bitrate shifting, the AI model predicts optimal streamlet bitrates, pre-fetches decisions, and even requests redundant streamlets at predicted future optimal bitrates or from multiple web servers (116) or proxy caches (118) to minimize buffering and maximize perceived quality. The encoding master (502) could also use AI to predict demand for certain bitrate streamlets, prioritizing encoding jobs for popular content or predicted high-demand quality levels.

sequenceDiagram
    participant C as Client Module 114
    participant AI as AI Predictive Module
    participant N as Network Controller Module 706
    participant W as Web Server 116
    C->>AI: Send Real-time Network Metrics, Buffer State
    AI->>AI: Analyze & Predict Optimal Bitrate/Prefetch
    AI->>C: Recommend Streamlet Request Strategy (Bitrate, Quantity)
    C->>N: Request Streamlets (AI Optimized)
    N->>W: Fetch Streamlets
    W->>N: Deliver Streamlets
    N->>C: Pass to Staging/Viewer
    loop Continuous Adaptation
        C->>AI: Update Metrics
        AI->>AI: Re-evaluate & Re-predict
    end

Derivative 4.2: IoT Sensor-Augmented Content Module with Edge Encoding

Enabling Description:
The content module (112) integrates with a network of IoT sensors (e.g., environmental sensors, audience engagement sensors, camera analytics) deployed at the content capture location (e.g., a live event venue). The data from these IoT sensors is fed into the streamlet module (404) and encoding module (406). The encoding module, particularly the master module (502), uses this real-time IoT data to dynamically adjust encoding parameters. For example, if audience engagement sensors indicate high interest in a specific segment, the encoding module might prioritize higher bitrate streamlets for that segment. Furthermore, a portion of the encoding hosts (504) are deployed as edge computing devices (e.g., on-site servers, specialized hardware at the venue) to perform initial raw streamlet encoding closest to the source, reducing backhaul bandwidth requirements and latency for the first pass encoding process.

graph TD
    ES[Event Source (Camera, Mic)] --> CM[Capture Module 402];
    IOT[IoT Sensors (Audience, Environment)] --> CM;
    CM --> SM[Streamlet Module 404];
    SM -- Raw Streamlets --> EEC[Edge Encoding Cluster (Host 504.1-N)];
    EEC -- Encodes Primary Bitrates --> SD[Streamlet Database 408];
    EEC -- High-Bitrate/Archive --> CEC[Central Encoding Cluster (Host 504.X-Y)];
    CEC --> SD;
    SM -- Encoding Control (IoT-driven) --> M(Master Module 502);
    M --> EEC;
    M --> CEC;

Derivative 4.3: Blockchain-Verified Content Provenance and Rights Management for Streamlets

Enabling Description:
Each streamlet (304) and its corresponding set (306) are immutably linked to metadata (414) stored and verified on a distributed ledger (blockchain). When a streamlet is generated by the encoding module (406), its hash, time index, bitrate, and a cryptographic signature from the encoding host (504) are recorded as a transaction on a blockchain. This provides verifiable proof of content provenance, ensuring the integrity and authenticity of each streamlet from capture to delivery. The metadata module (412) interacts with the blockchain to retrieve and update content rights, licensing information, and publisher-defined usage policies for each streamlet. The client module (114) can query the blockchain to verify the legitimacy of requested streamlets and ensure compliance with digital rights management (DRM) policies before playback, enhancing trust and security in content distribution.

sequenceDiagram
    participant S as Streamlet Module 404
    participant E as Encoding Module 406
    participant B as Blockchain Ledger
    participant M as Metadata Module 412
    participant C as Client Module 114

    S->>E: Raw Streamlet
    E->>E: Encode Multi-Bitrate Set
    E->>B: Record Streamlet Hash, Metadata, Signature (Transaction)
    E->>M: Store Streamlet Info + Blockchain TxID
    M->>B: Update Content Rights/Policies
    C->>M: Request Streamlet & Metadata
    M->>C: Deliver Streamlet & TxID
    C->>B: Verify Streamlet Integrity & Rights via TxID
    alt Verification Success
        C->>C: Play Streamlet
    else Verification Failure
        C->>C: Deny Playback, Alert User
    end

5. The "Inverse" or Failure Mode

Derivative 5.1: Low-Power/Limited-Functionality Encoding for Emergency Broadcast

Enabling Description:
The encoding module (406) includes an "emergency mode" or "low-power mode" where the master module (502) automatically reduces the number of generated bitrate streams (e.g., only generating a single, lowest-quality stream), simplifies encoding algorithms (e.g., single-pass encoding instead of multi-pass), and reduces the number of active host computing modules (504). This mode is triggered during power outages, network blackouts, or critical resource scarcity. The goal is to ensure minimal content streaming (e.g., text-based emergency alerts, very low-resolution video) can persist using residual computing power and bandwidth. The client module (114) would prioritize receiving these low-power streamlets, even at the cost of quality, to maintain critical information dissemination. The streamlet duration might also increase in this mode (e.g., from 2 seconds to 10-15 seconds) to reduce encoding overhead.

stateDiagram
    state "Normal Operation" as Normal
    state "Emergency Mode (Low Power)" as Emergency
    state "Encoding Module 406" as EM
    state "Client Module 114" as CM

    [*] --> Normal
    Normal --> Emergency: Trigger (Power/Network Failure)
    Emergency --> Normal: Restore (Power/Network Restore)

    state Normal {
        EM --> EM: Multi-Bitrate Encoding
        CM --> EM: Adaptive Request
    }

    state Emergency {
        EM --> EM: Single Low-Bitrate Encoding
        EM --> EM: Reduced Host Activity
        CM --> EM: Prioritize Low-Bitrate Request
        note on EM
            Encoding simplified (e.g., single-pass)
            Fewer active hosts
            Longer streamlet durations
        end
    }

Derivative 5.2: Safe Failure Mode for Live Event Streamlet Redundancy

Enabling Description:
For critical live events, the encoding module (406) operates in a "safe failure mode" characterized by proactive streamlet redundancy. For each source streamlet (303), the master module (502) assigns encoding jobs to at least two independent host computing modules (504) for each required bitrate. These redundant hosts (504) generate identical multi-bitrate sets (306) in parallel. Upon completion, both sets are stored in geographically separated streamlet databases (408a, 408b). If one host fails during encoding, the other host's output is immediately available. If one streamlet database or web server (116) becomes unreachable, the client module (114) automatically switches to requesting streamlets from the alternative, redundant source. The bidding algorithm (502) for job assignment would prioritize hosts in different failure domains (ee.g., different racks, power grids, or data centers) to maximize resilience against single points of failure.

graph TD
    SM[Streamlet Module 404] --> M(Master Module 502);
    M -- Assign Redundant Job --> H1[Host 504.1 (Primary)];
    M -- Assign Redundant Job --> H2[Host 504.2 (Redundant)];
    H1 -- Encoded Streamlet Set --> D1[Streamlet Database 408a (Primary)];
    H2 -- Encoded Streamlet Set --> D2[Streamlet Database 408b (Redundant)];
    C[Client Module 114] -- Request Streamlet --> W1[Web Server 116a (Primary)];
    C -- Fallback Request --> W2[Web Server 116b (Redundant)];
    W1 -- Fetches from --> D1;
    W2 -- Fetches from --> D2;
    D1 -- Sync/Replication --> D2;