US20090089101A1 - Techniques for underwriting insurance policies using web-centric insurance management system - Google Patents

Techniques for underwriting insurance policies using web-centric insurance management system Download PDF

Info

Publication number
US20090089101A1
US20090089101A1 US10/670,995 US67099503A US2009089101A1 US 20090089101 A1 US20090089101 A1 US 20090089101A1 US 67099503 A US67099503 A US 67099503A US 2009089101 A1 US2009089101 A1 US 2009089101A1
Authority
US
United States
Prior art keywords
data
insurance
user
web
case
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10/670,995
Inventor
Safaa H. Hashim
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Oracle International Corp
Original Assignee
Oracle International Corp
Integrated Insurance Technologies Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Oracle International Corp, Integrated Insurance Technologies Corp filed Critical Oracle International Corp
Priority to US10/670,995 priority Critical patent/US20090089101A1/en
Assigned to INTEGRATED INSURANCE TECHNOLOGIES CORPORATION reassignment INTEGRATED INSURANCE TECHNOLOGIES CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: HASHIM, SAFAA H.
Assigned to SKYWIRE IIT ACQUISITION, LLC reassignment SKYWIRE IIT ACQUISITION, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: INTEGRATED INSURANCE TECHNOLOGIES CORPORTATION
Assigned to DOCUCORP INTERNATIONAL, INC. reassignment DOCUCORP INTERNATIONAL, INC. MERGER (SEE DOCUMENT FOR DETAILS). Assignors: SKYWIRE IIT ACQUISITION, LLC
Assigned to ORACLE INTERNATIONAL CORPORATION reassignment ORACLE INTERNATIONAL CORPORATION IP TRANSFER AGREEMENT Assignors: DOCUCORP INTERNATIONAL, INC.
Publication of US20090089101A1 publication Critical patent/US20090089101A1/en
Priority to US15/369,269 priority patent/US20170083982A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/08Insurance
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063Operations research, analysis or management
    • G06Q10/0633Workflow analysis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/10Office automation; Time management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/20Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/2866Architectures; Arrangements
    • H04L67/30Profiles
    • H04L67/306User profiles

