We describe systems and methods for the management and allocation of funds deposited in savings and other similar financial or bank accounts. More particularly, we describe technical means that assist a user in establishing multiple personal saving goals for funds deposited to multiple savings accounts, including automatic allocation of deposited funds to the multiple goals based on user preferences for those goals automatically inferred from user interactions with the system.
The drawings depict certain preferred embodiments but are not to be understood as in themselves limiting the scope of that described herein. They are to be considered as an aid to understanding preferred embodiments as described in more detail below.
The embodiments we describe herein are of systems and methods which aid people in managing their personal finances. More specifically, the systems and methods allow a user to specify multiple savings goals for the funds in multiple accounts owned by the user and automatically allocate deposits of funds in those accounts to the multiple goals. The amounts to be automatically allocated to the various goals are based on the relative preferences of the user for those goals as automatically learned from the user's interaction with certain features of embodiments of the systems and methods.
System Overview
Using the access interfaces 230, the savings account data aggregation module 220 retrieves the data for the multiple savings accounts owned by the user from the databases 231 using the access interfaces 230 and stores this data in the allocation database 210 for subsequent processing. The allocation database 210 also serves as a repository for data about user interactions as measured and logged by the user control and display interface 201. Similarly, in some embodiments the allocation database 210 serves as a repository for aggregate data about user preferences and allocations computed by the aggregation and analysis module 240.
The allocation computation module 211 retrieves the raw account data from the allocation database 210 and data about user interactions via the user interface 201 to determine allocations of user deposit transactions in the data for the multiple accounts retrieved by the data aggregation module 220 and stored in the allocation database 210. We describe the methods for determining these allocations in various embodiments later.
The user controls and display module 200 provides the graphical or other means in various embodiments by which users interact via the user control and display interface 201 to provide access to the multiple savings account they own, to specify their savings goals, and to monitor and adjust the allocations made automatically to their goals. We describe some typical embodiments of the control and displays provided to the user subsequently.
Some embodiments may include an aggregation and analysis module 241 which compiles aggregate statistics, data mines for patterns, or derives statistical inferences about user preferences and allocations for a population or sub-population of users from the data in the allocation database 210. These analysis results are stored in the aggregated and derived data database 241 for subsequent retrieval by consuming clients via the aggregated data client interface 242.
Reference is now made to
The allocation engine server 170 may embody the savings account data aggregation module 220 and the allocation computation module 211 of
System webserver 160 and the network 150 may embody the user control and display interface 201 and the data communications channel between the allocation database 210 and the control and display interface 201.
Some embodiments may include an aggregated data consumer client-server 190 that may embody the aggregation and analysis module 240 and aggregated data client interface 241 of
Finally, in some embodiments the network connected client computer 110 and the network 150 may embody the user controls and display module 100, implemented as a web browser and web application, and the data communications channel between the user control and display interface 201 and the controls and display module 200.
In other embodiments, the user controls and display module 200 and the data communications channel between the user control and display interface 201 may be embodied by the network 150 and a mobile carrier network component that includes a mobile carrier network tower 140, a mobile connected client device 112, a web browser, and web application.
In yet other embodiments, the user controls and display module 200 and the data communications channel between the user control and display interface 201 may be embodied by the network 150 and a mobile carrier network component that includes a mobile carrier network tower 140, a mobile connected client device 112, and an application on the mobile device.
Finally, in yet other embodiments the network connected mobile client device 112 and the network 150 may embody the user controls and display module 200, implemented as a native application on the mobile device, and the data communications channel between the user control and display interface 201 and the controls and display module 200.
Having described the major components as embodied by the block diagram
User Controls and Displays
The present system and method is intended to allow customers to track progress while saving money for particular goals. These goals can be for a future purchase, or for paying off a small debt they have collected.
Goals may be embodied by data records in the allocation database 210 of
“Goal Category”
The user must specify a category for each goal to identify the type of goal. These categories should cover all popular goals that customers will save for, such as: “Rainy Day Savings,” “Vacation,” “Automobile,” “Electronics,” “Large Purchase,” “Home Improvement,” “Other,” and “Debt Reduction.” These categories are flexible and may be adjusted as needed to accommodate market changes or user circumstances.
“Goal Name”
The user may specify free-form text or keywords that further identify the goal.
“Goal Amount”
A key property of a goal the user defines to an embodiment is the dollar amount of the goal.
“End Date” (Date Focused Goal)
For some goals the user may choose to specify an “End Date” by when the goal must be reached. If the user specifies an “End Date” the system and method will determine a “Monthly Contribution Amount” according to the amount needed to reach the goal amount by the “End Date.”
“Monthly Contribution Amount” (Contribution-Focused Goal)
For other goals the user may choose to specify a desired “Monthly Contribution Amount.” If the user specifies a “Monthly Contribution Amount” the “End Date” will be set according to how long it will take to reach the “Goal Amount” based on the “Monthly Contribution Amount.”
Some embodiments of the system may require that the user specify either an “End Date” or a “Monthly Contribution Amount.” Other embodiments may not require the user to specify either, but instead specify a minimum default amount for any goal and a total minimum amount to be allocated to all current goals.
“Linked Account”
The user has the option to link the goal to a savings account if they want deposits automatically applied toward their goals. Multiple goals may be linked to a single savings account. Some embodiments may allow the user to specify a goal without linking it to a savings account and then to manually specify contributions towards the goal.
“Goal Priority”
The user may assign a categorical priority that indicates how important achieving the goal is to the user. Typical categorical priorities in an embodiment may be H(igh), M(edium), or L(ow). Other embodiments may allow the user to explicitly assign goals to a larger number of categories, or to completely rank-order goals.
“Amount Saved”
The system and method may track how much the user has saved for each goal. For goals linked to a savings account, the “Amount Saved” will be automatically updated based on new deposits to the savings account. For goals that are not linked to an account, the “Amount Saved” will be manually updated by the customer. In some embodiments, the user may manually modify the allocations that were made automatically by the system and method.
“Amount Remaining”
The system and method may track how much is left to save to reach the “Goal Amount” and the “Amount Saved.”
“Goal Status and Contributions”
The system and method tracks and reports to the user progress towards the goal. This may include a status indication whether the goal is in progress or completed. This may include a status indication for goals in progress whether the amount saved is on track with the projected plan. Some embodiments may retain data about completed goals and the historical record of contributions for further analysis and reporting about the individual savings behavior of individual users or the aggregated savings behavior of a group of users.
In an embodiment, the user's goals and the allocation of user contributions to those goals may be summarized in a display 300 such as that shown in
The user display 300 of a preferred embodiment includes a bar graph that displays the goal name and show how much has been saved to date. A target marker 323 may be displayed on each bar to show what how much should be saved towards the goal on the current date the user is viewing the display. The bar graph may display status towards the goal by showing the percentage saved and may use different colors such as green to indicate if the goal is on track 321 and orange to indicate if the goal is behind 322.
In some embodiments, when the user positions a pointing device on the graphical display 310 for the goal a pop-up window 325 with a textual summary of the information in the bar graph for a goal may be displayed such as: “Amount saved so far $222, i.e. 38% of your Goal, which leaves $278 left to save”.
Additional textual information about each goal may also be displayed in some embodiments. The textual information may include any combination of the total amount saved towards the goal 330, the amount of the goal 331, the end date of the goal 332, and the monthly contribution amount towards the goal 333.
Some embodiments may include an edit button 341 for each goal that switches some or all of the textual displays of the attributes for a single goal - - - e.g. saved 330, goal 331, end date 332, or monthly amount - - - to data editing displays 350. The user may use these data entry displays to quickly edit the values for a single goal stored in the allocation database 210.
An embodiment may also include a delete button 340 for each goal that allows the user to remove the information about the goal from the display 300. When a goal is removed from the display using this button, the user control and display interface 201 may cause the goal information to be permanently deleted from the allocation database 210 or simply marked as deleted in the database so it can be ignored as appropriate in any data processing actions by the user control and display interface 201, the allocation computation module 211, and the aggregation and analysis module 240. Removing a goal using this button may also initiate further data processing actions by those components of the system and method.
The display 300 in an embodiment may also include an “Add Savings Goal” button 360 that allows the user to interactively specify a new goal by entering information about the goal in the allocation database 210. In some embodiments, this button when activated may cause the user control and display module 200 to create a new goal on the display 300, in others it may cause presentation of another display 400 as shown in
Some embodiments may also include an “Edit Savings Goal” button 361 that allows the user to conveniently and interactively edit information about all of the user's goals in the allocation database 210. When activated, this button may cause the user control and display module 200 to present another display 500 as shown in
The user controls and display module 200 of
The user control and display module 200 in a preferred embodiment of the system and method includes a means such as the display 400 in
In addition, the display includes a button 431 to allow the user to accept the goal and communicate the goal attributes to the allocation database 210 via the user controls and display interface 201. It also includes a button 430 to allow the user to exit the goal specification process without entering the goal in the database.
Several of the controls in the display 400 may be such that the allowable values for the goal attribute is selected from a limited number of options specified by the user control and display module 200. For instance, the goal type 410 may be specified as being in one of four categories: “Vacation,” “Automobile,” “Rainy Day Savings,” or “Debt Reduction.” The linked account 411 may be limited to the categories of “Savings” or “Unlinked.” The goal priority 413 may be specified as “High,” “Medium,” or “Low.” The linked account menu 411 may additionally allow the user to add a new linked account, rather than merely displaying previously linked accounts, to the system and method. In an embodiment, the linked account menu 411 may include an option “New Account” below “Savings” or “Unlinked” by, e.g., providing a separate screen or an expanded screen of the current display in which the user can enter data specific to the new account, e.g., account number, access code, account holder's name, account's nickname, and the like. The system and method have access to data from the linked accounts, e.g., account balances, but does not necessarily have access to the funds themselves. In another embodiment, the system and method may not only access data about the linked accounts but also be able to transfer funds from one account to another or from one account to an account it newly creates.
Other controls may be data entry fields for free-form numeric or text strings. This might include controls that permit the user to specify the goal amount 412, the user's name for the goal 414, the initial allocation to the goal 415, and the end date for the goal 420. These controls may include format validation to insure that the free-form numeric or text strings entered by the user represent the type of information required by the control. In addition, some may also include a companion alternative control that simplifies entry of the required information. For example, the initial allocation data entry field 415 may have a companion slider control 416. The end date data entry field 420 may have a companion data selector control 422 with an associated pop-up menu 418 that enumerates the possible selections.
For some of the user controls, the user controls and display module 200 may enforce extrinsic or intrinsic constraints on the information values entered by the user. For example, the initial allocation control 415 may limit the amount a user can allocate to the maximum amount not already allocated to other goals 417 linked to the same account as the goal 411. Similarly, if the user specifies an end date for the goal using the end date control 420, the module will supply a value for the monthly allocation 421 given the goal amount 412 and the initial allocation 415. If the user specifies a monthly allocation 421, the module supplies an end date 420.
The user may then use the account selector 411 to specify whether the goal is linked to an account. In some embodiments, the display 400 may also include a data entry that allows the user to specify identifying information for an account. If the goal is linked to an account, the user may also use the initial allocation control 415 to specify an initial allocation to the account, limited to the maximum unallocated amount in the account 417.
Next the user may specify the amount of the goal using the goal amount data entry control 412. Having specified the goal amount, the user may then use the end date control 420 or the monthly allocation data entry field 421 to specify the corresponding information. The user controls and display module 200 may then supply the complementary value for the unspecified attribute of the goal. The user may then use the goal priority selector 413 to categorize the priority of the goal.
Finally the user may either use the accept button 431 to cause the goal information to be entered in the Allocation Data database 110, or to cause the user controls and display module 200 to terminate the process of adding a goal without entering any goal information in the allocation database 210.
The user control and display module 200 in a preferred embodiment of the system and method may also include a means such as the display 500 in
For each goal, the display includes selectors and data entry fields that allow the user to edit some of the attributes of each goal in the allocation database 210. These may include the amount of the goal 530, the end date of the goal 531, the monthly allocation to the goal 532, the categorical priority for the user of the goal 534. In some embodiments, certain of the goal attributes originally specified by the user may not be modifiable. These may include the category and name of the goal or the savings account, if any, from which automatic allocations of deposits will be made to the goal.
The display 500 may also include a data entry field for the amount saved 533 that is initialized with the amount currently allocated to the goal at the time the display is activated by the user in response to the button 361 of the display 300 in
Finally, the display 500 may include a button 540 for each goal that allows the user to delete the goal. In some embodiments, this display may also include a control that allows the user to explicitly specify the goal has been completed and the funds for the goal have been withdrawn from the account.
In addition, the display includes a button 551 to allow the user to accept the changes made to all goals and communicate the edited goal attributes to the allocation database 210 via the User Controls and Display Interface 101. It also includes a button 550 to allow the user to exit the goal editing process without entering any modifications to the goal attributes in the database.
Next the user may use the amount saved control 533 to adjust the amount allocated to the goal. Any adjustment is ultimately reflected in the goal amount for the goal in the allocation database 210 and the display of the amount still available 560 in the savings account linked to that goal.
Finally, the user may adjust the priority of the goal with the goal priority selector 534.
If the goal is completed, the goal information in the allocation database 210 may supplemented to indicate this. The goal information with that indication may be retained in the database for subsequent retrieval and display to the user by the user controls and display module 200, or for further analysis by the aggregation and analysis module 240. The goal information for uncompleted goals may be deleted from the database.
Finally, any allocation to the goal as would be shown in displays 330 and 530 would be added back into the amount available 560 displayed for the account.
In some embodiments, the User Control and Display Module may include controls that allow the user to specify an alert indication should be activated when a one or more user-specifiable percentages of the goal has been reached. Once the goal reaches one of the specified percentage thresholds, an alert may be indicated for the goal 310 in the display 300. Some embodiments may also include means for providing external alerts to the user such as sending an email, or a post to the user's account on a social media platform.
In yet other embodiments, the user controls and display module 200 just described may be a component of another computer system which programmatically supplies and receives goal information from the user control and display interface 201.
Auto-Allocation of Deposits
Having just described the user displays and controls, we next describe a preferred embodiment of the system automatically allocating deposits to the goals.
To determine the amount of “Available” funds in each account for allocation, an embodiment of the system and method may store the “Amount Saved” for each goal, the “Reserve Cash” for each account, and the “Current Balance” of the account. The amount “Available” then is the difference between the “Current Balance” and the total of the “Reserve Cash” and the “Amount Saved” for all goals linked to the account. The “Available” funds may be positive, indicating the account has a surplus of funds that must be allocated to the linked goals. It may also be negative, indicating the account has a deficit of funds must be de-allocated from the linked goals.
A flowchart for one example of the process 1000 in the flowchart
If there is a surplus of funds that must be allocated, but all goals are met, the iteration ends. If some goals are unmet, then a “Preliminary Allocation” PA of those funds 1120 to those unmet goals is computed based in part on the user's relative preferences for the goals linked to the account inferred from the user's interaction with the embodiment of the system and method. The preliminary allocation may then be automatically adjusted according to additional rules 1121. One such rule might be an absolute ad hoc limit on the amount that may be allocated to a single goal. The total amount of the adjusted allocation to all of the goals is then subtracted from the surplus of “Available” funds.
Conversely, if there is a deficit of funds that must be deallocated, but all of the goals are unmet and no funds have been allocated to any of the goals, the iteration ends. If some goals are unmet, then a “Preliminary (De-)Allocation” PA of those funds 1110 from those unmet goals is computed based in part on the user's relative preferences for the goals linked to the account inferred from the user's interaction with the embodiment of the system and method. The preliminary de-allocation may then be automatically adjusted according to additional rules 1111. One such rule might be an absolute ad hoc limit on the amount that may be de-allocated from a single goal. The total amount of the adjusted de-allocation from all of the goals is then subtracted from the surplus of “Available” funds. Here we indicate a de-allocation as a negative amount so that subtracting the de-allocation amounts to adding the total amount of the absolute value of the de-allocated funds back to the amount of “Available” funds.
After the surplus or deficit funds have been allocated or de-allocated, respectively, an embodiment of the system and method may provide the user with the means and opportunity to adjust the goals that have been met. These adjustments may include changing the “Goal Amount” 331 in the display 300 of
Next, an embodiment may provide the user with the means and opportunity to effectively release completed goals as unmet for purposes of the allocation process. In some points in the allocation process, such as when de-allocating a deficit of funds, completed goals may be treated differently from unmet goals or met goals. For instance, surplus funds may not be allocated to a completed goal or deficit funds may not be de-allocated from a completed goal. By releasing completed goals as unmet goals, the user may in effect allow the allocation process to allocate additional surplus funds to a completed goal or de-allocate deficit funds from a completed goal.
Finally, after all user adjustments have been made to the allocations determined, the process iterates starting with the user optionally unlinking any completed goals from the account such as by activating the button 340 in the display screen 300 in
Upon completion of the iterative allocation process some embodiments may also explicitly determine the user has met interim subgoals of a goal or completed a goal. If it is determined a subgoal has been met or a goal completed, the user may be offered incentives to induce the user to continue to attempt to achieve the goals the user has specified. Incentives may include, but are not limited to, visible indicators in the display 300 of
Detailed Automatic Allocation Computation
GoalAmounti (GAi): “Goal Amount”
GoalPriorityi (GPi): “Goal Priority”
StartDatei (SDi): Date savings toward goal starts
StartAmounti (SAi): Initial amount towards goal.
MonthlyContributionAmounti (MCAi): “Monthly Contribution Amount”
EndDatei (EDi): “End Date” This is the target date if the goal is date focused, it is an approximation based on the “Monthly Contribution Amount” if the goal is contribution focused.
AmountSavedi (ASi): Current total amount that has been allocated towards goal i.
ContributionDatesi (CDi), ContributionAmountsi (CAi), AllocationModei (MDi): Time sequence of “Last Contribution Date” and “Last Contribution Amount” attribute values, and mode (batch/corrected/user) since saving towards goal started.
We also assume we have a set G={G1, G2, . . . , Gn} of active goals, with the parameters described for each goal Gi and an available amount Available, or just A.
The computation results in a preliminary allocation PA={PA1, PA2, . . . , PAn} based on the allocation histories (CD1, CA1, MD1=user), . . . , (CDn, CAn, MDn=user) such that
A=Σ
i, G
GPAi
There are several problems to consider for allocating funds: The goals have different start dates and therefore we have varying amount of information from which we can infer preferences. In addition, some of the allocations in the history may have been made relative to goals that have been completed and therefore are no longer in G. Finally, one or more goals may be new and so we have no allocation history for them.
To help us sort out the preference inference problem, we first assume the goal priority attributes GPi for the goals in G are authoritative. We then consider two possible options as the endpoints of a sequence of possibilities:
Minimum Inferences from Available History Data
For this approach, we have two additional exogenous parameters, a minimum allocation MA per goal and a total minimum allocation TMA for all goals.
First, we might simply compute a preference profile PP={PP1, . . . , PPn} which only looks at goals for which the allocation history exists, over the time interval in which allocations have been made to all of those goals. Let the goals for which the allocation history exists be G>0={Gj|CAj not nil}, let CD>0 be the earliest date such that an allocation has been made to every GjεG>0, and let Gc>0=G−G>0. To get a ranking of these goals, we compute the fractions
p
j=(Σk, CD
where the summation over the k index on the histories CDj, CAj, and MDj should be understood to indicate these quantities are actually lists of values.
If we then let p=minjpj, in one embodiment we can define a consistent preference profile as
This profile assigns a fraction of an allocation consistent with the p, for any goals which we have MDi=user allocations and a minimum fraction of the allocation to any goals for which we have no information from the user to infer a preference.
Next, we establish a minimum allocation profile MA={MA1, . . . , MAn}. Of course, we have to limit n·MA≦TMA≦A. In one embodiment, we might establish a minimum linear allocation profile as:
MAi=MA+(i−1)[TMA−n·MA]/n
Other embodiments may use other minimum allocation profiles.
There is one detail we have to take care of in the minimum allocation profile. In some embodiments the computation may depend on a complete ordering of the goals and we may only have the categorization attributes GPi and the preference profile PP just described. Using this information, the goals G may be ordered and the minimum allocation profile MA adjusted in three steps. First, partition the goals G into three subsets of goals GLow, GMedium, and GHigh and order the goals in GLow before the goals in GMedium, and the goals in GMedium before the goals in GHigh. Using the preference profile PP, we can order the goals in each of these subsets.
First the goals are ordered according to the three subsets defined by the goal priority attributes GPi.
Next, in each subset the goals GiεGc>0 are ordered before the goals GiεG>0.
Finally, using GHigh as an example, the goals GiεG>0 ∩GHigh are partitioned into subsets GHigh,l, . . . , GHigh,k of goals that have the same value of PPi and ordered according to those subsets. For those subsets GHigh,k that include more than one goal Gi, the minimum allocation profile can be adjusted so that each goal within GHigh,k has the same minimum allocation
MAi′=Σi, G
Some embodiments may also consider the MonthlyContributionAmounti (MCAi) the user has specified or derive a minimum monthly contribution amount from a user-specified EndDatei (EDi). Let GMCA and GED be the goals for which the user has specified a monthly contribution amount MCAi or an end date EDi, respectively, and for which the monthly contribution has not yet been made for that month and perhaps previous months. In some embodiments, the preliminary allocation may be distributed across the specified monthly contributions for all of the goals in GMCA∪GED. These funds might be re-distributed by the user and those redistributions would subsequently show up in the preference profile PP. In those embodiments if the monthly contribution for previous months has not been for one goal, then in effect no goals are up-to-date and there is no need to distinguish between goals that are months behind and those that aren't in this step of the preliminary allocation.
Let ASTi (AmountSavedTargeti) be the amount that should be saved by the end of the current month to meet the user's goals and let the total monthly contribution “in arrears” for the goals in GMCA and GED, respectively, be
TMCA=Σi, G
TMAMCA=Σi, G
We also let the preference masses in each of the different groups of goals be:
PPMCA=Σi, G
The preliminary allocation PA={PA1, PA2, . . . PAn} of the AmountAvailable A must be derived in three possible cases:
Case 1: A≦(TMA−TMAED)+TED
In this case, the available funds A are sufficient to meet the minimum monthly allocation MA, but are not sufficient to meet the required monthly allocations for goals GED with specified end dates EDi. Any excess funds above the minimum allocation MA are distributed to the required monthly allocations for goals Gi with specified end dates GED as
Case 2: (TMA−TMAED)+TED<A≦(TMA−TMAED−TMAMCA)+TED+TMCA
In this case, the available funds A are sufficient to meet the minimum monthly allocation MA and the required monthly allocations for goals GED with specified end dates EDi, but are not sufficient to meet those goals GMCA with specified monthly contributions MCAi. Any excess funds above the minimum allocation MA and the required monthly allocations for goals Gi with specified end dates GED are distributed to the required monthly allocations for goals Gi with specified monthly allocations GMCA as
Case 3: (TMA−TMAED−TMAMCA)+TED+TMCA<A
In this case, the available funds A are sufficient to meet the minimum monthly allocation MA and the required monthly allocations both for goals GED with specified end dates EDi and goals GMCA with specified monthly contributions MCAi. Let TA=A−(TMA−TMAED−TMAMCA)+TED+TMCA. Any excess funds above these three categories of allocations are distributed to all goals as
This preliminary allocation does not allocate more than A, but it must be massaged according to rules dealing with how close a goal is to being accomplished, missed monthly goals, over-allocations, etc. Note also this algorithm would work for de-allocation, although all of the quantities must be interpreted appropriately.
Minimum Inferences from Available History Data
In the previous embodiments, a preliminary allocation PA is derived across the goals in G with minimum inferences on the available history data. In particular, the preference profile PP is derived by only looking at the period in time in which the user had explicitly ranked the goals in G>0 by making allocations to them.
Other embodiments may use the available history data CDi, CAi, MDi=user differently to make a preliminary allocation PA. Let CDS denote a date sometime before the current date that defines the start of a time window and let CDj,>0≧CDS represent the earliest date in the window which the user started make a contributions to goal Gj. If the user started to contribute to goal Gj before CDS, then CDj,>0=CDS. G>0 is now understood to represent the goals for which the user has made any contribution. The probabilities forming the basis for the preference profile then computed as
p
j=(Σk, CD
The preliminary allocation PA is then made as before. When the preference profile is built in this way, it in effect incorporates an additional inference about the user's relative preferences for the goals based on how long the user has been saving for each goal.
Yet other embodiments may incorporate a different set of inferences about a user's preferences by normalizing the contributions a user has made to each goal relative to the time they have been saving for each goal. Let TD represent today's date and, as a notational convenience, let ∥TD−CDS∥ denote the length of the window in days and ∥TD−CDj,>0∥ denote the length of time the user has been saving for goal Gj. In these embodiments the probabilities forming the basis for the preference profile then computed as
p
j=[(∥TD−CDS∥/∥TD−CDj,>0∥)·Σk, CD
When the preference profile is built in this way, it de-emphasizes the effect of how long the user has been saving for a goal. It still attempts, however, to give influence to the total amount a user has actually contributed to each goal by assuming the user would have contributed the same amount in the past to more recent goals as they actually contributed to those goals.
The preceding description discloses the preferred embodiments of the inventive system and method. Without further elaboration, it is believed that one skilled in the art can use the preceding description to utilize the system and method to its fullest extent. Therefore the examples and embodiments disclosed herein are to be construed as merely illustrative and not a limitation of the scope of the system and method in any way.
It will be obvious to those having skill in the art that many changes may be made to the details of the above-described embodiments without departing from the underlying principles of the system and method. Therefore, it is to be understood that the system or method should not be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims.
The scope of the present system and method, therefore, should be determined only by the following claims.
This non-provisional application claims priority to U.S. provisional application Ser. No. 61/381,044, filed Sep. 8, 2010, which we incorporate herein by reference.
Number | Date | Country | |
---|---|---|---|
61381044 | Sep 2010 | US |