Derivative works — US Patent 10880592

Defensive Disclosure: Derivative Embodiments and Integrations

Publication Date: May 9, 2026
Reference Patent: US 10880592
Abstract: This document discloses a series of derivative inventions and technical variations based on the core claims of US patent 10,880,592 ("the '592 patent"). The purpose of this disclosure is to place these variations, extensions, and combinations into the public domain, thereby establishing them as prior art against future patent applications claiming these incremental improvements as novel. The descriptions are intended to be enabling for a Person Having Ordinary Skill in the Art (PHOSITA).

Derivatives Based on Claim 1: Content Control Information Management

The core concept of Claim 1 is a receiving apparatus that designates content, stores a re-selection identifier, and automatically obtains and links control information (e.g., availability) from the content source.

1.1. Component Substitution: Decentralized and Low-Power Architecture

Enabling Description: The function of the "second unit" for storing content identifiers is implemented using a distributed hash table (DHT) or content-addressed storage, such as the InterPlanetary File System (IPFS). The identifier is an IPFS Content Identifier (CID) rather than a server-dependent URL. The "third unit," responsible for fetching control information, is instantiated as a dedicated microservice on a low-power RISC-V or ARM Cortex-M-series core. This service uses the Constrained Application Protocol (CoAP) with Observe functionality to subscribe to metadata updates from the content source, minimizing power consumption compared to continuous HTTP polling. The control information itself, such as an expiration timestamp, is cryptographically signed by the provider and stored alongside the CID.

Diagram:

graph TD
    subgraph Receiving Apparatus
        A[Main CPU/OS] -- Designates Content --> B(IPFS Node);
        B -- Stores CID --> C{Distributed Storage};
        D[Low-Power Core] -- Runs CoAP Client --> E{Content Source Metadata API};
        E -- Pushes Signed Metadata --> D;
        D -- Links Metadata to CID --> C;
        A -- Reads CID & Metadata --> C;
    end
    style D fill:#f9f,stroke:#333,stroke-width:2px

1.2. Operational Parameter Expansion: Industrial SCADA Integration

Enabling Description: The system is applied to an industrial control (SCADA) environment for managing power grid assets. The "digital content" is a real-time power generation profile from a wind farm, and the "outside source" is the farm's control system API. The "first unit" designates the farm's SCADA endpoint. The "third unit" automatically queries a predictive analytics API, which provides a 48-hour forecast of the farm's operational availability and power output, serving as the "control information." If the forecast indicates upcoming maintenance (a form of "time limit"), the receiving apparatus, which acts as a grid load balancer, automatically schedules charging cycles for a connected battery storage facility to compensate for the anticipated downtime.

Diagram:

sequenceDiagram
    participant LB as Load Balancer ('592 Apparatus)
    participant PA as Predictive API
    participant WF as Wind Farm SCADA
    LB->>WF: Designate Content (Select Farm)
    LB->>PA: Query Control Info (Get Forecast)
    PA-->>LB: Return Forecast (Maintenance at T+24h)
    LB->>LB: Link Forecast to Farm Endpoint
    LB->>Battery: Schedule Charging Cycle before T+24h

1.3. Cross-Domain Application: Aerospace Digital Twin

Enabling Description: In an avionics system for predictive maintenance, the "receiving apparatus" is an onboard maintenance computer. The "digital content" is the digital twin model for a specific, serialized aircraft component (e.g., a turbine blade with serial number X). The "second unit" stores the component's unique identifier. The "third unit" automatically establishes a secure, encrypted connection to the manufacturer's ground server to query for updated service bulletins or revised operational lifetime limits ("control information") specific to serial number X. This control data is linked to the digital twin model, and if a new, shorter lifetime is published, the system automatically elevates the priority of maintenance alerts.

Diagram:

classDiagram
  class OnboardComputer {
    +designateComponent(componentID)
    +storeIdentifier(componentID)
    +queryControlInfo(componentID)
  }
  class DigitalTwinModel {
    <<Service>>
    -componentID
    -operationalData
    -controlInfo
  }
  class ManufacturerServer {
    <<External>>
    +getServiceBulletin(componentID)
  }
  OnboardComputer --> DigitalTwinModel : Manages
  OnboardComputer --> ManufacturerServer : Queries

1.4. Integration with Emerging Tech: AI-Predicted Content Expiration

Enabling Description: The "third unit" is enhanced with an AI module executing a predictive model (e.g., a recurrent neural network or transformer model). Instead of merely fetching a deterministic expiration date from the provider, this module analyzes a wide range of features: content genre, provider's historical content removal patterns, viewership telemetry, and social media sentiment. Based on this analysis, it predicts a "Probabilistic Unavailability Window" for the designated content, even in the absence of an official notice. This control information is stored and used to proactively trigger a download of the content if the probability of removal exceeds a user-defined threshold (e.g., 75% chance of removal within 30 days).

Diagram:

graph LR
    A[Content Provider API] -- Official Expiration Date --> C{Control Info Processor};
    B[Telemetry & Social APIs] -- Raw Data --> D[AI Predictive Model];
    D -- Probabilistic Unavailability --> C;
    subgraph 'Third Unit'
        C -- Fused Control Info --> E(Link to Content ID);
    end

1.5. Inverse/Failure Mode: Graceful Degradation and Preservation

Enabling Description: The system is designed to handle failures in obtaining control information. If the "third unit" fails to connect to the outside source after a defined number of retries (e.g., 5 attempts over 24 hours), it enters a "Stale" state. In this state, the content is still accessible, but the user interface displays a visual indicator (e.g., a yellow warning icon) signifying that availability is unconfirmed. If failures persist for an extended period (e.g., 7 days), the system transitions to a "Preservation" state. It assumes the content is at high risk of deletion and, as per dependent claims of the '592 patent, automatically initiates a download. To conserve resources, this download uses the lowest available bitrate and is scheduled for off-peak network hours.

Diagram:

stateDiagram-v2
    [*] --> Active
    Active: Control info is current.
    Active --> Stale: on (Query Fails > 5 times)
    Stale: UI shows availability warning.
    Stale --> Active: on (Query Succeeds)
    Stale --> Preservation: on (Query Fails for > 7 days)
    Preservation: Low-bitrate download initiated.
    Preservation --> Active: on (Query Succeeds)
    Preservation --> [*]: on (Download Completes)

Derivatives Based on Claim 6: Power-Cycle Content Resumption

The core concept of Claim 6 is an apparatus that saves the state of video playback upon being turned off and automatically resumes playback upon being turned on.

2.1. Component Substitution: Instantaneous State-Save to NVRAM

Enabling Description: The "second unit" utilizes non-volatile memory, specifically Magnetoresistive RAM (MRAM) or NVRAM, for near-instantaneous state saving. The power-off signal, detected by a microcontroller from the IR receiver, triggers a direct memory access (DMA) transfer of the playback state (content identifier, stream position, and audio track selection) to the MRAM. This operation bypasses the main operating system's shutdown procedure, ensuring the state is saved even if the OS is unstable. Upon power-on, the system's bootloader (e.g., UEFI) has an early-stage module that reads this MRAM location and initiates a network request to pre-buffer the content before the full user interface loads, creating a near-instantaneous resumption experience.

Diagram:

sequenceDiagram
    participant IR as IR Receiver
    participant MCU as Microcontroller
    participant MRAM as 'Second Unit'
    participant CPU as Main CPU/OS
    participant Bootloader as UEFI/BIOS

    IR->>MCU: Power-Off Signal Detected
    MCU->>CPU: Initiate DMA Transfer of State
    CPU->>MRAM: Write Playback State
    CPU->>MCU: Acknowledge State Saved
    MCU->>Power Mgmt: Execute Power-Off

    Note over Bootloader, MRAM: On next power-on...
    Bootloader->>MRAM: Read Playback State
    Bootloader->>Network: Pre-buffer content
    Bootloader->>CPU: Load Main OS with resume info

2.2. Cross-Domain Application: Autonomous Agricultural Vehicle

Enabling Description: An autonomous tractor uses this mechanism for task resumption. The "digital moving image content" is an operational task plan, such as a precision fertilizing map. The "manually operable unit" is the emergency stop button. When the stop button is engaged ("turned off"), the tractor's control unit ("second unit") immediately saves its state: precise GPS coordinates, task progress (e.g., last completed row), and the current settings of all implements (e.g., fertilizer flow rate). When the system is re-engaged ("turned on"), it automatically re-designates the saved task state, moves the implements to their saved positions, and prompts the operator to confirm resumption, ensuring no part of the field is missed or over-applied.

Diagram:

graph TD
    A[Emergency Stop Pressed] --> B{Save State};
    B -- GPS Coordinates --> C[NVRAM];
    B -- Task Map Progress --> C;
    B -- Implement Settings --> C;
    D[System Re-Engaged] --> E{Load State};
    E -- Reads All Data --> C;
    E --> F[Prompt Operator: "Resume Task?"];
    F -- Confirmed --> G[Resume Operation];

2.3. Integration with Emerging Tech: IoT-Based Presence Detection

Enabling Description: The "manually operable unit" is abstracted to be a logical power state controlled by an IoT presence-sensing system. The receiving apparatus is tied into a smart home hub. When the user's wearable device (e.g., smartwatch or BLE beacon) leaves a defined geofence around the room, the hub sends a "power-off" command. The apparatus saves its playback state and enters a standby mode. When the user re-enters the geofenced area, the hub sends a "power-on" command, causing the apparatus to wake and automatically resume playback from the saved state without any manual interaction with a remote control.

Diagram:

stateDiagram-v2
    state "User Present" as Present
    state "User Absent" as Absent

    [*] --> Absent
    Present: Content playing.
    Absent: Apparatus in standby.

    Absent --> Present: on (User Enters Geofence) / Power On & Resume
    Present --> Absent: on (User Exits Geofence) / Save State & Power Off

Derivatives Based on Claim 12: Scheduled Content "Start-Over"

The core concept of Claim 12 is allowing a user who tunes into a scheduled broadcast mid-stream to view a part of the program that has already aired.

3.1. Component Substitution: Network-Side Proxy Implementation

Enabling Description: The "controller unit" functionality is offloaded from the client device to a network-side proxy server operated by the content provider. The client device is a lightweight appliance that tunes to a standard multicast IP stream for live viewing. When the user activates the "start-over" function, the client sends a simple API call to the proxy. The proxy server then terminates the multicast feed for that client and initiates a unicast HTTP Live Streaming (HLS) session, serving the content from the beginning from a rolling buffer stored on a high-throughput storage cluster (e.g., Ceph). This architecture removes the need for any significant storage or processing capability on the end-user's device.

Diagram:

sequenceDiagram
    participant User
    participant ClientDevice
    participant ProxyServer
    participant StorageCluster

    ClientDevice->>ProxyServer: Join Live Multicast Stream
    User->>ClientDevice: Press "Start-Over"
    ClientDevice->>ProxyServer: API Call: startOver(contentID)
    ProxyServer->>StorageCluster: Request HLS playlist from T=0
    StorageCluster-->>ProxyServer: Return Playlist
    ProxyServer-->>ClientDevice: Start Unicast HLS Stream

3.2. Integration with Emerging Tech: AI-Generated "Smart Chapters"

Enabling Description: The "controller unit" incorporates a real-time AI event detection engine that processes the live broadcast. For a sports event, this engine identifies key moments (goals, penalties, etc.) by analyzing video frames and audio commentary. For a news broadcast, it identifies topic changes. These events are timestamped and used to generate a dynamic "smart chapter" list. When a user tunes in mid-stream, the interface displays not just a "start-over" button, but a list of these chapters (e.g., "Goal at 15:32," "Topic: Market Update at 22:10"). The user can select one of these chapters to view a specific "second part" of the content that has already been provided, offering a more granular and meaningful catch-up experience.

Diagram:

graph TD
    subgraph Cloud Service
        A[Live Broadcast Ingest] --> B(AI Event Detection);
        B -- Timestamped Events --> C{Metadata Server};
    end
    subgraph Client Device
        D[Player Tuned to Live Stream]
        E[Controller Unit] --> C: Fetches Chapters;
        E --> F[UI Display];
        F -- Presents --> G["Chapter 1: Goal @ 15:32"];
        F -- Presents --> H["Chapter 2: Red Card @ 31:05"];
    end

3.3. Inverse/Failure Mode: Live-Only Graceful Degradation

Enabling Description: The system is designed for high availability of the live stream, with the "start-over" feature being a secondary enhancement. The "controller unit" constantly monitors the health of its connection to the archival storage system that holds the "second part" (the already-aired content). If this connection is lost or experiences high latency, the controller unit immediately disables the start-over, rewind, and pause functions in the user interface. The UI elements are grayed out, and a small, non-intrusive icon appears, indicating that "Live viewing only" is available. This prevents a negative user experience of failed commands and clarifies the system's current state, degrading gracefully to a traditional linear broadcast experience.

Diagram:

stateDiagram-v2
    state "Full Functionality" as Full
    state "Live-Only Mode" as LiveOnly

    [*] --> Full
    Full: Start-over/Rewind enabled.
    LiveOnly: Start-over/Rewind UI disabled.

    Full --> LiveOnly: on (Archive Connection Lost)
    LiveOnly --> Full: on (Archive Connection Restored)

Combination Prior Art Scenarios with Open Standards

Combination with HLS (HTTP Live Streaming): The functionality of Claim 12 ("start-over") is implemented by leveraging the open HLS standard. A provider's live stream uses a DVR-style rolling manifest file (.m3u8). When a client tunes in, it receives the live manifest. To "start over," the client's "controller unit" simply seeks to the beginning of the manifest's available window and plays the video chunks (.ts files) from that point. Furthermore, control information from Claim 1, such as a content expiration date, is embedded as a custom tag (e.g., #EXT-X-EXPIRATION-DATE:2027-12-31T23:59:59Z) within the manifest. Any HLS-compliant player can be programmed to parse this tag and trigger a download or display a warning as the date approaches.
Combination with Matter (Smart Home Standard): The "turn on/off" and state resumption functionality of Claim 6 is integrated directly into the open Matter smart home protocol. The television is a Matter-compliant device. Its playback state (e.g., a JSON object containing {"contentId": "...", "timestamp": 1234.5}) is stored as a custom attribute within a standardized Matter Media Playback cluster. A "power off" event, triggered by a physical remote or another Matter device (e.g., a "Goodnight" scene), causes the TV's Matter endpoint to write the current playback state to this attribute before entering standby. Upon power-on, the TV's firmware reads this attribute as part of its initialization and automatically resumes playback.
Combination with ActivityPub (Decentralized Social Networking): The principles of Claim 1 are applied to a decentralized video platform like PeerTube, which utilizes the ActivityPub protocol. A user's PeerTube instance follows another instance's channel (this acts as the designation by the "first unit"). The "second unit" stores the channel's ActivityPub actor URL. The "third unit" is a background process that listens for Update or Delete activities sent from the followed channel. These activities serve as the "control information." If a Delete activity for a specific video is received, and that video is bookmarked by the user, the user's instance can automatically trigger a preservation download (mirroring) of the content before it becomes unavailable on the originating instance.