JP2014123239A - 渋滞情報配信システム、サーバ、車載端末、及びプログラム - Google Patents

Abstract

【課題】
道路ＩＴインフラシステムによる情報に頼らず、交通渋滞の渋滞原因となる事象を早期に特定し通知することができる渋滞情報配信システム、サーバ、車載端末、および、プログラムを提供する。
【解決手段】
車載端末２０は、車両の走行状態に基づき渋滞に巻き込まれていることがわかると、車内の運転者や同乗者が発した音声を録音した音声データを解析し、キーワード、感情、音声の変化等により特徴的な音声を検知したら、渋滞情報配信サーバ１０に前記音声データを送信する。渋滞情報配信サーバ１０は、前記音声データから渋滞原因に関連するキーワードを抽出し、関連する渋滞情報において渋滞原因の集計を取り、ある渋滞原因キーワードの集計値が閾値を超えると、渋滞原因を前記渋滞原因キーワードに決定する。
【選択図】図１

Description

本明細書で開示される主題は、自動車の運転に係る情報を生成し、関連するユーザに対して当該情報を配信するシステム、及び、それに用いるサーバ、車載端末、プログラムに関する。

道路の渋滞情報を検知及び報知するシステムの例として、道路に設置されたセンサ（カメラ、トラフィックカウンタ等）から収集されるデータや、各車両から携帯網や路側機経由の通信により収集された車両走行データ（プローブデータと一般的に呼ばれる）を活用して、道路状況を推測、渋滞情報を生成及び配信するシステムが存在する。これらは、対象とする道路上の車両の走行状態を把握することにより、渋滞情報を検知している。いろいろな原因により発生する渋滞のうち、道路形状により発生する渋滞に係る渋滞情報は、プローブデータなどの情報を参照することにより、生成することができるし、その原因も推定できる可能性が高い。

一方、道路形状に依存しない、非日常的な原因による渋滞に関しては、プローブデータなどの情報を参照するシステムでは、渋滞の状態は認識できても、渋滞の原因を知ることは難しい。ドライバは、自分が向かう方向の道路の渋滞状況を認識することができるが、渋滞の原因がわからないと、今後どのように渋滞の状態が推移していくか推測することが困難のため、渋滞に対してどのように行動を取るべきか判断に困るという問題がある。

特許文献１は、この問題を解決するため、渋滞を引き起こしそうなイベント情報（花火大会等）をあらかじめ入力しておき、交通情報センタ等からの渋滞情報と渋滞履歴情報の比較により非日常的な渋滞を検知したときに、前記イベント情報と照らし合わせて渋滞原因であるかどうかを決定し、ユーザに通知することを開示する（段落0006）。

特許文献２は、この問題を解決するため、非日常的な渋滞を検知したときに、インターネット上を時間情報や位置情報、所定の検索項目に基づき検索することにより、渋滞原因を推定することを開示する（段落0014）。

特許第4259404号公報 特開2009-75981号公報

上述した特許文献１の場合、渋滞原因を究明するためには、あらかじめ渋滞情報の提供側でイベント情報を把握し入力しておかなければならないため、把握が漏れていると渋滞原因を究明することができないという問題があった。また、事前に予定がわからない突発的なイベント（事故、天候、またはゲリラライブ等）による渋滞の場合、原因を特定することができないという問題があった。

上述した特許文献２の場合、インターネット上の情報を対象に検索しているため、無数のコンテキストの情報が入り混じっており、渋滞原因とは無関係の内容が検索結果に反映される可能性が高い。そのため、渋滞原因を誤って推測する確率が高くなるという問題があった。また、事前に予定がわからない突発的なイベントによる渋滞の場合は、検索時にインターネット上に情報が反映されていない可能性が高く、やはり原因を特定することが難しいという問題があった。

なお、従来構成においても、高速道路や主要道路等の道路ＩＴインフラシステムが整備されている箇所では、道路表示板、ラジオ、または近距離無線システム経由で道路交通情報センタ（道路交通情報を収集し、道路利用者にメディアを通して提供する機関）から提供される道路工事、道路規制、または事故等の情報から、運転者が渋滞の理由を推測することは可能だった。

しかし、提供される情報は道路交通情報センタ側で取得可能な範囲の情報であり、かつ、交通渋滞と渋滞原因を手動で紐づけて配信される情報であるから、特定できる渋滞原因に限度がある上、渋滞原因のイベント発生後から配信されるまでの時間に遅延があった。これにより、渋滞原因がわからなかったり、渋滞原因が判明した頃には渋滞に巻き込まれていたり、するという問題があった。また、このような道路ＩＴインフラシステムが整備されていない場所では、渋滞原因を知りえないという問題があった。

そのため、渋滞原因となる事象を早期に特定し通知することができる技術が求められている。

開示されるのは、道路ＩＴインフラシステムに頼らず、交通渋滞の渋滞原因となる事象を早期に特定し、配信することができる渋滞情報配信システム、サーバ、車載端末、および、プログラムである。

開示される渋滞情報配信システムは、車両に搭載された車載端末と、車載端末と通信手段を持つ渋滞情報配信サーバと、を備えている。

車載端末は、車両外にあるサーバ装置と接続するための通信部と、を備え、車両内で発せられた音声から音声データを取得する音声データ取得部と、発声時点付近の、車両の状態に関する車両状態データを取得する車両状態データ取得部と、取得された車両状態データを用いて、音声が発せられたコンテキストを決定するコンテキスト決定部と、取得された音声データを用いて、音声データの取得元である音声が、コンテキスト決定部により決定されたコンテキストにおける、特徴的な音声であるかを判定する特徴的音声判定部と、特徴的と判定された音声から取得された音声データを含むメッセージを、サーバ装置に送信するデータ送信部と、を備えることを特徴とする。

サーバは、車載端末から、音声データと車両状態データとを含むメッセージを受信するデータ受信部と、メッセージに含まれる車両状態データに基づいて、車両が渋滞の中に位置しているかどうかを判定するコンテキスト判定部と、コンテキスト判定部において車両が渋滞の中に位置していると判定された場合に、同一のメッセージに含まれる音声データに基づいて渋滞原因を決定する渋滞原因決定部と、決定された渋滞原因を、当該渋滞に関連する車両へ配信する渋滞情報配信部と、を備えることを特徴とする。

上記態様によれば、交通渋滞の渋滞原因となる事象が、非日常的なものであっても、その事象を早期に特定し通知することができるため、運転者による効果的な早期渋滞回避を可能にする。特に、道路ＩＴインフラシステムが整備されていないエリアや道路においても、渋滞原因となる事象を特定することができるため、道路ＩＴインフラシステムの整備状況に依存せずにサービスを提供することが可能となる。

開示によれば、渋滞原因となる事象が非日常的なものであっても、その事象を早期に特定可能となる。

一実施形態における渋滞情報配信システムの構成を例示する図である。 一実施形態における渋滞情報データ群の構成例を示す説明図である。 一実施形態における渋滞原因集計データ群の構成例を示す説明図である。 一実施形態（実施例１）における渋滞情報配信システムの動作を例示するシーケンス図である。 一実施形態における車載端末での音声データ処理時の動作を例示するシーケンス図である。 一実施形態における車載端末での特徴的音声判定処理時の動作を例示するシーケンス図である。 一実施形態におけるメッセージのフォーマットを例示する説明図である。 一実施形態における渋滞情報配信サーバでの渋滞コンテキスト判定処理時の動作を例示するシーケンス図である。 一実施形態における渋滞情報配信サーバでの渋滞コンテキスト処理時の動作を例示するシーケンス図である。 一実施形態における渋滞情報配信サーバでの渋滞原因決定処理時の動作を例示するシーケンス図である。 一実施形態における渋滞情報メッセージのフォーマットを例示する説明図である。 一実施形態における車載端末での渋滞情報通知処理の一例である渋滞情報表示方法を示す説明図である。 一実施形態（実施例２）における車載端末での音声データ処理の動作を例示するシーケンス図である。

