Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION 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/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
  • G06Q40/08—Insurance

Definitions

• This invention relates to a system for retrieving and processing information related to a specified industry so as to provide subject specific information and analytical tools, for example to the insurance industry.
• the present invention looks to provide advantages over the currently available services by integrating into a single system, the ability to access all of the available information on risk management in any given field by providing a data-base which stores and analyzes risk management data from a large quantity of sources.
• the present invention provides a system and method for information and data aggregation and analysis which provides risk managers, benefits managers, brokers, insurers and other insurance professional to have access to information resources, knowledge management tools, and powerful analytical models needed to increase their " value and productivity.
• the system provides a means for insurance industry professionals, to access current industry trends, financial alternatives and advisory services.
• the system also provides a means for accessing up-to-date portfolio valuations, exposure details and access to the risk environments. This system and method provides users with a novel full spectrum of administrative, information, and knowledge tools.
• the system and method provided is designed for information and data aggregation that allows for the compilation of data for mining and categorization by a knowledge management system, which stores all retrieved information in accordance with categories provided by a categorization engine referred to as a Taxonomy module.
• the process of gathering information extends beyond, traditional on-line sources.
• the system is configured to access private and semi-private databases to gather relevant information from various organizational resources. The stored information can be retrieved in accordance with various embodiments of the invention.
• a contextual ization module is configured to retrieve relevant information, based on various factors, among other things, including the user's profile, and the user's particular task at any time the system is employed. As such, the system dynamically provides relevant information as the user interacts and conducts various tasks.
• the stored information is also analyzed by a concept clustering module, so that various concepts relating to a particular topic can be uncovered and stored.
• the concept clustering module is configured to analyze specific word patterns to uncover concepts that originally were not known to have a relationship with the underlying user's search. These uncovered concepts can be employed to enhance the taxonomy module as the system continues to adapt by increased usage.
• the system provides for various analytical tools that allow users to carry on with highly complex analysis of insurance related topics.
• the range of available analytical tool dynamically varies based on the user's needs and research topics.
• the system provides for a unique interactive workspace that combines the features explained above in a logical manner.
• the system interface provides for various job templates, so as to enable the user's to carry various projects by a template driven task assignments. As the user navigates through the workspace, the range of available information to the user changes, based on the user's profile and navigation pattern.
• Fig. la illustrates a block diagram of an information management system in accordance with one embodiment of the invention.
• Fig. lb illustrates a block diagram of various components of a knowledge management module in accordance with one embodiment of the invention.
• Fig. lc illustrates a block diagram of an information management system in accordance with another embodiment of the invention.
• Figs 2a-2d 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. 3b 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. 4 is a block diagram of a contextualization module in accordance with one embodiment of the present invention.
• Fig. 5a illustrates a user graphical interface as displayed by the knowledge management system in accordance with one embodiment of the present invention.
• Fig. 5b illustrates an advanced search page in accordance with one embodiment of the invention.
• Fig. 6 illustrates a concept clustering process in accordance with one embodiment of the invention.
• Figs. 7a and 7b 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. 8a and 8b 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. 9a and 9b 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. 10a and 1 Ob illustrate a workspace and more specifically, a key practice portion 304, after a user selects exposure analysis template in Fig. 5a, 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. 5a 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. 5a, 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. 5a, in accordance with one embodiment of the invention.
• Fig. 14 is a block diagram of various components of an analytical module in accordance with one embodiment of the invention.
• Fig. 5 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.
• 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. 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. 19 is a wireframe for a histogram graph benchmarking entry as managed by a property and casualty benchmarking module, in
• 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.
• 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. Also, system 10 provides an information and data aggregation capability that allows for the compilation of the data for mining and categorization by a knowledge management module. The combination of these services in conjunction with the formed partnerships with current on-line service offerings make the present invention a unique and novel approach to the providing of full spectrum administrative, information and knowledge tools'.
• 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.
• a load balancing module 18 which directs web traffic to one of a plurality of web servers 20.
• web server 20 directs communications through a second firewall 22 and into the main processing and data storage area of the system. Communications are first received at an application server module 24.
• An LDAP (Lightweight-Directory-Access- Protocol) server 26 is attached to application server modules 24 to control login applications of the clients. After the communications are processed by application server module 24, the communications are directed to a knowledge management server module 28.
• LDAP Lightweight-Directory-Access- Protocol
• Knowledge management server module 28 maintains control over the flow of information into and out of system 10.
• knowledge management server module 28 is connected to the Internet and thus to public data sources 30, semi-public data sources 32 and client data sources 34. These data sources provide information via Internet to knowledge management server module 28, so as to store processed information in data storage units 36 and aggregated data storage units 38.
• 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.
• system 10 includes a system wide server configuration with conventional storage systems for data storage and access that satisfies the load and bandwidth requirements.
• storage systems include Storage Area Network (SAN) and Network Attached Storage (NAS).
• NAS refers to the use of a large amount of fiber channel RAIDS (Redundant Array of Independent Disks) on a system and sharing the data either through NSF (Network File System) or database access.
• RAIDS Redundant Array of Independent Disks
• NSF Network File System
• the network is organized as RAID 5, to support the transport of and access to the large data sheets.
• the operating system of system 10 uses any operating system, which meets the system's requirements.
• the operating system is a UNIX operating system.
• the implementation language of system 10 is Java, running on a Java 1.2x compliant Java Virtual Machine (JVM).
• Java l.lx 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.
• JSP Java Script Protocol
• HTML Hyper-Text-Markup-Language
• Oracle's PL/SQL Programming Language/Structured Query Language
• web server area 16 consists of multiple web servers 20 with the flow of traffic controlled by way of a load-balancing module 18.
• Web server area 16 is preferably disposed between first and second firewalls 14, 22 such that web server area 16 is separated from outside web traffic by way of first firewall 14, and it also separated from the system hardware by way of second firewall 22.
• First firewall 14 allows only HTTP, HTTPS, S-HTTP, and FTS (File Transfer Protocol) through to web server area 16.
• Second firewall 22 allows only IP addresses of web servers 20, possibly routing requests from a single user to same web server 20 to simplify session management.
• a servlet (not shown) works to interface between web servers 20 and application server modules 24 in JSP (Java Script Protocol).
• 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. lc, 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.
• the application server modules include direct outside Internet connections to transactional services and news services.
• Fig. lb 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.
• knowledge management system 28 is . coupled to users 12 and data sources 30 through 34 via the Internet.
• System 28 includes a search engine 1 12 that is configured to search information based on search queries provided to it.
• Search engine 1 12 includes a data aggregation module 1 16, which is configured to access various type of data sources, such as sources 30, 32 and 34.
• a taxonomy module 114 is coupled to search engine 112. Taxonomy module 114 is configured to store a list of categories related to the information collected and maintained by knowledge management system 28, as will be explained in more detail in reference with Fig.3 and Appendix I.
• Taxonomy module 114 is coupled to a database 37, which includes aggregated database 38 and client data storage 36.
• Database 37 stores filtered information as processed via taxonomy module 1 14.
• Knowledge management system 28 also includes a contextualization module 104, which is configured to conduct contextual and role based searches as will be explained in more detail later in reference with Fig. 4.
• Contextualization module 104 generates search queries corresponding to, among other things, the user's profile and user's navigation through the system, such as the page type that the user is viewing, and the prior page the user was viewing.
• Contextualization module 104 is configured to store all search queries created dynamically during a user's session with knowledge management system 20.
• Knowledge management system 28 also includes a concept- clustering module 106 coupled to database unit 37.
• Knowledge management system 28 also includes an analytical module 108, coupled to database unit 37.
• the analytical module is configured to perform various analytical functions, such as property and casualty benchmarking, company comparisons, insurance financial analysis, league table calculations, risk mapping, risk accounting, claims data, loss triangles, loss development analysis, severity Monte Carlo simulations, financial modeling of cost structure, safety administration reports, engineering reports and financial summary links.
• Knowledge management system 28 also includes an administrative efficiency tool module 110, which is also coupled to database unit 37.
• the administrative efficiency tool module is configured to provide a plurality of chart drawing, functionalities that enable the user to asses various insurance programs, as will be explained in more detail in reference with Fig. 15.
• Module 110 also includes a look-up table processor that enables users to compare various insurance related characteristics in different given jurisdictions.
• module 1 10 can provide a look-up chart to a user that desires to compare the rules and regulations relating to captive domiciles arrangements in various jurisdictions, displaying the requirements in each jurisdiction.
• the look-up processor module is an effective and powerful research tool that provides comparison analysis to users.
• Knowledge management system 28 also includes a workspace administration module 102 that is coupled to contextualization module 104, concept clustering module analytical module 108 and administration efficiency tools module 110.
• Workspace administration module 102 is configured to control user interface functionalities, including the display of various workspaces on users' terminals, and tracking users' navigation throughout the workspace, dividing the user's terminal into various display portions with corresponding group of interactive commands for users to employ, as will be discussed in more detail.
• Fig. 2a illustrates a block diagram of various data sources employed by information management system 10.
• the data sources are divided into three principal sections, client data 34, semi- public data 32 and public data 30, as illustrated in Fig. 2a.
• Client data 34 consists of information derived from the client's own records used to create a client specific database.
• client data 34 is also used to create a collective client information database 36.
• system 10 also collects client data not only in a standard client data database, but also it creates a collective database, based on the aggregated data of all clients of the system.
• the data collective client information database 36 is striped of all client proprietary and confidential material. Therefore database 36 provides an additional source for clients and the system analysts to use for comparisons.
• Semi-public data 32 includes but is not limited to information consisting of news, AM best, litigation, financial (OneSource), Regulatory, (BNA or CCH) case law, corporate SEC (EDGAR), IRMI, NCCI, RMS, and BAI.
• Public data sources 30 include non-deterministic web data and deterministic web data, captured through the use of a commercial web crawler agent.
• Fig. 2a 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.
• 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.
• 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.
• the client has neither an ERP system or an XML interface to its own data.
• a customized interface is developed that maps and translates the client data from the client's proprietary formats to system 10 XML.
• system 10 the use of a standard XML (Extensible Markup Language) interface that insures continuity in the client data storage modules.
• An example of an XML that uses standard XML format is the IFX (Interactive Financial Exchange) developed by by ACORD.
• the EDI (Electronic Data Interchange) specification is called Automation Level 3 (AL3), with mapping between itself and the XML specifications.
• A3 Automation Level 3
• Other XMLS modules which can operate in system 10 to properly store client data is within the contemplation of this invention.
• system 10 communicates with data storage modules via (JDBC) Java Database Connectivity, as well the use of an object to relational mapping tool for avoiding SQL (Structured Query Language) in the application code.
• JDBC Java Database Connectivity
• object to relational mapping tool for avoiding SQL (Structured Query Language) in the application code.
• system 10 provides the ability for users to share data and track tasks. In the insurance industry, data is often shared between client and broker and within the client organization via paper or verbal communication. The present invention provides an electronic medium for more efficient communication through the use of a workgroup/workflow or collaboration software tool 48.
• System 10 provides the capability for implementing insurance recommendations, to track the recommendation form to its introduction through the client modifications to the impact on risks and insurance.
• search engine 112 is configured to locate information on specific topics from web sites on the Internet, and other semi-public and private sources as explained before.
• system 28 employs search engine 1 12 to search all available resources for any topic related to the insurance industry.
• Typical search engines include those provided by Inktomi, WebRefiner and Google.
• taxonomy module 114 which categories each document based on categories contained in the taxonomy module.
• the categories in the taxonomy module are related to the types of products that business, organizations and individuals desire to hedge associated risks. These risk, include among other things, hazard risks, such as property and casualty losses; operational risks, such as breakdown in business processes or operations; Financial risks, such as capital market fluctuations, or loan defaults; and strategic risks, such as product marketing failures, or new product development failures.
• taxonomy 114 includes approximately 300 insurance-related categories.
• taxonomy 114 may expand over time. Although the taxonomy has more than one level (it is hierarchical, not flat), “categories” are only defined at the lowest level (the “leaves” of the "tree”). Higher levels of the taxonomy are only used for organizational purposes. Thus, for example, if a taxonomy had a hierarchy: Level 1 Level 2 Level 3 Sports Baseball Minor League Baseball Major League Baseball Football College Football • Professional Football
• taxonomy module 114 is overlapping, not orthogonal. Thus, a low-level category could fit into more than one place in the hierarchy.
• the taxonomy could include the following high-level categories: "Sports” and “Education,” and “College Football” would fall into both categories (either directly or indirectly).
• search engine 1 12 As documents are fed into system 28 via search engine 1 12, they are analyzed and classified into one or more of the categories in the taxonomy. For each category a corresponding rule is created in accordance with one embodiment of the invention.
• rule-based queries For example, a simple rule could be (in lay terms): "If the word 'environmental' appears in the same sentence as the word 'contamination' in a document, classify the document in the Environmental_Contamination category. Because the taxonomy module in accordance with one embodiment is focused solely on insurance, a category may bear a close relationship to other categories (for example, long-term disability insurance and short-term disability insurance). For this reason, when developing rules, it is necessary to clearly differentiate each of the categories, in order to minimize potential overlaps. In accordance with another embodiment of the invention, insurance domain experts develop the substantive foundation for the creation of rule-based queries.
• rule-based queries utilize a Boolean like structure and proprietary grammar, which "define" which documents should be classified in which categories.
• a rule states that if a document contains certain words or phrases then it should be included in a given category.
• each query includes a method for ranking documents by giving each document a numeric confidence rating. This ranking method may include giving greater (or lesser) weight to the existence of certain terms and phrases, and also giving greater weight to the number of appearances each term and phrase makes in a document.
• numeric threshold which only permits a document to be returned to the user if the document's confidence rating exceeds the threshold.
• Other, more generalized considerations also must be taken into account, which varies from category to category. For example, it may be preferable to risk returning many "irrelevant” documents in order to ensure that as many "relevant” documents as possible are returned (this is known as “recall”). Alternatively, it may be preferable to risk not returning many "relevant” documents so that minimum number of "irrelevant” documents are returned (this is known as "precision").
• Verity Query Language is the language that is used to create the rule-based queries that are utilized by taxonomy module 1 14, to analyze and classify documents.
• Fig. 3a illustrates a queiy 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.
• Query definition table 160 also includes an item section, which contains all the keyterms and phrases relevant to a category. For each item, a field is provided that identifies the category number. Another field specifies whether a term should be used in its exact format. Yet another field specifies whether the term is case sensitive. Another term specifies whether multiple incidents of the same term exist in the document. Another field specifies the weight associated with a document because of presence of a corresponding term. Another field defines the terms.
• Query definition table 160 also includes a parts section, which divides the items into logical parts, each part defining a relationship among its member items. Finally, query definition table 160 includes a structure section that defines a rule governing the relationship of the parts defined in the part section. Each query may be composed of the following:
• 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).
• WORD word- The WORD operator checks whether the document contains an exact match for word.
• STEM word The STEM operator checks whether the document contains word and its variations (such as plurals, different verb tenses, etc.).
• WILDCARD word* The WILDCARD operator checks whether the document contains word as well as any word which has word as its prefix, such as "disab*", which would match "disability,” "disabled”, etc. (Other wildcards are permitted, such as ?, which allows a variation for any single character, etc.)
• THESAURUS word The THESAURUS operator checks whether the document contains word as well as certain predefined synonyms of word. Proximity Operators
• NEAR [word ] , word2...] The NEAR operator checks whether the document contains both wordl and word2 (and any other listed words). If all search terms are located, a score is returned based on how close together in the document the listed words are (the closer together, the higher the score).
• NEAR/N [wordl, word2...] -
• the NEAR/N operator is similar to NEAR, except the listed words must be within N words of each other for the document to match.
• NEAR if all search terms are located (within N words of each other), a score is returned based on how close together in the document the listed words are.
• PARAGRAPH [wordl, word2...] -
• the PARAGRAPH operator checks whether the document contains both wordl and word! (and any other listed words) in the same paragraph. Due to limitations on the format of the documents being fed into our system, a paragraph is simply a certain number of words and not a true paragraph.
• PHRASE [wordl, word2...] - The PHRASE operator checks whether the document contains both wordl and word! (and any other listed words) in the same phrase, meaning one directly after the other.
• OR [wordl, wordl...] - The OR operator checks whether the document contains either wordl or word2 (and any other listed words). Unlike ANY, the score returned by OR may be adjusted based on the weight given certain search terms and the number of times (using MANY) certain search terms are found in the document. ACCRUE [wordl, w ⁇ rd2...] - The ACCRUE operator checks whether the document contains either wordl or word2 (and any other listed words). Unlike ANY, the score returned by ACCRUE may be adjusted based on the weight given certain search terms and the number of times (using MANY) certain search terms are found in the document. Unlike OR, the score returned by ACCRUE is further adjusted by the number of terms on the list that appear. Thus, if three words are searched for, documents containing all three words will score higher than documents containing less than three, although documents that contain any of the terms will always return a score above 0.00. Modifiers
• the MANY modifier checks whether the document contains word and, if ' so, returns a score based on the density of that word in the document (i.e., the number of times the word appears divided by the length of the document). Thus, the more times a word appears, the higher the score. If two documents contain word the same number of times, the shorter document will get a higher score, because the word density is greater.
• NOT word/operator The NOT modifier will exclude a document if it contains word or the search operator that follows.
• ORDER [wordl, word2...] -
• the ORDER modifier checks whether the document contains both wordl and word2 (and any other listed words) in the order provided, although not necessarily one right next to the other. This is typically used with a proximity operator, to ensure both that a certain order is followed and that the words appear near each other.
• a weight can be applied to sub-parts of a rule to affect the overall score given a document.
• the weight can be any number between 0.01 and 1.00. By default, the weight of most items is 1.00, but the elements searched for by ACCRUE have a default weight of ⁇ .5.
• Example of a Simple Rule Figs. 3a and 3b describe a simple rule that looks for documents that discuss gambling in Reno, Nevada, 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.
• Search term (1) is a sentence that includes the word “Reno” with initial cap and either the word “Nevada” with initial cap or "NV" in all caps.
• Search term (2) contains a list of gambling terms. We have provided greater weight to terms such as “gambling” and “casino” (the default weight is .50, we have provided a weight of .80) over more specific forms of gambling. Also, documents that mention “gambling” or “casino" more often will be given a greater weight than those that mention it less often, through the MANY modifier.
• search term (3) specifies that documents not only need to contain gambling terms and a reference to Reno, Nevada, but they may not contain a reference to the word "Janet” with initial cap or the phrase “Attorney General” with initial caps, followed by the word "Reno” with initial cap, with both in the same sentence.
• Fig. 3b illustrates a flow chart that defines the guidelines for defining a search query for a given category.
• a rule for each category can be written in a search language such as VQL based on the guidelines provided and illustrated in Fig. 3b.
• a team of experts are provided with a file, such as Excel containing worksheet templates in the form of table 160 (Fig. 3a) 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.
• Taxonomy module 114 begins at step 170 to receive a category name from taxonomy category definitions. For each category, the following steps are taken 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.
• 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 r 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.
• retrieving around five unique articles about each category provides a sufficient basis for building rules. Furthermore a list of all relevant synonyms for the defined terms and phrases are created at step 174. Variations of th « key terms that are not readily apparent (different verb endings for verbs, plurals for nouns, and adjectival and adverbial formats of nouns are all considered to be apparent) are also noted at step 174.
• step 176 all documents based on terms generated at step 174 are retrieved. At step 178, those documents , which do not fall into the category are considered.
• the documents are analyzed to determine whether there are any words or phrases that might appear in such "irrelevant" documents (but not in “relevant” documents), which would provide a basis for excluding such documents from the category. For example, a search for documents about Reno, Nevada could search just for the initially capitalized word “Reno,” but this would likely also include documents about Janet Reno. Thus, the search could be enhanced to exclude any documents that contain the word "Janet” or the phrase "Attorney General” in the same sentence as the word "Reno” as illustrated in steps 180 and 182.
• Next key terms, which should be searched for in a case sensitive manner are preferably considered at step 184. This would include proper nouns (company names, place names, people) and abbreviations.
• words or phrases that need to be searched for in the exact spelling format are considered(for example, no plurals for nouns) at step 186. If exact spelling is not specified then a STEM, THESAURUS or WILDCARD search will be performed on the item.
• step 188 whether a document should be ranked higher is considered, because certain words or search terms appear multiple times in the document. Also whether any words or search terms should be given a higher (or lower) weight than others is noted. For example, if a document would match if it includes any of four gambling words, such as "poker,” “slots,” “blackjack,” and “roulette,” the word “slots” may be given less weight, because "slots" can have a meaning besides a gambling device or game.
• a weight for each of these terms on a scale of 1 (lowest) to 10 (highest) is provided .
• poker, blackjack and roulette might each get a 10, and slots 5.
• the "Weight" value remains blank.
• the items are consolidated into parts, identifying each group with a letter. This may only be necessary for a search with many sub-parts. For simpler searches, each item is treated as a part. For example, many items are synonyms for each other. These items are put in a part indicating that "any" of them would be useful, and as such are noted by a number.
• a part and a corresponding proximity criteria is noted (such as the maximum number of words that should separate the items, that they should be in the same sentence or paragraph, or simply that the closer the terms are in a document, the better). Also whether the order of the terms is important and the order itself is indicated.
• the relationship of the parts to each other is noted at step 192. Parts that must appear in conjunction with other parts are noted (for example, "Reno, Nevada” must appear with “gambling”). If a conjunction is required, whether the proximity of these parts matter is noted. Also, whether the order of the parts matter is noted. Furthermore, whether the existence of a part in a document indicates that the document should be excluded from the search is noted.
• each rule is considered so as to whether the search terms should be broken up for greater accuracy.
• two (or more) completely unrelated search terms can be employed to classify documents in the same category.
• Figure 3c illustrates a taxonomy table 210, with categories defined in accordance with query definitions explained in reference with Figs. 3a and 3b.
• taxonomy table 210 has a field that defines the types of risks the documents retrieved by search module 112 are related.
• 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. 3a and 3b.
• 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. Thus, each document retrieved by search engine 1 12 is filtered in accordance with the category rules defined in taxonomy module 1 14.
• contextualization module 104 is configured to provide relevant research information as a user navigates through various screens provided by knowledge management system 28 via its workspace administrator module 102. Contextualizatoin module 104 dynamically builds search queries that retrieve relevant information. 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.
• 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.
• 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 a user navigation table 236, which is configured to track the navigation of the user within the workspace provided by knowledge management system 28.
• user navigation module 104 includes a field or a buffer user workspace selections 238 that is configured to store every location within the workspace navigated by the user.
• contextualization module 104 has access to information relating to the current and prior location of the user's navigation.
• Contextualization module 104 also includes a concept extraction module 240, which is configured to identify top concepts relating to the documents retrieved in connection with a user's research. Concept extraction module 240 operates such that various concepts relating to a particular topic are uncovered and stored.
• Concept extraction module 240 analyzes the text or document that is being viewed by the user to extract the top concepts within it.
• the concept extraction module is configured to analyze specific word patterns to uncover concepts that originally were not known to have a relationship with the underlying user's search.
• 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.
• 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. 3b.
• Contextualization module 104 also includes a context table 242 coupled to expert query module 220, and concept extraction module 240, which is configured to provide the appropriate expert queries based on the context of the user's research.
• Contextualization module 104 also includes a search builder module 244, which is coupled to context table 242, expert query module 220, user profile module 222, user navigation module 236 and concept extraction module 240.
• Search builder module is also coupled to database 37.
• Search builder module 244 is configured to provide search queries corresponding to the type of a research a user desires.
• search builder 244 includes a search matrix 246, which is configured to provide search queries within the context of a user's research.
• search matrix 246 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. 3b.
• context table 242 receives the appropriate context of the user from user profile module 222 and user navigation module 236 via a search builder module 244. The operation of contextualization module 104 is explained in more detail in reference with Fig.
• FIG. 5a which illustrates a sample workspace generated by workspace administrator 102 (Fig. lb).
• workspace 300 is displayed to a user who has visited a site provided by knowledge management system 28.
• 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 functions provided within search portion 302 are governed among other things, by contextualization module 104. Accordingly, the "search within” field includes “advisen” field, "my profile” field, "company look-up” field and "context of a template” field.
• search box field 308 that enables users to provide their own key words and phrases and to conduct desired searches within a specified field.
• a user after entering the desired key words in search box field 308, selects one of the available fields. If the user selects a search within advisen, search builder 244 retrieves the key words and conducts a search of all available data with database system 37. If the user selects a search within "my profile" field, search builder 244 obtains the profile information from user profile 222, so as to generate a search query in response to the profile information and the desired keywords provided by the user. Thus, the search is conducted within the documents that are not only related to the desired keywords but also the categories that are related to the user's profile.
• search builder 244 If the user selects a search within "company look-up" field, search builder 244 generates a search query relating to the company name provided by the user in box 308. If the user selects a search within "context of a template” field, search builder 244 obtains information from user navigation module 236 so as to generate a search query relating to one of the key practice templates in the projects section 304 of workspace 300. Thus, the search is conducted within the document that are not only related to the desired keywords, but also categories that are related to the template the user is operating.
• the advanced search option 310 responds by providing an interface page as illustrated in Fig. 5b. 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.
• the advanced search page also includes an "exact phrase match" option 322, so as to enable a user to treat all of the words entered in the keyword box as a phrase.
• Sources field option 324 allows the user to ⁇ specify the information sources that can be used for conduction the search specified in the keyword box.
• data range field 326 allows the user to restrict the search results to documents published within a certain time frame. By default, the system searches for documents published within the previous 30 days.
• Industry field 328 allows the user to restrict the search results to documents that concern a particular industry by selecting an industry from a pull-down menu. Only one industry at a time may be selected. If the user does not select an industry, the search includes all industries.
• Geographic region field 330 allows the user to retrieve only those documents that refer to a particular geographic region by selecting a region from, a pull-down menu. Only one region may be selected at a time. If no region is selected, the search will include all regions.
• 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.
• search portion 302 also includes in-context Preformatted searches as provided by contextualization module 104.
• 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.
• context table 242 provides the user's context information to expert query module 220. This information includes the user's profile and/or user's navigation within the workspace.
• expert query module 220 In response, expert query module 220 generates only the categories that are relevant to the user's information, among all the categories available within expert query module 220.
• search builder module 244 retrieves the categories provided by concept extraction module 240.
• Concept extraction module 240 provides the top concepts that are identified in-context. To this end, all documents relating to the user's profile and navigation are first obtained based on the query generated by search builder 244. Afterwards, concept extraction module identifies top concepts within those retrieved documents and makes those concepts available for further research by the user. As such, those additional concepts are presented in the form of additional new categories, against which database 37 could be searched.
• Contextualization module 104 is an effective search tool that enables the user to retrieve documents that are related to the context of the research being handled and to the profile of the user who is conducting the research. To this end, module 104 dynamically generates a list of categories obtained from taxonomy module 114 that are relevant to the context of the research.
• concept clustering module 106 of Fig. lb is now described in more detail in reference with Fig. 6.
• 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. 3a.
• "concept clustering" module 106 at step 360 retrieves n number of documents related to a selected category defined in taxonomy module 1 14, where n is a sufficiently reliable integer. In accordance with one embodiment of the invention, n is about 20 documents.
• concept clustering module 106 searches for key terms and phrases that occur m number of times within the retrieved documents, where m is a sufficiently reliable integer.
• concept clustering module 106 analyzes each of the key terms and phrases and determines the statistical correlation between the key terms and phrases with the selected category.
• 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 1 14 as additional items in category rule table 160 of Fig. 3a. Referring back to Fig. 5a, key practice portion 304 is described in more detail.
• knowledge management system 28 and specifically work space administrator 102 Fig.
• 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.
• work space administrator 102 retrieves the most recent news form database 37 (Fig. 1).
• 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. 5a.
• workspace administrator 102 In response to the selection of the projects button, workspace administrator 102 displays key practice templates.
• key practice portion 304 provides for a choice of various templates, including claims and loss analysis template 420, mergers and acquisitions template 422, renewal of insurance template 424, exposure analysis template 426, insurance administration 428, client research template 430, new product development template 432.
• workspace administrator 102 For each of these templates, workspace administrator 102 provides a list of actions that a user can follow, similar to. a workflow management arrangement. It is noted that in accordance with another embodiment of the invention, each user is enabled to create a user specific template that defines a desired workflow management, whereby a specific key practice area can be automated. Figs.
• FIG. 7a and 7b illustrate a workspace and more specifically, a keypractice portion 304, after a user selects claims and loss analysis template in Fig. 5a.
• workspace administrator module 102 displays the workflow associated with the claims and loss analysis template.
• An exemplary workflow as illustrated in Fig. 7a 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. 7b 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.
• additional sub steps are also defined.
• the workflow specifies three steps of searching news and journals, Property and Casualty (P&C) benchmarking, Risk Cost benchmarking.
• the benchmarking functionalities are provided by analytical module 108 as explained before.
• the contextualization module modifies predefined searches available in the search portion 302. Figs.
• FIG. 8a and 8b illustrate a workspace and more specifically, a keypractice portion 304, after a user selects mergers and acquisitions template in Fig. 5a.
• workspace administrator module 102 displays the workflow associated with the mergers and acquisitions analysis template.
• An exemplary workflow as illustrated in Fig. 8a 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 first step is followed by the step of obtaining annual reports and SEC filings corresponding to the candidate company, followed by the step of obtaining media articles.
• the next step includes reviewing sales and marketing brochures, followed by the step of obtaining corporate history.
• a corresponding sub step here includes obtaining candidate's legal history information.
• 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.
• this step includes the steps of enabling the user to conduct contract language search and policy form comparisons.
• database module 37 (Fig. lb) 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.
• 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 in the acquisition and mergers workflow includes participating in data room evaluation and due diligence process.
• workspace administrator 102 allows various users to collaborate over various documents involved in the project to track the progress of the project and to participate in the most coherent fashion.
• 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. lb).
• Fig. 8b 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.
• this step includes sub steps that enable the user to employ analytical tools to assess the candidate company's insurance losses.
• the following steps include analyzing the quality of risk of the candidate company, followed by analyzing the safety statistics and conducting news and journals searches.
• the workflow then prompts the user to determine whether the candidate company's program should be continued.
• the next step includes determining run-off coverages and servicing followed by the step of analyzing special exposures and coverages.
• the workflow then prompts the user to review claims made policies and determine the need for transitional coverages.
• the workflow prompts the user to acquire binders for coverage after acquisition.
• Figs. 9a and 9b illustrate a workspace and more specifically, a keypractice portion 304, after a user selects renewal of insurance template in Fig. 5a.
• 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. 9a 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 1 14.
• the next step includes meetings with brokers and/or agents followed by the step of conducting marketplace trend analysis.
• This step provides sub steps for conducting analytical functions such as property and casualty (P&C) benchmarking, A.M. Bests/News Search, S&P Insurance ratings and directors and officers (D&O) benchmarking.
• 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. lb).
• the next step includes performing loss control and safety program analysis, by obtaining safety administration reports, engineering reports and news searching, followed by the step of developing coverage specifications and issuing requests for proposals.
• Figs. 10a and 10b illustrate a workspace and more specifically, a keypractice portion 304, after a user selects exposure analysis template in Fig. 5a.
• 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.
• the steps provided in the exposure analysis template include risk analysis and mapping followed by internal benchmarking, followed by identifying and separating internal divisions of the organization. These steps are followed by the steps of compiling costs of risk and conducting and external benchmarking. These steps are followed by the steps of determining SIC classifications for the desired industry, obtaining trade association costs of risk information, comparing to internal cost of risk, RIMS benchmarking, ISO benchmarking, D&O benchmarking, displaying results in charts, obtaining various financial solutions for financing the risk, and identifying suppliers of insurance for alternative solutions.
• Fig 11 illustrates a workspace and more specifically, a keypractice portion 304, after a user selects client research template in Fig. 5a.
• 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. 5a.
• 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.
• the steps illustrated in the workflow of Fig. 12 includes the step of identifying new exposure and loss by employing the sub steps of conducting client industry searches, insurance industry searches, case law searches by exposure and regulatory searches by exposure. This step is followed by researching new.
• Fig 13 illustrates a workspace and more specifically,- a key practice portion 304, after a user selects the reference button of Fig. 5a.
• workspace administrator module 1 2 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.
• Knowledge management system 28 can be configured in accordance to other embodiments of the invention so as to generate and display other key practice templates relating to other desired workflows. This can be handled either by the user itself or by a system administrator who plans to distribute the system to other users.
• 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.
• 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.l) 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.
• the resulting data will simply produce an abstract benchmark for the industry according to the below selected criteria.
• the data set to be compared against is preferably drawn from similarly situated companies.
• the data set is preferably drawn from companies of the same size, in the same location, in the same ' industry.
• 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.
• 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.
• benchmarking module 460 of the present invention allows a user to produce a benchmarking analysis against multiple industries simultaneously.
• 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.
• 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.
• the user may further indicate that the revenue split is 70% manufacturing, 10% banking and 20% real estate.
• 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.
• 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.
• 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.
• 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.
• 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,)
• 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.
• LOBs Lines of Business
• 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.
• the user can set the specific characteristics to limit the size of the peer group data set.
• 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 60million, +/- 25%. In such an instance the peer group data set will be limited to policies with limits of 45million to 70 million dollars.
• benchmarking module 460 of system 10 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.
• the user may progress to the benchmarking selection wireframe, illustrated in Fig. 17.
• the benchmarking selection wireframe illustrated in Fig. 17.
• the user selects the information to be shown in the benchmark results, such as premiums, limits, retention, revenue etc...,.
• 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.
• 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.
• 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.
• 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.
• Analytical module 108 also includes a league table module 46, which is configured to generate league tables.
• Module 108 also includes a co-charting module 468, which is configured to generate various charts as necessary.
• Module 108 also includes a risk accounting module 470, which is configured to conduct risk accounting as understood by those skilled in the art.
• RIMS data module 472 is configured to provide data developed by the Risk and Insurance Management Society industry, for research purposes of the user.
• Claims data module 474 is configured to provide the claims data related to a company specified by the user.
• Loss triangle module 476 is configured to perform loss triangle analysis.
• the Loss Triangles feature enables policyholders to create a customized electronic loss history up to and including for example five years of data — aggregated in real-time on an annual basis — providing users with an integrated picture of how losses for Worker's Compensation, Automobile and General Liability and other coverages have developed over time.
• the information can be tabulated by Loss Paid or Total Incurred and can also compare the worker's compensation results against industry averages using the latest National Council on Compensation Insurance (NCCI) statistics.
• NCCI National Council on Compensation Insurance
• the Loss Triangle feature also provides the user with Loss Development Factors (LDF) — based on a company's specific loss experience — which, collectively can be strategically used to forecast future loss development or determine the effectiveness of specific risk management programs.
• LDF Loss Development Factors
• 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.
• Loss Triangle reports can be used to measure the claims handling efficiency of Third Party Administrators (TPA).
• Severity Monte Carlo Simulation module 478 provides the user with the tools necessary to perform that simulation, for actuarial and other calculations.
• Module 480 provides analysis for financial modeling of cost structures as desired by the user.
• Safety administration report module 482 generates reports relating to safety issues for mitigating risks related to an organization.
• engineering report module 484 is configured to generate engineering reports relates to various risks a specified organization is exposed.
• financial summary module 486, provides information related to the financials of the organization being researched by the user.
• 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.
• 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.
• 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.
• 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 info ⁇ nation from the user, and the format that illustrates the graphic displays in accordance with one embodiment of the invention. Referring back to Fig.
• a look up module 518 is configured to provide various look up functionalities for the user.
• 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.
• 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).
• field 584 the user selects the topics that are available for comparison.
• 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.
• 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.
• 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.
• administrative efficiency tool 1 10 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 1 10 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 1 10 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.
• Two additional modules coupled to look up table 518 include league table module 526, which provides comparison of various insurance ratings and financial term module 530, which is configured to provide financing topics for each jurisdiction.
• a policy form 532 module is also coupled to look up table 518. Policy form 532, is configured to provide a table of how various policies have treated a certain topic, by providing examples of prior forms. This enables the user to get an overall impression of coverages, exclusions, definitions for each form and jurisdiction. It is noted that the present information management system although described in relation to the insurance industry, can be employed in other applications and is not limited in scope in that respect.

Landscapes

• Business, Economics & Management (AREA)
• Accounting & Taxation (AREA)
• Finance (AREA)
• Engineering & Computer Science (AREA)
• Development Economics (AREA)
• Economics (AREA)
• Marketing (AREA)
• Strategic Management (AREA)
• Technology Law (AREA)
• Physics & Mathematics (AREA)
• General Business, Economics & Management (AREA)
• General Physics & Mathematics (AREA)
• Theoretical Computer Science (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Applications Claiming Priority (3)

Publications (2)

Family

ID=34752983

Family Applications (1)

Country Status (2)

Families Citing this family (4)

Family Cites Families (2)

• 2004
  • 2004-12-27 EP EP04817060A patent/EP1704524A4/de not_active Withdrawn
  • 2004-12-27 WO PCT/US2004/043601 patent/WO2005065299A2/en active Application Filing

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events