Derivative works — US Patent 8868772

Defensive Disclosure and Prior Art Enhancement for Adaptive Streaming Technologies

Publication Date: May 8, 2026
Reference Patent: US 8,868,772 B2
Field: Digital Data Streaming, Network Protocols, Multimedia Content Delivery

This document serves as a defensive publication to disclose variations, extensions, and combinations of the adaptive bitrate streaming method described in US Patent 8,868,772. The intention is to place these concepts in the public domain, thereby establishing prior art against future patent applications claiming these incremental or obvious improvements. The core concept involves a client-side media player that adaptively requests segments of a video stream ("streamlets") from multiple quality tiers based on real-time monitoring of network performance.

Derivative Variations on Core Claim 1

The following disclosures expand upon the method of simultaneously requesting streamlets, monitoring responses, adaptively selecting subsequent streamlet quality, and staging for playback.

Axis 1: Material & Component Substitution

This axis explores replacing the software and hardware components described or implied in the patent with alternative technologies that achieve the same functional outcome.

Derivative 1.1: WebAssembly (WASM) Based Agent Controller

Enabling Description: The "agent controller module," originally conceived as JavaScript or native application code, is implemented as a high-performance WebAssembly module. This allows for near-native speed in calculating the performance factor (φ) by executing compiled C++ or Rust code directly in the browser. The WASM module accesses network performance data via the JavaScript Performance API, performing complex statistical analysis (e.g., Kalman filtering instead of a simple geometric mean) on streamlet download times with minimal overhead. This substitution allows for more computationally intensive prediction algorithms to run efficiently on the client, improving the accuracy of upshift/downshift decisions.

Mermaid Diagram:

graph TD
    subgraph Browser Environment
        A[JavaScript Glue Code] -- Invokes & Passes Data --> B(WASM Agent Controller);
        C[HTML5 Video Player] -- Playback Control --> A;
        B -- Performance Data Request --> D{Performance API};
        D -- Raw Timings --> B;
        B -- Calculated Quality Tier --> E[Network Controller];
        E -- HTTP/S Requests --> F((Content Delivery Network));
        F -- Streamlets --> E;
        E -- Received Streamlets --> G[Staging Module / Buffer];
        G -- Ordered Streamlets --> C;
    end

Derivative 1.2: QUIC Protocol as the Transport Layer

Enabling Description: The underlying transport mechanism of multiple TCP connections is replaced with a single connection using the QUIC protocol (built on UDP). QUIC's native support for multiple independent streams within a single connection directly maps to the concept of simultaneously requesting multiple streamlets. The "agent controller module" leverages QUIC's stream-level feedback, such as packet loss and round-trip time (RTT) per stream, as primary inputs for its performance factor calculation. This eliminates the head-of-line blocking issue inherent in using multiple TCP connections and provides more granular, real-time network diagnostics, leading to faster and more accurate quality switching.

Mermaid Diagram:

sequenceDiagram
    participant Client as Client Media Player
    participant Server as QUIC-Enabled Server
    Client->>Server: Establish Single QUIC Connection
    loop Parallel Streamlet Requests
        Client->>Server: Request Streamlet N (on Stream 1)
        Client->>Server: Request Streamlet N+1 (on Stream 2)
        Client->>Server: Request Streamlet N+2 (on Stream 3)
    end
    Note over Client,Server: Streams are independent; packet loss on one does not block others.
    Server-->>Client: Streamlet N Data (on Stream 1)
    Server-->>Client: Streamlet N+1 Data (on Stream 2)
    Note left of Client: Agent Controller analyzes RTT & loss for each stream.
    Client->>Client: Calculate performance factor φ_quic
    Client->>Server: Request Streamlet N+3 from new quality tier (on Stream 4)

Derivative 1.3: FPGA-Accelerated Staging Module

