US20170270615A1 - System and Method for Vehicle Telematics Data - Google Patents

Abstract

A system and method are disclosed herein to receive preliminary telematics data collected by a smartphone and actual telematics data collected by a data collection device. The system includes a computer memory and a processor in communication with the computer memory. The computer memory stores the data indicative of preliminary telematics data collected by the smartphone, including at least one of geo-position information of the vehicle and vehicle kinematics data. The processor is configured to calculate an initial benefit based upon the preliminary telematics data, and apply the initial benefit in exchange for receiving the data indicative of actual telematics data via the data collection device within the vehicle. When the received data indicative of the actual telematics data meets a pre-determined condition, the processor may compute a final benefit based on the actual telematics data.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This application is a continuation application of co-pending U.S. patent application Ser. No. 14/715,272 entitled “System And Method For Receiving Actual Telematics Data For A Vehicle Based On Determination Of An Initial Benefit From Preliminary Telematics Data Collected By A Smartphone” and filed on May 18, 2015, which is a continuation application of U.S. patent application Ser. No. 13/529,115 entitled “System and Method to Determine an Initial Insurance Policy Benefit Based on Telematics Data Collected by a Smartphone” and filed on Jun. 21, 2012, issued as U.S. Pat. No. 9,037,394, which claims priority from U.S. Provisional Application No. 61/650,040 entitled “System and Method Associated with Telematics Data” and filed on May 22, 2012, the entire contents of each of which are incorporated herein by reference for all purposes.
FIELD OF THE INVENTION
• In general, the invention relates to a computerized system and method for determining an insurance policy benefit based on telematics data.
BACKGROUND OF THE INVENTION
• The insurance industry has begun exploring the use of telematics sensors and other location-aware devices associated with motor vehicles as a way of determining driver behavior and, from this, driver risk for the purposes of underwriting, pricing, renewing, and servicing vehicle insurance. The devices can capture very high frequency information on location, speed, vehicle handling, vehicle characteristics, and other factors, which can be used in setting vehicle insurance rates. This data may be used to identify safety events, such as a moment of relatively high de-acceleration (e.g., a “hard brake” event). The data may also indicate if a vehicle is often driven during times of relatively high risk (e.g., late at night) and/or at speeds above a predetermined threshold (e.g., above 75 miles per hour). It can be difficult, however, to encourage drivers to provide such data and/or to adjust driving habits in ways that may lower risk.
SUMMARY
• Therefore, there is a need in the art for ways to encourage drivers to provide telematics information and/or modify behaviors so as to reduce a likelihood of accidents and losses. Such measures may, according to some embodiments, use safety events calculated from location information and/or other vehicle data, such as speed, orientation, and acceleration. Statistical analysis of the data may be used to classify safety events as being associated with different intensity levels.
• Accordingly, systems and methods are disclosed herein to determine a benefit for an insurance policy. In some embodiments, a processor is configured to calculate and apply an initial insurance policy benefit, calculated based on preliminary telematics data collected by a smartphone, in exchange for receiving data indicative of actual telematics data. When the data indicative of actual telematics data meets a pre-determined condition, the processor may compute a final benefit and replace the initial benefit with the final benefit.
• In some embodiments, a processor may receive data indicative of telematics data collected from a sensor coupled to a vehicle, wherein the telematics data includes at least one of geo-position information and kinematics data. The processor may identify safety events and associated safety event locations based on the telematics data. Indications of the safety events may then be displayed to a driver on a map display.
• According to another aspect, the invention relates to computerized methods for carrying out the functionalities described above. According to another aspect, the invention relates to non-transitory computer readable medium having stored therein instructions for causing a processor to carry out the functionalities described above.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 is an architectural model of a system for determining a discount for an insurance premium based on telematics data, according to an illustrative embodiment of the invention.
• FIG. 2 is a block diagram of a computing system as used inFIG. 1, according to an illustrative embodiment of the invention.
• FIG. 3 is a block diagram of a vehicle and a device coupled to the vehicle for collecting telematics data, according to an illustrative embodiment of the invention.
• FIG. 4 illustrates an automobile in accordance with some embodiment of the invention.
• FIG. 5 is a flowchart of a method according to an illustrative embodiment of the invention.
• FIGS. 6 through 9 illustrate map displays in accordance with some embodiments described herein.
• FIGS. 10 and 11 illustrate current telematics displays according to some embodiments.
• FIG. 12 illustrates a safety score display according to some embodiments.
• FIG. 13 illustrates a likely discount display according to some embodiments.
• FIG. 14 illustrates how an insurance premium might change over time according to some embodiments.
• FIGS. 15 through 17 are examples of insurance discount calculator displays in accordance with some embodiments described herein.
• FIG. 18 is a block diagram of an insurance platform provided in accordance with some embodiments.
• FIG. 19 is a tabular portion of a telematics database in accordance with some embodiments.
DESCRIPTION OF CERTAIN ILLUSTRATIVE EMBODIMENTS
• To provide an overall understanding of the invention, certain illustrative embodiments will now be described, including systems and methods for determining an insurance premium discount or other benefit using geo-spatial information and/or other telematics data. However, it will be understood by one of ordinary skill in the art that the systems and methods described herein may be adapted and modified as is appropriate for the application being addressed and that the systems and methods described herein may be employed in other suitable applications, and that such other additions and modifications will not depart from the scope thereof.
• FIG. 1 is a block diagram of asystem100 for determining a discount for an insurance premium based on telematics data according to an illustrative embodiment. Thesystem100 uses data collected along multiple trips traveled by a vehicle, including, for example, speeding information, time of day information, and/or safety event information. An insurance company may use route data, such as Global Positioning Satellite (“GPS”) latitude and longitude data, acceleration/deceleration data, speed data, and/or vehicle orientation data collected along a route traveled by the vehicle to determine an insurance premium discount to be associated with a driver and/or a vehicle. With a sufficient amount of data, the insurance company can calculate a level of risk score for the driver based on, for example, the driver's driving habits. The insurance company can use the score for setting or adjusting a discount value to be applied to an insurance premium. In some implementations, a score or discount is determined by a third party data processing service. In addition, the score or discount may be set by an underwriter, which may be a part of the insurance company or otherwise affiliated with or in a third party arrangement with the insurance company. According to any embodiments described here, a score might be used to determine a premium price, a premium adjustment, and/or any other benefit that may be associated with an insurance policy (e.g., a decreased deductable value or increased overall coverage amount).
• Thesystem100 includes one ormore vehicles102, each having adata collection device104. Thevehicle102 may be an automobile, motorcycle, truck, bus, watercraft, aircraft, or any other vehicle operated by a driver. Adata collection device104 is coupled to avehicle102 for collecting data about the vehicle's location, movements, or other information that can be used to determine risk scores. For vehicles with multiple drivers, the data may be associated with the vehicle itself or with the individual drivers. Thedata collection device104 may be positioned inside thevehicle102, attached to the outside of thevehicle102, or integrated into thevehicle102. Thedata collection device104 is in communication with aninsurance company system108 over acommunication network150. Thedata collection device104 may communicate with theinsurance company system108 though a wireless network such as a cellular network or using a wireless Internet connection. In general, thedata collection device104 can be any computing device or plurality of computing devices in cooperation having a data collection sensor (e.g., an antenna or an accelerometer), a processor, a memory, and a means for transmitting the collected data. Thecustomer vehicle102 ordata collection device104 may include an antenna for receiving signals from Global Navigation Satellite System (“GNSS”) satellites, numbered 1 through “n” inFIG. 1. In one implementation, thedata collection device104 is also configured to process the collected data. In some embodiments, the data processing protects the driver's privacy by encrypting the data, removing location information, producing summary information, or taking other measures to reduce the likelihood that location information, speed information, or other sensitive information are received by the insurance company or third parties.
• In some embodiments, rather than sending collected data directly to theinsurance company system108, thedata collection device104 sends collected data to adata processing service106, which processes the data to determine a risk score and/or an appropriate premium discount for a driver that is then sent to theinsurance company system108. This can help protect a driver's privacy, since the insurance company does not get detailed data about a driver's location, but only receives summary information. Using adata processing service106 is in some implementations also preferable to having thedata collection device104 process data to output a risk score because it reduces the processing power needed bydata collection device104 and because using a third partydata processing service106 may also make it more difficult for drivers to tamper with the data. Thedata processing service106 can perform additional monitoring functions, such as vehicle security monitoring or providing location-based alerts (e.g., alerting a parent or employer when a vehicle travels an unusual path) and/or speed alerts. Note that an insurance company might received detailed reports from the third partydata processing service106, summary reports (with certain details removed), and/or supplemented information (e.g., including information from one or more public databases).
• Theinsurance company system108 includes a plurality ofapplication servers112, a plurality of loadbalancing proxy servers114, aninsurance company database116, aprocessing unit120, andcompany terminal122. These computing devices are connected by alocal area network124.
• Theapplication servers112 are responsible for interacting with thedata collection device104 and/or thedata processing service106. The data exchange between theinsurance company system108 anddata collection device104 and/ordata processing service106 can utilize push and pull technologies where theapplication servers112 of theinsurance company system108 can act as both a server and client for pushing data to the data processing service106 (e.g., which vehicles to monitor, when to stop data collection, rules for monitoring services requested by the customer) and for pulling data from thedata processing service106. Theapplication servers112 or other servers of theinsurance company system108 can request to receive periodic data feeds from thedata collection device104 and/ordata processing service106. The communication between theapplication servers112 and thedata processing service106 can follow various known communication protocols, such as TCP/IP. Alternatively, theapplication servers112 anddata processing service106 can communicate with each other wirelessly, e.g., via cellular communication, Wi-Fi, Wi-Max, or other wireless communications technologies or combination of wired or wireless channels. The loadbalancing proxy servers114 operate to distribute the load amongapplication servers112.
• Theinsurance company database116 stores information about vehicular insurance policies. For each insurance policy, thedatabase116 includes for example and without limitation, the following data fields: policy coverage, a risk rating, policy limits, deductibles, the agent responsible for the sale or renewal, the date of purchase, dates of subsequent renewals, product and price of product sold, applicable automation services (for example, electronic billing, automatic electronic funds transfers, centralized customer service plan selections, etc.), customer information, customer payment history, or derivations thereof. Note that any of the embodiments described herein might be associated with existing insurance policies, newly issued insurance policies, and/or policies that have not yet been issued (e.g., during a trial phase before a policy is issued). According to some embodiments, information collected during a trial period may influence a discount or other benefit that is eventually associated with an insurance policy.
• Theprocessing unit120 is configured for determining the price of an insurance premium based on a risk rating for a driver or vehicle. Theprocessing unit120 may comprise multiple separate processors, such as a risk or safety processor, which may calculates a safety rating from raw or processed data from thedata collection device104 ordata processing service106 over thecommunications network150; and a business logic processor, which determines a premium price for a policyholder based on, among other things, a risk score. In some embodiments, insurance premium prices or information for making insurance pricing determinations may be generated by a third-party underwriter, which is separate from theinsurance company system108. An exemplary implementation of a computing device for use in theprocessing unit120 is discussed in greater detail in relation toFIG. 2.
• Thecompany terminals122 provide various user interfaces to insurance company employees to interact with theprocessing system120. The interfaces include, without limitation, interfaces to review telematics data, or risk ratings; to retrieve data related to insurance policies; to manually adjust a risk rating; and to manually adjust premium pricing. In some instances, different users may be given different access privileges. For example, marketing employees may only be able to retrieve information on insurance policies but not make any changes to data. Such interfaces may be integrated into one or more websites for managing theinsurance company system108 presented by theapplication servers112, or they may be integrated into thin or thick software clients or stand alone software. Thecompany terminals122 can be any computing devices suitable for carrying out the processes described above, including personal computers, laptop computers, tablet computers, smartphones, servers, and other computing devices.
• Theuser terminal130 provides various user interfaces to customers to interact with theinsurance company system108 over thecommunications network150. Potential customers can useuser terminals130 to retrieve policy and pricing information for insurance policies offered by the insurance company. Customers can enter information pertaining to changes in their insurance policy, e.g., changes in policy coverage, addition or subtraction of drivers, addition or subtraction of vehicles, relocation, mileage information, etc. Customers can also use theuser terminal130 for a pay-as-you-go insurance policy in which customers purchase insurance by the trip or mile.
• In some embodiments, thedata collection device104 may not be continually connected to theinsurance company system108 via thenetwork150. For example, thedata collection device104 may be configured to temporarily store data if thedata collection device104 becomes disconnected from the network, like when it travels out of range of cellular towers. When the connection is restored, thedata collection device104 can then transmit the temporarily stored data to theinsurance company system108. Thedata collection device104 may alternatively be configured to connect to thecommunications network150 through a user's home Wi-Fi network. In this case, thedata collection device104 stores trip data until it returns to the vicinity of the user's home, connects to the user's wireless network, and sends the data. In some embodiments, thedata collection device104 is not connected to thenetwork150 at all, but rather, data collected is transmitted to the insurance company though other means. For example, a customer can receive adata collection device104 from the insurance company, couple thedevice104 to his car for a set period of time or number of miles, and then either mail thedevice104 with the collected data to theinsurance company system108 or extract and send the collected data to theinsurance company system108 via mail, email, or though a website.
• FIG. 2 is a block diagram of acomputing device200 used for carrying out at least one of an insurance premium discount determination and business logic processing described in relation toFIG. 1, according to an illustrative embodiment of the invention. Thecomputing device200 comprises at least onenetwork interface unit204, an input/output controller206,system memory208, and one or moredata storage devices214. Thesystem memory208 includes at least one Random Access Memory (“RAM”)210 and at least one Read-Only Memory (“ROM”)212. All of these elements are in communication with a Central Processing Unit (“CPU”)202 to facilitate the operation of thecomputing device200. Thecomputing device200 may be configured in many different ways. For example, thecomputing device200 may be a conventional standalone computer or alternatively, the functions ofcomputing device200 may be distributed across multiple computer systems and architectures. Thecomputing device200 may be configured to perform some or all of the insurance premium discount determination and business logic processing, or these functions may be distributed across multiple computer systems and architectures. In the embodiment shown inFIG. 2, thecomputing device200 is linked, vianetwork150 orlocal network124, to other servers or systems housed by theinsurance company system108, such as theload balancing server114, and/or theapplication servers112.
• Thecomputing device200 may be configured in a distributed architecture, wherein databases and processors are housed in separate units or locations. Thecomputing device200 may also be implemented as a server located either on site near theinsurance company system108, or it may be accessed remotely by theinsurance company system108. Some such units perform primary processing functions and contain at a minimum a general controller or aprocessor202 and asystem memory208. In such an embodiment, each of these units is attached via thenetwork interface unit204 to a communications hub or port (not shown) that serves as a primary communication link with other servers, client or user computers and other related devices. The communications hub or port may have minimal processing capability itself, serving primarily as a communications router. A variety of communications protocols may be part of the system, including, but not limited to: Ethernet, SAP, SAS™, ATP, BLUETOOTH™, GSM and TCP/IP.
• TheCPU202 comprises a processor, such as one or more conventional microprocessors and one or more supplementary co-processors such as math co-processors for offloading workload from theCPU202. TheCPU202 is in communication with thenetwork interface unit204 and the input/output controller206, through which theCPU202 communicates with other devices such as other servers, user terminals, or devices. Thenetwork interface unit204 and/or the input/output controller206 may include multiple communication channels for simultaneous communication with, for example, other processors, servers or client terminals. Devices in communication with each other need not be continually transmitting to each other. On the contrary, such devices need only transmit to each other as necessary, may actually refrain from exchanging data most of the time, and may require several steps to be performed to establish a communication link between the devices.
• TheCPU202 is also in communication with thedata storage device214. Thedata storage device214 may comprise an appropriate combination of magnetic, optical and/or semiconductor memory, and may include, for example, RAM, ROM, flash drive, an optical disc such as a compact disc and/or a hard disk or drive. TheCPU202 and thedata storage device214 each may be, for example, located entirely within a single computer or other computing device; or connected to each other by a communication medium, such as a USB port, serial port cable, a coaxial cable, an Ethernet type cable, a telephone line, a radio frequency transceiver or other similar wireless or wired medium or combination of the foregoing. For example, theCPU202 may be connected to thedata storage device214 via thenetwork interface unit204.
• TheCPU202 may be configured to perform one or more particular processing functions. For example, thecomputing device200 may be configured for calculating a risk or safety score for a driver or vehicle. Thesame computing device200 or another similar computing device may be configured for calculating an aggregate risk rating based on multiple safety scores (e.g., associated with different clusters of similar routes). Thesame computing device200 or another similar computing device may be configured for calculating an insurance premium discount for a vehicle or driver based at least the risk scores and/or the safety rating.
• Thedata storage device214 may store, for example, (i) anoperating system216 for thecomputing device200; (ii) one or more applications218 (e.g., computer program code and/or a computer program product) adapted to direct theCPU202 in accordance with the present invention, and particularly in accordance with the processes described in detail with regard to theCPU202; and/or (iii) database(s)220 adapted to store information that may be utilized to store information required by the program. The database(s)220 may including all or a subset of data stored ininsurance company database116, described above with respect toFIG. 1, as well as additional data, such as formulas or manual adjustments, used in establishing the insurance risk for a vehicle.
• Theoperating system216 and/orapplications218 may be stored, for example, in a compressed, an uncompiled and/or an encrypted format, and may include computer program code. The instructions of the program may be read into a main memory of the processor from a computer-readable medium other than thedata storage device214, such as from theROM212 or from theRAM210. While execution of sequences of instructions in the program causes theCPU202 to perform the process steps described herein, hard-wired circuitry may be used in place of, or in combination with, software instructions for implementation of the processes of the present invention. Thus, embodiments of the present invention are not limited to any specific combination of hardware and software.
• Suitable computer program code may be provided for scoring risk based on telematics data associated with a plurality of trips taken by a vehicle or driver over a period of time. The program also may include program elements such as an operating system, a database management system and “device drivers” that allow the processor to interface with computer peripheral devices (e.g., a video display, a keyboard, a computer mouse, etc.) via the input/output controller206.
• The term “computer-readable medium” as used herein refers to any non-transitory medium that provides or participates in providing instructions to the processor of the computing device (or any other processor of a device described herein) for execution. Such a medium may take many forms, including but not limited to, nonvolatile media and volatile media. Nonvolatile media include, for example, optical magnetic, or opto-magnetic disks, or integrated circuit memory, such as flash memory. Volatile media include Dynamic Random Access Memory (“DRAM”), which typically constitutes the main memory. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM or Electronically Erasable Programmable Read-Only Memory (“EEPROM”), a FLASH-EEPROM, any other memory chip or cartridge, or any other non-transitory medium from which a computer can read.
• Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to the CPU202 (or any other processor of a device described herein) for execution. For example, the instructions may initially be borne on a magnetic disk of a remote computer (not shown). The remote computer can load the instructions into its dynamic memory and send the instructions over an Ethernet connection, cable line, or even telephone line using a modem. A communications device local to a computing device (e.g., a server) can receive the data on the respective communications line and place the data on a system bus for the processor. The system bus carries the data to main memory, from which the processor retrieves and executes the instructions. The instructions received by main memory may optionally be stored in memory either before or after execution by the processor. In addition, instructions may be received via a communication port as electrical, electromagnetic or optical signals, which are exemplary forms of wireless communications or data streams that carry various types of information.
• FIG. 3 is a block diagram of avehicle102 having adata collection device104. As described with regard toFIG. 1, thevehicle102 may be an automobile, motorcycle, truck, bus, watercraft, aircraft, or any other vehicle operated by a driver. Thevehicle102 includes avehicle computer302, an On-Board Diagnostics (“OBD”)port304, andvehicle telematics sensors306. Thedata collection device104 is connected to thevehicle102 via anOBD port connector322 connected to theOBD port304 to receive telematics data and other information. Thedata collection device104 includes aCPU310, aGNSS receiver312, anaccelerometer314,memory316, auser interface318, and awireless communications device320. TheCPU310 is in communication with the other elements of thedata collection device104 to facilitate the operation of thedata collection device104. The CPU can also be configured to process data received from theGNSS receiver312, theaccelerometer314, and theOBD port connector322. Data processing may include calculating risk scores, calculating safety ratings, calculating intermediate values for determining insurance premium discounts, or encrypting data sent by thewireless communications device320.
• The Global Navigation Satellite System (“GNSS”)receiver312 includes an antenna and associated signal processing circuitry for receiving signals from GNSS satellites, such as the satellites numbered 1 through n inFIG. 1, and determining its location from the signals. GNSS satellites may be, for example, GPS, GLONASS, Galileo, or Beidou satellites which send time and orbital data from which thedata collection device104 can calculate its location. In some configurations, theCPU310 calculates the location of the vehicle from data from thereceiver312. TheCPU310 can pull location data from theGNSS receiver312 at set time intervals, such as every 0.1 seconds, 0.2 seconds, 0.5 seconds, 1 second, 2 seconds, 7 seconds, or 10 seconds. TheCPU310 sends the location data to thememory316 along with a time and date stamp indicating when the vehicle was at the location. In some embodiments, theGNSS receiver312 may be part of a separate GNSS device used by the driver for obtaining driving directions. In this case, theGNSS receiver312 transmits data to thedata collection device104 though a wired connection or a wireless connection, e.g., BLUETOOTH or Wi-Fi.
• Theaccelerometer314 is a device that measures proper acceleration. Data collected from anaccelerometer314 may include or be used for obtaining the g-force, acceleration, orientation, shock, vibration, jerk, velocity, speed, and/or position of the vehicle. Some or all of these types of data are received or calculated by theCPU310. TheCPU310 may collect data at intervals such as every 0.1 seconds, 0.2 seconds, 0.5 seconds, 1 second, 2 seconds, 7 seconds, or 10 seconds and store the data in thememory316. Each data point is time and date stamped and/or location stamped. In some embodiments, theCPU310 determines intervals between data stored in thememory316 based on trends in the data. The rate of data collection may vary based on vehicle behavior; for example, if a driver is travelling along a straight road at a consistent speed, theCPU310 may save data less frequently than if the driver is making frequent turns. In some embodiments, only “exception data” evident of safety events or other unusual driving behavior is stored. For example, theCPU310 may only save accelerations, decelerations, hard turns, speeds, lane change speeds, etc. with rates above a certain threshold.
• TheOBD port connector322 is used to collect data from thevehicle computer302 and/orvehicle telematics sensors306 viaOBD port304. Thevehicle computer302 may provide information about the vehicle's speed, the number of miles traveled, whether the vehicle is running or not, seatbelt usage, airbag deployment, and vehicle diagnostics. Vehicle diagnostics data can be used to determine whether a safety event was caused by the driver's actions or related to a vehicle malfunction, such as low tire pressure, low oil pressure, high engine temperature, loss of power, and stalling. The vehicle may containadditional telematics sensors306 for, e.g., vehicle tracking, monitoring gasoline consumption, and vehicle safety. Data obtained by thedata collection device104 from thevehicle computer302 andtelematics sensors306 via theOBD port304 can supplement or be used instead of data collected by theGNSS receiver312 and/oraccelerometer314. In some embodiments, thedata collection device104 turns on automatically when the vehicle is turned on; thedata collection device104 may be powered by thevehicle102.
• Thedata collection device104 also includes awireless communications device320 for sending collected data to and receiving commands from thedata processing service106 and/orinsurance company system108 via thenetwork150. Thedata collection device104 may also be configured for communication with the driver or a passenger viauser interface318. Theuser interface318 includes output components, such as a screen or speakers, and input components, such as a touch screen, keyboard, or microphone. Theuser interface318 can output risk data, route summary data, vehicle diagnostics data, and any data collected from theGNSS receiver312,accelerometer314, and/orOBD port304. In some embodiments, thedata collection device104 is also a navigation device that can calculate and display a route to a destination inputted by the user.
• Thevehicle102 anddata collection device104 may be associated with, for example, an automobile. For example,FIG. 4 illustrates anautomobile400 in accordance with some embodiment of the invention. Theautomobile400 includes one ormore sensors410 that may be used to collect telematics information, such as a GNSS receiver or similar device. Note that telematics information might instead be associated with, for example, a motorcycle, a recreational vehicle, a boat, an airplane, etc.
• FIG. 5 is a flowchart of amethod500 for determining an insurance policy benefit for a driver or vehicle based on telematics data. Themethod500 can be performed by thedata collection device104, thedata processing service106, theinsurance company system108, or any combination of these. Themethod500 includes the step of collecting preliminary telematics data via a smartphone associated with a driver of a vehicle (Step S510), For example, a smartphone application might time of day information associated with driving, day of week, location, velocity, and/or mileage information.
• An initial benefit is calculated based on the preliminary telematics data and a policy is issued in accordance with that benefit in exchange for receiving data indicative of actual telematics data (Step S520). For example, an insurance company may offer a driver a 5% initial discount to his or her insurance premium if he or she agrees to participate in a telematics program. Another driver, associated with preliminary telematics data (collected by a smartphone) indicating a potentially higher level or risk might only be offered a 3% initial premium discount. Other examples of policy benefits include a monetary discount (e.g., 100 dollars), an insurance coverage amount, and/or a deductable amount. If the driver agrees, the insurance company may provide the driver with an apparatus, including sensors, storage means, and/or a transmitted, to be installed in his or her vehicle. The calculated initial benefit may, according to some embodiments, encourage drivers to participate in the telematics program.
• Themethod500 may further include the storage of actual telematics data received from a sensor “within” the vehicle (Step S530). As used herein, a sensor may be “within” a vehicle if it is attached to the vehicle (e.g., either inside or outside the body of the vehicle), is powered by the vehicle, or is otherwise inside or associated with the vehicle. To obtain actual telematics data (step S530), data from receivers and sensors such asGNSS receiver312,accelerometer314,vehicle computer302, andvehicle telematics sensors306 may be collected by thedata collection device104 and stored in thememory306 of thedata collection device306 and/or sent to thedata processing service106 orinsurance company system108.
• It may then be determined that the data indicative of the actual telematics data meets a pre-determined condition (Step S530). For example, an insurance company might determine that actual telematics data has been collected from a driver for three consecutive months or 2,000 miles. After the pre-determined condition has been met, a final benefit for the insurance policy may be computed based on the telematics data; and the initial discount may be replaced with the final discount (Step S540). For example, based on actual telematics data it may be determined that the driver should actually receive a 16% discount. In this case, the initial 5% discount would be replaced by the 16% discount for the insurance policy. According to some embodiments, an indication of the final benefit for the insurance policy may be output (e.g., shown on a display or included in an email message to the driver).
• According to some embodiments, prior to computing the final benefit, a range of potential benefits may be computed based on at least a portion of the actual telematics data. For example, consider a program where a final discount is not calculated until three months of telematics data has been collected. In this case, after two months of telematics data has been collected, a likely range of potential insurance discounts might be predicted and output to the driver. For example, a driver might be told that based on his or her driving habits during those two months, a discount of between 8% and 12% should be expected.
• The telematics data used to compute a final discount or other insurance policy benefit might include, for example, times of day associated with driving, velocities associated with driving, distances associated with driving, weather information, and/or traffic information. Moreover, the insurance company might identify safety events within the telematics data (e.g., hard brake events) and/or a severity estimation of the safety events. Moreover, according to some embodiments an insurance platform might output an indication of a suggested driving modification along with a discount or other benefit goal for the insurance premium of the automobile insurance policy. For example, the driving modification might include a suggested route to a destination to achieve a 15% discount for an insurance premium
• According to some embodiments, information about safety events may be displayed to a driver on a map display. For example, referring now toFIG. 6, a diagram650 depicting auser interface602 is shown. Theuser interface602 may be displayed ondevice600 such as a mobile telephone, PDA, personal computer, or the like. For example, thedevice600 may be a PC, an IPHONE® from Apple, Inc., a BLACKBERRY® from RIM, a mobile phone using the Google ANDROID® operating system, or the like. Theuser interface602 depicts a portion of a map showing a portion of Fairfield County in the State of Connecticut. Theuser interface602 may display the location ofsafety events654,656 (e.g., locations of rapid de-acceleration, speeding events, etc.) collected in connection with all drivers who have provided telematics data while driving in that area. In this way, a driver may be alerted and take extra precautions when driving in an area of relatively high risk.
• In some embodiments, such as the one depicted inFIG. 6, identifiedsafety events654,656 may associated with a plurality of different event types and a substantial number of drivers. For example,safety events654,656 associated with both hard braking events and excessive speeding may be displayed in connections with thousands of drivers. Note that a driver may instead be more interested in his or her own personal safety events. For example, referring now toFIG. 7, a diagram750 depicting auser interface702 is shown. As before, theuser interface702 may be displayed ondevice700 such as a mobile telephone and may depict a portion of a map. Theuser interface702 may display to a driver the location ofsafety events754,756 (e.g., locations of rapid de-acceleration) that were a result of his or her driving habits. In this way, a driver may be become aware of unsafe driving habits and adjust his or her behaviors to reduce the risk of an accident.
• Note that driving habits and conditions may change over time. Thus, according to some embodiments a driver may interact with a map display to view safety events associated with a selected range of dates and/or times. For example, referring now toFIG. 8, a diagram850 depicting anotheruser interface802 is shown. As before, theuser interface802 may be displayed ondevice800 such as a mobile telephone and may depict a portion of a map. Theuser interface802 may display to a driver the location ofsafety events854,856 (e.g., locations of rapid de-acceleration) that occurred during a particular period of time (e.g., during the prior 24 hours, the prior week, the prior month, the prior year, etc.). Note that thesafety events854,856 might be associated with the driver's own driving habits or may reflect those of all drivers who have provided telematics data. According to some embodiments, a driver may interact with a “sliding scale” bar to select which period of time should be used to filter thesafety events854,856. Note that the identifiedsafety events854,856 may associated with a plurality of different event types. For example,safety events854,786 associated with both hard braking events and excessive speeding may be displayed. In this case, different labels (e.g., reflecting event types “1,” “2,” or “3” as illustrated inFIG. 8), icons, or colors may be used to differentiate event types. Similarly, thesafety events854,856 may be associated with different levels of risk or severity (e.g., high, medium, and low intensity events) and these may also be differentiated on theuser interface802.
• In some cases, a driver might be interested in a particular type of safety event. According to some embodiments, a selection of a particular event type may be received from the driver and only indications of the safety events associated with that particular event type may be displayed to the driver on the map display (e.g., only hard brake events). For example, referring now toFIG. 9, a diagram950 depicting anotheruser interface902 is shown. As before, theuser interface902 may be displayed ondevice900 such as a mobile telephone and may depict a portion of a map. Theuser interface902 may display to a driver the location ofsafety events954,956 (e.g., locations of rapid de-acceleration) that are of particular interest to the driver. In the example ofFIG. 9, the driver has selected to view all high intensity brake events. Note that thesafety events954,956 might be associated with the driver's own driving habits or may reflect those of all drivers who have provided telematics data. Moreover, selection of a particular event icon might result in the display of further details about that particular event (e.g., the date and time the event occurred). In addition to, or instead of, filtering safety events based on event type or severity, a driver might be able to display events associated with a particular type of driver or vehicle (e.g., based on age, driving experience, gender, etc.).
• In addition to the locations where safety events occurred, a driver might be interested in his or her overall performance in connection with one or more types of safety events and/or how that performance compares to others, how that performance is modifying his or her current insurance premium discount, etc.FIG. 10 illustrates acurrent telematics display1000 according to some embodiments. In particular, thedisplay1000 includes agraphical representation1010 of information about a particular risk variables derived from telematics data which may be categorized as “below average,” “average,” or “above average” from a risk perspective. Thedisplay1100 also includes a current score (e.g., calculated at least in part based on the risk variable) and a current discount (e.g., determined based on the current score). The current discount might, according to some embodiments, represent the final discount or other benefit described with respect to Step S540 ofFIG. 5. Note that thegraphical representation1010 might instead be a sliding scale, letter grade (“B+”), or any other type of indication. In addition to, or instead of, a current number of events per week, a driver might be shown an average number of events for all drivers or for a particular type of driver or vehicle (e.g., based on age, driving experience, gender, etc.).
• FIG. 11 illustrates anothercurrent telematics display1100 according to some embodiments. In particular, thedisplay1100 includes a graphical representation of information about three different risk variables derived from telematics data, a current score (e.g., calculated based on the risk variables) and a current discount or other policy benefit (e.g., determined based on the current score). The current discount might, according to some embodiments, represent the final discount. According to some embodiments, the current discount might be calculated in substantially real time or be recalculated using new data when the driver's safety scores are more likely change, e.g., if the customer moves, changes jobs, has a child, or retires, or at certain time periods, e.g., every year, every two years, every three years, every five years, every ten years, etc. In some embodiments, both prospective pricing and retroactive pricing are used. For example, a customer being continually monitored might receive a premium discount for a time period based on one or more past safety scores, and if the customer's actual score rating for the time period was greater than or less than the expected rating, an adjustment may be applied as appropriate.
• By way of example only, a score model might consist of two main elements: (1) a percentage of time speeding over a threshold value (e.g., 75 miles per hour) and (2) an annualized miles value associated with times of day. Each driver's score might, for example, start with fifteen (15) points then be modified by adding speeding points and/or subtracting time of day mileage by the factors shown below:
• For Time of Day:

