Derivative works

Defensive Disclosure and Prior Art Derivations for Namespace Security Mechanisms

Subject Patent: US 12,254,103 B2
Publication Date: May 1, 2026
Purpose: This document discloses a series of technical implementations, variations, and applications derived from the core concepts of US patent 12,254,103. The intent is to place these concepts into the public domain to serve as prior art against future patent applications claiming these or similar incremental innovations.

---

Axis 1: Material & Component Substitution

Derivative 1.1: Ultrasonic Data-Over-Audio for Namespace Negotiation

• Enabling Description: This derivative replaces the Near Field Communication (NFC) or Bluetooth Low Energy (BLE) communication layer with a modulated ultrasonic data-over-audio protocol. The mobile device's speaker emits high-frequency (e.g., 18-22 kHz) audio signals imperceptible to most humans, which are encoded with the list of supported eID namespaces. The reader terminal uses a dedicated microphone and a digital signal processor (DSP) to demodulate the audio stream, decode the namespace list, and select a candidate. It then transmits its selection and subsequent authentication data back to the mobile device's microphone using a similar ultrasonic signal. The security policy template, normally a bytestring, is transmitted as a compressed binary-coded decimal (BCD) sequence optimized for low-bandwidth acoustic channels. This substitution is advantageous in environments with high RF interference or where physical "line-of-sight" (or at least "line-of-sound") is a desired security feature to prevent remote skimming.

sequenceDiagram
    participant MD as Mobile Device (Speaker/Mic)
    participant RT as Reader Terminal (Mic/Speaker)

    MD->>+RT: Encoded Ultrasonic Signal (Broadcasts Namespace List: [NS_A, NS_B])
    Note over RT: DSP Demodulates Signal
    RT->>-MD: Modulated Ultrasonic Signal (Selects Namespace: NS_B)
    MD->>+RT: Ultrasonic Signal (Transmits Security Policy for NS_B)
    Note over RT: Evaluates Policy (e.g., requires signed nonce)
    RT->>-MD: Ultrasonic Signal (Transmits Signed Nonce)
    Note over MD: Verifies Signature
    MD->>RT: Ultrasonic Signal (Grants Access; Transmits Data)

Derivative 1.2: Software-Based Trusted Execution Environment (TEE) for Policy Storage

• Enabling Description: This variation replaces the hardware-based secure element (e.g., embedded UICC or eSE) with a software-based Trusted Execution Environment (TEE) implemented using technologies like ARM TrustZone or Intel SGX. The eID wallet application is split into two parts: a "normal world" component running on the main mobile OS that handles user interface and non-secure communication, and a "secure world" Trusted Application (TA) running inside the TEE. The associations between namespaces (e.g., org.iso.18013.5.1.mDL) and their security policies are stored, managed, and enforced entirely within the TA. When the reader requests data, the normal world app forwards the request to the TA, which performs the policy check and cryptographic operations in its isolated memory space, preventing even a compromised mobile OS from tampering with the security rules or accessing private keys.

graph TD
    subgraph Mobile Device
        subgraph Normal World OS
            A[eID Wallet UI App] --> B{Communication Interface};
        end
        subgraph TEE (Secure World)
            C[Trusted Application] -- Manages --> D{Namespace-Policy DB};
            D -- Contains --> E[NS_A: Policy_1];
            D -- Contains --> F[NS_B: Policy_2];
            C -- Accesses --> G[Cryptographic Keys];
        end
        A -- Invokes --> C;
        C -- Returns Secure Data --> A;
    end
    B <--> R[Reader Terminal];

---

Axis 2: Operational Parameter Expansion

Derivative 2.1: High-Frequency, Low-Latency Negotiation for Financial Clearinghouses

