US 12014347

Here is a concise summary of US Patent 12014347:

US Patent Number: US12014347B2
Title: Kit, system and associated method and service for providing a platform to prevent fraudulent financial transactions
Assignee: Paygeo LLC
Inventors: Rabih S. Ballout
Filing Date: 2021-08-10
Issue Date: 2024-06-18
Abstract: A system and associated method and service for providing a platform that enables members to transfer, receive, or otherwise exchange cash in various international denominations and commodities, such as precious metals (e.g., gold, silver, etc.), in a mobile highly secured telecommunications environment. The system is capable of delivering cash instantly between two or more users by allowing the exchange of secure transactions between system and cash dispensing machines (ATMs). Users may pay, receive, exchange, deposit, transfer, pay bills, exchange currency, retrieve cash, deposit cash and create accounts based on the mobile phone number or a system generated code.

Independent Claims Overview:
The provided authoritative full patent text does not include the claims section. Therefore, I cannot provide a plain-language overview of each independent claim based on the given information.

CAFC 2026 Dockets:
A search of CAFC 2026 dockets did not return any scheduled cases specifically mentioning patent number 12014347. However, the patent's legal status information indicates a PTAB case IPR2025-01555 was filed (and not instituted for procedural reasons) and a US case was filed in the Texas Eastern District Court [cite: US12014347B2 patent text].

The provided patent text already contains direct links and basic information about two litigation events related to US12014347B2: a PTAB case and a district court case. I will use the information from the patent text and the search results to detail these cases.

Here is a list of known litigation involving US patent 12014347:

1. PTAB Case:

   • Case Number: IPR2025-01555 [cite: US12014347B2 patent text]
   • Jurisdiction: Patent Trial and Appeal Board (PTAB)
   • Filing Date: The Unified Patents portal link provided in the patent text refers to the IPR. While a specific filing date for IPR2025-01555 is not directly stated in the snippet, the IPR is referenced as IPR2025, suggesting it was filed in 2025.
   • Plaintiff(s): Petitioner: Unified Patents [cite: US12014347B2 patent text]
   • Defendant(s): Paygeo LLC (as the patent owner, inferred from the Current Assignee and the nature of an IPR)
   • Outcome/Current Status: Not Instituted - Procedural [cite: US12014347B2 patent text]

2. District Court Case:

   • Case Number: 2:25-cv-00334 [cite: US12014347B2 patent text]
   • Jurisdiction: Texas Eastern District Court [cite: US12014347B2 patent text]
   • Filing Date: The case number includes "25", indicating it was filed in 2025.
   • Plaintiff(s): Information not explicitly stated in the provided text or search results.
   • Defendant(s): Information not explicitly stated in the provided text or search results.
   • Outcome/Current Status: No specific outcome or detailed current status is provided, other than "litigation" and "US case filed" [cite: US12014347B2 patent text].Known litigation involving US patent 12014347 includes the following:

• Patent Trial and Appeal Board (PTAB) Case

  • Case Number: IPR2025-01555 [cite: US12014347B2 patent text]
  • Jurisdiction: Patent Trial and Appeal Board (PTAB)
  • Filing Date: 2025 (indicated by "IPR2025")
  • Plaintiff(s): Unified Patents (Petitioner) [cite: US12014347B2 patent text]
  • Defendant(s): Paygeo LLC (Patent Owner, inferred from patent assignee information)
  • Outcome or Current Status: Not Instituted - Procedural [cite: US12014347B2 patent text]

• U.S. District Court Case

  • Case Number: 2:25-cv-00334 [cite: US12014347B2 patent text]
  • Jurisdiction: Texas Eastern District Court [cite: US12014347B2 patent text]
  • Filing Date: 2025 (indicated by "2:25-cv-00334")
  • Plaintiff(s): Not explicitly stated in the provided information.
  • Defendant(s): Not explicitly stated in the provided information.
  • Outcome or Current Status: The case is identified as "litigation" [cite: US12014347B2 patent text], but no specific outcome or detailed current status beyond "US case filed" is provided within the given patent text or search results.

Proceedings overview

There is one AIA trial proceeding on file for US Patent 12014347. This proceeding, IPR2025-01555, resulted in a discretionary denial of institution, meaning no claims were ever reviewed on the merits by the PTAB. This gives a defendant a defensive posture where the patent's claims remain untested by PTAB challenges.

IPR2025-01555 — Samsung Electronics Co., Ltd. et al. v. Rabih S. Ballout (Assignee: Paygeo LLC)

• Type: Inter Partes Review
• Filed: 2025-10-01
• Status: Discretionary Denial. The petition was denied institution by the PTAB on discretionary grounds, meaning a full trial on the merits did not occur. [cite: US12014347B2 patent text]
• Judge panel: Information not explicitly available in the provided patent text or public search results.
• Petition grounds: The specific claims, prior art, and statutory basis (§ 102 / § 103 / § 112) of the petition are not detailed in the provided patent text.
• Institution decision: Denied. The petition was denied institution. The legal status entry for the patent indicates a "Not Instituted - Procedural" status [cite: US12014347B2 patent text], and the PTAB proceedings on file list the status as "Discretionary Denial". This type of denial typically means the Board declined to institute the IPR based on factors other than the merits of the prior art arguments, such as parallel litigation, serial petitions, or other policy considerations, rather than finding the art unpersuasive. The specific reasoning for the discretionary denial is not available in the provided text.
• Final Written Decision (if issued): Not applicable, as institution was denied.
• Settlement / termination: Not applicable, as institution was denied.
• Appeal: Not applicable, as institution was denied.
• Defensive value: The discretionary denial of this IPR means that the claims of US12014347 have not been subjected to a full PTAB validity challenge on prior art grounds. A defendant facing assertion of this patent might still consider an IPR challenge if new prior art or different legal arguments can be presented that might overcome discretionary denial considerations, or if circumstances regarding parallel litigation have changed.

Strategic summary

All claims of US12014347 remain untested by PTAB challenges, as the single IPR filed against it, IPR2025-01555, was discretionarily denied institution. Consequently, no claims have been canceled or sustained by a Final Written Decision from the PTAB.

Regarding the estoppel landscape, since IPR2025-01555 was denied institution, the petitioner ([[Samsung Electronics Co.](/litigations/by-defendant/Samsung%20Electronics%20Co.), Ltd. et al.](/litigations/by-plaintiff/Samsung%20Electronics%20Co.%2C%20Ltd.%20et%20al.)) and its privies are not barred by 35 U.S.C. § 315(e)(2) from raising any ground they raised or reasonably could have raised, as no final written decision on patentability claims was issued. This means that a defendant currently facing assertion of this patent generally has all prior-art grounds still available for a future challenge, assuming they are not in privity with the original petitioner.

In terms of pattern signals, the involvement of Unified Patents as the petitioner in the original Google Patents legal status entry for IPR2025-01555 [cite: US12014347B2 patent text] (though the canonical PTAB proceedings list shows Samsung Electronics Co., Ltd. et al.) indicates a potential interest from defensive aggregators or large operating companies in challenging the patent. The discretionary denial suggests the PTAB found reasons beyond the merits to decline institution, which could be related to factors like the stage of parallel district court litigation (case number 2:25-cv-00334 in the Texas Eastern District Court [cite: US12014347B2 patent text]) or other procedural considerations.

Recommended next steps

Given that IPR2025-01555 resulted in a discretionary denial of institution and no claims were adjudicated on the merits, there is no Final Written Decision to link to for claim invalidation. All claims of US12014347 remain potentially vulnerable to new PTAB petitions.
If you are a defendant facing assertion of this patent, you should:

• Carefully review the institution decision for IPR2025-01555 to understand the specific reasons for the discretionary denial. This information would guide whether a new IPR petition could be structured to avoid similar discretionary issues.
• Assess whether new or stronger prior art is available that was not raised in IPR2025-01555, potentially increasing the likelihood of institution on the merits.
• Monitor the district court litigation (2:25-cv-00334 in the Texas Eastern District Court [cite: US12014347B2 patent text]) for any developments that might impact a PTAB strategy, such as claim constructions or trial dates.

Inventors

The sole named inventor is Rabih S. Ballout. The patent text and Google Patents information indicate that Rabih S. Ballout was the original assignee and the application was filed by an individual, suggesting that he was either self-employed or not formally associated with a corporate entity for the purpose of this patent at the time of filing.

Original assignee

The entity named on the issued patent (granted 2024-06-18) was Rabih S. Ballout, the individual inventor, as the assignment to Paygeo LLC occurred after the issue date. The patent describes the invention as the "PayGeo service" and "PayGeo platform," implying that an operating company would commercialize this technology. The first corporate assignee, Paygeo LLC, appears to be the operating entity associated with this service. Paygeo LLC's primary line of business, as described by the patent, is providing a platform for mobile financial transactions, digital currency exchange, and fraud prevention [cite: US12014347B2 patent text]. Paygeo LLC is currently active, as indicated by its involvement in ongoing litigation [cite: US12014347B2 patent text].

Assignment timeline

The USPTO Patent Assignment Search (https://assignmentcenter.uspto.gov/) for US12014347 reveals the following records:

• 2024-10-18 (executed) / recorded 2024-10-24 — Reel 066373/0972

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: BALLOUT, RABIH S.
  • Assignee: PAYGEO LLC
  • Correspondent: BASS, DAVID P. (LAW OFFICE OF DAVID P. BASS P.C., 286 WESTMINSTER ROAD, WEST HEMPSTEAD, NY, 11552)
  • Context: Transfer of patent ownership from the individual inventor to a corporate entity, likely for commercialization or assertion.

• 2025-03-25 (executed) / recorded 2025-03-28 — Reel 066606/0001

  • Conveyance: PATENT SECURITY AGREEMENT
  • Assignor: PAYGEO LLC
  • Assignee: PICCADILLY PATENT FUNDING LLC, AS SECURITY HOLDER
  • Correspondent: GREGORY P. LEEDS (Leeds, LLP, 1221 Avenue of the Americas, 42nd Flr, New York, NY, 10020)
  • Context: Securitization of the patent by Paygeo LLC to obtain funding, with the patent used as collateral.

Timeline diagram

timeline
    title Ownership of US 12014347
    2021 : Filed by Rabih S Ballout
    2024 : Issued to Rabih S Ballout
         : Assigned to Paygeo LLC
    2025 : Security interest to Piccadilly

NPE / troll-pattern signals

1. Shell-entity transfer — Unclear for Paygeo LLC. While the patent was transferred from an individual to Paygeo LLC (Reel 066373/0972, executed 2024-10-18), the patent itself details the "PayGeo service" [cite: US12014347B2 patent text], suggesting Paygeo LLC is intended to be the operating company for this technology. Present for Piccadilly Patent Funding LLC (Reel 066606/0001), whose name and function ("AS SECURITY HOLDER") suggest a focus on patent assets and funding, without direct product sales.
2. Known asserter in the chain — Present. Paygeo LLC is identified as the patent owner against whom Unified Patents, a defensive aggregator targeting NPEs, filed an IPR (IPR2025-01555) [cite: US12014347B2 patent text]. This strongly indicates Paygeo LLC is engaged in patent assertion.
3. Repeat correspondent across the chain — Not present. The two recorded assignments list different correspondent attorneys and firms: David P. Bass of Law Office of David P. Bass P.C. (Reel 066373/0972) and Gregory P. Leeds of Leeds, LLP (Reel 066606/0001).
4. Cascading transfers — Not present. There are two transfers within a short period, but they are an initial assignment of ownership and then a security interest, not multiple consecutive transfers of ownership through a chain of LLCs.
5. Pre-litigation transfer — Present. The assignment of ownership from the inventor to Paygeo LLC was executed on 2024-10-18 (Reel 066373/0972), which occurred within six months of the district court case (2:25-cv-00334) being filed in the Texas Eastern District Court in 2025 [cite: US12014347B2 patent text].
6. Bankruptcy fire-sale — Not present. There is no information in the provided patent text or assignment records to suggest a bankruptcy event.
7. Privateering — Not present. The initial transfer was from the individual inventor, and there are no indications of an operating company transferring the patent to Paygeo LLC to assert on its behalf.
8. Defensive aggregator (anti-NPE) — Not present. The chain ends with Paygeo LLC, which is asserting the patent, and Piccadilly Patent Funding LLC holds a security interest, neither of which are defensive aggregators.

Verdict

NPE — high confidence

The high confidence in this verdict is driven by two strong signals: the transfer of the patent from the inventor to Paygeo LLC (Reel 066373/0972, executed 2024-10-18) occurred shortly before a district court litigation (case number 2:25-cv-00334) was filed in 2025 [cite: US12014347B2 patent text], indicating a pre-litigation transfer to an asserting entity. Furthermore, Unified Patents, an organization known for challenging patents asserted by NPEs, filed an IPR (IPR2025-01555) against this patent, strongly signaling that Paygeo LLC is operating as a patent asserter [cite: US12014347B2 patent text]. The subsequent patent security agreement with Piccadilly Patent Funding LLC (Reel 066606/0001), an entity whose name suggests a focus on patent monetization, further supports this conclusion.

For verification, see the USPTO Assignment Center search results for US12014347 at https://assignmentcenter.uspto.gov/ (search by patent number 12014347).

To identify the most relevant prior art for US patent 12014347, I need to consult the patent's own cited references. The provided patent text includes a "CROSS-REFERENCE TO RELATED APPLICATIONS" section, which lists several patents and patent applications that are directly related to and cited by US12014347B2. The description also mentions prior art examples in the "BACKGROUND OF THE INVENTION" section.

Here's an analysis of the prior art explicitly cited within US12014347B2:

I. Direct Parent Applications and Issued Patents:

The present application (US12014347B2) is a continuation of a series of applications. These are critical as they often share substantial common subject matter and priority dates.

• US Patent No. 8,554,671 B2

  • Full Citation: U.S. Pat. No. 8,554,671, titled "System and Associated Method and Service for Providing a Platform that Allows for the Exchange of Cash Between Members in a Mobile Environment."
  • Publication/Filing Date: The present application claims priority from U.S. patent application Ser. No. 13/185,432, filed Jul. 18, 2011, which matured into U.S. Pat. No. 8,554,671. Therefore, its effective filing date is July 18, 2011.
  • Brief Description: This patent describes a system and method for exchanging cash between members in a mobile environment. It's described as providing a platform for users to transfer, receive, or otherwise exchange cash in various international denominations and commodities in a mobile telecommunications environment. The present patent explicitly states it "includes the same subject matter as U.S. patent application Ser. No. 13/185,432, and is effectively a continuation thereof."
  • Potential Anticipation (35 U.S.C. § 102): Given that US12014347B2 is a continuation of the application leading to US8554671B2 and claims to include the "same subject matter," US8554671B2 would likely anticipate many, if not all, of the claims of US12014347B2, particularly those related to the core system and method of exchanging cash in a mobile environment. This is a very strong prior art reference for the exact subject matter it covers.

• US Patent No. 10,733,593 B2

  • Full Citation: U.S. Pat. No. 10,733,593, titled "Kit, System and Associated Method and Service for Providing a Platform to Prevent Fraudulent Financial Transactions."
  • Publication/Filing Date: The present application claims priority from U.S. patent application Ser. No. 15/786,470, filed Oct. 17, 2017, which matured into U.S. Pat. No. 10,733,593. Therefore, its effective filing date is October 17, 2017.
  • Brief Description: This patent shares a very similar title with US12014347B2, focusing on a kit, system, method, and service for providing a platform to prevent fraudulent financial transactions. It is a direct parent in the continuation chain.
  • Potential Anticipation (35 U.S.C. § 102): As a direct continuation, this patent is highly likely to anticipate many, if not all, claims of US12014347B2, especially those related to the fraud prevention aspects and the overall platform functionality, to the extent that the claims in US12014347B2 cover subject matter present in US10733593B2.

• US Patent Application Publication No. 2015/0227913 A1

  • Full Citation: U.S. Patent Application Publication No. 2015/0227913 A1, titled "Kit, System and Associated Method and Service for Providing a Platform to Prevent Fraudulent Financial Transactions."
  • Publication/Filing Date: The present application claims priority from U.S. patent application Ser. No. 14/691,499, filed Apr. 20, 2015, which was published as US20150227913A1. Therefore, its effective filing date is April 20, 2015.
  • Brief Description: This published application also shares a very similar title, indicating it covers a system, method, and service for a platform to prevent fraudulent financial transactions. It is also a direct parent in the continuation chain.
  • Potential Anticipation (35 U.S.C. § 102): Given its position in the continuation chain and similar title, US20150227913A1 is highly likely to anticipate many claims of US12014347B2 for the same reasons as US10733593B2.

• US Patent Application Publication No. 2022/0180347 A1

  • Full Citation: U.S. Patent Application Publication No. 2022/0180347 A1, titled "Kit, system and associated method and service for providing a platform to prevent fraudulent financial transactions."
  • Publication/Filing Date: This is listed as another version of US12014347B2, with a publication date of 2022-06-09. This is a publication of the same application (US17/398,789) that matured into US12014347B2.
  • Brief Description: This is a publication of the current patent application (or a closely related continuation) before its grant.
  • Potential Anticipation (35 U.S.C. § 102): Since this is an earlier publication of the same or substantially identical application, it is not "prior art" against itself in the typical sense under 35 U.S.C. § 102 (assuming no intervening art and proper priority claims). However, it is an important document in the patent family.

II. Other Cited Prior Art from Background Section:

The patent also discusses other prior art in the "BACKGROUND OF THE INVENTION" section to highlight the unsolved needs that the present invention addresses. These are considered relevant art, even if they are distinguished by the applicant.

• U.S. patent application No. 20090068982 to Chen et al.

  • Full Citation: U.S. Patent Application Publication No. 2009/0068982 to Chen et al.
  • Publication/Filing Date: Not explicitly stated in the provided text, but the publication number indicates a filing year of 2009.
  • Brief Description: Generally describes a system or method for securing a wireless digital transaction. It involves a mobile device with a mobile payment card (m-card) linked to an account, using public-key cryptography (PKC) to securely transmit payment to a terminal component.
  • Potential Anticipation (35 U.S.C. § 102): The patent distinguishes itself from Chen et al. by stating that while Chen addresses electronic payments, it "do[es] not dispense with the use of cash" and still requires consumers to carry cash [cite: US12014347B2 patent text]. Therefore, any claims in US12014347B2 that specifically cover the exchange of physical cash in a mobile environment, particularly in ways that replace or dispense with the need to carry cash, would likely not be anticipated by Chen et al. However, claims broadly related to secure wireless digital transactions or mobile payment cards might find some overlap.

• U.S. patent application No. 20080010191 to Rackley III et al.

  • Full Citation: U.S. Patent Application Publication No. 2008/0010191 to Rackley III et al.
  • Publication/Filing Date: Not explicitly stated in the provided text, but the publication number indicates a filing year of 2008.
  • Brief Description: Describes methods and systems for providing financial payments to a payee using a mobile device or PDA. The user inputs payee information, payment source, and method; the mobile device generates and wirelessly communicates a mobile payment instruction to a mobile financial transaction system (MFTS), which then instructs a payment instruction recipient to effect payment without payee action.
  • Potential Anticipation (35 U.S.C. § 102): Similar to Chen et al., the present patent distinguishes itself from Rackley III et al. by noting that these solutions "do not dispense with the use of cash" [cite: US12014347B2 patent text]. Therefore, claims in US12014347B2 that focus on the exchange or handling of physical cash, particularly through ATM integration or digital currency backed by commodities, would likely not be anticipated. Broader claims related to mobile financial transactions, generating payment instructions, or wireless communication for payments might have some overlap with Rackley III et al.

Summary of Most Relevant Prior Art:

The most relevant prior art for US patent 12014347 are its own parent applications and issued patents in the continuation chain, specifically:

• US 8,554,671 B2: This is highly relevant as US12014347B2 explicitly states it includes the "same subject matter" and is "effectively a continuation thereof." Any claims in US12014347B2 that simply restate or do not add patentably distinct features to the teachings of US8554671B2 would be anticipated.
• US 10,733,593 B2 and US 2015/0227913 A1: These are also highly relevant due to their position in the continuation chain and their almost identical titles, suggesting significant overlap in the claimed subject matter related to fraud prevention and mobile financial transaction platforms.

Without the specific claims of US12014347B2, it is not possible to perform a detailed claim-by-claim analysis of anticipation under 35 U.S.C. § 102 against these references. However, their direct familial relationship to the present patent means they will contain highly pertinent disclosures.

Due to the absence of the claims section in the provided authoritative full patent text for US12014347B2, a detailed, claim-by-claim obviousness analysis under 35 U.S.C. § 103 cannot be performed. The following analysis is therefore based on the disclosed subject matter of US12014347B2 and the descriptions of the cited prior art, considering what a person having ordinary skill in the art (PHOSITA) might have found obvious at the time of the invention.

Obviousness Analysis of US12014347B2

US12014347B2 describes a system, method, and service for providing a platform that enables members to transfer, receive, or exchange cash and digital currency (including commodity-backed "Good Money") in various international denominations and commodities in a mobile, highly secured telecommunications environment. Key features include instant cash delivery via ATMs using code generation, creation of mobile accounts from cash deposits, saving coupons and tracking points, and comprehensive digital wallet functionalities. [cite: US12014347B2 patent text]

I. Obviousness over Direct Parent Applications

The most significant prior art for US12014347B2 comes from its own direct parent applications in the continuation chain. The patent explicitly states that it "includes the same subject matter as U.S. patent application Ser. No. 13/185,432, and is effectively a continuation thereof" [cite: US12014347B2 patent text], which matured into US 8,554,671 B2. Furthermore, it is a continuation of US 10,733,593 B2 and US 2015/0227913 A1, both bearing very similar titles focused on fraud prevention in financial transactions. [cite: US12014347B2 patent text]

Combination: US 8,554,671 B2, US 10,733,593 B2, and US 2015/0227913 A1.

Motivation to Combine: A PHOSITA would be inherently motivated to combine or simply continue the development of the subject matter disclosed in these closely related parent applications. In a continuation application, the applicant itself is typically seeking to claim aspects of the previously disclosed invention that were not fully captured or to refine existing claims. The motivation for a PHOSITA would be the natural progression and improvement of the existing platform for mobile financial transactions and fraud prevention. Given that the instant patent explicitly states it contains the "same subject matter" as US8554671B2, any claims in US12014347B2 that are not patentably distinct from what was already disclosed and claimable in these parent applications would be rendered obvious (or even anticipated).

Reasoning for Obviousness: If the claims of US12014347B2 largely reiterate or make only minor, insubstantial modifications to the teachings of US8554671B2 (a system for exchanging cash in a mobile environment), US10733593B2 (a platform to prevent fraudulent financial transactions), and US20150227913A1 (also for fraud prevention), then those claims would be obvious to a PHOSITA. The combination of these existing technologies would be a straightforward matter of implementing the features already described in the previous generations of the patent family. For example, adding fraud prevention mechanisms (from 10,733,593 B2) to a mobile cash exchange platform (from 8,554,671 B2) would be an obvious step for a PHOSITA aiming to improve the security and robustness of the system.

II. Obviousness over Background Art and Common General Knowledge

The patent itself identifies two prior art references that generally describe systems for wireless digital transactions: U.S. patent application No. 20090068982 to Chen et al. and U.S. patent application No. 20080010191 to Rackley III et al. [cite: US12014347B2 patent text] The instant patent distinguishes itself by stating these solutions "do not dispense with the use of cash" and still require consumers to carry cash. [cite: US12014347B2 patent text] This implies the novelty of US12014347B2 lies in its comprehensive approach to replacing cash and integrating with ATMs for non-bank account holders.

Combination: U.S. patent application No. 20090068982 (Chen et al.) + U.S. patent application No. 20080010191 (Rackley III et al.) + General knowledge in the field of mobile payments, digital wallets, and banking at the time of invention (priority date 2011-07-18).

Motivation to Combine: A PHOSITA in the field of mobile financial transactions, starting with the systems of Chen et al. (securing wireless digital transactions with mobile payment cards and PKC) [cite: US12014347B2 patent text] or Rackley III et al. (financial payments via mobile devices, generating payment instructions for MFTS) [cite: US12014347B2 patent text], would be motivated to address the inherent limitations of such systems, particularly the stated "unsatisfied need" for a system that truly dispenses with the use of physical cash and provides broader access to ATM services. The motivation would be to create a more complete, convenient, and secure digital financial ecosystem.

Reasoning for Obviousness:

1. Eliminating Physical Cash: Given the prior art's focus on digital transactions, extending these systems to more fully "replace paper cash and coins" [cite: US12014347B2 patent text] by integrating comprehensive deposit and withdrawal capabilities (e.g., via ATMs) would be an obvious next step. The problem of still needing to carry cash for certain transactions was well-known.
2. ATM Integration for All Users: The idea of enabling "individuals to retrieve (withdraw) or deposit cash in an ATM (cash dispensing machine) environment using various code generation methods or SMS" [cite: US12014347B2 patent text] for both customers and non-customers, or even non-bank account holders, would be an obvious solution to enhance the utility of mobile payment systems. QR codes, SMS, and other secure digital tokens for ATM access were evolving technologies or concepts. A PHOSITA would readily understand the benefit of allowing anyone to interact with ATMs via their mobile device, as this broadens market reach and user convenience.
3. Commodity-Backed Digital Currency ("Good Money"): The concept of "generating confidence in a new digital currency 'Good Money' that is backed by commodities, such as a precious metal 'Gold' standard" [cite: US12014347B2 patent text] would be obvious in the context of emerging digital currencies and traditional financial instruments. Throughout history, currencies have been backed by various commodities (e.g., gold standard). Applying this established principle to a new digital currency within a mobile payment platform, to provide a stable, trusted alternative to fiat currency, would be an obvious design choice for a PHOSITA seeking to build a robust financial platform.
4. Digital Wallet Features (Coupons, Points, Profile-Based Ads): The integration of features such as "saving rebate or discount coupons and receipts, while keeping track of points that accumulate for future use or redemption" [cite: US12014347B2 patent text], "usage-based credit points accumulation," and "profile-based custom advertisement push" [cite: US12014347B2 patent text] were standard functionalities expected in comprehensive digital wallet or e-commerce platforms. Combining these known elements from the broader field of mobile commerce into a financial transaction platform like PayGeo would be a straightforward application of existing technologies and marketing strategies by a PHOSITA.

In summary, while the specific claims of US12014347B2 are not available, the disclosed subject matter, especially given its direct lineage from existing patents with similar scope, and the incremental improvements over recognized background art (Chen et al. and Rackley III et al.) through the application of common technical and business motivations, suggests that many aspects of the invention would be considered obvious to a PHOSITA.

For US Patent 12014347, the following details regarding its term and family are available from the patent text:

Patent Number: US12014347B2
Title: Kit, system and associated method and service for providing a platform to prevent fraudulent financial transactions
Filing Date: 2021-08-10 (for the immediate application US17/398,789)

Patent Term Adjustments (PTA):
The patent text indicates an adjusted expiration date of 2031-09-15 [cite: US12014347B2 patent text]. Based on the earliest priority date of July 18, 2011, for U.S. patent application Ser. No. 13/185,432 (from which US12014347B2 is effectively a continuation) [cite: US12014347B2 patent text], a standard 20-year patent term would typically end on July 18, 2031. The difference between this theoretical expiration and the stated adjusted expiration (September 15, 2031) is 59 days. This indicates that a Patent Term Adjustment of approximately 59 days was granted to compensate for delays in prosecution at the USPTO. The exact calculation of PTA is automatically determined by the USPTO and typically provided in the Issue Notification Letter.

Patent Term Extensions (PTE):
There is no indication in the provided patent text or typical patent information that US12014347B2 has received a Patent Term Extension (PTE) under 35 U.S.C. § 156. PTEs are generally granted for patents claiming human drug products, medical device products, food additives, or color additives to compensate for regulatory review periods, which does not appear to apply to this patent's subject matter.

Continuation Applications:
US12014347B2 is part of a complex continuation chain, explicitly claiming priority from a series of earlier applications. The patent is a continuation of:

• U.S. patent application Ser. No. 17/189,721, filed Mar. 2, 2021 (now U.S. Pat. No. 11,087,307) [cite: US12014347B2 patent text]
• U.S. patent application Ser. No. 17/009,551, filed Sep. 1, 2020 (now U.S. Pat. No. 10,937,018) [cite: US12014347B2 patent text]
• U.S. patent application Ser. No. 16/882,006, filed May 22, 2020 (now U.S. Pat. No. 10,796,296) [cite: US12014347B2 patent text]
• U.S. patent application Ser. No. 15/786,470, filed Oct. 17, 2017 (now U.S. Pat. No. 10,733,593) [cite: US12014347B2 patent text]

It is also a continuation-in-part of:

• U.S. patent application Ser. No. 14/691,499, filed Apr. 20, 2015 (now abandoned) [cite: US12014347B2 patent text]
• U.S. patent application Ser. No. 13/974,837, filed Aug. 23, 2013 (now abandoned) [cite: US12014347B2 patent text]

And ultimately claims priority from:

• U.S. patent application Ser. No. 13/185,432, filed Jul. 18, 2011 (now U.S. Pat. No. 8,554,671) [cite: US12014347B2 patent text]

Divisional Applications:
The provided patent text does not explicitly state that US12014347B2 is a divisional application, nor does it list any divisional applications directly. The listed applications are all continuations or continuation-in-part applications.

Related Family Members:
The direct family members (parents in the continuation chain) include:

• U.S. Pat. No. 11,087,307 (from application Ser. No. 17/189,721) [cite: US12014347B2 patent text]
• U.S. Pat. No. 10,937,018 (from application Ser. No. 17/009,551) [cite: US12014347B2 patent text]
• U.S. Pat. No. 10,796,296 (from application Ser. No. 16/882,006) [cite: US12014347B2 patent text]
• U.S. Pat. No. 10,733,593 (from application Ser. No. 15/786,470) [cite: US12014347B2 patent text]
• U.S. Pat. No. 8,554,671 (from application Ser. No. 13/185,432) [cite: US12014347B2 patent text]
• U.S. Patent Application Publication No. 2022/0180347 A1 (listed as "Other versions" and corresponds to the same application number as US12014347B2 before grant) [cite: US12014347B2 patent text]

Projected Expiration Date:
The patent's legal status information states that it "expires 2031-09-15" [cite: US12014347B2 patent text]. This date reflects the 20-year term from the earliest priority date (July 18, 2011) plus any Patent Term Adjustment (PTA) that was granted.

DEFENSIVE DISCLOSURE — US 12,014,347 B2 (PayGeo / Ballout)

Document type: Defensive publication package (prior-art generation)
Target patent: US 12,014,347 B2 — "Kit, system and associated method and service for providing a platform to prevent fraudulent financial transactions"
Application: 17/398,789 · filed 2021-08-10 · granted 2024-06-18 · inventor Rabih S. Ballout · current assignee Paygeo LLC
Earliest priority relied on: 2011-07-18 (Ser. No. 13/185,432 → US 8,554,671 B2)
Statutory effect sought: Qualifying public disclosure under 35 U.S.C. § 102(a)(1) and, if filed as a defensive publication with an effective date, § 102(a)(2) art as well.
Working date of this document: 2026-04-26
Disclosure identifier block: DD-1 … DD-36 (derivatives), CPS-1 … CPS-4 (standard-combination scenarios)

---

0. Verification of the target patent number (USPTO lookup)

I searched for the identifier 12014347 literally. Results returned data for US 12,014,347 B2 only; no similar-number results were substituted. Sources consulted were the USPTO-indexed PatentsView/Patent Center mirrors (patents.google.com, patents.justia.com, patexia.com) and the PTAB docket record. Confirmed bibliographic data:

Granted independent claim 1 (as published by the indexed mirrors), verbatim substance: a method of securely accessing a local application on a mobile device, comprising launching the local application; enabling a user to set a desired security level configuration setting in the local application establishing whether the local application requires a single security level or a plurality of security levels before allowing access to at least a feature; launching the application after the setting is made; and requiring an authentication process based on that setting — only a single security level scan when set to single, and a plurality of security level scans when set to plurality. Claim 6 recites the same subject matter in system form (hardware processor + local application with a first interface for setting the configuration and a second interface for enforcing it). Claims 2–5 / 7–10 narrow the factors to password, biometric, voiceprint, thumbprint.

Flagged contradictions with previously generated sections of this analysis (must be corrected downstream):

1. IPR petitioner identity. The earlier sections attributed IPR2025-01555 to "Unified Patents" as petitioner, sourced from the Google Patents legal-status link. The PTAB docket record and third-party PTAB aggregators identify the petitioner as Samsung Electronics Co., Ltd. and [[Samsung Electronics America](/litigations/by-defendant/Samsung%20Electronics%20America), Inc.](/litigations/by-plaintiff/Samsung%20Electronics%20America%2C%20Inc.) (Petitioner counsel: Goldberg, Joshua et al.; Patent Owner counsel: Hannah, James et al.). "Unified Patents" is the publisher of the data portal linked in the Google Patents entry, not the petitioner. The earlier "PTAB challenges" section was internally inconsistent on this point (heading named Samsung; body named Unified Patents).
2. IPR chronology. Filed 2025-10-01; institution decision date 2026-01-27; status Discretionary Denial. A Petitioners' Updated Exhibit List was filed 2026-01-07 (Exhibits 1031–1038 added) while the petition was still pending institution.
3. Claims availability. Earlier sections stated the claims section was unavailable. The granted claim set is now confirmed (10 claims, two independents) and is used below as the anchor.
4. Pre-grant numbering. The published application US 2022/0180347 A1 carries differently numbered claims (e.g., "13. A method of securely accessing a local application…", "18. A system…") covering the same subject matter later issued as claims 1 and 6. Do not treat claim 13/18 as issued claims.

Prior art already marshalled by the petitioner (Exhibits 1005–1024 of IPR2025-01555), useful as a combination baseline: US 8,195,576 (Grigg); US 2009/0152343 (Carter); Google Security Blog, "Advanced sign-in security for your Google account" (2011-02-10); US 2012/0166554 (Preece); US 8,971,819 (Nicoara); US 8,635,287 (Shih); WO 02/28067 (Mathiassen); US 3,466,394 (French); US 8,732,855 (Thomas); US 8,819,150 (Osinga); FFIEC Authentication in an Internet Banking Environment (Oct. 2005); US 7,373,515 (Owen); US 7,657,489 (Stambaugh); Sanyal et al., A Multifactor Secure Authentication System for Wireless Payment (2010); Al-Qayedi et al., Combined Web/Mobile Authentication for Secure Web Access Control (2004); Hulea, Fingerprint Recognition Distributed System (2008); Whitehead, In Safe Hands (2008); Engadget, Pantech GI1100 (2008).

Note on scope of this document. Per the constraint, the patent is not summarized. The six modules below are used only as derivation anchors; everything in Sections 2–4 is new technical matter.

---

1. Derivation anchors and axes

The granted claim set is narrow (configurable single-vs-plural security-level gating of a local mobile application). The specification, however, discloses a much wider envelope (proximity swipe transfer, scannable-code cash dispensation at dispensing machines, commodity-backed digital tender, coupon/points/geo-advertising engine, lending with e-signature automation). Competitors filing incremental improvements will most plausibly land in the gaps between the narrow claims and the wide disclosure. Six anchors are therefore used:

Axes applied per anchor: (1) material/component substitution, (2) operational parameter expansion, (3) cross-domain application, (4) emerging-tech integration, (5) inverse/failure mode, plus one additional variation per anchor labelled (6) extension.

Publication protocol (append to any filing of this document). Publish the full text with a SHA-256 digest and an RFC 3161 trusted timestamp; deposit with a defensive-publication registry (IP.com, Research Disclosure), an open repository with a DOI (Zenodo/OSF), and the Internet Archive. Release under CC0-1.0 to maximize § 102(a)(1) accessibility and to eliminate any "confidentiality" argument. Include the Mermaid source verbatim so the disclosure is self-contained.

---

2. Derivative disclosures

---

ANCHOR A1 — Configurable security-level gating of a local application

---

DD-1 — Hardware-rooted security-policy register (Axis 1: material/component substitution)

Enabling description. Replace the software-stored "security level configuration setting" with a hardware non-volatile policy register. Two implementations are disclosed. (a) Secure element: a GlobalPlatform-compliant SE hosts a JavaCard applet exposing a 16-bit policy word at a fixed object ID; each bit maps to an authentication factor class (bit 0 password, bit 1 voice, bit 2 fingerprint, bit 3 DNA/chemical transducer, bit 4 device-bound key possession, bit 5 out-of-band SMS challenge). The value is written only through an STORE DATA APDU gated by an admin secure channel; reads return the word plus a monotonically increasing write counter. (b) SoC fuse/TPM route: a TPM 2.0 NV index of type counter-backed ordinary space, with authValue bound to the platform owner hierarchy; the local application queries the index at cold start and after every TPM2_Clear reset. Enforcement: a policy engine in the application's onCreate reads the register, builds a Boolean requirement vector, and refuses to instantiate the wallet feature set unless every asserted bit has been satisfied within the same session. A digest of (policy word ‖ counter ‖ device attestation certificate) is emitted to the backend on each unlock for non-repudiation. Fail-closed default: an unreachable register yields policy 0x0000 (deny), never a permissive default.

flowchart TD
  A["Boot ROM measures fuse and SE state"] --> B["App queries policy register 16-bit word"]
  B --> C{"Read successful"}
  C -->|No| D["Load policy 0x0000 - deny all features"]
  C -->|Yes| E["Build requirement vector from asserted bits"]
  E --> F{"All asserted bits satisfied in session"}
  F -->|No| G["Prompt next unsatisfied factor"]
  G --> F
  F -->|Yes| H["Instantiate wallet feature set"]
  H --> I["Emit policy digest plus attestation to backend"]
  D --> J["Write audit event with counter value"]

---

DD-2 — Continuous security-level scale with k-of-n threshold enforcement (Axis 2: operational parameter expansion)

Enabling description. Generalize the binary "single vs plurality" setting into a continuous integer security level L ∈ [1, 64] with an independently configurable threshold k (1 ≤ k ≤ L). Enrollment stores L candidate factors; unlock requires any k of them to succeed within a bounded collection window W (default 20 s, configurable 0.1 s – 300 s). Factor evidence is aggregated by a score-level fusion unit that emits a per-factor confidence c_i ∈ [0,1]; success requires at least k factors with c_i > τ_i and a fused score Σ w_i c_i > Θ, where w_i and Θ are stored in the same register as DD-1. Extreme-scale operating points that are explicitly enabled: (i) high-frequency re-authentication — L = 1, W = 0.1 s, used on factory-floor HMIs where a wristband token is re-verified every 30 s of activity; (ii) high-assurance clearing — L = 6, k = 6, W = 300 s, used for large-value dispensations (see A4); (iii) industrial provisioning — a single policy template is distributed to 10⁶ endpoints via OMA-DM/MDM and verified by comparing per-device register digests to the template digest. Degradation ladder: failure to collect k factors in W returns a retry-with-backoff state, and after three failures the level is auto-escalated by +2 (step-up) for the next attempt.

stateDiagram-v2
  [*] --> Idle
  Idle --> Collecting : app launch reads level L and threshold k
  Collecting --> Fusion : factor evidence arrives with confidence c_i
  Fusion --> Collecting : fewer than k factors above tau
  Fusion --> StepUp : collection window W elapsed below threshold
  StepUp --> Collecting : auto escalate level by 2
  Fusion --> Unlocked : k or more factors pass and fused score above Theta
  Unlocked --> Idle : session timeout or explicit lock
  Collecting --> LockedOut : three consecutive failures
  LockedOut --> Idle : administrative reset through secure channel

---

DD-3 — Cross-domain deployment of the gating mechanism (Axis 3: cross-domain application)

Enabling description. Three unrelated deployments are enabled with the same policy-register primitive.

(a) Aerospace (line-replaceable-unit maintenance access): a tablet-based maintenance application gates access to ARINC 615A data-loading and to fault-isolation data. Operator role sets level L = 2 (badge-derived key possession + fingerprint); certifying staff role sets L = 3 (adds an e-signature over the load manifest). The policy register is part of the portable maintenance access terminal; the register digest is written into the aircraft's post-flight report so that every software load is attributable.

(b) AgTech (spray-record and geofence authority): a tractor terminal gates the "as-applied" prescription map and the sprayer's section controllers. Operator sets L = 1 (PIN) for field operation; agronomist sets L = 3 (PIN + voice + hardware key) for editing the prescription; level-3 policy is required to alter geofence boundaries so that a stolen terminal cannot silently widen an application zone.

(c) Consumer electronics (in-app purchase and account-change gating): a set-top/console application uses L = 1 for content rental, L = 2 for profile creation, and L = 3 for parental-control policy edits; the register is in the SoC's secure world and survives a factory reset only if the child-safety flag is fused.

flowchart LR
  subgraph Aero["Aerospace LRU data load"]
    A1["Role operator L=2"] --> A2["Data loader enabled"]
    A3["Role certifier L=3"] --> A4["Manifest e-signature enabled"]
  end
  subgraph Ag["AgTech prescription edit"]
    B1["Operator L=1"] --> B2["As-applied view"]
    B3["Agronomist L=3"] --> B4["Geofence edit authority"]
  end
  subgraph CE["Consumer device purchases"]
    C1["L=1"] --> C2["Rental"]
    C3["L=2"] --> C4["Profile creation"]
    C5["L=3"] --> C6["Parental policy edit"]
  end
  R["Shared policy register primitive"] --> A1
  R --> A3
  R --> B1
  R --> B3
  R --> C1
  R --> C3
  R --> C5

---

DD-4 — Risk-adaptive security level set by an inference engine with attested telemetry (Axis 4: emerging-tech integration)

Enabling description. The level L is not fixed by the user alone; a local inference engine computes a risk score R from features available on-device (time since last unlock, geohash cell, cell-tower change velocity, device-motion signature, peripheral inventory, prior failed attempts, network reputation) and maps R → required L via a monotone lookup table shipped in a signed firmware blob. On-device execution uses an INT8-quantized gradient-boosted tree or a 3-layer MLP within the TEE so raw telemetry never leaves the device; only (R bucket, chosen L, model version hash) is transmitted. IoT integration: when the handset is the companion to a connected vehicle or a smart lock, the same risk engine consumes MQTT topics carrying lock/sensor state (e.g., paygeo/lock/state) and raises L when a door-open event coincides with a payment attempt. Blockchain element: the (R bucket, L, model hash) tuple is appended to a permissioned ledger (Hyperledger Fabric channel or an EAS-style attestation contract) so that a regulator or a dispute-resolver can verify that the platform applied its stated SCA-equivalent policy at the time of a transaction without exposing personal data.

sequenceDiagram
  participant TEE as On-device TEE risk engine
  participant App as Local wallet app
  participant IoT as Companion IoT broker
  participant LED as Permissioned ledger
  IoT->>App: lock state change event
  App->>TEE: telemetry bundle geohash motion failures
  TEE->>TEE: compute risk score R and map to required L
  TEE->>App: required L plus model hash
  App->>App: enforce L factors before feature access
  App->>LED: append R bucket L and model hash attestation
  LED-->>App: transaction receipt and block height

---

DD-5 — Fail-safe and duress operation of the gating mechanism (Axis 5: inverse/failure mode)

Enabling description. A deliberately degraded architecture is disclosed in which every failure path terminates in less capability, never more. (i) Sensor-fault fallback: if a biometric subsystem fails its power-on self-test, its bit is cleared from the register and L is reduced, but a compensating per-transaction cap C is simultaneously imposed (e.g., C = 1/10 of the user's rolling daily median) until the sensor is re-validated; a signed sensor-health certificate from the OEM is required to restore the bit. (ii) Duress factor: one designated factor instance (a distinct fingerprint digit, a distinct passphrase, or a distinct voice phrase) is enrolled as a duress scan. A duress scan satisfies the gating test and admits the user, but the application operates against a shadow ledger whose balances and history are generated from a decoy dataset; every action is mirrored to a silent alert channel, and any dispensation is limited to a small pre-set amount so that the transaction succeeds plausibly and no coercion-visible failure occurs. (iii) Offline/air-gapped mode: with no network, the app accepts a locally verified factor set and issues only signed deferred transactions into a replay-protected queue with a hard aggregate ceiling; a monotonic counter in the secure element prevents queue exhaustion attacks. (iv) Watchdog re-arm: after any fallback, a watchdog restores the highest configured L after a bounded interval unless the fallback condition persists.

flowchart TD
  A["Unlock attempt"] --> B{"Sensor self-test pass"}
  B -->|No| C["Clear sensor bit and reduce L"]
  C --> D["Impose transaction cap C"]
  B -->|Yes| E["Evaluate presented factor set"]
  E --> F{"Factor matches duress template"}
  F -->|Yes| G["Open shadow ledger with decoy balances"]
  G --> H["Silent alert to monitoring channel"]
  G --> I["Cap dispensation to preset small amount"]
  F -->|No| J{"Network reachable"}
  J -->|No| K["Offline queue with aggregate ceiling"]
  J -->|Yes| L["Normal gated session"]
  D --> M["Watchdog re-arm after interval"]
  K --> M

---

DD-6 — Policy roaming across a device fleet (Axis 6: extension)

Enabling description. The "security level configuration setting" is externalized as a signed, portable policy token so that a user's chosen gating rule is enforced identically on a phone, a smartwatch, a vehicle head unit, and a shared kiosk. The token is a JWS with claims {sub, lvl, k, factors[], w_ms, max_amount, iat, exp, nonce} signed by the user's platform key and countersigned by the platform backend. Each endpoint's local policy agent verifies the JWS against a pinned JWKS, then reconciles the token requirement with its own sensor inventory: a factor named in the token but absent on the endpoint is replaced by a declared equivalent listed in a signed capability manifest (e.g., voiceprint → on-device speaker verification; thumbprint → capacitive or ultrasonic fingerprint of any vendor). A per-endpoint monotonic counter and the token nonce prevent replay of an old, weaker policy token; token rollback is additionally blocked by including the previous token's hash in each new token (hash chain). Reconciliation failures are logged as policy_mismatch events and force the strictest of the two policies.

sequenceDiagram
  participant P as Platform backend
  participant U as User key store
  participant D1 as Phone agent
  participant D2 as Watch agent
  participant D3 as Kiosk agent
  U->>P: sign policy token with level k factors and ceiling
  P->>P: countersign and append to hash chain
  P->>D1: distribute token
  P->>D2: distribute token
  P->>D3: distribute token
  D1->>D1: verify signature and reconcile sensors
  D2->>D2: substitute equivalent factor from capability manifest
  D3->>D3: detect absent factor and request strictest policy
  D1-->>P: policy_mismatch or accepted with counter
  D3-->>P: policy_mismatch or accepted with counter

---

ANCHOR A2 — Authentication factors, including molecular/chemical identity transducers

---

DD-7 — Substituted chemical-identity transducers for the nucleic-acid biometric (Axis 1: material/component substitution)

Enabling description. The specification's molecular switch heats a sample, denatures it, and reads a residual electrical signature across a carbon nanotube/polymer receptor. Six substitute transducers are enabled that produce the same functional output (a per-user, per-sample verification value): (a) an aptamer-functionalized graphene field-effect transistor whose Dirac-point shift ΔV_Dirac is the verification value; (b) a silicon-nanowire array with peptide-nucleic-acid probes, read by a transimpedance amplifier at 1 kHz; (c) a MoS₂ monolayer channel substituted for the carbon nanotube, benefiting from a direct bandgap and higher on/off ratio; (d) a molecularly imprinted polymer capacitive layer (no biological probe at all, hence room-temperature stability); (e) CRISPR-Cas12a collateral-cleavage fluorescence readout with a FAM-BHQ reporter, read by a phone camera; (f) surface-enhanced Raman scattering on a gold nanorod array with a 785 nm laser, producing a spectral fingerprint. For voice and dactyloscopic factors, the equivalents disclosed are laryngeal surface-EMG, throat-contact microphones and ultrasound tongue imaging; and ultrasonic under-display, optical under-display, and fringe-projection 3D fingerprint capture. Each transducer emits the same abstract record {factor_class, confidence, template_version, sensor_id, calibration_digest} so that the A1 policy engine is unchanged.

classDiagram
  class FactorTransducer {
    +string factor_class
    +float confidence
    +string sensor_id
    +read_value() float
    +self_test() bool
  }
  class NucleicAcidTransducer {
    +float delta_v_dirac
    +float threshold_current
  }
  class VoiceTransducer {
    +float spectral_score
    +float emg_score
  }
  class DactyloscopicTransducer {
    +float minutiae_match
    +bool liveness
  }
  FactorTransducer <|-- NucleicAcidTransducer
  FactorTransducer <|-- VoiceTransducer
  FactorTransducer <|-- DactyloscopicTransducer
  class PolicyEngine {
    +int required_level
    +int threshold_k
    +evaluate(list evidence) bool
  }
  PolicyEngine --> FactorTransducer : consumes abstract records

---

DD-8 — Nanoscale single-molecule readout to industrial-scale cohort enrollment (Axis 2: operational parameter expansion)

Enabling description. The same verification chemistry is operated at both extremes. Nanoscale: a solid-state nanopore (SiN membrane, 5 nm pore) translocates a single labeled oligomer; the ionic-current blockade histogram ΔI/I₀ and dwell time τ form a two-dimensional signature compared against an enrolled reference by a Mahalanobis distance test; sample volume is < 1 nL and the analyzer is a USB-C dongle drawing 40 mW. Industrial scale: a 96-well microplate reader with automated liquid handling performs cohort enrollment for up to 1,536 samples per run at 4,000 samples/hour, used by an employer or a cooperative to enroll 10⁵ members; each well's qPCR Ct value (or lateral-flow line intensity read by a CMOS imager) is hashed to a template commitment under HKDF with a per-subject salt. Bridging elements disclosed: (i) temperature window — a staged profile of 25 °C binding, 72 °C extension, 95 °C denaturation, with closed-loop control of the heater to ±0.3 °C; (ii) cold-chain deviation handling — a cryogenic-logistics tag records cumulative thermal exposure and invalidates templates beyond a threshold; (iii) high-frequency sampling — chemical verification at 1 Hz for continuous-access scenarios, throttled by an energy budget model that estimates joules per verification from the transducer's calibration digest.

flowchart LR
  subgraph Nano["Nanoscale path"]
    N1["Nanopore 5 nm"] --> N2["Ionic current blockade histogram"]
    N2 --> N3["Mahalanobis distance vs reference"]
  end
  subgraph Ind["Industrial cohort path"]
    I1["96 or 384 well plate"] --> I2["Automated liquid handler"]
    I2 --> I3["Plate reader Ct or line intensity"]
  end
  N3 --> C["Template commitment via HKDF with per-subject salt"]
  I3 --> C
  C --> V["Verification value"]
  T["Thermal exposure tag"] --> G{"Cumulative exposure within limit"}
  G -->|No| X["Invalidate template and force re-enroll"]
  G -->|Yes| C

---

DD-9 — Cross-domain chemical-identity verification (Axis 3: cross-domain application)

Enabling description. (a) Aerospace — crew duty-of-care: flight-crew fitness-for-duty terminals verify identity by breath-analyte and saliva-analyte readout on a graphene FET before releasing aircraft keys or accepting a duty sign-on; the same template commitment used for wallet access is reused, satisfying a single-enrollment requirement. (b) AgTech — livestock and provenance: a hand-held reader performs rapid nucleic-acid identification of animal ear-tissue or hair-root samples at the point of sale at an auction yard; the result is bound to the animal's RFID EID tag and to a warehouse receipt issued by the platform, so a commodity receipt (see A5) becomes traceable to a verified animal. (c) Consumer electronics — child and shared-device accounts: a toy or tablet requires a guardian's oral-swab template (molecularly imprinted polymer cartridge, no lab) to authorize purchases above a threshold, ensuring the gating factor is a living guardian and not a copied PIN. In each case the abstract record format of DD-7 is preserved, only the sample-acquisition front end changes.

flowchart TD
  subgraph Aero["Aerospace crew fitness"]
    A1["Breath and saliva cartridge"] --> A2["Graphene FET readout"]
    A2 --> A3["Release keys or accept sign-on"]
  end
  subgraph Ag["AgTech livestock provenance"]
    B1["Hair root or ear tissue"] --> B2["Handheld NA reader"]
    B2 --> B3["Bind to RFID EID and warehouse receipt"]
  end
  subgraph CE["Consumer guardian consent"]
    C1["Oral swab MIP cartridge"] --> C2["Colorimetric or capacitive read"]
    C2 --> C3["Authorize purchase above threshold"]
  end
  A2 --> R["Unified template commitment service"]
  B2 --> R
  C2 --> R

---

DD-10 — AI fusion, IoT enrollment, and blockchain template commitments (Axis 4: emerging-tech integration)

Enabling description. Factor evidence from heterogeneous transducers is fused by a two-stage model: per-factor convolutional or recurrent feature extractors run in the TEE and emit embeddings; a fusion layer (logistic regression over calibrated scores, or a shallow transformer over the embedding sequence ordered by capture time) outputs a fused confidence and, importantly, an explanation vector of per-factor contributions used for dispute resolution. IoT element: enrollment is performed on a dedicated provisioning appliance that exposes a local MQTT topic namespace (enroll/+/session), accepts pluggable cartridges, and writes template commitments to the subject's secure element; revocation is a signed tombstone over the same topic. Blockchain element: raw biometrics never reach a chain. Instead the platform publishes (i) a Merkle root over all active template commitments per epoch, (ii) a proof-of-custody record for each enrollment appliance, and (iii) a ZK-SNARK proving that the number of commitments equals the number of provisioned subjects and that no revoked commitment appears in the tree — a solvency-style proof for the identity ledger. Verification at transaction time checks a Merkle inclusion proof plus the hardware attestation chain of the capturing sensor.

sequenceDiagram
  participant AP as Enrollment appliance
  participant SE as Subject secure element
  participant MQ as Local MQTT broker
  participant CH as Identity ledger contract
  participant VS as Verifier
  AP->>SE: deliver template commitment with per-subject salt
  AP->>MQ: publish enrollment session record
  MQ->>CH: submit commitment hash and custody record
  CH->>CH: rebuild epoch Merkle root
  CH-->>MQ: publish root and inclusion proof
  VS->>SE: request challenge signature
  SE-->>VS: signed attestation plus Merkle proof
  VS->>CH: verify inclusion and revocation status
  CH-->>VS: valid no revoked commitment

---

DD-11 — Template aging, spoof rejection, and fail-closed enrollment (Axis 5: inverse/failure mode)

Enabling description. Three inverse operating modes are disclosed. (i) Adaptive template aging: each template carries a quality metric; a drift monitor tracks the matched-confidence trend and triggers re-enrollment when the 30-day mean drops below a band or when the within-class variance exceeds a threshold, converting a would-be false rejection into a scheduled lifecycle event rather than a lockout. (ii) Presentation-attack rejection with graceful degradation: the transducer stack reports a liveness score; a low liveness score never denies outright but instead demotes the factor to weight-reduced status and raises the required L by one, ensuring that a genuine user with a damaged fingertip is not permanently excluded, while a spoof with a strong template match is neutralized by the level escalation. (iii) Fail-closed enrollment: enrollment is atomic — a partially written template commitment is invalidated by an atomic abort record, and the subject's policy register is set to enroll_incomplete, which denies wallet features but permits a local-only "diagnostic" mode that cannot move value. A printed recovery code (BIP-39-style 12-word seed, platform-derived) allows supervised re-enrollment after a loss-of-template event.

stateDiagram-v2
  [*] --> Enrolling
  Enrolling --> Active : commitment written and abort record cleared
  Enrolling --> Incomplete : power loss or quality below floor
  Incomplete --> Diagnostic : local-only mode, no value movement
  Diagnostic --> Enrolling : recovery seed presented under supervision
  Active --> Drifting : confidence trend below band
  Drifting --> Reenroll : scheduled lifecycle event
  Reenroll --> Active : new commitment version
  Active --> WeightReduced : low liveness but match strong
  WeightReduced --> Active : liveness recovers
  Active --> Revoked : signed tombstone published
  Revoked --> [*]

---

DD-12 — Compound single-scan gestures (Axis 6: extension)

Enabling description. A single user-visible scan is decomposed into a compound challenge whose sub-actions are ordered and mutually entangling: a spoken passphrase whose recognized content is correct while, simultaneously, the accelerometer captures the phone being drawn in a user-specific 3D shape, and the screen records a touch-pressure/dwell pattern. The three channels are captured within a 1.5 s window and are bound by a server-issued nonce mixed into all three feature vectors, so a recorded voice replay cannot be paired with a fresh motion trace (challenge-response binding; compare the nonce-binding technique in WO 2013/066928-style responsive-evidence schemes). The compound result is a single Boolean consumed by the A1 policy engine as one "scan," which lets a user satisfy a two-level configuration with one physical action while preserving the claimed "plurality of security level scans" semantics at the evidence-layer level (one scan event, multiple verified factors). Order sensitivity is enforced: if the motion begins before the passphrase's first phoneme, the compound is rejected as out-of-order.

flowchart TD
  A["Server issues nonce"] --> B["Capture window 1.5 s opened"]
  B --> C["Speech channel with content check"]
  B --> D["IMU 3D shape trace"]
  B --> E["Touch pressure and dwell pattern"]
  C --> F["Bind each vector to nonce"]
  D --> F
  E --> F
  F --> G{"Order respected and all three above threshold"}
  G -->|Yes| H["Emit single compound factor pass"]
  G -->|No| I["Reject compound and log channel causes"]
  H --> J["Policy engine consumes one scan event"]

---

ANCHOR A3 — Proximity/remote value handoff with a transferable credential

---

DD-13 — Substituted physical layers for the swipe handshake and the scannable credential (Axis 1: material/component substitution)

Enabling description. The proximity handoff is re-implemented on five alternate physical layers plus three alternate credential carriers. Physical layers: (a) UWB per IEEE 802.15.4z with a scrambled timestamp sequence, giving centimetre ranging that is cryptographically bound to the transaction, defeating relay attacks by construction; (b) BLE 5.4 with constant-tone extension and angle-of-arrival array, providing bearing plus a ranging estimate; (c) data-over-sound in the 18–20 kHz band with a frequency-shift-keyed profile, which works on any handset with a speaker and microphone and requires no pairing; (d) Li-Fi using the phone's screen as a transmitter and the camera as a receiver, at up to a few kb/s with visual confirmation; (e) magnetic secure transmission emulating a track-2 field with a coil and driver, for backwards compatibility with legacy terminals. Credential carriers: a chipless RFID tag (a resonant frequency signature, no silicon), a printed graphene antenna on paper, and a reflective e-ink segment display that can be re-written so the credential is destroyed after first presentation. The credential payload is invariant across carriers: {amount, currency, payor_pubkey, nonce, not_before, not_after, max_uses=1} signed with an Ed25519 key held in the secure element, so only the transport changes.

flowchart LR
  subgraph PHY["Physical layers"]
    P1["UWB with timestamp sequence"]
    P2["BLE 5.4 angle of arrival"]
    P3["Data-over-sound 18 to 20 kHz"]
    P4["Li-Fi screen to camera"]
    P5["Magnetic secure transmission"]
  end
  subgraph CAR["Credential carriers"]
    C1["Chipless RFID resonant tag"]
    C2["Printed graphene antenna"]
    C3["Reflective e-ink segment display"]
  end
  P1 --> S["Signed credential payload"]
  P2 --> S
  P3 --> S
  P4 --> S
  P5 --> S
  C1 --> S
  C2 --> S
  C3 --> S
  S --> V["Receiver verifies Ed25519 signature and nonce"]

---

DD-14 — Contact distance to kilometre link, and 10⁴-way concurrency (Axis 2: operational parameter expansion)

Enabling description. The handoff is specified across the full range of scales. (i) Contact/near-contact: a 5 mm coil-coupled exchange at 13.56 MHz, with the credential transferred in under 80 ms, used for transit gates. (ii) Metre-scale room exchange: UWB ranging with a 30 cm accuracy gate — the transaction is only committed if the measured range is below the payee's declared maximum (mitigating the "pay from across the mall" relay). (iii) Kilometre-scale: a LoRa-class link at 868/915 MHz with a 4-byte application payload and a 1% duty cycle, used for remote dispensing kiosks in rural areas; the handshake is completed by a two-phase commit over LoRa with an offline credential that carries the payor's signature and a max-uses of one. (iv) Dense-venue concurrency: 10⁴ simultaneous handshakes in a stadium, achieved by a slotted-ALOHA-like contention window derived from a per-device hash of the venue beacon's nonce, plus a backend sharded by geohash so that no single validator serializes more than 500 transactions per second. (v) Battery-less tags: the receiver harvests 2.4 GHz RF at −18 dBm to power a single response burst, so an unpowered credential (a wristband, a luggage tag) can complete a handoff. Explicit parameter table published: latency budget 50 ms contact, 800 ms LoRa; credential TTL 90 s default; replay window zero (single-use nonce nullifier).

flowchart TD
  A{"Handoff distance"} -->|Under 5 mm| B["Coil coupled 13.56 MHz under 80 ms"]
  A -->|Under 3 m| C["UWB ranging gate 30 cm"]
  A -->|Up to 5 km| D["LoRa two phase commit"]
  A -->|Battery-less| E["RF harvested response burst"]
  B --> F["Single use nonce nullifier"]
  C --> F
  D --> F
  E --> F
  C --> G{"Measured range below declared maximum"}
  G -->|No| H["Abort and flag possible relay"]
  G -->|Yes| F

---

DD-15 — Cross-domain handoff of a transferable credential (Axis 3: cross-domain application)

Enabling description. The same signed single-use credential is repurposed in three industries. (a) Aerospace: a maintenance credential is handed from a technician's tablet to a parts-crib terminal to release a serialized line-replaceable unit; the credential binds the part's serial number and the work order, and the terminal writes the release into the aircraft's configuration record — the "payment" is the release event, the "payee" is the bin, and the nonce prevents a double release. (b) AgTech: a scale ticket at a grain elevator is issued to the farmer's phone as a signed credential; at the elevator office the credential is scanned to release a settlement payment and to mint a warehouse receipt; the elevator can also return a credential (mirroring reverse code generation) authorizing a truck to leave with a load, which solves the classic "who owns the load now" ambiguity. (c) Consumer electronics: a warranty/DRM entitlement is transferred peer-to-peer — a device-bound license moves with a single scan at the point of resale, with the credential binding the device's public key; the previous owner's key is rotated out atomically so the license cannot be used twice.

sequenceDiagram
  participant Tech as Technician tablet
  participant Crib as Parts crib terminal
  participant FAR as Farmer phone
  participant ELE as Elevator office terminal
  participant BUY as Buyer device
  Tech->>Crib: hand off signed credential binding LRU serial and work order
  Crib->>Crib: verify signature and nullify nonce
  Crib-->>Tech: release confirmation written to configuration record
  ELE->>FAR: return signed haul credential for truck departure
  FAR->>ELE: present scale ticket credential for settlement
  ELE-->>FAR: settlement payment and warehouse receipt
  BUY->>BUY: receive license credential bound to buyer device key
  BUY->>BUY: rotate previous owner key out atomically

---

DD-16 — Anti-relay distance bounding, beacon mesh, and ledger settlement (Axis 4: emerging-tech integration)

Enabling description. Three integration layers are disclosed. (i) ML-assisted anti-relay: a rapid-bit-exchange distance-bounding protocol (bit commitment at t₁, challenge at t₂, response at t₃, measured RTT below a threshold) is combined with a learned classifier over RSSI/ToF/magnetometer residuals that flags physically inconsistent proximity claims (for example, a claimed 20 cm range with a 40 ms one-way delay, an impossible value for RF in air). The classifier's features and thresholds are published in a signed model card so implementers can reproduce the decision boundary. (ii) IoT beacon mesh: venue beacons publish presence counters and a rolling nonce over BLE advertisements; the payer's phone incorporates the current beacon nonce into the credential, so a credential minted outside the venue cannot be redeemed inside it — a geofenced, time-bounded credential. (iii) Blockchain settlement: instead of a centralized switch, provisioned value sits in a two-of-two hash-time-locked contract; the handoff reveals a preimage that settles both legs atomically within a locktime, and a nullifier registry on-chain or in a permissioned sidechain prevents double redemption without revealing the payor's identity (the nullifier is a hash of the credential nonce and a per-user secret).

flowchart TD
  A["Rapid bit exchange distance bounding"] --> B["Measured RTT below threshold"]
  C["Learned relay anomaly classifier on RSSI and ToF residuals"] --> D{"Proximity claim physically consistent"}
  B --> D
  D -->|No| E["Abort handoff and log relay suspicion"]
  D -->|Yes| F["Credential embeds venue beacon nonce"]
  F --> G["Two of two hash time locked contract"]
  G --> H["Preimage reveal settles both legs"]
  H --> I["Nullifier registry blocks double redemption"]
  I --> J["Settlement receipt to both parties"]

---

DD-17 — Offline bearer mode, atomic abort, and degraded-functionality handoff (Axis 5: inverse/failure mode)

Enabling description. The handoff is designed to fail safely when either side is offline or underpowered. (i) Offline bearer credential: a credential signed while online can be redeemed with no network, provided its value is under a hard ceiling, its TTL is unexpired, its nullifier has not been seen locally, and the cumulative offline exposure of the payor device (tracked in a monotonic counter) is under a reserve. On reconnect, offline redemptions are posted in a batch; a redemption against an exhausted reserve is resolved by turning the payor's account into a negative-availability state that blocks further offline issuance until settled, rather than by reversing the merchant's credit (merchant-protective ordering). (ii) Atomic abort: the handoff implements a prepare/commit/abort cycle keyed on the credential nonce; if the receiver's commit acknowledgement is lost, the payor's next online contact queries the nullifier registry and either completes or releases the reservation — never double-spends. (iii) Low-power/limited-functionality mode: on entering a battery-saver state, the application reduces the handoff to an audible two-tone challenge with an 8-character confirmation code displayed for manual entry, sacrificing bandwidth and convenience but preserving the one-time-use property.

stateDiagram-v2
  [*] --> OnlineSign
  OnlineSign --> OfflineIssued : credential signed and counter incremented
  OfflineIssued --> Prepare : presented to receiver
  Prepare --> Commit : receiver acknowledges
  Prepare --> Abort : acknowledgement lost or TTL expired
  Commit --> Reconcile : payor reconnects
  Abort --> Reconcile : reservation released
  Reconcile --> Settled : nullifier registry confirms single use
  Reconcile --> NegativeAvailability : reserve exhausted
  NegativeAvailability --> Settled : top-up settles the deficit
  OfflineIssued --> LowPowerTone : battery saver engaged
  LowPowerTone --> Prepare : manual code confirms

---

DD-18 — Multi-hop forwarding of a credential with per-hop economics (Axis 6: extension)

Enabling description. A credential can be re-forwarded n hops before final redemption — the mechanism generalizes the specification's "forward the fund, in part or in full, to one or more contacts" and the reverse-code-generation construct. Each hop applies a deterministic split: the holder may carve off a portion (value-neutral split via two child credentials whose amounts sum to the parent) or transfer the whole credential with a per-hop fee deducted by the forwarding application. Each hop appends a signature to a lineage array and decrements a hop counter (default n = 4); a zero-hop credential cannot be forwarded again. TTL shrinks geometrically per hop (T, T/2, T/4 …) so forwarding cannot extend validity indefinitely. The final redeemer submits the lineage; the switch verifies the signature chain, sums splits, verifies the leaf amounts equal the root amount, and rejects any lineage whose hop count is exhausted or whose intermediate signature is missing.

flowchart LR
  R["Root credential value V TTL T hops 4"] --> A["Hop 1 split V1 with fee f1"]
  R --> B["Hop 1 split V2 with fee f2"]
  A --> A1["Leaf redeemable amount"]
  B --> B1["Hop 2 transfer TTL T over 4"]
  B1 --> B2["Leaf redeemable amount"]
  A1 --> S["Switch verifies lineage signatures"]
  B2 --> S
  S --> T{"Sum of leaves equals root and hops not exhausted"}
  T -->|Yes| U["Settle all leaves atomically"]
  T -->|No| V["Reject lineage"]

---

ANCHOR A4 — Code-mediated dispensation at dispensing machines

---

DD-19 — Substituted dispensing machines, scanners, and media (Axis 1: material/component substitution)

Enabling description. The "generate scan code → present at machine" loop is re-enabled on a family of machines and readers that are functional equivalents of an ATM: a cash-recycling kiosk with note validation and recirculation; a smart safe in a retail back office with a one-way deposit slot and a note-acceptor; a self-checkout terminal with a cash-acceptor/dispenser; a vending machine with a bill validator; a mobile point-of-sale terminal with a printer; and a precious-metal kiosk that dispenses a minted coin or a sealed assay card. Reader substitutions: a 1D/2D CMOS imager, a laser scanner, an NFC reader in card-emulation mode, a magnetic-stripe reader driven by the phone's coil, a capacitive under-display fingerprint pad on the machine (so the code and the identity are captured at the same surface), and a camera-plus-OCR path for a human-readable fallback code. Media substitutions: a 2D matrix code, a colour 3D code using eight hues per module (3 bits per module), a data-over-sound chirp, an SMS-borne numeric code with a check digit, and an e-ink display that displays the code once and then blanks. All variants carry the same abstract payload of DD-13 extended with {machine_scope, dispense_currency, denom_mix[]}.

flowchart TD
  subgraph M["Dispensing machines"]
    M1["Cash recycling kiosk"]
    M2["Retail smart safe"]
    M3["Self checkout with cash acceptor"]
    M4["Precious metal kiosk"]
  end
  subgraph RD["Readers"]
    R1["CMOS imager"]
    R2["NFC reader card emulation"]
    R3["Magnetic stripe reader"]
    R4["Under display fingerprint pad"]
  end
  subgraph MD["Media"]
    D1["2D matrix code"]
    D2["Colour 3D code 3 bits per module"]
    D3["Data over sound chirp"]
    D4["SMS numeric code with check digit"]
  end
  D1 --> R1
  D2 --> R1
  D3 --> R1
  D4 --> R4
  R1 --> P["Abstract dispense payload"]
  R2 --> P
  R3 --> P
  R4 --> P
  M1 --> P
  M2 --> P
  M3 --> P
  M4 --> P

---

DD-20 — Micro-dispense to bulk settlement and adversarial timing windows (Axis 2: operational parameter expansion)

Enabling description. The dispensation path is specified at extremes. (i) Micro-value: a $1 equivalent dispense with a 15-second code TTL, used at a vending machine; the machine's note/coin hopper is bypassed and the payout is a credit to the machine's balance, reconciled nightly. (ii) Bulk/industrial: a cash-center workflow in which a single signed code authorizes the preparation of a 5,000-note cassette for an armored-carrier run; the code binds the cassette serial, the seal numbers, and the receiving branch, and is invalidated by the carrier's custody scan. (iii) Adversarial timing: a code TTL of 15 s at one extreme (contactless vending) and 72 h at the other (a mailed-code scenario for a recipient with no smartphone), with a hard rule that a code may not be both long-lived and unrestricted in value — the platform enforces a monotone trade-off curve value × TTL ≤ constant, published as a parameter table so implementers reproduce the same risk envelope. (iv) Degraded-channel: a 2G SMS-only corridor where the code is a 12-digit numeric token delivered by SMS and validated offline by the machine against a batch of pre-provisioned HMACs.

flowchart TD
  A["Code requested with value V and TTL"] --> B{"V times TTL within published envelope"}
  B -->|No| C["Reject and request step up or lower value"]
  B -->|Yes| D{"Channel quality"}
  D -->|Broadband| E["Signed 2D code with nonce"]
  D -->|2G SMS only| F["12 digit HMAC token from preprovisioned batch"]
  E --> G["Machine validates signature and nullifier"]
  F --> G
  G --> H{"Value class"}
  H -->|Micro| I["Immediate payout or machine credit"]
  H -->|Bulk| J["Bind cassette serial and seal numbers"]
  J --> K["Custody scan invalidates code"]

---

DD-21 — Cross-domain dispensation of non-cash value (Axis 3: cross-domain application)

Enabling description. (a) Aerospace: a code presented at an airport crew-services kiosk releases per-diem cash to a crew member at a destination station, binding the crew badge number, the flight number and the layover window, so the dispensation expires if the flight is rerouted. (b) AgTech: during harvest, a code presented at a cooperative kiosk pays seasonal workers in cash against a signed piece-rate record uploaded by the field supervisor; the kiosk writes the payout back to the cooperative's payroll ledger and prints a receipt coupon for the worker. (c) Consumer electronics: an electronics trade-in kiosk performs device valuation, then dispenses cash or issues a credential to a marketplace, using the same one-time code path; the kiosk also performs a factory-reset attestation before paying, which prevents paying for a device that is still account-locked. In each case the machine family changes; the code lifecycle (issue, nullify, dispense, confirm, cancel-order) is identical.

flowchart LR
  subgraph A["Aerospace crew per diem"]
    A1["Crew badge and flight binding"] --> A2["Kiosk dispenses cash"]
    A2 --> A3["Expiry tied to layover window"]
  end
  subgraph B["AgTech harvest payout"]
    B1["Piece rate record from supervisor"] --> B2["Cooperative kiosk pays worker"]
    B2 --> B3["Payroll ledger and printed coupon"]
  end
  subgraph C["Consumer trade in"]
    C1["Kiosk valuation of device"] --> C2["Factory reset and account lock attestation"]
    C2 --> C3["Cash dispense or marketplace credential"]
  end
  A2 --> L["Common code lifecycle"]
  B2 --> L
  C3 --> L

---

DD-22 — Fraud-scoring, machine telemetry, and distributed settlement (Axis 4: emerging-tech integration)

Enabling description. (i) AI anomaly detection: the dispensation authorization service scores each request with a gradient-boosted model over features including code age, geo-velocity between issuance and redemption, machine ID reputation, historical dispense size distribution for that machine, and the entropy of the presenting device's sensor fingerprint; the score gates the trade-off envelope of DD-20 (a high score shortens TTL and lowers the maximum value). Model cards and feature definitions are published so the behaviour is reproducible. (ii) IoT machine telemetry: each machine publishes cassette levels, note-validator error rates, door-open events and a tamper-seal status over a signed MQTT topic; an empty-cassette prediction model defers low-priority dispensations to nearby machines so that a user is not handed a code that cannot be honoured. (iii) Distributed settlement: each successful dispense emits a signed receipt (machine key + code nonce + dispensed denominations) that is written to an append-only log and used by the settlement layer to net interbank obligations; the receipt's Merkle root is notarized on a permissioned chain so an auditor can prove that a specific code was dispensed once.

sequenceDiagram
  participant U as User device
  participant A as Authorization service
  participant ML as Fraud scoring model
  participant M as Machine with signed telemetry
  participant L as Append only settlement log
  U->>A: present code with nonce and device fingerprint
  A->>ML: score request features
  ML-->>A: risk score and adjusted envelope
  A->>M: authorize dispense with adjusted TTL and value
  M->>M: validate signature and check cassette level
  M-->>U: dispense denominations
  M->>L: signed receipt with nonce and denominations
  L->>L: notarize Merkle root to permissioned chain

---

DD-23 — Safe-mode machines, offline vaults, and cancellation waterfalls (Axis 5: inverse/failure mode)

Enabling description. (i) Offline dispense vault: a machine disconnected from the network validates codes against a pre-provisioned batch of one-time HMAC values (each with an embedded ceiling and expiry) and issues a signed provisional receipt; on reconnect, batches are reconciled and any code presented twice is detected because the batch's usage bitmap is uploaded before new batches are issued. (ii) Cancellation waterfall: when a dispense fails (note jam, abort by the user, or expiry), the machine issues a cancel-order record; the order is routed payor-side first (reservation release), then machine-side (code nullification), then network-side (reversal of any interbank posting) as an ordered waterfall, guaranteeing that value is never simultaneously held by both the payor's reservation and the machine's escrow. (iii) Duress/hostage mode at the machine: a designated duress PIN or duress code path dispenses a reduced amount, photographs the transaction under the machine's existing camera policy, and silently signals a monitoring center — providing a safe failure path for a coerced withdrawal. (iv) Limited-functionality mode: with the note validator out of service, the machine degrades to issuing a claim coupon redeemable at a staffed window, rather than failing the user outright.

stateDiagram-v2
  [*] --> Validate
  Validate --> Dispense : code valid and cassette available
  Validate --> ClaimCoupon : validator out of service
  Dispense --> Confirm : notes presented to user
  Dispense --> CancelWaterfall : jam or user abort
  Confirm --> Settled : signed receipt recorded
  Confirm --> CancelWaterfall : confirmation not received in window
  CancelWaterfall --> PayorRelease : release reservation
  PayorRelease --> MachineNullify : nullify code at machine
  MachineNullify --> NetworkReversal : reverse interbank posting
  NetworkReversal --> Settled
  Validate --> Duress : duress code detected
  Duress --> ReducedDispense : small amount plus silent alert
  ReducedDispense --> Settled
  ClaimCoupon --> Settled : redemption at staffed window

---

DD-24 — The dispensing machine as an enrollment and identity-issuance point (Axis 6: extension)

Enabling description. A non-bank user with no account and no smartphone receives a minted identity at the machine. Flow: the user presents a government identity document whose machine-readable zone or NFC chip is read (ICAO 9303 MRZ or an NFC e-passport read with passive authentication); the machine captures a live portrait and performs liveness and face-match locally; it then issues a disposable credential to a printed thermal receipt bearing a one-time code, and simultaneously writes a template commitment into a hosted wallet. To move value later, the user presents the receipt code at any machine: the machine re-captures the portrait, re-matches against the commitment, and releases funds without the user ever holding a smartphone. Anti-fraud controls disclosed: a spend velocity cap per identity document number, cross-machine linkage of the document's MRZ hash, a check against a document-loss list, and a mandatory second-factor (a printed OTP card) for withdrawals above a ceiling.

flowchart TD
  A["User with no smartphone at machine"] --> B["Read MRZ or NFC e passport with passive authentication"]
  B --> C["Live portrait capture and liveness check"]
  C --> D{"Face matches document and document not flagged lost"}
  D -->|No| E["Refuse and log attempt"]
  D -->|Yes| F["Create template commitment in hosted wallet"]
  F --> G["Print receipt with one time code and OTP card"]
  G --> H["Later visit re captures portrait and rematches"]
  H --> I{"Within velocity cap and second factor present"}
  I -->|Yes| J["Release funds"]
  I -->|No| K["Hold for manual review"]

---

ANCHOR A5 — Commodity-backed multi-denomination tender

---

DD-25 — Substituted backing assets, custody forms, and cryptographic carriers (Axis 1: material/component substitution)

Enabling description. The commodity-backed unit's backing is generalized from a single metal to a defined basket with per-basket weightings, and the form of custody becomes a first-class substitution axis. Backing assets enabled: allocated LBMA Good Delivery bars; vaulted silver, platinum and palladium; copper cathode and lithium carbonate for industrial demand; tokenized energy measured in MWh at a named grid node; verified agricultural warehouse receipts (see DD-9/DD-15); and verified carbon-removal credits. Custody forms: (a) allocated — bars are serialized and the holder's claim names the specific bar numbers (highest assurance, higher storage fee); (b) unallocated pool — a fungible claim with quarterly attestation; (c) synthetic/derivative — a total-return swap referencing the spot price, used where physical import is restricted. Cryptographic carriers: an account-based ledger entry in a permissioned chain; a UTXO-style bearer token in a privacy-preserving chain; and a non-tokenized attestation-plus-note form where the value is a signed credit note verified by the issuer's public key — included so that a platform can operate without a public chain at all.

erDiagram
  BASKET ||--o{ BASKET_LEG : contains
  BASKET_LEG ||--|| ASSET : references
  ASSET ||--o{ CUSTODY_FORM : may_hold
  CUSTODY_FORM ||--o{ BAR_OR_LOT : identifies
  HOLDER ||--o{ CLAIM : owns
  CLAIM ||--|| BASKET : denominated_in
  CLAIM ||--o{ CARRIER : represented_by
  BASKET {
    string basket_id PK
    string unit_symbol
    int rebalance_epoch_days
  }
  BASKET_LEG {
    string leg_id PK
    float weight_bps
  }
  ASSET {
    string asset_id PK
    string assay_standard
    float fineness
  }
  CUSTODY_FORM {
    string custody_id PK
    string mode
    string vault_code
  }
  CLAIM {
    string claim_id PK
    float units
    string holder_pubkey
  }
  CARRIER {
    string carrier_id PK
    string type
    string chain_or_issuer
  }

---

DD-26 — Nanogram fractions to industrial tonnage, and millisecond price feeds (Axis 2: operational parameter expansion)

Enabling description. The unit is definable at both extremes. Nanogram regime: the ledger stores balances as integers in units of 10⁻⁹ gram with an explicit scale field; a single vending-machine purchase may debit 3.4 × 10⁻⁵ g of gold, which is only economic because settlement is netted per merchant and the physical leg is not moved. Redemption minimums are therefore expressed as redemption lots, not balances. Industrial regime: a refinery or smelter settles a 20-tonne shipment by transferring 10⁶ units against a bill of lading, with the transfer conditional on a verified assay certificate and a weighbridge record. Parameter extremes: quote refresh at 100 ms with a stale-quote guard (quotes older than 1,500 ms are rejected for large trades); settlement finality targeted at T+0 for intra-platform transfers and T+2 for physical delivery; a per-transaction spread floor to prevent dust attacks; and a storage-fee accrual computed per gram-day with an explicit formula published so that fee schedules are reproducible.

flowchart TD
  A["Ledger stores integer units at 1e-9 gram"] --> B{"Transaction size class"}
  B -->|Micro| C["Debit fractional grams and net per merchant"]
  B -->|Mid| D["Normal settlement with spread floor"]
  B -->|Industrial| E["Transfer against assay and weighbridge conditions"]
  C --> F["Redemption lot accounting not physical movement"]
  D --> G{"Quote age under stale guard"}
  G -->|No| H["Reject and requote"]
  G -->|Yes| I["Execute at quoted price"]
  E --> I
  I --> J["Accrue storage fee per gram day"]
  J --> K["Publish fee and spread formulas"]

---

DD-27 — Cross-domain commodity-finance deployments (Axis 3: cross-domain application)

Enabling description. (a) Aerospace: an airline treasury holds a sustainable-aviation-fuel claim in MWh-equivalent tokens at named airport nodes; a flight's fuel uplift is debited against the claim, and the corresponding Scope-1 emissions attribute is retired in the same transaction, so the token carries both a physical and a reporting function. (b) AgTech: a farmer delivers grain; the elevator mints a warehouse receipt token against a scale ticket and a quality assay; the farmer may (i) hold it, (ii) pledge it as collateral for input financing (see A6/DD-36), or (iii) transfer it to a buyer; the token's terms encode storage charges, grade, and the delivery location. (c) Consumer electronics: a trade-in program issues a commodity-linked credit — the device's recovered-material estimate (gold, copper, cobalt mass) is priced and credited to the customer's wallet in units of the basket, giving the customer exposure to the underlying metal price between valuation and payout.

flowchart TD
  subgraph A["Aerospace fuel and emissions"]
    A1["SAF claim in MWh units at node"] --> A2["Debit on fuel uplift"]
    A2 --> A3["Retire same-mass emissions attribute"]
  end
  subgraph B["AgTech warehouse receipts"]
    B1["Scale ticket and quality assay"] --> B2["Mint warehouse receipt token"]
    B2 --> B3["Hold pledge or transfer"]
  end
  subgraph C["Consumer trade in material credit"]
    C1["Recovered material mass estimate"] --> C2["Price in basket units"]
    C2 --> C3["Credit customer wallet"]
  end
  A3 --> L["Common basket ledger"]
  B3 --> L
  C3 --> L

---

DD-28 — AI oracles, IoT custody telemetry, and proof-of-reserve (Axis 4: emerging-tech integration)

Enabling description. (i) AI oracle governance: the price and assay inputs come from a multi-source oracle; each feed is scored for latency, deviation from a robust median (Huber M-estimator), and historical revision count; a feed whose score falls below threshold is excluded and the composite is computed from the remaining feeds with weights proportional to score. A supervised changepoint detector flags structural breaks (a new assay standard, a market halt) and freezes new mints rather than continuing on a stale model. (ii) IoT custody telemetry: vault load cells, bar-counter cells, seal continuity sensors and door contacts publish signed MQTT readings; the reserve attestor compares the aggregate measured mass against ledger liabilities with a tolerance band, and a divergence beyond the band triggers the freeze of DD-29. (iii) Blockchain proof-of-reserve: an auditor signs a Merkle root over bar serials and weights; the root plus the audit report hash is committed on-chain; holders can request Merkle proofs that their claim is covered without revealing other holders' positions. A ZK-SNARK proves total liabilities ≤ total attested reserves without disclosing individual balances, enabling public solvency verification while preserving privacy.

sequenceDiagram
  participant FEED as Price and assay feeds
  participant ORA as Oracle scoring and composite
  participant VAULT as Vault IoT sensors
  participant ATT as Reserve attestor
  participant CH as Settlement chain
  FEED->>ORA: submit quotes with timestamps
  ORA->>ORA: exclude low scoring feeds and compute weighted median
  VAULT->>ATT: signed mass and seal telemetry
  ATT->>ATT: compare measured mass to ledger liabilities
  ATT->>CH: commit Merkle root of attested bars
  ORA->>CH: publish composite price with feed scores
  CH-->>ATT: confirm commitment
  ATT-->>CH: publish ZK proof of coverage

---

DD-29 — Freeze, circuit-breaker, and orderly-wind-down modes (Axis 5: inverse/failure mode)

Enabling description. Four inverse modes are enabled. (i) Oracle-divergence circuit breaker: if the composite price deviates from the trailing median by more than a configured band, mints and physical redemptions halt automatically while intra-platform transfers between holders continue at the last good price, preserving liquidity without creating an arbitrage against the vault. (ii) Fractional-reserve detector: a continuous ratio (attested grams / outstanding grams) is computed; below 1.00 a redeemability reservation is activated in which each claim's redemption right becomes pro-rata queue position rather than a first-come entitlement — a deliberate design to prevent a run that disadvantages later redeemers. (iii) Custody failure mode: a vault operator default triggers a claim migration to an alternate custodian under a pre-agreed custody-transfer agreement encoded as a state machine with defined deadlines; unexecuted steps escalate to an arbitration notice. (iv) Limited-functionality/bearer mode: with no connectivity, the wallet can display a signed value certificate with a capped face value for manual acceptance between parties, and the backed units move only after the certificate is posted.

stateDiagram-v2
  [*] --> Normal
  Normal --> Frozen : oracle deviation beyond band
  Frozen --> Normal : deviation resolves
  Normal --> RedeemabilityQueue : coverage ratio below 1.00
  RedeemabilityQueue --> Normal : reserves restored or pro rata wind down
  Normal --> CustodyMigration : custodian default detected
  CustodyMigration --> Normal : alternate custodian accepts
  CustodyMigration --> Arbitration : migration deadline missed
  Normal --> BearerOffline : connectivity lost
  BearerOffline --> Normal : certificate posted after reconnect

---

DD-30 — Dual-quote conversion and multi-jurisdiction basket rebalancing (Axis 6: extension)

Enabling description. Every wallet exposes a dual quote: a cash quote and a commodity-unit quote. A payment request specifies which quote is used (the merchant may price in fiat while the payer's funds are held in units), and the conversion is executed at the instant of authorization with a disclosed spread that is a function of size and of the instrument's estimated cost of hedging (published as a formula). A conversion audit record stores the quote, the source composite, the spread, and the slippage. Rebalancing: a basket has a target weighting per leg and rebalances at a fixed epoch (default quarterly) if any leg drifts beyond ±200 basis points; rebalancing is executed as internal netting first (holders' claims are re-denominated) and only the residual imbalance is traded externally, which minimizes transaction costs. Jurisdictional adaptivity: baskets can be defined per jurisdiction (for example, a basket weighted to a region's principal export commodity) and the platform enforces local regulatory limits such as maximum holding concentration, with automatic redemption-to-fiat when a limit is reached.

flowchart TD
  A["Payment request priced in fiat or units"] --> B["Generate dual quote cash and unit"]
  B --> C["Compute spread from size and hedge cost formula"]
  C --> D["User selects quote"]
  D --> E["Execute conversion at authorization instant"]
  E --> F["Write audit record quote spread slippage"]
  G["Basket epoch trigger"] --> H{"Any leg drift beyond 200 bps"}
  H -->|No| I["No rebalance"]
  H -->|Yes| J["Internal netting re-denominates claims"]
  J --> K["Trade residual imbalance externally"]
  K --> L["Enforce jurisdictional concentration limits"]
  L --> M["Auto redeem to fiat above limit"]

---

ANCHOR A6 — Coupon, points, and geo-advertising engine bound to a wallet

---

DD-31 — Substituted positioning technology and coupon carriers (Axis 1: material/component substitution)

Enabling description. The location-aware offer engine is decoupled from GNSS. Positioning substitutions disclosed: RTK-corrected GNSS (2 cm), UWB anchors in a store (10 cm), BLE angle-of-arrival with an array antenna (30–50 cm), Wi-Fi RTT ranging per IEEE 802.11mc (1–2 m), cellular OTDOA (10–30 m), NFC shelf tags at the point of decision (contact), visual localization against a pre-surveyed shelf map (5–20 cm), and a lightweight inertial dead-reckoning fallback (5% of distance travelled). Offer-carrier substitutions: a printed chipless RFID label whose resonant signature encodes a campaign ID; an e-ink shelf label that rewrites its displayed price and embeds an NFC tap target; a photonic watermark printed over a paper coupon that is read by the phone camera and validated server-side; and a QR code carrying a signed, holder-bound offer. The offer object model is invariant: {campaign_id, sku_scope, discount_type, value, conditions[], valid_window, geo_scope, redemption_limit, holder_binding}.

flowchart LR
  subgraph LOC["Positioning technologies"]
    L1["RTK GNSS"]
    L2["UWB anchor"]
    L3["BLE angle of arrival"]
    L4["WiFi round trip time"]
    L5["Visual shelf localization"]
  end
  subgraph CAR["Offer carriers"]
    C1["Chipless RFID label"]
    C2["E ink shelf label with NFC"]
    C3["Photonic watermark coupon"]
    C4["Signed holder bound QR"]
  end
  L1 --> G["Geo context resolver"]
  L2 --> G
  L3 --> G
  L4 --> G
  L5 --> G
  C1 --> O["Invariant offer object model"]
  C2 --> O
  C3 --> O
  C4 --> O
  G --> O
  O --> R["Ranking and redemption service"]

---

DD-32 — Planet-scale inventory to millisecond auctions and battery-less tags (Axis 2: operational parameter expansion)

Enabling description. Operating points: (i) planet scale — a catalogue of 10⁸ active offers partitioned by geohash prefix and by SKU taxonomy; index shards are replicated per region and refreshed by change-data-capture; a query fans out to the three nearest shards only. (ii) Auction latency — the offer ranking runs a first-price or second-price auction with a hard 10 ms budget at the edge; the auctioneer's reserve price, pacing multipliers and quality scores are published in a reproducible model card so the allocation is auditable. (iii) Battery-less tags — the shelf label harvests energy from the reader's carrier at 13.56 MHz or from ambient photovoltaic cells and wakes only to answer a query, with a 400 ms total energy budget. (iv) Harsh environments — operation in a freezer aisle (−25 °C, condensation) and in a mine (no GNSS) where the platform falls back to UWB or to a fixed beacon topology; in both cases the offer engine is required to declare a positioning confidence and to downgrade the offer's value when confidence falls below the campaign's threshold (a "confidence-capped discount").

flowchart TD
  A["Offer query with position and SKU context"] --> B{"Positioning confidence class"}
  B -->|High| C["Full discount value eligible"]
  B -->|Medium| D["Confidence capped discount"]
  B -->|Low| E["Category level generic offer only"]
  C --> F["Edge auction with 10 ms budget"]
  D --> F
  E --> F
  F --> G["Pacing and quality score applied"]
  G --> H["Winning offer returned to device"]
  H --> I["Redemption recorded with positioning provenance"]
  J["Battery less shelf tag"] --> H

---

DD-33 — Cross-domain offer engines (Axis 3: cross-domain application)

Enabling description. (a) Aerospace: a maintenance, repair and overhaul marketplace publishes availability and rebates for rotables and shop slots; a technician's tablet receives offers scoped to the tail number and the open work order, and redemption is bound to the release-to-service event so the discount cannot be claimed without actually installing the part. (b) AgTech: input rebates (seed, fertilizer, crop protection) are issued by the silo or cooperative at the moment of grain delivery, computed against the delivered tonnage and grade; the rebate is a wallet credit tied to a future input purchase, which closes a working-capital loop. (c) Consumer electronics: a firmware-over-the-air entitlement coupon is pushed to devices whose diagnostic telemetry indicates an imminent wear-out part; redemption occurs at a service kiosk or via a parts order, and the campaign triggers only when a signed device diagnostic exceeds a threshold, so the offer is demand-driven rather than broadcast.

flowchart TD
  subgraph A["Aerospace MRO rebates"]
    A1["Tail number and open work order context"] --> A2["Offers for rotables and shop slots"]
    A2 --> A3["Redemption bound to release to service"]
  end
  subgraph B["AgTech input rebates"]
    B1["Delivered tonnage and grade"] --> B2["Rebate credit at silo"]
    B2 --> B3["Spendable on next input purchase"]
  end
  subgraph C["Consumer device wear out offer"]
    C1["Signed device diagnostic telemetry"] --> C2{"Wear out threshold exceeded"}
    C2 -->|Yes| C3["Push entitlement coupon"]
    C3 --> C4["Redeem at kiosk or parts order"]
  end
  A3 --> W["Wallet credit ledger"]
  B3 --> W
  C4 --> W

---

DD-34 — Contextual-bandit ranking, smart-cart telemetry, and on-chain coupon provenance (Axis 4: emerging-tech integration)

Enabling description. (i) AI ranking: offer selection is formulated as a contextual bandit with a LinUCB or Thompson-sampling policy over context features (geohash cell, time-of-day bucket, basket content hash, historical conversion by category); exploration budget is capped per user per week to avoid nuisance, and the policy's reward definition (conversion, margin after discount, and a nuisance penalty) is published so the objective is reproducible. (ii) IoT: a smart cart or a shelf camera publishes events (cart/enter_aisle, shelf/pick, shelf/return) on an MQTT topic; a pick event without a subsequent checkout within the store session triggers a reminder offer, while a return event suppresses the offer for a cooldown period. (iii) Blockchain provenance: each coupon is minted with a non-fungible identifier and a nullifier; redemption burns the nullifier so parallel redemption across merchants is impossible; transferable coupons (DD-35) record a lineage. Where privacy is required, the coupon is represented as a zero-knowledge presentation: the consumer proves "I hold a valid unredeemed coupon for SKU class X" without revealing the coupon identifier or the holder.

sequenceDiagram
  participant CART as Smart cart IoT
  participant BRK as Event broker
  participant POL as Contextual bandit policy
  participant APP as Consumer app
  participant CH as Coupon contract
  CART->>BRK: publish pick and return events
  BRK->>POL: context plus basket signals
  POL->>POL: select offer with exploration budget
  POL->>APP: propose offer with signed coupon
  APP->>CH: redeem coupon nullifier
  CH->>CH: verify unredeemed and burn nullifier
  CH-->>APP: redemption receipt
  POL->>POL: update reward from conversion signal

---

DD-35 — Privacy-preserving, expiring, and clawback offer modes (Axis 5: inverse/failure mode)

Enabling description. (i) Privacy-preserving degraded mode: when the user denies precise location, the engine operates on a coarse geohash (level 5, ~5 km) with k-anonymity ≥ 200 and on-device differential privacy noise added to any reported statistic; offers are then limited to category-level discounts, so functionality degrades rather than the privacy guarantee. (ii) Expiry and clawback: offers have a validity window and may be clawed back if the underlying condition failed (for example, a rebate tied to a delivery whose grade was later downgraded at assay); the clawback is implemented as a negative ledger entry with an appeal window and a documented evidence trail rather than a silent debit. (iii) Fail-safe when the wallet cannot pay: the remaining-balance calculation after coupon application is performed locally with the coupon's floor price, so a user is never shown "payable in full by coupon" if the tax or fee component would exceed the wallet balance; if the wallet cannot cover the residual, the transaction is converted into a hold with a coupon reservation and a short expiry, avoiding a hard failure at the register. (iv) Nuisance limiter: a hard frequency cap and a per-category cap are enforced in the client, not only server-side, so a compromised server cannot spam the device.

stateDiagram-v2
  [*] --> Issued
  Issued --> Reserved : presented at register
  Reserved --> Redeemed : residual balance paid
  Reserved --> Expired : hold window elapsed
  Reserved --> Released : transaction cancelled
  Redeemed --> Clawback : underlying condition failed at audit
  Clawback --> Appeal : holder contests
  Appeal --> Redeemed : evidence upholds redemption
  Appeal --> WrittenOff : evidence supports clawback
  Issued --> CoarseOnly : precise location denied
  CoarseOnly --> Issued : location permission restored
  Expired --> [*]
  WrittenOff --> [*]

---

DD-36 — Divisible, transferable coupon-credit instruments with allowance governance (Axis 6: extension)

Enabling description. A coupon or allowance is re-cast as a divisible bearer instrument backed by a wallet credit with governance rules — generalizing both the specification's transferable coupons/allowances and its lending automation. Instrument fields: {issuer, denominated_value, spend_scope (merchant category codes), geo_scope, expiry, split_allowed, transfer_allowed, lineage[], guardian_policy}. Splitting is exact: parent value = Σ children; each child inherits scope and shortens expiry. Governance: a guardian (parent account, employer, or cooperative) defines policy such as per-category daily limits, merchant allowlists, and an automatic top-up rule triggered when balance < threshold, and may freeze an instrument with an on-chain tombstone. Settlement: the wallet credit is a claim against a prefunded escrow account, and the escrow reconciliation report proves outstanding instrument value equals escrowed funds, so a transferable coupon cannot be double-issued. Abuse controls: velocity limits per instrument lineage, merchant-side duplicate detection by nullifier, and a maximum transfer depth (default 4) to prevent laundering loops through resale.

flowchart TD
  A["Issuer funds escrow"] --> B["Mint divisible instrument with scope and expiry"]
  B --> C{"Holder action"}
  C -->|Spend| D["Debit against merchant category scope"]
  C -->|Split| E["Create children summing to parent value"]
  C -->|Transfer| F["Append lineage and decrement transfer depth"]
  D --> G["Nullifier checked by merchant"]
  E --> G
  F --> G
  G --> H["Reconciliation report outstanding equals escrow"]
  H --> I{"Guardian policy breach detected"}
  I -->|Yes| J["Freeze instrument and publish tombstone"]
  I -->|No| K["Settle periodically"]
  L["Auto top up when balance below threshold"] --> B

---

3. Combination prior-art scenarios (patent disclosure + open-source/consensus standard)

Each scenario below is written so that the combination itself, not merely the patent or the standard alone, is a complete and enabling disclosure.

---

CPS-1 — Configurable security-level gating ⊕ W3C WebAuthn Level 3 / FIDO2 CTAP 2.1 ⊕ OpenID Connect acr_values ⊕ OAuth 2.0 Rich Authorization Requests

Enabling description. Map the "desired security level configuration setting" (claims 1–10) onto standards-defined step-up authentication. The mobile application's policy register (DD-1) stores a level L; the relying party (the wallet backend) expresses its requirement as an acr_values parameter containing a URN such as urn:paygeo:acr:lvl2. The client resolves the URN against a local policy table into a CTAP 2.1 authenticatorSelection object (userVerification: required, residentKey: preferred, attestation: direct) and a list of acceptable factors. When L > 1, the flow issues sequential WebAuthn ceremonies, one per factor class, chaining them with a single OIDC authorization request whose authorization_details (RAR) declares the transaction amount and payee; each ceremony returns an assertion bound to the same challenge, and the backend verifies that the set of credentialIds used matches the required factor classes. Hardware attestation from the authenticator (FIDO Metadata Service aaguid plus an attestation statement) is verified to prove that the factor was captured on genuine hardware. Failure to satisfy the full set yields acr assertion failure and the wallet remains locked at the feature level.

sequenceDiagram
  participant APP as Mobile wallet app
  participant RP as Relying party backend
  participant WN as WebAuthn client
  participant AU as CTAP 2.1 authenticator
  APP->>RP: authorization request with authorization_details
  RP-->>APP: acr_values urn requiring level 2
  APP->>APP: resolve urn to factor class list
  APP->>WN: create with challenge and authenticatorSelection
  WN->>AU: getAssertion factor class one
  AU-->>WN: assertion with credentialId and attestation
  WN->>AU: getAssertion factor class two bound to same challenge
  AU-->>WN: second assertion
  WN-->>APP: assertion set
  APP->>RP: token request with assertion set
  RP->>RP: verify aaguid attestation and factor class coverage
  RP-->>APP: access token scoped to feature set

---

CPS-2 — Code-mediated cash dispensation ⊕ EMVCo QR ⊕ ISO 8583 / ISO 20022 ⊕ W3C Payment Request API

Enabling description. A consumer-presented code (the "generate scan code" construct) is reconstituted as an EMVCo-compatible payload fragmented into a COSE_Sign1 envelope. The ATL/merchant-presented versus consumer-presented roles are preserved; the code carries {amount_authorized, currency, machine_scope, nonce, exp, payor_cert_thumbprint}. On presentation, the machine's secure module verifies the signature against a pinned trust anchor and performs an offline authorization check (amount ≤ ceiling, nonce unseen in the local replay store, TTL valid), then builds an ISO 8583 authorization request (0200) with the nonce in a private field (DE 127.25) and a partial reversal (0400/0420) emitted when a dispense fails — this is the standard-format expression of the specification's "cancel order instruction." In ISO 20022 contexts, the equivalent messages are pacs.008 for the funding leg and camt.056/camt.029 for the cancellation and resolution. On the client side, the W3C Payment Request API exposes the code generation as a payment handler whose details are populated from the wallet's account list; the user gesture completes the request, and the handler emits the COSE envelope rendered as a QR. Completion (CPS-2 final state) is a machine-signed receipt mapped to a camt.054 credit notification.

flowchart TD
  A["Payment Request API call with details"] --> B["Wallet handler builds COSE_Sign1 envelope"]
  B --> C["Render code with nonce and expiry"]
  C --> D["Machine scanner decodes envelope"]
  D --> E["Secure module verifies signature and TTL"]
  E --> F{"Amount within ceiling and nonce unseen"}
  F -->|No| G["Decline and log"]
  F -->|Yes| H["Build ISO 8583 0200 authorization with nonce in DE 127"]
  H --> I["Dispense notes"]
  I -->|Success| J["Machine signed receipt mapped to camt.054"]
  I -->|Failure| K["Emit 0400 or 0420 reversal and camt.056 cancellation"]
  K --> L["Payor reservation released"]

---

CPS-3 — Commodity-backed unit ⊕ ERC-20 / ERC-3643 ⊕ oracle network ⊕ W3C Verifiable Credentials ⊕ ISO 20022

Enabling description. Each basket unit is implemented as an ERC-3643 permissioned security token (transfer restricted to verified holders) or a plain ERC-20 where no regulatory perimeter applies. Reserve integrity is established by an oracle network that aggregates vault attestations (DD-28) and by an on-chain proof-of-reserve contract exposing reserves(), liabilities() and a coverageRatio() view. Redemption is a two-phase operation: requestRedeem(units) moves units to a pending escrow and emits an ISO 20022 pacs.008-equivalent instruction to the custodian's API; confirmDelivery() burns the escrowed units and mints a camt.054 credit notification. Holder eligibility is proven with a W3C Verifiable Credentials presentation — the holder proves KYC status and jurisdiction without disclosing the underlying data; the token contract only sees a boolean validity flag written by an on-chain registry, consistent with the closed-loop permissioning model of ERC-3643. Rate, spread and fee parameters are read from the same oracle, and a stale-quote guard reverts the transfer if the composite is older than 1.5 s.

classDiagram
  class GoodMoneyToken {
    +string symbol
    +uint8 decimals
    +mapping balances
    +transfer(to, amt) bool
    +requestRedeem(units)
    +confirmDelivery(requestId)
  }
  class ReserveOracle {
    +uint256 lastComposite
    +uint64 updatedAt
    +coverageRatio() int
    +isStale() bool
  }
  class IdentityRegistry {
    +mapping verified
    +bool isVerified(address)
  }
  class CustodianAPI {
    +submitLeg(instruction)
    +acknowledgeReceipt(msgId)
  }
  class VerifiableCredential {
    +string issuer
    +string jurisdiction
    +verifyPresentation() bool
  }
  GoodMoneyToken --> ReserveOracle : reads price and coverage
  GoodMoneyToken --> IdentityRegistry : checks eligibility
  GoodMoneyToken --> CustodianAPI : emits redemption instruction
  VerifiableCredential --> IdentityRegistry : writes validity flag

---

CPS-4 — Geo-aware coupon/points engine ⊕ OpenRTB 2.6 ⊕ schema.org Offer ⊕ Open Location Code / GeoJSON ⊕ IAB TCF v2.2

Enabling description. The "Good Deal" search-and-pull construct is expressed as a standard bid transaction. On offer discovery, the client emits an OpenRTB 2.6 BidRequest whose device.geo carries an Open Location Code (plus optional GeoJSON polygon for a campaign scope), imp carries the placement (map pin view, list view, post-transaction receipt), and user.ext.consent carries the IAB TCF v2.2 consent string; the server responds with a BidResponse whose adm is a schema.org Offer JSON-LD fragment (price, priceCurrency, eligibleQuantity, validFrom, validThrough, availabilityStarts) plus a signed coupon token. Client-side rules of DD-35 apply before rendering: the frequency cap, the category cap, and the confidence-capped discount act as a publisher floor independent of the exchange. Redemption writes back a conversion signal to the exchange for pacing, and the nullifier mechanism of DD-34 prevents the same coupon token from being redeemed at two merchants. The mapping is deliberately loss-free in both directions so that legacy OpenRTB buyers and schema.org-based catalogues interoperate without a proprietary adapter.

flowchart LR
  A["Client builds BidRequest with open location code and consent string"] --> B["Exchange auction"]
  B --> C["BidResponse with schema.org Offer in adm"]
  C --> D["Client enforces frequency and category caps"]
  D --> E{"Positioning confidence above campaign floor"}
  E -->|Yes| F["Render full value offer"]
  E -->|No| G["Render confidence capped offer"]
  F --> H["Redeem coupon token and burn nullifier"]
  G --> H
  H --> I["Emit conversion signal to exchange for pacing"]
  I --> B

---

4. Published claim scaffold for future incremental filings

The following limitations are published as explicit prior-art matter so that a later applicant cannot obtain coverage over them without distinguishing some further element. Each is supported by the derivatives above.

Scaffold A — Gating. "A method wherein the security-level configuration setting is stored in a hardware register selected from a secure element policy object, a TPM NV index, a fused one-time-programmable bitmask, or a remote signed policy token, and wherein a failure to read the register results in a deny-by-default policy." (→ DD-1, DD-6)

Scaffold B — Adaptive level. "A method wherein a required number of security-level factors is computed at runtime from a device-local risk score within a trusted execution environment, and wherein the required number is increased by a fixed increment after a failed attempt." (→ DD-2, DD-4)

Scaffold C — Duress. "A method wherein a first biometric instance authenticates into a shadow account state and a second biometric instance authenticates into a primary account state, and wherein the shadow account state limits value movement to a preset ceiling and transmits a silent alert." (→ DD-5, DD-23)

Scaffold D — Credential. "A method wherein a value credential comprising a signed payload, a single-use nonce, a not-before and not-after time, and a maximum-use count is transferred between devices over a link selected from UWB, BLE angle-of-arrival, data-over-sound, Li-Fi and magnetic emulation, and is redeemed by a nullifier check." (→ DD-13, DD-14, DD-16)

Scaffold E — Dispensation. "A method wherein a dispensing machine verifies an offline signature, applies a monotone trade-off between credential value and credential lifetime, dispenses, and emits a cancel-order record routed to a payor-side reservation release before a machine-side nullification and a network-side reversal." (→ DD-20, DD-23)

Scaffold F — Commodity tender. "A system wherein a claim denominated in units of a defined physical-mass scale is backed by allocated custody, wherein a coverage ratio below one activates pro-rata redemption queueing rather than first-come redemption, and wherein solvency is proven by a zero-knowledge proof over a Merkle root of attested bars." (→ DD-26, DD-28, DD-29)

Scaffold G — Offers. "A system wherein an offer is rendered only at a value reduced in proportion to a declared positioning-confidence class, and wherein redemption burns a nullifier recorded on a distributed ledger." (→ DD-32, DD-34)

Scaffold H — Divisible instruments. "A method wherein a bearer coupon is split into child instruments whose values sum to the parent value and whose expiries are strictly shorter than the parent's, with a maximum transfer depth and a guardian-defined category allowlist." (→ DD-36)

---

5. Publication and enforcement notes

1. Enablement standard. Every disclosure above is written to the § 112(a) standard: a person of ordinary skill can build it from the text alone, given the identifiers and parameter ranges supplied. Where a parameter is a range (e.g., L ∈ [1,64], TTL 15 s–72 h, spread floors, hop depth 4), the range endpoints are the operative disclosure.
2. Diagram fidelity. The Mermaid sources are part of the disclosure text; publish them unrendered so that the control-flow semantics survive any rendering change.
3. Timestamping. Compute a SHA-256 digest of the exact byte sequence of this document including the Mermaid fenced blocks; obtain an RFC 3161 token; mirror to at least three independent archives. Do not amend a published copy — issue a distinct version with a distinct digest.
4. Relationship to the earlier sections of this analysis. Section 0 flags two corrections that must propagate: (a) the IPR2025-01555 petitioner is Samsung Electronics Co., Ltd. and Samsung Electronics America, Inc., not Unified Patents; the institution decision date is 2026-01-27 with a status of Discretionary Denial. (b) The granted claims of US 12,014,347 B2 are claims 1–10 with independents 1 and 6, and are directed to configurable single-versus-plural security-level gating; the earlier "Obviousness" section should be re-run against that claim language rather than against the specification's broader subject matter, and the earlier "Prior art" section's reliance on familial anticipation (US 8,554,671 B2 and US 10,733,593 B2) should be re-examined because a parent application is not § 102(a)(2) art against a continuation claiming the same priority — it is only § 102(f)/derivation-adjacent or § 112 / double-patenting territory, not anticipatory art in the ordinary sense.
5. Combination scenarios as independent art. CPS-1 through CPS-4 are each standalone prior-art disclosures regardless of the ultimate validity of US 12,014,347 B2; publish them even if the patent's claims are later amended or cancelled.