以下、図面を参照して、実施例について説明する。

図１は、本実施形態による渋滞情報配信システムの構成図の一例である。図１に示すように、本実施形態に係る渋滞情報配信システム１は、例えば、１台以上の車両２に渋滞情報を提供する渋滞情報配信システムであり、渋滞情報を提供する渋滞情報配信サーバ１０と、車両２に搭載された車載端末２０と、ネットワーク３と、を含んで構成される。

渋滞情報配信サーバ１０は、例えば、テレマティクスサービスを提供するテレマティクスセンタのサーバ、道路交通情報センタのサーバ、等であり、処理部１００と、記憶部１１０と、通信部１２０と、を有する。

処理部１００は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ：中央演算処理装置）やＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などを含んで構成され、所定の動作プログラムを実行することで、渋滞情報配信サーバ１０の機能を実現する処理を行う。また、処理部１００には、機能ブロックとして、車両２から受信したデータを処理するデータ受信部１０１、車両から受信したデータのコンテキストを判定するコンテキスト判定部１０２、車両から受信した音声データを解析する音声データ解析部１０３、渋滞原因を特定する処理を行う渋滞原因決定部１０４、渋滞原因決定部１０４で決定した渋滞原因の位置情報を特定する処理を行う渋滞原因位置決定部１０５、複数の車両２の車両状態データ等を用いて渋滞情報を生成する処理を行う渋滞情報生成部１０６、特定した渋滞原因及び渋滞原因位置を含む渋滞情報を１台以上の車載端末２０に配信する渋滞情報配信部１０７、等が含まれる。

記憶部１１０は、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、フラッシュメモリ、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）などの記憶装置を含んで構成され、処理部１００が実行する動作プログラム（非表示）や、本システムの実現に必要なデータ群などが格納される。本実施形態では、特に、渋滞情報データ群１１１、渋滞原因集計データ群１１２、渋滞原因キーワードデータ群１１３、等が格納される。

通信部１２０は、例えば、Ｅｔｈｅｒｎｅｔ（登録商標）などの有線ＬＡＮ規格に準拠したネットワークカードなどを含んで構成され、ネットワーク３にアクセスして、例えば、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）系の各種プロトコルなどに基づいて生成されたデータの送受信を行う。なお、ネットワーク３との接続形態は、Ｅｔｈｅｒｎｅｔのような有線接続に限定されることはなく、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）などの近距離無線接続であってもよいし、携帯電話の通信システムのような長距離無線接続であってもよい。

ネットワーク３は、無線および／または有線を媒体とする回線交換網やパケット交換網の任意の組み合わせで構成される通信ネットワークであり、渋滞情報配信サーバ１０と車載端末２０が相互にデータを送受信可能なように構成されている。

車載端末２０は、例えば、車両２に設置される、もしくは車両２内に位置し、所定の通信方法により車両外部と接続可能に構成される、テレマティクス通信装置、ナビゲーション装置、携帯電話（スマートフォンと呼ばれる高機能通信端末を含む）、またはタブレット端末、等であり、処理部２００と、記憶部２１０と、通信部２２０と、入出力部２３０を有する。

処理部２００は、例えば、渋滞情報配信サーバ１０の処理部１００と同様の装置で構成され、所定の動作プログラムを実行することで、車載端末２０の機能を実現する処理を行う。また、処理部２００には、機能ブロックとして、音声入出力部２３２経由でマイク２５３から入力された音声データを取得する音声データ取得部２０１と、例えば、音声認識、感情認識、発声者認識、等の音声データを解析する処理を行う音声データ解析部２０２と、音声データのコンテキストを決定するコンテキスト決定部２０３と、コンテキスト決定部２０３により決定されたコンテキストにおいて音声データが特徴的な音声に該当するかどうかを判定する特徴的音声判定部２０４と、車内ＬＡＮ入出力部２３３経由で車内ＬＡＮ２５４から入力された車両状態データを取得する車両状態データ取得部２０５と、渋滞情報配信サーバ１０に音声データを送信するデータ送信部２０６と、渋滞情報配信サーバ１０から渋滞情報を受信する渋滞情報受信部２０７と、受信した渋滞情報をディスプレイやスピーカに出力して運転者や同乗者に通知する渋滞情報通知部２０８と、等が含まれる。

記憶部２１０は、例えば、渋滞情報配信サーバ１０の記憶部１１０と同様の装置で構成され、処理部２００が実行する動作プログラム（非表示）や、本明細書で開示するシステムの実現に必要なデータ、例えば、車両状態データ群２１１、音声データ群２１２、音声処理パラメータデータ群２１３、などが格納される。

通信部２２０は、例えば、渋滞情報配信サーバ１０の通信部１２０と同様の装置で構成され、ネットワーク３にアクセスして、渋滞情報配信サーバ１０とデータの送受信を行う。

入出力部２３０は、車載端末２０に接続される他の装置との入出力を実現するように構成されており、例えば、ディスプレイ２５１との入出力処理を行う画面入出力部２３１、スピーカ２５２やマイク２５３との音声入出力処理を行う音声入出力部２３２、ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）等の車載ネットワークと接続し車載ネットワークに流れる車両データの受信処理を行う車内ＬＡＮ入出力部２３３、等が含まれる。

マイク２５３は、例えば、車両のハンドル付近などに設置され、運転者や同乗者の会話が録音できるようになっている。あるいは、マイク２５３は、車両外に設置され、車両外部の音声を録音できるようになっていてもよいし、車内外に複数個設置されていてもよい。図１では、ディスプレイ２５１、スピーカ２５２、マイク２５３が車載端末２０の外部に接続されているが、車載端末に内蔵されても良い。

渋滞情報配信サーバ１０の渋滞情報データ群１１１は、渋滞情報生成部１０６により生成、管理される渋滞情報データエントリの集合であり、例えば、図２のような構成になっている。

本明細書では、一つ以上の異なるデータで構成される一つの集合をエントリという。

渋滞ＩＤ３０１は、渋滞を識別するための識別子（ＩＤ）である。道路情報３０２は、渋滞している一つ以上の道路の情報を示す。図２では、道路を表すデータ構造の一例として、地図データにおける道路リンク（ノードＩＤのペア）情報を用いている。

どの道路が渋滞しているかの判定は、渋滞情報生成部１０６により実現される。本実施例では記載していないが、渋滞情報生成部１０６は、道路交通情報センタ等の道路インフラ事業者が生成した渋滞情報を取得することにより道路情報３０２を生成しても良いし、車両２から定期的に車両状態データ（プローブデータ）を取得し車速や加速度等の情報を解析することにより生成しても良い。

渋滞原因３０３は、該当する渋滞が発生している原因を表している。すでに、渋滞原因決定部１０４により渋滞原因が決定されている場合は、「交通事故」等特定の渋滞原因を表すテキストデータが格納される。まだ決定されていない場合は「不明」等、未決定であることを表すデータが格納される。渋滞原因位置３０４は、渋滞原因３０３の位置情報が格納される。位置情報としては、例えば、道路リンク、緯度、及び経度の組み合わせで表現される。渋滞原因位置３０４は、渋滞原因位置決定部１０５により決定され、決定されている場合は特定の位置情報が、決定されていない場合は「不明」等、未決定であることを表すデータが格納される。

