DETAILED ACTION
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 .
Status of the Claims
This is a final office action in response to claims and Remarks submitted on October 14, 2025 relating to U.S. Patent Application 18/378,298, filed on October 10, 2023. No claims have been amended by Applicant. Claims 1-18 are pending and have been examined.
Response to Arguments
The Remarks submitted by Applicant on October 14, 2025, have been fully considered, however, are not persuasive.
With respect to the Section 101 rejection, Applicant disagrees with the rejection and asserts that the Office Action has mischaracterized the claims in that it provides an unreasonable interpretation of the claims that ignores and gives no patentable weight to numerous unique /unconventional elements. (Remarks, pp. 22-25). Applicant further disagrees with the rejection and asserts that the claims add significantly more to the abstract idea. (Remarks, pp. 25-26). Examiner respectfully disagrees. The abstract and the additional elements in the claim are specified. The additional elements are recited at a high level of generality and are used as tools to implement the abstract idea. They do not provide improvements to the functioning of a computer or to technology. Applicant has not provided support from the Specification to indicate otherwise. Further, they do not add significantly more to the abstract idea because as there is no detail provided as to how the additional elements perform the abstract steps. The Section 101 rejection is maintained.
With respect to the Claim Interpretation under Section 112(f) Applicant asserts that there is no requirement that claims follow formulaic language with regard to 35 USC 112 or other sections of the code, and Applicant does not assent to any asserted/forced Office Action interpretations of claim language. (Remarks, p. 44). The Claim Interpretation under Section 112(f) is maintained.
With respect to the Section 103 rejection, Applicant asserts that the cited references, Fantini and Ingargiola do not disclose the elements of the claim, particularly "obtain... via a bidirectional decentralized exchange smart contract deployed on a blockchain, a decentralized exchange liquidity provision transaction structured as specifying... a crypto assets liquidity tranche datastructure." (Remarks, pp. 38-41). Examiner respectfully disagrees. Although Fantini does not use similar language as the application, this is just labeling. The cited references disclose the elements of the claim. The Section 103 Rejection is maintained.
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-18 are rejected pursuant to 35 USC § 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1 - Statutory Class
Claims 1-15 are directed to an apparatus. Claim 16 is directed to a processor- readable, non-transient medium. Claim 17 is directed to a processor-implemented system. Claim 18 is directed to processor-implemented process. Therefore, on their face, each of the claims are directed to a statutory class of invention.
Step 2A, Prong 1 – Abstract Idea
Claim 1 recites obtain, via a bidirectional decentralized exchange contract, a decentralized exchange liquidity provision transaction structured as specifying: a crypto assets liquidity tranche data structure from a plurality of crypto assets liquidity tranche data structures that constitute a liquidity pool associated with the bidirectional decentralized exchange contract, a first contribution amount associated with a first crypto asset type, a second contribution amount associated with a second crypto asset type, and a provision blockchain address controlled by a sender of the decentralized exchange liquidity provision transaction; determine, a crypto assets exchange quotient for exchanging the first crypto asset type and the second crypto asset type; calculate, a quantity of fungible tokens specific to the crypto assets liquidity tranche data structure to generate via a calculation involving: the first contribution amount associated with the first crypto asset type, the second contribution amount associated with the second crypto asset type, the crypto assets exchange quotient, a quantity of previously issued fungible tokens specific to the crypto assets liquidity tranche data structure, and a total value locked in the crypto assets liquidity tranche data structure; and the crypto assets liquidity tranche data structure to the provision blockchain address controlled by the sender of the decentralized exchange liquidity provision transaction. The abstract idea in Claim 1 recites performing a transaction involving an exchange of crypto assets which falls within commercial interactions under Certain Methods of Organizing Human Activity under MPEP 2106. Claims 16, 17 and 18 recite the same abstract idea.
Step 2A, Prong 2 – Practical Application
Claim 1 recites at least one memory, a component collection stored in the at least one memory, at least one processor disposed in communication with the at least one memory, the at least one processor executing processor-executable instructions from the component collection, the component collection storage structured with processor- executable instructions, a smart contract, a blockchain, tokens and a datastructure. The additional elements are recited at a high level of generality and are used as tools to implement the abstract idea. They do not provide improvements to the functioning of a computer or to technology because they only manipulate data. The claims do not invoke a particular machine as our guidance is clear that a generic computer is not the particular machine envisioned, they do not transform matter as they only manipulate data which is not matter.
Step 2B – Significantly more
As set forth in the discussion in Step 2A, Prong 2, above, the additional elements are recited at a high level of generality and are used as tools to implement the abstract idea. They do not add significantly more to the abstract idea because there is no detail as to how the additional elements perform the abstract steps.
Dependent claims
Claim 2 (update, via at least one processor, crypto assets balances for the crypto assets liquidity tranche data structure to reflect contributions of the first contribution amount associated with the first crypto asset type and of the second contribution amount associated with the second crypto asset type), Claim 3 (the instructions to determine the crypto assets exchange quotient are structured as instructions to query a price oracle), Claim 4 (verify, via at least one processor, exchange quotient fidelity associated with the crypto assets exchange quotient by checking compliance of a confidence measure provided by the price oracle with a confidence measure threshold rule), Claim 5 (the instructions to determine the crypto assets exchange quotient are structured as instructions to utilize a derived crypto assets exchange quotient upon determining that a timestamp associated with the derived crypto assets exchange quotient is more recent than a timestamp associated with a crypto assets exchange quotient from the price oracle), Claim 6 (each of the plurality of crypto assets liquidity tranche data structures that constitute the liquidity pool associated with the bidirectional decentralized exchange smart contract utilizes a different type of fungible tokens specific to the respective crypto assets liquidity tranche data structure), Claim 7 (obtain, via at least one processor, via the bidirectional decentralized exchange smart contract deployed on the blockchain, a decentralized exchange liquidity redemption transaction structured as specifying: the crypto assets liquidity tranche data structure, a first redemption quantity associated with the fungible tokens specific to the crypto assets liquidity tranche data structure, and a redemption blockchain address controlled by a sender of the decentralized exchange liquidity redemption transaction; calculate, via at least one processor, a first redemption amount associated with the first crypto asset type via a calculation involving: the first redemption quantity associated with the fungible tokens specific to the crypto assets liquidity tranche data structure, a quantity of currently issued fungible tokens specific to the crypto assets liquidity tranche data structure, and a total amount of crypto assets of the first crypto asset type locked in the crypto assets liquidity tranche data structure; calculate, via at least one processor, a second redemption amount associated with the second crypto asset type via a calculation involving: the first redemption quantity associated with the fungible tokens specific to the crypto assets liquidity tranche data structure, the quantity of currently issued fungible tokens specific to the crypto assets liquidity tranche data structure, and a total amount of crypto assets of the second crypto asset type locked in the crypto assets liquidity tranche data structure; and transfer, via at least one processor, the calculated first redemption amount of crypto assets of the first crypto asset type and the calculated second redemption amount of crypto assets of the second crypto asset type to the provision blockchain address controlled by the sender of the decentralized exchange liquidity redemption transaction), Claim 8 (update, via at least one processor, crypto assets balances for the crypto assets liquidity tranche data structure to reflect redemption of the first redemption amount associated with the first crypto asset type and of the second redemption amount associated with the second crypto asset type), Claim 9 (the component collection storage is further structured with processor-executable instructions, comprising: exchange liquidity redemption transaction is within an allowed redemption time), Claim 10 (determine, via at least one processor, that a timestamp associated with the decentralized exchange liquidity redemption transaction is outside an allowed redemption time; determine, via at least one processor, an updated crypto assets exchange quotient for exchanging the first crypto asset type and the second crypto asset type; and allow, via at least one processor, execution of the decentralized exchange liquidity redemption transaction upon determining that exchange quotient fidelity associated with the updated crypto assets exchange quotient is not verified), Claim 11 (determine, via at least one processor, that a timestamp associated with the decentralized exchange liquidity redemption transaction is outside an allowed redemption time; determine, via at least one processor, an updated crypto assets exchange quotient for exchanging the first crypto asset type and the second crypto asset type; and deny, via at least one processor, execution of the decentralized exchange liquidity redemption transaction upon determining that exchange quotient fidelity associated with the updated crypto assets exchange quotient is verified), Claim 12 (remove, via at least one processor, the first redemption quantity of fungible tokens specific to the crypto assets liquidity tranche data structure from circulation), Claim 13 (a fungible token is removed from circulation by destroying the fungible token), Claim 14 ( ) and Claim 15 (update, via at least one processor, a derived crypto assets exchange quotient for exchanging the first crypto asset type and the second crypto asset type upon execution of the decentralized exchange liquidity provision transaction; and update, via at least one processor, the derived crypto assets exchange quotient for exchanging the first crypto asset type and the second crypto asset type upon execution of the decentralized exchange liquidity redemption transaction) further define and add specificity to the abstract idea. Thus, the dependent claims also fail to add significantly more to the abstract idea.
As such, Claims 1-18 are not patent eligible.
Claim Interpretation - 35 USC § 112(f)
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier.
Like “means” the word “unit” is a nonce term that does not indicate any particular structure.
The claim limitations are: “means to store a component collection” and “means to process executable instructions from the component collection” in Claim 17.
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed functions, and equivalents thereof.
Support can be found in Paragraphs 244 and 245 and Fig. 17 of the Specification with respect to means to store a component collection. Support can be found in Paragraphs 232, 233, 244 and 245 and Fig. 17 of the Specification with respect to means to process executable instructions from the component collection. The Specification discloses sufficient structure to perform the claimed functions.
If applicant does not intend to have these limitations interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed functions); or (2) present a sufficient showing that the claim limitations recite sufficient structure to perform the claimed functions so as to avoid them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 103
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, 6-7 and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Fantini et al., U.S. 2023/0141423 A1, (“Fantini”), in view of Ingargiola, U.S. 2021/0073913 A1, (“Ingargiola”)
Claim 1:
Fantini teaches:
A bidirectional decentralized exchange apparatus, comprising: at least one memory; a component collection stored in the at least one memory; at least one processor disposed in communication with the at least one memory, the at least one processor executing processor-executable instructions from the component collection, the component collection storage structured with processor- executable instructions, comprising: (See Fantini, Par. 35 (Reference to FIG. 1, the zero-impact limit trade service computer system 102, in some embodiments, can be a node of the blockchain infrastructure/network 110 and it performs a portion or all of the processing steps for zero-impact limit trade described herein in response to the processor 130 executing computer readable program codes having one or more sequences of one or more instructions contained in the application memory 124. Zero-impact limit trade service computer system 102 may include one computer for multiple computers with different software components operating on different computers/nodes of the blockchain infrastructure. The application server 120 includes an application 122 including executable application code for performing the functions of the application. Application 122 may store data 126 in application memory 124. Application memory 124 may include internal tables for data related to order books, for example, or other data structures for maintaining and manipulating data used by application 122. Application memory 124 may store data corresponding to simple or complex data structures.))
obtain, via at least one processor, via a bidirectional decentralized exchange smart contract deployed on a blockchain, a decentralized exchange liquidity provision transaction structured as specifying: a crypto assets liquidity tranche data structure from a plurality of crypto assets liquidity tranche data structures that constitute a liquidity pool associated with the bidirectional decentralized exchange smart contract, (See Fantini, Par. 52 (A smart contract, which is compatible for interaction with the decentralized oracle system 108, is then generated by the zero-impact limit trade service computer system 102 for the intended trade/swap as in step 416. The smart contract automatically opens a custom made one-sided liquidity pool in the decentralized exchange (Uni swap V3, for example) on behalf of the trader/user 109 for the trade/swap.) a first contribution amount associated with a first crypto asset type, a second contribution amount associated with a second crypto asset type, and (See Fantini, Par. 49 (The user 109 is then required to select a first digital asset (digital asset ETH in this example) using the button 506 and enter, using the button 508, a desired amount or number / quantity of the first digital asset (desired quantity of first digital asset to be swapped is 1 in the present example) which the user 109 wants to swap, as shown in the exemplary screenshots of the user interfaces 502 and 504 in FIGS. 5A and 5B respectively. The user 109 is then required to select the second digital asset using the button 606 on the user interface (as in exemplary screenshot 602 of FIG. 6A), as shown in step 406 of FIG. 4.))
determine, via at least one processor, a crypto assets exchange quotient for exchanging the first crypto asset type and the second crypto asset type; (See Fantini, Figs. 4, 9A – 9B, Par. 53 (The decentralized oracle system 108 continuously monitors the price of the swap token pair in real time as in step 422 and checks if the smart contract requires any work to be done and calls the smart contract, as in step 424 of FIG. 4, as soon as the market moves to the target price set by the user 109. Block 306 of FIG. 3 represents this step. The blockchain infrastructure 110 then verifies the target price match as in step 426 of FIG. 4 (also, block 308 of FIG. 3).), (The target price of the swap token pair reads on the crypto assets exchange quotient insofar as the respective prices of the crypto assets is used by the oracle to determine the amounts exchanged.))
calculate, via at least one processor, a quantity of fungible tokens specific to the crypto assets liquidity tranche data structure to generate via a calculation involving: the first contribution amount associated with the first crypto asset type, the second contribution amount associated with the second crypto asset type, the crypto assets exchange quotient, a quantity of previously issued fungible tokens specific to the crypto assets liquidity tranche data structure, and a total value locked in the crypto assets liquidity tranche data structure; and (See Fantini, Figs. 4, 9A – 9B, Par. 53 (The decentralized oracle system 108 continuously monitors the price of the swap token pair in real time as in step 422 and checks if the smart contract requires any work to be done and calls the smart contract, as in step 424 of FIG. 4, as soon as the market moves to the target price set by the user 109. Block 306 of FIG. 3 represents this step. The blockchain infrastructure 110 then verifies the target price match as in step 426 of FIG. 4 (also, block 308 of FIG. 3).))
transfer, via at least one processor, the calculated quantity of fungible tokens specific to the crypto assets liquidity tranche data structure to the provision blockchain address controlled by the sender of the decentralized exchange liquidity provision transaction. (See Fantini, Par. 53 (If a price match is confirmed i.e. if the decentralized oracle system 108 confirms that the limit order conditions are fulfilled i.e. the market has moved to the target price set by the user 109, then the trade is executed i.e. the limit order execution is started by swapping the first digital asset (ETH in the present example) for the second digital asset (CIV in the present example) at the target price, as shown in block 310 of FIG. 3 and in step 428 of FIG. 4, using the one-sided liquidity pool which was already created. Every such transaction is broadcasted to the blockchain network 110.))
Fantini does not expressly disclose, however, Ingargiola teaches:
a provision blockchain address controlled by a sender of the decentralized exchange liquidity provision transaction; (See Ingargiola Par. 215 (The nodes can include access control with signed genesis blocks by one or more governance nodes (any governance from centralized to federated, to voting rights as a token on a public ledger protocol. With respect to the tokenization (issuance) process and the burn (redeem/detokenization) processes, the nodes can issue requests (create new un-mined token issuance signed by the custodian for public key address of a user aka "coinbase" transaction), redeem requests (send to burn address); or custodian controlled address is possible for other use cases and lock and unlock data or assets (can be wallet to wallet transfer with different policies applied, (e.g. no withdrawals allowed without m of n signature or custodial signature) or other programmatic lock or reservation of assets (e.g. smart contract code executed on a public ledger or other machine or policies) preventing movement/spend.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Fantini discussed above, a step for providing an address controlled by a sender, as taught by Ingargiola. Fantini teaches a system for execution of trades on a decentralized system. It would be obvious for --Fantini to include a step for providing an address controlled by a sender so as to provide more security for the transaction. Since the claimed invention is merely a combination of old elements, Fantini’s decentralized trading system and Ingargiola’s address controlled by a sender, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 3:
Fantini and Ingargiola teach each and every element of Claim 1 above.
Fantini further teaches:
the instructions to determine the crypto assets exchange quotient are structured as instructions to query a price oracle. (See Fantini, Par. 52 (The zero-impact limit trade service computer system 102 then fetches the limit trade request information, as in step 412 of FIG. 4, and processes it for the next step. For the real-time monitoring of one or more price feeds/data to find one or more matches for the swapping of the exemplary pair of tokens ETH/CIV (first digital asset/second digital asset) at the target price, the zero-impact limit trade service computer system 102 takes help from the decentralized oracle system 108. To create a smart contract that is compatible with the decentralized oracle system 108, the zero impact limit trade service computer system 102 imports the packages/codes/kits from the decentralized oracle system 108, as in step 414 of FIG. 4.))
Claim 6:
Fantini and Ingargiola teach each and every element of Claim 1 above.
Fantini further teaches:
each of the plurality of crypto assets liquidity tranche data structures that constitute the liquidity pool associated with the bidirectional decentralized exchange smart contract utilizes a different type of fungible tokens specific to the respective crypto assets liquidity tranche data structure. (See Fantini, Par. 52 (For the real-time monitoring of one or more price feeds/data to find one or more matches for the swapping of the exemplary pair of tokens ETH / CIV (first digital asset/second digital asset) at the target price, the zero-impact limit trade service computer system 102 takes help from the decentralized oracle system 108. To create a smart contract that is compatible with the decentralized oracle system 108, the zero impact limit trade service computer system 102 imports the packages/codes/kits from the decentralized oracle system 108, as in step 414 of FIG. 4.))
Claim 7:
Fantini and Ingargiola teach each and every element of Claim 1 above.
Fantini further teaches:
obtain, via at least one processor, via the bidirectional decentralized exchange smart contract deployed on the blockchain, a decentralized exchange liquidity redemption transaction structured as specifying: the crypto assets liquidity tranche data structure, a first redemption quantity associated with the fungible tokens specific to the crypto assets liquidity tranche data structure, and (See Fantini, Par. 52 (A smart contract, which is compatible for interaction with the decentralized oracle system 108, is then generated by the zero-impact limit trade service computer system 102 for the intended trade/swap as in step 416. The smart contract automatically opens a custom made one-sided liquidity pool in the decentralized exchange (Uni swap V3, for example) on behalf of the trader/user 109 for the trade/swap.), Par. 49 (The user 109 is then required to select a first digital asset (digital asset ETH in this example) using the button 506 and enter, using the button 508, a desired amount or number / quantity of the first digital asset (desired quantity of first digital asset to be swapped is 1 in the present example) which the user 109 wants to swap, as shown in the exemplary screenshots of the user interfaces 502 and 504 in FIGS. 5A and 5B respectively. The user 109 is then required to select the second digital asset using the button 606 on the user interface (as in exemplary screenshot 602 of FIG. 6A), as shown in step 406 of FIG. 4.))
calculate, via at least one processor, a first redemption amount associated with the first crypto asset type via a calculation involving: the first redemption quantity associated with the fungible tokens specific to the crypto assets liquidity tranche data structure, a quantity of currently issued fungible tokens specific to the crypto assets liquidity tranche data structure, and a total amount of crypto assets of the first crypto asset type locked in the crypto assets liquidity tranche data structure; (See Fantini, Figs. 4, 9A – 9B, Par. 53 (The decentralized oracle system 108 continuously monitors the price of the swap token pair in real time as in step 422 and checks if the smart contract requires any work to be done and calls the smart contract, as in step 424 of FIG. 4, as soon as the market moves to the target price set by the user 109. Block 306 of FIG. 3 represents this step. The blockchain infrastructure 110 then verifies the target price match as in step 426 of FIG. 4 (also, block 308 of FIG. 3).))
calculate, via at least one processor, a second redemption amount associated with the second crypto asset type via a calculation involving: the first redemption quantity associated with the fungible tokens specific to the crypto assets liquidity tranche data structure, the quantity of currently issued fungible tokens specific to the crypto assets liquidity tranche data structure, and a total amount of crypto assets of the second crypto asset type locked in the crypto assets liquidity tranche data structure; and (This step involves a duplication of parts similar to the prior step.) (See Fantini, Figs. 4, 9A – 9B, Par. 53 (The decentralized oracle system 108 continuously monitors the price of the swap token pair in real time as in step 422 and checks if the smart contract requires any work to be done and calls the smart contract, as in step 424 of FIG. 4, as soon as the market moves to the target price set by the user 109. Block 306 of FIG. 3 represents this step. The blockchain infrastructure 110 then verifies the target price match as in step 426 of FIG. 4 (also, block 308 of FIG. 3).))
transfer, via at least one processor, the calculated first redemption amount of crypto assets of the first crypto asset type and the calculated second redemption amount of crypto assets of the second crypto asset type to the provision blockchain address controlled by the sender of the decentralized exchange liquidity redemption transaction. (See Fantini, Par. 53 (If a price match is confirmed i.e. if the decentralized oracle system 108 confirms that the limit order conditions are fulfilled i.e. the market has moved to the target price set by the user 109, then the trade is executed i.e. the limit order execution is started by swapping the first digital asset (ETH in the present example) for the second digital asset (CIV in the present example) at the target price, as shown in block 310 of FIG. 3 and in step 428 of FIG. 4, using the one-sided liquidity pool which was already created. Every such transaction is broadcasted to the blockchain network 110.))
Fantini does not expressly disclose, however, Ingargiola teaches:
a redemption blockchain address controlled by a sender of the decentralized exchange liquidity redemption transaction; (See Ingargiola Par. 215 (The nodes can include access control with signed genesis blocks by one or more governance nodes (any governance from centralized to federated, to voting rights as a token on a public ledger protocol. With respect to the tokenization (issuance) process and the burn (redeem/detokenization) processes, the nodes can issue requests (create new un-mined token issuance signed by the custodian for public key address of a user aka "coinbase" transaction), redeem requests (send to burn address); or custodian controlled address is possible for other use cases and lock and unlock data or assets (can be wallet to wallet transfer with different policies applied, (e.g. no withdrawals allowed without m of n signature or custodial signature) or other programmatic lock or reservation of assets (e.g. smart contract code executed on a public ledger or other machine or policies) preventing movement/spend.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Fantini discussed above, a step for providing an address controlled by a sender, as taught by Ingargiola. Fantini teaches a system for execution of trades on a decentralized system. It would be obvious for --Fantini to include a step for providing an address controlled by a sender so as to provide more security for the transaction. Since the claimed invention is merely a combination of old elements, Fantini’s decentralized trading system and Ingargiola’s address controlled by a sender, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 15:
Fantini and Ingargiola teach each and every element of Claim 7 above.
Fantini further teaches:
update, via at least one processor, a derived crypto assets exchange quotient for exchanging the first crypto asset type and the second crypto asset type upon execution of the decentralized exchange liquidity provision transaction; and Figs. 4, 9A – 9B, Par. 53 (The decentralized oracle system 108 continuously monitors the price of the swap token pair in real time as in step 422 and checks if the smart contract requires any work to be done and calls the smart contract, as in step 424 of FIG. 4, as soon as the market moves to the target price set by the user 109. Block 306 of FIG. 3 represents this step. The blockchain infrastructure 110 then verifies the target price match as in step 426 of FIG. 4 (also, block 308 of FIG. 3).), (The target price of the swap token pair reads on the crypto assets exchange quotient insofar as the respective prices of the crypto assets is used by the oracle to determine the amounts exchanged.))
update, via at least one processor, the derived crypto assets exchange quotient for exchanging the first crypto asset type and the second crypto asset type upon execution of the decentralized exchange liquidity redemption transaction. Figs. 4, 9A – 9B, Par. 53 (The decentralized oracle system 108 continuously monitors the price of the swap token pair in real time as in step 422 and checks if the smart contract requires any work to be done and calls the smart contract, as in step 424 of FIG. 4, as soon as the market moves to the target price set by the user 109. Block 306 of FIG. 3 represents this step. The blockchain infrastructure 110 then verifies the target price match as in step 426 of FIG. 4 (also, block 308 of FIG. 3).), (The target price of the swap token pair reads on the crypto assets exchange quotient insofar as the respective prices of the crypto assets is used by the oracle to determine the amounts exchanged.))
Claim 16:
Fantini teaches:
A bidirectional decentralized exchange processor-readable, non-transient medium, the medium storing a component collection, the component collection storage structured with processor-executable instructions comprising: (See Fantini, Par. 35 (Reference to FIG. 1, the zero-impact limit trade service computer system 102, in some embodiments, can be a node of the blockchain infrastructure/network 110 and it performs a portion or all of the processing steps for zero-impact limit trade described herein in response to the processor 130 executing computer readable program codes having one or more sequences of one or more instructions contained in the application memory 124. Zero-impact limit trade service computer system 102 may include one computer for multiple computers with different software components operating on different computers/nodes of the blockchain infrastructure. The application server 120 includes an application 122 including executable application code for performing the functions of the application. Application 122 may store data 126 in application memory 124. Application memory 124 may include internal tables for data related to order books, for example, or other data structures for maintaining and manipulating data used by application 122. Application memory 124 may store data corresponding to simple or complex data structures.))
obtain, via at least one processor, via a bidirectional decentralized exchange smart contract deployed on a blockchain, a decentralized exchange liquidity provision transaction structured as specifying: a crypto assets liquidity tranche data structure from a plurality of crypto assets liquidity tranche data structures that constitute a liquidity pool associated with the bidirectional decentralized exchange smart contract, (See Fantini, Par. 52 (A smart contract, which is compatible for interaction with the decentralized oracle system 108, is then generated by the zero-impact limit trade service computer system 102 for the intended trade/swap as in step 416. The smart contract automatically opens a custom made one-sided liquidity pool in the decentralized exchange (Uni swap V3, for example) on behalf of the trader/user 109 for the trade/swap.) a first contribution amount associated with a first crypto asset type, a second contribution amount associated with a second crypto asset type, and (See Fantini, Par. 49 (The user 109 is then required to select a first digital asset (digital asset ETH in this example) using the button 506 and enter, using the button 508, a desired amount or number / quantity of the first digital asset (desired quantity of first digital asset to be swapped is 1 in the present example) which the user 109 wants to swap, as shown in the exemplary screenshots of the user interfaces 502 and 504 in FIGS. 5A and 5B respectively. The user 109 is then required to select the second digital asset using the button 606 on the user interface (as in exemplary screenshot 602 of FIG. 6A), as shown in step 406 of FIG. 4.))
determine, via at least one processor, a crypto assets exchange quotient for exchanging the first crypto asset type and the second crypto asset type; (See Fantini, Figs. 4, 9A – 9B, Par. 53 (The decentralized oracle system 108 continuously monitors the price of the swap token pair in real time as in step 422 and checks if the smart contract requires any work to be done and calls the smart contract, as in step 424 of FIG. 4, as soon as the market moves to the target price set by the user 109. Block 306 of FIG. 3 represents this step. The blockchain infrastructure 110 then verifies the target price match as in step 426 of FIG. 4 (also, block 308 of FIG. 3).), (The target price of the swap token pair reads on the crypto assets exchange quotient insofar as the respective prices of the crypto assets is used by the oracle to determine the amounts exchanged.))
calculate, via at least one processor, a quantity of fungible tokens specific to the crypto assets liquidity tranche data structure to generate via a calculation involving: the first contribution amount associated with the first crypto asset type, the second contribution amount associated with the second crypto asset type, the crypto assets exchange quotient, a quantity of previously issued fungible tokens specific to the crypto assets liquidity tranche data structure, and a total value locked in the crypto assets liquidity tranche data structure; and (See Fantini, Figs. 4, 9A – 9B, Par. 53 (The decentralized oracle system 108 continuously monitors the price of the swap token pair in real time as in step 422 and checks if the smart contract requires any work to be done and calls the smart contract, as in step 424 of FIG. 4, as soon as the market moves to the target price set by the user 109. Block 306 of FIG. 3 represents this step. The blockchain infrastructure 110 then verifies the target price match as in step 426 of FIG. 4 (also, block 308 of FIG. 3).))
transfer, via at least one processor, the calculated quantity of fungible tokens specific to the crypto assets liquidity tranche data structure to the provision blockchain address controlled by the sender of the decentralized exchange liquidity provision transaction. (See Fantini, Par. 53 (If a price match is confirmed i.e. if the decentralized oracle system 108 confirms that the limit order conditions are fulfilled i.e. the market has moved to the target price set by the user 109, then the trade is executed i.e. the limit order execution is started by swapping the first digital asset (ETH in the present example) for the second digital asset (CIV in the present example) at the target price, as shown in block 310 of FIG. 3 and in step 428 of FIG. 4, using the one-sided liquidity pool which was already created. Every such transaction is broadcasted to the blockchain network 110.))
Fantini does not expressly disclose, however, Ingargiola teaches:
a provision blockchain address controlled by a sender of the decentralized exchange liquidity provision transaction; (See Ingargiola Par. 215 (The nodes can include access control with signed genesis blocks by one or more governance nodes (any governance from centralized to federated, to voting rights as a token on a public ledger protocol. With respect to the tokenization (issuance) process and the burn (redeem/detokenization) processes, the nodes can issue requests (create new un-mined token issuance signed by the custodian for public key address of a user aka "coinbase" transaction), redeem requests (send to burn address); or custodian controlled address is possible for other use cases and lock and unlock data or assets (can be wallet to wallet transfer with different policies applied, (e.g. no withdrawals allowed without m of n signature or custodial signature) or other programmatic lock or reservation of assets (e.g. smart contract code executed on a public ledger or other machine or policies) preventing movement/spend.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Fantini discussed above, a step for providing an address controlled by a sender, as taught by Ingargiola. Fantini teaches a system for execution of trades on a decentralized system. It would be obvious for --Fantini to include a step for providing an address controlled by a sender so as to provide more security for the transaction. Since the claimed invention is merely a combination of old elements, Fantini’s decentralized trading system and Ingargiola’s address controlled by a sender, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 17:
Fantini teaches:
A bidirectional decentralized exchange processor-implemented system, comprising: means to store a component collection; means to process processor-executable instructions from the component collection, the component collection storage structured with processor-executable instructions including: (See Fantini, Par. 35 (Reference to FIG. 1, the zero-impact limit trade service computer system 102, in some embodiments, can be a node of the blockchain infrastructure/network 110 and it performs a portion or all of the processing steps for zero-impact limit trade described herein in response to the processor 130 executing computer readable program codes having one or more sequences of one or more instructions contained in the application memory 124. Zero-impact limit trade service computer system 102 may include one computer for multiple computers with different software components operating on different computers/nodes of the blockchain infrastructure. The application server 120 includes an application 122 including executable application code for performing the functions of the application. Application 122 may store data 126 in application memory 124. Application memory 124 may include internal tables for data related to order books, for example, or other data structures for maintaining and manipulating data used by application 122. Application memory 124 may store data corresponding to simple or complex data structures.))
obtain, via at least one processor, via a bidirectional decentralized exchange smart contract deployed on a blockchain, a decentralized exchange liquidity provision transaction structured as specifying: a crypto assets liquidity tranche data structure from a plurality of crypto assets liquidity tranche data structures that constitute a liquidity pool associated with the bidirectional decentralized exchange smart contract, (See Fantini, Par. 52 (A smart contract, which is compatible for interaction with the decentralized oracle system 108, is then generated by the zero-impact limit trade service computer system 102 for the intended trade/swap as in step 416. The smart contract automatically opens a custom made one-sided liquidity pool in the decentralized exchange (Uni swap V3, for example) on behalf of the trader/user 109 for the trade/swap.) a first contribution amount associated with a first crypto asset type, a second contribution amount associated with a second crypto asset type, and (See Fantini, Par. 49 (The user 109 is then required to select a first digital asset (digital asset ETH in this example) using the button 506 and enter, using the button 508, a desired amount or number / quantity of the first digital asset (desired quantity of first digital asset to be swapped is 1 in the present example) which the user 109 wants to swap, as shown in the exemplary screenshots of the user interfaces 502 and 504 in FIGS. 5A and 5B respectively. The user 109 is then required to select the second digital asset using the button 606 on the user interface (as in exemplary screenshot 602 of FIG. 6A), as shown in step 406 of FIG. 4.))
determine, via at least one processor, a crypto assets exchange quotient for exchanging the first crypto asset type and the second crypto asset type; (See Fantini, Figs. 4, 9A – 9B, Par. 53 (The decentralized oracle system 108 continuously monitors the price of the swap token pair in real time as in step 422 and checks if the smart contract requires any work to be done and calls the smart contract, as in step 424 of FIG. 4, as soon as the market moves to the target price set by the user 109. Block 306 of FIG. 3 represents this step. The blockchain infrastructure 110 then verifies the target price match as in step 426 of FIG. 4 (also, block 308 of FIG. 3).), (The target price of the swap token pair reads on the crypto assets exchange quotient insofar as the respective prices of the crypto assets is used by the oracle to determine the amounts exchanged.))
calculate, via at least one processor, a quantity of fungible tokens specific to the crypto assets liquidity tranche data structure to generate via a calculation involving: the first contribution amount associated with the first crypto asset type, the second contribution amount associated with the second crypto asset type, the crypto assets exchange quotient, a quantity of previously issued fungible tokens specific to the crypto assets liquidity tranche data structure, and a total value locked in the crypto assets liquidity tranche data structure; and (See Fantini, Figs. 4, 9A – 9B, Par. 53 (The decentralized oracle system 108 continuously monitors the price of the swap token pair in real time as in step 422 and checks if the smart contract requires any work to be done and calls the smart contract, as in step 424 of FIG. 4, as soon as the market moves to the target price set by the user 109. Block 306 of FIG. 3 represents this step. The blockchain infrastructure 110 then verifies the target price match as in step 426 of FIG. 4 (also, block 308 of FIG. 3).))
transfer, via at least one processor, the calculated quantity of fungible tokens specific to the crypto assets liquidity tranche data structure to the provision blockchain address controlled by the sender of the decentralized exchange liquidity provision transaction. (See Fantini, Par. 53 (If a price match is confirmed i.e. if the decentralized oracle system 108 confirms that the limit order conditions are fulfilled i.e. the market has moved to the target price set by the user 109, then the trade is executed i.e. the limit order execution is started by swapping the first digital asset (ETH in the present example) for the second digital asset (CIV in the present example) at the target price, as shown in block 310 of FIG. 3 and in step 428 of FIG. 4, using the one-sided liquidity pool which was already created. Every such transaction is broadcasted to the blockchain network 110.))
Fantini does not expressly disclose, however, Ingargiola teaches:
a provision blockchain address controlled by a sender of the decentralized exchange liquidity provision transaction; (See Ingargiola Par. 215 (The nodes can include access control with signed genesis blocks by one or more governance nodes (any governance from centralized to federated, to voting rights as a token on a public ledger protocol. With respect to the tokenization (issuance) process and the burn (redeem/detokenization) processes, the nodes can issue requests (create new un-mined token issuance signed by the custodian for public key address of a user aka "coinbase" transaction), redeem requests (send to burn address); or custodian controlled address is possible for other use cases and lock and unlock data or assets (can be wallet to wallet transfer with different policies applied, (e.g. no withdrawals allowed without m of n signature or custodial signature) or other programmatic lock or reservation of assets (e.g. smart contract code executed on a public ledger or other machine or policies) preventing movement/spend.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Fantini discussed above, a step for providing an address controlled by a sender, as taught by Ingargiola. Fantini teaches a system for execution of trades on a decentralized system. It would be obvious for --Fantini to include a step for providing an address controlled by a sender so as to provide more security for the transaction. Since the claimed invention is merely a combination of old elements, Fantini’s decentralized trading system and Ingargiola’s address controlled by a sender, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 18:
Fantini teaches:
A bidirectional decentralized exchange processor-implemented process, including processing processor-executable instructions via at least one processor from a component collection stored in at least one memory, the component collection storage structured with processor-executable instructions comprising: (See Fantini, Par. 35 (Reference to FIG. 1, the zero-impact limit trade service computer system 102, in some embodiments, can be a node of the blockchain infrastructure/network 110 and it performs a portion or all of the processing steps for zero-impact limit trade described herein in response to the processor 130 executing computer readable program codes having one or more sequences of one or more instructions contained in the application memory 124. Zero-impact limit trade service computer system 102 may include one computer for multiple computers with different software components operating on different computers/nodes of the blockchain infrastructure. The application server 120 includes an application 122 including executable application code for performing the functions of the application. Application 122 may store data 126 in application memory 124. Application memory 124 may include internal tables for data related to order books, for example, or other data structures for maintaining and manipulating data used by application 122. Application memory 124 may store data corresponding to simple or complex data structures.))
obtain, via at least one processor, via a bidirectional decentralized exchange smart contract deployed on a blockchain, a decentralized exchange liquidity provision transaction structured as specifying: a crypto assets liquidity tranche data structure from a plurality of crypto assets liquidity tranche data structures that constitute a liquidity pool associated with the bidirectional decentralized exchange smart contract, (See Fantini, Par. 52 (A smart contract, which is compatible for interaction with the decentralized oracle system 108, is then generated by the zero-impact limit trade service computer system 102 for the intended trade/swap as in step 416. The smart contract automatically opens a custom made one-sided liquidity pool in the decentralized exchange (Uni swap V3, for example) on behalf of the trader/user 109 for the trade/swap.) a first contribution amount associated with a first crypto asset type, a second contribution amount associated with a second crypto asset type, and (See Fantini, Par. 49 (The user 109 is then required to select a first digital asset (digital asset ETH in this example) using the button 506 and enter, using the button 508, a desired amount or number / quantity of the first digital asset (desired quantity of first digital asset to be swapped is 1 in the present example) which the user 109 wants to swap, as shown in the exemplary screenshots of the user interfaces 502 and 504 in FIGS. 5A and 5B respectively. The user 109 is then required to select the second digital asset using the button 606 on the user interface (as in exemplary screenshot 602 of FIG. 6A), as shown in step 406 of FIG. 4.))
determine, via at least one processor, a crypto assets exchange quotient for exchanging the first crypto asset type and the second crypto asset type; (See Fantini, Figs. 4, 9A – 9B, Par. 53 (The decentralized oracle system 108 continuously monitors the price of the swap token pair in real time as in step 422 and checks if the smart contract requires any work to be done and calls the smart contract, as in step 424 of FIG. 4, as soon as the market moves to the target price set by the user 109. Block 306 of FIG. 3 represents this step. The blockchain infrastructure 110 then verifies the target price match as in step 426 of FIG. 4 (also, block 308 of FIG. 3).), (The target price of the swap token pair reads on the crypto assets exchange quotient insofar as the respective prices of the crypto assets is used by the oracle to determine the amounts exchanged.))
calculate, via at least one processor, a quantity of fungible tokens specific to the crypto assets liquidity tranche data structure to generate via a calculation involving: the first contribution amount associated with the first crypto asset type, the second contribution amount associated with the second crypto asset type, the crypto assets exchange quotient, a quantity of previously issued fungible tokens specific to the crypto assets liquidity tranche data structure, and a total value locked in the crypto assets liquidity tranche data structure; and (See Fantini, Figs. 4, 9A – 9B, Par. 53 (The decentralized oracle system 108 continuously monitors the price of the swap token pair in real time as in step 422 and checks if the smart contract requires any work to be done and calls the smart contract, as in step 424 of FIG. 4, as soon as the market moves to the target price set by the user 109. Block 306 of FIG. 3 represents this step. The blockchain infrastructure 110 then verifies the target price match as in step 426 of FIG. 4 (also, block 308 of FIG. 3).))
transfer, via at least one processor, the calculated quantity of fungible tokens specific to the crypto assets liquidity tranche data structure to the provision blockchain address controlled by the sender of the decentralized exchange liquidity provision transaction. (See Fantini, Par. 53 (If a price match is confirmed i.e. if the decentralized oracle system 108 confirms that the limit order conditions are fulfilled i.e. the market has moved to the target price set by the user 109, then the trade is executed i.e. the limit order execution is started by swapping the first digital asset (ETH in the present example) for the second digital asset (CIV in the present example) at the target price, as shown in block 310 of FIG. 3 and in step 428 of FIG. 4, using the one-sided liquidity pool which was already created. Every such transaction is broadcasted to the blockchain network 110.))
Fantini does not expressly disclose, however, Ingargiola teaches:
a provision blockchain address controlled by a sender of the decentralized exchange liquidity provision transaction; (See Ingargiola Par. 215 (The nodes can include access control with signed genesis blocks by one or more governance nodes (any governance from centralized to federated, to voting rights as a token on a public ledger protocol. With respect to the tokenization (issuance) process and the burn (redeem/detokenization) processes, the nodes can issue requests (create new un-mined token issuance signed by the custodian for public key address of a user aka "coinbase" transaction), redeem requests (send to burn address); or custodian controlled address is possible for other use cases and lock and unlock data or assets (can be wallet to wallet transfer with different policies applied, (e.g. no withdrawals allowed without m of n signature or custodial signature) or other programmatic lock or reservation of assets (e.g. smart contract code executed on a public ledger or other machine or policies) preventing movement/spend.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Fantini discussed above, a step for providing an address controlled by a sender, as taught by Ingargiola. Fantini teaches a system for execution of trades on a decentralized system. It would be obvious for --Fantini to include a step for providing an address controlled by a sender so as to provide more security for the transaction. Since the claimed invention is merely a combination of old elements, Fantini’s decentralized trading system and Ingargiola’s address controlled by a sender, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claims 2 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Fantini et al., U.S. 2023/0141423 A1, (“Fantini”), in view of in view of Ingargiola, U.S. 2021/0073913 A1, (“Ingargiola”), in further view of McNamara et al., U.S. 10,902,416 B1, (“McNamara”).
Claim 2:
Fantini and Ingargiola teach each and every element of Claim 1 above.
Fantini does not expressly disclose, however, McNamara teaches:
update, via at least one processor, crypto assets balances for the crypto assets liquidity tranche data structure to reflect contributions of the first contribution amount associated with the first crypto asset type and of the second contribution amount associated with the second crypto asset type. (See McNamara, Col. 13, lines 62-67 (In certain examples, the exchange account adapter 345 can output an account exchange connection status event that comprises, for example, an exchange account address and account balance events indicating transfers, withdrawals, deposits, and/or value medium conversions.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Fantini discussed above, a step for providing account balances after the asset transfers, as taught by McNamara. Fantini teaches a system for execution of trades on a decentralized system. It would be obvious for --Fantini to include a step for providing account balances after the asset transfers so as to the user with his current account details after an asset transfer. Since the claimed invention is merely a combination of old elements, Fantini’s decentralized trading system and McNamara’s providing account balances after the asset transfers, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 8:
Fantini and Ingargiola teach each and every element of Claim 7 above.
Fantini does not expressly disclose, however, McNamara teaches:
update, via at least one processor, crypto assets balances for the crypto assets liquidity tranche data structure to reflect redemption of the first redemption amount associated with the first crypto asset type and of the second redemption amount associated with the second crypto asset type. (See McNamara, Col. 13, lines 62-67 (In certain examples, the exchange account adapter 345 can output an account exchange connection status event that comprises, for example, an exchange account address and account balance events indicating transfers, withdrawals, deposits, and/or value medium conversions.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Fantini discussed above, a step for providing account balances after the asset transfers, as taught by McNamara. Fantini teaches a system for execution of trades on a decentralized system. It would be obvious for --Fantini to include a step for providing account balances after the asset transfers so as to the user with his current account details after an asset transfer. Since the claimed invention is merely a combination of old elements, Fantini’s decentralized trading system and McNamara’s providing account balances after the asset transfers, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Fantini et al., U.S. 2023/0141423 A1, (“Fantini”), in view of in view of Ingargiola, U.S. 2021/0073913 A1, (“Ingargiola”), in further view of Osborn et al., U.S. 2023/0298016 A1, (“Osborn”).
Claim 4:
Fantini and Ingargiola teach each and every element of Claim 3 above.
Fantini does not expressly disclose, however, Osborn teaches:
verify, via at least one processor, exchange quotient fidelity associated with the crypto assets exchange quotient by checking compliance of a confidence measure provided by the price oracle with a confidence measure threshold rule. (See Osborn, Par. 77 (The oracle device of clause 1, wherein the transaction pattern data comprises, for one or more of the blockchain payment transactions, a payment type indicating a purchase, sale, or peer-to-peer transfer, an amount, or a category of associated goods or services.), Par. 78 (The oracle device of clause 1, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to, responsive to determining that the confidence score is below a threshold value.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Fantini discussed above, a step for an oracle providing a confidence measure based on a threshold, as taught by Osborn. Fantini teaches a system for execution of trades on a decentralized system. It would be obvious for --Fantini to include a step for having an oracle provide a confidence measure based on a threshold so as to provide a measure as to the accuracy of the asset exchange transaction. Since the claimed invention is merely a combination of old elements, Fantini’s decentralized trading system and Osborn’s oracle providing a confidence measure based on a threshold, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Fantini et al., U.S. 2023/0141423 A1, (“Fantini”), in view of in view of Ingargiola, U.S. 2021/0073913 A1, (“Ingargiola”), in further view of Leshner et al., U.S. 2021/0065302 A1, (“Leshner”).
Claim 5:
Fantini and Ingargiola teach each and every element of Claim 3 above.
Fantini does not expressly disclose, however, Leshner teaches:
utilize a derived crypto assets exchange quotient upon determining that a timestamp associated with the derived crypto assets exchange quotient is more recent than a timestamp associated with a crypto assets exchange quotient from the price oracle. (See Leshner, Par. 48 (Certain digital assets, for instance underlying digital assets for each pool, may fluctuate in value outside of the protocol. The protocol may implement a price oracle for maintaining the current exchange rate of each supported digital asset.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Fantini discussed above, a step for using the most current crypto exchange quotient, as taught by Leshner. Fantini teaches a system for execution of trades on a decentralized system. It would be obvious for --Fantini to include a step for using the most current crypto exchange quotient so as to provide the most timely information for an accurate asset exchange transaction. Since the claimed invention is merely a combination of old elements, Fantini’s decentralized trading system and Leshner’s use of the most current crypto exchange quotient, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Fantini et al., U.S. 2023/0141423 A1, (“Fantini”), in view of in view of Ingargiola, U.S. 2021/0073913 A1, (“Ingargiola”), in further view of Dichtl, WO 2020/043508 A1, (“Dichtl”).
Claim 9:
Fantini and Ingargiola teach each and every element of Claim 7 above.
Fantini does not expressly disclose, however, Dichtl teaches:
exchange liquidity redemption transaction is within an allowed redemption time (See Dichtl, Description (Exchange transaction requests are preferably only allowed within a predetermined period of time after the solution to the cryptographic challenge has been identified.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Fantini discussed above, a step for providing a pre-determined period of time to complete a transaction request, as taught by Dichtl. Fantini teaches a system for execution of trades on a decentralized system. It would be obvious for --Fantini to include a step for providing a pre-determined period of time to complete a transaction request so restrict an open ended request and provide a measure of security to the exchange transaction. Since the claimed invention is merely a combination of old elements, Fantini’s decentralized trading system and Dichtl’s pre-determined period of time to complete a transaction, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claims 10 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Fantini et al., U.S. 2023/0141423 A1, (“Fantini”), in view of in view of Ingargiola, U.S. 2021/0073913 A1, (“Ingargiola”), in further view of Dichtl, WO 2020/043508 A1, (“Dichtl”), in further view of Osborn et al., U.S. 2023/0298016 A1, (“Osborn”).
Claim 10:
Fantini and Ingargiola teach each and every element of Claim 7 above.
Fantini further teaches:
determine, via at least one processor, an updated crypto assets exchange quotient for exchanging the first crypto asset type and the second crypto asset type; and (See Fantini, Figs. 4, 9A – 9B, Par. 53 (The decentralized oracle system 108 continuously monitors the price of the swap token pair in real time as in step 422 and checks if the smart contract requires any work to be done and calls the smart contract, as in step 424 of FIG. 4, as soon as the market moves to the target price set by the user 109. Block 306 of FIG. 3 represents this step. The blockchain infrastructure 110 then verifies the target price match as in step 426 of FIG. 4 (also, block 308 of FIG. 3).), (The target price of the swap token pair reads on the crypto assets exchange quotient insofar as the respective prices of the crypto assets is used by the oracle to determine the amounts exchanged.))
Fantini does not expressly disclose, however, Dichtl teaches:
determine, via at least one processor, that a timestamp associated with the decentralized exchange liquidity redemption transaction is outside an allowed redemption time; (See Dichtl, Description (Exchange transaction requests are preferably only allowed within a predetermined period of time after the solution to the cryptographic challenge has been identified.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Fantini discussed above, a step for providing a pre-determined period of time to complete a transaction request, as taught by Dichtl. Fantini teaches a system for execution of trades on a decentralized system. It would be obvious for --Fantini to include a step for providing a pre-determined period of time to complete a transaction request so restrict an open ended request and provide a measure of security to the exchange transaction. Since the claimed invention is merely a combination of old elements, Fantini’s decentralized trading system and Dichtl’s pre-determined period of time to complete a transaction, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Fantini does not expressly disclose, however, Osborn teaches:
allow, via at least one processor, execution of the decentralized exchange liquidity redemption transaction upon determining that exchange quotient fidelity associated with the updated crypto assets exchange quotient is not verified. (See Osborn, Par. 77 (The oracle device of clause 1, wherein the transaction pattern data comprises, for one or more of the blockchain payment transactions, a payment type indicating a purchase, sale, or peer-to-peer transfer, an amount, or a category of associated goods or services.), Par. 78 (The oracle device of clause 1, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to, responsive to determining that the confidence score is below a threshold value.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Fantini discussed above, a step for an oracle providing a confidence measure based on a threshold, as taught by Osborn. Fantini teaches a system for execution of trades on a decentralized system. It would be obvious for --Fantini to include a step for having an oracle provide a confidence measure based on a threshold so as to provide a measure as to the accuracy of the asset exchange transaction. Since the claimed invention is merely a combination of old elements, Fantini’s decentralized trading system and Osborn’s oracle providing a confidence measure based on a threshold, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 11:
Fantini and Ingargiola teach each and every element of Claim 7 above.
Fantini further teaches:
determine, via at least one processor, an updated crypto assets exchange quotient for exchanging the first crypto asset type and the second crypto asset type; and (See Fantini, Figs. 4, 9A – 9B, Par. 53 (The decentralized oracle system 108 continuously monitors the price of the swap token pair in real time as in step 422 and checks if the smart contract requires any work to be done and calls the smart contract, as in step 424 of FIG. 4, as soon as the market moves to the target price set by the user 109. Block 306 of FIG. 3 represents this step. The blockchain infrastructure 110 then verifies the target price match as in step 426 of FIG. 4 (also, block 308 of FIG. 3).), (The target price of the swap token pair reads on the crypto assets exchange quotient insofar as the respective prices of the crypto assets is used by the oracle to determine the amounts exchanged.))
Fantini does not expressly disclose, however, Dichtl teaches:
determine, via at least one processor, that a timestamp associated with the decentralized exchange liquidity redemption transaction is outside an allowed redemption time; (See Dichtl, Description (Exchange transaction requests are preferably only allowed within a predetermined period of time after the solution to the cryptographic challenge has been identified.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Fantini discussed above, a step for providing a pre-determined period of time to complete a transaction request, as taught by Dichtl. Fantini teaches a system for execution of trades on a decentralized system. It would be obvious for --Fantini to include a step for providing a pre-determined period of time to complete a transaction request so restrict an open ended request and provide a measure of security to the exchange transaction. Since the claimed invention is merely a combination of old elements, Fantini’s decentralized trading system and Dichtl’s pre-determined period of time to complete a transaction, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Fantini does not expressly disclose, however, Osborn teaches:
deny, via at least one processor, execution of the decentralized exchange liquidity redemption transaction upon determining that exchange quotient fidelity associated with the updated crypto assets exchange quotient is verified. (See Osborn, Par. 77 (The oracle device of clause 1, wherein the transaction pattern data comprises, for one or more of the blockchain payment transactions, a payment type indicating a purchase, sale, or peer-to-peer transfer, an amount, or a category of associated goods or services.), Par. 78 (The oracle device of clause 1, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to, responsive to determining that the confidence score is below a threshold value.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Fantini discussed above, a step for an oracle providing a confidence measure based on a threshold, as taught by Osborn. Fantini teaches a system for execution of trades on a decentralized system. It would be obvious for --Fantini to include a step for having an oracle provide a confidence measure based on a threshold so as to provide a measure as to the accuracy of the asset exchange transaction. Since the claimed invention is merely a combination of old elements, Fantini’s decentralized trading system and Osborn’s oracle providing a confidence measure based on a threshold, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claims 12-14 are rejected under 35 U.S.C. 103 as being unpatentable over Fantini et al., U.S. 2023/0141423 A1, (“Fantini”), in view of in view of Ingargiola, U.S. 2021/0073913 A1, (“Ingargiola”), in further view of Doney, U.S. 11,430,066 B2, (“Doney”),
Claim 12:
Fantini and Ingargiola teach each and every element of Claim 7 above.
Fantini does not expressly disclose, however, Doney teaches:
remove, via at least one processor, the first redemption quantity of fungible tokens specific to the crypto assets liquidity tranche data structure from circulation. (See Doney, Col. 7, lines 31-38 (Disclosed implementations include an interface specification and data structure enabling a smart contract and/or a discrete token to be associated with, i.e. to own, a cryptographic wallet. This novel structure makes it possible for a token to own other tokens and add or remove other tokens from its ownership and to conduct transactions with other entities by interacting with wallets 211 corresponding to other tokens or entities.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Fantini discussed above, a step for removing a token from circulation, as taught by Doney. Fantini teaches a system for execution of trades on a decentralized system. It would be obvious for --Fantini to include a step for removing a token from circulation so as to conduct transactions with other tokens. Since the claimed invention is merely a combination of old elements, Fantini’s decentralized trading system and Doney’s removing a token from circulation, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 13:
Fantini, Ingargiola and Doney teach each and every element of Claim 12 above.
Fantini does not expressly disclose, however, Doney teaches:
a fungible token is removed from circulation by destroying the fungible token. (See Doney, Col. 26, lines 5-9 (At 4006, base wallet on Provider B sends value to Destination Wallet on Provider B. At 4008, on transaction completion, equivalent number of tokens are destroyed from Provider A Base Wallet.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Fantini discussed above, a step for destroying a token, as taught by Doney. Fantini teaches a system for execution of trades on a decentralized system. It would be obvious for --Fantini to include a step for destroying it so as to remove it from circulation. Since the claimed invention is merely a combination of old elements, Fantini’s decentralized trading system and Doney’s destroying a token, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 14:
Fantini, Ingargiola and Doney teach each and every element of Claim 12 above.
Fantini does not expressly disclose, however, Doney teaches:
a fungible token is removed from circulation by returning the fungible token to a fixed supply. (See Doney, Col. 7, lines 31-38 (Disclosed implementations include an interface specification and data structure enabling a smart contract and/or a discrete token to be associated with, i.e. to own, a cryptographic wallet. This novel structure makes it possible for a token to own other tokens and add or remove other tokens from its ownership and to conduct transactions with other entities by interacting with wallets 211 corresponding to other tokens or entities.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Fantini discussed above, a step for removing a token from circulation, as taught by Doney. Fantini teaches a system for execution of trades on a decentralized system. It would be obvious for --Fantini to include a step for removing a token from circulation so as to conduct transactions with other tokens. Since the claimed invention is merely a combination of old elements, Fantini’s decentralized trading system and Doney’s removing a token from circulation, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Conclusion
THIS ACTION IS MADE FINAL. 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GEORGE PROIOS whose telephone number is (571)272-4573. The examiner can normally be reached M-F 8-5.
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, Bennett M Sigmond can be reached on 303-297-4411. 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.
/GEORGE N. PROIOS/Examiner, Art Unit 3694
/BENNETT M SIGMOND/Supervisory Patent Examiner, Art Unit 3694
Prosecution Insights