Apparatus and method using front-end network gateways and search criteria for efficient quoting at a remote location

[0002] This is a continuation-in-part of U.S. patent application Ser. No. 07/912,978 having a filing date of Aug. 17, 1992 now U.S. Pat. No. 5,673,402, and a continuation-in-part of U.S. patent application Ser. No. 08/210,395 having a filing date of Mar. 18, 1994 now U.S. Pat. No. 5,655,085, the latter of which also claims priority from the former.

[0003] A. Technical Field of the Invention

[0004] This invention concerns an electrical computer and a data processing system, and methods involving the same, applied to the financial fields of insurance and mortgages. More particularly, this invention relates to a computer system for preparing, processing and transmitting life insurance premium quotes as part of a mortgage calculation in support of a new financial product. In the new financial product, life insurance is used as collateral and a means for repayment of a mortgage, and facilitates the purchase of real estate without (or with a greatly reduced) down payment. The invention includes automated aspects of the use of premiums paid on life insurance as a substitute for the initial down payment on a mortgage, the use of life insurance policy death benefits to retire the mortgage upon the death of the borrower, the use of accumulated cash values to retire the outstanding principal on a mortgage in the event of the borrower's survival, and the services of storage and transmission of data for all of the foregoing.

[0005] This invention optionally also relates generally to a computerized system for preparing and processing multiple universal life insurance quotes and for preparing and processing universal life insurance applications, based upon those quotes. More particularly, the present invention relates to a machine, manufacture, process, and improvement thereof.

[0006] More particularly, this invention relates to a computer system for preparing, processing and transmitting life insurance premium quotes as part of a mortgage calculation in support of a new financial product. In the new financial product, life insurance is used as collateral and a means for repayment of a mortgage, and facilitates the purchase of real estate without (or with a greatly reduced) down payment. The invention includes automated aspects of the use of premiums paid on life insurance as a substitute for the initial down payment on a mortgage, the use of life insurance policy death benefits to retire the mortgage upon the death of the borrower, the use of accumulated cash values to retire the outstanding principal on a mortgage in the event of the borrower's survival, and the services of storage and transmission of data for all of the foregoing.

[0007] B. Description of the Background Art

[0008] In the United States, the declining supply of low-cost housing and the inability of many low-income renters to save enough money to make a down payment has forced many potential home buyers out of the housing market, according to a study released Mar. 17, 1988, by the Harvard University Joint Center for Housing Studies. (Reported in the Mar. 28, 1988, Bureau of National Affairs Banking Report.) To address this problem in the United Kingdom, a way has been found to combine life insurance and a mortgage into what is known as an “endowment mortgage.”

[0009] A UK endowment mortgage is a balloon payment mortgage combined with an endowment life insurance contract. A UK endowment life insurance policy provides life insurance coverage and tax-free accumulation of premium dollars invested in the life insurance policy over a stipulated time period—usually between twenty and forty years. The lender and the insurance company work in concert to engineer a balloon payment mortgage linked to an endowment life insurance policy so that, at the end of the mortgage period, the cash value accumulated via the life insurance is sufficient to repay the mortgage in a single, lump-sum “balloon” repayment.

[0010] A home buyer financing the purchase of a home with a UK endowment mortgage pays no principal to the lender over the term of the mortgage. Monthly loan payments are limited to interest only. The mortgage principal is repaid separately by using the life insurance policy. This principal accumulates in an endowment life insurance policy—a universal life insurance policy with a level death benefit equal to the purchase price of the home. The premium dollars invested grow over the term of the mortgage to meet the amount of the principal borrowed to purchase the home. In the last year of the mortgage, the life insurance policy “endows,” and the homeowner uses a one-time tax-free distribution from the life insurance policy to repay the mortgage.

[0011] The endowment mortgage has numerous advantages to UK borrowers and lenders. First, it is more tax-efficient for borrowers than a conventional amortization mortgage. This is because monthly payments include only interest and are therefore 100 percent tax deductible. Second, principal payments, made in the form of premium payments to the endowment policy (less the cost of mortality and insurance charges), accumulate tax free. This causes endowment policy assets to grow more rapidly, and in turn allows lenders to lower the amount of the required down payment. Third, it is a more secure lending vehicle for the lender. The lender has collateral rights to both the mortgaged property and the insurance policy. Fourth, because of the insurance component of the endowment mortgage, the homeowner has built-in security that so long as he or she maintains the mortgage payments, the survivors will inherit the mortgaged property free of the mortgage.

[0012] Subsequent generations of products have expanded on the endowment mortgage concept in the UK. Derivative versions of the product include the so-called Pension Mortgage and Personal Equity Plan (PEP) Mortgage. Both products link the UK equivalent of an Individual Retirement Account or Keough Account, term insurance, and a balloon payment mortgage. These financial products include all of the characteristics of an endowment mortgage (full deductibility of mortgage interest payments, life coverage, and tax-free accumulation of principal). The term insurance provides the life coverage component of the endowment mortgage, the Pension or PEP provides the tax-free accumulation of principal, and the balloon payment mortgage provides fully deductible loan interest. In addition, both the PEP and Pension mortgages have the additional benefit of offering at least a partially deductible principal repayment. Both PEP and Pension contributions are tax-deductible up to certain limits.

[0013] Endowment mortgages dominate the residential mortgage market in the UK. For example, approximately 82 percent of all mortgages underwritten in the UK in 1988 were endowment, pension, or PEP type mortgages. Conventional amortization type mortgages, similar to those commonly available in the United States, are also available in the UK, but these accounted for only 18 percent of new mortgage sales in 1988.

[0014] Despite their great success in the UK, endowment type mortgages have not similarly dominated the United States residential mortgage market, apparently largely due to the different laws of each nation. In the United States, federal statutes forbid most lenders from selling life insurance. Also, most states have laws forbidding tie-in sales of mortgages. A tie-in sale occurs when a lender insists that a borrower buy a particular insurance product from a particular life insurance company. Legal impediments also exist for life insurers wishing to lend money as an inducement to sell insurance. Further, in the United States the tax treatment of life insurance is different from that in the United Kingdom. In the United States, policyowners must pay taxes on policy distributions in excess of the basis (for US tax purposes, the basis is equal to cumulative premium payments) in the contract. In the UK, distributions from endowment type insurance contracts are tax free.

[0015] Thus, in the US there is a unique problem of how to lawfully combine a mortgage and life insurance and additionally make a viable financial product. Accordingly, it is not surprising that computer systems to illustrate such a financial product have been lacking in the United States.

[0016] A proposal to combine life insurance and a mortgage, implemented by means of a computer system, has been made in U.S. Pat. No. 4,876,648, titled “System and Method for Implementing and Administrating a Mortgage Plan” (Charles Lloyd) (hereinafter “LLOYD”), issued on Oct. 24, 1988. Under LLOYD's mortgage scheme, as it is presently understood, each year the lender charges some percent over the standard interest rate to cover the cost of insurance premiums ($100,000×1%=$1,000 in LLOYD's example). These insurance premium payments buy an insurance policy that is owned by the lender as the means by which the mortgage principal is repaid. At five-year intervals, the homeowner may receive a rebate of this extra interest paid (and deducted) by exercising a cost containment clause. At the execution of this clause, the lender makes a distribution equal to the policy premiums to the homeowner. For example, in year 20, the distribution would be equal to $20,000 for a total of 20 annual premiums of $1,000. By exercising the cost containment clause to obtain the $20,000 distribution and using that distribution to buy the life insurance policy from the lender at the lender's basis in the policy, $20,000, the homeowner can pay down the mortgage. That is, the homeowner now owns an insurance policy with a cash value of $40,648, which may be used to pay down the mortgage.

[0017] However, there are a number of significant problems with the LLOYD approach. These problems seem to center on the mechanism for getting the money out of the insurance policy to retire the mortgage, i.e., the cost containment clause. One significant problem that may be real or perceptual is the possibility that the financial product could be viewed as constituting an unlawful discrimination based on age and sex. That is, if the lender builds the cost of the policy premium into the mortgage interest rate, then there will be the appearance of charging different interest rates to different individuals based on their age and sex. Such pricing differences are lawful in a life insurance transaction because these factors relate to the insurance risk. But age and sex discrimination in lending is generally forbidden under the Equal Credit Opportunity Act, 15 U.S.C. § 1691(a)(1), which provides that “It shall be unlawful for any creditor to discriminate against any applicant with respect to any aspect of a credit transaction—(1) on the basis of race, color, religion, national origin, sex or marital status, or age. . . . ”

[0018] It remains undecided whether a court would view the higher interest rate charged as an interest payment, and therefore subject to the regulations regarding equal treatment for all borrowers with the same credit rating, or as an insurance premium. Nonetheless, there may be a perception that there is some risk that whoever attempts to sell the LLOYD financial product would be sued and would lose, and the penalties for unlawful interest rate discrimination are considerable: 15 U.S.C. § 1691(e)(a) provides for class action suits; subsection (b) provides for punitive damages; and subsection (c) provides for recovery of attorney fees and costs. In the end, though, the perception of discrimination may be the real Achilles heel of the LLOYD financial product, as the lender would have to offer different rates based on age and sex.

[0019] Another drawback of the LLOYD approach is that it has potentially adverse tax consequences. It is unclear if the incremental interest in the LLOYD financial product is tax deductible as home mortgage interest or non-tax deductible as an insurance policy premium payment. That is, if the homeowner has taken a deduction for the incremental interest paid of $1,000 per year over the term of the mortgage, and the cost containment clause is exercised, it is not clear what the tax treatment of the rebate would be. Certainly the IRS will not permit the homeowner to take a deduction for an interest payment for money that is later rebated, and LLOYD acknowledges the possibility of a tax problem with his financial product. See Col. 16, lines 6-20.

[0020] For example, in order to buy the policy from the lender at its cost of $20,000, the LLOYD homeowner will have to pay the difference between the cost of the policy and the after-tax proceeds from the interest rebate. This amounts to about $14,000, assuming that the individual is in a 30 percent tax bracket.

[0021] Still another drawback to the LLOYD approach is its lack of flexibility. While LLOYD mentions the use of variable and fixed rate mortgages the borrower makes only fixed cost containment clause payments, and there exists no mechanism for adjusting the amount of the payments in the event of declining interest rates. The borrower is therefore financing the repayment of a fixed obligation (i.e., the mortgage) with a variable asset (i.e., an interest-sensitive universal life insurance policy). Thus, in the event of declining interest rates, there is no assurance that the cash value accumulated in the cost containment clause will be sufficient to completely repay the mortgage. Furthermore, if the individual wants to sell the home at any time other than at the precise five-year intervals required by the cost containment clause, he or she will lose the value of the incremental interest payments. It is undoubtedly cumbersome to have to retire the mortgage (i.e., exercise the cost containment clause) “only during the fifth, tenth, fifteenth, etc., years of the mortgage.” See LLOYD at Col. 7, line 47-Col. 8, line 6.

[0022] Yet another problem with the LLOYD approach is that, under some circumstances, it appears that the lender may end up with either the incremental insurance payments or the insurance policy after the mortgage is retired. For example, if the home buyer missed the 30-day deadline required for the cost containment clause anniversary in year 20, even if the home buyer happens to have $20,000 and buys the policy outright, he or she will receive a policy worth $60,648. But because the home buyer has already invested $20,000 over the previous twenty years, the lender is $20,000 richer, and the homeowner $20,000 poorer, for the exchange.

[0023] In addition, there appears to be a potential problem with the approach of LLOYD under circumstances where the mortgage is paid off with cash, such as when the mortgaged property is sold. Assume a $100,000 mortgage is retired with cash at the end of the mortgage term. Under LLOYD, the borrower apparently must pay an additional $30,000 to purchase the insurance policy from the lender.

[0024] This is not to say that the financial product proposed in LLOYD is not worthwhile. Rather, LLOYD provides an excellent example of the difficulty in linking a mortgage and an insurance product under the present laws of the United States on a commercially feasible basis.

[0025] In sum, then, United States laws (which define a US mortgage) and other obstacles have seemingly prevented a mortgage/insurance type product from being sold. Despite great success of the endowment type mortgage in the United Kingdom, despite billions of dollars lost in bad real estate loans and many collapsed lenders in the United States, despite the creative prowess of the US financial industry which has tried and failed to successfully develop and sell anything resembling a UK endowment type program in the US, the problem remained unsolved: “for some renters longing to enter the housing market, the likelihood of coming up with a down payment may seem like a pie-in-the-sky notion.” (Chicago Tribune, Jan. 24, 1992.) It remained for the present inventors to find a solution.

[0026] As a further aspect of the present invention, prior to the present invention, insurance quotes for term life insurance, health insurance, and dental insurance were available from a single computer, but universal life insurance quotes were not known to be available.

[0027] Using such single-computer based systems, insurance sellers of annuities, health policies, and term life insurance could request quotes from a large data base of insurance carriers' products. The computer computes the price of a particular financial product offered by a particular carrier for a given customer of a given age, sex, and health, or insured population profile. Then the computer repeats this operation for a large number of different insurance companies. Comparing the values so calculated for a larger number of different carriers' insurance products has permitted the computer to automatically identify that product which provides the best value for the consumer. This also permitted the seller to provide the insurance purchaser with the least expensive quote with a minimum of effort.

[0028] Companies which have developed and used technology of this kind include Quotesmith, in Palatine, Ill., Group Benefit Shoppers in Boulder, Colorado, Dinan in San Jose, Calif., Select Quote in San Francisco, Calif., and Insurance Information Inc. in Lowell, Mass. Quotesmith, Group Benefit Shoppers and Dinan operate primarily in the group medical field, identifying the best policy for brokers and agents seeking to offer competitive quotes. Quotesmith also uses its technology to provide a similar service to brokers wishing to identify the best term life insurance, single premium deferred annuity, individual medical insurance, and group dental insurance policies. Select Quote offers to find the lowest cost quote for a term life insurance policy, selling insurance to the general public on a discount basis. Insurance Information Inc. offers to find the best term life insurance policy for a fee. See “New Firms Offer Computer Listings Of Insurance Prices: Both Have National Ambitions; Both Are Interested in Affiliations with Banks,” American Banker, Oct. 3, 1985, Pg. 1; “Here's how to find cheaper and better health insurance,” Medical Economics, Mar. 19, 1990, Pg. 109; and “Health quoters target agents,” National Underwriter Property& Casualty Risk-Benefits Management, Aug. 28, 1989, Pg. 9.

[0029] While companies have discussed a desire to have the ability to quote homeowners' insurance, a form of universal life insurance, as early as 1985, as of September 1993, no company or individual has been known to find a way to provide multiple universal life insurance quotes to the public in the United States from a single computer, let alone use that ability to identify the best product.

[0030] Instead, insurance agents, insurance brokers, and others representing individuals wishing to purchase universal life insurance policies have been forced to go to many different insurance companies to request quotes. Once received, these universal life insurance quotes have been difficult to compare. Differences in the way these carriers calculate the universal life insurance values have made product comparisons difficult. As a result, insurance sellers have been forced to conduct lengthy and time-consuming analyses to establish which was the best product for the customer. But in view of the aforementioned technological limitations and a fragmented life insurance industry with more than 5,000 carriers; brokers and agents work with only a few carriers. They have not had the ability to search out the best product for their customers. This has become increasingly problematic as product complexity has grown in the universal life insurance industry. Indeed, in some cases unscrupulous agents have taken advantage of increasing complexity in products to further their own unethical ends. In “Investigating Agents,” Best's Review, September, 1993, pp. 29-30, the authors, Stefan E. Keller and Tony D'Orazio, pointed out, “The intricacies of these [life insurance] products require that agents and brokers be more educated than ever to be able to adequately represent the products to consumers. At the same time, the growing complexity increases the probability that products will be represented in an unethical fashion.” In the absence of a systematic means for computing universal life insurance values and comparing products, a consumer purchasing a universal life insurance policy has little to assure himself or herself that he or she has purchased the best policy.

[0031] Once a seller has identified the appropriate product for an individual from one of the thousands of policies available, the process of completing the life insurance carrier's application forms and obtaining underwriting approval for the product can take weeks or months. Because carriers have different insurance forms, and no system has been designed to accommodate the different policies and their associated forms, even if a consumer, agent, or broker identifies the best policy, he or she might not have the appropriate policy forms on hand to initiate an application. He or she and would have to request these forms by mail and, having received them, complete them manually. Because many different carriers have different ways of assessing their underwriting risks, if the prospective insured is of less than perfect health, the agent or broker may have to request additional illustrations. (An illustration is a projection of estimated policy values over a defined period beginning in the present.) For example, a single “No” response to an underwriting question may trigger a rated policy with higher premiums. Such a policy rating would necessitate a new round of illustrations, starting the whole cycle of illustrations over again.

[0032] Given that a system for preparing and processing multiple universal life insurance quotes and for preparing and processing universal life insurance applications would be highly desirable, it would seem obvious that such a system should exist. However, there are several reasons that the aforementioned invention seems to have been elusive heretofore.

[0033] The first reason that multiple universal life insurance quotations have not been available from a single computer in the past has to do with, among other things, the mathematics of universal life insurance. Universal life insurance generally involve iteration computations, unlike health insurance, dental insurance, or term life insurance, where a strict linear relationship exists between a given set of insurance parameters (e.g., age, health characteristics, etc.) and the benefit cost. Therefore, product illustrations or projected values for those products require simply looking up the appropriate value in a data base structure based on a given set of product parameters. The best product, given the selection criteria presented, is always the cheapest product. However complicated, complexity of the design for such a system is limited to the requirements of table manipulation. In addition, the universal life insurance policy accumulates cash value. Universal life insurance is therefore a savings vehicle, and any system which produces universal life insurance illustrations must take into account the time value of money. The time value of money is an exponential, non-linear function. The relationships between the cash value accumulated by the policy, its death benefit, and the amount of premium needed to generate them, are also non-linear. They take into account the time value of money and other factors, such as Internal Revenue Service guidelines for the definition of insurance. Therefore, unlike term life insurance, health insurance and annuity products, such a system for illustrating universal life insurance cannot depend on tables of values which can be selected from using a simple set of selection parameters. Heretofore no system has been able to iterate sufficiently efficiently to find the lowest premium from among a large number of different universal life policies using a single, affordable computer.

[0034] A second reason that universal life quotes from multiple carriers have not been available from a single computer has to do with how universal life insurance calculations must be manipulated to solve for non-linear values. The best policy in a universal life insurance policy comparison can be determined in several ways other than by calculating the lowest premium. The best policy could also be a policy which remains in force for the longest period of time, given specific assumptions regarding interest rates and the insured person's longevity. On the other hand, the best policy could be the policy which provides the highest death benefit or cash value accumulation, given an assumed number of level premium payments over a stipulated period. Finally, the best policy could be the policy which provides the highest guaranteed rate of interest in times of low interest rates or the highest policy crediting rates during times of higher interest rates. The complexity of solving for these variables in a non-linear set of equations is an additional impediment to the development of such a system.

[0035] A third reason that universal life insurance quotes from multiple carriers have not been available from a single computer has to do with the way in which different life insurance carriers compute universal life insurance policy values. While most universal life policy illustration systems are structurally similar, many different carriers have different ways of computing the various elements of a life insurance policy. These different methods have evolved from actuarial conventions designed to reduce the complexity of computations prior to the age of computing, and, of course, through the process of product differentiation. For example, the way in which annual mortality rates are converted into monthly cost of insurance charges may be computed using a variety of different actuarial assumptions regarding the rate of deaths during the year. Some carriers assume deaths are evenly distributed across all twelve months. Other carriers assume more deaths at the end of the year. Other carriers assume the converse. Similarly, different carriers have different methods for calculating policy administrative expense charges and interest credited.

[0036] A fourth reason that universal life insurance quotes from multiple carriers have not been available from a single computer has to do with the way in which insurance is regulated. Each state has legal authority to regulate the way insurance is sold and the kind of insurance that is sold within its boundaries. Therefore, each product sold must be filed with the state insurance commissioner's office. Each state may require that universal life insurance policies have values that are calculated in different ways. For example, some states may require the use of unisex tables in computing mortality costs even though traditional actuarial principles might dictate otherwise. Other states might require different minimum guarantees in terms of the maximum insurance costs that a carrier may charge. Because in the United States an insurance quote system must be able to provide insurance quotes in more than one state in order to justify the cost of development, such state by state differences (added to the aforementioned product by product differences) increase the difficulty of developing a system for finding the best universal life insurance quote from a single computer.

[0037] Therefore it is an object of the present invention to provide a computerized investment and mortgage payment calculation system which overcomes the previously mentioned disadvantages and limitations of the prior art.

[0038] A further object of this invention is to provide a computerized investment and mortgage illustration system, and a method of operating that system, in which a standardized illustration request form is filled out electronically for the purposes of providing a mortgage quote and an investment quote, and a means for computing mortgage and investment payments in conformity with those quotes.

[0039] An additional object of this invention is to provide a computerized investment and mortgage illustration system which uses a central computer to provide information concerning a mortgage using an investment as collateral and as a means for repaying the mortgage.

[0040] Another object of this invention is to provide a computer system for producing a printed illustration document which will permit comparison of the innovative financial product with other loan products.

[0041] Yet another object of this invention is to provide a computer system incorporating a central database into which data representing different lenders' mortgage rates is written and from which data is read in order to provide an illustration of a mortgage collateralized by an investment which is most suitable to the borrower's needs.

[0042] Still another object of this invention is to provide a computer system incorporating a central database into which data regarding different carriers' life insurance policies is written and verified by each such carrier authorized for retrieval thereof and from which is read data making up an illustration proposal of a mortgage backed by a life insurance policy which is most suitable to the borrower's needs given underwriting and policy requirements.

[0043] Still another object of the invention is to provide a computer system incorporating a central database accessible via modem capable of storing and transmitting locally applicable mortgage and insurance quotes on a national basis.

