Prosecution Insights
Last updated: April 19, 2026
Application No. 17/193,416

SYSTEMS AND METHODS FOR AUTOMATIC ASSET TRANSFER USING SMART CONTRACTS

Non-Final OA §101§103
Filed
Mar 05, 2021
Examiner
MANDEL, MONICA A
Art Unit
3622
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
BOOST SUBSCRIBERCO L.L.C.
OA Round
5 (Non-Final)
18%
Grant Probability
At Risk
5-6
OA Rounds
6y 9m
To Grant
27%
With Interview

Examiner Intelligence

Grants only 18% of cases
18%
Career Allow Rate
59 granted / 324 resolved
-33.8% vs TC avg
Moderate +9% lift
Without
With
+8.9%
Interview Lift
resolved cases with interview
Typical timeline
6y 9m
Avg Prosecution
17 currently pending
Career history
341
Total Applications
across all art units

Statute-Specific Performance

§101
23.0%
-17.0% vs TC avg
§103
43.6%
+3.6% vs TC avg
§102
6.5%
-33.5% vs TC avg
§112
22.6%
-17.4% vs TC avg
Black line = Tech Center average estimate • Based on career data from 324 resolved cases

Office Action

§101 §103
DETAILED ACTION Continued Examination Under 37 CFR 1.114 A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant’s submission filed on November 13, 2025 has been entered. 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 . Acknowledgements This Office Action is in response to Applicant’s response filed on November 13, 2025 (“November 2025 Response”) which contained inter alia, claim amendments (“November 2025 Claims”) and “REMARKS” (“November 2025 Remarks”). Claims 1-14 and 16-20 are currently pending and have been examined. 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-14 and 16-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Step 1 of the Subject Matter Eligibility Analysis for Products and Processes1 (“SME Analysis”): Claims 1-14 and 16-20 are directed to at least one of the statutory categories: Claims 1-14 are directed to a system. Claims 16-19 are directed to a process. Claim 20 is directed to an article of manufacture. Step 2A- Prong One of the SME Analysis: Claim 20 (representative of Claims 1 and 16) recites the following steps: receiving at least one contract term, wherein the at least one contract term specifies a transfer of assets from an escrow wallet to a service-provider wallet; constructing, at least one contract based on the at least one contract term, wherein the at least one contract is between at least one consumer and at least one service provider; receiving financial data associated with the at least one consumer, wherein the financial data is at least one of: a financial record, a bank statement, a credit report, a background check, and a response to a questionnaire; receiving financial data associated with at least one historical financial data; based on the financial data associated with the at least one consumer and the financial data associated with the at least one historical financial data, constructing at least one consumer investment profile, wherein constructing at least one consumer investment profile further comprises applying a model to the financial data associated with the at least one consumer; receiving a deposit of at least one asset; recording the deposit of the at least one asset; storing the at least one coin in the at least one escrow wallet; automatically investing a first portion of the at least one asset in at least one investment vehicle based on the at least one consumer investment profile; receiving at least one trigger event associated with the contract, wherein the at least one trigger event is determined based on a usage level of a specific service by the at least one consumer, wherein the usage level indicates an amount used or a time period using the specific service; in response to receiving the at least one trigger event, transferring a second portion of the at least one asset to the at least one service-provider wallet; and recording the transfer of the second portion of the at least one asset to the at least one service-provider wallet, wherein in an event that the at least one trigger event is determined, determining whether the at least one escrow wallet has sufficient funds; and wherein, in response to a determination that the at least one escrow wallet has insufficient funds, initiating a transfer from the at least one investment vehicle to the at least one escrow wallet. These steps, under their broadest reasonable interpretation, describe or set-forth utilizing a contract to manage an escrow account to deposit funds by a consumer, invest a portion of its funds, and to pay a service provider for usage of a specific service with another portion of its funds, which amounts to: a fundamental economic principle or practice, a commercial or legal interactions (i.e.: agreements in the form of contracts), and also managing personal behavior or relationships or interactions between people (following rules or instructions). These limitations therefore fall within the “certain methods of organizing human activity” subject matter grouping of abstract ideas. Additionally, these steps, under their broadest reasonable interpretation, encompass a human manually (e.g., in their mind, or using paper and pen) following contract rules to manage an escrow account to deposit funds by a consumer, invest a portion of its funds, and to pay a service provider for usage of a specific service with another portion of its funds (i.e., one or more concepts performed in the human mind, such as one or more observations, evaluations, judgments, opinions), but for the recitation of generic computer components. If one or more claim limitations, under their broadest reasonable interpretation, covers performance of the limitations in the mind but for the recitation of generic computer components, then it falls within the “mental processes” subject matter grouping of abstract ideas. As such, Claims 1-14 and 16-20 recite an abstract idea. Step 2A-Prong Two of the SME Analysis: The claims recite the additional elements/limitations of a system comprising: at least one processor; and memory coupled to the at least one processor, the memory comprising computer executable instructions that, when executed by the at least one processor (as recited in Claim 1); computer-implemented (as recited in Claim 1); a non-transitory computer-readable media storing computer executable instructions that when executed cause a computing system (as recited in Claim 20); the contract being a smart contract, and wherein the at least one contract term is in the form of program code; a database; “an amount of data used” applying at least one machine-learning model to the financial data associated with the at least one consumer (as recited in Claim 20 and similarly in Claims 6, and 18); the assets being a stablecoin; recording on a blockchain; wherein the at least one machine-learning model is based in part on at least one of: a linear regression, a logistic regression, a linear discriminant analysis, a regression tree, a naive Bayes algorithm, a k-nearest neighbors algorithm, a learning vector quantization, a neural network, a support vector machines (SVM), and a random forest algorithm (as recited in Claim 7); training the at least one machine-learning model to distinguish between a high-risk consumer and a low-risk consumer (as recited in Claim 8); wherein the assets comprise at least one cryptocurrency coin (as recited in Claim 10); wherein the at least one cryptocurrency coin is at least one of: a Bitcoin, an Ether, and a stablecoin (as recited in Claim 11 and similarly in Claim 17); The requirement to execute the claimed steps/functions using the “system comprising: at least one processor; and memory coupled to the at least one processor, the memory comprising computer executable instructions,” the computer in the “computer-implemented” recitation of Claim 1, and the “computer-readable media” of Claim 20, and the database, is equivalent to adding the words “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer. These limitations do not impose any meaningful limits on practicing the abstract idea, and therefore do not integrate the abstract idea into a practical application (see MPEP 2106.05(f)). The recited additional elements of: a “smart contract,” “wherein the at least one contract term is in the form of program code,” a “stablecoin,” and different types of “crytpocurrency” serve merely to generally link the use of the judicial exception to a particular technological environment or field of use. Specifically, it serves to limit the application of the abstract idea to blockchain and cryptocurrency technologies. This reasoning was demonstrated in Bilski, where it was determined that certain claim elements limiting the basic concept of hedging to commodities and energy markets (merely limiting an abstract idea to one field of use) did not make the concept patentable. Furthermore, in Intellectual Ventures I LLC v. Capital One Bank (Fed. Cir. 2015), the court determined “an abstract idea does not become nonabstract by limiting the invention to a particular field of use or technological environment, such as the Internet [or] a computer”). These limitations do not impose any meaningful limits on practicing the abstract idea, and therefore do not integrate the abstract idea into a practical application (see MPEP 2106.05(g)). Moreover, the recited additional elements pertaining to the machine-learning model serve merely to generally link the use of the judicial exception to a particular technological environment or field of use. Specifically, it serves to limit the application of the abstract idea to artificial intelligence. This reasoning was demonstrated in Bilski and Intellectual Ventures I LLC v. Capital One Bank (Fed. Cir. 2015), as discussed above. These limitations do not impose any meaningful limits on practicing the abstract idea, and therefore do not integrate the abstract idea into a practical application (see MPEP 2106.05(g)). Yet further, the recited additional element of “training the at least one machine-learning model to distinguish between a high-risk consumer and a low-risk consumer” simply appends insignificant extra-solution activity to the judicial exception, (e.g., mere pre-solution activity, such as data gathering, in conjunction with an abstract idea; mere post-solution activity in conjunction with an abstract idea). The term “extra-solution activity” is understood as activities incidental to the primary process or product that are merely a nominal or tangential addition to the claim. The recited additional elements are deemed “extra-solution” because the training is tangentially connected to the rest of the claim. This limitation does not impose any meaningful limits on practicing the abstract idea, and does not integrate the abstract idea into a practical application (see MPEP 2106.05(h)). Lastly, the recited additional element of “an amount of data used” simply appends insignificant extra-solution activity to the judicial exception, (e.g., mere pre-solution activity, such as data gathering, in conjunction with an abstract idea; mere post-solution activity in conjunction with an abstract idea). The term “extra-solution activity” is understood as activities incidental to the primary process or product that are merely a nominal or tangential addition to the claim. The recited additional elements are deemed “extra-solution” because the feature of the “amount of data used” is nominal to the claim as it is optional to what the usage level is determined based upon (e.g., “an amount of data used or a time period using”), and it is not recited as being the trigger event, but rather what the usage level is determined based upon, and the usage level is a determinant for the trigger event. This limitation does not impose any meaningful limits on practicing the abstract idea, and does not integrate the abstract idea into a practical application (see MPEP 2106.05(h)). Furthermore, although the claims recite a specific sequence of computer-implemented functions, and although the specification suggests certain functions may be advantageous for various reasons (e.g., business reasons), the ordered combination of claim elements (i.e., the claims as a whole) are not directed to an improvement to computer functionality/capabilities, an improvement to a computer-related technology or technological environment, and do not amount to a technology-based solution to a technology-based problem. The rest of the dependent claims fail to include any additional elements. In other words, each of the limitations/elements recited in respective dependent claims are further part of the abstract idea for each respective dependent claim (i.e. they are part of the abstract idea recited in each respective claim). Thus, the additional elements, or combination of additional elements, do not integrate the abstract idea into a practical application. Accordingly, Claims 1-14 and 16-20 are directed to an abstract idea. Step 2B of the SME Analysis: As discussed above in “Step 2A – Prong 2”, the requirement to execute the claimed steps/functions using the “system comprising: at least one processor; and memory coupled to the at least one processor, the memory comprising computer executable instructions,” the computer in the “computer-implemented” recitation of Claim 1, and the “computer-readable media” of Claim 20, and the database is equivalent to adding the words “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer. These limitations therefore do not qualify as “significantly more” (see MPEP 2106.05(f)). As discussed above in “Step 2A – Prong 2”, the recited additional elements of a “smart contract,” “wherein the at least one contract term is in the form of program code,” a “stablecoin,” and different types of “crytpocurrency”, and the recited additional elements pertaining to the machine-learning model, serve merely to generally link the use of the judicial exception to a particular technological environment or field of use. These limitations therefore do not qualify as “significantly more” (see MPEP 2106.05(g)). As discussed above in “Step 2A – Prong 2”, the recited additional elements of “training the at least one machine-learning model to distinguish between a high-risk consumer and a low-risk consumer” and “an amount of data used” simply appends insignificant extra-solution activity to the judicial exception, (e.g., mere pre-solution activity, such as data gathering, in conjunction with an abstract idea; mere post-solution activity in conjunction with an abstract idea). Viewing the additional limitations in combination also shows that they fail to ensure the claims amount to significantly more than the abstract idea. When considered as an ordered combination, the additional components of the claims add nothing that is not already present when considered separately, and thus simply append the abstract idea with words equivalent to “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer, generally link the abstract idea to a particular technological environment or field of use, append the abstract idea with insignificant extra solution activity associated with the implementation of the judicial exception, (e.g., mere data gathering, post-solution activity). The remaining dependent claims fail to include any additional elements. In other words, each of the limitations/elements recited in respective dependent claims are further part of the abstract idea for each respective dependent claim (i.e. they are part of the abstract idea identified to which each respective claim is directed). Therefore, no additional element, or combination of additional claims elements are sufficient to amount to significantly more than the abstract idea. For the reasons stated above, Claims 1-14 and 16-20 as whole do not amount to significantly more than the abstract idea itself. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 1-7, 9-14, and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Arrasjid et al. (US 2020/0241929 A1)(“Arrasjid”) in view of Nazari (US 2019/0295169 A1)(“Nazari”) and further in view of Beadles et al. (US 2020/0258061 A1)(“Beadles”). As to Claim 1, Arrasjid discloses a system comprising at least one processor (processing device 802); and memory (memory 812) coupled to the at least one processor (Fig.8), the memory comprising instructions that, when executed by the at least one processor, performs a method comprising: receiving at least one contract term, wherein the at least one contract term is in the form of program code (“the terms of the validation and escrow smart contracts may be set by the client device 102 or SP system 104 individually, or may be negotiated between the two.” [0079], “The term smart contract, in this context, refers to a program or algorithm executed by nodes on a distributed ledger network.” [0077], see also [0095] and [0096]); constructing, on a blockchain (“The term smart contract, in this context, refers to a program or algorithm executed by nodes on a distributed ledger network.” [0077]), at least one smart contract based on the at least one contract term (“the terms of the validation and escrow smart contracts may be set by the client device 102 or SP system 104 individually, or may be negotiated between the two.” [0079]); receiving a deposit of assets (“the client device 102 sends a payment to the escrow contract 381” [0080], “…the transfer of funds may be in the form of a public cryptocurrency.” [0100]); recording (“The blockchain distributed ledger is illustratively configured to provide transparency and immutability of monitoring metrics for cloud services provided by the cloud service provider 104 to the client device 102, in that changes to the distributed ledger 162 are publicly viewable by all participants and the corresponding blocks cannot be altered or deleted.” [0019]) the deposit of assets on the blockchain (“…the transfer of funds may be in the form of a public cryptocurrency.” [0100], “the client device 102 sends a payment to the escrow contract 381” [0080], “The escrow smart contract provides functionality for: (i) accepting conditional payments;” [0092]); storing the assets in at least one escrow (“The blockchain distributed ledger…changes to the distributed ledger 162 are publicly viewable by all participants and the corresponding blocks cannot be altered or deleted.” [0019], and “funds provided by a user of the client device 102 are pre-paid in advance, and held by the SP system 104” [0083]); receiving at least one trigger event associated with the smart contract (“the monitoring data is evaluated by the validation smart contract (e.g., the SLA contract 361) on the distributed ledger monitoring system 106 to verify the SLA conditions specified in the initiation phase 401 have been met. Responsive to this verification, the SLA contract 361 triggers payment release by the escrow contract 381.” [0082], see also “The SLA contract 361 is responsible for verifying that the monitoring data meets the SLA conditions agreed to by the client device 102, and for triggering release of the conditional payment to the SP system 104 responsive to such verification.” [0099]), wherein the at least one trigger event is triggered in response to a determination that at least one consumer uses a specific service reaching a usage level (“The smart contract validation module 166 implements a smart contract for determining whether monitoring metrics included in monitoring envelopes provided by the monitoring envelope publishing module 146 of client agent 142 meet the quality of service metrics agreed upon between the client device 102 and the cloud service provider 104 for the requested cloud services.” [0031], “the monitoring metrics provided by the monitoring envelope publishing module 146 include information regarding the cloud resources utilized to provide the requested cloud services to the client device 102. Such information regarding cloud resources may include resource metrics such as virtual central processing unit (CPU) or vCPU in number of gigahertz (GHz), random access memory (RAM) in gigabytes (GB), storage in number of GB, network bandwidth in number of megabits per second (Mbit/s), disk input/output operations per second (IOPS), etc. The information regarding the cloud resources may also or alternatively include utilization metrics…and availability metrics” [0032], “Utilization metrics may include the percentage of time that a particular resource is busy, or the percentage of the resource’s capacity that is in use for a given time period.” “Availability metrics may include the percentage of time that a resource responded to requests.” [0096]), wherein the usage level indicates an amount of data used or a time period using the specific service (“The smart contract validation module 166 implements a smart contract for determining whether monitoring metrics included in monitoring envelopes provided by the monitoring envelope publishing module 146 of client agent 142 meet the quality of service metrics agreed upon between the client device 102 and the cloud service provider 104 for the requested cloud services. The resource release triggering module 168 triggers release of resources held by the escrow system 108 to the cloud service provider 104 if such conditions are met. If the conditions are not met, or if a designated time period has expired, the resource release triggering module 168 may return the resources to the client device 102.” [0031], “the monitoring metrics provided by the monitoring envelope publishing module 146 include information regarding the cloud resources utilized to provide the requested cloud services to the client device 102. Such information regarding cloud resources may include resource metrics such as virtual central processing unit (CPU) or vCPU in number of gigahertz (GHz), random access memory (RAM) in gigabytes (GB), storage in number of GB, network bandwidth in number of megabits per second (Mbit/s), disk input/output operations per second (IOPS), etc. The information regarding the cloud resources may also or alternatively include utilization metrics…and availability metrics” [0032], “Utilization metrics may include the percentage of time that a particular resource is busy, or the percentage of the resource’s capacity that is in use for a given time period.” “Availability metrics may include the percentage of time that a resource responded to requests.” [0096]); in response to receiving the at least one trigger event, executing the at least one contract term (“the monitoring data is evaluated by the validation smart contract (e.g., the SLA contract 361) on the distributed ledger monitoring system 106 to verify the SLA conditions specified in the initiation phase 401 have been met. Responsive to this verification, the SLA contract 361 triggers payment release by the escrow contract 381.” [0082], “The validating smart contract and escrow smart contract functions would then trigger release of a portion of these funds from the client account to the SP system 104” [0100]). Arrasjid does not directly disclose the escrow having a wallet; receiving financial data associated with the at least one consumer; based on the financial data associated with the at least one consumer, constructing at least one consumer investment profile; automatically transferring a portion of the assets to at least one investment vehicle based on the at least one consumer investment profile; wherein in an event that the at least one trigger event is determined, determining whether the at least one escrow wallet has sufficient funds; and wherein, in response to a determination that the at least one escrow wallet has insufficient funds, initiating a transfer from the at least one investment vehicle to the at least one escrow wallet. Nazari teaches receiving financial data associated with the at least one consumer (“User defines the following input parameters…” [0033], see questionnaire depicted in Fig.3 and associated text at [0033]-[0041]); based on the financial data associated with the at least one consumer (“daily analysis of the optimum targets depending on the historical information and the user profile.” [0032]), constructing at least one consumer investment profile (“performing automatic trading once the personal risk profile of the trader has been defined.” [0028]); automatically transferring a portion of the assets to at least one investment vehicle (“Cryptocurrencies, Stocks, ETFs, Indices, Bonds, Notes, Options, Futures, Commodities, Interest Rates, etc.” [0041]) based on the at least one consumer investment profile (“performing automatic trading once the personal risk profile of the trader has been defined.” [0028]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Arrasjid by the features of Nazari and in particular to include in Arrasjid, the features of: receiving financial data associated with the at least one consumer; based on the financial data associated with the at least one consumer, constructing at least one consumer investment profile; automatically transferring a portion of the assets to at least one investment vehicle based on the at least one consumer investment profile, as taught by Nazari. A person having ordinary skill in the art would have been motivated to combine these features because Arrasjid recognizes “problems associated with credit risk, cash flow” (Arrasjid, [0048]) and investing as in Nazari would help to minimize the lack of available credit and cash flow to all parties involved. Beadles teaches cryptocurrency wallets (“users/merchants to access and view their cryptocurrency wallet(s)” [0270]); wherein in an event that at least one trigger event is determined (“the smart contract contains contract functions which can be triggered by events or instructions from the payment system.” [0282], “The smart contract may interact with the user smart contract personal wallet 1040 and/or cause the subscription pay manager app 1030 to prompt the user device to approve deposit of funds from the user smart contract personal wallet to the user subscription smart contract wallet if there is an insufficient balance in the user subscription smart contract wallet for the purpose of fulfilling subscription payments or for the purpose of making a first time payment to the subscription.” [0263]), determining whether at least one escrow wallet (“user subscription smart contract wallet” [0263]) has sufficient funds (“If the blockchain subscription payment system determines the user subscription wallet token balance is insufficient to make a payment or payments according to the subscription plan (see step 2104), the system proceeds to determine if the user has enough tokens on their user smart contract personal wallet (step 2015).” [0280]); and wherein, in response to a determination that the at least one escrow wallet has insufficient funds, initiating a transfer from at least one investment vehicle (“user smart contract personal wallet” [0280]) to the at least one escrow wallet (“If the token balance of the user smart contract personal wallet is insufficient, the system proceeds to execute the smart contract function ‘Get Ethereum Balance’ which allows smart contract to determine if the user has enough ETH on their personal wallet to exchange for tokens of the type specified in the merchant subscription payment plan (step 2107). In some embodiments, this smart contract function can instead be a function to determine the balance of another type of crypto currency other than ETH or even fiat (in other words any other type of crypto currency that is not a type of token (cryptocurrency) specified by the merchant subscription payment plan but which can be exchanged for the correct type of token specified by the merchant subscription plan).” [0280], “Once the exchange is completed by the system, the tokens of the type specified by the merchant subscription plan are moved to the user smart contact smart wallet and the process can for example revert to step 2104.” [0280]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Arrasjid/Nazari combination by the features of Beadles, and in particular to include in the escrow of Arrasjid of the Arrasjid/Nazari combination, the wallet as taught by Beadles; and to include in the Arrasjid/Nazari combination, the features of: wherein in an event that the at least one trigger event is determined, determining whether the at least one escrow wallet has sufficient funds, and wherein, in response to a determination that the at least one escrow wallet has insufficient funds, initiating a transfer from the at least one investment vehicle to the at least one escrow wallet, as taught by Beadles. A person having ordinary skill in the art would have been motivated to combine these features because it would “enable customers greater flexibility” (Beadles, [0150]). As to Claim 2, the Arrasjid/Nazari/Beadles combination discloses as discussed above. The Arrasjid/Nazari/Beadles combination discloses wherein the at least one contract term comprises transferring a predetermined amount of assets from the at least one escrow wallet to at least one service-provider wallet (“The SLA contract 361 is responsible for verifying that the monitoring data meets the SLA conditions agreed to by the client device 102, and for triggering release of the conditional payment to the SP system 104 responsive to such verification.”: Arrasjid, [0099], and the feature of wallets in Beadles at [0270] in the combination is discussed above). As to Claim 3, the Arrasjid/Nazari/Beadles combination discloses as discussed above. Arrasjid further discloses recording, on the blockchain (“The distributed ledger monitoring system 106 may store and share aggregated monitoring data, which may optionally be combined with a publicly available payment ledger for transferring payment for digital services provided by the SP system 104 to the client device 102.” [0076]), a transfer of assets from the at least one escrow wallet to the at least one service-provider wallet (“…the transfer of funds may be in the form of a public cryptocurrency.” [0100], “the client device 102 sends a payment to the escrow contract 381” [0080], “The escrow smart contract provides functionality for: (i) accepting conditional payments;” [0092]). As to Claim 4, the Arrasjid/Nazari/Beadles combination discloses as discussed above. Nazari teaches wherein the financial data associated with the at least one consumer comprises at least one of: a financial report (“User defines the following input parameters…” [0033], see questionnaire depicted in Fig.3 and associated text at [0033]-[0041]), a bank statement, a credit report, a social media profile, a response to a questionnaire (“User defines the following input parameters…” [0033], see questionnaire depicted in Fig.3 and associated text at [0033]-[0041]), a background check, and a job history. As to Claim 5, the Arrasjid/Nazari/Beadles combination discloses as discussed above. Nazari teaches wherein constructing the at least one investment profile further comprises analyzing at least one database of historical financial data (“daily analysis of the optimum targets depending on the historical information and the user profile.” [0032], “sentiment measurements curve for the following keyword ‘stock market crash’ from 2004 to present.” [0049]) associated with consumers having similar investment profiles to the at least one consumer investment profile (“daily analysis of the optimum targets depending on the historical information and the user profile.” [0032], “User defines the following input parameters…” [0033], see questionnaire depicted in Fig.3 and associated text at [0033]-[0041]; one having skill in the art would understand that consumers selecting the same to similar user characteristics for their profile such as “1. What is your (user's) risk tolerance? (e.g., High, Mid High, Mid, Mid Low, Low)” as in [0034], would have the same or similar profiles). As to Claim 6, the Arrasjid/Nazari/Beadles combination discloses as discussed above. Nazari teaches wherein constructing the at least one investment profile further comprises applying at least one machine-learning model to the financial data associated with the at least one consumer (“performing automatic trading once the personal risk profile of the trader has been defined.” [0028], “User defines the following input parameters qualitatively and/or quantitatively, then the automated A.I. engine starts searching and matching investment (i.e. trading) opportunities in the asset class or a few asset classes” [0033], “Neural Networks,” [0050]). As to Claim 7, the Arrasjid/Nazari/Beadles combination discloses as discussed above. Nazari teaches wherein the at least one machine-learning model is based in part on at least one of: a linear regression, a logistic regression, a linear discriminant analysis, a regression tree, a naive Bayes algorithm, a k-nearest neighbors algorithm, a learning vector quantization, a neural network (“Neural Networks,” [0050]), a support vector machines (SVM), and a random forest algorithm. As to Claim 9, the Arrasjid/Nazari/Beadles combination discloses as discussed above. Arrasjid further discloses wherein the at least one contract term is at least one of: a pay- per-use term (“Some embodiments utilize a solution involving an advance conditional payment for services at the point of usage, rather than subsequent to usage. The advance conditional payment is automatically released to the SP when SLA conductions are met. Such approaches are well-suited for consumption-based pricing models where the SP charges clients based on resource usage instead of paying for a pre-arranged period of time. Advantageously, embodiments are able to directly associate payments with usage, at the time of usage” [0048], “Some types of monitoring data that may be used to form one or more SLA conditions include but are not limited to:…Utilization metrics may include the percentage of time that a particular resource is busy, or the percentage of the resource's capacity that is in use for a given time period.” [0096]) and a pay-per-time term (“Some types of monitoring data that may be used to form one or more SLA conditions include but are not limited to:…Availability metrics may include the percentage of time that a resource responded to requests.” [0096]). As to Claim 10, the Arrasjid/Nazari/Beadles combination discloses as discussed above. Arrasjid further discloses wherein the assets comprise at least one cryptocurrency coin (“…the transfer of funds may be in the form of a public cryptocurrency.” [0100]). As to Claim 11, the Arrasjid/Nazari/Beadles combination discloses as discussed above. Arrasjid further discloses wherein the at least one cryptocurrency coin is at least one of: a Bitcoin (“Bitcoin” [0063]), an Ether (“Ethereum cryptocurrency,” [0066]), and a stablecoin. As to Claim 12, the Arrasjid/Nazari/Beadles combination discloses as discussed above. Arrasjid further discloses wherein the at least one trigger event is an indication that usage of a service exceeded a predetermined threshold (“triggering release of such resources to the cloud service provider 104 responsive to verification that the requested cloud services provided by the cloud service provider 104 meet the quality of service metrics agreed upon” [0026]). As to Claim 13, the Arrasjid/Nazari/Beadles combination discloses as discussed above. Arrasjid further discloses wherein the usage is measured based on at least one of: data (“Some embodiments utilize a solution involving an advance conditional payment for services at the point of usage, rather than subsequent to usage. The advance conditional payment is automatically released to the SP when SLA conductions are met. Such approaches are well-suited for consumption-based pricing models where the SP charges clients based on resource usage instead of paying for a pre-arranged period of time. Advantageously, embodiments are able to directly associate payments with usage, at the time of usage” [0048]) and time (“If the agreed-upon SLA conditions are not satisfied within a defined timeframe, the escrow smart contract 381 will return the payment to the client device 102.” [0091]). As to Claim 14, the Arrasjid/Nazari/Beadles combination discloses as discussed above. Arrasjid further discloses wherein the at least one trigger event is an indication that a service is inoperable (“If the agreed-upon SLA conditions are not satisfied within a defined timeframe, the escrow smart contract 381 will return the payment to the client device 102.” [0091], “Some resources, for example, are "low-level" such as a server's resources including physical components such as CPU, memory, disks, network interfaces, etc. Resource metrics offer a detailed description of a system's state. Utilization metrics may include the percentage of time that a particular resource is busy, or the percentage of the resource's capacity that is in use for a given time period. Saturation metrics may include a measure of the amount of requested work that a resource cannot yet service. Error metrics may include internal errors that may not be observable in the work a resource produces. Availability metrics may include the percentage of time that a resource responded to requests. In some embodiments, availability metrics are limited to use with well-defined resources that can be actively and regularly checked for availability.” [0096]). As to Claim 16, Arrasjid discloses a computer-implemented method for automatically transferring assets based on a smart contract comprising: receiving at least one contract term, wherein the at least one contract term is in the form of program code (“the terms of the validation and escrow smart contracts may be set by the client device 102 or SP system 104 individually, or may be negotiated between the two.” [0079], “The term smart contract, in this context, refers to a program or algorithm executed by nodes on a distributed ledger network.” [0077], see also [0095] and [0096]); constructing, on a blockchain (“The term smart contract, in this context, refers to a program or algorithm executed by nodes on a distributed ledger network.” [0077]), at least one smart contract based on the at least one contract term (“the terms of the validation and escrow smart contracts may be set by the client device 102 or SP system 104 individually, or may be negotiated between the two.” [0079]), wherein the at least one contract term is between at least one consumer and at least one service provider (“the terms of the validation and escrow smart contracts may be set by the client device 102 or SP system 104 individually, or may be negotiated between the two.” [0079]); receiving a deposit of cryptocurrency (“the client device 102 sends a payment to the escrow contract 381” [0080], (“…the transfer of funds may be in the form of a public cryptocurrency.” [0100]); recording (“The blockchain distributed ledger is illustratively configured to provide transparency and immutability of monitoring metrics for cloud services provided by the cloud service provider 104 to the client device 102, in that changes to the distributed ledger 162 are publicly viewable by all participants and the corresponding blocks cannot be altered or deleted.” [0019]) the deposit of cryptocurrency on the blockchain (“…the transfer of funds may be in the form of a public cryptocurrency.” [0100], “the client device 102 sends a payment to the escrow contract 381” [0080], “The escrow smart contract provides functionality for: (i) accepting conditional payments;” [0092]); storing the cryptocurrency in at least one escrow (“The blockchain distributed ledger…changes to the distributed ledger 162 are publicly viewable by all participants and the corresponding blocks cannot be altered or deleted.” [0019], and “funds provided by a user of the client device 102 are pre-paid in advance, and held by the SP system 104” [0083]); receiving at least one trigger event associated with the smart contract (“the monitoring data is evaluated by the validation smart contract (e.g., the SLA contract 361) on the distributed ledger monitoring system 106 to verify the SLA conditions specified in the initiation phase 401 have been met. Responsive to this verification, the SLA contract 361 triggers payment release by the escrow contract 381.” [0082], see also “The SLA contract 361 is responsible for verifying that the monitoring data meets the SLA conditions agreed to by the client device 102, and for triggering release of the conditional payment to the SP system 104 responsive to such verification.” [0099]); in response to receiving the at least one trigger event, executing the at least one contract term (“the monitoring data is evaluated by the validation smart contract (e.g., the SLA contract 361) on the distributed ledger monitoring system 106 to verify the SLA conditions specified in the initiation phase 401 have been met. Responsive to this verification, the SLA contract 361 triggers payment release by the escrow contract 381.” [0082], “The validating smart contract and escrow smart contract functions would then trigger release of a portion of these funds from the client account to the SP system 104” [0100]) wherein the at least one trigger event is triggered in response to a determination that at least one consumer uses a specific service reaching a usage level (“The smart contract validation module 166 implements a smart contract for determining whether monitoring metrics included in monitoring envelopes provided by the monitoring envelope publishing module 146 of client agent 142 meet the quality of service metrics agreed upon between the client device 102 and the cloud service provider 104 for the requested cloud services.” [0031], “the monitoring metrics provided by the monitoring envelope publishing module 146 include information regarding the cloud resources utilized to provide the requested cloud services to the client device 102. Such information regarding cloud resources may include resource metrics such as virtual central processing unit (CPU) or vCPU in number of gigahertz (GHz), random access memory (RAM) in gigabytes (GB), storage in number of GB, network bandwidth in number of megabits per second (Mbit/s), disk input/output operations per second (IOPS), etc. The information regarding the cloud resources may also or alternatively include utilization metrics…and availability metrics” [0032], “Utilization metrics may include the percentage of time that a particular resource is busy, or the percentage of the resource’s capacity that is in use for a given time period.” “Availability metrics may include the percentage of time that a resource responded to requests.” [0096]), wherein the usage level indicates an amount of data used or a time period using the specific service (“The smart contract validation module 166 implements a smart contract for determining whether monitoring metrics included in monitoring envelopes provided by the monitoring envelope publishing module 146 of client agent 142 meet the quality of service metrics agreed upon between the client device 102 and the cloud service provider 104 for the requested cloud services. The resource release triggering module 168 triggers release of resources held by the escrow system 108 to the cloud service provider 104 if such conditions are met. If the conditions are not met, or if a designated time period has expired, the resource release triggering module 168 may return the resources to the client device 102.” [0031], “the monitoring metrics provided by the monitoring envelope publishing module 146 include information regarding the cloud resources utilized to provide the requested cloud services to the client device 102. Such information regarding cloud resources may include resource metrics such as virtual central processing unit (CPU) or vCPU in number of gigahertz (GHz), random access memory (RAM) in gigabytes (GB), storage in number of GB, network bandwidth in number of megabits per second (Mbit/s), disk input/output operations per second (IOPS), etc. The information regarding the cloud resources may also or alternatively include utilization metrics…and availability metrics” [0032], “Utilization metrics may include the percentage of time that a particular resource is busy, or the percentage of the resource’s capacity that is in use for a given time period.” “Availability metrics may include the percentage of time that a resource responded to requests.” [0096]). Arrasjid does not directly disclose the escrow having a wallet; receiving financial data associated with the at least one consumer; based on the financial data associated with the at least one consumer, constructing at least one consumer investment profile; automatically transferring a portion of the cryptocurrency to at least one investment vehicle based on the at least one consumer investment profile; wherein in an event that the at least one trigger event is determined, determining whether the at least one escrow wallet has sufficient funds; and wherein, in response to a determination that the at least one escrow wallet has insufficient funds, initiating a transfer from the at least one investment vehicle to the at least one escrow wallet. Nazari teaches receiving financial data associated with the at least one consumer (“User defines the following input parameters…” [0033], see questionnaire depicted in Fig.3 and associated text at [0033]-[0041]); based on the financial data associated with the at least one consumer (“daily analysis of the optimum targets depending on the historical information and the user profile.” [0032]), constructing at least one consumer investment profile (“performing automatic trading once the personal risk profile of the trader has been defined.” [0028]); automatically transferring a portion of the cryptocurrency to at least one investment vehicle (“Cryptocurrencies, Stocks, ETFs, Indices, Bonds, Notes, Options, Futures, Commodities, Interest Rates, etc.” [0041]) based on the at least one consumer investment profile (“performing automatic trading once the personal risk profile of the trader has been defined.” [0028]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Arrasjid by the features of Nazari and in particular to include in Arrasjid, the features of receiving financial data associated with the at least one consumer; based on the financial data associated with the at least one consumer, constructing at least one consumer investment profile; automatically transferring a portion of the cryptocurrency to at least one investment vehicle based on the at least one consumer investment profile, as taught by Nazari. A person having ordinary skill in the art would have been motivated to combine these features because Arrasjid recognizes “problems associated with credit risk, cash flow” (Arrasjid, [0048]) and investing as in Nazari would help to minimize the lack of available credit and cash flow to all parties involved. Beadles teaches cryptocurrency wallets (“users/merchants to access and view their cryptocurrency wallet(s)” [0270]); wherein in an event that at least one trigger event is determined (“the smart contract contains contract functions which can be triggered by events or instructions from the payment system.” [0282], “The smart contract may interact with the user smart contract personal wallet 1040 and/or cause the subscription pay manager app 1030 to prompt the user device to approve deposit of funds from the user smart contract personal wallet to the user subscription smart contract wallet if there is an insufficient balance in the user subscription smart contract wallet for the purpose of fulfilling subscription payments or for the purpose of making a first time payment to the subscription.” [0263]), determining whether at least one escrow wallet (“user subscription smart contract wallet” [0263]) has sufficient funds (“If the blockchain subscription payment system determines the user subscription wallet token balance is insufficient to make a payment or payments according to the subscription plan (see step 2104), the system proceeds to determine if the user has enough tokens on their user smart contract personal wallet (step 2015).” [0280]); and wherein, in response to a determination that the at least one escrow wallet has insufficient funds, initiating a transfer from at least one investment vehicle (“user smart contract personal wallet” [0280]) to the at least one escrow wallet (“If the token balance of the user smart contract personal wallet is insufficient, the system proceeds to execute the smart contract function ‘Get Ethereum Balance’ which allows smart contract to determine if the user has enough ETH on their personal wallet to exchange for tokens of the type specified in the merchant subscription payment plan (step 2107). In some embodiments, this smart contract function can instead be a function to determine the balance of another type of crypto currency other than ETH or even fiat (in other words any other type of crypto currency that is not a type of token (cryptocurrency) specified by the merchant subscription payment plan but which can be exchanged for the correct type of token specified by the merchant subscription plan).” [0280], “Once the exchange is completed by the system, the tokens of the type specified by the merchant subscription plan are moved to the user smart contact smart wallet and the process can for example revert to step 2104.” [0280]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Arrasjid/Nazari combination by the features of Beadles, and in particular to include in the escrow of Arrasjid of the Arrasjid/Nazari combination, the wallet as taught by Beadles; and to include in the Arrasjid/Nazari combination, the features of: wherein in an event that the at least one trigger event is determined, determining whether the at least one escrow wallet has sufficient funds, and wherein, in response to a determination that the at least one escrow wallet has insufficient funds, initiating a transfer from the at least one investment vehicle to the at least one escrow wallet, as taught by Beadles. A person having ordinary skill in the art would have been motivated to combine these features because it would “enable customers greater flexibility” (Beadles, [0150]). As to Claim 17, the Arrasjid/Nazari/Beadles combination discloses as discussed above. Arrasjid further discloses wherein the cryptocurrency coin comprises at least one of: a Bitcoin (“Bitcoin” [0063]), an Ether (“Ethereum cryptocurrency,” [0066]), and a stablecoin. As to Claim 18, the Arrasjid/Nazari/Beadles combination discloses as discussed above. Nazari teaches wherein constructing the at least one consumer investment profile further comprises: analyzing at least one database of historical financial data (“daily analysis of the optimum targets depending on the historical information and the user profile.” [0032], “sentiment measurements curve for the following keyword ‘stock market crash’ from 2004 to present.” [0049]) and applying at least one machine-learning model to the at least one consumer investment profile (“performing automatic trading once the personal risk profile of the trader has been defined.” [0028], “User defines the following input parameters qualitatively and/or quantitatively, then the automated A.I. engine starts searching and matching investment (i.e. trading) opportunities in the asset class or a few asset classes” [0033]). As to Claim 19, the Arrasjid/Nazari/Beadles combination discloses as discussed above. Nazari teaches wherein the at least one machine-learning model is based on at least one of: a linear regression, a logistic regression, a linear discriminant analysis, a regression tree, a naive Bayes algorithm, a k-nearest neighbors algorithm, a learning vector quantization, a neural network (“Neural Networks,” [0050]), a support vector machines (SVM), and a random forest algorithm. As to Claim 20, Arrasjid discloses a computer-readable media (memory 812) storing computer executable instructions that when executed cause a computing system (processing device 802) to perform a method comprising: receiving at least one contract term, wherein the at least one contract term is in the form of program code (“the terms of the validation and escrow smart contracts may be set by the client device 102 or SP system 104 individually, or may be negotiated between the two.” [0079], “The term smart contract, in this context, refers to a program or algorithm executed by nodes on a distributed ledger network.” [0077], see also [0095] and [0096]) and wherein the at least one contract term specifies a transfer of assets from an escrow to a service-provider (“The escrow contract 381 provides an escrow service responsible for releasing funds or payment to the SP system 104 responsive to validation by the SLA contract 361.” [0077]); constructing, on a blockchain (“The term smart contract, in this context, refers to a program or algorithm executed by nodes on a distributed ledger network.” [0077]), at least one smart contract based on the at least one contract term, wherein the at least one smart contract is between at least one consumer and at least one service provider (“the terms of the validation and escrow smart contracts may be set by the client device 102 or SP system 104 individually, or may be negotiated between the two.” [0079]); receiving a deposit of at least one cryptocurrency (“the client device 102 sends a payment to the escrow contract 381” [0080], (“…the transfer of funds may be in the form of a public cryptocurrency.” [0100]); recording (“The blockchain distributed ledger is illustratively configured to provide transparency and immutability of monitoring metrics for cloud services provided by the cloud service provider 104 to the client device 102, in that changes to the distributed ledger 162 are publicly viewable by all participants and the corresponding blocks cannot be altered or deleted.” [0019]) the deposit of the at least one cryptocurrency on the blockchain (“…the transfer of funds may be in the form of a public cryptocurrency.” [0100], “the client device 102 sends a payment to the escrow contract 381” [0080], “The escrow smart contract provides functionality for: (i) accepting conditional payments;” [0092]); storing the at least one cryptocurrency in the at least one escrow (“The blockchain distributed ledger…changes to the distributed ledger 162 are publicly viewable by all participants and the corresponding blocks cannot be altered or deleted.” [0019], and “funds provided by a user of the client device 102 are pre-paid in advance, and held by the SP system 104” [0083]); receiving at least one trigger event associated with the smart contract (“the monitoring data is evaluated by the validation smart contract (e.g., the SLA contract 361) on the distributed ledger monitoring system 106 to verify the SLA conditions specified in the initiation phase 401 have been met. Responsive to this verification, the SLA contract 361 triggers payment release by the escrow contract 381.” [0082], see also “The SLA contract 361 is responsible for verifying that the monitoring data meets the SLA conditions agreed to by the client device 102, and for triggering release of the conditional payment to the SP system 104 responsive to such verification.” [0099]); in response to receiving the at least one trigger event, transferring a second portion of the at least one cryptocurrency to the at least one service-provider (“The validating smart contract and escrow smart contract functions would then trigger release of a portion of these funds from the client account to the SP system 104” [0100]); and recording (“The blockchain distributed ledger is illustratively configured to provide transparency and immutability of monitoring metrics for cloud services provided by the cloud service provider 104 to the client device 102, in that changes to the distributed ledger 162 are publicly viewable by all participants and the corresponding blocks cannot be altered or deleted.” [0019]) the transfer of the second portion of the at least one cryptocurrency to the at least one service-provider on the blockchain (“…the transfer of funds may be in the form of a public cryptocurrency.” [0100]) wherein the at least one trigger event is triggered in response to a determination that at least one consumer uses a specific service reaching a usage level (“The smart contract validation module 166 implements a smart contract for determining whether monitoring metrics included in monitoring envelopes provided by the monitoring envelope publishing module 146 of client agent 142 meet the quality of service metrics agreed upon between the client device 102 and the cloud service provider 104 for the requested cloud services.” [0031], “the monitoring metrics provided by the monitoring envelope publishing module 146 include information regarding the cloud resources utilized to provide the requested cloud services to the client device 102. Such information regarding cloud resources may include resource metrics such as virtual central processing unit (CPU) or vCPU in number of gigahertz (GHz), random access memory (RAM) in gigabytes (GB), storage in number of GB, network bandwidth in number of megabits per second (Mbit/s), disk input/output operations per second (IOPS), etc. The information regarding the cloud resources may also or alternatively include utilization metrics…and availability metrics” [0032], “Utilization metrics may include the percentage of time that a particular resource is busy, or the percentage of the resource’s capacity that is in use for a given time period.” “Availability metrics may include the percentage of time that a resource responded to requests.” [0096]), wherein the usage level indicates an amount of data used or a time period using the specific service (“The smart contract validation module 166 implements a smart contract for determining whether monitoring metrics included in monitoring envelopes provided by the monitoring envelope publishing module 146 of client agent 142 meet the quality of service metrics agreed upon between the client device 102 and the cloud service provider 104 for the requested cloud services. The resource release triggering module 168 triggers release of resources held by the escrow system 108 to the cloud service provider 104 if such conditions are met. If the conditions are not met, or if a designated time period has expired, the resource release triggering module 168 may return the resources to the client device 102.” [0031], “the monitoring metrics provided by the monitoring envelope publishing module 146 include information regarding the cloud resources utilized to provide the requested cloud services to the client device 102. Such information regarding cloud resources may include resource metrics such as virtual central processing unit (CPU) or vCPU in number of gigahertz (GHz), random access memory (RAM) in gigabytes (GB), storage in number of GB, network bandwidth in number of megabits per second (Mbit/s), disk input/output operations per second (IOPS), etc. The information regarding the cloud resources may also or alternatively include utilization metrics…and availability metrics” [0032], “Utilization metrics may include the percentage of time that a particular resource is busy, or the percentage of the resource’s capacity that is in use for a given time period.” “Availability metrics may include the percentage of time that a resource responded to requests.” [0096]). Arrasjid does not directly disclose the escrow and the service-provider having wallets; that the cryptocurrency is a stablecoin; receiving financial data associated with the at least one consumer, wherein the financial data is at least one of: a financial record, a bank statement, a credit report, a background check, and a response to a questionnaire; receiving financial data associated with at least one database of historical financial data; based on the financial data associated with the at least one consumer and the financial data associated with the at least one database of historical financial data, constructing at least one consumer investment profile, wherein constructing at least one consumer investment profile further comprises applying at least one machine-learning model to the financial data associated with the at least one consumer; automatically investing a first portion of the at least one stablecoin in at least one investment vehicle based on the at least one consumer investment profile; wherein in an event that the at least one trigger event is determined, determining whether the at least one escrow wallet has sufficient funds; and wherein, in response to a determination that the at least one escrow wallet has insufficient funds, initiating a transfer from the at least one investment vehicle to the at least one escrow wallet. Nazari teaches receiving financial data associated with the at least one consumer (“User defines the following input parameters…” [0033]), wherein the financial data is at least one of: a financial record, a bank statement, a credit report, a background check, and a response to a questionnaire (see questionnaire depicted in Fig.3 and associated text at [0033]-[0041]); receiving financial data associated with at least one database of historical financial data (“daily analysis of the optimum targets depending on the historical information and the user profile.” [0032], “sentiment measurements curve for the following keyword ‘stock market crash’ from 2004 to present.” [0049]); based on the financial data associated with the at least one consumer and the financial data associated with the at least one database of historical financial data (“daily analysis of the optimum targets depending on the historical information and the user profile.” [0032]), constructing at least one consumer investment profile (“performing automatic trading once the personal risk profile of the trader has been defined.” [0028]), wherein constructing at least one consumer investment profile further comprises applying at least one machine-learning model to the financial data associated with the at least one consumer (“performing automatic trading once the personal risk profile of the trader has been defined.” [0028], “User defines the following input parameters qualitatively and/or quantitatively, then the automated A.I. engine starts searching and matching investment (i.e. trading) opportunities in the asset class or a few asset classes” [0033]); automatically investing a first portion of the at least one in at least one investment vehicle (“Cryptocurrencies, Stocks, ETFs, Indices, Bonds, Notes, Options, Futures, Commodities, Interest Rates, etc.” [0041]) based on the at least one consumer investment profile (“performing automatic trading once the personal risk profile of the trader has been defined.” [0028]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Arrasjid by the features of Nazari and in particular to include in Arrasjid, the features of receiving financial data associated with the at least one consumer, wherein the financial data is at least one of: a financial record, a bank statement, a credit report, a background check, and a response to a questionnaire; receiving financial data associated with at least one database of historical financial data; based on the financial data associated with the at least one consumer and the financial data associated with the at least one database of historical financial data, constructing at least one consumer investment profile, wherein constructing at least one consumer investment profile further comprises applying at least one machine-learning model to the financial data associated with the at least one consumer; automatically investing a first portion of the at least one in at least one investment vehicle based on the at least one consumer investment profile, as taught by Nazari. A person having ordinary skill in the art would have been motivated to combine these features because Arrasjid recognizes “problems associated with credit risk, cash flow” (Arrasjid, [0048]) and investing as in Nazari would help to minimize the lack of available credit and cash flow to all parties involved. Beadles teaches cryptocurrency wallets (“users/merchants to access and view their cryptocurrency wallet(s)” [0270]); stablecoin (“DAI and TUSD,” [0278]); wherein in an event that at least one trigger event is determined (“the smart contract contains contract functions which can be triggered by events or instructions from the payment system.” [0282], “The smart contract may interact with the user smart contract personal wallet 1040 and/or cause the subscription pay manager app 1030 to prompt the user device to approve deposit of funds from the user smart contract personal wallet to the user subscription smart contract wallet if there is an insufficient balance in the user subscription smart contract wallet for the purpose of fulfilling subscription payments or for the purpose of making a first time payment to the subscription.” [0263]), determining whether at least one escrow wallet (“user subscription smart contract wallet” [0263]) has sufficient funds (“If the blockchain subscription payment system determines the user subscription wallet token balance is insufficient to make a payment or payments according to the subscription plan (see step 2104), the system proceeds to determine if the user has enough tokens on their user smart contract personal wallet (step 2015).” [0280]); and wherein, in response to a determination that the at least one escrow wallet has insufficient funds, initiating a transfer from at least one investment vehicle (“user smart contract personal wallet” [0280]) to the at least one escrow wallet (“If the token balance of the user smart contract personal wallet is insufficient, the system proceeds to execute the smart contract function ‘Get Ethereum Balance’ which allows smart contract to determine if the user has enough ETH on their personal wallet to exchange for tokens of the type specified in the merchant subscription payment plan (step 2107). In some embodiments, this smart contract function can instead be a function to determine the balance of another type of crypto currency other than ETH or even fiat (in other words any other type of crypto currency that is not a type of token (cryptocurrency) specified by the merchant subscription payment plan but which can be exchanged for the correct type of token specified by the merchant subscription plan).” [0280], “Once the exchange is completed by the system, the tokens of the type specified by the merchant subscription plan are moved to the user smart contact smart wallet and the process can for example revert to step 2104.” [0280]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Arrasjid/Nazari combination by the features of Beadles, and in particular to include in the escrow of Arrasjid of the Arrasjid/Nazari combination, the wallet as taught by Beadles; to include in the cryptocurrency of Arrasjid in the Arrasjid/Nazari combination, the stablecoin, as taught by Beadles; and to include in the Arrasjid/Nazari combination, the features of: wherein in an event that the at least one trigger event is determined, determining whether the at least one escrow wallet has sufficient funds, and wherein, in response to a determination that the at least one escrow wallet has insufficient funds, initiating a transfer from the at least one investment vehicle to the at least one escrow wallet, as taught by Beadles. A person having ordinary skill in the art would have been motivated to combine these features because it would “enable customers greater flexibility” (Beadles, [0150]). Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Arrasjid in view of Nazari, in view of Beadles, and further in view of Yang et al. (US 2020/0090268 A1)(“Yang”). As to Claim 8, the Arrasjid/Nazari/Beadles combination discloses as discussed above. Arrasjid does not directly disclose training the at least one machine-learning model to distinguish between a high-risk consumer and a low-risk consumer. Yang teaches training the at least one machine-learning model to distinguish between a high-risk consumer and a low-risk consumer (“a method for determining a risk level of a user” [0029], “training a machine classification model” [0057], [0062], “in the dimension of risk tolerance, risk tolerance levels of users may be classified into five categories: low, medium to low, medium, medium to high, and high.” [0041]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Arrasjid/Nazari/Beadles combination by the feature of Yang and in particular to include in Nazari’s machine-learning model in the Arrasjid/Nazari/Beadles combination, the feature of training the at least one machine-learning model to distinguish between a high-risk consumer and a low-risk consumer, as taught by Yang. A person having ordinary skill in the art would have been motivated to combine these features because “[t]o better serve a user, an Internet platform needs to evaluate a subjective risk preference degree of the user, so as to push suitable financial products to the user according to the risk preference degree of the user, or evaluate whether a financial product sold to the user is suitable for the user.” (Yang, [0025]). Response to Arguments Applicant’s arguments filed in the November 2025 Remarks have been fully considered and addressed below. On pages 9-10, Applicant argues that the previously applied prior art references do not disclose the new limitations of “wherein in an event that the at least one trigger event is determined, determining whether the at least one escrow wallet has sufficient funds; and wherein, in response to a determination that the at least one escrow wallet has insufficient funds, initiating a transfer from the at least one investment vehicle to the at least one escrow wallet.” However, the rejection has been updated such that a new reference- Beadles, is relied upon to teach those limitations. Therefore, the argument is now moot. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to MONICA A MANDEL whose telephone number is (571)270-7046. The examiner can normally be reached Monday and Thursday 10:00 AM-6:00 PM. 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, Ilana Spar can be reached at (571) 270-7537. 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. /M.A.M/Examiner, Art Unit 3622 /ILANA L SPAR/Supervisory Patent Examiner, Art Unit 3622 1 See Subject Matter Eligibility Analysis for Products and Processes in MPEP §2106 III.
Read full office action

Prosecution Timeline

Mar 05, 2021
Application Filed
Mar 16, 2023
Non-Final Rejection — §101, §103
Jul 18, 2023
Applicant Interview (Telephonic)
Jul 18, 2023
Response Filed
Jul 18, 2023
Examiner Interview Summary
Oct 07, 2023
Final Rejection — §101, §103
Dec 11, 2023
Interview Requested
Jan 12, 2024
Response after Non-Final Action
Jan 23, 2024
Applicant Interview (Telephonic)
Jan 27, 2024
Response after Non-Final Action
Feb 12, 2024
Request for Continued Examination
Feb 14, 2024
Response after Non-Final Action
Dec 28, 2024
Non-Final Rejection — §101, §103
Apr 14, 2025
Response Filed
Apr 21, 2025
Applicant Interview (Telephonic)
Apr 21, 2025
Examiner Interview Summary
Aug 09, 2025
Final Rejection — §101, §103
Nov 13, 2025
Request for Continued Examination
Nov 22, 2025
Response after Non-Final Action
Feb 07, 2026
Non-Final Rejection — §101, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12437279
TECHNIQUES FOR PERFORMING AUTHENTICATION IN ECOMMERCE TRANSACTIONS
2y 5m to grant Granted Oct 07, 2025
Patent 11941591
DEVICE INCLUDING ENCRYPTED DATA FOR EXPIRATION DATE AND VERIFICATION VALUE CREATION
2y 5m to grant Granted Mar 26, 2024
Patent 11868170
SIMPLE NONAUTONOMOUS PEERING MEDIA CLONE DETECTION
2y 5m to grant Granted Jan 09, 2024
Patent 11763335
REAL-TIME DISTRIBUTION OF CRYPTOCURRENCY REWARDS FOR A LOYALTY PROGRAM
2y 5m to grant Granted Sep 19, 2023
Patent 11734393
CONTENT DISTRIBUTION WITH RENEWABLE CONTENT PROTECTION
2y 5m to grant Granted Aug 22, 2023
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

5-6
Expected OA Rounds
18%
Grant Probability
27%
With Interview (+8.9%)
6y 9m
Median Time to Grant
High
PTA Risk
Based on 324 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month