US20230289890A1 - Usage-Based Policies - Google Patents
Usage-Based Policies Download PDFInfo
- Publication number
- US20230289890A1 US20230289890A1 US18/130,104 US202318130104A US2023289890A1 US 20230289890 A1 US20230289890 A1 US 20230289890A1 US 202318130104 A US202318130104 A US 202318130104A US 2023289890 A1 US2023289890 A1 US 2023289890A1
- Authority
- US
- United States
- Prior art keywords
- driving
- data
- vehicle
- trip
- account
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 230000006399 behavior Effects 0.000 claims description 45
- 230000007613 environmental effect Effects 0.000 claims description 29
- 238000004891 communication Methods 0.000 claims description 24
- 238000012546 transfer Methods 0.000 claims description 24
- 230000001133 acceleration Effects 0.000 claims description 12
- 238000001556 precipitation Methods 0.000 claims description 9
- 238000000034 method Methods 0.000 abstract description 36
- 238000004458 analytical method Methods 0.000 description 39
- 230000004048 modification Effects 0.000 description 17
- 238000012986 modification Methods 0.000 description 17
- 230000010354 integration Effects 0.000 description 16
- 230000006870 function Effects 0.000 description 14
- 230000008569 process Effects 0.000 description 10
- 230000001186 cumulative effect Effects 0.000 description 8
- 238000010586 diagram Methods 0.000 description 8
- 238000012423 maintenance Methods 0.000 description 8
- 238000007405 data analysis Methods 0.000 description 6
- 238000012545 processing Methods 0.000 description 6
- 230000005540 biological transmission Effects 0.000 description 5
- LFQSCWFLJHTTHZ-UHFFFAOYSA-N Ethanol Chemical compound CCO LFQSCWFLJHTTHZ-UHFFFAOYSA-N 0.000 description 4
- 230000008859 change Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 238000010923 batch production Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 3
- 230000006855 networking Effects 0.000 description 3
- 241001465754 Metazoa Species 0.000 description 2
- 206010039203 Road traffic accident Diseases 0.000 description 2
- 230000009471 action Effects 0.000 description 2
- 239000008280 blood Substances 0.000 description 2
- 210000004369 blood Anatomy 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 238000010276 construction Methods 0.000 description 2
- 239000002826 coolant Substances 0.000 description 2
- 230000009133 cooperative interaction Effects 0.000 description 2
- 239000000446 fuel Substances 0.000 description 2
- 239000002828 fuel tank Substances 0.000 description 2
- 230000035987 intoxication Effects 0.000 description 2
- 231100000566 intoxication Toxicity 0.000 description 2
- 230000006996 mental state Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000002085 persistent effect Effects 0.000 description 2
- 230000008439 repair process Effects 0.000 description 2
- 230000001276 controlling effect Effects 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000000779 depleting effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 239000002184 metal Substances 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000001105 regulatory effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 239000000344 soap Substances 0.000 description 1
- 230000003442 weekly effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/08—Insurance
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C5/00—Registering or indicating the working of vehicles
- G07C5/02—Registering or indicating driving, working, idle, or waiting time only
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C5/00—Registering or indicating the working of vehicles
- G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C5/00—Registering or indicating the working of vehicles
- G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
- G07C5/0808—Diagnosing performance data
Definitions
- aspects of the disclosure relate to usage-based insurance systems for determining and implementing usage-based insurance policies. More specifically, aspects of the disclosure relate to determining cost per day and cost per mile based on received driving data.
- Vehicle insurance policies are generally purchased by insurance customers from various insurance providers. Conventional policies generally provide coverage to the user for a term of the policy based on payment of a premium associated with the policy. Such term based policies might not account for driving behaviors, environmental conditions, or the like. Rather, coverage may be provided for the term, regardless of how, where, when, etc. the driver operates the vehicle.
- Many vehicles include sensors and internal computer systems designed to store and monitor driving data, vehicle operation data, driving conditions, and driving functions. Many vehicles also include one or more communication systems designed to send and receive information from inside or outside the vehicle. Such information can include, for example, vehicle operational data, driving conditions, and communications from other vehicles or systems.
- aspects of the disclosure relate to methods, computer-readable media, and apparatuses for determining a cost per day and/or a cost per mile for a usage-based insurance policy. These costs may be used to determine a cost associated with a driving trip and that cost may be deducted from a balance of a premium paid by the user.
- driving data associated with the first driving trip may be collected from one or more sensors in a vehicle. This driving data may be used to revise or modify the cost per day and/or cost per mile in order to account for increased or decreased risk associated with the particular driving behaviors of the user.
- One or more subsequent driving trips may then be performed and a cost associated with each of the one or more driving trips may be determined based on the revised or modified cost per day and/or cost per mile.
- FIG. 1 illustrates computing systems and a network environment that may be used to implement aspects of the disclosure.
- FIG. 2 is an example risk unit based insurance system according to one or more aspects described herein.
- FIG. 3 is an example risk unit based insurance system environment illustrating various communications between vehicles-based devices, a personal mobile device, and an insurance system server, according to one or more aspects of the disclosure.
- FIG. 4 is a flow diagram illustrating an example method of generating a risk unit based insurance policy and implementing the risk unit based insurance policy according to one or more aspects described herein.
- FIG. 5 is an example user interface providing information to a user regarding a risk unit consumption rate according to one or more aspects described herein.
- FIG. 6 is a flow diagram illustrating an example method of providing one or more risk unit account refill options to a user, according to one or more aspects described herein.
- FIGS. 7 A- 7 D are example user interfaces that may be provided to a user to facilitate risk unit account replenishment according to one or more aspects described herein.
- FIG. 8 is a flow diagram illustrating an example method of generating suggested modifications to driving behaviors in order to improve risk unit consumption rate, according to one or more aspects described herein.
- FIG. 9 is an example user interface providing one or more recommended driving behavior modifications to a user, according to one or more aspects described herein.
- FIG. 10 is an example usage-based insurance system according to one or more aspects described herein.
- FIG. 11 is an example usage-based insurance system environment illustrating various communications between vehicle-based devices, a personal mobile device, and an insurance system server, according to one or more aspects of the disclosure.
- FIG. 12 is a flow chart illustrating an example method of determining a cost of a trip associated with a usage-based insurance policy and deducting the cost of the trip from a premium associated with the policy according to one or more aspects described herein.
- FIG. 13 is a flow chart illustrating an example method of attempting to automatically transfer funds from a payment account to a user or vehicle account according to one or more aspects described herein.
- FIG. 14 is a flow chart illustrating one example method of reducing or eliminating charges upon reaching a daily mileage threshold limit, according to one or more aspects described herein.
- FIG. 15 is a flow chart illustrating one example method of tracking trip events via a ledger in accordance with one or more aspects described herein.
- FIG. 16 is a flow chart illustrating one example method of replenishing accounts according to one or more aspects described herein.
- FIG. 17 is a flow chart illustrating one example method of creating a new account according to one or more aspects described herein.
- aspects described herein may be embodied as a method, a computer system, or a computer program product. Accordingly, those aspects may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, such aspects may take the form of a computer program product stored by one or more computer-readable storage media having computer-readable program code, or instructions, embodied in or on the storage media. Any suitable computer-readable storage media may be utilized, including hard disks, CD-ROMs, optical storage devices, magnetic storage devices, and/or any combination thereof.
- signals representing data or events as described herein may be transferred between a source and a destination in the form of electromagnetic waves traveling through signal-conducting media such as metal wires, optical fibers, and/or wireless transmission media (e.g., air and/or space).
- signal-conducting media such as metal wires, optical fibers, and/or wireless transmission media (e.g., air and/or space).
- FIG. 1 illustrates a block diagram of a computing device (or system) 101 in a computer system 100 that may be used according to one or more illustrative embodiments of the disclosure.
- the device 101 may have a processor 103 for controlling overall operation of the device 101 and its associated components, including RAM 105 , ROM 107 , input/output module 109 , and memory 115 .
- the computing device 101 along with one or more additional devices (e.g., terminals 141 and 151 , security and integration hardware 160 ) may correspond to any of multiple systems or devices described herein, such as personal mobile devices, vehicle-based computing devices, insurance systems servers, external data sources and other various devices in a risk unit based insurance system.
- These various computing systems may be configured individually or in combination, as described herein, for determining and/or providing one or more risk units to a user, maintaining an account of risk units for a user, determining a rate at which a balance in the account may be reduced (e.g., based on various driving factor, external factors, traditional insurance factors, or the like), automatically refilling a risk unit account based on the balance reaching a predetermined threshold, and the like, using the devices of the risk unit based insurance systems described herein.
- the techniques described herein also may be used for generating and presenting insurance recommendations to customers, insurance underwriting, and other insurance-related tasks.
- I/O 109 may include a microphone, keypad, touch screen, and/or stylus through which a user of the computing device 101 may provide input, and may also include one or more of a speaker for providing audio output and a video display device for providing textual, audiovisual and/or graphical output.
- Software may be stored within memory 115 and/or storage to provide instructions to processor 103 for enabling device 101 to perform various actions.
- memory 115 may store software used by the device 101 , such as an operating system 117 , application programs 119 , and an associated internal database 121 .
- the various hardware memory units in memory 115 may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Certain devices and systems within risk unit based insurance systems may have minimum hardware requirements in order to support sufficient storage capacity, processing capacity, analysis capacity, network communication, etc.
- one or more nonvolatile hardware memory units having a minimum size may be used in a device 101 (e.g., a personal mobile device 101 , vehicle-based device 101 , insurance system server 101 , etc.), in order to collect and analyze driver data, vehicle data, and/or driving trip data, determine risk unit based insurance policy parameters, determine rate at which risk units are consumed during operation of a vehicle, etc., using the various devices of the risk unit based insurance systems.
- a device 101 e.g., a personal mobile device 101 , vehicle-based device 101 , insurance system server 101 , etc.
- Memory 115 also may include one or more physical persistent memory devices and/or one or more non-persistent memory devices.
- Memory 115 may include, but is not limited to, random access memory (RAM) 105 , read only memory (ROM) 107 , electronically erasable programmable read only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by processor 103 .
- RAM random access memory
- ROM read only memory
- EEPROM electronically erasable programmable read only memory
- flash memory or other memory technology
- CD-ROM compact discs
- DVD digital versatile disks
- magnetic cassettes magnetic tape
- magnetic disk storage magnetic disk storage devices
- Processor 103 may include a single central processing unit (CPU), which may be a single-core or multi-core processor (e.g., dual-core, quad-core, etc.), or may include multiple CPUs.
- processors 103 may have various bit sizes (e.g., 16-bit, 32-bit, 64-bit, 96-bit, 128-bit, etc.) and various processor speeds (ranging from 100 MHz to 5 Ghz or faster).
- Processor(s) 103 and its associated components may allow the system 101 to execute a series of computer-readable instructions, for example, determine a risk unit balance in a risk unit account, to receive and analyze driver data, vehicle data, and/or driving trip data, determine a rate at which risk units are consumed (e.g., based on analyzed driver data, vehicle data, external data, or the like), and/or automatically refill a risk unit account balance upon determining that the balance has reached a predetermined threshold.
- the computing device may operate in a networked environment 100 supporting connections to one or more remote computers, such as terminals 141 , 151 , and 161 .
- terminals may be personal computers or servers 141 (e.g., home computers, laptops, web servers, database servers), mobile communication devices 151 (e.g., mobile phones, tablet computers, etc.), vehicle-based computing systems 161 (e.g., on-board vehicle systems, telematics devices, mobile phones or other personal mobile devices within vehicles), and the like, each of which may include some or all of the elements described above with respect to the computing device 101 .
- LAN local area network
- WAN wide area network
- wireless telecommunications network 133 a wireless telecommunications network 133
- the computing device 101 may be connected to the LAN 125 through a network interface or adapter 123 .
- the device 101 may include a modem 127 or other means for establishing communications over the WAN 129 , such as network 131 (e.g., the Internet).
- the device 101 may include one or more transceivers, digital signal processors, and additional circuitry and software for communicating with wireless computing devices 151 and 161 (e.g., mobile phones, portable customer computing devices, vehicle-based computing devices and systems, etc.) via one or more network devices 135 (e.g., base transceiver stations) in the wireless network 133 .
- wireless computing devices 151 and 161 e.g., mobile phones, portable customer computing devices, vehicle-based computing devices and systems, etc.
- network devices 135 e.g., base transceiver stations
- a security and integration layer 160 through which communications are sent and managed between the device 101 (e.g., a personal mobile device, a vehicle-based computing device, an insurance server, an intermediary server and/or external data source servers, etc.) and the remote devices ( 141 , 151 , and 161 ) and remote networks ( 125 , 129 , and 133 ).
- the security and integration layer 160 may comprise one or more separate computing devices, such as web servers, authentication servers, and/or various networking components (e.g., firewalls, routers, gateways, load balancers, etc.), having some or all of the elements described above with respect to the computing device 101 .
- a security and integration layer 160 of a server 101 may comprise a set of web application servers configured to use secure protocols and to insulate the device 101 from external devices 141 , 151 , and 161 .
- the security and integration layer 160 may correspond to a set of dedicated hardware and/or software operating at the same physical location and under the control of same entities as device 101 .
- layer 160 may correspond to one or more dedicated web servers and network hardware in a vehicle and driver information datacenter or in a cloud infrastructure supporting a cloud-based vehicle identification and vehicle and driver data retrieval and analysis.
- the security and integration layer 160 may correspond to separate hardware and software components which may be operated at a separate physical location and/or by a separate entity.
- the data transferred to and from various devices in a risk unit based insurance system 100 may include secure and sensitive data, such as confidential vehicle operation data, insurance policy data, and confidential user data from drivers and passengers in vehicles. Therefore, it may be desirable to protect transmissions of such data by using secure network protocols and encryption, and also to protect the integrity of the data when stored on the various devices within a personalized insurance system, such as personal mobile devices, vehicle-based devices, insurance servers, external data source servers, or other computing devices in the system 100 , by using the security and integration layer 160 to authenticate users and restrict access to unknown or unauthorized users.
- security and integration layer 160 may provide, for example, a file-based integration scheme or a service-based integration scheme for transmitting data between the various devices in an electronic display system 100 .
- Data may be transmitted through the security and integration layer 160 , using various network communication protocols. Secure data transmission protocols and/or encryption may be used in file transfers to protect to integrity of the data, for example, File Transfer Protocol (FTP), Secure File Transfer Protocol (SFTP), and/or Pretty Good Privacy (PGP) encryption.
- FTP File Transfer Protocol
- SFTP Secure File Transfer Protocol
- PGP Pretty Good Privacy
- one or more web services may be implemented within the various devices 101 in the system 100 and/or the security and integration layer 160 . The web services may be accessed by authorized external devices and users to support input, extraction, and manipulation of the data (e.g., vehicle data, driver data, driving trip data, etc.) between the various devices 101 in the system 100 .
- Web services built to support a personalized display system may be cross-domain and/or cross-platform, and may be built for enterprise use.
- Such web services may be developed in accordance with various web service standards, such as the Web Service Interoperability (WS-I) guidelines.
- a driver data, vehicle data, and/or driving trip data analysis web service, a risk unit based insurance policy determination or offer web service, or the like may be implemented in the security and integration layer 160 using the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocol to provide secure connections between servers 101 and various clients 141 , 151 , and 161 .
- SSL or TLS may use HTTP or HTTPS to provide authentication and confidentiality.
- such web services may be implemented using the WS-Security standard, which provides for secure SOAP messages using XML encryption.
- the security and integration layer 160 may include specialized hardware for providing secure web services.
- secure network appliances in the security and integration layer 160 may include built-in features such as hardware-accelerated SSL and HTTPS, WS-Security, and firewalls.
- Such specialized hardware may be installed and configured in the security and integration layer 160 in front of the web servers, so that any external devices may communicate directly with the specialized hardware.
- various elements within memory 115 or other components in system 100 may include one or more caches, for example, CPU caches used by the processing unit 103 , page caches used by the operating system 117 , disk caches of a hard drive, and/or database caches used to cache content from database 121 .
- the CPU cache may be used by one or more processors in the processing unit 103 to reduce memory latency and access time.
- a processor 103 may retrieve data from or write data to the CPU cache rather than reading/writing to memory 115 , which may improve the speed of these operations.
- a database cache may be created in which certain data from a database 121 (e.g., a database of driver data, driving behaviors or characteristics, passenger-related data, vehicle data, driving trip data, account balance data, etc.) is cached in a separate smaller database on an application server separate from the database server (e.g., at a personal mobile device, vehicle-based data, or intermediary network device or cache device, etc.).
- a database cache on an application server can reduce data retrieval and data manipulation time by not needing to communicate over a network with a back-end database server.
- caches and others may be included in various embodiments, and may provide potential advantages in certain implementations of risk unit based insurance systems, such as faster response times and less dependence on network conditions when transmitting and receiving driver information, vehicle information, driving trip information, insurance parameters, account balance information, and the like.
- network connections shown are illustrative and other means of establishing a communications link between the computers may be used.
- the existence of any of various network protocols such as TCP/IP, Ethernet, FTP, HTTP and the like, and of various wireless communication technologies such as GSM, CDMA, WiFi, and WiMAX, is presumed, and the various computing devices in risk unit based insurance system components described herein may be configured to communicate using any of these network protocols or technologies.
- one or more application programs 119 may be used by the various computing devices 101 within a risk unit based insurance system 100 (e.g., vehicle data, driver data, and/or driving trip data analysis software applications, insurance parameter determination software applications, risk unit account applications, etc.), including computer executable instructions for receiving and analyzing various driver data, vehicle data, and/or driving trip data, determining parameters for risk unit insurance policies, presenting risk unit based insurance policies via the devices in the risk unit based insurance system, determining a rate at which risk units are consumed during operation of a vehicle, and evaluating and/or automatically refilling a balance of a risk unit account using the devices of the risk unit based insurance systems.
- a risk unit based insurance system 100 e.g., vehicle data, driver data, and/or driving trip data analysis software applications, insurance parameter determination software applications, risk unit account applications, etc.
- FIG. 2 is a schematic diagram of an illustrative risk unit based insurance system 200 .
- the risk unit based insurance system 200 may be associated with, internal to, operated by, or the like, an entity 201 , such as an insurance provider.
- entity 201 such as an insurance provider.
- the entity may be one of various other types of entities, such as a government entity, corporation or business, university, or the like.
- Various examples described herein will be discussed in the context of an insurance provider. However, nothing in the specification should be viewed as limiting use of the systems, methods, arrangements, etc. described herein to use only by an insurance provider.
- the risk unit based insurance system 200 may include one or more modules that may include hardware and/or software configured to perform various functions within the system 200 .
- the one or more modules may be separate, physical devices or, in other examples, one or more modules may be part of the same physical device.
- the risk unit based insurance system may include a risk unit module 202 .
- the risk unit module 202 may be configured to determine a cost to insure an average user for a predetermined period of time. For instance, the risk unit module 202 may receive data, such as insurance data from insurance data store 204 , locality data from locality data store 206 , as well as other data (from data stores not shown that may be internal to the entity 201 or external to the entity 201 ), and determine, based on the received data, the cost to insure an average user over a predetermined period of time (e.g., one month, one week, one day, one year, or the like). This cost may be considered equivalent to one risk unit.
- data such as insurance data from insurance data store 204 , locality data from locality data store 206 , as well as other data (from data stores not shown that may be internal to the entity 201 or external to the entity 201 )
- the cost to insure an average user over a predetermined period of time e.g.,
- a cost to the user or insurance policy holder to purchase a risk unit may be determined by the system. This cost may be different from the cost forming the risk unit and may be determined on a fixed date. The cost to the user may then be revised at a second date (e.g., monthly, annually, etc.). Accordingly, insurance may be provided to one or more users based on risk units, as will be discussed more fully herein.
- the risk unit based insurance system 200 may further include a policy module 208 .
- the policy module 208 may generate and/or store insurance policies using risk units, as well as insurance policy information or factors, such as vehicle information, driving record/experience, policy limits, deductibles, etc. That is, a user may be insured through a policy that provides a number of risk units for a particular cost (e.g., insurance premium). The risk units may then be consumed by the user as, for example, the user drives or operates his or her vehicle.
- the risk units may be consumed based on sensor data-focused factors, such as time elapsed, driving habits of the user, environmental conditions in which the user operates the vehicle, vehicle parameters (such as year, make, model, features, specifications, etc.), condition or performance of the vehicle (e.g., based on sensor data), and the like, as well as traditional policy factors, such as driving experience, driving record, credit variables, policy coverage, deductible, policy limits, familiarity of the driver with the vehicle or surroundings, and the like.
- one policy parameter may include a level of coverage.
- risk units may be purchased at various levels with each level providing a different level of coverage, as will be discussed more fully herein. Additionally or alternatively, the consumption rate may reflect different levels of coverage.
- the insurance policies based on risk units may further include a risk unit account stored in risk unit account module 210 .
- the risk unit account module 210 may include one or more accounts associated with one or more users (e.g., users having risk unit based insurance policies), vehicles (e.g., vehicles associated with a risk unit based insurance policy), or the like.
- the accounts may include information associated with a user such as name, address, contact information, and the like, as well as information associated with the vehicle, such as vehicle identification number, make, model, year, etc. Further, the accounts may include a number of risk units associated with or available to the user or account holder, associated with the vehicle, etc.
- the user account will show, at the purchase, 100 risk units.
- a balance of risk units in the account may be reduced.
- the balance of risk units in an account may be displayed to the user via a computing device, such as one or more of computing devices 212 a - 212 f
- the risk unit account balance may be displayed via an application (e.g., online or mobile application) on a smartphone 212 a , personal digital assistant (PDA) 212 b , tablet 212 c , cell phone 212 d , or other computing device 212 e .
- the risk unit account balance may be displayed to a user on a vehicle display 212 f .
- various other account details may be displayed as desired.
- the risk unit account may include units of another type (e.g., other than risk units).
- the risk unit account may include an amount or balance of funds or money.
- the balance of funds may be reduced based on operation of the vehicle, as discussed above.
- the risk units may be converted to funds in order to facilitate this reduction of balance (e.g., the consumption rate of units based on operation of the vehicle may be determined in risk units and then converted to funds in order to reduce the balance in the account appropriately).
- the consumption rate may be determined in monetary units and the balance reduced as appropriate.
- the risk unit based insurance system 200 may further include a risk unit consumption rate module 214 .
- the risk unit consumption rate module 214 may include hardware and/or software configured to determine and/or implement a consumption rate of risk units due to operation of the vehicle (e.g., as the user operates the vehicle, the number or balance of risk units in the risk unit account is reduced based on a determined consumption rate, thereby depleting the balance associated with the policy. Once the balance of risk units reaches a predetermined threshold, the number of risk units may be replenished, akin to renewal of a conventional insurance policy). As discussed above, the consumption rate may be determined in risk units, monetary units or other units, as desired.
- the rate at which risk units are consumed by a user may be based on a variety of factors, such as personal information of the user, driving habits or behaviors of the user, environmental conditions, locality or geographic conditions, types of road being travelled, traditional policy factors, coverage, vehicle features or operation, and the like.
- Various algorithms may be used to determine the consumption rate. For example, Equation 1 is one example that may be used to determine consumption rate based on sensor data-focused factors may include:
- Equation 2 is another example that may be used to determine consumption rate based on sensor data-focused factors, as well as traditional policy factors, may include:
- Equation 1 or Equation 2 may further include an expenses factor.
- an expenses value may be added to the result of Equation 1 or Equation 2 in order to determine the consumption rate.
- Equation 1 and Equation 2 are provided as examples for determining consumption rate, various other equations and/or algorithms may be used without departing for the invention. For instance, one or more factors may be removed from the equation to determine consumption rate. Additionally or alternatively, other factors may be included in the equations, without departing from the invention.
- one or more sensors 216 may be used to obtain data that may be used to determine the consumption rate for the user.
- the one or more sensors may include sensors to detect driving behaviors of the user, such as hard braking, speeding, and the like.
- one or more sensors may be used to detect environmental conditions such as precipitation, humidity, cloud cover, or the like.
- one or more sensors may be used to determine road conditions or to obtain information from outside sources (e.g., external databases, or the like) regarding traffic conditions, types of road (e.g., two-lane road, four-lane road), speed limit of the road, or the like.
- the data from one or more sensors 216 which may include data from combinations of different types of sensors, may be used by the risk unit consumption rate module 214 to determine a risk unit consumption rate for the user.
- the traditional policy factors such as driving record, credit information, driving experience, vehicle features and/or specifications, coverages, deductibles, policy limits, etc. may be obtained from, for example, policy module 208 .
- the risk unit consumption rate may be determined or calculated for a particular trip. Additionally or alternatively, the consumption rate may be calculated or determined in real-time or near real-time, such that the rate may change as the user's driving behavior changes, as the type of road changes, as the environmental conditions change, or the like.
- the consumption rate may be higher than if the user is driving at the speed limit and/or there is no precipitation.
- This is merely one example of how consumption rate may change based on received sensor data and should not be viewed as limiting the disclosure to only this example. Rather, various other changes in received sensor data may be used to modify or alter the risk unit consumption rate for the user.
- the risk unit consumption rate may be displayed to a user, such as via one or more computing devices 212 a - 212 f
- the risk unit consumption rate module 214 may generate and/or display to a user suggestions for improving the consumption rate. For instance, the system may generate an alternate route that has been determined to be safer than the user's current route and, thus, by taking the alternate route, the consumption rate may be reduced.
- a user may be driving faster than a posted speed limit.
- the system may generate a notice to display to the user (e.g., via a computing device 212 a - 212 f ) indicating that, by slowing down, the user's consumption rate may be reduced.
- the risk unit based insurance system 200 may further include a risk unit marketplace 218 .
- the risk unit marketplace 218 may be connected to or in communication with various other modules within the system 200 .
- the risk unit marketplace may be used to refill a user's risk unit account. For instance, upon the user reaching a predetermined threshold within the risk unit account of the user (e.g., the balance of risk units within the account reaches a certain threshold) the user may be notified that the balance of risk units in the account is low and may offer one or more options for purchasing additional risk units or otherwise increasing the balance of risk units in the account.
- a notification may be displayed to the user (e.g., via one or more of computing devices 212 a - 212 f ) indicating that the balance is low and offering additional risk units for sale.
- the user may store credit card or other payment information (e.g., account information, debit card information, electronic funds transfer information, and the like) in the system (e.g., within the risk unit marketplace 218 ) such that, upon receiving the notification, the user may select a “purchase” option and a predetermined number of risk units may be purchased by the user and charged to the stored payment information.
- the user may select an automatic refill option.
- a user may input payment information (e.g., credit card information, debit card information, checking or other account information, electronic funds transfer information, and the like) and may identify a predetermined threshold below which the system may automatically purchase additional risk units.
- payment information e.g., credit card information, debit card information, checking or other account information, electronic funds transfer information, and the like.
- the risk unit marketplace 218 may also provide risk units for sale to other users or insurance providers. For instance, a user may obtain insurance through a different insurance provider but the risk units may be common units among a plurality of insurance providers. Accordingly, users having insurance policies with other providers may purchase risk units from the risk unit marketplace 218 and may have the risk units placed in an account associated with the policy provided by or associated with the other insurance provider. In some examples, entity 201 may charge a service fee or surcharge for purchase of risk units for use with a policy provided by another insurance carrier.
- FIG. 3 is a diagram of an illustrative system driving analysis system 300 including additional aspects of the risk unit based insurance system 200 shown in FIG. 2 and/or implementing the risk unit based insurance system 200 of FIG. 2 .
- the system includes a vehicle 310 , a personal mobile device 330 , an insurance system server 350 , and additional related components.
- the components of the system 300 individually or using communication and collaborative interaction, may determine, present, and implement various types of risk unit based insurance to customers, including providing or facilitating purchase of a risk unit based insurance policy and/or associated risk units, determining a consumption rate of risk units, communicating a consumption rate to a user, generating and providing suggestions to a user for reducing consumption rate, etc.
- the components shown in FIG. 3 each may be implemented in hardware, software, or a combination of the two.
- each component of the system 300 may include a computing device (or system) having some or all of the structural components described above for computing device 101 .
- Vehicle 310 in the system 300 may be, for example, an automobile, a motorcycle, a scooter, a bus, a recreational vehicle, a boat, or other vehicle for which vehicle data, location data, driver data (or operator data), operational data and/or other driving data (e.g., location data, time data, weather data, etc.) may be collected and analyzed.
- vehicle 310 includes vehicle operation sensor 311 (similar to one or more of sensors 216 a - 216 c of FIG. 2 ) capable of detecting and recording various conditions at the vehicle and operational parameters of the vehicle.
- sensor 311 may detect and store data corresponding to the vehicle's location (e.g., GPS coordinates), time, travel time, speed and direction, rates of acceleration or braking, gas mileage, and specific instances of sudden acceleration, braking, swerving, and distance traveled. Sensor 311 also may detect and store data received from the vehicle's 310 internal systems, such as impact to the body of the vehicle, air bag deployment, headlights usage, brake light operation, door opening and closing, door locking and unlocking, cruise control usage, hazard lights usage, windshield wiper usage, horn usage, turn signal usage, seat belt usage, phone and radio usage within the vehicle, autonomous driving system usage, maintenance performed on the vehicle, and other data collected by the vehicle's computer systems, including the vehicle on-board diagnostic systems (OBD).
- OBD vehicle on-board diagnostic systems
- Additional sensors 311 may detect and store the external driving conditions, for example, external temperature, rain, snow, light levels, and sun position for driver visibility.
- external cameras and proximity sensors 311 may detect other nearby vehicles, vehicle spacing, traffic levels, road conditions, traffic obstructions, animals, cyclists, pedestrians, and other conditions that may factor into a driving data/behavior analysis.
- Sensor 311 also may detect and store data relating to moving violations and the observance of traffic signals and signs by the vehicle 310 .
- Additional sensors 311 may detect and store data relating to the maintenance of the vehicle 310 , such as the engine status, oil level, engine coolant temperature, odometer reading, the level of fuel in the fuel tank, engine revolutions per minute (RPMs), software upgrades, and/or tire pressure.
- RPMs revolutions per minute
- Vehicles sensor 311 also may include cameras and/or proximity sensors capable of recording additional conditions inside or outside of the vehicle 310 .
- internal cameras may detect conditions such as the number of the passengers and the types of passengers (e.g. adults, children, teenagers, pets, etc.) in the vehicles, and potential sources of driver distraction within the vehicle (e.g., pets, phone usage, and unsecured objects in the vehicle).
- Sensor 311 also may be configured to collect data identifying a current driver from among a number of different possible drivers, for example, based on driver's seat and mirror positioning, driving times and routes, radio usage, etc. Voice/sound data along with directional data also may be used to determine a seating position within a vehicle 310 .
- Sensor 311 also may be configured to collect data relating to a driver's movements or the condition of a driver.
- vehicle 310 may include sensors that monitor a driver's movements, such as the driver's eye position and/or head position, etc. Additional sensors 311 may collect data regarding the physical or mental state of the driver, such as fatigue or intoxication.
- the condition of the driver may be determined through the movements of the driver or through other sensors, for example, sensors that detect the content of alcohol in the air or blood alcohol content of the driver, such as a breathalyzer, along with other biometric sensors.
- Certain vehicle sensors 311 also may collect information regarding the driver's route choice, whether the driver follows a given route, and to classify the type of trip (e.g. commute, errand, new route, etc.) and type of driving (e.g., continuous driving, parking, stop-and-go traffic, etc.). In certain embodiments, sensors and/or cameras 311 may determine when and how often the vehicle 310 stays in a single lane or strays into other lane.
- a Global Positioning System (GPS) locational sensors positioned inside the vehicle 310 , and/or locational sensors or devices external to the vehicle 310 may be used to determine the route, speed, lane position, road-type (e.g. highway, entrance/exit ramp, residential area, etc.) and other vehicle position/location data.
- GPS Global Positioning System
- locational sensors positioned inside the vehicle 310 and/or locational sensors or devices external to the vehicle 310 may be used to determine the route, speed, lane position, road-type (e.g. highway, entrance
- the data collected by vehicle sensor 311 may be stored and/or analyzed within the vehicle 310 , such as for example a driving analysis computer 314 integrated into the vehicle, and/or may be transmitted to one or more external devices.
- sensor data may be transmitted via a telematics device 313 to one or more remote computing devices, such as personal mobile device 330 , insurance system server 350 , and/or other remote devices.
- Telematics device 313 may be one or more computing devices containing many or all of the hardware/software components as the computing device 101 depicted in FIG. 1 . As discussed above, the telematics device 313 may receive vehicle operation data and driving data from vehicle sensor 311 , and may transmit the data to one or more external computer systems (e.g., insurance system server 350 of an insurance company, financial institution, or other entity) over a wireless transmission network.
- external computer systems e.g., insurance system server 350 of an insurance company, financial institution, or other entity
- Telematics device 313 also may be configured to detect or determine additional types of data relating to real-time driving and the condition of the vehicle 310 .
- the telematics device 313 also may store the type of vehicle 310 , for example, the make, model, trim (or sub-model), year, and/or engine specifications, as well as other information such as vehicle owner or driver information, insurance information, and financing information for the vehicle 310 .
- telematics device 313 may receive vehicle driving data from vehicle sensor 311 , and may transmit the data to an insurance system server 350 .
- vehicle sensors 311 or systems may be configured to receive and transmit data directly from or to an insurance system server 350 without using a telematics device.
- telematics device 313 may be configured to receive and transmit data from certain vehicle sensors 311 or systems, while other sensors or systems may be configured to directly receive and/or transmit data to an insurance system server 350 without using the telematics device 313 .
- telematics device 313 may be optional in certain embodiments.
- the system 300 in FIG. 3 also includes a mobile device 330 .
- Mobile devices 330 may be, for example, smartphones or other mobile phones, personal digital assistants (PDAs), tablet computers, and the like, and may include some or all of the elements described above with respect to the computing device 101 .
- some mobile devices in systems 300 e.g., mobile device 330
- the mobile device 330 might not connect to vehicle-based computing devices and internal components, but may operate independently by communicating with vehicle 310 via their standard communication interfaces (e.g., telematics device 313 , etc.), or might not connect at all to vehicle 310 .
- Mobile device 330 may include a network interface 321 , which may include various network interface hardware (e.g., adapters, modems, wireless transceivers, etc.) and software components to enable mobile device 330 to communicate with insurance system server 350 , vehicle 310 , and various other external computing devices.
- network interface 321 may include various network interface hardware (e.g., adapters, modems, wireless transceivers, etc.) and software components to enable mobile device 330 to communicate with insurance system server 350 , vehicle 310 , and various other external computing devices.
- One or more specialized software applications, such as a driving analysis application 334 and/or a risk unit based insurance application 335 may be stored in the memory of the mobile device 330 .
- the driving analysis application 334 and risk unit based insurance application 335 may be received via network interface 321 from the insurance server 350 , vehicle 310 , or other application providers (e.g., application stores).
- the driving analysis application 334 and risk unit based insurance application 335 may or may not include various user interface screens, and may be configured to run as user-initiated applications or as background applications.
- the memory of the mobile device 330 also may include databases configured to receive and store vehicle data, driving data, driving trip data, and the like, associated with one or more drivers and/or vehicles.
- mobile device 330 may include various components configured to generate and/or receive vehicle data, driver data, and driving data or other operational data. For example, using data from the GPS receiver 333 , a driving analysis software application 334 may be able to identify starting and stopping points of driving trips, determine driving speeds, times, routes, and the like. Additional components of mobile device 330 may be used to generate or receive driving data for the driving data analysis application 334 and/or risk unit based insurance application 335 , such as an accelerometer, compass, and various cameras and proximity sensors.
- driving data analysis application 334 may be able to identify starting and stopping points of driving trips, determine driving speeds, times, routes, and the like.
- Additional components of mobile device 330 may be used to generate or receive driving data for the driving data analysis application 334 and/or risk unit based insurance application 335 , such as an accelerometer, compass, and various cameras and proximity sensors.
- these and other mobile device components may be used to receive, store, and output various user/driver data, to identify starting and stopping points and other characteristics of driving trips, to determine various driving data such as speeds, driving routes and times, acceleration, braking, and turning data, and other driving conditions and behaviors.
- the driving analysis software application 334 may store and analyze the data from various mobile device components, and the risk unit based insurance application 335 may use this data, alone or in any combination with other components or devices (e.g., insurance server 350 ), to determine and present insurance offers, insurance costs, and the like.
- mobile computing devices within vehicles When mobile computing devices within vehicles are used to detect vehicle driving data and/or to receive vehicle driving data from vehicle sensors, such mobile computing devices 330 may store, analyze, and/or transmit the vehicle driver data (e.g., data identifying a current driver), driving data (e.g., speed data, acceleration, braking, and turning data, and any other vehicle sensor or operational data), and driving trip data (e.g., driving route, driving times, driving destinations, etc.), to one or more other devices.
- vehicle driver data e.g., data identifying a current driver
- driving data e.g., speed data, acceleration, braking, and turning data, and any other vehicle sensor or operational data
- driving trip data e.g., driving route, driving times, driving destinations, etc.
- mobile computing device 330 may transmit driver data, driving data and driving behaviors, and driving trip data directly to one or more insurance servers 350 , and thus may be used in conjunction with or instead of telematics devices 313 .
- the processing components of the mobile computing device 330 may be used to identify vehicle drivers and passengers, analyze vehicle driving data, analyze driving trips, determine parameters related to aspects of risk unit based insurance policies, and perform other related functions. Therefore, in certain embodiments, mobile computing device 330 may be used in conjunction with, or in place of, the insurance system server 350 .
- Vehicle 310 may include driving analysis computer 314 , which may be separate computing devices or may be integrated into one or more other components within the vehicle 310 , such as the telematics device 313 , autonomous driving systems, or the internal computing systems of vehicle 310 .
- driving analysis computers 314 also may be implemented by computing devices independent from the vehicle 310 , such as mobile computing device 330 of the drivers or passengers, or one or more separate computer systems (e.g., a user's home or office computer).
- the driving analysis computer 314 may contain some or all of the hardware/software components as the computing device 101 depicted in FIG. 1 .
- the functionality of the driving analysis computers may be performed in a central insurance system server 350 rather than by the individual vehicle 310 or personal mobile device 330 .
- the vehicle 310 and and/or mobile device 330 might only collect and transmit driver data, vehicle data, driving data, and the like to an insurance server 350 , and thus the vehicle-based driving analysis computer 314 may be optional.
- the system 300 also may include one or more insurance system servers 350 , containing some or all of the hardware/software components as the computing device 101 depicted in FIG. 1 .
- the insurance system server 350 may include hardware, software, and network components to receive driver data, vehicle data, and vehicle operational data/driving data from one or more vehicles 310 , mobile devices 330 , and other data sources.
- the insurance system server 350 may include an insurance database 352 and risk unit based insurance system 351 to respectively store and analyze driver data, vehicle data, and driving data, etc., received from vehicle 310 , mobile device 330 , and other data sources.
- the risk unit based insurance system 351 may include many or all of the components of risk unit based insurance system 200 described with respect to FIG. 2 .
- the insurance system server 350 may initiate communication with and/or retrieve driver data, vehicle data, and driving data from vehicle 310 wirelessly via telematics device 313 , mobile device 330 , or by way of separate computing systems over one or more computer networks (e.g., the Internet).
- the insurance system server 350 may receive additional data from other third-party data sources, such as external traffic databases containing traffic data (e.g., amounts of traffic, average driving speed, traffic speed distribution, and numbers and types of accidents, etc.) at various times and locations, external weather databases containing weather data (e.g., rain, snow, sleet, and hail amounts, temperatures, wind, road conditions, visibility, etc.) at various times and locations, and other external data sources containing driving hazard data (e.g., road hazards, traffic accidents, downed trees, power outages, road construction zones, school zones, and natural disasters, etc.), route and navigation information, and insurance company databases containing insurance data (e.g., driver score, coverage amount, deductible amount, premium amount, insured status) for the vehicle, driver, and/or other nearby vehicles and drivers.
- traffic data e.g., amounts of traffic, average driving speed, traffic speed distribution, and numbers and types of accidents, etc.
- weather databases e.g., rain, snow, sleet,
- Data stored in the insurance database 352 may be organized in any of several different manners.
- a driver table in database 352 may contain all of the driver data for drivers associated with the insurance provider (e.g., driver personal information, insurance account information, demographic information, accident histories, risk factors, driving scores and driving logs, etc.)
- a vehicle table may contain all of the vehicle data for vehicles associated with the insurance provider (e.g., vehicle identifiers, makes, models, years, accident histories, maintenance histories, travel logs, estimated repair costs and overall values, etc.)
- a driving trip table may store all of the driving trip data for drivers and vehicles associated with the insurance provider (e.g., driving trip driver, vehicle driven, trip time, starting and ending points, route driven, etc.).
- Other tables in the database 352 may store additional data, including data types discussed above (e.g. traffic information, road-type and road condition information, weather data, insurance policy data, etc.). Additionally, one or more other databases of other insurance providers containing additional driver data and vehicle data may be accessed to retrieve such additional data.
- data types discussed above e.g. traffic information, road-type and road condition information, weather data, insurance policy data, etc.
- one or more other databases of other insurance providers containing additional driver data and vehicle data may be accessed to retrieve such additional data.
- the risk unit based insurance system 351 within the insurance system server 350 may be configured to retrieve data from the database 352 , or may receive driver data, vehicle data, and driving trip directly from vehicle 310 , mobile device 330 , or other data sources, and may perform driving data analyses, determine insurance parameters for risk unit based insurance policies, and other related functions.
- the functions performed by the risk unit based insurance analysis system 351 may be performed by specialized hardware and/or software separate from the additional functionality of the insurance system server 350 .
- Such functions may be similar to those of driving analysis module 314 of vehicle 310 , and the driving analysis and risk unit based insurance applications 334 and 335 of mobile device 330 , and further descriptions and examples of the algorithms, functions, and analyses that may be executed by the risk unit based insurance system 351 are described below, including in reference to FIGS. 4 - 9 .
- the driving data and driving trip analyses and/or risk unit based insurance determinations may be performed entirely in the insurance system server 350 , may be performed entirely in the vehicle-based driving analysis computing module 314 , or may be performed entirely in the driving analysis and risk unit based insurance applications 334 and 335 of mobile device 330 .
- certain analyses of driver data, vehicle data, and driving trip data, and certain risk unit based insurance determinations may be performed by vehicle-based devices (e.g., within driving analysis module 314 ) or mobile device 330 (e.g., within applications 334 and 335 ), while other data analyses and risk unit based insurance determinations are performed by the risk unit based insurance system 351 at the insurance system server 350 .
- a vehicle-based driving analysis computer 314 may continuously receive and analyze driver data, vehicle data, driving trip data, and the like to determine certain events and characteristics (e.g., commencement of a driving trip, identification of a driver, determination of a driving route or intended destination, driving data and behaviors during driving trips, etc.), so that large amounts of data need not be transmitted to the insurance system server 350 .
- certain events and characteristics e.g., commencement of a driving trip, identification of a driver, determination of a driving route or intended destination, driving data and behaviors during driving trips, etc.
- corresponding information may be transmitted to the insurance server 350 to perform insurance offer and cost determinations, determine consumption rate of risk units, generate one or more recommendations for reducing consumption rate, etc. which may be transmitted back to the vehicle-based device and/or personal mobile devices.
- FIG. 4 is a flow chart illustrating one example method of providing risk unit based insurance to a user, according to one or more aspects described herein.
- a risk unit is determined.
- the risk unit may be a common insurance unit that represents a cost to insure an average user for a predetermined period of time. For instance, the risk unit may be determined to be the cost to insure an average user for one week, one month, one year, etc.
- the risk unit may be used to provide insurance such that users may obtain risk unit based insurance policies in which, as the user, for example, operates a vehicle, the number of risk units in a risk unit account account is reduced based on a consumption rate determined for the user, trip, etc.
- a request is received to obtain a risk unit based insurance policy.
- the request may be received from a user and may be received, in some examples, via a computing device (e.g., mobile device, or the like).
- the request may include information associated with the user, such as name, contact information, vehicle information including make, model, year, vehicle identification number, and the like.
- the request to obtain the risk unit based insurance policy may include a level of coverage. For instance, similar to conventional insurance policies, a user may select from different levels of protection (e.g., whether to include collision coverage, amount of coverage for personal property, and the like). Similarly, a user may select a level of risk unit on which the policy is based.
- three levels may be used with the highest level of risk unit providing the most coverage and, in some instances, having the highest cost (e.g., cost per risk unit) to the user.
- a second level would provide lower coverage at a lower cost and the third level may provide a lowest level of coverage at a lowest cost.
- different levels of coverage selected may be reflected in the consumption rate of the units. For instance, the consumption rate may vary based on a level of coverage selected. Although different levels of coverage may be available to a user, the levels offered may meet minimum standards for insurance coverage, such as those required by the state in which the user lives, or the like.
- a risk unit based insurance policy is generated for the user and a risk unit account is created for the user.
- the risk unit account may be associated with the user or the vehicle. That is, the risk unit based insurance policy may provide coverage for the vehicle, regardless of which user is operating the vehicle, or may provide coverage to any vehicle being operated by a particular user.
- the user or operator of a vehicle may be identified (e.g., upon initiation of vehicle operation) in order to determine whether or what type of coverage to provide.
- a predetermined number of risk units is deposited into the account created.
- the predetermined number or risk units may be based on one or more policy parameters (e.g., term or length of policy), and/or one or more user preferences.
- step 408 data associated with the driving behaviors of the user and/or environmental conditions in which the vehicle is operating are received.
- the data may be received from one or more sensors associated with the vehicle, as well as various other sources, such as traffic, weather, road condition, etc. sources.
- received data may include speed, braking habits of the user or operator, type of road(s) being travelled, time of day, level of traffic, precipitation, and the like.
- a consumption rate of risk units in the risk unit account may be determined in step 410 .
- the consumption rate may be higher based on various behaviors and/or conditions that are determined to include more risk to the user, vehicle, etc. For instance, if a user is driving at a rate of speed above the speed limit, the consumption rate may be higher than if the user was operating at a speed closer to the speed limit. In another example, the consumption rate may be determined to be lower if the user travels outside of rush hour, rather than during peak travel times. In still another example, the consumption rate may increase if data is received that it is raining or snowing on the route which the vehicle is travelling.
- consumption rate may also be based, at least in part, on traditional policy factors, such as driving experience, driving record, credit factors, coverages, deductibles, and the like.
- Data related to various behaviors and conditions and/or traditional policy data may be combined to determine the consumption level in real-time or near real-time, as the user is operating the vehicle.
- the system may provide information associated with the consumption rate to the user.
- the vehicle display or mobile device of the user may display the current consumption rate.
- the display may include historical information associated with consumption rate for previous trips and/or a graphical display of previous and/or current consumption rates.
- FIG. 5 illustrates one example user interface 500 that may be provide to a user (e.g., via a vehicle display, mobile device, or other computing device) to provide information associated with the consumption rate.
- the interface 500 includes fields 502 and 504 in which the vehicle and operator of the vehicle are identified, respectively.
- Field 506 indicates a date and time of the current trip. In some examples, an elapsed time of the current trip may also be displayed.
- Field 508 indicates that data is being received. As discussed herein, data associated with one or more sensors detecting driving behaviors of the user, environmental conditions, and the like, may be received by the system and used to determine a current consumption rate. Field 508 provides an indication that data is currently being received. In the event of a communication disruption, field 508 may indicate that data is not being received or that an error has occurred. In some example situations of that nature, the system may apply the most recently determined consumption rate until data communication is restored and more current data is received by the system.
- Field 510 provides the current calculated or determined consumption rate. As described herein, the consumption rate may be based on a variety of factors that may include driving behaviors, environmental conditions, and the like, as determined based on data received by the system. Field 512 provides a listing of historical consumption rate information that may be useful to the user in tracking consumption rate.
- a balance of risk units in the risk unit account is reduced based on the consumption rate determined in step 410 .
- the account may include a predetermined threshold below which the user may be notified that the balance of risk units is low or in need of replenishment.
- a determination is made as to whether a balance of risk units in the risk unit account is below a predetermined threshold.
- the predetermined threshold may be based on one or more policy parameters, may meet a government or other regulatory body standards, or may be determined by the user or insurance provider.
- the threshold may be a percentage of a number of risk units obtained with the policy (e.g., a percentage of the full account balance). For instance, the threshold may be 10%, 15% or any other percentage of the full number of risk units obtained with the policy. In other examples, the threshold may be a number of risk units. For instance, the threshold may be 50, 100, or any other number of risk units.
- step 414 the process may return to step 408 to continue receiving data and determining consumption rate. If, in step 414 , the balance is below the predetermined threshold, one or more refill options may be provided to the user in step 416 .
- Refill options may include providing a notification to the user of the current balance and/or providing options for automatic refill, user requested refill, cancellation of policy, purchase of a new policy and associated risk units, and the like. Once the refill options are presented, the system may return to step 408 to continue receiving data, etc.
- FIG. 6 illustrates an example method of refilling risk units according to one or more aspects described herein.
- step 600 similar to step 414 in FIG. 4 , a determination is made as to whether a balance of risk units in a risk unit account is below a predetermined threshold. If not, the system may return to processes in which data is received, consumption rate is determined, etc., such as step 408 in FIG. 4 . If, in step 600 , the balance is below the threshold, a notification is transmitted to the user in step 602 .
- the notification may include an indication that the risk unit account is below the threshold and/or may provide instructions for refill of the account.
- the pre-stored payment information e.g. credit card information, account information, debit card information, etc.
- step 608 the user may respond to the notification transmitted in step 602 with a request to refill the account balance.
- the request may include a number of units to purchase, payment information, risk unit account information, policy information, and the like.
- the designated number of risk units may be purchased and deposited in the risk unit account.
- FIGS. 7 A- 7 D illustrate example user interfaces 700 a - 700 d that may be used to carry out refill or replenishment of risk units in a risk unit account.
- interfaces 700 a - 700 d are shown in FIGS. 7 A- 7 D as being displayed on a mobile device, the interfaces provided may be displayed on various different types of computing devices, including, for instance, a vehicle display, laptop or desktop computing device, tablet computing device, and the like.
- FIG. 7 A illustrates interface 700 a in which a notification is provided to the user.
- the notification 700 a indicates that the risk unit account is below the minimum threshold and provides options for the user to proceed with refilling the account balance now or requesting that the system remind the user later. Selection of the option to remind the user later may automatically prompt the notification to be displayed again at a predetermined time (e.g., each day, each hour, 48 hours from selection of remind me later option, etc.) or upon any continued consumption of the risk units. Accordingly, as the balance in the risk unit account continues to be reduced, additional notifications may be provided to the user.
- determination of the balance being below a predetermined level may result in various actions being taken with respect to the vehicle. For instance, the system may cause the headlights to flash or horn to blare while driving, may prevent the vehicle from starting if there is an insufficient number of risk units in the account, or the like.
- interface 700 b shown in FIG. 7 B may be displayed in which the user may input one or more risk unit account details, such as an account number and/or name associated with the account. In some examples, this information may automatically be prefilled based on the mobile device being associated with the user, vehicle, and/or account.
- the user may select continue option to prompt display of interface 700 c in FIG. 7 C , or similar interface, which provides fields in which the user may enter payment information.
- Information such as a credit card number, expiration date, name on the card, and the like, may be provided by the user.
- credit card information is provided as example payment information in FIG. 7 C , various other payment types may be used, such as electronic funds transfer, debit card, pre-paid debit or credit card, gift card, or the like.
- interface 700 d in FIG. 7 D may be provided to the user.
- Interface 700 d includes a field in which the user may indicate a number of risk units to purchase.
- the risk units may be a predetermined number of units based on one or more policy parameters.
- the number of units available for purchase may be determined by the user and input into interface 700 d.
- User interface 700 d further includes an option to select automatic refill. Indication of “yes” to automatic refill prompts the system to store the payment information provided in interface 700 c and, upon the system determining that the balance of risk units is below the predetermined threshold (e.g., step 414 in FIG. 4 , step 600 in FIG. 6 ) the system may automatically purchase the predetermined number of risk units, charge the associated cost to the pre-stored payment information, and deposit the purchased risk units in the risk unit account, thereby effectively automatically renewing insurance for the user.
- the predetermined threshold e.g., step 414 in FIG. 4 , step 600 in FIG. 6
- FIG. 8 illustrates one example method of determining proposed recommendations for reducing risk unit consumption rate according to one or more aspects described herein.
- step 800 data associated with driving behaviors of the user and/or environmental conditions may be received. As discussed above, data may include speed, braking habits, level of precipitation, road conditions, time of day, traffic level, and the like. Based on the received data, a risk unit consumption rate may be determined in step 802 . In some examples, the risk unit consumption rate may also be based on one or more factors associated with the user. For instance, accident history, length of time as licensed driver, credit rating, policy limits, policy deductibles, vehicle features, and the like, may, in some examples, be used in determining a risk unit consumption rate.
- one or more driving behavior or environmental condition modifications may be identified that may aid in reducing the risk unit consumption rate. For instance, if a user is driving on a road that is known as being in poor condition (e.g., potholes, poor lane markings, etc.), the system may indicate that, by changing the route to the destination, the user may reduce his or her consumption rate.
- a recommended modification identified to aid in reducing risk unit consumption rate may include modifications to more traditional policy factors, such as policy coverage, deductibles and/or limits, vehicle operation and/or maintenance, vehicle features, and the like.
- the modifications to reduce consumption rate may be identified by comparing received data with a database storing known conditions, behaviors, roads, environmental factors, and the like, that are associated with a reduced consumption rate.
- the database may store information such as historical travel information, accident history information, accident probability information, etc. that may be collected based on insurance data received by the insurance provider. For instance, the data associated with current speed may be compared to a posted speed limit for the current road (as stored in the database or received from an outside source) and, if the current speed is higher than the posted speed limit, a modification to slow the speed of the vehicle in order to reduce consumption rate may be identified.
- the received data may indicate that the current road is congested or is experiencing heavy traffic.
- the system may compare the current traffic information to levels of traffic that would result in a reduced consumption rate and may recommend modifying the route being travelled.
- the suggested modification may include a suggested alternate route.
- the identified modifications may be display to the user.
- a computing device such as a mobile device, vehicle display, or the like.
- FIG. 9 illustrates one example user interface 900 displaying recommended modifications for reducing consumption rate according to one or more aspects described herein.
- the interface includes region 902 in which the current risk unit consumption is provided to the user.
- the interface 900 further includes region 904 in which one or more suggested driving modifications are provided to the user.
- the risk unit consumption rate may change and the revised consumption rate may then be displayed.
- audio may accompany the notification.
- the notification may include an audio portion in which the text of the notification is stated to the user, thereby reducing the user's need to read the notification.
- the risk unit based insurance policies described herein may include other types of usage-based insurance policies.
- one or more usage-based insurance policies may include one or more of the aspects or features discussed above with respect to the risk unit based insurance policies.
- Usage-based policies may include a premium paid by a user. As the user operates a vehicle, the amount of the premium is reduced by a cost associated with operation of the vehicle. The cost may be based on a variety of factors, including duration of travel, distance of travel, driving behaviors, environmental conditions, and the like, as will be discussed more fully herein.
- FIG. 10 is a schematic diagram of another illustrative usage-based insurance system 1000 .
- the system 1000 shown in FIG. 10 may be similar to the system 200 shown in FIG. 2 and, although not shown in FIG. 10 , may include some or all of the components described above with respect to FIG. 2 in addition to (or in lieu of) some or all of the components shown in FIG. 10 .
- the usage-based insurance system 1000 may be associated with, internal to, operated by, or the like, an entity 1001 , such as an insurance provider.
- entity 1001 such as an insurance provider.
- the entity may be one of various other types of entities, such as a government entity, corporation or business, university, or the like.
- entities such as a government entity, corporation or business, university, or the like.
- Various examples described herein will be discussed in the context of an insurance provider. However, nothing in the specification should be viewed as limiting use of the systems, methods, arrangements, etc. described herein to use only by an insurance provider.
- the usage-based insurance system 1000 may include one or more modules that may include hardware and/or software configured to perform various functions within the system 1000 .
- the one or more modules may be separate, physical devices or, in other examples, one or more modules may be part of the same physical device.
- the system 1000 may include various modules similar to those discussed above with respect to system 200 in FIG. 2 (even if not shown in FIG. 10 ) in addition to those modules shown in FIG. 10 .
- the system 1000 may include a usage cost module 1002 configured to determine a cost or amount of funds to charge a driver (or a vehicle) for operation.
- the usage cost module 1002 may include hardware and/or software configured to perform various functions, including receiving insurance policy information, such as from policy module 1004 .
- the policy module 1004 may include information such as insurance data from insurance data store 1006 , locality or environmental/contextual data from locality data store 1008 , as well as other data (from data stores not shown that may be internal to the entity 1001 or external to the entity 1001 ).
- the policy module 1004 may transmit this information to the usage cost module 1002 and the usage cost module 1002 may determine, based on the received data, the cost for a particular driver to operate a vehicle or for a particular vehicle to operate. That is, the usage cost module 1002 may determine a cost per day and/or a cost per mile for the user and/or the vehicle. This information may be based on various factors, including driving history, vehicle specifications, historical driving data (if available), and the like.
- a driver with a new policy may receive usage cost information determined based on accident history and vehicle specifications. This information may be used to determine a cost per day and/or per mile for the driver and/or the vehicle. This cost per day and/or cost per mile may be used to determine a cost for one or more driving trips performed by the user. However, in some arrangements, these costs may be used until additional information has been collected for the driver and/or the vehicle. For instance, sensors 1010 a - 1010 c may be used to collect vehicle information. Similar to sensors 216 a - 216 c , sensors 1010 a - 1010 c may be used to obtain data that may be used to determine a revised cost per day and/or cost per mile for the user and/or the vehicle.
- the one or more sensors 1010 a - 1010 c may include sensors to detect driving behaviors of the user, such as hard braking, speeding, and the like.
- one or more sensors may be used to detect environmental conditions such as precipitation, humidity, cloud cover, or the like.
- one or more sensors may be used to determine road conditions or to obtain information from outside sources (e.g., external databases, or the like) regarding traffic conditions, types of road (e.g., two-lane road, four-lane road), speed limit of the road, or the like.
- the data from one or more sensors 1010 a - 1010 c which may include data from combinations of different types of sensors and may be used by the usage cost module 214 to determine a revised cost per day and/or cost per mile for the user.
- the usage-based insurance system 1000 may further include a policy module 1004 .
- the policy module 1004 may generate and/or store insurance policies and policy information, as well as insurance policy factors, such as vehicle information, driving record/experience, policy limits, deductibles, etc. That is, a user may be insured through a policy that provides, for a period of time, coverage for a vehicle.
- the policy may be a usage-based policy (e.g., rather than a traditional policy) in which the user may pay a premium at the start of the policy period.
- the premium may be held in an account associated with the user and/or the vehicle in, for instance, account module 1012 .
- the account module may store the pre-paid premium and, as the user operates the vehicle, the premium held in the account may be reduced by an amount associated with a cost of a trip (e.g., based on the determined cost per day and/or cost per mile). Reducing the premium may include transferring funds from the account of the user in the account module 1012 (which may be an account held by the entity 1001 ) to another account (e.g., an account of the entity 1001 ). In some examples, the funds may be transferred from the account in the account module 1012 to the second account of the entity as each trip occurs, at the end of each day, or the like. In other examples, the trip cost may be stored for each trip and the funds may be transferred in a batch process (e.g., weekly, monthly, or the like the funds may be deducted from the premium or remaining balance of the premium.
- a batch process e.g., weekly, monthly, or the like the funds may be deducted from the premium or remaining balance of the premium.
- the account module 1012 may further include hardware and/or software configured to determine when a balance (e.g., premium balance) meets a predetermined threshold level. For instance, as the user operates the vehicle, the balance of the premium may be reduced on a per trip basis, daily, in a batch process, or the like (as discussed above).
- the system may identify a minimum threshold balance of the premium for the account. Once the account in the account module 1012 reaches the minimum threshold balance, the system may notify the user. Notification to the user may be performed in various ways discussed herein.
- notification to the user may include modifying operation of the vehicle in order to provide an indication. That is, the system 1000 may transmit a signal to the vehicle to modify operation of the vehicle as a notification to the user. Modifying operation of the vehicle may include causing the headlights to flash, causing the horn to beep, and/or preventing the vehicle from starting or operating.
- the account module 1012 may attempt to automatically replenish a balance in the account. That is, the system 1000 may store payment account information for the user.
- the payment account information may include a credit card, bank account (e.g., checking account, savings account, etc.), or various other types of payment accounts.
- the payment account information may be stored in, for instance, the insurance database 1006 , policy module 1004 , or the like.
- the account module 1012 may attempt to enact an automatic transfer of funds (e.g., electronic transfer of funds) from the payment account to the account in the account module 1012 . If successful, the account may be replenished and the coverage may remain in effect. If the attempt is not successful, the system may notify the user, make another attempt after a predetermined time has elapsed, or the like. In some examples, if one or more attempts to replenish the account are unsuccessful, the policy may be cancelled.
- various types of information may be displayed to the user via one or more computing devices, such as devices 1014 a - 1014 f
- a remaining balance of a premium may be displayed to the user via one or more user interfaces (similar to arrangements discussed above) generated by and/or provided via an application (e.g., an application downloaded or otherwise provided on the device 1014 a - 1014 f ).
- the devices may include smartphone 1014 a , personal digital assistant (PDA) 1014 b , tablet 1014 c , cell phone 1014 d , or other computing device 1014 e .
- the information may be displayed to a user on a vehicle display 1014 f.
- FIG. 11 is a diagram of an illustrative driving analysis system 1100 including additional aspects of the usage-based insurance system 1000 shown in FIG. 10 and/or implementing the usage-based insurance system 1000 of FIG. 10 .
- the system 1100 shown in FIG. 11 may include one or more devices, components, or the like, similar to the system 300 shown in FIG. 3 , as well as (e.g., in addition to or in lieu of) the devices, components, and arrangements shown in FIG. 11 , without departing from the invention.
- the system includes a vehicle 1110 , a personal mobile device 1130 , an insurance system server 1150 , and additional related components.
- the components of the system 1100 may determine, present, and implement various types of usage-based insurance to customers, including providing or facilitating purchase of a usage-based insurance policy and/or associated premiums and premium payments, determining various costs associated with the usage-based insurance policy (e.g., cost per day, cost per mile, etc.), analyzing driving data to modify costs associated with the usage-based insurance policy, communicating various information to the user (e.g., trip data, historical trends, and the like), etc.
- the components shown in FIG. 11 each may be implemented in hardware, software, or a combination of the two.
- each component of the system 1100 may include a computing device (or system) having some or all of the structural components described above for computing device 101 .
- vehicle 1110 in the system 1100 may be, for example, an automobile, a motorcycle, a scooter, a bus, a recreational vehicle, a boat, or other vehicle for which vehicle data, location data, driver data (or operator data), operational data and/or other driving data (e.g., location data, time data, weather data, etc.) may be collected and analyzed.
- vehicle 1110 includes vehicle operation sensor 1111 (similar to one or more of sensors 1010 a - 1010 c of FIG. 10 ) capable of detecting and recording various conditions at the vehicle and operational parameters of the vehicle.
- sensor 1111 may detect and store data corresponding to the vehicle's location (e.g., GPS coordinates), time, travel time, speed and direction, rates of acceleration or braking (e.g., hard braking), gas mileage, and specific instances of sudden acceleration, braking, swerving, and distance traveled.
- location e.g., GPS coordinates
- time e.g., travel time, speed and direction
- rates of acceleration or braking e.g., hard braking
- gas mileage e.g., gas mileage
- Sensor 1111 also may detect and store data received from the vehicle's 1110 internal systems, such as impact to the body of the vehicle, air bag deployment, headlights usage, brake light operation, door opening and closing, door locking and unlocking, cruise control usage, hazard lights usage, windshield wiper usage, horn usage, turn signal usage, seat belt usage, phone and radio usage within the vehicle, autonomous driving system usage, maintenance performed on the vehicle, and other data collected by the vehicle's computer systems (e.g., 1117 ), including the vehicle on-board diagnostic systems (OBD).
- OBD vehicle on-board diagnostic systems
- Additional sensors 1111 may detect and store the external driving conditions, for example, external temperature, rain, snow, light levels, and sun position for driver visibility.
- external cameras and proximity sensors 1111 may detect other nearby vehicles, vehicle spacing, traffic levels, road conditions, traffic obstructions, animals, cyclists, pedestrians, and other conditions that may factor into a driving data/behavior analysis.
- Sensor 1111 also may detect and store data relating to moving violations and the observance of traffic signals and signs by the vehicle 1110 .
- Additional sensors 1111 may detect and store data relating to the maintenance of the vehicle 1110 , such as the engine status, oil level, engine coolant temperature, odometer reading, the level of fuel in the fuel tank, engine revolutions per minute (RPMs), software upgrades, and/or tire pressure.
- RPMs revolutions per minute
- Vehicles sensor 1111 also may include cameras and/or proximity sensors capable of recording additional conditions inside or outside of the vehicle 1110 .
- internal cameras may detect conditions such as the number of the passengers and the types of passengers (e.g. adults, children, teenagers, pets, etc.) in the vehicles, and potential sources of driver distraction within the vehicle (e.g., pets, phone usage, and unsecured objects in the vehicle).
- Sensor 1111 also may be configured to collect data identifying a current driver from among a number of different possible drivers, for example, based on driver's seat and mirror positioning, driving times and routes, radio usage, etc. Voice/sound data along with directional data also may be used to determine a seating position within a vehicle 1110 .
- Sensor 1111 also may be configured to collect data relating to a driver's movements or the condition of a driver.
- vehicle 1110 may include sensors that monitor a driver's movements, such as the driver's eye position and/or head position, etc. Additional sensors 1111 may collect data regarding the physical or mental state of the driver, such as fatigue or intoxication.
- the condition of the driver may be determined through the movements of the driver or through other sensors, for example, sensors that detect the content of alcohol in the air or blood alcohol content of the driver, such as a breathalyzer, along with other biometric sensors.
- Certain vehicle sensors 1111 also may collect information regarding the driver's route choice, whether the driver follows a given route, and to classify the type of trip (e.g. commute, errand, new route, etc.) and type of driving (e.g., continuous driving, parking, stop-and-go traffic, etc.). In certain embodiments, sensors and/or cameras 1111 may determine when and how often the vehicle 1110 stays in a single lane or strays into other lane.
- GPS Global Positioning System
- locational sensors positioned inside the vehicle 1110 and/or locational sensors or devices external to the vehicle 1110 may be used to determine the route, speed, lane position, road-type (e.g. highway, entrance/exit ramp, residential area, etc.) and other vehicle position/location data.
- road-type e.g. highway, entrance/exit ramp, residential area, etc.
- the data collected by vehicle sensor 1111 may be stored and/or analyzed within the vehicle 1110 , such as for example a driving analysis computer 1114 integrated into the vehicle, vehicle control computer 1117 , and/or may be transmitted to one or more external devices.
- sensor data may be transmitted via a telematics device 1113 to one or more remote computing devices, such as personal mobile device 1130 , insurance system server 1150 , and/or other remote devices.
- Telematics device 1113 may be one or more computing devices containing many or all of the hardware/software components as the computing device 101 depicted in FIG. 1 . As discussed above, the telematics device 1113 may receive vehicle operation data and driving data from vehicle sensor 1111 , and may transmit the data to one or more external computer systems (e.g., insurance system server 1150 of an insurance company, financial institution, or other entity) over a wireless transmission network. Telematics device 1113 also may be configured to detect or determine additional types of data relating to real-time driving and the condition of the vehicle 1110 .
- external computer systems e.g., insurance system server 1150 of an insurance company, financial institution, or other entity
- telematics device 1113 may receive vehicle driving data from vehicle sensor 1111 , and may transmit the data to an insurance system server 1150 .
- vehicle sensors 1111 or systems may be configured to receive and transmit data directly from or to an insurance system server 1150 without using a telematics device.
- telematics device 1113 may be configured to receive and transmit data from certain vehicle sensors 1111 or systems, while other sensors or systems may be configured to directly receive and/or transmit data to an insurance system server 1150 without using the telematics device 1113 .
- telematics device 1113 may be optional in certain embodiments.
- the received sensor data may be analyzed by one or more computing devices within the vehicle, such as driving analysis device 1114 and/or vehicle control computer 1117 .
- the system 1100 in FIG. 11 also includes a mobile device 1130 .
- Mobile devices 1130 may be, for example, smartphones or other mobile phones, personal digital assistants (PDAs), tablet computers, and the like, and may include some or all of the elements described above with respect to the computing device 101 .
- some mobile devices in systems 1100 e.g., mobile device 1130
- the mobile device 1130 might not connect to vehicle-based computing devices and internal components, but may operate independently by communicating with vehicle 1110 via their standard communication interfaces (e.g., telematics device 1113 , etc.), or might not connect at all to vehicle 1110 .
- Mobile device 1130 may include a network interface 1121 , which may include various network interface hardware (e.g., adapters, modems, wireless transceivers, etc.) and software components to enable mobile device 1130 to communicate with insurance system server 1150 , vehicle 1110 , and various other external computing devices.
- network interface 1121 may include various network interface hardware (e.g., adapters, modems, wireless transceivers, etc.) and software components to enable mobile device 1130 to communicate with insurance system server 1150 , vehicle 1110 , and various other external computing devices.
- One or more specialized software applications such as a driving analysis application 1134 and/or a usage-based insurance application 1135 may be stored in the memory of the mobile device 1130 (e.g., may be downloaded or otherwise provided to the device and stored).
- the driving analysis application 1134 and usage-based insurance application 1135 may be received via network interface 1121 from the insurance server 1150 , vehicle 1110 , or other application providers (e.g., application stores).
- the driving analysis application 1134 and risk unit based insurance application 1135 may or may not include various user interface screens, and may be configured to run as user-initiated applications or as background applications.
- the memory of the mobile device 1130 also may include databases configured to receive and store vehicle data, driving data, driving trip data, and the like, associated with one or more drivers and/or vehicles.
- mobile device 1130 also may include various components configured to generate and/or receive vehicle data, driver data, and driving data or other operational data. For example, using data from the GPS receiver 1133 , a driving analysis software application 1134 may be able to identify starting and stopping points of driving trips, determine driving speeds, times, routes, and the like. Additional components of mobile device 1130 may be used to generate or receive driving data for the driving data analysis application 1134 and/or usage-based insurance application 1135 , such as an accelerometer, compass, and various cameras and proximity sensors.
- driving data analysis application 1134 may be able to identify starting and stopping points of driving trips, determine driving speeds, times, routes, and the like.
- Additional components of mobile device 1130 may be used to generate or receive driving data for the driving data analysis application 1134 and/or usage-based insurance application 1135 , such as an accelerometer, compass, and various cameras and proximity sensors.
- these and other mobile device components may be used to receive, store, and output various user/driver data, to identify starting and stopping points and other characteristics of driving trips, to determine various driving data such as speeds, driving routes and times, acceleration, braking, and turning data, and other driving conditions and behaviors.
- the driving analysis software application 1134 may store and analyze the data from various mobile device components, and the usage-based insurance application 1135 may use this data, alone or in any combination with other components or devices (e.g., insurance server 1150 ), to determine and present insurance offers, insurance costs (e.g., cost per day, cost per mile, revised cost per day, revised cost per mile, etc.), and the like.
- mobile computing devices 1130 may store, analyze, and/or transmit the vehicle driver data (e.g., data identifying a current driver), driving data (e.g., speed data, acceleration, braking, and turning data, and any other vehicle sensor or operational data), and driving trip data (e.g., driving route, driving times, driving destinations, etc.), to one or more other devices.
- vehicle driver data e.g., data identifying a current driver
- driving data e.g., speed data, acceleration, braking, and turning data, and any other vehicle sensor or operational data
- driving trip data e.g., driving route, driving times, driving destinations, etc.
- mobile computing device 1130 may transmit driver data, driving data and driving behaviors, and driving trip data directly to one or more insurance servers 1150 , and thus may be used in conjunction with or instead of telematics devices 1113 .
- the processing components of the mobile computing device 1130 may be used to identify vehicle drivers and passengers, analyze vehicle driving data, analyze driving trips, determine parameters related to aspects of risk unit based insurance policies, and perform other related functions. Therefore, in certain embodiments, mobile computing device 1130 may be used in conjunction with, or in place of, the insurance system server 1150 .
- Vehicle 1110 may include driving analysis computer 1114 , which may be separate computing devices or may be integrated into one or more other components within the vehicle 1110 , such as the telematics device 1113 , autonomous driving systems, or the internal computing systems 1117 of vehicle 1110 .
- driving analysis computers 1114 also may be implemented by computing devices independent from the vehicle 1110 , such as mobile computing device 1130 of the drivers or passengers, or one or more separate computer systems (e.g., a user's home or office computer).
- the driving analysis computer 1114 may contain some or all of the hardware/software components as the computing device 101 depicted in FIG. 1 .
- the functionality of the driving analysis computers may be performed in a central insurance system server 1150 rather than by the individual vehicle 1110 or personal mobile device 1130 .
- the vehicle 1110 and and/or mobile device 1130 might only collect and transmit driver data, vehicle data, driving data, and the like to an insurance server 1150 , and thus the vehicle-based driving analysis computer 1114 may be optional.
- the system 1100 also may include one or more insurance system servers 1150 , containing some or all of the hardware/software components as the computing device 101 depicted in FIG. 1 .
- the insurance system server 1150 may include hardware, software, and network components to receive driver data, vehicle data, and vehicle operational data/driving data from one or more vehicles 1110 , mobile devices 1130 , and other data sources.
- the insurance system server 1150 may include an insurance database 1152 and usage-based insurance system 1151 to respectively store and analyze driver data, vehicle data, and driving data, etc., received from vehicle 1110 , mobile device 1130 , and other data sources.
- the usage-based insurance system 1151 may include many or all of the components of usage-based insurance system 1000 described with respect to FIG. 10 .
- the insurance system server 1150 may initiate communication with and/or retrieve driver data, vehicle data, and driving data from vehicle 1110 wirelessly via telematics device 1113 , mobile device 1130 , or by way of separate computing systems over one or more computer networks (e.g., the Internet).
- the insurance system server 1150 may receive additional data from other third-party data sources, such as external traffic databases containing traffic data (e.g., amounts of traffic, average driving speed, traffic speed distribution, and numbers and types of accidents, etc.) at various times and locations, external weather databases containing weather data (e.g., rain, snow, sleet, and hail amounts, temperatures, wind, road conditions, visibility, etc.) at various times and locations, and other external data sources containing driving hazard data (e.g., road hazards, traffic accidents, downed trees, power outages, road construction zones, school zones, and natural disasters, etc.), route and navigation information, and insurance company databases containing insurance data (e.g., driver score, coverage amount, deductible amount, premium amount, insured status) for the vehicle, driver, and/or other nearby vehicles and drivers.
- traffic data e.g., amounts of traffic, average driving speed, traffic speed distribution, and numbers and types of accidents, etc.
- weather databases e.g., rain, snow, sleet
- Data stored in the insurance database 1152 may be organized in any of several different manners.
- a driver table in database 1152 may contain all of the driver data for drivers associated with the insurance provider (e.g., driver personal information, insurance account information, demographic information, accident histories, risk factors, driving scores and driving logs, etc.)
- a vehicle table may contain all of the vehicle data for vehicles associated with the insurance provider (e.g., vehicle identifiers, makes, models, years, accident histories, maintenance histories, travel logs, estimated repair costs and overall values, etc.)
- a driving trip table may store all of the driving trip data for drivers and vehicles associated with the insurance provider (e.g., driving trip driver, vehicle driven, trip time, starting and ending points, route driven, etc.).
- Other tables in the database 1152 may store additional data, including data types discussed above (e.g. traffic information, road-type and road condition information, weather data, insurance policy data, etc.). Additionally, one or more other databases of other insurance providers containing additional driver data and vehicle data may be accessed to retrieve such additional data.
- data types discussed above e.g. traffic information, road-type and road condition information, weather data, insurance policy data, etc.
- one or more other databases of other insurance providers containing additional driver data and vehicle data may be accessed to retrieve such additional data.
- the usage-based insurance system 1151 within the insurance system server 1150 may be configured to retrieve data from the database 1152 , or may receive driver data, vehicle data, and driving trip directly from vehicle 1110 , mobile device 1130 , or other data sources, and may perform driving data analyses, determine insurance parameters for usage-based insurance policies, and other related functions.
- the functions performed by the usage-based insurance analysis system 1151 may be performed by specialized hardware and/or software separate from the additional functionality of the insurance system server 1150 . Such functions may be similar to those of driving analysis module 1114 of vehicle 1110 , and the driving analysis and usage-based insurance applications 1134 and 1135 of mobile device 1130 , and further descriptions and examples of the algorithms, functions, and analyses that may be executed by the usage-based insurance system 1151 are described more fully below.
- FIG. 12 illustrates one example method of determining a cost of a trip associated with a usage-based insurance policy and deducting the cost of the trip from a premium associated with the policy according to one or more aspects described herein. It should be noted that although various steps of the process are shown in order in FIG. 12 , one or more steps of the process may be performed in a different order, or not performed, without departing from the invention.
- a premium amount is received for an insurance policy.
- the premium e.g., an amount of funds
- the entity e.g., insurance provider
- the funds may be held in the account until a portion of the premium funds are used (e.g., based on operation of the vehicle).
- the cost of one or more trips may be deducted from the premium and transferred from the account to another account of the entity.
- the premium may be based on various factors, as described herein. For instance, driving history, credit rating, location, and various other factors may be used to determine an amount of the premium for the usage-based insurance policy.
- a first cost per day and/or a first cost per mile associated with the policy may be determined.
- the cost per day and/or cost per mile may be determined based on factors such as driving history, accident history, location, credit rating, and the like. These costs or rates may be used to determine a cost of a driving trip performed by the vehicle associated with the usage-based insurance policy, as is discussed more fully herein.
- driving trip data may be received for a first driving trip.
- the driving trip data may be received from one or more sensors (e.g., sensors 1010 a - 1010 c ) associated with the system and may be received by, for instance, the usage cost module.
- the driving trip data may include data associated with start time of the first driving trip, end time of the first driving trip, duration of driving, distance driven, location, braking, swerving, acceleration, deceleration, and the like.
- contextual or environmental information e.g. from sensors 1010 a - 1010 c and/or locality database 1008 ) associated with the first driving trip may be received.
- Contextual or environmental information may include time of day, weather conditions, precipitation conditions, traffic volumes, and the like.
- the driving trip data may include the contextual or environmental information (e.g., all desired data may be received in step 1204 and the process may proceed from step 1204 to 1208 ).
- the system may determine a cost of the driving trip. For instance, the system may determine the cost of the first driving trip based on, for example, the cost per day and the cost per mile determined in step 1202 . This information may be used in conjunction with the distance and time of the trip to determine a cost of the first trip.
- this cost of the first trip may then be deducted from the premium provided by the user in step 1200 and stored in the account module. For instance, a balance of the premium in the account may be reduced by the cost of the trip.
- a determination may be made as to whether, after reducing the premium by the cost of the trip, a balance of the premium is below a predetermined threshold. If so, the system may automatically attempt to transfer additional funds into the account in step 1214 . That is, the user may store payment account information in the account module. This payment account information may be used to access the payment account and attempt to transfer a predetermined amount of funds into the account of the user.
- the predetermined amount of funds may, in some examples, be a same amount as the initial premium amount. In other examples, the predetermined amount may be another amount determined by the user or the entity.
- step 1216 the system may proceed to step 1216 in which a second or revised rate or cost per day and a second or revised rate or cost per mile may be determined.
- the second cost per day and/or cost per mile may be determined based on factors similar to those used to determine the first cost per day and the first cost per mile, as well as based on the driving data and/or contextual environmental data received. For instance, if a user has several instances of hard braking in the received driving data, the cost per rate and/or cost per mile may be increased to account for the additional risk associated with this driving behavior. In another example, if the driver was operating the vehicle at night and/or in heavy precipitation, the system may increase the cost per day and/or cost per mile to account for this increased risk.
- the system may then return to step 1204 to receive driving data for a second or subsequent trip and may continue the process.
- FIG. 13 illustrates one example method of attempting to automatically transfer funds from a payment account to a user or vehicle account according to one or more examples discussed herein. For instance, the process shown in FIG. 13 may occur simultaneously with or immediately following step 1214 , in some examples.
- step 1300 the system may attempt to automatically transfer funds from the identified payment account of the user to the user account stored in the account module. This process may, in some examples, be performed by the account module.
- step 1302 a determination may be made as to whether the attempted transfer was successful. For instance, the system may determine whether there were sufficient funds in the payment account, whether a credit card number provided was still valid, etc. If the attempted transfer was successful, the funds may be transferred from the payment account to the user account in step 1304 .
- a notification may be provided to the user in step 1306 .
- providing a notification may include displaying an indication to the user (e.g., on a display of the on-board vehicle computing device, on a mobile device of the user, or the like) indicating that the user's account balance is below the threshold, that an attempt to replenish the account was made and was not successful.
- providing a notification may include modifying operation of the vehicle.
- the system may provide an instruction or signal to, for instance, the vehicle control computer 1117 , to modify operation of the vehicle or one or more systems of the vehicle.
- the instruction may include causing the vehicle to flash the headlights, engage the horn, and/or may prevent the vehicle from starting or operating in a normal fashion.
- a determination may be made as to whether, after a predetermined time, the desired funds were received by the user account. For instance, the system may wait a predetermined time, such as one day, three days, one week, or the like and may make another attempt to transfer the funds or may review the balance of the account to determine whether funds were deposited (e.g., determine whether the premium balance is still below the threshold). If the funds have been received in step 1308 , the transfer may be completed and/or the premium balance may be replenished (e.g., increased above the predetermined threshold).
- step 1308 If, in step 1308 , the funds have not been received or any additional attempts to transfer the funds are not successful, the insurance policy may be cancelled in step 1312 .
- FIG. 14 illustrates one example method of reducing or eliminating charges upon reaching a daily mileage threshold limit, according to one or more aspects described herein.
- a premium may be received for a usage-based insurance policy.
- a cost or rate per day and/or a cost or rate per mile may be determined based on one or more factors.
- the cost per day and/or cost per mile may be an initial or first cost per day or cost per mile, or may be a revised cost per day or cost per mile, as discussed above, and therefore may be based on various factors, as discussed herein.
- driving data for a trip may be received.
- Driving data may include duration, distance, location, driving behavior data, contextual or environmental data, and the like.
- a determination is made as to whether a distance driven in the trip is above a predetermined threshold. For instance, a user may have a policy that provides that any miles driven over a predetermined threshold number of miles in a day (e.g., 100 , 75 , 150 , or the like) may be driven free of charge (e.g., without a cost being deducted from the premium for miles over the threshold).
- the system may determine a cost of the trip based on the cost per day and/or cost per mile and the total distance driven in step 1408 .
- the cost for the trip will be determined based on the cost per day and/or the cost per mile and the threshold distance.
- FIG. 15 illustrates one example method of tracking trip events via a ledger according to one or more aspects described herein.
- a trip event may be received.
- a trip event may include an occurrence of driving a vehicle, such as from a source location to a destination.
- the trip event may be added to a database of trip events. For instance, the trip event may be added to a database storing historical driving data, such as within usage cost module 1002 , or within insurance database 1006 .
- trip cost and aggregate miles may be determined. That is, the usage cost module 1002 may determine a cost associated with the trip based on, for example, a number of miles, a duration of the trip, and the like. The cost per day and/or cost per mile may be determined, as well as an aggregate number of miles travelled.
- the trip event and associated details e.g., costs, aggregate miles, and the like
- the ledger may store and/or track an account balance for a user, trip events, trip costs, aggregate miles, and the like.
- the account module 1012 may determine a new balance in the ledger for the account based on the data received. For instance, a cost of the trip event may be deducted from a previous account balance stored in the ledger to determine a new balance. In one example in which a cost per day is used as a charge for the usage-based insurance policy, the balance in the ledger for a policy may be reduced by the determined rate per day for each vehicle associated with the policy (rate per day may vary based on a selected coverage for a vehicle).
- FIG. 16 illustrates one example method of replenishing accounts according to one or more aspects described herein.
- step 1600 one or more accounts with a balance below a threshold may be determined.
- step 1602 replenishment may be requested from the accounts identified as having a balance below the threshold.
- step 1604 a determination may be made as to whether payment has been received for, for example, a first account. If so, the ledger may be updated with payment information in step 1608 . If not, the account status may be updated in the ledger in step 1606 . Updating the account status may include flagging the account as being below the threshold, notifying the customer that his or her account is below the threshold, and/or cancelling the insurance policy associated with the account.
- step 1610 a determination is made as to whether there are more accounts to determine whether payment has been received. If so, the process may return to step 1604 . If not, the process may end.
- FIG. 17 illustrates one example method of creating a new account in the system and the ledger, according to one or more aspects described herein.
- a request may be transmitted to a customer.
- the request may include a request to open a new account, obtain a new usage-based policy, or the like.
- the request may be transmitted to the customer via an electronic message, such as email, SMS, and the like.
- the electronic message may include a link that the user may select if he or she desires to proceed with creating an account.
- a customer may accept the request to create a new account and the acceptance may be received and/or recorded by the system (e.g., system 1000 in FIG. 10 ).
- a new account may be created (e.g., in account module 1012 ) and the new account information may be transmitted to the ledger to create a new entry in the ledger.
- an initial deposit of funds may be received and the initial deposit may be recorded in the ledger.
- the initial deposit may be an insurance premium or other amount creating a balance of funds in the usage-based insurance account from which costs per mile and/or costs per day may be deducted as a vehicle is operated.
- the policy premium may be determined based on the following:
- an endorsement may occur during a term of the policy.
- a premium may be adjusted based on the endorsement.
- the premium may be determined by:
- the premium for the policy may be calculated using:
- the calculations are rounded to the nearest one cent. Additionally or alternatively, calculations may vary based on a coverage level for a vehicle. For instance, a policy having more coverage may have a different rate per day or rate per mile than a policy having lower or less coverage, thereby altering the premium based on the amount of coverage associated with the policy.
- the initial deposit may include an adjustment for one or more fees. For instance, some states have fees that are collected on various policies. Accordingly, the initial payment may be reduced by an amount of state fees prior to any deductions being made for operating a vehicle associated with the usage-based insurance policy.
- policy information may be requested.
- the policy information may include information associated with the vehicle (e.g., make, model, year, etc.) and/or the driver (e.g., age, driving history, and the like).
- the policy information may also include information associated with a type of policy, amount of premium, amount of replenishment, and the like. This information may be provided by the customer and, in some examples, may be stored in insurance database 1006 .
- the policy information may be received and the ledger may be updated with any policy information received.
- the balance of the account may be included in the ledger and, as the driver operates a vehicle, driving or trip event data may be received by the system, costs determined, and an amount deducted from the account, as discussed more fully herein.
- the ledger, initial payment, and the like may be associated with a policy.
- a single policy may have multiple vehicles associated therewith. Accordingly, a single ledger entry for the policy may exist and the account balance may be reduced by costs per day and/or costs per mile for any of the vehicles associated with the policy.
- premiums may be determined at a vehicle level (e.g., each vehicle on a policy may have a different premium based on characteristics of the vehicle), and coverage level, state fees, and the like, may also be determined at a vehicle level, rather than a policy level.
Landscapes
- Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Finance (AREA)
- Accounting & Taxation (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Methods, computer-readable media, systems and apparatuses for determining and implementing usage-based insurance policies are presented. A first cost per day and second cost per day associated with the usage-based insurance policy may be determined and a cost for a first trip may be determined based on the cost per day and cost per mile. Driving data received during the first trip may be used to modify the cost per day and cost per mile to determine a second cost per day and/or cost per mile that may be used to determine a cost of subsequent driving trips.
Description
- This application is a division of and claims priority to U.S. application Ser. No. 17/036,768, filed Sep. 29, 2020, and entitled “Usage-Based Policies” which is a division of and claims priority to U.S. application Ser. No. 14/988,977, filed Jan. 6, 2016, and entitled “Usage-Based Policies” which is a continuation-in-part of and claims priority to U.S. application Ser. No. 14/607,636, filed Jan. 28, 2015, and entitled “Risk Unit Based Policies,” and U.S. application Ser. No. 14/607,662, filed Jan. 28, 2015, and entitled “Risk Unit Based Policies.” Each of these applications is incorporated by reference in its entirety herein.
- Various aspects of the disclosure relate to usage-based insurance systems for determining and implementing usage-based insurance policies. More specifically, aspects of the disclosure relate to determining cost per day and cost per mile based on received driving data.
- Vehicle insurance policies are generally purchased by insurance customers from various insurance providers. Conventional policies generally provide coverage to the user for a term of the policy based on payment of a premium associated with the policy. Such term based policies might not account for driving behaviors, environmental conditions, or the like. Rather, coverage may be provided for the term, regardless of how, where, when, etc. the driver operates the vehicle.
- Many vehicles include sensors and internal computer systems designed to store and monitor driving data, vehicle operation data, driving conditions, and driving functions. Many vehicles also include one or more communication systems designed to send and receive information from inside or outside the vehicle. Such information can include, for example, vehicle operational data, driving conditions, and communications from other vehicles or systems.
- The following presents a simplified summary in order to provide a basic understanding of some aspects of the disclosure. The summary is not an extensive overview of the disclosure. It is neither intended to identify key or critical elements of the disclosure nor to delineate the scope of the disclosure. The following summary merely presents some concepts of the disclosure in a simplified form as a prelude to the description below.
- Aspects of the disclosure relate to methods, computer-readable media, and apparatuses for determining a cost per day and/or a cost per mile for a usage-based insurance policy. These costs may be used to determine a cost associated with a driving trip and that cost may be deducted from a balance of a premium paid by the user. In some examples, driving data associated with the first driving trip may be collected from one or more sensors in a vehicle. This driving data may be used to revise or modify the cost per day and/or cost per mile in order to account for increased or decreased risk associated with the particular driving behaviors of the user. One or more subsequent driving trips may then be performed and a cost associated with each of the one or more driving trips may be determined based on the revised or modified cost per day and/or cost per mile.
- Other features and advantages of the disclosure will be apparent from the additional description provided herein.
- A more complete understanding of the present invention and the advantages thereof may be acquired by referring to the following description in consideration of the accompanying drawings, in which like reference numbers indicate like features, and wherein:
-
FIG. 1 illustrates computing systems and a network environment that may be used to implement aspects of the disclosure. -
FIG. 2 is an example risk unit based insurance system according to one or more aspects described herein. -
FIG. 3 is an example risk unit based insurance system environment illustrating various communications between vehicles-based devices, a personal mobile device, and an insurance system server, according to one or more aspects of the disclosure. -
FIG. 4 is a flow diagram illustrating an example method of generating a risk unit based insurance policy and implementing the risk unit based insurance policy according to one or more aspects described herein. -
FIG. 5 is an example user interface providing information to a user regarding a risk unit consumption rate according to one or more aspects described herein. -
FIG. 6 is a flow diagram illustrating an example method of providing one or more risk unit account refill options to a user, according to one or more aspects described herein. -
FIGS. 7A-7D are example user interfaces that may be provided to a user to facilitate risk unit account replenishment according to one or more aspects described herein. -
FIG. 8 is a flow diagram illustrating an example method of generating suggested modifications to driving behaviors in order to improve risk unit consumption rate, according to one or more aspects described herein. -
FIG. 9 is an example user interface providing one or more recommended driving behavior modifications to a user, according to one or more aspects described herein. -
FIG. 10 is an example usage-based insurance system according to one or more aspects described herein. -
FIG. 11 is an example usage-based insurance system environment illustrating various communications between vehicle-based devices, a personal mobile device, and an insurance system server, according to one or more aspects of the disclosure. -
FIG. 12 is a flow chart illustrating an example method of determining a cost of a trip associated with a usage-based insurance policy and deducting the cost of the trip from a premium associated with the policy according to one or more aspects described herein. -
FIG. 13 is a flow chart illustrating an example method of attempting to automatically transfer funds from a payment account to a user or vehicle account according to one or more aspects described herein. -
FIG. 14 is a flow chart illustrating one example method of reducing or eliminating charges upon reaching a daily mileage threshold limit, according to one or more aspects described herein. -
FIG. 15 is a flow chart illustrating one example method of tracking trip events via a ledger in accordance with one or more aspects described herein. -
FIG. 16 is a flow chart illustrating one example method of replenishing accounts according to one or more aspects described herein. -
FIG. 17 is a flow chart illustrating one example method of creating a new account according to one or more aspects described herein. - In the following description of the various embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration, various embodiments of the disclosure that may be practiced. It is to be understood that other embodiments may be utilized.
- As will be appreciated by one of skill in the art upon reading the following disclosure, various aspects described herein may be embodied as a method, a computer system, or a computer program product. Accordingly, those aspects may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, such aspects may take the form of a computer program product stored by one or more computer-readable storage media having computer-readable program code, or instructions, embodied in or on the storage media. Any suitable computer-readable storage media may be utilized, including hard disks, CD-ROMs, optical storage devices, magnetic storage devices, and/or any combination thereof. In addition, various signals representing data or events as described herein may be transferred between a source and a destination in the form of electromagnetic waves traveling through signal-conducting media such as metal wires, optical fibers, and/or wireless transmission media (e.g., air and/or space).
-
FIG. 1 illustrates a block diagram of a computing device (or system) 101 in acomputer system 100 that may be used according to one or more illustrative embodiments of the disclosure. Thedevice 101 may have aprocessor 103 for controlling overall operation of thedevice 101 and its associated components, includingRAM 105,ROM 107, input/output module 109, andmemory 115. Thecomputing device 101, along with one or more additional devices (e.g.,terminals - Input/Output (I/O) 109 may include a microphone, keypad, touch screen, and/or stylus through which a user of the
computing device 101 may provide input, and may also include one or more of a speaker for providing audio output and a video display device for providing textual, audiovisual and/or graphical output. Software may be stored withinmemory 115 and/or storage to provide instructions toprocessor 103 for enablingdevice 101 to perform various actions. For example,memory 115 may store software used by thedevice 101, such as anoperating system 117,application programs 119, and an associatedinternal database 121. The various hardware memory units inmemory 115 may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Certain devices and systems within risk unit based insurance systems may have minimum hardware requirements in order to support sufficient storage capacity, processing capacity, analysis capacity, network communication, etc. For instance, in some embodiments, one or more nonvolatile hardware memory units having a minimum size (e.g., at least 1 gigabyte (GB), 2 GB, 5 GB, etc.), and/or one or more volatile hardware memory units having a minimum size (e.g., 256 megabytes (MB), 512 MB, 1 GB, etc.) may be used in a device 101 (e.g., a personalmobile device 101, vehicle-baseddevice 101,insurance system server 101, etc.), in order to collect and analyze driver data, vehicle data, and/or driving trip data, determine risk unit based insurance policy parameters, determine rate at which risk units are consumed during operation of a vehicle, etc., using the various devices of the risk unit based insurance systems.Memory 115 also may include one or more physical persistent memory devices and/or one or more non-persistent memory devices.Memory 115 may include, but is not limited to, random access memory (RAM) 105, read only memory (ROM) 107, electronically erasable programmable read only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed byprocessor 103. -
Processor 103 may include a single central processing unit (CPU), which may be a single-core or multi-core processor (e.g., dual-core, quad-core, etc.), or may include multiple CPUs. Processor(s) 103 may have various bit sizes (e.g., 16-bit, 32-bit, 64-bit, 96-bit, 128-bit, etc.) and various processor speeds (ranging from 100 MHz to 5 Ghz or faster). Processor(s) 103 and its associated components may allow thesystem 101 to execute a series of computer-readable instructions, for example, determine a risk unit balance in a risk unit account, to receive and analyze driver data, vehicle data, and/or driving trip data, determine a rate at which risk units are consumed (e.g., based on analyzed driver data, vehicle data, external data, or the like), and/or automatically refill a risk unit account balance upon determining that the balance has reached a predetermined threshold. - The computing device (e.g., a personal mobile device, vehicle-based system, insurance system server, etc.) may operate in a
networked environment 100 supporting connections to one or more remote computers, such asterminals computing device 101. The network connections depicted inFIG. 1 include a local area network (LAN) 125 and a wide area network (WAN) 129, and awireless telecommunications network 133, but may also include other networks. When used in a LAN networking environment, thecomputing device 101 may be connected to theLAN 125 through a network interface oradapter 123. When used in a WAN networking environment, thedevice 101 may include amodem 127 or other means for establishing communications over theWAN 129, such as network 131 (e.g., the Internet). When used in awireless telecommunications network 133, thedevice 101 may include one or more transceivers, digital signal processors, and additional circuitry and software for communicating withwireless computing devices 151 and 161 (e.g., mobile phones, portable customer computing devices, vehicle-based computing devices and systems, etc.) via one or more network devices 135 (e.g., base transceiver stations) in thewireless network 133. - Also illustrated in
FIG. 1 is a security andintegration layer 160, through which communications are sent and managed between the device 101 (e.g., a personal mobile device, a vehicle-based computing device, an insurance server, an intermediary server and/or external data source servers, etc.) and the remote devices (141, 151, and 161) and remote networks (125, 129, and 133). The security andintegration layer 160 may comprise one or more separate computing devices, such as web servers, authentication servers, and/or various networking components (e.g., firewalls, routers, gateways, load balancers, etc.), having some or all of the elements described above with respect to thecomputing device 101. As an example, a security andintegration layer 160 of aserver 101 may comprise a set of web application servers configured to use secure protocols and to insulate thedevice 101 fromexternal devices integration layer 160 may correspond to a set of dedicated hardware and/or software operating at the same physical location and under the control of same entities asdevice 101. For example,layer 160 may correspond to one or more dedicated web servers and network hardware in a vehicle and driver information datacenter or in a cloud infrastructure supporting a cloud-based vehicle identification and vehicle and driver data retrieval and analysis. In other examples, the security andintegration layer 160 may correspond to separate hardware and software components which may be operated at a separate physical location and/or by a separate entity. - As discussed below, the data transferred to and from various devices in a risk unit based
insurance system 100 may include secure and sensitive data, such as confidential vehicle operation data, insurance policy data, and confidential user data from drivers and passengers in vehicles. Therefore, it may be desirable to protect transmissions of such data by using secure network protocols and encryption, and also to protect the integrity of the data when stored on the various devices within a personalized insurance system, such as personal mobile devices, vehicle-based devices, insurance servers, external data source servers, or other computing devices in thesystem 100, by using the security andintegration layer 160 to authenticate users and restrict access to unknown or unauthorized users. In various implementations, security andintegration layer 160 may provide, for example, a file-based integration scheme or a service-based integration scheme for transmitting data between the various devices in anelectronic display system 100. Data may be transmitted through the security andintegration layer 160, using various network communication protocols. Secure data transmission protocols and/or encryption may be used in file transfers to protect to integrity of the data, for example, File Transfer Protocol (FTP), Secure File Transfer Protocol (SFTP), and/or Pretty Good Privacy (PGP) encryption. In other examples, one or more web services may be implemented within thevarious devices 101 in thesystem 100 and/or the security andintegration layer 160. The web services may be accessed by authorized external devices and users to support input, extraction, and manipulation of the data (e.g., vehicle data, driver data, driving trip data, etc.) between thevarious devices 101 in thesystem 100. Web services built to support a personalized display system may be cross-domain and/or cross-platform, and may be built for enterprise use. Such web services may be developed in accordance with various web service standards, such as the Web Service Interoperability (WS-I) guidelines. In some examples, a driver data, vehicle data, and/or driving trip data analysis web service, a risk unit based insurance policy determination or offer web service, or the like, may be implemented in the security andintegration layer 160 using the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocol to provide secure connections betweenservers 101 andvarious clients integration layer 160 may include specialized hardware for providing secure web services. For example, secure network appliances in the security andintegration layer 160 may include built-in features such as hardware-accelerated SSL and HTTPS, WS-Security, and firewalls. Such specialized hardware may be installed and configured in the security andintegration layer 160 in front of the web servers, so that any external devices may communicate directly with the specialized hardware. - Although not shown in
FIG. 1 , various elements withinmemory 115 or other components insystem 100, may include one or more caches, for example, CPU caches used by theprocessing unit 103, page caches used by theoperating system 117, disk caches of a hard drive, and/or database caches used to cache content fromdatabase 121. For embodiments including a CPU cache, the CPU cache may be used by one or more processors in theprocessing unit 103 to reduce memory latency and access time. In such examples, aprocessor 103 may retrieve data from or write data to the CPU cache rather than reading/writing tomemory 115, which may improve the speed of these operations. In some examples, a database cache may be created in which certain data from a database 121 (e.g., a database of driver data, driving behaviors or characteristics, passenger-related data, vehicle data, driving trip data, account balance data, etc.) is cached in a separate smaller database on an application server separate from the database server (e.g., at a personal mobile device, vehicle-based data, or intermediary network device or cache device, etc.). For instance, in a multi-tiered application, a database cache on an application server can reduce data retrieval and data manipulation time by not needing to communicate over a network with a back-end database server. These types of caches and others may be included in various embodiments, and may provide potential advantages in certain implementations of risk unit based insurance systems, such as faster response times and less dependence on network conditions when transmitting and receiving driver information, vehicle information, driving trip information, insurance parameters, account balance information, and the like. - It will be appreciated that the network connections shown are illustrative and other means of establishing a communications link between the computers may be used. The existence of any of various network protocols such as TCP/IP, Ethernet, FTP, HTTP and the like, and of various wireless communication technologies such as GSM, CDMA, WiFi, and WiMAX, is presumed, and the various computing devices in risk unit based insurance system components described herein may be configured to communicate using any of these network protocols or technologies.
- Additionally, one or
more application programs 119 may be used by thevarious computing devices 101 within a risk unit based insurance system 100 (e.g., vehicle data, driver data, and/or driving trip data analysis software applications, insurance parameter determination software applications, risk unit account applications, etc.), including computer executable instructions for receiving and analyzing various driver data, vehicle data, and/or driving trip data, determining parameters for risk unit insurance policies, presenting risk unit based insurance policies via the devices in the risk unit based insurance system, determining a rate at which risk units are consumed during operation of a vehicle, and evaluating and/or automatically refilling a balance of a risk unit account using the devices of the risk unit based insurance systems. -
FIG. 2 is a schematic diagram of an illustrative risk unit basedinsurance system 200. The risk unit basedinsurance system 200 may be associated with, internal to, operated by, or the like, anentity 201, such as an insurance provider. In some examples, the entity may be one of various other types of entities, such as a government entity, corporation or business, university, or the like. Various examples described herein will be discussed in the context of an insurance provider. However, nothing in the specification should be viewed as limiting use of the systems, methods, arrangements, etc. described herein to use only by an insurance provider. - The risk unit based
insurance system 200 may include one or more modules that may include hardware and/or software configured to perform various functions within thesystem 200. The one or more modules may be separate, physical devices or, in other examples, one or more modules may be part of the same physical device. - The risk unit based insurance system may include a
risk unit module 202. Therisk unit module 202 may be configured to determine a cost to insure an average user for a predetermined period of time. For instance, therisk unit module 202 may receive data, such as insurance data frominsurance data store 204, locality data fromlocality data store 206, as well as other data (from data stores not shown that may be internal to theentity 201 or external to the entity 201), and determine, based on the received data, the cost to insure an average user over a predetermined period of time (e.g., one month, one week, one day, one year, or the like). This cost may be considered equivalent to one risk unit. Further, a cost to the user or insurance policy holder to purchase a risk unit may be determined by the system. This cost may be different from the cost forming the risk unit and may be determined on a fixed date. The cost to the user may then be revised at a second date (e.g., monthly, annually, etc.). Accordingly, insurance may be provided to one or more users based on risk units, as will be discussed more fully herein. - The risk unit based
insurance system 200 may further include apolicy module 208. Thepolicy module 208 may generate and/or store insurance policies using risk units, as well as insurance policy information or factors, such as vehicle information, driving record/experience, policy limits, deductibles, etc. That is, a user may be insured through a policy that provides a number of risk units for a particular cost (e.g., insurance premium). The risk units may then be consumed by the user as, for example, the user drives or operates his or her vehicle. The risk units may be consumed based on sensor data-focused factors, such as time elapsed, driving habits of the user, environmental conditions in which the user operates the vehicle, vehicle parameters (such as year, make, model, features, specifications, etc.), condition or performance of the vehicle (e.g., based on sensor data), and the like, as well as traditional policy factors, such as driving experience, driving record, credit variables, policy coverage, deductible, policy limits, familiarity of the driver with the vehicle or surroundings, and the like. In some examples, one policy parameter may include a level of coverage. For instance, risk units may be purchased at various levels with each level providing a different level of coverage, as will be discussed more fully herein. Additionally or alternatively, the consumption rate may reflect different levels of coverage. - The insurance policies based on risk units may further include a risk unit account stored in risk
unit account module 210. The riskunit account module 210 may include one or more accounts associated with one or more users (e.g., users having risk unit based insurance policies), vehicles (e.g., vehicles associated with a risk unit based insurance policy), or the like. The accounts may include information associated with a user such as name, address, contact information, and the like, as well as information associated with the vehicle, such as vehicle identification number, make, model, year, etc. Further, the accounts may include a number of risk units associated with or available to the user or account holder, associated with the vehicle, etc. Accordingly, if a user has a risk unit based insurance policy that includes the purchase of 100 risk units, the user account will show, at the purchase, 100 risk units. As the risk units are consumed (e.g., by the user operating the vehicle, or the like) a balance of risk units in the account may be reduced. In some examples, the balance of risk units in an account may be displayed to the user via a computing device, such as one or more of computing devices 212 a-212 f For instance, the risk unit account balance may be displayed via an application (e.g., online or mobile application) on asmartphone 212 a, personal digital assistant (PDA) 212 b,tablet 212 c,cell phone 212 d, orother computing device 212 e. In some examples, the risk unit account balance may be displayed to a user on avehicle display 212 f. In addition to display of the account balance, various other account details may be displayed as desired. - In some arrangements, the risk unit account may include units of another type (e.g., other than risk units). For instance, the risk unit account may include an amount or balance of funds or money. The balance of funds may be reduced based on operation of the vehicle, as discussed above. In some examples, the risk units may be converted to funds in order to facilitate this reduction of balance (e.g., the consumption rate of units based on operation of the vehicle may be determined in risk units and then converted to funds in order to reduce the balance in the account appropriately). In other examples, the consumption rate may be determined in monetary units and the balance reduced as appropriate. Although various arrangements discussed herein will be described in terms of consumption rate being determined in risk units and a balance of an account including a number of risk units reduced accordingly, various other units may be used (e.g., monetary units) without departing from the invention.
- The risk unit based
insurance system 200 may further include a risk unitconsumption rate module 214. The risk unitconsumption rate module 214 may include hardware and/or software configured to determine and/or implement a consumption rate of risk units due to operation of the vehicle (e.g., as the user operates the vehicle, the number or balance of risk units in the risk unit account is reduced based on a determined consumption rate, thereby depleting the balance associated with the policy. Once the balance of risk units reaches a predetermined threshold, the number of risk units may be replenished, akin to renewal of a conventional insurance policy). As discussed above, the consumption rate may be determined in risk units, monetary units or other units, as desired. - As discussed above, the rate at which risk units are consumed by a user (e.g., by a user's operation of a vehicle) may be based on a variety of factors, such as personal information of the user, driving habits or behaviors of the user, environmental conditions, locality or geographic conditions, types of road being travelled, traditional policy factors, coverage, vehicle features or operation, and the like. Various algorithms may be used to determine the consumption rate. For example,
Equation 1 is one example that may be used to determine consumption rate based on sensor data-focused factors may include: -
RC1 =L 1 ×R 1 ×T 1 ×B 1 ×E 1, where Equation 1: -
- RC1 is the Rate of Consumption;
- L1 is a location factor that may include population density, traffic density, new route, commonly used route, and the like;
- R1 is a road condition factor that may include type of road, road geometry, road hazards, and the like;
- T1 is a time of day factor;
- B1 is a driver behavior factor and may include braking rate, acceleration rate, cornering, trip duration, swerving, distracted driving, and the like; and
- E1 is an environmental factor that may include weather conditions, contextual speed, and the like.
-
Equation 2 is another example that may be used to determine consumption rate based on sensor data-focused factors, as well as traditional policy factors, may include: -
RC2 =O 2 ×P 2 ×V 2 ×C 2 ×L 2 ×R 2 ×T 2 ×B 2 ×E 2, where Equation 2: -
- RC2 is the Rate of Consumption;
- O2 is an operator factor and may include driver age, gender, marital status, driving experience, driving record, and the like;
- P2 is a policy factor and may include credit variables, number of vehicles associated with a policy or driver, number of operators or drivers associated with a policy, prior insurance, multiple policies, and the like;
- V2 is a vehicle factor and may include vehicle identification number, aftermarket parts, vehicle features or specifications, vehicle condition, maintenance history, and the like;
- C2 is a coverage factor and may include coverages provided, policy or coverage limits, deductibles, and the like;
- L2 is a location factor that may include population density, traffic density, new route, commonly used route, and the like;
- R2 is a road condition factor that may include type of road, road geometry, road hazards, and the like;
- T2 is a time of day factor;
- B2 is a driver behavior factor and may include braking rate, acceleration rate, cornering, trip duration, swerving, distracted driving, and the like; and
- E2 is an environmental factor that may include weather conditions, contextual speed, and the like.
- In addition, either
Equation 1 orEquation 2 may further include an expenses factor. In some examples, an expenses value may be added to the result ofEquation 1 orEquation 2 in order to determine the consumption rate. - Further, although
Equation 1 andEquation 2 are provided as examples for determining consumption rate, various other equations and/or algorithms may be used without departing for the invention. For instance, one or more factors may be removed from the equation to determine consumption rate. Additionally or alternatively, other factors may be included in the equations, without departing from the invention. - Accordingly, one or more sensors 216 may be used to obtain data that may be used to determine the consumption rate for the user. For instance, the one or more sensors may include sensors to detect driving behaviors of the user, such as hard braking, speeding, and the like. In another example, one or more sensors may be used to detect environmental conditions such as precipitation, humidity, cloud cover, or the like. In still another example, one or more sensors may be used to determine road conditions or to obtain information from outside sources (e.g., external databases, or the like) regarding traffic conditions, types of road (e.g., two-lane road, four-lane road), speed limit of the road, or the like. The data from one or more sensors 216, which may include data from combinations of different types of sensors, may be used by the risk unit
consumption rate module 214 to determine a risk unit consumption rate for the user. - In examples in which the consumption rate is determined based on traditional policy factors (either in combination with sensor data-focused factors or alone) the traditional policy factors, such as driving record, credit information, driving experience, vehicle features and/or specifications, coverages, deductibles, policy limits, etc. may be obtained from, for example,
policy module 208. In some examples, the risk unit consumption rate may be determined or calculated for a particular trip. Additionally or alternatively, the consumption rate may be calculated or determined in real-time or near real-time, such that the rate may change as the user's driving behavior changes, as the type of road changes, as the environmental conditions change, or the like. Thus, for example, if a user is driving at speed higher than the speed limit and it is raining, the consumption rate may be higher than if the user is driving at the speed limit and/or there is no precipitation. This is merely one example of how consumption rate may change based on received sensor data and should not be viewed as limiting the disclosure to only this example. Rather, various other changes in received sensor data may be used to modify or alter the risk unit consumption rate for the user. - Similar to the risk unit account information, the risk unit consumption rate may be displayed to a user, such as via one or more computing devices 212 a-212 f In some examples, the risk unit
consumption rate module 214 may generate and/or display to a user suggestions for improving the consumption rate. For instance, the system may generate an alternate route that has been determined to be safer than the user's current route and, thus, by taking the alternate route, the consumption rate may be reduced. In another example, a user may be driving faster than a posted speed limit. The system may generate a notice to display to the user (e.g., via a computing device 212 a-212 f) indicating that, by slowing down, the user's consumption rate may be reduced. These are merely some examples of messages that may be displayed in order to aid the user in reducing the consumption rate of the risk units. However, various other suggestions or driving behavior modifications may be generated and provided to the user without departing from the invention. - The risk unit based
insurance system 200 may further include arisk unit marketplace 218. Therisk unit marketplace 218 may be connected to or in communication with various other modules within thesystem 200. In some examples, the risk unit marketplace may be used to refill a user's risk unit account. For instance, upon the user reaching a predetermined threshold within the risk unit account of the user (e.g., the balance of risk units within the account reaches a certain threshold) the user may be notified that the balance of risk units in the account is low and may offer one or more options for purchasing additional risk units or otherwise increasing the balance of risk units in the account. - For example, in some instances, upon reaching the threshold number of risk units within the account, a notification may be displayed to the user (e.g., via one or more of computing devices 212 a-212 f) indicating that the balance is low and offering additional risk units for sale. In some examples, the user may store credit card or other payment information (e.g., account information, debit card information, electronic funds transfer information, and the like) in the system (e.g., within the risk unit marketplace 218) such that, upon receiving the notification, the user may select a “purchase” option and a predetermined number of risk units may be purchased by the user and charged to the stored payment information. In another example, the user may select an automatic refill option. In such arrangements, a user may input payment information (e.g., credit card information, debit card information, checking or other account information, electronic funds transfer information, and the like) and may identify a predetermined threshold below which the system may automatically purchase additional risk units. These and various other arrangements will be discussed more fully below.
- The
risk unit marketplace 218 may also provide risk units for sale to other users or insurance providers. For instance, a user may obtain insurance through a different insurance provider but the risk units may be common units among a plurality of insurance providers. Accordingly, users having insurance policies with other providers may purchase risk units from therisk unit marketplace 218 and may have the risk units placed in an account associated with the policy provided by or associated with the other insurance provider. In some examples,entity 201 may charge a service fee or surcharge for purchase of risk units for use with a policy provided by another insurance carrier. -
FIG. 3 is a diagram of an illustrative system drivinganalysis system 300 including additional aspects of the risk unit basedinsurance system 200 shown inFIG. 2 and/or implementing the risk unit basedinsurance system 200 ofFIG. 2 . The system includes avehicle 310, a personalmobile device 330, aninsurance system server 350, and additional related components. As discussed below, the components of thesystem 300, individually or using communication and collaborative interaction, may determine, present, and implement various types of risk unit based insurance to customers, including providing or facilitating purchase of a risk unit based insurance policy and/or associated risk units, determining a consumption rate of risk units, communicating a consumption rate to a user, generating and providing suggestions to a user for reducing consumption rate, etc. To perform such features, the components shown inFIG. 3 each may be implemented in hardware, software, or a combination of the two. Additionally, each component of thesystem 300 may include a computing device (or system) having some or all of the structural components described above forcomputing device 101. -
Vehicle 310 in thesystem 300 may be, for example, an automobile, a motorcycle, a scooter, a bus, a recreational vehicle, a boat, or other vehicle for which vehicle data, location data, driver data (or operator data), operational data and/or other driving data (e.g., location data, time data, weather data, etc.) may be collected and analyzed. Thevehicle 310 includes vehicle operation sensor 311 (similar to one or more of sensors 216 a-216 c ofFIG. 2 ) capable of detecting and recording various conditions at the vehicle and operational parameters of the vehicle. For example,sensor 311 may detect and store data corresponding to the vehicle's location (e.g., GPS coordinates), time, travel time, speed and direction, rates of acceleration or braking, gas mileage, and specific instances of sudden acceleration, braking, swerving, and distance traveled.Sensor 311 also may detect and store data received from the vehicle's 310 internal systems, such as impact to the body of the vehicle, air bag deployment, headlights usage, brake light operation, door opening and closing, door locking and unlocking, cruise control usage, hazard lights usage, windshield wiper usage, horn usage, turn signal usage, seat belt usage, phone and radio usage within the vehicle, autonomous driving system usage, maintenance performed on the vehicle, and other data collected by the vehicle's computer systems, including the vehicle on-board diagnostic systems (OBD). -
Additional sensors 311 may detect and store the external driving conditions, for example, external temperature, rain, snow, light levels, and sun position for driver visibility. For example, external cameras andproximity sensors 311 may detect other nearby vehicles, vehicle spacing, traffic levels, road conditions, traffic obstructions, animals, cyclists, pedestrians, and other conditions that may factor into a driving data/behavior analysis.Sensor 311 also may detect and store data relating to moving violations and the observance of traffic signals and signs by thevehicle 310.Additional sensors 311 may detect and store data relating to the maintenance of thevehicle 310, such as the engine status, oil level, engine coolant temperature, odometer reading, the level of fuel in the fuel tank, engine revolutions per minute (RPMs), software upgrades, and/or tire pressure. -
Vehicles sensor 311 also may include cameras and/or proximity sensors capable of recording additional conditions inside or outside of thevehicle 310. For example, internal cameras may detect conditions such as the number of the passengers and the types of passengers (e.g. adults, children, teenagers, pets, etc.) in the vehicles, and potential sources of driver distraction within the vehicle (e.g., pets, phone usage, and unsecured objects in the vehicle).Sensor 311 also may be configured to collect data identifying a current driver from among a number of different possible drivers, for example, based on driver's seat and mirror positioning, driving times and routes, radio usage, etc. Voice/sound data along with directional data also may be used to determine a seating position within avehicle 310.Sensor 311 also may be configured to collect data relating to a driver's movements or the condition of a driver. For example,vehicle 310 may include sensors that monitor a driver's movements, such as the driver's eye position and/or head position, etc.Additional sensors 311 may collect data regarding the physical or mental state of the driver, such as fatigue or intoxication. The condition of the driver may be determined through the movements of the driver or through other sensors, for example, sensors that detect the content of alcohol in the air or blood alcohol content of the driver, such as a breathalyzer, along with other biometric sensors. -
Certain vehicle sensors 311 also may collect information regarding the driver's route choice, whether the driver follows a given route, and to classify the type of trip (e.g. commute, errand, new route, etc.) and type of driving (e.g., continuous driving, parking, stop-and-go traffic, etc.). In certain embodiments, sensors and/orcameras 311 may determine when and how often thevehicle 310 stays in a single lane or strays into other lane. A Global Positioning System (GPS), locational sensors positioned inside thevehicle 310, and/or locational sensors or devices external to thevehicle 310 may be used to determine the route, speed, lane position, road-type (e.g. highway, entrance/exit ramp, residential area, etc.) and other vehicle position/location data. - The data collected by
vehicle sensor 311 may be stored and/or analyzed within thevehicle 310, such as for example a drivinganalysis computer 314 integrated into the vehicle, and/or may be transmitted to one or more external devices. For example, as shown inFIG. 3 , sensor data may be transmitted via atelematics device 313 to one or more remote computing devices, such as personalmobile device 330,insurance system server 350, and/or other remote devices. - As shown in
FIG. 3 , the data collected byvehicle sensor 311 may be transmitted to aninsurance system server 350, personalmobile device 330, and/or additional external servers and devices viatelematics device 313.Telematics device 313 may be one or more computing devices containing many or all of the hardware/software components as thecomputing device 101 depicted inFIG. 1 . As discussed above, thetelematics device 313 may receive vehicle operation data and driving data fromvehicle sensor 311, and may transmit the data to one or more external computer systems (e.g.,insurance system server 350 of an insurance company, financial institution, or other entity) over a wireless transmission network.Telematics device 313 also may be configured to detect or determine additional types of data relating to real-time driving and the condition of thevehicle 310. Thetelematics device 313 also may store the type ofvehicle 310, for example, the make, model, trim (or sub-model), year, and/or engine specifications, as well as other information such as vehicle owner or driver information, insurance information, and financing information for thevehicle 310. - In the example shown in
FIG. 3 ,telematics device 313 may receive vehicle driving data fromvehicle sensor 311, and may transmit the data to aninsurance system server 350. However, in other examples, one or more of thevehicle sensors 311 or systems may be configured to receive and transmit data directly from or to aninsurance system server 350 without using a telematics device. For instance,telematics device 313 may be configured to receive and transmit data fromcertain vehicle sensors 311 or systems, while other sensors or systems may be configured to directly receive and/or transmit data to aninsurance system server 350 without using thetelematics device 313. Thus,telematics device 313 may be optional in certain embodiments. - The
system 300 inFIG. 3 also includes amobile device 330.Mobile devices 330 may be, for example, smartphones or other mobile phones, personal digital assistants (PDAs), tablet computers, and the like, and may include some or all of the elements described above with respect to thecomputing device 101. As shown in this example, some mobile devices in systems 300 (e.g., mobile device 330) may be configured to establish communication sessions with vehicle-based devices and various internal components ofvehicle 310 via wireless networks or wired connections (e.g., for docked devices), whereby suchmobile devices 330 may have secure access tointernal vehicle sensors 311 and other vehicle-based systems. However, in other examples, themobile device 330 might not connect to vehicle-based computing devices and internal components, but may operate independently by communicating withvehicle 310 via their standard communication interfaces (e.g.,telematics device 313, etc.), or might not connect at all tovehicle 310. -
Mobile device 330 may include a network interface 321, which may include various network interface hardware (e.g., adapters, modems, wireless transceivers, etc.) and software components to enablemobile device 330 to communicate withinsurance system server 350,vehicle 310, and various other external computing devices. One or more specialized software applications, such as a drivinganalysis application 334 and/or a risk unit basedinsurance application 335 may be stored in the memory of themobile device 330. The drivinganalysis application 334 and risk unit basedinsurance application 335 may be received via network interface 321 from theinsurance server 350,vehicle 310, or other application providers (e.g., application stores). As discussed below, the drivinganalysis application 334 and risk unit basedinsurance application 335 may or may not include various user interface screens, and may be configured to run as user-initiated applications or as background applications. The memory of themobile device 330 also may include databases configured to receive and store vehicle data, driving data, driving trip data, and the like, associated with one or more drivers and/or vehicles. - Like the vehicle-based computing devices in
vehicle 310,mobile device 330 also may include various components configured to generate and/or receive vehicle data, driver data, and driving data or other operational data. For example, using data from theGPS receiver 333, a drivinganalysis software application 334 may be able to identify starting and stopping points of driving trips, determine driving speeds, times, routes, and the like. Additional components ofmobile device 330 may be used to generate or receive driving data for the drivingdata analysis application 334 and/or risk unit basedinsurance application 335, such as an accelerometer, compass, and various cameras and proximity sensors. As discussed below, these and other mobile device components may be used to receive, store, and output various user/driver data, to identify starting and stopping points and other characteristics of driving trips, to determine various driving data such as speeds, driving routes and times, acceleration, braking, and turning data, and other driving conditions and behaviors. In some implementations, the drivinganalysis software application 334 may store and analyze the data from various mobile device components, and the risk unit basedinsurance application 335 may use this data, alone or in any combination with other components or devices (e.g., insurance server 350), to determine and present insurance offers, insurance costs, and the like. - When mobile computing devices within vehicles are used to detect vehicle driving data and/or to receive vehicle driving data from vehicle sensors, such
mobile computing devices 330 may store, analyze, and/or transmit the vehicle driver data (e.g., data identifying a current driver), driving data (e.g., speed data, acceleration, braking, and turning data, and any other vehicle sensor or operational data), and driving trip data (e.g., driving route, driving times, driving destinations, etc.), to one or more other devices. For example,mobile computing device 330 may transmit driver data, driving data and driving behaviors, and driving trip data directly to one ormore insurance servers 350, and thus may be used in conjunction with or instead oftelematics devices 313. Moreover, the processing components of themobile computing device 330 may be used to identify vehicle drivers and passengers, analyze vehicle driving data, analyze driving trips, determine parameters related to aspects of risk unit based insurance policies, and perform other related functions. Therefore, in certain embodiments,mobile computing device 330 may be used in conjunction with, or in place of, theinsurance system server 350. -
Vehicle 310 may include drivinganalysis computer 314, which may be separate computing devices or may be integrated into one or more other components within thevehicle 310, such as thetelematics device 313, autonomous driving systems, or the internal computing systems ofvehicle 310. As discussed above, drivinganalysis computers 314 also may be implemented by computing devices independent from thevehicle 310, such asmobile computing device 330 of the drivers or passengers, or one or more separate computer systems (e.g., a user's home or office computer). In any of these examples, the drivinganalysis computer 314 may contain some or all of the hardware/software components as thecomputing device 101 depicted inFIG. 1 . Further, in certain implementations, the functionality of the driving analysis computers, such as storing and analyzing driver data, vehicle data, driving data and driving behaviors, and determining, presenting, and implementing aspects of risk unit based insurance polies, may be performed in a centralinsurance system server 350 rather than by theindividual vehicle 310 or personalmobile device 330. In such implementations, thevehicle 310 and and/ormobile device 330, might only collect and transmit driver data, vehicle data, driving data, and the like to aninsurance server 350, and thus the vehicle-baseddriving analysis computer 314 may be optional. - The
system 300 also may include one or moreinsurance system servers 350, containing some or all of the hardware/software components as thecomputing device 101 depicted inFIG. 1 . Theinsurance system server 350 may include hardware, software, and network components to receive driver data, vehicle data, and vehicle operational data/driving data from one ormore vehicles 310,mobile devices 330, and other data sources. Theinsurance system server 350 may include aninsurance database 352 and risk unit basedinsurance system 351 to respectively store and analyze driver data, vehicle data, and driving data, etc., received fromvehicle 310,mobile device 330, and other data sources. In some examples, the risk unit basedinsurance system 351 may include many or all of the components of risk unit basedinsurance system 200 described with respect toFIG. 2 . - The
insurance system server 350 may initiate communication with and/or retrieve driver data, vehicle data, and driving data fromvehicle 310 wirelessly viatelematics device 313,mobile device 330, or by way of separate computing systems over one or more computer networks (e.g., the Internet). Additionally, theinsurance system server 350 may receive additional data from other third-party data sources, such as external traffic databases containing traffic data (e.g., amounts of traffic, average driving speed, traffic speed distribution, and numbers and types of accidents, etc.) at various times and locations, external weather databases containing weather data (e.g., rain, snow, sleet, and hail amounts, temperatures, wind, road conditions, visibility, etc.) at various times and locations, and other external data sources containing driving hazard data (e.g., road hazards, traffic accidents, downed trees, power outages, road construction zones, school zones, and natural disasters, etc.), route and navigation information, and insurance company databases containing insurance data (e.g., driver score, coverage amount, deductible amount, premium amount, insured status) for the vehicle, driver, and/or other nearby vehicles and drivers. - Data stored in the
insurance database 352 may be organized in any of several different manners. For example, a driver table indatabase 352 may contain all of the driver data for drivers associated with the insurance provider (e.g., driver personal information, insurance account information, demographic information, accident histories, risk factors, driving scores and driving logs, etc.), a vehicle table may contain all of the vehicle data for vehicles associated with the insurance provider (e.g., vehicle identifiers, makes, models, years, accident histories, maintenance histories, travel logs, estimated repair costs and overall values, etc.), and a driving trip table may store all of the driving trip data for drivers and vehicles associated with the insurance provider (e.g., driving trip driver, vehicle driven, trip time, starting and ending points, route driven, etc.). Other tables in thedatabase 352 may store additional data, including data types discussed above (e.g. traffic information, road-type and road condition information, weather data, insurance policy data, etc.). Additionally, one or more other databases of other insurance providers containing additional driver data and vehicle data may be accessed to retrieve such additional data. - The risk unit based
insurance system 351 within theinsurance system server 350 may be configured to retrieve data from thedatabase 352, or may receive driver data, vehicle data, and driving trip directly fromvehicle 310,mobile device 330, or other data sources, and may perform driving data analyses, determine insurance parameters for risk unit based insurance policies, and other related functions. The functions performed by the risk unit basedinsurance analysis system 351 may be performed by specialized hardware and/or software separate from the additional functionality of theinsurance system server 350. Such functions may be similar to those of drivinganalysis module 314 ofvehicle 310, and the driving analysis and risk unit basedinsurance applications mobile device 330, and further descriptions and examples of the algorithms, functions, and analyses that may be executed by the risk unit basedinsurance system 351 are described below, including in reference toFIGS. 4-9 . - In various examples, the driving data and driving trip analyses and/or risk unit based insurance determinations may be performed entirely in the
insurance system server 350, may be performed entirely in the vehicle-based drivinganalysis computing module 314, or may be performed entirely in the driving analysis and risk unit basedinsurance applications mobile device 330. In other examples, certain analyses of driver data, vehicle data, and driving trip data, and certain risk unit based insurance determinations may be performed by vehicle-based devices (e.g., within driving analysis module 314) or mobile device 330 (e.g., withinapplications 334 and 335), while other data analyses and risk unit based insurance determinations are performed by the risk unit basedinsurance system 351 at theinsurance system server 350. For example, a vehicle-baseddriving analysis computer 314, or the hardware and software components ofmobile device 330 may continuously receive and analyze driver data, vehicle data, driving trip data, and the like to determine certain events and characteristics (e.g., commencement of a driving trip, identification of a driver, determination of a driving route or intended destination, driving data and behaviors during driving trips, etc.), so that large amounts of data need not be transmitted to theinsurance system server 350. However, for example, after driver, vehicle, and/or driving trip is determined by a vehicle-based device and/or mobile device, corresponding information may be transmitted to theinsurance server 350 to perform insurance offer and cost determinations, determine consumption rate of risk units, generate one or more recommendations for reducing consumption rate, etc. which may be transmitted back to the vehicle-based device and/or personal mobile devices. -
FIG. 4 is a flow chart illustrating one example method of providing risk unit based insurance to a user, according to one or more aspects described herein. Instep 400, a risk unit is determined. As discussed above, the risk unit may be a common insurance unit that represents a cost to insure an average user for a predetermined period of time. For instance, the risk unit may be determined to be the cost to insure an average user for one week, one month, one year, etc. The risk unit may be used to provide insurance such that users may obtain risk unit based insurance policies in which, as the user, for example, operates a vehicle, the number of risk units in a risk unit account account is reduced based on a consumption rate determined for the user, trip, etc. These and other aspects are discussed more fully herein. - In
step 402, a request is received to obtain a risk unit based insurance policy. The request may be received from a user and may be received, in some examples, via a computing device (e.g., mobile device, or the like). The request may include information associated with the user, such as name, contact information, vehicle information including make, model, year, vehicle identification number, and the like. In some examples, the request to obtain the risk unit based insurance policy may include a level of coverage. For instance, similar to conventional insurance policies, a user may select from different levels of protection (e.g., whether to include collision coverage, amount of coverage for personal property, and the like). Similarly, a user may select a level of risk unit on which the policy is based. In one example, three levels may be used with the highest level of risk unit providing the most coverage and, in some instances, having the highest cost (e.g., cost per risk unit) to the user. A second level would provide lower coverage at a lower cost and the third level may provide a lowest level of coverage at a lowest cost. In another example, different levels of coverage selected may be reflected in the consumption rate of the units. For instance, the consumption rate may vary based on a level of coverage selected. Although different levels of coverage may be available to a user, the levels offered may meet minimum standards for insurance coverage, such as those required by the state in which the user lives, or the like. - Further, although three levels of risk units are described in the above example, more or fewer levels of risk unit, and, accordingly, insurance coverage, may be provided without departing from the invention.
- In
step 404, a risk unit based insurance policy is generated for the user and a risk unit account is created for the user. The risk unit account may be associated with the user or the vehicle. That is, the risk unit based insurance policy may provide coverage for the vehicle, regardless of which user is operating the vehicle, or may provide coverage to any vehicle being operated by a particular user. Thus, in some examples, the user or operator of a vehicle may be identified (e.g., upon initiation of vehicle operation) in order to determine whether or what type of coverage to provide. - In
step 406, a predetermined number of risk units is deposited into the account created. The predetermined number or risk units may be based on one or more policy parameters (e.g., term or length of policy), and/or one or more user preferences. - In
step 408, data associated with the driving behaviors of the user and/or environmental conditions in which the vehicle is operating are received. As discussed above, the data may be received from one or more sensors associated with the vehicle, as well as various other sources, such as traffic, weather, road condition, etc. sources. As discussed herein, received data may include speed, braking habits of the user or operator, type of road(s) being travelled, time of day, level of traffic, precipitation, and the like. - Based on the data received, a consumption rate of risk units in the risk unit account may be determined in
step 410. As discussed herein, the consumption rate may be higher based on various behaviors and/or conditions that are determined to include more risk to the user, vehicle, etc. For instance, if a user is driving at a rate of speed above the speed limit, the consumption rate may be higher than if the user was operating at a speed closer to the speed limit. In another example, the consumption rate may be determined to be lower if the user travels outside of rush hour, rather than during peak travel times. In still another example, the consumption rate may increase if data is received that it is raining or snowing on the route which the vehicle is travelling. As discussed above, consumption rate may also be based, at least in part, on traditional policy factors, such as driving experience, driving record, credit factors, coverages, deductibles, and the like. Data related to various behaviors and conditions and/or traditional policy data, may be combined to determine the consumption level in real-time or near real-time, as the user is operating the vehicle. Accordingly, the system may provide information associated with the consumption rate to the user. For instance, the vehicle display or mobile device of the user may display the current consumption rate. In another example, the display may include historical information associated with consumption rate for previous trips and/or a graphical display of previous and/or current consumption rates. -
FIG. 5 illustrates oneexample user interface 500 that may be provide to a user (e.g., via a vehicle display, mobile device, or other computing device) to provide information associated with the consumption rate. Theinterface 500 includesfields Field 506 indicates a date and time of the current trip. In some examples, an elapsed time of the current trip may also be displayed. -
Field 508 indicates that data is being received. As discussed herein, data associated with one or more sensors detecting driving behaviors of the user, environmental conditions, and the like, may be received by the system and used to determine a current consumption rate.Field 508 provides an indication that data is currently being received. In the event of a communication disruption,field 508 may indicate that data is not being received or that an error has occurred. In some example situations of that nature, the system may apply the most recently determined consumption rate until data communication is restored and more current data is received by the system. -
Field 510 provides the current calculated or determined consumption rate. As described herein, the consumption rate may be based on a variety of factors that may include driving behaviors, environmental conditions, and the like, as determined based on data received by the system.Field 512 provides a listing of historical consumption rate information that may be useful to the user in tracking consumption rate. - With further reference to
FIG. 4 , instep 412, a balance of risk units in the risk unit account is reduced based on the consumption rate determined instep 410. As the balance in the risk unit account is reduced, the account may include a predetermined threshold below which the user may be notified that the balance of risk units is low or in need of replenishment. For instance, instep 414, a determination is made as to whether a balance of risk units in the risk unit account is below a predetermined threshold. The predetermined threshold may be based on one or more policy parameters, may meet a government or other regulatory body standards, or may be determined by the user or insurance provider. In some examples, the threshold may be a percentage of a number of risk units obtained with the policy (e.g., a percentage of the full account balance). For instance, the threshold may be 10%, 15% or any other percentage of the full number of risk units obtained with the policy. In other examples, the threshold may be a number of risk units. For instance, the threshold may be 50, 100, or any other number of risk units. - If, in
step 414, the balance in the risk unit account is at or above the predetermined threshold, the process may return to step 408 to continue receiving data and determining consumption rate. If, instep 414, the balance is below the predetermined threshold, one or more refill options may be provided to the user instep 416. Refill options may include providing a notification to the user of the current balance and/or providing options for automatic refill, user requested refill, cancellation of policy, purchase of a new policy and associated risk units, and the like. Once the refill options are presented, the system may return to step 408 to continue receiving data, etc. -
FIG. 6 illustrates an example method of refilling risk units according to one or more aspects described herein. Instep 600, similar to step 414 inFIG. 4 , a determination is made as to whether a balance of risk units in a risk unit account is below a predetermined threshold. If not, the system may return to processes in which data is received, consumption rate is determined, etc., such asstep 408 inFIG. 4 . If, instep 600, the balance is below the threshold, a notification is transmitted to the user instep 602. The notification may include an indication that the risk unit account is below the threshold and/or may provide instructions for refill of the account. - In
step 604, a determination is made as to whether the account is set up for automatic refill. That is, the system may determine whether the user has preselected an option to automatically refill a balance in the account (e.g., by automatically purchasing additional risk units using pre-stored payment information). If so, the system may automatically purchase the predetermined number of units, charge any cost to the pre-stored payment information (e.g. credit card information, account information, debit card information, etc.), and deposit the risk units purchased in the account instep 606. - If, in
step 604, it is determined that the account is not set for automatic refill, instep 608, the user may respond to the notification transmitted instep 602 with a request to refill the account balance. The request may include a number of units to purchase, payment information, risk unit account information, policy information, and the like. Instep 610, the designated number of risk units may be purchased and deposited in the risk unit account. -
FIGS. 7A-7D illustrate example user interfaces 700 a-700 d that may be used to carry out refill or replenishment of risk units in a risk unit account. Although interfaces 700 a-700 d are shown inFIGS. 7A-7D as being displayed on a mobile device, the interfaces provided may be displayed on various different types of computing devices, including, for instance, a vehicle display, laptop or desktop computing device, tablet computing device, and the like. -
FIG. 7A illustratesinterface 700 a in which a notification is provided to the user. Thenotification 700 a indicates that the risk unit account is below the minimum threshold and provides options for the user to proceed with refilling the account balance now or requesting that the system remind the user later. Selection of the option to remind the user later may automatically prompt the notification to be displayed again at a predetermined time (e.g., each day, each hour, 48 hours from selection of remind me later option, etc.) or upon any continued consumption of the risk units. Accordingly, as the balance in the risk unit account continues to be reduced, additional notifications may be provided to the user. In some examples, determination of the balance being below a predetermined level (e.g., below the level for refill notification) may result in various actions being taken with respect to the vehicle. For instance, the system may cause the headlights to flash or horn to blare while driving, may prevent the vehicle from starting if there is an insufficient number of risk units in the account, or the like. - Upon selection of yes option in 700 a,
interface 700 b shown inFIG. 7B , or similar interface, may be displayed in which the user may input one or more risk unit account details, such as an account number and/or name associated with the account. In some examples, this information may automatically be prefilled based on the mobile device being associated with the user, vehicle, and/or account. The user may select continue option to prompt display ofinterface 700 c inFIG. 7C , or similar interface, which provides fields in which the user may enter payment information. Information such as a credit card number, expiration date, name on the card, and the like, may be provided by the user. Although credit card information is provided as example payment information inFIG. 7C , various other payment types may be used, such as electronic funds transfer, debit card, pre-paid debit or credit card, gift card, or the like. - Upon selection of continue option,
interface 700 d inFIG. 7D , or similar interface, may be provided to the user.Interface 700 d includes a field in which the user may indicate a number of risk units to purchase. In some examples, the risk units may be a predetermined number of units based on one or more policy parameters. In other examples, the number of units available for purchase may be determined by the user and input intointerface 700 d. -
User interface 700 d further includes an option to select automatic refill. Indication of “yes” to automatic refill prompts the system to store the payment information provided ininterface 700 c and, upon the system determining that the balance of risk units is below the predetermined threshold (e.g.,step 414 inFIG. 4 ,step 600 inFIG. 6 ) the system may automatically purchase the predetermined number of risk units, charge the associated cost to the pre-stored payment information, and deposit the purchased risk units in the risk unit account, thereby effectively automatically renewing insurance for the user. -
FIG. 8 illustrates one example method of determining proposed recommendations for reducing risk unit consumption rate according to one or more aspects described herein. Instep 800, data associated with driving behaviors of the user and/or environmental conditions may be received. As discussed above, data may include speed, braking habits, level of precipitation, road conditions, time of day, traffic level, and the like. Based on the received data, a risk unit consumption rate may be determined instep 802. In some examples, the risk unit consumption rate may also be based on one or more factors associated with the user. For instance, accident history, length of time as licensed driver, credit rating, policy limits, policy deductibles, vehicle features, and the like, may, in some examples, be used in determining a risk unit consumption rate. - In
step 804, one or more driving behavior or environmental condition modifications may be identified that may aid in reducing the risk unit consumption rate. For instance, if a user is driving on a road that is known as being in poor condition (e.g., potholes, poor lane markings, etc.), the system may indicate that, by changing the route to the destination, the user may reduce his or her consumption rate. In some examples, a recommended modification identified to aid in reducing risk unit consumption rate may include modifications to more traditional policy factors, such as policy coverage, deductibles and/or limits, vehicle operation and/or maintenance, vehicle features, and the like. - In some examples, the modifications to reduce consumption rate may be identified by comparing received data with a database storing known conditions, behaviors, roads, environmental factors, and the like, that are associated with a reduced consumption rate. The database may store information such as historical travel information, accident history information, accident probability information, etc. that may be collected based on insurance data received by the insurance provider. For instance, the data associated with current speed may be compared to a posted speed limit for the current road (as stored in the database or received from an outside source) and, if the current speed is higher than the posted speed limit, a modification to slow the speed of the vehicle in order to reduce consumption rate may be identified.
- In another example, the received data may indicate that the current road is congested or is experiencing heavy traffic. The system may compare the current traffic information to levels of traffic that would result in a reduced consumption rate and may recommend modifying the route being travelled. In some examples, the suggested modification may include a suggested alternate route.
- Various other driving behavior and/or environmental condition modifications may be identified based on the received data and/or historical data, stored data, and the like. The examples described herein are merely some examples and are not intended to limit the modifications or types of modifications identified by the system. Rather, various other modifications may be identified without departing from the invention.
- In
step 806, the identified modifications may be display to the user. For instance, one or more of the recommended modifications to reduce consumption rate may be displayed to the user via a computing device, such as a mobile device, vehicle display, or the like. -
FIG. 9 illustrates oneexample user interface 900 displaying recommended modifications for reducing consumption rate according to one or more aspects described herein. The interface includesregion 902 in which the current risk unit consumption is provided to the user. Theinterface 900 further includesregion 904 in which one or more suggested driving modifications are provided to the user. As data is received by the system from one or more vehicle sensors, the risk unit consumption rate may change and the revised consumption rate may then be displayed. In some examples, audio may accompany the notification. For instance, the notification may include an audio portion in which the text of the notification is stated to the user, thereby reducing the user's need to read the notification. - As discussed herein, the risk unit based insurance policies described herein may include other types of usage-based insurance policies. For instance, one or more usage-based insurance policies may include one or more of the aspects or features discussed above with respect to the risk unit based insurance policies. Usage-based policies may include a premium paid by a user. As the user operates a vehicle, the amount of the premium is reduced by a cost associated with operation of the vehicle. The cost may be based on a variety of factors, including duration of travel, distance of travel, driving behaviors, environmental conditions, and the like, as will be discussed more fully herein.
-
FIG. 10 is a schematic diagram of another illustrative usage-basedinsurance system 1000. Thesystem 1000 shown inFIG. 10 may be similar to thesystem 200 shown inFIG. 2 and, although not shown inFIG. 10 , may include some or all of the components described above with respect toFIG. 2 in addition to (or in lieu of) some or all of the components shown inFIG. 10 . - The usage-based
insurance system 1000 may be associated with, internal to, operated by, or the like, anentity 1001, such as an insurance provider. In some examples, the entity may be one of various other types of entities, such as a government entity, corporation or business, university, or the like. Various examples described herein will be discussed in the context of an insurance provider. However, nothing in the specification should be viewed as limiting use of the systems, methods, arrangements, etc. described herein to use only by an insurance provider. - The usage-based
insurance system 1000 may include one or more modules that may include hardware and/or software configured to perform various functions within thesystem 1000. The one or more modules may be separate, physical devices or, in other examples, one or more modules may be part of the same physical device. As indicated above, thesystem 1000 may include various modules similar to those discussed above with respect tosystem 200 inFIG. 2 (even if not shown inFIG. 10 ) in addition to those modules shown inFIG. 10 . - For instance, the
system 1000 may include ausage cost module 1002 configured to determine a cost or amount of funds to charge a driver (or a vehicle) for operation. For instance, theusage cost module 1002 may include hardware and/or software configured to perform various functions, including receiving insurance policy information, such as frompolicy module 1004. Thepolicy module 1004 may include information such as insurance data frominsurance data store 1006, locality or environmental/contextual data fromlocality data store 1008, as well as other data (from data stores not shown that may be internal to theentity 1001 or external to the entity 1001). Thepolicy module 1004 may transmit this information to theusage cost module 1002 and theusage cost module 1002 may determine, based on the received data, the cost for a particular driver to operate a vehicle or for a particular vehicle to operate. That is, theusage cost module 1002 may determine a cost per day and/or a cost per mile for the user and/or the vehicle. This information may be based on various factors, including driving history, vehicle specifications, historical driving data (if available), and the like. - For instance, a driver with a new policy may receive usage cost information determined based on accident history and vehicle specifications. This information may be used to determine a cost per day and/or per mile for the driver and/or the vehicle. This cost per day and/or cost per mile may be used to determine a cost for one or more driving trips performed by the user. However, in some arrangements, these costs may be used until additional information has been collected for the driver and/or the vehicle. For instance, sensors 1010 a-1010 c may be used to collect vehicle information. Similar to sensors 216 a-216 c, sensors 1010 a-1010 c may be used to obtain data that may be used to determine a revised cost per day and/or cost per mile for the user and/or the vehicle. For instance, the one or more sensors 1010 a-1010 c may include sensors to detect driving behaviors of the user, such as hard braking, speeding, and the like. In another example, one or more sensors may be used to detect environmental conditions such as precipitation, humidity, cloud cover, or the like. In still another example, one or more sensors may be used to determine road conditions or to obtain information from outside sources (e.g., external databases, or the like) regarding traffic conditions, types of road (e.g., two-lane road, four-lane road), speed limit of the road, or the like. The data from one or more sensors 1010 a-1010 c, which may include data from combinations of different types of sensors and may be used by the
usage cost module 214 to determine a revised cost per day and/or cost per mile for the user. - As mentioned above, the usage-based
insurance system 1000 may further include apolicy module 1004. Thepolicy module 1004 that may generate and/or store insurance policies and policy information, as well as insurance policy factors, such as vehicle information, driving record/experience, policy limits, deductibles, etc. That is, a user may be insured through a policy that provides, for a period of time, coverage for a vehicle. The policy may be a usage-based policy (e.g., rather than a traditional policy) in which the user may pay a premium at the start of the policy period. The premium may be held in an account associated with the user and/or the vehicle in, for instance,account module 1012. The account module may store the pre-paid premium and, as the user operates the vehicle, the premium held in the account may be reduced by an amount associated with a cost of a trip (e.g., based on the determined cost per day and/or cost per mile). Reducing the premium may include transferring funds from the account of the user in the account module 1012 (which may be an account held by the entity 1001) to another account (e.g., an account of the entity 1001). In some examples, the funds may be transferred from the account in theaccount module 1012 to the second account of the entity as each trip occurs, at the end of each day, or the like. In other examples, the trip cost may be stored for each trip and the funds may be transferred in a batch process (e.g., weekly, monthly, or the like the funds may be deducted from the premium or remaining balance of the premium. - The
account module 1012 may further include hardware and/or software configured to determine when a balance (e.g., premium balance) meets a predetermined threshold level. For instance, as the user operates the vehicle, the balance of the premium may be reduced on a per trip basis, daily, in a batch process, or the like (as discussed above). The system may identify a minimum threshold balance of the premium for the account. Once the account in theaccount module 1012 reaches the minimum threshold balance, the system may notify the user. Notification to the user may be performed in various ways discussed herein. In addition, notification to the user may include modifying operation of the vehicle in order to provide an indication. That is, thesystem 1000 may transmit a signal to the vehicle to modify operation of the vehicle as a notification to the user. Modifying operation of the vehicle may include causing the headlights to flash, causing the horn to beep, and/or preventing the vehicle from starting or operating. - Additionally or alternatively, the
account module 1012 may attempt to automatically replenish a balance in the account. That is, thesystem 1000 may store payment account information for the user. The payment account information may include a credit card, bank account (e.g., checking account, savings account, etc.), or various other types of payment accounts. The payment account information may be stored in, for instance, theinsurance database 1006,policy module 1004, or the like. Theaccount module 1012 may attempt to enact an automatic transfer of funds (e.g., electronic transfer of funds) from the payment account to the account in theaccount module 1012. If successful, the account may be replenished and the coverage may remain in effect. If the attempt is not successful, the system may notify the user, make another attempt after a predetermined time has elapsed, or the like. In some examples, if one or more attempts to replenish the account are unsuccessful, the policy may be cancelled. - As discussed herein, various types of information may be displayed to the user via one or more computing devices, such as devices 1014 a-1014 f For instance, a remaining balance of a premium, notifications as to a low balance, cost per day, cost per mile, trip data, patterns of driving behaviors, trends in trip costs, as well as policy information, user information, and the like, may be displayed to the user via one or more user interfaces (similar to arrangements discussed above) generated by and/or provided via an application (e.g., an application downloaded or otherwise provided on the device 1014 a-1014 f). The devices may include
smartphone 1014 a, personal digital assistant (PDA) 1014 b,tablet 1014 c,cell phone 1014 d, orother computing device 1014 e. In some examples, the information may be displayed to a user on avehicle display 1014 f. -
FIG. 11 is a diagram of an illustrativedriving analysis system 1100 including additional aspects of the usage-basedinsurance system 1000 shown inFIG. 10 and/or implementing the usage-basedinsurance system 1000 ofFIG. 10 . Thesystem 1100 shown inFIG. 11 may include one or more devices, components, or the like, similar to thesystem 300 shown inFIG. 3 , as well as (e.g., in addition to or in lieu of) the devices, components, and arrangements shown inFIG. 11 , without departing from the invention. The system includes avehicle 1110, a personalmobile device 1130, aninsurance system server 1150, and additional related components. As discussed below, the components of thesystem 1100, individually or using communication and collaborative interaction, may determine, present, and implement various types of usage-based insurance to customers, including providing or facilitating purchase of a usage-based insurance policy and/or associated premiums and premium payments, determining various costs associated with the usage-based insurance policy (e.g., cost per day, cost per mile, etc.), analyzing driving data to modify costs associated with the usage-based insurance policy, communicating various information to the user (e.g., trip data, historical trends, and the like), etc. To perform such features, the components shown inFIG. 11 each may be implemented in hardware, software, or a combination of the two. Additionally, each component of thesystem 1100 may include a computing device (or system) having some or all of the structural components described above forcomputing device 101. - Various aspects of
system 1100 may be similar to aspects ofsystem 300. For instance,vehicle 1110 in thesystem 1100 may be, for example, an automobile, a motorcycle, a scooter, a bus, a recreational vehicle, a boat, or other vehicle for which vehicle data, location data, driver data (or operator data), operational data and/or other driving data (e.g., location data, time data, weather data, etc.) may be collected and analyzed. Thevehicle 1110 includes vehicle operation sensor 1111 (similar to one or more of sensors 1010 a-1010 c ofFIG. 10 ) capable of detecting and recording various conditions at the vehicle and operational parameters of the vehicle. For example,sensor 1111 may detect and store data corresponding to the vehicle's location (e.g., GPS coordinates), time, travel time, speed and direction, rates of acceleration or braking (e.g., hard braking), gas mileage, and specific instances of sudden acceleration, braking, swerving, and distance traveled.Sensor 1111 also may detect and store data received from the vehicle's 1110 internal systems, such as impact to the body of the vehicle, air bag deployment, headlights usage, brake light operation, door opening and closing, door locking and unlocking, cruise control usage, hazard lights usage, windshield wiper usage, horn usage, turn signal usage, seat belt usage, phone and radio usage within the vehicle, autonomous driving system usage, maintenance performed on the vehicle, and other data collected by the vehicle's computer systems (e.g., 1117), including the vehicle on-board diagnostic systems (OBD). -
Additional sensors 1111 may detect and store the external driving conditions, for example, external temperature, rain, snow, light levels, and sun position for driver visibility. For example, external cameras andproximity sensors 1111 may detect other nearby vehicles, vehicle spacing, traffic levels, road conditions, traffic obstructions, animals, cyclists, pedestrians, and other conditions that may factor into a driving data/behavior analysis.Sensor 1111 also may detect and store data relating to moving violations and the observance of traffic signals and signs by thevehicle 1110.Additional sensors 1111 may detect and store data relating to the maintenance of thevehicle 1110, such as the engine status, oil level, engine coolant temperature, odometer reading, the level of fuel in the fuel tank, engine revolutions per minute (RPMs), software upgrades, and/or tire pressure. -
Vehicles sensor 1111 also may include cameras and/or proximity sensors capable of recording additional conditions inside or outside of thevehicle 1110. For example, internal cameras may detect conditions such as the number of the passengers and the types of passengers (e.g. adults, children, teenagers, pets, etc.) in the vehicles, and potential sources of driver distraction within the vehicle (e.g., pets, phone usage, and unsecured objects in the vehicle).Sensor 1111 also may be configured to collect data identifying a current driver from among a number of different possible drivers, for example, based on driver's seat and mirror positioning, driving times and routes, radio usage, etc. Voice/sound data along with directional data also may be used to determine a seating position within avehicle 1110.Sensor 1111 also may be configured to collect data relating to a driver's movements or the condition of a driver. For example,vehicle 1110 may include sensors that monitor a driver's movements, such as the driver's eye position and/or head position, etc.Additional sensors 1111 may collect data regarding the physical or mental state of the driver, such as fatigue or intoxication. The condition of the driver may be determined through the movements of the driver or through other sensors, for example, sensors that detect the content of alcohol in the air or blood alcohol content of the driver, such as a breathalyzer, along with other biometric sensors. -
Certain vehicle sensors 1111 also may collect information regarding the driver's route choice, whether the driver follows a given route, and to classify the type of trip (e.g. commute, errand, new route, etc.) and type of driving (e.g., continuous driving, parking, stop-and-go traffic, etc.). In certain embodiments, sensors and/orcameras 1111 may determine when and how often thevehicle 1110 stays in a single lane or strays into other lane. A Global Positioning System (GPS), locational sensors positioned inside thevehicle 1110, and/or locational sensors or devices external to thevehicle 1110 may be used to determine the route, speed, lane position, road-type (e.g. highway, entrance/exit ramp, residential area, etc.) and other vehicle position/location data. - The data collected by
vehicle sensor 1111 may be stored and/or analyzed within thevehicle 1110, such as for example a drivinganalysis computer 1114 integrated into the vehicle,vehicle control computer 1117, and/or may be transmitted to one or more external devices. For example, as shown inFIG. 11 , sensor data may be transmitted via atelematics device 1113 to one or more remote computing devices, such as personalmobile device 1130,insurance system server 1150, and/or other remote devices. - As shown in
FIG. 11 , the data collected byvehicle sensor 1111 may be transmitted to aninsurance system server 1150, personalmobile device 1130, and/or additional external servers and devices viatelematics device 1113.Telematics device 1113 may be one or more computing devices containing many or all of the hardware/software components as thecomputing device 101 depicted inFIG. 1 . As discussed above, thetelematics device 1113 may receive vehicle operation data and driving data fromvehicle sensor 1111, and may transmit the data to one or more external computer systems (e.g.,insurance system server 1150 of an insurance company, financial institution, or other entity) over a wireless transmission network.Telematics device 1113 also may be configured to detect or determine additional types of data relating to real-time driving and the condition of thevehicle 1110. - In the example shown in
FIG. 11 ,telematics device 1113 may receive vehicle driving data fromvehicle sensor 1111, and may transmit the data to aninsurance system server 1150. However, in other examples, one or more of thevehicle sensors 1111 or systems may be configured to receive and transmit data directly from or to aninsurance system server 1150 without using a telematics device. For instance,telematics device 1113 may be configured to receive and transmit data fromcertain vehicle sensors 1111 or systems, while other sensors or systems may be configured to directly receive and/or transmit data to aninsurance system server 1150 without using thetelematics device 1113. Thus,telematics device 1113 may be optional in certain embodiments. In other examples, as indicated above, the received sensor data may be analyzed by one or more computing devices within the vehicle, such as drivinganalysis device 1114 and/orvehicle control computer 1117. - The
system 1100 inFIG. 11 also includes amobile device 1130.Mobile devices 1130 may be, for example, smartphones or other mobile phones, personal digital assistants (PDAs), tablet computers, and the like, and may include some or all of the elements described above with respect to thecomputing device 101. As shown in this example, some mobile devices in systems 1100 (e.g., mobile device 1130) may be configured to establish communication sessions with vehicle-based devices and various internal components ofvehicle 1110 via wireless networks or wired connections (e.g., for docked devices), whereby suchmobile devices 1130 may have secure access tointernal vehicle sensors 1111 and other vehicle-based systems. However, in other examples, themobile device 1130 might not connect to vehicle-based computing devices and internal components, but may operate independently by communicating withvehicle 1110 via their standard communication interfaces (e.g.,telematics device 1113, etc.), or might not connect at all tovehicle 1110. -
Mobile device 1130 may include a network interface 1121, which may include various network interface hardware (e.g., adapters, modems, wireless transceivers, etc.) and software components to enablemobile device 1130 to communicate withinsurance system server 1150,vehicle 1110, and various other external computing devices. One or more specialized software applications, such as a drivinganalysis application 1134 and/or a usage-basedinsurance application 1135 may be stored in the memory of the mobile device 1130 (e.g., may be downloaded or otherwise provided to the device and stored). The drivinganalysis application 1134 and usage-basedinsurance application 1135 may be received via network interface 1121 from theinsurance server 1150,vehicle 1110, or other application providers (e.g., application stores). As discussed below, the drivinganalysis application 1134 and risk unit basedinsurance application 1135 may or may not include various user interface screens, and may be configured to run as user-initiated applications or as background applications. The memory of themobile device 1130 also may include databases configured to receive and store vehicle data, driving data, driving trip data, and the like, associated with one or more drivers and/or vehicles. - Like the vehicle-based computing devices in
vehicle 1110,mobile device 1130 also may include various components configured to generate and/or receive vehicle data, driver data, and driving data or other operational data. For example, using data from theGPS receiver 1133, a drivinganalysis software application 1134 may be able to identify starting and stopping points of driving trips, determine driving speeds, times, routes, and the like. Additional components ofmobile device 1130 may be used to generate or receive driving data for the drivingdata analysis application 1134 and/or usage-basedinsurance application 1135, such as an accelerometer, compass, and various cameras and proximity sensors. As discussed below, these and other mobile device components may be used to receive, store, and output various user/driver data, to identify starting and stopping points and other characteristics of driving trips, to determine various driving data such as speeds, driving routes and times, acceleration, braking, and turning data, and other driving conditions and behaviors. In some implementations, the drivinganalysis software application 1134 may store and analyze the data from various mobile device components, and the usage-basedinsurance application 1135 may use this data, alone or in any combination with other components or devices (e.g., insurance server 1150), to determine and present insurance offers, insurance costs (e.g., cost per day, cost per mile, revised cost per day, revised cost per mile, etc.), and the like. - When mobile computing devices within vehicles are used to detect vehicle driving data and/or to receive vehicle driving data from vehicle sensors, such
mobile computing devices 1130 may store, analyze, and/or transmit the vehicle driver data (e.g., data identifying a current driver), driving data (e.g., speed data, acceleration, braking, and turning data, and any other vehicle sensor or operational data), and driving trip data (e.g., driving route, driving times, driving destinations, etc.), to one or more other devices. For example,mobile computing device 1130 may transmit driver data, driving data and driving behaviors, and driving trip data directly to one ormore insurance servers 1150, and thus may be used in conjunction with or instead oftelematics devices 1113. Moreover, the processing components of themobile computing device 1130 may be used to identify vehicle drivers and passengers, analyze vehicle driving data, analyze driving trips, determine parameters related to aspects of risk unit based insurance policies, and perform other related functions. Therefore, in certain embodiments,mobile computing device 1130 may be used in conjunction with, or in place of, theinsurance system server 1150. -
Vehicle 1110 may include drivinganalysis computer 1114, which may be separate computing devices or may be integrated into one or more other components within thevehicle 1110, such as thetelematics device 1113, autonomous driving systems, or theinternal computing systems 1117 ofvehicle 1110. As discussed above, drivinganalysis computers 1114 also may be implemented by computing devices independent from thevehicle 1110, such asmobile computing device 1130 of the drivers or passengers, or one or more separate computer systems (e.g., a user's home or office computer). In any of these examples, the drivinganalysis computer 1114 may contain some or all of the hardware/software components as thecomputing device 101 depicted inFIG. 1 . Further, in certain implementations, the functionality of the driving analysis computers, such as storing and analyzing driver data, vehicle data, driving data and driving behaviors, and determining, presenting, and implementing aspects of usage-based insurance polies, may be performed in a centralinsurance system server 1150 rather than by theindividual vehicle 1110 or personalmobile device 1130. In such implementations, thevehicle 1110 and and/ormobile device 1130, might only collect and transmit driver data, vehicle data, driving data, and the like to aninsurance server 1150, and thus the vehicle-baseddriving analysis computer 1114 may be optional. - The
system 1100 also may include one or moreinsurance system servers 1150, containing some or all of the hardware/software components as thecomputing device 101 depicted inFIG. 1 . Theinsurance system server 1150 may include hardware, software, and network components to receive driver data, vehicle data, and vehicle operational data/driving data from one ormore vehicles 1110,mobile devices 1130, and other data sources. Theinsurance system server 1150 may include aninsurance database 1152 and usage-basedinsurance system 1151 to respectively store and analyze driver data, vehicle data, and driving data, etc., received fromvehicle 1110,mobile device 1130, and other data sources. In some examples, the usage-basedinsurance system 1151 may include many or all of the components of usage-basedinsurance system 1000 described with respect toFIG. 10 . - The
insurance system server 1150 may initiate communication with and/or retrieve driver data, vehicle data, and driving data fromvehicle 1110 wirelessly viatelematics device 1113,mobile device 1130, or by way of separate computing systems over one or more computer networks (e.g., the Internet). Additionally, theinsurance system server 1150 may receive additional data from other third-party data sources, such as external traffic databases containing traffic data (e.g., amounts of traffic, average driving speed, traffic speed distribution, and numbers and types of accidents, etc.) at various times and locations, external weather databases containing weather data (e.g., rain, snow, sleet, and hail amounts, temperatures, wind, road conditions, visibility, etc.) at various times and locations, and other external data sources containing driving hazard data (e.g., road hazards, traffic accidents, downed trees, power outages, road construction zones, school zones, and natural disasters, etc.), route and navigation information, and insurance company databases containing insurance data (e.g., driver score, coverage amount, deductible amount, premium amount, insured status) for the vehicle, driver, and/or other nearby vehicles and drivers. - Data stored in the
insurance database 1152 may be organized in any of several different manners. For example, a driver table indatabase 1152 may contain all of the driver data for drivers associated with the insurance provider (e.g., driver personal information, insurance account information, demographic information, accident histories, risk factors, driving scores and driving logs, etc.), a vehicle table may contain all of the vehicle data for vehicles associated with the insurance provider (e.g., vehicle identifiers, makes, models, years, accident histories, maintenance histories, travel logs, estimated repair costs and overall values, etc.), and a driving trip table may store all of the driving trip data for drivers and vehicles associated with the insurance provider (e.g., driving trip driver, vehicle driven, trip time, starting and ending points, route driven, etc.). Other tables in thedatabase 1152 may store additional data, including data types discussed above (e.g. traffic information, road-type and road condition information, weather data, insurance policy data, etc.). Additionally, one or more other databases of other insurance providers containing additional driver data and vehicle data may be accessed to retrieve such additional data. - The usage-based
insurance system 1151 within theinsurance system server 1150 may be configured to retrieve data from thedatabase 1152, or may receive driver data, vehicle data, and driving trip directly fromvehicle 1110,mobile device 1130, or other data sources, and may perform driving data analyses, determine insurance parameters for usage-based insurance policies, and other related functions. The functions performed by the usage-basedinsurance analysis system 1151 may be performed by specialized hardware and/or software separate from the additional functionality of theinsurance system server 1150. Such functions may be similar to those of drivinganalysis module 1114 ofvehicle 1110, and the driving analysis and usage-basedinsurance applications mobile device 1130, and further descriptions and examples of the algorithms, functions, and analyses that may be executed by the usage-basedinsurance system 1151 are described more fully below. - For instance,
FIG. 12 illustrates one example method of determining a cost of a trip associated with a usage-based insurance policy and deducting the cost of the trip from a premium associated with the policy according to one or more aspects described herein. It should be noted that although various steps of the process are shown in order inFIG. 12 , one or more steps of the process may be performed in a different order, or not performed, without departing from the invention. - In
step 1200, a premium amount is received for an insurance policy. As discussed above, the premium (e.g., an amount of funds) may be stored in an account associated with the user (e.g., driver) or vehicle and held by the entity (e.g., insurance provider). The funds may be held in the account until a portion of the premium funds are used (e.g., based on operation of the vehicle). At that time (or in a batch process) the cost of one or more trips may be deducted from the premium and transferred from the account to another account of the entity. - The premium may be based on various factors, as described herein. For instance, driving history, credit rating, location, and various other factors may be used to determine an amount of the premium for the usage-based insurance policy. In
step 1202, a first cost per day and/or a first cost per mile associated with the policy may be determined. Instep 1202, the cost per day and/or cost per mile may be determined based on factors such as driving history, accident history, location, credit rating, and the like. These costs or rates may be used to determine a cost of a driving trip performed by the vehicle associated with the usage-based insurance policy, as is discussed more fully herein. - In
step 1204, driving trip data may be received for a first driving trip. The driving trip data may be received from one or more sensors (e.g., sensors 1010 a-1010 c) associated with the system and may be received by, for instance, the usage cost module. The driving trip data may include data associated with start time of the first driving trip, end time of the first driving trip, duration of driving, distance driven, location, braking, swerving, acceleration, deceleration, and the like. Instep 1206, contextual or environmental information (e.g. from sensors 1010 a-1010 c and/or locality database 1008) associated with the first driving trip may be received. Contextual or environmental information may include time of day, weather conditions, precipitation conditions, traffic volumes, and the like. In some examples, the driving trip data may include the contextual or environmental information (e.g., all desired data may be received instep 1204 and the process may proceed fromstep 1204 to 1208). - In
step 1208, the system may determine a cost of the driving trip. For instance, the system may determine the cost of the first driving trip based on, for example, the cost per day and the cost per mile determined instep 1202. This information may be used in conjunction with the distance and time of the trip to determine a cost of the first trip. Instep 1210, this cost of the first trip may then be deducted from the premium provided by the user instep 1200 and stored in the account module. For instance, a balance of the premium in the account may be reduced by the cost of the trip. - In
step 1212, a determination may be made as to whether, after reducing the premium by the cost of the trip, a balance of the premium is below a predetermined threshold. If so, the system may automatically attempt to transfer additional funds into the account instep 1214. That is, the user may store payment account information in the account module. This payment account information may be used to access the payment account and attempt to transfer a predetermined amount of funds into the account of the user. The predetermined amount of funds may, in some examples, be a same amount as the initial premium amount. In other examples, the predetermined amount may be another amount determined by the user or the entity. - If, in
step 1212, the premium balance is not below the predetermined threshold, or after the system has attempted to automatically transfer funds instep 1214, the system may proceed to step 1216 in which a second or revised rate or cost per day and a second or revised rate or cost per mile may be determined. The second cost per day and/or cost per mile may be determined based on factors similar to those used to determine the first cost per day and the first cost per mile, as well as based on the driving data and/or contextual environmental data received. For instance, if a user has several instances of hard braking in the received driving data, the cost per rate and/or cost per mile may be increased to account for the additional risk associated with this driving behavior. In another example, if the driver was operating the vehicle at night and/or in heavy precipitation, the system may increase the cost per day and/or cost per mile to account for this increased risk. - The system may then return to step 1204 to receive driving data for a second or subsequent trip and may continue the process.
-
FIG. 13 illustrates one example method of attempting to automatically transfer funds from a payment account to a user or vehicle account according to one or more examples discussed herein. For instance, the process shown inFIG. 13 may occur simultaneously with or immediately followingstep 1214, in some examples. - In
step 1300, the system may attempt to automatically transfer funds from the identified payment account of the user to the user account stored in the account module. This process may, in some examples, be performed by the account module. Instep 1302, a determination may be made as to whether the attempted transfer was successful. For instance, the system may determine whether there were sufficient funds in the payment account, whether a credit card number provided was still valid, etc. If the attempted transfer was successful, the funds may be transferred from the payment account to the user account instep 1304. - If, in
step 1302, the attempted transfer was not successful, a notification may be provided to the user instep 1306. As discussed herein, providing a notification may include displaying an indication to the user (e.g., on a display of the on-board vehicle computing device, on a mobile device of the user, or the like) indicating that the user's account balance is below the threshold, that an attempt to replenish the account was made and was not successful. In some examples, providing a notification may include modifying operation of the vehicle. For instance, the system may provide an instruction or signal to, for instance, thevehicle control computer 1117, to modify operation of the vehicle or one or more systems of the vehicle. For instance, the instruction may include causing the vehicle to flash the headlights, engage the horn, and/or may prevent the vehicle from starting or operating in a normal fashion. - In
step 1308, a determination may be made as to whether, after a predetermined time, the desired funds were received by the user account. For instance, the system may wait a predetermined time, such as one day, three days, one week, or the like and may make another attempt to transfer the funds or may review the balance of the account to determine whether funds were deposited (e.g., determine whether the premium balance is still below the threshold). If the funds have been received instep 1308, the transfer may be completed and/or the premium balance may be replenished (e.g., increased above the predetermined threshold). - If, in
step 1308, the funds have not been received or any additional attempts to transfer the funds are not successful, the insurance policy may be cancelled instep 1312. -
FIG. 14 illustrates one example method of reducing or eliminating charges upon reaching a daily mileage threshold limit, according to one or more aspects described herein. Instep 1400, a premium may be received for a usage-based insurance policy. Instep 1402, a cost or rate per day and/or a cost or rate per mile may be determined based on one or more factors. The cost per day and/or cost per mile may be an initial or first cost per day or cost per mile, or may be a revised cost per day or cost per mile, as discussed above, and therefore may be based on various factors, as discussed herein. - In
step 1404, driving data for a trip may be received. Driving data, as discussed above, may include duration, distance, location, driving behavior data, contextual or environmental data, and the like. Instep 1406, a determination is made as to whether a distance driven in the trip is above a predetermined threshold. For instance, a user may have a policy that provides that any miles driven over a predetermined threshold number of miles in a day (e.g., 100, 75, 150, or the like) may be driven free of charge (e.g., without a cost being deducted from the premium for miles over the threshold). Accordingly, if the number of miles for the trip is determined to be below the threshold instep 1406, then the system may determine a cost of the trip based on the cost per day and/or cost per mile and the total distance driven instep 1408. Alternatively, if the distance driven is above the threshold instep 1406, then instep 1410, the cost for the trip will be determined based on the cost per day and/or the cost per mile and the threshold distance. -
FIG. 15 illustrates one example method of tracking trip events via a ledger according to one or more aspects described herein. Instep 1500, a trip event may be received. A trip event may include an occurrence of driving a vehicle, such as from a source location to a destination. Instep 1502, the trip event may be added to a database of trip events. For instance, the trip event may be added to a database storing historical driving data, such as withinusage cost module 1002, or withininsurance database 1006. - In
step 1504, trip cost and aggregate miles may be determined. That is, theusage cost module 1002 may determine a cost associated with the trip based on, for example, a number of miles, a duration of the trip, and the like. The cost per day and/or cost per mile may be determined, as well as an aggregate number of miles travelled. Instep 1506, the trip event and associated details (e.g., costs, aggregate miles, and the like) may be transmitted to a ledger stored withinaccount module 1012. The ledger may store and/or track an account balance for a user, trip events, trip costs, aggregate miles, and the like. - In
step 1508, theaccount module 1012 may determine a new balance in the ledger for the account based on the data received. For instance, a cost of the trip event may be deducted from a previous account balance stored in the ledger to determine a new balance. In one example in which a cost per day is used as a charge for the usage-based insurance policy, the balance in the ledger for a policy may be reduced by the determined rate per day for each vehicle associated with the policy (rate per day may vary based on a selected coverage for a vehicle). -
FIG. 16 illustrates one example method of replenishing accounts according to one or more aspects described herein. Instep 1600, one or more accounts with a balance below a threshold may be determined. Instep 1602, replenishment may be requested from the accounts identified as having a balance below the threshold. Instep 1604, a determination may be made as to whether payment has been received for, for example, a first account. If so, the ledger may be updated with payment information instep 1608. If not, the account status may be updated in the ledger instep 1606. Updating the account status may include flagging the account as being below the threshold, notifying the customer that his or her account is below the threshold, and/or cancelling the insurance policy associated with the account. - In
step 1610, a determination is made as to whether there are more accounts to determine whether payment has been received. If so, the process may return tostep 1604. If not, the process may end. -
FIG. 17 illustrates one example method of creating a new account in the system and the ledger, according to one or more aspects described herein. Instep 1700, a request may be transmitted to a customer. The request may include a request to open a new account, obtain a new usage-based policy, or the like. In some examples, the request may be transmitted to the customer via an electronic message, such as email, SMS, and the like. The electronic message may include a link that the user may select if he or she desires to proceed with creating an account. - In
step 1702, a customer may accept the request to create a new account and the acceptance may be received and/or recorded by the system (e.g.,system 1000 inFIG. 10 ). Instep 1704, a new account may be created (e.g., in account module 1012) and the new account information may be transmitted to the ledger to create a new entry in the ledger. - In
step 1706, an initial deposit of funds may be received and the initial deposit may be recorded in the ledger. As discussed herein, the initial deposit may be an insurance premium or other amount creating a balance of funds in the usage-based insurance account from which costs per mile and/or costs per day may be deducted as a vehicle is operated. In some examples, the policy premium may be determined based on the following: -
Policy Premium=(Days1*RPD)+(Miles1*RPM)+(Days2*RPD)+(Miles2*RPM)+(Days3*RPD)+(Miles3*RPM)+(Days4*RPD)+(Miles4*RPM)+(Days5*RPD)+(Miles5*RPM), where -
- New Business Date is
date Date 1 - RPD is the Rate Per Day
- RPM is the Rate Per Mile
- Miles1 is the Cumulative Chargeable Miles Driven between
Date 1 andDate 1+1 month as evaluated on adate following Date 1+1 month. - Miles2 is the Cumulative Chargeable Miles Driven between
Date 1+1 month and -
Date 1+2 months, evaluated on adate following Date 1+2 months. - Miles3 is the Cumulative Chargeable Miles Driven between
Date 1+2 months andDate 1+3 months, evaluated on adate following Date 1+3 months. - Miles4 is the Cumulative Chargeable Miles Driven between
Date 1+3 months andDate 1+4 months, evaluated on adate following Date 1+4 months. - Miles5 is the Cumulative Chargeable Miles Driven between
Date 1+4 months andDate 1+5 months, evaluated on adate following Date 1+5 months. - Days1 is the number of Days between
Date 1 andDate 1+1 month. - Days2 is the number of Days between
Date 1+1 month andDate 1+2 months. - Days3 is the number of Days between
Date 1+2 months andDate 1+3 months. - Days4 is the number of Days between
Date 1+3 months andDate 1+4 months. - Days5 is the number of Days between
Date 1+4 months andDate 1+5 months.
- New Business Date is
- In some examples, an endorsement may occur during a term of the policy.
- Accordingly, a premium may be adjusted based on the endorsement. In such examples, the premium may be determined by:
-
Policy Premium=(Days1*RPD)+(Miles1*RPM)+(Days2a*RPD)+(Miles2a*RPM)+(Days2b*RPDe)+(Miles2b*RPMe)+(Days3*RPDe)+(Miles3*RPMe)+(Days4*RPDe)+(Miles4*RPMe)+(Days5*RPDe)+(Miles5*RPMe), where -
- Miles2a is the Cumulative Chargeable Miles Driven between
Date 1+1 month and the Endorsement date, evaluated on a date following the endorsement date. - Miles2b is the Cumulative Chargeable Miles Driven between the Endorsement
- Date and
Date 1+2 Months, evaluated on adate following Date 1+2 months. - Days2a is the number of days between
Date 1+1 month and the Endorsement Date. - Days2b is the number of days between the Endorsement Date and
Date 1+2 months. - RPDe is the Endorsement New Rate Per Day.
- RPMe is the Endorsement New Rate Per Mile.
- Miles2a is the Cumulative Chargeable Miles Driven between
- If a policy is cancelled mid-term, the premium for the policy may be calculated using:
-
Policy Premium=(Days1*RPD)+(Miles1*RPM)+(Days2a*RPD)+(Miles2a*RPM), where -
- Miles2a is the Cumulative Number of Miles Driven Between
Date 1+1 Month and the cancellation date. - Days2a is the number of days between
Date 1+1 month and the cancellation date.
- Miles2a is the Cumulative Number of Miles Driven Between
- In at least some examples, the calculations are rounded to the nearest one cent. Additionally or alternatively, calculations may vary based on a coverage level for a vehicle. For instance, a policy having more coverage may have a different rate per day or rate per mile than a policy having lower or less coverage, thereby altering the premium based on the amount of coverage associated with the policy.
- In some arrangements, the initial deposit may include an adjustment for one or more fees. For instance, some states have fees that are collected on various policies. Accordingly, the initial payment may be reduced by an amount of state fees prior to any deductions being made for operating a vehicle associated with the usage-based insurance policy.
- With further reference to
FIG. 17 , instep 1708, policy information may be requested. The policy information may include information associated with the vehicle (e.g., make, model, year, etc.) and/or the driver (e.g., age, driving history, and the like). The policy information may also include information associated with a type of policy, amount of premium, amount of replenishment, and the like. This information may be provided by the customer and, in some examples, may be stored ininsurance database 1006. Instep 1710, the policy information may be received and the ledger may be updated with any policy information received. The balance of the account may be included in the ledger and, as the driver operates a vehicle, driving or trip event data may be received by the system, costs determined, and an amount deducted from the account, as discussed more fully herein. - In some examples, the ledger, initial payment, and the like, may be associated with a policy. For instance, a single policy may have multiple vehicles associated therewith. Accordingly, a single ledger entry for the policy may exist and the account balance may be reduced by costs per day and/or costs per mile for any of the vehicles associated with the policy. Additionally or alternatively, premiums may be determined at a vehicle level (e.g., each vehicle on a policy may have a different premium based on characteristics of the vehicle), and coverage level, state fees, and the like, may also be determined at a vehicle level, rather than a policy level.
- While the aspects described herein have been discussed with respect to specific examples including various modes of carrying out aspects of the disclosure, those skilled in the art will appreciate that there are numerous variations and permutations of the above described systems and techniques that fall within the spirit and scope of the invention.
Claims (20)
1. A usage-based insurance system, comprising:
a plurality of sensors arranged on a vehicle;
an on-board vehicle computing device including at least one processor and at least one memory storing computer readable instructions that, when executed by the at least one processor, cause the on-board vehicle computing device to:
receive, from the plurality of sensors on the vehicle, driving data associated with operation of the vehicle during a first driving trip, the driving data including at least a start time of the first driving trip, an end time of the first driving trip, a distance of the first driving trip, and a driving behavior associated with the first driving trip; and
transmit, to an insurance system server, the received driving data;
the insurance system server to:
retrieve, from one or more insurance system databases, insurance information associated with the vehicle, the insurance information including a usage-based insurance policy;
determine, from the retrieved insurance information, a cost per day and a cost per mile for insuring the vehicle based on the usage-based insurance policy;
store, received from a user device associated with the vehicle, a predetermined amount of funds for a premium for the usage-based insurance policy in a first account;
receive, from the on-board vehicle computing device, the driving data for the first driving trip;
analyze the driving data to determine a distance and time associated with the first driving trip and a type of the driving behavior;
determine, based on the analyzed driving data, a cost of the first driving trip; and
reduce a balance of the premium in the first account by the cost of the first driving trip.
2. The usage-based insurance system of claim 1 , wherein the driving behavior is a hard braking behavior.
3. The usage-based insurance system of claim 1 , wherein reducing the balance of the premium in the first account includes transferring an amount of funds associated with the cost of the trip from the first account to a second account.
4. The usage-based insurance system of claim 3 , wherein the first account and the second account are both associated with an insurance provider.
5. The usage-based insurance system of claim 1 , the insurance system server further including instructions that, when executed, cause the insurance system server to:
receive environmental condition data for the first driving trip.
6. The usage-based insurance system of claim 5 , wherein the environmental condition data includes at least one of: inclement weather, precipitation, heavy traffic volume, and night driving.
7. The usage-based insurance system of claim 1 , the insurance system server further to:
determine whether the reduced premium balance is below a predetermined threshold; and
responsive to determining that the reduced premium balance is below the predetermined threshold, automatically attempt a transfer of funds from a payment account to the first account.
8. One or more non-transitory computer-readable media storing computer-executable instructions that, when executed by a processor, cause an insurance system server to:
receive, from a telematics device in a vehicle, driving data including a start time of a first driving trip, an end time of the first driving trip, a distance of the first driving trip, and a driving behavior of the first driving trip;
receive a premium for a usage-based insurance policy, the premium including an amount of funds stored in an account associated with one of a user or the vehicle;
receive, from an insurance system database, insurance information including a first cost per day and a first cost per mile for the usage-based insurance policy;
receive environmental condition data for the first trip;
determine a cost of the first trip based on a duration of the first trip, the distance of the first trip, the first cost per day, and the first cost per mile;
reduce the amount of funds associated with the premium and stored in the account by the cost of the first driving trip and storing a balance of remaining funds in the account;
subsequent to determining the cost of the first driving trip, modifying the cost per day and cost per mile for operating the vehicle based on the received driving data and the received environmental data to determine a second cost per day and a second cost per mile;
receive, from the telematics device, driving data for a second driving trip including a start time of the second driving trip, an end time of the second driving trip, a distance of the second driving trip and any occurrences of the driving behavior in the second driving trip;
determine a cost of the second driving trip based on the received driving data for the second driving trip, the second amount per day and the second amount per mile; and
reducing the balance of the remaining funds in the account by the cost of the second driving trip.
9. The one or more non-transitory computer-readable media of claim 8 , further including instructions that, when executed, cause the insurance system server to:
determine a threshold number of miles per day;
determine whether the distance of the first driving trip is greater than the threshold number of miles per day;
responsive to determining that the distance of the first driving trip is not greater than the threshold number of miles per day, determining the cost of the first driving trip based on the distance of the first driving trip; and
responsive to determining that the distance of the first driving trip is equal to or greater than the threshold number of miles per day, determining the cost of the first driving trip based on the threshold number of miles per day.
10. The one or more non-transitory computer-readable media of claim 8 , further including instructions that, when executed, cause the insurance system server to:
determine whether the reduced balance of the remaining funds is below a predetermined threshold; and
responsive to determining that the reduced balance of the remaining funds is below the predetermined threshold, automatically attempt to transfer funds from a payment account to the first account.
11. The one or more non-transitory computer-readable media of claim 10 , wherein the payment account is a credit card of the user.
12. The one or more non-transitory computer-readable media of claim 8 , wherein the driving behavior includes hard braking.
13. The one or more non-transitory computer-readable media of claim 8 , wherein the driving behavior includes at least one of: swerving, speeding, and rapid acceleration.
14. An insurance system server device comprising:
a communication port receiving driving data obtained from a plurality of sensors arranged on a vehicle, the driving data comprising a start time of a first driving trip, an end time of the first driving trip, a distance of the first driving trip, and a driving behavior of the first driving trip;
a processor; and
one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the processor, cause the processor to:
receive a premium for a usage-based insurance policy, the premium including an amount of funds provided by a user and stored in an account associated with one of a user and the vehicle;
receive, from an insurance system database, insurance information including a first cost per day and a first cost per mile for the usage-based insurance policy;
receive, via the communication port and from the plurality of sensors, environmental condition data for the first trip;
determine a cost of the first trip based on a duration of the first trip, the distance of the first trip, the first cost per day and the first cost per mile;
reduce the amount of funds associated with the premium and stored in the account by the cost of the first driving trip and storing a balance of remaining funds in the account;
subsequent to determining the cost of the first driving trip, modifying the cost per day and cost per mile for operating the vehicle based on the received driving data and the received environmental data to determine a second cost per day and a second cost per mile;
receive, from the plurality of sensors arranged on the vehicle, driving data for a second driving trip including a start time of the second driving trip, an end time of the second driving trip, a distance of the second driving trip and any occurrences of the driving behavior in the second driving trip;
determine a cost of the second driving trip based on the received driving data for the second driving trip, the second amount per day and the second amount per mile; and
reducing the balance of the remaining funds in the account by the cost of the second driving trip.
15. The insurance system server device of claim 14 , wherein the one or more non-transitory computer-readable media further store computer-executable instructions that, when executed, cause the processor to:
determine a threshold number of miles per day;
determine whether the distance of the first driving trip is greater than the threshold number of miles per day;
responsive to determining that the distance of the first driving trip is not greater than the threshold number of miles per day, determining the cost of the first driving trip based on the distance of the first driving trip; and
responsive to determining that the distance of the first driving trip is equal to or greater than the threshold number of miles per day, determining the cost of the first driving trip based on the threshold number of miles per day.
16. The insurance system server device of claim 14 , wherein the one or more non-transitory computer-readable media further store computer-executable instructions that, when executed, cause the processor to:
determine whether the reduced balance of the remaining funds is below a predetermined threshold; and
responsive to determining that the reduced balance of the remaining funds is below the predetermined threshold, automatically attempt to transfer funds from a payment account to the first account.
17. The insurance system server device of claim 16 , wherein the payment account is a credit card of the user.
18. The insurance system server device of claim 14 , wherein the driving behavior includes hard braking.
19. The insurance system server device of claim 14 , wherein the communication port further receives, from the plurality of sensors arranged on the vehicle, environmental condition data comprising at least one of inclement weather, precipitation, heavy traffic volume, or night driving.
20. The insurance system server of claim 14 , wherein the non-transitory computer-readable media storing computer-executable instructions further cause the processor to:
determine whether the reduced premium balance is below a predetermined threshold; and
responsive to determining that the reduced premium balance is below the predetermined threshold, automatically attempt to transfer funds from a payment account to the first account.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US18/130,104 US20230289890A1 (en) | 2015-01-28 | 2023-04-03 | Usage-Based Policies |
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/607,636 US9361599B1 (en) | 2015-01-28 | 2015-01-28 | Risk unit based policies |
US14/607,662 US9390452B1 (en) | 2015-01-28 | 2015-01-28 | Risk unit based policies |
US14/988,977 US10817950B1 (en) | 2015-01-28 | 2016-01-06 | Usage-based policies |
US17/036,768 US11645721B1 (en) | 2015-01-28 | 2020-09-29 | Usage-based policies |
US18/130,104 US20230289890A1 (en) | 2015-01-28 | 2023-04-03 | Usage-Based Policies |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/036,768 Division US11645721B1 (en) | 2015-01-28 | 2020-09-29 | Usage-based policies |
Publications (1)
Publication Number | Publication Date |
---|---|
US20230289890A1 true US20230289890A1 (en) | 2023-09-14 |
Family
ID=72944424
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/988,977 Active US10817950B1 (en) | 2015-01-28 | 2016-01-06 | Usage-based policies |
US17/036,768 Active US11645721B1 (en) | 2015-01-28 | 2020-09-29 | Usage-based policies |
US18/130,104 Pending US20230289890A1 (en) | 2015-01-28 | 2023-04-03 | Usage-Based Policies |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/988,977 Active US10817950B1 (en) | 2015-01-28 | 2016-01-06 | Usage-based policies |
US17/036,768 Active US11645721B1 (en) | 2015-01-28 | 2020-09-29 | Usage-based policies |
Country Status (1)
Country | Link |
---|---|
US (3) | US10817950B1 (en) |
Families Citing this family (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9652770B1 (en) | 2014-04-30 | 2017-05-16 | Wells Fargo Bank, N.A. | Mobile wallet using tokenized card systems and methods |
US10430883B1 (en) | 2016-02-12 | 2019-10-01 | Allstate Insurance Company | Dynamic usage-based policies |
US20210295440A1 (en) | 2016-05-11 | 2021-09-23 | State Farm Mutual Automobile Insurance Company | Systems and methods for allocating vehicle costs between vehicle users using pre-paid accounts |
US11386502B2 (en) * | 2019-06-13 | 2022-07-12 | Sure, Inc. | Automatic action-based product provisioning |
US12002305B1 (en) * | 2019-08-28 | 2024-06-04 | State Farm Mutual Automobile Insurance Company | Systems and methods for generating improved vehicle usage analytics based upon vehicle sensor and telematics data |
US11516295B1 (en) * | 2019-12-06 | 2022-11-29 | State Farm Mutual Automobile Insurance Company | Using contextual information for vehicle trip loss risk assessment scoring |
US11769206B1 (en) | 2020-01-28 | 2023-09-26 | State Farm Mutual Automobile Insurance Company | Transportation analytics systems and methods using a mobility device embedded within a vehicle |
US11487891B2 (en) * | 2020-10-14 | 2022-11-01 | Philip Chidi Njemanze | Method and system for mental performance computing using artificial intelligence and blockchain |
US12020329B1 (en) * | 2021-03-03 | 2024-06-25 | United Services Automobile Association (Usaa) | Systems and methods for dynamically adjusting pay-per-ride insurance |
US11995621B1 (en) | 2021-10-22 | 2024-05-28 | Wells Fargo Bank, N.A. | Systems and methods for native, non-native, and hybrid registration and use of tags for real-time services |
JP2023076261A (en) * | 2021-11-22 | 2023-06-01 | 本田技研工業株式会社 | Information processing server, information processing method, program, and storage medium |
US20230316410A1 (en) * | 2022-03-31 | 2023-10-05 | Ago Technologies Llc | Dual telemetry system and method to reduce insurance costs and claims for vehicles driven fully or partially for commercial purposes |
US11983778B2 (en) | 2022-05-12 | 2024-05-14 | Hartford Fire Insurance Company | Systems and methods to remotely monitor machine usage |
Family Cites Families (155)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5510765A (en) | 1993-01-07 | 1996-04-23 | Ford Motor Company | Motor vehicle security sensor system |
US5797134A (en) | 1996-01-29 | 1998-08-18 | Progressive Casualty Insurance Company | Motor vehicle monitoring system for determining a cost of insurance |
US8090598B2 (en) * | 1996-01-29 | 2012-01-03 | Progressive Casualty Insurance Company | Monitoring system for determining and communicating a cost of insurance |
US6868386B1 (en) | 1996-01-29 | 2005-03-15 | Progressive Casualty Insurance Company | Monitoring system for determining and communicating a cost of insurance |
US8140358B1 (en) | 1996-01-29 | 2012-03-20 | Progressive Casualty Insurance Company | Vehicle monitoring system |
US20020002475A1 (en) | 2000-04-13 | 2002-01-03 | Joel Freedman | Automated insurance system and method |
US20020111725A1 (en) | 2000-07-17 | 2002-08-15 | Burge John R. | Method and apparatus for risk-related use of vehicle communication system data |
US20090109037A1 (en) * | 2000-08-11 | 2009-04-30 | Telanon, Inc. | Automated consumer to business electronic marketplace system |
US7941258B1 (en) | 2000-08-31 | 2011-05-10 | Strategic Design Federation W, Inc. | Automobile monitoring for operation analysis |
US6556905B1 (en) | 2000-08-31 | 2003-04-29 | Lisa M. Mittelsteadt | Vehicle supervision and monitoring |
US7584033B2 (en) | 2000-08-31 | 2009-09-01 | Strategic Design Federation W. Inc. | Automobile monitoring for operation analysis |
JP2002149984A (en) | 2000-11-09 | 2002-05-24 | Denso Corp | Automobile premium calculating system |
JP2002183456A (en) | 2000-12-18 | 2002-06-28 | Tatsuo Ikoma | Operation evaluating device and insurance evaluation method using it |
US6433863B1 (en) | 2001-01-08 | 2002-08-13 | Ronald Weiss | Combination breathalyzer and eye-sensor |
JPWO2002056222A1 (en) | 2001-01-15 | 2004-05-20 | 株式会社日立製作所 | Vehicle non-life insurance method, in-vehicle device, terminal device, and non-life insurance system for vehicle |
US7117173B1 (en) | 2001-02-02 | 2006-10-03 | Sonal Sheth Ambani | System and method for providing financial services to children and teenagers |
JP2002297910A (en) | 2001-03-29 | 2002-10-11 | Aioi Insurance Co Ltd | Fluctuating consumption type insurance system |
JP2004029872A (en) | 2002-06-21 | 2004-01-29 | Hitachi Ltd | Insurance fee calculation system |
US20040064247A1 (en) | 2002-09-26 | 2004-04-01 | Davis Christopher E. | Method and system for remotely managing vehicle mileage |
US20040153352A1 (en) | 2003-02-05 | 2004-08-05 | James Berns | Vendor referral system |
DE10314119A1 (en) | 2003-03-28 | 2004-10-21 | Dieter Dr. Bastian | Process for determining an integral risk potential for a road user and device for carrying out the process |
CA2925145A1 (en) * | 2003-07-07 | 2005-01-13 | Insurance Services Office, Inc. | Traffic information system |
US9311676B2 (en) | 2003-09-04 | 2016-04-12 | Hartford Fire Insurance Company | Systems and methods for analyzing sensor data |
US7323970B1 (en) | 2004-01-21 | 2008-01-29 | Numerex Corporation | Method and system for remote interaction with a vehicle via wireless communication |
US20060053038A1 (en) | 2004-09-08 | 2006-03-09 | Warren Gregory S | Calculation of driver score based on vehicle operation |
US7890355B2 (en) * | 2004-10-29 | 2011-02-15 | Milemeter, Inc. | System and method for the assessment, pricing, and provisioning of distance-based vehicle insurance |
US7865378B2 (en) * | 2004-10-29 | 2011-01-04 | Milemeter, Inc. | System and method for the assessment, pricing, and provisioning of distance-based vehicle insurance |
US20070299700A1 (en) | 2004-10-29 | 2007-12-27 | Milemeter, Inc. | System and Method for Assessing Earned Premium for Distance-Based Vehicle Insurance |
US7991629B2 (en) * | 2004-10-29 | 2011-08-02 | Milemeter, Inc. | System and method for the assessment, pricing, and provisioning of distance-based vehicle insurance |
US7987103B2 (en) * | 2004-10-29 | 2011-07-26 | Milemeter, Inc. | System and method for the assessment, pricing, and provisioning of distance-based vehicle insurance |
US7937278B1 (en) * | 2005-01-18 | 2011-05-03 | Allstate Insurance Company | Usage-based insurance cost determination system and method |
US20060182661A1 (en) | 2005-02-11 | 2006-08-17 | Aquila Albert B | Blood alcohol content (BAC) level actuated lock box |
EP1904347B1 (en) | 2005-07-11 | 2011-09-28 | Volvo Technology Corporation | Methods and arrangement for performing driver identity verification |
US8655776B2 (en) | 2005-07-19 | 2014-02-18 | The Prudential Insurance Company Of America | Benefits contract providing a bundle of benefits |
EP1984868A4 (en) | 2006-02-13 | 2010-08-25 | All Protect Llc | Method and system for controlling a vehicle given to a third party |
US8549318B2 (en) | 2006-02-13 | 2013-10-01 | Affirmed Technologies, Llc | Method and system for preventing unauthorized use of a vehicle by an operator of the vehicle |
GB0605069D0 (en) | 2006-03-14 | 2006-04-26 | Airmax Group Plc | Method and system for driver style monitoring and analysing |
JP2007257326A (en) | 2006-03-23 | 2007-10-04 | Toyota Motor Corp | Insurance contract system, insurance contracting method, mobile mounted device, server and insurance contract program |
US20070250382A1 (en) | 2006-04-19 | 2007-10-25 | Hablar Holdings Ltd. | Responsibilities-based reward allocation and management system |
JP4475251B2 (en) | 2006-04-25 | 2010-06-09 | トヨタ自動車株式会社 | Vehicle environmental service system |
US8630768B2 (en) | 2006-05-22 | 2014-01-14 | Inthinc Technology Solutions, Inc. | System and method for monitoring vehicle parameters and driver behavior |
US20080258890A1 (en) | 2006-05-22 | 2008-10-23 | Todd Follmer | System and Method for Remotely Deactivating a Vehicle |
US20070282638A1 (en) | 2006-06-04 | 2007-12-06 | Martin Surovy | Route based method for determining cost of automobile insurance |
US8086523B1 (en) | 2006-08-07 | 2011-12-27 | Allstate Insurance Company | Credit risk evaluation with responsibility factors |
EP1921580A1 (en) * | 2006-11-07 | 2008-05-14 | András Kovács | Efficient implementation of electronic data collection assisted vehicle insurance schemes |
US7899560B2 (en) | 2007-01-09 | 2011-03-01 | Swiss Reinsurance Company | Electronic switching apparatus and method for switching autonomous intervention means for automatically redressing malfunctions |
US8650623B2 (en) | 2007-01-17 | 2014-02-11 | International Business Machines Corporation | Risk adaptive information flow based access control |
US8117049B2 (en) | 2007-04-10 | 2012-02-14 | Hti Ip, Llc | Methods, systems, and apparatuses for determining driver behavior |
US10096038B2 (en) | 2007-05-10 | 2018-10-09 | Allstate Insurance Company | Road segment safety rating system |
US10157422B2 (en) | 2007-05-10 | 2018-12-18 | Allstate Insurance Company | Road segment safety rating |
US8606512B1 (en) | 2007-05-10 | 2013-12-10 | Allstate Insurance Company | Route risk mitigation |
US8346578B1 (en) | 2007-06-13 | 2013-01-01 | United Services Automobile Association | Systems and methods for using unmanned aerial vehicles |
US8577703B2 (en) | 2007-07-17 | 2013-11-05 | Inthinc Technology Solutions, Inc. | System and method for categorizing driving behavior using driver mentoring and/or monitoring equipment to determine an underwriting risk |
US8180655B1 (en) * | 2007-09-24 | 2012-05-15 | United Services Automobile Association (Usaa) | Systems and methods for processing vehicle or driver performance data |
US8566126B1 (en) * | 2007-09-24 | 2013-10-22 | United Services Automobile Association | Systems and methods for processing vehicle or driver performance data |
BRPI0916722A2 (en) | 2008-07-31 | 2019-09-24 | Choicepoint Services Inc | steering performance data provision system and method of obtaining steering performance data |
FR2936631B1 (en) | 2008-09-29 | 2011-03-25 | Act Concepts | METHOD AND DEVICE FOR AUTHENTICATING TRANSMITTED DATA RELATING TO THE USE OF A VEHICLE AND / OR BEHAVIOR OF ITS DRIVER |
US20100131300A1 (en) | 2008-11-26 | 2010-05-27 | Fred Collopy | Visible insurance |
NZ596948A (en) | 2009-05-08 | 2014-05-30 | Obdedge Llc | Systems, methods, and devices for policy-based control and monitoring of use of mobile devices by vehicle operators |
US8196694B2 (en) | 2009-05-21 | 2012-06-12 | GM Global Technology Operations LLC | Vehicle immobilizer methods and apparatus based on driver impairment |
US9053469B1 (en) * | 2009-07-10 | 2015-06-09 | United Services Automobile Association | System and method for providing usage based vehicle insurance |
US8373554B2 (en) | 2009-09-09 | 2013-02-12 | Alcatel Lucent | Network-based identification of uninsured vehicles |
US11042816B2 (en) * | 2009-10-30 | 2021-06-22 | Getaround, Inc. | Vehicle access control services and platform |
WO2011057217A2 (en) | 2009-11-06 | 2011-05-12 | University Of Utah Research Foundation | Method for gathering, processing, and analyzing data to determine crash risk associated with driving behavior |
US8423239B2 (en) | 2009-11-23 | 2013-04-16 | Hti Ip, L.L.C. | Method and system for adjusting a charge related to use of a vehicle during a period based on operational performance data |
CN102666240B (en) | 2009-11-27 | 2014-04-16 | 丰田自动车株式会社 | Collision prevention device |
US8635091B2 (en) | 2009-12-17 | 2014-01-21 | Hartford Fire Insurance Company | Systems and methods for linking vehicles to telematics-enabled portable devices |
US20110304465A1 (en) | 2009-12-30 | 2011-12-15 | Boult Terrance E | System and method for driver reaction impairment vehicle exclusion via systematic measurement for assurance of reaction time |
US8805707B2 (en) | 2009-12-31 | 2014-08-12 | Hartford Fire Insurance Company | Systems and methods for providing a safety score associated with a user location |
US20120004933A1 (en) | 2010-02-09 | 2012-01-05 | At&T Mobility Ii Llc | System And Method For The Collection And Monitoring Of Vehicle Data |
US20120010906A1 (en) | 2010-02-09 | 2012-01-12 | At&T Mobility Ii Llc | System And Method For The Collection And Monitoring Of Vehicle Data |
WO2011146466A2 (en) | 2010-05-17 | 2011-11-24 | The Travelers Companies, Inc. | Monitoring customer-selected vehicle parameters |
US20120062392A1 (en) | 2010-09-14 | 2012-03-15 | Ferrick David P | System and Method for Protecting Assets from Harm and for Reducing Insurance Risk |
US20120066007A1 (en) | 2010-09-14 | 2012-03-15 | Ferrick David P | System and Method for Tracking and Sharing Driving Metrics with a Plurality of Insurance Carriers |
US20120073892A1 (en) | 2010-09-24 | 2012-03-29 | Hunter Cecil L | Ignition interlock and driving monitoring system and method |
US20120179493A1 (en) | 2010-12-13 | 2012-07-12 | James Richard Giordano | Simple Metering Automatic Real Time Insurance (SMARTI) |
US20120173128A1 (en) | 2010-12-30 | 2012-07-05 | Theresa Peeler | System and Method for Preventing the Operation of a Motor Vehicle Without Required Insurance |
US9164957B2 (en) | 2011-01-24 | 2015-10-20 | Lexisnexis Risk Solutions Inc. | Systems and methods for telematics monitoring and communications |
US20120191481A1 (en) | 2011-01-24 | 2012-07-26 | Lexisnexis Risk Solutions Inc. | Telematics smart pinging systems and methods |
US20120197669A1 (en) | 2011-01-27 | 2012-08-02 | Kote Thejovardhana S | Determining Cost of Auto Insurance |
JP4729137B1 (en) | 2011-03-03 | 2011-07-20 | 株式会社データ・テック | Operation management device, portable information terminal, operation management server, computer program mounted on a moving body |
US20140276090A1 (en) | 2011-03-14 | 2014-09-18 | American Vehcular Sciences Llc | Driver health and fatigue monitoring system and method using optics |
US8653953B2 (en) | 2011-04-12 | 2014-02-18 | General Motors Llc | Odometer verification and reporting using a telematics-equipped vehicle |
US20130006674A1 (en) | 2011-06-29 | 2013-01-03 | State Farm Insurance | Systems and Methods Using a Mobile Device to Collect Data for Insurance Premiums |
US9082072B1 (en) * | 2011-07-14 | 2015-07-14 | Donald K. Wedding, Jr. | Method for applying usage based data |
US8538785B2 (en) | 2011-08-19 | 2013-09-17 | Hartford Fire Insurance Company | System and method for computing and scoring the complexity of a vehicle trip using geo-spatial information |
US20130169442A1 (en) | 2011-08-25 | 2013-07-04 | John Ruocco | Ignition interlock device operating method |
EP2573727A1 (en) | 2011-09-21 | 2013-03-27 | Allianz Telematics S.p.A. | Telematics on-board unit for vehicles |
US8849803B2 (en) * | 2011-10-31 | 2014-09-30 | International Business Machines Corporation | Data collection for usage based insurance |
US20140257862A1 (en) | 2011-11-29 | 2014-09-11 | Wildfire Defense Systems, Inc. | Mobile application for risk management |
GB201205125D0 (en) * | 2012-02-08 | 2012-05-09 | Tomtom Int Bv | Methods using speed distribution profiles |
SE536396C2 (en) | 2012-02-09 | 2013-10-08 | Movelo Ab | Determination of activity level of portable electronic equipment |
US9010477B2 (en) | 2012-02-16 | 2015-04-21 | Aonec, Llc | In vehicle glucose apparatus and vehicular operation inhibitor |
US10657597B1 (en) * | 2012-02-17 | 2020-05-19 | United Services Automobile Association (Usaa) | Systems and methods for dynamic insurance premiums |
US20130274955A1 (en) * | 2012-04-13 | 2013-10-17 | Walter Steven Rosenbaum | Method for analyzing operation characteristics of a vehicle driver |
US9037394B2 (en) | 2012-05-22 | 2015-05-19 | Hartford Fire Insurance Company | System and method to determine an initial insurance policy benefit based on telematics data collected by a smartphone |
US20150168174A1 (en) * | 2012-06-21 | 2015-06-18 | Cellepathy Ltd. | Navigation instructions |
WO2015027248A2 (en) * | 2013-08-23 | 2015-02-26 | Cellepathy Ltd. | Mobile device context aware determinations |
US20150177010A1 (en) * | 2013-08-23 | 2015-06-25 | Cellepathy Ltd. | Suppressed navigation instructions |
US20140006164A1 (en) | 2012-06-29 | 2014-01-02 | Yahoo! Inc. | Methods and systems for targeting ads based on risk behavior metadata |
US20140019167A1 (en) | 2012-07-16 | 2014-01-16 | Shuli Cheng | Method and Apparatus for Determining Insurance Risk Based on Monitoring Driver's Eyes and Head |
US20140046701A1 (en) | 2012-08-12 | 2014-02-13 | Insurance Services Office, Inc. | Apparatus and Method for Detecting Driving Performance Data |
DE102012214464A1 (en) | 2012-08-14 | 2014-02-20 | Ford Global Technologies, Llc | System for monitoring and analyzing the driving behavior of a driver in a motor vehicle |
CA2882603A1 (en) | 2012-08-21 | 2014-02-27 | Insurance Services Office, Inc. | Apparatus and method for analyzing driving performance data |
US20140067434A1 (en) | 2012-08-30 | 2014-03-06 | Agero, Inc. | Methods and Systems for Providing Risk Profile Analytics |
US20140095214A1 (en) | 2012-10-03 | 2014-04-03 | Robert E. Mathe | Systems and methods for providing a driving performance platform |
WO2014058999A1 (en) * | 2012-10-09 | 2014-04-17 | Insurance Services Office, Inc. | System and method for classifying and identifying a driver using driving performance data |
US20140108058A1 (en) * | 2012-10-11 | 2014-04-17 | Agero, Inc. | Method and System to Determine Auto Insurance Risk |
CA2888492C (en) | 2012-10-16 | 2023-03-07 | Ims Solutions Inc. | Driving event classification system |
US20140114674A1 (en) | 2012-10-22 | 2014-04-24 | Robert M. Krughoff | Health Insurance Plan Comparison Tool |
US8930269B2 (en) | 2012-12-17 | 2015-01-06 | State Farm Mutual Automobile Insurance Company | System and method to adjust insurance rate based on real-time data about potential vehicle operator impairment |
US9524269B1 (en) * | 2012-12-19 | 2016-12-20 | Allstate Insurance Company | Driving event data analysis |
US9141995B1 (en) * | 2012-12-19 | 2015-09-22 | Allstate Insurance Company | Driving trip and pattern analysis |
US9535878B1 (en) * | 2012-12-19 | 2017-01-03 | Allstate Insurance Company | Driving event data analysis |
US9141582B1 (en) * | 2012-12-19 | 2015-09-22 | Allstate Insurance Company | Driving trip and pattern analysis |
US20140297348A1 (en) | 2013-01-21 | 2014-10-02 | David A. Ellis | Merit-based incentive to-do list application system, method and computer program product |
US20140257863A1 (en) | 2013-03-06 | 2014-09-11 | American Family Mutual Insurance Company | System and method of usage-based insurance with location-only data |
US9454786B1 (en) * | 2013-03-08 | 2016-09-27 | Allstate Insurance Company | Encouraging safe driving using a remote vehicle starter and personalized insurance rates |
US20140257868A1 (en) * | 2013-03-10 | 2014-09-11 | State Farm Mutual Automobile Insurance Company | Systems and methods for processing vehicle insurance based on acuity testing performance |
US20140278574A1 (en) | 2013-03-14 | 2014-09-18 | Ernest W. BARBER | System and method for developing a driver safety rating |
US20140278837A1 (en) | 2013-03-14 | 2014-09-18 | Frederick T. Blumer | Method and system for adjusting a charge related to use of a vehicle based on operational data |
US9628958B1 (en) * | 2013-03-15 | 2017-04-18 | Paul McBurney | User-controlled, smart device-based location and transit data gathering and sharing |
EP3101392B1 (en) | 2013-03-15 | 2021-12-15 | Apple Inc. | Mapping application with turn-by-turn navigation mode for output to vehicle display |
US20140279707A1 (en) * | 2013-03-15 | 2014-09-18 | CAA South Central Ontario | System and method for vehicle data analysis |
WO2014182971A2 (en) * | 2013-05-08 | 2014-11-13 | Obdedge, Llc | Driver identification and data collection systems for use with mobile communication devices in vehicles |
WO2014181303A1 (en) | 2013-05-09 | 2014-11-13 | Outsurance Holdings Limited | Vehicle monitoring and feedback system |
US20150161738A1 (en) | 2013-12-10 | 2015-06-11 | Advanced Insurance Products & Services, Inc. | Method of determining a risk score or insurance cost using risk-related decision-making processes and decision outcomes |
US20150025917A1 (en) | 2013-07-15 | 2015-01-22 | Advanced Insurance Products & Services, Inc. | System and method for determining an underwriting risk, risk score, or price of insurance using cognitive information |
US20150032481A1 (en) | 2013-07-26 | 2015-01-29 | Farmers Group, Inc. | Method and Apparatus for Behavior Based Insurance |
US20150045983A1 (en) | 2013-08-07 | 2015-02-12 | DriveFactor | Methods, Systems and Devices for Obtaining and Utilizing Vehicle Telematics Data |
US20150081404A1 (en) | 2013-08-12 | 2015-03-19 | Intelligent Mechatronic Systems Inc. | Driver behavior enhancement using scoring, recognition and redeemable rewards |
US8935036B1 (en) | 2013-09-06 | 2015-01-13 | State Farm Mutual Automobile Insurance Company | Systems and methods for updating a driving tip model using telematics data |
US10115164B1 (en) * | 2013-10-04 | 2018-10-30 | State Farm Mutual Automobile Insurance Company | Systems and methods to quantify and differentiate individual insurance risk based on actual driving behavior and driving environment |
CA2927515C (en) | 2013-10-14 | 2022-01-04 | Ims Solutions Inc. | Behavior based driving record management and rehabilitation |
KR101759341B1 (en) | 2013-11-08 | 2017-07-19 | 한국전자통신연구원 | Method method and apparatus for managing automobile insurance |
US10023114B2 (en) | 2013-12-31 | 2018-07-17 | Hartford Fire Insurance Company | Electronics for remotely monitoring and controlling a vehicle |
US20150187014A1 (en) | 2013-12-31 | 2015-07-02 | Hartford Fire Insurance Company | System and method for expectation based processing |
US10134091B2 (en) | 2013-12-31 | 2018-11-20 | Hartford Fire Insurance Company | System and method for determining driver signatures |
US9754425B1 (en) | 2014-02-21 | 2017-09-05 | Allstate Insurance Company | Vehicle telematics and account management |
US20150253144A1 (en) | 2014-03-10 | 2015-09-10 | Sackett Solutions & Innovations Llc | Methods and route planning systems for dynamic trip modifications and quick and easy alternative routes |
US9418491B2 (en) * | 2014-09-22 | 2016-08-16 | Brian K. Phillips | Method and system for automatically identifying a driver by creating a unique driver profile for a vehicle from driving habits |
US9984420B1 (en) | 2014-10-06 | 2018-05-29 | Allstate Insurance Company | System and method for determining an insurance premium based on analysis of human telematic data and vehicle telematic data |
US20160189304A1 (en) * | 2014-12-30 | 2016-06-30 | Paypal, Inc. | Detection of users and vehicle usage for variable insurance terms |
US9390452B1 (en) | 2015-01-28 | 2016-07-12 | Allstate Insurance Company | Risk unit based policies |
US9361599B1 (en) | 2015-01-28 | 2016-06-07 | Allstate Insurance Company | Risk unit based policies |
US10846799B2 (en) | 2015-01-28 | 2020-11-24 | Arity International Limited | Interactive dashboard display |
US20170011467A1 (en) * | 2015-03-14 | 2017-01-12 | Telanon, Inc. | Methods and Apparatus for Remote Collection of Sensor Data for Vehicle Trips with High-Integrity Vehicle Identification |
US10891693B2 (en) * | 2015-10-15 | 2021-01-12 | International Business Machines Corporation | Method and system to determine auto insurance risk |
US10430883B1 (en) * | 2016-02-12 | 2019-10-01 | Allstate Insurance Company | Dynamic usage-based policies |
US10036645B2 (en) * | 2016-06-15 | 2018-07-31 | Here Global B.V. | Vehicle usage-based pricing alerts |
US20180060970A1 (en) | 2016-09-01 | 2018-03-01 | International Business Machines Corporation | System and method for context-based driver monitoring |
CN110582802A (en) * | 2017-03-24 | 2019-12-17 | 深圳市大疆创新科技有限公司 | Vehicle behavior monitoring system and method |
JP7156268B2 (en) * | 2017-03-29 | 2022-10-19 | ソニーグループ株式会社 | Information processing device, information processing system, information processing method, and program |
JP7219545B2 (en) * | 2018-03-26 | 2023-02-08 | 本田技研工業株式会社 | Driving evaluation device, driving evaluation system, and program |
JP7011508B2 (en) * | 2018-03-26 | 2022-01-26 | 本田技研工業株式会社 | Driving evaluation system and program |
-
2016
- 2016-01-06 US US14/988,977 patent/US10817950B1/en active Active
-
2020
- 2020-09-29 US US17/036,768 patent/US11645721B1/en active Active
-
2023
- 2023-04-03 US US18/130,104 patent/US20230289890A1/en active Pending
Also Published As
Publication number | Publication date |
---|---|
US11645721B1 (en) | 2023-05-09 |
US10817950B1 (en) | 2020-10-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11651438B2 (en) | Risk unit based policies | |
US11948199B2 (en) | Interactive dashboard display | |
US11645721B1 (en) | Usage-based policies | |
US10719880B2 (en) | Risk unit based policies | |
US12020324B2 (en) | Dynamic usage-based policies | |
WO2018048870A1 (en) | Interactive dashboard display |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |