Note: Descriptions are shown in the official language in which they were submitted.
1
SYSTEMS AND METHODS FOR CONTROLLING THE COLLECTION OF
VEHICLE USE DATA USING A MOBILE DEVICE
TECHNICAL FIELD
The present disclosure relates generally to systems and methods for collecting
and
evaluating driving behavior data and/or driving environment data,
automatically controlling the
starting and stopping of such data collection, and using such collected data
to calculate insurance
premiums. Aspects of the data collection, evaluation, and/or premium
calculation may be
provided by a mobile device, e.g., a smart phone.
Date Recue/Date Received 2020-04-27
CA 02805995 2013-02-18
2
BACKGROUND
Improvements in roadway and automobile designs have steadily reduced injury
and death
rates in developed countries. Nevertheless, auto collisions are still the
leading cause of injury-
related deaths, an estimated total of 1.2 million worldwide in 2004, or 25% of
the total from all
causes. Further, driving safety is particularly important for higher-risk
drivers such as teens and
elderly drivers, as well as higher-risk passengers such as infant and elderly
passengers. For
example, motor vehicle crashes are the number one cause of death for American
teens.
Thus, driving safety remains a critical issue in today's society. Various
efforts and
programs have been initiated to improve driving safety over the years. For
example, driving
instruction courses (often referred to as "drivers ed") are intended to teach
new drivers not only
how to drive, but how to drive safely. Typically, an instructor rides as a
passenger and provides
instruction to the learning driver, and evaluates the driver's performance. As
another example,
"defensive driving" courses aim to reduce the driving risks by anticipating
dangerous situations,
despite adverse conditions or the mistakes of others. This can be achieved
through adherence to
a variety of general rules, as well as the practice of specific driving
techniques. Defensive
driving course provide a variety of benefits. For example, in many states, a
defensive driving
course can be taken as a way to dismiss traffic tickets, or to qualify the
driver for a discount on
car insurance premiums.
From the perspective of an automobile insurance provider, the provider seeks
to assess
the risk level associated with a driver and price an insurance policy to
protect against that risk.
The process of determining the proper cost of an insurance policy, based on
the assessed risk
level, is often referred to as "rating." The rating process may include a
number of input
variables, including experience data for the specific driver, experience data
for a class of drivers,
capital investment predictions, profit margin targets, and a wide variety of
other data useful for
predicting the occurrence of accidents as well as the amount of damage likely
to result from such
accidents.
In the industry today, driving behavior data for insurance rating purposes is
collected by
specialized devices that plug into vehicle data ports. For example, US
6,832,141, issued to
CA 02805995 2013-02-18
3
Skeen et al., discloses an onboard diagnostic memory module that is configured
to plug into the
OBD II port. The memory module is preprogrammed with data collection
parameters through
microprocessor firmware by connection to a PC having programming software for
the module
firmware. Data is recorded on a trip basis. Intelligent interrogation occurs
by interpretive
software from an interrogating PC to retrieve a trip-based and organized data
set including hard
and extreme acceleration and deceleration, velocity (in discrete bands),
distance traveled, as well
as the required SAE-mandated operating parameters.
CA 02805995 2013-02-18
4
SUMMARY
In accordance with the teachings of the present disclosure, a mobile device,
such as a
smartphone, is used to collect and transmit vehicle operation data, rather
than a specialized
device that plugs into a vehicle data port.
According to one aspect of the invention, a mobile device may include at least
one sensor
that detects a characteristic of the mobile device selected from distance
traveled, location, time,
and g-force dynamics; a processor; and a tangible non-transitory computer
readable storage
medium containing instructions that, when executed on by the processor, are
programmed to
automatically detect that a wireless connection has been established between
the mobile device
and a vehicle, and in response to detecting the wireless connection between
the mobile device
and the vehicle, automatically start collecting vehicle operation data via the
at least one sensor.
The mobile device may automatically stop collecting the vehicle operation data
in response to
the vehicle being turned off.
According to another aspect, a method for automatically recording vehicle
operation data
may include automatically detecting that a wireless connection has been
established between a
mobile device and a vehicle associated with the mobile device, and in response
to detecting the
wireless connection between the mobile device and the vehicle, automatically
starting to collect
vehicle operation data via at least one sensor provided by the mobile device.
According to another aspect, computer instructions embodied in a tangible non-
transitory
computer readable storage medium may be executable by a processor to:
automatically detect
that a wireless connection has been established between a mobile device and a
vehicle associated
with the mobile device, and in response to detecting the wireless connection
between the mobile
device and the vehicle, automatically start to collect vehicle operation data
via at least one sensor
provided by the mobile device, without interaction between the mobile device
and a user.
CA 02805995 2013-02-18
BRIEF DESCRIPTION OF THE DRAWINGS
A more complete understanding of the present embodiments and advantages
thereof may
be acquired by referring to the following description taken in conjunction
with the accompanying
drawings, in which like reference numbers indicate like features, and wherein:
5 FIGURE 1 illustrates an example mobile device located in a vehicle,
the mobile device
including a driving analysis system, according to certain embodiments of the
present disclosure;
FIGURE 2 illustrates example components of the mobile device relevant to the
driving
analysis system, according to certain embodiments;
FIGURE 3 illustrates an example method of collecting and processing driving
data,
according to certain embodiments;
FIGURE 4 illustrates an example method of collecting and processing driving
data using
example algorithms, according to certain embodiments;
FIGURE 5 illustrates an example system for sharing driving data between a
mobile
device including a driving analysis system and other external devices,
according to certain
embodiments;
FIGURES 6A-6G illustrate example screen shots generated by an example driving
analysis application on a mobile device, according to certain embodiments;
FIGURE 7 is a flow chart of an illustrative algorithm for determining severity
levels of
notable driving events (NDE) identified during data collection sessions;
FIGURE 8 is a flow chart of an illustrative algorithm for determining severity
levels of
notable driving events (NDE) identified during data collection sessions;
FIGURE 9 is schematic illustration of an infrastructure for collecting vehicle
operation
data, transmitting vehicle operation data, receiving vehicle operation data
and = calculating
insurance premiums based on vehicle operation data, wherein the infrastructure
comprises a
remote data storage system and a property and casualty system;
FIGURE 10 is a flowchart of a driving analysis application that may be
downloaded onto
a mobile device;
FIGURE 11A is a screen shot of a graphic user interface of a Create Account
screen of a
driving analysis application;
CA 02805995 2013-02-18
6
FIGURE 11B is a screen shot of a graphic user interface of an Account Creation
Complete screen of a driving analysis application;
FIGURE 11C is a screen shot of a graphic user interface of a Settings screen
of a driving
analysis application;
FIGURE 11D is a screen shot of a graphic user interface of a Bluetooth Setup
screen of a
driving analysis application;
FIGURE 11E is a screen shot of a graphic user interface of a Vehicle screen of
a driving
analysis application;
FIGURE 11F is a screen shot of a graphic user interface of a Main Menu
(Landing Page)
screen of a driving analysis application;
FIGURE 11G is a screen shot of a graphic user interface of a Daily Report
screen of a
driving analysis application;
FIGURE 11H is a screen shot of a graphic user interface of a Speed Interval
screen of a
driving analysis application;
FIGURE 111 is a screen shot of a graphic user interface of a Time Interval
screen of a
driving analysis application;
FIGURE 11J is a screen shot of a graphic user interface of a Trip Details
screen of a
driving analysis application;
FIGURE 11K is a screen shot of a graphic user interface of a Trip Map screen
of a
driving analysis application;
FIGURE 11L is a screen shot of a graphic user interface of a Odometer Update
screen of
a driving analysis application;
FIGURE 12 is a flowchart of a process for collection and analysis of vehicle
operation
data; and
FIGURE 13 is a flowchart of another process for collection and analysis of
vehicle
operation data.
CA 02805995 2013-02-18
7
DETAILED DESCRIPTION
Preferred embodiments and their advantages over the prior art are best
understood by
reference to FIGURES 1-13 below. The present disclosure may be more easily
understood in
the context of a high level description of certain embodiments.
According to certain embodiments of the invention, a smartphone based
telematics
technology solution may be implemented that requires no additional hardware or
sensing
equipment in an insured's vehicle. A mobile device equipped with software may
capture and
transmit the miles driven and vehicle dynamics (g-force events such as hard
stops, sharp turns,
fast accelerations, etc.) in an automated fashion. Thus, individual driver's
may collect and
transmit driving behavior and use information to their insurance company via
their mobile
device.
Insurance companies may receive, store and use the collected driving behavior
and use
information to calculate and charge insurance premiums. Software programs
operating on
insurance company servers may provide a telematics data infrastructure to
receive, process,
present and transform telematics data for insurance rating purposes.
Insurance customers may be incentivized to provide driving behavior and use
information
to their insurance company via their mobile device by subsidization of
consumers' smartphones
and/or smartphone data plan fees through business relationships between
insurance providers and
wireless data carriers.
A software application ("APP") may be provided for operating systems such as
those
employed by iPhone, iPad and Android systems. Once the APP is downloaded to
the
smartphone and launched for initial set up, no additional start/stop
activities by the user may be
required. The APP may collect data using sensors in the smartphone to
determine miles driven,
location, time, and vehicle dynamics (g-force events such as hard stops, sharp
turns, fast
accelerations, etc.).
Computing infrastructure may be provided for receiving telematics data from
customer
smartphones in real time. The infrastructure may be a cloud computing
infrastructure.
In one embodiment of the invention, the APP may utilize sensors in a
smartphone to
automatically start and stop the application once initially setup on the
smartphone. Automated
CA 02805995 2013-02-18
8
tracking may use algorithms to use the smartphone/server architecture to
determine driving,
mileage, etc. The APP may turn itself "on" as soon as the smartphone detects
that it is in an
automobile with its engine running, e.g., as discussed below regarding the
methods of FIGURES
12 and 13. The smartphone may communicate with the vehicle via Bluetooth to
determine that
the smartphone is inside the vehicle and that the engine is running. Once
detected, the APP may
then turn itself on and begin tracking miles driven, location, time, and
vehicle dynamics (g-force
data). The APP may be configured so that interaction with a driver is limited,
such that the APP
will run automatically on the smartphone after initial setup, wherein
automatic start and stop
capabilities may be accomplished using smartphone sensors.
FIGURE 1 illustrates an example mobile device 10 located in a vehicle 12,
according to
certain embodiments or implementations of the present disclosure. Mobile
device 10 may
comprise any type of portable or mobile electronics device, such as for
example a smartphone, a
cell phone, a mobile telephone, personal digital assistant (PDA), laptop
computer, tablet-style
computer, or any other portable electronics device. For example, in some
embodiments, mobile
device 10 may be a smart phone, such as an iPhone by Apple Inc., a Blackberry
phone by RIM, a
Palm phone, or a phone using an Android, Microsoft, or Symbian operating
system (OS), for
example. In some embodiments, mobile device 10 may be a tablet, such as an
iPad by Apple,
Inc., a Galaxy by Samsung, or Eee Pad Transformer by ASUS, and Latitude ST
Tablet PC by
Dell, for example.
In some embodiments, mobile device 10 may be configured to provide one or more
features of a driving analysis system, such as (a) collection of driving data
(e.g., data regarding
driving behavior and/or the respective driving environment), (b) processing of
collected driving
data, and/or (c) providing collected driving data and/or processed driving
data to a server or
database via telecommunication or telematics. Accordingly, mobile device 10
may include one
or more sensors, a driving analysis application, a display, and transmitters.
The sensor(s) may collect one or more types of data regarding driving behavior
and/or the
driving environment. For example, mobile device 10 may include a built-in
accelerometer
configured to detect acceleration in one or more directions (e.g., in the x,
y, and z directions). As
another example, mobile device 10 may include a GPS (global positioning
system) device or any
CA 02805995 2013-02-18
9
other device for tracking the geographic location of the mobile device. As
another example,
mobile device 10 may include sensors, systems, or applications for collecting
data regarding the
driving environment, e.g., traffic congestion, weather conditions, roadway
conditions, or driving
infrastructure data. In addition or alternatively, mobile device 10 may
collect certain driving
data (e.g., driving behavior data and/or driving environment data) from
sensors and/or devices
external to mobile device 10 (e.g., speed sensors, blind spot information
sensors, seat belt
sensors, GPS device, etc.).
The driving analysis application ("APP") on mobile device 10 may process any
or all of
this driving data collected by mobile device 10 and/or data received at mobile
device 10 from
external sources to calculate one or more driving behavior metrics and/or
scores based on such
collected driving data. For example, driving analysis application may
calculate acceleration,
braking, and cornering metrics based on driving behavior data collected by the
built-in
accelerometer (and/or other collected data). Driving analysis application may
further calculate
scores based on such calculated metrics, e.g., an overall driving score. As
another example,
driving analysis application may identify "notable driving events," such as
instances of notable
acceleration, braking, and/or cornering, as well as the severity of such
events. In some
embodiments, the driving analysis application may account for environmental
factors, based on
collected driving environment data corresponding to the analyzed driving
session(s). For
example, the identification of notable driving events may depend in part on
environmental
conditions such as the weather, traffic conditions, road conditions, etc.
Thus, for instance, a
particular level of braking may be identified as a notable driving event in
the rain, but not in dry
conditions.
The driving analysis application may display the processed data, e.g., driving
behavior
metrics and/or driving scores. In embodiments in which mobile device 10
includes a GPS or
other geographic location tracking device, the application may also display a
map showing the
route of a trip, and indicating the location of each notable driving event.
The application may
also display tips to help drivers improve their driving behavior.
The driving analysis application may display some or all of such data on the
mobile
device 10 itself. In addition or alternatively, the driving analysis
application may communicate
CA 02805995 2013-02-18
some or all of such data via a network or other communication link for display
by one or more
other computer devices (e.g., smart phones, personal computers, etc.). Thus,
for example, a
parent or driving instructor may monitor the driving behavior of a teen or
student driver without
having to access the mobile device 10. As another example, an insurance
company may access
5
driving behavior data collected/processed by mobile device 10 and use such
data for risk analysis
of a driver and determining appropriate insurance products or premiums for the
driver according
to such risk analysis (i.e., performing rating functions based on the driving
behavior data
collected/processed by mobile device 10).
FIGURE 2 illustrates example components of mobile device 10 relevant to the
driving
10
analysis system discussed herein, according to certain embodiments. As shown,
mobile device
10 may include a memory 30, processor 32, one or more sensors 34, a display
36, and
input/output devices 38.
Memory 30 may store a driving analysis application 50 and historical driving
data 46, as
discussed below. In some embodiments, memory 30 may also store one or more
environmental
data applications 58, as discussed below. Memory 30 may comprise any one or
more devices
suitable for storing electronic data, e.g., RAM, DRAM, ROM, internal flash
memory, external
flash memory cards (e.g., Multi Media Card (MMC), Reduced-Size MMC (RS-MMC),
Secure
Digital (SD), MiniSD, MicroSD, Compact Flash, Ultra Compact Flash, Sony Memory
Stick,
etc.), SIM memory, and/or any other type of volatile or non-volatile memory or
storage device.
Driving analysis application 50 may be embodied in any combination of
software, firmware,
and/or any other type of computer-readable instructions.
Application 50 and/or any related, required, or useful applications, plug-ins,
readers,
viewers, updates, patches, or other code for executing application 50 may be
downloaded via the
Internet or installed on mobile device 10 in any other known manner.
Processor 32 may include a microprocessor, a microcontroller, a digital signal
processor
(DSP), an application specific integrated controller (ASIC), electrically-
programmable read-only
memory (EPROM), or a field-programmable gate array (FPGA), or any other
suitable
processor(s), and may be generally operable to execute driving analysis
application 50, as well as
providing any other functions of mobile device 10.
CA 02805995 2013-02-18
11
Sensors 34 may include any one or more devices for detecting information
regarding a
driver's driving behavior and/or the driving environment. For example, as
discussed above,
sensors 34 may include an accelerometer 54 configured to detect acceleration
of the mobile
device 10 (and thus, the acceleration of a vehicle in which mobile device 10
is located) in one or
more directions, e.g., the x, y, and z directions. As another example, mobile
device 10 may
include a location tracking system 56, such as a GPS tracking system or any
other system or
device for tracking the geographic location of the mobile device. A solid
state compass, with
two or three magnetic field sensors, may provide data to a microprocessor to
calculate direction
using trigonometry. The mobile device 10 may also include proximity sensors, a
camera or
ambient light.
Display 36 may comprise any type of display device for displaying information
related to
driving analysis application 50, such as for example, an LCD screen (e.g.,
thin film transistor
(TFT) LCD or super twisted nematic (STN) LCD), an organic light-emitting diode
(OLED)
display, or any other suitable type of display. In some embodiments, display
36 may be an
interactive display (e.g., a touch screen) that allows a user to interact with
driving analysis
application 50. In other embodiments, display 36 may be strictly a display
device, such that all
user input is received via other input/output devices 38.
Input/output devices 38 may include any suitable interfaces allowing a user to
interact
with mobile device 10, and in particular, with driving analysis application
50. For example,
input/output devices 38 may include a touch screen, physical buttons, sliders,
switches, data
ports, keyboard, mouse, voice activated interfaces, or any other suitable
devices.
As discussed above, driving analysis application 50 may be stored in memory
30.
Driving analysis application 50 may be described in terms of functional
modules, each embodied
in a set of logic instructions (e.g., software code). For example, as shown in
FIGURE 2, driving
analysis application 50 may include a data collection module 40, a data
processing module 42,
and a feedback module 44.
Data collection module 40 may be operable to manage the collection of driving
data,
including driving behavior data and/or the driving environment data. Data
collection module 40
may collect such data from any number and types of data sources, including (a)
data sources
CA 02805995 2013-02-18
12
provided by mobile device 10 (e.g., sensors 34, environmental data application
58), (b) data
sources in vehicle 12 but external to mobile device 10 (e.g., on-board vehicle
computer, seat belt
sensors, GPS system, etc.), and/or (c) data sources external to vehicle 12
(e.g., data sources
accessible to mobile device 100 by a satellite network or other
telecommunication links). In
certain embodiments, the mobile device 10 may communicate with data source in
vehicle 12 but
external to mobile device 10 via a hardwire connection, Bluetooth or other
wireless means,
optical signal transmission, or any other known manner. Sources in vehicle 12
but extended to
mobile device 10 may include: engine RPM, speedometer, fuel usage rate,
exhaust components
or other combination indications, suspension system monitors, seat belt use
indicators, tracking
systems for other vehicles in vicinity, blind spot indicators.
In some embodiments, data collection module 40 may control the start and stop
of
driving data collection, e.g., from sources such as accelerometer 54, location
tracking system 56,
other sensor(s) 34 provided by mobile device 10, or other sensors or sources
of driving data
external to mobile device 10. In some embodiments or situations, driving data
collection is
manually started and stopped by the driver or other user, e.g., by interacting
with a physical or
virtual object (e.g., pressing a virtual "start recording" button) on mobile
device 10.
In other embodiments or situations, data collection module 40 may
automatically start
and/or stop collection of driving data in response to triggering signals
received by mobile device
10 from one or more triggering devices 15 associated with vehicle 12 (see
FIGURE 1). For
example, triggering device 15 may include a vehicle on-board computer,
ignition system, car
stereo, GPS system, a key, key fob, or any other device that may be configured
to communicate
signals to mobile device 10. Triggering signals may include any signals that
may indicate the
start or stop of a driving trip. For example, triggering signals may include
signals indicating the
key has been inserted into or removed from the ignition, signals indicating
the ignition has been
powered on/off (e.g., as discussed below regarding the example method of
FIGURE 13), signals
indicating whether the engine is running, signals indicating the radio has
been powered on/off,
etc. or signals indicating the transmission has been set in a forward gear
position. Such
triggering device(s) may communicate with mobile device 10 in any suitable
manner, via any
suitable wired or wireless communications link. As another example, data
collection module 40
CA 02805995 2013-02-18
13
may automatically start and/or stop collection of driving data in response to
determining that the
mobile device 10 is likely travelling in an automobile, e.g., based on a real
time analysis of data
received from accelerometer 54, location tracking system 56, or other sensors
34 provided by
mobile device 10. For example, data collection module 40 may include
algorithms for
determining whether mobile device 10 is likely travelling in an automobile
based on data from
accelerometer 54 and/or location tracking system 56, e.g., by analyzing one or
more of (a) the
current acceleration of mobile device 10 from accelerometer 54, (b) the
current location of
mobile device 10 from location tracking system 56 (e.g., whether mobile device
10 is located
on/near a roadway), (c) the velocity of mobile device 10 from location
tracking system 56, (d)
any other suitable data, or (e) any combination of the preceding.
In some embodiments or situations, data collection module 40 may allow or
trigger the
start and stop (including interrupting and re-starting) of driving data
collection based on the
orientation of mobile device 10 (relative to vehicle 12), e.g., based on
whether the orientation is
suitable for collecting driving data. For example, data collection module 40
may allow driving
data collection to be manually or automatically started (or re-started after
an interruption).
Further, during driving data collection, module 40 may automatically stop or
interrupt the
driving data collection if mobile device 10 is moved such that it is no longer
suitably able to
collect driving data.
In some embodiments, data collection module 40 may manage the physical
orientation of
mobile device 10 relative to the vehicle 12. Module 40 may determine the
orientation of mobile
device 10 within the vehicle 12 by comparing GPS and position information for
the mobile
device 10 with GPS and position information for the vehicle 12. This
comparison of data may
allow the user to adjust the mobile device 10 such that the orientation of
mobile device 10 is
suitable for collecting driving data. For example, data collection module 40
may determine the
orientation of mobile device 10; determine whether the orientation is suitable
for collecting
driving data; if so, allow data collection to begin or continue; and if not,
instruct or notify the
user to adjust the orientation of mobile device 10 (e.g., by indicating the
direction and/or extent
of the desired adjustment). Once mobile device 10 has been adjusted to a
suitable orientation for
collecting driving data, module 40 may notify the user and allow data
collection to begin or
CA 02805995 2013-02-18
14
continue. Module 40 may continue to monitor the orientation of mobile device
10 relative to the
vehicle during the driving data collection session, and if a change in the
orientation is detected,
interact with the user to instruct a correction of the orientation.
In other embodiments, mobile device 10 is capable of automatically
compensating for the
orientation of mobile device 10 for the purposes of processing collected
driving data (e.g., by
data processing module 42), such that data collection may start and continue
despite the
orientation of mobile device 10, or changes to the orientation of the mobile
device 10 relative to
the vehicle 12. Module 40 may continue to monitor the orientation of mobile
device 10 relative
to the vehicle during the driving data collection session, and if a change in
the orientation is
detected, automatically compensate for the changed orientation of mobile
device 10 for
processing driving data collected from that point forward. In such
embodiments, data processing
module 42 may include any suitable algorithms for compensating for the
orientation of mobile
device 10 (relative to automobile 12) determined by data collection module 40.
Such aspects of
the invention allow the mobile device to collect accurate g-force data from
the sensors of the
mobile device regardless of the position of the mobile device in the vehicle.
The quality of this
data is improved by adjusting the data based on the orientation of the mobile
device in the
vehicle such as upside down, sideways, in a pocket or in a purse.
As used herein, the term "user" refers to the driver or other person
interacting with
driving analysis application 50 on mobile device 10.
Data collection module 40 may collect data over one or more data collection
sessions
corresponding to one or more driving sessions. As used herein, a "driving
session" may refer to
any period of driving, which may comprise a single uninterrupted trip, a
portion of a trip, or a
series of multiple distinct trips. A "data collection session" may generally
correspond to one
driving session, a portion of a driving session, or multiple distinct driving
sessions. Further, a
data collection session may comprise an uninterrupted period of data
collection or may include
one or more interruptions (e.g., in some embodiments, if mobile device 10 is
moved out of
proper orientation for data collection). Thus, in some embodiments, each
interruption of data
collection initiates a new data collection session; in other embodiments,
e.g., where a data
CA 02805995 2013-02-18
collection session generally corresponds to a driving trip, an interrupted
data collection session
may reconvene after the interruption.
Thus, based on the above, data collection module 40 may trigger or control the
start and
stop of data collection sessions and/or start and the stop of interruptions
within a data collection
5 session.
Any or all data collected by data collection module 40 may be time stamped
(e.g., time
and date), either by data collection module 40 itself or by another device
that collected or
processed particular data before sending the data to data collection module
40. The time
stamping may allow for data from different sources (e.g., data from
accelerometer 54, location
10 tracking system 56, a seat belt sensor, etc.) to be synchronized for
analyzing the different data
together as a whole (e.g., to provide the driving context for a particular
reading of accelerometer
54, as discussed below).
Data collection module 40 may collect data corresponding to physical
parameters or
characteristics of the vehicle.
15 Data processing module 42 may be operable to process or analyze any of
the driving data
(e.g., driving behavior data and/or the driving environment data) collected by
mobile device 10
itself and/or collected by external devices and communicated to mobile device
10, and based on
such collected driving data, calculate one or more driving behavior metrics
and/or scores. For
example, data processing module 42 may calculate the driving behavior metrics
of acceleration,
braking, and/or cornering metrics based on driving behavior data collected by
an accelerometer
54, location tracking system 56, and/or other collected data. Further, data
processing module 42
may calculate one or more driving scores based on the calculated driving
behavior metrics (e.g.,
acceleration, braking, cornering, etc.) and/or based on additional collected
data, e.g., driving
environment data collected by environmental data applications 58. For example,
data processing
module 42 may apply algorithms that calculate a driving score based on
weighted values for each
respective driving behavior metric, and environmental correction values based
on the relevant
driving environment data, such as weather, traffic conditions, road
conditions, etc.
Data processing module 42 may calculate individual driving behavior metrics
(e.g.,
acceleration, braking, cornering, etc.) and/or driving scores for individual
data collection
CA 02805995 2013-02-18
16
sessions. Similarly, data processing module 42 may calculate driving behavior
metrics and/or
driving scores corresponding to a group of data collection sessions, which may
be referred to as
group-session metrics/scores. Data processing module 42 may calculate group-
session
metrics/scores may using averaging, filtering, weighting, and/or any other
suitable algorithms for
determining representative metrics/scores corresponding to a group of data
collection sessions.
A "group" of data collection sessions may be specified in any suitable manner,
for example:
= The n most recent data collection sessions;
= The n most recent data collection sessions corresponding to one or more
specific
driving conditions or other preset conditions, such as for example: nighttime
driving,
daytime driving, driving within specific times of day (e.g., specific hours),
weekend
driving, weekday driving, highway driving, city driving, rush-hour driving,
good-
weather driving, bad-weather driving, driving in specific weather conditions
(e.g.,
rain, snow, etc.), trips of specified distances (e.g., trips shorter than a
threshold
distance, longer than a threshold distance, or within any present range of
distances,
trips associated with a certain geographic area (e.g., trips within or near a
specific
city), trips between specific points (e.g., trips between the driver's home
and work,
which may be determined for example by GPS data or entered into application 50
by
the driver), trips following a specific route (e.g., which may be determined
for
example by GPS data or entered into application 50 by the driver), driving
alone (e.g.,
which status may be entered into application 50 by the driver), driving with
passengers (e.g., which status may be entered into application 50 by the
driver),
= All data collection sessions within a specified time period, e.g., all
data collection
sessions in the last day, week, 30 days, 90 days, year, or any other specified
time
period.
= All data collection sessions within a specified time period that also
correspond to one
or more specific driving conditions or other preset conditions, e.g., any of
the
conditions listed above.
CA 02805995 2013-02-18
17
= All data collection sessions after a particular starting point, e.g., all
data collection
sessions after a user initiates application 50, or after a user resets a
particular average
or filtered metric/score (or all average or filtered metrics/scores).
= All data collection sessions within a specified time period that also
correspond to one
or more specific driving conditions or other preset conditions, e.g., any of
the
conditions listed above.
= All data collection sessions related to a particular driver.
= Any combination or variation of any of the above.
The number n may be any multiple number (2, 3, 4, 5, etc.), which may be
automatically
determined by application 50, selected by a user, or otherwise determined or
selected. Further,
as mentioned briefly above, data processing module 42 may identify "notable
driving events,"
such as instances of notable acceleration, braking, and cornering, as well as
the severity of such
events. Data processing module 42 may identify notable driving events using
any suitable
algorithms. For example, an algorithm may compare acceleration data from
accelerometer 54
(raw or filtered) to one or more predefined thresholds for notable
acceleration, braking, or
cornering. In some embodiments, data processing module 42 may analyze the
acceleration data
in combination with contextual data, which may provide a context for the
acceleration data, and
analyze the acceleration data based on the context data. Thus, for example,
particular
acceleration data may or may not indicate "notable acceleration" depending on
the contextual
data corresponding (e.g., based on time stamp data) to the particular
acceleration data being
analyzed. Data processing module 42 may utilize algorithms that analyze the
acceleration data
together with the relevant contextual data.
Contextual data may include, for example, location data and/or driving
environment data.
Module 42 may use location data (e.g., from location tracking system 56) in
this context to
determine, for example, the type of road the vehicle is travelling on, the
speed limit, the location
of the vehicle relative to intersections, traffic signs/light (e.g., stop
signs, yield signs, traffic
lights), school zones, railroad tracts, traffic density, or any other features
or aspects accessible
from location tracking system 56 that may influence driving behavior. Module
42 may use
CA 02805995 2013-02-18
18
driving environment data (e.g., from environmental data applications 58) in
this context to
determine, for example, the relevant weather, traffic conditions, road
conditions, etc.
in some embodiments, data processing module 42 may apply different thresholds
for
determining certain notable driving events. For example, for determining
instances of "notable
cornering" based on acceleration data from accelerometer 54 and weather
condition data (e.g.,
from sensors on the vehicle, sensors on mobile device 10, data from an online
weather
application (e.g., vvww.weather.com), or any other suitable source), module 42
may apply
different thresholds for identifying notable cornering in dry weather
conditions, rainy weather
conditions, and icy weather conditions. As another example, for determining
instances of
"notable braking" based on acceleration data from accelerometer 54 and
location data (e.g., from
a GPS system), module 42 may apply different thresholds for identifying
notable braking for
highway driving, non-highway driving, low-traffic driving, high-traffic
driving, approaching a
stop sign intersection, approaching a stop light intersection, etc.
Further, in some embodiments, data processing module 42 may define multiple
levels of
severity for each type (or certain types) of notable driving events. For
example, module 42 may
define the following levels of notable braking: (1) significant braking, and
(2) extreme braking.
As another example, module 42 may define the following three progressively
severe levels of
particular notable driving events: (1) caution, (2) warning, and (3) extreme.
Each level of
severity may have corresponding thresholds, such that the algorithms applied
by module 42 may
determine (a) whether a notable event (e.g., notable braking event) has
occurred, and (b) if so,
the severity level of the event. Each type of notable driving event may have
any number of
severity levels (e.g., 1, 2, 3, or more).
in some embodiments, data processing module 42 may calculate the number of
each type
of notable driving events (and/or the number of each severity level of each
type of notable
driving event) for a particular time period, for individual data collection
sessions, or for a group
of data collection sessions (e.g., using any of the data collection session
"groups" discussed
above).
Environmental data applications 58 may comprise any applications or interfaces
for
collecting driving environment data regarding the driving environment
corresponding to a
CA 02805995 2013-02-18
19
driving data collection session. For example, environmental data applications
58 may comprise
any applications or interfaces operable to collect data from one or more
sensors on vehicle 12 or
from one or more devices external to vehicle 12 (via a network or
communication links)
regarding the relevant driving environment. For example, such driving
environment data may
include any of (a) traffic environment characteristics, e.g., congestion,
calmness, or excitability
of traffic, quantity and type of pedestrian traffic, etc., (b) weather
environment characteristics,
e.g., ambient temperature, precipitation, sun glare, darkness, etc., (c)
roadway environment
characteristics, e.g., curvature, skid resistance, elevation, gradient and
material components, etc.,
(d) infrastructure environment characteristics, e.g., lighting, signage, type
of road, quantity and
type of intersections, lane merges, lane markings, quantity and timing of
traffic lights, etc.,
and/or (e) any other type of driving environment data.
According to some embodiments of the invention, data collection module 40
collects
information and data sufficient to enable the data processing module 42 to
analyze how driving
has impacted fuel efficiency. The feedback module 44 may report notable
driving events that
had positive or negative impact on the fuel efficiency of the vehicle 12. For
example, if the
vehicle 12 has a normal transmission and the driver allows the engine to reach
excessive RPMs
before shifting to a higher gear, each occurrence may be reported as a notable
driving event that
impacts fuel efficiency. The feedback may assist the driver to develop driving
habits that enable
more fuel efficient vehicle operation.
Feedback module 44 may be operable to display any data associated with
application 50,
including raw or filtered data collected by data collection module 40 and/or
any of the metrics,
scores, or other data calculated or proceed by data processing module 42. For
the purposes of
this description, unless otherwise specified, "displaying" data may include
(a) displaying data on
display device 36 of mobile device 10, (b) providing audible feedback via a
speaker of mobile
device 10, providing visual, audible, or other sensory feedback to the driver
via another device in
the vehicle (e.g., through the vehicle's radio or speakers, displayed via the
dashboard, displayed
on the windshield (e.g., using semi-transparent images), or using any other
known techniques for
providing sensory feedback to a driver of a vehicle, (d) communicating data
(via a network or
other wired or wireless communication link or links) for display by one or
more other computer
CA 02805995 2013-02-18
devices (e.g., smart phones, personal computers, etc.), or (e) any combination
of the preceding.
To provide feedback to the driver visual, audible, or other sensory feedback
to the driver via a
feedback device in the vehicle other than mobile device 10, mobile device 10
may include any
suitable communication system for wired or wireless communication of feedback
signals from
5 mobile device 10 to such feedback device.
Further, feedback module 44 may also initiate and/or manage the storage of any
data
associated with application 50, including raw or filtered data collected by
data collection module
40 and/or any of the metrics, scores, or other data calculated or proceed by
data processing
module 42, such that the data may be subsequently accessed, e.g., for display
or further
10 processing. For example, feedback module 44 may manage short-term
storage of certain data
(e.g., in volatile memory of mobile device 10), and may further manage long-
term storage of
certain data as historical driving data 46 (e.g., in non-volatile memory of
mobile device 10). As
another example, feedback module 44 may communicate data associated with
application 50 via
a network or other communication link(s) to one or more other computer
devices, e.g., for
15 display by remote computers 150 and/or for storage in a remote data
storage system 152, as
discussed in greater detail below with reference to FIGURE 5.
Feedback module 44 may be operable to display metrics, scores, or other data
in any
suitable manner, e.g., as values, sliders, icons (e.g., representing different
magnitudes of a
particular metric/score value using different icons or using different colors
or sizes of the same
20 icon), graphs, charts, etc. Further, in embodiments in which mobile
device 10 includes a GPS or
other location tracking system 56, feedback module 44 may display one or more
maps showing
the route travelled during one or more data collection sessions or driving
sessions, and indicating
the location of "notable driving events." Notable driving events may be
identified on the map in
any suitable manner, e.g., using representative icons. As an example only,
different types of
notable driving events (e.g., notable acceleration, notable braking, and
notable cornering) may be
represented on the map with different icons, and the severity level of each
notable driving event
may be indicated by the color and/or size of each respective icon.
Feedback module 44 may also display tips to help drivers improve their driving
behavior.
For example, feedback module 44 may analyze the driver's driving behavior
metrics and/or
CA 02805995 2013-02-18
21
driving scores to identify one or more areas of needed improvement (e.g.,
braking or cornering)
and display driving tips specific to the areas of needed improvement.
In some embodiments, feedback module 44 may provide the driver real time
feedback
regarding notable driving events, via any suitable form of feedback, e.g., as
listed above. For
example, feedback module 44 may provide audible feedback (e.g., buzzers or
other sound
effects, or by human recorded or computer-automated spoken feedback) through a
speaker of
mobile device 10 or the vehicle's speakers, or visual feedback via display 36
of mobile device 10
or other display device of the vehicle. Such real-time audible or visual
feedback may distinguish
between different types of notable driving events and/or between the severity
level of each
notable driving event, in any suitable manner. For example, spoken feedback
may indicate the
type and severity of a notable driving event in real time. Non-spoken audible
feedback may
indicate the different types and severity of notable driving events by
different sounds and/or
different volume levels.
Feedback module 44 may manage user interactions with application 50 via
input/output
devices 38 (e.g., a touch screen display 36, keys, buttons, and/or other user
interfaces). For
example, feedback module 44 may host a set or hierarchy of displayable objects
(e.g., screens,
windows, menus, images etc.) and facilitate user navigation among the various
objects. An
example set of displayable objects, in the form of screens, is shown and
discussed with reference
to FIGURES 6A-6G.
In some embodiments, feedback module 44 may generate a series of user-
navigable
screens, windows, or other objects for display on display device 36 on mobile
device 10.
FIGURES 6A-6G illustrate example screen shots generated by driving analysis
application 50 on
an example mobile device 10, according to certain embodiments.
FIGURE 6A illustrates an example screenshot of a screen 200 of a device
orientation
feature provided by application 50 for assisting a user with the proper
alignment or orientation of
mobile device 10 within the automobile or vehicle. In this example, an
alignment image 202
may indicate the physical orientation (e.g., angular orientation) of mobile
device 10 relative to
the automobile. For example, alignment image 202 may rotate relative to the
rest of the display
as mobile device 10 is reoriented. Alignment image 202 may include arrows or
other indicators
CA 02805995 2013-02-18
22
to assist the use in orienting mobile device 10. An indicator 204 (e.g., a
lighted icon) may
indicate when mobile device 10 is suitably oriented for data collection, e.g.,
with the front of
mobile device 10 facing toward the front of the automobile or vehicle.
In embodiments requiring manual starting of data recording (i.e., starting a
data
collection session), a screen or image for starting data recording may appear
upon the mobile
device 10 being properly oriented. Thus, data collection module 40 may then
start (or re-start)
collection of driving data upon a manual instruction (e.g., a user pressing a
"Start Recording"
button that is displayed on display 36 once mobile device 10 is properly
oriented).
In embodiments that provide for automatic starting of data recording (i.e.,
starting a data
collection session), data collection module 40 may start (or re-start) driving
data collection
automatically upon the proper orientation of mobile device 10, or
automatically in response to an
automatically generated triggering signal (assuming mobile device 10 is
properly oriented).
FIGURE 6B illustrates an example screenshot of a screen 210 during a data
collection
session. The display may indicate that driving data is being recorded (image
212) and may
provide a selectable image 214 for stopping the recording of driving data
(i.e., ending the data
collection session).
FIGURE 6C illustrates an example screenshot of a summary screen 218 for a
single data
collection session, including three driving behavior metrics (Acceleration,
Braking, and
Cornering) and a driving score ("224") calculated by data processing module 42
for the single
data collection session. For the illustrated data collection session, the
driving score 224
calculated to be "82." The metrics and score may be displayed in real time
(e.g., evaluating the
driving behavior during an ongoing trip), after conclusion of a trip (e.g.,
evaluating the
completed trip or a group of trips), or at any other time. As shown, screen
218 includes values
220 and corresponding bar graphs 222 indicating the Acceleration, Braking, and
Cornering
metrics, as well a visual representation 224 of the driving score ("82")
calculated by data
processing module 42. The driving score may be calculated based on the
Acceleration, Braking,
and Cornering metrics using any suitable algorithm. For example, the driving
score may be a
straight or weighted average of the metrics, a sum or weighted sum of the
metrics, or any other
representation. The algorithm for calculating the driving score may also
account for data other
CA 02805995 2013-02-18
23
than the metrics, such as the identity of the driver, the time, duration,
and/or distance of the data
collection session, the weather conditions, traffic conditions, and/or any
other relevant data
accessible to data processing module 42.
FIGURE 6D illustrates an example screenshot of a summary screen 230 for a
group of
multiple data collection sessions, including three multi-session driving
behavior metrics
(Acceleration, Braking, and Cornering) and a multi-session driving score
("78") calculated by
data processing module 42 for the group of data collection sessions. Each
multi-session driving
behavior metric, as well as the driving score, for the group of sessions may
be calculated based
on any number of data collection sessions, and using any suitable algorithm.
For example, each
multi-session metric/score may be an average (e.g., straight or weighted
average) of the
respective metrics/scores determined for the n most recent data collection
sessions. Further, the
multi-session metric/score may be filtered according to preset or user-
selected criteria. For
example, each multi-session metric/score may be an average (e.g., straight or
weighted average)
of the respective metrics/scores determined for the n most recent data
collection sessions that
meet one or more preset or user-selected criteria regarding the respective
data collection session,
e.g., the particular driver, time of day, trip distance, trip duration,
geographic area of travel,
weather conditions, traffic conditions, or any other relevant data accessible
to data processing
module 42. Thus, for instance, module 42 may calculate multi-session driving
behavior metrics
and driving scores for the five most recent trips by Bob, which were further
than 3 miles, within
the geographic limits of a particular city, and during good weather
conditions.
The number of data collection sessions included in a particular multi-session
driving
metric/score may be automatically or manually selected in any suitable manner,
e.g., a
predetermined number of sessions, a number automatically determined by module
42 (e.g., all
sessions occurring within a predetermined time period), a number manually
selected by a user, or
determined in any other manner.
In embodiments in which particular multi-session driving metrics/scores
represent
weighted averages, each individual-session metric (e.g., each individual-
session Braking metric)
to be averaged into a weighted average may be weighted based on recentness
(e.g., based on the
elapsed time since that session, or the sequential order position of that
session (e.g., the 3" most
CA 02805995 2013-02-18
24
recent session)), trip duration, trip distance, or any other relevant criteria
accessible to data
processing module 42. Thus, for instance, the weighting of each individual-
session metric to be
averaged into a weighted average may be weighted proportionally according to
the number of
days since each respective session, such that a trip that occurred 20 days ago
is weighted twice as
much as a trip that occurred 20 days ago. As another example, the 1st most
recent, 21d most
recent, 3rd most recent, and 4th most recent sessions may be assigned
predefined weighting
factors of 0.50, 0.30, 0.15, 0.05, respectively. As another example, a 6-mile
trip may be
weighted the same as, or twice as much, as a 3-mile trip, depending on the
specific embodiment.
As another example, a 30-minte trip may be weighted the same as, or three
times as much, a 10-
minute trip, depending on the specific embodiment.
Alternatively, instead of displaying the average of the metrics/scores
determined for a
group of data collection sessions, summary screen 230 may display the median
value for
particular metrics/scores. Thus, for example, summary screen 230 may display
for each metric
the median value for that metric over the last seven trips. As another
alternative, summary
screen 230 may display the lowest or highest value for particular
metrics/scores. Thus, for
example, summary screen 230 may display for each metric the lowest value for
that metric over
the last seven trips.
It should be understood that multi-session driving metrics/scores may be
determined
using any combination of techniques or algorithms discussed above, or using
any other suitable
techniques or algorithms.
FIGURE 6E illustrates an example screenshot of a screen 240 summarizing
various data
for each of multiple data collection sessions. In this example, screen 240
indicates for each data
collection session for a particular driver: a trip description (manually
entered by a user or
automatically determined by module 42, e.g., based on GPS data), trip date,
trip time (e.g.,
session start time, end time, or midpoint), and driving score (indicated by a
bar graph and
numerical value). In addition to or instead of displaying the driving score
for each session,
screen 240 may display one or more driving behavior metrics for each session,
and/or other data
relevant to each session (e.g., weather conditions, traffic conditions, trip
distance, trip duration,
etc.). Any number of sessions may be displayed, and the particular sessions
that are displayed
CA 02805995 2013-02-18
may be filtered, e.g., according to any of the criteria discussed above. In
the illustrated example,
the user may scroll down on screen 240 to view data for additional sessions.
FIGURE 6F illustrates an example screenshot of a screen 250 in which multiple
trips can
be compared. In this example, two trips by the same driver are compared.
However, trips by
5 different drivers may similarly be compared. The trips being compared may
be selected by a
user, or automatically selected by module 42 based on any suitable criteria.
The compare
function may be used to test drivers against a particular test course. For
example, a driver
education instructor could collect driving behavior metrics for himself by
driving a test course.
Later, students could collect driving behavior metrics while driving the same
test course as
10 previously driven by the instructor. The driving behavior metrics of the
instructor could then be
used as a standard against which to compare the driving behavior metrics of
the students.
FIGURE 6G illustrates an example screenshot of a map screen 260, indicating
the path
262 of a recorded trip, which may be generated based on data collected by
location tracking
system 56 (e.g., GPS data). Screen 260 may also display icons 264 indicating
the locations of
15 notable driving events (NDEs). Such icons 264 may indicate the type
and/or severity level of
each NDE. In the illustrated example, the type of NDE (e.g., type "L", "R",
"A", or "D") is
indicated by the shape of the respective icon 264, and the severity level of
the NDE is indicated
by the color of the icon 264, indicated in FIGURE 6G by different shading. In
some
embodiments, the user may select a particular icon 264 to display (e.g., via a
pop-up window or
20 new screen) additional details regarding the respective NDE.
It should be understood that driving analysis application 50 may generate any
number of
additional screens for displaying the various information collected or
processed by application
50.
FIGURE 3 illustrates an example method 80 of providing driver feedback,
according to
25 certain embodiments. Any or all of the steps of method 80 may be
performed by the various
modules of driving analysis application 50.
At step 82, data collection module 40 may collect driving data during a data
collection
session (which may correspond to a driving trip, a portion of a driving trip,
or multiple driving
trips). The collected driving data may include, e.g., driving behavior data
collected by
CA 02805995 2013-02-18
26
accelerometer 54, location tracking system 56, etc. and/or driving environment
data collected by
environmental data applications 58. The collected driving data may also
include driving
behavior data and/or driving environment data collected by external devices
and communicated
to mobile device 10.
Data collection module 40 may control the start and stop of the data
collection session
either manually or automatically, as discussed herein. In some embodiments,
this may include
interacting with the user (driver or other person) to manage the physical
orientation of mobile
device 10 in order to allow the driving data collection to begin (or re-start
after an interruption),
as discussed above.
At step 84, data processing module 42 may process or analyze any or all of the
driving
data collected at step 82, and calculate one or more driving behavior metrics
and/or scores
corresponding to the data collection session, e.g., as discussed above. In
addition, data
processing module 42 may identify "notable driving events" (NDEs) and
determine the severity
of such events, e.g., as discussed above. In some embodiments, data processing
module 42 may
process the collected data in real time or substantially in real time. In
other embodiments, data
processing module 42 may process the collected data after some delay period,
upon the end of
the data collection session, in response to a request by a user (e.g., a user
of mobile device 10, a
user at remote computer 150, or other user), upon collection of data for a
preset number of data
collection session, or at any other suitable time or in response to any other
suitable event.
In some embodiments, data processing module 42 may calculate one or more
individual
driving behavior metrics (e.g., acceleration, braking, cornering, etc.) and/or
driving scores for the
current or most recent data collection session. Further, data processing
module 42 may calculate
one or more individual driving behavior metrics and/or driving scores for
multiple data
collection sessions. For example, data processing module 42 may calculate
filtered or averaged
driving behavior metrics and/or driving scores for a group of data collection
sessions (e.g., as
discussed above), including the current or most recent data collection
session.
At step 86, feedback module 44 may display any of the data collected by data
collection
module 40 at step 82 (e.g., raw data or filtered raw data) and/or any of the
metrics, scores, or
other data calculated or proceed by data processing module 42 at step 84. This
may include any
CA 02805995 2013-02-18
27
manner of "displaying" data as discussed above, e.g., displaying data on
display device 36,
providing visual, audible, or other sensory feedback to the driver via mobile
device 10 or other
device in the vehicle, communicating data to remote computer devices for
remote display, etc.
In some embodiments, feedback module 44 may facilitate user interaction with
application 50
(e.g., via a touch screen display 36 or other input devices 38) allowing the
user to view any of the
data discussed above, e.g., by user selection or navigation of displayed
objects).
At step 88, feedback module 44 may initiate and/or manage the storage of any
of the data
collected by data collection module 40 at step 82 (e.g., raw data or filtered
raw data) and/or any
of the metrics, scores, or other data calculated or proceed by data processing
module 42 at step
84, such that the stored data may be subsequently accessed, e.g., for display
or further
processing. For example, feedback module 44 may store data in local volatile
memory for
display, in local non-volatile memory as historical driving data 46, and/or in
remote memory as
historical driving data 152.
As shown in FIGURE 3, method 80 may then return to step 82 for the collection
of new
driving data. It should be understood that the steps shown in FIGURE 3 may be
performed in
any suitable order, and additional steps may be included in the process.
Further, certain steps
may be performed continuously (e.g., the data collection step 82 may continue
throughout the
data collection process). Further, multiple steps may be performed partially
or fully
simultaneously.
In some embodiments, steps 82-88 (or at least portions of such steps) may be
executed in
real time or substantially in real time such that steps 82-88 are continuously
performed, or
repeated, during a particular data collection session. In such embodiments, at
step 86 data may
be prepared for subsequent display rather than being displayed in real time,
while the process
continues to collect, process, and store new driving data. However, as
discussed above, certain
feedback may be provided at step 86 in real time, e.g., real time feedback
indicating the
occurrence of notable driving events. In other embodiments, one or more steps
may not be
performed in real time. For example, some or all of the processing, display,
and storage steps
may be performed after the completion of the data collection session, e.g.,
when more processing
resources may be available. For instance, collected raw data may be stored in
first memory (e.g.,
CA 02805995 2013-02-18
28
cache or other volatile memory) during the data collection session; and then
after the end of the
data collection session, the collected data may be processed, displayed,
stored in second memory
(e.g., stored in non-volatile memory as historical driving data 46), and/or
communicated to
remote entities for storage, processing, and/or display.
As discussed above, in some embodiments, driving data collected by application
50 may
be used by various third parties for various purposes. Thus, for example, at
step 90, an insurance
provider may receive or access driving behavior metrics and/or driving scores
collected by
application 50 (e.g., by receiving or accessing historical driving data 46
directly from mobile
device 10 and/or by receiving or accessing historical driving data 152 from
external storage), and
analyze such data for performing risk analysis of the respective driver. The
insurance provider
may determine appropriate insurance products or premiums for the driver
according to such risk
analysis.
FIGURE 4 illustrates an example method 100 of providing driver feedback using
example algorithms, according to certain embodiments. Any or all of the steps
of method 100
may be performed by the various modules of driving analysis application 50.
At step 102, data collection module 40 may interact with the user to adjust
the mobile
device 10 such that the orientation of mobile device 10 is suitable for
collecting driving data.
For example, data collection module 40 may instruct the user to position the
mobile device 10
towards the front of the vehicle and with the top end of the mobile device 10
facing the front of
the vehicle.
Once data collection module 40 determines that mobile device 10 is properly
oriented,
data collection module 40 may begin collecting driving data, i.e., start a
data collection session,
at step 104. For example, data collection module 40 may begin collecting raw G-
force data (i.e.,
acceleration data) from built-in accelerometer 54. The collected G-force data
may provide data
for multiple different acceleration directions, e.g., lateral G-force data
regarding lateral
acceleration and longitudinal G-force data regarding longitudinal
acceleration. Module 40 may
time stamp the collected data. Further, module 40 may filter or truncate the
beginning and end
of the data collection session, the extent of which filtering or truncation
may depend on the
length of the data collection session. For example, if the data collection
session exceeds 4
CA 02805995 2013-02-18
29
minutes, module 40 may erase data collected during the first and last 60
seconds of the data
collection session; whereas if the data collection session does not exceed 4
minutes, module 40
may erase data collected during the first and last 3 seconds of the data
collection session. The
particular values of 4 minutes, 60 seconds, and 3 seconds are example values
only; any other
suitable values may be used.
At step 106, data processing module 42 may process the collected driving data.
For
example, module 42 may calculate a one-second moving average of the G-force.
Thus, if the
data collection is for instance 5 Hz, the 5-step moving average may be
calculated.
Module 42 may then calculate the "jerk" at each time stamp T,, wherein jerk at
a
particular time stamp 7; is defined as follows:
Jerk = abs (moving averaged G-force at time stamp T, ¨ moving
averaged G-force at time stamp T) / unit_time (1 second)
(Alternatively, jerk may be calculated using raw G-forces data instead of
averaged G-force data.)
Module 42 may then calculate the one-second moving average of the jerk.
Module 42 may then determine one or more driving behavior metrics based on the
moving averaged jerk and G-force data. For example, module 42 may determine a
G-force
percentile and a jerk percentile at each time stamp T, by accessing look-up
tables corresponding
to one or more relevant parameters. For instance, a portion of an example look-
up table for an
example set of relevant parameters is provided below:
Relevant Parameters:
Vehicle: Impala
Vehicle type: Sedan
Acceleration direction (lateral or longitudinal): Lateral
Type of data (G-force or Jerk): G-force
Speed range: 0-100 mph
Table 1: G-force Percentile Look-Up Table
G-force range Percentile
0.000 0.012 0
0.013 0.025 1
CA 02805995 2013-02-18
0.026 0.038 2
0.039 0.051 3
0.052 0.064 4
0.065 0.077 5
0.078 0.090 6
Module 42 may store or have access to any number of such look-up tables for
various
combinations of relevant parameters. For example, module 42 may store a look-
up table (similar
to Table 1) for determining the jerk percentile. As another example, module 42
may store
5 similar look-up tables for determining G-force and jerk percentiles for
different combinations of
vehicles, vehicle types, speed ranges, acceleration direction (lateral or
longitudinal), etc.
At step 108, data processing module 42 may calculate a Base Driving Score for
the data
collection session, according to the following equation:
Base Driving Score = (AVG_G-force_percentile) * W1 +
10 (AVG_Jerk_percentile) * W2
wherein:
AVG G-force_percentile is the average of the G-force percentiles for all time
stamps T, during the data collection session;
AVG_Jerk_percentile is the average of the jerk percentiles for all time stamps
T,
15 during the data collection session; and
W1 and W2 are weighting constants used to weight the relative significance of
G-
force data and jerk data as desired.
As another example, the base driving score may be calculated according to the
following
equations:
20 T, Driving Score = min
(100, 250 ¨ (2 * T, percentile))
Base Driving Score = average of all T, Driving Scores in which
max G-force (lateral, longitudinal) < predefined minimal value.
wherein:
CA 02805995 2013-02-18
31
T, percentile is a percentile determined for each time stamp T, (e.g., G-force
percentile, jerk percentile, or a weighted average of G-force percentile and
jerk percentile
for the time stamp T,);
T, Driving Score is a driving score for each time stamp T,; and
1; Driving Scores in which max 6-force (lateral, longitudinal) < predefined
minimal value indicates that data from time stamps in which the max (lateral,
longitudinal) 6-force is less than some predefined minimal value (e.g., 0.01)
is excluded
from the calculations. For example, due to the fact that g-forces may be less
than some
predefined minimal value (e.g., 0.01) at some or many time stamps (e.g.,
during highway
cruise driving), as well as the issue of unstable g-force reading (below) a
predefined
minimal value, module 42 may ignore data from time stamps in which the max
(lateral,
longitudinal) G-force is less than the predefined minimal value.
At step 110, data processing module 42 may identify and analyze any notable
driving
events during the data collection session, based on the collected/processed G-
force data and jerk
data. For example, module 42 may compare the lateral and longitudinal G-force
data to
corresponding threshold values to identify the occurrence of notable driving
events. For
example, module 42 may execute the following example algorithms to identify
the occurrence
and type of a notable driving event (NDE) for a Chevrolet Impala:
lat_magnitude_gf = max(0, abs(LatG) - 0.40);
lon_magnitude gf = max(0, abs(LonG) - 0.30);
magnitude_gf = max(lat_magnitude_gf, lon_magnitude_gf);
--- if magnitude_gf lat_magnitude_gf and latG.>0 then NDE_type =
--- else if magnitude gf= lat_magnitude_gf and latG.<=0 then NDE_type =
--- else if magnitude_gf = lon_magnitude_gf and lonG<0 then NDE_type = "A";
--- else if magnitude_gf = lon_magnitude_gf and lonG>=0 then NDE_type =
--- else no NDE identified.
wherein:
LatG = lateral G-forces detected by the accelerometer;
LonG = longitudinal G-forces detected by the accelerometer;
CA 02805995 2013-02-18
32
NDE_type "L" = Left Cornering
NDE_type "R" = Right Cornering
NDE_type "A" = Acceleration
NDE_type "D" = Deceleration
The threshold values used in such algorithms (e.g., the LatG and LonG
threshold values
0.40 and 0.30 shown above) may be specific to one or more parameters, such
that module 42
applies appropriate thresholds based on the parameter(s) relevant to the data
being analyzed. For
example, module 42 may store different threshold values for different types of
vehicles. To
illustrate an example, module 42 may store the following threshold values for
three different
vehicles: Impala, Camaro, and FordVan:
Impala (shown above)
LatG threshold = 0.40
LonG threshold = 0.30
Camaro
LatG threshold = 0.60
LonG threshold = 0.40
Ford Van
LatG threshold = 0.30
LonG threshold = 0.30
It should be understood that the threshold values shown above are examples
only, and
that any other suitable values may be used.
Data processing module 42 may further determine the severity level of each
notable
driving event (NDE) identified during the data collection session. For
example, FIGURE 7
provides an illustrative flow chart wherein module 42 may execute the
following algorithm to
determine the severity level (e.g., caution, warning, or extreme) of each NDE:
--- start 701 the algorithm
--- identify 702 the G-force magnitude peak associated with the NDE;
--- if the G-force magnitude peak is at least 0.2 above the relevant LatG/LonG
threshold 703, the NDE severity level is "extreme" 704;
CA 02805995 2013-02-18
33
--- else if the G-force magnitude peak is at least 0.1 above the relevant
LatG/LonG threshold 705, the NDE severity level is "warning" 706;
--- else if the G-force magnitude peak is above the caution threshold 707, the
NDE severity level is "caution" 708; and
--- return 709 to the algorithm for detecting NDEs.
It should be understood that the threshold values shown above (0.2 and 0.1)
are examples only,
and that any other suitable values may be used.
FIGURE 8 is a flow chart of an alternative illustrative algorithm for
determining severity
levels of notable driving events (NDE) identified during data collection
sessions. In this
embodiment, the output severity levels are "severe," "medium" and "low."
Data processing module 42 may further "de-dupe" identified NDEs, i.e.,
eliminate or
attempt to eliminate double counting (or more) of the same NDE. For example,
module 42 may
apply an algorithm that applies a 30 second rule for de-duping the same type
of NDE (e.g., L, R,
A, or D), and a 4 second rule for de-duping different types of NDEs. Thus, if
multiple NDEs of
the same type (e.g., two L-type events) are identified within a 30 second
window, module 42
assumes that the same NDE is being counted multiple times, and thus treats the
multiple
identified NDEs as a single NDE. Further, if multiple NDEs of different types
(e.g., one L-type
event and one R-type event) are identified within a 4 second window, module 42
assumes that
the same NDE is being counted multiple times, and thus treats the multiple
identified NDEs as a
single NDE, and applies any suitable rule to determine the NDE type that the
NDE will be
treated as (e.g., the type of the first identified NDE controls, or a set of
rules defining that
particular NDE types control over other NDE types).
It should be understood that the de-duping time limits shown above (30 seconds
and 4
seconds) are examples only, and that any other suitable time limits may be
used.
Referring again to FIGURE 4, at step 116 feedback module 44 may initiate
and/or
manage the storage of any of the data collected by data collection module 40
at step 104 (e.g.,
raw data or filtered raw data) and/or any of the metrics, scores, or other
data calculated or
processed by data processing module 42 at steps 106-112, such that the stored
data may be
subsequently accessed, e.g., for display or further processing. For example,
feedback module 44
CA 02805995 2013-02-18
34
may store data in local volatile memory for display, in local non-volatile
memory as historical
driving data 46, and/or communicate data to remote devices 150 and/or remote
driving data
storage 152.
As discussed above, in some embodiments, driving data collected by application
50 may
be used by various third parties for various purposes. Thus, for example, at
step 118, an
insurance provider may receive or access driving behavior metrics and/or
driving scores
collected by application 50 (e.g., by receiving or accessing historical
driving data 46 directly
from mobile device 10 and/or by receiving or accessing historical driving data
152 from external
storage), and analyze such data for performing risk analysis of the respective
driver. The
insurance provider may determine appropriate insurance products or premiums
for the driver
according to such risk analysis.
At step 112 (see FIGURE 4), data processing module 42 may calculate an
Adjusted
Driving Score for the data collection session, by adjusting the Base Driving
Score certain values
calculated at step 108 based on NDEs determined at step 110. For example,
module 42 may
deduct from the Base Driving Score based on the number, type, and/or severity
level of NDEs
determined at step 110. In some embodiments, only certain types and/or
severity levels of NDEs
are deducted from the Base Driving Score. For example, module 42 may execute
the following
algorithm, in which only "warning" and "extreme" level NDEs (but not "caution"
level NDEs)
are deducted from the Base Driving Score:
NDE Penalty for each NDE = 50 * (G-force ¨ G-force_warning_threshold);
--- Adjusted Driving Score = Base Driving Score ¨ sum (NDE Penalties)
It should be understood that this algorithm is an example only, and that any
other suitable
algorithms for determining an Adjusted Driving Score may be used.
At step 114, feedback module 44 may display any of the data collected by data
collection
module 40 at step 104 (e.g., raw data or filtered raw data) and/or any of the
metrics, scores, or
other data calculated or processed by data processing module 42 at steps 106-
112. This may
include any manner of "displaying" data as discussed above, e.g., displaying
data on display
device 36 on mobile device 10, providing visual, audible, or other sensory
feedback to the driver
via mobile device 10 or other device in the vehicle, communicating data to
remote computer
CA 02805995 2013-02-18
devices for remote display, etc. In some embodiments, feedback module 44 may
facilitate user
interaction with application 50 (e.g., via a touch screen display 36 or other
input devices 38)
allowing the user to view any of the data discussed above, e.g., by user
selection or navigation of
displayed objects).
5
FIGURE 5 illustrates an example system 140 for sharing driving data between a
mobile
device 10 including driving analysis application 50 and other external systems
or devices,
according to certain embodiments. As shown, mobile device 10 may be
communicatively
connected to one or more remote computers 150 and/or remote data storage
systems 152 via one
or more networks 144.
10
Computers 150 may include any one or more devices operable to receive driving
data
from mobile device 10 and further process and/or display such data, e.g.,
mobile telephones,
personal digital assistants (PDA), laptop computers, desktop computers,
servers, or any other
device. In some embodiments, a computer 150 may include any suitable
application(s) for
interfacing with application 50 on mobile device 10, e.g., which
application(s) may be
15 downloaded via the Internet or otherwise installed on computer 150.
In some embodiments, one or more computers 150 may be configured to perform
some
or all of the data processing discussed above with respect to data processing
module 42 on
mobile device 10. Such a computer may be referred to herein as a remote
processing computer.
For example, mobile device 10 may communicate some or all data collected by
data collection
20
module 40 (raw data, filtered data, or otherwise partially processed data) to
a remote processing
computer 150, which may process (or further process) the received data, e.g.,
by performing any
or all of the driver data processing discussed above with respect to data
processing module 42,
and/or additional data processing. After processing the data, computer 150 may
then
communicate the processed data back to mobile device 10 (e.g., for storage
and/or display), to
25
other remote computers 150 (e.g., for storage and/or display), and/or to
remote data storage 152.
The data processing and communication of data by computer 150 may be performed
in real time
or at any other suitable time. In some embodiments, computer 150 may process
driving data
from mobile device 10 and communicate the processed data back to mobile device
10 such that
CA 02805995 2013-02-18
36
the data may be displayed by mobile device 10 substantially in real time, or
alternatively at or
shortly after (e.g., within seconds of) the completion of a driving data
collection session.
Using one or more computers 150 to perform some or all of the processing of
the driving
data may allow for more processing resources to be applied to the data
processing (e.g., thus
providing for faster or additional levels of data processing), as compared to
processing the data
by mobile device 10 itself. Further, using computer(s) 150 to perform some or
all of the data
processing may free up processing resources of mobile device 10, which may be
advantageous.
Remote data storage devices 152 may include any one or more data storage
devices for
storing driving data received from mobile device 10 and/or computers 150.
Remote data storage
152 may comprise any one or more devices suitable for storing electronic data,
e.g., RAM,
DRAM, ROM, flash memory, and/or any other type of volatile or non-volatile
memory or
storage device. A remote data storage device 152 may include any suitable
application(s) for
interfacing with application 50 on mobile device 10 and/or with relevant
applications on
computers 150.
Network(s) 144 may be implemented as, or may be a part of, a storage area
network
(SAN), personal area network (PAN), local area network (LAN), a metropolitan
area network
(MAN), a wide area network (WAN), a wireless local area network (WLAN), a
virtual private
network (VPN), an intranet, the Internet or any other appropriate architecture
or system that
facilitates the communication of signals, data and/or messages (generally
referred to as data) via
any one or more wired and/or wireless communication links. The network(s) 144
may include
any communication link known to persons of skill, including for example,
cloud, cellular or
satellite transmission, magnetic or optical media, radio frequency
transmission, microwave or
fiber optic transmission, or communications via Internet, cable, or satellite
providers.
Referring to FIGURE 9, an example of an architectural design for an
infrastructure
according to embodiments of the invention. An infrastructure 151 according to
one embodiment
comprises a remote data storage system 152 and a property and casualty system
153. Data may
be transmitted via a network 144 from a mobile device 10 in a vehicle 12 to a
remote data
storage system 152.
CA 02805995 2013-02-18
=
37
The remote data storage system 152 comprises a server 154 and a database 155.
The
database 155 stores various data and information transmitted to it via the
server 154, including:
data received from a mobile device 156, data calculated by a mobile device
prior to receiving
157, and captured and available data for property and casualty rating 158.
Data received from a
mobile device 156 may comprise: device identification; Bluetooth MAC address;
trip number;
location - latitude; location - longitude; location - coarse / fine indicator;
speed; acceleration -X;
acceleration -Y; acceleration -Z; GPS date and time; turn indicator and/or GPS
accuracy. Prior
to sending, the mobile device 10 may also calculate information. Data
calculated by a mobile
device prior to receiving 157 may include: turn indicator; lateral G force;
longitudinal G force;
turn radius; average lateral G force; average longitudinal G force; average
turn radius; X
midpoint; X now; X back 1; X back 2; Y midpoint; Y now; Y back 1; Y back 2;
tangent
calculation for radius 1; tangent calculation for radius 2; time change
between locations;
longitude G with local gravity; lateral G with local gravity; lateral G
calculated; lateral G second
derivative; and/or parallel G slope. Examples of captured and available data
for property and
casualty rating 158 may include; vehicle information (age, manufacturer,
model, value), driver
information (age, sex, marital status, driving record, accident history,
residence), and insurance
information (liability, uninsured motorists, comprehensive, collision,
liability limits, deductibles,
rebates, discounts).
The property and casualty system 153 comprises a server 140, a storage
application 141,
a staging telematics database 142 and an operational telematics data base 143.
The property and
casualty system 153 uses the data captured by the remote data storage system
152 to calculate
property and casualty premiums for the operators of vehicles. Threshold
metrics may be
established for driving behaviors so that property and casualty premiums may
be identified to
correspond to the driving behaviors. This system may be automated so that the
property and
casualty premiums may be charge to the operators of vehicles in real time
depending on their
driving behaviors.
FIGURE 10 provides a flow chart for a driving analysis application 50. The
application
launches 160 on a mobile device 10 (see FIGURE 1) and splashes 161 an
introductory page
publishing the name of the application and appropriate logos to identify the
application. The
CA 02805995 2013-02-18
38
application queries the user 162 to determine whether the user is registered.
If the user is not
registered, the application 50 will prompt the user to create an account 163.
When the user is
registering for the first time, the user may enter details like: username;
password; vehicle make;
vehicle year; vehicle model; and/or vehicle odometer reading. The application
50 may then
determine if an account is successfully created 167, and if not again prompt
the user to create an
account 163. If an account is successfully created 167, the user may be
directed to a main menu
(landing page) 164 that may have options: (1) a Bluetooth pairing setup 165
for completing the
registration or modifying the car which is being used; (2) a daily summary 168
giving details
regarding the trips of the user; (3) an odometer option 169 for updating the
odometer reading of
the paired vehicle; and (4) a help section 170 for the user to report
technical difficulties with the
application 50 or to answer questions that the user may have.
From the main menu (landing page) 164, the user may select a Bluetooth pairing
setup
165 for completing the registration or modifying the vehicle which is being
operated by
completing a Bluetooth pairing. If the user exits the application prior to
Bluetooth pairing, then
the user may not able to access the daily summary and odometer details. If the
Bluetooth pairing
165 is successful, then the data 166 (Bluetooth pairing; vehicle year; vehicle
model; and/or
vehicle odometer reading) may be transmitted to a server 154. If the Bluetooth
pairing 165 is
unsuccessful, the application 50 may return to the main menu (landing page)
164. Once as user
has successfully created an account 163 and Bluetooth paired 165 the mobile
device 10 with the
vehicle 12, the application 50 always runs in the background for collection of
data. As soon as
the user starts the vehicle, the data logging starts to take place. Collected
data is automatically
transmitted to the server 154, described more fully below. During the whole
process certain data
is sent to the server 154 from the mobile device 10, and similarly after
calculations are made,
data may be received by the mobile device 10 from the server 154. Data sent to
the server 154
may include: Username; Password; Vehicle Make; Vehicle Year; Vehicle Model;
Odometer
Reading; and Bluetooth Mac address. Data received from the server 154 may
include: Date
Selection; Vehicle Details; Total Miles Driven; Number of Stops; Number of
Trips; Maximum
Speed; Odometer Reading; Time Specific Details; Speed Specific Details; and
Trip List.
CA 02805995 2013-02-18
39
In alternative embodiments of the invention, any trigger may be used to tell
the
application 50 to begin logging data. For example, a threshold engine speed
(RPM) may trigger
data logging. As a further example, movement of the vehicle 12 may trigger
data logging.
FIGURE 10 further shows that, from the main menu (landing page) 164, the user
may
select a daily summary 168 giving details regarding the trips of the user.
Based on the trips for
that particular day a daily report is available to the user. The daily report
includes vehicle use
data 171, which may be transmitted from the remote data storage device 152 to
the mobile
device 10. The vehicle use data 171 may include: 1) "date selection" for the
user to select the
date of which he wants the details; 2) "vehicle details" that were entered by
the user at the start;
3) "total miles driven" are recorded by the application 50 once the user has
registered; 4)
"number of stops" provides information about the vehicle not moving, i.e.,
idling or being at 0
mph; 5) "number of trips" provides the total trips on that particular day; 6)
"maximum speed" is
the max speed reached on that particular day; and 7) "odometer reading" is the
total odometer
reading (User Entered Value + Total Miles Driven). The daily report may also
allow the user to
view: time specific details 172; speed specific details 173; and trip specific
details 174.
Time specific details (Time Interval) 172 may include time in blocks of 2
hours displayed
on the left hand side, which is helpful for the user to know in which times he
has driven the most.
Time specific details may be relevant to insurance providers to know whether
the user is driving
in high, moderate or low traffic times. Time specific details (Time Interval)
172 may also
include trip percentages, so the user can see what percent of total daily
driving each trip
comprised.
Speed Specific Details (Speed Interval) 173 may include time in blocks of 10,
with a
separate section for idling displayed on the left hand side, which may be
helpful for the user to
know the speed range he has driven the most. It may be relevant to insurance
providers to know
whether the user is driving at high, moderate or low speeds to determine risks
of potential
accidents. Speed Specific Details (Speed Interval) 173 may also include
percentages in which
the user drove at particular speed ranges, wherein the percentages add up to a
total of 100% for
that day.
CA 02805995 2013-02-18
Different Trip Details 174 may contain a list of trips by the user on that
particular day.
When the user selects a particular trip, the application 50 may provide the
user the route that was
traversed on the trip, which is similar to a GPS plot on a map.
Turning to FIGURES 11A-11K, example screen shots of the application user
interface
5 are
provided. FIGURE 11A illustrates an user interface for prompting the user to
create an
account 163, wherein fields are provided for a user ID, password, and zip
code. If the user
successfully creates an account, the application 50 prompts the user to select
Setting to complete
registration as shown in FIGURE 11B. A Settings tab (see FIGURE 11C) allows
the user to
navigate to a Bluetooth Setup window as shown in FIGURE 11D. From this window,
the user
10 may
select a Bluetooth Settings tab, which will enable the application 50 to cause
the mobile
device 10 to search for a signal from a vehicle 12 and pair the mobile device
10 to the vehicle 12.
After pairing, a Vehicle screen is displayed to the user so that the user is
prompted to enter the
year, make, model and odometer of the paired vehicle 12, as shown in FIGURE
11E. Once
paired with the vehicle, registration is complete.
15
FIGURE 11F shows a screen shot for a main menu (landing page) 164. The user is
provided tabs for Drive Data, Odometer, Settings, and Help. The Drive Data tab
allows the user
to navigate to a Daily Report screen as shown in FIGURE 11G. For any given day
selectable by
the user, the Daily Report identifies the vehicle, provides the total miles
driven (moving time),
the number of stops, the number of trips, the maximum speed, and the odometer.
The Daily
20
Report screen also provides the user three tabs: Speed, Time, and Trip. The
Speed tab navigates
to a screen as shown in FIGURE 11H, which shows speed ranges in increments of
10 miles per
hour, for example, and the percent of time the vehicle was operated within
each speed range
during the day. In this illustration for a vehicle operated on December 22,
2011, the vehicle
idled for 22% of the time, was operated between 1-9 mph for 6% of the time,
was operated
25
between 10-19 mph for 9% of the time, was operated between 20-29 mph for 9% of
the time,
was operated between 30-39 mph for 20% of the time, was operated between 40-49
mph for 31%
of the time, and was operated between 50-59 mph for 4% of the time. The Time
tab shown in
FIGURE 11G navigates to a screen as shown in FIGURE 111, which provides
periods of time
during the day and the percent of operation during each time period. In this
illustration for a
CA 02805995 2013-02-18
41
vehicle operated on December 22, 2011, 100% of the operation was between 6:00 -
7:59 am.
The Trip tab shown in FIGURE 11G navigates to a screen as shown in FIGURE 11J,
which
provides a listing of trips for the selected date. In this example, only one
trip (6:06 AM 6.5
miles) was recorded on the selected day. If the user selects a trip displayed
on the screen of
FIGURE 11J, the application 50 navigates to a map with the trip plotted
thereon, as shown in
FIGURE 11K.
Referring again to FIGURE 11F, if the user selects the Odometer tab from the
main menu
(landing page) 164, the application navigates to an Odometer Update screen as
shown in
FIGURE 11L. This screen prompts the user to enter the actual vehicle odometer
reading.
FIGURE 12 illustrates an example flow chart for the collection and analysis of
vehicle
use data according to certain embodiments of the invention. When the user
starts 180 the engine
of the vehicle, a Bluetooth connection is made 181 between the mobile device
10 and the vehicle
12. If the Bluetooth connection is unsuccessful, the application 50 does not
start logging data
182. If the Bluetooth connection is successful, the application 50 does start
logging data 183.
The application 50 will log vehicle use data until the vehicle engine is
turned off. The status of
the engine is monitored 184 and if the engine is turned off, the application
50 stops logging data
185. Any data collected on the mobile device when the engine is turned off is
sent to the server
154 of the remote data storage system 152. As long as the vehicle engine is
not turned off, data
is collected 186 every second on the mobile device 10. Data collected every
second 187 may
include: (1) Acceleration Data from accelerometer or sensor used for
determining speed, stops,
acceleration, and turns; (2) G-force Data for very high speed brakes, hard
brakes, smooth brakes,
very high speed turns, hard turns, smooth turns, very high speed acceleration,
hard acceleration,
or smooth acceleration; (3) GPS/Location Coordinate Data used for plotting the
route and speed;
and (4) Time based information for telling time periods of operation. Data is
transmitted 188
from the mobile device 10 to the server 154 of the remote data storage system
152 via a network
144. Every 1 minute of data is sent 189 to the server for backend calculations
if the network is
readily available. In the case of non availability of network or intermittent
availability the data is
stored 191 on the mobile device 10 until that batch is sent to the server. It
is sent as soon as the
network is available on the user's mobile device 10. Data is sent back 190
from the server after
CA 02805995 2013-02-18
=
42
calculations for the users Daily Report and also to allow the user to see the
data in the terms of
the time, trip and speed. When the vehicle is turned off, the application
stops logging the data
185, and the remaining data is then sent to the server for calculations at the
point of
disconnection of the Bluetooth.
FIGURE 13 illustrates another example flow chart for the collection and
analysis of
vehicle use data according to certain embodiments of the invention.
A user enters a vehicle 12 at 300. At 302 the vehicle 12 is started, e.g.,
manually by the
user or automatically based on signaling between the vehicle 12 and a
triggering device 15 (e.g.,
key fob) or other electronic device. Upon starting of the vehicle, a
connection and authentication
process begins between the vehicle 12 and the mobile device 10. First, at 304,
a Bluetooth
connection is automatically made between the mobile device 10 and the vehicle
12, which allows
communications of certain types of data (e.g., for authentication or
handshaking) between the
mobile device 10 and the vehicle 12. In some embodiments, the Bluetooth
connection may
require that a Bluetooth pairing setup has previously been performed, e.g.,
using the process
described above with respect to steps 164-166 shown in FIGURE 10.
In addition, in some embodiments or situations application 50 may
automatically start or
turn itself on upon detecting that the mobile device 10 is inside the vehicle,
upon starting of the
vehicle, or upon some other triggering signal, e.g., as discussed above. This
may occur prior to,
simultaneous with, or after the Bluetooth connection is automatically
established at 304,
depending on the particular embodiment. In other embodiments or situations,
application 50
may already be running (e.g., in the background of device 10) at the time the
user enters and
starts the vehicle.
With application 50 running and the Bluetooth connection established, at 306
driving
analysis application 50 automatically determines whether a setup process for
the application 50
has been completed. The setup process may include a user registration process,
such as the user
registration/account setup process described above with respect to any or all
of the steps shown
in FIGURE 10. The setup process may also include any other required or
appropriate user
registration, authentication, or setup steps.
CA 02805995 2013-02-18
43
If driving analysis application 50 determines that the setup process has been
completed,
the method advances to 308. If not, at 310 application 50 facilitates the
completion of the
application setup process, e.g., by facilitating all or portions of the user
registration/account setup
process shown in FIGURE 10 and/or any other required or appropriate user
registration,
authentication, or setup steps. At 308, application 50 automatically obtains
or identifies the
Bluetooth MAC address of vehicle 12, which may be appended or otherwise
associated with
recorded vehicle use data by application 50 such that the recorded data may be
linked to the
particular vehicle 12 for data storage (e.g., locally at device 10 or remotely
by a remote data
storage system 152) and recall. After obtaining the vehicle's Bluetooth MAC
address,
application 50 automatically begins recording vehicle use data at 312.
Thus, in the manner described above, when the vehicle is started, a Bluetooth
connection
between mobile device 10 and vehicle 12 is automatically established and
application 50
automatically starts collecting and logging data, without requiring any
interaction with the user
(assuming the Bluetooth pairing and user registration/account setup processes
have previously
been completed).
At 314, application 50 continues to record vehicle use data. Application 50
may store the
recorded data locally and/or automatically transmit the recorded data to a
remote data storage
system 152, e.g., as discussed above with respect to FIGURES 9 and 10.
Application 50 may
store the Bluetooth MAC address of vehicle 12 and/or other identifying
information, in
association with the record vehicle use data.
Application 50 may continue to log vehicle use data until the vehicle is
turned off. In
some embodiments, data may be collected and recorded by application 50 every
second or
according to any other frequency or timing. The collected and recorded data
may include, for
example: (1) Acceleration Data from accelerometer or sensor used for
determining speed, stops,
acceleration, and turns; (2) G-force Data for very high speed brakes, hard
brakes, smooth brakes,
very high speed turns, hard turns, smooth turns, very high speed acceleration,
hard acceleration,
or smooth acceleration; (3) GPS/Location Coordinate Data used for plotting the
route and speed;
and (4) Time based information for telling time periods of operation.
CA 02805995 2013-02-18
44
In some embodiments, mobile device 10 transmits data recorded by application
50 to
server 154 of remote data storage system 152 or to any other remote storage or
remote or
backend processing system via a network 144. Mobile device 10 may transmit
data in real time,
or may send recorded data in batches, e.g., periodically or upon defined
triggering events. In
some embodiments, the remote storage system or backend processing system may
process data
received from mobile device 10 (e.g., performing calculations on such data),
and send resulting
data back to mobile device 10, either substantially in real time,
periodically, or upon defined
triggering events. For example, the remote storage system or backend
processing system may
receive and store recorded data from mobile device 10 every second, perform
backend
calculations on every minute-worth of received data, and provide resulting
data back to mobile
device 10 every minute or after defined triggering events.
While application 50 records data, the status of the vehicle engine is
continuously or
periodically monitored at 316. As long as the engine is running, the Bluetooth
connection is
maintained and application 50 continues to record data. However, upon
detecting that the engine
has been turned off, the vehicle 12 automatically disconnects the Bluetooth
connection with
mobile device 12 at 318. At 320 the application 50 automatically recognizes
that the vehicle has
disconnected the Bluetooth connection, and thus automatically stops recording
data at 322. At
324, the application 50 may transmit any recorded data that has not already
been transmitted to
the server 154 of the remote data storage system 152.
While some embodiments of the invention use a Bluetooth pairing between the
mobile
device 10 and the vehicle 12, any pairing methodology known to persons of
skill may be
employed. For example, an audio signal may fingerprint the vehicle 12 for the
mobile device 10.
Radio frequency signals may also be used.
According to different aspects of the invention, software may reside on the
mobile device
10 in the application 50 to perform various calculations and manipulation of
data, or software
may reside on a remote processing computer 150 or a remote data storage system
152 to perform
these functions. Depending on the storage and communication capabilities of
the mobile device
10, it may be more efficient to perform functions on the mobile device 10 or
on the on a remote
processing computer 150 or a remote data storage system 152.
CA 02805995 2013-02-18
A rating engine according to embodiments of the present invention may be used
to
generate or calculate use-based insurance premiums, which may be applied
prospectively or
retrospectively. Based on the collected data, a previously paid insurance
premium may be
adjusted by providing a rebate for low risk driving behaviors or charging a
surcharge for high
5 risk driving behaviors. In this retrospective case, the cost of insurance
may be the sum of a base
premium and the surcharge or rebate. In a prospective case, use data may be
collected for a
given month and used as a basis to set an insurance premium for a subsequent
month.
A rating engine may be used to calculate an insurance premium based on the
data
collected from the mobile device 10. From the data collected from the mobile
device 10,
10 individual factors tending to have predictive power may be isolated and
fed into the automated
rating engine. The individual factors may be placed in context with other
known information
about the insured user to increase the predictive power of the automated
rating engine to set an
appropriate insurance premium for the particular insured user. Insurance
premiums are typically
calculated based on actuarial classifications, which may be required for
underwriting. These
15 classifications may include: vehicle type, vehicle age, user age, user
sex, driving history, place
of residence, place of employment, traffic violations, vehicle equipment
(airbags, antilock
breaks, theft control), etc. Data collected from the mobile device 10 may be
used to supplement
these actuarial classifications to calculate an insurance premium.
The rating engine may employ use-based information from many drivers to
identify
20 factors that have greater or less predictive power. As more data is
collected on a larger number
of vehicle users, over time, the rating engine may be improved to place
greater weight on those
use factors that tend to have greater predictive power.
The use data collected from vehicles may be inserted into an insurance
company's
normal data streams to allow the rating engine to calculate insurance premiums
based on all
25 available information. Normal billing cycles and processes for
communicating premium
information to insured users may proceed without disruption as the rating
engine proceeds as
normal, except that it now incorporates use-based information into the premium
calculation.
To encourage vehicle users to register their mobile devices 10 and download
the
application 50 so as to take advantage of use-based insurance products,
wireless service
CA 02805995 2013-02-18
46
providers may discount service provider premiums in exchange for users
registering their mobile
devices 10 for use-based insurance. Wireless service providers and carriers
currently offer a
number of discounts and/or subsidizing programs for phone and data plans.
Participants in use-
based insurance programs may be offered discounts or subsidized programs
relative to their
phone or data plans.
Embodiments of the invention may be used in a variety of applications. For
example, a
driver feedback mobile device could be used to proctor a driver's test for a
candidate to obtain a
driver's license. It may be used to educate drivers about how to drive in ways
that promote
better fuel efficiency. The invention may be used to leverage mobile devices
to quantify and
differentiate an individual's insurance risk base on actual driving behaviors
and/or driving
environment. The invention may be used to provide data that could be used as a
basis to provide
a potential customer a quote for insurance. Embodiments of the invention may
be used by driver
education instructors and systems to educate drivers about safe driving
behaviors.
Although the disclosed embodiments are described in detail in the present
disclosure, it
should be understood that various changes, substitutions and alterations can
be made to the
embodiments without departing from their spirit and scope.
