Derivative works — US Patent US5905865

Defensive Disclosure: Derivative Embodiments and Extensions for Synchronized Broadcast and Online Service Access

Publication Date: April 30, 2026
Reference Patent: US5905865

This document discloses novel variations, extensions, and alternative embodiments of the methods and systems for automatically accessing on-line services in response to a synchronized broadcast of on-line addresses, as generally described in US patent US5905865. The purpose of this disclosure is to place these concepts in the public domain, thereby establishing them as prior art for future patent applications.

Section 1: Derivatives of Core Concept A (Synchronized Push of Online Address)

1.1 Material & Component Substitution

1.1.1. Acoustic Data Transmission via Inaudible Ultrasonics

Enabling Description: This embodiment replaces the radio-frequency (RF) address transmitter (e.g., a paging system) with an acoustic transducer system. The online address (URL) is encoded into a data packet using a robust modulation scheme like Binary Phase Shift Keying (BPSK) or Quadrature Amplitude Modulation (QAM). This signal is then carried on an ultrasonic frequency (e.g., 22-40 kHz), which is inaudible to humans but can be embedded directly into the audio track of the primary audio/video broadcast. A client device (e.g., a computer, smartphone, or smart TV) uses its built-in microphone to receive the audio, a digital signal processor (DSP) to apply a band-pass filter centered on the ultrasonic carrier frequency, and a demodulator to extract the data packet containing the URL. The client's application then passes this URL to a web browser for automatic access. This method co-locates the address transmission within the primary broadcast medium itself.

Mermaid.js Diagram:

sequenceDiagram
    participant Broadcaster
    participant ClientDevice
    participant OnlineService

    Broadcaster->>Broadcaster: Encode URL into ultrasonic carrier (e.g., 38 kHz)
    Broadcaster->>ClientDevice: Transmit A/V Program with embedded ultrasonic signal
    ClientDevice->>ClientDevice: Microphone captures audio
    ClientDevice->>ClientDevice: DSP applies band-pass filter & demodulates URL
    ClientDevice->>OnlineService: Automatically access extracted URL via HTTP GET
    OnlineService-->>ClientDevice: Return web content

1.1.2. Photonic Transmission via Modulated Ambient Lighting

Enabling Description: This embodiment uses a visible light communication (VLC) or Li-Fi system for address transmission. The address transmitter is a lighting element (e.g., an LED bulb) in the viewing environment. The online address is encoded into a binary stream, which then modulates the intensity of the light at a frequency imperceptible to the human eye (e.g., >1 kHz). A client device equipped with a photodiode or ambient light sensor receives the modulated light. A dedicated integrated circuit or software running on the main processor demodulates the signal to recover the URL, which is then used to access the online service. This system is synchronized with a video broadcast by having the central broadcast signal control the lighting system via a side-channel.

Mermaid.js Diagram:

flowchart TD
    A[TV Broadcast Signal] --> B{Sync Controller};
    B --> C[Address Transmitter (LED Light)];
    B --> D[TV Display];
    C -- Modulated Light (VLC) --> E[Client Device Photodiode];
    E --> F{Demodulator};
    F -- Extracted URL --> G[Web Browser];
    G -- HTTP Request --> H((Online Service));
    H -- Web Content --> G;

1.2 Operational Parameter Expansion

1.2.1. Planetary Scale: Deep Space Network Data Synchronization

Enabling Description: This system operates at a planetary scale for coordinating distributed scientific data processing. The "broadcast" is the raw telemetry stream from a deep space probe (e.g., the James Webb Space Telescope), transmitted via the Deep Space Network (DSN). This stream is public. Simultaneously, a separate, low-bandwidth DSN side-channel transmits "addresses." These addresses are not URLs, but rather Uniform Resource Identifiers (URIs) pointing to specific containerized data processing pipelines and algorithms stored in a distributed cloud repository (e.g., Docker Hub, AWS ECR). A global network of volunteer or institutional computing nodes receives both the raw data stream and the URI. The URI automatically directs the node's orchestration software (e.g., Kubernetes) to pull the specified container, mount the relevant segment of the raw data stream, and execute the analysis pipeline. As the probe changes observation targets, new URIs are broadcast to load different processing pipelines.

Mermaid.js Diagram:

graph LR
    subgraph "Deep Space Network (DSN)"
        A[Probe Raw Telemetry]
        B[Pipeline URI Side-Channel]
    end
    subgraph "Distributed Compute Node"
        C{Receiver}
        D[Orchestration Agent]
        E[Processing Engine]
    end
    F((Cloud Algorithm Repository))

    A -- High-Bandwidth Stream --> C;
    B -- Low-Bandwidth Stream --> C;
    C -- URI --> D;
    D -- Pull Container --> F;
    F -- Container Image --> D;
    D -- Deploy & Run --> E;
    A -- Raw Data Segment --> E;

1.3 Cross-Domain Application

1.3.1. Aerospace: Synchronized Launch Telemetry Dashboards

Enabling Description: During a live video broadcast of a spacecraft launch, a parallel, authenticated data stream is transmitted to mission control partners. This data stream contains time-stamped packets, where each packet is an address (e.g., a specific URL or API endpoint). These addresses correspond to highly specific diagnostic dashboards. For example, at T-60s (main engine start), a URL is broadcast that automatically opens a real-time engine performance and vibration analysis dashboard on engineers' workstations. At SRB separation, a new URL is broadcast that opens a trajectory and structural load dashboard. This ensures all relevant personnel are viewing the correct, context-sensitive information automatically and in perfect sync with the mission events shown on the main video feed.

Mermaid.js Diagram:

stateDiagram-v2
    [*] --> PreLaunch
    PreLaunch --> EngineStart: Event: T-60s
    note right of EngineStart
        Broadcast URL: /dash/engine-perf
        Workstation automatically opens Engine Performance dashboard
    end note
    EngineStart --> SRBSeparation: Event: T+120s
    note right of SRBSeparation
        Broadcast URL: /dash/trajectory-loads
        Workstation automatically opens Trajectory Analysis dashboard
    end note
    SRBSeparation --> Orbit: Event: T+480s
    note right of Orbit
        Broadcast URL: /dash/orbital-params
        Workstation automatically opens Orbital Parameters dashboard
    end note

1.3.2. AgTech: Drone-to-Robot Tasking via Synchronized Geolocation Addresses

Enabling Description: An agricultural drone performs a live video survey of a field, which is broadcast to a central farm management system. The drone's onboard computer uses machine vision to identify areas needing intervention (e.g., pest infestation, dry soil). When an area is identified, the drone's system transmits a "Geo-Address" packet over a local RF network (e.g., LoRaWAN). This address is not a URL but a high-precision GPS coordinate string formatted as a tasking URI (e.g., geo:34.0522,-118.2437?action=spray&pest=aphid). A fleet of autonomous ground robots receives the video feed for situational awareness and simultaneously listens for the Geo-Address packets. Upon receiving a packet, the designated robot automatically parses the URI, plots a course to the specified coordinates, and executes the action parameter using the appropriate implement.

Mermaid.js Diagram:

sequenceDiagram
    participant Drone
    participant GroundRobot
    participant TargetArea

    Drone->>Drone: Identify pest infestation via live video
    Drone->>GroundRobot: Transmit Geo-Address URI <br> `geo:...?action=spray`
    GroundRobot->>GroundRobot: Parse URI, plot route
    GroundRobot->>TargetArea: Navigate to coordinates
    GroundRobot->>TargetArea: Execute 'spray' action

1.3.3. Consumer Electronics: Interactive Cooking with Smart Appliances

Enabling Description: A user watches a cooking show on a smart display in their kitchen. The show's broadcast includes an embedded data track compliant with a new smart home standard (e.g., Matter). As the chef on screen performs an action, a corresponding control "address" or command packet is broadcast over the local Wi-Fi network. When the chef says, "Preheat your oven to 425 degrees," the display broadcasts a packet like appliance://oven/1/set?temp=425&unit=F. The home's smart oven, subscribed to these broadcasts, receives this address, validates it, and automatically begins preheating. Similarly, when the show mentions a 10-minute simmer, a appliance://stovetop/3/timer?set=600 packet is sent to the smart stovetop.

Mermaid.js Diagram:

flowchart LR
    A[Cooking Show Broadcast] --> B{Smart Display};
    B --"Preheat oven to 425" (Audio/Video)--> C(User);
    B --`appliance://oven/set?temp=425` (Data)--> D[Smart Oven];
    D --> E{Action: Begin Preheating};

1.4 Integration with Emerging Tech

1.4.1. AI-Driven Predictive Address Generation

Enabling Description: The system integrates a real-time AI content analysis module. This AI processes the audio and video of the broadcast feed microseconds before it is transmitted. It performs speech-to-text, object recognition, and sentiment analysis to understand the context. Based on this analysis, it predictively generates or selects the most relevant online address from a vast database. For example, during a live news report about a company, the AI can detect the sentiment. If positive, it generates a link to the company's investor relations page; if negative, it links to a third-party news analysis of the event. This allows for dynamically tailored and context-aware online content that is more relevant than a pre-programmed sequence of URLs.

Mermaid.js Diagram:

graph TD
    A[Live A/V Feed] --> B{AI Content Analyzer};
    B -- Context & Sentiment --> C{Address Generation Engine};
    C --> D[URL Database];
    C --> E{Selected/Generated URL};
    A --> F(Broadcast Delay Buffer);
    E --> G(Address Transmitter);
    F --> H[Public Broadcast];
    G --> H;

