WO2011123924A1 - A personal financial planning system and method with a novel undo system and method - Google Patents

Abstract

A system for personal financial planning for a user along a specified timeline comprising: a data storage device; data processing means, a control component that generates a first lifeline for the user along the specified timeline; a sub- control component that generates a representation of a financial factor and financial information, wherein each representation of the financial factor is part of a lifeline, a display device for displaying at least one the financial factor along the specified timeline from a start position to an end position determined by the sub-control component based on corresponding financial information in the financial factor. The present invention further contemplates an undo or a reverse change system and method that is utilized with the personal financial planning system and method. The undo or reverse change system is a powerful, generic and reusable system that may be utilized in other computer programs.

Description

A PERSONAL FINANCIAL PLANNING SYSTEM AND METHOD

WITH A NOVEL UNDO SYSTEM AND METHOD

FIELD OF THE INVENTION

The present invention relates to personal financial planning systems and methods. The present invention also relates to undo systems and methods for computer programs.

BACKGROUND OF THE INVENTION

By way of background, people usually seek out

professional financial advice to help solve a current need. Common reasons are: (1) retirement planning, (2) major life changes, such as a new baby, marriage or divorce, (3)

education savings planning for a child, or (4) a major financial goal, such as buying a first home, car or cottage. All of these common reasons can be a part of the larger picture of long-term financial planning.

Many financial advisors can assist a client with some of the common reasons and then work to build a more comprehensive long-term financial plan. For example, some financial advisors will not assist a client with retirement planning until they have first helped the client with basic risk mitigation strategies, such as life and disability insurance.

Unfortunately, there is no known computerized tool for financial advisors that can help them readily and easily answer the most simple and the most common questions.

Advisors need a tool to help a client understand their current and future financial positions. Yet, there is no

comprehensive financial planning tool available on the market that can help advisors accomplish this.

Instead, many financial advisors are using index

collections of pre-printed graphs, collections of MS Excel ™ spreadsheets, and poor quality disparate web-based tools. For example, one advisor has commented that, when a client asked if he should use a small inheritance to maximize his registered retirement savings contribution room or purchase a rental property, the advisor had to build a custom Excel spreadsheet to answer the question. This approach is time- consuming and error-prone.

One product being used is NaviPlan™ developed by Emerging Information Systems Inc. NaviPlan™ Standard allows advisor^s to specify retirement, education and major purchase goals' and determines if existing strategies can meet those goals. The program is designed for wealth-accumulating and affluent clients. The program uses a province-specific tax rate calculations, highlights the advantages and disadvantages of different planning strategies, produces reports and

presentations, and can be upgraded to NaviPlan Extended for detailed cash-flow-based analysis. The program models income, expenses, assets and liabilities, goals, insurance coverage and different asset allocations, and includes a "Planning Assistant" to analyze plans and recommend actions.

NaviPlan™ Extended is designed for more complex

scenarios, allows cash-flow-based planning analysis and offers some support for small business planning and incorporated entities. Although the program allows advisors to include small business assets, holding companies and trusts, the assets are not uniquely identified or treated separately in the application. Along with the Standard program functions, the Extended version also models stock options, gifting strategies and estate planning options. In addition, a "what- if" analysis tool lets advisors create multiple scenarios and compare the results side by side.

Unfortunately, NaviPlan™ and other prior art tools remain very difficult and cumbersome to use. They do not help the advisor understand their client's complete financial picture, or even address how such tools might integrate with a financial plan to help the client achieve their desired lifestyle and life's goals. In addition, these prior art tools have not developed a user-friendly graphical user interface .

As an example of the difficulties faced by financial advisors regarding planning software, while NaviPlan™ is currently the top software in this space, almost every advisor interviewed by the inventor dismissed NaviPlan as being too complex and unusable. A single financial advisor was found who uses NaviPlan and this advisor organized his affairs such that NaviPlan was shared with six other advisors and, between them, they hired a shared, full-time NaviPlan support employee that rotated between their offices 1 day a week. This, clearly, is both inefficient and expensive. However, it powerfully demonstrates the difficulty and complexity of current

software .

As can be seen, many financial advisors are wasting time and money, and sometimes losing clients, because they do not have a user-f iendly comprehensive financial planning

computerized system.

There is also a need in the prior art for an

undo/reversible change system and method for computer

programs. In the prior art, undo systems (which can reverse changes previously implemented) function at the user-interface level of the software. User actions are recorded by the software as the user does them, and a hard-coded "undo" is written by the developer to allow the user to undo that action or reverse any changes made. This prevents the system from performing an undo on an arbitrary action performed an arbitrary number of steps ago because each undo action is recorded relative to the previous state of the system. For each action the user performs, a software developer must code both the action and the corresponding undo action, which increases both the development and testing effort - and therefore the cost - of developing an undo system.

Additionally, the entire undo system is only applicable for that specific user interface - if a new user interface is created, a new undo system will need to be created. For example, if the original application was a desktop application the undo would only work with the desktop application; if the application was also made available as a web application a completely new undo system would need to be created.

Based on the aforementioned shortcomings of the prior art, there is therefore a need for a systems and methods for personal financial planning that is computerized and

comprehensive. In addition, when creating financial plans and building other plans, there is a need to be able to undo actions taken prior to the last action taken.

SUMMARY OF INVENTION

The present invention provides systems and methods for personal computerized financial planning through a user interface.

The present invention also provides an undo system and method for computer programs.

In a first aspect, the present invention provides a system for personal financial planning for a user along a specified timeline comprising: a data storage device for storing data associated with a user; data processing means, operatively coupled to a data storage device, and configured with: a control component that generates a first lifeline for the user along the specified timeline; at least one sub- control component, wherein each sub-control component

generates a representation of at least one financial factor and financial information corresponding to the at least one financial factor, wherein each representation of at least one financial factor is part of the first lifeline, a display device, operatively coupled to the processor, for displaying at least one the financial factor along the specified timeline from a start position to an end position, wherein the start position and the end position are determined by the sub- control component based on corresponding financial information in the financial factor.

In a second aspect, the present invention provides a computer readable media having encoded thereon a method for creating a visual representation of at least one financial factor in personal financial planning for an individual along a specified timeline, the method comprising: (a) selecting the at least one financial factor, and providing financial information corresponding to the at least one financial factor; (b) determining a start position and an end position for the financial factor along the specified timeline, based on financial information corresponding to the financial factor; (c) repeating steps (a) and (b) for each of the at least one financial factor; and(d) displaying a representation of each financial factor along the specified timeline to form a lifeline for the individual.