渋滞情報配信サーバ１０の渋滞原因集計データ群１１２は、渋滞原因決定部１０４がある渋滞情報の原因を特定する過程で用いられるデータエントリの集合であり、例えば、図３のような構成になっている。

渋滞ＩＤ３１１は、渋滞を識別するためのＩＤで、渋滞情報データ群１１１の渋滞ＩＤ３０１に対応する。登録済車両ＩＤ３１２は、当該渋滞ＩＤの渋滞に関する渋滞原因キーワードの集計に登録済の車両ＩＤの集合である。渋滞原因キーワード３１３は、当該渋滞ＩＤの渋滞の原因候補として登録、集計されているキーワードである。カウンタ３１４は、各渋滞原因キーワード３１３に対するその時点での集計値を表す。

渋滞情報配信サーバ１０の渋滞原因キーワードデータ群１１３は、渋滞原因決定部１０４が音声データから渋滞原因に相当するキーワードを抽出するためのデータエントリの集合であり、渋滞原因に関連性のあるキーワードが登録されている。例えば、「交差点」「合流」「サグ（下り坂から上り坂にさしかかる凹部）」「対向車線横断時の待機（右折待ちなど）」等の渋滞を引き起こす道路形状に関連するキーワードや、「事故」「工事」「故障」等の車両や道路のイベントに関連するキーワードや、「祭り」「花火」または「アウトレット」等の地域イベントに関連するキーワードが含まれる。

車載端末２０の車両状態データ群２１１は、当該車両の状態に関する車両状態データエントリの集合であり、１エントリ毎に、車内ＬＡＮ入出力部２３３経由で取得された当該車両のセンサ、ＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）、アクチュエータ等の任意の一つ以上の車両の状態に係るデータが、それぞれ、取得時刻と関連付けられて記録される。好ましくは、車両状態データ取得部２０５が、当該センサ、ＥＣＵ、アクチュエータの任意の一つ以上から情報を繰り返し（たとえば定期的に）取得し、取得時刻と関連付けて記録する。

また、例えば、１エントリは、時刻をキーとする複数種類のデータ、例えば、ある時刻での、車両位置、速度、加速度のいずれか二つ以上を含む。記録される対象としては、例えば、車両の位置、速度、加速度、角加速度、進行方向、アクセル開度、ブレーキ開度、インジケータ、シフトレバーの位置、等の任意の一つ以上が含まれる。

なお、車両状態データ群２１１に格納されるデータは、車内ＬＡＮ２５４経由で取得しなくても構わない。車載端末２０に搭載されているセンサ情報や、接続している他の装置から取得したデータが含まれてもよい。例えば、車内ＬＡＮ２５４と接続している、車両の位置を測位するためのＧＮＳＳ（Ｇｌｏｂａｌ Ｎａｖｉｇａｔｉｏｎ Ｓａｔｅｌｌｉｔｅ Ｓｙｓｔｅｍ）受信装置から、車内ＬＡＮと接続していて車内ＬＡＮ経由で車両位置を取得しても良いし、携帯電話等の他の端末に搭載されているＧＮＳＳ受信装置から取得しても良い。

車載端末２０は、車両状態データ取得部２０５により取得した情報を、記憶部１１０の記憶容量が許す限り保存してもよいし、一定期間経過すると削除しても良いし、渋滞情報配信サーバ１０を例とした他の装置に転送した時点で削除しても良い。

車載端末２０の音声データ群２１２は、マイク２５３から入力された運転者及び同乗者の音声を録音した音声データエントリの集合であり、録音時刻と関連付けられて格納される。録音については、音声入出力部２３２を、無音状態のときもすべて録音して記録するように構成しても良いし、音声を認識したときだけ録音して記録するように構成しても良い。１エントリに含まれる音声データの長さに、制限を設けなくても良いし、最大長を決めて複数エントリに分割しても良い。

車載端末２０の音声処理パラメータデータ群２１３は、パラメータデータエントリの集合であり、各エントリは、処理部２００の各種音声処理に必要となる一つ以上の各種パラメータを含む。

続いて、渋滞情報配信システム１の動作について説明する。

図４は、渋滞情報配信システム１の処理フローを表している。図４の左上のフローは、車載端末２０が音声データを渋滞情報配信サーバ１０に送信する処理のフローを示している。図４の右のフローは、渋滞情報配信サーバ１０が音声データを受信したときの処理フローを示している。図４の左下のフローは、車載端末２０が渋滞情報配信サーバ１０から渋滞情報を受信したときの処理フローを示している。以下、図４の左上のフローから順番に説明していく。

車両２に搭載された車載端末２０では、車内の音声を録音するかどうかのモードを設定できるようになっている。これは、例えば、記憶部２１０に音声録音モードを判定するためのデータが格納されており、車載端末２０に搭載されているディスプレイ２５１等を用いて運転者や同乗者が入出力部２３０経由で手動により設定できるようになっていてもよいし、遠隔にある他のシステムやアプリケーションから通信部２２０を経由して設定できるようになっていてもよい。また、音声録音モードを指定するための、手動で物理的に切替が可能なスイッチが車載端末２０に搭載されていてもよい。

まず、全体フロー５００では、音声データ取得部２０１が、ステップ５０１において、音声録音モードが有効になっているか確認する。もしも、音声録音モードが無効の状態だった場合（ステップ５０１でＮｏ）で、音声録音を開始していた場合は、音声録音を停止し、車載端末２０は処理を終了する。音声録音モードが有効になっている場合は（ステップ５０１でＹｅｓ）、音声録音を開始していなければ音声録音を開始する。すでに音声録音が開始されていたら、そのまま音声録音を継続する。続いて、ステップ５０２においてマイク２５３からの音声入力があるかをチェックする。

ここでの音声入力のチェックとは、例えば音声データと認識できる入力があるかどうかのチェックである。もしも、雑音しか入力されておらず、音声データとして認識できない場合は（ステップ５０２でＮｏ）、ステップ５０１に戻る。一方、認識できる音声データが入力された場合は（ステップ５０２でＹｅｓ）、音声データ取得部２０１が該音声データを取得し、次の音声データ解析部２０２による音声データ処理５０３に進む。

このとき、音声データとは、音声データ取得部２０１が音声入力の録音データを所定の方式により区切ったものである。例えば、音声入力が一定時間以上ない（入力が雑音のみ）ことを契機に区切っても良いし、データ長が一定時間を超えないように区切っても良いし、その両方の組み合わせにより区切っても良い。あるいは、音声入力の録音データを区切ることはせず、そのままストリームデータとして、音声データ解析部２０２による音声データ処理５０３に渡しても良い。

図５を用いて、音声データ解析部２０２による音声データ処理５０３について説明する。音声データ解析部２０２は、まずステップ６０１で入力された音声データを取得し、続いてステップ６０２において、車両状態データ群２１１を検索し、音声入力があった時点（すなわち発声時点）付近（好ましくは、音声入力があった時点の前後それぞれの所定の時間内）の車両状態データを取得する。次の、コンテキスト決定処理（ステップ６０３）は、コンテキスト決定部２０３が、取得された音声データは、どのようなコンテキストで運転者もしくは同乗者が発声したものであるか、を解析する処理である。

ここでコンテキストとは、車両２もしくは運転者や同乗者が置かれている状況を意味しており、本実施例の渋滞情報配信システム１では、音声データを活用して渋滞原因を特定することを目的としているため、抽出したいのは車両２が渋滞に関与している時点の音声データとなる。そのため、渋滞というコンテキスト（以下、渋滞コンテキストという）に車両２が置かれているかどうかを判定する。

この渋滞コンテキストは、飽くまで一例であり、他の提供サービスに応じて、さまざまなコンテキスト（例えば、停車中、故障中、または電話中等）が定義され、コンテキスト決定処理の中に定義されたコンテキストを判定するための処理が含まれてもよい。

渋滞コンテキストを判定する処理としては、車両状態データを利用する。例えば、速度情報において一定時間低速状態が続いた場合は、渋滞の中にいると判定することができる。例えば、加速度情報において急減速状態が発生した付近（急減速状態の発声前後それぞれの所定の時間）でインジケータが点滅（ハザードランプが点灯）した場合は、渋滞の入口（最後尾または開始地点とも称す）付近に位置すると判定することができる。例えば、速度情報において一定時間以上低速状態が続いた後に、加速度情報において加速状態となり、一定時間速度情報がある閾値を超えたまま保持された場合は、渋滞の出口（先頭または終了地点とも称す）付近に位置すると判定することができる。また、車両状態データだけでなく、道路情報等と組み合わせてもよい。道路の制限速度情報や信号機の有無等を合わせて用いることで、当該車両が渋滞中に位置しているかどうかを、より精度良く判定することが可能となる。また、渋滞情報配信サーバ等、ネットワーク３経由で取得した渋滞情報と、当該車両の位置を比較することにより、渋滞中に位置しているかを判定してもよい。

ステップ６０３でコンテキストが判定されると、特徴的音声判定部２０４は、特徴的音声判定処理（ステップ６０４）を実行する。すべての音声データを渋滞情報配信サーバ１０に送信してしまうと、渋滞情報配信サーバ１０が不要な音声データに対しても解析することになり、大量の車両による音声データの送信が集中した際に、処理能力が追い付かなくなる可能性がある。そこで、車載端末２０側で、コンテキストに応じて、不要な音声データはできる限り送信しない方が望ましい。この「音声データを送信すべきか否か」を判定する処理が、特徴的音声判定処理である。

図６を用いて、特徴的音声判定処理を説明する。

特徴的音声判定部２０４は、まず、判定したコンテキストに対応する音声処理パラメータを音声処理パラメータデータ群２１３から取得する（ステップ６１０）。音声処理パラメータを参照し、当該コンテキストにおける特徴的音声判定モードを決定する（ステップ６１１）。特徴的音声判定モードとしては、例えば、音声データの内容の特徴から判定する内容解析判定モード、音声データの音声に含まれる感情的特徴から判定する感情解析判定モード、音声データにおける音声のトーン、音量、またはタイミングそれぞれの変化の特徴、あるいは任意の一つ以上の組み合わせの変化の特徴から判定する音声変化解析判定モード等が考えられる。

内容解析判定モードの場合は（ステップ６１２でＹｅｓ）、音声データに対して音声認識処理を施し（ステップ６２０）、テキスト化した音声データをキーワード分解し（ステップ６２１）、その中に当該コンテキストの特徴的なキーワードが含まれるかを確認する（ステップ６２２）。コンテキスト毎の特徴的キーワードは、音声処理パラメータデータ群２１３に格納されている。もしも、特徴的キーワードが含まれていた場合は、当該音声データを特徴的音声と判定し（ステップ６３０）。そうでなければ、非特徴的音声と判定し（ステップ６３１）、処理を終了する。

ステップ６１２に戻り、特徴的音声判定モードが、内容解析判定モードではなく、感情解析判定モードであった場合（ステップ６１３でＹｅｓ）、まず、音声データに対して感情解析処理を実行する（ステップ６２５）。感情解析処理とは、音声の速度、強さ、間隔、抑揚等の各種パラメータを分析することで、音声に含まれる怒り、驚き、苛立ち、または疑問等の感情を認識する処理のことである。次に、感情解析処理６２５で認識された感情タイプと、当該コンテキストが対象とする感情タイプとが合致するかをチェックする（ステップ６２６）。もしも、合致した場合は、特徴的音声と判定し（ステップ６３０）、合致しなかった場合は非特徴的音声と判定し（ステップ６３１）、処理を終了する。例えば、運転者は渋滞の原因が判明した際、「あ、事故だ！」、「なんだ、道路工事やっていたのかよ…」、「へぇ、アウトレットがオープンしていたんだ！」などのように、驚き、怒り、または苛立ちを伴って、渋滞原因を発声する場合が多い。そのため、渋滞コンテキストにおいては、例えば、対象感情として驚き、怒り、または苛立ちなどを設定しておくと、渋滞原因を表す発声を抽出できる可能性を高めることができる。

ステップ６１３に戻り、特徴的音声判定モードが、内容解析判定モードでも感情解析モードでもなく、音声変化解析判定モードの場合（ステップ６１４でＹｅｓ）、まず、音声データに対して発声者識別処理を実行する（ステップ６１５）。

発声者識別処理とは、声から個人を識別する処理のことであり、音声から特徴量を抽出して、照合することにより実現される。ただし、このステップでの発声者識別処理は、特定の個人を認証することが目的ではなく、車内に複数人存在する場合に発声者を識別して各個人における音声変化を抽出することが目的である。そのため、必ずしも精度の高い発声者識別処理を実行する必要はない。

例えば、過去に録音されたもしくは現在進行中の音声データを解析し、発声者の声のトーン（周波数）や音量等の特徴量パラメータを抽出しておく。通常時に発声者から発せられた音声データを取得し、解析しておけば、同一の発声者からは同様な特徴量パラメータを抽出できるため、それを統計的に解析することで、その発声者の特徴を表す統計的な特徴量パラメータを抽出することが可能となる。統計的な特徴量パラメータには、例えば、特徴量パラメータの平均値、分散、標準偏差等が含まれる。

車内に複数人が存在していた場合は、例えば、クラスタリング（クラスター分析）等の解析にかけることによって、同一の発声者から発せられた音声データ毎に分類することが可能であり、さらにそれぞれの発声者毎に統計的な特徴量パラメータを算出することが可能となる。これにより、新たに発せられた音声データの特徴量パラメータを、各個人の統計的な特徴量パラメータと比較することによって、発声者を識別することが可能となる。

発声者が識別されると、ステップ６１６、６１７、６１８において、音声の特徴的な変化（トーン、音量、間隔等の任意の一つ以上の変化）を確認する。もしも、声のトーンが通常よりも高かったり（ステップ６１６でＹｅｓ）、声の音量が通常よりも大きかったり（ステップ６１７）、前回の発声から一定時間以上経過していたり、した場合は、特徴的音声と判定して（ステップ６３０）、処理を終了する。

一方、特に音声の特徴的変化が確認されなかった場合は、非特徴的音声と判定して（ステップ６３１）、処理を終了する。なお、声のトーンや音量が通常と異なるかどうかは、各パラメータに対する平均値、分散、標準偏差等の統計的情報を任意の一つ以上用いて判定されることが望ましい。

音声の変化には、発声者の感情が反映されていることが多い。そのため、音声の変化を検知することにより、感情が表面化された部分の発声を抽出することが可能である。その点、感情解析モードとも近いが、感情解析モードでは表面化した感情を特定してから特徴的音声かどうかを判定しているのに対し、音声変化解析判定モードでは、どのような感情かは特定せずに、感情が表面化した部分を一括りに特徴的音声と判定する点で異なる。そのため、感情解析モードの方が精度良く対象とする音声データを抽出できるという利点があるが、音声変化解析判定モードにも感情解析モードと比較して単純な処理で実現できるという利点がある。

ステップ６１４に戻り、特徴的音声判定モードが、いずれでもない場合、その他の判定モード処理を実行して（ステップ６３２）、処理を終了する。

なお、ここでは内容解析判定モード、感情解析判定モード、音声変化解析モードの３つを例として挙げたが、いずれか一つだけでも良いし、複数を組み合わせても良い。

図５の音声データ処理５０３の処理フローに戻る。特徴的音声判定処理６０４の結果、特徴的音声と判定された場合（ステップ６０５でＹｅｓ）、特徴的音声判定部２０４は、該当する音声データを切り出す処理を実行する（ステップ６０６）。音声データは、比較的長い時間に渡り録音されたデータである場合もあり、複数の発声が混在していることもある。その場合は特徴的音声と判定された発声部分だけ切り出す処理が必要となる。

特徴的音声判定部２０４が該当音声データを切り出すと、続いて、データ送信部２０６が送信データを生成する処理を行う（ステップ６０７）。本実施例で対象とする渋滞コンテキストの場合、送信データには、少なくとも、音声データ、音声データが録音された時刻情報、時刻情報に関連する位置情報等の車両状態データを含む。それに加えて、渋滞情報配信サーバ１０が、車両２の識別に必要となる車両ＩＤ、コンテキストの識別に必要となるコンテキストフラグも含まれる。なお、送信データに含まれる情報は、コンテキストに応じて異なってもよい。送信データ生成処理６０７を実行すると、音声データ処理５０３は終了する。

一方、ステップ６０５にて特徴的音声と判定されなかった場合は（ステップ６０５でＮｏ）、そのまま処理を終了する。

図４の渋滞情報配信システム１の処理フロー５００に戻る。音声データ処理５０３の結果、送信データが生成されていた場合（ステップ５０４でＹｅｓ）、データ送信部２０６は、メッセージ送信処理（ステップ５０５）を実行する。メッセージ送信処理では、送信データ生成処理６０７で生成された送信データを、所定フォーマットのメッセージに変換して、渋滞情報配信サーバ１０に送信する。

図７は、メッセージのフォーマット（７００）の一例を示している（ただし、通信プロトコルに関係するヘッダ情報は割愛）。車両ＩＤ７００は、車両２を識別するユニークな識別子が入る。これにより、渋滞情報配信サーバ１０が、車両２を識別することが可能となる。コンテキストフラグ７０２は、コンテキスト決定処理６０３で決定されたコンテキストの情報を示すフラグが入る。例えば、各ビット位置によってコンテキストの種別（例えば、渋滞コンテキスト）が割り当てられており、もしもそのコンテキスト種別が有効の場合は該当ビットに１がセットされる。これにより、一つの音声データに対し、複数のコンテキストを同時に指定することが可能となる。なお、車載端末側でコンテキスト処理が実施されない場合も考えられ、コンテキストが「不明」であることを示すフラグを用意してもよい。

音声データ時刻情報７０３には、音声データ７０４が対応する音声開始時刻と音声終了時刻が含まれる。車両状態データ７０５には、音声データ時刻情報７０３で示された時刻の期間、もしくはその前後を含んだ期間の車両状態データが含まれる。車両状態データ７０５には、データセット数７１１で示された数だけ、時刻７１２で示された時点の車両状態データのセットが含まれる。

車両状態データとしては、車両２の位置情報７１３、速度情報７１４、等が含まれる。なお、位置情報７１３は、ＧＮＳＳにより測位された、もしくはその値をベースに他センサ情報を用いて補正した緯度、経度の情報でも良い。また、その緯度、経度を地図データの道路リンク情報と照合することで車両２が走行している可能性が最も高い道路情報（走行道路情報）を取得し、走行道路情報（道路のリンクＩＤ等）を位置情報７１３がさらに含んでも良い。

車載端末２０は、音声データ送信処理５０５を終えると、ステップ５０１に戻り、これまでに説明した一連の処理を繰り返す。

車載端末２０の音声データ送信処理５０５において、送信データに含まれて送信された音声データは、渋滞情報配信サーバ１０によって受信される。渋滞情報配信サーバ１０のデータ受信部１０１は、音声データ受信処理を行い（ステップ５１０）、メッセージフォーマット７００に従って各種情報を取得する。続いて、コンテキスト判定部１０２は、コンテキスト判定処理を実行し（ステップ５１１）、受信した音声データが渋滞に関連するものであるかを判定する。

図８を用いて、コンテキスト判定処理５１１を説明する。

まず、コンテキスト判定部１０２は、受信したメッセージのコンテキストフラグ７０２を参照し、コンテキストが「渋滞コンテキスト」もしくは「不明」であるかを確認する（ステップ８０１）。もしも、別のコンテキストが指定されていた場合は（ステップ８０１でＮｏ）、車載端末２０によりすでにコンテキストが解析されているため、渋滞コンテキストではないと判定し（ステップ８２０）、処理を終了する。

一方、ステップ８０１でＹｅｓの場合、メッセージに含まれる該当車両の車両状態データ７０５の位置情報７１３に基づいて渋滞情報データ群１１１を検索して、関連する渋滞情報があるか調べる（ステップ８０２）。渋滞情報が関連しているかどうかは、例えば、渋滞情報データ群１１１の道路情報３０２を参照し、自分の位置情報が渋滞の道路と一致しているか、もしくは渋滞の道路に向かっているか（例えば、位置情報が走行道路情報を含む場合は、走行道路が渋滞の道路に接続しているかどうかで判定可能）により判定する。
もしも、関連する渋滞情報があるなら（ステップ８０３でＹｅｓ）、取得して、位置情報に基づき該当車両が渋滞の入口付近に位置するかどうかをチェックする（ステップ８０４）。もしも、該当車両が渋滞の入口付近に位置していると判定したら、受信した音声データは「渋滞（開始地点）」において発声されたもの（つまり発声時のコンテキストは渋滞（開始地点）、と判定する（ステップ８２４）。一方、該当車両が渋滞の入口付近に位置しない場合は、該当車両が渋滞の出口付近に位置しているかどうかをチェックし（ステップ８０５）、もしそうであればコンテキストは「渋滞（終了地点）」と判定する（ステップ８２３）。そうでなければ、該当車両が渋滞の中間に位置するかどうかをチェックし（ステップ８０６）、もしそうであればコンテキストは「渋滞（中間）」と判定（ステップ８２２）、そうでなければコンテキストは「渋滞（不明）」と判定し（ステップ８２１）、処理を終了する。

ステップ８０３に戻り、関連する渋滞情報が見つからなかった場合、コンテキストフラグ７０２を参照し、コンテキストが「渋滞」であるかを確認する（ステップ８１０）。もしも、「渋滞」であれば、受信した音声データに係るコンテキストを「渋滞（不明）」と判定し（ステップ８２１）、「渋滞」でなければ、ステップ８１１に進む。ここで、注意すべきは、ステップ８０１の条件から、ステップ８１０でコンテキストが「渋滞」でないということは、コンテキストは「不明」であることである。つまり、車載端末２０側で、コンテキスト決定処理が実施されていないことを意味するので、コンテキスト決定処理６０３の上記説明と同様にして、ステップ８１１で車両状態データに基づいてコンテキストが渋滞であるかどうかを判定する。もしも、ステップ８１１で渋滞と判定された場合は、受信した音声データに係るコンテキストを「渋滞（不明）」と判定して（ステップ８２１）、処理を終了する。さもなければ、受信した音声データに係るコンテキストを「渋滞ではない」と判定し（ステップ８２０）、処理を終了する。

