Source: https://insight.rpxcorp.com/pat/US9019092B1
Timestamp: 2019-06-16 01:13:43
Document Index: 562036944

Matched Legal Cases: ['art500', 'art600', 'art650', 'art700', 'art800', 'art900', 'art1000', 'art1100']

Patent US 9,019,092 B1
US 10,026,091 B2
US 20150287311A1
US 9,466,196 B2
a disturbance response module installed at the vehicle in signal communication with one or more of the sensors, wherein the disturbance response module is configured to i) determine whether the vehicle was running when the disturbance event occurred, ii) determine whether the vehicle was moving when the disturbance event occurred, iii) determine that the vehicle was parked when the disturbance event occurred in response to a determination that the vehicle was not running and not moving when the disturbance event occurred; and
FIG. 1is an illustrative environment in which various aspects of the disclosure may be implemented.
FIG. 2is an example of an implementation of an operating environment in which various aspects of the disclosure may be implemented.
FIG. 3is an example of an implementation of network devices and servers that may be used to implement the processes and functions of certain aspects of the present disclosure.
FIG. 4is an example of an implementation of an insurance management system.
FIG. 5is a flowchart of example method steps for detecting and responding to a collision.
FIG. 6Ais a flowchart of example method steps for detecting a collision.
FIG. 6Bis a flowchart of alternative example method steps for detecting a collision.
FIG. 7is a flowchart of example method steps for automatically identifying the participants involved in a collision.
FIG. 8is a flowchart of example method steps for automatically determining and attributing fault to one of the participants involved in a collision.
FIG. 9is a flowchart of example method steps for automatically determining a total estimated repair cost for a vehicle involved in a collision.
FIG. 10is a flowchart of example method steps for automatically processing an insurance claim resulting from a collision.
FIG. 11is a flowchart of example method steps for automatically detecting and responding to a collision involving a parked vehicle.
Aspects of the present disclosure are directed towards automated collision detection, fault attribution, and insurance claims processing. Referring toFIG. 1, two individuals100a, 100bmay experience a vehicle collision, e.g., an accident. Wireless communication devices102a, 102bat each vehicle104a, 104bmay wirelessly communicate with an automated collision detection, fault attribution, and claims processing system106. The automated collision detection, fault attribution, and claims processing system106may be additionally or alternatively referred to as an insurance processing system. Communications may be exchanged between the system106and a mobile device108a, 108boperated by the individual100a, 100b, respectively, via, for example, a network110. The system106may automatically detect that a collision has occurred, automatically determine which individual100aor100bis at fault for the accident, and manage subsequent insurance claims resulting from the accident. The system106may also communicate with the individuals100a, 100bvia respective mobile devices108a, 108boperated by the individuals. It will be appreciated that, in some instances, more than two individuals may be involved in an accident. It will also be appreciated that, in some instances, a single vehicle may be involved in an accident. For example, an individual may hit a pole or a wall or the individual may forget to set a parking brake causing the vehicle to run away on its own. Accordingly, aspects of this disclosure are also applicable in situations where a single vehicle is involved in an accident.
As used throughout the description, the various terms may be used to refer to the entities involved or associated with the automated collision detection, fault attribution, and claims processing procedures. A participant in this context is an individual100a, 100bwhose vehicle104a, 104bwas involved in a collision. A participant may or may not be a customer of an insurance provider that provides insurance coverage. In some instances, participants may be customers of the same insurance provider while in other instances the participants may be customers of different insurance providers. An insurance provider may be referred to as an insurer, and a customer of the insurer may be referred to as an insured. The insurer may provide and operate the insurance management system106to automatically detect collisions, to automatically determine and attribute fault, and to automatically process insurance claims resulting from the vehicle collision.
Each participant in the vehicle collision may be insured by the insurance provider that operates the insurance management system106. In some situations, the participants may be respectively insured by different insurance providers in which case one of the participants may be described as being insured by a third-party insurance provider, e.g., a third-party insurer. The third-party insurer may operate a third-party insurance management system that also automatically detects collisions, determines and attributes fault, and processes insurance claims.
The insurance management system106provides a number of advantages by automating aspects of responding to collisions. As an example, the insurance management system106advantageously reduces the cost, time, and effort involved in processing and resolving an insurance claim by automating aspects of the claim processing and resolution process. The insurance management system106may automatically collect information relating to the collision, automatically determine and attribute fault to one of the participants, automatically estimate the cost to repair a damaged vehicle, and automatically provide settlement offers to participants involved in vehicle collisions. Moreover, by automating aspects of responding to vehicle collisions, the insurance management system106may advantageously provide automated settlement offers within a relatively short timeframe after the collision occurred. The insurance management system106described below also advantageously reduces the cost, time, and effort associated with subrogation by automating aspects of the subrogation process. These and other aspects will be discussed further below.
Referring toFIG. 2, an example of an implementation of an operating environment in which various aspects of the disclosure may be implemented is shown. In accordance with various aspects of the disclosure, methods, computer-readable media, and apparatuses are disclosed through which collisions may be automatically detected, fault automatically determined, and insurance claims automatically processed. In certain aspects, when an insurance management system receives data regarding a collision (e.g., from a vehicle), the insurance management system processes the data and manages the various automated procedures involved in responding to the collision.
FIG. 2illustrates a block diagram of an insurance management system200 (e.g., a computer server) that may be used according to an illustrative embodiment of the disclosure. The server201may have a processor203for controlling operation of various aspects of the insurance management system200and its associated components, including RAM205, ROM207, input/output module209, and memory215. The insurance management system200may include multiple servers201for controlling operation of respective aspects of the insurance management system.
I/O module209may include a microphone, keypad, touch screen, stylus, and/or other input sources through which a user of the server201may provide input, and may also include one or more of a speaker for providing audio output and a video display device for providing textual, audiovisual, and/or graphical output. Software may be stored within memory215to provide instructions to processor203for enabling server201to perform various functions. For example, memory215may store software used by the server201, such as an operating system217, application programs219, and an associated database221. Processor203and its associated components may allow the server201to run a series of computer-readable instructions to detect that a collision has occurred, identify the participants involved in the collision, determine which participant was at fault, and process any resulting insurance claims. The server201may operate in a networked environment supporting connections to one or more remote computers, such as terminals241and251. The terminals241and251may be personal computers or servers that include many or all of the elements described above relative to the server201. Also, terminal241or251may be data stores for storing data relating to the collision as well as the vehicles and participants involved in the collision. In yet other embodiments, terminals241and251may represent mobile devices respectively operated by the participants involved in the collision.
The network connections depicted inFIG. 2include a local area network (LAN) 225and a wide area network (WAN) 229, but may also include other networks such as a metropolitan area network (MAN) or a cellular network. When used in a LAN networking environment, the server201is connected to the LAN225through a network interface or adapter223. When used in a WAN or MAN networking environment, the server201may include a modem227, the network interface or adapter223, or other means for establishing communications over the WAN229 (or MAN), such as the Internet231. It will be appreciated that the network connections shown are illustrative and other means of establishing a communications link between the computers may be used. The existence of any of various well-known protocols such as TCP/IP, Ethernet, FTP, HTTP and the like is presumed.
Additionally, an application program219used by the server201according to an illustrative embodiment of the disclosure may include computer executable instructions for invoking functionality related to detect that a collision has occurred, identify the participants involved in the collision, determine which participant was at fault, and process any resulting insurance claims. As noted above, multiple servers201having respective application programs219may be employed to implement and invoke this functionality. The insurance management system201and/or terminals241or251may also be mobile terminals including various other components, such as a battery, speaker, camera, and antennas (not shown).
With reference toFIG. 3, a system300for implementing methods according to the present disclosure is shown. As illustrated, the system300may include one or more network devices301. The devices301may be local or remote, and are connected by one or more communications links302to a computer network303that is linked via communications links305to an insurance management system304. In certain embodiments, the network devices301may run different algorithms used by the insurance management system304for detecting that a collision has occurred, identifying the participants involved in the collision, determining which participant was at fault, and processing any resulting insurance claims. In yet other embodiments, the network devices301may represent mobile computing devices utilized by the participants involved in the collision to exchange communications relating to the collision. In system300, the insurance management system304may be one or more of any suitable server, processor, computer, or data processing device, or combination of the same.
Computer network303may be any suitable computer network including the Internet, an intranet, a metropolitan area network (MAN), a wide-area network (WAN), a local-area network (LAN), a wireless network, a digital subscriber line (DSL) network, a frame relay network, an asynchronous transfer mode (ATM) network, a virtual private network (VPN), or any combination of any of such networks. Communications links302and305may be any communications links suitable for communicating between the network devices301and the insurance management system304, such as network links, dial-up links, wireless links, hard-wired links, etc. The example method steps discussed below may be implemented by one or more of the components inFIGS. 2-3or other components, including other computing devices.
Referring now toFIG. 4, an example of an implementation of an insurance management system400for automatically detecting a vehicle collision, attributing fault, and processing insurance claims is shown. The insurance management system400is in signal communication with a vehicle402such that the insurance management system is capable of detecting a collision involving the vehicle and exchanging communications with the vehicle. The insurance management system400may also be in signal communication with one or more mobile computing devices404operated by the collision participants such that the insurance management system is capable of exchanging communications with the mobile computing devices.
The insurance management system400may receive data from the vehicle402including, for example, vehicle identification data, vehicle telematics data, collision data, and vehicle diagnostic data. In some example implementations, the insurance management system400may receive participant identification data (e.g., name, customer number, etc.) from the vehicle402as well. The vehicle402may include various components to collect and provide this data to the insurance management system400. It will be appreciated that these components may be interconnected and in signal communication with each other via various vehicle busses (not shown).
The vehicle402may include, for example, a collision response module (CRM) 406for coordinating the operation of the other vehicle systems, devices, and components in response to a collision involving the vehicle. As noted above a collision may be one type of physical disturbance event that can occur involving the vehicle. Accordingly, the collision response module406may additionally or alternatively referred to more broadly as a disturbance response module. In this regard, the collision response module406may be understood as a type of controller that interacts with various vehicle systems, devices, and components in order to obtain data that is utilized when responding to the collision. As an example, the collision response module406of the vehicle402may be in signal communication with: an automated collision notification device (ACN) 408that automatically detects vehicle collisions and provides notifications of a vehicle collision; a motor vehicle event data recorder (MVEDR) 410that records event data relating to the operation of the vehicle prior to or during a collision; and an on-board diagnostic unit (OBD) 412that monitors vehicle systems, devices, and components and provides diagnostic data relating to the health, status, or condition of these components. The CRM406, ACN408, MVEDR410, and ODB412may include one or more respective memories (not shown) for storing and retaining data relating to the condition, status, or operation of the vehicle402for both normal driving events and collision events. The CRM406of the vehicle402may additionally be in signal communication with one or more recording devices, e.g., audio recording equipment414and video recording equipment416 (A/V equipment) that respectively records audio data and video data at the vehicle. Furthermore the CRM406may be in signal communication with communication equipment418for transmitting the data from these components via a network to various systems, such as, for example, an insurance management system400. The communication equipment418of the vehicle402may be configured to wirelessly communicate via, for example, a cellular network or an internet protocol-based network (IP). It will be appreciated that the communication equipment418may be configured to wirelessly communicate using additional or alternative approaches for wireless communication.
The ACN408may include components for automatically detecting vehicle collisions and providing notifications of the vehicle collision. Those skilled in the art will recognize that these components may include, for example, one or more accelerometers420 (e.g., triaxial accelerometers) for detecting changes in the velocity of the vehicle402, a location determination device422such as a Global Positioning System (GPS) receiver for determining the geographic location of the vehicle, and communication equipment424for transmitting one or more collision notification messages. Based on the changes in velocity detected by the accelerometers420, the ACN408may determine that a collision has occurred. The ACN408may then prepare a collision notification message that includes, for example, vehicle identification data, GPS location data, and collision data. The communication equipment424of the ACN408may similarly be configured to communicate wirelessly, for example, via a cellular network or an IP-based network. The ACN408may transmit the collision notification information to, e.g., an insurance management system400. In some example implementations the ACN408may transmit the collision notification message directly to the insurance management system using the communication equipment of the ACN. In other example implementations, the ACN may transmit the collision notification message to the CRM406, which may in turn utilize the communication equipment418of the vehicle402to transmit a corresponding collision notification message to the insurance management system400. It will also be appreciated that in other example implementations, the vehicle402may respectively include the individual components of the ACN408 (e.g., the accelerometers420, the GPS receiver422, etc.) rather than the ACN itself and utilize these components in conjunction with the CRM406and the communication equipment418of the vehicle to detect and provide notifications of a collision.
The MVEDR410may also be referred to a vehicle “black box” (e.g., a crash-proof memory device) that records vehicle telematics data. Vehicle telematics data refers to technical information relating to the status or operation of the vehicle402prior to or during a vehicle event such as a collision or other physical disturbance event involving the vehicle. As noted above, individuals involved in or associated with the physical disturbance event may be referred to as participants, and participants may or may not be customers of an insurer that operates the insurance management system400.
Vehicle telematics data may include, for example, directional acceleration and deceleration (e.g., forward/backward, left/right, up/down), change in directional acceleration, vehicle speed or velocity, engine throttle and RPM (revolutions per minute), steering input, engagement of various vehicle subsystems (e.g., stability control systems, antilock brake systems), and the like. Those skilled in the art will appreciate that the MVEDR410may be configured to collect and record other types of data relating to the operation and status of the vehicle402prior to or during a vehicle event.
The OBD412is a system configured to continuously monitor various components of the vehicle402such as the powertrain, chassis, and body of the vehicle as well as various automotive devices. The OBD412may collect and report automotive diagnostic data in accordance with the OBD-II protocol standard. The OBD412may be in signal communication with an engine control unit (ECU) 424and the transmission control unit (TCU) 426of a powertrain control module (PCM) 428to monitor and record diagnostic data from these components. The OBD412 (as well as the ECU424and TCU426) may be in signal communication with various automotive sensors430throughout the vehicle402that provide sensor data relating to various systems, components, and devices of the vehicle including, for example, the engine, transmission, chassis, body, and the like. The sensors430may thus indicate the status and condition of these vehicle components. Sensors430may also include sensors that can detect the status and condition of the vehicle wheels and tires as well as sensors that can detect damage to the panels of the vehicle body, e.g., deformations, dents, punctures, and so forth. Those skilled in the art will appreciate that the automotive sensors430may include, for example, temperature sensors, pressure sensors, angular position sensors, linear position sensors, rotational motion sensors, inertial sensors, and the like.
As noted above, the vehicle402may transmit data from a vehicle to an insurance management system400. The insurance management system400may include various systems, subsystems, modules, and the like to facilitate automated detection of collisions, automated identification of participants, automated determination and attribution of fault, and automated insurance claims processing. The insurance management system400may include for example: a communication module432that exchanges communications with the vehicle and other remote systems and devices; a collision detection module434that automatically detects vehicle collisions; a participant identification module436that automatically identifies the participants involved in a vehicle collision; a fault determination module438that automatically determines which participant is at fault for the collision; a repair cost estimation module440that determines an estimated repair cost; and an insurance claims processing module442that automates aspects of the insurance claims process. The communication module may manage the communications exchanged between the modules of the insurance management system400and the vehicle402, mobile computing devices404, and remote systems. In this regard, the communication module432may function as the communication gateway for the insurance management system400. In some example implementations, the communication module432may include one or more web servers for managing the exchange of communications.
The insurance management system400may also include a storage module441having one or more data stores to facilitate automated collision detection, fault determination, and claims processing. The data stores of the storage module441may include, for example: a customer data store442that stores biographic or demographic information relating to insurance customers; a vehicle data store444that stores vehicle profile information; a policy data store446that stores the insurance policy information for the customers insured by the insurers; a vehicle telematics data store448that stores vehicle telematics information provided by the vehicles; an event data store450that stores information relating to collisions; a repair data store452that stores vehicle repair information; and a claims data store454that stores information relating to insurance claims. The data store440may also store a fault determination ruleset455used to determine which participant in a vehicle collision was at fault for the collision.
The customer biographic and demographic data may include, for example, customer name, address, contact information (e.g., mailing address, home phone number, mobile phone number, email address, etc.), date of birth, age, marital status, and so forth. Vehicle profile data may include information that identifies and describes a vehicle, for example, a vehicle make, model, year, color, vehicle identification number (VIN), vehicle classification, and so forth. The insurance policy data may include information describing the insurance coverage for an insured such as insurance premium information, deductible information, covered vehicles, coverage types, and coverage levels. Vehicle telematics data may include data relating to the movement and operation of a vehicle as discussed above with reference to the MVEDR410. Event data may include, for example, data identifying the date, time, and location (e.g., GPD coordinates) of the collision. Repair data may include repair estimates correlated with or otherwise associated with vehicle telematics data and vehicle diagnostic data. Repair data may also include estimates of total vehicle value.
A database management system (not shown) may implement an insurance management data model that models the relationships between the customer data, vehicle data, insurance policy data, vehicle telematics data, event data, repair data, and claims data stored in the data stores442-454of the storage module441. The insurance management data model may be implemented, for example, as one or more databases that define respective tables, attributes, and relationships corresponding to the insurance management data model. The data store may thus store and retain the data described above as respective related or unrelated records in accordance with the insurance management data model.
In addition to the vehicle402, the insurance management system400may be in signal communication with one or more mobile computing devices404operated by insurance customers or participants involved in a vehicle collision. A mobile computing device404may store and execute an insurance application456, and an individual may interact with the insurance application to carry out various insurance-related tasks. In this way, the insurance management system400may communicate with individuals such as customers and participants. The mobile computing device404may be a computing device configured to wirelessly communicate with the insurance management system400via a network. As noted above, in some example implementations, the mobile computing device may be, for example, a mobile cellular telephone.
The insurance management system400may also be in signal communication with one or more computing devices of one or more remote systems via a network. In this example, the insurance management system400is shown to be in signal communication with another insurance management system458, a system460of a repair service, a system462of a banking institution, a system464of a vehicle rental service, a system466of a vehicle tow service, and other third-party systems468. The interaction of the insurance management system400with these remote systems458-468will be discussed in further detail below.
Referring toFIG. 5a flowchart500of example method steps for automatically detecting vehicle collisions, determining fault, and managing insurance claims is shown. A collision detection module434 (FIG. 4) of an insurance management system400may detect that a collision between vehicles has occurred (step502). As discussed further below, the collision detection module434may detect the collision based on a collision notification message received from an ACN408or CRM406of a vehicle or, additionally or alternatively, based on an analysis of vehicle telematics data received from a vehicle402.
A participant identification module436of the insurance management system400may then attempt to identify the participants of the collision (step504). As discussed further below, the participant identification module436may attempt to identify the participants based, at least in part, on event data450obtained by the collision detection module434. The insurance management system400may then automatically notify the participants that a collision has been detected (step506). A communication module432of the insurance management system400may transmit an event notification message to the mobile computing devices404respectively operated by the participants. A participant may then be able to provide additional information relating to the collision in order to assist in the fault determination and claims processing procedures.
Having identified and notified the participants, a fault determination module438may attempt to automatically ascertain which participant was at fault for the collision (step508). The fault determination module438may employ a fault determination ruleset455to determine and identify the at-fault participant. The fault determination module438may analyze vehicle telematics data in accordance with the fault determination ruleset455to determine and attribute fault. Fault determination and attribution will be discussed in further detail below.
A repair cost estimation module440may then determine an estimated repair cost for the damage caused to a vehicle402associated with a participant involved in the collision (step510). The repair cost estimation module440may determine an estimated repair cost based on vehicle telematics data obtained by the MVEDR410of the vehicle402and diagnostic data452obtained by the OBD412of the vehicle. The communication equipment418at the vehicle402may transmit the vehicle telematics data and the diagnostic data452to the communication module432of the insurance management system400. The communication module432may then forward the vehicle telematics data and diagnostic data to the repair cost estimation module440for analysis.
Having estimated the cost to repair the damaged vehicle, a claims processing module442of the insurance management system400may process an insurance claim associated with one of the participants involved in the collision (step512). As noted above, the insurance claim may be filed against the at-fault participant for the participant that was not at fault, or the insurance claim may be filed for the at-fault participant. The insurance management system400may communicate with the participant via an insurance application456operating at mobile computing device404. The insurance management system400may exchange communications with the participant via the insurance application456to obtain additional information used when processing the insurance claim. In this way, the insurance management system400advantageously automates aspects of identifying and responding to collisions. Accordingly, it will be appreciated that some of the steps described above and in further detail below relating to identifying and responding to collisions may performed automatically or, alternatively, performed manually by an individual.
As noted above, the collision detection module434 (FIG. 4) of the insurance management system400may automatically detect collisions based on a collision notification message received from an ACN408or CRM406at a vehicle402as well as based on an analysis of vehicle telematics data received from the MVEDR410of the vehicle. InFIG. 6A, a flowchart600of example method steps for automatically detecting collisions via an ACN408is shown. In this example, an ACN408at the vehicle402detects a collision (step602). Accelerometers420may measure changes to the speed or velocity of the vehicle402. For example, the ACN408may determine that a collision has occurred where the vehicle402undergoes a change in velocity of around 8.0 kilometers per hour (km/h) within an interval of around 150 milliseconds (ms), i.e., a change in velocity of around 4.97 miles per hour (mph) within an interval of around 0.15 seconds.
Upon determination that a collision has occurred, the ACN408may collect data for inclusion in a collision notification message (step604). The ACN408may collect, for example, vehicle telematics data from the MVEDR410, vehicle identification data from the OBD412, and vehicle location data from the GPS receiver422. The ACN408may prepare a collision notification message that includes the vehicle telematics data, the vehicle identification data, and the vehicle location data (step606) and transmit the collision notification message to an insurance management system400 (step608). In some example implementations, the vehicle402may store data that identifies the individual that owns, operates, or is otherwise associated with the vehicle (e.g., a name, a unique identifier, etc.).
A communication module432of the insurance management system400may receive the collision notification message (step610) and forward the collision notification message to a collision detection module434 (step612). In response to receipt of the collision notification message, the collision detection module434may create and store a record of the collision. As an example, the collision detection module434may create a new collision record in the event data store450that corresponds to the collision (step614). The collision detection module434may also extract the vehicle telematics data, vehicle identification data, and vehicle location data from the collision notification message and store (or otherwise associate) this data with the event record corresponding to the collision.
The collision detection module434may, in some example implementations, request additional collision information or vehicle information from the vehicle402involved in the collision (step616). The collision detection module434may forward a request for additional information to the communication module432of the insurance management system400. The communication module432may then transmit the request to the vehicle402where it may be received, for example, at the vehicle communication equipment418or the ACN communication equipment424. In response to receipt of the request, the ACN408, MVEDR410, OBD412, CRM406, or another vehicle component may obtain the requested information, and the communication equipment418or424may transmit the requested information back to the insurance management system400.
Having detected the occurrence of a collision, the process to identify the participants in the collision may be initiated (step618). As noted above, the CRM406may additionally or alternatively be configured to prepare and transmit the collision notification message as described. Accordingly, the CRM406may be additionally or alternatively employed to perform the functions and purpose of the ACN408with regard to automatically detecting collisions.
Referring toFIG. 6B, a flowchart650of alternative example method steps for automatically detecting collisions is shown. In this alternative example, the collision detection module434of the insurance management system400automatically detects collisions. A vehicle402may continuously transmit vehicle telematics data to the insurance management system400where it may be received at the communication module432 (step652). The communication module432may forward the vehicle telematics data to the collision detection module434of the insurance management system400or to the vehicle telematics data store448of the storage module441 (step654). Similar to the approach set forth above, the vehicle telematics data received may include, for example, vehicle velocity or changes to velocity. The vehicle telematics data store448may store the vehicle telematics data such that it is related to or otherwise associated with vehicle identification data in the vehicle data store444that identifies the vehicle402from which the insurance management system400received the vehicle telematics data.
The collision detection module434may process and analyze the vehicle telematics data to determine whether a collision has occurred (step656). As an example, the collision detection module434may analyze the vehicle telematics data to determine whether a change in velocity occurred at the vehicle within a relative short time period, e.g., a change in velocity of 8 km/h within 150 ms. The collision detection module434may process and analyze the vehicle telematics data as it is received from the vehicle402or at periodic intervals (e.g., every 30 seconds) after having stored the vehicle telematics data in the vehicle telematics data store448.
If the collision detection module434does not detect a collision (step658), then steps652-656may be repeated until a collision is detected. If the collision detection module434does detect a collision (step658), then the collision detection module may create a record of the collision (step660). As noted above, the collision detection module may create a new collision record in the event data store450that corresponds to the collision. The collision detection module434may associate the vehicle telematics data stored at the vehicle telematics data store448with the event record stored at the event data store450. Having associated the vehicle telematics data with the vehicle identification data in the vehicle data store444, the event data associated with the vehicle telematics data is thus also associated with the vehicle identification data.
In some example implementations, the collision detection module434may attempt to obtain additional information from a vehicle402involved in the collision. This additional information may include, for example, the vehicle telematics data corresponding to the collision and data identifying the vehicle involved in the collision. Accordingly, the collision detection module434may transmit a request to the vehicle402involved in the collision for additional event or vehicle data (step662), and receive the requested data from the vehicle in a response (step664). As noted above, an insurance management data model may define the relationships between the event and vehicle data received. The event data may include, e.g., the time, date, and location of the collision as well as vehicle telematics data corresponding to the collision; and the vehicle data may include, e.g., vehicle identification data and vehicle diagnostic data. In this way, the insurance management system400may utilize the event and vehicle telematics data when determining the participants involved in the collision, determining which participant is likely at fault for the collision, and estimating the vehicle repair cost. Having received the event data and vehicle telematics data, the insurance management system400may store the data in the respective data stores450and448 (step666) and initiate determination of the participants involved in the collision (step668).
The participant identification module436 (FIG. 4) of the insurance management system400may automate aspects of the process of identifying the participants involved in a vehicle collision. Automated participant identification advantageously streamlines the process of handling, responding to, and processing information about the collision. Referring toFIG. 7, a flowchart700of example method steps for automatically identifying participants involved in a vehicle collision is shown.
Upon determination that a collision has occurred (step702), a participant identification module436of the insurance management system400may attempt to identify the participants involved in the collision. As noted above, the insurance management system400may determine that a collision has occurred by receiving a collision notification message from an ACN408or CRM406installed and operating at a vehicle402or, additionally or alternatively, based on vehicle telematics data collected from the vehicle and analyzed at a collision detection module434. The participant identification process described below assumes that at least one of the participants is a customer of the insurer that operates the insurance management system400such that the storage module441of the insurance management system400includes customer and vehicle data corresponding to the participant. In some example implementations, the collision notification message received from the vehicle402may directly identify the participant where the notification message includes participant identification information, e.g., a name of the individual associated with the vehicle, a customer number, an insurance policy number, or some other unique identifier. In these embodiments, the participant identification module436may query the customer data store442or the policy data store446using the participant identification information included in the collision notification message.
In other example implementations, the participant identification module436may attempt to identify a participant indirectly based on vehicle identification data included in the collision notification message. Accordingly, the participant identification module436may obtain the vehicle identification data associated with the vehicle involved in the collision (step704), e.g., vehicle identification data, such as a VIN, included in the collision notification message. The participant identification module436may extract the vehicle identification data from the collision notification message and query the vehicle data store444using the vehicle identification data. Additionally or alternatively, the vehicle identification data may be included with or otherwise associated with the vehicle telematics data provided by the vehicle402.
The participant identification module436may then query the customer data store442for the customer data associated with the vehicle identification data (step706). As noted above, the insurance management data model may define relationships between the customer data and vehicle data enabling the participant identification module436to lookup customer data based on vehicle data. The participant identification module436may then associate the customer with the collision (step708), e.g., by associating the customer record for the participant with the event record for the collision.
The participant identification module436may be configured to identify each participant involved in a collision. Accordingly, the participant identification module436may attempt to match an event record for the collision with a corresponding event record (step710). The participant identification module436may identify matching event records based on the event data received from the vehicles involved in the collision, e.g., the time, date, and location of the collision. In particular, the participant identification module436may determine whether two events have matching times, dates, and locations. If the respective time, date, and location of the event records are the same, then the participant identification module436may determine that the event records are associated with and refer to the same collision.
If the participant identification module436identifies a matching event record (step712), then a participant associated with the matching event record is also likely insured by, e.g., a customer of, the insurer that operates the insurance management system400. Accordingly, the participant identification module436may determine that the corresponding participant is a customer (step714) and query the customer data store442and vehicle data store444for the customer data vehicle data associated with the corresponding participant and vehicle involved in the collision (step716). The participant identification module436may thus associate the each of the participants with the collision, e.g., by associating the customer records for the participants with the event records for the collision. In this way, the participant identification module436associates the incident with each participant involved in the incident (step718). The participant identification module436may repeat steps710-718to associate additional participants with the collision.
If both participants are insured by the insurer, then the insurer may automatically provide respective insurance information to each participant. The participant identification module436may retrieve the insurance information for the first participant and the insurance information for the second participant from the insurance policy data store446. The participant identification module436may then automatically transmit the insurance policy information for the first participant to the second participant and transmit the insurance policy information for the second participant to the first participant. The insurance policy information may be received at the respective insurance applications456operating at the mobile computing devices404of the participants. In this way, the insurance management system400automates the exchange of insurance information between participants in response to detection of a vehicle collision.
In some situations, one of the participants involved in the collision may not be a customer of the insurer that operates the insurance management system400. As a result, the participant identification module436may not be able to identify a matching event record in the event data store450. If the participant identification module436cannot identify a matching event record in the event data store450 (step712), then the participant identification module may determine that the corresponding participant is not a customer of the insurer (step720) and attempt to identify the corresponding participant using alternative approaches. For example, other insurance companies may maintain insurance management systems458that also include a collision detection module and store event records for collisions. As noted above, the insurance management systems400and458may be remote relative to one another and in signal communication with each other via a network. The participant identification module436may transmit a request to a remote insurance management system458to determine whether the remote insurance management system includes an event record matching the detected collision (step722). The participant identification module436may include the event data for the collision in the request.
The remote insurance management system458may utilize the event data received from the participant identification module436when attempting to identify a matching event record, e.g., an event record having a matching time, date, and location. If the remote insurance management system458identifies a matching event record (step724), then the remote insurance management system may retrieve the customer, vehicle, and insurance policy data associated with the corresponding participant and transmit a response to the participant identification module436that includes this data. The insurance management system400may receive the data associated with the corresponding participant from the remote insurance management system458 (step726). The participant identification module436may store the data for the corresponding participant at the storage module441and associate the data for the corresponding participant with the event record for the collision.
If the remote insurance management system458cannot identify a matching event record, then the participant identification module436may repeat steps722-724to query other remote insurance management systems in an attempt to locate a matching event record for the collision. If a matching event record also cannot be located at other remote insurance management systems, the participant identification module436may transmit a request to one of the identified participants that prompts the identified participant to obtain the information from the corresponding participant involved in the collision (step728). The participant identification module436may transmit the request via the communication module432, and the request may be received at the insurance application456operating at the mobile computing device404of the identified participant. Prompted by the request, the identified participant may obtain the participant, vehicle, and insurance information from the corresponding participant (step730). In some example implementations, the corresponding participant may automatically transmit the participant, vehicle, and insurance information using a mobile computing device404. For example, the respective mobile computing devices404of each user may store participant, vehicle, and insurance data, and this data may be wirelessly exchanged between the mobile computing devices where the exchange is initiated by touching the mobile computing devices together.
Upon receipt of the information from the corresponding participant, the insurance application456may transmit the information to the insurance management system400where the participant identification module436may receive the information via the communication module432 (step732). The participant identification module436may store the participant, vehicle, and insurance information received in the storage module441and associate the information with the event record for the collision (step718). In some example implementations, once both participants have been identified, the participant identification module436may transmit a notification to each identified participant (step734). The notification message may indicate that the collision was detected, that the participants were identified, and that the insurance management system400is automatically processing a response to the collision. The notification message may also include the respective insurance information for the participants (e.g., name of insurer, insurance policy number, etc.). The communication module432of the insurance management system400may transmit the notification message to the insurance applications456at the mobile computing devices400. An insurance application456may also be configured to enable a participant to indicate that there were no additional participants involved in the collision, e.g., that the collision involved the participant and a stationary object such as a wall or parked vehicle. Once the participant identification module436determines the participants involved in the collision, the participant identification module may initiate an attempt to determine which one of the participants was at fault for the incident (step736).
The insurance management system400 (FIG. 4) may include a fault determination module438that automates aspects of determining and attributing fault to one of the participants involved in the collision. Referring toFIG. 8, a flowchart800of example method steps for automatically determining and attributing fault to one of the participants is shown. Once the participant identification module436identifies the participants involved in a collision (step801), a fault determination module438may attempt to determine which participant involved in the incident is the at-fault participant. The at-fault participant may be the participant to which liability for the collision is assigned. As discussed further below, the fault determination module438may determine a respective fault probability for each participant involved in the collision and identify one of the participants as the at-fault participant based on the fault probabilities. A fault probability may be a value (e.g., a percentage) that quantifies the likelihood a participant is the at-fault participant.
The automated fault determination438module may receive event information from the respective MVEDRs410of the vehicles402involved in the collision (step802). The fault determination module438may receive the event data via the communication module432of the insurance management system400. In some example implementations, the fault determination module438may obtain supplemental driving data related to the participants involved in the collision (step804). The supplemental driving data may include, for example, driver history data and claim history data respectively associated with the participants. Driving history data may indicate previous incidents that the drivers have been involved in or citations the driver has received for moving violations. Claim history data may indicate, for instance, previous insurance claims filed against the participant. The fault determination module438may obtain the driving history data or the claim history data from respective data stores of the storage module441or, additionally or alternatively, in response to requests for the supplemental driving data from one or more remote third-party systems468in signal communication with the insurance management system400.
The fault determination module438may analyze the event data and the supplemental driving data to identify the at-fault participant and to determine the fault probability values (step806). The fault determination module438may apply a fault determination ruleset456 (step808) when analyzing the event data and supplemental driving data. The fault determination ruleset may be configured, for example, to apply the rules of the road to the vehicle telematics received from the vehicles. In one example, the vehicle telematics data may indicate that prior to the collision, one of the vehicles made a left turn in front of an oncoming vehicle. Based on the telematics data, in this example, the fault determination ruleset may indicate that the left-turning vehicle is at fault or at least likely to be at fault. In another example, the vehicle telematics data may indicate that prior to the collision, one of the vehicles was moving and the other vehicle was not moving. Based on the vehicle telematics data, in this other example, the fault determination ruleset may indicate that the moving vehicle is at fault or at least likely to be at fault. In an additional example, the vehicle telematics data may indicate that prior to the collision, one of the vehicles was exceeding the speed limit. Based on the vehicle telematics data, in this additional example, the fault determination ruleset may indicate that the speeding vehicle is likely to be at fault. In response, the fault determination module may increase the probability that the speeding vehicle was at fault. In a further example, the vehicle telematics data may indicate that prior to the collision, each vehicle was moving but one of the vehicles suddenly decelerated causing the other vehicle to collide with the vehicle. In this further example, the fault determination ruleset may indicate that the decelerating vehicle is at fault or at least likely to be at fault. Historical data may also be employed as a factor to determine fault. For example, if the historical data indicates that one of the individuals has been more at fault in previous accidents, then the fault determination module may initially guess that the individual is at fault for a present accident. Accordingly, the fault determination ruleset may be implemented, for example, as a decision tree or decision table, using conditional statements or switch statements, and combinations thereof. It will be appreciated that various approaches may be selectively employed for implementing the fault determination ruleset.
Based on the fault determination ruleset456, the fault determination module438may generate one or more fault probability values that respectively indicate the likelihood each participant is at fault for the collision (step810). The fault determination module438may then attribute fault to one of the participants based on the fault probability values (step812). As an example, the fault determination module438may attribute fault to the participant associated with the higher fault probability value.
In some example implementations, the fault determination module438may be configured to determine that fault cannot be accurately attributed to one participant over the other. For example, the fault determination module438may conclude that fault cannot be attributed where the fault probability values for each participant are equal or where the difference between the fault probability values does not exceed a predetermined threshold. As an example, the fault determination module438may conclude that fault can be accurately attributed where the respective fault values are 75% likelihood of fault versus 25% likelihood of fault—a fifty percentage point difference—but that fault cannot be accurately attributed where the respective fault values are 53% likelihood of fault versus 47% likelihood of fault—only a six percentage point difference. Example implementations of the fault determination module may be configured to determine that fault can or cannot be determined using additional or alternative thresholds.
If the insurer that operates the insurance management system insures the at-fault party (step814), then the fault determination module438may assign liability to the insurer, create an insurance claim for the claimant (step816), and process the insurance claim (step818). Processing the insurance claim may include, for example, estimating the cost of repairs for damage to the vehicle associated with the claimant and providing a settlement offer to the claimant. Processing an insurance claims will be discussed in further detail below.
If the insurer does not insure the at-fault participant (step814), e.g., where a third-party insurer insures the at-fault participant, the fault determination module438may assign liability to the at-fault participant (step820) and contact a third-party insurer that insures the at-fault participant to confirm the determination and attribution of fault. The fault determination module438may transmit the event data and fault probability values to a remote insurance management system458of the third-party insurer (step822). The remote insurance management system458may also be configured to automatically determine fault based on the event data, supplemental driving data, and a fault determination ruleset. In some circumstances, the remote insurance management system458may be configured to apply the same fault determination ruleset as the fault determination module438. In other circumstances, the remote insurance management system458may apply an alternative fault determination ruleset to identify the at-fault participant.
The remote insurance management system458of the third-party insurer may likewise analyze the event data and supplemental driving data to identify the at-fault participant. The third-party insurer may transmit a fault determination response back to the fault determination module438indicating whether the third-party insurer agrees with the determination that the at-fault participant is insured by the third-party insurer. The fault determination module438may analyze the response from the remote insurance management system458to determine whether the third-party insurer agrees with the determination and attribution of fault (step824). If the remote insurance management system458indicates disagreement with the determination and attribution of fault, e.g., if there is a dispute over fault (step826), then typical claim subrogation procedures may be initiated to determine whether the insurer or the third-party insurer should assume liability for the incident (step828). If, however, the third-party insurer agrees that the participant insured by the third-party is at fault, e.g., if there is not dispute over fault (step826), then the fault determination module438may automatically assign liability to the third-party insurer (step830), create an insurance claim for the claimant (step816), and process the insurance claim (step818). Automatically creating a claim for the claimant may include automatically filing a claim against the at-fault participant. It will be appreciated that a claim may also be automatically created and filed for the at-fault participant. As noted above, processing the claim may include estimating a total repair cost and providing a settlement offer. Where liability for the collision is assigned to the third-party insurer, processing the claim may also include subrogation of the insurance claim.
As noted above estimating the cost to repair the damage to a vehicle402 (FIG. 4) involved in the collision may be part of the claims processing procedure. The insurance management system400may include a repair cost estimation module440that automates aspects of the repair cost estimation process. FIG. 9shows a flowchart900of example method steps for automatically estimating vehicle repair cost. Having detected that a collision has occurred (step902), the repair cost estimation module440may initiate the process of estimating the cost to repair the vehicle402involved in the collision. The repair cost estimation module440may determine a total estimated repair cost based at least in part on diagnostic data and vehicle telematics data provided by the vehicle402involved in the collision. As discussed above, the OBD412of the vehicle402may provide the diagnostic data and the MVEDR410may provide the vehicle telematics data. The repair cost estimation module440may transmit a request to the vehicle402for the diagnostic and vehicle telematics data in response to detecting a collision involving the vehicle (step904). Additionally or alternatively, the vehicle402may be configured to automatically transmit the diagnostic and vehicle telematics data to the insurance management system440in response to a collision detected at the vehicle. The diagnostic and vehicle telematics data may be received at the repair cost estimation module440via the communication module432of the insurance management system (step906). The storage module441of the insurance management system400may store the diagnostic data in the repair data store452and the vehicle telematics data in the vehicle telematics data store448. The diagnostic data and vehicle telematics data may be associated with the event record for the collision such that the repair cost estimation module440may query the respective data stores for the data during the cost estimation process.
The repair cost estimation module440may analyze the diagnostic and vehicle telematics data (step908). Analysis of the diagnostic data and vehicle telematics data may include comparing the diagnostic data and vehicle telematics data received from the vehicle402to repair data stored in the repair data store452of the insurance management system400. The repair data may represent reference information that associates diagnostic data and vehicle telematics data with repair cost estimates. The repair cost estimation module440may query these repair cost estimates from the repair data store452based on the diagnostic data and vehicle telematics data received from the vehicle402 (step910). As noted above, the diagnostic data may include information that identifies which vehicle systems, components, and parts were damaged in the collision. The repair data store452may include repair estimates that indicate the cost of repairing or replacing the various systems, components, and parts of a vehicle. Accordingly, the repair cost estimation module440may retrieve the repair estimates for the any damaged systems, components, or parts identified in the diagnostic data and determine a total estimated repair cost based, at least in part, on those repair estimates.
Additionally or alternatively, the repair cost estimation module440may estimate a total repair cost based, at least in part, on the vehicle telematics data received from the vehicle402. The repair data store452may include repair estimates that are correlated with vehicle speeds. The repair cost estimation module440may determine the speed at which the vehicle was traveling when the collision occurred based on the vehicle telematics data received from the vehicle402. The repair cost estimation module440may query the repair data store452for repair estimates that correlate to the speed of the vehicle402when the collision occurred.
The repair cost estimation module440may determine a total repair estimate based on the diagnostic data and the vehicle telematics data individually or in combination. The repair cost estimation module440may also use additional or alternative types of data individually or in combination with the diagnostic and vehicle telematics data to determine a total repair estimate. As noted above, the repair cost estimation module440may obtain repair estimates from the repair data store452of the insurance management system440. Additionally or alternatively, the repair cost estimation module440may retrieve repair estimate from a remote third-party system468via a network. In these situations, the repair cost estimation module440may transmit via the communication module432the diagnostic data, vehicle telematics data, or other data to the remote third-party system468and receive repair estimates from the remote third-party system in response.
Based on the repair estimates received, the repair cost estimation module440may generate a total estimated repair cost for the vehicle402involved in the collision (step912). The repair cost estimation module440may then transmit via the communication module432a repair cost message that includes the total estimated repair cost (step914). An insurance application456operating at the mobile computing device404of the participant may receive the repair cost message and display the total estimated repair cost to the participant. It will be appreciated that the repair cost estimation module440may estimate the cost to repair any of the vehicles involved in the collision including the vehicle of the at-fault participant as well as the vehicle of the participant that was not at fault. It will be appreciated that aspects of the disclosure may be applicable to other types of insured items. For example, sensors may detect when a window breaks such that a claim may automatically be generated.
The insurance management system400 (FIG. 4) may include a claims processing module442that automates other aspects of the claims processing procedure. Referring toFIG. 10, a flowchart1000of example methods steps for automating aspects of the claims processing procedure is shown. As noted above, the claims processing procedure may include automatically creating an insurance claim for a claimant (step1002) and automatically determining a total estimated repair cost for the damaged vehicle402 (step1004). As discussed further below, the claims processing procedure may include providing a settlement offer to one of the participants. As used in the description below, a claimant may be a participant for whom an insurance claim has been created as well as a participant to whom a settlement offer is provided. The claimant may or may not be the at-fault participant and may be insured by the insurer that operates the insurance management system400or by a third-party insurer.
When processing insurance claims, the claims processing module442may determine whether the total estimated repair cost exceeds the total value of the vehicle402 (step1006). The claims processing module442may obtain a total estimated value of the vehicle based on vehicle profile data for the vehicle402 (e.g., make, model, year, mileage, etc.). The repair data store452of the storage module441may include market value price estimates for vehicles of various makes, models, and years having various mileage readings. Additionally or alternatively, the claims processing module442may obtain the market value price estimates from a remote third-party system468via a network. The claims processing module442may provide the vehicle profile data to the remote third-party system468and receive the market value price estimates in response.
If the total estimated repair cost exceeds the total estimated value of the vehicle402 (step1008), then the claims processing module442may determine that the vehicle is a total loss (step1010). When the damaged vehicle402is determined to be a total loss, the claims processing module442may automatically initiate transmission of a tow service request to the system466of a vehicle tow service (step1012). The tow service request may include the geographic location of the vehicle402. In response to receipt of the tow service request, a tow service provider may dispatch a tow truck to the geographic location of the vehicle402in order to retrieve the damaged vehicle. The claims processing module442may also automatically initiate transmission of a vehicle rental request to the system464of a remote vehicle rental service (step1014). The rental request may include the geographic location of the claimant. In response to receipt of the rental request, a vehicle rental service provider may dispatch a rental vehicle to the geographic location of the claimant in order to deliver the rental vehicle to the claimant.
If the total estimated repair cost does not exceed the value of the vehicle402, then a settlement offer may be provided to the claimant. Before the claims processing module442provides a settlement offer to the claimant, the claims processing module may determine whether the claimant is insured by the insurer (step1016). In this way, the claims processing module442may determine whether the total estimated repair cost exceeds the deductible for the claimant (step1018). If the claimant is insured by the insurer (step1016) and the total estimated repair cost exceeds the deductible for the claimant (step1020), then the claims processing module442may not provide a settlement offer to the claimant. Instead, the claims processing module442may transmit a repair cost message to the claimant (step1022) that indicates the total estimated repair cost and identifies the insurance deductible of the claimant. The claims processing module442may transmit the repair cost message to the insurance application456at the mobile computing device404of the claimant.
The claims processing module442may also attempt to identify repair service centers located near the claimant and provide a list of repair service centers within a predetermined radius (e.g., 5 miles) of the claimant (step1024). The insurance application456operating at the mobile computing device404may receive and display the list of recommended repair service centers. The claims processing module442may utilize the location data received from the vehicle402to identify repair service centers located within a predetermined radius (e.g., 5 miles) relative to the location of the claimant. The repair data store452of the storage module441may also store information relating to repair service centers and their corresponding geographic locations. The claims processing module442may query the repair data store452for a list of repair service centers in the vicinity of the claimant based on the geographic location of the claimant. Additionally or alternatively, the list of repair service centers may be stored at a remote third-party system468, and the claims processing module442may retrieve the list of repair service centers the vicinity of the claimant from the remote third-party system468via a network. In some example implementations, the claims processing module may identify one or more of the repair service centers as a preferred repair service center. The insurance application may be configured to receive a selection from the user (e.g., via a button) indicating which repair service center the user intends to patronize. The insurance application may transmit the selection to the insurance management system, and the insurance management system may apply a discount to the insurance policy for the customer as a reward for selecting a preferred repair service center.
The claims processing module442may also be configured to automate some steps of the claims resolution process including, for example, automatically determining a settlement offer for the claimant (step1026). The claims processing module442may determine a settlement offer for the claimant where, for example, the vehicle is a total loss (step1008), where the total estimated repair cost exceeds the deductible for the claimant (step1020), or where the claimant is not insured by the insurer (step1016). The claims processing module442may determine the settlement offer based, at least in part, on the total estimated repair cost. The claims processing module442may provide the settlement offer to the claimant (step1028), e.g., by transmitting a settlement offer to the insurance application456at the mobile computing device404of the claimant. The insurance application456may display the settlement offer to the claimant and prompt the claimant to either accept or reject the settlement offer.
The claimant may provide user input indicating whether the claimant accepted or rejected the settlement offer, and the insurance application456may transmit the user input back to the claims processing module442. If the user input indicates that the claimant did not accept the settlement offer (step1030), then the claims processing module442may update the insurance claim to indicate the claimant rejected the settlement offer (step1032) and the typical claims resolution process may proceed.
If the user input indicates that the claimant accepted the settlement offer (step1030), then the claims processing module442may initiate a transfer of funds into a bank account associated with the claimant (step1034). The claims processing module442may transmit a request to the system462of a banking institution to transfer funds corresponding to the settlement offer from a bank account associated with the insurer to the bank account associated with the claimant. Upon confirmation from the banking system462that the funds have been transferred, the claims processing module442may transmit a deposit notification message to the claimant indicating that the settlement funds have been deposited into the bank account associated with the claimant (step1036). The insurance application456at the mobile computing device404may receive the deposit notification message and display the message to the claimant.
Although an insurer provides a settlement offer to a claimant, the insurer may not be liable for the collision. For example, if the insured is not the at-fault party, e.g., if the at-fault party is insured by a third-party insurer, the insurer may provide the settlement funds to the insured and then proceed with subrogation to recover the settlement funds from the third-party insurer. Accordingly, the claims processing module442may additionally determine whether the insurer insures the at-fault participant (step1038) in order to determine whether the insurer should proceed with subrogation. If the insurer insures the at-fault participant, then there may be no need for subrogation as liability may already be assigned to the insurer. In this regard, where the insurer insures the at-fault participant, the claims processing module442may flag the insurance policy of the at-fault participant such that the insurer may subsequently reassess the insurance policy (step1040), e.g., by applying penalties or adjusting insurance premiums upon renewal.
Where the insurer does not insure the at-fault participant, the insurer may engage in subrogation with the third-party insurer. The claims processing module442may be configured to automate aspects of the subrogation process. For example, if there is no dispute over fault attribution (step1042), the claims processing module442may transmit a request to a remote insurance management system458operated by the third-party insurer (step1044). In response to receipt of the request, the third-party insurer may provide funds to reimburse the insurer for the settlement funds provided to the claimant. The insurer may receive the reimbursement funds (step1046) via, for example, a transfer of the reimbursement funds from a bank account associated with the third-party insurer to a bank account associated with the insurer. The claims processing module442may receive a deposit notification message from the remote insurance management system458indicating the transfer of funds. In response to receipt of the deposit notification from the remote insurance management system458, the insurance management system400may designate or identify the insurance claim as closed or settled. In this way, the claims processing module442of the insurance management system400may advantageously subrogate insurance claims with a third-party insurer automatically. If there is a dispute over fault (step1042), then the claims processing module442may initiate typical subrogation procedures (step1048).
The claims processing module442may additionally or alternatively be configured to allocate settlement payments between the insurer and third-party insurers. In some example embodiments, the insurance management system may charge a settlement fee when a claim is settled using the system. The insurance management system may also employ the fault determination probabilities to determine respective portions of a settlement payment shared between one insurer and another insurer. As an example, if the insurers agree that one of the drivers was 35% at fault and the other driver was 65% at fault, then one of the insurers may agree to provide 35% of the settlement payment, and the other insurer may agree to provide 65% of the settlement payment. Furthermore, in some example embodiments, insurers may maintain debit/credit accounts, and the claims processing module may initiate a credit or debit to the respective accounts for the insurers. Accordingly, in this example, payments between insurers may be a matter of bookkeeping in which the accounts indicate how much money one insurer owes to or is owed by another insurer. Actual payments may thus be provided or received at periodic intervals based on the balances of the debit/credit accounts.
Referring toFIG. 11, a flowchart1100of example method steps for detecting and responding to a physical disturbance event (e.g., a collision) involving a parked vehicle is shown. The description below refers to a collision event by way of example, but aspects of the disclosure may be applicable to other types of physical disturbance events. The detection and response components of a parked vehicle may be configured to detect and respond to a collision at the vehicle (step1102) even when the vehicle is parked. As an example, a CRM406 (FIG. 4) of the vehicle402may be configured to enter a low power mode (e.g., a sleep mode, a standby mode, a hibernation mode) when the vehicle is parked. In response to receipt of a notification that a collision has occurred at the vehicle402, the CRM406may enter an active mode (e.g., resume, wake up) in order to respond to the vehicle collision.
The accelerometers420of the ACN408or other sensors430at the parked vehicle402may detect a collision as described above. In response to the collision, the ACN408or other sensors430may provide a notification to the CRM406that a collision has occurred. In response to receipt of the notification, the CRM406may carry out various steps in order to respond to the collision. It will be appreciated that the ACN408or other sensors may provide notification of a collision that has occurred at the vehicle402when the vehicle is both running and not running as well as when the vehicle is both moving and not moving.
As shown by way of example inFIG. 11, the CRM406may determine if the vehicle402was running when the disturbance event occurred (step1104), e.g., by querying the OBD412or MVEDR410. If the vehicle402was running when the disturbance event occurred (step1106), then the CRM406may determine that the vehicle402was not parked when the disturbance event occurred (step1108), e.g., that the vehicle was moving, stopped, or standing when the disturbance event occurred. If the CRM406determines that the vehicle402was not running when the disturbance event occurred (step1106), then the CRM may determine whether the vehicle was moving when the disturbance event occurred (step1110). The CRM406may determine whether the vehicle402was moving also, e.g., by querying the OBD412or MVEDR410. If the CRM406determines that the vehicle402was moving but not running when the disturbance event occurred (step1112), then the CRM may determine that the vehicle is being towed or stolen (step1114). If the CRM406determines that the vehicle402was not moving (step1112) and not running (step1106) when the disturbance event occurred, then the CRM may thus determine that the vehicle was parked when the disturbance event occurred (step1116).
In response to detection of the disturbance event, the CRM406may initiate various steps in order to respond to the disturbance event. The CRM406may, for example, activate one or more recording devices414or416at the vehicle402 (step1118), e.g., the A/V equipment, to record the area surrounding the vehicle for a period of time following the disturbance event (step1120). The recording devices414or416may record the area surrounding the vehicle402following detection of the disturbance event for a predetermined period of time, e.g., for 30 seconds after detection of the disturbance event. In this way, the recording devices414or416may capture and retain information regarding the circumstances of the disturbance event including possibly information identifying a vehicle that collided with the parked vehicle402 (e.g., a license plate, vehicle make, model, color, etc.), information identifying an individual tampering with the vehicle, or information indicating that the vehicle is being towed or stolen. It will be appreciated that the recording devices414or416may also be employed to record audio or video for collisions detected when the vehicle is moving.
The CRM406may also generate and transmit a collision notification message to an insurance management system400 (step1122). The collision notification message may include information relating to the vehicle402and the collision including, for example, vehicle identification data (e.g., VIN, make, model, year, etc.), location data (e.g., GPS coordinates), event data (e.g., audio or video recordings), and diagnostic data. The communication equipment418at the vehicle402may transmit the collision notification message to the insurance management system40via a network (e.g., cellular, IP-based, etc.) The communication module432of the insurance management system400may receive the collision notification message and forward the message to other modules at the insurance management system for further processing.
As an example, the insurance management system400may leverage the GPS data received from the vehicle to identify high-risk areas based on what type of area it is. For example, the insurance management system may identify highly dense urban areas as relatively riskier compared to less dense rural areas. As another example, the insurance management system may identify large parking lots in commercial areas as relatively riskier compared to driveways in residential areas. The insurance management system400may also leverage the velocity of impacts to identify relatively high-risk areas. For example, areas in which low velocity impacts occur may be less risky than areas in which high velocity impacts occur. It will be recognized that the insurance management system may leverage additional or alternative types of information from the vehicles to identify additional or alternative aspects of the areas in which the vehicles travel and reside.
The participant identification module436of the insurance management system400may identify the owner of the parked vehicle402based, e.g., on the vehicle information (e.g., the VIN) as discussed above. The participant identification module436may retrieve the contact information for an individual associated with the parked vehicle402 (e.g., an email address, a cellular phone number, etc.) and provide a collision notification message to that individual (step1124). In some example implementations, the CRM406may be configured to transmit the collision notification message directly to the individual associated with the parked vehicle402. The CRM406may store and retain the contact information for the individual and utilize this contact information to contact the individual directly in response to detecting a collision at the vehicle402. The insurance application456at the mobile computing device404of the individual may receive and display the collision notification message. In response to receipt of the collision notification message, the individual may return to the vehicle402in order to assess any damage, engage with the at-fault participant to exchange insurance information, and initiate insurance claims.
In some example implementations, receipt of the collision notification message at the insurance management system400may trigger automatic identification of the participants involved in the collision (step1126), automatic selection of one of the participants as the at-fault participant (step1128), and automatic claims processing for insurance claims associated with the collision (step1130), e.g., an insurance claim against the at-fault participant. The participant identification module436of the insurance management system400may be configured to identify the at-fault participant that collided with the parked vehicle402. If the vehicle associated with the at-fault participant is also configured to communicate with an insurance management system (e.g., insurance management system400or458) as described above, then the participant identification module436may identify the at-fault participant based on a collision notification message or vehicle telematics data received from the vehicle associated with the at-fault participant.
The participant identification module436may also be configured to identify the at-fault participant based on the recording obtained by the parked vehicle402. As an example, the parked vehicle402may provide the recording obtained after the collision occurred to the insurance management system400, and the insurance management system may process the recording to extract information identifying the vehicle that collided with the parked vehicle. The participant identification module436may, for example, employ various image-processing techniques to extract the license plate number of the vehicle and query a third-party system468for information identifying the individual associated with the vehicle. Having identified the participant associated with the moving vehicle, the fault determination module438of the insurance management system400may select the individual associated with the colliding vehicle as the at-fault participant. The claims processing module442may thus automatically file an insurance claim against the at-fault participant.
In some example implementations, the disclosures described above may be employed to distinguish between prior damage to the parked vehicle and current damage to the parked vehicle caused by the collision. For example, the insurance management system400may be employed to identify prior damage to a vehicle that did not occur as a result of a recent collision. As an example, the vehicle sensors may indicate that damage to the right front bumper occurred prior to the collision (e.g., using timestamp information associated with sensor readings). If the recent collision resulted in damage to the left front bumper, then the insurance management system may thus determine that only the damage to the left front bumper was due to the collision with the damage to the right front bumper being prior damage. The insurance management system may also employ the sensor readings to determine the likelihood of damage caused by a collision. For example, if the vehicle sensors detect a low velocity impact at the rear of the vehicle such that the vehicle moved forward without backward recoil, then the insurance management system may determine that no impact occurred at the front of the vehicle. As a result, the insurance management system may determine that any damage at the front of the vehicle is not due to the recent collision. It will be recognized that the insurance management module may be configured to identify current damage from previous damage in additional or alternative situations.
In further example implementations, the disclosures described above may be employed to detect fraud. Because the insurance management system400may be configured to distinguish current damage from previous damage as described above, the insurance management system may also be able to detect attempts at fraud. For example, if an individual claims previous damage as current damage, the insurance management system may flag the claim as fraudulent. As another example, if the velocity information provided by the vehicle do not correlate with the amount of damage claimed by the individual, then the insurance management system may also flag the claim as fraudulent. It will be recognized that the information received from the vehicle may be employed by the insurance management system to identify additional or alternative types of fraudulent activities.
340/426.1, 340/428, 340/429, 340/426.18, 340/426.19, 340/436, 701/300, 701/301, 705/4