Derivative works — US Patent US6098106

Defensive Disclosure of Derivative Technologies from US6098106

Publication Date: April 26, 2026
Disclosed by: Senior Patent Strategist and Research Engineer

This document serves as a defensive disclosure to establish prior art for derivative inventions and incremental improvements related to the core teachings of US Patent US6098106. The intent of this publication is to place the described concepts into the public domain, thereby rendering them obvious or non-novel for future patent applications by third parties. The following disclosures are described in sufficient detail to enable a person having ordinary skill in the art (PHOSITA) to practice the inventions without undue experimentation.

Analysis of Core Claim (Claim 1 of US6098106)

The fundamental teaching involves:

A broadcast program (e.g., television, radio).
An embedded routing signal within the broadcast.
Extraction of the routing signal by a computing device.
Control of the computer to retrieve information from a network location defined by the routing signal.

The preferred embodiment specifies an audible analog signal as the routing signal. The following derivations expand upon this core concept.

Derivative Variations

1. Material & Component Substitution

Derivative 1.1: Sub-audible Acoustic Carrier

Enabling Description: This variation replaces the audible audio tone with a sub-audible or ultrasonic acoustic carrier wave. The routing information is modulated onto a carrier frequency outside the typical range of human hearing, such as in the 18 kHz to 22 kHz range, or in the ultrasonic range (>22 kHz). A standard condenser or piezoelectric microphone in a user's device (e.g., smartphone, PC) receives the audio spectrum. A digital signal processor (DSP) or a software-defined filter isolates the specific high-frequency carrier. Demodulation is achieved using Frequency-Shift Keying (FSK) or Phase-Shift Keying (PSK) to extract the digital routing information (e.g., a compressed URL or a unique identifier). This method prevents interference with the primary audio content of the broadcast program and is imperceptible to the user.

Mermaid Diagram:

sequenceDiagram
    participant Broadcast as Broadcast Source
    participant TV as Television/Speaker
    participant PC as User Computing Device
    participant ARS as Advertiser Reference Server

    Broadcast->>TV: Program with Ultrasonic Signal (19 kHz FSK)
    TV->>PC: Plays Audio (Mic captures full spectrum)
    PC->>PC: DSP filters and demodulates 19 kHz signal
    PC->>ARS: Transmits extracted identifier
    ARS-->>PC: Returns full URL
    PC->>PC: Browser redirects to URL

Derivative 1.2: Haptic Transducer Signal

Enabling Description: Instead of an audio signal, the routing information is encoded as a low-frequency haptic vibration pattern transmitted through a specialized transducer. This could be embedded in furniture (e.g., a couch), a wearable device, or a dedicated receiver pad. The broadcast signal contains a control sub-carrier that activates the haptic transducer to generate a specific temporal pattern of vibrations. An accelerometer or piezoelectric sensor within a user's device detects this pattern. The sequence of pulses and their duration is decoded into binary data representing the routing identifier. This is particularly applicable for environments where audio is muted or for providing access to information for the hearing-impaired.

Mermaid Diagram:

flowchart TD
    A[Broadcast with Haptic Control Signal] --> B{TV/Set-Top Box};
    B --> C[Haptic Transducer];
    C -- Vibration Pattern --> D(User Device with Accelerometer);
    D --> E{Pattern Decoding Algorithm};
    E -- Extracted ID --> F[Send Request to Network];
    F --> G[Retrieve Content];

2. Operational Parameter Expansion

Derivative 2.1: Nanoscale Acoustic Data Transfer in Microfluidics

Enabling Description: This applies the core concept to a laboratory setting at the nanoscale. A microfluidic "lab-on-a-chip" device is the "broadcast" environment. A nano-acoustic transducer generates high-frequency (GHz range) sound waves that propagate through the fluid medium. These acoustic waves carry routing information for a control computer. A receiving nanosensor (e.g., a cantilever-based detector) on the chip detects these waves and decodes the information. The computer then uses this information to route commands to other components on the chip, such as activating micropumps or retrieving specific datasets from a connected database corresponding to the experiment's state (e.g., pulling up a specific protein folding model).

Mermaid Diagram:

graph LR
    subgraph Microfluidic Chip
        A(Nano-Acoustic Tx) -- GHz Signal --> B(Fluid Medium);
        B -- Propagates --> C(Cantilever Rx);
    end
    C -- Decoded ID --> D[Control Computer];
    D -- Fetches Data --> E(Genomic Database);
    D -- Sends Command --> F(Micropump Actuator);

Derivative 2.2: High-Pressure, High-Temperature Industrial Process Control