Definitions

  • FIG. 1 depicts in a simplified diagram the various participants involved in a typical insurance sales and underwriting process.
  • a life insurance contract for a natural person is employed as an example.
  • the information disclosed herein applies equally well to other types of insurance contract and/or to other types of insurance customer, i.e., irrespective whether the customer is a natural person or a legal or physical entity such as a corporation, a building, etc.
  • agents 102 , 104 , and 106 in FIG. 1 perform many customer interface functions. For example, agents may prospect for potential customers, provide information to potential customers about various insurance products, and interact with the customers to initiate the underwriting process once the customers decide on one or more insurance products.
  • an agent may work with his customer, now an applicant, to obtain necessary information and/or biological specimens, and may answer any questions that the applicant may have about the proposed insurance contract and/or the underwriting process.
  • the insurance contract is approved by the carrier and executed by the applicant, it becomes a policy in force, and the applicant, now the insured, may continue to interact with the agent to update his personal information from time to time, to make a claim against the policy, and/or to obtain any further information about the insurance policy and/or any other insurance offerings.
  • an agent may work for or through one or more agencies. Some agents may work for a single insurance agency (such as in the case of agents 102 and 104 with respect to an agency 108 ). These exclusive relationships between agents 102 and 104 with respect to agency 108 are indicated by reference numbers 114 and 116 respectively. Other agents may work for multiple agencies, such as in the case of an agent 106 with respect to agencies 108 , 110 , and 112 . These relationships between agent 106 and agencies 108 , 110 , and 112 are enumerated by reference numbers 118 , 120 , and 122 , respectively. An agent may chose to work with multiple agencies to broaden his product offerings since an agency typically represents only a limited number of insurance carriers.
  • agencies may rely on third-party service providers ( 124 , 126 and 128 in FIG. 1 ) to perform various tasks, such as to obtain a health history of an applicant, and to obtain blood pressure readings, blood samples and/or any other metrics required to evaluate the insurance contract proposed.
  • third-party service providers 124 , 126 and 128 in FIG. 1
  • the market for service providers is dominated by about two dozen large service providers.
  • the orders for such service come primarily from the agencies although some may come from the insurance carriers. Examples of these relationships are shown by reference numbers 140 , 142 , 144 , and 146 .
  • an agency may work with as many service providers as necessary to fulfill the requirements of an insurance contract and/or to fulfill its obligations to the insurance carrier interested in insuring the applicant.
  • insurance carriers can work with as many service providers as desired.
  • Insurance companies or insurance carriers 150 , 152 , and 154 represent the entities that evaluate a proposed insurance contract in view of the information gathered by the agent, his agency, and/or one or more service providers, and to decide on an applicable rate and/or insurance policy limit.
  • Insurance carriers There are hundreds of insurance carriers offering life insurance products in the United States.
  • Insurance carriers have relationships ( 160 , 162 , 164 , 166 , 168 , and 170 ) with service providers (e.g. 124 , 126 , and 128 ), since it is customary (but not absolutely required) that insurance carriers pay for the services furnished by the service providers irrespective whether the service orders originated from the agencies (e.g., 108 , 110 , or 112 ) or from the insurance carriers.
  • an insurance carrier generally has a contract with one or more insurance agencies, which contract governs the relationship between the insurance carrier and the insurance agency(ies). These contractual relationships are enumerated in FIG. 1 by reference numbers 180 , 182 , 184 , and 186 .
  • the contract may include terms such as the insurance products an agency may sell, its geographical territory, the commissions payable to the agency for a successfully sold insurance policy, and the like.
  • an insurance carrier rarely work directly with agents, it is customary that an insurance carrier notify a state's insurance department of the appointment of an agent, in effect informing the state's regulatory agency about the agents representing its product lines before the public in that state.
  • FIG. 2 shows in a simplified diagram a typical insurance underwriting cycle.
  • the cycle starts with a customer 202 contacting an agent 204 to request information about insurance.
  • Agent 204 may have identified customer 202 through his contacts or via his prospecting program, or customer 202 may have been referred to agent 204 by an agency and/or an insurance carrier.
  • agent 204 typically provides insurance information to customer 202 , answers any questions that may specifically apply to customer 202 , and/or clarifies any information to entice customer 202 to apply for insurance.
  • agent 204 Since agent 204 earns a commission on each successfully completed insurance policy, agent 204 typically has a vested interest in getting customer 202 to fill out an application and in following up with other participants in the underwriting process to ensure that the application timely matures into a valid insurance policy.
  • customer 202 fills out an application, generally in the form of a questionnaire that is designed to solicit certain preliminary information from the applicant.
  • the information to be provided may include the name of the applicant, his birth date, any governmental form of identification such as his driver license number and/or his social security number, his age, certain lifestyle data, superficial medical history, and the like.
  • Agent 204 then forwards the application to agency 206 , which is an agency representing the insurance product of the insurance carrier that the applicant is interested in.
  • agency 206 at this point takes in the application, performs certain administrative quality-control checks such as to ensure that the submitting agent can in fact sell the insurance contract proposed, that all questions in the application have been filled out, that the application is properly signed. Once the preliminary quality-control checks are completed, agency 206 then forwards the application to both service providers 208 and an insurance carrier 210 . Typically, the service provider gets specific orders based on the requirements of the carrier that offers the applied for insurance coverage.
  • the transmission of the application may be made using traditional paper and mailing methods, or may involve the electronic transmission of text/images.
  • agency 206 continues to monitor the application progress to ensure that the service provider(s) timely perform the requested services and that the application is timely acted upon by the insurance carrier once all the information required by the insurance carrier is obtained.
  • Service provider 208 may provide various administrative and/or paramedical services. For example, service provider 208 may obtain a health history (e.g., an Attending Physician Statement or APS) from the applicant's physician to be forwarded to insurance carrier 210 . As another example, service provider 208 may obtain blood and urine samples from the applicant, and forward the samples to a laboratory 212 for analysis. The results of the analysis by laboratory 212 may be sent back to service provider 208 for forwarding to insurance carrier 210 , or, more likely, laboratory 212 may send such analysis directly to insurance carrier 210 .
  • a health history e.g., an Attending Physician Statement or APS
  • service provider 208 may obtain blood and urine samples from the applicant, and forward the samples to a laboratory 212 for analysis. The results of the analysis by laboratory 212 may be sent back to service provider 208 for forwarding to insurance carrier 210 , or, more likely, laboratory 212 may send such analysis directly to insurance carrier 210 .
  • APS Attending Physician Statement
  • insurance carrier 210 may begin the risk assessment process to determine the probability of whether and when the proposed insured (i.e., the applicant) would likely be making a claim. For life insurance contracts, this risk assessment generally relates to deciding the expected mortality of the applicant in view of the information obtained. Once risk assessment is completed, insurance carrier 210 may then place the applicant in a premium class, which determines the cost of the proposed insurance contract for the applicant given the applicant's own unique circumstances and the proposed insurance limit amount(s).
  • This premium and/or insurance limit information is transmitted to agency 208 and in turn to agent 204 to be discussed with customer 202 . If customer 202 approves, the customer may execute the insurance contract at that point. At this point, the executed insurance contract becomes an enforceable insurance policy, thereby completing the insurance underwriting process.
  • the insurance underwriting process is a complex process requiring information from and coordination with numerous participants in a predetermined sequence.
  • the insurance industry has been underwriting millions of insurance contracts, and has developed techniques for obtaining the necessary information to converting a pending application into a premium-generating policy.
  • the current process for insurance underwriting is extremely inefficient and time-consuming. At every step in the chain, there is a significant amount of duplication of efforts and inefficiency.
  • agencies, service providers, and carriers often have their own proprietary software for processing and tracking cases (i.e., applications). This is particularly true for independent agents and/or independent agencies and/or service providers. Accordingly, the information transmitted from one participant to another often comes in disparate packages, and often needs to be re-transcribed or translated at every step to simply accomplish data entry.
  • the insurance carrier and/or service providers often receive disparate information related to a case at different times. A significant amount of effort must be spent correlating received pieces of information, all belonging to different cases and arriving at different times.
  • Current industry practice employs the applicant's name and/or date of birth and/or some form of government identification such as an applicant's social security number for correlation. Yet, it is not unusual that one of the participants along the chain mis-transcribes a name, a birth date, and/or a social security number, giving rise to confusion for other participants down the chain.
  • the aforementioned problem in correlating information means that a service provider must not only devote human resources to correlate data received from the various agencies but must also devote human resources to answer calls and/or emails from agents, agencies, and insurance carriers about the progress and/or status information on service orders.
  • agents and agencies are particularly anxious in finding out status data regarding a case, in determining whether additional information is needed to move a case along, whether that information can be provided by the service provider, the applicant, or by the insurance carrier.
  • agents and agencies Given the different participants involved, with each participant employing its own proprietary software to process and monitor cases, there is no easy way for agents and agencies these days to easily monitor the status information pertaining to a case as it moves among the participants, particularly after the case has been forwarded to the service providers and the insurance carrier.
  • agents serve as the customer interface function, and the inability to quickly obtain status information in order to meaningfully respond to status inquiries from applicants significantly lowers customer satisfaction.
  • the applicant may be sufficiently frustrated about the delay and lack of information to terminate the process with an agent, opting to reapply for insurance with a different agency that can underwrite the policy in a shorter amount of time. In some cases, the applicant may simply quit the process entirely out of frustration.
  • a scalable, adaptable, modular, and web-centric Insurance Back-Office System for serving the needs of carriers, agencies, agents, and service providers in the insurance industry.
  • the IBOS provides a framework for allowing web-centric collaboration among agents, agencies, carriers, and service providers, using applications that manage applicants, cases, and policies in an efficient and secure manner.
  • the IBOS infrastructure is designed to facilitate the creation of a new application, module, tool, or view in a simplified manner.
  • FIG. 1 depicts in a simplified diagram the various participants involved in a typical insurance sales and underwriting process.
  • FIG. 2 shows in a simplified diagram a typical insurance underwriting cycle.
  • FIG. 3 shows, in accordance with one embodiment, the IBOS architecture components.
  • FIG. 4 shows an exemplary screenshot of a IBOS application, iDesktopTM.
  • FIG. 5 shows, in accordance with one embodiment of the present invention, one deployment configuration for iDesktopTM.
  • FIG. 6 shows, in accordance with one embodiment of the present invention, an alternative approach wherein each participant (agency, carrier, service provider) hosts its own business database.
  • FIG. 7 shows, in accordance with one embodiment of the present invention, the sequence for user login and authentication.
  • FIG. 8 An exemplary login screen for iDesktopTM is shown in FIG. 8 .
  • FIG. 9 An exemplary home page for iDesktopTM is shown in FIG. 9 .
  • FIG. 10 shows an exemplary page displayed when the user is employing the QuickViewTM module.
  • FIG. 11 shows an exemplary QuickViewTM page displaying the summary by carrier view.
  • FIG. 12 shows an exemplary QuickViewTM page displaying the policies list view, showing five policies per page.
  • FIG. 13 displays another exemplary policy list view after the user has specified in FIG. 12 that 20 policies are to be displayed per page.
  • FIG. 14 shows an exemplary policy details view, which represents the most detailed display pertaining to a policy.
  • FIG. 15 shows an exemplary screen that the user can invoke to add a follow-up task to the policy shown to the policy details view.
  • FIG. 16A shows, in accordance with one embodiment of the present invention, the tools available in the QuickViewTM module.
  • FIG. 16B shows, in accordance with one embodiment of the present invention, the tools available in QuickCaseTM, in accordance with one embodiment.
  • FIG. 17 shows, in accordance with one embodiment of the present invention, a workflow for underwriting a policy using iDesktopTM.
  • FIGS. 18-22 show, in accordance with embodiments of the present invention, various exemplary views of the Client Tool of the QuickCaseTM module.
  • FIGS. 23-27 show, in accordance with embodiments of the present invention, various exemplary views of the Client Tool of the QuickCaseTM module.
  • IBOS Insurance Back-Office System
  • the IBOS provides a framework for allowing web-centric collaboration among agents, agencies, carriers, and service providers, using applications that manage applicants, cases, and policies in an efficient and secure manner.
  • the inventive IBOS leverages on the familiar desktop visual metaphor even though the applications themselves are provided over thin web clients.
  • IBOS To promote secure collaboration in the insurance underwriting and management processes, user access to the IBOS is role-dependent. In other words, the data, views, tools, modules, and applications available to a user of the IBOS depend on the role of the user. To clarify, there are currently two broad roles within the IBOS. It is contemplated, however, that as the product evolves, additional roles may also be implemented, and IBOS is designed such that additional roles can be accommodated easily.
  • agent is the person directly interfacing with the insurance buying public, and who is compensated for his effort in selling the insurance product to the public.
  • a case manager who may work for an agency, a service provider, or a carrier, is an administrative personnel responsible for gathering and processing information to help a case mature into a policy and to manage a policy once in force.
  • the IBOS is also user-specific in that the identity of the user may also be employed to determine the set of applications/modules/tools (collectively “mechanisms”) and the data that he has access to.
  • the role-based feature allows, for example, an agent using the IBOS to employ role-appropriate mechanisms to view/manipulate data related to clients and/or cases/policies. Being also user-specific, the identity of that agent will be employed to ensure that that agent can view/manipulate data associated only with his clients and/or cases/policies but not to view/manipulate data associated with other agents' clients and/or other agents' cases/policies.
  • a case manager in an agency using the IBOS can employ role-appropriate mechanisms (which may be the same or different from those employed by the agents) to view/manipulate data related to cases/policies assigned to her for managing in that agency. Being also user-specific, the identity of that case manager will be employed to ensure that that case manager can view/manipulate data associated only with the cases/policies for which she is responsible but not to view/manipulate data associated with cases/policies under the management of other case managers in the same agency or in different agencies. The same feature applies for case managers in service providers or in carriers.
  • the user identity and/or role also determines the data that that user can view and/or edit.
  • a user may have access for viewing to only some data pertaining to a case but not other data based on his user identity and/or role.
  • a user may be able to view some data but not edit such data based on his user identity and/or role.
  • a case manager at a service provider may be able to view selected data pertaining to a case (e.g., the phone number of an applicant for contact purposes) but not others (e.g., the policy limit).
  • a case manager at a carrier may be able to view certain data pertaining to a case (e.g., the agency in charge of the case) but not edit such information (e.g., cannot change the agency name to another agency).
  • the appearance of the IBOS to a user may change depending on his/her role, and the data available for viewing and/or manipulation is also dependent on his/her identity.
  • This is one way that the IBOS promotes compliance with privacy protection initiatives in the industry as well as with privacy protection regulations such as the federally-mandated HIPAA (The Health Insurance Portability and Accountability Act of 1996) or GLB (The Gramm-Leach-Bliley Act of 1999).
  • IBOS is also context-dependent.
  • a context can be characterized by one or more environmental factors that, in combination, sets the context of operation. For example, role, browser type, organization type (e.g., carrier, agency, or service provider), and others all combine to define a context that in turn defines how the application behaves in terms of the modules/tools/views available and the data accessible to a user.
  • the IBOS is implemented by a multi-layer component architecture, with each layer serving as a container for grouping the modular components associated with the layer below it.
  • the IBOS is implemented by a five-tier architecture: portal/container, web application, module, tool, and view. These the IBOS architecture components are depicted in FIG. 3 .
  • portal/container level 302 At the highest level is the portal/container level 302 .
  • portal/container level Under portal/container level is the application level 304 .
  • Application level 304 includes one or more web-centric applications, some or all of which preferably adopt the web-centric desktop visual metaphor provided by portal/container level 302 .
  • the IBOS can be deployed either as a portal hosted by a third-party hosting company or a container/framework for a set of applications, which container/framework is hosted by the company locally at the company's server.
  • the company represents an agency or a service provider or a carrier.
  • the portal model may be an aggregator model or a private-label model.
  • the aggregator portal model is particularly well-suited to the needs of independent insurance agents who may work for multiple insurance agencies.
  • a third-party hosting company would host the applications, and agents may be able to login via the internet to use the IBOS applications.
  • the agent may type in “http://login.iitcorporation.com/idesktop” on any web browser to access the login page for the iDesktopTM application hosted by the third-party hosting company IIT (whose URL is at iitcorporation.com).
  • the role-appropriate mechanisms are then provided for viewing/manipulating of user-appropriate data.
  • the agent may be charged a fee for such use, which may be, for example, a one-time per case/policy fee or a set monthly fee (which may be scaled based on volume if desired).
  • the third-party hosting company may also host the IBOS applications for a particular company, in effect providing hosting services for a private-label version of the IBOS. This is the case, for example, agency ABC or service provider OPQ or carrier XYZ wishes to buy or lease a private label version of the IBOS applications so as to promote their name brand to their users, and contracts with the third-party hosting company to host the set of private-label applications for agency ABC or service provider OPQ or carrier XYZ.
  • an agent working for agency ABC may be able may type in “http://login.abc.com/idesktop” on any web browser.
  • the server at abc.com redirects the user to the third-party hosting company's server in a manner transparent to the agent accessing the IBOS application iDesktopTM.
  • the third party host company server may then serve up a private label version of the IBOS application iDesktopTM, which appears to the agent as if it is a IBOS application branded and tailor-made only for the ABC agency.
  • This portal private label model is well-suited to the needs of companies (agencies/service providers/carriers) that may wish to provide private-label access for free for their employees/independent contractors but do not wish to undertake the task of hosting the IBOS themselves.
  • the companies in turn compensate the hosting company (e.g., IIT) for the hosting service and/or for the use of the applications.
  • IIT hosting company
  • the company may also lease or buy the IBOS directly for hosting on a server at their site.
  • the IBOS acts as a container/framework for the leased or purchased applications. This is similar to the portal private label model except that the IBOS (and thus the portal) is now hosted by the company itself.
  • Applications 304 are preferably implemented as web-centric applications that employ the desktop visual metaphor for accessing modules 306 . Leveraging on the user's familiarity with desktop interfaces, such as Windows XPTM by Microsoft Corporation of Redmond, Wash., an application 304 may be structured so as to appear as a desktop to the user.
  • FIG. 4 shows, in accordance with one embodiment of the present invention, an example of a IBOS application, iDesktopTM, which allows the participants to manage the insurance underwriting process. iDesktopTM functionalities will be discussed in details later herein.
  • FIG. 4 there is a toolbar 402 , on which an icon 404 is displayed, signaling that the web-centric IBOS application currently employed is iDesktopTM.
  • Icons 406 , 408 , 410 , and 412 represent the icons for activating the modules associated with the active application iDesktopTM. This is in keeping with the desktop metaphor wherein the user clicks on the icons on the tool bar to activate desktop applications (whereas in the IBOS world in which the desktop is only a metaphor, clicking on the toolbar icons will activate the modules).
  • each application serves as a framework to furnish an infrastructure for plugging in modules.
  • other applications exist to serve different insurance management needs. For example, applications directed toward data mining of policy/policyholder data, toward making the client and case intake process more efficient through the use of telephonic or web-based interviews, and the like, may also be accommodated.
  • each application 304 such as iDesktopTM includes a plurality of modules to serve different business logic needs.
  • each business module comprises a set of business logic functions or features, implemented as tools, that maps closely to the entities being managed.
  • data is associated with entities.
  • iDesktopTM the business data can currently be broadly classified as being associated with one of four entities: client, case, policy, or service order. It is contemplated, however, that other entities may exist and the IBOS architecture can readily accommodate additional entities, if additional entities are desired.
  • a client is either a prospective applicant for insurance, an applicant for insurance, or the insured (i.e., policy holder) if the insurance contract is approved and executed.
  • the prospective and in-force insurance contract is referred to as a case.
  • an application for insurance is a case, and so is a pending policy, and so is a policy in-force.
  • a policy is a case after it has been accepted by a carrier for consideration.
  • a policy may be pending policy, which means that the carrier has deemed the case submitted to have enough minimum information to allow the carrier to begin the process of data collection from the service providers and others, of performing risk and premium analysis, and ultimately of approving or rejecting the case.
  • a service order is an order for service to a service provider from an agent, an agency, another service provider, or a carrier.
  • An example service order may involve, for example, an order for EFG Company to take blood and urine specimens of an insurance applicant for analysis.
  • the classification of all insurance related data as belonging to one of these four entities vastly simplifies the logic model and user model for implementing and using the iDesktopTM application.
  • the application framework also includes infrastructure for security control, access control, authentication and verification (user-login), general administration and setup, and the like. It is preferable that each application includes at least three modules: a user profile module to manage user profiles, a general administration module for handling administrative tasks pertaining to the application such as to manage user accounts, and a business module for accomplishing certain tasks related to insurance underwriting or management. Although this organization makes applications easier to implement and navigate, it is not absolutely necessary in all cases.
  • Modules are configured to be modular, allowing the application to be scalable.
  • iDesktopTM may have seven modules but not all will be required at all times. In fact, modules can be purchased incrementally as need arises.
  • a QuickViewTM module for enabling agents and their case managers in an agency to analyze, quantify, and process cases.
  • a QuickCaseTM module allows collaboration among agent/agency/service provider/carrier during the underwriting process, up to the time the case is accepted by the carrier and becomes an enforceable policy.
  • Each module 306 implements a plurality of tools.
  • a module may be thought of as a container that provides an infrastructure for plugging in modular tools. Both tools and modules are reusable components, allowing the creation of new modules and/or new applications without requiring a complete rewrite of codes. In other words, certain tools and modules are reusable, and different tools may be grouped to form a new module, and different modules may be grouped to form a new application. Tools can be customized by users using preference settings.
  • a generic tools represents a tool that can exist in more than one module and functions in a substantially similar manner in each of the modules in which it is deployed.
  • Examples of generic tools which will be discussed in details later herein in connection with the QuickViewTM and QuickCaseTM modules, are hotlist, followup, report and search.
  • Entity-specific tools are tools specific to entities (of which there are four in the exemplary implementation of iDesktopTM).
  • Client tools and service order tools are examples of entity-specific tools in the QuickCaseTM module.
  • Each tool 308 may have a plurality of views. Like tools and modules, the views are implemented by code that is modular and also reusable. In most tools, there may be found three views: summary, list, and details.
  • a summary view provides an agent with a summary view of the cases he is handling, sorted by some broad criteria (e.g., by carriers).
  • the list view provides, for example, a list of all cases the agent is currently handling.
  • the detailed view provides, for example, the most detailed presentation of data associated with a case undergoing the underwriting process.
  • One important aspect of the invention is the consistency with which new features/product offerings can be developed and user navigation can be accomplished.
  • By classifying all insurance-related data as belonging to one of the entities e.g., the four entities of the present example: case, policy, client, or service order
  • tools can be easily developed.
  • each level representing a container for bundling the modular components associated with the level below it (e.g., a tool is a container for bundling modular views, a module is a container for bundling the modular tools, an application is a container for bundling the modular modules, and a portal is a container for bundling modular applications)
  • a tool is a container for bundling modular views
  • a module is a container for bundling the modular tools
  • an application is a container for bundling the modular modules
  • a portal is a container for bundling modular applications
  • the development of a new feature/product offering comprises deciding which architectural level the new feature/product offering belongs to (e.g., a new application, a new module, a new tool or a new view). Once the appropriate architectural level is decided, new feature/product offering may be formed by bundling existing modular architectural components. If existing modular architectural components do not satisfy all the requirements of the new feature/product offering, new code may be written but only to the extent necessary to supplement the existing bundle.
  • each module is implemented with a given set of menus and tools.
  • all modules are implemented with three menus (action, tool, and help), and two access tools (of which search is one access tool and the other may be a hotlist or summary or the like) on its home page.
  • the action menu provides the user with the actions that can be taken with respect to the entities selected (e.g., cases, policies, clients, or service orders).
  • An example of an action may be send an email to all clients selected, or to group all selected cases into a hotlist (note that hotlist is either an action, denoting that a group of cases or policies is to be marked as high priority, or a hot list may be an access tool, causing the group previously designated as a hotlist to be displayed).
  • the tool menu furnishes the user with all the generic and entity-specific tools available in the module. Help provides helpful hints in using the particular module.
  • the search tool which is one of the access tools visible in the home page of the module, allowing the user to search the entities (e.g., cases, policies, clients, or service orders) according to some predefined criteria.
  • entities e.g., cases, policies, clients, or service orders
  • QuickViewTM an agent may search for all his cases that has a policy limit between $750,000 and $1,000,000.
  • Summary displays the entities in accordance with some predefined criteria, depending on the preference setting. For example, an agent may use the summary tool to view all cases summaries sorted by agencies, carriers, or service providers.
  • data needs to be shared among the participants of the insurance underwriting/management process.
  • data be encrypted using a highly secure encryption technology (e.g., 128-bit encryption in one embodiment) and using a secure connection technology such as secure socket layer or SSL, (see Internet Engineering Task Force at ietf.org).
  • a highly secure encryption technology e.g., 128-bit encryption in one embodiment
  • a secure connection technology such as secure socket layer or SSL, (see Internet Engineering Task Force at ietf.org).
  • the business database (i.e., the database that includes data regarding clients and/or cases/policies) is hosted at a central hub, and carriers, service providers, agencies, and agents may access data at this central hub.
  • a central hub i.e., the database that includes data regarding clients and/or cases/policies
  • FIG. 5 wherein there is shown, in accordance with one embodiment of the present invention, an iDesktopTM application 502 and 504 executing at servers associated with an agency and a carrier respectively. There is also shown an IIT aggregator iDesktopTM portal 508 , representing the aforementioned aggregator portal.
  • Data hub 510 which is responsible for hosting the business database.
  • Data hub 510 includes an integration server 512 , which provides business-to-business (B2B) transaction processing.
  • Integration server 512 may include a web application transactional web engine 520 , a data translation engine 522 , and a workflow engine 524 .
  • the transactional engine 520 sends data to and receives data from iDesktopTM applications 502 and 504 to facilitate underwriting a case and/or managing cases/policies.
  • This same engine may also be responsible for sending and receiving data for business partners (carriers, agencies, and service providers), in effect acting as a middleman to facilitate the data transfer among these partners.
  • RDBMS relational database management system
  • the business data or meta data translation engine 522 translates data and formats data as data is exchanged among agencies, carriers, and service providers. This ensures that the receiving party can receive data in the format that can be easily used and analyzed, thereby eliminating the need for manual transcribing.
  • a business rules engine 526 for managing business rules is shown.
  • the workflow engine 524 in data hub 510 implements public workflows, i.e., workflows among the agents, agencies, service providers, and carriers.
  • a workflow is a bundle of data and subtasks executed in a predefined sequence. An exemplary portion of such a public workflow may include sending an email to notify the agency at the same time that the service provider sends a specimens result to the carrier.
  • the public workflows are handled by the workflow engine at data hub 510 since data hub 510 serves as the hub through which data among the participants may flow and therefore is a natural place for implementing the public workflow logic.
  • Each iDesktopTM application 502 , 504 , and 508 may also include a private workflow engine (reference numbers 502 a , 504 a , and 508 a ). These workflows are deemed private since they involve data and tasks to be transmitted internally within the participant's organization. An exemplary portion of such a private workflow may include sending an email to both an agent and his case manager, informing both that an application from the agent's client has been examined and another signature is needed before the case can be forwarded to the carrier.
  • each of Each iDesktopTM application 502 , 504 , and 508 is shown interacting with its own web client (which may be through a wired connection as in the case of web client 502 a or a wireless connection, as in the case of web client 502 b ).
  • IIT hub 510 is also shown coupled to legacy systems, such as the service providers' own order processing system 527 , the agency's own case management system 526 , or the carrier's own application underwriting system 525 .
  • FIG. 6 shows, in accordance with one embodiment of the present invention, an alternative approach wherein each participant (agency, carrier, service provider) hosts its own business database.
  • each of agency 602 and carrier 604 can use multiple databases: its own internal or third party application or business database, and a database containing data for collaboration.
  • agency 602 also manages an agency database 602 b and a QuickViewTM database 602 c .
  • carrier 604 also manages a carrier database 604 b and a QuickViewTM database 604 c.
  • IIT hub refers to the central application and database employed to enable data exchange among IIT network and insurance business partners (such as carriers, agents, agencies, service providers).
  • the collaboration data in databases 602 c and 604 c are synchronized with hub database 610 c using either IIT's data synchronization technology or an industry-standard web services technology.
  • the data in QuickViewTM database e.g., 610 c or 602 c
  • This carrier-provided data from the carrier is synchronized with IIT hub ( 610 ) to update the QuickViewTM database 610 c .
  • IIT hub 610 then synchronizes the carrier-provided data at the agencies (e.g., in QuickViewTM database 602 c ) to enable the IIT general agency system (IITGA) 602 d to view the latest carrier-provided data.
  • agencies e.g., in QuickViewTM database 602 c
  • IITGA IIT general agency system
  • FIG. 6 also shows a GA-QV integration facility 602 e in agency 602 .
  • the carrier may have its own legacy or third-party software for case/policy management, and the data provided by the carrier may differ in format from that originally provided to the carrier. Furthermore, the carrier may not even employ the case number assigned by iDesktopTM.
  • GA-QV integration facility 602 e employs algorithm to match the pending policy provided by the carrier with the case being tracked by iDesktopTM (using for example the applicant name, his address, his birth date, his governmental identification data, and/or the like). Once the match is made, a translation table may be generated to permit correlation between the case being tracked by iDesktopTM and the pending policy tracked by the carrier.
  • Web clients 610 d , 602 f , and 604 d are also shown in communication with their respective iDesktopTM applications. Although only one web client is shown per application, it should be understood that each iDesktopTM application can service any number of web clients, through a local area network, a virtual private network, or through the Internet, or any other data transmitting network.
  • data translation may be performed at the target server (e.g., the server receiving data such as the server at the carrier, agency, or service provider) or more preferably, data translation may be performed by the IIT hub 510 or 610 .
  • iDesktopTM is one application that can be plugged into the infrastructure provided by the IBOS.
  • iDesktopTM allows geographically diverse agents, agencies, service providers and carriers to collaborate in a secure, web-centric environment using the familiar desktop metaphor in order to underwrite and manage insurance policies. It is not necessary that all agents, agencies, service providers, and carriers have a business relationship with one another to employ iDesktopTM. Diverse groups of participants can all employ idesktopTM, and since iDesktopTM is role-sensitive, context-sensitive, and user-specific, a user of iDesktopTM can only access data for which he is authorized to view and/or manipulate.
  • the iDesktopTM application can be made available to thousands of business partners, all working on millions of cases in various permutations of working relationships.
  • the role-based, context-based, and user-specific features mean that ownership for accessing cases for viewing and/or manipulating data is well-defined for each case and each business partner working on that case, and there is virtually no risk of a data security compromise on any case.
  • iDesktopTM can be employed by an independent agent who is not exclusively associated with any agency, by an agent who is exclusive with an agency, by a case manager at an agency, by a case manager at a carrier, or by a case manager at a service provider.
  • FIG. 7 shows, in accordance with one embodiment of the present invention, the sequence for user login and authentication.
  • the user may access the application iDesktopTM ( 702 ) by, for example, typing the appropriate URL into a browser.
  • the user may type in “https://iit.idxtop.com:9443” which brings up a login screen.
  • An exemplary login screen is shown in FIG. 8 .
  • the user may either ( 703 ) enter his id/password ( 704 ) if he is an existing user or may choose to register if he is a new user ( 706 ).
  • the registration process may require the user to identify his role (i.e., agent or case manager) ( 706 a ), to choose a new userID and a password ( 706 b ), and to enter his personal data ( 706 c ) such as name, address, email, government IDs, and the like.
  • the user may also be required to identify data related to the agency/agencies, carrier(s) and service provider(s) which pertain to his work.
  • authentication is performed using a user database that is separate from the business database. Technologies such as directory server (available from the aforementioned Microsoft Corporation or Sun Microsystems, Inc. of Mountain View, Calif.) may be employed during the authentication process.
  • the authentication may involve checking with the carrier and/or service provider and/or agency to ensure that the user is authorized as represented by the user. Part of the checking includes ascertaining the business data (e.g., regarding entities such as clients, polices, cases, and service orders) that the user is allowed to access based on his role and his agency/carrier affiliation.
  • iDesktopTM which is presented in the desktop metaphor as mentioned earlier. This is shown in FIG. 9 . From this home page of iDesktopTM (and indeed from any page from this point onward), the user may then select the module to work on by clicking on the appropriate icon in the toolbar.
  • QuickCaseTM is employed collaboratively among agent, his agency, the service provider(s) and the carrier to create a completed insurance application. Once the application is accepted by the carrier, it becomes a pending policy. At that point, QuickViewTM may still be employed to search, view, and annotate the policies with follow-ups and QuickCaseTM is still employed to facilitate collaboration if an action is needed from one of the business partners (e.g., from the service providers) to turn the pending policy into a policy in force.
  • the business partners e.g., from the service providers
  • QuickViewTM is the tool employed by the business partners for collaboratively viewing, researching data and status, and annotating (with follow-ups) on the pending policies and the policies in-force. If a business partner discovers that a pending policy requires action to be taken, the client/case/service order tools in QuickCaseTM is then invoked to allow the business partners to work collaboratively.
  • QuickViewTM may be employed to perform many tasks associated with managing policies. For example, an agent or a case manager may employ QuickViewTM to view data pertaining to policies and to annotate policies with follow-up data if desired. As another example, the user (agent or case manager) may also employ QuickViewTM to create a hot list of policies for special attention. As another example, the user may employ QuickViewTM to search/filter policies available to that user to come up with a search result comprising policies selected in accordance with some search criteria. As another example, the user may create reports on any of the views displayed or on the policies using appropriate reporting criteria.
  • policies tool is employed to view policies.
  • the following views are available: summary by agency view (all policies for the user organized by agencies), summary by carrier view (all policies for the user organized by carriers), policies view (list of policies for the user), policy details view (the most detailed view available for a policy), policy follow-ups view (all policies earlier designated for follow-up tasks for the user) and policy hotlist view (all policies earlier designated as a hot list for special attention for the user).
  • Reports tool is the report generating utility to create policy reports according to some report generation criteria, which reports may be created in an electronic form or a printed form.
  • Search tool allows the user to search for an entity (case, policy, service order, client) according to the search criteria entered
  • a page displayed preferably comprises of three main parts: module menus (e.g., action, tools, and help), module tool in focus (e.g., policies tool), and search tool form.
  • FIG. 10 shows an exemplary page displayed when the user is employing the QuickViewTM module.
  • the search tool form is shown by reference 1002 .
  • the module tool in focus is the policies tool, which shows the summary of cases ( 1018 ) by agencies view.
  • the module menus action, tools, and help are shown by reference numbers 1004 , 1006 , and 1008 respectively.
  • the summary-by-agencies view, summary-by-carriers view, policies list view, and hotlist views may be invoked by clicking on tabs 1010 , 1012 , 1014 , and 1016 respectively.
  • the aforementioned three-part organization stays consistent throughout the various pages of the modules and across different modules (e.g., QuickCase) so as to reduce the learning curve for new users, to render navigation consistent, thereby promoting user-friendliness, and to render the implementation of new modules simple.
  • modules e.g., QuickCase
  • FIG. 11 shows an exemplary QuickViewTM page displaying the summary by carrier view (which is displayed by clicking on tab 1012 ).
  • FIG. 12 shows an exemplary QuickViewTM page displaying the policies list view (which is shown by clicking on tab 1016 ).
  • the policies list view of FIG. 12 further comprises an option 1202 , which allows the user to choose the number of policies displayed per page, an option 1204 , which allows the user to manipulate icons to move between pages in the policies list view, and an option 1206 , which allows the user to remember the view currently displayed in the page as a search criteria in the search tool.
  • the saved search criteria may be saved with a name, and may be recalled by name at a later time to allow the user to quickly access the data previously displayed.
  • FIG. 13 displays another exemplary policy list view after the user has specified in FIG. 12 , using option 1202 , that 20 policies are to be displayed per page.
  • FIG. 14 shows an exemplary policy details view, which represents the most detailed display pertaining to a policy.
  • This view may be invoked by clicking on any policy displayed in any of the views displaying one or more policies in a summarized format (e.g., any of the summary views, hotlist view, followup view, search result view, policies list view, and the like). Clicking activates the hyperlink associated with the policy summary data, allowing the page showing the policy details to be displayed.
  • a summarized format e.g., any of the summary views, hotlist view, followup view, search result view, policies list view, and the like.
  • FIG. 15 shows an exemplary screen that the user can invoke to add a follow-up task to the policy shown to the policy details view.
  • the user can arrive at the display screen of FIG. 15 by selecting the follow-up tool 1402 in FIG. 14 , for example.
  • iDesktopTM is user-specific. Accordingly, policies viewable by some agents may not be viewable by other agents and/or case managers. iDesktopTM is also role-specific. Accordingly, a case manager may not have some of the views available to agents. For example, a case manager employed with a specific agency would see only cases associated with that agencies. In which case, instead of a summary by agencies view, the case manager may be presented with a summary by agents view or summary by service providers view or summary by carriers view for all the cases assigned to her to manage. As another example, a case manger employed with a carrier would see only cases associated with that carrier.
  • case manager may be presented with a summary by agencies view or summary by service providers view for all the cases assigned to her to manage. This is an example of how the role-specific feature of the IBOS both improves efficiency/user-friendliness and promotes data security and confidentiality.
  • FIG. 16A shows, in accordance with one embodiment of the present invention, the tools available in the QuickViewTM module 1600 .
  • FIG. 16A there are four generic tools: search tool 1602 , followup tool 1604 , hotlist tool 1606 , and report tool 1608 .
  • search tool 1602 search tool 1602
  • followup tool 1604 followup tool 1604
  • hotlist tool 1606 hotlist tool 1606
  • report tool 1608 report tool 1608
  • entity-specific tool which is policies tool 1610 .
  • FIG. 16B shows, in accordance with one embodiment of the present invention, the tools available in QuickCaseTM, in accordance with one embodiment.
  • QuickCaseTM may include search tool 1652 , reports tool 1654 , follow-ups tool 1656 , and hotlist tools 1658 .
  • search tool 1652 search tool 1652
  • reports tool 1654 reports tool 1654
  • follow-ups tool 1656 follow-ups tool 1656
  • hotlist tools 1658 As mentioned before, these are generic tools and they function in a substantially similar manner as their counterparts in other modules.
  • Client tool 1660 may be employed by the agent to obtain information about a client and build a client profile.
  • the client tool may be employed in step 1702 to obtain at least certain preliminary data regarding the applicant for insurance such as his name, his age, and superficial lifestyle data such as whether he smokes or skydives.
  • Case tool 1662 may be employed by the agent to begin filling out data regarding the insurance policy the client wishes to purchase ( 1704 in FIG. 17 ).
  • the client may indicate that he wishes to purchase term life insurance for 20 years, with a $1,000,000 limit.
  • case tool 1662 may also be employed to view and/or annotate the cases, much in the same manner that policies tools may be employed for policies in QuickViewTM.
  • the client may also employed the QuickQuoteTM tool ( 1706 ) to search among carriers for insurance products that fit the requirements of the client and to provide some preliminary premium quote and/or to provide alternative products that may also be of interest to the client.
  • the agent may associate the case to be underwritten with an agency, if such association hasn't been done as a default (e.g., as in the case where the agent is an exclusive agent of an agency).
  • the case is then assigned with a unique case number in iDesktopTM, which subsequently serves as the primary correlation key for correlating all communication and data from various business partners pertaining to this case. If a communication or data is sent from one of the modules of iDesktopTM pertaining to a case, the unique case number is automatically sent along to allow the receiving server to easily correlate all communication and data pertaining to a case. In this manner, the invention advantageously avoids the prior art problem of trying to resolve communication and data pertaining to a case based on data that may be erroneous or duplicative.
  • the correlation algorithm may be employed to, for example, match the pending policy as sent back from the carrier with the case being tracked in iDesktopTM (based on, e.g., a combination of applicant name, birthdate, social security number, and the like). Once a match is found, a correlation table may track such mapping to allow the business partners to easily correlate communication and data pertaining to a case when collaborating using iDesktopTM.
  • the agent or a clerk at the agency may employ the service order tool 1664 to order services, such as blood or urine tests, from service provider ( 1710 ).
  • Ordering service causes the service order tool to send the order, along with relevant data (e.g., contact information for the applicant) to the service provider(s).
  • relevant data e.g., contact information for the applicant
  • the agent or clerk at the agency may employ QuickCaseTM to send data pertaining to the partially completed case 1712 to the carrier ( 1714 ).
  • Service provider 1710 may also employ QuickCaseTM to collaborate with sub-contractors (such as laboratories) to obtain analysis service for urine specimen, for example.
  • the service provider 1710 may also employ QuickCaseTM to collaborate with the carrier and/or other sub-contracting service providers to furnish the required information to the carrier to allow the carrier to evaluate the pending policy.
  • the agent, agency, and carrier may employ QuickViewTM to monitor the progress and status of the case.
  • a case manager at a carrier may employ QuickViewTM to ascertain whether all data required from the agency has been received and whether all data required from the service provider has been received timely at the carrier. Tools such as follow-ups, reports, and hot lists may also be employed to manage cases.
  • a case manager at the agency and/or agent may employ QuickViewTM to track the progress of a case.
  • the agent may designate a case to be one in his hot list, and he may note that it has taken abnormally long for the service provider to provide the urine specimen analysis result to the carrier. The agent may then follow up with the service provider by sending an email or by another alerting/communicating facility within QuickCaseTM to request that the urine analysis result be sent as soon as possible.
  • a business partner When a business partner completes a business task with respect to a case (e.g., the agency sending a case to the carrier or to the service provider, the service provider obtaining a urine sample and sending the sample to a laboratory for analysis, a carrier receiving a blood sample result from a laboratory or a service provider), that business partner updates status information for the case in iDesktopTM. Thereafter, business partners authorized for viewing the case data may readily obtain status/progress information pertaining to the case at any time using, for example, QuickviewTM.
  • the carrier 1714 may then either accept the pending policy, which becomes a policy in force ( 1716 ) after execution by the applicant or the carrier 1714 may reject the policy and employ QuickViewTM to inform the agent/agency of the rejection ( 1718 ).
  • FIGS. 18-22 show, in accordance with embodiments of the present invention, various exemplary views of the Client Tool of the QuickCaseTM module.
  • the QuickCaseTM module is activated by pressing on the “book of business” icon 1800 in the tool bar. Notice how the navigation options and visual presentation on the screen 1801 follows the theme of the present example: 3 menus and two active tools.
  • the default QuickCaseTM has an active Clients and Search Tool.
  • the Clients tool views are shown by 1802 .
  • FIG. 19 shows a Clients List view in the Clients Tool.
  • FIG. 20 shows the Clients Details View.
  • the Client Profile Form is shown in 2002 , and the user can press icon 2004 to get a print-formatted report of client details.
  • the user can also add client to list of selected items for action ( 2206 ).
  • the user can obtain/access addition data pertaining to the specific client in focus.
  • FIG. 21 shows a Client Followup screen.
  • the list of follow-ups for the client is shown in 2102 .
  • the new/updated follow-up form is shown by reference 2104 .
  • the screen of FIG. 21 is accessed by selecting New Follow-up tab 2106 shown.
  • FIG. 22 shows a Client Follow-Up List View. All clients with follow-up items are shown in the list 2202 .
  • the user can navigate to follow-up detail screen by clicking on the Client name 2204 (since all data shown in iDesktopTM is hyperlinked).
  • option 2206 the user can select the entity displayed (e.g., client) for follow-up action such as print report, add to hot-list, etc).
  • the search tool form is shown by reference number 2208 .
  • FIGS. 23-27 show, in accordance with embodiments of the present invention, various exemplary views of the Case Tool of the QuickCaseTM module.
  • agents may employ the Case Tool to create cases for existing or new clients.
  • a new case for a new client may require the gathering of certain data pertaining to the new client via the Client tool first, in one embodiment.
  • the Case tool has, in one embodiment, case summary, case list, and case detail view.
  • search, follow-up, and hotlist tools there are provided search, follow-up, and hotlist tools.
  • the summary view is shown in FIG. 23 . This is activated by the summary view tab 2302 .
  • the customized drilldown GUI 2304 displays summary of all user cases.
  • the case search tool is again shown by reference number 2306 .
  • FIG. 24 shows the Case List view of the Case Tool.
  • the user can choose the number of cases to be displayed per page ( 2402 ), and can save ( 2404 ) the view as a search criteria to access later, if desired.
  • the columns 2406 are sortable using a preference setting for criteria or by setting options in a popup menu, for example.
  • the case displayed can be selected ( 2408 ) for further action, if desired.
  • the case search tool is again shown by reference number 2410 .
  • FIG. 25 shows the Case Details View.
  • the Case Profile Form is shown ( 2502 ).
  • User can selection option 2504 to get a print-formatted report of the case details.
  • the user can add the case to the list of items ( 2506 ).
  • Through detail tabs 2508 the user can access other data pertaining to the case in focus.
  • FIG. 26 shows the Adding New Followup view of the Case Details View.
  • the New Follow-up form is shown ( 2602 ).
  • the view of FIG. 26 is accessed by selecting the New Follow-up tab 2604 .
  • the Case follow-up view 2700 is shown in FIG. 27 .
  • All cases with follow-up items are shown in the list 2702 .
  • the user can navigate to follow-up detail screen by clicking on the Case reference number 2704 (since all data shown in iDesktopTM is hyperlinked).
  • option 2706 the user can select the entity/entities displayed (e.g., client) for follow-up action such as print report, add to hot-list, etc).
  • the search tool form is shown by reference number 2708 .
  • Access control includes authentication and validation while all data transfer is preferably encrypted (e.g., 128-bit encryption) using a secure connection (such as SSL).
  • a secure connection such as SSL.
  • the data related to user access e.g., the user data base
  • the business data which can only be accessed by the application server through a firewall, using a secure connection.
  • the user may employ the application(s) on the application server to access the business data.
  • Both the access database and the business database may also be physically secured in a secure physical location (e.g., a vault).
  • a view-state database or table for tracking the current states of the views of various tools.
  • the view-state database is preferably persistent in that the user can log off and the view-state database will remember the states of the various views at log-off.
  • the views associated with the various tools are restored.
  • a user may switch among tools while using QuickViewTM or QuickCaseTM.
  • the view-state database tracks the states of the views of the various tools and if the user returns to the previous tool, the view associated with that tool that was displayed just prior to switching is restored, along with all the data associated with that view. This is useful for insurance agents who deal with constant interruptions from different clients and who may need to be able to switch among tools often.
  • collaboration using the web-centric, collaborative IBOS and iDesktopTM application allows information, status, progress and instructions pertaining to a case to be efficiently manipulated, transmitted, tracked, and shared among business partners authorized to view and/or manipulate that case. This solves the problems in the prior art that arise when different participants in the insurance process employs different software to track, process, and transmit information pertaining to a case.
  • the ability for the business partners to employ the collaborative, web-centric IBOS and iDesktopTM application to communicate among themselves to resolve problems (e.g., through emails, notifications or private messenger messages that tie to the unique case number) as well as the ability to easily view a case status and progress at any time renders the insurance underwriting and management processes substantially more efficient.
  • the agent can now obtain progress and/or status data pertaining to a case at any given time from any web-enabled device, customer service is substantially improved.
  • the agent can now respond to a customer's request for status with accurate information.
  • the agent can also track the cases, and take action to speed up the conversion of a pending policy to a policy in force (e.g., by sending a timely reminder email to the right party to take the next step in the process), the invention can substantially reduces the amount of time required to underwrite a policy.

