WO2014207558A2 - Onboard vehicle accident detection and damage estimation system and method of use - Google Patents

Abstract

Described herein is an onboard vehicle accident detection and damage estimation system and method of use. In accordance with an embodiment, a vehicle is equipped with a portable device comprising sensors that monitor vehicle and driver activity and a data collection and assessment module. Incoming sensor data is compared to historical patterns to detect when an accident has occurred. Once an accident is detected, an estimation of damage and injury is performed. The information can be used, for example, by an investigator or an insurance claims adjuster, to review the status or operation of a vehicle at the time of the accident. Additional uses of the system include notification to emergency responders and determination of the driving risk associated with segments of a transportation network.

Description

Onboard Vehicle Accident Detection and Damage Estimation

System and Method of Use

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. Priority Claim:

[0001] This application claims the benefit of priority to US Provisional Application No. 61/840,383 titled "SYSTEM AND METHOD FOR DETERMINATION OF VEHICLE ACCIDENT INFORMATION" filed on 27 June 2013 and US Provisional Application No. 61/846,203 tilted SYSTEM AND METHOD FOR DETERMINATION OF VEHICLE ACCIDENT INFORMATION" filed on 15 July 2013 and 61/968904 titled "RISK BASED AUTOMOTIVE INSURANCE RATING" filed on 29 April 2014 of which are herein incorporated by reference.

[0002] This application is 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 No. 13/679,722, filed November 16, 2012; which claims the benefit of priority to U.S. Provisional Patent Application No. 61/578,511, filed December 21, 2011;

PCT/US 12/71487 titled "SYSTEMS AND METHODS FOR ASSESSING OR MONITORING VEHICLE STATUS OR OPERATOR STATUS" filed 21 December 2012; and 14/317624 titled "System and method for Determining Of Vehicle Accident information" file on 27 June 2014; each of which the above applications are herein incorporated by reference. Field of Invention;

[0003] This invention relates to an in-vehicle system and method to detect, analyze and transmit information about an accident. The system monitors onboard sensor input then compares that input with predetermined stored relationships (patterns) to detect accidents and to access resulting damage and injury. Immediately after a detected accident, damage/injury assessment is then wirelessly transmitted (if feasible) to interested parties such as first responders and insurance carriers. The invention also relates to method of initial creation, update and maintenance of the system and supporting database. Background;

[0004] There is a need to both detect when and where a vehicle accident occurs and to accurately assess the damage and loss as well as injury associated with 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.

[0005] 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.

[0006] 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.

[0007] 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.

[0008] 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 drivers past driving history.

[0009] 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.

[0010] 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.

[0011] 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. 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.

[0012] 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.

[0013] 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.

[0014] 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.

[0015] 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.

[0016] 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.

Glossary;

[0017] 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.

[0018] 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.

[0019] 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.

[0020] 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. [0021] 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.

[0022] 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 / 5g's.

[0023] 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.

[0024] 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.

[0025] 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.

[0026] 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.

[0027] 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.

[0028] 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.

[0029] 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.

[0030] Parameters: Any factor that may be directly or indirectly be related to insurance risk, accident pattern, injury pattern, damage pattern or driver pattern.

[0031] 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.

[0032] 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.

[0033] 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.

[0034] 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.

[0035] 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. [0036] 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.

• Standard GIS road network including:

Road Segments

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.

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.)

Intersections

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)

Attributes are stored that are associated with the intersection and/or the connecting segments

Maneuvers (including complex maneuvers)

Geography usually stored as a reference to one or more geographic components that make up the maneuver

Attribution Examples (all attributes may have multiple values base on time and may also have metadata associate with them):

For Segments:

Speed limit / Actual Speed Driven

Accident Count

Historical Traffic Flow/count

Historical Weather Information

Number of Lanes

Vehicle Type Access

Street Side Parking

Elevation / Change in Elevation

Railroad crossing

Political Boundaries

Parking Areas • Historical Data

Crimes associated with a location (snapped to road segment or intersection); time of data; time of year

Accidents: type of accident (solo or collision); location, direction of travel; date, time of day; type of vehicle; weather; driver record

Previous Claims: location; type of claim (accident; vandalism; car-jacking); amount of claim; type and age of vehicle.

Police citations: location, type

Weather: ice, temperature, wind, pressure, snow, rain, flooding

Time Series of sensor data before during and after an accident; or indicative of a driver pattern

Brief Summary of the Invention;

[0037] The present invention pertains 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:

a. A vehicle on-board system comprises:

i. a processor which monitors and analyses onboard sensors used to detect vehicle activity and driver behavior;

ii. an on-board database comprising:

1. which stores vehicle specific information;

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;

3. Driver information;

4. Emergency contact information;

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.

b. A central server comprising : i. One or more computers;

ii. A comprehensive central database located on one or more servers

comprising:

1. historical information from several sources

2. raw sensor data or indices derived from the raw sensor data from individual vehicles.

3. Patterns for all vehicle types and areas

4. Geographic Information

5. Spatial, temporal, and severity Information pertaining to accident incidents

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.

[0039] An object of the present invention is a method to develop a database comprising parameters that may be related to accident detection, accident categorization, insurance risk to be used for vehicle insurance rating and/or pricing and furthermore, where the parameters are related to transportation network elements and/or driving behavior, and/or to vehicle type and characteristics.

[0040] Another object of the invention is to determine which parameters or combination of parameters best able to detect accidents, to categorize accidents, and to determine insurance risk for individual drivers.

[0041] A further object of the present invention is a maintenance and update method for the above mentioned databases.

[0042] Yet another object of the present invention is to track and parameterize the driving habits of individual drivers and to compare those driving habits to historical parameters and habits of other driver in order to predict individual insurance risk.

[0043] It is a further object of the present invention to influence the driving habits of individual drivers by suggesting safer routes or driving habits and to reword or penalize individual driver based on their utilization or lack of utilization of suggestions.

[0044] It is an object of the present invention to develop a system that comprises a database, software and hardware to predict accidents, damage from accidents, and insurance risk, and to mitigate insurance risk while individuals are driving and to set insurance premiums based on the database and real-time input. [0045] It is an object of the present invention to develop an insurance rating system based on accident counts for individual elements of a transportation network and how frequently a driver travels elements with accident risk.

[0046] It is an object of the present invention to provide information to a driver of risk associated with driving at a particular location and time either by written, verbal or visual methods.

Brief Description of the Drawings;

[0047] The drawings constitute a part of this specification and include exemplary embodiments to the invention, which may be embodied in various forms. It is to be understood that in some instances various aspects of the invention may be shown exaggerated or enlarged to facilitate an understanding of the invention.

[0048] Figure 1 illustrates a vehicle on-board system for acquiring, analyzing and transmitting onboard sensor data.

[0049] Figure 2 illustrates the process of pattern detection in sensor data.

[0050] Figure 3 illustrates a method of determining insurance risk.

[0051] Figure 4 illustrates a method of determining models or patterns.

[0052] Figure 5 illustrates a method for generating a hazard index.

[0053] Figure 6 is a flowchart for using a system to adjust insurance rates based on risk

Detailed Description of Embodiments of the Invention;

Central Service / Server / Database

[0054] One or more servers provide the functions in the form of web services or similar of:

• Communications will vehicle equipped with on-board measurement and analysis systems

• Linking a central database/s with vehicle on-board databases containing information used in the system

• Analysis of data / creation of patterns for accident detection, injury and damage assessment, driver behavior and insurance risk.

• Database maintenance / updating

• Cross correlation of information from disparate sources

• Repository for all related information

[0055] The central service /server or servers are in periodic communication with the vehicle onboard 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 th date of the accident.

Database Content

[0056] 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

• Collections of sensor data acquired during accident events along with a unique ID for each event

• Weather, traffic and road conditions data for each accident event

• Insurance company profiles and communication protocols

• Vehicle specific information including parts and options

• Associated parts and services required for specific types of accident damage and injuries that may be incurred

• Accident Patterns specific to the vehicle (relationship between sensor output and accident detection)

• Damage Patterns specific to the vehicle (relationship between sensors output and type and severity of damage and parts that may need to be replaced)

• 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.)

• Driver Behavior Patterns generic to a group of drivers and indicative of good and bad driver characteristics

• Repair facility information relative to both the vehicle type and insurance carrier

• Towing services relative to both the vehicle type and the insurance carrier

• Contact information for:

o Insurance Adjuster

o Local Emergency Dispatch

o Part Carriers

o Auto Body and Auto Repair Providers • Cross correlation information of parts for each vehicle with the same parts in other vehicles

• Geographic parts availability

• Location of medical treatment facilities and their capabilities

• Digital Map of the area or areas of interest for georeferencing accident events and

relationship to driving risk

On-board Vehicle System

[0057] Figure 1 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).

[0058] The overall system comprises vehicle on-board systems for many vehicles and one or more central processor/s and data repository/s.

