Derivative works — US Patent 11677798B2

Defensive Disclosure and Prior Art Publication

Publication Date: May 8, 2026
Reference ID: DDP-2026-7798
Title: Enhancements, Derivatives, and Novel Applications of Client-Side Adaptive Bitrate Streaming Algorithms
Keywords: Adaptive Bitrate Streaming (ABR), HTTP Live Streaming (HLS), MPEG-DASH, Quality of Experience (QoE), network performance estimation, predictive bitrate adaptation, volumetric video streaming, remote robotics, tele-operations, AI-driven networking.

This document discloses a series of methods, systems, and applications that build upon, extend, and re-contextualize the core technologies described in U.S. Patent 11,677,798 B2 (the '798 patent). The purpose of this disclosure is to place these concepts into the public domain, thereby establishing them as prior art for any future patent applications in these areas. The core inventive concept being expanded upon is a client-side method for adaptive bitrate streaming that involves monitoring streamlet receive times to calculate a performance factor and, critically, performing a sustainability check before upshifting to a higher quality stream.

Derivative Embodiments & Technical Disclosures

Axis 1: Material & Component Substitution

Derivative 1.1: Neuromorphic Processor-Based ABR for Edge AI Devices

Enabling Description: The ABR decision logic, including the performance factor (ρ) calculation and sustainability check, is offloaded from the primary CPU to a dedicated low-power neuromorphic processing unit (NPU) or AI accelerator (e.g., an Intel Loihi-style or IBM TrueNorth-style architecture). The time intervals between incoming streamlet packets trigger spike trains within the neuromorphic hardware. The network's state (ρ_current) is represented by the firing patterns and synaptic weights of a small, recurrent spiking neural network (SNN). The sustainability check for a higher bitrate is performed by inputting a hypothetical, higher-frequency spike train (representing the data rate of the higher quality stream) into the SNN and observing whether the network remains stable or enters a chaotic state, which would predict buffer underrun. This method reduces CPU load and power consumption on the client device, making it ideal for battery-powered edge devices.

Mermaid Diagram:

graph TD
    A[Network Interface] --Packet Arrival Timestamps--> B(Spike Train Generator);
    B --Input Spikes--> C{Spiking Neural Network on NPU};
    C --Current Firing Pattern--> D[Calculate ρ_current];
    D --> E{Decision Engine};
    subgraph Sustainability Check
        F(Hypothetical Spike Train Generator) --Higher Bitrate Pattern--> C;
        C --Predicted Firing Pattern--> G[Calculate ρ_higher_est];
    end
    G --> E;
    E --Upshift/Downshift/Maintain--> H[Streamlet Request Scheduler];
    H --Request Next Streamlet--> A;

Derivative 1.2: Volumetric and Light-Field Video Streaming Adaptation

Enabling Description: The concept of "streamlets" is adapted for non-traditional video formats. For volumetric video (e.g., meshes + textures) or light-field data, a "streamlet" is not a simple time-slice of video. Instead, it is a spatially and temporally coherent data chunk containing a base mesh and a set of enhancement layers (e.g., higher resolution textures, additional viewing angles, finer geometry). The ABR algorithm adapts by requesting different combinations of these layers. The sustainability check estimates whether the network can deliver not just a higher temporal bitrate, but a higher spatial data rate. For example, before upshifting, the client estimates if it can sustainably download the base mesh plus two high-resolution texture layers per time interval, based on the performance factor calculated from receiving the base mesh plus only one texture layer.

Mermaid Diagram:

sequenceDiagram
    participant Client
    participant Server

    loop Playback
        Client->>Server: Request BaseMesh_t1 + Texture_Low_t1
        Server-->>Client: Deliver(BaseMesh_t1 + Texture_Low_t1)
        Client->>Client: Monitor receive time, calc ρ_current
        Client->>Client: Sustainability Check: Est. time for (BaseMesh_t2 + Texture_High_t2)
        alt Sustainable
            Client->>Server: Request BaseMesh_t2 + Texture_High_t2
        else Not Sustainable
            Client->>Server: Request BaseMesh_t2 + Texture_Low_t2
        end
    end

Axis 2: Operational Parameter Expansion

Derivative 2.1: ABR for Deep-Space and Disrupted Communication Links

Enabling Description: The ABR algorithm is adapted for scenarios with extremely high latency (minutes, not milliseconds) and intermittent connectivity, such as communication with a Mars rover. The "streamlet" duration is significantly longer (e.g., 30-60 seconds of sensor data). The performance factor ρ calculation is heavily weighted towards long-term throughput and packet loss trends over dozens of prior streamlets, rather than instantaneous receive time intervals, to avoid reacting to transient solar flare interference. The sustainability check (ρ_higher > ρ_up) is modified to require a much larger safety margin; ρ_up is set to be at least 200-300% of the bitrate of the higher quality stream to ensure that an entire multi-minute data segment can be received before the next communication window closes.

Mermaid Diagram:

stateDiagram-v2
    [*] --> Stable_Low_Bandwidth
    Stable_Low_Bandwidth --> Attempting_Upshift: Long-term ρ > (3 * Bitrate_High)
    Attempting_Upshift --> Stable_High_Bandwidth: N consecutive streamlets received successfully
    Attempting_Upshift --> Stable_Low_Bandwidth: Packet loss > 5%
    Stable_High_Bandwidth --> Stable_Low_Bandwidth: Long-term ρ < (1.5 * Bitrate_High)
    Stable_Low_Bandwidth --> Connection_Lost: No signal for T > window_timeout
    Stable_High_Bandwidth --> Connection_Lost: No signal for T > window_timeout
    Connection_Lost --> Stable_Low_Bandwidth: Connection re-established

Derivative 2.2: Micro-burst ABR for Real-Time Industrial Control

Enabling Description: The technology is applied to an industrial automation network where a central controller streams command sequences to factory robots. In this context, "streamlets" are micro-bursts of control data, each with a playback duration of only 10-20 milliseconds. The entire system operates at the microsecond level. The ABR logic is implemented on a programmable network interface card (SmartNIC) to bypass kernel-level processing delays. The "bitrate" corresponds to the complexity of the command sequence (e.g., a low-rate stream is a simple "move-to-coordinate" command, while a high-rate stream includes complex pathing with real-time sensor feedback adjustments). The sustainability check is critical to prevent command buffer underruns, which could cause a robot to stall, damaging equipment. The performance factor is calculated based on round-trip-time (RTT) and jitter measurements of command acknowledgements.

Mermaid Diagram:

graph TD
    subgraph Central Controller
        A[Command Sequencer] --> B{ABR Logic on SmartNIC};
    end
    subgraph Robot
        D[Actuator Control] <-- C[Command Buffer];
    end
    B --"Streamlet (10ms command burst)"--> C;
    C --"ACK (with jitter/RTT data)"--> B;
    B --Calculates ρ and checks sustainability--> B;
    B --Selects High/Low Complexity Command--> A;

Axis 3: Cross-Domain Application

Derivative 3.1: Aerospace - Adaptive Telemetry Downlink from Hypersonic Vehicles

Enabling Description: During hypersonic flight testing, a vehicle generates massive amounts of telemetry (vibration, thermal, pressure, video). The wireless downlink channel is unstable due to atmospheric plasma and vehicle maneuvering. The ground control station acts as the client, requesting telemetry "streamlets." The ABR algorithm is used to dynamically adjust the resolution and frequency of the telemetry data being sent. A "low bitrate" stream might consist of down-sampled, time-averaged sensor readings. A "high bitrate" stream would provide raw, high-frequency data from all sensors. The sustainability check ensures that when the ground station requests higher-fidelity data during a critical flight phase, the communication link can actually support it, preventing loss of irreplaceable test data.

Mermaid Diagram:

sequenceDiagram
    participant GroundStation
    participant HypersonicVehicle

    GroundStation->>HypersonicVehicle: Request Telemetry (Low Fidelity)
    loop Flight Test
        HypersonicVehicle-->>GroundStation: Streamlet [AeroData_t1_low]
        GroundStation->>GroundStation: Calc ρ from receive interval
        alt Critical Maneuver Upcoming & Link is Stable
            GroundStation->>GroundStation: Sustainability check for High Fidelity
            alt Check Passes
                GroundStation->>HypersonicVehicle: Request Telemetry (High Fidelity)
                HypersonicVehicle-->>GroundStation: Streamlet [AeroData_t2_high]
            else Check Fails
                GroundStation->>HypersonicVehicle: Request Telemetry (Low Fidelity)
            end
        else
             GroundStation->>HypersonicVehicle: Request Telemetry (Low Fidelity)
        end
    end

Derivative 3.2: AgTech - Coordinated Drone Swarm Data Offload

Enabling Description: A swarm of agricultural drones collects hyperspectral imaging data over a large farm. The drones must periodically offload this data to a mobile edge computing (MEC) server in the field. The MEC server acts as the client, managing simultaneous incoming streams from multiple drones. It runs a separate instance of the ABR algorithm for each drone. Based on the signal strength and link quality of each drone (which changes as they fly), the MEC server requests either a compressed, low-resolution "preview" streamlet or a full-resolution, raw data streamlet. The sustainability check prevents the MEC from requesting high-resolution data from too many drones simultaneously, which would saturate its own wireless backhaul or processing capacity.

Mermaid Diagram:

graph TD
    D1(Drone 1) --Stream 1--> M{MEC Server};
    D2(Drone 2) --Stream 2--> M;
    DN(Drone N) --Stream N--> M;
    subgraph MEC Server
        M --> ABR1(ABR Instance for D1);
        M --> ABR2(ABR Instance for D2);
        M --> ABRN(ABR Instance for DN);
        ABR1 --Request High/Low Res--> D1;
        ABR2 --Request High/Low Res--> D2;
        ABRN --Request High/Low Res--> DN;
        ABR1 & ABR2 & ABRN --> C(Global Capacity Manager);
        C --Adjusts ρ_up thresholds for all ABR instances--> ABR1 & ABR2 & ABRN;
    end
    M --Aggregated Data--> Cloud;

Derivative 3.3: Telemedicine - Remote Robotic Surgery Haptic Feedback Control

Enabling Description: A surgeon uses a haptic interface to control a remote surgical robot. The system relies on multiple data streams: 4K video from endoscopes, robot positional data, and high-frequency haptic feedback data sent from the robot back to the surgeon. The surgeon's console (the client) uses the ABR algorithm to manage the haptic feedback stream. A "high bitrate" haptic stream provides detailed, nuanced force feedback, while a "low bitrate" stream provides coarser, less responsive feedback. Latency is paramount. The sustainability check is used before upshifting the haptic quality to ensure the network can handle the increased data rate without introducing jitter or latency spikes, which could cause the surgeon to make a dangerous error. In this application, the algorithm prioritizes minimizing latency over maximizing throughput.

Mermaid Diagram:

sequenceDiagram
    participant SurgeonConsole
    participant SurgicalRobot

    loop Operation
        SurgeonConsole->>SurgicalRobot: Send Control Command
        SurgicalRobot-->>SurgeonConsole: Stream Haptic Data (Streamlet)
        SurgeonConsole->>SurgeonConsole: Calculate ρ based on haptic packet jitter & latency
        alt Latency is low & stable
            SurgeonConsole->>SurgeonConsole: Sustainability check for higher fidelity haptics
            alt Check Passes
                SurgeonConsole->>SurgicalRobot: Request High-Fidelity Haptic Stream
            end
        else
            SurgeonConsole->>SurgicalRobot: Request Low-Fidelity Haptic Stream
        end
    end

Axis 4: Integration with Emerging Tech

Derivative 4.1: AI-Driven Predictive Sustainability Analysis

Enabling Description: The rule-based sustainability check of the '798 patent is replaced by a predictive model (e.g., a Long Short-Term Memory (LSTM) network) running on the client. This model is trained on vast datasets of network performance. Its inputs include not just the recent history of streamlet receive times, but also contextual data: time of day, geographic location (via GPS), network type (Wi-Fi, 5G, LTE), current cell tower load (if available via APIs), and device mobility (from accelerometer data). The model doesn't just estimate ρ_higher; it predicts a probability distribution of ρ_higher over the next N seconds. The client upshifts only if the probability of the future performance factor remaining above the ρ_up threshold for the duration of the next several streamlets is greater than a confidence value (e.g., 95%).

Mermaid Diagram:

graph TD
    subgraph Client Device
        A[Network Stats] --> M;
        B[Context Sensors: GPS, WiFi/5G Radio, Time] --> M;
        M(LSTM Predictive Model) --"P(ρ_future > ρ_up) > 95%?"--> D{Decision Logic};
        D --Upshift--> R[Request Higher Bitrate Streamlet];
        D --Maintain/Downshift--> S[Request Current/Lower Bitrate Streamlet];
    end

Derivative 4.2: IoT-Informed ABR for Mobile Environments

Enabling Description: The ABR algorithm is enhanced with real-time data from on-device IoT sensors to preemptively adapt to network changes. For example, the client's GPS detects the user is entering a tunnel or an area with known poor cellular coverage. This information is fed to the decision engine, which will preemptively downshift the stream quality before the performance factor ρ degrades, ensuring uninterrupted playback. Similarly, an accelerometer detecting that the user is running or on a high-speed train will cause the algorithm to become more conservative in its upshifting decisions, anticipating frequent network hand-offs and instability. The sustainability check now includes a "mobility penalty" that artificially raises the ρ_up threshold when the device is in motion.

Mermaid Diagram:

flowchart LR
    subgraph Inputs
        A[Streamlet Receive Times];
        B[GPS Sensor];
        C[Accelerometer];
        D[WiFi/Cellular Signal Sensor];
    end

    subgraph ABR Logic
        E[Calculate ρ_current];
        F[Calculate Mobility Penalty];
        G["ρ_up_adjusted = ρ_up + Mobility Penalty"];
        H{"Sustainability Check: ρ_higher_est > ρ_up_adjusted?"};
    end

    A --> E;
    B & C & D --> F;
    E --> H;
    F --> G --> H;
    H --Yes--> I[Upshift];
    H --No--> J[Do Not Upshift];

Axis 5: The "Inverse" or Failure Mode

Derivative 5.1: Graceful Degradation to "Story-Mode" Stream

Enabling Description: This derivative defines a "failsafe" mode for when network conditions become unusable. If the performance factor ρ drops below a critical threshold (ρ_critical) for a sustained period (e.g., 10 seconds), the client abandons the multi-bitrate video streams entirely. It instead requests a special "Story-Mode" streamlet. This is a very low-bandwidth, pre-packaged streamlet containing a series of still images (keyframes) from the video, synchronized with the full-quality audio track and subtitles. This provides a "visual radio play" experience, allowing the user to follow the plot without frustrating buffering of unwatchable video. The client will only attempt to switch back to a normal video stream after ρ has recovered and remained stable above a recovery threshold for at least 30 seconds.

Mermaid Diagram:

stateDiagram-v2
    state "Normal ABR" as ABR
    state "Story Mode (Audio + Stills)" as Story
    [*] --> ABR
    ABR --> Story : ρ_current < ρ_critical for >10s
    Story --> ABR : ρ_current > ρ_recovery for >30s
    ABR: Client requests video streamlets at various bitrates.
    Story: Client requests special streamlets with audio and keyframes only.

Derivative 5.2: QoS-Aware Power-Saving ABR

Enabling Description: The ABR algorithm's objective function is inverted from "maximize quality" to "minimize energy consumption for a user-defined Quality of Service (QoS) level". The user selects a mode like "Battery Saver" or "Max Quality". In "Battery Saver" mode, the client determines the lowest possible bitrate that meets a minimum resolution and framerate target (e.g., 480p at 24fps). It will only stream at this bitrate, even if the network could support 4K. It will only upshift temporarily if the application detects a specific user action, such as engaging fullscreen mode. The sustainability check is repurposed to be a "necessity check": is an upshift required to meet the current QoS target? This is particularly useful for background audio playback of video content, where the video stream can be reduced to the lowest possible bitrate without affecting the user experience.

Mermaid Diagram:

graph TD
    U[User sets mode: Battery Saver/Max Quality] --> P{ABR Policy Engine};
    N[Network Performance (ρ)] --> D{Decision Logic};
    P --Sets QoS Floor/Ceiling--> D;
    D --> R{Request Streamlet};
    subgraph "Decision Logic (Battery Saver Mode)"
        S1{Is ρ > ρ_for_QoS_Floor?} --> S2{Is current bitrate < QoS_Floor?};
        S2 --Yes--> S3[Upshift to meet Floor];
        S2 --No--> S4[Maintain lowest possible rate];
    end
    R --> N;

Combination Prior Art Scenarios

1. Integration with MPEG-DASH using a Custom Adaptation Set Profile:

Enabling Description: A new profile or scheme is defined for the MPEG-DASH Media Presentation Description (MPD) manifest. Within an AdaptationSet, a custom XML element, <DishABR SustainabilityCheck="true" RhoUpFactor="1.5"/>, is introduced. A DASH-compliant client that recognizes this scheme will, upon parsing the MPD, discard its default ABR heuristic (e.g., simple buffer-based or throughput-based logic). It will instead instantiate the specific ABR algorithm from the '798 patent, using the time intervals between received DASH segments to calculate ρ_current. The RhoUpFactor attribute from the MPD is used to dynamically set the ρ_up threshold, allowing the content provider to tune the aggressiveness of the upshifting logic on a per-content basis.

2. Integration into the WebRTC Stack for Peer-to-Peer Quality Management:

Enabling Description: The core logic of monitoring receive intervals and performing a sustainability check is implemented directly within the RTCPeerConnection object in a web browser's WebRTC implementation. For a multi-party video conference, each participant's browser acts as a client for every other participant's stream. The browser continuously monitors the arrival times of incoming RTP packets for each peer's stream to calculate a unique ρ for each peer-to-peer link. Before requesting a higher resolution video layer from a specific peer (via RTCP REMB or Transport-CC feedback messages), it performs the sustainability check. This prevents a single client with a good connection from requesting high-quality streams from all peers, potentially overwhelming its own downlink capacity.

3. Implementation over the QUIC Transport Protocol:

Enabling Description: The client-server streaming session is established using the QUIC protocol instead of TCP+TLS. Each streamlet is requested over a separate QUIC stream, taking advantage of QUIC's multiplexing and lack of head-of-line blocking. The ABR algorithm is tightly integrated with the transport layer. Instead of only measuring application-level streamlet receive times, the performance factor ρ is calculated using a richer set of metrics directly available from the QUIC transport state, including min/max RTT, RTT variance, congestion window size (cwnd), and the rate of QUIC ACK frame reception. The sustainability check for a higher bitrate B_high is performed by a formula that explicitly models the required cwnd to support B_high given the current RTT variance, providing a more accurate prediction than an application-layer-only heuristic.