Abstract

A scalable, adaptable, modular, and web-centric Insurance Back-Office System (IBOS) for serving the needs of carriers, agencies, agents, and service providers in the insurance industry is disclosed. The IBOS provides a framework for allowing web-centric collaboration among agents, agencies, carriers, and service providers, using applications that manage applicants, cases, and policies in an efficient and secure manner. The IBOS infrastructure is designed to facilitate the creation of a new application, module, tool, or view in a simplified manner. The web-centric application includes a first module for creating a case and a second module for tracking the case after the case has been submitted to the carrier for consideration.

Description

  • This application claims priority from a provisional patent application entitled “Insurance Management Systems and Methods Therefor”, by inventor Safaa Hashim, filed Sep. 19, 2003, which is incorporated by reference.
  • BACKGROUND OF THE INVENTION
  • Insurance is a complex field. The underwriting of an insurance contract between an applicant and an insurance carrier often involves a plurality of participants, each of whom plays a well-defined role in the complex underwriting process. To facilitate discussion, FIG. 1 depicts in a simplified diagram the various participants involved in a typical insurance sales and underwriting process. In FIG. 1 and the figures herein, a life insurance contract for a natural person is employed as an example. However, the information disclosed herein applies equally well to other types of insurance contract and/or to other types of insurance customer, i.e., irrespective whether the customer is a natural person or a legal or physical entity such as a corporation, a building, etc.
  • In the life insurance industry alone, for example, there are currently between 200,000 and 250,000 licensed agents. These agents, shown as agents 102, 104, and 106 in FIG. 1, perform many customer interface functions. For example, agents may prospect for potential customers, provide information to potential customers about various insurance products, and interact with the customers to initiate the underwriting process once the customers decide on one or more insurance products.
  • During the underwriting process, an agent may work with his customer, now an applicant, to obtain necessary information and/or biological specimens, and may answer any questions that the applicant may have about the proposed insurance contract and/or the underwriting process. After the insurance contract is approved by the carrier and executed by the applicant, it becomes a policy in force, and the applicant, now the insured, may continue to interact with the agent to update his personal information from time to time, to make a claim against the policy, and/or to obtain any further information about the insurance policy and/or any other insurance offerings.
  • Generally speaking, an agent may work for or through one or more agencies. Some agents may work for a single insurance agency (such as in the case of agents 102 and 104 with respect to an agency 108). These exclusive relationships between agents 102 and 104 with respect to agency 108 are indicated by reference numbers 114 and 116 respectively. Other agents may work for multiple agencies, such as in the case of an agent 106 with respect to agencies 108, 110, and 112. These relationships between agent 106 and agencies 108, 110, and 112 are enumerated by reference numbers 118, 120, and 122, respectively. An agent may chose to work with multiple agencies to broaden his product offerings since an agency typically represents only a limited number of insurance carriers.
  • During the insurance underwriting process, agencies may rely on third-party service providers (124, 126 and 128 in FIG. 1) to perform various tasks, such as to obtain a health history of an applicant, and to obtain blood pressure readings, blood samples and/or any other metrics required to evaluate the insurance contract proposed. In the United States, the market for service providers is dominated by about two dozen large service providers. Generally speaking, the orders for such service come primarily from the agencies although some may come from the insurance carriers. Examples of these relationships are shown by reference numbers 140, 142, 144, and 146. As before, an agency may work with as many service providers as necessary to fulfill the requirements of an insurance contract and/or to fulfill its obligations to the insurance carrier interested in insuring the applicant. Similarly, insurance carriers can work with as many service providers as desired.
  • Insurance companies or insurance carriers 150, 152, and 154 represent the entities that evaluate a proposed insurance contract in view of the information gathered by the agent, his agency, and/or one or more service providers, and to decide on an applicable rate and/or insurance policy limit. There are hundreds of insurance carriers offering life insurance products in the United States. Insurance carriers have relationships (160, 162, 164, 166, 168, and 170) with service providers (e.g. 124, 126, and 128), since it is customary (but not absolutely required) that insurance carriers pay for the services furnished by the service providers irrespective whether the service orders originated from the agencies (e.g., 108, 110, or 112) or from the insurance carriers.
  • Generally speaking, insurance carriers work with agents through agencies. Accordingly, an insurance carrier generally has a contract with one or more insurance agencies, which contract governs the relationship between the insurance carrier and the insurance agency(ies). These contractual relationships are enumerated in FIG. 1 by reference numbers 180, 182, 184, and 186. The contract may include terms such as the insurance products an agency may sell, its geographical territory, the commissions payable to the agency for a successfully sold insurance policy, and the like. Although insurance carriers rarely work directly with agents, it is customary that an insurance carrier notify a state's insurance department of the appointment of an agent, in effect informing the state's regulatory agency about the agents representing its product lines before the public in that state.
  • From a contractual standpoint, the participants depicted in FIG. 1 deal with one another at arms length. In practical terms, many of these participants in the insurance underwriting process work with other participants in endless permutations. As will be discussed in connection with FIG. 2, this fact currently contributes to a huge amount of wasted and/or duplicate effort and inefficiency in the insurance underwriting and management process.
  • FIG. 2 shows in a simplified diagram a typical insurance underwriting cycle. The cycle starts with a customer 202 contacting an agent 204 to request information about insurance. Agent 204 may have identified customer 202 through his contacts or via his prospecting program, or customer 202 may have been referred to agent 204 by an agency and/or an insurance carrier. During this pre-sale period, agent 204 typically provides insurance information to customer 202, answers any questions that may specifically apply to customer 202, and/or clarifies any information to entice customer 202 to apply for insurance. Since agent 204 earns a commission on each successfully completed insurance policy, agent 204 typically has a vested interest in getting customer 202 to fill out an application and in following up with other participants in the underwriting process to ensure that the application timely matures into a valid insurance policy.
  • If the insurance product offered is of interest to customer 202, customer 202 fills out an application, generally in the form of a questionnaire that is designed to solicit certain preliminary information from the applicant. The information to be provided may include the name of the applicant, his birth date, any governmental form of identification such as his driver license number and/or his social security number, his age, certain lifestyle data, superficial medical history, and the like. Agent 204 then forwards the application to agency 206, which is an agency representing the insurance product of the insurance carrier that the applicant is interested in.
  • Generally speaking, agency 206 at this point takes in the application, performs certain administrative quality-control checks such as to ensure that the submitting agent can in fact sell the insurance contract proposed, that all questions in the application have been filled out, that the application is properly signed. Once the preliminary quality-control checks are completed, agency 206 then forwards the application to both service providers 208 and an insurance carrier 210. Typically, the service provider gets specific orders based on the requirements of the carrier that offers the applied for insurance coverage.
  • The transmission of the application may be made using traditional paper and mailing methods, or may involve the electronic transmission of text/images. After the application has been transmitted, agency 206 continues to monitor the application progress to ensure that the service provider(s) timely perform the requested services and that the application is timely acted upon by the insurance carrier once all the information required by the insurance carrier is obtained.
  • Service provider 208 may provide various administrative and/or paramedical services. For example, service provider 208 may obtain a health history (e.g., an Attending Physician Statement or APS) from the applicant's physician to be forwarded to insurance carrier 210. As another example, service provider 208 may obtain blood and urine samples from the applicant, and forward the samples to a laboratory 212 for analysis. The results of the analysis by laboratory 212 may be sent back to service provider 208 for forwarding to insurance carrier 210, or, more likely, laboratory 212 may send such analysis directly to insurance carrier 210.
  • After insurance carrier 210 collects all the requisite information from agency 206, service provider(s) 208, laboratory(ies) 212, and any other participants in the insurance underwriting process, insurance carrier 210 may begin the risk assessment process to determine the probability of whether and when the proposed insured (i.e., the applicant) would likely be making a claim. For life insurance contracts, this risk assessment generally relates to deciding the expected mortality of the applicant in view of the information obtained. Once risk assessment is completed, insurance carrier 210 may then place the applicant in a premium class, which determines the cost of the proposed insurance contract for the applicant given the applicant's own unique circumstances and the proposed insurance limit amount(s).
  • This premium and/or insurance limit information is transmitted to agency 208 and in turn to agent 204 to be discussed with customer 202. If customer 202 approves, the customer may execute the insurance contract at that point. At this point, the executed insurance contract becomes an enforceable insurance policy, thereby completing the insurance underwriting process.
  • As can be appreciated from the foregoing, the insurance underwriting process is a complex process requiring information from and coordination with numerous participants in a predetermined sequence. For years, the insurance industry has been underwriting millions of insurance contracts, and has developed techniques for obtaining the necessary information to converting a pending application into a premium-generating policy. However, it is observed by the inventors herein that the current process for insurance underwriting is extremely inefficient and time-consuming. At every step in the chain, there is a significant amount of duplication of efforts and inefficiency.
  • As one example, agencies, service providers, and carriers often have their own proprietary software for processing and tracking cases (i.e., applications). This is particularly true for independent agents and/or independent agencies and/or service providers. Accordingly, the information transmitted from one participant to another often comes in disparate packages, and often needs to be re-transcribed or translated at every step to simply accomplish data entry.
  • Additionally, the insurance carrier and/or service providers often receive disparate information related to a case at different times. A significant amount of effort must be spent correlating received pieces of information, all belonging to different cases and arriving at different times. Current industry practice employs the applicant's name and/or date of birth and/or some form of government identification such as an applicant's social security number for correlation. Yet, it is not unusual that one of the participants along the chain mis-transcribes a name, a birth date, and/or a social security number, giving rise to confusion for other participants down the chain.
  • The lack of coordination gives rise to inefficiency. If a certain amount of time has passed and the insurance carrier still has not received, for example, laboratory results pertaining to a particular applicant, the customary way to resolve the problem is for an insurance carrier employee to call or email the agency in charge of the case, asking the agency to contact the responsible service provider to ask the service provider to contact the laboratory and request that the laboratory forward the laboratory analysis to that carrier. This manner of problem resolution of course requires that there be a human being at each participant to handle the call and/or email and to manually resolve the problem.
  • For service providers, there is no efficient way to receive service orders from different agencies and/or insurance carriers. Again, information from different agencies and/or insurance carriers must be re-transcribed for data entry into the service provider's own order management and tracking software. If an applicant has a special requirement (such as a female applicant requesting that her physical examination be conducted with a female nurse), such information must often be processed manually. Service providers also have difficulties getting status information regarding a particular case from the various laboratories. If a vial of blood sample breaks during transit, and the result is not transmitted to the insurance carrier timely, the service provider may not know until it receives a call from the agency, asking why the insurance carrier has not received the requisite test result. Under this paradigm, the aforementioned problem in correlating information means that a service provider must not only devote human resources to correlate data received from the various agencies but must also devote human resources to answer calls and/or emails from agents, agencies, and insurance carriers about the progress and/or status information on service orders.
  • Agencies and agents are compensated when the underwriting process completes. Accordingly, agents and agencies are particularly anxious in finding out status data regarding a case, in determining whether additional information is needed to move a case along, whether that information can be provided by the service provider, the applicant, or by the insurance carrier. Given the different participants involved, with each participant employing its own proprietary software to process and monitor cases, there is no easy way for agents and agencies these days to easily monitor the status information pertaining to a case as it moves among the participants, particularly after the case has been forwarded to the service providers and the insurance carrier. More importantly, agents serve as the customer interface function, and the inability to quickly obtain status information in order to meaningfully respond to status inquiries from applicants significantly lowers customer satisfaction. In some cases, the applicant may be sufficiently frustrated about the delay and lack of information to terminate the process with an agent, opting to reapply for insurance with a different agency that can underwrite the policy in a shorter amount of time. In some cases, the applicant may simply quit the process entirely out of frustration.
  • Perhaps the most visible manifestation of the inefficiency of the current underwriting process can be seen in the average and standard deviation values for the time required to complete a typical life insurance underwriting cycle. According to some industry sources, a typical life insurance contract underwriting cycle currently requires over two months to complete. It is not unusual that some applications take as long as 180 days to complete. From an applicant perspective, the delay is especially frustrating, especially since meaningful status information is difficult to obtain from his agent. From the perspectives of the agents and agencies, the delay means that they are getting paid late for the work done months earlier. For insurance carriers, the inefficiency translates into additional cost in processing each proposed insurance contract. The lengthy insurance underwriting cycle also delay the point in time where an insurance carrier can deem a pending insurance contract a premium-earning policy.
  • In view of the foregoing, improved methods and arrangements for underwriting and managing insurance policies among the various participants are desired.
  • SUMMARY OF INVENTION
  • In one embodiment, a scalable, adaptable, modular, and web-centric Insurance Back-Office System (IBOS) for serving the needs of carriers, agencies, agents, and service providers in the insurance industry is disclosed. The IBOS provides a framework for allowing web-centric collaboration among agents, agencies, carriers, and service providers, using applications that manage applicants, cases, and policies in an efficient and secure manner. The IBOS infrastructure is designed to facilitate the creation of a new application, module, tool, or view in a simplified manner.
  • These and other features of the present invention will be described in more detail below in the detailed description of the invention and in conjunction with the following figures.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
  • FIG. 1 depicts in a simplified diagram the various participants involved in a typical insurance sales and underwriting process.
  • FIG. 2 shows in a simplified diagram a typical insurance underwriting cycle.
  • FIG. 3 shows, in accordance with one embodiment, the IBOS architecture components.
  • FIG. 4 shows an exemplary screenshot of a IBOS application, iDesktop™.
  • FIG. 5 shows, in accordance with one embodiment of the present invention, one deployment configuration for iDesktop™.
  • FIG. 6 shows, in accordance with one embodiment of the present invention, an alternative approach wherein each participant (agency, carrier, service provider) hosts its own business database.
  • FIG. 7 shows, in accordance with one embodiment of the present invention, the sequence for user login and authentication.
  • An exemplary login screen for iDesktop™ is shown in FIG. 8.
  • An exemplary home page for iDesktop™ is shown in FIG. 9.
  • FIG. 10 shows an exemplary page displayed when the user is employing the QuickView™ module.
  • FIG. 11 shows an exemplary QuickView™ page displaying the summary by carrier view.
  • FIG. 12 shows an exemplary QuickView™ page displaying the policies list view, showing five policies per page.
  • FIG. 13 displays another exemplary policy list view after the user has specified in FIG. 12 that 20 policies are to be displayed per page.
  • FIG. 14 shows an exemplary policy details view, which represents the most detailed display pertaining to a policy.
  • FIG. 15 shows an exemplary screen that the user can invoke to add a follow-up task to the policy shown to the policy details view.
  • FIG. 16A shows, in accordance with one embodiment of the present invention, the tools available in the QuickView™ module.
  • FIG. 16B shows, in accordance with one embodiment of the present invention, the tools available in QuickCase™, in accordance with one embodiment.
  • FIG. 17 shows, in accordance with one embodiment of the present invention, a workflow for underwriting a policy using iDesktop™.
  • FIGS. 18-22 show, in accordance with embodiments of the present invention, various exemplary views of the Client Tool of the QuickCase™ module.
  • FIGS. 23-27 show, in accordance with embodiments of the present invention, various exemplary views of the Client Tool of the QuickCase™ module.
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • The present invention will now be described in detail with reference to a few preferred embodiments thereof as illustrated in the accompanying drawings. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without some or all of these specific details. In other instances, well known process steps and/or structures have not been described in detail in order to not unnecessarily obscure the present invention.
  • In accordance with one aspect of the present invention, there is provided a scalable, adaptable, modular, and web-centric Insurance Back-Office System (IBOS) for serving the needs of carriers, agencies, agents, and service providers in the insurance industry. The IBOS provides a framework for allowing web-centric collaboration among agents, agencies, carriers, and service providers, using applications that manage applicants, cases, and policies in an efficient and secure manner. To improve user-friendliness, the inventive IBOS leverages on the familiar desktop visual metaphor even though the applications themselves are provided over thin web clients.
  • To promote secure collaboration in the insurance underwriting and management processes, user access to the IBOS is role-dependent. In other words, the data, views, tools, modules, and applications available to a user of the IBOS depend on the role of the user. To clarify, there are currently two broad roles within the IBOS. It is contemplated, however, that as the product evolves, additional roles may also be implemented, and IBOS is designed such that additional roles can be accommodated easily.
  • Currently, a user is either an agent/producer (“agent”) or a case manager. An agent is the person directly interfacing with the insurance buying public, and who is compensated for his effort in selling the insurance product to the public. A case manager, who may work for an agency, a service provider, or a carrier, is an administrative personnel responsible for gathering and processing information to help a case mature into a policy and to manage a policy once in force. Within these two broad categories of roles, the IBOS is also user-specific in that the identity of the user may also be employed to determine the set of applications/modules/tools (collectively “mechanisms”) and the data that he has access to.
  • The role-based feature allows, for example, an agent using the IBOS to employ role-appropriate mechanisms to view/manipulate data related to clients and/or cases/policies. Being also user-specific, the identity of that agent will be employed to ensure that that agent can view/manipulate data associated only with his clients and/or cases/policies but not to view/manipulate data associated with other agents' clients and/or other agents' cases/policies.
  • Likewise, a case manager in an agency using the IBOS can employ role-appropriate mechanisms (which may be the same or different from those employed by the agents) to view/manipulate data related to cases/policies assigned to her for managing in that agency. Being also user-specific, the identity of that case manager will be employed to ensure that that case manager can view/manipulate data associated only with the cases/policies for which she is responsible but not to view/manipulate data associated with cases/policies under the management of other case managers in the same agency or in different agencies. The same feature applies for case managers in service providers or in carriers.
  • Within a case, the user identity and/or role also determines the data that that user can view and/or edit. In other words, a user may have access for viewing to only some data pertaining to a case but not other data based on his user identity and/or role. Likewise, a user may be able to view some data but not edit such data based on his user identity and/or role. As an example, a case manager at a service provider may be able to view selected data pertaining to a case (e.g., the phone number of an applicant for contact purposes) but not others (e.g., the policy limit). As another example, a case manager at a carrier may be able to view certain data pertaining to a case (e.g., the agency in charge of the case) but not edit such information (e.g., cannot change the agency name to another agency).
  • Thus, while all the IBOS users employ thin web clients (e.g., a browser on a desktop, laptop, or palmtop computer or a browser on a PDA/web-enabled phone) to access the IBOS applications, the appearance of the IBOS to a user may change depending on his/her role, and the data available for viewing and/or manipulation is also dependent on his/her identity. This is one way that the IBOS promotes compliance with privacy protection initiatives in the industry as well as with privacy protection regulations such as the federally-mandated HIPAA (The Health Insurance Portability and Accountability Act of 1996) or GLB (The Gramm-Leach-Bliley Act of 1999).
  • IBOS is also context-dependent. A context can be characterized by one or more environmental factors that, in combination, sets the context of operation. For example, role, browser type, organization type (e.g., carrier, agency, or service provider), and others all combine to define a context that in turn defines how the application behaves in terms of the modules/tools/views available and the data accessible to a user.
  • The IBOS is implemented by a multi-layer component architecture, with each layer serving as a container for grouping the modular components associated with the layer below it. In one embodiment, the IBOS is implemented by a five-tier architecture: portal/container, web application, module, tool, and view. These the IBOS architecture components are depicted in FIG. 3. At the highest level is the portal/container level 302. Under portal/container level is the application level 304. Application level 304 includes one or more web-centric applications, some or all of which preferably adopt the web-centric desktop visual metaphor provided by portal/container level 302.
  • With respect to portal/container level 302, the IBOS can be deployed either as a portal hosted by a third-party hosting company or a container/framework for a set of applications, which container/framework is hosted by the company locally at the company's server. The company represents an agency or a service provider or a carrier. The portal model may be an aggregator model or a private-label model.
  • The aggregator portal model is particularly well-suited to the needs of independent insurance agents who may work for multiple insurance agencies. In this aggregator portal deployment model, a third-party hosting company would host the applications, and agents may be able to login via the internet to use the IBOS applications. For example, the agent may type in “http://login.iitcorporation.com/idesktop” on any web browser to access the login page for the iDesktop™ application hosted by the third-party hosting company IIT (whose URL is at iitcorporation.com). Once the user is authenticated and the user's role/identity is resolved, the role-appropriate mechanisms are then provided for viewing/manipulating of user-appropriate data. It is contemplated that the agent may be charged a fee for such use, which may be, for example, a one-time per case/policy fee or a set monthly fee (which may be scaled based on volume if desired).
  • The third-party hosting company may also host the IBOS applications for a particular company, in effect providing hosting services for a private-label version of the IBOS. This is the case, for example, agency ABC or service provider OPQ or carrier XYZ wishes to buy or lease a private label version of the IBOS applications so as to promote their name brand to their users, and contracts with the third-party hosting company to host the set of private-label applications for agency ABC or service provider OPQ or carrier XYZ.
  • In this portal private label model, an agent working for agency ABC may be able may type in “http://login.abc.com/idesktop” on any web browser. The server at abc.com then redirects the user to the third-party hosting company's server in a manner transparent to the agent accessing the IBOS application iDesktop™. Once the user is authenticated and the user's role/identity is resolved, the third party host company server may then serve up a private label version of the IBOS application iDesktop™, which appears to the agent as if it is a IBOS application branded and tailor-made only for the ABC agency. This portal private label model is well-suited to the needs of companies (agencies/service providers/carriers) that may wish to provide private-label access for free for their employees/independent contractors but do not wish to undertake the task of hosting the IBOS themselves. The companies in turn compensate the hosting company (e.g., IIT) for the hosting service and/or for the use of the applications.
  • The company (agency/service provider/carrier) may also lease or buy the IBOS directly for hosting on a server at their site. In this model, the IBOS acts as a container/framework for the leased or purchased applications. This is similar to the portal private label model except that the IBOS (and thus the portal) is now hosted by the company itself.
  • Applications 304 are preferably implemented as web-centric applications that employ the desktop visual metaphor for accessing modules 306. Leveraging on the user's familiarity with desktop interfaces, such as Windows XP™ by Microsoft Corporation of Redmond, Wash., an application 304 may be structured so as to appear as a desktop to the user. FIG. 4 shows, in accordance with one embodiment of the present invention, an example of a IBOS application, iDesktop™, which allows the participants to manage the insurance underwriting process. iDesktop™ functionalities will be discussed in details later herein.
  • In the desktop world, the user accesses the desktop applications by clicking on icons on a toolbar. In FIG. 4, there is a toolbar 402, on which an icon 404 is displayed, signaling that the web-centric IBOS application currently employed is iDesktop™. Icons 406, 408, 410, and 412 represent the icons for activating the modules associated with the active application iDesktop™. This is in keeping with the desktop metaphor wherein the user clicks on the icons on the tool bar to activate desktop applications (whereas in the IBOS world in which the desktop is only a metaphor, clicking on the toolbar icons will activate the modules).
  • Returning to FIG. 3, each application serves as a framework to furnish an infrastructure for plugging in modules. In addition to the aforementioned iDesktop™, other applications exist to serve different insurance management needs. For example, applications directed toward data mining of policy/policyholder data, toward making the client and case intake process more efficient through the use of telephonic or web-based interviews, and the like, may also be accommodated.
  • The remaining of the disclosure will be made with reference to iDesktop™ as an exemplary application. It should be kept in mind, however, that the invention applies to other applications of the IBOS as well. In general, each application 304 such as iDesktop™ includes a plurality of modules to serve different business logic needs. Generally speaking, each business module comprises a set of business logic functions or features, implemented as tools, that maps closely to the entities being managed.
  • To clarify, in the IBOS, data is associated with entities. In iDesktop™, for example, the business data can currently be broadly classified as being associated with one of four entities: client, case, policy, or service order. It is contemplated, however, that other entities may exist and the IBOS architecture can readily accommodate additional entities, if additional entities are desired.
  • In terms of terminology, a client is either a prospective applicant for insurance, an applicant for insurance, or the insured (i.e., policy holder) if the insurance contract is approved and executed. Throughout its lifecycle, the prospective and in-force insurance contract is referred to as a case. Thus, an application for insurance is a case, and so is a pending policy, and so is a policy in-force. A policy is a case after it has been accepted by a carrier for consideration. A policy may be pending policy, which means that the carrier has deemed the case submitted to have enough minimum information to allow the carrier to begin the process of data collection from the service providers and others, of performing risk and premium analysis, and ultimately of approving or rejecting the case. Once the carrier has approved a pending policy and after it is executed by the applicant (and perhaps after the payment of the first premium payment), the pending policy is converted into a policy in force.
  • A service order is an order for service to a service provider from an agent, an agency, another service provider, or a carrier. An example service order may involve, for example, an order for EFG Company to take blood and urine specimens of an insurance applicant for analysis. The classification of all insurance related data as belonging to one of these four entities vastly simplifies the logic model and user model for implementing and using the iDesktop™ application.
  • The application framework also includes infrastructure for security control, access control, authentication and verification (user-login), general administration and setup, and the like. It is preferable that each application includes at least three modules: a user profile module to manage user profiles, a general administration module for handling administrative tasks pertaining to the application such as to manage user accounts, and a business module for accomplishing certain tasks related to insurance underwriting or management. Although this organization makes applications easier to implement and navigate, it is not absolutely necessary in all cases.
  • Modules are configured to be modular, allowing the application to be scalable. For example, iDesktop™ may have seven modules but not all will be required at all times. In fact, modules can be purchased incrementally as need arises. There is, for example, a QuickView™ module for enabling agents and their case managers in an agency to analyze, quantify, and process cases. A QuickCase™ module allows collaboration among agent/agency/service provider/carrier during the underwriting process, up to the time the case is accepted by the carrier and becomes an enforceable policy.
  • Each module 306 implements a plurality of tools. In one sense, a module may be thought of as a container that provides an infrastructure for plugging in modular tools. Both tools and modules are reusable components, allowing the creation of new modules and/or new applications without requiring a complete rewrite of codes. In other words, certain tools and modules are reusable, and different tools may be grouped to form a new module, and different modules may be grouped to form a new application. Tools can be customized by users using preference settings.
  • Generally speaking, there are two types of tools: generic tools and entity-specific tools. A generic tools represents a tool that can exist in more than one module and functions in a substantially similar manner in each of the modules in which it is deployed. Examples of generic tools, which will be discussed in details later herein in connection with the QuickView™ and QuickCase™ modules, are hotlist, followup, report and search. Entity-specific tools are tools specific to entities (of which there are four in the exemplary implementation of iDesktop™). Client tools and service order tools are examples of entity-specific tools in the QuickCase™ module.
  • Each tool 308 may have a plurality of views. Like tools and modules, the views are implemented by code that is modular and also reusable. In most tools, there may be found three views: summary, list, and details. In the case of QuickCase™, a summary view provides an agent with a summary view of the cases he is handling, sorted by some broad criteria (e.g., by carriers). The list view provides, for example, a list of all cases the agent is currently handling. The detailed view provides, for example, the most detailed presentation of data associated with a case undergoing the underwriting process.
  • One important aspect of the invention is the consistency with which new features/product offerings can be developed and user navigation can be accomplished. By classifying all insurance-related data as belonging to one of the entities (e.g., the four entities of the present example: case, policy, client, or service order), tools can be easily developed. By organizing the architecture into a plurality of discrete architecture levels (e.g., five levels as in the present example), with each level representing a container for bundling the modular components associated with the level below it (e.g., a tool is a container for bundling modular views, a module is a container for bundling the modular tools, an application is a container for bundling the modular modules, and a portal is a container for bundling modular applications), development of new features/product offerings is vastly simplified.
  • In many cases, the development of a new feature/product offering comprises deciding which architectural level the new feature/product offering belongs to (e.g., a new application, a new module, a new tool or a new view). Once the appropriate architectural level is decided, new feature/product offering may be formed by bundling existing modular architectural components. If existing modular architectural components do not satisfy all the requirements of the new feature/product offering, new code may be written but only to the extent necessary to supplement the existing bundle.
  • With regard to user navigation, user friendliness is enhanced by leveraging on the desktop metaphor as mentioned earlier. However, navigation is also made consistent in that in an application, users expect to be able to invoke modules by, for example, clicking on the icons in the toolbar as shown in FIG. 4. Within each module, the user will see certain generic tools (e.g., followup, hotlist, search, report) that behave substantially similarly across modules and certain entity-specific module. In one embodiment, within each tool, the user will be presented with certain views (e.g., summary, list, and detailed). This paradigm repeats for all applications, modules, and tools in the BIOS.
  • Preferably, each module is implemented with a given set of menus and tools. In one embodiment of iDesktop™, all modules are implemented with three menus (action, tool, and help), and two access tools (of which search is one access tool and the other may be a hotlist or summary or the like) on its home page. The action menu provides the user with the actions that can be taken with respect to the entities selected (e.g., cases, policies, clients, or service orders). An example of an action may be send an email to all clients selected, or to group all selected cases into a hotlist (note that hotlist is either an action, denoting that a group of cases or policies is to be marked as high priority, or a hot list may be an access tool, causing the group previously designated as a hotlist to be displayed).
  • The tool menu furnishes the user with all the generic and entity-specific tools available in the module. Help provides helpful hints in using the particular module. The search tool, which is one of the access tools visible in the home page of the module, allowing the user to search the entities (e.g., cases, policies, clients, or service orders) according to some predefined criteria. In QuickView™ for example, an agent may search for all his cases that has a policy limit between $750,000 and $1,000,000. Summary, as mentioned before, displays the entities in accordance with some predefined criteria, depending on the preference setting. For example, an agent may use the summary tool to view all cases summaries sorted by agencies, carriers, or service providers.
  • To facilitate collaboration, certain data needs to be shared among the participants of the insurance underwriting/management process. In general, it is preferable that data be encrypted using a highly secure encryption technology (e.g., 128-bit encryption in one embodiment) and using a secure connection technology such as secure socket layer or SSL, (see Internet Engineering Task Force at ietf.org).
  • In one embodiment, the business database (i.e., the database that includes data regarding clients and/or cases/policies) is hosted at a central hub, and carriers, service providers, agencies, and agents may access data at this central hub. This is the case shown in FIG. 5 wherein there is shown, in accordance with one embodiment of the present invention, an iDesktop™ application 502 and 504 executing at servers associated with an agency and a carrier respectively. There is also shown an IIT aggregator iDesktop™ portal 508, representing the aforementioned aggregator portal.
  • There is provided a data hub 510, which is responsible for hosting the business database. Data hub 510 includes an integration server 512, which provides business-to-business (B2B) transaction processing. Integration server 512 may include a web application transactional web engine 520, a data translation engine 522, and a workflow engine 524. The transactional engine 520 sends data to and receives data from iDesktop™ applications 502 and 504 to facilitate underwriting a case and/or managing cases/policies. This same engine may also be responsible for sending and receiving data for business partners (carriers, agencies, and service providers), in effect acting as a middleman to facilitate the data transfer among these partners. It is contemplated that a per-transaction or per-case fee may be charged for this middleman service, which may include services such as data translation and public workflow management (discussed below) and others. The transacted data is consolidated in the hub's database, shown in FIG. 5 as relational database management system (RDBMS) 509.
  • The business data or meta data translation engine 522 translates data and formats data as data is exchanged among agencies, carriers, and service providers. This ensures that the receiving party can receive data in the format that can be easily used and analyzed, thereby eliminating the need for manual transcribing. A business rules engine 526 for managing business rules is shown. The workflow engine 524 in data hub 510 implements public workflows, i.e., workflows among the agents, agencies, service providers, and carriers. A workflow is a bundle of data and subtasks executed in a predefined sequence. An exemplary portion of such a public workflow may include sending an email to notify the agency at the same time that the service provider sends a specimens result to the carrier. The public workflows are handled by the workflow engine at data hub 510 since data hub 510 serves as the hub through which data among the participants may flow and therefore is a natural place for implementing the public workflow logic.
  • Each iDesktop™ application 502, 504, and 508 may also include a private workflow engine ( reference numbers 502 a, 504 a, and 508 a). These workflows are deemed private since they involve data and tasks to be transmitted internally within the participant's organization. An exemplary portion of such a private workflow may include sending an email to both an agent and his case manager, informing both that an application from the agent's client has been examined and another signature is needed before the case can be forwarded to the carrier.
  • Note that in FIG. 5, each of Each iDesktop™ application 502, 504, and 508 is shown interacting with its own web client (which may be through a wired connection as in the case of web client 502 a or a wireless connection, as in the case of web client 502 b). IIT hub 510 is also shown coupled to legacy systems, such as the service providers' own order processing system 527, the agency's own case management system 526, or the carrier's own application underwriting system 525.
  • It is not necessary that the business database be consolidated at a hub database, such as RDBMS 509 of FIG. 5. FIG. 6 shows, in accordance with one embodiment of the present invention, an alternative approach wherein each participant (agency, carrier, service provider) hosts its own business database. Thus, in addition to iDesktop™ 602 a and 604 a, each of agency 602 and carrier 604 can use multiple databases: its own internal or third party application or business database, and a database containing data for collaboration. Using the module QuickView™ as an example, agency 602 also manages an agency database 602 b and a QuickView™ database 602 c. Likewise, carrier 604 also manages a carrier database 604 b and a QuickView™ database 604 c.
  • There is also shown a hub 610, with its own iDesktop™ application 610 a, IIT global general agency database 610 b (also known as IITGA), which contains data pertaining to the plurality of agencies that employ hub 610 to collaborate with service providers and carriers. There is also shown a QuickView™ database 610 c associated with hub 610. Generally speaking, IIT hub refers to the central application and database employed to enable data exchange among IIT network and insurance business partners (such as carriers, agents, agencies, service providers).
  • The collaboration data in databases 602 c and 604 c are synchronized with hub database 610 c using either IIT's data synchronization technology or an industry-standard web services technology. With respect to the carrier-provided data, the data in QuickView™ database (e.g., 610 c or 602 c) includes carrier-provided data pertaining to updates on approved and currently pending policies. This carrier-provided data from the carrier is synchronized with IIT hub (610) to update the QuickView™ database 610 c. Once synchronized, IIT hub 610 then synchronizes the carrier-provided data at the agencies (e.g., in QuickView™ database 602 c) to enable the IIT general agency system (IITGA) 602 d to view the latest carrier-provided data.
  • FIG. 6 also shows a GA-QV integration facility 602 e in agency 602. There are times when the carrier may have its own legacy or third-party software for case/policy management, and the data provided by the carrier may differ in format from that originally provided to the carrier. Furthermore, the carrier may not even employ the case number assigned by iDesktop™. GA-QV integration facility 602 e employs algorithm to match the pending policy provided by the carrier with the case being tracked by iDesktop™ (using for example the applicant name, his address, his birth date, his governmental identification data, and/or the like). Once the match is made, a translation table may be generated to permit correlation between the case being tracked by iDesktop™ and the pending policy tracked by the carrier.
  • Web clients 610 d, 602 f, and 604 d are also shown in communication with their respective iDesktop™ applications. Although only one web client is shown per application, it should be understood that each iDesktop™ application can service any number of web clients, through a local area network, a virtual private network, or through the Internet, or any other data transmitting network.
  • Generally speaking, data translation may be performed at the target server (e.g., the server receiving data such as the server at the carrier, agency, or service provider) or more preferably, data translation may be performed by the IIT hub 510 or 610.
  • As mentioned, iDesktop™ is one application that can be plugged into the infrastructure provided by the IBOS. iDesktop™ allows geographically diverse agents, agencies, service providers and carriers to collaborate in a secure, web-centric environment using the familiar desktop metaphor in order to underwrite and manage insurance policies. It is not necessary that all agents, agencies, service providers, and carriers have a business relationship with one another to employ iDesktop™. Diverse groups of participants can all employ idesktop™, and since iDesktop™ is role-sensitive, context-sensitive, and user-specific, a user of iDesktop™ can only access data for which he is authorized to view and/or manipulate. Thus, the iDesktop™ application can be made available to thousands of business partners, all working on millions of cases in various permutations of working relationships. The role-based, context-based, and user-specific features mean that ownership for accessing cases for viewing and/or manipulating data is well-defined for each case and each business partner working on that case, and there is virtually no risk of a data security compromise on any case.
  • Generally speaking, iDesktop™ can be employed by an independent agent who is not exclusively associated with any agency, by an agent who is exclusive with an agency, by a case manager at an agency, by a case manager at a carrier, or by a case manager at a service provider.
  • FIG. 7 shows, in accordance with one embodiment of the present invention, the sequence for user login and authentication. The user may access the application iDesktop™ (702) by, for example, typing the appropriate URL into a browser. For example, the user may type in “https://iit.idxtop.com:9443” which brings up a login screen. An exemplary login screen is shown in FIG. 8. In the log in screen, the user may either (703) enter his id/password (704) if he is an existing user or may choose to register if he is a new user (706). If he is a new user, the registration process may require the user to identify his role (i.e., agent or case manager) (706 a), to choose a new userID and a password (706 b), and to enter his personal data (706 c) such as name, address, email, government IDs, and the like. The user may also be required to identify data related to the agency/agencies, carrier(s) and service provider(s) which pertain to his work. Once the registration is completed, the user is taken back to the screen where he can enter his userID and password.
  • Once the userID and password are entered, the user (whether new or existing) will be authenticated (712). In one embodiment, authentication is performed using a user database that is separate from the business database. Technologies such as directory server (available from the aforementioned Microsoft Corporation or Sun Microsystems, Inc. of Mountain View, Calif.) may be employed during the authentication process. For a new user, the authentication may involve checking with the carrier and/or service provider and/or agency to ensure that the user is authorized as represented by the user. Part of the checking includes ascertaining the business data (e.g., regarding entities such as clients, polices, cases, and service orders) that the user is allowed to access based on his role and his agency/carrier affiliation.
  • If authentication is successful, the user will be presented with the home page of iDesktop™, which is presented in the desktop metaphor as mentioned earlier. This is shown in FIG. 9. From this home page of iDesktop™ (and indeed from any page from this point onward), the user may then select the module to work on by clicking on the appropriate icon in the toolbar.
  • In the insurance underwriting and management process, two modules are currently employed. However, additional modules may be involved in additional functionalities are desired. QuickCase™ is employed collaboratively among agent, his agency, the service provider(s) and the carrier to create a completed insurance application. Once the application is accepted by the carrier, it becomes a pending policy. At that point, QuickView™ may still be employed to search, view, and annotate the policies with follow-ups and QuickCase™ is still employed to facilitate collaboration if an action is needed from one of the business partners (e.g., from the service providers) to turn the pending policy into a policy in force.
  • In one exemplary implementation of iDesktop™, QuickView™ is the tool employed by the business partners for collaboratively viewing, researching data and status, and annotating (with follow-ups) on the pending policies and the policies in-force. If a business partner discovers that a pending policy requires action to be taken, the client/case/service order tools in QuickCase™ is then invoked to allow the business partners to work collaboratively.
  • QuickView™ may be employed to perform many tasks associated with managing policies. For example, an agent or a case manager may employ QuickView™ to view data pertaining to policies and to annotate policies with follow-up data if desired. As another example, the user (agent or case manager) may also employ QuickView™ to create a hot list of policies for special attention. As another example, the user may employ QuickView™ to search/filter policies available to that user to come up with a search result comprising policies selected in accordance with some search criteria. As another example, the user may create reports on any of the views displayed or on the policies using appropriate reporting criteria.
  • In one embodiment, the following tools are available in the QuickView™ module: policies tool, follow-ups tool, reports tool, hotlist tool, and search tool. Policies tool is employed to view policies. In the policy tool, the following views are available: summary by agency view (all policies for the user organized by agencies), summary by carrier view (all policies for the user organized by carriers), policies view (list of policies for the user), policy details view (the most detailed view available for a policy), policy follow-ups view (all policies earlier designated for follow-up tasks for the user) and policy hotlist view (all policies earlier designated as a hot list for special attention for the user). Followup tool is employed to designate one or more selected policies for a particular follow-up task (e.g., call at 3PM on August 12, email service provider to request a female nurse to examine this applicant, etc.) Reports tool is the report generating utility to create policy reports according to some report generation criteria, which reports may be created in an electronic form or a printed form. Search tool allows the user to search for an entity (case, policy, service order, client) according to the search criteria entered
  • In the QuickView™ module, a page displayed preferably comprises of three main parts: module menus (e.g., action, tools, and help), module tool in focus (e.g., policies tool), and search tool form. FIG. 10 shows an exemplary page displayed when the user is employing the QuickView™ module. In FIG. 10, the search tool form is shown by reference 1002. In the case of FIG. 10, the module tool in focus is the policies tool, which shows the summary of cases (1018) by agencies view. The module menus action, tools, and help are shown by reference numbers 1004, 1006, and 1008 respectively. The summary-by-agencies view, summary-by-carriers view, policies list view, and hotlist views may be invoked by clicking on tabs 1010, 1012, 1014, and 1016 respectively.
  • Preferably, the aforementioned three-part organization stays consistent throughout the various pages of the modules and across different modules (e.g., QuickCase) so as to reduce the learning curve for new users, to render navigation consistent, thereby promoting user-friendliness, and to render the implementation of new modules simple.
  • FIG. 11 shows an exemplary QuickView™ page displaying the summary by carrier view (which is displayed by clicking on tab 1012). FIG. 12 shows an exemplary QuickView™ page displaying the policies list view (which is shown by clicking on tab 1016). The policies list view of FIG. 12 further comprises an option 1202, which allows the user to choose the number of policies displayed per page, an option 1204, which allows the user to manipulate icons to move between pages in the policies list view, and an option 1206, which allows the user to remember the view currently displayed in the page as a search criteria in the search tool. The saved search criteria may be saved with a name, and may be recalled by name at a later time to allow the user to quickly access the data previously displayed. FIG. 13 displays another exemplary policy list view after the user has specified in FIG. 12, using option 1202, that 20 policies are to be displayed per page.
  • FIG. 14 shows an exemplary policy details view, which represents the most detailed display pertaining to a policy. This view may be invoked by clicking on any policy displayed in any of the views displaying one or more policies in a summarized format (e.g., any of the summary views, hotlist view, followup view, search result view, policies list view, and the like). Clicking activates the hyperlink associated with the policy summary data, allowing the page showing the policy details to be displayed.
  • FIG. 15 shows an exemplary screen that the user can invoke to add a follow-up task to the policy shown to the policy details view. The user can arrive at the display screen of FIG. 15 by selecting the follow-up tool 1402 in FIG. 14, for example.
  • As mentioned, iDesktop™ is user-specific. Accordingly, policies viewable by some agents may not be viewable by other agents and/or case managers. iDesktop™ is also role-specific. Accordingly, a case manager may not have some of the views available to agents. For example, a case manager employed with a specific agency would see only cases associated with that agencies. In which case, instead of a summary by agencies view, the case manager may be presented with a summary by agents view or summary by service providers view or summary by carriers view for all the cases assigned to her to manage. As another example, a case manger employed with a carrier would see only cases associated with that carrier. In which case, instead of a summary by carriers view, the case manager may be presented with a summary by agencies view or summary by service providers view for all the cases assigned to her to manage. This is an example of how the role-specific feature of the IBOS both improves efficiency/user-friendliness and promotes data security and confidentiality.
  • FIG. 16A shows, in accordance with one embodiment of the present invention, the tools available in the QuickView™ module 1600. As shown in FIG. 16A, there are four generic tools: search tool 1602, followup tool 1604, hotlist tool 1606, and report tool 1608. There is also an entity-specific tool, which is policies tool 1610. These have been discussed earlier herein.
  • FIG. 16B shows, in accordance with one embodiment of the present invention, the tools available in QuickCase™, in accordance with one embodiment. QuickCase™ may include search tool 1652, reports tool 1654, follow-ups tool 1656, and hotlist tools 1658. As mentioned before, these are generic tools and they function in a substantially similar manner as their counterparts in other modules. In addition, there are three entity-specific tools: client tool 1660, case tool 1662, and service order tool 1664.
  • Client tool 1660 may be employed by the agent to obtain information about a client and build a client profile. With respect to the exemplary workflow of FIG. 17, the client tool may be employed in step 1702 to obtain at least certain preliminary data regarding the applicant for insurance such as his name, his age, and superficial lifestyle data such as whether he smokes or skydives. Case tool 1662 may be employed by the agent to begin filling out data regarding the insurance policy the client wishes to purchase (1704 in FIG. 17). For example, the client may indicate that he wishes to purchase term life insurance for 20 years, with a $1,000,000 limit. During the underwriting process, case tool 1662 may also be employed to view and/or annotate the cases, much in the same manner that policies tools may be employed for policies in QuickView™.
  • Once preliminary client and case data is obtained, the client may also employed the QuickQuote™ tool (1706) to search among carriers for insurance products that fit the requirements of the client and to provide some preliminary premium quote and/or to provide alternative products that may also be of interest to the client. At this point, the agent may associate the case to be underwritten with an agency, if such association hasn't been done as a default (e.g., as in the case where the agent is an exclusive agent of an agency).
  • Suppose the client chooses one of the insurance companies to pursue further. In one embodiment, the case is then assigned with a unique case number in iDesktop™, which subsequently serves as the primary correlation key for correlating all communication and data from various business partners pertaining to this case. If a communication or data is sent from one of the modules of iDesktop™ pertaining to a case, the unique case number is automatically sent along to allow the receiving server to easily correlate all communication and data pertaining to a case. In this manner, the invention advantageously avoids the prior art problem of trying to resolve communication and data pertaining to a case based on data that may be erroneous or duplicative.
  • As mentioned, if a carrier employs a legacy systems that works only with the carrier's own case number, the correlation algorithm may be employed to, for example, match the pending policy as sent back from the carrier with the case being tracked in iDesktop™ (based on, e.g., a combination of applicant name, birthdate, social security number, and the like). Once a match is found, a correlation table may track such mapping to allow the business partners to easily correlate communication and data pertaining to a case when collaborating using iDesktop™.
  • In step 1708, the agent or a clerk at the agency may employ the service order tool 1664 to order services, such as blood or urine tests, from service provider (1710). Ordering service causes the service order tool to send the order, along with relevant data (e.g., contact information for the applicant) to the service provider(s). Furthermore, the agent or clerk at the agency may employ QuickCase™ to send data pertaining to the partially completed case 1712 to the carrier (1714). Service provider 1710 may also employ QuickCase™ to collaborate with sub-contractors (such as laboratories) to obtain analysis service for urine specimen, for example.
  • The service provider 1710 may also employ QuickCase™ to collaborate with the carrier and/or other sub-contracting service providers to furnish the required information to the carrier to allow the carrier to evaluate the pending policy.
  • The agent, agency, and carrier may employ QuickView™ to monitor the progress and status of the case. For example, a case manager at a carrier may employ QuickView™ to ascertain whether all data required from the agency has been received and whether all data required from the service provider has been received timely at the carrier. Tools such as follow-ups, reports, and hot lists may also be employed to manage cases. Likewise, a case manager at the agency and/or agent may employ QuickView™ to track the progress of a case. For example, the agent may designate a case to be one in his hot list, and he may note that it has taken abnormally long for the service provider to provide the urine specimen analysis result to the carrier. The agent may then follow up with the service provider by sending an email or by another alerting/communicating facility within QuickCase™ to request that the urine analysis result be sent as soon as possible.
  • When a business partner completes a business task with respect to a case (e.g., the agency sending a case to the carrier or to the service provider, the service provider obtaining a urine sample and sending the sample to a laboratory for analysis, a carrier receiving a blood sample result from a laboratory or a service provider), that business partner updates status information for the case in iDesktop™. Thereafter, business partners authorized for viewing the case data may readily obtain status/progress information pertaining to the case at any time using, for example, Quickview™.
  • Once all the required information is obtained from the service providers and agent/agency, the carrier 1714 may then either accept the pending policy, which becomes a policy in force (1716) after execution by the applicant or the carrier 1714 may reject the policy and employ QuickView™ to inform the agent/agency of the rejection (1718).
  • FIGS. 18-22 show, in accordance with embodiments of the present invention, various exemplary views of the Client Tool of the QuickCase™ module. In FIG. 18, the QuickCase™ module is activated by pressing on the “book of business” icon 1800 in the tool bar. Notice how the navigation options and visual presentation on the screen 1801 follows the theme of the present example: 3 menus and two active tools. In the present example, the default QuickCase™ has an active Clients and Search Tool. The Clients tool views are shown by 1802. FIG. 19 shows a Clients List view in the Clients Tool.
  • FIG. 20 shows the Clients Details View. The Client Profile Form is shown in 2002, and the user can press icon 2004 to get a print-formatted report of client details. The user can also add client to list of selected items for action (2206). By using one of detail tabs 2008, the user can obtain/access addition data pertaining to the specific client in focus.
  • FIG. 21 shows a Client Followup screen. The list of follow-ups for the client is shown in 2102. The new/updated follow-up form is shown by reference 2104. The screen of FIG. 21 is accessed by selecting New Follow-up tab 2106 shown.
  • FIG. 22 shows a Client Follow-Up List View. All clients with follow-up items are shown in the list 2202. The user can navigate to follow-up detail screen by clicking on the Client name 2204 (since all data shown in iDesktop™ is hyperlinked). By selecting option 2206, the user can select the entity displayed (e.g., client) for follow-up action such as print report, add to hot-list, etc). The search tool form is shown by reference number 2208.
  • FIGS. 23-27 show, in accordance with embodiments of the present invention, various exemplary views of the Case Tool of the QuickCase™ module.
  • As mentioned, agents may employ the Case Tool to create cases for existing or new clients. A new case for a new client may require the gathering of certain data pertaining to the new client via the Client tool first, in one embodiment. The Case tool has, in one embodiment, case summary, case list, and case detail view. As in other iDesktop™ modules of the present example, there are provided search, follow-up, and hotlist tools.
  • The summary view is shown in FIG. 23. This is activated by the summary view tab 2302. The customized drilldown GUI 2304 displays summary of all user cases. The case search tool is again shown by reference number 2306.
  • FIG. 24 shows the Case List view of the Case Tool. The user can choose the number of cases to be displayed per page (2402), and can save (2404) the view as a search criteria to access later, if desired. The columns 2406 are sortable using a preference setting for criteria or by setting options in a popup menu, for example. The case displayed can be selected (2408) for further action, if desired. The case search tool is again shown by reference number 2410.
  • FIG. 25 shows the Case Details View. The Case Profile Form is shown (2502). User can selection option 2504 to get a print-formatted report of the case details. The user can add the case to the list of items (2506). Through detail tabs 2508, the user can access other data pertaining to the case in focus.
  • FIG. 26 shows the Adding New Followup view of the Case Details View. The New Follow-up form is shown (2602). The view of FIG. 26 is accessed by selecting the New Follow-up tab 2604.
  • The Case follow-up view 2700 is shown in FIG. 27. All cases with follow-up items are shown in the list 2702. The user can navigate to follow-up detail screen by clicking on the Case reference number 2704 (since all data shown in iDesktop™ is hyperlinked). By selecting option 2706, the user can select the entity/entities displayed (e.g., client) for follow-up action such as print report, add to hot-list, etc). The search tool form is shown by reference number 2708.
  • Since iDesktop™ is intended to be web-centric, security is an important concern. Security among participants is assured by leveraging on the role-based and context-based feature, enabling a user to only access the subset of data he is authorized to access. Access control includes authentication and validation while all data transfer is preferably encrypted (e.g., 128-bit encryption) using a secure connection (such as SSL). To enhance security, the data related to user access (e.g., the user data base) is separated from the business data, which can only be accessed by the application server through a firewall, using a secure connection. Once the user is authenticated using the access database, the user may employ the application(s) on the application server to access the business data. Both the access database and the business database may also be physically secured in a secure physical location (e.g., a vault).
  • In accordance with one embodiment of the present invention, there is provided a view-state database or table for tracking the current states of the views of various tools. The view-state database is preferably persistent in that the user can log off and the view-state database will remember the states of the various views at log-off. When the user logs in again, the views associated with the various tools are restored. As another example, a user may switch among tools while using QuickView™ or QuickCase™. The view-state database tracks the states of the views of the various tools and if the user returns to the previous tool, the view associated with that tool that was displayed just prior to switching is restored, along with all the data associated with that view. This is useful for insurance agents who deal with constant interruptions from different clients and who may need to be able to switch among tools often.
  • As can be appreciated from the foregoing, collaboration using the web-centric, collaborative IBOS and iDesktop™ application allows information, status, progress and instructions pertaining to a case to be efficiently manipulated, transmitted, tracked, and shared among business partners authorized to view and/or manipulate that case. This solves the problems in the prior art that arise when different participants in the insurance process employs different software to track, process, and transmit information pertaining to a case.
  • Further, the ability for the business partners to employ the collaborative, web-centric IBOS and iDesktop™ application to communicate among themselves to resolve problems (e.g., through emails, notifications or private messenger messages that tie to the unique case number) as well as the ability to easily view a case status and progress at any time renders the insurance underwriting and management processes substantially more efficient.
  • The use of a single unique case number to track a case within iDesktop™ as well as the ability to automatically associate insurance information and instructions sent via iDesktop™ with the unique case number during transmission and receiving times substantially eliminate the problems associated with correlating communication and data to cases in the past.
  • Since the agent can now obtain progress and/or status data pertaining to a case at any given time from any web-enabled device, customer service is substantially improved. The agent can now respond to a customer's request for status with accurate information. The agent can also track the cases, and take action to speed up the conversion of a pending policy to a policy in force (e.g., by sending a timely reminder email to the right party to take the next step in the process), the invention can substantially reduces the amount of time required to underwrite a policy.
  • While this invention has been described in terms of several preferred embodiments, there are alterations, permutations, and equivalents which fall within the scope of this invention. For example, although agents are discussed as being either independent or working exclusively for an agency, the invention also applies to agents who works directly for carriers without agency intervention, either on an independent basis with multiple carriers or exclusively with a carrier. It should also be noted that there are many alternative ways of implementing the methods and apparatuses of the present invention. It is therefore intended that the invention be interpreted as including all such alterations, permutations, and equivalents as fall within the true spirit and scope of the present invention.

Claims (29)

1-3. (canceled)
4. A method for facilitating communication among at least one participant in an insurance-underwriting process, the method comprising:
providing a web-based system for storing and organizing a plurality of data related to the insurance-underwriting process, the web-based system adapted to allow collaboration among the at least one participant via the Internet, the web-based system comprising a first module for creating a case and a second module for tracking the case among the at least one participant after the case has been submitted to a carrier for consideration;
sharing, via the web-based system, the plurality of data among the at least one participant;
wherein the web-based system comprises a multi-layer, modular architecture, the multi-layer modular architecture including a plurality of applications, each application in the plurality of applications including a plurality of modules and employing a desktop visual metaphor for accessing the plurality of modules; and
wherein the at least one participant comprises at least one user, and the web-based system is adapted to restrict the plurality of data accessible to the at least one user based on a plurality of attributes of the at least one user.
5. The method of claim 4, wherein the at least one participant is selected from the group consisting of: insurance carriers, insurance agencies, insurance agents, and service providers.
6. The method of claim 4, wherein the at least one user is selected from the group consisting of: agents and case managers.
7. The method of claim 4, wherein:
each module of the plurality of modules comprises a plurality of tools, and wherein each tool of the plurality of tools comprises a plurality of views.
8. (canceled)
9. The method of claim 7, wherein the plurality of modules are adapted to allow the plurality of applications to be scalable.
10. The method of claim 9, wherein the plurality of modules are purchased incrementally.
11. The method of claim 7, wherein the plurality of modules comprises:
a user profile module;
a general administration module; and
a business module.
12. The method of claim 7, wherein the plurality of tools comprises at least one generic tool and at least one entity-specific tool.
13. The method of claim 12, wherein the at least one generic tool is adapted to exist in a plurality of modules, and wherein the at least one generic tool is adapted to function in a substantially similar manner in each of the plurality of modules.
14. The method of claim 7, wherein the plurality of views comprises:
a summary view;
a list view; and
a detail view.
15. The method of claim 7, wherein the multi-layer, modular architecture is adapted to allow development of new applications, modules, tools, or views.
16. The method of claim 4, wherein the plurality of attributes of the at least one user comprises:
the at least one user's role in the insurance underwriting process;
the at least one user's identity; and
a context in which the at least one user seeks access to the plurality of data.
17. The method of claim 4, wherein the step of sharing the plurality of data further comprises encrypting the plurality of data using a secure encryption technology.
18. The method of claim 4, wherein the web-based system is deployed on a portal hosted by a hosting service provider.
19. The method of claim 4, wherein the web-based system is deployed on a framework for a plurality of applications.
20. A system for facilitating communication among participants in an insurance-underwriting process, the system comprising:
at least one database adapted to store a plurality of data related to the insurance-underwriting process;
at least one server coupled to the at least one database, the at least one server adapted to host a web-based system for allowing collaboration among the participants via the Internet;
at least one client coupled to the at least one server, the at least one client adapted to allow access to the web-based system;
wherein the web-based system comprises a multi-layer, modular architecture, the multi-layer modular architecture including a plurality of applications, each application in the plurality of applications including a plurality of modules and employing a desktop visual metaphor for accessing the plurality of modules; and
wherein the participants comprise at least one user, and the web-based system is adapted to restrict the plurality of data accessible to the at least one user based on a plurality of attributes of the at least one user.
21. The system of claim 20, wherein the plurality of data comprises data related to an insurance client.
22. The system of claim 20, wherein the plurality of data comprises data related to an insurance case or policy.
23. The system of claim 20, further comprising:
a data-translation engine;
a workflow engine;
a web-application-transactional engine; and
a business-rules engine.
24. The system of claim 23, wherein the web-application-transactional engine is adapted to send the plurality of data to, and receive the plurality of data from, at least one application associated with the web-based system.
25. The system of claim 23, wherein the data-translation engine is adapted to translate and format the plurality of data as the plurality of data is shared among the participants.
26. The system of claim 25, wherein the data-translation engine ensures that a receiving party can receive the plurality of data in a preferred format without manual transcribing.
27. The system of claim 23, wherein the workflow engine implements a plurality of workflows comprising a plurality of tasks and subtasks executed in a predefined sequence.
28. The system of claim 23, wherein the plurality of workflows comprises at least one public workflow and at least one private workflow.
29. The system of claim 20, further comprising a view-state database, the view-state database adapted to track a current state of the plurality of views.
30. The system of claim 29, wherein the view-state database is adapted to store the current state of the plurality of views upon log-off of the at least one user.
31. The system of claim 30, wherein the view state database is further adapted to restore the current state of the plurality of views upon log-in of the at least one user.
US10/670,995 2003-09-19 2003-09-23 Techniques for underwriting insurance policies using web-centric insurance management system Abandoned US20090089101A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US10/670,995 US20090089101A1 (en) 2003-09-19 2003-09-23 Techniques for underwriting insurance policies using web-centric insurance management system
US15/369,269 US20170083982A1 (en) 2003-09-19 2016-12-05 Techniques For Underwriting Insurance Policies Using Web-Centric Insurance Management System

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US50453903P 2003-09-19 2003-09-19
US10/670,995 US20090089101A1 (en) 2003-09-19 2003-09-23 Techniques for underwriting insurance policies using web-centric insurance management system

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/369,269 Division US20170083982A1 (en) 2003-09-19 2016-12-05 Techniques For Underwriting Insurance Policies Using Web-Centric Insurance Management System

Publications (1)

Publication Number Publication Date
US20090089101A1 true US20090089101A1 (en) 2009-04-02

Family

ID=40472671

Family Applications (4)

Application Number Title Priority Date Filing Date
US10/670,995 Abandoned US20090089101A1 (en) 2003-09-19 2003-09-23 Techniques for underwriting insurance policies using web-centric insurance management system
US10/669,882 Active 2029-05-29 US8463624B2 (en) 2003-09-19 2003-09-23 Techniques for ensuring data security among participants in a web-centric insurance management system
US10/669,885 Active 2028-11-27 US9916624B2 (en) 2003-09-19 2003-09-23 Techniques for arranging views and navigating in a web-centric insurance management system
US15/369,269 Abandoned US20170083982A1 (en) 2003-09-19 2016-12-05 Techniques For Underwriting Insurance Policies Using Web-Centric Insurance Management System

Family Applications After (3)

Application Number Title Priority Date Filing Date
US10/669,882 Active 2029-05-29 US8463624B2 (en) 2003-09-19 2003-09-23 Techniques for ensuring data security among participants in a web-centric insurance management system
US10/669,885 Active 2028-11-27 US9916624B2 (en) 2003-09-19 2003-09-23 Techniques for arranging views and navigating in a web-centric insurance management system
US15/369,269 Abandoned US20170083982A1 (en) 2003-09-19 2016-12-05 Techniques For Underwriting Insurance Policies Using Web-Centric Insurance Management System

