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 Ingar