INSURANCE CONTEXTS AND FACTORS

DESCRIPTION OF THE DISCLOSURE

Field of the Disclosure

[0001 ] This disclosure relates to systems and methods for insurance designs and, more particularly, to systems and methods for insurance designs using standard insurance contexts and factors.

Background of the Disclosure

[0002] The insurance industry considers a plurality of variable factors in

designing and marketing different insurance products. For example, different factors may be used in designing insurance products offered to different insured objects and/or geographic regions. To accommodate variations and changes in customer and market needs, insurance companies may need to constantly design new insurance coverages for various incidents and new insurance products for various insured objects. For example, if a market opportunity comes up, an insurance company may want to redesign its insurance coverage and develop a new insurance product to take

advantage of such market opportunity.

[0003] However, with existing insurance design systems, the design/redesign process is typically complex and time-consuming. A product has to be rebuilt from bottom up to respond to each market need and change. As a result, a large number of products with no structured relations with each other may be created, and very soon it becomes inevitably hard to manage these products. For example, in response to a small change of market or risk pattern, an insurance company may need to recreate the new insurance coverage and design the new insurance product from scratch. For example, using existing insurance design systems, it may take about several months for some insurance companies to design a new product and distribute the newly designed products to the market. The delay contributes to inefficiency and lost market

opportunities.

[0004] To improve the speed of insurance product design, a method has been developed that predefines various insurance coverages and creates insurance products based on these predefined insurance coverages. However, using such a method, a new insurance coverage has to be created in response to a market change, even if a minor one. Then the newly created insurance coverage has to be added to the list of predefined insurance coverages, and the subsequent insurance product design has to be updated accordingly. Since the insurance products and various coverages have no structured relations with each other, the design process becomes inevitably difficult to manage. The process could be complicated and time consuming. Therefore, although predefining and storing insurance coverages may save the time to assemble an insurance product, it still does not efficiently response to market changes. In fact, the task of predefining and managing these unstructured insurance coverages is very complex and still time consuming.

[0005] Therefore, there is a need to go one or more levels below coverage to standardize the insurance product design process based on standardized insurance contexts and factors. There is also a need to use these standardized insurance contexts and factors to efficiently assemble and segment insurance products from coverages. There is yet another need to generate various insurance related templates based on these standardized insurance contexts and factors in order to fast deploy the products into the insurance production system. It is an objective of the present invention to improve insurance product design and deployment such that the insurance products respond to the fast-changing market in a real time manner.

SUMMARY

[0006] Various insurance products may be designed to cover different perils and damages. For examples, an auto product may include coverage to cover auto damages caused by fire or third party liabilities caused by collision. Insurance management may include different phases such as, for example, product design, product distribution, and policy life cycle management including sales, renew, endorsement, and claim. Risk and risk management stay at the center of the insurance industry. When an insurance event happens, its cause (peril) may vary case by case, and the caused damage may be of different types and different significances. However, for an insurance product line of business, such as automobile insurance, perils to cover are limited in number and can be standardized. Further, upon the occurrence of a particular peril, types of potential damages are limited in number and can be standardized. Also, for a particular peril and a particular damage, the associated risk factors, which are used to determine the likelihood of peril(s) as well as the potential scope of damage, are stable and finite in number and thus, can be standardized as well. For an insurance coverage, the covered peril(s) and damage(s) are the foundational elements that define and size the risk of the coverage along with indemnification.

[0007] The current disclosure describes systems and methods to pre-establish, standardize and manage basic insurance contexts and factors, and then to create coverage using these basic elements. As a result, the number of distinct coverages can be kept small and differences among these coverages are well structured and easily managed. Insurance products may then be assembled and segmented using these risk factors in respond to the market changes, so that real time insurance product design can be achieve.

[0008] In one aspect, a computer-implemented method for creating an insurance design is disclosed. The method includes defining a plurality of factors, and associating the plurality of factors with at least one insurance context. The method further includes providing a list of associated factors upon a selection of the insurance context.

[0009] In another aspect, a computer-implemented method for creating an insurance coverage is disclosed. The method includes providing a list of factors associated with a plurality of user-selected insurance contexts, and determining the insurance coverage based on the list of factors.

[0010] In yet another aspect, a computer-implemented method for creating an insurance product is disclosed. The method includes providing a list of factors associated with a plurality of user-selected insurance contexts, and determining an insurance coverage and an insured object based on the list of factors. The method further includes creating the insurance product by combining the insurance coverage with the insured object.

[001 1 ] In yet another aspect, a computer-implemented method for creating an insurance product is disclosed. The computer-implemented method includes providing a list of factors. The method further includes creating a first insurance product based on the list of factors, and creating a second insurance product by segmenting the first insurance product based on a subset of the list of factors.

[0012] In yet another aspect, a computer-implemented method for generating an insurance-related template is disclosed. The computer-implemented method includes providing a list of factors associated with a plurality of user-selected insurance contexts. The method further includes generating the insurance-related template based on the list of factors.

[0013] In yet another aspect, a computer-implemented method for generating an insurance policy model is disclosed. The computer-implemented method includes receiving values of a list of factors, the list of factors associated with a plurality of user- selected insurance contexts. The method further includes generating the insurance policy model based on the values of the list of factors and an insurance policy model template, the insurance policy model template created based on the list of factors. In some embodiments, the method also includes performing an insurance calculation by applying the values to a formula, where the formula is determined based on the list of factors. In some embodiments, the insurance calculation calculates one of an insurance premium, an insurance commission, or an insurance discount [0014] In yet another aspect, a computer-implemented method for processing an insurance application is disclosed. The method includes receiving values of a list of factors, the list of factors associated with a plurality of user-selected insurance contexts. The method further includes determining whether to accept, reject, or perform a predefined processing on the insurance application based on the values and a rule, the rule determined based on the list of factors.

[0015] In yet another aspect, a computer-implemented method for generating insurance analytics is disclosed. The computer-implemented method includes receiving values of a list of factors used in a plurality of insurance policies, the list of factors associated with a plurality of user-selected insurance contexts. The method further includes generating insurance analytics based on the values.

[0016] It is to be understood that both the foregoing general descriptions and the following detailed descriptions are exemplary and explanatory only and are not restrictive of the invention, as claimed.

[0017] Although the disclosed embodiments are discussed primarily in the context of creating and managing insurance products, other applications are

contemplated. For example, the disclosed embodiments may be used for processing other insurance-related transactions based on the created insurance product. As another example, the disclosed embodiments may also be used for creating virtual products other than insurance products. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments and, together with the description, serve to explain principles of the invention.

[0019] Fig. 1 is a block diagram of an exemplary insurance design system, according to some disclosed embodiments.