• 	Risk Level	Per Mile Subtraction

  	Risky	0.005
  	Moderate	0.0025
  	Low	0.00125

  
  Where “risky” is defined as driving between midnight and 4:00 am every day of the week, “moderate” is driving from 4:00 am to 6:00 am and 9:00 pm to midnight every day of the week and 6:00 am to 9:00 am and 3:00 pm to 6:00 pm on weekdays. “Low” risk times may comprise all other times of the day.
• For Speeding Over a Threshold:

• 	% Time	Speeding Points

  	>0.75%	0
  	0.1 -0.75%	5
  	<0.1%	10

• In such an example, consider a driver who drives 5,000 annualized miles. Moreover, 4,000 of these miles are driven during moderate risk times of the day and 1,000 of these miles are driven during low risk times of the day. Moreover, the driver speeds over the threshold 0.05% of the time. In this case, a safety score might be determined as follows:
• 
  Safety Score=15+10−(4,000*0.0025+1,000*0.00125)=13.75
• Rounding this to the nearest whole number and looking it up in a risk/discount table, the driver might receive a 14% discount for his or her insurance premium.
• As another example, aggressive driving/hard braking events might be classified into different intensity or severity levels. For example, atype 1 event might have a threshold of from 340 to 500 milli-g (˜change in speed or velocity (delta-V) of greater than +/−7.5 mph/sec²) (e.g., from 14 mph to 25 mph in 1 second). Atype 2 event might have a threshold of from 501 to 750 milli-g (˜change in speed or velocity (delta-V) of greater than +/−11 mph/sec²) (e.g., from 65 mph to 45 mph in 1 second). Atype 3 event might have a threshold of 750 milli-g (˜change in speed or velocity (delta-V) of greater than +/−16.5 mph/sec²) (e.g., from 65 mph to 35 mph in 1 second). The severity of the event may then be used when determining an insurance premium discount of the driver.
• Note that a driver's safety score will change over time based on his or her driving habits.FIG. 12 is an example of asafety score display1200 that might be provided to a driver according to some embodiments. In particular, thedisplay1200 includes agraph1210 showing the drivers safety score over a particular period of time (e.g., over the last month or year). According to some embodiments, a driver may select the period of time depicted on thegraph1210. Such asafety score display1200 may encourage a driver to improve his or her safety score and become a less risky driver.
• An insurance premium discount or other benefit may be based at least in part on telematics data, a driver's safety score, and/or safety events that occur over time. According to some embodiments, a final discount value may not be determined until telematics data has been collected for a predetermined period of time and/or a predetermined number of miles. Even before the final discount value is determined, a likely discount value might be calculated based on a driver's known driving habits. For example, during a trial or initial period, a likely discount value might be calculated based on safety events that have occurred during the trial period.FIG. 13 illustrates alikely discount display1300 according to some embodiments. In particular, thedisplay1300 includes a current mostlikely discount1310 calculated based on the existing telematics data that has been collected for that driver. Moreover, an upperlikely discount1320 and lowerlikely discount1330 may also be displayed (e.g., there might be a 90% chance that the driver's final discount will not exceed the upper likely discount1320). Note that as more telematics data is collected over time, the upper and lowerlikely discounts1320,1330 might converge until, at the end of a trial period, the final premium discount is actually computed for the driver.
• According to some embodiments, an initial insurance policy benefit might be calculated based on preliminary telematics data collected by a smartphone and be provided to a driver while actual telematics data is collected.FIG. 14 is anillustration1400 of how an insurance premium might change over time according to some embodiments. A baseline insurance premium associated with what a driver would pay if he or she did not participate in a telematics program is represented by a dashedline1410 inFIG. 14 along with asolid line1420 representing his or her actual premiums that begin on the date the insurance policy is issued (represented by a dotted line inFIG. 14). During aperiod1430 prior to issuance of the insurance policy, preliminary telematics data is collected by a driver's smartphone. After the policy is issued and the driver agrees to participate in the program, actual telematics data is collected1440 (e.g., by devices provided by the insurance company and installed in the vehicle) until a pre-determined condition is met (e.g., three months of actual telematics data has been collected). During thistime1440, the driver's insurance premium is reduced by an initial discount amount that is calculated based at least in part on the preliminary telematics data collected by the driver's smartphone duringtime1430. After the pre-determined condition is met, a final discount amount is determined and applied to his or her insurance premium (and the final amount might be more or less than the initial discount depending on his or her driving habits as reflected by the actual telematics data).
• It may be difficult for a driver to predict or understand exactly how his or her driving habits will adjust a safety score or premium discount value. According to some embodiments, a telematics calculator may be provided for a driver to reduce this problem. For example,FIG. 15 is an example of atelematics calculator1500 display according to some embodiments. Thetelematics calculator1500 includes anentry box1510 where a user can enter a predicted number of hard brake events that he or she expects will occur each week. Thecalculator1500 also displays how many hard brake events are currently occurring each week based on the collected telematics data. Similarly, the driver may enter how many speeding events he or she predicts will occur. After entering these values, the driver may activate a “calculate”icon1520 causing the system to display a predicted score and/or premium discount value based on the predicted hard brake and speeding events. In this way, a driver may be encouraged to reduce these types of events and improve his or her driving habits.
• As another example,FIG. 16 is atelematics calculator1600 where a driver can predict safety events of various severity or intensity levels. In the example ofFIG. 16, a driver predicts how many “high,” “medium,” and “low” intensity hard brake events will occur each week. According to other embodiments, agraphical representation1610 may be used to reflect the entered information and/or may be used instead by the driver to enter information (e.g., by rotating a gauge or dial). Based on this information, thecalculator1600 may generate and display a predicted score and/or discount value.
• According to other embodiments, a driver might enter a desired score or premium discount value. For example,FIG. 17 is an example of aninsurance discount calculator1700 in accordance with some embodiments described herein. Thecalculator1700 may receive from a driver a desired premium discount via a sliding scale1710 (e.g., in the example ofFIG. 17 the driver is interested in receiving a 10% discount). Based on the desired discount, thecalculator1700 generates a number of safety events for various types of events and/or various levels of severity. For example, thecalculator1700 might indicate that 5 high intensity hard brake events should be experienced per week in order for the driver to receive a 10% discount. Thecalculator1700 may be, for example, associated with a web page, a smartphone application, and/or a kiosk and may encourage drivers to adopt less risky driving habits.
• The processes described herein may be performed by any suitable device or apparatus.FIG. 18 is one example of aninsurance platform1800 according to some embodiments. Theinsurance platform1800 may be, for example, associated with thesystem108 ofFIG. 1. Theinsurance platform1800 comprises aprocessor1810, such as one or more commercially available CPUs in the form of one-chip microprocessors, coupled to acommunication device1820 configured to communicate via a communication network (not shown inFIG. 18). Thecommunication device1820 may be used to communicate, for example, with one or more remote vehicles or third party services. Theinsurance platform1800 further includes an input device1840 (e.g., a mouse and/or keyboard to enter insurance discount information) and an output device1850 (e.g., a computer monitor to display aggregated insurance reports and/or results to an administrator).
• Theprocessor1810 also communicates with astorage device1830. Thestorage device1830 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., a hard disk drive), optical storage devices, and/or semiconductor memory devices. Thestorage device1830 stores aprogram1812 and/orscoring system1814 for controlling theprocessor1810. Theprocessor1810 performs instructions of theprograms1812,1814, and thereby operates in accordance with any of the embodiments described herein. For example, theprocessor1810 may receive telematics data associated with a vehicle. Theprocessor1810 may also analyze the telematics data and/or transmit discount information to a potential entity to be insured based at least in part on a computed risk score.
• Referring again toFIG. 18, theprograms1812,1814 may be stored in a compressed, uncompiled and/or encrypted format. Theprograms1812,1814 may furthermore include other program elements, such as an operating system, a database management system, and/or device drivers used by theprocessor1810 to interface with peripheral devices.
• As used herein, information may be “received” by or “transmitted” to, for example: (i) theinsurance platform1800 from another device; or (ii) a software application or module within theinsurance platform1800 from another software application, module, or any other source.
• In some embodiments (such as shown inFIG. 18), thestorage device1830 stores an underwriting database1860 and/or atelematics database1900. An example of a database that may be used in connection with theinsurance platform1800 will now be described in detail with respect toFIG. 19. Note that the database described herein is only one example, and additional and/or different information may be stored therein. Moreover, various databases might be split or combined in accordance with any of the embodiments described herein.
• Referring toFIG. 19, a table is shown that represents thetelematics database1900 that may be stored at theinsurance platform1800 according to some embodiments. The table may include, for example, entries identifying users, drivers, or vehicles. The table may also definefields1902,1904,1906,1908,1910 for each of the entries. Thefields1902,1904,1906,1908,1910 may, according to some embodiments, specify: adriver identifier1902, apolicy identifier1904, time ofday information1906, speedinginformation1908, and anapplicable discount1910. The information in thetelematics database1900 may be created and updated, for example, whenever data is received from remote vehicles.
• Thedriver identifier1902 may be, for example, a unique alphanumeric code identifying a customer or potential customer (e.g., a person or business). Thepolicy identifier1904 might represent an insurance product that may be offered to the user associated with thedriver identifier1902. The time ofday information1906 might represent an estimated number of hours driven per year during high, moderate, and/or low risk times of day. The speedinginformation1908 might indicate a percent of time the driver spends driving above a threshold value (e.g., 75 miles per hour). The applicable discount might represent, for example, an initial pre-determined discount value, a predicted value, and/or a final value calculated based on collected telematics data.
• The following illustrates various additional embodiments of the invention. These do not constitute a definition of all possible embodiments, and those skilled in the art will understand that the present invention is applicable to many other embodiments. Further, although the following embodiments are briefly described for clarity, those skilled in the art will understand how to make any changes, if necessary, to the above-described apparatus and methods to accommodate these and other embodiments and applications.
• Although specific hardware and data configurations have been described herein, not that any number of other configurations may be provided in accordance with embodiments of the present invention (e.g., some of the information associated with the databases described herein may be combined or stored in external systems).
• The present invention has been described in terms of several embodiments solely for the purpose of illustration. Persons skilled in the art will recognize from this description that the invention is not limited to the embodiments described, but may be practiced with modifications and alterations limited only by the spirit and scope of the appended claims.

