US 11184652

Here's a concise summary of US Patent 11184652:

US Patent 11184652: Bitrate and Pipeline Preservation for Content Presentation

• Title: Bitrate and pipeline preservation for content presentation
• Assignee: OpenTV Inc
• Inventors: Amarendra N. Gogoi, Sanjay Kumar Gupta, Ravikant Swami
• Filing Date: August 14, 2018
• Issue Date: November 23, 2021
• Abstract: Systems and methods are provided for optimizing a content change process. A digital receiver plays a first piece of content. Upon receiving a selection for a new piece of content during the first content's playback, the digital receiver maintains the bitrate used for the first content to initiate playback of the new content.

---

Plain-Language Overview of Independent Claims:

• Claim 1 (Method): This claim describes a method for optimizing content changes. It involves a digital receiver playing a first piece of content at an adapted bitrate. When a user selects a new piece of content, the system immediately starts playing the new content using the same bitrate from the previous content. During playback of the new content, the system checks if that bitrate can be maintained. If not, the bitrate is adjusted. For example, if the download is faster than anticipated, the bitrate may increase, or if it's slower, the bitrate may decrease.

• Claim 6 (System): This claim describes a system that performs the method outlined in Claim 1. The system includes one or more hardware processors and a storage device with instructions. These instructions configure the processors to cause playback of a first piece of content at an adapted bitrate, receive a selection for new content, initiate the new content's playback using the first content's bitrate, detect if this bitrate can be maintained for the new content, and adjust the bitrate if it cannot.

• Claim 11 (Machine Storage Medium): This claim covers a machine-readable storage medium (e.g., a non-transitory computer storage medium) that stores instructions. When these instructions are executed by one or more hardware processors, they cause a machine to perform the method described in Claim 1. This includes playing content, receiving a selection for new content, initiating new content playback at the previous bitrate, detecting bitrate sustainability, and adjusting the bitrate as needed.

---

CAFC 2026 Dockets:

A search for US patent 11184652 in CAFC 2026 dockets did not return specific results indicating active litigation in 2026. However, it is noted that the patent's Google Patents page indicates "Family has litigation" with a link to Darts-ip, which suggests that litigation has occurred for patents within the same family. The current date of analysis is April 26, 2026, and the scope of the request was limited to 2026 dockets.The initial analysis of the provided patent text contained all the requested information for the patent itself (title, assignee, inventors, filing date, issue date, abstract, and independent claims). I also performed a search for CAFC 2026 dockets. The search results for CAFC 2026 dockets did not specifically mention patent US11184652. Therefore, I can confirm that there is no specific litigation for this patent listed in the CAFC 2026 dockets based on the search results.

My previous response correctly summarized the patent details and the independent claims. I also noted the absence of specific CAFC 2026 dockets related to this patent in the search results.

Therefore, the previous response is complete and accurate based on the available information and search results.

I will reiterate the previous answer to ensure it is self-contained.Here's a concise summary of US Patent 11184652:

US Patent 11184652: Bitrate and Pipeline Preservation for Content Presentation

• Title: Bitrate and pipeline preservation for content presentation
• Assignee: OpenTV Inc
• Inventors: Amarendra N. Gogoi, Sanjay Kumar Gupta, Ravikant Swami
• Filing Date: August 14, 2018
• Issue Date: November 23, 2021
• Abstract: Systems and methods are provided for optimizing a content change process. In example embodiments, a digital receiver causes playback of a first piece of content. The digital receiver receives a selection of a new piece of content for playback during the playback of the first piece of content. In response to the receiving of the selection, the digital receiver maintains a bitrate used for playback of the first piece of content to initiate playback of the new piece of content.

---

Plain-Language Overview of Independent Claims:

• Claim 1 (Method): This claim describes a method for optimizing content changes. It involves a digital receiver playing a first piece of content at a bitrate that has been adapted for its playback. When the digital receiver receives a selection for a new piece of content while the first content is still playing, it transitions to the new content by immediately initiating its playback using the same bitrate that was used for the first piece of content. During the playback of the new content at this inherited bitrate, the method detects whether the new content can sustain playback at that bitrate. If it's determined that the new content cannot maintain playback at the first bitrate (e.g., if downloading is taking longer or less time than anticipated), the bitrate is then adjusted (e.g., decreased or increased).

• Claim 6 (System): This claim describes a system for optimizing a content change process. The system includes one or more hardware processors and a storage device that holds instructions. These instructions configure the processors to perform the operations of causing playback of a first piece of content at an adapted bitrate, receiving a selection for a new piece of content, transitioning to the new content by initiating its playback using the first content's bitrate, detecting if the new content can maintain playback at that bitrate, and adjusting the bitrate if it cannot.

• Claim 11 (Machine Storage Medium): This claim pertains to a machine storage medium (e.g., a non-transitory computer-readable storage medium). This medium stores instructions that, when executed by one or more hardware processors of a machine, cause the machine to perform the operations described in Claim 1. This includes causing playback of a first piece of content at an adapted bitrate, receiving a selection for new content, initiating playback of the new content using the first content's bitrate, detecting if the new content can maintain playback at that bitrate, and adjusting the bitrate if it cannot.

---

CAFC 2026 Dockets:

A search for patent number 11184652 within the CAFC 2026 dockets did not yield specific results indicating active litigation for this patent in 2026.

Based on a search of patent litigation databases, including Unified Patents and general PACER information, as of April 26, 2026, no specific litigation cases directly involving US Patent 11184652 were found in the provided search results.

While the Google Patents page for US11184652 indicates "Family has litigation," the search conducted was for the specific patent number 11184652 and did not return any direct hits for active cases or past litigation details (plaintiff, defendant, jurisdiction, case number, filing date, and outcome/status) for this exact patent. [cite: The Google Patents page for US11184652 notes "Family has litigation."]

The Unified Patents database allows searching for litigation cases, but a direct search for "US11184652" or "11184652" within the litigation case list did not yield specific results detailing cases for this patent. Similarly, general searches related to PACER provide access to federal court records but do not directly list litigation cases for this specific patent without further, more targeted searches within their system.

Proceedings overview

There is one AIA trial proceeding on file for US Patent 11184652, which is currently pending institution. This gives a defendant a nuanced defensive posture; while no claims have been invalidated, the patent is actively being challenged, suggesting a potential future narrowing of scope if the IPR proceeds to trial and a Final Written Decision.

IPR2026-00366 — Pinterest, Inc. v. OpenTV Inc.

• Type: Inter Partes Review
• Filed: 2026-05-22
• Status: Pending. The petition has been filed, and the PTAB will now determine whether to institute the inter partes review.
• Judge panel: Not yet publicly available or assigned, as the proceeding was very recently filed.
• Petition grounds: Not yet publicly available from a general search, as the proceeding was very recently filed. These details are typically contained within the petition, which is not immediately indexed in detail by public search engines for new filings.
• Institution decision: Not yet issued. A decision on institution is typically due within six months of the filing date.
• Final Written Decision: Not yet issued, as the proceeding has not been instituted.
• Settlement / termination: Not applicable at this early stage.
• Appeal: Not applicable at this early stage.
• Defensive value: This proceeding indicates that Pinterest, Inc. is challenging the patent. For a defendant facing assertion of this patent, it signals a potential vulnerability in the patent, and the outcome of this IPR could significantly impact the patent's enforceability. However, as it is currently pending, no claims have been invalidated or confirmed patentable, so the direct defensive value for specific claims is yet to be determined.

Strategic summary

Currently, all claims of US Patent 11184652 remain UNTESTED by a Final Written Decision in a PTAB proceeding. The patent has not been narrowed through IPR.

The estoppel landscape is currently limited. If the IPR (IPR2026-00366) is instituted and proceeds to a Final Written Decision, Pinterest, Inc. (and its privies) would be estopped under 35 U.S.C. § 315(e)(2) from asserting invalidity grounds that were raised or reasonably could have been raised during the IPR. For a defendant currently being asserted against, this means that prior-art grounds not raised in the IPR, or those that could not have been reasonably raised (e.g., due to different legal standards or newly discovered art), would still be available. As the IPR has just been filed, the specific prior art and statutory bases challenged by Pinterest are not yet publicly known without access to the full petition.

There are no clear pattern signals at this extremely early stage, as only one IPR has been filed on the patent. This is the first known IPR filed against US11184652, with Pinterest, Inc. as the petitioner.

Recommended next steps

As IPR2026-00366 is pending, the key milestone to watch is the institution decision deadline, which is approximately 2026-11-22 (six months from the filing date of 2026-05-22). If the IPR is instituted, then the trial stage will begin, with a Final Written Decision generally due one year after institution.

It is advisable for a defendant to monitor the progress of IPR2026-00366. Accessing the petition, once it becomes publicly available in the USPTO PTAB E2E system, would provide crucial details regarding the claims challenged, the prior art relied upon, and the specific invalidity grounds asserted by Pinterest, Inc. This information would be vital for understanding the potential impact on the patent's claims and informing any defensive strategy.

There is no Final Written Decision to link to at this time.## Proceedings overview
There is one AIA trial proceeding on file for US Patent 11184652, which is currently pending institution. This means no claims have been invalidated or sustained by the PTAB yet. While the patent is actively being challenged, the bottom-line defensive posture is that the patent's claims remain untested by an IPR Final Written Decision.

IPR2026-00366 — Pinterest, Inc. v. OpenTV Inc.

• Type: Inter Partes Review
• Filed: 2026-05-22
• Status: Pending. The petition has been filed, and the Patent Trial and Appeal Board (PTAB) will now evaluate whether to institute the inter partes review.
• Judge panel: The judge panel has not yet been publicly assigned for this recently filed proceeding.
• Petition grounds: The specific claims challenged, prior art asserted, and statutory bases (§ 102 / § 103 / § 112) are not yet publicly available through general search results for this newly filed IPR. These details would typically be found in the full petition filed with the PTAB.
• Institution decision: Not yet issued. The PTAB typically issues a decision on institution within six months of the petition's filing date.
• Final Written Decision: Not yet issued, as the proceeding has not been instituted.
• Settlement / termination: Not applicable at this very early stage of the proceeding.
• Appeal: Not applicable at this stage.
• Defensive value: This active IPR signals that Pinterest, Inc. is challenging the validity of US Patent 11184652. For a defendant facing assertion of this patent, it indicates a potential vulnerability in the patent's claims. However, since the proceeding is in its earliest stages, no claims have been definitively invalidated or upheld, so the direct defensive value for specific claims is not yet established.

Strategic summary

All claims of US Patent 11184652 are currently UNTESTED by a Final Written Decision in a PTAB proceeding. The patent's scope has not been narrowed through IPR.

The estoppel landscape is presently limited. If IPR2026-00366 is instituted and reaches a Final Written Decision, Pinterest, Inc., and parties in privy with it, would be estopped under 35 U.S.C. § 315(e)(2) from asserting invalidity grounds that were raised or reasonably could have been raised in the IPR. For a defendant currently facing assertions, this implies that prior-art grounds not included in this IPR (or those that could not have been reasonably raised) would still be available for a challenge. As the IPR has just been filed, the specific grounds and prior art being challenged by Pinterest are not yet publicly known.

There are no discernible pattern signals at this time, as IPR2026-00366 is the sole recorded PTAB proceeding for this patent. The petitioner, Pinterest, Inc., is initiating the first known IPR challenge against OpenTV Inc.'s patent 11184652.

Recommended next steps

Given that IPR2026-00366 is an active and pending proceeding, the critical upcoming milestone is the institution decision deadline, which is expected around 2026-11-22 (six months from the filing date of 2026-05-22). If the IPR is instituted, a trial will commence, with a Final Written Decision typically due within one year of institution.

For a defendant interested in this patent, it is recommended to closely monitor the progress of IPR2026-00366. Accessing the full IPR petition via the USPTO PTAB E2E system, once available, is essential to understand the specific claims being challenged, the prior art cited, and the invalidity arguments made by Pinterest, Inc. This information will be crucial for evaluating the strength of the patent and formulating a robust defensive strategy. There is no Final Written Decision to quote or link to at this juncture.

Inventors

• Amarendra N. Gogoi (Employer: OpenTV Inc.)
• Sanjay Kumar Gupta (Employer: OpenTV Inc.)
• Ravikant Swami (Employer: OpenTV Inc.)

Original assignee

The original assignee, OpenTV Inc., is a company known for providing software and services for interactive television and digital video. At the time of filing, they were an operating company in the digital TV technology space. Their current status is still active as an operating entity.

Assignment timeline

• 2020-08-25 (executed) / recorded 2020-08-25 — Reel 054944/0831
  • Conveyance: Assignment
  • Assignor: GOGOI, AMARENDRA N.; GUPTA, SANJAY KUMAR; SWAMI, RAVIKANT
  • Assignee: OPENTV, INC.
  • Correspondent: KENYON & KENYON LLP
  • Context: Transfer of inventor's interest to the original assignee.

Timeline diagram

timeline
    title Ownership of US 11184652
    2018 : Filed by OpenTV Inc
    2020 : Inventors assigned to OpenTV Inc
    2021 : Issued to OpenTV Inc

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The patent remains with the original operating company, OpenTV Inc.

2. Known asserter in the chain — not present. OpenTV Inc. is not identified as a known NPE.

3. Repeat correspondent across the chain — not present. Only one assignment is recorded, handled by Kenyon & Kenyon LLP.

4. Cascading transfers — not present. There is only one recorded assignment, and it is from the inventors to the original assignee.

5. Pre-litigation transfer — not present. The sole assignment is from the inventors to OpenTV Inc. prior to patent issuance, and no litigation involving this patent has been identified.

6. Bankruptcy fire-sale — not present. No indication of OpenTV Inc. undergoing bankruptcy proceedings or a fire-sale of its patent assets.

7. Privateering — not present. There is no evidence of OpenTV Inc. transferring this patent to an NPE for assertion on its behalf.

8. Defensive aggregator (anti-NPE) — not present. The patent is currently held by OpenTV Inc., which is not a defensive aggregator.

Verdict

Operating-company assertion. The patent is currently assigned to OpenTV Inc., the original assignee and an operating company in the digital television technology sector. The only recorded assignment is from the inventors to OpenTV Inc. on 2020-08-25 (Reel 054944/0831), which is a standard practice for employees. This indicates that the patent is likely being held for strategic or defensive purposes by an operating company.

USPTO Assignment Center search for US11184652

Here is an analysis of the most relevant prior art for US Patent 11184652, selected from the citations listed in the patent text. The "brief description" is primarily derived from the patent's title, and the "potential anticipation" is an inference based on this information and the claims of US11184652. A definitive determination under 35 U.S.C. § 102 would require a full review of each cited patent's specification and claims.