[0020] Fig. 2 illustrates a block diagram of an exemplary computing system, according to some disclosed embodiments.

[0021 ] Fig. 3 illustrates an architectural diagram of an exemplary process for creating and managing insurance products, according to some disclosed embodiments.

[0022] Fig. 4 illustrates a flow chart of an exemplary process for creating an insurance design, according to some disclosed embodiments.

[0023] Figs. 5A and 5B each illustrate a table including a plurality of exemplary factors associated with insurance contexts, according to some disclosed embodiments.

[0024] Fig. 6 illustrates a flow diagram of an exemplary process for creating insurance products from standard factors, according to some disclosed embodiments.

[0025] Fig. 7 illustrates exemplary associations among peril, damage, indemnity, and standard factors, according to some disclosed embodiments.

[0026] Fig. 8 illustrates a flow chart of an exemplary process for creating an insurance coverage, according to some disclosed embodiments.

[0027] Figs. 9A and 9B each illustrate an exemplary interface for creating an insurance coverage, according to some disclosed embodiments. [0028] Fig. 10 illustrates an exemplary interface for creating a formula for insurance coverage, according to some disclosed embodiments.

[0029] Fig. 1 1 illustrates a flow chart of an exemplary process for creating an actuary insurance product, according to some disclosed embodiments.

[0030] Fig. 12 illustrates an exemplary interface for creating an actuary insurance product, according to some disclosed embodiments.

[0031 ] Fig. 13 illustrates a flow chart of an exemplary process for creating a marketable insurance product, according to some disclosed embodiments.

[0032] Fig. 14 illustrates an exemplary interface for creating a marketable insurance product, according to some disclosed embodiments.

[0033] Fig. 15 illustrates a table containing exemplary predetermined factors for segmenting an actuary product, according to some disclosed embodiments.

[0034] Fig. 16 illustrates a flow diagram for creating various insurance-related templates and other documents, according to some disclosed embodiments.

[0035] Fig. 17 illustrates a flow chart of an exemplary process for processing an insurance application/claim, according to some disclosed embodiments.

[0036] Fig. 18 illustrates a flow chart of an exemplary process for creating an insurance policy, according to some disclosed embodiments.

[0037] Fig. 19 illustrates a flow chart of an exemplary process for creating insurance analytics, according to some disclosed embodiments. DESCRIPTION OF THE EMBODIMENTS

[0038] Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. The following description refers to the accompanying drawings in which the same numbers in different drawings represent the same or similar elements unless otherwise represented. The implementations set forth in the following description of exemplary embodiments do not represent all implementations consistent with the invention. Instead, they are merely examples of systems and methods consistent with aspects related to the invention as recited in the appended claims.

[0039] Fig. 1 is a block diagram of an insurance design system 100, according to some disclosed embodiments. In some embodiments, system 100 may include an insurance software provider 1 10, insurance companies 120A and 120B, a client 130, and a network 140. It is contemplated that the components and arrangement of the components included in system 100 may vary. For example, system 100 may further include other components that perform or assist in the performance of one or more processes consistent with the disclosed embodiments.

[0040] Insurance software provider 1 10 may be an entity that provides insurance design software. For example, insurance software provider 1 10 may be a software design company that designs, generates, provides, manages, and/or maintains insurance products to be used by insurance companies 120A and 120B. In some embodiments, insurance software provider 1 10 may custom-design insurance software products based on special requests from insurance companies 120A and 120B.

[0041 ] Insurance software provider 1 10 may include one or more computing systems that are configured to execute software instructions stored on one or more memory devices to perform one or more operations consistent with the disclosed embodiments. In one embodiment, insurance software provider 1 10 may include server 1 1 1 .

[0042] Server 1 1 1 may be a general-purpose computer, a mainframe computer, or any combination thereof. For example, Fig. 2 illustrates an exemplary computing system 200 that can be implemented as server 1 1 1. For example, server 1 1 1 may include one or more memory devices 223 configured to store software

instructions/programs 224 and data 225, including metadata for insurance design.

Additional programs and data may also be stored in storage device 226. In some embodiments, data 225 may be stored as a database 227 coupled to memory 223 and storage device 226.

[0043] Sever 11 1 may further include one or more processors 221 configured to use the data and execute the software instructions to perform server-based functions and operations. For example, processor 221 may be configured to execute stored software instructions to perform operations associated with providing software for insurance companies to design and manage insurance products in a manner consistent with the disclosed embodiments.

[0044] Server 1 1 1 may be a standalone server, or may be part of a subsystem, which may be part of a larger system. For example, server 1 1 1 may be among a group of distributed servers that are remotely located and communicate over a network (e.g., network 140) or a dedicated network, such as a LAN. As another example, server 1 1 1 may be part of server 121A or 121 B.

[0045] In certain embodiments, a user 1 12 may operate one or more components of insurance software provider 1 10 (e.g., server 1 1 1 ) to perform one or more operations consistent with the disclosed embodiments. For example, user 1 12 may operate server 1 1 1 via input/output interface 222, and receive processing results from display 228. In one aspect, user 1 12 may be someone authorized to use components of server 1 1 1 or perform processes for insurance software provider 110. For example, user 1 12 may be an employee of, or otherwise associated with, insurance software provider 1 10.

[0046] In some embodiments, insurance companies 120A and 120B may be entities that provide insurance services consistent with the disclosed embodiments. In some embodiments, insurance company 120A and insurance company 120B may be entities that purchase insurance software products offered by insurance software provider 1 10, and use the software products to create and manage insurance products. For descriptive purposes only, the descriptions below refer only to insurance company 120A, but it is contemplated system 100 is not limited to one insurance company.

Insurance company 120B may have same or similar components (e.g., server 121 B may be the same as or similar to server 121 A) as those provided by insurance company 120A, and may perform same or similar functions as those described with respect to insurance company 120A.

[0047] Insurance company 120A may operate brick and mortar location(s) that a consumer (e.g., user 132) may physically visit and purchase insurance goods and services. Such physical locations may have on-site computing devices that perform insurance service transactions with consumers. They may also have back-end and/or front-end computing components that store insurance-system-related data and execute software instructions to perform operations consistent with the disclosed embodiments. These computing components may be computers that are operated by employees of insurance company 120A (e.g., back-office systems, etc.). In certain embodiments, insurance company 120A may also include entities that provide electronic mechanisms, such as a website or a similar online location that consumers (e.g., user 132) may access using a computer (e.g., client 130) through browser software or similar software.

[0048] Insurance company 120A may operate a server 121 A. Similar to sever 1 1 1 , server 121 A may be a computing device such as computing device 200 illustrated in Fig. 2. For example, server 121 A may include one or more memory devices 223 storing software instructions/programs 224, such as insurance software provided by insurance software provider 1 10. Memory device 223 may further store data 225, including metadata for insurance design and values for the metadata to create an insurance policy. Server 121 A may further include processor 221 configured to execute stored software instructions to perform operations associated with creating and managing insurance products.