[0059] A vehicle on-board system Figuer 1 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.

[0060] In an embodiment some or all of the following functions occur in the vehicle on-board system:

• Continuously monitoring of sensors occurring a data acquisition module 104

• Acquiring external information via wireless communication from external services 110 off- vehicle

• In a pattern recognition module 106, matching sensor output or derivatives of sensor output 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 .

• Matching sensor output or derivatives of sensor output to patterns that are indicative of driver behavior.

• Store sensor data and analysis for defined time periods in an onboard database 112.

• Store damage/injury assessment and/or raw sensor data pertaining to the accident in an onboard database 112.

• If wireless communication is available using an external communication module 114 after an accident event, submit preconfigured damage/injury assessment reports; send out prefigured requests for services and supplies based on the assessed damage/injury. • 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.

• Make damage/injury analysis available for on-scene participants via short range wireless or wired connection.

• 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 Figure 1)

[0061] As shown in Figure 1, the vehicle on-board hardware and/or software implementation components to achieve the above tasks are:

On-board Sensors 102 (Data Collection Devices)

A data acquisition module 104

Pattern recognition module 106 for accident detection and damage/injury assessment On-board Database 112 containing:

sensor data 108

Patterns (not shown)

Communication module 114 used between on-board systems and components and/or external server/s and services

[0062] The on-board sensors 102 comprise one or more of:

GPS

Air bag deployment indicator

Accelerometers

Gyroscope

Seatbelt fastened indicator

Number of passengers (sensors in seats)

Ambient Temperature

Tire pressure

Engine Oxygen Sensors

Engine Temperature

PMs

Vehicle Speed

Exterior Temperature

Humidity Dew Point

Video Cameras

[0063] External Services 110 that are monitored comprise one or more of:

Weather

Road Conditions

Traffic

[0064] A pattern recognition module 106 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

[0065] Individual vehicle on-board databases 112 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.

[0066] 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.

[0067] 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.

[0068] 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.

[0069] 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.

[0070] 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:

a. Number of vehicle trips and where for a given time interval

b. Number of accidents reported in last day/week/month/year

c. Number of risky driving events reported in last day/week/month/year

d. Number of speeding events reported in last day/week/month/year

Building the Initial Central Database

[0071] 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.

[0072] 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 (12mph). 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.

[0073] 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).

[0074] 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.

[0075] Alternatively, an initial accident detection pattern could simply be the observation that an airbag has deployed.

[0076] Information amassed from historical records that are desirable to input into the central database are:

• Impact zone (where impact occurs on the vehicle),

• Impact magnitude and direction (usually inferred from accelerometer readings)

• Location (geographic)

• Vehicle Type and age( and from the Vehicle Identification Number (VIN), what options did the car come with)

• Any custom modification to the vehicle (mag wheels, aftermarket sound / entertainment system)

• The availability of parts within the vicinity of the accident

• Who, where and how quickly was the auto fixed

• Listing of OEM or other parts used for the fix.

• Speed, direction of travel

• Single car collision, multiple car collision; relative speed, speed of the other vehicle

• Brakes on? ABS engaged; airbags deployed • Pictures and/or video of the accident

• Surveillance camera footage

• Insurance pay-out.

• Emergency esponder and onsite treatment received

• Transport to what hospital facilities

• Number of passengers, where they were sitting and extent of injuries

• Erratic driving behavior prior to the accident for the driver

[0077] To build the initial database, some or all of the following need to be performed:

• 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.

• 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.

• 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.

• Design and Create metadata for entries into the database.

• Identify relationship between damage and cost to fix the damage, to indicators of the extent of damage from the historical database/s.

• Map historical information to a map database of the transportation network

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

[0078] 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.

[0079] 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.

[0080] 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.

[0081] 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.

[0082] Figure 2 illustrates and embodiment of a vehicle on-board system. Realtime time series data is acquired from many sensor on-board the vehicle 202. At intervals, the analysis software is comparing the sensor data feeds to either an accident pattern 210 or a driver pattern 212 in search of a correlation. If an accident pattern is detected this triggers recording of detail information 214 a a search for damage and injury patterns within the data 216. If a pattern is detected, then analysis is performed concerning the extent of damage or injury and the location of damage or injury 222 and this information along with the underlying data is transmitted to interested parties 218.

[0083] If a driver pattern is detected 212, a instance of the pattern is recorded 220 for later transmission 218 to, for example an insurance company, for analysis.

Determination of Accident, Damage and Injury Patterns