[0044] Still another object of this invention is to provide a computerized insurance and mortgage illustration system capable of showing the projected annual accumulation of life insurance cash values that (under current interest and mortality charge assumptions under a given life insurance carrier's life contract and authorized projections thereof) will provide collateral for a mortgage and which will eventually pay off that mortgage with the after-tax proceeds from surrendering the insurance policy after a stipulated period.

[0045] Still another object of this invention is to provide a computerized insurance and mortgage illustration system capable of showing the projected annual accumulation of life insurance cash values that (under current interest and mortality charge assumptions under a given life insurance carrier's life contract and authorized projections thereof) will provide collateral for a mortgage and which will eventually pay off that mortgage with the proceeds from a life insurance policy loan after a stipulated period.

[0046] Still another object of this invention is to provide a computerized insurance and mortgage illustration system capable of showing the projected annual accumulation of life insurance cash values that (under current interest and mortality charge assumptions under a given life insurance carrier's life contract and authorized projections thereof) will provide collateral for a mortgage and which will eventually pay off that mortgage with the proceeds from life insurance policy death benefits.

[0047] Still another object of this invention is to provide a computerized insurance and mortgage illustration system capable of showing the projected annual accumulation of life insurance cash values that (under current interest and mortality charge assumptions under a given life insurance carrier's life contract and authorized projections thereof) will provide collateral for a mortgage and which will eventually pay the interest on that mortgage with the proceeds from life insurance policy loans after a stipulated period.

[0048] Still another object of this invention is to provide a computerized insurance and mortgage illustration system capable of showing the annual death benefit amount which will provide for the payment of the remaining principal owed in each year over the stipulated term of the mortgage.

[0049] Still another object of this invention is to provide a computerized insurance system capable of identifying potentially higher risk individuals and providing specialized insurance values for those individuals in an illustration of a mortgage using life insurance cash values as collateral.

[0050] Still another object of this invention is to provide a computerized insurance and mortgage illustration system incorporating a central database into which data is written and from which such data is read, to provide the prospective applicant with finally printed, individualized, loan and insurance application forms prepared from standardized textual material in combination with the aforementioned information.

[0051] It is also an object of the present invention to provide a machine, manufacture, process, and improvement thereof in which an electrical signal processing system processes and modifies electrical signals representing data so as to overcome the aforementioned disadvantages of prior art systems and construct and manipulate multiple universal life insurance quotes by electrical engineering means.

[0052] Another object of this invention is to provide a machine, manufacture, process, and improvement thereof in which a computerized system is capable of using iteration to efficiently arrive at the correct amount of a universal life insurance policy premium and, indeed, amounts for other universal life insurance policies as well.

[0053] Yet another object of the invention is to provide a machine, manufacture, process, and improvement thereof in which a computerized system is capable of comparing multiple universal life insurance quotes in order to identify the policy which best fits a given consumer's needs as defined, for example, by the lowest premium, highest cash value, highest policy death benefit, or longest in-force policy life.

[0054] Yet another object of the invention is to provide a machine, manufacture, process, and improvement thereof in which a computerized system is capable of taking into account a large number of different actuarial methods for computing universal life insurance policy values.

[0055] Yet another object of the invention is to provide a machine, manufacture, process, and improvement thereof in which a computerized system is capable of accommodating different universal life insurance values from different states.

[0056] Yet another object of the invention is to provide a machine, manufacture, process, and improvement thereof in which a computerized system is adapted for preparing and processing universal life insurance quotes from many policies based on underwriting information obtained in a single set of questions common to all carriers.

[0057] Yet another object of the invention is to provide a machine, manufacture, process, and improvement thereof in which a computerized system in which different carriers' universal life insurance application forms are available electronically, and may be completed electronically for the purpose of producing both paper and electronic applications to be sent to a carrier.

[0058] Other objects and advantages of the present invention will become apparent from the following summary of the invention, drawings, and detailed description of the invention and its preferred embodiment.

[0059] Various other objects, advantages and features of the present invention will become readily apparent from the ensuing detailed description, and the novel features will be particularly pointed out in the appended claims.

[0060] In accordance with the broad, general objects of this invention, particularly as regards the mortgage aspect of the present invention, a computerized investment and mortgage illustration system is provided for use in illustrating and supporting an innovative financial product. The innovation involves a financial product using an investment other than a down payment (such as cash value life insurance) as collateral and a repayment means for a mortgage, preferably wherein the financial product is devoid of a cost containment clause. This can be accomplished, for example, by having the borrower own an insurance policy and use the policy to secure the loan. In one embodiment (to which the present invention is not limited), a party other than the lender or insurer can illustrate a combination of life insurance and a mortgage preferably selected from those of numerous lenders and insurers.

[0061] Accordingly, the present invention involves processing information in a standardized manner, preferably to package an individually selected mortgage product with an individually selected investment product, the products each being selected from respective groups of such products made available by different suppliers. The packaging process tailors the financial product to the prospective applicant's particular needs.

[0062] The system can, for example, be owned and operated by a suitably licensed national intermediary, for example, a broker or data processing company. The intermediary would work in conjunction with lenders, securities firms and life insurance companies (and their agents and representatives) and with mortgage brokers to design, develop, and distribute investment and mortgage products. The investment and mortgage products, when used in combination with one another, will provide mortgages using an investment as supplemental collateral acceptable to lenders, mortgage insurers and endorsers, and investors in the secondary market for mortgages. The intermediary, operating nationally in cooperation with lenders and utilizing the system provided by this invention, can facilitate the sale of the combined investment/mortgage products by providing authorized lawyers, real estate agents, accountants, financial consultants, relocation specialists, corporate benefits advisors, or mortgage and/or life insurance agents and securities brokers with access to the system of this invention via remote terminals. As compensation for its work in designing the products, maintaining the system, and administering new kinds of supplemental collateral made possible by the system, the intermediary and user of the system would receive commissions for the sale of investments or, when appropriate, would receive fees for services provided.

[0063] Having a data processor or broker working in conjunction with lenders differs from past intermediaries both in the United States and the United Kingdom in that the system of this invention creates for the first time the capability of offering a number of different investment and mortgage products which may be used in conjunction with one another. By bringing these disparate products together in a combined format that is understandable to the end customer, the system permits the customer to have the benefit of access to a new composite mortgage instrument with supplemental security which would otherwise not be available, without encountering the aforementioned problems of the prior art.

[0064] A user of the system can be an employee of the aforementioned intermediary providing illustrations requested by individuals outside of that firm. Alternatively, a user of the system can be an individual who has received special approval from the intermediary to use the system.

[0065] A central processing unit in a digital computer is at the heart of the system. The central processing unit can access a database into which data is written and from which data is read. That data includes information regarding life insurance, mortgage information, actuarial information, insurance premium information, and predetermined text data for incorporation into the combined mortgage and insurance illustrations. The computer system further includes information corresponding to requirements of laws and regulations governing insurance and information on personal tax rates.

[0066] Plural terminals are provided for communicating with the central processing unit, each terminal having input means, such as a keyboard, and a display, such as a cathode ray tube (CRT) or a video display terminal (VDT). Each terminal is operable by a user to produce requests and to enter information and/or retrieve information for writing into and/or reading from the database via the central processing unit. The central processing unit provides a means for enabling access to the database in response to predetermined information entered at the terminal by the user and is suitably programmed to recognize particular authorizations.

[0067] In accordance with one desirable aspect of the invention, information regarding a life to be insured and other data needed to provide illustrations of a mortgage using life insurance as collateral for that individual is keyed into the central processing unit by a system user using a keyboard at a video display terminal. To assist the user in entering the appropriate data, a series of data comprising a “form” is displayed on the user's terminal by the central processing unit, and the user will normally proceed to enter pertinent information in the blanks provided. This information constitutes such things as the potential borrower's name and address, the amount of the mortgage requested, the amount of life insurance coverage required, the individual's personal tax rate, the number of points required by the lending institution, the individual's age, sex, and health status, and any other information necessary in providing an illustration of a mortgage using life insurance as collateral. This information is correlated via the central processing unit, resulting in the generation of premium quotation and mortgage illustration information. This information is then displayed at the user's terminal and can be printed out on the user's printer. Thus, in a matter of minutes, a prospective applicant is apprised of information pertinent to the mortgage such as (but not limited to) what the up-front payment and monthly payments would be for the mortgage if life insurance is used as collateral.

[0068] Once data called for by the “form” is entered into the computer system at the user's keyboard, a client information file or database record (hereinafter “client file”) is established which will be variously updated as the user conducts sensitivity analyses of the impact of different insurance and loan related assumptions on the ultimate amount of the up-front payment and the mortgage. Once the prospective applicant decides to apply for a life insurance policy and loan, a final version of the illustration is saved by the user in a master database file for later retrieval and processing.

[0069] After input data has been compiled in a client file, errors or omissions in that data (e.g., the amount of requested insurance may be too high or omitted altogether, etc.) are detected. If these errors cannot be corrected immediately (for example, by supplying information from another file or record), further processing of the illustration request is suspended and the need for additional information is reported.

[0070] In the event that the prospective applicant wishes to proceed immediately to obtain the respective applications for the insurance and mortgage products, the system is capable of taking the information stored in a final illustration database file, requesting a minimum of information otherwise not required in the illustration process (such as the prospective applicant's personal balance sheet information, which typically is required in the loan application form) and merging it with prepared textual information about the insurance and loan products to generate printed application documents in a form acceptable to, and previously approved by, the lender and the insurance company. The system also permits the user to separately enter these forms and fill the forms out electronically. The application forms still require signature by the prospective applicant, however. When signed, these forms are sent, for example, by mail or courier, to the lending institution and the system owner/operator for further processing. Should the prospective applicant wish to have this process expedited, the user may send the information on the signed forms electronically to a computer at the lending institution and/or system owner/operator, facilitating processing in advance of the receipt of the signed paper copies.

[0071] An alternative method for entering client data into the system, rather than by entering this data directly at a user's terminal, is to have the prospective applicant manually complete insurance and loan illustration request forms which may or may not have been generated at the user's terminal. The request form can be sent by mail or courier to the system operator and entered by the user into the computer system.

[0072] By means of the aforementioned computer system, this invention makes it possible for the first time to offer the American consumer a US mortgage arrangement which will perform like the endowment mortgage available in the United Kingdom. This mortgage/insurance financial product (referenced herein as the “Ryan Mortgage”) has innovative characteristics uniquely suited to the US legal environment, but without the drawbacks of LLOYD. Unlike LLOYD, the Ryan Mortgage is typically not a single financial product necessarily offered by a single seller (e.g., a lender). In a preferred embodiment, it is a combination of two or more different financial products offered by different suppliers (i.e., multiple lenders and multiple insurance carriers). Because the consumer, not the lender, is the owner of the life insurance policy, there is no cost containment clause in the Ryan Mortgage.

[0073] Also, the borrower owns the means for repaying the mortgage; the borrower may completely repay the mortgage without having to purchase the means for repaying the mortgage from the lender. Like the UK product, the key components to the transaction may include: a balloon repayment mortgage, life insurance coverage equal to the amount of the mortgage, and a separate vehicle for accumulating principal. Vehicles for accumulating principal might include a universal life insurance contract, an Individual Retirement Account, Keough Account, or zero coupon bond.

[0074] This description will focus on a preferred embodiment of the invention using as an investment a universal life insurance policy, but it is to be explicitly understood that other equivalent investments can be used as a means for repaying the mortgage, e.g., term life insurance with a zero coupon bond, IRA, Keough Account, or tax-deferred annuity, or some other (preferably tax-favored) means for producing secured revenue in conjunction with life insurance. Indeed, in another embodiment of the present invention, an investment for repaying the mortgage can be selected from any two or three of a group consisting of a life insurance policy, a security, and an annuity. Further, the mortgage repayment vehicle can comprise a plurality of these investments selected from the group.

[0075] As in the UK, a purchaser of a Ryan Mortgage will enjoy fully deductible mortgage interest payments over the life of the mortgage. Premium payments provide life insurance coverage, and tax-free growth of principal for the repayment of the mortgage.

[0076] Unlike the UK product or a conventional US mortgage, the Ryan Mortgage completely or partially replaces the traditional mortgage down payment with an insurance purchase. For example, to purchase a $262,000 home rather than pay $52,400 (20% of the home purchase price) as a down payment and borrow the remaining $209,600, the Ryan Mortgage home buyer pays $31,586 (12% of the home purchase price) to purchase a life insurance contract and borrows $262,000, the full purchase price of the home. The $31,586 life insurance investment provides paid up coverage for the remainder of the borrower's life. The policy also accumulates sufficient cash value to repay the $262,000 balloon payment mortgage loan when it comes due, for example, in thirty years. The borrower pays only monthly interest charges on the mortgage. Monthly mortgage payments do not include principal repayment. Monthly mortgage payments are one hundred percent tax deductible over the life of the mortgage. (See Specimen 2.)

[0077] Normally lenders are reluctant to provide financing for one hundred percent of the purchase price of a home and are unwilling to wait until the end of the mortgage for the repayment of principal. However, under the Ryan Mortgage, the lender has additional security: the real estate plus the insurance.

[0078] The Ryan Mortgage offers the borrower at least two premium payment methods. The first is a lump-sum prepayment. With a lump-sum prepayment, the home buyer deposits an amount sufficient to pay the first scheduled premium. He or she also deposits enough money to purchase an annuity contract that will pay three annual premium payments (for example) for the second through fourth years of the life insurance contract. For example, of the $31,586 payment described above, $8,916.16 would go to pay the first scheduled premium payment and $22,669.84 would go to purchase an annuity at the date of the mortgage closing. Over the next three years, the annuity will make the premium payment of $8,916.16 on the anniversary of the mortgage transaction. After making his or her lump-sum payment, the home buyer normally makes no further premium payments. While interest rates remain at or above the rate projected, these premium payments will be sufficient to ensure that the life insurance contract remains in force over the life of the mortgage. The premium is also large enough to assure that the policy will accumulate sufficient cash value to repay the mortgage by the end of the mortgage term. Normally, the lump-sum prepayment needed will be less than twenty percent of the purchase price of the home. (The standard down payment amount of a conventional home purchase is twenty percent of the purchase price.) Also, the after-tax monthly cost of the all-interest monthly mortgage payments will typically be less than or equal to the cost of a conventional mortgage with a similar down payment amount.

[0079] The second premium payment method involves the participation of a guarantor. A guarantor could be an employer wishing to provide a benefit for its employees to relocate for business purposes. Also, a guarantor could be a lender providing an irrevocable letter of credit in exchange for a fee. The guarantor provides financial assurances to the lender that the home buyer will make the annual insurance payments. In a guaranteed transaction, the homeowner's premium payment would usually be less than five percent of the purchase price of the home. For example, ten annual premium payments of $4,700.70 could provide adequate cash value to pay off the $262,000 mortgage obligation in the last year of the mortgage. A guarantor arrangement allows the home buyer to make a drastically reduced up-front payment. In this example, the first of ten annual premium payments, $4,700.70, amounts to 1.79% of the $262,000 home purchase price. However, the transaction will require the home buyer to make, for example, nine additional premium payments in upcoming years. These insurance payments are divided into monthly payments and paid into an escrow account. Thus, in the first years, the monthly cost to the prospective applicant will include these amounts which may inflate the Ryan Mortgage cost versus the conventional mortgage. Since the insurance premiums are typically lower for younger individuals, the Ryan Mortgage will be most attractive to that kind of person. Younger individuals, such as first time home buyers, are also the ones most likely to need the smallest possible up-front payment. (See Specimen 5 for sample system output.)

[0080] Under both premium payment plans, the borrower makes a collateral assignment of the policy to the lender or a third party endorser of the mortgage, such as a federal mortgage endorsement agency or a private mortgage insurance company. Under the terms of the collateral assignment agreement, the assignee has claim to the life insurance contract until the borrower repays the mortgage. When the borrower repays the mortgage, title to the home and the insurance policy vest in the borrower. If the borrower dies before the end of the mortgage term, the borrower's estate receives tax-free life insurance death benefit proceeds after deduction of the amount required to repay the mortgage obligation.

[0081] Should the home be sold for an amount which permits the mortgage to be paid out of the proceeds, the borrower will retain ownership of the life insurance contract. Such a life insurance policy has many uses. For example, the policyholder may use the policy as supplemental collateral for another mortgage and to replace the down payment in a subsequent home purchase and mortgage transaction.

[0082] Alternatively, the homeowner may not want to enter another Ryan Mortgage transaction. If so, he or she can keep the policy and take advantage of the many other benefits of a permanent life insurance policy. A policyholder may use the life insurance policy as a savings vehicle, a source of additional life insurance coverage, a source of cash for other obligations, or a means of financing retirement benefits. For example, the policyholder may pay additional premiums and enjoy tax-free accumulation of the invested principal. The policyholder may elect to reduce his or her coverage and withdraw cash from the policy via partial withdrawals or policy loans. Policy distributions can be used to pay for major expenses such as a new car, a medical emergency, or college tuition payments for children. If the policyholder no longer needs life insurance coverage, the policyholder can enter into a tax-free exchange of the life insurance policy. For example, the policyholder can exchange the life insurance policy for an annuity that provides monthly income in retirement.

[0083] The Ryan Mortgage has other unique features designed to maximize benefit to the consumer and minimize the after-tax cost of financing the mortgage. The homeowner may repay the mortgage in one of at least three ways at the end of the mortgage term. First, the homeowner may surrender the life insurance contract and use the proceeds of the policy surrender to pay off the mortgage. Under US tax law, presently, the policyholder must pay taxes on the interest income accumulated over the basis in the contract in the event of policy surrender. However, the policyholder will have had the benefit of tax-deferred accumulation of interest on the principal for up to forty years. Normally, cash value accumulated by the end of the mortgage will be sufficient to both repay the mortgage and pay the taxes on interest earnings.

[0084] Second, the homeowner may use a policy loan to pay off the mortgage. Life insurance contracts typically permit policyholders to borrow against the cash value of the life insurance policy. A policy loan differs from a mortgage or other loan from a lender in that the policy loan is non-recourse debt. The insurance company, in issuing the policy loan, has recourse only to the life insurance policy cash value. Under some policy loan provisions, as long as the policy cash value exceeds the policy loan balance, the policyholder need never pay interest on the loan, or repay the policy loan balance. When the policyholder dies, the policy loan is deducted from the policy death benefit and the insurance company will pay the net death benefit remaining to the policyholder's estate.

[0085] The advantage of a policy loan over a policy surrender has to do with the income tax effects of the two transactions. Proceeds from policy surrenders which are in excess of the basis (premiums) represent taxable income to the policyholder. On the other hand, policy loans are not taxable income to the recipient. Therefore, by using a policy loan to repay the mortgage, the homeowner can simply hold the policy until death. Using this method, the policyholder never has to pay taxes on the accumulated interest earned in the life insurance contract.

[0086] A third option may be available to the homeowner with a good credit record during the life of the mortgage. The homeowner may roll over the mortgage in the last year and hold it until death. By using life insurance policy loans at the beginning of each year to pay the annual mortgage interest, the policyholder keeps more money in the life insurance contract and maintains a higher death benefit than if the money had been used to pay off the mortgage immediately. This approach also allows the homeowner to maintain tax-deductible mortgage interest payments in retirement.

[0087] Further, as regards the insurance component of the present invention, and in accordance with the broad, general objects of this invention, a digital signal processing system processes and modifies electrical signals representing data to construct multiple universal life insurance quotes. Accordingly, the present invention involves processing information in a standardized manner, preferably to offer an individually selected universal life insurance product, the product being selected from a group of such products made available by different suppliers.

[0088] The system can, for example, be owned and operated by a suitably licensed national intermediary, for example, a broker or data processing company. The intermediary would work in conjunction with life insurance companies (and their agents and representatives) to design, develop, and distribute universal life insurance policies. The intermediary, operating nationally in cooperation with life insurance companies and utilizing the system provided by this invention, can facilitate the sale of the universal life insurance by agents accessing the system of this invention via remote terminals.

[0089] A user of the system can be an employee of the aforementioned intermediary providing illustrations requested by individuals outside of that firm. Alternatively, a user of the system can be an individual who has received special approval from the intermediary to use the system. (In a simplified version of the product, it is anticipated that an authorized user might even include a member of the general public, in states where the direct sale of insurance via computer is permitted.) A central processing unit in an electrical digital computer is at the heart of the system. The central processing unit can access a database into which data is written and from which data is read. That data includes information regarding life insurance, actuarial information, insurance premium information, and predetermined text data for incorporation into the insurance illustrations. The computer system further includes information corresponding to requirements of laws and regulations governing insurance.

[0090] At least one, preferably multiple terminals are provided for communicating with the central processing unit, each terminal having input means, such as a keyboard, and a display, such as a cathode ray tube (CRT) or a video display terminal (VDT). Each terminal is operable by a user to produce requests and to enter information and/or retrieve information for writing into and/or reading from the database via the central processing unit. The central processing unit provides a means for enabling access to the database in response to predetermined information entered at the terminal by the user and is suitably programmed to recognize particular authorized users.

[0091] In accordance with one desirable aspect of the invention, information regarding a life to be insured and other data needed to provide an illustration of a universal life insurance policy for that individual is keyed into the computer system user using a keyboard at a video display terminal. To assist the user in entering the appropriate data, a series of data comprising a “form” is displayed on the user's terminal by the central processing unit, and the user will normally proceed to enter pertinent information in the blanks provided. This information constitutes such things as the potential insured's name and address, the amount of the mortgage requested, the amount of life insurance coverage required, the individual's age, sex, and health status, and any other information necessary in providing an illustration of a universal life insurance policy. This information is correlated via the central processing unit, resulting in the signal processing generation of premium quotation. This information is then displayed at the user's terminal and can be printed out on the user's printer. Thus, a prospective applicant is quickly apprised of information pertinent to the policy such as (but not limited to) what the premium payment would be.

[0092] Once data called for by the “form” is entered into the computer system at the user's keyboard, a client information file or database record (hereinafter “client file”) is established which will be variously updated as the user conducts sensitivity analyses of the impact of different insurance-related assumptions on the ultimate amount of the premium payment. Once the prospective applicant decides to apply for a life insurance policy, a final version of the illustration is saved by the user in a master database file for later retrieval and processing.

[0093] After input data has been compiled in a client file, errors or omissions in that data (e.g., the amount of requested insurance may be too high, etc.) are detected. If these errors cannot be corrected immediately (for example, by supplying information from another file or record), further processing of the illustration request is suspended and the need for additional information is reported.

[0094] In the event that the prospective applicant wishes to proceed immediately to obtain the application for the insurance, the system is capable of taking the information stored in a final illustration database file, requesting a minimum of information otherwise not required in the illustration process (such as additional health information not taken in the initial illustration process) and merging it with prepared textual information about the insurance policy to generate printed application documents in a form acceptable to, and previously approved by, the insurance company. The system also permits the user to separately fill the forms out electronically. The application forms still can require signature by the prospective applicant, however. When signed, these forms are sent, for example, by mail or courier, to the system owner/operator (or carrier) for further processing. Should the prospective applicant wish to have this process expedited, the user may send the information on the signed forms electronically to a computer at the carrier, facilitating processing in advance of the receipt of the signed paper copies.

[0095] An alternative method for entering client data into the system, rather than by entering this data directly at a user's terminal, is to have the prospective applicant manually complete insurance illustration request forms which may or may not have been generated at the user's terminal. The request form can be sent by mail or courier to the system operator and entered by the user into the computer system.

[0096] By means of the aforementioned computer system, this invention makes it possible for the first time to offer the American consumer a universal life insurance policy which is verifiably the best policy to suit his or her needs. The need for such a capability is well documented: “There can hardly be a banker left in the United States who doesn't know that the insurance distribution system is costly, inefficient, and vulnerable to attack. There are more than 5,000 insurance companies in the United States, their products are sold one-on-one, and—although most of these products are commodities—their prices vary by hundreds of dollars,” American Banker, Oct. 3, 1985, Pg. 1. While many have discussed creating such a system, it was left to the present inventor to conceive of a way to make the present invention.

[0097] The following description, given by way of example and not intended to limit the present invention solely to the described embodiments, will be best understood in conjunction with the accompanying drawings, the computer or “user” screens, and specimens incorporated herein.

[0098] A. Figures

[0099] FIG. 1 is a schematic representation of the computerized insurance and mortgage illustration system of the present invention.

[0100] FIG. 2 represents a schematic flow chart of the logic behind the “main menu” (or user screen with a list of the functional choices that the computerized system provides to users) of the present invention.

[0101] FIG. 3 depicts the logic behind the illustration function of the present invention.

[0102] FIG. 3A-1 represents a schematic flow chart of the logic used in making standardized or “generic” illustrations designed to provide potential purchasers with examples of how the life insurance and mortgage combination might perform, according to the present invention.

[0103] FIGS. 3B-1-3B-8 provide a flow chart of the logic used in calculating and printing an individualized or “new” prospective applicant illustration tailored to the individual, and in creating a corresponding new prospective applicant data file, in accordance with the present invention.

[0104] FIG. 3C-1 provides a flow chart of the logic used in changing or updating an existing client data file for the purpose of providing the prospective applicant new illustrations based on assumptions which differ from those originally illustrated, in accordance with the present invention.

[0105] FIG. 3D-1 represents a flow chart of the logic used in electronically completing and/or printing a life insurance application form and storing the information contained on the insurance application form in a database of the host computer for later retrieval, in accordance with the present invention.

[0106] FIG. 3E-1 represents a flow chart of the logic used in electronically completing and/or printing a mortgage loan application form and storing the information contained on the mortgage loan application form in a database of the host computer for later retrieval, in accordance with the present invention.

[0107] FIG. 3F-1 represents a flow chart of the logic used to access the host computer for, and/or print out information regarding, new insurance product developments.

[0108] FIG. 3G-1 represents a flow chart of the logic used to access the host computer for, and/or print out information regarding, current loan rates and other mortgage-product related information.

[0109] FIGS. 3H-1-3H-2 provide a flow chart of the logic used in recalculating a homeowner's mortgage and premium payments in a given year after the mortgage transaction has been completed.

[0110] FIGS. 4-35C are schematic representations of the relationships between various data entities (database tables) within the database system of the present invention.

[0111] FIG. 5 is a representation of a computer user screen, User Screen 1, in accordance with the present invention.

[0112] FIG. 6 is a representation of a computer user screen, Screen 2 in accordance with the present invention.

[0113] FIG. 7 is a representation of a computer user screen, Screen 3 in accordance with the present invention.

[0114] FIG. 8 is a representation of a computer user screen, Screen 4 in accordance with the present invention.

[0115] FIG. 9 is a representation of a computer user screen, Screen 5 in accordance with the present invention.

[0116] FIG. 10 is a representation of a computer user screen, Screen 6 in accordance with the present invention.

[0117] FIG. 11 is a representation of a computer user screen, Screen 7 in accordance with the present invention.

[0118] FIG. 12 is a representation of a computer user screen, Screen 8 in accordance with the present invention.

[0119] FIG. 13 is a representation of a computer user screen, Screen 9 in accordance with the present invention.

[0120] FIG. 14 is a representation of a computer user screen, Screen 10 in accordance with the present invention.

[0121] FIG. 15 is a representation of a computer user screen, Screen 11 in accordance with the present invention.

[0122] FIG. 16 is a representation of a computer user screen, Screen 12 in accordance with the present invention.

[0123] FIG. 17 is a representation of a computer user screen, Screen 13 in accordance with the present invention.

[0124] FIG. 18 is a representation of a computer user screen, Screen 14 in accordance with the present invention.

[0125] FIG. 19 is a representation of a computer user screen, Screen 15 in accordance with the present invention.

[0126] FIG. 20 is a representation of a computer user screen, Screen 16 in accordance with the present invention.

[0127] FIG. 21 is a representation of a computer user screen, Screen 17 in accordance with the present invention.

[0128] FIG. 22 is a representation of a computer user screen, Screen 18 in accordance with the present invention.

[0129] FIG. 23 is a representation of a computer user screen, Screen 19 in accordance with the present invention.

[0130] FIG. 24 is a representation of a computer user screen, Screen 20 in accordance with the present invention.

[0131] FIG. 25 is a representation of a computer user screen, Screen 21 in accordance with the present invention.

[0132] FIG. 26 is a representation of a computer user screen, Screen 22 in accordance with the present invention.

[0133] FIG. 27A, which continues through FIG. 27E, represents a portion of an example of a printed specimen, Specimen 1, in accordance with the present invention.

[0134] FIG. 27B is a continuation from FIG. 27A and represents a portion of an example of a printed specimen, Specimen 1, in accordance with the present invention.

[0135] FIG. 27C is a continuation from FIG. 27A and represents a portion of an example of a printed specimen, Specimen 1, in accordance with the present invention.

[0136] FIG. 27D is a continuation from FIG. 27A and represents a portion of an example of a printed specimen, Specimen 1, in accordance with the present invention.

[0137] FIG. 27E is a continuation from FIG. 27A and represents a portion of an example of a printed specimen, Specimen 1, in accordance with the present invention.

[0138] FIG. 28A, which continues through FIG. 28J, represents a portion of an example of a printed specimen, Specimen 2, in accordance with the present invention.

[0139] FIG. 28B is a continuation from FIG. 28A and represents a portion of an example of a printed specimen, Specimen 2, in accordance with the present invention.

[0140] FIG. 28C is a continuation from FIG. 28A and represents a portion of an example of a printed specimen, Specimen 2, in accordance with the present invention.

[0141] FIG. 28D is a continuation from FIG. 28A and represents a portion of an example of a printed specimen, Specimen 2, in accordance with the present invention.

[0142] FIG. 28E is a continuation from FIG. 28A and represents a portion of an example of a printed specimen, Specimen 2, in accordance with the present invention.

[0143] FIG. 28F is a continuation from FIG. 28A and represents a portion of an example of a printed specimen, Specimen 2, in accordance with the present invention.

[0144] FIG. 28G is a continuation from FIG. 28A and represents a portion of an example of a printed specimen, Specimen 2, in accordance with the present invention.

[0145] FIG. 28H is a continuation from FIG. 28A and represents a portion of an example of a printed specimen, Specimen 2, in accordance with the present invention.

[0146] FIG. 28I is a continuation from FIG. 28A and represents a portion of an example of a printed specimen, Specimen 2, in accordance with the present invention.

[0147] FIG. 28J is a continuation from FIG. 28A and represents a portion of an example of a printed specimen, Specimen 2, in accordance with the present invention.

[0148] FIG. 29A, which continues through FIG. 29L, represents a portion of an example of a printed specimen, Specimen 3, in accordance with the present invention.

[0149] FIG. 29B is a continuation from FIG. 29A and represents a portion of an example of a printed specimen, Specimen 3, in accordance with the present invention.

[0150] FIG. 29C is a continuation from FIG. 29A and represents a portion of an example of a printed specimen, Specimen 3, in accordance with the present invention.

[0151] FIG. 29D is a continuation from FIG. 29A and represents a portion of an example of a printed specimen, Specimen 3, in accordance with the present invention.

[0152] FIG. 29E is a continuation from FIG. 29A and represents a portion of an example of a printed specimen, Specimen 3, in accordance with the present invention.

[0153] FIG. 29F is a continuation from FIG. 29A and represents a portion of an example of a printed specimen, Specimen 3, in accordance with the present invention.

[0154] FIG. 29G is a continuation from FIG. 29A and represents a portion of an example of a printed specimen, Specimen 3, in accordance with the present invention.

[0155] FIG. 29H is a continuation from FIG. 29A and represents a portion of an example of a printed specimen, Specimen 3, in accordance with the present invention.

[0156] FIG. 29I is a continuation from FIG. 29A and represents a portion of an example of a printed specimen, Specimen 3, in accordance with the present invention.

[0157] FIG. 29J is a continuation from FIG. 29A and represents a portion of an example of a printed specimen, Specimen 3, in accordance with the present invention.

[0158] FIG. 29K is a continuation from FIG. 29A and represents a portion of an example of a printed specimen, Specimen 3, in accordance with the present invention.

[0159] FIG. 29L is a continuation from FIG. 29A and represents a portion of an example of a printed specimen, Specimen 3, in accordance with the present invention.

[0160] FIG. 30A, which continues through FIG. 30L, represents a portion of an example of a printed specimen, Specimen 4, in accordance with the present invention.

[0161] FIG. 30B is a continuation from FIG. 30A and represents a portion of an example of a printed specimen, Specimen 4, in accordance with the present invention.

[0162] FIG. 30C is a continuation from FIG. 30A and represents a portion of an example of a printed specimen, Specimen 4, in accordance with the present invention.

[0163] FIG. 30D is a continuation from FIG. 30A and represents a portion of an example of a printed specimen, Specimen 4, in accordance with the present invention.

[0164] FIG. 30E is a continuation from FIG. 30A and represents a portion of an example of a printed specimen, Specimen 4, in accordance with the present invention.

[0165] FIG. 30F is a continuation from FIG. 30A and represents a portion of an example of a printed specimen, Specimen 4, in accordance with the present invention.

[0166] FIG. 30G is a continuation from FIG. 30A and represents a portion of an example of a printed specimen, Specimen 4, in accordance with the present invention.

[0167] FIG. 30H is a continuation from FIG. 30A and represents a portion of an example of a printed specimen, Specimen 4, in accordance with the present invention.

[0168] FIG. 30I is a continuation from FIG. 30A and represents a portion of an example of a printed specimen, Specimen 4, in accordance with the present invention.

[0169] FIG. 30J is a continuation from FIG. 30A and represents a portion of an example of a printed specimen, Specimen 4, in accordance with the present invention.

[0170] FIG. 30K is a continuation from FIG. 30A and represents a portion of an example of a printed specimen, Specimen 4, in accordance with the present invention.

[0171] FIG. 30L is a continuation from FIG. 30A and represents a portion of an example of a printed specimen, Specimen 4, in accordance with the present invention.

[0172] FIG. 31A, which continues through FIG. 31J, represents a portion of an example of a printed specimen, Specimen 5, in accordance with the present invention.

[0173] FIG. 31B is a continuation from FIG. 31A and represents a portion of an example of a printed specimen, Specimen 5, in accordance with the present invention.

[0174] FIG. 31C is a continuation from FIG. 31A and represents a portion of an example of a printed specimen, Specimen 5, in accordance with the present invention.

[0175] FIG. 31D is a continuation from FIG. 31A and represents a portion of an example of a printed specimen, Specimen 5, in accordance with the present invention.

[0176] FIG. 31E is a continuation from FIG. 31A and represents a portion of an example of a printed specimen, Specimen 5, in accordance with the present invention.

[0177] FIG. 31F is a continuation from FIG. 31A and represents a portion of an example of a printed specimen, Specimen 5, in accordance with the present invention.

[0178] FIG. 31G is a continuation from FIG. 31A and represents a portion of an example of a printed specimen, Specimen 5, in accordance with the present invention.

[0179] FIG. 31H is a continuation from FIG. 31A and represents a portion of an example of a printed specimen, Specimen 5, in accordance with the present invention.

[0180] FIG. 31I is a continuation from FIG. 31A and represents a portion of an example of a printed specimen, Specimen 5, in accordance with the present invention.

[0181] FIG. 31J is a continuation from FIG. 31A and represents a portion of an example of a printed specimen, Specimen 5, in accordance with the present invention.

[0182] FIG. 32A, which continues through FIG. 32L, represents a portion of an example of a printed specimen, Specimen 6, in accordance with the present invention.

[0183] FIG. 32B is a continuation from FIG. 32A and represents a portion of an example of a printed specimen, Specimen 6, in accordance with the present invention.

[0184] FIG. 32C is a continuation from FIG. 32A and represents a portion of an example of a printed specimen, Specimen 6, in accordance with the present invention.

[0185] FIG. 32D is a continuation from FIG. 32A and represents a portion of an example of a printed specimen, Specimen 6, in accordance with the present invention.

[0186] FIG. 32E is a continuation from FIG. 32A and represents a portion of an example of a printed specimen, Specimen 6, in accordance with the present invention.

[0187] FIG. 32F is a continuation from FIG. 32A and represents a portion of an example of a printed specimen, Specimen 6, in accordance with the present invention.

[0188] FIG. 32G is a continuation from FIG. 32A and represents a portion of an example of a printed specimen, Specimen 6, in accordance with the present invention.

[0189] FIG. 32H is a continuation from FIG. 32A and represents a portion of an example of a printed specimen, Specimen 6, in accordance with the present invention.

[0190] FIG. 32I is a continuation from FIG. 32A and represents a portion of an example of a printed specimen, Specimen 6, in accordance with the present invention.

[0191] FIG. 32J is a continuation from FIG. 32A and represents a portion of an example of a printed specimen, Specimen 6, in accordance with the present invention.

[0192] FIG. 32K is a continuation from FIG. 32A and represents a portion of an example of a printed specimen, Specimen 6, in accordance with the present invention.

[0193] FIG. 32L is a continuation from FIG. 32A and represents a portion of an example of a printed specimen, Specimen 6, in accordance with the present invention.

[0194] FIG. 33A, which continues through FIG. 33L, represents a portion of an example of a printed specimen, Specimen 7, in accordance with the present invention.

[0195] FIG. 33B is a continuation from FIG. 33A and represents a portion of an example of a printed specimen, Specimen 7, in accordance with the present invention.

[0196] FIG. 33C is a continuation from FIG. 33A and represents a portion of an example of a printed specimen, Specimen 7, in accordance with the present invention.

[0197] FIG. 33D is a continuation from FIG. 33A and represents a portion of an example of a printed specimen, Specimen 7, in accordance with the present invention.

[0198] FIG. 33E is a continuation from FIG. 33A and represents a portion of an example of a printed specimen, Specimen 7, in accordance with the present invention.

[0199] FIG. 33F is a continuation from FIG. 33A and represents a portion of an example of a printed specimen, Specimen 7, in accordance with the present invention.

[0200] FIG. 33G is a continuation from FIG. 33A and represents a portion of an example of a printed specimen, Specimen 7, in accordance with the present invention.

[0201] FIG. 33H is a continuation from FIG. 33A and represents a portion of an example of a printed specimen, Specimen 7, in accordance with the present invention.

[0202] FIG. 33I is a continuation from FIG. 33A and represents a portion of an example of a printed specimen, Specimen 7, in accordance with the present invention.

[0203] FIG. 33J is a continuation from FIG. 33A and represents a portion of an example of a printed specimen, Specimen 7, in accordance with the present invention.

[0204] FIG. 33K is a continuation from FIG. 33A and represents a portion of an example of a printed specimen, Specimen 7, in accordance with the present invention.

[0205] FIG. 33L is a continuation from FIG. 33A and represents a portion of an example of a printed specimen, Specimen 7, in accordance with the present invention.

[0206] FIG. 34A, which continues through FIG. 34B, represents a portion of an example of an application for life insurance, Specimen 8, in accordance with the present invention.

[0207] FIG. 34B is a continuation from FIG. 34A and represents a portion of an example of an application for life insurance, Specimen 8, in accordance with the present invention.

[0208] FIG. 35A, which continues through FIG. 35C, represents a portion of an example of a residential loan application, Specimen 9, in accordance with the present invention.

[0209] FIG. 35B is a continuation from FIG. 35A and represents a portion of an example of an application for life insurance, Specimen 9, in accordance with the present invention.

[0210] FIG. 35C is a continuation from FIG. 35A and represents a portion of an example of an application for life insurance, Specimen 9, in accordance with the present invention.

[0211] B. User Screens

[0212] User Screens 1-22 provide a representative group of screens shown on a monitor or other output device and produced by means of the computer system of the present invention. The User Screens can be seen by the system users as they prepare or update illustrations.

[0213] C. Variables, Identities, and Formulas

[0214] Variables, identities, and formulas which can be used throughout the illustration system are provided subsequently herein.

[0215] D. Specimens

[0216] Specimens 1-9 provide examples of printed product illustrations, a life insurance application form, and a mortgage application form which can be created by the present invention. The printed illustrations also include prepared textual information explaining the use of life insurance as collateral for a mortgage, life insurance policy information, mortgage information, and a comparison of these and other forms of financing.

[0217] Specimens 2-7 show an illustration of an investment, here exemplified as a life insurance policy, used as at least a partial replacement for a down payment, when contrasted with a conventional mortgage. (An illustration is a printed or visual representation of estimated values which permits a customer for or seller of a financial product to understand how that product will perform given a specified set of assumptions.) This investment/collateral/mortgage repayment means is owned by the home buyer.

[0218] The following description, given by way of example and not intended to limit the present invention solely to the described embodiments, will be best understood in conjunction with the accompanying drawings, computer or “user” screens, variables, and specimens incorporated herein.

[0219] A. Figures

[0220] FIG. 36 represents a schematic flow chart of logic behind a “main menu” (or user screen with a list of the functional choices that the computerized system provides to users) of the present invention.

[0221] FIG. 37A depicts logic behind an illustration function of the present invention, as continued in FIGS. 37B-1-37F-1.

[0222] FIG. 37B-1 is a portion of FIG. 37 that provides a flow chart of logic used in calculating and printing an individualized or “new” prospective applicant illustration tailored to the individual, and in creating a corresponding new prospective applicant data file, in accordance with the present invention.

[0223] FIG. 37B-2 is a portion of FIG. 37 that provides a flow chart of logic used in calculating and printing an individualized or “new” prospective applicant illustration tailored to the individual, and in creating a corresponding new prospective applicant data file, in accordance with the present invention.

[0224] FIG. 37B-3 is a portion of FIG. 37 that provides a flow chart of logic used in calculating and printing an individualized or “new” prospective applicant illustration tailored to the individual, and in creating a corresponding new prospective applicant data file, in accordance with the present invention.

[0225] FIG. 37B-4 is a portion of FIG. 37 that provides a flow chart of logic used in calculating and printing an individualized or “new” prospective applicant illustration tailored to the individual, and in creating a corresponding new prospective applicant data file, in accordance with the present invention.

[0226] FIG. 37B-5 is a portion of FIG. 37 that provides a flow chart of logic used in calculating and printing an individualized or “new” prospective applicant illustration tailored to the individual, and in creating a corresponding new prospective applicant data file, in accordance with the present invention.

[0227] FIG. 37B-6 is a portion of FIG. 37 that provides a flow chart of logic used in calculating and printing an individualized or “new” prospective applicant illustration tailored to the individual, and in creating a corresponding new prospective applicant data file, in accordance with the present invention.

[0228] FIG. 37B-7 is a portion of FIG. 37 that provides a flow chart of logic used in calculating and printing an individualized or “new” prospective applicant illustration tailored to the individual, and in creating a corresponding new prospective applicant data file, in accordance with the present invention.

[0229] FIG. 37B-8 is a portion of FIG. 37 that provides a flow chart of logic used in calculating and printing an individualized or “new” prospective applicant illustration tailored to the individual, and in creating a corresponding new prospective applicant data file, in accordance with the present invention.

[0230] FIG. 37B-9 is a portion of FIG. 37 that provides a flow chart of logic used in calculating and printing an individualized or “new” prospective applicant illustration tailored to the individual, and in creating a corresponding new prospective applicant data file, in accordance with the present invention.

[0231] FIG. 37C-1 provides a flow chart of logic used in changing or updating an existing client data file for the purpose of providing the prospective applicant new illustrations based on assumptions which differ from those originally illustrated, in accordance with the present invention.

[0232] FIG. 37D-1 represents a flow chart of logic used in electronically completing and/or printing a life insurance application form and storing the information contained on the insurance application form in a database of the host computer for later retrieval, in accordance with the present invention.

[0233] FIG. 37E-1 represents a flow chart of logic used to access the host computer for, and/or print out information regarding, new insurance product developments.

[0234] FIG. 37F-1 represents a flow chart of logic used in interpolating to find target universal life insurance illustration values.

[0235] FIG. 38A, which is continued to FIG. 38B, is a schematic representation of relationships between various data entities (database tables) within the database system of the present invention.

[0236] FIG. 38B is a continuation from FIG. 38A of the schematic representation of relationships between various data entities (database tables) within the database system of the present invention.

[0237] FIG. 39 represents a User Screen shown on a monitor or other output device and produced by means of the computer system of the present invention, to be seen by the system users as they prepare or update illustrations.

[0238] FIG. 40 represents a User Screen shown on a monitor or other output device and produced by means of the computer system of the present invention, to be seen by the system users as they prepare or update illustrations.

[0239] FIG. 41 represents a User Screen shown on a monitor or other output device and produced by means of the computer system of the present invention, to be seen by the system users as they prepare or update illustrations.

[0240] FIG. 42 represents a User Screen shown on a monitor or other output device and produced by means of the computer system of the present invention, to be seen by the system users as they prepare or update illustrations.

[0241] FIG. 43 represents a User Screen shown on a monitor or other output device and produced by means of the computer system of the present invention, to be seen by the system users as they prepare or update illustrations.

[0242] FIG. 44 represents a User Screen shown on a monitor or other output device and produced by means of the computer system of the present invention, to be seen by the system users as they prepare or update illustrations.

[0243] FIG. 45 represents a User Screen shown on a monitor or other output device and produced by means of the computer system of the present invention, to be seen by the system users as they prepare or update illustrations.

[0244] FIG. 46 represents a User Screen shown on a monitor or other output device and produced by means of the computer system of the present invention, to be seen by the system users as they prepare or update illustrations.

[0245] FIG. 47 represents a User Screen shown on a monitor or other output device and produced by means of the computer system of the present invention, to be seen by the system users as they prepare or update illustrations.

[0246] FIG. 48 represents a User Screen shown on a monitor or other output device and produced by means of the computer system of the present invention, to be seen by the system users as they prepare or update illustrations.

[0247] FIG. 49 represents a User Screen shown on a monitor or other output device and produced by means of the computer system of the present invention, to be seen by the system users as they prepare or update illustrations.

[0248] FIG. 50 represents a User Screen shown on a monitor or other output device and produced by means of the computer system of the present invention, to be seen by the system users as they prepare or update illustrations.

[0249] FIG. 51 represents a User Screen shown on a monitor or other output device and produced by means of the computer system of the present invention, to be seen by the system users as they prepare or update illustrations.

[0250] FIG. 52 represents a User Screen shown on a monitor or other output device and produced by means of the computer system of the present invention, to be seen by the system users as they prepare or update illustrations.

[0251] FIG. 53 represents a User Screen shown on a monitor or other output device and produced by means of the computer system of the present invention, to be seen by the system users as they prepare or update illustrations.

[0252] FIG. 54 represents a User Screen shown on a monitor or other output device and produced by means of the computer system of the present invention, to be seen by the system users as they prepare or update illustrations.

[0253] FIG. 55 represents a User Screen shown on a monitor or other output device and produced by means of the computer system of the present invention, to be seen by the system users as they prepare or update illustrations.

[0254] FIG. 56 represents a User Screen shown on a monitor or other output device and produced by means of the computer system of the present invention, to be seen by the system users as they prepare or update illustrations.

[0255] FIG. 57 represents a User Screen shown on a monitor or other output device and produced by means of the computer system of the present invention, to be seen by the system users as they prepare or update illustrations.

[0256] FIG. 58 represents a User Screen shown on a monitor or other output device and produced by means of the computer system of the present invention, to be seen by the system users as they prepare or update illustrations.

[0257] FIG. 59 represents a User Screen shown on a monitor or other output device and produced by means of the computer system of the present invention, to be seen by the system users as they prepare or update illustrations.

[0258] FIG. 60 represents a User Screen shown on a monitor or other output device and produced by means of the computer system of the present invention, to be seen by the system users as they prepare or update illustrations.

[0259] FIG. 61A, which continues through FIG. 61E, represents a portion of an example of a printed product illustration prepared in accordance with the present invention.

[0260] FIG. 61B, represents a portion of an example of a printed product illustration prepared in accordance with the present invention.

[0261] FIG. 61C, represents a portion of an example of a printed product illustration prepared in accordance with the present invention.

[0262] FIG. 61D, represents a portion of an example of a printed product illustration prepared in accordance with the present invention.

[0263] FIG. 61E, represents a portion of an example of a printed product illustration prepared in accordance with the present invention.

[0264] FIG. 62 represents an example of a printed product illustration prepared in accordance with the present invention.

[0265] FIG. 63A, which continues through FIG. 63B, represents an example of a printed life insurance application form prepared in accordance with the present invention.

[0266] FIG. 63B, which continues FIG. 63A, represents an example of a printed life insurance application form prepared in accordance with the present invention.

[0267] B. User Screens

[0268] User Screens 23-42 provide a representative group of screens shown on a monitor or other output device and produced by means of the computer system of the present invention. The User Screens can be seen by the system users as they prepare or update illustrations.

[0269] C. Variables, Identities, and Formulas

[0270] Variables, identities, and formulas which can be used throughout the illustration system are provided subsequently herein.

[0271] It should be kept in mind that such variables, identities, and formulas are not the present invention—rather, they are convenient ways of characterizing the electrical signal modification being accomplished by the digital electrical signal processing system of the present invention, as defined in the claims herein.

[0272] D. Specimens

[0273] The specimens provide examples of printed product illustrations, and a life insurance application form. It should also be kept in mind that the present invention, as defined in the claims, is not merely a printed publication or a business—rather, the claimed invention is a tool having utility in commercial, scholarly, and other applications.

[0274] Because the present invention is directed at modifying electrical signals in a computer system having a processor, such as a microprocessor, to understand how the signals are modified, a basic understanding of computer science and electrical engineering is useful. It is well known in the art of computer science that it is a trivial technical exercise to go from hardware to software or vice versa. See, for example, James R. Goodman, Todd E. Marlette, and Peter K. Trzyna, “The Alappat Standard for Determining That Programmed Computers are Patentable Subject Matter,” J.P.T.O.S. October 1994, Volume 76, No. 10, pages 771-786, and James R. Goodman, Todd E. Marlette, and Peter K. Trzyna, “Toward a Fact-based Standard for Determining Whether Programmed Computers are Patentable Subject Matter,” J.P.T.O.S. May 1995, Vol. 77, No. 5, pages 353-367, both of which are incorporated by reference. A copy of source code is also included herewith and incorporated by reference herein, the source code including files that can be catagorized by their file extensions as follows: .INP—Oracle Forms 3.0; PC—Oracle ProC; C—“C” language; .H—“C” language header; and .TXT—control files used to link and\or run the programs.

[0275] A. Discussion of Figures (FIGS.) and User Screens

[0276] The following is a description of a preferred embodiment and best mode of the invention. The following includes a description of the manner in which the computerized insurance system of the present invention can be made and used. Some of the unique insurance and mortgage transactions that are carried out by this system are described in detail. Other transactions are described more generally. In the interest of brevity, a highly detailed description of each and every one of the data transactions that may be performed by the computerized system of the present invention is not provided. But based upon the detailed description of certain examples, and the knowledge of those familiar with the life insurance industry and the mortgage lending industry, how to make and use the present invention should be readily apparent from the information provided herein.

[0277] Generally, in the computations underpinning the use of a mortgage in conjunction with life insurance as collateral, there is a computer system for producing an illustration of an investment as a means for repaying a mortgage. The system includes a digital computer for receiving input data and for storing borrower information and investment information. The digital computer is programmed with means, responsive to the data, the borrower information, and to the investment information, for computing an amount of investment funding sufficient to repay the mortgage and for generating an illustration of said investment as a means for repaying the mortgage. Further, the computer system is devoid of means for generating an illustration of a mortgage plan having a cost containment clause.

[0278] More particularly, the computer system requests that a user input data specifying the kind of mortgage and the kind of insurance policy (e.g., or some equivalent financial vehicle) to be illustrated. This information is stored in the computer's database system. Also, the computer is programmed to make calculations of loan and insurance values and other data needed for the illustration. When all the values have been computed and written to the database, the computer will then combine them with text data to provide an illustration that can be printed out. This information will also be stored in a database and may be updated as needed.

[0279] Once the user, in consultation with a prospective borrower, has designated the illustration as complete, data in the database can be merged with stored text data and other input data in order to produce loan and insurance application forms. These forms can be printed out on the user's printer for signature by the prospective applicant and for subsequent processing by the system operator, the life insurance carrier, and the lender.

[0280] FIG. 1 shows an overview of a data processing system for producing an insurance policy/mortgage illustration according to the present invention. The Data Screen 4, discussed more fully hereinafter, can be produced on Terminal 2, for example an IBM compatible PC running Smarterm 340 (available from Persoft Corp.), with a Local Printer 5, e.g., a laser printer. Terminal 2 is linkable to Communications System 6. The Communication System 6 can be a modem and appropriate telephone lines. Communications System 6 is thus linkable to a Digital Computer 8, for example, a Digital Equipment Corporation VAX with a VMS operating system, ORACLE, and WordPerfect (e.g., 5.1) from WordPerfect Corporation. Digital Computer 8 is operably connected to Central Printer 9. The Digital Computer 8 contains a Central Processor 10 that is operable to obtain Loan/Insurance Product Information 12, Loan Rate Information 14, and Insurance Premium Information 16. The respective information of Blocks 12, 14, and 16 can optionally be accessible on line to other computers or stored as data in a System Database 17 of the Digital Computer 8.

[0281] Help 18 is a computerized system, preferably a context sensitive, hypertext-linked help system. Help 18 is available throughout the program.

[0282] Central Processor 10 is also operable to activate a function Print Out Loan/Insurance Application Forms 22 on Central Printer 9, which points to the function Fill In Forms 24 to selectively transmit Loan Application Data To Lender 26 and Life Insurance Application Data To Carrier 28.

[0283] Further, Central Processor 10 can generate an illustration via a function Generate Illustration 30, which leads to Print Illustration 32 On Local Printer 5. The generated illustration can be saved in the Database 17.

[0284] When the system is accessed, the user must choose the transaction desired, and the selection will vary by the type of user. A management level user with a higher level of authority can update the data used in the illustration process. This data includes, but is not limited to: (1) current interest rates and other charges for loans offered by the lenders wishing to provide loans collateralized with life insurance; (2) insurance underwriting related values, including age, sex, and health characteristics, premium amounts to be applied, cash value accumulation, annual death benefit amounts, and typical policy interest crediting rates and insurance charges; (3) all of the illustrations saved in the Database 17 which may be used for manipulation and analysis in both the marketing and underwriting functions carried out by an insurance agent, a carrier, and a lender; and (4) administrative messages from other users. Otherwise, a non-management user of the system has access to only a portion of the system.

[0285] Prior to engaging the computerized aspects of the present invention, the user should consult with the prospective applicant to obtain such information as the prospective insured's age and sex, the amount of the mortgage desired, the individual's ability or willingness to provide a down payment on the property, the individual's employment status, whether or not the individual has certain health problems which may require specialized insurance underwriting, whether or not the individual's employer is currently involved in a program that will guarantee the payment of policy premiums, etc. After this information-gathering step has been completed, the user “logs” on at Terminal 4 by entering an assigned authorization password.

[0286] Turning now to FIG. 2, the user engages the system at Sign On To System 34. Branch 36, Authorized To Use System?, checks the password against stored passwords to determine whether the user is authorized to use the system. If the user is not authorized, Block 38 displays a message on the Terminal 2 that the user should telephone the system owner/operator for further information. If the user is authorized, meaning that the password is recognized by the Digital Computer 8, the logic continues to Branch 40. However, prior to Branch 40, there is a logic entry point X1, which is described more fully below, but which generally is a connection from another part of the logic.

[0287] In any case, Branch 40 assesses the level of authority of the user from the password. In the present embodiment of the invention, there are two alternatives. First, as previously suggested, the user could be a “Client User,” in which case the logic connects to Illustration 42, as is subsequently discussed. Second, the user could be a “Super User,” having access to Main Menu 44.

[0288] The Client User/Super User authorization system is included in a preferred embodiment of this invention to avoid security problems which would otherwise be created by a diverse number of users using the system. It also provides for confidentiality of database information and, in the case of communications between the system owner/operator and users, allows each user to view only the information relating to the applicants for whom the user is providing illustrations.

[0289] From the Main Menu 44, if the user does not yet wish to log off at Block 48, there are a number of choices shown in User Screen 1.

[0290] The Main Menu 44 permits access to Illustration 42 used to create an illustration (Generic, New, or Existing). The user can also select Update Database 50, which is described with particularity hereinafter, but which generally is a list of tables that can be updated. A typical Update Database 50 screen is shown in User Screen 2.

[0291] The user can select Analyze 54 to access various reports and statistics on illustrations. Electronic Mail 52 permits electronic communication between system users (see FIG. 1). Mail messages may be printed out via the Printers 5 and 9.

[0292] Returning to FIG. 2, the Electronic Mail 52 function utilizes the VMS operating system mail feature. The system has the ability to alert the user that a message is present in his or her electronic “mail box.” The system is capable of reading these messages from that file onto the user's screen, again allowing the user to move from screen-to-screen at his or her own speed. Once the user has completed a review of the data, one or all of the textual screens or “pages” may be printed at the Local Printer 5. The user may also write electronic messages to other users' mail boxes to be used in a similar manner.

[0293] At the completion of each subordinate function 42, 50, 52, 54, and 18, control is returned to the Main Menu 44 via the Return To Main Menu Block 46.

[0294] Turning now to FIG. 3 where the logic proceeds from Illustration 42 of FIG. 2, the user is presented with a Select Type Of Illustration 56 submenu, shown as a portion of User Screen 1. Each of the functions of the submenu of Branch 56 will be presented in summary form here and described subsequently in detail. One function is Generate Generic Illustration 58, which is elaborated by FIG. 3A-1. Generally, Function 58 permits the user to quickly provide an illustration of how a mortgage using life insurance as collateral might work for a standard mortgage amount. By limiting the number of variables and illustrating a standard amount, this Function 58 allows the user to quickly provide the prospective applicant with enough information to decide whether a mortgage using life insurance as collateral might be of interest. The information created in this Function 58 can be sent directly to the Local Printer 5 for review by the prospective applicant.

[0295] A second function under Submenu 56 is Generate New Applicant Illustration 60, which goes to FIG. 3B-1. This Function 60 permits the user to provide a detailed presentation, tailored to the prospective applicant's own factual situation, of how a mortgage using life insurance as collateral might perform for the prospective applicant. This Function 60 also allows the user to save the illustration for later updates and to send the illustration to the Local Printer 5 for review by the prospective applicant.

[0296] A third function of Submenu 56 is Update Existing Illustration 62, which goes to FIG. 3C-1. This Function 62 permits the user to update a previously saved prospective applicant illustration using different assumptions. This Function 62 also allows the user to quickly create an illustration which is different from one already saved by allowing the user to change only those few items that the prospective applicant may select, thereby avoiding the laborious process of entering all of the information required to create a new prospective applicant illustration. This Function 62 likewise allows the user to save a new illustration for later updates and to send the illustration to the Local Printer 5 to permit review by the prospective applicant.

[0297] Returning to FIG. 3, once the illustration has been compiled, the system presents a sequence of further options. Print Life Insurance Application 64, goes to FIG. 3D-1. This Function 64 allows the user to: (1) take the information generated and saved in the aforementioned illustration process, add to it, and merge it with life insurance application form text data to construct a customized, printed life insurance application form for signature; (2) electronically save in a file the customized life insurance application form; or (3) print out a partially completed or blank life insurance application form for later manual completion by the prospective applicant.

[0298] Print Loan Application 66 goes to FIG. 3E-1. This Function 66 allows the user to: (1) take the information generated and saved in the aforementioned illustration process, add to it, and merge it with loan application form text data to provide a customized, printed loan application form for signature; (2) electronically save in a file the customized loan application form; or (3) print out a partially completed or blank loan application form for later manual completion by the prospective applicant.

[0299] In another embodiment of the present invention, a Block can be added at this point to perform the analogous function for a securities brokerage account application form to permit use of a security and/or an annuity as the investment to repay the mortgage.

[0300] Review Insurance Product Developments 68 goes to FIG. 3F-1. This Function 68 allows the user to be quickly apprised of new developments in the insurance products used in forming the illustrations including, but not limited to, changes in interest rates credited by carriers on cash value reserves in the life insurance policies, new underwriting rules, new products provided by different carriers, etc. This information is available inside the Generate New Applicant Illustration 60 and Update Existing Applicant Illustration 62 functions. Information may be read from the screen or printed out.

[0301] Review Loan Rates 70 goes to FIG. 3G-1. This Function 70 allows the user to be quickly apprised of current loan rates and other timely product information from lenders. This information coincides with the Generate New Applicant Illustration 60 and Update Existing Applicant Illustration 62 functions. Information may also be read from the data screen 4 or printed out.

[0302] With further reference to FIG. 3, it should be noted that, in another embodiment of the present invention, the computer system is modified to accommodate other species of investment for repaying the mortgage. The modifications would include adapting FIG. 3, particularly Blocks 58, 60, and 62, to consider these additional investments. These other investments can include, for example, joint or joint and survivor life insurance, insurance (such as term insurance) in combination with an annuity or securities (for example, a zero coupon bond), an Individual Retirement Account (IRA), or a Keough Account. In the interest of brevity, this application will not delve into each of these variations on the theme of a preferably tax-exempt repayment vehicle for serving as partial down payment and the means for repaying the mortgage. A suitably skilled computer programmer would recognize from the detailed description of the logic, user screens, specimens, and text discussion herein, that the logic would simply be modified to focus on distinctive features of the other repayment vehicle(s). Thus, for example, the alternate embodiment of the computer system would be adapted to obtain data and compute information sufficient for determining how and when the repayment vehicle will pay off the mortgage. The data can be obtained, for example, in a manner parallel to that described in Insurance Premium Information 16 or via modem, for example, from a plurality of stock brokers. There would be means for generating an illustration of such an investment, along with investment implementing documentation, brokerage account applications, etc. Similarly, the logic described herein can be modified to reflect different mortgage products. These can include fixed and variable rate mortgages with negative or positive amortization. While the fixed rate mortgages would be handled by means for computing fixed rate mortgage payments, an adjustable rate mortgage would be more complicated, having a means for computing extra amortization of mortgage principal when interest rates are low, and negative amortization when interest rates are high. The cash value accumulation can be treated as an offset to negative amortization.

[0303] Turning now to FIG. 3A-1, the Generate Generic Illustration 58 function is illustrated. The Function 58 begins with User Screen 3 via Block 72, which asks the user to input the age and sex of the prospective client. A Ryan Mortgage involves the payment of monthly interest only on the loan, with repayment of principal at the end of the mortgage term. Conventional amortization mortgages, on the other hand, involve a gradual repayment of principal over the term of the mortgage. Since a preferred embodiment of this invention involves the illustration of how accumulated life insurance cash values may be used to pay off the mortgage at the end of the mortgage term, the amount and timing of the principal repayment is an important variable in the presentation of mortgage alternatives.

[0304] The specification of age and sex is appropriate, even for an illustration designed to show only average or hypothetical insurance values, i.e., values not entirely tailored to the individual prospective applicant. This is because the statistical probability of the insured's death (and hence the amount the insurance carrier must charge policyholders in order to have adequate reserves for the payment of policy death proceeds) varies according to the age and sex of the individual insured. This in turn has an important impact on how the policy is designed and has an ultimate bearing on the price and term for policy premium payments.

[0305] User Screen 3, via Block 72 in FIG. 3A-1, also asks the user to select whether the life insurance premiums are to be paid in a lump-sum prepayment, which is a single premium payment plus (at least) three premiums prepaid with the purchase of an annuity. This minimum number of premium payments is required under present law to avoid treatment of the policy as a modified endowment contract. The system automatically preselects these amounts: (1) to assure that the policy conforms to US tax regulations and avoids modified endowment contract status under IRC Section 7702A(b) (thereby assuring that the policyholder avoids costly tax penalties in the event of policy surrender); and (2) to assure that the life insurance cash value will be sufficient to provide an amount of collateral which will be acceptable to prospective lenders.

[0306] In addition, User Screen 3, Block 72 in FIG. 3A-1, asks the user to select the preferred mortgage repayment plan. Each plan offers distinct financial advantages to the prospective applicant and allows him or her to select the plan that best suits his or her needs.

[0307] Block 73 allows the user to modify any of the default generic data to more closely parallel the prospective applicant's situation. This allows for a more personalized generic illustration, without requiring the prospective applicant to complete the more thorough Generate New Applicant Illustration 60.

[0308] User Screen 4 depicts Submenu 73, also known as the Generic Supermenu. After modifying whatever data the prospective applicant wishes to change, Block 74 saves the data. Block 74 also finds loan rates from the Database 17, Block 76 gets the average loan rates, and Block 78 gets average closing costs.

[0309] Retrieve Average Closing Costs 78 uses an average loan closing cost based on the amount of the mortgage by consulting the database of average closing costs, as measured, for example, by the Department of Housing and Urban Development or some other reliable source of statistics on the costs involved in completing a home purchase transaction.

[0310] Proceeding to FIG. 3B-4, the insurance illustration system can be designed so that the same computer can be used to provide product illustrations for the insurance products of different carriers. In this embodiment of the invention, the system offers maximum flexibility so that it may accommodate virtually any life insurance policy and/or annuity. In a preferred embodiment of the invention, the system also provides many tables for product-specific data such as mortality tables, expense charges, interest rates, and other insurance related data. These tables can be used to store the different components of the carriers' products. Product specific “flags” or identifiers in the insurance computation formulas can be used to provide maximum flexibility in the way the system makes insurance computations. This allows the system to offer a method of customizing computations that are common to all life insurance products. This feature also makes it possible for a single computer to efficiently provide multiple life insurance product illustrations for multiple life insurance carriers. (In another embodiment of the invention, the system can use front-end network gateways to connect multiple carriers' computers to the Digital Computer 8.)

[0311] The system maintains security by affording limited access to carrier-specific databases. The system provides carriers exclusive access to their own databases, for example, via modem, by requiring a password. Only individuals authorized by the carrier can access or see the carrier's databases.

[0312] In the case of a generic illustration, Block 80 leads to Block 82, which solicits a selection of the best product criteria. Criteria solicited by the system in Block 82 might include, for example, minimum initial or minimum monthly costs to the borrower. These criteria are subsequently used by the system to find the best product. The system also stores the selection in Database 17, via Block 84.

[0313] However, if the user selected Generate New Applicant Illustration 60 in FIG. 3 instead of Generate Generic Illustration 58, the user would have selected a product displayed on the User Screen 2. The system stores either the product displayed in FIG. 3B-3 or the product found in FIG. 3B-3 in Blocks 90 and 84, respectively.

[0314] Blocks 92 and 86 identify a count of products to be illustrated and Block 94 initializes a counter to keep track of the number of products being illustrated. Solicit Premium Payment Plan 96 solicits the mortgage repayment plan, unless this data has already been selected as part of the generic illustration in User Screen 3.

[0315] The insurance illustration aspect of the present invention involves computing the amount of up-front payments required to obtain an insurance policy that will, after N years (typically thirty), have sufficient cash value to repay the mortgage. Given the selection of how the user premium payments will be made, the user must select how the mortgage will be repaid in Block 98. Under existing law, the mortgage can economically be repaid in one of three ways. The policyowner may surrender the contract and use policy proceeds to repay the mortgage. In this case, the system assigns a value of 0 to the mortgage repayment variable, LOPT, in Block 98. The policyowner may use a policy loan to repay the mortgage and plan to hold the life insurance contract until death. In this case, LOPT is set equal to 1. Alternatively, the policyholder may hold the mortgage and life insurance policy until death, using annual policy loans to pay the mortgage interest, in which case LOPT is set equal to 2. The user may select any combination of the premium payment and mortgage repayment options at the outset of the illustration process.

[0316] There is no formula for the correct premium amount. Instead, in FIG. 3B-5, the system uses formulas that project a cash value amount corresponding to a given premium amount and premium payment plan. The system tests this cash value amount to see if it falls within the system's mortgage repayment guidelines as defined in Blocks 102 and 104 of FIG. 3B-4. (Separate guidelines exist for each mortgage repayment plan.)

[0317] Turning now to FIG. 3B-5, at Block 106, the system retrieves from Database 17 carrier product information. Block 108 uses this information to make a first trial annual premium, and the remainder of FIG. 3B-5 tunes the trial premium to make it more accurate. If the projected cash value falls outside system parameters in Block 112 and if this is the first trial in Block 114, the system selects another trial premium amount above or below (as is discussed more fully hereinafter) the first trial premium in Block 116 and produces another cash value estimate in Block 110.

[0318] Because various insurance expenses are variable in ratio to the premium and policy cash value, the system does not depend on scaling. Instead, the system uses bracketing (i.e., finding a value above, and a value below, a target value). The system finds two premium/cash value pairs that bracket the desired goals in Block 118, and can use bisection or Newton's method to find the desired premium amount. That is, in the second pass through Branch 112, if the target is not met, Branch 114 is “no” (as it is not the first trial). Block 118 tests whether the first and second trial premiums bracket (fall above and below) the target. If not, Block 116 generates a third trial premium, etc., until the target is bracketed. If at Branch 122 the system has found two bracketing trial premium amounts, Block 124 then finds a third trial premium via bisection or Newton's method. To accelerate convergence, if at Branch 122 the system has found three trials, from then on, the system uses quadratic interpolation in Block 126 to find the next trial premium. The system replaces the more outlying trial with the new one, and conducts another iteration. Once the target is met in Branch 112, the monthly premium amount is stored via Block 120, and the logic goes to FIG. 3B-6.

[0319] The two premium payment plans have two system defaults, although others may be used at the discretion of the system owner/operator. For a sponsored transaction in which a corporation or financial services institution guarantees the payment of premiums, the default number of premium payments is ten. The home buyer pays one as part of the mortgage closing, and pays the remainder in monthly installments to a lender escrow account over the next nine years. For a lump-sum prepayment of the premium, the default number of premiums is four. One is payable at closing, and the rest are prepaid by an annuity purchased at the closing. The system ignores the annuity cost calculation until it has solved for the correct four premium payment amounts. (Specimens 2-4 show sample illustrations assuming lump-sum prepayment of the premium, and specimens 5-7 show illustrations assuming sponsored mortgage transactions.)

[0320] More particularly in Blocks 106 and 108, the first way the mortgage can be repaid is by surrendering the policy. In searching for this amount, the system will iteratively solve for an amount of cash value targeted in FIG. 3B-4, Block 104. This amount will repay the mortgage assuming the policyowner/borrower surrenders the policy at the end of the last year of the mortgage. To arrive at the appropriate cash value amount, the system will iteratively repeat the following six steps until it arrives at a premium amount that will generate an after-tax cash surrender value equal to the mortgage principal:

[0321] 1) Select a premium amount, based on a first trial;

[0322] 2) Use the selected premium amount to compute a cash value in the Nth year of the mortgage;

[0323] 3) Compute a life insurance policy basis by adding up cumulative premiums over the life of the mortgage;

[0324] 4) Subtract the basis from a total cash value projected in the Nth year of the policy to arrive at the taxable gain in the policy;

