(57)【要約】【課題】交通情報をユーザの予定に応じた態様で報知できるようにする。【解決手段】サーバ装置は、ユーザの予定情報に基づいて運行情報を報知すべき路線を特定し、特定した路線の運行情報をユーザの通信端末に送信する。サーバ装置は、特定した路線やユーザの予定情報に基づいて運行情報の報知態様を決定する。サーバ装置は、特定した路線の移動距離又は乗換回数が閾値以上であるか（Ｓｂ１）、予定情報に重要であることを示す情報が含まれているか（Ｓｂ３）、予定情報に人物がタグ付けされているか（Ｓｂ５）などを判断し、その判断結果に応じた優先フラグを設定し（Ｓｂ８、Ｓｂ９）、この優先フラグに応じた報知態様で運行情報が報知されるようにする。【選択図】図９
2015083417.tif 000002
【特許請求の範囲】
【請求項１】
あらかじめ入力された予定に関する位置を少なくとも示す予定情報を複数の予定について取得する取得部と、
所定の位置から前記取得部により取得された予定情報が示す位置に到達するための交通手段を前記複数の予定情報毎に特定する特定部と、
前記取得部により取得された予定情報と前記特定部により特定された交通手段の少なくともいずれかに基づいて、ユーザへの報知態様を決定する決定部と、
前記特定部により特定された交通手段の状況を知らせる交通情報を、前記決定部により決定された報知態様で報知されるようにそれぞれ出力する出力部と
を備える情報処理装置。
【請求項２】
前記決定部は、前記特定部により特定された交通手段による移動距離又は乗換回数に応じて報知態様を異ならせる
請求項１に記載の情報処理装置。
【請求項３】
前記予定情報は、前記予定に関する時刻を示す情報を含み、
前記所定の位置を、前記交通手段の特定に用いる前記予定情報が示す時刻よりも前の時刻を示す予定情報が示す位置と前記ユーザの位置のいずれかに基づいて特定する位置特定部を備える
請求項２に記載の情報処理装置。
【請求項４】
前記決定部は、前記取得部により取得された予定情報の重要度に応じて報知態様を異ならせる
請求項１ないし３のいずれか１項に記載の情報処理装置。
【請求項５】
前記予定情報は、前記予定に関する人物を示す情報を含み、
前記決定部は、前記人物を示す情報に基づいて重要度を判断する
請求項４に記載の情報処理装置。
【請求項６】
前記出力部が前記特定部により特定された交通手段の前記交通情報を出力するか否かを当該交通手段の特定に用いた前記予定情報が示す時刻と現在時刻の差分に基づいて判断する判断部を備え、
前記決定部は、前記取得部により取得された予定情報と前記特定部により特定された交通手段の少なくともいずれかに基づいて、前記報知態様を決定するための優先度を算出し、
前記判断部は、前記差分の比較に用いる閾値を、前記決定部により算出された優先度に応じて異ならせる
請求項１ないし５のいずれか１項に記載の情報処理装置。
【請求項７】
前記特定部は、前記交通情報を報知すべき前記予定情報がない場合に、前記ユーザの現在地から当該ユーザによりあらかじめ設定された場所に到達するための交通手段を特定する
請求項１ないし６のいずれか１項に記載の情報処理装置。
【請求項８】
コンピュータを、
あらかじめ入力された予定に関する位置を少なくとも示す予定情報を複数の予定について取得する取得部と、
所定の位置から前記取得部により取得された予定情報が示す位置に到達するための交通手段を前記複数の予定情報毎に特定する特定部と、
前記取得部により取得された予定情報と前記特定部により特定された交通手段の少なくともいずれかに基づいて、ユーザへの報知態様を決定する決定部と、
前記特定部により特定された交通手段の状況を知らせる交通情報を、前記決定部により決定された報知態様で報知されるようにそれぞれ出力する出力部
として機能させるためのプログラム。
【請求項９】
あらかじめ入力された予定に関する位置を少なくとも示す予定情報を複数の予定について取得するステップと、
所定の位置から前記取得された予定情報が示す位置に到達するための交通手段を前記複数の予定情報毎に特定するステップと、
前記取得された予定情報と前記特定された交通手段の少なくともいずれかに基づいて、ユーザへの報知態様を決定するステップと、
前記特定された交通手段の状況を知らせる交通情報を、前記決定された報知態様で報知するステップと
を有する交通情報の報知方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、交通情報を報知するための技術に関する。
【背景技術】
【０００２】
非特許文献１には、携帯電話において、出発地と終着地のほかに経由地を入力し、それぞれのルートに関する乗換案内を一覧表示することが記載されている。また、このような乗換案内を表示する際に、必要に応じて鉄道等の運行情報（遅延、運休など）を表示することも一般的である。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】“ナビタイムマスター講座−ＮＡＶＩＴＩＭＥの活用法：上級編” 、［online］、［平成２５年９月１３日検索］、インターネット〈URL：http://www.navitime.co.jp/pcstorage/html/master/useful_lv3.html〉
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、複数のルートについて運行情報を報知する場合には、ルート毎にその軽重が存在することがある。例えば、複数回の移動によって複数の目的地を辿るような予定の場合、どうしても間に合わなくてはならない目的地がある一方で、時間にそこまでの厳密さが求められない目的地もある、といったことが考えられる。
【０００５】
そこで、本発明は、交通情報をユーザの予定に応じた態様で報知できるようにすることを目的とする。
【課題を解決するための手段】
【０００６】
本発明に係る情報処理装置は、あらかじめ入力された予定に関する位置を少なくとも示す予定情報を複数の予定について取得する取得部と、所定の位置から前記取得部により取得された予定情報が示す位置に到達するための交通手段を前記複数の予定情報毎に特定する特定部と、前記取得部により取得された予定情報と前記特定部により特定された交通手段の少なくともいずれかに基づいて、ユーザへの報知態様を決定する決定部と、前記特定部により特定された交通手段の状況を知らせる交通情報を、前記決定部により決定された報知態様で報知されるようにそれぞれ出力する出力部とを備える構成を有する。
【０００７】
また、前記決定部は、前記特定部により特定された交通手段による移動距離又は乗換回数に応じて報知態様を異ならせる構成であってもよい。
また、前記予定情報は、前記予定に関する時刻を示す情報を含み、前記所定の位置を、前記交通手段の特定に用いる前記予定情報が示す時刻よりも前の時刻を示す予定情報が示す位置と前記ユーザの位置のいずれかに基づいて特定する位置特定部を備える構成であってもよい。
また、前記決定部は、前記取得部により取得された予定情報の重要度に応じて報知態様を異ならせる構成であってもよい。
また、前記予定情報は、前記予定に関する人物を示す情報を含み、前記決定部は、前記人物を示す情報に基づいて重要度を判断する構成であってもよい。
【０００８】
また、前記出力部が前記特定部により特定された交通手段の前記交通情報を出力するか否かを当該交通手段の特定に用いた前記予定情報が示す時刻と現在時刻の差分に基づいて判断する判断部を備え、前記決定部は、前記取得部により取得された予定情報と前記特定部により特定された交通手段の少なくともいずれかに基づいて、前記報知態様を決定するための優先度を算出し、前記判断部は、前記差分の比較に用いる閾値を、前記決定部により算出された優先度に応じて異ならせる構成であってもよい。
また、前記特定部は、前記交通情報を報知すべき前記予定情報がない場合に、前記ユーザの現在地から当該ユーザによりあらかじめ設定された場所に到達するための交通手段を特定する構成であってもよい。
【０００９】
また、本発明に係るプログラムは、コンピュータを、あらかじめ入力された予定に関する位置を少なくとも示す予定情報を複数の予定について取得する取得部と、所定の位置から前記取得部により取得された予定情報が示す位置に到達するための交通手段を前記複数の予定情報毎に特定する特定部と、前記取得部により取得された予定情報と前記特定部により特定された交通手段の少なくともいずれかに基づいて、ユーザへの報知態様を決定する決定部と、前記特定部により特定された交通手段の状況を知らせる交通情報を、前記決定部により決定された報知態様で報知されるようにそれぞれ出力する出力部として機能させる。
【００１０】
また、本発明に係る交通情報の報知方法は、あらかじめ入力された予定に関する位置を少なくとも示す予定情報を複数の予定について取得するステップと、所定の位置から前記取得された予定情報が示す位置に到達するための交通手段を前記複数の予定情報毎に特定するステップと、前記取得された予定情報と前記特定された交通手段の少なくともいずれかに基づいて、ユーザへの報知態様を決定するステップと、前記特定された交通手段の状況を知らせる交通情報を、前記決定された報知態様で報知するステップとを有する。
【発明の効果】
【００１１】
本発明によれば、交通情報をユーザの予定に応じた態様で報知することが可能である。
【図面の簡単な説明】
【００１２】
【図１】通信システムの全体構成を示すブロック図
【図２】通信端末のハードウェア構成を示すブロック図
【図３】サーバ装置のハードウェア構成を示すブロック図
【図４】予定情報のデータ構造を説明するための図
【図５】サーバ装置の音声エージェント機能に関する機能構成を示すブロック図
【図６】予定情報を例示する図
【図７】サーバ装置の運行情報の検索に関する機能構成を示すブロック図
【図８】運行情報を配信する処理の一例を示すフローチャート
【図９】決定処理示すフローチャート
【図１０】判断処理を説明するための図
【発明を実施するための形態】
【００１３】
［実施例］
図１は、本発明の一実施例である通信システム１０の全体構成を示すブロック図である。通信システム１０は、サーバ装置１００と、通信端末２００と、ネットワーク３００とを備える。なお、通信システム１０は、実際には複数の通信端末２００を備え、複数のユーザに対してサービスを提供するシステムであってもよい。この場合、ユーザの識別は周知の手法によるものとする。
【００１４】
本実施例において、通信システム１０は、ユーザに音声エージェント機能を提供する。ここにおいて、音声エージェント機能とは、通信端末２００に対して音声によって入力し、入力した音声に応じた情報を出力するなどのユーザの意図に応じた処理を実行する機能をいう。ユーザは、音声エージェント機能を利用することで、通信端末２００内外のコンテンツ（データ、アプリケーションなど）により容易にアクセスできるようになる。
【００１５】
サーバ装置１００は、音声エージェント機能に関する主要な処理を実行するコンピュータ装置である。サーバ装置１００は、通信端末２００から音声データを受信し、受信した音声データに応じた処理を実行する。サーバ装置１００は、本発明に係る情報処理装置の一例に相当するものである。通信端末２００は、ユーザに所持されるコンピュータ装置である。通信端末２００は、スマートフォン、データ通信が可能な携帯電話機などの無線通信端末である。ネットワーク３００は、サーバ装置１００と通信端末２００とを接続する通信ネットワークであり、インターネット、移動体通信網などを含んで構成される。
【００１６】
図２は、通信端末２００のハードウェア構成を示すブロック図である。通信端末２００は、制御部２１０と、記憶部２２０と、通信部２３０と、表示部２４０と、入力部２５０と、音声入出力部２６０と、測位部２７０とを少なくとも備える。なお、通信端末２００は、ここでは図示を省略するが、ＬＥＤ（Light Emitting Diode）などのライトやバイブレータを備え、データの入出力等に応じて発光又は振動するよう構成されていてもよい。
【００１７】
制御部２１０は、通信端末２００の各部の動作を制御する手段である。制御部２１０は、ＣＰＵ（Central Processing Unit）などの演算処理装置と主記憶装置に相当するメモリとを備え、プログラムを実行することによって各種の処理を実行する。制御部２１０が実行するプログラムには、複数のアプリケーションプログラムが含まれる。本実施例においては、音声エージェント機能を利用するためのアプリケーションプログラムや、後述する予定情報を管理するためのアプリケーションプログラム（以下「スケジューラ」という。）が制御部２１０によって実行される。
【００１８】
記憶部２２０は、データを記憶する手段である。記憶部２２０は、フラッシュメモリ、ＨＤＤ（Hard Disk Drive）などによる補助記憶装置を備える。また、記憶部２２０は、いわゆるメモリカードのような着脱可能な記憶媒体（リムーバブルメディア）を含んで構成されてもよい。記憶部２２０は、上述したプログラムや予定情報を記憶することができる。
【００１９】
通信部２３０は、データを送受信する手段である。通信部２３０は、モデムなどを備え、ネットワーク３００に応じた方式でデータの変調及び復調を行う。通信部２３０は、ネットワーク３００に接続し、ネットワーク３００を介してサーバ装置１００と通信を行う。
【００２０】
表示部２４０は、情報を表示する手段である。表示部２４０は、液晶素子や有機ＥＬ（electroluminescence）素子により構成される表示パネルと、この表示パネルを駆動する駆動回路とを含んで構成される。表示部２４０は、制御部２１０から供給された表示データに応じた文字や画像を表示する。
【００２１】
入力部２５０は、情報を入力する手段である。入力部２５０は、例えば、複数のキーにより構成されるキーパッドである。あるいは、入力部２５０は、表示部２４０の表示パネルに対応して設けられたタッチスクリーンによって構成されてもよい。入力部２５０は、ユーザの操作による入力を受け付け、操作に応じた入力データを制御部２１０に供給する。
【００２２】
音声入出力部２６０は、情報を音声によって入力及び出力する手段である。音声入出力部２６０は、典型的には、マイクロホンとスピーカにより構成されるが、イヤホンやヘッドセットに接続するための端子又は無線インタフェースを含み得る。音声入出力部２６０は、音声をデジタルデータに変換して入力し、又はデジタルデータを音声に変換して出力する。
【００２３】
測位部２７０は、位置情報を取得する手段である。測位部２７０によって取得される位置情報は、通信端末２００の位置（すなわちこれを所持しているユーザの位置）を示す情報であるといえる。測位部２７０は、ここではＧＰＳ（Global Positioning System）などの衛星測位システムによって得られた緯度及び経度を位置情報として用いることとするが、代替又は併用可能な他の位置情報（例えば、移動体通信網の基地局からの情報を利用したもの）を用いてもよい。測位部２７０は、演算等により取得した位置情報を制御部１１０に供給する。
【００２４】
次に、図３は、サーバ装置１００のハードウェア構成を示すブロック図である。サーバ装置１００は、制御部１１０と、記憶部１２０と通信部１３０とを備える。制御部１１０は、サーバ装置１００の各部の動作を制御する手段である。制御部１１０は、演算処理装置やメモリを備え、プログラムを実行することによって各種の処理を実行する。記憶部１２０は、データを記憶する手段であり、ＨＤＤやＳＳＤ（Solid State Drive）により構成される。記憶部１２０は、例えば、各ユーザの予定情報を記憶する。通信部１３０は、データを送受信する手段であり、ネットワーク３００を介して通信端末２００と通信を行う。
【００２５】
なお、サーバ装置１００は、データを記憶部１２０に記憶することに代えて、外部の記憶装置にデータを書き込み、又は当該記憶装置からデータを読み出すことも可能である。例えば、各ユーザの予定情報は、このような外部の記憶装置に記憶されていてもよい。
【００２６】
通信システム１０のハードウェア構成は、以上のとおりである。ユーザは、通信システム１０を用いて、音声エージェント機能を利用することができる。ユーザは、音声エージェント機能によって、情報を検索したり、特定のアプリケーションを起動したりすることができる。例えば、ユーザは、通信端末２００に対して「富士山の高さは？」と音声で問いかけると、「富士山の高さは３，７７６ｍです」という回答を通信端末２００から得たり、「１０時３０分にアラーム」と音声で話しかけると、１０時３０分にアラームを鳴らすアプリケーションを起動したりすることが可能である。
【００２７】
また、本実施例において、ユーザは、スケジューラによって自己の予定を管理することが可能である。通信端末２００において、個々の予定は、予定情報として保持される。ここにおいて、予定情報とは、ユーザによってあらかじめ入力された予定に関する情報をいい、当該予定に関する位置及び時刻を示す情報を少なくとも含むものとする。したがって、本実施例の予定情報は、「いつ」、「どこで」、「何がある」といったことがらを表す。
【００２８】
図４は、予定情報のデータ構造を説明するための図である。図４に示す予定情報は、「予定名」、「開始時刻」、「終了時刻」、「場所」、「内容」、「重要度」、「タグ情報」といった項目を有している。
【００２９】
「予定名」は、予定を識別するために入力される当該予定の名称である。この情報は、例えば、「打ち合わせ」、「出張」、「会食」、「パーティ」、「コンサート」など、ユーザによって入力される任意の文字列である。
「開始時刻」、「終了時刻」は、それぞれ、当該予定が開始される日時と終了する日時を表す情報である。
【００３０】
「場所」は、予定されている行事が開催される場所（すなわち位置）を示す情報である。この情報は、住所の全部又は一部であってもよいが、例えば、通信端末２００に表示された地図上のいずれかの位置をユーザが指定することで入力されてもよいし、「東京駅」などのような著名な施設・建造物（ランドマーク）であってもよい。
【００３１】
「内容」は、予定の具体的な内容を示す情報である。この情報は、ユーザがメモや備忘録の目的で入力するものである。
「重要度」は、予定の重要度を示す情報である。本実施例の重要度は、説明の便宜上、重要であるか否かを二値的に示すフラグであるとするが、重要度を３段階以上とすることを妨げない。重要度は、例えばユーザによって事前に入力されるものである。
【００３２】
「タグ情報」は、予定に付随する情報である。本実施例のタグ情報は、予定に関連する人物を関連付けることが可能である。予定情報に人物を関連付ける行為を、以下においては「タグ付け」という。ユーザは、例えば通信端末２００に記憶されているアドレス帳に登録されている人物をタグ付けすることが可能である。ユーザは、例えば、Ａさんと出張に行くといった場合に、同行者である「Ａさん」をタグ付けする。なお、タグ情報は、人物に限らず、ユーザが定義したさまざまな情報を入力可能であってもよい。
【００３３】
なお、予定情報は、図４に示した全ての項目を必須の入力項目とするものではなく、必要に応じて一部の項目の入力が省略されてもよい。また、予定情報は、図４に示されていない他の項目を含むことも可能である。すなわち、図４に示した予定情報は、あくまでも一例である。
【００３４】
本実施例において、予定情報は、通信端末２００において入力されたものが通信端末２００とサーバ装置１００とに記憶され、データが同期されているものとする。通信端末２００は、予定情報が入力されると、これを記録するとともに、適当なタイミングで同じものをサーバ装置１００に送信する。
【００３５】
また、ユーザは、予定情報を音声によって入力又は検索（出力）することも可能である。すなわち、通信端末２００は、音声エージェント機能とスケジューラを連携させることが可能である。例えば、翌日の予定情報として「予定名」が「打ち合わせ」である予定情報が記録されている場合において、ユーザが「明日の打ち合わせは何時？」と問いかけると、通信端末２００は、ユーザの意図を解釈してスケジューラを参照し、当該予定情報の「開始時刻」や「終了時刻」を音声によって再生し、又は文字によって表示する。
【００３６】
上述したとおり、音声エージェント機能に関する主要な処理は、サーバ装置１００によって行われる。音声エージェント機能に関しては、通信端末２００は、音声入力を受け付けて音声データを送信し、サーバ装置１００による処理結果を出力することが主な役割である。ここにおいて、通信端末２００は、音声を所定のエンコード方式で符号化した音声データを送信する。なお、音声データは、音声そのものを表すものでなく、音声の特徴量を表すものであってもよい。
【００３７】
図５は、サーバ装置１００の音声エージェント機能に関する機能構成を示すブロック図である。サーバ装置１００は、制御部１１０が所定のプログラムを実行することにより、同図に示す音声認識部１１０Ａ、意図解釈部１１０Ｂ及び音声合成部１１０Ｃを実現する。
【００３８】
音声認識部１１０Ａは、ユーザにより発声された音声を認識する手段である。音声認識部１１０Ａは、通信端末２００から送信された音声データを解析し、ユーザがどのような音声（言葉）を発したかを特定する。音声認識部１１０Ａは、このようにして特定した音声を表すテキストデータを生成する。
【００３９】
意図解釈部１１０Ｂは、発声によるユーザの意図を解釈する手段である。意図解釈部１１０Ｂは、音声認識部１１０Ａにより生成されたテキストデータに基づいて、テキスト化された音声の意味を解析する。意図解釈部１１０Ｂは、形態素解析などの自然言語処理を実行することによってテキストデータが示す意図を解釈する。
【００４０】
また、意図解釈部１１０Ｂは、このようにして解釈したユーザの意図に応じた処理を実行する。例えば、ユーザの意図が何らかの情報を検索することであった場合、意図解釈部１１０Ｂは、外部のデータベースやサーチエンジンにアクセスしてユーザの意図に合致する情報を取得する。あるいは、ユーザの意図が何らかのアプリケーションを起動することであった場合、意図解釈部１１０Ｂは、通信端末２００に当該アプリケーションを起動させるために必要な命令を生成する。
【００４１】
音声合成部１１０Ｃは、ユーザに応答する音声を合成する手段である。音声合成部１１０Ｃは、意図解釈部１１０Ｂによる処理結果に基づき、ユーザの意図に応じた音声を人工的に合成した合成音声データを生成する。なお、ユーザの音声入力に対する応答は、必ずしも音声であるとは限らない。例えば、サーバ装置１００は、情報を検索する要求に対してウェブページなどの視覚的な情報で応答する場合もある。
【００４２】
サーバ装置１００は、このような構成により、音声データに応じた出力データを通信端末２００に送信する。出力データは、音声合成部１１０Ｃにより生成された合成音声データと、ウェブページなどの表示データとを含み得る。つまり、ユーザは、音声入力に対する応答を視覚的又は聴覚的に得ることができる。
【００４３】
なお、本実施例において、音声エージェント機能により検索可能な情報には、運行情報が含まれる。ここにおいて、運行情報とは、鉄道の運行状況を示す情報をいい、例えば、ダイヤ（運行計画）が乱れていることを知らせる情報（遅延情報）や、列車の運休等を知らせる情報である。以下においては、鉄道の運行に何らかの支障を生じさせる運行状況を総称して「遅延等」という。運行情報は、所定の事業者によって所定の区間（以下「路線」という。）毎に提供されるものとする。また、運行情報は、運行状況の変化に応じて逐次更新される。ユーザは、例えば「運行情報を教えて」、あるいは単に「運行情報」といった所定のキーワードによって問いかけ（音声入力）を行うことによって、運行情報を検索することが可能である。なお、運行情報は、本発明に係る交通情報の一例に相当する。
【００４４】
サーバ装置１００が検索可能な運行情報は、以下の３通りである。
（１）ユーザがあらかじめ設定している路線の運行情報
（２）ユーザの現在地と予定情報の少なくともいずれかに基づいて特定される路線の運行情報
（３）その他、ユーザが指定し、又はサーバ装置１００が推定した路線の運行情報
【００４５】
（１）の路線は、例えば、ユーザが通勤・通学などに利用するなど、比較的頻繁に利用する路線である。ユーザは、このような路線をあらかじめ１又は複数登録し、運行情報の検索に利用することができる。このようにして設定された路線を示す情報を、以下においては「設定情報」という。設定情報は、通信端末２００において登録されるが、通信端末２００を介してサーバ装置１００にも通知される。
【００４６】
なお、設定情報は、路線を示す情報に加え、あらかじめ設定された場所を示す情報を含み得る。例えば、ユーザは、自宅又は職場の最寄り駅など、頻繁に乗降する駅を登録することが可能である。
【００４７】
（２）の路線は、第一には、ユーザが現在地から予定情報が示す場所（目的地）に移動するために利用する（と推測される）路線である。サーバ装置１００は、予定情報に基づいて、予定された時刻に目的地に到達するために必要な路線を特定する。このとき特定される路線は、１つであるとは限らず、例えば、乗り換えがあれば複数である。また、サーバ装置１００は、目的地に到達可能な路線が複数ある場合には、それぞれの路線について運行情報を検索してもよい。
【００４８】
また、（２）の路線は、第二には、ある予定に関連付けられた場所から次の予定に関連付けられた場所に移動するためにユーザが利用する（と推測される）路線である。サーバ装置１００は、時間的に連続する２つの予定情報に基づいて、予定された時刻に目的地に到達するために必要な路線を特定する。なお、ここにおいて、ある予定情報に「連続する」予定情報とは、当該ある予定情報が示す終了時刻以降に予定されている予定情報のうちの開始時刻が当該終了時刻に最も近い予定情報をいう。
【００４９】
図６は、連続する予定情報を例示する図である。ここでは、「予定名」が「打ち合わせ」であり、「開始時刻」、「終了時刻」、「場所」がそれぞれ「１６時」、「１８時」、「渋谷」である第１の予定情報と、「予定名」が「食事」であり、「開始時刻」、「終了時刻」、「場所」、「タグ情報」がそれぞれ「１９時」、「２１時」、「横浜」、「Ａさん」である第２の予定情報とがあらかじめ入力されているものとする。つまり、第１の予定情報は、「“１６時”から“１８時”まで“渋谷”で“打ち合わせ”が予定されている」ということを示す予定情報であり、第２の予定情報は、「“１９時”から“２１時”まで“横浜”で“Ａさん”と一緒に“食事”が予定されている」ということを示す予定情報である。
【００５０】
このような予定情報が入力されている場合、サーバ装置１００は、第１の予定情報が示す場所から第２の予定情報が示す場所に移動するために利用する（と推測される）路線を特定する。つまり、図６に示した例の場合、サーバ装置１００は、「渋谷」から「横浜」に移動するための路線を特定する。
【００５１】
図７は、サーバ装置１００の運行情報の検索に関する機能構成を示すブロック図である。サーバ装置１００は、制御部１１０が所定のプログラムを実行することにより、同図に示す予定情報取得部１１１、交通情報取得部１１２、受付部１１３、位置特定部１１４、交通手段特定部１１５、報知態様決定部１１６、出力部１１７及び判断部１１８を実現する。図７に示す各部は、意図解釈部１１０Ｂの一部を構成する。
【００５２】
予定情報取得部１１１は、予定情報を取得する手段である。予定情報取得部１１１は、記憶部１２０に記憶されている予定情報を読み出して取得する。なお、予定情報取得部１１１は、全ての予定情報を取得する必要はない。例えば、ユーザの目的地を特定する場合、予定情報取得部１１１は、既に終了した過去の予定情報を取得する必要はなく、開始時刻が現在時刻よりも後の予定情報を取得すればよい。
【００５３】
交通情報取得部１１２は、交通情報（ここでは運行情報）を取得する手段である。交通情報取得部１１２は、所定の事業者によって外部から逐次送信される運行情報を、通信部１３０を介して取得する。
【００５４】
受付部１１３は、運行情報を出力する要求を受け付ける手段である。受付部１１３は、ユーザの音声を解析して得られたテキスト中に「運行情報（を教えて）」といった所定のキーワードが含まれているか否かを判断し、当該キーワードが含まれている場合に、ユーザが運行情報の出力を要求していると判断する。
【００５５】
位置特定部１１４は、ユーザの位置を特定する手段である。本実施例において、ユーザの位置は、通信端末２００の位置と実質的に同一である。したがって、位置特定部１１４は、通信端末２００の位置を特定することによってユーザの位置を特定する。位置特定部１１４は、測位部２７０によって取得された位置情報を通信端末２００から受信することにより、通信端末２００の位置を特定する。なお、位置特定部１１４によって特定された直近の位置のことを、ここでは「現在地」という。
【００５６】
交通手段特定部１１５は、運行情報を出力すべき交通手段（ここでは路線）を特定する手段である。交通手段特定部１１５は、位置特定部１１４により特定された位置と、予定情報取得部１１１により取得された予定情報が示す位置（場所）とに基づいて、位置特定部１１４により特定された位置から予定情報取得部１１１により取得された予定情報が示す位置に到達するための路線を特定する。また、交通手段特定部１１５は、予定情報が示す時刻をさらに参照し、位置特定部１１４により特定された位置から予定情報取得部１１１により取得された予定情報が示す位置に当該時刻までに到達するための路線を特定してもよい。また、交通手段特定部１１５は、このようにして特定した路線による移動距離や、出発地から目的地に到達するまでの乗換回数を特定することも可能である。
【００５７】
さらに、交通手段特定部１１５は、位置特定部１１４により特定された位置と、予定情報取得部１１１により取得された予定情報が示す位置とに基づいて、特定した路線を利用した場合の所要時間を特定することも可能である。ここにおいて、交通手段特定部１１５は、ユーザの位置や予定情報が示す位置が鉄道の駅から離れている場合には、当該位置から最寄り駅までの移動に要する時間を所要時間に加算してもよい。あるいは、交通手段特定部１１５は、位置特定部１１４により特定された位置から予定情報取得部１１１により取得された予定情報が示す位置までの距離を特定してもよい。ここでいう距離は、２点間の最短距離であってもよいが、移動距離、すなわち実際の移動に要した距離（道のり）であってもよい。
【００５８】
報知態様決定部１１６は、ユーザへの交通情報の報知態様を決定する手段である。報知態様決定部１１６は、交通情報をユーザにどのように認識させるか（すなわち認識のさせ方）を決定する。ここにおいて、報知態様とは、画像の表示、音声の再生のほか、ＬＥＤの発光（点滅など）やバイブレータによる振動を含んでもよい。報知態様決定部１１６は、予定情報取得部１１１により取得された予定情報と、交通手段特定部１１５により特定された交通手段の少なくともいずれかに基づいて報知態様を決定することができる。
【００５９】
出力部１１７は、運行情報を出力する手段である。出力部１１７は、交通手段特定部１１５により特定された路線の運行情報を出力データに含めて出力する。出力部１１７は、交通情報取得部１１２により取得された運行情報であって、交通手段特定部１１５により特定された路線の運行情報を出力する。なお、運行情報は、合成音声データと表示データ（ウェブページ等）のいずれの形態で供給されてもよい。
【００６０】
また、出力部１１７は、運行情報を、報知態様決定部１１６により決定された報知態様で報知されるように出力する。具体的には、出力部１１７は、報知態様を指定する情報を運行情報に関連付けて出力する。通信端末２００は、この情報に従った報知態様で運行情報を報知することができる。
【００６１】
判断部１１８は、運行情報を出力するか否かを判断する手段である。すなわち、出力部１１７は、交通手段特定部１１５により特定された路線に運行情報がある場合に、これを常に出力するとは限らない。例えば、判断部１１８は、予定情報が示す時刻（開始時刻）と現在時刻の差分が所定の閾値を上回る場合、すなわち予定情報が示す時刻が現在時刻よりも当分先である場合には、遅延等の運行情報が仮にあってもこれを出力しないと判断してもよい。なぜならば、このような運行情報は、ユーザにとってあまり意味がない場合が多いからである。
【００６２】
判断部１１８は、交通手段特定部１１５による路線の特定に用いられた予定情報に基づいて、このような判断を実行する。例えば、判断部１１８は、予定情報が示す時刻と現在時刻の差に基づいて判断を行ってもよいし、予定情報に含まれる重要度に基づいて判断を行ってもよい。
【００６３】
図８は、運行情報を配信する処理の一例を示すフローチャートである。同図に示す処理は、ユーザが「運行情報（を教えて）」といった所定のキーワードを発声し、これに応答するように出力データが出力される場合を例示したものである。したがって、この場合の運行情報の配信形態は、いわゆるプル型配信に相当する。なお、ここでは、通信端末２００からは、現在地を示す位置情報が音声データとともに送信されるものとする。
【００６４】
まず、サーバ装置１００の制御部１１０は、あるユーザの通信端末２００から送信された音声データに基づき、当該ユーザの意図、すなわち当該ユーザが運行情報の検索を要求しているか否かを判断する（ステップＳａ１）。制御部１１０は、ユーザの意図が運行情報の検索でない場合には、本処理を終了し、ユーザの意図に応じた他の処理を実行する。
【００６５】
ユーザが運行情報の検索を要求している場合、制御部１１０は、予定情報を取得する（ステップＳａ２）。すなわち、制御部１１０は、報知に必要な予定情報を記憶部１２０から読み出す。ここにおいて、報知に必要な予定情報とは、当日の予定情報であって、かつ、未了の予定に関する予定情報である。すなわち、制御部１１０は、翌日以降の予定に関する予定情報や、既に予定が終了している予定情報を取得対象から除外する。なぜならば、このような予定情報は、運行情報の報知に際してほとんど意味をなさないからである。
【００６６】
次に、制御部１１０は、予定情報を取得できたか否かを判断する（ステップＳａ３）。制御部１１０は、報知に必要な予定情報を１つでも取得できれば、予定情報に基づいて路線を特定する一方、報知に必要な予定情報を１つも取得できなければ、設定情報に基づいて路線を特定する。
【００６７】
予定情報を取得できた場合、制御部１１０は、取得した予定情報と通信端末２００から送信された位置情報とに基づいて路線を特定する（ステップＳａ４）。路線を特定したら、制御部１１０は、特定した路線の運行情報が提供されているか検索する（ステップＳａ５）。制御部１１０は、ステップＳａ４、Ｓａ５の処理を、取得した予定情報毎に実行する。すなわち、制御部１１０は、予定情報を複数取得した場合には、複数の予定情報のそれぞれについてステップＳａ４、Ｓａ５の処理を実行する。
【００６８】
なお、ステップＳａ４の処理において、制御部１１０は、複数の予定情報を取得した場合に、路線の始点（すなわち出発地）を予定情報毎に異ならせる。具体的には、制御部１１０は、開始時刻が現在時刻に最も近い予定情報に関しては、通信端末２００から送信された位置情報が示す位置（すなわちユーザの現在地）を始点として路線を特定する。一方、それ以外の予定情報、すなわち当該予定情報よりも前の予定に関する予定情報が取得されている予定情報に関しては、制御部１１０は、終了時刻が当該予定情報が示す時刻（開始時刻）に最も近い予定情報、すなわち直前の予定に関する予定情報が示す位置を始点として路線を特定する。
【００６９】
これを図６を例にして説明すると、以下のようになる。すなわち、１５時（ないしそれ以前）の時点で運行情報が要求されたとすると、制御部１１０は、第１の予定情報と第２の予定情報とを取得することができる。このとき、制御部１１０は、第１の予定情報については、始点をユーザの現在地とし、現在地から渋谷に向かう路線を特定する。一方、第２の予定情報については、制御部１１０は、始点を第１の予定情報が示す位置、すなわち渋谷とし、渋谷から横浜に向かう路線を特定する。このようにすれば、ユーザの予定に即した路線を特定することができるようになる。
【００７０】
なお、運行情報は、運行状況に異変があった場合にのみ提供される（すなわち、平常どおり運行されていれば提供されない）ものであるとするが、平常どおり運行されている場合には「平常どおり運行しています」などといった運行情報が提供されるものであってもよい。前者の場合において、運行情報がないときには、制御部１１０は、「平常どおり運行しています」などのあらかじめ決められたメッセージで応答するように出力データを生成してもよい。
【００７１】
運行情報を検索したら、制御部１１０は、運行情報の報知態様を決定する処理を実行する（ステップＳａ６）。この処理のことを、以下においては「決定処理」という。制御部１１０は、複数の路線について運行情報が得られた場合には、それぞれの路線毎に決定処理を実行する。
【００７２】
図９は、決定処理を示すフローチャートである。決定処理において、制御部１１０は、まず、予定情報に基づいて特定した路線による移動距離又は乗換回数が所定の閾値以上であるか否かを判断する（ステップＳｂ１）。制御部１１０は、移動距離又は乗換回数が所定の閾値以上であれば、優先度に関する評価値を「ｎ1」だけ増加させる（ステップＳｂ２）。
【００７３】
次に、制御部１１０は、予定情報の「重要度」を参照し、当該予定情報が重要であるか否かを判断する（ステップＳｂ３）。制御部１１０は、予定情報が重要であると判断されれば、優先度に関する評価値を「ｎ2」だけ増加させる（ステップＳｂ４）。
【００７４】
次に、制御部１１０は、予定情報の「タグ情報」を参照し、人物がタグ付けされているか否かを判断する（ステップＳｂ５）。制御部１１０は、予定情報に人物がタグ付けされていれば、優先度に関する評価値を「ｎ3」だけ増加させる（ステップＳｂ６）。これは、他人が関わる予定は、そうでない予定（自分だけで行動する予定）に比べて重要度が高く、予定されている時間に対して遅刻するべきでないという考えに基づくものである。
【００７５】
最後に、制御部１１０は、このようにして算出した評価値を所定の閾値Ｎと比較する（ステップＳｂ７）。ここにおいて、閾値Ｎは、Ｎ≦ｎ1＋ｎ2＋ｎ3を満たす適当な数値である。制御部１１０は、評価値が閾値Ｎ以上であれば、優先フラグを「オン」とする一方、評価値が閾値Ｎ未満であれば、優先フラグを「オフ」とする（ステップＳｂ８）。優先フラグは、報知態様を決定するための優先度を表す情報である。
【００７６】
なお、決定処理は、ステップＳｂ１、Ｓｂ３、Ｓｂ５の判断処理の少なくともいずれかが実行されればよく、その一部が省略されてもよい。また、これらの３回の判断処理は、特に順番が限定されるものではないため、図９とは異なる順番で実行されてもよい。さらに、ｎ1、ｎ2、ｎ3の値は、同じ値であってもよいし、互いに異なる値であってもよい。閾値Ｎの値は、実行する判断処理やｎ1〜ｎ3の値に応じて可変としてもよい。
【００７７】
ここで、制御部１１０は、運行情報を出力するか否かを判断する（ステップＳａ７）。制御部１１０は、ステップＳａ４において特定した路線を利用した場合の所要時間を特定し、所要時間に基づいて運行情報を出力するか否かを判断する。あるいは、制御部１１０は、上述した優先フラグを参照し、その値に応じて出力するか否かを判断してもよい。
【００７８】
図１０は、ステップＳａ７の判断処理を説明するための図である。制御部１１０は、予定の開始時刻から所要時間と時間Ｔを加算した時間だけ遡った時刻ｔ0を算出し、現在時刻が時刻ｔ0以後であれば運行情報を出力し、現在時刻が時刻ｔ0より前であれば運行情報を出力しない。換言すれば、制御部１１０は、所要時間と時間Ｔを加算した時間を閾値とし、予定の開始時刻と現在時刻の差分をこの閾値と比較している。
【００７９】
このようにすると、ユーザは、目的地に移動するための行動が必要になるときに運行情報を入手し、それ以外のときには不必要な運行情報が配信されないようにすることができる。例えば、直近の予定が夜の予定であり、かつ、目的地への移動のための所要時間も１時間程度であるような場合において、当該移動に利用する路線に朝や昼に遅延等が生じたとしても、その運行情報はユーザにとって必ずしも有益であるとはいえない。ユーザにとってより有益である可能性が高い運行情報は、ユーザが目的地に移動するために鉄道を利用しようとするタイミングでの運行情報であるといえる。
【００８０】
なお、ここでいう所要時間は、遅延等が発生していない場合の標準的な所要時間のことである。したがって、時刻ｔ0の算出に際して時間Ｔを設けなかった場合（すなわちＴ＝０とした場合）には、遅延等の運行情報を入手してもユーザにとっては手遅れになる可能性が高い。なぜならば、遅延等が発生していれば、目的地への移動には標準的な所要時間以上の時間を要するからである。
【００８１】
時間Ｔの値は、あらかじめ決められた値（例えば、１〜２時間程度）でもよいが、ここでは、優先フラグが「オン」の場合と「オフ」の場合で異なるとする。具体的には、優先フラグが「オン」の場合の方が、時間Ｔの値が大きくなる。つまり、ここでは、予定の開始時刻と現在時刻の差分の比較に用いる閾値を優先フラグに応じて異ならせている。これにより、優先フラグが「オン」である運行情報、すなわち乗換回数の多い路線や重要度が高い予定に関する路線の運行情報は、優先フラグが「オフ」である運行情報よりも前もって報知されるようになる。
【００８２】
制御部１１０は、出力対象である運行情報を含む出力データを生成して出力する（ステップＳａ８、Ｓａ９）。すなわち、制御部１１０は、ステップＳａ７において出力すると判断した運行情報を含んだ出力データを生成及び出力する。通信端末２００は、この出力データを受信すると、出力データに応じた処理を実行する。
【００８３】
通信端末２００は、運行情報を含む出力データを受信したとき、それぞれの運行情報に指定された報知態様でユーザに運行情報を報知する。通信端末２００は、上述した優先フラグを参照し、これが「オン」であるか「オフ」であるかによって運行情報の報知態様を異ならせる。例えば、通信端末２００は、優先フラグが「オン」である運行情報を優先的に表示することができる。ここにおいて、表示を「優先的」にするとは、運行情報を一覧表示するときにより上位に表示することをいう。あるいは、通信端末２００は、優先フラグが「オン」である運行情報を、そうでない運行情報よりも強調して表示させてもよい。ここでいう強調とは、運行情報の一部又は全部を点滅させたり、目立ちやすい色で表示させたりすることをいう。
【００８４】
また、通信端末２００は、優先フラグが「オン」である運行情報を報知する場合には、音声の再生や画像の表示に加え、バイブレータを振動させたりＬＥＤを点灯させたりする一方、優先フラグが「オン」である運行情報を報知しない場合には、音声の再生や画像の表示のみを行い、バイブレータやＬＥＤによる報知を行わないようにしてもよい。
【００８５】
なお、ステップＳａ３において予定情報がないと判断した場合、制御部１１０は、設定情報に基づいて路線を特定する（ステップＳａ１０）。制御部１１０は、設定情報によって路線が設定されている場合には、当該路線の運行情報を検索する。また、制御部１１０は、設定情報に場所（自宅の最寄り駅など）が設定されていれば、現在地から当該場所に到達するための路線を特定する。
【００８６】
制御部１１０は、このようにして路線を特定したら、特定した路線の運行情報を検索し（ステップＳａ１１）、検索結果に応じた出力データを生成及び出力する（ステップＳａ１２、Ｓａ１３）。これらの処理は、ステップＳａ５、Ｓａ８、Ｓａ９の処理と同様の処理である。なお、制御部１１０は、このときステップＳａ７の判断処理と同様の処理を実行してもよい。
【００８７】
サーバ装置１００が実行する処理は、以上のとおりである。ここで、運行情報の具体的な報知態様について、図６を例にして説明する。ここにおいて、ユーザは、１５時に運行情報の検索を要求するものとする。また、説明の便宜上、ここでは、１５時におけるユーザの現在地から第１の予定情報が示す位置（渋谷）への所要時が「３０分」であるとする。さらに、時間Ｔの値は、優先フラグが「オフ」の場合には２時間、「オン」の場合には４時間であるとする。
【００８８】
例えば、第１の予定情報と第２の予定情報のいずれもが、優先フラグが「オフ」であるとする。この場合において、ユーザが１５時に運行情報の検索を要求したとすると、運行情報が報知されるのは、現在地から渋谷までの移動に関する運行情報のみであり、渋谷から横浜までの移動に関する運行情報は報知の対象外である。なぜならば、渋谷から横浜までの移動に関する運行情報は、第２の予定情報の優先フラグが「オフ」である場合には、開始時刻の２時間３０分前、すなわち１６時３０分以降が報知の対象だからである。
【００８９】
一方、第２の予定情報が重要な予定であるとか「Ａさん」がタグ付けされているといった理由により、第２の予定情報の優先フラグが「オン」であるとした場合において、ユーザが１５時に運行情報の検索を要求したとすると、現在地から渋谷までの移動に関する運行情報に加え、渋谷から横浜までの移動に関する運行情報も通知される。なぜならば、渋谷から横浜までの移動に関する運行情報は、第２の予定情報の優先フラグが「オン」である場合には、開始時刻の４時間３０分前、すなわち１４時３０分以降が報知の対象だからである。
【００９０】
以上のとおり、本実施例の通信システム１０によれば、運行情報をユーザの予定に応じた報知態様で報知することが可能である。ユーザは、より重要な予定や、移動時によりトラブルが生じやすい予定に関連する運行情報を、他の運行情報よりも優先的に、あるいは明瞭に把握することができるようになる。したがって、ユーザは、遅延等が発生した場合に、適切な行動をより迅速に開始したり、遅延等に対処したりすることがより容易となる。
【００９１】
［変形例］
本発明は、上述した実施例の態様に限らず、他の態様でも実施することができる。以下に示すのは、本発明の他の態様の一例である。なお、これらの変形例は、必要に応じて、各々を適宜組み合わせることも可能である。
【００９２】
（１）本発明は、音声エージェント機能を利用するものに限定されない。したがって、本発明は、運行情報の検索の要求などを音声によって入力するものに限定されない。例えば、運行情報の検索は、所定のボタンを押下することによって実行されてもよい。あるいは、本発明は、ユーザから明示的な要求をすることなく、遅延等の運行情報が発生した場合にこれを随時報知するものであってもよい。すなわち、本発明は、プル型配信のみならず、いわゆるプッシュ型配信の配信形態にも適用可能である。
【００９３】
例えば、本発明は、通信端末２００が定期的（例えば数分に１回）に位置情報をサーバ装置１００に送信し、サーバ装置１００がこの位置情報を受信する毎に図８に示した処理を実行するものであってもよい。このとき制御部１１０は、ステップＳａ１の処理（運行情報の検索が要求されているか判断する処理）に代えて、位置情報を取得したか否かを判断する処理を実行し、位置情報を取得した場合にステップＳａ２以降の処理を実行すればよい。
【００９４】
（２）本発明の予定情報は、時刻を示す情報を必ずしも要しない。すなわち、本発明は、現在時刻との関係を問わずに、取得された予定情報に応じた路線を特定して報知態様を決定するものであってもよい。
【００９５】
（３）ユーザの現在地は、測位部２７０による測位によらなくても特定（あるいは推定）可能である。例えば、通信端末２００は、ユーザの現在地をユーザ自身に入力させてもよい。あるいは、通信端末２００は、終了した予定情報のうちの現在時刻に最も近いものを参照し、当該予定情報に記述された情報（場所）に基づいてユーザの現在地を推定してもよい。
【００９６】
（４）上述した（鉄道の）運行情報は、本発明に係る交通情報の一例である。本発明に係る交通情報は、鉄道の運行情報に限らず、例えばバスの運行情報であってもよい。また、ここでいう「鉄道」は、広義の鉄道であって、ＡＧＴ（Automated Guideway Transit）、モノレールなどの類似の交通機関を含む概念であるとする。さらに、本発明の交通情報は、高速道路等の渋滞情報を含んでもよい。
【００９７】
（５）本発明に係る情報処理装置は、複数のサーバ装置の協働によって実現されてもよい。例えば、上述したサーバ装置１００は、音声認識部１１０Ａ、意図解釈部１１０Ｂ、音声合成部１１０Ｃのそれぞれに相当するサーバ装置によって実現されてもよい。
【００９８】
また、本発明に係る情報処理装置は、サーバ装置と通信端末の協働によって実現されてもよい。すなわち、上述した通信端末２００は、サーバ装置１００の機能の一部を有してもよい。例えば、通信端末２００は、音声認識部１１０Ａや音声合成部１１０Ｃに相当する機能を実行することも可能である。また、通信端末２００は、図７に示した各部の一部の機能を実行するように構成されてもよい。さらに、本発明に係る情報処理装置は、（サーバ装置ではなく）通信端末によっても実現可能である。
【００９９】
（６）本発明は、情報処理装置としてだけではなく、これを備えたサーバ装置（又は通信端末）、交通情報の報知方法、コンピュータを本発明の情報処理装置として機能させるためのプログラムなどとして特定されてもよい。また、本発明に係るプログラムは、光ディスクなどの記録媒体に記録した形態や、インターネットなどのネットワークを介してコンピュータにダウンロードさせ、これをインストールして利用可能にする形態などでも提供することができる。
【符号の説明】
【０１００】
１０…通信システム、１００…サーバ装置、１１０…制御部、１１０Ａ…音声認識部、１１０Ｂ…意図解釈部、１１０Ｃ…音声合成部、１１１…予定情報取得部、１１２…交通情報取得部、１１３…受付部、１１４…位置特定部、１１５…交通手段特定部、１１６…報知態様決定部、１１７…出力部、１１８…判断部、１２０…記憶部、１３０…通信部、２００…通信端末、２１０…制御部、２２０…記憶部、２３０…通信部、２４０…表示部、２５０…入力部、２６０…音声入出力部、２７０…測位部、３００…ネットワーク
【図１】
2015083417.tif 000003
【図２】
2015083417.tif 000004
【図３】
2015083417.tif 000005
【図４】
2015083417.tif 000006
【図５】
2015083417.tif 000007
【図６】
2015083417.tif 000008
【図７】
2015083417.tif 000009
【図８】
2015083417.tif 000010
【図９】
2015083417.tif 000011
【図１０】
2015083417.tif 000012