WO2001016845A1

WO2001016845A1 - Method and apparatus for network-based automated insurance transaction processing

Info

Publication number: WO2001016845A1
Application number: PCT/US2000/024004
Authority: WO
Inventors: Catharine G. Neumann; Antonino Silva; J. Scott Neumann; Alan J. Zall; William J. Morrissey; John Paul Sullivan; Patrick J. Nestor; Anthony J. Consoles; David F. Burns; Srikanth Tatineni
Original assignee: Insurance Technology Services Of America, Inc.
Priority date: 1999-08-31
Filing date: 2000-08-31
Publication date: 2001-03-08
Also published as: AU7340900A

Abstract

An insurance transaction processing system is comprised of a management system (230) that includes a variety of workstations (205, 250) configurable for any of a variety of users interfaced with a database management system that includes a set of engines and servers. Agents and clients may obtain and compare policies and associated rate quotes from a plurality of insurance carriers, based on client profile data input at the workstation. This system can underwrite, quote rates and bill.

Description

METHOD AND APPARATUS FOR NETWORK-BASED AUTOMATED INSURANCE TRANSACTION PROCESSING

Background of the Invention The present invention relates to the field of computer and network based business application systems, and specifically to systems which relate to the presentation, processing, and maintenance of insurance products and related transactions over a distributed computer system.

Traditionally, insurance companies have utilized paper intensive systems for the presentation, processing, and maintenance of insurance policies to potential clients. Additionally, claims processing and monetary transactions, such as bill payment or payment under a claim, have been accomplished largely by paper means. To initiate a policy, clients typically have had the choice of dealing directly with an insurance company's agent and, typically, being limited to that company's policy choices or dealing with an independent insurance agent, who may offer policy choices from a group of insurance companies. In either case, the process of comparing, selecting, and processing a policy is largely accomplished by a variety of intermediate entities using largely paper processing, and to a lesser degree some computer processing. Additionally, because the processing of a client's policy, once selected, is extremely time consuming, often about six weeks, the insurance agent is only able to provide a policy quote, rather than an accurate premium (or price) to the client at the time the application for insurance is taken. In some systems, despite some automation, a client is tentatively issued a policy, which is then subject to subsequent approval and possible cancellation if certain underwriting rules are not satisfied.

A typical process 100 for processing a client's policy selection is shown in Figure 1. Initially, a client meets with an agent to compare policies and policy options for a specific type of insurance policy, e.g., home or auto. Based on the information provided by a client for the specific type of policy, the agent generates a set of comparative price quotes, shown in step 102. These quotes may be generated from company hard-copy literature or from tables stored in a computer, wherein the agents computer configuration is often highly customized with special software to access and use insurance company information - which may not actually be current when used. As an example, a client may inquire about an auto insurance policy including comprehensive coverage. The client may then request different policy price quotes for the auto policy having different options (or elements) selected for comparison, such as having a $500 versus a $1,000 deductible option or having a towing option added to the policy. Additionally, the premium of the policy depends on unique client information, such as driving record and the value of the auto to be insured, and unique insurance company information, such as current policy rates.

The need to process the insurance application through underwriting, including the need to verify a variety of factors involved in accurately determining a policy premium, makes it impossible for the insurance agent to produce a definite premium at the time the policy application is taken. Therefore, the agent can, at best, only provide the client with a price quote or quotes, which are merely estimates. Such a system and process results in the client having to leave the application process without having certain premium information. Therefore, the client bears an undesirable cost risk that the policy may ultimately be more costly than envisioned, assuming it actually issues after the underwriting process is complete.

Once the client has selected a given policy, including any desired policy options, the agent prepares and submits a policy application to the insurance company (or carrier), shown in steps 104 and 106, and accepts a down-payment from the client. The insurance company's mail- room logs in the receipt of the policy application, step 108, forwards the policy application to the underwriting department, step 110, and forwards the client's down-payment to the company's billing department, step 109, where it is held until a decision regarding the issuance of the policy is made by underwriting. Among other things, the underwriting department verifies certain critical information in and related to the application. For example, the underwriting department may verify a client's driving record 112, credit history 1 14, and criminal record 1 16, along with applying the most current set of available underwriting rules of the company 118 to the application. The nature of such inquiries is that the data used, whether client related or insurance company related, may not necessarily be current, i.e. the data may be "stale". And, even if current, may become stale between the time of inquiry and the time of policy issuance. In such cases, the insurance company unavoidably assumes the risk that the factors used as the basis for issuing a policy are correct and that these factors do not change between the time of making the inquiries and the time of issuing the policy. Based on the results of these types of inquiries and analysis, a determination is made regarding whether a policy will issue, step 120 (i.e., meets the underwriting guidelines). If the policy issues, step 122, it is mailed to the insurance agent, step 124, who then notifies the client of the issuance of the policy.

Once a policy issues, a legal notice is issued to that effect, step 126, and a bill reflecting the final premium is generated. Typically, the insurance company's billing department credits the client's original down-payment toward the premium. If the amount of the premium is less than the down-payment, then a refund for the difference is mailed to the insured client, in step

132. However, it is more typical that after application of the down-payment, a balance remains and the insured client is billed in accordance with agreed upon billing terms reflected in the policy, step 130. From thereon, the insurance company generates a billing schedule and mails a bill statement to the client and the client returns statement with the appropriate payment. This process continues until the premium and any associated finance charges are paid in full.

In the case where the policy application does not meet underwriting guidelines, the underwriting department rejects the policy application, step 134, and notifies the insurance agent, step 136. The agent then works with the client to replace the policy application with a revised application, step 138, that overcomes (if possible) the basis for rejection of the previous policy application, and in doing so returns to the initial step 102 of generating new quotes based on various policy changes. This process may be repeated until the agent and client finally arrive at a policy application that results in an issued policy by the underwriting department, if possible. While policies are often written to retroactively provide coverage back to the date of the application, such protection is only useful to the client in the case where the policy issues. If the policy does not issue, the client has unknowingly been uninsured between the time of application and the time of rejection.

Therefore, it would be advantageous to the client to have a system which allows for comparison of a variety of insurance products having a variety of selected options at one time and for immediate generation and receipt of accurate price quote information for such policies. Furthermore, a system which provides near-real time policy issuance would eliminate any significant gap in coverage between the time the client applies for a policy and the time the client is informed as to whether the policy has been approved for issuance. Also, a system which allows insurance companies to efficiently maintain and control the underwriting guidelines, algorithms, rate tables, account information and other pertinent information which is accessible by agents, without a high degree of computer customization required by the agents, would expedite the policy application and evaluation process, while also reducing risk to the carrier associated with reliance on stale data.

Accordingly, it is an object of the present invention to provide a highly automated distributed computer system for dynamically accepting user information and, based thereon, generating unique product candidate solutions, displaying said candidate solutions, accepting selection of one of said candidate solutions, and storing said solution. It is also an object to provide computer access to third party financial institutions to allow electronic transfer of funds and credit card payments, for example, to facilitate bill and claim related payments. It is a further object of the invention to provide access to third party information providers (e.g., motor vehicle, claim, and credit databases), where available, to facilitate a more efficient underwriting process, for example. In such a system, it is a further object to allow real or near real-time updates of product information.

Summary of the Invention

The present invention is a data driven automated insurance transaction processing system operating over a distributed communication network to provide real or near real-time generation of policy price quotes, underwriting and policy issuance, and generation of billing schedules. An insurance agent can login to the system over the network and gain access to a core set of engines (the "Core") and Framework databases, including databases containing a plurality of insurance provider's (or carrier's) information, and quickly provide a comparison of candidate policies and corresponding price quotes from among those carriers to a client. The client and agent may select a preferred policy from among the candidate policies and in response the system issues the selected policy and generates a corresponding billing schedule. Payments against the policy premium can be made electronically by credit and debit card, payroll deduction, or electronic funds transfer. Additionally, insurance claims may be filed over the network, and a claims adjuster and an examiner may be automatically assigned from a database of preferred adjusters and examiners. The system may also be configured to generate candidate policies of types other than that requested, using at least some of the client information provided.

The system architecture includes a user management subsystem and the Framework database system (and its Core set of engines). Among other things, the Framework database system includes at least one static database for storing standard procedures, rules, and rate products and at least one dynamic database for storing data produced during a particular user session. The Core includes interfaces to related third party service providers (e.g., credit card and third party information source companies). The user management subsystem includes a group of software applications which may be configured for different types of users and that interface with the Core via the World Wide Web ("Web"), for example. As discussed below, some types of users may access the Core using a standard Web browser, while other types of users require a client-side application to be resident in their computer. Depending on the login privileges of a user, the substantive interface to the Core will vary. An interface is primarily created by the presentation of screen images on a workstation or terminal display. For example, a carrier's application interface allows an insurance provider to access the Core and view their customers' accounts. An agent's application interface allows access to the Core for generating a client's profile information and accessing insurance carrier's databases and algorithms for generating policy rate quotes, selecting a policy, issuing a policy, generating a bill schedule, accepting premium payments and filing claims. A claims application interface allows access to the Core by claim examiner's and adjusters for processing claims, including reviewing a claim, tracking the claim, and issuing claim pay-outs to service provider's (e.g., repair shops) and to clients. A general developer's (or implementor's) system (i.e., a client-server application) includes several development tools that allow access to the Core databases for the creation and maintenance of the Core and related applications. Using the development tools, a rating analyst, for example, may create and/or enter the Web User Interface (WUI) screens, rating tables, algorithms, underwriting rules, associate carrier/product information with territories, generate help text, and enter accident and violation information on a company /product basis. Access to the Core is also provided for the determination of agent's commissions and for generating system reports.

The Core includes an application interface server which acts as the interface between the Core and the management system. In the preferred embodiment, the application server is a WUI server that generally manages access to other servers and databases within the Framework to accomplish tasks requested by the external users. An underwriting engine within the Core accesses an underwriting rules database and applies these rules, as part of calculating a rate quote for a candidate policy, to input client profile information to determine whether or not the policy can be issued. If a candidate policy or policies satisfy the underwriting rules, a rate/quote engine within the Core generates a price quote for each candidate policy. A reporting engine is also part of the Core and generates reports concerning various system aspects and carrier based information for different users, as appropriate. Once a policy has been issued, a billing engine within the Core generates a billing schedule, issues bills and invoices, and applies payments received to existing accounts. At the center of the Core is a transaction engine which controls the general tasking within the Core and which processes premium transactions and payments transactions. Premium transactions relate to creating, modifying, renewing, canceling, or processing claims for an existing policy. Payment transactions relate to the transfer of money.

Brief Description of the Drawings

The foregoing and other objects of this invention, the various features thereof, as well as the invention itself, may be more fully understood from the following description, when read together with the accompanying drawings, as described below.

FIGURE 1 is a flowchart of a typical prior art process for processing an insurance policy application. FIGURE 2 A is a block diagram of an insurance processing system and FIGURE 2B is a block diagram that includes the portions of the Framework and Core, in accordance with the present invention.

FIGURE 2C is a diagram of a set of development tools included in the implementor's system of FIGURE 2A. FIGURE 3 is a diagram of a representative page displayed at a user's workstation and produced by the Core of the insurance processing system of Figure 2A.

FIGURE 4 is a table depicting a representative group of transactions performed by the transaction engine of the insurance processing system of Figure 2 A.

Figures 5 A - 5F are a series of tables which illustrate how a quote is achieved by the insurance processing system of Figure 2A.

FIGURE 6 is a diagram of a computer architecture embodying the insurance processing system of Figure 2 A.

For the most part, and as will be apparent when referring to the figures, when an item is used unchanged in more than one figure, it is identified by the same alphanumeric reference indicator in all figures.

Detailed Description of the Preferred Embodiments

The present invention is a data driven automated insurance transaction processing system operating over a distributed communication network to, among other things, provide real or near real-time generation of policy rate (i.e., price) quotes from a variety of insurance carriers' (i.e., providers or companies) multiple lines of business, issue insurance policies, and generate billing schedules. The system includes capabilities to determine and present insurance policy information from one or more of a variety of sources to facilitate comparison and selection by an insurance agent ("agent") and/or a client, based on client profile information or data which describes relevant characteristics of the person or property to be insured. Additionally, the insurance processing system includes capabilities which facilitate efficient processing of an insured client's (the "insured's") claims. Using a compliment of automated processing and electronic data storage and transfer features embodied within the system, the present invention allows for the paperless generation, comparison, and issuance of an insurance policy, as well as the electronic transfer of funds necessary for the payment of insurance premiums by the insured or the payment of claims by the insurance carrier. To accomplish this, the present invention provides real-time access to various external underwriting data sources, interfaces to outside services, such as policy printing and bank and credit card company systems, and is electronically coupled to various carrier systems.

The insurance transaction processing system is designed to allow a developer (e.g., a rating analyst or specialist) to accomplish the generation and maintenance of, for example, rate quote products using a set of user friendly (i.e., non-technical) development tools. Rating analysts are individuals knowledgeable in insurance rate subject matter, and are not required to be skilled in computer programming. Rate quote products are used, typically by an insurance agent, with specific client data to generate rate quotes for that client. The ease of use of the system provides the ability to rapidly develop and maintain a large number of rate quote products, spanning multiple lines of business, and covering all states. In the preferred embodiment, the distributed communication network is the Internet and

World Wide Web (i.e., the "Web") and the insurance processing system is a "Web-based" insurance processing system. In an alternate embodiment, the distributed communication network includes an extra-net (i.e., a form of wide area network (WAN)) using Web browser interfaces. Operating applications of the system, which implement relevant processes, and rate quotes produced by the system are delivered to users through a TCP/IP connection and a standard Web browser on the user's workstation. Delivering its services over the Web, the present invention generally minimizes costs, for example costs associated with the development and maintenance of the client-side workstation configuration.

To facilitate automated processing, the capabilities of the system are embodied in a combination of computer software and hardware. The system architecture implemented in the preferred embodiment includes a variety of terminals or workstations which run or access applications which then provide access to a Web User Interface ("WUI") Server, an implementor's system including a set of development tools for product development and maintenance and a corresponding tools server, a plurality of third party interfaces, and a database system that provides the underlining system functionality, referred to as the "Framework". For the most part, the Framework database system drives system processes. For example, the Framework database system contains the information required to build the user interface screens, maintains state in the Web-based applications, stores all of the business and underwriting rules, drives external processes which interface with remote systems, and stores business rule and transactional data. Each data element, whether a rule, a rate factor, a screen display element or some other data element is tagged with an effective and an expiration date, which allows each of the periodic rate and rule changes to be specifically preserved in the system at all times. Entering the appropriate policy effective date allows the corresponding rate, rule, and/or screen set to be automatically accessed at any time.

The Framework is driven by and includes a standard set of stored procedures that provide core, data driven functionality, referred to as "the Core". The primary functional areas of the Framework are built as a series of Core "engines" and servers. As will be described in more detail and as shown in Figure 2 A, the Web-based insurance processing system 200 includes a user management system 220 that interfaces with Core 230, wherein the Core also includes an interface to third party entities 250 and to a developer's/maintainer's, or implementor's, system 260. The user management system 220 includes a variety of computer terminals or workstations that have access to Core 230 for transaction processing. The workstations may be remote to each other and to the Core, wherein communication among the various workstations and the Core takes place over the Web using standard communication links (e.g., phone lines). While the preferred embodiment uses the Internet and Web as a communication medium, other types of networks, such as an Intranet, extra-net, local area network (LAN), WAN or a combination of networks could also be used. A workstation may be any commercially available desktop computer running a standard operating system and Web browser (e.g., Internet Explorer™ by Microsoft Corporation). As such, the workstations do not require any significant customization to access the Core.

The WUI server 232, which is an application server, is the primary interface between each workstation and the servers and engines of the Core 230 and the Framework databases they access. The WUI server 232 may be any commercially available server configured to communicate across the Internet and Web with the workstations. The engines provide the primary processing capability of the system 200, and include the necessary logic and hardware to accomplish relevant insurance processing related tasks by acting on both transactional and business rule data stored in dynamic and static Framework databases, respectively. Data which identifies the client and/or item to be insured, along with any other required client specific information required by the system 200, is referred to as client profile information or data, which is supplied by user input at a workstation during a session and constitutes at least a portion of the transactional data stored in a dynamic database. Data related to a specific policy, either an issued or candidate policy, is referred to as policy data and includes client profile information as necessary, and also constitutes at least a portion of transactional data.

A simplified database structure is shown in Figure 2B, those skilled in the art will appreciate that the databases may or may not be physically co-located with the engines or with each other and may be distributed over several devices and backed-up and mirrored as desired. Because the system is both an insurance transaction processing system and a development system (used for, among other things, maintenance and updates), the Framework database system 225 design is easily extensible by using commonly available and standard devices and interfaces. Extensibility is also accomplished in large part through the use of vertical "objectized" data structures. That is, when new data elements are required, they are added as a row in a data element master table, not as columns in a hard-coded table structure. Data element properties are stored in related tables and may be configured by product, carrier, or user, for example. The database structure is discussed further below and with respect to Figures 2B and 6. I. Management System (Workstations) There are several types of users which may access the Core to perform, in most cases, a subset of available system functions. For example, typical users may include insurance agents, clients, insurance carriers, claims adjusters and examiners, and system developers and maintainers (e.g., a "rating analyst"). In the preferred embodiment, different types of users have different privileges. For example, insurance carrier rating analysts have privileges to create and update rate tables and underwriting rules within the Core, but clients may only have privileges to review an existing policy and account information, and agents may only have privileges to generate, renew, and review a policy. Consequently, the system 200 includes user specific application interfaces (i.e., computer screens and functionality) rendered on workstations 202 - 212. Some of these application interfaces merely require a standard Web browser to access the Core, while others require user specific client-side applications. These application interfaces allow predetermined types of access to Core 230, each interface having functions specific to its corresponding type of user, based on predetermined user privileges. These workstations and interfaces are collectively referred to as the user management system 220. The Web browser application interfaces are actually generated by the Core and communicated to the workstations as hypertext markup language (HTML) code and then rendered on the workstation within a Web browser.

In Figure 2 A, a group of representative user specific "applications", each running on a standard workstation, is shown as a simplified depiction of the preferred embodiment. However, in practice, a plurality of workstations running the same application, for example, a plurality of workstations at different locations running agent's application 205, is more likely to be the case. Additionally, each workstation may run more than one type of application, such flexibility being a function of the login privileges of different types of users (e.g., carriers, agents, and claims adjusters), and wherein such users may login to and access the Core from any Web enabled workstation. As a general notion, types of users and access privileges may be defined in a variety of ways, as is known in the art. In the preferred embodiment, communication between the Core and each workstation takes place over the Web (and Internet) using commercially available hardware and software interfaces, systems and communication links (e.g., phone lines). Each type of user specific application included in management system 220 is described more fully below.

Referring once again to Figure 2A, a claims application 202 allows a claim examiner and adjuster to access the Core and manage the processing of insurance claims via a Web browser. Claim information may initially be entered into the Core via an agent's (or carrier's) workstation and an examiner and adjuster may be automatically assigned to the particular claim or recommended from a Core database of preferred examiners and adjusters. An examiner or adjuster may update and manipulate claim data from a workstation running claims application 202 during the course of claim resolution. Other users may also take part in updating or providing claim related data, such as an agent or carrier. Furthermore, an adjuster may facilitate payment of a claim electronically by transferring funds from the carrier's bank to the insured's bank or to the bank of a service provider. A service provider may be any entity involved in the repair, replacement, or resolution of the subject matter of the claim, such as an auto repair person or shop.

A carrier's application 204 is a compliment of carrier screens and functionality displayed and available within the Web browser of a workstation and which allows a carrier to access the Core directly for carrier specific purposes. The carrier's application 204 provides access to the Core to allow the carrier to update carrier information, such as rate tables and underwriting rules stored in the static Framework database 255. The carrier's application 204 also allows the carrier to access and manipulate existing policy and account information (stored in the long term database 265), accomplish payment transactions, generate new policies, and so on.

An agent's application 205 is a compliment of screens and functionality displayed and available within the Web browser of a workstation to allow an insurance agent to generate price quotes, have policies issued, query existing policies, and process claims, for example. In practice, the actual privileges associated with an agent's workstation may vary depending on a variety of factors. For example, it may be the case where an agent may only be authorized to sell products from a certain carrier or carriers, while other agents may be authorized to sell products offered by any available carriers. It is envisioned that workstations or terminals running the agent application will be located at various locations where agents service the needs of existing and potential clients. For example, access to the system of the present invention may be franchised to agents and agencies, wherein agent workstations may be located in any of a variety of locations as franchise locations. Such locations may include traditional agency offices or non- traditional forums such as retail store or wholesale club locations, as a means of improving the consumer's accessibility to such insurance related services and products.

A data access application 206 is a compliment of screens and functionality displayed and available as a client-side application running on a workstation that is used for accessing and extracting data from and storing data to the management system 220. The data access application 206 may be used by any of a variety of users to obtain reports and data consistent with the user's privileges. For instance, data (e.g., system performance measures) may be extracted from the Framework database system by a system manager using the data access application 206 to determine if system performance is acceptable.

A system manager's application 208 is used to generally maintain the Core 230, e.g., keep applications, frameworks, utility versions, and so on up to date via a Web browser. The system manager can monitor system performance and tune the system by adjusting, to some degree, the allocation of system resources (e.g., processors and memory).

A commissions application 210 is a compliment of functionality and screens accessible on a workstation that is interfaced with a call center and agency application 212 to accomplish up-to-date commission processing and maintenance of commission rates within the a carrier's call center or an agency. The call center and agency application 212 logs on to the Core to retrieve information related to the determination of an insurance agent's earned commissions, such information being maintained within the Core as part of typical transaction processing. II. The Core 230

The Framework database system provides the primary functionality and data storage capability of the preferred embodiment of the present invention, and it is the Core 230 of the

Framework which provides the functionality, as shown in Figure 2B. Core 230 accesses a series of Framework databases which store data, such as business and underwriting rules for each insurance carrier (in database 255), client policy and account information (in database 245 and/or 265), and all other necessary business and transactional data. In the preferred embodiment, the

Framework databases are object-centric relational Structured Query Language (SQL) databases, version 6.5. SQL databases are known in the art and are not discussed in detail herein. For the most part, Core 230 includes a series of stored procedures that provide data-driven functionality, referred to as "engines" and servers. As examples, the engines and servers use the data in the Framework databases to build user interface screens, generate policy information and quotes, issue, store and maintain policies, and accomplish claims processing. These engines and servers include: billing engine, rate/quote engine, reporting engine, tools server, transaction engine, underwriting engine, and WUI server. Generally, the servers provide interfaces between external users and the Core and the engines accomplish tasks in response to server requests. The Core includes external interfaces to the management system workstations and to third party systems for performing a variety of ancillary insurance transaction functions, such as electronic funds transfer, credit/debit card authorizations and transactions, and lock box processing. Core 230 also includes an interface to implementor's system 260, which includes a set of development tools for the creation of WUI pages, rate tables, underwriting rule databases and so on, as well as general maintenance of the system. Each engine and server is described below, a. WUI Server 232

The WUI server 232 is the primary interface of external users to the Core for processing insurance transactions. In the preferred embodiment each WUI server is a commercially available server running Windows NT™ Server 4.0 software, by Microsoft Corporation. The WUI server 232 includes functionality which generates and communicates, in real-time, HTML computer screen information corresponding to a screen image to be rendered at a user's workstation during a session. When the HTML screen information is received, the user's workstation processes the information using a standard Web browser to produce and present the desired screen image. As the interface to the workstations of the management system 220, the WUI server controls user privileges, as a function of the user's login, for accessing the Core.

More specifically, the WUI server 232 extracts rules from the Framework databases, as shown in Figure 2B, guiding which graphic, data, and functional elements are to be displayed then dynamically builds pages according to a predefined general layout. As a result, system performance is enhanced, wherein the WUI server 232 generates screen information dynamically in response to user inputs, such that the next screen to be displayed is a function of the client profile information and responses input in the current (and previous) screens, as well as the business and underwriting rules stored within the Framework databases. Building screens dynamically involves generating and sending software code from the WUI server 232 to a workstation, wherein the Web browser running on the workstation compiles the code (e.g., HTML code) and builds the screen therefrom. The preferred embodiment employs software written using a commercially available server-side scripting software language, such as ColdFusion® (by Allaire™ Corporation), to accomplish the dynamic generation of screen images processed and displayed by the Web browser, using data from the Framework databases. Therefore, once the user submits responses to the WUI server 232 (via a workstation) the server executes the server-side scripting language (which is an application) to quickly generate HTML code, which is then sent by the WUI server back to the workstation and Web browser of the user. The Web browser running on the workstation then builds the appropriate screen using the HTML code.

To start a session, a user logs on to WUI server 232 via the Web using the standard Web browser interface. The user may, for example, be an agent working with a client to obtain policy information and compare policies or a user may be a client seeking to review the status of an existing policy. In other embodiments, the client may be given the flexibility to compare and have policies issued without the use of an agent. Using agent's workstation 205 and WUI server 232 generated screens, the user enters client profile information (or client data) to define the client and/or property to be insured to the system 200 and to identify the type of policy or policies of interest, which is stored in transactional database 245 during the agent's/client's session. Client data identifies the client and subject matter of the policy of interest and includes, for example, the client's name, age, and address, and also includes any basic information necessary for the system to generate one or more policy rate quotes for the type of policy of interest. For example, this basic information may include the make, model, and year of an automobile to be insured. In addition to generating computer screen information, the WUI server 232 manages the flow of information in and out of the Core, and (along with the transaction engine 236) the assignment of tasks to engines and the storing of data into Framework databases.

Through the WUI server 232, users remotely perform a variety of transactions, such as obtain policy rate quotes, access billing information, and process claims. To facilitate the input of relevant information for processing a transaction, the WUI server 232 incorporates a 4-level hierarchical tree structure within the screen images, including pages 300, sections 305, questions 310, and options 315 (the lowest level), as shown in Figure 3. That is, a page contains sections, sections contain questions, and questions contain options. As an example, page 300 in Figure 3 relates to an automobile policy and the input of client profile information. A page is an electronic graphical equivalent (i.e., screen image) of a physical page of data. A section 305 divides a page 300 into sets of questions 310. A question 310 solicits a response and, thereby, obtains information for the Core transaction processing. A question may be visible or hidden, wherein a visible question may ask for date of birth and the hidden question may compute age therefrom. For the most part, responses to questions are stored in dynamic transactional database 245.

Each question is assigned a data type to define the form of the response, which corresponds to a data definition within a Framework database. In the preferred form, data types include free text, drop-down list, and button. A data type of free text relates to a question that requires a free text response typed into a corresponding answer field. A data type of drop down list means that the question requires the response be selected from a corresponding list of responses (i.e., options 315). A data type of button refers to a question that is displayed as either a button or hyperlink, which when clicked submits a request for a new page to the Web browser. Questions may also include formulas, typically embodied within the servers and engines, that aid in the generation of the code corresponding to the next page to be submitted to the workstation. For example, if a user selects the option "Under 25 years of age", then the code generated for the next page submitted will be different than if the user selected the option "Over 25 years of age". Those skilled in the art will appreciate that other forms of input data types may be used, such as graphical sliding scales, audio/voice data input, and so on, without departing from the present invention.

In practice, once the user has logged into the Web server 232, the Web browser running on the remote user's workstation submits a request for a page to the WUI server 232. The WUI 232 server analyzes the request and returns the appropriate screen image code and data to the workstation, assuming the request is consistent with the user's privileges. The WUI server 232 passes user requests and associated tasking to the transaction engine 234 (as shown in Figures 2A and 2B), which then tasks the other Core engines and servers to accomplish tasks related to the user's request, some of which may involve the Core obtaining information from third parties. For example, if a user is seeking to obtain rate quotes for a new auto insurance policy in Massachusetts, Core 230 may be configured to automatically request the client's driving record from the Massachusetts Registry of Motor Vehicles, assuming it is available on-line, and such information may be used in determining whether the client is insurable and, if so, comparative policy rate quotes are generated, b. Transaction Engine 234 The transaction engine 234 receives user transaction requests via the WUI server 232 and serves as the central director and manager for processing within Core system 230, as shown in Figures 2 A and 2B. In response to workstation requests by a user, the WUI server 232 passes the user's request to the transaction engine 234 for processing. The transaction engine then controls the processing of the transaction using the other engines and servers within the Core 230 and Framework databases as needed. In the preferred embodiment, transactions primarily fall into one of two groups, either premium transactions or payment transactions. Premium transactions potentially effect the policy premium. The types of transactions in the premium transaction group include: new business (i.e., policies) and policy amendments, changes, endorsements, renewals, cancellations, rescissions, terminations, non-renewals, and claims processing.

Payment transactions involve the transfer or exchange of money, and the group includes billing termination and resumption, premium returns, receipt of payments (including cash), transfers of funds electronically, and write-offs. A representative list of actions (i.e., transactions) and descriptions preformed by the transaction engine 234 in the preferred embodiment is provided in Figure 4. Generally, each type of transaction is customary in the insurance business and will not be explained in detail herein and, in fact, most are self-explanatory.

The transaction engine 234 includes three managers, which are embodied in stored procedures and data (associated with, for example, rating server 630a of Figure 6) used for processing transactions, and serves as the central processor of the WUI server 232 requests. As such, the transaction engine 234 interacts with other severs and engines within the Core and

Framework databases, as required. The transaction engine 234 includes a transaction manager, a quote manager, and a policy manager, in the preferred embodiment. Generally, the managers respond to user manipulation of a WUI screen (e.g., answering questions) at the user's workstation to create, modify, or view a policy, for example. As part of a user's request, the WUI Server 232 assigns a value ("Q" for quote or "P" for policy) to a "transaction type" parameter associated with the user's request. The WUI server 232 calls transaction engine 234 which invokes the transaction manager to service the user's request for a transaction, using procedures, rules, and rate products in database 255. In the preferred form and as shown in Figure 2B. the standard procedures, rules, and rate products are stored in substantially static database 255 and transactional data (e.g., client profile data and rate quotes) associated with a particular user's session are stored in a dynamic (or relatively temporary) database 245. It should be understood that databases 255 and 265 are not truly static, in that they are updated from time to time, for example, when a carrier issues new rate products. However, with respect to the session oriented dynamic database 245, databases 255 and 265 are relatively static.

Based on the value of the transaction type parameter, the transaction manager directs the request to either the quote manager or the policy manager. If the user has requested comparative policy rate quotes the transaction type parameter is set to "Q" and the transaction manager invokes the quote manager to operate on the request by interacting with the rate/quote engine 236. The quote manager saves information from the front-end (i.e., workstation) to a quote repository in dynamic database 245 for use by the rate/quote engine and retrieves information from the repository for use by the front-end. Once the rates are determined by the rate/quote engine, the quote information is passed from the rate/quote engine 236 to the billing engine 242 (but staying within database 245), where a billing schedule is automatically generated.

If the quote type parameter is set to "P" and a policy already exists, the transaction manager invokes the policy manager to retrieve the requested policy and, subsequently, desired policy actions (e.g., renew) may be accomplished. On the other hand, if the quote type parameter is set to "P" and a policy does not exist, the transaction manager invokes the policy manger to create a new policy image into which the client profile data is merged, and processing is passed to the rate/quote engine 336 for generation of a rate quote, which is stored in transactional database 245 until the policy is issued or the session is ended, c. Rate/ Quote Engine 236

The rate/quote engine 236 provides the client and agent with a quote, or bottom-line price, for an insurance product or products. The rate/quote engine is a set of back-end procedures and tables in static database 255 that perform mathematical calculations. The engine 236 matches rating elements with client profile information in dynamic database 245 to calculate "components", which are the building blocks of a quote. Premiums are calculated for each component and the sum of all premiums is presented as the quote. For the most part, there are three parts to the rate/quote engine 236: client profile information, rate product algorithms, and quotes. Client profile information (i.e., client data) is information stored in database 245 about the client that is entered at a workstation into the WUI server 232 by the user, as discussed previously. The rate product algorithms are stored in database 255 and used to calculate rate quotes, each carrier may have their own algorithms and each policy type and policy option offered by each carrier may have a unique set of algorithms. A quote is the policy cost at a given point in time. And, rating elements are carrier defined rates for individual coverages.

A component is the mathematical representation of a coverage, which, when combined with other components, comprises the total premium. For any component, there can also be sub- components. For an item to be a component of a coverage or total premium, it must be computed before the coverage or total premium is computed. While components are mathematical expressions, formulas determine the amounts that comprise the components. Since the determination of one component may be used to determine another component, components are processed in a deliberate order, referred to as the "rate sequence."

To understand how components and a rate are calculated, it is useful to know how carrier manual details (rates, algorithms, etc.) are mapped to formulas and components. As an example, Figure 5 A shows a table of the bodily injury (BI) rating elements listed in an insurance manual for a hypothetical carrier XYZ. BI is just one of the numerous rating elements that make up the total premium. The left column (a through k) lists the elements that make up the BI rating component. The right column (A through J) lists the component calculations (or formulas). With the above information, a tree-diagram is created which represents how the rating elements are to be processed. This tree is created by starting at the first element to be processed (i.e., Base Rate x Territory Relativity) and diagramming the components until the last element is included. Figure 5B shows the resulting tree-diagram 510. Once the tree-diagram 510 has been created, the rating elements can be entered into the system, applying formulas to components and assigning rate sequences.

A rate sequence is a number assigned to each element and represents the order in which elements are processed in order to calculate the total premium. For example, if there are two components, Territory Relativity and Multi-car Discount Factor, and the Multi-car Discount Factor needs to be multiplied by a number that includes Territory Relativity in its formula, Territory Relativity will have a lower rate sequence than Multi-car Discount Factor. In this case, the rate sequence assigned to the Base Rate times Territory Relativity is 10, and the sequence assigned to Multi-car Discount Factor is 35. This way, the components that make up the Multi- car Discount multiplier (which includes Territory Relativity) can be processed first. It is preferable to have a unique rating sequence for each component, but the rate sequence number need not be unique. For example, two unrelated questions, both with a rate sequence of 10, will be processed in an arbitrary order as determined by the system immediately after questions with rate sequences of less than 10. The rate/quote engine inverts the tree-diagram of Figure 5B, as shown in Figure 5C, and starts processing at the lowest level of the tree. In this example, components with rate sequence 60 are the individual coverage premiums. Components with rate sequence 70 are the sums of these premiums and many other factors that may be applied (e.g., car rental factor). Rate sequence 80 sums all the components, resulting in the total premium.

Components are calculated using rates and factors, which are based on coverage choices and associated limits and the client profile information. Figure 5D shows the base rate and the factors for the BI coverage, as defined by the hypothetical carrier XYZ. The base rate is dependent on Territory and other similar client-related information. To illustrate how rating is done, the BI premium is calculated, as an example, using a specific hypothetical client profile. In this example the client profile information is such that the client: a) chooses 25/50 BI coverage, b) lives in territory 5, c) is thirty-five years of age d) drives a car for pleasure (non-business), e) has one Driving Under the Influence conviction and one violation, f) would like to increase his limit factor, g) owns one car that is rated as having "intermediate" performance, h) also has a homeowner's policy,

I) always uses his car, and j) will pay semi-annually.

Figure 5E shows how the rates are assigned to this client profile for the BI coverage. The factors are calculated and shown in Figure 5F, wherein the total BI premium is $853. This premium is ultimately added to the premiums for other coverages (not shown), resulting in the total policy premium. In this example, there is one car and one driver. If a policy has multiple cars and/or drivers, the rate/quote engine will process a component calculation for each.

A temporary Framework database location, i.e., dynamic database 245, holds each premium, that is each component calculation. The premiums for each component are summed to produce the total policy premium. The total policy premium is the quote, before issuance. In the preferred embodiment, two tables (i.e., databases) are populated when the actual rate/quote transaction occurs, a premium table and a question table. The premium table is where premium information is stored for each component calculation and includes effective and expiration date tags, since a rate quote will only be valid for a fixed amount of time typically. Ultimately, the question table is used to save the answers associated with each component; this table stores the information used to obtain the quote. A policy (or total premium) quote is based on client profile information and the business climate at a specific moment in time. If the quote is accepted by the client, it is stored in permanent database 265 and made into a policy. If the quote is not accepted, it may be saved in temporary database 245. In a comparative rating environment, there may be many quotes from multiple carriers stored.

The system may be configured to generate candidate or recommended policies of types in addition to the policy type for which the initial quotes were sought. In such a case, it would be preferable, but not essential, that the system generate such candidate policies and quotes based solely on the client profile information input to obtain the initial quotes. As an example, if a client and agent requested quotes for an automobile policy, the system can search the Framework databases to determine whether the client has an existing homeowner's policy and, if not, the system generates and offers comparative homeowner's quotes to the client, in addition to the auto quotes. d. Underwriting Engine 238

Generally speaking, underwriting is the process in which a carrier assesses the risks of insuring the client and determines whether to offer insurance based on that assessment. Underwriting rules exist in an underwriting rules database of the Framework for each type of policy offered by each carrier, such as database 255. The underwriting engine 238 and rules are accessed by the rate/quote engine 236 in response to a request for a rate quote, such information and rules being used to facilitate the generation of a rate quote for a given carrier. In the preferred form, the rate/quote engine 236 tasks the underwriting engine 238 to apply rules before a quote is actually calculated. That is, once it is clear that the carrier would underwrite the candidate policy, the rate quote is prepared and initially stored in transactional database 245. e. Tools Server 240

The key to developing applications with the system is a development tool set included as part of the implementor's system 260. The development tool set shields an application developer from the underlying table structures and stored procedures of the system and provides a user friendly, rapid development environment for building and maintaining rate quote products. For the most part, tools server 240 is accessed and used by the implementor's system 260 as an interface to Core 230. The tools server 240 is, therefore, a development and maintenance server which includes the functionality to process inputs from a developer or maintainer (e.g., rating analyst) to create and edit WUI pages, sections, etc. and to create carrier products (e.g., rate quote products). f. Billing Engine 242

The billing engine 242 generates a billing schedule, that is, a schedule of payments, issues bills and invoices, and applies payments. The billing engine 242 accesses third party financial institutions to accomplish any of a variety of monetary transactions, as appropriate.

Monetary transaction methods include, for example, payroll deductions, electronic funds transfers, and credit/debit card transactions, g. Reporting Engine 244 The reporting engine provides carriers, agents, and system managers with reports on various aspects of the system through the various applications. Such reports generally provide business management information. For example, the following reports are provided to the following types of users: a) to carriers: new business, renewals, written/earned premium, claims etc.; b) to agents: those of part a) above plus commissions; and c) to system managers: same as part b). III. Other Interfaces a. Implementor's System 260

The implementor's system 260 is used by developers (e.g., rating analysts) to create and maintain rating products (see Figures 2 A, 2B, 2C and 6) stored in the static Framework database 255 and used by the Core's rate/quote engine 236. The implementor's system 260 includes several development tools (or tool modules), shown in Figure 2C, in the preferred embodiment, which are stored in static database 255. These development tools include a web user interface tool 261 that is used to design and layout WUI screens or pages, such as the computer display screens accessed by an agent when requesting an insurance policy rate quote from the system 200. Such screens include information and questions which prompt the agent to enter client profile information required to provide a policy rate quote. A rating tool 262 is used to enter basic rates into rate tables and to enter and store rate algorithms and procedures. These rates, algorithms and procedures are associated with rating questions, which ultimately are presented to a user in WUI pages, wherein the responses are used for determining the final rate quotes. Each carrier determines their own rates and algorithms and those are built into Core 230 using the rating tool 262. An underwriting tool 263 is used to enter carrier specific underwriting rules as logical formulas into static Framework database 255. A territory tool 264 is used to enter the specific territories and corresponding rate factors used by the rating engine, per company and per product. Accordingly, territory codes are associated with ZIP codes corresponding to the geographic area or areas for which insurance coverage can be obtained. Generally, a rate quote is a function of the rates, algorithms, and rate factors for the geographic area or territory in which the policy is to be issued. For example, a carrier's basic rate for a certain policy may be $100 which then gets multiplied by a factor of 1.1 for a given geographic territory to produce a final rate quote of $110.

The ability to generate useful quotes is, of course, dependent on the sufficiency and accuracy of the user's inputs. Therefore, a question help tool 266 is used by the rating analyst to enter help text for each question to be included in the WUI screen displays. A violations tool 267 is used for auto, motorcycle, and boat rate products, to specify the accidents and violations that the insurance carrier tracks for the purpose of rating each insured driver/operator. In the preferred embodiment, a specific violation code (SVC) mapping tool 268 is used to map standard violation codes, accessed via ChoicePoint Inc., to company specific violation codes for auto, motorcycle and boat rate products. An unacceptable vehicle tool 269 allows a rating analyst to specify the make and model of each vehicle that each insurance carrier does not insure for auto, motorcycle, and boat rate products. The information entered via tools 267-269 is also used in calculating rates, for the appropriate types of policies.

As will be appreciated by those skilled in the art, various development tools may be defined which embody the basic functionality (or modifications thereto) of the development tools described herein without departing from the spirit and scope of the present invention. The tools described herein are intended to be illustrative and not exhaustive, b. 3^rd Party Interfaces 250

Third party interfaces 250 include interfaces to a variety of entities and services useful in automating the transaction processing of the insurance processing system 200. More specifically, the third party interfaces are responsible for retrieving underwriting verification data from industry specific service bureaus, transferring policy data to carriers, and importing data to system Framework databases from carriers for the purpose of billing and claims inquiry. Such third parties also include banks (as shown in Figure 6) and credit card companies, as well as other financial institutions, accessed for electronic fund transfers, payroll deductions, credit card charges and so on to pay premiums and other insurance related expenses or to issue refunds or pay outs. Third parties may also provide financial information. For example, the system may interface with First Data, Inc. for real-time credit card authorizations. As another example, the system may include interfaces to state or federal agencies having information relevant to the insurability of a client, perhaps criminal or motor vehicle database information. One example of a commercially available database interfaced by the preferred embodiment of the insurance transaction processing system 200 is provided by ChoicePoint, Inc., which provides real-time access to motor vehicle registry data for about thirty states, presently, and also provides credit history as well as claim history information for automobiles and personal property. Another database interfaced by the system is made available by Trans Union Inc., which provides individuals' credit scores. To obtain such data, the WUI server of the present invention provides a "COM" object over the network to relevant third parties, wherein the object includes built-in methods used to request information from the data and service providers to which they link. It is envisioned that such third party information would become increasingly available and that the present invention incorporates interfaces to such increasingly available databases and sources. IV. Architecture

Figure 6 shows a preferred architecture 600 which implements the insurance processing system 200 shown in Figures 2A and 2B. The server topology is configured as two networks. A first network 605 is routed to external networks for user access, and a second network 610 is a non-routed internal network for database access. The front-end WUI servers 232a-c are multi- homed with one network interface to the routed network 605, and a second network interface to the non-routed, back-end SQL server network 610. All Framework data are maintained in back- end dedicated SQL servers 620 and 630a-b that are single-homed, not routed. The third party interface server 650 runs system custom software to access 3^rd party data sources 655 linked to the database network 610.

The front-end WUI servers may be duplicated as required for scalability, and are clustered for high availability, preferably using a "cluster CATS" solution from Allaire, Inc.. The back-end SQL servers are also clustered and all systems run with mirrored hot swapable drives and redundant power supplies, for high availability and fault protection. The Framework includes a collection of individual SQL server databases that may be run on multiple separate computers, as load balancing demands. Load is distributed among these sources based on user logon and therefore may be grouped in logical units, such as all agents in one or more states. The databases shown in Figure 6 depict a physical implementation of the static and dynamic databases of Figure 2B. Wherein, temporary databases 624, 636a and 636b correspond to dynamic database 245 of Figure 2B and the remaining databases of Figure 6 correspond to static databases 255 and 265 of Figure 2B.

With more specific regard to the preferred embodiment shown in Figure 6, each WUI server 232a-c is actually a cluster of individual servers, with each WUI server supporting one database server. Generally, each WUI server cluster is paired with a database server and typically designated for a specific type of user, but this need not always be the case. For example, WUI server cluster 232a is designated for general management application serving, that is, it is not designated to any specific type of user (see discussion related to workstations 202,

204, and 208 in Figure 2A). WUI server 232b is designated for call center rating and WUI server 232c is designated for agency rating (see discussion related to workstations 210 and 212 in Figure 2A). Those skilled in the art will realize that either more or less WUI servers 232 could be included in the architecture 600 and dedicated to one or more sub-groups of users in a variety of configurations.

A plurality of rate product servers 630a-b are included within the architecture and are accessed by their associated WUI servers 232a-b respectively. While only two rate product (i.e., "QUOTE Services") servers are shown in Figure 6, there can be any number of rate product servers, wherein a rate product server can be associated with a given state, carrier, or line of business. Each rate product server 630a and 630b includes a corresponding general database management Framework 632a and 632b, respectively, including a series of general utilities and information 634a and 634b used by the server to assist in the generation of rate quotes. Also included with each server as part of the Framework is a temporary data storage area 636a and 636b, each of which is used as a repository for data while the rate quote is being prepared.

