DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
2. Applicant filed the Request for Continued Examination on 11/07/2025. Claims 9-20 are pending. Claims 9 and 17 are amended. Claims 1-8 are canceled. Claims 9-20 are rejected. After careful consideration of applicant arguments, the examiner finds them to be not persuasive.
Rejection under 35 USC § 101
3. Applicant’s arguments toward 35 U.S.C. § 101 rejection are not persuasive. Amended independent claims 9 and 17 do not have additional elements that could lead to an improvement in the functioning of a computer, or an improvement to other technology or technical field.
4. Applicant is of the opinion that “claim 9 recites limitations that cannot be practically performed in the human mind”, lists some amended claim limitations, and concludes that “the claim goes beyond mere methods of organizing human activity, and instead recites specific computational features which cannot be performed in the human mind… claim 9 is not directed to a judicial exception”.
Examiner respectfully disagrees.
Independent claims 9 and 17 recite generating and managing a transfer of resources to a shared account which is grouped under “Certain methods of organizing human activity” (e.g. commercial interactions), but not “Mental processes” as Applicant indicated.
5. Applicant is of the opinion that the amended independent claim 9 is integrated into a practical application by stating that, “the features of claim 9 solve technical problems relating to secure and dynamic linking of online financial accounts across different provider systems. The features of claim 9 solve these technical problems by, among other features, enabling conditional logic and system-level interactions that vary based on whether the account is internal or external to a provider computing system. This achieves a particular desired outcome, resulting in greater consistency between account linking workflows and data exchange protocols for financial account applications, thereby improving user experiences with linking online financial accounts”.
Examiner respectfully disagrees.
Mentioned in response to the office action claims’ features performed by using the computer components. The use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field.
6. Applicant is of the opinion “that the claim features, when viewed individually or as an ordered combination, go beyond routine or conventional components configured in a known manner, and instead recite elements which amount to significantly more than any alleged judicial exception.”
Examiner respectfully disagrees.
Applicant’s argument is not persuasive for the reasons already discussed above – the additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field. As per the identification of the “additional elements” under Step 2A Prong Two and Step 2B, the rejection properly identifies the elements which are recited in the claim beyond the abstract idea, including a computing system, a network interface, a plurality of user devices, a plurality of provider devices, a first database, a second database, one or more processors, a first user device, a second user device, a first user element, a second user element, generating a dialogue box, and a database. Under Step 2A Prong Two, the “additional elements” have been identified and the limitations are not indicative of integration into a practical application. Under Step 2B, the additional elements have been evaluated and do not amount to “significantly more”. Note that Revised Step 2A overlaps with Step 2B, and thus, many of the considerations need not be reevaluated in Step 2B because the answer will be the same. The identification of the additional elements in the claim from Step 2A Prong Two is carried over as well as the conclusion from Step 2A Prong Two on the considerations discussed in MPEP 2106.05(a)-(c), (e), (f), and (h).
The claims are not patent eligible.
Rejections under 35 U.S.C. § 103
7. Applicant is of the opinion that the prior art reference Norman et al. does not teach or suggest the amended claim 9 limitations.
Examiner respectfully disagrees.
Applicant arguments are no longer applicable because they are moot in light of the new ground of rejection.
Claim Rejections - 35 USC § 101
8. 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.
9. Claims 9-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.
10. In the instant case, claims 9 and 17 are directed to a “system, and a non-transitory computer readable medium for shared account transactions”.
11. Claim 9 recites “generating and managing a transfer of resources to a shared account”. Specifically, claim recites “receiving … a request from … a first user, the request to form a shared account accessible by a second user, wherein the request includes a plurality of rules associated with the shared account; generating the shared account; linking a first account of the first user with the shared account; identifying the second user based on the request to form the shared account; transmitting … a notification … associated with the second user, the notification indicating the second user has access to the shared account; receiving … an input … indicating acceptance of access to the shared account; linking a second account of the second user with the shared account, wherein linking the second account comprises: receiving … in a first instance in which the second account is associated with the first provider, a second input… the second input including an account number associated with the second account; or receiving … in a second instance in which the second account is not associated with the first provider, a third input … the third input including a selection of a second provider from associated with the second provider, and a fourth input … the fourth input including a selection of the second account; and
establishing … between the second account and the shared account; receiving … a fifth input … indicating a selection to initiate an outbound transfer of resources from the shared account to the second account, wherein the fifth input includes a selection of a category; determining that the category meets at least one of the plurality of rules; generating a second notification, the second notification comprising … ; transmitting the second notification …; receiving … a sixth input … indicating an operation … responsive … within the second notification; storing the sixth input …; receiving … a seventh input … indicating an operation …; and initiating, responsive to determining that the category meets the at least one of the plurality of rules and responsive to receiving the seventh input, the outbound transfer of resources from the shared account to the second account”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
12. This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of claim 9 such as “a computing system”, “a network interface”, “a plurality of user devices”, “a plurality of provider devices”, “a first database”, “a second database”, “one or more processors”, “a first user device”, “a second user device”, “a drop-down list of providers displayed on a user interface and log-in credentials”, “a secure link”, “a first user element”, “a second user element”, “generating a dialogue box”, and “a database” represent the use of a computer as a tool to perform an abstract idea and/or does no more than generally link the abstract idea to a particular field of use. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to (i.e., automate) the acts of generating and managing the online transfer of resources to the shared account. And, with respect to “receiving, via the network interface, a request from a first user device of a first user, the request to form a shared account accessible by a second user, wherein the request includes a plurality of rules associated with the shared account”, “transmitting, via the network interface, a notification to a second user device associated with the second user, the notification indicating the second user has access to the shared account”, “receiving, via the network interface, in a first instance in which the second account is associated with the first provider, a second input to the second user device, the second input including an account number associated with the second account”, and “receiving, via the network interface, in a second instance in which the second account is not associated with the first provider, a third input to the second user device, the third input including a selection of a second provider from a drop-down list of providers displayed on a user interface and log-in credentials associated with the second provider, and a fourth input to the second user device, the fourth input including a selection of the second account” is simply transmitting data “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more, (MPEP 2106.05(f)(2)).
13. When analyzed under step 2B (MPEP 2106.04 II), as the additional elements do no more than represent the use of a computer, or computer technology, as a tool to perform generating and managing a transfer of resources to a shared account and they do not improve computer functionality or provide an improvement to another technology or technological field.
14. Hence, claim 9 is not patent eligible.
15. Claim 17 also recites “generating and managing a transfer of resources to the shared account”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
16. As in the case of claim 9, the judicial exception is not integrated into a practical application because when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of claim 17 such as “a non-transitory computer readable medium”, “one or more processors”, “a network interface”, “a first user device”, “a second user device”, “a drop-down list of providers displayed on a user interface and log-in credentials”, “a secure link”, “a first user element”, “a second user element”, and “a database” represent the use of a computer as a tool to perform an abstract idea and/or does no more than link the abstract idea to a particular field of use. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to (i.e., automate) the acts of generating and managing a transfer of resources to a shared account. With respect to “receiving, via the network interface, a request from a first user device of a first user, the request to form a shared account accessible by the first user and by a second user for a period of time, wherein the request includes a plurality of rules associated with the shared account”, “transmitting, via the network interface, a notification to a second user device associated with the second user, the notification indicating the second user has access to the shared account”, “receiving, via the network interface, in a first instance in which the second account is associated with the first provider, a second input to the second user device, the second input including an account number associated with the second account”, and “receiving, via the network interface, in a second instance in which the second account is not associated with the first provider, a third input to the second user device, the third input including a selection of a second provider from a drop-down list of providers displayed on a user interface and log-in credentials associated with the second provider, and a fourth input to the second user device, the fourth input including a selection of the second account” is simply transmitting data “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more, (MPEP 2106.05(f)(2)).
17. When analyzed under step 2B (MPEP 2106.04 II), as the additional elements do no more than represent the use of a computer, or computer technology, as a tool to perform generating and managing a transfer of resources to a shared account and they do not improve computer functionality or provide an improvement to another technology or technological field.
18. Hence, claim 17 is not patent eligible.
19. Dependent claim 10 further describes the abstract idea of generating and managing the transfer of resources to the shared account as it recites “receiving … an input … indicating a selection to initiate an inbound transfer of resources from the first account to the shared account; wherein the input … indicates a selected category of a plurality of predetermined categories earmarking the transfer of resources; and wherein determining that the category of the outbound transfer meets at least one of the plurality of rules comprises determining that the category matches the selected category”. The additional elements such as “the network interface”, and “the first user device” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 11 further describes the abstract idea of generating and managing the transfer of resources to the shared account as it recites “determining, based on the plurality of rules associated with the shared account, that the second user is eligible to request the outbound transfer of resources”.
Dependent claim 12 further describes the abstract idea of generating and managing the transfer of resources to the shared account as it recites “wherein the initiating of the outbound transfer of resources is …. communicably coupled to …”. The additional elements such as “a third party service provider computer” and “the computing system” represent the use of a computer as a tool to perform an abstract idea and does no more than generally link the abstract idea to a particular field of use. And, therefore, does not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 13 further describes the abstract idea of generating and managing the transfer of resources to the shared account as it recites “wherein the plurality of rules associated with the shared account comprises an expiration date of the shared account, and wherein the instructions, when executed … to perform the steps of: determining that an amount of resources remain in the shared account at the expiration date; initiating a first outbound transfer of a first subset of the amount of resources remaining in the shared account to the first account; and initiating a second outbound transfer of a second subset of the amount of resources remaining in the shared account to the second account”. The additional element such as “the one or more processors” represents the use of a computer as a tool to perform an abstract idea and does no more than generally link the abstract idea to a particular field of use. And, therefore, does not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 14 further describes the abstract idea of generating and managing the transfer of resources to the shared account as each recites “wherein the first subset and the second subset are based on an allotment of resources between the first account and the second account defined by the plurality of rules associated with the shared account”.
Dependent claim 15 further describes the abstract idea of generating and managing the online transfer of resources to the shared account as each recites “wherein a ratio between the first subset and the second subset is equal to a ratio of an inbound transfer of resources from the first account to an inbound transfer of resources from the second account”.
Dependent claim 16 further describes the abstract idea of generating and managing the transfer of resources to the shared account as it recites “wherein the plurality of rules associated with the shared account define a balance goal of the shared account, and wherein the instructions, when executed … to perform the steps of: determining, based on the balance goal, a first amount of resources owed by the first account and a second amount of resources owed by the second account; transmitting … a first notification … indicating to initiate a first inbound transfer of resources from the first account to the shared account; and transmitting … a second notification … indicating to initiate a second inbound transfer of resources from the second account to the shared account”. The additional elements such as “the one or more processors”, “the network interface”, “the first user device”, and “the second user device” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 18 further describes the abstract idea of generating and managing the transfer of resources to the shared account as it recites “receiving … an input … indicating a selection to initiate an inbound transfer of resources from the first account to the shared account; wherein the input … indicates a selected category of a plurality of predetermined categories earmarking the transfer of resources; and wherein determining that the category of the outbound transfer meets at least one of the plurality of rules comprises determining that the category matches the selected category”. The additional elements such as “the network interface”, and “the first user device” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 19 further describes the abstract idea of generating and managing the transfer of resources to the shared account as it recites “wherein the initiating of the outbound transfer of resources is …”. The additional element such as “a third party service provider computer” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 20 further describes the abstract idea of generating and managing the transfer of resources to the shared account as it recites “determining that an amount of resources remain in the shared account after the period of time; initiating a first outbound transfer of a first subset of the amount of resources remaining in the shared account to the first account; and initiating a second outbound transfer of a second subset of the amount of resources remaining in the shared account to the second account”.
Conclusion
20. The claims as a whole do not amount to significantly more than the abstract idea itself. This is because the claims do not effect an improvement to another technology or technical field; the claims do not amount to an improvement to the functioning of a computer system itself; and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment.
21. Accordingly, there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself.
Claim Rejections - 35 USC § 103
22. 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.
23. 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.
24. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
25. Claims 9-20 are rejected under 35 U.S.C. 103 as being unpatentable over US20190325442A1 to Norman et al. in view of US20190370787A1 to Mueller et al., US10530761B2 to Hockey et al., and US11574359B1 to Ball et al.
26. As per claims 9 and 17:
Norman et al. discloses the following limitations:
a network interface (Fig.1, item 118) configured to communicate with a plurality of user devices and a plurality of provider devices (Fig.1, items 102, 106, 108, 110; [0029] “…System environment 100 may include one or more networks 102, financial institutions 106, third-party service providers 110, and user devices 108. Each of the networks 102, financial institutions 106, and third-party service providers 110 may comprise one or more computing devices or servers, databases, cloud services, and/or internal networks…”)
a first database structured to store a plurality of accounts of a first provider (Fig.1, items 110, 140; [0029] “…Each of the networks 102, financial institutions 106, and third-party service providers 110 may comprise one or more computing devices or servers, databases, cloud services, and/or internal networks…”, [0042] “…Rules may be established and stored in an account owner's financial account 130 by financial institution 106, in a service account 140 of third-party service provider 110, or both…”)
a second database structured to store a plurality of shared accounts (Fig.1, items 106, 130; [0029] “…Each of the networks 102, financial institutions 106, and third-party service providers 110 may comprise one or more computing devices or servers, databases, cloud services, and/or internal networks…”, [0039] “Financial institution 106 in system environment 100 may include any entity that generates, provides, manages, and/or maintains financial service accounts 130, etc., for customers…”)
one or more processors ([0012] “Certain disclosed embodiments provide systems for transferring funds from a first account to a second account, which may comprise one or more memory devices storing instructions, and one or more processors…”)
memory storing instructions that, when executed by the one or more processors, cause the one or more processors to perform the steps ([0038] “In some embodiments, one or more of financial institution 106, third-party service provider 110, and/or network 102 may include or may access one or more storage devices configured to store data and/or software instructions used by one or more processors to perform operations consistent with disclosed embodiments…”)
receiving, via the network interface, a request from a first user device of a first user, the request to form a shared account accessible by a second user, wherein the request includes a plurality of rules associated with the shared account (Fig.2A, items 106, 108, 110, 131, 132; fig.3, item 302; [0043] “One or more financial institutions 106 and/or one or more third-party service providers 110 may host a web application, API, web site, or similar interface that is accessible over network 102 to account owners via user device 108… Graphical user interface 118 may also provide an interface enabling the disclosed functions herein, including, among other things, authorizations to transfer funds, authorizations to share information and link financial accounts, establish rules for transferring funds between linked accounts, and track and monitor transfers and the status of financial accounts.”, [0044] “…To enable transfers from first account 131 to second account 132, an account owner may send a request to link first account 131 with second account 132. The request may be sent from user device 108 that is registered to an account owner, where the request may be received by one or more of financial institution 106 and third-party service provider 110…”, [0051] “At step 302, financial institution 106 and/or third-party service provider 110 may receive a request to link first account 131 with second account 132 via graphical user interface 118 of user device 108…”)
linking a first account of the first user with the shared account (Fig.2A, items 131, 132; fig.3, item 304; [0044] “…In response, owner of second account 132 may authorize, via user device 108 and graphical user interface 118, the request to link first account 131 with second account 132. The authorization may be sent back to third-party service providers 110 and/or financial institution 106, which will link accounts and enable information sharing between owners of first account 131 and second 132.”, [0052] “…Upon receipt of the authorization, financial institution 106 and/or third-party service provider 110 may link first account 131 with the second account 132 at step 304.”)
identifying the second user based on the request to form the shared account ([0051] “…The request to link accounts may include information about each of first account 131 and second account 132, including identifiers for these accounts and details related to account ownership. The request may be processed by one or more of financial institution 106 or third-party service provider 110 to determine whether the accounts can be linked and if sufficient information has been provided to link accounts…”)
transmitting, via the network interface, a notification to a second user device associated with the second user, the notification indicating the second user has access to the shared account ([0052] “Once financial institution 106 and/or third-party service provider 110 has determined that first account 131 and second account 132 are eligible to be linked, financial institution 106 and/or third-party service provider 110 may send an authorization to link the accounts to one (or more) owners of first account 131 and second account 132…”, [0053] “…The shared information may be transmitted using a secure link, tunnel, portal, or any other known secure data transfer protocol known for securely sending data over a public or private network. The shared information may be transferred from financial institution 106 and/or third-party service provider 110 to user device 108 over network 102…”)
receiving, via the network interface, an input to the second user device indicating acceptance of access to the shared account ([0044] (…To enable transfers from first account 131 to second account 132, an account owner may send a request to link first account 131 with second account 132… In response, owner of second account 132 may authorize, via user device 108 and graphical user interface 118, the request to link first account 131 with second account 132…”)
Norman et al. does not disclose, however, Mueller et al., as shown, teaches the following limitations:
generating the shared account (Fig.6, items 622, 624; [0062] “At operation 622, the shared access payment account system 26 receives a request from the user, such as the primary cardholder 502, to create a shared account number 520 (shown in FIG. 5). The primary cardholder 502 may link one or more PANs and/or virtual PANs to the shared account number 520 at operation 624)
linking a second account of the second user with the shared account, wherein linking the second account comprises (Fig.5, items 502, 504, 520; [0051] “…After establishing the shared account number 520, the primary cardholder 502 may invite one or more secondary cardholders 504 to link to the shared account number 520. For example, and without limitation, the primary cardholder 502 may choose one or more secondary cardholders 504 having a user account 508 with the shared access payment account system 26, using for example, the shared access account application 28. The secondary cardholders 504 may receive a notification 518 that a shared account number 520 is available for use. Alternatively, in some embodiments, the primary cardholder 502 may send a message, such as an SMS message, to one or more of the secondary cardholders 504 notifying them that a shared account number 520 is available for use…”)
receiving, via the network interface, a fifth input to the second user device indicating a selection to initiate an outbound transfer of resources from the shared account to the second account, wherein the fifth input includes a selection of a category ([0065] “At operation 630, the shared access payment account system 26 transmits the shared account information, e.g., the linked PANs and/or virtual PANs, to the secondary cardholder's digital wallet 306… At an operation 632, the shared access payment account system 26 receives a transaction authorization message. The shared access payment account system 26 checks transaction information contained in the authorization message against the limitations 516 established for the shared account number 520 at operation 634. The shared access payment account system 26 declines the transaction if it is determined that the transaction violates a limitation 516 imposed on the shared account number 520 and allows the transaction if it is determined that it does not …”)
determining that the category meets at least one of the plurality of rules (Fig.5, item 516; [0052] “As discussed above, the shared access payment account system 26 stores limitations 516 that are established by the primary cardholder 502. The limitation 516 may be established, for example, by specifying restrictions or approvals of the use of the shared account number 520 by one or more of the secondary cardholders 504…”, [0065] “…At operation 636, the shared access account application 28 transmits notifications 518 to the primary cardholder 502 including details of transactions made by the secondary cardholder 504, including for example, whether the transaction violated one or more limitations 516…”)
generating a second notification, the second notification comprising a first user element and a second user element ([0060] “After the user account 508 is complete and the user (e.g., the primary or secondary cardholders 502 and 504, respectively) has been setup or onboarded with the shared access payment account system 26, the method 600 proceeds with authenticating the user, as shown in FIG. 6…”)
transmitting the second notification to the second user device ([0060] “…At operation 608, upon receipt of the user account 508, the biometrics module 512 generates a user activation code. The biometrics module 512 then transmits the user activation code to the user via the user's email address at operation 610.”)
receiving, via the network interface, a sixth input to the second user device indicating an operation of the first user element responsive … within the second notification (Fig.5, items 26 32, 502, 516; [0050] “… the shared access payment account system 26 allows for communication between the shared access account application 28 and the digital wallet 306 (shown in FIG. 3) to send, receive, and store information related to, for example, and without limitation, the shared account number 520, limitations 516 set for the secondary cardholders 504 associated with the shared account number 520, notifications 518 of transactions made though the shared account number 520, etc.”)
storing the sixth input in a database (Fig.5, item 516; [0050] “… the shared access payment account system 26 allows for communication between the shared access account application 28 and the digital wallet 306 (shown in FIG. 3) to send, receive, and store information related to, for example, and without limitation, the shared account number 520, limitations 516 set for the secondary cardholders 504…”, [0064] “… The shared access payment account system 26 stores the limitations 516 that are established by the primary cardholder 502, for example, in database 24.”)
receiving, via the network interface, a seventh input to the second user device indicating an operation of the second user element (Fig.6, item 632; [0065] “… At an operation 632, the shared access payment account system 26 receives a transaction authorization message…”)
initiating, responsive to determining that the category meets the at least one of the plurality of rules and responsive to receiving the seventh input, the outbound transfer of resources from the shared account to the second account (Fig.6, items 634, 636; [0065] “… The shared access payment account system 26 checks transaction information contained in the authorization message against the limitations 516 established for the shared account number 520 at operation 634… At operation 636, the shared access account application 28 transmits notifications 518 to the primary cardholder 502 including details of transactions made by the secondary cardholder 504, including for example, whether the transaction violated one or more limitations 516…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for creating a shared account number upon receiving a request from the primary cardholder and linking the primary account number to the shared account number of Mueller et al. (‘787, [0006]) with teaching of Norman et al. for transferring funds from a first account to a second account that improve the ability to automatically or semi-automatically transfer funds from a first account to a second account based on activity (‘442, [0010]) to creating a shared account number by linking one or more account numbers, storing transaction elements such as time limit, spending amount, and the like, determining whether the transaction rules meets the established limitations, and allowing a transaction made by a secondary account owner (‘787, [0062], [0064]-[0065]).
Neither Norman et al. nor Mueller et al. disclose, however, Hockey et al., as shown, teaches the following limitations:
receiving, via the network interface, in a first instance in which the second account is associated with the first provider, a second input to the second user device, the second input including an account number associated with the second account (Col/line 4/65-5/6 “According to yet another aspect, the specified account is a user account of the financial application system, wherein a plurality of application proxy instances corresponding to the specified user account are used to access financial data from a plurality of external financial service systems, and wherein financial data provided to the application system corresponds to accounts of the external financial service systems that are associated with user credentials of the application proxy instances.”)
receiving, via the network interface, in a second instance in which the second account is not associated with the first provider, a third input to the second user device, the third input including a selection of a second provider from a drop-down list of providers displayed on a user interface and log-in credentials associated with the second provider, and a fourth input to the second user device, the fourth input including a selection of the second account (Col.3, lines 22-37 “The present disclosure describes various embodiments of interactive and dynamic user interfaces that are the result of significant development. This non-trivial development has resulted in the user interfaces described herein which may provide significant cognitive and ergonomic efficiencies and advantages over previous systems… For example, user interaction with the interactive user interface via the inputs described herein may provide an optimized display of, and interaction with, transaction and account data and may enable a customer user to more quickly and accurately access, navigate, assess, and digest the account data than previous systems.”, col.6, lines 8-35 “According to yet another aspect, the normalized financial service request is a request for a list of transactions for the user account, wherein financial service systems corresponding to the normalized financial service request include financial service systems corresponding to application proxy instances for the user account of the external application system, and wherein each proprietary API request is a request for financial data of accounts corresponding to user credentials of the associated application proxy instance used to provide the proprietary API request. According to another aspect, providing the normalized financial service response comprises transforming the received financial data into a normalized form, and wherein transforming the received financial data comprises at least one of processing the financial data, cleaning the financial data, supplementing the financial data with additional information, and enhancing the financial data, and wherein additional information includes at least one of categorical labels, tags, and geo location information. According to yet another aspect, the normalized financial service request is a request for details of a transaction associated with the user account, wherein the normalized financial service request specifies information identifying the transaction, the associated financial service system, and the associated account of the financial service system, and wherein the proprietary API request is a request for details of the transaction of the specified account of the specified financial service system.”)
establishing a secure link between the second account and the shared account (Col.6, lines 36-49 “According to another aspect, the normalized financial service request is a financial transfer request, wherein the normalized financial service request specifies information identifying a source financial service system, a source account of the source financial service system, a destination financial service system, a destination account of the destination financial service system, and a transaction amount, and wherein at least one of an application proxy instance of the source financial service system and an application proxy instance of the destination financial service system is used to initiate the financial transfer request to transfer the specified transaction amount from the source account to the destination account by providing a proprietary transfer API request to the respective financial service system.”, col/line 6/58-7/15 “According to yet another embodiment, a method is disclosed comprising a financial platform system receiving a normalized financial API request associated with at least one financial account endpoint, the normalized financial API request being provided by an external financial application system by using a financial platform API of the financial platform system, the normalized financial API request specifying account credentials of each financial account endpoint of the normalized financial API request; responsive to the normalized financial API request: collecting transaction information of each financial account endpoint of the normalized financial API request by using an application proxy instance associated with the financial account endpoint to collect the transaction information from a corresponding financial institution system by using the associated account credentials specified by the normalized financial API request and a proprietary Application Programming Interface (API) of the financial institution system; and providing a normalized financial API response to the external financial application system, the normalized financial API response providing the transaction information of each financial account endpoint of the normalized financial API request, wherein each application proxy instance is constructed to simulate an application of the corresponding external financial institution system.”, col.8, lines 4-30 “According to yet another embodiment, a method is disclosed comprising a financial platform system constructed to programmatically access at least one external financial institution system external to the financial platform system, and responsive to a normalized financial API request provided by a financial application system by using a financial platform API of the financial platform system, the normalized financial API request specifying user information corresponding to at least one financial account endpoint of the at least one external financial institution system: using at least one application proxy instance associated with the normalized API request to collect transaction information from a corresponding financial institution system by providing the financial institution system with a proprietary financial API request that specifies at least account credentials associated with the user information specified by the normalized financial API request, the transaction information being included in at least one proprietary financial API response provided by the financial institution system; generating a normalized financial API response based on the collected transaction information; and providing the normalized financial API response to the financial application system, wherein each application proxy instance is constructed to simulate an application of the corresponding financial institution system on behalf of a user associated with the application proxy instance.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for creating a shared account number upon receiving a request from the primary cardholder and linking the primary account number to the shared account number of Mueller et al. (‘787, [0006]) and systems that significantly more efficient at obtaining user account data from external systems than previous techniques, wherein the user account data may be normalized and requested and/or provided via a normalized API, enabling others to efficiently access such data from a single standardized interface in a highly efficient manner of Hockey et al. (‘761, col.2, lines 20-27) with teaching of Norman et al. for transferring funds from a first account to a second account that improve the ability to automatically or semi-automatically transfer funds from a first account to a second account based on activity (‘442, [0010]) for managing financial account endpoint that can be identified by account credentials, providing account credentials to access specific accounts, and managing multiple different financial institutions simultaneously, selecting interface from searchable list format (‘761, (Col/line 4/65-5/6, col.6, lines 8-35, col/line 6/58-7/15).
Neither Norman et al. nor Mueller et al. or Hockey et al. disclose, however, Ball et al., as shown, teaches the following limitations:
[receiving] … generating a dialogue box … (Figs.5C-5D, item 530, col.22, lines 30-34 “The navigation portion 522 provides the customer with access points to various functionalities described herein. As shown, the navigation portion 522 includes a dynamic icon 524, an advising icon 526, a transaction icon 528, and a navigation dialogue box 530.”, col.23, lines 9-14 “The navigation dialogue box 530 is configured to provide the customer with access to a plurality of additional functionalities. For example, via the navigation dialogue box 530, the customer may input a sequence of symbols relating to the functionality that the customer wishes to access.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method for creating a shared account number upon receiving a request from the primary cardholder and linking the primary account number to the shared account number of Mueller et al. (‘787, [0006]), systems that significantly more efficient at obtaining user account data from external systems than previous techniques, wherein the user account data may be normalized and requested and/or provided via a normalized API, enabling others to efficiently access such data from a single standardized interface in a highly efficient manner of Hockey et al. (‘761, col.2, lines 20-27), and a method for establishing an account by a customer request wherein the account management configured to create first and second checking accounts for the customer, the first checking account having a payment card and the second checking account not having any payment cards of Ball et al. (‘359, col.1, lines 59-65) with teaching of Norman et al. for transferring funds from a first account to a second account that improve the ability to automatically or semi-automatically transfer funds from a first account to a second account based on activity (‘442, [0010]) to creating at the graphical user interface a dialog box that allows a customer to access to a plurality of additional functionalities (‘359, col.23, lines 9-14).
As per claim 17 Norman et al. additionally teaches the following limitations:
A non-transitory computer readable medium ([0014] “Aspects of the disclosed embodiments may also include a tangible, non-transitory, computer-readable medium…”)
one or more processors ([0014] “Aspects of the disclosed embodiments may also include … one or more processors…”)
27. As per claims 10 and 18:
Norman et al. discloses the following limitations:
receiving, via the network interface, an input to the first user device indicating a selection to initiate an inbound transfer of resources from the first account to the shared account (Fig.4, items 402, 403, 404; [0058] “Once the request for transfer has been accepted by financial institution 106 and/or third-party service provider 110, financial institution 106 and/or third-party service provider 110 may begin monitoring account activity in first account 131 at step 402 … If the transaction meets the qualifications of the established rules, a qualifying transaction is determined at step 403. The qualifying transaction, as noted, may be a qualifying deposit, withdrawal, fee, or any other type of transaction that fulfills the rules established by the transfer request.”, [0059] “At step 404, a qualifying transaction in second account 132 triggers a transfer of funds. For example, upon determining a qualifying deposit in second account 132, funds are transferred from first account 131 to second account 132 in an automatic process…”, [0060] “Before transferring funds, notifications and/or authorizations may be sent to one or more owner of first account 131 and second account 132…”)
wherein the input to the first user device indicates a selected category of a plurality of predetermined categories earmarking the transfer of resources ([0058] “… For each transaction in account 131, financial institution 106 and/or third-party service provider 110 may determine whether the transaction qualifies as a transaction that triggers a transfer of funds from first account 131 to second account 132, or vice versa…)
wherein determining that the category of the outbound transfer meets at least one of the plurality of rules further comprises determining that the category matches the selected category ([0058] “…The rules established in the transfer request determine what transactions will trigger transfers and associated authorizations and notifications thereof. The monitoring process is an automated process that is accomplished, for example, by one or more processors of financial institution 106 and/or third-party service provider 110, whereby data related to each transaction (e.g., deposit, transfer, withdrawal, fee, etc.) is compared to the transfer request rules…”)
28. As per claim 11:
Norman et al. discloses the following limitations:
determining based on the plurality of rules associated with the shared account, that the second user is eligible to request the outbound transfer of resources ([0071] “In other embodiments, a notice may be provided to user device 108 registered to one or more of first account 131 and second account 132, notifying the users that an early request to withdraw or transfer funds is requested…funds may be withdrawn or transferred before the predetermined time period has expired, and upon doing so the transferred funds in second account 132 may be transferred back to first account 131 as an early withdrawal or transfer penalty…”, [0072] “In some embodiments, a date identifier may be stored that is associated with the date the funds were transferred from first account 131 to second account 132. For example, the deposit date in second account 132 may be stored. Based on the transfer rules, the transferred funds and/or the funds that triggered the transfer may be monitored over a period of time in second account 132… Notices and/or authorization requests may be sent to user devices 108 registered with first account 131 and second account 132 during many stages of the disclosed methods…”)
29. As per claims 12 and 19:
Norman et al. discloses the following limitations:
wherein the initiating of the outbound transfer of resources is via a third party service provider computer communicably coupled to the computing system (Fig.2B, item 110; [0047] “In FIG. 2B, first account 131 and second account 132 may be maintained within separate financial institutions 106, 116… third-party service provider 110 may be a third-party entity acting as an information clearing house or intermediary between financial institutions 106, 116, and one or more user devices 108.”, [0054] “In some embodiments, third-party service provider 110 may act as an intermediary between financial institution 106 and user device 108. In this embodiment, third-party service provider 110 may collect and transmit requests to link accounts and authorizations to do so from user device 108…”)
30. As per claims 13 and 20:
Norman et al. discloses the following limitations:
wherein the plurality of rules associated with the shared account comprises an expiration date of the shared account ([0071] “In some embodiments, if funds are requested to be withdrawn or transferred before the expiration of the time period set in the transfer rules, the request may be declined… funds may be withdrawn or transferred before the predetermined time period has expired…”)
determining that an amount of resources remain in the shared account at the expiration date ([0071] “In some embodiments, if funds are requested to be withdrawn or transferred before the expiration of the time period set in the transfer rules, the request may be declined…a notice may be provided to user device 108 registered to one or more of first account 131 and second account 132, notifying the users that an early request to withdraw or transfer funds is requested. The notification may notify one or more of the users that the request is declined…”)
initiating a first outbound transfer of a first subset of the amount of resources remaining in the shared account to the first account ([0056] “…The transfer request may include a request to initiate ongoing and automatic transfers of funds, for example, from second account 132 to first account 131 based on activity in first account 131. Activity may include, for instance, deposits, withdrawals, or any other form of activity in the account. The transfer request may include a number of rules associated with the request. The rules may establish, for example, when money is transferred from second account 132 to first account 131…”, [0071] “… an authorization request may be provided to the user device 108 registered to first account 131 to authorize the early withdrawal or transfer (e.g., against the preset transfer rules). User of user device 108 registered to first account 131 may then authorize or decline the withdrawal or transfer. In still other embodiments, funds may be withdrawn or transferred before the predetermined time period has expired, and upon doing so the transferred funds in second account 132 may be transferred back to first account 131 as an early withdrawal or transfer penalty…”)
initiating a second outbound transfer of a second subset of the amount of resources remaining in the shared account to the second account ([0056] “…The transfer request may include a request to initiate ongoing and automatic transfers of funds, for example, from second account 132 to first account 131 based on activity in first account 131. Activity may include, for instance, deposits, withdrawals, or any other form of activity in the account. The transfer request may include a number of rules associated with the request. The rules may establish, for example, when money is transferred from second account 132 to first account 131, how often transfers may occur within a time period, limits on the amount or frequency of transfers, how transfer amounts are determined, elections for one or both accounts to receive authorization requests for each transfer, elections for one or both accounts to receive notifications for each transfer, limits on how transferred funds may be used, how long the automatic transfer process will be in effect, what activity triggers for transfers, etc.”, [0072] “In some embodiments, a date identifier may be stored that is associated with the date the funds were transferred from first account 131 to second account 132. For example, the deposit date in second account 132 may be stored. Based on the transfer rules, the transferred funds and/or the funds that triggered the transfer may be monitored over a period of time in second account 132…”)
31. As per claim 14:
Norman et al. discloses the following limitations:
wherein the first subset and the second subset are based on an allotment of resources between the first account and the second account defined by the plurality of rules associated with the shared account ([0067] “Transfer rules may be selected and established when a transfer request is submitted and received from either owner of first account 131 or second account 132. Various transfer rules are contemplated. The transfer rules govern how second account 132 is monitored and when to trigger transfers, either to or from second account 132. In one embodiment, transfer rules may include monitoring second account 132 for qualifying deposits and initiating transfers from first account 131 to second account 132 based on the qualifying deposit…” [0068] “The rules may place caps on the amount of funds that will be matched and/or transferred. In some embodiments, the transfer rules may establish a matching percentage in which transfers are matched up to a certain deposit amount…”[0069] “The transfer rules may further establish what constitutes a qualified transaction in second account 132. For example, the transfer rules may place limitations on the type of transfer that triggers a transfer from first account 131. Qualifying transactions may include certain types of deposits, to the exclusion of all others. For instance, a cash deposit up to a certain limit may be a qualifying transaction, but a direct deposit from an employer may not be. The qualifying transaction rules enable transfers from first account 131, for example, that promote personal savings contributions to second account 132, while excluding normal pay deposits…”)
32. As per claim 15:
Norman et al. discloses the following limitations:
wherein a ratio between the first subset and the second subset is equal to a ratio of an inbound transfer of resources from the first account to an inbound transfer of resources from the second account (Fig.7; [0067] “…A transfer is initiated from first account 131 to second account 132 when a qualifying deposit is received in first account 131, and the transfer amount matches the deposit amount up to certain percentage. For instance, if the transfer rules establish a matching rate of 6%, six dollars will be transferred to second account for every one hundred dollars.”, [0068] “…In some embodiments, the transfer rules may establish a matching percentage in which transfers are matched up to a certain deposit amount. For example, the transfer rules may establish a 6% matching rule for each deposit up to $300. In addition, the transfer rules may establish a sum total of transfers over a given time period. For example, the transfer rules may establish a 6% matching for each deposit up to $300 and up to a total of $1,000 in deposits per month. Additional matching rules are contemplated that restrict how and when transfers are triggered…”)
33. As per claim 16:
Norman et al. discloses the following limitations:
wherein the plurality of rules associated with the shared account define a balance goal of the shared account ([0073] “In some embodiments, transfer rules may place limitations on when transfers can be made from first account 131 to second account 132. For example, transfer rules may set a minimum balance in first account 131, below which no transfers will be triggered. The amount to be transferred may also be compared to the account balance of first account 131 in order to prevent overdrafts of first account 131. In some embodiments, upon determining a qualifying transaction has occurred in second account 132, it may be determined that first account 131 has insufficient funds or an account balance below a defined threshold to fund the requested transfer to second account 132. In those situations, the transfer may be declined and/or delayed until first account 131 has a sufficient balance to make the transfer. An amount identifier may be stored that indicates the amount of the funds to be transferred based on the qualifying transaction in second account 132…”)
determining, based on the balance goal, a first amount of resources owed by the first account and a second amount of resources owed by the second account ([0073]-[0074])
transmitting, via the network interface, a first notification to the first user device indicating to initiate a first inbound transfer of resources from the first account to the shared account ([0073] “…First account 131 may be monitored after storing the amount identifier, and a determination may be made at a later date or time that first account 131 has sufficient funds to transfer funds to the second account 132 in the amount of the amount identifier. Upon determining first account 131 has sufficient funds or is sufficiently funded, the transfer of the funds may be initiated from first account 131 to second account 132 based on the amount in the stored amount identifier…” [0074] “…a request to authorize the withdrawal or transfer may be sent to user device 108 registered to first account 131 to authorize the withdrawal or transfer above the predetermined maximum…”)
transmitting, via the network interface, a second notification to the second user device indicating to initiate a second inbound transfer of resources from the second account to the shared account ([0073] “In some embodiments, transfer rules may place limitations on when transfers can be made from first account 131 to second account 132… upon determining a qualifying transaction has occurred in second account 132, it may be determined that first account 131 has insufficient funds or an account balance below a defined threshold to fund the requested transfer to second account 132…An amount identifier may be stored that indicates the amount of the funds to be transferred based on the qualifying transaction in second account 132…” [0074] “…the transfer rules may limit the number of withdrawals of transferred funds and/or funds that triggered transfer from second account 132. For example, a withdrawal identifier may be stored indicating a number of withdrawals from second account 132. A maximum number of withdrawals (or transfers) out of second account 132 may be compared to the withdrawal identifier before authorizing the withdrawal or transfer…”)
Conclusion
34. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US20200058012A1 – Chandorkar et al. – Discloses a multi-account payment system includes a memory device and a processor wherein the processor is programmed to receive a designation of a plurality of account numbers associated with a primary cardholder for control by a multi-account application of the multi-account payment system.
US20100312696A1 – Sinha et al. – Discloses methods and systems for establishing and managing a virtual shared account wherein for a virtual shared account comprises setting up an n-member virtual shared account for achieving a goal over a network and adding members to the virtual shared account and contributing funds to the virtual shared account.
US20200258072A1 – Unnerstall et al. – Discloses data controller computing device is configured to receive, from a voice-controlled (VC) computing device, a shared payment initialization request identifying a primary user payment account associated with the VC computing device.
35. Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMANULLA ABDULLAEV whose telephone number is (571)272-4367. The examiner can normally be reached Monday-Friday 9:30AM -4:30PM ET.
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, Ryan D Donlon can be reached at 571-270-3602. 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.
/AMANULLA ABDULLAEV/ Examiner, Art Unit 3692 /RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692