• Enabling Description: The namespace negotiation protocol is adapted for a high-frequency trading (HFT) or financial clearinghouse environment where latency is measured in nanoseconds. The mobile device is a server blade and the "reader" is a transaction-matching engine. The "namespaces" represent different clearing authorities or risk-assessment models (e.g., DTCC.equities.T+0, CME.derivatives.SPAN). The security policy is not a simple bytestring but a pre-compiled function pointer to a specific risk validation algorithm. The entire communication occurs over a direct RDMA (Remote Direct Memory Access) over Converged Ethernet (RoCE) link. When a trade is initiated, the server blade transmits a bitmask of available risk models. The matching engine selects a model by returning an offset into the bitmask, receives the function pointer, executes the risk calculation locally on the trade data, and proceeds only upon successful validation. The entire process is designed to execute in under a single-digit microsecond.

stateDiagram-v2
    [*] --> Init_Trade
    Init_Trade --> Send_Models: Trade Request Received
    Send_Models --> Select_Model: Transmit Bitmask of Risk Models
    Select_Model --> Execute_Validation: Receive Model Selection
    Execute_Validation --> Validation_Pass: Execute Risk Function
    Execute_Validation --> Validation_Fail: Execute Risk Function
    Validation_Pass --> Finalize_Trade
    Validation_Fail --> [*]: Abort
    Finalize_Trade --> [*]: Trade Cleared

Derivative 2.2: Extreme Low-Bandwidth Protocol for Deep-Space Probes

• Enabling Description: This derivative applies the concept to communication between a deep-space probe and a ground control station, where bandwidth is severely limited (e.g., a few bits per second) and latency is high. The probe hosts different "namespaces" representing various instrument data sets (JPL.spectrometer.calibrated, JPL.magnetometer.raw). Due to power constraints, activating an instrument has a significant energy cost. The security policy for each namespace includes the "energy cost" to retrieve the data. The ground station requests the list of namespaces. The probe returns a highly compressed list using a pre-shared dictionary. The ground station selects a namespace based on both its scientific interest and the associated energy cost, ensuring the probe's power budget is maintained. The negotiation protocol uses a store-and-forward mechanism with long timeouts (e.g., hours) to account for the signal travel time.

flowchart LR
    GC[Ground Control] -- Request List (High Latency) --> P[Space Probe]
    P -- Send Compressed List <br> [Spec: 2W, Mag: 0.5W] --> GC
    GC -- Select Namespace <br> (Choose Mag based on power budget) --> P
    P -- Activate Magnetometer --> D{Data Buffer}
    P -- Transmit Data <br> (Slow Dribble) --> GC

---

Axis 3: Cross-Domain Application

Derivative 3.1: Aerospace - Smart Part Authentication

• Enabling Description: An aircraft maintenance technician uses a ruggedized tablet (the "reader") to interact with an avionics component like a Flight Control Unit (FCU), which acts as the "mobile device." The FCU exposes multiple namespaces: FAA.part8130.airworthiness, AIRBUS.maint_log.history, and THALES.diag.realtime. Each namespace is protected by a different security policy. Accessing the official FAA airworthiness certificate requires the tablet to present a valid, digitally signed FAA mechanic license credential. Accessing the maintenance history requires a manufacturer-issued certificate. Accessing the real-time diagnostics requires establishing a time-locked, encrypted session key. The technician's tablet selects the appropriate namespace based on the task at hand, fulfills the security policy, and retrieves the necessary data without needing a persistent network connection to a central server.

classDiagram
    class RuggedizedTablet {
        +selectNamespace(namespace)
        +satisfyPolicy(policy)
        +getPartData()
    }
    class FlightControlUnit {
        -Map<String, Policy> namespacePolicies
        +listNamespaces()
        +getSecurityPolicy(namespace)
        +verifyPolicySatisfaction(proof)
        +provideData(namespace)
    }
    RuggedizedTablet "1" -- "1" FlightControlUnit : communicates_with

Derivative 3.2: AgTech - Autonomous Drone and Field Sensor Interaction