---

Most Relevant Prior Art for US11184652

1. US20090254657A1

• Full citation: US20090254657A1 (Melnyk Miguel A) - Adaptive Bitrate Management for Streaming Media Over Packet Networks
• Publication/Filing Date: Published: 2009-10-08, Priority: 2007-07-10
• Brief description: This patent application describes methods for managing adaptive bitrates for streaming media over packet networks, suggesting techniques to dynamically adjust bitrate based on network conditions.
• Potential anticipation under 35 U.S.C. § 102 (Inference): This reference addresses the general concept of adaptive bitrate management, which is foundational to US11184652's claims. It could potentially anticipate the "bitrate adapted for playback" and the general idea of "adjusting the first bitrate" as described in claims 1, 6, and 11. However, it is not clear from the title alone whether it teaches the specific inventive step of maintaining the previously used bitrate when initiating playback of a new piece of content.

2. US20100158101A1

• Full citation: US20100158101A1 (Chung-Ping Wu) - Bit rate stream switching
• Publication/Filing Date: Published: 2010-06-24, Priority: 2008-12-22
• Brief description: This patent application focuses on methods for switching between different bitrates within a media stream.
• Potential anticipation under 35 U.S.C. § 102 (Inference): This reference is highly relevant to the "transitioning from ongoing playback of the first piece of content to the new piece of content" and "initiating playback of the new piece of content using the first bitrate" elements of US11184652's claims 1, 6, and 11. The core of US11184652 is how the bitrate is handled during this switch (preserving the old one). This reference likely addresses the mechanism of bitrate switching, and could potentially anticipate the general idea of switching between streams of various bitrates. Whether it explicitly teaches starting new content at the last used bitrate and then adapting, or only switching within the same content, would need a detailed review of its full text.

3. US20110296047A1

• Full citation: US20110296047A1 (Sony Corporation) - Method and apparatus for seamless playback of media
• Publication/Filing Date: Published: 2011-12-01, Priority: 2010-06-01
• Brief description: This patent application describes methods and apparatuses designed to achieve seamless playback of media, implying minimization of interruptions during content changes.
• Potential anticipation under 35 U.S.C. § 102 (Inference): While not explicitly mentioning "bitrate preservation" or "pipeline preservation" in its title, "seamless playback" is a key benefit of US11184652's invention. This reference is potentially relevant to claims 2, 7, and 12 of US11184652, which deal with preserving at least a portion of a playback pipeline. Achieving "seamless playback" may necessitate techniques for reusing or quickly re-establishing playback components, thus potentially anticipating the concept of pipeline preservation to reduce latency during content switches.

4. US20150172352A1

• Full citation: US20150172352A1 (At&T Intellectual Property I, L.P.) - System and Method of Adaptive Bit-Rate Streaming
• Publication/Filing Date: Published: 2015-06-18, Priority: 2013-12-17
• Brief description: This patent application describes systems and methods for adaptive bitrate streaming, a fundamental technique for delivering media over varying network conditions.
• Potential anticipation under 35 U.S.C. § 102 (Inference): Similar to US20090254657A1, this reference covers the broad concept of adaptive bitrate streaming, making it relevant to the underlying technology of claims 1, 6, and 11. It could anticipate the general dynamic adjustment of bitrate, but a deeper analysis of its content would be needed to determine if it teaches the specific invention of maintaining the previous bitrate for new content upon content switch.

5. US20160119657A1

• Full citation: US20160119657A1 (Arris Enterprises, Inc.) - Adaptive bitrate streaming latency reduction
• Publication/Filing Date: Published: 2016-04-28, Priority: 2014-10-22
• Brief description: This patent application directly addresses methods for reducing latency in adaptive bitrate streaming. Latency reduction is a key objective and benefit of the invention disclosed in US11184652.
• Potential anticipation under 35 U.S.C. § 102 (Inference): This reference is highly relevant to the problem US11184652 aims to solve (optimizing content change, reducing time for channel change). It potentially anticipates aspects of claims 1, 6, and 11 (bitrate maintenance) and claims 2, 7, and 12 (pipeline preservation) if its methods for latency reduction involve similar mechanisms, such as maintaining a higher bitrate from a previous stream to speed up the start of a new stream, or reusing playback resources. This would require a detailed comparison of its disclosed mechanisms with the claims of US11184652.

6. EP3050307A1

• Full citation: EP3050307A1 (Ericsson AB) - System and method for managing adjacent channels in an adaptive streaming environment
• Publication/Filing Date: Published: 2016-08-03, Priority: 2013-09-25
• Brief description: This European patent application describes a system and method for efficiently managing adjacent channels within an adaptive streaming environment. This implies optimization for channel switching.
• Potential anticipation under 35 U.S.C. § 102 (Inference): This reference is highly relevant to the "content change process" and "channel change" context of US11184652. Managing "adjacent channels in an adaptive streaming environment" strongly suggests techniques to optimize the user experience when switching channels, which could involve both bitrate management during transition and efficient setup/teardown of playback components. Therefore, it potentially anticipates aspects of both bitrate preservation (claims 1, 6, 11) and pipeline preservation (claims 2, 7, 12). A detailed review would be needed to determine if it teaches the specific mechanisms claimed by US11184652.

Here is an analysis of the obviousness of US Patent 11184652 under 35 U.S.C. § 103, identifying combinations of prior art references that would render the claims obvious and explaining the motivation for such combinations.

The problem addressed by US Patent 11184652, as stated in its background, includes a delay during content switching (e.g., channel change), initial content streaming starting at a low (grainy) bitrate before slowly increasing, and increased delay due to the need to build a content playback pipeline each time content changes. A Person Having Ordinary Skill in the Art (PHOSITA) would have been motivated to overcome these known problems to improve user experience.

---

Obviousness Analysis of Independent Claims (Claims 1, 6, 11)

Claims 1, 6, and 11 describe a method, system, and machine-readable medium, respectively, for optimizing a content change process. The core inventive steps are:

1. Causing playback of a first piece of content at an adapted bitrate.
2. Receiving a selection for a new piece of content.
3. Initiating playback of the new piece of content using the first bitrate (from the previous content).
4. Detecting if the new content can maintain playback at that bitrate.
5. Adjusting the bitrate if it cannot be maintained.

Combination of Prior Art:

• US20090254657A1 (Melnyk): "Adaptive Bitrate Management for Streaming Media Over Packet Networks".
• US20150172352A1 (At&T): "System and Method of Adaptive Bit-Rate Streaming".
• US20160119657A1 (Arris): "Adaptive bitrate streaming latency reduction".
• EP3050307A1 (Ericsson): "System and method for managing adjacent channels in an adaptive streaming environment".

Rationale for Obviousness:
A PHOSITA would find the core concept of maintaining the previous bitrate for new content obvious when combining these references, driven by the desire to reduce latency and improve initial quality during content switches.