Claims (20)

What is claimed is:

1. A vehicle telematics data management computer system comprising:

a data storage device configured to store data indicative of preliminary telematics data collected by a first data collection device within a vehicle and data indicative of actual telematics data collected by a second data collection device within the vehicle;

an application server configured to:

receive the data indicative of preliminary telematics data collected by the first data collection device within the vehicle during a first time period;

determine, based on the data indicative of preliminary telematics data, an initial safety-related benefit linked to driver participation in a telematics program;

responsive to receipt of data indicative of driver participation in the telematics program;

push, to a third-party telematics data processing platform, monitoring parameters for the third-party telematics data processing service to receive telematics data for the vehicle, during a second time period after the first time period, from the second data collection device within the vehicle, wherein the monitoring parameters include a stop parameter for stopping collection of the second time period telematics data, the stop parameter corresponding to a pre-determined condition for collection of the second time period telematics data;

receive, from the third-party telematics data processing platform based upon the second time period telematics data received by the third-party telematics data processing service and the monitoring parameters, date indicative of the actual telematics data collected by the second data collection device within the vehicle;

determine, based on the information corresponding to the actual telematics data, a final safety-related benefit, and

output an indication of the final safety-related benefit.

2. The computer system ofclaim 1, wherein the application server is further configured to determine the final safety-related benefit to be greater or less than the initial safety-related benefit depending on driving habits reflected by the data collected during the second time period.

