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 .
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references cited in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Response to Amendment
The Amendment filed 3/12/2026 has been entered. Claims 2, 7, 11, 16, and 20 have been canceled. New claims 21-25 have been added. Claims 1, 3-6, 8-10, 12-15, 17-19, and 21-25 remain pending in the present Office Action.
Claim Objections
Claim 1 is objected to because of the following informalities:
Claim 1, line 7, should be amended to recite “based on ”.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 6, 9-10, 15, 18-19, 21 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Purdy (U.S. Pub. No. 2023/0419183) in view of Ruff et al. (U.S. Pub. No. 2015/0379488), hereinafter Ruff.
Regarding claim 1, Purdy teaches A method for providing an asset savings notification to a user ([0007] – “This disclosure describes one or more embodiments of methods, non-transitory computer readable media, and systems that can solve the foregoing problems in addition to providing other benefits by utilizing machine learning models to intelligently transmit pre-emptive digital notifications to client devices across computer networks.”), the method comprising:
determining, by user evaluation circuitry ([0103] – “Embodiments of the present disclosure may comprise or utilize a special purpose or general-purpose computer including computer hardware, such as, for example, one or more processors and system memory […] In general, a processor (e.g., a microprocessor) receives instructions, from a non-transitory computer readable medium, (e.g., a memory, etc.), and executes those instructions, thereby performing one or more processes, including one or more of the processes described herein.”; [0107] – “computer-executable instructions are executed on a general-purpose computer to turn the general-purpose computer into a special purpose computer implementing elements of the disclosure.”; [0112] – “processor(s) 702 includes hardware for executing instructions”.
For clarity of the record, the Examiner would like to point to paragraph [0040] of the Specification which recites “while the terms "circuitry" and "engine" should be understood broadly to include hardware, in some embodiments, the terms "circuitry" and "engine" may in addition refer to software instructions that configure the hardware components of the apparatus 200 to perform the various functions described herein.” Thus, any of the claimed “circuitry” is understood to be any hardware and/or software which configures the hardware to perform the claimed functions.) and using an event prediction model, a user event prediction for the user based on internal source data, wherein the user event prediction comprises an event time frame during which an event is predicted to occur within ([0020] – “the pre-emptive notification system can utilize a decision availability prediction machine learning model to generate a predicted asset availability time for a client account (e.g., a particular time for which an account asset, such as a direct deposit, will become available within a client account).”; [0045] – “the preemptive notification system 102 performs an act 204 of determining account features. For instance, the pre-emptive notification system 102 can extract a recent schedule of direct deposits for a client account corresponding to the client device 214.”; [0046] – “the pre-emptive notification system 102 utilizes the account features with the availability prediction machine learning model 206 and the intent prediction machine learning model 208 to perform an act 210 of determining a pre-emptive digital notification. For example, the availability prediction machine learning model 206 can analyze one or more account features and generate a predicted asset availability time. To illustrate, the pre-emptive notification system 102 can determine an anticipated time that a direct deposit amount will be available via the client account.”; [0052]-[0053] – “The pre-emptive notification system 102 can extract the account features 300 from a variety of sources, including a digital account corresponding to a user, the client device 312, and/or a database of historical interactions or information pertinent to a user/client device. […] extract the account features 300 from a value metric such as an account balance for a digital account, the value of a direct deposit, the value of a transaction made on the digital account, the value of interest accrued on a digital account, […] the account features 300 can include user attributes (e.g., age, income, location, etc.).”; [0056] – “upon determining the account features 300, the pre-emptive notification system 102 utilizes the availability prediction machine learning model 301 to determine a predicted asset availability time. […] the predicted asset availability time can include a prediction of a direct deposit amount and a day/time that the direct deposit amount will be available via a client account.”; [0059] – “the LSTM can predict a new direct deposit time (and/or amount) based on the sequence of previous direct deposit times”. “Account features”, which include income data of a user, is analogous to the claimed “internal source data”. As shown in example notifications in FIGS. 1, 2, and 4, the predicted asset availability time could be a day, e.g. “today”, which is a time frame in which the direct deposit becomes available (e.g., an event) is predicted to occur.);
in response to determining the user event prediction, determining, by the user evaluation circuitry and based on the the internal source data, a predicted liquid asset influx for the user event prediction ([0056] – “upon determining the account features 300, the pre-emptive notification system 102 utilizes the availability prediction machine learning model 301 to determine a predicted asset availability time. As shown, the predicted asset availability time can include an amount 303 and a time 305. For example, the predicted asset availability time can include a prediction of a direct deposit amount and a day/time that the direct deposit amount will be available via a client account.”; [0059] – “the LSTM can predict a new direct deposit time (and/or amount) based on the sequence of previous direct deposit times”.
For clarity of the record, the Examiner would like to point to paragraph [0061] of the Specification, which recites “determine a predicted liquid asset influx in response to determining the user event prediction. The predicted liquid asset influx may be indicative of a value or value range of funds that correspond to the event described by the user event prediction. The predicted liquid asset influx may therefore be indicative of a predicted amount of funds that the user is predicted to receive during the event time frame.” Thus, the predicted direct deposit amount corresponding to the predicted asset availability time is thus analogous to the “predicted liquid asset influx”. Predicting the asset availability time (“determining the user event prediction”) comprises predicting the amount, thus the amount is determined “in response to” determining the prediction.);
generating, by the user evaluation circuitry, the asset savings notification, wherein the asset savings notification comprises an indication of the predicted liquid asset influx and the event time frame ([0071] – “the pre-emptive notification system 102 also utilizes the predicted asset availability time to generate the pre-emptive digital notification. For example, the pre-emptive notification system 102 generates a pre-emptive digital notification that references predicted asset availability time.”; [0048] – “the pre-emptive notification system 102 can also determine the pre-emptive digital notification based on the predicted asset availability time. For example, the pre-emptive digital notification can include a reference to the predicted asset availability.”; [0056] – “the predicted asset availability time can include an amount 303 and a time 305. For example, the predicted asset availability time can include a prediction of a direct deposit amount and a day/time that the direct deposit amount will be available via a client account.” Since the notification can include the predicted asset availability time and the predicted asset availability time can include an amount (“predicted liquid asset influx”) and a time (“event time frame”), the generated notification can include both the amount and the time.);
providing, by communications hardware ([0037] – “the pre-emptive notification system 102 utilizes the network 112 to communicate with the client device 108”; [0117] – “communication interface 710 can include hardware software, or both. The communication interface 710 can provide one or more interfaces for communication (such as, for example, packet-based communication) between the computing device and one or more other computing devices 7 00 or one or more networks.”), the asset savings notification to a user device of the user prior to the event time frame ([0021] – “the pre-emptive notification system provides a pre-emptive digital notification to a client device regarding the account asset and/or the predicted asset availability time.”; [0049] – “the pre-emptive notification system 102 provides the pre-emptive digital notification to the client device 214.”; [0075] – “the pre-emptive notification system 102 provides the pre-emptive digital notification 310 a certain time prior to the predicted asset availability time (e.g., 24 hours, 12 hours, 6 hours, or 1 hour prior to the predicted asset availability time)”); […]
[…], monitoring, by the user evaluation circuitry, for receipt of the predicted liquid asset influx in a user account of the user ([0082]-[0083] – “the pre-emptive notification system 102 can continue to monitor the status of the predicted future event and provide status updates in the form of additional notifications. For example, and as illustrated in FIG. 4, after the pre-emptive notification system 1 02 provides the pre-emptive digital notification related to a predicted asset availability corresponding to the user account, the pre-emptive notification system 102 continues to monitor for status progression of the predicted asset availably.”; [0088] – “For example, and continuing with the example described in FIG. 4, the pre-emptive notification system 102 can detect that the direct deposit has funded into the client account.”).
Purdy fails to expressly teach receiving, by the communications hardware, user input authorizing a portion of the predicted liquid asset influx to be rerouted to a different user account; in response to receiving the user input, monitoring for receipt of the predicted liquid asset influx in a user account of the user; and automatically rerouting, by the user evaluation circuitry, the portion of the predicted liquid asset influx from the user account to the different user account.
However, Ruff teaches receiving, by the communications hardware, user input authorizing a portion of the predicted liquid asset influx to be rerouted to a different user account ([0055]-[0057] – “the user accesses the user Interface 102 (described in more detail in FIG. 2) through an electronic device. The user answers a series of survey questions, illustrated here as user Input, that establish a knowledge base about the user including information such as, but not limited to: […] the user's financial goals and objectives, the user's income and projected expenses, and/or the user's assets and liabilities. […] A portion or all of the Account Configuration Instructions can then be sent, as Data & Input Requests, from the Processing Systems 104 to the user Interface 102 for the user to approve, modify, and/or reject. Configuration Instructions can include, but would not be limited to: how many and what types of Accounts to establish, […] how much, how often, and from what sources each Account should be funded. The approved, modified, and/or rejected Configuration Instructions are then sent to the Processing Systems 104 as revised user Input. Once approved, Configuration Instructions received by the Processing Systems 104 are relayed to the user's Accounts Configuration 106 (described in more detail in FIG. 4) as approved Configuration Instructions to be automatically implemented. Money, in the form of lncome or Incoming Transfers of money from other external sources, can be deposited into one of the user's Accounts that exist within the user's Accounts Configuration 106. […] As new deposits are made, money is transferred”; [0152]-[0153] – “The user can also be offered suggested amounts to allocate to each Account, how often the Accounts should be funded, and from what sources, whether from external deposits directly to the Accounts or internal transfers from one or more existing Accounts. […] Once the recommendations have been delivered to the user for review and edit, the system has the ability to receive authorization from the user to automatically execute the series of steps to configure and implement the strategies and/or other recommendations.” The user authorizes Configuration Instructions to be implemented, which may include accounts to be established and an amount of money to be transferred (“rerouted”) from one account to another account. The Configuration Instructions may have been generated based on predicted user income (“predicted liquid asset influx”): [0146] – “The objective of the survey is to gather and determine specific important facts about the user's personal financial situation and financial goals.”; [0158] – “Facts about the user's personal financial situation and financial goals can include information such as but not limited to: […] current and future projected income”, and as identified below, income in the form of direct deposits is transferred from income accounts to other accounts according to the authorized Configuration Instructions.); in response to receiving the user input, monitoring for receipt of the predicted liquid asset influx in a user account of the user ([0068] – “the Active Agent Processing System 308 is an automated processing system that is continuously searching out and compiling Account Data (information about the user' s Accounts such as current account balance, pending transactions, pending transfers to and from the Account, cleared transaction history, balance history, and other relevant information about the user' s Accounts)”; [0229]-[0231] – “An Active Agent ("AA") can include a computer processing system that actively searches, locates, monitors, and gathers the latest updates to both internal user data and externally available information, and automatically incorporates that collective original and updated information in active and ongoing analysis and assessment of a users' financial situation and behavior, including allocation of a user's financial resources. […] The AA can be configured to interface with other internal or external processing systems to actively search, locate, monitor, gather, determine, and make recommendations and, in some embodiments, directly make changes or allocations to Accounts. External processing systems can include ACH, direct deposit or other payroll or income sources […] The AA processing system can monitor, gather, and incorporate real-time, updated knowledge of internal user data, including the following, affecting a user's financial matters: 1) Income flows”; [0268] – “In block 802, an income account system receives assets from an incoming resource processing system, such as a direct deposit” User’s accounts are established according to the authorized Configuration Instructions – see [0094]; thus, the Active Agent monitoring the user’s accounts is “in response to receiving the user input”, where the user input was the authorization of the Configuration Instructions.); and automatically rerouting, by the user evaluation circuitry ([0276]), the portion of the predicted liquid asset influx from the user account to the different user account ([0022] – “"Accounts," can receive, hold, and allow the transfer of digital money or other financial resources based on configuration information, or "Configuration Instructions."”; [0094] – user accounts in Accounts Configuration 400 are established and configured according to Configuration Instructions; [0097] – Income Accounts are configured to receive income, and money in income accounts are transferred to other accounts in the user’s Account Configuration 400, such as a Master Transfer Account or Category Spending Account; [0099] – a Master Transfer Account facilitate further transfer to other accounts; [0107] – “as money gets deposited into an Income Account 402, the money is instantly and automatically transferred out to another internal Account for more secure safekeeping.”; [0268] – “In block 802, an income account system receives assets from an incoming resource processing system, such as a direct deposit. In block 804, the income account system transfers the assets to a protected master control processing system, such as a system that provides a master transfer account service. In block 806, the assets are distributed to internal systems according to a configuration, such as distribution to savings and spending accounts.”; [0139] – “The user can choose to pay back the money from the Account that received the extra money or from any other Account. The money to pay back the Account can be taken out all at once, at a later specified date, or over time by rerouting a percentage of the user's weekly transfer from another Account or Accounts, until the amount that was taken is paid back.”).
Purdy and Ruff are considered to be analogous art to the claimed invention because they are reasonably pertinent to the problem faced by the inventor of predicting and handling a liquid asset influx received in a user account. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the methods of Purdy to incorporate the teachings of Ruff including receiving a user input authorizing rerouting of a portion of the predicted liquid asset influx (as taught by Purdy) to a different user account and the monitoring for receipt of the predicted liquid asset influx in a user account is performed in response to the user input, and automatically rerouting the portion of the predicted liquid asset influx from the user account to the different user account as taught by Ruff. Doing so would provide improve security by automatically routing the influx to a more secure account (Ruff: [0107]), and recommending particular accounts to set up and automatic transfers between the accounts for the user to authorize saves the user time and provides help to the user in managing his or her financial matters (Ruff: [0041] and [0154]).
Regarding claim 6, the combination of Purdy in view of Ruff teaches the method of claim 1. Purdy further teaches wherein the user event prediction comprises one or more of a contribution limit event, a temporally periodic event, or a circumstantial event ([0079] – “the pre-emptive notification system 102 can determine that a client account has historically received a direct deposit on a particular day each month and based on detecting that the current date is within some threshold time of the determined day, the pre-emptive notification system 102 can detect the trigger notification event associated with the expected direct deposit.” Direct deposit events are temporally periodic events. Since the claim recites “one or more of a contribution limit event, a temporally periodic event, or a circumstantial event” in the alternative, only one of the alternatives is required by the claim language.).
Regarding claim 9, the combination of Purdy in view of Ruff teaches the method of claim 1. Purdy teaches the method further comprising:
receiving, by the communications hardware, a status update request from the user, wherein the asset savings notification is provided in response to the status update request ([0034] – “a trigger notification event can include a client device accessing a particular application, […], a client device contacting a server, or a client device accessing a client account.”; [0037] – “the pre-emptive notification system 102 utilizes the network 112 to communicate with the client device 108”; [0041] – “the pre-emptive notification system 102 communicates with the client device 108 through the device application 109.”; [0078] – “the pre-emptive notification system 102 can detect a trigger notification event 402. A trigger notification event includes any detectable signal or feature associated with a client account that pre-emptive notification system 102 uses, at least in part, to determine to provide a pre-emptive digital notification. Examples of a trigger notification event can include an application initiation event that indicates initiation of a session within an application of a client device corresponding to a client account (e.g., opening a client application). In the same or other embodiments, detecting a trigger notification event can include the pre-emptive notification system 102 detecting a particular user action within a client application (e.g., navigating to an account balance UX within the client application).”; [0079] – “a particular status associated with a client account (e.g., account balance, transfer notifications, transfer amounts, credit usage, account history, or any statuses associated with a client account).” A user opening an application or navigating to an account balance in an application on the client device can be considered the user “requesting” an update of the status of their account, e.g., of their account balance. Further, Purdy teaches communications between inter-network facilitation system 104, comprising pre-emptive notification system 102 on server 102 with communications interface 710, and the client device 108, and thus the user interacting with an application on the client device, may be in the form of HTTP or API requests (see [0123] and [0130]-[0131]).).
Regarding claim 10, Purdy teaches An apparatus for providing an asset savings notification to a user ([0103] – “Embodiments of the present disclosure may comprise or utilize a special purpose or general-purpose computer including computer hardware, such as, for example, one or more processors and system memory […] In general, a processor (e.g., a microprocessor) receives instructions, from a non-transitory computer readable medium, (e.g., a memory, etc.), and executes those instructions, thereby performing one or more processes, including one or more of the processes described herein.”; [0107] – “computer-executable instructions are executed on a general-purpose computer to turn the general-purpose computer into a special purpose computer implementing elements of the disclosure.”; [0111] – “FIG. 7 illustrates, in block diagram form, an exemplary computing device 700 (e.g., the client device 108, or the server(s) 106) that may be configured to perform one or more of the processes described above.”; [0112] – “processor(s) 702 includes hardware for executing instructions”; [0117] – “communication interface 710 can include hardware”), the apparatus comprising: the circuitry and hardware which perform the method of claim 1. As such, claim 10 is rejected as being unpatentable over Purdy in view of Ruff for the same reasons presented with respect to claim 1.
Claims 15 and 18 recite substantially the same limitations as claims 6 and 9, respectively, applied to the apparatus of claim 10. As such, claims 15 and 18 are rejected as being unpatentable over Purdy in view of Ruff for the same reasons presented with respect to claims 6 and 9.
Regarding claim 19, Purdy teaches A computer program product for providing an asset savings notification to a user, the computer program product comprising at least one non-transitory computer-readable storage medium storing software instructions that, when executed ([0123] – “Embodiments within the scope of the present disclosure also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures. In particular, one or more of the processes described herein may be implemented at least in part as instructions embodied in a non-transitory computer-readable medium and executable by one or more computing devices”), cause an apparatus to: perform the method of claim 1. As such, claim 19 is rejected as being unpatentable over Purdy in view of Ruff for the same reasons presented with respect to claim 1.
Regarding claim 21, the combination of Purdy in view of Ruff teaches the method of claim 1. Ruff teaches the method further comprising:
generating, by the user evaluation circuitry and based on the predicted liquid asset influx, a resource allocation recommendation that identifies the different user account and the portion of the predicted liquid asset influx ([0059]-[0060] – “The user initially begins use of the Setup Wizard 204 by completing a survey, contained within the Setup Wizard 204. The survey solicits information about the user in order to establish a knowledge base about the user. The user may be asked questions in the survey that are related to subjects such as, but not limited to: […] the user' s income and projected expenses, and/or the user' s assets and liabilities. Information gathered from the user in the survey is sent to the Processing Systems as user Input, where it is analyzed to create Configuration Instructions. Configuration Instructions can include, but would not be limited to: recommendations as to what bank accounts or prepaid debit card accounts to establish, an allocation amount for each account, an allocation schedule for each account”; The Configuration Instructions (comprising a “resource allocation recommendation”) may have been generated based on predicted user income (“predicted liquid asset influx”) gathered in the survey: [0146] – “The objective of the survey is to gather and determine specific important facts about the user's personal financial situation and financial goals.”; [0158] – “Facts about the user's personal financial situation and financial goals can include information such as but not limited to: […] current and future projected income”.; [0152] – “The user can also be offered suggested amounts to allocate to each Account, how often the Accounts should be funded, and from what sources, whether from external deposits directly to the Accounts or internal transfers from one or more existing Accounts.”; [0154] – “The recommended Accounts, funding parameters, automatic transfers, and other recommendations”; [0155] – “configuration wizard is presented in the form of a survey to help users quickly and easily set up and configure a personalized version of The Money Pool System™ or variant of The Money Pool System™, including the specific or recommended categories of spending Accounts, and the specific or recommended dollar amounts of periodic allocation and transfers into each spending or other Account”); and
providing, by communications hardware, a resource allocation recommendation message comprising the resource allocation recommendation to the user device prior to the event time frame, wherein the user input is received in response to providing the resource allocation recommendation message ([0056] – “A portion or all of the Account Configuration Instructions can then be sent, as Data & Input Requests, from the Processing Systems 104 to the user Interface 102 for the user to approve, modify, and/or reject. Configuration Instructions can include, but would not be limited to: how many and what types of Accounts to establish, […] how much, how often, and from what sources each Account should be funded. The approved, modified, and/or rejected Configuration Instructions are then sent to the Processing Systems 104 as revised user Input.”; [0061] – “The Configuration Instructions are then sent to the Setup Wizard 204 in the form of Data & Input Requests for the user to view, edit, reject, and/or approve each of the Configuration Instructions. The modified and/or approved Configuration Instructions are then sent to the Processing Systems as user Input to be implemented at the financial institution.”; [0062] – “The user Dashboard 206: After the initial setup has been completed, the user rarely has a need to continue to use the Setup Wizard 204”. The recommendations in the Configuration Instructions (“resource allocation recommendation message”) are sent to the a user device, and presented in a user interface at time of setup, e.g., at set up of the accounts, which would be “prior to the event time frame”, i.e., when a deposit is received in one of the accounts. [0148] – “These recommendations are delivered to the user, for the user to edit and review, in the form of […] on a computer or other electronic device.”; [0153] – “Once the recommendations have been delivered to the user for review and edit, the system has the ability to receive authorization from the user to automatically execute the series of steps to configure and implement the strategies and/or other recommendations.”).
It would have been obvious to one of ordinary skill in the art to have modified the teachings of Purdy to incorporate the teachings of Ruff. Recommending particular accounts to set up and amounts for automatic transfers between the accounts for the user to authorize saves the user time and provides help to the user in managing his or her financial matters (Ruff: [0041] and [0154]).
Regarding claim 25, the combination of Purdy in view of Ruff teaches the method of claim 1. Purdy further teaches wherein at least one of the user account or the different user account is a savings user account, a checking user account, a credit card user account, a user investment account, or a user loan account ([0062] – “a credit card with a linked, secured cash account”; [0078] – “checking account”; [0079] – “the pre-emptive notification system 102 can detect trigger notification events related to a particular status associated with a client account (e.g., account balance, transfer notifications, transfer amounts, credit usage, account history, or any statuses associated with a client account).”; [0124] – “an online bank account, credit account, debit account, or other financial account”).
Claims 3 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Purdy in view of Ruff as applied to claims 1 and 10, and further in view of Bueche, Jr. (U.S. Patent No. 8,527,376), hereinafter Bueche.
Regarding claim 3, the combination of Purdy in view of Ruff teaches the method of claim 1. Purdy further teaches wherein the internal source data comprises income data ([0052] – “extract the account features 300 from a variety of sources, including a digital account corresponding to a user, the client device 312, and/or a database of historical interactions or information pertinent to a user/client device.; [0053] – “extract the account features 300 from a value metric such as an account balance for a digital account, the value of a direct deposit, the value of a transaction made on the digital account, the value of interest accrued on a digital account, […] the account features 300 can include user attributes (e.g., age, income, location, etc.).”; [0080] – “information coming from another service, such as from payroll or processing sources.”).
The combination of Purdy in view of Ruff fails to expressly teach the income data is sourced from one or more of direct deposit documents, paycheck documents, or self-reported income for the user.
However, Bueche teaches the income data is sourced from one or more of direct deposit documents, paycheck documents, or self-reported income for the user (Col. 3, lines 11-16 – “The financial institution 130 may receive a direct deposit data file representing a direct deposit from the payor 160 to the user 110 and may use any known processing software or other application(s) to obtain data from the direct deposit data file that may be used for income itemization and income tax liability information.”; Col. 3, lines 49-50 – “a direct deposit, such as a payroll payment“; Col. 4, lines 52-54 – “The income itemization may comprise a report that provides an indication of income the user 110 earned over the year, via direct deposit,”; Col. 5, lines 49-54 – “The income itemization engine 221 has access to data, files, and documents pertaining to the user 110 as well as any other data, files, and documents that may be useful in generating an income itemization and information pertaining to income tax liabilities that are currently stored by the financial institution 130 as well as external data, files, and documents.”; Col. 7, lines 61-67 – “At 350, the user's financial institution may extract data from the direct deposit data file that may be used to generate an income itemization and income tax liability information. The extracted data may comprise the date of deposit, amount of deposit, payor as well as the supplemental information that was previously appended to the direct deposit information. The financial institution may store the extracted data at 360” Direct deposit data may be represented as a file from the payor. The amount of the deposit (e.g. income) can be extracted. Since the claim recites “one or more of direct deposit documents, paycheck documents, or self-reported income” in the alternative, only one of the alternatives is required by the claim language).).
Bueche is considered to be analogous art to the claimed invention as it is reasonably pertinent to the problem faced by the inventor of identifying income data for a user. Therefore, it would have been obvious to one of ordinary skill in the art that the variety of sources from which the account features (including income and/or direct deposit data) taught by Purdy could include direct deposit documents as taught by Bueche. Sourcing income data from one or more direct deposit documents in the manner taught by Bueche enables generation of an income itemization report to aid and reduce the burden of determining and paying income taxes for a user (Bueche: Col. 1, lines 27-38 and Col. 4, lines 49-61).
Claim 12 recites substantially the same limitations as claim 3, applied to the apparatus of claim 10. As such, claim 12 is rejected as being unpatentable over Purdy in view of Ruff, and further in view of Bueche for the same reasons presented with respect to claim 3.
Claims 4-5 and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Purdy in view of Ruff as applied to claims 1 and 10, and further in view of PHILLIPS et al. (U.S. Pub. No. 2021/0217104), hereinafter PHILLIPS.
Regarding claim 4, the combination of Purdy in view Ruff teaches the method of claim 1, but fails to teach wherein determining the user event prediction further comprises: identifying, by the user evaluation circuitry and based on the internal source data, an employer organization associated with the user; and determining, by organization analysis circuitry, one or more organization attributes for the employer organization, wherein at least one of (i) determining the user event prediction or (ii) determining the predicted liquid asset influx is based on the one or more organization attributes.
However, PHILLIPS teaches identifying, by the user evaluation circuitry ([0244] – embodiments implemented on hardware such as circuits) and based on the internal source data, an employer organization associated with the user ([0061]-[0062] – “A user interface 101 may receive an identifier of an income source, such as an employer number or an employer name, via an employer field 134. […] user interface 101 may receive additional information related to an income source. In some embodiments, additional information may also be, or alternatively be, related to the user of the user account. For example, a user interface 101 may receive an indication of a user' s role and/or job title with respect to an employer identified with an income source.”; [0068] – “A bonus calculator may estimate at least one bonus amount for a user based on one or more data sources 137. Data sources 137 may include information related to the user's employment. For example, a bonus calculator may base estimations on employer information associated with the customer. Some embodiments may include information associated with sources 125 in employer information, such as an employer identifier. Some embodiments may receive and/or retrieve further information about a user's employment for bonus calculations.”; [0072] – “A user interface 101 may receive information related to one or more data sources 137. For example, a bonus calculator interface 138 of a user interface 101 may include fields such as employer field 134 and job field 135 to receive information about a user's employment (not shown).” Income data (analogous to the “internal source data”) may include data about the source of income, such as employer information.); and determining, by organization analysis circuitry, one or more organization attributes for the employer organization, wherein at least one of (i) determining the user event prediction or (ii) determining the predicted liquid asset influx is based on the one or more organization attributes ([0067] – “Employees may receive bonuses of pre-known amounts or bonuses that are determined by at least one of an employer, a role, time employed by the employer, department, co-worker reviews, performance metrics, or other variable terms. If a bonus amount is predictable, data about the expected payment may be received via a user interface 101 and saved. For example, bonus data may include the providing employer, an amount of the estimated bonus, and an estimated timestamp of receipt of the bonus.”; [0068] – “Alternatively, or additionally, embodiments may include a bonus calculator. A bonus calculator may estimate at least one bonus amount for a user based on one or more data sources 137. Data sources 137 may include information related to the user's employment. For example, a bonus calculator may base estimations on employer information associated with the customer.”; [0069] – “Data sources 137 may additionally, or alternatively, include data managed by employers or third-party systems. For example, the source "Glasswindow" may be a website including information about one or more companies, including reports from employees about salary and bonuses associated with job titles, time worked at the company, and co-worker review data.”; [0071] – “In exemplary interface l00F, the illustrated selection of "Glasswindow" and the deselection of "Co-worker Polls" may direct calculation of an estimated bonus to include data from Glasswindow but not co-worker polls, for example.”; [0048]-[0049] – “available sources 125 include "Car Service," "RentYourHome," "DigitWallet," "Payroll," "Bonus Calculator," and "Custom Source 1 ." […] incoming fund estimations in association with the source 125 […] a user interface may display an estimated incoming fund amount in association with an estimated time of the incoming fund.”).
PHILLIPS is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of determining a user event prediction comprising an event time frame and a determining a predicted liquid asset influx corresponding to the user event prediction. Thus, it would have been obvious to have modified the teachings of Purdy to incorporate the teachings of PHILLIPS. Doing so enables better estimation of income from multiple income sources, including irregular income sources (PHILLIPS: [0013] and [0016]).
Regarding claim 5, the combination of Purdy in view of Ruff teaches the method of claim 1, but fails to teach the method further comprising: identifying, by the user evaluation circuitry and based on the internal source data, an employer organization associated with the user; identifying, by the user evaluation circuitry, one or more other users associated with the employer organization; identifying, by the user evaluation circuitry, a similar user subset from the one or more other users, wherein the similar user subset comprises one or more users determined to share one or more attributes with the user; and performing, by the user evaluation circuitry, an analysis on the similar user subset, wherein at least one of (i) determining the user event prediction or (ii) determining the predicted liquid asset influx is further based on the analysis of similar user subset.
However, PHILLIPS teaches identifying, by the user evaluation circuitry ([0244] – embodiments implemented on hardware such as circuits) and based on the internal source data, an employer organization associated with the user ([0061]-[0062] – “A user interface 101 may receive an identifier of an income source, such as an employer number or an employer name, via an employer field 134. […] user interface 101 may receive additional information related to an income source. In some embodiments, additional information may also be, or alternatively be, related to the user of the user account. For example, a user interface 101 may receive an indication of a user' s role and/or job title with respect to an employer identified with an income source.”; [0068] – “A bonus calculator may estimate at least one bonus amount for a user based on one or more data sources 137. Data sources 137 may include information related to the user's employment. For example, a bonus calculator may base estimations on employer information associated with the customer. Some embodiments may include information associated with sources 125 in employer information, such as an employer identifier. Some embodiments may receive and/or retrieve further information about a user's employment for bonus calculations.”; [0072] – “A user interface 101 may receive information related to one or more data sources 137. For example, a bonus calculator interface 138 of a user interface 101 may include fields such as employer field 134 and job field 135 to receive information about a user's employment (not shown).” Income data (analogous to the “internal source data”) may include data about the source of income, such as employer information.); identifying, by the user evaluation circuitry, one or more other users associated with the employer organization ([0128] – “user performance data 314 may include a record of a user's historic employment with respect to an income source, for example, a duration of employment in a particular position. User performance data 314 may be based on an individual user or based on a comparison of metrics for a user to metrics to other employees of the entity of the income source.”; [0147] – “an income estimation may be based on the historic contributions of the same or similar income sources for other or similar users”; [0153] – “a bonus calculation component 350 may include a model trained on user data 304 relating to an income source, a position, a user's employment, records of historic bonuses associated with employees of the income source, and/or other data.”; [0196] – “similar employees of the income source”); identifying, by the user evaluation circuitry, a similar user subset from the one or more other users, wherein the similar user subset comprises one or more users determined to share one or more attributes with the user ([0069] – “the source "Glasswindow" may be a website including information about one or more companies, including reports from employees about salary and bonuses associated with job titles”; [0119] – “user data 304 may include a measure of similarity between users, indications of groups of similar users, or other metric of comparison of users”; [0147] – “an income estimation may be based on the historic contributions of the same or similar income sources for other or similar users, based on user data 304.”; [0150] – “an income source which has reliably contributed to the incomes of other users similar to the user may have a high reliability score”; [0157] – “users with similar estimations of income flow, credit history, employment history, schedule, skill set, and/or another factor.”; [0196] – “similar employees of the income source” ); and performing, by the user evaluation circuitry, an analysis on the similar user subset, wherein at least one of (i) determining the user event prediction or (ii) determining the predicted liquid asset influx is further based on the analysis of similar user subset ([0147] – “an income estimation may be based on the historic contributions of the same or similar income sources for other or similar users, based on user data 304.”; [0196] – “if a secondary income stream corresponds to an auxiliary bonus, logic at block 417 may determine a probability of a user receiving an amount as a bonus based on historic bonuses received from the corresponding income source, time spent in a position associated with the income source, performance reviews for the user associated with the income source, and reports of bonuses received by similar employees of the income source.” Bonuses or income, e.g. salary or payroll contributions, for a user may be estimated based on historic bonuses or income of similar users/employees of the income source (e.g., an employer). To obtain this data for these estimations, it would necessarily require identifying other users of the same income source, i.e., other users associated with the employer organization, and identifying users similar to the user, and identifying the overlap of the users of the same income source and the similar users, i.e., the “similar user subset”).).
PHILLIPS is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of determining a user event prediction comprising an event time frame and a determining a predicted liquid asset influx corresponding to the user event prediction. Thus, it would have been obvious to have modified the teachings of Purdy to incorporate the teachings of PHILLIPS. Doing so enables better estimation of income from multiple income sources, including irregular income sources (PHILLIPS: [0013] and [0016]).
Claims 13-14 recite substantially the same limitations as claims 4-5, applied to the apparatus of claim 10. As such, claims 13-14 are rejected as being unpatentable over Purdy in view of Ruff, and further in view of PHILLIPS for the same reasons presented with respect to claims 4-5.
Claims 8 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Purdy in view of Ruff as applied to claims 1 and 10, and further in view of Grossblatt et al. (U.S. Patent No. 8,498,910), hereinafter Grossblatt.
Regarding claim 8, the combination of Purdy in view of Ruff teaches the method of claim 1, but fails to teach the method further comprising: determining, by the user evaluation circuitry, a user contribution metric set for the user, wherein (i) the user contribution metric set is indicative of one or more user contribution metrics in one or more contribution fields over a particular time frame of interest and (ii) the asset savings notification further comprises the user contribution metric set.
However, Grossblatt teaches determining, by the user evaluation circuitry (Col. 10, lines 42-46 – a processor such as an integrated circuit may be used to implement the teachings), a user contribution metric set for the user, wherein (i) the user contribution metric set is indicative of one or more user contribution metrics in one or more contribution fields over a particular time frame of interest (Col. 3 lines 13-19 – “or more payroll fields may be populated with […] 401K deduction, employee stock purchase plan (ESPP) contributions”; Col. 4, lines 33-40 – “A payroll rule's condition may test whether an employee's 401K retirement contribution amount exceeds 15% of the employee's gross pay for a given pay period. Accordingly, the values needed to evaluate the condition include the employee's 401K retirement contribution and the employee's gross pay. As discussed above, these values may be obtained from payroll data (e.g., payroll dollar amounts on the employee's paystub).”; Col. 5, lines 22-24 – “a rule may include a condition that tests whether the YTD 401K deduction for an employee exceeds the yearly contribution limit (e.g., $15,000).” The claimed “time frame of interest” may be a pay period or the year-to-date, depending on the rule and the corresponding metric (e.g., the percent of gross pay for a pay period or the year-to-date contributions). Col. 5, lines 43-62 – “the payroll engine (15) is configured to generate payroll previews for one or more partially-complete pay periods and/or one or more future pay periods. In one example, halfway through a current pay period, the payroll engine (150) is configured to extrapolate (i.e., estimate) existing payroll data (e.g., hours worked for the current pay period, pay for the current pay period, deductions for the current pay period, etc.) to the end of the current pay period. In addition, the payroll engine (150) is configured to extrapolate (i.e., estimate) existing payroll data to a future pay period. The employee and/or employer may be notified (e.g., via email, text message, etc.) when the payroll data has been extrapolated and is available for viewing. In one or more embodiments of the invention, the rules engine (151) is responsible for applying the payroll rules (142) to payroll data”; Col. 7, lines 51-53 – “A pay period or pay cycle may refer to any time interval over which a payroll calculation is made, whether in the past, present, and/or future.”) and (ii) the asset savings notification further comprises the user contribution metric set (Col. 6, lines 16-42 – “Before, during, or after payroll processing, one or more rules may be applied to one or more payroll fields generated by the payroll engine (150) such that the contents of the payroll may be modified according to the rules. In one or more embodiments of the invention, the message module (152) outputs the message associated with a satisfied rule. Alternatively, a link (e.g., a uniform resource locator (URL)) to the message may be outputted. In one or more embodiments of the invention, the message module (152) outputs the message according to rule-metadata of a rule that is processed by the rules engine (151). Upon application of the rule, the condition of the rule is evaluated. If the condition is satisfied, the message is sent to one or more predefined recipients (i.e., employee, employer, employee's bank or financial institution, another software application, etc.) in accordance with the rule-metadata and/or system-wide settings. For example, an employee may request the message be transmitted to his/her bank. The bank may then wish to notify the employee of the message during an online banking session.”; Col. 4, lines 40-48 – “Further, the payroll rule's message may be the following string: "Your 401K contribution for this pay period has exceeded 15% of your gross pay for this pay period. Please monitor your year-to-date 401K contribution amount and make sure you do not exceed 15% of annual gross earnings." In the event the payroll rule's condition evaluates to "TRUE", the payroll rule's message may be outputted”).
Grossblatt is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of alerting users using notifications of an a predicted event corresponding to a predicted liquid asset influx. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Purdy to incorporate the teachings of Grossblatt. Doing so would better inform employees regarding changes in their pay, including projected changes in future paychecks (Grossblatt: Col. 11, lines 22-36).
Claim 17 recites substantially the same limitations as claim 8, applied to the apparatus of claim 10. As such, claim 17 is rejected as being unpatentable over Purdy in view of Ruff and further in view of Grossblatt for the same reasons presented with respect to claim 8.
Claims 22-24 are rejected under 35 U.S.C. 103 as being unpatentable over Purdy in view of Ruff as applied to claim 21 above, and further in view of Klieman et al. (U.S. Patent No. 7,899,750), hereinafter Klieman.
Regarding claim 22, the combination of Purdy in view of Ruff teaches the method of claim 21. Purdy teaches the method further comprising determining, by the user evaluation circuitry and based on the internal source data, a current account value for the […] user account ([0051] – “the account features 300 can include the last balance, transaction activity, prior or recent direct deposit activity, a maximum/minimum balance (within a threshold time), a maximum/minimum transaction amount (within a threshold time)”; [0053] – “the pre-emptive notification system 102 can extract the account features 300 from a value metric such as an account balance for a digital account”).
The combination of Purdy in view of Ruff fails to expressly teach determining a current account value for the different user account, wherein the resource allocation recommendation is generated further based on the current account value.
However, Klieman teaches determining a current account value for the different user account (Claim 1 – “the projected balance feature being used to predict future balances of one or more selected accounts associated with computing system implemented financial management system using historical financial data or recurring financial activities associated with the one or more selected accounts”; Col. 2, lines 22-29 – “A projected balance feature calculates and estimates a projected balance of a selected account, such as a checking or savings account, at any designated future date or time frame, such as a particular day, week or month. Typically the projected balance is calculated using historical data about the account such as: current balance in the account; recurring deposits to the account, such as a weekly, biweekly, or monthly paycheck”. Determining projected balances for one or more accounts requires determining the current account balance for each account. Col. 2, lines 49-54 – “the term "automatic payment", as used independently and/or as used in the phrases such as "automatic payment rules", applies to payments, transfers, deposits or any other form of transaction that involves the movement of funds within an account, between accounts, into an account, or from an account.” Col. 16, lines 1-19 – “the automatic payment rules created might include, but are not limited to: […] transferring funds to the selected account from another account based on data obtained from the projected balance feature regarding the projected income and anticipated deposits and/or outflow of funds to/from the selected account.”) wherein the resource allocation recommendation is generated further based on the current account value (Col. 21, lines 39-52 – “recommendation notification screen 340 includes recommendation text 341. In one embodiment, recommendation text informs the user of a recommended financial action/transaction based on the user's defined financial goal from DEFINE USER GOAL OPERATION 305 and the resulting automatic payment rules created at CREATE AUTOMATIC PAYMENT RULES BASED ON PROJECTED BALANCE CONSISTENT W ITH USER GOAL OPERATION 307, as well as, or in light of, projected balance data from the projected balance feature”. A recommended action/transaction, e.g. a transfer from an another account to a selected account “the different account”, based on the automatic payment rules, which are based on projected balance data of a selected account, is also implicitly based on the current account balance, since the projected balance data is based on the current account balance.).
Klieman is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of predicting and handling predicted liquid asset influxes in a user’s account. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Purdy in view of Ruff to incorporate the teachings of Klieman. The recommendations, such as transfers between accounts, of Klieman advise and assist the user in meeting their financial goals while allowing the user to maintain control over the process (Klieman: Col. 20, lines 55-59), and making recommendations based on a projected future balance (determined based at least on a current balance) of one or more accounts provides a user with new, powerful budgeting capabilities (Klieman: Col. 2, lines 35-48).
Regarding claim 23, the combination of Purdy in view of Ruff teaches the method of claim 21. Purdy teaches the method further comprising:
providing, by the communications hardware, a user account metric request to a third-party entity, wherein the different user account is managed by the third-party entity ([0124]-[0125] – “the inter-network facilitation system 104 can send and receive network communications (e.g., via the network 804) to link the third-party-system 808. For example, the inter-network facilitation system 104 may receive authentication credentials from a user to link a third-party system 808 such as an online bank account, credit account, debit account, or other financial account to a user account within the inter-network facilitation system 104. The inter-network facilitation system 104 can subsequently communicate with the third-party system 808 to detect or identify balances, transactions, withdrawal, transfers, deposits, credits, debits, or other transaction types associated with the third-party system 808. The inter-network facilitation system 104 can further provide the aforementioned or other financial information associated with the third-party system 808 for display via the client device 806. In some cases, the inter-network facilitation system 104 links more than one third-party system 808, receiving account information for accounts associated with each respective third-party system 808 and performing operations or transactions between the different systems via authorized network connections.”; [0132] – “A third-party system 808 can communicate with the inter-network facilitation system 104 to provide financial information pertaining to balances […] a third-party system 808 communicates with the inter-network facilitation system 104 to update account balances, transaction histories, credit usage, and other internal information of the inter-network facilitation system 104”); and
receiving, by the communications hardware, a user account metric response comprising a current account value for the different user account ([0124]-[0125] – “the inter-network facilitation system 104 can send and receive network communications (e.g., via the network 804) to link the third-party-system 808. For example, the inter-network facilitation system 104 may receive authentication credentials from a user to link a third-party system 808 such as an online bank account, credit account, debit account, or other financial account to a user account within the inter-network facilitation system 104. The inter-network facilitation system 104 can subsequently communicate with the third-party system 808 to detect or identify balances, transactions, withdrawal, transfers, deposits, credits, debits, or other transaction types associated with the third-party system 808. The inter-network facilitation system 104 can further provide the aforementioned or other financial information associated with the third-party system 808 for display via the client device 806. In some cases, the inter-network facilitation system 104 links more than one third-party system 808, receiving account information for accounts associated with each respective third-party system 808 and performing operations or transactions between the different systems via authorized network connections.”; [0132] – “A third-party system 808 can communicate with the inter-network facilitation system 104 to provide financial information pertaining to balances […] a third-party system 808 communicates with the inter-network facilitation system 104 to update account balances, transaction histories, credit usage, and other internal information of the inter-network facilitation system 104” Inter-network facilitation system 104, comprising pre-emptive notification system 102, sends (e.g., a “request”) and receives (e.g., a “response”) communications to a third-party system, e.g. a third-party bank account, to obtain account information, e.g. balances, for the third party account. [0129] – “the inter-network facilitation system 104 may be capable of linking a variety of entities. […] interact with these entities through an application programming interfaces ("API")”. Further, inter-network facilitation system 104 may link entities, e.g. third party systems 808, and interact through an API, which would comprise API requests/responses.)
The combination of Purdy in view of Ruff fails to expressly teach wherein the resource allocation recommendation is generated further based on the current account value.
However, Klieman teaches determining a current account value for the different user account, wherein the resource allocation recommendation is generated further based on the current account value (Claim 1 – “the projected balance feature being used to predict future balances of one or more selected accounts associated with computing system implemented financial management system using historical financial data or recurring financial activities associated with the one or more selected accounts”; Col. 2, lines 22-29 – “A projected balance feature calculates and estimates a projected balance of a selected account, such as a checking or savings account, at any designated future date or time frame, such as a particular day, week or month. Typically the projected balance is calculated using historical data about the account such as: current balance in the account; recurring deposits to the account, such as a weekly, biweekly, or monthly paycheck”. Determining projected balances for one or more accounts requires determining the current account balance for each account. Col. 2, lines 49-54 – “the term "automatic payment", as used independently and/or as used in the phrases such as "automatic payment rules", applies to payments, transfers, deposits or any other form of transaction that involves the movement of funds within an account, between accounts, into an account, or from an account.” Col. 16, lines 1-19 – “the automatic payment rules created might include, but are not limited to: […] transferring funds to the selected account from another account based on data obtained from the projected balance feature regarding the projected income and anticipated deposits and/or outflow of funds to/from the selected account.”; Col. 21, lines 39-52 – “recommendation notification screen 340 includes recommendation text 341. In one embodiment, recommendation text informs the user of a recommended financial action/transaction based on the user's defined financial goal from DEFINE USER GOAL OPERATION 305 and the resulting automatic payment rules created at CREATE AUTOMATIC PAYMENT RULES BASED ON PROJECTED BALANCE CONSISTENT W ITH USER GOAL OPERATION 307, as well as, or in light of, projected balance data from the projected balance feature”. A recommended action/transaction, e.g. a transfer from an another account to a selected account “the different account”, based on the automatic payment rules, which are based on projected balance data of a selected account, is also implicitly based on the current account balance, since the projected balance data is based on the current account balance.).
Klieman is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of predicting and handling predicted liquid asset influxes in a user’s account. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Purdy in view of Ruff to incorporate the teachings of Klieman. The recommendations, such as transfers between accounts, of Klieman advise and assist the user in meeting their financial goals while allowing the user to maintain control over the process (Klieman: Col. 20, lines 55-59), and making recommendations based on a projected future balance (determined based at least on a current balance) of one or more accounts provides a user with new, powerful budgeting capabilities (Klieman: Col. 2, lines 35-48).
Regarding claim 24, the combination of Purdy in view of Ruff teaches the method of claim 21, but fails to teach the method further comprising generating, by the user evaluation circuitry, a forecast resource metric for the different user account based on the portion of the predicted liquid asset influx and a current account value of the different user account, wherein the resource allocation recommendation message further comprises the forecast resource metric.
However, Klieman teaches generating, by the user evaluation circuitry, a forecast resource metric for the different user account based on the portion of the predicted liquid asset influx and a current account value of the different user account (Col. 2, lines 22-29 – “A projected balance feature calculates and estimates a projected balance of a selected account, such as a checking or savings account, at any designated future date or time frame, such as a particular day, week or month. Typically the projected balance is calculated using historical data about the account such as: current balance in the account; recurring deposits to the account, such as a weekly, biweekly, or monthly paycheck”. “Recurring deposits” such as a paycheck is analogous to the “portion of the predicted liquid asset influx” as taught by Purdy in view of Ruff, where the predicted liquid asset influx is a direct deposit, e.g. a user’s income or paycheck. Col. 16, lines 1-19 – “the automatic payment rules created might include, but are not limited to: […] transferring funds to the selected account from another account based on data obtained from the projected balance feature regarding the projected income and anticipated deposits and/or outflow of funds to/from the selected account”), wherein the resource allocation recommendation message further comprises the forecast resource metric (Col. 21, lines 39-52 – “recommendation notification screen 340 includes recommendation text 341. In one embodiment, recommendation text informs the user of a recommended financial action/transaction based on the user's defined financial goal from DEFINE USER GOAL OPERATION 305 and the resulting automatic payment rules created at CREATE AUTOMATIC PAYMENT RULES BASED ON PROJECTED BALANCE CONSISTENT W ITH USER GOAL OPERATION 307, as well as, or in light of, projected balance data from the projected balance feature”).
Klieman is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of predicting and handling predicted liquid asset influxes in a user’s account. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Purdy in view of Ruff to incorporate the teachings of Klieman. The recommendations, such as transfers between accounts, of Klieman advise and assist the user in meeting their financial goals while allowing the user to maintain control over the process (Klieman: Col. 20, lines 55-59), and making recommendations based on a projected future balance of one or more accounts provides a user with new, powerful budgeting capabilities (Klieman: Col. 2, lines 35-48).
Response to Arguments
Applicant’s arguments with respect to claim 1 as being anticipated by Purdy have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Specifically, Claim 1 stands rejected as being unpatentable over Purdy in view of new reference, Ruff (U.S. Pub. No. 2015/0379488), wherein Ruff is relied upon to teach the argued claim limitations introduced in the amendment “receiving, by the communications hardware, user input authorizing a portion of the predicted liquid asset influx to be rerouted to a different user account; in response to receiving the user input, monitoring, by the user evaluation circuitry, for receipt of the predicted liquid asset influx in a user account of the user; and automatically rerouting, by the user evaluation circuitry, the portion of the predicted liquid asset influx from the user account to the different user account.”
Applicant’s arguments, see pages 11-15 of the Remarks, filed 3/12/2026, with respect to the rejections of claims 1-20 under 35 U.S.C. 101 have been fully considered and are persuasive. The rejections under 35 U.S.C. 101 have been withdrawn.
Specifically, at least the limitation “automatically rerouting, by the user evaluation circuitry, the portion of the predicted liquid asset influx from the user account to the different user account” as recited in independent claims 1, 10 and 19, is considered to be indicative of integration into a practical application when evaluating the claim at Step 2A, Prong One. The examiner would like to point to paragraphs [0011] and [0129] of the Specification which recites automatic reallocation/rerouting of portions of the predicted liquid asset influx to different accounts may improve the process of asset transfer by reducing overall processing requirements.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Czyewski et al. (U.S. Patent No. 10,402,897) teaches a method for redirecting a financial transaction from one account held be a customer to a second account held by a customer, including receiving a customer request for redirection, receiving transaction information, and performing the transaction with respect to the second account, where a financial transaction may be an incoming direct deposit (see Abstract and Col. 8, lines 15-20).
DUNJIC et al. (U.S. Pub. No. 2023/0067630) teaches a method for handling transfers comprising receiving a transfer message including a transfer quantity, identifying a main recipient account, detecting a trigger condition based on the transfer message, wherein the trigger condition causes the system to re-route a portion of the transfer quantity to a second recipient account, the re-routing being confirmed by the account holder through a notification (see Abstract, [0050], and [0075]).
MATHEW et al. (U.S. Pub. No. 2021/0103980) teaches identifying one or more projected future transfers for a first account based on a pattern of past transfers associated with the account, determining a forecasted balance by adjusting a current balance based on the projected future transfers, and providing a notification based on the forecasted balance to a client device associated with the account (see Abstract and [0042]).
Ghosh et al. (U.S. Pub. No. 2010/02747198) teaches a system which allows a customer to link multiple financial institution accounts and authorize a financial institution to automatically and intuitively manage the linked accounts, e.g. by managing the transfer of funds between accounts (see Abstract).
Amazon Web Services (NPL Document: “What is an API (Application Programming Interface)?”) teaches an API is a mechanism that enables two software components to communicate with each other through sending requests and responses (see Page 2).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JENNIFER MARIE GUTMAN whose telephone number is (703)756-1572. The examiner can normally be reached M-F: 8:00 am - 4:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kevin Young can be reached at 571-270-3180. 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.
/JENNIFER MARIE GUTMAN/Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights