JP2017168097A - 状況に特有の車両ドライバとの交信を提供するためのシステムおよび方法 - Google Patents

Abstract

【課題】ドライバが眠そうである際に考慮するよう、ドライバの注意力のレベルを測定して注意力のレベルを向上させる。
【解決手段】ドライバの状況に基づいてドライバと交信することは、ドライバに警告し続けるのに役立つ。状況は、興味を含むドライバの特徴を判定すること、車両に含まれるセンサを使用してドライバの状態、車両の状態およびドライバの現在の位置に関する情報など、ドライバの周囲の環境を監視することにより、判定される。ドライバの興味の情報が取得され、ドライバの状況に基づいてドライバへ推奨可能な動作を生成するために使用される。動作はドライバに警告し続けるために使用される。
【選択図】図２

Description

本出願は、一般的に車両の安全に関し、より具体的には、状況に特有の車両ドライバとの交信を提供するためのシステムおよび方法に関する。

注意深いドライバは、安全な道路のための必須条件である。残念ながら、不十分な睡眠時間、長い労働時間、および、長い通勤時間など、現代生活の絶えず続く要求により、多くの人々は、疲労が大きく道路に集中できない際にも運転をしており、疲労状態にあるにもかかわらず、道路から離れる選択肢を有さない。その結果として、米国における１つの世論調査では、成人ドライバの６０％が眠気を感じながら運転したことがあり、３分の１を超える人々が、実際に過去に運転しながら眠ってしまったことがあると推定している。そのようなドライバは、道路条件、他の車両、および、道路上の歩行者に対する反応が間に合わない可能性があり、致命的となり得る交通事故を起こすリスクが高まる。そのようなリスクは、ドライバが運転中に完全に眠ってしまった場合、さらに増大する。一貫して、国家道路交通局（Ｎａｔｉｏｎａｌ Ｈｉｇｈｗａｙ Ｔｒａｆｆｉｃ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ）は、保守的に見積もって、米国における少なくとも１００，０００件の警察に報告された追突がドライバの疲労によるものであり、結果的に、推定１，５５０件の死亡を引き起こしたとしている。

疲労に関連する追突を防ごうとする複数の技術が存在するが、理想的なものはない。例えば、Ｎａｄ−Ｚａｐｐｅｒ（商標）Ａｎｔｉ−Ｓｌｅｅｐ Ａｌａｒｍは、ドライバの頭が特定の速度で前方に傾いた際にアラームを鳴らしてドライバを起こす、ドライバの耳の後ろに装着可能な動作検出器を含む。しかしながら、アラームは、ドライバが眠ってしまい車両の制御ができなくなるリスクが生じた後にのみ起動するため、眠りに落ちるドライバが危険な状態に陥るのを防げない。さらに、次に眠ってしまうまで、アラームは、ドライバの目を覚ましておくための策を何も講じない。

同様に、ミシガン州ディアボーンのＦｏｒｄ（登録商標）Ｍｏｔｏｒ Ｃｏｍｐａｎｙにより生産されるドライバ警告システムなど、他のシステムは、車両の側方位置、ハンドルの角度、および、速度の変動を評価して、ドライバが車両を制御できていないか判定する。しかしながら、そのような技術は、車が直線道路上にある間のマイクロスリープ、数秒間のみ続く睡眠を検出せず、事故が起こる前にドライバの目を覚まさせようとしない可能性がある。さらに、そのようなシステムは、ドライバが実際に車両を制御できなくなる前に、道路上に止まる必要があるドライバの目を覚ましておこうとしない。

同様に、スウェーデンのヨーテボリにあるＶｏｌｖｏ（登録商標）Ｇｒｏｕｐにより調査されたシステムなど、他のシステムは、車両内のカメラを使用してドライバの視覚的な分析を行い、画像を処理してドライバの顔における眠気の兆候を検出する。眠気の兆候を検出すると、そのようなシステムは、ドライバが休息のために十分な休憩をとるという想定のもとに、ドライバが眠そうであるという警告をドライバに提供する。そのようなシステムは、ドライバの注意力を直接的に向上させるものではなく、特定の状態においてはドライバが休息をとれない可能性があるため、そのようなシステムの警告はドライバに無視される可能性がある。

したがって、ドライバが眠そうである際に考慮するよう、ドライバの注意力のレベルを測定して注意力のレベルを向上させる手法が必要である。

ドライバの状況に基づいてドライバと交信することは、ドライバに警告し続けるのに役立ち得る。状況は、ドライバの興味を含むドライバの特徴を判定することにより、および、車両に含まれるセンサを使用してドライバの状態、車両の状態、および、ドライバの現在の場所に関する情報など、ドライバの周囲環境を監視することにより、判定され得る。特徴および監視された環境は、ドライバの状況を規定する。ドライバに対する興味の情報が取得され、ドライバの状況に基づいてドライバへ推奨可能である動作を生成するために使用される。動作は、ドライバに警告し続けるために使用される。

