US 12231703

Summary of U.S. Patent 12,231,703

A concise summary of U.S. Patent 12,231,703 is provided below, based on the available information as of April 26, 2026.

Title: Bitrate and pipeline preservation for content presentation

Assignee: OpenTV Inc

Inventors:

• Amarendra N. Gogoi
• Sanjay Kumar Gupta
• Ravikant Swami

Filing Date: October 4, 2023

Issue Date: February 18, 2025

Abstract:
Systems and methods for optimizing a content change process are provided. 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

U.S. Patent 12,231,703 contains three independent claims: claim 1, claim 11, and claim 20. Here is a plain-language explanation of each:

Independent Claim 1: This claim describes a method for a digital receiver (like a set-top box or smart TV) to more efficiently switch between different pieces of content. When a user who is watching one video selects a new one, the system checks if the new video is of the same technical format as the first. If it is, the system then determines if it can reuse parts of the existing software pathway (the "playback pipeline") that's already running. This pipeline includes components for downloading the video, separating the audio and video, and decoding them for playback. The goal is to reuse as much of this pipeline as possible to make the switch to the new content faster and smoother.

Independent Claim 11: This claim describes a system, which includes a hardware processor and a storage device, that performs the same method outlined in claim 1. Essentially, it covers the physical device that is configured to receive a selection for a new piece of content while another is playing, and then determine whether to preserve parts of the existing playback pipeline based on whether the content types are the same. This allows for a quicker transition to the new content by not having to rebuild the entire processing pipeline from scratch.

Independent Claim 20: This claim covers a machine-readable storage medium (like a hard drive or memory chip) that contains instructions. When these instructions are executed by a processor, they cause the machine to perform the method described in claim 1. This means the claim protects the software itself that, when run on a device, enables the efficient switching between content by evaluating the content type and preserving the playback pipeline where possible.

Litigation Status

As of April 26, 2026, a search of the dockets for the Court of Appeals for the Federal Circuit (CAFC) for the year 2026 did not reveal any appeals related to U.S. Patent 12,231,703. However, the patent document indicates a history of litigation, with a case filed in the Delaware District Court (1:25-cv-01404). The current status of that district court case is not specified in the available information.

Litigation History of U.S. Patent 12,231,703

As of April 30, 2026, U.S. Patent 12,231,703 is involved in at least one known litigation. The details of this case are as follows:

• Plaintiff: OpenTV, Inc.
• Defendant: Pinterest, Inc.
• Jurisdiction: U.S. District Court for the District of Delaware
• Case Number: 1:25-cv-01404
• Filing Date: November 18, 2025
• Current Status: The complaint for patent infringement has been filed. The case is ongoing.

The complaint alleges that Pinterest's platform for storing and viewing video content on various devices infringes on OpenTV's patented technologies. OpenTV, Inc. is seeking to stop the alleged unlicensed use of its technology.

Proceedings overview

There is one AIA trial proceeding filed against US Patent 12,231,703, which is currently pending. This means the patent's claims have not yet been challenged on the merits at the PTAB, offering a defendant a neutral defensive posture with potential for future invalidation.

IPR2026-00334 — Pinterest, Inc. v. OpenTV, Inc. et al.

• Type: Inter Partes Review
• Filed: 2026-04-06
• Status: Pending. The PTAB has not yet issued an institution decision or a final written decision.
• Judge panel: Not yet publicly available, as an institution decision has not been issued.
• Petition grounds: Specific claims, prior art, and statutory bases (§ 102 / § 103 / § 112) for the petition are not publicly available in the provided data. This information would typically be found in the filed petition document.
• Institution decision: Not yet issued. The PTAB will decide whether to institute the IPR within a statutory timeframe, typically one year from the petition's filing date.
• Final Written Decision: Not applicable, as the proceeding is pending.
• Settlement / termination: Not applicable, as the proceeding is pending.
• Appeal: Not applicable, as no final decision has been issued.
• Defensive value: This active IPR proceeding indicates that at least one party (Pinterest, Inc.) believes there are valid grounds to challenge the patentability of claims in US Patent 12,231,703. For a defendant facing assertion, the outcome of this IPR could significantly impact the strength of the patent. If claims are invalidated, it weakens the patent owner's position. If institution is denied or claims are sustained, it could strengthen the patent's defensive posture.

Strategic summary

Currently, all claims of US Patent 12,231,703 are UNTESTED at the PTAB, as the single filed IPR (IPR2026-00334) is still pending an institution decision. There are no claims that have been canceled or sustained through an AIA trial.

Regarding the estoppel landscape, if IPR2026-00334 is instituted and proceeds to a final written decision, Pinterest, Inc. (and its privies) would be estopped under § 315(e)(2) from raising any ground that was raised or reasonably could have been raised in that IPR against the claims challenged. For any other defendant, the prior art grounds remain available, subject to any other procedural bars (e.g., time-bar under § 315(b)).

