Derivative works — US Patent 5905248

Defensive Disclosure and Prior Art Generation

Reference Patent: U.S. Patent 5,905,248
Subject Matter: System and method for initiating an internet-based transaction by scanning a physical symbol encoded with a Uniform Resource Locator (URL), which directs a client device to a web document containing a transaction-enabling applet that is automatically launched and executed.
Purpose: This document establishes public prior art for a series of derivative inventions and improvements related to the core claims of U.S. Patent 5,905,248. The disclosures herein are intended to be enabling for a person having ordinary skill in the art, thereby rendering subsequent patent applications for these concepts as obvious or lacking novelty.

Axis 1: Material & Component Substitution

Derivative 1.1: Near-Field Communication (NFC) Initiated Transaction Applet

Enabling Description: The optical barcode symbol is replaced with a passive Near-Field Communication (NFC) tag (ISO/IEC 14443 compliant). The URL is written to the tag's NDEF (NFC Data Exchange Format) record. The code symbol reader is an NFC-enabled mobile device (smartphone, tablet). When the device is brought within proximity (typically < 4 cm) of the NFC tag, the device's operating system automatically reads the NDEF record, identifies the URI (Uniform Resource Identifier), and launches the default web browser to the specified URL. The web server at this URL serves an HTML5 document containing a JavaScript-based transaction application (replacing the Java Applet) which executes automatically upon page load to handle the transaction.

Mermaid Diagram:

sequenceDiagram
    participant UserDevice as Mobile Device (NFC Enabled)
    participant NFCTag as NFC Tag
    participant WebServer as HTTP Server
    participant TransactionApp as Web App (JavaScript)

    UserDevice->>+NFCTag: Tap device on tag
    NFCTag-->>-UserDevice: Transmit NDEF Record (contains URL)
    UserDevice->>UserDevice: OS URI Handler launches browser
    UserDevice->>+WebServer: HTTP GET Request (URL from tag)
    WebServer-->>-UserDevice: HTTP 200 OK (HTML/JS Payload)
    UserDevice->>+TransactionApp: Browser executes JavaScript on load
    TransactionApp-->>-UserDevice: Render transaction interface

Derivative 1.2: Biometric-Indexed Transaction Applet Launch

Enabling Description: The transaction initiation is triggered by a biometric scan rather than a manufactured symbol. A user's biometric data (e.g., a fingerprint hash, iris template) is pre-registered in a secure database and linked to a specific transaction URL. The "reader" is a standard biometric scanner (e.g., FAP 30 fingerprint sensor) connected to a client terminal. Upon a successful scan, the terminal generates a hash of the biometric data and sends it to a secure lookup server. The server retrieves the corresponding URL and returns it to the client terminal. The client terminal then launches a web browser and navigates to the returned URL, where the transaction applet is served and executed.

Mermaid Diagram:

flowchart TD
    A[User presents biometric] --> B{Biometric Scanner};
    B --> C[Generate Biometric Hash];
    C --> D[Send Hash to Lookup Server];
    subgraph Secure Backend
        D --> E{Biometric DB};
        E -- URL --> F[Retrieve Associated URL];
    end
    F --> G[Return URL to Client];
    G --> H{Client Terminal};
    H --> I[Launch Browser with URL];
    I --> J[Execute Transaction Applet];

Derivative 1.3: Thermochromic Ink for Conditional URL Visibility

Enabling Description: The URL is encoded in a 2D barcode (e.g., QR Code) printed using thermochromic ink that is invisible at a standard ambient temperature (e.g., 20°C) but becomes visible and scannable above a specific activation temperature (e.g., 35°C). A transaction kiosk is equipped with a standard optical scanner and a controlled heating element (e.g., a Peltier device or infrared lamp). To initiate a transaction, the user places their transaction card on a designated platen. The heating element raises the surface temperature of the card, revealing the barcode. The optical scanner then reads the URL, and the system proceeds to launch the transaction applet. This provides a physical security layer, as the URL is not scannable via casual photography.

