Abstract:
This invention relates generally to a computer system and method for integrating insurance policy underwriting. In one aspect it integrates the older legacy insurance policy generating systems to on line systems where users access the system through browsers. The computer system to perform the process of underwriting, rating, quoting, binding, and booking an insurance policy includes browsers, data bases, processors and a dispatcher that parses the information to select an insurance process. Suitable software programs review messages received from users to determine if certain messages are less than a prescribed limit. If a message is greater than the limit, then the message is parsed into a header information and one or more data fields whereby the header information is provided to a legacy processor and to policy generation software for further creation of policy related information and documentation.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation application of co-pending U.S. patent application Ser. No. 11/025,548 entitled METHOD AND SYSTEM FOR COMPUTERIZED INSURANCE UNDERWRITING, filed Dec. 28, 2004, which application claims priority to and benefit of U.S. Provisional Patent Application No. 60/533,753 filed Dec. 30, 2003, the entire contents of all of which are herein incorporated by reference for all purposes 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     This invention relates generally to computer-based insurance processing and more specifically to integrating a legacy insurance policy underwriting process to a real-time on-line process. 
     2. Description of the Related Art 
     With regard to the insurance industry, records regarding issued policies, premiums, payments and payouts must be maintained for extended periods of time. The insurance industry readily embraced computer and computer technology for the storage of their records and files and developed special purpose software systems that are suitable for the maintenance and storage of the insurance files. 
     As computer technology and computer software changes, the insurance industry is pressed to update and upgrade their equipment and facilities. For example, the current computerized process for underwriting an insurance policy is a textual-based system that is burdensome and not user-friendly. The process requires that the underwriting agent prepare forms using manual tabulation of data and, in cases, requires specialized knowledge with regard to translating human-readable information into computer-readable codes. This is time-consuming and labor-intensive. However, there is hesitation to upgrade current existing software, i.e., legacy processor and associated software, as there is a significant cost in time, labor and expense in transitioning existing legacy-software-based files to newer software. 
     Hence, there is a need for a method and system that is not time-consuming, burdensome and labor-intensive that affords an underwriting agent the ability to process the factors that underwrite an insurance policy while providing proper interface with existing legacy-based files. 
     SUMMARY OF THE INVENTION 
     This invention relates generally to computer-based insurance processing and more specifically to integrating the insurance policy underwriting processes. In one aspect of the invention a computer system to perform the process of underwriting, rating, quoting, binding, and booking an insurance policy comprises one or more browsers operative to communicate associated information to a dispatcher that parses the information to select an insurance process and an output device to produce the insurance product. A server having suitable software reviews the message received from a browser and determines whether the message length is greater than a predetermined limit, and if the message is less than the limit, then input data is provided to a first input queue and input to a dispatcher means for subsequent processing. The system further includes the feature whereby if the message is greater than the predetermined limit, then the message is parsed into a header information and one or more data fields information and the header information is provided to first input queue and the data information is provided to a second input queue and the dispatcher means and the data information is provided to a legacy processor and associated software system. In one aspect of the invention, the information in the data field is parsed into multiple records of a predetermined size, preferably 16 kilobytes. Following completion of the processing the results are provided to a user-assigned data queue and subsequently to the server. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The invention is best understood from the following detailed description when read in connection with the accompanying drawings. The various features of the drawings are not specified exhaustively. On the contrary, the various features may be arbitrarily expanded or reduced for clarity. Included in the drawing are the following figures: 
       Other aspects, advantages and novel features of the invention will become more apparent from the following detailed description of the invention when considered in conjunction with the accompanying drawings wherein: 
         FIG. 1  is a block diagram of a process flow of an underwriting system in accordance with the principles of the invention; 
         FIG. 2  is a second block diagram of an exemplary process flow of an underwriting system in accordance with the principles of the present invention; 
         FIG. 3  illustrates a block diagram of the structure of the underwriting system shown in  FIG. 1  and  FIG. 2 ; 
         FIG. 4  illustrates a state diagram of the exemplary structure shown in  FIG. 3 ; 
         FIG. 5  illustrates a block diagram of a second aspect of the system shown in  FIG. 1  and  FIG. 2 ; 
         FIG. 6  illustrates a block diagram of another aspect of the system shown in  FIG. 1  and  FIG. 2 ; 
         FIG. 7  illustrates an exemplary format for exchanging information in accordance with the principles of the invention; 
         FIG. 8  illustrates a state diagram of an exemplary processing in accordance with the principles of the invention; 
         FIG. 9  illustrates a flow chart of an exemplary process associated with the operation and communication with e-file database in accordance with the principles of the invention; 
         FIG. 10  illustrates an exemplary process associated with parsing of an Inquiry command in accordance with the principles of the invention; 
         FIG. 11  illustrates an exemplary process for establishing account information in accordance with the principles of the invention; and 
         FIG. 12  illustrates an exemplary graphic interface in accordance with the principles of the invention. 
     
    
    
     It is to be understood that these drawings are solely for purposes of illustrating the concepts of the invention and are not intended as a definition of the limits of the invention. The embodiments shown in the figures herein and described in the accompanying detailed description are to be used as illustrative embodiments and should not be construed as the only manner of practicing the invention. Also, the same reference numerals, possibly supplemented with reference characters where appropriate, have been used to identify similar elements. 
     DETAILED DESCRIPTION OF THE INVENTION 
     In the figures to be discussed, the circuits and associated blocks and arrows represent functions of the process according to the present invention, which may be implemented as electrical circuits and associated wires or data busses, which transport electrical signals. Alternatively, one or more associated arrows may represent communication (e.g., data flow) between software routines, particularly when the present method or apparatus of the present invention is a digital process. 
       FIG. 1  illustrates a block diagram of a system  100  for an integrated method of insurance underwriting in accordance with the principles of the invention. In this system, one or more users  105  employ a browser apparatus  110  having browser software  113  that operates in association with a web/application server  120  via processor  112  and network  115 . Network  115 , as would be recognized by those skilled in the art, may be a local area network (LAN), wide area network (WAN), or a public network, such as the INTERNET or conventional telephone network that may include hardware interfaces and input and output devices as by way of example: facsimile machines, document scanners, printers, copiers and handheld communication devices that receive and send information from and to the processes of the present invention and produce insurance policies, insurance statements and bills. Web/app server  120  is also in communication with a system  130  containing data queues  132 , intermediary data queues  240  to retain processing results, an output data queue  134  to retain the output from a legacy system, input from a table lookup data base  510  (to be further described in  FIG. 5 ) and a dispatcher module  136  which parses information received from the browser to determine which insurance process to call to service the browser request. Although not shown, it would be appreciated that web/app server  120  may be in communication with system  130  via a network similar to or different from that of network  115 . 
     System  130  is further in communication with system  140  comprised of legacy process and associated software module  142  that is suitable for communicating with a legacy database  144  for the storage and/or retrieval of desired data or information items. One skilled in the art would appreciate that system  140  may be external to system  130  and, thus, system  130  and legacy system software  142  may be in communication via a network similar to or different from that of network  115 . 
     Database system  150 , comprised of a database referred to herein as “e-file” database  152  and server  154  is further in communication with network  115 . Those skilled in the art of programming will appreciate that the database system  150  may optionally connect directly to the server  112  as described in  FIG. 2 ; the connection being a design choice. The operation of the database  150  is more fully disclosed in  FIG. 9  although in general it contains quote letters, binding letters, or issue letters that may be preformed using the available features of the word processing program and desired information associated with each insurance account. 
       FIG. 2  illustrates a block diagram of the system  130 . As noted with regard to  FIG. 1 , web/app server  120  provides information based upon input received from one or more users  105   1  through  105   n  employing one or more browsers  110   1  through  110   n  operating in association with processor  112  though the network  115  to an input data queue  132 . The information stored in data queue  132  is then provided to the dispatcher  136 , which parses the information to determine which specific insurance process  210 A 1  through  210 A n  is associated with the information. In one embodiment, each process is related to one or more different insurance products  210 B 1  through  210 B n  that may be available to the public (life, property and casualty) or custom designed products for doctors, lawyers or other professions or organizations requiring a particular kind of insurance. 
     Processing results  210 A 1  through  210 A n  are stored in one of a plurality of intermediary data queues  240   1 - 240   n . Each product  210 B 1  through  210 B n  stores the results of its processing in an associated data interim database  210 C 1  through  210 C n  respectively. Intermediary data queues  240   1  through  240   n  retain processing results based on a user  105   1  through user  105   n  identification. Web/app server  120 , in receiving product processing  210 A 1  through  210 A n  results from the intermediary data queues  240   1  through  240   n  transmits the results to the appropriate browser  110   1  through  110   n . Although intermediary data queues  240   1  through  240   n  are shown to be physically disjointed, it would be recognized by those skilled in the art of computer programming that intermediary data queues  240   1  through  240   n  may represent logical devices on one or more physical devices. 
     In response to a “submit” message from a user at a browser  110 , the dispatcher  136  directs the associated process to transfer to the legacy processor and associated software  142 , which then stores the results in database  144 . 
       FIG. 3  illustrates an organizational structure  300  of dispatcher  136  in responding to input data or information items received from the browsers  110   1  through  110   n  for each product. In this organization structure, inputs are received by main menu  310 , which by way of example then determines whether the input data requires that inquiry processing  320 , new account processing  330  or modify existing account processing  370  be performed. 
     When the main menu  310  determines inquiry processing  320  is to be performed, the content of the inquiry command is then reviewed to determine whether the inquiry requires information as by way of example and not limitation with regard to a policy  322 , a claim  324 , billing  326  or reinsurance  328 . Inquiry processing is more fully disclosed with regard to  FIG. 10 . 
     When the main menu block  310  determines new account processing  330  is to be performed, a determination is made at block  332  whether all the account information has been cleared. When all the account information is cleared, the account information is established at block  334 . Establishment of account information is more fully disclosed with regard to  FIG. 11 . 
     After the account information is established, one of a plurality of processes, i.e., account summary,  336 , underwriting worksheet  340 , rating  344 , create quote  348 , create binder  352 , book and bill  356 , and issue policy  360 , associated with the input information item is executed. Account summary processing  336  includes the steps of adding or changing general detail information such as new or renewal, primary or excess, effective date, contact information and product selection. Underwriting worksheet  340  includes the steps of adding additional information based on the product selected. The information is product specific. Rating process  344  includes the steps of defining debits or credits and calculating premium options using either a legacy rating engine or a spreadsheet means. Create quote process  348  includes the steps of creating a letter, conventionally referred to as a quote letter, using a word processing program with an option to select various premiums calculated from rating process  344 . The create binder process  352  includes the steps of creating a letter, conventionally referred to as a binder letter, using a word processing program with an option to select a premium option calculated from rating process  344 . Book and bill process  356  includes the steps of selecting industry code, ISO class as well as payment plan and billing method before finalizing or booking the account. Issue policy process  360  includes the steps of printing and issuing an insurance policy. Optionally, a printer and output type, such as draft or production, may be selected. 
     In one aspect of the invention, each of the processes is executed in sequence, wherein a subsequent process is not allowed to be performed until a preceding process has completed it operation. Thus, after the account summary process  336  is executed, a determination is made at block  338  whether an update of the account summary has occurred. If the answer is negative, then processing is returned to the account summary process for further processing. However, if the answer is in the affirmative, then tab  337  enables processing to continue to underwriting worksheet  340  processing. Similarly, rating  344  processing is executed until a determination at block  346  indicates that the preceding process, in this case rating  344 , has been executed or performed.  FIG. 3  illustrates that each of the processes  336 ,  340 ,  344 ,  348 ,  352 ,  356  and  360  have corresponding tests  338 ,  342 ,  346 ,  348 ,  354 ,  358  and  362 . In each instance a corresponding tab  337 ,  339 ,  341 ,  343 ,  345  and  347  enable the subsequent process to operate if the determination is in the affirmative. 
     The ability to determine the execution of preceding processes is advantageous as it allows the user to update, amend or modify input data or prior process results without requiring the sequential execution of preceding processes. In this manner, an underwriting process may be partitioned into one or more sessions that enables the user to “tailor”, customize or modify a desired package to meet the insured party&#39;s needs. 
     Modify existing account process  370  operates on existing accounts and operates similar to new account process  330  in executing one or more of the illustrated processes. However, as the nomenclature suggests, modification, amendment and changes to existing policies are achieved. 
     Also illustrated is a forms data base  353 , which includes a plurality of standardized forms used in the insurance underwriting process. The use of standardized forms is advantageous as it provides the user known, pre-approved forms and letters. Furthermore, the contents of the forms can be dynamically filled by information provided by each of the processes included in the underwriting process. Forms database  353  is accessible from create quote process  348 , create binder process  352 , book and bill process  356  and issue policy process  360 . These processes may further enable the forms to be contained in a centralized process for storage and archiving. 
     In one aspect of the invention  FIG. 4  illustrates an exemplary state diagram of the process shown in  FIG. 3 . In this exemplary process diagram, each of the processes  336  through  360  is represented as a state that when successfully completed allows processing to continue at a next state. For example, when rating state  344  is completed, processing continues at process create quote  348 . Otherwise, processing remains in the rating state  344 . In one aspect of the invention, a state variable or variables may include indications about which states have been executed. Hence, a process state may not be executed until the preceding states have been indicated to have been executed. In another aspect, when a state is entered, all indication of subsequent state processes are set to a “not executed” state. 
       FIG. 5  illustrates a block diagram of another aspect of the system shown in  FIG. 1  and  FIG. 2 . In this aspect of the invention, browser  110  software  113  controls a communication with the e-file system  150  and processor  112  directly or via network  115  (not shown). Web server  120  reviews the message received from browser software  113  and determines at decision block  500  whether the message length is greater than a predetermined length. In one aspect of the invention, the predetermined limit is set to 32 kilobytes. If the determination is that the message length is not greater than a predetermined limit, then the input data is provided to an input queue  502 . The information may then be provided to the dispatcher  136  for subsequent process as described in  FIG. 1  and  FIG. 2 . 
     However, if the message is greater than the predetermined limit, then the information is parsed into a header and data fields. In this case, the header information is provided to first input queue  502  and the data information is provided to an input queue  503 . In this case, the header is provided to the dispatcher  136  and the data information is provided to one of the products process  210  or the legacy system  140  having the legacy process  142  and an associated database  144 . In one aspect the information in the data field is parsed into multiple records of a predetermined size. In one embodiment, the record size is 16 kilobytes. Upon process completion the results are provided to the user assigned data queue  506  and subsequently to the web server  120 . 
     A table lookup data base  510  may include information that may be used in a browser  110   n  through  110   n  “drop-down” menus associated with a specific field in a specific process interface. For example, the address field table lookup data base  510  may include the names of the fifty states of the United States which may be displayed in a “drop-down” menu. A user may then select one of the predefined entries from the “drop-down” menu. Table lookup data base  510  may also include, for example, product codes or underwriter codes by way of example. 
       FIG. 6  illustrates a block diagram of another aspect of the system shown in  FIG. 1  and  FIG. 2 . In this aspect of the system, browser software  113  is shown comprising processes account summary  336 ′, underwriting worksheet  340 ′, rating  344 ′ create quote  348 ′, create binder  352 ′, book and bill  356 ′, and issue  360 ′, which correspond to dispatcher  136  processes  336  through  360 , respectively. Each process  336 ′- 360 ′ is operable to assess e-file data base  150  and Popup page  610 . Popup page  610  is operable to display information associated with table lookup data base  510 . In this aspect of the invention, the centralized table lookup data base  510  allows additions to the information in the table lookup data without altering any browser  110   1  through  110   n . 
     The network  115  transmits and receives data from the browser processes  336 ′ through  360 ′ to the input data queues  132  and the input data queue  503  which operation in conjunction with dispatcher  136  previously has been described. The information stored in data queue  132  is then provided to the dispatcher  136 , which parses the information to determine which specific process  210  such as shown in  FIG. 1  processes  210 A 1  through  210 A n  is associated with the information. Input data queue  503  also communicates with the legacy process  140  to update information in the data base  144 . 
       FIG. 7  illustrates an exemplary format  700  for exchanging information in accordance with the principles of the present invention. In this exemplary format, thirty (30) data bytes are allocated for data transfer. In one aspect, data bytes are composed of 8 data bits. However, it would be recognized that the number of data bytes or the size of the data bytes may be altered without altering the scope of the invention and is thus considered to be within the scope of the invention. 
     In this case, eight (8) bytes  710  are allocated for the identification of a desired process or operation, seven (7) bytes  715  are allocated as a user identification, that may also be used as an identifier on the respective data queues. Five (5) bytes  720  are allocated for a state identification, seven (7) bytes  725  are allocated for a state function identification, nine (9) bytes  730  are held as reserved, ten (10) bytes  735  are allocated for a state switch indication, five (5) bytes  740  are allocated to provide an indication to allow a next state, and two (2) bytes  745  are allocated to indicate the status of a request. 
     Process identification bytes  710  may be associated with the type of environment dispatcher  136  is operating within. For example, dispatcher  136  may operate in a production environment, a test environment or a shut down environment. As one skilled in the art would recognize, in a test environment dispatcher  136  would include executable features that may not be included in a production environment. 
     User identification bytes  715  may be statically or dynamically assigned to a user to uniquely identify users. In one aspect, the user identification  715  may be  105   1  through  105   n  the user name or initials. The User identification may also include a password that limits access to authorized users. State identifier  720  provides an identification of a current state. With reference to  FIG. 3 , the state identifier  720  may be associated with and identified as account summary, underwriting worksheet, rate, create quote, create binder and issue. Function identifier code  725  provides an identification regarding a next operation to be executed. In one aspect, function identifier code  725  may represent a state such as “update and remain at current state” or “update and advance to next state.” In the former case, data bases may be updated, but the processing remains at a current state, while in the latter case, data bases may be updated and processing is allowed to proceed to the next state. State switch indication  735  provides direction with regard to a switch in the state process flow of dispatcher  136 . Switch indication  735  may be used by browser  110  to enable a user to enter information suitable for a next state. Next state indicator  740  may be used by any browser  110   1  through  110   n  to enable a user to progress or proceed to a next state. Request state  745  may be used by any browser  110   1  through  110   n  to indicate when a requested update has been completed successfully. 
     A method of the present invention underwrites, rates, quotes, binds, books and bills and issues insurance policies comprising the steps of maintaining the browser  110  to communicate information to the dispatcher system  130 , and parsing information in the dispatcher  136  to communicate with one or more insurance generating processes  210 .  FIG. 8  illustrates a state diagram depicting an exemplary interaction  800  between the browser  110   1  through  110   n  and the dispatcher  136  over the network  115  in accordance with the principles of the invention. In this illustration, dispatcher states  336  through  360  are in communication with a main menu state  310 , as discussed with regard to  FIG. 3  and  FIG. 4 . Browsers  110   1  through  110   n  include states  336 ′ through  360 ′ corresponding to states  336  through  360  in the dispatcher  136 . Process states  336 ′ through  360 ′ allow a user to enter information items, using a Graphic User Interface (GUI) that may be processed by dispatcher  136 . In this illustrated embodiment, process states  336 ′ through  356 ′ are operable to remain in a current state, proceed to a subsequent state or to a preceding state. In the illustrated embodiment, a user thus may restart all or part of the underwriting process to customize the package to meet an insured party&#39;s needs. 
     Using a GUI corresponding to a specific state, a user may manually enter the state, for example  336 ′, which is then registered as a current state. The current state may then be transferred to the dispatcher  136  through the transfer format  700  shown in  FIG. 7  and the corresponding process may then be executed. Upon completion of the current state processing, an indication of successful update is returned to the associated browser  110   1  through  110   n  which allows a user to enter next subsequent state, in this case state  340 ′, and enter information items using a GUI associated with this new current state. The information items obtained in this new current state  340 ′ may then be transferred to the dispatcher  136  through transfer format  700  shown in  FIG. 7  and the corresponding process may then be executed. Upon completion of the current state processing, an indication of successful completion or update is returned to the associated browser  110   1  through  110   n  which allows a user to enter next subsequent state. This procedure may be repeated until each of the process states has been successfully completed. 
     However, the user may manually return to a preceding state to update the information contained therein and execute the associated processing in the dispatcher  136 . This ability to repeat certain preceding processes is advantageous as it allows for alternative formulations of the underwriting process without requiring input of all prior data. 
     Communication with legacy processor and associated software  142  may be performed using known software tools. For example, in one aspect, use of IBM AS/ 400  software Toolkit provides necessary plug-ins and protocols to communicate with legacy database  144  and need not be discussed in detail herein. IBM is a registered Trademark of the International Business Machine Corporation, Armonk, N.Y. 
       FIG. 9  illustrates a flow chart  900  of an exemplary processing associated with the operation and communication with e-file database  150 . As illustrated, this exemplary process may be accessed by process steps  336 ,  340 ,  344 ,  352 ,  356  and  360  shown in  FIG. 3 , represented by block  910 . At block  920  access to an available suite of programs for word processor or spreadsheet operation is enabled. In one aspect, access to word processing software MS-WORD  925  and spreadsheet software MS-EXCEL  930  is available. MS-WORD and MS-EXCEL are registered trademarks of the Microsoft Corporation, Redmond, Wash. Although the present invention is disclosed with regard to MS-WORD and MS-EXCEL, it would be recognized by those skilled in the art that other word processing or spreadsheet programs may also be used and, thus, are considered to be within the scope of the invention. 
     Templates, created or available, within the word processing program may then be accessed and information items from an associated account may then be stored in predetermined fields within a selected template. For example, quote letters, binding letters, or issue letters may be preformed using the available features of the word processing program and desired information associated with each account may be extracted from the collected data and stored in predetermined fields within the selected template. 
     At block  926  a determination is made whether to exit the selected word processing program. When exiting the program, the program is closed at block  927  and processing proceeds to block  940  to update an e-file  150  program. The updated information is then stored in the e-file data base  150  ( FIG. 1 ). 
     Similarly, when the spreadsheet program, in this case MS-EXCEL, is selected at block  930 , templates available at block  930  are accessed and information from an associated account is stored in predetermined fields within a selected template. At block  931 , a determination is made whether to exit the selected program and the program closed at block  932 . A determination is then made at block  935  whether the information is to be returned to a browser  110   1  through  110   n  ( FIG. 1 ). If the answer is in the affirmative, the program is closed at block  936  and the information is returned via block  910 . 
     However, if the answer is in the negative, then the program is closed at block  936  and processing proceeds to block  940  to update the e-file  150  program. The updated information is stored in e-file data base  150  ( FIG. 1 ). 
     In another aspect, the e-file data base  152  may be searched, at block  950 , for designated or selected account information. In this case, information regarding account information, such as insured name, is made available at block  955 . At block  960 , the e-file database  152  is accessed and searched for the designated or selected account. At block  965 , the information is returned to the search requester, i.e., the associated browser  110   1  through  110   n . 
     In another aspect, documents related to a particular account, e.g., the currently opened account associated with the specific user, may be accessed at block  970 . In this case, a search for documents associated with a currently opened account is initiated at block  975 . At block  980  a search program is executed that accesses e-file database  152 . The results of the search may then be provided to search requester at block  965 . 
       FIG. 10  illustrates an exemplary process  1000  associated with parsing of an inquiry command chosen from a main menu  1005  in accordance with the principles of the invention. In this illustrated process, information associated with a desired account, e.g., user name or policy number, is provided at block  1010 . At block  1020 , a search program is executed to extract account information associated with the provided input data. At block  1030 , a determination is made whether more than one entry has matched the provided input information. If the answer is in the affirmative then the matching entries are provided to a user at block  1040 . At block  1050 , a user may select an account from the matching entries. The selected account is then provided to the policy detail module  1060 , the claims detail module  1065 , reinsurance detail module  1070  or billing module  1075 . Policy detail module  1060  may include information regarding the policy limits or terms associated with the selected account. Claims detail module  1065  may include information regarding claims written or processed against the selected account. Reinsurance module  1070  may include information regarding whether reinsurance is associated with the selected account. Billing module  1075  may include information regarding invoices and payments associated with the selected account. 
     However, if only one entry is found to match the provided input information, then that entry is provided to the policy detail module  1060 , the claims detail module  1065 , reinsurance detail module  1070  or billing module  1075 . 
       FIG. 11  illustrates an exemplary process  1100  for establishing account information. In the illustrated process, a user  105  such as earlier described in connection with  FIG. 1  is presented with a main menu  1105  and enters information, such as a name of an insured party or other identifying characteristic, at block  1110 . For example, a user may enter one or more characters that represent parts or all of a name or identifying characteristic. At block  1120  a search of the legacy data base  144  ( FIG. 1 ) is executed to determine entries, i.e., user accounts, that substantially match the user entered information. At block  1130  a list of matching entries that substantially match the user entered information is provided to the user. At block  1140 , a determination is made whether the user entered information matches an entry on the list of matching entries or whether a new account must be created. If a matching entry is found, then the information in the entry or account is made available to one or more of the processes shown in  FIG. 3 , as represented by block  1160 . 
     However, if a matching entry is not found, a new account may be created at block  1150 , wherein additional information such as address, contact information, new account or account renewal, producer, product, or underwriter may be entered. In addition, notes or comments may be added to the account information. The information in the new entry or account is then made available to one or more of the processes shown in  FIG. 3 , as represented by block  1160 . 
       FIG. 12  illustrates an exemplary GUI  1200  for processing account information in accordance with the principles of the invention. In this illustrated interface, a user may select a process such as account summary  1210 , underwriting worksheet  1215 , rating summary  1220 , create quote  1225 , create binder  1230 , book and bill  1235  or issue policy  1240 . As previously described, processes are selected in a sequential order but previously executed processes may be re-selected to update information within the selected process. 
       FIG. 12  depicts the GUI associated with account summary process  1210 , i.e. process  336 . In this interface, information regarding the insured party, such as name, address and city/state may be entered at blocks  1252 ,  1253 ,  1254  respectively. Also information contact or beneficiary information may be provided at block  1255 . 
     At block  1262 , information regarding a producer or agent may be entered and at block  1272  information regarding the type of insurance, e.g., D&amp;O, malpractice, etc., may be entered. At blocks  1282 , comments regarding the policy or the account may be entered and at block  1284  the underwriter may be identified. At block  1286  a date of a next action and type of action may be entered or determined. For example, the date of the next premium payment may be determined based on the payment terms. 
     At block  1287 , an “update” operation allows the user to update the information entered and at block  1288 , a “submit” operation allows the user to memorialize the entered information. The “submit” procedure further indicates that a step has been completed, thus enabling entry into a next process. A “reset” operation, at block  1290 , clears the information on the currently displayed GUI. 
     Furthermore, each of the processes is accessible on each of the available process GUIs by maintaining indications  1210  through  1240  associated with the processes  336  through  360 , respectively. In this manner, a user may switch between process indications to review or change data in other processes. 
     In an embodiment, a computer system for underwriting, rating, quoting, binding, and booking an insurance policy includes one or more browsers operative to communicate associated information to a dispatcher that parses the information to select an insurance process and an output device to produce an insurance product. The dispatcher may communicate with a legacy system and produce data to an output data queue to retain the output received from a legacy system. One or more browsers may communicate information to the dispatcher, which parses the information to determine the specific insurance process associated with the information. One or more data queues may communicate one or more results of a specific process to the browser. Dispatcher inputs may be received from a main menu, which determines whether the input data requires processing selected from a group including: an inquiry processing, a new account processing or a modify existing account processing. One or more browsers may communicate with an e-file. A server analyzes a message from one or more browsers and determines whether the message length is greater than a predetermined length. 
     In an embodiment, the computer system may further include a server to review a message received from the browser and a means to determine whether the message length is greater than a predetermined limit; and if the message is less than the limit then input data is provided to a first input queue and used as input to a means for producing the insurance product. In an embodiment, if the message is greater than the predetermined limit, then the message is parsed into a header information and one or more data fields information and the header information is provided to first input queue and the data fields information is provided to a second input queue and the dispatcher means and the data fields information is provided to a legacy processor and associated software system. The information in the data field may be parsed into multiple records of a predetermined size. The message size may be equal to or greater than 16 kilobytes. The subsequent processing completion results may be provided to a user assigned data queue and subsequently to the server. 
     In an embodiment, the computer system includes a table lookup data queue for underwriting, rating, quoting, binding, booking and billing and issuing insurance policies including : a drop-down menu in a browser associated with a field selected from a group including: the identification of a desired process or operation, data bytes for user identification, data bytes for a state identification, data bytes for state function identification, data bytes for a state switch indication, data bytes for providing an indication to allow a next state, data bytes for indicating the status of a request. 
     In an embodiment, a computer readable medium for underwriting, rating, quoting, binding, booking and billing and issuing insurance policies has stored thereon one or more data structure to transfer control selected from a group comprising: a plurality of data for the identification of a desired process or operation, data for user identification, data for a state identification, data for state function identification, data for a state switch indication, data for providing an indication to allow a next state, data for indicating the status of a request. 
     In an embodiment, a computer-based insurance processing system includes a browser having executable browser software to process account summaries, underwriting worksheets, ratings, quotes, binders, and bills and issue insurance policies, which correspond to associated dispatcher means for producing an insurance product and an output device to print insurance products. In the computer-based insurance processing system, each process may be operable to access one or more e-file databases and to display one or more pop up pages on the browser. The one or more pop up pages may be operable to display information on the browser associated with a table lookup data queue for underwriting, rating, quoting, binding, booking and billing and issuing insurance policies. The table lookup data queue may allow additions to the information in the table lookup data without altering the browser. 
     The computer-based insurance processing system may further include one or more state switches and associated state indicators to provide process direction to a state flow process of a dispatcher in association with a browser and a means for producing an insurance product and an output device to print the insurance product. The switch indication may be used by the browser to enable a user to enter information through the browser suitable for a next state, wherein the next state produces an associated indication. The next state indicator may be used by the browser to enable a user through the browser to proceed to a subsequent state. The browser may use a request state to indicate when a requested update has been completed. The computer-based insurance processing system may further include: a main menu state. The browser state may correspond to the dispatcher state. The browser state may allow a user to enter information using a Graphic User Interface (GUI) to be processed by the dispatcher. The browser state may be operable to remain in a current state, to proceed to a subsequent state or to a preceding state. The GUI corresponding to a specific state may allow a user to manually enter the state, which is then registered as a current state. The current state may be then transferred to the dispatcher through a transfer control format initiating execution of a corresponding process. Upon a completion of the current state processing, an indication of a successful update may be returned to the associated browser, which allows a user to enter subsequent state. In an embodiment, a user may enter information using a GUI associated with this new current state. 
     In an embodiment, a computer method to underwrite, rate, quote, bind, book and bill and issue insurance policies includes the steps of maintaining a browser to communicate information to a dispatcher, and parsing information in the dispatcher to communicate with one or more insurance generating processes and printing one or more insurance products resulting from the processes. The method may include the additional step wherein the dispatcher communicates with a legacy system and produces output to a data queue. The method may include the additional step of maintaining one or more browsers to communicate information to a dispatcher, which parses the information to determine the specific insurance process associated with the information. The method may include the additional step of transmitting from one or more data queues the results of a specific process associated with the information to the appropriate browser. The method may include the additional step of inputting information by the dispatcher and receiving said input by a main menu which determines whether the input data requires processing from a group including: an inquiry processing, a new account processing or a modify existing account processing. The method may include the additional step of maintaining one or more browsers to communicate with an e-file system. 
     The method may include the additional step of reviewing the message received from one or more browsers to determine whether the message length is greater than a predetermined length. The method may include the additional step of: reviewing a message received from the browser and determining whether the message length is greater than a predetermined limit, and if the message is less than the limit then inputting data to the dispatcher for subsequent selection of an insurance process and printing an insurance product based upon the insurance process. The method may include the additional step wherein if the message is greater than the predetermined limit, then the message is parsed into a header information and one or more data fields information and the header information is provided to first input queue and the data information is provided to a second input queue and the dispatcher means and the data information is provided to a legacy processor and associated software system. The method may include the additional step wherein the information in the data field is parsed into multiple records of a predetermined size. The method may include the additional step of maintaining the message size to 16 kilobytes. 
     While there has been shown, described, and pointed out fundamental novel features of the present invention as applied to preferred embodiments thereof, it will be understood that various omissions and substitutions and changes in the apparatus described, in the form and details of the devices disclosed, and in their operation, may be made by those skilled in the art without departing from the spirit of the present invention. It is expressly intended that all combinations of those elements that perform substantially the same function in substantially the same way to achieve the same results are within the scope of the invention. Substitutions of elements from one described embodiment to another are also fully intended and contemplated. It will be understood that various omissions and substitutions and changes in the routines and algorithms described, in the form and details of the methodologies disclosed, and in their operation, may be made by those skilled in the art without departing from the spirit of the present invention. It is expressly intended that all combinations of those elements that perform substantially the same function in substantially the same way to achieve the same results are within the scope of the invention. Substitutions of elements from one described embodiment to another are also contemplated and should be considered embodied in the present invention.