U.S. patent application number 17/491945 was filed with the patent office on 2022-02-24 for system and method for estimation of vehicle accident damage and repair.
The applicant listed for this patent is Scope Technologies Holdings Limited. Invention is credited to Gil Emanuel Fuchs.
Application Number | 20220058701 17/491945 |
Document ID | / |
Family ID | 1000005947249 |
Filed Date | 2022-02-24 |
United States Patent
Application |
20220058701 |
Kind Code |
A1 |
Fuchs; Gil Emanuel |
February 24, 2022 |
System and Method for Estimation of Vehicle Accident Damage and
Repair
Abstract
Described herein is a system and method for predicting the
extent and cost of repair resulting from a vehicle accident. The
estimates can be based on one or more of in-vehicle sensor
measurements during the accident, external observations such as
weather and traffic and road conditions, and manually or digitally
input accident reports. The gathered information is compared to
information in a database from historical accidents and the
resulting damage and costs for those. The information is classified
according to impact force, direction and location along with the
specific type of vehicle. Maintaining and refreshing the
information and predictive models in the system is also part of the
invention.
Inventors: |
Fuchs; Gil Emanuel; (Nes
Tziona, IL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Scope Technologies Holdings Limited |
Road Town Tortola |
|
VG |
|
|
Family ID: |
1000005947249 |
Appl. No.: |
17/491945 |
Filed: |
October 1, 2021 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
14517543 |
Oct 17, 2014 |
11157973 |
|
|
17491945 |
|
|
|
|
PCT/IB2014/001656 |
Jun 27, 2014 |
|
|
|
14517543 |
|
|
|
|
61840383 |
Jun 27, 2013 |
|
|
|
61846203 |
Jul 15, 2013 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G07C 5/008 20130101;
G06Q 30/0283 20130101; G07C 5/085 20130101 |
International
Class: |
G06Q 30/02 20060101
G06Q030/02; G07C 5/00 20060101 G07C005/00 |
Claims
1. A system for vehicle accident damage and repair estimation,
comprising: one or more in-vehicle sensors configured to collect
information during a timeframe encompassing an accident, said
collected information including at least information indicative of
strength of an impact on the vehicle, zone of the impact, and
direction of the impact occurring during said timeframe; an
in-vehicle transceiver configured to transmit at least one of the
collected information and derivatives of the collected information;
a historical accident database which contains cross-referenced
entries for one or more of: vehicle type and equipment
configuration, vehicle age, vehicle condition, accident type,
accident severity, location of accident, vehicle impact zone, force
and direction, time of accident, vehicle parts replaced and
repaired, materials needed for repair, labor costs and material
costs to effect repairs, and sensor data and derivative products of
sensor data recorded for each accident; an accident review module
configured to: receive the information from said in-vehicle sensors
via said in-vehicle transceiver; classify the accident type and
severity based on similar entries in the historical accident
database; and generate a damage and repair estimate based on the
comparison to similar entries.
2. A system for vehicle accident damage and repair estimation,
comprising: a data collection module configured to collect
information about an accident; a historical accident database which
contains cross-referenced entries for at least: vehicle unique
identification number, location of prior accidents, vehicle impact
zone, force and direction for prior accidents, time of prior
accidents, past vehicle parts replaced and repairs, and sensor data
and derivative products of sensor data recorded by the data
collection module for each accident; and an accident review module
configured to: receive the information from the data collection
module via the communication module, classify the accident type and
severity based on similar entries in the historical accident
database, and generate a damage and repair estimate based on the
comparison to similar entries.
3. The system of claim 2, wherein the data collection module is
in-vehicle and wherein the collected information comprises
information from one or more in-vehicle sensors during a timeframe
encompassing the accident.
4. The system of claim 2, further comprising: an in-vehicle
transceiver capable of transmitting at least one of the collected
information and derivatives of the collected information to the
accident review module that is external to the vehicle.
5. The system of claim 2, further comprising: a repair parts
database which has cross-referenced entries including: location of
each part; applicable vehicles; availability of each part; and cost
of each part; wherein an estimate is generated for time and cost of
repair based on the identified type and severity of the accident
and the availability of parts in the vicinity of the accident.
6. The system of claim 2, wherein the accident damage and repair
estimate is transmitted to a mobile device or other device in
possession of at least one of an insurance adjuster, an emergency
responder and other authorized personnel.
7. The system of claim 2, wherein the in-vehicle transceiver is
further capable of receiving the accident damage and repair
information from the accident review module.
8. The system of claim 7, further comprising an in-vehicle display
screen wherein the accident damage and repair information received
by the in-vehicle transceiver are displayed on the display
screen.
9. The system of claim 2, wherein the data collection module
comprises at least one of an application on a mobile device
operated by an on-scene individual at the accident and manual data
collection by an on-scene individual.
10. The system of claim 2, wherein the historical accident database
comprises information compiled from a plurality of historical
accident reports.
11. The system of claim 3, wherein the historical database
comprises information compiled from in-vehicle sensors measurements
for a plurality of accidents and derivatives thereof.
12. The system of claim 3, wherein: said data collection module
comprises in-vehicle sensors for determining at least strength of
an impact, zone of an impact on the vehicle and direction of an
impact; and the classification of the accident type and severity
is, at least in part, in terms of impact zones, direction of impact
and force of impact.
13. The system of claim 12, wherein the classification of the
accident type and severity is configured for use at least in part
to determine fault when the accident is a two car collision.
14. The system of claim 2, wherein additional information is
collected from at least one of sensors external to the vehicle, web
services, and other observations external to the vehicle.
15. The system of claim 2, wherein the historical database
comprises information collected from at least one of sensors
external to the vehicle, web services, and other observations
external to the vehicle.
16. The system of claim 2, wherein the damage and repair estimate
includes a range of estimates and a statistical probability for the
validity of the range or intervals within the range.
17. The system of claim 2, wherein the historical accident database
is continually updated by at least one of: adding newer accident
data; removing data from older accidents; replacing more
qualitative data with more quantitative data; replacing manually
entered data with sensor data and sensor derived information;
updating the predictive models based on the new data; and updating
metadata associated with the quality of input data and the
predictive model.
18. A non-transitory computer readable medium, including
instructions stored thereon which when read and executed by one or
more computer processors cause the one or more computer processors
to perform the steps of: implement a data collection module
configured to collect information about an accident including at
least information indicative of strength of an impact on the
vehicle, zone of the impact, and direction of the impact occurring
during an accident; implement a historical accident database which
contains cross-referenced entries for one or more of: vehicle type
and equipment configuration, vehicle age, vehicle condition,
accident type, accident severity, location of accident, vehicle
impact zone, force and direction, time of accident, vehicle parts
replaced and repaired, materials needed for repair, labor costs and
material cost to effect repairs, and sensor data and derivative
products of sensor data recorded for each accident in the
historical accident database; and implement an accident review
module configured to: receive the information from the data
collection module; classify the accident type and severity based on
similar entries in the historical accident database; and generate a
damage and repair estimate based on the comparison to the similar
entries.
19. The system of claim 2, further comprising a vehicle configured
to move material or people along a transportation network, wherein
the data collection module comprises at least one or more sensors
disposed in said vehicle and wherein the collected information
comprises information output from said one or more sensors disposed
in said vehicle during a timeframe encompassing the accident.
20. The system of claim 1, wherein the accident review module is
located either in the vehicle or remote to the vehicle.
Description
RELATED APPLICATIONS
[0001] This application is a continuation of U.S. Nonprovisional
patent application Ser. No. 14/517,543, filed on Oct. 17, 2014,
entitled "System and Method for Estimation of Vehicle Accident
Damage and Repair"; which application was a continuation-in-part of
international application PCT/M2014/001656 titled "ONBOARD VEHICLE
ACCIDENT DETECTION AND DAMAGE ESTIMATION SYSTEM AND METHOD OF USE",
filed on Jun. 27, 2014. PCT/M2014/001656 claims the benefit of
priority to both U.S. Provisional Application No. 61/840,383 titled
"SYSTEM AND METHOD FOR DETERMINATION OF VEHICLE ACCIDENT
INFORMATION" filed on Jun. 27, 2013, and U.S. Provisional
Application No. 61/846,203 titled "SYSTEM AND METHOD FOR
DETERMINATION OF VEHICLE ACCIDENT INFORMATION" filed on Jul. 15,
2013. All of these applications are incorporated by reference in
their entireties. The present application is also related to U.S.
Patent Application titled "SYSTEM AND METHOD FOR USE OF PATTERN
RECOGNITION IN ASSESSING OR MONITORING VEHICLE STATUS OR OPERATOR
DRIVING BEHAVIOR", application Ser. No. 13/679,722, filed Nov. 16,
2012; which claims the benefit of priority to U.S. Provisional
Patent Application No. 61/578,511, filed Dec. 21, 2011; each of
which above applications are herein incorporated by reference.
FIELD OF INVENTION
[0002] Embodiments of the invention are generally related to
systems and methods to rapidly assess a vehicle accident and
produce an estimate of damage and cost of repair. In an embodiment,
the system monitors in-vehicle sensor output acquired during an
accident, then compares that output with a database of information
on previous similar accidents to estimate damage and amount of
repair work that may be needed. In other embodiments, the estimate
is transmitted to the accident scene in near real-time either to
the vehicle or to an insurance adjustor or other authorized party
carrying a mobile device.
BACKGROUND
[0003] Standard methods of dealing with repairing damage due to an
vehicle accident consist of: [0004] Visually assessing the damage,
[0005] Estimating the cost of repairs based on prior experience of
the assessor [0006] Finding a repair facility and a time when they
can do the work
[0007] Current state of the art is to perform these tasks manually
which is time consuming and requires input from several individuals
including an insurance adjuster, one or more estimators from a body
shop, a searcher for replacement parts, work on the part of the
driver or the insured in negotiating an insurance settlement and
the list goes on.
[0008] It may also be necessary, for insurance purposes, to assign
blame so that the insurance of the responsible party is charged.
This is typically done by interviewing participants in the accident
and/or witnesses of the accident. It can also, in part, be done by
examining the damage to the two vehicles to facilitate learning who
hit who.
[0009] There is a need to detect when and where a vehicle accident
occurs and to accurately assess the damage and loss as well as
injury associated with an accident immediately following the
accident. Systems in the art require two-way communications with a
central server to get information required to do an accurate
assessment of damage and to facilitate remedial action. By having
all the pertinent information needed to assess damage and effect
repair in-vehicle, issues requiring uninterrupted wireless
communication can be avoided. Should long-range wireless
communication be impeded, immediate information is available to
on-site interested parties via short-range wireless communication,
wired communication, visual display or physically removing memory
that contains event data and analysis. By having all pertinent
information in-vehicle, accident analysis can be performed locally
without the need of any communication. This information can then be
relayed digitally (in standard formats) or manually if necessary to
interested parties. This information can then be transmitted to,
for example, to insurance carriers for the vehicle, emergency
responders, service technicians, and towing and parts providers
when and if long-range wireless communications is available.
[0010] A large amount of data is necessary to accurately and
rapidly assess the damage resulting from a vehicle accident. Parts
of these data may be specific to both the vehicle, location, and
driver of the vehicle. To make pertinent vehicle information
available within the vehicle, part of this invention is the
methodology to parse and download that pertinent information
periodically to the vehicle.
[0011] Methods exist to collect vehicle sensor information and to
transmit that information to a central server for use in an
insurance claim, but no comprehensive in-vehicle system and
database exists that facilitates accident detection and rapid and
accurate damage assessment and/or facilitate immediate claim
processing and repair scheduling.
[0012] There is a need in the automotive insurance industry to
accurately predict the risk of claims being made and the costliness
of claims being made and adjusting the insurance rate charged to an
individual accordingly so that the individual is paying their
appropriate premium based on the risk attributed to the individual.
The more accurate the prediction, the lower the premiums can
become, making the insurer more competitive and presumably
profitable, and/or the insurer may choose to not insure those
individuals of the perceived greatest risk or smallest profit
potential.
[0013] It is known in the art to base premiums on such thing as the
geographic area where a driver lives, or potentially the area s/he
drives through on a regular basis. It is also known to further
evaluate rates based on the historical location and frequency of
accidents, crime rates, traffic flow and/or claims made in the
vicinity of geographic area used as a rating territory. It is
further known to adjust the rates based on the driver's past
driving history.
[0014] One of the many problems with existing insurance risk rating
systems is that they are too granular or non-specific. For example,
typically a geographic area for rating would be based on the
address of the owner of the vehicle. This would mean that all the
residents of a given area or neighborhood would be lumped into the
same rate category. These rates could be adjusted for factors such
as the type of car being insured on how expensive claims are for
that particular type of car in the area of interest, however this
type of rating system generally does not take into account the
areas typically driven through on a regular basis by the
driver.
[0015] Another issue with current insurance risk rating systems is
that assumptions made in the systems may not be valid. For example,
most would agree that if a person obeys the traffic laws, then that
person's driving risk would be less. This may not be the case and
the embodiments of the present invention make no such
assumptions.
[0016] There is a need in the industry to have a vehicle insurance
risk system based on one or several parameters that are spatially
referenced with respect to the transportation network the vehicles
travel on and further based on the driving habits of individual
drivers that are insured or desire insurance.
SUMMARY
[0017] In an embodiment of this invention, it is an object to
perform a rapid assessment of damage and needed repair resulting
from a vehicle accident.
[0018] The above may be performed by acquiring information about
the vehicle accident from a variety of sources and comparing that
information to the same information compiled from other previous
accidents that is housed in a database of historical accident
information. Estimates of resulting damage and repairs are then
based on the comparisons.
[0019] In some embodiments, there is a link between the system that
performs the assessments and providers of repair services and also
parts warehouses in order to determine the availability of parts
and approximate time of repair.
[0020] Other embodiments pertain to an in-vehicle accident
detection, analysis and notification system. An additional usage of
the system is for monitoring driving behavior; developing insurance
premiums based on the monitoring and also effecting change in
driver behavior than make a driver safer and less of an insurance
risk. In an embodiment, the system comprises one or more of the
following components:
[0021] 1. A vehicle on-board system comprises: [0022] i. a
processor which monitors and analyzes onboard sensors used to
detect vehicle activity and driver behavior; [0023] ii. an on-board
database comprising: [0024] 1. which stores vehicle specific
information; [0025] 2. Patterns, for the individual vehicle type,
used to analyze sensor data to detect accidents and to assess
resulting injury and damage and useful to predict driver behavior
and driver/insurance risk; [0026] 3. Driver information; [0027] 4.
Emergency contact information; [0028] iii. one or more of several
data transmission components which can include both short-range
wireless (for example Bluetooth), long-range wireless transmission
(for example mobile service) and wired-data communication
component--which can communicate with external servers to transmit
both raw sensor data and damage/injury estimation and to provide
software and database updates to the vehicle on-board system.
[0029] 2. A central server comprising: [0030] i. One or more
computers; [0031] ii. A comprehensive central database located on
one or more servers comprising: [0032] 1. historical information
from several sources; [0033] 2. raw sensor data or indices derived
from the raw sensor data from individual vehicles; [0034] 3.
Patterns for all vehicle types and areas; [0035] 4. Geographic
Information; [0036] 5. Spatial, temporal, and severity information
pertaining to accident incidents; [0037] 6. Metadata.
[0038] Vehicle onboard databases facilitates the analysis of the
type and severity and potential cost of repair/injury treatment of
the accident and also facilitates the immediate notification of the
accident occurrence and assessment to interested parties.
BRIEF DESCRIPTION OF THE FIGURES
[0039] FIG. 1 is a system overview for estimating vehicle accident
damage and cost.
[0040] FIG. 2 is a sample of how vehicle faults are indicated in
diagnostic trouble codes (DTC).
[0041] FIG. 3 is an example of a method to divide up damage
locations on a vehicle to 8 pie shaped zones.
[0042] FIG. 4 is another method to divide damage zones by
panels.
[0043] FIGS. 5A-5C are typical pages of an accident report.
[0044] FIG. 6 illustrates a vehicle on-board system for acquiring,
analyzing and transmitting on-board sensor data.
[0045] FIG. 7 illustrates the process of pattern detection in
sensor data.
[0046] FIG. 8 illustrates a method of determining insurance
risk.
[0047] FIG. 9 illustrates a method of determining models or
patterns.
[0048] FIG. 10 illustrates a method for generating a hazard
index.
[0049] FIG. 11 is a flowchart for using a system to adjust
insurance rates based on risk
[0050] FIG. 12 is a flowchart showing compilation of geo-referenced
hazard information.
DETAILED DESCRIPTION
Glossary
[0051] Accident Damage and Repair Estimate: a document or report
(either hardcopy or online) that results from analysis of
information relating to an accident, that estimates the amount and
extent of damage to a vehicle and how much work and/or money it
will take to fix it.
[0052] In-vehicle: Refers to anything that is part of the vehicle
or within or attached to the vehicle.
[0053] Sensors: measurement devices which measure parameters that
are directly or indirectly related to the amount and extent of
damage incurred during a vehicle accident or to the underlying
cause of an accident. Sensors could be in-vehicle--either part of
the vehicle or an after-market attachment to the vehicle such as a
fleet management system or as part of a mobile device within the
vehicle such as the sensors in a mobile phone--like accelerometers
or gyroscopes. Sensors may also be outside the vehicle such as
roadside traffic counters in the vicinity of the vehicle, weather
stations, and satellite or airborne based sensor such as LIDAR.
Sensors that can inform interested individuals about the condition
of pavement, weather, freeze thaw conditions or the like are
included.
[0054] Transceiver: A means to communicate between two devices
whether it be wired or wireless. Examples are two-way radios,
mobile phones, wired modems and the like.
[0055] Location: where an object is relative to a reference frame.
The location of a vehicle is some embodiments is relative to the
earth in terms of a coordinate system such as latitude and
longitude (and perhaps elevation).
[0056] Vehicle: any object capable of moving material or people
along a transportation network. This includes cars, trucks, boats,
airplanes and the like.
[0057] External Observations: See the definition of sensors above
for examples of observations that can come from outside the
vehicle. Source for this information can also be from web services,
for example weather data, or traffic information that is a feed
coming in from a FM sideband via an FM receiver.
[0058] Reference (for a database): an index or other attribute that
can be used to select database records of interest by querying
using the index or attribute. For example reference for accident
information could be: location, time, time of day, time of week;
make of vehicle, year of vehicle (or Vehicle Identification
Number), weather conditions, location of impact (zone on the car),
direction of impact, force of impact and the like.
[0059] Normalized: transforming data from a variety of sources into
the same units, in the same frame of reference.
[0060] Historical Accident Database: a database or collection of
linked databases containing information that is related to
individual accident events where all information is cross
referenced so that it can be used for statistical analysis of
accidents and the cost of repair resulting from the accident.
[0061] Cross-referenced: With respect to a database, one entry can
be queried as to its relationship to another if there is some type
of relationship between the two. For example, a certain model of
water pump produced by General Motors may have been used in a
variety of car models over a variety of model years, so the part
number for the water pump will be cross referenced to vehicle model
number, year, engine type. Also note these parameters may not be
sufficient information, because a part used may change mid-model
year. For example a wheel type my not be compatible halfway through
a model year because the lug spacing was changed for safety
reasons. In this case, the wheel would have to be referenced to the
specific Vehicle Identification Number (VIN) which could be further
cross referenced to a linked database containing more detailed
information.
[0062] Confidence Interval: One method of expressing the
probability that an outcome will be observed to happen within a
specific range for a given set of circumstances. For example the
probability that the front bumper will have to be replaced for a
collision with a force of impact perpendicular to the front bumper
and impact at speed greater than 5 mph is 95 percent for a Ford
Focus and 92 percent for a BMW 928i.
[0063] Bias: Tendency to make certain observations more than
others.
[0064] Accident Pattern: A known isolated or sequence of sensor
readings that are indicative of a vehicle accident or collision
occurring. For, example, it may be observed that in a front end
collision that the ABS brakes are always applied followed by a
rapid deceleration in the direction of travel and finally followed
by a complete stoppage of the vehicle.
[0065] Damage Pattern: Once it is established that an accident has
occurred by observation of an accident pattern occurring, sensor
output before, during and after the accident is compared to
predefined damage patterns which comprise a sequence and/or
collection of sensors readings that exhibit behavior indicative of
particular damage being caused. The level of damage, for example,
may be associated with the time interval between the application of
the ABS brakes followed by the stoppage of the vehicle.
[0066] Injury Pattern: Once it is established that an accident has
occurred by observation of an accident pattern occurring, sensor
output before, during and after the accident is compared to
predefined injury patterns which comprise a sequence and/or
collection of sensors readings that exhibit behavior indicative of
particular injury being caused to the driver and/or passengers.
[0067] Driver Pattern: A pattern established that is indicative of
driving behavior. For example, frequent fast acceleration from a
complete stop may be indicative of reckless driving; comparison of
a gps trace while driving and determining that the driver is
frequently veering over the median may be indicative of distracted
driving. Likewise obeying the speed limit and no undue acceleration
would be indicative of a good driver.
[0068] On-board: Refers to being part of the vehicle or contained
in the vehicle. An onboard sensor therefore could be a sensor that
is integral to the engine such as an oxygen sensor, for example,
and also sensor in installed aftermarket equipment or sensors in a
smartphone that resides in the vehicle. Examples of these type of
sensors would be an accelerometer or gps. Processors used to query,
record and analyze information can likewise be part of a stock
vehicle, and add-on product or a mobile device that resides in the
vehicle.
[0069] Transfer Function: If an initial database does not contain
sensor data from vehicle on-board sensors, but it is built with
information transferred from accident reports, then it is necessary
to equate how a verbal observation relates to a sensor measurement.
For example, perhaps a description of a right front quarter panel
being replaced would be assumed to be equivalent to an impact at 45
degrees from the longitudinal centerline of the vehicle with a
force of the weight of the vehicle/5 g's.
[0070] Driver Insurance Risk: The probability that an insured will
make a claim and for how much given a variety of measured factors.
It could also refer simply to the probability of being in an
accident.
[0071] Transportation Network: A system of road, streets, paths,
sidewalks, trails, waterways or other ways that a vehicle or
pedestrian travels along. A transportation network can be
subdivided by the type of vehicle or pedestrian that is intended to
be used for. For example, roads and streets may be used by cars,
trucks and busses. Trails and sidewalks may be used by pedestrians
and perhaps bicycles. Transportation networks are generally stored
in a Geographic information System that documents the location and
interaction of various components of the transportation network.
Attribution is also associated with the various components of the
network.
[0072] Transportation Element: Is a distinct component of a
transportation network that has an associated geographic
coordinate/s. Examples of elements are road segments where the road
begins and ends at an intersection; an intersection between two or
more roads; or the boundary of a lake.
[0073] Attribution: Attribution associated with a transportation
network includes any piece of information that can be related to a
spatially referenced element or component of the transportation
network. Examples are such things as speed limits, number of lanes,
connections between components, or type of vehicle that can
traverse the component. Attribution, in addition to being spatially
referenced may have a temporal (time) component expressed as, for
example, time of day, time of week, or time of year. An example of
this is the speed limit in a school zone.
[0074] Metadata: Metadata is a special kind of attribution
associated with the quality of components of transportation
network. Metadata can be associated with individual geographic
components, attribution or the source of the geography or
attribution. Metadata may be associated with precision or accuracy
of the components or source. Metadata may have a component that
list the age of the source.
[0075] Maneuver/Complex Maneuver: A maneuver is an attribute
associated with an action that can be either perform or not
performed and which is associated with one or more components of a
transportation network. For example, a no-left-turn at an
intersection is an example of a prohibited maneuver. A complex
maneuver is generally associated with more than one component of a
transportation network--for example, what is known as a Michigan
Left Turn, in which a vehicle desires to turn left at an
intersection, but in order to do this has to turn right, cross one
or more lanes, then cross a median on an avenue, then turn left, is
a complex maneuver.
[0076] Index: One or more values used to multiply or otherwise
adjust up or down a baseline value. For example if a prospective
insured base premium is $100, discounts and/or increases to the
base may be applied by multiplying the base by a crash index, a
driver age index, a safe driving index or a single index that is
based on a number of parameters.
[0077] Parameters: Any factor that may be directly or indirectly be
related to insurance risk, accident pattern, injury pattern, damage
pattern or driver pattern.
[0078] Multivariate Analysis: A class of statistical analysis used
to determine the relevance of one or more parameters in predicting
an outcome and used to build a predictive function base on one or
more of the analyzed parameters. In this case the outcome is the
prediction of insurance risk.
[0079] Accident Count: The number of accidents that occur for a
given element of the transportation network over a given time. This
may be further subdivided based on weather conditions and/or time
of day, time of week or based on other attributes that may
influence accident occurrence.
[0080] Incident: A single occurrence of a measured parameter. For
example an individual accident report is an incident of the
parameter accidents; a recorded speed of an individual driver along
a segment of road is an incident of speed of travel for that
segment.
[0081] Granularity: This term is used to refer to the specificity
of either an attribute or index. For example, if an accident count
is based simply on the transportation element it took place on, it
is less granular than if the accident count is based on the
location (element) and the time.
[0082] Insurance Risk: This term is used collectively for all
embodiments of the present invention to encompass the desired
outcome of an insurance risk model. Examples of desired output are
the probability of: having an accident, making an insurance claims,
or making an insurance claim within defined monetary limits.
[0083] Below are examples of elements of a vehicle insurance risk
database. Some or all of these elements may be used to develop a
risk model or risk indices. [0084] Standard GIS road network
including: [0085] Road Segments [0086] Geography typically stored
as a series of end nodes locations, and a series of shape points
(internal points that define the location of the segment) or as a
geometric function. [0087] Attributes Stored relative to a node or
the segment as a whole (Road segments typical have an end node at
the intersection with another road segment or a political boundary
or a geographic feature.) [0088] Intersections [0089] Geography may
be stored as either a singularity or a series of point and lines
which make up a complex intersection (such as a highway cloverleaf)
[0090] Attributes are stored that are associated with the
intersection and/or the connecting segments [0091] Maneuvers
(including complex maneuvers) [0092] Geography usually stored as a
reference to one or more geographic components that make up the
maneuver [0093] Attribution Examples (all attributes may have
multiple values base on time and may also have metadata associate
with them): [0094] For Segments: [0095] Speed limit/Actual Speed
Driven [0096] Accident Count [0097] Historical Traffic Flow/count
[0098] Historical Weather Information [0099] Number of Lanes [0100]
Vehicle Type Access [0101] Street Side Parking [0102]
Elevation/Change in Elevation [0103] Railroad crossing [0104]
Political Boundaries [0105] Parking Areas [0106] Historical Data
[0107] Crimes associated with a location (snapped to road segment
or intersection); time of data; time of year [0108] Accidents: type
of accident (solo or collision); location, direction of travel;
date, time of day; type of vehicle; weather; driver record [0109]
Previous Claims: location; type of claim (accident; vandalism;
car-jacking); amount of claim; type and age of vehicle. [0110]
Police citations: location, type [0111] Weather: ice, temperature,
wind, pressure, snow, rain, flooding [0112] Time Series of sensor
data before during and after an accident; or indicative of a driver
pattern
Overview Of Embodiments
[0113] Knowing when and where a driver drives and knowing the
historical risk associated with driving a given route at a
particular time, a formula can be derived to predict risk for
individual driver which in turn can be used to set rates. Because
the parameters related to driving/insurance risk and driving habits
of a given driver are associated with transportation system
elements in the present invention, a more refined model of risk is
possible than for insurance risk solutions in the art. Determining
premiums based on a single point or region (for example a
residential address) does not take into account where a person
drives on a regular basis.
[0114] As the correlation between one or more risk parameters and
insurance risk may vary over time and may vary regionally, it may
be needed to statistically analyze the parameters used in a model
and continually change them over time. In addition, historical
parameters used may lose relevance with time and will need to be
retired or withdrawn from the determination of risk relying on more
recent data.
[0115] Real time information (while the insured is driving) may be
much more relevant to risk. For example, if the road is icy, the
likelihood of making a claim is potentially higher, than if the
only information available is that is likely to be icy at the
timeframe when driving.
[0116] With a dynamic rating system that is continually updated and
also has a real-time component, it is further possible to compel
drivers to adjust driving habits based on the real-time information
to reduce the risk. For example, if a particular route is known to
be icy, and the course the driver is taking is being monitored, and
the monitoring system further suggest an alternate non-icy route,
then the driver can be rewarded for avoiding risky conditions by a
reduced premium, or by monthly rebate checks or similar.
[0117] Real-time information can come from a variety of sources
such as wireless acquired weather information and traffic reports.
This information can further be statistically aggregated to produce
historical weather/traffic risk information likelihood indices that
are spatially and temporally indexed. Metadata associated with the
historical information can then be used to cull older information
and continually update the indices with the latest information.
Also continuous, real time, accumulation of accident reports with
root causes can be helpful to asses and distribute that risk across
the total driving space of some geographic region.
[0118] If is further possible to assist a driver by providing a
display of driving risk. The driving risk, for example, could be
displayed much like traffic information on a map with high risk
being displayed on routed segments in a red color and using other
colors for route segments of lesser risk.
[0119] In embodiments of the present invention, one of the goals is
to predict the amount of damage that is incurred during an accident
and how much it will cost to repair. Damage incurred is a function,
for example, of what kind of car was being driven, the age and
condition of the car, the location, direction and force of
collision impact on the vehicle during the accident. The cost of
repair, for example, is a function of the locale of the accident
(regional variation in parts costs and labor costs), the parts that
need to be replaced given the specific class of accident, the
materials needed, for example paint and sandpaper, and the amount
of labor required to perform the repairs.
[0120] Since no two accidents will be the same, the accidents must
be classified or grouped together, so that information based on
observed parameters recorded during historical accidents can be
used to predict and assess damage that happens in accidents
occurring now.
[0121] It is further object of this invention to locate and reserve
parts that may need to be replaced--immediately after an
accident.
[0122] Another object of the invention is to schedule time for
repairs with qualified technicians--immediately after the
accident.
[0123] It is an object of the invention to continually update the
database of records for previous accidents with information that
can be better utilized to predict future assessments of accident
damage.
[0124] It is an object of the present invention to determine blame
or apportion the blame in a two vehicle accident.
[0125] It is an object of the present invention to estimate when
the cost of repairs would exceed the worth of the vehicle.
System Designs
[0126] Systems designed to predict damage and necessary repair
resulting from vehicle accidents can come in a variety of
configurations. However basic components and/or functionality are
common to most as shown in FIG. 1. Primary components are: [0127]
In-vehicle data collection module 102 [0128] Database of historical
accident information 104 [0129] Accident review module 110
[0130] When initially constructing the database 104, multiple
sources of information 106 are used which include accident reports
from police or insurance adjusters, repair invoices, parts lists,
and the like. In addition, sensor data that was recorded (if
available) during accident events is also stored in the database
104. The database 104 may contain the raw data, the predictive
functions, and metadata (for example, error estimates on the
validity of the data). The database 104 also contains derivative
products of the sensor data such as categorized or normalized
versions of the input data and/or functions for which to categorize
or normalize each type of input. Once an initial database is
configured and populated, statistical predictors are formulated
based on the historic information in order to predict damage and
cost in future accidents. In operation, an in-vehicle data
collection model 102 comprises a sensor interface capable of
receiving and storing data from sensors within the vehicle or part
of the vehicle. The data collection module can communicate with an
accident review module 110 which can either be located in the
vehicle or remote to the vehicle. Communication can be either by
wired or wireless methods. In addition the accident review module
110 can acquire information from external sensors networks such as
weather feeds and traffic. Note this function could alternatively
take place in the in-vehicle data collection module 102. The
accident review module 110 receives all the pertinent information
concerning an accident, categorizes the information; inputs the
information into a predictive function, then predicts the damage
incurred during the accident and the anticipated cost. At least one
of the raw data and derivatives of the data, such as normalized
data, categories data, and error estimates are then transmitted to
the database 104 to be used in updating the predictive function.
Later information from repair facilities are also input into the
database and are used to validate the prediction and improve the
prediction going forward (not shown).
Communication Protocols
[0131] Referring to the schematic of a system FIG. 1, the
information that is either stored or generated in the various
components needs to be communicated to other modules of the system.
Sensors need to communicate with data collection module 102. If the
sensors are part of the car (air bag sensors, integrated GPS--for
example) then communication would typically happened using the
car's system bus which could be either conventionally wired or
based on fiber optics provided the data collection module 102 was
integral to the car electronics. If the data collection module 102
was an add-on product or consists of software running on a mobile
device within the car, then communication with the integral vehicle
sensor may be by using an interface that can read on-board
diagnostic (OBD II) codes by interfacing with a car portal designed
for external communications.
[0132] Another type of code that is somewhat standardized for
automotive diagnostics is the diagnostic trouble codes (DTC). FIG.
2 describes how a typical DTC is structured.
[0133] Many vehicles have Bluetooth or similar short range wireless
protocol communication modules and can transmit information such as
DTC codes to nearby devices.
[0134] If the vehicle data collection module has software running
on a general purpose computing device such as a mobile phone, the
phone or other device could be plugged into the vehicle using a
wired means such as a Universal Serial Bus (USB) or short range
wireless such as Bluetooth.
[0135] Sensor that are part of the mobile device can also be
considered in-vehicle sensors provided the device is in or attached
to the vehicle. These type of sensors can include gyroscopes,
accelerometers, altimeters and GPS, for example. Communication with
these sensors would be over the data bus of the portable
device.
[0136] External data coming from services or external sensors can
be communicated through an internet connection, FM sidebands (such
as traffic messaging channel information TMC).
Database Design and Input Normalization
[0137] In embodiments of this invention, vehicle damage from an
accident is predicted by comparing the observed conditions that
occur during an accident with similar observed conditions for
similarly classed accidents stored in a historical vehicle accident
database and the damage resulting from those accidents. Algorithms
are developed to classify each type of accident as succinctly as
possible, given the available data, such that when the conditions
of a present accident match a classification, this can be used with
a degree of certainty, to predict resulting damage and the parts
and services necessary to effect repairs.
[0138] In an embodiment, the observed conditions of interest during
an accident include: [0139] Specific type of vehicle, including
make, year, model, weight and options [0140] Condition of the
vehicle (prior damage, corrosion, state of repair) [0141] Location
of collision impact, force and direction [0142] Locale of the
accident (for determination of regional variable costs) [0143]
Environmental factors (weather, road conditions)
[0144] Raw data that may be used to predict accident damage and
repair needed can come from a plurality of sources. Sources
include: [0145] In-vehicle Sensors [0146] Accelerometer to measure
force of impact and direction of impact and any motion that occurs
after the accident such as rollover of the vehicle [0147] Gyroscope
to measure direction of travel when a GPS is unavailable [0148] GPS
for speed and direction of travel [0149] Air bag deployment and
seatbelt sensors [0150] ABS brake sensors [0151] External Sensors
[0152] Weather from web services [0153] Traffic information from
web services or FM sideband (Traffic Messaging Channel) [0154] Road
Condition Information from web-sources such as highway departments
[0155] Other means of collecting information [0156] Police Reports
(subsequently manually entered into the system database by manual
entry using a computer interface application [0157] Insurance
adjuster reports [0158] Via the driver or passenger or observer of
the accident input from a mobile device running an interface or app
that allows the input and connects to the system. [0159] Accident
scene photographs depicting the damage which are analyzed either
manually or using image analysis techniques
[0160] Note that the historical accident "database" may be
distributed, so that, for example, the predictive function may be
in the vehicle and the historical raw data may be on a central
server.
[0161] When initially building a historical vehicle accident
database, it is likely that there will be a mix of more qualitative
data, for example from manually entered police and insurance
adjuster accident reports and quantitative data, for example, from
in-vehicle sensors. As such there is a subjective element in the
reporting and the likelihood of human error will reduce the quality
of the manually entered data and therefore if the manually entered
data makes up the bulk of the available information, the error in
prediction of collision damage will be greater.
[0162] In addition, since much of qualitative information would
have initially have been manually entered on a piece of paper,
there will also be transcription errors regardless of whether the
information is manually input into the database by a human or if
the information is machine input using optical character
recognition and algorithmic processing of the text.
[0163] Available information to input into the database will change
with time. As more information of a quantitative nature or more
precise, accurate and with less bias information becomes available,
older more qualitative data will be replaced and the resulting
predictive model or associated statistics will be updated to
reflect the new data.
[0164] There are at least two methods to deal with disparate data
(differing quality and precision) that can be used to model an
event: 1) You can make the initial predictive model imprecise, for
example, using quadrants, sextants, or octants or other slice of
the vehicle to identify the location of impact and you could
identify the force of impact quantitatively using low, moderate and
extreme impact (or similar rating system); and 2) you could
structure the database to support a more precise model, but
indicate that initial predictions will have low accuracy.
[0165] FIG. 3 is an example of an imprecise method to represent
where damage has occurred on a vehicle 302. A vehicle 302 is
divided into a number of slices 304. Damage would be categorized by
the number of a slice 304 it occurred in.
[0166] FIG. 4 is an example of a more precise model for
classification of direction and location of impact on a vehicle
402. Differing components of the vehicle are identified and damage
is associated with the component, for example, hood 404, left
fender 414, left front door 408, left rear fender 410, trunk 412,
and roof 406.
[0167] For information from disparate sources to be compared, the
information must be normalized, i.e. converted to the same units of
measure and be relative to the same reference frame. In addition,
the quality and precision of the data must also be evaluated and
represented within the database in a normalized fashion. In other
words, if for example, one speed is known to be accurate within
+/-10 mph, then all speeds in the database should have an error of
estimate in mph (as opposed to kph for example).
[0168] A probability that a particular level of damage or type of
damage will occur if a series of measured parameters fall within a
specified ranges is calculated. No two accidents are alike, so any
prediction will not be 100 percent accurate and it is best to
either provide an error of estimate associated with each estimate
and/or provide an upper and lower range of probable damage and
costs.
[0169] If an initial build of a database is created from mostly
quantitative data, then it may not be possible to predict specific
damage and may only be possible to predict cost of repair, and with
a large degree of uncertainty.
[0170] If the input data is a mix of in-vehicle sensor data, and
manually input qualitative data then, using statistical techniques
know in the art, the predictive function can be generated weighting
the sensor data more heavily than the qualitative data.
[0171] With respect to force of impact, in-vehicle sensor
measurements can be used to accurately calculate, using methods
known in the art, the force and direction of impact, if the
velocity or acceleration and mass of the vehicle or vehicles
involved in the collision is known during the period of time
encompassing the accident.
[0172] Direction and area of impact (on the vehicle) is very
important. For example, if a vehicle if backing up at slow speed
and the driver does not notice a telephone pole, if the impact on
the rear bumper is more towards the middle and the direction of
impact is more perpendicular to the bumper, as opposed to impact
near the corner of the bumper at an angle less than perpendicular,
this could mean the difference in no damage to the bumper, as
opposed to having to replace the bumper--given the same speed of
impact.
[0173] Likewise, the direction of impact given the same speed of
impact, may cause a greater number of airbags being deployed making
the difference between the vehicle being totaled and the vehicle
being salvageable.
Reduction of Information from an Accident Report
[0174] FIGS. 5A-5C are an example of a typical accident report
(this particular one is from the Massachusetts Department of
Transportation) and it contains several parameters that can be used
to provide input for a historical vehicle accident database.
[0175] Since no two accident reports would be the same, the raw
data from many type of accident reports could be entered into a
database, then normalized to be used in the predictive model.
[0176] The process could be as follows: [0177] Create a section of
the accident database to house the data from each particular form
[0178] If the form is in paper form, scan in the pages of the
report: [0179] Optically recognize the characters and use search
techniques to find headings of interest--for example FIG. 5A 504
Vehicle Registration # and further down the line Vehicle Year and
Vehicle Make. [0180] Find the value associated with each heading
and enter it into the database [0181] Manually enter other data,
for example in FIG. 5A 506, it may be necessary to interpret the
vehicle damage (signified by circling a code for the appropriate
damage zone) manually. [0182] If the form is tag based (for example
XML) or in other machine readable form: [0183] Enter the
information into the database directly [0184] Obtain information
regarding the repairs that were performed to fix each particular
accident or alternatively determine if the vehicle was totaled and
the rationale for this determination. [0185] Find statistical
relationships between the damage assessment from the accident
reports and the repairs made. [0186] Determine a common schema for
the predictive database that all the various report structures can
be normalized to (see below) and transpose all the data from
differing reporting structures to a single format (or at least
store functions to normalize all the information).
[0187] Values to be input into a database associated with collision
impact can be approximated by the quantitative information provided
in FIGS. 5A-5C. For example, in FIG. 5A, under the section
"Sequence of Events" 502, you could determine whether an accident
was a single car or multiple car accident. You could determine if
there was more than one event. You could determine whether the
object that was collided with, was rigid and unyielding or giveway
during an accident. The force of impact could be assigned a value
based on various events: for example, a collision with a utility
pole (as indicated on the form--FIG. 5A 502 under heading 23) at a
particular speed would generate a greater force of impact than a
collision with a bicycle (as indicated on the form--FIG. 5A 502
under heading 4) given the same vehicle. A vehicle with more mass
would have a greater force of impact than a lighter vehicle (mass
could be determined by information in Section B of the accident
form (FIG. 5A 502). Further in FIG. 5C 520--the crash diagram, the
relative direction one or both vehicle were traveling could also be
factored into the force calculation, however, it would most likely
be necessary to limit the zones of impact based on the panel of the
car impacted (door, fender, hood, etc) or on a quadrant or sextant,
or octant for example as show in FIG. 5A 506.
[0188] As in FIG. 5A 502, there could be multiple events in
sequence. For example, a glancing impact by one car with another
could cause one of the cars to roll over. In which case you would
have multiple impact locations. To quantify this, the database
could be designed, similar to the accident form, to have multiple
events, or the database could integrate the force of impact for the
multiple events.
[0189] It should be noted in some embodiments, that more detailed
information and information that does not have to be normalized or
transposed is preferable. Also information that can be
automatically acquired and processed, rather than manually entered
is also preferable.
[0190] In an embodiment, as more sensor data that can be correlated
to accident damage becomes available and is entered into the
database, then manually entered and transposed data should be
removed from the database and relationships should be
re-calculated.
[0191] There will be bias associated with certain measurement
types. An example would be transcription of the location of impact
from a drawing on a police report (FIG. 5C 520), you would most
likely visually estimate the direction of impact, and would
furthermore probably enter an even value to the nearest 20 or 30
degrees. Therefore you would have a bias for measurements at even
angles at fixed intervals.
[0192] More information on how to build the historical accident
database and maintaining it for the purpose of categorizing
accidents for damage assessment is covered in the related
application PCT/IB2014/001656 which is incorporated herein by
reference.
Post-Accident Repair Information
[0193] In the historical vehicle accident database, there must also
exist post-accident information associated with each accident. This
information may include: [0194] A listing of parts replaced [0195]
Body work done [0196] Price of labor (preferably broken out by part
installed or service performed) [0197] Price of parts [0198] Time
between accident and completed repair
[0199] This information must be associated with the accident report
information and/or sensors information so that correlations can be
made. Insurance companies are a likely source of information for
both that accident report and the repair information.
Development of the Predictive Model
[0200] Armed with the populated historical vehicle accident
database, a predictive function can be developed. As a starting
point, it can be assumed that damage is a function of the specific
vehicle, and the force of impact (including direction and location
of impact on the vehicle). Using this assumption, for a given
accident, a query can be run on the database to find all accidents
that have: [0201] A force of impact: [0202] Approximately the same
as the force of the present accident [0203] In a similar direction
and location of impact [0204] The same or similar vehicle
[0205] Based on the query, a list of database entries should be
returned that provide: [0206] Parts that have been replaced and
costs [0207] Services that were performed and associated costs
[0208] Statistics can then be run on the returned entries: for
example, the probability that a particular part was replaced; the
range of costs to purchase and replace that part and so-on.
[0209] It should be noted if the vehicle accident database spans
large geographic areas and large periods of time, then statistics
would need to be adjusted (normalized) for things like present
value of money and regional costs differentials.
[0210] Depending on how much information is in the database, a
query could be very specific, for example, the vehicle model could
be simply a Mustang, or the vehicle type could be a Mustang XL. The
XL designation could correspond to a different trim package, for
example, the XL may have magnesium wheels instead of steel. If the
database is refined enough to have enough Mustang XL entries, then
there may be a high probably, for example, that in a one car
collision traveling at 35 mph where the impact with a stationary
object occurred on the left front quarter panel, that left front
magnesium wheel will have to be replaced. Alternatively if there is
insufficient information about the Mustang XL in the database, then
the query could be for all Mustangs. The returned information could
be that it is likely that the left front wheel would have to be
replaced, but the database does not distinguish costs for steel vs.
magnesium wheels in this instance.
[0211] As the amount of information in the database continues to
grow and be refined, the relationships for how to predict damage
may change depending what factors correlate the strongest. It may
be found for example, that all variations of the same vehicle
develop similar damage during accidents or it may be found that
there is significant differences in the amount and extent of damage
if the same vehicle has a different engine type.
[0212] There will be regional variations for cost associated with
repairs. Labor charges may be different for autobody technicians
depending on location and also parts availability may vary from
place to place. This factors also need to be accounted for in the
database.
[0213] The database of information needs to contain a statistically
significant amount of records that can be related to damage and
repair. In other words, a quality standard need to be set, for
example, a standard could be that cost estimates must be valid
within plus or minus $500. Therefore there must be enough previous
accident and cost of repair data to be able to statistically
validate the quality standard for each category.
Determination of Damage from Sensor Data
[0214] In an embodiment, on-board sensors are monitored and the
output recorded in volatile memory which is continually overwritten
at intervals until some triggering event happens that is indicative
of an accident. This could be for example, an air bag deployment or
and acceleration value exceeding a threshold. Once the trigger
occurs, then the stored data is no longer overwritten, but saved,
such that there is information proceeding the accident and the
sensor output continues to be recorded until such time as an ending
event (such as the vehicle coming to rest) is observed in the
sensor output.
[0215] Next, depending on the system configuration, the data is
either analyzed within the vehicle to produce derivative output or
the raw data itself is transmitted to an accident review module for
performing analysis.
[0216] Derivative output could for example, be a parameter such as
the impact force and direction as derived from 3 component
accelerometer data. The force and direction could be further
categorized into, for example: and impact zone and an impact force
level and the direction of impact.
[0217] What is transmitted to an accident review module depends on
how the prediction model is structured. If the model requires raw
sensor data as input, then that is what is transmitted. Likewise,
if the model requires further categorized data, then that is
transmitted. In some embodiments, both raw data and derivative
parameters of the raw data are transmitted, even if the raw data is
not used in the predictive model. The transmitted raw data can then
become part of the raw data in the database, so the predictive
model can be updated by including the new raw data in the
analysis.
[0218] The accident review module provided with the input data from
the accident, then plugs in the information into the predictive
model and returns a prediction.
[0219] The prediction will include some or all of the following:
[0220] A listing of parts that most likely need to be replaced (and
optionally probabilities that a part will need to be replaced)
[0221] A listing of costs associated with each part (for the region
of the accident) [0222] Materials such as paint and supplies [0223]
The overall cost estimate (may include an upper and lower
limit)
[0224] In embodiments, additional information is in the database or
in a second linked database. This additional information includes
an inventory of new and/or used parts and their location. In
addition it may include the workload or backlog of various repair
technicians and their availability to perform the predicted repairs
that need to be done. Additional functionality of the accident
review module in embodiments can do one or more of determining the
availability of parts, materials and labor and/or request bids for
each from providers that have the part/s, materials or time. The
review module, in some embodiments will schedule delivery of the
parts and repair labor based on the availability.
[0225] Once the damaged vehicle arrives at a shop for repairs, or
alternatively if an insurance examiner makes an assessment, the
evaluation of the actual repairs and the anticipated labor costs
can be compared to the estimates made by the accident repair
module. This manual evaluation can also be incorporated into the
database to update the model.
[0226] In certain instances, for example, the magnitude of impact
(or some other parameter) may exceed a statistically determined
threshold value, and this would indicated that the vehicle should
be totaled (not worth repairing). In these instances, the insurance
company may decide to not even send an adjustor to review the case
and expedite payment to the insurer.
[0227] In other instance, the magnitude of the impact may be such
that the probability is that damage will be minor. In these
instances, it may be prudent to not send an adjustor but rather
settle for some cost that is slightly higher than the norm based on
the historical database and avoid the cost of the adjustor
visit.
Fault Determination in a Two Car Accident
[0228] In most states, in the United States at least, determination
of liability in vehicle collisions is based on who caused of the
accident. In some situations this fault may be jointly assigned,
but not necessarily equally. For example, a driver may have been
distracted and veered over the middle line into on-coming traffic,
but an oncoming driver may have had ample time to move out of the
way, but did not for some reason. In embodiments where in-vehicle
sensors are used for accident assessment, these same sensor outputs
can be used to infer blame (or exonerate a driver of blame). For
example, the combination of GPS and accelerometer readings could
indicate a sudden veering out of a lane and into incoming traffic.
Another example may be that based on DOT information, the roads
were icy at the time of an accident, but based on GPS data, the
driver was exceeding a safe speed limit. These are just two
examples of information that could be used to assign blame and at
least contribute to the assignment of blame.
System Utilization
[0229] In an embodiment of the system and method, the prediction of
damage and the estimated cost of repair is transmitted to the
accident site shortly after the accident occurs. The transmission
can occur to either the in-vehicle system or to a mobile device
carried by an insurance adjuster or emergency response personnel.
By having on-site information about the anticipated cost of repair,
this can facilitate rapid settlement of insurance claims and
expedite repair. Analysis of fault of the accident can facilitate
whether or not a traffic citation needs to be issued by police at
the scene.
[0230] If the analysis is transmitted to the car, results can be
displayed either graphically and/or in text on a screen in the
vehicle--for example, an infotainment system screen.
Implementations
[0231] The present invention may be conveniently implemented using
one or more conventional general purpose or specialized digital
computers or microprocessors programmed according to the teachings
of the present disclosure, or a portable device (e.g., a
smartphone, tablet computer, computer or other device), equipped
with a data collection and assessment environment, including one or
more data collection devices (e.g., accelerometers, GPS) or where
the portable device are connected to the data collection devices
that are remote to the portable device, that are connected via
wired or wireless means. Appropriate software coding can readily be
prepared by skilled programmers based on the teachings of the
present disclosure, as will be apparent to those skilled in the
software art.
[0232] In some embodiments, the present invention includes a
computer program product which is a non-transitory storage medium
(media) having instructions stored thereon/in which can be used to
program a computer to perform any of the processes of the present
invention. The storage medium can include, but is not limited to,
any type of disk including floppy disks, optical discs, DVD,
CD-ROMs, microdrive, and magneto-optical disks, ROMs, RAMs, EPROMs,
EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical
cards, nanosystems (including molecular memory ICs), or any type of
media or device suitable for storing instructions and/or data.
Alternative Embodiments Shown in FIGS. 6-12
Central Service/Server/Database
[0233] One or more servers provide the functions in the form of web
services or similar of: [0234] Communications will vehicle equipped
with on-board measurement and analysis systems [0235] Linking a
central data base/s with vehicle on-board databases containing
information used in the system [0236] Analysis of data/creation of
patterns for accident detection, injury and damage assessment,
driver behavior and insurance risk
Database Maintenance/Updating
[0236] [0237] Cross correlation of information from disparate
sources [0238] Repository for all related information
[0239] The central service/server or servers are in periodic
communication with the vehicle on-board systems. The database
repository needs to contain all pertinent information and raw data
to relate sensor data (or data quantified from text based accident
reports) and other pertinent measures for detection of accidents
and damage and injury assessments in addition to driver behaviour
and estimation of insurance risk. It also can contain information
to expedite repair of accident damage and to facilitate treatment
of passenger injury. The central database may be hosted in a single
facility or server or may be hosted in several facilities that are
connected via hyper-links and indices. For example data on
insurance pay-outs may be in an insurance company database and
details of related accidents may be in an accidents report database
(at the police station) and the two are linked by the Vehicle
Identification Number (VIN) of the automobile and the date of the
accident.
Database Content
[0240] Both the vehicle on-board database and the central database
comprise one of more of the data below. The on-board database may
be vehicle specific and may only contain pertinent information to
the vehicle in question. The following list comprises information
that may be stored: [0241] Collections of sensor data acquired
during accident events along with a unique ID for each event [0242]
Weather, traffic and road conditions data for each accident event
[0243] Insurance company profiles and communication protocols
[0244] Vehicle specific information including parts and options
[0245] Associated parts and services required for specific types of
accident damage and injuries that may be incurred [0246] Accident
Patterns specific to the vehicle (relationship between sensor
output and accident detection) [0247] Damage Patterns specific to
the vehicle (relationship between sensors output and type and
severity of damage and parts that may need to be replaced) [0248]
Injury Patterns specific to the vehicle (relationship between
sensors output and type and severity of damage and emergency
services and treatments that may be required.) [0249] Driver
Behavior Patterns generic to a group of drivers and indicative of
good and bad driver [0250] Characteristics [0251] Repair facility
information relative to both the vehicle type and insurance carrier
[0252] Towing services relative to both the vehicle type and the
insurance carrier [0253] Contact information for: [0254] Insurance
Adjuster [0255] Local Emergency Dispatch [0256] Part Carriers
[0257] Auto Body and Auto Repair Providers [0258] Cross correlation
information of parts for each vehicle with the same parts in other
vehicles [0259] Geographic parts availability [0260] Location of
medical treatment facilities and their capabilities [0261] Digital
Map of the area or areas of interest for georeferencing accident
events and relationship to driving risk
On-Board Vehicle System
[0262] FIG. 6 illustrates an embodiment of the components on-board
a vehicle utilized to acquire sensor data, analyze that sensor data
indicative of vehicle action and driver behavior. The system can be
provided all or in part as a portable device (e.g., a smartphone, a
tablet computer, computer, or other portable device).
[0263] The overall system comprises vehicle on-board systems for
many vehicles and one or more central processor/s and data
repository/s.
[0264] A vehicle on-board system FIG. 6 comprises several
functionalities that can be implemented as individual components
that communicate with one another via wireless or wired connections
or a single or few components with modules implemented in software
or firmware. The components can be permanently installed in a
vehicle or be a mobile device that can be used in more than one
vehicle or a combination of components that are both permanently
installed and removable. Likewise sensors can be integral to the
vehicle or added on or part of another device that resides in the
vehicle or any combination.
[0265] In an embodiment some or all of the following functions
occur in the vehicle on-board system: [0266] Continuously
monitoring of sensors occurring a data acquisition module 604
[0267] Acquiring external information via wireless communication
from external services 610 off-vehicle [0268] In a pattern
recognition module 606, matching sensor output or derivatives of
sensor output [0269] To patterns that are indicative of an accident
event that has occurred and/or patterns that can be used to predict
resulting damage and/or injury associated with an accident events
[0270] Matching sensor output or derivatives of sensor output to
patterns that are indicative of driver behavior [0271] Store sensor
data and analysis for defined time periods in an onboard database
612. [0272] Store damage/injury assessment and/or raw sensor data
pertaining to the accident in an onboard database 612 [0273] If
wireless communication is available using an external communication
module 614 after an accident event, submit preconfigured
damage/injury assessment reports; send out prefigured requests for
services and supplies based on the assessed damage/injury [0274]
After an accident, send out or make available a listing of patterns
that were observed based on the sensor data and/or the raw sensor
data recorded during the event to a central database repository
[0275] Make damage/injury analysis available for on-scene
participants via short range wireless or wired connection [0276]
Optionally display the results of the accident analysis on an
infotainment screen within the vehicle or on a screen of a mobile
device (not shown in FIG. 6)
[0277] As shown in FIG. 6, the vehicle on-board hardware and/or
software implementation components to achieve the above tasks are:
[0278] On-board Sensors 602 (Data Collection Devices) [0279] A data
acquisition module 604 [0280] Pattern recognition module 606 for
accident detection and damage/injury assessment [0281] On-board
Database 612 containing: [0282] Sensor data 608 [0283] Patterns
(not shown) [0284] Communication module 614 used between on-board
systems and components and/or external server's and services
[0285] The on-board sensors 602 comprise one or more of: [0286] GPS
[0287] Air bag deployment indicator [0288] Accelerometers [0289]
Gyroscope [0290] Seatbelt fastened indicator [0291] Number of
passengers (sensors in seats) [0292] Ambient Temperature [0293]
Tire pressure [0294] Engine Oxygen Sensors [0295] Engine
Temperature [0296] RPMs [0297] Vehicle Speed [0298] Exterior
Temperature [0299] Humidity [0300] Dew Point [0301] Video
Cameras
[0302] External Services 610 that are monitored comprise one or
more of: [0303] Weather [0304] Road Conditions [0305] Traffic
[0306] A pattern recognition module 606 is configured with one or
more defined operating patterns, each of which operating patterns
reflects either a known change in vehicle status, or a known
vehicle operating or driving behavior. For example, a vehicle
responds in a physically-measurable manner to driver-based driving
actions, e.g., by the driver turning the vehicle sharply at a
corner. An accelerometer can be similarly used to register the
sudden deceleration or impact of a collision, and its direction.
This enables the system to associate patterns with certain vehicle
status or operations, or with historical records for a particular
vehicle or for similar vehicles.
Vehicle On-Board Database
[0307] Individual vehicle on-board databases 612 may be a subset of
the central database having specific information for a make, model
or class of vehicle. In an embodiment, information is also specific
to the geographic area the vehicle is in. In an embodiment, to
create a vehicle on-board database, a query, based on the Vehicle
Identification Number (VIN) of the vehicle, is made to the central
database that allows selection of only pertinent data. In an
embodiment, the list of equipment that is part of a vehicle can be
modified to account for aftermarket replacement parts (for example
a new sound system). Depending on communications system that is
implemented within the vehicle and the bandwidth available,
location specific information can be periodically updated based on
the actual location of the vehicle (based on GPS or other location
measurements while the vehicle is moving) or based on a route plan
in a navigation system.
[0308] As part of the vehicle on-board database for a given
vehicle, relationships referred to as accident patterns and damage
and injury and driver behavior patterns are stored. These patterns
relate sequences of sensors reading or calculations based on sensor
readings and information about the vehicle to accident detection.
Damage patterns relate sensors reading and vehicle specific
information to a damage assessment. Injury patterns relate sensors
reading and vehicle specific information to assessment of driver
and passenger injury. Driver patterns relate to driver safe
operation of a vehicle.
[0309] In embodiments, there is a listing of parts associated with
types and location of impacts. There is a cross correlation of
parts number associated the vehicle in question and other vehicles
that use the same part. For example the front fender of a 1993 Ford
Taurus is the same for 1994 Mercury Sable but may have a different
part number.
[0310] There can be a listing of type of injuries associated with
type and location of impacts and where passengers are sitting and
additional information such as if the passenger is in a baby
seat.
[0311] All vehicles are different: they have different options,
they are exposed to different road conditions, and weather, they
are used for different purposes, they are maintained differently
and they are driven more or less frequently and have different
drivers and most importantly, they have different weights. All of
these factors can contribute to how much an insurance claim will be
for any accident and also how quickly the vehicle can be repaired
or an injury treated. In addition any of these pieces of
information can also give clues to whether a resulting claim is
wholly or partly fraudulent. For example, for a front end collision
of a new vehicle, it should not be necessary to repaint the trunk,
because the paint is not faded, and it would be easy to match the
existing paint. If a car has a side impact airbag, and the car is
impacted on the side, then injuries will potentially be far less
than if the airbag was not available. However the damage estimate
will be far greater due to the airbag deployment.
[0312] Addition information that may be recorded on-board a vehicle
and included with an accident report and/or added to the on-board
vehicle database could be the following car history items: [0313]
Number of vehicle trips and where for a given time interval [0314]
Number of accidents reported in last day/week/month/year [0315]
Number of risky driving events reported in last day/week/month/year
[0316] Number of speeding events reported in last
day/week/month/year
Building the Initial Central Database
[0317] Patterns must be established that enable: the detection of
an accident occurrence from onboard sensor data; assessment of the
type and severity of damage/injury in a vehicle accident; and for
driving behavior. In addition the data is used to relate areas and
times to the hazard of driving a given road segment. The central
database, in an embodiment, is initially created from historic
records concerning accidents such as police accident reports and
insurance adjuster on-site reports. These type of reports typically
would not have on-board sensor data associated with an accident,
but rather would have a written description of damage and the
location of damage. As the patterns for detection of an accident
event, for damage assessment and for injury assessment are designed
to be relative to sensor data and no sensor data may be initially
available, then a transfer function or correlation between the
verbal description in accident reports and anticipated sensor
response needs to be made.
[0318] An accident report may document that there was an impact to
a right front fender when another vehicle collided with the subject
vehicle. It might further be documented that the subject vehicle
was stationary and the colliding vehicle was moving at 20 kph (12
mph). If the right front fender was damaged, but not the front
bumper, an angle of impact of 45 degrees from the long axis of the
vehicle might be inferred. The angle of impact could also be
inferred from images of the damage that are taken at the accident
scene.
[0319] As sensors measure physical parameters, then verbal
descriptions and inferences from accident reports must be
translated into a physical units to derive the accident, damage and
injury patterns based initially on accident reports, but later to
be based on sensor output. For example, given the relative speed of
impact (velocity of impacting vehicle and the velocity of the
impacted vehicle--for head on collision), and the weight of each
vehicle, force of impact can be calculated. Given the force and
direction of impact, then the maximum acceleration on impact (that
would be detected by an accelerometer on a vehicle) could be
approximately calculated. If the accident reports are standardized,
then descriptions of accident specifics could be read
electronically (if the report is in digital format) or by searching
for keywords (if paper reports are optically character
recognized).
[0320] Information about repairs made or injuries treated, most
likely come from reports other than the police accident
report--usually from the insurance carrier or directly from repair
services and medical services.
[0321] Alternatively, an initial accident detection pattern could
simply be the observation that an airbag has deployed.
[0322] Information amassed from historical records that are
desirable to input into the central database are: [0323] Impact
zone (where impact occurs on the vehicle) [0324] Impact magnitude
and direction (usually inferred from accelerometer readings)
Location (geographic) [0325] Vehicle Type and age (and from the
Vehicle Identification Number (VIN), what options did the car come
with) [0326] Any custom modification to the vehicle (mag wheels,
aftermarket sound/entertainment system) [0327] The availability of
parts within the vicinity of the accident [0328] Who, where and how
quickly was the auto fixed [0329] Listing of OEM or other parts
used for the fix. [0330] Speed, direction of travel [0331] Single
car collision, multiple car collision; relative speed, speed of the
other vehicle [0332] Brakes on? ABS engaged; airbags deployed
[0333] Pictures and/or video of the accident [0334] Surveillance
camera footage [0335] Insurance pay-out. [0336] Emergency Responder
and onsite treatment received [0337] Transport to what hospital
facilities [0338] Number of passengers, where they were sitting and
extent of injuries [0339] Erratic driving behavior prior to the
accident for the driver
[0340] To build the initial database, some or all of the following
need to be performed: [0341] Identify historic sources of accident
information such as police reports, insurance adjuster reports,
repair bills, parts require, vehicle specifics preferably in some
type of digital form such as JSON or XML [0342] Design a database
and standardize units and numerical ranges between datasets; map
and enter into a database and cross correlate the information to
particular vehicle specifications [0343] Create a means to
document, quantify, and locate damage to a vehicle (for example
create zones on the vehicle and identify any impact damage that
falls within a zone [0344] Design and Create metadata for entries
into the database [0345] Identify relationship between damage and
cost to fix the damage, to indicators of the extent of damage from
the historical data base/s [0346] Map historical information to a
map database of the transportation network
[0347] It should be noted that the database could be a collection
of remote databases that are linked and indexed together. So
information about vehicle specifics could be in one database in
Detroit, while accident event information could be in one of
several other databases in other locations.
Sensor Data Collection, Pattern Detection and Accident
Remediation
[0348] New data is collected from vehicle on-board sensors and from
external feeds continually, in an embodiment. At given time
intervals the data for the last time period is stored and the older
data is thrown out. Alternatively the data is stored in a memory
stack of a set size where new data is added to top of the stack and
the oldest data (at the bottom of the stack) is thrown out. At
intervals which could correspond to the sample interval or
multiples of the sampling rate, an accident patterns is looked for.
If an accident patterns is detected, indicating an accident has
occurred during the time interval, then the sampling rate may be
increased to acquire more data per time period, and/or other sensor
data, previously not being recorded, may be recorded.
[0349] The end of the accident event, in an embodiment, is defined
when the vehicle is stationary. Once the accident is over, the
stored data is analyzed to detect damage and injury patterns.
Analysis is performed and if accident and/or injury patterns are
detected, then the location and estimated damage and injury
associated with these patterns is recorded.
[0350] If the severity of injury anticipated by the analysis is
sufficient, then an ambulance and/or paramedic is contacted
(provided communication is available). If a tow is needed, then a
tow vehicle is called, provided the local information for such
services is available. An insurance adjuster is contacted. Parts
and repair services are queried to check availability. Depending on
the configuration, information about the accident is displayed on
an infotainment screen in the vehicle or on an authorized portable
device.
[0351] The raw data and/or the sensor analysis is transferred to a
server via the communication network (wireless, or otherwise) for
inclusion into the central database and for future determination of
accident, damage and injury patterns.
[0352] FIG. 7 illustrates and embodiment of a vehicle on-board
system. Realtime time series data is acquired from many sensor
on-board the vehicle 702. At intervals, the analysis software is
comparing the sensor data feeds to either an accident pattern 710
or a driver pattern 712 in search of a correlation. If an accident
pattern is detected this triggers recording of detail information
714 and a search for damage and injury patterns within the data
716. If a pattern is detected, then analysis is performed
concerning the extent of damage or injury and the location of
damage or injury 722 and this information along with the underlying
data is transmitted to interested parties 718.
[0353] If a driver pattern is detected 712, an instance of the
pattern is recorded 720 for later transmission 718 to, for example
an insurance company, for analysis.
Determination of Accident, Damage and Injury Patterns
[0354] Patterns are the vehicle on-board sensor output and other
external environmental information observed during an accident.
Patterns may be expressed as polynomial equation; they may be a
threshold constant or upper and lower range for a specific sensor;
they may be based on frequency and/or amplitude analysis of a
single type or multiple types of sensors or they could be a
statistical mean value for one or more sensor outputs or
environmental factors. Patterns will change over time as more data
is added, more sophisticated analysis is performed or more sensor
types are available for on-board measurement. Patterns for one type
of vehicle may be entirely different than for another type of
vehicle. This may be due to different sensor suites being available
or different physical attributes of the vehicle.
[0355] When starting a program for estimating accident damage and
injury using patterns, patterns can be inferred from historic
accident reports and/or vehicle on-board sensor data.
[0356] In an embodiment, if all or part of input for accident
detection, damage and injury assessment comes from accident
reports, these data may need to be parameterized in such a way as
they can be used into a numeric model. An example of
parameterization would be to characterize incidents into a
grouping. For example, it may be desirable to collectively refer to
impact force based on accelerometer readings in ranges in units of
meters/second' rather than actual values or as a mean over a time
frame.
[0357] The following tasks comprise steps to determine patterns
initially based on accident reports: [0358] Develop a relationship
between geographic location, the zone on the vehicle where the
damage occurred and severity of impact and other inputs, to the
cost of repair and likelihood that certain parts will have to be
replaced. Also develop a relationship to severity and location of
an impact and other vehicle specific inputs, to the likelihood of
injury to passengers. [0359] Develop transfer functions between
observation in historical databases built from accident reports to
on-board sensor measurements that are indicative of the
observations. For example, an accident impact could be inferred
when a rapid deceleration is detected either by accelerometer
measurements or change in speed measurements. Location, and
relative speed of an impact can be inferred based on 3 component
acceleration. Alternatively a side impact can be inferred when a
side airbag is deployed. [0360] Test the transfer function by
predicting vehicle damage and resulting cost based on sensor data
after an accident. Confirm the prediction based on conventional
accident and insurance adjustor reports. [0361] Refine the transfer
functions as necessary to increase statistical reliability. [0362]
Gradually incorporate sensor measurements and create a more
granular predictive models based solely on sensor measurements
(without inference from historical data not from sensors). In the
initial database collisions may be classified based on relative
speed of impact, for example. With more accurate speed data from
sensors and vehicle weights, the classification could be changed to
an impact momentum in N/m2 using finer ranges for classification
rather than simply an approximate relative speed of collision.
[0363] It may be desirable to limit the data/parameters that are
utilized and make some simplifying assumptions.
[0364] Accident detection patterns could be inferred simply by
knowing the weight of the car and inferring a maximum acceleration
or change in momentum that would indicate an accident occurred.
Damage and Injury patterns are approximated by relating specific
accident descriptions to ranges of acceleration or momentum and the
direction of impact. Once accidents are categorized as to the
location and severity of damage in terms of anticipated range of
acceleration that occurred during an event, then a cross
correlation between repairs and injury treatments required for a
given vehicle type can be made with the each range of
acceleration.
Insurance/Driving Risk Prediction
[0365] FIG. 8 shows one method of how to initially construct a
spatially referenced database, to be used to predict insurance risk
or risk of driving along a particular route or along certain
transportation segments during a given time of day or time of week,
based on existing historical information. A database of historical
information is needed in order to determine baseline insurance
premiums or risk and also to determine what type of information is
available that may be relevant to insurance risk or driving risk.
The development of the database assumes no strong correlation
between any parameter and risk. For example an individual may
consistently drive over the speed limit, but yet still be a safe
driver--therefore, at least on an individual level, fast driving
may not have a strong relationship to insurance risk, however as a
whole, drivers in general may be a larger risk if they drive
fast.
[0366] It is not presumed that relationships between parameters and
risk hold true over large areas--there may be locally relevant
predictors that are not as significant as in other areas. Certain
historical datasets or parameters may not be as readily available
in some areas as they are in others. For example, reports
documenting accidents and accident locations may be more readily
available and more easily input into a database for an urban area
than for a rural area. Or accident reports may not be available,
but traffic counts which may indicate accidents may be
available.
[0367] Ideally the attribution used for insurance rating will be
easier to deal with if it is consistent throughout the entire
rating area. To accommodate this, it may be necessary to
approximate a parameter stored in the database with input from a
related parameter. For example, from the previous paragraph, you
may wish to store accident occurrences associated with each road
segment. If accident reports are not available for an area of
interest but traffic flow information is, you may be able to infer
that while traffic stops or slows way down that this is caused by
an accident. This could then be reflected as an accident
occurrence. This inferred accident occurrence could further be
reflected in the metadata as the source for the accident count and
an indication that the count is less reliable than an actual
accident count. Another means of getting the proxy is the road
quality, like road maintenance, and quality of the road surface
type.
[0368] Accordingly as shown in FIG. 8, the first step 802 is to
find sources of historical information that potentially can be used
singly or in tandem with other parameters to predict insurance and
driving risk. As pointed out above, the sources of information may
vary locally, but it will be necessary to combine or map 806 the
information from different sources that represent the same
parameter into a single database field.
[0369] Any model or predictive function could be greatly influenced
by information that is acquired in real-time or near real time from
drivers. This information could comprise things such as speed of
travel, braking, engine function, acceleration, route taken and
many others. If this information is readily available, it will
influence the design of the predictive database. Therefore sources
of pertinent real time information need to be identified 804.
[0370] Based on what historical information that is available and
what quantity there is and what type of real time information can
be acquired, the database schema or design can then be created 808.
All parameters to be stored in the database will be geographically
referenced 814 with respect to an underlying GIS database 812 of
the transportation network. Certain parameter (for example a speed
limit) may also be temporally referenced.
[0371] Once a rating system is running based on the database, some
of the data in the database may be retired based on age or when
more accurate information becomes available. Therefore metadata
about the age and quality of the data needs to be documented
810.
[0372] FIG. 8 shows an example of how disparate information is
combined into a single layer in the risk database. The example is
given for accident reports but the technique also applies to any
type of attribution. As accident reports initially come from local
police departments and/or directly from insurers, the format of the
information and availability varies between departments or
companies. For example, one department will have available accident
reports that are geographically referenced to a street address or
an intersection 802 and another department will have accident
reports referenced to geographic coordinates 806, for example,
latitude and longitude. In an embodiment of this invention, risk
attribution is referenced to components of the transportation
network, for example street segments or intersections, with
possibly also direction of travel. Therefore the frame of reference
of the incoming accident reports need to be translated into the
frame of reference of the database. For accident reports
geographically referenced to a street address or intersection 802,
the reference must be geocoded 804 so that the segment or
intersection can be associated (snapped) 808 with appropriate road
segment or intersection in the database. If the incoming accident
report is referenced to map coordinates 806, then this location can
simply be snapped 808 to the nearest street segment or
intersection.
[0373] As is well known, the probability of an accident will
increase with increased traffic density and/or due to inclement
weather. This information may be available 810 with incoming
accident reports or may be available via other sources such from a
weather service which then can be related to an accident incident
via location and time.
[0374] The probably of an accident may increase based on the time.
For example the probability of an accident most likely increases at
2 AM (2:00) on New Year's day as opposed to any other day at the
same time. Therefore any form of attribution that can be associated
with an incident should be added 812 so that it can be analyzed to
see if there is any correlation with risk.
[0375] The granularity of associated information will vary. For
example if a traffic flow was associated with a particular accident
and that traffic flow information was acquired from a Traffic
Messaging Channel (TMC), this information may not be associated
with the exact location of the accident and therefore may be
suspect. The quality of the associated attribution for accident
reports needs to be documented as metadata 814.
[0376] It should be noted that initially accident reports (and
other parameters) would come from historical data such as police
reports, however, this could be supplanted by real time information
coming from vehicle sensors. For example, if an insurance
subscriber allowed access to the insurer for output from car
sensors, an accident incident could be recorded at the gps location
of the vehicle when there was signal indicating that the air-bag
was deployed. Once again the source of the report or parameter
should be included as part of the metadata and be used as a measure
of quality. Other driving telemetry obtaining devices which may be
installed on the vehicle (perhaps at the behest of the insurance
company) would be used to obtain additional pertinent
information.
[0377] In accordance with an embodiment, the system can incorporate
or utilize additional functionality as further described in U.S.
Patent Application titled "SYSTEM AND METHOD FOR USE OF PATTERN
RECOGNITION IN ASSESSING OR MONITORING VEHICLE STATUS OR OPERATOR
DRIVING BEHAVIOR"; application Ser. No. 13/679,722, filed Nov. 16,
2012, herein incorporated by reference.
Distributed Database Synchronization
[0378] In an embodiment the vehicle on-board database is specific
to that vehicle. In order to keep this data current and
geographically relevant, periodic syncing of the on-board vehicle
database needs to occur with the central database repository.
[0379] Syncing of the vehicle on-board database with the central
database needs to occur: [0380] During initialization of the
on-board vehicle database [0381] When process control software
needs to be updated [0382] When new accident detection patterns or
damage estimation patterns are available [0383] When vehicle
equipment is modified [0384] When the vehicle moves out of a
specified geographic area or when a trip is planned [0385] When the
insurance carrier is changed
[0386] As part of both the vehicle on-board database and central
database there is metadata associated with the currency of the
data. Upon update to new currency of data, the metadata is also
changed to reflect the update. Currency metadata is associated with
all data structures. If there was only a single currency on an
entire vehicle on-board database, then if an upload of new currency
data failed mid-stream, the entire upload would have to be
re-implemented.
[0387] The following occurs during a data currency upload. The
vehicle communication module establishes communication with a
central server or visa-versa. The vehicle identifies itself to the
server. The server then checks for flags associated with the
identified vehicle indicating whether an update was in progress
previously that did not finish. If there was an unfinished update,
the records of transaction IDs for database entries that were
successfully updated are retrieved to determine where the upload
needs to resume. The upload resumes until all new elements are
updated.
[0388] After a update has completed or if a new one is desired,
then the server performs a query to determine all pieces of
information that have changed since the last update and assigns
transaction IDs to each database replace or insert operation that
needs to happen. The query to determine what updates need to be
performed are based on the date of the last successful complete
update (or associated metadata), the vehicle VIN number and any
alterations to the vehicle systems and the location and/or
destination of the vehicle. Geographic information may be
overwritten or simply added to the database depending on how much
on-board storage is available. Update of geographically referenced
data such as the location and contact information of approved
repair establishments, occurs when the GPS or other location sensor
on-board the vehicle determines the vehicle is out of a zone where
this information is already stored. Alternatively, the information
could be stored previous to a trip being planned.
Detail of an Accident Detection and Assessment Embodiment
[0389] The following is an embodiment of how an accident is
identified and damage and injury are assessed. A single 3 component
accelerometer is used as the sole sensor for accident detection,
damage and injury assessment. The weight of the vehicle is known.
The acceleration of the vehicle is measured continuously, for
example, at a frequency of 100 Hz. Acceleration measurements at
each sampling interval are placed on top of the memory stack. After
every sampling period, using the last successive acceleration
measurements over a preset time interval and the vehicle weight, a
running mean force vector and a mean force duration (impulse or
momentum change) and a peak force vector are calculated.
[0390] The accident detection pattern is defined as either when the
peak-force exceeds a preset threshold or the amplitude of the
mean-force vector exceeds a threshold value for a set amount of
time. If one of these conditions occurs, then an accident is
declared in progress. The thresholds for force and duration are
configurable based on type of vehicle and weight of vehicle and
historical information. If the same threshold were used for a many
ton tractor trailer and a 1.5 ton smart car, you would get many
false positive accident detection events for the tractor
trailer.
[0391] At the end of the accident event, damage assessment occurs
by comparing how much the thresholds were exceeded and the
directionality of the force vector and comparison to historical
records that indicate costs and parts and potential injuries and
treatment costs associated with this type of force/duration and
direction (this is the damage and injury assessment parameter).
[0392] The raw data is uploaded to the central database and once
actual figures for repair are input into the central database, this
information becomes part of the historical database and the
accident and damage patterns can be refined based on this new
input.
Sample Notification of Accident Occurrence
[0393] In an embodiment an accident report is referred to as the
The First Notice of Loss (FNOL) would consist one or more of the
following parameters: [0394] Policy number of vehicle insurance
[0395] ID of any hardware system involved in acquiring information
or processing the information [0396] Version number of data
acquisition and analysis software [0397] Data and time of accident
including time zone [0398] Location of accident [latitude,
longitude, altitude] [0399] Direction of travel (compass direction)
[0400] Velocity of vehicle prior to accident (include speed limit
for the road as optional value to be added/or when not available as
unknown value) [0401] Road type (use map road classification value
[0402] Vehicle information [0403] Make; Model; Year; [0404] VIN
(Unit can read VIN from vehicle if exposed in OBD; TOMS TDR file
provide policy and vehicle details including the VIN) [0405]
Odometer reading [0406] Ignition state (values: ON/OFF) [0407]
Driver identification [0408] Accident severity category (force of
impact) [0409] Accident impact information (incident angle of
impact, car zones affected
[0410] In embodiments where a communication connection is lost, the
vehicle on-board processor could send an accident report directly
via SMS.
[0411] Examples are shown below of incidents that can be recorded
in a risk database (part of a central database) and which can
subsequently be used to determine driving/insurance risk. Examples
of associated attribution are also provided. These are examples
only and is not an exhaustive list. [0412] Accidents [0413] Crime
[0414] Tickets [0415] Vandalism [0416] Insurance Payout; Fault
(victim or perpetrator) [0417] Road Condition (Potholes, pavement
temperature, lane marking, etc.) [0418] Road Surface Type [0419]
Traffic Counts [0420] Weather Events (Ice, Snow, Rain, Fog, Smog,
Temperature) [0421] Driver Distracted? Also visibility of curves,
signs, traffic lights, warning signals [0422] Traffic Flow [0423]
Volume of Traffic [0424] Speed of Traffic/Excess Speed [0425] Lane
Closures [0426] Detours [0427] Related Accidents
[0428] The following list are examples of information that may be
recorded for an individual driver and may come from either/or
questionnaires or real-time sensor information: [0429] Type of car;
where you drive; when you drive; snow tires during winter; previous
tickets Real-time tracking allowed by the vehicle driver? [0430]
GPS, bluetooth usage (i.e., cellphone); rapid acceleration;
braking; airbag deploy; speed; other driving telemetry devices
installed in car (accelerometer, gyroscope, compass) [0431] Air Bag
Deployment [0432] Rapid Acceleration/Deceleration [0433] Swerving
from lane [0434] Segments and intersections traversed including
time of day; time of week; speed; braking; acceleration; lane
changes; crossing the median; bluetooth usage [0435] Stopping
locations; duration [0436] Associated weather
[0437] Once a historical database of incidents, for example,
accidents and traffic violations is developed and referenced to
transportation elements, then analysis can be performed to
determine relationships to risk. Once again, no a priori
assumptions are made about a correlation between a particular
parameter and risk other than initial assumptions that are made to
run and test a multivariate model.
[0438] In an embodiment, incidents are evaluated based on the
quantity and quality of information available and also the extent
over which the information is available. The goal is to create a
risk index or indices based on one or more of the type of incidents
recorded related to elements of the transportation network.
[0439] In an embodiment, what is desired, is a function to predict
the likelihood that a given driver will make an insurance claim and
for how much. The likelihood of claims and cost of those claims can
be a function of: [0440] Time [0441] Location (for driving and
parking) [0442] Driver Performance [0443] Road Conditions [0444]
Weather [0445] Traffic Volume [0446] Crime Statistics [0447] Type
of Vehicle [0448] Number of passengers [0449] Vehicle condition
[0450] These parameter can be further broken down into: [0451]
Time: time of day, time of week, time of year, holidays;
daylight/nighttime [0452] Location: relative to a transportation
segment, geographic location, within a political boundary [0453] If
monitored with car sensors (where a vehicle is left overnight;
where and when it is driven); [0454] Driver Performance: [0455] If
monitored using sensors while driving: amount of distraction
(mobile use); driving above or below speed limits; weaving; rapid
acceleration; road class usage; and duration [0456] From records:
accident reports; speeding and other violations [0457] Road
Conditions: [0458] From records: potholes, sanding/salting during
storms; plowing frequency; number of police patrols; visibility
issues (like proper lighting at night, or blinding sun in eyes)
[0459] From vehicle sensors: bumpiness; storm conditions; ABS
braking engaged; differential slip
[0460] The factors that may influence the number and amount of
insurance claims may be exceedingly complex. This is why the
analysis lends itself to a form of multivariate analysis. Typically
a human can only visualize the relationship between 2 maybe 3
variables at a time and a parameter my not be directly related to a
cause of an incident, but may provide an indication of the cause.
For example in one area, it may be found that the instance of
traffic accidents at 2 AM is far greater than in another area.
Therefore you could conclude that time of night is not a very good
overall predictor of having an accident. However if you also
observe that in the first area, the instance of arrest for drunk
and disorderly is higher than the second area, the combination of
time and arrests for intoxication, may be a much better predictor.
If yet more variables are introduced, then the relationship may get
more complicated and more poorly understood without some form of
multivariate statistical correlation.
[0461] In another example the quality of the information will
influence the predictive model. It is well known that ice formation
on a road is a function of temperature, humidity and barometric
pressure. However if the weather conditions in an accident report
are based on the general weather conditions for the region from a
weather report, this data will not take into account, subtle
weather variations that may be available from in-car sensors. A
difference of a degree in temperature could make the difference
between ice and no ice.
[0462] As shown in FIG. 9, once an initial database is constructed
902 with some or all of the above listed information, then a
predictive model (patterns) needs to be developed. When collecting
data, care must be taken to not duplicate the same incident that is
recorded in multiple sources. A statistical significance of the
measurement parameters needs to be evaluated with respect to
insurance risk 904. For a given geographic area, it must be
ascertained whether or not there is enough data to make a
meaningful correlation and whether that data is of sufficient
quality. If the data is of mixed quality, as in the freezing
pavement example above, then quality must be taken into account for
the overall general model. This can be done by setting a minimum
threshold data quality where a dataset must contain quality data
for a specified percentage of the transportation elements within
the region of interest.
[0463] It is desirable to have as much granularity in the observed
information as possible in order to determine what information
correlates more strongly to risk. Using the accident report
example, we want to predict insurance risk. Therefore, for all the
accidents that occur in a region, if we have information on the
insurance pay-out, a model can be developed that uses part of the
information is a training set 906, for example in a neural network
predictive model known in the art and part of the data to test the
prediction 908.
[0464] In many multivariate analysis methods, initial assumptions
need to be made to come up with a working predictive function 906.
For example, initial weighting or correlation values might need to
be assigned to the input variables. An educated guess may be that
the number of pot holes in a road is about half as important to
risk as the number of drunk driving arrests.
[0465] Once an initial model is generated, an iterative process 910
is used to converge on a reasonable predictive model. This is done
by modifying the weighting of input parameters slightly 912, then
rerunning the new predictive function and observing the correlation
statistics until an optimal correlation is arrived at.
[0466] In an embodiment, the input for a model may need to be
parameterized in such a way as it can be used into a model. An
example of parameterization would be to characterize incidents into
a grouping. For example, it may be desirable to collectively refer
to accidents counts falling into a range of 1-10 accidents per year
as a "low" accident count and have "medium" and "high" counts as
well.
[0467] As was previously pointed out, the parameters that could be
used to predict insurance or driving risk and the resulting model
could be exceedingly complex. Compiling information from a variety
of sources to populate a given parameter may be difficult and if
available data is insufficient, may also result in a poor
prediction. Therefore, in order to keep the cost of the insurance
rating or driving risk system low and to facilitate rapid
development, it may be desirable to limit the data/parameters that
are utilized and make some simplifying assumptions.
[0468] In an embodiment, the assumption is made that insurance or
driving risk for driving on a particular transportation element is
directly correlated to the number of accidents reported on that
element over a set time period. Therefore the risk database could
simply contain accident incidents that are related to individual
transportation segments. If available, additional attribution that
may be recorded with accident incidents are, for example, direction
of travel, time of day, date, and weather variables. In this
embodiment, it is further assumed that insured drivers have agreed
to have their driving habits monitored. If the person is applying
for insurance, an initial insurance premium could be based
partially on the area of residence and some average of accident
risk within a geographic radius of the residence. Alternatively or
after an initial rate is applied, the weekly habits (or longer
duration) of the driver could be monitored. By monitoring when and
where the driver has been, then, for example, it could be
determined all the transportation elements the driver has traversed
for a given rating interval and how many times they have been
traversed.
[0469] As shown in FIG. 10, this embodiment would comprise
assembling an accident incident database and linking accidents
incidents to transportation elements 1002. If any additional
information is available such as the time of accident, the severity
of the accident, the weather or pavement conditions, this should be
included as associated attribution. Based on the incident
information, an accident count could then be developed 1004 which
in its simplest form would be the average number of accidents that
occur on each transportation element over a given time period. If
other attribution is available, then the accident count could be
further subdivided based by separating data, for example, for a
given time of day or time of week, thus having multiple accident
counts per transportation element. If severity information was
available, then accident incidents could be weighted in the
accident count, for example, an accident with a fatality could be
counted as 10 times a minor accident.
[0470] To determine an insurance premium based on the above
accident counts, then the risk associated with an individual's
driving habits needs to be assessed. The can be done by collection
of data while an individual is driving 1006. Data to be collected
comprises when and where a person is driving and then relating that
information to the transportation elements a person drives on and
the frequency they drive on them. From this information, a basic
Hazard Index (I) can be developed 1008. In its simplest form, the
Hazard Index is the summation of the accident count for all
elements traversed multiplied by the number of traversals for a
given time period. Finally insurance premiums could be adjusted
based on the individual Hazard Index when compared to other
individuals.
[0471] Yet more refinement of an individual Hazard Index could be
made by further subdividing the index based on additional
attribution such as weather and road conditions provided that the
accident count database has this amount of granularity.
[0472] As more drivers are monitored, gradually, historical data
gleaned from accident reports could be replaced by, for example,
air bag deployments sensor information from insured drivers. The
air bag deployment could be related to accident occurrence and
severity and would make it unnecessary to acquire accident
information from other sources such as accident reports from the
police.
[0473] In an embodiment of the present invention, once a database
of insurance or driving risk is established and maintained with
current information, then commercial risk products can be created
that map the associated driving risk to transportation elements,
for example in a geographic information (GIS) system. This product
can be sold to municipalities and other entities responsible for
safety on transportation networks and provided to driver so they
know what the risk of driving a particular route is.
Influence Driving Behavior
[0474] Yet another embodiment of the present invention is a method
to reduce driver/insurance risk utilizing one of the above
described risk and driver habit databases and monitoring of a
driver activities and habits in real-time. The system utilizes a
navigation device located in a vehicle. The navigation device is
either in communication with a risk database and a driving habits
database or the databases are stored within the navigation device.
The navigation device can be integral to the vehicle, a stand-alone
device or software implemented on a computer, smartphone or tablet
device. Generally location is determined by a GPS which is part of
the navigation device. Based on former analysis and part of the
driver habits database, the system pre-determines routes that the
driver in question has historically taken. It further determines
the propensity of the driver to deviate from safe driving habits
such as driving faster than the speed limit or swerving in the
other lane or using a mobile phone (as determined from blue-tooth
usage for example).
[0475] As shown in FIG. 11, starting with the risk database 1102
and the driving habits database 1104, when a driver starts driving,
the system determines whether the driver is driving a historical
route, for example, driving towards work at a given time of day, or
alternatively if a driver has input a route 1106 to a new
destination. If a route is being taken, the system next looks for
real-time information from external sources of information
1108--for example traffic counts, accident reports or reports of
lane closures. In addition, weather information along the route
could also be acquired. Next, the travel time and risk assessment
along the anticipated route is calculated by the navigation device.
Alternate routes are also calculated taking into account the
real-time information. If an alternate route is found that is safer
and/or faster 1114, then this information can be displayed to the
driver and a selection can be presented to route via the safer or
faster route 1118. If the safer route is selected 1120, then the
navigation system can either add an indication into the driver
habit database, that the advice was taken or this can be
transmitted to a server where insurance rates are determined. This
information can then be used to affect insurance rates 1116.
[0476] In addition, deviations from safer driving habits are
monitored during driving 1112. If a bad driving habit are
detected--say, for example, exceeding the speed limit--advice can
be displayed to slow down. If the advice is taken, then this
information can be treated as in the above safe route scenario
1116.
Road Hazard Mapping
[0477] FIG. 12 depicts an embodiment of the present invention
showing compilation of geo-referenced hazard information which can
subsequently be displayed to vehicle drivers or which can be viewed
on a map view showing transportation routes. Accident reports are
compiled that are referenced to street addresses 1202 or to map
coordinates 1206. For the accident reports referenced to streets
1202, the addresses are geocoded to get a location in map
coordinates 1220. Located accident reports are then associated with
a transportation segment such as a road segment or intersection
1208. Any associated environmental conditions are added to the
database which are referenced to the time and place of the accident
1210. Any pertinent additional data is also associated with the
accident 1212. Finally metadata with respect to the quality of
information is added to be used to remove outdated or poor quality
data as more and better accident information comes it.
Methods of Implementation
[0478] The present invention may be conveniently implemented using
one or more conventional general purpose or specialized digital
computers or microprocessors programmed according to the teachings
of the present disclosure, or a portable device (e.g., a
smartphone, tablet computer, computer or other device), equipped
with a data collection and assessment environment, including one or
more data collection devices (e.g., accelerometers, GPS) or where
the portable device are connected to the data collection devices
that are remote to the portable device, that are connected via
wired or wireless means. Appropriate software coding can readily be
prepared by skilled programmers based on the teachings of the
present disclosure, as will be apparent to those skilled in the
software art.
[0479] In some embodiments, the present invention includes a
computer program product which is a non-transitory storage medium
(media) having instructions stored thereon/in which can be used to
program a computer to perform any of the processes of the present
invention. The storage medium can include, but is not limited to,
any type of disk including floppy disks, optical discs, DVD,
CD-ROMs, microdrive, and magneto-optical disks, ROMs, RAMs, EPROMs,
EEPROMs, DRAMs, VRAM5, flash memory devices, magnetic or optical
cards, nanosystems (including molecular memory ICs), or any type of
media or device suitable for storing instructions and/or data.
Remarks
[0480] The foregoing description of the present invention has been
provided for the purposes of illustration and description. It is
not intended to be exhaustive or to limit the invention to the
precise forms disclosed. The embodiments were chosen and described
in order to best explain the principles of the invention and its
practical application, thereby enabling others skilled in the art
to understand the invention for various embodiments and with
various modifications that are suited to the particular use
contemplated. For example, although the illustrations provided
herein primarily describe embodiments using vehicles, it will be
evident that the techniques described herein can be similarly used
with, e.g., trains, ships, airplanes, containers, or other moving
equipment, and with other types of data collection devices. It is
intended that the scope of the invention be defined by the
following claims and their equivalence.
* * * * *