In a third aspect, the present invention provides a method for tracking changes in values in a computer program such that the changes may be reversed, the method comprising: (a) for each top level object in the program : (al) creating a top level change monitor object; (a2) determining child objects created for the top-level object; (a3) for each child object, creating a change monitor object to monitor changes relating to the child object; (a3-l) determining subsidiary child objects created for the child object; (a3-2) for each subsidiary child object determined in step (a3-l) ; creating a corresponding change monitor object to monitor changes relating to the subsidiary child object; (a4) recursively executing steps (a3-l) to (a3-2) for each subsidiary child object and for each child object such that each child object and each subsidiary child object has a corresponding change monitor object; (b) registering each change monitor object with the top level change monitor object; (c) registering each change monitor object with a parent monitor object; and (d) for each change relating to a child object or subsidiary child object detected by a relevant change monitor, creating an undo object and listing the undo object with a master list

administered by the top level change monitor; wherein each undo object, when activated by a user, reverses a change which caused a creation of the undo object.

BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments of the present invention will now be described by reference to the following figures, in which identical reference numerals in different figures indicate identical elements and in which:

FIGURE 1 is a block diagram illustrating a hardware computer system on which the invention may be implemented;

FIGURE 2 is a graphical representation of a lifeline in accordance with an embodiment of the present invention;

Figure 3 is a user profile interface in accordance with an embodiment of the present invention;

Figure 4 is a flowchart representation of a process for arranging financial factors along a specified timeline in accordance with an embodiment of the present invention;

Figure 5 is a first graphical representation of a graph overlaid on a lifeline in accordance with another embodiment of the present invention; Figure 6 is a second graphical representation of a graph overlaid on a lifeline in accordance with another embodiment of the present invention;

Figure 7 is a third graphical representation of a graph overlaid on a lifeline in accordance with another embodiment of the present invention;

Figure 8 is a fourth graphical representation of a graph overlaid on a lifeline in accordance with another embodiment of the present invention;

Figure 9 is a fifth graphical representation of a graph overlaid on a lifeline in accordance with another embodiment of the present invention;

Figure 10 is a graphical representation of a lifeline showing a series of bar graphs adjacent to the lifeline in accordance with another embodiment of the present invention;

Figure 11 is a graphical representation of an expanded bar graph shown in Figure 10;

Figure 12 is a graphical representation of a first lifeline in accordance with another embodiment of the present invention;

Figure 13 is a graphical representation of the first lifeline shown in Figure 12 and of a second lifeline is identical to the first lifeline in accordance with another embodiment of the present invention;

Figure 14 is a user interface for a financial factor in accordance with another embodiment of the present invention ;

Figure 15 is a representation of graphical icons in accordance with another embodiment of the present invention;

Figure 16 is a representation of graphical icons for a user's family in accordance with another embodiment of the present invention; Figure 17 is a graphical representation of an

individual's lifeline with a baby as a financial factor in accordance with another embodiment of the present invention;

Figure 18 is a representation of a list of reversible changes or undo objects which, if activated by the user, reverses specific changes which have been previously entered;

Figure 19 is a representation of domain objects and change monitor objects in accordance with a further embodiment of the present invention; and

Figure 20 is a representation of items and their relationships in the reversible change system in accordance with a further embodiment of the present invention .

DETAILED DESCRIPTION OF THE INVENTION

The present invention provides an information processing apparatus and method, a program, and a recording medium and, more particularly, to an information processing apparatus and method, a program, and a recording medium that are adapted to enable the legal distribution of works derived from

copyrighted sources.

Referring to Figure 1, a block diagram of a system 10 on which the invention may be practiced is illustrated. A computer system 10 having a processor 20, memory 30, storage 40, and a display device 50 is illustrated. The processor 20 retrieves data for the above invention from storage 40 and, by using memory 30, executes the steps of one aspect of the invention. The processor 20 then displays the processed data through the display device 50. It should be noted that the processor 20 may be

operatively coupled to the storage 40, and thus the processor 20 may store to and retrieve data from the storage 40.

The document will refer to data processing means which can include a processor and memory, and may also include any other sub-systems which may be part of a computer or a data server .

The display device 50 provides a user interface, such as a graphical user interface (GUI) whereby graphical icons and visual indicators are offered, as opposed to text-based interfaces, typed command labels or text navigation, to fully represent the information or actions available to a user.

Through the GUI, user actions may be performed through direct manipulation of the graphical elements.

In an alternative embodiment, the processor may be operatively coupled to a remote server 70 through a wireless or wired connection, via the Internet or some other networked interface. All or part of the present invention may be hosted at and performed by the remote server 70.

According to one embodiment, the present invention provides a computerized system that produces a visual or graphical representation of a user's financial life. In this document, a user's financial life will be represented by what is termed a "lifeline". The lifeline is a representation of the user's financial information over a specified period of time .

For the purposes of this document, a timeline is defined as a graphical representation of a chronological sequence. That chronological sequence may begin at a future date and end at a past date, or conversely, begin at some past or current date and end at a future date. A lifeline can therefore be termed as a representation of user's financial information over a specified timeline. It should also be mentioned at the outset that a

financial advisor, or other user, may use the system on behalf someone else, such as a client. In that case, the lifeline represents the financial information of the client, rather than that of the user. For the purposes of this document, we will assume that the client is the user.

In Figure 2, a graphical representation 100 of a lifeline is shown. The lifeline representation 100 includes a timeline that begins at the year 2010 and continues past the year 2016. In this example, the user has a number of associated financial factors: personal expenses, entertainment expenses, spend spare income, full-time employment, vacation in Vancouver, fixed-rate mortgage, housing costs, vacation in Cuba, cash received (¥10,000 yen), short-term disability, dependent expenses for a child, vacation in P.E.I. , and cancer.

According to one embodiment of the present invention, these financial factors are represented as graphical icons on the lifeline. Other financial factors may be selected from a toolbar and dragged-and-dropped onto the lifeline. The financial factors can comprise at least one of, but not limited to, factors relating to income (from employment, business, or other) , expenses (entertainment or other) , assets, liabilities, investments, calamities, various types of insurance, taxes, vacations, children, etc.

Accordingly, based on the financial factors selected, the system can determine in real-time how the addition or removal of a financial factor, or a change made to a financial factor, in the lifeline affects the user's cash flow, income,

expenses, taxes, assets or liabilities at any given point in the timeline.