Information that may be stored in such an area includes client profile information and candidate policy information. Once a candidate policy is chosen (i.e., a preferred policy) and a policy is issued, that policy is stored in a permanent (or long term) memory location, such as database 265 of Figure 2B. The architecture of Figure 6 also includes a report application server 640 which hosts a variety of applications for producing reports used in the general monitoring and maintenance of the system and for analyzing carrier and agent related information including client account information. Additionally, there is a third party interface server 650 which is used, for example, by the billing engine 242 and underwriting engine 238 of the Core. As an example, the billing engine may use the third paπy interface server to exchange information necessary to conduct electronic fund transfers with a bank or between banks 655, or among other financial institutions. The third party interface 650 is also used to access data from information providers during the underwriting and rate quote process to verify or obtain client profile information, depending on the availability of on-line resources. The system is maintained on a single set of servers, preferably, and delivered via an IP connection and a browser. Consequently, maintenance and software version control is greatly simplified. For example, when a carrier issues a modified set of rates or underwriting rules, the new rates are entered into the system "development" area, then moved to a "staging area" for Quality Assurance (QA) review, and ultimately released to the production servers where they then become available for use by agents, clients, and so on. The development area refers to an off-line development environment where manipulation, formatting, and testing of code is accomplished, as needed, using system tools as preparation for releasing the new rates and/or rules as software code to the production system 200. Once the development team is satisfied that such code is ready for release, the code is moved to the staging area which models the production system, and QA provides verification of the code's readiness. Because a single set of servers is used, release to production by QA accomplishes a simultaneous upgrade for all users. Additionally, the reliance on commonly available and standard computers and interfaces (e.g., Windows NT servers, SQL server databases, Web browser interfaces, and so on) and the ability to seamlessly add additional servers to support additional users results in an architecture with relatively unlimited scalability.

The invention may be embodied in other specific forms without departing from the spirit or central characteristics thereof. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by appending claims rather than by the foregoing description, and all changes that come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.

Claims

1. An insurance transaction system for processing transactions related to new or existing insurance policies across a remote communication network by a user, the insurance transaction system comprising: A. at least one computer workstation having a display screen and an input device, by which the user interacts with said insurance transaction system; B. at least one database having insurance rating information and underwriting rules stored therein for a plurality of insurance carriers; C. an application server, including: I. an application interface, which generates initial and subsequent prompts at said workstation for the user to input client data associated with a specific client, wherein said subsequent prompts are dynamically generated as a function of previous client data inputs at said workstation; ii. a quote generator which, as a function of said client data inputs, said rating information, and said underwriting rules, generates data representations, including rate quotes, of one or more candidate policies of a selected insurance product type from the plurality of insurance carriers; iii. a display generator which displays at the display screen said candidate policies for comparison, if more than one candidate policy has been generated by said quote generator, and selection of a preferred policy from said one or more candidate policies by said user using the input device; iv. a policy issuer which, as a function of the user's selection of a preferred policy, establishes in said database an issued policy corresponding to said preferred policy and correlated to said client; and v. a billing generator which generates and stores in said database an electronic billing schedule corresponding to said issued policy; and d. a communication network which interconnects said workstation with said application server and said database.

2. The insurance transaction system of claim 1 wherein the database includes rating information and underwriting rules for at least one other type of insurance product and the quote generator includes a companion quote generator which, as a function of said client data inputs and said rating information and underwriting rules for at least one other type of insurance product, generates data representations of one or more candidate companion policies from the plurality of carriers.

3. The insurance transaction system of claim 1 wherein the communication network includes the Internet.

4. The insurance transaction system of claim 1 wherein the communication network includes the World Wide Web.

5. The insurance transaction system of claim 1 wherein the communication network includes at least an extra-net or an intra-net.

6. The insurance transaction system of claim 1, wherein the application server further includes: vi. a payment processor which accepts electronic funds transfer information input at said workstation, including a payment amount to be transferred from an identified financial account associated with said client and client policy identification information which identifies a policy to which the payment is to be applied; and vii. a bill updater which applies the payment amount to a balance of the identified policy and recalculates the balance and generates a revised billing schedule as a function of the application of said payment amount.

7. The insurance transaction system of claim 6, wherein the said electronic funds transfer is of the type from the group comprising payroll deduction, direct payment, and electronic bill payment.

8. The insurance transaction system of claim 1 , wherein the application server further includes: vi. a payment processor which accepts credit card information input at said workstation, including a payment amount to be credited from an identified credit card account associated with said client and client policy identification information which identifies the policy to which the payment is to be applied; and vii. a bill updater which applies the payment amount to a balance of the identified policy and recalculates the balance and generates a revised billing schedule as a function of the application of said payment amount.

9. The insurance transaction system of claim 1 , wherein a subset of said underwriting rules and rating information residing on said database relates to each carrier, and said subset is accessible and maintainable independently by the carrier to which the subset corresponds and across the computer network.

10. The insurance transaction system of claim 1 , wherein the system is adapted for the processing of an insurance claim in accordance with a client's existing policy issued by an insurance carrier and stored in said database, wherein a subject matter of said claim identifies the situation to be remedied or damage to be repaired under said claim, and the database includes information corresponding to a set of preferred providers for providing services related to remedying said situation or repairing said damage and a set of insurance adjusters for assessing the monetary claim value associated with said remedy or repair under said policy, wherein the application server includes: vi. a claims input interface, which generates prompts at said workstation for the input of client claim data, including the subject matter of said claim and identification of the client's existing policy in said database; vii. an adjuster assigner, which assigns an insurance adjuster to said claim, the assignment being a function of a set of predefined adjuster criteria stored in said database and said claim data; and viii. a provider assigner, which assigns at least one preferred provider from said set of preferred providers to said claim, the assignment being a function of a set of predefined provider criteria stored in said database and said claim data.

11. The insurance transaction system of claim 10, wherein the application server further includes: ix. a claim payment processor which electronically transfers a payment amount derived from said claim value from a carrier financial account of said insurance carrier to a preferred provider financial account of said preferred provider.

12. The insurance transaction processing system of claim 1 , further including: e. a framework database system which includes said at least one database as a substantially static database.

13. The insurance transaction processing system of claim 12, wherein said framework database system includes objectized extensible databases.

14. The insurance transaction processing system of claim 12, wherein said framework database system includes at least one dynamic database for storage of transactional data, said transactional data including session oriented data comprising at least said client data and said candidate policies.

15. The insurance transaction system of Claim 1, further including an implementor's system comprised of a workstation and a plurality of development tools usable to create at least a portion of said application interface and to enter and store in said database said insurance rating information and underwriting rules from a graphical user interface, wherein each development tool includes program code stored and executable on said workstation.

16. The insurance transaction system of claim 15, wherein said application interface is comprised of a plurality of display screens and said development tools include a web user interface tool configured to layout said display screens and generate corresponding program code and wherein said display screens include said application interface initial and subsequent prompts.

17. The insurance transaction system of claim 16 wherein the display screens are pages which are segmented into one or more sections, and wherein each section may include one or more questions and each question may include one or more options.

18. The insurance transaction system of claim 17, wherein said development tools include a question help tool configured to enter and associate with each question explanatory help text to facilitate a user's accurate input of said client data.

19. The insurance transaction system of claim 15, wherein said rating information includes rates, rate formulas, and rate procedures and said development tools include a rating tool configured to enter and store in said database, for each product or policy of each insurance carrier, said rates, rate formulas, and rate procedures and selectively create associations between at least a portion of said rating information and said application interface initial and subsequent prompts.

20. The insurance transaction system of claim 15, wherein said development tools include an underwriting tool configured to enter and store in said database, for a given carrier, said underwriting rules as logical formulas.

21. The insurance transaction system of claim 15, wherein said development tools include a territory tool configured to associate one or more pre-existing insurance carrier territory codes, as part of said rating information, with one or more geographic Zip codes, wherein a territory code is indicative of the degree of risk associated with offering a given policy in a given geographical area.

22. The insurance transaction system of claim 15, wherein said development tools include a violations tool configured, for auto, motorcycle, or boat insurance policies offered by a given carrier, to define and enter into the insurance transaction system one or more types of accidents and violations tracked by said carrier for the purpose of generating said rate quotes.

