DETAILED ACTION
This office action is in response to applicant’s submission filed on May 7, 2026. Claims 1-9 are pending and rejected.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on May 7, 2026 has been entered.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on May 7, 2026 and May 22, 2026 and have been considered. The submissions are in compliance with the provisions of 37 CFR 1.97. Accordingly, initialed and dated copies of Applicant’s IDS forms 1449 are attached to the instant Office action.
Response to Amendment
This communication is in response to the amendment filed on May 7, 2026. The Examiner has acknowledged the amended claim 1. Claims 1-9 are pending and are rejected.
Response to Arguments
Applicant’s Arguments (Remarks) filed May 7, 2026 have been fully considered, but are moot.
Applicant’s arguments with respect to claim 1 has been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3 and 5-8 are rejected under 35 U.S.C. 103 as being unpatentable over US 2020/0042958 A1 to Soundararajan et al. (hereinafter, “Soundararajan”) in view of US 2020/0193425 A1 to Ferenczi et al. (hereinafter, “Ferenczi”) and in further view of US 10762478 B1 to Maeng.
Regarding claim 1, Soundararajan discloses: A system comprising:
off chain transaction confirmation machines exchanging private transaction messages (“A user of user device 200 is configured to conduct an off-chain transaction with agent system 300 and approve the off-chain transaction ... Receiver 240 and transmitter 250 may be configured to receive or transmit communications from/to agent system 300 ... during a process of creating and approving an off-chain transaction and/or a blockchain transaction including a reference to the offchain transaction” [0062-0070] [Examiner notes that the user device 200 is the off chain transaction confirmation machine and the user device 200 receiving and transmitting communications from/to agent system 300 constitutes exchanging private transaction messages]);
off chain zero-knowledge proof machines in communication with the off chain transaction confirmation machines (“Agent system 300 may be configured to generate an off-chain transaction ID from an off-chain transaction with a user” [0071] [Examiner notes that agent system 300 constitutes off chain proof machines in communication with the off chain transaction confirmation machines]);
off chain bank machines in communication with the off chain An off-chain verifier server system 400 (referred to herein as "off-chain verifier 400") may be configured to conduct digital transactions off-chain. When there is an agent looking to confirm validity of a transaction, it may determine if a transaction associated with transaction ID shared by the agent has succeeded (e.g., sufficient funds available for transaction and transaction approved by user), and it may also trigger a request to the secured identity verifier 500 to confirm if a blockchain identity claimed by the user is valid” [0080] [Examiner notes that off-chain verifier 400 constitutes off chain bank machines in communication with the proof machines, where the off-chain verifier 400 may be a bank]; “the systems may decide if additional validation may be done at the secured identity validator or off-chain validator for checking additional conditions using a smart contract” [0119] [Examiner notes that the smart contract constitutes code associated with the off chain proof machines]);
off chain central bank machines in communication with the off chain bank machines to validate a network transaction and form a private network transaction record and a public network transaction record (“A secured identity verifier server system 500 (referred to herein as "secured identity verifier 500") may be configured to verify blockchain transactions and issue attestations to the blockchain network attesting to verified blockchain transactions ... secured identity verifier server system 500 may be implemented as a server system of a central bank” [0084] [Examiner notes that a secured identify verifier server system 500 is an off chain central bank machines in communication with the off chain bank machines and the identity verifier verifying blockchain transaction and issuing attestations to the blockchain network constitute validating a network transaction and forming a public network transaction record]; “Network interface 530 may be configured to communicate with off-chain verifier 400 and/or blockchain network 700, para 0086; the blockchain transaction record protects the identities of the involved parties as non-permissioned nodes will not be able to understand the random numbers generated by independent bodies or off-chain transaction ID that has no meaning to non-parties to the off-chain transaction” [0086] [Examiner notes that the off-chain transaction constitutes a private network transaction record since only the parties involved can interpret the off-chain transaction, the blockchain transaction constitutes a public network transaction record]); and
on chain bank machines the term "distributed ledger" generally refers to a shared digital ledger that is decentralized and shared between nodes distributed across a network. After a transaction that is approved to be written to the ledger is consented by at least the majority of the nodes, the contents of the ledger are synchronized across all the nodes” [0028] [Examiner notes that the nodes of a distributed ledger that write a transaction to the ledger constitutes on chain bank machines]; “at step 904, agent system 300 writes a first block transaction Tx-Bl to blockchain 800” [0101] [Examiner notes that the agent system writing a block transaction to the blockchain shows that the blockchain transaction is added by the blockchain network nodes])
where the on chain central bank machines monitor all private transactions by the on chain bank machines (“A secured identity verifier server system 500 (referred to herein as "secured identity verifier 500") may be configured to verify blockchain transactions and issue attestations to the blockchain network attesting to verified blockchain transactions ... secured identity verifier server system 500 may be implemented as a server system of a central bank” [0084]) and
Soundararajan does not explicitly disclose: off chain zero knowledge proof machines; off chain bank machines in communication with the off chain zero knowledge proof machines via proprietary code associated with the off chain zero knowledge proof machines; and on chain central bank machines, where the on chain bank machines and on chain central bank machines establish an on chain smart contract pool to store private data accessible by the off chain zero knowledge proof machines, where the on chain smart contract pool orchestrates a pool hierarchy to meet legal requirements, and where the on chain smart contract pool keeps token account balances, where the on chain smart contract pool specifies an orchestration structure and maintain private balances and transactions of tokenized deposits by the on chain bank machines.
However, Ferenczi discloses: off chain zero knowledge proof machines (“An issuer system may establish the zero-knowledge proof algorithm and may allow merchants and customers to register with the issuer system to enroll in zero-knowledge proof payments” [0014] [Examiner notes that the issuer system establishing the zero-knowledge proof algorithm constitutes off chain zero knowledge proof machines]);
off chain bank machines in communication with the zero knowledge proof machines via proprietary code associated with the off chain zero knowledge proof machines (“A smart contract may be used to control end-to-end data flow during the zero-knowledge proof payment process” [0014]; “Issuer system 130 may also include one or more blockchain nodes, application programming interfaces (APIs), software development kits (SDKs), or the like configured to allow issuer system 130 to interact with blockchain network 140, retrieve and write data to the blockchain, and deploy one or more ZKP smart contracts 145” [0028]; “Issuer system 130 authorizes merchant system 120 to invoke ZKP smart contract 145 (Step 312)” [0046] [Examiner notes the issuer system authorizing the merchant system to invoke the ZKP smart contract constitutes an off chain bank machine in communication with the zero knowledge proof machine via proprietary code associated with the off chain zero knowledge proof machines where the proprietary code is the smart contract]); and
on chain central bank machines (“Blockchain network 140 may be in electronic communication with issuer system 130 via one or more blockchain nodes” [0020] [Examiner notes that the blockchain nodes constitutes on chain central bank machines]).
where the on chain bank machines and on chain central bank machines establish an on chain smart contract pool to store private data accessible by the off chain zero knowledge proof machines, where the on chain smart contract pool orchestrates a pool hierarchy to meet legal requirements, and where the on chain smart contract pool keeps token account balances (“For example, and in accordance with various embodiments, ZKP smart contract 145 determines the account balance of customer 115 (Step 516). For example, ZKP smart contract 145 may query the blockchain based on the customer hash to determine the customer account balance associated with the customer hash. ZKP smart contract 145 may compare the customer account balance with the purchase amount to determine whether customer 115 has sufficient funds to complete the zero-knowledge proof transaction. In response to determining that customer 115 has insufficient funds to complete the purchase, ZKP smart contract 145 may return an insufficient funds notification to merchant system 120. In response to determining that customer 115 has sufficient funds to complete the purchase, ZKP smart contract 145 adjusts the account balance of customer 115 (Step 518) based on the purchase amount. For example, ZKP smart contract 145 may adjust the customer account balance by decreasing the account balance by an amount equal to the purchase amount. ZKP smart contract 145 adjusts the account balance of merchant 125 (Step 520) based on the purchase amount. ZKP smart contract 145 may query the blockchain based on the merchant hash to locate the merchant account balance associated with the merchant hash. ZKP smart contract 145 may adjust the merchant account balance by increasing the account balance by the purchase amount, minus any applicable transaction fees” [0057]; “In various embodiments, blockchain network 101 may host and/or implement one or more smart contracts. The smart contracts may control the end-to-end data flow in system 100 and may autonomously govern the payment process by supporting execution and recording of various transaction data. For example, and in accordance with various embodiments, blockchain network 140 may host one or more zero-knowledge proof (ZKP) smart contracts 145. ZKP smart contract 145 may comprise executables that write data to a blockchain in a predetermined format based on predetermined function parameters passed by an API call or the like, as discussed further herein. ZKP smart contract 145 may include a program written in a programming language such as, for example, Solidity, or any other suitable smart contract programming language” [0023] [Examiner notes that the customer hash and balances are stored on the blockchain and the ZKP smart contracts uses that data to verify a transaction (showing ZKP-based processing using stored data). It also adjusts and queries customer and merchant account balances which maintains account balance data and enforcing transaction rules within an on-chain contract system. Examiner also notes that the description of smart contracts managing execution and recording of transactions indicates access and operations can be controlled according to organizational policies or predetermined criteria]),
where the on chain smart contract pool specifies an orchestration structure (“In various embodiments, blockchain network 101 may host and/or implement one or more smart contracts. The smart contracts may control the end-to-end data flow in system 100 and may autonomously govern the payment process by supporting execution and recording of various transaction data. For example, and in accordance with various embodiments, blockchain network 140 may host one or more zero-knowledge proof (ZKP) smart contracts 145. ZKP smart contract 145 may comprise executables that write data to a blockchain in a predetermined format based on predetermined function parameters passed by an API call or the like, as discussed further herein. ZKP smart contract 145 may include a program written in a programming language such as, for example, Solidity, or any other suitable smart contract programming language” [0023])
maintain private balances and transactions of tokenized deposits by the on chain bank machines (“For example, and in accordance with various embodiments, ZKP smart contract 145 determines the account balance of customer 115 (Step 516). For example, ZKP smart contract 145 may query the blockchain based on the customer hash to determine the customer account balance associated with the customer hash. ZKP smart contract 145 may compare the customer account balance with the purchase amount to determine whether customer 115 has sufficient funds to complete the zero-knowledge proof transaction. In response to determining that customer 115 has insufficient funds to complete the purchase, ZKP smart contract 145 may return an insufficient funds notification to merchant system 120. In response to determining that customer 115 has sufficient funds to complete the purchase, ZKP smart contract 145 adjusts the account balance of customer 115 (Step 518) based on the purchase amount. For example, ZKP smart contract 145 may adjust the customer account balance by decreasing the account balance by an amount equal to the purchase amount. ZKP smart contract 145 adjusts the account balance of merchant 125 (Step 520) based on the purchase amount. ZKP smart contract 145 may query the blockchain based on the merchant hash to locate the merchant account balance associated with the merchant hash. ZKP smart contract 145 may adjust the merchant account balance by increasing the account balance by the purchase amount, minus any applicable transaction fees” [0057]).
It would have been obvious to one of ordinary skill in the art before the priority date to modify Soundararajan with the zero knowledge proof payments of Ferenczi for the purpose of providing a zero-knowledge proof payment system that may be used to complete transactions between a customer and a merchant without the customer needing to expose sensitive data, including transaction account data ... The algorithm enables the customer to prove knowledge or possession of certain information (e.g., the transaction account data), and the merchant to verify knowledge or possession of the information, without the actual information needing to be disclosed or exchanged between the parties (see Ferenczi, para 0014).
A combination of Soundararajan-Ferenczi do not disclose: where the on chain central bank machines maintain a Central Bank Digital Currency and
However, Maeng disclose: where the on chain central bank machines maintain a Central Bank Digital Currency (“At 302, the FI system may receive from a mobile wallet (e.g., a mobile wallet or card within a mobile wallet) a request for depositing an amount of the private e-currency. The FI system may register the mobile wallet as part of its network, as discussed above. The private e-currency may be a digital currency that is managed using a blockchain, guaranteed by the financial institution to be convertible into a government-backed currency and only available for transactions with members of the network. The financial institution may hold government-backed currency assets in reserves in an amount dependent upon the total amount of private e-currency issued by the financial institution. The deposit request may include payment credentials for a financial account to debit for paying for the private e-currency” [Col 5, lines 53-67] [Examiner notes that this text shows a central authority-controlled blockchain system that issues, maintains, and manages a digital currency with ledger-based balances and government-backed convertibility, corresponding to a CBDC maintained by on-chain central bank machines]) and
It would have been obvious to one of ordinary skill in the art before the priority date to modify Soundararajan-Ferenczi’s central banking authority framework with the added blockchain-based digital currency system structure of Maeng for the purpose of allowing the central banking authority to implement/operate a digital currency system using the blockchain-based currency management techniques.
Regarding Claim 2, a combination of Soundararajan-Ferenczi-Maeng discloses the system of claim 1.
Soundararajan further discloses: wherein the private network transaction record is available to the off chain bank machines and off chain central bank machines (“An off-chain verifier server system 400 (referred to herein as "off-chain verifier 400") may be configured to conduct digital transactions off-chain. When there is an agent looking to confirm validity of a transaction, it may determine if a transaction associated with transaction ID shared by the agent has succeeded (e.g., sufficient funds available for transaction and transaction approved by user), and it may also trigger a request to the secured identity verifier 500 to confirm if a blockchain identity claimed by the user is valid” [0080] [Examiner notes the off-chain verifier server system 400 verifying the off-chain transaction using the transaction ID constitutes the private network transaction record being available to the off chain bank machines]; “At operation 1310, secured identity verifier 500 receives a request from off-chain verifier 400 to verify first and second blockchain transactions ... The first blockchain transaction may include the offchain transaction ID” [0117] [Examiner notes that the secured identify verifier 500 verifying the first blockchain transaction which includes the off-chain transaction ID constitutes the private network transaction record being available to the off chain central bank machines]).
Regarding Claim 3, a combination of Soundararajan-Ferenczi-Maeng discloses the system of claim 1.
Soundararajan does not disclose: wherein the on chain bank machines and on chain central bank machines administer a smart contract associated with the network transaction.
However, Ferenczi discloses: wherein the on chain bank machines and on chain central bank machines administer a smart contract associated with the network transaction (“Blockchain network 140 may also be accessible by merchant system 120 in response to merchant system 120 invoking a smart contract (e.g., zero-knowledge proof smart contract 145)” [0021] [Examiner notes that the blockchain network 140 being accessible by the merchant system 120 in response to the invocation of a ZKP smart contract constitutes administering a smart contract associated with the network transaction]).
It would have been obvious to one of ordinary skill in the art before the priority date to modify Soundararajan with the smart contract administering of Ferenczi for the purpose of controlling end-to-end data flow during the zero-knowledge proof payment process, and to update customer account balances and merchant account balances, in response to a successful authorization and/or transaction (see Ferenczi, para 0015).
Regarding Claim 5, a combination of Soundararajan-Ferenczi-Maeng discloses the system of claim 1.
Soundararajan further discloses: wherein the (“to confirm the distributed identity of a user, the bank may check with a secured identity validator ( e.g., central bank). This validation based on TOTAs of the user may provide a secondary validation of a transaction and prevent any spoofing or card theft or identity theft based spurious transactions” [0080]; “when executed by a processing device 420, cause off-chain verifier 400 to issue payment to an agent from funds after attestation by secured identity verifier 500. This may provide for secondary verification of a transaction and faster settlement” [0082] [Examiner notes that the settlement of a transaction based on validation of identify from the central bank and verification of the bank to issue payment constitutes negotiated data received from a first and second off chain bank machine]).
Soundararajan does not disclose: wherein the off chain zero knowledge proof machines generate a commitment and proof from negotiated data.
However, Ferenczi discloses: wherein the off chain zero knowledge proof machines generate a commitment and proof from negotiated data (“Customer 115 shops at merchant 125 (Step 502). For example, customer 115 may shop at merchant 125 by visiting a brick and mortar store associated with merchant 125, by visiting an online store via customer device 110, or the like. In response to customer 115 desiring to purchase one or more goods and/or services, customer 115 initiates a transaction with merchant 125 (Step 504). For example, merchant 125 (and/or merchant system 120) may prompt customer 115 (and/or customer device 110) to select a payment method. Customer 115 may select a zero-knowledge proof payment method to initiate the transaction… customer device 110 generates a purchase hash (Step 506)… Customer device 110 generates a proof (Step 508) using the proof function from the zero-knowledge proof algorithm. The proof may be generated to comprise a binary large object (BLOB) file. Customer device 110 may input the proving key pk, the customer hash, and the purchase hash into the proof function to generate the proof. Customer device 110 transmits the proof and the customer hash to merchant system 120 (Step 510). In response to receiving the proof and the customer hash, merchant system 120 invokes ZKP smart contract 145 (Step 512) by passing the proof, the customer hash, the purchase amount, the verification key vk, and the merchant hash. In response to being invoked, ZKP smart contract 145 executes the validate function (Step 514) from the zero-knowledge proof algorithm” [0053-0056] [Examiner notes that the customer generating the proof using the zero-knowledge proof algorithm and the transaction hash and the merchant invoking the ZKP smart contract using the proof and the purchase amount constitutes off chain zero knowledge machines generating a commitment and proof from negotiated data where the negotiated data is the data associated with the transaction]).
It would have been obvious to one of ordinary skill in the art before the priority date to modify Soundararajan with the zero knowledge proof payments of Ferenczi for the purpose of providing a zero-knowledge proof payment system that may be used to complete transactions between a customer and a merchant without the customer needing to expose sensitive data, including transaction account data ... The algorithm enables the customer to prove knowledge or possession of certain information (e.g., the transaction account data), and the merchant to verify knowledge or possession of the information, without the actual information needing to be disclosed or exchanged between the parties (see Ferenczi, para 0015).
Regarding Claim 6, a combination of Soundararajan-Ferenczi-Maeng discloses the system of claim 5.
Soundararajan does not disclose: wherein the commitment and proof include a zero knowledge proof circuit and private data.
However, Ferenczi discloses: wherein the commitment and proof include a zero knowledge proof circuit and private data (“The zero-knowledge proof payment system and process may be used to complete transactions between a customer and a merchant without the customer needing to expose sensitive data, including transaction account data. The system may implement a zero-knowledge proof algorithm such as, for example, zkSNARKs. The algorithm enables the customer to prove knowledge or possession of certain information (e.g., the transaction account data), and the merchant to verify knowledge or possession of the information, without the actual information needing to be disclosed or exchanged between the parties” [0015] [Examiner notes that the customer proving knowledge of transaction account data without disclosing or exchanging the transaction account data constitutes private data]; “hardware components such as application specific integrated circuits (ASICs)” [0081]; “the system may employ various integrated circuit components, e.g., memory elements, processing elements, logic elements, look-up tables, and the like, which may carry out a variety of functions under the control of one or more microprocessors or other control devices” [0103] [Examiner notes the circuits that carry out zero knowledge proof payment systems constitute zero knowledge proof circuits]).
It would have been obvious to one of ordinary skill in the art before the priority date to modify Soundararajan with the zero knowledge proof payments of Ferenczi for the purpose of providing a zero-knowledge proof payment system that may be used to complete transactions between a customer and a merchant without the customer needing to expose sensitive data, including transaction account data ... The algorithm enables the customer to prove knowledge or possession of certain information (e.g., the transaction account data), and the merchant to verify knowledge or possession of the information, without the actual information needing to be disclosed or exchanged between the parties (see Ferenczi, para 0015).
Regarding Claim 7, a combination of Soundararajan-Ferenczi-Maeng discloses the system of claim 1.
Soundararajan does not disclose: an application program interface to facilitate communications with the off chain zero knowledge proof machines and third-party applications.
However, Ferenczi discloses: an application program interface to facilitate communications with the off chain zero knowledge proof machines and third-party applications (“Issuer system 130 may also include one or more data centers, cloud storages, or the like, and may include software, such as APIs, configured to perform various operations discussed herein. Issuer system 130 may also include one or more blockchain nodes, application programming interfaces (APIs), software development kits (SDKs), or the like configured to allow issuer system 130 to interact with blockchain network 140, retrieve and write data to the blockchain, and deploy one or more ZKP smart contracts 145” [0029] [Examiner notes the issuer system including APIs constitutes an application program interface to facilitate communications with the off chain knowledge proof machine and third-party applications]; “issuer system 130 may generate different keys based on different payment types (e.g., credit card, debit card, gift card, loyalty points, a third party payment provider, etc.)” [0042]; [Examiner notes the third party payment provider constitutes a third party application]).
It would have been obvious to one of ordinary skill in the art before the priority date to modify Soundararajan with the zero knowledge proof payments of Ferenczi for the purpose of providing a zero-knowledge proof payment system that may be used to complete transactions between a customer and a merchant without the customer needing to expose sensitive data, including transaction account data ... The algorithm enables the customer to prove knowledge or possession of certain information (e.g., the transaction account data), and the merchant to verify knowledge or possession of the information, without the actual information needing to be disclosed or exchanged between the parties (see Ferenczi, para 0014).
Regarding Claim 8, a combination of Soundararajan-Ferenczi-Maeng discloses the system of claim 1.
Soundararajan further discloses: wherein the off chain transaction confirmation machines are distributed machines in a cloud environment (“The one or more computer systems or computer processors may also operate to support performance of the relevant operations in a "cloud computing" environment or as a "software as a service" (SaaS)” [0184]).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over US 2020/0042958 A1 to Soundararajan et al. (hereinafter, “Soundararajan”) in view of US 2020/0193425 A1 to Ferenczi et al. (hereinafter, “Ferenczi”) and in further view of US 10762478 B1 to Maeng and in further view of US 2019/0205884 A1 to Batra et al. (hereinafter, “Batra”).
Regarding Claim 4, a combination of Soundararajan-Ferenczi-Maeng discloses the system of claim 3.
Soundararajan-Ferenczi-Maeng do not disclose: wherein the smart contract has a configurable permission orchestration structure.
However, Batra discloses: wherein the smart contract has a configurable permission orchestration structure (“The example process encodes state 'status' and a portion of the workflow process that manages that state, which enforces access control rules and defines the interfaces between interacting smart contracts. For example, a smart contract may be configured to have a published 'private', 'protected' and/or 'public' event(s). Private events can only be subscribed by the event generating smart contract, public events can be subscribed by other smart contracts having (one or more) common parties and protected events can be subscribed by any smart contract on the network. Smart contract programs may subscribe to events generated by other smart contracts running on the blockchain. This enables an event-subscription based collaboration and orchestration among smart contracts and enables inter-smart contract workflow execution that permits an end-to-end workflow to occur as a set of interacting smart contracts with the necessary access controls” [0030] [Examiner notes that the smart contracts enforcing access control rules and defining interactions between smart contracts based on a designation of private, protected, and public events constitutes smart contracts that have configurable permission orchestration structure where private events can only be subscribed by the event generating smart contract, but public events can be subscribed by other smart contracts having common parties, which shows permissions in the form of access control]).
It would have been obvious to one of ordinary skill in the art before the priority date to modify Soundararajan-Ferenczi-Maeng with the smart contracts of Batra for the purpose of evaluating complex multi-party workflow processes which cannot be implemented/executed through a single smart contract on a blockchain. The workflow process is identified, analyzed and used to automatically generate multiple interacting smart contracts on the blockchain. For a given (complex) workflow process specification, subsets of parties transacting together may be identified and consolidated as sub-parts of the business process where the changing set of transacting parties may be identified as sub-workflow or sub-contract boundaries for those parties (see Batra, para 0020).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over US 2020/0042958 A1 to Soundararajan et al. (hereinafter, “Soundararajan”) in view of US 2020/0193425 A1 to Ferenczi et al. (hereinafter, “Ferenczi”) and in further view of US 10762478 B1 to Maeng and in further view of US 2021/0264408 A1 to Paschini et al. (hereinafter, “Paschini”).
Regarding Claim 9, a combination of Soundararajan-Ferenczi-Maeng discloses the system of claim 1.
Soundararajan-Ferenczi-Maeng do not disclose: off chain treasury machines and on chain treasury machines to support tokenized federal treasury bond processing.
However, Paschini discloses: off chain treasury machines and on chain treasury machines to support tokenized federal treasury bond processing (“the system 100 includes an Al-based management platform 140 configured to facilitate digital wallet transactions conducted by individuals 102, businesses 103 and merchants 104” [0046]; “The system 100 also interfaces with banks 105 and other financial institutions 106 holding government debt 170 backing the tokenized assets held or associated with such tokenized assets” [0047]; “The transactions involving the digital wallets 108 are recorded as one or more blockchains (hereinafter "blockchain wallet" or "blockchain") within a transaction validation and recording network 164 including a plurality of distributed nodes 166. The ID and risk score module 114 determines a risk score for each digital wallet 108 based at least in part on such transactions in the manner described herein” [0049]; “the tokenized crypto asset is pegged to a government issued fiat currency (e.g., USD, EUR). The token is collateralized by purchasing and holding government treasury bonds 170 (from the same nations the token is pegged to), except for funds which are in flight for settlement back to the pegged fiat currency. The government bonds 170 are kept in regulated financial institutions 106” [para 0050] [Examiner notes the financial institutions 106 holding government debt constitute off chain treasury machines that support tokenized federal treasury bond processing and the distributed nodes that add transactions to the blockchain constitute on chain treasury machines that support tokenized federal treasury bond processing]; “As shown, a user's bank 184 initially sends a fiat currency (e.g., U.S. dollars) to the partner bank 105 (stage 402). The partner bank 105 then sends a corresponding amount of the fiat currency to a platform treasury account 190 associated with one or more entities such as, for example, one or more operator(s) of the platform 140 (stage 404). The smart contract module 118 then checks the ID classification and the risk score of the user to determine if the user is eligible to receive the tokens desired to be purchased (stage 408), i.e., the smart contract module 118 determines whether to approve the token purchase transaction to proceed or not). If the user is determined to be eligible to send the tokens (stage 412), the smart contract module 118 transfers the tokens from a treasury wallet 192 to the digital wallet 108; that is, the smart contact module 118 records the token transfer in the blockchain wallet existing within the transaction validation and recording network 164 (stage 416). If the user is determined to be ineligible to send the tokens (stage 412), the smart contract module 118 rejects the transaction (stage 420) and the fiat currency within the treasury account 190 is returned to the user's bank 184, either directly or via the partner bank 105 (stage 424). In one embodiment the partner bank 105 and the financial institution 106 maintaining the platform treasury account 190 may be the same institution. FIG. 5 is a flow diagram representative of an exemplary process 500 of minting or burning tokens of the stable cryptocurrency within the system 100. The process of minting new tokens begin with the collection of a fiat currency (e.g., U.S. dollars) from users in the platform treasury account 190 (stage 502). This may occur by, for example, transfer of fiat currency from user accounts at one or more user banks 184 to a platform treasury account 190, potentially by way of a partner bank 105 utilized by the platform. Similarly, the process of burning, i.e., destroying tokens begins with the transfer of the fiat currency from the platform treasury account 190 in response to withdrawal transactions initiated by users (stage 502). Based on the net fiat currency received (for new issuance) or withdrawn (burn tokens), a determination is made as to whether new tokens of the stable cryptocurrency need to be minted or existing tokens burned (stage 506). The AI engine 148 determines the amount of treasury bonds in the fiat currency to be bought or sold to 100% collateralize all issued tokens (stage 510). In one embodiment the parameters used by the AI engine 148 in determining the amount of treasury bonds to be bought or sold include: net daily liquidity requirements for fiat USD, bond maturity, available USD from new mining, macro economic outlook of US economy, and the like. Once the treasury bonds are bought or sold, the smart contract module 118 mints new tokens or burns existing tokens (stage 514)” [0068-0069]).
It would have been obvious to one of ordinary skill in the art before the priority date to modify Soundararajan-Ferenczi-Maeng with the tokenized assets of Paschini for the purpose of enabling a tokenized crypto asset backed by sovereign debt (or "stable coin") to be traded in a controlled network configured to score and otherwise rate the risk of trading with counterparties on the network ... Since the tokenized crypto asset is not backed by or held in any one bank but is instead backed by government debt, the stability of the tokenized crypto asset is more akin to the stability of the government debt rather than to the stability of a single bank holding collateral in fiat currency. Banks can fail and pose a risk to any decentralized tokenized asset which is backed by an asset such as fiat money in a bank or gold in a warehouse. For example, the bank holding the funds can go insolvent, be stripped of its licenses or be sanctioned by governments. By placing the collateral for the tokenized crypto asset into sovereign debt such as government treasury bonds, these banking-related risks are eliminated (see Paschini, para 0008).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
Gutierrez-Sheris (US 2025/0190966 A1) teaches techniques for a blockchain system including a global state and an assemblage of blocks, each block representing a collection of state transformation records, each state transformation record describing a state transformation performed on the global state, where preceding blocks referenced by any given block contain state transformation records describing state transformations performed on the global state prior to the evaluation of the given block, and where at least one state transformation record is a zero-knowledge transformation record encoding a zero-knowledge state transformation description, which zero-knowledge transformation record comprises at least the following elements: paths identifying the locations of the elements of a discrete data subset, a revised data subset, and a transition proof implemented as a non-interactive zero-knowledge proof, which transition proof proves that the transition from the discrete data subset to the revised data subset follows the established rules of the blockchain system.
Agbamu (US 2024/0346473 A1) teaches techniques for a computer-implemented payment and banking system, includes a gateway microservice system comprising proxying, authenticating, logging, routing, and monitoring functionality for managing systems, requests, and responses, enabling the orchestration of communication between a plurality of upstream and downstream systems, an open and/or core banking system enabling functionality comprising authentication, transmission, and receipt of data and/or transactions between a plurality of upstream and downstream systems, an account management system synchronized with the open and/or core banking system facilitating actions comprising buying, selling, transferring, depositing, withdrawing, and exchanging of fungible assets, and a data storage system for storing, retrieving, updating, and synchronizing data.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SARON MATTHEWOS WORKU whose telephone number is (703)756-1761. The examiner can normally be reached Monday - Friday, 9:30 am - 6:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Linglan Edwards can be reached on 571-270-5440. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SARON MATTHEWOS WORKU/Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408
Prosecution Insights