Derivative works — US Patent 11184652

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.