DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Applicant filed a response dated October 28, 2025 in which claims 1, 9, 11, 19, 25, and 28 have been amended, claims 2-5, 8, 10, 12-15, 18, and 20 have been canceled, and claims 31-32 have been added. Therefore, claims 1, 6-7, 9, 11, 16-17, 19, and 21-32 are currently pending in the application.
Priority
Application 18/217,330 was filed on June 30, 2023 and claims benefit of 63/440,328 January 20, 2023.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 U.S.C. § 112(a) or § 112 1st paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
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, 6-7, 9, 11, 16-17, 19, and 21-32 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. (MPEP 2106). The claims are directed to a method, system, and apparatus which is one of the statutory categories of invention (Step 1: YES). The recitation of the claimed invention is analyzed as follows, in which the abstract elements are boldfaced.
Claim 11 recites the limitations of:
A non-transitory computer-readable medium comprising instructions for automatically triggering interactions between virtual accounts, the instructions, when executed by a computing system, causing the computing system to perform operations including: maintaining a virtual account structure including a plurality of virtual accounts mapped to a single physical account, the plurality of virtual accounts including a payor virtual account, an intermediary virtual account for a single deal, and a payee virtual account, wherein the single deal defines a first expected obligation of the payor virtual account to the deal virtual account and a second expected obligation of the deal virtual account to the payee virtual account;
receiving a first push notification, from a first webhook attached to the payor virtual account, of a change in available assets in the payor virtual account;
responsive to receiving the first push notification, comparing the available assets in the payor virtual account to the first expected obligation of the payor virtual account, the first expected obligation of the payor virtual account identifying the intermediary virtual account to which assets are to be transferred;
responsive to the available assets in the payor virtual account matching the first expected obligation within a first threshold tolerance,
automatically transferring an intended portion of the available assets from the payor virtual account to the intermediary virtual account without transferring assets to or from the single physical account; and
receiving a second push notification, from a second webhook attached to the intermediary virtual account, of a change in available assets in the intermediary virtual account due to the transfer from the payor virtual account;
responsive to receiving the second push notification, comparing the available assets in the intermediary virtual account to the second expected obligation of the intermediary virtual account, the second expected obligation of the intermediary virtual account identifying the payee virtual account to which assets are to be transferred; and
responsive to the available assets held in the intermediary virtual account matching the second expected obligation within a second threshold tolerance,
automatically transferring the intended portion of the assets in the intermediary virtual account to the payee virtual account,
wherein the change in available assets in the payor virtual account and the automatic transfer of the intended portion of the available assets from the payor virtual account to the intermediary virtual account and then from the intermediary account to the payee virtual account all occur in one day.
The claim as a whole recites a method that, under its broadest reasonable interpretation, covers collecting, analyzing, and transmitting data to facilitate a financial processing and accounting system and transfer of assets between accounts of a payor and payee. This is a fundamental economic practice of a financial transaction; a commercial interaction, such as for business relations; and managing personal behavior or relationships or interactions between people, which are certain methods of organizing human activity.
Thus, the claims recite an abstract idea. (Step 2A, prong 1: YES).
Moreover, the judicial exception is not integrated into a practical application. Other than reciting a “A non-transitory computer-readable medium comprising instructions for automatically triggering interactions between virtual accounts, the instructions, when executed by a computing system, causing the computing system to perform operations including:”, “a first push notification”, “a first webhook attached to the payor virtual account”, “a second push notification”, and “a second webhook attached to the intermediary virtual account”, to perform the steps of “maintaining”, “comparing”, and “transferring”, nothing in the claim elements preclude the steps from practically being a certain method for organizing human activity. The claim as a whole does not integrate the exception into a practical application. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data to facilitate a financial processing and accounting system and transfer of assets between accounts of a payor and payee in a computer environment. The additional computer elements recited in the claim limitations are recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception utilizing generic computer components.
For example, the Specification at [0020] discloses “the client devices 140 may be desktop computers, laptop computers, tablets, smartphones, or the like, with which the user accesses functionality of the accounts system 110 or interactions triggering system 120 via the network 170 using a web browser or dedicated application. The client devices 140 may interact with the other elements of the networked computing environment 100 using an application programming interface (API). Although FIG. 1 shows to client devices 140 (a payor client device 140A used by a user that is transferring value to a payee and a payee client device 140B used by the payee that is receiving the value from the payor), the networked computing environment 100 can include any number of such devices (and will typically include many more).” Additionally, at [0045] “the storage device 508 is a non-transitory computer-readable storage medium such as a hard drive, compact disk read-only memory (CD- ROM), DVD, or a solid-state memory device. The memory 506 holds instructions and data used by the processor 502.”
Thus, the specification supports that general purpose computers or computer components are utilized to implement the steps of the abstract idea.
Merely implementing the abstract idea on a generic computer is not a practical application of the abstract idea. The claim as a whole, in viewing the additional elements both individually and in combination, does not integrate the judicial exception into a practical application. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. (Step 2A prong two: No)
The claim does not include additional elements, when considered both individually and as an ordered combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using “A non-transitory computer-readable medium comprising instructions for automatically triggering interactions between virtual accounts, the instructions, when executed by a computing system, causing the computing system to perform operations including:”, “a first push notification”, “a first webhook attached to the payor virtual account”, “a second push notification”, and “a second webhook attached to the intermediary virtual account”, to perform the steps of “maintaining”, “comparing”, and “transferring”, amounts to no more than mere instructions to apply the exception using generic computer component. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data to facilitate a financial processing and accounting system and transfer of assets between accounts of a payor and payee in a computer environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e. an inventive concept) to the abstract idea. Such additional elements are determined to not contain an inventive concept according to MPEP 2106.05(f). It should be noted that (1) the “recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not provide significantly more because this type of recitation is equivalent to the words “apply it”, and (2) “Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice, commercial interaction, or managing personal behavior or relationships or interactions between people, mental process, or mathematical calculation) does not integrate a judicial exception into a practical application or provide significantly more”.
Claims 1 and 25 are substantially similar to claim 1, thus, they are rejected on similar grounds.
Claim 1 recites the additional elements of “A computer-implemented method of automatically triggering interactions between virtual accounts, the method comprising:”.
Claim 25 recites the additional elements of “A computing system for automatically triggering interactions between virtual accounts, the computing system comprising: one or more processors; and one or more non-transitory computer-readable media comprising instructions that, when executed collectively by at least some of the one or more processors, cause the computing system to perform operations including:”.
For similar reasons as explained above with regard to claim 11, under Step 2A, prong two, these additional elements are merely applying generic computer components to implement the abstract idea. Under Step 2B, when viewing the additional elements individually and in combination, the additional elements do not amount to an inventive concept amounting to significantly more than the judicial exception itself as the claimed computer-related technologies are mere tools for implementing the abstract idea as explained with regard to claim 11.
Dependent claims 6-7, 9, 16-17, 19, 21-24, and 26-32 merely limit the abstract idea and do not recite any further additional elements beyond the cited abstract idea and the elements addressed above, thus, they do not amount to significantly more. The dependent claims are abstract for the reasons presented above because there are no additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Thus, the dependent claims are directed to an abstract idea. (Step 2B: No)
Therefore, claims 1, 6-7, 9, 11, 16-17, 19, and 21-32 are not patent-eligible.
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.
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, 6-7, 9, 11, 16-17, 19, and 21-32 are rejected under 35 U.S.C. 103 as being unpatentable over Meggs, U.S. Patent Application Publication Number 2022/0358501; in view of Ingargiola, U.S. Patent Application Publication Number 2024/0370927; in view of Crawford, U.S. Patent Application Publication Number 2021/0365944.
As per claim 11,
Meggs explicitly teaches:
payor virtual account
(Meggs US20220358501 at Figs. 4,5 and paras. 66-68)
intermediary virtual account
(Meggs US20220358501 at Figs. 4,5 and paras. 75-78)
A non-transitory computer-readable medium comprising instructions for automatically triggering interactions between virtual accounts, the instructions, when executed by a computing system, causing the computing system to perform operations including: maintaining a virtual account structure including a plurality of virtual accounts mapped to a single physical account, the plurality of virtual accounts including a payor virtual account, an intermediary virtual account for a single deal, and a payee virtual account, wherein the single deal defines a first expected obligation of the payor virtual account to the deal virtual account and a second expected obligation of the deal virtual account to the payee virtual account;
(Meggs US20220358501 at paras. 102-112) ([0103] "Virtual bill accounts 46 are relatively inexpensive to implement and relatively easy to manage and use, plus they are addressable. More particularly, each virtual bill account 46 has an externally addressable routing and account number from which checks and ACH transactions can be drawn. The VSE platform 31 accordingly may incorporate recent Fintech developments in virtual account management and ledgering to facilitate a more advanced form of healthcare sharing. In the VSE platform 31, all accounts that are created and activated within the VSE module 37 enjoy the benefits of a physical bank account. Member share accounts 33, provider accounts 44 and virtual bill accounts 46 all reside within the VSE/FBO Module 37, which may be implemented within a single physical bank account held by a financial institution. The FBO account at the financial institution is held and titled “for the benefit of” the sharing network's members 36. All account transactions within the VSE/FBO account are “on us” transactions and are simple to initiate and manage, and may be done for relatively little or no cost." [0104] "This VSE platform enables the automated creation, activation and deactivation of numerous addressable single purpose virtual bill accounts 46 for each medical bill 38 submitted to the sharing network. This advantageously allows a healthcare sharing network with the ability to create a virtual account and ledger for every unique medical bill published and shared by the community. Moreover, each virtual bill account 46 within the VSE/FBO module 37 is externally addressable with a routing number and account number, as noted above. This enables the VSE module 37 with the ability to coordinate and ledger sharing transactions between bill owners and bill contributors and then, through the use of the addressable account number, transfer funds as payment to the provider account 44 that resides inside of the VSE module, or another account that reside outside of the VSE module in a physical bank account with any bank. This enables the ledgering and full reconciliation from the beginning point of publishing a bill for sharing to the end point of paying a provider who exists inside or outside of the sharing system." [0105] "The virtual bill accounts 46 are single purpose accounts that are dynamically created and activated within the VSE/FBO module 37 for a specific purpose (which, in the present example, is paying a given medical bill 38), and thereafter they are deactivated and archived whenever that specific purpose is complete. This process will now be described further with reference to the sequence flow diagram 150 of FIG. 7.")
automatically transferring an intended portion of the available assets from the payor virtual account to the intermediary virtual account without transferring assets to or from the single physical account; and
(Meggs US20220358501 at Figs. 4,5 and paras. 66-68) ("[0068] The monthly share amount funds may be remitted by the member 36 via the VSE's banking module 35. As the funds come into the VSE platform 31, they appear on the member's GUI portal 60. Through an integration with the VSE's billing module 49, the banking module 35 automatically moves the appropriate amount of funds into distinct, corresponding virtual accounts as indicated. For the funds related to the portion for administrative fees and services, they are moved to a corresponding share network account 39. Funds held in the share network accounts 39 are owned and managed by the sharing network 40 and may be withdrawn from the VSE platform 31 into an external account at any point by the sharing network.")
automatically transferring the intended portion of the assets in the intermediary virtual account to the payee virtual account,
(Meggs US20220358501 at Figs. 4,5 and paras. 75-78) ("[0077] Once the matching of funds to a bill occurs, as part of the publishing process (Blocks 87-88), the publishing module 43 restricts the dollars accordingly in the contributing member's share account 33. Each share network 40 may have its own protocol for how notification to contributing members is executed, e.g., via the share network's customer relations management (CRM) tool. Bills matched, allocated and published (i.e., notification) for sharing remain in a published state for a period of time (e.g., three days), which may be configured by the share network 40. This is called the “publishing period”. The publishing period satisfies additional regulatory requirements by giving notice of sharing before funds are transferred and allowing members to withdraw from membership before funds are transferred. Thus, the publishing of matched bills 38 and the allocated publishing period satisfies the “voluntary sharing” requirement of most regulatory statutes. After the publishing period is satisfied, the restricted funds are then moved (Block 89) into the recipient's share account 33. Those moved funds would now appear as used in the GUI 60. The moved funds are similarly restricted to the recipient and indicated as an active bill (section 63) until they are moved into the provider account 44 (Block 90), and subsequently to the medical provider's external account 45 (Block 91). The method of FIG. 4 illustratively concludes at Block 92.")
Meggs does not explicitly teach, however, Ingargiola does teach:
Initially, Examiner notes that Meggs explicitly teaches: “receiving a first . . . notification . . . of a change in available assets in the payor virtual account”;
“ . . . comparing the available assets in the payor virtual account to the first expected obligation of the payor virtual account, the first expected obligation of the payor virtual account identifying the intermediary virtual account to which assets are to be transferred”;
“receiving a second . . . notification . . . of a change in available assets in the intermediary virtual account due to the transfer from the payor virtual account”; and
“ . . . comparing the available assets in the intermediary virtual account to the second expected obligation of the intermediary virtual account, the second expected obligation of the intermediary virtual account identifying the payee virtual account to which assets are to be transferred”. (See Meggs US20220358501 at Figs. 1, 4, 5, and paras. 6, 7, 65-69)
Furthermore, in combination with Meggs, Ingargiola explicitly teaches the following:
receiving a first push notification, from a first webhook attached to the payor virtual account, of a change in available assets in the payor virtual account;
(Ingargiola US20240370927 at paras. 257-263) ("[0258] With the Ocp-Apim-Subscription-Key, the block trading platform 2306 can make API calls to Trader's SilverGate account on behalf of user. The block trading platform 2306 will make API calls to SilverGate 2302, 2308 to register an account balance change the web hook for the Trader's account. With help of webhook, if there is any change in balance of Trader's SilverGate account, the block trading platform 2306 will be notified. In an alternate approach-SilverGate can create a master API key for the block trading platform 2306, so that the block trading platform 2306 can lock and unlock funds on Trader's behalf. One benefit of this approach is that the block trading platform 2306 will not have to ask SilverGate API details from Trader in the Exchange Trader UI.")
responsive to receiving the first push notification, comparing the available assets in the payor virtual account to the first expected obligation of the payor virtual account, the first expected obligation of the payor virtual account identifying the intermediary virtual account to which assets are to be transferred;
(Ingargiola US20240370927 at paras. 257-263) ("[0259] In step 3, the block trading platform 2306 will make “balance API” call to SilverGate to get account balances for Trader 1 2304 and Trader 2 2310. An “Untokenized balance” will be shown on the Exchange Trader UI. The Trader can allocate a certain amount of funds to be tokenized on the block trading platform 2306. The block trading platform 2306 will make API calls to SilverGate to lock the funds. The “Locked funds” will be shown as available balance for Trader to trade on the block trading platform 2306. At the block trading platform 2306, if there is no ledger, then a ledger will be automatically created for SilverGate and Trader's balance will be recorded in SilverGate's ledger. Trader 1 2304 and Trader 2 2310 will see the balances on Trader UI and are now enabled to do an OTC trade. A new feature to make this process work is a new SilverGate API that is created to enable funds to be locked. [0260] In step 4, Trader 1 2304 and Trader 2 2310 will perform a trade on the block trading platform 2306 or LiquiMatch ECN (electronic communication network) with tokenized funds (digital representation of the locked funds on the Exchange provided custodian blockchain ledger). In step 5, after the trade is recorded on the block trading platform 2306 or LiquiMatch ECN, the block trading platform 2306 will make a transfersen API call to transfer money from Trader 1 into Trader 2 SEN account 2032, 2308 and vice-versa.")
receiving a second push notification, from a second webhook attached to the intermediary virtual account, of a change in available assets in the intermediary virtual account due to the transfer from the payor virtual account;
(Ingargiola US20240370927 at paras. 282-285) ("[0283] In a settlement recording step, after assets are committed into transactions as described elsewhere and/or are received, notifications of the transactions will be authenticated and trigger a single atomic transaction covering an atomic transaction for the movement of residual quantities going both directions between CUST1 and CUST2 in any of the above described methods and the below two atomic transactions on an exchange platform to record special net settlement transaction as follows. [0284] The two example transactions can include: Transaction 1—CUST1_USD Ledger=(T4 UTXO+T5 UTXO+T6 UTXO)->CUST2 UTXO; and Transaction 2—CUST2_USD Ledger=Coinbase Transaction->(T4 UTXO+T5 UTXO+T6 UTXO). In first transaction, on CUST1_USD ledger, UTXOs available to Custodian 2 traders—Trader 4, Trader 5 and Trader 6 are combined and assigned to Custodian 2 public key. In second Transaction, a coinbase transaction is made on CUST2_USD ledger and UTXO is assigned Trader 4, Trader 5 and Trader 6. Above two transactions achieve transfer of UTXOs from CUST1_USD ledger to CUST2_USD ledger, reflecting the cross-custodian net settlement on a blockchain as proof. Alternatively, a separate special blockchain ledger can be created on the governance node to record cross-custodian net settlement.")
responsive to receiving the second push notification, comparing the available assets in the intermediary virtual account to the second expected obligation of the intermediary virtual account, the second expected obligation of the intermediary virtual account identifying the payee virtual account to which assets are to be transferred; and
(Ingargiola US20240370927 at paras. 282-285) ("[0283] In a settlement recording step, after assets are committed into transactions as described elsewhere and/or are received, notifications of the transactions will be authenticated and trigger a single atomic transaction covering an atomic transaction for the movement of residual quantities going both directions between CUST1 and CUST2 in any of the above described methods and the below two atomic transactions on an exchange platform to record special net settlement transaction as follows. [0284] The two example transactions can include: Transaction 1—CUST1_USD Ledger=(T4 UTXO+T5 UTXO+T6 UTXO)->CUST2 UTXO; and Transaction 2—CUST2_USD Ledger=Coinbase Transaction->(T4 UTXO+T5 UTXO+T6 UTXO). In first transaction, on CUST1_USD ledger, UTXOs available to Custodian 2 traders—Trader 4, Trader 5 and Trader 6 are combined and assigned to Custodian 2 public key. In second Transaction, a coinbase transaction is made on CUST2_USD ledger and UTXO is assigned Trader 4, Trader 5 and Trader 6. Above two transactions achieve transfer of UTXOs from CUST1_USD ledger to CUST2_USD ledger, reflecting the cross-custodian net settlement on a blockchain as proof. Alternatively, a separate special blockchain ledger can be created on the governance node to record cross-custodian net settlement.")
wherein the change in available assets in the payor virtual account and the automatic transfer of the intended portion of the available assets from the payor virtual account to the intermediary virtual account and then from the intermediary account to the payee virtual account all occur in one day.
(Ingargiola US20240370927 at paras.4-5, 145, 256-257, 322) ("[0257] Clients only hold a single Fiat account at the custodian 2302 and a single cryptocurrency account at a cryptocurrency custodian 2308 and can trade with any other counterparties on the network 2306 with instant clearing and settlement of both the Fiat and cryptocurrency leg atomically.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Meggs and Ingargiola, because it can provide technical benefits in other applications or use cases that rely on time-critical data or cryptographic lineage or provability of data that may or may not be distributed across systems and/or disaggregated. For example, the approaches herein can be implemented to provide a new technical framework for timely access to time-critical data in robotic applications, autonomous driving applications, extended reality applications, Internet of things (IoT) applications, automation applications, supply-chain applications, disaster recovery applications, payments from one party to another, etc.” (Ingargiola at Abstract and paras. 2-11, 76, 160, 161).
Meggs and Ingargiola do not explicitly teach, however, Crawford does teach:
responsive to the available assets in the [payor virtual] account matching the first expected obligation within a first threshold tolerance,
(Crawford US20210365944 at paras. 44-45, 81-87, 102-106) ("[0105] After the default or base payment condition is defined, like in paths AA, BB and CC, the user has the option to add one or more additional conditions in the same manner as in paths AA, BB and CC. In this case, the Bill pay plan condition types include but are not limited to: (i) Funding account balance, (ii) Recent Income (iii) Recent income from certain sources (iv) Date of scheduled transfer, (v) Amount due, (vi) Bill due date and (vii) Current deposit amount. In some embodiments, for options (ii) and (iii) above, the user is able to next define an amount of time to go back and calculate “recent income.” In some embodiments, like above, for (iii) the user is able to specify which income should be included by entering multiple separated “tags” to use to search for certain funding account deposits to mark for inclusion in this income calculation). In some embodiments, options (v) and (vi) are available only if the user has successfully connected his/her account to a partner company's cooperating API). Conditional operators for the options above may include but are not limited to (for all dollar amounts) (i) is less than, (ii) is less than or equal to, (iii) is more than, (iv) is more than or equal to, (v) is between or equal to, (for dates of scheduled transfers) (i) is before, (ii) is on or before, (iii) is after, (iv) is on or after, (v) is on or between, (vi) is on, and (for bill due date) (i) is past due, and (ii) is coming up within a certain interval (user enters an interval). The user is then able to enter a dollar amount, or two amounts in the case of defining a range, along with a new action to take for each of the new conditions. For example, the new actions are able to be one or more of, Pay bill automatically, Pay a fixed amount (where the user enters the fixed amount to pay) and Do not pay. When the user is finished setting up the conditions they are able to select “Next” to reach the review/edit page.")
responsive to the available assets held in the [intermediary virtual] account matching the second expected obligation within a second threshold tolerance,
(Crawford US20210365944 at paras. 44-45, 81-87, 102-106) ("[0105] After the default or base payment condition is defined, like in paths AA, BB and CC, the user has the option to add one or more additional conditions in the same manner as in paths AA, BB and CC. In this case, the Bill pay plan condition types include but are not limited to: (i) Funding account balance, (ii) Recent Income (iii) Recent income from certain sources (iv) Date of scheduled transfer, (v) Amount due, (vi) Bill due date and (vii) Current deposit amount. In some embodiments, for options (ii) and (iii) above, the user is able to next define an amount of time to go back and calculate “recent income.” In some embodiments, like above, for (iii) the user is able to specify which income should be included by entering multiple separated “tags” to use to search for certain funding account deposits to mark for inclusion in this income calculation). In some embodiments, options (v) and (vi) are available only if the user has successfully connected his/her account to a partner company's cooperating API). Conditional operators for the options above may include but are not limited to (for all dollar amounts) (i) is less than, (ii) is less than or equal to, (iii) is more than, (iv) is more than or equal to, (v) is between or equal to, (for dates of scheduled transfers) (i) is before, (ii) is on or before, (iii) is after, (iv) is on or after, (v) is on or between, (vi) is on, and (for bill due date) (i) is past due, and (ii) is coming up within a certain interval (user enters an interval). The user is then able to enter a dollar amount, or two amounts in the case of defining a range, along with a new action to take for each of the new conditions. For example, the new actions are able to be one or more of, Pay bill automatically, Pay a fixed amount (where the user enters the fixed amount to pay) and Do not pay. When the user is finished setting up the conditions they are able to select “Next” to reach the review/edit page.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Meggs, Ingargiola, and Crawford, because it can provide a dynamic personalizable automated finance management system providing a financial management platform that enables users to easily generate a plurality of customized rules or conditions associated with one or more accounts thereby creating account plans. (Crawford at Abstract and paras. 2-15).
As per claim 16,
Meggs explicitly teaches:
wherein the second expected obligation comprises the intended portion of the assets received from the payor virtual account and additional assets received from one or more additional payor virtual accounts of the plurality of virtual accounts in the account structure.
(Meggs US20220358501 at Figs. 4,5 and paras. 75-78) ("[0077] Once the matching of funds to a bill occurs, as part of the publishing process (Blocks 87-88), the publishing module 43 restricts the dollars accordingly in the contributing member's share account 33. Each share network 40 may have its own protocol for how notification to contributing members is executed, e.g., via the share network's customer relations management (CRM) tool. Bills matched, allocated and published (i.e., notification) for sharing remain in a published state for a period of time (e.g., three days), which may be configured by the share network 40. This is called the “publishing period”. The publishing period satisfies additional regulatory requirements by giving notice of sharing before funds are transferred and allowing members to withdraw from membership before funds are transferred. Thus, the publishing of matched bills 38 and the allocated publishing period satisfies the “voluntary sharing” requirement of most regulatory statutes. After the publishing period is satisfied, the restricted funds are then moved (Block 89) into the recipient's share account 33. Those moved funds would now appear as used in the GUI 60. The moved funds are similarly restricted to the recipient and indicated as an active bill (section 63) until they are moved into the provider account 44 (Block 90), and subsequently to the medical provider's external account 45 (Block 91). The method of FIG. 4 illustratively concludes at Block 92.")
As per claim 17,
Meggs explicitly teaches:
wherein the second expected obligation is to the payee virtual account and one or more additional payee virtual accounts of the plurality of virtual accounts in the account structure, and one or more additional portions of the available assets are transferred to the one or more additional payee virtual accounts.
(Meggs US20220358501 at Figs. 4,5 and paras. 75-78) ("[0077] Once the matching of funds to a bill occurs, as part of the publishing process (Blocks 87-88), the publishing module 43 restricts the dollars accordingly in the contributing member's share account 33. Each share network 40 may have its own protocol for how notification to contributing members is executed, e.g., via the share network's customer relations management (CRM) tool. Bills matched, allocated and published (i.e., notification) for sharing remain in a published state for a period of time (e.g., three days), which may be configured by the share network 40. This is called the “publishing period”. The publishing period satisfies additional regulatory requirements by giving notice of sharing before funds are transferred and allowing members to withdraw from membership before funds are transferred. Thus, the publishing of matched bills 38 and the allocated publishing period satisfies the “voluntary sharing” requirement of most regulatory statutes. After the publishing period is satisfied, the restricted funds are then moved (Block 89) into the recipient's share account 33. Those moved funds would now appear as used in the GUI 60. The moved funds are similarly restricted to the recipient and indicated as an active bill (section 63) until they are moved into the provider account 44 (Block 90), and subsequently to the medical provider's external account 45 (Block 91). The method of FIG. 4 illustratively concludes at Block 92.")
As per claim 19,
Meggs explicitly teaches:
payor virtual account
(Meggs US20220358501 at Figs. 4,5 and paras. 66-68)
transferring make-whole assets from an agent virtual account of the plurality of virtual accounts in the account structure to the payor virtual account or the intermediary account,
(Meggs US20220358501 at paras.55-56, 67-68, 131-133) ("[0132] Generally speaking, the VSE platform 31 of FIG. 16 is advantageously configured to automatically and dynamically facilitate sharing through share accounts 33 to targeted levels using dynamic reserves. Through enhancements and extensions of the VSE billing module 49, sharing networks can dynamically react to stresses and excesses of targeted reserved levels by engineering a variable bill amount (or dynamic reserve portion) to the monthly share amount (or portion) to sustain its distributed reserves. As reserves grow in excess of targeted levels, member accounts 33 are automatically credited by the VSE module 37. As reserves fall below targeted levels, member accounts 33 are debited a small amount by the VSE module 37. Incorporating a small variable amount in a monthly share notice helps a network regulate reserve targets, as well as deepens the loyalty of members 36 by helping to ensure them that the reserve amounts held in their share accounts 33 will not grow too large or too small.")
Meggs and Ingargiola do not explicitly teach, however, Crawford does teach:
wherein the operations further include, responsive to the available assets in the [payor virtual] account being less than the first expected obligation by no more than the first threshold tolerance,
(Crawford US20210365944 at paras. 44-45, 81-87, 102-106) ("[0081] Additionally, in some embodiments the policies are able to specify how to handle the case where one or more of the accounts have insufficient funds to meet the amount of their share of a withdrawal (as determined by the withdrawal policy and thresholds for those accounts). For example, the policy is able to specify that if one or more of the accounts in a combined account has insufficient funds: cancel the whole transfer (do not transfer money from any account in the group); cancel those accounts' portions/shares of the transfer and send the withdrawal amount from the remaining accounts of the combined account with sufficient funds; send as much as possible from each of those accounts and then send the remaining withdrawal amount from the remaining accounts of the combined account; set up a linear insufficient funds priority/order to use one account to pick up all insufficient funds, then a second if the first falls short, a third, and so on as the user desires (wherein if there are not enough funds in the last account to cover the difference, all available money will be sent from all actively funding accounts in the group) or distribute the difference equally between the other funding accounts, paying as much from all accounts as possible if there's not enough to fund the whole amount with equal portions. Additionally, in some embodiments if two or more accounts have insufficient funds, or if one or more of the “overflow accounts” has insufficient funds to cover the whole amount of the difference from the account(s) with insufficient funds, as much as possible is able to be transferred from each account and the remaining balance owed is able to continue to be covered equally among any accounts in the account group with remaining funds.")
wherein the available assets in the [payor virtual] account and the make-whole assets collectively match the first expected obligation.
(Crawford US20210365944 at paras. 44-45, 81-87, 102-106) ("[0081] Additionally, in some embodiments the policies are able to specify how to handle the case where one or more of the accounts have insufficient funds to meet the amount of their share of a withdrawal (as determined by the withdrawal policy and thresholds for those accounts). For example, the policy is able to specify that if one or more of the accounts in a combined account has insufficient funds: cancel the whole transfer (do not transfer money from any account in the group); cancel those accounts' portions/shares of the transfer and send the withdrawal amount from the remaining accounts of the combined account with sufficient funds; send as much as possible from each of those accounts and then send the remaining withdrawal amount from the remaining accounts of the combined account; set up a linear insufficient funds priority/order to use one account to pick up all insufficient funds, then a second if the first falls short, a third, and so on as the user desires (wherein if there are not enough funds in the last account to cover the difference, all available money will be sent from all actively funding accounts in the group) or distribute the difference equally between the other funding accounts, paying as much from all accounts as possible if there's not enough to fund the whole amount with equal portions. Additionally, in some embodiments if two or more accounts have insufficient funds, or if one or more of the “overflow accounts” has insufficient funds to cover the whole amount of the difference from the account(s) with insufficient funds, as much as possible is able to be transferred from each account and the remaining balance owed is able to continue to be covered equally among any accounts in the account group with remaining funds.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Meggs, Ingargiola, and Crawford, because it can provide a dynamic personalizable automated finance management system providing a financial management platform that enables users to easily generate a plurality of customized rules or conditions associated with one or more accounts thereby creating account plans. (Crawford at Abstract and paras. 2-15).
As per claim 23,
Meggs explicitly teaches:
wherein the operations further include transferring, responsive to the intended portion of the assets being transferred to the payee virtual account, at least some of the intended portion of the assets to an agent virtual account.
(Meggs US20220358501 at Figs. 4,5 and paras. 66-68) ("[0068] The monthly share amount funds may be remitted by the member 36 via the VSE's banking module 35. As the funds come into the VSE platform 31, they appear on the member's GUI portal 60. Through an integration with the VSE's billing module 49, the banking module 35 automatically moves the appropriate amount of funds into distinct, corresponding virtual accounts as indicated. For the funds related to the portion for administrative fees and services, they are moved to a corresponding share network account 39. Funds held in the share network accounts 39 are owned and managed by the sharing network 40 and may be withdrawn from the VSE platform 31 into an external account at any point by the sharing network.")
As per claim 24,
Meggs does not explicitly teach, however, Ingargiola teaches:
wherein the operations further include initiating, responsive to the intended portion of the assets being transferred to the payee virtual account, a wire transfer of at least some of the intended portion of the assets from the single physical account to a physical account of the payee.
(Ingargiola US20240370927 at paras. 213-215, 226, 242, 278, 304) ("[0214] Step 4: If the redeeming party are both clients of the same sponsoring firm then the sponsoring firm can perform internal debit/credit transactions. If the redeeming party is not at the same sponsoring firm, then C1 1504 unblocks T1's funds and remits the funds to T2 1510 pursuant to the payment instructions submitted by T2 1510, usually in the form of a wire transfer from C1 1504 to T2's designated custodial or other specified bank account or a wallet transfer from C1 1504 to T2's custodial or other specified wallet, as may be permitted by the sponsoring firm's internal AML/KYC procedures.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Meggs, Ingargiola, and Crawford, because it can provide technical benefits in other applications or use cases that rely on time-critical data or cryptographic lineage or provability of data that may or may not be distributed across systems and/or disaggregated. For example, the approaches herein can be implemented to provide a new technical framework for timely access to time-critical data in robotic applications, autonomous driving applications, extended reality applications, Internet of things (IoT) applications, automation applications, supply-chain applications, disaster recovery applications, payments from one party to another, etc.” (Ingargiola at Abstract and paras. 2-11, 76, 160, 161).
As per claim 32,
Meggs explicitly teaches:
intermediary virtual account
(Meggs US20220358501 at Figs. 4,5 and paras. 66-68)
transferring make-whole assets from an agent virtual account of the plurality of virtual accounts in the account structure to the intermediary account or the payee virtual account,
(Meggs US20220358501 at paras.55-56, 67-68, 131-133) ("[0132] Generally speaking, the VSE platform 31 of FIG. 16 is advantageously configured to automatically and dynamically facilitate sharing through share accounts 33 to targeted levels using dynamic reserves. Through enhancements and extensions of the VSE billing module 49, sharing networks can dynamically react to stresses and excesses of targeted reserved levels by engineering a variable bill amount (or dynamic reserve portion) to the monthly share amount (or portion) to sustain its distributed reserves. As reserves grow in excess of targeted levels, member accounts 33 are automatically credited by the VSE module 37. As reserves fall below targeted levels, member accounts 33 are debited a small amount by the VSE module 37. Incorporating a small variable amount in a monthly share notice helps a network regulate reserve targets, as well as deepens the loyalty of members 36 by helping to ensure them that the reserve amounts held in their share accounts 33 will not grow too large or too small.")
Meggs and Ingargiola do not explicitly teach, however, Crawford does teach:
wherein the operations further include, responsive to the available assets in the [intermediary virtual] account being less than the second expected obligation by no more than the second threshold tolerance,
(Crawford US20210365944 at paras. 44-45, 81-87, 102-106) ("[0081] Additionally, in some embodiments the policies are able to specify how to handle the case where one or more of the accounts have insufficient funds to meet the amount of their share of a withdrawal (as determined by the withdrawal policy and thresholds for those accounts). For example, the policy is able to specify that if one or more of the accounts in a combined account has insufficient funds: cancel the whole transfer (do not transfer money from any account in the group); cancel those accounts' portions/shares of the transfer and send the withdrawal amount from the remaining accounts of the combined account with sufficient funds; send as much as possible from each of those accounts and then send the remaining withdrawal amount from the remaining accounts of the combined account; set up a linear insufficient funds priority/order to use one account to pick up all insufficient funds, then a second if the first falls short, a third, and so on as the user desires (wherein if there are not enough funds in the last account to cover the difference, all available money will be sent from all actively funding accounts in the group) or distribute the difference equally between the other funding accounts, paying as much from all accounts as possible if there's not enough to fund the whole amount with equal portions. Additionally, in some embodiments if two or more accounts have insufficient funds, or if one or more of the “overflow accounts” has insufficient funds to cover the whole amount of the difference from the account(s) with insufficient funds, as much as possible is able to be transferred from each account and the remaining balance owed is able to continue to be covered equally among any accounts in the account group with remaining funds.")
wherein the available assets in the [intermediary virtual] account and t