There is no evident pattern of multiple IPRs filed by the same petitioner against this specific patent yet, as only one is active. However, it is noteworthy that OpenTV Inc. is identified as an operating company asserting its patent rights in district court litigation against Pinterest, Inc. (Case No. 1:25-cv-01404), and Pinterest, Inc. has subsequently filed this IPR. This suggests a reactive IPR filing in response to the district court litigation.

Recommended next steps

Since IPR2026-00334 is pending, a key milestone to watch is the institution decision deadline. The PTAB typically aims to issue an institution decision within 6 months of the petition filing date. Given the petition was filed on 2026-04-06, the institution decision is expected around 2026-10-06. The recent USPTO memos on discretionary institution, which consider factors like US manufacturing footprint and small business status, could play a role in this decision.

If the IPR is instituted, the PTAB has a statutory 1-year trial deadline from institution to issue a Final Written Decision.

Inventors

• Amarendra N. Gogoi (Employer: OpenTV Inc. at time of priority filing 2017-09-08)
• Sanjay Kumar Gupta (Employer: OpenTV Inc. at time of priority filing 2017-09-08)
• Ravikant Swami (Employer: OpenTV Inc. at time of priority filing 2017-09-08)

Original assignee

OpenTV Inc. is the original assignee named on the issued patent. OpenTV Inc. is primarily known for providing software and technology for interactive television and digital video broadcasting. They offer products and solutions for content discovery, user interfaces, and video delivery. The current status of OpenTV Inc. is operating, as indicated by their active involvement in litigation as a plaintiff.

Assignment timeline

• 2024-01-11 (executed) / recorded 2024-01-11 — Reel 059941/0816
  • Conveyance: Assignment
  • Assignor: GOGOI, AMARENDRA N., GUPT, SANJAY KUMAR, SWAMI, Ravikant
  • Assignee: OPENTV, INC.
  • Correspondent: BLANK ROME LLP, 1825 EYE STREET, NW, WASHINGTON, DISTRICT OF COLUMBIA, 20006-5403.
  • Context: This is the original assignment from the inventors to the assignee.

Timeline diagram

timeline
    title Ownership of US 12231703
    2017 : Priority date
    2023 : Application filed
    2024 : Assigned to OpenTV Inc
    2025 : Issued

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The initial assignment is from the inventors to OpenTV, Inc., which is an operating company. No transfers to shell entities are recorded.
2. Known asserter in the chain — not present. OpenTV, Inc. is an operating company and is acting as the plaintiff in the current litigation. No known NPEs are identified as assignees in the provided records.
3. Repeat correspondent across the chain — not present. Only one assignment is recorded, and thus no recurrence of correspondents can be observed in this specific chain for this patent.
4. Cascading transfers — not present. Only one assignment from the inventors to the operating company is recorded.
5. Pre-litigation transfer — not present. The assignment from the inventors to OpenTV Inc. was recorded on 2024-01-11 (Reel 059941/0816). The litigation with Pinterest Inc. was filed on 2025-11-18. This transfer occurred well over 6 months before the litigation commenced.
6. Bankruptcy fire-sale — not present. There is no indication that OpenTV Inc. has filed for bankruptcy.
7. Privateering — unclear. While OpenTV Inc. is an operating company and is asserting against Pinterest, the full details of any potential privateering agreements are not publicly available in the assignment records or the provided patent text.
8. Defensive aggregator (anti-NPE) — not present. The patent is currently owned by OpenTV Inc., which is asserting it.

Verdict

Operating-company assertion. The patent was assigned from the individual inventors to OpenTV Inc., an operating company. OpenTV Inc. is the plaintiff in the active litigation against Pinterest, Inc., which suggests the patent is being asserted by an operating company against a competitor.

https://assignmentcenter.uspto.gov/patents/[12231703](/patent/12231703)

Analysis of Prior Art for U.S. Patent 12,231,703

As a technical patent analyst on April 26, 2026, I have reviewed the citations listed for U.S. Patent 12,231,703 to identify the most relevant prior art. The following analysis details key references and their potential impact on the patent's claims under 35 U.S.C. § 102, which pertains to novelty.

The core invention of patent 12,231,703 is a method and system for reducing latency when a user switches between content streams on a digital receiver. This is achieved by:

1. Maintaining the bitrate of the previous content stream for the new stream.
2. Preserving all or part of the existing "playback pipeline" (source element, demultiplexer, audio/video decoders) if the new content is of the same type and uses compatible codecs.

Below is an examination of prior art references that could be considered to anticipate these claims.

---

Key Prior Art and Potential Anticipation of Claims

1. U.S. Patent Application Publication No. US 2013/0329354 A1

• Full Citation: Systems and methods for achieving optimal digital video channel change performance. Publication No. US 2013/0329354 A1.
• Publication Date: December 30, 2010 (filed June 29, 2009).
• Brief Description: This application describes a method for reducing channel change times in a digital video system. It discloses pre-tuning to a new channel and pre-building a media pipeline for the new content before the user finalizes the channel change. This includes allocating resources and initializing decoders in advance.
• Potential Anticipation: This reference appears to be highly relevant to the claims of patent 12,231,703, particularly independent claims 1, 11, and 20. The concept of preparing a playback pipeline for new content before it is selected is a core element of the '354 application. While it may not explicitly mention "preserving" the exact same pipeline components, the act of "pre-building" a pipeline for an anticipated content switch achieves a similar technical goal of reducing latency by avoiding the need to construct the pipeline from scratch after the switch. This could be argued to anticipate the novelty of determining whether to preserve the pipeline based on content type.

2. U.S. Patent No. 8,532,171 B1

• Full Citation: Multiple stream adaptive bit rate system. Patent No. US 8,532,171 B1.
• Publication Date: September 10, 2013 (filed December 23, 2010).
• Brief Description: This patent addresses adaptive bitrate streaming and describes a system that can manage multiple content streams simultaneously. It includes methods for switching between streams and managing the bitrate of those streams to ensure a smooth user experience.
• Potential Anticipation: This reference is relevant to the bitrate maintenance aspect of patent 12,231,703. Claim 6 of the patent, which depends on claim 1, specifies initiating playback of the new content using the bitrate from the previous content. The '171 patent's disclosure on managing bitrates across multiple streams could be interpreted as anticipating this specific step, as managing a switch between streams would inherently involve decisions about the initial bitrate of the new stream. An argument could be made that using the previous bitrate is an obvious starting point in an adaptive bitrate system.

3. U.S. Patent Application Publication No. US 2011/0296047 A1

• Full Citation: Method and apparatus for seamless playback of media. Publication No. US 2011/0296047 A1.
• Publication Date: December 1, 2011 (filed June 1, 2010).
• Brief Description: This application focuses on achieving seamless playback when switching between different media items. It describes a method where a media player can prepare for the playback of a subsequent media item while the current one is still playing. This includes pre-buffering data and preparing the necessary playback resources.
• Potential Anticipation: Similar to the '354 application, this reference teaches the concept of preparing for a content switch in advance to reduce delays. It directly addresses the problem of "seamless playback," which is the stated goal of patent 12,231,703. The '047 application's disclosure of preparing playback resources beforehand could be seen as anticipating the core idea of preserving or pre-building the playback pipeline as claimed in claims 1, 11, and 20 of the patent in question.

4. U.S. Patent Application Publication No. US 2004/0111526 A1

• Full Citation: Compositing MPEG video streams for combined image display. Publication No. US 2004/0111526 A1.
• Publication Date: June 10, 2004 (filed December 10, 2002).
• Brief Description: This application, though older, discusses the handling of multiple MPEG video streams. It describes a system that can decode and composite multiple streams, which requires managing multiple decoding pipelines.
• Potential Anticipation: While focused on displaying multiple streams at once rather than switching between them, the underlying technology for managing multiple decoder instances is relevant. An argument could be made that the knowledge of how to efficiently manage resources for multiple video streams was well-established by this reference. This could potentially render the concept of reusing a decoder pipeline for a new stream of the same type obvious to a person skilled in the art, thereby challenging the non-obviousness of the invention in patent 12,231,703, even if not directly anticipating it under § 102.

In summary, several prior art references disclose key elements of the invention claimed in U.S. Patent 12,231,703. The '354 and '047 applications, in particular, describe methods for pre-building or preparing playback resources to achieve faster content switching, which closely aligns with the concept of pipeline preservation. The '171 patent addresses adaptive bitrate management in a way that could anticipate the specific claim of maintaining the previous bitrate. These references would likely form the basis of any challenge to the novelty of the claims in patent 12,231,703.

Obviousness Analysis of U.S. Patent 12,231,703 under 35 U.S.C. § 103

This analysis, conducted on May 1, 2026, evaluates whether the invention claimed in U.S. Patent 12,231,703 would have been obvious to a Person Having Ordinary Skill in the Art (PHOSITA) at the time the invention was made. The analysis is based on the prior art references identified in the preceding section.

Under 35 U.S.C. § 103, a patent claim is invalid "if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art." This involves considering the scope and content of the prior art, the differences between the prior art and the claims at issue, and the level of ordinary skill in the pertinent art. An obviousness rejection can be based on a combination of prior art references if there was a motivation to combine them.

The independent claims (1, 11, and 20) of patent 12,231,703 broadly cover a method and system for optimizing a content switch by (A) maintaining the bitrate of the first content stream for the new content stream and (B) preserving the existing playback pipeline if the new content is of a compatible type and format.

The following combinations of prior art would have rendered these claims obvious to a PHOSITA.

