(57)【特許請求の範囲】
【請求項１】
ドライバ間の通信を容易にするコンピュータ実装システムであって、
複数のドライバを監視する監視モジュールと、
前記複数のドライバのうちの１人のドライバの位置を決定する位置決定モジュールと、  前記識別された位置に基づいて、前記１人のドライバに近接した他のドライバから成るネットワークを備えたソーシャルバブルを、前記１人のドライバ用に決定するネットワーク決定モジュールと、
前記１人のドライバからコマンドを受信するコマンド受信モジュールと、
前記ソーシャルバブル内の１人または複数のドライバに前記コマンドを送信する配信モジュールと、
前記ソーシャルバブルを識別するネットワーク識別モジュールとを備え、
前記ネットワーク識別モジュールが、
前記位置においてトラフィック密度を決定する密度決定モジュールと、
前記１人のドライバの車両の速度を決定する速度決定モジュールと、
前記車両密度および前記車両速度に基づいて、近接した距離を決定する距離決定モジュールと、
前記１人のドライバからの、前記他のドライバのそれぞれの距離が、前記近接した距離を満たすことを決定するドライバ距離モジュールと、
前記ソーシャルバブルのメンバとして、前記他のドライバをグループ分けするグループ分けモジュールとを有する、コンピュータ実装システム。
【請求項２】
前記ソーシャルバブルの範囲内の前記他のドライバの数を低減する因子を適用する因子モジュールをさらに備えた、請求項１に記載のコンピュータ実装システム。
【請求項３】
ユーザから前記１人のドライバ用の識別情報を受信する受信モジュールと、
前記識別情報に基づいて前記１人のドライバを識別するドライバ識別モジュールと、
前記識別されたドライバに前記コマンドを送信するコマンド送信モジュールとをさらに備えた、請求項１に記載のコンピュータ実装システム。
【請求項４】
配信用コマンドの妥当性を決定する妥当性決定モジュールであって、
前記コマンドの趣旨を決定する趣旨決定モジュールと、
前記メッセージの趣旨を肯定的であると識別する趣旨識別モジュールと、
前記メッセージを有効にする有効化モジュールと、
前記配信用コマンドに基づいて妥当性を決定する決定モジュールとを備えた、妥当性決定モジュールをさらに備えた、請求項１に記載のコンピュータ実装システム。
【請求項５】
ドライバ間の通信を容易にするコンピュータ実装方法であって、
複数のドライバを監視するステップと、
前記複数のドライバのうちの１人のドライバの位置を決定するステップと、
前記識別された位置に基づいて、前記１人のドライバに近接した他のドライバから成るネットワークを備えたソーシャルバブルを、前記１人のドライバ用に決定するステップと、
前記１人のドライバからコマンドを受信するステップと、
前記ソーシャルバブル内の１人または複数のドライバに前記コマンドを送信するステップとを備え、
前記ソーシャルバブルを決定するステップが、
前記位置においてトラフィック密度を決定するステップと、
前記１人のドライバの車両の速度を決定するステップと、
前記車両密度および前記車両速度に基づいて、近接した距離を決定するステップと、    前記１人のドライバからの、前記他のドライバのそれぞれの距離が、前記近接した距離を満たすことを決定するステップと、
前記ソーシャルバブルのメンバとして、前記他のドライバをグループ分けするステップとを有する、コンピュータ実装方法。
【請求項６】
前記ソーシャルバブルの範囲内の前記他のドライバの数を低減する因子を適用するステップをさらに備えた、請求項５に記載のコンピュータ実装方法。
【請求項７】
ユーザから前記１人のドライバ用の識別情報を受信するステップと、
前記識別情報に基づいて前記１人のドライバを識別するステップと、
前記識別されたドライバに前記コマンドを送信するステップとをさらに備えた、請求項４に記載のコンピュータ実装方法。
【請求項８】
配信用コマンドの妥当性を決定するステップであって、
前記コマンドの趣旨を決定するステップと、
前記メッセージの趣旨を肯定的であると識別するステップと、
前記メッセージを有効にするステップと、
前記配信用コマンドに基づいて妥当性を決定する決定ステップとを備えた、妥当性を決定するステップをさらに備えた、請求項４に記載のコンピュータ実装方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、一般にソーシャルネットワークに関し、詳しくは、音声指向ネットワークを経由して通信を容易にするコンピュータ実装システムおよび方法に関する。
【背景技術】
【０００２】
現在、ドライバが他のドライバと通信する選択肢は、限定されている。例えば、ドライバは、手の動作、車のクラクション、車両用ライト、または顔の表現を通して、通信することができる。車両用ヘッドライトが夜間に点灯されていない場合、別のドライバは、自身のヘッドライトを点滅して、ヘッドライトが点灯されていないことを指摘することができる。代替策としては、ドライバが、自身の車線に別の車両を合流可能にするとき、別の車両のドライバは、自身の手を振って感謝を示すことができる。さらに、ドライバは、例えば、携帯電話およびハンズフリーセットを用いて、通信することができる。しかしながら、ドライバは、別のドライバの身元ならびに携帯電話番号を知っている場合だけ、この別のドライバと通信することができる。限定されてはいるが、ドライバ間通信は、運転経験を改善して車両事故数を低減することができる。
【０００３】
ドライバ通信を促進しようとする試みがなされてきた。例えば、カリフォルニア州マウンテンビューにあるグーグル社によるＷａｚｅは、ドライバが、話題データおよび道路データ、事故レポート、警察投入、ならびに他の危険要因を、リアルタイムで提供可能にすることによって、ドライバ間の通信を増加させようとする。ドライバが提供したデータは、他のドライバが眺めるために地図に表される。ドライバの位置も、地図に表される。それゆえに、Ｗａｚｅは、情報を一般的に共有することに焦点を合わせており、ドライバ間の通信を制御すること、すなわち１人のドライバが別のドライバを選択して通信可能にすること、に対処することができない。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
したがって、動的なコミュニティの形成、車両の識別、および通信の制御を含む、ドライバ間の通信を容易にする手法の必要性がある。通信は、音声指向型であることが好ましい。
【課題を解決するための手段】
【０００５】
ソーシャルバブルとして知られている、ドライバのネットワークに基づいて、１人のドライバは、ごく近接した他の１人または複数のドライバとの通信を開始することができる。ソーシャルバブル内の複数のドライバは、当該複数のドライバの、当該開始しているドライバの車両への近接性に基づいて決定することができる。次に、当該開始しているドライバは、ソーシャルバブル内の特定のドライバを、当該特定のドライバの特徴または当該特定のドライバの車両に基づいて識別することができる。次いで当該開始しているドライバは、当該特定のドライバ向けのコマンドを口頭で伝達することができる。コマンドは、特定のドライバに直接に提供することができ、または配信に先立って分析することができる。分析の間に、コマンドの趣旨が決定されて、有効化を行うことができる。コマンドが肯定的であると決定されて成功裏に有効にされるとき、コマンドは配信することができる。別のやり方では、コマンドが肯定的でないまたは有効化できない場合、コマンドは、書き直すまたは削除することができる。
【０００６】
一実施形態が、音声指向ネットワークを経由して通信を容易にするコンピュータ実装システムおよび方法を提供する。複数のドライバが監視されて、当該複数のドライバのうちの少なくとも１人の位置が決定される。当該少なくとも１人のドライバに近接した他のドライバから成るネットワークを備えたソーシャルバブルが、識別された位置に基づいて決定される。当該少なくとも１人のドライバからのコマンドが受信され、当該コマンドは、ソーシャルバブル内の１人または複数のドライバへ送信される。
【０００７】
本発明のさらに別の実施形態は、次の詳細な説明から当業者には容易に明らかなことになり、その説明では、本発明の実施形態が、本発明を実行するようにもくろまれた最良の態様を例証する目的で説明される。理解されるように、本発明は、他のかつ相異なる実施形態が可能であり、そのいくつかの細部は、本発明の趣旨および範囲からすべて逸脱せずに、種々の自明な観点において修正することが可能である。したがって、図面および詳細な説明は、本来は例示的なものとしてみなすべきであり、限定的なものとしてみなすべきではない。
【図面の簡単な説明】
【０００８】
【図１】図１は、一実施形態に従って、音声指向ネットワークを経由して通信を容易にするコンピュータ実装システムを示すブロック図である。
【図２】図２は、一実施形態に従って、音声指向ネットワークを経由して通信を容易にするコンピュータ実装方法を示すフローチャートである。
【図３】図３は、例として、一ドライバ用のソーシャルバブルを決定する工程を示すフローチャートである。
【図４】図４は、例として、一般の車両通信を容易にする工程を示すフローチャートである。
【図５】図５は、例として、特定の車両通信を容易にする工程を示すフローチャートである。
【図６】図６は、例として、配信用コマンドの妥当性を決定する工程を示すフローチャートである。
【図７】図７は、例として、コマンドの送信者有効化用工程を示すフローチャートである。
【図８】図８は、例として、コマンドの受信者有効化用工程を示すフローチャートである。
【図９】図９は、例として、受信者の認知負荷に基づいてコマンドを配信する工程を示すフローチャートである。
【図１０】図１０は、例として、ドライバのフィードバックを有するレポートを示すブロック図である。
【発明を実施するための形態】
【０００９】
運転中に、他のドライバと通信すると、車のライトまたはクラクションなどの、手の動作および車両の信号を含めて利用可能な通信手段が限定されるので、問題となる。ドライバ間の通信を増加させると、例えば車両ヘッドライトを点灯したりウィンカを使用したりして、有用な運転情報および注意喚起事項をドライバに提供することによって、運転経験を増加させて車両事故数を低減するのに役立つことができる。ドライバ用の音声指向ソーシャルネットワークは、近接したドライバとの通信を提供することができ、当該通信は、ドライバへの不必要な妨害を回避して運転中の激怒を防止するように制御される。
【００１０】
上述した音声指向ソーシャルネットワークによって、効率的かつ安全な環境内でドライバが互いに通信することが可能になる。図１は、一実施形態に従って、音声指向ネットワークを経由してドライバ通信を容易にするコンピュータ実装システムを示すブロック図である。車両１１を運転するユーザは、携帯電話２６または他のモバイル・ハンドヘルド・コンピューティング・デバイス（図示されない）を経由して、音声指向ソーシャルネットワーク用のソフトウェアアプリケーション（図示されない）またはウェブページ１５にアクセスすることができる。ウェブページ１５にアクセスするために、ユーザの携帯電話２６は、インターネットなどの相互接続ネットワーク１２を経由してサーバ１３へ、ウェブページの要求を送信する。ウェブページ１５は、サーバ１３へ相互接続されたデータベース１４内に記憶することができ、要求に応じてユーザの携帯電話２６へ送信することができる。
【００１１】
いったんアクセスされると、ユーザは、アプリケーションまたはウェブページにログインして他のドライバと通信することができる。他のドライバから成るネットワークを決定するために、ユーザ車両１１のトラッキングが開始される。車両１１は、車両の位置座標２０を得るためにＧＰＳナビゲーションシステム２７を含むことができ、位置座標２０は、サーバ１３へ送信されてデータベース１４内に記憶される。座標は、連続した基準で、所定の時間に、または要求通りに得ることができる。サーバ１３は、ネットワークモジュール１３、通信モジュール１７、有効化モジュール１８、および配信モジュール１９を含む。ネットワークモジュール１６は、ユーザ車両の位置座標２０を利用して、近接して位置決めされた車両２５を識別し、当該近接して位置決めされた車両２５に基づいてユーザのソーシャルバブルを生成する。ソーシャルバブルは、ユーザ車両位置が変化するにつれて、絶えずアップデートされる。ユーザは、ソーシャルバブル全体にブロードキャストすることができ、またはソーシャルバブルの範囲内の特定のドライバを識別することができる。特定のドライバは、ユーザによって、車両の特徴、ドライバの特徴、および占有期間を用いて、識別することができる。車両の特徴およびドライバの特徴ならびに占有期間は、各ドライバによって提供されてユーザのプロファイル２１内に記憶することができる。これらの特徴は、ユーザによって、自然言語または予め定義された入力コマンドを用いて識別することができる。代わりにまたは加えて、車両の特徴およびドライバの特徴ならびに占有期間が、車両内部のセンサ（図示されない）から得られて、例えば、車両内に現在何人の搭乗者がいるかを決定することができる。１人または複数のドライバの識別の際に、ユーザは、これらのドライバ向けに口頭による発話のコマンドを提供することができる。通信モジュール１７は、予め定義された入力コマンドを利用することによって、およびユーザからのコマンドがドライバへ配信するのに適切であるかどうかを決定することによって、ユーザと１人または複数のドライバとの間で口頭による通信を制御する。
【００１２】
ユーザからの通信は、ユーザ車両１１またはハンドヘルド・モバイル・デバイス２６に位置決めされたマイクロホンを経由して、行うことができる。有効化モジュール１８は、配信に先立って通信を有効にして、通信が有用かつ建設的であることを保証する。配信モジュール１９は、所期のドライバに通信を配信する適切な時間を決定する。適切な時間は、所期のドライバには最も重荷とならない時間とすることができる。最後に、各ドライバによって送受信された通信に基づいて、通信のレポートを生成して当該ドライバに提供することができる。具体的には、レポートは、ユーザの運転経験の概要を含むことができ、毎日の、毎週の、毎月の、または年４回の基準で、ならびに各運転セッションの後を含む相異なる期間で、提供することができる。
【００１３】
モバイル・コンピューティング・デバイスおよびサーバはそれぞれ、本明細書で開示された実施形態を実行する中央処理装置および１つまたは複数のモジュールを含むことができる。モジュールは、ソースコードとして従来のプログラミング言語で書かれたコンピュータプログラムまたはコンピュータ処理手順として実装することができ、オブジェクトコードまたはバイトコードとして中央処理装置による実行のために提供される。代替策としては、モジュールは、集積回路構造としてまたは読み出し専用メモリ部品内へ焼かれることで、ハードウェア内に実装することもでき、コンピューティングデバイスおよびサーバはそれぞれ、専門化したコンピュータとして機能することができる。例えば、モジュールがハードウェアとして実装されるとき、この特別のハードウェアは、メッセージの優先順位付けを行うように専門化されて、他のコンピュータを用いることができない。さらに加えて、モジュールが読み出し専用メモリ部品内へ焼かれるとき、読み出し専用メモリを格納するコンピューティングデバイスまたはサーバは、他のコンピュータが可能でないメッセージの優先順位付けを行うように専門化されることになる。ソースコードならびにオブジェクトコードおよびバイトコードの種々の実装形態は、フロッピディスク、ハードドライブ、デジタル・ビデオ・ディスク（ＤＶＤ）、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）および類似の記憶媒体などの、コンピュータ読み取り可能な記憶媒体上に保持することができる。他の種類のモジュールおよびモジュール機能が可能であり、ならびに他の物理的なハードウェア部品が可能である。
【００１４】
ドライバ間の通信は、ソーシャルバブルを経由して開始することができる。図２は、一実施形態に従って、音声指向ネットワークを経由して通信を容易にするコンピュータ実装方法３０を示すフローチャートである。最初にユーザは、ユーザのプロファイル内に記憶することができるユーザ識別情報を提供することによって、ウェブページまたはモバイル・コンピュータ・アプリケーションなどを経由して、ソーシャルネットワークに登録する（ブロック３１）。ユーザ識別情報は、名前、住所、電話番号、ユーザ関心事、ならびに性別、ヘアーカラーおよび年齢などのユーザの特徴、ならびに車両製造元および車両モデル、ナンバープレート番号、車両カラー、車両形状もしくは車両型、車両製造年ならびに車両ステッカーなどの車両の特徴、または頻繁な通行人などの運転情報を含むことができる。ユーザの特徴、車両の特徴、および運転情報は、他のドライバによって用いられて、通信を開始するユーザを識別することができる。
【００１５】
ユーザがいったん運転を開始すると、ユーザの位置が識別される（ブロック３２）。位置は、ユーザまたは車両のモバイルデバイスと関連付けられたＧＰＳシステムを経由して、連続した基準で、要求通りに、または所定の時間に得られる座標を含むことができる。ユーザの位置座標の決定は、音声指向ソーシャルネットワークへのユーザのログインおよびアクセス、音声コマンド、または車両エンジンの始動に基づいて、トリガすることができる。車両位置を決定する他のトリガが可能である。決定された位置を用いて、ユーザのソーシャルバブル、すなわちコミュニティ、を識別することができる（ブロック３３）。ソーシャルバブルは、ユーザ車両に近接した車両を含む。近接した車両は、さらに以下で図３を参照して説明されるように、ユーザの決定位置におけるトラフィック密度およびユーザ車両の速度に基づいて、決定することができる。さらに、ソーシャルバブル内の車両数は、変更することができ、すなわち所定の車両数は、ソーシャルバブル内に含まれる最大車両数として指定することができる。
【００１６】
ユーザとソーシャルバブル内の他の車両のドライバとの間の一般のまたは特定の通信セッションを、開始することができる（ブロック３４）。一般の通信セッションは、ソーシャルバブル内に、ユーザを含むすべてのメンバを含み、一方で特定の通信は、ユーザ、およびソーシャルバブルからユーザによって選択された１人または複数のドライバを含む。一般のおよび特定の通信セッションを開始することは、さらに以下で図４および図５に関して詳細に説明される。セッション中の通信は、制御することができる（ブロック３５）。通信は、ユーザおよびセッション内の他の参加者から受信される、口頭による発話のコマンドを含むことができる。一実施形態において、当該コマンドは、予め定義することができ、ユーザから受信された自然言語による発話は、予め定義されたコマンドと比較して、予め定義された適切な通信用コマンドを識別することができる。代替策としては、当該コマンドは、自然言語による発話を含むことができる。各コマンドは、さらに以下で図６〜図８を参照して詳細に説明されるように、妥当性および内容が再検討され、有効にされて、不必要な妨害を回避することができる。コマンドの再検討、有効化、および配信を制御すると、ドライバの安全性を保証しながら、使いやすく効果的なドライバ通信を提供するのに役立つ。ユーザと他の各ドライバとの間の通信は、録音され記憶されて、任意選択で、毎日の、毎週の、または毎月のなどの基準で、コメントの概要レポートを生成することができる（ブロック３６）。他の期間が可能である。
【００１７】
ソーシャルバブルは、車両と、ユーザとの通信に利用可能な関連するドライバとのコミュニティを含む。図３は、例として、ソーシャルバブルを決定する工程４０を示すフローチャートである。ソーシャルバブル内のメンバは、ユーザからの近接距離に基づいて選択することができる。近接距離を決定するために、トラフィック密度が決定される（ブロック４１）。高密度トラフィックでは、多数の車両がユーザの近くにありそうである。したがって、高密度トラフィックは、より短い近接距離と関連付けられて、極端に多い車両がソーシャルバブル内のメンバとして含まれることを防止することができる。代替策としては、低密度トラフィックは、より長い近接距離と関連付けられて、ユーザが通信することができる適度な数の車両を含むことができる。
【００１８】
近接距離は、ユーザ車両の速度に基づいて決定することもできる（ブロック４２）。ユーザが制限速度よりも速く運転しているとき、より速い運転速度が、ユーザが速度を速めることができる空の道路を示すことができるように、一般に、より長い近接距離が割り当てられる。対照的に、指定された制限速度を下回る運転速度は、低い速度が一般に多数の車から成るトラフィックおよびごく近接した状態を示すので、より短い近接距離と関連付けることができる。さらに、ユーザが時速６０マイル以上などの高速で運転しているとき、ユーザがハイウェイ上にいそうであり、ハイウェイがたくさんの車両を有しがちであるので、近接距離はより短いとすることができる。
【００１９】
続いて、近接距離は、トラフィック密度および車両速度に基づいて設定される（ブロック４３）。近接距離は、決定されたトラフィック密度および車両速度と関連付けられた所定の距離に基づくことができ、ならびに近接距離を決定する他の方法に基づくことができる。例えば、所定の距離に基づくとき、平均値の１０％のトラフィック密度は、４０フィートの近接性と関連付けることができ、一方で指定速度を５％下回る速度は、３５フィートの距離と関連付けられる。近接距離を決定するために、トラフィック密度用の距離と車両速度用の距離との平均値を平均して近接距離として提供することができる。
【００２０】
さらなる一実施形態において、近接距離は、距離格子を用いて決定することができ、当該距離格子は、水平軸に沿ってトラフィック密度または車両速度のうちのいずれか一方、および垂直軸に沿ってトラフィック密度または車両速度のうちの他方を含む。軸は、トラフィック密度および車両速度の大きさを特定する。次いで所定の近接性値が、トラフィック密度および車両速度の組合せごとに満たされる。いったん格子が完成されると、ユーザ用に決定されたトラフィック密度および車両速度の値を、格子上で特定することができ、密度および速度の値に対する近接距離を決定することができる。
【００２１】
音声指向ソーシャルネットワークへ登録された他の車両の位置を決定することができ、ユーザ車両の近接距離の範囲内にあるこれらの車両が、ユーザのソーシャルバブル内に含まれるように選択される（ブロック４４）。一実施形態において、ソーシャルバブルにサイズしきい値を適用することができ、ソーシャルバブルの範囲内の車両の数がしきい値を越える場合、ソーシャルバブルは、除去する車両を識別するルールを適用することによって、低減することができる（ブロック４５）。当該ルールは、反対方向に運転するすべての車両を除去すること、または予め適用された近接距離よりも短い追加の近接距離に比べて、ユーザからより遠いすべての車両を除去することを含むことができる。
【００２２】
代替策としては、ソーシャルバブルは、トラフィック密度および車両速度にかかわらず、ユーザ位置の所定の車両近接距離の範囲内にあるすべての車両を識別することによって、決定することができる。本実施形態において、トラフィック密度が高くなるにつれて、ソーシャルバブルはますます大きくなり、トラフィック密度が低くなるにつれて、ソーシャルバブルはますます小さくなる。ソーシャルバブルのサイズを低減するために、ソーシャルバブルの範囲内にある車両数に対して、所定のサイズしきい値を適用することができ、ソーシャルバブルの範囲内にある車両数がサイズしきい値を越えるとき、１つまたは複数の低減ルールを適用することができる。当該ルールは、反対方向に運転するすべての車両を除去すること、またはもう１つの近接距離に比べてユーザからより遠いすべての車両を除去することを含むことができる。対照的に、ソーシャルバブルのサイズを増加させるために、より長い近接距離を適用することができる。
【００２３】
ユーザが運転し続けながら、ソーシャルバブルの範囲内の車両メンバは、ユーザ車両へのメンバ車両の近接性に基づいて、変更することができる。例えば、ユーザが時速６６マイルでハイウェイを運転中であり、かつユーザのソーシャルバブルの範囲内であると決定された別のドライバが時速５９マイルにすぎない速度で運転中である場合、ユーザがドライバからの距離を増加させて他のドライバがもはやソーシャルバブルの近接距離の範囲内にいないとき、結局のところドライバをソーシャルバブルから除去することになる。しかしながら、ドライバがソーシャルバブル内に含まれるとはもはや決定されないときにユーザがドライバと会話している場合、通信接続は保持することができ、したがってユーザおよびドライバは通信し続けることができる。ソーシャルバブルは、連続した基準で、所定の時間間隔で、または所定の時間に、決定することができる。
【００２４】
一例において、Ｄｅｒｒｅｌｌは、水曜日午後５時３０分ラッシュアワー中に、サウス・シアトル内をレーニエ・アベニューに沿って南行きに、ブラック色のアキュラを運転している。レーニエ・アベニューは、制限速度が時速３０マイルの幹線道路であり、２本の南行き車線および２本の北行き車線を有する。しかしながら、ラッシュアワーによるトラフィックが原因で、Ｄｅｒｒｅｌｌは、時速２２マイルで運転している。音声指向ソーシャルネットワークに登録または署名すると、Ｄｅｒｒｅｌｌの車両の位置は、４７．５７６１１１、−１２２．２９２７７８として決定される。当該位置に基づいて、Ｄｅｒｒｅｌｌの車両に近接した車両から成るネットワークは、ソーシャルバブルに属するものであると識別される。具体的には、トラフィック密度は、平均値よりも１０％高いと決定され、Ｄｅｒｒｅｌｌの速度は、掲示制限の時速３０マイルよりも８マイル低い。３０フィートの距離は、増加したトラフィック密度と関連付けられ、２４フィートの距離は、通常よりも２３％低速であるＤｅｒｒｅｌｌの速度と関連付けられる。それゆえに、近接距離は、２７フィートであると決定される。Ｄｅｒｒｅｌｌの車両から２７フィートの範囲内のすべての車両が、Ｄｅｒｒｅｌｌのソーシャルバブルの一部であると識別される。本例において、１６台の車両が識別される。２００台の車両のサイズしきい値が適用され、ソーシャルバブル内の車両がサイズしきい値を越えないので、どんな低減因子も適用される必要がない。
【００２５】
ユーザは、ソーシャルバブル内の車両と関連付けられた１人または複数のドライバとの通信を開始することができる。一般の通信は、ユーザとユーザのソーシャルバブルと関連付けられた他のすべてのドライバとの間の通信に焦点を合わせ、一方で特定の通信は、ユーザによって識別されたソーシャルバブルと関連付けられた１人または複数のドライバとの通信に焦点を合わせる。図４は、例として、一般の車両通信を容易にする工程５０を示すフローチャートである。一般の通信中に、ユーザは、ドライバと直接に話すことができ、または最初に再検討され次いでドライバに対して演じられるコマンドを提供することができる。１つまたは複数の自然言語によるスピーチ発話から成る口頭コマンドが、ユーザから受信される（ブロック５１）。コマンドは、運転指示、運転条件または運転提案、ソーシャル会話、ドライバ通信の要求、および指令、ならびに他の種類の通信などの、内容を含むことができる。一実施形態において、ユーザによって提供された自然言語による発話は、一式の予め定義されたコマンドと比較して、所期の受信者に配信するためのほとんど類似のコマンドを識別することができる。代替策としては、ユーザによって提供された自然言語は、コマンドであると識別することができる。
【００２６】
コマンドが発言の要求かどうかに関して、決定がなされる（ブロック５２）。そうである場合、ユーザは、ソーシャルバブル内の車両と関連付けられた他のドライバと直接に接続される（ブロック５４）。ソーシャルバブルの範囲内の各メンバは、コマンドの送信者または受信者とすることができる。例えば、電話会議または会議類似のフォーラムと同様な、ソーシャルバブル内のドライバによって言葉で表された各コマンドは、バブル内の他のドライバによって聞くことができまたは応答することができる。しかしながら、ユーザは、チャットルームと同様なサイドカンバセーションで、他の１人または複数のドライバと直接にやり取りすることもできる。２人以上のドライバが全体グループとは別個の会話を望む場合、サブカンバセーションを形成することができ、２人以上のドライバ参加者からのスピーチの音量を増加させて、他のドライバからのスピーチの音量を低減することができる。サブカンバセーションは、サイドカンバセーションがソーシャルバブルの主要会話を妨害することを防止するように形成することができる。さらなる一実施形態において、ユーザは、ソーシャルバブルが発生すると、バブル内の他のドライバと自動的に接続することができる。
【００２７】
ユーザからのコマンドが発言の要求でない場合、当該コマンドは、その内容がソーシャルバブルの範囲内の別のドライバに送信するのが適切であることを保証するように再検討される（ブロック５３）。適切なコマンドは、有用な提案、トラフィックアップデート、および追加の通信への接触情報の要求などの、肯定的情報を含む。専門家は、コマンドを再検討して「肯定的」または「否定的」状態を割り当てることができる。さらに加えて、メカニカルタークを用いてコメントを肯定的もしくは否定的として分類することができ、または機械学習を用いて各コマンドの内容に基づいて分類することができる。
【００２８】
同様に送信者または受信者に基づいて、適切なコマンドを有効にすべきである。送信者有効化は、送信者の評判を分析して送信者の評判が肯定的であるときにメッセージを有効にすることができ、さらに以下で図７を参照して詳細に説明される。受信者有効化は、さらに以下で図８を参照して詳細に説明されるように、受信者によって受信されたコマンドの履歴、および有効にしようとする現在のコマンドが予め受信されたコマンドと一致するかどうかを分析する。
【００２９】
コマンドが配信用に適切である場合（ブロック５５）、コマンドは、ソーシャルバブルと関連付けられた１人または複数のドライバに配信することができる（ブロック５６）。具体的には、コマンドは、送信者の音声の録音としてまたは合成スピーチに基づいて、口頭で配信することができる。コマンドを配信する時間は、ユーザの認知負荷に基づいて決定することができる。例えば、コマンドは、ユーザの認知負荷が低いときに配信することができる。ユーザの認知負荷が高いとき、コマンドは、ユーザの認知負荷が低くなるまで保持することができる。コマンドを配信するステップは、さらに以下で図９に関して詳細に説明される。コマンドが配信用に不適切である場合（ブロック５５）、コマンドは、他のドライバに提供することができなくて、その代わりに削除することができる（ブロック５７）。
【００３０】
上述した例に戻ると、Ｄｅｒｒｅｌｌは、「会話の要求」の口頭コマンドを提供する。コマンドの要求に基づいて、Ｄｅｒｒｅｌｌは、ソーシャルバブル内の１６台の車両のドライバと接続されて、ドライバと直接に話すことができる。ドライバと接続されながら、Ｄｅｒｒｅｌｌは、ソーシャルバブルに対処するいずれのドライバからのコマンドも聞くことができる。さらに、ソーシャルバブル内のいずれのドライバも、Ｄｅｒｒｅｌｌによってコミュニティへ送られたコマンドを聞くことができる。結局のところ、Ｄｅｒｒｅｌｌは、いつの間にか別のドライバのＪｕｓｔｉｎとの１対１の会話の中にいる。この１対１の会話は自動的に識別することができて、ＤｅｒｒｅｌｌとＪｕｓｔｉｎの通信の音量は強調することができ、一方でソーシャルバブル内の他のドライバからの通信の音量は低下させることができる。代替策としては、ＤｅｒｒｅｌｌまたはＪｕｓｔｉｎは、サブカンバセーションに参加するように要求することができる。
【００３１】
一般の通信に加えてまたはその代わりに、ユーザは、ソーシャルバブル内で通信するための１人または複数のドライバを識別することができる。図５は、例として、特定の車両通信を容易にする工程６０を示すフローチャートである。ユーザは、口頭のスピーチなどを経由して、コマンドを提供する（ブロック６１）。コマンドは、車両ナンバープレート番号、車両形状もしくは車両型、カラー、ステッカー、ならびに製造元およびモデルなどの、車両識別子、または性別、ヘアーカラー、および年齢、ならびに車両占有期間などの、ドライバ識別子を含む。他の識別子が可能である。一実施形態において、コマンドは、ナンバープレート番号全部ではなくて、ナンバープレート番号のうちの最初の２つまたは３つのシンボルなどの、部分的な識別情報を含むことができる。識別コマンドの例には、「ゴールド色のカムリ」、「ＳＵＶ８２」、または「コンバーチブル、定員２名」を含むことができる。
【００３２】
識別情報がソーシャルバブル内の２つ以上の車両に当てはまるとき、口頭の要求がユーザへ提供されて、車両属性またはドライバ属性の区別をさらに提供することによって、可能性がある車両を明確にすることができる。識別情報を意味的に分析することが実行され、ソーシャルバブル内の車両と関連付けられたドライバのプロファイルと比較されて、分析された情報と整合する車両を識別することができる。車両カラーに関しては、一般に各ドライバは、異なるカラー知覚を有し、ブルー、ライトブルー、コバルトブルーまたはグリーンブルーなどの、過度のカラー区分を回避するために、強力なカラーの周囲をグループ化したカラーが採用されて、関連したカラーがいっしょにグループ化されるようにすることができる。例えば、ブルーについてのすべての相異なる変化形態は、ブルーの単一カラーとしてグループ化することができる。
【００３３】
ユーザのソーシャルバブルが分析されて、ユーザの記述と整合した車両を識別する（ブロック６２）。ユーザは、識別された車両と関連付けられた特定のドライバと直接に話すことができ、または最初に再検討され次いで特定のドライバへ口頭で提供されるコマンドを提供することができる。通信の種類は、ドライバ識別コマンドまたは車両識別コマンドの後にユーザからのコマンドが受信されるかどうかに基づいて決定することができる（ブロック６３）。さらにどんなコマンドも受信されない場合、ユーザは、ユーザによって指定された識別車両のドライバと直接に接続することができる（ブロック６４）。しかしながら、一実施形態において、通信の要求は、最初にドライバへ送信される。ユーザが直接に接続される前に、ドライバは、要求を受理しなければならない。要求が受理されない場合、ユーザは、ドライバと接続することができず、または以下で説明されるように間接的にコメントを提供することができる。
【００３４】
さらにコマンドが受信される場合、コマンドは分析されて、識別された車両と関連付けられたドライバへの配信用にコマンドが適切であるかどうかを決定することができる（ブロック６５）。コマンドが適切である場合、コマンドは配信することができる（ブロック６６）。代わりに、コマンドが適切でない場合、コマンドは、削除することができる（ブロック６７）。
【００３５】
上述した例に戻ると、ＤｅｒｒｅｌｌおよびＪｕｓｔｉｎが話しながら、別のドライバであるＤｏｍｙｎｉｃが、Ｄｅｒｒｅｌｌへ送られたコマンド「［ブラック色のアキュラ］私の車両を中に入れてくれてありがとう」を話す。ＤｅｒｒｅｌｌおよびＪｕｓｔｉｎがすでに会話に参加しているので、Ｄｏｍｙｎｉｃとの通信の要求がＤｅｒｒｅｌｌへ提供される。Ｄｅｒｒｅｌｌは、Ｊｕｓｔｉｎと話し終えていなくて、それゆえその要求を断り、このようにＤｏｍｙｎｉｃは直接にはＤｅｒｒｅｌｌへ接続されない。Ｄｏｍｙｎｉｃからのコマンドは、代わりに再検討されて妥当性を分析され、適切なときにＤｅｒｒｅｌｌへ口頭で配信される。当該コマンドは、Ｊｕｓｔｉｎとの会話中または会話後にＤｅｒｒｅｌｌに提供することができる。
【００３６】
ユーザと他のドライバとの通信を制御すると、ドライバ間における運転中の激怒やどんな否定的な感情でも防止するのに役立つ。当該通信は、ユーザなどの送信者からのコマンドを分析することによって制御されて、各コマンドが配信用に適切であるかどうかを決定することができる。図６は、例として、配信用コマンドの妥当性を決定する工程７０を示すフローチャートである。コマンドの内容が分析され、詳しくはコマンドの趣旨が内容に基づいて決定される（ブロック７１）。趣旨が肯定的である場合（ブロック７２）、コマンドは、適切であると決定されて（ブロック７６）、ユーザのソーシャルバブル内の車両と関連付けられた１人または複数のドライバへ配信される。肯定的コマンドは、提案、または注意喚起事項、ならびにトラフィックアップデートおよび事故レポートなど、ドライバに有用な情報を含むことができる。肯定的コマンドの例には、「［ホワイト色のトラック］が［レッド色のコンバーチブル６］に感謝する」または「［ホワイト色のトラック］が５番アベニューとユニオン・ストリートの交差点で事故を特定する、［全車両］は回り道をせよ」を含む。肯定的コマンドは、メッセージの送信者、メッセージの内容、およびメッセージの受信者を識別することができる。一方では、否定的、すなわち侮辱的、コマンドは、侮辱的であると受信者が見つけ出すことができる情報、または受信者に代わって怒りを起こさせる可能性のある、もしくは送信者の好ましくない印象を生み出す可能性のある情報を含む。否定的コマンドは、送信者の身元を保護するために、「［ブルー色のホンダ］が過度に低速で運転している」または「［ジープ］がテールゲートしている」などの、コマンドの受信者およびコマンドの内容の識別だけを含むことができる。
【００３７】
否定的コマンドは、有効化のため再検討される。否定的コマンドは、さらに以下で図７および図８を参照して詳細に説明されるように、コマンドの送信者またはコマンドの所期の受信者によって有効にすることができる。メッセージが有効にされる場合（ブロック７３）、コマンドは、適切であると決定され（ブロック７６）続いてソーシャルバブルと関連付けられた所期のドライバに配信することができる。代替策としては、コマンドが有効にされない場合、コマンドは、不適切であると決定される（ブロック７４）。不適切なコマンドが書き直されて（ブロック７５）、肯定的な観点で内容を書き替えかつどんな無礼な用語も除去することができる。コマンドを書き直すと、配信用に適切なメッセージを表すことができる（ブロック７６）。例えば、上述の識別された否定的コマンドは、「低速車線に移動していただけませんか？」または「車間距離をより広くするとあなたの安全性が改善されるでしょう」のように書き直すことができる。しかしながら、書き直されない場合、コマンドは、不適切な状態のままとなり、削除することができる。
【００３８】
上述した例に関しては、Ｄｏｍｙｎｉｃによって提供されたコマンドは、Ｄｅｒｒｅｌｌに感謝するコマンドの趣旨が肯定的であるので、適切であると決定される。しかしながら、追加のドライバ、Ｊａｆａｒは、次の通り「［ブラック色のアキュラ］が減速し、あなたの車両はテールゲートしている」にＤｅｒｒｅｌｌへ送られた口頭コマンドを提供する。Ｊａｆａｒからのコメントは、否定的であると解釈することができ、有効にされない。それゆえに、コマンドは、Ｄｅｒｒｅｌｌに「そのまま」配信するのは不適切である。テールゲート・コマンドが共通であるので、コマンドは、「［ブラック色のアキュラ］あなたの車両と別の車両の車間距離を増加させて、あなたの安全性を増加させてください」のように書き直されて、Ｄｅｒｒｅｌｌに録音メッセージとしてまたは音声生成メッセージとして口頭で提供することができる。
【００３９】
否定的内容が含まれるものの、コマンドは、有効にされるとき、依然として配信用に適切であることが可能である。コマンドは、送信者の評判または受信者の運転履歴に基づいて、有効にすることができる。図７は、例として、コマンドの送信者有効化用工程８０を示すフローチャートである。送信者の身元が決定される（ブロック８１）。送信者は、ユーザまたは送信者のソーシャルバブルと関連付けられた他の任意のドライバとすることができる。送信者のコマンド履歴が得られ、送信者によって予め提供されたコマンドが再検討されて（ブロック８２）送信者の評判を決定する（ブロック８３）。送信者の評判は、予め提供されたコマンドであって、適切であると決定されて所期の受信者へ配信されたコマンドの数に基づくことができる。例えば、良好なまたは信頼できる評判は、適切なコマンドのしきい値数と関連付けることができる。送信者の適切なコマンドがしきい値を満たすとき、送信者の評判は肯定的であると決定される。別のやり方では、しきい値が満たされない場合、送信者の評判は、追加のしきい値に基づいて中立または悪いとして決定することができる。
【００４０】
さらに加えて、送信者の評判は、送信者によって提供されたコマンドが他のユーザに有用であったかどうかに基づくことができる。コマンドの有用性は、コマンドの有用性のレベルに基づいて、受信者からの投票を受信する格付けシステムによって決定することができる。投票が多くなるにつれて、ますます送信者の評判が良好であると識別されそうになる。ユーザの評判が良好であると決定される場合（ブロック８４）、コマンドは、有効にされて（ブロック８５）所期の受信者に配信することができる。別のやり方では、ユーザの評判が良好でない場合、コマンドは、有効にされなくて（ブロック８６）配信されない。
【００４１】
送信者の有効化と対照的に、受信者の有効化は、コマンド受信者の運転履歴に基づく。図８は、例として、コマンドの受信者有効化用工程９０を示すフローチャートである。コマンドが分析されて、コマンドの内容が決定される（ブロック９１）。その内容は、送信者が所期の受信者に中継しようとするメッセージを含むことができる。続いて、受信者のコマンド履歴が得られる（ブロック９２）。コマンド履歴は、受信者によって予め送受信されたコマンドを含むことができ、データベースを経由してアクセスすることができる。現在のコマンドの内容は、コマンド履歴と比較されて、受信者によって受信された以前のコマンドが現在のコマンドの内容と類似しているかどうかを決定する。類似のコマンドが識別されている場合（ブロック９３）、類似のコマンドのしきい値数が、類似のコマンドに任意選択で適用することができる（ブロック９４）。類似のコマンドの数がしきい値を満たす場合、コマンドは有効にされる（ブロック９５）。しかしながら、類似のコマンドの数がしきい値を満たさない場合、コマンドは有効にされなくて（ブロック９６）削除することができる。
【００４２】
さらなる一実施形態において、コマンドは送信者有効化および受信者有効化の組合せに基づいて有効にすることができる。例えば、スコアまたは他の値が、送信者有効化および受信者有効化に個々に割り当てることができる。続いて、スコアは、合計して平均することができる。平均スコアが有効化しきい値を満たす場合、コマンドは有効にされる。別のやり方では、平均スコアがしきい値を満たさないとき、コマンドは有効にされない。例えば、上述したシナリオに戻ると、テールゲートに関するＪａｆａｒからのコマンドは、削除するのではなく分析して有効にすることができる。コマンドの有効化決定は、送信者有効化および受信者有効化に基づく。送信者有効化に関しては、送信者のコメント履歴、および詳しくは送信されるコマンドが再検討されて、Ｊａｆａｒが有用かつ建設的なメッセージを送信するかどうかを決定する。Ｊａｆａｒの送信されるコメント履歴に基づいて、０と１の間の値が割り当てられる。具体的には、Ｊａｆａｒのコメントの大略６０％が有用であると決定されて配信されたので、０．６の値が送信者有効化に関して割り当てられる。例えば、Ｊａｆａｒは、高速で運転することを好み、かつ過度に低速で進むドライバに関してたくさんのコメントを提供することもある、せっかちなドライバであるが、しかしながら、コメントは、否定的と解釈されて有効にされないことがあるので、配信されないこともある。さらなる一実施形態において、Ｊａｆａｒの評判の決定に直接に値を割り当てることができ、例えば、Ｊａｆａｒの評判が良好であると決定されるとき、１の値を割り当てることができ、Ｊａｆａｒの評判が良好でないとき、０の値を割り当てることができる。
【００４３】
受信者有効化に関して、Ｄｅｒｒｅｌｌのコメント履歴が得られて再検討される。これまで２週間、Ｄｅｒｒｅｌｌがテールゲートに関して他の３通のコメントを受信しているので、Ｄｅｒｒｅｌｌのコメント履歴に基づいて、Ｊａｆａｒのテールゲート・コマンドが有効にされる。多数の類似のコマンドが短期間に受信されたので、０．０８の値が割り当てられる。２つの有効化値の平均値は、０．７である。当該平均値に０．６５のしきい値が適用され、当該平均値はしきい値を満たし、結果的にＪａｆａｒのコマンドの有効化をもたらす。
【００４４】
コマンドがいったん適切であると決定されると、コマンドは受信者へ配信される。コマンドは、妥当性の決定に基づいて、予め定義された時間に、または受信者の認知負荷に基づいて、配信することができる。図９は、例として、受信者の認知負荷に基づいてコマンドを配信する工程１００を示すフローチャートである。認知負荷に基づいてメッセージを配信すべきかどうかを決定することは、同一出願人が所有する、発明の名称が「Ｓｙｓｔｅｍ  ａｎｄ  Ｍｅｔｈｏｄ  ｆｏｒ  Ｄｅｔｅｒｍｉｎｉｎｇ  ａｎ  Ａｐｐｒｏｐｒｉａｔｅ  Ｔｉｍｅ  ｆｏｒ  Ｐｒｏｖｉｄｉｎｇ  ａ  Ｍｅｓｓａｇｅ  ｔｏ  ａ  Ｄｒｉｖｅｒ」であり、事件番号第２０１３０８１０ＵＳ０１号、出願日が２０１４年１２月２３日である、米国特許出願第１４／５８１，９７５号明細書で、さらに詳細に説明される。最初に、受信者の認知負荷が計算されて（ブロック１０１）、コマンドの受信およびコマンドの受信によって引き起こされた動揺を受信者が現在処理することができるかどうかを決定する。受信者の認知負荷は、受信者の作業記憶へ課された活動の総量、それゆえに受信者の必要な心的処理の量を意味する。例えば、受信者の認知負荷が高いとき、受信者は、必要な心的処理が高い量であるために、コマンドの受信を処理することがそれほどできない。反対に、受信者の認知負荷が低いとき、受信者は、受信者によって必要となる処理がそれほどでないので、メッセージの検分をより良好に処理することができる。ドライバの認知負荷は、道路条件、センサ計器の示度および異常、ある特定の時間および位置における受信者の現在の運転状態を囲むもの、を含む多数の因子に基づくことができる。
【００４５】
さらに加えて、コマンドを提供するためのより良好な機会が将来存在するかどうかに関する決定（ブロック１０２）がなされる。具体的には、受信者の経路が決定され、当該経路を用いて、現在の時間よりも受信者にコマンドを提供するのにより良好な機会とすることができる位置であって、当該経路に沿った将来の位置を決定する。コマンドの重要性も決定されて（ブロック１０３）、メッセージが受信者に直ちに配信すべきかどうか、またはメッセージ配信がより良好な機会を待つことができるかどうかを識別するのに役立つ。コマンドの重要性は、コマンドが要求を含んでも提案された動作を含んでも、送信者の重要性に基づくことができ、およびコマンドを提供するのに必要な時間の長さに基づくことができる。コマンドの重要性を決定することは、同一出願人が所有する、発明の名称が「Ｃｏｍｐｕｔｅｒ−Ｉｍｐｌｅｍｅｎｔｅｄ  Ｓｙｓｔｅｍ  ａｎｄ  Ｍｅｔｈｏｄ  ｆｏｒ  Ｐｒｉｏｒｉｔｉｚｉｎｇ  Ｅｌｅｃｔｒｏｎｉｃ  Ｍｅｓｓａｇｅｓ  Ｂａｓｅｄ  ｏｎ  Ｉｍｐｏｒｔａｎｃｅ」であり、事件番号第２０１２０３３６ＵＳ０１号、出願日が２０１４年１２月２３日である、米国特許出願第１４／５７１，９４５号明細書で、さらに詳細に説明される。続いて、認知負荷因子、将来の機会因子、およびメッセージ重要性因子へ割り当てられた値に基づいて、配信決定スコアが計算される（ブロック１０４）。配信決定スコアにしきい値が適用され（ブロック１０５）、スコアがしきい値を満たす場合（ブロック１０６）、コマンドは配信される（ブロック１０７）。別のやり方では、スコアがしきい値を満たせない場合（ブロック１０６）、コマンドは追加の時間まで保持される（ブロック１０８）。
【００４６】
配信されようと、削除されようと、または受信されようと、すべてのコマンドは、ドライバのコマンド履歴内に録音することができる。ドライバのコマンド履歴に基づいて、レポートを生成してそのドライバに提供することができる。図１０は、例として、ドライバのフィードバックを有するレポート１１０を示すブロック図である。音声指向ソーシャルネットワークへ登録された各ドライバは、当該ドライバによって送受信されたコメントを要約するレポートを受信するように決めることができる。さらなる一実施形態において、レポートには、適切な、しかし配信されないコマンドを含むことができる。
【００４７】
レポートは、口頭メッセージ、電子メール、またはテキストを経由して、ならびに他の配信手段を経由して、連続した基準または所定の基準で、配信することができる。例えば、毎日の、毎週の、毎月の、または年４回の基準で、ならびに他の期間で、概要を受信するように決めることができる。レポート１１０は、レポートを生成するドライバ１１１の識別、ドライバ識別番号１１２、レポートがカバーする期間１１３、および当該期間中に送受信されるコマンド１１４の概要を含むことができる。
【００４８】
音声指向ソーシャルネットワークは、フェースブックなどの、他のソーシャルネットワークとも接続することができる。長いまたは興味深い会話をするドライバは、接触情報を交換することを望んでもよく、それゆえ後日再び通信することができる。さらに加えて、ユーザのソーシャルバブルの範囲内のドライバは、１人または複数のユーザの友人と友人になることができる。フェースブックまたは別のソーシャルネットワーク上で接続するユーザおよびドライバへの提案は、友人の友人または類似の特徴を有する別のドライバなどに基づいて、自動的に行うことができる。
【図１】
0006730802.tif 000002
【図２】
0006730802.tif 000003
【図３】
0006730802.tif 000004
【図４】
0006730802.tif 000005
【図５】
0006730802.tif 000006
【図６】
0006730802.tif 000007
【図７】
0006730802.tif 000008
【図８】
0006730802.tif 000009
【図９】
0006730802.tif 000010
【図１０】
0006730802.tif 000011