WO2001009800A1

WO2001009800A1 - System and method for electronically revising a financial service product

Info

Publication number: WO2001009800A1
Application number: PCT/US2000/021220
Authority: WO
Inventors: Michael Degusta
Original assignee: Ecoverage, Inc.
Priority date: 1999-08-03
Filing date: 2000-08-02
Publication date: 2001-02-08
Also published as: WO2001009798A1; AU6514600A; AU6619900A; WO2001009811A1; AU6514500A; WO2001009798A9; AU6516200A; WO2001009801A1; AU6516300A; WO2001009802A1; WO2001009801A9; WO2001009799A1; AU6513700A; WO2001009810A1; AU6515900A

Abstract

The present invention relates to a system and method for providing financial services. According to an embodiment of the present invention, a financial service, such as insurance, may be provided through the use of reusable modules that may be called upon multiple times for various functions. A exemplary embodiment is shown in a flow diagram (Figure 1). Data related to a financial service is provided (step 200). Module associated with the provided is then selected (step 202) and then the selected module is executed (step 204). An example of a practical result of the use of these modules is that an insurance program may be quickly and easily established in all states with a minimum of duplication of effort.

Description

SYSTEM AND METHOD FOR ELECTRONICALLY REVISING A FINANCIAL SERVICE PRODUCT

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent Application No.

60/146,958 (Attorney Docket No. ECOVP001+) entitled SYSTEM AND METHOD FOR ELECTRONICALLY PROVIDING FINANCIAL SERVICES USING MODULES filed August 3, 1999 which is incorporated herein by reference for all purposes; and this application claims priority to U.S. Provisional Patent Application No. 60/146,964 (Attorney Docket No. ECOVP002+) entitled SYSTEM AND METHOD FOR ELECTRONICALLY PROVIDING AN ESTIMATE FOR A FINANCIAL SERVICE filed August 3, 1999 which is incorporated herein by reference for all purposes; and this application claims priority to U.S. Provisional Patent Application No. 60/146,957 (Attorney Docket No. ECOVP003+) entitled SYSTEM AND METHOD FOR ELECTRONICALLY PROVIDING A FINANCIAL SERVICE USING RATING FACTORS filed August 3, 1999 which is incorporated herein by reference for all purposes; and this application claims priority to U.S. Provisional Patent Application No. SYSTEM AND METHOD FOR ELECTRONICALLY PROVIDING A FINANCIAL SERVICE USING RATING FACTORS (Attorney Docket No. ECOVP004+) entitled SYSTEM AND METHOD

FOR ELECTRONICALLY PROVIDING A FINANCIAL SERVICE USING

RATING FACTORS filed August 3, 1999 which is incorporated herein by reference for all purposes; and this application claims priority to U.S. Provisional Patent

Application No. 60/146,959 (Attorney Docket No. ECOVP005+) entitled SYSTEM AND METHOD FOR ELECTRONICALLY REVISING A FINANCIAL SERVICE PRODUCT filed August 3, 1999 which is incorporated herein by reference for all purposes; and this application claims priority to U.S. Provisional Patent Application No. 60/146,966 (Attorney Docket No. ECOVP006+) entitled SYSTEM AND METHOD FOR ELECTRONICALLY MANAGING FINANCIAL SERVICE CLAIMS filed August 3, 1999 which is incorporated herein by reference for all purposes; and this application claims priority to U.S. Provisional Patent Application No. 60/146,949 (Attorney Docket No. ECOVP007+) entitled SYSTEM AND METHOD FOR ELECTRONICALLY CREATING A NEW FINANCIAL SERVICE PRODUCT filed August 3, 1999 which is incorporated herein by reference for all purposes.

This application is related to co-pending U.S. Patent Application No. (Attorney Docket No. ECOVP002) entitled SYSTEM AND

METHOD FOR ELECTRONICALLY PROVIDING AN ESTIMATE FOR A FINANCIAL SERVICE filed concurrently herewith, which is incorporated herein by reference for all purposes; and co-pending U.S. Patent Application No. (Attorney Docket No. ECOVP003) entitled SYSTEM AND

METHOD FOR ELECTRONICALLY PROVIDING A FINANCIAL SERVICE

USING RATING FACTORS filed concurrently herewith, which is incorporated herein by reference for all purposes; and co-pending U.S. Patent Application No. (Attorney Docket No. ECOVP004) entitled SYSTEM AND

METHOD FOR ELECTRONICALLY PROVIDING A FINANCIAL SERVICE USING COLLECTIONS INCLUDING MODULES filed concurrently herewith, which is incorporated herein by reference for all purposes; and co-pending U.S. Patent Application No. (Attorney Docket No. ECOVP005) entitled SYSTEM

AND METHOD FOR ELECTRONICALLY REVISING A FINANCIAL SERVICE PRODUCT filed concurrently herewith, which is incorporated herein by reference for all purposes; and co-pending U.S. Patent Application No. ___________ (Attorney Docket No. ECOVP006) entitled SYSTEM AND METHOD FOR

