U.S. patent application number 15/727972 was filed with the patent office on 2018-02-01 for method for smartphone-based accident detection.
The applicant listed for this patent is Zendrive, Inc.. Invention is credited to Romit Choudhury, Bipul Islam, Jonathan Matus, Jayanta Pal, Pankaj Risbood, Vishal Verma.
Application Number | 20180033220 15/727972 |
Document ID | / |
Family ID | 58158615 |
Filed Date | 2018-02-01 |
United States Patent
Application |
20180033220 |
Kind Code |
A1 |
Pal; Jayanta ; et
al. |
February 1, 2018 |
METHOD FOR SMARTPHONE-BASED ACCIDENT DETECTION
Abstract
A method and system for detecting an accident of a vehicle, the
method including: receiving a movement dataset collected at least
at one of a location sensor and a motion sensor arranged within the
vehicle, during a time period of movement of the vehicle,
extracting a set of movement features associated with at least one
of a position, a velocity, and an acceleration characterizing the
movement of the vehicle during the time period, detecting a
vehicular accident event from processing the set of movement
features with an accident detection model, and in response to
detecting the vehicular accident event, automatically initiating an
accident response action.
Inventors: |
Pal; Jayanta; (San
Francisco, CA) ; Islam; Bipul; (San Francisco,
CA) ; Choudhury; Romit; (San Francisco, CA) ;
Risbood; Pankaj; (San Francisco, CA) ; Matus;
Jonathan; (San Francisco, CA) ; Verma; Vishal;
(San Francisco, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Zendrive, Inc. |
San Francisco |
CA |
US |
|
|
Family ID: |
58158615 |
Appl. No.: |
15/727972 |
Filed: |
October 9, 2017 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15243565 |
Aug 22, 2016 |
9818239 |
|
|
15727972 |
|
|
|
|
62207468 |
Aug 20, 2015 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
B60W 40/10 20130101;
G06K 9/00664 20130101; G08G 1/0129 20130101; B60R 25/24 20130101;
G08B 25/00 20130101; H04M 1/72538 20130101; H04W 4/029 20180201;
H04W 88/00 20130101; G08B 25/001 20130101; G08G 1/012 20130101;
G06K 2009/00939 20130101; H04W 4/40 20180201; G07C 5/02 20130101;
G07C 5/0808 20130101; G06Q 40/08 20130101; B60R 2325/205 20130101;
G06K 9/00791 20130101; H04M 2250/12 20130101; G08B 25/006 20130101;
G08B 25/016 20130101; G06K 9/00845 20130101; G07C 5/0866 20130101;
G06N 7/005 20130101; H04W 4/027 20130101; G07C 5/008 20130101 |
International
Class: |
G07C 5/02 20060101
G07C005/02; G08B 25/01 20060101 G08B025/01; H04M 1/725 20060101
H04M001/725; B60W 40/10 20120101 B60W040/10; B60W 30/08 20120101
B60W030/08; G08B 25/00 20060101 G08B025/00; G07C 5/00 20060101
G07C005/00; G06K 9/00 20060101 G06K009/00; H04W 4/04 20090101
H04W004/04; G08G 1/01 20060101 G08G001/01 |
Claims
1. A system for determining a vehicular accident associated with
first user and a vehicle, the system comprising: a first
application executing on a first device associated with the first
user, wherein the first application is operable to collect a first
movement dataset sampled from at least one of a first motion sensor
and a first location sensor of the first device; an accident
detection processing system operable to: receive a traffic dataset
describing traffic conditions proximal a vehicle location extracted
from the first movement dataset, wherein the traffic conditions
comprise at least one of: a traffic level, a traffic law, and
accident data; retrieve an accident detection model; and determine
a vehicular accident event with the accident detection model, the
traffic dataset, and the first movement dataset.
2. The system of claim 1, wherein the accident detection processing
system is operable to: extract a vehicle motion characteristic from
the first movement dataset, wherein the vehicle motion
characteristic describes movement of the vehicle; and detect
satisfaction of a threshold condition based on the vehicle motion
characteristic and the traffic dataset, wherein retrieval of the
accident detection model and determination of the vehicular
accident event are in response to detection of the satisfaction of
the threshold condition.
3. The system of claim 1, further comprising: a second application
executing on a second device associated with a second user, wherein
the second application is operable to collect a second movement
dataset sampled from at least one of a second motion sensor and a
second location sensor of the second device while the second device
is proximal the first device, wherein the accident detection
processing system is operable to determine the vehicular accident
event with the accident detection model, the traffic dataset, the
first movement dataset, and the second movement dataset.
4. The system of claim 1, further comprising: a set of
supplementary applications executing on a set of supplementary
devices associated with a plurality of users and a plurality of
vehicles, wherein the set of supplementary applications is operable
to collect a set of supplementary movement datasets sampled at
sensors of the set of supplementary devices during driving sessions
associated with the plurality of vehicles, wherein the accident
detection model comprises an accident detection machine learning
model, and wherein the accident detection processing system is
operable to: train the accident detection machine learning model
based on the set of supplementary movement datasets; and determine
the vehicular accident event with the accident detection machine
learning model, the traffic dataset, and the first movement
dataset.
5. The system of claim 4, wherein the accident detection processing
system is operable to: collect a set of supplementary traffic
datasets associated with locations of the plurality of vehicles
during the driving sessions; and train the accident detection
machine learning model based on the set of supplementary movement
datasets and the set of supplementary traffic datasets.
6. The system of claim 1, wherein the accident detection processing
system is operable to: in response to determination of the
vehicular accident event, initiate an accident response action
associated with the vehicular accident.
7. The system of claim 6, further comprising: a second application
executing on a second device associated with a second user, wherein
the accident response action comprises transmission of an
accident-related communication to the second device through the
second application.
8. The system of claim 7, wherein the second user is associated
with an emergency service, and wherein the accident-related
communication comprises location data indicating an accident
location of the vehicular accident.
9. The system of claim 1, wherein the first device comprises the
vehicle, wherein the first application is executing on the vehicle,
and wherein the accident detection processing system comprises a
remote server system operable to receive the first movement dataset
from the vehicle, and to determine the vehicular accident
event.
10. The system of claim 1, wherein the first device comprises a
mobile computing device, wherein the first application is executing
on the mobile computing device, wherein the accident detection
processing system comprises the first application, and wherein the
first application executing on the mobile computing device is
operable to determine the vehicular accident event with the
accident detection model, the traffic dataset, and the first
movement dataset.
11. The system of claim 10, wherein the mobile computing device
comprises a microphone, wherein the first application is operable
to collect an audio dataset sampled at the microphone during a time
period associated with the first movement dataset, and wherein the
accident detection processing system is operable to determine the
vehicular accident event with the accident detection model, the
audio dataset, the traffic dataset, and the first movement
dataset.
12. The system of claim 11, wherein the accident detection
processing system is operable to transmit at least one of the
extracted vehicle location and audio from the audio dataset to an
emergency service in response to determination of the vehicular
accident event.
13. A method for determining a vehicular accident associated with a
user and a vehicle, the method comprising: collecting a movement
dataset corresponding to at least one of a location sensor and a
motion sensor of a mobile computing device proximal the vehicle;
extracting a vehicle motion characteristic from the movement
dataset, wherein the vehicle motion characteristic describes
movement of the vehicle; determining a vehicular accident event
based on an accident detection model and the vehicle motion
characteristic; and after determining the vehicular accident event,
facilitating an accident response action associated with the
vehicular accident.
14. The method of claim 13, further comprising: receiving a traffic
dataset describing traffic conditions proximal a vehicle location
extracted from the movement dataset, wherein determining the
vehicular accident event comprises determining the vehicular
accident event based on the accident detection model, the vehicle
motion characteristic, and the traffic dataset, and wherein
facilitating the accident response action comprises facilitating
the accident response action based on the traffic dataset.
15. The method of claim 13, wherein the movement dataset is
collected during a time period, wherein the method further
comprises collecting a biosignal dataset sampled at a biosignal
detector proximal the user during the time period, and wherein
determining the vehicular accident event comprises determining the
vehicular accident event based on the accident detection model, the
vehicle motion characteristic, and the biosignal dataset.
16. The method of claim 15, wherein the mobile computing device
comprises the biosignal detector, and wherein facilitating the
accident response action comprises facilitating the accident
response action based on the biosignal dataset.
17. The method of claim 13, wherein the vehicle motion
characteristic comprises a vehicle speed characteristic, and
wherein the method further comprises: in response to the vehicle
speed characteristic exceeding a vehicle speed threshold,
monitoring for the vehicular accident event using the accident
detection model.
18. The method of claim 13, further comprising: determining an
accident severity score associated with the vehicular accident,
based on the vehicle motion characteristic, wherein facilitating
the accident response action comprises selecting a personalized
accident response action for the user from a set of potential
accident response actions based on the accident severity score.
19. The method of claim 13, further comprising: collecting a camera
dataset captured at a camera proximal the vehicle during a time
period associated with the vehicular accident; and determining a
vehicular accident cause for the vehicular accident based on the
camera dataset, wherein facilitating the accident response action
comprises facilitating the accident response action based on the
vehicular accident cause.
20. The method of claim 13, wherein determining the vehicular
accident event comprises determining accident-related information
describing the vehicular accident, and wherein facilitating the
accident response action comprises transmitting the
accident-related information to a third party, in response to a
request from the third party, for performance of the accident
response action by the third party.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of U.S. application Ser.
No. 15/243,565, filed 22 Aug. 2016, which claims the benefit of
U.S. Provisional Application Ser. No. 62/207,468 filed 20 Aug.
2015, which are both herein incorporated in their entirety by this
reference.
TECHNICAL FIELD
[0002] This invention relates generally to the vehicle telematics
field, and more specifically to a new and useful method for
smartphone-based accident detection in the vehicle telematics
field.
BACKGROUND
[0003] Vehicle telematic devices monitor the location, movements,
status, and behavior of a vehicle. Such devices commonly use GPS
receivers and an electronic device to transmit the collected data.
Vehicle telematic devices can additionally include capabilities to
interface with signals from the car. Such devices are often
purpose-built devices installed in the car or vehicle; however,
mobile phones also contain sensing capabilities similar to those of
telematic devices and can be used in such a capacity.
[0004] Vehicle telematic devices are typically used for functions
like navigation and position monitoring, but they can also be used
to detect the occurrence of vehicle accidents. Unfortunately,
traditional accident detection techniques often fail to take
advantage of the numerous sensor data sources available to modern
smartphones, and thus are not able to deliver the resolution of
detail needed for an ideal response to an accident. Thus, there is
a need in the vehicle telematic field to create a new and useful
method for smartphone-based accident detection. This invention
provides such a new and useful method.
BRIEF DESCRIPTION OF THE FIGURES
[0005] FIG. 1 is a flowchart representation of an embodiment of a
method;
[0006] FIG. 2 is a flowchart representation of a variation of an
embodiment of the method;
[0007] FIG. 3 is a flowchart representation of a variation of an
embodiment of the method;
[0008] FIG. 4 is a graphical representation of an embodiment of the
method;
[0009] FIGS. 5A-5B is a graphical representation of a variation of
an accident response action;
[0010] FIGS. 6A-6B is a graphical representation of a variation of
an accident response action;
[0011] FIG. 7 is a graphical representation of a variation of an
accident response action;
[0012] FIG. 8 is a graphical representation of a variation of an
accident response action; and
[0013] FIG. 9 is an example representation of acceleration profiles
of a variation of an embodiment of the method.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0014] The following description of the preferred embodiments of
the invention is not intended to limit the invention to these
preferred embodiments, but rather to enable any person skilled in
the art to make and use this invention.
1. Overview
[0015] As shown in FIGS. 1-3, an embodiment of a method 100 for
detecting an accident of a vehicle includes receiving a movement
dataset collected at least at one of a location sensor and a motion
sensor arranged within the vehicle, during a time period of
movement of the vehicle Silo; extracting a set of movement features
associated with at least one of a position, a velocity, and an
acceleration characterizing the movement of the vehicle during the
time period S130; detecting a vehicular accident event from
processing the set of movement features with an accident detection
model S140; and in response to detecting the vehicular accident
event, automatically initiating an accident response action
S150.
[0016] Additionally or alternatively, the method 100 can include
receiving a supplementary dataset configured to supplement the
movement dataset S120, determining an accident characteristic
associated with the vehicular accident event S160, and/or receiving
accident detection feedback S170.
[0017] The method 100 functions to enable vehicular accident
detection based on movement data (e.g., relating to position,
velocity, and/or acceleration) and/or supplemental data.
Additionally or alternatively, the method 100 can function to
identify one or more accident characteristics characterizing a
detected vehicular accident.
[0018] The method 100 is preferably implemented on a mobile
computing device removably coupled to a vehicle (e.g., a smartphone
carried inside a car); the method 100 can additionally or
alternatively be implemented by any device (e.g., including the
vehicle itself) capable of collecting movement data and
supplementary data.
2. Benefits.
[0019] In specific examples, the method 100 and/or system 200 can
confer several benefits over conventional methodologies used for
detecting vehicular accidents. In specific examples, the method 100
and/or system 200 can perform one or more of the following:
[0020] First, the technology can leverage non-generic location data
(e.g., GPS data) and/or motion data (e.g., accelerometer data,
gyroscope data) to conveniently and unobtrusively detect vehicular
accident events. In examples, the location data and/or motion data
can be passively collected at a user's mobile computing device
(e.g., a smartphone), such that the technology can perform
vehicular accident detection without requiring a user to purchase
additional hardware.
[0021] Second, the technology can detect vehicular accident events
with high accuracy. In examples, the technology can accurately
distinguish between collision events (e.g., single-vehicle
collisions, multi-vehicle collisions, etc.) and non-collision
events (e.g., hard braking, rapid acceleration, etc.), thereby
minimizing the detection of false positives. Further, the
technology can provide accurate detection while allowing a user to
have flexibility in placement of their mobile computing device in
relation to the vehicle (e.g., motor vehicles, bicycles,
watercraft, aircraft, spacecraft, railed vehicles, etc.). Vehicular
accident events can be detected when the mobile computing device
collecting movement data is in a user's pocket, in a user's hand,
mounted within the car, in a cup holder, and/or in other suitable
locations within the vehicle.
[0022] Third, the technology can automatically initiate accident
response actions in response to detection of a vehicular accident.
Accident response actions can include any one or more of notifying
emergency services, notifying loved ones, requesting roadside
assistance, insurance processing, and/or other suitable accident
response actions. Further, in examples, the type of initiated
accident response action can be tailored to the particular accident
based on movement data and/or supplemental data. In examples, the
technology can include a software development kit for third-parties
to integrate the accident detection features, thereby enabling
third-parties to leverage accident detection for purposes of
driving education, ride sharing, valet services, navigation,
roadside assistance, insurance processing, emergency services,
and/or other services.
[0023] Fourth, the technology can detect vehicular accident events
in real-time. Prompt transmission of time-sensitive information
(e.g., GPS coordinates, vehicular accident characteristics, etc.)
to the appropriate entities (e.g., emergency services) can be the
differentiator between life and death in serious vehicular
accidents.
[0024] Fifth, the technology can improve the technical fields of at
least vehicle telematics, computational modeling of vehicular
accident detection, and vehicular accident detection with mobile
computing device data. The technology can continuously collect and
utilize non-generic sensor data (e.g., location sensor data, motion
sensor data, etc.) to provide real-time accident detection and/or
determination of accident characteristics (e.g., severity, accident
type, etc.) Further, the technology can take advantage of the
non-generic sensor data and/or supplemental data (e.g., vehicle
sensor data, weather data, traffic data, biosignal sensor data,
etc.) to better improve the understanding of correlations between
such data and vehicular accident events, leading to an increased
understanding of vehicular-related and driver-related variables
affecting vehicular accidents.
[0025] Sixth, the technology can provide technical solutions
necessarily rooted in computer technology (e.g., utilizing
computational models to detect vehicular accidents from non-generic
location and/or motion datasets collected at mobile computing
devices, etc.) to overcome issues specifically arising with
computer technology (e.g., issues surrounding how to leverage
movement data collected by a mobile computing device to detect
vehicular accidents, and/or to automatically initiate accident
response actions for alleviating the harm caused by the vehicular
accidents, etc.).
[0026] Seventh, the technology can leverage specialized computing
devices (e.g., computing devices with GPS location capabilities,
computing devices with motion sensor functionality, etc.) to
collect specialized datasets for detecting vehicular accidents.
[0027] The technology can, however, provide any other suitable
benefit(s) in the context of using non-generalized computer systems
for detecting one or more vehicular accident events.
3. Method.
[0028] As shown in FIGS. 1-3, an embodiment of a method 100 for
detecting an accident of a vehicle includes receiving a movement
dataset collected at least at one of a location sensor and a motion
sensor arranged within the vehicle, during a time period of
movement of the vehicle Silo; extracting a set of movement features
associated with at least one of a position, a velocity, and an
acceleration characterizing the movement of the vehicle during the
time period S130; detecting a vehicular accident event from
processing the set of movement features with an accident detection
model S140; and in response to detecting the vehicular accident
event, automatically initiating an accident response action
S150.
[0029] In some variations, the method 100 can additionally or
alternatively include receiving a supplementary dataset configured
to supplement the movement dataset S120, determining an accident
characteristic associated with the vehicular accident event S160,
and/or receiving accident detection feedback S170.
3.1 Collecting a Movement Dataset.
[0030] As shown in FIGS. 1-3, Block S170 recites: receiving one or
more movement datasets collected at least at one of a location
sensor and a motion sensor arranged within the vehicle, during a
time period of movement of the vehicle. Block Silo functions to
collect movement-related data for use in detecting one or more
vehicular accident events (e.g., in Block S150) and/or for
determining one or more vehicular accident characteristics (e.g.,
in Block S160). Block S170 can additionally or alternatively
include collecting a location dataset S112, and/or collecting a
motion dataset S114.
[0031] Relating to Block Silo, movement data preferably refers to
any data related to the position, velocity, and/or acceleration of
one or more vehicles for which vehicular accident events are to be
detected through the method 100. In examples, movement data can
include only acceleration data (and not position/velocity data).
Movement data can include any one or more of: a location dataset, a
motion dataset, and/or any other suitable data related to the
position and/or movement of one or more vehicles. Movement data can
be collected from and/or associated with any one or more of: motion
sensors (e.g., multi-axis and/or single-axis accelerometers,
gyroscopes, etc.), location sensors (e.g., GPS data collection
components, magnetometer, compass, altimeter, etc.), and/or any
other suitable components. Such components are preferably arranged
at a mobile computing device (e.g., smartphone, laptop, tablet,
smart watch, smart glasses, medical devices, etc.) associated with
a user (e.g., a vehicle driver). For example, Block S110 can
include receiving one or more movement datasets collected at least
at one of a location sensor and a motion sensor arranged within the
vehicle, where the location sensor and the motion sensor are
arranged at a mobile computing device positioned within the
vehicle. Additionally or alternatively, the vehicle can include
sensors used in collecting movement data. For example, Block S110
can include collecting a movement dataset at least one of a
location sensor and a motion sensor of a vehicle (e.g., a vehicle
that is being driven by the user). However, any suitable components
associated with any suitable devices can be used in collecting
movement data and/or data from which movement data can be derived.
For example, S110 can include deriving movement data from visual
data (e.g., deriving velocity from video taken by a smartphone's
camera) and/or audio data (e.g., deriving motion from Doppler
effects captured in data from the smartphone's microphone, etc.),
as described in more detail below.
[0032] In relation to Block S110, movement data preferably serves
as the primary data used in detecting vehicular accident events;
additionally or alternatively, movement data can serve as secondary
data, or accident detection can not use movement data at all.
However, movement data can be used for any suitable purpose.
[0033] Block S110 preferably includes collecting movement data
whenever the mobile computing device is in a moving vehicle, but
can additionally or alternatively include collecting movement data
S110 for a stationary vehicle. Block S110 can be include collecting
movement data continuously, at specified time intervals (e.g.,
every minute, every 15 minutes, every half hour, every hour, etc.),
in response to satisfaction of conditions (e.g., movement
thresholds, supplementary data conditions, etc.) and/or at any
suitable time. For example, Block S110 can include receiving a
first location dataset collected at a location sensor of a mobile
computing device during a first time period of movement of the
vehicle; receiving a first motion dataset collected at a motion
sensor of the mobile computing device during the first time period;
in response to a vehicle motion characteristic (e.g., extracted
from at least one of the first location dataset and the first
motion dataset) exceeding the motion characteristic threshold:
receiving a second location dataset collected at the location
sensor of the mobile computing device during a second time period
of the movement of the vehicle, where the second time period is
after the first time period, and receiving a second motion dataset
collected at the motion sensor of the mobile computing device
during the second time period.
[0034] For Block S110, movement data is preferably associated with
one or more temporal indicators (e.g., a time point, a time window,
a time period) describing when the movement data was collected.
However, movement data can be correspond to any suitable temporal
indicator or be time-independent.
[0035] In a variation, Block S110 can include collecting movement
data at multiple devices associated with a user and/or vehicle. For
example, Block S110 can include collecting a first movement dataset
at least at one of a location sensor and a motion sensor of mobile
computing device positioned within a moving vehicle, and receiving
a second movement dataset collected at least at one of a location
sensor and a motion sensor of the moving vehicle. Multiple sources
of movement data can be used to reduce noise, fill gaps of movement
data during a time period, and/or increase confidence levels
associated with detecting vehicular accident events and/or
determining vehicular accident characteristics. For example, the
method 100 can include reducing noise by combining (e.g.,
averaging) multiple sources of movement data. Movement datasets
from multiple sources can be collected at the same type of device
(e.g., a first and a second smart phone positioned within the
vehicle), or different types of devices (e.g., a smart phone and a
vehicle). Additionally or alternatively, collecting movement data
at multiple devices can be performed in any suitable fashion.
[0036] However, collecting movement data S170 can be performed in
any suitable manner.
3.1.A Movement Data--Collecting a Location Dataset.
[0037] As shown in FIG. 3, Block S170 can additionally or
alternatively include Block S112, which recites: receiving a
location dataset collected at a location sensor associated with a
vehicle during a time period. Block S112 functions to collect
location-related data for use in detecting one or more vehicular
accident events (e.g., in Block S140) and/or for determining one or
more vehicular accident characteristics (e.g., in Block S160).
[0038] Relating to Block S112, a location dataset can include any
one or more of: GPS data (e.g., position coordinates, associated
time stamps, etc.), indoor positioning system data, local
positioning system data, multilateration data, GSM localization
data, self-reported positioning, control plane locating data,
compass data, magnetometer data, and/or any other suitable
location-related data. Collecting a location dataset S112
preferably includes collecting GPS data from a GPS receiver of a
mobile computing devices. GPS data preferably includes complete
position, velocity, time (PVT) solutions, but can additionally or
alternatively include any movement data retrieved using GNSS data
(e.g., via GLONASS, Galileo, BeiDou). For example, velocity data is
preferably collected directly from the GPS PVT solution, but can
additionally or alternatively be derived from change in position
over time (i.e., average velocity). GPS data can additionally or
alternatively be used as a source of acceleration data (as derived
from change in velocity over time). However, any suitable movement
data can be determined from GPS data.
[0039] For Block S112, collecting a location dataset preferably
includes collecting GPS data according to a mobile computing device
operating state. Operating states preferably dictate how GPS data
is collected, including data collection frequency, GPS receiver
power state, etc. For example, Block S112 can include collecting
GPS data when necessary for accident detection purposes, while
disabling the GPS receiver when GPS data collection is not
necessary. Additionally or alternatively, GPS data can be used for
multiple reasons (e.g., for both navigation and accident detection
purposes), in these cases, GPS data can be collected whenever
desired for any purpose. For example, GPS data can be collected and
used for accident detection (even if other sources of movement data
are available) anytime it is already being collected for another
purpose. However, Block S112 can include collecting GPS data based
on any suitable criteria.
[0040] In relation to Block S112, mobile computing device operating
states (as they pertain to GPS data collection) can be set based on
any input data. For example, Block S112 can include collecting GPS
data differently depending on navigation system state (e.g.,
battery charge level, charging status), time of day, location,
route knowledge (e.g., how much data has been collected about the
current route and/or position), GPS signal quality, and/or any
other suitable data.
[0041] However, collecting a location dataset S112 can be performed
in any suitable fashion.
3.1.B Movement Data--Collecting a Motion Dataset.
[0042] As shown in FIG. 3, Block S170 can additionally or
alternatively include Block S114, which recites: receiving a motion
dataset collected at a motion sensor associated with a vehicle
during a time period. Block S114 functions to collect
motion-related data for use in detecting one or more vehicular
accident events (e.g., in Block S140) and/or for determining one or
more vehicular accident characteristics (e.g., in Block S160).
[0043] Relating to Block S114, a motion dataset can include any one
or more of: accelerometer data (e.g., single-axis data, multi-axis
data), gyroscope data (e.g., single-axis data, multi-axis data),
velocity data (e.g., speed, instantaneous velocity, average
velocity, change in velocity, velocity variability over time,
maximum velocity, minimum velocity, etc.), acceleration data (e.g.,
instantaneous acceleration, gravitational acceleration, average
acceleration, change in acceleration, acceleration variability over
time, maximum acceleration, minimum acceleration, etc.),
displacement data, orientation data, rotation data, turning data,
and/or any other suitable motion-related data. For example,
gravitational acceleration can be used to measure one or more free
fall parameters (e.g., entering a free fall state, exiting a free
fall state, duration of free fall, etc.) before, during, and/or
after a vehicular accident event. Free fall parameters of a motion
dataset can indicate that a mobile computing device has been
dropped, is in mid-air (e.g., in response to a vehicular accident
event), and/or has moved in any other manner.
[0044] Block S114 preferably includes collecting movement data
using one or more accelerometers (i.e., collecting accelerometer
data). Accelerometer data is preferably used as a source of
acceleration data. For example, Block S114 can include deriving
acceleration data from a motion dataset collected at an
accelerometer of a mobile computing device.
[0045] In variations, Block S114 can include collecting a motion
dataset at an accelerometer of a mobile computing device during a
time period, and deriving at least one of position data and
velocity data from the motion dataset for the time period.
Accelerometer data is preferably used as a source of position data
by comparing accelerometer patterns to a map reference with known
patterns (e.g., road surface vibration patterns, as measured by the
accelerometer, correlate to a specific stretch of road), but can
additionally or alternatively be used to derive or estimate
position data in any manner.
[0046] In relation to Block S114, accelerometer data is preferably
collected according to a navigation system state, but can
additionally or alternatively be collected in any manner.
[0047] Additionally or alternatively, Block S114 can include any
elements described in U.S. patent application Ser. No. ______ filed
______ and entitled "Method for Accelerometer-Assisted Navigation,"
the entirety of which is incorporated by this reference.
[0048] However, collecting a motion dataset S114 can be performed
in any suitable fashion.
3.2 Collecting Supplementary Data.
[0049] As shown in FIGS. 1-3, Block S120 recites: collecting
supplementary data during a time period at one or more devices
associated with the user. Block S120 functions to collect data that
can be used to filter, control for errors in, and/or otherwise
supplement movement data collected in Block Silo.
[0050] In relation to Block S120, supplementary data can include
any one or more of: audio data (e.g., collected in Block S121),
video data (e.g., collected in Block S122), vehicle sensor data
(e.g., collected in Block S123), remote movement data (e.g.,
collected in Block S124), biosignal data (e.g., collected in Block
S125), environmental data (e.g., collected in Block S126), traffic
data (e.g., collected in Block S127), contextual data (e.g.,
collected in Block S128), and/or any other suitable data for
detecting one or more vehicular accident event and/or determining
one or more vehicular accident characteristics. Block S120
preferably includes collecting supplementary data at a mobile
computing device used to collect movement data (e.g., in Block
S110), but can additionally or alternatively include collecting
supplementary data at a device distinct from the mobile computing
device used to collect movement data. In a variation, Block S120
can include collecting supplementary data across a plurality of
devices, where the supplementary data can be combined and/or
otherwise processed in Block S130.
[0051] Block S120 preferably includes passively collecting
supplementary data (e.g., without requiring human intervention),
but can additionally or alternatively include actively collecting
supplementary data (e.g., from presenting a digital survey to the
user at the mobile computing device, etc.). In a specific example,
Block S120 can include prompting, at an application executing on
the mobile computing device, the user to input vehicle model
information.
[0052] Block S120 can include collecting supplementary data at any
suitable time before, during, and/or after a vehicular accident
event. In a variation, Block S120 can include collecting
supplementary data in response to determining an unsafe driving
conditions status (e.g., from movement data, from other
supplementary data, etc.). In another variation, Block S120 can
include collecting supplementary data in response to detecting a
vehicular accident event. For example, Block S120 can include
capturing image data and/or video data of vehicles (e.g., license
plates) involved in the vehicular accident event, which can be used
to facilitate insurance processing and/or other suitable
purposes.
[0053] Relating to Block S120, supplementary data is preferably
associated with a temporal indicator that is the same and/or
overlapping with a temporal indicator associated with movement data
(e.g., collected in Block S110). For example, the method 100 can
include collecting a movement dataset at a mobile computing device
during a time period, and collecting a supplementary dataset at the
mobile computing device during the time period. Additionally or
alternatively, the supplementary data can be associated with a
temporal indicator distinct from temporal indicators associated
with movement data, but can otherwise be time independent.
[0054] However, collecting supplementary data S120 can be performed
in any suitable manner.
3.2.A Supplementary Data--Collecting Audio Data.
[0055] In a variation, Block S120 can optionally include Block
S121, which recites: collecting audio data. Block S121 preferably
includes collecting audio data that can be used to detect that an
accident has occurred and/or the severity of an accident (e.g., by
analyzing recorded audio for sounds related to or resulting from
impacts). For example, audio data can provide information on the
status of a vehicle before/during/after an accident (e.g., by
recording engine noise), the nature, location, and/or severity of
an accident (e.g., by recording impact noise), and the effect of
the accident on the vehicle's occupants (e.g., by recording voice
data for a vehicle's occupants). In another example, Block S121 can
include recording airbag deployment audio data, and detecting a
vehicular accident event and/or determining an vehicular accident
characteristic based on the airbag deployment audio data, any other
suitable audio data, and/or movement data.
[0056] Block S121 preferably includes collecting audio data via one
or more microphones located in the mobile computing device, but can
additionally or alternatively collect audio data from any source
(e.g., a vehicle microphone coupled to the mobile computing device
via Bluetooth).
[0057] In a variation, Block S121 includes collecting audio data
via recorded gyroscope signals (e.g., as described in "Gyrophone:
Recognizing Speech From Gyroscope Signals", by Yan Michalevsky, Dan
Boneh, and Gabi Nakibly, published in the 23.sup.rd Usenix Security
Symposium, the entirety of which is incorporated by this
reference).
[0058] However, collecting audio data S121 can be performed in any
suitable fashion.
3.2.B Supplementary Data--Collecting Video Data.
[0059] In a variation, Block S120 can optionally include Block
S122, which recites: collecting video data. Block S122 preferably
includes collecting video data that can be used to detect that an
accident has occurred and/or the severity of an accident (e.g., by
analyzing video to determine how far the mobile computing device
was moved during an accident). For example, video data can provide
information on the status of a vehicle before/during/after an
accident (e.g., by recording visuals of the vehicle's exterior),
the nature, location, and/or severity of an accident (e.g., by
recording visuals of an impact site), and the effect of the
accident on the vehicle's occupants (e.g., by recording video data
of a vehicle's occupants).
[0060] Block S122 preferably includes collecting video data via one
or more cameras located in the mobile computing device, but can
additionally or alternatively collect video data from any source
(e.g., a backup camera of the vehicle accessible to the navigation
device).
[0061] However, collecting video data S122 can be performed in any
suitable fashion.
3.2.0 Supplementary Data--Vehicle Sensor Data.
[0062] In a variation, Block S120 can optionally include Block
S123, which recites: collecting vehicle sensor data. Vehicle sensor
data can include any one or more of: proximity sensor data (e.g.,
radar, electromagnetic sensor data, ultrasonic sensor data, light
detection and ranging, light amplification for detection and
ranging, line laser scanner, laser detection and ranging, airborne
laser swath mapping, laser altimetry, sonar, etc.), vehicle camera
data (e.g., in-car cameras, exterior cameras, back-up cameras,
dashboard cameras, front-view cameras, side-view cameras, image
recognition data, infrared camera, 3D stereo camera, monocular
camera, etc.), car speed, RPM data, odometer, altimeter, location
sensor data (e.g., GPS data, compass data, etc.), motion sensor
data (e.g., from an accelerometer, gyroscope, etc.), environmental
data (e.g., pressure, temperature, etc.), light sensor data (e.g.,
from infrared sensors, ambient light sensors, etc.), fuel level
(e.g., percentile-based, distance-based, low warning, etc.), fuel
system status, oxygen sensor data, throttle position, gear data
(e.g., drive, neutral, park, reverse, gear number, etc.), HVAC data
(e.g., current temperature, target temperature, etc.), driving
status (e.g., restricted features such as user inputs into control
panel, unrestricted features, etc.), and/or any other suitable
vehicle data. For example, vehicle sensor data can provide
information on the status of a vehicle before/during/after an
accident (e.g., by collecting airbag deployment data, ABS or other
braking system data, engine temperature data, etc.). For example,
Block S123 can include receiving a proximity dataset collected at a
proximity sensor of the vehicle.
[0063] Block S123 can include collecting vehicle sensor data (e.g.,
vehicle subsystem status data) via the vehicle's on-board
diagnostics (OBD) port. For example, Block S123 can include using
OBD-II Parameter IDs to request OBD data from a vehicle. In another
example, Block S123 can include detecting deployment of an airbag
through a communicable link with a vehicle. However, collecting
vehicle sensor data through the OBD system can be performed in any
manner.
[0064] However, collecting vehicle sensor data S123 can be
performed in any suitable fashion.
3.2.D Supplementary Data--Collecting Remote Movement Data.
[0065] In a variation, Block S120 can optionally include Block
S124, which recites: collecting remote movement data. Block S124
preferably includes collecting movement data from one or more
mobile computing devices proximal a mobile computing device
implementing Block Silo. For example, Block S124 can include
collecting remote movement data from other smartphones in the
vehicle, smartphones in nearby vehicles, etc. Remote movement data
is preferably used to aid in performing accident detection through
comparison of local movement data (i.e., movement data captured in
Block S110) and remote movement data. For example, if local
movement data appears to indicate that an accident has occurred,
but remote data from a number of nearby sources does not appear to
support the accident detection, this can indicate that the local
movement data is not trustworthy.
[0066] Block S124 preferably includes collecting remote movement
data via wireless data connections of the mobile computing device
(e.g., LTE internet on a smartphone) but can additionally or
alternatively include collecting remote movement data in any
manner.
[0067] Block S124 can include collecting remote movement data from
mobile computing devices (or other sources) when remote movement
data sources are within some range (e.g., loom). Additionally or
alternatively, Block S124 can include collecting remote movement
data selectively based on any criteria (e.g., only collecting
remote movement data from vehicles traveling in the same direction
as the vehicle with the navigation device operating the method
100), but remote movement data can be collected at any suitable
time.
[0068] However, collecting remote movement data S124 can be
performed in any suitable fashion.
3.2.E Supplementary Data--Collecting Biosignal Data.
[0069] In a variation, Block S120 can optionally include Block
S125, which recites: collecting biosignal data. Biosignal data can
include any one or more of: cardiovascular parameters (e.g.,
instantaneous blood pressure, blood pressure variability,
instantaneous heart rate, heart rate variability, average heart
rate, resting heart rate, heartbeat signature, pulse rate metrics,
etc.), bioelectrical signal data (e.g., electrooculography,
electromyography, electrocardiography, galvanic skin response,
magnetoencephalogram, etc.), sleep metrics (e.g., amount of sleep,
types of sleep, etc.), respiration data (e.g., respiration rate,
depth of breath, shallowness of breath, inhalation-to-exhalation
ratio, thoracic variations, tidal volume, inspiratory flow,
expiratory flow, work of breathing, phase angle, respiratory
waveform morphology, etc.), data regarding analytes detectable in
biological fluids (e.g., blood, sweat, interstitial fluid, chime,
saliva, serum, etc.) and/or any other suitable biosignal data.
Block S125 can include collecting biosignal data ay any one or more
of: medical devices (e.g., therapeutic devices, monitoring devices,
etc.), mobile electronic devices with biosignal data collection
functionality (e.g., smart watch with cardiovascular monitoring
capabilities, etc.), and/or any other suitable biosignal data
collector.
[0070] In an example, Block S125 can include measuring, at a
fitness monitoring device coupled to the vehicle driver, a blood
pressure parameter of the vehicle driver during a time period in
which movement data is collected. In this example, an unusually
high blood pressure (e.g., relative an average blood pressure for
the driver during other driving sessions) can indicate a driver's
inability to focus, which can be correlated with a higher
probability of vehicular accident. In another example, Block S125
can include: in response to detecting a vehicular accident event,
measuring a heart rate parameter of the vehicle driver at a smart
watch coupled to the vehicle driver. In this example, measuring an
average heart rate that is comparable to the driver's average
resting heart rate can indicate driving conditions familiar to the
driver, which can be correlated with a lower probability of
vehicular accident.
[0071] However, collecting biosignal data S126 can be performed in
any suitable fashion.
3.2.F Supplementary Data--Collecting Environmental Data.
[0072] In a variation, Block S120 can optionally include Block
S126, which recites: collecting environmental data. Environmental
data can include any one or more of: weather conditions (e.g.,
weather forecast, temperature, humidity, precipitation, wind,
etc.), road conditions (e.g., road closure, road opening, number of
road lanes, road deterioration, etc.), pressure conditions (e.g.,
ambient pressure, etc.), air quality (e.g., pollution levels,
etc.), and/or other suitable environmental data. In an example, a
weather forecast describing thunderstorms proximal the driver's
location (e.g., derived from a location dataset collected in Block
S112, etc.) can indicate a higher likelihood of a vehicular
accident event. In another example, road conditions indicating a
single-lane freeway, analyzed along with a motion dataset
describing a vehicular speed in excess of the freeway speed limit,
can indicate a greater chance of occurrence of a vehicular accident
event.
[0073] However, collecting environmental data S126 can be performed
in any suitable fashion.
3.2.G Supplementary Data--Collecting Traffic Data.
[0074] In a variation, Block S120 can optionally include Block
S127, which recites: collecting traffic data. Traffic data can
include any one or more of: accident data (e.g., number of
accidents within a predetermined radius of the user, accident
frequency, accident rate, types of accidents, frequency of
accidents, etc.), traffic level, traffic laws (e.g., speed limit,
intersection laws, turning laws), traffic lights, type of vehicular
path (e.g., freeway, intersection, etc.), and/or other suitable
traffic data.
[0075] In an example, Block S127 can include querying a traffic
information database (e.g., traffic accident tracker) with GPS
coordinate inputs; and receiving a traffic report for a location
proximal the vehicle location. In another example, higher amounts
of traffic proximal the vehicle location can indicate a higher
likelihood of a multi-vehicle collision. In another example, a
vehicle driver violating traffic laws (e.g., turning left at an
intersection prohibiting left turns) can indicate a higher
likelihood of a particular vehicle accident type (e.g., a T-bone
collision).
[0076] However, collecting traffic data S127 can be performed in
any suitable fashion.
3.2.H Supplementary Data--Collecting Contextual Data.
[0077] In a variation, Block S120 can optionally include Block
S128, which recites: collecting contextual data. Contextual data
can include any one or more of: temporal data (e.g., time of day,
date, etc.), driver data, mobile electronic device usage (e.g.,
driver texting, usage of smartphone while driving, etc.), vehicle
model data (e.g., model, age, accident history, mileage, repair
history, etc.), light sensor data (e.g., associated with a user's
mobile electronic device, etc.), and/or any other suitable
contextual data.
[0078] In an example, Block S128 can include collecting driver
behavior data (e.g., actively collected driver data, derived from
movement data, etc.), which can be used to adjust and/or select one
or more accident detection models tailored to a given driver.
Additionally or alternatively, Block S128 can include any elements
described in U.S. application Ser. No. 14/566,408 filed 10 Dec.
2014 and entitled "System and Method for Assessing Risk through a
Social Network," and U.S. application Ser. No. 14/206,721 filed 12
Mar. 2014 and entitled "System and Method for Determining a Driver
in a Telematic Application," which are each hereby incorporated in
their entirety by this reference.
[0079] In another example, Block S128 can include collecting
temporal data indicating the time of day when a driving session is
occurring. For example, a higher risk of vehicular accident can be
correlated with temporal data indicating a driving session at a
time when the driver does not usually drive. In another example,
mobile computing device usage by the driver during the driving
session (e.g., texting while driving) can provide insight into
driver behaviors affecting the likelihood of a vehicular accident.
In another example, the method 100 can include collecting a light
dataset from a light sensor of the mobile computing device;
determining a position of the mobile computing device in the
vehicle (e.g., in a user's pocket, being held, mounted, in a cup
holder, in a passenger seat, etc.); and selecting an accident
detection model from a set of accident detection models, based on
the position of the mobile computing device.
[0080] However, collecting contextual data S128 can be performed in
any suitable fashion.
3.3 Processing Movement Data and/or Supplementary Data
[0081] As shown in FIGS. 1-2, Block S130 recites: processing at
least one of a movement dataset and a supplementary dataset. Block
S130 functions to process data collected at least in one of Block
S170 and Block S120 for detecting one or more vehicular accident
events.
[0082] Processing data can include any one or more of: extracting
features, performing pattern recognition on data, fusing data from
multiple sources, combination of values (e.g., averaging values,
etc.), compression, conversion (e.g., digital-to-analog conversion,
analog-to-digital conversion), wave modulation, normalization,
filtering, noise reduction, smoothing, model fitting,
transformations, mathematical operations (e.g., derivatives, moving
averages, etc.), multiplexing, demultiplexing, and/or any other
suitable processing operations. For example, Block S130 can include
associating different data (e.g., different data types, same data
type collected at different sources, etc.) based on a common and/or
overlapping temporal indicator (e.g., time point, time window, time
period, etc.), which can enable data collected from multiple
sources during a common temporal indicator to be processed and/or
analyzed together (e.g., for detecting a vehicular accident event
during the temporal indicator. In another example, Block S130 can
include measuring sensor data oscillation periods; in many cases,
measurement `ringing` (i.e., oscillation around some value) can be
higher magnitude or sustained for a longer period of time for
larger impacts. Therefore, measurements of ringing magnitude and/or
duration can be used to generate impact estimates.
[0083] Block S130 preferably includes extracting a one or more
movement features from at least one of a movement dataset and a
supplementary dataset, but movement features can be derived from
any suitable data. Movement features are preferably associated with
at least one of a position, a velocity, and an acceleration
characterizing the movement of the vehicle during a time period.
Movement features can include any one or more of: raw movement data
(e.g., raw location data, raw motion data, etc.), processed
movement data (e.g., through a processing operation described
above), movement profiles (e.g., driving profile, braking profile,
position profile, speed profile, acceleration profile, turning
profile, etc.), identified driving actions (e.g., parking,
acceleration, braking, short following, lane-departure,
freewheeling, U-turn, left turn, right turn, over-revving,
stationary vehicle, moving vehicle, etc.), vehicle motion
characteristics (e.g., determined in Block S142), and/or any other
suitable features.
[0084] For example, Block S130 can include calculating a vehicle
braking profile and/or stopping distance from movement data (and/or
from supplementary data). A vehicle braking profile can be
calculated from vehicle deceleration over time. Stopping distance
can be calculated from distance traveled between initiation of
deceleration and a vehicle stopping. In another example, Block S130
can include identify or estimating an acceleration feature
describing changes in vehicle acceleration (e.g., for use in
determining an accident severity score in Block S160). In another
example, Block S130 can include deriving movement features from
image and/or video analysis of media captured by one or more
cameras associated with the vehicle (e.g., mobile computing device
cameras, vehicle cameras, etc.). In another example, Block S130 can
include extracting driving profile features (e.g., describing
driver behavior) from interpreting speech recorded by microphones
of the navigation device; speech can be interpreted based on
meaning (e.g., driver behavior can be detected based on what people
say) and/or emotion (e.g., driver behavior can be detected based on
identified emotions). In another example, Block S130 can include
extracting a vertical vehicular motion feature (e.g., from vertical
accelerometer data) describing motion of the vehicle perpendicular
a road surface.
[0085] Additionally or alternatively, Block S130 can include
extracting one or more supplemental features (e.g., weather
features, traffic features), from one or more supplemental datasets
(e.g., a weather dataset, a traffic dataset). For example, Block
S130 can include deriving a mobile computing device location
feature within the vehicle (e.g., in pocket, on a seat, on
dashboard, on a car mount mobile computing device holder, held in a
hand, etc.) from processing mobile computing device light sensor
data, camera data (e.g., image recognition processing operations on
in-vehicle camera data) and/or other suitable data, but any
suitable features can be extracted from any suitable data.
[0086] Block S130 can include filtering data from at least one of a
movement dataset and a supplementary dataset. Movement and
supplementary data can be filtered using both independent filters
(i.e., filters operating on data from a single source) and joint
filters (i.e., filters operating on data from multiple sources). In
an example, accelerometer readings from the navigation device can
be filtered according to expected impact patterns. As shown in FIG.
9, a small change in acceleration followed by a very quick (but
high magnitude) spike in acceleration and then a longer, lower
magnitude acceleration reading can be indicative of braking causing
a phone to fly out of a cup holder, and then land in a seat.
Filtering can be important in this case as the first three sections
of the acceleration profile are indicative of navigation device
motion independent of vehicle motion, which can be useful for
accident detection.
[0087] Relating to Block S130, in an example of a joint filter, GPS
data can be filtered based on accelerometer data. If GPS data
indicates a sudden change in velocity, but that change in velocity
is not reflected in accelerometer readings, the GPS data can be
flagged as untrustworthy data. In another example, Block S130 can
include operating a Kalman filter on accelerometer and microphone
data to identify correlations between the two datasets (which can
be used to identify accidents).
[0088] Block S130 can include processing any available data (e.g.,
behavior models built into the navigation system, a database of
known data profiles stored in the cloud, learned patterns derived
from system behavior during normal non-accident operation periods,
etc.).
[0089] However, processing at least one of a movement dataset and a
supplementary dataset can be performed in any suitable manner.
3.4 Detecting a Vehicular Accident Event.
[0090] As shown in FIGS. 1-3, Block S140 recites: detecting one or
more vehicular accident events from processing a set of movement
features with an accident detection model. Block S140 functions to
identify one or more accidents involving one or more vehicles. As
shown in FIG. 3, Block S140 can additionally or alternatively
include performing threshold satisfaction tests S142, and/or
generating an accident detection machine learning model S144.
[0091] Vehicular accident events can include: collisions (e.g.,
single-vehicle collisions, multi-vehicle collisions, pedestrian
collisions, etc.), vehicle failures (e.g., mechanical breakdowns,
electrical failures, software failures, issues with battery, wheel
change, fuel, puncture, charging, clutch, ignition, cooling,
heating, ventilation, brakes, engine, etc.), and/or any other
suitable type of vehicular accident. Vehicular accident events can
be detected for any type of vehicle(s) involved in an accident
(e.g., motor vehicles, bicycles, watercraft, aircraft, spacecraft,
railed vehicles, etc.), possessing any suitable vehicle
characteristics (e.g., size, form, construction, materials, etc.),
but vehicular accident events can include any suitable
accident-related events.
[0092] Block S140 preferably includes detecting a vehicular
accident event based on the set of movement features. For example,
Block S140 can include detecting a vehicular accident event from
processing the set of movement features with an accident detection
model. In another example, Block S140 can include detecting a
vehicular accident event with the accident detection model and at
least one of a location dataset and a motion dataset (e.g., a
location dataset and motion dataset received in response to
satisfaction of a comparison to a threshold in Block S142). In
another example, Block S142 can include detecting a vehicular
accident event from processing a vertical vehicular motion feature
with the accident detection model.
[0093] Additionally or alternately, Block S142 can include
detecting a vehicular accident event based on supplemental data.
For example, the method 100 can include receiving a traffic dataset
describing traffic conditions proximal a vehicle location extracted
from the second location dataset, where the traffic conditions
include at least one of: a traffic level, a traffic law, and
accident data; and detecting a vehicular accident event with the
accident detection model, the traffic dataset, and a movement
dataset (e.g., a location dataset, a motion dataset, etc.). In
another example, the method 100 can include receiving a weather
dataset associated with a vehicle location extracted from a
movement dataset, where the weather dataset indicates weather
conditions proximal the vehicle location during a time period
(e.g., the time period in which the movement dataset was
collected); and detecting the vehicular accident event from
processing the weather dataset and a set of movement features
(e.g., extracted from the movement dataset) with the accident
detection model. In another example, the method 100 can include
receiving a proximity dataset collected at a proximity sensor of
the vehicle; extracting a set of proximity features describing an
object physically proximal the vehicle; and detecting a vehicular
accident event from processing the set of proximity features and
the set of movement features with the accident detection model. In
another example, the method 100 can include receiving an audio
dataset collected at a microphone of the mobile computing device;
receiving a biosignal dataset collected at a biosignal monitoring
device coupled to a driver of the vehicle; receiving a weather
dataset describing weather conditions proximal a vehicle location
extracted from the first movement dataset; receiving a traffic
dataset describing traffic conditions proximal the vehicle
location; receiving a vehicular gear dataset describing gear status
of the vehicle; and detecting one or more vehicular accident events
from processing the audio dataset, the biosignal dataset, the
weather dataset, the traffic dataset, the vehicular gear dataset,
the set of movement features, and the set of proximity features
with the accident detection model.
[0094] In a variation, Block S140 can include generating a
comparison between movement-related data (e.g., a movement dataset,
movement features, vehicle motion characteristics extracted in
Block S142, etc.) and one or more accident detection thresholds.
Detecting an accident can be in response to exceeding, being below,
and/or being at an accident detection threshold, and/or in response
to satisfaction of any suitable accident detection threshold
condition. Accident detection thresholds can include any one or
more of: a threshold change in position (e.g., change in latitude,
longitude, altitude, etc.), change in velocity, change in
acceleration, supplemental data thresholds (e.g., weather
precipitation threshold, traffic level threshold, etc.), and/or any
suitable threshold. An accident detection threshold preferably
indicates a threshold to be reached within an amount of time, which
can be predetermined (e.g., manually by a human, automatically
through a computational model), dynamic (e.g., based on
supplemental information), and/or otherwise determined. For
example, Block S140 can include generating a comparison between a
vehicular speed motion characteristic and a vehicular speed
accident detection threshold of a change in speed of 40 MPH in less
than 2 seconds. Alternatively, the accident detection threshold can
be time independent.
[0095] In this variation, Block S140 can include dynamically
adjusting an accident detection threshold based on at least one of
movement-related data and/or supplemental-related data. For
example, Block S140 can include dynamically adjusting an accident
detection threshold of change in speed based on weather conditions
(e.g., reducing the threshold change in speed of 40 MPH in less
than 2 seconds to 35 MPH in less than 3 seconds based on a high
precipitation forecast). In another example, Block S140 can include
dynamically increasing a change in acceleration accident detection
threshold in response to retrieving traffic level supplemental data
indicating light traffic at a location proximal the vehicle.
[0096] In another variation, Block S140 can include generating a
comparison with one or more reference profiles. Reference profiles
can include accident reference profiles (e.g., movement profiles
and/or supplemental profiles indicative of a vehicular accident
event), non-accident reference profiles, and/or any other suitable
reference profiles for illuminating the presence of a vehicular
accident event. One or more reference profiles are preferably
compared to movement-related data collected for a user driving the
vehicle, but can additionally or alternatively be compared to
supplemental-related data. In an example, Block S140 can include
generating a comparison between an expected non-accident reference
profile for a large vehicle performing a sharp U-turn and
movement-related data collected for a commercial truck performing a
sharp U-turn. In this example, Block S140 can include detecting a
vehicular accident event in response to a similarity score (e.g.,
between the reference profile and the movement-related data) below
a similarity score threshold.
[0097] In examples of this variation, Block S140 can include
matching patterns between one or more reference profiles and at
least one of movement-related data and supplemental-related data.
For example, Block S140 can include processing movement and/or
supplemental data with an accident detection machine learning model
(e.g., in Block S144). For example, Block S140 can include
comparing accelerometer data to known impact profiles or impact
models. Block S140 can also include comparing modeled results to
typical results for data types; for example, stopping distance can
be compared to a typical emergency stopping distance for a vehicle.
If measured stopping distance is significantly shorter than the
typical emergency stopping distance, that can be an indication that
an accident has occurred. As an example of joint pattern
recognition, Block S1340 can process movement data and microphone
data simultaneously to determine potential impacts (e.g., for
impact to be detected, an impact noise can need to be detected
within a certain time period of a rapid acceleration change).
However, generating a comparison with a reference profile can be
performed in any suitable manner.
[0098] In another variation, Block S140 can include mapping out a
decision tree with decision nodes, chance nodes, and/or end nodes
describing accident detection actions (e.g., selecting a machine
learning model to retrieve, collecting additional data, etc.) to
take in response to different events. However, generating a
decision tree can be performed in any suitable manner.
[0099] In another variation, Block S140 can include dynamically
adjusting an accident detection threshold, accident detection
model, and/or a reference profile based on the source of movement
data (e.g., collected in Block S110). For example, Block S140 can
include retrieving a collision reference profile tailored for
comparison to movement data collected from a mobile computing
device positioned at a device mount within the vehicle (e.g.,
versus an unrestrained mobile computing device positioned on top of
the passenger seat). In another example, Block S140 can include
generating a set of accident detection models for mobile computing
devices coupled to different portions of a driver's body. In this
example, a first and a second accident detection model can be
generated for mobile computing devices coupled to the wrist (e.g.,
a smartwatch worn by the driver) and to a driver pocket (e.g., a
smartphone within a pant pocket), respectively. Block S140 can
accordingly include, in this example, retrieving the second
accident detection model in response to mobile computing device
light sensor data indicating a device position within the pocket of
the driver. In another example, if it is detected or otherwise
known that the navigation device is kept in a driver's pocket, the
acceleration profile of the phone can be assumed to more closely
match that of the vehicle than if the navigation device was set on
(and not fixed to) the dashboard. However, dynamically adjusting an
accident detection threshold, model, and/or reference profile can
be performed in any suitable manner.
[0100] Block S140 can include testing for a vehicular accident
event (e.g., generating a comparison with an accident detection
threshold and/or reference profile, processing movement data with
an accident detection model, etc.) in response to satisfaction of a
condition (e.g., in Block S142), at predetermined time intervals
(e.g., every second, minute, hour, etc.), manually triggered (e.g.,
a user requesting accident detection monitoring, such as when the
user is unconfident about driving conditions, etc.) dynamically
determined (e.g., based on movement-related data,
supplementary-related data, etc.). In examples, Block S140 can
include triggering the testing for a vehicular accident event in
response to movement-related data indicating rapid deceleration
(e.g., which can indicate an emergency braking situation), unusual
position and speed data (e.g., a stationary vehicle in the middle
of a highway), high-risk locations (e.g., an intersection with a
high number of accidents), and/or other suitable movement-related
events. In other examples, Block S140 can include initiating
vehicular accident event testing in response to
supplementary-related data including: mobile computing device
characteristics (e.g., more frequent testing in response to the
mobile computing device having a high state-of-charge, etc.),
driver data (e.g., less frequent monitoring in response to driver
data indicating low-risk driving behaviors, etc.), weather
conditions (e.g., more frequent monitoring in response to
retrieving weather data indicating heavy snowfall, etc.), traffic
conditions (e.g., more frequent testing in response to identifying
the vehicle in a high traffic location), and/or any other suitable
supplementary data). However, testing for a vehicular accident
event can be performed at any suitable frequency at any suitable
time.
[0101] Block S140 preferably includes detecting one or more
vehicular accident events at a mobile computing device associated
with the vehicle (e.g., a mobile computing device within the
vehicle, mounted to the vehicle, proximal the vehicle, etc.). In an
example, Block S140 can include detecting a vehicular accident
event at an offline (e.g., without internet connectivity) mobile
computing device. Additionally or alternatively, Block S140 can be
performed at a remote server and/or other suitable component.
[0102] However, detecting a vehicular accident event can be
performed in any suitable manner.
3.4.A Performing Threshold Satisfaction Tests.
[0103] As shown in FIGS. 1 and 3, Block S140 can optionally include
Block S142, which recites: performing threshold satisfaction tests.
Block S142 functions compare at least one of movement-related data
(e.g., raw movement data, movement features, extracted
characteristics, etc.) and supplemental-related data (e.g., raw
supplemental data, supplemental features, extracted
characteristics, etc.) to threshold conditions for determining when
to monitor for one or more vehicular accident events.
[0104] Block S142 preferably includes extracting a vehicle motion
characteristic (e.g., to compare against motion characteristic
threshold). Vehicle motion characteristics and motion
characteristic thresholds can typify motion characteristic types
including any one or more of: speed characteristics (e.g., average
speed, instantaneous speed, speed variability, change in speed,
etc.), acceleration (e.g., average acceleration, instantaneous
acceleration, acceleration variability, change in acceleration,
etc.), position (e.g., altitude, GPS coordinates, direction,
location, etc.), turning characteristics (e.g., turn speed, turn
radius, steering angles, wheel velocities, tire slip velocities,
etc.), movement features, and/or any other suitable vehicle motion
characteristics. For example, Block S142 can include extracting a
vehicle motion characteristic, where the vehicle motion
characteristic is a vehicular speed value, and where the threshold
motion characteristic (e.g., to which the vehicle motion
characteristic can be compared) is a vehicular speed threshold. In
another example, Block S142 can include extracting a vehicle motion
characteristic from a movement dataset (e.g., a location dataset
and/or motion dataset), where the vehicle motion characteristic
describes the movement of the vehicle within a time window of the
first time period.
[0105] Further, Block S142 preferably includes comparing an
extracted vehicle motion characteristic to a motion characteristic
threshold. However, any suitable data can be compared to any
suitable threshold.
[0106] Block S142 preferably includes initiating one or more
actions (e.g., retrieving an accident detection model, comparing a
movement feature to an accident detection threshold, collecting
additional movement data and/or supplementary data, etc.) in
response to satisfaction of a threshold condition (e.g., exceeding
a threshold, being below or at a threshold, etc.). For example,
Block S142 can include, in response to the vehicle motion
characteristic exceeding the motion characteristic threshold:
retrieving an accident detection model, receiving a location
dataset collected at the location sensor of the mobile computing
device during a second time period of the movement of the vehicle,
where the second time period is after the first time period (e.g.,
a first time period where an initial location dataset and/or motion
dataset were collected), and receiving a motion dataset collected
at the motion sensor of the mobile computing device during the
second time period. In another example, accident detection can
occur only when a vehicle is traveling above 2 MPH, 5 MPH, 10 MPH,
20 MPH, 30 MPH, and/or any other suitable velocity threshold. In
another example, before the first time period: generating a first
accident detection trained model from first training data
characterized by a first training data motion characteristic below
a motion characteristic threshold (e.g., vehicular speed of 30
MPH), and generating a second accident detection trained model from
second training data characterized by a second training data motion
characteristic exceeding the motion characteristic threshold. In
other examples, Block S142 can include performing one or more
comparisons to a stopping distance threshold (e.g., stopping
distance must be less than the typical emergency stopping
distance), a movement cessation threshold (e.g., vehicle must not
move for thirty seconds after a detected accident), an acceleration
threshold (e.g., deceleration must be greater than free-fall
deceleration/9.8 ms.sup.-2), and/or any other suitable
threshold.
[0107] Block S142 can be performed at specified time intervals
(e.g., every second, every minute, every hour, etc.), in response
to satisfaction of predetermined conditions (e.g., satisfaction of
a data collection threshold), at any stage of processing (e.g.,
during an early stage of data processing before retrieving and/or
using an accident detection model, etc.), and/or at any suitable
time.
[0108] In a variation, Block S142 can include dynamically adjusting
the motion characteristic threshold (e.g., during a vehicle driving
session, in response to collecting movement data, at other suitable
times, etc.). Dynamically adjusting one or more motion
characteristic thresholds is preferably based on supplemental
information, but can additionally or alternatively be based on
movement data and/or other suitable data. For example, Block S142
can include: prior to comparing the vehicle motion characteristic
to the motion characteristic threshold, dynamically adjusting the
motion characteristic threshold based on a traffic dataset
describing traffic conditions proximal the vehicle during the time
period. In another example, Block S142 can include dynamically
adjusting the motion characteristic threshold based on a
supplementary weather dataset. In this example, dynamically
adjusting the motion characteristic threshold can include reducing
the vehicular speed threshold in response to the weather dataset
indicating rainy weather conditions proximal the vehicle
location.
[0109] However, performing threshold satisfaction tests can be
performed in any suitable manner.
3.4.B Generating an Accident Detection Machine Learning Model.
[0110] As shown in FIGS. 1 and 3, Block S140 can optionally include
Block S144, which recites: generating an accident detection machine
learning model. Block S144 functions to train and/or use a machine
learning model for detecting one or more vehicular accident events.
Additionally or alternatively, Block S144 can function to determine
a confidence level associated with whether detected vehicular
accident event actually occurred.
[0111] Block S144 preferably includes training and/or updating one
or more accident detection machine learning models with movement
features (e.g., extracted in Block S130), supplementary features
(e.g., extracted in Block S130), and/or any other suitable
features. Training data can be acquired from collision events
(e.g., single-vehicle accident, multi-vehicle accident, rear-end
collision, head-on accident, side-impact, T-bone collision,
pedestrian collision, hit and run, parking lot accident, major
collision, minor collision, fender bender, vehicle damage
characteristics), non-collision events (e.g., hard braking, rapid
movement, sharp turning, cargo loading, parking, other driving
actions, etc.), and/or any suitable event. Training data can be
collected for different vehicle types (e.g., compact cars,
mid-size, large, SUV, convertible, sedan, truck, commercial car,
etc.), different road types (e.g., streets, highways, dirt paths,
parking lots, non-drivable roads, roundabouts, etc.), different
traffic scenarios (e.g., low traffic, high traffic, different
traffic laws, single-lane traffic, multi-lane traffic, etc.),
different passenger types (e.g., adult, child, female, male, etc.),
different movement-related data (e.g., training data for vehicles
exceeding 30 MPH), different supplemental-related data (e.g.,
training data for poor weather condition scenarios), and/or any
suitable driving-related aspect. For example, Block S144 can
include generating an accident detection machine learning model
from training data including vehicular collision events and
vehicular non-collision events, where the training data is
characterized by a training data motion characteristic value
exceeding a motion characteristic threshold.
[0112] Relating to Block S144, accident detection machine learning
models can output one or more of: whether a vehicular accident
event occurred, accident characteristics (e.g., as described in
Block S160), confidence levels (e.g., associated with vehicular
accident events and/or accident characteristics), and/or any
suitable output.
[0113] However, generating an accident detection machine learning
model S144 can be performed in any suitable manner.
3.5 Initiating an Accident Response Action.
[0114] As shown in FIGS. 1-3, Block S150 includes automatically
initiating one or more accident response actions in response to
detecting a vehicular accident event. Block S150 functions to
appropriately response to a detected vehicular accident event.
[0115] In relation to Block S150, accident response actions can
include any one or more of: presenting an accident-related
notification (e.g., in Block S151), contacting emergency services
(e.g., in Block S152), facilitating insurance processing (e.g., in
Block S153), facilitating communication with a virtual assistant
(e.g., in Block S154), communicating with a mobile computing device
(e.g., in Block S155), storing accident-related data (e.g. storing
movement data and/or supplemental data at a mobile computing
device, at a remote server, etc.) and/or any other suitable types
of response actions.
[0116] Block S150 can include automatically initiating a plurality
of accident response actions (e.g., of the same type, of different
types), etc. Types of accident response actions to perform can be
selected based on one or more: movement datasets, supplemental
datasets, features (e.g., movement features, supplemental
features), accident characteristics (e.g., determined in Block
S160), user preferences (e.g., preferred type of action response
actions, number of action response actions, preferences received at
an application executing on the mobile computing device, etc.),
and/or any other suitable data. For example, Block S150 can include
automatically contacting emergency services (e.g., rather than only
notifying selected user contacts) in response to a vehicular speed
movement feature exceeding a threshold vehicular speed. In another
example, Block S150 can include prompting a user to signify that
he/she is okay if a low-severity accident score accident is
detected, but can include automatically notifying emergency
services if a severe accident is detected. In another example,
Block S150 can include presenting a driver education notification
prompting the user to drive to the side of the freeway in response
to detecting a vehicular accident event on a busy freeway. In
another example, the method 100 can include determining a
mechanical breakdown vehicular accident cause; and automatically
facilitating communications with roadside assistance in response to
identifying the mechanical breakdown. However, dynamically
selecting an accident response action can be performed in any
suitable manner.
[0117] Relating to Block S150, automatically initiating an accident
response action is preferably in response to detecting one or more
vehicular accident events (e.g., in Block S140), but can
additionally or alternatively be initiated at any time proximal a
vehicular accident event (e.g., before, during, and/or after a
vehicular accident event), in response to determining one or more
accident characteristics (e.g., in Block S160), in response to a
request (e.g., through an API, a software development kit, etc.),
based on user preferences, and/or at any suitable time. In an
example, the method 100 can include calculating an accident
confidence metric indicating a degree of confidence in occurrence
of the vehicular accident event; receiving a request from a
third-party service for the accident confidence metric; in response
to receiving the request, automatically initiating an accident
response action of transmitting the accident confidence metric to
the third-party service for initiating a third-party accident
response action.
[0118] However, initiating one or more accident response actions
S150 can be performed in any suitable manner.
3.5.A Accident Response Action--Presenting an Accident-Related
Notification
[0119] In a variation, Block S150 can optionally include Block
S151, which recites: automatically presenting one or more
accident-related notification. Accident-related notifications
preferably inform a suitable entity of vehicular accident
event-related data (e.g., the detection of the accident, movement
data, supplemental data, accident characteristics, etc.), but can
include any suitable accident-related information. Accident-related
notifications can be presented to: authorities (e.g., a local
police station), a service (e.g., emergency services, ride-sharing
services, valet services, mapping services, navigation services,
etc.), user-selected contacts, friends, family, loved ones, and/or
any suitable entity. Accident-related notifications can include
content in the form of one or more of: audio, graphical, verbal,
and/or other suitable form. Further, accident-related notifications
can be in the form of any one or more of: a phone call, a text
message, an e-mail message, a printed message, a human notifier,
and/or any other suitable form. For example, Block S151 can include
in response to detecting a vehicular accident event, identifying a
scheduled event in a calendar application executing on a user
mobile computing device; and e-mailing participants of the
scheduled event that the user was involved in the vehicular
accident event.
[0120] In an example, Block S151 can include generating and/or
transmitting an audio message including accident-related
information (e.g., location data, motion data, accident severity
score, accident type, accident cause, other suitable data). In a
specific example, as shown in FIGS. 6A-6B, the method 100 can
include receiving, at the mobile computing device, a selection from
a user of an emergency contact to notify in response to the
detection of the vehicular accident event, where automatically
initiating an accident response action includes, in response to
detecting the vehicular accident event: automatically generating an
audio message describing the vehicular accident event; initiating a
phone call to the emergency contact through a telecommunications
application programming interface (API, such as Twilio.TM., etc.);
and emitting the audio message during the phone call. Automatically
generating an audio message can be based creating a text prompt
with vehicular accident event information; and inputting the text
prompt into text-to-speech software (e.g., querying a
text-to-speech API with the text prompt). However, any suitable
techniques for personalized audio messaging can be used in
generating and/or transmitting an audio message.
[0121] In another example, as shown in FIG. 8, Block S151 can
include presenting an educational notification. Educational
notifications can include any one or more of: reporting tips (e.g.,
for insurance purposes, for police report purposes, etc.), health
tips (e.g., to guide the user in seeking healthcare if needed),
driving tips (e.g., to avoid future accidents), and/or any other
suitable educational information. In an example, Block S151 can
include generating a driving tip notification based on driving
behavior indicated by at least one of a movement dataset and a
supplementary dataset (e.g., in response to detecting a lane switch
without the driver using signal lights, advising the driver to use
signal lights in future lane switches, etc.). In another example,
Block S151 can include providing a user with a post-accident
checklist (e.g., take pictures, ask if the other party is okay, get
the other party's insurance information, etc.). However, presenting
an educational notification S151 can be performed in any suitable
manner.
[0122] In another example, Block S151 can include transmitting an
accident-related notification to a mapping service (e.g., a
navigation service, a directory, etc.). In a specific example,
Block S151 can include presenting, to a navigation service, an
accident-related notification including GPS coordinates, where the
accident-related notification is configured to facilitate
re-routing of traffic around the accident by the navigation
service.
[0123] In another example, Block S151 can include presenting an
accident-related notification to the owner of the vehicle in
response to detecting a vehicular accident event where the owner
was not present. Notifications presented to the vehicle owner
and/or other related individuals can be used, for example, to
assure customers of ride-sharing and/or valet services of the
safety of vehicles lent to the ride-sharing and/or valet
services.
[0124] However, automatically presenting one or more
accident-related notifications can be performed in any suitable
manner.
3.5.B Accident Response Action--Contacting Emergency Services
[0125] In another variation, Block S150 can optionally include
Block S152, which recites: initiating communication one or more
emergency services. Emergency services can include any one or more
of: police services, firefighter services, medical services,
roadside assistance services (e.g., AAA, towing services, etc.),
and/or any other suitable emergency services. Communications with
emergency services can be in any form analogous to those described
with respect to notifications in Block S151. In an example, as
shown in FIGS. 5A-5B, initiating communication with one or more
emergency services can include, presenting, at the mobile computing
device, a countdown to initiating a phone call with an emergency
service (e.g., 911); providing, at the mobile computing device, a
cancellation option to stop the countdown; and preventing the phone
call in response to user selection of the cancellation option. In
another example, as shown in FIG. 7, Block S152 can include
enabling roadside service assistance for the vehicular accident
event. In this example, Block S152 can include providing an
estimated time of arrival for the road side service assistance.
[0126] In relation. Block S152, communications transmitted to
emergency services preferably include accident-related information
(e.g., movement data, supplemental data, accident characteristics,
etc.). In an example, the method 100 can include receiving a camera
dataset captured at a camera mounted to the vehicle; determining a
number of passengers in the vehicle from the camera dataset, where
the audio sample includes the number of passengers in the vehicle
(e.g., in addition to GPS coordinates associated with the vehicular
accident event and/or other suitable information). In this example,
emergency services equipped with information regarding the number
of passengers can appropriately allocate resources according to
characteristics of the accident (e.g., multiple ambulance vehicles
for a multi-passenger accident of high severity, etc.). In another
example, the method 100 can include: generating an audio sample
including GPS coordinates associated with the vehicular accident
event, where the GPS coordinates are derived from a location
dataset (e.g., received in response to an extracted vehicle motion
characteristic exceeding a threshold motion characteristic); and
transmitting the audio sample to an emergency service. In another
example, Block S152 can include automatically pre-filling a police
report with accident-related information; and transmitting the
police report to local authorities.
[0127] However, contacting emergency services S152 can be performed
in any suitable manner.
3.5.C Accident Response Action--Promoting Insurance Processing
[0128] In another variation, Block S150 can additionally or
alternatively include Block S153, which recites: promoting
insurance processing. Insurance processing can include any one or
more of: pre-filling insurance claims, insurance education,
transmitting accident-related information to an insurance company
and/or related entities, and/or any other suitable action.
[0129] In an example, Block S153 can include automatically
initiating a first notice of loss (FNOL) for alerting insurance
companies associated with participants in the vehicular accident
event. In another example, Block S153 can include receiving, at a
mobile computing device, a selection from a user permitting
information release to an insurance company, where the user is
driving the vehicle during the time period, and where automatically
initiating the accident response action includes automatically
transmitting, to the insurance company, accident-related
information derived from the movement dataset and associated with
the vehicular accident event. In another example, Block S153 can
include guiding a vehicular accident event participant through
actions to take for properly filing an insurance claim (e.g.,
information to obtain, documents to file, questions to ask
different parties, etc.). In another example, Block S153 can
include deriving accident-related information from one or more
camera datasets (e.g., captured by a mobile computing device,
captured by a vehicular camera, etc.), and automatically preparing
an insurance claim with the accident-related information. In
another example, insurance-related information can be derived from
social network data associated with one or more participants in the
vehicular accident event.
[0130] Additionally or alternatively, Block S153 can include any
elements described in U.S. application Ser. No. 14/566,408 filed 10
Dec. 2014 and entitled "System and Method for Assessing Risk
through a Social Network," which is hereby incorporated in its
entirety by this reference.
[0131] However, facilitating insurance processing can be performed
in any suitable manner.
3.5.D. Accident Response Action--Enabling Communication with a
Virtual Assistant
[0132] In another variation, Block S150 can additionally or
alternatively include Block S154, which recites: enabling
communication with a virtual assistant. A virtual assistant
preferably aids with tasks related to vehicular accident events,
including communications with services (e.g., emergency services,
roadside assistance services, etc.) police reporting, insurance
processing, post-accident tasks, questions to ask, data to capture
(e.g., photos and/or video to capture, etc.), and/or any other
suitable task. Virtual assistants can include any one or more of: a
chat bot, vocal input bot, media bot, analysis bot, technical
support bot, decision support bot, and/or any other suitable
virtual assistant. In examples, Block S154 can include
automatically generating an automated script for a virtual
assistant, wherein automatic generation includes defining trigger
patterns (e.g., patterns associated with a user question) and
responses (e.g., a reply for the virtual assistant to transmit;
actions to take such as querying a search engine, etc.) to an
identified trigger pattern. However, determining virtual assistant
inputs (e.g., triggers), outputs (e.g., responses), parameters
(e.g., personality, etc.), and/or other related aspects can be
based on natural language processing, artificial intelligence,
and/or other suitable virtual assistant development tool.
[0133] In an example, Block S154 can include generating an
automated script for a virtual assistant bot to follow regarding
insurance processing (e.g., for guiding a user through the steps of
filing an insurance claim for the vehicular accident event). In
another example, Block S154 can include presenting, through a
virtual assistant, a set of options for services for aiding with
the vehicular accident event; receiving, from a user in
communication with the virtual assistant, a roadside assistance
service selection from the set of options for services; and
transmitting a roadside service request to the roadside assistance
service.
[0134] However, facilitating communications with a virtual
assistance can be performed in any suitable manner.
3.5.E Accident Response Action--Communicating with a Mobile
Computing Device
[0135] In another variation, Block S150 can additionally or
alternatively include Block S155, which recites: communicating with
a mobile computing device (e.g., a vehicle control panel, a medical
device within the vehicle, a mobile computing device distinct from
the mobile computing device collecting the movement dataset used in
detecting the vehicular accident event, etc.). Communications with
one or more mobile computing devices preferably includes
controlling the one or more mobile computing devices to perform an
accident-related operation to assist a participant in the vehicular
accident event.
[0136] In an example, Block S155 can include transmitting
accident-related information to a vehicle involved in the vehicular
accident event, where the transmission is configured to enable
accident services provided by the vehicle (e.g., in-vehicle
security services, airbag deployment, emergency lights, etc.). In
another example, Block S155 can include initiating communication
with a medical device associated with the user. In a specific
example, the method 100 can include: in response to detecting a
vehicular accident event, automatically prompting (e.g., through a
request transmitted by a smart phone) a medical device coupled to
the user to collect cardiovascular data (e.g., heart rate data,
blood pressure data, etc.) of the user; and transmitting the
cardiovascular data in a communication with emergency services. In
this specific example, emergency services such as a healthcare
provider can leverage the cardiovascular data collected proximal
the time period of the vehicular accident event in order to tailor
healthcare to the harm caused.
[0137] In examples, Block S155 can include outputting therapeutic
interventions at a mobile computing device. In a specific example,
Block S155 can include promoting an stress-relieving intervention
(e.g., calming audio, therapeutic stimulation, reassuring
notifications, guided exercises, etc.) configured to relieve stress
of a participant in the vehicular accident event. In this specific
example, stress-relieving interventions can enable a driver and/or
other accident participant to focus and respond properly to the
vehicular accident event.
[0138] However, communicating with a mobile computing device can be
performed in any suitable manner.
3.6 Determining an Accident Characteristic.
[0139] The method 100 can optionally include Block S160, which
recites: determining one or more accident characteristics
associated with the vehicular accident event. Block S160 functions
to determine one or more characteristics regarding a detected
vehicular accident event, in order to facilitate provision of an
accident response action (e.g., in Block S150). For example, the
method 100 can include selecting a personalized accident response
action from a set of accident response actions, based on one or
more accident characteristics (e.g., vehicular accident type). In a
specific example, the method 100 can include in response to
determining one or more accident characteristics (e.g., vehicular
accident type), automatically pre-filling, at the mobile computing
device, an insurance claim with the one or more accident
characteristics. However, accident characteristics can be used for
any suitable purpose.
[0140] In relation to Block S160, determining accident
characteristics can include determining any one or more of:
accident meta-information (e.g., in Block S161), accident severity
score (e.g., in Block S162), accident type (e.g., in Block S163),
accident cause (e.g. in Block S164), and/or any other suitable
accident characteristic data.
[0141] Determining accident characteristics S160 is preferably
based on movement data (e.g., movement features). For example, the
Block S160 can include determining a vehicular accident type
describing the vehicular accident event, based on at least one of
the a location dataset and a motion dataset, where the location and
motion datasets are received in response to a vehicle motion
characteristic (e.g., extracted in Block S140 from a location
dataset and/or motion dataset collected at an earlier time)
exceeding a threshold motion characteristic. Additionally or
alternatively, determining accident characteristics can be based on
supplementary data and/or any other suitable accident-related
information.
[0142] In relation to Block S160, determining accident
characteristics is preferably based on processing with an accident
characteristic model (e.g., an accident characteristic machine
learning model, an accident characteristic decision tree model,
etc.), but can additionally or alternatively be based on
comparisons with accident characteristic thresholds, accident
characteristic reference profiles, and/or any suitable
mechanism.
[0143] For Block S160, determining accident characteristics is
preferably performed substantially concurrently with detecting a
vehicular accident event. Additionally or alternatively,
determining accident characteristics can be performed after a
vehicular accident event (e.g., in response to a user manually
inputting accident-related information at the mobile computing
device), and/or at any suitable time. Block S160 can be performed
at a mobile computing device, remote server (e.g., in response to
the remote server receiving accident-related information from
multiple mobile computing devices), and/or at any suitable
component.
3.6.a Accident Characteristics--Determining Accident
Meta-Information
[0144] In a variation, Block S160 can include Block S161, which
recites: determining accident meta-information. Accident
meta-information can include any one or more of: driver data (e.g.,
driver identifier, driver behavior, etc.), accident location (e.g.,
GPS coordinates), temporal indicators (e.g., timestamp, duration of
accident, duration of driving session, etc.), driving session
identifier, tracking identifier, accident identifier, confidence
metrics (e.g., confidence levels associated with detected vehicular
accident event, confidence levels associated with accident
characteristics, etc.), and/or any other suitable meta-information
regarding a vehicular accident event. In an example, the method 100
can include calculating an accident confidence metric indicating a
degree of confidence in occurrence of the vehicular accident event,
based on at least one of the second location dataset and the second
motion dataset; selecting a personalized accident response action
from a set of accident response actions, based on the accident
confidence metric, and where the personalized accident response
action is the accident response action automatically initiated in
response to detecting the vehicular accident event.
[0145] However, determining accident meta-information S161 can be
performed in any suitable manner.
3.6.B Accident Characteristics--Generating an Accident Severity
Score
[0146] In another variation, Block S160 can include Block S162,
which includes generating an accident severity score. An accident
severity score preferably provides an indication of how severe an
accident might be (e.g., as measured with respect to vehicle
damage, property damage, and/or injury to vehicle occupants or
others), but can be otherwise defined. Accident severity scores are
preferably generated based on movement data (e.g., measured
acceleration magnitude, acceleration direction, pre-impact speed,
etc.), but can additionally or alternatively be based on
supplemental data, other accident characteristics, and/or any
suitable data. For example, the method 100 can include determining
an accident severity score based on a set of proximity features
(e.g., extracted from proximity data collected at a vehicle
proximity sensor) and the set of movement features; and selecting a
personalized accident response action from a set of accident
response actions, based on the accident severity score, and where
the personalized accident response action is the accident response
action. In another example, generating an accident severity score
can include interpreting speech recorded by microphones of the
navigation device; speech can be interpreted based on meaning
(e.g., accident severity can be detected based on what people say)
and/or emotion (e.g., accident severity can be detected based on
identified emotions). Likewise, Block S162 can include interpreting
vehicle sensor data (e.g., whether airbags deployed or not) as a
measure of accident severity.
[0147] In relation to Block S162, accident severity scores are
preferably generated by a single algorithm that takes into account
accident severity variables (as discussed below), but can
additionally or alternatively be generated according to different
algorithms for different operating states. For example, one
accident severity score algorithm can be used for pre-impact speeds
of 30-50 MPH, while another accident severity score algorithm can
be used for pre-impact speeds of 50-80 MPH.
[0148] Relating to Block S162, examples of accident severity
variables include measured acceleration magnitude, measured
acceleration direction (e.g., relative to travel direction),
measured angular acceleration, measured velocity, acceleration
profile (e.g., acceleration vs. time graph, this can be used to
infer braking profile), velocity profile, measured position,
vehicle stopping distance (e.g., as compared to typical emergency
stopping distances), navigation device free-fall time (e.g., time
where gravity is the primary acceleration acting upon the
navigation device), impact noise magnitude, and measured movement
data of surrounding traffic.
[0149] For Block S162, generating accident severity scores can
include generating accident severity sub-scores. For example, S133
can include generating a free-fall score, a braking profile score,
and a stopping distance score, each of which measure accident
severity according to free-fall time, braking profile, and vehicle
stopping distance respectively. From these three sub-scores, the
accident severity score can be generated in any manner (e.g., the
average of the three values, the maximum of the three values,
etc.).
[0150] However, generating an accident severity score S162 can be
performed in any suitable manner.
3.6.0 Accident Characteristics--Determining an Accident Type
[0151] In another variation, Block S160 can include Block S163,
which recites: determining an accident type of the vehicular
accident event. Accident types can include any one or more of:
single-vehicle accident, multi-vehicle accident, rear-end
collision, head-on accident, side-impact, T-bone collision,
pedestrian collision, hit and run, parking lot accident, major
collision, minor collision, fender bender, vehicle damage
characteristics, and/or any other suitable accident type.
Multi-vehicle accident types can include accident types indicating
the size of the vehicles involved (e.g., compact, mid-size, large,
SUV, convertible, sedan, truck, commercial car, etc.). Vehicle
damage characteristics can include any one or more of: vehicular
damage location (e.g., rear, front, side, tires, etc.), mechanical
damage (e.g., engine damage, brakes damage, etc.), electrical
damage, and/or any other suitable damage type. Vehicle sizes of
vehicles involved in a vehicular accident event can inform the
determination of accident severity score, indications of fault,
and/or other suitable accident characteristics. For example,
determining that the vehicular accident event was a multi-vehicle
accident involving a commercial truck and a convertible can
indicate an accident of greater severity. In this example, the
method 100 can include training an accident detection machine
learning model with movement-related training data (e.g., position,
velocity, acceleration profiles etc.) collected from multi-vehicle
collisions involving different combinations of vehicle sizes (e.g.,
compact vs. mid-size, compact vs. large, mid-size vs. large); and
identifying the relative size of vehicles involved in a vehicular
accident event by processing a movement dataset and/or supplemental
dataset with the accident detection machine learning model. In
another example, Block S163 can include generating an analysis of
vehicular acceleration over time; comparing the analysis to
reference profiles for a single-vehicle accident (e.g., a vehicle
crashing into a highway guardrail) and a multi-vehicle accident
(e.g., a vehicle crashing into another vehicle while changing
lanes); and identifying a multi-vehicular accident in response to
detecting a greater similarity between the analysis and the
reference profile for a multi-vehicular accident. In a specific
example, identifying a single-vehicle accident type of a vehicle
crashing head-on into a stationary object can be based on
calculating a more negative slope in acceleration measured over
time compared to a reference acceleration profile for a
multi-vehicle accident type of a first vehicle side-swiping a
second vehicle.
[0152] In another example, Block S163 can include determining an
irregular change in tire pressure during a time period in which a
vehicular accident event is detected; and identifying, based on the
irregular change in tire pressure, a vehicle damage characteristic
of tire damage resulting from the vehicular accident event. In
another example, the method 100 can include collecting horizontal
vehicle movement data (e.g., parallel the road); extracting turning
movement features (e.g., left turn, right turn, turn radius, etc.)
form the horizontal vehicle movement data; and in response to the
turning movement features indicating a sharp turn, determining a
high probability of a side collision (e.g., a T-bone accident).
However, determining an accident type S163 can be performed in any
suitable manner.
3.6.D Accident Characteristics--Determining an Accident Cause
[0153] In another variation, Block S160 can include Block S164,
which recites: determining one or more causes of a vehicular
accident event. Accident causes can include: indications of fault
(e.g., which driver was at fault, proportion of fault allocated to
different drivers and/or other entities, etc.), identification of
entities involved in the accident (e.g., pedestrians, other
vehicles, other drivers, passengers, etc.), driver behavior, and/or
any other suitable potential cause of a vehicular accident
event.
[0154] In relation to Block S164, identifying one or more accident
causes is preferably based on at least one of a movement dataset
and a supplemental dataset. For example, the method 100 can include
detecting a two-vehicle collision between a first driver and a
second driver; assigning a higher proportion of fault to the first
driver based on a first movement dataset describing a first driver
vehicular speed exceeding the speed limit identified from a traffic
dataset, and based on a second movement dataset describing a second
driver vehicular speed below the speed limit. In another example,
the method 100 can include detecting a pedestrian collision from
processing a movement dataset with an accident detection model, and
determining an accident cause of an illegal left turn based on
horizontal-axis accelerometer data from the movement dataset and a
traffic dataset describing the traffic laws associated with the
intersection at the site of the accident.
[0155] In examples, Block S164 can include identifying one or more
accident causes from movement data and/or supplemental data
collected prior to and/or after a vehicular accident event. In an
example, Block S164 can include generating an analysis of video
data capture prior to a vehicular accident event; and determining
an accident cause based on the analysis. In a specific example,
video data showing a second vehicle merging into a lane of a first
vehicle can indicate the cause of a side-collision multi-vehicular
accident event. In another example, Block S164 can include
collecting rear proximity sensor (e.g., positioned proximal the
trunk of the vehicle) data for a first vehicle during a time period
prior to detecting a rear-end collision between the first vehicle
and a second vehicle crashing into the rear of the first vehicle;
generating an analysis of the rear proximity sensor data and
movement-related data of the first vehicle during the time period;
and assigning a higher proportion of fault to the second vehicle in
response to the analysis indicating a stationary position of first
vehicle and a lack of deceleration by the second vehicle. In
another example, failing to identify sharp changes in movement data
of a first vehicle prior to a side-collision vehicular accident
event can indicate greater fault for a second vehicle that merged
into a lane in which the first vehicle was traveling. In another
example, Block S164 can include recording conversational audio
between vehicular accident event participants and/or witnesses
during a time period subsequent the vehicular accident event, and
determining an allocation of fault between parties based on the
conversational audio (e.g., by parsing the audio to identify
admissions by a participant, observations from a witness, etc.).
However, accident cause identification can be based on any suitable
data.
[0156] Relating to Block S164, accident cause information is
preferably used in initiating an accident response action. For
example, the method 100 can include determining accident cause
information based on at least one of a movement dataset and a
supplemental dataset; and automatically generating a portion of an
insurance claim including the accident cause information. In
another example, the method 100 can include identifying an accident
cause (e.g., an illegal U-turn from a nearby driver); and
transmitting information regarding the illegal vehicular maneuver
to local authorities (e.g., through automatically filling a police
report with the information). However, accident cause information
can be used for any suitable purpose.
[0157] However, determining one or more accident causes S164 can be
performed in any suitable manner.
3.7 Receiving Accident Detection Feedback
[0158] The method 100 can optionally include Block S170, which
recites: receiving accident detection feedback. Block S170
functions to receive feedback post-accident that can be used to
measure accident severity (and thus calibrate and/or train the
accident severity score generation algorithm).
[0159] Post-accident feedback can include any measure of accident
severity, including user survey data (e.g., prompting a user to
describe or rate the severity of the accident), accident reports,
insurance claims, or any other data.
[0160] For example, S170 can include prompting a user to state if
their vehicle can move under its own power. This data can be useful
for both S140 (e.g., a tow truck can be contacted if the answer is
no) and S160 (e.g., car being moveable being an indication of lower
accident severity).
[0161] In a variation of a preferred embodiment, S170 includes
measuring movement data and/or supplementary data post-accident to
derive vehicle status information. For example, a vehicle moving
shortly after an accident can be a sign that the accident was not
very severe. As another example, changes in vehicle status
information or accelerometer data recorded under normal driving can
reflect damage to the vehicle (e.g., high oil pressure/temperature
or unusual vibrations detected by accelerometer can be indications
of vehicle damage).
[0162] S170 can include collecting any manner of post-accident
feedback in any suitable manner, at any suitable time (e.g., months
post-accident).
4. System.
[0163] As shown in FIG. 4, an embodiment of a system 200 for
detecting a vehicular accident includes a processing system 205
including: a first module 210 configured to receive a movement
dataset collected during a time period of vehicle movement; a
second module 220 configured to receive a supplemental dataset
during the time period; a third module 230 configured to extract a
set of movement features associated with at least one of a
position, a velocity, and an acceleration characterizing the
movement of the vehicle during the time period; a fourth module 240
configured to detect a vehicular accident event from processing the
set of movement features with an accident detection model; and a
fifth module 250 configured to automatically initiate an accident
response action in response to detecting the vehicular accident
event. Additionally or alternatively, the system can include a
sixth module 260 configured to determine an accident
characteristic, and/or a seventh module configured to receive
accident detection feedback. The system 200 functions to enable
detection of one or more vehicular accident events based on
movement data (e.g., relating to position, velocity, and/or
acceleration) and/or supplemental data. Additionally or
alternatively, the method 100 can function to identify one or more
accident characteristics characterizing a detected vehicular
accident event.
[0164] The system 200 can incorporate, at least in part,
embodiments, variations, and examples of elements of the system
described in U.S. application Ser. No. 14/566,408 filed 10 Dec.
2014 and entitled "System and Method for Assessing Risk through a
Social Network," and U.S. application Ser. No. 14/206,721 filed 12
Mar. 2014 and entitled "System and Method for Determining a Driver
in a Telematic Application," which are each hereby incorporated in
their entirety by this reference.
[0165] Database(s) and/or portions of the method 100 can be
entirely or partially executed, run, hosted, or otherwise performed
by: a mobile computing device, a remote computing system (e.g., a
server, at least one networked computing system, stateless
computing system, stateful computing system, etc.), a machine
configured to receive a computer-readable medium storing
computer-readable instructions, or by any other suitable computing
system possessing any suitable component (e.g., a graphics
processing unit, a communications module, etc.). Mobile computing
devices implementing at least a portion of the method 100 can
include one or more of: a smartphone, a wearable computing device
(e.g., head-mounted wearable computing device, a smart watch, smart
glasses), tablet, desktop, a supplemental biosignal detector, a
supplemental sensor (e.g., motion sensors, magnetometers, audio
sensors, video sensors, location sensors a motion sensor, a light
sensor, etc.), a medical device, and/or any other suitable device.
All or portions of the method 100 can be performed by one or more
of: a native application, web application, firmware on the device,
plug-in, and any other suitable software executing on a device.
Device components used with the method 100 can include an input
(e.g., keyboard, touchscreen, etc.), an output (e.g., a display), a
processor, a transceiver, and/or any other suitable component,
where data from the input device(s) and/or output device(s) can be
generated, analyzed, and/or transmitted to entities for consumption
(e.g., for a user to assess their health parameters) Communication
between devices and/or databases can include wireless communication
(e.g., WiFi, Bluetooth, radiofrequency, etc.) and/or wired
communication.
[0166] However, the components of the system 200 can be distributed
across machine and cloud-based computing systems in any other
suitable manner.
[0167] The system 200 is preferably configured to facilitate
reception and processing of movement data and/or supplementary
data, but can additionally or alternatively be configured to
receive and/or process any other suitable type of data. As such,
the processing system 205 can be implemented on one or more
computing systems including one or more of: a cloud-based computing
system (e.g., Amazon EC3), a mainframe computing system, a
grid-computing system, and any other suitable computing system.
Furthermore, reception of data by the processing system 205 can
occur over a wired connection and/or wirelessly (e.g., over the
Internet, directly from a natively application executing on an
electronic device of the patient, indirectly from a remote database
receiving data from a mobile computing device, etc.).
[0168] However, one or more mobile computing devices, vehicles,
remote servers, and/or other suitable computing systems can be
communicably connected (e.g., wired, wirelessly) through any
suitable communication networks. For example, a non-generalized
mobile computing device (e.g., smartphone including at least one of
a location sensor and motion sensor, etc.) can be configured to
collect a movement dataset, to receive additional movement datasets
from the vehicle (e.g., OBD port) and/or other mobile computing
devices (e.g., a wearable fitness tracker coupled to the driver's
wrist), and to detect a vehicular accident event with the collected
data, where the mobile computing device, the vehicle, and the other
mobile computing devices are communicably connected through one or
more wireless links (e.g., Bluetooth). In another example, a remote
server can be configured to receive movement data from a vehicle
and a mobile computing device, to detect a vehicular accident event
based on the received data, and to automatically contact emergency
services (e.g., through a telecommunications API), where the a
remote server, vehicle, and mobile computing device are connected
over a wireless network. However, the system 200 can include any
suitable configuration of non-generalized computing systems
connected in any combination to one or more communication
networks.
[0169] Components of the system 200 and/or any suitable portion of
the method 100 can employ machine learning approaches including any
one or more of: supervised learning (e.g., using logistic
regression, using back propagation neural networks, using random
forests, decision trees, etc.), unsupervised learning (e.g., using
an Apriori algorithm, using K-means clustering), semi-supervised
learning, reinforcement learning (e.g., using a Q-learning
algorithm, using temporal difference learning), and any other
suitable learning style. Each module of the plurality can implement
any one or more of: a regression algorithm (e.g., ordinary least
squares, logistic regression, stepwise regression, multivariate
adaptive regression splines, locally estimated scatterplot
smoothing, etc.), an instance-based method (e.g., k-nearest
neighbor, learning vector quantization, self-organizing map, etc.),
a regularization method (e.g., ridge regression, least absolute
shrinkage and selection operator, elastic net, etc.), a decision
tree learning method (e.g., classification and regression tree,
iterative dichotomiser 3, C4.5, chi-squared automatic interaction
detection, decision stump, random forest, multivariate adaptive
regression splines, gradient boosting machines, etc.), a Bayesian
method (e.g., naive Bayes, averaged one-dependence estimators,
Bayesian belief network, etc.), a kernel method (e.g., a support
vector machine, a radial basis function, a linear discriminate
analysis, etc.), a clustering method (e.g., k-means clustering,
expectation maximization, etc.), an associated rule learning
algorithm (e.g., an Apriori algorithm, an Eclat algorithm, etc.),
an artificial neural network model (e.g., a Perceptron method, a
back-propagation method, a Hopfield network method, a
self-organizing map method, a learning vector quantization method,
etc.), a deep learning algorithm (e.g., a restricted Boltzmann
machine, a deep belief network method, a convolution network
method, a stacked auto-encoder method, etc.), a dimensionality
reduction method (e.g., principal component analysis, partial lest
squares regression, Sammon mapping, multidimensional scaling,
projection pursuit, etc.), an ensemble method (e.g., boosting,
boostrapped aggregation, AdaBoost, stacked generalization, gradient
boosting machine method, random forest method, etc.), and any
suitable form of machine learning algorithm. Each processing
portion of the method 100 can additionally or alternatively
leverage: a probabilistic module, heuristic module, deterministic
module, or any other suitable module leveraging any other suitable
computation method, machine learning method or combination
thereof.
[0170] The method 100 and/or system 200 of the embodiments can be
embodied and/or implemented at least in part as a machine
configured to receive a computer-readable medium storing
computer-readable instructions. The instructions can be executed by
computer-executable components integrated with the application,
applet, host, server, network, website, communication service,
communication interface, hardware/firmware/software elements of a
patient computer or mobile device, or any suitable combination
thereof. Other systems and methods of the embodiments can be
embodied and/or implemented at least in part as a machine
configured to receive a computer-readable medium storing
computer-readable instructions. The instructions can be executed by
computer-executable components integrated with apparatuses and
networks of the type described above. The computer-readable medium
can be stored on any suitable computer readable media such as RAMs,
ROMs, flash memory, EEPROMs, optical devices (CD or DVD), hard
drives, floppy drives, or any suitable device. The
computer-executable component can be a processor, though any
suitable dedicated hardware device can (alternatively or
additionally) execute the instructions.
[0171] The FIGURES illustrate the architecture, functionality and
operation of possible implementations of systems, methods and
computer program products according to preferred embodiments,
example configurations, and variations thereof. In this regard,
each block in the flowchart or block diagrams can represent a
module, segment, step, or portion of code, which includes one or
more executable instructions for implementing the specified logical
function(s). It should also be noted that, in some alternative
implementations, the functions noted in the block can occur out of
the order noted in the FIGURES. For example, two blocks shown in
succession may, in fact, be executed substantially concurrently, or
the blocks can sometimes be executed in the reverse order,
depending upon the functionality involved. It will also be noted
that each block of the block diagrams and/or flowchart
illustration, and combinations of blocks in the block diagrams
and/or flowchart illustration, can be implemented by special
purpose hardware-based systems that perform the specified functions
or acts, or combinations of special purpose hardware and computer
instructions.
[0172] As a person skilled in the art will recognize from the
previous detailed description and from the figures and claims,
modifications and changes can be made to the embodiments of the
invention without departing from the scope of this invention as
defined in the following claims.
* * * * *