１つの実施形態において、状況に特有の動作を車両のドライバへ向けて行うためのシステムおよび方法が開示される。車両のドライバの状況は、以下を含んで判定される：ドライバの状態を判定すること；車両の状態を判定すること；および、ドライバの１つ以上の特徴を判定すること。１つ以上の動作が、システムによりドライバに対して状況に基づいて行われるよう推奨される。推奨動作のうちの１つ以上が、行われる。

さらに、本発明の他の実施形態が、本発明を実行するために検討される最良の様式を図示する目的で本発明の実施形態が記載される、以下の詳細な説明から当業者に容易に明らかになるであろう。理解されるように、本発明は、他の実施形態および異なる実施形態が可能であり、いくつかの詳細は、全てが本発明の精神および範囲から逸脱することなく、様々な明確な態様において修正可能である。したがって、図および詳細な説明は、本質的に図示であると見なされ、制限とは見なされない。

図１は、１つの実施形態による、状況に特有の動作を車両のドライバへ向けて行うためのシステムを示すブロック図である。 図２は、１つの実施形態による、状況に特有の動作を車両のドライバへ向けて行うための方法を示すフロー図である。 図３は、１つの実施形態による、図２の方法において使用するドライバの状況を判定するためのルーチンを示すフロー図である。 図４は、１つの実施形態による、図３のルーチンにおいて使用するドライバの状態を監視するためのルーチンを示すフロー図である。 図５は、１つの実施形態による、図４のルーチンにおいて使用する細かい凝視の予測を行うためのルーチンを示すフロー図である。 図６は、１つの実施形態による、図２の方法において使用するドライバの特徴を判定するためのルーチンを示すフロー図である。 図７は、１つの実施形態による、図２の方法において使用するドライバに対して行うべき動作を推奨するためのルーチンを示すフロー図である。

ドライバの注意力は、および、その結果として道路上の安全は、ドライバの現状に基づくようドライバとの交信をカスタマイズすることにより、向上し得る。図１は、１つの実施形態による、状況に特有の動作を車両のドライバへ向けて行うためのシステム１０を示すブロック図である。システム１０は、車両１５のドライバ１４の状態１３を監視する役割を果たす検知／視覚モジュール１２を実行する１つ以上のサーバ１１を含む。ドライバの状態は、ドライバが注意を傾けているか、または、眠そうかを表し得るが、他の種類の状態も可能である。例えば、さらなる実施形態において、ドライバの状態１３は、ドライバの感情を含み得る。検知／視覚モジュール１２は、状態を監視するために車両１５の内部の１つ以上のセンサと交信する。センサは、ドライバを監視する少なくとも１つのドライバと直面するデジタルカメラ１６を含む。カメラ１６は、可視光画像を記録するカメラ１６であり得る。代替的に、カメラ１６は、さらに、赤外線カメラ１６であってよい。他の種類のカメラも可能である。加えて、他のセンサがユーザを監視していてよい。例えば、生体センサは、スマートウォッチ１７に組み込まれるなど、ドライバに装着されることができ、ドライバ１４の生理学的データを検知し得る。したがって、センサは、ドライバの光電脈波（「ＰＰＧ波」）を記録し得るスマートウォッチ１７内に組み込まれるパルスオキシメータであり得る。さらに、他の種類のセンサが可能である。

さらに、サーバ１１は、ドライバの状況、特定の時間にドライバと関連付けられる環境のセットを判定する状況モジュール１８を実行する。状況は、状況モジュール１８に保存され、追加的にバックアップ保存媒体２０に保存され得る、状況グラフ１９に表される。状況グラフ１９は、意味グラフ１９である（状況グラフ１９は、以降、以下の記載において「意味グラフ１９」と称される）。ドライバ１４の状態に加えて、意味グラフ１９は、車両の速度または車両のエンジンの毎分反復など、車両１５の状態２１、車の前方の任意の物体、車両１５が運行している道路の状態、および、車両が道路のレーンに対する位置を維持しているか（車両内のセンサを使用して判定され得る）を反映するが、さらに、他の種類の車両の状態情報も可能である。加えて、ストレージ２０は、特定の都市または国など、ドライバの位置に関する空間データ２２を含み得るが、他の種類の地理的な位置も可能である。空間データ２２は、レストラン、店舗、および、位置において興味のある他の地点を含み得る。空間データ２２は、状況モジュール１８により、インターネットまたはセルラーネットワークなど、インターネットワーク２３を介してアクセス可能な１つ以上のウェブページ２１から取得され得る。状況モジュール１８は、車両に内蔵されるＧＰＳ受信器を使用して取得され、インターネットワーク２３と接続し得る車両１５に内蔵される無線送受信器を介して送信され得る、車両の現在位置を受信することができ、ドライバの位置に近い興味のある地点を特定できる。状況モジュール１８は、意味グラフ１９に興味のある地点を含み得る。

さらなる実施形態において、カメラまたは他のセンサなど、車両１５のセンサは、以下のいずれに該当するかなど、ドライバの負荷（図示せず）を測定し得る：負荷が高く、ドライバは運転に集中する必要があり、注意散漫であるべきではない；通常の負荷であり、一部のドライバは運転に注意を傾ける必要があり、会話のための追加的な負荷が許可される；または、負荷は低く、ドライバは停車しているか、または、信号でアイドリングしている。負荷は、瞬きの頻度（以下に記載されるように判定され得る）を評価することにより、衝動性運動を測定することにより、または、瞳孔拡張を測定することにより、測定され得るが、ドライバの負荷を評価する他の手法も可能である。センサからのデータは、無線送受信器によりセンサへ送信されてよく、意味グラフ１９内に組み込まれ得る。意味グラフ１９は、２０１５年１２月８日に発行された、Ｒｏｂｅｒｔｓ等の同一出願人による米国特許第９，２０８，４３９号に記載されるように、ドライバの状態１３、車両の状態２１、位置情報２２、および、他の情報から生成され得る。意味グラフ１９を作成するための他の手法も可能である。

さらに、サーバ１１は、ドライバに関する情報を収集して、収集された情報に基づいて、ドライバの現在および過去の興味など、ドライバの特徴を学習する、個人データモジュール２４を実行するが、ドライバの他の特徴も可能である。特徴は、さらに図５と関連して以下に記載されるように、ドライバの提示されたプロファイル２５である。簡潔に言えば、個人データモジュールは、２３個のデータ項目を、サーバ１１によりインターネットワーク２３を介して取り込まれ得る、ドライバと関連付けられるウェブコンテンツ２６から抽出する。ウェブコンテンツ２６は、ドライバによる、または、ドライバのソーシャルネットワーク接続による、ソーシャルネットワーキング投稿などの情報フィード、ドライバが承認するＲＳＳフィード、１つ以上のサーバ２７上に保持されるドライバのソーシャルネットワークプロファイルを含み得るが、他の種類のウェブコンテンツ２６も可能である。

抽出データ項目は、個人データモジュール２４により、トピックの階層２８（異なるカテゴリにグループ化されるトピックを含み得る）と比較され、ストレージ２０に保存され得るが、他の種類の比較も可能である。比較に基づいて、各データ項目と関連付けられる階層２８におけるトピックが特定される。特定されたトピックに基づいて、データ項目は、統一されたパラメータ空間に分類され得る。特に、１つの実施形態において、表現ベクトルが、特定されたトピックからデータ項目ごとに生成され得る。そのようなベクトルは、階層的なトピックに関して文書の分類を示し、データ項目のコンテンツに特有の高次元ベクトル空間における地点を定義する。ベクトルは、データ項目の経年に基づいて重み付けされてよく、より最近のデータ項目に対するベクトルが、より多く重み付けされる。重み付けベクトルは、ドライバの現在および過去の興味を示す描写ベクトルにおいてドライバのプロファイル２５として機能する単一のベクトルに組み合わされる。ベクトルにおける領域は、階層２８に含まれるトピックと関連する数値に対応する。さらなる実施形態において、個人データモジュール２４は、複数のユーザと関連付けられるベクトルを組み合わせて母集団事前分布２９を形成し得る。

事前分布２９は、クラスタリングおよび教師なし学習などの技術を介して作成され得るが、さらに、他の技術も可能である。例えば、事前分布２９は、類似性に基づいてプロファイル２５を組み合わせるよう推奨するために使用され得る、協調フィルタリング規則を介して構築され得る。同様に、母集団事前分布は、ドライバの年齢、および、プロファイル２５における他のデータなど、ドライバ１３と関連付けられる他の情報に基づいて構築されてよい。さらに、母集団事前分布を作成するための他の手法が可能である。特定のドライバのプロファイル２５に最も近い母集団事前分布が、さらに以下に記載されるように、動作を推奨するためにドライバのプロファイル２５の代わりに使用され得る。

意味グラフ１９およびドライバ１４のプロファイル２５（または、最も近い事前分布）は、サーバ１１により実行されるレコメンダ３０により、ドライバの個人的な特徴（ドライバの興味など）、ドライバの状態、車両の状態、位置を全て網羅する、ドライバの現状を表す単一のベクトル空間「現状」ベクトル３１に統合される。さらに、レコメンダ３０は、ドライバ１４に対して取り込まれる可能性がある可能な動作３２のリストへのアクセスを有する。そのような動作は、実行されるドライバ１４との特定の会話パターンおよび他の動作を含み得る。例えば、そのような動作は、以下を含み得る：ドライバ１４のソーシャルネットワーキング接続により行われるソーシャルネットワーキング投稿など、トピックに関してドライバ１４と会話すること；ドライバ１４が、ニュース記事の読み上げで近所の興味のある特定の地点に関して聞きたいか、ドライバ１４に尋ねること。さらに、リスト３２における他の可能な動作が可能である。可能な動作は、実施を推奨され得るパラメータ化された推奨可能な動作３３を生成するために使用される。

推奨可能な動作３３を生成するために、レコメンダ３０は、ドライバと関連付けられる現在の情報を表す最近のデータ項目を、ドライバ１４が接続した最近のソーシャルネットワーク、最近のニュース記事など、ウェブコンテンツ２６から抽出し、抽出されたコンテンツを使用して可能な動作をパラメータ化する。さらに、動作３３は、現状ベクトル３１に基づいて生成される。したがって、例えば、可能な動作３２がドライバと会話することであり、ベクトル３１に示されるドライバの興味が料理を含んでいて、抽出された現在の情報が料理に関するソーシャルネットワーキング投稿を含む場合、生成される動作は、抽出されたソーシャルネットワーキング投稿に関する会話となり得る。

生成される推奨可能な動作の各々は、高次元ベクトル空間において動作を示す特徴ベクトルにより表される。ベクトル空間は、トピック２８の階層の表現に対応する。例えば、中国／アジア融合レストランである興味の地点に関して話すことは、「アジア融合料理」および「中華料理」の描写ベクトルにおいて高い値を有するかもしれない。同様に、ユーザが眠そうな際に再生する予定のコンテンツは、「眠気」に対して高い値を有するかもしれない。さらに、そのようなコンテンツが親しい友人による投稿と関連する場合、コンテンツは、さらに、親しくない友人項目に対する０とは対照的に、１に近い「親友」の値を有するかもしれない。

さらに、生成された動作３２の少なくとも一部は、さらに以下に記載されるように、動作が実施される前に満たされなければならない始動条件３４と関連付けられ得る。例えば、ドライバ１４と会話することを含む動作は、ドライバの認知的な負荷が安全に会話するのに十分なほど低くなることにより始動されるまで、実施されなくてよい。同様に、特定の興味がある地点に関して会話することは、興味のある地点が近くなることにより、始動され得る。

レコメンダ３０は、生成された動作の特徴ベクトルを分析して、それらをランク付けする。ランク付けは、複数の手法で行われ得る。例えば、特徴ベクトルは、ドライバのプロファイル２５との近さに基づいて比較され得る。例えば、１つの実施形態において、特徴ベクトルのスロットの値に、ドライバのプロファイル２５であるベクトルにおける対応するスロットの値を乗じ、その後、これらの値を合計して項目に対するスコアを与える。レコメンダ３０は、異なるベクトルのスコアを比較して、推奨可能な動作３３に対するベクトルを比較に基づいてランク付けする。さらなる実施形態において、動作は、動作が以前に行われたかを示す新規性、および、特定の動作がどのくらい最近に行われたかを示す新近性、に基づいて、ランク付けされ得る。さらなる実施形態において、複数の技術を使用する複数のランク付けが、異なって重み付けされ組み合わされる結果を伴って、行われ得る。重みは、機械学習を使用して最適化され得る。

上位２つのスコアベクトルなど、ベクトルが特定のランクである動作３３は、実行のためにレコメンダ３０により推奨される。さらなる実施形態において、さらに、他のランクの他の動作３３が使用されてよい。データ項目の生成および推奨は、２０１５年５月２１日に発行された、Ｒｏｂｅｒｔｓ等の同一出願人による米国特許出願第２０１５／０１４２７８５号に記載されるように、および、２００８年４月５日のＣＨＩ２００８のＢｅｌｏｔｔｉ等による「Ａｃｔｉｖｉｔｙ−ｂａｓｅｄ ｓｅｒｅｎｄｉｐｉｔｏｕｓ ｒｅｃｏｍｍｅｎｄａｔｉｏｎｓ ｗｉｔｈ ｔｈｅ Ｍａｇｉｔｔｉ ｍｏｂｉｌｅ ｌｅｉｓｕｒｅ ｇｕｉｄｅ（マジッティのモバイルレジャーガイドによる活動ベースの予期せぬ推奨）」に記載されるように、行われ得る。

推奨動作３３は、サーバ１１により実装される動作モジュール３５により実施される。動作モジュール３５は、ドライバ１４との自然言語の会話に従事する自然言語コンポーネント３６を含む。会話は、２０１５年１０月１５日に公開された、同一出願人による米国特許出願公開番号第２０１５／０２９３９０４号に記載されるように、行われ得る。レコメンダ３０は、推奨動作３３を、連続するＪＳＯＮオブジェクトの形式など、様々な形式で動作モジュール３５に提供することができ、動作３３の記載に加えて、ドライバ１４の現状１３および動作を実施するのに必要な任意の情報を提供し得る。したがって、提供される情報は、以下を含み得る：関連する従事地点（眠そうなドライバおよび興味のある地点の近くなど）で動作を行うためのトリガ３４；意味グラフ１９から取り込まれるドライバの注意力の状態に関する状況情報（情報がリアルタイムで変化する際に更新される情報を伴う）；ドライバ１４のプロファイル２５からの個人データ；および、ソーシャルネットワーキング更新および推奨動作３３を実施するために使用され得るスポーツおよびエンターテインメントなど、抽出されたウェブコンテンツ２６。動作モジュールは、ドライバの状態１３および他の提供情報を分析して始動条件３４が起こった時期を認識し、生じた始動条件３４と関連付けられる推奨動作を行う。

自然言語コンポーネント３６は、会話の促進および対話作用の両方をサポートし得る。会話の促進は、コンポーネント３６に、ソーシャルネットワーキング投稿を読むこと、または、ゲームをすることなど、事前に規定されたパターンのうちの１つを起動させる。対話作用は、音楽の選択を確認するなど、他のモジュールからの単純な交信を提供する。例えば、ドライバが眠気を感じないでいられるようアップビートの曲が推奨される場合、レコメンダ３０は、ＣｏｎｆｉｒｍＴｕｎｅ（Ｘ）の要求を発行し得る。ここで、Ｘはドライバの現状および既知の好みが与えられた推奨の曲である。要求により、自然言語コンポーネント３６は、ドライバに質問して提案された音楽に対するドライバの認証または否認を提供する。

動作モジュール３５は、車両に配置されるドライバインタフェース３７によりインターネットワーク２３を介してドライバ１４と交信し、推奨動作を行う。１つの実施形態において、ドライバインタフェース３７は、ソフトウェアコンポーネントであってよく、トリップまたはナビゲーションコンピュータ、バックモニタ、および、他のコンポーネントなど、車両１５に組み込まれるオンボードコンピュータシステムを利用し得る。さらなる実施形態において、ドライバインタフェース３７は、独占的にシステム１０の一部であり、他のオンボード車両コンポーネントにより使用されない、ハードウェアコンポーネントを含み得る。ドライバインタフェース３７は、インタフェースが発話を行う際に形状および不透明性を変化させるアニメ化された輪の形状など、視覚表示を含み得るが、インタフェースの他の視覚表現も可能である。特定の会話に従事するための動作モジュール３５を決定すると、動作モジュール３５は、ドライバ１４に話しかけるテキストを車両内の代理インタフェース３７へ送信し、マサチューセッツ州バーリントンのＮｕａｎｃｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ，Ｉｎｃ．により生産されるＮｕａｎｃｅ（登録商標）のような、商業的に使用する入手可能なＴＴＳソフトウェアを使用するなどのテキスト音声変換（ＴＴＳ）を行うが、テキスト音声変換を行う他の手法でもよい。受信された音声は、自然言語の音声である。音声は、車両１５に組み込まれるスピーカ（図示せず）を介して伝えられる。ドライバ１４の応答は、ドライバインタフェース３７と接続される１つ以上のマイクロホンを介して拾い上げられ、さらに、ドライバ１４と交信するために使用され得る。インタフェース３７は、適切な音声テキスト変換ソフトウェアを使用して音声テキスト変換を行い、分析のために、および、可能であれば、会話の続行または別の動作の実施のために、テキストを自然言語コンポーネント３６へ送信する前に、ドライバの音声に基本の閾値化および他の必要な音声処理を行う。さらに、インタフェース３７は、ユーザを起こすためにユーザに浴びせ得る光など、動作を行うための他のコンポーネントを含み得る。さらに、ドライバインタフェース３７における他のコンポーネントが可能である。

上述されたように、サーバ１１は、本明細書に開示される実施形態を実行するための複数のモジュールを含む。モジュールは、ソースコードとして従来のプログラミング言語で書かれたコンピュータプログラムまたはプロシージャとして実施されることができ、中央処理装置によりオブジェクトまたはバイトコードとして実行するために提示される。代替的に、さらに、モジュールは、集積回路または焼き付け読み出し専用メモリコンポーネントのいずれかとしてハードウェアに実装されてよく、サーバの各々は、専用コンピュータとして作用し得る。例えば、モジュールがハードウェアとして実装される際、特定のハードウェアは、上述された通信を行うことに特化しており、他のコンピュータは使用され得ない。追加的に、モジュールが焼き付け読み出し専用メモリコンポーネントである場合、読み出し専用メモリを保存するコンピュータは、他のコンピュータが行い得ない上述の動作を行うことに特化することになる。ソースコードおよびオブジェクトおよびバイトコードの様々な実装が、フロッピーディスク、ハードドライブ、デジタルビデオディスク（ＤＶＤ）、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、および、類似の保存媒体など、コンピュータ可読保存媒体に保持され得る。他の種類のモジュールおよびモジュール機能が、他の物理的なハードウェアコンポーネントと共に可能である。例えば、サーバ１１は、入力／出力ポート、ネットワークインタフェース、および、不揮発性ストレージなど、プログラマブル計算デバイスに見られる他のコンポーネントを含み得るが、他のコンポーネントも可能である。サーバ１１およびストレージ２０は、クラウドコンピューティング環境の一部であってよく、または、専用サーバであってよい。

ドライバに対して行われる動作を状況および興味に基づいて調整することが、ドライバが注意深い安全な運転を続けるのに役立つ。図２は、１つの実施形態による、状況に特有の動作を車両のドライバへ向けて行うための方法４０を示すフロー図である。方法４０は、図１のシステムを使用して実施され得る。現在のドライバの状況が、さらに図３と関連して以下に記載されるように、判定される（ステップ４１）。ドライバに対して行われる１つ以上の動作が、さらに図６と関連して以下に記載されるように、推奨される（ステップ４２）。推奨動作のうちの１つ以上が行われ、方法４０が終了する（ステップ４３）。図１と関連して上述されたように、推奨動作は、ドライバを会話に従事させること、または、ドライバに従事させ続ける他の動作を行うことを含み得る。図１と関連して上述されたように、推奨された項目のうちの少なくとも一部は、トリガと関連付けられてよく、推奨動作と関連付けられるトリガが認識される際に実行される。さらに、一部の動作はトリガと関連付けられず、推奨されることにより実行されてよい。

ドライバの状況は、複数のコンポーネントを含み得る。図３は、１つの実施形態による、図２の方法において使用するドライバの状況を判定するためのルーチン５０を示すフロー図である。ドライバの状態は、カメラなど、車両に含まれる１つ以上のセンサを使用して判定されるが、さらに図４と関連して以下に記載されるように、状況を判定するための他の手法も可能である（ステップ５１）。車両の状態は、車両のセンサを使用して判定される（ステップ５２）。ドライバが現在位置する場所に関する空間情報が、インターネットからの情報検索などにより、取得される（ステップ５３）。ドライバの状態、車両の状態、および、空間情報は、意味グラフに表される（ステップ５４）。ドライバのプロファイルを含むドライバの特徴は、さらに図６と関連して以下に記載されるように、判定される（ステップ５５）。さらなる実施形態において、プロファイルの事前分布が作成されてよい（図示せず）。ドライバの特徴、ドライバの状態、車両の状態、および、現在の位置情報の全てを網羅する、現在の状況を特徴づけるベクトルが、さらに図５と関連して以下に記載されるように、意味グラフをドライバのプロファイル（または、ドライバのプロファイルと最も近い事前分布）と統合することにより作成され（ステップ５６）、ルーチン５０が終了する。

図４は、１つの実施形態による、図３のルーチンにおいて使用するドライバの状態を監視するためのルーチン６０を示すフロー図である。最初に、コース姿勢の予測（左側−正面−右側）が、車両のカメラにより撮像される画像に、正面、左側、および、右側の顔検出器を同時に起動することにより行われる（ステップ６１）。正面の顔姿勢として検出されるこれらのフレームごとに、顔のランドマーク特性のセットが検出され、カルマンフィルタの適用などの技術により経時的に追跡されるが、他の技術も可能である（ステップ６２）。特性は、目、鼻、および、口など、顔のパーツの相対的な位置を含み得るが、他の特性も可能である。通常の方向を見ているドライバの細かい凝視の予測は、さらに図５と関連して記載されるように、ドライバが見ている場所を予測するために使用されているドライバの特性を含む特性に基づいて行われる（ステップ６３）。１つの実施形態において、凝視の予測は、８つの異なる方向に関して行われるが、さらなる実施形態において他の数の方向も可能である。細かい凝視の予測の結果は、ドライバのルートおよび車両の速度など、他の状況情報と組み合わされて、ドライバの注意散漫のレベルの測定値を取得する（ステップ６４）。瞬きの頻度および目を閉じる割合など、目のメトリクスは、カメラを使用して予測される（ステップ６５）。頷きおよび垂下の動きの頻発など、頭の動きは、Ｅ．Ｍｕｒｐｈｙ−Ｃｈｕｔｏｒｉａｎ，Ｍ．Ｔｒｉｖｅｄｉの「Ｈｅａｄ Ｐｏｓｅ Ｅｓｔｉｍａｔｉｏｎ ｉｎ Ｃｏｍｐｕｔｅｒ Ｖｉｓｉｏｎ： Ａ Ｓｕｒｖｅｙ（コンピュータビジョンにおける頭の姿勢予測：調査）」（ＩＥＥＥ ＴＰ ＡＭＩ，ｖｏｌ．３１，ｎｏ．４，ｐｐ．６０７−６２６，２００９）、および、Ｅ．Ｍｕｒｐｈｙ−Ｃｈｕｔｏｒｉａｎ，Ａ．Ｄｏｓｈｉ，Ｍ．Ｍ．Ｔｒｉｖｅｄｉの「Ｈｅａｄ Ｐｏｓｅ Ｅｓｔｉｍａｔｉｏｎ ｆｏｒ Ｄｒｉｖｅｒ Ａｓｓｉｓｔａｎｃｅ Ｓｙｓｔｅｍｓ： Ａ Ｒｏｂｕｓｔ Ａｌｇｏｒｉｔｈｍ ａｎｄ Ｅｘｐｅｒｉｍｅｎｔａｌ Ｅｖａｌｕａｔｉｏｎ（ドライバ支援システムのための頭の姿勢予測：ロバストアルゴリズムおよび実験評価）」（ＩＥＥＥ ＩＴＳＣ，２００７）に記載されている技術などを使用して、予測されるが、他の技術も可能である（ステップ６６）。ドライバにより装着されるＰＰＧ波形センサの出力が取得され、ピークトゥピーク統計値およびパワースペクトル密度など、ＰＰＧ波形の特性は、Ｂ．ＬｅｅおよびＷ．Ｃｈｕｎｇの「Ｄｒｉｖｅｒ ａｌｅｒｔｎｅｓｓ ｍｏｎｉｔｏｒｉｎｇ ｕｓｉｎｇ ｆｕｓｉｏｎ ｏｆ ｆａｃｉａｌ ｆｅａｔｕｒｅｓ ａｎｄ ｂｉｏ−ｓｉｇｎａｌｓ（顔の特性および生体信号を融合して使用するドライバの注意力監視）」（ＩＥＥＥ Ｓｅｎｓｏｒｓ Ｊｏｕｒｎａｌ，Ｖｏｌ．１２，Ｎｏ．７，ｐｐ．２４１６−２４２２）にさらに記載される方法などで計算されるが、特性を計算する他の手法も可能である（ステップ６７）。計算されたＰＰＧ波形、予測された目のメトリクス、および、予測された頭の動きは、異なる時間帯からの長い旅から戻ってきた直後のドライバなど、ドライバに関する時刻および他の関連情報など、他の状況情報と組み合わされて（処理されて意味グラフ内に含まれてよく、ドライバの車両におけるセンサに基づいて、または、ソーシャルネットワーキング投稿を分析することにより、判定され得るが、そのような情報を判定する他の手法も可能である）、ドライバの眠気の測定を提供する（ステップ６８）。選択的に、予測されたメトリクスは、ドライバへ表示されてよく、または、インターネットワークへの接続を介して第三者へ提供されてよく（ステップ６９）、ルーチン６０を終了する。さらなる実施形態において、ドライバの身振りまたはドライバの周囲の環境など、他のデータが、車両のセンサを使用して分析され得る。