3. The computer system ofclaim 1, wherein the application server is further configured to issue a policy to the driver responsive to receipt of data indicative of driver participation in the telematics program, and the initial safety-related benefit and the final safety-related benefits are benefits associated with the policy.

4. The computer system ofclaim 1, wherein the application server is further configured to:

pull data associated with the telematics data collected during the second time period from the third-party telematics data processing platform.

5. The computer system ofclaim 4, wherein the pulled data associated with the telematics data collected during the second time period from the third-party telematics data processing platform does not include location data corresponding to the vehicle.

6. The computer system ofclaim 1, wherein the first data collection device and the second data collection device comprise a same device.

7. The computer system ofclaim 1, wherein the stop parameter of the monitoring parameters corresponds to one of a time duration and a cumulative driving distance.

8. The computer system ofclaim 1, wherein the information corresponding to the actual telematics data received by the application server from the third-party telematics data processing platform comprises one of a risk score and a discount value.

9. The computer system ofclaim 1, wherein the first data collection device and the second data collection device being within the vehicle comprises the first data collection device and the second data collection device being one of: inside the vehicle, attached to an outside of the vehicle, or integrated into the vehicle.

10. The computer system ofclaim 1, wherein the second data collection device is configured to encrypt the actual telematics data and remove one or both of location information and speed information from the actual telematics data.

11. A computer-implemented method comprising:

receiving, by an application server of a vehicle telematics data processing computer system, data indicative of preliminary telematics data collected by a first data collection device within the vehicle for a first time period;

storing, in a data storage device coupled to the application server, the data indicative of preliminary telematics data;

determining, by the application server based on the data indicative of preliminary telematics data, an initial vehicle safety-related benefit to be applied at commencement of a second time period, after the first time period, and associated with driver participation in a telematics program;

responsive to receiving data indicative of an agreement to participate in a telematics program from a driver:

pushing, by the application server to a third-party telematics data processing service, monitoring parameters for receiving second time period telematics data for the vehicle from a second data collection device within the vehicle, wherein the monitoring parameters include a stop parameter for stopping collection of the second time period telematics data, the stop parameter corresponding to a pre-determined condition for collection of the second time period telematics data;

receiving, by the application server from the third-party telematics data processing platform based upon the second time period telematics data received by the third-party telematics data processing platform and the monitoring parameters, information corresponding to actual telematics data collected by the second data collection device within the vehicle;

storing, by the data storage device, the information corresponding to the actual telematics data collected by the second data collection device within the vehicle;

determining, by the application server based on the information corresponding to the actual telematics data, a final vehicle safety-related benefit, wherein the final vehicle safety-related benefit may be greater or less than the initial vehicle safety-related benefit depending on driving habits reflected by the telematics data collected during the second time period; and

