US20100131303A1

US20100131303A1 - Dynamic insurance rates

Info

Publication number: US20100131303A1
Application number: US12/536,999
Authority: US
Inventors: Fred Collopy; Craig Allen Nard; Himanshu S. Amin; Gregory Turocy; Seyed Vahid Sharifi Takieh; Ronald Charles Krosky; David Noonan; Gustavo Arnaldo Narvaez; Brian Asquith
Original assignee: Individual
Current assignee: RCK-IP LLC; Great Lakes Incubator LLC
Priority date: 2008-11-26
Filing date: 2009-08-06
Publication date: 2010-05-27
Also published as: US20180260908A1; US20100131300A1; US20150324928A1; WO2010062899A1; US9996884B2; US20130297418A1; US20100131307A1; US20100131308A1; US20100131301A1; US20150339780A1; US20150324927A1; US8255275B2; US20100131302A1; US20100131304A1; US8620692B2; US20120259666A1; US8484113B2; US20140100892A1; US20100131305A1

Abstract

Systems and methods that customize insurance rates in real time to correspond to unique behavior/character traits of a user/driver. A rate adjustment component can interact with insurance companies that provide bids based on the contextual data—wherein, insurance costs can be dynamically adjusted, and the user/driver switched in real-time between such insurance companies (e.g., based on bids), to ensure obtaining optimum rates. A switching component can switch user/driver) to an insurance company that bids the best rate. Hence, during a trip the user/driver can actually be insured by various suppliers during different segments of such trip.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No. 61/118,400 filed on 26 Nov. 2008 entitled “INSURANCE OPTIMIZER AND REAL TIME ANALYTICS”, and the entirety of this application is hereby incorporated by reference.

BACKGROUND

Insurance policies typically include legal agreements that specify items to be afforded coverage with respect to particular perils. For such agreements, numerous conditions apply, such as applicable deductibles, coverage limits, and the like, wherein related expense/billing can further be broken down into elements by covered item and peril.
Moreover, insurance carriers often view such policies as being derived from and related to a “policy product”. Typically, a policy product defines the attributes and shared data for its derived policies, wherein a process of writing a specific policy involves referring to the available attributes of the policy as defined by the policy product and the corresponding selection of appropriate values for a given customer. As such, a coverage typically comprises an obligation to pay for damages that are caused by a particular peril (or collection of perils). Such obligation typically has corresponding financial limits and deductibles that circumscribe the insurer's responsibility for losses against that coverage. For example, a policy's total cost is usually determined as a function of the aggregate cost of the policy's constituent coverage sections.
Moreover, insurance coverage typically applies to risk units (e.g., a scenario or circumstance that may be exposed to loss). For example, risk units can comprise buildings, vehicles, personal property, on-going business, or the like. In such cases, insurance is obtained by receiving quotes from various companies and selecting the most desirable policy considering coverage, price, and other factors. In particular, insurance companies generate coverage premiums based on a number of factors that represent averaged scenarios regarding the item to be covered. Insurance companies typically have highly proprietary systems that automatically generate premiums using the factors, and each insurance company typically has its own system resulting in varying premiums for different items with respect to different policy holders and desired coverage levels.
Moreover, insurance premiums are typically fixed in price and billed in monthly, semi-annual, or annual time periods. Premiums can be affected by many policy parameters for which cost is averaged and can be adjusted for a given billing period. For example, with respect to automobile insurance, rates can be determined based on desired coverage level, automobile make, model, and color, automobile features, estimated miles driven each year, zip code, and the like In addition, rates can be evaluated at the end of a premium period based on number of claims filed in the primary zip code. With such speculative and broad premium computation, it can become difficult to offer precise and competitive rates for insurance policies, hence hindering insurance markets.
Put differently, an insurance company determines insurance costs based on insurance models that classify segments of the population to groups sharing similar data, such as; age range, sex, marital status, residence, driving record, and the like. For each segment, the insurance model then employs a “one size fit” for all members—with no further differentiation. Nonetheless, such approach fails to consider additional variances that exist between members in same category, and hence squanders valuable data related to each individual's unique traits that can further affect respective insurance rates.

SUMMARY

The following presents a simplified summary in order to provide a basic understanding of some aspects described herein. This summary is not an extensive overview of the claimed subject matter. It is intended to neither identify key or critical elements of the claimed subject matter nor delineate the scope thereof. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.
The subject innovation customizes insurance rates in real time to correspond to unique behavior/character traits of a user/driver by exploiting contextual data (e.g., from third party data banks, driving behavior, and the like), which are related to such user/driver. A rate adjustment component can interact with insurance companies that provide bids based on the contextual data—wherein, insurance costs can be dynamically adjusted, and the user/driver switched in real-time between such insurance companies (e.g., based on bids)—to ensure obtaining optimum rates. The contextual data and/or data banks can include data pertaining to the motor vehicle (e.g., maintenance history, current vehicle conditions, sensor monitoring operation of the motor vehicle, and the like); data related to the driver (e.g., via health insurance records, police records, internet records, and the like); and data related to operating environment (e.g., weather, geographical location, and the like.) Moreover, the real-time contextual driving data can include both an intensity portion and a frequency portion, which represent severity and regularity of driving episodes (e.g., slamming the brakes, gradual/sudden deceleration, velocity variances, and number of such acts in a predetermined period).
In a related aspect, a switching component can switch user/driver (e.g., automatically with no additional input from user) to an insurance company that bids the best rate. Hence, during a trip the user/driver can actually be insured by various suppliers during different segments of such trip—(each of which supplies an optimal rate for the trip segment that switching thereto occurred.) Alternatively, the user can remain with the same insurance company throughout the trip; and yet comply with its mandates (e.g., limits on speed/acceleration, car maintenance) for obtaining optimal rates.
Hence, the subject innovation introduces two insurance models, namely: 1) a user/driver complying with requirements of a single insurance company to keep current insurance rates; or 2) different insurance companies bidding for the behavior of user not willing to necessarily abide to requirements of a single insurance company. Moreover, the subject innovation can be implemented as part of a system local to each motor vehicle (e.g., the rate adjustment component and the switching component are positioned on the motor vehicle); or part of a central management system, or a combination thereof. It is to be appreciated that even though the subject innovation is primarily described in context of an automobile, the subject innovation is not so limited and can be applied to any type of vehicle that requires insurance; such as motor boats, airplanes, motorcycles, and the like.
To the accomplishment of the foregoing and related ends, certain illustrative aspects of the claimed subject matter are described herein in connection with the following description and the annexed drawings. These aspects are indicative of various ways in which the subject matter may be practiced, all of which are intended to be within the scope of the claimed subject matter. Other advantages and novel features may become apparent from the following detailed description when considered in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an exemplary block diagram of a switching component and a rate adjustment component according to an aspect of the subject innovation.

FIG. 2 illustrates a particular aspect of a switching component that has an analyzer component according to a further aspect.

FIG. 3 illustrates a particular aspect of a system that illustrates exemplary type of contextual data according to a further aspect.

FIG. 4 illustrates a system that determines location of a vehicle as part of contextual data related to driving behavior of an owner or user.

FIG. 5 illustrates a particular methodology of customizing insurance rates according to a further aspect of the subject innovation.

FIG. 6 illustrates a related methodology of switching insurance to a policy with an optimal rate according to a further aspect.

FIG. 7 illustrates an exemplary system that obtains contextual data related to biometrics of a driver/owner in real-time.

FIG. 8 illustrates an inference component that facilitates customizing insurance rates based on contextual data.

FIG. 9 illustrates a particular system that employs cameras mounted on the vehicle in conjunction with various aspects of the subject innovation.

FIG. 10 illustrates an exemplary environment for implementing various aspects of the subject innovation.

FIG. 11 is a schematic block diagram of a sample-computing environment that can be employed for dynamically determining an insurance rate according to a further aspect of the subject innovation.

DETAILED DESCRIPTION

The various aspects of the subject innovation are now described with reference to the annexed drawings, wherein like numerals refer to like or corresponding elements throughout. It should be understood, however, that the drawings and detailed description relating thereto are not intended to limit the claimed subject matter to the particular form disclosed. Rather, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the claimed subject matter.
FIG. 1 illustrates an exemplary system 100 that customizes insurance rates to correspond to unique behavior of—and/or-character traits of a user/owner by exploiting data banks 111, 112, 113 such as data mined by third parties. Such leveraging from data banks enables insurance providers to bid in real time, and hence an owner and/or user of a vehicle can benefit from competition among various insurance providers, to obtain optimum rates. The system 100 includes a rate adjustment component 131 that in real time can determine the various rates from a plurality of insurance providers 121, 122, 123 (1 to m, where m is an integer). In one particular aspect, a retrieval agent (not shown) associated with the rate adjustment component 131 can pull insurance data from the insurance providers based on the contextual data supplied thereto. For example, such contextual data can be data records related to the vehicle 111 (such as auto shop service records, current service status for the car, and the like); data related to the individual driver 112 (such as health records, criminal records, shopping habits, and the like); data related to the environment 113 (road condition, humidity, temperature, and the like) and data related to real time driving 115 (frequency of braking, accelerating, intensity of such actions, and the like).
The retrieval agent (not shown) can pull data from the insurance providers 121, 122, 123 and further publish such data to enable a rich interaction between the users on a display or a within a written communication environment. The retrieval agent can further generate an instance for a connection with the insurance providers. Accordingly, a connection instance can be employed by the rate adjustment component 131 to store connection information such as the state of data conveyance, the data being conveyed, connection ID and the like. Such information can additionally be employed to monitor progress of data transfer to the written communication environment or display, for example.
Accordingly drivers/owners of motor vehicles can pull or receive data from the insurance providers 121, 122, 123, wherein received data can be posted (e.g., displayed on a monitor) and the connection instance can be concurrently updated to reflect any successful and/or failed data retrievals. Thus, at any given moment the connection instance can include the most up-to-date version of data transferred between the motor vehicle and the insurance providers.
Moreover, the switching component 141 can automatically switch user/driver to an insurance provider/company that bids the best rate. Such switching component 141 can employ interrupts both in hardware and/or software to conclude the switching from one insurance provider to another insurance provider. For example, the interrupt can convey receipt of a more optimal insurance rate or completion of a pull request to the insurance providers 121, 122, 123 or that a configuration has changed. In one particular aspect, once an interrupt occurs, an operating system analyzes the state of the system 100 and performs an action in accordance with the interrupt, such as a change of insurance provider, for example.
Such interrupts can be in form of asynchronous external events to the processor that can alter normal program flow. Moreover, the interrupts can usually require immediate attention from a processor(s) associated with the system 100. In one aspect, when an interrupt is detected, the system often interrupts all processing to attend to the interrupt, wherein the system can further save state of the processor and instruction pointers on related stacks.
According to a further aspect, the switching component 141 can employ an interrupt dispatch table in memory, which can be accessed by the processor to identify a function that is to be called in response to a particular interrupt. For example, a function can accept a policy from an insurance provider, cancel an existing policy, and/or clear the interrupt for a variety of other reasons. The function can execute processes such as clearing the state of the interrupt, calling a driver function to check the state of an insurance policy and clearing, setting a bit, and the like.
FIG. 2 illustrates a switching component 241 that further includes an analyzer component 251, which further employs threshold ranges and/or value(s) (e.g., pricing ranges for insurance policies, terms of the insurance policy, and the like) according to a further aspect of the subject innovation. The analyzer component 251 can compare a received value for insurance coverage to the predetermined thresholds, which can be designated by an owner/driver. Accordingly, the analyzer component 251 can determine if the received insurance coverage policies are within the desired range as specified by a user an “accept” or “reject”, and/or further create a hierarchy from “low” to “high” based on criteria designated by the user (e.g., price of the insurance policy, terms of the insurance policy, and the like).
According to a further aspect, the analyzer component 251 can further interact with a rule engine component 252. For example, a rule can be applied to define and/or implement a desired evaluation method for an insurance policy. It is to be appreciated that the rule-based implementation can automatically and/or dynamically define and implement an evaluation scheme of the insurance policies provided. Accordingly, the rule-based implementation can evaluate an insurance policy by employing a predefined and/or programmed rule(s) based upon any desired criteria (e.g., criteria affecting an insurance policy such as duration of the policy, number of drivers covered, type of risks covered, and the like.)
In a related example, a user can establish a rule that can implement an evaluation based upon a preferred hierarchy (e.g., weight) of a criteria that affects the insurance policy. For example, the rule can be constructed to evaluate the criteria based upon predetermined thresholds, wherein if such criteria does not comply with set thresholds, the system can further evaluate another criteria or attribute(s) to validate the status (e.g., “accept” or “reject” the insurance bid and operate the switching component based thereon). It is to be appreciated that any of the attributes utilized in accordance with the subject invention can be programmed into a rule-based implementation scheme.
FIG. 3 illustrates a system 300 that illustrates type of data for dynamically adjusting insurance costs according to an aspect of the subject innovation. As explained earlier, the subject innovation customizes insurance rates to correspond to unique behavior/character traits of a user/driver by exploiting data banks (e.g., from third parties), in conjunction with real time contextual driving data (e.g., driving behavior) of such user/driver. Accordingly, insurance costs can be dynamically adjusted and the user/driver switched in real-time between insurance companies (e.g., based on bids), to ensure obtaining optimum rates.
The data banks can include data pertaining to the motor vehicle 310 (e.g., maintenance history, current vehicle conditions, and the like); data related to the driver (e.g., via health insurance records, police records, internet records, and the like); and data related to operating environment 330 (e.g., weather, geographical location, and the like.) Moreover, the real-time contextual driving data 340 can include both an intensity portion and a frequency portion, which represent severity and regularity of driving episodes (e.g., slamming the brakes, gradual/sudden deceleration, velocity variances, and the like). Although a single data store for each of data type, it is to be understood that multiple data stores can be employed in connection with the subject innovation. In addition, it is to be appreciated that any number of reference data sources and stores can be located remotely from the rate adjustment component (not shown), and the analyzer component (not shown). In one particular aspect, the data bank 320 can further include user profiles and demographics such as user preferences, age, gender, religion, ethnicity, education level, likes, dislikes, interests, occupation, political ideology, and the like—which can be employed in connection with the contextual information to facilitate generating customized insurance policies by the insurance providers.
Furthermore, the system 300 can aggregate such user information amongst a plurality of users in connection with providing relevant results to a group of individuals (e.g., with similar interaction histories, engaged in a common activity, part of a multi-user collaboration, within a work environment or social network). Such retrieval can benefit from the construction of models of interest from data about information access or consumption patterns by people with similar attributes and/or immersed in similar contexts (e.g., similar demographics, similar locations, and the like). It is to be appreciated that the functionality associated with context-based insurance policies can also be employed as a context-based filter, to eliminate policies that do not match user predetermined thresholds.
The insurance providers 350, 352, 354 and the motor vehicle can also be part of a network 370 (e.g., wireless network) such as a system area network or other type of network, and can include several hosts, 361, 362, 363, 364, 365, which can be personal computers, servers or other types of computers. Such hosts generally can be capable of running or executing one or more application-level (or user-level) programs, as well as initiating an I/O request (e.g., I/O reads or writes). Moreover, such I/O units can include one or more I/O controllers connected thereto, and each of the I/O can be any of several types of I/O devices, such as storage devices (e.g., a hard disk drive, tape drive) or other I/O device. The hosts and I/O units and their attached I/O controllers and devices can be organized into groups such as clusters, with each cluster including one or more hosts and typically one or more I/O units (each I/O unit including one or more I/O controllers). The hosts and I/O units can be interconnected via a collection of routers, switches and communication links (such as wires, connectors, cables, and the like) that connects a set of nodes (e.g., connects a set of hosts and I/O units) of one or more clusters.
Furthermore, the wireless communication network can be cellular or WLAN communication network; such as Global System for Mobile communication (GSM) networks, Universal Mobile Telecommunication System (UMTS) networks, and wireless Internet Protocol (IP) networks like Voice over Internet Protocol (VOIP) and IP Data networks. Accordingly, the portable device employed by insurance providers 350, 352, 354 can be a hand-held wireless communication device that can communicate with a wireless communication network, (e.g. wireless communication network) to further engage in an enriched text messaging in the written communication environment. Such connections can be shared among the insurance providers 350, 352, 354 which can employ, personal computers, workstations, and any device capable of text messaging such as mobile phones for example.
It is to be appreciated that the system can supply data to insurance providers in accordance with determined and/or inferred context as well as automatically generate queries in the background as a function of user state. For example, a device (e.g., cell phone, computing device, on-board computer system for a vehicle, boat, plane, or machine, and the like) can dynamically generate responses for queries in the background as a function of constantly changing state, initiate searches in the background and cache results for immediate viewing to the user. As an example, searches of databases of detailed highway safety information, conditioned on a current weather context, can be retrieved as a function of the location and velocity of a user's vehicle. Moreover, the driver/owner of the vehicle can be appropriately notified (e.g., via visual and/or audio signals) regarding a potential change of insurance premiums. For example, immediate visual or audio feedback can be supplied to the driver via a heads up display, as to provide instantaneous notifications regarding change in driver's insurance policy—while mitigating driving distractions (e.g., line of sight for driver remains substantially unchanged.)
Accordingly, the subject innovation introduces two insurance models, namely: 1) a user/driver complying with requirements of a single insurance company to maintain current insurance rates; or 2) different insurance companies bidding for the behavior of user not willing to necessarily abide to requirements of an insurance company. Moreover, the subject innovation can be implemented as part of a system local to each motor vehicle (e.g., the rate adjustment component and the switching component are positioned on the motor vehicle); or part of a central management system, or a combination thereof.
FIG. 4 illustrates a system 400 that determines location of a vehicle 450 as part of customizing contextual data related to driving behavior of an owner/user in real-time, according to an aspect of the subject innovation. As explained earlier, the real-time contextual driving data can include both an intensity portion 465 and a frequency portion 475, which represent severity and regularity of driving episodes/actions respectively (e.g., slamming the brakes, gradual/sudden deceleration, velocity variances, and number of times such acts occur). Initially, a geographic location for the vehicle can be determined via a GPS positioning system 406, wherein such data can then be matched with real-time weather and/or road conditions for the determined location via the wireless network 410 and/or the IP network 416, which interact with geographic maps serve 416 or weather server 420. In general, the geographic location data is determined by receiving geographic location signals of a GPS (global positioning system) technology. For example, the GPS can consist of a constellation of twenty-four satellites each in its own orbit approximately 11,000 miles above the earth. Each of the satellites orbits the earth in about twelve hours, and the positions of which are monitored by ground stations. The satellites each include atomic clocks for extremely accurate timing (e.g., within three nanoseconds of each other) that provides the capability to locate the receiver (e.g., a handheld terrestrial receiver) on the earth within, in some applications, one meter resolution.
The GPS location data can be received from a receiver (not shown) which is, for example, a wireless assisted GPS (WAGPS) device such as a GPS-enabled cellular telephone, GPS-enabled PDA, and the like WAGPS facilitates the transmission of the GPS location data from the receiver to a remote location. Generally, such can occur through a cellular network (not shown) where the receiver is a cellular telephone associated with insurance providers, to an IP network (not shown) (e.g., the Internet), and terminating at the remote location, node or device on the Internet or on a subnet thereof.
When receiving geographic location signals from several of the GPS satellites, the receiver can further calculate the distance to each satellite of the communicating satellites and then calculate its own position, on or above the surface of the earth. It is to be appreciated, however, that the geographic location technology can also include, for example, WiFi triangulation, cellular telephone triangulation, radio frequency signal strengths, and digital television signals.
FIG. 5 illustrates a particular methodology 500 of customizing insurance rates according to a further aspect of the subject innovation. While the exemplary method is illustrated and described herein as a series of blocks representative of various events and/or acts, the subject innovation is not limited by the illustrated ordering of such blocks. For instance, some acts or events may occur in different orders and/or concurrently with other acts or events, apart from the ordering illustrated herein, in accordance with the innovation. In addition, not all illustrated blocks, events or acts, may be required to implement a methodology in accordance with the subject innovation. Moreover, it will be appreciated that the exemplary method and other methods according to the innovation may be implemented in association with the method illustrated and described herein, as well as in association with other systems and apparatus not illustrated or described. Initially and at 510 contextual data from various data banks can be accessed by the insurance providers or supplied thereto. As explained earlier, the data banks can include data pertaining to the motor vehicle (e.g., maintenance history, current vehicle conditions, and the like); data related to the driver (e.g., via health insurance records, police records, internet records, and the like); and data related to operating environment (e.g., weather, geographical location, and the like.) Moreover, the real-time contextual driving data can include both an intensity portion and a frequency portion, which represent severity and regularity of driving episodes (e.g., slamming the brakes, gradual/sudden deceleration, velocity variances, and the like). Subsequently and at 520, such data can be analyzed by the insurance providers as to customize an insurance rate based thereon at 530. Subsequently, the customized insurance rate can then be sent from an insurance provider to an owner/user of the vehicle (e.g., in form of an insurance bid) at 540.
FIG. 6 illustrates a related methodology 600 of switching insurance to a policy with an optimal rate according to a further aspect of the subject innovation. Initially threshold ranges and/or discrete values can be set by the user/owner of the vehicle. For example, such threshold values and/or discrete ranges can relate to pricing ranges that the owner/user will consider or will not consider at all, various terms of the insurance policy such as minimum amount of liability desired, number of drivers that user/owner desires to be included in the policy, and the like. Such thresholds can facilitate determining whether an insurance bid should be considered and/or out right rejected. At 620, the insurance bids can be obtained from the insurance providers, and an optimal insurance rate selected at 630. The insurance policy can then be switched (e.g., automatically) to such optimal rate. Hence, during a trip the user/driver can actually be insured by various suppliers during different segments of such trip—(each of which supplied an optimal rate for the trip segment that switching thereto occurred.)
FIG. 7 illustrates exemplary system 700 that collects contextual data related to acquiring biometrics from a driver/owner 701 of a vehicle 704 (e.g., in real time) to facilitate customizing an insurance policy and further switching the user/owner 701 to an optimal policy. In one particular aspect, values such as a biometric data (e.g., temperature, blood sugar level, and the like) can be asynchronously read via sensor of the modular component 708 and output values can be written directly to the I/O table by slave processors for subsequent communication to the process by specialized communications circuitry.
During execution of a control routine, (e.g., real time monitoring of blood sugar level), values of the inputs and outputs exchanged with and/or acquired by the components 711, 712, 713, 714 and/or controlled process for data collection, can pass through the I/O table. The values of inputs in the I/O table can further be asynchronously updated from the controlled process by dedicated modular components. Moreover, modality specific circuitry can communicate with input and/or output modules over a bus on a backplane or network communications. The modality specific circuitry can also asynchronously write values of the outputs in the I/O table to the controlled process of data collection. The output values from the I/O table can then be communicated to one or more of the modular components and/ or associated output modules for interfacing with the process of data collection. Thus, a slave processor(s) can simply access the I/O table rather than needing to communicate directly with the master processor and/or controlled process of data collection.
For example, the system 700 can be adapted to acquire data related to Electromyography (EMG, frequency range 2-500 Hz), Electrocardiography (ECG, frequency range 0.05-100 Hz, resolution of 24 bits), Electroencephalography (EEG, frequency range 0.16-100 Hz), blood pressure, and the like. The system can employ a Common Data Controller, which has a Bus Interface, I/O functions (controls), and a module clock. The Bus Interface can coordinate activities of the system 700 with a bus controller of the master controller (not shown), for transmittal of biometric indicia (e.g., medical parameter data) and reception of control data.
Likewise, the I/O functions can control operation for the specific circuitry (e.g., specific to EKG, EEG, and the like). Typically, the system 700 (e.g., required for a controlled data collection, such as collecting/monitoring blood sugar in real time) can be connected to other modular components on a common backplane through a network or other communications medium. As explained earlier, the system 700 can include processors, power supplies, network communication modules, and I/O modules exchanging input and output signals directly with the master controller and/or the controlled process. Data may be exchanged between modules using a backplane communications bus, which may be serial or parallel, or via a network.
In addition to performing I/O operations based solely on network communications, smart modules can be employed that can execute autonomous logical or other control programs or routines. A RAM memory medium can function as a data storage medium for buffering of collected, so that data is not lost when the system bus is in use by other functions. Such memory also enables asynchronous data collection. Additionally, the module clock provides for timing on a modular component for data collection functions. The module clock supplies timing for data collection functions, and enables synchronous collection of data for supplying to insurance providers.
It is to be appreciated that various sensor components for a distributed controlled data collection system can be spatially distributed along a common communication link, such as a belt 716 around a user's body as illustrated in FIG. 7. Certain components can thus be located proximate to predetermined portions of a driver's body. Data can be communicated with such modular components 711, 712, 713, 714 over a common communication link, or network, wherein all modules on the network communicate via a standard communications protocol.
Likewise, sensor can be distributed at various location of the vehicle 704 to monitor health of the vehicle and driving behavior of user (e.g., on gas pedal, steering wheel, and the like). Similarly, in such a distributed control system of the vehicle 704, one or more I/O modules are provided for interfacing with a data collection process, wherein the outputs derive their control or output values in the form of a message from a master controller over a network or a backplane. For example, a sensor component can receive an output value from a processor, via a communications network or a backplane communications bus. The desired output value for controlling data collection associated with biometric indicia can be generally sent to the output module in a message, such as an I/O message. The system 700 that receives such a message can provide a corresponding output (analog or digital) to the controlled process for data collection. The system 700 can also measure a value of a process variable and report the input values to a master controller or peer modular component over a network or backplane. The input values can further be employed by the master processor for performing control computations.
FIG. 8 illustrates a system 800 with an inference component 830 that can facilitate customizing insurance rates based on contextual data and switching to an optimal rate based thereon. As used herein, the term “inference” refers generally to the process of reasoning about or inferring states of the system, environment, and/or user from a set of observations as captured via events and/or data. Inference can be employed to identify a specific context or action, or can generate a probability distribution over states, for example. The inference can be probabilistic—that is, the computation of a probability distribution over states of interest based on a consideration of data and events. Inference can also refer to techniques employed for composing higher-level events from a set of events and/or data. Such inference results in the construction of new events or actions from a set of observed events and/or stored event data, whether or not the events are correlated in close temporal proximity, and whether the events and data come from one or several event and data sources.
For example a process for determining an insurance rate can be facilitated via an automatic classifier system and process. A classifier is a function that maps an input attribute vector, x=(x1, x2, x3, x4, xn), to a confidence that the input belongs to a class, that is, f(x)=confidence(class). Such classification can employ a probabilistic and/or statistical-based analysis (e.g., factoring into the analysis utilities and costs) to prognose or infer an action that a user desires to be automatically performed.
A support vector machine (SVM) is an example of a classifier that can be employed. The SVM operates by finding a hypersurface in the space of possible inputs, which hypersurface attempts to split the triggering criteria from the non-triggering events. Intuitively, this makes the classification correct for testing data that is near, but not identical to training data. Other directed and undirected model classification approaches include, e.g., naive Bayes, Bayesian networks, decision trees, neural networks, fuzzy logic models, and probabilistic classification models providing different patterns of independence can be employed. Classification as used herein also is inclusive of statistical regression that is utilized to develop models of priority.
As will be readily appreciated from the subject specification, the subject invention can employ classifiers that are explicitly trained (e.g., via a generic training data) as well as implicitly trained (e.g., via observing user behavior, receiving extrinsic information). For example, SVM's are configured via a learning or training phase within a classifier constructor and feature selection module. Thus, the classifier(s) can be used to automatically learn and perform a number of functions, including but not limited to determining according to a predetermined criteria when to update or refine the previously inferred schema, tighten the criteria on the inferring algorithm based upon the kind of data being processed (e.g., type of contextual data, real time driving behavior and the like.)
FIG. 9 illustrates a further aspect of the subject innovation that employs a plurality of cameras 901, 902, 903, 904, 905 to facilitate collection of contextual data, and/or for accident analysis. In one particular aspect, any of the cameras 901. 902, 903, 904 and 905 can include a monitor shell having a monitor lens on the outside and a charge-coupled device (CCD) on the inside. Such camera can further include a motherboard shell with motherboard peripheral circuits on the inside, and a transmission line can electrically couple the motherboard and the CDD—wherein an image output line can be additionally mounted on the motherboard. It is to be appreciated that the cameras can be mounted on various locations, such as by mounting the motherboard on the inside of the car trunk apart from a car bumper, for example. It is further to be appreciated that other type of cameras such as metal oxide semiconductor (CMOS) cameras, infrared cameras, and the like can be employed to transfer data to insurance providers via buffers 916, 918, 920 (1 to k, where k is an integer).
As illustrated by the exemplary system 910, a threading and communication architecture can be employed to facilitate interaction of the cameras 901, 902, 903, 904, 905 with the insurance provider(s) 950. The system 910 includes two threads, namely, a camera interface thread 912 and an instruction thread 914. The camera interface thread 912 can process user interface activity of the cameras, such as managing commands, menus and the like. Likewise, the instruction thread 914 provides instructions for retrieving of data to and from the cameras and their associated applications.
The two threads 912 and 914 are operatively linked or connected through one or more buffers 916, 918, and 920. Each buffer 916, 918, 920 can hold information retrieved from the cameras for a predetermined time, as well as queues commands and requests from the camera interface thread 912 to the instruction thread 914. The buffers 916, 918, and 920 can further serve as a synchronization system between the threads.
For example, when an application associated with a camera is initiated, initially only one interface thread such as 912 can become active. The interface thread 912 can perform application initialization operations, such as creation of the initial GUI elements, command-line parsing, and the like. The camera interface thread 912 also gathers information about the process to be performed from command-line arguments, menu selections and dialog boxes.
The instruction thread 914 can be responsible for all major use of the associated cameras such as view angle, pixel size, number of frames collected per second, and the like. The instruction thread 914 can supply a queue of commands to the camera interface thread 912, such as data being stored in buffers 916, 918, and 920, and by carrying out active requests. Accordingly, buffers can be refilled, wherein data that has been expired (e.g., after a predetermined period such as several minutes) can be discarded. The predetermined period can further be extended by the insurance provider(s) 950, such as when an accident occurs and the driver contacts the insurance provider—and hence data related to the accident can be preserved.
The word “exemplary” is used herein to mean serving as an example, instance or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs. Similarly, examples are provided herein solely for purposes of clarity and understanding and are not meant to limit the subject innovation or portion thereof in any manner. It is to be appreciated that a myriad of additional or alternate examples could have been presented, but have been omitted for purposes of brevity.
Furthermore, all or portions of the subject innovation can be implemented as a system, method, apparatus, or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware or any combination thereof to control a computer to implement the disclosed innovation. For example, computer readable media can include but are not limited to magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips . . . ), optical disks (e.g., compact disk (CD), digital versatile disk (DVD) . . . ), smart cards, and flash memory devices (e.g., card, stick, key drive . . . ). Additionally it should be appreciated that a carrier wave can be employed to carry computer-readable electronic data such as those used in transmitting and receiving electronic mail or in accessing a network such as the Internet or a local area network (LAN). Of course, those skilled in the art will recognize many modifications may be made to this configuration without departing from the scope or spirit of the claimed subject matter.
Furthermore, all or portions of the subject innovation can be implemented as a system, method, apparatus, or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware or any combination thereof to control a computer to implement the disclosed innovation. For example, computer readable media can include but are not limited to magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips . . . ), optical disks (e.g., compact disk (CD), digital versatile disk (DVD) . . . ), smart cards, and flash memory devices (e.g., card, stick, key drive . . . ). Additionally it should be appreciated that a carrier wave can be employed to carry computer-readable electronic data such as those used in transmitting and receiving electronic mail or in accessing a network such as the Internet or a local area network (LAN). Of course, those skilled in the art will recognize many modifications may be made to this configuration without departing from the scope or spirit of the claimed subject matter.
In order to provide a context for the various aspects of the disclosed subject matter, FIGS. 10 and 11 as well as the following discussion are intended to provide a brief, general description of a suitable environment in which the various aspects of the disclosed subject matter may be implemented. While the subject matter has been described above in the general context of computer-executable instructions of a computer program that runs on a computer and/or computers, those skilled in the art will recognize that the innovation also may be implemented in combination with other program modules.
As used in this application, the terms “component”, “system”, “engine” are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more computers.
Generally, program modules include routines, programs, components, data structures, and the like, which perform particular tasks and/or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the innovative methods can be practiced with other computer system configurations, including single-processor or multiprocessor computer systems, mini-computing devices, mainframe computers, as well as personal computers, hand-held computing devices (e.g., personal digital assistant (PDA), phone, watch . . . ), microprocessor-based or programmable consumer or industrial electronics, and the like. The illustrated aspects may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. However, some, if not all aspects of the innovation can be practiced on stand-alone computers. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
With reference to FIG. 10, an exemplary environment 1010 for implementing various aspects of the subject innovation is described that includes a computer 1012. The computer 1012 includes a processing unit 1014, a system memory 1016, and a system bus 1018. The system bus 1018 couples system components including, but not limited to, the system memory 1016 to the processing unit 1014. The processing unit 1014 can be any of various available processors. Dual microprocessors and other multiprocessor architectures also can be employed as the processing unit 1014.
The system bus 1018 can be any of several types of bus structure(s) including the memory bus or memory controller, a peripheral bus or external bus, and/or a local bus using any variety of available bus architectures including, but not limited to, 11-bit bus, Industrial Standard Architecture (ISA), Micro-Channel Architecture (MSA), Extended ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Universal Serial Bus (USB), Advanced Graphics Port (AGP), Personal Computer Memory Card International Association bus (PCMCIA), and Small Computer Systems Interface (SCSI).
The system memory 1016 includes volatile memory 1020 and nonvolatile memory 1022. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer 1012, such as during start-up, is stored in nonvolatile memory 1022. By way of illustration, and not limitation, nonvolatile memory 1022 can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. Volatile memory 1020 includes random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, RAM is available in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus RAM (DRRAM).
Computer 1012 also includes removable/non-removable, volatile/non-volatile computer storage media. FIG. 10 illustrates a disk storage 1024, wherein such disk storage 1024 includes, but is not limited to, devices like a magnetic disk drive, floppy disk drive, tape drive, Jaz drive, Zip drive, LS-60 drive, flash memory card, or memory stick. In addition, disk storage 1024 can include storage media separately or in combination with other storage media including, but not limited to, an optical disk drive such as a compact disk ROM device (CD-ROM), CD recordable drive (CD-R Drive), CD rewritable drive (CD-RW Drive) or a digital versatile disk ROM drive (DVD-ROM). To facilitate connection of the disk storage devices 1024 to the system bus 1018, a removable or non-removable interface is typically used such as interface 1026.
It is to be appreciated that FIG. 10 describes software that acts as an intermediary between users and the basic computer resources described in suitable operating environment 1010. Such software includes an operating system 1028. Operating system 1028, which can be stored on disk storage 1024, acts to control and allocate resources of the computer system 1012. System applications 1030 take advantage of the management of resources by operating system 1028 through program modules 1032 and program data 1034 stored either in system memory 1016 or on disk storage 1024. It is to be appreciated that various components described herein can be implemented with various operating systems or combinations of operating systems.
A user enters commands or information into the computer 1012 through input device(s) 1036. Input devices 1036 include, but are not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, TV tuner card, digital camera, digital video camera, web camera, and the like. These and other input devices connect to the processing unit 1014 through the system bus 1018 via interface port(s) 1038. Interface port(s) 1038 include, for example, a serial port, a parallel port, a game port, and a universal serial bus (USB). Output device(s) 1040 use some of the same type of ports as input device(s) 1036. Thus, for example, a USB port may be used to provide input to computer 1012, and to output information from computer 1012 to an output device 1040. Output adapter 1042 is provided to illustrate that there are some output devices 1040 like monitors, speakers, and printers, among other output devices 1040 that require special adapters. The output adapters 1042 include, by way of illustration and not limitation, video and sound cards that provide a means of connection between the output device 1040 and the system bus 1018. It should be noted that other devices and/or systems of devices provide both input and output capabilities such as remote computer(s) 1044.
Computer 1012 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer(s) 1044. The remote computer(s) 1044 can be a personal computer, a server, a router, a network PC, a workstation, a microprocessor based appliance, a peer device or other common network node and the like, and typically includes many or all of the elements described relative to computer 1012. For purposes of brevity, only a memory storage device 1046 is illustrated with remote computer(s) 1044. Remote computer(s) 1044 is logically connected to computer 1012 through a network interface 1048 and then physically connected via communication connection 1050. Network interface 1048 encompasses communication networks such as local-area networks (LAN) and wide-area networks (WAN). LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet/IEEE 802.3, Token Ring/IEEE 802.5 and the like. WAN technologies include, but are not limited to, point-to-point links, circuit switching networks like Integrated Services Digital Networks (ISDN) and variations thereon, packet switching networks, and Digital Subscriber Lines (DSL).
Communication connection(s) 1050 refers to the hardware/software employed to connect the network interface 1048 to the bus 1018. While communication connection 1050 is shown for illustrative clarity inside computer 1012, it can also be external to computer 1012. The hardware/software necessary for connection to the network interface 1048 includes, for exemplary purposes only, internal and external technologies such as, modems including regular telephone grade modems, cable modems and DSL modems, ISDN adapters, and Ethernet cards.
FIG. 11 is a schematic block diagram of a sample-computing environment 1100 that can be employed for customizing insurance rates according to an aspect of the subject innovation. The system 1100 includes one or more client(s) 1110. The client(s) 1110 can be hardware and/or software (e.g., threads, processes, computing devices). The system 1100 also includes one or more server(s) 1130. The server(s) 1130 can also be hardware and/or software (e.g., threads, processes, computing devices). The servers 1130 can house threads to perform transformations by employing the components described herein, for example. One possible communication between a client 1110 and a server 1130 may be in the form of a data packet adapted to be transmitted between two or more computer processes. The system 1100 includes a communication framework 1150 that can be employed to facilitate communications between the client(s) 1110 and the server(s) 1130. The client(s) 1110 are operatively connected to one or more client data store(s) 1160 that can be employed to store information local to the client(s) 1110. Similarly, the server(s) 1130 are operatively connected to one or more server data store(s) 1140 that can be employed to store information local to the servers 11 30.
What has been described above includes various exemplary aspects. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing these aspects, but one of ordinary skill in the art may recognize that many further combinations and permutations are possible. Accordingly, the aspects described herein are intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims.
Furthermore, to the extent that the term “includes” is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.

Claims

1. A computer implemented system that customizes insurance rates to user profiles comprising:

a rate adjustment component that dynamically adjusts an insurance rate in real time for a user based on contextual data; and

a switching component that switches the user to an insurance provider(s) that supplies optimal rate based on the contextual data.

2. The computer implemented system of claim 1 further comprising a retrieval agent that pulls insurance data from the insurance provider(s.)

3. The computer implemented system of claim 1, the contextual data includes data pertaining to a motor vehicle; or data related to a driver of the motor vehicle; or data related to environment that the motor vehicle operates therein; or real time data related to driving behavior; or a combination thereof.

4. The computer implemented system of claim 1 further comprising an analyzer component that employs threshold ranges to accept or reject insurance bids from the insurance provider.

5. The computer implemented system of claim 3, the real time driving data pertains to both frequency and intensity of driving actions.

6. The computer implemented system of claim 2 further comprising sensor positioned on a body of driver for collection of biometric data.

7. The computer implemented system of claim 1 further comprising an inference component that facilitates customization of insurance rates.

8. The computer implemented system of claim 7 further comprising an artificial intelligence component that employs classifiers.

9. The computer implemented system of claim 8, the switching component is an automatic switch.

10. A computer implemented method comprising the following computer executable acts:

employing a processor to execute computer executable instructions stored on a computer readable medium to perform the following acts:

acquiring contextual data associated with a driver of a motor vehicle; and;

dynamically adjusting insurance rates in real time based on contextual data via a rate determination component that receives offers from insurance companies.

11. The computer implemented method of claim 10 further comprising switching insurance policy for a motor vehicle of a user to an insurance company via a switching component mounted on the motor vehicle.

12. The computer implemented method of claim 11 further comprising pulling insurance bids from the insurance company.

13. The computer implemented method of claim 11 further comprising employing an interrupt for the switching act.

14. The computer implemented method of claim 11 further comprising setting threshold values or ranges to accept or reject a bid.

15. The computer implemented method of claim 11 further comprising evaluating an insurance policy via a rule-based implementation.

16. The computer implemented method of claim 11 further comprising collecting data by cameras mounted on the motor vehicle.

17. The computer implemented method of claim 11 further comprising automatically switching a driver to an insurance provider.

18. The computer implemented method of claim 11 further comprising employing both intensity and frequency of a driving act as part of the contextual data.

19. The computer implemented method of claim 11 further comprising employing an artificial intelligence component to facilitate selection of an insurance policy.

20. A computer implemented system that customizes insurance rates to user profiles comprising:

means for dynamically adjusting an insurance rate in real time for a user based on contextual data; and

means for switching the user to an insurance provider that supplies optimal rate based on the contextual data.