Country Status (1)

Country Link
US (4) US20090089101A1 (en)

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030187703A1 (en) * 2001-12-31 2003-10-02 Bonissone Piero Patrone System for determining a confidence factor for insurance underwriting suitable for use by an automated system
US20030187701A1 (en) * 2001-12-31 2003-10-02 Bonissone Piero Patrone Process for optimization of insurance underwriting suitable for use by an automated system
US20030187702A1 (en) * 2001-12-31 2003-10-02 Bonissone Piero Patrone System for optimization of insurance underwriting suitable for use by an automated system
US20040220838A1 (en) * 2003-04-30 2004-11-04 Ge Financial Assurance Holdings, Inc. System and process for detecting outliers for insurance underwriting suitable for use by an automated system
US20080022002A1 (en) * 2006-07-18 2008-01-24 Jeff Roberts Methods and apparatuses for dynamically enforcing privileges for use during a data collaboration session
US20090048876A1 (en) * 2003-04-30 2009-02-19 Piero Patrone Bonissone System and process for a fusion classification for insurance underwriting suitable for use by an automated system
US20090083077A1 (en) * 2003-09-19 2009-03-26 Hashim Safaa H Techniques for arranging views and navigating in a web-centric insurance management system
US7813945B2 (en) 2003-04-30 2010-10-12 Genworth Financial, Inc. System and process for multivariate adaptive regression splines classification for insurance underwriting suitable for use by an automated system
US7844476B2 (en) 2001-12-31 2010-11-30 Genworth Financial, Inc. Process for case-based insurance underwriting suitable for use by an automated system
US7844477B2 (en) 2001-12-31 2010-11-30 Genworth Financial, Inc. Process for rule-based insurance underwriting suitable for use by an automated system
US20110054884A1 (en) * 2007-09-17 2011-03-03 Capfinder Aktiebolag System for assisting in drafting applications
US8005693B2 (en) 2001-12-31 2011-08-23 Genworth Financial, Inc. Process for determining a confidence factor for insurance underwriting suitable for use by an automated system
US8793146B2 (en) 2001-12-31 2014-07-29 Genworth Holdings, Inc. System for rule-based insurance underwriting suitable for use by an automated system
US20140222885A1 (en) * 2013-02-04 2014-08-07 Uni-B Solutions Llc System for real-time data processing
US9552599B1 (en) * 2004-09-10 2017-01-24 Deem, Inc. Platform for multi-service procurement
US10489859B1 (en) 2013-08-29 2019-11-26 Allstate Insurance Company Life insurance clearinghouse
US10970787B2 (en) * 2015-10-28 2021-04-06 Qomplx, Inc. Platform for live issuance and management of cyber insurance policies
US11514531B2 (en) 2015-10-28 2022-11-29 Qomplx, Inc. Platform for autonomous risk assessment and quantification for cyber insurance policies
US11822767B1 (en) * 2023-03-13 2023-11-21 The Prudential Insurance Company Of America Display tool

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9547415B2 (en) 2007-04-30 2017-01-17 Oracle International Corporation Suite-wide navigation
US8621641B2 (en) * 2008-02-29 2013-12-31 Vicki L. James Systems and methods for authorization of information access
US20130218606A1 (en) * 2011-08-19 2013-08-22 Apptical Corp. System, method, and computer-readable medium for determining an insurance rating class
US20130067345A1 (en) * 2011-09-14 2013-03-14 Microsoft Corporation Automated Desktop Services Provisioning
US10482536B1 (en) 2014-07-09 2019-11-19 Allstate Insurance Company Prioritization of insurance requotations
US11138669B1 (en) 2014-07-09 2021-10-05 Allstate Insurance Company Prioritization of insurance requotations
US11176615B1 (en) 2014-07-22 2021-11-16 Allstate Insurance Company Generation of an insurance quote based on another insurance quote
US11127081B1 (en) * 2014-07-22 2021-09-21 Allstate Insurance Company Generation and presentation of media to users
US10460392B1 (en) 2014-10-27 2019-10-29 State Farm Mutual Automotive Insurance Company Insurance application process providing bound online coverage for life insurance products
US20170124661A1 (en) * 2015-11-01 2017-05-04 Bolt Solutions Inc. Book exchange process
US10679298B2 (en) * 2015-12-03 2020-06-09 Aon Singapore Centre For Innovation Strategy And Management Pte., Ltd. Dashboard interface, platform, and environment for automated negotiation, benchmarking, compliance, and auditing
CN117036056A (en) * 2019-10-30 2023-11-10 博泰车联网科技(上海)股份有限公司 Method, mobile device, and computer-readable storage medium for generating insurance information
CN113326230A (en) * 2019-12-13 2021-08-31 上海汉之光华知识产权服务有限公司 Case state automatic identification and control method, system, electronic terminal and medium
US20230259517A1 (en) * 2022-02-16 2023-08-17 Yeroosha, Inc. Business application process and system

