▶ ケンブリッジ モバイル テレマティクス，インク．の特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-08-31
(54)【発明の名称】総損失イベントを予測する方法およびシステム
(51)【国際特許分類】
B60R 21/0136 20060101AFI20230824BHJP
B60W 50/14 20200101ALI20230824BHJP
G06N 20/00 20190101ALI20230824BHJP
B60W 30/08 20120101ALI20230824BHJP
B60R 21/01 20060101ALI20230824BHJP
G07C 5/00 20060101ALI20230824BHJP
【ＦＩ】
B60R21/0136
B60W50/14
G06N20/00
B60W30/08
B60R21/01 321
G07C5/00 Z
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023501761
(86)(22)【出願日】2021-07-14
(85)【翻訳文提出日】2023-03-13
(86)【国際出願番号】 US2021041659
(87)【国際公開番号】W WO2022015871
(87)【国際公開日】2022-01-20
(31)【優先権主張番号】63/051,727
(32)【優先日】2020-07-14
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】17/374,684
(32)【優先日】2021-07-13
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＡＮＤＲＯＩＤ
(71)【出願人】
【識別番号】517411036
【氏名又は名称】ケンブリッジ モバイル テレマティクス，インク．
【氏名又は名称原語表記】ＣＡＭＢＲＩＤＧＥ ＭＯＢＩＬＥ ＴＥＬＥＭＡＴＩＣＳ， ＩＮＣ．
(74)【代理人】
【識別番号】100137969
【弁理士】
【氏名又は名称】岡部 憲昭
(74)【代理人】
【識別番号】100104824
【弁理士】
【氏名又は名称】穐場 仁
(74)【代理人】
【識別番号】100121463
【弁理士】
【氏名又は名称】矢口 哲也
(72)【発明者】
【氏名】クイ，ユティング
(72)【発明者】
【氏名】ヤング，コーネリアス
(72)【発明者】
【氏名】シャリフ，リズキー
(72)【発明者】
【氏名】エレム，ブラク
【テーマコード（参考）】
3D241
3E138
【Ｆターム（参考）】
3D241BA31
3D241BA50
3D241BA62
3D241BB59
3D241BB72
3D241BB74
3D241CE02
3D241CE04
3D241CE08
3D241DA49Z
3D241DC05Z
3D241DC51Z
3D241DD04Z
3E138AA07
3E138MA02
3E138MB03
3E138MC03
3E138MD05
3E138MF06
(57)【要約】
総損失イベントの信頼度を予測するための技術が開示される。モバイルデバイスは、モバイルデバイスの１つまたは複数のセンサを使用してクラッシュイベントを検出する。モバイルデバイスは、モバイルデバイスの１つまたは複数のセンサからの第１のデータセットを記録する。モバイルデバイスは、第１のデータセットと、車両の識別子を含む車両データとを含む第１の特徴ベクトルを生成する。モバイルデバイスは、第１のデータセットおよび追加のデータタイプを使用して第２の特徴ベクトルを生成する。モバイルデバイスは、第１の特徴ベクトルを使用して第１の機械学習モデルから第１の信頼値を生成し、第２の特徴ベクトルを使用して第２の機械学習モデルから第２の信頼値を生成することによって、総損失イベントの信頼度を予測する。
【選択図】図４
【選択図】図４
【特許請求の範囲】
【請求項1】
モバイルデバイスが車両内に配置されている間に、前記モバイルデバイスの１つまたは複数のセンサからセンサ測定値を受信するステップと、前記センサ測定値を使用して、車両衝突の発生を示すクラッシュイベントを検出するステップと、
前記センサ測定値から第１のデータセットを識別するステップであって、前記第１のデータセットが前記クラッシュイベントに関連付けられる、ステップと、
前記第１のデータセットおよび車両データを使用して第１の特徴ベクトルを生成するステップであって、前記車両データが前記車両の識別子を含む、ステップと、
前記第１のデータセットおよび１つまたは複数の追加のデータタイプを使用して第２の特徴ベクトルを生成するステップと、
総損失イベントの信頼度を予測するステップであって、
第１の機械学習モデルおよび前記第１の特徴ベクトルを使用して第１の信頼値を生成するステップと、
第２の機械学習モデルおよび前記第２の特徴ベクトルを使用して第２の信頼値を生成するステップと、によって予測するステップと、
前記総損失イベントの前記信頼度の表示を含む通知を送信するステップと、
を含む方法。
【請求項2】
前記第１の特徴ベクトルを生成するステップが、前記第１のデータセットからクラッシュ特徴のセットを抽出するステップであって、前記クラッシュ特徴のセットが、前記クラッシュイベントが発生した時点における前記車両のセンサデータを表す、ステップと、
前記車両データから車両特徴のセットを抽出するステップと、
前記クラッシュ特徴のセットと前記車両特徴のセットとを組み合わせるステップと、
を含む、請求項１に記載の方法。
【請求項3】
前記総損失イベントが、前記車両が前記クラッシュイベント中に前記車両の値よりも大きい損傷レベルを被ったという判定に関連付けられる、請求項１に記載の方法。
【請求項4】
前記１つまたは複数の追加のデータタイプがエアバッグ作動データタイプを含む、請求項１に記載の方法。
【請求項5】
前記総損失イベントの前記信頼度を予測するステップが、前記第２の特徴ベクトルを使用して第３の特徴ベクトルを生成するステップであって、前記第３の特徴ベクトルが、前記１つまたは複数の追加のデータタイプについて異なる値を含む、ステップと、
前記第２の機械学習モデルおよび前記第３の特徴ベクトルを使用して第３の信頼値を生成するステップと、
をさらに含む、請求項１に記載の方法。
【請求項6】
前記１つまたは複数の追加のデータタイプが流体漏れインジケータを含む、請求項１に記載の方法。
【請求項7】
前記第１の信頼値と前記第２の信頼値との間の差がしきい値よりも大きいと判定するステップと、前記第１の信頼値と前記第２の信頼値との間の前記差が前記しきい値よりも大きいという判定に応答して、追加情報の要求を送信するステップと、
をさらに含む、請求項１に記載の方法。
【請求項8】
１つまたは複数のプロセッサと、命令を格納する非一時的コンピュータ可読媒体と、を含み、前記命令は、前記１つまたは複数のプロセッサによって実行されると、前記システムを、
モバイルデバイスが車両内に配置されている間に、前記モバイルデバイスの１つまたは複数のセンサからセンサ測定値を受信し、
前記センサ測定値を使用して、車両衝突の発生を示すクラッシュイベントを検出し、
前記センサ測定値から第１のデータセットを識別し、前記第１のデータセットが前記クラッシュイベントに関連付けられ、
前記第１のデータセットおよび車両データを使用して第１の特徴ベクトルを生成し、前記車両データが前記車両の識別子を含み、
前記第１のデータセットおよび１つまたは複数の追加のデータタイプを使用して第２の特徴ベクトルを生成し、
総損失イベントの信頼度を、
第１の機械学習モデルおよび前記第１の特徴ベクトルを使用して第１の信頼値を生成するステップと、
第２の機械学習モデルおよび前記第２の特徴ベクトルを使用して第２の信頼値を生成するステップと、によって予測し、
前記総損失イベントの前記信頼度の表示を含む通知を送信する、ように構成するシステム。
【請求項9】
前記第１の特徴ベクトルを生成するステップは、前記第１のデータセットからクラッシュ特徴のセットを抽出するステップであって、前記クラッシュ特徴のセットが、前記クラッシュイベントが発生した時点における前記車両のセンサデータを表す、ステップと、
前記車両データから車両特徴のセットを抽出するステップと、
前記クラッシュ特徴のセットと前記車両特徴のセットとを組み合わせるステップと、
をさらに含む、請求項８に記載のシステム。
【請求項10】
前記総損失イベントが、前記車両が前記クラッシュイベント中に前記車両の値よりも大きい損傷レベルを被ったという判定に関連付けられる、請求項８に記載のシステム。
【請求項11】
前記１つまたは複数の追加のデータタイプがエアバッグ作動データタイプを含む、請求項８に記載のシステム。
【請求項12】
前記総損失イベントの前記信頼度を予測するステップが、前記第２の特徴ベクトルを使用して第３の特徴ベクトルを生成するステップであって、前記第３の特徴ベクトルが、前記１つまたは複数の追加のデータタイプについて異なる値を含む、ステップと、
前記第２の機械学習モデルおよび前記第３の特徴ベクトルを使用して第３の信頼値を生成するステップと、
をさらに含む、請求項８に記載のシステム。
【請求項13】
前記１つまたは複数の追加のデータタイプが流体漏れインジケータを含む、請求項８に記載のシステム。
【請求項14】
前記命令は、前記システムを、前記第１の信頼値と前記第２の信頼値との間の差がしきい値よりも大きいと判定し、
前記第１の信頼値と前記第２の信頼値との間の前記差が前記しきい値よりも大きいという判定に応答して、追加情報の要求を送信する、
ようにさらに構成する、請求項８に記載のシステム。
【請求項15】
命令を格納する非一時的コンピュータ可読媒体であって、前記命令は、１つまたは複数のプロセッサによって実行されると、前記１つまたは複数のプロセッサに、モバイルデバイスが車両内に配置されている間に、前記モバイルデバイスの１つまたは複数のセンサからセンサ測定値を受信するステップと、
前記センサ測定値を使用して、車両衝突の発生を示すクラッシュイベントを検出するステップと、
前記センサ測定値から第１のデータセットを識別するステップであって、前記第１のデータセットが前記クラッシュイベントに関連付けられる、ステップと、
前記第１のデータセットおよび車両データを使用して第１の特徴ベクトルを生成するステップであって、前記車両データが前記車両の識別子を含む、ステップと、
前記第１のデータセットおよび１つまたは複数の追加のデータタイプを使用して第２の特徴ベクトルを生成するステップと、
総損失イベントの信頼度を予測するステップであって、
第１の機械学習モデルおよび前記第１の特徴ベクトルを使用して第１の信頼値を生成するステップと、
第２の機械学習モデルおよび前記第２の特徴ベクトルを使用して第２の信頼値を生成するステップと、によって予測するステップと、
前記総損失イベントの前記信頼度の表示を含む通知を送信するステップと、
を含む動作を実行させる、非一時的コンピュータ可読媒体。
【請求項16】
前記第１の特徴ベクトルを生成するステップが、前記第１のデータセットからクラッシュ特徴のセットを抽出するステップであって、前記クラッシュ特徴のセットが、前記クラッシュイベントが発生した時点における前記車両のセンサデータを表す、ステップと、
前記車両データから車両特徴のセットを抽出するステップと、
前記クラッシュ特徴のセットと前記車両特徴のセットとを組み合わせるステップと、
を含む、請求項１５に記載の非一時的コンピュータ可読媒体。
【請求項17】
前記１つまたは複数の追加のデータタイプがエアバッグ作動データタイプを含む、請求項１５に記載の非一時的コンピュータ可読媒体。
【請求項18】
前記総損失イベントの前記信頼度を予測するステップは、前記第２の特徴ベクトルを使用して第３の特徴ベクトルを生成するステップであって、前記第３の特徴ベクトルが、前記１つまたは複数の追加のデータタイプについて異なる値を含む、ステップと、
前記第２の機械学習モデルおよび前記第３の特徴ベクトルを使用して第３の信頼値を生成するステップと、
をさらに含む、請求項１５に記載の非一時的コンピュータ可読媒体。
【請求項19】
前記１つまたは複数の追加のデータタイプが流体漏れインジケータを含む、請求項１５に記載の非一時的コンピュータ可読媒体。
【請求項20】
前記命令が、前記１つまたは複数のプロセッサに、前記第１の信頼値と前記第２の信頼値との間の差がしきい値よりも大きいと判定するステップと、
前記第１の信頼値と前記第２の信頼値との間の前記差が前記しきい値よりも大きいという判定に応答して、追加情報の要求を送信するステップと、
を含むさらなる動作を実行させる、請求項１５に記載の非一時的コンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
[0001]本出願は、２０２０年７月１４日に出願された「Ｍｅｔｈｏｄｓ ａｎｄ Ｓｙｓｔｅｍｓ ｏｆ Ｐｒｅｄｉｃｔｉｎｇ Ｔｏｔａｌ Ｌｏｓｓ Ｅｖｅｎｔｓ」と題する米国仮特許出願第６３／０５１，７２７号、および２０２１年７月１３日に出願された「Ｍｅｔｈｏｄｓ ａｎｄ Ｓｙｓｔｅｍｓ ｏｆ Ｐｒｅｄｉｃｔｉｎｇ Ｔｏｔａｌ Ｌｏｓｓ Ｅｖｅｎｔｓ」と題する米国特許出願第１７／３７４，６８４号明細書の優先権を主張し、これらの各々の開示は、あらゆる目的のためにその全体が参照により本明細書に組み込まれる。
[0001]本出願は、２０２０年７月１４日に出願された「Ｍｅｔｈｏｄｓ ａｎｄ Ｓｙｓｔｅｍｓ ｏｆ Ｐｒｅｄｉｃｔｉｎｇ Ｔｏｔａｌ Ｌｏｓｓ Ｅｖｅｎｔｓ」と題する米国仮特許出願第６３／０５１，７２７号、および２０２１年７月１３日に出願された「Ｍｅｔｈｏｄｓ ａｎｄ Ｓｙｓｔｅｍｓ ｏｆ Ｐｒｅｄｉｃｔｉｎｇ Ｔｏｔａｌ Ｌｏｓｓ Ｅｖｅｎｔｓ」と題する米国特許出願第１７／３７４，６８４号明細書の優先権を主張し、これらの各々の開示は、あらゆる目的のためにその全体が参照により本明細書に組み込まれる。
【背景技術】
【0002】
[0002]現代のモバイルデバイスは、モバイルデバイスの環境の特性を測定するように動作可能ないくつかのセンサを含む。モバイルデバイスを使用してモバイルデバイスのセンサによって検出されたイベントの結果を予測する分野においてなされた進歩にもかかわらず、イベントの結果を予測することに関連する改善された方法およびシステムが当技術分野において必要とされている。
【発明の概要】
【0003】
[0003]本発明の実施形態は、一般に、総損失イベントを予測することに関し、より詳細には、クラッシュイベントを検出し、クラッシュイベントに関連する総損失イベントの信頼度を予測することに関する。
【0004】
[0004]本発明の一実施形態によれば、総損失イベントの信頼度を予測する方法が提供される。モバイルデバイスは、１つまたは複数のセンサを使用してクラッシュイベントを検出することができる。モバイルデバイスは、１つまたは複数のセンサからの第１のデータセットを記録する。モバイルデバイスは、第１のデータセットを検出されたクラッシュイベントと関連付ける。モバイルデバイスは、第１のデータセットと、車両の識別子を含む車両データとを含む第１の特徴ベクトルを生成する。モバイルデバイスは、１つまたは複数の追加のデータタイプを含む第１のデータセットを使用して第２の特徴ベクトルを生成する。モバイルデバイスは、第１の特徴ベクトルを使用して第１の機械学習モデルから第１の信頼値を生成し、第２の特徴ベクトルを使用して第２の機械学習モデルから第２の信頼値を生成することによって、総損失イベントの信頼度を予測することができる。
【0005】
[0005]本発明の別の態様は、１つまたは複数のプロセッサと、１つまたは複数のプロセッサによって実行されると、１つまたは複数のプロセッサに上述の方法を実行させる命令を格納する非一時的コンピュータ可読媒体と、を含むシステムを含む。
【0006】
[0006]本開示の別の態様は、１つまたは複数のプロセッサによって実行されると、１つまたは複数のプロセッサに上述の方法を実行させる命令を格納する非一時的コンピュータ可読媒体を含む。
【0007】
[0007]従来技術よりも多くの利点が本発明によって達成される。例えば、本発明の実施形態は、運転中のセンサデータのリアルタイム処理を提供する。リアルタイム処理は、損失イベントの検出時または検出直後の損失イベントの大きさの判定を可能にする。さらに、モバイルデバイスによるセンサデータのリアルタイム処理は、これに限定されないが、損失イベント（例えば、クラッシュ、機械的故障など）などの様々な運転イベントの検出を可能にすることができる。
【0008】
[0008]本発明の適用可能なさらなる領域は、以下に提供される詳細な説明から明らかになるであろう。詳細な説明および特定の例は、様々な実施形態を示しているが、例示のみを目的とするものであり、本開示の範囲を必ずしも限定するものではないことを理解されたい。
【図面の簡単な説明】
【0009】
【図1】いくつかの実施形態による、総損失イベントを予測するためのモバイルデバイスのセンサおよび処理構成要素を示す例示的なブロック図である。
【図2】いくつかの実施形態による、総損失イベントを予測するためのソフトウェア環境のブロック図である。
【図3】いくつかの実施形態による、総損失イベントの信頼度を予測するための例示的なプロセスを示す図である。
【図4】いくつかの実施形態による、機械学習モデルを使用して総損失イベントを予測するためのフローチャートである。
【図5】いくつかの実施形態による、追加の入力データタイプを有する追加の機械学習モデルを使用して総損失イベントの信頼度を予測するためのフローチャートである。
【図6】いくつかの実施形態による、総損失イベント信頼度の信頼度を予測するための別の例示的なプロセスを示す図である。
【図7】いくつかの実施形態による、検出されたクラッシュの総損失イベントを予測するための結果のグラフの一例を示す図である。
【図8】いくつかの実施形態による、確認されたクラッシュで検出されたクラッシュの総損失イベントを予測するための結果のグラフの一例を示す図である。
【図9】いくつかの実施形態による、機械学習モデルによって生成された確認されたクラッシュの総損失イベントを予測するための結果の表を示す図である。
【図10】いくつかの実施形態による、総損失イベントの信頼度を予測するためのシステムのブロック図である。
【発明を実施するための形態】
【0010】
[0019]本発明の実施形態は、一般に、総損失イベントを予測することに関し、より詳細には、クラッシュイベントを検出し、クラッシュイベントに関連する総損失イベントの信頼度を予測することに関する。
【0011】
[0020]本発明の実施形態は、運転中の車両衝突などのクラッシュイベントの検出に基づいて総損失イベントを予測することを可能にする。モバイルデバイス上で実行されるアプリケーションは、アプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用してモバイルデバイスのセンサの測定値にアクセスする。アプリケーションは、測定値を解析してクラッシュイベントを検出する。次いで、アプリケーションは、クラッシュイベント中の車両の動きを表す測定値の一部を識別する。アプリケーションは、クラッシュイベントを表す測定値の一部の解析に基づいて、クラッシュイベントが総損失イベントに対応するかどうかを予測することができる。
【0012】
[0021]場合によっては、アプリケーションは、機械学習およびコンテキストまたは車両データを使用して総損失イベントの信頼度を予測して、予測の精度を向上させることができる。アプリケーションは、例えば、クラッシュイベントの検出のほぼ直後に、リアルタイムで総損失イベントの信頼度を生成することができる。アプリケーションは、クラッシュ時に利用可能な特定のデータに対して選択された複数の機械学習モデルを使用することができる。例えば、アプリケーションは、センサ情報によって特徴付けることができ、車両を識別するために使用することができる車両データ（例えば、製造元、モデル、年など）を含むクラッシュイベント中に第１の機械学習モデルを使用することができる。別の例では、アプリケーションは、センサ情報によって特徴付けることができ、かつ、クラッシュイベントの他の特性（例えば、エアバッグ作動データタイプ、流体漏れインジケータ、構造的損傷など）を識別するために使用することができる追加のデータタイプを含む第２の機械学習モデルをクラッシュイベント中に使用することができる。
【0013】
[0022]本明細書で使用される場合、「総損失イベント」は、車両がその車両の値よりも大きい損傷レベルを被ったことを意味する。
【0014】
[0023]本明細書で使用される場合、「直後に」とは、近似的にクラッシュイベントが検出された瞬間（例えば、１秒以内、１分以内、しきい値を下回るセンサ測定値の検出後の所定の期間など）に続くことを意味する。例えば、本明細書に記載のプロセスは、車両に関する車両衝突などのクラッシュイベントの検出直後に実行され得る。
【0015】
[0024]図１は、いくつかの実施形態による、総損失イベントを予測するためのモバイルデバイスのセンサおよび処理構成要素を示す例示的なブロック図である。システム１００は、複数の処理、センサ、および通信リソース構成要素を含むモバイルデバイス１０４を含む。モバイルデバイス１０４は、センサデータブロック１０８、データ処理ブロック１４４、データ送信ブロック１６４、および任意選択的に通知ブロック１６０を含んでもよい。センサデータブロック１０８は、データ収集センサ、ならびにモバイルデバイス１０４に利用可能なセンサから収集されたデータを含む。センサデータブロック１０８は、ブルートゥース（登録商標）、ユニバーサルシリアルバス（ＵＳＢ）ケーブルなどを介して接続された外部デバイス１３２を含むことができる。データ処理ブロック１４４は、プロセッサ１４８によって処理されたセンサデータブロック１０８のセンサによって収集されたデータを含むことができるストレージ１５６を含んでもよい。これには、解析、特徴付け、操作、平滑化、サブサンプリング、フィルタリング、再フォーマットなどが含まれ得るが、これらに限定されない。モバイルデバイスの例には、スマートフォン、タブレット、ラップトップ、特定用途向け集積回路（ＡＳＩＣ）などが含まれるが、これらに限定されない。
【0016】
[0025]データ送信ブロック１６４は、外部コンピューティングデバイス（例えば、電子デバイス１８０）に送信された処理済みセンサデータなどの通信（例えば、送受信される通信）を処理することができる。外部コンピューティングデバイスはまた、センサデータブロック１０８から得られたデータを記憶および／または処理することもできる。いくつかの例では、電子デバイス１８０は、それ自体のプロセッサ１８４およびストレージ１８８を含んでもよい。
【0017】
[0026]通知ブロック１６０は、データ処理ブロック１４４によって実行されたセンサデータの解析の結果を、ディスプレイ（図示せず）を介してモバイルデバイス１０４のユーザに報告することができる。例えば、通知ブロック１６０は、ユーザが予測された総損失イベントを経験したと判定すると、モバイルデバイス１０４のユーザに警告通信を表示または提示することができる。いくつかの例では、予測された総損失イベントの判定は、モバイルデバイス１０４のプロセッサ１４８によって実行されるプロセスであってもよい。他の例では、予測された総損失イベントの判定は、プロセッサ１８４によって実行されるプロセスであってもよい。
【0018】
[0027]いくつかの例では、運転データは、モバイルデバイス１０４を使用して収集されてもよい。これらの例は、いかなる特定の電子デバイスにも限定されない。一例として、全地球測位システム（ＧＰＳ）受信器１１２、加速度計１１６、磁力計１２０、ジャイロスコープ１２４、マイクロフォン１２８、外部デバイス１３２、コンパス１３６、気圧計１４０、通信機能などの位置決定システムなどのセンサを含む様々な電子デバイスが、モバイルデバイス１０４に含まれるかまたは接続されてもよい。モバイルデバイス１０４の例には、スマートウォッチ、フィットネスモニタ、ブルートゥース（登録商標）ヘッドセット、タブレット、ラップトップコンピュータ、スマートフォン、音楽プレーヤ、動き解析デバイスなどが含まれる。
【0019】
[0028]モバイルデバイス１０４（例えば、センサデータブロック１０８のセンサ）の１つまたは複数のセンサは、モバイルデバイス１０４との物理的相互作用に関する表示を提供するために測定値を収集するように動作することができる。いくつかの例では、測定値は、デバイスが特定の速さで移動しているとき、またはデバイスが既知の道路（例えば、高速道路）上に位置しているときなど、車両を操作するときにモバイルデバイス１０４が運転者と一緒にいる可能性が高いときに収集されてもよい。データを収集するために使用されるセンサは、モバイルデバイス１０４の構成要素であってもよく、モバイルデバイス１０４の構成要素、例えば、モバイルデバイスのバッテリ電力および／またはモバイルデバイス１０４の外部のデータソースに利用可能な電力リソースを使用してもよい。
【0020】
[0029]いくつかの例では、モバイルデバイスの設定を使用して、本明細書に記載の異なる機能を可能にすることができる。例えば、特定の設定が有効にされたＡｐｐｌｅ ｉＯＳ、Ａｎｄｒｏｉｄ ＯＳ、および／またはウェアラブル・デバイス・オペレーティング・システムなどのオペレーティングシステム（ＯＳ）は、実施形態の特定の機能を可能にすることができる。いくつかの例では、位置サービスを有効にすることにより、モバイルデバイスからの位置情報の収集（例えば、全地球測位システム（ＧＰＳ）受信器１１２によって収集される）が可能になり、バックグラウンド・アプリケーション・リフレッシュを有効にすることにより、いくつかの実施形態は、アプリケーションが実行されていないときでも運転データを収集および解析することをバックグラウンドで実行することが可能になる。いくつかの実施態様では、様々な処理およびデータ収集をバックグラウンドで実行できるため、アプリがバックグラウンドで実行されている間に通知ブロック１６０を使用して警告が提供または表示される。
【0021】
[0030]図２は、いくつかの実施形態による、総損失イベントを予測するためのソフトウェア環境２００のブロック図である。様々な実施形態において、総損失モジュール２０１は、総損失信頼度２２２を生成することによって総損失イベントの予測を提供するソフトウェアアプリケーションである。総損失モジュール２０１は、モバイルデバイス１０４のデータ処理ブロック１４４によって実行されてもよい。総損失モジュール２０１は、様々な運転センサ２０２からの入力、およびＴＬＥ予測モデル２１０によって総損失イベント（ＴＬＥ）を予測するために使用することができる内部および外部ソースからの追加のデータタイプ（例えば、エアバッグ作動データタイプ）を受信することができる。例えば、ＴＬＥ予測モデル２１０は、車両データ２２０、クラッシュイベント２０４、クラッシュ予測モデル２０６の出力、および追加のクラッシュ入力２０８に基づくことができる総損失イベントの予測を生成することができる。
【0022】
[0031]総損失モジュール２０１は、運転センサ２０２から入力を取得する。運転センサ２０２は、モバイルデバイス１０４のセンサデータブロック１０８に含まれるセンサを含むことができるが、これに限定されない。運転センサ２０２は、外部センサをさらに含むことができ、そこから測定値をモバイルデバイス１０４に送信することができる。外部センサの例には、流体漏れ（例えば、トランスミッション液、ブレーキ液、オイルなど）を示すセンサ、機械的障害（例えば、構造的なトランスミッションの損傷、車輪の位置／カップリング、トルクまたはシャフトの応力など）を示すセンサ、別のモバイルデバイス（例えば、モバイルデバイス１０４と同様のタイプの）からのセンサ、車両に埋め込まれたセンサ（例えば、車両のテレマティクスユニット）、別の車両に埋め込まれたまたは付随するセンサ（例えば、クラッシュイベントに関与する別の車両）、およびそれらの組み合わせなどが含まれる。場合によっては、運転センサ２０２は、総損失モジュール２０１に車両の動きの継続的な監視を提供することができる。他の場合には、運転センサ２０２の各個々のセンサは、総損失モジュール２０１によって指定された測定速度で監視を提供することができる。例えば、総損失モジュール２０１は、環境条件、運転トリップの長さ、車両の種類／モデル、特定の運転者などに基づいて規定の速度で動作するように運転センサ２０２の特定のセンサを規定することができる。
【0023】
[0032]総損失モジュール２０１は、運転中、または車両の動作中の別の時点でクラッシュイベント２０４を検出することができる。総損失モジュール２０１は、運転センサ２０２からの情報に基づいてクラッシュイベント２０４を検出することができる。例えば、総損失モジュール２０１は、クラッシュイベント２０４が発生したというインジケータに対応する運転センサ２０２からの情報を使用して、高加速度計測定値、急激な速度変化、または他の測定値を検出することができる。場合によっては、総損失モジュール２０１は、例えば磁力計、マイクロフォンなどを使用して、衝突型クラッシュイベントに関連しない車両の機械的、電気的、または構造的故障に起因してクラッシュイベント２０４が発生したと判定することができる。
【0024】
[0033]例えば、加速度計センサは、車両の進行方向とは反対方向の大きさの突然の増加を検出することができる。総損失モジュール２０１は、加速度の突然の低下を引き起こした衝突に車両が関与したと判定することができる。磁力計は、車両の回転金属要素の突然の停止（例えば、トランスミッション、シャフト、車軸など）などの磁場特性の突然の変化を検出することができる。総損失モジュール２０１はまた、磁力計の変化に基づいて機械的故障が発生したと判定することができる。
【0025】
[0034]総損失モジュール２０１は、車両の基準とは異なり得る基準フレームを有するモバイルデバイスに起因する広範囲の動きを検出することができる。モバイルデバイス１０４は車両に固定されていない可能性があるため、加速度測定値は、モバイルデバイス１０４については車両テレマティクスシステムとは異なる可能性がある。一例として、車両に搭載された加速度計とは対照的に、モバイルデバイスが座席に横たわっている事故（例えば、車両の衝突）の間、モバイルデバイスは車両の動きとは半独立に車両内を移動することができるため、モバイルデバイスの減速は車両の減速を遅らせることができる。モバイルデバイス１０４は、モバイルデバイスを使用して測定された加速度を車両の基準フレームにマッピングする変換を定義することができる。その変換は、モバイルデバイス（例えば、モバイルデバイスのセンサ測定値）の基準フレームを車両の基準フレームに変換することを可能にすることができる。その変換は、車両の動き（例えば、移動方向、破壊イベント、車両の位置など）を特徴付けるために使用される運転センサ２０２の測定値を可能にしてもよい。
【0026】
[0035]場合によっては、モバイルデバイス１０４はまた、変換を使用して、車両の動きに対応するセンサ測定値からモバイルデバイスの動きに対応するセンサ測定値を除外することができる。例えば、変換を使用して、モバイルデバイス１０４は、加速度測定値の一部が車両内のモバイルデバイスの独立した動きの結果であったと判定することができる。加速度測定値の残りの部分が車両の動きを特徴付けるように、モバイルデバイスに関連する加速度測定値の部分を除外することができる。一例として、急ブレーキイベント中に、モバイルデバイスは、ファイアウォールによって停止される前に前方にスライドすることができ、それにより、運転センサ２０２は、ブレーキイベント中に大きな加速度（後方方向）を検出し、その後に、モバイルデバイスがファイアウォールに当たるとさらに大きな加速度を検出する。変換は、センサ測定値の残りの部分が車両の加速度に正確に対応することを保証するために、モバイルデバイスに関連する加速度測定値の部分をフィルタリングするために使用され得る。
【0027】
[0036]総損失モジュール２０１は、クラッシュイベントを含む期間にわたって収集された運転センサ２０２からのセンサ測定値を含む第１のデータセットを識別してもよい。場合によっては、その期間は、クラッシュイベントの前の第１の時間（例えば、１分、５分、または任意の他の時間）およびクラッシュイベントの後の第２の時間（例えば、１分、５分、または任意の他の時間）から始まるなど、所定の長さであってもよい。他の例では、その期間は、運転センサ２０２に基づいて総損失モジュール２０１によって動的に定義されてもよい。例えば、その期間は、クラッシュイベントの前の第１の時刻に開始し、（例えば、期間がクラッシュイベント全体を含むことを保証するために）総損失モジュール２０１が運転センサ２０２を使用して、車両が停止したと（センサ測定値から）判定する第３の時刻に終了してもよい。総損失モジュール２０１は、センサ入力の大きさのしきい値（例えば、しきい値加速度の大きさ、ＧＰＳ位置測定値が変化していない、またはしきい値変動内にあるという表示など）に基づいて第３の時刻データを選択してもよい。場合によっては、ＴＬＥ予測モデル２１０が、処理のために第１のデータセットを電子デバイス１８０に送信してもよく、結果が電子デバイス１８０からＴＬＥ予測モデル２１０に送信されてもよい。
【0028】
[0037]クラッシュ予測モデル２０６は、車両が事故（例えば、車両の衝突、機械的故障など）に巻き込まれた可能性を判定する。クラッシュ予測モデル２０６は、予測バイナリ（または非バイナリ）分類器であってもよい。例えば、クラッシュ予測モデル２０６は、様々な加速度測定値、ＧＰＳ位置、運転センサ２０２によって測定された車両運動などからクラッシュ特徴のセットを導出することができる。クラッシュ予測モデル２０６は、クラッシュイベントが発生したという予測を生成するために、クラッシュ特徴のセットを使用して実行することができる。クラッシュ予測モデル２０６は、クラッシュイベント２０４に関連付けられたクラッシュ特徴を含むクラッシュ特徴ベクトルをさらに出力することができる。クラッシュ特徴ベクトルは、ＴＬＥ予測モデル２１０に出力され得る。
【0029】
[0038]総損失モジュール２０１は、ＴＬＥ予測モデル２１０に追加のクラッシュ入力２０８を提供することができる。追加のクラッシュ入力２０８は、エアバッグ展開情報、流体漏れインジケータ、緊急医療サービスに電話がかけられたという表示、運転者または乗客の病状（例えば、心拍数データ、呼吸データなどを収集するウェアラブルデバイスから）などを含むことができるが、これらに限定されない。他の例では、追加のクラッシュ入力２０８は、総損失モジュール２０１によってモバイルデバイス１０４のユーザインターフェースを介してユーザ（例えば、運転者または乗客など）に提供される調査質問への応答であり得る。
【0030】
[0039]総損失モジュール２０１は、車両データ２２０をＴＬＥ予測モデル２１０に提供することができる。車両データ２２０は、車両固有情報に対応する１つまたは複数のデータ型を含む。車両データ２２０のデータタイプの例には、製造元、モデル、製造年、トリムパッケージ（例えば、品質および特徴）、過去の事故履歴（例えば、以前の車両の衝突）、車両識別番号、車両に対する過去の保険請求、車両メンテナンス記録、それらの組み合わせなどが含まれるが、これらに限定されない。ＴＬＥ予測モデル２１０は、車両データ２２０を使用して、総損失イベントをより正確に予測することができる。
【0031】
[0040]ＴＬＥ予測モデル２１０は、総損失イベントの総損失信頼度２２２を生成するための２つ以上の機械学習モデルを含むことができる。図２において、ＴＬＥ予測モデル２１０は、第１の機械学習モデル２１２および第２の機械学習モデル２１４を含む。ＴＬＥ予測モデル２１０は、追加の機械学習モデル２１６または他の機械学習モデル（図示せず）などの任意の数の追加の機械学習モデルを含んでもよい。ＴＬＥ予測モデル２１０は、機械学習モデルのうちの１つまたは複数を使用して総損失信頼度２２２（すなわち、総損失イベントの可能性）を生成する。
【0032】
[0041]ＴＬＥ予測モデル２１０の機械学習モデルは、特定のデータタイプのデータセットを使用して、教師あり学習または教師なし学習を使用して訓練することができる。例えば、第１の機械学習モデル２１２は、第１の特徴ベクトルに対する信頼度を生成するように訓練されてもよい。第１の特徴ベクトルは、限定はしないが、車両特徴（例えば、車両データ２２０から抽出される）およびセンサ特徴（例えば、運転センサ２０２からのセンサデータから抽出される）などの特徴の第１のセットを含むことができる。第２の機械学習モデル２１４は、第２の特徴ベクトルに対する信頼度を生成するように訓練されてもよい。第２の特徴ベクトルは、限定はしないが、車両特徴（例えば、車両データ２２０から抽出される）、センサ特徴（例えば、運転センサ２０２からのセンサデータから抽出される）、およびエアバッグの展開の表示などの特徴の第２のセットを含むことができる。特徴の第１のセットおよび特徴の第２のセットは、前述のように排反なセットまたは排反でないセットであってもよい。
【0033】
[0042]第１の機械学習モデル２１２、第２の機械学習モデル２１４および追加の機械学習モデル２１６は、いずれのタイプの機械学習モデルであってもよい。第１の機械学習モデル２１２および第２の機械学習モデル２１４の例は、決定木、ニューラルネットワーク、ベイジアンネットワーク、または他のモデルであってもよい。一例では、第１の機械学習モデル２１２は、車両データ２２０と運転センサ２０２から記録された第１のデータセットとを含む第１の特徴ベクトルを用いて信頼度を予測する。第１の機械学習モデル２１２は、センサデータを表す訓練データセットを使用して訓練される。第２の機械学習モデル２１４は、運転センサ２０２および追加のクラッシュ入力２０８から記録された第１のデータセットを含む第２の特徴ベクトルを用いて信頼度を予測する。追加の機械学習モデル２１６を含む例では、追加の機械学習モデル２１６は、第１の機械学習モデル２１２および／または第２の機械学習モデル２１４によって使用されるデータタイプに加えて、またはその代わりに、１つまたは複数のデータタイプを使用して信頼度を予測する。ＴＬＥ予測モデル２１０は、それぞれがＴＬＥ予測モデル２１０の他の機械学習モデルによって使用される入力の異なるセットに基づいてそれぞれの予測を生成するように構成された任意の数の追加の機械学習モデル２１６を含むことができる。
【0034】
[0043]ＴＬＥ予測モデル２１０は、上述したように、１つまたは複数の機械学習モデルを使用して複数の信頼値を生成することができる。総損失モジュール２０１は、各それぞれの機械学習モデルの信頼値から総損失信頼度２２２を決定することができる。総損失信頼度２２２の一例は、クラッシュイベント２０４が総損失イベントである可能性のパーセンテージであってもよい。
【0035】
[0044]図３は、いくつかの実施形態による、総損失イベントの信頼度を予測するための例示的なプロセス３００である。ブロック３０２では、モバイルデバイスのアプリケーション（例えば、前述の総損失モジュールなど）に関連付けられたクラッシュイベントが検出される。クラッシュイベント２０４などのクラッシュイベントは、モバイルデバイスの１つまたは複数のセンサ（例えば、モバイルデバイス１０４のセンサデータブロック１０８のセンサなど）を使用して検出することができる。第１の例として、モバイルデバイスは、例えばＧＰＳセンサや加速度計を用いて車両の動きの変化を検出することで、クラッシュイベントを検出することができる。ＧＰＳセンサは、速度（例えば、加速度を導出するために使用され得る速さおよび方向）を測定するために定義された基準フレームに対応することができる。加速度計は、モバイルデバイスの基準フレーム内の方向の加速度の大きさを測定する。モバイルデバイスは、加速度計測定値を使用して、運転中の加速度が典型的には特定のしきい値（例えば、複数のドライブにわたる平均化）内にあることを判定することができ、車両の基準フレームにマッピングされると、モバイルデバイスは、加速度計測定値を使用して車両に対する加速度の方向（例えば、車両に対して前方および後方）を判定することができる。加速度計は、総損失モジュールが損失イベント（例えば、衝突、機械的故障など）の発生を判定するために使用することができるしきい値を超える横加速度または加速度を検出することができる。総損失モジュールは、加速度測定値に加えて、または加速度測定値の代わりにＧＰＳ測定値を使用して、車両の位置に対応する位置情報を提供することができる。例えば、モバイルデバイス（ひいては車両）の位置の変化が予期しないものであって、クラッシュイベントに起因する可能性が高いことを位置情報が示していると、総損失モデルが判定することができる。
【0036】
[0045]別の例として、モバイルデバイス１０４は、加速度計測定値の大きさがしきい値よりも大きいこと（例えば、外力が車両に作用していることを示す）を検出することができる。加速度計の測定値を時間の関数として解析して、車両が加速度または速度を変化させた期間を決定することができる。加速度または速度の変化は、加速度計の測定値の変化が、例えばしきい値（例えば、２０ｍｐｈ）を超える速さから０に近いかまたは０に等しい速さまでなどの車両の速さの低下に対応するかどうかを示すことができる。総損失モジュールは、０または０に近い速さの延長された期間と共に急速な加速（例えば、車両の減速を示す後方方向に）がクラッシュイベントを示すと判定することができる。
【0037】
[0046]場合によっては、総損失モジュールは、急速な加速が衝突ではない損失イベントに対応すると判定することができる。総損失モジュールは、加速度計測定値をモバイルデバイスの他のセンサと相関させて、損失イベントのタイプを判定することができる。例えば、総損失モジュールは、衝突に関連付けるには大きすぎる（例えば、第１のしきい値よりも大きい）測定値などの異常な加速度計測定値を検出することができる。総損失モジュールは、加速度計測定値を磁力計測定値、モバイルデバイスによって取り込まれたオーディオまたはビデオなどと相関させて、異常な加速度計測定値の可能性のある原因を識別することができる。第１の例では、加速度計の測定値と時間的に重なる磁力計の測定値は、伝送の問題を示すことができる。別の例では、モバイルデバイスのマイクロフォンは、平坦なタイヤまたは吹き飛ばされたタイヤを示す音を取り込むことができる。センサ測定値を相関させることによって、総損失モジュールは、衝突、機械的故障、電気的故障、構造的故障などを含むがこれらに限定されない任意のタイプの総損失イベントを識別することができる。
【0038】
[0047]ブロック３０４において、プロセス３００は継続し、クラッシュイベントに関連付けられた第１のデータセットを（例えば、前述の総損失モジュールなどによって）識別する。例えば、モバイルデバイスは、運転トリップ中にモバイルデバイスのセンサからセンサ測定値を連続的に収集することができる。クラッシュイベントが検出されると、総損失モジュールは、クラッシュイベントに関連するセンサ測定値の一部を識別することができる。場合によっては、第１のデータセットは、クラッシュイベントを含む期間にわたって収集されたセンサ測定値を含むことができる。一例では、第１の期間は、クラッシュイベントの前の第１の時刻（例えば、クラッシュイベントの１０秒前、３０秒前、５分前など）に開始し、クラッシュイベントの後の第２の時刻（例えば、クラッシュイベントの１０秒後、３０秒後、５分後など）に終了することができる。他の例では、第１のデータセットを記録するための期間は、センサ測定値の様々なしきい値（例えば、しきい値加速度、ＧＰＳ道路境界または障害物境界など）によって決定されてもよい。
【0039】
[0048]場合によっては、総損失モジュールは、車両の動作状態に基づいて運転中にセンサを動的に制御することができる。総損失モジュールは、どのセンサを作動させるか（例えば、センサ測定値を収集するためにどのセンサが使用されるべきか）および／またはそれらのセンサのサンプリングレートに関する判定の一部として、外部ソースから追加のデータを受信することができる。追加のデータは、現在の天候、経路情報、道路状況、交通、経路に沿った過去の衝突、過去の衝突または運転者の総損失イベント、車両情報（例えば、製造元、モデル、年、保守記録など）を含むことができるが、これらに限定されない。例えば、悪天候でのストップアンドゴー交通では、総損失モジュールは、他の車両の近接性および悪天候での衝突の可能性のために、より多くのセンサを作動させることができる。別の例では、車両が交通のない晴れた日に高速道路上にある場合、総損失モジュールはより少ないセンサを動作させる（例えば、より少ないセンサからセンサ測定値を収集するか、またはより低いサンプリングレートでセンサ測定値を収集する）ことができる。
【0040】
[0049]クラッシュイベントを検出すると（または経路に沿って衝突が発生する可能性が高いことを検出すると）、総損失モジュールは、（例えば、以前に使用されていなかったセンサによる測定値の収集を開始するために）非アクティブなセンサを動的に起動し、および／または（または総損失モジュールが衝突が発生する可能性が高いことを識別した場合には）クラッシュイベント中にアクティブなセンサのサンプリングレートを増加させることができる。総損失モジュールは、使用されるべきモバイルデバイスのセンサの第１のサブセットを指定することができる。クラッシュイベントが検出されると、総損失モジュール２０１は、モバイルデバイスのセンサのすべてまでを含むセンサの第２のサブセットを指定してもよい。
【0041】
[0050]ブロック３０６において、プロセス３００は、第１のデータセットおよび車両データ（例えば、車両の特性を含む）から第１の特徴ベクトルを生成することを含む。クラッシュ特徴の第１のセットは、クラッシュイベントの個々の測定可能な特性（例えば、センサデータ）を表すことができ、車両の特性を表す特徴を含む。総損失モジュール２０１は、第１の特徴ベクトルを第１の機械学習モデル２１２などの機械学習モデルに提供してもよい。
【0042】
[0051]ブロック３０８において、プロセス３００は、追加のクラッシュ入力２０８に関連して説明したように、第１のデータセット、車両データ、ならびにエアバッグ作動データタイプおよび／または流体漏れインジケータなどの追加のデータタイプを使用して、第２の特徴ベクトルを生成することを含む。場合によっては、総損失モジュールは、１つまたは複数の追加のデータタイプを第１の特徴ベクトルに連結することによって、第１の特徴ベクトルから第２の特徴ベクトルを生成することができる。クラッシュ特徴の第２のセットの特徴は、クラッシュイベントの個々の測定可能な特性（例えば、センサデータ）、車両の特性を表す特徴、および１つもしくは複数の追加のデータタイプを表す特徴を表すことができる。１つまたは複数の追加のデータタイプの例には、流体漏れの測定された表示、エアバッグ展開、運転者の病状、ユーザインターフェースを介して運転者から受信した調査質問に対する応答などを表す特徴が含まれるが、これらに限定されない。
【0043】
[0052]ブロック３１０において、プロセス３００は、総損失イベントの信頼度を予測することを含む。ＴＬＥ予測モデルは、第１の機械学習モデル２１２または第２の機械学習モデル２１４などの第１の機械学習モデルおよび第２の機械学習モデルを使用して、車両に総損失イベントが発生した信頼度を計算する。信頼度は、損失イベントが総損失イベントである確率であってもよい。信頼度は、パーセンテージ（例えば、１００）、整数、グレード（例えば、低、中、高、Ａ～Ｆなど）として、または損失イベントが総損失イベントであるという信頼度を識別することができる任意の方法で表すことができる。
【0044】
[0053]第１の機械学習モデルおよび第２の機械学習モデルの例は、決定木、ニューラルネットワーク、ベイジアンネットワークなどを含むが、これらに限定されない。場合によっては、第１の機械学習モデルは、車両データおよび第１のデータセットを含む第１の特徴ベクトルを使用して第１の信頼度を予測し、第２の機械学習モデルは、追加のデータタイプ、記録された第１のデータセット、および車両データを含む第２の特徴ベクトルを使用して第２の信頼度を予測する。他の場合には、第１の機械学習モデルは、（第１の特徴ベクトルを使用して）第１の信頼度および（第２の特徴ベクトルを使用して）第２の信頼度を生成することができる。他の場合には、第２の機械学習モデルは、第１の信頼度および第２の信頼度を生成することができる。
【0045】
[0054]図３に示す特定のステップは、本発明の一実施形態による総損失イベントの信頼度を予測する特定の方法を提供することを理解されたい。代替的な実施形態によれば、他の一連のステップもまた実行され得る。例えば、本発明の代替的な実施形態は、上記で概説したステップを異なる順序で実行してもよい。さらに、図３に示す個々のステップは、個々のステップに適切であるように様々な順序で実行することができる複数のサブステップを含むことができる。さらに、特定の用途に応じて、さらなるステップが追加または削除されてもよい。当業者であれば、多くの変形例、修正例、および代替例を認識するであろう。
【0046】
[0055]図４は、いくつかの実施形態による、機械学習モデルを使用して総損失イベントの信頼度を予測するためのプロセス４００のフローチャートである。
【0047】
[0056]ブロック４０２において、プロセス４００はクラッシュイベントを検出することを含む。図１のモバイルデバイス１０４などのモバイルデバイスは、モバイルデバイスのセンサ測定値を解析するアプリケーションを実行することによってクラッシュイベントを検出することができる。場合によっては、モバイルデバイスの１つまたは複数のセンサを使用してクラッシュイベントを検出することができる。モバイルデバイスは、１つまたは複数のセンサを使用して、限定はしないが、場所、タイムスタンプ、現在の交通量、現在の天候、その場所での過去の衝突などの、クラッシュイベントに関連する他の属性を識別することができる。ブロック４０２の動作は、図３のブロック３０２に関して説明したように実行することができる。
【0048】
[0057]ブロック４０４において、プロセス４００は、クラッシュ予測モデルを使用してクラッシュ予測を生成することを含む。例えば、クラッシュ予測は、しきい値を超える加速度計の測定値、車両の横方向位置の変化（例えば、車両が道路から外れていることを示す）、ランブルストリップ検出（例えば、車両が道路から外れているかどうかを判定するため）、頻繁なおよび／または急ブレーキ（例えば、渋滞が激しいこと、および／または運転者の前方の車両から適切な距離を維持していないことを示す）、注意力不足運転（例えば、車両が動いている間に検出された運転者とモバイルデバイスとの相互作用）などを判定するモバイルデバイスのセンサに基づいて生成され得る。クラッシュ予測モデルは、センサデータおよび上記の要因などのコンテキスト情報に基づいて車両衝突が発生した可能性を出力するための訓練されたモデルであってもよい。
【0049】
[0058]いくつかの実施形態では、クラッシュ予測モデルが出力を生成すると、プロセス４００はブロック４０６に進む。他の実施形態では、クラッシュ予測モデルがしきい値を下回る出力を生成する場合、プロセス４００はブロック４０８に進む。例えば、クラッシュ予測モデルは、クラッシュイベントの可能性がしきい値クラッシュ可能性より大きい場合にのみ出力を生成することができる。場合によっては、クラッシュ予測モデルは、クラッシュイベントの可能性がしきい値クラッシュ可能性よりも小さいときにヌル出力を生成することができる。他の場合では、クラッシュ予測モデルは、クラッシュ予測モデルのすべての例のバイナリ値である出力を生成してもよい。これらの場合、プロセス４００は、バイナリ出力がクラッシュイベントが発生したことを示す場合にはブロック４０８に進み、バイナリ出力がクラッシュイベントが発生していないことを示す場合にはブロック４０６に進むことができる。
【0050】
[0059]ブロック４０６において、プロセス４００は、クラッシュ予測モデルの出力を使用してクラッシュ特徴ベクトルを生成することを含む。クラッシュ特徴ベクトルは、例えば、運転センサから受信したデータの一部または全部から抽出されたクラッシュ特徴を含むことができ、クラッシュ予測（例えば、クラッシュイベントが発生した統計的可能性）を含むことができる。クラッシュ特徴ベクトルは、クラッシュ予測モデルによって出力されてもよく、クラッシュイベントの異なる態様に対応するモバイルデバイスのセンサから収集された様々な信号に関する要約統計（例えば、中央値、分散、および最大値）を含むことができる。クラッシュ特徴は、クラッシュイベントの前、最中、または後に、異なる長さの時間窓を使用して抽出することができる。各窓は、クラッシュイベントの時点に中心付けられ、クラッシュイベントの前の時間およびクラッシュイベントの後の時間まで拡張することができる。クラッシュ特徴ベクトルの生成は、クラッシュイベントについての値のセットを生成する。
【0051】
[0060]ブロック４０８において、プロセス４００は、モバイルデバイス１０４のセンサデータからクラッシュ特徴ベクトルを生成することを含む。例えば、クラッシュ予測モデルは、クラッシュが発生しなかったか、または低精度出力を生成したと予測したので、総損失モジュールは、モバイルデバイスのセンサから収集されたセンサデータから直接クラッシュ特徴ベクトルを生成することができる。総損失モジュールは、クラッシュ予測モデル出力が低精度であるか、またはクラッシュが発生しなかったと予測される場合、クラッシュ予測モデルの値にヌル値（またはバイナリ値）を設定してもよい。
【0052】
[0061]ブロック４１０において、プロセス４００は、エアバッグ情報が提供されるかどうかを判定することを含む。総損失モジュールは、クラッシュ特徴ベクトルを使用して、エアバッグ作動データタイプが提供されるかどうかを判定することができる。第１の例では、クラッシュ特徴ベクトルは、エアバッグステータス値を含んでもよい。総損失モジュールは、運転センサまたは追加のクラッシュ入力２０８からエアバッグステータスを受信することができる。場合によっては、運転センサは、クラッシュイベントに関連する時間ウィンドウの間にエアバッグ状態を検出することができる。モバイルデバイス１０４はまた、エアバッグ作動データタイプが提供されるか否かを判定するために他のセンサ（例えば、車両のエアバッグシステムインジケータに通信可能に結合する）を使用してもよい。例えば、エアバッグ作動データタイプは、ユーザインターフェースを介してユーザ入力から受信されてもよい。エアバッグ作動データタイプが提供されるプロセス４００の一例では、プロセス４００はブロック４１４に進む。そうでなければ、エアバッグ作動データタイプが提供されないか、あるいは未知であるプロセス４００では、プロセス４００はブロック４１２に進む。
【0053】
[0062]ブロック４１２において、ＴＬＥ予測モデルは、第１の特徴ベクトルを使用して第１の信頼度を予測するために第１の機械学習モデルを使用する。第１の機械学習モデルは、センサデータおよび車両データ（車種、車種、年式、車両の車両識別番号（ＶＩＮ）など）を表す訓練データを使用して訓練することができる。第１の機械学習モデルは、クラッシュイベントおよび車両データに関連するセンサ測定値に対応する信頼度を生成することができる。第１の機械学習モデルは、車両が総損失イベントに関与したという信頼度を出力する決定木であってもよい。第１の機械学習モデルは、クラッシュ特徴ベクトルのデータ値の一部または全部を使用して、総損失イベントの信頼度を予測することができる。プロセス４００はブロック４１２からブロック４２４に進む。
【0054】
[0063]ブロック４２４において、ＴＬＥ予測モデルは、総損失イベントに関連する追加の出力を計算する。ＴＬＥ予測モデルは、モバイルデバイス１０４のユーザに追加の信頼度を出力することができる。第１の例では、ＴＬＥ予測モデルは、ある期間にわたって移動した距離および車両年数（例えば、年式から計算される）を計算するためにセンサデータを使用することによって走行距離推定を出力することができる。ＴＬＥ予測モデルは、走行距離推定および車両年数を用いて、クラッシュイベント時の車両の推定値をさらに出力することができる。
【0055】
[0064]ブロック４１０に戻って、エアバッグ作動データタイプが提供されるプロセス４００の一例では、プロセス４００はブロック４１４に進む。ブロック４１４において、ＴＬＥ予測モデルは、図２の第２の機械学習モデル２１４などの第２の機械学習モデルを使用して、クラッシュ特徴ベクトルを使用して信頼度を予測する。第２の機械学習モデルは、センサデータ、車両データ、および追加のデータタイプを表す訓練データを使用して訓練することができる。場合によっては、ＴＬＥ予測モデルは、追加のデータタイプの異なる値を有する複数の例で第２の機械学習モデルを使用してもよい。
【0056】
[0065]例えば、第２の機械学習モデルは、エアバッグ作動データタイプが提供される場合に信頼度を生成することができる。この例では、第２の機械学習モデルは、総損失モジュールによって提供されたエアバッグ情報に基づいて、クラッシュイベント中にエアバッグが展開されたかどうか（例えば、展開されたか、または展開されていないかのいずれか）を示す値に基づいて、クラッシュイベントが総損失であるという信頼度を生成することができる。第２の機械学習モデルは、センサデータおよびエアバッグ情報（例えば、展開済み、非展開）を表す訓練データを使用して訓練することができる。第２の機械学習モデルは、クラッシュイベントおよびエアバッグ情報に関連するセンサ測定値に対応する信頼度を生成することができる。第２の機械学習モデルは、車両が総損失イベントに関与したという信頼度を出力する決定木であってもよい。第２の機械学習モデルは、第２の特徴ベクトルのデータ値の一部または全部を使用して、総損失イベントの信頼度を予測してもよい。
【0057】
[0066]ブロック４２６において、ＴＬＥ予測モデルは、ブロック４１４からの出力、ならびにブロック４２４に関連して説明した追加の出力を含む、総損失イベントに関連する追加の出力を計算する。したがって、ＴＬＥ予測モデルは、ある期間にわたって移動した距離および車両年数（例えば、年式から計算される）、ならびに走行距離推定および車両年数を使用したクラッシュイベント時の車両の推定値を計算するためにセンサデータを使用することによって走行距離推定を出力することができる。
【0058】
[0067]図４に示す特定のステップは、本発明の一実施形態による機械学習モデルを使用して総損失イベントの信頼度を予測する特定の方法を提供することを理解されたい。代替的な実施形態によれば、他の一連のステップもまた実行され得る。例えば、本発明の代替的な実施形態は、上記で概説したステップを異なる順序で実行してもよい。さらに、図４に示す個々のステップは、個々のステップに適切であるように様々な順序で実行することができる複数のサブステップを含んでもよい。さらに、特定の用途に応じて、さらなるステップが追加または削除されてもよい。当業者であれば、多くの変形例、修正例、および代替例を認識するであろう。
【0059】
[0068]図５は、いくつかの実施形態による、追加の入力データタイプを有する追加の機械学習モデルを使用して総損失イベントの信頼度を予測するためのフローチャートである。ブロック５０２では、モバイルデバイスのアプリケーション（例えば、前述の総損失モジュールなど）に関連付けられたクラッシュイベントが検出される。クラッシュイベント２０４などのクラッシュイベントは、モバイルデバイスの１つまたは複数のセンサ（例えば、モバイルデバイス１０４のセンサデータブロック１０８のセンサなど）を使用して検出することができる。第１の例として、モバイルデバイスは、例えばＧＰＳセンサや加速度計を用いて車両の動きの変化を検出することで、クラッシュイベントを検出することができる。ＧＰＳセンサは、速度（例えば、加速度を導出するために使用され得る速さおよび方向）を測定するために定義された基準フレームに対応することができる。加速度計は、モバイルデバイスの基準フレーム内の方向の加速度の大きさを測定する。モバイルデバイスは、加速度計測定値を使用して、運転中の加速度が典型的には特定のしきい値（例えば、複数のドライブにわたる平均化）内にあることを判定することができ、車両の基準フレームにマッピングされると、モバイルデバイスは、加速度計測定値を使用して車両に対する加速度の方向（例えば、車両に対して前方および後方）を判定することができる。加速度計は、横方向加速度または総損失モジュールが損失イベント（例えば、衝突、機械的故障など）の発生を判定するために使用することができるしきい値よりも大きい加速度を検出することができる。総損失モジュールは、加速度測定値に加えて、または加速度測定値の代わりにＧＰＳ測定値を使用して、車両の位置に対応する位置情報を提供することができる。例えば、モバイルデバイス（ひいては車両）の位置の変化が予期しないものであって、クラッシュイベントに起因する可能性が高いことを位置情報が示していると、総損失モジュールが判定することができる。
【0060】
[0069]別の例として、モバイルデバイス１０４は、加速度計測定値の大きさがしきい値よりも大きいこと（例えば、外力が車両に作用していることを示す）を検出することができる。加速度計の測定値を時間の関数として解析して、車両が加速度または速度を変化させた期間を決定することができる。加速度または速度の変化は、加速度計の測定値の変化が、例えばしきい値（例えば、２０ｍｐｈ）を超える速さから０に近いかまたは０に等しい速さまでなどの車両の速さの低下に対応するかどうかを示すことができる。総損失モジュールは、０または０に近い速さの延長された期間と共に急速な加速（例えば、車両の減速を示す後方方向に）がクラッシュイベントを示すと判定することができる。
【0061】
[0070]場合によっては、総損失モジュールは、急速な加速が衝突ではない損失イベントに対応すると判定することができる。総損失モジュールは、加速度計測定値をモバイルデバイスの他のセンサと相関させて、損失イベントのタイプを判定することができる。例えば、総損失モジュールは、衝突に関連付けるには大きすぎる（例えば、第１のしきい値よりも大きい）測定値などの異常な加速度計測定値を検出することができる。総損失モジュールは、加速度計測定値を磁力計測定値、モバイルデバイスによって取り込まれたオーディオまたはビデオなどと相関させて、異常な加速度計測定値の可能性のある原因を識別することができる。第１の例では、加速度計の測定値と時間的に重なる磁力計の測定値は、伝送の問題を示すことができる。別の例では、モバイルデバイスのマイクロフォンは、平坦なタイヤまたは吹き飛ばされたタイヤを示す音を取り込むことができる。センサ測定値を相関させることによって、総損失モジュールは、衝突、機械的故障、電気的故障、構造的故障などを含むがこれらに限定されない任意のタイプの総損失イベントを識別することができる。
【0062】
[0071]ブロック５０４において、プロセス５００はクラッシュ予測モデルを生成することを含む。例えば、クラッシュ予測は、しきい値を超える加速度計の測定値、車両の横方向位置の変化（例えば、車両が道路から外れていることを示す）、ランブルストリップ検出（例えば、車両が道路から外れているかどうかを判定するため）、頻繁なおよび／または急ブレーキ（例えば、渋滞が激しいこと、および／または運転者の前方の車両から適切な距離を維持していないことを示す）、注意力不足運転（例えば、車両が動いている間に検出された運転者とモバイルデバイスとの相互作用）などを判定するモバイルデバイスのセンサに基づいて生成され得る。クラッシュ予測モデルは、センサデータおよび上記の要因などのコンテキスト情報に基づいて車両衝突が発生した可能性を出力するための訓練されたモデルであってもよい。
【0063】
[0072]いくつかの実施形態では、クラッシュ予測モデルが出力を生成すると、プロセス５００はブロック５０６に進む。他の実施形態では、クラッシュ予測モデルがしきい値を下回る出力を生成すると、プロセス５００はブロック５０８に進む。例えば、クラッシュ予測モデルは、クラッシュイベントの可能性がしきい値クラッシュ可能性より大きい場合にのみ出力を生成することができる。場合によっては、クラッシュ予測モデルは、クラッシュイベントの可能性がしきい値クラッシュ可能性よりも小さいときにヌル出力を生成することができる。他の場合では、クラッシュ予測モデルは、クラッシュ予測モデルのすべての例のバイナリ値である出力を生成してもよい。これらの場合、プロセス５００は、バイナリ出力がクラッシュイベントが発生したことを示す場合にはブロック５０８に進み、バイナリ出力がクラッシュイベントが発生していないことを示す場合にはブロック５０６に進むことができる。
【0064】
[0073]ブロック５０６において、プロセス５００は、クラッシュ予測モデルの出力を使用してクラッシュ特徴ベクトルを生成することを含む。クラッシュ特徴ベクトルは、例えば、運転センサから受信したデータの一部または全部から抽出された特徴を含むことができ、クラッシュ予測（例えば、クラッシュイベントが発生した統計的可能性）を含むことができる。クラッシュ特徴ベクトルは、クラッシュ予測モデルによって出力されてもよく、クラッシュイベントの異なる態様に対応するモバイルデバイスのセンサから収集された様々な信号に関する要約統計（例えば、中央値、分散、および最大値）を含むことができる。その特徴は、クラッシュイベントの前、最中、または後に、異なる長さの時間窓を使用して抽出することができる。各窓は、クラッシュイベントの時点に中心付けられ、クラッシュイベントの前の時間およびクラッシュイベントの後の時間まで拡張することができる。クラッシュ特徴ベクトルの生成は、クラッシュイベントについての値のセットを生成する。
【0065】
[0074]ブロック５０８において、プロセス５００は、センサデータからクラッシュ特徴ベクトルを生成することを含む。センサデータは、モバイルデバイス１０４などのモバイルデバイスからのものであってもよい。例えば、クラッシュ予測モデルは、クラッシュが発生しなかったか、または低精度出力を生成したと予測したので、総損失モジュールは、モバイルデバイスのセンサから収集されたセンサデータから直接クラッシュ特徴ベクトルを生成することができる。総損失モジュールは、クラッシュ予測モデル出力が低精度であるか、またはクラッシュが発生しなかったと予測される場合、クラッシュ予測モデルの値にヌル値（またはバイナリ値）を設定してもよい。
【0066】
[0075]ブロック５０９において、プロセス５００は、エアバッグ情報が提供されるかどうかを判定することを含む。総損失モジュールは、クラッシュ特徴ベクトルを使用して、エアバッグ作動データタイプが提供されるかどうかを判定することができる。第１の例では、クラッシュ特徴ベクトルは、エアバッグステータス値を含んでもよい。総損失モジュールは、運転センサまたは追加のクラッシュ入力２０８からエアバッグステータスを受信することができる。場合によっては、運転センサは、クラッシュイベントに関連する時間ウィンドウの間にエアバッグ状態を検出することができる。モバイルデバイス１０４はまた、エアバッグ作動データタイプが提供されるか否かを判定するために他のセンサ（例えば、車両のエアバッグシステムインジケータに通信可能に結合する）を使用してもよい。例えば、エアバッグ作動データタイプは、ユーザインターフェースを介してユーザ入力から受信されてもよい。エアバッグ作動データタイプが利用できない例では、プロセス５００はブロック５１０に進む。エアバッグ作動データタイプが利用可能である別の例では、プロセス５００はブロック５２０に進む。
【0067】
[0076]ブロック５１０において、プロセス５００は、追加の車両情報が提供されるかどうかを判定することを含む。例えば、ＴＬＥ予測モデルは、追加情報（例えば、特徴ベクトルに含まれる追加の値）が利用可能であるかどうかを判定することができる。追加の車両情報の例は、流体漏れ、構造的完全性、ルート情報、交通、保守履歴、リコールなどを表す情報を含む。追加の車両情報が利用できない例では、プロセス５００はブロック５１２に進む。追加の車両情報が利用可能である別の例では、プロセス５００はブロック５１６に進む。
【0068】
[0077]ブロック５１２において、プロセス５００は、第１の機械学習モデルを使用して総損失イベントを予測することを含む。第１の機械学習モデルは、エアバッグ作動データタイプまたは追加の車両データを使用せずに、センサデータ（例えば、モバイルデバイスのセンサから、またはクラッシュ予測モデルからの出力）を使用して訓練することができる。第１の機械学習モデルは、車両が総損失イベントに関与したという信頼度を出力する決定木であってもよい。第１の機械学習モデルは、クラッシュ特徴ベクトルのデータ値の一部または全部を使用して、総損失イベントの信頼度を予測することができる。プロセス５００はブロック５１２からブロック５１４に進む。
【0069】
[0078]ブロック５１４において、プロセス５００は、図４のブロック４２４に関連して説明したように追加の出力を計算することを含む。例えば、ＴＬＥ予測モデルは、モバイルデバイス１０４のユーザに追加の信頼度を出力することができる。第１の例では、ＴＬＥ予測モデルは、ある期間にわたって移動した距離および車両年数（例えば、年式から計算される）を計算するためにセンサデータを使用することによって走行距離推定を出力することができる。ＴＬＥ予測モデルは、走行距離推定および車両年数を用いて、クラッシュイベント時の車両の推定値をさらに出力することができる。
【0070】
[0079]ブロック５１０に戻って、追加の車両情報が提供されるプロセス５００の一例では、プロセス５００はブロック５１６に進む。ブロック５１６において、プロセス５００は、第３の機械学習モデルを使用して総損失イベントを予測することを含む。第３の機械学習モデルは、エアバッグ作動データタイプを使用せずに、追加の車両情報の少なくとも１つのデータタイプを含む（例えば、運転センサ２０２またはクラッシュ予測モデル出力からの）センサデータを使用して訓練することができる。場合によっては、ＴＬＥ予測モデルは、追加のデータタイプの異なる値を有する複数の例で第３の機械学習モデルを使用してもよい。
【0071】
[0080]例えば、第３の機械学習モデルは、流体漏れインジケータが提供されるときに信頼度を生成することができる。この例では、第３の機械学習モデルは、総損失モジュールによって提供された流体漏れ情報に基づいて、クラッシュイベントの後に流体漏れがあったかどうか（例えば、漏れが検出されたか、漏れが検出されなかったかのいずれか）を示す値に基づいて、クラッシュイベントが総損失であるという信頼度を生成することができる。第３の機械学習モデルは、第１のデータセットおよび流体漏れ情報（例えば、漏れを検出、漏れを非検出）を表す訓練データを使用して訓練することができる。第３の機械学習モデルは、クラッシュイベントおよび流体漏れ情報に関連するセンサ測定値に対応する信頼度を生成することができる。第３の機械学習モデルは、車両が総損失イベントに関与したという信頼度を出力する決定木であってもよい。第３の機械学習モデルは、クラッシュ特徴ベクトルのデータ値の一部または全部を使用して、総損失イベントの信頼度を予測することができる。プロセス５００はブロック５１６からブロック５１８に進む。
【0072】
[0081]ブロック５１８において、プロセス５００は、追加の出力を計算することを含む。ＴＬＥ予測モデルは、図４に関連して説明したように、ブロック５１２からの出力ならびにブロック４２４に関連して説明した追加の出力を含む総損失イベントに関する追加の出力を計算することができる。例えば、ＴＬＥ予測モデルは、モバイルデバイス１０４のユーザに追加の信頼度を出力することができる。第１の例では、ＴＬＥ予測モデルは、ある期間にわたって移動した距離および車両年数（例えば、年式から計算される）を計算するためにセンサデータを使用することによって走行距離推定を出力することができる。ＴＬＥ予測モデルは、走行距離推定および車両年数を用いて、クラッシュイベント時の車両の推定値をさらに出力することができる。
【0073】
[0082]ブロック５０９に戻って、エアバッグ作動データタイプが利用可能であるプロセス５００の一例では、プロセス５００はブロック５２０に進む。ブロック５２０において、プロセス５００は、追加の車両情報が提供されるかどうかを判定することを含む。例えば、ＴＬＥ予測モデルは、追加情報（例えば、特徴ベクトルに含まれる追加の値）が利用可能であるかどうかを判定することができる。追加の車両情報の例は、流体漏れ、構造的完全性、ルート情報、交通、保守履歴、リコールなどを表す情報を含む。追加の車両情報が利用できない例では、プロセス５００はブロック５２２に進む。追加の車両情報が利用可能である別の例では、プロセス５００はブロック５２６に進む。
【0074】
[0083]ブロック５２２において、プロセス５００は、第２の機械学習モデルを使用して総損失イベントを予測することを含む。第２の機械学習モデルは、センサデータ（例えば、運転センサ２０２またはクラッシュ予測モデル出力から）およびエアバッグ作動データを使用して訓練することができる。第２の機械学習モデルは、車両が総損失イベントに関与したという信頼度を出力する決定木であってもよい。第２の機械学習モデルは、クラッシュ特徴ベクトルのデータ値の一部または全部を使用して、総損失イベントの信頼度を予測することができる。プロセス５００はブロック５２２からブロック５２４に進む。
【0075】
[0084]ブロック５２４において、プロセス５００は追加の出力を計算することを含む。例えば、ＴＬＥ予測モデルは、ある期間にわたって移動した距離および車両年数（例えば、年式から計算される）、ならびに走行距離推定および車両年数を使用したクラッシュイベント時の車両の推定値を計算するためにセンサデータを使用することによって走行距離推定を出力することができる。
【0076】
[0085]ブロック５２０に簡単に戻ると、追加の車両情報が提供されるプロセス５００の一例では、プロセス５００はブロック５２６に進む。ブロック５２６において、プロセス５００は、第４の機械学習モデルを使用して総損失イベントを予測することを含む。第４の機械学習モデルは、センサデータ（例えば、運転センサ２０２またはクラッシュ予測モデル出力から）およびエアバッグ作動データならびに少なくとも１つのデータタイプの追加の車両情報を使用して訓練することができる。場合によっては、ＴＬＥ予測モデルは、追加のデータタイプの異なる値を有する複数の例で第４の機械学習モデルを使用してもよい。
【0077】
[0086]例えば、第４の機械学習モデルは、エアバッグ作動データが提供されるときに信頼度を生成することができる。この例では、第４の機械学習モデルは、総損失モジュールによって提供されたエアバッグ情報に基づいて、クラッシュイベント中にエアバッグが展開されたかどうか（例えば、展開されたか、または展開されていないかのいずれか）を示す値に基づいて、クラッシュイベントが総損失であるという信頼度を生成することができる。第４の機械学習モデルは、センサデータおよびエアバッグ情報（例えば、展開済み、非展開）を表す訓練データを使用して訓練することができる。第４の機械学習モデルは、クラッシュイベントおよびエアバッグ情報に関連するセンサ測定値に対応する信頼度を生成することができる。第４の機械学習モデルは、車両が総損失イベントに関与したという信頼度を出力する決定木であってもよい。第４の機械学習モデルは、クラッシュ特徴ベクトルのデータ値の一部または全部を使用して、総損失イベントの信頼度を予測することができる。プロセス５００はブロック５２６からブロック５２８に進む。
【0078】
[0087]ブロック５２８において、プロセス５００は追加の出力を計算することを含む。例えば、ＴＬＥ予測モデルは、総損失イベントに関する追加の出力を計算する。いくつかの例では、ＴＬＥ予測モデルは、他の様々なタイプのデータのために訓練された追加のモデルを含んでもよい。ＴＬＥ予測モデルは、異なるデータタイプに対応し、各クラッシュイベントに利用可能なデータタイプに合わせて調整された予測を提供するために、任意の数のモデルを使用することができる。
【0079】
[0088]図５に示す特定のステップは、本発明の一実施形態による追加の入力データタイプを有する追加の機械学習モデルを使用して総損失イベントの信頼度を予測する特定の方法を提供することを理解されたい。代替的な実施形態によれば、他の一連のステップもまた実行され得る。例えば、本発明の代替的な実施形態は、上記で概説したステップを異なる順序で実行してもよい。さらに、図５に示す個々のステップは、個々のステップに適切であるように様々な順序で実行することができる複数のサブステップを含んでもよい。さらに、特定の用途に応じて、さらなるステップが追加または削除されてもよい。当業者であれば、多くの変形例、修正例、および代替例を認識するであろう。
【0080】
[0089]図６は、いくつかの実施形態による、追加の特徴ベクトルを使用して総損失イベントの信頼度を予測して追加の信頼値を生成するための例示的なプロセス６００である。ブロック６０１において、プロセス６００は、モバイルデバイス（例えば、モバイルデバイス１０４のセンサデータブロック１０８のセンサなど）の１つまたは複数のセンサからセンサ測定値を受信することを含む。例えば、図２に示す総損失モジュール２０１などの総損失モジュールは、モバイルデバイスの動きまたは外部環境に関するコンテキスト情報を検出する運転センサからの入力を受信することができる。
【0081】
[0090]ブロック６０２において、プロセス６００は、モバイルデバイスの運転センサからのセンサ測定値を使用して、クラッシュイベントの発生を示すクラッシュイベントを検出することを含む。ブロック６０２で実行される動作は、ブロック３０２，４０２および５０２に関連して説明した動作と実質的に同様である。例えば、クラッシュイベントは、例えば、ＧＰＳセンサまたは加速度計からのセンサ測定値を使用することによって、車両の動きの変化から検出することができる。ＧＰＳセンサは、速度（例えば、加速度を導出するために使用され得る速さおよび方向）を測定するために定義された基準フレームに対応することができる。加速度計は、モバイルデバイスの基準フレーム内の方向の加速度の大きさを測定する。加速度計測定値を使用して、運転中の加速度が典型的には特定のしきい値（例えば、複数のドライブにわたる平均化）内にあることを判定することができ、車両の基準フレームにマッピングされると、加速度計測定値を使用して車両に対する加速度の方向（例えば、車両に対して前方および後方）を判定することができる。加速度計は、横方向加速度または総損失モジュールが損失イベント（例えば、衝突、機械的故障など）の発生を判定するために使用することができるしきい値よりも大きい加速度を検出することができる。総損失モジュールは、加速度測定値に加えて、または加速度測定値の代わりにＧＰＳ測定値を使用して、車両の位置に対応する位置情報を提供することができる。例えば、総損失モジュールは、位置情報が、車両の位置の変化が予想外であり、クラッシュイベントに起因する可能性が高いことを示すと判定することができる。
【0082】
[0091]別の例として、モバイルデバイス１０４は、加速度計測定値の大きさがしきい値よりも大きいこと（例えば、外力が車両に作用していることを示す）を検出することができる。加速度計の測定値を時間の関数として解析して、車両が加速度または速度を変化させた期間を決定することができる。加速度または速度の変化は、加速度計の測定値の変化が、例えばしきい値（例えば、２０ｍｐｈ）を超える速さから０に近いかまたは０に等しい速さまでなどの車両の速さの低下に対応するかどうかを示すことができる。総損失モジュールは、０または０に近い速さの延長された期間と共に急速な加速（例えば、車両の減速を示す後方方向に）がクラッシュイベントを示すと判定することができる。
【0083】
[0092]場合によっては、総損失モジュールは、急速な加速が衝突ではない損失イベントに対応すると判定することができる。総損失モジュールは、加速度計測定値をモバイルデバイスの他のセンサと相関させて、損失イベントのタイプを判定することができる。例えば、総損失モジュールは、衝突に関連付けるには大きすぎる（例えば、第１のしきい値よりも大きい）測定値などの異常な加速度計測定値を検出することができる。総損失モジュールは、加速度計測定値を磁力計測定値、モバイルデバイスによって取り込まれたオーディオまたはビデオなどと相関させて、異常な加速度計測定値の可能性のある原因を識別することができる。第１の例では、加速度計の測定値と時間的に重なる磁力計の測定値は、伝送の問題を示すことができる。別の例では、モバイルデバイスのマイクロフォンは、平坦なタイヤまたは吹き飛ばされたタイヤを示す音を取り込むことができる。センサ測定値を相関させることによって、総損失モジュールは、衝突、機械的故障、電気的故障、構造的故障などを含むがこれらに限定されない任意のタイプの総損失イベントを識別することができる。
【0084】
[0093]ブロック６０４において、プロセス６００は、センサ測定値から第１のデータセットを識別することを含み、第１のデータセットはクラッシュイベントに関連付けられる。ブロック６０４で実行される動作は、ブロック３０４に関連して説明した動作と実質的に同様である。例えば、モバイルデバイスは、運転トリップ中にモバイルデバイスのセンサからセンサ測定値を連続的に収集することができる。クラッシュイベントが検出されると、総損失モジュールは、クラッシュイベントに関連するセンサ測定値の一部を識別することができる。場合によっては、第１のデータセットは、クラッシュイベントを含む期間にわたって収集されたセンサ測定値を含むことができる。一例では、第１の期間は、クラッシュイベントの前の第１の時刻（例えば、クラッシュイベントの１０秒前、３０秒前、５分前など）に開始し、クラッシュイベントの後の第２の時刻（例えば、クラッシュイベントの１０秒後、３０秒後、５分後など）に終了することができる。他の例では、第１のデータセットを記録するための期間は、センサ測定値の様々なしきい値（例えば、しきい値加速度、ＧＰＳ道路境界または障害物境界など）によって決定されてもよい。
【0085】
[0094]場合によっては、総損失モジュールは、車両の動作状態に基づいて運転中にセンサを動的に制御することができる。総損失モジュールは、どのセンサを作動させるか（例えば、センサ測定値を収集するためにどのセンサが使用されるべきか）および／またはそれらのセンサのサンプリングレートに関する判定の一部として、外部ソースから追加のデータを受信することができる。追加のデータは、現在の天候、経路情報、道路状況、交通、経路に沿った過去の衝突、過去の衝突または運転者の総損失イベント、車両情報（例えば、製造元、モデル、年、保守記録など）を含むことができるが、これらに限定されない。例えば、悪天候でのストップアンドゴー交通では、総損失モジュールは、他の車両の近接性および悪天候での衝突の可能性のために、より多くのセンサを作動させることができる。別の例では、車両が交通のない晴れた日に高速道路上にある場合、総損失モジュールはより少ないセンサを動作させる（例えば、より少ないセンサからセンサ測定値を収集するか、またはより低いサンプリングレートでセンサ測定値を収集する）ことができる。
【0086】
[0095]クラッシュイベントを検出すると（または経路に沿って衝突が発生する可能性が高いことを検出すると）、総損失モジュールは、（例えば、以前に使用されていなかったセンサによる測定値の収集を開始するために）非アクティブなセンサを動的に起動し、および／または（または総損失モジュールが衝突が発生する可能性が高いことを識別した場合には）クラッシュイベント中にアクティブなセンサのサンプリングレートを増加させることができる。総損失モジュールは、使用されるべきモバイルデバイスのセンサの第１のサブセットを指定することができる。クラッシュイベントが検出されると、総損失モジュール２０１は、モバイルデバイスのセンサのすべてまでを含むセンサの第２のサブセットを指定してもよい。プロセス６００は、ブロック６０６とブロック６０８とで並行して進むことができる。
【0087】
[0096]ブロック６０６において、プロセス６００は、第１のデータセットおよび車両データを使用して第１の特徴ベクトルを生成することを含み、車両データは車両の識別子を含む。ブロック６０６で実行される動作は、ブロック３０６に関連して説明した動作と実質的に同様である。例えば、第１の特徴ベクトルは、クラッシュイベントの個々の測定可能な特性（例えば、センサデータ）を表すことができ、車両の特性を表す特徴を含む。総損失モジュール２０１は、第１の特徴ベクトルを第１の機械学習モデル２１２などの機械学習モデルに提供してもよい。
【0088】
[0097]ブロック６０７において、プロセス６００は、追加のデータタイプを含む入力を受信することを含む。ＴＬＥ予測モデル２１０は、追加のクラッシュ入力２０８などの追加のデータタイプを受信することができる。ＴＬＥ予測モデル２１０は、車両情報（例えば、流体漏れインジケータ、構造的破壊インジケータなど）などの追加のデータタイプを受信することができる。
【0089】
[0098]ブロック６０８において、プロセス６００は、クラッシュイベント、車両データ、および追加のデータタイプに関連する第１のデータセットを使用して第２の特徴ベクトルを生成することを含む。ブロック６０８で実行される動作は、ブロック３０８に関連して説明した動作と実質的に同様である。例えば、総損失モジュールは、１つまたは複数の追加のデータタイプを第１の特徴ベクトルに連結することによって、第１の特徴ベクトルから第２の特徴ベクトルを生成することができる。第２の特徴ベクトルの特徴は、クラッシュイベントの個々の測定可能な特性（例えば、センサデータ）、車両の特性を表す特徴、および１つまたは複数の追加のデータタイプを表す特徴を表すことができる。１つまたは複数の追加のデータタイプの例には、流体漏れの測定された表示、エアバッグ展開、運転者の病状、ユーザインターフェースを介して運転者から受信した調査質問に対する応答などを表す特徴が含まれるが、これらに限定されない。
【0090】
[0099]ブロック６１０において、プロセス６００は、第１の機械学習モデルおよび第１の特徴ベクトルを使用して第１の信頼値を生成することによって、総損失イベントの第１の信頼度を予測することを含む。ブロック６１０における動作は、ブロック４１２に関連する動作と実質的に同様である。例えば、第１の機械学習モデルは、センサデータおよび車両データ（車両の製造元、モデル、年、ＶＩＮなど）を表す訓練データを使用して訓練することができる。第１の機械学習モデルは、クラッシュイベントおよび車両データに関連するセンサ測定値に対応する信頼度を生成することができる。第１の機械学習モデルは、車両が総損失イベントに関与したという信頼度を出力する決定木であってもよい。第１の機械学習モデルは、クラッシュ特徴ベクトルのデータ値の一部または全部を使用して、総損失イベントの信頼度を予測することができる。
【0091】
[0100]ブロック６１２において、プロセス６００は、第２の機械学習モデルおよび第２の特徴ベクトルを使用して第２の信頼値を生成することによって、総損失イベントの第２の信頼度を予測することを含む。例えば、第２の機械学習モデルは、第２の特徴ベクトルを使用して、エアバッグ展開データタイプ（例えば、クラッシュイベント中にエアバッグが展開したか、または展開しなかったことを示す値）を有するクラッシュイベントの信頼度を生成することができる。エアバッグ展開データタイプの値は、センサデータから、機械学習モデルによる予測から、またはユーザ入力から導出されてもよい。場合によっては、第２の機械学習モデルは、エアバッグ情報が提供されない異なる値を使用して、同じクラッシュイベントに対する第２の信頼度を生成することができる。これらの例では、第２の機械学習モデルは、エアバッグ展開データタイプが（クラッシュイベント中に）非展開に設定されている第２の信頼度と、エアバッグ展開データセットが（クラッシュイベント中に）展開されている別の第２の信頼度と、を生成することができる。
【0092】
[0101]図４に関して説明したような第１の例では、総損失モジュールは、提供されたエアバッグ情報を使用して第２の信頼度を計算することができる第２の機械学習モデルへの入力としてエアバッグ情報を提供することができる。別の例では、エアバッグ情報は、第２の機械学習モデルに提供されない。この例では、第２の機械学習モデルは、異なる値を使用して第２の信頼度を生成することができ、最初にエアバッグの非展開を示すようにエアバッグ作動データを設定する。さらに、第２の機械学習モデルは、エアバッグ展開を示すように設定されたエアバッグ作動値を用いて追加の信頼値を生成することができる。第２の機械学習モデルはエアバッグ作動データを使用するように訓練され得るので、複数の出力は、クラッシュイベントのエアバッグ作動データが総損失イベントが発生したという信頼度に影響を及ぼすかどうかを判定することができる。
【0093】
[0102]例えば、特定のクラッシュイベントの場合、第２の機械学習モデルは、エアバッグ展開データタイプの値が非展開（例えば、エアバッグは展開しなかった）に設定される第２の信頼度を生成することができる。第２の信頼度がしきい値信頼度未満であると判定することができる。第２の機械学習モデルは、エアバッグ展開データタイプの値が展開を示す追加の第２の信頼度を生成することができる。追加の第２の信頼度がしきい値信頼度よりも大きいと判定することができる。出力（例えば、総損失が識別されるかどうか）を変化させる第２の信頼度と追加の第２の信頼度との間に競合（例えば、差）があるため、総損失モジュールは、クラッシュイベントが総損失イベントであるかどうかを判定するためにエアバッグ展開情報が必要であり得ると判定する。それらの例では、エアバッグ情報を取得するために、ユーザ入力を介した追加情報の要求が要求されてもよい。場合によっては、第２の機械学習モデルは、第２の信頼度と追加の第２の信頼度との間のしきい値差を計算して、競合（例えば、２０％の差）が存在すると判定することができる。
【0094】
[0103]ブロック６１４において、プロセス６００は、総損失イベントを予測するために追加のクラッシュデータが使用されるべきかどうかを判定することを含む。例えば、ＴＬＥ予測モデル２１０は、第１の信頼度、第２の信頼度、または追加の第２の信頼度における競合を識別することができる。ＴＬＥ予測モデル２１０は、エアバッグ作動データなどの追加のクラッシュデータが、第１の信頼度、第２の信頼度、または追加の第２の信頼度の間の競合を解決する予測を提供し得ると決定することができる。ＴＬＥ予測モデル２１０は、競合に基づいて、追加のクラッシュデータ（例えば、エアバッグ作動データ）が必要であると決定することができる。ＴＬＥ予測モデル２１０は、調査質問などを用いて、モバイルデバイス１０４のユーザインターフェースを介したユーザ入力からエアバッグ作動データを要求することができる。追加的または代替的に、ＴＬＥ予測モデル２１０は、エアバッグ作動データなどの追加のクラッシュデータを、モバイルデバイスのセンサからの、または外部ソース（例えば、１つまたは複数の外部センサまたはデバイス）からの追加のデータから導出し、追加のデータに含まれるデータタイプを処理するように訓練された機械学習モデルを使用して追加のデータを処理することができる。追加のクラッシュデータが必要とされないプロセス６００の一例では、プロセス６００はブロック６１６に進む。そうでない場合、追加のクラッシュデータが必要とされるプロセス６００では、プロセス６００はブロック６１８に進む。
【0095】
[0104]ブロック６１６において、プロセス６００は総損失信頼度を出力することを含む。例えば、ＴＬＥ予測モデル２１０は、第１の信頼度または第２の信頼度が総損失イベントの決定的な予測であると判定することができる。例えば、総損失信頼度は、エアバッグ情報が利用できず、第２の信頼度または追加の第２の信頼度と競合しない場合、第１の機械学習モデルの第１の信頼度とすることができる。総損失信頼度は、エアバッグ情報が利用可能であり、第２の信頼度を生成するために使用される場合の第２の信頼度とすることができる。ＴＬＥ予測モデル２１０は、総損失信頼度をモバイルデバイスのユーザに出力することができる。代替的または追加的に、ＴＬＥ予測モデル２１０は、総損失信頼度を別のコンピューティングシステムに送信することができる。例えば、ブロック６１７において、プロセス６００は、総損失の表示を含む通知を送信することを含む。総損失の表示を送信することは、データ送信ブロック１６４を使用することを含むことができる。例えば、総損失を送信することは、総損失の表示を送信するために無線トランシーバ１６８、セルラトランシーバ１７２、または直接送信１７６のうちの１つまたは複数を使用することを含むことができる。
【0096】
[0105]ブロック６１４に戻って、追加のクラッシュデータが必要とされるプロセス６００の一例では、プロセス６００はブロック６１８に進む。ブロック６１８において、プロセス６００は、追加のクラッシュデータを取得することを含む。ＴＬＥ予測モデル２１０は、エアバッグ作動データなどの追加のクラッシュデータを受信することができる。いくつかの例では、追加のクラッシュデータはまた、車両内の運転者または乗客の医療状態、クラッシュの環境に関するコンテキストデータ（例えば、天候、道路状況など）を含むことができる。
【0097】
[0106]ブロック６２０において、プロセス６００は、追加のクラッシュデータを含む第３の信頼度を出力することを含む。例えば、ＴＬＥ予測モデル２１０は、第２の特徴ベクトルおよび追加のクラッシュデータ（例えば、第１の特徴ベクトルのセンサ測定値とは異なるクラッシュデータ）を含む第３の信頼度を生成することができる。ＴＬＥ予測モデル２１０は、追加のクラッシュデータの１つまたは複数の態様を使用して第３の信頼度を生成することができる。総損失信頼度は、追加情報が利用可能であり、第３の信頼度を生成するために使用されるときの第３の信頼度であってもよい。ＴＬＥ予測モデル２１０は、総損失信頼度をモバイルデバイスのユーザに出力することができる。代替的または追加的に、ＴＬＥ予測モデル２１０は、総損失信頼度を別のコンピューティングシステムに送信することができる。例えば、ブロック６２１において、プロセス６００は、総損失の表示を含む通知を送信することを含む。総損失の表示を送信することは、データ送信ブロック１６４を使用することを含むことができる。例えば、総損失を送信することは、総損失の表示を送信するために無線トランシーバ１６８、セルラトランシーバ１７２、または直接送信１７６のうちの１つまたは複数を使用することを含むことができる。
【0098】
[0107]図６に示す特定のステップは、本発明の一実施形態による追加の信頼値を生成するために追加の特徴ベクトルを使用して総損失イベントの信頼度を予測する特定の方法を提供することを理解されたい。代替的な実施形態によれば、他の一連のステップもまた実行され得る。例えば、本発明の代替的な実施形態は、上記で概説したステップを異なる順序で実行してもよい。さらに、図６に示す個々のステップは、個々のステップに適切であるように様々な順序で実行されてもよい複数のサブステップを含んでもよい。さらに、特定の用途に応じて、さらなるステップが追加または削除されてもよい。当業者であれば、多くの変形例、修正例、および代替例を認識するであろう。
【0099】
[0108]図７は、いくつかの実施形態による、検出されたクラッシュの総損失イベントを予測するための結果のグラフ７００の一例である。図７に示すように、グラフ７００は、検出されたクラッシュのセットの総損失予測の精度対パーセンテージのプロットを示す。グラフ７００の縦軸は、総損失予測の精度を表す。本明細書で使用される場合、「精度」は、検索されたインスタンス（例えば、真陽性）の中の関連するインスタンス（例えば、車両クラッシュ）の割合である。グラフ７００の横軸は、リコールを表す。本明細書で使用される場合、「リコール」は、（例えば、完全性の尺度）実際に検索された関連インスタンスの総量の割合である。ＴＬＥ予測モデルは、上述したように、様々な入力データの組み合わせを用いることができる。例えば、入力データは、本明細書でさらに説明するように、センサデータ、車両データ、エアバッグ作動データ、およびクラッシュ確認データを含むことができる。
【0100】
[0109]図７に示すグラフ７００では、精度は、ＴＬＥ予測モデルに利用可能であり、ＴＬＥ予測モデルによって使用されるデータ入力に基づいて変化する。例えば、短い破線で表される曲線７０２は、運転センサからの出力、車両の製造元、モデル、および年式のＴＬＥ予測モデルへの入力が与えられた場合に、ＴＬＥ予測モデルを使用して生成された総損失予測の精度を示す。センサデータは、モバイルデバイス１０４などのモバイルデバイスの１つまたは複数のセンサから受信したデータを含むことができる。１つまたは複数のセンサは、全地球測位システム（ＧＰＳ）受信器、加速度計、磁力計、ジャイロスコープ、マイクロフォン、コンパス、および／または気圧計などのセンサを含むことができる。曲線７０２のセンサデータは、１２，０００マイルにわたって毎秒０．２フレームで収集された。予測は、毎秒０．２フレームよりも高いまたは低いフレームレートで収集されたセンサデータに基づいてもよい。予測はまた、１２，０００マイルよりも少ないまたは多いマイル数にわたって収集されたセンサデータに基づいてもよい。図７に示すように、曲線７０２は、運転センサならびに車両の製造元、モデルおよび年式からの出力を使用して、ＴＬＥモデルが５０％のリコールで７８～８０％の精度を達成することができることを示している。
【0101】
[0110]別の例として、点線で表される曲線７０４は、運転センサからの出力ならびに車両の製造元、モデルおよび年式のＴＬＥ予測モデルへの入力が与えられた場合に、ＴＬＥ予測モデルを使用して生成された総損失予測の精度を示す。センサデータは、モバイルデバイス１０４などのモバイルデバイスの１つまたは複数のセンサから受信したデータを含むことができる。１つまたは複数のセンサは、全地球測位システム（ＧＰＳ）受信器、加速度計、磁力計、ジャイロスコープ、マイクロフォン、コンパス、および／または気圧計などのセンサを含むことができる。曲線７０４のセンサデータは、１２，０００マイルにわたって毎秒２フレームで収集された。予測は、毎秒２フレームよりも高いまたは低いフレームレートで収集されたセンサデータに基づいてもよい。予測はまた、１２，０００マイルよりも少ないまたは多いマイル数にわたって収集されたセンサデータに基づいてもよい。図７に示すように、フレームレートを増加させると、曲線７０２と比較して曲線７０４のそれらのリコール値でのより高い精度によって実証されるように、約４０％のリコールから９０％のリコールまで精度が増加する。
【0102】
[0111]曲線７０２および曲線７０４を生成するために使用されるＴＬＥモデルによって使用されるデータに加えて、実線で表される曲線７０６は、センサデータならびに車両の製造元、モデル、および年式をエアバッグ検出データで補完する。センサデータは、モバイルデバイス１０４などのモバイルデバイスの１つまたは複数のセンサから受信したデータを含むことができる。１つまたは複数のセンサは、全地球測位システム（ＧＰＳ）受信器、加速度計、磁力計、ジャイロスコープ、マイクロフォン、コンパス、および／または気圧計などのセンサを含むことができる。曲線７０６のセンサデータは、１２，０００マイルにわたって毎秒０．２フレームで収集された。予測は、毎秒０．２フレームよりも高いまたは低いフレームレートで収集されたセンサデータに基づいてもよい。予測はまた、１２，０００マイルよりも少ないまたは多いマイル数にわたって収集されたセンサデータに基づいてもよい。エアバッグ作動データは、ユーザインターフェースを介してユーザ入力から受信されてもよい。代替的または追加的に、エアバッグ作動データは、車両センサなどの１つまたは複数の外部センサから受信されてもよい。図７に示すように、センサデータおよび車両データに加えてエアバッグ作動データをＴＬＥ予測モデルに提供することにより、曲線７０２および曲線７０４と比較して曲線７０６のリコール値におけるより高い精度によって実証されるように、約０％のリコールから７５％のリコールまでの精度の向上がもたらされる。
【0103】
[0112]別の例では、一点鎖線で表される曲線７０８は、運転センサからの出力、車両の製造元、モデルおよび年、ならびにエアバッグ作動データのＴＬＥ予測モデルへの入力が与えられた場合に、ＴＬＥ予測モデルを使用して生成された総損失予測の精度を示す。センサデータは、モバイルデバイス１０４などのモバイルデバイスの１つまたは複数のセンサから受信したデータを含むことができる。１つまたは複数のセンサは、全地球測位システム（ＧＰＳ）受信器、加速度計、磁力計、ジャイロスコープ、マイクロフォン、コンパス、および／または気圧計などのセンサを含むことができる。曲線７０８のセンサデータは、１２，０００マイルにわたって毎秒２フレームで収集された。予測は、毎秒２フレームよりも高いまたは低いフレームレートで収集されたセンサデータに基づいてもよい。予測はまた、１２，０００マイルよりも少ないまたは多いマイル数にわたって収集されたセンサデータに基づいてもよい。エアバッグ作動データは、ユーザインターフェースを介してユーザ入力から受信されてもよい。代替的または追加的に、エアバッグ作動データは、車両センサなどの１つまたは複数の外部センサから受信されてもよい。図７に示すように、フレームレートを増加させると、曲線７０６と比較して曲線７０８のそれらのリコール値でのより高い精度によって実証されるように、約３５％のリコールから９０％のリコールまで精度が増加する。
【0104】
[0113]曲線７０６および曲線７０８を生成するために使用されるＴＬＥモデルによって使用されるデータに加えて、長い破線によって表される曲線７１０は、センサデータ、車両の製造元、モデル、および年式、ならびにエアバッグ検出データをクラッシュ確認データで補完する。センサデータは、モバイルデバイス１０４などのモバイルデバイスの１つまたは複数のセンサから受信したデータを含むことができる。１つまたは複数のセンサは、全地球測位システム（ＧＰＳ）受信器、加速度計、磁力計、ジャイロスコープ、マイクロフォン、コンパス、および／または気圧計などのセンサを含むことができる。エアバッグ作動データは、ユーザインターフェースを介してユーザ入力から受信されてもよい。代替的または追加的に、エアバッグ作動データは、車両センサなどの１つまたは複数の外部センサから受信されてもよい。クラッシュ確認データは、ユーザインターフェースを介してユーザ入力から受信されてもよい。例えば、クラッシュ確認データは、総損失モジュール２０１によってモバイルデバイス１０４のユーザインターフェースを介してユーザ（例えば、運転者または乗客など）に提供される調査質問への応答とすることができる。図７に示すように、センサデータ、車両データ、およびエアバッグ作動データに加えてクラッシュ確認データをＴＬＥ予測モデルに提供することにより、曲線７０６および曲線７０８と比較して曲線７１０のそれらのリコール値におけるより高い精度によって実証されるように、約３５％のリコールから９５％のリコールまで精度が向上する。
【0105】
[0114]図８は、いくつかの実施形態による、確認されたクラッシュで検出されたクラッシュの総損失イベントを予測するための結果のグラフ８００の一例である。図８に示すように、グラフ８００は、検出されたクラッシュのセットの総損失予測の精度対パーセンテージのプロットを示す。グラフ８００の縦軸は、総損失予測の精度を表す。本明細書で使用される場合、「精度」は、検索されたインスタンス（例えば、真陽性）の中の関連するインスタンス（例えば、車両クラッシュ）の割合である。グラフ８００の横軸は、リコールを表す。本明細書で使用される場合、「リコール」は、（例えば、完全性の尺度）実際に検索された関連インスタンスの総量の割合である。ＴＬＥ予測モデルは、上述したように、様々な入力データの組み合わせを用いることができる。例えば、入力データは、本明細書でさらに説明するように、センサデータ、車両データ、エアバッグ作動データ、およびクラッシュ確認データを含むことができる。
【0106】
[0115]図８に示すグラフ８００では、精度は、ＴＬＥ予測モデルに利用可能であり、ＴＬＥ予測モデルによって使用されるデータ入力に基づいて変化する。例えば、太い実線で表されている曲線８０２は、車両データのみのＴＬＥ予測モデルへの入力が与えられた場合にＴＬＥ予測モデルを使用して生成された総損失予測の精度を示す。総損失モジュール２０１は、車両データをＴＬＥ予測モデルに提供することができる。車両データは、車両固有情報に対応する１つまたは複数のデータタイプを含むことができる。車両データのデータタイプの例には、製造元、モデル、製造年、トリムパッケージ（例えば、品質および特徴）、過去の事故履歴、車両識別番号、車両に対する過去の保険請求、車両メンテナンス記録、それらの組み合わせなどが含まれるが、これらに限定されない。図８に示すように、曲線８０２は、車両データのみを入力として使用して、ＴＬＥモデルが５０％のリコールで６３％の精度を達成することができることを示している。
【0107】
[0116]別の例として、細い破線で表される曲線８０４は、運転センサのみからの出力のＴＬＥ予測モデルへの入力が与えられた場合にＴＬＥ予測モデルを使用して生成された総損失予測の精度を示す。センサデータは、モバイルデバイス１０４などのモバイルデバイスの１つまたは複数のセンサから受信したデータを含むことができる。１つまたは複数のセンサは、全地球測位システム（ＧＰＳ）受信器、加速度計、磁力計、ジャイロスコープ、マイクロフォン、コンパス、および／または気圧計などのセンサを含むことができる。図８に示すように、曲線８０２は、車両データのみではなく、運転センサからの出力のみを使用して、ＴＬＥモデルが５０％のリコールで約７０％の精度を達成することができることを示している。
【0108】
[0117]太い一点鎖線で表される曲線８０６は、運転センサからの出力と車両データとの組み合わせを使用してＴＬＥ予測モデルを使用して生成された総損失予測の精度を示す。センサデータは、モバイルデバイス１０４などのモバイルデバイスの１つまたは複数のセンサから受信したデータを含むことができる。１つまたは複数のセンサは、全地球測位システム（ＧＰＳ）受信器、加速度計、磁力計、ジャイロスコープ、マイクロフォン、コンパス、および気圧計などのセンサを含むことができる。車両データは、車両固有情報に対応する１つまたは複数のデータタイプを含むことができる。車両データのデータタイプの例には、製造元、モデル、製造年、トリムパッケージ（例えば、品質および特徴）、過去の事故履歴、車両識別番号、車両に対する過去の保険請求、車両メンテナンス記録、それらの組み合わせなどが含まれるが、これらに限定されない。図８に示すように、センサデータと車両データとの組み合わせをＴＬＥ予測モデルに提供することにより、曲線８０２および曲線８０４と比較して曲線８０６のそれらのリコール値におけるより高い精度によって実証されるように、約１０％のリコールから９５％のリコールまでの精度の向上がもたらされる。さらに、曲線８０６は、運転センサからの出力、車両の製造元、モデル、および年式を使用して、ＴＬＥモデルが５０％のリコールで８０％の精度を達成できることを示している。
【0109】
[0118]曲線８０４を生成するために使用されるＴＬＥモデルによって使用されるデータに加えて、細い実線によって表される曲線８０８は、センサデータをエアバッグ検出データで補完する。センサデータは、モバイルデバイス１０４などのモバイルデバイスの１つまたは複数のセンサから受信したデータを含むことができる。１つまたは複数のセンサは、全地球測位システム（ＧＰＳ）受信器、加速度計、磁力計、ジャイロスコープ、マイクロフォン、コンパス、および／または気圧計などのセンサを含むことができる。エアバッグ作動データは、ユーザインターフェースを介してユーザ入力から受信されてもよい。代替的または追加的に、エアバッグ作動データは、車両センサなどの１つまたは複数の外部センサから受信されてもよい。図８に示すように、センサデータに加えてエアバッグ作動データをＴＬＥ予測モデルに提供することにより、曲線８０４と比較して曲線８０８のリコール値におけるより高い精度によって実証されるように、約５％のリコールから７０％のリコールまでの精度の向上がもたらされる。さらに、曲線８０８は、運転センサからの出力およびエアバッグ作動データを使用して、ＴＬＥモデルが５０％のリコールで８８％の精度を達成することができることを示している。
【0110】
[0119]同様に、曲線８０２を生成するために使用されるＴＬＥモデルによって使用されるデータに加えて、一点鎖線で表される曲線８１０は、エアバッグ検出データによって車両データを補完する。車両データは、車両固有情報に対応する１つまたは複数のデータタイプを含むことができる。車両データのデータタイプの例には、製造元、モデル、製造年、トリムパッケージ（例えば、品質および特徴）、過去の事故履歴、車両識別番号、車両に対する過去の保険請求、車両メンテナンス記録、それらの組み合わせなどが含まれるが、これらに限定されない。エアバッグ作動データは、ユーザインターフェースを介してユーザ入力から受信されてもよい。代替的または追加的に、エアバッグ作動データは、車両センサなどの１つまたは複数の外部センサから受信されてもよい。図８に示すように、車両データに加えてエアバッグ作動データをＴＬＥ予測モデルに提供することにより、曲線８０２と比較して曲線８１０のリコール値の精度が高いことによって示されるように、約１０％のリコールから９２％のリコールまでの精度の向上がもたらされる。さらに、曲線８１０は、車両データおよびエアバッグ作動データを使用して、ＴＬＥモデルが５５％のリコールで８８％の精度を達成することができることを示している。
【0111】
[0120]最後に、太い破線で表されている曲線８１２は、センサデータ、車両データ、およびエアバッグ作動データの組み合わせを使用してＴＬＥ予測モデルによって生成された総損失予測の精度を示している。センサデータは、モバイルデバイス１０４などのモバイルデバイスの１つまたは複数のセンサから受信したデータを含むことができる。１つまたは複数のセンサは、全地球測位システム（ＧＰＳ）受信器、加速度計、磁力計、ジャイロスコープ、マイクロフォン、コンパス、および／または気圧計などのセンサを含むことができる。車両データは、車両固有情報に対応する１つまたは複数のデータタイプを含むことができる。車両データのデータタイプの例には、製造元、モデル、製造年、トリムパッケージ（例えば、品質および特徴）、過去の事故履歴、車両識別番号、車両に対する過去の保険請求、車両メンテナンス記録、それらの組み合わせなどが含まれるが、これらに限定されない。エアバッグ作動データは、ユーザインターフェースを介してユーザ入力から受信されてもよい。代替的または追加的に、エアバッグ作動データは、車両センサなどの１つまたは複数の外部センサから受信されてもよい。図８に示すように、センサデータ、車両データ、およびエアバッグ作動データの組み合わせをＴＬＥ予測モデルに提供することにより、曲線８０８および曲線８１０と比較して曲線８１２のこれらのリコール値におけるより高い精度によって実証されるように、約５２％のリコールから９２％のリコールまでの精度の向上がもたらされる。さらに、曲線８１２は、センサデータ、車両データ、およびエアバッグ作動データを使用して、ＴＬＥモデルが５５％のリコールで９２％の精度を達成することができることを示している。
【0112】
[0121]図９は、いくつかの実施形態による、確認されたクラッシュの総損失イベントを予測するための結果データの表９００である。表９００は、図８に示す結果の別の図である。列９０２は、予測総損失イベントのためにＴＬＥ予測モジュールによって使用される予測モデルを表す。列９０４は、予測モデルに提供される特定のデータを示す。列９０６は、リコール値における精度の尺度として予測モデルの性能を示す。本明細書で使用される場合、「精度」は、検索されたインスタンス（例えば、真陽性）の中の関連するインスタンス（例えば、車両クラッシュ）の割合である。本明細書で使用される場合、「リコール」は、（例えば、完全性の尺度）実際に検索された関連インスタンスの総量の割合である。入力データは、センサデータ、車両データ、および／またはエアバッグ作動データ、ならびにそれらの任意の組み合わせを含むことができる。
【0113】
[0122]図９は、総損失イベントが発生したという総損失信頼度を予測するときに、車両クラッシュに関する特定のデータセットが様々な精度の結果を提供することができることを表形式で示す。例えば、行９１０は、車両データのみのＴＬＥ予測モデルへの入力が与えられたＴＬＥ予測モデルを使用して生成された総損失予測の精度を示している。総損失モジュール２０１は、車両データをＴＬＥ予測モデルに提供することができる。車両データは、車両固有情報に対応する１つまたは複数のデータタイプを含むことができる。車両データのデータタイプの例には、製造元、モデル、製造年、トリムパッケージ（例えば、品質および特徴）、過去の事故履歴、車両識別番号、車両に対する過去の保険請求、車両メンテナンス記録、それらの組み合わせなどが含まれるが、これらに限定されない。図９に示すように、行９１０は、車両データのみを入力として使用して、ＴＬＥモデルが５０％のリコールで６３％の精度を達成することができることを示している。
【0114】
[0123]別の例として、行９１２は、センサデータのみのＴＬＥ予測モデルへの入力が与えられたＴＬＥ予測モデルを使用して生成された総損失予測の精度を示す。センサデータは、モバイルデバイス１０４などのモバイルデバイスの１つまたは複数のセンサから受信したデータを含むことができる。１つまたは複数のセンサは、全地球測位システム（ＧＰＳ）受信器、加速度計、磁力計、ジャイロスコープ、マイクロフォン、コンパス、および／または気圧計などのセンサを含むことができる。図９に示すように、行９１２は、車両データのみではなく、運転センサからの出力のみを使用して、ＴＬＥモデルが５０％のリコールで約７０％の精度を達成できることを示している。
【0115】
[0124]行９１４は、センサデータと車両データとの組み合わせを使用してＴＬＥ予測モデルを使用して生成された総損失予測の精度を示している。センサデータは、モバイルデバイス１０４などのモバイルデバイスの１つまたは複数のセンサから受信したデータを含むことができる。１つまたは複数のセンサは、全地球測位システム（ＧＰＳ）受信器、加速度計、磁力計、ジャイロスコープ、マイクロフォン、コンパス、および／または気圧計などのセンサを含むことができる。車両データは、車両固有情報に対応する１つまたは複数のデータタイプを含むことができる。車両データのデータタイプの例には、製造元、モデル、製造年、トリムパッケージ（例えば、品質および特徴）、過去の事故履歴、車両識別番号、車両に対する過去の保険請求、車両メンテナンス記録、それらの組み合わせなどが含まれるが、これらに限定されない。図９に示すように、行９１４は、運転センサからの出力、車両の製造元、モデル、および年式からの出力を使用して、ＴＬＥモデルが５０％のリコールで８０％の精度を達成できることを示している。
【0116】
[0125]行９１２で使用されているＴＬＥモデルによって使用されるデータに加えて、行９１６は、エアバッグ検出データでセンサデータを補足する。センサデータは、モバイルデバイス１０４などのモバイルデバイスの１つまたは複数のセンサから受信したデータを含むことができる。１つまたは複数のセンサは、全地球測位システム（ＧＰＳ）受信器、加速度計、磁力計、ジャイロスコープ、マイクロフォン、コンパス、および／または気圧計などのセンサを含むことができる。エアバッグ作動データは、ユーザインターフェースを介してユーザ入力から受信されてもよい。代替的または追加的に、エアバッグ作動データは、車両センサなどの１つまたは複数の外部センサから受信されてもよい。図９に示すように、行９１６は、運転センサからの出力およびエアバッグ作動データを使用して、ＴＬＥモデルが、５０％のリコールで、行９１２と比較して８８％の精度向上を達成することができることを示している。
【0117】
[0126]同様に、行９１０を生成するために使用されるＴＬＥモデルによって使用されるデータに加えて、細い一点鎖線によって表される行９１８は、エアバッグ検出データによって車両データを補足する。車両データは、車両固有情報に対応する１つまたは複数のデータタイプを含むことができる。車両データのデータタイプの例には、製造元、モデル、製造年、トリムパッケージ（例えば、品質および特徴）、過去の事故履歴、車両識別番号、車両に対する過去の保険請求、車両メンテナンス記録、それらの組み合わせなどが含まれるが、これらに限定されない。エアバッグ作動データは、ユーザインターフェースを介してユーザ入力から受信されてもよい。代替的または追加的に、エアバッグ作動データは、車両センサなどの１つまたは複数の外部センサから受信されてもよい。図９に示すように、行９１８は、車両データおよびエアバッグ作動データを使用して、ＴＬＥモデルが、５５％のリコールで、行９１０と比較して８８％の精度向上を達成することができることを示している。
【0118】
[0127]最後に、行９２０は、センサデータ、車両データ、およびエアバッグ作動データの組み合わせを使用してＴＬＥ予測モデルによって生成された総損失予測の精度を示している。センサデータは、モバイルデバイス１０４などのモバイルデバイスの１つまたは複数のセンサから受信したデータを含むことができる。１つまたは複数のセンサは、全地球測位システム（ＧＰＳ）受信器、加速度計、磁力計、ジャイロスコープ、マイクロフォン、コンパス、および／または気圧計などのセンサを含むことができる。車両データは、車両固有情報に対応する１つまたは複数のデータタイプを含むことができる。車両データのデータタイプの例には、製造元、モデル、製造年、トリムパッケージ（例えば、品質および特徴）、過去の事故履歴、車両識別番号、車両に対する過去の保険請求、車両メンテナンス記録、それらの組み合わせなどが含まれるが、これらに限定されない。エアバッグ作動データは、ユーザインターフェースを介してユーザ入力から受信されてもよい。代替的または追加的に、エアバッグ作動データは、車両センサなどの１つまたは複数の外部センサから受信されてもよい。図９に示すように、さらに、行９２０は、センサデータ、車両データ、およびエアバッグ作動データを使用して、ＴＬＥモデルが、５５％のリコールで、行９１６および行９１８と比較して９２％の精度向上を達成することができることを示している。
【0119】
[0128]図９は特定のグループの入力セットを示しているが、他の機械学習モデルは、利用可能にされた車両クラッシュに関する他のデータに基づいて、総損失予測に追加のデータタイプを使用するように訓練することができる。例えば、図９には示されていないが、ステアリングホイール位置、ヘッドライト設定、ウインドシールドワイパー設定、ブレーキペダル位置などの車両の訓練動作パラメータを使用して、追加のモデルを訓練して、総損失イベントが発生したことの追加の信頼度を提供することができる。
【0120】
[0129]図１０は、いくつかの実施形態による、総損失イベントの信頼度を予測するためのシステム１０００のブロック図である。システム１０００は、電子デバイス１００４を含んでもよく、これは、モバイルデバイス１０４内に（例えば、専用のハードウェアまたはソフトウェアとして）組み込まれてもよく、またはモバイルデバイス１０４と通信する別個のデバイスであってもよい（または別個のデバイス上で実行されてもよい）。例えば、別個のデバイスとして、電子デバイス１００４は、モバイルデバイス（例えば、図１のモバイルデバイス１０４、同様のタイプのモバイルデバイス、異なるタイプのモバイルデバイスなど）、サーバ、デスクトップもしくはラップトップコンピュータなどのコンピューティングデバイス、専用処理デバイス（例えば、１つまたは複数の特定用途向け集積回路、フィールド・プログラマブル・ゲートアレイなど）、分散処理システム（例えば、そのようなクラウド環境など）、またはそれらの組み合わせ（例えば、分散プロセスとして）などであってもよい。いくつかの実施形態では、電子デバイス１００４は、限定はしないが、ベクトル解析器１００８、ベクトル決定器１０１２、外部情報受信器１０１６、ＴＬＥ予測モデル２１０（例えば、機械学習モデル）、クラッシュ予測エンジン１０２４、運転者検出エンジン１０２８、およびアクティビティ検出エンジン１０３２を含む構成要素を使用して機能を提供することができる。各構成要素は、１つまたは複数のプロセッサ（図示せず）およびメモリ（図示せず）を含むことができる。構成要素のメモリに記憶された命令は、構成要素の機能を構成および／または提供するために、構成要素の１つまたは複数のプロセッサによって実行されてもよい。あるいは、電子デバイス１００４（図示せず）の１つまたは複数のプロセッサは、電子デバイス１００４の中央メモリに記憶された、システムに構成要素の機能を提供するように構成する、および／または提供させる命令を実行することができる。電子デバイス１００４はまた、データストレージ１０３６を含むことができる。場合によっては、電子デバイス１００４上で動作する構成要素のうちの１つまたは複数は、モバイルデバイス１０４のメモリ１５２もしくはストレージ１５６に記憶されてもよく、および／またはモバイルデバイス１０４のプロセッサ１４８によって実行されてもよい。
【0121】
[0130]モバイルデバイス１０４（例えば、センサデータブロック１０８のセンサ）の１つまたは複数のセンサは、モバイルデバイスが配置される環境の特性を測定するために使用される。例えば、１つまたは複数のセンサは、モバイルデバイスが車両内に配置されている間および運転中に車両の特性を収集するために使用される。その場合、１つまたは複数のセンサは、運転者が車両を操作しているときに対応する期間に、モバイルデバイスが運転者に近接して配置されている間に操作されてもよい。本明細書で使用される場合、「運転」および「走行」という用語は、ある期間にわたる車両の動作を指す。１つまたは複数のセンサから得られた測定値を解析して、車両の加速度ベクトル、ならびに駆動装置の異なる特徴を決定することができる。場合によっては、外部データ（例えば、天候、交通、車両情報、運転者情報など）を検索し、収集された運転データと関連付けることができる。
【0122】
[0131]いくつかの実施形態では、モバイルデバイス（モバイルデバイス１０４など）のディスプレイは、１つまたは複数のセンサによって収集されたまたは電子デバイス１００４の構成要素のいずれかによって生成された運転データの表現を示すことができる。例えば、運転データの表現は、収集されたセンサデータ（例えば、センサデータブロック１０８を使用して収集された運転データ）を、モバイルデバイス１０４のユーザのアクティビティの推定値（例えば、静止、歩行、走行、運転など）、データが収集された運転中の種々の運転イベントの発生の推定値、運転中の運転者の運転行動を記述するメトリック、すべての運転について運転者の運転行動全体を記述するメトリック、特定のイベントの発生に関連する運転者の行動を記述するメトリック、および／または変換された運転データと地理的データの組み合わせを含むが、これらに限定されない種々の結果に変換することによって生成され得る。
【0123】
[0132]場合によっては、収集された運転データを解析して、異なる基準に基づいて、運転、複数の運転、運転者、および／または運転行動にスコアを割り当てることができる。スコアリングエンジン（図示せず）は、１つまたは複数のセンサによって収集されたデータを集約し、１つまたは複数の規則を適用して実施形態のスコアを生成することができる。
【0124】
[0133]センサデータ（例えば、センサデータブロック１０８を使用して収集される）を使用して、モバイルデバイスの動きを解析し、運転イベントの発生を検出することができる。センサデータは、電子デバイス１００４によって集約され、所定量のセンサデータが受信されると解析されてもよい。例えば、電子デバイス１００４が５０メガバイトのセンサデータを集約すると、電子デバイス１００４は、センサデータの解析を開始することができる。別の例では、電子デバイス１００４が所定の期間（例えば、３０分のセンサデータ、１時間のセンサデータなど）にわたって収集されたセンサデータを受信すると、電子デバイス１００４はセンサデータの解析を開始することができる。さらに別の例では、電子デバイス１００４は、ドライブに関連するセンサデータを集約し、走行に関連するセンサデータのすべてが受信されると、センサデータを解析する。あるいは、モバイルデバイス１０４は、電子デバイス１００４の１つまたは複数の構成要素を含み、リアルタイムで（例えば、１つまたは複数のセンサが測定値を取得すると）センサデータの解析を提供する。
【0125】
[0134]ＧＰＳ受信器は、モバイルデバイス上で実行される様々なアプリケーションによって使用され得るタイムスタンプされた位置および速さデータを提供することができる。タイムスタンプされたデータは、車両の位置および速さを正確に決定するために使用することができる。ＧＰＳ受信器は、クラッシュを検出し、車両が移動した距離を決定することができる。例えば、ＧＰＳ受信器は、速さまたは位置の突然の変化を検出することによってクラッシュを検出することができる。しかしながら、モバイルデバイスは、電力および処理の制約に起因して、かつＧＰＳ受信器を動作させる高い電力消費に起因して、限られたリソースで動作するため、電子デバイス１００４は、車両の位置および／または速さを検出するためにモバイルデバイス１０４の１つまたは複数の他のセンサを使用してもよい。
【0126】
[0135]例えば、車両内に配置されたモバイルデバイスは、車両のアクティビティに関連する機械的振動を受ける。これらの振動は、慣性測定ユニット（ＩＭＵ）と呼ばれるモバイルデバイス１０４のセンサデータブロック１０８内のセンサのサブセットを使用して測定可能である。機械的振動の測定は、車両アクティビティまたは場合によってはユーザのアクティビティを識別するために使用することができる様々な振幅および周波数で行うことができる。例えば、加速度計、ジャイロスコープ、および磁力計の測定値の一部または全部は、ユーザの歩行パターンを車両の運転パターン（例えば、約５ｍ／ｓの車速）と区別することができる。
【0127】
[0136]ＩＭＵは、加速度計１１６、ジャイロスコープ１２４、および磁力計１２０のいずれかを含むことができる。ＩＭＵおよび内部に含まれるセンサは、ＧＰＳ受信器とは別個のユニットであってもよい。加速度計１１６は、縦方向および横方向の加速度ならびに重力による加速度を測定するように動作可能な３軸加速度計であってもよい。ジャイロスコープ１２４および磁力計１２０はまた、３軸デバイスであってもよく、３次元で角回転および磁気方位をそれぞれ測定することができる。ＩＭＵは、３次元加速度計データを３次元ジャイロスコープデータと組み合わせて、６自由度（例えば、並進および回転）を有するモバイルデバイスの動きを識別することができる。
【0128】
[0137]車両内に配置されたモバイルデバイスによる運転中、モバイルデバイスのＩＭＵを使用して、加速度計、ジャイロスコープ、および磁力計のいずれかからの運動測定値、ならびにクラッシュ予測エンジン１０２４がクラッシュを予測するための入力を生成するための運動測定値を取得することができる。場合によっては、加速度測定値は、ＴＬＥ予測モデル２１０によって使用されてもよく、加速度の著しい変化（例えば、典型的な駆動または制動イベントからの逸脱）を含んでもよい。
【0129】
[0138]ＩＭＵセンサからの移動測定信号は、デジタル信号を取得するために特定のサンプリングレートでサンプリングされてもよい。場合によっては、動き測定信号に９Ｈｚのサンプリングレートを使用することができる。他の例では、動き測定信号に３０Ｈｚのサンプリングレートを使用することができる。他のサンプリングレート、例えば５０Ｈｚまたは他のサンプリングレートが使用されてもよい。より高いサンプリングレートは、リソース消費量の増加（例えば、処理および／または電力リソース）を犠牲にして、速さ推定を改善することができる。電子デバイス１００４および／またはモバイルデバイス１０４は、収集されるデータ量（例えば、データ解析の精度のために）およびリソース消費を最適化するためにリアルタイムでＩＭＵセンササンプリングを変調してもよい。
【0130】
[0139]アクティビティ検出エンジン１０３２は、センサデータブロック１０８の１つまたは複数のセンサから受信したセンサ測定値に対応するアクティビティを検出する。例えば、アクティビティ検出エンジン１０３２は、モバイルデバイス１０４が静止しているとき、歩いているユーザ、走っているユーザ、運転している車両内、飛行している航空機内などを検出する。場合によっては、アクティビティ検出エンジン１０３２は、アクティビティの確率を出力する。それらの例では、アクティビティ検出エンジン１０３２は、モバイルデバイスが歩行している４５％の確率、モバイルデバイスが運転している３３％の確率、および何らかの他のアクティビティの２２％の確率などの複数の確率を出力することができる。確率は、整数もしくは実数、パーセンテージ、グレード（例えば、低、中、または高など）として、または所与のアクティビティの確率を表すように構成された別の機構で表すことができる。
【0131】
[0140]アクティビティ検出エンジン１０３２は、アクティビティを使用して、センサデータから駆動を検出してもよい。例えば、アクティビティ検出エンジン１０３２は、モバイルデバイス１０４から受信したデータを解析し、アクティビティが、モバイルデバイス１０４が運転中の車に乗っている可能性が高いことを示す第１の時間を識別することができる。アクティビティ検出エンジン１０３２は、運転が進行中であるという判定に基づいて、総損失モジュールの実行を開始してもよい。次いで、電子デバイス１００４の他の構成要素は、運転中に受信したセンサデータをさらに解析して、運転者の挙動、運転者スコア、クラッシュ検出などを識別することができる。場合によっては、これは、センサデータブロック１０８によるデータ収集を制御するためにモバイルデバイスのオペレーティングシステムによって実行されてもよい。
【0132】
[0141]場合によっては、アクティビティ検出エンジン１０３２は、センサデータブロック１０８からの測定値の収集を制御するためにモバイルデバイス１０４上で動作してもよい。モバイルデバイス１０４は、モバイルデバイス１０４の１つまたは複数のセンサ（例えば、サンプリングレートなど）の動作を制御し、１つまたは複数のセンサから測定値を収集する総損失モジュールを実行することができる。総損失モジュールは、電子デバイス１００４の構成要素のうちの１つまたは複数を含むことができる。モバイルデバイスは限られたリソースで動作するため、総損失モジュールは、モバイルデバイスが運転中に停止しているか停止していない間に中断、バックグラウンドで実行、または終了することができる。アクティビティ検出エンジン１０３２は、運転が発生しているか否かを検出するためにバックグラウンドプロセスで動作してもよい。運転が発生している場合、アクティビティ検出エンジン１０３２は、総損失モジュールを始動させ、運転に関連するセンサデータの収集を開始してもよい。場合によっては、アクティビティ検出エンジン１０３２は、モバイルデバイス１０４の周りにジオフェンスを生成することができる。モバイルデバイス１０４がジオフェンスを横切る場合、アクティビティ検出エンジン１０３２は、総損失モジュールを開始させることができる。例えば、ジオフェンスは、ユーザの家を囲むことができ、ジオフェンスを横切ったとき、ユーザが運転を開始したためである可能性が高い。ジオフェンスは、非アクティビティ期間の後に生成されてもよい。ジオフェンスは、移動体がジオフェンスを横切るときに、歩行などの他のアクティビティではなく、運転の開始に起因する可能性が高いように、移動体から所定の距離だけ生成することができる。限定はしないが、訪問、他の通知、期間、しきい値を超える１つまたは複数のセンサ測定値などの他の検出可能なイベントを使用して、総損失モジュールを開始することができる。
【0133】
[0142]前述したように、アクティビティ検出エンジン１０３２は、モバイルデバイスのオペレーティングシステム（または別のアプリケーション）によって収集されたセンサ測定値を取得し、モバイルデバイスに関連するアクティビティの確率を生成してもよい。あるいは、これはオペレーティングシステム自体によって実行されてもよい。例えば、オペレーティングシステムは、モバイルデバイス１０４が静止している、歩いている、走っている、運転している、飛行しているなどの確率を出力することができる。次いで、アクティビティ検出エンジン１０３２は、運転アクティビティに関連するイベント中にオペレーティングシステムによって収集されたセンサデータを要求することができる。オペレーティングシステムによって収集されたセンサデータは、総損失モジュールによって（例えば、運転センサ２０２を使用して）収集された任意のセンサデータに追加することができる。
【0134】
[0143]例えば、アクティビティ検出エンジン１０３２は、モバイルデバイス１０４がジオフェンスを横切ったことを検出し、ＩＭＵセンサなどのセンサ測定値の収集を開始するために総損失モジュールの実行を開始する。次いで、総損失モジュールは、モバイルデバイスがジオフェンスを横断する前の期間に、オペレーティングシステムからセンサデータを要求する。これにより、モバイルデバイス１０４は、総損失モジュールが運転中に数分にわたってセンサ測定値の収集を実行および開始しているにもかかわらず、運転の全期間にわたってセンサ測定値を取り込むことができる。
【0135】
[0144]別の例では、総損失モジュールが実行されると、総損失モジュールの実行前の期間にわたってモバイルデバイス１０４のオペレーティングシステムから要求する。最初の実行の直後に、総損失モジュールは、運転センサから駆動が進行中であることを識別する。次いで、総損失モジュールは、総損失モジュールの実行に先行してモバイルデバイス１０４の動作によって収集されたセンサデータを要求する。場合によっては、駆動が開始されてからオペレーティングシステムが運転アクティビティが発生していることを検出するまでの間に遅延があり得る。
【0136】
[0145]以下の説明では、実施形態の完全な理解を提供するために特定の詳細が与えられる。しかしながら、当業者であれば、これらの具体的な詳細なしで実施形態を実施できることを理解するであろう。例えば、回路、システム、ネットワーク、プロセス、および他の構成要素は、不必要な詳細で実施形態を不明瞭にしないために、ブロック図形式の構成要素として示すことができる。他の例では、実施形態を不明瞭にすることを避けるために、周知の回路、プロセス、アルゴリズム、構造、および技術を不必要な詳細なしに示すことができる。
【0137】
[0146]また、個々の実施形態は、フローチャート、フロー図、データフロー図、構造図、またはブロック図として示されるプロセスとして説明され得ることに留意されたい。フローチャートは、動作を逐次的なプロセスとして記述することができるが、動作の多くは並列にまたは同時に実行することができる。さらに、動作の順序は再配置されてもよい。プロセスは、その動作が完了した時点で終了するが、図面には含まれていない追加のステップが含まれてもよい。プロセスは、方法、関数、手順、サブルーチン、サブプログラムなどに対応することができる。プロセスが関数に対応する場合、その終了は、呼び出し関数またはメイン関数への関数の戻りに対応することができる。
【0138】
[0147]上述した技術、ブロック、ステップ、および手段の実装は、様々な方法で行うことができる。例えば、これらの技法、ブロック、ステップ、および手段は、ハードウェア、ソフトウェア、またはそれらの組み合わせで実装することができる。ハードウェア実装の場合、処理ユニットは、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）、デジタル信号プロセッサ（ＤＳＰ）、デジタル信号処理デバイス（ＤＳＰＤ）、プログラマブル・ロジック・デバイス（ＰＬＤ）、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）、マスク・プログラマブル・ゲートアレイ（ＭＰＧＡ）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサ、上述の機能を実行するように設計された他の電子ユニット、および／またはそれらの組み合わせのうちに実装されてもよい。
【0139】
[0148]また、実施形態および／または例は、フローチャート、フロー図、スイム図、データフロー図、構造図、またはブロック図として示されるプロセスとして説明され得ることに留意されたい。描写は、動作を連続的なプロセスとして説明することができるが、動作の多くは、並行してまたは同時に実行することができる。さらに、動作のうちの１つまたは複数は、図示の順序から外れて実行されてもよい。プロセスは、その動作が完了したとき、または前のステップもしくはブロックに戻ったときに終了することができる。プロセスは、図に含まれていない追加のステップまたはブロックを有することができる。プロセスは、方法、関数、手順、サブルーチン、サブプログラムなどに対応することができる。プロセスが関数に対応する場合、その終了は、呼び出し関数またはメイン関数への関数の戻りに対応する。
【0140】
[0149]さらに、本明細書に記載のデバイスおよび／またはシステムは、ハードウェア、ソフトウェア、スクリプト言語、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、および／またはそれらの任意の組み合わせによって実装されてもよい。ソフトウェア、ファームウェア、ミドルウェア、スクリプト言語、および／またはマイクロコードで実装される場合、必要なタスクを実行するためのプログラムコードまたはコードセグメントは、記憶媒体などの非一時的コンピュータ可読媒体に記憶されてもよい。コードセグメントまたは機械実行可能命令は、設計通りに動作するようにシステムを構成する、手順、関数、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェアパッケージ、スクリプト、クラス、または命令、データ構造、および／またはプログラム文の任意の組み合わせを表すことができる。コードセグメントは、情報、データ、引数、パラメータ、および／またはメモリ内容を渡しおよび／または受け取ることによって、別のコードセグメントまたはハードウェア回路に結合することができる。情報、引数、パラメータ、データなどは、メモリ共有、メッセージ渡し、トークン渡し、ネットワーク送信などの任意の適切な手段により、渡され、転送され、または送信されてもよい。
【0141】
[0150]ファームウェアおよび／またはソフトウェア実装の場合、方法論は、本明細書に記載の機能を実行するモジュール（例えば、手順、機能など）で実装されてもよい。命令を実体的に具現化する任意の非一時的なコンピュータ可読媒体が、本明細書に記載の方法を実施する際に使用されてもよい。例えば、ソフトウェアコードは、メモリに記憶され、後に命令の実行時にシステムを構成するために使用されてもよい。メモリは、プロセッサ内またはプロセッサの外部に実装されてもよい。本明細書で使用される場合、「メモリ」という用語は、任意のタイプの揮発性、不揮発性、または他の記憶媒体を指し、任意の特定のタイプのメモリまたはメモリの数、またはメモリが記憶される媒体のタイプに限定されるものではない。
【0142】
[0151]さらに、本明細書で開示されるように、「記憶媒体」という用語は、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ＲＡＭ、キャッシュメモリ、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイス、および／または情報を記憶するための他の機械可読媒体を含む、データを記憶するための１つまたは複数のメモリを表すことができる。「コンピュータ可読媒体」という用語は、命令および／またはデータを含むまたは搬送する、携帯型もしくは固定型記憶装置、光記憶装置、および／または記憶することができる様々な他の記憶媒体を含むが、これらに限定されない。
【0143】
[0152]本開示の原理は、特定の装置および方法に関連して上述されているが、この説明は、例としてのみ行われ、本開示の範囲に対する限定としてではないことを明確に理解されたい。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【国際調査報告】