Derivative works — US Patent 6098106

Defensive Disclosure and Prior Art Generation

RE: US Patent 6098106 - Method for controlling a computer with an audio signal
Publication Date: April 26, 2026
Status: PUBLIC DISCLOSURE

This document serves as a defensive publication of derivative inventions, applications, and improvements related to the art described in US Patent 6,098106. The intent of this disclosure is to place these concepts in the public domain, thereby establishing them as prior art to preclude future patenting by third parties.

1. Signal, Component, and Data Substitution

1.1. Derivative: Inaudible Acoustic Data Carrier

Enabling Description: The system is modified to use an inaudible acoustic signal as the data carrier for the trigger and product identifier. A carrier wave is generated at a frequency outside the range of normal human hearing, such as in the ultrasonic (>20 kHz) or infrasonic (<20 Hz) ranges. The product identifier and trigger signal are encoded onto this carrier wave using Frequency-Shift Keying (FSK) or Phase-Shift Keying (PSK) modulation. A client device equipped with a wide-spectrum microphone and a corresponding digital signal processor (DSP) continuously samples ambient audio. The DSP implements a band-pass filter tuned to the carrier frequency. Upon detecting the carrier, it demodulates the FSK/PSK signal to recover the digital identifier, which is then passed to the client software to initiate the network lookup process as described in the primary invention. This method allows the data to be transmitted without interfering with the primary audible program content.

sequenceDiagram
    participant Broadcaster
    participant ClientDevice
    participant ARS
    participant AdvertiserServer

    Broadcaster->>ClientDevice: Transmits Program + Ultrasonic Signal (Identifier: 8A4F)
    ClientDevice->>ClientDevice: DSP filters for >20kHz frequency
    ClientDevice->>ClientDevice: Demodulates FSK to extract '8A4F'
    ClientDevice->>ARS: HTTP GET http://ars.server/?id=8A4F
    ARS->>ARS: Lookup '8A4F' in database
    ARS-->>ClientDevice: HTTP 302 Redirect to http://advertiser.com/product/8A4F
    ClientDevice->>AdvertiserServer: HTTP GET http://advertiser.com/product/8A4F
    AdvertiserServer-->>ClientDevice: HTML content for product 8A4F

1.2. Derivative: Dynamic Visual Data Carrier (Temporal Watermark)

Enabling Description: Instead of an audio signal, the trigger and identifier are encoded into the video signal as a temporal, machine-readable watermark. A small, designated block of pixels (e.g., 16x16 pixels in a corner of the frame) has its luminance or chrominance values subtly modulated over a sequence of frames. For example, a "1" bit is encoded by a slight increase in average luminance over 3 frames, and a "0" bit by a slight decrease. A client device uses its camera to view the display. A computer vision algorithm on the client isolates the designated pixel block, tracks its average luminance/chrominance values frame-by-frame, and decodes the bitstream to recover the identifier. This method is resistant to geometric distortion and ambient lighting changes.

flowchart TD
    A[Video Broadcast] --> B{Client Device Camera Views Screen};
    B --> C[CV Algorithm Isolates 16x16 Pixel Block];
    C --> D[Track Avg. Luminance Over N Frames];
    D --> E{Decode Temporal Bitstream};
    E --> F[Identifier Recovered];
    F --> G[Initiate ARS Network Lookup];
    G --> H[Redirect to Advertiser URL];

1.3. Derivative: Piggybacked RF Data Side-Channel

Enabling Description: The system utilizes a secondary, low-bandwidth Radio Frequency (RF) signal that is broadcast concurrently with the primary television or radio program. In a television broadcast, this could be implemented within the Vertical Blanking Interval (VBI) of an analog signal or as a custom data stream within an ATSC (Advanced Television Systems Committee) digital broadcast. A specialized receiver in the client device, separate from the primary audio/video tuner, is dedicated to monitoring this RF side-channel. The trigger and product identifier are transmitted as data packets on this channel. When a packet is received, the client software is alerted and uses the payload data to initiate the ARS lookup, decoupling the trigger mechanism entirely from the perceptible program content.