Citations (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5191522A (en) * 1990-01-18 1993-03-02 Itt Corporation Integrated group insurance information processing and reporting system based upon an enterprise-wide data structure
US5428785A (en) * 1990-04-30 1995-06-27 Hewlett-Packard Company Distributed computer system log-on device for storing and retrieving a user's view of objects at log-off
US5867665A (en) * 1997-03-24 1999-02-02 Pfn, Inc Domain communications server
US6304859B1 (en) * 1996-01-16 2001-10-16 Evergreen Group, Incorporated System and method for premium optimization and loan monitoring
US20010030644A1 (en) * 1999-03-30 2001-10-18 Allport David E. Method of controlling multi-user access to the functionality of consumer devices
US20010037223A1 (en) * 1999-02-04 2001-11-01 Brian Beery Management and delivery of product information
US20020002475A1 (en) * 2000-04-13 2002-01-03 Joel Freedman Automated insurance system and method
US20020010679A1 (en) * 2000-07-06 2002-01-24 Felsher David Paul Information record infrastructure, system and method
US20020010598A1 (en) * 1999-12-18 2002-01-24 Johnson Jerome Dale System and method for providing configuration and sales information to assist in the development of insurance plans
US20020032583A1 (en) * 1999-12-18 2002-03-14 Joao Raymond Anthony Apparatus and method for processing and/or for providing healthcare information and/or healthcare-related information
US20020032626A1 (en) * 1999-12-17 2002-03-14 Dewolf Frederik M. Global asset information registry
US20020035488A1 (en) * 2000-04-03 2002-03-21 Anthony Aquila System and method of administering, tracking and managing of claims processing
US20020040312A1 (en) * 2000-10-02 2002-04-04 Dhar Kuldeep K. Object based workflow system and method
US20020046064A1 (en) * 2000-05-19 2002-04-18 Hector Maury Method and system for furnishing an on-line quote for an insurance product
US20020059137A1 (en) * 2000-06-27 2002-05-16 Freeman Douglas K. Online mortgate application processing and tracking system
US20020062367A1 (en) * 2000-01-26 2002-05-23 Debber J. Dale Opportunity tracking information system
US20020065758A1 (en) * 2000-03-02 2002-05-30 Henley Julian L. Method and system for provision and acquisition of medical services and products
US20020116231A1 (en) * 2000-11-06 2002-08-22 Hele John C. R. Selling insurance over a networked system
US20020120776A1 (en) * 2000-12-23 2002-08-29 Eggebraaten Thomas John Computer system, method, and business method for automating business-to-business communications
US20020138306A1 (en) * 2001-03-23 2002-09-26 John Sabovich System and method for electronically managing medical information
US20020188484A1 (en) * 2000-05-19 2002-12-12 Grover Ruth B. Method and system for furnishing an on-line quote for an insurance product
US20020198743A1 (en) * 2001-06-20 2002-12-26 Ariathurai Arjuna A. Network architecture and management system for conducting insurance activities on a network
US6529948B1 (en) * 1999-08-31 2003-03-04 Accenture Llp Multi-object fetch component
US20030065614A1 (en) * 2001-10-01 2003-04-03 Sweeney Joan M. Method and system for rules based underwriting
US20030078816A1 (en) * 2001-09-28 2003-04-24 Filep Thomas J. System and method for collaborative insurance claim processing
US20030093302A1 (en) * 2000-10-04 2003-05-15 Francis Quido Method and system for online binding of insurance policies
US20030144949A1 (en) * 2002-01-25 2003-07-31 Ed Blanch Web-based mortgage broker application
US20030145124A1 (en) * 1999-05-04 2003-07-31 George V. Guyan Method and article of manufacture for component based task handling during claim processing
US20030154403A1 (en) * 2001-08-14 2003-08-14 Keinsley Brian E. Web-based security with controlled access to data and resources
US6618851B1 (en) * 1999-08-31 2003-09-09 Autodesk, Inc. Method and apparatus for state-reversion
US20030182463A1 (en) * 2002-03-25 2003-09-25 Valk Jeffrey W. Dynamic thin client for information management system
US20030195776A1 (en) * 2002-04-10 2003-10-16 Swiss Re Life & Health America Inc. Facultative underwriting system and method
US20030195838A1 (en) * 2000-11-29 2003-10-16 Henley Julian L. Method and system for provision and acquisition of medical services and products
US20030204421A1 (en) * 2002-04-29 2003-10-30 Value Benefits Insurance Agency, Inc. Integrated system and method for insurance products
US20030233260A1 (en) * 2002-06-14 2003-12-18 Reinsurance Group Of America Corporation Computerized system and method of performing insurability analysis
US20040117358A1 (en) * 2002-03-16 2004-06-17 Von Kaenel Tim A. Method, system, and program for an improved enterprise spatial system
US20040186750A1 (en) * 2003-03-18 2004-09-23 Gordon Surbey Method and system for automating insurance processes
US20040225596A1 (en) * 2002-12-30 2004-11-11 Fannie Mae System and method for facilitating delivery of a loan to a secondary mortgage market purchaser
US20050055250A1 (en) * 2003-09-05 2005-03-10 Wolfgang Kopold Methods and systems for computing estimated and actual accruals for a business entity
US6907546B1 (en) * 2000-03-27 2005-06-14 Accenture Llp Language-driven interface for an automated testing framework
US7080020B1 (en) * 2000-01-04 2006-07-18 Employers Reinsurance Corporation Interactive system and method for selling insurance
US7167705B2 (en) * 2003-06-27 2007-01-23 Oracle International Corporation Roaming across different access mechanisms and network technologies
US7181017B1 (en) * 2001-03-23 2007-02-20 David Felsher System and method for secure three-party communications
US7240017B2 (en) * 2001-01-18 2007-07-03 International Insurance Group, Inc. System and method of dispensing insurance through a computer network
US7249038B2 (en) * 2001-07-20 2007-07-24 Employers Reinsurance Corporation Online method for binding automatic type reinsurance
US7333939B1 (en) * 2000-07-21 2008-02-19 Travelers Property Casualty Corp. Method for providing web-based insurance data processing services to users
US7389246B1 (en) * 2000-02-15 2008-06-17 Insweb Corporation Insurance rating calculation software component architecture
US7406427B1 (en) * 2000-09-22 2008-07-29 Accenture Llp Capture highly refined claim evaluation information across multiple web interfaces
US20090083077A1 (en) * 2003-09-19 2009-03-26 Hashim Safaa H Techniques for arranging views and navigating in a web-centric insurance management system

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6157915A (en) * 1998-08-07 2000-12-05 International Business Machines Corporation Method and apparatus for collaboratively managing supply chains
US7343310B1 (en) * 2000-04-28 2008-03-11 Travelers Property Casualty Corp. System and method for providing web-based user interface to legacy, personal-lines insurance applications
CA2423011A1 (en) * 2000-09-22 2002-03-28 Riskclick, Inc. Method and system for automating insurance processes
US20020123898A1 (en) * 2001-03-05 2002-09-05 Marie-Helene Lemay System and method for managing business to business customer extranet
US7222369B2 (en) * 2001-12-20 2007-05-22 Sap Ag Role-based portal to a workplace system
JP2004114650A (en) * 2002-09-30 2004-04-15 Canon Finetech Inc Recorder
CA2510111A1 (en) * 2002-12-16 2004-07-15 Questerra Corporation Real-time insurance policy underwriting and risk management

Patent Citations (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5191522A (en) * 1990-01-18 1993-03-02 Itt Corporation Integrated group insurance information processing and reporting system based upon an enterprise-wide data structure
US5428785A (en) * 1990-04-30 1995-06-27 Hewlett-Packard Company Distributed computer system log-on device for storing and retrieving a user's view of objects at log-off
US6304859B1 (en) * 1996-01-16 2001-10-16 Evergreen Group, Incorporated System and method for premium optimization and loan monitoring
US5867665A (en) * 1997-03-24 1999-02-02 Pfn, Inc Domain communications server
US20010037223A1 (en) * 1999-02-04 2001-11-01 Brian Beery Management and delivery of product information
US20010030644A1 (en) * 1999-03-30 2001-10-18 Allport David E. Method of controlling multi-user access to the functionality of consumer devices
US6906696B2 (en) * 1999-03-30 2005-06-14 Research Investment Network, Inc. Method of controlling multi-user access to the functionality of consumer devices
US7617240B2 (en) * 1999-05-04 2009-11-10 Accenture Llp Component based task handling during claim processing
US20030145124A1 (en) * 1999-05-04 2003-07-31 George V. Guyan Method and article of manufacture for component based task handling during claim processing
US6529948B1 (en) * 1999-08-31 2003-03-04 Accenture Llp Multi-object fetch component
US6618851B1 (en) * 1999-08-31 2003-09-09 Autodesk, Inc. Method and apparatus for state-reversion
US20020032626A1 (en) * 1999-12-17 2002-03-14 Dewolf Frederik M. Global asset information registry
US20020032583A1 (en) * 1999-12-18 2002-03-14 Joao Raymond Anthony Apparatus and method for processing and/or for providing healthcare information and/or healthcare-related information
US20020010598A1 (en) * 1999-12-18 2002-01-24 Johnson Jerome Dale System and method for providing configuration and sales information to assist in the development of insurance plans
US7080020B1 (en) * 2000-01-04 2006-07-18 Employers Reinsurance Corporation Interactive system and method for selling insurance
US20020062367A1 (en) * 2000-01-26 2002-05-23 Debber J. Dale Opportunity tracking information system
US7389246B1 (en) * 2000-02-15 2008-06-17 Insweb Corporation Insurance rating calculation software component architecture
US20020065758A1 (en) * 2000-03-02 2002-05-30 Henley Julian L. Method and system for provision and acquisition of medical services and products
US6907546B1 (en) * 2000-03-27 2005-06-14 Accenture Llp Language-driven interface for an automated testing framework
US20020035488A1 (en) * 2000-04-03 2002-03-21 Anthony Aquila System and method of administering, tracking and managing of claims processing
US20020002475A1 (en) * 2000-04-13 2002-01-03 Joel Freedman Automated insurance system and method
US20020046064A1 (en) * 2000-05-19 2002-04-18 Hector Maury Method and system for furnishing an on-line quote for an insurance product
US20020188484A1 (en) * 2000-05-19 2002-12-12 Grover Ruth B. Method and system for furnishing an on-line quote for an insurance product
US20020059137A1 (en) * 2000-06-27 2002-05-16 Freeman Douglas K. Online mortgate application processing and tracking system
US20020010679A1 (en) * 2000-07-06 2002-01-24 Felsher David Paul Information record infrastructure, system and method
US7333939B1 (en) * 2000-07-21 2008-02-19 Travelers Property Casualty Corp. Method for providing web-based insurance data processing services to users
US7406427B1 (en) * 2000-09-22 2008-07-29 Accenture Llp Capture highly refined claim evaluation information across multiple web interfaces
US20020040312A1 (en) * 2000-10-02 2002-04-04 Dhar Kuldeep K. Object based workflow system and method
US20030093302A1 (en) * 2000-10-04 2003-05-15 Francis Quido Method and system for online binding of insurance policies
US20020116231A1 (en) * 2000-11-06 2002-08-22 Hele John C. R. Selling insurance over a networked system
US20030195838A1 (en) * 2000-11-29 2003-10-16 Henley Julian L. Method and system for provision and acquisition of medical services and products
US20020120776A1 (en) * 2000-12-23 2002-08-29 Eggebraaten Thomas John Computer system, method, and business method for automating business-to-business communications
US7240017B2 (en) * 2001-01-18 2007-07-03 International Insurance Group, Inc. System and method of dispensing insurance through a computer network
US7181017B1 (en) * 2001-03-23 2007-02-20 David Felsher System and method for secure three-party communications
US20020138306A1 (en) * 2001-03-23 2002-09-26 John Sabovich System and method for electronically managing medical information
US20020198743A1 (en) * 2001-06-20 2002-12-26 Ariathurai Arjuna A. Network architecture and management system for conducting insurance activities on a network
US7249038B2 (en) * 2001-07-20 2007-07-24 Employers Reinsurance Corporation Online method for binding automatic type reinsurance
US20030154403A1 (en) * 2001-08-14 2003-08-14 Keinsley Brian E. Web-based security with controlled access to data and resources
US20030078816A1 (en) * 2001-09-28 2003-04-24 Filep Thomas J. System and method for collaborative insurance claim processing
US20030065614A1 (en) * 2001-10-01 2003-04-03 Sweeney Joan M. Method and system for rules based underwriting
US20030144949A1 (en) * 2002-01-25 2003-07-31 Ed Blanch Web-based mortgage broker application
US20040117358A1 (en) * 2002-03-16 2004-06-17 Von Kaenel Tim A. Method, system, and program for an improved enterprise spatial system
US20030182463A1 (en) * 2002-03-25 2003-09-25 Valk Jeffrey W. Dynamic thin client for information management system
US20030195776A1 (en) * 2002-04-10 2003-10-16 Swiss Re Life & Health America Inc. Facultative underwriting system and method
US20030204421A1 (en) * 2002-04-29 2003-10-30 Value Benefits Insurance Agency, Inc. Integrated system and method for insurance products
US20030233260A1 (en) * 2002-06-14 2003-12-18 Reinsurance Group Of America Corporation Computerized system and method of performing insurability analysis
US20040225596A1 (en) * 2002-12-30 2004-11-11 Fannie Mae System and method for facilitating delivery of a loan to a secondary mortgage market purchaser
US20040186750A1 (en) * 2003-03-18 2004-09-23 Gordon Surbey Method and system for automating insurance processes
US7167705B2 (en) * 2003-06-27 2007-01-23 Oracle International Corporation Roaming across different access mechanisms and network technologies
US20050055250A1 (en) * 2003-09-05 2005-03-10 Wolfgang Kopold Methods and systems for computing estimated and actual accruals for a business entity
US20090083077A1 (en) * 2003-09-19 2009-03-26 Hashim Safaa H Techniques for arranging views and navigating in a web-centric insurance management system
US20090083076A1 (en) * 2003-09-19 2009-03-26 Hashim Safaa H Techniques for ensuring data security among participants in a web-centric insurance management system
US8463624B2 (en) * 2003-09-19 2013-06-11 Oracle International Corporation Techniques for ensuring data security among participants in a web-centric insurance management system

Non-Patent Citations (11)

* Cited by examiner, † Cited by third party
Title
Definition, "Corresponding" as downloaded on 2/9/2015 *
IIT Press Relase, "Integrated Insurance Technologies Corporation Launches with Proven Business System Enhancing Efficiencies for Agnencies and Carriers" December 3, 2002 *
Kolban, Neil "MQ and SSL" IBM WebSphere MQ 10/31/2002 *
Myers, Eva "Viewing File Permissions" 6/17/2002 *
Myhre, Robert "Introduction to Networking and the OSI Model" 1/3/2001 from CCNA 2.0 Certfication: Routing Basics for Cisco Certified Network Associates Exam 640-507 *
NAILBA Special Summer Technology Issue, Summer 2001 *
PeopleSoft, "EnterpriseOne B73.3.1 Web-Based Solutions PeopleBook" June 1999 *
Somerset, Lawrence, "Virtual Insurance Companies" March 1999, Lawrence Somerset Limited, www.l-s-l.com *
ZeBU, "ZeBU and AssureNet, Ltd. Announce Strategic Partnership" 5/3/2001 *
ZeBU, "ZeBU Announces the Introduction of AIM QV/GA Integration" 11/9/2000 *
ZeBU, "ZeBU Breaks New Ground with Electronic Application Upload" November 12, 2001 *

Cited By (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7844476B2 (en) 2001-12-31 2010-11-30 Genworth Financial, Inc. Process for case-based insurance underwriting suitable for use by an automated system
US20030187701A1 (en) * 2001-12-31 2003-10-02 Bonissone Piero Patrone Process for optimization of insurance underwriting suitable for use by an automated system
US20030187702A1 (en) * 2001-12-31 2003-10-02 Bonissone Piero Patrone System for optimization of insurance underwriting suitable for use by an automated system
US8793146B2 (en) 2001-12-31 2014-07-29 Genworth Holdings, Inc. System for rule-based insurance underwriting suitable for use by an automated system
US20030187703A1 (en) * 2001-12-31 2003-10-02 Bonissone Piero Patrone System for determining a confidence factor for insurance underwriting suitable for use by an automated system
US8005693B2 (en) 2001-12-31 2011-08-23 Genworth Financial, Inc. Process for determining a confidence factor for insurance underwriting suitable for use by an automated system
US7899688B2 (en) 2001-12-31 2011-03-01 Genworth Financial, Inc. Process for optimization of insurance underwriting suitable for use by an automated system
US7895062B2 (en) 2001-12-31 2011-02-22 Genworth Financial, Inc. System for optimization of insurance underwriting suitable for use by an automated system
US7844477B2 (en) 2001-12-31 2010-11-30 Genworth Financial, Inc. Process for rule-based insurance underwriting suitable for use by an automated system
US7818186B2 (en) 2001-12-31 2010-10-19 Genworth Financial, Inc. System for determining a confidence factor for insurance underwriting suitable for use by an automated system
US8214314B2 (en) 2003-04-30 2012-07-03 Genworth Financial, Inc. System and process for a fusion classification for insurance underwriting suitable for use by an automated system
US7801748B2 (en) 2003-04-30 2010-09-21 Genworth Financial, Inc. System and process for detecting outliers for insurance underwriting suitable for use by an automated system
US20090048876A1 (en) * 2003-04-30 2009-02-19 Piero Patrone Bonissone System and process for a fusion classification for insurance underwriting suitable for use by an automated system
US20040220838A1 (en) * 2003-04-30 2004-11-04 Ge Financial Assurance Holdings, Inc. System and process for detecting outliers for insurance underwriting suitable for use by an automated system
US7813945B2 (en) 2003-04-30 2010-10-12 Genworth Financial, Inc. System and process for multivariate adaptive regression splines classification for insurance underwriting suitable for use by an automated system
US9916624B2 (en) 2003-09-19 2018-03-13 Oracle International Corporation Techniques for arranging views and navigating in a web-centric insurance management system
US20090083077A1 (en) * 2003-09-19 2009-03-26 Hashim Safaa H Techniques for arranging views and navigating in a web-centric insurance management system
US10832177B2 (en) * 2004-09-10 2020-11-10 Deem, Inc. Platform for multi-service procurement
US10049330B2 (en) * 2004-09-10 2018-08-14 Deem, Inc. Platform for multi-service procurement
US9552599B1 (en) * 2004-09-10 2017-01-24 Deem, Inc. Platform for multi-service procurement
US20080022002A1 (en) * 2006-07-18 2008-01-24 Jeff Roberts Methods and apparatuses for dynamically enforcing privileges for use during a data collaboration session
US8296362B2 (en) * 2006-07-18 2012-10-23 Cisco Technology, Inc. Methods and apparatuses for dynamically enforcing privileges for use during a data collaboration session
US20110054884A1 (en) * 2007-09-17 2011-03-03 Capfinder Aktiebolag System for assisting in drafting applications
WO2014120407A3 (en) * 2013-02-04 2015-01-29 Uni-B Solutions Llc A system for real-time data processing
WO2014120407A2 (en) * 2013-02-04 2014-08-07 Uni-B Solutions Llc A system for real-time data processing
US20140222885A1 (en) * 2013-02-04 2014-08-07 Uni-B Solutions Llc System for real-time data processing
US10489859B1 (en) 2013-08-29 2019-11-26 Allstate Insurance Company Life insurance clearinghouse
US10825101B1 (en) 2013-08-29 2020-11-03 Allstate Insurance Company Life insurance clearinghouse
US11348185B1 (en) 2013-08-29 2022-05-31 Allstate Insurance Company Life insurance clearinghouse
US10970787B2 (en) * 2015-10-28 2021-04-06 Qomplx, Inc. Platform for live issuance and management of cyber insurance policies
US11475528B2 (en) 2015-10-28 2022-10-18 Qomplx, Inc. Platform for live issuance and management of cyber insurance policies
US11514531B2 (en) 2015-10-28 2022-11-29 Qomplx, Inc. Platform for autonomous risk assessment and quantification for cyber insurance policies
US11822767B1 (en) * 2023-03-13 2023-11-21 The Prudential Insurance Company Of America Display tool

Also Published As

Publication number Publication date
US20170083982A1 (en) 2017-03-23
US9916624B2 (en) 2018-03-13
US20090083077A1 (en) 2009-03-26
US20090083076A1 (en) 2009-03-26
US8463624B2 (en) 2013-06-11

Similar Documents

Publication Publication Date Title
US20170083982A1 (en) Techniques For Underwriting Insurance Policies Using Web-Centric Insurance Management System
US8374944B2 (en) Method and system for enabling collaboration between advisors and clients
CA2716420C (en) Third party information transfer
US8990834B2 (en) Managing healthcare information in a distributed system
US7860726B2 (en) Method for providing web-based delivery of medical service requests
US8538779B1 (en) Method and system for online secure patient referral system
US20080052113A1 (en) System, method, and article of manufacture for managing a health and human services regional network
US8271346B1 (en) System to format and use electronically readable identification data strings, biometric data, matrix codes and other data to link and enroll users of products and services to roles and rights and fees and prices associated with research protocols linked to said products and services
US8401871B2 (en) Healthcare notification method and system including a healthcare website
US20120246741A1 (en) Universal Medical Records Processing System
US10096063B2 (en) Office management solution
US20030208384A1 (en) Agent appointment process via a computer network
US20090182606A1 (en) System and Method for Facilitating Strategic Contract Audit, Resolution and Recovery
KR20110112495A (en) Medical analysis serve system for medical data
Bizimana E-government Readiness Assessment for Government institutions in Burundi
US20030208363A1 (en) Method of making mass solicitations and referrals
US20090164243A1 (en) Electronic healthcare identification generation and reconciliation
KR101162705B1 (en) Project matching method and system thereof
US20170206606A9 (en) Insurance management systems and methods therefor
CN111465952A (en) Computerized network system for initiating, assisting, auditing and managing communications and documents relating to expertise
KR20060076650A (en) System for reviewing irb and method thereof
US20030236698A1 (en) Method and system for collecting, storing, managing and distributing references using networked computer devices
Osman Examining the fundamental obstructs of adopting cloud computing for 9-1-1 dispatch centers in the USA
TWM607508U (en) Customized appointment system
JP2023122610A (en) Support system, support method and program

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTEGRATED INSURANCE TECHNOLOGIES CORPORATION, CAL

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HASHIM, SAFAA H.;REEL/FRAME:015119/0651

Effective date: 20040220

AS Assignment

Owner name: SKYWIRE IIT ACQUISITION, LLC, TEXAS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INTEGRATED INSURANCE TECHNOLOGIES CORPORTATION;REEL/FRAME:020647/0262

Effective date: 20070126

AS Assignment

Owner name: DOCUCORP INTERNATIONAL, INC., CALIFORNIA

Free format text: MERGER;ASSIGNOR:SKYWIRE IIT ACQUISITION, LLC;REEL/FRAME:021778/0760

Effective date: 20080829

AS Assignment

Owner name: ORACLE INTERNATIONAL CORPORATION, CALIFORNIA

Free format text: IP TRANSFER AGREEMENT;ASSIGNOR:DOCUCORP INTERNATIONAL, INC.;REEL/FRAME:021784/0871

Effective date: 20080901

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION