DETAILED ACTION
The present application, filed on 12/19/2023 is being examined under the AIA first inventor to file provisions.
The following is a FINAL Office Action in response to Applicant’s amendments filed on 4/14/2026.
a. Claims 1, 9, 17, 24 are amended
b. Claims 2, 10, 16, 18, 20-21 are cancelled
c. Claims 24-26 are new
Overall, claims 1, 3-9, 11-15, 17, 19, 22-26 are pending and have been considered below.
Claim Rejections - 35 USC § 101
35 USC 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, 3-9, 11-15, 17, 19, 22-26 are rejected under 35 USC 101 because the claimed invention is not directed to patent eligible subject matter. The claimed matter is directed to a judicial exception, i.e. an abstract idea, not integrated into a practical application, and without significantly more.
Per Step 1 of the multi-step eligibility analysis, claims 1, 3-8, 21-24 are directed to a computer implemented method, claims 9, 11-16 are directed to a system, and claims 17, 19 are directed to computer executable instructions stored on a non-transitory storage medium.
Thus, on its face, each independent claim and the associated dependent claims are directed to a statutory category of invention.
[INDEPENDENT CLAIMS]
Per Step 2A.1. Independent claim 1, (which is representative of independent claims 9, 17) is rejected under 35 USC 101 because the independent claim is directed to an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application.
The limitations of the independent claim 1 (which is representative of independent claims 9, 17) recite an abstract idea, shown in bold below:
[A] A method for crypto token management:
[B] receiving a first amount of fiat to be associated with a fiat wallet of a user profile at a custodial token platform;
[C] displaying, at a graphical user interface of the custodial token platform, a user interface page that displays a fiat amount corresponding to the first amount, a stablecoin amount corresponding to a second amount of stablecoin associated with a stablecoin wallet of the user profile, and a selectable option to convert fiat amounts associated with the user profile to stablecoin;
wherein the fiat wallet is not associated with a blockchain address and is not operable to perform cryptographic operations on a blockchain network, and
wherein the stablecoin wallet is associated with a public key and a private key enabling cryptographic operations via the blockchain network;
[D] receiving, at the custodial token platform, via the graphical user interface, a user input indicating selection of the selectable option;
[E] converting, after receiving the user input, the fiat amount to the stablecoin such that the converted fiat amount is associated with the stablecoin wallet of the user profile;
[F] displaying, at the graphical user interface, an updated user interface page that displays the stablecoin amount without displaying the fiat amount, wherein the stablecoin amount is updated to include the converted fiat amount.
[G] receiving, while the selectable option is selected, a third amount of fiat to be associated with the user profile at the custodial token platform;
[H] converting, automatically based at least in part on the selectable option being selected, the third amount of fiat to the stablecoin; and
[I] displaying, at the graphical user interface, the stablecoin amount that is updated to include the converted third amount of fiat.
Independent claim 1 (which is representative of independent claims 9, 16) recites: enabling an amount ([D]); converting the amount to digital currency ([E]); displaying the digital currency amount, without displaying the fiat amount ([F]), receiving and converting a third amount of stablecoin ([G], [H]) and displaying the updated stablecoin amount ([I]), which, based on the claim language and in view of the application disclosure, represents a process aimed at: “converting fiat currency into digital currency and vice versa, and displaying the updated amount and displaying the updated amount”.
This is a combination that, under its broadest reasonable interpretation, covers sales activities or behaviors, business relationships (e-commerce) which falls under Certain Methods of Organizing Human Activity, i.e., Commercial or Legal Interactions grouping of abstract ideas (see MPEP 2106.04(a)(2)).
Accordingly, it is reasonable to conclude that independent claim 1 (which is representative of independent claims 9, 17) recites an abstract idea that corresponds to a judicial exception.
[INDEPENDENT CLAIMS Additional Elements]
Per Step 2A.2. The identified abstract idea is not integrated into a practical application because the additional elements in the independent claims only amount to instructions to apply the judicial exception to a computer, or are a general link to a technological environment (see MPEP 2106.05(f); MPEP 2106.05(h)).
For example, the added elements “custodian token platform,” “at a graphical user interface of the custodial token platform,” and “at the custodial token platform via the graphical user interface” recite computing elements at a high level of generality, generally linking the use of a judicial exception to a particular technological environment (see MPEP 2106.05(h)), or merely using a computer as a tool to perform an abstract idea (MPEP 2106.05(f)). Further, the qualifiers “wherein the fiat wallet is not associated with a blockchain address and is not operable to perform cryptographic operations on a blockchain network”, “wherein the stablecoin wallet is associated with a public key and a private key enabling cryptographic operations via the blockchain network”, “wherein the fiat wallet is not associated with a blockchain address and is not operable to perform cryptographic operations on a blockchain network,”, “wherein the stablecoin wallet is associated with a public key and a private key enabling cryptographic operations via the blockchain network;”, “wherein the stablecoin amount is updated to include the converted fiat amount”; and “wherein displaying the stablecoin amount that is updated to include the converted fiat amount is based at least in part on broadcasting the message” are nothing more than (a) descriptive limitations of claim elements, such as describing the nature, structure and/or content of other claim elements, or (b) general links to the computing environment, which amount to instructions to “apply it,” or equivalent (MPEP 2106.05(f)).
These additional elements of the independent claims do not preclude from carrying out the identified abstract idea “converting fiat currency into digital currency and vice versa, and displaying the updated amount”, and do not serve to integrate the identified abstract idea into a practical application.
More additional steps in the independent claims, shown not bolded above, recite: receiving an amount of fiat currency ([B]), displaying a corresponding fiat amount ([C]). When considered individually, they amount to nothing more than receiving data, processing data, storing results or transmitting data that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea.
Thus, it is reasonable to conclude that these claim elements do not integrate the identified abstract idea (“converting fiat currency into digital currency and vice versa, and displaying the updated amount”) into a practical application (see MPEP 2106.05(f)(2)).
Thus, it is reasonable to conclude that these claim elements do not integrate the identified abstract idea (“converting fiat currency into digital currency and vice versa, and displaying the updated amount”) into a practical application (see MPEP 2106.05(h)).
Therefore, the additional steps of independent claim 1 (which is representative of independent claims 9, 18) do not integrate the identified abstract idea into a practical application and the claims remain a judicial exception.
Per Step 2B. Independent claim 1 (which is representative of claims independent 9, 18) does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when the independent claim is reevaluated as a whole, as an ordered combination under the considerations of Step 2B, the outcome is the same like under Step 2A.2.
Overall, it is concluded that independent claims 1, 9, 18 are deemed ineligible.
[DEPENDENT CLAIMS]
Dependent claim 3, which is representative of dependent claims 11, 19, recites:
[A] broadcasting a message that is configured to call a minting contract for the stablecoin, the minting contract configured to mint an amount of the stablecoin equal to the fiat amount associated with the user profile, wherein displaying the stablecoin amount that is updated to include the converted fiat amount is based at least in part on broadcasting the message.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “converting fiat currency into digital currency and vice versa, and displaying the updated amount”. The elements in this dependent claim are comparable to “receiving or transmitting data over a network, e.g., using the Internet to gather or provide data”, which has been recognized by a controlling court as "well-understood, routine and conventional computing functions" when claimed generically as they are in these dependent claims. Thus, it is reasonable to conclude that these claim elements do not integrate the identified abstract idea (“converting fiat currency into digital currency and vice versa, and displaying the updated amount”) into a practical application (see MPEP 2106.05(d) II)).
The dependent claim elements have the same relationship to the underlying abstract idea (“converting fiat currency into digital currency and vice versa, and displaying the updated amount”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“converting fiat currency into digital currency and vice versa, and displaying the updated amount”).
Therefore, dependent claim 3 (which is representative of dependent claims 11, 19) is deemed ineligible.
Dependent claim 5, which is representative of dependent claims 13, recites:
[A] receiving at the custodial token platform, a second input to disable the single amount setting.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “converting fiat currency into digital currency and vice versa, and displaying the updated amount”. The elements in this dependent claim are comparable to “receiving or transmitting data over a network, e.g., using the Internet to gather or provide data”, which has been recognized by a controlling court as "well-understood, routine and conventional computing functions" when claimed generically as they are in these dependent claims. Thus, it is reasonable to conclude that these claim elements do not integrate the identified abstract idea (“converting fiat currency into digital currency and vice versa, and displaying the updated amount”) into a practical application (see MPEP 2106.05(d) II)).
The dependent claim elements have the same relationship to the underlying abstract idea (“converting fiat currency into digital currency and vice versa, and displaying the updated amount”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“converting fiat currency into digital currency and vice versa, and displaying the updated amount”).
Therefore, dependent claim 5 (which is representative of dependent claims 13) is deemed ineligible.
Dependent claim 6, which is representative of dependent claims 14, recites:
[A] displaying, based at least in part on receiving the second input and at a user interface of the custodial token platform, a fiat amount and a stablecoin amount associated with the user profile.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “converting fiat currency into digital currency and vice versa, and displaying the updated amount”. The elements in this dependent claim are comparable to receiving data, processing data, storing results or transmitting data that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea, Thus, it is reasonable to conclude that these claim elements do not integrate the identified abstract idea (“converting fiat currency into digital currency and vice versa, and displaying the updated amount”) into a practical application (see MPEP 2106.05(f)(2)).
The dependent claim elements have the same relationship to the underlying abstract idea (“converting fiat currency into digital currency and vice versa, and displaying the updated amount”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“converting fiat currency into digital currency and vice versa, and displaying the updated amount”).
Therefore, dependent claim 6 (which is representative of dependent claims 14) is deemed ineligible.
Dependent claim 8, which is representative of dependent claims 16, recites:
[A] displaying, at the user graphical interface, an option to enable the single amount setting based at least in part on receiving the first amount of fiat; and
[B] receiving, based at least in part on displaying the option to enable the single amount setting, the input.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “converting fiat currency into digital currency and vice versa, and displaying the updated amount”. The elements in this dependent claim are comparable to receiving data, processing data, storing results or transmitting data that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea. Thus, it is reasonable to conclude that these claim elements do not integrate the identified abstract idea (“converting fiat currency into digital currency and vice versa, and displaying the updated amount”) into a practical application (see MPEP 2106.05(f)(2)).
The dependent claim elements have the same relationship to the underlying abstract idea (“converting fiat currency into digital currency and vice versa, and displaying the updated amount”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“converting fiat currency into digital currency and vice versa, and displaying the updated amount”).
Therefore, dependent claim 8 (which is representative of dependent claims 16) is deemed ineligible.
Dependent claim 22 recites:
[A] displaying, at the graphical user interface, one or more benefits associated with the selectable option, a rate of return associated with the stablecoin or both based at least in part on the first amount of the fiat satisfying a threshold.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “converting fiat currency into digital currency and vice versa, and displaying the updated amount”. The elements in this dependent claim are comparable to receiving data, processing data, storing results or transmitting data that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea. Thus, it is reasonable to conclude that these claim elements do not integrate the identified abstract idea (“converting fiat currency into digital currency and vice versa, and displaying the updated amount”) into a practical application (see MPEP 2106.05(f)(2)).
The dependent claim elements have the same relationship to the underlying abstract idea (“converting fiat currency into digital currency and vice versa, and displaying the updated amount”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“converting fiat currency into digital currency and vice versa, and displaying the updated amount”).
Therefore, dependent claim 22 is deemed ineligible.
Dependent claim 23 recites:
[A] displaying, at the graphical user interface, an option to disable the single amount setting; and
[B] receiving, based at least in part on displaying the option to disable the single amount setting, the user input.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “converting fiat currency into digital currency and vice versa, and displaying the updated amount”. The elements in this dependent claim are comparable to receiving data, processing data, storing results or transmitting data that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea. Thus, it is reasonable to conclude that these claim elements do not integrate the identified abstract idea (“converting fiat currency into digital currency and vice versa, and displaying the updated amount”) into a practical application (see MPEP 2106.05(f)(2)).
The dependent claim elements have the same relationship to the underlying abstract idea (“converting fiat currency into digital currency and vice versa, and displaying the updated amount”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“converting fiat currency into digital currency and vice versa, and displaying the updated amount”).
Therefore, dependent claim 23 is deemed ineligible.
Dependent claim 25 recites:
[A] receiving, after converting the fiat amount to the stablecoin, a user input to transfer an amount of the stablecoin to an external wallet address via the blockchain network;
[B] signing, using a private key associated with the stablecoin wallet, a transaction for the transfer of the amount of the stablecoin; and
[C] broadcasting the signed transaction to one or more nodes of the blockchain network.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “converting fiat currency into digital currency and vice versa, and displaying the updated amount”. The elements in this dependent claim are comparable to receiving data, processing data, storing results or transmitting data that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea. Thus, it is reasonable to conclude that these claim elements do not integrate the identified abstract idea (“converting fiat currency into digital currency and vice versa, and displaying the updated amount”) into a practical application (see MPEP 2106.05(f)(2)).
The dependent claim elements have the same relationship to the underlying abstract idea (“converting fiat currency into digital currency and vice versa, and displaying the updated amount”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“converting fiat currency into digital currency and vice versa, and displaying the updated amount”).
Therefore, dependent claim 25 is deemed ineligible.
Dependent claims 4, 7, which are representative of dependent claims 12, 15, respectively, and dependent claims 21, 24, 26 recite:
wherein the message is configured to cause the converted fiat amount to be associated with a blockchain address associated with the user profile.
wherein the fiat amount is zero.
wherein the fiat amount is associated with a first wallet and the stablecoin amount is associated with a second wallet, and
wherein the first wallet has reduced functionality as compared to the second wallet.
wherein converting the fiat amount to the stablecoin is performed internally by the custodial token platform without broadcasting an on-chain transaction to a blockchain network.
wherein the fiat wallet is not associated with a private key and is not operable to sign transactions for broadcast to the blockchain network.
These further elements in the dependent claims do not perform any claimed method steps. They describe the nature, structure and/or content of other claim elements – the message configuration, the fiat currency amount – and as such, cannot change the nature of the identified abstract idea (“converting fiat currency into digital currency and vice versa, and displaying the updated amount”), from a judicial exception into eligible subject matter, because they do not represent significantly more (see MPEP 2106.07). The nature, form or structure of the other claim elements themselves do not practically or significantly alter how the identified abstract idea would be performed and do not provide more than a general link to a technological environment.
When the dependent claims are considered as a whole, as an ordered combination, the claim elements noted above appear to merely apply the abstract concept to a technical environment in a very general sense. The most significant elements, which form the abstract concept, are set forth in the independent claims. The fact that the computing devices and the dependent claims are facilitating the abstract concept is not enough to confer statutory subject matter eligibility, since their individual and combined significance do not transform the identified abstract concept at the core of the claimed invention into eligible subject matter. Therefore, it is concluded that the dependent claims of the instant application, considered individually, or as a as a whole, as an ordered combination, do not amount to significantly more (see MPEP 2106.07(a)II).
Therefore, dependent claims 4, 7, which are representative of dependent claims 12, 15, respectively, and dependent claims 21, 24, 26 are deemed ineligible.
In sum, claims 1, 3-9, 11-15, 17, 19, 22-26 are rejected under 35 USC 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 112(b)
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, 3-9, 11-15, 17, 19, 22-26 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor regards as the invention.
Claim 1, 9, 17 are rejected under 35 U.S.C. 112(b) because they have been amended to incorporate a negative limitation (“wherein the fiat wallet is not associated with a blockchain address and is not operable to perform cryptographic operations on a blockchain network”) that defines a claim by what it’s not, thus not “particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention” (see MPEP 2173.05(i)).
Claim 26 is rejected under 35 U.S.C. 112(b) because it has been amended to incorporate a negative limitation (“wherein the fiat wallet is not associated with a private key and is not operable to sign transactions for broadcast to the blockchain network.”) that defines a claim by what it’s not, thus not “particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention” (see MPEP 2173.05(i)).
The remainder of the claims are rejected by virtue of dependency. The reference is provided for the purpose of compact prosecution.
Claim Rejections - 35 USC § 103
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 difference 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 the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103(a) are summarized as follows:
i. Determining the scope and contents of the prior art.
ii. Ascertaining the differences between the prior art and the claims at issue.
iii. Resolving the level of ordinary skill in the pertinent art.
iv. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3-9, 11-15, 17, 19, 22-26 are rejected under 35 U.S.C. 103 as being unpatentable over Plenet de Badts de Cugnac (US 11,704,732) (herein after Plenet), in view of Mawson et al (US 2023/0186285), in further view of Saraf et al (US 2023/0251353).
Regarding Claims 1, 9, 17: Plenet discloses: A method for crypto token management, comprising:
receiving a first amount of fiat to be associated with a fiat wallet of a user profile at a custodial token platform; {see at least fig2, rc290, (38)/[5:45-51] lending fund allocated to borrower (reads on first amount); fig3, rc310, (39)/[5:51-56] transferred to borrower (reads on user profile at custodian platform}
displaying, at a graphical user interface of the custodial token platform, a user interface page that displays a fiat amount corresponding to the first amount, a stablecoin amount corresponding to a second amount of stablecoin associated with a stablecoin wallet of the user profile, … {see at least fig2, rc270, (36)/[5:38-42] display with the amount; (41)/[5:62-65] multiple lenders (based on the broadest reasonable interpretation (MPEP 2111), reads on second amount); (19)/[3:54-61] convert fiat money into stablecoins; (24)/[3:65-4:10] convert that money into stablecoin currency}
wherein the fiat wallet is not associated with a blockchain address and is not operable to perform cryptographic operations on a blockchain network, and {see at least (24)-(25)/[4:21-40] fiat wallet}
converting, after receiving the user input, the fiat amount to the stablecoin, such that the converted fiat amount is associated with the stablecoin wallet of the user profile; and {see at least (19)/[3:54-62]; (24)/[4:21-35] convert to stablecoins (based on the broadest reasonable interpretation (MPEP 2111), reads on single amount setting); fig1, rc175, (24)/[ 4:21-35] borrower crypto wallet (reads on converting fiat currency to stablecoin). Plenet does not disclose the limitation, “such that the converted fiat amount is associated with the stablecoin wallet of the user profile”. However, this difference is only found in the non-functional descriptive material and does not affect how the claimed invention functions (i.e., the descriptive material does not have any claim function in the claimed method; see MPEP 2111.05). Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability}
displaying, at the graphical user interface, an updated user interface page that displays the stablecoin amount without displaying the fiat amount, wherein the stablecoin amount is updated to include the converted fiat amount. {see at least fig2, rc270, (36)/[5:38-42] display with the amount; (41)/[5:62-65] multiple lenders (based on the broadest reasonable interpretation (MPEP 2111), reads on second amount)}
receiving, while the selectable option is selected, a third amount of fiat to be associated with the user profile at the custodial token platform; {see at least (19)/[3:54-62]; (24)/[4:21-35] convert to stablecoins (based on the broadest reasonable interpretation (MPEP 2111), reads on single amount setting); fig1, rc175, (24)/[ 4:21-35] borrower crypto wallet (reads on single amount setting); fig3, rc330, (41)/[5:61-65] multiple lenders (based on the broadest reasonable interpretation (MPEP 2111), reads on third amount }
displaying, at the graphical user interface, the stablecoin amount that is updated to include the converted third amount of fiat. {see at least fig2, rc270, (36)/[5:38-42] display with the amount; (41)/[5:62-65] multiple lenders (based on the broadest reasonable interpretation (MPEP 2111), reads on second amount)}
Plenet does not disclose, however, Mawson discloses:
wherein the stablecoin wallet is associated with a public key and a private key enabling cryptographic operations via the blockchain network; {see at least fig11, rc1132, [0195] user wallet includes public key, private key}
receiving, at the custodial token platform, via the graphical user interface, a user input indicating selection of the selectable option; {see at least fig3C, [0083] user indicates the amount … the currency to be converted; fig3A, [0080] selectable options; fig3B, [0082] option to convert assets, how to convert assets; fig4A, rc406, [0086] enable the user to convert a portion of the asset into another asset (reads on converting fiat to stablecoin}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Plenet to include the elements of Mawson. One would have been motivated to do so, in order to provide user with the option to make a choice. In the instant case, Plenet evidently discloses generating a single balance from diverse currencies. Mawson is merely relied upon to illustrate the functionality of user input in the same or similar context. Since both generating a single balance from diverse currencies, as well as user input are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Plenet, as well as Mawson would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Plenet / Mawson
Plenet, Mawson does not disclose, however, Saraf discloses:
… and a selectable option to convert fiat amounts associated with the user profile to stablecoin; {see at least [0005], [0011]; [0013]; [0022] fiat-to-crypto on-ramp … convert fiat currency to crypto-currency (reads on stablecoin); [0032] enabling buyers to convert fiat currency to crypto currency (reads on selectable option); [0034]; fig1, rc125, [0041] fiat to crypto on-ramp; ([0067]-[0068] two options (reads selectable option) to convert cryptocurrency to fiat}
converting, automatically based at least in part on the selectable option being selected, the third amount of fiat to the stablecoin; and {see at least [0005], [0011]; [0013]; [0022] fiat-to-crypto on-ramp … convert fiat currency to crypto-currency (reads on stablecoin); [0032] enabling buyers to convert fiat currency to crypto currency (reads on selectable option); [0034]; fig1, rc125, [0041] fiat to crypto on-ramp; ([0067]-[0068] two options (reads selectable option) to convert cryptocurrency to fiat}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Plenet, Mawson to include the elements of Saraf. One would have been motivated to do so, in order to provide user with the option to make a choice. In the instant case, Plenet evidently discloses generating a single balance from diverse currencies. Saraf is merely relied upon to illustrate the functionality of user selecting an option in the same or similar context. Since both generating a single balance from diverse currencies, as well as user selecting an option are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Plenet, as well as Saraf would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Plenet, Mawson / Saraf.
Regarding Claims 3, 11, 19: Plenet, Mawson, Saraf discloses the limitations of Claims 1, 9, 17. Plenet further discloses: wherein converting the fiat amount to the stablecoin comprises:
broadcasting a message that is configured to call a minting contract for the stablecoin, the minting contract configured to mint an amount of the stablecoin equal to the fiat amount associated with the user profile, wherein displaying the stablecoin amount that is updated to include the converted fiat amount is based at least in part on broadcasting the message. {see at least (19)/[3:54-62]; (24)/[4:21-35] convert to stablecoins (based on the broadest reasonable interpretation (MPEP 2111), reads on single amount setting); fig1, rc175, (24)/[ 4:21-35] borrower crypto wallet (reads on single amount setting). The claim element “the minting contract configured to mint an amount of the stablecoin equal to the fiat amount associated with the user profile” consists entirely of language disclosing at most a reason to have performed earlier method steps (intended use or field of use), but does not affect the functions in a manipulative sense (see MPEP 2103 I C) and imparts neither structure nor functionality to the claimed method (see MPEP 2111.05, MPEP 2114 and authorities cited therein), so it is considered but given no patentable weight. The reference is provided for the purpose of compact prosecution.}
Regarding Claims 4, 12: Plenet, Mawson, Saraf discloses the limitations of Claims 3, 11. Plenet further discloses:
wherein the message is configured to cause the converted fiat amount to be associated with a blockchain address associated with the user profile. {see at least fig1, rc175, (24)/[ 4:21-35] borrower wallet (based on the broadest reasonable interpretation (MPEP 2111), reads on user profile); fig3, rc310, (39)/[5:51-56] transferred to borrower wallet (based on the broadest reasonable interpretation (MPEP 2111), reads on blockchain address associated with user profile)}
Regarding Claims 5, 13: Plenet, Mawson, Saraf discloses the limitations of Claims 1, 9, 17. Mawson further discloses:
receiving at the custodial token platform, a second user input to disable a single amount setting. {see at least fig3A, rc310, rc340, [0080] cash balance (reads on fiat currency, stablecoin (based on the broadest reasonable interpretation (MPEP 2111), reads on single amount setting disabled, because multiple amounts are shown)}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Plenet Mawson, Saraf to include additional elements of Mawson. One would have been motivated to do so, in order to provide more account details (i.e. individual amounts). In the instant case, Plenet, Mawson, Saraf evidently discloses generate a single balance from diverse currencies. Mawson is merely relied upon to illustrate the additional functionality of displaying in multiple amounts in the same or similar context. Since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claims 6, 14: Plenet Mawson discloses the limitations of Claims 5, 13. Mawson further discloses:
displaying, based at least in part on receiving the second user input and at the graphical user interface of the custodial token platform, a fiat amount and a stablecoin amount associated with the user profile. {see at least fig3A, rc310, rc340, [0080] cash balance (reads on fiat currency, stablecoin)}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Plenet, Mawson, Saraf to include additional elements of Mawson. One would have been motivated to do so, in order to provide more account details (i.e. individual amounts). In the instant case, Plenet, Mawson, Saraf evidently discloses generate a single balance from diverse currencies. Mawson is merely relied upon to illustrate the additional functionality of displaying separate amounts in the same or similar context. Since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claims 7, 15: Plenet, Mawson, Saraf discloses the limitations of Claims 6, 14. Mawson further discloses:
wherein the fiat amount is zero. {see at least [0048] cash out the balance (based on the broadest reasonable interpretation, (MPEP 2111), reads on fiat amount is zero)}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Plenet Mawson, Saraf to include additional elements of Mawson. One would have been motivated to do so, in order to reveal that the fiat balance has reached zero. In the instant case, Plenet Mawson, Saraf evidently discloses generate a single balance from diverse currencies. Mawson is merely relied upon to illustrate the additional functionality of a fiat amount of zero in the same or similar context. Since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claims 8, 16: Plenet, Mawson, Saraf discloses the limitations of Claims 1, 9, 17. Mawson further discloses: wherein receiving the user input indicating selection of the selectable option setting comprises:
displaying, at the graphical user interface, an option to enable a single amount setting based at least in part on receiving the first amount of fiat; and {see at least fig5, rc520, [0094] single amount setting; [0033] synthetic balance in USD (reads on fiat currency)}
receiving, based at least in part on displaying the option to enable the single amount setting, the user input. {see at least fig5, rc520, [0094] single amount setting; [0033] synthetic balance in USD (reads on fiat currency)}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Plenet, Mawson, Saraf to include additional elements of Mawson One would have been motivated to do so, in order to provide total account details (i.e. combined amounts) only. In the instant case, Plenet, Mawson, Saraf evidently discloses generate a single balance from diverse currencies. Mawson is merely relied upon to illustrate the additional functionality of displaying single amounts in the same or similar context. Since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 22: Plenet, Mawson, Saraf discloses the limitations of Claim 1. Plenet further discloses:
displaying, at the graphical user interface, one or more benefits associated with the selectable option, a rate of return associated with the stablecoin or both based at least in part on the first amount of the fiat satisfying a threshold. {see at least fig2, rc210, rc250, (30)-(35)/[5:1-37]]interest rate (reads on rate of return)}
Regarding Claim 23: Plenet, Mawson, Saraf discloses the limitations of Claim 5. Saraf further discloses: wherein receiving the second user input to disable the single amount setting comprises:
displaying, at the graphical user interface, an option to disable the single amount setting; and {see at least fig3, , rc342, rc344, [0069] displaying and receiving input from user[0067]-[0068] two options (reads selectable option) to convert cryptocurrency to fiat}
receiving, based at least in part on displaying the option to disable the single amount setting, the user input. {see at least [0067]-[0068] merchant elects … two options (reads selectable option) to convert cryptocurrency to fiat}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Plenet, Mawson, Saraf to include additional elements of Saraf. One would have been motivated to do so, in order to provide user with a means to interact with the system. In the instant case, Plenet, Mawson, Saraf evidently discloses generate a single balance from diverse currencies. Saraf is merely relied upon to illustrate the additional functionality of a user input/output display in the same or similar context. Since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 24: Plenet, Mawson, Saraf discloses the limitations of Claim 1. Plenet further discloses:
wherein converting the fiat amount to the stablecoin is performed internally by the custodial token platform without broadcasting an on-chain transaction to the blockchain network. {see at least fig1, rc130, rc190, (24)/[4:21-39} converting fiat money to stablecoin at the backend of the system (based on the BRI (MPEP 2111), reads on conversion that is performed internally by a computer)}
Regarding Claim 25: Plenet, Mawson, Saraf discloses the limitations of Claim 1. Plenet further discloses:
receiving, after converting the fiat amount to the stablecoin, a user input to transfer an amount of the stablecoin to an external wallet address via the blockchain network; {see at least fig3, rc310, (39)/[5:52-57] transfer loan amount in stablecoin currency … transaction added to the blockchain}
broadcasting the signed transaction to one or more nodes of the blockchain network. {see at least fig3, rc310, (39)/[5:52-57] transfer loan amount in stablecoin currency … transaction added to the blockchain … from their crypto-wallet to the borrower crypto-wallet (reads on nodes)}
Mawson further discloses:
signing, using a private key associated with the stablecoin wallet, a transaction for the transfer of the amount of the stablecoin; and {see at least [0199] signed by user’s private key}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Plenet, Mawson, Saraf to include additional elements of Mawson. One would have been motivated to do so, in order to increase transaction security. In the instant case, Plenet, Mawson, Saraf evidently discloses generate a single balance from diverse currencies. Mawson is merely relied upon to illustrate the additional functionality of signing a transaction with a private key in the same or similar context. Since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 26: Plenet, Mawson, Saraf discloses the limitations of Claim 25. Plenet further discloses:
wherein the fiat wallet is not associated with a private key and is not operable to sign transactions for broadcast to the blockchain network. {see at least (24)-(25)/[4:21-40] fiat wallet}
The prior art made of record and not relied upon which, however, is considered pertinent to applicant's disclosure:
US 20190139033 A1 Ricotta; Frank et al. METHOD FOR REAL-TIME CONVERSION OF CRYPTOCURRENCY TO CASH AND OTHER FORMS OF VALUE AT THE POINT OF USE - Systems and methods move money from a crypto currency to a fiat currency in real-time using a mobile wallet or debit card to allow a customer to use the funds instantly. The process for such movement of money is secured using distributed ledger technology and smart contract services. The funds are available to the customer in real-time and the customer is able to use those funds substantially anywhere credit cards are accepted and at substantially any automatic teller machine (ATM). A multi-layered distributed ledger and reconciliation method may be used as a transaction settlement system. The multi-tiered authentication and distributed identification method may be used to prevent fraud and theft. A retail transactional value of a portfolio of digital currencies may be determined by taking into account asset market liquidity and volatility.
US 20200074552 A1 Shier; Charles Louis et al. SYSTEMS AND METHODS FOR SHORT AND LONG TOKENS - A long and short fund that is implemented using a distributed token-based system. A change in an indicator causes assets to be moved from one fund to the other. Investors may redeem their fund units at any time, including at the conclusion of the fund when one of the funds reaches zero value. A cryptographic whitelist may be used to ensure that only validated investors hold or redeem units of the funds. Offering memorandum and auditing documentation may be cryptographically attached to the token.
US 20210042799 A1 Adams; Chris et al. SYSTEM FOR EMPOWERING CONSUMERS TO ACHIEVE THEIR DREAMS AND ASPIRATIONS THROUGH SOCIAL NETWORKING WITH AN INTEGRATED DECENTRALIZED MARKETPLACE TO FACILITATE THE TRUSTLESS EXCHANGE OF SERVICES, AND CROWDFUNDING CAPABILITIES - A computer implemented method of communicating between devices is disclosed. The computer implemented method includes: transmitting at least one dream request to a specialized program on a dreamr server; receiving the at least one dream request at the dreamr server; determining if the at least one dream request invites a first group of registered users to co-dream with the at least one dream request; forming a supportive network if the at least one dream request invites the first group of registered users; determining if the supportive network invites a second group of registered users to co-dream; initiating dreamweaving between the supportive network and the second group of registered users if the supportive network invites the second group of registered users to co-dream and become a supernetwork; and enabling the supernetwork and the second group of registered users to become monetized, wherein goods and services of the supernetwork and the second group of registered users are marketed at a marketplace.
US 20230065042 A1 LI; Tiffany et al. BLOCKCHAIN MARKETPLACE FOR DEBT CAPITAL - A marketplace for trading bonds on the block chain includes a bond token smart contract that tokenizes the bond for buying/selling using a stablecoin. Each bond generates a corresponding marketplace smart contract. A whitelist smart contract is used to provide permissions for trading bonds on the block chain.
US 20210118052 A1 Walser; Joachim Paul CRYPTOCURRENCY CASH GATEWAY - The present invention concerns a cryptocurrency-cash gateway, comprising a wallet interface (403) for communicating over a network with at least one crypto wallet (102) and an EFT gateway interface (404) for communicating over a network with at least one electronic funds transfer, EFT, gateway or financial institution (407), wherein the cryptocurrency-cash gateway is operable to perform a cryptocurrency-to-cash transaction for allowing a user to withdraw cash at an automatic transaction machine, ATM (110), or a point-of-sale, POS, system (110B) by exchanging a corresponding amount of a cryptocurrency from the crypto wallet(s); or conversely allowing the user to deposit cash at an ATM or POS system and exchanging it for a corresponding amount of a cryptocurrency to be deposited in at least one crypto wallet of the user.
Response to Amendments/Arguments
Applicant’s submitted remarks and arguments have been fully considered.
Applicant disagrees with the Office Action conclusions and asserts that the presented claims fully comply with the requirements of 35 U.S.C. § 101 regrading judicial exceptions. Further, Applicant is of the opinion that the prior art fails to teach Applicant’s invention.
Examiner respectfully disagrees in both regards.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 101.
Applicant submits:
a. The pending claims are not directed to an abstract idea.
b. The identified abstract idea is integrated into a practical application.
c. The pending claims amount to significantly more.
Furthermore, Applicant asserts that the Office has failed to meet its burden to identify the abstract idea and to establish that the identified abstract idea is not integrated into a practical application and that the pending claims do not amount to significantly more.
Examiner responds – The arguments have been considered in light of Applicants’ amendments to the claims. The arguments ARE NOT PERSUASIVE. Therefore, the rejection is maintained.
The pending claims, as a whole, are directed to an abstract idea not integrated into a practical application. This is because (1) they do not effect improvements to the functioning of a computer, or to any other technology or technical field (see MPEP 2106.05 (a)); (2) they do not apply or use the abstract idea to effect a particular treatment or prophylaxis for a disease or a medical condition (see the Vanda memo); (3) they do not apply the abstract idea with, or by use of, a particular machine (see MPEP 2106.05 (b)); (4) they do not effect a transformation or reduction of a particular article to a different state or thing (see MPEP 2106.05 (c)); (5) they do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the identified abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designated to monopolize the exception (see MPEP 2106.05 (e) and the Vanda memo).
In addition, the pending claims do not amount to significantly more than the abstract idea itself.
As such, the pending claims, when considered as a whole, are directed to an abstract idea not integrated into a practical application and not amounting to significantly more.
More specific:
Applicant submits “… because these features define a specific technical architecture for managing digital assets on a custodial token platform (e.g., a dual-wallet architecture in which a fiat wallet lacks blockchain-native cryptographic capabilities and a stablecoin wallet possesses public-key cryptographic capabilities) and recite a specific technical transformation in which a conversion causes an amount of fiat in a user's account to become associated with the cryptographically enabled stablecoin wallet.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Based on the claim language (“converting, automatically based at least in part on the selectable option being selected, the third amount of fiat to the stablecoin; and displaying, at the graphical user interface, the stablecoin amount that is updated to include the converted third amount of fiat.”) and in light of the specification (“... enabling a single cash balance …”), the claims are unequivocally directed to “converting fiat currency into digital currency and vice versa, and displaying the updated amount and displaying the updated amount”.
Thus, the rejection is proper and has been maintained.
Applicant submits “Moreover, the Office Action has not explained how the specific technical features of the amended claims (e.g., including the management of a fiat wallet and a stablecoin wallet having distinct cryptographic and/or functional qualities) fall within any of the enumerated subgroupings of "Certain Methods of Organizing Human Activity."”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
The eligibility analysis in the instant office action has considered each and every limitation of the independent claims, has analyzed the steps and has concluded that the claims are directed to an abstract idea, as defined by MPEP 2016.04-07:
Independent claim 1 (which is representative of independent claims 9, 16) recites: enabling an amount ([D]); converting the amount to digital currency ([E]); displaying the digital currency amount, without displaying the fiat amount ([F]), receiving and converting a third amount of stablecoin ([G], [H]) and displaying the updated stablecoin amount ([I]), which, based on the claim language and in view of the application disclosure, represents a process aimed at: “converting fiat currency into digital currency and vice versa, and displaying the updated amount and displaying the updated amount”. This is a combination that, under its broadest reasonable interpretation, covers sales activities or behaviors, business relationships (e-commerce) which falls under Certain Methods of Organizing Human Activity, i.e., Commercial or Legal Interactions grouping of abstract ideas (see MPEP 2106.04(a)(2)). Accordingly, it is concluded that independent claim 1 (which is representative of independent claims 9, 17) recites an abstract idea that corresponds to a judicial exception.
Thus, the rejection is proper and has been maintained.
Applicant submits “Independent Claims I. 9, and 17 recite features that integrate any alleged judicial exception into a practical application … Thus, the claims improve the functioning of a custodial token platform by enabling a user to …”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
First, MPEP 2106.05(a) discloses that the additional claim elements bring about “improvements to the functioning of a computer, or any other technology or technical field.” Providing a user with promotions information along navigation information is a pure BUSINESS problem, rather than a technology or technical field problem. As such, the limitations which have not been deemed as being part of the identified abstract idea, i.e., the “additional elements,” do not integrate the identified abstract idea into a practical application, as disclosed by MPEP 2106.05(a).
Second, MPEP 2106.04(d)(1) discloses:
An important consideration to evaluate when determining whether the claim as a whole integrates a judicial exception into a practical application is whether the claimed invention improves the functioning of a computer or other technology .... In short, first the specification should be evaluated to determine if the disclosure provides sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement. The specification need not explicitly set forth the improvement, but it must describe the invention such that the improvement would be apparent to one of ordinary skill in the art .... Second, if the specification sets forth an improvement in technology. the claim must be evaluated to ensure that the claim itself reflects the disclosed improvement. (Emphasis added)
That is, the claimed invention may integrate the judicial exception into a practical application by demonstrating that it improves the relevant existing technology although it may not be an improvement over well-understood, routine, conventional activity. (Emphasis added)
Thus, the rejection is proper and has been maintained.
Applicant submits “Independent claims I. 9, and 17 recite elements that amount to significantly more than any alleged judicial exception”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
The eligibility analysis in the instant office action concludes at step 2B:
Per Step 2B. Independent claim 1 (which is representative of claims independent 9, 18) does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when the independent claim is reevaluated as a whole, as an ordered combination under the considerations of Step 2B, the outcome is the same like under Step 2A.2.
Overall, it is concluded that independent claims 1, 9, 18 are deemed ineligible.
Thus, the rejection is proper and has been maintained.
Applicant submits “These features are not well-understood, routine, or conventional, as the Office Action has not identified any evidence that the specific ordered combination of features recited in the amended claims was well-understood, routine, or conventional at the time of filing.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
The eligibility analysis in the instant office action has identified well-understood, routine, or conventional elements only in dependent claims 3, 5, 11, 13, 19. These elements have been determined to be well-understood, routine, or conventional by precedential court cases (see MPEP 2106.05(d) II))
Thus, the rejection is proper and has been maintained.
Applicant submits “Dependent claims 3-8, 11-15, 19, and 22-26 each depend from one of amended independent claims 1, 9, and 17 and recite further features that are particularly integrated into the practical application of the claims from which they depend.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
The eligibility analysis in the instant office action has found independent claims 1, 9, 17 as being ineligible.
Thus, the rejection is proper and has been maintained.
It follows from the above that there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself. Therefore, the rejection under 35 U.S.C. § 101 is maintained.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 112(a).
The rejection is withdrawn, as a result of the amendments.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 103.
Applicant submits “Thus, Plenet does not teach or suggest "displaying, at a graphical user interface of the custodial token platform, a user interface page that displays a fiat amount corresponding to the first amount [and] a stablecoin amount corresponding to a second amount of stablecoin associated with a stablecoin wallet of the user profile, ... wherein the fiat wallet is not associated with a blockchain address and is not operable to perform cryptographic operations on a blockchain network, and wherein the stablecoin wallet is associated with a public key and a private key enabling cryptographic operations via the blockchain network," as recited in amended independent claim 1.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Plenet discloses:
displaying, at a graphical user interface of the custodial token platform, a user interface page that displays a fiat amount corresponding to the first amount, a stablecoin amount corresponding to a second amount of stablecoin associated with a stablecoin wallet of the user profile, … {see at least fig2, rc270, (36)/[5:38-42] display with the amount; (41)/[5:62-65] multiple lenders (based on the broadest reasonable interpretation (MPEP 2111), reads on second amount); (19)/[3:54-61] convert fiat money into stablecoins; (24)/[3:65-4:10] convert that money into stablecoin currency}
wherein the fiat wallet is not associated with a blockchain address and is not operable to perform cryptographic operations on a blockchain network, and {see at least (24)-(25)/[4:21-40] fiat wallet}
Mawson discloses:
wherein the stablecoin wallet is associated with a public key and a private key enabling cryptographic operations via the blockchain network; {see at least fig11, rc1132, [0195] user wallet includes public key, private key}
Therefore, Plenet, Mawson discloses the emended claim limitations. Thus, the rejection is proper and has been maintained.
Applicant submits “However, Plenet does not teach or suggest "converting, after receiving the user input, the fiat amount to the stablecoin such that the converted fiat amount is associated with the stablecoin wallet of the user profile," as recited in amended independent claim 1.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Plenet discloses:
converting, after receiving the user input, the fiat amount to the stablecoin, such that the converted fiat amount is associated with the stablecoin wallet of the user profile; and {see at least (19)/[3:54-62]; (24)/[4:21-35] convert to stablecoins (based on the broadest reasonable interpretation (MPEP 2111), reads on single amount setting); fig1, rc175, (24)/[ 4:21-35] borrower crypto wallet (reads on converting fiat currency to stablecoin). Plenet does not disclose the limitation, “such that the converted fiat amount is associated with the stablecoin wallet of the user profile”. However, this difference is only found in the non-functional descriptive material and does not affect how the claimed invention functions (i.e., the descriptive material does not have any claim function in the claimed method; see MPEP 2111.05). Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability}
Therefore, Plenet discloses the amended claim limitation. Thus, the rejection is proper and has been maintained.
Applicant submits “Specifically, the cited portions of Plenet describe a cryptocurrency conversion module that "converts fiat money (that is, government-issued currency) into stablecoins" in the context of loan repayments, where a payment gateway retains a portion of a borrower's revenue stream, converts that portion to stablecoins, and distributes the stablecoins to one or more lenders.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Applicant argues that Plenet does not disclose the limitations of the independent claims. However, the art rejection in the instant office action shows that Plenet discloses the literal meaning of each and every claim limitation, even if, as applicant argues, it might violate the spirit of the claim.
Thus, the rejection is proper and has been maintained.
Applicant submits “Saraf does not teach or suggest "a selectable option to convert fiat amounts associated with the user profile to stablecoin" or "converting, automatically based at least in part on the selectable option being selected, the third amount of fiat to the stablecoin," as recited in amended independent claim 1.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Saraf discloses:
… and a selectable option to convert fiat amounts associated with the user profile to stablecoin; {see at least [0005], [0011]; [0013]; [0022] fiat-to-crypto on-ramp … convert fiat currency to crypto-currency (reads on stablecoin); [0032] enabling buyers to convert fiat currency to crypto currency (reads on selectable option); [0034]; fig1, rc125, [0041] fiat to crypto on-ramp; ([0067]-[0068] two options (reads selectable option) to convert cryptocurrency to fiat}
converting, automatically based at least in part on the selectable option being selected, the third amount of fiat to the stablecoin; and {see at least [0005], [0011]; [0013]; [0022] fiat-to-crypto on-ramp … convert fiat currency to crypto-currency (reads on stablecoin); [0032] enabling buyers to convert fiat currency to crypto currency (reads on selectable option); [0034]; fig1, rc125, [0041] fiat to crypto on-ramp; ([0067]-[0068] two options (reads selectable option) to convert cryptocurrency to fiat}
Therefore, Saraf discloses the amended claim limitation.
Thus, the rejection is proper and has been maintained.
Applicant submits “Mawson does not teach or suggest "receiving, at the custodial token platform via the graphical user interface, a user input indicating selection of the selectable option," as recited in amended independent claim 1.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Mawson discloses:
wherein the stablecoin wallet is associated with a public key and a private key enabling cryptographic operations via the blockchain network; {see at least fig11, rc1132, [0195] user wallet includes public key, private key}
receiving, at the custodial token platform, via the graphical user interface, a user input indicating selection of the selectable option; {see at least fig3C, [0083] user indicates the amount … the currency to be converted; fig3A, [0080] selectable options; fig3B, [0082] option to convert assets, how to convert assets; fig4A, rc406, [0086] enable the user to convert a portion of the asset into another asset (reads on converting fiat to stablecoin}
Therefore, Mawson discloses the amended claim limitation.
Thus, the rejection is proper and has been maintained.
The other arguments presented by Applicant continually point back to the above arguments as being the basis for the arguments against the other 103 rejections, as the other arguments are presented only because those claims depend from the independent claims, and the main argument above is presented against the independent claims. Therefore, it is believed that all arguments put forth have been addressed by the points above.
Examiner has reviewed and considered all of Applicant’s remarks. The changes of the grounds for rejection, if any, have been necessitated by Applicant’s extensive amendments to the claims. Therefore, the rejection is maintained, necessitated by the extensive amendments and by the fact that the rejection of the claims under 35 USC § 101 has not been overcome.
Conclusion
THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Inquiries
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Radu Andrei whose telephone number is 313.446.4948. The examiner can normally be reached on Monday – Friday 8:30am – 5pm EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John Hayes can be reached at 571.272.6708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
As disclosed in MPEP 502.03, communications via Internet e-mail are at the discretion of the applicant. Without a written authorization by applicant in place, the USPTO will not respond via Internet e-mail to any Internet correspondence which contains information subject to the confidentiality requirement as set forth in 35 U.S.C. 122. A paper copy of such correspondence will be placed in the appropriate patent application. The following is a sample authorization form which may be used by applicant:
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with me concerning any subject matter of this application by electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center information webpage. Status information for unpublished applications is available to registered users through Patent Center information webpage only.
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.
Any response to this action should be mailed to:
Commissioner of Patents and Trademarks
P.O. Box 1450
Alexandria, VA 22313-1450
or faxed to 571-273-8300
/Radu Andrei/
Primary Examiner, AU 3697
Prosecution Insights