ELECTRONICALLY MANAGING FINANCIAL SERVICE CLAIMS filed concurrently herewith, which is incorporated herein by reference for all purposes; and co-pending U.S. Patent Application No. (Attorney Docket No. -

ECOVP007) entitled SYSTEM AND METHOD FOR ELECTRONICALLY CREATING A NEW FINANCIAL SERVICE PRODUCT filed concurrently herewith, which is incorporated herein by reference for all purposes.

FIELD OF THE INVENTION

The present invention relates to a system and method for providing financial services.

BACKGROUND OF THE INVENTION

Regulations for financial services, such as insurance, can be very complicated. Additionally, the complication may be compounded by the enforcement of different rules and regulations unique to each regulatory area, such as in a particular state. In order to accommodate these varying requirements, financial services, such as the insurance industry, have adopted a procedure that typically requires the financial service provider to reestablish the financial service system for each regulatory area. For example, in the insurance industry, each state has its own set of rules and regulations for a particular insurance type offered in that state. Examples of insurance types include auto, life, and health. An example of the different requirement for auto insurance in varying states includes signature requirements. For example, one state might require an original signature, while another state might deem that a faxed copy of the signature is sufficient.

To accommodate the various regulations, insurance companies typically create a separate process for each insurance type in each state. Additionally, a new pricing program is typically prepared for each insurance type in each state. This multiple duplication of establishing programs typically results in extremely high costs, inefficiencies, duplication of effort, and high labor costs.

It would be desirable to have a system and method for providing financial services in an efficient and less costly manner. The present invention addresses such a need.

SUMMARY OF THE INVENTION

The present invention relates to a system and method for providing financial services. According to an embodiment of the present invention, a financial service, such as insurance, may be provided through the use of reusable modules that may be called upon multiple times for various functions. An example of a practical result of the use of these modules is that an insurance program may be quickly and easily established in all states with a minimum of duplication of effort. A method according to an embodiment of the present invention for revising a financial service product is presented. The method comprises selecting a first module; copying the selected first module, resulting in a copied module; editing the copied module, resulting in a second module; and saving the second module.

A system according to an embodiment of the present invention for revising a financial service product is also presented. The system comprises a processor configured to facilitate selecting a first module; copying the selected first module, resulting in a copied module; editing the copied module, resulting in a second module; and saving the second module. The system also includes a memory coupled to the processor to provide instructions to the processor.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be readily understood by the following detailed description in conjunction with the accompanying drawings.

FIG. 1 is a block diagram of an example of a computer system suitable for use with an embodiment of the present invention.

FIG. 2 is a flow diagram of a method according to an embodiment of the present invention for providing a financial service.

FIG. 3 is another flow diagram of a method according to an embodiment of the present invention for providing a financial service.

FIGs. 4A - 4B are further flow diagrams of a method according to an embodiment of the present invention for providing a financial service.

FIG. 5 is an example of a table showing modules which may be used according to an embodiment of the present invention.

FIGs. 6A-6F are examples of tables that may be used accordmg to an embodiment of the present invention.

FIG. 7 is a flow diagram of a method according to an embodiment of the present invention for using a meta collection in conjunction with providing a financial service. FIG. 8 is a flow diagram of a method according to an embodiment of the present invention for calculating a net factor in conjunction with providing a financial service.

FIG. 9 shows an example of questions that may be asked of a potential customer who is interested in obtaining an auto insurance quote according to an embodiment of the present invention.

FIGS. 10A - 10B shows an example of a list of collections and modules that are valid for a product according to an embodiment of the present invention.

FIG. 11 shows an example of a screen shot of a quote manipulation tool.

FIG. 12 is a flow diagram of a method according to an embodiment of the present invention for revising a module.

FIG. 13 illustrates an example of a graphical user interface during the revision of a module.

FIG. 14 shows another graphical user interface showing an example of revising a module.

FIG. 15 is another example of a graphical user interface that can be used for creating a revision of a module or collection.

DESCRIPTION OF SPECIFIC EMBODIMENTS

The following description is presented to enable one of ordinary skill in the art to make and to use the invention and is provided in the context of a patent application and its requirements. Various modifications to the preferred embodiments will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. Thus, the present invention is not intended to be limited to the embodiment shown but is to be accorded the widest scope consistent with the principles and features described herein.

FIG. 1 is a block diagram of a general purpose computer system 100 suitable for carrying out the processing in accordance with one embodiment of the present invention. FIG. 1 illustrates one embodiment of a general purpose computer system. Other computer system architectures and configurations can be used for carrying out the processing of the present invention. Computer system 100, made up of various subsystems described below, includes at least one microprocessor subsystem (also referred to as a central processing unit, or CPU, 102). That is, CPU 102 can be implemented by a single-chip processor or by multiple processors. CPU 102 is a general purpose digital processor which controls the operation of the computer system 100. Using instructions retrieved from memory 110, the CPU 102 controls the reception and manipulation of input data, and the output and display of data on output devices.

