WO2002003595A2

WO2002003595A2 - Process and architecture for xml-based insurance marketplace

Info

Publication number: WO2002003595A2
Application number: PCT/US2001/021534
Authority: WO
Inventors: Adam Pelzman; Russell Dale; William Morein; Jonathan Leslie; Alexander Volnov; Jim Buckridge
Original assignee: Xml Ind Llc
Priority date: 2000-07-05
Filing date: 2001-07-05
Publication date: 2002-01-10
Also published as: AU7326201A

Abstract

There is disclosed a process and an apparatus architecture for electronic data transfer using XML technology to standardize these data for processing. Specifically, there is disclosed a secure, Internet-based, synchronous/asynchronous insurance marketplace that utilizes extensible markup language ("XML") technology. The process provides for "insurance applicants" (such as, agents, brokers, and customers) to access a database of HTML-formatted insurance application forms, input data, and transmit those data to either all insurance providers of the relevant insurance (<i>i.e.</i>, carriers, managing general agents and managing general underwriters) or to only those insurance providers chosen by the insurance applicant.

Description

PROCESS AND ARCHITECTURE OR XML-BASED INSURANCE MARKETPLACE Technical Field of the Invention The present invention provides a process and apparatus for electronic data transfer using XML technology to standardize the data for processing. Specifically, the inventive process and apparatus is a secure, Internet-based, synchronous/asynchronous insurance marketplace that utilizes extensible markup language ("XML") technology. The process provides for "insurance applicants" (such as, agents, brokers and customers) to access a database of HTML-formatted insurance application forms, input data, and transmit those data to either all "insurance providers" of the relevant insurance (i.e., carriers, managing general agents and managing general underwriters) or to only those insurance providers chosen by the insurance applicant.

Background of the Invention

Insurance agents and their carriers have historically used many paper forms for the transmission of data to insurance carriers. These paper forms are transmitted in various ways, including mail, hand carry, and more recently, fax. When an insurance carrier receives a form having data, there are computer programs that will process the information on that form. However, in order for such a computer program to process that data, the information on that form must be entered in an appropriate environment for that computer program. When data are transmitted on a paper or fax medium, entering these data into a computer program requires a person to re-enter the data into a computer. There is also a higher probability for error, because each translation onto a different format or form provides an opportunity for entry error.

Traditionally, computer systems for the insurance quoting market are designed with the idea that people enter data to be processed. Some systems are currently available that can handle direct data streams, however these systems tend to have several issues that make them difficult to use. They tend to be very specific in how the data is to be presented to them. As a result, applications that input data in this fashion must use and match the data stream specifications exactly. This creates further problems when the data are also wanted at another computer system, where its input specifications are different. In short, previous attempts to automate the process of inputting data into a computer system do not have the flexibility to handle variations in the data formats coming in. Presently, most insurance information for specialty lines of insurance are handled by using paper forms and transferring the information by mail or fax. This method is inefficient from a data processing viewpoint. It has no ability to automatically read the data, that is, parse the data. Other attempts to put this information on the Internet have included, for example, taking the paper-based forms, scanning the form, and transferring the form electronically. This method still does not allow for any parsing of the data. XML

In order for insurance information to be communicated in a manner that is understandable by a computer program, a predefined system of communication, or protocol, must be established. To achieve this, the World Wide Web Consortium has defined XML, a protocol that will allow data to be communicated between disjoint systems. XML documents, with their corresponding DTD's, is a method by which computer systems can communicate with each other without the very specific data streams that have been the traditional method of data transfer between computer systems. An XML document carries within it all the information a computer system needs to properly access the data also within the same XML document.

A document type definition (DTD) is a specific definition that follows the rules of the Standard Generalized Markup Language (SGML). DTD is a specification that accompanies a document and identifies the markup that, for example separate paragraphs, identify topic headings, and so forth and how each is to be processed. By mailing a DTD with a document, any location that has a DTD "reader" (or "SGML compiler") will be able to process the document. This means that a single standard SGML compiler can serve many different kinds of documents that use a range of different markup codes and related meanings. The compiler looks at the DTD and then processes the document accordingly.

