US 12254103

As of April 30, 2026, a search of the United States Patent and Trademark Office (USPTO) and U.S. Court of Appeals for the Federal Circuit (CAFC) dockets for patent number 12,254,103 reveals the following information.

Summary of U.S. Patent No. 12,254,103

Title: Security mechanism for namespaces used in electronic identification on mobile devices

Assignee: Thales DIS France SAS

Inventors: Mourad Faher, Carole Bayle

Filing Date: September 25, 2020

Issue Date: March 18, 2025

Abstract:
A system, mobile device, and method for managing security policies for data items stored in an electronic identification (eID) wallet on the mobile device. Security policies are associated with each of a plurality of supported namespaces on a mobile device and a verifier terminal operates to select a namespace to access a data item stored on the mobile device based on the security policies associated with the plurality of supported namespaces on the mobile device.

Plain-Language Overview of Independent Claims

This patent has three independent claims: Claim 1, Claim 11, and Claim 16.

Claim 1: This claim describes a method for managing security for electronic ID wallets on a mobile device. The core idea is that the system first links different security rules to various data categories (called "namespaces") on the device. Then, a separate device, called a "reader," communicates with the mobile device and chooses which data category to access based on these security rules.

Claim 11: This claim focuses on the mobile device itself. It specifies a device with a processor and memory that stores an eID wallet application. The application is designed to receive a list of selected data categories ("namespaces") from a reader. In response, the device sends back the specific security rules for each of those selected categories using a predefined data format (a "bytestring template").

Claim 16: This claim outlines a comprehensive, back-and-forth method for securely accessing data.

1. A mobile device has security policies for its various data "namespaces."
2. The device sends these policies to a reader.
3. The reader selects one or more namespaces it's interested in and sends this list back to the mobile device.
4. The mobile device then sends the specific security policies for just the selected namespaces.
5. The reader checks if it can comply with the security rules for any of the selected namespaces.
6. If it can, it picks one, proves to the mobile device that it meets the security requirements, and is then granted access to the data. If it cannot, access is denied.

Litigation Search

A search of the CAFC dockets for 2026 revealed no litigation records associated with U.S. Patent No. 12,254,103.

Litigation Search

As of April 30, 2026, a search for litigation involving U.S. Patent No. 12,254,103 in U.S. federal courts and the U.S. Court of Appeals for the Federal Circuit reveals no known cases. A thorough review of the PACER (Public Access to Court Electronic Records) Case Locator and CAFC dockets for the specific patent number "12254103" returned no results.

Therefore, there is no known litigation involving US patent 12,254,103.

Proceedings overview

As of May 29, 2026, there is one active Inter Partes Review (IPR) proceeding on file for U.S. Patent No. 12,254,103. This IPR is currently pending an institution decision. Consequently, all claims of the patent remain untested by the PTAB, and the defensive posture for a defendant is that the patent owner's claims have not yet been challenged or affirmed by an AIA trial.

IPR2026-00327 — Okta, Inc. et al. v. Thales DIS France SAS

• Type: Inter Partes Review
• Filed: 2026-04-06
• Status: Pending. The petition has been filed, and the Patent Trial and Appeal Board (PTAB) is currently reviewing whether to institute the trial.
• Judge panel: The judge panel information is not yet public as the institution decision is pending.
• Petition grounds: The specific claims challenged, prior art asserted, and statutory bases (§ 102 / § 103) are not publicly available at this pre-institution stage.
• Institution decision: Not yet issued. The PTAB typically issues an institution decision within six months of the petition filing date if a preliminary response is filed, or within three months otherwise. Given the filing date of April 6, 2026, this decision is expected in the coming months.
• Final Written Decision: Not issued, as the trial has not yet been instituted.
• Settlement / termination: Not applicable at this stage.
• Appeal: Not applicable at this stage.
• Defensive value: This pending IPR indicates that the patentability of some claims of U.S. Patent No. 12,254,103 is being challenged. Until an institution decision or Final Written Decision is issued, all claims remain unaddressed by the PTAB. A favorable institution decision for the petitioner would open the possibility of claims being cancelled, which could significantly weaken the patent owner's assertion position.

Strategic summary

Currently, no claims of U.S. Patent No. 12,254,103 have been canceled or sustained by the PTAB. All claims remain untested as the single IPR filed, IPR2026-00327, is in its preliminary "Pending" stage. Therefore, there is no estoppel landscape established yet under § 315(e)(2), meaning that potential defendants are not barred from raising any particular prior-art grounds in future challenges.

Regarding pattern signals, IPR2026-00327 is the first and only PTAB proceeding filed against this patent. There is no history of the same petitioner filing multiple IPRs, nor any indication of aggressive PTAB appeals by the patent owner or involvement of a defensive aggregator at this time.

Recommended next steps

The primary next step for anyone interested in this patent would be to monitor the status of IPR2026-00327 closely for the institution decision. The PTAB has a statutory deadline for issuing institution decisions, which will be approximately six months from the petition's filing date of April 6, 2026, if the patent owner files a preliminary response, or three months if no response is filed. The institution decision will reveal which claims, if any, the PTAB agrees to review and on what grounds. Access to the petition itself, once public (usually upon institution or denial of institution), would provide details on the specific prior art and arguments being leveraged by Okta, Inc..

Inventors

• Mourad Faher (Thales DIS France SAS)
• Carole Bayle (Thales DIS France SAS)

Original assignee

The original assignee on the issued patent is Thales DIS France SAS. Thales DIS France SAS is a large industrial company based in France, specializing in advanced technologies across defense, aeronautics, space, and digital identity and security. They develop and provide solutions, services, and products, including those related to digital identity and security. Thales DIS France SAS is an operating company that ships products embodying the claims, particularly within their digital identity and security domain. The company is currently operating.

Assignment timeline

• 2022-04-04 (executed) / recorded 2022-04-12 — Reel 059566/0702
  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: BAYLE, CAROLE; MOURAD, FAHER
  • Assignee: THALES DIS FRANCE SAS
  • Correspondent: THALES NORTH AMERICA, INC., 2200 Corporate Drive, STE 200, Dulles, VA 20166, UNITED STATES.
  • Context: Transfer of inventor's rights to the corporate assignee.

Timeline diagram

timeline
    title Ownership of US 12254103
    2020 : Filed by Thales DIS France SAS
    2022 : Inventors assigned rights to Thales DIS France SAS
    2025 : Issued

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The sole recorded assignment is from the individual inventors to Thales DIS France SAS, which is a known operating company.
2. Known asserter in the chain — not present. Thales DIS France SAS is an operating company, not a known NPE.
3. Repeat correspondent across the chain — not present. There is only one assignment recorded, and thus no recurrence of a correspondent within the chain.
4. Cascading transfers — not present. Only one assignment is recorded.
5. Pre-litigation transfer — not present. There is no recorded litigation, and the assignment is from the inventors to the original assignee, occurring well before the patent's issue date.
6. Bankruptcy fire-sale — not present. Thales DIS France SAS is an active, operating company.
7. Privateering — not present. The patent is currently held by the operating company.
8. Defensive aggregator (anti-NPE) — not present. The current assignee is an operating company, not a defensive aggregator.

Verdict

Operating-company assertion. The patent is currently assigned to Thales DIS France SAS, an operating company with products in the digital identity and security domain that would embody the claims. The only recorded assignment is from the inventors to this operating company. This indicates the patent is held by an entity that develops and sells products in the relevant technology space.

For verification, search U.S. Patent No. 12,254,103 on the USPTO Patent Assignment Search.

Analysis of Prior Art for U.S. Patent No. 12,254,103

This analysis reviews the prior art cited by the USPTO examiner during the prosecution of U.S. Patent No. 12,254,103. The focus is on determining whether any single reference anticipates the patent's independent claims (Claims 1, 11, and 16) under 35 U.S.C. § 102, which requires that a single prior art document disclose every element of a claim.