---

Combination 1: US 2013/0329354 A1 ('354) in view of US 8,532,171 B1 ('171)

1. The '354 Application Teaches Pipeline Preparation:
The '354 application directly addresses the same technical problem as the '703 patent: reducing latency during channel changes. It discloses a method of "pre-building a media pipeline" for the anticipated new content before the user confirms the switch. This pre-building involves allocating necessary resources, including initializing decoders. This teaching is functionally equivalent to the '703 patent's concept of "preserving at least a portion of a playback pipeline." A PHOSITA would recognize that pre-building a new pipeline and preserving an existing one are two closely related strategies to achieve the same goal of having resources ready for the new stream, thereby minimizing delay. Both avoid the latency of constructing a pipeline from scratch.

Furthermore, the process of pre-building a pipeline as taught by '354 would inherently require determining the content type and codec requirements of the new stream. It is a fundamental prerequisite for a media system to know these parameters to allocate the correct resources (e.g., a DASH source handler, an H.265 video decoder). Therefore, the '354 application teaches or at least strongly suggests the core pipeline management aspect of the '703 patent's claims.

2. The '171 Patent Teaches Bitrate Management for Stream Switching:
The '171 patent relates to adaptive bitrate streaming and managing switches between multiple streams. While the '354 application focuses on the pipeline structure, it does not explicitly teach what initial bitrate to use for the new stream. This is a question a PHOSITA implementing the '354 system would inevitably face. In adaptive streaming, starting with the lowest possible bitrate is a common but suboptimal approach that leads to poor initial quality—the very problem the '703 patent seeks to solve.

3. Motivation to Combine '354 and '171:
A PHOSITA, starting with the '354 application's method for fast channel switching, would be motivated to optimize the user experience further by ensuring the new stream starts at the highest possible quality. They would look to the art concerning adaptive bitrate management, such as the '171 patent, for guidance. The most logical and readily available information for selecting an initial bitrate is the performance of the currently playing stream. The bitrate of the first piece of content has already been optimized by the system based on current network conditions. Therefore, it would have been obvious to a PHOSITA to try using this last known-good bitrate as the starting point for the new stream to avoid the slow ramp-up from a low-quality version. This is a simple and effective heuristic that directly follows from combining the teachings of the two references.

The combination of '354's pipeline preparation with the bitrate management principles evident in '171 teaches all elements of the independent claims of patent 12,231,703.

---

Combination 2: US 2011/0296047 A1 ('047) in view of US 8,532,171 B1 ('171)

An alternative but similar argument for obviousness can be made using the '047 application.

1. The '047 Application Teaches Preparing Resources for Seamless Playback:
The '047 application discloses a method for "seamless playback" when switching between media items by preparing playback resources for the next item while the current one is still playing. This includes pre-buffering data and preparing the necessary playback components. This teaching, like that of the '354 application, is analogous to the '703 patent's concept of preserving the playback pipeline. Achieving seamlessness necessitates that the playback resources are ready at the moment of the switch, which is the central idea of claims 1, 11, and 20 of the '703 patent.

2. Motivation to Combine '047 and '171:
The motivation to combine the '047 application with the '171 patent is the same as in the first combination. A PHOSITA implementing the "seamless" system of '047 would recognize that a sudden drop in video quality upon switching content is not a seamless experience. To prevent this, they would seek a method to select a better initial bitrate than the default lowest one. The '171 patent provides the context of managing bitrates during stream switches. The most obvious and predictable solution would be to maintain the bitrate from the previous stream, as it reflects the established network capacity. This combination would lead directly to the invention claimed in the '703 patent.

Conclusion

The independent claims of U.S. Patent 12,231,703 would likely be found obvious under 35 U.S.C. § 103. The core concepts of preparing a playback pipeline in advance to reduce switching latency were already taught by prior art such as US 2013/0329354 A1 and US 2011/0296047 A1. A person of ordinary skill in the art, when implementing such a system, would have been motivated to address the initial bitrate selection for the new stream to ensure a high-quality user experience. Combining the teachings on pipeline preparation with the known principles of adaptive bitrate management, as discussed in art like US 8,532,171 B1, would have led to the obvious solution of using the previously established bitrate for the new content stream. The specific steps of checking for content type and codec compatibility are inherent and necessary prerequisites for any form of pipeline preparation or preservation and do not constitute a separate inventive step.

Based on my analysis of U.S. Patent 12,231,703 as of May 1, 2026, here are the details regarding its term, related applications, and family members.

Patent Term Adjustment (PTA) and Patent Term Extension (PTE)