Enabling Description: The invention is adapted for process control in extreme industrial environments, such as a chemical reactor or a deep-sea drilling operation. The "broadcast" is the physical state of the process, monitored by sensors. The "routing signal" is an acoustic pressure wave generated by a robust piezoelectric transducer, capable of operating at pressures exceeding 1000 bar and temperatures over 300°C. The signal is transmitted through the process medium (e.g., drilling mud, chemical slurry). A hardened sensor array downstream decodes the acoustic data, which contains an identifier for a specific operational protocol. A ruggedized industrial PC uses this identifier to retrieve the corresponding protocol from a central server, adjusting valve positions or drill speeds accordingly.

Mermaid Diagram:

stateDiagram-v2
    [*] --> Monitoring
    Monitoring --> TransmitSignal: High Pressure/Temp Detected
    TransmitSignal: Generate Acoustic ID through Slurry
    TransmitSignal --> DecodeSignal
    DecodeSignal --> RetrieveProtocol: ID Decoded
    RetrieveProtocol --> ExecuteProtocol: Fetch from Server
    ExecuteProtocol --> Monitoring: Adjust Valve/Drill

3. Cross-Domain Application

Derivative 3.1: Aerospace - In-Flight Maintenance Assistance

Enabling Description: During a commercial flight, a sensor on a component (e.g., a hydraulic actuator) detects an anomaly. It "broadcasts" an ultrasonic audio signature unique to the fault condition through the aircraft's fuselage. A technician's handheld device, equipped with a contact microphone, detects and decodes this signature. The decoded identifier acts as a routing key, automatically directing the device's browser to the specific page in the aircraft's digital maintenance manual corresponding to that exact fault code and component, displaying repair procedures and diagrams.

Mermaid Diagram:

sequenceDiagram
    participant Actuator as Faulty Actuator
    participant Fuselage as Aircraft Fuselage
    participant Device as Technician's Handheld
    participant Server as Maintenance Server

    Actuator->>Fuselage: Emits ultrasonic fault signature
    Device->>Fuselage: Contact mic detects signature
    Device->>Device: Decodes signature to Fault ID
    Device->>Server: Requests manual for Fault ID
    Server-->>Device: Returns specific repair procedure

Derivative 3.2: AgTech - Smart Irrigation and Pest Control

Enabling Description: A network of in-field sensors monitors soil moisture and acoustic signatures of insect activity. When a specific pest (e.g., a locust) is detected by its unique acoustic frequency profile, the sensor node "broadcasts" this signature as a routing signal over a local network. A central farm management computer receives this signal, which automatically routes a request to a pest control database to retrieve the appropriate treatment protocol (e.g., targeted pesticide drone dispatch coordinates and mixture settings). A parallel system uses soil moisture acoustic profiles to retrieve specific irrigation schedules.

Mermaid Diagram:

flowchart TD
    A[In-Field Sensor] -- Detects Locust Acoustic Signature --> B{Local Gateway};
    B -- Transmits Pest ID --> C[Farm Management Server];
    C -- Uses ID to query --> D(Pest Control Database);
    D -- Returns Protocol --> C;
    C --> E[Dispatch Pesticide Drone];

Derivative 3.3: Consumer Electronics - Interactive Toy

Enabling Description: A children's television show embeds high-frequency, inaudible audio tones into its broadcast. An associated smart toy, equipped with a microphone and a simple processor, listens for these tones. When a specific tone is detected, it is decoded into an identifier. The toy uses its Wi-Fi connection to send this identifier to a server, which returns a small packet of data. This data triggers a specific action in the toy—it might say a phrase related to the on-screen character, light up in a certain color, or download a new story module.

Mermaid Diagram:

sequenceDiagram
    participant TV as TV Show Broadcast
    participant Toy as Smart Toy
    participant Server as Content Server

    TV->>Toy: Broadcasts audio with embedded 20kHz tone
    Toy->>Toy: Decodes tone to Character ID 'XYZ'
    Toy->>Server: Request action for ID 'XYZ'
    Server-->>Toy: Return command: "Say 'Hello!'"
    Toy->>Toy: Activates speaker to say "Hello!"

4. Integration with Emerging Tech

Derivative 4.1: AI-Optimized Dynamic Ad Insertion

Enabling Description: A broadcast stream (e.g., internet radio, podcast) includes silent, watermarked audio routing signals. A user's device continuously decodes these signals. An on-device AI agent analyzes the user's real-time context (location, time of day, calendar events, recent app usage). When a routing signal is detected, the AI combines the signal's identifier with the user's current context vector and forwards it to an ad server. The server uses a machine learning model to select and return a hyper-personalized advertisement URL, which is then loaded in the browser. This moves beyond a static link to a dynamically selected one based on AI-driven personalization.

Mermaid Diagram:

graph TD
    A[Broadcast with Audio Watermark] --> B{User Device};
    subgraph On-Device AI
        C(Context Analyzer: Location, Time, Apps)
    end
    B -- Watermark ID --> D{AI Agent};
    C -- Context Vector --> D;
    D -- Combined Request --> E[Personalized Ad Server];
    E -- ML Model Selects Ad --> F(Returns Hyper-Personalized URL);
    F --> G[Device Browser Loads Ad];

Derivative 4.2: IoT-Triggered Supply Chain Verification via Blockchain

Enabling Description: An IoT sensor within a temperature-controlled shipping container (the "broadcast" source) monitors for temperature deviations. If the temperature goes out of spec, the sensor emits a specific ultrasonic signature. A nearby gateway device (e.g., in a port warehouse) detects this signature, decodes it into an "event ID," and uses it to trigger a smart contract on a blockchain. The smart contract automatically records the temperature excursion event, links it to the product's digital twin, and retrieves a new routing URL pointing to a "Quarantine and Inspect" protocol, which is sent to the logistics manager's dashboard.

Mermaid Diagram:

sequenceDiagram
    participant IoT as IoT Sensor in Container
    participant Gateway as Warehouse Gateway
    participant Blockchain as Smart Contract
    participant Dashboard as Manager Dashboard

    IoT->>IoT: Temperature exceeds threshold
    IoT->>Gateway: Emits ultrasonic Event ID
    Gateway->>Blockchain: Triggers 'Log_Event' on smart contract with ID
    Blockchain->>Blockchain: Records immutable event
    Blockchain-->>Gateway: Returns URL for 'Quarantine Protocol'
    Gateway->>Dashboard: Pushes protocol URL for action

5. The "Inverse" or Failure Mode

Derivative 5.1: Fail-Safe Industrial Alert System

Enabling Description: This system is designed to function only when a primary control network fails. In an industrial plant, a control system continuously broadcasts a high-frequency "heartbeat" audio tone. A distributed network of low-power sensor nodes listens for this heartbeat. If the heartbeat signal disappears for a predetermined duration (indicating primary network or power failure), the nodes default to a "fail-safe" mode. In this mode, they begin broadcasting a different, low-frequency, high-amplitude acoustic signal that encodes a routing identifier for an emergency "shutdown and vent" procedure. A battery-powered master control unit, designed to listen for this specific failure tone, receives the signal and retrieves the emergency protocol from local, non-volatile memory to safely shut down the facility.

Mermaid Diagram:

stateDiagram-v2
    state "Normal Operation" as Normal {
        direction LR
        [*] --> Listening
        Listening --> Listening: Heartbeat Tone Detected
    }
    Normal --> FailureMode: Heartbeat Tone NOT Detected for >5s
    state "Failure Mode" as FailureMode {
        [*] --> Broadcasting
        Broadcasting: Emit Emergency 'Shutdown' Tone
    }
    state "Emergency Controller" as ECU {
        [*] --> Idle
        Idle --> Execute: 'Shutdown' Tone Detected
        Execute: Load protocol from local memory
    }

Combination Prior Art with Open-Source Standards

Combination with WebRTC (Web Real-Time Communication):
- Enabling Description: The routing signal from the broadcast is received and decoded by a web browser client. Instead of routing to a standard HTTP server, the decoded identifier is used as a session key to initiate a peer-to-peer (P2P) connection using the WebRTC open standard. The browser connects directly to another user's device (or a group of devices) that watched the same broadcast, enabling instantaneous, low-latency shared experiences like synchronized second-screen content, real-time polling, or P2P gaming triggered by the broadcast event. The "Advertiser Reference Server" in this model becomes a WebRTC signaling server for peer discovery and NAT traversal.
Combination with MQTT (Message Queuing Telemetry Transport):
- Enabling Description: The device that decodes the audio signal acts as an MQTT client. The decoded routing information contains an MQTT "topic" string (e.g., broadcast/channel_ABC/event_123). The device subscribes to this topic on a public or private MQTT broker. The "retrieved information" is not a webpage but a stream of real-time data messages published to that topic by the broadcaster. This allows for lightweight, continuous data updates related to the broadcast (e.g., real-time sports statistics, live voting results, stock price changes) without the overhead of HTTP requests.
Combination with Verifiable Credentials (W3C VC-Data Model):
- Enabling Description: The broadcast signal contains a routing identifier that directs the user's device to a server to fetch a Verifiable Credential. This credential digitally attests that the user's device was "present" for a specific broadcast at a specific time, signed by the broadcaster. The user can store this credential in a digital wallet. Later, they can present this credential to a third-party service (e.g., an e-commerce site) to prove they watched a particular advertisement, unlocking a special discount or exclusive content. This combines the triggering mechanism with a standardized, cryptographically secure proof-of-action.