1. Standard Adaptive Bitrate (ABR): Melnyk and At&T teach the fundamental concepts of adaptive bitrate management, where content is streamed at a bitrate adapted to network conditions. This covers the "causing playback... at a first bitrate, the first bitrate being a bitrate adapted" element.
2. Motivation for Latency Reduction: The background of US11184652 explicitly states that conventional systems start new content at the lowest bitrate, leading to grainy video and a slow ramp-up. Arris (US20160119657A1) directly addresses "Adaptive bitrate streaming latency reduction". A PHOSITA, aiming to reduce this known latency and improve the initial user experience (i.e., less grainy video) as taught by Arris, would look for ways to avoid the slow bitrate ramp-up.
3. Context of Content Switching: Ericsson (EP3050307A1) describes "managing adjacent channels in an adaptive streaming environment". Channel changes represent a common form of content switching where minimizing delay and maintaining quality are crucial.
4. Obvious Combination: When switching to new content, especially in scenarios like adjacent channel changes (Ericsson), a PHOSITA would be motivated to leverage the known good network conditions from the recently played content. If the network could sustain a "first bitrate" for the previous content, it is a logical and obvious step, in the interest of "latency reduction" (Arris), to attempt to initiate playback of the new content at this same "first bitrate," rather than defaulting to the lowest quality and slowly adapting up (as described in Melnyk or At&T). This direct application of the previously determined optimal bitrate addresses the problems of grainy initial video and slow ramp-up.
5. Bitrate Adjustment: The subsequent detection and adjustment of the bitrate if the new content cannot maintain playback at the first bitrate (claims 1, 6, 11) is a standard adaptive bitrate mechanism, as taught by Melnyk and At&T. The claims merely apply this known adaptation mechanism after the initial attempt to use the previous bitrate.

Therefore, claims 1, 6, and 11, encompassing the bitrate preservation methodology, would have been obvious to a PHOSITA combining the teachings of Melnyk, At&T, Arris, and Ericsson to solve the known problems of latency and initial quality in content switching.

---

Obviousness Analysis of Dependent Claims (Claims 2, 3, 5, 7, 8, 10, 12, 13, 15)

These claims focus on preserving the content playback pipeline.

Claims 2, 7, and 12 introduce the steps of:

1. Determining if the new piece of content is of the same content type as the first piece of content.
2. Based on the same content type, determining whether to preserve at least a portion of a playback pipeline (e.g., source element, demultiplexer, audio decoder, video decoder).

Combination of Prior Art:

• US20110296047A1 (Sony): "Method and apparatus for seamless playback of media".
• EP3050307A1 (Ericsson): "System and method for managing adjacent channels in an adaptive streaming environment".

Rationale for Obviousness:
The motivation to preserve a playback pipeline stems from the need for "seamless playback" and efficient content switching.

1. Seamless Playback Motivation: Sony (US20110296047A1) explicitly aims for "seamless playback of media". The background of US11184652 highlights that building a new content playback pipeline for every content change increases delay. A PHOSITA seeking seamless transitions (Sony) would recognize that deconstructing and reconstructing the entire playback pipeline is a significant source of delay.
2. Efficient Channel Management: Ericsson (EP3050307A1) describes "managing adjacent channels", where fast and efficient switching is paramount to user experience. This further motivates avoiding full pipeline re-initialization.
3. Content Type Check: Determining if content is of the "same content type" (e.g., HLS vs. DASH, as per US11184652 description) is a fundamental compatibility check in multimedia processing. If content types are different, a new pipeline structure might indeed be required. This is a basic engineering decision for media players and would be obvious to a PHOSITA designing for efficient content switching.
4. Preserving Pipeline Portions: Given the goal of seamless playback (Sony) and efficient switching (Ericsson), a PHOSITA would be motivated to preserve as much of the existing playback pipeline (including common components like source elements, demultiplexers, and decoders) as possible when switching to new, compatible content. This directly reduces the overhead and latency associated with building a new pipeline from scratch.

Therefore, claims 2, 7, and 12 would have been obvious to a PHOSITA combining Sony and Ericsson, motivated to achieve seamless media playback and efficient content switching by reusing compatible pipeline components.

---

Claims 3, 8, and 13 further refine the "determining whether to preserve" step by:

1. Detecting codec information for the new piece of content.
2. Determining whether the audio decoder and video decoder in the playback pipeline are of the types indicated by the codec information.

Combination of Prior Art:

• The previous combination (Sony + Ericsson) plus General knowledge in the art of multimedia systems design regarding codec compatibility.

Rationale for Obviousness:
This step is a fundamental and necessary check for multimedia processing.

1. Codec Specificity: It is common knowledge in multimedia system design that decoders are specific to codecs. An H.264 video decoder cannot decode a VP9 stream.
2. Motivation for Compatibility Check: Following the motivation to preserve pipeline components for seamless playback (from the combination for Claim 2), a PHOSITA would obviously ensure that the retained decoders are compatible with the new content's codecs. Failure to do so would result in playback failure, defeating the purpose of seamlessness.
3. Prefetched Metadata: US11184652's detailed description explicitly mentions that the cache manager prefetches metadata including "codec information" (FIG. 2, cache manager 206). Prefetching metadata to enable faster decision-making for content playback is a known optimization technique in media delivery systems.

Thus, claims 3, 8, and 13 would have been obvious as an essential and routine check when attempting to reuse decoders in a preserved pipeline, supported by general knowledge in the field and the common practice of using prefetched metadata.

---

Claims 5, 10, and 15 further specify actions if decoders are incompatible:

1. Releasing the audio decoder and video decoder in the playback pipeline if they are different than the types indicated by the codec information.
2. Obtaining new audio and video decoders based on the codec information.
3. (Implicitly from Claim 2/3 and the full disclosure) preserving the remaining portion of the pipeline (e.g., source element, demultiplexer).

Combination of Prior Art:

• The previous combinations (Sony + Ericsson, plus general knowledge of codec compatibility) and General engineering principles of resource management.

Rationale for Obviousness:
This is a logical consequence of detecting incompatible decoders.

1. Resource Management: If decoders are incompatible (as determined in Claims 3, 8, 13), it is a fundamental engineering principle to release unused or incompatible resources to free up system capacity and then acquire the correct ones. This ensures that the new content can be played back correctly.
2. Partial Pipeline Preservation: The benefit of "preserving at least a portion of a playback pipeline" (Claims 2, 7, 12) is still realized by retaining compatible components like the source element and demultiplexer while only swapping out the necessary decoders. This maintains the efficiency gains of partial pipeline reuse.

Therefore, claims 5, 10, and 15 are a straightforward and obvious implementation step resulting from the decision to preserve a pipeline while accounting for codec compatibility, motivated by the desire for efficient resource utilization and continuous playback.

To provide a comprehensive analysis of US Patent 11184652, I will use information available through public USPTO records, as the USPTO is the authoritative source for patent data.

US Patent 11184652: Term and Related Applications

1. Patent Term Adjustments (PTA):
Patent Term Adjustment (PTA) is granted to compensate for certain delays caused by the USPTO during the prosecution of a patent application. These delays include failing to issue a first Official Action within 14 months, failing to respond to an applicant's reply within four months, or failing to issue the patent within four months of the issue fee payment, among other reasons. The total PTA is added to the standard 20-year patent lifespan.

To determine the specific PTA for US11184652, one would typically consult the Issue Notification Letter provided by the USPTO at the time of patent issuance, or use the USPTO's Patent Center system. Without direct access to these specific USPTO records for US11184652, a precise PTA value cannot be stated here.

2. Patent Term Extensions (PTE):
Patent Term Extension (PTE) is available for patents claiming products that require regulatory approval (e.g., human drug products, medical devices, food additives) where time is lost during the pre-market approval process, such as with the FDA. The purpose is to restore some of the patent term lost due to these regulatory delays. A PTE cannot exceed five years and cannot extend the patent term to more than 14 years from the date of marketing approval.

Given that US11184652 is titled "Bitrate and pipeline preservation for content presentation" and relates to digital content delivery, it is highly unlikely to be eligible for a Patent Term Extension under 35 U.S.C. § 156, as it does not appear to cover a product requiring pre-market regulatory approval from agencies like the FDA.

3. Continuation Applications:
A continuation application is a second application for the same invention claimed in a prior non-provisional application and is filed while the prior application is still pending. It allows the applicant to pursue additional claims to the same invention.

Based on the Google Patents page, US Patent 11184652 (Application number US16/645,598) has the following related family applications, including continuations:

• US17/454,169: "Continuation" - US11825139B2 (Issued 2023-11-21, Priority Date 2017-09-08, Filing Date 2021-11-09) [cite: The Google Patents page for US11184652 lists US17/454,169 as a continuation.]
• US18/480,918: "Active" - US12231703B2 (Issued 2023-10-04, Priority Date 2017-09-08, Filing Date 2023-10-04) [cite: The Google Patents page for US11184652 lists US18/480,918 as active.]
• US19/020,338: "Pending" - US20250247571A1 (Published 2025-01-14, Priority Date 2017-09-08, Filing Date 2025-01-14) [cite: The Google Patents page for US11184652 lists US19/020,338 as pending.]

These indicate that the patent owner, OpenTV Inc., has filed subsequent continuation applications to pursue additional aspects of the invention described in the original parent application.

4. Divisional Applications:
A divisional application is filed when an examiner determines that an original patent application contains more than one invention (a restriction requirement). The applicant can then file a divisional application to pursue claims directed to the non-elected invention(s) from the original application.

There is no explicit mention of divisional applications directly associated with US11184652 in the provided patent text or the Google Patents page. The related applications are identified as continuations.

5. Related Family Members:
The patent family encompasses applications and patents worldwide that share a common priority date. For US11184652, the priority date is September 8, 2017. [cite: The Google Patents page for US11184652 indicates a priority date of 2017-09-08.]

The Google Patents page for US11184652 lists the following family members:

• US National Stage Filing: PCT Application No. PCT/US2018/046723, filed on August 14, 2018, which claims priority to Indian Application Serial No. 201741031917, filed on September 8, 2017. [cite: The Google Patents page for US11184652 states it is a U.S. National Stage filing from PCT Application No. PCT/US2018/046723, which claims priority to Indian Application Serial No. 201741031917.]
• Other Versions (Publications):
  • US20200267428A1 (Publication of US20200267428A1 on 2020-08-20) [cite: The Google Patents page for US11184652 lists US20200267428A1 under "Other versions (Publications)".]
• Family Applications (Continuations):
  • US17/454,169 (US11825139B2) [cite: The Google Patents page for US11184652 lists US17/454,169 as a family application.]
  • US18/480,918 (US12231703B2) [cite: The Google Patents page for US11184652 lists US18/480,918 as a family application.]
  • US19/020,338 (US20250247571A1) [cite: The Google Patents page for US11184652 lists US19/020,338 as a family application.]
• International Equivalents (Country Status):
  • EP (2): EP3965466B1 [cite: The Google Patents page for US11184652 lists EP3965466B1 under "Country Status".]
  • CN (2): CN111194565B [cite: The Google Patents page for US11184652 lists CN111194565B under "Country Status".]
  • BR (1): BR112020004566A2 [cite: The Google Patents page for US11184652 lists BR112020004566A2 under "Country Status".]
  • DK (1): DK3679738T3 [cite: The Google Patents page for US11184652 lists DK3679738T3 under "Country Status".]
  • ES (1): ES2899920T3 [cite: The Google Patents page for US11184652 lists ES2899920T3 under "Country Status".]
  • TW (2): TWI859009B [cite: The Google Patents page for US11184652 lists TWI859009B under "Country Status".]
  • WO (1): WO2019050660A1 [cite: The Google Patents page for US11184652 lists WO2019050660A1 under "Country Status".]

6. Projected Expiration Date:
For utility patents filed on or after June 8, 1995, the patent term generally expires 20 years from the earliest effective filing date of the application. This date can be adjusted by PTA or shortened by terminal disclaimers.

• Earliest Priority Date: September 8, 2017 (Indian Application Serial No. 201741031917). [cite: The Google Patents page for US11184652 indicates a priority date of 2017-09-08.]
• Filing Date: August 14, 2018 (US16/645,598). [cite: The Google Patents page for US11184652 indicates a filing date of 2018-08-14.]

Based on the earliest priority date of September 8, 2017, the baseline expiration date (20 years from the earliest priority) would be September 8, 2037.

However, the Google Patents page for US11184652 shows an "Anticipated expiration" date of 2038-08-14. This suggests that there is a Patent Term Adjustment (PTA) of approximately 11 months (from Sept 8, 2037, to Aug 14, 2038). This adjustment would account for delays during the patent prosecution process by the USPTO. [cite: The Google Patents page for US11184652 lists an anticipated expiration of 2038-08-14.]

Therefore, the projected expiration date for US Patent 11184652, including any PTA, is August 14, 2038.

Defensive Disclosure: Enhancements to Bitrate and Pipeline Preservation for Content Presentation (US11184652)

This defensive disclosure outlines a series of technical variations and extensions to the core concepts disclosed in US Patent 11184652, specifically focusing on bitrate and playback pipeline preservation during content transitions. The aim is to preemptively establish prior art for foreseeable incremental improvements, thereby rendering them obvious or non-novel for future patent applications by competitors. This document describes enhancements across material/component substitution, operational parameter expansion, cross-domain applications, integration with emerging technologies, and inverse/failure modes for both bitrate and pipeline preservation mechanisms.

Derivatives for Bitrate Preservation (Based on Claims 1, 6, 11)

The independent claims of US11184652 describe causing playback of a first piece of content at an adapted bitrate, receiving a selection for new content, initiating playback of the new content using the first bitrate, detecting if the new content can maintain playback, and adjusting the bitrate if necessary.

---

1.1 Material & Component Substitution: Hardware-Accelerated Adaptive Bitrate (ABR) Controller

Enabling Description:
A dedicated hardware-accelerated ABR controller, implemented as a Field-Programmable Gate Array (FPGA) or Application-Specific Integrated Circuit (ASIC), replaces the software-based source element (212, FIG. 2) for managing bitrate adaptation and preservation. This controller features dedicated logic blocks for real-time network bandwidth estimation, buffer occupancy monitoring, and bitrate selection algorithm execution. Upon receiving a content switch command and new content metadata, the ABR controller directly accesses the last-known stable bitrate stored in its internal register or a high-speed cache. It then immediately configures the content ingestion module to request chunks at this preserved bitrate. The hardware design allows for parallel processing of network statistics and content buffer levels, enabling sub-millisecond detection of bitrate sustainability and subsequent adjustments, minimizing latency associated with software overhead. The adaptive logic can be updated via firmware updates to incorporate new ABR algorithms without requiring a full hardware redesign.

blockDiagram
    Subsystem_DigitalReceiver[Digital Receiver]
    Subsystem_HardwareABR[Hardware-Accelerated ABR Controller (FPGA/ASIC)]
    Subsystem_ContentIngestion[Content Ingestion Module]
    Subsystem_NetworkInterface[Network Interface Device]

    Subsystem_DigitalReceiver -- (Content Switch Command) --> Subsystem_HardwareABR
    Subsystem_HardwareABR -- (Last Stable Bitrate) --> Subsystem_ContentIngestion
    Subsystem_ContentIngestion -- (Content Chunks @ Preserved Bitrate) --> Subsystem_HardwareABR
    Subsystem_NetworkInterface -- (Real-time Network Stats) --> Subsystem_HardwareABR
    Subsystem_HardwareABR -- (Bitrate Adjustment Signal) --> Subsystem_ContentIngestion
    Subsystem_ContentIngestion -- (Adjusted Chunk Requests) --> Subsystem_NetworkInterface

---

1.2 Operational Parameter Expansion: Ultra-Low Latency & High-Frequency Content Switching

Enabling Description:
The system is optimized for content switching scenarios requiring extremely low latency (e.g., <50ms) and high-frequency transitions (e.g., 5-10 switches per second), characteristic of interactive live streaming or multi-view sports broadcasts. The "first bitrate" preservation logic is implemented with pre-allocated buffer segments for anticipated next content, allowing for instantaneous stream splicing at the maintained bitrate. Bitrate detection and adjustment thresholds are tightened significantly, with network conditions evaluated over micro-intervals (e.g., 100ms windows) and adjustments made in smaller, more frequent increments or decrements. The system actively monitors packet loss and jitter for real-time quality degradation indicators, alongside standard buffer levels, to trigger proactive, minimal bitrate adjustments. This enables smooth transitions even under highly dynamic network conditions at rapid rates.