• Patent Term Adjustment (PTA): The provided documentation from Google Patents does not specify the exact number of days of Patent Term Adjustment granted by the USPTO for delays during prosecution. PTA is awarded on a day-for-day basis for certain administrative delays by the USPTO. While this information would be available in the USPTO's official file wrapper, it is not present in the provided source materials.
• Patent Term Extension (PTE): There is no indication that this patent has received or is eligible for a Patent Term Extension. PTE is typically granted to compensate for regulatory review delays (e.g., by the Food and Drug Administration) for products such as pharmaceuticals and medical devices, and is not applicable to the technology covered by this patent.

Continuation and Divisional Applications

The prosecution history of this patent involves a chain of continuation applications.

• Continuation Applications: U.S. Patent 12,231,703, which issued from application Ser. No. 18/480,918, is part of a series of continuing applications.
  • It is a continuation of U.S. application Ser. No. 17/454,169 (now U.S. Patent 11,825,139).
  • Application Ser. No. 17/454,169 is itself a continuation of U.S. application Ser. No. 16/645,598 (now U.S. Patent 11,184,652).
• Child Application: The patent family includes a subsequent continuation application filed after this patent's application. As listed in the "Related Child Applications" section of the patent data, U.S. application Ser. No. 19/020,338 is a continuation of the application that led to this patent.
• Divisional Applications: Based on the provided patent documentation, there is no mention of any divisional applications related to U.S. Patent 12,231,703.

Related Patent Family

U.S. Patent 12,231,703 is part of a larger patent family (Family ID 65634196) with members in the United States and other countries. The U.S. patents in this family include:

• U.S. Patent 11,184,652: Issued from application Ser. No. 16/645,598.
• U.S. Patent 11,825,139: Issued from application Ser. No. 17/454,169.
• U.S. Patent 12,231,703: The patent in question, issued from application Ser. No. 18/480,918.

The family also includes patent applications and grants in other jurisdictions, including Europe (EP), China (CN), Brazil (BR), and Taiwan (TW), stemming from the international PCT application WO2019050660A1.

Projected Expiration Date

The term of a U.S. patent is typically 20 years from the filing date of the earliest U.S. or international (PCT) application in the priority chain.

• Earliest Effective Filing Date: The patent's priority chain traces back to PCT Application No. PCT/US2018/046723, which was filed on August 14, 2018.
• Calculated Expiration Date: The 20-year term, calculated from this effective filing date, ends on August 14, 2038.

This date aligns with the "Anticipated expiration" date provided in the patent's documentation. This suggests that there were zero days of Patent Term Adjustment (PTA) granted, as the expiration date is exactly 20 years from the earliest effective filing date.

As a Senior Patent Strategist and Research Engineer, I have analyzed U.S. Patent 12,231,703. The following defensive disclosure document details a series of derivative works and improvements built upon the core claims of the patent. The purpose of this document is to place these concepts into the public domain, thereby establishing them as prior art against future patent applications for similar, incremental inventions.

Defensive Disclosure: Derivative Works for Content Delivery Pipeline Management

Reference Patent: US 12,231,703 B2
Publication Date: May 1, 2026

I. Material & Component Substitution

Derivative 1.1: Hardware-Accelerated Pipeline Preservation with Heterogeneous Decoders

• Enabling Description: This variation extends the pipeline preservation logic to a System-on-a-Chip (SoC) environment with multiple, heterogeneous hardware decoders. The digital receiver's player component (ref. US 12,231,703, FIG. 2, 202) maintains a real-time registry of available hardware decoder blocks (e.g., a dedicated H.264 block, a more power-efficient HEVC block, and a versatile AV1 block). When a content switch is requested, the system's player consults the prefetched metadata for the new content's codec. Instead of only checking for a codec match with the current decoder, it checks if any available and idle hardware decoder block matches. If the current HEVC decoder is in use, but an idle AV1 decoder is available and the new stream is AV1, the system preserves the source element and demux while re-routing the video elementary stream to the idle AV1 hardware block. This avoids the latency of releasing the first decoder and allows for instantaneous switching between content streams of different, but hardware-supported, codecs. The audio decoder pipeline is preserved independently based on audio codec compatibility (e.g., AAC, Dolby Digital).

• Diagram:

  graph TD
      subgraph Original Pipeline (HEVC)
          A[Source Element] --> B[Demux];
          B --> C{Video ES};
          B --> D{Audio ES};
          C --> E[Hardware HEVC Decoder];
          D --> F[Audio Decoder];
      end
  
      subgraph New Pipeline (AV1)
          A_preserved[Source Element (Preserved)] --> B_preserved[Demux (Preserved)];
          B_preserved --> C_new{Video ES (AV1)};
          B_preserved --> D_preserved{Audio ES (AAC)};
          C_new --> G[Hardware AV1 Decoder (Idle)];
          D_preserved --> F_preserved[Audio Decoder (Preserved)];
      end
  
      H{Player Logic} -- Request Switch --> I{Check Prefetched Metadata};
      I -- Codec=AV1 --> J{Query Decoder Registry};
      J -- AV1 block idle --> K[Re-route to AV1 Decoder];
      E -- Released --> J;
  

Derivative 1.2: Pipeline Preservation using FPGA-based Reconfigurable Logic

• Enabling Description: This embodiment replaces dedicated hardware decoders with a Field-Programmable Gate Array (FPGA). The player component loads a specific decoder bitstream (e.g., for VP9) onto the FPGA to instantiate the initial playback pipeline. Upon a content switch to a different codec (e.g., HEVC), the system initiates a partial reconfiguration of the FPGA. While the source element and demux (running on a CPU) are preserved, the FPGA logic block corresponding to the VP9 decoder is dynamically swapped with a pre-compiled HEVC decoder bitstream. This allows for pipeline "preservation" even with incompatible codecs by reconfiguring the hardware itself, which is significantly faster than tearing down the entire software pipeline and releasing OS-level resources. The process relies on having a library of decoder bitstreams stored locally.

• Diagram:

  sequenceDiagram
      participant User
      participant Player
      participant CPU
      participant FPGA
  
      User->>Player: Selects new content (HEVC)
      Player->>CPU: Preserve Source & Demux
      Player->>FPGA: Initiate Partial Reconfiguration
      FPGA-->>Player: Acknowledge
      Note over FPGA: Unloads VP9 Bitstream
      Note over FPGA: Loads HEVC Bitstream
      Player->>CPU: Route new HEVC stream to FPGA
      CPU->>FPGA: Pushes HEVC elementary stream
      FPGA->>Player: Decoded frames available
  

II. Operational Parameter Expansion

Derivative 2.1: Pipeline Preservation in High-Latency Satellite Networks

• Enabling Description: This derivative applies the invention to a digital receiver operating over a geostationary satellite link, characterized by high latency (~600ms RTT) and variable bandwidth due to weather. The source element (ref. US 12,231,703, FIG. 2, 212) is enhanced with a predictive buffering algorithm that uses a larger forward buffer (e.g., 60-90 seconds). When a content switch occurs, preserving the source element not only maintains the bitrate heuristic but also the entire buffered data state. If the user switches to a new piece of content and then quickly switches back, the system can resume playback from the preserved buffer without re-requesting segments from the server, effectively masking the high network latency for the return action. The decision to preserve the pipeline is weighted by the size of the forward buffer; if the buffer is nearly full, the system prioritizes preservation to save bandwidth.

• Diagram:

  stateDiagram-v2
      [*] --> Playback_ContentA
      Playback_ContentA: Bitrate = 2Mbps, Buffer = 85s
      Playback_ContentA --> Playback_ContentB: User selects new content
      note on link
          Preserve Pipeline & Buffer for Content A.
          Start new stream for Content B.
      end note
  
      Playback_ContentB: Bitrate = 2Mbps (maintained)
      Playback_ContentB --> Playback_ContentA: User switches back within 30s
      note on link
          Instantly resume from preserved buffer.
          No data requested over satellite link.
      end note
  

Derivative 2.2: Massively-Scaled Pipeline Management in Cloud Transcoding

• Enabling Description: The core mechanism is applied at an industrial scale within a cloud-based video transcoding service. A server handling thousands of live streams (e.g., for a streaming event) must generate multiple adaptive bitrate renditions for each. When a source stream's parameters change (e.g., resolution switches from 720p to 1080p), instead of tearing down and rebuilding the entire transcoding graph for all ABR renditions, the system preserves compatible pipeline elements. The demux and audio transcoder (if the audio format is unchanged) are preserved for all renditions. Only the video scaler and video encoder components are re-initialized with the new parameters. This preservation of a "master" pipeline segment that feeds multiple child pipelines drastically reduces resource churn and processing gaps across the entire bitrate ladder.

• Diagram:

  graph TD
      subgraph Original State (720p Input)
          Input[Live 720p Stream] --> Demux;
          Demux --> AudioTranscoder;
          Demux --> VideoPath_720p[Scaler + Encoder];
          Demux --> VideoPath_480p[Scaler + Encoder];
          Demux --> VideoPath_360p[Scaler + Encoder];
      end
  
      subgraph New State (1080p Input)
          NewInput[Live 1080p Stream] --> PreservedDemux[Demux (Preserved)];
          PreservedDemux --> PreservedAudio[AudioTranscoder (Preserved)];
          PreservedDemux --> NewVideoPath_1080p[New Scaler + Encoder];
          PreservedDemux --> NewVideoPath_720p[New Scaler + Encoder];
          PreservedDemux --> NewVideoPath_480p[New Scaler + Encoder];
      end
  
      Logic{Orchestrator} -- Input Change Detected --> PreserveAndRebuild;
  

III. Cross-Domain Application

Derivative 3.1: Aerospace - Real-Time Sensor Fusion Pipeline for UAVs