[0325] 5) Multiply the taxable gain by one minus the customer's tax rate to arrive at the customer's net after-tax gain; and

[0326] 6) Add the basis back to the net after-tax gain to arrive at the after-tax cash surrender value.

[0327] For example, assume the amount of the mortgage is $262,000 and the homeowner's expected tax rate in year thirty of the mortgage is thirty-four percent. The system will iteratively solve until it arrives at a premium amount of $35,664.64 ($8,916.16 annually for four years) and a cash value amount of [($378,608.59−$35,664.64)×(1−0.34)]+$35,664.64=$262,007.64. (Specimen 2 shows sample output for this mortgage and the LOPT=0 mortgage repayment method. Specimen 5 shows sample output for this mortgage assuming a sponsored premium payment plan and LOPT=0).

[0328] The second way in which the mortgage may be repaid is using a life insurance policy loan. This illustration assumes that the policyholder elects to take a policy loan against the cash value of the policy in the last year of the mortgage. Then the policyholder uses the proceeds of the policy loan to repay the borrowed mortgage principal. In this way the homeowner is converting debt with recourse (the lender has recourse to the mortgaged property and the life insurance policy) to non-recourse debt (the insurance company has recourse only to the life insurance policy).

[0329] With this second method of mortgage repayment, the system at Blocks 106 and 108 uses a different definition of adequate cash value in Block 102. The adequate cash value amount is enough to allow the policyholder to maintain the policy until death. The system assumes death at age ninety-five or ninety-nine, depending on the requirements of the specific policy being illustrated. For the policy to remain in force until that age, both the policy cash value and death benefit must always exceed the outstanding policy loan balance. Policy loan balances grow in tandem with cash values. Rather than pay each year's policy loan interest, the policyholder may elect to add this interest to the policy loan principal as additional policy borrowing. By means of a default, the system assumes that the policyholder never repays the policy loan and holds the policy and policy loan until death. (Specimen 3 shows sample system output for such a mortgage, a lump-sum prepayment, and LOPT=1. Specimen 6 shows the same transaction assuming a sponsored transaction.)