• Enabling Description: An autonomous agricultural drone ("reader") needs to retrieve data from a network of in-ground sensors ("mobile devices"). Each sensor has namespaces like AGRICO.soil_moisture.v3, AGRICO.ph_level.raw, and FARM.pest_model.output. The security policies prevent unauthorized data access or tampering (e.g., by a competitor's drone). Accessing raw sensor data requires the drone to prove its identity via a shared secret provisioned at the start of its mission. Accessing the processed pest model output, which consumes more sensor battery, requires the drone to also provide proof of a valid flight plan ID, ensuring it's not making superfluous requests. The drone queries nearby sensors, evaluates their offered namespaces and policies against its current mission objectives (e.g., "survey for moisture"), and selects the most power-efficient and mission-relevant namespace to access.

sequenceDiagram
    participant D as Ag-Drone
    participant S as Soil Sensor
    D->>S: Request Supported Namespaces
    S->>D: List: [soil_moisture, ph_level, pest_model]
    D->>S: Request Policy for 'soil_moisture'
    S->>D: Policy: {auth: shared_secret_hmac}
    Note right of D: Drone computes HMAC<br/>using its mission key
    D->>S: Access Request with HMAC
    Note left of S: Sensor validates HMAC
    S->>D: Access Granted: {moisture: 42%}

Derivative 3.3: Consumer Electronics - Smart Home Device Onboarding

• Enabling Description: A new smart lightbulb (a "device") is powered on in a home. The central smart home hub (the "reader") discovers it via a protocol like Matter. The lightbulb offers several namespaces for configuration and control: CSA.Matter.onboarding, ACME.firmware.update, and ACME.light_effects.premium. To onboard the device to the secure home network (CSA.Matter.onboarding), the hub must follow a standard security protocol defined by the Connectivity Standards Alliance. To access the firmware update namespace, the hub must present a manufacturer-signed token proving it is an authorized management device. To access the premium lighting effects, the hub must present proof-of-purchase linked to the homeowner's account. This allows the hub to progressively unlock functionality based on the level of trust and authorization it can provide.

graph TD
    Hub[Smart Home Hub] -- Discovers --> Bulb[Smart Lightbulb]
    Bulb -- Offers Namespaces --> Hub
    subgraph Bulb Namespaces
        N1[Onboarding]
        N2[Firmware Update]
        N3[Premium Effects]
    end
    Hub -- Selects Onboarding --> N1
    N1 -- Policy: Matter Protocol --> Hub
    Hub -- Satisfies --> N1
    N1 -- Grants Access --> Hub

---

Axis 4: Integration with Emerging Tech

Derivative 4.1: AI-Driven Proactive Namespace Caching

• Enabling Description: The reader terminal integrates a machine learning model (e.g., a recurrent neural network) trained on past transaction data. The model predicts which namespace a user is most likely to need based on contextual triggers (time of day, location, terminal type, recent application usage). For example, at a subway turnstile at 8:30 AM, it predicts the TRANSIT.monthly_pass namespace will be needed. Before the user even presents their mobile device, the reader proactively signals its interest in this namespace over a low-power broadcast. The mobile device, upon detecting this signal, pre-fetches the required credentials from its secure element and caches them, drastically reducing the transaction time when the user finally taps their device. The security policy negotiation is effectively front-loaded based on a probabilistic prediction.

flowchart TD
    A[Context Data <br> (Time, Location)] --> B{ML Model on Reader};
    B -- Prediction: 'Transit Pass' --> C[Reader Broadcasts Interest in NS_Transit];
    D[Mobile Device in Proximity] -- Hears Broadcast --> E{Pre-fetch Transit Credential};
    F[User Taps Device] --> G{Initiate Transaction};
    E -- Cached Credential --> G;
    G -- Completes Instantly --> H[Gate Opens];

Derivative 4.2: Blockchain-Hosted Verifiable Security Policies

• Enabling Description: Instead of the mobile device storing the security policies directly, it stores only a pointer to a policy object on a public, immutable ledger (e.g., a smart contract on Ethereum). Each namespace identifier corresponds to a specific smart contract address. When the reader requests the security policy for a namespace, the mobile device returns the contract address. The reader then queries the blockchain to retrieve the current, authoritative policy. This method allows policy issuers (e.g., governments, universities) to update their security requirements transparently and verifiably. It also creates a non-repudiable audit trail of every policy version. Accessing the data requires the reader to submit a transaction to the smart contract that proves it has met the on-chain conditions, which then emits an event that the mobile device's wallet uses as a trigger to release the data.

sequenceDiagram
    participant R as Reader
    participant MD as Mobile Device
    participant BC as Blockchain Smart Contract

    R->>MD: Request Policy for 'gov.eID'
    MD->>R: Return Contract Address: 0x123...
    R->>BC: queryPolicy(0x123...)
    BC->>R: Return Policy: {requires: signed_eth_tx}
    R->>BC: executeAccessRequest(signedTx)
    BC-->>MD: Event Emitted: 'AccessGranted(nonce)'
    Note over MD: Verifies event
    MD->>R: Release eID Data

---

Axis 5: The "Inverse" or Failure Mode

Derivative 5.1: Graceful Degradation to a Public "Display-Only" Namespace

• Enabling Description: The eID wallet is designed with a fail-safe mode. If the device's secure element becomes unresponsive due to a hardware fault, or if the high-security communication channel (e.g., NFC) fails, the device's eID wallet application automatically switches to a "degraded" state. In this state, it ceases to advertise any namespaces that require cryptographic operations. It advertises only a single, public-key-free namespace: org.iso.18013.5.1.visual. The security policy for this namespace is minimal, requiring only user consent via a screen tap. Upon selection by a reader, the mobile device simply displays a QR code or a human-readable summary of the ID data (e.g., name, photo, and a "NOT FOR OFFICIAL USE" watermark) on its screen, similar to a physical card. This allows the user to still present their identity information in a low-assurance, non-cryptographic manner when technical failures occur.

stateDiagram-v2
    state "Fully Functional" as Full {
        Full: Advertises [NS_Secure, NS_Visual]
        Full: NFC/SE Active
    }
    state "Degraded Mode" as Degraded {
        Degraded: Advertises [NS_Visual] only
        Degraded: NFC/SE Inactive
    }
    [*] --> Full
    Full --> Degraded : SE Failure or NFC Failure
    Degraded --> Full : Device Reboot / Issue Resolved
    Full --> [*]
    Degraded --> [*]

---

Combination Prior Art Scenarios with Open-Source Standards

1. Combination with W3C Verifiable Credentials and OpenID Connect: The entire negotiation protocol of patent 12,254,103 is implemented as an extension grant flow for OpenID Connect (OIDC). The mobile device acts as an OIDC Provider. The "namespaces" are different scopes of Verifiable Credentials (VCs) that the device can present (e.g., scope=org.w3c.VerifiableCredential.DrivingLicense). The "security policy" is communicated using the acr_values_supported parameter in the OIDC discovery document, specifying the authentication methods (e.g., phr for phishing-resistant) required to release a given VC. A reader (OIDC Relying Party) discovers the provider, selects a scope, is informed of the required ACR, initiates the flow, and upon successful user authentication on the device, receives the requested VC.

2. Combination with FIDO2/WebAuthn for Reader Authentication: The "Reader Authentication" security requirement described in the patent (FIG. 7, byte 2, bit 2) is implemented using the W3C WebAuthn standard. The reader terminal possesses its own FIDO2 authenticator (e.g., a hardware security key). The mobile device's security policy for a high-value namespace requires the reader to sign a challenge using its FIDO2 key. The mobile device, holding the reader's previously registered public key, verifies the signature. This binds the transaction not only to the user's identity but also to the specific, authenticated terminal that requested it, preventing man-in-the-middle or device-spoofing attacks.

3. Combination with ISO 23220 (NDEF+) for Secure Messaging: The secure messaging option in the patent's security policy template is implemented using the open ISO 23220 (NDEF+) standard for NFC. This standard defines a secure channel protocol that can be established over a standard NFC connection. The security policy for a namespace on the mobile device specifies that the NDEF+ protocol with AES-GCM encryption is mandatory. When a reader selects this namespace, it must initiate an NDEF+ session with the mobile device before any data elements (like the identity information itself) are exchanged, wrapping the entire post-negotiation communication in a standardized, end-to-end encrypted tunnel.