To begin, the user may input personal information into a user profile interface 200 as shown in Figure 3. A user will input personal information, such as his or her name, birth date, contact information, target retirement age, and equity needed to retire. Here, the user profile 200 is a graphical user interface; however, a text-based user interface may also be implemented.

It should be mentioned that personal information is not necessarily required. A lifeline may be created without entering any personal information.

Referring back to Figure 2, a lifeline is generated by a control component and each financial factor is generated by an associated sub-control component. The control component interacts with each sub-control component to display each financial factor along a specified timeline such that each financial factor is graphically displayed and forms part of the user's lifeline.

Each financial factor, such as full-time employment or a mortgage, is generated by a specialized sub-control component. Each sub-control component has its own timeline to allow each financial factor to display child factors (such as a pay-raise or a pay cut in the case of employment) in a separate timeline that aligns with user's lifeline. Referring ahead to Figure 17, an example of a child factor could be the different types of expenses for a baby changing over time. In Figure 17, the ball represents toddler expenses, the cell phone represented teenager expenses, the little hat represents university expenses, and the door with an arrow represents the child attaining financial independence. Further along the timeline, the ring represents wedding costs incurred by the parents.

For clarity, child factors change the financial factor at, or starting from, the point in time along the timeline that they are created. For example, for a full-time

employment financial factor a pay-raise is a child factor that changes the income received from that point on, but a bonus is a child factor that would change the financial factor at a given point in time. In accordance with the embodiment shown in Figure 2, all financial factors are displayed horizontally according to their start and end date, or according to a "centre-on" date. Sub-control components, for each financial factor, expose these values to the control component. The control component utilizes the dates to determine a position on the lifeline. For clarity purposes, this position is referred to as an x- position .

The control component defines the resolution width. The control component lays out the sub-controls according to its resolution width and the start and end dates of the sub- control. In the example shown in Figure 2, the resolution width is the time between each major vertical line, which is 1 year in this example. While the example in Figure 2 uses a resolution width of one year, the resolution width may be any increment of time, for example, weeks, months, or decades.

According to one embodiment of the present invention, the following process may be followed to convert a date into an x- position value:

1. First, the process determines the number of days between the start-date of the timeline, which is the left-most graphically visible date, and the date-to-convert, which is the start date for the financial factor. In Figure 2, the start-date would be a date close to the beginning of the year 2010. In this example, the date-to-convert would be January 1, 2010 for personal expenses as this is the starting date for this financial factor. The x-position is then expressed as the number of days between the start date of the timeline and the date-to-convert.

2. Next, the x-position expressed as a number of days, is divided by the number of days in each resolution. For example, if the resolution is 10 years then there would be 3650 days in each resolution; 1825 days, if the resolution is 5 years; or 365, if the resolution is 1 year, and so on and so forth. This gives the x-position as a fractional number of the control's resolution. In other words, the x-axis is divided into however many days there are in the given

timeline .

3. The process then multiplies the fractional number of timeline resolutions by the width in screen pixels of one resolution to arrive at a concrete x value in pixels. The above process enables the user to change the resolution width, and therefore, provide a sort of "zoom" or "squish" feature for increasing or decreasing the resolution width

respectively .

According to one embodiment of the present invention, the following are different ways that the timeline control component and sub-control components can be configured to order financial factors vertically.

1. Explicitly: Each sub-control component must generate an explicit vertical Y-position value for its financial factor, such that the timeline control component enables it regardless of whether it causes the financial factor of one sub-control component to overlap with that of another sub- control component (s) .

2. Top: The timeline control component will arrange financial factors for all sub-control components at the top of the timeline at any specified height.

3. Center: The timeline control component will arrange all financial factors for all sub-control components in the middle of the timeline at any specified height.

4. Bottom: The timeline control component will arrange all financial factors for all sub-control components at the bottom of the timeline.

5. Stretch: The timeline control component will stretch all financial factors for all sub-control components from the top to the bottom of the timeline. 6. Automatic stack: Starting from the top of the timeline, each financial factor is stacked vertically when it collides with another item.

The automatic stacking process will now be explained in more detail. The process associates meta-data with every sub- control component, which is used to help maintain extra information about the sub-control component such as its related sub-control components and its total height including all sub-control components.

It should also be noted that x-positions and y-positions are interchangeable. In other words, financial factors may be stacked horizontally along a vertical timeline, rather than stacked vertically along a horizontal timeline as shown in Figure 2.

According to an embodiment of the present invention,

Figure 4 is a flowchart representation of a process 400 for arranging financial factors along a specified timeline, for financial factors that have an associated duration of time (as compare to an event, which occurs at a given point in time) . The process enables a specified financial factor to have related-below financial factors (which are displayed

immediately below that specified financial factor) , and related-after financial factors (which are displayed

immediately after the specified financial factor at the same vertical position) . [For example, referring ahead to Figure 10, the lifeline representation shows mortgage, followed by a related-after mortgage-free house sub-control component and with a related-below housing-costs sub-control component.

It should also be noted at the outset that we have defined an x-position of a financial factor as the leftmost position along the timeline, and a financial factor's end position as its rightmost position along the timeline.

However, the x-position could the rightmost position along the timeline, and a financial factor's end position as it leftmost position along the timeline.

The process includes the following steps:

Step 410: The process begins here and determines the desired width and height for each financial factor

representation. This information may be previously

determined.

Step 420: This process step determines the total height for all related financial factors based on relationships between financial factors, i.e., for the related-below financial factors. This ensures that during the vertical layout process there is room for the financial factor and its related-below factors.

Step 430: This process step determines the horizontal x- position of each financial factor. Specifically, the step calculates the horizontal x-position of each financial factor based on the item's start date and end date, or based on the item's centre-at date and the sub-controls desired width.

Step 440: The process sorts all of the financial factors by increasing x-position.

Step 450: Next, the process creates an initially empty linked-list for each financial factor that will store all sub- control components that have been assigned a vertical y- position. Specifically, the linked-list may be referred to as V.

Step 460: Finally, the process will determine the vertical y-position for each contributor and update the linked-list V accordingly. Specifically, the process will determine the vertical position of each financial factor a in our sorted list by comparing it to each financial factor γ in V. If there is space for a above γ then insert a into V before γ and the process can stop examining financial factors in V because a vertical position has been found. If a cannot be fit above any of the financial factors in V then position a after all of them and add a to the end of V.

(i) Related-after financial factors will have the same vertical position as the specific

financial factor, and be added to V after a.

(ii) For related-below financial factors, position them under the specific financial factor and add them to V after a and all the related-after financial factors in already added in (i) .

It should be noted that by carefully performing the inserts into list V as described above, the list V remains sorted by y values without incurring the performance slowdown of manually sorting the list, or using a sorted list data structure .

In accordance with an embodiment of the present

invention, the process for performing financial calculations is optimized. With some prior art financial calculators, the user is required to actively trigger a calculation. For example, the user may be required to press a "Calculate Now" graphical user interface button, or calculations are done when the user closes the current dialog box in which they are entering information. In the present invention, the processor calculates, or re-calculates, financial information as the user changes financial information, adds, or removes financial factors. Therefore, the user does not need to close a dialog box or press a "calculate now" button to view updated

financial information.

For clarity, each financial factor comprises financial information that may be input by the user or by another source or may be pre-configured with specific financial information. Financial information may be defined as a value, wherein that type of value may be, but is not limited to, a date, a monetary cost, a monetary amount, or a number. To achieve these fast results, the present invention has reduced the number of calculations that need to be made by the processor (as compared to the prior art systems) .

Two processes may be used to achieve these reductions in the number of calculations:

1. Implicit time dependencies

When the user changes financial information for a specific financial factor, the change is always made on a specific date on the timeline. The processor then uses that date to reduce the number of calculations required. Any financial factor on the same timeline that ends before the specific date cannot be affected by the change, and thus its financial information does not need to be recalculated.

For example, if full-time employment ends on June 1, 2020, and the user adds a vacation at January 1, 2025, the processor will not recalculate the financial information related to the full-time employment because the vacation does not affect the full-time employment five years earlier.

Similarly, when processing a specific financial factor, the processor determines the specific date on which the change occurred so that the processor can begin calculations from that date. Calculations related to information before that specific date do not need to be performed. By reducing the number of calculations, the system of the present invention performs more efficiently.

2. Explicitly declared external dependencies

The second process to reduce the number of calculations involves having each financial factor declare its external dependencies. The processor utilizes the external dependency, or dependencies, to determine the minimum subset of financial factors that are affected by a change made to financial information for a specific financial factor.

A financial factor can declare one of five types of external dependencies: 1. No dependents: The financial factor does not have any dependent financial factors. Therefore, any changes will only be recalculated when the user changes that financial factor directly. For example, a change could be made by moving the financial factor along the lifeline, or by changing

information that relates to the financial factor (also referred to herein as properties), or by adding, removing or changing a child factor.

2. Depends on economic factors: The financial factor depends on external economic information, such as financial market projections or insurance rate projections, for its calculations. Thus, if the economic information changes (by user input or other) , the processor recalculates the financial information for the dependent financial factors. Dependent financial factors are defined as those factors that are dependent on projections, financial or other.

3. Depends on the user's ability to be employed: A financial factor, such as full-time employment, depends on the user's ability to work; for example, vacations and the health of the person (e.g., heart attack, cancer, etc.) can affect some financial factors.

4. Depends on the financial information of other

financial factors: A user may indicate that financial

information for a financial factor depends on information generated by other financial factors. Here, the processor will recalculate this information at each instance where information relating to other financial factors changes.

5. Depends on the calculated taxes: A specific financial factor requires the tax amounts generated for other financial factors. These financial factors are calculated after all other financial factors and yearly taxes are calculated and may be recalculated if the yearly tax changes.

According to another embodiment of the present invention, the control component associated with the lifeline can generate lifeline overlay charts. Figures 6 through 12 show a number of different overlay charts generated by various embodiments of the present invention.

The lifeline overlay chart is generated by a reusable control component that, according to one embodiment, generates one or more line graphs along a specified timeline. The chart control component interacts with a timeline control component, such that the chart control component utilizes a specific timeline to convert a date-based x-coordinate for every data point on the chart into an x pixel position in the display that lines up with the same date on the specified timeline.

A chart can be either be overlaid on top of a lifeline (by setting its background colour to transparent so the chart does not obscure the image of the lifeline and its

corresponding financial factors), or adjacent to the lifeline such that the chart aligns with the dates in the timeline.

Figures 5 through 9 illustrate how the line graphs may be overlaid on the lifeline. For example, in Figure 5, after-tax income 610 and expenses 620 are shown as an overlaid line graph. In Figure 6, a heart attack shown in the lifeline, which is a type of financial factor referred to herein as a calamity. Therefore, the line graph changed to demonstrate the effect the timing of the heart attack has on after-tax income 610 and expenses 620. The change in line graph also demonstrates that the processor can perform calculations and output new financial information in real-time as changes to the financial information are being inputted by a user or other source.

In Figure 10, a series of bar graphs 630A, 630B,

630F, is shown adjacent to the lifeline. Here, each decade in the timeline has its own corresponding bar graph 630A, 630B, 630F. In Figure 11, an expanded bar graph 630B for the 2030 decade is shown. Here, each bar in the bar graph represents a monetary value for specific financial information. The bar graph 630B has a bar for income, expenses, taxes, cash, assets and liabilities. As can be clearly seen in Figure 10, the monetary value of cash is much greater than any of the other monetary values.

The present invention is not limited to the

aforementioned types of charts. Other graphing techniques and charts may be readily contemplated and implemented by the skilled artisan.

In the drawings, there are three different lifeline overlay charts shown: (1) overlay charts showing specific lifeline information, as in Figures 5, 6, 10, and 11; (2) overlay charts for insurance information, as in Figures 8 and 9, and (3) overlay charts for economic information, as in Figures 7 and 9. As can be seen in Figure 9, lifeline, insurance, and economic information can be charted and overlaid on top of one another.

Figure 7 is a line graph, overlaid on a lifeline, of well-known financial indexes for the Dow Jones, MSCI EAFE World Index, and the NASDAQ. The line graphs were generated by the processor based on projections made from 20 years of historical information on these financial indexes.

Figure 8 is a line graph, overlaid on a lifeline, of insurance information.

Figure 9 is a line graph, overlaid on a lifeline, showing projections for the Dow Jones index 710, the NASDAQ 720, a user's desired amount of insurance 730, and a user's financial assets 740. Figure 9 illustrates how lifeline, insurance, and economic information can be charted and overlaid on top of one another .

All of the information for the charts is generated by the control component. When the processor for the control component finishing recalculating the minimum set of financial information, it produces a calculated completed event, which then causes all of the overlay charts to be updated. According to another embodiment of the present invention, the lifeline information may be cloned. Figures 12 and 13 illustrate this optional feature. Figure 12 shows a first lifeline. Figure 13 shows a first lifeline 810 and a cloned lifeline 820. A cloned lifeline is a second lifeline with the same financial factors as the first. The cloned lifeline enables a user to change information related to various financial factors, and add new financial factors, and

completely remove cloned financial factors, to compare financial outcomes for different scenarios. Also, the present invention contemplates providing financial summaries adjacent to the first lifeline and the cloned lifeline (s) . These summaries enhance the user's experience by displaying

comparable financial information.

In accordance with the present invention, it is

contemplated that there are many different properties

(financial information) that may be related to each other. In Figure 14, a graphical user interface for a financial factor, the fixed rate mortgage, is shown. The down payment amount plus the mortgage amount equals the initial value of the property. The mortgage amount also affects the regular payment amount for the mortgage, as does the interest rate. Changing any of the values for this financial factor would change the other values associated with it as well as values associated with financial factors which are related to or dependent on this specific financial factor.

For clarity sake, each financial factor comprises financial information.

For a fixed rate mortgage financial factor, only some of the financial information may be changed by the user, with the remaining information calculated by the processor. The present invention contemplates that the user may change any of the user-changeable financial information in the order the user chooses. As such, the sub-control component for the given financial factor re-calculates the required financial information (or properties of that financial information) to ensure that the mathematical relationships between the financial information remain correct.

For example, in Figure 14, a user may change the "annual percentage interest rate" from "4.500%" to "5.500%". The sub- control component for the fixed rate mortgage financial factor would then re-calculate the "regular payment amount" because it would be affected by the interest rate change.

It should be further mentioned that the sub-control component functionality is accomplished at the domain object level, such that a user interface is not required. Here, a domain object must specifically create a related-properties object that implements this functionality.

In programming one aspect of the invention, a special software construct or class may be used to implement the above feature. A special class (here called the RelatedProperties class) can provide this functionality. The creating class - which in the example shown in Figure 14 would be the mortgage financial factor - creates an instance of the

RelatedProperties class passing in itself as a parameter.

This allows the RelatedProperties class to react to changes made to the financial information for the mortgage amount. The RelatedProperties class maintains the collection of the financial properties and the equations used to calculate each property.

For example, the financial information name is

"DownPayment" and the equation is: downPayment = totalValue - outstandingBalance

The RelatedProperties class then records each instance where financial information changes on the mortgage financial factor. The class maintains a most-recently-changed list of changed financial information.

In accordance with one embodiment of the present

invention, the most-recently changed list is a standard and reusable data structure for storing the most recently used items. The "Recent Documents" feature in the MS Vista™ operating system, or in the MS Word™ application, are examples of this data structure in the prior art. There are also several different means for implementing the data structure, with the two most common being a linked-list or an array.

Either may be used in accordance with the present invention. Data structures other than a linked-list or an array may, of course, be used to implement this feature.

In accordance with the most-recently-changed list data structure, any time financial information for the mortgage is changed, the RelatedProperties class uses the most-recently- changed list to determine the property that was changed by the user longest ago. It then uses the equation associated with that property to recalculate the property that was changed longest ago, so that the mathematical inter-relationship between financial information is correctly maintained without negatively impacting information more recently entered by the user .

In accordance with another embodiment of the present invention, the financial factors can include calamities, which are typically negative events with variable durations along the lifeline. For example, Figure 15 lists the following calamities 800 as graphical icons: cancer, heart attack, long term disability, short term disability, and stroke.

In addition, financial factors such as those shown in lifeline 100 of Figure 2 may be selected from a menu. In Figure 16, a graphical icon menu 810 is shown.

It should be further mentioned that a user's lifeline can include financial factors related to a family member, such as a dependent child. In Figure 16, graphical icons for the user's family 820 are shown.

In accordance with another embodiment of the present invention, Figure 17 shows a lifeline with a baby as a financial factor and child factors.

It should also be mentioned that lifelines, and any client profiles, may be saved in memory or in the storage device and may thus be recalled at a later date.

The present invention further contemplates an undo or a reverse change system and method that is utilized with the personal financial planning system and method. However, it should be noted that the undo or reverse change system described herein is a powerful, generic and reusable system that may be utilized in other computer programs.

According to another embodiment of the present invention, each item visible to and changeable by the user (e.g., address, phone number, client, lifeline item, etc) is

automatically and transparently associated with a change monitor object that watches or monitors the "item" for undo- able changes (or reversible changes), and logs those changes. There are, therefore, many change monitors at any time. All the change monitors report to a top-level change monitor that aggregates all the changes for display to the user. Changes are captured in special undo objects or "reversible change" objects, which are programmed to be able to undo (reverse change) and redo (repeat) a single change. It should be noted that undo objects are created by change monitor objects in response to a specific change in a property for a domain object being monitored by the change monitor object.

When the list of changes is displayed to the user

(essentially a list of the undo objects), each undo object constructs an appropriate human-readable description of the change based on meta-data applied to the property that was changed. An appropriate icon may also be assigned to the property that was changed.

It should be noted that the reverse change system (or the undo system) may be applied to all items and/or properties noted above. Items for which changes may be reversed may include events, financial information, financial factors, lifelines, timelines, and any other item mentioned above.

These items may be removed, added, or inserted and such removal, addition, or insertion may be undone (or redone) at any point by the user. The properties for these items may also be changed and, as such, any change for these properties may be reversed or undone. Each change is reflected by the creation of a specific undo object and activation of that undo object by the user reverses the change that caused the creation of that specific undo object.

When the user selects an undo object through the user interface (graphical or textual) the undo object undoes or reverses the change. If necessary, this event signals to the processor that a recalculation may be needed for the item changed as well as any items or properties which may be dependent upon that item.

In accordance with an embodiment of the invention, Figure 18 is a representation of a list of reversible changes or undo objects which, if activated by the user, reverses specific changes which have been previously entered.

Figure 19 is a representation of domain objects and change monitor objects in accordance with an embodiment of the present invention. Figure 20 is a representation of items and their relationships in the reversible change system in accordance with an embodiment of the present invention.

Figures 19 and 20 are explained in further detail below.

The undo or reverse change system and method of the present invention operates at the domain logic layer,

operating below the user interface layer (except for the purposes of displaying reversible changes, where the list of reversible changes is made available to user) .

The domain logic layer is defined as the internal code layer where business rules and business objects are codified. Each business "noun" is codified as a class. For example, the domain logic layer may have classes for "client", "phone number", "address", "mortgage", "vacation", "heart-attack", etc. Each domain object has a number of properties or specific data values associated with it. For example, a client has a first name, last name, birth date, two e-mail addresses, a list of phone numbers, a list of addresses, a list of lifelines, and etc.

According to an embodiment of the present invention, the undo or reversible changes system operates at the domain object layer by understanding that domain object properties change, and that lists of things can also change by adding, removing, moving or changing an item within the list.

According to the present invention, the "top-level" domain object is of the class "client". Whenever a "client" is created, a special "undoable-object monitor" or "change monitor object" is also created and is associated with that client. Referring to Figure 19, it can be seen that the top- level domain object is "fred" and that, associated with this top-level domain object are the lists "addresses" and "phone numbers". For these two lists, each list has multiple domain objects. For "addresses", two domain objects are "home" and "cottage", both of which are of the class "address", meaning that each of "home" and "cottage" have the properties

"Street", "City", "ProvinceOrState", "Country", and

"PostalOrZipCode", all of which are strings. For the "phone numbers" list, the three domain objects are "home", "mobile", and "office", all of which are of the class "PhoneNumber" . This means that, as can be seen, all of the domain objects under the list "phoneNumbers" will have the properties

"Number", "Notes", and "Type".

For the top-level domain object "fred" (of class

"Client") a top level change monitor object is created (see top right corner of Fig 19) . For each of the domain objects under the top-level domain object "fred", a separate change monitor object (or change monitor in the figure) is created. As can be seen, each change monitor object created is

associated with a specific domain object and the hierarchy for the domain objects is mirrored by the hierarchy for the change monitor objects, e.g. the change monitor object for the list "addresses" has child monitor objects, each corresponding to a specific domain object that is a child domain object of the list "addresses".

To explain the process of how the hierarchy for the reversible change objects is created, it should be noted that, essentially, each domain object is mirrored by a change monitor object that monitors the properties of that domain object. Once a new top-level domain object (or an object of class "client" in Fig 19) has been created, the top-level change monitor object associated with that new top level domain object client reviews all the properties of that top level domain object and looks for any public properties or lists that should be watched for changes. If the top-level change monitor object discovers child objects that are other domain objects (e.g., an "address" object on a "client" object) then the top-level change monitor object creates a new change monitor object and associates it with the discovered domain object. As an example, if the new top level domain object has a child (or offspring) domain object of class "mortgage", this child domain object may have a number of properties or values such as interest rate, maturity date, down payment, bank name, amount mortgaged, etc., etc. This child domain object would have a corresponding change monitor object that monitors those properties and the child object itself for any changes.

This discovery process occurs recursively down the chain of domain objects until every domain object, whether a child object or a subsidiary child object subsidiary to a child object, and every list is associated with a change monitor object. Each change monitor object has knowledge of its parent change monitor object, such that a hierarchy of change monitor objects is created that mimics the domain object hierarchy in memory. This mirroring of the hierarchy can be seen in the example in Fig. 19.

Once the undo system hierarchy is in place, each of the various change monitor objects monitor their associated domain object or list for any changes related to this domain object or list. Once a change occurs (e.g. a property is changed, the domain object is deleted, etc.), the relevant change monitor is notified and that relevant change monitor creates an undo object specific to that change. The created undo object may have, as its parameters, the domain object whose property changed, the specific property for that domain object that was changed, the previous value for that property, the new value for that property and the change monitor that is creating the undo object. As will be noted below, an undo object for a change to a list will also have the actual type of change done to the list. The created undo object is then listed/registered by the top level change monitor in its master list of undo objects. This master list can then be presented to the user if and when the user wishes to undo or reverse any changes which may have been carried out

previously. As will be noted below, the human readable data (as well as an associated icon) for the master list can also be generated by each undo object.

If the user wishes to undo a previously entered change, the master list of undo objects is presented to the user and the user can activate any of the undo objects listed. Once an undo object has been activated, since the undo object knows which specific domain object and property is to be affected, that domain object and/or property is changed based on the parameters for that specific undo object. As can be seen in the example of Figure 18, each undo object provides the user with an indication of what which property/object is to be changed and what it is to be changed back to. Once the undo object is activated, that undo object undoes or reverses the change that caused its own creation.

It should be noted that the activation of an undo object does not necessarily entail the removal of that undo object from the master list of undo objects. The undo object which has been activated may still be in the master list. It should, however, be pointed out that the activation of an undo object will cause the creation of another undo object, one that reverses the change that the first undo object effected. As an example, if a value is changed from 0 to 1, this may cause the creation of undo object A which notes the change of the value from 0 to 1. Activation of undo object A will change the value back from 1 to 0 but this activation will also cause the creation of a new undo object B which will note the change of the value from 1 to 0.

It should be noted that a special type of change monitor object is required to watch lists, because a list is

fundamentally different than a normal domain object which just has properties (where those properties may be normal

properties, other objects, or even other lists) . This special type of change monitor object monitors its associated list for list changes such as insertions, changes, additions, and removals from the list. When such changes occur to the associated list, the list undo object created for that change notes the specific change type (insertion, deletion, change, addition, or removal) and what was inserted, removed, or added.

The present invention also contemplates that dictionary changes may be possible. For dictionary changes, any changes as to what key is mapped to what value are recorded by the relevant change monitor object.

It should be noted that each change monitor object knows its top-level change monitor object, and registers itself with this top-level change monitor object. As such, the top-level change monitor object knows about all subsidiary change monitor objects in the hierarchy. As an example from Fig 19, the top-level change monitor object at the top right corner of the figure will have registered with it all the change monitor objects below it in the hierarchy.

According to the present invention, each change monitor object watches its associated domain object for changes. Each domain object is responsible for raising a special event when a property or list changes or when any change relating to its associated domain object occurs. Raising a property-changed event is common practice in programming; in .NET framework the event contains the name of the property, and in Java the event contains the new and old values of the property as well.

Raising the property changed event can be made completely automatic by using aspect oriented programming techniques in conjunction with the undo/reversible change system. It should be noted that this automating of the raising of the property changed event is not necessary but it has been found to contribute to clarity in the domain object code. The

undo/reversible change system may best be used with a property changed event that contains both the old value and new value, as well as the programmatic name of the property.

Thus, whenever a property or a list changes on a domain object the associated change monitor object is notified, and can record the change. (Note that a special attribute can be applied to any property on the domain object that instructs the undo/reversible change system to ignore changes to that property. This is useful in many situations where a property on a domain object should never be exposed or changed by the user, so the undo/reversible change system does not need to watch it . )

There are only a few types of changes which may be used to address the different types of changes a user can implement with the system:

• Property changed - works with any type of property (integer, decimal, boolean, string, object, etc.)

• List item inserted - a new item has been added to a list

• List item removed - an existing item has been removed from a list

• List item moved - an existing item in a list has been moved within the list

• List item replaced - an item in the list was replaced by a new item

This loose coupling (the undo/reversible change system depends on the domain object raising property changed events, but the domain object knows nothing about the undo/reversible change system) means that in most cases the domain object is completely unaware of the undo/reversible change system, which is very powerful. This has the major benefit that domain objects can be created without any concern for the

undo/reversible-system, but the undo/reversible change-system can still automatically and transparently provide undo services for the domain object. This dramatically reduces coding time, because the undo-system is "done once" and then works for all existing and new domain objects as the

application grows and changes over time.

Note that every undo-able/reversible change is registered with the top-level change monitor object, so that the user interface has one location to look for all possible changes. As mentioned above, each relevant and allowable change to an object or property causes the creation of a specific undo object which is listed with the master list administered by the top-level monitor object.

When the set of reversible changes or a presentation master list is to be presented to the user a number of things occur. Each undo object is responsible for determining its own representative image and its own undo message text. To clarify, each undo object determines which representative image is suitable based on such considerations as the type of object being monitored and/or the data-type of the property that was changed and, once the image and its text has been determined, the undo object saves this information for future use. Each undo object investigates or determines which image and text is suitable for it based on the object being monitored .

Each undo object knows which domain object and which property on the domain object it was created for (or, in the case of list change-actions the list action that occurred) , and the exact property on that domain object that changed. Every domain object property is attributed with a special resource-key. When the undo object is created, the undo object determines the various parameters it needs such as the domain object which was changed, the property which was changed, etc., etc. During this investigation by the undo object, the resource key is retrieved from the property, and then looked up in a language-specific dictionary of terms. The dictionary maps resource-keys to human-readable names. A an example, the property might be "FirstName" and the associated key might be "FirstName_Key" . In an English dictionary this would map to "First name", and in a French dictionary this might map to "Prenora". This investigation by the undo object, by retrieving the resource key from the property and then mapping the key to human readable names by looking up the key in a specific dictionary of terms, is done at runtime. Once the human readable names have been retrieved and/or determined, the names are then presented to the user. Thus, the undo object can retrieve the human-readable name of the property that changed, and combine it with the original value of the property to construct a rich human readable description of the undo-able or reversible change. This description can then be used when listing the created undo object in the master list.

Each type of reversible change is automatically

associated with a particular image. However, the generic undo object also performs some further functions regarding the image associated with it. Each undo object, when created, examines the data type of the property that changes and dynamically determines the type of image. As an example, for a boolean data type, the undo object may associate itself with a check-box image, but for a string data type it may associate itself with a little text cursor image, etc. If the property is tagged with a special undo-image attribute then the data type is treated as an image or a pointer to an image, and the actual image is used to annotate the undo-able or reversible change in the user interface.

ch undo object can test if it is currently relevant For example, if a person domain object's first name is currently "Frank", but the user changes the first name to "Susan", then changes it to "Bob", and then changes it back to "Frank" there will be three undo-able or reversible changes:

1. Most recent change: Change the name back to

Bob" (from "Frank")

2. Middle change: Change the name back to

Susan" (from Bob)

3. Oldest change: Change the name back to

Frank" (from "Susan") The current value of the first name is "Frank", so the oldest change is not relevant - the name is already "Frank" so displaying an undo-able or reversible change to change the name to "Frank" is not helpful for the user.

Thus, each reversible change exposes the ability to determine if that particular reversible change is currently appropriate or relevant. The user interface only displays relevant reversible changes. Reversible changes will only report that they are relevant if the change monitor object that created the undo object is still in the change monitor object hierarchy. Thus, when the user deletes a domain object, all its associated reversible changes and its

associated objects are removed from the list of available changes presented to the user.

As the user removes objects from the domain object hierarchy the corresponding change monitor object is also removed from the change monitor object hierarchy. However, it remains registered with the top-level change monitor object. This ensures that the association between the top-level change monitor object and the domain object is not lost. This is significant because the user can undo the removal. One side- effect of this scheme is that it also allows users to "cut" the object, and the object can then be "pasted" back in.

As an example, if in Figure 19 the domain object "home" from the list "addresses" was deleted, then the change monitor object for that object "home" is removed from the change monitor hierarchy. All the associated undo objects related to that object "home" and its properties will not be presented to the user when the master list is viewed by the user as these undo objects are no longer relevant as the change monitor object for this object has been removed from the hierarchy. However, the change monitor object for that object "home" is still registered with the top-level change monitor and the deletion of the object "home" creates a corresponding undo object which will now be listed in the master list.

To support keeping the reversible changes between top- level objects, this mapping between change monitor objects and domain objects can be made static, such that it is shared between all top-level objects.

Alternatively, all business objects could expose the association with the domain object's change monitor object directly. However this approach concretely ties the domain objects to the undo/reversible change system. With advanced aspect oriented programming, the association between the domain object and the change monitor object can be injected directly into the domain object at compile time. This solution may be seen as more elegant than programming the association into the domain objects as the domain object's class remains ignorant of the association but the association is still stored directly in the domain object. Both

approaches eliminate the need to have a programmed mapping between the two classes maintained by the top-level change monitor object.

It should be noted that, for ease of use, the master list of undo objects as well as the hierarchy of both the change monitors and the domain objects may be saved prior to exiting a computer program which uses the undo/reverse change system. Such an action would allow a user to save a state of the system for future use so that changes made in one session may be undone or redone in another session.

It should be mentioned that all components of the present invention may be software modules executed by or residing in the computer system.

The method steps of the invention may be embodied in sets of executable machine code stored in a variety of formats such as object code or source code. Such code is described

generically herein as programming code, or a computer program for simplification. Clearly, the executable machine code may be integrated with the code of other programs, implemented as subroutines, by external program calls or by other techniques as known in the art .

The embodiments of the invention may be executed by a computer processor or similar device programmed in the manner of method steps, or may be executed by an electronic system which is provided with means for executing these steps.

Similarly, an electronic memory means such computer diskettes, CD-ROMs, Random Access Memory (RAM) , Read Only Memory (ROM) or similar computer software storage media known in the art, may be programmed to execute such method steps. As well,

electronic signals representing these method steps may also be transmitted via a communication network.

Embodiments of the invention may be implemented in any conventional computer programming language For example, preferred embodiments may be implemented using suitable programming languages or platforms such as C#, Java, or

VB.NET. Alternative embodiments of the invention may be implemented as pre-programmed hardware elements, other related components, or as a combination of hardware and software components. Embodiments can be implemented as a computer program product for use with a computer system. Such

implementations may include a series of computer instructions fixed either on a tangible medium, such as a computer readable medium (e.g., a diskette, CD-ROM, ROM, or fixed disk) or transmittable to a computer system, via a modem or other interface device, such as a communications adapter connected to a network over a medium. The medium may be either a tangible medium (e.g., optical or electrical communications lines) or a medium implemented with wireless techniques (e.g., microwave, infrared or other transmission techniques) . The series of computer instructions embodies all or part of the functionality previously described herein. Those skilled in the art should appreciate that such computer instructions can be written in a number of programming languages for use with many computer architectures or operating systems. Furthermore, such instructions may be stored in any memory device, such as semiconductor, magnetic, optical or other memory devices, and may be transmitted using any communications technology, such as optical, infrared, microwave, or other transmission technologies . It is expected that such a computer program product may be distributed as a removable medium with

accompanying printed or electronic documentation (e.g., shrink wrapped software), preloaded with a computer system (e.g., on system ROM or fixed disk) , or distributed from a server over the network (e.g., the Internet or World Wide Web) . Of course, some embodiments of the invention may be implemented as a combination of both software (e.g., a computer program product) and hardware. Still other embodiments of the

invention may be implemented as entirely hardware, or entirely software (e.g., a computer program product).

A person understanding this invention may now conceive of alternative structures and embodiments or variations of the above all of which are intended to fall within the scope of the invention as defined in the claims that follow.

Claims

Having thus described the invention, what is claimed as new and secured by Letters Patent is:

1. A system for personal financial planning for a user along a specified timeline comprising:

a data storage device for storing data associated with a user;

data processing means, operatively coupled to a data storage device, and configured with:

a control component that generates a first lifeline for the user along the specified timeline;

at least one sub-control component, wherein each sub-control component generates a

representation of at least one financial factor and financial information corresponding to the at least one financial factor, wherein each representation of at least one financial factor is part of the first lifeline,

a display device, operatively coupled to the

processor, for displaying at least one the financial factor along the specified timeline from a start position to an end position, wherein the start position and the end position are determined by the sub-control component based on corresponding financial information in the financial factor.

2. A system as in claim 1, wherein the display device displays a plurality of financial factors along the specified timeline, financial factor, such that the plurality of representations of financial factors are simultaneously visible on the display device.

3. A system as in claim 1, wherein the start position and the end position are determined by the sub-control component based on user input.

4. A system as in claim 2, wherein the display device includes a user interface component, and wherein the user selects, through the user interface component, each financial factor and corresponding financial information to be represented along the specified timeline.

5. A system as in claim 2, wherein dates relating to a second financial factor is based on information relating to a first financial factor.

6. A system as in claim 2, wherein associated financial information includes at least a first value and a second value, wherein a change made to the first value affects the second value, such that upon a change to the first value, the processor calculates the second value.

7. A system as in claim 2, the plurality of financial factors comprises at least one of the following: income, expenses, mortgage, assets, liabilities, investments, calamities, various types of insurance, taxes, vacations, and family dependents .

8. A system as in claim 1, wherein the control component overlays a transparent representation of financial information along the specified timeline, such that a representation of the at least one financial factor and the transparent

representation of financial information are visible on the display device.

9. A system as in claim 1, wherein the control component generates a second lifeline that is identical to the first lifeline.

10. Computer readable media having encoded thereon a method for creating a visual representation of at least one financial factor in personal financial planning for an individual along a specified timeline, the method comprising:

(a) selecting the at least one financial factor, and providing financial information

corresponding to the at least one financial factor;

(b) determining a start position and an end

position for the financial factor along the specified timeline, based on financial

information corresponding to the financial factor;

(c) repeating steps (a) and (b) for each of the at least one financial factor; and

(d) displaying a representation of each financial factor along the specified timeline to form a lifeline for the individual.

11. A method for tracking changes in values in a computer program such that the changes may be reversed, the method comprising :

(a) for each top level object in the program:

(al) creating a top level change monitor object;

(a2) determining child objects created for the top-level object;

(a3) for each child object, creating a change monitor object to monitor changes relating to the child object;

(a3-l) determining subsidiary child objects created for the child object;

(a3-2) for each subsidiary child object determined in step (a3-l) , creating a corresponding change monitor object to monitor changes relating to the subsidiary child

object;

(a4) recursively executing steps (a3-l) to (a3- 2) for each subsidiary child object and for each child object such that each child object and each subsidiary child object has a

corresponding change monitor object;

(b) registering each change monitor object with the top level change monitor object; and

(c) registering each change monitor object with a parent monitor object; and

(d) for each change relating to a child object or subsidiary child object detected by a relevant change monitor, creating an undo object and listing the undo object with a master list administered by the top level change monitor; wherein each undo object, when activated by a user, reverses a change which caused a creation of the undo object.

12. A method according to claim 11, wherein each undo object is associated with a specific icon based on at least one of the following:

- a data type of a property whose change caused a creation of the undo object; and

- a type of object being monitored by a change monitor that created the undo object.

13. A method according to claim 11, wherein each undo object associated with a specific description based on a resource-key associated with a property whose change caused a creation of the undo object.

14. A method according to claim 12, wherein each undo object is represented by the specific icon in the master list when the master list is presented to the user.

15. A method according to claim 13, wherein each undo object is described on the master list using the specific description when the master list is presented to the user.

16. A method according to claim 11, wherein a presentation master list presented to the user comprises undo objects which relate to child objects or subsidiary child objects which have not been deleted.

17. A method according to claim 11, wherein each undo object comprises parameters for reversing the change which caused a creation of the undo object, the parameters including at least one of the following:

a previous value of a property;

a new value of a property;

an operation on a list which changes the list;

an identification of a property whose change caused a creation of the undo object; and

an identification of a child object or subsidiary child object for which the change relates.

18. A method according to claim 11, wherein entries in the master list is saved prior to exiting the program.

19. A method according to claim 11, wherein a presentation master list presented to the user comprises undo objects which are relevant, a relevance of a specific undo object being based on whether prior undo objects execute a change whose effects are similar to the specific undo object.