Enabling Description: In embedded systems or high-performance set-top boxes, the "staging module" is implemented in hardware on a Field-Programmable Gate Array (FPGA). The network interface controller (NIC) forwards incoming streamlet packets directly to the FPGA. The FPGA logic handles the reordering of streamlets based on their time indexes and manages the playback buffer, offloading this memory-intensive task from the main CPU. This hardware-based approach guarantees low-latency staging and assembly, even with a high number of parallel streamlet requests, making it suitable for 8K or high-frame-rate streaming applications where CPU contention could be a bottleneck.

Mermaid Diagram:

graph LR
    A[NIC] -- Streamlet Packets --> B{FPGA};
    subgraph FPGA Logic
        B -- Demultiplexes --> C[Packet Parser];
        C -- Time Index & Payload --> D[Streamlet Reorder Engine];
        D -- Writes to --> E[On-chip Buffer Memory];
    end
    F[CPU] -- Buffer Read Request --> B;
    B -- Requests Data --> E;
    E -- Ordered Streamlet --> G[Video Decoder];
    F -- Runs --> H(Agent Controller);
    H -- Quality Decision --> A;

Axis 2: Operational Parameter Expansion

This axis describes the core invention operating at extreme or unconventional scales and conditions.

Derivative 2.1: Nanoscale Streaming for Molecular Simulation

Enabling Description: The method is applied to the real-time visualization of molecular dynamics simulations. The "content file" is a massive, multi-terabyte simulation dataset. The "streamlets" are femtosecond-duration snapshots of molecular positions. The "quality tiers" correspond to different levels of data resolution (e.g., full atomic coordinates vs. coarse-grained bead models). A client-side scientific visualization tool on a researcher's workstation requests these streamlets to render a live view of the simulation. The agent controller monitors the download speed from the supercomputing cluster and adaptively shifts between full-atomic and coarse-grained representations to ensure a smooth, interactive visualization without stalling the rendering pipeline.

Mermaid Diagram:

graph TD
    A[Supercomputer Cluster] -- Simulation Data --> B(Content Server);
    B -- Encodes --> C[Tier 1: Atomic Coords];
    B -- Encodes --> D[Tier 2: Coarse-Grained];
    E[Visualization Client] -- Requests Streamlets --> B;
    subgraph E
        F[Agent Controller] -- Monitors Network --> G{Performance Metric};
        G -- Selects Tier --> H[Request Scheduler];
        H -- Sends Request --> B;
    end
    B -- Sends Streamlet --> I[Staging Module];
    I -- Assembles --> J[3D Molecular Renderer];

Derivative 2.2: Deep Space Communications Relay

Enabling Description: The adaptive-rate shifting method is used for transmitting scientific data from a Martian rover to an orbiting relay satellite with a highly variable communication link due to atmospheric interference and orbital mechanics. The "content" is a high-resolution panoramic image. The "quality tiers" are different levels of wavelet compression for the image. The rover's communication subsystem (the "client") acts as the agent controller. It simultaneously requests acknowledgments for multiple data "streamlets" (image tiles) from the orbiter. By monitoring the latency and packet loss of these acknowledgments, it determines the link quality and decides whether to send the next tile with more or less aggressive compression to maximize data throughput during a limited communication window.

Mermaid Diagram:

sequenceDiagram
    participant Rover as Rover (Client)
    participant Orbiter as Relay Satellite (Server)
    Rover->>Orbiter: Request ACK for Tile 1 (Packet A)
    Rover->>Orbiter: Request ACK for Tile 2 (Packet B)
    Note over Rover,Orbiter: Link quality is variable.
    Orbiter-->>Rover: ACK for Tile 1 (Delayed)
    Orbiter--xRover: ACK for Tile 2 (Lost)
    Rover->>Rover: Agent Controller detects high latency/loss.
    Rover->>Rover: Decision: Increase compression for next tile.
    Rover->>Orbiter: Send Tile 3 (High Compression)

Axis 3: Cross-Domain Application

This axis applies the core streaming mechanism to three unrelated industries.

Derivative 3.1: Aerospace - Predictive Maintenance for Jet Engines