[0330] In the example described above, the system illustrates the policyholder receiving a policy loan equal to $262,000 in the Nth year of the life insurance contract. This amount is enough to repay the mortgage on the home. The policy loan eliminates the mortgage obligation. The terms of the life insurance contract illustrated might call for a policy loan rate of 9.5%. The system would then project the policy loan interest equal to $24,890 at the end of the N+1st year of the life insurance contract. At the beginning of the N+2nd year, the policy loan interest for the previous year would be added to the policy loan and the new policy loan balance would be $286,890. For the N+2nd year, the system would calculate policy loan interest based on the current year's policy loan balance of $286,890. The policy loan interest would therefore be $27,254.55 in the N+2nd year. At the beginning of the N+3rd year, this would be added to the policy loan balance. The system would repeat this procedure until the final year of the illustration, when the insured reaches age ninety-five or ninety-nine.

[0331] The system projects cash value amounts which may be adjusted by the policy loan balance. The system guideline or target cash value for this computation is the cash value balance net of policy loan balances and accrued policy loan interest. This amount must be slightly greater than zero in the policy year that the insured would have his or her ninety-ninth birthday. The invention allows for two different rates at which interest will be credited toward cash value balances. The first rate is the unloaned funds credited rate, which is the rate credited on policy cash values not subject to liens from policy loans. The second rate is the loaned funds credited rate, which is the rate earned on that portion of the cash value that the policy has borrowed against.

[0332] Returning to the above example, assume that the system lowered its initial premium plus annuity payment to $26,151. The system now projects the cash value to be $302,973.30 in the thirtieth year of the mortgage. After the homeowner uses the $262,000 policy loan to pay off the mortgage obligation, the cash value will remain at $302,973.30. However, by year 30 the remainder will be equal to $40,973.30 net of policy loans. This amount, $40,973.30 net of policy loans, will earn interest at an unloaned funds credited rate. The $262,000 in cash value nominally collateralizing the policy loan will earn interest at a loaned funds credited rate.

[0333] In most universal life insurance policies the loaned funds credited rate is much lower than the policy loan interest rate. This creates a negative arbitrage or “spread” between the interest earned and interest paid within the two accounts of the policy. Because of this negative spread, policy loan balances typically grow much more quickly than the policy cash value. After a few years, policy debt will exceed cash value. At this time, the policyholder must either pay additional premiums, reduce the policy loan balance, or allow the life insurance policy to lapse. Using the above example, assume the individual requesting the illustration is a male aged thirty-two at the time of the illustration. Assume further that the loaned funds credited rate is a full three percentage points less than the 9.5% policy loan rate. Here again the system will compute the policy cash value as $302,973.30 in year 30. However, by year 36 of the policy, the policy loan balance plus outstanding policy loan interest would be $451,633.35, while the policy cash value would be $440,503.71. This would force the policyholder to pay additional premium payments or allow the policy to lapse (and pay the tax consequences) in the following year.

[0334] On the other hand, assuming a zero spread policy loan, by the end policy of year 36, the policy cash value would be $511,955.57. The policy loan balance plus outstanding policy loan interest would again be $451,633.35, yielding a net cash value of $60,322.21. Assuming constant interest rates and mortality charges, the policy would remain in place until the insured's assumed death at age ninety-nine when the net cash value would be $354.43. So long as interest rates remain relatively constant, no further premium payments are required of the insured.

[0335] Low or zero spread policy loans have been available to policyholders in the past. However, their use has been limited previously to key-man or corporate owned life insurance policies. They have not heretofore been used in conjunction with home mortgages in accordance with the teachings of the present invention, wherein a system illustrates, monitors, and administers these policy cash values and policy loan balances efficiently and at low cost. This capability permits carriers to offer prospective applicants a low or zero spread policy loan for use in the repayment of mortgages. Such a spread is preferably less than 300 basis points. The use of these smaller spreads minimizes the ratio of cash value to policy loan value required to keep the policy in force over the life of the policy. This, in turn, reduces the amount of up-front premium payments required in the funding of the transaction.

[0336] The third illustration option (LOPT=2) is computed using the target cash value for the zero-spread/low spread policy loan option described above (LOPT=1) and computed in Block 102. This is because it assumes a roll-over of the mortgage obligation. In this scenario, at the end of the term of the mortgage, the homeowner requests a new mortgage. The lender will approve such a transaction subject to a second credit review and collateral evaluation in the last year of the mortgage. The system therefore calculates an amount of premium plus annuity ($26,151) which will provide for repayment of the mortgage in the Nth year (assuming LOPT=1), then shows alternative uses of the policy as of that year.

[0337] This third method assumes the homeowner does not pay off the principal in year N. Instead, he or she rolls over the mortgage and uses policy loans thereafter to pay the mortgage interest. The mortgage is held until the death of the homeowner. Mortgage interest is paid using zero or low spread policy loans from the life insurance policy. This method of mortgage repayment is attractive to those wishing to maximize the amount of life insurance death benefit payable to their estate. For the above example, assuming death at age ninety-nine, the death benefit net of policy loans would be $1,868,160.32. The policy loan balances in this repayment option remain extremely low compared to the policy cash value and death benefit ($5.8 million vs. death benefits of $8.2 million). Therefore, an amount of premium plus annuity to generate enough cash value to pay off the mortgage at the end of the mortgage term assuming LOPT=1 ($26,151) will be more than sufficient to carry the policy until the insured's ninety-ninth birthday. (Specimen 4 shows sample system output assuming the above-characterized mortgage, a lump-sum prepayment premium plan, and LOPT=2. Specimen 7 shows the same transaction but with a sponsored premium plan.)

[0338] Moving now to FIG. 3B-6, the system begins a process of checking the illustration just calculated to make sure it is in conformity with the legal definition of insurance by calculating regulatory guideline premium amounts in Block 128. These amounts are regulatory limits on the size of the premium relative to life insurance cash value and death benefits. As is subsequently discussed, the regulatory benchmarks include guidelines for Single Premium, Level Premium, and “Seven Pay” premium amounts. In Branch 130, the system compares these guideline premium amounts to those premium amounts previously stored via Block 120, the premium amounts for the proposed illustration. The cumulative premium initially illustrated must not exceed the cumulative Guideline Level Premium or the Guideline Single Premium in any given year of the proposed illustration. If the premium amounts exceed any of the guidelines, the system recomputes the needed premium using the newly computed guidelines via Block 132 and goes via logic entry point Z2 to FIG. 3B-5.

[0339] Once the system has solved for the correct premium/cash value combination and has tested this value against regulatory requirements, the system carries out four other operations. First, it prepares a further illustration in Block 133. This illustration assumes that the policyholder pays the previously determined premium amount and maintains the desired death benefit. However, the illustration further assumes that the carrier pays only the minimum guaranteed interest crediting rate on policy cash value, and charges the maximum mortality charges possible under the terms of the insurance contract. Samples of these Guaranteed Values appear in Specimens 2-7.

[0340] Next, the system in Block 134 computes two policy cost indices designed to provide the prospective applicant with a bench mark for measuring product performance. The first index is the Surrender Cost Index which is 1000 times the present value of premiums paid discounted at five percent minus the present value of the end-of-period cash value divided by the present value of the death benefits. The second index, known as the Net Payment Cost Index, is equal to 1000 times the ratio of the present value of the premiums discounted at five percent to the present value of the death benefits over the period discounted at five percent. The system calculates these two indices through Years 10 and 20 of the policy illustrated, assuming current interest and mortality charges apply, and assuming guaranteed interest and mortality charges apply. Sample calculations of these cost indices appear on the last page of Specimens 2-7.

[0341] Next the system computes the financial advantage to the prospective applicant of the Ryan Mortgage in Block 135. The computation compares these costs for the Ryan Mortgage and a conventional mortgage after five and ten years. The analysis also includes a comparison of the homeowner's equity in the home, assuming the home buyer enters into a conventional mortgage transaction, and the accumulated cash value in the life insurance contract in the Ryan Mortgage. This analysis appears in Specimens 2-7.

[0342] Next, the system provides an analysis of the effect of a change in interest rates on the required premium payment and cash value in Block 136. The system conducts this analysis first, by assuming the interest rate index pushes the carrier's credited rate down to the guaranteed rate and second, assuming the index pushes the mortgage rate up to the lender's cap after the first year. (The system does not perform the second analysis in the event a fixed rate or variable mortgage with no cap has been chosen.)

[0343] The first analysis assumes a decline in interest rates. Using the premium amount previously solved for, the system reprojects the cash value assuming mortality charges remain constant, but interest rates go down to the carrier's guaranteed rate. The analysis, provided for years 2 through the end of the mortgage, also assumes that in each year the customer is required to make additional premium payments. These additional premium payments are equal to one-twelfth of the difference between the cash value as it was originally projected and the cash value assuming a minimum guaranteed interest rate (plus premium processing charges). The payments are made monthly to the lender where they are held in escrow until the end of the year whereupon they are sent to the carrier. Because in a preferred embodiment of the invention the carrier credited and mortgage interest rates are tied to the same index, the decrease in the mortgage cost in most years will be less than the increase in the cost of a supplemental premium.

[0344] The additional premiums paid by the borrower will also permit the home buyer to pay off the mortgage sooner, assuming the home buyer has chosen to repay the mortgage by surrendering the life insurance contract. This is because the additional premium increases the policyholder's basis, thereby reducing the amount of the cash value which must be used to pay taxes upon surrender.

[0345] The second analysis made by the system in Block 136 assumes that the interest index rate rises, pushing the mortgage interest rate up to the cap. In a preferred embodiment of the invention the mortgage interest rate is variable. The carrier's crediting rate also rises with the index. This, in turn, causes cash value to accumulate faster than originally projected. This will permit the home buyer to pay off the mortgage sooner. The interest rate sensitivities summarized in Block 136 appear in Specimens 2-7.

[0346] These analyses, furthermore, permit the system to automatically generate Truth in Lending disclosures. By calculating the maximum cost to the consumer, assuming both maximum and minimum interest rates, the system apprises the consumer of the maximum mortgage cost in any year.

[0347] After the aforementioned supplemental analyses have been completed, the system saves the results in Block 137 for later printing. This completes the illustration for a particular financial product. Next, the system checks to see if it needs to make a similar computation for other products. If in Branch 138 it finds that not all desired products have been illustrated by comparing a target number of products to be illustrated (from Block 92 or 86) with a counter, the system increments the counter in Block 139 and returns to FIG. 3B-5 to initiate another illustration.

[0348] Otherwise, the system tests whether more than one product has been illustrated (J>1), and if so, proceeds to Block 142 to find the best product based on the criteria entered in Block 82. In either case, the logic goes to Block 144 to store the insurance product specific data for an illustration, and then goes to FIG. 3B-7.

[0349] FIG. 3B-7 produces a comparative illustration of a conventional mortgage. Block 146 computes the down payment amount. Block 148 then computes the loan amounts and calculates monthly payments. Block 150 computes a conventional mortgage, term insurance cost, and private mortgage insurance cost such that Block 152 can produce an illustration of the Ryan Mortgage in comparison with a conventional mortgage. The illustration is displayed on Terminal 2 via Block 153. If, in Branch 154, the prospective client specifies a changed down payment amount, the system performs a recomputation via FIG. 3B-5. Otherwise, the system goes to FIG. 3B-8.

[0350] Turning to FIG. 3B-8 at Block 156, the values relevant to the computation of an illustration are stored in the Database 17. The user can select a number of options: Print Illustration? 158, which will print the information on the Local Printer 5 via Block 160; Print and Mail Illustration? 162, which will print the illustration on the Central Printer 9 for mailing to a requested address via Block 164; and Make Application Using This Illustration? 166, which merges illustration data with stored text to make an application form, in Block 168. Block 168 also will save the illustration results for further analysis or review, except if this is a generic illustration (as it has been in the present discussion), in which case the generic illustration is removed from the Database 17. However, were this a new applicant illustration, the user could also access the saved illustration (for example, by the Update Existing Illustration 62). The logic returns to the submenu provided by Block 56 in FIG. 3. This return is helpful for changing the generic illustration assumptions in order to see a different version of the generic illustration.

[0351] In FIG. 3, again, the Generate New Applicant Illustration 60 function is illustrated in FIGS. 3B-1-3B-8 and User Screens 5-20. This part of the logic performs a similar function to that described above with reference to the Generate Generic Illustration 58 function, with the exception that illustrations can be customized to the prospective applicant's own particular circumstances to produce an illustration that resembles a financial transaction that might be entered into.

[0352] In FIG. 3B-1, Solicit 170 generates User Screens 5-7 to obtain information about the prospective applicant, the prospective applicant's employer, and the property at issue, respectively.

[0353] User Screens 5-7 request informational items for use in providing a mortgage quote. These items include, but are not limited to, the prospective applicant's name and address, the name and address of the prospective applicant's employer, the location of the property to be mortgaged, and the name and address of the realtor or sales agent representing the individual borrower in the purchase of the property.

[0354] Information regarding the employer (User Screen 6) of the prospective applicant is useful for the purpose of providing a printed loan application form. Also, because such data may be referenced against the list in the Database 17 of companies that have agreed to guarantee the premium payments to be made by employees, this information may also be useful in facilitating the loan approval and endorsement process. Such guarantees increase the security of the mortgage from the lender's perspective, thereby increasing the likelihood of mortgage approval on the part of a lender or other loan endorsing entity. Therefore, maintaining information on such guarantees and providing a function to verify the availability of such guarantees and the authenticity thereof is an important feature of the invention.

[0355] Information regarding the employer of the prospective applicant is also useful in the life insurance underwriting process. For example, there exist policies that life insurance carriers sell in large volumes through sponsored corporate purchases. These demand far less stringent underwriting requirements than would otherwise be required had the prospective applicant attempted to purchase the life insurance individually. The reason life insurance carriers may offer such policies has to do with the risks inherent in insuring large groups. If an insurance company were to offer to the general public life insurance policies that asked no questions as to the prospective insured's health, the insurance carrier would attract primarily those individuals who were of ill health or who expected to have increased mortality risk. This is known to those familiar with the life insurance industry as “adverse selection.” Adverse selection can be avoided in the case of a sponsored corporate purchase by designating a class of insureds all of whom will be insured. A class of insureds thereby takes on the characteristics of a randomly selected portion of the population at large, which, if large enough, will exhibit the same statistical distribution of deaths as the population at large. A class can be defined in many ways and might include such groups as all individuals who are members of the management of a large corporation or those who are relocated to a new community as a result of the normal performance of their duties.

[0356] In the event that corporations are willing to offer corporate sponsored purchase of life insurance, life insurance carriers may be willing to relax their underwriting requirements. Relaxed underwriting requirements usually take one of two forms, simplified issue or guaranteed issue. In simplified issue underwriting, only a few simple questions (typically three or four) are asked of the insured. In guaranteed issue underwriting, no questions apart from the age and sex of the prospective insured are asked.

[0357] The availability of this kind of underwriting may be beneficial to both the insurance carrier, which may profit from increased insurance sales by providing insurance policies with reduced underwriting in a high volume sale, and to the employer, which as a consequence may offer an enhanced product to its employees. In addition, this kind of underwriting creates another use for the prospective applicant's employment information. The employment information may be compared to a database of all those companies which offer corporate sponsorship of insurance purchases for their employees. If there is a match between the data provided concerning a prospective applicant's employer and information in the database, a corporate sponsor number will be used to identify a product which may be offered to the employee at reduced cost or with less stringent underwriting requirements.

[0358] A preferred embodiment of the invention involves a system of corporate sponsorship recognition involving the identification of companies providing both the aforementioned guarantee of premium payments and the creation of a defined group for the provision of specialized underwriting. Block 172 is dedicated to this task.

[0359] An inquiry into the prospective applicant's tax status begins with Block 174. The prospective applicant's tax rate information is input directly, as indicated in User Screen 8.

[0360] The information obtained via User Screen 8 is used in estimating the amount of the tax benefit to the borrower from the deductible mortgage interest expense, which is an important consideration to anyone evaluating the monthly net after-tax cost of a home purchase. This tax rate is then stored in the Database 17 for later use in the computation of tax credits from the deductible mortgage interest expense.

[0361] Proceeding to FIG. 3B-2, the logic develops information as to what kind of loan the prospective applicant might require.

[0362] User Screen 9 generated by Block 176 inquires as to the amount of money which will be required to purchase the target property, based on the entered estimated appraised value of the real estate. This data is written to the Database 17 for later retrieval and processing by the Digital Computer 8 in the creation of the illustration. User Screen 9 further asks the user to choose between: (1) selecting a loan offered by one of the lenders that currently offers mortgages using life insurance as collateral and which has authorized the system owner/operator to illustrate the use of its loans in conjunction with life insurance; or (2) entering hypothetical loan rates. (See Branch 178 in FIG. 3B-2.)

[0363] The ability to illustrate hypothetical loan rates is offered as a convenience to prospective borrowers who, through their own lending relationships, may have identified lenders who are willing to provide loans which may not be available to other borrowers.

[0364] In the event the user chooses to use one of the loans from a lender which has authorized the illustration of its loans, the logic consults the Database 17 at Block 180 to identify all those loans listed and writes selection of loan, its pricing, and the name of the institution offering it in User Screen 10.

[0365] Otherwise, from Branch 178, in the event the user chooses to enter a hypothetical rate, the logic requests basic information regarding the expected loan costs via User Screen 11, which is generated by Block 182.

[0366] To minimize the potential for generating an unreasonable illustration as a result of a mistake, Branch 184 checks to see that such rates are reasonable, given the current range of possibilities available in the market. If the rates are unreasonable, the logic loops back to Block 182.

[0367] User Screens 10 and 11, constructed at Branch 186, also ask the user if the prospective applicant would like the illustration to be based on closing costs which are known, or if it would be preferable to use some or all of the closing costs provided by the Database 17, derived from statistics provided by the Department of Housing and Urban Development or some other entity which gathers and reports such information. In the event the prospective applicant knows or can reliably estimate some or all of the costs, User Screen 12 appears, via Block 188.

[0368] The typical closing costs estimated by the system appear in one column. The user may alternatively enter the prospective applicant's estimate of those costs in a second column or leave certain cost categories in the second column blank, or if only a grand total of all closing costs is known to the prospective applicant, the prospective applicant may choose to enter the grand total amount, which then supersedes the itemized amounts listed in the “if known” column. The user must, however, enter a separate amount for the tax escrow. In those categories where blanks remain, Block 190 provides estimates. After Block 190, the estimates will be written to the Database 17 via Block 192, and in those categories where data has been entered to fill in the blanks, the Digital Computer 8 will, for this specific illustration, replace the system's estimates with those made by the prospective applicant when writing these values to the Database 17. Likewise, if only a grand total and tax escrow amount have been entered, those amounts are written to the Database 17 superseding all of the system's estimates.

[0369] Turning now to FIG. 3B-3, Branch 194 tests whether the system has identified a corporate sponsor number when the prospective applicant's employment data was compared to the aforementioned stored corporate sponsor tables via Block 172 (FIG. 3B-1). If none has been identified and the prospective applicant is unsure if there is a sponsor, Block 196 presents User Screen 13.

[0370] User Screen 13 asks if the prospective applicant has a corporate sponsor number and provides access to a listing of sponsors. In the event that there is a sponsor number in Branch 194 or in Branch 198, User Screen 14 appears via Block 200.

[0371] In User Screen 14, options are presented as to the lump-sum prepayment or the corporate guarantee of annual premium payments to be made, as well as the preferred mortgage repayment plan. User Screen 14 also prompts the user to select the mortgage repayment plan. Once designated, these selections are written to the Database 17 for the final computation of the mortgage using life insurance as collateral. If a corporate sponsor number is not identified in Branches 194 or 198, User Screen 15 appears via Branch 202.

[0372] In User Screen 15, via Block 202, options are presented as to the lump-sum prepayment or annual premium payments to be made, as well as the mortgage repayment plan. Screen 15 also prompts the user to select a mortgage repayment plan based on the distinct financial advantages of each plan to the prospective applicant. These selections are written to the Database 17 for the final computation of the mortgage using life insurance as collateral.