Mermaid Diagram:

stateDiagram-v2
    [*] --> Inactive
    Inactive: Card at ambient temp. Barcode invisible.
    Inactive --> Heating: User places card on platen
    Heating: Peltier element warms card to >35°C
    Heating --> Scannable: Barcode becomes visible
    state Scannable {
        direction LR
        [*] --> Scanning
        Scanning --> Success: Scanner reads URL
        Scanning --> Timeout: Scanner fails to read
        Success --> [*]
        Timeout --> Inactive
    }
    Scannable --> Inactive: Card cools down

Axis 2: Operational Parameter Expansion

Derivative 2.1: DNA-Encoded URL for Nanoscale Biological Transactions

Enabling Description: The URL is encoded as a sequence of nucleotide bases (A, C, G, T) and synthesized into a single-stranded DNA molecule. This DNA is suspended in a solution or affixed to a substrate. The "reader" is a nanopore sequencing device (e.g., Oxford Nanopore MinION). The DNA sample is introduced to the sequencer, which determines the base sequence in real-time. A connected computer translates the base sequence back into an ASCII URL string using a predefined encoding scheme (e.g., 2 bits per base). The computer then launches a browser to this URL, which opens a specialized web applet for bioinformatics, such as ordering a custom synthetic gene from a genomics foundry or querying a protein folding database.

Mermaid Diagram:

graph LR
    A(DNA Strand w/ Encoded URL) -- Sampled --> B(Nanopore Sequencer);
    B -- Electrical Signals --> C(Basecalling Software);
    C -- Nucleotide Sequence --> D(Decoder Module);
    D -- "ACGT -> 'http://...'" --> E(ASCII URL String);
    E --> F(Web Browser);
    F -- HTTP Request --> G(Genomics Web Server);
    G -- Applet --> F;

Derivative 2.2: Long-Range Optical Scan for Industrial Asset Management

Enabling Description: A large-format (e.g., 1m x 1m) 2D barcode with high error correction (e.g., QR Code Level H) is affixed to industrial equipment, such as a wind turbine nacelle or a large chemical tank. The "reader" is a drone or robotic vehicle equipped with a high-resolution camera and a telephoto lens. The drone navigates to the asset, captures an image of the barcode from a standoff distance (e.g., 50-100 meters), and performs image processing to decode the URL. The URL includes the unique asset ID and points to a web-based industrial IoT platform. The platform's applet launches, displaying real-time telemetry from the asset's sensors, its complete maintenance history, and providing controls for remote diagnostics.

Mermaid Diagram:

sequenceDiagram
    participant Drone as UAV with Camera
    participant Asset as Industrial Equipment
    participant GroundControl as Ground Control Station
    participant IIoT_Platform as Industrial IoT Server

    GroundControl->>+Drone: Fly to Asset Coordinates
    Drone->>Asset: Capture image of large-format barcode
    Drone-->>-GroundControl: Transmit image
    GroundControl->>GroundControl: Decode URL from image
    GroundControl->>+IIoT_Platform: HTTP Request (URL with Asset ID)
    IIoT_Platform-->>-GroundControl: Serve Asset Management Applet
    GroundControl->>GroundControl: Display telemetry and controls

Axis 3: Cross-Domain Application

Derivative 3.1: Aerospace In-Situ Component Analysis

Enabling Description: A unique Data Matrix code is laser-etched onto a critical, life-limited aerospace component (e.g., a compressor disk in a jet engine). During an on-wing inspection, a technician uses a ruggedized borescope equipped with a camera to scan the code. The borescope is connected to a tablet. The decoded URL contains the component's unique serial number. It directs the tablet's browser to a secure manufacturer's portal. A WebGL-based applet loads, rendering a 3D model of that specific component. The applet overlays historical manufacturing quality data, previous inspection reports, and live data from nearby sensors (e.g., vibration, temperature) streamed via a local avionics bus gateway. The technician can then log new inspection data directly into the applet, which updates the component's digital twin record.

Mermaid Diagram:

