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 .
Claims 1-20 have been examined in this application. This communication is the first action on the merits.
Priority
Application 18/817,698 filed on 08/28/2024 is a CON of 17/302,957 05/17/2021.
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 Objections
Claim 20 is objected to because of the following informalities:
Claim 20 recites “wherein the indication includes one or more of: an instruction to transfer a fixed amount to the account, an instruction to transfer a customer account, or an instruction percentage of the current balance.” The meaning of “an instruction percentage of the current balance is unclear” and appears to be an error. Examiner interprets the phrase to mean “an instruction to transfer a percentage of the current balance”. Appropriate correction is required.
Double Patenting
The non-statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. See In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) may be used to overcome an actual or provisional rejection based on a non-statutory double patenting ground provided the conflicting application or patent is shown to be commonly owned with this application. See 37 CFR 1.131(c). A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a non-statutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional, the reply must be complete. MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to MPEP 1490(V)(A).
Claims 1-20 are rejected on the ground of non-statutory double patenting as being unpatentable over claim 1 of U.S. Patent No. 12,112,369.
Claims 1 and 8 of the instant application are broader and fully encompass the method steps of patent claim 1 of U.S. Patent No. 12,112,369. Accordingly, the claims are rejected under non-statutory obviousness-type double patenting.
Claim 15 is substantially similar to claim 1, thus, it is rejected on the same grounds.
Application 18/4817,698 – Claim 1
Application 18/4817,698 – Claim 8
US Patent No. 12,112,369
1. A system for transmitting proactive notifications based on machine learning model predictions, the system comprising: one or more memories; and one or more processors, coupled to the one or more memories, configured to:
8. A non-transitory computer-readable medium storing a set of instructions for transmitting proactive notifications based on one or more predictions, the set of instructions comprising: one or more instructions that, when executed by one or more processors of a system, cause the system to:
1. A system for transmitting proactive notifications based on machine learning model predictions, the system comprising: one or more memories; and one or more processors, coupled to the one or more memories, configured to:
generate, using a machine learning model, a prediction of a future date on which a predicted event, of a series of recurring events, is to occur,
generate, using a machine learning model, a prediction of a future date on which a predicted event, of a series of recurring events, is to occur,
train a machine learning model based on information included in one or more entries, that are respectively associated with one or more reoccurring events, of historical data;
identify, using the machine learning model, a series of recurring events associated with an account;
generate, using the machine learning model, a prediction of a future date on which a predicted event, of the series of recurring events, is to occur, wherein the machine learning model processes a set of entries from the series of recurring events to generate the prediction of the future date on which the predicted event associated with the series of recurring events is to occur and output a confidence score in connection with the predicted event;
determine, using the machine learning model, a predicted amount of the predicted event in connection with the future date;
determine, using the machine learning model, a predicted amount of the predicted event in connection with the future date;
determine, using the machine learning model, a predicted amount of the predicted event in connection with the future date;
determine that a current balance, associated with an account, is within a threshold amount of a limit associated with the account, wherein the threshold amount is based on the predicted amount associated with the predicted event;
determine that a current balance, associated with an account, is within a threshold amount of a limit associated with the account, wherein the threshold amount is based on the predicted amount associated with the predicted event;
determine that a current date is within a threshold number of days of the future date based on the prediction of the future date;
determine that a current balance, associated with the account, is within a threshold amount of a limit associated with the account,
wherein the threshold amount is based on the predicted amount associated with the predicted event;
transmit, to a user device, a notification based on determining that a current date is within a threshold number of days of the future date, a confidence score, and that the current balance is within the threshold amount of the limit associated with the account, receive an indication from the user device based on the notification; and
transmit, to a user device, a notification based on determining that a current date is within a threshold number of days of the future date, and that the current balance is within the threshold amount of the limit associated with the account; receive an indication from the user device based on the notification;
transmit, to a user device, a notification based on determining that the current date is within the threshold number of days of the future date, the confidence score, and that the current balance is within the threshold amount of the limit associated with the account, wherein the notification includes information for presentation of one or more input elements, to be presented by the user device; receive an indication from the user device based on the information;
selectively retrain the machine learning model; and
selectively retrain the machine learning model; and
perform an action based on the indication, wherein the action includes one or more of: cause a transfer to occur to reduce the current balance of the account based on the predicted amount, cause the limit associated with the account to be increased, cause the user device to load a cancelation webpage, or cause one or more card service actions to occur.
perform an action based on the indication, wherein the action includes one or more of: cause a transfer to occur to reduce the current balance of the account based on the predicted amount, cause the limit associated with the account to be increased, cause the user device to load a cancelation webpage, or cause one or more card service actions to occur.
perform an action based on the indication,
wherein the action includes one or more of:
cause a transfer to occur to reduce the current balance of the account based on the predicted amount,
cause the limit associated with the account to be increased,
cause the user device to load a cancelation webpage, or
cause one or more card service actions to occur.
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-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. (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 1 recites the limitations of:
A system for transmitting proactive notifications based on machine learning model predictions, the system comprising: one or more memories; and one or more processors, coupled to the one or more memories, configured to: generate, using a machine learning model, a prediction of a future date on which a predicted event, of a series of recurring events, is to occur,
determine, using the machine learning model, a predicted amount of the predicted event in connection with the future date;
determine that a current balance, associated with an account, is within a threshold amount of a limit associated with the account, wherein the threshold amount is based on the predicted amount associated with the predicted event;
transmit, to a user device, a notification based on determining that a current date is within a threshold number of days of the future date, a confidence score, and
that the current balance is within the threshold amount of the limit associated with the account,
receive an indication from the user device based on the notification; and
perform an action based on the indication, wherein the action includes one or more of: cause a transfer to occur to reduce the current balance of the account based on the predicted amount, cause the limit associated with the account to be increased, cause the user device to load a cancelation webpage, or cause one or more card service actions to occur.
Claim 8 recites the limitations of:
A non-transitory computer-readable medium storing a set of instructions for transmitting proactive notifications based on one or more predictions, the set of instructions comprising: one or more instructions that, when executed by one or more processors of a system, cause the system to: generate, using a machine learning model, a prediction of a future date on which a predicted event, of a series of recurring events, is to occur,
determine, using the machine learning model, a predicted amount of the predicted event in connection with the future date;
determine that a current balance, associated with an account, is within a threshold amount of a limit associated with the account, wherein the threshold amount is based on the predicted amount associated with the predicted event;
transmit, to a user device, a notification based on determining that a current date is within a threshold number of days of the future date, and that the current balance is within the threshold amount of the limit associated with the account;
receive an indication from the user device based on the notification;
selectively retrain the machine learning model; and
perform an action based on the indication, wherein the action includes one or more of: cause a transfer to occur to reduce the current balance of the account based on the predicted amount, cause the limit associated with the account to be increased, cause the user device to load a cancelation webpage, or cause one or more card service actions to occur.
The claim as a whole recites a method that, under its broadest reasonable interpretation, covers collecting, analyzing, and transmitting data to manage financial data and to facilitate a financial transaction, e.g., payments of a bill on a regular basis, altering a credit account limit, or altering an authorized user account limit. 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.
Furthermore, the claims cover the use of a computer system providing an interface to facilitate collecting, analyzing, and transmitting data to manage financial data and to facilitate a financial transaction. As the steps could be performed by a human without a computer, the claim limitations fall within the mental processes grouping, and the claim recites an abstract idea.
Finally, the claims also recite the use of a trained machine learning model to determine predictions related to recurring financial transactions. This is a mathematical calculation.
In the alternative, the machine learning model is considered a technology that is recited at a high level of generality and merely applied as a tool to implement the abstract idea.
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 storing a set of instructions for transmitting proactive notifications based on one or more predictions, the set of instructions comprising: one or more instructions that, when executed by one or more processors of a system, cause the system to:”, “a machine learning model”, “a user device”, and “a user device to load a cancelation webpage”, to perform the steps of “generating”, “determining”, “transmitting”, “retraining”, and “performing”, nothing in the claim elements preclude the steps from practically being a certain method for organizing human activity, mental process, or mathematical calculation. The claim as a whole does not integrate the judicial exception into a practical application. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data to manage financial data and to facilitate a financial transaction, e.g., payments of a bill on a regular basis, altering a credit account limit, or altering an authorized user account limit 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 discloses “[0059] The user device 320 includes one or more devices capable of receiving, generating, storing, processing, and/or providing information associated with transmitting proactive notifications based on machine learning model predictions, as described elsewhere herein. The user device 320 may include a communication device and/or a computing device. For example, the user device 320 may include a wireless communication device, a mobile phone, a user equipment, a laptop computer, a tablet computer, a desktop computer, a gaming console, a set-top box, a wearable communication device (e.g., a smart wristwatch, a pair of smart eyeglasses, a head mounted display, or a virtual reality headset), or a similar type of device. The user device 320 may communicate with one or more other devices of environment 300, as described elsewhere herein.”
Furthermore, the Specification discloses “[0048]The target variable may represent a value that a machine learning model is being trained to predict, and the feature set may represent the variables that are input to a trained machine learning model to predict a value for the target variable. The set of observations may include target variable values so that the machine learning model can be trained to recognize patterns in the feature set that lead to a target variable value. A machine learning model that is trained to predict a target variable value may be referred to as a supervised learning model. [0049]In some implementations, the machine learning model may be trained on a set of observations that do not include a target variable. This may be referred to as an unsupervised learning model. In this case, the machine learning model may learn patterns from the set of observations without labeling or supervision, and may provide output that indicates such patterns, such as by using clustering and/or association to identify related groups of items within the set of observations. [0050]As shown by reference number 220, the machine learning system may train a machine learning model using the set of observations and using one or more machine learning algorithms, such as a regression algorithm, a decision tree algorithm, a neural network algorithm, a k-nearest neighbor algorithm, a support vector machine algorithm, or the like. After training, the machine learning system may store the machine learning model as a trained machine learning model 225 to be used to analyze new observations.”
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 storing a set of instructions for transmitting proactive notifications based on one or more predictions, the set of instructions comprising: one or more instructions that, when executed by one or more processors of a system, cause the system to:”, “a machine learning model”, “a user device”, and “a user device to load a cancelation webpage”, to perform the steps of “generating”, “determining”, “transmitting”, “retraining”, and “performing”, 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, transmitting, and posting to an account ledger, various balance transfer data records 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”.
Claim 15 is substantially similar to claims 1 and 8, thus, it is rejected on similar grounds.
Claim 15 recites “A method for transmitting proactive notifications based on one or more machine learning predictions, comprising:”.
For similar reasons as explained above with regard to claims 1 and 8, 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 claims 1 and 8.
Dependent claims 2-7, 9-14, and 16-20 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-20 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-3, 5-12, 15, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Reses, U.S. Patent Application Publication Number 2022/0005036; in view of Templeton, U.S. Patent Application Publication Number 2019/0259095.
As per claim 1,
Reses explicitly teaches:
A system for transmitting proactive notifications based on machine learning model predictions, the system comprising: one or more memories; and one or more processors, coupled to the one or more memories, configured to: generate, using a machine learning model, a prediction of a future date on which a predicted event, of a series of recurring events, is to occur,
(Reses US20220005036 at paras. 100-102) ("[0101] In some instances, the amount of surplus funds may represent a prediction at a later point in the future. For example, using some of the techniques discussed below with reference to FIGS. 16-27, the application generating the UI 1000 may predict that the account will have the illustrated amount of surplus funds (e.g., $400) at a later date in the future. The user may use the UI 1000 and/or other described UIs for instructing the application to take action on the surplus funds (e.g., move to a higher-yield account, etc.) in response to the prediction coming to fruition, such as the amount of surplus funds being greater than a threshold.")
determine, using the machine learning model, a predicted amount of the predicted event in connection with the future date;
(Reses US20220005036 at paras. 100-102) ("[0101] In some instances, the amount of surplus funds may represent a prediction at a later point in the future. For example, using some of the techniques discussed below with reference to FIGS. 16-27, the application generating the UI 1000 may predict that the account will have the illustrated amount of surplus funds (e.g., $400) at a later date in the future. The user may use the UI 1000 and/or other described UIs for instructing the application to take action on the surplus funds (e.g., move to a higher-yield account, etc.) in response to the prediction coming to fruition, such as the amount of surplus funds being greater than a threshold.")
determine that a current balance, associated with an account, is within a threshold amount of a limit associated with the account, wherein the threshold amount is based on the predicted amount associated with the predicted event;
(Reses US20220005036 at paras. 36-44) ("[0042] In order to determine the existence of surplus funds, the techniques described below may determine, for each example merchant or user, a balance of an account over which funds in the account are deemed surplus. That is, the techniques may determine a balance over which the funds in the account are not predicted to be needed to operate the business of the example merchant or needs of a user for at least a threshold amount of time (e.g., one day, one week, one month, etc.). In some instances, this balance may comprise the minimum balance plus an additional amount (e.g., twice the minimum balance, the minimum balance plus a largest payment out of the account in the past year, etc.). In some instances, this defined balance may be set by the merchant or user and/or may be determined based at least in part on a level of risk desired by the merchant or user. For example, the techniques may set a relatively high balance if the merchant indicates a relatively low desire for risk, and vice versa.")
that the current balance is within the threshold amount of the limit associated with the account,
(Reses US20220005036 at paras. 36-44) ("[0042] In order to determine the existence of surplus funds, the techniques described below may determine, for each example merchant or user, a balance of an account over which funds in the account are deemed surplus. That is, the techniques may determine a balance over which the funds in the account are not predicted to be needed to operate the business of the example merchant or needs of a user for at least a threshold amount of time (e.g., one day, one week, one month, etc.). In some instances, this balance may comprise the minimum balance plus an additional amount (e.g., twice the minimum balance, the minimum balance plus a largest payment out of the account in the past year, etc.). In some instances, this defined balance may be set by the merchant or user and/or may be determined based at least in part on a level of risk desired by the merchant or user. For example, the techniques may set a relatively high balance if the merchant indicates a relatively low desire for risk, and vice versa.")
receive an indication from the user device based on the notification; and
(Reses US20220005036 at paras. 185-187) ("[0186] FIG. 18 illustrates an example UI 1800 that the payment service 108 may provide to the POS device 104 or other client device in response to the merchant 102(1) or other user selecting the icon 1706. In this example, the UI 1800 includes an area 1802 that introduces the concept of providing recommendations to the merchant or other user for managing any predicted cashflow difficulties. As illustrated, the area 1802 includes a recommendation 1804 for handling the predicted cashflow challenge discussed above with reference to FIG. 17. In this example, the recommendation 1804 comprises a recommendation to move a bill to a different day of the month, such as a later day in the month when the account is predicted to have a balance that can cover the predicted expense. In some instances, the recommendation 1804 may be selectable to cause action of the recommendation. For example, the recommendation 1804 may comprise a link that, when selected, causes the POS device 104 or other device to present a UI for requesting to move the expense to a later date. Of course, while FIG. 18 illustrates an example recommendation 1804, it is to be appreciated that the recommendation 1804 may take any other form, such as a recommendation to attempt to lessen the expense, a recommendation to cancel a service or item associated with the expense, a recommendation to take a “cash boost” or “float” (as described above), or the like. Finally, the UI 1800 includes an icon 1806 that, when selected, continues the sequence of onboarding UIs.")
perform an action based on the indication, wherein the action includes one or more of: cause a transfer to occur to reduce the current balance of the account based on the predicted amount, cause the limit associated with the account to be increased, cause the user device to load a cancelation webpage, or cause one or more card service actions to occur.
(Reses US20220005036 at paras. 185-187) ("[0186] FIG. 18 illustrates an example UI 1800 that the payment service 108 may provide to the POS device 104 or other client device in response to the merchant 102(1) or other user selecting the icon 1706. In this example, the UI 1800 includes an area 1802 that introduces the concept of providing recommendations to the merchant or other user for managing any predicted cashflow difficulties. As illustrated, the area 1802 includes a recommendation 1804 for handling the predicted cashflow challenge discussed above with reference to FIG. 17. In this example, the recommendation 1804 comprises a recommendation to move a bill to a different day of the month, such as a later day in the month when the account is predicted to have a balance that can cover the predicted expense. In some instances, the recommendation 1804 may be selectable to cause action of the recommendation. For example, the recommendation 1804 may comprise a link that, when selected, causes the POS device 104 or other device to present a UI for requesting to move the expense to a later date. Of course, while FIG. 18 illustrates an example recommendation 1804, it is to be appreciated that the recommendation 1804 may take any other form, such as a recommendation to attempt to lessen the expense, a recommendation to cancel a service or item associated with the expense, a recommendation to take a “cash boost” or “float” (as described above), or the like. Finally, the UI 1800 includes an icon 1806 that, when selected, continues the sequence of onboarding UIs.")
Reses does not explicitly teach, however, Templeton teaches:
transmit, to a user device, a notification based on determining that a current date is within a threshold number of days of the future date, a confidence score, and
(Templeton US20190259095 at paras. 89-92, 116-120) ("[0118] Many other use cases are also possible, which may not be explicitly contemplated herein. For example, a “low balance detector” may be configured to warn a user that insufficient funds are likely (or otherwise possible within some threshold tolerance) in the near future. The number of days the low balance detector looks ahead to, the degree of confidence necessary to trigger the warning, and a variety of other aspects of such a low balance detector may be configured according to the particular needs of a user or organization. As another example, a system implementing the model may transmit a notification or email to a user when there is an 80% or greater likelihood that the user will be unable to pay a particular recurring bill the following month. As yet another example, a credit card company may wish to transmit marketing materials or extend exclusive offers to users associated with accounts that have a 95% or greater likelihood of paying all expenses for the following year. The scope of the present disclosure encompasses the broad range of possible outputs and/or actions taken based on outputs of the model. [0119] The models described herein may be integrated with, or accessible by, a website or application, either for an organization or for end users. FIG. 7 depicts an example user interface 700 on a smartphone. A service provider may publish an application, which builds upon the future balance model to monitor a user's spending and notify the user about potential issues (e.g., low balance, spending near or above a credit limit, etc.) before the occurrence of such issues. In the example of FIG. 7, the application generated a “low balance alert” 702, which notifies the user that their recent spending habits may render them unable to make an upcoming rent payment.")
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 Reses and Templeton, because it allows for improved systems for managing data records to determine present and future virtual balances of an account, and/or operating a user interface of a client computing device that communicates with the cloud platform and/or other computing device. (Templeton at Abstract and paras. 2-21).
As per claim 2,
Reses explicitly teaches:
wherein the one or more processors, to perform the action, are further configured to: automatically call a phone number or send a message associated with cancelling a service associated with the account.
(Reses US20240152928 at paras. 185-187) ("[0186] FIG. 18 illustrates an example UI 1800 that the payment service 108 may provide to the POS device 104 or other client device in response to the merchant 102(1) or other user selecting the icon 1706. In this example, the UI 1800 includes an area 1802 that introduces the concept of providing recommendations to the merchant or other user for managing any predicted cashflow difficulties. As illustrated, the area 1802 includes a recommendation 1804 for handling the predicted cashflow challenge discussed above with reference to FIG. 17. In this example, the recommendation 1804 comprises a recommendation to move a bill to a different day of the month, such as a later day in the month when the account is predicted to have a balance that can cover the predicted expense. In some instances, the recommendation 1804 may be selectable to cause action of the recommendation. For example, the recommendation 1804 may comprise a link that, when selected, causes the POS device 104 or other device to present a UI for requesting to move the expense to a later date. Of course, while FIG. 18 illustrates an example recommendation 1804, it is to be appreciated that the recommendation 1804 may take any other form, such as a recommendation to attempt to lessen the expense, a recommendation to cancel a service or item associated with the expense, a recommendation to take a “cash boost” or “float” (as described above), or the like. Finally, the UI 1800 includes an icon 1806 that, when selected, continues the sequence of onboarding UIs.")
As per claim 3,
Reses does not explicitly teach, however, Templeton teaches:
wherein the machine learning model identifies the series of recurring events based on a feature set that includes at least one of: an average time between events included in the series of recurring events, a standard deviation determined for times between events included in the series of recurring events, an average transaction amount associated with the series of recurring events, or a standard deviation determined for transaction amounts of the series of recurring events.
(Templeton US20190259095 at paras. 90-92, 116-120) ("FIG. 5 depicts an example probability distribution 500 to illustrate an example technique for determining the change in an account balance between time steps (e.g., between successive days). The distribution 500 represents a normal distribution (although it may not necessarily be drawn to scale). In this example, the distribution represents the negative change in an account balance. [0088] The mean value μ of the distribution 500 is $100. Each standard deviation a has a $25 interval. One way to interpret the distribution 500, therefore, is that there is about a 68% chance that the user will spend between $75 and $125 between the current and subsequent time “ticks.” Another way to interpret the distribution 500 is that there is about a 95% chance that the user will spend between $50 and $150 between the current and subsequent time “ticks.”")
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 Reses and Templeton, because it allows for improved systems for managing data records to determine present and future virtual balances of an account, and/or operating a user interface of a client computing device that communicates with the cloud platform and/or other computing device. (Templeton at Abstract and paras. 2-21).
As per claim 5,
Reses does not explicitly teach, however, Templeton teaches:
wherein the notification indicates the future date and a merchant associated with the predicted event.
(Templeton US20190259095 at paras. 112-119) ("[0118] Many other use cases are also possible, which may not be explicitly contemplated herein. For example, a “low balance detector” may be configured to warn a user that insufficient funds are likely (or otherwise possible within some threshold tolerance) in the near future. The number of days the low balance detector looks ahead to, the degree of confidence necessary to trigger the warning, and a variety of other aspects of such a low balance detector may be configured according to the particular needs of a user or organization. As another example, a system implementing the model may transmit a notification or email to a user when there is an 80% or greater likelihood that the user will be unable to pay a particular recurring bill the following month." "[0112] To summarize, the present disclosure describes techniques for generating and using models that predict the likely balance of a financial account at a future time. Transaction data may include a date, time, amount of money transferred, payee, category of expenditure, and/or other related information.")
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 Reses and Templeton, because it allows for improved systems for managing data records to determine present and future virtual balances of an account, and/or operating a user interface of a client computing device that communicates with the cloud platform and/or other computing device. (Templeton at Abstract and paras. 2-21).
As per claim 6,
Reses explicitly teaches:
wherein an amount of the transfer is based on the predicted amount associated with the predicted event.
(Reses US20220005036 at paras. 15, 185-187) ("[0186] FIG. 18 illustrates an example UI 1800 that the payment service 108 may provide to the POS device 104 or other client device in response to the merchant 102(1) or other user selecting the icon 1706. In this example, the UI 1800 includes an area 1802 that introduces the concept of providing recommendations to the merchant or other user for managing any predicted cashflow difficulties. As illustrated, the area 1802 includes a recommendation 1804 for handling the predicted cashflow challenge discussed above with reference to FIG. 17. In this example, the recommendation 1804 comprises a recommendation to move a bill to a different day of the month, such as a later day in the month when the account is predicted to have a balance that can cover the predicted expense. In some instances, the recommendation 1804 may be selectable to cause action of the recommendation. For example, the recommendation 1804 may comprise a link that, when selected, causes the POS device 104 or other device to present a UI for requesting to move the expense to a later date. Of course, while FIG. 18 illustrates an example recommendation 1804, it is to be appreciated that the recommendation 1804 may take any other form, such as a recommendation to attempt to lessen the expense, a recommendation to cancel a service or item associated with the expense, a recommendation to take a “cash boost” or “float” (as described above), or the like. Finally, the UI 1800 includes an icon 1806 that, when selected, continues the sequence of onboarding UIs.")
As per claim 7,
Reses explicitly teaches:
wherein the series of recurring events occurs: daily, weekly, monthly, semiannually, or annually.
(Reses US20220005036 at paras. 54, 68, 133) ("[0054] Historical data 130 may include data such as: a current balance in the merchant account; recurring deposits to the account (e.g., a weekly or monthly paycheck), or other type of deposit made into the account on a recurring periodic basis;" "[0068] In some instances, a capital need may be identified based on or more of an array of factors. For example, a capital need may be identified from historical data 130 of a merchant or other use indicating a relatively-large recurring purchase, such as a large monthly, quarterly, or yearly purchase." "[0133] For instance, in at least one example, the service provider 1412 can offer a daily repayment loan product, wherein a capital loan is repaid daily, for instance, from a portion of transactions processed by the payment processing service on behalf of the borrower. Additionally and/or alternatively, the service provider 1412 can offer a monthly repayment loan product, wherein a capital loan is repaid monthly, for instance, via a debit from a bank account linked to the payment processing service.")
As per claim 8,
Reses explicitly teaches:
A non-transitory computer-readable medium storing a set of instructions for transmitting proactive notifications based on one or more predictions, the set of instructions comprising: one or more instructions that, when executed by one or more processors of a system, cause the system to: generate, using a machine learning model, a prediction of a future date on which a predicted event, of a series of recurring events, is to occur,
(Reses US20220005036 at paras. 100-102) ("[0101] In some instances, the amount of surplus funds may represent a prediction at a later point in the future. For example, using some of the techniques discussed below with reference to FIGS. 16-27, the application generating the UI 1000 may predict that the account will have the illustrated amount of surplus funds (e.g., $400) at a later date in the future. The user may use the UI 1000 and/or other described UIs for instructing the application to take action on the surplus funds (e.g., move to a higher-yield account, etc.) in response to the prediction coming to fruition, such as the amount of surplus funds being greater than a threshold.")
determine, using the machine learning model, a predicted amount of the predicted event in connection with the future date;
(Reses US20220005036 at paras. 100-102) ("[0101] In some instances, the amount of surplus funds may represent a prediction at a later point in the future. For example, using some of the techniques discussed below with reference to FIGS. 16-27, the application generating the UI 1000 may predict that the account will have the illustrated amount of surplus funds (e.g., $400) at a later date in the future. The user may use the UI 1000 and/or other described UIs for instructing the application to take action on the surplus funds (e.g., move to a higher-yield account, etc.) in response to the prediction coming to fruition, such as the amount of surplus funds being greater than a threshold.")
determine that a current balance, associated with an account, is within a threshold amount of a limit associated with the account, wherein the threshold amount is based on the predicted amount associated with the predicted event;
(Reses US20220005036 at paras. 36-44) ("[0042] In order to determine the existence of surplus funds, the techniques described below may determine, for each example merchant or user, a balance of an account over which funds in the account are deemed surplus. That is, the techniques may determine a balance over which the funds in the account are not predicted to be needed to operate the business of the example merchant or needs of a user for at least a threshold amount of time (e.g., one day, one week, one month, etc.). In some instances, this balance may comprise the minimum balance plus an additional amount (e.g., twice the minimum balance, the minimum balance plus a largest payment out of the account in the past year, etc.). In some instances, this defined balance may be set by the merchant or user and/or may be determined based at least in part on a level of risk desired by the merchant or user. For example, the techniques may set a relatively high balance if the merchant indicates a relatively low desire for risk, and vice versa.")
that the current balance is within the threshold amount of the limit associated with the account;
(Reses US20220005036 at paras. 36-44) ("[0042] In order to determine the existence of surplus funds, the techniques described below may determine, for each example merchant or user, a balance of an account over which funds in the account are deemed surplus. That is, the techniques may determine a balance over which the funds in the account are not predicted to be needed to operate the business of the example merchant or needs of a user for at least a threshold amount of time (e.g., one day, one week, one month, etc.). In some instances, this balance may comprise the minimum balance plus an additional amount (e.g., twice the minimum balance, the minimum balance plus a largest payment out of the account in the past year, etc.). In some instances, this defined balance may be set by the merchant or user and/or may be determined based at least in part on a level of risk desired by the merchant or user. For example, the techniques may set a relatively high balance if the merchant indicates a relatively low desire for risk, and vice versa.")
receive an indication from the user device based on the notification;
(Reses US20220005036 at paras. 185-187) ("[0186] FIG. 18 illustrates an example UI 1800 that the payment service 108 may provide to the POS device 104 or other client device in response to the merchant 102(1) or other user selecting the icon 1706. In this example, the UI 1800 includes an area 1802 that introduces the concept of providing recommendations to the merchant or other user for managing any predicted cashflow difficulties. As illustrated, the area 1802 includes a recommendation 1804 for handling the predicted cashflow challenge discussed above with reference to FIG. 17. In this example, the recommendation 1804 comprises a recommendation to move a bill to a different day of the month, such as a later day in the month when the account is predicted to have a balance that can cover the predicted expense. In some instances, the recommendation 1804 may be selectable to cause action of the recommendation. For example, the recommendation 1804 may comprise a link that, when selected, causes the POS device 104 or other device to present a UI for requesting to move the expense to a later date. Of course, while FIG. 18 illustrates an example recommendation 1804, it is to be appreciated that the recommendation 1804 may take any other form, such as a recommendation to attempt to lessen the expense, a recommendation to cancel a service or item associated with the expense, a recommendation to take a “cash boost” or “float” (as described above), or the like. Finally, the UI 1800 includes an icon 1806 that, when selected, continues the sequence of onboarding UIs.")
selectively retrain the machine learning model; and
(Reses US20220005036 at paras. 172-174) ("[0173] The training module 1538 can be configured to train models using machine-learning mechanisms. For example, a machine-learning mechanism can analyze training data to train a data model that generates an output, which can be a recommendation, a score, and/or another indication. Machine-learning mechanisms can include, but are not limited to supervised learning algorithms (e.g., artificial neural networks, Bayesian statistics, support vector machines, decision trees, classifiers, k-nearest neighbor, etc.), unsupervised learning algorithms (e.g., artificial neural networks, association rule learning, hierarchical clustering, cluster analysis, etc.), semi-supervised learning algorithms, deep learning algorithms, etc.), statistical models, etc. In at least one example, machine-trained data models can be stored in a datastore associated with the user device(s) 1502 and/or the server(s) 1504 for use at a time after the data models have been trained (e.g., at runtime).
perform an action based on the indication, wherein the action includes one or more of: cause a transfer to occur to reduce the current balance of the account based on the predicted amount, cause the limit associated with the account to be increased, cause the user device to load a cancelation webpage, or cause one or more card service actions to occur.
(Reses US20220005036 at paras. 185-187) ("[0186] FIG. 18 illustrates an example UI 1800 that the payment service 108 may provide to the POS device 104 or other client device in response to the merchant 102(1) or other user selecting the icon 1706. In this example, the UI 1800 includes an area 1802 that introduces the concept of providing recommendations to the merchant or other user for managing any predicted cashflow difficulties. As illustrated, the area 1802 includes a recommendation 1804 for handling the predicted cashflow challenge discussed above with reference to FIG. 17. In this example, the recommendation 1804 comprises a recommendation to move a bill to a different day of the month, such as a later day in the month when the account is predicted to have a balance that can cover the predicted expense. In some instances, the recommendation 1804 may be selectable to cause action of the recommendation. For example, the recommendation 1804 may comprise a link that, when selected, causes the POS device 104 or other device to present a UI for requesting to move the expense to a later date. Of course, while FIG. 18 illustrates an example recommendation 1804, it is to be appreciated that the recommendation 1804 may take any other form, such as a recommendation to attempt to lessen the expense, a recommendation to cancel a service or item associated with the expense, a recommendation to take a “cash boost” or “float” (as described above), or the like. Finally, the UI 1800 includes an icon 1806 that, when selected, continues the sequence of onboarding UIs.")
Reses does not explicitly teach, however, Templeton teaches:
transmit, to a user device, a notification based on determining that a current date is within a threshold number of days of the future date, and
(Templeton US20190259095 at paras. 90-92, 116-120) ("[0118] Many other use cases are also possible, which may not be explicitly contemplated herein. For example, a “low balance detector” may be configured to warn a user that insufficient funds are likely (or otherwise possible within some threshold tolerance) in the near future. The number of days the low balance detector looks ahead to, the degree of confidence necessary to trigger the warning, and a variety of other aspects of such a low balance detector may be configured according to the particular needs of a user or organization. As another example, a system implementing the model may transmit a notification or email to a user when there is an 80% or greater likelihood that the user will be unable to pay a particular recurring bill the following month. As yet another example, a credit card company may wish to transmit marketing materials or extend exclusive offers to users associated with accounts that have a 95% or greater likelihood of paying all expenses for the following year. The scope of the present disclosure encompasses the broad range of possible outputs and/or actions taken based on outputs of the model. [0119] The models described herein may be integrated with, or accessible by, a website or application, either for an organization or for end users. FIG. 7 depicts an example user interface 700 on a smartphone. A service provider may publish an application, which builds upon the future balance model to monitor a user's spending and notify the user about potential issues (e.g., low balance, spending near or above a credit limit, etc.) before the occurrence of such issues. In the example of FIG. 7, the application generated a “low balance alert” 702, which notifies the user that their recent spending habits may render them unable to make an upcoming rent payment.")
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 Reses and Templeton, because it allows for improved systems for managing data records to determine present and future virtual balances of an account, and/or operating a user interface of a client computing device that communicates with the cloud platform and/or other computing device. (Templeton at Abstract and paras. 2-21).
As per claim 9,
Reses does not explicitly teach, however, Templeton teaches:
wherein the machine learning model processes a set of entries from the series of recurring events to generate the prediction of the future date and outputs a confidence score in connection with the predicted event.
(Templeton US20190259095 at paras. 89-91) ("[0090] In some embodiments, an application that utilizes the above-described model may involve setting some threshold confidence or likelihood value as an indication of whether a user associated with the account can afford to make a particular expenditure (e.g., a vacation, a gift, etc.). For instance, whether or not a user can afford to make a particular purchase within a given time frame may be based on the premise that there is a 90% or greater likelihood that a user will have the requisite funds to make the purchase. The model may be run to determine the probability distribution, which in turn is evaluated to determine whether or not that threshold is met.")
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 Reses and Templeton, because it allows for improved systems for managing data records to determine present and future virtual balances of an account, and/or operating a user interface of a client computing device that communicates with the cloud platform and/or other computing device. (Templeton at Abstract and paras. 2-21).
As per claim 10,
Reses does not explicitly teach, however, Templeton teaches:
wherein the one or more instructions that, when executed by one or more processors of the system, further cause the system to: determine that the current date is within the threshold number of days of the future date when a difference between the future date and the current date is less than or equal to the threshold number of days.
(Templeton US20190259095 at paras. 112-120) ("[0118] Many other use cases are also possible, which may not be explicitly contemplated herein. For example, a “low balance detector” may be configured to warn a user that insufficient funds are likely (or otherwise possible within some threshold tolerance) in the near future. The number of days the low balance detector looks ahead to, the degree of confidence necessary to trigger the warning, and a variety of other aspects of such a low balance detector may be configured according to the particular needs of a user or organization. As another example, a system implementing the model may transmit a notification or email to a user when there is an 80% or greater likelihood that the user will be unable to pay a particular recurring bill the following month." "[0119] The models described herein may be integrated with, or accessible by, a website or application, either for an organization or for end users. FIG. 7 depicts an example user interface 700 on a smartphone. A service provider may publish an application, which builds upon the future balance model to monitor a user's spending and notify the user about potential issues (e.g., low balance, spending near or above a credit limit, etc.) before the occurrence of such issues. In the example of FIG. 7, the application generated a “low balance alert” 702, which notifies the user that their recent spending habits may render them unable to make an upcoming rent payment.")
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 Reses and Templeton, because it allows for improved systems for managing data records to determine present and future virtual balances of an account, and/or operating a user interface of a client computing device that communicates with the cloud platform and/or other computing device. (Templeton at Abstract and paras. 2-21).
As per claim 12,
Reses does not explicitly teach, however, Templeton teaches:
wherein the machine learning model outputs a confidence score that indicates a likelihood that the prediction of the future date or the predicted amount is correct.
(Templeton US20190259095 at paras. 89-91) ("[0090] In some embodiments, an application that utilizes the above-described model may involve setting some threshold confidence or likelihood value as an indication of whether a user associated with the account can afford to make a particular expenditure (e.g., a vacation, a gift, etc.). For instance, whether or not a user can afford to make a particular purchase within a given time frame may be based on the premise that there is a 90% or greater likelihood that a user will have the requisite funds to make the purchase. The model may be run to determine the probability distribution, which in turn is evaluated to determine whether or not that threshold is met.")
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 Reses and Templeton, because it allows for improved systems for managing data records to determine present and future virtual balances of an account, and/or operating a user interface of a client computing device that communicates with the cloud platform and/or other computing device. (Templeton at Abstract and paras. 2-21).
As per claim 19,
Reses explicitly teaches:
wherein the notification includes information for presentation of one or more input elements, to be presented by the user device, that enable the action to be performed.
(Reses US20220005036 at paras. 185-187) ("[0186] FIG. 18 illustrates an example UI 1800 that the payment service 108 may provide to the POS device 104 or other client device in response to the merchant 102(1) or other user selecting the icon 1706. In this example, the UI 1800 includes an area 1802 that introduces the concept of providing recommendations to the merchant or other user for managing any predicted cashflow difficulties. As illustrated, the area 1802 includes a recommendation 1804 for handling the predicted cashflow challenge discussed above with reference to FIG. 17. In this example, the recommendation 1804 comprises a recommendation to move a bill to a different day of the month, such as a later day in the month when the account is predicted to have a balance that can cover the predicted expense. In some instances, the recommendation 1804 may be selectable to cause action of the recommendation. For example, the recommendation 1804 may comprise a link that, when selected, causes the POS device 104 or other device to present a UI for requesting to move the expense to a later date. Of course, while FIG. 18 illustrates an example recommendation 1804, it is to be appreciated that the recommendation 1804 may take any other form, such as a recommendation to attempt to lessen the expense, a recommendation to cancel a service or item associated with the expense, a recommendation to take a “cash boost” or “float” (as described above), or the like. Finally, the UI 1800 includes an icon 1806 that, when selected, continues the sequence of onboarding UIs.")
As per claim 20,
Reses explicitly teaches:
wherein the indication includes one or more of: an instruction to transfer a fixed amount to the account, an instruction to transfer a customer account, or an instruction percentage of the current balance.
(Reses US20220005036 at paras. 15, 185-187) ("[0186] FIG. 18 illustrates an example UI 1800 that the payment service 108 may provide to the POS device 104 or other client device in response to the merchant 102(1) or other user selecting the icon 1706. In this example, the UI 1800 includes an area 1802 that introduces the concept of providing recommendations to the merchant or other user for managing any predicted cashflow difficulties. As illustrated, the area 1802 includes a recommendation 1804 for handling the predicted cashflow challenge discussed above with reference to FIG. 17. In this example, the recommendation 1804 comprises a recommendation to move a bill to a different day of the month, such as a later day in the month when the account is predicted to have a balance that can cover the predicted expense. In some instances, the recommendation 1804 may be selectable to cause action of the recommendation. For example, the recommendation 1804 may comprise a link that, when selected, causes the POS device 104 or other device to present a UI for requesting to move the expense to a later date. Of course, while FIG. 18 illustrates an example recommendation 1804, it is to be appreciated that the recommendation 1804 may take any other form, such as a recommendation to attempt to lessen the expense, a recommendation to cancel a service or item associated with the expense, a recommendation to take a “cash boost” or “float” (as described above), or the like. Finally, the UI 1800 includes an icon 1806 that, when selected, continues the sequence of onboarding UIs.")
Claims 11 and 18 are substantially similar to claim 5, thus, they are rejected on similar grounds.
Claim 15 is substantially similar to claim 1, thus, it is rejected on similar grounds.
Claims 4 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Reses, U.S. Patent Application Publication Number 2022/0005036; in view of Templeton, U.S. Patent Application Publication Number 2019/0259095; in view of Scislowski, U.S. Patent Application Publication Number 2020/0372536.
As per claim 4,
Reses explicitly teaches:
wherein performing the action comprises: sending a message to a device associated with the account to cause:
(Reses US20220005036 at paras. 195-197) ("[0196] FIG. 24 illustrates an example UI 2400 after the user has selected the icon 2306. As illustrated, the UI 2400 may enable the user to perform actions such as “make a big payment”, save for an “unexpected expense”, “buy new equipment”, “prepare for taxes”, or the like. In response to selecting one or more of these options, the payment service 108 (e.g., the underlying application provided by the payment service 108) may initiate a workflow for performing the requested action.")
Reses does not explicitly teach, however, Scislowski teaches:
a new virtual card to be activated, a new virtual card number to be established, and the new virtual card to be unlocked.
(Scislowski US20200372536 at paras. 36, 45) ("[0009] An example disclosed system for operating a pool of virtual credit cards for airline passenger vouchers includes one or more databases configured to store virtual credit cards within a virtual card pool and one or more servers. The one or more servers are configured to unlock one of the virtual credit cards stored within the virtual card pool for each accepted voucher offer of a qualifying passenger name record, remove each unlocked virtual credit card stored from virtual card pool, identify a current date-and-time, and determine a target distribution of virtual credit cards within the virtual card pool for the current date-and-time. The target distribution indicates a target quantity of cards for each of a plurality of card values. The one or more servers also are configured to determine whether the current date-and-time corresponds with a predefined restocking time to restock the virtual card pool based on the target distribution. The one or more servers also are configured to, in response to determining that the current date-and-time corresponds with the predefined restocking time, for each of the plurality of card values: identify a current number of virtual credit cards within the virtual card pool that have the card value; identify a threshold number of virtual credit cards for the card value based on the target distribution; compare the current number of virtual credit cards to the threshold number of virtual credit cards; in response to determining that the current number of virtual credit cards is less than the threshold number of virtual credit cards, transmit a request for a set of virtual credit cards having the card value to an external server of a card distributer; and add the requested virtual credit cards having the card value to the virtual card pool upon receipt from the external server." "[0036] As used herein, a “virtual credit card” and a “VCC” refer to a randomly-generated card number that is associated with a credit card account and is different than the credit card number of the credit card account. Oftentimes, a virtual credit card is a randomly-generated, single-use number that limits the virtual credit card to a single transaction through utilization of a limited-use token. Other limits may be placed on a virtual credit card, such as activation duration, credit limits, service or product type limits, etc.")
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 Reses, Templeton, and Scislowski, because it allows for improved systems to quickly and efficiently issue virtual credit cards and securely process them for billing purposes. (Scislowski at Abstract and paras. 2-21, 41).
Claim 17 is substantially similar to claim 4, thus, it is rejected on similar grounds.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Reses, U.S. Patent Application Publication Number 2022/0005036; in view of Templeton, U.S. Patent Application Publication Number 2019/0259095; in view of Grassadonia, U.S. Patent Application Publication Number 2018/0005229.
As per claim 13,
Reses does not explicitly teach, however, Grassadonia teaches:
wherein the one or more instructions, when executed by one or more processors of the system, further cause the system to: store the predicted amount in an account database associated with the account.
(Grassadonia US20180005229 at paras. 77-79) ("[0078] FIG. 15 includes exemplary pseudo code for two subroutines. The first is named “is_recurring,” and is an exemplary method for determining whether a transaction is recurring. The server 104 can compare the current incoming transaction to all previous debit or credit transactions to see whether the transaction matches a previous transaction. The comparison between transactions can use an overloaded comparison method for determining whether two transactions match. The overloaded method can assess time of transaction, number of recurrences, amounts, etc. to determine whether the transactions match. To determine whether there is a match, the server 104 can compare transaction data to determine whether they are sufficiently similar. For example, if the dates are sufficiently similar to the same day of the month within a predetermined number of days, e.g., 5 days; if the amounts are sufficiently the same within a predetermined amount, e.g., $50 or 10%, or if the payees or payors are the same. The server 104 can take any combination of the parameters, such as if there are one, two or three matches, then that can mean that the transactions are sufficiently similar. Other transaction data can similarly be checked, such as MCC code, account numbers, addresses, and payment types. If the there is a match, then the server 104 can create a new recurring transaction using a make_recurring method, which can generate a predicted debit or credit transaction or potential transaction, comprising transaction data, such as amount, date, and payee/payor, which can be stored in one of databases 107a-n and used to predict a balance. The server 104 can also remove recurring transactions if they do not in fact occur, therefore the predicted transactions will only potentially occur. For example, if a user moves and no longer pays rent, the server 104 can expect a recurring payment to be made, but does not see it, and therefore can prompt the user to approve removing that recurring payment.")
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 Reses, Templeton, and Grassadonia, because it can allow for more accurate, real-time accounting information by logically separated subaccounts at a server that has increased visibility of financial transactions. The increased visibility improves the function of the computer by allowing more control over the computer network and transactions that occur over the network, as explained throughout this specification. The system can predict a balance, display the predicted balance on this user interface, and update the user interface upon the execution of scheduled and unscheduled transactions. (Grassadonia at Abstract and paras. 1-21).
Claims 14 and 16 is rejected under 35 U.S.C. 103 as being unpatentable over Reses, U.S. Patent Application Publication Number 2022/0005036; in view of Templeton, U.S. Patent Application Publication Number 2019/0259095; in view of Burton, U.S. Patent Application Publication Number 2008/0114676.
As per claim 14,
Reses does not explicitly teach, however, Burton teaches:
wherein the account is associated with one or more conditions including one or more of: the account has a current balance that is over a credit limit associated with the account, the account has a current balance that is over an authorized user limit associated with the account, the account is associated with a transaction card that is expired, the account is associated with a transaction card that is reported as lost, the account is associated with a transaction card that is reported as stolen, the account is associated with a transaction card that is locked, or the account is in a past due status.
(Burton US20080114676 at paras. 29-35) ("[0035] The customer makes a $100 charge 250 to the debt recovery account 130. For example, the customer makes a purchase using the credit card she recently received. The account balance is increased to $450, which exceeds the current credit limit of $400. Open-to-buy status reverts to “no” to prevent further abuse of the account. A new open-to-buy payment is generated based upon the new account balance. In addition, any over-limit charges in the terms of the account would now apply 252.")
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 Reses, Templeton, and Burton, because it allows for improved systems for debt recovery credit account that is easier to administer and use and improved incentives for payment and limits on the credit-issuer's initial exposure to non-payment or new credit liabilities. (Burton at Abstract and paras. 1-12).
As per claim 16,
Reses does not explicitly teach, however, Burton teaches:
wherein determining that the current balance is within the threshold amount of the limit associated with the account comprises: determining that the current balance of the account is within a credit limit or an authorized user limit of the account.
(Burton US20080114676 at paras. 29-35) ("[0034] The customer makes a $100 payment 240 to the debt recovery account 130. For example, the payment may have been made in response to a second monthly bill and the customer deciding to make the open-to-buy payment on the bill. The account balance is reduced to $350 and the open-to-buy conditions are met (the account balance is $50 less than the credit limit of $400). The open-to-buy status is changed to “yes”. The open-to-buy payment is now the minimum payment required according to the terms of the credit account. As long as the minimum payment is met, the credit account remains open-to-buy. In an alternate example (not shown), the open-to-buy payment is no longer tracked or provided on the bill at all and does not reappear until open-to-buy status is lost, such as by overcharging the account. Because open-to-buy status has been achieved, a credit card is issued 242 to the customer to provide access to the debt recovery account. In addition, over-limit charges will apply to any future charges that carry the account balance over the credit limit.")
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 Reses, Templeton, and Burton, because it allows for improved systems for debt recovery credit account that is easier to administer and use and improved incentives for payment and limits on the credit-issuer's initial exposure to non-payment or new credit liabilities. (Burton at Abstract and paras. 1-12).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is available for review on Form PTO-892 Notice of References Cited.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MERRITT J HASBROUCK whose telephone number is (571)272-3109. The examiner can normally be reached M-F 9:00-5:00.
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, Christine Tran can be reached on 571-272-8103. 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.
/MERRITT J HASBROUCK/Examiner, Art Unit 3695
/CHRISTINE M Tran/Supervisory Patent Examiner, Art Unit 3695