Risk Unit Based Policy

Abstract

A method, computer readable medium, system and apparatus for implementing a risk unit-based insurance policy are provided. In one embodiment, a user receives a plurality of risk units associated with an insurance policy. The risk units are stored in a risk unit account associated with the user, the vehicle, etc. During operation of the vehicle, sensor data is received. The sensor data provides information associated with the user's driving behavior, environmental conditions in which the vehicle is operated, etc. A consumption rate of the risk units is determined based at least in part on the received sensor data. The consumption rate is displayed to the user via the user's mobile device or a vehicle display. Additionally, one or more driving modifications to reduce the consumption rate may be determined and provided to the user.

Description

[Technical field]

[0001] Various aspects of the present disclosure relate to a risk unit based insurance system for determining and implementing a risk unit based insurance policy. More specifically, aspects of the present disclosure relate to determining risk units, providing a plurality of risk units to a user, receiving and analyzing various driver data, vehicle data, and / or driving movement data, determining a consumption rate of the risk units (or other units within the account), and reducing a balance in a risk unit account based on the consumption rate according to the risk unit based insurance policy. [Background technology]

[0002] Vehicle insurance policies are generally purchased by insurance customers from various insurance carriers. Traditional policies generally provide coverage to a user for the term of the policy based on the payment of a premium associated with the policy. Such term-based policies may not be based on driving behavior, environmental conditions, etc. Rather, coverage may be provided for the term regardless of how, where, when, etc., the driver operates the vehicle.

[0003] 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 within or outside the vehicle. Such information can include, for example, vehicle operation data, driving conditions, and communications from other vehicles or systems. Summary of the Invention

[0004] SUMMARY OF THE DISCLOSURE The following is a simplified summary in order to provide a basic understanding of some aspects of the disclosure. This summary is not an extensive overview of the disclosure. It is not intended to identify key or critical elements of the disclosure or 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 that follows.

[0005] Aspects of the present disclosure relate to methods, computer readable media, and apparatus for determining and implementing a risk unit based insurance policy. In some configurations, a user may receive a number of risk units associated with an insurance policy, e.g., an automobile insurance policy. The risk units may be stored in a risk unit account associated with the user, the vehicle, etc. During vehicle operation, sensor data may be received. The sensor data may provide information associated with the user's driving behavior, environmental conditions in which the vehicle is being operated, etc. A consumption rate of the risk units may be determined based at least in part on the received sensor data. The consumption rate may also be based on additional factors, e.g., driving experience, policy coverage, vehicle characteristics, etc. In some examples, the consumption rate may be based on a combination of factors, or based solely on sensor data factors, or other factors not determined based on sensor data. In this manner, as the vehicle is operated, the number or balance of risk units in the risk unit account may be reduced based on the determined consumption rate.

[0006] In some examples, the consumption rate may be displayed to the user, for example, via the user's mobile device or vehicle display. Additionally, in some configurations, one or more driving modifications to reduce the consumption rate may be determined. For example, the system may identify one or more modifications or changes to the user's driving behavior, the environment in which the vehicle is operating, etc. based on the received sensor data, which may reduce the consumption rate of risk units. These recommendations may be provided to the user, for example, via the user's mobile device and / or vehicle display.

[0007] Other features and advantages of the present disclosure will become apparent from the further description provided herein.

[0008] A more complete understanding of the present invention and its advantages may be obtained by reference to the following description taken in conjunction with the accompanying drawings, in which like reference numerals indicate like features and in which: [Brief description of the drawings]

[0009] [Figure 1] 1 illustrates exemplary computing systems and network environments that can be used to implement aspects of the present disclosure. [Diagram 2] 1 is an example of a risk unit-based insurance system according to one or more embodiments described herein. [Diagram 3] 1 is an example of a risk unit-based insurance system environment illustrating various communications between a vehicle-based device, a personal mobile device, and an insurance system server, in accordance with one or more aspects of the present disclosure. [Figure 4] FIG. 1 is a flow diagram illustrating an example method for generating a risk unit-based insurance policy and implementing a risk unit-based insurance policy according to one or more aspects described herein. [Diagram 5] 1 is an example of a user interface that provides a user with information regarding risk unit consumption rates, according to one or more aspects described herein. [Figure 6] FIG. 1 is a flow diagram illustrating one example of a method for providing a user with one or more risk unit account replenishment options, according to one or more aspects described herein. [Figure 7A] 1 is an example of a user interface that may be provided to a user to facilitate risk unit account top-up according to one or more aspects described herein. [Figure 7B] 1 is another example of a user interface that may be provided to a user to facilitate risk unit account top-up according to one or more aspects described herein. [Figure 7C]11 is yet another example of a user interface that may be provided to a user to facilitate risk unit account top-up according to one or more aspects described herein. [Figure 7D] 11 is yet another example of a user interface that may be provided to a user to facilitate risk unit account top-up according to one or more aspects described herein. [Figure 8] FIG. 1 is a flow diagram illustrating an example of a method for generating suggested changes to driving behavior to improve risk unit consumption rate, according to one or more embodiments described herein. [Figure 9] 1 is an example of a user interface that provides one or more recommended driving behavior changes to a user, according to one or more aspects described herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] In the following description of 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 present disclosure which may be practiced. It should be understood that other embodiments may be utilized.

[0011] As will be apparent to one of ordinary skill in the art upon reading the disclosure that follows, various aspects described herein may be embodied as a method, a computer system, or a computer program product. As such, these 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 medium. Any suitable computer-readable storage medium may be utilized, including hard disks, CD-ROMs, optical storage devices, magnetic storage devices, and / or any combination thereof. Additionally, 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).

[0012] 1 illustrates a block diagram of a computing device (or system) 101 of a computer system 100 that may be used in accordance with one or more exemplary embodiments of the present disclosure. The device 101 may have a processor 103 for controlling the 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 embedded hardware 160), may correspond to any of a number of systems or devices described herein, such as a personal mobile device, a vehicle-based computing device, an insurance system server, an external data source, and various other devices within a risk unit-based insurance system. These various computing systems, individually or in combination as described herein, may be configured to use the risk unit based insurance system equipment described herein to determine and / or provide one or more risk units to a user, maintain a risk unit account for the user, determine the rate at which a balance in the account may decrease (e.g., based on various driving factors, external factors, traditional insurance factors, etc.), automatically replenish the risk unit account based on the balance reaching a predetermined threshold, etc. In addition to the features described above, the techniques described herein may further be used to generate and present insurance recommendations, underwriting, and other insurance related tasks to a customer.