[0084] 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.

[0085] 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.

[0086] 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.

[0087] The following tasks comprise steps to determine patterns initially based on accident reports:

^■ 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.

^■ 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.

^■ 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.

^■ Refine the transfer functions as necessary to increase statistical reliability.

^■ 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/m² using finer ranges for classification rather than simply an approximate relative speed of collision.

[0088] It may be desirable to limit the data/parameters that are utilized and make some simplifying assumptions.

[0089] 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

[0090] Figure 3 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.

[0091] 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.

[0092] 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.

[0093] Accordingly as shown in Figure 3, the first step 302 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 306 the information from different sources that represent the same parameter into a single database field.

[0094] 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 304.

[0095] 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 308. All parameters to be stored in the database will be geographically referenced 314 with respect to an underlying GIS database 312 of the transportation network. Certain parameter (for example a speed limit) may also be temporally referenced.

[0096] 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 310.

[0097] Figure 2 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 302 and another department will have accident reports referenced to geographic coordinates 306, 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 302, the reference must be geocoded 304 so that the segment or intersection can be associated (snapped) 308 with appropriate road segment or intersection in the database. If the incoming accident report is referenced to map coordinates 306, then this location can simply be snapped 308 to the nearest street segment or intersection.

[0098] 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 310 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.

[0099] 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 312 so that it can be analyzed to see if there is any correlation with risk. [00100] 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 314.

[00101] 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.

[00102] 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 RECOGN ITION I N ASSESSING OR MON ITORI NG VEHICLE STATUS OR OPERATOR DRIVING BEHAVIOR"; Application No. 13/679,722, filed November 16, 2012, herein incorporated by reference.

Distributed Database Synchronization

[00103] 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.

[00104] Syncing of the vehicle on-board database with the central database needs to occur:

^■ During initialization of the on-board vehicle database

^■ When process control software needs to be updated

^■ When new accident detection patterns or damage estimation patterns are available

^■ When vehicle equipment is modified

^■ When the vehicle moves out of a specified geographic area or when a trip is planned

^■ When the insurance carrier is changed

[00105] 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. [00106]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.

[00107] 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

[00108]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 100Hz. 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.

[00109]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.

[00110] 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).

[00111] 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

[00112] 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:

• Policy number of vehicle insurance

• I D of any hardware system involved in acquiring information or processing the information

• Version number of data acquisition and analysis software

• Data and time of accident including time zone

• Location of accident [latitude, longitude, altitude]

• Direction of travel (compass direction)

• Velocity of vehicle prior to accident (include speed limit for the road as optional value to be added / or when not availa ble as unknown value)

• Road type (use map road classification value

• Vehicle information

o Make; Model; Year;

o VI N (Unit can read VI N from vehicle if exposed in OBD; TOMS TDR file provide policy and vehicle details including the VI N)

o Odometer reading

o Ignition state (values: ON / OFF)

• Driver identification

• Accident severity category (force of impact)

• Accident impact information (incident angle of impact, car zones affected

[00113] In embodiments where a communication connection is lost, the vehicle on-board processor could send an accident report directly via SMS.

[00114] 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.

• Accidents

• Crime

• Tickets

• Vandalism

• Insurance Payout; Fault (victim or perpetrator) • Road Condition (Potholes, pavement temperature, lane marking, etc.)

• Road Surface Type

• Traffic Counts

• Weather Events(lce, Snow, Rain, Fog, Smog, Temperature)

• Driver Distracted? Also visibility of curves, signs, traffic lights, warning signals

• Traffic Flow

o Volume of Traffic

o Speed of Traffic / Excess Speed

o Lane Closures

o Detours

o Related Accidents

[00115]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:

Type of car; where you drive; when you drive; snow tires during winter; previous tickets

• Real-time tracking allowed by the vehicle driver?

o GPS, bluetooth usage (ie cellphone); rapid acceleration; braking; airbag deploy; speed; other driving telemetry devices installed in car (accelerometer, gyroscope, compass)

• Air Bag Deployment

• Rapid Acceleration / Deceleration

• Swerving from lane

• Segments and intersections traversed including time of day; time of week; speed; braking; acceleration; lane changes; crossing the median; bluetooth usage

• Stopping locations; duration

• Associated weather

[00116] 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.

[00117] 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.

[00118] 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:

• Time

• Location (for driving and parking)

• Driver Performance

• Road Conditions

• Weather

• Traffic Volume

• Crime Statistics

• Type of Vehicle

• Number of passengers

• Vehicle condition

[00119]These parameter can be further broken down into:

• Time: time of day, time of week, time of year, holidays; daylight/nighttime

• Location: relative to a transportation segment, geographic location, within a political

boundary

o If monitored with car sensors (where a vehicle is left overnight; where and when it is driven);

• Driver Performance:

o 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

o From records: accident reports; speeding and other violations

• Road Conditions:

o 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)

o From vehicle sensors: bumpiness; storm conditions; ABS braking engaged; differential slip

[00120]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.

[00121] 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.

[00122] As shown in FIG 4, once an initial database is constructed 402 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 404. 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.

[00123] 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 as a training set 406, for example in a neural network predictive model known in the art and part of the data to test the prediction 408.

[00124] In many multivariate analysis methods, initial assumptions need to be made to come up with a working predictive function 406. 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.

[00125] Once an initial model is generated, an iterative process 410 is used to converge on a reasonable predictive model. This is done by modifying the weighting of input parameters slightly 412, then rerunning the new predictive function and observing the correlation statistics until a optimal correlation is arrived at.

[00126] 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.

[00127] 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.

[00128] 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.

[00129] As shown in Figure 5, this embodiment would comprise assembling an accident incident database and linking accidents incidents to transportation elements 502. 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 504 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.

[00130] 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 506. 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 508. 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.

[00131] Yet more refinement of an individual Hazard Index could be made by further su bdividing the index based on additional attribution such as weather and road conditions provided that the accident count database has this amount of granularity.

[00132] 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.

[00133] 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

[00134] 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).