図４の渋滞情報配信システム１の処理フロー５００に戻る。コンテキスト判定部１０２は、渋滞コンテキスト判定処理５１１の結果、「渋滞コンテキストではない」と判定した場合は（ステップ５１２でＹｅｓ）、渋滞コンテキストと同様その他のコンテキストに関する処理を実行して（ステップ５１６）、処理を終了する。一方、渋滞コンテキスト判定処理５１１で「渋滞コンテキスト」と判定した場合は、渋滞コンテキスト処理（ステップ５１３）に進む。

図９を用いて、コンテキスト判定部１０２による渋滞コンテキスト処理５１３を説明する。

コンテキスト判定処理５１１において分類した、コンテキストを「渋滞（終了地点）」、「渋滞（開始地点）」、「渋滞（中間）」「渋滞（不明）」の４種類のコンテキストに応じて処理が分かれる。もしも、「渋滞（終了地点）」の場合は（ステップ８５１でＹｅｓ）、渋滞原因決定処理を実行する（ステップ８６１）。

図１０を用いて、渋滞原因決定処理８６１を説明する。

まず、渋滞原因決定部１０４は、受信したメッセージに含まれる該当車両の位置情報７１３に基づいて、渋滞情報データ群１１１を検索して関連する渋滞情報を取得する（ステップ８８１）。もしくは、渋滞コンテキスト判定処理５１１のステップ８０２で取得した渋滞情報を用いても良い。続いて、取得した渋滞情報の渋滞ＩＤに基づいて渋滞原因集計データ群１１２を検索し、該当する渋滞原因集計情報を取得する（ステップ８８２）。

渋滞原因決定部１０４は、次に、同一車両による渋滞原因情報の二重登録を防ぐため、渋滞原因集計情報の登録済車両ＩＤを確認する（ステップ８８３）。もしも、登録済だったら、渋滞原因決定処理８６１を終了する。一方、登録済でない場合は、ステップ８８４に進み、受信した音声データを音声認識処理に通す。そして、音声認識処理８８４により取得された音声テキストをキーワードに分解し（ステップ８８５）、渋滞原因キーワードデータ群１１３と比較することにより渋滞に関連するものを抽出する（ステップ８８６）。

もしも、抽出された渋滞原因キーワードが存在しなかったら（ステップ８８７でＮｏ）、処理を終了する。一方、渋滞原因キーワードが抽出された場合は、渋滞原因集計情報において、抽出された渋滞原因キーワードに該当する渋滞原因キーワードのカウンタを増やす（ステップ８８８）。もしも、渋滞原因キーワードとして登録されていない場合は、新規に追加し、カウンタに初期値を入力する。そして、該当車両の車両ＩＤを渋滞原因集計情報に登録する（ステップ８８９）。

なお、カウンタの増やし方は、一様に１加えても良いし、渋滞コンテキストの分類や特定のパラメータの差異によって重みづけしても良い。例えば、運転者や同乗者が渋滞原因を認識するのは、たいてい渋滞の終了地点付近であり、渋滞の開始地点や中間部で渋滞原因に気づくことは稀である。そのため、「渋滞コンテキスト（終了地点）」では、カウンタを多く増やし（例えば＋５）、その他の渋滞コンテキストの場合はカウンタを少なく増やす（例えば＋１）という方法であっても良い。もしくは、渋滞の終了地点から発声地点までの距離に反比例するように重みづけをして、カウンタを増やしても良い。

以上、一連の渋滞原因集計情報の更新が完了すると、渋滞原因を決定する処理に移行する。もしも、ある渋滞原因キーワードｗのカウンタＣの値が、閾値Ｃ_thを超えていた場合は（ステップ８９０でＹｅｓ）、渋滞原因キーワードｗを当該渋滞情報の渋滞原因として設定する（ステップ８９１）。

次に、渋滞原因位置決定部１０５は、渋滞原因位置を特定する処理（ステップ８９２）を行う。

渋滞原因位置の特定は、渋滞情報を参照することにより実施される。渋滞原因が、サグや交差点等による道路形状、事故や工事等の道路イベント、またはアウトレット等商業施設、等の場合、ある特定の地点が渋滞を引き起こす原因となる。そのため、その地点に向かう道路が渋滞するため、渋滞の終了地点しかない地点（その地点からはいずれの方向にも渋滞が存在しないような地点）が原因箇所となる。例えば、図２の渋滞ＩＤが１の渋滞は、渋滞の道路は道路リンク（８０００、８１００）と（８１５０、８１００）であり、渋滞はいずれもの道路リンクでもノード８１００が終点であり、ノード８１００からはいずれの方向にも渋滞が存在しないため、ノード８１００付近が渋滞原因であるということがわかる。ただし、道路の容量を超過したために発生する自然渋滞や、花火大会等広範囲に渡り駐車スペースを探す車両により引き起こされる渋滞等は、渋滞原因が特定の地点によるものではないため、渋滞原因位置を指定することはできない。その場合は、上記手法でも「渋滞の終了地点しかない地点」を見つけることはできないので、渋滞原因位置は「不明」となる。

なお、自然渋滞の場合は、日常的に発生するものであるため、渋滞原因を運転手や同乗者の音声から抽出するのは難しい可能性がある。その反面、日常的に発生するものであるが故に、過去の渋滞履歴を確認することにより、それが自然渋滞によるものかを容易に判定できる。そのため、過去の渋滞履歴を解析して自然渋滞のデータベースを作成しておき、該当する渋滞が、自然渋滞データベースに登録されているケースと一致した場合は、渋滞原因が自然渋滞によるものと特定するようにしても良い。

もしも、ステップ８８９にて、いずれの渋滞原因キーワードも閾値Ｃ_thを超えていなかった場合は、渋滞原因は決定せず、処理を終了する。

図９の渋滞コンテキスト処理５１３のフローに戻る。判定されたコンテキストが「渋滞（不明）」だった場合（ステップ８５３でＹｅｓ）、コンテキスト判定部１０２は、受信したメッセージに含まれる該当車両の位置情報７１３に基づいて、渋滞情報データ群１１１を検索して関連する渋滞情報を取得する（ステップ８６３）。もしくは、渋滞コンテキスト判定処理５１１のステップ８０２で取得した渋滞情報を用いても良い。もしも、関連する渋滞情報があった場合は（ステップ８６４でＹｅｓ）、渋滞原因決定処理８６１を実行する。もしも、渋滞情報が見つからなかった場合は（ステップ８６４でＮｏ）、新規に発生した渋滞を意味するため、渋滞情報データ群１１１に位置情報７１３に基づいて渋滞情報エントリを新規登録し（ステップ８６５）、渋滞原因決定処理８６１を実行して、処理を終了する。

もしも判定されたコンテキストが「渋滞（中間）」もしくは「渋滞（開始地点）」だった場合は（ステップ８５３でＮｏ）、何も実行せず終了する。これは、渋滞の開始地点もしくは真っ只中にいるときは、渋滞原因を把握している可能性が低く、苛立ちによる推測の発声が多いと考えられ、渋滞原因集計の精度を下げる危険性があるためである。

図４の渋滞情報配信システム１の処理フロー５００に戻る。渋滞コンテキスト処理５１３の結果、渋滞原因情報が更新された場合（ステップ５１４でＹｅｓ）、渋滞情報配信部１０７は、渋滞情報配信処理を行う（ステップ５１５）。その後、その他のコンテキスト処理を実行し（ステップ５１６）、処理を終了する。もしも渋滞原因情報が更新されていない場合は、何も実行せずステップ５１６に進み、処理を終了する。

渋滞情報配信部１０７は、渋滞情報配信処理５１５では、渋滞原因が決定された渋滞情報に関係する車両２の車載端末２０に、渋滞原因情報を含む渋滞情報メッセージを送信する。ここでは、渋滞原因が更新された時点で、関係車両にプッシュする方法での渋滞情報配信を想定しているが、車載端末２０が定期的に渋滞情報を問い合わせて取得する方法でも良い。なお、渋滞情報に関係する車両２とは、当該渋滞につかまっている車両、当該渋滞の方向に向かっている、もしくは旅程計画を立てている車両、等を含む。これは、渋滞情報の問合せをする際に、現在地や目的地の情報を含むこと等により、渋滞情報配信サーバ１０が関連性を検証することで実現できる。

渋滞情報メッセージのフォーマットの一例を図１１に示す。渋滞情報メッセージは、渋滞情報を識別するための渋滞ＩＤ７５１、渋滞している道路の情報を示す一つ以上の道路リンク情報を含む渋滞道路情報７５２、渋滞原因７６１や渋滞原因位置情報７６２を含む渋滞原因情報７５３、を含む。渋滞原因７６１は、例えば、渋滞原因を表すテキストデータもしくはＩＤであり、渋滞原因決定処理８６１のステップ８９１で設定した渋滞原因キーワードｗに相当するものである。渋滞原因位置情報７６２は、渋滞原因決定処理８６１のステップ８９２で特定した渋滞原因位置に相当する。

渋滞情報配信サーバ１０の渋滞情報配信処理５１５において送信された渋滞情報メッセージは、車載端末２０によって受信される。すると、車載端末２０の渋滞情報受信部２０７は、渋滞情報受信処理を行い（ステップ５２０）、渋滞情報メッセージフォーマット７５０に従って渋滞情報を取得する。そして、渋滞情報が新規情報であった場合、渋滞情報通知部２０８は、必要性に応じて、運転者及び同乗者に対して、所定の方法で渋滞情報を通知する（ステップ５２１）。渋滞情報の通知方法としては、例えば、スピーカ２５２を用いた音声による読み上げによる通知でも良いし、ディスプレイ２５１を用いて渋滞情報を表示しても良いし、車載端末２０と任意の手段により接続された他端末に渋滞情報を渡し他端末上で通知しても良いし、いずれの任意の組み合わせにより通知しても良い。

図１２に、渋滞情報通知処理５２１の一例として、ディスプレイ２５１を用いて渋滞情報を表示する例を示す。

ディスプレイ２５１では、例えば、ナビゲーションアプリケーションが動作しており、周辺地図１０１０、車両２の位置と進行方向１０１１、ナビゲーション経路１０１２、等が表示されている。ここで、渋滞情報配信サーバ１０から、渋滞情報メッセージを受信し、渋滞情報メッセージには、渋滞道路情報７５２として道路リンク１００３−１００６の情報が、渋滞原因７６１として「アウトレット駐車待ち」というテキスト情報１０２２が、渋滞原因位置情報７６２としてアウトレットの駐車情報位置を示す位置情報が、含まれていたことを想定する。すると、ディスプレイ２５１では、例えば、図１２のようにして、渋滞道路情報、渋滞原因、及び渋滞原因位置を表示する。

渋滞道路情報は、例えば、ディスプレイ２５１上の道路において渋滞している箇所を所定の方式（色分け等）でハイライトすることにより、通知する。渋滞原因は、例えば、ディスプレイ２５１上にテキストボックス１０２０を一時的もしくは定常的に表示し、渋滞原因のテキスト情報１０２２を表記することにより通知する。渋滞原因位置は、例えば、ディスプレイ２５１上の地図に該当位置が含まれる場合は、地図の渋滞原因位置上に渋滞原因位置を表す印１００２を表記することにより通知する。

以上のように、本実施形態によれば、渋滞に遭遇している現場の運転者や同乗者が発した音声データから、自動的に渋滞原因に関連するキーワードを抽出して解析するため、インターネットやブログ全体を検索した場合よりも、精度高く実際の渋滞原因に関連するキーワードを収集することができる。そのため、渋滞原因の推定の精度を高めると同時に、判定に至るまでの収束時間を短縮することができる。さらに、渋滞に遭遇しているすべての車両を対象とするのではなく、渋滞の終了地点付近に位置する車両を特に対象とすることにより、実際の渋滞原因に関連するキーワードの収集精度を高めることができる。

また、交通事故等の渋滞原因イベント発生直後から、現場で状況を把握している運転者や同乗者の発声を収集することができるため、まだ渋滞が表面化されていないうちから、渋滞原因を特定、関連車両に通知することができる。そのため、道路事業者が事故を認識した後に道路交通情報センタ等から配信されるよりも早い段階で、渋滞原因を通知することができ、運転者が渋滞を回避する確率を高めることが可能となる。

また、本実施形態によれば、車載端末２０は、車両や車内の人が置かれている環境（コンテキスト）に応じて音声データを解析し、有用な情報が含まれる可能性のある音声データのみをサーバに送信する形態を取っている。この方式は、本実施例で記載した渋滞原因を特定する目的に拠らず、コンテキストに関連する運転者や同乗者の思考や知識を、音声データから抽出することができ、他の用途に応用することが可能である。

実施例２では、図４の左上の車載端末２０が音声データを渋滞情報配信サーバ１０に送信する処理フローにおいて、運転者や同乗者の音声を常時録音するのではなく、渋滞原因を運転者や同乗者に問い合わせる方法を用いた場合について説明する。

図１３に、図４の左上の車載端末２０による処理フローに相当する実施例２における処理フローを示す。

車載端末２０のＣＰＵ（図示していない）は、記憶部（図示していない）に格納したプログラムを実行し、いかに説明する処理を行うプロセスを実現する。

まず、車載端末２０ は、車両状態データを参照して、車両２が渋滞に巻き込まれたかどうかを常時確認している（ステップ１１０１）。渋滞に巻き込まれたかを判定する処理は、実施例１のコンテキスト決定処理６０３にて記載した渋滞コンテキストを判定する処理と同等のものである。

車載端末２０は、もしも、渋滞を検知した場合は（ステップ１１０１でＹｅｓ）、渋滞の終了地点に至ったかどうかを監視する（ステップ１１０２）。

渋滞の終了地点に至った場合の車両の挙動は二通りある。一つ目は、渋滞を引き起こしている原因の地点を通過した場合である。これは、車速データを監視しておき、それまで低速走行していた状況から急激に通常の速度の安定走行に移行したことを検知することにより、判定が可能である。二つ目は、渋滞原因が駐車待ちによるものであり、駐車スペースに停車した場合である。これは、車両のシフトレバー等の状態データを参照することにより、判定が可能である。

車載端末２０は、以上の方法により、渋滞の終了地点に至ったことを検知した場合は（ステップ１１０２でＹｅｓ）、渋滞原因質問処理に進む（ステップ１１０３）。この処理では、車載端末２０が、音声入出力部２３２を用いて、運転者や同乗者に対して、例えば「渋滞の原因は何でしたか？」などの質問文にて、渋滞の原因を音声で問い合わせる。そして、運転者や同乗者の音声による回答を、音声入出力部２３２経由で、音声データとして取得する。もしも、有効な音声データが取得できた場合は（ステップ１１０４でＹｅｓ）、音声データ送信処理５０５と同様な方法で音声データを渋滞情報配信サーバ１０に送信し、ステップ１１０１に戻る。一方、有効な音声データが取得できなかった場合は、所定回数リトライした後に、ステップ１１０１に戻る。