graph LR
    subgraph Broadcaster
        A[Program Content]
        B[Identifier Data]
    end
    subgraph Client Device
        D[TV/Radio Tuner]
        E[VBI/ATSC Data Receiver]
        F[Browser Application]
    end
    C[Multiplexer]
    G[ARS]

    A --> C
    B --> C
    C -- Primary Broadcast --> D
    C -- RF Side-Channel --> E
    E -- Decoded Identifier --> F
    F -- HTTP Request --> G

1.4. Derivative: Haptic Signature Encoding

Enabling Description: This variation targets mobile and wearable devices equipped with advanced haptic actuators (e.g., linear resonant actuators). The "broadcast" is a localized transmission, such as in a retail store or museum exhibit, via NFC or UWB radio. When a user's device comes into range, it receives a data packet containing a haptic signature. The client software translates this signature into a specific sequence of vibrations with varying frequency and amplitude. This haptic pattern serves as a non-visual, non-auditory identifier. The software recognizes the pattern and initiates the ARS network request to pull up relevant information about the retail product or museum exhibit.

stateDiagram-v2
    [*] --> Idle
    Idle --> Receiving: Device enters UWB field
    Receiving --> Decoding: Receives haptic signature packet
    Decoding --> NetworkRequest: Translates haptic pattern to ID
    NetworkRequest --> DisplayingContent: Receives redirect from ARS and fetches content
    DisplayingContent --> Idle: User navigates away
    Receiving --> Idle: Device leaves UWB field

2. Operational Parameter Expansion

2.1. Derivative: Microsecond-Scale Financial Data Feed Trigger

Enabling Description: The invention is applied to high-frequency trading (HFT). The "broadcast" is a direct market data feed (e.g., ITCH/OUCH protocol) from a financial exchange, delivered over a low-latency network. The "trigger signal" is a specific, predefined pattern in the data feed, such as a specific sequence of trades or a price discrepancy between two related instruments that signals a statistical arbitrage opportunity. A co-located trading server (the "client device") ingests the feed. A dedicated FPGA or software process detects this pattern in real-time (microseconds). The pattern itself serves as the "identifier." The server immediately constructs a REST API call to a specific trading venue's order entry gateway (the "advertiser server"), bypassing the ARS for speed. The API call parameters are derived from the data pattern, executing a trade.

sequenceDiagram
    participant Exchange
    participant HFT_Server
    participant Order_Gateway

    Exchange->>HFT_Server: Market Data Stream (Pattern Detected)
    HFT_Server->>HFT_Server: Identify Arbitrage ID: ARB-XYZ-01
    HFT_Server->>Order_Gateway: POST /execute_trade (Symbol:XYZ, Action:BUY)
    Order_Gateway-->>HFT_Server: 200 OK (Trade Executed)

2.2. Derivative: High-Latency Deep Space Communications Protocol

Enabling Description: The method is adapted for communication with autonomous deep-space probes where bandwidth is minimal and latency is extreme (minutes to hours). The "broadcast" is the probe's telemetry stream. A specific sequence of sensor readings or an error code (e.g., ERR_GYRO_SATURATE) acts as the "trigger" and "identifier." A ground station computer receives the signal. It initiates a request to a Mission Control ARS. The ARS, rather than returning a simple URL, returns a complete, pre-compiled command sequence or a differential software patch optimized for low-bandwidth transmission. This "content" is then uplinked to the probe during the next available transmission window to correct the error condition.

flowchart TD
    A[Probe Telemetry Downlink] --> B{Ground Station Receives Error ID};
    B --> C[Query Mission Control ARS w/ Error ID];
    C --> D{ARS Database Lookup};
    D --> E[Retrieve Corrective Command Sequence];
    E --> F[Return Sequence to Ground Station];
    F --> G[Queue Sequence for Next Uplink Window];
    G --> H[Transmit Commands to Probe];

2.3. Derivative: City-Scale Emergency Alert Dissemination

Enabling Description: The system is scaled to a municipal level for emergency response. The "broadcast" is an alert pushed via the Wireless Emergency Alerts (WEA) system. The alert message contains a short alphanumeric code (the "identifier") representing the event type and geographical zone (e.g., FLOOD_ZN7_EVAC). All mobile devices in the area ("client devices") receive this alert. An OS-level service on the devices automatically sends a request including this identifier to a regional civil defense server (the "ARS"). The ARS responds with a redirect to a geo-specific, dynamically updated URL containing evacuation routes, shelter status, and localized instructions hosted on a content delivery network (CDN) for massive scalability.

graph TD
    subgraph Emergency_Operations_Center
        A[Alert Origination]
    end
    subgraph Municipal_ARS
        B[Regional Server]
        C[Geo-Redirection Database]
    end
    subgraph CDN
        D[Edge Servers w/ Evac Maps]
    end
    subgraph Citizens
        E((Mobile Device 1))
        F((Mobile Device 2))
        G((...))
    end

    A -- WEA Broadcast w/ ID --> E & F & G
    E -- Request w/ ID --> B
    F -- Request w/ ID --> B
    B -- Queries --> C
    C -- Returns Geo-URL --> B
    B -- Redirect to Geo-URL --> E & F
    E --> D
    F --> D

3. Cross-Domain Application

3.1. Derivative: Aerospace - Predictive Maintenance on Turbine Blades

Enabling Description: The method is applied to aircraft engine maintenance. Each turbine blade is etched with a unique micro-barcode (a visual identifier). During a maintenance check, an automated borescope is inserted into the engine. The borescope's camera scans the blades. Onboard computer vision software identifies each blade's barcode. Simultaneously, an ultrasonic transducer on the borescope emits a signal to test the blade's integrity. The reflected ultrasonic wave's signature (an "acoustic signal") is captured. The CV software combines the visual barcode with the acoustic signature ID and sends them to the airline's central maintenance server ("ARS"). The server cross-references this data with the blade's manufacturing and flight history, and returns a redirect to a page showing the blade's health status, projected lifespan, and any required maintenance procedures.

sequenceDiagram
    participant Borescope
    participant MaintenanceServer (ARS)
    participant BladeHealthDB

    Borescope->>Borescope: Scan visual barcode (ID: 7X3B2)
    Borescope->>Borescope: Capture ultrasonic signature (ID: US-99A1)
    Borescope->>MaintenanceServer: GET /check?blade=7X3B2&sig=US-99A1
    MaintenanceServer->>BladeHealthDB: Query(7X3B2, US-99A1)
    BladeHealthDB-->>MaintenanceServer: Health Status: 'Nominal'
    MaintenanceServer-->>Borescope: Redirect to /status/7X3B2/nominal.html

3.2. Derivative: AgTech - Autonomous Pest Detection and Response

Enabling Description: An array of acoustic sensors is deployed across an agricultural field, tuned to detect the specific wing-beat frequency of a target insect pest. When a sensor detects a sustained signature above a certain amplitude (the "trigger"), it records the signature's dominant frequency (the "identifier"). The sensor, acting as the "client device," transmits this identifier to a central farm management server ("ARS") via a LoRaWAN network. The server's database maps insect frequencies to specific organic pesticides. The server returns a command packet (the "content") which is redirected to a specific autonomous drone. The packet instructs the drone to fly to the sensor's GPS coordinates and apply the appropriate pesticide.

flowchart LR
    A[Acoustic Sensor] -- Detects Pest Frequency --> B{Transmit ID via LoRaWAN};
    B --> C[Farm Server (ARS)];
    C --> D{DB Lookup: Freq -> Pesticide};
    D --> E[Generate Drone Command Packet];
    C -- Redirect Packet --> F[Pesticide Drone];
    F --> G[Fly to GPS & Apply Pesticide];

3.3. Derivative: Consumer Electronics - Smart Appliance Consumable Reordering

Enabling Description: A smart water filter pitcher contains a sensor that measures the volume of water passed through its filter cartridge. When the volume exceeds a predefined threshold, the device's firmware is triggered. It generates an identifier containing the pitcher's model number and the filter type. Instead of audio, it uses the home's Wi-Fi network to send an HTTP request with this identifier to the manufacturer's cloud service ("ARS"). The ARS maintains a database linking product identifiers to e-commerce APIs (e.g., Amazon Dash Replenishment). The ARS returns an API endpoint URL to the pitcher, which the pitcher's firmware then calls to automatically place an order for a new filter, using pre-authorized user credentials.