CPU 102 is coupled bi-directionally with memory 110 which can include a first primary storage, typically a random access memory (RAM), and a second primary storage area, typically a read-only memory (ROM). As is well known in the art, primary storage can be used as a general storage area and as scratch-pad memory, and can also be used to store input data and processed data. It can also store programming instructions and data, in the form of data objects and text objects, in addition to other data and instructions for processes operating on CPU 102. Also as well known in the art, primary storage typically includes basic operating instructions, program code, data and objects used by the CPU 102 to perform its functions. Primary storage devices 110 may include any suitable computer-readable storage media, described below, depending on whether, for example, data access needs to be bi-directional or uni-directional. CPU 102 can also directly and very rapidly retrieve and store frequently needed data in a cache memory (not shown).

A removable mass storage device 112 provides additional data storage capacity for the computer system 100, and is coupled either bi-directionally or uni- directionally to CPU 102. For example, a specific removable mass storage device commonly known as a CD-ROM typically passes data uni-directionally to the CPU 102, whereas a floppy disk can pass data bi-directionally to the CPU 102. Storage 112 may also include computer-readable media such as magnetic tape, flash memory, signals embodied on a carrier wave, PC-CARDS, portable mass storage devices, holographic storage devices, and other storage devices. A fixed mass storage 120 can also provide additional data storage capacity. The most common example of mass storage 120 is a hard disk drive. Mass storage 112, 120 generally store additional programming instructions, data, and the like that typically are not in active use by the CPU 102. It will be appreciated that the information retained within mass storage 112, 120 may be incorporated, if needed, in standard fashion as part of primary storage 110 (e.g. RAM) as virtual memory.

In addition to providing CPU 102 access to storage subsystems, bus 114 can be used to provide access other subsystems and devices as well. In the described embodiment, these can include a display monitor 118, a network interface 116, a keyboard 104, and a pointing device 106, as well as an auxiliary input/output device interface, a sound card, speakers, and other subsystems as needed. The pointing device 106 may be a mouse, stylus, track ball, or tablet, and is useful for interacting with a graphical user interface.

The network interface 116 allows CPU 102 to be coupled to another computer, computer network, or telecommunications network using a network connection as shown. Through the network interface 116, it is contemplated that the CPU 102 might receive information, e.g., data objects or program instructions, from another network, or might output information to another network in the course of performing the above-described method steps. Information, often represented as a sequence of instructions to be executed on a CPU, may be received from and outputted to another network, for example, in the form of a computer data signal embodied in a carrier wave. An interface card or similar device and appropriate software implemented by CPU 102 can be used to connect the computer system 100 to an external network and transfer data according to standard protocols. That is, method embodiments of the present invention may execute solely upon CPU 102, or may be performed across a network such as the Internet, intranet networks, or local area networks, in conjunction with a remote CPU that shares a portion of the processing. Additional mass storage devices (not shown) may also be connected to CPU 102 through network interface 116.

An auxiliary I/O device interface (not shown) can be used in conjunction with computer system 100. The auxiliary I/O device interface can include general and customized interfaces that allow the CPU 102 to send and, more typically, receive data from other devices such as microphones, touch-sensitive displays, transducer card readers, tape readers, voice or handwriting recognizers, biometrics readers, cameras, portable mass storage devices, and other computers.

In addition, embodiments of the present invention further relate to computer storage products with a computer readable medium that contain program code for performing various computer-implemented operations. The computer-readable medium is any data storage device that can store data which can thereafter be read by a computer system. The media and program code may be those specially designed and constructed for the purposes of the present invention, or they may be of the kind well known to those of ordinary skill in the computer software arts. Examples of computer-readable media include, but are not limited to, all the media mentioned above: magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROM disks; magneto-optical media such as floptical disks; and specially configured hardware devices such as application-specific integrated circuits (ASICs), programmable logic devices (PLDs), and ROM and RAM devices. The computer-readable medium can also be distributed as a data signal embodied in a carrier wave over a network of coupled computer systems so that the computer- readable code is stored and executed in a distributed fashion. Examples of program code include both machine code, as produced, for example, by a compiler, or files containing higher level code that may be executed using an interpreter.

The computer system shown in FIG. 1 is but an example of a computer system suitable for use with the invention. Other computer systems suitable for use with the invention may include additional or fewer subsystems. In addition, bus 114 is illustrative of any interconnection scheme serving to link the subsystems. Other computer architectures having different configurations of subsystems may also be utilized.

FIG. 2 is a flow diagram of a method according to an embodiment of the present invention for providing a financial service. Data related to a financial service, such as insurance, is provided (step 200), typically by a potential customer or a company administrator. A module associated with the provided data is then selected (step 202). Modules, as defined herein, are encapsulations of code, with attributes that collectively define a component of a process of a financial institution. Examples of modules for insurance include the make of a car, a pricing weight of a person's driving record, and zip code. There may be multiple modules dealing with a specific piece of information needed for processing a particular type of insurance in a specified state. For example, there may multiple modules dealing the make of the person's car. Further details of modules will later be discussed in conjunction with the remaining figures, particularly FIG. 5. Once a module associated with the data has been selected (step 202), then the selected module is executed (step 204).

FIG. 3 is another flow diagram of a method according to embodiment of the present invention for providing a financial service. A quote request is received (step 300). For example, the quote request may be sent via the Internet by a potential customer interested in a financial service product.

Once the quote request is received, an underwriting decision is then performed

(step 302). The underwriting decision may be a preliminary decision determining whether this potential customer qualifies for an initial quote for the financial service product. For example, a potential customer requesting a quote may provide information to help determine the underwriting decision. If the potential customer requests a quote for car insurance but it is determined that he is too high of a risk based on his driver's record, the requested quote may simply be refused. Accordingly, time and resources are not wasted in determining and describing a product that will eventually not be offered to the potential customer. Further details of the underwriting decision performed in step 302 will later be discussed in conjunction with FIGs. 4 A - 4B.

Once an underwriting decision has been made and approved, quote generation is performed (step 304). Modules may be used to perform the quote generation to return quote information to the potential customer requesting the quote. Further details of the generation of the quote are later discussed in conjunction with FIGS 4A - 4B.

Thereafter, billing and detailed information may be obtained from the potential customer (step 306). Validation and verification of the information provided by the potential customer may also be performed (step 308). For example, verification of the driver's record which was provided by the potential customer may be independently verified. Closing functions may also be performed (step 310). Closing functions may include any remaining pending issues such as filling out forms to comply with state regulations.

FIGs. 4A - 4B are further flow diagrams of an example of a method according to an embodiment of the present invention for providing a financial service. FIG. 5 shows an example of a modules table showing examples of modules and their attributes. FIGs. 6A - 6F show examples of table mappings and collections that may be used in conjunction with modules. FIG. 6A shows a person table 600; FIG. 6B shows a frequency table 610; FIG. 6C is an example of a table of mappings 620; FIG. 6D is an example of a table of collections 630; FIG. 6E is another example of a table of collections 640; and FIG. 6F is an example of a table of meta collections 650. These figures are herein described together.

In the example shown in FIGs. 4A - 4B, a potential customer logs onto a web site providing a financial service (step 400). The potential customer then requests a financial service application, such as an application for a particular type of insurance in a particular state (step 402).

Examples of information that a potential customer may be requested to provide in conjunction with the request for an application are shown in FIG. 9. FIG. 9 is an example of questions that may be asked of a potential customer who is interested in obtaining an auto insurance quote. Examples of questions include name, gender, marital status, years as a licensed driver in the U.S., years without lapse in insurance coverage, points on driving record in the last three years, whether the person has completed a defensive driving course in the last three years, whether the person is a student with a B or better grade average, vehicle year, make, model, usage, principal driver, home zip code, and any other information that may be relevant to an application for the requested financial service product.

Quote request modules associated with the selected state and selected insurance type are identified (step 404). There may be different types of modules, such as module types delineated by function. Examples of types of modules include quote request, quote generation, verification, closing requirements, billing, claims handling, help, and underwriting modules. In step 404, modules used for the quote request process may be identified based on their assigned module type, such as quote request modules. An example of quote request modules associated with a selected state and insurance type (step 404 of FIG. 4A) is shown in FIGs. 6C and 5.

FIG. 6C shows a mappings table that identifies modules with some attributes.

For example, modules with an assigned type of "quote request", for the state of California, for car insurance include modules named "car" and "zip". These modules may be found in the modules table 500 shown in FIG. 5.

FIG. 5 shows an example of a modules table showing examples of modules and their attributes. The modules table 500 is shown to include the names 501 of the modules and various attributes 502A-502J of the modules. In this example, the modules included in the modules table 500 is zip code, car make, car year, zip code, and frequency. Further examples of module names include "Calculation", "Content", "Document", "External", "frame", "rating", and "underwriting". In this example, attributes shown in the modules table 500 mclude code type 502A, code 502B, whether this module is repeatable 502C, a destination table 502D, a destination field 502E, initial conditions 502F, date from 502G, date to 502H, state 5021, and insurance type 502 J. Further examples of attributes which may be associated with modules include the following:

ATTRIBUTES FOR CALCULATION MODULE

Calculation

Language

Destination Table

Destination Field Destination Custom ATTRIBUTES FOR CONTENT MODULE

Title

Text

Destination Table Destination Field

Form Type

Form Size

Answer Set

Default Answer Help

Layout

Borders

Repetition

Auto Reload Language

Execute Dependency

ATTRIBUTES FOR DOCUMENT MODULE Title Format

Template

ATTRIBUTES FOR EXTERNAL MODULE Protocol Format

Destination Authorization

ATTRIBUTES FOR FRAME MODULE Frame Name

Initial Page Name Scroll

ATTRIBUTES FOR RATING MODULE Factor

Source Table

Source Field

Match Type

Factor Usage Constraint Table

Constraint Field

ATTRIBUTES FOR UNDERWRITING MODULE Asset Type Test

Success Failure For example, California may be the selected state 5021 and auto may be the selected insurance type 502J of FIG. 5. Accordingly, in this example, the modules that would be identified during step 404 include zip code, car make, car year, and frequency.

