U.S. patent application number 14/203210 was filed with the patent office on 2014-09-11 for determining driving patterns from on-board vehicle sensor data.
This patent application is currently assigned to STATE FARM MUTUAL AUTOMOBILE INSURANCE COMPANY. The applicant listed for this patent is STATE FARM MUTUAL AUTOMOBILE INSURANCE COMPANY. Invention is credited to Todd Binion, Scott Thomas Christensen, Steven Cielocha, Christopher E. Gay, Gregory Hayward.
Application Number | 20140257870 14/203210 |
Document ID | / |
Family ID | 51229155 |
Filed Date | 2014-09-11 |
United States Patent
Application |
20140257870 |
Kind Code |
A1 |
Cielocha; Steven ; et
al. |
September 11, 2014 |
Determining Driving Patterns from On-Board Vehicle Sensor Data
Abstract
A computer implemented method for providing insurance receives
vehicle data that indicates one or more driving maneuvers of a
vehicle, wherein the vehicle data originates from one or more
sensors. The method also analyzes the received vehicle data to
determine a driving pattern associated with one or more operators
of the vehicle, wherein the driving pattern includes a plurality of
driving maneuvers and the vehicle corresponds to an insurance
policy data structure having a rating data component. The method
further determines that the driving pattern indicates a change in
the rating and adjusts the rating data component. The method
further processes one or more insurance options based at least in
part on the changed rating.
Inventors: |
Cielocha; Steven;
(Bloomington, IL) ; Binion; Todd; (Bloomington,
IL) ; Christensen; Scott Thomas; (Bloomington,
IL) ; Hayward; Gregory; (Bloomington, IL) ;
Gay; Christopher E.; (Dallas, TX) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
STATE FARM MUTUAL AUTOMOBILE INSURANCE COMPANY |
Bloomington |
IL |
US |
|
|
Assignee: |
STATE FARM MUTUAL AUTOMOBILE
INSURANCE COMPANY
Bloomington
IL
|
Family ID: |
51229155 |
Appl. No.: |
14/203210 |
Filed: |
March 10, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61775652 |
Mar 10, 2013 |
|
|
|
Current U.S.
Class: |
705/4 |
Current CPC
Class: |
G06Q 30/0207 20130101;
B60R 25/20 20130101; B60Q 1/00 20130101; B60C 1/00 20130101; G07C
5/008 20130101; G07C 5/00 20130101; G06Q 40/00 20130101; H04W 4/40
20180201; G06Q 30/0208 20130101; G06Q 40/08 20130101 |
Class at
Publication: |
705/4 |
International
Class: |
G06Q 40/08 20120101
G06Q040/08 |
Claims
1. A computer implemented method for providing insurance, the
method comprising: receiving, via a computer network, vehicle data
that indicates one or more driving maneuvers of a vehicle, wherein
the vehicle data originates from one or more sensors; analyzing, by
one or more processors, the received vehicle data to determine a
driving pattern associated with one or more operators of the
vehicle, wherein the driving pattern includes a plurality of
driving maneuvers and the vehicle corresponds to an insurance
policy data structure having a rating data component; determining,
by the one or more processors, that the driving pattern indicates a
change in the rating; adjusting, by the one or more processors, the
rating data component; and processing, by the one or more
processors, one or more insurance options based at least in part on
the changed rating.
2. The computer implemented method of claim 1, further comprising:
receiving, via the computer network, a plurality of vehicle
characteristic data, wherein the plurality of vehicle
characteristic data is indicative of vehicle condition and/or
vehicle usage; and processing, at the one or more processors, the
one or more insurance options based at least in part on the
received vehicle characteristic data.
3. The computer implemented method of claim 1 further comprising:
receiving, via the computer network, a plurality of customer data
from a third party database, wherein the customer data is
associated with one or more operators of the vehicle; and
determining, by the one or more processors, that the plurality of
customer data from the third party database indicates a change in
the rating.
4. The computer implemented method of claim 1 further comprising:
determining, by the one or more processors, an interval period for
receiving the vehicle data; determining, by the one or more
processors, that vehicle data has not been collected within the
interval period; and establishing, via the computer network, a
connection with the vehicle in response to the determination that
vehicle data has not been collected within the interval period.
5. The computer implemented method of claim 1 further comprising:
adjusting, by the one or more processors, a price quote associated
with the insurance policy data structure based at least in part on
the changed rating.
6. The computer implemented method of claim 1, wherein the
plurality of vehicle data is received without any intervention from
a current operator of the vehicle.
7. The computer implemented method of claim 1, wherein the driving
maneuver includes one or more of a vehicle movement, a rapid
acceleration, a sudden turn, or a sudden stop.
8. The computer implemented method of claim 1 further comprising:
determining, by the one or more processors, an operator driving
pattern associated with a known operator of the vehicle; and
analyzing, by the one or more processors, the received vehicle data
to determine whether the driving pattern corresponds to the known
operator or an unknown operator.
9. The computer implemented method of claim 1, wherein the one or
more sensors record the vehicle data at a sample rate of at least
once per second.
10. A computer device for providing insurance, the device
comprising: one or more processors; and one or more memories
coupled to the one or more processors; wherein the one or more
memories include computer executable instructions stored therein,
that, when executed by the one or more processors, cause the one or
more processors to: receive, via a computer network, vehicle data
that indicates one or more driving maneuvers of a vehicle, wherein
the plurality of vehicle data originates from one or more sensors;
analyze the plurality of vehicle data to determine a driving
pattern associated with one or more operators of the vehicle
wherein the driving pattern includes a plurality of driving
maneuvers and the vehicle corresponds to an insurance policy data
structure having a rating data component; determine that the
driving pattern indicates a change in the rating; adjust the rating
data component; and process one or more insurance options based at
least in part on the changed rating.
11. The computer device of claim 10 wherein the computer executable
instructions further cause the one or more processors to: receive,
via the computer network, a plurality of vehicle characteristic
data, wherein the plurality of vehicle characteristic data is
indicative of vehicle condition and/or vehicle usage; and process
the one or more insurance options based at least in part on the
received vehicle characteristic data.
12. The computer device of claim 10 wherein the computer executable
instructions further cause the one or more processors to: receive,
via the computer network, a plurality of customer data from a third
party database, wherein the customer data is associated with the
one or more operators of the vehicle; and determine that the
customer data plurality of customer data from the third party
database indicates a change in the rating.
13. The computer device of claim 10 wherein the computer executable
instructions further cause the one or more processors to: determine
an interval period for receiving the vehicle data; determine that
vehicle data has not been collected within the interval period; and
establishing, via the computer network, a connection with a vehicle
in response to the determination that vehicle data has not been
collected within the interval period.
14. The computer device of claim 10 wherein the computer executable
instructions further cause the one or more processors to adjust a
price quote associated with the insurance policy data structure
based at least in part on the changed rating.
15. The computer device of claim 10 wherein the computer executable
instructions further cause the one or more processors to receive
the plurality of vehicle data without any intervention from a
current operator of the vehicle.
16. The computer implemented method of claim 10 wherein the
computer executable instructions further cause the one or more
processors to determine that the driving maneuver includes one or
more of a vehicle movement, a rapid acceleration, a sudden turn, or
a sudden stop.
17. The computer implemented method of claim 10 wherein the
received vehicle data is recorded at a sample rate of at least once
per second.
18. The computer device of claim 10 wherein the computer executable
instructions further cause the one or more processors to: determine
an operator driving pattern associated with a known operator of the
vehicle; and analyze the received vehicle data to determine whether
the driving pattern corresponds to the known operator or an unknown
operator.
19. A non-transitory computer readable storage medium comprising
non-transitory computer readable instructions stored thereon, that,
when executed by one or more processors, cause the one or more
processors to: receive, via a computer network, vehicle data that
indicates one or more driving maneuvers of a vehicle, wherein the
vehicle data originates from one or more sensors; analyze the
received vehicle data to determine a driving pattern associated
with one or more operators of the vehicle, wherein the driving
pattern includes a plurality of driving maneuvers and the vehicle
corresponds to an insurance policy data structure having a rating
data component; determine that the driving pattern indicates of a
change in the rating; adjust the rating of the rating data
component; and process one or more insurance options based at least
in part on the changed rating.
20. The non-transitory computer readable storage medium of claim
19, wherein the computer readable instructions when executed on the
one or more processors further cause the one or more processors to:
receive, via the computer network, a plurality of vehicle
characteristic data, wherein the plurality of vehicle
characteristic data is indicative of vehicle condition and/or
vehicle usage; and process the one or more insurance options based
at least in part on the received vehicle characteristic data.
21. The non-transitory computer readable storage medium of claim
19, wherein the computer readable instructions when executed on the
one or more processors further cause the one or more processors to:
receive, via the computer network, a plurality of customer data
from a third party database, wherein the customer data is
associated with the one or more operators of the vehicle; and
determine that the plurality of customer data from the third party
database indicates of a change in the rating.
22. The non-transitory computer readable storage medium of claim
19, wherein the computer readable instructions when executed on the
one or more processors further cause the one or more processors to:
determine an interval period for receiving the vehicle data;
determine that vehicle data has not been collected within the
interval period; and establishing, via the computer network, a
connection with the vehicle in response to the determination that
vehicle data has not been collected within the interval period.
23. The non-transitory computer readable storage medium of claim
19, wherein the computer readable instructions when executed on the
one or more processors further cause the one or more processors to:
adjust a price quote associated with the insurance policy data
structure based at least in part on the changed rating.
24. The non-transitory computer readable storage medium of claim
19, wherein the computer readable instructions when executed on the
one or more processors further cause the one or more processors to
receive the plurality of vehicle data without any intervention from
the current operator of the vehicle.
25. The non-transitory computer readable storage medium of claim
19, wherein the computer readable instructions when executed on the
one or more processors further cause the one or more processors to
determine that the driving maneuver includes one or more of a
vehicle movement, a rapid acceleration, a sudden turn, or a sudden
stop.
26. The non-transitory computer readable storage medium of claim 19
wherein the received vehicle data is recorded at a sample rate of
at least once per second.
27. The non-transitory computer readable storage medium of claim
19, wherein the computer readable instructions when executed on the
one or more processors further cause the one or more processors to:
determine an operator driving pattern associated with a known
operator of the vehicle; and analyze the received vehicle data to
determine whether the driving pattern corresponds to the known
operator or an unknown operator.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. Provisional
Application No. 61/775,652, filed Mar. 10, 2013, which is
incorporated by reference herein.
FIELD OF THE DISCLOSURE
[0002] This disclosure generally relates to insurance premiums and,
more particularly, to establishing and using common driving routes
for assessing, pricing and provisioning of vehicle insurance.
BACKGROUND
[0003] The background description provided herein is for the
purpose of generally presenting the context of the disclosure. Work
of the presently named inventors, to the extent it is described in
this background section, as well as aspects of the description that
may not otherwise qualify as prior art at the time of filing, are
neither expressly nor impliedly admitted as prior art against the
present disclosure.
[0004] Insurance companies desire to collect vehicle and driver
behavior data for use in enhancing policy holder risk assessment.
Many companies employ vehicle monitoring system for a variety of
purposes, including determining of insurance risk and/or premiums.
These systems may monitor many vehicle attributes, such as
location, speed, acceleration/deceleration, etc. The monitoring
devices are integrated with the vehicle or plugged into the vehicle
systems. Many of these monitoring systems require expert
installation into the vehicle and further require the user to
periodically withdraw the monitoring device to download the trip
data.
SUMMARY
[0005] This Summary is provided to introduce a selection of
concepts in a simplified form that are further described below in
the Detailed Description. This Summary is not intended to identify
key features or essential features of the claimed subject matter,
nor is it intended to be used to limit the scope of the claimed
subject matter.
[0006] In one embodiment, a computer implemented method for
providing insurance comprises receiving, via a computer network,
vehicle data that indicates one or more driving maneuvers of a
vehicle, wherein the vehicle data originates from one or more
sensors. The method also comprises analyzing, by one or more
processors, the received vehicle data to determine a driving
pattern associated with one or more operators of the vehicle,
wherein the driving pattern includes a plurality of driving
maneuvers and the vehicle corresponds to an insurance policy data
structure having a rating data component. The method further
comprises determining, by the one or more processors, that the
driving pattern indicates a change in the rating and adjusting, by
the one or more processors, the rating data component. The method
also comprises processing, by the one or more processors, one or
more insurance options based at least in part on the changed
rating.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] FIG. 1 is a block diagram of an example computing system in
which the techniques for determining driving patterns from on-board
vehicle sensor data can be implemented;
[0008] FIG. 2A is a flow diagram of an example method for
calculating an insurance quote based on a determined driving
pattern;
[0009] FIG. 2B is a flow diagram of an example method for
determining whether vehicle data has been collected within a
determined interval period;
[0010] FIG. 3 is a flow diagram of an example method for
determining a driving pattern from received vehicle data;
[0011] FIG. 4A is a flow diagram of an example method for
performing a purchase transaction for an insurance product;
[0012] FIG. 4B is a diagram illustrating an example viewport of a
client device displaying a plurality of insurance coverage
products; and
[0013] FIG. 5 is an exemplary architecture of a data system of a
system and method for orienting telematics data.
[0014] The figures depict a preferred embodiment of the present
invention for purposes of illustration only. One skilled in the art
will readily recognize from the following discussion that
alternative embodiments of the structures and methods illustrated
herein may be employed without departing from the principles of the
invention described herein.
DETAILED DESCRIPTION
[0015] The present disclosure is directed towards a method for
monitoring vehicle operational characteristics and driver behavior
to obtain data relevant for assessing, pricing, and provisioning of
vehicle insurance. In this manner, the method of the present
disclosure provides a more accurate determination of price quotes
for vehicle insurance.
[0016] A system of sensors such as vehicle mileage sensors, time of
day sensors, vehicle location sensors (e.g., driver pad on garage
floor), speed sensors, passenger seat occupancy sensors or
operational sensors for maneuvers such as vehicle movements, rapid
acceleration, sudden turns, and sudden stops is used to monitor,
record and transmit data that may be used in assessing, pricing and
provisioning vehicle insurance. In some embodiments, a diagnostics
device may be selected for use with current industry standard on
board diagnostics systems such as the On Board Diagnostics-II
(OBD-II) system. The diagnostics device may be inserted and/or
installed in a customer's vehicle OBD-II system to obtain speed,
odometer data, and other relevant vehicle data. In some
embodiments, the vehicle may also access external databases to
aggregate and transmit additional vehicle and/or customer data such
as customer demographic data, vehicle condition data, usage data,
and other characteristic data as needed to assess, price, and
provision vehicle insurance.
[0017] Because vehicle usage data and additional vehicle and/or
customer data is transmitted directly from the vehicle to the
insurance agency, in some embodiments, direct input from the
customer may not be required. Based on the data received from the
vehicle, an insurance company may automatically make updates and
adjustments to the vehicle policy whether in real-time during the
term of the policy, or at a renewal time for the policy, or other
times. In some embodiments, the coverage types and quotes may be
displayed to the customer by onboard display screen in the vehicle,
or via remote connection from the vehicle to a client device. In
further embodiments, the customer may opt for automatic renewals,
or to receive automatic renewal alerts. For example, a renewal
alert may be presented through the client device or even through
the vehicle using an on board computer and LCD, a "dummy light,"
etc. At the time of purchase of a vehicle, a company may also offer
financial incentives to a customer to encourage registration with
such self-insurance services, based on the interest in the insured
product.
[0018] These techniques are discussed in more detail below with
reference to FIGS. 1-4. In general, the techniques discussed below
can be implemented on a server device, or partially implemented on
a client device, and partially implemented on a server device.
[0019] FIG. 1 illustrates various aspects of an exemplary
architecture implementing a system 100 for determining driving
patterns from on-board vehicle sensor data. The high-level
architecture includes both hardware and software applications, as
well as various data communications channels for communicating data
between the various hardware and software components. The system
100 for adjusting insurance policies based on common driving routes
and other risk factors may include various software and hardware
components or modules.
[0020] The system 100 for adjusting insurance policies based on
common driving routes and other risk factors may include front end
components, including a vehicle 102 and a client device 104. The
vehicle may include an on board diagnostics connector 106, an
odometer 108 and a GPS 110 module for communicating with one or
more GPS satellites 111. The vehicle 102 may also include a local
network transceiver 112 and/or a cellular network transceiver 114
for communicating with backend components 116 via the computer
network 118.
[0021] The computer network 118 may be a network such as the
Internet or other type of suitable network (e.g., local area
network (LAN), a metropolitan area network (MAN), a wide area
network (WAN), a mobile, a wired or wireless network, a private
network, a virtual private network, etc.). The computer network 118
may also be one or more cellular networks such as code division
multiple access (CDMA) network, GSM (Global System for Mobile
Communications) network, WiMAX (Worldwide Interoperability for
Microwave Access) network, Long Term Evolution (LTE) network,
etc.
[0022] In some embodiments, the client device 104 may be placed in
the vehicle 102. The client device 104 may be a personal computer,
a smart phone, a tablet computer, a smart watch, a head mounted
display, a wearable computer or other suitable client device. In
some embodiments, the client device 104 may also include a GPS
module 120 for communicating with the one or more GPS satellites
111. The client device 104 may also include a local network
transceiver 122 and/or a cellular network transceiver 124 for
communicating with the backend components 116 via the computer
network 118. In an embodiment, the client device 102 may also
execute one or more applications to allow a customer to manage a
customer account, purchase one or more insurance products, view
driving statistics, change settings, etc. In some embodiments, both
the vehicle 102 and the client device 104 may include additional
sensors. The sensors may collect data at a variety of sample rates,
such as, for example, at a sample rate of at least once per
second.
[0023] The back end components 116 may include a data server 126
and a database 128. The back end components may communicate with
each other through a communication network 130 such as a local area
network or other type of suitable network (e.g., the Internet, a
metropolitan area network (MAN), a wide area network (WAN), a
mobile, a wired or wireless network, a private network, a virtual
private network, etc.). In some embodiments, the back end
components 116, the vehicle 102 and/or the client device 104 may
also communicate with one or more internet sources 119 via the
computer network 118. For example, the internet source may be a
third party database.
[0024] In some embodiments, the system 100 for determining driving
patterns from on-board vehicle sensor data in general and the data
server 126 in particular may include computer-executable
instructions 132. A processor of the data server 126 may execute
the instructions 132 to instantiate one or more modules for
retrieving and analyzing data from one or more databases 128, as
discussed in further detail below. The database 128 may be a data
storage device such as random-access memory (RAM), hard disk drive
(HDD), flash memory, flash memory such as a solid state drive
(SSD), etc. The database may store one or more insurance policy
data structures 128 associated with a customer account. The
insurance policy data structure may include assorted information
corresponding to the customer account such as a rating component
129. In some embodiments, a customer account may be associated with
one than one driver.
[0025] Turning now to FIG. 2A, a flow chart depicts an exemplary
method 200 for calculating an insurance quote based on a determined
driving pattern. At block 202, a processor of a data server (such
as the data server 126 illustrated in FIG. 1) may execute an
instruction to access a customer account for an insurance company.
In some embodiments, the processor may execute an instruction to
create an insurance company account if there is no current user
account. The account may be used, for example, to purchase
insurance products, adjust coverage for insurance products, etc. At
block 204, the processor may execute an instruction to establish a
remote connection with a client device (such as the vehicle 102
illustrated in FIG. 1) and at block 206, the processor may execute
an instruction to receive vehicle data from the client device. For
example, vehicle data may include odometer data, GPS data, data
from a diagnostics device, such as an On-Board Diagnostics device,
or from one or more additional sensors placed in the vehicle.
[0026] At block 208, the processor may execute an instruction to
determine one or more driving behaviors from the received vehicle
data. For example, the processor may execute an instruction
implementing one or more blocks of the method 400, discussed in
reference to FIG. 4 below. At block 210, the processor may execute
an instruction to calculate one or more insurance quotes based on
the determined driving behavior. In some embodiments, a customer
may have already purchased one or more insurance products from the
insurance company and the processor may execute an instruction to
adjust one or more the insurance quotes based on the determined
driving behavior. At block 212, the processor may execute an
instruction to transmit one or more insurance quotes to a
customer.
[0027] Turning now to FIG. 2B, a flow chart depicts an exemplary
method 250 for determining whether vehicle data has been collected
within a determined interval period. At block 252, a processor of a
data server (such as the data server 126 illustrated in FIG. 1) may
execute an instruction to determine an interval period for
transmitting data. For example, the interval period may be hours,
days, months, years, etc. In some embodiments, a customer may set a
preference for an interval period. At block 254, the processor may
execute an instruction to determine whether or not vehicle data has
been collected within the interval period. If the processor
executing the instruction determines that vehicle data has been
collected within the interval period (YES branch of block 254),
then, at block 256, the processor may execute an instruction to end
the method 250.
[0028] If the processor executing the instruction determines that
vehicle data has not been collected within the interval period, (NO
branch of block 254) then at block 258 the processor may execute an
instruction to establish a connection with the vehicle. At block
260, the processor receive vehicle data from the vehicle and at
block 262, the processor may execute an instruction to process an
insurance option. For example, the processor may execute an
instruction to calculate a price quote or price quote adjustment
based on the vehicle data.
[0029] Referring now to FIG. 3, a flow chart depicts an exemplary
method 300 for determining a driving pattern from received vehicle
data. At block 302, a processor of a data server (such as the data
server 126 illustrated in FIG. 1) may receive sensor data that
originates from one or more sensors that record the vehicle data
for the vehicle associated with an insurance account. In some
embodiments, the vehicle data is indicative of a driving maneuver
for a vehicle and the driving maneuver includes one or more of
rapid acceleration, a sudden turn, a vehicle movement, and a sudden
stop. As discussed above, the processor may receive vehicle data at
regular intervals from a variety of different sensors such as
vehicle mileage sensors, time of day sensors, vehicle location
sensors (e.g., driver pad on garage floor), speed sensors,
passenger seat occupancy sensors or operational sensors. At block
304, the processor may execute an instruction to determine one or
more diving maneuvers from the vehicle data. The vehicle data may
include a variety of sensor readings, including accelerometer
values over a certain sample period. The received vehicle data may
be indicative of one or more driving maneuvers such as rapid
acceleration, sudden turns, and sudden stops. Of course these are
only example driving maneuvers and those of ordinary skill in the
art will recognize that the received vehicle data may be indicative
of a wide variety of driving maneuvers. In some embodiments, the
processor may further execute an instruction to classify the
driving maneuvers (i.e. unsafe, safe, etc.) or rank the driving
maneuvers via one or more ranking schemes.
[0030] At block 306, the processor may further execute an
instruction to determine if one of the driving maneuvers is
indicative of a driving pattern of the vehicle. The driving pattern
may include a plurality of driving maneuvers. In some embodiments,
the vehicle corresponds to an insurance policy data structure
having a rating, such as the data structure 128A and the rating
component 129 illustrated in FIG. 1. If the processor executing the
instruction determines that the driving maneuvers are not
indicative of a driving pattern (NO branch of block 306), at block
308, the processor may execute an instruction to end the method
300.
[0031] If the processor executing the instruction determines that
the driving maneuvers are indicative of a driving pattern, at block
310, the processor may execute an instruction to record the
pattern. For example, if the vehicle data indicates a certain
number of unsafe driving maneuvers, the processor executing the
instruction may determine that the driving maneuvers are indicative
of an unsafe driving pattern. At block 312, the processor may
execute an instruction to determine if the determined driving
pattern is indicative of a change in rating for the insurance
premium.
[0032] For example, if the received vehicle data indicates rapid
acceleration a certain number of times over a certain period of
time, this may indicate a change in rating that reflects this
unsafe driving behavior. This change may affect one or more
insurance options associated with the insurance policy. The
processor may execute an instruction to analyze the accelerometer
values and determine if there are any spikes in speed. For example,
if the received vehicle data indicates consistent rapid
acceleration, this may indicate a change in rating that reflects
this unsafe driving behavior. This change in rating may also affect
one or more insurance options associated with the driver's
insurance policy.
[0033] In one embodiment, the processor may analyze one or more
driving patterns to identify an operator of a vehicle. The
processor may execute an instruction to determine an operator
driving pattern associated with a first operator of the vehicle and
to analyze the received vehicle data to determine whether the
driving pattern corresponds to the operator driving pattern or
corresponds to an unknown driver. For example, a customer may have
previously indicated that there is only one driver of a vehicle
that is insured, but there are actually two people driving the
vehicle. Accordingly, the processor use this analysis to determine
that the driving pattern at certain times is different than the
driving pattern at other times and further analyze this information
to determine that there are indeed two drivers. The processor may
further execute an instruction to process one or more insurance
options based on this analysis. In some embodiments, two or more
drivers may already be associated with the vehicle. Accordingly,
the analysis can determine driving patterns, such as unique driving
patterns, for each driver and then determine the safety of each
driver as well as the amount of time each driver spends driving the
vehicle. The processor may further execute an instruction to
process one or more insurance options based on this analysis.
[0034] The processor may execute an instruction to determine if the
number of spikes in speed meet a threshold amount that would result
in a change in rating. If the processor determines that the
threshold amount is met, then the processor may execute an
instruction to adjust the rating component of the insurance policy
data structure. The processor may further execute an instruction to
process one or more insurance options based at least in part on the
changed rating. For example, the processor may execute an
instruction to remove certain discounts, add certain discounts,
increase or decrease an insurance premium, etc.
[0035] In some embodiments, the processor executing the instruction
may determine that the driving maneuvers and/or patterns are
indicative of unsafe behavior, but the unsafe behavior is already
reflected in the rating and thus the insurance premium does not
need to be adjusted. If the processor executing the instruction
determines that the determined driving pattern is not indicative of
a change in rating for the insurance premium (NO branch of block
312), at block 314, the processor may execute an instruction to end
the method 300.
[0036] If the processor executing the instruction determines that
the determined driving pattern is indicative of a change in rating
for the insurance premium (YES branch of block 312), at block 316,
the processor may execute an instruction to adjust an insurance
option. For example, the processor may execute an instruction to
adjust the rating component of the insurance policy data structure.
In some embodiments, the method 300 may be used to determine an
initial insurance premium for the customer.
[0037] In an embodiment, the processor may execute an instruction
to notify the customer about the driving pattern, change in rating,
etc., before adjusting the rating component of the insurance policy
data structure and/or adjusting/determining an insurance premium.
By notifying the customer, the customer may have an opportunity to
adjust their behavior to avoid an increased premium. The customer
may be notified by, for example, a notification in an application,
an e-mail, phone call, etc.
[0038] In some embodiments, the processor may also execute an
instruction to associate the driving maneuver, driving pattern,
rating and/or insurance premium with the customer account. In some
embodiments, this may also involve saving certain data to one or
more databases. As described above, if the customer does not have a
customer account, the processor may execute an instruction to
create one. For example, if the vehicle data indicates that number
of unsafe driving maneuvers, the processor executing the
instruction may determine that the driving maneuvers are indicative
of an unsafe driving pattern.
[0039] Referring now to FIG. 4A, a flow chart depicts an exemplary
method 400 for performing a purchase transaction for an insurance
product. The method 400 may be used to present a price quote for an
insurance product to a customer and perform a purchase transaction
for the insurance product.
[0040] At block 402 a processor of a data server, (such as the data
server 126 described in reference to FIG. 1), may execute an
instruction to transmit a plurality of insurance coverage products
to a client device. After transmitting the plurality of insurance
coverage products to the client device, a processor of the client
device may display the plurality of insurance coverage products
within a viewport of the client device. For example, turning
briefly to the example viewport 450 of a client device displaying a
plurality of insurance coverage products illustrated in FIG. 4B the
insurance products may include different coverage types associated
with vehicle insurance, such as liability coverage, medical
payments coverage, collision coverage, comprehensive coverage and
emergency road service. In some embodiments, the coverage types and
quote may be displayed to the customer by onboard display screen in
the vehicle to be insured, or via remote connection from the
vehicle to the client device. Of course, these are only example
insurance products and those skilled in the art will recognize that
other types of insurance products may be transmitted to the client
device during operation of the method 400.
[0041] A user may make an input selection of an insurance coverage
product and a processor of the client device may receive the input
selection and transmit the input selection to the data server. At
block 404, the processor may receive an input selection of an
insurance product from the client device in response to the
transmission. At block 406, the processor may execute an
instruction to determine one or more insurance premiums
corresponding to the received input selection based at least in
part on the driving maneuver. For example, the processor may
execute an instruction incorporating one or more steps from the
method 300 in determining the one or more insurance premiums. The
processor may also execute an instruction to transmit the one or
more insurance premiums to the client device. At block 408, the
processor may further execute an instruction to perform a purchase
transaction for the insurance product.
[0042] Referring now to FIG. 5, a data system 500 includes a
controller 502. Exemplary data systems include the vehicle 102, the
client device 104 and the data server 118 as illustrated in FIG. 1.
The controller 502 includes a program memory 504, a microcontroller
or a microprocessor (.mu.P) 506, a random-access memory (RAM) 508,
and an input/output (I/O) circuit 510, all of which are
interconnected via an address/data bus 512. The program memory 504
may store computer-executable instructions, which may be executed
by the microprocessor 506. In some embodiments, the controller 502
may also include, or otherwise be communicatively connected to, a
database 514 or other data storage mechanism (e.g., one or more
hard disk drives, optical storage drives, solid state storage
devices, etc.). It should be appreciated that although FIG. 5
depicts only one microprocessor 506, the controller 502 may include
multiple microprocessors 506. Similarly, the memory 504 of the
controller 502 may include multiple RAMs 516 and multiple program
memories 518, 518A and 518B storing one or more corresponding
server application modules, according to the controller's
particular configuration.
[0043] Although FIG. 5 depicts the I/O circuit 510 as a single
block, the I/O circuit 510 may include a number of different types
of I/O circuits (not depicted), including but not limited to,
additional load balancing equipment, firewalls, etc. The RAM(s)
516, 508 and the program memories 518, 518A and 518B may be
implemented in a known form of computer storage media, including
but not limited to, semiconductor memories, magnetically readable
memories, and/or optically readable memories, for example, but does
not include transitory media such as carrier waves.
[0044] The following additional considerations apply to the
foregoing discussion. Throughout this specification, plural
instances may implement components, operations, or structures
described as a single instance. Although individual operations of
one or more methods are illustrated and described as separate
operations, one or more of the individual operations may be
performed concurrently, and nothing requires that the operations be
performed in the order illustrated. Structures and functionality
presented as separate components in example configurations may be
implemented as a combined structure or component. Similarly,
structures and functionality presented as a single component may be
implemented as separate components. These and other variations,
modifications, additions, and improvements fall within the scope of
the subject matter of the present disclosure.
[0045] Additionally, certain embodiments are described herein as
including logic or a number of components, modules, or mechanisms.
Modules may constitute either software modules (e.g., code stored
on a machine-readable medium) or hardware modules. A hardware
module is tangible unit capable of performing certain operations
and may be configured or arranged in a certain manner. In example
embodiments, one or more computer systems (e.g., a standalone,
client or server computer system) or one or more hardware modules
of a computer system (e.g., a processor or a group of processors)
may be configured by software (e.g., an application or application
portion) as a hardware module that operates to perform certain
operations as described herein.
[0046] A hardware module may comprise dedicated circuitry or logic
that is permanently configured (e.g., as a special-purpose
processor, such as a field programmable gate array (FPGA) or an
application-specific integrated circuit (ASIC)) to perform certain
operations. A hardware module may also comprise programmable logic
or circuitry (e.g., as encompassed within a general-purpose
processor or other programmable processor) that is temporarily
configured by software to perform certain operations. It will be
appreciated that the decision to implement a hardware module in
dedicated and permanently configured circuitry or in temporarily
configured circuitry (e.g., configured by software) may be driven
by cost and time considerations.
[0047] Accordingly, the term hardware should be understood to
encompass a tangible entity, be that an entity that is physically
constructed, permanently configured (e.g., hardwired), or
temporarily configured (e.g., programmed) to operate in a certain
manner or to perform certain operations described herein.
Considering embodiments in which hardware modules are temporarily
configured (e.g., programmed), each of the hardware modules need
not be configured or instantiated at any one instance in time. For
example, where the hardware modules comprise a general-purpose
processor configured using software, the general-purpose processor
may be configured as respective different hardware modules at
different times. Software may accordingly configure a processor,
for example, to constitute a particular hardware module at one
instance of time and to constitute a different hardware module at a
different instance of time.
[0048] Hardware and software modules can provide information to,
and receive information from, other hardware and/or software
modules. Accordingly, the described hardware modules may be
regarded as being communicatively coupled. Where multiple of such
hardware or software modules exist contemporaneously,
communications may be achieved through signal transmission (e.g.,
over appropriate circuits and buses) that connect the hardware or
software modules. In embodiments in which multiple hardware modules
or software are configured or instantiated at different times,
communications between such hardware or software modules may be
achieved, for example, through the storage and retrieval of
information in memory structures to which the multiple hardware or
software modules have access. For example, one hardware or software
module may perform an operation and store the output of that
operation in a memory device to which it is communicatively
coupled. A further hardware or software module may then, at a later
time, access the memory device to retrieve and process the stored
output. Hardware and software modules may also initiate
communications with input or output devices, and can operate on a
resource (e.g., a collection of information).
[0049] The various operations of example methods described herein
may be performed, at least partially, by one or more processors
that are temporarily configured (e.g., by software) or permanently
configured to perform the relevant operations. Whether temporarily
or permanently configured, such processors may constitute
processor-implemented modules that operate to perform one or more
operations or functions. The modules referred to herein may, in
some example embodiments, comprise processor-implemented
modules.
[0050] Similarly, the methods or routines described herein may be
at least partially processor-implemented. For example, at least
some of the operations of a method may be performed by one or
processors or processor-implemented hardware modules. The
performance of certain of the operations may be distributed among
the one or more processors, not only residing within a single
machine, but deployed across a number of machines. In some example
embodiments, the processor or processors may be located in a single
location (e.g., within a home environment, an office environment or
as a server farm), while in other embodiments the processors may be
distributed across a number of locations.
[0051] The one or more processors may also operate to support
performance of the relevant operations in a "cloud computing"
environment or as an SaaS. For example, as indicated above, at
least some of the operations may be performed by a group of
computers (as examples of machines including processors), these
operations being accessible via a network (e.g., the Internet) and
via one or more appropriate interfaces (e.g., APIs).
[0052] The performance of certain of the operations may be
distributed among the one or more processors, not only residing
within a single machine, but deployed across a number of machines.
In some example embodiments, the one or more processors or
processor-implemented modules may be located in a single geographic
location (e.g., within a home environment, an office environment,
or a server farm). In other example embodiments, the one or more
processors or processor-implemented modules may be distributed
across a number of geographic locations.
[0053] Some portions of this specification are presented in terms
of algorithms or symbolic representations of operations on data
stored as bits or binary digital signals within a machine memory
(e.g., a computer memory). These algorithms or symbolic
representations are examples of techniques used by those of
ordinary skill in the data processing arts to convey the substance
of their work to others skilled in the art. As used herein, an
"algorithm" or a "routine" is a self-consistent sequence of
operations or similar processing leading to a desired result. In
this context, algorithms, routines and operations involve physical
manipulation of physical quantities. Typically, but not
necessarily, such quantities may take the form of electrical,
magnetic, or optical signals capable of being stored, accessed,
transferred, combined, compared, or otherwise manipulated by a
machine. It is convenient at times, principally for reasons of
common usage, to refer to such signals using words such as "data,"
"content," "bits," "values," "elements," "symbols," "characters,"
"terms," "numbers," "numerals," or the like. These words, however,
are merely convenient labels and are to be associated with
appropriate physical quantities.
[0054] Unless specifically stated otherwise, discussions herein
using words such as "processing," "computing," "calculating,"
"determining," "presenting," "displaying," or the like may refer to
actions or processes of a machine (e.g., a computer) that
manipulates or transforms data represented as physical (e.g.,
electronic, magnetic, or optical) quantities within one or more
memories (e.g., volatile memory, non-volatile memory, or a
combination thereof), registers, or other machine components that
receive, store, transmit, or display information.
[0055] As used herein any reference to "one embodiment" or "an
embodiment" means that a particular element, feature, structure, or
characteristic described in connection with the embodiment is
included in at least one embodiment. The appearances of the phrase
"in one embodiment" in various places in the specification are not
necessarily all referring to the same embodiment.
[0056] Some embodiments may be described using the expression
"coupled" and "connected" along with their derivatives. For
example, some embodiments may be described using the term "coupled"
to indicate that two or more elements are in direct physical or
electrical contact. The term "coupled," however, may also mean that
two or more elements are not in direct contact with each other, but
yet still co-operate or interact with each other. The embodiments
are not limited in this context.
[0057] As used herein, the terms "comprises," "comprising,"
"includes," "including," "has," "having" or any other variation
thereof, are intended to cover a non-exclusive inclusion. For
example, a process, method, article, or apparatus that comprises a
list of elements is not necessarily limited to only those elements
but may include other elements not expressly listed or inherent to
such process, method, article, or apparatus. Further, unless
expressly stated to the contrary, "or" refers to an inclusive or
and not to an exclusive or. For example, a condition A or B is
satisfied by any one of the following: A is true (or present) and B
is false (or not present), A is false (or not present) and B is
true (or present), and both A and B are true (or present).
[0058] In addition, use of the "a" or "an" are employed to describe
elements and components of the embodiments herein. This is done
merely for convenience and to give a general sense of the
description. This description should be read to include one or at
least one and the singular also includes the plural unless it is
obvious that it is meant otherwise.
[0059] Upon reading this disclosure, those of skill in the art will
appreciate still additional alternative structural and functional
designs for determining driving patterns from on-board vehicle
sensor data through the disclosed principles herein. Thus, while
particular embodiments and applications have been illustrated and
described, it is to be understood that the disclosed embodiments
are not limited to the precise construction and components
disclosed herein. Various modifications, changes and variations,
which will be apparent to those skilled in the art, may be made in
the arrangement, operation and details of the method and apparatus
disclosed herein without departing from the spirit and scope
defined in the appended claims.
* * * * *