Derivative works — US Patent 5978773

Defensive Disclosure and Prior Art Generation

Publication Date: April 28, 2026
Reference Patent: U.S. Patent 5,978,773
Subject Matter: System and method for using a standardized identification number on an article of commerce to retrieve a network address from a database for accessing a remote computer.

This document describes technical variations, extensions, and combinations of the system and method disclosed in U.S. Patent 5,978,773. The purpose of this disclosure is to place these concepts into the public domain, thereby establishing them as prior art for any future patent applications in this domain.

Derivative Works Based on Core Claims

Axis 1: Material & Component Substitution

1. Derivative: Radio-Frequency Identification (RFID) / Near Field Communication (NFC) Linkage

Enabling Description: An active or passive RFID or NFC tag is embedded within the article of commerce or its packaging. The tag stores the standardized identification number (e.g., a serialized GTIN). The input device is a stationary or handheld RFID/NFC reader that energizes the tag and reads the identification number without requiring a line of sight. The reader, connected via USB, Bluetooth, or TCP/IP to a local host, transmits the number to the application software. The software then queries the database over a network to retrieve the associated URL, which could, for example, point to a real-time authentication or inventory management portal. The system utilizes standard ISO/IEC 14443 (NFC) or ISO/IEC 18000 series (RFID) protocols for communication between the tag and reader.

Mermaid Diagram:

sequenceDiagram
    participant User
    participant Reader as RFID/NFC Reader
    participant Tag as Embedded Tag
    participant LocalHost as Local Host Application
    participant DatabaseServer as Remote Database
    User->>Reader: Bring product near reader
    Reader->>Tag: Energize and request ID
    Tag-->>Reader: Transmit Identification Number
    Reader->>LocalHost: Send ID via Bluetooth/USB
    LocalHost->>DatabaseServer: Query database with ID
    DatabaseServer-->>LocalHost: Return associated Network Address
    LocalHost->>User: Display/Access resource at Address

2. Derivative: Direct Object & Logo Recognition

Enabling Description: The input device is a standard digital camera, such as one integrated into a smartphone or kiosk. Instead of a barcode, the system uses a machine learning model, specifically a pre-trained Convolutional Neural Network (CNN) like ResNet or MobileNet, to perform object recognition. The model is trained to identify the unique packaging, shape, or logo of the article of commerce. Upon a successful identification with a confidence score exceeding a predefined threshold (e.g., 95%), the model outputs the associated product identification number. This number is then used to perform the database lookup as described in the reference patent. This obviates the need for any printed barcode, using the product's inherent visual design as the indicia.

Mermaid Diagram:

flowchart TD
    A[Capture Image of Product] --> B{Image Processing};
    B --> C[CNN Model Inference];
    C --> D{Confidence Score > 95%?};
    D -- Yes --> E[Output Product ID];
    D -- No --> F[Recognition Failed];
    E --> G[Query Remote Database with ID];
    G --> H[Retrieve Network Address];
    H --> I[Access Remote Computer];

3. Derivative: Acoustic Signature Identification