Summary of the Invention

The present invention provides a process for transmitting insurance information provided in HTML format into an XML file, comprising:

(a) providing an insurance information form in an HTML format from a forms database;

(b) completing information on the HTML form by an insurance applicant;

(c) converting the information obtained in step (b) into an XML format having XML tags on the information as XML-formatted information, and storing the XML- formatted information in a users database; (d) transmitting the quote request to one or a plurality of insurance providers by one or a plurality of transmission means, ; and

(e) providing quotes or other responses from insurance providers. Preferably, the quote request is additionally transmitted to an internal insurance provider backend server located in a middle layer to provide quotes or other responses. Preferably, the quotes and other responses from insurance providers are stored in an answer set database. Preferably, the quotes and other policy terms are obtained from an internal insurance provider backend server. Preferably, the XML-formatted information is created using a DTD (document-type definition) file. Preferably, the completing information on the HTML form by the insurance applicant further comprises parsing the information.

The present invention provides an architecture for transmitting insurance information provided in HTML format into an XML file, comprising:

(a) a "middle layer" web server device comprising a software program for converting HTML forms into XML format, users database, and a forms database, wherein the users database comprises a listing of insurance applicants who have used the process, wherein the forms database comprises forms for insurance quotes in an HTML format;

(b) a transmission means communicating with insurance carriers backend means; and (c) a backend server for retrieving quotes from insurance providers or a database of historical quotations of insurance products communicating with the backend server.

Preferably, the middle layer further comprises an answer set database, wherein the answer set database comprises a database of insurance quotes received and sorted by information received in the fields of the forms database. Preferably, the middle layer further comprises an internal insurance provider backend server for holding insurance quote algorithms and other policy terms. Preferably, the web server device further comprises a private customer database that contains information for filling out forms sorted according to broker or agent. Preferably, the transmission means is via the Internet or another wide area network. Preferably, the backend server further comprises a quotations database containing quotation algorithms from insurance providers to enable the backend server to directly provide quotations.

Brief Description of the Drawing Figure 1 shows an overview of the architecture of the inventive system.

Specifically, Figure 1 shows the process and system components, including databases, for generating insurance quotes from a plurality on insurance carriers. The middle layer web server comprises a CGI program to interconnect with insurance applicants through a browser function, a server program for answer sets interconnected with an answer set database, an internal insurance provider backend server and several databases.

Detailed Description of the Invention

Definitions:

Insurance applicants are, for example, brokers, agents, wholesale brokers and customers who look for insurance quotes.

Managing General Agents (MGAs) are typically the backend suppliers of quotes, policy terms and administrative and other services on behalf of insurance carriers. MGAs work with MGUs (for underwriters).

Managing General Underwriters (MGUs) perform similar functions to MGAs but typically provide additional underwriting services. Insureds are the recipients of insurance services.

Insurance providers are the firms that underwrite insurance policies, including, for example, carriers, managing general agents and managing general underwriters. Customers are entities who require insurance quote services but who utilize agents or brokers to obtain such insurance quotes or insurance products rather than accessing the inventive process directly.

The inventive process provides a secure, Internet-based, synchronous/asynchronous insurance marketplace that utilizes extensible markup language ("XML") technology. The inventive process enables insurance applicants (such as agent, brokers and customers) to access HTML insurance application forms on the forms database, input required data, and transmit those data to either all insurance providers of the relevant insurance (i.e., carriers, managing general agents and managing general underwriters) or to only those insurance providers chosen by the insurance applicant. The data are then translated into XML and stored in such a format. The inventive process, through resident software on the middle level server, then delivers data to the insurance provider in any format that it desires, such as XML, HTML, e-mail, fax, comma separated values (CSV file), and the like.

