Derivative works — US Patent 8191091

Here is a Defensive Disclosure based on U.S. Patent No. 8,191,091.

Defensive Disclosure: Methods and Systems for Personalized and Controlled Information Distribution

Publication Date: May 10, 2026

Abstract: This document discloses a series of methods, systems, and applications that expand upon the concept of embedding data and control signals within a primary information broadcast. These disclosures are intended to enter the public domain to serve as prior art for future patent applications. The disclosed variations cover component substitutions, expansions of operational parameters, novel cross-domain applications, integration with emerging technologies such as artificial intelligence and blockchain, and fail-safe operational modes. The core principle involves a one-to-many broadcast signal containing instructions that are processed by remote receiver units, which then combine the broadcast information with local data or conditions to produce a personalized or controlled output.

Part 1: Derivatives for Personalized Information Display on a Broadcast Signal

This section details variations on the concept of using embedded data in a broadcast (e.g., television) to generate user-specific graphical or textual overlays.

1.1. Software-Defined Radio (SDR) and Web-Based Overlay Rendering

Enabling Description: A signal processing apparatus is configured with a Software-Defined Radio (SDR) front-end connected via a USB interface to a general-purpose computing device. The SDR is programmed to tune to a specific broadcast frequency (e.g., an ATSC 3.0 channel) and demodulate the entire transport stream. A software-based demultiplexer isolates the primary audio/video (A/V) streams and a separate data-over-broadcast stream (e.g., an IP multicast stream encapsulated within the broadcast). This data stream contains control signals and content, such as HTML5, CSS, and JavaScript code. The computing device renders the primary A/V stream in a video player window, while a co-located embedded browser engine (e.g., Chromium Embedded Framework) executes the received web code. This code, using locally stored user data (e.g., profile information from a JSON file or IndexedDB), generates a transparent HTML5 canvas overlay that is precisely positioned and synchronized over the video player window, creating a combined, personalized display.

Mermaid Diagram:

graph TD
    A[Broadcast Tower] -->|ATSC 3.0 Signal| B(SDR Receiver);
    B --> C{General-Purpose Computer};
    C --> D[Software Demultiplexer];
    D -->|A/V Streams| E[Video Player];
    D -->|HTML5/JS Data Stream| F[Embedded Browser Engine];
    G[Local User Data Store] <-- Local API Call --> F;
    F --> H{Rendered HTML5 Canvas};
    E & H ==> I[Synchronized Display];

1.2. Augmented Reality (AR) Overlay for High-Frequency Data Streams

Enabling Description: During a live broadcast of a motorsport event, a high-frequency, low-latency data stream is embedded within the video signal's metadata packets (e.g., SMPTE 2110 ancillary data). This stream contains real-time telemetry from multiple vehicles, including GPS coordinates, speed, gear, and engine RPM, with each packet time-stamped with a PTP (Precision Time Protocol) value. At the receiver, a dedicated hardware-accelerated processing unit (e.g., a GPU or FPGA) decodes the video and extracts the telemetry data. This data is fed into a 3D rendering engine. The user, wearing an AR headset that is displaying the live video feed, sees a real-time, 3D holographic overlay of the telemetry data (e.g., a "ghost" car showing a previous lap, speed gauges floating over the vehicle) that is precisely synchronized with the on-screen action. The user can select which vehicle's data to display via a remote control interface.

Mermaid Diagram:

sequenceDiagram
    participant Broadcast as Broadcast Source
    participant Receiver as AR Headset
    participant GPU as GPU/FPGA
    participant Renderer as 3D Rendering Engine

    loop Real-time Telemetry
        Broadcast->>Receiver: Video Frame + Embedded Telemetry Packet
        Receiver->>GPU: Offload Frame and Packet
        GPU->>Renderer: Decode Video and Extract Telemetry Data
        Renderer->>GPU: Render 3D AR Overlay
        GPU->>Receiver: Composite Video + AR Overlay
    end

1.3. AI-Driven Contextual Information Generation

Enabling Description: A broadcast network embeds semantic metadata tags (e.g., "Scene: Interior, Dialogue", "Actors: John Doe, Jane Smith", "Topic: Economics") into the closed-captioning data track of a television program. At the receiver, a local, edge-based AI model (such as a compact large language model or a computer vision model) running on a neural processing unit (NPU) parses these tags. When a user activates an "info mode," the AI cross-references the tags with a local knowledge base (e.g., Wikipedia dump, user's browsing history). The AI then generates a contextually relevant, non-intrusive informational overlay. For example, if "John Doe" is tagged, the AI generates a brief on-screen biography. If "Economics" is tagged, it might display a real-time stock ticker for related companies, pulled from a separate internet-based data feed. The user can interact with the AI via voice commands to request deeper information, with the AI generating new overlays in response.

Mermaid Diagram:

graph TD
    subgraph Broadcast Head-End
        A[Program Content] --> B{Semantic Tagger};
        B --> C[Encoder];
    end
    subgraph Receiver Device
        D[Tuner/Decoder] --> E{Tag Extractor};
        E --> F[Edge AI Processor];
        G[Local Knowledge Base] --> F;
        H[Internet Data API] --> F;
        I[Voice Input] --> F;
        F --> J{Overlay Generator};
        K[Video Plane] --> L((Display));
        J --> L;
    end
    C --> D;

1.4. Application in Smart Agriculture (AgTech)

Enabling Description: A regional satellite service broadcasts weather data, commodity market prices, and regional pest alerts over a wide area. This broadcast signal includes embedded control instructions. An AgTech receiver unit, located at a farm, is equipped with a solar-powered computer and sensors for soil moisture, temperature, and nutrient levels. The receiver decodes the broadcast. A local control application uses the received regional data (e.g., "heavy rain expected in 2 hours") in conjunction with its local sensor data (e.g., "soil moisture at 40%") to make decisions. It generates an overlay on a display in the farm office, showing the satellite weather map with a color-coded representation of the farm's own soil moisture levels, and displays a recommendation like "Postpone scheduled irrigation for Sector 4." If authorized, it can also send control signals to automated irrigation equipment.

Mermaid Diagram:

flowchart LR
    subgraph SatelliteBroadcast
        direction TB
        A[Weather Data]
        B[Market Data]
        C[Control Signals]
    end

    subgraph FarmReceiver
        direction TB
        D(Receiver/Decoder)
        E{Local Processor}
        F[Local Sensors]
        G[Display]
        H[Irrigation Controller]
    end

    SatelliteBroadcast -- Encoded Signal --> D
    D -- Decoded Data --> E
    F -- Sensor Readings --> E
    E -- Generates Personalized Overlay --> G
    E -- Issues Control Command --> H

1.5. Graceful Degradation and Fail-Safe Overlay Mode

Enabling Description: A system is designed to provide personalized overlays on public transport displays. The broadcast data stream contains three tiers of information for each message: 1) a full-motion video advertisement, 2) a static image version of the ad, and 3) a plain-text-only version. The local display controller continuously monitors its own health, including CPU temperature, available memory, and network connectivity status. Under normal operation, it displays the full-motion video. If the CPU temperature exceeds a predefined threshold (e.g., 85°C), it automatically switches to displaying only the static image to reduce processing load. If it detects a critical error in the video decoder module, it switches to the fail-safe text-only mode, ensuring that essential information (e.g., "Next Stop: Main Street") is always displayed. An embedded "heartbeat" signal is expected from the broadcast; if this signal is lost for more than 60 seconds, the display reverts to a pre-loaded default schedule stored in non-volatile memory.

Mermaid Diagram:

stateDiagram-v2
    [*] --> Normal: System Boot
    Normal: Displaying Full-Motion Video
    Normal --> Degraded_Image: CPU Temp > 85°C
    Normal --> FailSafe_Text: Decoder Fault
    Normal --> Offline: Heartbeat Lost > 60s
    Degraded_Image: Displaying Static Image
    Degraded_Image --> Normal: CPU Temp < 75°C
    Degraded_Image --> FailSafe_Text: Decoder Fault
    Degraded_Image --> Offline: Heartbeat Lost > 60s
    FailSafe_Text: Displaying Plain Text
    FailSafe_Text --> Normal: System Reset
    Offline: Displaying Default Schedule
    Offline --> Normal: Heartbeat Restored

Part 2: Derivatives for Hierarchical Distribution and Control

This section details variations on a system where a central station broadcasts a signal that can be modified by intermediate stations and used to control end-user equipment.

2.1. Dynamic Ad Insertion Using Geofenced Control Signals

Enabling Description: A national television network broadcasts a single satellite feed across the country. The feed contains the primary program content and a SCTE-35 compliant data stream with splice markers. In addition, a separate, encrypted data channel within the feed carries a catalog of advertisement metadata, including unique ad IDs, advertiser rules, and associated geofence coordinates (polygons of latitude/longitude). Local cable head-ends or Low Power TV (LPTV) transmitters receive this feed. Their signal processing apparatus decrypts the ad catalog. Based on its own known geographical location, the local station filters the catalog for ads approved for its area. When a SCTE-35 splice-out point is detected in the primary feed, the local apparatus automatically inserts a selected local ad from its cache, then splices back into the network feed at the corresponding splice-in point. This allows for hyper-local advertising without altering the primary network feed.