[0373] At Branch 204, if the prospective applicant is interested in securing an irrevocable letter of credit arrangement to backup the annual premium payment, a list of institutions which might be willing to offer such is provided to the user via Block 206. The entry of a selection of an institution in Block 206 brings up a financial sponsor number, which is written to the Database 17 for later retrieval and processing by the Digital Computer 8 in the creation of the illustration. In the event of unsponsored (lump-sum) purchases and Letter of Credit sponsored purchases, the information is stored at Block 208. The system reviews policy parameters saved in the Database 17 and consults the insurance data tables for policies conforming to the choices selected, and writes (Letter of Credit or unsponsored) summary information regarding these policies to the screen. The screen data appearing before the user is summarized in User Screen 16 for borrowers contemplating employer sponsored life insurance purchases.

[0374] Once selected by the user the policy selections are written to the Database 17 for later retrieval and processing by the Digital Computer 8 in the creation of the illustration. If instead a corporate sponsor number existed in Block 194 or 198, Block 210 presents User Screen 16, which obtains mortgage data from user selections.

[0375] Block 210, User Screen 16, selects a specific insurance policy in accordance with corporate sponsorship. The selected policy offered through the corporate sponsor can include three underwriting types: full medical underwriting, simplified issue and guaranteed issue. Normally, with guaranteed issue or simplified issue underwriting, the selection is limited to only one carrier's policy. Most carriers will require that only their product be illustrated in exchange for offering non-medical underwriting. The system then moves to Block 212 where the underwriting type is determined. If the policy is guaranteed issue, then the logic proceeds directly to Block 214 to store the selection, and then to FIG. 3B-4, where the system identifies the illustration as a single product illustration.

[0376] If instead the user had selected Simplified, the logic proceeds, to Block 216 where a four-question health questionnaire is presented via User Screen 18.

[0377] If the prospective applicant answers all the questions in the negative, at Branch 218, the policy selection and underwriting information is written to the Database 17 via Block 214 for later retrieval and processing by Digital Computer 8 in the creation of the illustration.

[0378] However, if the prospective applicant does not answer all questions in the negative, the logic of Branch 218 offers the choice of proceeding to Electronic Health Questionnaire 220, exemplified in User Screen 19. The choice is whether to continue to illustrate or to proceed to an Electronic Health Questionnaire 220, which is designed to more accurately portray the health status of the prospective applicant and hence facilitate the underwriting process by providing health information which will be needed for the prospective insured's life insurance application. This questionnaire will vary by policy, and may require several screens to complete, as different carriers have very different underwriting standards.

[0379] The other choice offered in Branch 218 is to proceed directly to the illustrations (via FIG. 3B-3) with the knowledge that illustration values may not reflect the actual insurance costs to be incurred by the individual. In this case, a blank health questionnaire is also printed out for the prospective applicant to complete at a later date.

[0380] Also, if the policy selected uses Medical underwriting, (or after Block 208) the logic proceeds to Block 220, User Screen 20, where the user enters answers to the Electronic Health Questionnaire 220 before proceeding ultimately to FIG. 3B-4.

[0381] No matter what choice is selected, all data created regarding the prospective insured's health status is written at Block 214 to the Database 17 for later retrieval and processing by the Digital Computer 8 in the creation of the illustration.

[0382] The logic then proceeds to FIGS. 3B-4, etc., which has been previously discussed herein with reference to the Generic Illustration selection of Block 58. Generally, though, the logic determines the number of policies to be illustrated (one for corporate sponsored or user selected policies, two or more for best product) solicits the best product search criteria, reads the values saved in the database, computes insurance and loan values, writes these values to the illustration table, prints these values on the user's screen, and allows the user to print out the illustration requested. However, in contrast to the procedure followed in the generation of a generic illustration, the logic automatically asks the user if it would be desirable to save the values in the illustration table for later use in updating the illustration or in generating and printing completed loan and/or insurance application forms as in Block 62.

[0383] Returning to FIG. 3, the Update Existing Illustration 62 function goes to FIG. 3C-1, which commences with Select Input Menu 222. This selection is depicted in User Screen 21, which is also known as the Update Existing Illustration Supermenu.

[0384] The logic then goes to the following boxes: Block 224 to update the prospective applicant data, including personal, employment, and health data; Block 226 to update the property data; Block 228 to update the tax rate data; Block 230 to update the insurance data, including the premium structure, as well as the policy selection; and Block 232 to update the mortgage data, including the loan selection and closing costs data. These Blocks 224-232 permit the user to revise selected data in Database 17. Once the menu item has been selected and the update screen has been visited, Block 234 is used to facilitate going to the appropriate screen. The screens are filled in with the old data and in Block 236 the user is allowed to change, add to, or delete from any of the existing data. Block 236 then returns to Block 222. When the user has gone through this loop as many times as necessary to update whatever screens need updating, then from Block 222, the choice of Proceed, Block 238, can be made in which the illustration process proceeds to FIG. 3B-5, which then completes the illustration.

[0385] Additionally, the user may select Help, Block 18, which has been previously mentioned as being available from any screen in the system from the Update Existing Illustration Supermenu. A representative context-sensitive hypertext Help screen is shown in User Screen 22.

[0386] Lastly, Block 240, may be selected to quickly terminate the current illustration session and return to the Main Menu 44 via Entry Point X1. The user is given an opportunity at this time to save what data has been entered thus far.

[0387] With further reference to FIG. 3, the Print Life Insurance Application 64 selection goes to FIG. 3D-1. Block 242 selects one form from a variety of insurance forms that could be printed, depending on the carrier. The logic proceeds to Block 244, which retrieves the existing prospective applicant data from Database 17, which was solicited in the process of creating the illustration, and prefills the insurance application form. If necessary, Block 246 allows the user to fill in any additional data. Then Block 248 prints the application at Local Printer 5. The logic proceeds to Block 250 which requests whether or not to send the application to the system owner/operator electronically. (The system owner/operator may also expedite transmission of application to the insurance carrier.) If that answer, in fact, is “no,” the logic goes to Block 252 to return to Block 244. If the answer is “yes,” Block 254 checks for completeness and permits sending the application to the Carrier via Block 256. Block 258 saves the insurance policy data and then returns to Block 64 in FIG. 3.

[0388] FIG. 3 also has a Print Loan Application 66 selection, which goes to FIG. 3E-1. While differing from Print Life Insurance Application 64 in the output provided, these two parts of the program carry out similar tasks. The user is asked whether to fill out the form by: (1) merging it with existing applicant illustration file data and adding whatever data might remain missing; or (2) filling out a loan form electronically ex nove. The user has the option of printing out the application form in varying degrees of completeness. However, in order for the loan application to be accepted electronically for processing, the form must have been completed for all answers programmed.

[0389] More particularly, in FIG. 3E-1, Block 260, the system automatically selects the particular loan application form from the library of loan application forms for the various lenders, and proceeds to Block 262, which retrieves existing applicant data from Database 17 and prefills the form. Block 264 allows the user to update fields that were not present in the illustration process. Block 266 prints the application on Local Printer 5. Block 268 asks whether or not the application should be sent electronically to the lender. If the answer is “no,” the routine goes to Block 270, which returns to Block 66 in FIG. 3. If the answer is “yes,” the routine proceeds to Block 272 to check the application for completeness. If it is complete, it is sent via Block 274 to the lender for processing electronically. Block 276 saves the data, and the logic finally returns to Block 66 on FIG. 3.

[0390] Review Insurance Product Developments and Review Loan Rates, Functions 68 and 70 in FIG. 3, permit the user to read through prepared textual data by allowing the user to move from screen-to-screen. Once the user has completed a review of the data from Database 17, one or all of the textual screens or “pages” can be printed at the Local Printer 5.

[0391] More particularly, for Review Insurance Product Developments 68 in FIG. 3, the logic goes to FIG. 3F-1. In Block 278, new insurance product developments are retrieved and displayed for the user. Block 280 allows the new insurance product developments to be printed on the Local Printer 5, if desired, and then the logic returns via Block 282 to Block 68 on FIG. 3.

[0392] In FIG. 3, Review Loan Rates 70 goes to FIG. 3G-1, which begins with Block 284, to retrieve and display the loan rate data from Database 17. Block 284 permits displaying that information and Block 286 permits printing that information on Local Printer 5, if desired, and then the logic returns via Block 288 to Review Loan Rates Block 70 of FIG. 3.

[0393] A separate but associated computer program which uses Database 17 is exemplified in FIGS. 3H-1 and 3H-2. FIG. 3H-1 shows a reillustration function of the present invention. The system uses this function in the maintenance of the policies, after the prospective applicant has entered a home financing transaction. The system essentially reillustrates a previously given illustration and saves the results of the reillustration. The system uses this reillustration information to monitor the annual cash value accumulation of the life insurance contract.

[0394] The system performs this function using, in part, data it already has from Database 17 by completing a batch run, for example, two months prior to the policy anniversary date. This is shown in Block 290. The system finds the original applicant data at Block 292 in the existing applicant Database 17, and then compares the cash value originally projected in the original Ryan product illustration to the annual cash value growth actually occurring in the insurance contract. In order to do this, the system finds the original illustration product parameters via Block 294 from the Database 17. Monitoring computations may be made using a life insurance policy index rate and a mortgage index rate.

[0395] In a preferred embodiment of the system, the life insurance policy credited rate and the mortgage loan rate use the same interest rate index. The interest rate index might be, for example, the average yield on United States Treasury Bills over the past year. Both life insurance policy interest credited and the mortgage rate are therefore variable in one embodiment of the invention. (In another embodiment of the invention, the mortgage interest rate and payment can be fixed.) However, some lenders will introduce mortgage products that place caps or limits on the amount interest rates can go up or down. This could limit interest changes in a given year, and/or over the life of the mortgage. (This is appealing to borrowers because it limits the potential cost of the mortgage upon a rise in interest rates. Also, most life insurance contracts must by present law provide a guaranteed minimum credited rate of interest on policyholder's funds. This amount is usually four percent. This feature is appealing to policyholders because it assures them a minimum return on their invested funds.)

[0396] In Block 296, the reillustration function of the system computes at the end of each year what the interest rate will be in the upcoming year using historical index interest rate information from Database 17. It makes this calculation for both the life insurance policy and the mortgage. This, in turn, permits the system to predict the cash value accumulation in the policy and recalculate the monthly mortgage payment in Block 298.

[0397] If interest rates go down, the amount of interest credited on the homeowner's policy will go down and the cash value will drop below the target. In order for the product to be acceptable to lenders or endorsers, however, the system must assure that the homeowner will have sufficient cash value to pay back the principal at the end of the mortgage term. Therefore, the terms of the mortgage agreement may require that the homeowner pay extra premiums in the event of a cash value shortfall. There is a test of whether extra premiums calculated by the system are payable upon a projected cash value shortfall due to lower interest rates in a given year in Block 300. The amount the home buyer must pay is determined by reference to the difference between the cash value originally projected and the amount that the contract will earn in the upcoming year. (A rise in interest rates will create a cash value surplus that will carry over into years of low interest rates.) This amount, for example, can be payable in twelve monthly installments and held in escrow by the lender. These amounts are computed in Block 302, the mortgage payment is computed in Block 304, FIG. 3H-2, these are stored in memory in Block 306 and sent to the lender in Block 308. The logic returns via Block 310 to Block 290.

[0398] At the end of the year, the lender sends the accumulated twelve monthly extra premium payments to the insurance company. After this payment is made, the life insurance policy will be at its originally projected cash value. Thus, the policy is subsequently back on target, even though interest rates may have fallen below original projections.

[0399] The increased cost of the additional premium payment payable in the event of a cash value shortfall is offset by the decreased cost of the mortgage interest. Mortgage interest rates typically exceed life insurance credited rates by one or two percentage points. The cash value amount will exceed the mortgage principal only in the last years of the mortgage. Therefore, the decrease in the cost of the mortgage payment will equal or exceed the cost increase from supplemental insurance premium payments. The net payment will be lower in all but the last years of the mortgage. The supplemental insurance premium payments can only exceed the decrease in mortgage payments when the cash value balance exceeds the principal balance. Then, generally after year twenty-five of the mortgage, a sudden drop in interest rates will cause the homeowner to pay the largest extra premium payments. This is because the cash value accumulation is greatest in those years.

[0400] This situation is analogous to the effects of a precipitous drop in interest rates in the last years of a variable rate conventional mortgage. In a variable rate mortgage, the year's mortgage payment is recalculated each year. The calculation is based on the preceding year's principal balance, the year's interest rate, and the number of payments remaining over the life of the mortgage. The rate at which principal is amortized in a conventional mortgage differs, according to the interest rate. At higher interest rates, amortization occurs more slowly. Thus, if the mortgage principal has been amortized at a higher interest rate and interest rates drop suddenly in a given year, the homeowner must pay a larger amount of principal in that year than originally expected. The Ryan Mortgage functions the same way when interest rates decline. However, when interest rates go up, in the Ryan Mortgage principal accumulation is actually more rapid, because the principal is accumulating in a life insurance contract. Thus, the Ryan Mortgage variable rate mortgage offers the consumer the same assurance of mortgage repayment as a conventional mortgage upon falling interest rates, but it also provides for more rapid repayment of the mortgage in the event of rising interest rates. This feature is a significant improvement over the conventional variable rate mortgage.

[0401] FIG. 4 provides a depiction of a relational Database 17 for the present invention. The description of the relational Database 17 includes numbered entity (database table) definitions and detailed descriptions of the columns (fields) present and their characteristics. NOT NULL specifies that a column is required to be filled, and TYPE designates the type of data that this column contains. The following table definitions parallel the above entity definitions and detail the columns (fields) present and their characteristics.

[0402] ADDITIONAL_RESPONSES 400 has records of additional responses made by the prospective applicant to questions that appear on an insurance or loan application form that were not solicited during the illustration process.

[0403] APPLICATION 402 is a super entity which holds the various insurance applications 402A and loan applications 402B (each specific type of application is a view or instance of this table). These application records are built on information contained in the illustration, as well as supplemental information supplied by the prospective applicant (e.g., provided in ADDITIONAL_RESPONSES 400). There is one APPLICATION 402 record for every application created for a prospective applicant

[0404] CLOSING_COSTS 404 is an entity that holds closing costs data that is used to generate the estimates used for the closing costs specific to an illustration.

[0405] The CONVENTIONAL_MORTGAGE 406 entity contains all the information necessary to compute the conventional mortgage costs for the same property. These figures are reported in the illustration printout.

[0406] The CS_CLOSED_ELIGIBILITY 408 entity contains the specific eligibility requirements for each corporate sponsored premium guarantee plan. Specifically, it contains the eligibility requirements for closed plans, i.e., those corporate sponsored premium guarantee plans that are available only to limited personnel within an organization.

[0407] The CS_OPEN_ELIGIBILITY 410 entity contains the specific eligibility requirements for each corporate sponsored premium guarantee plan. Specifically, it contains the eligibility requirements for open plans, i.e., those corporate sponsored premium guarantee plans that are available to all personnel within an organization.

[0408] The EMPLOYMENT 412 entity contains the employment data for the prospective applicant requesting an illustration, such as place of employment, salary, etc.

[0409] The FMA_HELP 414 entity contains all context sensitive, hypertext linked help records for Help 18. It contains context keywords, and hyperlink keywords in addition to the help text that enables these features.

[0410] The HEALTH_QUESTION 416 entity contains the individual questions that comprise a specific health questionnaire. Depending on the question and questionnaire, a specific question may appear in multiple health questionnaires.

[0411] The HEALTH_QUESTION_RESPONSE 418 entity contains the responses to the health questions by the prospective applicant. It contains responses to all of the health questions, be they simplified or medical underwriting types.

[0412] The IC_CS_REGISTER 420 entity is an intersection table used internally to resolve the “many-to-many” relationship between insurance carriers (IC) and corporate sponsors (CS). Since any single corporate sponsor may have agreements with multiple insurance carriers, and any single insurance carrier may have agreements with multiple corporate sponsors, this table is required to describe these relationships.

[0413] An ILLUSTRATION 422 is a document (both hard copy and database record) that is produced for a PERSON 452 (prospective applicant) which compares a conventional mortgage with an insurance collateralized, Ryan Mortgage on a specific property. Multiple illustrations may be produced for a single prospective applicant illustrating various insurance and loan selections, but each illustration must be owned by a single prospective applicant. A special generic illustration may be created in which most (or all) of the client information is derived from a generic set of data. With the exception of the generic illustration, any illustration may result in an insurance and loan application. The ILLUSTRATION entity contains both data and pointers to data for all aspects of an illustration.

[0414] The ILLUSTRATION_RIDERS 424 table, also an intersection table, contains a list of all of the rider clauses required for a particular illustration.

[0415] The INSTITUTION 426 entity is a super entity (like APPLICATION 402) which holds the various institution types. Each specific type of institution (like LENDER, INSURANCE_CARRIER, etc.) is a view of this table. There is an INSTITUTION 426 record for every institution participating in the illustration process. The INSTITUTION entity is not shown on the Entity Relationship Diagram (ERD) of FIG. 4. Rather, the specific views are represented. These are:

[0416] AGENCY (not shown)

[0417] EMPLOYER/CORPORATE_SPONSOR

[0418] INSURANCE_CARRIER

[0419] LENDER

[0420] REALTY_FIRM

[0421] The INSTITUTION_OFFICER 428 entity is a super entity (like APPLICATION) which holds the various institution officer types. Each specific type of institution officer (like LOAN_OFFICER, INSURANCE_AGENT, etc.) is a view of this table. There is an INSTITUTION_OFFICER record for every institution officer participating in the illustration process. The INSTITUTION_OFFICER entity is not shown on the ERD of FIG. 4. Rather, the specific views are represented. These are:

[0422] AGENCY_OFFICER (not shown)

[0423] CORPORATE_SPONSOR_OFFICER

[0424] EMPLOYER_CONTACT (not shown)

[0425] INSURANCE_AGENT

[0426] LOAN_OFFICER

[0427] REALTOR

[0428] USER

[0429] The INSURANCE_PACKAGE 430 entity details the insurance packages available to be chosen for an illustration—the rates, duration, etc. This list can be viewed during the illustration process. If the prospective applicant has chosen an alternative form of collateral (a zero coupon bond, for example) this collateral is detailed in the OTHER_COLLATERAL 444 entity. The database entity is OTHER_COLLATERAL capable of storing information regarding other types of securities, term insurance, and the type of account in which the securities are held (e.g., IRA, Keough Account, or other tax-favored account.) For an individual illustration, OTHER_COLLATERAL 444 and INSURANCE_PACKAGE 430 are mutually exclusive.

[0430] The INSURANCE_POLICY 432 entity contains data specific for a policy issued as a result of an illustration.

[0431] The LOAN_AGREEMENT 434 entity contains data specific for a loan agreement issued as a result of an illustration.

[0432] The LOAN_PACKAGE 436 entity details the Ryan Mortgage authorized lender loan packages available to be chosen for an illustration—the rates, duration, etc. This list can be viewed during the illustration process.

[0433] The LETTER OF CREDIT (LOC) 438 entity contains data on the available irrevocable letters of credit available to be chosen for an illustration. The LOC can be used in lieu of a corporate sponsored premium guarantee, where the prospective applicant would choose not to have the lump-sum prepayment. The lump-sum prepayment, corporate sponsored premium guarantee, and the irrevocable letter of credit premium guarantee are all mutually exclusive.

[0434] The LOC_ELIGIBILITY 440 entity contains the specific eligibility requirements for each irrevocable letter of credit available for use in an illustration.

[0435] The NEW_INSURANCE_DEV 468 entity contains primarily textual data describing the new insurance developments in the industry that are and will be available to a prospective applicant in creating a Ryan Mortgage.

[0436] The NEW_LOAN_DEV 442 entity contains primarily textual data describing the new loan developments in the industry that are and will be available to a prospective applicant in creating a Ryan Mortgage.

[0437] The OTHER_COLLATERAL 444 entity contains data on other instruments that are used to secure a Ryan Mortgage. The OTHER_COLLATERAL_ID number identifies the type of investment instrument to be illustrated. Other instruments may include, for example, term insurance used in conjunction with a security, such as a zero coupon bond, or term insurance used in conjunction with a deferred annuity. Each of these instruments, like a universal life policy, may be used in place of a down payment to provide a means of accumulating the principal needed to repay the mortgage. This data base entity is also capable of storing the type of account that the security is held in. TAX_STATUS identifies the kind of account that the investment is held in and may include information regarding a Keough Account, Individual Retirement Account, Profit Sharing Plan, 401k plan, or other tax-favored investment account. The tax status of the account in which the investment is held is important, as it dictates the amount and timing of the taxes payable on the investment's earnings. This, in turn, dictates the amount of up-front payment required for the mortgage transaction, as well as any tax escrows which may be required.

[0438] The PAPER_FORM 446 entity describes the individual paper form for the specific mortgage loan and insurance application forms, illustration forms, and health questionnaires used by the system. It holds global information regarding the form, (e.g., WordPerfect merge file name). It is pointed to by the individual PAPER_FORM_ITEM.

[0439] The PAPER_FORM_ITEM 448 entity contains the specific “select data” instructions that are used to retrieve the prospective applicant data that will then be written to a paper form, e.g., the prospective applicant's name. Any PAPER_FORM_ITEM 448, like the prospective applicant's name, may be used in multiple paper forms throughout the system, which allows for non-redundant storage of common information between forms.

[0440] The PAPER_FORM_ITEM_REGISTER 450 entity is an intersection table that resolves the “many-to-many” relationship between the PAPER_FORM and PAPER_FORM_ITEM tables, and details which paper forms contain which items, and which items belong to which forms.

[0441] A PERSON 452 (applicant) is defined as a person or husband/wife couple who collectively request an illustration. A PERSON file may contain two insureds and/or borrowers. Two insureds could have, for example, two separate policies with coverage proportional to their share of the combined household income. Two insureds' policies are calculated separately then combined in a composite illustration for the two-insured PERSON. Two insureds may also own a single policy. A single policy option for two insureds includes a joint and survivor policy wherein death benefits are paid upon the death of the second insured to die, and a joint life policy which pays a death benefit on the death of the first insured. Each PERSON may have requested multiple illustrations.

[0442] The PROPERTY 454 is the real estate (land, dwelling, etc.) on which the illustration is being drawn up.

[0443] The RIDER 456 entity describes the insurance riders available for use in the illustration process. A policy rider is an amendment attached to a policy that modifies the conditions of the policy by expanding, or decreasing its benefits or excluding certain conditions from coverage. Typical examples of policy riders include disability income riders which pay a benefit equal to the mortgage cost in the event the insured(s) are disabled and waiver of premium riders (typically used in conjunction with disability riders to waive the cost of insurance charges in the policy in the event the insured is disabled).

[0444] The UPDATE_ACTIVITY 458 entity is an internal table that is used to keep track of the dates of supervisory update and modification operations made to the various reference tables (e.g., INSURANCE_PACKAGE 430, LOAN_PACKAGE 436, etc.).

[0445] The MORT_REGISTER 460 entity documents the association of group numbers with various combinations of prospective applicant attributes and insurance products.

[0446] This table documents the association of group numbers with the various combinations of attributes possible:

[0447] Male/Female

[0448] Smoking/Non-smoking/Aggregate

[0449] Age last/Age nearest

[0450] Insurance Product

[0451] CSO table/COI table

[0452] For example:

[0453] The “description” data in MORT_REGISTER is simply that. It describes the attributes of each table for use in managing the system. During the illustration process the system uses another database entity to select which of the MORT_REGISTER tables are applicable to a particular product. The actual logical selection of which table is to be used for each combination is accomplished by entries in the INSURANCE_PACKAGE 430 table, which describes in detail each insurance product available to the system, and which, through its associated detail tables, points to the particular MORT_REGISTER Groups to be used, for each sex/smoking/etc. combination, in illustrating that particular product, referring to each group by its GROUP_NAME.

[0454] MORT 462 tabulates mortality figures (either in strict deaths per thousand or cost of insurance). While the common mortality tables (CSO and the like) and the product specific Cost Of Insurance (COI) tables are essentially the same, there are some differences.

[0455] Both conceptual tables are housed inside one relational database table structure (MORT 462) to allow for ease of access. The relational table's structure for the MORT 462 table follows:

[0456] The MORT 462 table is organized into groups of records, each group having the same GROUP_NUMBER. A group is a “Mortality Table.” Each combination of the following attributes will reference a GROUP_NUMBER:

[0457] Male/Female

[0458] Smoking/Non-smoking/Aggregate

[0459] Age last/Age nearest

[0460] Insurance Product

[0461] CSO table/COI table

[0462] A GROUP_NUMBER may be used by any combination. Therefore, for a particular Group (mortality table), for example, the 1980 CSO table for Male/Non-smoking/Age last (no product designation in this case), there are records for ages 18 through 99 as shown below:

[0463] Note that in the case of the CSO tables, there is nothing in the AGE_OF_ISSUE column (NULL). So, to reference the CSO Group that corresponds to Male/Non-smoking/Age last, the system retrieves all records for GROUP_NUMBER+1.

[0464] To satisfy all combinations of the above attributes for the CSO tables (Male/Female, Smoking/Non-smoking/Aggregate, Age last/Age nearest) there are as many as 12 groups, each group having entries for ages 18 through 99 years of age. Thus, there will be 82 (i.e., 99−18+1) rows (i.e., records) in each group, one for each year of age, times each of the 12 combinations, resulting in 984 records for the collection of all 12 CSO groups. Like the common mortality groups (mortality tables), the COI groups (mortality tables) are organized by GROUP_NUMBER. The GROUP_NUMBER in this case segregates groups not only by sex, smoking, etc., but also by insurance product. But unlike the common mortality tables, there is a sub-group structure to the mortality table based on the prospective applicant's age at the time of policy issue. There is a special “sub-table,” selected by the prospective applicant's age, as designated by the AGE_OF_ISSUE column, that is used for the first YS years. The AGE_OF_ISSUE entry specifies the select versus ultimate portions of the mortality table. If the AGE_OF_ISSUE column is NULL, then that series of records correspond to the ultimate series within that particular insurance product group. The CSO mortality table, then, is a standard mortality table with YS=O (i.e., no select entries).

[0465] One further difference is that the year/age column designates age of the insured for ultimate groups, but designates year of policy for select groups.

[0466] An applicant's cost of insurance will be determined by selecting the rows corresponding to a particular group number (which may be for a specific insurance product and a specific collection of attributes such as sex, smoking, etc.) for the applicant's AGE_OF_ISSUE. There will be typically 10 or less rows (YS) within a particular AGE_OF_ISSUE sub-group. For years beyond the YS years, the ultimate group is used, which is retrieved by selecting the rows for this GROUP_NUMBER whose AGE_OF_ISSUE is NULL and whose “year/age” entries are AGE_OF_ISSUE+YS and greater.

[0467] An example of a COI group is given below:

[0468] The above shows two of the select sub-groups (for age of issue 35 and 40) for COI group 5, as well as the ultimate group (age of issue=NULL) for COI group 5. (Subgroups will be present for all possible AGE_OF_ISSUE values.)

[0469] The COI group 5 may be used by any insurance product. This association of product to group (mortality table) is managed by the MORT_REGISTER 460 table.

[0470] The CORPORATE_SPONSOR_GUARANTEE 464 entity contains data on the corporate guarantees available to be chosen for an illustration. The corporate sponsor guarantee is only available to those prospective applicants with a participating employer and can be used where a prospective applicant prefers not to use a lump-sum prepayment.

[0471] The HEALTH_QUESTIONNAIRE 466 entity is used to register the individual questions that comprise a specific health questionnaire. Depending on the question and questionnaire, a specific question may appear in multiple questionnaires.

[0472] B. Discussion of Variables

[0473] The following variables, identities, and formulas show how the insurance and mortgage illustrations of the kind previously described are computed in a preferred embodiment of the invention. Because these variables are used throughout the illustration process, references to how and where they are used will include multiple Figures and Blocks. Every effort, however, has been made to illustrate the flow of system logic in the description of the variables and computations.

[0474] LNUM: This is the number of annual insurance premiums. This is a system parameter. Two possibilities exist in a preferred embodiment of the invention: (1) Assuming an annuity, this value is four and is the minimum normally allowed under legal definitions of insurance; or (2) Assuming a non-annuity, this number is typically ten, but could range from four to the total number of years in the mortgage. These values are not user selectable but may be system adjusted.

[0475] LIFPAY: This is the annual premium required. This value is computed. The system assumes a value in Blocks 108, 116, 124, and 126, and evaluates the formulas in Block 110. The system uses iterative approximation to find the value that will produce the needed insurance, and the cash value. Then, the system iterates if needed on the illustrated insurance values to test if the value computed meets the regulatory definition of insurance in Block 128. The variable, once computed, is also used to show contract performance assuming guaranteed interest and mortality charges apply in Block 134.

[0476] PRIN: Initially, this is equal to the value of the property being financed but may also be equal to the sum borrowed. A default value is assumed in Block 72 of FIG. 3A-1. It is a system input in Block 176 of FIG. 3B-2. The death benefit of the insurance must equal this value, at a minimum. The death benefit may be higher, for certain options, if the regulatory tests are not met at this value.

[0477] a₁: This is the age of the insured for the first year of the policy. It is computed from the birth date solicited in Block 170 or solicited directly in Block 72.

[0478] The birth date is a system input. Each product has a parameter, using the “nearest” or “last” birthday which defines how the birth date is used to compute a₁. An insured stays this age for the first year of the policy. The age is incremented at each policy anniversary. The policy anniversary date is the date when the policy is sold. For illustration purposes, the policy anniversary date is equal to the estimated closing date, a system input.

[0479] Because changes in birth date in relation to closing date can change policy charges, any non-final illustration in FIG. 3B-8, Block 160, and FIG. 3B-7, Block 152 may include a disclaimer in its output to the effect that a delay in making the application may result in changes to the projections, comparisons, and costs.

[0480] inlp: This is the percentage discount rate for a Guideline Level Premium (GLP) value calculation which is computed in FIG. 3B-6, Block 128. The system stores this information by product. The variable, mlp=monthly multiplier=(1+inlp)^{{fraction (1/12)}}, is computed upon use of inlp.

[0481] insp: This is the discount rate, expressed as a percentage, for the Guideline Single Premium (GSP) value calculation which is computed in FIG. 3B-6, Block 128. The system stores this information by product. The variable, msp=monthly multiplier=(1+insp)^{{fraction (1/12)}}, is computed upon use of insp.

[0482] The mortality table data discussed below is stored as percentages. The system stores all percentages as such. All formulas assume the fractional equivalent which is the value divided by one hundred. The stored values, however, are not generally integers.

[0483] CSO(a): All values from the Commissioner's Standard Ordinary Table, a common mortality table published in 1980, are stored in deaths/1000 at age a. These are real numbers. The system allows up to five place accuracy after the decimal point, i e., xxx.xxxxx.

[0484] The table, as it is used by the system, is tabulated for ages eighteen to ninety-nine. This table is used for GSP and GLP calculations in FIG. 3B-6, Block 128 and is therefore a system parameter. The system contains several versions of the 1980 CSO tables. They include: Male/Female, Smoking/Nonsmoking/Aggregate, and Age last/Age nearest. The system contains, therefore, a total of 2×3×2=12 tables. Table entries appear as a value per thousand and are used to obtain a fractional probability of death. Each product indicates whether to use the male/female tables in accordance with the sex of the insured, or whether to use a blend. If a blend is indicated, the product data table indicates the percentage male. The remainder is female. An exception table exists, by state, for each product. Multiple products may be present in the system for a single carrier and all use this same exception table. However, this is not a system rule. There is not a unique exception table for every product, but a given exception table may apply to any number of products, including just one. If an entry is present, it mandates the blend percentage male to use for policies issued in that state for the product(s) referencing that table. That blend percentage will override any generic male/female or blend selection in the product. This feature is a system requirement because some states require the use of unisex tables weighted exactly in proportion with the carrier's male/female weighting of its existing insured population.

[0485] ^Amax: This is the variable for the assumed maximum survival age. This is a system parameter. Typically, it is age ninety-five or ninety-nine. For the sake of consistency, this document has assumed age ninety-nine throughout its discussion.

[0486] NYR: This is the variable for mortgage length, usually 30 years. This is a system parameter. The system manager can change this variable using the aforementioned super user function. The system is capable of illustrating other mortgage lengths, and permitting user selection of various mortgage lengths in FIG. 3B-2, Block 182. This capability is needed as lenders offer alternative length mortgages.

[0487] MTH: This is the variable for the number of months in the mortgage. It is computed as:

[0488] =12×NYR

[0489] LEXP(n): This is the variable for per-policy expenses, in month n. The cost is independent of the premium size and the prospective applicant's characteristics. It is dependent, however, on month and Specified Amount, SA. A table exists for each product to store this information. Each table entry, for month n of the insurance period, contains two values: a fixed dollar amount, LEXPF(n), and, a percentage amount expressed as cost as a percentage of SA: LEXPV(n).

[0490] On use in FIG. 3B-5, Block 110 and FIG. 3B-6, Blocks 128 and 134, the system computes $\mathrm{LEXP}\left(n\right)=\mathrm{LEXPF}\left(n\right)+\frac{\mathrm{LEXPV}\left(n\right)\times \mathrm{SA}}{1000}$

[0491] In month one, the system adds LEXPSELL, a one time charge by product to LEXP(n).

[0492] LPCT(n): This variable is the percent-of-premium expense charged by the carrier, in a given month n. For each product, the system develops a “table” of values, generated from parameters for that product. It likewise is used in FIG. 3B-5, Block 110 and FIG. 3B-6, Blocks 128 and 134.

[0493] For each combination of the criteria below which a product uses, the system contains six values. These values are reflected using flags for a particular product's criteria. LPCT1A and LPCT1B are the initial values, LPCT2A and LPCT2B are the continuing values, and LPCTY is the year number (of the policy) at the beginning of which the system switches between pairs 1 and 2. $\begin{array}{cc}\mathrm{LPCTx}\left(n\right)=\mathrm{LCPT1x},& n\le 12x\left(\mathrm{LPCTY}\text{-}1\right)\\ =\mathrm{LCPT2x},& n>12x\left(\mathrm{LPCTY}\text{-}1\right)\end{array}$ $\text{for}x=A\text{and}B$

[0494] LPCTSA: This variable is the break ratio, in dollars per thousand dollars of Specified Amount or basic death benefit, SA. (The formula for Specified Amount appears later in the formula description text.) This is used to compute a breakpoint value for LPCT(n).

[0495] LPCTBRK=LPCTSA×SA

[0496] Then, when the equations call for applying LPCT(n), the system uses LPCTA(n) on the first LPCTBRK dollars, and LPCTB(n) on the remainder. If LPCTSA=0, there is no break and, for ease of computation, the system stores equal values for the A and B versions.

[0497] The following variables store mortgage repayment plan information solicited in FIG. 3B-4, Block 98.

[0498] LOPT: This is the loan repayment option referred to earlier in the document. It is selected by the user.

[0499] LOPT=0: This variable assumes the mortgage is to be paid off with the after-tax insurance cash surrender value after MTH months.

[0500] LOPT=1: This variable assumes the mortgage is to be paid off with a life insurance policy loan secured by the insurance cash value, after MTH months. The interest on the loan is paid by further borrowing. The system guideline is net remaining cash value just greater than zero at A_max.

[0501] LOPT=2: This loan repayment option assumes the mortgage is rolled over and is paid off by the death benefit when the insured dies. The insured starts borrowing against the cash value to pay the mortgage interest after MTH months. The system tracks cumulative borrowing, per LOPT=1. The system assumes the same premium as is solved for assuming LOPT=1.

[0502] iCL: This is the annual policy loaned funds interest rate. It is stored by product. This is the cost of policy loan interest. Carriers compute this figure in one of two ways. Therefore, the system uses a flag for iCL, by product. Based on this flag, the system uses interest in arrears or in advance formulas in the computation of policy loans in FIG. 3B-5, Block 110. The system computes, at the start of the illustration for a specific product, the monthly compounding multiplier: mCL=(1+iCL)^{{fraction (1/12)}}.

[0503] Qx(a): This variable represents the annual cost of insurance at attained age a. The data is contained in multiple tables. The data is stored by product. However, a single set of tables, with state exceptions (please see below), may service multiple products. The data is stored as real values, in terms of mortality per 1000. Wherever used in a formula in this patent application, it should be understood that the value used is the probability of dying at age $a=\frac{\mathrm{Qx}\left(a\right)}{1000}.$

[0504] This variable is used in the computation of cash value and death benefit amounts in FIG. 3B-5, Block 110.

[0505] {overscore (q)}x(a): This is a table for the monthly cost of insurance values. It is shown as a computed value in the formulas, as computed from Qx(a). The system allows for a product to point to tables, directly, in the same structure, for example Select/Ultimate, and with the same selection criteria, sex, smoking, etc., and sponsored/unsponsored flags as Qx(a).

[0506] The following statements apply to both Qx(a) and, if present, qx(a). Every Qx and qx table in the system is in two parts, Select and Ultimate, either of which may be empty. It is rare for part two, the Ultimate Table, to be empty. The Select Table is empty more frequently. The first part is the Select table. The select table is actually a table of tables. (See also the MORT and MORT_REGISTER table discussion for additional information on Select and Ultimate tables.)

[0507] The Ultimate table has entries for attained age from Y_sto 100 (maximum), that apply for those attained ages, after the first Y_syears have elapsed. For example, assume Y_s=8, for a policy issued at attained age of 35. The system uses the entries in the Select table, for the age at issue=35, for the first 8 years, then uses the Ultimate table, thereafter. The system from there on will use the entry for attained-age=43 for year 9, 44 for year 10, etc. Therefore, an important parameter stored by the system by product is which table to use. A table is described by Select/Ultimate breakpoint (in years), and the two actual tables, the first of which has two dimensions, and the second of which, is a vector.

[0508] In summary, a single set of mortality tables may apply to many products, or to just one. The system tracks the tables by carrier and product. These variables are used in the computation of death benefit and cash value amounts in Block 110 of FIG. 3B-5.

[0509] The number and application of tables in each set is specified for a given set of tables by the following product-specific flags:

[0510] Smoking/Nonsmoking tables, or just Aggregate Tables.

[0511] Preferred/Nonpreferred risk tables, or no selection on risk.

[0512] Male, Female, and Unisex tables, or just Unisex tables.

[0513] The Unisex table subset includes a table to be used in other than exception states, with auxiliary tables for specific states. A system exception list contains specific states for which Unisex rating is required and, if so, whether to use the standard Unisex table, or the name of a special table for that state. If normally the product selects between male/female tables, the system will instead use the Unisex table if mandated for that State by state regulatory guidelines. In addition, a separate product flag indicates if the Unisex table is to be used for any sponsored applicant (guaranteed premiums). Finally, in the sponsor table, a flag indicates whether that sponsor mandates the use of the Unisex table.

[0514] The system uses a group of default tables, characterized as 1983 GAM Mortality, which is a typical mortality assumption. However, other default tables may be used at the system operator's discretion. These tables are used for illustrations when no other mortality data is listed for a product. There are four 1983 GAM tables: Nearest age, or last age, and male, female. A flag in a product record will indicate whether or not to use these mortality tables and, if so, the default male percentage to use when blending for Unisex. The system default for the state exception table that mandates unisex rating also mandates the male percentage value. The system default also uses the same mortality table for life insurance in the Ryan Mortgage and the conventional mortgage term insurance.

[0515] The system also allows for the input of a rating factor for high risk, separately underwritten prospective applicants, qf. Its default value is 100%. The system formulas use qf×{overscore (q)}x (or Qx) wherever the equations use {overscore (q)}x (or Qx). This input will not be under the prospective applicant's control. Rather, it is provided by the system owner's operations staff or the carrier's staff. If rating is required, it triggers the generation of a new illustration, otherwise the same as the old illustration, except that the mortality charges will be based on a rating factor. The illustration is of a single product and will be printed by the system locally and mailed to the prospective applicant separately.

[0516] Set out below are a number of computational flags:

[0517] qx guideline guarantee flag: If set, qx is computed from Qx, or is tabular and is used for the first year instead of qxg in the guideline premium computations.

[0518] qx minimum guaranteed interest projection flag: If set, qx is computed from Qx, or is tabular and is used for the first year, instead of qxg, in the minimum guaranteed interest projection.

[0519] qxg(a): This is a special set of qx tables, the guaranteed monthly cost of insurance. Each is a simple table of values versus attained age. There is no Select table, just Ultimate. The system stores this information by product. A data set consists of a standard table product, plus special table(s) for specific states. For example, a product uses its standard qxg except for certain states. Each special state present points to a qxg table, but multiple special states may use the same special qxg table.

[0520] The table, standard, or special for each state, is actually several. Tables appear by sex, smoking/nonsmoking/aggregate, age last/next, in parallel with the CSO tables. However, there is not a blend percentage for producing a unisex table for a state; rather, an explicit Unisex table is present, with the possibility of different tables for different states, and, again, a state flag that mandates the use of a Unisex table, overriding the product preference.

[0521] The formula below is used in refining the gLP and gSP.

[0522] A product flag, if set, indicates that the formula approximation is to be used. If so, the qxg(a) value is computed from the corresponding CSO(a) value as: $\mathrm{qxg}\left(a\right)=\frac{\frac{\mathrm{CSO}\left(a\right)}{12}}{\left[1-\frac{11}{24}\mathrm{CSO}\left(a\right)\right]}$

[0523] CORR(a): The guideline premium corridor is the minimum insurance coverage or death benefit permissible under law. The death benefit computed in FIG. 3B-5, Block 110 is this factor times cash value. The values are expressed as a percent of cash value, (e.g., 250 is 2.5 times cash value). The corridor data consists of a single table, by attained age. No male/female or other differentiation is made in the computation.

[0524] iC1, iC2, iCbreak: These flags identify current policy credited rates as a percentage of unloaned funds, and the breakpoint value on the dollar amount at which to switch from iC1 to iC2 by product. The system also allows for a no breakpoint case. The system computes, and then saves for use in formulas, the monthly rates:

[0525] iC1_m=(1+iC1)^{{fraction (1/12)}}−1

[0526] iC2_m=(1+iC2)^{{fraction (1/12)}}−1

[0527] iC guideline guarantee flag: If this flag is set, iC1 and iC2 are guaranteed for the first year, in guideline premium computations.

[0528] iC minimum interest guarantee flag: If this flag is set, iC1 and iC2 are guaranteed for the first year of the minimum guaranteed interest projection.

[0529] iL: This variable represents the annual policy loan credited rate for a particular product. The system computes, then saves for use in formulas, the monthly rate:

[0530] iL_m=(1+iL)^{{fraction (1/12)}}−1

[0531] TAXRATE: This variable represents the prospective applicant's tax bracket. This is a user input entered in FIG. 3B-1, Block 174. The system default used in FIG. 3A-1 is 30 percent.

[0532] Set out below are formulas for the life insurance and mortgage computations of the system. #: Indicates a computation which is independent of life insurance policy size. These computations are therefore out of the illustration system's iterative loop. *: Indicates a computation which is product independent and is therefore standard for all products.

[0533] LPAY(n): This is the premium paid in month n. The system computes a first trial value as to the value for LPAY(1) in FIG. B5, Block 108, then makes iterative trials as to the correct amount.

[0534] =LIFPAY,n=1, 13, 25, . . . , 12×LNUM−11

[0535] =0, otherwise

[0536] The premium is paid annually, in the beginning of each year's first month.

[0537] LBASIS(n): This is the value for cumulative premiums paid to date, including the month n. It is computed as: $=\sum _{r=1}^n\mathrm{LPAY}\left(r\right)$

[0538] #*a_t: This is the variable for the insured's age in year t of the policy.

[0539] =a₁+(t−1)

[0540] This variable is used in equations which calculate annual amounts.

[0541] â_n=: This variable tracks the insured's age in month n. It is used for age nearest/age last computations.

[0542] =^a_{int(n+11)/12]}, where int is the integer function.

[0543] #* Q(t): This is the variable for the probability of death, during year t, using the 1980 CSO table, a common mortality table used in the system's regulatory compliance computations in FIG. 3B-4, Block 128. Carriers commonly use this table in the calculation of guaranteed mortality. It is computed as: $=\frac{\mathrm{CSO}\left(a_t\right)}{1000}$

[0544] #* P(t): This variable represents the probability of not dying in a given year. It is computed as:

[0545] =1−Q(t)

[0546] 7#* tP(t): This variable represents the probability of surviving through year t. It is computed as: $=\prod _{s=1}^{t}P\left(s\right),t>0=1,t=0$

[0547] #* N_max: This variable represents the maximum number of policy years. It is computed in relation to the insured's ninety-fifth or ninety-ninth birthday, as:

[0548] =A_max−a₁+1

[0549] Initially, the system uses the regulatory guideline formulas to develop an estimate of the appropriate insurance to cash value relationship. The system calculates estimates of the regulatory guideline premium amounts, and uses them as a basis for computing cash value and death benefit amounts in the system in FIG. 3B-5. Block 110. The initial estimates use approximations of the Guideline Single, Guideline Level, and Guideline Seven Pay Premium amounts. The variables for these approximations, and formulas for computing them are set out below.

[0550] gSP. This is a variable for the estimated Guideline Single Premium (GSP). The variable is calculated as a fraction of coverage, expressed in dollars. It is first calculated as: $\#=\frac{\sum _{t=1}^{N_{\max }}\frac{\mathrm{tP}\left(t-1\right)\times Q\left(t\right)}{{\left(1+\mathrm{insp}\right)}^t}}{1-\mathrm{LPCTA}\left(1\right)}$

[0551] gLP. This is the variable for the estimated Guideline Level Premium (GLP). The variable is calculated as a fraction of coverage, expressed in dollars. It is calculated as: $\#=\frac{\sum _{t=1}^{N_{\max }}\frac{\mathrm{tP}\left(t-1\right)\times Q\left(t\right)}{{\left(1+\mathrm{inlp}\right)}^t}}{\sum _{t=1}^{N_{\max }}\frac{\mathrm{tP}\left(t-1\right)\times \left[1-\mathrm{LPCTA}\left(12t-11\right)\right]}{{\left(1+\mathrm{inlp}\right)}^{t-1}}}$

[0552] 7LP (or “SLP”): This is the variable for the estimated Guideline Seven Pay Premium. This variable is likewise calculated as a fraction of coverage, expressed in dollars. It is calculated as: $\#=\frac{\sum _{t=1}^{N_{\max }}\frac{\mathrm{tP}\left(t-1\right)\times Q\left(t\right)}{{\left(1+\mathrm{inlp}\right)}^t}}{\sum _{t=1}^7\frac{\mathrm{tP}\left(t-1\right)}{{\left(1+\mathrm{inlp}\right)}^{t-1}}}$

[0553] SA: This is the variable for the policy's Specified Amount. The Specified Amount, a common life insurance expression, is equal to the basic, stated policy death benefit (the face amount of the policy.) The policy death benefit will remain equal to the Specified Amount until such time as changes in cash value cause it to change. Withdrawals of cash value or cash value growth may cause an increase or decrease in the death benefit. The Specified Amount appears on page three of a life insurance policy. The Specified Amount formula uses boolean logic designed to assure compliance with the regulatory guidelines. It is computed as: $=\max \left\{\mathrm{PRIN},\frac{\mathrm{LIFPAY}}{\mathrm{SLP}},\min \left[\frac{\mathrm{LIFPAY}}{\mathrm{gLP}},\frac{\mathrm{LIFPAY}}{\left(\frac{\mathrm{gSP}}{\mathrm{LNUM}}\right)}\right]\right\}$

[0554] The system records which of the three cases determined SA.

[0555] # LOAN(n): This is the variable for new borrowings, in the beginning of month n, as computed in FIG. 3B-5, Block 110. $\begin{array}{c}\mathrm{LOPT}=0\text{:}\mathrm{LOAN}\left(n\right)=0,\mathrm{all}n\\ \mathrm{LOPT}=1\text{:}\mathrm{LOAN}\left(n\right)\\ =\mathrm{PRIN},n=\mathrm{MTH}+1\\ =\mathrm{TOTLOAN}\left(n-12\right)\mathrm{xiCL},n=\mathrm{MTH}+13,\mathrm{MTH}+25,\\ \mathrm{MTH}+37,\dots \\ =0,\mathrm{elsewhere}\end{array}$

[0556] The system uses an alternative formula for policy loan interest if policy loan interest is in advance rather than in arrears. This formula assumes interest on policy loans is paid annually in arrears.

[0557] LOPT=2:LOAN(n)

[0558] =PRIN×iM+TOTLOAN(n−12)×iCL

[0559] n=MTH+1,MTH+13, MTH+25,MTH+37, . . .

[0560] =0, elsewhere

[0561] This computation assumes mortgage interest is paid annually in arrears. The system uses a second formula if policy loan interest is paid in advance.

[0562] # TOTLOAN(n): This value presents total borrowings, in the beginning of month n:

[0563] =TOTLOAN(n−1)+LOAN(n),n>0

[0564] =0, n=0

[0565] This value becomes non-zero for LOPT=1 or LOPT=2 at n=MTH+1 and normally changes only annually.

[0566] LOANBAL(n): This variable computes the loan balance, including accrued interest, in the beginning of month n. This formula assumes interest is paid in arrears.

[0567] =TOTLOAN(n),n=1, 13, 25, 37, . . .

[0568] =LOANBAL(n−1)×mCL, otherwise.

[0569] # qx(n): This variable computes the monthly cost of insurance. $=\frac{\frac{\mathrm{Qx}\left({\hat{a}}_n\right)}{12}}{1-\frac{\mathrm{Qx}\left({\hat{a}}_n\right)}{12}}$

[0570] The variable qx(n) is independent of loan or mortgage value, and is computed for a prospective applicant for a product, and saved by the system. The system also allows for qx(n) to be table-driven instead of being computed as above from Qx. In this case, tables qx(a), as follows, are present instead of Qx.

[0571] :{overscore (q)}x(a) This is the monthly cost of insurance for a person of attained age a. The system uses the same kind of multiple tables with selection factors, etc., that apply to Qx, including state-dpendent unisex requirements and tables. This permits carriers which have non-standard actuarial approaches to the conversion of annual mortality figures into monthly figures to use the system. In this case:

[0572] qx(n)=qx(â_n)

[0573] The cash value computations in FIG. 3B-5, Block 110 are iterative. The system starts with CV(0)=0. The cash value at the start of the contract is always equal to zero.

[0574] CVI(n): This is an intermediate value, calculated for the beginning of month n:

[0575] =CV(n−1)+LPAY(n)−LEXP(n)−[LPCT(n)×LPAY(n)]

[0576] AAR(n): This variable computes the amount by which the carrier is at risk in any month n. It is calculated as: $=\max \left\{\frac{\mathrm{SA}}{\mathrm{mlp}}-\mathrm{CVI}\left(n\right),\left[\frac{\mathrm{CORR}\left({\hat{a}}_n\right)}{100}-1\right]\times \mathrm{CVI}\left(n\right)\right\}$

[0577] COI(n): This variable computes the cost of insurance charge for a given month n

[0578] =qx(n×ARR(n)

[0579] The following variables are used for the computation of cash values and interest rate breakpoints. These arc calculated net of policy loans. Breakpoint formulas include:

[0580] NCV(n): This is the net pre-interest cash value, end of month n. It is computed as:

[0581] =CVI(n)−COI(n)−LOANBAL(n)

[0582] NCVI(n): Part 1, up to the break:

[0583] =min(NCV(n),iCbreak)

[0584] NCV2(n): Part 2, above the break:

[0585] =max(0,NCV(n)−iCbreak)

[0586] INTC(n): This is the variable for interest credited in a given month n. It is computed as:

[0587] =LOANBAL(n)×iL_m+NCV1(n)×iC1m+NCV2(n)×iC2_m

[0588] CV(n): This is the variable that computes the end of monthly life insurance cash value. It is equal to:

[0589] =CVI(n)−COI(n)+INTC(n)

[0590] MINS(n): This is the variable for the life insurance death benefit for month n. It is the larger of the estimated guideline amount calculated in SA, or the insurance corridor amount, multiplied by the Cash Value:

[0591] =max{SA,CORR(â_n)×CV(n)}

[0592] LSURR(n): This is the after-tax cash surrender value, at the end of month n, which is the amount the policyholder would receive if he or she were to surrender the contract and pay his/her tax obligation at the end of month n.

[0593] =CV(n)−TAXRATE×max{0,CV(n)−LBASIS(n)}

[0594] LSNET(n): This is the net after-tax surrender value, at the end of month n, assuming the policyholder surrenders the contract and pays off the policy loan and the tax liability at the end of month n.

[0595] =LSURR(n)−LOANBAL(n)

[0596] The homeowner's surrender value includes the present value of the future annuity payments plus LSURR(n) and LSNET(n) in those years when an annuity is present.

[0597] The system's first trial as to the premium amount needed to fund the policy is calculated using the 7LP formula. The system replaces Q(t) with Qx(a_t) for this computation; if only a value for qx(a_t) is available, the system uses 12×qx(a_t). The system sets inlp equal to (iC1+iC2)2, and sums to LNUM instead of using 7 in the denominator.

[0598] For any solved policy in FIG. 3B-6, Block 130, the system must check that it conforms with regulatory limits on the size of premium for the policy cash value. The original gSP and gLP rates were approximations. The estimated guideline amounts are rates, expressed as dollars of premium divided by dollars of insurance, where the estimated GLP=gLP×SA, and the estimated GSP=gSP×SA. The system next finds the actual GLP and GSP for this policy in FIG. 3B-6, Block 128, both to report to the carrier, and to check that the illustrated policy conforms to tax rules governing insurance in FIG. 3B-6, Block 130. To do this, the system reruns the insurance LIFPAY calculation, but with a change of certain parameters and tables, and with a new target.

[0599] In these re-illustrations:

[0600] The system saves the entire results of the preceding insurance computation in FIG. 3B-6, Block 128, since they may remain valid. In particular, the system lets SA_r=SA, LIFPAY_r=LIFPAY, each from the previously solved insurance run.

[0601] The system then uses qxg(â_n) tables instead of the tabulated or computed qx(n) values. The systems checks, however, the qx guarantee flag for guideline premiums. If it is set, the system uses qx(n) instead of qxg(ân) in the first year. For COI(n), n=1 to 12, the guaranteed rate is assumed to be equal to the current rate, for those carriers that guarantee the first year's interest crediting rate.

[0602] The system freezes SA in the GSP/GLP runs at SA_rIt does not use the formula previously shown for the computation of SA. Therefore, the system skips the computations for Q(t), P(t), tp(t), gSP, gLP, 7LP, and SA in this iteration.

[0603] The target in each iteration is to find the value for LIFPAY that achieves CV(12N_max)=SA_r. The cash value at the end of the insurance policy must equal the Specified Amount the system just projected and saved. None of the standard insurance targets apply. However, the system checks and reports if the projected cash value drops below zero CV(n)<=0, any n, throughout the projection.

[0604] The system does not compute loans in this iteration. LOAN, TOTLOAN and LOANBAL are equal to zero, for all n. The system also does not compute LBASIS(n), MINS(n), LSURR(n), or LSNET(n).

[0605] For The Actual Regulatory GSP: The system first assumes:

[0606] LNUM=1, is a single premium, in the first month of the policy.

[0607] iC1=iC2=max(insp,IRS_—insp)

[0608] where IRS_insp is a system parameter. Currently, this value is 6 percent.

[0609] The resulting LIFPAY computed by the system is the new Guideline Single Premium, GSP_a.

[0610] For The Actual Regulatory GLP. The system assumes:

[0611] LNUM=min(N_max,95−a₁+1)

[0612] iC1=iC2=max(inlp,IRS_—inlp)

[0613] where IRS_inlp is a system parameter. This value is usually four percent for most carriers. The resulting LIFPAY computed by the system is the new Guideline Level Premium, GLP_a.

[0614] Both GSP_aand GLP_a, as finally computed, are reported to the carrier as part of the insurance issuance process. They are also used to confirm that the originally saved illustration values met the guidelines, as follows:

[0615] The system computes new guideline ratios, $\mathrm{gSP}=\frac{{\mathrm{GSP}}_a}{{\mathrm{SA}}_r}$ $\mathrm{gLP}=\frac{{\mathrm{GLP}}_a}{{\mathrm{SA}}_r}$

[0616] and checks that the original SA formula continues to be met. For example, using the original LIFPAY and the new gLP and gSP, the system checks whether it computed the same SA_r. Also, the system checks the cumulative premiums each year:

[0617] t×LIFPAY_r≦max(GSP_a·t×GLP_a), t=1 to LNUM_r

[0618] where LNUM_ris the LNUM from the original illustration.

[0619] The technical tax rule that must be met is that the cumulative premiums paid, as of year t, are less than or equal to max(GSP_a·t×GLP_a). However, since the policies illustrated will initially require a fixed premium per year, in order to comply with other regulatory requirements previously noted, the cumulative premium paid is quickly computed by the system. If the test is met when the last premium is paid, at LNUM_r, it must be met thereafter. Thus, a simpler two part test suffices: (1) if LIFPAY_r≦GLP_a·the test is met. Otherwise, (2) if LNUM_r×LIFPAY_r≦GSP_a·the test is met.

[0620] If any of these three tests is not met in FIG. 3B-6, Block 130, the system uses the new gLP and gSP in place of the last in Block 132, whether from their approximation formulas or the last iteration, and re-solves the insurance computation originally saved, returning to FIG. 3B-5, Block 110. Then the system repeats the GSP_aand GLP_adetermination and test for the new SA_rresulting from the re-illustration. The system repeats this computation as required. Once the tests are all met, the system saves the gLP_aand gSP_avalues.

[0621] When it has completed the aforementioned regulatory guideline computations, the system computes a projection of insurance cash values based upon carrier guaranteed rates for the minimum credited interest and maximum mortality charges in Block 133. This projection is unrealistic and will look unattractive to the applicant. (See Guaranteed Life Insurance Values, Specimens 2-7.) However, by law it must be presented to the prospective applicant. The cash value will in many instances drop to below zero before the end of the required period. The system continues the computation, but the display shows the insurance lapsing in the first month the cash value is negative.

[0622] This projection therefore uses the LIFPAY and LNUM for the actual projected insurance premium values, the qxg(â_n) table(s) in place of qx(n) table/formula, and iC1=iC2=inlp. However, if the iC year-one guarantee flag for this projection is set because the carrier guarantees its first year rate, the system uses iC1 and iC2 for n=1 to 12. These are used to compute INTC(n). Similarly, if the qx year-one guarantee flag for this projection is set because the carrier guarantees the first year mortality changes, the systems uses qx(n) instead of qxg(â_n), for n=1 to 12 for the first year.

[0623] The system also computes the required policy cost indices, see Block 134, FIG. 3B-6, for each insurance product illustrated. These are the Surrender Cost Index At 5%, also called the Interest Adjusted Net Cost Index (IANC), and the Net Payment Cost Index At 5%. The formulas are noted below:

[0624] Surrender Cost Index At 5% at year t: $\mathrm{IANC}\left(t\right)=\frac{\mathrm{LIFPAY}\sum _{i=1}^{\mathrm{LNUM}}{\left(1+\mathrm{INVI}\right)}^{t-i+1}-\mathrm{CV}\left(12t\right)}{\mathrm{SA}\sum _{i=1}^t{\left(1+\mathrm{INVI}\right)}^t}$

[0625] where INVI is the investment interest rate, here assumed to be 5%. The cash value term, CV(12t), is the illustrated cash value at the end of policy year t. The Surrender Cost Index is typically computed for years 10 and 20 of the policy.

[0626] Similarly, the Net Payment Cost Index (NPI), Formula is identical to IANC(t) except that the cash value term CV(12t) is omitted, as shown below:

[0627] Net Payment Cost Index At 5% at year t: $\mathrm{NPI}\left(t\right)=\frac{\mathrm{LIFPAY}\sum _{i=1}^{\mathrm{LNUM}}{\left(1+\mathrm{INVI}\right)}^{t-i+1}}{\mathrm{SA}\sum _{i=1}^t{\left(1+\mathrm{INVI}\right)}^i}$

[0628] If in FIG. 3B-7, Block 155, the prospective applicant wishes to see a comparison with a larger up-front payment than the Ryan Mortgage requires, or if he or she wishes to see an equal up-front payment comparison for the sponsored case, the following describes how the system computes the additional up-front payment in the Ryan Mortgage.

[0629] The variables below are used by the system in this computation:

[0630] CLDP: This is the applicant-specified up-front payment amount which is:

[0631] ADDEQ: This is a variable for additional equity achieved by applying that part of the up-front payment not going towards the premium to reducing the original amount borrowed:

[0632] Then, the system reduces PRIN by ADDEQ, and solves for the new LIFPAY and, if unsponsored, the annuity for the new DOWN1. This gives a new ADDEQ.

[0633] To bracket the final value and apply interpolation, rather than the asymptotic approach that simple iteration would achieve, the system uses a first try of PRIN₁=PRIN₀−CLDP. The system assumes all the prospective applicant's payment is used to reduce principal. Thus, the system has two end values:

[0634] ADDEQ=0: ERR=CLDP−DOWN1₀(or, LIFPAY₀)  (1)

[0635] ADDEQ=CLDP: ERR=−DOWN1₁(or, −LIFPAY₁)  (2)

[0636] where DOWN1₀(or LIFPAY₀) are the original insurance values, and DOWN1₁or LIFPAY₁are the values obtained by applying the entire CLDP to reduce PRIN. Then the system interpolates to ERR=0, to obtain the next trial for ADDEQ. As for the aforementioned insurance illustration iterations, quadratic interpolation is used to accelerate convergence.

[0637] Set out below are the formulas for computing the targets referred to in FIG. 3B-4, Block 104, and which are tested against in FIG. 3B-6, Block 130.

[0638] The basic target that a universal life policy must meet is that the premium must be adequate to provide a positive net cash value at all times.

[0639] min_n{CV(n)−LOANBAL(n)}>0, n=1 through 12N_max

[0640] Whether or not there is a loan balance, of course, depends on which LOPT is in use. If there is none, the system test is min_n({CV(n)}>0, for all n.

[0641] For each of the LOPIT values, this basic test is combined with others, as follows:

[0642] LOPT=0:

[0643] (1) Basic test:

[0644] min_n{CV(n)}>0, n=1 through 12N_max

[0645] (2) The guideline test for the ability of the cash surrender value to repay the mortgage is:

[0646] LSURR(MTH)=PRIN

[0647] Where the test value is V=LSURR(MTH)−PRIN, where V=0.

[0648] If test (2) is not met, the system scales LIFPAY by the factor $\frac{\mathrm{PRIN}}{\mathrm{LSURR}\left(\mathrm{MTH}\right)}.$

[0649] If this does not bracket V=0, the system repeats the computation with a double correction, ${\left[\frac{\mathrm{PRIN}}{\mathrm{LSURR}\left(\mathrm{MTH}\right)}\right]}^2.$

[0650] Once the value is bracketed, the system applies interpolation on V to find the correct LIFPAY.

[0651] LOPT=1:

[0652] (1) Basic test:

[0653] min_n{CV(n)}>0, n=1 through MTH

[0654] (2) The guideline test for the repayment of the mortgage:

[0655] CV(n)≧LOANBAL(n), n=MTH+1, . . . , 12N_max

[0656] The test value for this computation is: V=min_n{CV(n)−LOANBAL(n)}

[0657] If test (2) is not met, then the systems scales LIFPAY by the factor $\frac{\mathrm{LOANBAL}\left(n_0\right)}{\mathrm{CV}\left(n_0\right)},$

[0658] where n₀is the month in which the minimum value of V was reached. As before, the system uses double correction as needed to bracket V=0. The system checks for CV(n₀) going negative and, if it does, uses a much larger LIFPAY instead of using a computed factor. Then, the system interpolates.

[0659] The system then performs Check (1). If this condition is not met, the system proceeds per LOPT=0.

[0660] LOPT=2:

[0661] (1) The Basic test is the same as LOPT=1.

[0662] (2) There are two guideline tests. The first, V1, is the same as V for LOPT=1. The second is the sufficiency of the insurance death benefit to, eventually, pay off the mortgage and the borrowing against the policy's cash value, and is expressed as:

[0663] MINS(n)≧LOANBAL(n)+PRIN, n=MTH+1, . . . , 12N_max.

[0664] The test value is:

[0665] V2=min_n{MINS(n)−LOANBAL(n)−PRIN\}.

[0666] The goal is to achieve V1=0 or V2=0, and the other ≧0.

[0667] If in FIG. 3B-5, Block 118, both V1 and V2 are less than zero, the system scales LIFPAY by the larger of: $\mathrm{V1}\text{:}\frac{\mathrm{LOANBAL}\left(n_0\right)}{\mathrm{CV}\left(n_0\right)},n_0=\mathrm{month}\mathrm{of}\mathrm{minimum}\mathrm{V1}$ $\mathrm{V2}\text{:}\frac{\mathrm{LOANBAL}\left(n_0\right)+\mathrm{PRIN}}{\mathrm{MINS}\left(n_0\right)},n_0=\mathrm{month}\mathrm{of}\mathrm{minimum}\mathrm{V2}$

[0668] and, as necessary, uses double correction to bracket V1 (or V2)=0.

[0669] If both V1 and V2 are greater than zero, the system scales LIFPAY by the smaller of these two ratios. If one of V1 and V2 is less than zero, but not the other, the system uses the ratio for that one which is less than zero. The system once again uses double correction if necessary to achieve bracketing If CV(n₀) is negative, or MINS(n₀) is negative, the system uses a much larger fixed factor times LIFPAY instead of attempting to scale by a computed factor.

[0670] If the LIFPAY range that brackets V1=0 also yields V2≧0 at both ends, the system only needs to solve for the former. Otherwise the system interpolates with each, and uses the larger LIFPAY. Eventually, one dominates.

[0671] The system once again, tests (1). If it is not met, it proceeds per LOPT=0. In general, the month at which the auxiliary tests of LOFT=1 and 2 yield the minimum V (or V1 and V2) should be at 12N_max.

[0672] The selection of a life insurance product also selects the companion annuity if one is needed. Annuity parameters, tables, etc., therefore, are stored with the companion product as product parameters, tables, etc.

[0673] In FIG. 3B-7, Block 146, the system computes the annuity from basic expense, cost, and interest values, or uses a table-driven set of pre-computed values provided by the carrier. The selected product data file indicates which computational approach is used. The following variables are used to compute the annuity for a lump-sum premium payment plan.

[0674] ATYPE: This is the annuity type flag. It indicates whether the annuity computation for that product is to be made by formula, or is to be table driven.

[0675] NUM: This is the variable for the number of annuity payments. This value is equal to LNUM-1, one less than the number of insurance payments. The system default is three.

[0676] ANNPAY: This is the variable for the annual annuity payment. This value is equal to LIFPAY, the required life insurance (annual) premium.

[0677] APCTAX: This is the variable for the annuity initial tax charge, expressed as a percentage of annuity premium. Annuity taxes differ for each state. This variable is independent of product.

[0678] iA: This is the annual annuity credited rate expressed as a percentage. It is the rate of interest earned by the funds invested in the annuity. This rate varies by product.

[0679] APCT: This is the annuity initial expense, expressed as a percentage of annuity premium, for this product.

[0680] ASELEXP: This is the annuity selling expense. This is a fixed dollar amount and normally applies only in the first month of the first year.

[0681] AMNTEXP(n): This is the annuity maintenance expense. It is also a fixed dollar amount. Depending on the product, it may be an annual charge, in the first month of each year, or a monthly charge. It may be constant or variable, depending on the size of the annuity. A value may be present for (12×NUM)+1, i.e. in the month the last annuity payment is received.

[0682] AMTH: This is the variable for the number of months in the annuity. It is computed as:

[0683] =(12×NUM)+1

[0684] iA_M: This is the variable for the monthly annuity credited rate. It is computed as:

[0685] =(1+iA)^{{fraction (1/12)}}−1

[0686] APCTOT: This is the total percentage of annuity initial expense. It reflects the carrier's charges and annuity taxes:

[0687] =APCT+APCFAX

[0688] AEXP(n): This is the total carrier's fixed charges in the annuity for month n. It is computed as:

[0689] =ASELEXP+AMNTEXP(n), n=−1

[0690] =AMNTEXP(n), n=2, . . . , AMTH

[0691] DOWN1: This is the variable for the up-front payment amount. This is the amount the applicant pays, at the start, to: (1) pay the first year's insurance premium; and (2) buy the annuity that will pay the rest of the premiums. It is computed as: $=\frac{\begin{array}{c}\left[\mathrm{ANNPAY}\times \left\{1-\mathrm{APCTOT}+\sum _{t=1}^{\mathrm{NUM}}\frac{1}{{\left(1+\mathrm{iA}\right)}^t}\right\}\right]+\\ \sum _{n=1}^{\mathrm{AMTH}}\frac{\mathrm{AEXP}\left(n\right)}{{\left(1+{\mathrm{iA}}_m\right)}^{n-1}}\end{array}}{1-\mathrm{APCTOT}}$

[0692] DOWN1A: This is the variable for the annuity portion of the lump-sum prepayment. It is computed as: $=\frac{\left[\mathrm{ANNPAY}\times \sum _{t=1}^{\mathrm{NUM}}\frac{1}{{\left(1+\mathrm{iA}\right)}^t}\right]+\sum _{n=1}^{\mathrm{AMTH}}\frac{\mathrm{AEXP}\left(n\right)}{{\left(1+{\mathrm{iA}}_m\right)}^{n-1}}}{1-\mathrm{APCTOT}}$

[0693] The applicant pays taxes on annuity interest earned received in the annual proceeds in the month the annuity payment is made. This is the beginning of the first month, in each year, starting in the second year. For tax purposes, the total income of the annuity is shown as received by the applicant in equal annual payments.

[0694] ATAX(n): This is equal to the taxes payable on the annuity interest income. It is computed as: $\begin{array}{c}=\max \left\{0,\left(\mathrm{ANNPAY}-\frac{\mathrm{DOWN1A}}{\mathrm{NUM}}\right)\times \mathrm{TAXRATE}\right\},\\ n=13,25,...,\left(12\times \mathrm{NUM}\right)+1\\ =0,\mathrm{elsewhere}\end{array}$

[0695] Monthly Interest Rates: The system uses the interest rate, iA, in its monthly equivalent multiplier,

[0696] (1+iA)^{{fraction (1/12)}}−1=iA_m

[0697] ABASIS(n): This is the remaining basis in the annuity as of month n. It is equal to: $=\mathrm{DOWN1A}\left[\frac{\mathrm{NUM}-t}{\mathrm{NUM}}\right],$

[0698] where t=int[(n−1)/^{{fraction (1/12)}}] is the number of whole years elapsed prior to month n, the number of payments made to date.

[0699] ABAL(n): This is the remaining annuity balance at the end of month n. It is computed as:

[0700] ABAL(0)=DOWN1A=(1−APCTOT)

[0701] ABAL(1)=[ABAL(0)−AEXP(1)]×(1+iA_m)

[0702] ABAL(n)=[ABAL(n−1)−AEXP(t+1)−ANNPAY]×(1+iA_m),

[0703] n=12t+1, for t=1, 2, . . . , NUM−1

[0704] ABAL(n)=ABAL(n−1)×(1+iA_m), otherwise, n≧12×NUM

[0705] This reflects: (1) AEXP(t) is charged in the first month of year t, and; (2) ANNPAY is paid out in the first month of each year t, following year 1.

[0706] ASURR(n): This is the after-tax surrender value, at the end of month n. Since this is the amount the policyholder's estate would receive in the event of his or her death, it is also the annuity death benefit in month n. Because the annuity is not insurance, the gain on the annuity is taxable.

[0707] ABAL(n)−TAXRATE×max{0, ABAL(n)−ABASIS(n}

[0708] The following are inputs and parameters for table-driven annuity computations.

[0709] ARATE(NUM): This is the gross annuity conversion rate for table-driven annuities. This number is stored exclusive of state tax, and is expressed in terms of dollars of premium per dollar of annual payment, for an annuity with NUM annual payments.

[0710] DOWN1A: This is the annuity portion of the lump-sum prepayment for a table-driven annuity. It is computed as: $=\mathrm{ARATE}\left(\mathrm{NUM}\right)\times \frac{\mathrm{ANNPAY}}{1-\mathrm{APCTAX}}$

[0711] DOWN1: This is the total down payment for a table-driven annuity. It is computed as:

[0712] =DOWN1A+ANNPAY

[0713] ATAX(n), ABASIS(n): These are computed in the same way in a table-driven annuity as in a computed annuity.

[0714] ABAL(n): This is the before-tax annuity surrender value, at the end of month n. For a table-driven annuity, this is computed as:

[0715] =(NUM−T_n+1)×ANNPAY, 0<n≦12NUM

[0716] where T_n=int[(n+11)/12]

[0717] ASURR(n): For a table-driven annuity, this is calculated in the same manner as for a computed annuity, using the preceeding ABAL(n).

[0718] The system includes two tables of mortgages to illustrate to the prospective applicant. One is for use in illustrating a conventional mortgage shown in FIG. 3B-7, Block 150, and one is for a balloon payment mortgage of the type made possible by this invention shown in FIG. 3B-7, Block 148. Selection from the system is based on whether a particular mortgage is available to the prospective applicant in the state in which the property is located and the mortgage duration. The system default for comparisons is to select the conventional mortgage most closely matching the Ryan Mortgage assumptions.

[0719] In order to provide a comparison of the economic benefits of the Ryan Mortgage, the system illustrates the conventional mortgage together with the prospective applicant purchase of life insurance with death benefit equal to the outstanding mortgage balance. This is compared to the Ryan Mortgage. The term insurance cost is computed using the same mortality charges used for the universal life product to which it is being compared. To this end, certain additional parameters are added to each product's description, for use in computing the conventional mortgage's life insurance costs.

[0720] The system, with a lump-sum prepayment illustration comparison to a conventional mortgage, solves for a conventional mortgage with the same down payment, in terms of initial cost, as the Ryan Mortgage. However, since sponsored plans allow for insurance premiums to be spread over a longer period with no annuity purchase, the initial Ryan Mortgage up-front payment may be lower than the five percent minimum down payment a standard mortgage will permit. In that case, the system assumes the minimum down payment, five percent (or the minimum available on the market), is to be paid, and the comparisons will show the lower up-front payment advantage of the Ryan Mortgage. Otherwise the comparison will be based on like amounts.

[0721] Any Ryan Mortgage available in a particular location may be used with any insurance product available in that particular location. However, if selecting the best combination, the system will default to insurance and mortgage products tied to the same index.

[0722] The system computes the various elements of the mortgage transaction in FIG. 3B-7 Blocks 148 and 150.

[0723] INITPAY: This is the variable for the conventional mortgage, from the insurance illustration, for the amount to be used for the comparison of the up-front payment:

[0724] =LIFPAY, sponsored Ryan Mortgage (no annuity)

[0725] =DOWN1, not sponsored (annuity+LIFPAY)

[0726] PTS: This is the variable for mortgage points. It is expressed as a percentage of the mortgage principal. It is retrieved either as an average value from a database of closing costs (FIG. 3A-1, Block 78 or FIG. 3B-2, Block 190) or if known, entered by the user in FIG. 3B-2, Block 188. Mortgage principal, and therefore the cost of mortgage points, will differ between the Ryan and conventional mortgages. Some mortgage points are deductible as interest, while others are non-deductible fees. A flag is set if, for this mortgage, all or part of the PTS is deductible interest, rather than a non-deductible fee.

[0727] PMIPCT: This is the cost of private mortgage insurance. Because of its enhanced security to lenders, this is not expected to be a cost with the Ryan Mortgage. Conventional mortgages typically require private mortgage insurance if the down payment amount is less than 20 percent of the purchase price of the home. The system allows an input in FIG. 3B-2, Block 182, but the default is 0.5 percent of the original mortgage balance annually until the mortgage balance goes below 80% of the original purchase price of the home. The system uses zero for the Ryan Mortgage. However, other values may be used for both the Ryan Mortgage and the conventional mortgage.

[0728] dpins: This is the down payment expressed as a percentage of property value, below which PMI must be paid. The system allows an input in FIG. 3B-2, Block 182, but the default is 20 percent. This is a system parameter.

[0729] dpmin: This is the minimum down payment permissible for this mortgage, expressed as a percentage of PRIN, the mortgage principal amount. The default minimum down payment is five percent. However, this may vary in the case of VA or other federal or state agency endorsed mortgages.

[0730] TRATE: This is the variable for the term mortality rate. It is used to adjust the Qx table as it applies to the equivalent term insurance. It varies by life insurance product.

[0731] TEXP: This is the variable for the fixed expense charges, charged by the carrier, for maintenance of the term insurance policy. This data is stored by product as a fixed dollar amount.

[0732] TLOAD: This is the variable for the term insurance load factor. It is expressed as a percentage of premium for each product.

[0733] iM: This is the variable for the nominal annual mortgage interest rate. It is converted to a monthly rate when used for monthly payment amounts as, for example, in FIG. 3B-7, Block 148. The formula for the monthly rate is: ${\mathrm{iM}}_m=\frac{\mathrm{iM}}{12}$

[0734] Because the Ryan Mortgage may be a variable mortgage, the system may contain three values. The first is the fixed mortgage rate if one is offered. The second is the increment to be added to the current index rate in order to obtain the first year's rate, and the third, the increment to be added in succeeding years. The current index rate (for example the Treasury rate index) is a system parameter, maintained as required by the Ryan Mortgage operations management. Fixed rate values are stored by product. Most variable rate mortgages include a low rate for the first year and a higher rate attached to an index in later years. In the equations for a variable rate mortgage, wherever iM_mis specified, the system uses ${\mathrm{iM}}_m\left(n\right)=\frac{{\mathrm{iM}}_t}{12},t=\mathrm{int}\left[\frac{\left(n+11\right)}{12}\right],$

[0735] for the value in month n.

[0736] NYR: This is the variable for the mortgage length in years, per insurance parameters. It is equal to MTH/12.

[0737] Each mortgage chosen in the system is qualified by, or selected by, state and length of mortgage, NYR. The system may accommodate from 15 to 40, in 5 year increments where 15, 20, 30 and 40 are the most common choice of lenders. The Ryan Mortgage table includes a ninety-nine year table entry which permits illustration of a mortgage for which the LOPT=1 and LOPT=2.

[0738] INITPAY is used to pay: (1) the actual up-front payment; (2) the initial points; and (3) the first year's PMI, if needed. Since the system cannot determine whether there is a PMI charge before it has computed the up-front payment the system solves it both ways.

[0739] INITPAY=DOWN+[PTS×MBAL(0)]+[PMIPCT×MBAL(0)]

[0740] where

[0741] MBAL(0)=Initial mortgage balance,

[0742] =PRIN−DOWN

[0743] The system solves the above formula with PMIPCT=0, then, if dpmin<dpins, the system checks $\frac{\mathrm{DOWNX}}{\mathrm{PRIN}}<\mathrm{dpins}.$

[0744] If this condition is true, the system solves for INITPAY again with PMIPCT at its standard value, and uses that result.

[0745] Then, the system takes DOWN=max(DOWNX, dpmin×PRlN) and recomputes INITPAY, if DOWN does not equal DOWNX.

[0746] MPAY: This is the monthly payment in a conventional mortgage. The conventional mortgage payment includes mortgage principal and interest as of the end of each month n. $=\frac{{\mathrm{iM}}_m\times \mathrm{MBAL}\left(0\right)}{1-{\left(1+{\mathrm{iM}}_m\right)}^{-\mathrm{MTH}}}$

[0747] For variable rate mortgages, iM_mis a function of the month number, and MPAY is recomputed each year, with MBAL(12t−12), t=1, 2, 3, . . . being the initial balance instead of MBAL(0), and MMH−12t+12 replacing MTH in the exponent, to compute MPAY(12t+i−12), i=1 to 12. In the system illustration, three values are defined for iM. The year 1 guaranteed rate, the assumed value, based on the current Treasury bill rate, in years 2 and on, and the maximum value required for truth in lending disclosure.

[0748] PRINRE(n): This is the reduction in mortgage principal during month n.

[0749] =MPAY−INT(n)

[0750] =MBAL(n−1)−MBAL(n)

[0751] INT(n): This is the interest paid at end of month n.

[0752] =iM_m×MBAL(n−1)

[0753] =MPAY−PRINRE(n)

[0754] so

[0755] INT(n)=iM_m×MBAL(n−1)

[0756] MBAL(n): This is the variable for mortgage principal, after the payment at end of month n.

[0757] =MBAL(n−1)−PRINRE(n)

[0758] PMI_tt: This is the annual PMI cost for year t. $=0,\mathrm{if}\frac{\mathrm{MBAL}\left(12t-12\right)}{\mathrm{PRIN}}\le \left(1-\mathrm{dpins}\right)=\mathrm{PMIPCT}\times \mathrm{MBAL}\left(12t-12\right),\mathrm{otherwise}$

[0759] PMI_1, is a prepaid item.

[0760] TERM_t: This is the annual term insurance premium for year t. $=\frac{\left[{\mathrm{Qx}}_t\left(a_t\right)\times \mathrm{MBAL}\left(12t-12\right)\right]+\mathrm{TEXP}}{1-\mathrm{TLOAD}}$

[0761] where Qx_t(a_t)=TRATE×Qx(a_t)

[0762] MPTOT(n): This is the conventional loan monthly payment. It is computed as: $\mathrm{MPAY}+\frac{{\mathrm{PMI}}_t}{12}+\frac{{\mathrm{TERM}}_t}{12}$

[0763] where t=int[(n+23)/12]

[0764] This shows the applicant prepaying, into escrow, next year's PMI premiums and paying annual term insurance premiums.

[0765] TAXDED_t: This is the annual tax credit used by the system in computing the mortgage after-tax cost. It is computed as: $=\mathrm{TAXRATE}\times \sum _{n=12t-11}^{12t}\mathrm{INT}\left(n\right),t>1=\mathrm{TAXRATE}\times \left[\sum _{n=1}^{12}\mathrm{INT}\left(n\right)+\left[\mathrm{PTS}\times \mathrm{MBAL}\left(0\right)\right]\right],t=1$

[0766] C. Discussion of Specimens

[0767] Specimens 1-7 provide samples of part of the output that would be printed on the user's printer.

[0768] Specimen 1 includes a sample of explanatory textual material that would be provided to introduce prospective applicants to the principal concepts involved in the use of life insurance as collateral for mortgages. Specimens 2-7 provide examples of the textual data which would be merged with illustration data in order to apprise prospective applicants of the potential advantages of using such a vehicle. Specimen 8 provides an example of textual data than can be merged with client data to provide a completed insurance application form. Specimen 9 provides an example of textual data that can be merged with client data to provide a completed loan application form. In this embodiment of the invention, it is contemplated that such textual data as is required by federal, state, and local regulations in the disclosure of loan, insurance, and other information to potential purchasers/borrowers would be automatically generated. This information might include data from insurers and their agents as to minimum interest crediting rates and maximum cost of insuance charges, truth in lending disclosure information from lenders, information from employers or financial institutions regarding premium payment guarantees, and all other information necessary for legal compliance, ethical business practice, and improved marketing through the provision of that information which may be most useful to the prospective applicant in financial planning and decision making.

[0769] D. Conclusion

[0770] In sum, the present invention involves a computer system used to support a financial innovation in which a mortgage is combined with an investment as a means for repaying the mortgage. This investment may collateralize the mortgage. Also, the investment may serve in place of a down payment for a conventional mortgage. The combination is tailored to meet the U S legal requirements for offering such a combination, but without the drawbacks of a cost containment clause approach. There are many variations on the theme of this invention, revolving primarily around variations in the kind of investment and variations in the kind of mortgage that are combined, and each variation can inherently impart computational and illustration requirements on the computer system. All involve providing the consumer access to an investment specifically designed for use in repaying a mortgage. Preferably, this investment is made available for purchases from multiple suppliers and is purchased and owned by the borrower.

[0771] As to the investment, in one case, it can be placed in a tax-favored account, such as an IRA, Keough, or 401K plan, but in another case, the investment can be held separately (i.e., in a manner that is not tax-favored).

[0772] In any of these cases, one alternative is for the investment to include a security or a security in combination with term life insurance. The security can be a zero coupon bond, such as a US Treasury Derivative or a municipal bond derivative, or the security can be a mutual fund.

[0773] Another alternative is for the investment to include an annuity. The annuity can be either an immediate annuity or a deferred annuity. Each can be used with or without term life insurance to assure that the mortgage is repaid upon the death of the borrower. The immediate annuity can be used to pay interest on the mortgage, more particularly where the mortgage is a home equity loan, and the term life insurance can be used in repaying the home equity mortgage. The deferred annuity can be a single premium, level premium, or variable premium annuity and may be used as a means for accumulating the necessary principal to repay the mortgage. Still another alternative is for the investment to include life insurance. The life insurance can be term or permanent. For the permanent life insurance, there can be one policy covering two insured lives (e.g., borrower and co-borrower), and such a policy can be a joint policy (which pays on the first death) or a joint and survivor policy (which pays on the second death). The policy may also be a single policy covering a single life. Either way, the permanent life insurance can be universal life insurance or variable life insurance, or the permanent life insurance can have at least one rider, such as a disability rider or an income rider.

[0774] For any of these cases and any of these alternatives, the mortgage can be more particularly defined as including a first mortgage, a home equity mortgage, a balloon repayment mortgage, a fixed interest mortgage, or a variable interest mortgage. As to the latter, the computer system can be programmed to compute a fixed payment, variable interest rate mortgage having extra amortization of principal when interest rates are low, and negative amortization of the principal when interest rates are high. Such a mortgage may be used together with permanent life insurance or a deferred annuity such that cash value accumulation from the investment is an offset to the negative amortization.

[0775] While this invention has been particularly shown and described with reference to a preferred embodiment, it will be readily appreciated by those of ordinary skill in the art that various changes and modifications may be made without departing from the spirit or scope of the invention. For example, the particular formats of the various display screens or output herein described may be modified, as desired. Likewise, the present invention should not be limited to the specific examples described herein since a greater or lesser number of options and functions for each of the menus and submenus that may be displayed on a CRT or VDT are within the scope of this invention. It is therefore, contemplated that the appended claims be interpreted as including the foregoing and other changes and modifications.

[0776] A. Discussion of Figures (FIGS.) and User Screens

[0777] The following includes a description of the manner in which the computerized insurance system of the present invention can be made and used. Some of the unique insurance functions that are carried out by this system are described in detail. Other transactions arc described more generally. In the interest of brevity, a highly detailed description of each and every one of the data transactions that could be performed by the computerized system of the present invention is not provided. But based upon the detailed description of certain examples, and the knowledge of those familiar with the life insurance industry, how to make and use the present invention should be readily apparent from the information provided herein.

[0778] Generally, the system includes a digital computer for receiving input data and for storing insured information and life insurance information. The digital computer is programmed with means, responsive to the data, the insured information, and to the insurance information, for computing an amount of universal life insurance premium sufficient to provide needed coverage and for generating an illustration of said life insurance as a means for understanding that coverage.

[0779] More particularly, the computer system requests that a user input data specifying the kind of insurance coverage (e.g., amount and duration of coverage) to be illustrated. This information is stored in the computer's database system Also, the computer is programmed to make calculations of universal life insurance policy riders and other data needed for the illustration. When all the values have been computed and written to the database, the computer will then combine them with text data to provide an illustration that can be printed out. This information will also be stored in a database and may be updated as needed.

[0780] Once the user, in consultation with a prospective insured, has designated the illustration as complete, data in the database can be merged with stored text data and other input data in order to produce insurance application forms. These forms can be printed out on the user's printer for signature by the prospective applicant and for subsequent processing by the system operator and the life insurance carrier.

[0781] It is to be explicitly understood that other implementations of the present invention, say, those using a different kind of digital computer, analogous hardware, multiple computer systems, comparable input and output, a computer program or computer programs written in a different language, a chip or chips, or a full or partially hardwired system replacing (and in accordance with) the logic of the computer program, are entirely acceptable and equivalent to the embodiment of the invention discussed herein. Also the invention can be implemented by hardwired logic in a handheld calculator. When software is loaded into, and running, a programmable computer, the software sets what in effect are many, many “switches,” and the result can be considered a new computer machine, with logic formed from the set switches. Instead of setting the switches, a circuit equivalent would be to hardwire the same or equivalent logic. Therefore, whether a configurable device is configured to the requirements of the present invention, or a device is constructed from scratch solely for meeting the requirements of the present invention, the result is effectively the same from an electrical signal processing standpoint. All these embodiments are different species of the present invention that are within the contemplated scope of the present invention.

[0782] Turning now to FIG. 1, an overview of a data processing system for producing a universal life insurance policy illustration system according to the present invention is shown. The Data Screen 4, discussed more fully hereinafter, can be produced on Terminal 2, for example an IBM compatible PC running Smarterm 340 (available from Persoft Corp.), with a Local Printer 5. e.g., a laser printer. Terminal 2 is linkable to Communications System 6. The Communication System 6 can be a modem and appropriate telephone lines. Communications System 6 is thus linkable to a Digital Computer 8, for example, a Digital Equipment Corporation VAX with a VMS operating system, ORACLE, and WordPerfect (e.g., 5.1) from WordPerfect Corporation. Digital Computer 8 is operably connected to Central Printer 9. The Digital Computer 8 contains a Central Processor 10 that is operable to obtain Insurance Product Information 12 (digital electric signals), and Insurance Premium Information 16. The respective information of Blocks 12 and 16 can optionally be accessible on line to other computers or stored as data in a System Database 17 of the Digital Computer 8.

[0783] Help 18 is a computerized system, preferably a context sensitive, hypertext-linked help system. Help 18 is available throughout the program.

[0784] Central Processor 10 is also operable to activate a function Print Out Insurance Application Forms 22 on Central Printer 9, which points to the function Fill In Forms 24 to selectively transmit Life Insurance Application Data To Carrier 28.

[0785] Further, Central Processor 10 can generate an illustration via a function Generate Illustration 30, which leads to Print Illustration 32 On Local Printer 5. The generated illustration can be saved in the Database 17.

[0786] When the system is accessed, the user must choose the transaction desired, and the selection will vary by the type of user. A management level user with a higher level of authority can update the data used in the illustration process. This data includes, but is not limited to: (1) insurance underwriting related values, including data regarding age, sex, and health characteristics, premium amounts to be applied, cash value accumulation factors, annual death benefit amounts, and typical policy interest crediting rates and insurance charges; (2) all of the illustrations saved in the Database 17, which may be used for manipulation and analysis in both the marketing and underwriting functions carried out by an insurance agent and carrier; and (3) administrative messages from other users. Otherwise, a non-management user of the system has access to only a portion of the system.

[0787] Prior to engaging the computerized aspects of the present invention, the user should consult with the prospective applicant to obtain such information as the prospective insured's age and sex, the amount of life insurance coverage desired, whether or not the individual has certain health problems which may require specialized insurance underwriting, whether or not the individual's employer is currently involved in a program that will sponsor reduced cost policy premiums, etc. After this information-gathering step has been completed, the user “logs on” at Terminal 2 by entering an assigned authorization password.

[0788] Turning now to FIG. 36, the user engages the system at Sign On To System 534. Branch 536, Authorized To Use System?, checks the password against stored passwords to determine whether the user is authorized to use the system. If the user is not authorized, Block 538 displays a message on the Terminal 2 indicating that the user should telephone the system owner/operator for further information. If the user is authorized, meaning that the password is recognized by the Digital Computer 8, the logic continues to Branch 542. However, prior to Branch 542, there is a logic entry point X4, which is described more fully below, but which generally is a connection from another part of the logic.

[0789] In any case, Branch 542 assesses the level of authority of the user from the password. In the present embodiment of the invention, there are two alternatives. First, as previously suggested, the user could be a “Client User,” in which case the logic connects to Client User Menu 546 as is subsequently discussed. Second, the user could be a “Super User,” having access to Super User Main Menu 544.

[0790] The Client User/Super User authorization system is included in a preferred embodiment of this invention to avoid security problems which would otherwise be created by different kinds of system users. Different degrees of authorization also provide for confidentiality of database information and, in the case of communications between the system owner/operator and users, allows each user to view only the information relating to the applicants for whom the user is providing illustrations.

[0791] From the Super User Main Menu 544, if -the user does not yet wish to log off at Block 558, there are a number of choices shown in User Screen 23.

[0792] The Super User Main Menu 544 permits access to Illustration 552 used to create an illustration. The user can also select Update Database 550, which is described with particularity hereinafter, but which generally is a list of tables that can be updated.

[0793] The user can select Analyze 548 to access various reports and statistics on illustrations. Electronic Mail 556 permits electronic communication between system users (see FIG. 1). Mail messages may be printed out via the Printers 5 and 9.

[0794] Returning to FIG. 2, the Electronic Mail 556 function utilizes the VMS operating system mail feature. The system has the ability to alert the user that a message is present in his or her electronic “mail box.” The system is capable of reading these messages from that file onto the user's screen, again allowing the user to move from screen-to-screen at his or her own speed. Once the user has completed a review of the data, one or all of the textual screens or “pages” may be printed at the Local Printer 5. The user may also write electronic messages to other users' mail boxes to be used in a similar manner.

[0795] At the completion of each subordinate function 548, 550, 552, 554 and 556, control is returned to the Super User Main Menu 544 via the Return To Main Menu Block 560.

[0796] Turning now to FIG. 37A where the logic proceeds from Illustration 552 of FIG. 36, the user is presented with a Select Type Of Illustration 562 submenu, shown as a portion of User Screen 23. Each of the functions of the submenu of Branch 568 will be presented in summary form here and described subsequently in detail. One function is Generate New Application Illustration 568, which is elaborated by FIG. 37B-1. This Function 568 permits the user to provide a detailed-presentation, tailored to the prospective applicant's own factual situation, of how universal life insurance might perform for the prospective applicant. This Function 568 also allows the user to save the illustration for later updates and to send the illustration to the Local Printer 5 for review by the prospective applicant.

[0797] A second function of Submenu 562 is Choose Existing Illustration 566, which goes to FIG. 37C-1. This Function 566 permits the user to update a previously saved prospective applicant illustration using different assumptions. This Function 566 also allows the user to quickly create an illustration which is different from one already saved by allowing the user to change only those few items that the prospective applicant may select, thereby avoiding the laborious process of entering all of the information required to create a new prospective applicant illustration. This 566 likewise allows the user to save a new illustration for later updates and to send the illustration to the Local Printer 5 to permit review by the prospective applicant.

[0798] A third function of Submenu 562 is the Print Existing Illustration Function which goes to 732 in FIG. 37 B-8. This allows the user to print the illustration on which he or she is currently working at any time, without having to move through other menus.

[0799] Returning to FIG. 37A, once the illustration has been compiled, the system presents a sequence of further options. Print Life Insurance Application 570, goes to FIG. 37D-1. This Function 570 allows the user to: (1) take the information generated and saved in the aforementioned illustration process, add to it, and merge it with life insurance application form text data to construct a customized, printed life insurance application form for signature; (2) electronically save in a file the customized life insurance application form; or (3) print out a partially completed or blank life insurance application form for later manual completion by the prospective applicant.

[0800] Review Insurance Product Developments 572 goes to FIG. 37E-1. This Function 572 allows the user to be quickly apprised of new developments in the insurance products used in forming the illustrations including, but not limited to, changes in interest rates credited by carriers on cash value reserves in the life insurance policies, new underwriting rules, new products provided by different carriers, etc. This information is available inside the Generate New Applicant Illustration 572 and Choose Existing Applicant Illustration 566 functions. Information may be read from the screen or printed out.

[0801] Proceeding to FIG. 37B-1 Generate New Applicant Insurance Illustration 576, the system offers maximum flexibility so that it may accommodate virtually any life insurance policy. In a preferred embodiment of the invention, the system also provides many tables for product-specific data such as mortality tables, expense charges, interest rates, and other insurance-related data. These tables can be used to store the different components of the carriers' products. Product specific “flags” or identifiers in the insurance computation formulas can be used to provide maximum flexibility in the way the system makes insurance computations. This allows the system to offer a method of customizing computations that are common to all life insurance products. This feature also makes it possible for a single computer to efficiently provide multiple life insurance product illustrations for multiple life insurance carriers. (In another embodiment of the invention, the system can use front-end network gateways to connect multiple carriers' computers to the Digital Computer 8.)

[0802] The system maintains security by affording limited access to carrier-specific databases. The system provides carriers exclusive access to their own databases, for example, via modern, by requiring a password. Only individuals authorized by the carrier can access or see the carrier's databases.

[0803] Block 576 leads to Block 578, which solicits the type of policy the user would have selected as displayed on the User Screen 24. The user may select to illustrate either a joint and survivor life insurance policy or an individual life insurance policy. If it is a joint and survivor policy, the system will require policy information for each of two insureds. This is because a joint and survivor policy pays a benefit only upon the death of both insureds. Such policies are often used in estate planning for the payment of estate taxes upon the death of, for example, a married couple or a father and a daughter. Such policies are often used to assure that an estate has sufficient liquid assets to pay estate taxes. In Block 580, Solicit: Insureds Information; Employer Information, and as shown in Screens 25 and 26, the system solicits the Prospective Insured's information including, but not limited to the Insured's home address and telephone number, age, sex, and date of birth, and place of work. In Block 582, and as depicted by Screen 27, the system goes on to solicit information regarding the prospective Insured's Health. These general questions regarding the prospective insured's health permit carriers to segment prospective policy applicants into preferred and non-preferred risks and thereby provide a more accurate projection of policy charges. Preferred risks are individuals who exhibit desirable underwriting characteristics, as exemplified by good health, for whom carriers may lay away smaller amounts in reserve against the future possibility of death Non-preferred risks include individuals who have physical conditions which tend to place them at greater risk of early mortality. Such characteristics might include, for example, being a smoker or having been diagnosed as having had a Heart Attack, Cancer, AIDS or some other life-threatening condition. In Blocks 584 through 586, the same questions are repeated for the prospective co-Insured in the Joint and Survivor branch of the logic.

[0804] If the response to the question posed in User Screen 24 is “Individual” then the system goes instead to Block 588, Solicit Insured Information; Employer Information and Block 590, Solicit Insured Answers to Four Underwriting Questions. This information will be used likewise by the system to determine whether the applicant(s) is (are) a preferred or non-preferred risk,-through comparison with specific desired responses, stored by product in System Data Base 17.

[0805] Once this information has been obtained, the system goes on to solicit what kind of illustration the user would like in Block 592, Solicit Insurance Requirements. An example of the Screen that appears in front of the user appears in Screen 28 Insurance Requirements—Insured. The system requires the user to designate two out of three key variables needed in the illustration of a life insurance policy. The user must enter onto the screen some combination of the Minimum Death Benefit, Cash Value (and year the Cash Value should be attained), and premium amount. For example, if given Death Benefit and Cash Value amounts, the system finds for any product stored in the system that amount of Premium (and the Number of Years it would be payable) needed for the system to achieve that goal. Similarly, if given the annual Premium, the Number of Years for which it would be paid and the Death Benefit desired, the system projects the Cash Value that would be associated with such a transaction.

[0806] In Block 594, Solicit Additional Coverages, the system solicits any additional coverages desired by the client. These coverages, made available in the form of riders to the base policy, will permit the user to augment his/her coverage under the terms of the policy in exchange for an additional premium payment. Screen 29, for example, shows several riders potentially made available by the system. A waiver of annual premium benefit provides that premiums will be automatically waived in the event of policyholder disability. The Accidental Death Benefit Rider allows for the payment of an additional death benefit in the event the insured dies in an accident. The Additional Death Benefit Rider allows the policyholder to obtain additional coverage during the early years of the policy. A Spousal Death Benefit allows the user to obtain coverage for his or her spouse in addition to his or her own coverage. This screen has an electronically highlighted area, a “form” or blank, appearing next to the description of each additional benefit. This “form” is filled in by the user with a dollar amount. The system interprets any blanks as zeros with the exception of Waiver of Premium, which requires a “Yes” or “No” response from the user before allowing the user to move onto the next screen. Screen 30 solicits information as to where the policy will be issued.

[0807] In Block 596, Store, all the information regarding the prospective Insured and, if one exists, the co-Insured, is stored in System Data Base 17 for later use by the system.

[0808] Moving now to FIG. 37B-2, the part of the system logic dedicated to identifying and verifying the existence a Corporate Sponsor is shown. In Block 602, Identify and Mark Corporate Sponsor, information regarding the employer of the prospective applicant is used by the system for the selection of a policy. For example, there exist policies that life insurance carriers sell in large volumes through sponsored corporate purchases. Often such policies are paid for via a monthly payroll deduction. Because such automatic payments reduce the costs of distribution to the carrier, such policies are often offered on a discount basis to any employee purchasing the policy.

[0809] Also, in the event that corporations are willing to offer corporate sponsored purchase of life insurance, life insurance carriers may be willing to relax their underwriting requirements. Relaxed underwriting requirements usually take one of two forms, simplified issue or guaranteed issue. In simplified issue underwriting, only a few simple questions (typically three or four) are asked of the prospective insured. In guaranteed issue underwriting, no questions apart from the age and sex of the prospective insured are asked.

[0810] The availability of this kind of underwriting may be beneficial to both the insurance carrier, which may profit from increased insurance sales by providing insurance policies with reduced underwriting in a high volume sale, and to the employer, which as a consequence may offer an enhanced product to its employees. In addition, this kind of underwriting creates another use for the prospective applicant's employment information. The employment information may be compared to a database of all those companies which offer corporate sponsorship of insurance purchases for their employees. If there is a match between the data provided concerning a prospective applicant's employer and information in the database, a corporate sponsor number will be used to identify a product which may be offered to the employee at reduced cost or with less stringent underwriting requirements.

[0811] A preferred embodiment of the invention involves a system of corporate sponsorship recognition involving the identification of companies providing both the aforementioned guarantee of premium payments and the creation of a defined group for the provision of specialized underwriting. Block 602 is dedicated to this task.

[0812] In Block 604, the system checks System DataBase 17 to see whether or not the Prospect Applicant Works with a company which provides corporate sponsored polices. If the Answer is “Yes,” then the system moves to Block 610, Select Corporate Sponsored Policy, and the system selects the appropriate corporate sponsored policy for that particular employer and writes the information to System DataBase 17. If the user and/or client is unsure, the system provides a list of Corporate Sponsors for him or her to consult in Block 606, Check List of Corporate Sponsors. In Block 608, Sponsor Selected?, the system checks to see if a Sponsor has been selected from the list of sponsored policies. If the answer is “Yes,” the system moves to Block 610, Select Corporate Sponsored Policy. If the answer is “No,” the system moves to Block 612, User Selects Policy or Best, as shown by Screen 31. If the response is “Best,” the system logic moves to 614, Select Best Product—whereupon the system solves for the policy that provides the best solution to the mathematical problem identified in Block 592, Solicit Insurance Requirements, given the underwriting information provided in Blocks 580, 582, 584 and 586 for joint and survivor policies and Blocks 588 and 590 for individual life insurance policies. “Best” is defined as the Minimum Premium amount if the dollar cost of the annual premium is the solved for amount. Otherwise, if the missing variables are cash value or death benefit, then the “Best” will be defined in terms of highest Death Benefit or Cash Value. Screen 32 provides a sample of a screen which is provided to the user to summarize all the information in the system prior to computing to find the “Best” policy. Because finding the best policy from many different policies can be a time-consuming process, this screen helps to avoid finding the “Best” policy using the wrong information. Screen 33 provides a representative example of a screen that appears before the user while the system is searching out the “Best” policy while Screen 34 shows the listing of the “Best” policies identified on the screen by the system based on a single premium payment.

[0813] If, on the other hand, the user wishes to select the policy from a number of different policies available in the system, then the system moves to Block 612, User Selects Policy. Screen 33 shows an example of a screen listing of available policies on the system. Policies are listed alphabetically, but the system provides an electronic policy search capability, allowing the user to search out all policies that match a given criterion such as carrier name, policy name, current life insurance policy interest credited rate, or guaranteed rate of interest in the life insurance policy.

[0814] Moving now to FIG. 37B-3, a schematic representation of the policy search function of the system is shown. Block 622, Corporate Sponsored/User Selection or Best Product, is the branch of the system logic that identifies whether the system is to illustrate one Corporate Sponsored/User Selected Product or whatever number of policies fit the “Best” criteria. Blocks 624, Solicit Best Product Criteria, and 626, Store Criteria, identify and store a count of products to be illustrated. Block 628, J Gets Total Number of Products Available, initializes a counter to keep track of the number of products meeting the desired criteria to be illustrated.

[0815] In FIG. 37B-4 a schematic representation of the insurance illustration function of the system is presented. First, in Block 640, the system retrieves all components needed for a projection of life insurance values: product-specific data from data tables, stored by product and carrier; information regarding the insured(s) and information regarding the prospective insured(s)' life insurance needs and other personal information as solicited and stored in FIG. 37B-1.

[0816] Moving now to Block 642, the system determines whether riders are present. If the answer is “No,” then in Block 644, Compute 1st Premium, Trial Guideline for Policy, the system computes its first guess as to the premium amount, or uses the premium amount previously provided by the user. The system also computes a trial guideline amount, an initial estimate as to actuarial regulatory guideline values. Using trial amounts speeds the illustration process, by reducing the number of iterations needed. These trial amounts, used at the onset of the illustration process, assure that policy values computed during the illustration process will in most cases ultimately comply with regulatory definitions of insurance during the first round of computations.

[0817] In Block 646, Compute Specified Amount, the system uses the guideline values previously computed to calculate a Specified Amount. The Specified Amount is the amount that the insurance company will pay the beneficiary upon the death of the insured. In most states the Specified Amount must by law appear on page three of a life insurance policy. The Specified Amount is a common life insurance variable and is equal to the basic, stated policy death benefit (the face amount of the policy). The policy death benefit will remain equal to the Specified Amount until such time as changes in cash value cause it to change. Withdrawals of cash value or cash value growth may cause a decrease or increase in the death benefit. Returning now to another branch of the logic, if the answer to the question “Riders Present?” is “Yes,” the system moves to 648 Compute 1st Premium Trial Guideline for Base Policy. With Riders present, the system calculates the Trial Guidelines and Premium amounts first for the base policy as previously described for a policy with no riders, then computes a Trial Guideline amount including the rider(s) in Block 650, then computes a Specified Amount including combined Rider and Base Policy values in Block 652, Compute Specified Amount w/Riders.

[0818] Then, in Block 654, Iterate on Target Value: Death Benefit, Cash Value or Premium, the system enters into an iterative illustration loop used to solve for the target value, refining its initial guesses as to Premium Guideline Amounts and Specified Amount, moving to FIG. 37F-1. In order to solve for these policy values the system computes additional guesses, and tests those guesses iteratively until it finds the appropriate target value. This kind of iteration is required because of the non-linear nature of universal life insurance policy values, as many of the policy values being solved for will have no closed form solution. Once the system has solved initial illustration and has a Premium and Specified Amount combination that corresponds to the target value, it saves it in Block 656, Save Specified Amount, Premium.

[0819] Next, in Block 658, Compute Guideline Single Premium for Base Policy, the system makes another illustration, this time calculating a Single Premium amount for the Base Policy assuming Guaranteed Carrier policy values, and corresponding to the Specified Amount previously computed in Block 656.

[0820] Moving now to FIG. 37B-5, in Block 644, Set Guideline Single Premium for Base Policy Equal to Premium variable, the system makes this equivalency, then in Block 666, Store, saves the information. Next in Block 670, Compute Guideline Level Premium for Policy, the system uses the aforementioned Specified Amount as the target value, and then finds the level annual premium amount, payable over the entire time of the illustration's duration and assuming guaranteed policy values, that would yield that Specified Amount. In Block 672, Store, the system saves this premium amount as well.

[0821] At Block 674, Riders Present, the system once again determines whether riders are present. If not, the system moves on to FIG. 37B-6. If so, the system moves on to Block 676, Compute Guideline Single Premium for Policy Including Riders. The calculation here is the same as that made in Block 658 except that this computation includes in the Specified Amount whatever additional coverage is provided for under the rider. In Block 678, Set Guideline Single Premium for Total Policy Equal to Premium Variable, the equivalency is made and the value is stored in Block 680. Similar steps are taken to compute values for the Guideline Level Premium including riders in Blocks 682 and 684. This value is stored in 686.

[0822] Moving on to FIG. 37B-6, Block 692, Recompute Specified Amount using Guideline Values, the system recomputes the Specified Amount, originally computed in Block 654, and saved in Block 656, this time using the Guideline Premium amounts computed in Blocks 658, 668, 676 and 682 if riders are present. The Specified Amount so calculated in Block 692 is then compared in Block 694 to the previously calculated Specified Amount. In Block 696, Are Two Amounts Equal?, the system tests for equivalency. If the answer is “Yes,” then the Specified Amount lies within actuarially defined regulatory guidelines for life insurance, and the system moves on to FIG. 37B-7. If the two values are not equal, the system in Block 698, First Pass, determines whether or not this is the first attempt at an illustration. If the answer is “No,” the system determines whether the Premium Values are equal in Block 700. If the answer is “No,” once again the system returns to either Z4 or Z5 depending on whether or not Riders are found to be present in Block 701. Both Z4 and Z5 are entry points for the illustration system in FIG. 37B-4.

[0823] If the two Specified Amounts are not equal in Block 696 and if this is not the first pass for the system in Block 698, the system returns to Z4 in the event that riders are present, and Z5 in the event that they are not, in Block 701.

[0824] Once the system has solved for the correct premium/cash value combination and has tested this value against regulatory requirements, the system carries out four other operations in FIG. 37B-7. First, it prepares a further illustration in Block 708. This illustration assumes that the policyholder pays the previously determined premium amount and maintains the desired death benefit. However, the illustration further assumes that the carrier pays only the minimum guaranteed interest crediting rate on policy cash value, and charges the maximum mortality charges possible under the terms of the insurance contract. Samples of these Guaranteed Values appear in Specimen 10.

[0825] Next, the system in Block 710 computes two policy cost indices designed to provide the prospective applicant with a bench mark for measuring product performance. The first index is the Surrender Cost Index which is 1000 times the present value of premiums paid discounted at five percent minus the present value of the end-of-period cash value divided by the present value of the death benefits. The second index, known as the Net Payment Cost Index, is equal to 1000 times the ratio of the present value of the premiums discounted at five percent to the present value of the death benefits over the period discounted at five percent. The system calculates these two indices through Years 10 and 20 of the policy illustrated, assuming current interest and mortality charges apply, and assuming guaranteed interest and mortality charges apply. Sample calculations of these cost indices appears on the last page of Specimen 16.

[0826] After the aforementioned analyses have been completed, the system saves the results in Block 712 for later printing. This completes the illustration for a particular financial product. Next, the system checks to see if it needs to make a similar computation for other products. If in Branch 656 it finds that not all desired products have been illustrated by comparing a target number of products to be illustrated with a counter, the system increments the counter in Block 714 and returns to FIG. 37B-4 to initiate another illustration.

[0827] Otherwise, the system tests whether more than one product has been illustrated (J>1), and if so, proceeds to Block 722 to find the best product based on the criteria entered in Block 592. In either case, the logic goes to Block 724 to store the insurance product specific data for an illustration.

[0828] Next in Block 726, Comparative Analysis, the system asks the user if he or she would like to see a comparison of the best policies. If the answer is “Yes,” the system moves to FIG. 37B-9 and otherwise, the system goes to FIG. 37B-8.

[0829] Turning to FIG. 37B-8 at Block 666, the values relevant to the computation of an illustration are generated, then displayed at the user's terminal in Block 668, and stored in the Database 17. The user can select a number of options: Print Illustration? 672, which will print the information on the Local Printer 5 via Block 674; Print and Mail Illustration? 676, which will print the illustration on the Central Printer 9 for mailing to a requested address via Block 678; and Make Application Using This Illustration? 680, which merges illustration data with stored text to make an application form, in Block 682. Block 670 also will save the illustration results for further analysis or review. The logic returns to the submenu provided by Block 560 in FIG. 36. This return is helpful for changing the illustration assumptions in order to see a different version of the illustration.

[0830] Turning to FIG. 37B-9, a schematic representation of the comparative analysis function is shown. In Block 750, prepare J≦5 Best Illustrations, the system creates the illustration from the values stored in Block 724. Then, in Block 751, those values are printed side by side for comparison by the user. The system returns to the subroutine that called it.

[0831] Returning to FIG. 36, the Update Existing Illustration 566 function goes to FIG. 37C-1, which commences with Select Input Menu 752. This selection is depicted in User Screen 34, which is also known as the Update Existing Illustration Supermenu.

[0832] The logic then goes to the following boxes: Block 754 to update the prospective applicant data, including personal, employment, and health data; and Block 756 to update the insurance data, including the premium structure, as well as the policy selection. These Blocks 754-756 permit the user to revise selected data in Database 17. Once the menu item has been selected and the update screen has been visited, Block 768 is used to facilitate going to the appropriate screen. The screens are filled in with the old data, and in Block 770 the user is allowed to change, add to, or delete from any of the existing data. Block 770 then returns to Block 752. When the user has gone through this loop as many times as necessary to update whatever screens need updating, from Block 752, the choice of Proceed, Block 758 can be made. The illustration process then proceeds to FIG. 37B-4, which then completes the illustration.

[0833] Additionally, the user may select Help, Block 18, which has been previously mentioned as being available from any screen in the system from the Update Existing Illustration Supermenu. A representative context-sensitive hypertext Help screen is shown in User Screen 35.

[0834] Lastly, Block 762 may be selected to quickly terminate the current illustration session and return to the Main Menu, 44, via Entry Point X4. The user is given an opportunity at this time to save what data has been entered thus far.

[0835] With further reference to FIG. 36, the Print Life Insurance Application 570 selection goes to FIG. 37D-1. Block 774 selects one form from a variety of insurance forms that could be printed, depending on the carrier. The logic proceeds to Block 776, which retrieves the existing prospective applicant data from Database 17, which was solicited in the process of creating the illustration, and prefills the insurance application form. If necessary, Block 778 allows the user to fill in any additional data. Then Block 780 prints the application at Local Printer 5. The logic proceeds to Block 782 which requests whether or not to send the application to the carrier electronically. If that answer, in fact, is “No,” the logic goes to Return 752. If the answer is “Yes,” Block 784 checks for completeness and permits sending the application to the Carrier via Block 786. Block 788 saves the insurance policy data and then returns to Block 570 in FIG. 36.

[0836] Review Insurance Product Developments 572 in FIG. 36, permits the user to read through prepared textual data by allowing the user to move from screen-to-screen. Once the user has completed a review of the data from Database 17, one or all of the textual screens or “pages” can be printed at the Local Printer 5.