23. The insurance transaction system of claim 15 wherein said insurance transaction system is capable of accessing, via said communication network, a third party violations database system having predetermined third party violation codes, and said development tools include a specific violation code mapping tool configured to map said third party violation codes to carrier specific violation codes in said database, for auto, motorcycle, or boat insurance policies offered by each carrier.

4. The insurance transaction system of claim 15, wherein said development tools include an unacceptable vehicles tool configured to define, as part of said rating information, for each insurance carrier, the make and model of each auto, motorcycle, and boat not insurable by said insurance carrier, for each auto, motorcycle, or boat insurance policies offered by said insurance carrier.

25. A method for processing insurance transactions within an insurance transaction system having at least one workstation including a display screen and an input device, at least one database, and at least one application server interconnected via a communications network, wherein the database includes rating information and underwriting rules from a plurality of insurance carriers, the method including the steps of: A. prompting a user to select at said workstation a type of transaction from among a plurality of available transaction types, including: i. issuing a new policy, wherein a plurality of candidate policies are generated and displayed for selection of a preferred policy by the user; ii. effecting a payment related to a policy; and iii. processing a claim against an existing policy; B. prompting the user to input at said workstation client data required by the insurance transaction system for the processing of the selected type of transaction, wherein subsequent prompts are dynamically generated as a function of the previously input client data; and C. processing said selected transaction as a function of said client data and rating information.

26. The method for processing insurance transactions of claim 25 wherein, when the selected type of transaction involves issuing a new policy of a selected insurance product type, step C includes: C-l . generating, as a function of said user inputs, rating information, and underwriting rules, data representations, including rate quotes, of one or more candidate policies from the plurality of carriers; C-2. displaying at said display screen the candidate policies for comparison, if more than one candidate policy has been generated, and selection of a preferred policy from said one or more candidate policies by said user using said input device; C-3. establishing in said database, as a function of the user's selection of said preferred policy, an issued policy corresponding to said preferred policy and correlated with said client; and C-4. generating and storing in said database an electronic billing schedule corresponding to said issued policy.

27. The method for processing insurance transactions of claim 25, wherein the database includes rating information and underwriting rules for at least one other type of insurance product, and step C further includes: C- 1.1. generating data representations of candidate companion policies from the plurality of carriers, as a function of said client data inputs and said rating information and underwriting rules, for at least one other type of insurance product.

28. The method for processing insurance transactions of claim 25, wherein said workstation communicates with said application server via the Internet.

29. The method for processing insurance transactions of claim 25, wherein said workstation communicates with said application server via the World Wide Web.

30. The method for processing insurance transactions of claim 25 wherein said workstation communicates with said application server via at least an extra-net or an intra-net.

31. The method for processing insurance transactions of claim 25, wherein when the selected type of transaction involves effecting a payment, the step C includes: C-l . inputting at said workstation electronic funds transfer information, including a payment amount to be transferred from an identified financial account associated with said client and client policy identification information which identifies a policy in said database having a balance to which the payment is to be applied; C-2. applying said payment by electronically transferring said payment amount from said identified financial account to a carrier financial account associated with said policy; and C-3. recalculating said balance and generating a revised billing schedule as a function of the application of said payment.

32. The insurance transaction system of claim 31 , wherein electronically transferring said payment constitutes a transaction of the type from the group comprised of payroll deduction, direct payment, and electronic bill payment.

33. The method for processing insurance transactions of claim 25, wherein when the selected type of transaction is effecting a payment, step C includes: C-l . inputting at said workstation credit card information, including a payment amount to be credited from an identified credit card account associated with said client and client policy identification information which identifies a policy in said database having a balance to which the payment is to be applied; C-2. applying said payment by electronically crediting said payment amount to said identified credit card account and transferring said payment amount to a carrier financial account associated with said policy; and C-3. recalculating said balance and generating a revised billing schedule as a function of the application of said payment.

34. The method for processing insurance transactions of claim 25, wherein a subset of said rating information and said underwriting rules in said database corresponds to a first carrier from said plurality of carriers, the method further including: D. accessing remotely over the communication network said database by a first carrier; and E. updating said corresponding subset of rating information and underwriting rules in said database by said first carrier.

35. The method for processing insurance transactions of claim 25, wherein when the selected type of transaction involves processing an insurance claim in accordance with an existing policy issued by an insurance carrier and stored in said database, a subject matter of said claim identifies the situation to be remedied or damage to be repaired under said claim, and the database further includes information corresponding to a set of preferred providers for providing services related to remedying said situation or repairing said damage and a set of insurance adjusters for assessing the monetary claim value associated with said remedy or repair under said policy, step B includes: B-l . inputting at said workstation client claim data, including the subject matter of said claim and identification of the client's existing policy; and step C includes: C-l . generating and displaying at said workstation a preferred adjuster list from said set of preferred adjusters as a function of a set of predefined adjuster criteria and said claim data; C-2. generating and displaying at said workstation a preferred provider list from said set of preferred providers to said claim as a function of a set of predefined provider criteria and said claim data; and C-3. assigning, based on client selection at said workstation, at least one preferred adjuster from said preferred adjuster list and at least one preferred provider from said preferred provider list..

36. The method for processing insurance transactions of claim 35, wherein step C further includes: C-4. electronically transferring an amount derived from said claim value from a carrier financial account of said insurance carrier to a preferred provider financial account of said preferred provider.

37. A method of conducting insurance related transactions over the Internet using an insurance transaction system, each transaction being part of a session related to a specific client being serviced by an insurance agent using a workstation, having Internet access, to input client data and otherwise interact with said insurance transaction system, wherein said insurance transaction system includes: i. a framework database system which includes and manages at least one dynamic database for storing session oriented data and at least one static database for storing at least a set of standard procedures, underwriting rules, and insurance carrier rate products; and ii. a core set of engines and servers, wherein said engines accomplish the processing of said insurance transactions using the data in said framework database system and wherein at least one server provides an interface between the Internet and said engines; and wherein said method includes the steps of: A. populating said static databases with said standard procedures, underwriting rules, and rate products for each of a plurality of insurance carriers; B. selectively designating, within said framework database system, at least one insurance agent having access and privileges to said insurance transaction system for processing insurance related transactions; and C. accessing said insurance transaction system with said workstation and via the Internet by said insurance agent, inputting said client data, and selectively processing an insurance related transaction by accessing said core set of engines and servers.

38. The method of conducting insurance related transactions of claim 37, wherein said agent is a franchisee located in a wholesale club.

39. The method of conducting insurance related transactions of claim 37, wherein said insurance related transactions include generating a plurality of candidate policies and corresponding rate quotes for a client as a function of client data input by said agent at said workstation and related to said client and said standard procedures, underwriting rules, and rate products.

40. The method of conducting insurance related transactions of claim 39, wherein said insurance related transaction includes issuing a preferred policy, selected from said plurality of candidate policies, and associating said preferred policy with said client in said framework database management system, and generating a billing schedule associated with said preferred policy.

41. The method of conducting insurance related transactions of claim 40, wherein said insurance related transaction includes accomplishing a payment of at least a portion of a premium associated with said preferred policy, including electronically transferring a payment amount from an account associated with said client to an account associated with a carrier of said preferred policy.

42. The method of conducting insurance related transactions of claim 37, wherein said client data, said plurality of candidate policies, and said rate quotes are session oriented data stored in said dynamic database.

43. The method of conducting insurance related transactions of claim 37, wherein said insurance related transactions include processing an insurance claim by said agent as a function of said input client data and an existing insurance policy issued to said client and providing coverage for said claim, wherein an adjuster for evaluating a monetary claim value associated with resolving said claim is chosen from a preferred adjuster database in said framework database system and a service provider for resolving said claim is chosen from a preferred provider database within said framework database system.