The insurance provider can utilize the system/data in either a synchronous or asynchronous manner. For example, if the insurance provider chooses the synchronous option, it will interface with the XML output, draw such data directly into its underwriting database, generate an instantaneous quote, and transmit such quote to the insurance applicant transmitted over or generated within the middle ware server by the internal insurance provider backend server, or both. If the insurance provider chooses the asynchronous option, it can accept the data provided in the desired format, enter these data into its underwriting database (either through XML or otherwise), generate a quote, then transmit such quote to the middle ware server for storage in the answer set database.

In summary, the present invention takes information within an HTML form to determine, among other things, the intended audience for that form, the correctness of the information within the form, and the ability for the present invention to add previously entered data into the form automatically. Process

The present invention creates an environment wherein the specific information (i.e., data) either of an applicant or regarding a history of insurance quotes are stored and retrieved in such a fashion so that once information is entered and transmitted to the middle ware server of the inventive architecture, that information can be re-applied without the need for the insurance applicant to re-key the information. Current systems have information initially entered on paper forms and in many instances, re-entered on disjoint systems that do not share information. The potential for error is high and the cost of manipulating these data is high. The present invention, by contrast, uses Extensible Markup Language (XML) in order to allow the data within the form to be processed without data transfer by receiving processes and databases of insurance providers or those acting as agents of insurance providers. By using XML, dissimilar systems can communicate data such that functions previously requiring human intervention will no longer require any such intervention.

All requests are organized into a request-based schema in an answer set database (Figure 1) so that multiple requests for information are sent together because of the storage of historical information on the answer set database. As an example, a customer acting through a broker or agent (insurance applicant) makes a request for insurance for a billiard hall. As the form for billiard hall insurance has its data elements available for electronic processing, all insurance providers handling billiard hall insurance can be notified of the request. The responses to the request come back immediately, i.e., synchronously, or comes back in at a later time, i.e., asynchronously. The insurance applicant in this example will have an organized messaging center where the responses to the request for the billiard hall insurance can be reviewed and isolated from any other requests he or she may have made.

For both the insurance providers and the insurance applicants, a profile specifying notification preferences was also specified at a prior time to the example. The insurance applicants can set it up so that when submissions or responses are made, Email, faxes, etc, can be initiated. The insurance providers will pre-establish the format in which the XML document is received. The XML document can be converted into HTML, spreadsheet document, comma separated values (CSV file), or any other format specified by the insurance provider. As will be evident to a person skilled in the art, extensions can be added so that custom formats can be created from the XML document. System Architecture

The architecture of the present invention is a front end, middle ware layer and back end. At the very front-end, an insurance applicant (i.e., agent, broker or customer) will access an HTML form. The insurance applicant submits the form to the web server in the middle layer (generally via a browser function). The submission activates a CGI program (common gateway interface, or the first software that is available for a client on the middle ware server). If there are problems with the insurance applicant's submission, for example, if fields are missing or alphabetic when they should be numeric, or some such thing, then the insurance applicant is asked to correct the mistakes by the CGI program in the middle ware server. The middle ware server comprises the CGI software and a series of databases. Preferably, the middle ware server further comprises an internal insurance provider backend server. The essential databases are a users database and a forms database. Preferably, the middle ware server further comprises an answer set database to store information received from insurance providers (either through the backend server or through the internal insurance provider backend server), wherein such information includes, for example, quote information and policy terms. The users database comprises a listing of insurance applicants who have used the process. The forms database comprises forms for insurance quotes in an HTML format. The answer set database comprises a database of insurance quotes and other policy terms received sorted by information received in the fields of the forms database. Optionally, the middle ware server further comprises a private customer database that contains information for filling out forms sorted according to broker or agent and customer of that broker or agent. When the insurance applicant submits to the middle ware server a filled-in (completed) HTML form, the CGI program makes a client connection to a backend server. The client connection can be by any means of communication of direct electronic transfer of information, including, for example, LAN (local area network) or WAN (wide area network, such as the Internet) or by a form of a private network. The insurance provider backend server utilizes a process that listens for insurance applicant requests. When the insurance applicant request arrives, the insurance provider backend server spawns an instance of a quote-generating engine (a combination of databases, software programs and engines that accomplish a task), which will interact with the CGI program on the middle ware server. The backend server quote-generating engine accesses quote supplier data from insurance providers or from a private database communicating with the backend server. The backend server (worker program) then makes a quote calculation based on the data it finds from multiple sources, including the information sent to it (the backend server) from the CGI program (middle ware server). The CGI program information originated with the insurance applicant's entries on the HTML form. The completed quote or quotes information is sent to a quote server process that is located in the middle layer. The insurance provider backend server comprises a software program takes it along with similar quotes collected from other quote supplier backend servers, and presents the quotes to the agent.

These data that are read from the insurance applicant are wrapped in XML tags as specified by the DTD's. In XML form, the data are sent to the backend servers of insurance providers (quote supplier's) that have registered to respond to that form (type of insurance product). These data are recovered from the XML document and manipulated to make either the database queries appropriate for the sort of quote needed, or to present a report to the quote supplier personnel responsible for providing quotes to agents. In this latter embodiment, asynchronous messages are routed to a messaging database (preferably located in the middle ware level) and saved for later retrieval by the originating insurance applicant. A message in the form of an email can be dispatched to the originating insurance applicant.

It should be noted that the present invention makes substantial use of databases at the middle layer to pre-populate any HTML forms for the insurance applicants. An insurance applicant of the present invention will logon, preferably in a confidential, private manner such as through a standard encryption format or through secure sockets in an Internet embodiment. While the session is active, any forms the insurance applicant calls up will be pre-populated with his or her specific information. The middle layer CGI program recognizes the insurance applicant from the logon identity. The CGI program uses the logon id as an index into the users database where the CGI program retrieves all the data it can to fill in the fields of the form. The form and the data are merged into a custom HTML form that has as many of the fields as it can pre-populated.

In a preferred embodiment of the present invention, each insurance applicant who is a broker or agent has his or her own customer database in the form of a private customer database. Information about the customer of the insurance applicant who is a broker or agent will also come back to the HTML form in a pre-populated fashion. As an example, the insurance applicant will call up a form "A." Form A is merged with the customer's personal information from the private customer database regarding the customer of a particular agent or broker and from the users database regarding information for the insurance applicant. Preferably, all customers of a particular insurance applicant (who is a broker or agent) are also available in the form of a drop list of previous customers. The insurance applicant can then select a particular customer and re-submit the modified form back to the middle layer CGI program. The CGI program recognizes that a particular customer of an insurance applicant has been picked. The private customer database is then accessed. Just like the users personal information, form "A" is merged with the private customers data into a new custom HTML form that pre-populates as many of the fields as it can. This interaction of the insurance applicant and the middle layer continues until all required information is filled. Whether a field is required or not is pre-determined in the original form creation. The middle layer CGI program also has information from the original form as to whether a field can be used as an index into a database for pre- populating other fields. This is handled by a custom configuration file for each form detailing the how the data for it is to be processed in the present inventions middle layer.

Example 1 This example illustrates a sample transaction. An insurance applicant logs onto a secure host website. Prior to this logon, the insurance applicant has registered himself or herself and has supplied personal information that was stored in a users database. At this present session, the insurance applicant is now presented with a list of available lines of insurance, and a list of previous customers if the insurance applicant is an agent or broker (it should be noted that when an insurance applicant is an agent or broker, then the agent or broker will have customers or insurance applicants of that agent or broker for whom the agent or broker is seeking quotes). From all previous sessions, all customer information that the insurance applicant has entered was stored in a customer database. The insurance applicant will select a line of business (kind of insurance product) and a previous customer, if applicable. The insurance applicant will then request a form, in the embodiment of an HTML document, for that line of insurance product. The CGI program will access the users database and private customer database (in case the insurance applicant is an agent or broker) and match all fields that have relevant data. These matched data will pre-populate the HTML form with such data. As an example, the insurance applicant's address and phone number will be posted in the HTML form's input fields corresponding to that information. If a customer was selected, items such as phone number, address, social security id, etc, will also be pre-populated into the HTML form from the private customer database. This HTML form will then be returned to the insurance applicant.

