Derivative works

Defensive Disclosure: U.S. Patent 11,461,828

Publication Date: May 10, 2026
Subject: Derivative Implementations and Obvious Extensions of Systems and Methods for Single-Gesture Wireless Transactions.
Abstract: This document discloses a series of technical variations, alternative embodiments, and cross-domain applications derived from the core principles described in U.S. Patent 11,461,828. The purpose of this disclosure is to place into the public domain a comprehensive set of foreseeable modifications and integrations, thereby rendering them obvious to a person having ordinary skill in the art. The disclosures herein cover component substitutions, expansions of operational parameters, novel applications in disparate industries, integration with emerging technologies, and fail-safe operational modes.

---

Axis 1: Material & Component Substitution

1.1: Acoustic Near-Field Data Transfer for Point-of-Sale Transactions

• Enabling Description: This embodiment replaces the radio-frequency (RF) transceiver (e.g., NFC, BLE) with a pair of ultrasonic micro-transducers operating in the 40-100 kHz range. The user device's transducer is coupled with its haptic engine. The "single function action" is the physical tapping of the user device against a designated resonant surface on the merchant terminal. The tap generates a specific mechanical impulse, which is detected by an accelerometer in the terminal, triggering it to listen for an incoming ultrasonic data packet. The user's device then modulates the payment data onto an ultrasonic carrier wave. Confirmation on the user's device is signaled back via a different ultrasonic frequency. This method is immune to RF skimming and interference.

sequenceDiagram
    participant UserDevice as User Device
    participant MerchantTerminal as Merchant Terminal
    UserDevice->>MerchantTerminal: Physical Tap (Single Function Action)
    MerchantTerminal-->>UserDevice: Activate Ultrasonic Listener
    UserDevice->>MerchantTerminal: Transmit Purchase Data Request (40kHz)
    MerchantTerminal-->>UserDevice: Send Purchase Details (40kHz)
    UserDevice->>User: Display Purchase Details
    User->>UserDevice: Confirm Purchase (Single Interaction)
    UserDevice->>MerchantTerminal: Transmit Encrypted Payment Token (50kHz)
    MerchantTerminal-->>UserDevice: Acknowledge Receipt (50kHz)

1.2: Integrated Data-Over-Power via Inductive Coupling

• Enabling Description: This variation utilizes the existing hardware for wireless power transfer (e.g., Qi standard) to create a data link. The "single function action" is placing the user device onto an inductive charging pad integrated into the point-of-sale counter. The initial power handshake protocol (as defined by the Wireless Power Consortium) is extended with custom data packets. Once the link is established, the merchant terminal modulates the purchase data onto the power-carrying magnetic field by varying the load. The user device demodulates this signal. The user's "single-interaction confirmation" authorizes the device to transmit its payment token back to the terminal using a backscatter modulation technique, momentarily altering its own coil's impedance.

flowchart TD
    A[User places Device on Charging Pad] -->|Single Function Action| B(Initiate Qi Power Handshake);
    B --> C{Extended Handshake?};
    C -->|Yes| D[Modulate Purchase Data onto Power Field];
    C -->|No| E[Standard Charging Only];
    D --> F[Device Demodulates & Displays Data];
    F --> G[User Confirms via Single Interaction];
    G --> H[Device Transmits Payment Token via Backscatter Modulation];
    H --> I[Terminal Receives Token & Completes Transaction];

---

Axis 2: Operational Parameter Expansion

2.1: Hydro-Acoustic Transaction System for Subsea Environments

• Enabling Description: This system is designed for transactions between an Autonomous Underwater Vehicle (AUV) and a subsea docking station. The AUV ("user device") initiates the "single function action" by physically latching with the station's docking port. The wireless link is established via hydro-acoustic modems operating between 10-20 kHz. The docking station ("merchant device") transmits data on available services (e.g., battery recharge cost, data offload fee) as the "purchase data". The AUV's mission controller, which may be remote, provides the "single-interaction confirmation" via a secure uplink, which causes the AUV to transmit a pre-funded cryptographic payment wallet address to the station to complete the transaction.

stateDiagram-v2
    [*] --> Disconnected
    Disconnected --> Connecting: AUV performs physical docking
    Connecting --> Authenticating: Acoustic modems handshake
    Authenticating --> Data_Exchange: Dock sends service data (cost, type)
    Data_Exchange --> Awaiting_Confirmation: AUV displays data to remote operator
    Awaiting_Confirmation --> Transmitting_Payment: Operator provides single-interaction approval
    Transmitting_Payment --> Confirmed: AUV sends payment token
    Confirmed --> Service_Delivery: Dock provides power/data transfer
    Service_Delivery --> Disconnected: AUV undocks
    Confirmed --> [*]

2.2: Ruggedized Infrared (IR) Data Link for Extreme Temperature Industrial Use

• Enabling Description: For use in industrial environments (e.g., foundries, cryogenic labs) where RF is unreliable and operators wear heavy protective gear. The user device is a ruggedized tablet with a high-power IR transceiver (e.g., IrDA standard on steroids). The "single function action" is pressing a large, physical, glove-friendly button on the device while aiming it at a corresponding IR port on a piece of machinery ("merchant device"). This triggers the IR link establishment. The machinery transmits diagnostic data or consumable costs ("purchase data"). The "single-interaction confirmation" is a voice command (e.g., "Confirm Purchase") authenticated by a pre-trained voiceprint model on the tablet, which then transmits an authorization code over the IR link.

graph TD
    subgraph User Device (Ruggedized Tablet)
        A[Physical Button Press] -->|Single Action| B(Activate IR Transceiver);
        B --> C(Transmit 'Request to Connect');
        E --> F{Display Data & Await Voice};
        G[Voice Input: 'Confirm'] --> H(Authenticate Voiceprint);
        H --> I[Transmit Authorization Code via IR];
    end
    subgraph Machine (Merchant Device)
        J(IR Port) --> K(Receive 'Request to Connect');
        K --> L(Establish Link & Transmit Data);
        L --> M(Receive Authorization Code);
        M --> N(Execute Action/Dispense Material);
    end
    C --> J;
    L --> E(Receive Data);
    I --> M;

---

Axis 3: Cross-Domain Application

3.1: Aerospace: Secure Avionics Configuration via Tablet

• Enabling Description: A flight maintenance crew member uses an authorized tablet ("user device") to update or reconfigure a module in an aircraft's avionics bay ("merchant device"). The "single function action" involves tapping the tablet on the specific Line-Replaceable Unit's (LRU) designated NFC touchpoint. This establishes a point-to-point encrypted link. The LRU transmits its current configuration and the proposed changes ("purchase data"). The technician provides a "single-interaction confirmation" using a biometric fingerprint scan on the tablet. This generates a digitally signed command packet containing the new configuration, which is transmitted to the LRU. The transaction is logged in the aircraft's maintenance log. The "payment" is the authorization and transfer of validated data.

classDiagram
    class Tablet {
      +string technicianID
      +biometricScanner
      +nfcController
      +signConfiguration(configData)
      +transmitSignedPacket()
    }
    class Avionics_LRU {
      +string partNumber
      +string currentConfig
      +nfcController
      +receiveSignedPacket(packet)
      +applyConfiguration()
      +logMaintenanceEvent()
    }
    Tablet "1" -- "1" Avionics_LRU : communicates via NFC

3.2: AgTech: Automated Resource Dispensing for Smart Farming Implements

• Enabling Description: A smart seeder ("user device") autonomously docks with a silo ("merchant device") to refill its hopper. The physical docking is the "single function action," detected by contact sensors and initiating a Wi-Fi Direct connection. The silo's control unit transmits the type of seed available and the cost per kilogram ("purchase data"). The seeder's onboard computer verifies this against its work order, and if it matches, sends an authorization request to the central farm management server. The server's automated response is the "single-interaction confirmation," which triggers the seeder to transmit a payment/inventory-deduction token to the silo. The silo then dispenses the specified amount of seed.