• Enabling Description: An unmanned aerial vehicle (UAV) uses multiple sensors for autonomous navigation (e.g., 4K EO camera, thermal IR, LiDAR). Each sensor has a dedicated processing pipeline (noise reduction, stabilization, object detection). To save computational resources, only one sensor pipeline is fully active at a time. When the navigation logic switches from EO to IR due to low light, it preserves the common pipeline stages, such as the data ingestion buffer, the geometric transformation module (for aligning sensor data to a common map), and the control signal output module. Only the sensor-specific front-end processing modules are swapped. This reduces switch latency from hundreds of milliseconds to under 10 milliseconds, which is critical for maintaining stable flight during sensor transitions.

• Diagram:

  flowchart LR
      subgraph EO Pipeline
          A[EO Sensor] --> B[Noise Reduction];
          B --> C[Geo-Transform];
          C --> D[Object Detection];
          D --> E[Flight Control];
      end
  
      subgraph IR Pipeline
          F[IR Sensor] --> G[IR Gain Control];
          G --> C_p[Geo-Transform (Preserved)];
          C_p --> D_p[Object Detection (Preserved)];
          D_p --> E_p[Flight Control (Preserved)];
      end
  
      Nav[Navigation Logic] -- Low Light --> Switch;
      Switch -- Preserve C, D, E --> IR_Pipeline;
  

Derivative 3.2: AgTech - Dynamic Task Pipeline on Autonomous Tractors

• Enabling Description: An autonomous tractor performs multiple tasks in a field, such as soil nutrient analysis, weed detection, and targeted pesticide spraying. Each task requires a different sensor-to-actuator pipeline. When transitioning from weed detection (using multispectral cameras) to soil analysis (using ground-penetrating sensors), the core Data Aggregator and GPS/Positioning elements of the pipeline are preserved. The system releases the machine vision processing module and instantiates a soil composition analysis module, but the underlying data structures and connection to the tractor's CAN bus controller are maintained. This allows the tractor to switch tasks without rebooting its control system, saving time and energy.

• Diagram:

  classDiagram
      class TractorControlSystem {
          +Pipeline currentPipeline
          +switchTask(newTask)
      }
      class Pipeline {
          +DataSource dataSource
          +Processor processor
          +ActuatorController actuator
      }
      class GpsDataSource
      class VisionProcessor
      class SoilProcessor
      class SprayerActuator
  
      TractorControlSystem "1" -- "1" Pipeline
      Pipeline "1" *-- "1" GpsDataSource
      Pipeline "1" *-- "1" VisionProcessor
      Pipeline "1" *-- "1" SoilProcessor
      Pipeline "1" *-- "1" SprayerActuator
  
      note for TractorControlSystem "switchTask preserves GpsDataSource and re-instantiates Processor"
  

Derivative 3.3: Telemedicine - Multi-Feed Management in Robotic Surgery

• Enabling Description: During a remote surgical procedure, the surgeon's console displays video from an endoscope, an external overhead camera, and real-time ultrasound imaging. Each feed has a processing pipeline for tasks like latency compensation, artifact removal, and data overlay. When the surgeon switches their main view from the endoscope to the ultrasound, the system preserves the Network Transport element (maintaining the WebRTC connection and its quality-of-service parameters) and the Display Rendering engine. The system releases the endoscope-specific image processing resources and allocates resources for the ultrasound feed, directing its output to the preserved renderer. This minimizes the "black screen" time and cognitive load on the surgeon during a critical procedure.

• Diagram:

  sequenceDiagram
      participant Surgeon
      participant Console
      participant Network
      participant Robot
  
      Surgeon->>Console: Switch view to Ultrasound
      Console->>Console: Preserve Network & Renderer
      Console->>Robot: Request Ultrasound Stream
      Robot-->>Console: Ultrasound Data
      Console->>Console: Instantiate US Processor
      Console->>Console: Route data to Renderer
  

IV. Integration with Emerging Tech

Derivative 4.1: AI-Driven Predictive Pipeline Pre-warming

• Enabling Description: This system uses a recurrent neural network (RNN) trained on user navigation history to predict the next piece of content a user is likely to select with a high probability (e.g., >95%). Instead of waiting for a selection, the system proactively instantiates a "shadow" pipeline for the predicted content. It uses the principles of the '703 patent to preserve components from the current pipeline to build this shadow pipeline efficiently. When the user makes the predicted selection, the system performs an instantaneous switch by promoting the shadow pipeline to the active one. The AI model also determines the optimal initial bitrate for the shadow pipeline based on a time-series forecast of network bandwidth, rather than just using the last known bitrate.

• Diagram:

  graph TD
      A[User Navigation Events] --> B[RNN Model];
      B -- Prediction: Content_X --> C[Orchestrator];
      D[Current Pipeline] --> C;
      C --> E{Build Shadow Pipeline for X};
      E -- Reuse Components --> D;
      F[User] -- Selects Content_X --> G{Instant Switch};
      E --> G;
  

Derivative 4.2: IoT-Informed Pipeline Preservation Logic

• Enabling Description: The decision logic for pipeline preservation is augmented with real-time data from IoT sensors on the client device. A Device State Monitor service collects data on CPU temperature, battery charge level, and memory pressure. The player component queries this service before deciding on preservation. For example, if the metadata indicates the new and old content use the same resource-intensive software video decoder, but the CPU temperature is above a critical threshold (e.g., 85°C), the preservation logic will be overridden. The system will deconstruct the pipeline and build a new one using a less intensive hardware decoder or a lower-resolution stream, prioritizing device stability and battery life over switch speed.

• Diagram:

  flowchart TD
      A[User requests new content] --> B{Check content type & codec};
      B -- Compatible --> C{Query Device State Monitor};
      subgraph IoT Sensors
          T[CPU Temp] --> DSM;
          M[Memory Pressure] --> DSM;
          BATT[Battery Level] --> DSM;
      end
      C -- State Data --> D{Preservation Logic};
      D -- Is CPU > 85°C? --> E{Yes};
      D -- Is CPU > 85°C? --> F{No};
      E --> G[Override: Deconstruct & build low-power pipeline];
      F --> H[Proceed: Preserve pipeline];
  

V. The "Inverse" or Failure Mode

Derivative 5.1: Graceful Degradation Pipeline

• Enabling Description: This derivative describes a "Safe Mode" for the playback pipeline. If the system detects a non-fatal error during playback (e.g., a series of corrupted video frames, a decoder process repeatedly crashing), it triggers a graceful degradation. Instead of halting, the system intentionally preserves only the most basic components of the pipeline: the source element and demux. It releases the potentially faulty hardware/software decoders and constructs a new pipeline backend using a "failsafe" profile: a low-resolution video stream and a universally compatible, low-CPU software video decoder (e.g., a simple MPEG-4 Part 2 decoder). This ensures that playback continues, albeit at a significantly reduced quality, allowing the user to continue watching while the system logs the error in the background. The bitrate is also reset to the lowest available to ensure stability.

• Diagram:

  stateDiagram-v2
      state "Full Quality" as Full
      state "Degraded Mode" as Degraded
  
      [*] --> Full
      Full: Playing 1080p HEVC with Hardware Decoder
      Full --> Degraded: on: DecoderError
      note on link
          Preserve Source & Demux.
          Reset to 360p stream.
          Instantiate Failsafe SW Decoder.
      end note
  
      Degraded: Playing 360p MPEG4 with Software Decoder
      Degraded --> Full: on: UserReboot or ErrorClear
  

VI. Combination Prior Art with Open-Source Standards

Scenario 6.1: Integration with GStreamer Multimedia Framework

• Enabling Description: The patented method is implemented as a new GStreamer plugin library, gst-pipeline-preserver.so. This library provides a new element, pipemanager, which can be placed in a GStreamer pipeline. When an application needs to switch content, it sends a "prepare-switch" event to the pipemanager containing the URI and prefetched metadata of the new stream. The pipemanager introspects the current running pipeline, identifies compatible downstream elements (e.g., avdec_h264, audioconvert), and locks them. It then sends a flush event to clear their internal state. When the application sets the pipeline to the PLAYING state with the new URI, the pipemanager allows data to flow through the preserved elements, having avoided the cost of destroying and recreating them.

Scenario 6.2: Integration with WebRTC Standard

• Enabling Description: In a browser implementing the WebRTC standard, the pipeline preservation logic is applied to RTCPeerConnection. When a track is replaced using RTCRtpSender.replaceTrack(), for example, to switch from a 1080p camera to a 1080p screen share, the browser's media engine checks if the codec and resolution are identical. If so, it preserves the underlying video encoding pipeline (e.g., the configured VP9 or AV1 encoder instance) and the RTP packetization components. It simply flushes the encoder's state and begins feeding it frames from the new media track. This avoids renegotiating the connection or re-allocating the computationally expensive encoder, resulting in a nearly instantaneous track switch for remote peers.

Scenario 6.3: Integration with FFmpeg Libraries

• Enabling Description: The logic is integrated into FFmpeg's libavformat and libavcodec libraries. A new set of functions, such as avformat_preserve_context() and avcodec_flush_and_reuse(), is introduced. An application playing content can call avformat_preserve_context() on its AVFormatContext before closing it. This caches the bitrate heuristics and pointers to the underlying AVCodecContext. When opening a new stream, the application can pass this cached object to avformat_open_input(). The function will then attempt to reuse the existing codec context by calling avcodec_flush_and_reuse(), which is faster than avcodec_close() followed by avcodec_open2(). This allows any media player built on FFmpeg to leverage pipeline preservation with minimal code changes.