[00135] As shown in FIGURE 6, starting with the risk database 602 and the driving habits database 604, 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 606 to a new destination. If a route is being taken, the system next looks for real-time information from external sources of information 608 - 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 614, then this information can be displayed to the driver and a selection can be presented to route via the safer or faster route 618. If the safer route is selected 620, 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 616.

[00136] In addition, deviations from safer driving habits are monitored during driving 612. 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 616.

Road Hazard Mapping

[00137] Figure 7 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 702 or to map coordinates 706. For the accident reports referenced to streets 702, the addresses are geocoded to get a location in map coordinates 720. Located accident reports are then associated with a transportation segment such as a road segment or intersection 708. Any associated environmental conditions are added to the database which are referenced to the time and place of the accident 710. Any pertinent additional data is also associated with the accident 712. 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

[00138]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.

[00139] 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.

[00140]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.

Claims

Claims; What is claimed is:

1. A system for vehicle accident and hazard assessment and reporting, comprising: at least one vehicle comprising: a plurality of sensors that measure vehicle and driver actions and characteristics; an external communication module used to transmit accident and hazard information to and from the at least one vehicle and remote servers, services and sources; an accident and hazard assessment and reporting module; a data collection module used to capture sensor data and data from remote servers, services and sources; a vehicle on-board database comprising: assessment patterns; captured sensor data; calculated indices based on captured sensor data; geographic information; hazard data; vehicle specific data; driver specific data; contact information; and environmental data; a central service comprising: at least one database comprising: a compilation of all vehicle on-board databases; historic information; a compilation of all vehicle assessment patterns; a communications module used to communicate with sources of information and vehicle accident and hazard assessment modules; and a pattern determination module; wherein the pattern determination module analyzes historic information and the compilation of all vehicle on-board databases to determine patterns indicative of: an accident event occurring, a damage assessment after an accident, an injury assessment after an accident, a driver behavior during driving, and a driving hazard associated with

transportation elements; and wherein the an accident and hazard assessment and reporting module monitors sensor data and remote data and compares those data to patterns and when a pattern matches the monitored data, at least one of recording an event in the database or a reporting occurs.

2. The system of claim 1 wherein the sensors can include: one or more accelerometers, a gyroscope, an airbag sensor, speedometer, GPS, and a compass and the data from remote servers, services and sources comprises at least on of weather, traffic and road closures.

3. The system of claim 1 wherein the pattern determination module determines and analyzes at least one of: vehicle speed, mass of the vehicle, direction of the vehicle, abrupt stopping of the vehicle and, the make, year and condition of the vehicle to be used in assessment patterns.

4. The system of claim 1 wherein the accident and hazard assessment and reporting module further comprises a display wherein the reporting is displayed in at least one of a text or a graphical or a map form.

5. The system of claim 1 wherein the reporting is transmitted to emergency personal and accident investigators using the external communications module immediately after an accident event and analysis thereof .

6. The system of claim 1 wherein at least one of the sensors or one of the modules are contained within a single portable device removable from the vehicle.

7. The system of claim 1 wherein the on-board database and central database further comprise information related to each accident event including as least one of: vehicle make and model, images of vehicle damage, cost of repair, and a list of damaged components, number and extent of injuries to passengers, and, the number of passengers.

8. The system of claim 1 wherein the external communication module periodically is used to upload captured sensor and other data to the central service for use to determine or update patterns and to be used in rating road hazards.

9. The system of claim 1 wherein the vehicle on-board database is periodically updated from the central database and wherein the information transfer is limited to one or more of: information relative to the vehicle specifics, the best or most recent data currency or metadata, and geographic location of the vehicle.

10. The system of claim 1 wherein the reporting also occurs during normal driving and comprises at least one of a text and map display of a hazard index associated with transportation segments in the vicinity of the vehicle location or a vehicle operator selected location or along a route corridor.

1 1. The system of claim 1 wherein the central database is initially created by: collecting historical data including accident reports and associated data; applying a transfer function to the historical data to put the historical data in terms of sensor data or indices derived from sensor data; and determining patterns based on the transferred historical data.

12. The system of claim 1 wherein the recorded events comprise driver behavior events for a driver that are analyzed to determine insurance premiums for that driver.

13. The system of claim 1 wherein the reporting comprises driver feedback to the driver while a driver is driving to alert the driver of certain types of driver behavior.

14. The system of claim 16 wherein, an event is recorded after a driver is alerted to a poor driver behavior and the driver subsequently reframes from that behavior.

5. A method for vehicle accident and hazard assessment and reporting, comprising: for at least one vehicle providing at least: a plurality of sensors that measure vehicle and driver actions and characteristics; an external communication module used to transmit accident and hazard information to and from the at least one vehicle and remote servers, services and sources; an accident and hazard assessment and reporting module; a data collection module used to capture sensor data and data from remote servers, services and sources; a vehicle on-board database comprising: assessment patterns; captured sensor data; geographic information; hazard data; vehicle specific data; driver specific data; contact information; and environmental data; providing a central service comprising: at least one database comprising: a compilation of all vehicle on-board databases; historic information; a compilation of all vehicle assessment patterns; a communications module used to communicate with sources of information and vehicle accident and hazard assessment modules; and a pattern determination module; wherein the pattern determination module analyzes historic information and the compilation of all vehicle on-board databases to determine patterns indicative of: an accident event occurring, a damage assessment after an accident, an injury assessment after an accident, a driver behavior during driving and a driving hazard associated with transportation elements; and wherein the an accident assessment and reporting module monitors sensor data and remote data and compares those data to patterns and when a pattern matches the monitored data, at least one of recording an event in the database or a reporting occurs.

16. A non-transitory computer readable medium, including instructions stored thereon which when read and executed by one or more computers cause the one or more computers to perform the steps comprising: for at least one vehicle providing at least: a plurality of sensors that measure vehicle and driver actions and characteristics; an external communication module used to transmit accident and hazard information to and from the at least one vehicle and remote servers, services and sources; an accident and hazard assessment and reporting module; a data collection module used to capture sensor data and data from remote servers, services and sources; a vehicle on-board database comprising: assessment patterns; captured sensor data; geographic information; hazard data; vehicle specific data; driver specific data; contact information; and environmental data; providing a central service comprising: at least one database comprising: a compilation of all vehicle on-board databases; historic information; a compilation of all vehicle assessment patterns; a communications module used to communicate with sources of information and vehicle accident and hazard assessment modules; and a pattern determination module; wherein the pattern determination module analyzes historic information and the compilation of all vehicle on-board databases to determine patterns indicative of: an accident event occurring, a damage assessment after an accident, an injury assessment after an accident, a driver behavior during driving and a driving hazard associated with transportation elements; and wherein the an accident assessment and reporting module monitors sensor data and remote data and compares those data to patterns and when a pattern matches the monitored data, at least one of recording an event in the database or a reporting occurs.

17. A system to alert drivers of the risk associated of driving a given route or in the vicinity of a present location of a vehicle comprising: a vehicle on-board database comprising: a transportation system database; driving risk factors associated with transportation segments in the transportation system database; a location and time determination device; a communication device; a risk assessment and reporting module; wherein the risk assessment and reporting module acquires environmental information from sources external to the vehicle, if available, using the communication device and acquires the selected or present location of the vehicle or route and determines the risk associated with driving on nearby transportation segments based on the associated risk factors and the given time.