[0049] According to some embodiments, server 121 A may be configured to communicate with server 1 1 1 to receive data associated with creating and managing insurance products stored in one or more memory devices of server 11 1. In some embodiments, server 121A may access and execute insurance design software and data stored remotely, such as on sever 1 1 1. In some embodiments, server 121 A may use cloud computing and let a remote server (e.g., server 1 1 1 ) execute insurance design software stored thereon and send the results to sever 121A. In some

embodiments, server 121A may include server 1 1 1 , or perform the functions of server 1 1 1.

[0050] In some exemplary embodiments, a user 122A may operate server 121A to perform one or more operations consistent with the disclosed embodiments. For example, user 122A may be someone authorized to use components of server 121 A or perform processes for insurance company 120A consistent with the disclosed embodiments. For example, user 122A may be an employee of, or otherwise associated with, insurance company 120A.

[0051 ] Client 130 may be a computing device configured to execute software instructions for performing one or more operations consistent with the disclosed embodiments. For example, client 130 may be a desktop computer, a laptop, a server, a mobile device (e.g., tablet, smartphone, etc.), and/or any other type of computing device. In some embodiments, client 130 may have components and configurations as those illustrated in Fig. 2 for computing system 200. For example, client 130 may include one or more processors 221 configured to execute software instructions stored in memory 223. In some embodiments, client 130 may include software that, when executed by a processor, performs Internet-related communications and content display processes. For instance, client 130 may execute browser software that generates and displays interfaces on display device 228 included in, or connected to, client 130.

[0052] In some embodiments, client 130 may have insurance design software installed thereon for creating and managing insurance products. For example, insurance software provider 1 10 may provide a copy of the insurance design software to client 130 directly or indirectly through insurance company 120A/120B.

[0053] In some embodiments, a user 132 may use client 130 to perform one or more operations consistent with the disclosed embodiments. In one aspect, user 132 may be a customer or an insurance agent of insurance company 120A and/or insurance company 120B. For instance, insurance company 120A and/or insurance company 120B may maintain an insurance service account for user 132. In some other embodiments, user 132 may not be affiliated with insurance company 120A and/or insurance company 120B from the perspective of user 132 and/or the perspective of insurance company 120A and/or insurance company 120B. For example, user 132 may be a beneficiary of an insurance product offered by insurance company 120A and/or insurance company 120B.

[0054] Network 140 may be any type of network configured to facilitate communications between the components of system 100. In some embodiments, network 140 may be the Internet, a Local Area Network, or other suitable connections that enable transmission of information among the components of system 100. In some other embodiments, one or more components of system 100 may communicate directly through a dedicated communication link(s), such as the exemplary link between insurance software provider 1 10 and insurance companies 120A and 120B.

[0055] Fig. 2 illustrates a block diagram of a computing system 200 that may correspond to anyone of servers 11 1 , 121 A, and 121 B, and client 130, according to some disclosed embodiment. Computing system may include a processor 221 , an input/output (I/O) device 222, a memory 223, a storage device 226, a database 227, and a display device 228.

[0056] Processor 221 may be one or more known processing devices, such as a microprocessor from the Pentium™ family manufactured by Intel™ or the Turion™ family manufactured by AMD™. Processor 221 may include a single core or multiple core processor system that provides the ability to perform parallel processing. For example, processor 221 may be a single core processor that is configured with virtual processing technologies. In certain embodiments, processor 221 may use logical processors to simultaneously execute and control multiple processes. Processor 221 may implement virtual machine technologies, or other similar known technologies, to provide the ability to execute, control, run, manipulate, store, etc., multiple software processes, applications, programs, etc. In another embodiment, processor 221 includes a multiple-core processor arrangement (e.g., dual or quad core) that is configured to provide parallel processing functionalities to allow computing system 200 to execute multiple processes simultaneously. One of ordinary skill in the art would understand that other types of processor arrangements could be implemented that provide for the capabilities disclosed herein.

[0057] Memory 223 may include one or more storage devices configured to store instructions used by processor 221 to perform functions related to the disclosed embodiments. For example, memory 223 may be configured with one or more software instructions, such as program 224 that may perform one or more operations when executed by processor 221. The disclosed embodiments are not limited to separate programs or computers configured to perform dedicated tasks. For example, memory 223 may include a single program 224 that performs the functions of computing system 200, or program 224 could comprise multiple programs. Additionally,

processor 221 may execute one or more programs located remotely from server 21 1.

[0058] Memory 223 may also store data 225 that may reflect any type of information in any format that insurance software provider 1 10 may use to perform functions consistent with the disclosed embodiments. For example, data 225 may include metadata of a plurality of standard factors associated with an insurance system of which a detailed description is provided below, and other data enabling processor 221 to perform functions including providing insurance software products for creating and managing insurance products, consistent with the disclosed embodiments.

[0059] I/O devices 222 may be configured to allow data to be received and/or transmitted by server 21 1. I/O devices 222 may include one or more digital and/or analog communication devices that allow computing system 200 to communicate with other machines and devices, such as insurance company 120A (via server 121A) and/or insurance company 120B (via server 121 B).

[0060] Computing system 200 may also include or be communicatively

connected to one or more of database 227 through network 140. By way of example, database 227 may include Oracle™ databases, Sybase™ databases, or other relational databases or non-relational databases, such as Hadoop sequence files, HBase, or Cassandra. In exemplary embodiments, database 227 may store metadata of standard factors to be used for insurance design. For example, the metadata may be created by user 1 12, and stored into database 227. [0061 ] Fig. 3 illustrates an architectural diagram of an exemplary process 300 for creating and managing insurance products, according to some disclosed embodiments. In some embodiments, process 300 may embody the complete insurance design lifecycle, which includes various design phases performed by one or multiple people.

[0062] Process 300 may start with a phase 310 where standard factors are defined and stored. For example, insurance software provider 1 10 may define the factors. Consistent with this disclosure, a factor is the metadata associated with an or more insurance context (such as peril/damage with indemnity). In some embodiments, the factors may include actuary factors and non-actuary factors. Actuary factors may include factors that are considered by an actuary when calculating the premium of an insurance policy and evaluating the business rules to manage risk. Non-actuary factors may include factors that are not directly related to risk but may still affect the pricing of the insurance policy. For example, non-actuary factors may include marketing pricing factors, such as a competitor's premium for same or similar coverage. Such factors are normally not considered by actuaries but may still affect the insurance pricing. On the other hand, a person's name is not an actuary factor and does not affect pricing at all.

[0063] In some embodiments, insurance software provider 1 10 may further perform phase 320 to associate the factors with a plurality of insurance contexts, such that each insurance context may refer to a list of factors. For example, "fire," as a type of peril, may refer to factors including location, building age, building area, number of bedrooms, construction type, wall construction type, roof construction type, etc.

[0064] In some embodiments, multiple insurance contexts may refer to a same factor. In such cases, the common factor is associated with each of the insurance contexts that refer to it. For example, "theft," a type of peril for auto insurance may refer to the location of the owner, which is also a factor for "flood," a type of peril for home insurance. Insurance software provider 1 10 may store the factors, as well as the association between the factors and the insurance contexts in a database, such as database 227 shown in Fig. 2.

[0065] Coverages, and other intermediate insurance attributes, such as rules, formulas, and clauses, may be created based on the factors and their associations to the insurance contexts. In some embodiments, insurance contexts such as standard peril, damage, indemnity, and insured objects may be first determined based on the factors, in phase 330. Then, insurance coverage may be determined by assembling the standard peril, damage, and indemnity, in phase 340. For example, insurance

companies 120A and 120B may perform phases 330 and 340 using the software as well as the metadata (including the factors) provided by insurance software company 1 10.

[0066] Consistent with this disclosure, peril is a risk or incident that is covered by the insurance, such as fire (for a house), collision (for a car), and theft (for a personal property). Damage is the loss caused by associated peril. For example, vehicle property damage and personal medical damage may both occur in a collision accident. Indemnity is the extent that damage is covered by the insurance. In some embodiments, indemnity may include limits and deductibles. For example, an auto insurance policy may limit its payment to $100,000 any one accident (AOA).

[0067] As part of phase 330, insured objects may also be created. Consistent with this disclosure, an insured object is the object to which an insurance coverage applies. For example, the insured object in a home insurance policy may be a dwelling built on a specific piece of land. As another example, the insured object in an auto insurance policy may be one or more vehicles owned by a specific household. An insured object may be created based on actuary factors which are shared with related perils and damages, as well as additional non-actuary factors.

[0068] Insurance coverage, the indemnification for a specified damage caused by covered peril, may be assembled in phase 340 based on the peril, damage, and indemnification created in phase 330. Other elements, such as actuary formulas, rules, and clauses may also be created in phase 330. Consistent with this disclosure, an actuary formula is a mathematical formula used for computing an insurance premium based on various factors associated with the insurance contexts (e.g., peril, damage, indemnity, and insured object). A rule may specify one or more conditions for accepting or rejecting an insurance application. Typically, a rule may specify a range of values for a factor as a condition for accepting an insurance application. For example, a rule may be created to accept applications for people younger than 50 years old, or for houses that have smoke detectors installed. A clause may be a template language specifying certain insurance terms, or otherwise describing the insurance coverage.

[0069] In phase 350, an actuary insurance product (also known as a technical insurance product) may be created based on the coverages, the insured objects, and optionally the product level rules and formulas . For example, one or more insurance coverages may be combined with one or more insured objects to create the actuary product.

[0070] In phase 360, a marketable insurance product may be created, for example, by segmenting the actuary product created in phase 350. In some embodiments, the segmentation may be implemented as presetting values or ranges of values for certain factors associated with the actuary product. For example, the property location factor of a home insurance product may be preset to Virginia to target the Virginia residents as a potential market, such that sales and marketing efforts may be tailored for the Virginia market. As another example, the age factor of the covered person in a medical insurance product may be preset to 20-25 to target the young (typically single and/or with no kids) individuals. Such a product may be marketed to, for example, college students and new graduates.

[0071 ] In phase 370, various insurance related templates may be created based on the factors. In some embodiments, an interface may be created for receiving inputs of values for various factors associated with a particular insurance product. The interface may include various fields for receiving the inputs. In some embodiments, the interface may be a user interface ("Ul") or a graphic user interface ("GUI") for receiving inputs from a user. In some other embodiments, the interface may be a programing interface for receiving input values from a public service. For example, the programing interface may be an application programing interface ("API").

[0072] In some embodiments, an insurance policy model template may be created based on the associated factors in phase 360. Consistent with the present disclosure, an insurance policy model is an electronic version of an insurance policy that is created, stored, and modified on a computer. Further, an insurance policy model template is a template insurance policy model with fields to store values of the associated factors that are to be provided. When the fields are filled in with specific values, the insurance policy model template becomes an actual insurance policy model. Other template documents may also be created based on the associated factors in phase 360. For example, template reports, forms, and agreements may be created.

[0073] In other words, consistent with the present disclosure, factors and various insurance contexts, such as peril, damage, indemnity, and insured object, are the very basic "elements" for insurance design. Coverages are the "compounds" that are combinations of the basic "elements." On the next level, actuary products are

"mixtures" that are combinations of the coverages and insured objects. Just as a large number of mixtures may be created using the limited number of elements, a large number of actuary products may be created based on a limited number of factors. By predefining and storing a small number of "elements," and assembling higher-level insurance semantics using these "elements," the entire insurance design process may thus be simplified and expedited. The entire insurance life cycle may be efficiently and consistently managed among different people through the use of these predefined factors.

[0074] Fig. 4 illustrates a flow chart of an exemplary process 400 for creating an insurance design, according to some disclosed embodiments. For example, insurance software provider 1 10 may perform process 400. In step 410, insurance software provider 1 10 may predefine a list of standard factors. The factors may be selected based on empirical knowledge of insurance software provider 1 10, and/or based on feedback from insurance companies 120A and 120B. In some embodiments, each factor may be defined as a metadata class, which includes a factor ID, a factor name, a factor description, a data type, a business type, value option, etc. [0075] In step 420, the list of standard factors may be associated with a plurality of insurance contexts. For example, the insurance contexts may include a peril/risk category, a damage/loss category, an indemnity category, and an insured object category. Each insurance context may refer to one or more standard factors predefined in step 410. In some embodiments, each insurance context may also be defined as a metadata class. For example, a peril class may include a peril ID, a peril name, and associated factor IDs.

[0076] In step 430, the predefined factors and their associations/relationships may be stored in a database as metadata. For example, insurance software provider 1 10 may use existing database management systems including, for example, Microsoft SQL Server, Microsoft Access, Oracle, FoxPro, My SQL, PostgreSQL, SQLite, etc., to create database 227 for storing the metadata.

[0077] Figs. 5A and 5B each illustrate a table including a plurality of exemplary factors associated with insurance contexts, according to some disclosed embodiments. For example, the factors illustrated in table 500A are organized based on risk categories (e.g., motor, fire, accident & health). As shown in table 500A, risk category "motor" may refer to a list of factors including brand, model, vehicle age, number of seats, capacity, usage, driving area, market value, imported reconditioned, parallel imported, etc.

[0078] As shown in Fig. 5B, the factors illustrated in table 500B are associated with a plurality of types of peril/risk (e.g., collision), and their associated damage/loss (e.g., vehicle damage) and indemnity (e.g., litigation and labor expenses). In some embodiments, the peril/risk may include various risks an individual may face daily, or various risk an entity may face in the ordinary course of business. For example, risks associated with a vehicle may include collisions, natural disasters, fire, theft, and other accidents. Factors under the peril/risk category may include, for example, information related to the insured individual and the insured property, information related to a geographic region around the insured, and past claims related to the insured as well as the geographic region, etc. For example, peril "collision" may be associated with factors such as usage, total indemnity of claims, number of accidents, number of insured, number of drivers, main driver age, main driver occupation, main driver gender, main driver driving experience, named driver age, named driver occupation, named driver gender, named driver driving experience, type of customer, and annual mileage.

[0079] In some embodiments, the damage/loss may include bodily injury (death, disability, burns, fracture, etc.), medical expense, life style maintenance, property loss, etc. For example, the damage/loss associated with a "collision" peril may include vehicle damage, litigation and labor expenses, etc. As shown in table 500B, factors associated with vehicle damage may include vehicle, age, number of seat, capacity, market value, imported reconditioned, parallel imported, brand, model, type of vehicle, etc.

[0080] In some embodiments, the indemnity may specify a compensation method for the associated damage/loss. For example, it may include an indemnity mode (compensated by Any One Accident (AOA) or by Any One Period (AOP)). As shown in table 500B, factors associated with the indemnity of vehicle damage may include, for example, the limit of compensation and a deductible.

[0081 ] The organization of factors in table 500A and 500B are only exemplary. It is contemplated that the factors can be organized in various other ways facilitating the retrieval of these factors from the database (e.g., database 227) for creating and managing insurance products.

[0082] Referring back to Fig. 4, in step 440, a selection of insurance context may be received. For example, the selection may be received from user 1 12, or user 122A/122B. The selection may specify the category of the insurance context, such as a peril/risk category, and the specific peril/risk, such as "collision." Factors that are associated with the selected insurance context may be identified, in step 450. The associated factors may be identified from the database where the factors and associations are stored in step 430. For example, factors associated with "collision" as listed in table 500B may be identified. In step 460, the associated factors may be provided, e.g., displayed to user 1 12.

[0083] In some embodiments, process 400 may further include step 460 where one or more factors are updated. Updating a factor may include adding, deleting, or modifying the factor. In some embodiments, insurance software provider 1 10 may update the factor based on analytics it obtains on existing insurance products, and/or feedback provided by insurance companies 120A and 120B. For example, insurance company 120A may discover that an additional factor may affect the pricing of insurance coverage on hailstorm and may communicate that to insurance software provider 1 10 to have the factor added to the database. The updated factor may be associated or re-associated with the corresponding insurance contexts (step 420), and stored in the database (step 430).

[0084] Fig. 6 illustrates a flow diagram of an exemplary process for creating insurance products from standard factors, according to some disclosed embodiments. In some embodiments, insurance companies 120A and 120B may perform that process using insurance design software provided by insurance software provider 1 10. As shown in Fig. 6, the insurance design software may include a database that stores the standard factors, including, for example, actuary factors and non-actuary factors.

Insurance companies 120A and 120B may first select/create insurance contexts including peril, damage, and indemnity, each of which refers to one or more factors in the database.

[0085] Fig. 7 illustrates exemplary associations among peril, damage, indemnity and standard factors, according to some disclosed embodiments. Table 701 shows a plurality of insurance product lines. For example, the risk categories may include, for example, accident, travel, health, auto, home, and etc. Each risk category may be associated with a plurality of possible peril/risk. For example, as shown in table 702, a "motor" type risk may cover perils including collision, fire, theft and robbery, etc. In some embodiments, table 702 may be linked to the entry "motor" in table 701 , such that once "motor" is selected during coverage design, perils listed in table 702 may be automatically retrieved and provided as the available perils.

[0086] In some embodiments, each particular peril/risk in table 702 may be associated with one or more risk factors. For example, as shown in table 703,

"collision" may be associated with factors including age of the driver, and driving experience of the driver, etc. In addition, each particular peril/risk in table 702 may also be associated with a plurality of damages/losses. For example, table 704 illustrates a number of possible damages/losses associated with a "collision," including vehicle damage, litigation and labor expense, and bodily injury, etc. In some embodiments, table 704 may be linked to the entry "collision" in table 702, such that once "collision" is selected during coverage design, damages/losses listed in table 704 may be

automatically retrieved and provided as the available damages/losses.

[0087] In some embodiments, each particular damage/loss in table 704 may be associated with a plurality of factors. For example, "vehicle damage" in table 704 may be associated with factors such as year, maker, and model of the vehicle, as shown in table 705. In addition, each particular damage/loss in table 704 may also be

associated with a plurality of indemnity factors. For example, table 706 illustrates a number of possible indemnity factors associated with "vehicle damage" in table 704, such as indemnity mode, limit, and deductible, etc. In some embodiments, tables 705 and 706 may be linked to the entry "vehicle damage" in table 704, such that once "vehicle damage" is selected during coverage design, damage/loss factors listed in table 705 and indemnity factors listed in table 706 may be automatically retrieved and provided.

[0088] Referring back to Fig. 6, insurance companies 120A and 120B may assemble insurance coverage using the selected peril, damage, and indemnity. As a result, the created coverage is associated with the aggregated list of factors that are associated with the peril, damage, and indemnity. Insurance companies 120A and 120B may then create an insured object, based on the associated factors.

[0089] On the next level, insurance companies 120A and 120B may create an actuary product by assembling the insurance coverage with the insured object.

Consequently, the created actuary product is associated with the aggregated list of factors that are associated with the peril, damage, indemnity, and insured object. Insurance companies 120A and 120B may further create one or more marketable products by segmenting the actuary product. For example, insurance companies 120A and 120B may set predetermined values or ranges of values for certain factors.

Therefore, each marketable product is associated with the aggregated list of factors that are associated with the peril, damage, indemnity, and insured object, where some of the factors have preset values and the remaining factors still have unknown values.

[0090] Fig. 8 illustrates a flow chart of an exemplary process 800 for creating an insurance coverage, according to some disclosed embodiments. Figs. 9A and 9B each illustrate an exemplary interface 900 for creating an insurance coverage, according to some disclosed embodiments. Process 800 starts upon receiving a selection of a risk category in step 810. As shown in Fig. 9A, user 120A/120B may select the "motor" risk category from a drop-down list 901 on interface 900.

[0091 ] Upon receiving the selection of the risk category, process 800 may identify and provide available perils and their associated damages and indemnities in step 820. In some embodiments, as shown in Fig. 9A, the available perils and associated damages may be shown in a display panel 902 on interface 900. For example, for the selected risk category "motor," display panel 902 may show available perils "collision," "fire," and "theft and robbery." The available perils and associated damages and indemnities may be obtained, for example, from tables 702, 704 and 706.

[0092] Referring back to Fig. 8, process 800 may receive selections of at least one peril type, at least one damage type, and/or at least one indemnity type. In some embodiments, a user may select the peril type, for example, by clicking on the displayed peril items in display panel 902. For example, as shown in Fig. 9A, "collision" may be selected and become highlighted on display panel 902. The user may then click on "add to coverage" button 903 to add the selected items to the new coverage. For example, selected perils and their corresponding damage items such as "vehicle damage" may be shown in display panel 904 in Fig. 9B, after being added to the coverage.

[0093] In some embodiments, a user may make indemnity type selections by checking the appropriate boxes and click on appropriate items from the drop-down lists shown on interface 900. For example, the user may select between "yes" and "no" on whether to apply AOA limit, AOP limit, and lifetime. If any of these selections is "yes," the user may be allowed to make a further selection from the corresponding drop-down list. For example, if the user selects "yes" on AOA limit, he may further select an AOA limit pattern and an AOA amount from the drop-down lists. The user may also input an amount for the deductible on interface 900.

[0094] Referring back to Fig. 8, upon receiving the selections of peril, damage and indemnity types, process 800 may proceed to identify associated factors for the selected combinations of peril, damage, and indemnity in step 840. In some

embodiments, the associated factors may be obtained from tables 703, 705, and 706, stored in database 227. In some embodiments, the associated factors may be displayed on interface 900, for example, in display panel 904 of Fig. 9B, under the corresponding perils and damages.

[0095] Process 800 may include a step 850 where an insurance-related rule is created based on one or more of the identified factors. In some embodiment, the rule may set one or more conditions for accepting or rejection an insurance application. For example, the rule may be created based on the factor "driver age" shown in display panel 904 of Fig. 9B, and the condition may be that the factor "driver age" has to have a value larger than 40 for the application to be accepted.

[0096] Process 800 may also include a step 860 where an actuary formula is created based on one or more of the identified factors. In some embodiments, the formula may be used for calculating an insurance premium. Fig. 10 illustrates an exemplary interface 1000 for creating a formula for insurance coverage, according to some disclosed embodiments. As shown in Fig. 10, a list of identified factors, including driver age and driver driving experience associated with "collision," and year, maker, and model of the vehicle associated with "vehicle damage," may be shown in a display panel 1001. In some embodiments, the user may select one or more factors from this factor list to be included in the actuary formula. For example, the user may select a factor by clicking on it, or dragging it into formula edit area 1002. The user may edit the formula in formula edit area 1002.

[0097] As an example, premium associated with a certain coverage may change based on the values of the standard factors. As an example, pricing rate of an auto coverage may be determined based on a combination of two factors: annual mileage of the car and driver's driving experience. For example, if the driver has less than a year driving experience, whereas another driver has over five-year experience of driving, prices for these two technical products may be different.

[0098] Referring back to Fig. 8, it is contemplated that process 800 may optionally include additional steps for creating other insurance related standard components, such as creating one or more insurance clauses. After these standard insurance components are created, process 800 may create insurance coverage in step 870 by assembling the components. For example, the processor may assemble the created standard peril, damage, and indemnity, and also the rule, formula and clause. In some embodiments, the insurance coverage may be created and stored as metadata.

[0099] Fig. 1 1 illustrates a flow chart of an exemplary process 1100 for creating an actuary insurance product, according to some disclosed embodiments. For example, insurance companies 120A and 120B may use insurance design software provided by insurance software provider 1 10 to perform process 1 100 to create actuary products. In step 1 1 10, the insurance design software may provide a list of standard factors. In step 1 120, process 1 100 may create an insured object. In some embodiments, the insured objects may also be previously created and provided in a database. A user may select an insured object and the insurance design software may identify, from the database, factors that are associated with the selected insured object. Metadata for the insured object may then be created based on these associated factors.

[00100] Fig. 12 illustrates an exemplary interface 1200 for creating an actuary insurance product, according to some disclosed embodiments. In some embodiments, interface 1200 may include a drop-down list 1201 for a user to select an insured object. For example, as shown in Fig. 12, the user selects "private car" as the insured object. Accordingly, the insurance design software may provide a list of standard factors associated with a "private car," according to predefined associations stored in database 227. In some embodiments, the insurance design software may then create metadata for this insured "private car" based on the associated factors. [00101] Referring back to Fig. 1 1 , process 1 100 may provide a list of insurance coverages related to the created or selected insured object in step 1 130. In some embodiments, these insurance coverages may be previously created using process 800. For example, Fig. 12 shows an exemplary list of coverage names in a display panel 1202 that are related to the insured object "private car."

[00102] Process 1 100 may receive a selection of one or more insurance coverages in step 1140. In some embodiments, the user may select coverages from the list shown in display panel 1202 to be included in the actuary product. For example, the user may select a coverage by clicking on it. In step 1 150, process 1 100 may then create the actuary product by assembling metadata of the selected coverages with the metadata of the insured object. For example, as shown in Fig. 12, an automobile insurance product may be created by assembling metadata for "private car " and metadata for certain selected coverages, such as "natural disaster insurance," and "traffic accident mental damage insurance."

[00103] Depending on the relationship between the insured object and the coverage, various types of actuary products may be created. For example, an actuary product can have one insured object paired with one set of coverage. As another example, a technical product can have more than one insured object paired with one set of coverage. If more than one insured object is paired with one set of coverage, depending on whether the insured objects have the same instance value, the actuary product may be a group product (multiple insured objects share one instance value of coverage) and a multiple insured product (multiple insured objects have individual instance values of coverage). In an exemplary embodiment, an actuary product may also include multiple risk categories.

[00104] Fig. 13 illustrates a flow chart of an exemplary process 1300 for creating a marketable insurance product, according to some disclosed embodiments. For example, insurance companies 120A and 120B may use insurance design software provided by insurance software provider 1 10 to perform process 1100 to create actuary products. In step 1310, the insurance design software may provide a list of standard factors. In step 1320, process 1300 may create an actuary insurance product. In some embodiments, the actuary insurance product may be created using process 1100.

[00105] In step 1330, process 1300 may identify one or more factors for segmenting. In some embodiments, the factors to be segmented may be indicated by a user on an interface. Fig. 14 illustrates an exemplary interface 1400 for creating a marketable insurance product, according to some disclosed embodiments. For example, interface 1400 may include areas 1401 and 1402 for user to identify factors to be segmented. As shown in Fig. 14, the factors for segmenting include insured occupation and insured age.

[00106] In step 1340, process 1300 may define values or ranges of values for the factors. In some embodiments, a user may specify these values or ranges of values on an interface. For example, area 1401 may include check boxes for the user to select the insured occupation. Area 1402 may include input fields for the user to type in value ranges for the driver's age, e.g., from 30 to 45. Once the values and ranges of values are set for the selected factors, a marketable product has been created in step 1350. Accordingly, the marketable product may include data (i.e., preset values) for the segmented factors and metadata for the remaining factors.

[00107] Fig. 15 illustrates a table 1500 containing exemplary predetermined factors for segmenting a travel insurance product, according to some disclosed embodiments. For example, the segmented factors may be associated with the insured object (who), the target travel region of the insured object (where), the covered activities (do what), and the travel duration (when). As shown in table 1500, the age of the insured traveler may be set to ranges such as 1 -17, 18-80, and 71 -80 to have the product target different demographic markets. Further, the number of insured travelers may be set to one (self), or multiple (e.g., with spouse and child) to target single, or married people. As other examples, travel destinations may be set to various domestic as well as foreign cities. Marketable products may be later distributed specifically to the target markets.

[00108] Fig. 16 illustrates a flow diagram for creating various insurance-related templates and other documents based on the standard factors, according to some disclosed embodiments. For example, for an insurance product designed using process 1 100 or 1300, the factors associated with the peril, damage, indemnity, and insured object, selected for such an insurance product, may be used to create the insurance-related templates. Consistent with the embodiments, the insurance-related templates may be created automatically by insurance company 120A/120B or client 130.

[00109] In yet some embodiments, the insurance-related template may be a discovery interface for retrieving metadata of the factors associated with a particular insurance product. For example, the discovery interface may be a programing interface, such as an application programming interface ("API"). In some embodiments, the discovery interface may retrieve metadata that indicate the data types of the factor values, e.g., number, percentage, text, date, currency, etc., and the data length, e.g., number of digits after the decimal.

[001 10] In some embodiments, the insurance-related template may be an interface created for receiving inputs of values for the various factors associated with a particular insurance product. The interface may include various fields for receiving the inputs. In some embodiments, the interface may be designed based on the metadata retrieved by the discovery interface. For example, for receiving an integer number type factor value, the interface may include a field that takes only integer numbers. If texts are input in that field, the input may be rejected and the user may be prompted to input again. If an non-integer number is input in that field, the user may be prompted to input a valid integer number, or the non-integer number may be automatically rounded to the closest integer number.

[001 1 1] In some embodiments, the interface may be a user interface ("Ul") or a graphic user interface ("GUI") for receiving inputs from a user, such as user 132 for certain factors. For example, the Ul or GUI may include check boxes, dropdown lists, input fields, or other types of fields for receiving user inputs. A user may input user- specific information, such as name, gender, age, location, driving experience of a driver, and mileage, age, and model of a car. The user may also input coverage-specific information, such as a choice of a deductible level.

[001 12] In some other embodiments, the interface may also be a programing interface for receiving input values from a service. For example, the programing interface may be an API. The input values of certain factors may be obtained from a service such as a database, a form, or other another type of public or private data source. Such factors may include, for example, number of claims in past 3 years or credit score of the insured person, etc.

[001 13] In some embodiments, the insurance-related template may be an insurance policy model template created based on the associated factors. For example, a policy model template for a particular insurance product may be created based on the factors identified as associated with that insurance product. The policy model template may include various fields to store values of the associated factors that are to be provided. When the fields are filled in with specific values, the insurance policy model template becomes an actual insurance policy model.

[001 14] In some embodiments, the insurance-related template may also be a document created based on the associated factors. The document may include various fields to store values of the associated factors that are to be provided. For example, the document may be a template of a clause, a template form, a template report, a template insurance card, and etc.

[001 15] Fig. 16 further illustrates the flow of and use of factor values, which will be described in more details in connection with Figs. 17-19. In general, as shown in Fig. 16, factor values may be input and received by the interfaces. The values may then be used to fill in the fields in those policy model templates to generate actual policy models. The values may further flow to fill in the fields of the documents, to generate actual forms, reports, and agreements, etc. The values may also be plugged into the insurance components, such as formulas, rules, and clauses. For example, premiums may be calculated when the values are applied to a formula. As another example, boundaries of the conditions may be set in the rules, so that the rules may be used to determine whether a particular application should be accepted or declined.

[001 16] Fig. 17 illustrates a flow chart of an exemplary process 1700 for processing an insurance application/claim, according to some disclosed embodiments. In some embodiments, process 1700 may start when an insurance application is received in step 1710. An insurance application may be a new application to apply for an insurance policy, a renew application to renew an existing insurance policy, or an endorsement application to request insurance endorsement.

[001 17] In step 1720, process 1700 may receive values of various factors associated with the insurance product being applied for. For example, the values may be predefined by insurance company 120A/120B or insurance software provider 1 10 and pre-programed into the insurance design software, or input by the applicant via a Ul, or obtained directly from a service by insurance company 120A/120B or client 130. In some embodiments, the values may be for factors associated with the insured object, such as a person, a car, a house, and etc.

[001 18] Process 1700 may then compare one or more of the input values with a rule, in step 1730. As disclosed previously in connection with Fig. 3, the rule may set one or more conditions for accepting or rejection an insurance application. In some embodiments, the rule may specify a value or a range of values for a certain factor. For example, the rule associated with a particular insurance product may specify that the age of the applicant has to be over 40 years old, or the driving experience of the application has to be over 2 years, or the location of the applicant's house is within a particular region (e.g., in the state of Maryland). The input values may be compared with the specified value or value range to determine whether the applicant satisfies the rule (step 1740).

[001 19] If it is determined that the rule is satisfied, the application may be accepted by insurance company 120A/120B in step 1750. Otherwise, the application may be rejected in step 1760 or forwarded to a predefined step for further processing in step 1770. For example, the application may be forwarded to an employee of insurance company 120A/120B for manual processing.

