Source: https://patents.google.com/patent/US8762178B2/en
Timestamp: 2019-05-19 21:09:38
Document Index: 124236173

Matched Legal Cases: ['Application No. 60', 'Application No. 60', 'art 570', 'art 570', 'art 580', 'art 590']

US8762178B2 - System and method for providing global information on risks and related hedging strategies - Google Patents
System and method for providing global information on risks and related hedging strategies Download PDF
US8762178B2
US8762178B2 US11/021,111 US2111104A US8762178B2 US 8762178 B2 US8762178 B2 US 8762178B2 US 2111104 A US2111104 A US 2111104A US 8762178 B2 US8762178 B2 US 8762178B2
US11/021,111
US20050154617A1 (en
2000-09-30 Priority to US24248300P priority Critical
2001-10-01 Priority to US96949301A priority
2003-12-24 Priority to US53278003P priority
2004-09-24 Priority to US10/949,112 priority patent/US20050144114A1/en
2004-12-23 Priority to US11/021,111 priority patent/US8762178B2/en
2004-12-23 Application filed by Advisen Ltd filed Critical Advisen Ltd
2005-07-14 Publication of US20050154617A1 publication Critical patent/US20050154617A1/en
2007-08-09 Assigned to ADVISEN, LTD. reassignment ADVISEN, LTD. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: FORER, EDWARD, RUGGIERI, TOM
2014-06-24 Publication of US8762178B2 publication Critical patent/US8762178B2/en
2016-06-22 Assigned to SAAS CAPITAL FUNDING II, LLC reassignment SAAS CAPITAL FUNDING II, LLC SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ADVISEN LTD.
The present system provides information on risks and related hedging strategies. A plurality of client terminals are coupled to the system, for providing access to the system for accessing information on risks and related hedging strategies. A data aggregation module is configured to store financial and risk related information from a plurality of data sources, including private client data sources and public data sources. An analytical module is coupled to the data aggregation module, and configured to perform benchmarking estimates based on information retrieved from the private client data sources and the public data sources. The benchmarking estimates are performed against the private data and the public data obtained from a plurality of industries.
This application is a continuation-in-part application of U.S. patent application Ser. No. 10/949,112, filed on Sep. 24, 2004 now abandoned, which is a continuation of U.S. patent application Ser. No. 09/969,493, filed on Oct. 1, 2001 now abandoned, which in turn claims the benefit of priority from U.S. Provisional Patent Application No. 60/242,483, filed on Sep. 30, 2000, and which present application also claims the benefit of priority from U.S. Provision Patent Application No. 60/532,780, filed on Dec. 24, 2003, the entirety of which are incorporated herein by reference.
FIG. 1 a illustrates a block diagram of an information management system in accordance with one embodiment of the invention.
FIG. 1 b illustrates a block diagram of various components of a knowledge management module in accordance with one embodiment of the invention.
FIG. 1 c illustrates a block diagram of an information management system in accordance with another embodiment of the invention.
FIGS. 2 a-2 d illustrate block diagrams of various data sources employed by information management system and different interfacing arrangements in accordance with one embodiment of the invention.
FIG. 3 a illustrates a query definition table used by the taxonomy module that defines a query related to a category in accordance with one embodiment of the invention.
FIG. 3 b illustrates a flow chart that defines the guidelines for defining a search query for a given category in accordance with one embodiment of the invention.
FIG. 5 a illustrates a user graphical interface as displayed by the knowledge management system in accordance with one embodiment of the present invention.
FIG. 5 b illustrates an advanced search page in accordance with one embodiment of the invention.
FIGS. 7 a and 7 b illustrate the steps in the workflow provided in response to a user selecting a claims and loss analysis template in accordance with one embodiment of the invention.
FIGS. 8 a and 8 b illustrate the steps in the workflow provided in response to a user selecting a mergers and acquisitions template, in accordance with one embodiment of the present invention.
FIGS. 9 a and 9 b illustrate the steps in the workflow provided in response to a user selecting a renewal of insurance template, in accordance with one embodiment of the invention.
FIGS. 10 a and 10 b illustrate a workspace and more specifically, a key practice portion 304, after a user selects exposure analysis template in FIG. 5 a, in accordance with one embodiment of the invention.
FIG. 11 illustrates a workspace and more specifically, a key practice portion 304, after a user selects client research template in FIG. 5 a in accordance with one embodiment of the invention.
FIG. 12 illustrates a workspace and more specifically, a key practice portion 304, after a user selects new product development template in FIG. 5 a, in accordance with one embodiment of the invention.
FIG. 13 illustrates a workspace and more specifically, a key practice portion 304, after a user selects the reference button of FIG. 5 a, in accordance with one embodiment of the invention.
FIG. 15 is a wireframe for a peer group benchmarking entry as managed by a property and casualty benchmarking module, in accordance with one embodiment of the present invention;
FIG. 16 is another wireframe for a peer group benchmarking entry as managed by a property and casualty benchmarking module, in accordance with one embodiment of the present invention;
FIG. 17 is a wireframe for a benchmarking session benchmarking entry as managed by a property and casualty benchmarking module, in accordance with one embodiment of the present invention;
FIG. 18 is a wireframe for a quartile graph benchmarking entry as managed by a property and casualty benchmarking module, in accordance with one embodiment of the present invention;
FIG. 19 is a wireframe for a histogram graph benchmarking entry as managed by a property and casualty benchmarking module, in accordance with one embodiment of the present invention;
FIG. 20 is a block diagram of various components of administrative efficiency tool module, in accordance with one embodiment of the invention.
FIG. 21 illustrates an exemplary coverage chart for a single period specified by the user, in accordance with one embodiment of the invention.
FIG. 22 illustrates an exemplary coverage chart for a multiple period single insurance program specified by the user in accordance with one embodiment of the invention.
FIG. 23 illustrates an exemplary coverage chart for a single period portfolio insurance view in accordance with one embodiment of the invention.
FIG. 24 illustrates the format that user policy data input module collects insurance information from the user, and the format that illustrates the graphic displays in accordance with one embodiment of the invention.
FIG. 25 illustrates a work space for look up table comparison function in accordance with one embodiment of the invention.
FIG. 26 illustrates an example of a look up table that enables the user to view a treatment of a topic in all available jurisdictions in accordance with one embodiment of the invention.
In accordance with one embodiment of the invention, as illustrated in FIG. 1 a, an information management system 10 enables users to collect and access all data necessary for their business from a centralized location. As such users can perform searches and conduct research. System 10 also enables users to employ additional analytical tools, based on the research they are conducting. System 10 also enables users to employ administrative tools to automate their entire insurance processes.
In one embodiment of the present invention, as illustrated in FIG. 1 a, an overview of the structure of the system includes a user web browser 12 connected to a web server via HTTP or HTTPS connection, through a first fire wall 14. Within the web server area 16 the initial communication is received at a load balancing module 18, which directs web traffic to one of a plurality of web servers 20.
In the case of information retrieval at the request of a user, knowledge management server module 28 connects to a database server module 40, which acts an intermediary between data storage modules 36, 38 and knowledge management server module 28. The database server module 40 searches the appropriate data storage module 36, 38 and retrieves the requested information and sends it to knowledge management server module 28. Although the storage modules appear as single units in FIG. 1 a any amount of actual components used to store aggregated data or client data is within the contemplation of the present invention.
In one embodiment of the present invention, the implementation language of system 10 is Java, running on a Java 1.2x compliant Java Virtual Machine (JVM). Alternatively, Java 1.1x can be used with the option to upgrade to Java 1.2x. The web content is written in JSP (Java Script Protocol), which contains embedded HTML (Hyper-Text-Markup-Language) text along with JSP scripting commands for populating the page with dynamic content. Oracle's PL/SQL (Programming Language/Structured Query Language) is preferably used for database administration purposes on the database server modules. However, any implementation language, which fulfills the requirements of system 10, is within the contemplation of the present invention.
Application server modules 24 serve two primary functions, session management and connection management. Session management is useful for access control and achieving state in an otherwise stateless environment. Connection management is for keeping a pool of resource connections (such as databases), useful for performance reasons. Application server modules 24 maintain the functions involved in managing the applications maintained by the system and providing the interface between the system and web servers 20.
As illustrated in FIG. 1 c, application server 24 is described in more detail. Application server 24 includes presentation services modules 46, business objects module 48, data access layer module 50 in accordance with one embodiment of the invention. Application module 46 is configured to handle presentation services, including: security module, presentation module and the request dispatcher. Business objects module includes: core services, globalization module, connection pool management and session management. Data access layer module 50 includes: database wrapper, workgroup wrapper, knowledge management wrapper, analytical wrappers, transaction service wrappers, and new service wrappers. In addition to these modules the application server modules include direct outside Internet connections to transactional services and news services.
FIG. 1 b illustrates a block diagram of a knowledge management system 28 in accordance with one embodiment of the invention, although the invention is not limited in scope in that respect. As mentioned before, knowledge management system 28 is coupled to users 12 and data sources 30 through 34 via the Internet.
Knowledge management system 28 also includes a concept—clustering module 106 coupled to database unit 37. Concept clustering module is configured to identify top concepts that are present among a group of documents retrieved during a user's research session. Concept clustering module provides information so as to display a specified number of concepts contained and identified within those documents.
FIG. 2 a illustrates a block diagram of various data sources employed by information management system 10. In accordance with one embodiment of the present invention, the data sources are divided into three principal sections, client data 34, semi-public data 32 and public data 30, as illustrated in FIG. 2 a.
Although FIG. 2 a depicts the client data as being stored in separate modules for each different type of information, it is within the contemplation of the present invention to be compatible with clients with data stored in a single ERP system, which would house all of their information.
With regard to client data 34, in one embodiment of the present invention, as illustrated in FIG. 2 b, the client has an ERP system which internally combines the clients data regarding TPA/RMIS, Assets, General Ledger, HR, and other materials. This allows system 10 to upload this data from a single source, thus requiring only a single interface with that client. Policy and Ad hoc materials are usually manually converted.
In another embodiment of the present invention, as illustrated in FIG. 2 c the client has separate XMLs (extensible Markup Language) for each of its data types. Because the client has not already integrated its own data into a ERP. In this case each XML transfer will require a separate port for data transfer to system 10, and possibly requires mapping and translating from the clients XML to system 10 XML.
In another embodiment of the present invention, as illustrate in FIG. 2 d, the client has neither an ERP system or an XML interface to its own data. In this case, a customized interface is developed that maps and translates the client data from the client's proprietary formats to system 10 XML.
FIG. 3 a illustrates a query definition table 160 used by taxonomy module 114 that defines a query related to a category. As illustrated each field in the table relates to a definition of rules that generate a query. As such, each query definition includes a filed that defines the category prefix. Another field of the query definition includes the name of experts who were involved in developing the category and its related search query. A third and forth field define the original category name, and an updated category name correspondingly. Other fields include original category definition and updated category definitions.
A rule (including a sub-rule) returns a score for every document in every category. The score will be between 0.01 and 1.00 (with 1.00 the highest). If a rule scores a document as 0.00 for a given category, it will be ignored. For a simple rule, a document that satisfies the rule will return a score of 1.00. This score can be adjusted by applying a weight to the search terms or by using the MANY modifier, as described below. For purposes of the example of FIG. 3 a, as described below, VQL contains the following classes of operators and modifiers (the use of word in the descriptions below could mean any search term: a word, phrase or sub-rule).
FIGS. 3 a and 3 b describe a simple rule that looks for documents that discuss gambling in Reno, Nev., in accordance with one embodiment of the invention. The rule has been named “Reno_Gambling.” Table 3a can be described in accordance to VQL as follows, although the invention is not limited in scope in that respect.
(1) <SENTENCE>
<CASE><WORD> Reno
<CASE><WORD> Nevada
<CASE><WORD> NV
(2) <ACCRUE>
0.80 <MANY> <THESAURUS> gambling
0.80 <MANY> <THESAURUS> casino
<WORD> blackjack
<WORD> poker
<WORD> craps
<WILDCARD> slot*
<WORD> slot
<STEM> machine
(3) <NOT><ORDER><SENTENCE>
<CASE><WORD> Janet
<CASE><WORD> Attorney
<CASE><WORD> General
FIG. 3 b illustrates a flow chart that defines the guidelines for defining a search query for a given category. Thus, a rule for each category can be written in a search language such as VQL based on the guidelines provided and illustrated in FIG. 3 b.
Initially a team of experts are provided with a file, such as Excel containing worksheet templates in the form of table 160 (FIG. 3 a) for the categories for which they are responsible. Each worksheet is named with the Category_Prefix for the category, and contains a template that is completed so that it may be later converted into a an appropriate language such as VQL. The template already has certain information filled in, such as the definition of each category from the categories listed in taxonomy module 114.
In accordance with one embodiment of the invention during the phase of developing category terms, designers of system 28 consider sample articles and documents that relate to the category. Doing so helps the designers to prepare a substantially complete list of the key words and phrases (and their synonyms) that are found in documents about the category, and givesthem more insight into the structure of these documents, such as how often words and phrases are repeated, how close to each other they are found, etc. This process also helps the designers to identify documents that do not fit within the category but that may be found in a key word search.
In accordance with one embodiment of the invention, at step 172, all relevant key terms and phrases are provided. Various ways to locate relevant articles includes the step of performing a search for documents on the Web, each using a different general-purpose search engine (such as Yahoo and Northern Light), or by going to an insurance news Web site (such as www.AIGonline.com, www.insurancenewsnet.com, www.riskandinsurance.com, www.newsre.com, www.ltcnewsandcomment.com, www.disabilitynews.com, www.insurancejrnl.com, www.claimsmag.com, www.propertyandcasualty.com, www.re-world.com, etc.), based on the defined key terms and phrases. It is noted that certain categories are general purpose, not insurance related, such as “Earthquakes,” and do not require articles with an insurance slant. In accordance with one embodiment of the invention retrieving around five unique articles about each category, provides a sufficient basis for building rules.
FIG. 3 c illustrates a taxonomy table 210, with categories defined in accordance with query definitions explained in reference with FIGS. 3 a and 3 b. Generally, taxonomy table 210 has a field that defines the types of risks the documents retrieved by search module 112 are related. As explained before, such risk types include, among other things, hazard risks, operational risks, financial risks, enterprise risks, and strategic risks. A second field defines the insurance types, such as property, casualty and benefits. A third field relate to various insurance groups. Another field relates to category name and category prefix as described above in reference with FIGS. 3 a and 3 b. The last field includes the category definitions for collection of documents. In accordance with one embodiment of the invention, this last field relates to the query rules developed in accordance with the steps described in accordance with FIG. 3 b.
Contextualization module 104 includes a user profile module 222 that is configured to retrieve the profile of the user navigating through various pages provided by knowledge management system 28. User profile module 222 in accordance with one embodiment of the invention is a table containing various fields relating to the profile. For example these fields in accordance with one embodiment of the invention include, the user's role field 224 that stores the role of the user within the insurance industry, for example, an insurance administrator, a broker or an underwriter. Industry field 226 defines the industry within which the user operates, for example, high technology, construction, real estate, etc. Geography field 228 contains the location of the user, or the location within which the user is active. Insurance products 230 field contains the information representing the insurance products that the user is interested. Finally, exposure/issues of interest field 232 contains the information relating to the types of risk exposures and insurance related issues that the user is interested.
Contextualization module 104 also includes an expert query module 220, which is configured to store search queries that are considered timely or news breaking and have not been defined within taxonomy module 114 yet. Expert query module 220 is periodically and constantly updated in accordance with one embodiment of the invention. Furthermore, expert query module may be maintained with various experts on each related topic, who are constantly recent topics and ground breaking news and define new categories and associated rules to update expert query module 220. These categories and associated query rules are provided in accordance with the same steps explained in reference with FIG. 3 b.
Thus, based on the information provided by user profile module 222, user navigation module 236, expert query module 220, concept extraction module 240, search matrix 246 generates a query string that can be used to obtain relevant information from database 37. It is noted that the query string provided by search matrix 246 includes the categories defined in taxonomy module 114. To this end the searches conducted by search builder 244 employ the same query search rules defined in taxonomy module 114 as explained in reference with FIG. 3 b.
The operation of contextualization module 104 is explained in more detail in reference with FIG. 5 a, which illustrates a sample workspace generated by workspace administrator 102 (FIG. 1 b). As illustrated workspace 300 is displayed to a user who has visited a site provided by knowledge management system 28. In accordance with one embodiment of the invention, workspace 300 is divided into three separate portions, including a search portion 302, a key practice portion 304 and an analytical tool portion 306. It is noted that these portions may change depending on the page the user is visiting within the knowledge management system.
The advanced search option 310 responds by providing an interface page as illustrated in FIG. 5 b. Advanced search page includes a keywords box 320 that enables the user to enter the terms that best describe the desired search. The keyword box allows for Boolean searches, similar to conventional search engines.
Finally category field 332 allows the user to search for information based on the categories defined within taxonomy module 114. The user may restrict the results of a search by taking advantage of these pre-defined categories. By default, the system searches for documents in every category. To restrict a search to a subset of categories, the user can select the option of “select up to 25 categories” radio button. Next, the user clicks on the category for which the search is restricted. Otherwise, the search can be restrict to a set of the available categories or to all of them.
Referring back to FIG. 5 a, search portion 302 also includes in-context preformatted searches as provided by contextualization module 104. Thus, when a user selects expert searches field 312, search builder module 244 retrieves the categories defined and stored in expert query module 220, so as to generate a pre-formatted search query, based on recent topics and issues.
The operation of concept clustering module 106 of FIG. 1 b is now described in more detail in reference with FIG. 6. Generally, concept clustering module 106 is configured to find terms or phrases that are related to a category defined in taxonomy module 114, which have not been previously identified as a related item, within the item list illustrated in table 160 in reference with discussion of FIG. 3 a.
At step 366, module 106 determines whether the correlation between the key terms and phrases are larger than a specified threshold. If so, module 106 provides the key term and phrases to taxonomy module 114 as additional items in category rule table 160 of FIG. 3 a.
Referring back to FIG. 5 a, key practice portion 304 is described in more detail. In accordance with one embodiment of the invention, knowledge management system 28, and specifically work space administrator 102 (FIG. 1), includes options for various predefined projects that are employed by those involved in the insurance industry.
The top section of key practice portion 304, provides three buttons for users to select, such as news button 340, projects button 342 and reference button 344. In response to the selection of the news button, work space administrator 102 retrieves the most recent news form database 37 (FIG. 1). It is noted that in accordance with one embodiment of the invention, the news retrieval function is based on the context, depending on the choice of the search criteria specified by the user as set forth in the search portion 302 of the workspace. Therefore, the news content retrieved may be based on the entire database, or user's profile, or context of a template as described above in reference with FIG. 5 a.
FIGS. 7 a and 7 b illustrate a workspace and more specifically, a keypractice portion 304, after a user selects claims and loss analysis template in FIG. 5 a. As a result, workspace administrator module 102 displays the workflow associated with the claims and loss analysis template. An exemplary workflow as illustrated in FIG. 7 a includes the first step of processing and analyzing claim patterns, followed by the step of normalizing claims and loss experiences. The next step includes deleting divestitures data, followed by the step of adding acquisitions data. The next step includes screening out erroneous data from outside entities, followed by compiling claims and loss data from Internet and insurance records. The next step is inclusion of loss data followed by the step of segmenting data by their type. The next step is extending back claims and loss experience up to five years.
FIG. 7 b illustrates the remaining steps of establishing a projection module followed by generating summaries of projected costs. The last step refers to loss development factors that permit loss projection of claims.
FIGS. 8 a and 8 b illustrate a workspace and more specifically, a keypractice portion 304, after a user selects mergers and acquisitions template in FIG. 5 a. As a result, workspace administrator module 102 displays the workflow associated with the mergers and acquisitions analysis template. An exemplary workflow as illustrated in FIG. 8 a includes the first step of obtaining and reviewing information on a candidate company. A sub step corresponding to this step may be the step of performing company research in accordance with one embodiment of the invention.
The next step includes providing risk management input during acquisition process, with a corresponding sub step of completing a due diligence checklist. The next step includes recommending risk management language for acquisition contract. In accordance with one embodiment of the invention this step includes the steps of enabling the user to conduct contract language search and policy form comparisons. To this end, database module 37 (FIG. 1 b) stores a plurality of contracts corresponding to various issues that may arise during the user's research employing system 28. Workspace administrator 102 provides access to these contracts, based on for example, contract topics, or contract issues represented in various clauses of the contract. Thus, a user is enabled to review a plurality of clauses of prior contracts that have dealt with a particular topic, in order to research the proper language for crafting a new contract.
The next step includes prompting the user to interview candidate CFO, general counsel and the broker to obtain relevant information. The step is followed by the step of evaluating the candidate's insurance risk profile. This step includes sub steps that employ analytical tools provided by analytical module 108 (FIG. 1 b).
FIG. 8 b illustrates the remaining steps in the workflow provided in work space 304 in response to a user selecting a mergers and acquisitions template, in accordance with one embodiment of the present invention. The next step includes analyzing the candidate company's losses. Again, this step includes sub steps that enable the user to employ analytical tools to assess the candidate company's insurance losses.
FIGS. 9 a and 9 b illustrate a workspace and more specifically, a keypractice portion 304, after a user selects renewal of insurance template in FIG. 5 a. As a result, workspace administrator module 102 displays the workflow associated with the renewal of insurance template. This workflow enables the user to carry insurance negotiations in a methodical fashion, from preliminary strategy through binding, including compilation of renewal data, and interaction with underwriters and service providers.
An exemplary workflow as illustrated in FIG. 9 a includes the first step of reviewing risk profile and identifying and evaluating new risks. This step includes the sub steps of obtaining client news and legal research. To this end, database 37 provides documents that contain recent case law and legal commentaries based on the categories related to the client's specifications as stored in taxonomy module 114. The next sub step includes conducting a client industry research, to identify risk trends developing in the client's industry. Again, database 37 provides relevant documents as specified by taxonomy module 114.
The next step includes compiling and updating and screening underwriting data, which includes the sub steps of conducting the application process, performing risk mapping and risk accounting functions. This step is followed by the step of projecting future losses and conducting catastrophe loss analysis, including the sub step of performing a severity Monte Carlo simulation as provided by analytical module 108 (FIG. 1 b).
FIGS. 10 a and 10 b illustrate a workspace and more specifically, a keypractice portion 304, after a user selects exposure analysis template in FIG. 5 a. As a result, workspace administrator module 102 displays the workflow associated with the exposure analysis template. This workflow enables the user to compare its organizational risk management costs, policy limits, coverages and losses to others in the industry using insurance data benchmarks from various sources, such as RIMS, Tillinghast's D&O survey, and ISO statistics.
FIG. 11 illustrates a workspace and more specifically, a keypractice portion 304, after a user selects client research template in FIG. 5 a. As a result, workspace administrator module 102 displays the workflow associated with the client research template. This workflow enables the user to learn how to construct business and financial profiles of current and potential clients, and how to identify significant trends and developments that impact client relationships. The steps included in this workflow include constructing profiles of the client with sub steps of conducting company research, obtaining links to the company and obtaining company hierarchy. This step is followed by the step of constructing a financial profile of the client, and identifying current and prior litigation, so as to asses the company's exposure to various risks, followed by the step of identifying significant trends and developments relating to that company.
FIG. 12 illustrates a workspace and more specifically, a key practice portion 304, after a user selects new product development template in FIG. 5 a. As a result, workspace administrator module 102 displays the workflow associated with the new product development template. This workflow enables the user to identify the pattern for developing a new insurance product, from identification of the new exposure through research of the potential market, and finally to a means for treating the exposure.
FIG. 13 illustrates a workspace and more specifically, a key practice portion 304, after a user selects the reference button of FIG. 5 a. In response, workspace administrator module 102 displays a list of all references contained in or tracked by database 37. This enables the user to access various references in a centralized format.
Referring now to FIG. 14, a block diagram of analytical module 108 is described in more detail. Analytical module 108 includes analytical tools that can be employed by the users when conducting research or performing the workflows specified in key practice portions 304. To this end, analytical module 108 includes an interface unit 490 that is configured to receive data from various tool modules within module 108 and provide that data to workspace administrator 102 (FIG. 1) for display to the user. Analytical module 108 includes an P&C benchmarking module 460, which is configured to perform property and casualty (P&C) benchmarking as understood by those skilled in the art.
It is noted that benchmarking as it is generally understood in the insurance industry refers to comparisons between a company being analyzed and the industry wide average premiums being paid by those other companies in the same industry.
As illustrated in wireframe FIG. 15, a user first selects the peer group selection section and then selects the company upon which to perform the benchmarking analysis. For example, a broker, working with a number of clients may represent a number of different companies. Peer group selection wireframe 15 allows the user to select the company to be analyzed.
It is understood that the option “none” may chosen. In such an instance, rather than compare the aggregated data against a known client company, the resulting data will simply produce an abstract benchmark for the industry according to the below selected criteria.
When performing a benchmarking analysis, the data set to be compared against is preferably drawn from similarly situated companies. For example, the data set is preferably drawn from companies of the same size, in the same location, in the same industry. Furthermore, the data set must be drawn from data on the proper coverage type and further may be tailored to the particular lines of business. This data set is referred to as a peer group and is used as the basis for the benchmarking analysis.
The first operation in setting the peer group is to select the industry to be compared to. In basic situations, the user simply sets the industry selection to the industry of the selected company, or if no company is selected, the industry to be reviewed.
In one embodiment of the present invention, as shown in wireframe 15, the present invention allows the user to set the peer group select from a number of different industries. A number of companies now operate within several areas, deriving revenue from a number of sources that are typically identified as being within different industries. As such, benchmarking against a single industry field may not produce the most useful or even accurate results. In accordance with one embodiment of the present invention, benchmarking module 460 of the present invention allows a user to produce a benchmarking analysis against multiple industries simultaneously.
For example, if the selected company determines that they derive a substantial portion of revenue from manufacturing, but also from banking and real estate transactions, the user can select to benchmark their company against all three industries, so that the peer group data set used for the benchmarking is derived from all three industries, rather than from any one of the three separately. A peergroup wireframe produced by benchmarking module 460, illustrated in FIG. 15, illustrates the user's ability to indicate the benchmarking to be performed against multiple industries.
Furthermore, benchmarking module 460 may preferably facilitate the ability for a user to benchmark not only against multiple industry data but also to select percentages, assigned to each of the industries according to particulars of the user's company. For example, using the above company which derives revenue from manufacturing, banking and real estate transactions, the user may further indicate that the revenue split is 70% manufacturing, 10% banking and 20% real estate. In such an instance, a user using benchmarking module 460 would be allowed to benchmark the premiums against data weighted from all three industries, where the data used for the premium benchmarking is further weighted to corresponding percentages.
After the industries to be compared to are selected, the user selects whether the peer group data set to be benchmarked against is to be derived from public sources only, private sources only or all data sources. After selecting, as illustrated in peergroup wireframe illustrated in FIG. 15, the user then enters which financial metric dimensions are to be used in the benchmarking search. Examples of such metrics dimensions include but are not limited to revenues (default), market cap, assets, employees, net worth, profits or deposits.
These metrics dimensions allow the peer group data set, used to by benchmarking module 460 to be limited not only to the same industry(s) as the companying being analyzed but also allows the data set to be drawn from other companies in the industry fields that are in the same size range with respect to the above selected criteria. These financial metrics dimensions can be set according to predefined sizes/ranges or they can be set manually by the user.
Once the peer group data set for comparison selections are made according to the above description, the counts entry on the peergroup wireframe, show in FIG. 15, indicates the number of companies in the peer group data set that match the above selected criteria and from which the data set will be drawn. A current peer group panel shows all of the selected and calculated information on the left side of the peergroup wireframe for easy review.
Once the peergroup wireframe, illustrated in FIG. 15, is complete, the user selects to progress to the next peergroup wireframe, shown in FIG. 16, in order to select the program criteria for benchmarking module 460. Here the user is prompted with more detailed record of the count of records that match the selected criteria and that will be used as the basis for the data set in the benchmarking process.
The user first is prompted to select the type of coverage to be compared, such as premiums (insurance premium costs), limits (casualty limits) revenue, and retention (The net amount of risk retained by an insurance company for its own account or that of specified others.)
After selecting the type of coverage, held by the members of the peer group to be compared to, the user may also select which Lines of Business (LOBs) that will be used in the benchmark analysis, either all of the selected lines of business or only some of the LOBs. By selecting a particular line of business, the user is able to limit the benchmarking peer group data set to the most relevant members, so that the aggregated data the company is compared are better matched with one another.
The time period, allows the user to determine what time frame the data set should be drawn from for he benchmarking process, allowing the analysis to be used for benchmarking against current types of coverage or to determine how the coverage differs from the historic industry average.
Lastly, the user can set the specific characteristics to limit the size of the peer group data set. Here the characteristics are defined by the coverage types that form the peer group as selected above. But for each characteristics, a limiting range can be set such that the only data is within the range will be included in the peer group data set. For example, if a policy limit comparison is being done, a user may select that the peer group data set be limited to policies with limits of 60 million, +/−25%. In such an instance the peer group data set will be limited to policies with limits of 45 million to 70 million dollars.
It is noted that when benchmarking module 460 of system 10 is used for larger corporations, certain conglomerates have revenue obtained from a number of subsidiaries, in diverse industries, making the assigning of a benchmarking peer group industry impossible. Conglomerates of comparable revenue generally do not have the same industry mix, while companies in the representative industries commonly have significantly less revenue.
In such instances, benchmarking module 460 of system 10 preferably offers users a model that uses policy level data from companies in the representative industries as input into algorithms that simulate the size, risk diversification features, and buying characteristics of conglomerates. Thus, if the conglomerate is vastly large than the rest of the industry the peer group data set can either be aggregated and then scaled up by the model, or alternatively, the data can be scaled up by the model and then aggregated. The model may also employ Monte Carlo simulations to generate an industry peer group of synthetic policies, from which quartiles can be calculated.
Once the peer group selection is completed and the company to be benchmarked is selected, the user then may progress to the benchmarking selection wireframe, illustrated in FIG. 17. Here, if the user selected a company they may limit the benchmarking result to a particular program and/or coverage for that company.
In an analytics section, also shown in FIG. 17, the user selects the information to be shown in the benchmark results, such as premiums, limits, retention, revenue etc. . . . These selections taken from the above selected characteristics from the previous wireframe in FIG. 16, and may be separated according to graph types on which they are more appropriately displayed. The user is also allowed to select from a number of additional graph options. Once all of the selected criteria are set, the user then instructs benchmarking module 460 to produce the graph results.
A first type of graph result is a quartile graph output wireframe, shown in FIG. 18. The graph output contains the company of being analyzed as well as a label containing a number of the selected benchmarking criteria that are reflected on the graph, such as LOB, effective dates, and end dates. The results show the scale, mean value for the data set, and where the analyzed company lies with respect to the aggregated data. In certain situations, where multiple LOBs were selected, benchmarking module 460 may produce multiple quartile graphs as necessary.
It is noted that if the user selected a number of industries to be compared against, benchmarking module 460 of system 10 may generate a separate graph for each industry or it can generate a single graph showing the comparison of the company against the peer group data set aggregated across all of the selected industries.
If the user selected that the results be provided as a histogram, illustrated FIG. 19, the graphic out put again shows in the title the company being analyzed, the LOB being graphed, the effective dates and end dates. The histogram is usually used when a number of time periods are being benchmarked so that fluctuations against the industry(s) average over time can be easily viewed. The results for each time period compare the company's amount (for the selected criteria being benchmarked, such as premiums) as a percentage of the selected industry(s) aggregated data, for each of the selected time frames.
It is understood that the above description of the functions of benchmarking module 460 are intended only as an example of one manner of performing benchmarking analysis within system 10. Any similar benchmarking operation, that includes the same essential features to perform benchmarking analysis within a similar system 2 is also within the contemplation of the present invention.
Also, the graphing selections shown are intended as only one possible example of graphic output and are not intended in any way to limit the scope of the present invention. Any graphic output from a similar benchmarking module, using a similarly formed peer group data set is within the contemplation of the present invention.
Module 108 also includes a company comparison module 462 that is configured to perform comparison of key information of companies specified by the user.
For example, a Loss Triangle report can be utilized to analyze the effectiveness of “back-to-work” initiatives-programs, which are traditionally implemented by many companies to limit Worker's Compensation losses. In addition, Loss Triangle reports can be used to measure the claims handling efficiency of Third Party Administrators (TPA).
FIG. 20 is a block diagram of various components of administrative efficiency tool module 110, in accordance with one embodiment of the invention. Administrative efficiency tool module 110 is configured to provide a plurality of chart drawing functionalities that enable the user to asses various insurance programs. To this end module 110 includes a user policy data input module 516, which is configured to receive all relevant information relating to the insurance coverages of an organization as specified by the user. User policy data input module 516 is coupled to database 37 so that information relating to all users can be stored and employed by knowledge management system 28.
Module 15 also includes a single period insurance analyzer that determines and charts a list of a specified insurance policy of an organization extended over a specified period. FIG. 21 illustrates an exemplary coverage chart 570 for a single period specified by the user. The chart includes various portions that identify the type of insurance coverage, the policy amount, its effective dates, and whether they are retroactive and/or extended. Chart 570 provides the user with a visual summary of all pertinent insurance information of a company within a specified period.
Referring back to FIG. 20, administrative efficiency module 110 also includes a multiple period single insurance analyzer 512, which is configured to provide a visual table that summarizes a single insurance program of an organization within multiple periods. FIG. 22 illustrates an exemplary coverage chart 580 for a multiple period single insurance program specified by the user in accordance with one embodiment of the invention. The chart includes various portions that identify the liability converage for each specified period over many periods, for example, on a yearly basis over a period of five years.
Referring back to FIG. 20, administrative efficiency module 110 also includes a single period portfolio analyzer 514, which is configured to provide a visual table that summarizes the portfolio of all insurance policies owned by an organization over a specified period. FIG. 23 illustrates an exemplary coverage chart 590 for a single period portfolio insurance view in accordance with one embodiment of the invention. Thus, the chart illustrates that for a specified period, the organization has commercial general liability insurance with various sublimits, an environmental liability insurance, a travel accident coverage and a workers compensation coverage.
FIG. 25 illustrates the format that user policy data input module 516 collects insurance information from the user, and the format that illustrates the graphic displays in accordance with one embodiment of the invention.
Referring back to FIG. 20, a look up module 518 is configured to provide various look up functionalities for the user. As such, administrative efficiency tool module includes a captive domicile module 520 coupled to look up table module 518. Captive insurance refers to a subsidiary corporation established to provide insurance to the parent company and its affiliates. A captive insurance company represents an option for many corporations and groups that want to take financial control and manage risks by underwriting their own insurance rather than paying premiums to third-party insurers.
However, many insurance issues, such as captive domicile are governed by various state and federal regulations that vary in each jurisdiction. Look up table module 518, in accordance with one embodiment of the invention, allows the user to retrieve comparison tables, that set forth various rules relating to an issue so the user can asses the benefits and trade offs between each jurisdiction. To this end, FIG. 26 illustrates a work space 304, for look up table comparison function, wherein field 580 is used to state one jurisdiction (eg. Colorado), while field 582 is used to state another jurisdiction (eg. New York). For field 584, the user selects the topics that are available for comparison. In response look up table 518 prepares a corresponding look up table for the two jurisdictions and retrieves the relevant topics in each jurisdiction for display. This feature enables the user to efficiently retrieve regulations relating to an issue and further to compare their treatment in each jurisdiction.
In accordance with another embodiment of the invention, it is possible to select a topic and in response retrieve all jurisdictions that have corresponding regulations relating to that topic. FIG. 26 illustrates an example of a look up table that enables the user to view a treatment of a topic in all available jurisdictions. Thus, for example, a user can select a topic referred to as the name of statute(s) relating to an issue and request the system to identify the corresponding statute in each of the available jurisdictions, as depicted in FIG. 26.
Referring back to FIG. 20, administrative efficiency tool 110 includes a federal insurance laws module 522, coupled to look up table module 518, which is configured to provide look up comparisons, related to federal insurance law topics. Module 110, also includes a state insurance laws module 524, coupled to look up table module 518, which is configured to provide look up comparisons, related to state insurance law topics. Module 110 also includes an international insurance laws module 528, coupled to look up table module 518, which is configured to provide look up comparisons, related to international law topics.
1. A system for providing information on risks and related hedging strategies to a plurality customers, said system comprising:
a server for receiving communications from said plurality of customers each having client terminals, said server configured to allow said plurality of customers' client terminals to access said system for providing and accessing information corresponding to risks and related hedging strategies;
a data aggregation module coupled to said server configured to store both financial information and said information corresponding to risks and related hedging strategies provided by a plurality of data sources, said plurality of data sources including private customer data sources and public data sources, wherein said private customer data sources includes aggregated financial and transaction data from said plurality of customers and wherein said information corresponding to risks and related hedging strategies from said private customer data sources is associated with one or more industries to which said transaction data is applicable;
an analytical module coupled to said data aggregation module, said analytical module configured to perform benchmarking estimates for said plurality of customers using said financial information and said information corresponding to risks and related hedging strategies from both said private customer data sources and public data sources retrieved from said data aggregation module,
wherein said benchmarking estimates for said plurality of customers are based on said financial information and said information corresponding to risks and related hedging strategies from said public data sources as well as said aggregated financial and transaction data supplied from said plurality of customers to said system,
and wherein said benchmarking estimates are performed for each customer of said plurality of customers using combined data from said private customer data sources and said public data sources from a plurality of industries, where each benchmarking estimate for said each customer, among said plurality of customers, is assigned a weighted assessment against a plurality of industries such that said benchmark estimates provided to said each customer are customizably weighted by percentage for comparison against public and private customer data with corresponding industry weighting,
said system configured to generate a benchmarking estimate report for each of said plurality of customers, including said weighted assessment against said plurality of industries.
2. The system in accordance with claim 1, wherein said private customer data sources include asset information corresponding to each customer of said plurality of customers whose information is stored in said data aggregation module, said asset information including one or more of asset categories from a list comprising real estate assets, automobile assets, inventory assets, technology assets and heavy equipment assets.
3. The system in accordance with claim 1, wherein said private customer data sources include legal information, insurance policy information, and claims information.
4. The system in accordance with claim 1, wherein said private customer data sources include financial information selected from the group consisting of payroll and general ledger information.
5. The system in accordance with claim 1, wherein said each customer of said plurality of customers is a subsidiary of a conglomerate, such that said benchmarking analysis more accurately reflects a comparison industry peer group.
said analytical module performs benchmarking estimates against modeled data, said modeled data being an estimated data derived from said private customer data sources and said public data sources.
US11/021,111 2000-09-30 2004-12-23 System and method for providing global information on risks and related hedging strategies Active 2025-04-03 US8762178B2 (en)
US24248300P true 2000-09-30 2000-09-30
US96949301A true 2001-10-01 2001-10-01
US53278003P true 2003-12-24 2003-12-24
US10/949,112 US20050144114A1 (en) 2000-09-30 2004-09-24 System and method for providing global information on risks and related hedging strategies
US11/021,111 US8762178B2 (en) 2000-09-30 2004-12-23 System and method for providing global information on risks and related hedging strategies
US14/305,530 US20140358824A1 (en) 2000-09-30 2014-06-16 System and method for providing global information on risks and related hedging strategies
US10/949,112 Continuation-In-Part US20050144114A1 (en) 2000-09-30 2004-09-24 System and method for providing global information on risks and related hedging strategies
US14/305,530 Continuation US20140358824A1 (en) 2000-09-30 2014-06-16 System and method for providing global information on risks and related hedging strategies
US20050154617A1 US20050154617A1 (en) 2005-07-14
US8762178B2 true US8762178B2 (en) 2014-06-24
ID=34743844
US11/021,111 Active 2025-04-03 US8762178B2 (en) 2000-09-30 2004-12-23 System and method for providing global information on risks and related hedging strategies
US14/305,530 Abandoned US20140358824A1 (en) 2000-09-30 2014-06-16 System and method for providing global information on risks and related hedging strategies
US (2) US8762178B2 (en)
WO2007068881A2 (en) * 2005-12-13 2007-06-21 British Telecommunications Public Limited Company User specific database querying method and apparatus
2004-12-23 US US11/021,111 patent/US8762178B2/en active Active
2014-06-16 US US14/305,530 patent/US20140358824A1/en not_active Abandoned
Features-A review of Lexis-Nexis Intranet Solutions, Roger V. Skalbeck, published May 16, 1999, 7 pages. *
Features—A review of Lexis-Nexis Intranet Solutions, Roger V. Skalbeck, published May 16, 1999, 7 pages. *
US "Business Insurance, Risk Management & Online Resources Spotlight report" Dec. 2000 detailing known software of various ages, hearafter "RMIS". *
US20050154617A1 (en) 2005-07-14
US20140358824A1 (en) 2014-12-04
Dikova et al. 2010 Cross-border acquisition abandonment and completion: The effect of institutional differences and organizational learning in the international business service industry, 1981–2001
US20050203896A1 (en) 2005-09-15 Analyst search engine method and system
Owner name: ADVISEN, LTD., NEW YORK
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:RUGGIERI, TOM;FORER, EDWARD;REEL/FRAME:019673/0273
Free format text: SECURITY INTEREST;ASSIGNOR:ADVISEN LTD.;REEL/FRAME:038984/0597