DETAILED ACTION
This is a final office action on the merits. The U.S. Patent and Trademark Office (the Office) has received claims 1 – 18.
Claims 1-18 are pending and have been examined on the merits.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
35 USC § 101
Applicant's arguments filed 12/01/2025 have been fully considered but they are not persuasive.
On page 24, applicant asserts that the examiner adopted “an unreasonable interpretation of the claim(s) that literally ignores and gives no patentable weight to numerous unique/unconventional elements.” The examiner respectfully disagrees. All claim elements have been considered and the action identifies the language that recites an abstract idea versus recites an additional element. The applicant might disagree with the examiner’s characterization as such, but that is different from ignoring or giving no patentable weight.
On page 25, applicant further argues that, “Literally over ¾ of the claim elements are outright ignored in the Office Action's analysis for the various steps” and “As such, the Office Action's assertion that the claim is directed to an abstract idea is based on an interpretation that is willfully blind to numerous valuable claim elements, making it an unreasonable and therefor impermissible interpretation, see supra, paragraph(s) 0017.1 above.” Applicant’s argument is not persuasive. The 101 analysis must consider the claim as a whole and must account for all recited limitations. USPTO guidance expressly says to “consider all of the recited limitations when determining eligibility,” and Step 2A Prong 2 evaluates the claim as a whole, including additional elements individually in combination. However, that does not mean every recited limitation necessarily weighs in favor of eligibility, nor does it mean a claim becomes eligible simply because it includes many detailed limitations. The issue is whether, after considering those limitations, the claim as a whole is directed to a judicial exception and, if so, whether the additional elements integrate that exception into a practical application. Here, even considering the allegedly “ignored” limitations, the claim still centers on rules for administering a financial arrangement. The claim limitations describe the management of a commercial exchange position, which remains with the abstract idea framework because the claims do not express a specific technological improvement in blockchain, networking, storage or computer operation. Still, even with the full consideration of the claim language, this does not change the conclusion that the claim is directed to an abstract idea of managing decentralized-exchange liquidity provisioning and redemption, implemented using generic computer and blockchain components, and therefore does not integrate the exception into a practical application.
Applicant’s arguments on page 27 and 28 are not persuasive. Although Enfish recognizes that software based claims can be eligible when they are directed to a specific improvement in computer functionality, the present claims do not clearly improve how a computer, blockchain, or network operates. Instead, they recite rules for managing a decentralized exchange liquidity position using known tool such as a processor, blockchain smart contract, oracle, and NFT. That is not the kind of computer functionality improvement described in Enfish and MPEP 2106.05. The limitations mention on page 27 do not show integration into a practical application merely because they are detailed. The claim still focuses on selecting asset types, contribution amounts, exchange quotients, liquidity amounts, and NFT linked tracking of the position which is best understood as financial management logic (i.e., part of the abstract idea) implemented in a blockchain environment. Under USPTO guidance, limiting an abstract idea to a particular technological environment does not by itself make the claim patent eligible.
Applicant’s arguments on page 34 is not persuasive. The Office must consider the machine or transformation test, but Bilski and MPEP 2106 make it clear that it is only a useful clue not a separate or controlling test for eligibility. The controlling inquiry remains the Alice framework – whether the claim is directed to a judicial exception and if so, whether the additional elements integrate the exception into a practical application or amount to significantly more. Reciting DEPO components, processors, smart contracts, and blockchain implementation does not by itself show a meaningful machine limitation. Accordingly, even considering the machine or transformation argument, the claims remain directed to managing decentralized exchange liquidity provision. Transforming data falls under the abstract idea and does not qualify as transforming a physical object to a different state or thing that would meet the Step 2A, prong 2 considerations.
Applicant’s arguments on page 38 is not persuasive. The August 4, 2025 Kim Memorandum does caution examiners not to oversimplify claims but that memorandum also reaffirms that examiners must still apply the existing MPEP 2106 framework and evaluate whether the claim as a whole is directed to a judicial exception and whether any additional elements integrate that exception into a practical application. The rejection is maintained without violating the guidance that was provided.
Applicant’s arguments on page 41 is not persuasive. Desjardins does not hold that all software related claims are eligible, rather it applies Enfish to claims that recited a specific technological improvement in how the computer implement system itself operate. The present claims are different. Here, the claimed “unidirectional decentralized exchange,” smart contract, oracle, liquidity tranche data structure, and NFT metadata are used to carry out and track a financial liquidity management scheme. These features do not clearly improve computer functionality, blockchain functionality, or another technical field in the manner discussed in Enfish and Desjardins. Therefore, the 101 rejection is maintained.
35 USC § 103
Applicant's arguments filed 12/01/2025 have been fully considered but they are not persuasive. Applicant argues Fantini does not disclose a “crypto assets liquidity tranche data structure” because Fantini does not use the word “tranche.” This is not persuasive because the prior art is not required to use the identical claim terminology. Under the broadest reasonable interpretation, the claimed “crypto assets liquidity tranche datastructure” reads on data defining a particular liquidity position within a liquidity pool. Fantini teaches that “a smart contract automatically opens a custom made one-sided liquidity pool in the decentralized exchange…on behalf of the trader/user 109 (¶ 0052)” which is a particular liquidity pool position within a pool rather than the entire exchange.
Applicant’s position that Fantini has “no structure” corresponding to the claimed transaction is also unpersuasive. Fantini teaches a smart contract based workflow in which the user selects “a first digital asset,” selects the second digital asset, and enters a “desired amount or number/quantity of the first digital asset (¶ 0049).” Fantini further teaches that the pool is opened with a “narrow range defined around the target price of the limit order” and that the user deposits only first digital asset (¶ 0052). Collectively, these disclosures teach a transaction structure specifying at least: a source asset type, a target asset type, a contribution amount, and an exchange condition/quotient tied to the target price.
Applicant argues Fantini lacks the recited “provision blockchain address controlled by a sender.” Even assuming Fantini does not expressly disclose that feature, the rejection does not rely on Fantini alone for that limitation. Ingargiola teaches issuance/redemption requests signed for the “public key address of a user” and also describes wallet-to-wallet transfers and custodian controlled address (¶ 0215). Thus, Ingargiola cures the admitted deficiency regarding an address controlled by the transaction sender.
Applicant’s argument that Ingargiola cannot be combined because there is “no structure present in Fantini into which the Ingargiola element would be placed” is not persuasive. A proper obviousness analysis does not require physical insertion of one reference into another. The question is whether the combined teachings would have suggested the claimed subject matter to a person of ordinary skill. Here, incorporating a sender controlled blockchain address into Fantini’s smart contract based liquidity provision transaction would have been a predictable implementation choice for identifying the user, controlling asset movement, and authorizing provision/redemption activity.
Applicant’s argument that Fantini is not “obtain…via a unidirectional decentralized exchange smart contract deployed on a blockchain” is likewise unpersuasive. Fantini teaches a smart contract generated for the intended trade/swap, compatible with the decentralized oracle system, and “subsequently deployed on the blockchain infrastructure 110 as in step 418 as a transaction block (¶ 0052).” Fantini further teaches a “one-sided liquidity pool,” which reasonably corresponds to the claimed unidirectional liquidity provision under the broadest reasonable interpretation.
Applicant’s assertion that the Office Action improperly treated claim terms as mere “name,” “labes,” or “nonfunctional” language is not persuasive on this record. The rejection need not ignore claim language to determine that certain terms are broad labels for otherwise known structures. The issue is not whether the references use applicant’s exact nomenclature, but whether they teach the claimed substance. Here, the cited references collectively teach the substantive features of the claimed liquidity provision transaction and associated sender controlled blockchain addressing.
Accordingly, the rejection remains proper because the disputed limitations obvious to a person of ordinary skill in the art.
USC § 112
Applicant's arguments filed 12/01/2025 have been fully considered but they are not persuasive. Please see rejection below.
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 under 35 U.S.C. 101 because the claimed invention recites and is directed to a judicial exception to patentability (i.e., an abstract idea) and does not provide an integration of the recited abstract idea into a practical application nor include an inventive concept that is “significantly more” than the recited abstract idea to which the claim is directed. MPEP §2106.
In determining subject matter eligibility in an Alice rejection under 35 U.S.C. §101, it is first determined at Step 1 whether the claims are directed to one of the four statutory categories of an invention (i.e., a process, a machine, a manufacture, or a composition of matter). MPEP §2106.03. Here, it is determined that claims 1-15 are directed to an apparatus (system), claims 16-18 are directed to a process; Under a Step 2A, Prong 1 analysis, it must be determined whether the claims recite an abstract idea that falls within one or more enumerated categories of patent ineligible subject matter that amounts to a judicial exception to patentability. MPEP §2106.04. Here, independent claim 1 recites:
A unidirectional 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: obtain, via at least one processor, via a unidirectional 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 unidirectional decentralized exchange smart contract,
a first contribution amount associated with a source crypto asset type,
a target crypto asset type,
a limit crypto assets exchange quotient for exchanging the source crypto asset type and the target crypto asset type, and
a provision blockchain address controlled by a sender of the decentralized exchange liquidity provision transaction;
determine, via at least one processor, a crypto assets exchange quotient for exchanging the source crypto asset type and the target crypto asset type;
execute, via at least one processor, an imbalance rule check for the crypto assets liquidity tranche data structure, in which the imbalance rule check is executed via a calculation involving: a first total amount of crypto assets of the source crypto asset type locked in the crypto assets liquidity tranche data structure;
a second total amount of crypto assets of the target crypto asset type locked in the crypto assets liquidity tranche data structure;
the crypto assets exchange quotient, and
the first contribution amount associated with the source crypto asset type; and
mint, via at least one processor, a non-fungible token specific to the crypto assets liquidity tranche data structure, in which the non-fungible token is associated with the provision blockchain address controlled by the sender of the decentralized exchange liquidity provision transaction, and in which the non-fungible token comprises metadata structured as specifying: an available liquidity amount associated with the source crypto asset type, in which the available liquidity amount is initialized to the first contribution amount associated with the source crypto asset type,
an executed quantity associated with the target crypto asset type, and
the limit crypto assets exchange quotient for exchanging the source crypto asset type and the target crypto asset type.
(emphasis added on additional element(s))
Here, the claims are directed to the abstract idea, or combination of abstract ideas, of managing a crypto asset exchange transaction, including liquidity provision and redemption, by specifying a “source crypto asset type,” a “target crypto asset type,” a “first contribution amount,” a “limit crypto assets exchange quotient,” an “available liquidity amount,” and a “redemption amount,” and by determining whether and how crypto assets are exchanged, tracked, and transferred. This concept/abstract idea, which is seen above, falls within the Certain Methods of Organizing Human Activity grouping because it describes a commercial or legal interaction (e.g., asset management) that governs the terms under which parties provide assets, exchange assets, maintain a liquidity position, and redeem value in a decentralized exchange environment, i.e., asset management and exchange of financial value. Accordingly, it is determined that the claims recite an abstract idea since they fall within one or more of the three enumerated categories of patent ineligible subject matter.
Claims 16, 17, and 18 recite the same abstract idea.
Since it is determined that the claim(s) contain a judicial exception, it must then be determined, under Step 2A, Prong 2, whether the judicial exception is integrated into a practical application of the exception. MPEP §2106.04. Here, claim 1 recites the additional elements of: at least one memory, a component collection stored in the at least one memory, a processor, and a smart contract are recited at a high-level of generality such that they amount to no more than using a generic computer component and/or system. This is consistent with how these elements are described in applicant’s specification at paragraphs 0033-0036 and 0257-0258. Therefore, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Looking at the elements as a combination does not add anything more than the elements analyzed individually. Examiner further notes that even though the claims may not preempt all forms of the abstraction, this alone, does not make them any less abstract. See OIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1362-63 (Fed. Cir. 2015).
Under the Step 2B analysis, it is determined whether the recited additional elements amount to something “significantly more” than the recited abstract idea to which the claims are directed (i.e., provide an inventive concept). MPEP §2106.05. As discussed above with respect to integration of the abstract idea into a practical application, the additional element(s) of at least one memory, a component collection stored in the at least one memory, a processor, and a smart contract to implement the abstract idea amounts to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept. That is, simply implementing the abstract idea on a generic computer or merely using a computer as a tool to perform an abstract idea cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Accordingly, taken alone, the additional elements do not amount to significantly more than a judicial exception. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually.
Therefore, independent claim 1 is rejected under 35 U.S.C. §101 and is not patent eligible. Independent claims 16, 17, and 18 are similar and is therefore rejected under 35 U.S.C. §101 also. Dependent claims 2-15 when analyzed are held to be patent ineligible under 35 U.S.C. §101 because the additional recited limitation(s) fail to establish that the claim(s) is/are not directed to an abstract idea.
Dependent claim 2 recites “The apparatus of claim 1, in which the component collection storage is further structured with processor-executable instructions, comprising: update, via at least one processor, source crypto assets balance for the crypto assets liquidity tranche data structure to reflect contribution of the first contribution amount associated with the source crypto asset type.” The claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 3 recites “The apparatus of claim 1, in which the instructions to determine the crypto assets exchange quotient are structured as instructions to query a price oracle.” The claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 4 recites “The apparatus of claim 3, in which the component collection storage is further structured with processor-executable instructions, comprising: 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.” The claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 5 recites “The apparatus of claim 3, in which 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.” The claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 6 recites “The apparatus of claim 1, in which the non-fungible token comprises metadata further structured as specifying an event notification alert API.” The claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 7 recites “The apparatus of claim 1, in which the non-fungible token comprises metadata further structured as specifying the available liquidity amount associated with the source crypto asset type via a displayed liquidity amount and a non-displayed liquidity amount, in which the non-displayed liquidity amount is encrypted.” The claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 8 recites “The apparatus of claim 1, in which the component collection storage is further structured with processor-executable instructions, comprising: obtain, via at least one processor, via the unidirectional decentralized exchange smart contract deployed on the blockchain, a decentralized exchange liquidity redemption initiate transaction structured as specifying: the crypto assets liquidity tranche data structure, an identifier of the non-fungible token specific to the crypto assets liquidity tranche data structure, a first redemption amount associated with the source crypto asset type, and a redemption blockchain address controlled by a sender of the decentralized exchange liquidity redemption initiate transaction; determine, via at least one processor, a timestamp associated with the decentralized exchange liquidity redemption initiate transaction; adjust, via at least one processor, the available liquidity amount associated with the source crypto asset type via a calculation involving the first redemption amount upon determining that a minimum delay threshold rule associated with the decentralized exchange liquidity redemption initiate transaction is satisfied by checking the timestamp associated with the decentralized exchange liquidity redemption initiate transaction with regard to a minimum delay period; obtain, via at least one processor, via the unidirectional decentralized exchange smart contract deployed on the blockchain, a decentralized exchange liquidity redemption confirm transaction corresponding to the decentralized exchange liquidity redemption initiate transaction; calculate, via at least one processor, a second redemption amount associated with the source crypto asset type via a calculation involving: the first redemption amount associated with the source crypto asset type, and the available liquidity amount associated with the source crypto asset type, in which the available liquidity amount specifies a remaining liquidity amount associated with the non-fungible token; and transfer, via at least one processor, the calculated second redemption amount of crypto assets of the source crypto asset type to the provision blockchain address controlled by the sender of the decentralized exchange liquidity redemption initiate transaction.” The claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 9 recites “The apparatus of claim 8, in which the component collection storage is further structured with processor-executable instructions, comprising: update, via at least one processor, crypto assets balances for the crypto assets liquidity tranche data structure to reflect redemption of the second redemption amount associated with the source crypto asset type.” The claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 10 recites “The apparatus of claim 8, in which the first redemption amount is structured as specifying a displayed liquidity redemption amount and a non-displayed liquidity redemption amount.” The claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 11 recites “The apparatus of claim 8, in which the component collection storage is further structured with processor-executable instructions, comprising: obtain, via at least one processor, via the unidirectional decentralized exchange smart contract deployed on the blockchain, a second decentralized exchange liquidity redemption initiate transaction; and update, via at least one processor, the first redemption amount associated with the source crypto asset type to a value specified via the second decentralized exchange liquidity redemption initiate transaction upon determining that a minimum delay threshold rule associated with the decentralized exchange liquidity redemption initiate transaction is not satisfied.” The claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 12 recites “The apparatus of claim 8, in which the component collection storage is further structured with processor-executable instructions, comprising: determine, via at least one processor, that the non-fungible token is fully executed upon determining that the available liquidity amount associated with the source crypto asset type is zero.” The claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 13 recites “The apparatus of claim 12, in which the component collection storage is further structured with processor-executable instructions, comprising: generate, via at least one processor, an execution alert associated with the non-fungible token via an event notification alert API specified via the non-fungible token.” The claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 14 recites “The apparatus of claim 13, in which the event notification alert API is accessed off-chain.” The claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 15 recites “The apparatus of claim 8, in which the component collection storage is further structured with processor-executable instructions, comprising: update, via at least one processor, a derived crypto assets exchange quotient for exchanging the source crypto asset type and the target 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 source crypto asset type and the target crypto asset type upon execution of the decentralized exchange liquidity redemption confirm transaction.” The claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Claim Interpretation
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.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
In claim 17, the phrases “means to store a component collection” and “means to process executable instructions from the component collection” recites a generic placeholder in paragraph 0131. The function of the “means” as described in this paragraph is being interpreted as computer code. Because this claim limitation is being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it is being interpreted to cover only the corresponding structure, material, or acts described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) 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 function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-18 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter (“means to store a component collection” and “means to process executable instructions from the component collection”) which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
For a computer-implemented 35 U.S.C. 112(f) claim limitation, the specification must disclose an algorithm for performing the claimed specific computer function. The corresponding structure is not simply a general-purpose computer by itself but the special purpose computer as programmed to perform the disclosed algorithm. Thus, the specification must sufficiently disclose an algorithm to transform a general-purpose microprocessor to the special purpose computer. Because applicant’s specification does not clearly link the corresponding structure, i.e., the algorithm, for performing the functions associated with the elements that invoke 112(f), the originally filed disclosure does not show that applicant had possession of the claimed invention at the time the application was filed.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1-18 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particular point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Claim 17 recites the following limitations: “means to store a component collection” and “means to process executable instructions from the component collection”
Claim limitation 17 invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function.
A “mean” is configured as a machine or program that processes something. For a computer-implemented 35 U.S.C. 112(f) claim limitation, the specification must disclose an algorithm for performing the claimed specific computer function. The corresponding structure is not simply a general-purpose computer by itself but the special purpose computer as programmed to perform the disclosed algorithm. Thus, the specification must sufficiently disclose an algorithm to transform a general-purpose microprocessor to the special purpose computer. Because applicant’s specification does not clearly link the corresponding structure, i.e., the algorithm, for performing the functions associated with the elements that invoke 112(f), these elements are unbounded, purely functional, and indefinite.
Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
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.
The factual inquires set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1066), that are applied for establishing a background for determining obviousness under 35 U.S.C. § 103 are summarized as follows:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Fantini et al. (US20230141423A1) hereinafter Fantini, in view of Ingargiola (US20210073913A1), in further view of Leshner et al. (US20210065302A1) hereinafter Leshner, and in further view of Osborn et al. (US20230298016A1) hereinafter Osborn.
Regarding Claims 1, 16, 17, and 18. Fantini teaches (in BOLD): A unidirectional decentralized exchange apparatus, comprising: at least one memory; means to store 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, processor-readable, non-transient medium, the medium storing a component collection, the component collection storage structured with processor-executable instructions:
Fantini - 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 or 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 (¶ 0035).
obtain, via at least one processor, via a unidirectional 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 unidirectional decentralized exchange smart contract,
Fantini – […] 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 (Uniswap V3, for example) on behalf of the trader/user 109 for the trade/swap (¶ 0052).
a first contribution amount associated with a source crypto asset type,
Fantini - 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 (¶ 0049).
a target crypto asset type,
Fantini - FIGS. 7A-7B illustrate non-limiting exemplary screenshots of the user interface for entering a target price for a selected digital asset and initiating approval process for the same in accordance with an embodiment of the present invention (¶ 0026).
a limit crypto assets exchange quotient for exchanging the source crypto asset type and the target crypto asset type, and
Fantini - 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 ). 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 (¶ 0053).
determine, via at least one processor, a crypto assets exchange quotient for exchanging the source crypto asset type and the target crypto asset type;
Fantini - 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 ). 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. Each of the one or more price feeds is a block on the blockchain network corresponding to a price feed update transaction on a price of the second digital asset with respect to the first digital asset and their real-time monitoring is continued until the trade is filled i.e. the limit order is completely filled by swapping all of the first digital asset for the second digital asset. The smart contract deployed by the zero-impact trade service computer system 102 registers/recognizes/defines the first digital wallet i.e. the digital wallet associated with the first digital asset as the liquidity provider for this trade, and, hence, the applicable liquidity provider fee debited from the second digital wallet associated with the second digital asset is credited to the first digital wallet of the user 109 (¶ 0053).
execute, via at least one processor, an imbalance rule check for the crypto assets liquidity tranche data structure, in which the imbalance rule check is executed via a calculation involving: a first total amount of crypto assets of the source crypto asset type locked in the crypto assets liquidity tranche data structure;
Fantini - 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 ). 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. Each of the one or more price feeds is a block on the blockchain network corresponding to a price feed update transaction on a price of the second digital asset with respect to the first digital asset and their real-time monitoring is continued until the trade is filled i.e. the limit order is completely filled by swapping all of the first digital asset for the second digital asset. The smart contract deployed by the zero-impact trade service computer system 102 registers/recognizes/defines the first digital wallet i.e. the digital wallet associated with the first digital asset as the liquidity provider for this trade, and, hence, the applicable liquidity provider fee debited from the second digital wallet associated with the second digital asset is credited to the first digital wallet of the user 109 (¶ 0053).
a second total amount of crypto assets of the target crypto asset type locked in the crypto assets liquidity tranche data structure;
Fantini - FIGS. 5A-5B illustrate non-limiting exemplary screenshots of Graphical User Interface (GUI) or user interface provided by the present invention which allow a user to select a first digital asset and enter a desired amount/quantity of the first digital asset for transaction in accordance with an embodiment of the present invention (¶ 0024). For this, the zero-impact limit trade service computer system 102 interacts with the digital wallet system 115 of FIG. 1 . 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 . As depicted in exemplary screenshot 604 of the user interface in FIG. 6B, the user 109 is offered a number of digital asset options to select from for the swap. In the present example, digital asset “CIV”, indicated by 608, has been selected by the user 109 for the swap (¶ 0049).
the crypto assets exchange quotient, and
Claim interpretation: 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 - A decentralized exchange (DEX) is a cryptocurrency exchange which allows for direct peer-to-peer cryptocurrency transactions to take place online securely and without the need for an intermediary. Trading occurs directly from the traders' wallets through smart contracts. Decentralized exchanges offer almost all and similar trading services that a centralized exchange can offer. Many decentralized exchanges offer a service known as token swap that allow users to buy and sell cryptocurrencies for traditional currencies or for other cryptocurrencies. However, due to the insufficient liquidity, swapping may not be possible sometimes. Also, such a situation may induce price impact which affects the trade over the market price of the underlying tokens. Price impact will be high when liquidity is low for a particular token pair. Then there is slippage which occurs when traders have to settle for a different price than what they initially requested due to a movement in price between the time the order enters the market and the execution of a trade. Another grave issue plaguing the decentralized exchanges is Front Running which is the act of placing a transaction in a queue with the knowledge of a future transaction. These kinds of problems associated with decentralized exchanges make execution of true Limit Orders a challenge (¶ 0004) and (Fig. 4, 9A-9B).
the first contribution amount associated with the source crypto asset type; and
Fantini - 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 . As depicted in exemplary screenshot 604 of the user interface in FIG. 6B, the user 109 is offered a number of digital asset options to select from for the swap. In the present example, digital asset “CIV”, indicated by 608, has been selected by the user 109 for the swap (¶ 0049). The smart contract deployed by the zero-impact trade service computer system 102 registers/recognizes/defines the first digital wallet i.e. the digital wallet associated with the first digital asset as the liquidity provider for this trade, and, hence, the applicable liquidity provider fee debited from the second digital wallet associated with the second digital asset is credited to the first digital wallet of the user 109 (¶ 0053).
mint, via at least one processor, a non-fungible token specific to the crypto assets liquidity tranche data structure, in which the non-fungible token is associated with the provision blockchain address controlled by the sender of the decentralized exchange liquidity provision transaction, and in which the non-fungible token comprises metadata structured as specifying: an available liquidity amount associated with the source crypto asset type, in which the available liquidity amount is initialized to the first contribution amount associated with the source crypto asset type,
Fantini - 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. Each of the one or more price feeds is a block on the blockchain network corresponding to a price feed update transaction on a price of the second digital asset with respect to the first digital asset and their real-time monitoring is continued until the trade is filled i.e. the limit order is completely filled by swapping all of the first digital asset for the second digital asset. The smart contract deployed by the zero-impact trade service computer system 102 registers/recognizes/defines the first digital wallet i.e. the digital wallet associated with the first digital asset as the liquidity provider for this trade, and, hence, the applicable liquidity provider fee debited from the second digital wallet associated with the second digital asset is credited to the first digital wallet of the user 109 (¶ 0053).
an executed quantity associated with the target crypto asset type, and
Fantini - 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. Each of the one or more price feeds is a block on the blockchain network corresponding to a price feed update transaction on a price of the second digital asset with respect to the first digital asset and their real-time monitoring is continued until the trade is filled i.e. the limit order is completely filled by swapping all of the first digital asset for the second digital asset (¶ 0053).
the limit crypto assets exchange quotient for exchanging the source crypto asset type and the target crypto asset type.
Fantini - A system for execution of limit trades on decentralized exchanges comprising a computer service system configured for receiving from a client device a limit order for swapping a desired quantity of a first digital asset for a second digital asset at a desired target price. A smart contract on a blockchain network is then generated corresponding to the order. By depositing the desired quantity of the first digital asset the smart contracts creates a single-sided liquidity pool on the blockchain network. For real-time monitoring of price feeds the smart contract interacts with a decentralized oracle system. On finding one or more matches for the swapping at said target price the position is filled using liquidity pool. User receives the exact number of the second digital asset which the user wanted at the target price in exchange of the first digital asset without any price impact, liquidity fee or slippage (Abstract).
Fantini does not teach, however, Ingargiola discloses:
a provision blockchain address controlled by a sender of the decentralized exchange liquidity provision transaction;
Ingargiola - 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 (¶ 0215).
Therefore, it would have been obvious to one of ordinary skill in that art before the effective filing date of the claimed invention to combine a system for execution of trades on a decentralized system of Fantini with a step for providing an address controlled by a sender of Ingargiola because doing so provides more security for the transaction.
The combination of Fantini and Ingargiola does not disclose, however Leshner discloses the following (in BOLD):
mint, via at least one processor, a non-fungible token specific to the crypto assets liquidity tranche data structure, in which the non-fungible token is associated with the provision blockchain address controlled by the sender of the decentralized exchange liquidity provision transaction, and in which the non-fungible token comprises metadata structured as specifying: an available liquidity amount associated with the source crypto asset type, in which the available liquidity amount is initialized to the first contribution amount associated with the source crypto asset type,
Leshner - A mint operation by an account may transfer an underlying digital asset from the account into the pool and accordingly update the account's digital token balance. The underlying digital asset may be specified by a reference, such as an amount of the underlying digital asset. The account's digital token balance may be increased based on the underlying digital asset and the exchange rate (¶ 0040).
Therefore, it would have been obvious to one of ordinary skill in that art before the effective filing date of the claimed invention to combine a system for execution of trades on a decentralized system of Fantini with a step for providing an address controlled by a sender of Ingargiola with the minting of Leshner because doing so provides the most update information in the transaction.
The combination of Fantini, Ingargiola, and Leshner does not disclose, however Osborn discloses the following (in BOLD):
mint, via at least one processor, a non-fungible token specific to the crypto assets liquidity tranche data structure, in which the non-fungible token is associated with the provision blockchain address controlled by the sender of the decentralized exchange liquidity provision transaction, and in which the non-fungible token comprises metadata structured as specifying: an available liquidity amount associated with the source crypto asset type, in which the available liquidity amount is initialized to the first contribution amount associated with the source crypto asset type,
Osborn - a non-fungible token (NFT) (¶ 0043).
Therefore, it would have been obvious to one of ordinary skill in that art before the effective filing date of the claimed invention to combine a system for execution of trades on a decentralized system of Fantini with a step for providing an address controlled by a sender of Ingargiola and the minting of Leshner the non-fungible token of Osborn because doing so provides the most update information including current ownership and provides more security for the transaction.
Regarding Claim 2. The combination of Fantini, Ingargiola, Leshner, and Osborn further discloses: the apparatus of claim 1, in which the component collection storage is further structured with processor-executable instructions, comprising: update, via at least one processor, source crypto assets balance for the crypto assets liquidity tranche data structure to reflect contribution of the first contribution amount associated with the source crypto asset type.
Fantini - Each of the one or more price feeds is a block on the blockchain network corresponding to a price feed update transaction on a price of the second digital asset with respect to the first digital asset and their real-time monitoring is continued until the trade is filled i.e. the limit order is completely filled by swapping all of the first digital asset for the second digital asset. The smart contract deployed by the zero-impact trade service computer system 102 registers/recognizes/defines the first digital wallet i.e. the digital wallet associated with the first digital asset as the liquidity provider for this trade, and, hence, the applicable liquidity provider fee debited from the second digital wallet associated with the second digital asset is credited to the first digital wallet of the user 109 (¶ 0053).
Regarding Claim 3. The combination of Fantini, Ingargiola, Leshner, and Osborn further discloses: the apparatus of claim 1, in which the instructions to determine the crypto assets exchange quotient are structured as instructions to query a price oracle.
Fantini - 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. (¶ 0052).
Regarding Claim 4. The combination of Fantini, Ingargiola, Leshner, and Osborn further discloses: the apparatus of claim 3 in which the component collection storage is further structured with processor-executable instructions, comprising: 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.
Osborn - 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 service (¶ 0077). 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 (¶ 0078).
Therefore, it would have been obvious to one of ordinary skill in that art before the effective filing date of the claimed invention to combine a system for execution of trades on a decentralized system of Fantini with a step for providing an address controlled by a sender of Ingargiola and the minting of Leshner the non-fungible token of Osborn because doing so provides the most update information including current ownership and provides more security for the transaction with confidence.
Regarding Claim 5. The combination of Fantini, Ingargiola, Leshner, and Osborn further discloses the apparatus of claim 3 in which 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.
Leshner - 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 (¶ 0048).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine a system for execution of trades on a decentralized system of Fantini with a step for providing an address controlled by a sender of Ingargiola and the minting of Leshner because doing so provides the most timely information for an accurate asset exchange transaction.
Regarding Claim 6. The combination of Fantini, Ingargiola, Leshner, and Osborn further discloses: the apparatus of claim 1 in which the non-fungible token comprises metadata further structured as specifying an event notification alert API.
Osborn - While a machine learning model 230 is used in the examples described and illustrated herein, one or more databases could also be used that include correlations of blockchain addresses with transaction context data and/or distributions, for example. In yet other examples, records of definitive fact (e.g., address/legal entity association, verified fraud report, etc.) can be recorded into the blockchain hosted by the blockchain network 104 as a non-fungible token (NFT), owned by a service hosting the oracle device 110, but available to be queried by the public, for example. The NFTs can be recorded for blockchain addresses confirmed with certainty to be fraudulent or to correspond with a particular identifier (e.g., retailer name). Other types of data structures and methods for facilitating analysis of the validity of blockchain addresses can also be used (¶ 0043). By way of example only, the transaction context data can be received from the wallet application 112 in this example via an API provided by the oracle device 110, but the transaction context data could be received from other sources, including the smart contract 114 as described and illustrated in detail below, in other examples (¶ 0047). In block 504, the blockchain node 106(n) may send a query with the transaction context data to the oracle device 110. The query can be the same or similar to the request sent by the wallet application 112 as explained above with reference to block 402 of FIG. 4 . In this example, the smart contract 114 can be configured to automatically send the query at a predefined time and to an endpoint associated with an API made available by the oracle device 110, for example (¶0059). In block 602, the oracle device 110 may receive from the blockchain node 106(n) executing the smart contract 114 transaction context data associated with an asset transfer and including at least a destination address. The transaction context data can be received via a query from the blockchain node 106(n) to an API provided by the oracle device 110, for example, as described above with reference to block 502 of FIG. 5 (¶ 0065).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the exchange quotient (trade swap) of Fantini and a step for an oracle and the security of Igargiola and minting of Leshner with the time of Osborn because do so provides a confidence measure based on a threshold.
Regarding Claim 7. The combination of Fantini, Ingargiola, Leshner, and Osborn further discloses: the apparatus of claim 1, in which the non-fungible token comprises metadata further structured as specifying the available liquidity amount associated with the source crypto asset type via a displayed liquidity amount and a non-displayed liquidity amount, in which the non-displayed liquidity amount is encrypted.
Fantini - 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. (¶ 0052).
Regarding Claim 8. The combination of Fantini, Ingargiola, Leshner, and Osborn further discloses: the apparatus of claim 1, in which the component collection storage is further structured with processor-executable instructions, comprising: obtain, via at least one processor, via the unidirectional decentralized exchange smart contract deployed on the blockchain, a decentralized exchange liquidity redemption initiate transaction structured as specifying: the crypto assets liquidity tranche data structure,
Fantini - The smart contract automatically opens a custom made one-sided liquidity pool in the decentralized exchange (Uniswap V3, for example) on behalf of the trader/user 109 for the trade/swap. This step is shown in block 304 of FIG. 3 . This single-sided/one-sided liquidity pool, opened with a narrow range defined around the target price of the limit order, does not let any price impact on the trade i.e. the user receives the exact number of the purchased digital asset (second digital asset) at the set target price which the user defines for the sold digital asset (first digital asset). In the present example, the user wants to swap ETH (first digital asset) for CIV (second digital asset) i.e. buy CIV token using ETH token. So, the user deposits only the first digital asset ETH by approving on his/her digital wallet (first digital wallet) and the single-sided liquidity pool is created by depositing only this first digital asset ETH to the liquidity pool (¶ 0052).
an identifier of the non-fungible token specific to the crypto assets liquidity tranche data structure,
Osborn - The wallet application 112 can provide an interface for a user to input transaction context data regarding a transfer (e.g., payment) of digital assets hosted by the wallet application 112 to a third party, such as an identifier (e g, name) of the third party and a destination blockchain address in the blockchain network 104 and associated with the third party, for example. The wallet application 112 is also configured to communicate the obtained transaction context data or a portion thereof to the oracle device 110 and obtain an indication (e.g., confidence score) of the validity of the proposed transaction in response, which can be output to inform the user regarding whether the proposed transaction should proceed (¶ 0025).
Therefore, it would have been obvious to one of ordinary skill in that art before the effective filing date of the claimed invention to combine a system for execution of trades on a decentralized system of Fantini with a step for providing an address controlled by a sender of Ingargiola and the minting of Leshner the non-fungible token of Osborn because doing so provides the most update information including current ownership and provides more security for the transaction.
a first redemption amount associated with the source crypto asset type, and
Fantini - A decentralized exchange (DEX) is a cryptocurrency exchange which allows for direct peer-to-peer cryptocurrency transactions to take place online securely and without the need for an intermediary. Trading occurs directly from the traders' wallets through smart contracts. Decentralized exchanges offer almost all and similar trading services that a centralized exchange can offer. Many decentralized exchanges offer a service known as token swap that allow users to buy and sell cryptocurrencies for traditional currencies or for other cryptocurrencies. However, due to the insufficient liquidity, swapping may not be possible sometimes. Also, such a situation may induce price impact which affects the trade over the market price of the underlying tokens. Price impact will be high when liquidity is low for a particular token pair. Then there is slippage which occurs when traders have to settle for a different price than what they initially requested due to a movement in price between the time the order enters the market and the execution of a trade. Another grave issue plaguing the decentralized exchanges is Front Running which is the act of placing a transaction in a queue with the knowledge of a future transaction. These kinds of problems associated with decentralized exchanges make execution of true Limit Orders a challenge (¶ 0004).
a redemption blockchain address controlled by a sender of the decentralized exchange liquidity redemption initiate transaction;
Fantini - Reference to FIG. 1 , the system 100, for optimizing cost of digital asset trade execution on decentralized exchange platforms, in accordance with an embodiment of the present invention is configured to operate as part of a blockchain infrastructure 110. The blockchain infrastructure 110 may include a publicly managed (permissionless) blockchain infrastructure/network (such as Ethereum or the like) or a privately managed (permissioned) infrastructure/network (e.g., a blockchain managed by an organization). Blockchain infrastructure/network 110 may be accessible to zero-impact limit trade service computer system 102, decentralized exchange 106, client device 115 and other computers over the network 140. In one embodiment, blockchain infrastructure 110 is implemented by a plurality of computer servers or nodes 111 that implement a predefined, distributed protocol, such that no single computer or small group of computers may gain control over the blockchain infrastructure 111. Thus, the blockchain infrastructure 110 commonly includes predefined behavior according to a known protocol without control by any central authority. In some implementations, each of the nodes 111 may be configured to mine and thereby validate transactions submitted to the blockchain infrastructure 110. The zero-impact limit trade service computer system 102 and the client device 104 may be configured to execute transactions on the blockchain infrastructure 110. As is further discussed below, the transactions may include placing of limit orders, selling of a digital asset and buying of a digital assets etc ( 0034).
determine, via at least one processor, a timestamp associated with the decentralized exchange liquidity redemption initiate transaction;
Leshner - Transactions 132 may include records of transactions for pool 130. For example, in a blockchain environment, each transaction may form a basis for a new block. Datum, such as accounts 134, last update 140, reserves balance 142, borrowing balance 144, cash balance 146, and/or interest model 148, may be updated and stored. Last update 140 may include a timestamp corresponding to the last time of updating one or more datum as described herein. Interest model 148 may correspond to internally used values, including various index values such as an automatically updated interest rate and other transaction rates, as will be described further below (¶ 0065).
Therefore, it would have been obvious to one of ordinary skill in that art before the effective filing date of the claimed invention to combine a system for execution of trades on a decentralized system of Fantini with a step for providing an address controlled by a sender of Ingargiola and the minting of Leshner the non-fungible token of Osborn because doing so provides the most update information including current ownership and provides more security for the transaction.
adjust, via at least one processor, the available liquidity amount associated with the source crypto asset type via a calculation involving the first redemption amount upon determining that a minimum delay threshold rule associated with the decentralized exchange liquidity redemption initiate transaction is satisfied by checking the timestamp associated with the decentralized exchange liquidity redemption initiate transaction with regard to a minimum delay period;
Ingargiola - The value of the digital representation of collateral on deposit at the custodian 520 in the name of the client 508 is visible to network services of 530/532 and displayed in custodian 520, client 508 and network operator UI/ API 502, 518 and 534. As transactions are created or received as managed by the network operator 532, balances are calculated in real-time and maintained in memory and in one aspect, also persisted to disk. “Persistence” can be writing directly to the file system, or a database, or a cryptographic database. Balances can also be computed in real time from a state on blockchain ledgers and may involve real-time enrichment/adjustments to state such as “earmarking” assets as used when a redemption request is pending even though no blockchain transaction for the redeem has taken place yet. The same can apply for a pending order not yet filled. This prevents the failure of the transaction on the second collateral verification check in the atomic swap process and prevents a bad user experience or lost opportunity (¶ 0145).
Therefore, it would have been obvious to one of ordinary skill in that art before the effective filing date of the claimed invention to combine a system for execution of trades on a decentralized system of Fantini with a step for providing an address controlled by a sender of Ingargiola and the minting of Leshner the non-fungible token of Osborn because doing so provides the most update information including current ownership and provides more security for the transaction.
obtain, via at least one processor, via the unidirectional decentralized exchange smart contract deployed on the blockchain, a decentralized exchange liquidity redemption confirm transaction corresponding to the decentralized exchange liquidity redemption initiate transaction;
Fantini - 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 ). 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 (¶ 0053).
calculate, via at least one processor, a second redemption amount associated with the source crypto asset type via a calculation involving: the first redemption amount associated with the source crypto asset type, and
Ingargiola - The method can further include a redemption process in which the first client (who now owns the second asset type) or the second client (who now owns the first asset type) can receive actual dollars or bitcoin (or other instrument of value), which can be moved from an account or wallet held by the custodian to the new owner after the trade. At the time of redemption, a respective token can be transferred to a burn account or burn wallet to update the respective ledger appropriately. The burn account can also be to the custodian's public key address (¶ 0074).
Therefore, it would have been obvious to one of ordinary skill in that art before the effective filing date of the claimed invention to combine a system for execution of trades on a decentralized system of Fantini with a step for providing an address controlled by a sender of Ingargiola and the minting of Leshner the non-fungible token of Osborn because doing so provides the most update information including current ownership and provides more security for the transaction.
the available liquidity amount associated with the source crypto asset type, in which the available liquidity amount specifies a remaining liquidity amount associated with the non-fungible token; and
Fantini - The digital asset trading module 116 handles the processes for limit trade execution. The blockchain module 118 communicatively interfaces the zero-impact limit trade service system 102 with other blockchain participating nodes and client devices so as to enable the zero-impact limit trade service computer system 102 to participate in the available blockchain protocols by acting as a blockchain protocol compliant node. This permits the zero-impact limit trade service computer system 102 to provide blockchain services to the other participating nodes and client devices. In example embodiments, the blockchain module 118 may include instructions executable by the processor(s) 130 to cooperate with one or more blockchain nodes/client devices/decentralized exchanges/decentralized oracle systems for execution of zero-impact limit trade. The instructions may also enable the processor(s) 130 to generate the smart contract(s) that are incorporated on the blockchain 110 with respect to the execution of zero-impact trade limit (¶ 0037).
transfer, via at least one processor, the calculated second redemption amount of crypto assets of the source crypto asset type to the provision blockchain address controlled by the sender of the decentralized exchange liquidity redemption initiate transaction.
Fantini - Reference to FIG. 1 , the system 100, for optimizing cost of digital asset trade execution on decentralized exchange platforms, in accordance with an embodiment of the present invention is configured to operate as part of a blockchain infrastructure 110. The blockchain infrastructure 110 may include a publicly managed (permissionless) blockchain infrastructure/network (such as Ethereum or the like) or a privately managed (permissioned) infrastructure/network (e.g., a blockchain managed by an organization). Blockchain infrastructure/network 110 may be accessible to zero-impact limit trade service computer system 102, decentralized exchange 106, client device 115 and other computers over the network 140. In one embodiment, blockchain infrastructure 110 is implemented by a plurality of computer servers or nodes 111 that implement a predefined, distributed protocol, such that no single computer or small group of computers may gain control over the blockchain infrastructure 111. Thus, the blockchain infrastructure 110 commonly includes predefined behavior according to a known protocol without control by any central authority. In some implementations, each of the nodes 111 may be configured to mine and thereby validate transactions submitted to the blockchain infrastructure 110. The zero-impact limit trade service computer system 102 and the client device 104 may be configured to execute transactions on the blockchain infrastructure 110. As is further discussed below, the transactions may include placing of limit orders, selling of a digital asset and buying of a digital assets etc (¶ 0034).
Regarding Claim 9. The combination of Fantini, Ingargiola, Leshner, and Osborn further discloses: the apparatus of claim 8, in which the component collection storage is further structured with processor-executable instructions, comprising: update, via at least one processor, crypto assets balances for the crypto assets liquidity tranche data structure to reflect redemption of the second redemption amount associated with the source crypto asset type.
Fantini - Each of the one or more price feeds is a block on the blockchain network corresponding to a price feed update transaction on a price of the second digital asset with respect to the first digital asset and their real-time monitoring is continued until the trade is filled i.e. the limit order is completely filled by swapping all of the first digital asset for the second digital asset. The smart contract deployed by the zero-impact trade service computer system 102 registers/recognizes/defines the first digital wallet i.e. the digital wallet associated with the first digital asset as the liquidity provider for this trade, and, hence, the applicable liquidity provider fee debited from the second digital wallet associated with the second digital asset is credited to the first digital wallet of the user 109 (¶ 0053).
Regarding Claim 10. The combination of Fantini, Ingargiola, Leshner, and Osborn further discloses: the apparatus of claim 8, in which the first redemption amount is structured as specifying a displayed liquidity redemption amount and a non-displayed liquidity redemption amount.
Fantini - FIG. 11 shows an enlarged view 1100 of the order book 1004 of FIG. 10 with an exemplary pair of tokens/digital assets different from that is shown in order book 1004. The order book 1004 or 1100 comprises real time details of limit orders such as one or more order parameters including a value of the token/digital asset (second digital asset) to be bought in fiat currency and/or in terms of the token/digital asset (first digital asset) to be sold, and a value of the limit orders in fiat money. For example, it shows the second digital asset (e.g. WBTC) at each price level assuming a constant fiat (USD) value of the other token i.e. first digital asset (e.g. WETH) at its current market value. The displayed data can be spaced across price levels based on user-defined ranges, e.g. 1% to show WBTC/WETH prices in 1% increments, summing all ticks around that price point e.g. of 0.067 WBTC per WETH+/−0.5%. The limit order book of the present invention maintains a live record of the limit orders and displays their changes in real-time. For this, the smart contract deployed by the present invention updates the data in specific intervals (in every 15 seconds, for example) to let at least one new block to be mined by the blockchain network 110 (¶ 0056).
Regarding Claim 11. The combination of Fantini, Ingargiola, Leshner, and Osborn further discloses: the apparatus of claim 8, in which the component collection storage is further structured with processor-executable instructions, comprising: obtain, via at least one processor, via the unidirectional decentralized exchange smart contract deployed on the blockchain, a second decentralized exchange liquidity redemption initiate transaction; and
Fantini - The blockchain module 118 is configured to generate smart contracts as transaction blocks on a blockchain network via a high-level application and programming language (Solidity, for example) which can be deployed to the blockchain for execution by zero-impact limit trade service computer system 102 using a virtual machine deployed in conjunction with the blockchain 110. The smart contracts may comprise self-executing instructions, which are guaranteed to occur according to their specification (e.g., code) by implementation on the blockchain 110 and execution by zero-impact limit trade service computer system 102 without requiring an external authority. In the context of both permissioned and permissionless blockchains, the term smart contract is often used to refer to software programs that run on a blockchain. The smart contracts include executable codes which are registered, stored, and/or replicated on the blockchain 110. A transaction is an execution of the smart contract code which can be performed in response to conditions associated with the smart contract being satisfied. In the context of the present invention, the code of the smart contract acts as a programmatically defined autonomous agent for zero-impact limit trade execution with its own persistent variables that get executed within the blockchain when the smart contract is referenced by a message and/or a transaction. Any modification to the blockchain ledger caused by the smart contract execution may be automatically replicated throughout the blockchain peers using one or more consensus protocols (¶ 0038).
update, via at least one processor, the first redemption amount associated with the source crypto asset type to a value specified via the second decentralized exchange liquidity redemption initiate transaction upon determining that a minimum delay threshold rule associated with the decentralized exchange liquidity redemption initiate transaction is not satisfied.
Fantini - Every such transaction is broadcasted to the blockchain network 110. Each of the one or more price feeds is a block on the blockchain network corresponding to a price feed update transaction on a price of the second digital asset with respect to the first digital asset and their real-time monitoring is continued until the trade is filled i.e. the limit order is completely filled by swapping all of the first digital asset for the second digital asset. The smart contract deployed by the zero-impact trade service computer system 102 registers/recognizes/defines the first digital wallet i.e. the digital wallet associated with the first digital asset as the liquidity provider for this trade, and, hence, the applicable liquidity provider fee debited from the second digital wallet associated with the second digital asset is credited to the first digital wallet of the user 109 (¶ 0053).
Regarding Claim 12. The combination of Fantini, Ingargiola, Leshner, and Osborn further discloses: the apparatus of claim 8, in which the component collection storage is further structured with processor-executable instructions, comprising: determine, via at least one processor, that the non-fungible token is fully executed upon determining that the available liquidity amount associated with the source crypto asset type is zero.
Fantini - 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 ). 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 (¶ 0053).
Regarding Claim 13. The combination of Fantini, Ingargiola, Leshner, and Osborn further discloses: the apparatus of claim 12, in which the component collection storage is further structured with processor-executable instructions, comprising: generate, via at least one processor, an execution alert associated with the non-fungible token via an event notification alert API specified via the non-fungible token.
Ingargiola - The custodian module can be hosted directly by the sponsoring firm and communicate with the core system through application programming interface (“API”) calls. The custodian module can also be hosted by the same entity operating the core system, thus enabling the sponsoring firm to perform all applicable functions through a web portal accessed through a multi-factor authentication process. Blockchain nodes can be configured as part of the custodian module and the governing node or core system (¶ 0062).
Therefore, it would have been obvious to one of ordinary skill in that art before the effective filing date of the claimed invention to combine a system for execution of trades on a decentralized system of Fantini with a step for providing an address controlled by a sender of Ingargiola and the minting of Leshner the non-fungible token of Osborn because doing so provides the most update information including current ownership and provides more security for the transaction.
Regarding Claim 14. The combination of Fantini, Ingargiola, Leshner, and Osborn further discloses: the apparatus of claim 13, in which the event notification alert API is accessed off-chain.
Osborn- In some examples, the oracle device 110 can query external sources (e.g., databases or servers accessible via API) to obtain address identity verification data from exchanges (e.g., a particular blockchain address has been authenticated or confirmed to belong to an identified retailer or fraud has been reported with respect to a blockchain address). As another example, the external source data can be obtained via web scraping, which can yield information such as an indication that an identified retailer is advertised on a commercial website as associated with a particular blockchain address, for example. By being hosted external to the blockchain network 104, the oracle device 110 can advantageously access external source data as well as public blockchain data, which can facilitate a more robust machine learning model 230 (¶ 0039).
Therefore, it would have been obvious to one of ordinary skill in that art before the effective filing date of the claimed invention to combine a system for execution of trades on a decentralized system of Fantini with a step for providing an address controlled by a sender of Ingargiola and the minting of Leshner the non-fungible token of Osborn because doing so provides the most update information including current ownership and provides more security for the transaction.
Regarding Claim 15. The combination of Fantini, Ingargiola, Leshner, and Osborn further discloses: the apparatus of claim 8, in which the component collection storage is further structured with processor-executable instructions, comprising: update, via at least one processor, a derived crypto assets exchange quotient for exchanging the source crypto asset type and the target crypto asset type upon execution of the decentralized exchange liquidity provision transaction; and
Fantini - A system for execution of limit trades on decentralized exchanges comprising a computer service system configured for receiving from a client device a limit order for swapping a desired quantity of a first digital asset for a second digital asset at a desired target price. A smart contract on a blockchain network is then generated corresponding to the order. By depositing the desired quantity of the first digital asset the smart contracts creates a single-sided liquidity pool on the blockchain network. For real-time monitoring of price feeds the smart contract interacts with a decentralized oracle system. On finding one or more matches for the swapping at said target price the position is filled using liquidity pool. User receives the exact number of the second digital asset which the user wanted at the target price in exchange of the first digital asset without any price impact, liquidity fee or slippage (Abstract).
update, via at least one processor, the derived crypto assets exchange quotient for exchanging the source crypto asset type and the target crypto asset type upon execution of the decentralized exchange liquidity redemption confirm transaction.
Fantini - Every such transaction is broadcasted to the blockchain network 110. Each of the one or more price feeds is a block on the blockchain network corresponding to a price feed update transaction on a price of the second digital asset with respect to the first digital asset and their real-time monitoring is continued until the trade is filled i.e. the limit order is completely filled by swapping all of the first digital asset for the second digital asset. The smart contract deployed by the zero-impact trade service computer system 102 registers/recognizes/defines the first digital wallet i.e. the digital wallet associated with the first digital asset as the liquidity provider for this trade, and, hence, the applicable liquidity provider fee debited from the second digital wallet associated with the second digital asset is credited to the first digital wallet of the user 109 (¶ 0053).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
McNamara et al. (US10902416B1) - A computing system can facilitate cross-medium transactions through use of a digital currency. The computing system can provide a guaranteed exchange rate and manage customer pools and/or slippage balances in digital wallets to adjust digital currency transfer amounts in order to align them with the guaranteed exchange rate.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTINA C STEVENSON whose telephone number is (571)270-7280 and whose email address is christina.mention@uspto.gov. The examiner can normally be reached M-F 8am-5pm.
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.
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, Patrick McAtee can be reached on (571) 272-7575. 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.
/C.C.S./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights