US20110004492A1 - Dynamic adjustment of insurance premiums - Google Patents

Dynamic adjustment of insurance premiums Download PDF

Info

Publication number
US20110004492A1
US20110004492A1 US12/790,750 US79075010A US2011004492A1 US 20110004492 A1 US20110004492 A1 US 20110004492A1 US 79075010 A US79075010 A US 79075010A US 2011004492 A1 US2011004492 A1 US 2011004492A1
Authority
US
United States
Prior art keywords
input data
entity
environmental
data
source
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US12/790,750
Inventor
Paul Bradshaw
John Anthony Levin
Michael Concannon
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Certua Licensing Ltd
Quanis Inc
Original Assignee
Quanis Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Quanis Inc filed Critical Quanis Inc
Priority to US12/790,750 priority Critical patent/US20110004492A1/en
Publication of US20110004492A1 publication Critical patent/US20110004492A1/en
Assigned to QUANIS LICENSING LIMITED reassignment QUANIS LICENSING LIMITED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BRADSHAW, PAUL, CONCANNON, MICHAEL, LEVIN, JOHN ANTHONY
Assigned to QUANIS LICENSING LIMITED reassignment QUANIS LICENSING LIMITED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BRADSHAW, PAUL, CONCANNON, MICHAEL, LEVIN, JOHN ANTHONY
Assigned to Certua Licensing Limited reassignment Certua Licensing Limited ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: QUANIS LICENSING LIMITED
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/08Insurance
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/02Reservations, e.g. for tickets, services or events
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/085Payment architectures involving remote charge determination or related payment systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102Bill distribution or payments
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/389Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records

Definitions

  • Insurance is typically viewed as a form of risk management, in terms of which there is a transfer of risk from an insured party to an insurer party in exchange for a premium.
  • An insurer may be a corporation selling the insurance, while an insured (e.g., the policy holder or owner) is typically a person or an entity that is buying the insurance.
  • An insurer charges the insured a premium, which is typically a once-off or recurring monetary payment from the insured to the insurer in exchange for the assumption of the risk by the insurer.
  • Life insurance (or assurance) is typically provided in terms of a contract between a policy owner and an insurer.
  • the contract may obligate the insurer to pay a sum of money to a beneficiary specified by the policy holder upon the policy holder's death, terminal illness or catastrophic event.
  • the insurer typically calculates policy prices using mortality tables (i.e., statistically-based tables showing expected annual mortality rates).
  • mortality tables i.e., statistically-based tables showing expected annual mortality rates.
  • Main variables in mortality tables have traditionally been age, gender and use of tobacco.
  • Life insurance is often provided in two basic classes, namely temporary life insurance or permanent life insurance.
  • Temporary life insurance provides coverage for a specified term of years for a specified premium, while permanent life insurance remains in force until the relevant policy matures or pays out.
  • U.S. Pat. No. 7,395,219 describes an “insurance on demand” transaction management system that implements an intermittent risk exposure liability insurance method.
  • the method involves establishing an Internet business site enabled for communication between insurers and insured. Insureds are enrolled in intermittent risk exposure liability insurance policies. These policies provide a variable insurance premium rate depending upon an intermittent use of an insured article (e.g., a motor vehicle). The start and completion times of each intermittent use of the insured article are logged on the Internet business site by the insured. These start and completion times are verified. Premium insurance rates are applied and billed in accordance with the verified log start and completion times of use.
  • U.S. Pat. No. 5,839,118 describes linking an external computer with a system of an insurance carrier and a system of an independent lending institution to determine an optimal premium structure for a variable life insurance product, using a portion of a policy owner's money and a lending institution loan to finance a premium.
  • the system provides for the tracking of several variable life insurance policy cash values to ensure each individual policy cash value is adequate for collateral purposes.
  • FIG. 1 is a schematic diagram illustrating an insurance provisioning environment within a dynamic insurance provisioning system, according to an example embodiment.
  • FIG. 2 is a block diagram providing a high-level representation of relationships between information components of the example system, as may be processed by example methods.
  • FIG. 4 is a block diagram illustrating the architecture of a dynamic insurance provisioning system, according to an example embodiment.
  • FIG. 5 is a flowchart illustrating a method, according to an example embodiment, to determine variable life protection attributes, based on dynamic inputs.
  • FIG. 6 is a block diagram of machine in the example form of a computer system within which instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed.
  • the terms “person,” “individual,” “entity,” or “customer” are used interchangeably to refer to a party (e.g., an insured or an insurer) that interacts with a dynamic provisioning system.
  • Example embodiments include systems and methods for providing life assurance protection based on changes in individual and environmental characteristics that are partly predefined by the insured party (e.g., a customer). It should be noted that embodiments of the present invention may be utilized to provide other forms of insurance protection.
  • FIG. 1 is a schematic diagram illustrating an insurance provisioning environment within which a dynamic insurance provisioning system 100 may be deployed, according to an example embodiment.
  • the dynamic insurance provisioning system 100 is shown to be communicatively coupled by a network 102 to one or more information sources.
  • the information sources may include one or more network access devices (e.g., a personal computer system 104 ), regulatory computer systems 106 , medical data systems 108 , and financial data systems 110 .
  • the dynamic insurance provisioning system 100 may receive inputs (or input data) from one or more sources.
  • the inputs may include entity inputs (or entity input data), environmental inputs (or environmental input data), customer preference inputs (or customer preference data or customer preference input data or customer preferences), regulatory inputs (or regulatory input data), medical inputs (or medical input data), market inputs (or market input data), or other inputs.
  • the dynamic insurance provisioning system 100 may update previously received or stored input data to determine whether a risk (e.g., an underwriting risk) associated with providing an insurance policy has changed. Based on this determination, the dynamic insurance provisioning system 100 may recalculate a coverage amount, a coverage time period, or a premium of the insurance policy. In various embodiments, the dynamic insurance provisioning system 100 may initiate the updating in response to receiving a preference of an insured entity or an insuring entity regarding when (e.g., a date or a time) or how often (e.g., a frequency) a coverage amount, a coverage time period, or a premium of the insurance policy is to be updated. The dynamic insurance provisioning system 100 may amend the insurance policy based on the updating.
  • a risk e.g., an underwriting risk
  • an entity e.g., a person 112 or a corporation (e.g., via an agent) may use the personal computer system 104 or other network access device (e.g., a mobile communication device, such as a mobile phone, personal digital assistant, netbook, e-reader, and so on) to provide entity inputs (also called entity input data) or customer preference inputs to the dynamic insurance provisioning system 100 .
  • entity inputs also called entity input data
  • customer preference inputs to the dynamic insurance provisioning system 100 .
  • an entity may be a corporation that is acting (e.g., via an agent) on behalf of itself or on behalf of one or more individuals.
  • the entity may provide the entity inputs or customer preference input data using software running on the client system that accesses the dynamic insurance provisioning system 100 .
  • the dynamic insurance provisioning system 100 may receive the input data (e.g., via a publish/subscribe system or by querying interfaces (e.g., application program interfaces (APIs))).
  • An entity may also provide entity inputs or customer preference data using an out-of-band communication channel (e.g., a voice call).
  • the dynamic insurance provisioning system 100 may further receive (e.g., via the publish/subscribe system or querying interfaces) regulatory inputs in the form of regulatory information from the regulatory computer system 106 , medical information (e.g., pertaining to the person 112 or to a group of people) from the medical data systems 108 , and financial data (e.g., wealth data for the person 112 or market data pertaining to one or more markets) from the financial data systems 110 .
  • regulatory inputs in the form of regulatory information from the regulatory computer system 106
  • medical information e.g., pertaining to the person 112 or to a group of people
  • financial data e.g., wealth data for the person 112 or market data pertaining to one or more markets
  • the dynamic insurance provisioning system 100 may store the entity inputs, the customer preference data, the regulator information, the market data, or other data in storage (e.g., a database, file system, or memory; not shown). The dynamic insurance provisioning system 100 may make a decision whether to store the customer preference data based on the received entity input data. The dynamic insurance provisioning system 100 may access the data in the storage (e.g., using an operating system command, an API, or a query) for further processing or analysis.
  • storage e.g., a database, file system, or memory; not shown.
  • the dynamic insurance provisioning system 100 may access the data in the storage (e.g., using an operating system command, an API, or a query) for further processing or analysis.
  • the dynamic insurance provisioning system 100 is furthermore shown, in FIG. 1 , to be communicatively coupled via the network 102 (e.g., the Internet) to channel partner computer systems 116 and an insurer computer system 120 .
  • the channel partner computer systems 116 may be associated with the various channel partners, such as brokers, agents and financial advisors that broker and sell insurance products of an insurer associated with the insurer computer system 120 .
  • the dynamic insurance provisioning system 100 uses the various inputs from the systems 104 - 110 to dynamically calculate period commissions 114 , which are communicated to the channel partner computer systems 116 (or to bank accounts associated with the channel partners), and a period premium 118 , which is communicated to the insurer computer system 120 (or to a bank account associated with the insurer).
  • a period premium is one of a series of premiums that may be different from another one of the series of premiums.
  • the amount of the premium prior to an adjustment of the premium may be considered to be a first period premium and the amount of the premium after the adjustment may be considered to be a second period premium.
  • the amount of a premium prior to a renewal of an insurance policy may be considered to be a first period premium and the amount of the premium after the renewal of the policy may be considered to be a second period premium.
  • a period commission is one of a series of commissions that may be different from another one of the series of commissions.
  • a period commission may be associated with a period premium.
  • a period commission may be provided to a channel partner upon a renewal of an insurance policy.
  • FIG. 2 is a block diagram providing a high-level representation of relationships between information components of the example dynamic insurance provisioning system 100 , as may be processed by example methods.
  • a policy is recalculated or reissued based on customer preferences 200 that define a specified time interval and a trigger threshold for accepting input changes, which in turn generate a trigger to change the underwriting risk or coverage amount.
  • Entity inputs 202 may include one or more inputs pertaining to (or specific to) a person (e.g., individual inputs or individual input data), a corporation (e.g., corporation inputs or corporation input data), or another entity.
  • corporation inputs may include values corresponding to a corporation's size (e.g., number of employees), geographic location, or business focus.
  • individual inputs may include values corresponding to a person's health status, biometric inputs (e.g., sensed physiological or behavioral characteristics, such as fingerprint, facial, iris, gait, voice, or other characteristics), marital status, location, or age.
  • Environmental inputs 204 may include market inputs 206 (e.g., to perform a market valuation of a customer's net worth), regulatory inputs 208 (e.g., regulatory changes to determine individual liability such as inheritance/estate tax), and mortality table 210 (e.g., mortality data that refactors the underlying risk; the refactoring may include, for example, incorporating population mortality data).
  • market inputs 206 e.g., to perform a market valuation of a customer's net worth
  • regulatory inputs 208 e.g., regulatory changes to determine individual liability such as inheritance/estate tax
  • mortality table 210 e.g., mortality data that refactors the underlying risk; the refactoring may include, for example, incorporating population mortality data.
  • Data inputs may be captured through a combination of manual and automatic data feeds, such as through a biometric sensor, a manually entered cholesterol value, or an automatic updating of the customer's net worth.
  • inputs may be captured through system integration with an Internet-based portfolio administration service (e.g., a “wrap” platform, such as Aviva's Wrap and Sipp Platform or AXA's Elevate wrap platform).
  • the Internet-based portfolio administration service may be one of the financial data systems 110 of FIG. 1 .
  • the dynamic insurance provisioning system 100 recalculates the period premium amount 216 .
  • a new premium amount 216 triggers a change in the period commissions 218 paid, for example, as trail commission that can be calculated daily and paid monthly to the agent/distribution channel.
  • the adverse/anti-selection risk is significantly reduced, thus reducing the underwriting burden, speed of issuance, and overall cost.
  • Customer preferences data 200 may be categorized as personal attributes and product preferences.
  • Personal attributes include preferences for capturing personal information, such as a cell phone broadcast or a self-report for determining country location.
  • Product preferences may include time period and threshold triggers to determine when a particular input, such as net worth, is considered for recalculation of underwriting risk or coverage amount. Time period is based on time intervals, such as real time, daily, weekly, monthly, quarterly, or annual. Thresholds may be based on either absolute or percentage changes of input.
  • Input A would not trigger a recalculation of coverage amount because the value of Input A only changed 5% over the time period.
  • multiple triggers may be associated with each one of multiple inputs, including entity inputs 202 or environmental inputs 204 .
  • entity inputs 202 may be captured though automatic and manual data uploads.
  • the entity inputs may include such information as biometric data through biometric sensors, health status change through physician statements or electronic heath records, weight, body mass index (BMI), level of fitness, cholesterol, or marital status.
  • Entity inputs 202 primarily drive underwriting risk, although inputs such as marital status may combine with environmental inputs 204 to determine coverage amount (e.g., all things being equal, coverage amount for an unmarried customer will be different than coverage amount for a married customer because inheritance tax (IHT) liability is different).
  • coverage amount e.g., all things being equal, coverage amount for an unmarried customer will be different than coverage amount for a married customer because inheritance tax (IHT) liability is different).
  • the entity inputs 202 may be independently (or externally) verifiable.
  • the dynamic insurance provisioning system 100 may use a weighting mechanism to assign weights to entity inputs 202 according to an extent that such entity inputs 202 are independently verifiable. For example, the dynamic insurance provisioning system 100 may assign weights having high values to entity inputs 202 received automatically through a biometric device (indicating a relatively great level of external verifiability) and weights having low values to entity inputs 202 received as a result of manual inputs by the person 112 or other entity (indicating a relatively low level of external verifiability). The dynamic insurance provisioning system 100 may then use the weights when performing any one of various calculations, including, for example, a calculation of underwriting risk. The dynamic insurance provisioning system 100 may consider entity inputs 202 to be generally less independently verifiable than environmental inputs 204 and may therefore typically assign weights having lower values to entity inputs 202 than to environmental inputs 204 .
  • Environmental inputs 204 may be data inputs that are not specific to an entity but nevertheless impact both coverage amount 212 and underwriting risk 214 .
  • the environmental inputs may be external to the entity inputs 202 .
  • environmental inputs may come from an Internet-based portfolio administration service that tracks market changes or regulatory changes in IHT calculations that impact coverage amount 212 .
  • the market changes or regulatory changes may be categorized as environmental inputs 204 because they are not specific to an entity.
  • market changes or regulatory changes may be external to entity inputs 202 , but may include data that affects the entity inputs 202 (e.g., a customer's investment portfolio).
  • mortality tables which may contain population mortality data, may not be specific to an entity.
  • Mortality tables may be external to entity inputs 202 (e.g., automatically loaded as they are published by an external source). Mortality tables may impact the customer's underwriting risk 214 , resulting in a recalculation of the period premium 216 .
  • Environmental inputs 204 may be independently verifiable.
  • the dynamic insurance provisioning system 100 may use a weighting mechanism like the one described above with respect to entity inputs 202 to assign weights to the environmental inputs 204 .
  • the dynamic insurance provisioning system 100 may then use the weights when performing any one of various calculations, including, for example, a calculation of underwriting risk.
  • the dynamic insurance provisioning system 100 may consider environmental inputs 204 to be generally more independently verifiable than entity inputs 202 and may therefore typically assign weights having higher values to environmental inputs 204 than to entity inputs 202 .
  • a customer's underwriting risk 214 may be calculated in real-time as entity inputs 202 (e.g., customer inputs) or environmental inputs 204 are received. Changes to mortality data 210 may be manually or automatically fed into the system.
  • the customer may be provided with an option to select underwriting bands in excess of an initial coverage amount. These bands may determine the medical evidence that the customer should supply to support a coverage amount 212 within that band. Such bands may become “binding bands” at the time of policy issuance, and may allow the coverage amount 212 to flex up to that amount without requiring additional medical underwriting.
  • a customer's initial coverage may be set at 1 million Euros and may require the customer to undergo a qualifying process, such as completing a simple blood and urine test.
  • a qualifying process such as completing a simple blood and urine test.
  • the customer may choose to select a binding band of up to 5 million Euros and therefore may have to undergo an additional qualifying process, such as an electrocardiogram (EKG) or a treadmill test.
  • EKG electrocardiogram
  • This medical information may be gathered, processed, and underwritten by an underwriting information coordination (UIC) module (to be described in further detail below) and the binding band (or range) may be written into the customer's record within a dynamic risk assessor (DRA) module (also to be described in further detail below).
  • UIC underwriting information coordination
  • DAA dynamic risk assessor
  • the coverage amount 212 for the customer may be the policy face amount for the time period. It may be recalculated based on changes in environmental inputs 204 and entity inputs 202 .
  • the coverage amount 212 may be required or optional (e.g., recommended).
  • the coverage amount 212 may be required if the customer is obligated by a third party to carry an amount of insurance that corresponds to the coverage amount 212 .
  • the coverage amount 212 may be required if a mortgagor of a property contractually obligates a mortgagee to maintain an amount of insurance coverage on the property that is equal to the coverage amount 212 .
  • the coverage amount may be recommended if the customer is not obligated to a third party to maintain the coverage amount 212 .
  • the coverage amount 212 may be recommended if the customer is obtaining or managing a life insurance for no other reason than for his own peace of mind.
  • the coverage amount 212 may increase or decrease. If the coverage amount 212 is recommended, the customer may be given an option to accept the recommended amount.
  • the period for premium calculation may be determined by the customer preferences 200 .
  • a premium calculator module receives inputs (e.g., the underwriting risk 214 and the coverage amount 212 ) to determine a period premium 216 .
  • the period premiums 216 can be aggregated over a period to consolidate billing. For example, a customer may choose to set a recalculation time interval (or frequency) equal to daily. While a daily premium is calculated, the total for the month is calculated and customer is invoiced at the end of the month.
  • the recalculation frequency may, in turn, affect a frequency at which the dynamic insurance provisioning system 100 initiates a receiving of updates of input data.
  • the amount of commission 218 paid to distributors may be set as a function of premium earned.
  • the commission 218 may be earned on a time interval basis and from that basis a variable trail-based commission may be paid.
  • a trail commission tracker component tracks and disburses commissions 218 to the appropriate distribution stakeholders. Commission 218 may be paid on the sum of one or more period premiums 216 .
  • FIG. 4 is a block diagram illustrating the architecture of a dynamic insurance provisioning system 400 , according to an example embodiment.
  • the system 400 is shown to comprise a number of modules that receive inputs 402 (e.g., the inputs 202 and 204 discussed above with reference to FIG. 2 ) and interact with each other to provide outputs 404 (e.g., a policy, premium, period cover, or commission amount).
  • inputs 402 e.g., the inputs 202 and 204 discussed above with reference to FIG. 2
  • outputs 404 e.g., a policy, premium, period cover, or commission amount
  • a value integration (VI) module 406 builds, tracks, and verifies the customer's net worth.
  • the VI module 406 includes a manual data entry interface and automatic data integration component (not shown) for gathering and monitoring the customer's total net worth.
  • the data integration component integrates with third-party systems and information feeds to determine the value of the customer's portfolio.
  • This integration channel uses a multi-channel (e.g., HyperText Transfer Protocol (HTTP), HyperText Transfer Protocol Secure (HTTPS), Web Service, or File Transfer Protocol (FTP)) architecture to automatically receive updates of the value of all classes of assets such as stocks, bonds, warrants, annuities, pensions, art, collectibles and property.
  • HTTP HyperText Transfer Protocol
  • HTTPS HyperText Transfer Protocol Secure
  • FTP File Transfer Protocol
  • a manual data entry system For assets not automatically updatable, a manual data entry system, using HTTPS, is used to capture asset value. Customers and system users have access to view and update assets or asset values based on system controlled workflow and approval. For each asset an independent valuation attribute is set and a process for updating and validating values is set.
  • a customer information (CI) module 408 captures customer preferences (e.g., attribute and product preferences), customer information such as living location, and marital status, and regulatory information, such as IHT rules. Customer preferences for medical underwriting bands are specified in the CI module 408 , and requests are made to an underwriting information coordination (UIC) module 410 to schedule examinations, if a determination is made that the customer should provide additional medical information based on a limit of the binding band being reached. Data are updated in the CI module 408 through manual updates using a web browser, or auto data feeds such as the customer's cell phone location signal or third party feeds. The CI module 408 may also specify how much a premium or coverage amount can change without triggering the need for the customer to accept or reject the change.
  • customer preferences e.g., attribute and product preferences
  • customer information such as living location, and marital status
  • regulatory information such as IHT rules.
  • Customer preferences for medical underwriting bands are specified in the CI module 408 , and requests are made to an underwriting information
  • An underwriting information coordination (UIC) module 410 determines and gathers information requirements to support manual and automatic underwriting decision making.
  • the UIC module 410 collects customer information, diagnoses medical information requirements based on the product and customer preferences set, schedules the examination or collection of information, collects the medical information, and provides the information to an underwriting and administration (UA) module 414 .
  • the medical underwriting bands are presented to the customer at a time of scheduling through the CI module 408 , allowing for the customer to opt-in for a higher ceiling in the policy binding band to accommodate for greater flex (or range) in coverage amount.
  • a health and wellness (HW) module 412 provides functionality to measure, monitor and facilitate positive health for the customer. For example, the HW module 412 receives manual and automatic data feeds on a customer's weight, BMI, level of fitness, cholesterol, or smoking habits. The HW module 412 has functionality for requisitioning and managing physician statements or electronic heath records.
  • the HW module 412 also contains an online survey administration tool for health risk assessment (HRA), and a time-based data model to track and report on changes in customer health.
  • HRA health risk assessment
  • Each information element is attributed with an independently verified source flag and system for updating if independently verifiable.
  • each element may be associated with metadata that includes an indicator of whether the information element has been independently verified or an identifier of a system that has performed (or is capable of performing) independent verification of the information element.
  • the HW module 412 may receive entity input data related to a level of fitness of an insured entity (e.g., via the online survey administration tool). Based on a determination that the entity input data has not been independently verified, the HW module 412 may select a source of additional input data.
  • the selection may be based on an ability of the source to provide input data that can be used to independently verify the entity input data (e.g., a source capable of providing EKG or a biometric input data to verify a level of fitness).
  • the HW module 412 may associate metadata with an information element (e.g., the level of fitness of the insured entity) that indicates whether the information has been independently verified.
  • the HW module 412 contains tools and functionality to enable an insurer to interact with a customer to help manage his/her health.
  • the HW module 412 may share the same customer presentation layer as the CI module 408 .
  • An underwriting and administration (UA) module 414 takes real-time data inputs from the other system modules to calculate risk, premium and commission amounts.
  • the UA module 414 generates a new or amended policy, such as new premium, period cover, or commission amounts for a defined time period.
  • the UA module 414 comprises a database and application layer.
  • a dynamic risk assessment (DRA) component 416 receives inputs (e.g., updates previously received inputs) and contains business logic for determining if a premium calculation or recalculation is necessary and possible based on changes in the customer's risk profile. Based on preset tolerances or thresholds, if a change in one or more input variables such as smoker status, health status, travel/residency, avocation/hazardous pursuits occurs and is within the binding bank, the DRA component 416 passes the appropriate value to a premium calculation (PC) component 418 .
  • PC premium calculation
  • the PC component 418 may perform a calculation of the premium, including a calculation of a period premium or an aggregating of the premium over a period of time.
  • the PC component 418 may calculate one or more amounts of one or more payments of the premium based on input data, including entity input data, environmental input data, or customer preference data. For example, the PC component 418 may determine that an entity should pay the premium in a single payment or in multiple payments based on input data received from a wrap platform. Additionally, the PC component 418 may determine that entity should make payments at one or more specific dates, over a specific time period, or with a specific frequency based on customer preference data (e.g., preferences of an insured entity or an insuring entity). The PC component 418 may perform the calculation in real-time. An illustration of a calculated premium for a joint life policy is provided below.
  • Step 1 The system calculates the current age based on the coverage start date.
  • t Age d CoverStart - d Birthday 365.25
  • the PC component 418 identifies the rate tables based on Gender, Health and Smoking Status.
  • T Preferred f(gender, health, smoking)
  • Step 3 The PC component 418 selects the mortality rate table for the person given the age at the beginning of the coverage and the current year.
  • q Mortality f (t Age , t Year )
  • the mortality rate table may be organized such that look ups are based on the age at the start of coverage and the current year as of the calculation. For example, a person being born on Jul. 14, 1971, starting coverage on Dec.
  • r JLF 1000 * ( r Life ⁇ ⁇ 1 + r Life ⁇ ⁇ 2 1000 - r Life ⁇ ⁇ 1 * r Life ⁇ ⁇ 2 1000 2 )
  • the Core Price is calculated on a yearly basis and can be interpolated for a user defined Time Period Note 2: The Core Price is based on the mortality rate for each life, the assured value, and the cost of the policy.
  • a trail commission tracker (TCT) component 420 calculates and tracks commissions paid to the partners in the distribution channel, such as agents, brokers and financial advisors. Partners can view and model commission revenue flow using this tool. Commission transparency is provided using an online tool to access data within the TCT component 420 .
  • the UA module 414 may include a coverage amount component (not shown) to calculate a new coverage amount for an insurance policy based on one or more data inputs. Additionally, the UA module 414 may include a coverage time period component (not shown) to calculate a new coverage time period for an insurance policy based on one more data inputs.
  • FIG. 5 is a flowchart illustrating a method 500 , according to an example embodiment, to determine variable life protection attributes, based on dynamic inputs.
  • a given time interval defined by customer preference in the CI module 408
  • customer life attributes 502 of cholesterol and weight have increased slightly and the data are manually entered into the HW module 412 .
  • the updated cholesterol and weight data are fed into the DRA component 416 to determine if a rate recalculation is necessary.
  • the changes in cholesterol and weight are within tolerances set by the underwriters using the DRA component 416 and the rate remains the same for the next time interval period if all other variables remained constant.
  • the CI module 408 assesses the new regulations 504 against the customer profile, and the changed marital status. This information, combined with regulatory changes, determines a recalculation of inheritance tax is required. The customer new tax liability is calculated.
  • the VI module 406 identifies that the customer's net worth 506 changed, triggered by a 15% decline in the customer's stock portfolio, while the customers other assets remained unchanged.
  • the customer's trigger threshold is set at 5% within the CI module 408 and therefore the 15% decline in stock portfolio is sufficient to trigger a request to the CI module 408 to recalculate IHT.
  • the CI module 408 iteratively calculates the impact of the new coverage amount on IHT combined with changes in regulatory environment and marital status. A new coverage amount is either required or recommended.
  • the premium calculation (PC) module 418 receives a request from the CI module 408 to calculate a new period premium based on a net increase in coverage required or recommended primarily due to the customer relocating to Ukraine and having an increased tax liability.
  • the PC module 418 checks with the DRA module 416 to determine if the customer's risk profile changed. In this example, the change in cholesterol and weight does not trigger a risk revaluation.
  • the PC module 418 also checks with the UIC module 410 to determine if the increase in coverage is within the medical underwriting band. The increase in coverage is within the medical underwriting binding band and the increase in the premium does not exceed a threshold specified in the CI module 408 that would trigger the need for the customer to accept or reject the premium increase; therefore, coverage was automatically provided.
  • the new premium amount is calculated and the premium amount sent to the TCT module 420 to calculate and disburse trail commission payment to the customer's broker.
  • Modules may constitute either software modules (e.g., code embodied on a machine-readable storage medium or in a transmission signal) or hardware modules or devices.
  • a device is tangible unit capable of performing certain operations and may be configured or arranged in a certain manner.
  • one or more computer systems e.g., a standalone, client or server computer system
  • one or more components of a computer system e.g., a processor or a group of processors
  • software e.g., an application or application portion
  • a device may be implemented mechanically or electronically.
  • a device may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations.
  • a device may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a device mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.
  • the term “device” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired) or temporarily configured (e.g., programmed) to operate in a certain manner and/or to perform certain operations described herein.
  • devices are temporarily configured (e.g., programmed)
  • each of the devices need not be configured or instantiated at any one instance in time.
  • the devices comprise a general-purpose processor configured using software
  • the general-purpose processor may be configured as respective different devices at different times.
  • Software may accordingly configure a processor, for example, to constitute a particular device at one instance of time and to constitute a different device at a different instance of time.
  • Devices can provide information to, and receive information from, other devices. Accordingly, the described devices may be regarded as being communicatively coupled. Where multiple of such devices exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses) that connect the devices. In embodiments in which multiple devices are configured or instantiated at different times, communications between such devices may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple devices have access. For example, one device may perform an operation, and store the output of that operation in a memory device to which it is communicatively coupled. A further device may then, at a later time, access the memory device to retrieve and process the stored output. Devices may also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information).
  • a resource e.g., a collection of information
  • processors may be temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules or devices that operate to perform one or more operations or functions.
  • the modules referred to herein may, in some example embodiments, comprise processor-implemented modules or devices.
  • the methods described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or processors or processor-implemented modules or devices. The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the processor or processors may be located in a single location (e.g., within a home environment, an office environment or as a server farm), while in other embodiments the processors may be distributed across a number of locations.
  • the one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., Application Program Interfaces (APIs).)
  • SaaS software as a service
  • Example embodiments may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them.
  • Example embodiments may be implemented using a computer program product, e.g., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage medium for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers.
  • a computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, subroutine, or other unit suitable for use in a computing environment.
  • a computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
  • operations may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output.
  • Method operations can also be performed by, and apparatus of example embodiments may be implemented as, special purpose logic circuitry, e.g., a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC).
  • FPGA field programmable gate array
  • ASIC application-specific integrated circuit
  • the computing system can include clients and servers.
  • a client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
  • both hardware and software architectures require consideration.
  • the choice of whether to implement certain functionality in permanently configured hardware e.g., an ASIC
  • temporarily configured hardware e.g., a combination of software and a programmable processor
  • a combination of permanently and temporarily configured hardware may be a design choice.
  • hardware e.g., machine
  • software architectures that may be deployed, in various example embodiments.
  • FIG. 6 is a block diagram of machine in the example form of a computer system 600 within which instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed.
  • the machine operates as a standalone device or may be connected (e.g., networked) to other machines.
  • the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.
  • the machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine.
  • PC personal computer
  • PDA Personal Digital Assistant
  • STB set-top box
  • WPA Personal Digital Assistant
  • a cellular telephone a web appliance
  • network router switch or bridge
  • machine any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine.
  • machine shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
  • the example computer system 600 includes a processor 602 (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory 604 and a static memory 606 , which communicate with each other via a bus 608 .
  • the computer system 600 may further include a video display unit 610 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)).
  • the computer system 600 also includes an alphanumeric input device 612 (e.g., a keyboard), a user interface (UI) navigation device 614 (e.g., a mouse), a disk drive unit 616 , a signal generation device 618 (e.g., a speaker) and a network interface device 620 .
  • a processor 602 e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both
  • main memory 604 e.g., RAM
  • static memory 606 e.g.,
  • the disk drive unit 616 includes a machine-readable storage medium 622 on which is stored one or more sets of instructions and data structures (e.g., software) 624 embodying or utilized by any one or more of the methodologies or functions described herein.
  • the instructions 624 may also reside, completely or at least partially, within the main memory 604 and/or within the processor 602 during execution thereof by the computer system 600 , the main memory 604 and the processor 602 also constituting machine-readable media.
  • machine-readable storage medium 622 is shown in an example embodiment to be a single medium, the term “machine-readable storage medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions or data structures.
  • the term “machine-readable storage medium” shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention, or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions.
  • the term “machine-readable storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media.
  • machine-readable storage media include non-volatile memory, including by way of example semiconductor memory devices, e.g., Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.
  • semiconductor memory devices e.g., Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), and flash memory devices
  • EPROM Erasable Programmable Read-Only Memory
  • EEPROM Electrically Erasable Programmable Read-Only Memory
  • flash memory devices e.g., electrically Erasable Programmable Read-Only Memory (EEPROM), and flash memory devices
  • magnetic disks such as internal hard disks and removable disks
  • magneto-optical disks e.g., magneto-optical disks
  • the instructions 624 may further be transmitted or received over a communications network 626 using a transmission medium.
  • the instructions 624 may be transmitted using the network interface device 620 and any one of a number of well-known transfer protocols (e.g., HTTP).
  • Examples of communication networks include a local area network (“LAN”), a wide area network (“WAN”), the Internet, mobile telephone networks, Plain Old Telephone (POTS) networks, and wireless data networks (e.g., WiFi and WiMax networks).
  • POTS Plain Old Telephone
  • the term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible media to facilitate communication of such software.

Abstract

A method to dynamically adjust a premium of an insurance policy is disclosed. At least one of an entity input data or an environmental input data is updated by a dynamic insurance provisioning system, the entity input data being an input data that is specific to an entity insured by the insurance policy and the environmental input data being additional input data that is not being specific to the entity. A determination is made as to whether a risk associated with providing the insurance policy has changed based on the updating of the at least one of the entity input data and the environmental input data. Responsive to the determination, the premium of the insurance policy is recalculated.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • This application claims the priority benefit of U.S. Provisional Application No. 61/182,589, entitled, “Variable Life Protection Base on Dynamic Inputs,” filed May 29, 2009, which is hereby incorporated herein by reference in its entirety.
  • BACKGROUND
  • Insurance is typically viewed as a form of risk management, in terms of which there is a transfer of risk from an insured party to an insurer party in exchange for a premium. An insurer may be a corporation selling the insurance, while an insured (e.g., the policy holder or owner) is typically a person or an entity that is buying the insurance. An insurer charges the insured a premium, which is typically a once-off or recurring monetary payment from the insured to the insurer in exchange for the assumption of the risk by the insurer. There are many types of insurance, such as auto insurance, home insurance, health insurance, disability insurance, casualty insurance, life insurance, and credit insurance, to name but a few.
  • Life insurance (or assurance) is typically provided in terms of a contract between a policy owner and an insurer. The contract may obligate the insurer to pay a sum of money to a beneficiary specified by the policy holder upon the policy holder's death, terminal illness or catastrophic event.
  • The insurer typically calculates policy prices using mortality tables (i.e., statistically-based tables showing expected annual mortality rates). Main variables in mortality tables have traditionally been age, gender and use of tobacco.
  • Life insurance is often provided in two basic classes, namely temporary life insurance or permanent life insurance. Temporary life insurance provides coverage for a specified term of years for a specified premium, while permanent life insurance remains in force until the relevant policy matures or pays out.
  • U.S. Pat. No. 7,395,219 describes an “insurance on demand” transaction management system that implements an intermittent risk exposure liability insurance method. The method involves establishing an Internet business site enabled for communication between insurers and insured. Insureds are enrolled in intermittent risk exposure liability insurance policies. These policies provide a variable insurance premium rate depending upon an intermittent use of an insured article (e.g., a motor vehicle). The start and completion times of each intermittent use of the insured article are logged on the Internet business site by the insured. These start and completion times are verified. Premium insurance rates are applied and billed in accordance with the verified log start and completion times of use.
  • U.S. Pat. No. 5,839,118 describes linking an external computer with a system of an insurance carrier and a system of an independent lending institution to determine an optimal premium structure for a variable life insurance product, using a portion of a policy owner's money and a lending institution loan to finance a premium. The system provides for the tracking of several variable life insurance policy cash values to ensure each individual policy cash value is adequate for collateral purposes.
  • BRIEF DESCRIPTION OF DRAWINGS
  • Some embodiments are illustrated by way of example and not limited in the figures of the accompanying drawings in which:
  • FIG. 1 is a schematic diagram illustrating an insurance provisioning environment within a dynamic insurance provisioning system, according to an example embodiment.
  • FIG. 2 is a block diagram providing a high-level representation of relationships between information components of the example system, as may be processed by example methods.
  • FIG. 3 is a graph that provides an example for a scenario in which a customer preference for sampling net worth (Input A) is set to a time period of 1 week (t2−t1=1 week) and a trigger threshold is set to 10%.
  • FIG. 4 is a block diagram illustrating the architecture of a dynamic insurance provisioning system, according to an example embodiment.
  • FIG. 5 is a flowchart illustrating a method, according to an example embodiment, to determine variable life protection attributes, based on dynamic inputs.
  • FIG. 6 is a block diagram of machine in the example form of a computer system within which instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed.
  • DETAILED DESCRIPTION
  • In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of some example embodiments. It will be evident, however, to one skilled in the art that the subject matter of this disclosure may be practiced without these specific details.
  • As used herein, the terms “person,” “individual,” “entity,” or “customer” are used interchangeably to refer to a party (e.g., an insured or an insurer) that interacts with a dynamic provisioning system.
  • Example embodiments include systems and methods for providing life assurance protection based on changes in individual and environmental characteristics that are partly predefined by the insured party (e.g., a customer). It should be noted that embodiments of the present invention may be utilized to provide other forms of insurance protection.
  • FIG. 1 is a schematic diagram illustrating an insurance provisioning environment within which a dynamic insurance provisioning system 100 may be deployed, according to an example embodiment. The dynamic insurance provisioning system 100 is shown to be communicatively coupled by a network 102 to one or more information sources. The information sources may include one or more network access devices (e.g., a personal computer system 104), regulatory computer systems 106, medical data systems 108, and financial data systems 110. The dynamic insurance provisioning system 100 may receive inputs (or input data) from one or more sources. The inputs may include entity inputs (or entity input data), environmental inputs (or environmental input data), customer preference inputs (or customer preference data or customer preference input data or customer preferences), regulatory inputs (or regulatory input data), medical inputs (or medical input data), market inputs (or market input data), or other inputs.
  • In various embodiments, the dynamic insurance provisioning system 100 may update previously received or stored input data to determine whether a risk (e.g., an underwriting risk) associated with providing an insurance policy has changed. Based on this determination, the dynamic insurance provisioning system 100 may recalculate a coverage amount, a coverage time period, or a premium of the insurance policy. In various embodiments, the dynamic insurance provisioning system 100 may initiate the updating in response to receiving a preference of an insured entity or an insuring entity regarding when (e.g., a date or a time) or how often (e.g., a frequency) a coverage amount, a coverage time period, or a premium of the insurance policy is to be updated. The dynamic insurance provisioning system 100 may amend the insurance policy based on the updating.
  • For example, an entity (e.g., a person 112 or a corporation (e.g., via an agent)) may use the personal computer system 104 or other network access device (e.g., a mobile communication device, such as a mobile phone, personal digital assistant, netbook, e-reader, and so on) to provide entity inputs (also called entity input data) or customer preference inputs to the dynamic insurance provisioning system 100. In an example embodiment, an entity may be a corporation that is acting (e.g., via an agent) on behalf of itself or on behalf of one or more individuals. The entity may provide the entity inputs or customer preference input data using software running on the client system that accesses the dynamic insurance provisioning system 100.
  • The dynamic insurance provisioning system 100 may receive the input data (e.g., via a publish/subscribe system or by querying interfaces (e.g., application program interfaces (APIs))). An entity may also provide entity inputs or customer preference data using an out-of-band communication channel (e.g., a voice call). The dynamic insurance provisioning system 100 may further receive (e.g., via the publish/subscribe system or querying interfaces) regulatory inputs in the form of regulatory information from the regulatory computer system 106, medical information (e.g., pertaining to the person 112 or to a group of people) from the medical data systems 108, and financial data (e.g., wealth data for the person 112 or market data pertaining to one or more markets) from the financial data systems 110.
  • The dynamic insurance provisioning system 100 may store the entity inputs, the customer preference data, the regulator information, the market data, or other data in storage (e.g., a database, file system, or memory; not shown). The dynamic insurance provisioning system 100 may make a decision whether to store the customer preference data based on the received entity input data. The dynamic insurance provisioning system 100 may access the data in the storage (e.g., using an operating system command, an API, or a query) for further processing or analysis.
  • The dynamic insurance provisioning system 100 is furthermore shown, in FIG. 1, to be communicatively coupled via the network 102 (e.g., the Internet) to channel partner computer systems 116 and an insurer computer system 120. The channel partner computer systems 116 may be associated with the various channel partners, such as brokers, agents and financial advisors that broker and sell insurance products of an insurer associated with the insurer computer system 120. The dynamic insurance provisioning system 100, as will be described in detail below, uses the various inputs from the systems 104-110 to dynamically calculate period commissions 114, which are communicated to the channel partner computer systems 116 (or to bank accounts associated with the channel partners), and a period premium 118, which is communicated to the insurer computer system 120 (or to a bank account associated with the insurer). A period premium is one of a series of premiums that may be different from another one of the series of premiums. For example, with respect to an insurance policy having an adjustable premium, the amount of the premium prior to an adjustment of the premium may be considered to be a first period premium and the amount of the premium after the adjustment may be considered to be a second period premium. As another example, the amount of a premium prior to a renewal of an insurance policy may be considered to be a first period premium and the amount of the premium after the renewal of the policy may be considered to be a second period premium. Similarly, a period commission is one of a series of commissions that may be different from another one of the series of commissions. A period commission may be associated with a period premium. For example, a period commission may be provided to a channel partner upon a renewal of an insurance policy.
  • FIG. 2 is a block diagram providing a high-level representation of relationships between information components of the example dynamic insurance provisioning system 100, as may be processed by example methods. A policy is recalculated or reissued based on customer preferences 200 that define a specified time interval and a trigger threshold for accepting input changes, which in turn generate a trigger to change the underwriting risk or coverage amount.
  • Entity inputs 202 may include one or more inputs pertaining to (or specific to) a person (e.g., individual inputs or individual input data), a corporation (e.g., corporation inputs or corporation input data), or another entity. Examples of corporation inputs may include values corresponding to a corporation's size (e.g., number of employees), geographic location, or business focus. Examples of individual inputs may include values corresponding to a person's health status, biometric inputs (e.g., sensed physiological or behavioral characteristics, such as fingerprint, facial, iris, gait, voice, or other characteristics), marital status, location, or age.
  • Environmental inputs 204 may include market inputs 206 (e.g., to perform a market valuation of a customer's net worth), regulatory inputs 208 (e.g., regulatory changes to determine individual liability such as inheritance/estate tax), and mortality table 210 (e.g., mortality data that refactors the underlying risk; the refactoring may include, for example, incorporating population mortality data).
  • Data inputs (or inputs), including entity inputs 202 and environmental inputs 204, may be captured through a combination of manual and automatic data feeds, such as through a biometric sensor, a manually entered cholesterol value, or an automatic updating of the customer's net worth. For example, inputs may be captured through system integration with an Internet-based portfolio administration service (e.g., a “wrap” platform, such as Aviva's Wrap and Sipp Platform or AXA's Elevate wrap platform). The Internet-based portfolio administration service may be one of the financial data systems 110 of FIG. 1.
  • If a change in input causes a change in coverage amount 212 or underwriting risk 214, then the dynamic insurance provisioning system 100 recalculates the period premium amount 216. A new premium amount 216 triggers a change in the period commissions 218 paid, for example, as trail commission that can be calculated daily and paid monthly to the agent/distribution channel.
  • By having the coverage amount based on independently verifiable external variables, such as customer's net worth or current inheritance/estate tax calculations, the adverse/anti-selection risk is significantly reduced, thus reducing the underwriting burden, speed of issuance, and overall cost.
  • Further details of the example information components shown in FIG. 2 are now discussed.
  • Customer preferences data 200 may be categorized as personal attributes and product preferences. Personal attributes include preferences for capturing personal information, such as a cell phone broadcast or a self-report for determining country location. Product preferences may include time period and threshold triggers to determine when a particular input, such as net worth, is considered for recalculation of underwriting risk or coverage amount. Time period is based on time intervals, such as real time, daily, weekly, monthly, quarterly, or annual. Thresholds may be based on either absolute or percentage changes of input.
  • FIG. 3 shows a graph 300 that provides an example of a scenario in which a customer preference for sampling net worth (Input A) is set to time period of 1 week (t2−t1=1 week) and a trigger threshold is set to 10%. In the graphed example, Input A would not trigger a recalculation of coverage amount because the value of Input A only changed 5% over the time period. In other scenarios, multiple triggers may be associated with each one of multiple inputs, including entity inputs 202 or environmental inputs 204.
  • Referring back to FIG. 2, entity inputs 202 may be captured though automatic and manual data uploads. The entity inputs may include such information as biometric data through biometric sensors, health status change through physician statements or electronic heath records, weight, body mass index (BMI), level of fitness, cholesterol, or marital status. Entity inputs 202 primarily drive underwriting risk, although inputs such as marital status may combine with environmental inputs 204 to determine coverage amount (e.g., all things being equal, coverage amount for an unmarried customer will be different than coverage amount for a married customer because inheritance tax (IHT) liability is different).
  • The entity inputs 202 may be independently (or externally) verifiable. The dynamic insurance provisioning system 100 may use a weighting mechanism to assign weights to entity inputs 202 according to an extent that such entity inputs 202 are independently verifiable. For example, the dynamic insurance provisioning system 100 may assign weights having high values to entity inputs 202 received automatically through a biometric device (indicating a relatively great level of external verifiability) and weights having low values to entity inputs 202 received as a result of manual inputs by the person 112 or other entity (indicating a relatively low level of external verifiability). The dynamic insurance provisioning system 100 may then use the weights when performing any one of various calculations, including, for example, a calculation of underwriting risk. The dynamic insurance provisioning system 100 may consider entity inputs 202 to be generally less independently verifiable than environmental inputs 204 and may therefore typically assign weights having lower values to entity inputs 202 than to environmental inputs 204.
  • Environmental inputs 204 may be data inputs that are not specific to an entity but nevertheless impact both coverage amount 212 and underwriting risk 214. The environmental inputs may be external to the entity inputs 202. For example, environmental inputs may come from an Internet-based portfolio administration service that tracks market changes or regulatory changes in IHT calculations that impact coverage amount 212. The market changes or regulatory changes may be categorized as environmental inputs 204 because they are not specific to an entity. Furthermore, market changes or regulatory changes may be external to entity inputs 202, but may include data that affects the entity inputs 202 (e.g., a customer's investment portfolio).
  • It will also be appreciated that mortality tables, which may contain population mortality data, may not be specific to an entity. Mortality tables may be external to entity inputs 202 (e.g., automatically loaded as they are published by an external source). Mortality tables may impact the customer's underwriting risk 214, resulting in a recalculation of the period premium 216.
  • Environmental inputs 204 may be independently verifiable. The dynamic insurance provisioning system 100 may use a weighting mechanism like the one described above with respect to entity inputs 202 to assign weights to the environmental inputs 204. The dynamic insurance provisioning system 100 may then use the weights when performing any one of various calculations, including, for example, a calculation of underwriting risk. The dynamic insurance provisioning system 100 may consider environmental inputs 204 to be generally more independently verifiable than entity inputs 202 and may therefore typically assign weights having higher values to environmental inputs 204 than to entity inputs 202.
  • A customer's underwriting risk 214 may be calculated in real-time as entity inputs 202 (e.g., customer inputs) or environmental inputs 204 are received. Changes to mortality data 210 may be manually or automatically fed into the system. At the time of initial underwriting, the customer may be provided with an option to select underwriting bands in excess of an initial coverage amount. These bands may determine the medical evidence that the customer should supply to support a coverage amount 212 within that band. Such bands may become “binding bands” at the time of policy issuance, and may allow the coverage amount 212 to flex up to that amount without requiring additional medical underwriting. For example, a customer's initial coverage may be set at 1 million Euros and may require the customer to undergo a qualifying process, such as completing a simple blood and urine test. At time of medical underwriting, the customer may choose to select a binding band of up to 5 million Euros and therefore may have to undergo an additional qualifying process, such as an electrocardiogram (EKG) or a treadmill test. This medical information may be gathered, processed, and underwritten by an underwriting information coordination (UIC) module (to be described in further detail below) and the binding band (or range) may be written into the customer's record within a dynamic risk assessor (DRA) module (also to be described in further detail below).
  • The coverage amount 212 for the customer may be the policy face amount for the time period. It may be recalculated based on changes in environmental inputs 204 and entity inputs 202. The coverage amount 212 may be required or optional (e.g., recommended). For example, the coverage amount 212 may be required if the customer is obligated by a third party to carry an amount of insurance that corresponds to the coverage amount 212. For example, the coverage amount 212 may be required if a mortgagor of a property contractually obligates a mortgagee to maintain an amount of insurance coverage on the property that is equal to the coverage amount 212. Alternatively, the coverage amount may be recommended if the customer is not obligated to a third party to maintain the coverage amount 212. For example, the coverage amount 212 may be recommended if the customer is obtaining or managing a life insurance for no other reason than for his own peace of mind. The coverage amount 212 may increase or decrease. If the coverage amount 212 is recommended, the customer may be given an option to accept the recommended amount.
  • The period for premium calculation may be determined by the customer preferences 200. A premium calculator module, described in further detail below, receives inputs (e.g., the underwriting risk 214 and the coverage amount 212) to determine a period premium 216. The period premiums 216 can be aggregated over a period to consolidate billing. For example, a customer may choose to set a recalculation time interval (or frequency) equal to daily. While a daily premium is calculated, the total for the month is calculated and customer is invoiced at the end of the month. The recalculation frequency may, in turn, affect a frequency at which the dynamic insurance provisioning system 100 initiates a receiving of updates of input data.
  • The amount of commission 218 paid to distributors (e.g., agents, brokers, or independent financial advisors (IFAS)) may be set as a function of premium earned. The commission 218 may be earned on a time interval basis and from that basis a variable trail-based commission may be paid. A trail commission tracker component, described in further detail below, tracks and disburses commissions 218 to the appropriate distribution stakeholders. Commission 218 may be paid on the sum of one or more period premiums 216.
  • FIG. 4 is a block diagram illustrating the architecture of a dynamic insurance provisioning system 400, according to an example embodiment. The system 400 is shown to comprise a number of modules that receive inputs 402 (e.g., the inputs 202 and 204 discussed above with reference to FIG. 2) and interact with each other to provide outputs 404 (e.g., a policy, premium, period cover, or commission amount). The individual components of the system 400 are now discussed.
  • A value integration (VI) module 406 builds, tracks, and verifies the customer's net worth. The VI module 406 includes a manual data entry interface and automatic data integration component (not shown) for gathering and monitoring the customer's total net worth. The data integration component integrates with third-party systems and information feeds to determine the value of the customer's portfolio. This integration channel uses a multi-channel (e.g., HyperText Transfer Protocol (HTTP), HyperText Transfer Protocol Secure (HTTPS), Web Service, or File Transfer Protocol (FTP)) architecture to automatically receive updates of the value of all classes of assets such as stocks, bonds, warrants, annuities, pensions, art, collectibles and property. For assets not automatically updatable, a manual data entry system, using HTTPS, is used to capture asset value. Customers and system users have access to view and update assets or asset values based on system controlled workflow and approval. For each asset an independent valuation attribute is set and a process for updating and validating values is set.
  • A customer information (CI) module 408 captures customer preferences (e.g., attribute and product preferences), customer information such as living location, and marital status, and regulatory information, such as IHT rules. Customer preferences for medical underwriting bands are specified in the CI module 408, and requests are made to an underwriting information coordination (UIC) module 410 to schedule examinations, if a determination is made that the customer should provide additional medical information based on a limit of the binding band being reached. Data are updated in the CI module 408 through manual updates using a web browser, or auto data feeds such as the customer's cell phone location signal or third party feeds. The CI module 408 may also specify how much a premium or coverage amount can change without triggering the need for the customer to accept or reject the change.
  • An underwriting information coordination (UIC) module 410 determines and gathers information requirements to support manual and automatic underwriting decision making. The UIC module 410 collects customer information, diagnoses medical information requirements based on the product and customer preferences set, schedules the examination or collection of information, collects the medical information, and provides the information to an underwriting and administration (UA) module 414. The medical underwriting bands are presented to the customer at a time of scheduling through the CI module 408, allowing for the customer to opt-in for a higher ceiling in the policy binding band to accommodate for greater flex (or range) in coverage amount.
  • A health and wellness (HW) module 412 provides functionality to measure, monitor and facilitate positive health for the customer. For example, the HW module 412 receives manual and automatic data feeds on a customer's weight, BMI, level of fitness, cholesterol, or smoking habits. The HW module 412 has functionality for requisitioning and managing physician statements or electronic heath records.
  • The HW module 412 also contains an online survey administration tool for health risk assessment (HRA), and a time-based data model to track and report on changes in customer health. Each information element is attributed with an independently verified source flag and system for updating if independently verifiable. In one instance, each element may be associated with metadata that includes an indicator of whether the information element has been independently verified or an identifier of a system that has performed (or is capable of performing) independent verification of the information element. For example, the HW module 412 may receive entity input data related to a level of fitness of an insured entity (e.g., via the online survey administration tool). Based on a determination that the entity input data has not been independently verified, the HW module 412 may select a source of additional input data. The selection may be based on an ability of the source to provide input data that can be used to independently verify the entity input data (e.g., a source capable of providing EKG or a biometric input data to verify a level of fitness). The HW module 412 may associate metadata with an information element (e.g., the level of fitness of the insured entity) that indicates whether the information has been independently verified. The HW module 412 contains tools and functionality to enable an insurer to interact with a customer to help manage his/her health. The HW module 412 may share the same customer presentation layer as the CI module 408.
  • An underwriting and administration (UA) module 414 takes real-time data inputs from the other system modules to calculate risk, premium and commission amounts. The UA module 414 generates a new or amended policy, such as new premium, period cover, or commission amounts for a defined time period. The UA module 414 comprises a database and application layer.
  • A dynamic risk assessment (DRA) component 416 receives inputs (e.g., updates previously received inputs) and contains business logic for determining if a premium calculation or recalculation is necessary and possible based on changes in the customer's risk profile. Based on preset tolerances or thresholds, if a change in one or more input variables such as smoker status, health status, travel/residency, avocation/hazardous pursuits occurs and is within the binding bank, the DRA component 416 passes the appropriate value to a premium calculation (PC) component 418.
  • Based on input from the DRA component 416, the PC component 418 may perform a calculation of the premium, including a calculation of a period premium or an aggregating of the premium over a period of time. The PC component 418 may calculate one or more amounts of one or more payments of the premium based on input data, including entity input data, environmental input data, or customer preference data. For example, the PC component 418 may determine that an entity should pay the premium in a single payment or in multiple payments based on input data received from a wrap platform. Additionally, the PC component 418 may determine that entity should make payments at one or more specific dates, over a specific time period, or with a specific frequency based on customer preference data (e.g., preferences of an insured entity or an insuring entity). The PC component 418 may perform the calculation in real-time. An illustration of a calculated premium for a joint life policy is provided below.
  • Step 1 The system calculates the current age based on the coverage start
    date.
    t Age = d CoverStart - d Birthday 365.25
    Step 2 The PC component 418 identifies the rate tables based on
    Gender, Health and Smoking Status.
    TPreferred = f(gender, health, smoking)
    Step 3 The PC component 418 selects the mortality rate table for the
    person given the age at the beginning of the coverage and the
    current year.
    qMortality = f (tAge, tYear)
    Note 1: The mortality rate table may be organized such that look
    ups are based on the age at the start of coverage and the current
    year as of the calculation.
    For example, a person being born on Jul. 14, 1971, starting coverage
    on Dec. 1, 2008, being in Good health, and having given up
    smoking would have the following mortality rates:
    Year Mortality Rate
    0 0.2976660835
    1 0.3562437660
    2 0.4311634821
    3 0.5129592493
    4 0.6037844779
    Note 2: The mortality rate will be interpolated over the user
    defined Time Period to provide a Period value
    Step 4 The system calculates the life rate based on the mortality Rate
    and the Health Loading Factor.
    rLif e = qMortality * (1 + fHealthLoading)
    Step 5 If there is a joint life, the system calculates the joint life first rate
    based on the two individual rates.
    r JLF = 1000 * ( r Life 1 + r Life 2 1000 - r Life 1 * r Life 2 1000 2 )
    Step 6 The system calculates the core price as follows:
    p Core = r Life 1 * A Life 1 1000 + r Life 2 * A Life 2 1000 + r JLF * A Life Joint 1000 + c Policy + c Trust
    cPolicy = cn(1 + i)n + co
    cTrust = cn(1 + i)n + co
    Note 1: The Core Price is calculated on a yearly basis and can be
    interpolated for a user defined Time Period
    Note 2: The Core Price is based on the mortality rate for each life,
    the assured value, and the cost of the policy.
    Note 3: The cost of both policy and trust are based on the
    compound Time Period cost at Time Period X. If one was to
    compute the cost given the duration the future value of the cost is
    computed as follows:
    c Total = c * [ ( 1 + i ) n - 1 i ] + c o
    Step 7 The system calculates Travel/Residency Loading price:
    p TRL = r TRLoading 1 * A Life 1 1000 + r TRLoading 2 * A Life 2 1000
    Note 1: The loading factors are further based on the number of
    periods the loading factor is active for.
    Step 8 The System Calculates the Avocation/Hazardous Pursuits
    Loading Price:
    p AHP = r AHPLoading 1 * A Life 1 1000 + r AHPLoading 2 * A Life 2 1000
    Note 1: The loading factors are further based on the number of
    periods the loading factor is active for.
    Step 9 The System Calculates the price as the sum of the core price,
    Travel Residency Loading and Avocation/Hazardous Pursuits
    Loading.
    p = pCore + pTRL + pAHP
    Note: There maybe additional loading factors that will be used in
    the future. (This is most likely based on the product offering
    itself.)
    Step 10 The System calculates the fee and commissions for the current
    Time Period:
    c FeesCommissions = p Core ( r 1 - r ) + f
    Step
    11 The Time Period price is calculated as a summation of the fee
    and commissions and the core cost:
    pPremium = p + cFees Commissons
    Step 12 Finally, the yearly premium is divided by the invoicing interval
    (e.g. 365.25 days in a year):
    p Daily = p Premium 365.25
  • A trail commission tracker (TCT) component 420 calculates and tracks commissions paid to the partners in the distribution channel, such as agents, brokers and financial advisors. Partners can view and model commission revenue flow using this tool. Commission transparency is provided using an online tool to access data within the TCT component 420.
  • The UA module 414 may include a coverage amount component (not shown) to calculate a new coverage amount for an insurance policy based on one or more data inputs. Additionally, the UA module 414 may include a coverage time period component (not shown) to calculate a new coverage time period for an insurance policy based on one more data inputs.
  • FIG. 5 is a flowchart illustrating a method 500, according to an example embodiment, to determine variable life protection attributes, based on dynamic inputs.
  • During a given time interval, defined by customer preference in the CI module 408, customer life attributes 502 of cholesterol and weight have increased slightly and the data are manually entered into the HW module 412. The updated cholesterol and weight data are fed into the DRA component 416 to determine if a rate recalculation is necessary. The changes in cholesterol and weight are within tolerances set by the underwriters using the DRA component 416 and the rate remains the same for the next time interval period if all other variables remained constant.
  • However, during the same time period the customer got married, moved to Kazakhstan, and the regulations 504 changed an inheritance tax (IHT) rate calculation. Tax deductions and exceptions for inheritance tax are automatically fed into the CI module 408. The CI module 408 assesses the new regulations 504 against the customer profile, and the changed marital status. This information, combined with regulatory changes, determines a recalculation of inheritance tax is required. The customer new tax liability is calculated.
  • Also during the same period, the VI module 406 identifies that the customer's net worth 506 changed, triggered by a 15% decline in the customer's stock portfolio, while the customers other assets remained unchanged. The customer's trigger threshold is set at 5% within the CI module 408 and therefore the 15% decline in stock portfolio is sufficient to trigger a request to the CI module 408 to recalculate IHT. The CI module 408 iteratively calculates the impact of the new coverage amount on IHT combined with changes in regulatory environment and marital status. A new coverage amount is either required or recommended.
  • The premium calculation (PC) module 418 receives a request from the CI module 408 to calculate a new period premium based on a net increase in coverage required or recommended primarily due to the customer relocating to Kazakhstan and having an increased tax liability. The PC module 418 checks with the DRA module 416 to determine if the customer's risk profile changed. In this example, the change in cholesterol and weight does not trigger a risk revaluation. The PC module 418 also checks with the UIC module 410 to determine if the increase in coverage is within the medical underwriting band. The increase in coverage is within the medical underwriting binding band and the increase in the premium does not exceed a threshold specified in the CI module 408 that would trigger the need for the customer to accept or reject the premium increase; therefore, coverage was automatically provided.
  • The new premium amount is calculated and the premium amount sent to the TCT module 420 to calculate and disburse trail commission payment to the customer's broker.
  • Modules, Components and Logic
  • Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules may constitute either software modules (e.g., code embodied on a machine-readable storage medium or in a transmission signal) or hardware modules or devices. A device is tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client or server computer system) or one or more components of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a device that operates to perform certain operations as described herein.
  • In various embodiments, a device may be implemented mechanically or electronically. For example, a device may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A device may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a device mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.
  • Accordingly, the term “device” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired) or temporarily configured (e.g., programmed) to operate in a certain manner and/or to perform certain operations described herein. Considering embodiments in which devices are temporarily configured (e.g., programmed), each of the devices need not be configured or instantiated at any one instance in time. For example, where the devices comprise a general-purpose processor configured using software, the general-purpose processor may be configured as respective different devices at different times. Software may accordingly configure a processor, for example, to constitute a particular device at one instance of time and to constitute a different device at a different instance of time.
  • Devices can provide information to, and receive information from, other devices. Accordingly, the described devices may be regarded as being communicatively coupled. Where multiple of such devices exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses) that connect the devices. In embodiments in which multiple devices are configured or instantiated at different times, communications between such devices may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple devices have access. For example, one device may perform an operation, and store the output of that operation in a memory device to which it is communicatively coupled. A further device may then, at a later time, access the memory device to retrieve and process the stored output. Devices may also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information).
  • The various operations of example methods described herein may be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules or devices that operate to perform one or more operations or functions. The modules referred to herein may, in some example embodiments, comprise processor-implemented modules or devices.
  • Similarly, the methods described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or processors or processor-implemented modules or devices. The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the processor or processors may be located in a single location (e.g., within a home environment, an office environment or as a server farm), while in other embodiments the processors may be distributed across a number of locations.
  • The one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., Application Program Interfaces (APIs).)
  • Electronic Apparatus and System
  • Example embodiments may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Example embodiments may be implemented using a computer program product, e.g., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage medium for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers.
  • A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
  • In example embodiments, operations may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Method operations can also be performed by, and apparatus of example embodiments may be implemented as, special purpose logic circuitry, e.g., a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC).
  • The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In embodiments deploying a programmable computing system, it will be appreciated that that both hardware and software architectures require consideration. Specifically, it will be appreciated that the choice of whether to implement certain functionality in permanently configured hardware (e.g., an ASIC), in temporarily configured hardware (e.g., a combination of software and a programmable processor), or a combination of permanently and temporarily configured hardware may be a design choice. Below are set out hardware (e.g., machine) and software architectures that may be deployed, in various example embodiments.
  • Example Machine Architecture and Machine-Readable Storage Medium
  • FIG. 6 is a block diagram of machine in the example form of a computer system 600 within which instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
  • The example computer system 600 includes a processor 602 (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory 604 and a static memory 606, which communicate with each other via a bus 608. The computer system 600 may further include a video display unit 610 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 600 also includes an alphanumeric input device 612 (e.g., a keyboard), a user interface (UI) navigation device 614 (e.g., a mouse), a disk drive unit 616, a signal generation device 618 (e.g., a speaker) and a network interface device 620.
  • Machine-Readable Storage Medium
  • The disk drive unit 616 includes a machine-readable storage medium 622 on which is stored one or more sets of instructions and data structures (e.g., software) 624 embodying or utilized by any one or more of the methodologies or functions described herein. The instructions 624 may also reside, completely or at least partially, within the main memory 604 and/or within the processor 602 during execution thereof by the computer system 600, the main memory 604 and the processor 602 also constituting machine-readable media.
  • While the machine-readable storage medium 622 is shown in an example embodiment to be a single medium, the term “machine-readable storage medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions or data structures. The term “machine-readable storage medium” shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention, or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions. The term “machine-readable storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable storage media include non-volatile memory, including by way of example semiconductor memory devices, e.g., Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.
  • Transmission Medium
  • The instructions 624 may further be transmitted or received over a communications network 626 using a transmission medium. The instructions 624 may be transmitted using the network interface device 620 and any one of a number of well-known transfer protocols (e.g., HTTP). Examples of communication networks include a local area network (“LAN”), a wide area network (“WAN”), the Internet, mobile telephone networks, Plain Old Telephone (POTS) networks, and wireless data networks (e.g., WiFi and WiMax networks). The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible media to facilitate communication of such software.
  • Although an embodiment has been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof, show by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

Claims (20)

1. A method comprising:
updating at least one of an entity input data and an environmental input data, the entity input data being an input data that is specific to an entity that is insured by an insurance policy and the environmental input data being additional input data that is not specific to the entity;
determining, using a processor, whether a risk associated with providing the insurance policy has changed based on the updating of the at least one of the entity input data and the environmental input data; and
responsive to the determining, recalculating a premium of the insurance policy.
2. The method of claim 1, wherein:
the entity input data is biometric input data; and
the environmental input data is a mortality table.
3. The method of claim 1, wherein:
the entity input data is a net worth data of the entity; and
the environmental input data is regulatory input data.
4. The method of claim 1, further comprising:
identifying a first source of the entity input data;
selecting a second source of the entity input data to verify the entity input data independently of the first source;
using the second source, verifying the entity input data independently of the first source; and
associating metadata with the entity input data to indicate the verifying of the entity input data.
5. The method of claim 1, further comprising:
receiving a frequency at which the premium is to be updated,
wherein the updating of the at least one of the entity input data and the environmental input data is based on the frequency.
6. The method of claim 1, further comprising:
receiving a change threshold corresponding to the at least one of the entity input data and the environmental input data; and
wherein the recalculating is based on a value of the at least one of the entity input data and the environmental data transgressing the change threshold.
7. The method of claim 1, wherein the updating of the at least one of the entity input data and the environmental input data includes interacting with a wrap platform.
8. A system comprising:
an underwriting information coordination module to update at least one of an entity input data and an environmental input data, the entity input data being an input data that is specific to an entity that is insured by an insurance policy and the environmental input data being additional input data that is not specific to the entity; and
an underwriting and administration module to:
calculate a risk associated with providing the insurance policy based on the updating of the at least one of the entity input data and the environmental input data;
determine, using a processor, whether the risk associated with providing the insurance policy has changed; and
recalculate a premium of the insurance policy based on a change in the risk.
9. The system of claim 8, wherein:
the entity input data is biometric input data; and
the environmental input data is a mortality table.
10. The system of claim 8, wherein:
the entity input data is a net worth data of the entity; and
the environmental input data is regulatory input data.
11. The system of claim 8, further comprising:
a health and wellness module to:
identify a first source of the entity input data;
select a second source of the entity input data to verify the entity input data independently of the first source;
use the second source to verify the entity input data independently of the first source; and
associate metadata with the entity input data to indicate the verifying of the entity input data.
12. The system of claim 8, further comprising:
a customer information module to receive a frequency at which the premium is to be updated, wherein the underwriting and administration module is to update the at least one of the entity input data and the environmental input data is based on the frequency.
13. The system of claim 8, further comprising:
a customer information module to receive a change threshold corresponding to the at least one of the entity input data and the environmental input data, wherein the underwriting and administration module is to recalculate the premium of the insurance policy based on a value of the at least one of the entity input data and the environmental data transgressing the change threshold.
14. The system of claim 8, wherein the underwriting and administration module is to update the at least one of the entity input data and the environmental input data based on an interaction with a wrap platform.
15. A machine-readable storage medium embodying a set of instructions that, when executed by a processor, causes the processor to perform a method, the method comprising:
updating at least one of an entity input data and an environmental input data, the entity input data being an input data that is specific to an entity that is insured by an insurance policy and the environmental input data being additional input data that is not specific to the entity;
determining, using a processor, whether a risk associated with providing the insurance policy has changed based on the updating of the at least one of the entity input data and the environmental input data; and
responsive to the determining, recalculating a premium of the insurance policy.
16. The machine-readable storage medium of claim 15, wherein:
the entity input data is biometric input data; and
the environmental input data is a mortality table.
17. The machine-readable storage medium of claim 15, wherein:
the entity input data is a net worth data of the entity; and
the environmental input data is regulatory input data.
18. The machine-readable storage medium of claim 15, the method further comprising:
identifying a first source of the entity input data;
selecting a second source of the entity input data to verify the entity input data independently of the first source;
using the second source, verifying the entity input data independently of the first source; and
associating metadata with the entity input data to indicate the verifying of the entity input data.
19. The machine-readable storage medium of claim 15, the method further comprising:
receiving a frequency at which the premium is to be updated, wherein the updating of the at least one of the entity input data and the environmental input data is based on the frequency.
20. The machine-readable storage medium of claim 15, the method further comprising:
receiving a change threshold corresponding to the at least one of the entity input data and the environmental input data, wherein the recalculating is based on an amount of the at least one of the entity input data and the environmental data transgressing the change threshold.
US12/790,750 2009-05-29 2010-05-28 Dynamic adjustment of insurance premiums Abandoned US20110004492A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US12/790,750 US20110004492A1 (en) 2009-05-29 2010-05-28 Dynamic adjustment of insurance premiums

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US18258909P 2009-05-29 2009-05-29
US12/790,750 US20110004492A1 (en) 2009-05-29 2010-05-28 Dynamic adjustment of insurance premiums

Publications (1)

Publication Number Publication Date
US20110004492A1 true US20110004492A1 (en) 2011-01-06

Family

ID=43223128

Family Applications (3)

Application Number Title Priority Date Filing Date
US12/790,753 Abandoned US20100312584A1 (en) 2009-05-29 2010-05-28 Dynamic adjustment of insurance coverage
US12/790,758 Expired - Fee Related US10049407B2 (en) 2009-05-29 2010-05-28 Dynamic aggregation of insurance premiums
US12/790,750 Abandoned US20110004492A1 (en) 2009-05-29 2010-05-28 Dynamic adjustment of insurance premiums

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US12/790,753 Abandoned US20100312584A1 (en) 2009-05-29 2010-05-28 Dynamic adjustment of insurance coverage
US12/790,758 Expired - Fee Related US10049407B2 (en) 2009-05-29 2010-05-28 Dynamic aggregation of insurance premiums

Country Status (4)

Country Link
US (3) US20100312584A1 (en)
EP (1) EP2435972A4 (en)
AU (3) AU2010253917A1 (en)
WO (1) WO2010138932A1 (en)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100312584A1 (en) * 2009-05-29 2010-12-09 Quanis, Inc. Dynamic adjustment of insurance coverage
US20120197669A1 (en) * 2011-01-27 2012-08-02 Kote Thejovardhana S Determining Cost of Auto Insurance
US20120290331A1 (en) * 2011-05-12 2012-11-15 New York Life Insurance Company Methods and systems for providing deferred annuities with an income reset feature
US20130060582A1 (en) * 2011-09-01 2013-03-07 Brian M. Cutino Underwriting system and method associated with a civic improvement platform
US8630877B1 (en) * 2009-07-17 2014-01-14 United Services Automobile Association (Usaa) Systems and methods for retirement gap insurance
US20160140522A1 (en) * 2014-11-17 2016-05-19 John Hancock Life Insurance Company (U.S.A.) Methods and systems for implementing dynamic billing
US9839376B1 (en) * 2015-04-20 2017-12-12 Massachusetts Mutual Life Insurance Systems and methods for automated body mass index calculation to determine value
US10438292B1 (en) * 2015-09-17 2019-10-08 Allstate Insurance Company Determining body characteristics based on images
US20190370364A1 (en) * 2018-06-05 2019-12-05 Peter J. Casatelli Processing system to facilitate update of existing electronic record information
US20200334598A1 (en) * 2019-04-17 2020-10-22 Danah L. Prignano Automated summary system computer server associated with a risk relationship attribute value review
US10878062B1 (en) * 2017-09-06 2020-12-29 State Farm Mutual Automobile Insurance Company Systems and methods for analyzing captured biometric data

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110145023A1 (en) * 2009-12-14 2011-06-16 Unitrin Direct Insurance Company System and Method for Incentivizing Insurance Participation Utilizing Social Networking Systems
US8626538B1 (en) * 2011-05-12 2014-01-07 Risk Management Technologies, LLC Insurance coverage management system
US20130090953A1 (en) * 2011-10-07 2013-04-11 Erlan Feria Method for determining life expectancy
US9081466B2 (en) 2012-09-10 2015-07-14 Sap Se Dynamic chart control that triggers dynamic contextual actions
US10223750B1 (en) 2012-09-10 2019-03-05 Allstate Insurance Company Optimized inventory analysis for insurance purposes
US10783584B1 (en) * 2012-09-10 2020-09-22 Allstate Insurance Company Recommendation of insurance products based on an inventory analysis
US10489859B1 (en) 2013-08-29 2019-11-26 Allstate Insurance Company Life insurance clearinghouse
US10949923B1 (en) 2013-09-16 2021-03-16 Allstate Insurance Company Home device sensing
US10430887B1 (en) 2014-02-21 2019-10-01 Allstate Insurance Company Device sensing
US10380692B1 (en) 2014-02-21 2019-08-13 Allstate Insurance Company Home device sensing
US10467701B1 (en) 2014-03-10 2019-11-05 Allstate Insurance Company Home event detection and processing
US10366456B2 (en) 2014-08-29 2019-07-30 Guidewire Software, Inc. Operational data corresponding to a product model
US20180144345A1 (en) * 2016-11-23 2018-05-24 Kim Wagner Assurance exchange
US20180253670A1 (en) * 2017-03-06 2018-09-06 Catherine M. Sommer System to process data allocating resource availability risk
US11257132B1 (en) 2018-05-04 2022-02-22 Allstate Insurance Company Processing systems and methods having a machine learning engine for providing a surface dimension output
US11436648B1 (en) 2018-05-04 2022-09-06 Allstate Insurance Company Processing system having a machine learning engine for providing a surface dimension output
US11520803B1 (en) 2018-09-14 2022-12-06 State Farm Mutual Automobile Insurance Company Big-data view integration platform
US20200111168A1 (en) * 2018-10-09 2020-04-09 Michael M. Carter Engine, system and method of providing real-time insurance coverage and pricing modifications based on cloud-based business valuation
US10748219B2 (en) 2019-01-08 2020-08-18 Onoff, Inc. Method and system for dynamically changing automobile insurance
US11790300B2 (en) * 2021-08-03 2023-10-17 State Farm Mutual Automobile Insurance Company Systems and methods for generating insurance business plans
CN115511644A (en) * 2022-08-29 2022-12-23 易保网络技术(上海)有限公司 Processing method for target policy, electronic device and readable storage medium
US11928743B1 (en) * 2023-05-18 2024-03-12 AmerUs Group Inc. Gesture-enabled interfaces, systems, methods, and applications for custom designing non-level life insurance benefits policies and supporting customized pricing

Citations (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4831693A (en) * 1987-02-10 1989-05-23 Veit Transpo Gmbh Clamp for sheet material articles
US5752236A (en) * 1994-09-02 1998-05-12 Sexton; Frank M. Life insurance method, and system
US5839118A (en) * 1996-01-16 1998-11-17 The Evergreen Group, Incorporated System and method for premium optimization and loan monitoring
US5956691A (en) * 1997-01-07 1999-09-21 Second Opinion Financial Systems, Inc. Dynamic policy illustration system
US20010040591A1 (en) * 1998-12-18 2001-11-15 Abbott Kenneth H. Thematic response to a computer user's context, such as by a wearable personal computer
US20020002475A1 (en) * 2000-04-13 2002-01-03 Joel Freedman Automated insurance system and method
US20020095317A1 (en) * 2000-08-10 2002-07-18 Miralink Corporation Data/presence insurance tools and techniques
US20020188480A1 (en) * 2001-04-30 2002-12-12 Liebeskind Michael B. Insurance risk, price, and enrollment optimizer system and method
US20030018576A1 (en) * 2001-06-25 2003-01-23 Bomazu, Llc Risk evaluation system and method
US20030078817A1 (en) * 2001-10-16 2003-04-24 Lance Harrison Method and apparatus for insurance risk management
US20030120520A1 (en) * 2000-04-17 2003-06-26 Cumming David T. System, method, and computer program product for providing financial protection of equity investments
US20030158758A1 (en) * 2000-06-15 2003-08-21 Kiyoshi Kanazawa Insurance descriptions adjusting system
US20030187693A1 (en) * 2002-04-02 2003-10-02 Colin Corporation Premium updating method and apparatus
US20040030587A1 (en) * 2002-08-07 2004-02-12 Danico Angela G. System and method for identifying and assessing comparative negligence in insurance claims
US20040059608A1 (en) * 2002-09-20 2004-03-25 Adrian Gore Method of calculating a premium payable by an insured person on a life insurance policy
US20040103012A1 (en) * 2002-11-22 2004-05-27 Swiss Reinsurance Company Method for automated insurance pricing and renewal notification
US20040122770A1 (en) * 2002-12-23 2004-06-24 United Services Automobile Association (Usaa) System and method of processing account information over a computer network
US20040148201A1 (en) * 2003-01-27 2004-07-29 Smith Tracy Lee Insurance management system
US20040153362A1 (en) * 1996-01-29 2004-08-05 Progressive Casualty Insurance Company Monitoring system for determining and communicating a cost of insurance
US20040267651A1 (en) * 2001-07-31 2004-12-30 American Express Travel Related Services Company, Inc. Portfolio integration module for providing financial planning and advice
US20050071204A1 (en) * 2003-09-30 2005-03-31 Kiritharan Parankirinathan Method of calculating premium payment to cover the risk attributable to insureds surviving a specified period
US20060100912A1 (en) * 2002-12-16 2006-05-11 Questerra Llc. Real-time insurance policy underwriting and risk management
US20060136273A1 (en) * 2004-09-10 2006-06-22 Frank Zizzamia Method and system for estimating insurance loss reserves and confidence intervals using insurance policy and claim level detail predictive modeling
US7124088B2 (en) * 1999-07-30 2006-10-17 Progressive Casualty Insurance Company Apparatus for internet on-line insurance policy service
US20070255601A1 (en) * 2006-04-27 2007-11-01 Guidewire Software, Inc. Insurance policy revisioning method and apparatus
US20080033767A1 (en) * 1998-09-25 2008-02-07 Brown Stephen J Dynamic modeling and scoring risk assessment
US20080109333A1 (en) * 2006-10-05 2008-05-08 Frazer Lanier Company System and method for premium finance management
US20080126139A1 (en) * 2006-11-21 2008-05-29 American International Group, Inc. Method and System for Determining Rate of Insurance
US20080154651A1 (en) * 2006-12-22 2008-06-26 Hartford Fire Insurance Company System and method for utilizing interrelated computerized predictive models
US7395219B2 (en) * 2001-12-08 2008-07-01 Kenneth Ray Strech Insurance on demand transaction management system
US20080183636A1 (en) * 2007-01-29 2008-07-31 Walsh John T Methods and systems for customizing amounts and duration of payments of life insurance product
US20090024420A1 (en) * 2007-07-17 2009-01-22 Steve Winkler Automatic insurance adjustments using real world awareness
US20090037229A1 (en) * 2005-09-27 2009-02-05 Jairo Alberto Perez Munoz System for measuring the exposure time of the coverage offered by an insurance policy
US7657447B2 (en) * 2007-11-20 2010-02-02 Hartford Fire Insurance Company System and method for identifying and evaluating nanomaterial-related risk
US20100131305A1 (en) * 2008-11-26 2010-05-27 Fred Collopy Insurance visibility
US7742937B2 (en) * 2002-03-06 2010-06-22 Steven R. Cox System for improving logistics, tracking and billing for worker's compensation insurance
US20100312584A1 (en) * 2009-05-29 2010-12-09 Quanis, Inc. Dynamic adjustment of insurance coverage
US8027822B2 (en) * 2005-06-20 2011-09-27 Virgin Healthmiles, Inc. Interactive, internet supported health and fitness management system
US8041636B1 (en) * 2006-04-14 2011-10-18 Intuit Inc. Method and apparatus for dynamically determining insurance coverage
US8090592B1 (en) * 2007-10-31 2012-01-03 At&T Intellectual Property I, L.P. Method and apparatus for multi-domain anomaly pattern definition and detection
US8180655B1 (en) * 2007-09-24 2012-05-15 United Services Automobile Association (Usaa) Systems and methods for processing vehicle or driver performance data

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4837693A (en) 1987-02-27 1989-06-06 Schotz Barry R Method and apparatus for facilitating operation of an insurance plan
US4831696A (en) * 1988-05-06 1989-05-23 American Telephone And Telegraph Company Component insertion machine apparatus
WO2001039090A1 (en) 1999-11-26 2001-05-31 Esurance, Inc. Insurance marketing methods
CN101027689A (en) 2004-07-26 2007-08-29 发现控股有限公司 A data processing system for accurately calculating a policyholder's discount in a medical insurance plan and a method therefor
US20060184387A1 (en) * 2005-02-11 2006-08-17 Guard Insurance Group Insurance policy renewal chain
WO2008016931A2 (en) 2006-07-31 2008-02-07 Insight Catastrophe Solutions Apparatuses, methods, and systems for dynamic configuration and generation of insurance
US8073715B1 (en) * 2007-04-26 2011-12-06 United Services Automobile Association (Usaa) Systems and methods for providing enhanced service using public records
US20090112634A1 (en) * 2007-10-24 2009-04-30 Koziol Joseph D Insurance Transaction System and Method
US8478613B2 (en) 2008-10-02 2013-07-02 Hartford Fire Insurance Company System and method for providing and displaying dynamic coverage recommendations

Patent Citations (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4831693A (en) * 1987-02-10 1989-05-23 Veit Transpo Gmbh Clamp for sheet material articles
US5752236A (en) * 1994-09-02 1998-05-12 Sexton; Frank M. Life insurance method, and system
US5839118A (en) * 1996-01-16 1998-11-17 The Evergreen Group, Incorporated System and method for premium optimization and loan monitoring
US20040153362A1 (en) * 1996-01-29 2004-08-05 Progressive Casualty Insurance Company Monitoring system for determining and communicating a cost of insurance
US5956691A (en) * 1997-01-07 1999-09-21 Second Opinion Financial Systems, Inc. Dynamic policy illustration system
US20080033767A1 (en) * 1998-09-25 2008-02-07 Brown Stephen J Dynamic modeling and scoring risk assessment
US20010040591A1 (en) * 1998-12-18 2001-11-15 Abbott Kenneth H. Thematic response to a computer user's context, such as by a wearable personal computer
US7124088B2 (en) * 1999-07-30 2006-10-17 Progressive Casualty Insurance Company Apparatus for internet on-line insurance policy service
US20020002475A1 (en) * 2000-04-13 2002-01-03 Joel Freedman Automated insurance system and method
US20030120520A1 (en) * 2000-04-17 2003-06-26 Cumming David T. System, method, and computer program product for providing financial protection of equity investments
US20030158758A1 (en) * 2000-06-15 2003-08-21 Kiyoshi Kanazawa Insurance descriptions adjusting system
US20020095317A1 (en) * 2000-08-10 2002-07-18 Miralink Corporation Data/presence insurance tools and techniques
US20020188480A1 (en) * 2001-04-30 2002-12-12 Liebeskind Michael B. Insurance risk, price, and enrollment optimizer system and method
US20030018576A1 (en) * 2001-06-25 2003-01-23 Bomazu, Llc Risk evaluation system and method
US20040267651A1 (en) * 2001-07-31 2004-12-30 American Express Travel Related Services Company, Inc. Portfolio integration module for providing financial planning and advice
US20030078817A1 (en) * 2001-10-16 2003-04-24 Lance Harrison Method and apparatus for insurance risk management
US7395219B2 (en) * 2001-12-08 2008-07-01 Kenneth Ray Strech Insurance on demand transaction management system
US7742937B2 (en) * 2002-03-06 2010-06-22 Steven R. Cox System for improving logistics, tracking and billing for worker's compensation insurance
US20030187693A1 (en) * 2002-04-02 2003-10-02 Colin Corporation Premium updating method and apparatus
US20040030587A1 (en) * 2002-08-07 2004-02-12 Danico Angela G. System and method for identifying and assessing comparative negligence in insurance claims
US20040059608A1 (en) * 2002-09-20 2004-03-25 Adrian Gore Method of calculating a premium payable by an insured person on a life insurance policy
US20040103012A1 (en) * 2002-11-22 2004-05-27 Swiss Reinsurance Company Method for automated insurance pricing and renewal notification
US20060100912A1 (en) * 2002-12-16 2006-05-11 Questerra Llc. Real-time insurance policy underwriting and risk management
US20040122770A1 (en) * 2002-12-23 2004-06-24 United Services Automobile Association (Usaa) System and method of processing account information over a computer network
US20040148201A1 (en) * 2003-01-27 2004-07-29 Smith Tracy Lee Insurance management system
US6999935B2 (en) * 2003-09-30 2006-02-14 Kiritharan Parankirinathan Method of calculating premium payment to cover the risk attributable to insureds surviving a specified period
US20050267785A1 (en) * 2003-09-30 2005-12-01 Kiritharan Parankirinathan Survival risk insurance
US20050071204A1 (en) * 2003-09-30 2005-03-31 Kiritharan Parankirinathan Method of calculating premium payment to cover the risk attributable to insureds surviving a specified period
US20060136273A1 (en) * 2004-09-10 2006-06-22 Frank Zizzamia Method and system for estimating insurance loss reserves and confidence intervals using insurance policy and claim level detail predictive modeling
US8027822B2 (en) * 2005-06-20 2011-09-27 Virgin Healthmiles, Inc. Interactive, internet supported health and fitness management system
US20090037229A1 (en) * 2005-09-27 2009-02-05 Jairo Alberto Perez Munoz System for measuring the exposure time of the coverage offered by an insurance policy
US8041636B1 (en) * 2006-04-14 2011-10-18 Intuit Inc. Method and apparatus for dynamically determining insurance coverage
US20070255601A1 (en) * 2006-04-27 2007-11-01 Guidewire Software, Inc. Insurance policy revisioning method and apparatus
US20080109333A1 (en) * 2006-10-05 2008-05-08 Frazer Lanier Company System and method for premium finance management
US20080126139A1 (en) * 2006-11-21 2008-05-29 American International Group, Inc. Method and System for Determining Rate of Insurance
US20080154651A1 (en) * 2006-12-22 2008-06-26 Hartford Fire Insurance Company System and method for utilizing interrelated computerized predictive models
US20080183636A1 (en) * 2007-01-29 2008-07-31 Walsh John T Methods and systems for customizing amounts and duration of payments of life insurance product
US20090024420A1 (en) * 2007-07-17 2009-01-22 Steve Winkler Automatic insurance adjustments using real world awareness
US8180655B1 (en) * 2007-09-24 2012-05-15 United Services Automobile Association (Usaa) Systems and methods for processing vehicle or driver performance data
US8090592B1 (en) * 2007-10-31 2012-01-03 At&T Intellectual Property I, L.P. Method and apparatus for multi-domain anomaly pattern definition and detection
US7657447B2 (en) * 2007-11-20 2010-02-02 Hartford Fire Insurance Company System and method for identifying and evaluating nanomaterial-related risk
US20100131303A1 (en) * 2008-11-26 2010-05-27 Fred Collopy Dynamic insurance rates
US20100131305A1 (en) * 2008-11-26 2010-05-27 Fred Collopy Insurance visibility
US20110004493A1 (en) * 2009-05-29 2011-01-06 Quanis, Inc. Dynamic aggregation of insurance premiums
US20100312584A1 (en) * 2009-05-29 2010-12-09 Quanis, Inc. Dynamic adjustment of insurance coverage

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Furhaupter, Rainer. Adjustment in a fully-funded system. 19 March 2002. http://www.actuaries.org/EVENTS/Congresses/Cancun/health_subject/health_28_40_49_furhaupter.pdf *
Kominski, Gerald. Medicare's Use of Risk Adjustment. Nathional Health Policy Forum. 21 August 2007. http://www.nhpf.org/library/background-papers/BP_RiskAdjustMedicare_08-21-07.pdf *

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10049407B2 (en) 2009-05-29 2018-08-14 Quanis Licensing Ltd. Dynamic aggregation of insurance premiums
US20110004493A1 (en) * 2009-05-29 2011-01-06 Quanis, Inc. Dynamic aggregation of insurance premiums
US20100312584A1 (en) * 2009-05-29 2010-12-09 Quanis, Inc. Dynamic adjustment of insurance coverage
US8630877B1 (en) * 2009-07-17 2014-01-14 United Services Automobile Association (Usaa) Systems and methods for retirement gap insurance
US20120197669A1 (en) * 2011-01-27 2012-08-02 Kote Thejovardhana S Determining Cost of Auto Insurance
US20120290331A1 (en) * 2011-05-12 2012-11-15 New York Life Insurance Company Methods and systems for providing deferred annuities with an income reset feature
US8340986B2 (en) * 2011-05-12 2012-12-25 New York Life Insurance Company Methods and systems for providing deferred annuities with an income reset feature
US20130097098A1 (en) * 2011-05-12 2013-04-18 New York Life Insurance Company Methods and systems for providing deferred annuities with an income reset feature
US20130060582A1 (en) * 2011-09-01 2013-03-07 Brian M. Cutino Underwriting system and method associated with a civic improvement platform
US10990938B2 (en) * 2014-11-17 2021-04-27 John Hancock Life Insurance Company (U.S.A.) Methods and systems for implementing dynamic billing
US20160140522A1 (en) * 2014-11-17 2016-05-19 John Hancock Life Insurance Company (U.S.A.) Methods and systems for implementing dynamic billing
US10426378B1 (en) 2015-04-20 2019-10-01 Massachusetts Mutual Life Insurance Company Systems and methods for automated body mass index calculation to determine value
US9839376B1 (en) * 2015-04-20 2017-12-12 Massachusetts Mutual Life Insurance Systems and methods for automated body mass index calculation to determine value
US11259718B1 (en) 2015-04-20 2022-03-01 Massachusetts Mutual Life Insurance Company Systems and methods for automated body mass index calculation to determine value
US11263698B1 (en) 2015-09-17 2022-03-01 Allstate Insurance Company Determining body characteristics based on images
US10438292B1 (en) * 2015-09-17 2019-10-08 Allstate Insurance Company Determining body characteristics based on images
US11710189B2 (en) 2015-09-17 2023-07-25 Allstate Insurance Company Determining body characteristics based on images
US10878062B1 (en) * 2017-09-06 2020-12-29 State Farm Mutual Automobile Insurance Company Systems and methods for analyzing captured biometric data
US11587648B1 (en) 2017-09-06 2023-02-21 State Farm Mutual Automobile Insurance Company Systems and methods for analyzing captured biometric data
US11869637B2 (en) 2017-09-06 2024-01-09 State Farm Mutual Automobile Insurance Company Systems and methods for analyzing captured biometric data
US20190370364A1 (en) * 2018-06-05 2019-12-05 Peter J. Casatelli Processing system to facilitate update of existing electronic record information
US20200334598A1 (en) * 2019-04-17 2020-10-22 Danah L. Prignano Automated summary system computer server associated with a risk relationship attribute value review

Also Published As

Publication number Publication date
EP2435972A1 (en) 2012-04-04
US20100312584A1 (en) 2010-12-09
EP2435972A4 (en) 2014-08-27
AU2010253917A2 (en) 2012-01-19
AU2010253917A1 (en) 2012-01-12
AU2017201738A1 (en) 2017-03-30
WO2010138932A1 (en) 2010-12-02
US10049407B2 (en) 2018-08-14
US20110004493A1 (en) 2011-01-06
AU2010101547A4 (en) 2016-12-22

Similar Documents

Publication Publication Date Title
US10049407B2 (en) Dynamic aggregation of insurance premiums
Garrison Jr et al. An overview of value, perspective, and decision context—a health economics approach: an ISPOR Special Task Force report [2]
US8145500B2 (en) Data processing system for accurately calculating a policyholder's discount in a medical insurance plan and a method therefor
Medicare Payment Advisory Commission (US) Report to the congress, Medicare payment policy
US8359212B2 (en) System and method for processing data related to longevity insurance
US8612266B1 (en) Distributing financial risk for insurance coverage
Carroll et al. The growing importance of cost accounting for hospitals
US20020169702A1 (en) Methods and systems for financial planning
US20150363885A1 (en) Techniques and systems for managing investment and insurance policies
US20090187434A1 (en) System and method for a health insurance risk evaluator
US8725615B2 (en) System and method for monitoring accounts with insurance benefits
US20080300923A1 (en) Method, system, and interface for setting health insurance premiums
US20150154710A1 (en) System and method for calculating a premium for a life insurance option
US20140039918A1 (en) System and Method For Implementing Program Compliance For Health-Based Rewards
US20150088532A1 (en) Methods, Systems, and Servers for Processing Health Insurance Claims
AU2020285364A1 (en) System and method for monitoring wellbeing
McGuire et al. Medicare advantage: regulated competition in the shadow of a public option
Selden The Within‐Year Concentration of Medical Care: Implications for Family Out‐of‐Pocket Expenditure Burdens
US20150088552A1 (en) Methods, Systems, and Servers for Processing Health Insurance Claims
US20190096521A1 (en) Value-based scheduling system
US20150088553A1 (en) Methods, Systems, and Servers for Processing Health Insurance Claims
US9846914B1 (en) Systems, methods, and program products for calculating shared savings for a self-insured health care plan
US20230005069A1 (en) Methods and systems for administering life insurance products with death benefits automatically adjusted without underwriting based on independent data correlated with an insured individuals need for life insurance benefits
Park Ensuring Effective Risk Adjustment
Warshawsky Retirement income strategies designed in an expected utility framework

Legal Events

Date Code Title Description
AS Assignment

Owner name: QUANIS LICENSING LIMITED, MAURITIUS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BRADSHAW, PAUL;LEVIN, JOHN ANTHONY;CONCANNON, MICHAEL;SIGNING DATES FROM 20120524 TO 20120525;REEL/FRAME:028314/0727

AS Assignment

Owner name: QUANIS LICENSING LIMITED, MAURITIUS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BRADSHAW, PAUL;LEVIN, JOHN ANTHONY;CONCANNON, MICHAEL;SIGNING DATES FROM 20120524 TO 20120525;REEL/FRAME:028325/0118

STPP Information on status: patent application and granting procedure in general

Free format text: FINAL REJECTION MAILED

AS Assignment

Owner name: CERTUA LICENSING LIMITED, GREAT BRITAIN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:QUANIS LICENSING LIMITED;REEL/FRAME:047216/0338

Effective date: 20180704

STCB Information on status: application discontinuation

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