Enabling Description: The method is used to stream real-time sensor data from an operational jet engine to a ground-based maintenance system. The "content" is the continuous stream of telemetry from thousands of sensors. "Streamlets" are one-second blocks of sensor data. The "quality tiers" represent different data sampling rates (e.g., 1000 Hz, 100 Hz, 10 Hz). The aircraft's data gateway (the "client") uses the agent controller to monitor the satellite communication link. If the link is robust, it streams high-frequency data. If the link degrades, it automatically downshifts to a lower sampling rate, ensuring that a continuous, albeit lower-fidelity, data stream is always available for anomaly detection models on the ground.

Mermaid Diagram:

stateDiagram-v2
    [*] --> High_Bandwidth
    High_Bandwidth: Streaming 1000Hz Data
    High_Bandwidth --> Low_Bandwidth: Link Degradation Detected
    Low_Bandwidth: Streaming 100Hz Data
    Low_Bandwidth --> High_Bandwidth: Link Quality Restored
    Low_Bandwidth --> Critical_Mode: Severe Link Failure
    Critical_Mode: Streaming 10Hz "Heartbeat" Data
    Critical_Mode --> Low_Bandwidth: Link Partially Restored

Derivative 3.2: AgTech - Adaptive Irrigation Control

Enabling Description: A central farm management system uses the adaptive method to send control instructions to a fleet of IoT-enabled irrigation pivots over a mesh network with variable connectivity. The "content" is a high-resolution water application map for a field. "Streamlets" are control instructions for specific sectors of the field. The "quality tiers" correspond to the complexity of the instruction (e.g., Tier 1: precise Variable Rate Irrigation (VRI) command; Tier 2: simplified "average rate" command; Tier 3: binary "on/off" command). The irrigation pivot's controller monitors the signal strength from the mesh network. Based on connectivity, it requests either the precise VRI instructions or, if the link is poor, falls back to requesting simpler, lower-bandwidth commands to ensure the pivot continues to operate.

Mermaid Diagram:

graph TD
    A[Farm Mgmt Server] -- Generates --> B{VRI Map};
    B -- Encodes to --> C[Tier 1: Precise VRI];
    B -- Encodes to --> D[Tier 2: Average Rate];
    B -- Encodes to --> E[Tier 3: On/Off];
    F[Irrigation Pivot Controller] -- Monitors --> G((Mesh Network Quality));
    F -- Requests Instruction Streamlet --> A;
    A -- Sends Tier based on Quality --> F;
    F -- Executes Command --> H(Valves & Motors);

Derivative 3.3: Consumer Electronics - Dynamic Firmware Over-the-Air (FOTA) Updates

Enabling Description: A smart home device (e.g., a smart speaker) performs a firmware update using the adaptive-rate method. The "content" is the firmware image. The image is split into multiple "quality tiers," where the base tier contains critical bootloader and OS components, and higher tiers contain non-essential features, new language packs, or high-resolution UI assets. The device's update agent simultaneously requests multiple "streamlets" (blocks of the firmware file). It monitors the Wi-Fi connection. If the connection is unstable, it prioritizes completing the download of the base tier to ensure the device remains bootable. It will only request streamlets from the higher tiers (e.g., the new UI assets) when the network is stable, preventing a "bricked" device due to a failed update.

Mermaid Diagram:

flowchart LR
    subgraph Smart Speaker
        A(Update Agent) -- Monitors --> B(WiFi Quality);
        A -- Request Blocks --> C((Update Server));
    end
    subgraph Update Server
        D{Firmware Image};
        D --split--> E(Tier 1: Critical Core);
        D --split--> F(Tier 2: Feature Packs);
        D --split--> G(Tier 3: UI Assets);
    end
    C -- Serves Blocks --> A;
    B -- Poor Signal --> A;
    A -- Prioritize Tier 1 --> C;
    B -- Good Signal --> A;
    A -- Request Tiers 2 & 3 --> C;