[00120] In some alternative embodiments, process 1700 may start when an application for filing an insurance claim is received. The application may be submitted by an insured (e.g., in a health insurance or a traveler's insurance), owner of the insured (e.g., in an auto insurance or a home insurance), or a third-party beneficiary (e.g., in a life insurance, or an auto insurance).

[00121] In step 1720, process 1700 may receive values of various factors associated with the insurance policy being claimed for. In some embodiments, the values may be for a risk, one or more damages, one or more insured objects, or the third-party as well as factors associated with. For example, an application to file a claim against an auto insurance policy, the inputs may include the type of accident (e.g., a collision accident), the type of damage (e.g., property damage of a vehicle involved in the collision), and the people involved in the accident (e.g., the drivers of the vehicles that collided with each other).

[00122] Process 1700 may then compare one or more of the input values with a rule, in step 1730. For example, the rule associated with a particular insurance policy may specify that property damage of a vehicle involved in a collision accident with an uninsured is covered up to $30,000, or that a cancellation of a cruise sailing due to purely weather conditions is not covered if the length of the canceled sailing is less than 2 days. The input values may be compared with the specified value or value range to determine whether the applicant satisfies the rule (step 1740).

[00123] If it is determined that the rule is satisfied, the claim may be accepted by insurance company 120A/120B in step 1750. Otherwise, the claim may be rejected in step 1760 or forwarded to a predefined step for further processing in step 1770. For example, the claim may be forwarded to an employee of insurance company

120A/120B for manual processing.

[00124] Fig. 18 illustrates a flow chart of an exemplary process 1800 for creating an insurance policy model, according to some disclosed embodiments. Process 1800 may start when values of the various factors associated with the insurance policy are received in step 1810. In some embodiments, the values may be predefined by insurance company 120A/120B or insurance software provider 1 10 and pre-programed into the insurance design software, or input by the applicant via a Ul, or obtained directly from a service by insurance company 120A/120B or client 130.

[00125] In step 1820, the values may be applied to an insurance policy model template. As disclosed previously in connection with Fig. 3, the insurance policy model template is a template insurance policy with fields to store values of the associated factors that are to be provided. Applying the values to the insurance policy model template may include storing the values in the respective fields of the policy model template. [00126] Based on the values, certain insurance calculations may be performed in step 1830. In some embodiments, the insurance calculation may include calculating a premium for the policy based on a formula. In some other embodiments, the calculation may alternatively or additionally include calculating a discount on the premium for a particular buyer. In yet some other embodiments, the calculation may include calculating a commission to be paid to an insurance agent or distributor for selling or distributing the insurance policy to a buyer. After the values are applied to the policy model template and the calculations are performed, related insurance documents may be created in step 1840 and an insurance policy model may be created in step 1850.

[00127] Fig. 19 illustrates a flow chart of an exemplary process 1900 for creating insurance analytics, according to some disclosed embodiments. Insurance software provider 1 10 or insurance company 120A/120B may perform process 1900 to create insurance analytics on a routine basis to collect statistics of factors used in insurance policies created by the insurance design software. Based on the statistics, insurance software provider 1 10 or insurance company 120A/120B may evaluate performance of the insurance design software and improve the software.

[00128] In some embodiments, process 1900 may start when a plurality of insurance policies are received in step 1910. For example, the insurance policies may be created using process 1800. In particular, data and metadata related to the factors associated with the insurance policies are received. In some embodiments, data related to claims filed against the insurance policies may also be received.

[00129] In step 1920, the values of the factors may be extracted from the received insurance policies. For example, multiple auto insurance policies issued to various households for cover their respective vehicle(s) may be received in step 1910, and the ages of the vehicles may be extracted from these policies in step 1920. Other values, such as mileages of the vehicles, locations of the vehicles, driving experience of the drivers, may also be extracted in step 1920. In some embodiments, data related to coverage selections may also be extracted, such as comprehensive or liability only, compensation limits on property damage, deductible levels on collision, etc. In some embodiments, data related to filed claims may also be extracted.

[00130] Alternative to steps 1910 and 1920, process 1900 may receive the values of the factors directly from a database, where the factors used in a plurality of insurance policies are stored.

[00131] In step 1930, insurance analytics may be created based on the extracted values. In some embodiments, the extracted values may be processed and analyzed in step 1930. For example, statistical calculations, such as regressions, interpolations, averaging, clustering, etc., may be performed on the extracted values. For example, the analytics may provide the average or median mileage of insured vehicles, and a standard deviation to indicate the variance in mileages among the insured vehicles. As another example, the statistics may provide a distribution of the driving experience, such as 10% of the drivers have less than a year of driving experience, 30% have 1 -3 years of driving experience, 40% has 3-5 years of driving experience, and 20% has more 5 years of driving experience.

[00132] In some embodiments, correlations between values of two or more factors may be calculated as part of step 1930. For example, correlations between age of the vehicle and selection of comprehensive coverage may be calculated. As another example, correlations between driving experience of the driver and the selection of a relatively high deductible (e.g., $1000 for collision accident) may be calculated. In some embodiments, correlations between factor values and the frequency of filing claims may also be determined.

[00133] The insurance analytics may be used by insurance software provider 1 10 or insurance company 120A/120B in various ways to improve the insurance design software of the insurance design processes. For example, in step 1940, insurance software provider 1 10 or insurance company 120A/120B may analyze the insurance analytics, and determine that one or more formulas and/or rules need to be updated. Additionally or alternatively, insurance software provider 1 10 or insurance company 120A/120B may find that one or more factors need to be updated.

[00134] The one or more formulas and/or rules may be updated in step 1950, and insurance software provider 1 10 or insurance company 120A/120B. For example, in step 1940, a factor may be discovered as to have a greater influence insurance pricing than initially estimated. Accordingly, the formula may be updated in step 1950 to increase the weight of that particular factor. As another example, a rule may initially specify that only insurance applicants older than 60 years are qualify for purchasing a certain product. However, in step 1940, it may be found that including applicants are slightly younger may in fact improve profitability of the product. Accordingly, the rule may be changed to reflect this founding.

[00135] In some embodiments, the one or more factors may be updated in step 1960 by insurance software provider 1 10. For example, in step 1940, a new factor may be discovered as to affect the pricing of the insurance product, and therefore should be added to the database. The new factor may be associated with the insurance contexts, such as risk, damage, indemnity, and insured object in step 1950. As another example, in step 1940, the values of an existing factor may be found to be correlated with more or less insurance contexts, and therefore the association between the factor and the insurance contexts should be amended. For example, factor "driving area" may be previously associated with risks such as "natural disaster," "fire," "falling," "theft and robbery," etc. The analytics created in step 1930 may later indicate that the factor is also correlated with risk "collision." Accordingly, the factor may be updated and associated with risk "collision" in step 1960.

[00136] Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. The scope of the invention is intended to cover any variations, uses, or adaptations of the invention following the general principles thereof and including such departures from the present disclosure as come within known or customary practice in the art. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention indicated by the following claims.

[00137] It will be appreciated that the present invention is not limited to the exact construction that has been described above and illustrated in the accompanying drawings, and that various modifications and changes can be made without departing from the scope thereof. It is intended that the scope of the invention only be limited by the appended claims.