[0013] 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 further include one or more of a speaker for providing audio output, and a video display device for providing text, audiovisual, and / or graphic output. Software may be stored within the memory 115 and / or storage devices to provide instructions to the processor 103 for enabling the device 101 to perform various operations. For example, the memory 115 may store software used by the device 101, such as the operating system 117, application programs 119, and associated internal databases 121. The various hardware memory units within the memory 115 may include volatile and non-volatile, removable and non-removable media embodied in any method or technology for storage of information, data structures, program modules, or other data, such as computer-readable instructions. Certain devices and systems within the risk unit-based insurance system may have minimum hardware requirements to support sufficient storage capacity, processing power, analytical capabilities, network communications, and the like. For example, in some embodiments, one or more non-volatile 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 the devices 101 (e.g., personal mobile device 101, vehicle-based device 101, insurance system server 101, etc.) to collect and analyze driver data, vehicle data, and / or driving movement data using various devices of the risk unit-based insurance system, determine risk unit-based insurance policy parameters, determine the rate at which risk units are consumed during operation of a vehicle, etc. The memory 115 may further 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 disk (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 the processor 103.

[0014] The 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. The processor 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). The processor 103 and its associated components may enable the system 101 to execute a set of computer readable instructions, such as, for example, determining a risk unit balance in a risk unit account to receive and analyze driver data, vehicle data, and / or driving movement data, determining a rate at which risk units are consumed (e.g., based on the analyzed driver data, vehicle data, external data, etc.), and / or automatically refilling the risk unit account balance upon determining that the balance has reached a predetermined threshold.

[0015] A computing device (e.g., a personal mobile device, a vehicle-based system, an insurance system server, etc.) may operate in a networked environment 100 supporting connections to one or more remote computers, such as terminals 141, 151, and 161. Such terminals may be personal computers or servers 141 (e.g., a home computer, a laptop, a web server, a database server), mobile communication devices 151 (e.g., a mobile phone, a tablet computer, etc.), vehicle-based computing systems 161 (e.g., an in-car system, a telematic device, a mobile phone or other personal mobile device inside a vehicle), etc., each of which may include some or all of the elements described above with respect to the computing device 101. The network connections illustrated in FIG. 1 include a local area network (LAN) 125 and a wide area network (WAN) 129, as well as a wireless telecommunications network 133, but may also include other networks. When used in a LAN networking environment, the computing device 101 may be connected to the LAN 125 through a network interface or adapter 123. When used in a WAN networking environment, the device 101 may include a modem 127 or other means for establishing communications over the WAN 129, such as a network 131 (e.g., the Internet). When used in a wireless telecommunications network 133, 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 consumer 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.

[0016] FIG. 1 further illustrates a security and integration layer 160 through which communications are routed and managed between the device 101 (e.g., a personal mobile device, a vehicle-based computing device, an insurance server, an intermediate server, and / or an external data source server, etc.) and the remote devices (141, 151, and 161) and remote networks (125, 129, and 133). The security and integration layer 160 may include 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. As an example, the security and integration layer 160 of the server 101 may include a set of web application servers configured to secure protocols and isolate the device 101 from the external devices 141, 151, and 161. In some cases, the security and integration layer 160 may correspond to a set of dedicated hardware and / or software operating in the same physical location and under the control of the same entity as the device 101. For example, layer 160 may correspond to one or more dedicated web servers and network hardware in a vehicle and driver information data center or in a cloud infrastructure supporting cloud-based vehicle identification and vehicle and driver data search and analysis. In another example, security and integration layer 160 may correspond to separate hardware and software components that may be operated at separate physical locations and / or by separate entities.

[0017] As described below, data transferred to and from various devices within the risk unit based insurance system 100 may include secure sensitive data, such as confidential vehicle operation data, insurance policy data, and confidential user data from the driver and passengers within the vehicle. It may therefore be desirable to protect the transmission of such data by using secure network protocols and encryption, and further protect the integrity of the data when stored on various devices within the personal insurance system, such as personal mobile devices, vehicle-based devices, insurance servers, external data source servers, or other computing devices within the system 100, by authenticating users and restricting access to unknown or unauthorized users using the security and integration layer 160. In various implementations, the security and integration layer 160 may provide, for example, a file-based or server-based integration scheme for transmitting data between various devices within the 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 data integrity, e.g., File Transfer Protocol (FTP), Secure File Transfer Protocol (SFTP), and / or Pretty Good Privacy (PGP) encryption. In another example, one or more web services may be implemented within the various devices 101 in the system 100 and / or security and integration layer 160. The web services may be accessed by authorized external devices and users to support the input, retrieval, and manipulation of data (e.g., vehicle data, driver data, driving movement data, etc.) between the various devices 101 in the system 100. Web services built to support the personal display system may be cross-domain and / or cross-platform and built for business use.Such web services may be developed according to various web service standards, such as Web Services Interoperability (WS-I) guidelines. In some examples, driver data, vehicle data, and / or driving mobility data analysis web services, risk unit-based insurance policy adjudication or provisioning web services, etc. may be implemented in the security and integration layer 160 using Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocols to provide secure connections between the server 101 and the various clients 141, 151, and 161. SSL or TLS may provide authentication and confidentiality using HTTP or HTTPS. In another example, such web services may be implemented using the WS-Security standard, which provides secure SOAP messages with XML encryption. In yet other examples, the security and integration layer 160 may include specialized hardware for providing secure web services. For example, a secure network appliance in the security and integration layer 160 may include built-in features such as hardware accelerated SSL and HTTPS, WS-Security, and a firewall. Such specialized hardware may be installed and configured within the security and integration layer 160 in front of the web server, thereby allowing any external device to communicate directly with the specialized hardware.

[0018] Although not shown in FIG. 1 , various elements within memory 115 or other components in system 100 may include one or more caches, such as a CPU cache used by processing unit 103, a page cache used by operating system 117, a disk cache on a hard drive, and / or a database cache used to cache content from database 121. For embodiments that include a CPU cache, the CPU cache may be used by one or more processors in processing unit 103 to reduce memory latency and access times. In such an example, processor 103 may retrieve or write data to the CPU cache rather than reading / writing to memory 115, which may improve the speed of these operations. In some examples, a database cache may be created in which certain data from 121 (e.g., databases of driver data, driving behavior 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., on a personal mobile device, vehicle-based data, or an intermediate network or cache device, etc.). For example, in a multi-tier application, a database cache on the application server can reduce data lookup and data manipulation times by not having to communicate over a network to a back-end database server. These types of caches and the like 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 reduced dependency on network conditions when sending and receiving driver information, vehicle information, driving movement information, insurance parameters, account balance information, and the like.

[0019] It will be appreciated that the network connections shown are exemplary and that other means of establishing a communications link between the computers may be used. Any of a variety of network protocols, such as TCP / IP, Ethernet, FTP, HTTP, etc., and any of a variety of wireless communication technologies, such as GSM, CDMA, WiFi, and WiMAX, are contemplated, and the various computing devices within the risk unit based insurance system components described herein may be configured to communicate using any of these network protocols or technologies.

[0020] Additionally, one or more application programs 119 may be used by the various computing devices 101 within the risk unit based insurance system 100 (e.g., vehicle data, driver data, and / or driving movement data analysis software application, insurance parameter determination software application, risk unit account application, etc.) and include computer executable instructions to receive and analyze various driver data, vehicle data, and / or driving movement data, determine parameters for risk unit insurance policies, offer risk unit based insurance policies via equipment within the risk unit based insurance system, determine the rate at which risk units are consumed during vehicle operation, and evaluate and / or automatically replenish risk unit account balances using the risk unit based insurance system equipment.

[0021] 2 is a schematic diagram of an example risk unit based insurance system 200. The risk unit based insurance system 200 may be associated with, within, or operated by an entity 201, such as an insurance provider. In some examples, the entity may be one of a variety of other types of entities, such as a government entity, a corporation or business, a university, etc. Various examples described herein are discussed in the context of an insurance provider. However, nothing herein should be viewed as limiting the use of the systems, methods, configurations, etc. described herein to use only by insurance providers.