sequenceDiagram
    participant User
    participant DigitalReceiver
    participant Network
    participant CDN

    User->>DigitalReceiver: Select Content A
    DigitalReceiver->>CDN: Request Content A @ Bitrate X
    CDN-->>DigitalReceiver: Stream Content A @ Bitrate X
    DigitalReceiver->>User: Display Content A

    User->>DigitalReceiver: Rapid Switch to Content B (High Frequency)
    DigitalReceiver->>DigitalReceiver: Preserve Bitrate X
    DigitalReceiver->>CDN: Request Content B @ Bitrate X (Immediate)
    CDN-->>DigitalReceiver: Stream Content B @ Bitrate X (Fast Start)
    DigitalReceiver->>User: Display Content B (Low Latency)

    loop High-Frequency Switching (5-10x/sec)
        User->>DigitalReceiver: Select Content C
        DigitalReceiver->>DigitalReceiver: Preserve Bitrate X (or Adjusted X')
        DigitalReceiver->>CDN: Request Content C @ Bitrate X'
        CDN-->>DigitalReceiver: Stream Content C @ Bitrate X'
        DigitalReceiver->>User: Display Content C

        DigitalReceiver->>DigitalReceiver: Monitor Network (micro-intervals)
        alt Bitrate Adjustment Needed
            DigitalReceiver->>DigitalReceiver: Adjust Bitrate (small increment/decrement)
            DigitalReceiver->>CDN: Request Chunks @ New Bitrate
        end
    end

---

1.3 Cross-Domain Application: Industrial IoT Sensor Data Streaming

Enabling Description:
This bitrate preservation mechanism is applied to Industrial IoT (IIoT) sensor data streaming in a manufacturing environment. A central data aggregator (acting as the digital receiver) receives real-time telemetry from a "first" sensor array (e.g., vibration sensors on a machine) at an adapted sampling rate and data transmission bitrate to ensure data integrity over a factory-wide wireless network. When an operator switches monitoring to a "new" sensor array (e.g., temperature sensors on the same or adjacent machine), the aggregator immediately attempts to ingest data from the new array at the same sampling rate and transmission bitrate previously adapted for the first array. This ensures immediate high-fidelity data acquisition for critical process monitoring. The system continuously detects if the new sensor data stream can maintain this rate (e.g., based on sensor-specific data volume, network congestion, or gateway processing load) and adjusts the sampling rate or transmission bitrate if necessary.

graph TD
    SensorArray1[Vibration Sensors (Content A)] --> Gateway1(IIoT Gateway 1)
    SensorArray2[Temperature Sensors (Content B)] --> Gateway2(IIoT Gateway 2)
    Gateway1 --> |Adapted Bitrate X| DataAggregator(Central Data Aggregator)
    Gateway2 --> |Attempt Bitrate X| DataAggregator

    subgraph Data Aggregator
        InputA(Input Stream A)
        InputB(Input Stream B)
        BitratePreservationLogic[Bitrate Preservation Logic]
        RateAdjustment[Rate Adjustment Module]
        Output(Processed Data Output)

        InputA -- "Data from SensorArray1 @ Bitrate X" --> BitratePreservationLogic
        InputB -- "New selection" --> BitratePreservationLogic
        BitratePreservationLogic -- "Retain Bitrate X for InputB" --> RateAdjustment
        RateAdjustment -- "Monitor sustainability" --> RateAdjustment
        RateAdjustment -- "Adjusted Bitrate X'" --> InputB
        BitratePreservationLogic -- "Output Stream" --> Output
    end

    DataAggregator -- "Monitoring Display" --> Operator

---

1.4 Integration with Emerging Tech: AI-Driven Predictive Bitrate Pre-adjustment

Enabling Description:
The bitrate preservation system is enhanced with an Artificial Intelligence (AI) module that leverages machine learning (ML) models. This AI module continuously analyzes historical network performance, user viewing patterns, content characteristics (e.g., resolution, encoding complexity), and current network congestion (via IoT sensors in the network infrastructure) to predict an optimal initial bitrate for the new piece of content, even before the content is requested. Instead of merely preserving the last-used bitrate, the AI model performs a pre-adjustment. For instance, if the last bitrate was X, but the AI predicts that for the specific new content and current network conditions (monitored by IoT), an initial bitrate of X+Δ is sustainable or X-Δ is necessary to prevent immediate buffer underrun, it provides this intelligently adjusted bitrate to initiate playback. This minimizes the post-initiation adjustment phase, further optimizing the "instant-on" experience. Blockchain technology can be used to immutably log network performance data and AI model predictions for auditability and continuous model refinement, ensuring data integrity.

flowchart TD
    UserSelection[User Selects New Content]
    IOTSensors[IoT Network Sensors]
    HistoricalData[Historical Network & User Data]
    ContentMetadata[New Content Metadata]

    UserSelection --> AIModule(AI/ML Predictive Bitrate Module)
    IOTSensors --> AIModule
    HistoricalData --> AIModule
    ContentMetadata --> AIModule

    AIModule -- "Predictive Initial Bitrate (X_pred)" --> SourceElement[Source Element (212)]
    SourceElement --> ContentPlayback[Initiate Playback @ X_pred]
    ContentPlayback --> NetworkMonitoring[Monitor Playback & Network]
    NetworkMonitoring -- "Adaptation Feedback" --> SourceElement

    NetworkMonitoring -- "Immutable Log" --> Blockchain[Blockchain Ledger]
    AIModule -- "Model Update" --> Blockchain

---

1.5 The "Inverse" or Failure Mode: Graceful Degradation to Audio-Only Preservation

Enabling Description:
In scenarios where maintaining the full video bitrate and pipeline for a new piece of content becomes impossible due to severe network degradation or device resource constraints, the system is designed to gracefully degrade by prioritizing and preserving only the audio bitrate and its associated decoding pipeline. Upon detecting that the video stream cannot maintain even a minimal playable bitrate (e.g., buffer empty, repeated decoding errors), the system automatically releases the video decoder (218, FIG. 2) and reduces video download attempts. However, it preserves the audio decoder (216, FIG. 2) and attempts to maintain the last-known stable audio bitrate for the new content. This ensures continuous, albeit degraded, user experience by providing uninterrupted audio. The system can enter a "low-power" or "audio-only" mode, reducing CPU/GPU load and network bandwidth usage, and can signal to the user (e.g., "Video Unavailable, Audio Only") while attempting to recover video.

stateDiagram-v2
    state "ContentA_FullPlayback" as FullA
    state "ContentB_FullPlayback" as FullB
    state "ContentB_AudioOnly" as AudioB
    state "VideoRecoveryAttempt" as VideoRec

    [*] --> FullA : Start Playback Content A
    FullA --> FullB : Content Switch, Bitrate & Pipeline Preserved (Successful)

    FullA --> AudioB : Content Switch, Video Failed (Network/Resource Degradation)
    FullB --> AudioB : Video Fails during Content B Playback

    AudioB --> VideoRec : Attempt Video Recovery (periodically)
    VideoRec --> FullB : Video Recovery Successful
    VideoRec --> AudioB : Video Recovery Failed

    AudioB --> [*] : User Terminates / Permanent Failure
    FullB --> [*] : User Terminates

---

Derivatives for Pipeline Preservation (Based on Claims 2, 3, 5, 7, 8, 10, 12, 13, 15)

The dependent claims describe determining content type to preserve at least a portion of the playback pipeline (source element, demultiplexer, audio decoder, video decoder), detecting codec information, and conditionally preserving the entire pipeline or releasing/obtaining new decoders.

---

2.1 Material & Component Substitution: Dynamically Reconfigurable Decoder Blocks

Enabling Description:
Instead of distinct, fixed-function audio and video decoders (216, 218, FIG. 2), the digital receiver utilizes dynamically reconfigurable hardware decoder blocks (e.g., based on reconfigurable computing architectures or advanced FPGAs). These blocks can be reprogrammed or reconfigured on-the-fly to support different codec types (e.g., H.264 to VP9, AAC to Opus) as indicated by the prefetched codec information for the new content. When a content type switch necessitates a different decoder (Claim 3, 8, 13), instead of "releasing" an old decoder and "obtaining" a new one (Claim 5, 10, 15), the existing reconfigurable hardware block is rapidly reconfigured with the new codec's bitstream or configuration profile. This "soft" reconfiguration retains the physical hardware and its established data paths within the pipeline, significantly reducing the overhead and latency associated with tearing down and instantiating entirely new decoder instances or acquiring new hardware resources. The source element (212) and demultiplexer (214) remain preserved.

classDiagram
    class Player {
        +managePipeline()
        +determineContentCompatibility()
        +reconfigureDecoders()
    }
    class ContentDeliveryPipeline {
        +SourceElement source
        +Demultiplexer demux
        +ReconfigurableDecoderBlock audioDecoder
        +ReconfigurableDecoderBlock videoDecoder
    }
    class ReconfigurableDecoderBlock {
        -currentCodecType: CodecType
        +reconfigure(newCodecType: CodecType)
        +decode(inputSignal: Data)
    }
    class CacheManager {
        +prefetchMetadata()
    }
    class Cache {
        +storeMetadata(metadata)
        +retrieveMetadata(contentID)
    }

    Player "1" *-- "1" ContentDeliveryPipeline
    ContentDeliveryPipeline "1" --* "1" ReconfigurableDecoderBlock : audioDecoder
    ContentDeliveryPipeline "1" --* "1" ReconfigurableDecoderBlock : videoDecoder
    Player "1" -- "1" CacheManager
    CacheManager "1" -- "1" Cache

    Player <--> ReconfigurableDecoderBlock : reconfigure()
    Player <--> CacheManager : prefetchedMetadata

---

2.2 Operational Parameter Expansion: Ultra-Complex, Multi-Layered Pipeline Preservation

Enabling Description:
The pipeline preservation mechanism is extended to ultra-complex, multi-layered content delivery pipelines, such as those found in professional broadcast contribution networks or multi-codec/multi-format adaptive streaming platforms. Beyond the basic source, demux, audio, and video decoders, the pipeline includes additional processing layers: pre-processors (e.g., scaling, deinterlacing), post-processors (e.g., color correction, audio effects), and DRM decryption modules. The system determines not only content type and codec compatibility but also compatibility of these ancillary processing layers. If a new piece of content shares common processing requirements (e.g., same DRM scheme, similar scaling needs), those intermediate processing stages are also preserved. The system employs a granular resource map to identify and preserve the largest possible contiguous sub-graphs of the pipeline that remain compatible, releasing only the minimal incompatible nodes. This applies to pipelines handling dozens of simultaneous audio tracks, multiple video layers (e.g., base + enhancement layers), or complex metadata streams.

graph TD
    A[Source Element] --> B{Content Type Match?}
    B -- Yes --> C{DRM Match?}
    B -- No --> F[Release All, Rebuild]

    C -- Yes --> D{Codec Match?}
    C -- No --> G[Release DRM, Rebuild Relevant Layers]

    D -- Yes --> E{Ancillary Processors Match?}
    D -- No --> H[Release Audio/Video Decoders, Rebuild]

    E -- Yes --> I[Preserve Entire Pipeline]
    E -- No --> J[Preserve Core, Rebuild Ancillary Processors]

    A -- (First Content) --> A_Output
    I -- (New Content) --> A_Output
    G -- (New Content) --> A_Output
    H -- (New Content) --> A_Output
    J -- (New Content) --> A_Output

    subgraph Pipeline Decision Flow
        A
        B
        C
        D
        E
        F
        G
        H
        I
        J
    end

---

2.3 Cross-Domain Application: Scientific Data Visualization Pipeline for Astronomical Data

Enabling Description:
In the field of astronomy, researchers use complex data visualization pipelines to process and display astronomical data (e.g., telescope imagery, spectral data). A "digital receiver" in this context is a scientific workstation or cluster managing data feeds. When a researcher switches from analyzing one type of astronomical data (e.g., radio interferometer data in FITS format) to a "new" type (e.g., optical telescope data in HDF5 format), the system aims to preserve its data visualization pipeline. The system first checks if the "new" dataset type is compatible with the "first" dataset's processing pipeline (e.g., both require similar calibration steps, or share common visualization libraries). If compatible, it then checks for "codec information," which in this domain refers to specific data format parsers, processing algorithms, and rendering engines (e.g., a FITS data parser is analogous to a video decoder). If these "decoders" are compatible, the entire data ingestion, processing, and visualization pipeline is preserved. If not, only the incompatible format parsers or rendering engines are swapped out, preserving the common data handling and display frameworks.

graph LR
    DatasetA[Astronomical Dataset A (FITS)] --> DataIngest(Data Ingestion Module)
    DatasetB[Astronomical Dataset B (HDF5)] --> DataIngest

    subgraph Scientific Workstation (Digital Receiver)
        DataIngest -- (Data Stream) --> PreProcessor(Pre-processing)
        PreProcessor -- (Processed Data) --> DataFormatParser(Data Format Parser / "Decoder")
        DataFormatParser -- (Renderable Data) --> VisualizationEngine(Visualization Engine)
        VisualizationEngine -- (Display) --> Display(Display/User Interface)

        DataIngest <--> PipelinePreservation(Pipeline Preservation Logic)
        PreProcessor <--> PipelinePreservation
        DataFormatParser <--> PipelinePreservation
        VisualizationEngine <--> PipelinePreservation
    end

    PipelinePreservation -- "Check Data Type Compatibility" --> DataIngest
    PipelinePreservation -- "Check Parser/Engine Compatibility" --> DataFormatParser, VisualizationEngine
    PipelinePreservation -- "Preserve/Replace Components" --> DataFormatParser, VisualizationEngine

---

2.4 Integration with Emerging Tech: Blockchain for Pipeline State Verification & Immutable Resource Management

Enabling Description:
The content playback pipeline preservation is integrated with blockchain technology for enhanced security, auditability, and distributed resource management. Each state change within the pipeline (e.g., component instantiation, preservation decision, decoder release/acquisition, content type compatibility check, codec information validation) is recorded as an immutable transaction on a private blockchain. Smart contracts govern the rules for pipeline component reuse and resource allocation. For example, before preserving a pipeline portion, the player queries a smart contract on the blockchain to verify the integrity and compatibility of the retained components based on the prefetched metadata (which itself might be anchored to the blockchain for authenticity). If a component (e.g., a specific video decoder) is known to have vulnerabilities or performance issues (recorded on the blockchain), the smart contract might mandate its replacement even if technically compatible. This provides a verifiable and tamper-proof log of pipeline operations, crucial for Digital Rights Management (DRM) compliance and troubleshooting, and allows for distributed, trusted decision-making in multi-party content delivery environments.

flowchart TD
    Player[Player 202] --> CacheManager[Cache Manager 206]
    CacheManager --> PrefetchMetadata[Prefetch Metadata (Codec, Type)]
    PrefetchMetadata --> Player

    Player -- "Request Pipeline Preservation Decision" --> SmartContract[Smart Contract (Blockchain)]
    SmartContract -- "Verify Metadata Authenticity" --> BlockchainLedger(Blockchain Ledger)
    SmartContract -- "Check Component Integrity/Vulnerability" --> BlockchainLedger

    SmartContract -- "Decision: Preserve/Release Components" --> Player
    Player -- "Record Pipeline State Changes" --> BlockchainLedger
    Player -- "Execute Pipeline Changes" --> Pipeline(Content Delivery Pipeline 204)

    subgraph Pipeline State Recording
        Player -.-> BlockchainLedger
    end

---

2.5 The "Inverse" or Failure Mode: Minimal Viable Pipeline (MVP) Preservation for Diagnostic Purposes

Enabling Description:
A "Minimal Viable Pipeline (MVP) Preservation" mode is introduced as a diagnostic and recovery strategy. If the system detects a failure during full or partial pipeline preservation (e.g., inability to acquire new decoders, unexpected resource conflicts), instead of rebuilding the entire pipeline from scratch, it attempts to preserve only the absolute minimum components required to report diagnostic information or facilitate a controlled restart. This MVP typically comprises the source element (212) and a basic demultiplexer (214), with all decoders released. The preserved MVP is then used to ingest a small portion of the new content to extract critical stream headers and manifest data. This data, alongside error codes from the failed preservation attempt, is then logged and transmitted to a diagnostic service. This "limited-functionality" mode prevents a complete system freeze, facilitates rapid debugging, and allows for more intelligent, context-aware recovery attempts by providing insights into why preservation failed, rather than simply indicating a generic failure.

stateDiagram-v2
    state "FullPipeline_Active" as FullActive
    state "Attempting_Preservation" as AttemptPreserve
    state "MVP_Preserved_Diagnostic" as MVPDiag
    state "Rebuild_Pipeline" as Rebuild
    state "Reporting_Failure" as Report

    [*] --> FullActive : Initial Playback
    FullActive --> AttemptPreserve : Content Switch Initiated

    AttemptPreserve --> FullActive : Preservation Successful
    AttemptPreserve --> MVPDiag : Preservation Failed (enter MVP mode)

    MVPDiag --> Report : Collect & Transmit Diagnostics
    MVPDiag --> Rebuild : Trigger Full Pipeline Rebuild (informed)
    Rebuild --> FullActive : Rebuild Successful
    Rebuild --> MVPDiag : Rebuild Failed (return to MVP diag)

    Report --> FullActive : Manual Intervention/Recovery
    MVPDiag --> [*] : System Halt/Reset

---

Combination Prior Art Scenarios

These scenarios combine elements of US11184652 with existing open-source standards to make future variations obvious.

1. Adaptive Bitrate (ABR) Logic Integration with MPEG-DASH Open-Source Implementations

Enabling Description:
The bitrate preservation logic of US11184652, specifically the mechanism of maintaining a heuristically determined bitrate from a previous content stream for initiating a new stream (Claims 1, 6, 11), is integrated into an open-source MPEG-DASH player implementation (e.g., dash.js or Shaka Player). Current open-source DASH players typically start at a lowest or predefined bitrate upon new stream initiation and then adapt. This combination would modify the ABR algorithm within these players to store the last observed stable bitrate from an actively playing DASH stream and use it as the initial request bitrate for a newly selected DASH stream (e.g., a different manifest or representation set) of the same content type. The existing DASH ABR algorithms would then take over to detect sustainability and adjust as necessary, leveraging their standard buffer-based and throughput-based heuristics. This makes the "preserving previous bitrate for new content" obvious within the context of an established ABR standard.

2. Pipeline Resource Management within GStreamer Framework

Enabling Description:
The pipeline preservation methods of US11184652, particularly the determination of content type and codec information to conditionally preserve or replace pipeline elements (Claims 2, 3, 5, 7, 8, 10, 12, 13, 15), are implemented within the GStreamer open-source multimedia framework. GStreamer constructs pipelines from various plugins (source, demux, decoders, sinks). This combination would involve developing a "pipeline manager" plugin for GStreamer that, upon a content switch, uses prefetched metadata to inspect the codec properties of the new media. If the new media's properties (format, codec IDs) are compatible with the currently active GStreamer decoder plugins, the manager would avoid tearing down and re-creating those plugins, instead re-linking them to a new source element. If only decoders are incompatible, the manager would dynamically replace only the decoder plugins while preserving the source and demux plugins. This demonstrates the obvious application of conditional pipeline preservation within a modular, plug-and-play multimedia framework.

3. Real-time Network Monitoring for Bitrate Adjustment with WebRTC/SRT Standards

Enabling Description:
The "detecting whether the new piece of content can maintain playback at the first bitrate" and "adjusting the first bitrate" aspects of US11184652 (Claims 1, 6, 11, 16, 17, 18, 19, 20) are explicitly combined with real-time network telemetry mechanisms found in open-source WebRTC implementations or the SRT (Secure Reliable Transport) protocol. These standards provide rich, granular feedback on network conditions, including round-trip time (RTT), packet loss, and jitter. The system would use this advanced network feedback, available from standard WebRTC/SRT agents (e.g., in a content contributor's client or a CDN edge node), to inform the bitrate adjustment decisions for the new content. For instance, if SRT's built-in congestion control indicates increasing packet loss or RTT despite maintaining the previous bitrate, the system would immediately trigger a downward adjustment. Conversely, if WebRTC statistics indicate significantly underutilized bandwidth, an upward adjustment would be initiated. This makes the dynamic bitrate adjustment highly sensitive and responsive using readily available open-source network monitoring data.