ドライバが見ている方向を予測することは、ドライバの眠気の程度を判定するのに役立ち得る。図５は、１つの実施形態による、図４のルーチン６０において使用する細かい凝視の予測を行うためのルーチン７０を示すフロー図である。既知の方向を見ているドライバの１つ以上の映像が記録され、既知の方向でラベル付けされる（ステップ７１）。映像は、ストレージに保存され得る。訓練映像の各々におけるドライバの顔の特性が、特定される（ステップ７２）。ステップ７２で取得されたドライバの顔の特性が、訓練映像における顔の特性と比較され（ステップ７３）、細かい凝視の予測が比較に基づいて行われる。時間平滑化が凝視の予測に対して行われ（ステップ７４）、隣接するフレーム間の一貫性および整合性を取得し（ステップ７５）、ルーチン７０を終了する。

図６は、１つの実施形態による、図２の方法４０において使用するドライバの特徴を判定するためのルーチン８０を示すフロー図である。ドライバ、ドライバの興味、ソーシャルネットワーキング接続と関連付けられるデータ項目を含むユーザモデルは、ドライバが属するソーシャルネットワーク、または、ドライバが属する他のウェブサイトなど、ホストユーザが生成したコンテンツであるウェブコンテンツから抽出される（ステップ８１）。抽出されたデータ項目はトピックの階層と比較され、各データ項目と関連付けられる階層のトピックが特定される（ステップ８２）。データ項目は、統一されたパラメータ空間に特定されたトピックを使用して分類され得る（ステップ８３）。図１と関連して上述されたように、１つの実施形態において、分類は、特定されたトピックの表現ベクトルを生成することを含み得る。データ項目の各々に対するベクトルは、データ項目の経年に基づいて重み付けされ、古いデータ項目より、最近のデータ項目（ドライバの現在の特徴を表す）のベクトルに、より多く重み付けされる（ステップ８４）。重み付けされたベクトルは、興味など、ドライバの現在および過去の特徴を示すドライバのプロファイルとして機能する単一ベクトルに統合される（ステップ８５）。選択的に、個人データおよびプロファイルベクトルが組み合わされて、母集団事前分布を形成してよく（ステップ８６）、ルーチン８０を終了する。

ドライバの状況およびドライバの特徴に基づいて、ドライバに対して実行するための動作が推奨され得る。図７は、１つの実施形態による、図２の方法４０において使用するドライバに対して行われる動作を推奨するためのルーチン９０を示すフロー図である。可能な動作のリストが管理される（ステップ９１）。ドライバのソーシャルネットワーキング接続の最近のソーシャルネットワーキング投稿など、ドライバに関する現在の情報がウェブから抽出され、選択的に、意味グラフ１９に指標化される（ステップ９２）。推奨可能な動作は、現在の抽出された情報、可能な項目、および、現在の状況ベクトルに基づいて生成される（ステップ９３）。推奨可能な動作は、ランク付けされる（ステップ９４）。図１と関連して上述されたように、ランク付けを行う複数の方法が可能である。１つ以上の動作が、図１と関連して上述されたように、実行するためにランクに基づいて選択され（ステップ９５）、ルーチン９０を終了する。

Claims (10)

1. 状況に特有の動作を車両のドライバへ向けて行うためのシステムであって、
   インターネットワークを介して車両と接続される１つ以上のサーバであって、前記サーバはコードを実行するよう構成され、
   前記車両のドライバの状況を判定するよう構成される状況モジュールであって、
   前記ドライバの状態を判定するよう構成されるドライバ状態モジュール、および、
   前記車両の状態を判定するよう構成される車両状態モジュール、
   を備える、状況モジュール、
   前記ドライバの１つ以上の特徴を判定するよう構成される特徴モジュール、
   前記ドライバに対して行われる１つ以上の動作を前記状況に基づいて推奨するよう構成される推奨モジュール、および、
   前記推奨動作のうちの１つ以上を行うよう構成される実行モジュール、
   を備える、サーバを備える、システム。
2. 前記車両の位置を判定するよう構成される位置モジュール、
   前記判定された位置に関するデータを取得するよう構成されるデータモジュール、
   をさらに備える、請求項１に記載のシステム。
3. 前記ドライバの状態、前記車両の状態、および、前記位置データを、意味グラフに表すよう構成されるグラフモジュール、
   前記特徴をベクトルに表すよう構成されるベクトルモジュール、および、
   前記意味グラフおよび前記ベクトルを、前記状況を表す異なるベクトルに統合するよう構成される統合モジュール、
   をさらに備える、請求項２に記載のシステム。
4. コース姿勢の予測を前記ドライバに、前記車両に含まれるカメラを使用して行うよう構成される姿勢モジュール、
   コース姿勢の予測の結果のうちの少なくとも一部を使用して、前記ドライバの顔における１つ以上の顔のランドマーク特性を検出するよう構成される特性モジュール、
   前記検出された顔のランドマーク特性を使用して、前記ドライバの凝視の１つ以上の方向を判定することを備える、細かい凝視の予測を前記ドライバに行うよう構成される凝視モジュール、および、
   前記細かい凝視の予測および前記車両の状態を使用して、前記ドライバの注意散漫のレベルを測定するよう構成される注意散漫モジュール、
   をさらに備える、請求項１に記載のシステム。
5. 前記ドライバの１つ以上の目のメトリクスを、前記カメラを使用して予測するよう構成される目のメトリクスモジュールであって、前記メトリクスは瞬きの頻度および目を閉じる割合のうちの少なくとも１つを備える、目のメトリクスモジュール、
   生体データを前記ドライバにより装着されるセンサを使用して取得するよう構成される生体データモジュール、および、
   前記生体データ、前記目のメトリクス、および、前記頭の動きを使用して、前記ドライバの眠気のレベルを測定するよう構成される眠気モジュール、
   をさらに備える、請求項４に記載のシステム。
6. 状況に特有の動作を車両のドライバへ向けて行うための方法であって、前記方法は、
   車両のドライバの状況を判定するステップであって、
   前記ドライバの状態を判定するステップ、および、
   前記車両の状態を判定するステップ、
   を備える、判定するステップ、
   前記ドライバの１つ以上の特徴を判定するステップ、
   前記ドライバに対して行われる１つ以上の動作を前記状況に基づいて推奨するステップ、および、
   前記推奨動作のうちの１つ以上を行うステップ、
   を備え、
   前記ステップは少なくとも１つの適切にプログラム化されたコンピュータにより行われる、方法。
7. 前記状況を判定することは、
   前記車両の位置を判定すること、
   前記判定された位置に関するデータを取得すること、
   をさらに備える、請求項６に記載の方法。
8. 前記ドライバの状態、前記車両の状態、および、前記位置データを、意味グラフに表すこと、
   前記特徴をベクトルに表すこと、および、
   前記意味グラフおよび前記ベクトルを、前記状況を表す異なるベクトルに統合すること、
   をさらに備える、請求項７に記載の方法。
9. コース姿勢の予測を前記ドライバに、前記車両に含まれるカメラを使用して行うこと、
   前記ドライバの顔における１つ以上の顔のランドマーク特性を、コース姿勢の予測の結果のうちの少なくとも一部を使用して検出すること、
   前記検出された顔のランドマーク特性を使用して、前記ドライバの凝視の１つ以上の方向を判定することを備える、細かい凝視の予測を前記ドライバに行うこと、および、
   前記細かい凝視の予測および前記車両の状態を使用して、前記ドライバの注意散漫のレベルを測定すること、
   をさらに備える、請求項６に記載の方法。
10. 前記ドライバの１つ以上の目のメトリクスを、前記カメラを使用して予測することであって、前記メトリクスは瞬きの頻度および目を閉じる割合のうちの少なくとも１つを備える、予測すること、
    生体データを前記ドライバにより装着されるセンサを使用して取得すること、および、
    前記生体データ、前記目のメトリクス、および、前記頭の動きを使用して、前記ドライバの眠気のレベルを測定すること、
    をさらに備える、請求項９に記載の方法。

Images