Mermaid Diagram:

sequenceDiagram
    participant Superstation
    participant LocalStation
    participant AdServer
    participant Viewer
    Superstation->>LocalStation: Program Feed with SCTE-35 markers
    Superstation->>LocalStation: Encrypted Ad Catalog (with geo-data)
    LocalStation->>AdServer: Request local ads based on geo-filter
    AdServer-->>LocalStation: Local Ad Content
    loop Program
        LocalStation->>LocalStation: Detect SCTE-35 Splice-Out
        LocalStation->>Viewer: Insert Local Ad
        LocalStation->>LocalStation: Detect SCTE-35 Splice-In
        LocalStation->>Viewer: Resume Program Feed
    end

2.2. Industrial IoT: Distributed Control via Encrypted Broadcast

Enabling Description: In a large automated warehouse, a central control server broadcasts a single, low-power radio signal (e.g., LoRaWAN) containing a continuous stream of encrypted command packets. Each packet has a header specifying a target device type ("forklift", "robotic arm") or a specific device ID. Every IoT device in the facility (e.g., thousands of autonomous mobile robots or AMRs) receives this broadcast. Each AMR's onboard controller decrypts all packets using a shared group key. It then checks the packet header. If the packet is addressed to its ID or type, it executes the command (e.g., "AMR-734, proceed to waypoint X,Y", "All forklifts in Zone B, reduce speed to 2 m/s"). The controller can also overlay status information (e.g., battery level, current task) onto a small e-ink display on the AMR for human operators. This provides a robust, one-to-many command and control infrastructure that is not dependent on a high-bandwidth, point-to-point network like Wi-Fi.

Mermaid Diagram:

graph TD
    A[Central Control Server] -->|Encrypted LoRaWAN Broadcast| B((Warehouse Airwaves));
    subgraph AMR_101
        C[Receiver] --> D{Filter};
        D -- Addressed to me --> E[Actuator Control];
        D -- Not for me --> F[Discard];
        E --> G[Motor & Navigation];
    end
    subgraph AMR_734
        H[Receiver] --> I{Filter};
        I -- Addressed to me --> J[Actuator Control];
        I -- Not for me --> K[Discard];
        J --> L[Motor & Navigation];
    end
    B --> C & H;

Part 3: Combination with Open-Source Standards

3.1. Combination with MPEG Transport Stream (ISO/IEC 13818-1)

Enabling Description: The system's "embedded signals" are implemented as a custom data type within an MPEG Transport Stream (TS). A specific Program ID (PID) is allocated in the Program Map Table (PMT) for the "Personalized Control Data" stream. This stream consists of PES (Packetized Elementary Stream) packets containing the encrypted control instructions and user-specific data triggers. Standard DVB/ATSC receivers can be configured to demultiplex and route this specific PID to an application processor, while the standard audio and video PIDs are routed to their respective hardware decoders. This method leverages a ubiquitous, open standard for digital television to carry the proprietary control channel, allowing for compatibility with off-the-shelf demodulator and demultiplexer chipsets, thus rendering the method of transport obvious.

3.2. Combination with Secure Reliable Transport (SRT) Protocol

Enabling Description: For delivering personalized broadcast streams over unreliable IP networks (like the public internet), the '091 system is combined with the open-source SRT protocol. The central station acts as an SRT server, broadcasting the main A/V feed. The embedded control signals are transmitted as custom messages within SRT's "in-band messaging" feature. Subscriber-side receivers act as SRT clients, establishing a connection to the server. The SRT protocol's inherent packet recovery and jitter mitigation ensures that both the A/V content and the critical control signals arrive reliably and in synchronization, even over congested networks. A person of ordinary skill in the art would find it obvious to use an open, reliable transport protocol for delivering time-sensitive control data alongside a video stream.

3.3. Combination with Home Assistant / Matter IoT Standards

Enabling Description: The "signal processing apparatus" at the subscriber station is a software module running on an open-source home automation hub, such as Home Assistant. The hub receives the broadcast television signal via a connected TV tuner dongle. An integration component within Home Assistant processes the embedded signals as described in the '091 patent. Instead of controlling a proprietary VCR, the instructions trigger automations within the standardized smart home ecosystem. For example, a control signal embedded in a movie broadcast could trigger a "Movie Time" scene via the Matter protocol, which would dim all connected lights, lower smart blinds, and adjust the thermostat, regardless of the brand of the individual IoT devices. This combines the broadcast control concept with a widely adopted, open standard for device interoperability.