The core inventive concept of patent 12,254,103 appears to be the interactive method where a mobile device's eID wallet advertises multiple data sources ("namespaces") along with their specific security rules, allowing an external reader (or "verifier") to evaluate these rules and select the most appropriate namespace for a given transaction. This shifts some of the decision-making logic to the reader, which can then choose a namespace based on its own capabilities and the level of trust required.

Based on the examiner-cited references, the following are the most relevant prior art.

---

1. US Patent Application Publication No. 2015/0040180 A1

• Full Citation: US 2015/0040180 A1, "Information firewall," assigned to Palo Alto Research Center Incorporated.
• Date: Published February 5, 2015 (filed August 1, 2013). This qualifies as prior art.
• Brief Description: This reference discloses an "information firewall" for a device, which can be a mobile device. The firewall intercepts requests for data and applies policies to control what information is released. These policies can be associated with specific collections of data, analogous to the "namespaces" in patent 12,254,103. The system is designed to protect a user's private data by enforcing rules before any information is shared with an external requester.
• Potential Anticipation Analysis:
  • Claim 1: This reference teaches associating security policies with data collections on a mobile device and having a requester (reader) communicate with that device. However, it does not appear to disclose the key step where the reader selects a namespace based on the security policies. In the '180 application, the firewall on the mobile device enforces policies against an incoming request. It does not describe a preliminary step where the device advertises its data collections and their corresponding policies to allow the reader to make an informed selection beforehand.
  • Claims 11 and 16: The specific back-and-forth communication protocols detailed in claims 11 and 16 are not described. The '180 application does not teach a mobile device receiving a list of selected namespaces and then returning the security rules for them, nor the comprehensive negotiation process outlined in claim 16. The policy evaluation and enforcement happen entirely on the mobile device after a request is made.

Conclusion: This reference is relevant for its disclosure of policy-based data access on a mobile device but fails to anticipate the claims because it lacks the crucial element of the reader selecting a namespace based on policies communicated from the mobile device.

---

2. US Patent Application Publication No. 2012/0159195 A1

• Full Citation: US 2012/0159195 A1, "Writing application data to a secure element," assigned to Google Inc.
• Date: Published June 21, 2012 (filed December 17, 2010). This qualifies as prior art.
• Brief Description: This application describes a system for managing access to a secure element (SE) on a mobile device. It involves a trusted service manager that defines and enforces access control rules for different applications wanting to read from or write to the SE. This establishes a framework for applying security policies to data stored in a protected area of a mobile device.
• Potential Anticipation Analysis:
  • Claim 1: The '195 application discloses security policies for data on a mobile device. However, its focus is on managing application permissions, typically during installation or provisioning, rather than facilitating a real-time eID transaction with a reader. It does not describe a reader discovering multiple namespaces (e.g., different ID types like a driver's license and a university ID) and choosing one based on their respective security policies.
  • Claims 11 and 16: The interactive model is fundamentally different. The '195 application concerns a trusted manager controlling application access, not an eID reader negotiating access with an eID wallet as described in the detailed steps of claims 11 and 16. The specific query-response flow for security policies is not present.

Conclusion: While this reference relates to security policies on mobile devices, it addresses a different technical problem (secure application management) and does not disclose the claimed method of a reader dynamically selecting a namespace for an eID transaction based on advertised security rules.

---

3. US Patent Application Publication No. 2006/0265508 A1

• Full Citation: US 2006/0265508 A1, "System for administering a multiplicity of namespaces containing state information and services," listing Franklin J. Angel as the inventor.
• Date: Published November 23, 2006 (filed May 2, 2005). This qualifies as prior art.
• Brief Description: This reference details a server-based system for managing and controlling access to multiple, distinct namespaces. An administration server enforces policies that govern how different entities can access the data and services within each namespace. The system is designed to provide secure, isolated data environments.
• Potential Anticipation Analysis:
  • Claim 1: The '508 application teaches the concept of associating policies with namespaces. However, the policy enforcement and access control logic are centralized in an "administration server." It does not describe the specific architecture of patent 12,254,103, where a mobile device communicates policies to a reader, and the reader makes the selection. In this reference, the server enforces the rules, rather than the client/reader choosing which set of rules it wants to comply with.
  • Claims 11 and 16: The reference does not describe a mobile device eID wallet or the specific communication protocols where the device sends security rules to a reader in response to a selection. The system architecture and interaction flow are different from what is claimed.

Conclusion: This reference is relevant for its use of "namespaces" and "policies" but does not anticipate the claims because its centralized, server-driven enforcement model is distinct from the reader-driven selection process claimed in U.S. Patent No. 12,254,103.

Obviousness Analysis of U.S. Patent No. 12,254,103 under 35 U.S.C. § 103

This analysis evaluates whether the independent claims of U.S. Patent No. 12,254,103 would have been obvious to a Person Having Ordinary Skill in the Art (PHOSITA) at the time of the invention, with a priority date of October 18, 2019. An invention is considered obvious if the differences between the claimed invention and the prior art are such that the subject matter as a whole would have been obvious to a PHOSITA. This analysis relies on the prior art references cited by the USPTO examiner and summarized in the "Prior art" section.

A PHOSITA in this technical field would be an engineer or computer scientist with several years of experience in mobile application development, data security, secure element technology, and client-server communication protocols, particularly within the context of identity management or electronic payment systems.

Combination of Prior Art

The independent claims of patent 12,254,103 could be rendered obvious by combining the teachings of US 2015/0040180 A1 (the '180 application) and US 2006/0265508 A1 (the '508 application).

• US 2015/0040180 A1 ('180): Teaches a mobile device with an "information firewall" that associates security policies with different collections of data. It discloses a reader (requester) communicating with the mobile device to access data, and the device enforcing policies on that request.
• US 2006/0265508 A1 ('508): Teaches a system for managing a "multiplicity of namespaces," where each namespace is a distinct data environment with its own access control policies.

Analysis of Independent Claim 1

Claim 1 recites a method comprising:

1. Associating security policies with each of a plurality of supported namespaces on a mobile device.
2. Operating a reader to communicate with the mobile device.
3. The reader selects a namespace to access based on the security policies.

The '180 application teaches elements 1 and 2. It discloses a mobile device that associates policies with data collections (analogous to namespaces) and a reader that communicates with it. However, the '180 application is missing the key final element: the reader selecting a namespace based on the policies. In the '180 system, the reader makes a request, and the mobile device's firewall unilaterally enforces the policy.

The '508 application teaches the management of multiple, distinct namespaces, each with its own access policies. A PHOSITA would recognize that a modern mobile device, particularly for eID purposes, would function like the multi-tenant system of '508, needing to host different identities (e.g., a government ID, a university ID, a corporate badge) in distinct "namespaces."

Motivation to Combine:
A PHOSITA, starting with the mobile firewall concept from the '180 application, would be motivated to improve its efficiency and flexibility in a real-world eID context. The problem with the '180 system is that a reader may not know the mobile device's security policy in advance. The reader might make a request that is destined to fail because it cannot meet the stringent security requirements (e.g., requesting age verification from a national ID namespace that requires certificate verification, which the reader cannot perform). This leads to failed transactions and a poor user experience.

To solve this known problem, a PHOSITA would look for ways to make the interaction more intelligent. Drawing from the '508 concept of managing multiple, distinct namespaces, the PHOSITA would be motivated to modify the '180 system. It would be a logical and predictable step to have the mobile device first advertise its available namespaces and the rules for accessing them. This would allow the reader to discover what data is available and what is required to access it. Consequently, the reader could then intelligently select a namespace whose security policy it can satisfy, ensuring a successful transaction. This combination of advertising multiple data sources ('508) and their access rules ('180) to enable an intelligent choice by the reader would render the invention of claim 1 obvious.

Analysis of Independent Claims 11 and 16

Claims 11 and 16 build upon claim 1 by reciting the specific back-and-forth communication protocol to implement the reader's selection process.

• Claim 11 focuses on the mobile device's role: receiving a list of selected namespaces from a reader and, in response, transmitting the specific security rules for those namespaces.
• Claim 16 details the entire transaction flow: the mobile device sends policies, the reader selects candidate namespaces, the mobile device sends policies for those candidates, the reader determines if it can satisfy any of them, selects one, and demonstrates satisfaction to gain access.

Once the core idea of having the reader select a namespace based on advertised policies is established (from the combination of '180 and '508), designing the specific communication protocol would be a matter of routine engineering for a PHOSITA. The multi-step negotiation process described in claims 11 and 16 is a standard and efficient design pattern for client-server interactions.

Motivation for the Specific Protocol:
A PHOSITA would be motivated to design the communication flow this way for efficiency. Transmitting the full, potentially complex, security policies for all available namespaces at the beginning of every transaction could be slow and data-intensive. A more logical and predictable implementation would be:

1. Discovery: The mobile device first sends a simple list of available namespaces (e.g., fr.gouv.ants.id, fr.edu.univ-pau.labo.profile).
2. Selection of Interest: The reader, based on its own configuration (e.g., a whitelist of trusted issuers), selects the namespaces it is interested in.
3. Request for Details: The reader requests the specific security policies for only the selected namespaces.
4. Final Selection and Access: The mobile device transmits the detailed policies, and the reader makes its final selection and initiates the access request.

This flow, which maps directly onto the steps of claims 11 and 16, is an obvious way to implement the system to conserve bandwidth and reduce latency. It is a predictable solution to the problem of efficiently communicating the necessary information. Therefore, these claims represent an obvious implementation of the core inventive concept derived from the '180 and '508 references.

Conclusion

The independent claims of U.S. Patent No. 12,254,103 would have been obvious to a Person Having Ordinary Skill in the Art. The combination of US 2015/0040180 A1 and US 2006/0265508 A1 teaches all the core elements of the claims. A PHOSITA would have been motivated to combine their teachings to create a more flexible and efficient eID system where the reader could discover and select from multiple identity namespaces based on their advertised security policies, thereby avoiding transactional failures and improving system performance. The specific communication protocols recited in the dependent claims represent a predictable and routine implementation of this core concept.

Patent Term and Related Applications for U.S. Patent No. 12,254,103

As of May 1, 2026, the following details pertain to the term, application history, and international family of U.S. Patent No. 12,254,103.

Patent Term Adjustment (PTA) and Projected Expiration

A patent's term is typically 20 years from the earliest effective U.S. non-provisional filing date. For U.S. Patent No. 12,254,103, this would normally result in an expiration date of September 25, 2040, which is 20 years from its filing date of September 25, 2020.

However, the USPTO has granted a Patent Term Adjustment (PTA) to compensate for administrative delays during the patent prosecution process. The official "Adjusted expiration" date for this patent is listed as June 24, 2041.

This indicates a total PTA of 272 days. The adjustment extends the patent's enforceability beyond the standard 20-year term. There is no indication of any Patent Term Extension (PTE) under 35 U.S.C. § 156, which typically applies to products requiring pre-market regulatory review, such as pharmaceuticals.

Application History

• Application Number: The patent was granted from U.S. application number 17/767,153.
• Continuations and Divisionals: This application is the U.S. national stage entry of an international PCT application. It is not a continuation or divisional application of a prior U.S. patent application.

Patent Family and Priority

U.S. Patent No. 12,254,103 is part of a larger international patent family, claiming priority to an initial European patent application. This establishes an invention priority date of October 18, 2019.

• Priority Application:

  • EP19306357: Filed in the European Patent Office on October 18, 2019.

• International (PCT) Application:

  • WO2021073853A1 (filed as PCT/EP2020/076906): This international application was filed on September 25, 2020, and designated multiple countries for patent protection.

• Known National Family Members:
  Based on the priority claim, the following corresponding patents or patent applications have been filed in other jurisdictions:

  • Australia: AU2020367942A1
  • Brazil: BR112022006930A2
  • Canada: CA3154428A1
  • China: CN114868147B
  • Europe: EP3809358A1
  • South Korea: KR102822481B1

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.