Axis 4: Integration with Emerging Tech

This axis describes combining the core invention with AI, IoT, and blockchain.

Derivative 4.1: AI-Driven Predictive Rate Shifting

Enabling Description: The agent controller module is enhanced with a lightweight, on-device machine learning model (e.g., a recurrent neural network or LSTM) trained to predict future network bandwidth. The model uses a history of streamlet download times, time of day, device location (if available), and network type (WiFi/5G/LTE) as input features. Instead of reactively shifting based on past performance, the controller proactively requests a higher or lower quality streamlet based on the model's prediction of network conditions a few seconds into the future. This allows the player to "skate to where the puck is going," preventing buffering by downshifting before congestion occurs and improving quality by upshifting the moment the model predicts a stable improvement.

Mermaid Diagram:

sequenceDiagram
    participant Player
    participant ML_Model as On-Device ML Model
    participant Server
    loop Playback
        Player->>ML_Model: Input(History of Latencies, Time, Network Type)
        ML_Model-->>Player: Output(Predicted Bandwidth for t+5s)
        Player->>Player: Compare Predicted BW to Quality Tiers
        Player->>Server: Request streamlet from proactively chosen tier
        Server-->>Player: Streamlet Data
        Player->>Player: Update latency history
    end

Derivative 4.2: IoT Sensor Mesh for Context-Aware Streaming

Enabling Description: In a smart stadium or concert venue, the media player on a user's device subscribes to a local IoT sensor network that provides real-time data on Wi-Fi access point load and human crowd density. This contextual data is fed into the agent controller's decision algorithm. If the IoT network indicates the user is moving into an area with a historically congested access point, the agent controller preemptively lowers the streamlet quality, even if current download speeds are high. This avoids the inevitable buffering that would occur upon entering the congested zone, creating a smoother user experience based on hyper-local environmental conditions.

Mermaid Diagram:

graph TD
    A[User Device] -- Location --> B((Stadium IoT Network));
    B -- AP Load & Crowd Density --> A;
    subgraph User Device
        C[Agent Controller] -- Receives IoT Data --> D{Decision Logic};
        E[Network Monitor] -- Current BW --> D;
        D -- Combines Inputs --> F[Quality Tier Selection];
        F -- Issues Request --> G((CDN));
    end

Derivative 4.3: Blockchain for Verifiable Streamlet Provenance

Enabling Description: Each streamlet generated by the content server is cryptographically hashed, and its hash is recorded on a distributed ledger (blockchain). A "streamlet manifest," also on the ledger, maps time indexes to the official streamlet hashes for each quality tier. The client's staging module, after receiving a streamlet, verifies its hash against the manifest on the blockchain. This provides an immutable, auditable trail proving that the streamlets were not tampered with in transit (e.g., via a man-in-the-middle attack to inject malicious ads or content). This is particularly applicable to streaming legal depositions, medical procedures, or other content where authenticity and chain of custody are critical.

Mermaid Diagram:

erDiagram
    CONTENT_PROVIDER }|--|{ STREAMLET : generates
    STREAMLET {
        string hash PK
        string time_index
        string quality_tier
        binary data
    }
    STREAMLET ||--|{ BLOCKCHAIN_TRANSACTION : records
    BLOCKCHAIN_TRANSACTION {
        string tx_id PK
        string streamlet_hash FK
        timestamp block_time
    }
    CLIENT }o--|| STREAMLET : requests
    CLIENT {
        string client_id PK
    }
    CLIENT }o--|| BLOCKCHAIN_TRANSACTION : verifies

Axis 5: The "Inverse" or Failure Mode

This axis describes versions designed for safe failure or limited functionality.

Derivative 5.1: Graceful Degradation to Audio-Only Mode