以上のように、本実施形態によれば、渋滞原因を直接運転者や同乗者に問い合わせるため、取得できる渋滞原因の精度がさらに高くなる。また、実施例１が無意識のうちに発せられる発声を対象に受動的に知識を抽出しているのに対して、実施例２では能動的に運転者や同乗者の知識を抽出するため、車両当たりの情報の収集確率を高めることができる。

また、問い合わせるタイミングを、渋滞を通過した後にすることにより、能動的な問合せに対するストレスを軽減することができることに加え、運転者や同乗者が渋滞原因を知った直後である可能性が高いことから、問い合わせに対して回答してもらえる確率を高めることができる。

１：渋滞情報配信システム、２：車両、３：ネットワーク、１０：渋滞情報配信サーバ、２０：車載端末、１００：渋滞情報配信サーバ１０の処理部、１０１：データ受信部、１０２：コンテキスト判定部、１０３：音声データ解析部、１０４：渋滞原因決定部、１０５：渋滞原因位置決定部、１０６：渋滞情報生成部、１０７：渋滞情報配信部、１１０：渋滞情報配信サーバ１０の記憶部、１１１：渋滞情報データ、１１２：渋滞原因集計データ、１１３：渋滞原因キーワードデータ、１２０：渋滞情報配信サーバ１０の通信部、２００：車載端末２０の処理部、２０１：音声データ取得部、２０２：音声データ解析部、２０３：コンテキスト決定部、２０４：特徴的音声判定部、２０５：車両状態データ取得部、２０６：データ送信部、２０７：渋滞情報受信部、２０８：渋滞情報通知部、２１０：車載端末２０の記憶部、２１１：車両状態データ、２１２：音声データ、２１３：音声処理パラメータデータ、２２０：車載端末２０の通信部、２３０：車載端末２０の入出力部、２３１：画面入出力部、２３２：音声入出力部、２３３：車内ＬＡＮ入出力部、２５１：ディスプレイ（ＤＰ）、２５２：スピーカ、２５３：マイク、２５４：車内ＬＡＮ。

Claims (13)

1. 車両外にあるサーバ装置と接続するための通信部と、を備える車載端末であって、
   前記車両内で発せられた音声から音声データを取得する音声データ取得部と、
   前記発声の時点付近の、前記車両の状態に関する車両状態データを取得する車両状態データ取得部と、
   取得された前記車両状態データを用いて、前記音声が発せられたコンテキストを決定するコンテキスト決定部と、
   取得された前記音声データを用いて、前記音声データの取得元である音声が、前記コンテキスト決定部により決定されたコンテキストにおける、特徴的な音声であるかを判定する特徴的音声判定部と、
   特徴的と判定された音声から取得された前記音声データを含むメッセージを、前記サーバ装置に送信するデータ送信部と、を備える
   ことを特徴とする車載端末。
2. 請求項１に記載の車載端末において、
   前記メッセージは、さらに一つ以上の前記車両状態データセットを含み、
   前記車両状態データセットは、時刻情報、前記時刻情報に関する前記車両の位置情報、前記時刻情報に関する前記車両の速度情報、を少なくとも一つ以上含む、
   ことを特徴とする車載端末。
3. 請求項１または請求項２に記載の車載端末において、
   前記メッセージは、さらに前記コンテキスト決定部により決定されたコンテキストの情報を含む
   ことを特徴とする車載端末。
4. 請求項１から３のいずれか一項に記載の車載端末において、
   コンテキスト決定部は、前記音声データが取得された際に前記車両が渋滞と関係していたかどうかを判定する
   ことを特徴とする車載端末。
5. 請求項１から４のいずれか一項に記載の車載端末において、
   前記特徴的音声判定部は、
   前記音声データを解析することにより前記音声に含まれる感情タイプを認識し、
   前記認識した感情タイプと、あらかじめ定めた、前記コンテキストが対象とする感情タイプとが、合致するかにより、特徴的音声であるかを判定する
   ことを特徴とする車載端末。
6. 請求項１から４のいずれか一項に記載の車載端末において、
   前記特徴的音声判定部は、
   前記音声の発声者を識別し、
   特定された発声者が発した音声データから、前記発声者の音声の統計的な特徴量パラメータを抽出し、
   抽出した前記統計的な特徴量パラメータと前記音声データの特徴量パラメータとを比較し、
   両者に変化があるかどうかを判定することにより、特徴的な音声データであるかを判定する
   ことを特徴とする車載端末。
7. 請求項６に記載の車載端末において、
   前記特徴量パラメータは、音声のトーン、音量、発声の間隔の任意の一つ以上を含む
   ことを特徴とする車載端末。
8. 請求項１から４のいずれか一項に記載の車載端末において、
   さらに、前記コンテキスト毎に、関連する特徴的なキーワードを一つ以上含む音声処理パラメータデータ群を備え、
   前記特徴的音声判定部は、
   前記音声データを、音声認識により文字データに変換してキーワードに分解し、
   前記キーワードが、前記音声処理パラメータデータに含まれているかどうかにより、特徴的音声であるかを判定する
   ことを特徴とする車載端末。
9. 請求項１から８のいずれか一に記載の車載端末において、さらに、
   車両内ネットワークと接続するための車内ネットワーク入出力部を備え、
   前記車両状態データ取得部は、前記車両状態データの少なくとも一種類を、前記社内ネットワーク入出力部を介して、前記車両から取得する
   ことを特徴とする車載端末。
10. 車両に接続された車載端末と通信するサーバにおいて、
    前記車載端末から、音声データと車両状態データとを含むメッセージを受信するデータ受信部と、
    前記メッセージに含まれる前記車両状態データに基づいて、前記車両が渋滞の中に位置しているかどうかを判定するコンテキスト判定部と、
    前記コンテキスト判定部において前記車両が渋滞の中に位置していると判定された場合に、同一の前記メッセージに含まれる音声データに基づいて渋滞原因を決定する渋滞原因決定部と、
    決定された前記渋滞原因を、当該渋滞に関連する車両へ配信する渋滞情報配信部と、
    を備えることを特徴とするサーバ。
11. 請求項１０に記載のサーバにおいて、
    前記渋滞原因決定部は、
    前記音声データを音声認識処理して対応する文字データに変換し、
    前記文字データに含まれる、渋滞原因となり得るキーワードをカウントし、
    前記カウンタ値が予め定められた数よりも大きくなった場合に、前記キーワードが当該渋滞の渋滞原因であると決定する
    ことを特徴とするサーバ。
12. 請求項１０に記載のサーバにおいて、
    前記コンテキスト判定部は、さらに、
    生成された渋滞情報を取得し、
    前記車両状態データの位置情報及び取得した前記渋滞情報に基づき、当該渋滞における前記車両の位置を判定し、
    前記渋滞原因決定部は、前記車両が当該渋滞の終点付近に位置すると判定された場合に、前記渋滞原因を決定する
    ことを特徴とするサーバ。
13. 請求項１２に記載のサーバにおいて、
    取得した前記渋滞情報は、渋滞している道路を示す道路リンクのリストを含み、
    前記サーバは、
    前記渋滞している道路を示す道路リンクの終点において、一つも前記渋滞している道路を示す道路リンクの始点となっていない終点が存在する場合に、当該終点を渋滞原因位置と決定する渋滞原因位置決定部を備える
    ことを特徴とするサーバ。

Images