outputting, by the application server, an indication of the final vehicle safety-related benefit.

12. The computer-implemented method ofclaim 11, wherein the final safety-related benefit is determined to be greater or less than the initial safety-related benefit depending on driving habits reflected by the data collected during the second time period.

13. The computer-implemented method ofclaim 11, further comprising, responsive to receiving data indicative of an agreement to participate in a telematics program from the driver, issuing a risk mitigation policy to the driver, and the initial safety-related benefit and the final safety-related benefits are benefits associated with the policy.

14. The computer-implemented method ofclaim 11, further comprising pulling, by the application server, data associated with the second time period telematics data from the third-party telematics data processing service.

15. The computer-implemented method ofclaim 14, wherein the pulled data associated with the second time period telematics data from the third-party telematics data processing platform does not include location data corresponding to the vehicle.

16. The computer-implemented method ofclaim 11, wherein the first data collection device and the second data collection device comprise a same device.

17. The computer-implemented method ofclaim 11, wherein the information corresponding to the actual telematics data received by the application server from the third-party telematics data processing platform comprises one or more of a detailed report, a summary report, and supplemental data corresponding to the vehicle.

18. The computer-implemented method ofclaim 11, wherein the first data collection device and the second data collection device being within the vehicle comprises the first data collection device and the second data collection device being one of: inside the vehicle, attached to an outside of the vehicle, or integrated into the vehicle.

19. The computer-implemented method ofclaim 11, wherein the actual telematics data is encrypted and does not include one or both of location information and speed information.

20. The computer-implemented method ofclaim 11, wherein the monitoring parameters further includes parameters to vary a rate of collection of the actual telematics data based on vehicle behavior.

Images