Enabling Description: The system is designed with a lowest-possible "quality tier" that is audio-only. The agent controller's downshifting logic includes a final threshold for extremely poor or unstable network conditions. If the performance factor remains below this critical threshold for a sustained period (e.g., 10 seconds), the controller ceases all video streamlet requests and requests only the audio-only streamlets. The player UI displays a "Low-Bandwidth: Audio Only" message. This ensures the user can continue following the content's audio track (e.g., dialogue, commentary) without the frustrating experience of a constantly freezing video frame, providing a useful, predictable failure state.

Mermaid Diagram:

stateDiagram-v2
    state "Full Video" as Vid
    state "Audio Only" as Aud
    [*] --> Vid
    Vid --> Vid : Performance > Threshold
    Vid --> Aud : Performance drops below critical_threshold
    Aud --> Vid : Performance recovers above restore_threshold
    Aud --> Aud : Performance remains low

Derivative 5.2: "Lookahead-Only" Trick Play Mode

Enabling Description: To conserve battery and data on a mobile device, the player enters a low-power mode where the agent controller's behavior is inverted. Instead of continuously fetching a dense sequence of streamlets for linear playback, it only pre-fetches very low-quality "I-frame only" streamlets at sparse intervals (e.g., every 30 seconds). This populates the timeline bar with thumbnails for fast-forwarding and rewinding ("trick play"). The system does not attempt linear playback. Only when the user explicitly taps "play" does the agent controller switch back to its normal adaptive behavior, starting from the selected time index. This allows the user to browse content without consuming significant data or power.

Mermaid Diagram:

graph TD
    subgraph Low-Power Mode
        A(Agent Controller) -- Every 30s --> B(Request Low-Quality I-Frame);
        C((CDN)) -- I-Frame Streamlet --> D(Staging Module);
        D -- Thumbnail --> E(Player Timeline UI);
    end
    subgraph Active Playback
        F(Agent Controller) -- Adaptive Requests --> C;
        C -- Full Streamlets --> G(Staging Module);
        G -- For Playback --> H(Video Decoder);
    end
    E -- User Taps Play --> F;

Combination Prior Art with Open-Source Standards

Combination 1: MPEG-DASH Integration

Scenario: The method of US 8,868,772 is combined with the MPEG-DASH (Dynamic Adaptive Streaming over HTTP) standard. The server provides a standard Media Presentation Description (MPD) file, which lists the available quality tiers (Representations) and provides templates for generating streamlet URLs. The client's "agent controller module" parses the MPD file to identify the available streams. It then implements its core logic—simultaneously requesting multiple segments (streamlets), monitoring download times, and calculating a performance factor—to dynamically select which Representation to request for the next segment. The innovation of the patent is reduced to the specific heuristic for choosing among the standard options provided by the MPEG-DASH manifest.

Combination 2: WebRTC for P2P-Assisted Delivery

Scenario: The client-side player combines the adaptive streaming method with the WebRTC (Web Real-Time Communication) standard. The agent controller first attempts to request streamlets from a central CDN as described in the patent. Concurrently, it joins a WebRTC-based peer-to-peer mesh with other users watching the same content. The agent controller's monitoring function is expanded to track performance from both the CDN and its peers. The decision logic can now request the next streamlet from the source (CDN or a specific peer) that provides the best performance, while still using the overall performance metric to decide whether to upshift or downshift the quality tier for the next request, regardless of its source.

Combination 3: HTTP/3 and Application-Layer Protocol Negotiation (ALPN)

Scenario: The adaptive streaming method is implemented over HTTP/3 (which uses QUIC). The client uses Application-Layer Protocol Negotiation (ALPN) during the initial TLS handshake to inform the server that it supports a custom "adaptive-streamlet" protocol. The agent controller then uses a single HTTP/3 connection with multiple QUIC streams to request streamlets, as described in Derivative 1.2. The client can signal its calculated performance factor back to the server via custom HTTP headers. This allows the server to participate in the adaptive logic, for example, by preemptively pushing a lower-quality streamlet if the client signals a sudden drop in performance, combining the client-side logic of the patent with server-side assistance enabled by modern open protocols.