sequenceDiagram
    participant Seeder as Smart Seeder
    participant Silo as Dispensing Silo
    participant FarmServer as Central Mgmt. Server

    Seeder->>Silo: Physical Docking (Single Action)
    Silo-->>Seeder: Establish Wi-Fi Direct & Send Seed/Cost Data
    Seeder->>FarmServer: Request Authorization (Work Order vs. Silo Data)
    FarmServer-->>Seeder: Grant Authorization (Single Interaction Confirmation)
    Seeder->>Silo: Transmit Payment/Inventory Token
    Silo->>Seeder: Dispense Seed
    Silo->>FarmServer: Log Transaction

3.3: Consumer Electronics: Tap-to-Provision Secure IoT Device

• Enabling Description: A user onboards a new smart camera ("merchant device") to their home network using their smartphone ("user device"). The "single function action" is tapping the phone against an NFC logo on the camera. The camera uses the energy from the NFC field to power up its NFC chip and transmit its unique device ID and a request for network credentials ("purchase data"). The phone's OS prompts the user "Allow [Camera XYZ] to join your Wi-Fi network?". The user's Face ID scan serves as the "single-interaction confirmation," which authorizes the phone to securely transmit the encrypted SSID, password, and a unique device token ("payment data") to the camera via the NFC link.

flowchart LR
    A[User Taps Phone to Camera] -- Single Function Action --> B(NFC Handshake);
    B -- Device ID & Credential Request --> C[Phone OS Prompt];
    C -- "Allow Device to Join Network?" --> D(User Authenticates with Face ID);
    D -- Single Interaction --> E[Phone Encrypts Wi-Fi Credentials];
    E -- Transmit Secure Packet --> F(Camera Receives & Decrypts);
    F --> G[Camera Joins Wi-Fi Network];

---

Axis 4: Integration with Emerging Tech

4.1: AI-Powered Predictive Transaction Pre-Staging

• Enabling Description: A user's smartphone runs a federated learning model that analyzes location, time of day, calendar entries, and purchase history. Upon entering a geofenced area of a frequent merchant (e.g., a coffee shop), the AI predicts the user's likely order (e.g., "Large black coffee") and pre-stages a transaction with the merchant's cloud-based POS system via an API. The "purchase data" is already loaded. The user's "single function action" of tapping their phone to the terminal instantly brings up the predicted order on both the terminal's and the phone's screens. The user's "single-interaction confirmation" (e.g., a tap) simply confirms the pre-staged order, completing the transaction in milliseconds. The AI also selects the payment method with the optimal rewards or lowest foreign transaction fee in real-time.

sequenceDiagram
    participant UserAI as On-Device AI
    participant MerchantCloud as Merchant Cloud POS
    participant UserDevice as User Device
    participant MerchantTerminal as Merchant Terminal

    UserAI->>MerchantCloud: User entered geofence. Pre-stage predicted order.
    MerchantCloud-->>UserAI: Order staged with ID: 123
    UserDevice->>MerchantTerminal: NFC Tap (Single Function Action)
    MerchantTerminal->>MerchantCloud: NFC payload received, retrieve order 123.
    MerchantCloud-->>MerchantTerminal: Display: Large black coffee.
    MerchantCloud-->>UserDevice: Display: Large black coffee.
    UserDevice->>MerchantTerminal: User Confirmation (Single Interaction)
    MerchantTerminal->>MerchantCloud: Finalize payment for order 123.

4.2: Blockchain-Verified Transaction with NFT Warranty Issuance

• Enabling Description: This system enhances high-value retail transactions. The transaction flow proceeds as normal up to the final step. Upon "single-interaction confirmation" from the user, the user device constructs a transaction payload including merchant ID, item serial number, price, and timestamp. This payload is signed with the user's private key stored in the secure element. Instead of transmitting card details, this signed payload is submitted as a transaction to a smart contract on a public blockchain (e.g., Ethereum). The smart contract validates the transaction and, upon successful payment settlement (e.g., via a stablecoin), automatically mints a Non-Fungible Token (NFT) representing the item's warranty and proof of ownership, transferring it to the user's blockchain wallet address.

graph TD
    A[Start Transaction] --> B(NFC Tap);
    B --> C(Merchant sends Item Data);
    C --> D(User confirms w/ Biometrics);
    D --> E[Device constructs & signs payload<br/>{item_id, serial, price, ts}];
    E --> F{Blockchain Smart Contract};
    F --> G[Verifies & Processes Payment];
    G --> H[Mints & Transfers Ownership/Warranty NFT to User Wallet];
    G --> I[Sends Confirmation to Merchant];
    I --> J[Transaction Complete];

---

Axis 5: The "Inverse" or Failure Mode

5.1: Offline Transaction via Signed Cryptographic Promissory Token

• Enabling Description: In a network-denied environment (e.g., subway, remote area), the system shifts to an offline, store-and-forward mode. The initial handshake and data exchange via NFC or BLE occur as usual. When the user provides the "single-interaction confirmation," the user device—detecting no internet connectivity—generates a time-stamped, single-use cryptographic token. This token contains the merchant ID, transaction amount, and is digitally signed by a key within the device's secure element, acting as a promissory note. The merchant terminal stores this token. Later, when the terminal regains connectivity, it submits the collected batch of signed tokens to a payment processor for settlement. This allows commerce to continue without a live network connection.

stateDiagram-v2
    state "Offline Mode" as Offline {
        [*] --> Handshake: User Taps Terminal
        Handshake --> Data_Exchange: Purchase details sent to device
        Data_Exchange --> Awaiting_Confirmation: User prompted to confirm
        Awaiting_Confirmation --> Token_Generated: User confirms, device signs offline token
        Token_Generated --> Transaction_Complete: Token stored on Merchant & User devices
        Transaction_Complete --> [*]
    }
    state "Online Mode" as Online {
        [*] --> Batch_Upload: Terminal connects to network
        Batch_Upload --> Settlement: Processor validates & settles signed tokens
        Settlement --> [*]
    }

5.2: Low-Power Passive NFC Mode for Transit/Vending

• Enabling Description: The user device is in a deep power-save mode or has a depleted battery. Only the NFC controller, which can be powered parasitically by an NFC reader's field, remains active. This mode is pre-configured by the user for "Express Transit" or low-value payments. The "single function action" is tapping the device to the reader. The reader provides power and sends a payment request. Because this mode is pre-authorized, the "single-interaction confirmation" is bypassed. The NFC controller, operating without the main CPU, accesses a dedicated, pre-funded payment token from the secure element and transmits it to the reader. This allows for critical, low-value payments even when the device is otherwise non-functional.

flowchart TD
    subgraph Device (Low Power)
        A(NFC Controller) -- Powered by --> B[Reader's RF Field];
        A --> C(Secure Element);
        C -- Pre-funded Token --> A;
    end
    subgraph Reader (POS/Turnstile)
        B -- Sends Payment Request --> A;
        A -- Transmits Token --> B;
        B --> D[Process Payment];
    end

---

Combination Prior Art Scenarios

1. Combination with W3C Web Payments & FIDO2/WebAuthn: A user initiates a transaction by scanning a QR code on a merchant's web-based POS terminal, which triggers the W3C Web Payments API in the mobile browser. The browser then calls the FIDO2/WebAuthn API, allowing the user to provide a "single-interaction" biometric confirmation to authorize the payment. The combination of these open standards for in-browser payment initiation and cryptographic authentication renders a web-based implementation of the '828 patent's flow obvious.

2. Combination with Bluetooth GATT & GPG: A transaction is conducted over Bluetooth Low Energy using a standardized Generic Attribute Profile (GATT) for point-of-sale communication. After the "single function action" of pairing, the merchant device's GATT service exposes its public GPG key as a readable characteristic. The user's "single-interaction confirmation" triggers the client device to fetch this key, encrypt the payment data using the well-established open-source GPG protocol, and write it to a secure characteristic on the server, making the specific method of securing the BLE link obvious.

3. Combination with ISO/IEC 18013-5 (mDL) & NFC: The '828 patent's user flow is applied to identity verification. A user taps their phone, containing a mobile Driver's License (mDL), to a merchant's NFC reader to prove their age. The reader requests only the "is_over_21" data element as defined by the ISO/IEC 18013-5 open standard. The mDL application prompts the user for a "single-interaction" biometric confirmation to release this single piece of information. The combination of the patent's interaction flow with this public identity standard for selective data disclosure is a direct and obvious application.