[0022] The risk unit based insurance system 200 may include one or more modules, which may include hardware and / or software configured to perform various functions within the system 200. One or more of the modules may be separate physical devices, or in another example, one or more of the modules may be part of the same physical device.

[0023] 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 provide insurance to an average user for a given period of time. For example, the risk unit module 202 may receive data such as insurance data from the insurance data store 204, regional data from the regional data store 206, as well as other data (from unillustrated data stores that may be internal to the entity 201 or external to the entity 201) and determine a cost to provide insurance to an average user for a given period of time (e.g., one month, one week, one day, one year, etc.) based on the received data. This cost may be considered to be equivalent to one risk unit. Additionally, a cost for a user or insurance policy holder to purchase a risk unit may be determined by the system. This cost may be different from the cost of forming a risk unit and may be determined at a fixed date. And the cost to a user may be revised at a second date (e.g., monthly, annually, etc.). In this manner, insurance may be provided to one or more users based on risk units as more fully described herein.

[0024] The risk unit based insurance system 200 may further include a policy module 208. The policy module 208 may use the risk units to generate and / or store insurance policy information or factors, such as vehicle information, driving record / experience, policy limits, deductibles, etc., in addition to insurance policies. 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 a user, for example, when the user drives or operates his / her vehicle. The risk units may be consumed based on traditional policy factors, such as driving experience, driving record, credit variables, policy coverage, deductibles, policy limits, driver familiarity with the vehicle or its surroundings, in addition to sensor data-centric factors, such as elapsed time, the user's driving habits, the environmental conditions in which the user operates the vehicle, vehicle parameters (e.g., year, make, model, features, specifications, etc.), vehicle status or performance (e.g., based on sensor data), etc. In some examples, one policy parameter may include a level of coverage. For example, as described more fully herein, risk units may be purchased at various levels, with each level providing a different level of coverage. Additionally or alternatively, consumption rates may reflect the different levels of coverage.

[0025] The risk unit based insurance policy may further include a risk unit account stored in the 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 with risk unit based insurance policies), vehicles (e.g., vehicles associated with risk unit based insurance policies), and the like. The accounts may include information associated with the vehicles, such as vehicle identification number, make, model, year, and the like, in addition to information associated with the users, such as name, address, contact information, and the like. Additionally, the accounts may include the number of risk units associated with or available to the users or account holders associated with the vehicles, and the like. In this manner, if a user has a risk unit based insurance policy that includes a purchase of 100 risk units, the user's account will show 100 risk units in the purchase. As risk units are consumed (e.g., by the user operating the vehicle, and the like), the balance of risk units in the account may decrease. In some examples, the balance of risk units in the account may be displayed to the user via a computing device, such as one or more of the computing devices 212a-212f. For example, the risk unit account balance may be displayed via an application (e.g., an online or mobile application) on a smart phone 212a, personal digital assistant (PDA) 212b, tablet 212c, cell phone 212d, or other computing device 212e. In some examples, the risk unit account balance may be displayed to the user on a vehicle display 212f. In addition to displaying the account balance, various other account details may be displayed as desired.

[0026] In some configurations, the risk unit account may include other types of units (e.g., other than risk units). For example, the risk unit account may include funds or monetary amounts or balances. The balance of the funds may be reduced based on vehicle operations, as described above. In some examples, the risk units may be converted to funds to facilitate this reduction in the balance (e.g., the consumption rate of the units based on the vehicle operations may be determined in risk units and converted to funds to appropriately reduce the balance in the account). In other examples, the consumption rate may be determined in appropriately reduced monetary units and balances. Although various configurations disclosed herein are described in terms of consumption rates determined in risk units and balances of the account, including correspondingly reduced numbers of risk units, various other units (e.g., monetary units) may be used without departing from this invention.

[0027] 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 resulting from vehicle operation (e.g., when a user operates a vehicle, the number or balance of risk units in a risk unit account is reduced based on the determined consumption rate, thereby depleting the balance associated with the policy. Once the risk unit balance reaches a predetermined threshold, the number of risk units may be replenished, similar to a traditional insurance policy). As discussed above, the consumption rate may be determined in risk units, monetary units, or other units, as desired.

[0028] As discussed above, the rate at which risk units are consumed by a user (e.g., by the user's operation of the vehicle) may be based on a variety of factors, such as the user's personal information, the user's driving habits or behavior, environmental conditions, local or geographic conditions, the type of road traveled, traditional policy factors, coverage, vehicle characteristics or operations, etc. Various algorithms may be used to determine the consumption rate. For example, Equation 1 is one example that may be used to determine the consumption rate based on factors that focus on sensor data, and may include the following:

[0029] Formula 1: RC1=L1×R1×T1×B1×E1, in the formula, RC1 is the consumption rate, L1 is a location factor that may include population density, traffic volume, new routes, popular routes, etc. R1 is a road condition factor that may include road type, road shape, road hazards, etc. T1 is the time factor, B1 is a driver behavior factor, which may include braking speed, acceleration, cornering, travel time, derailment, distracted driving, etc. E1 is an environmental factor that may include weather conditions, speed depending on the situation, etc.

[0030] Equation 2 is another example that may be used to determine a consumption rate based on traditional policy factors in addition to sensor data focused factors, which may include:

[0031] Formula 2: RC2=O2×P2×V2×C2×L2×R2×T2×B2×E2, in the formula, RC2 is the consumption rate, O2 is an operator factor, which may include the driver's age, sex, marital status, driving experience, driving record, etc. P2 is a policy factor, which may include credit variables, number of vehicles associated with the policy or driver, number of operators or drivers associated with the policy, prior insurance, multiple policies, etc. V2 is a vehicle factor, which may include vehicle identification number, aftermarket parts, vehicle features or specifications, vehicle condition, maintenance history, etc. C2 is a coverage factor, which may include coverage provided, policy or coverage limits, deductibles, etc. L2 is location factors that may include population density, traffic volume, new routes, popular routes, etc. R2 is a road condition factor that may include road type, road shape, road hazards, etc. T2 is the time factor, B2 is a driver behavior factor, which may include braking speed, acceleration, cornering, travel time, derailment, distracted driving, etc. E2 are environmental factors that may include weather conditions, speed depending on the situation, etc.

[0032] Additionally, either Equation 1 or Equation 2 may further include an expense factor. In some examples, an expense value may be added to the result of Equation 1 or Equation 2 to determine the consumption rate.

[0033] Further, although Equation 1 and Equation 2 are provided as examples for determining the consumption rate, various other formulas and / or algorithms may be used without departing from this invention. For example, one or more factors may be removed from the formula to determine the consumption rate. Additionally or alternatively, other factors may be included in the formula without departing from this invention.

[0034] In this manner, one or more sensors 216 may be used to obtain data that can be used to determine a consumption rate for a user. For example, the one or more sensors may include sensors for detecting a user's driving behavior, such as sudden braking, speeding, etc. In another example, the one or more sensors may be used to detect environmental conditions, such as rainfall, humidity, cloud cover, etc. In yet another example, the one or more sensors may be used to determine road conditions or obtain information from an external source (e.g., an external database, etc.) about traffic conditions, road types (e.g., two-lane roads, four-lane roads), road speed limits, etc. Data from the one or more sensors 216, which may include data from a combination of different types of sensors, may be used by the risk unit consumption rate module 214 to determine a risk unit consumption rate for a user.

[0035] In examples where the consumption rate is determined based on traditional policy factors (either combined with sensor data focused factors or alone), the traditional policy factors, e.g., driving record, credit information, driving experience, vehicle characteristics and / or specifications, coverage, deductibles, policy limits, etc., may be obtained from, for example, the 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, for example, according to changes in the user's driving behavior, according to changes in road types, according to changes in environmental conditions. Thus, for example, if the user is driving faster 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 rain. This is merely one example of how the consumption rate may be changed based on received sensor data and should not be seen as limiting the present disclosure to only this example. Rather, various other changes in the received sensor data may be used to change or modify the risk unit consumption rate for the user.

[0036] Similar to risk unit account information, the risk unit consumption rate may be displayed to the user, for example, via one or more computing devices 212a-212f. In some examples, the risk unit consumption rate module 214 may generate and / or display to the user suggestions for improving the consumption rate. For example, the system may generate an alternative route that is determined to be safer than the user's current route, and thus, by taking the alternative route, the consumption rate may be reduced. In another example, the user may be driving faster than the posted speed limit. The system may generate guidance that displays (e.g., via the computing devices 212a-212f) to the user indicating that the user may reduce their consumption rate by slowing down. These are just a few examples of messages that may be displayed to assist the user in reducing the consumption rate of risk units. However, various other suggestions or changes in driving behavior may be generated and provided to the user without departing from this invention.

[0037] 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. In some examples, the risk unit marketplace may be used to replenish a user's risk unit account. For example, when a user reaches a predefined threshold within the user's risk unit account (e.g., when the balance of risk units within the account reaches a certain threshold), the user may be notified that the balance of risk units within the account is low and may be offered one or more options to purchase additional risk units or otherwise increase the balance of risk units within the account.

[0038] For example, in some cases, when a threshold number of risk units within an account is reached, a notification may be displayed to the user (e.g., via one or more of computing devices 212a-212f) indicating a low balance and offering to sell additional risk units. In some examples, the user may store credit card or other payment information (e.g., account information, debit card information, electronic funds transfer information, etc.) within the system (e.g., within the risk unit marketplace 218) so that upon receiving the notification, the user may select a "purchase" option so that 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 auto-replenish option. In such a configuration, the user may enter payment information (e.g., credit card information, debit card information, current or other account information, electronic funds transfer information, etc.) and identify a predetermined threshold below which the system may automatically purchase additional risk units. These and various other configurations are described more fully below.

[0039] The risk unit marketplace 218 may also offer risk units for sale to other users or insurers. For example, a user may obtain insurance through different insurers, but the risk unit may be a common unit among multiple insurers. In this manner, a user with insurance policies from other insurers may purchase risk units from the risk unit marketplace 218 and have risk units deposited in accounts associated with policies offered by or associated with other insurers. In some examples, the entity 201 may charge a service fee or surcharge for purchasing risk units for use with policies offered by another insurance carrier.

[0040] FIG. 3 is an exemplary system diagram of a driving analysis system 300 that includes additional aspects of and / or implements the risk unit-based insurance system 200 shown in FIG. 2. The system includes a vehicle 310, a personal mobile device 330, an insurance system server 350, and additional related components. As described below, the components of the system 300 may individually or through communication and collaborative interaction determine, present, and implement various types of risk unit-based insurance for customers, provide or facilitate the purchase of risk unit-based insurance policies and / or associated risk units, determine the consumption rate of risk units, communicate the consumption rate to the user, and generate and provide suggestions to reduce the consumption rate to the user. To perform such functions, the components shown in FIG. 3 may each be incorporated in hardware, software, or a combination of the two. In addition, each component of the system 300 may include a computing device (or system) having some or all of the structural components described above for the computing device 101.

[0041] The vehicle 310 in the system 300 may be, for example, an automobile, motorcycle, scooter, bus, recreational vehicle, boat, or other vehicle from which vehicle data, geographical data, driver data (or operator data), operational data, and / or other operational data (e.g., geographical data, time data, weather data, etc.) may be collected and analyzed. The vehicle 310 includes vehicle operational sensors 311 (similar to one or more of sensors 216a-c of FIG. 2) that can detect and record various conditions on the vehicle and operational parameters of the vehicle. For example, the sensors 311 may detect and store data corresponding to the vehicle's geography (e.g., GPS coordinates), time, duration of trip, speed and direction, acceleration or braking speed, fuel economy, and specific instances of sudden acceleration, braking, derailment, and distance traveled. The sensors 311 may also detect and store data received from internal systems of the vehicle 310, such as impacts to the vehicle body, deployment of airbags, use of headlights, operation of brake lights, opening and closing of doors, locking and unlocking of doors, use of cruise control, use of hazard lights, use of windshield wipers, use of the horn, use of turn signals, use of seat belts, use of the phone and radio in the vehicle, use of the autonomous driving system, maintenance performed on the vehicle, and other data collected from the vehicle's computer systems, including the on-board diagnostics system (OBD).

[0042] Additional sensors 311 may detect and store external driving conditions, such as external temperature, rain, snow, light levels, and the position of the sun relative to the driver's field of view. For example, 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 be taken into account in driving data / behavior analysis. Sensors 311 may also detect and store data regarding traffic violations and observance of traffic signals and signs by vehicle 310. Additional sensors 311 may detect and store data regarding the maintenance of vehicle 310, such as engine condition, oil level, engine coolant temperature, odometer reading, level of fuel in the fuel tank, engine revolutions per minute (RPM), software upgrades, and / or tire pressure.

[0043] The vehicle sensors 311 may further include cameras and / or proximity sensors capable of recording additional conditions inside and outside the vehicle 310. For example, the interior cameras may detect conditions such as the number of passengers and types of passengers (e.g., adults, children, teenagers, pets, etc.) in the vehicle, and possible sources of driver distraction inside the vehicle (e.g., pets, phone use, and non-fixed objects in the vehicle). The sensors 311 may further be configured to collect data to identify the current driver among many different possible drivers based on, for example, the driver's seat and mirror positioning, driving time and route, radio use, etc. The voice / acoustic data may further be used along with the directional data to determine the seat position inside the vehicle 310. The sensors 311 may also be configured to collect data regarding the driver's movements or the driver's conditions. For example, the vehicle 310 may include sensors that monitor the driver's movements, such as the driver's eye position and / or head position. Additional sensors 311 may collect data regarding the driver's physical or mental state, such as fatigue or intoxication. The driver's status may be determined through the driver's movements or through other sensors, such as a breathalyzer, that detect the alcohol content in the air or the driver's blood alcohol content, along with other biometric sensors.

[0044] Certain vehicle sensors 311 may also collect information regarding the driver's route choices, whether the driver is following a given route, and classify types of trips (e.g., commuting, errands, new routes, etc.) and types of driving (e.g., continuous driving, parking, stop-and-start traffic, etc.). In certain embodiments, sensors and / or cameras 311 may determine when and how often the vehicle 310 remains in a single lane or veers into other lanes. Global positioning systems (GPS), location sensors positioned inside the vehicle 310, and / or location sensors or equipment external to the vehicle 310 may be used to determine route, speed, lane position, road type (e.g., freeway, on / off ramps, residential streets, etc.), and other vehicle location / geographical data.

[0045] Data collected by the vehicle sensors 311 may be stored and / or analyzed within the vehicle 310, such as in a driving analysis computer 314 embedded in the vehicle, and / or may be transmitted to one or more external devices. For example, as shown in FIG. 3, the sensor data may be transmitted via a telematic device 313 to one or more remote computing devices, such as a personal mobile device 330, an insurance system server 350, and / or other remote devices.

[0046] As shown in FIG. 3, data collected by the vehicle sensors 311 may be transmitted via the telematic device 313 to the insurance system server 350, the personal mobile device 330, and / or additional external servers and devices. The telematic device 313 may be one or more computing devices that encompass many or all of the hardware / software components illustrated as the computing device 101 in FIG. 1. As described above, the telematic device 313 may receive vehicle operation and driving data from the vehicle sensors 311 and transmit the data via a wireless transmission network to one or more external computer systems (e.g., the insurance system server 350 of an insurance company, financial institution, or other entity). The telematic device 313 may be further configured to detect or determine additional data types related to the real-time driving and status of the vehicle 310. In addition to the type of vehicle 310, such as make, model, trim (or submodel), year, and / or engine use, the telematics device 313 may further store other information about the vehicle 310, such as vehicle owner or operator information, insurance information, and financing information.

[0047] 3, the telematic devices 313 may receive vehicle driving data from the vehicle sensors 311 and may transmit the data to the insurance system server 350. However, in another example, one or more of the vehicle sensors 311 or systems may be configured to receive and send data directly from or to the insurance system server 350 without the use of telematic devices. For example, the telematic devices 313 may be configured to receive and send data from the vehicle sensors 311 or systems, while other sensors or systems may be configured to receive and / or transmit data directly to the insurance system server 350 without the use of telematic devices 313. As such, the telematic devices 313 may be optional in certain embodiments.

[0048] The system 300 of FIG. 3 further includes a mobile device 330. The mobile device 330 may be, for example, a smartphone or other mobile phone, a personal digital assistant (PDA), a tablet computer, etc., and may include some or all of the elements described above with respect to the computing device 101. As shown in this example, some mobile devices in the system 300 (e.g., mobile device 330) may be configured to establish communication sessions with vehicle-based equipment and various internal components of the vehicle 310 via a wireless network or a wired connection (e.g., a docking device), whereby such mobile devices 330 may have secure access to the internal vehicle sensors 311 and other vehicle-based systems. However, in another example, the mobile devices 330 may not be connected to the vehicle-based computing equipment and internal components, and may operate independently by communicating with the vehicle 310 via their standard communication interfaces (e.g., telematic equipment 313, etc.), or may not be connected to the vehicle 310 at all.

[0049] The 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 the mobile device 330 to communicate with the insurance system server 350, the 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 the risk unit based insurance application 335 may be received from the insurance server 350, the vehicle 310, or other application vendors (e.g., application stores) via the network interface 321. As described below, the driving analysis application 334 and the risk unit based insurance application 335 may or may not include various user interface screens and may be configured to operate as a user-initiated application or as a background application. The memory of the mobile device 330 may further include a database configured to receive and store vehicle data, driving data, driving movement data, etc. associated with one or more drivers and / or vehicles.

[0050] Similar to the vehicle-based computing devices in the vehicle 310, the mobile device 330 may further 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, the driving analysis software application 334 may be able to identify start and stop points of a driving trip and determine driving speed, time, route, etc. Additional components of the mobile device 330, such as an accelerometer, compass, and various camera and proximity sensors, may be used to generate or receive driving data for the driving data analysis application 334 and / or the risk unit based insurance application 335. As described below, these and other mobile device components may be used to identify start and stop points and other characteristics of a driving trip and receive, store, and output various user / driver data for determining various driving data, such as speed, driving route and time, acceleration, braking, and turning data, and other driving conditions and behaviors, etc. In some implementations, the driving analysis software application 334 may store and analyze 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, etc.

[0051] When a mobile computing device within the vehicle is used to detect vehicle driving data and / or receive vehicle driving data from vehicle sensors, such mobile computing device 330 may store, analyze, and / or transmit vehicle driver data (e.g., data identifying the current driver), driving data (e.g., speed data, acceleration, braking, and turning data, and any other vehicle sensor or operation data), and driving movement data (e.g., driving route, driving time, driving destination, etc.) to one or more other devices. For example, the mobile computing device 330 may transmit the driver data, driving data and driving behavior, and driving movement data directly to one or more insurance servers 350 and may be used in conjunction with or in place of the telematic device 313. The processing components of the mobile computing device 330 may also be used to identify vehicle drivers and passengers, analyze vehicle driving data, analyze driving movements, determine parameters related to aspects of risk unit-based insurance policies, and perform other related functions. Thus, in certain embodiments, the mobile computing device 330 may be used in conjunction with or in place of the insurance system server 350 .

[0052] The vehicle 310 may include a driving analysis computer 314 that may be a separate computing device or may be integrated into one or more other components within the vehicle 310, such as a telematic device 313, an autonomous driving system, or an internal computing system of the vehicle 310. As mentioned above, the driving analysis computer 314 may further be implemented by a computing device independent of the vehicle 310, such as a driver's or passenger's mobile computing device 330, or one or more separate computer systems (e.g., a user's home or office computer). In any of these examples, the driving analysis computer 314 may encompass some or all of the hardware / software components such as the computing device 101 illustrated in FIG. 1. Furthermore, in certain implementations, the functionality of the driving analysis computer, such as storing and analyzing driver data, vehicle data, driving data, and driving behavior, and determining, presenting, and implementing aspects of a risk unit-based insurance policy, may be performed by a central insurance system server 350, rather than by the individual vehicles 310 or personal mobile devices 330. In such implementations, the vehicle 310 and / or mobile device 330 may only collect and transmit driver data, vehicle data, driving data, etc. to the insurance server 350, and the vehicle-based driving analysis computer 314 may be optional.

[0053] The system 300 may also include one or more insurance system servers 350 that encompass some or all of the hardware / software components such as the computing device 101 illustrated in FIG. 1. The insurance system server 350 may include hardware, software, and network components for receiving driver data, vehicle data, and vehicle operation / 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 a risk unit-based insurance system 351 for storing and analyzing the driver data, vehicle data, and driving data, etc., received from the vehicles 310, mobile devices 330, and other data sources, respectively. In some examples, the risk unit-based insurance system 351 may include many or all of the components of the risk unit-based insurance system 200 described with respect to FIG. 2.

[0054] The insurance system server 350 may initiate communication with and / or retrieve driver data, vehicle data, and driving data from the vehicle 310, wirelessly via the telematic device 313, the mobile device 330, or via a separate computing system over one or more computer networks (e.g., the Internet). In addition, the insurance system server 350 may receive additional data from other third party data sources, such as an external traffic database containing traffic data at various times and locations (e.g., traffic volume, average driving speed, traffic speed distribution, and accident numbers and types, etc.), an external weather database containing weather data at various times and locations (e.g., rain, snow, freezing rain, and hail amounts, temperature, wind, road conditions, visibility, etc.), and other external data sources containing driving hazard data (e.g., road hazards, traffic accidents, fallen trees, power outages, road construction zones, school zones, and natural disasters, etc.), route and navigation information, and an insurance company database containing insurance data (e.g., driver score, coverage amount, deductible, premium, coverage status) for the vehicle, driver, and / or other nearby vehicles and drivers.

[0055] The data stored in the insurance database 352 may be organized in any of several different ways. For example, a driver table in database 352 may contain all of the driver data (e.g., driver personal information, insurance account information, demographic information, accident history, risk factors, driving scores, and driving logs, etc.) for drivers associated with an insurer, a vehicle table may contain all of the vehicle data (e.g., vehicle identifier, make, model, year, accident history, maintenance history, trip logs, estimated repair costs and overall value, etc.) for vehicles associated with an insurer, and a driving trip table may store all of the driving trip data (e.g., driving trip driver, vehicle driven, trip time, start and end points, route driven, etc.) for drivers and vehicles associated with an insurer. Other tables in database 352 may store additional data, including the data types described above (e.g., traffic information, road type and road condition information, weather data, insurance policy data, etc.). In addition, one or more other databases of other insurers that contain additional driver and vehicle data may be accessed to retrieve such additional data.

[0056] 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 directly receive driver data, vehicle data, and driving movements from the vehicle 310, the mobile device 330, or other data sources, and may perform driving data analysis to determine insurance parameters for the risk unit based insurance policy and perform other related functions. The functions performed by the risk unit based insurance analysis system 351 may be performed by specialized hardware and / or software that is separate from the additional functionality of the insurance system server 350. Such functions may be similar to those of the driving analysis module 314 of the vehicle 310 and the driving analysis and risk unit based insurance applications 334 and 335 of the mobile device 330, and further descriptions and examples of algorithms, functions, and analyses that may be performed by the risk unit based insurance system 351 are described below, including with reference to Figures 4-9.

[0057] In various examples, the driving data and driving movement analysis and / or risk unit based insurance adjudication may be performed entirely within the insurance system server 350, entirely within the vehicle based driving analysis computing module 314, or entirely within the driving analysis and risk unit based insurance applications 334 and 335 of the mobile device 330. In another example, certain analysis of the driver data, vehicle data, and driving movement data and certain risk unit based insurance adjudication may be performed by the vehicle based device (e.g., within the driving analysis module 314) or the mobile device 330 (e.g., within the applications 334 and 335), while other data analysis and risk unit based insurance adjudication are performed by the risk unit based insurance system 351 at the insurance system server 350. For example, the vehicle-based driving analysis computer 314, or hardware and software components of the mobile device 330, may continuously receive and analyze driver data, vehicle data, driving movement data, etc. to determine certain events and characteristics (e.g., initiation of a driving movement, identification of the driver, determination of a driving route or intended destination, driving data and behavior during a driving movement, etc.), thereby eliminating the need to transmit large amounts of data to the insurance system server 350. However, after the driver, vehicle, and / or driving movement are determined by the vehicle-based device and / or mobile device, for example, corresponding information may be transmitted to the insurance server 350 to make insurance proposals and cost determinations, determine risk unit consumption rates, generate one or more recommendations for reducing consumption rates, etc., which may be transmitted back to the vehicle-based device and / or personal mobile device.

[0058] FIG. 4 is a flow chart illustrating an example of a method for providing risk unit-based insurance to a user according to one or more aspects described herein. In step 400, a risk unit is determined. As described above, the risk unit may be a general insurance unit representing the cost of providing insurance to an average user for a period of time. For example, a risk unit may be determined to provide insurance to an average user for a week, a month, a year, etc. The risk unit may be used to provide insurance such that a user may obtain a risk unit-based insurance policy where, for example, as the user operates a vehicle, the number of risk units in a risk unit account decreases based on a consumption rate determined for the user, travel, etc. These and other aspects are described more fully herein.

[0059] In step 402, a request for a risk unit based insurance policy is received. The request may be received from a user and in some examples may be received via a computing device (e.g., a mobile device, etc.). The request may include information associated with the user, such as vehicle information including name, contact information, make, model, year, vehicle identification number, etc. In some examples, the request for a risk unit based insurance policy may include a level of coverage. For example, similar to a traditional insurance policy, the user may select from various levels of protection (e.g., whether to include collision vehicle coverage, personal property coverage, etc.). Similarly, the user may select the level of risk units on which the policy is based. In one example, three levels may be used for the user, with the highest level of risk units providing the greatest coverage and in some cases having the highest cost (e.g., cost per risk unit). A second level may provide a narrower coverage at less cost, and a third level may provide the lowest level of coverage at the least cost. In another example, the different levels of selected coverage may be reflected in the consumption rate of the units. For example, the consumption rate may vary based on the selected coverage level. Different levels of coverage may be available to the user, but the suggested level may meet minimum standards for insurance coverage, such as those required by the area in which the user lives.

[0060] Further, although three levels of risk units are described in the above examples, more or less levels of risk units and corresponding insurance coverage may be provided without departing from the present invention.

[0061] In step 404, a risk unit-based insurance policy for the user is generated and a risk unit account for the user is created. The risk unit account may be associated with a user or a vehicle. That is, the risk unit-based insurance policy may provide coverage for a vehicle regardless of which user is operating the vehicle, or may provide coverage for any vehicle operated by a particular user. Thus, in some examples, the user or operator of the vehicle may be identified (e.g., at the start of vehicle operation) to determine whether coverage is provided or what type of coverage is provided.

[0062] In step 406, a predetermined number of risk units is deposited into the created account. The predetermined number or risk units may be based on one or more policy parameters (e.g., the term or length of the policy) and / or one or more user settings.

[0063] At step 408, data associated with the user's driving behavior and / or the environmental conditions in which the vehicle is operating is received. As discussed above, data may be received from one or more sensors associated with the vehicle, as well as from a variety of other sources, such as traffic, weather, road conditions, etc. As disclosed herein, the received data may include speed, braking habits of the user or operator, the type of road being traveled on, time of day, traffic levels, amount of precipitation, etc.

[0064] At step 410, a consumption rate of risk units in the risk unit account may be determined based on the received data. As disclosed herein, the consumption rate may be higher based on various behaviors and / or situations determined to involve more risk to the user, vehicle, etc. For example, if the user is driving at a 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, if the user is driving outside of rush hours, but not during peak driving hours, the consumption rate may be determined to be lower. In yet another example, if data is received that it is raining or snowing on the route the vehicle is traveling, the consumption rate may be increased. As discussed above, the consumption rate may also be based at least in part on traditional policy factors, such as driving experience, driving record, credit factors, coverage, deductibles, etc. Data regarding various behaviors and situations and / or traditional policy data may be combined to determine a consumption level in real time or near real time as the user is operating the vehicle. In this manner, the system may provide the user with information associated with the consumption rate. For example, the vehicle display or the user's mobile device may include an indication of the current consumption rate. In another example, the display may include historical information associated with consumption rates for previous trips and / or a graphical display of previous and / or current consumption rates.

[0065] 5 illustrates one example of a user interface 500 that may be provided to a user (e.g., via a vehicle display, a mobile device, or other computing device) to provide information associated with consumption rates. Interface 500 includes fields 502 and 504 in which the vehicle and vehicle operator, respectively, are identified. Field 506 indicates the date and time of the current trip. In some examples, the elapsed time of the current trip may also be displayed.

[0066] Field 508 indicates that data is being received. As disclosed herein, data associated with one or more sensors detecting a user's driving behavior, environmental conditions, etc. 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. If communication is lost, field 508 may indicate that data has not been received or that an error has occurred. In some such example scenarios, the system may apply a more recently determined consumption rate until data communication is restored and more current data is received by the system.

[0067] Field 510 provides a calculated or determined current consumption rate. As described herein, the consumption rate may be based on a variety of factors, which may include driving behavior, environmental conditions, etc., as determined based on data received by the system. Field 512 provides a list of historical consumption rate information that may be useful for a user to track consumption rates.

[0068] With further reference to FIG. 4, in step 412, the balance of risk units in the risk unit account is decreased based on the consumption rate determined in step 410. When the balance in the risk unit account is decreased, 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 example, in step 414, a determination is made as to whether the 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 government or other regulatory body specifications, or may be determined by the user or insurer. In some examples, the threshold may be a percentage of the number of risk units acquired with the policy (e.g., a percentage of the total account balance). For example, the threshold may be 10%, 15%, or any other percentage of the total number of risk units acquired with the policy. In another example, the threshold may be a number of risk units. For example, the threshold may be 50, 100, or any other number of risk units.

[0069] If, at 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 rates. If, at step 414, the balance is below the predetermined threshold, the user may be provided with one or more replenishment options at step 416. The replenishment options may include providing the user with a notification regarding the current balance and / or providing options for automatic replenishment, user requested replenishment, policy cancellation, purchasing a new policy and associated risk units, etc. Once a replenishment option has been presented, the system may return to step 408 to continue receiving data, etc.

[0070] 6 illustrates one example of a method for replenishing risk units according to one or more aspects described herein. In step 600, a determination is made as to whether the balance of risk units in the risk unit account falls below a predetermined threshold, similar to step 414 of FIG. 4. If not, the system may return to the process where data is received and consumption rates are determined, e.g., step 408 of FIG. 4. If the balance falls below the threshold in step 600, a notification is sent to the user in step 602. The notification may include an indication that the risk unit account falls below the threshold and / or may provide instructions for replenishing the account.

[0071] In step 604, a determination is made as to whether the account is set up for automatic replenishment. That is, the system may determine whether the user has previously selected an option to automatically replenish the balance in the account (e.g., by automatically purchasing additional risk units using pre-stored payment information). If so, the system may automatically purchase a predetermined number of units in step 606, charge the associated costs against pre-stored payment information (e.g., credit card information, account information, debit card information, etc.), and deposit the purchased risk units in the account.

[0072] If, in step 604, it is determined that the account is not set up for automatic replenishment, then, in step 608, the user may respond to the notification sent in step 602 with a request to replenish the account balance. The request may include the number of units to purchase, payment information, risk unit account information, policy information, etc. In step 610, the specified number of risk units may be purchased and deposited in the risk unit account.

[0073] Figures 7A-7D illustrate examples of user interfaces 700a-700d that may be used to effect replenishment or top-up of risk units in a risk unit account. Although interfaces 700a-700d are shown in Figures 7A-7D as being displayed on a mobile device, the interfaces provided may be displayed on a variety of different types of computing devices including, for example, a vehicle display, a laptop or desktop computing device, a tablet computing device, etc.

[0074] FIG. 7A illustrates an interface 700a through which a notification is provided to a user. The notification 700a indicates that the risk unit account is below a minimum threshold and provides an option for the user to go ahead and replenish the current account balance or to request that the system remind the user later. If the user selects the option to remind later, the notification may be automatically prompted again at a predetermined time (e.g., daily, hourly, 48 hours after selecting the option to remind later, etc.) or upon some continued consumption of risk units. In this manner, additional notifications may be provided to the user as the balance in the risk unit account continues to decrease. In some examples, a determination of a balance below a predetermined level (e.g., below a replenishment notification level) may result in various actions being taken on the vehicle. For example, the system may flash the headlights or honk the horn while driving, prevent the vehicle from starting, etc., if there is an insufficient number of risk units in the account.

[0075] If the yes option in 700a is selected, interface 700b shown in FIG. 7B, or a similar interface, may be displayed where the user may enter details of one or more risk unit accounts, such as an account number and / or a name associated with the account. In some examples, this information may be pre-populated automatically based on the user, vehicle, and / or mobile device associated with the account. The user may select to continue with the prompting option of interface 700c in FIG. 7C, or a similar interface, which provides fields where the user may enter payment information. Information such as credit card number, expiration date, cardholder name, etc. may be provided by the user. In FIG. 7C, credit card information is provided as an example of payment information, although various other payment types may be used, such as electronic funds transfer, debit card, pre-paid debit or credit card, gift card, etc.

[0076] Upon selecting the continue option, the user may be provided with interface 700d of FIG. 7D, or a similar interface. Interface 700d includes a field in which the user may indicate the 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 another example, the number of units available for purchase may be determined by the user and inputs into interface 700d.

[0077] The user interface 700d further includes an option for selecting auto-replenish. The indication of "Yes" for auto-replenish prompts the system to store the payment information provided in the interface 700c, and when the system determines that the risk unit balance falls below a predetermined threshold (e.g., step 414 in FIG. 4, step 600 in FIG. 6), the system may automatically purchase a predetermined number of risk units, charge the associated costs against the pre-stored payment information, and deposit the purchased risk units into the risk unit account, thereby effectively auto-renewing the user's insurance.

[0078] FIG. 8 illustrates an example method for determining a recommendation for reducing a risk unit consumption rate, according to one or more aspects described herein. In step 800, data associated with a user's driving behavior and / or environmental conditions may be received. As described above, the data may include speed, braking habits, precipitation level, road conditions, time of day, traffic level, etc. 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 be further based on one or more factors associated with the user. For example, in some examples, accident history, length of time as a licensed driver, rating, policy limits, policy deductibles, vehicle characteristics, etc. may be used in determining the risk unit consumption rate.

[0079] In step 804, one or more driving behavior or environmental condition changes may be identified that may assist in reducing the risk unit consumption rate. For example, if the user is driving on a road known for having poor conditions (e.g., potholes, poor lane markings, etc.), the system may indicate that the user may reduce his or her consumption rate by altering the route to the destination. In some examples, the recommended changes identified to assist in reducing the risk unit consumption rate may include changes to more traditional policy factors, such as policy coverage, deductibles and / or limits, vehicle operation and / or maintenance, vehicle features, etc.

[0080] In some examples, changes to reduce consumption rates may be identified by comparing the received data to a database that stores known conditions, behaviors, roads, environmental factors, etc. associated with reduced consumption rates. The database may store information such as driving history information, accident history information, accident probability information, etc., that may be collected based on insurance data received by an insurance carrier. For example, data associated with the current speed may be compared to a posted speed limit for the current road (stored in the database or received from an external source), and if the current speed is faster than the posted speed limit, changes to slow the vehicle down to reduce consumption rates may be identified.

[0081] In another example, the received data may indicate that a current road is congested or traffic congestion is being encountered. The system may compare the current traffic information with a level of traffic that would result in reduced consumption rates and may recommend a change in the ongoing route. In some examples, the proposed change may include a proposed alternative route.

[0082] Various other changes in driving behavior and / or environmental conditions may be identified based on the received data and / or historical data, stored data, etc. The examples described herein are merely some examples and are not intended to limit the changes or types of changes identified by the system. Rather, various other changes may be identified without departing from this invention.

[0083] In step 806, the identified changes may be displayed to a user. For example, one or more of the recommended changes to reduce consumption rates may be displayed to a user via a computing device, e.g., a mobile device, a vehicle display, etc.

[0084] FIG. 9 illustrates an example user interface 900 that displays recommended changes to reduce consumption rates, according to one or more embodiments described herein. The interface includes an area 902 where the current risk unit consumption is provided to the user. The interface 900 further includes an area 904 where one or more suggested driving changes are provided to the user. Once data from one or more vehicle sensors is received by the system, the risk unit consumption rate may be changed and the revised consumption rate may be displayed. In some examples, the notification may be accompanied by audio. For example, the notification may include an audio portion where the text of the notification is presented to the user, thereby reducing the need for the user to read the notification.

[0085] While the aspects described herein have been described in terms of specific examples, including various ways of carrying out the aspects of the present disclosure, those skilled in the art will recognize that there are numerous variations and permutations of the above-described systems and techniques that fall within the spirit and scope of the present invention.

Claims

1. 1. A vehicle data processing system comprising a server including one or more processors and at least one memory storing a plurality of computer readable instructions, The computer readable instructions, when executed by the one or more processors, cause the server to: providing at least one user with a number of risk units related to an insurance policy for a vehicle of the at least one user and deposited in a risk unit account associated with the at least one user; receiving, by the server, sensor data collected from at least one sensor disposed on the vehicle using one or more wireless network connections with a vehicle-based computing system; analyzing the sensor data to detect driving data; determining a consumption rate of the risk units based at least in part on the driving data; decreasing the number of risk units in the risk unit account based on the consumption rate; determining that the number of risk units in the risk unit account is below a predetermined level; and executing a process for executing a vehicle system action including at least one of flashing the headlights of the vehicle, honking the horn of the vehicle, or preventing the vehicle from starting in response to the number of risk units in the risk unit account being below the predetermined level.

2. 2. The vehicle data processing system of claim 1, wherein the plurality of computer readable instructions, when executed by the one or more processors, further cause the server to perform a process of using the consumption rate during a communication outage until data communication is restored and the consumption rate is determined using more recent data.

3. 3. The vehicle data processing system of claim 2, wherein the consumption rate is based at least in part on a number of lanes on a road along which the vehicle travels.

4. 3. The vehicle data processing system of claim 2, wherein the plurality of computer readable instructions, when executed by the one or more processors, further cause a process to be performed in response to the communication disruption, of providing an indication of the communication disruption to a user interface associated with the at least one user.

5. 5. The vehicle data processing system of claim 4, wherein the user interface is provided on an on-board display of the vehicle-based computing system.

6. 5. The vehicle data processing system of claim 4, wherein the user interface is provided on a mobile device associated with the at least one user.

7. The vehicle data processing system of claim 2 , wherein the communication disruption affects the one or more wireless network connections with the vehicle-based computing system.

8. The vehicle data processing system of claim 1 , wherein the driving data is further determined based on operational data associated with the at least one user.

9. 2. The vehicle data processing system of claim 1, wherein the driving data is further determined based on environmental conditions of the vehicle.

10. 2. The vehicle data processing system of claim 1, wherein the plurality of computer readable instructions, when executed by the one or more processors, further cause the server to perform a process of using historical data to determine the risk unit, which represents the cost of providing insurance to an average user for a given period of time.

11. one or more processors; at least one memory storing a plurality of computer readable instructions, The computer readable instructions, when executed by the one or more processors, cause the server computing device to: providing at least one user with a number of risk units related to an insurance policy for a vehicle of the at least one user and deposited in a risk unit account associated with the at least one user; receiving collected sensor data from at least one sensor disposed on the vehicle using one or more wireless network connections with a computing device of the vehicle; analyzing the sensor data to detect driving data indicative of one or more driving behaviors or environmental characteristics; determining a consumption rate of the risk units based at least in part on the driving data; decreasing the number of risk units in the risk unit account based on the consumption rate; determining that the number of risk units in the risk unit account is below a predetermined level; and executing a vehicle system action including at least one of flashing the headlights of the vehicle, honking the horn of the vehicle, or preventing the vehicle from starting in response to the number of risk units in the risk unit account being below the predetermined level.

12. 12. The server computing device of claim 11, wherein the computer-readable instructions, when executed by the one or more processors, further cause the server computing device to perform a process of receiving Global Positioning System (GPS) data corresponding to the server computing device, and the driving data is based at least in part on the GPS data.

13. 13. The server computing device of claim 12, wherein the server computing device is a mobile device of the at least one user, and the process of determining the driving data includes a process of determining speeding of the at least one user from the GPS data of the mobile device.

14. The computer-readable instructions, when executed by the one or more processors, further cause the server computing device to: continuing to decrease the number of risk units in the risk unit account based on the consumption rate in response to the communication disruption; and in response to communication being restored, further decreasing the number of risk units in the risk unit account based on a second consumption rate.

12. The server computing device of claim 11, wherein the second consumption rate is based on changes in environmental conditions since determining the consumption rate.

15. The computer-readable instructions, when executed by the one or more processors, further cause the server computing device to: continuing to decrease the number of risk units in the risk unit account based on the consumption rate in response to the communication disruption; and in response to communication being restored, further decreasing the number of risk units in the risk unit account based on a second consumption rate. The server computing device of claim 11 , wherein the second consumption rate is based on a change in driving behavior of the at least one user since determining the consumption rate.

16. The computer-readable instructions, when executed by the one or more processors, further cause the server computing device to: continuing to decrease the number of risk units in the risk unit account based on the consumption rate in response to the communication disruption; and in response to communication being restored, further decreasing the number of risk units in the risk unit account based on a second consumption rate.

12. The server computing device of claim 11, wherein the second consumption rate is based on a change in the type of roadway traveled by the vehicle since determining the consumption rate.

17. providing at least one user with a predetermined number of risk units related to an insurance policy for a vehicle of the at least one user and stored in a risk unit account associated with the at least one user; receiving, via one or more wireless network connections with a computing device associated with the at least one user, data indicative of one or more driving behaviors or environmental characteristics; determining a consumption rate of the risk units based at least in part on the data received from the computing device associated with the at least one user; decreasing the number of risk units in the risk unit account based on the consumption rate; determining that the number of risk units in the risk unit account is below a predetermined level; in response to the number of risk units in the risk unit account being below the predetermined level, performing a vehicle system action including at least one of: flashing headlights of the vehicle, honking a horn of the vehicle, or preventing the vehicle from starting; 13. A computer-implemented method for vehicle data processing, comprising:

18. 20. The computer implemented method of claim 17, further comprising receiving additional data indicative of driving behavior or environmental characteristics upon restoration of communication, the consumption rate being based on the additional data.

19. 20. The computer implemented method of vehicle data processing of claim 18, wherein the restoration of communication relates to a disruption in data received from the computing device over the one or more wireless network connections.

20. 20. The computer implemented method of processing vehicle data as described in claim 17, wherein continuing to reduce the number of risk units in the risk unit account based on the consumption rate is based on the data being the most recent data from the computing device.

Images