These quote request modules are then displayed to the potential customer (step

406). The potential customer then inputs requested data (step 408). Examples of requested data are later discussed in conjunction with FIG. 9.

Each module then takes input associated with that particular module and places it in a predetermined location (step 410). An example of determining the predetermined location is shown in FIG. 5 as the attributes destination table 502D and destination field 502E. For example, if the destination table 502D of FIG. 5 identifies "person" as the destination table and "frequency" as the destination field, then the data related to frequency module would be placed in the person table 600 of FIG. 6A in the frequency column.

After each module takes input associated with it and places it in a predetermined location (step 410 of FIG. 4 A), calculation modules related to the selected state and insurance type are then retrieved (step 412). The calculation modules may be modules that are related to calculating a rating associated with the potential customer and the insurance policy to be offered to him. The rating may be the insurance rate a potential customer would qualify to receive.

Primary underwriting modules are then implemented in this example (step 414). These underwriting modules determine whether or not to offer insurance to this particular potential customer. Quote generation modules are then determined (step 416). Quote generation modules determine a rating factor or a set of rating factors to be used in offering a quote to the potential customer. As previously mentioned, these modules may be determined by referring to a mappings table 620 of FIG. 6C which give examples of types of the modules that may be associated with a given module.

A net rating factor for the potential customer is then generated (step 450). A net rating factor is a customized rating factor for a particular potential customer that is a compilation of other rating factors. For example, there may be several rating factors provided in the form of modules such as car type, number of years of driving experience, driving record, insurance deductible, gender, age, location of residence, and age of the car. Each of these factors may be translated into a number system so that the number system may be associated with a particular cost and risk associated with that particular rating factor. For example, a ten may signify an extremely high risk factor which can be equivalent to a very high price for the offered policy, while a factor of one may indicate a very low risk and a correspondingly low price for the offered policy. The number system may be any system that denotes a degree of risk or price.

These various factors are then combined to produce a net factor. For example, all of the various rating factors may be multiplied to produce a net factor. This net factor may be used in conjunction with a specific insurance company's base rate for a specific state. For example, a particular insurance company may have a base rate in the state of California for bodily injury at $1000 per year. The net rating factor may be combined with the base rate, such as multiplying by the base rate, to produce a price for the potential customer for a particular type of insurance. For example, if the bodily injury base rate for car insurance in California is $1,000 per year, then the potential customer's price may be $1,000 per year times the net factor calculated for this particular customer. If the combination of all of the rating factors equals 2.75 as a net factor and the base rate for this type of insurance in this state is $1,000 per year, then the quote offered to the potential customer would be $2,750 per year. Further details of the calculation of the net factor will later be discussed in conjunction with FIG. 8.

In addition to presenting one quote for one type of financial service, another quote for another type of financial service may also be presented. For example, a net rating factor may be generated for auto insurance for a potential customer in a given state. In addition, the same information provided by the potential customer may be used to generate a net rating factor for home owner's insurance. Both the auto insurance quote and the home insurance quote generated from these net rating factors may be presented to the potential customer. In this manner, even though a potential customer may only request a quote for auto insurance, he can view a quote for home owner's insurance without having to input a significant amount of additional information, if any at all.

After the net rating factor is generated for the potential customer (step 450), a quote manipulation tool may be displayed to the potential customer (step 452). An example of a quote manipulation tool is described in conjunction with FIG. 11. The use of a quote manipulation tool is optional. The net rating factor may be used to generate a quote for the requested financial service to be presented to the user. The user may then decide whether to accept the financial service at that price. Alternatively, a potential customer may insert variables to generate different quotes with a quote manipulation tool (step 454). The potential customer then selects a policy or coverage (step 456). The potential customer then provides detailed information regarding the property or person being insured (step 458). The potential customer also provides billing information (step 460). Examples of the billing information include information required for electronic transfer. Validation of the information may then be performed (step 461). Resolution of outstanding issues are also performed if there are any outstanding issues (step 462). For example, a notification may be sent to the marketing department of the insurance company to send out a new customer package to the potential customer. Any remaining customer documents may be executed (step 464), and any required company documents may also be executed (step 466).

As previously mentioned, FIG. 5 is an example of a modules table according to an embodiment of the present invention. In this example, the modules table 500 identifies the name 501 of the modules and the various attributes 502A - 502J associated with the modules. The sample list of attributes associated with the modules for the modules table 500 includes a code type 502A, code 502B, repeatable 502C, a destination table 502D, a destination field 502E, initial conditions 502F, date from 502G, date to 502H, state 5021, and insurance type 502J.

A code type 502A indicates a type of programming code that is associated with a particular module. For example, SQL or math may be code types associated with a particular module. Code 502B is the actual code or calculation used in conjunction with the module. For example, the code may identify a field in another table multiplied by a factor and added to another field from another table. For example, the code associated with the module frequency may be a SQL code and defined as (person serious) times 5 plus (person minor) times 1, wherein person serious indicates a column entitled "serious" in the "person" table and person minor is the "minor" column in the "person" table.

The attribute "repeatable" 502C simply indicates whether a module may be used more than once in a particular process. For example, a potential customer may have more than one car that needs to be insured under his name. Accordingly, the car make and car year may be repeatable to allow input of more than one car.

Destination table 502D and destination field 502E identify the location to which the data received from the potential customer associated with a particular module is to be placed. For example, the data received from the potential customer associated with the module "frequency" is placed in destination table "person" 600 of FIG. 6A, in the destination field "frequency" of the "person" table 600 of FIG. 6 A.

Initial conditions 502F indicate under what conditions the module is activated. For example, for processing billing information, data associated with the billing information is an initial condition such that the billing module does nothing if there is no billing information to process. Another example is a credit card module wherein initial conditions of the credit card module may include a credit card number, a charge on the credit card or a lack of payment of a charge on the credit card. Under these conditions, the credit card module is activated. Completion conditions (not shown) may also be used in addition to or instead of initial conditions 502F. Completion conditions may indicate under what conditions the module is deactivated. For example, the credit card module may include completion conditions such as payment of a charge on the credit card. When a charge on the credit card is paid, then the credit card module is deactivated.

The "date from" 502G and "date to" 502H indicate the time period during which the module is valid. State 5021 may indicate the state or location to which the module applies. Insurance type 502J, which may also be financial services type, indicates what type of financial service to which the module applies.

Modules may be dynamic such that the modules may be rearranged in any order and associated with any other module or program. Modules may be classified into collections or groups and may be arbitrarily rearranged. Modules may include definable and editable attributes and may be defined by a set of its attributes.

Modules may be used so that an outside program simply executes the modules in any order desired by the programmer. A single module may be assigned to various uses such that the same module may be used repeatedly for different projects. A module may be disconnected from the data pool such that the module simply accesses the location of the data. Accordingly, the data may be changed in one location to update multiple modules. A group of modules or all of the modules may have at least one thing in common so that all of these modules may be generalized. For example, all modules or a subset of all modules may be valid for certain dates or have common initial conditions. This facilitates the use of an admin tool that can manipulate all of the modules or a subset of all of the modules by taking advantage of the factors that these modules have in common.

As previously mentioned a module is an encapsulation of code with attributes that collectively define a component of a process of financial services. It is optional to have different types of modules. An example of a type of module is a query module which would ask a potential customer a predetermined question or questions, such as the make of his car, and placing the answers to those questions in a predetermined location, such as a data table. Another example of a type of module is a rating module which is a piece of programming code that can determine a price for a particular financial service product.

There may be multiple modules for a concept, such as three modules for a car: make, model, and year. All of these modules associated with this particular concept may be placed in a collection called a car collection.

FIGs. 6D and 6E show examples of a table of collections 640, 630. In FIG.

6E, the collections table 640 shows the name of the collection, the name of the modules within that collection, and date from and date to which identify dates during which the collection is valid.

A collection may also include other collections and not just modules. The collections are a convenient form of access to the modules. Collections are not necessary to access modules, however, some modules may be convenient to be grouped together because they are often accessed together. Accordingly, a collection, such as car collection, may be re-accessed and reused more conveniently then accessing every module and collection within the car collection each time those modules and collections need to be accessed.

For example, if a customer applies for both auto insurance and property insurance, then much of the information the customer provides for auto insurance will be the same as information required to be provided for the property insurance. Accordingly, many of the modules used for the auto insurance may be reused for the application for the property insurance. Rather than determining a second time what each module is related to, a collection may be used to take advantage of the relationships that have already been determined. Examples of names of collections include "frameset", "page", and "content". Each collection identifies modules or other collections which point to the location of those modules and other collections. The following are examples of modules and collections that may be included in collections:

ELEMENTS OF FRAMESET COLLECTION Sizes

Layout

ELEMENTS OF PAGE COLLECTION Title Text

ELEMENTS OF CONTENT COLLECTION

Title

Text Help

Repeats

Layout

Borders

Execute Dependency

There may be several different types of collections, for example, an operational collection or a meta collection. The operational collection is preferably a collection that gets executed, while a meta collection is preferably not executed. Meta collections are preferably not used by transactions, they are only for administrative purposes. A meta collection identifies modules or collections for an operation. A meta collection associates modules to collections. The example of the meta collection

650 shown in FIG. 6F shows electronic funds transfer (EFT) as the name of a meta collection. If an electronic funds transfer is desired in the state of Texas, then a module, such as one identifying a credit card number, should be added to a billing page content as well as to billing processing. For administrative purposes, it may be desired to group these two collections, billing page content and billing processing, together since changes to the billing page content would also effect billing processing. Accordingly, it may be helpful to group these two collections together under a meta collection.

In the example of the meta collection 650 of FIG 6F, the meta collection named "EFT" associates module 19 with collection 8 and module 35 with collection 11, collection 8 being billing page content and collection 11 being billing processing. Examples of module 19 and 35 may be a credit card number and expiration date. Accordingly, if it is desired to add electronic funds transfer to pay for the financial service, then the EFT meta collection identifies the modules to be included in a particular collection to ensure that the EFT is properly added. If the electronic funds information is changed, such as the customer wishes to charge on a different credit card, then the EFT meta collection may again be used to identify what new or revised modules need to be added to which collections to enact these changes. Meta collections are not required to execute the modules, it is an additional directory to assist in organizing the modules and the uses thereof.

FIG. 7 is a flow diagram of a method according to an embodiment of the present invention for using a meta collection in conjunction with providing a financial service. A user, such as the program administrator, selects an option (step 700). An example of an option is whether the user chooses to present electronic fund transfer as an option to a potential customer applying for insurance. The selected option is then looked up under a meta collection (step 702). Modules identified under the meta collection are inserted into operational collections from the meta collection (step 704). When a customer selects a state and insurance type, the operational collection then puts together the modules required for the customer for the selected state and insurance type (step 706), as discussed in conjunction with FIGs. 2 - 6A-6F.

FIG. 8 is a flow diagram of a method according to an embodiment of the present invention for determining a net rating factor for providing a financial service, such as in step 450 of FIG. 4B. A rating factor for each calculation module is looked up for the selected state and insurance type (step 800). All of these rating factors are multiplied together to result in a net rating factor (step 802). A base rate of the financial service provider is looked up for the selected state and insurance type (step 804). The base rate is then multiplied with the net rating factor to result in a price for the customer (step 806). Although multiplication is used in this example, these rating factors may be combined in any way such as addition, subtraction, division or by any other mathematical function or combinations thereof to result in the net rating factor. Similarly, the base rate may be combined in any way with the net rating factor to result in the quoted price. The rating factor for each module for the selected state and insurance type may be determined by the company providing the financial services.

FIGS. 10A - 10B show an example of a list of collections and modules that are valid for a product according to an embodiment of the present invention. As shown in FIGS. 10A - 10B, collections can be included in other collections as well as modules (elements). Examples of collections include a purchasing master, quote request page, quote request frameset, quote questions frameset, auto quote, pre- underwriting calculation, preferred filter underwriting, post-underwriting calculation, auto program, auto rating, deductible rating, class factor rating, quote header page, drivers page, points questions content, and vehicles page. Examples of modules include quote header frame, drivers frame, vehicles frame, nav bottom frame, points calculation, symbol calculation, vehicle count, experience underwriting, accidents underwriting, points underwriting, frequency and severity calculation, driver assignment calculation, base rates rating, symbol rating, multiple vehicle rating, multiple vehicle rating, affinity group rating, mature driver rating, model year rating, and anti-theft rating.

FIG. 11 shows an example of a screen shot of a quote manipulation tool. Examples of variables that may be used to allow the potential customer to see the effect of the premium quote includes bodily injury liability amount, property damage liability amount, medical payments, uninsured motorist bodily injury amount, uninsured motorist personal damage amount, comprehensive coverage, and collision coverage. A potential customer may vary any of these variables to recalculate the total premium quote for that customer.

Figure 12 is a flow diagram of a method according to an embodiment of the present invention for revising a module. Modules are initially defined (step 1200). The modules may be defined by the person setting up the financial services product, for example. Once the modules are defined, it may be desirable to edit one of the modules. For example, an administrator may wish to edit one of the modules due to changes in the regulation of a particular state.

Accordingly, a first module is selected for editing (step 1202). A copy of the first module is made and the copy is edited and saved as a new module (step 1204). The new module is then added to the list of modules (step 1206). An example of the list of modules is shown in the modules table 500 of FIG. 5. A start date of the new module is set for the table of modules (step 1208). The start date for the new module identifies the date from which the new module is valid. An end date for the first module is set to the start date of the new module (step 1210). The end date of the first module signifies the end of the time period during which the first module is valid. Accordingly, rather than editing the first module and permanently deleting the data prior to the edit, the first module is saved in its original form except that it is designated as an earlier version as indicated by its start and end date. The new module preferably has a different start and end date from the first module such that the new module becomes valid at a date later than the first module.

The modules may then be selected by identifying a date (step 1212). For example, a default date to be identified may be the current date. Alternatively, a user may enter a specified date, either in the past or in the future, to view the status of the module at the specified time period.

An advantage of editing a module in this manner is that the history of the financial service product may be viewed, for example, for marketing or accounting purposes. Another advantage of editing the modules in this manner is that the edits do not need to be immediately effective. For example, if there are changes to the life insurance regulations in a particular state, then the changes may be incorporated by editing an existing module and setting the start date of the new module to be the date the regulation becomes effective. Accordingly, potentially vast amounts of work may be accomplished ahead of time on a predetermined schedule rather than having to wait until the regulation changes become effective to edit the modules. FIG. 13 illustrates an example of a graphical user interface during the revision of a module. The user, such as an administrator for the company providing the financial services, may be given the option to select a module by selecting a module type 1300 and a module 1302 within that module type 1300. The user may have the option of selecting any module type 1300 which can be listed within the module type 1300 section. Once a module type 1300 is selected, the user is given the option to select any of the modules 1302 within that selected module type 1300. The user can also select whether to create a new module or delete an existing module and the user is also given the option to edit attributes of a module, members of a collection and select the validity dates.

A version display 1310 shows the version of the current module being viewed by the user. The user may also see the family of collections that this particular module may be in, via section 312. For example, this module is shown to be included in the driver content collection, which is shown to be included in the "request page collection", which in turn is also included in the purchasing master collection. This module is also included in the points questions content collection which is included in the "request page collection", which is also included in the purchasing master collection.

In this example, this module is currently validated under auto insurance in California. There are no other current validations for this module. There are also no future validations for this module. All contents of the module may be revised, such as the title of the module, the text, the destination table, the destination field, the form type, the form size, the answer set, a default answer, and help. FIG. 14 shows another graphical user interface showing an example of revising a module. In this instance, a collection is shown being revised. In this example, a driver content collection has been selected within a content collection. It can be seen that this screen shot is version number 14. This collection is included in the "request page collection" which in turn is included in the purchasing master collection. This collection is also directly included in the purchasing master collection. There are no current validations for this collection. However, there are other current validations which is version number 8, auto insurance in California. Accordingly, this collection is not currently activated. In this example, there are no future validations. This graphical user interface shows that the modules that are currently available can be seen in the "available modules" section. The current members (collections and modules (elements)) can be seen in the "current members" list. A module from the available modules list can be included in the current members list by selecting an arrow symbol in this example.

FIG. 15 is another example of a graphical user interface that can be used for creating a revision of a module or collection. In this example, a validation date is being set for a collection. The purchasing master collection has been selected. The new validation shows a version number of 11 for California Auto Insurance the user can set the validation beginning and end dates for the validation of the purchasing master collection. Additionally, the user can view a validation log wherein each version of the selected module or collection is shown with information regarding the validation dates. Accordingly, if a financial services company wishes to determine what factors may contribute to producing a desired result, the user can review the validation log to analyze the history of what was in effect during an certain period of time. For example, if a large number of customers signed up for a new financial services product during a three month period in 1998, and then a sudden drop in new customers occurred in a three month period thereafter, then the user can view what was in effect during the three month period in 1998, as well as the three month period following the period of high sign up, via the validation log. Thereafter, the collections and modules that were in effect at that time can be pulled up by their validation dates.

A method and system for providing a financial service has been disclosed. Software written according to the present invention may be stored in some form of computer-readable medium, such as memory or CD-ROM, or transmitted over a network, and executed by a processor.

Although the present invention has been described in accordance with the embodiment shown, one of ordinary skill in the art will readily recognize that there could be variations to the embodiment and these variations would be within the spirit and scope of the present invention. The examples used to illustrate the invention were for the insurance industry, however, the invention may be applied to any financial service, such as various types of loans. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.

Claims

1. A method for revising a financial service product comprising: selecting a first module; copying the selected first module, resulting in a copied module; editing the copied module, resulting in a second module; and saving the second module.

2. The method of claim 1, further comprising setting a start date of the second module.

3. The method of claim 1, further comprising setting an end date of the first module to be approximately equal to a start date of the second module.

4. The method of claim 1, wherein the second module is saved to a list of modules.

5. The method of claim 4, wherein a modules from the list of modules may be selected by identifying a date.

6. The method of claim 1 , wherein the copied module may be edited by selecting from a list of options.

7. The method of claim 1, further comprising editing a first collection.

8. The method of claim 1, wherein the financial service is insurance.

9. The method of claim 1, wherein the second module may be arranged in any relative order compared to a third module.

10. The method of claim 1, wherein the second module may be used for a plurality of uses.

11. The method of claim 1 , wherein the first module identifies the location of data, wherein the data is related to the module.

12. The method of claim 1, wherein the second module has at least one attribute in common with a third module.

13. The method of claim 12, wherein the second module and the third module may both be manipulated by using the at least one attribute in common.

14. The method of claim 1, wherein the second module includes an attribute.

15. The method of claim 14, wherein the attribute is a code type.

16. The method of claim 14, wherein the attribute is a code.

17. The method of claim 14, wherein the attribute is whether the module is repeatable.

18. The method of claim 14, wherein the attribute is a destination table.

19. The method of claim 14, wherein the attribute is a destination field.

20. The method of claim 14, wherein the attribute is an initial condition.

21. The method of claim 1, wherein a start date of the second module is not earlier than an end date of the first module.

22. A system for revising a financial service product comprising: a processor configured to facilitate selecting a first module; copying the selected first module, resulting in a copied module; editing the copied module, resulting in a second module; and saving the second module; and a memory coupled with the processor for providing the processor with instructions.

23. A computer program product for revising a financial service product comprising: computer code selecting a first module; computer code copying the selected first module, resulting in a copied module; computer code editing the copied module, resulting in a second module; computer code saving the second module; and a computer readable medium that stores the computer codes.

24. The computer program product of claim 23, wherein the computer readable medium is selected from the group consisting of CD-ROM, floppy disk, tape, flash memory, system memory, hard drive, and data signal embodied in a carrier wave.