Detailed Action
This office action is in response to applicant’s submission filed on December 10, 2025. 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 .
Response to Amendment
This communication is in response to the amendment filed on December 10, 2025. The Examiner has acknowledged the amended claims 1 and 4. Claims 1-9 are pending and are rejected.
Drawings
The replacement drawings filed on 12/10/2025 have been accepted. They were also reviewed for informality.
Response to Arguments
Applicant’s Arguments (Remarks) filed December 10, 2025 have been fully considered, but are not persuasive. Note that this action is made FINAL. See MPEP § 706.07(a).
Applicant’s arguments with respect to claims 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.
Therefore, Examiner notes that the amended claim limitations are still taught by the prior art.
The amendments to claims 1 has resolved the claim rejections.
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”).
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]).
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.
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]).
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 2, a combination of Soundararajan-Ferenczi 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 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 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 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 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 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 2019/0205884 A1 to Batra et al. (hereinafter, “Batra”).
Regarding Claim 4, a combination of Soundararajan-Ferenczi discloses the system of claim 3.
Soundararajan-Ferenczi 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 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 2021/0264408 A1 to Paschini et al. (hereinafter, “Paschini”).
Regarding Claim 9, a combination of Soundararajan-Ferenczi discloses the system of claim 1.
Soundararajan-Ferenczi 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 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
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
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:30am - 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