The insurance applicant will then fill out the remainder of the HTML form and submit the completed form to the CGI program via a browser to the middle layer web server. When the CGI program receives the HTML form, it will access the forms database and check all the input fields for proper type formation. Some of the fields of the form are required, and some are optional. Such information is stored in the forms database. If the HTML form is missing required information, the HTML form is returned to the insurance applicant with hi-lights at the empty required fields. The insurance applicant will fill in the missing fields and re-submit the form.

When the CGI program has determined that all required fields are entered, it will take several steps in processing the HTML form. For example, if the customer information is new, a new customer profile will be created for that customer with respect for that particular broker. All the input fields will be checked against the forms database. The appropriate XML tag for that field will be obtained. The CGI program will then create an XML document using the forms database known fields and the supplied data. The CGI program will then submit the XML document to the audience of quote suppliers for that line of business products via the backend server. All submissions are recorded in a submission's database communicating with the backend server. The insurance providers will then respond to the specific submission with quote information. The responses have as references the corresponding submissions. At any time the insurance applicant can then call up the submissions list and see who was contacted and what their responses were. The insurance providers also have a similar interface where they can see who has made submissions to them, and what responses were made.

Claims

We claim:

1. A process for transmitting insurance information provided in HTML format into an XML file, comprising:

(b) completing information on the HTML form by an insurance applicant;

(c) converting the information obtained in step (b) into an XML format having XML tags on the information as XML-formatted information, and storing the XML- formatted information in a users database; (d) transmitting the quote request to one or a plurality of insurance providers by one or a plurality of transmission means; and

(e) providing quotes or other responses from insurance providers.

2. The process of claim 1 wherein the quote request is transmitted to an internal insurance provider backend server located in a middle layer to provide quotes or other responses to the insurance applicant.

3. The process of claim 1 wherein the quotes and other responses from insurance providers or from the internal insurance provider backend server are stored in an answer set database for later retrieval by the insurance applicant.

4. The process of claim 1 wherein the XML-formatted information is created using a DTD (document-type definition) file.

5. The process of claim 1 wherein the completing information on the HTML form by the insurance applicant further comprises parsing the information.

6. A architecture for transmitting insurance information provided in HTML format into an XML file, comprising: (a) a "middle layer" web server device comprising a software program for converting HTML forms into XML format, users database and a forms database, wherein the users database comprises a listing of insurance applicants who have used the process, and wherein the forms database comprises forms for insurance quotes in an HTML format;

(b) a transmission means communicating with insurance carriers backend means; and

(c) a backend server for retrieving quotes from insurance providers or a database of historical quotations of insurance products communicating with the backend server.

7. The architecture of claim 6 wherein the middle layer further comprises an answer set database, wherein the answer set database comprises a database of insurance quotes and policy terms received sorted by information received in the fields of the forms database.

8. The architecture of claim 6 wherein the middle layer further comprises an internal insurance provider backend server for holding insurance quote algorithms and other policy terms.

9. The architecture of claim 6 wherein the web server device further comprises a private customer database that contains information for pre-populating forms sorted according to broker or agent.

10. The architecture of claim 6 wherein the transmission means is via the Internet or another wide area network.

11. The architecture of claim 6 wherein the backend server further comprises a quotations database containing quotation algorithms from insurance providers to enable the backend server to directly provide quotations.