sequenceDiagram
    participant FilterPitcher
    participant ManufacturerCloud (ARS)
    participant ECommerceAPI

    FilterPitcher->>FilterPitcher: Water Volume > Threshold
    FilterPitcher->>ManufacturerCloud: POST /reorder (ID: FP-MODEL-X-F7)
    ManufacturerCloud->>ManufacturerCloud: Lookup ID -> API Endpoint
    ManufacturerCloud-->>FilterPitcher: Redirect to api.ecom.com/order/F7
    FilterPitcher->>ECommerceAPI: POST /order/F7 (auth_token)
    ECommerceAPI-->>FilterPitcher: 200 OK (Order Placed)

4. Integration with Emerging Technology

4.1. Derivative: AI-Personalized Content Redirection

Enabling Description: The client device software incorporates a lightweight AI agent that maintains a user profile based on local device usage. When a broadcast trigger is received, the identifier is first processed by this local agent. The agent analyzes the user's current context (e.g., time of day, calendar appointments, location) and appends a context vector to the identifier before sending it to the ARS. The ARS is an AI-powered inference engine. It uses the identifier and the context vector to predict the user's intent, and instead of returning a static URL, it redirects the user to a dynamically generated, personalized landing page or a conversational AI assistant pre-loaded with the relevant topic.

flowchart TD
    A[Broadcast Signal w/ Identifier] --> B{Client Device Receives};
    B --> C[Local AI Agent Analyzes Context];
    C --> D[Append Context Vector to Identifier];
    D --> E[Send Enriched ID to AI-Powered ARS];
    E --> F{ARS Predicts User Intent};
    F --> G[Dynamically Generate Personalized URL];
    E -- Redirect --> H[User Browser];
    H --> G;

4.2. Derivative: IoT Mesh Network Trigger and Action

Enabling Description: The system is implemented in an industrial IoT setting (e.g., a factory floor). A machine tool begins to vibrate outside of its normal operating parameters. A vibration sensor (an IoT device) detects this anomaly and broadcasts a "trigger" packet containing its own device ID and a vibration signature ID onto a local 6LoWPAN mesh network. A nearby gateway device (the "client") receives this packet. The gateway sends the IDs to a factory management server (the "ARS"). The ARS looks up the machine and vibration signature, and returns two redirects: one to the maintenance supervisor's tablet with a link to the machine's diagnostic page, and another to the machine tool's own control unit with a command to enter a safe, low-power state.

sequenceDiagram
    participant VibrationSensor
    participant Gateway
    participant FactoryServer (ARS)
    participant SupervisorTablet
    participant MachineController

    VibrationSensor-->>Gateway: Anomaly Packet (DeviceID, VibID)
    Gateway->>FactoryServer: GET /alert?dev=D1&vib=V5
    FactoryServer-->>Gateway: Redirect A: /diag/D1
    FactoryServer-->>Gateway: Redirect B: /cmd/D1/safe-mode
    Gateway->>SupervisorTablet: Push /diag/D1
    Gateway->>MachineController: Push /cmd/D1/safe-mode

4.3. Derivative: Blockchain-Verified Trigger for Royalty Distribution

Enabling Description: This derivative is used for media royalty tracking. Each piece of media (e.g., a song) is registered on a public blockchain, creating an immutable record with its unique identifier (an NFT or similar token). When the song is played by a registered broadcaster (e.g., a streaming service), the service's player emits an "audio signal" containing the song's blockchain identifier and a signed attestation from the broadcaster. A listener's client application detects this signal. The client sends the identifier to a "Royalty ARS." The ARS verifies the broadcaster's signature and confirms the identifier's validity on the blockchain. It then returns a URL to the user for song info, but more importantly, it triggers a smart contract associated with the song's identifier, which automatically distributes a micro-payment from the broadcaster's wallet to the artists' wallets.

flowchart LR
    A[Broadcaster Plays Song] --> B(Emits Blockchain ID + Signature);
    B --> C{User Client Detects Signal};
    C --> D[Royalty ARS];
    D --> E{Verify Signature & Blockchain ID};
    subgraph Blockchain
        F[Smart Contract]
        G[Artist Wallets]
    end
    E -- Triggers --> F;
    F -- Distributes Micropayment --> G;
    D -- Returns Song Info URL --> C;

5. Inverse, Failure Mode, and Low-Power Derivatives

5.1. Derivative: Graceful Degradation via Local Cache

Enabling Description: The client application is designed for network-unreliable environments. It maintains a local, periodically updated SQLite database that acts as a lightweight cache of the ARS. This cache maps the most common or most recent identifiers to a locally stored, static HTML page containing essential information (e.g., an advertiser's phone number and address, but not their full interactive website). When the client software decodes an identifier from an audio signal, it first attempts to connect to the primary ARS. If the connection times out or fails, the software automatically queries the local SQLite database for the identifier. If a match is found, it loads the corresponding static page in the browser, providing a degraded but still functional user experience.

flowchart TD
    A[Identifier Decoded] --> B{Attempt Network Connection to ARS};
    B -- Success --> C[Fetch Redirect from ARS];
    B -- Failure/Timeout --> D{Query Local SQLite Cache};
    D -- Match Found --> E[Display Static Local HTML Page];
    D -- No Match --> F[Display Generic 'Network Error' Message];
    C --> G[Load Full Web Content];

5.2. Derivative: User-Initiated, Privacy-Preserving Mode

Enabling Description: The system includes a user-configurable "privacy mode." When this mode is enabled, the client software's behavior changes. Upon detecting and decoding an identifier from an audio signal, the software does not automatically launch the browser or make any network connection. Instead, it performs a lookup in a local database to find the name of the entity associated with the identifier (e.g., "Coca-Cola"). It then generates a non-intrusive OS-level notification (e.g., a toast notification on Android or a notification banner on iOS) that reads, "Interaction available from Coca-Cola. Tap to proceed." Only if the user explicitly taps this notification will the software initiate the network connection to the ARS. This requires affirmative user consent for every interaction, preventing passive tracking.

sequenceDiagram
    participant System
    participant User
    participant ARS

    System->>System: Decodes Identifier 'CC-123'
    System->>System: Local DB Lookup: 'CC-123' -> 'Coca-Cola'
    System->>User: Display Notification: "Interact with Coca-Cola?"
    User->>System: Taps Notification (Consent)
    System->>ARS: GET /lookup?id=CC-123
    ARS-->>System: Redirect to Coca-Cola Website

6. Combination with Open-Source Standards

6.1. Combination: DVB/ATSC Metadata Stream Integration

Enabling Description: The '106 method is combined with the DVB (Digital Video Broadcasting) or ATSC (Advanced Television Systems Committee) open standards. The trigger and identifier are not embedded in the analog audio track. Instead, they are encoded as a data object within the Event Information Table (EIT) or a private data stream within the MPEG-2 transport stream. A standard-compliant smart TV or set-top box ("client device") continuously parses this metadata. When it encounters the predefined data object, the device's resident operating system extracts the identifier, constructs the URL for the ARS, and launches its native web browser to initiate the lookup and redirection process, displaying the final content either full-screen or in a picture-in-picture overlay.

6.2. Combination: DNS TXT/SVCB Record for ARS Lookup

Enabling Description: The system leverages the existing, open-standard Domain Name System (DNS) to replace the proprietary ARS application server. The identifier extracted from the broadcast signal (e.g., A4B7) is prepended to a known domain, forming a fully qualified domain name like A4B7.trigger.net. The client device performs a DNS query for a specific record type—either a TXT record or an HTTPS/SVCB service binding record—associated with this FQDN. The DNS response itself contains the final destination URL (e.g., "v=redir1 url=https://advertiser.com/promo/a4b7"). The client software parses this DNS record and directs the browser to the extracted URL. This offloads the redirection logic to globally distributed, highly resilient DNS infrastructure.

6.3. Combination: Bluetooth Beacon Eddystone-URL Standard

Enabling Description: The invention is combined with Google's open Eddystone-URL Bluetooth beacon standard. However, instead of broadcasting the final advertiser URL directly, the beacon is configured to broadcast a compressed URL pointing to the ARS and including the product identifier. For example, it broadcasts https://ars.co/[identifier]. A user's smartphone with BLE scanning enabled detects this beacon and offers to open the URL. When the user accepts, the phone's browser makes a request to the ARS. The ARS receives the request, performs its database lookup based on the identifier, and returns the 302 redirect to the final, full-featured advertiser URL. This combines the proximity-triggering of an open standard with the centralized, dynamic link management of the '106 patent's method.