Enabling Description: The system uses a microphone as the input device. The "indicia" is a unique acoustic signature, which can be either active (an ultrasonic watermark embedded in a product's advertisement or in-store audio) or passive (the characteristic sound the product makes, such as the snap of a specific container lid). The local host application performs a Fast Fourier Transform (FFT) on the captured audio to generate a spectrogram. This spectrogram is then compared against a library of pre-computed acoustic fingerprints using a perceptual hashing algorithm (pHash). A successful match yields the product identification number, which is then used to query the database for the associated network address.

Mermaid Diagram:

graph LR
    subgraph Local Host
        A(Microphone) -- Captures Audio --> B(Signal Processor);
        B -- FFT --> C(Spectrogram Generation);
        C -- pHash --> D(Fingerprint Matching);
    end
    subgraph Remote Server
        E(Fingerprint Library);
    end
    D -- Query --> E;
    E -- Returns Product ID --> D;
    D -- Sends ID --> F(Database Lookup);
    F -- Returns URL --> G(Access Resource);

Axis 2: Operational Parameter Expansion

1. Derivative: Nanoscale Identification and Data Linking

Enabling Description: This system operates at the molecular or nanoscale for laboratory research and material science applications. The "article" is a batch of quantum dots or other nanoparticles. The "indicia" is the unique spectroscopic signature (e.g., emission spectrum) of the nanoparticles, read by a spectrometer. The spectrometer software generates a unique identifier based on the peak wavelength and full width at half maximum (FWHM). This identifier is used to query a Laboratory Information Management System (LIMS) database. The database links the signature to a complete data record, including synthesis parameters, electron microscopy images, and URLs to published research utilizing that specific batch of nanoparticles.

Mermaid Diagram:

stateDiagram-v2
    [*] --> ReadingSignature
    ReadingSignature: Spectrometer captures emission spectrum
    ReadingSignature --> GeneratingID: Generate unique ID from peak wavelength & FWHM
    GeneratingID --> QueryingLIMS: Use ID to query LIMS database
    QueryingLIMS --> RetrievingData: LIMS returns URL to research data/images
    RetrievingData --> [*]

2. Derivative: High-Throughput Industrial Sorting System

Enabling Description: In a manufacturing or logistics facility, articles on a conveyor belt move at high speed (e.g., 5 meters/second). A high-frame-rate industrial camera (e.g., 1000 fps) captures images of each article. A dedicated image processing server with GPU acceleration identifies a 2D Data Matrix code on each product. The decoded identification number is sent to a local, low-latency database (e.g., an in-memory Redis instance) which acts as a cache for the primary remote database. The lookup retrieves not a URL for a browser, but a routing command for the Manufacturing Execution System (MES). The MES then actuates a pneumatic sorter to direct the article to the appropriate downstream process or shipping lane, all within a time budget of less than 100 milliseconds per article.

Mermaid Diagram:

sequenceDiagram
    participant Camera
    participant ImageProc as Image Processing Server
    participant Cache as Redis Cache
    participant MES as Manufacturing Execution System
    participant Sorter
    loop For Each Article
        Camera->>ImageProc: Stream Video Frame
        ImageProc->>ImageProc: Decode Data Matrix
        ImageProc->>Cache: Query with Article ID
        Cache-->>ImageProc: Return Routing Command
        ImageProc->>MES: Send Command
        MES->>Sorter: Actuate Sorter
    end

Axis 3: Cross-Domain Application

1. Derivative: Aerospace Component Lifecycle Management

Enabling Description: Every critical aircraft component is permanently marked with a unique identifier compliant with the ATA Spec 2000 standard, typically via a laser-etched 2D data matrix. During maintenance, a technician uses a ruggedized handheld scanner to read this mark. The identifier is sent over a secure wireless link to a private, cloud-hosted database. The database retrieves a network address pointing to a specific API endpoint. This endpoint provides access to the component's digital twin, a complete data record including its original manufacturing specifications, flight hours, stress test results, maintenance history, and a link to an augmented reality (AR) file for displaying work instructions directly overlaid on the component.

Mermaid Diagram:

erDiagram
    COMPONENT ||--o{ LOG_ENTRY : has
    COMPONENT {
        string componentID PK
        string partNumber
        string serialNumber
    }
    LOG_ENTRY {
        int logID PK
        string componentID FK
        datetime timestamp
        string eventType
        string details
        string arDataURL
    }

2. Derivative: AgTech Plant-Specific Intervention

Enabling Description: In a precision agriculture setting, individual plants or small sections of a field are identified by a unique signature derived from hyperspectral imagery captured by an autonomous drone. An image processing algorithm analyzes the unique spectral reflectance of the plant(s) to generate a consistent identifier. This identifier is used to query a geospatial database. The database links the plant's location and identifier to its history (genetics, planting date, soil moisture levels) and retrieves a network address for a specific set of instructions on a variable rate irrigation/fertilizer system. This allows for automated, tailored application of resources at the individual plant level.

Mermaid Diagram:

flowchart TD
    A[Drone captures hyperspectral image] --> B[Image processing server];
    B --> C{Generate unique spectral ID for plant};
    C --> D[Query Geospatial Database with ID];
    D --> E{Retrieve plant history & required intervention};
    E --> F[Generate instructions for VRT];
    F --> G(Variable Rate Applicator);

Axis 4: Integration with Emerging Tech

1. Derivative: AI-Powered Personalized Consumer Experience

Enabling Description: A user scans a UPC on a food product. The UPC is sent to a cloud service along with anonymized context data (e.g., time of day, general location). An AI/ML inference engine receives the UPC and context. It queries multiple databases to retrieve product information, the user's dietary preferences (if opted-in), and local store inventory. The AI then dynamically generates a personalized "experience" URL. This URL leads to a web page featuring not just product info, but recipes using that product which are compatible with the user's diet, a coupon valid at a nearby store that has the item in stock, and a tutorial video on how to prepare one of the recipes.

Mermaid Diagram:

graph TD
    subgraph User Device
        A[Scan UPC] --> B(Send UPC + Context);
    end
    subgraph Cloud Platform
        C(API Gateway);
        D(AI/ML Engine);
        E(Product DB);
        F(User Profile DB);
        G(Inventory DB);
    end
    B --> C --> D;
    D --> E;
    D --> F;
    D --> G;
    D --> H{Generate Personalized URL};
    H --> C;
    C --> I(Return URL to User);
    I --> J[User accesses dynamic content];

2. Derivative: Blockchain-Verified Product Provenance

Enabling Description: Each article of commerce (e.g., a luxury handbag, a bottle of fine wine) is assigned a unique, serialized identifier encoded in a QR code. This identifier is cryptographically linked to a non-fungible token (NFT) on a public blockchain (e.g., Ethereum). When a user scans the QR code, the application uses the identifier to query a blockchain indexing service (like The Graph). The service returns a URL to a decentralized application (dApp) interface. This dApp displays the product's immutable provenance, showing every transaction from the manufacturer to the current owner, along with links to certificates of authenticity stored on the InterPlanetary File System (IPFS).

Mermaid Diagram:

sequenceDiagram
    participant UserApp
    participant QR as QR Code
    participant Indexer as Blockchain Indexer
    participant Blockchain
    participant IPFS
    UserApp->>QR: Scan Code (get Product ID)
    UserApp->>Indexer: Query with Product ID
    Indexer-->>UserApp: Return dApp URL
    UserApp->>UserApp: Open dApp
    UserApp->>Blockchain: Fetch Ownership History
    Blockchain-->>UserApp: Return Transaction Log
    UserApp->>IPFS: Fetch Certificate of Authenticity
    IPFS-->>UserApp: Return Certificate

Axis 5: The "Inverse" or Failure Mode

1. Derivative: Graceful Degradation with Cached Offline Content

Enabling Description: The system is implemented in a mobile application for field technicians who may have intermittent connectivity. The application maintains a local SQLite database that caches critical data. When a technician scans a machine part's ID, the app first attempts a lookup against the local SQLite database. If a record is found, it provides the cached network address, which points to safety manuals and basic schematics already stored on the device. Simultaneously, it queues an asynchronous request to the primary remote server. If and when that request succeeds, the app notifies the user that updated information (e.g., real-time diagnostics) is available and updates its local cache with the latest URL and associated content.

Mermaid Diagram:

stateDiagram-v2
    state "Online" as On
    state "Offline" as Off

    [*] --> Off
    On --> Off: Network Lost
    Off --> On: Network Acquired

    state Off {
        [*] --> Scanning
        Scanning --> LocalLookup: On Scan
        LocalLookup --> DisplayCached: Record Found
        LocalLookup --> NoData: No Record
        DisplayCached --> Scanning
        NoData --> Scanning
    }

    state On {
        [*] --> Scanning
        Scanning --> RemoteLookup: On Scan
        RemoteLookup --> DisplayLive: Success
        RemoteLookup --> LocalLookup: Fail/Timeout
        DisplayLive --> CacheUpdate: Update local DB
        CacheUpdate --> Scanning
    }

Combination Prior Art with Open-Source Standards

1. Combination: GS1 Digital Link + DNS Resolver

Enabling Description: The invention's method is implemented using the open GS1 Digital Link standard, which defines a web-addressable syntax for existing UPC/GTINs. The "indicia" is a standard UPC barcode 049123456789. A scanning application transforms this into the GS1 Digital Link URI: https://id.gs1.org/gtin/0049123456789. The "local host" is a standard DNS resolver. It initiates a DNS query for this URI. The "database" is the global Domain Name System. The GS1 server is configured with DNS records (e.g., CNAME or A records with HTTP redirects) that associate that specific path with a final network address provided by the product manufacturer. The "retrieving" step is the standard DNS resolution process, making the entire system function using open, federated internet infrastructure.

2. Combination: Decentralized Identifiers (DIDs) + Verifiable Credentials (VCs)

Enabling Description: A product is marked with a QR code containing a W3C standard Decentralized Identifier (DID), such as did:ion:EiC.... The "input device" is a smartphone camera, and the "local host" application contains an open-source DID resolver library. The "database lookup" is the process of resolving the DID, which involves querying a distributed ledger (the DID method's "database," e.g., Bitcoin or a dedicated identity network) to retrieve a DID Document. This JSON-LD document contains service endpoints, one of which is the "network address." This address points to a server that can issue a W3C standard Verifiable Credential, providing cryptographically-verifiable claims about the product, such as its origin or organic status.

3. Combination: MQTT + Sparkplug for IIoT

Enabling Description: In an Industrial IoT (IIoT) factory setting, a machine part is identified by a standardized asset ID on its nameplate. An operator scans the ID. The "local host" application uses this ID to construct an MQTT topic string according to the open Eclipse Sparkplug specification (e.g., spv1.0/MyFactory/NBIRTH/MyMachine-123). The application then subscribes to this topic on an open-source MQTT broker (e.g., EMQ X). The "remote computer" is the machine's embedded controller, which, upon connection to the broker, publishes its full data model and a URL to its HMI/documentation as a Sparkplug "NBIRTH" message on that topic. The "database" is the MQTT broker itself, which associates the topic (derived from the ID) with the publisher. The "retrieved network address" is the URL contained within the payload of the received NBIRTH message.