flowchart TD
    subgraph On-Wing Inspection
        A(Technician uses Borescope) --> B{Scan Etched Data Matrix};
        B --> C[Decode URL with Serial Number];
    end
    subgraph Tablet
        C --> D[Browser requests URL];
    end
    subgraph Secure Cloud
        D --> E(Manufacturer Server);
        E --> F[Authenticate Technician];
        F --> G{Serve Component Digital Twin Applet};
        G --> H(Load Manufacturing & Sensor Data);
    end
    H --> I{Render 3D Model & Data Overlay};
    I --> Tablet;
    Tablet --> J(Technician logs new inspection);
    J --> G;

Derivative 3.2: AgTech Livestock Health Management

Enabling Description: An electronic ear tag on a farm animal (e.g., a cow) contains an NFC chip storing a URL. The URL includes the animal's unique ID. A farmhand uses an NFC-enabled mobile device to scan the tag. This action launches a web applet connected to a farm management platform. The applet automatically pulls the animal's history (birth, vaccinations, breeding). It then uses the mobile device's camera and a client-side machine learning model (e.g., TensorFlow.js) to perform a real-time visual health assessment (e.g., analyzing gait, eye clarity, or body condition). The results are logged in the applet and a recommendation for action (e.g., quarantine, dietary change) is displayed.

Mermaid Diagram:

sequenceDiagram
    participant Farmer as Farmer's Mobile Device
    participant CowTag as Animal NFC Tag
    participant FarmServer as Farm Management Server
    participant MLModel as On-Device ML Model

    Farmer->>+CowTag: Scan NFC Ear Tag
    CowTag-->>-Farmer: Return URL with Animal ID
    Farmer->>+FarmServer: GET /animal/{ID}
    FarmServer-->>-Farmer: Serve Health Applet + Animal History
    Farmer->>Farmer: Activate Camera via Applet
    Farmer->>+MLModel: Perform Visual Health Analysis
    MLModel-->>-Farmer: Return Health Score/Metrics
    Farmer->>+FarmServer: POST /health-log/{ID} (Data from ML Model)
    FarmServer-->>-Farmer: Acknowledge & provide recommendation

Axis 4: Integration with Emerging Tech

Derivative 4.1: AI-Optimized Equipment Calibration

Enabling Description: A QR code on a scientific instrument (e.g., a mass spectrometer) encodes a URL pointing to a cloud-based management platform. When a technician scans the code, the launched web applet sends the instrument's unique ID to an AI backend. The AI model has been trained on performance data from thousands of similar instruments. It analyzes the specific instrument's recent usage patterns, error logs, and environmental sensor data (via IoT). The AI generates a dynamic, optimized calibration procedure tailored to the instrument's current state and anticipated workload, rather than a generic, fixed schedule. The applet then guides the technician through this custom procedure step-by-step.

Mermaid Diagram:

graph TD
    A[Scan QR Code on Instrument] --> B(Launch Calibration Applet);
    B -- Instrument ID --> C{AI Backend};
    subgraph Cloud Platform
        C -- Analyzes --> D(Historical Usage Data);
        C -- Analyzes --> E(IoT Sensor Data);
        C --> F[Generate Optimized Calibration Workflow];
    end
    F -- Custom Steps --> B;
    B --> G[Guide Technician through steps];

Derivative 4.3: Blockchain-Verified Supply Chain Audit

Enabling Description: A QR code on a pallet of high-value goods (e.g., organic produce) contains a URL. The URL points to a decentralized application (dApp) front-end. When a supply chain participant (e.g., a customs officer) scans the code, the dApp is launched. The dApp prompts the officer to connect their decentralized identity wallet (e.g., MetaMask). Using their wallet, the officer signs a transaction that records the scan event (location, timestamp, their public key) on a permissioned blockchain. The dApp then reads the blockchain and displays the complete, immutable chain of custody for that specific pallet, verifying its origin and path.

Mermaid Diagram:

sequenceDiagram
    participant Officer as Customs Officer's Device
    participant QRCode as Pallet QR Code
    participant dApp as dApp Frontend
    participant Wallet as Identity Wallet (MetaMask)
    participant Blockchain as Supply Chain Ledger

    Officer->>QRCode: Scan QR Code
    QRCode-->>Officer: Provide URL to dApp
    Officer->>+dApp: Load dApp Frontend
    dApp->>+Wallet: Request Wallet Connection
    Wallet-->>-dApp: Wallet Connected
    dApp->>+Wallet: Request Signature for Scan Event
    Wallet-->>-dApp: Return Signed Transaction
    dApp->>+Blockchain: Broadcast Signed Transaction
    Blockchain->>Blockchain: Record new custody event in block
    Blockchain-->>-dApp: Confirmation
    dApp->>+Blockchain: Read full history for Pallet ID
    Blockchain-->>-dApp: Return complete audit trail
    dApp-->>-Officer: Display verified chain of custody

Axis 5: The "Inverse" or Failure Mode

Derivative 5.1: Graceful Degradation with Embedded Fallback URL

Enabling Description: The data encoded in a QR code is a structured format (e.g., a JSON object) containing a primaryUrl and a fallbackUrl. A custom scanner application (instead of the OS-default) reads the QR code. It first attempts to make an HTTP HEAD request to the primaryUrl. If the request succeeds within a 500ms timeout and returns a 200-series status code, the app launches a full web view with this URL. If it fails or times out, the app immediately launches the fallbackUrl. The fallbackUrl points to a statically-generated, CDN-hosted, text-only HTML page that allows for submission of the most critical transaction data via a simple form, ensuring core functionality even in poor network conditions.

Mermaid Diagram:

flowchart TD
    A[Scan QR with structured data] --> B{Custom Scanner App};
    B --> C{"Extract primaryUrl & fallbackUrl"};
    C --> D{HTTP HEAD to primaryUrl};
    D -- Success (200 OK, <500ms) --> E[Launch full applet at primaryUrl];
    D -- Fail (Timeout, Error) --> F[Launch lite page at fallbackUrl];
    E --> G[Full Transaction];
    F --> H[Limited Transaction];

Combination Prior Art with Open-Source Standards

Scenario 1: OAuth 2.0 for Secure Service Onboarding: A QR code on a newly purchased IoT device contains a pre-formatted OAuth 2.0 authorization URL for the device manufacturer's service. The URL includes the client_id (representing the device model), a unique state parameter (tied to the device serial number), and the requested scope (e.g., device_registration, data_sync). When the user scans this code with their phone, it launches their browser, directs them to their chosen identity provider (e.g., Google, Apple), and initiates an authorization flow. Upon user consent, the provider redirects back to the manufacturer's service with an authorization code, which is then exchanged for an access token. This token securely links the physical device to the user's account without the user ever needing to manually enter serial numbers or passwords.
Scenario 2: WebAuthn for Phishing-Resistant Kiosk Authentication: An interactive kiosk for financial services displays a QR code containing a session-specific URL. A user scans the QR code with their mobile phone, which opens the URL in their phone's browser. The web page served is a remote authenticator interface. It initiates a WebAuthn ceremony, prompting the user to authenticate on their phone using a platform authenticator (Face ID, Android fingerprint). The phone signs a challenge and sends the signed assertion back to the kiosk's session via a secure WebSocket connection established by the applet. The kiosk verifies the assertion and logs the user into their account, completely bypassing the need for passwords on the public kiosk.
Scenario 3: Verifiable Credentials for Decentralized Access Control: A secure facility uses QR codes at entry points. The QR code contains a URL that initiates a request for a Verifiable Credential (VC) based on the W3C DID and VC standards. When an employee scans the code, the launched web applet communicates with their digital wallet on their device. The wallet presents a cryptographically signed VC issued by the company's HR department, proving their identity and access level (role: "Level 3 Engineer"). The applet verifies the VC's signature against the company's public DID. If valid, the applet sends a signal to the physical access control system to open the door.