1.4.2. IoT-Enabled Real-World Synchronization and Blockchain Verification

Enabling Description: This system links a broadcast to real-world events via IoT sensors and verifies interactions on a blockchain. Imagine a live televised sporting event (e.g., a marathon). IoT pressure sensors and RFID readers are placed along the race route. When the lead runner (with an RFID tag in their bib) crosses a specific checkpoint, the IoT sensor triggers an event. This event is the "broadcast." Simultaneously, an address transmitter sends a URL to viewers' devices for a limited-edition digital collectible (NFT) commemorating that moment. When a user's computer accesses the URL to claim the NFT, the transaction request is sent to a blockchain smart contract. The smart contract first verifies the claim is coming within a valid time window of the IoT trigger event before minting and transferring the NFT to the user's wallet. This creates a provably scarce digital item tied to a verified real-world event.

Mermaid.js Diagram:

sequenceDiagram
    participant Runner
    participant IoT_Checkpoint
    participant Broadcaster
    participant Viewer_Device
    participant Blockchain_Contract

    Runner->>IoT_Checkpoint: Crosses checkpoint
    IoT_Checkpoint->>Broadcaster: Trigger Event (Timestamped)
    Broadcaster->>Viewer_Device: Broadcast URL for NFT Claim
    Viewer_Device->>Blockchain_Contract: Call claimNFT() function
    Blockchain_Contract->>Blockchain_Contract: Verify timestamp against IoT trigger
    Blockchain_Contract-->>Viewer_Device: Mint and transfer NFT

1.5 The "Inverse" or Failure Mode

1.5.1. Graceful Degradation to Cached or Low-Bandwidth Content

Enabling Description: The address transmitter broadcasts multiple addresses simultaneously on different channels or within a single data packet with priority flags. A primary address might point to a high-bandwidth, interactive WebGL experience (http://example.com/experience3D). A secondary address points to a standard HTML version (http://example.com/experienceHTML), and a tertiary address points to a locally cached version of the content, referenced by a content hash (cache://ipfs/Qm...). The client application first assesses its own state (network connectivity, processing power). If bandwidth is high, it accesses the primary URL. If low, it accesses the secondary URL. If offline, it attempts to load the content from its local cache using the tertiary address. This ensures a functional, albeit reduced, user experience rather than a complete failure.

Mermaid.js Diagram:

flowchart TD
    A[Receive Address Packet] --> B{Check Network Status};
    B -- High Bandwidth --> C[Access Primary URL (WebGL)];
    B -- Low Bandwidth --> D[Access Secondary URL (HTML)];
    B -- Offline --> E[Access Tertiary Address (Local Cache)];

Section 2: Combination with Open-Source Standards

2.1. Combination with MQTT (Message Queuing Telemetry Transport)

Enabling Description: The address transmission mechanism is implemented using the lightweight, open-source MQTT protocol, ideal for IoT and low-bandwidth environments. A central broadcaster runs an MQTT broker. During the audio/video broadcast, an associated system publishes the synchronized online addresses as messages to a specific MQTT topic (e.g., /broadcast/channel_A/sync_url). Client devices run a lightweight MQTT client that subscribes to this topic. When a message is published, the broker pushes it instantly to all subscribed clients. The client application receives the message payload (the URL) and automatically directs the browser. This decouples the address transmission from the broadcast medium and allows for flexible, low-latency delivery over any IP network.

2.2. Combination with WebRTC (Web Real-Time Communication)

Enabling Description: For users watching a broadcast via a web browser, the system uses WebRTC to enhance the experience. The main audio/video content is delivered over a standard streaming protocol (like HLS or DASH). In parallel, the browser establishes a peer-to-peer WebRTC DataChannel with a server controlled by the broadcaster. This DataChannel provides a low-latency, ordered, and reliable communication path. The broadcaster sends the synchronized address strings through this DataChannel precisely when needed. The client-side JavaScript receives the message from the DataChannel event listener and can then either open a new tab/window or load the URL into a designated <iframe> on the same page, all without requiring a separate receiver or plugin.

2.3. Combination with Schema.org and JSON-LD

Enabling Description: The transmitted address is not just a raw URL but a structured data object using the open Schema.org vocabulary, formatted in JSON-LD (JSON for Linked Data). This allows for much richer metadata to be sent alongside the URL. For a commercial, the transmitted packet might be a BroadcastEvent schema that includes the URL for the product (url property), an expiration time for an associated offer (endDate property), and the geographic region where the offer is valid (location property). The client application can parse this structured data and make more intelligent decisions, such as ignoring an expired or geographically irrelevant offer, or displaying a countdown timer next to the link. This makes the system more flexible and powerful than one transmitting simple URLs.