情報取得方法
【課題】 移動履歴からユーザの移動先を予測し、予測先に関連する情報を取得する技術において、移動先の予測の精度を、従来よりも向上させる。
【解決手段】 カーナビなどの情報取得装置において、履歴蓄積ＤＢ１０４はユーザの移動履歴を蓄積する。条件決定部１０７は精度良く予測を行うための検索用条件を決定し、予測部１０８はこの検索用条件を用いて移動先に関する予測を行う。提示情報決定部１１０は予測部１０８によって予測された移動先に関する情報を、受信情報ＤＢ８０２などから取得する。
【解決手段】 カーナビなどの情報取得装置において、履歴蓄積ＤＢ１０４はユーザの移動履歴を蓄積する。条件決定部１０７は精度良く予測を行うための検索用条件を決定し、予測部１０８はこの検索用条件を用いて移動先に関する予測を行う。提示情報決定部１１０は予測部１０８によって予測された移動先に関する情報を、受信情報ＤＢ８０２などから取得する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、カーナビや携帯電話、ＰＤＡ等の位置情報のセンシングが可能な情報機器を用いて、ユーザの移動履歴を蓄積し、この移動履歴から移動先を予測し、予測した移動先に関連する情報をネットワーク等を利用して取得する技術に関するものである。
【背景技術】
【０００２】
インターネットの普及により、我々の身の回りには実に様々な情報があふれている。情報機器を利用するユーザは、キーワードを情報機器に入力することによって、検索したい情報にアクセスすることができるが、自分の欲する情報がある度に、情報と直接結びつくキーワードをユーザ自身が毎回入力する作業は、非常に手間がかかるものである。例えば、移動中に携帯電話などの端末に入力を行ったり、車で移動中にカーナビに設定を行うのは手間であるし、場合によっては危険な操作となる。このため、カーナビのユーザは、目的地の設定などを行わないで走行することも多い。
【０００３】
このような問題の解決策の１つとして、ユーザが必要とするであろう情報を、ユーザの行動を予測することによって予め取得し提示する方法が考案されている。
【０００４】
例えば、車載端末において運転の開始位置および終了位置をその日時などの条件とともに走行履歴として記憶しておき、ユーザのエンジン始動を検出すると、現在の位置および日時などの条件をキーとして走行履歴を検索し、過去に最も高い頻度で行った目的地と、過去にその目的地までの走行に要した時間とを参照して、ユーザに目的地および所要時間を自動的に示す車載情報装置が、提案されている（特許文献１参照）。
【０００５】
また、情報端末を所持するユーザの行動を移動行動と停止（滞在）行動という単位で分割し、ある行動に関して、出現頻度、並びに直前および直後の行動内容などの情報をひとまとまりとし、移動履歴としてサーバに記憶しておき、サービスプロバイダが指定した条件（例えば、日曜の９〜１４時の間に京都駅周辺にいること）を満たすユーザを、履歴情報から行動予測することで見つけ出し、該当するユーザに対して広告情報を提供する情報提示方法が、提案されている（特許文献２参照）。
【特許文献１】特開平１１−１４９５９６号公報（特に第１図）
【特許文献２】特開２０００−２９３５４０号公報（特に第１図）
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、上述の従来技術には、次のような問題がある。
【０００７】
まず、目的地に関する予測結果は、条件の選択（日付を指定するか、日付と出発時刻を指定するか、さらに天気を含めるのか、など）によって異なり、また必要な条件は出発地に応じても異なってくることが予想される。このため、適切な検索条件を選択することは、予測を成功させるために非常に重要である。しかしながら、上述の特許文献１，２ではいずれも、このような観点に関する記載はない。
【０００８】
また、特許文献１では、検索に用いる履歴データベースは出発地と目的地の組合せを時系列に記憶しているだけなので、データベースを検索するのに計算コストがかかり、例えばエンジン起動時に動作を開始すると、予測結果が得られるまでに時間がかかりすぎる、という問題がある。また、所要時間の算出において、過去の走行実績のみを参照し、現在の渋滞度合などは参照していないため、正確な算出ができない場合がある。さらに、履歴データベースにはユーザの走行経路までは記憶されていないので、ユーザが走行すると思われる経路に関する予測を行うことができず、現在の渋滞度合や道路情報を参照できたとしても、経路上に関連する道路情報などの有益な情報をユーザに提示することができない。さらには、出発地が分かれば目的地が特定できる、ということは少なく、走行していくに従って、出発地を含んだ経路情報が分かってはじめて予測が成り立つという場合が非常に多い。
【０００９】
また、特許文献２では、同一出発地および同一目的地を結ぶ移動行動はその経路の違いによらずひとまとまりとして記憶しているため、複数の経路が存在する際に正確な経路の予測を行うことができない。また、前後の行動との関係しか記憶されていないため、４つ以上の連続した行動に関しては、ユーザの行動を再現することができないため、不完全な予測となってしまう。また、予測を行うための条件は、サービスプロバイダまたはユーザが指定しなければならないが、上述のように、精度の高い予測ができるように適切な条件を選択することは困難である。
【００１０】
前述した問題に鑑み、本発明は、移動履歴からユーザの移動先を予測し、予測先に関連する情報を取得する技術において、移動先の予測の精度を、従来よりも向上させることを課題とする。
【課題を解決するための手段】
【００１１】
本発明は、移動体の移動先に関連する情報を取得する情報取得方法として、移動体の位置情報の履歴から得た移動経路を移動履歴としてリンク間の推移の形式で蓄積する第１のステップと、前記移動履歴を検索する際のキーの種類およびカテゴリーを検索用条件として決定する第２のステップと、前記移動履歴に対して前記検索用条件に従った検索を行い、この検索結果に基づいて、移動体が進行する移動先または移動経路を１つ以上予測する第３のステップと、予測した移動先または移動経路に関連する情報を取得する第４のステップと、前記第４のステップにおいて取得した情報を基にして、前記移動先についての提示情報を決定する第５のステップとを備えたものである。
【００１２】
本発明によると、蓄積された移動履歴を検索する際の、キーの種類およびカテゴリーが、検索用条件として決定され、この検索用条件に従った検索の結果に基づいて、移動体が進行する移動先または移動経路が予測される。ここでのキーの種類としては、時刻、日付、天気、運転者、同乗者などが挙げられる。また、ここでのカテゴリーとは、キーの区分または尺度のことをいい、例えば、時刻については、「８時３０分」という時刻に関して、「朝」「６時〜１０時」「８時〜９時３０分」など、抽象度のレベルという意味で様々な尺度のカテゴリーが考えられるし、日付については「金曜日」という曜日に関して、「平日」というカテゴリーで捉えるか「週末」というカテゴリーで捉えるか、などまとめ方についての様々な尺度のカテゴリーを考えることができる。同様に例えば、天気については「晴れ」「降水確率４０％未満」など、運転者や同乗者については「佐藤家のユーザ」「２５歳以上」「お父さん」など、を考えることができる。このように、移動履歴を検索する際の検索用条件を予め決定してから予測を行うことによって、従来よりも精度の高い予測を行うことができ、したがって適切な情報を取得することができる。さらに、移動体の移動先について、従来よりも精度の高い予測を行うことができ、適切な情報を取得することができるので、ユーザにより適切に情報を提示することができる。
【発明を実施するための最良の形態】
【００１３】
本発明の第１態様では、移動体の移動先に関連する情報を取得する情報取得方法として、移動体の位置情報の履歴から得た移動経路を移動履歴としてリンク間の推移の形式で蓄積する第１のステップと、前記移動履歴を検索する際のキーの種類およびカテゴリーを検索用条件として決定する第２のステップと、前記移動履歴に対して前記検索用条件に従った検索を行い、この検索結果に基づいて移動体が進行する移動先または移動経路を１つ以上予測する第３のステップと、予測した移動先または移動経路に関連する情報を取得する第４のステップと、前記第４のステップにおいて取得した情報と、位置と、名称と、当該位置が属するジャンル名との対応関係を表す情報を参照し、前記移動先の予測確率に基づいて、名称およびジャンル名のうち少なくともいずれか１つを、提示情報として決定する第５のステップとを備えたものを提供する。
【００１４】
以下、本発明の実施の形態について、図面を参照して説明する。以下の各実施形態では、特にカーナビ（カーナビゲーションシステム）を例にとって説明するが、本発明はこれに限定されるものではない。例えば、携帯電話やＰＤＡ、パソコンなど、普段ユーザが持ち歩くものであって位置情報を検出する手段を有する情報機器であれば、本発明は同様に実現可能である。また、カーナビが有する機能の一部を、ネットワーク上のサーバに設けるような構成も考えられる。
【００１５】
（第１の実施形態）
図１は本発明の第１の実施形態に係る情報取得装置としてのカーナビの構成を示す。図１において、１０１はカーナビの現在位置（カーナビが搭載された移動体としての車の現在位置）情報を検出する位置検出部、１０２は位置検出部１０１によって検出された現在位置が後述するノードに相当するか否かを判定するノード判定部、１０３はカーナビで使用する地図情報を記憶している地図情報データベースである。
【００１６】
また１０４は車の位置情報の履歴から得た移動経路を移動履歴として蓄積する履歴蓄積データベース（ＤＢ）であり、ここでは、ノード判定部１０２において現在位置がノードと判定されたとき、そのノードを記憶する。履歴蓄積ＤＢ１０４に蓄積されるデータ構造については後述する。また１０５は履歴蓄積ＤＢ１０４に蓄積されているノードの出現頻度の情報を利用して、後述する遷移状態情報を作成するために用いる，ノードの出現頻度に対する閾値を算出する閾値算出部、１０６は履歴蓄積ＤＢ１０４に蓄積された移動履歴から、車の過去の位置遷移を表す遷移状態情報を生成する遷移状態情報作成部であり、ここでは、閾値算出部１０５で算出された閾値以上の頻度で出現するノードについて、ノード間の遷移に関する情報を、その出現頻度や走行日時等の付加情報とともに作成する。ノード判定部１０２、履歴蓄積ＤＢ１０４、閾値算出部１０５および遷移状態情報作成部１０６によって、履歴蓄積部が構成される。
【００１７】
１０７は遷移状態情報を利用して、履歴蓄積ＤＢ１０４に蓄積されている現在の状態を示す情報から、適切な予測結果を得るための検索用条件を決定する条件決定部、１０８は条件決定部１０７によって決定された検索用条件を用いて、状態遷移情報から、今後の移動先の予測を行う予測部である。
【００１８】
また１０９は移動履歴を参照して、現在位置のノードと予測部１０８によって予測されたノードとの間の走行時間を算出するノード間所要時間算出部、１１０は地図情報ＤＢ１０３を参照して、予測部１０８によって予測されたノードについて、ユーザに提示する情報を決める提示情報決定部、１１１は提示情報決定部１１０によって決定された提示情報をユーザに提示する情報提示部である。提示情報決定部１１０は例えば、名称などのノードを特定する情報や、ノードまでの予想所要時間や予想到着時刻等を、提示情報として決定する。
【００１９】
図２は地図情報ＤＢ１０３に記憶されているノードに関連する情報を示す図である。本実施形態では、交差点やランドマーク、またはエリア名称などをノードという概念で表し、「○○交差点」や「△△遊園地」などの固有名称以外に、「職場」や「Ａ子さんの家」などのユーザに特有の名称を登録できるようになっている。
【００２０】
図２において、ノード番号はこれらノードに唯一に割り当てられたＩＤ番号を示し、交差点であれば「Ｃ○○」、ランドマークであれば「Ｌ○○」、エリアであれば「Ａ○○」等のように割り当てられている。またノードは、それぞれ代表点の緯度、経度情報などの位置を表す情報とともに記憶されている。緯度、経度情報はあくまで代表点の位置情報を示し、実際には、交差点、ランドマーク、エリアなどそれぞれに応じて範囲（代表点を中心とした半径など）を表す情報が存在する。例えば、交差点やランドマークであれば代表点を中心とした半径１０ｍの範囲であったり、エリアであれば代表点を中心とした半径１ｋｍの範囲であったりすることが考えられる。また、個々のエリア毎に範囲が異なっていてもよい。また位置情報は、緯度・経度の他に例えば住所であってもよい。
【００２１】
なお、ＩＤ番号の代わりに交差点やランドマーク、エリアの名称が記述されていてもよく、いずれにしてもそれらノードを唯一に特定できる情報であればよい。そして、交差点やランドマーク、エリア等のノードを特定する情報が、履歴蓄積ＤＢ１０４に蓄積される。
【００２２】
なお、ユーザの走行に応じてノードを追加したり削除したりすることもできる。例えば、交差点の中で、ユーザの車が２つ以上の方向に走行したことがあるものをノードとして定めるようにしてもよい。すなわち、図３０（ａ）に示すように、交差点ａ，ｃについては、ユーザの車は２方向以上に走行しているのでノードＮａ，Ｎｃとして定める一方、交差点ｂについては、ユーザは１方向にしか走行していないのでノードとはしない。
【００２３】
その後、図３０（ｂ）に示すように、交差点ｂについてユーザが新たな方向に走行したとすると、交差点ｂについては、ユーザは２方向以上に走行したことがあるのでノードＮｂとして追加する。あるいは図３０（ｃ）に示すように、交差点ａについて、過去の所定期間においてユーザが１方向にしか走行しなくなると、ノードＮａを削除する（ＤＮａ）。なお、このようなノードの設定には地図データは必ずしも必要でなく、ユーザの走行履歴のみを用いて行うことができる。
【００２４】
図３は履歴蓄積ＤＢ１０４に蓄積されるデータの一例を示す図である。図３の例では、ノード番号と通過時刻とが対になって、時系列に記憶されている。例えば、７月３１日の８時５分にノードＬ６を、同８時６分にノードＣ８を、さらに同８時８分にノードＣ１２を、発進、通過または停車したことを表している。ノードの系列は、図３（ａ）に示すように、出発地と目的地によるセグメント単位、つまり「エンジンをスタート（移動の開始）してからストップ（移動の終了）するまで」という単位で蓄積してもよいし、図３（ｂ）に示すように、「自宅を出発してから自宅に帰着するまで」というセグメント単位で蓄積してもよい。さらには「同じ日付」というセグメント単位等で蓄積してもよいし、セグメントなしに蓄積してもよい。移動履歴を、移動の開始から終了までというセグメントで蓄積することによって、詳細な経路情報に基づいた移動先への予測が可能となる。
【００２５】
なお図３では、時刻は月、日、時、分で表されているが、その他、年や秒、曜日等も記憶してよいし、これらの単位のいずれかの組合せのみを記憶してもよい。また、ノード系列が走行毎にセグメントされて蓄積される場合は、エンジンをスタートした時刻とストップした時刻を記載し、通過したノードに関してはそのノード番号のみを記載するようにしてもよい。さらに、このような時刻や日付に関連する情報だけでなく、天気、あるいは運転者や同乗者に関する情報など、条件決定部１０７で決定される検索用条件となるキーに関する情報が記憶されていればよい。
【００２６】
次に、本実施形態における処理の流れについて、図４に示すフローチャートを用いて説明する。
【００２７】
位置検出部１０１においてカーナビの現在位置が検出されると（ステップａ１）、ノード判定部１０２は地図情報ＤＢ１０３を参照して現在位置がノードであるか否かの判定を行う（ステップａ２）。ノード判定部１０２によりノードであると判定されると、そのノードを示すＩＤ番号が履歴蓄積ＤＢ１０４に蓄積される（ステップａ３）。このとき、時刻、日付、天気などの付帯情報も併せて蓄積される。
【００２８】
閾値算出部１０５は履歴蓄積ＤＢ１０４を参照して、遷移状態情報を構成するノードを選別するための，出現回数の閾値を算出する（ステップａ４）。閾値の算出方法は様々に考えることができる。例えば、履歴蓄積ＤＢ１０４に蓄積されたデータ量に応じて算出したり、全てのノードの出現数の分布を求めて算出したり、全てのノードの出現数の平均値を求めてその値に一定数を乗じて算出したりすればよい。どのように決定されるのでもよい。
【００２９】
閾値算出部１０５において閾値が算出されると、遷移状態情報作成部１０６は履歴蓄積ＤＢ１０４のデータを利用して、閾値以上の出現回数をもつノードを選択して遷移状態情報を作成する（ステップａ５）。
【００３０】
図５は遷移状態情報の一例を示す。遷移状態情報は図５のように、走行を開始したランドマークやエリアなどのノード（出発地）をルート直下の最上位に位置させ、それらのノードを基点として過去のノード遷移の履歴（交差点の走行履歴を表す）を木構造で表現し、走行を終了したランドマークやエリアなどのノード（目的地）を各枝の最下層に位置させる構造を有している。各ノードには、そのノードを出発、通過、到着したときの状態情報が付与されており（図５では、矩形枠に表現されたデータ）、例えば「平日の午前９時から１２時までに走行したノード」などの条件を検索のキーとして、木構造を探索することが可能になっている。また、付与されている状態情報の個数でもって、そのノードを出発、通過、到着した頻度が分かるようになっている。このように、遷移状態情報には遷移の度合に関する情報が含まれているので、蓄積された移動履歴を全探索するよりも効率のよい探索が可能となる。
【００３１】
図５では、図３で示した日付と時刻が状態情報として記載されているが、この他にも、上述した運転者や同乗者の情報など、検索用条件となるキーの情報を記載しておけばよい。また図５では、これらの状態情報を一部のノードにしか記載していないが、実際は全てのノードにこのような状態情報が記載されている。
【００３２】
遷移状態情報が作成されると、条件決定部１０７は、予測部１０８による予測に適切な検索用条件を決定する（ステップａ６）。図６は条件決定部１０７の動作の一例を示すフローチャートである。
【００３３】
条件決定部１０７は履歴蓄積ＤＢ１０４を参照して、現在の状態に関する情報を取得する。履歴蓄積ＤＢ１０４には、過去の履歴情報の他に、現在の走行に関する情報を記憶しておく領域が存在し、出発してから現在のノードに至るまでの経路を抽出できるようになっている。いま、現在地をノード「Ｃ９」、出発してからの走行履歴を「Ｌ６→Ｃ９」、日時を６月３日の１４時とする。このとき、日時などの条件（キーの種類）に関しては、図２８に示すようなテーブルを参照して、「平日」、「昼」、「夏」などの条件（カテゴリー）を抽出できるものとする。
【００３４】
条件決定部１０７はこれらの条件の中から１つの組合せ、例えば「平日、かつ、Ｃ９」を選択すると（ステップｂ１）、遷移状態情報からこの条件を満たすノードを検索する（ステップｂ２）。図５では、ノード５０１「Ｃ９」がこれに該当する。そしてこのノードを基点として、今後遷移する可能性のあるノード（最下層に位置するノード）を遷移候補ノードとして１つ選択し（ステップｂ３）、そのノードへの遷移確率を計算して（ステップｂ４）、その値を記憶しておく（ステップｂ６）。
【００３５】
遷移確率の計算方法としては次のようなものがある。このときの条件をCond、条件Condにおける基点Ｃ９の出現頻度をFreq（Ｃ９｜Cond）、遷移候補ノード（Ｌｎ）において条件Condを満たす頻度をFreq（Ｌｎ｜Cond）とすると、
遷移確率Ｐ（Ｌｎ｜Ｃ９）＝Freq（Ｌｎ｜Cond）／Freq（Ｃ９｜Cond）
として求めることができる。
【００３６】
このように１つの遷移候補ノードについて遷移確率が計算されると、この条件の下で他に遷移候補ノードがあるか否かを判定し（ステップｂ５）、存在するときはその遷移候補ノードについても同様に遷移確率を計算してその値を記憶する。
【００３７】
他に遷移候補がなくなったとき（ｂ５でＮｏ）、記憶された遷移確率から、その条件における遷移確率のエントロピーを計算し（ステップｂ７）、その値を条件とともに記憶する（ステップｂ９）。ある条件において、過去に走行したことのある目的地の１つＬｉへの走行確率をＰｉと表したときのエントロピーの計算方法の一例を式（１）に示す。
ΣＰｉ（−ｌｏｇ２ Ｐｉ） …（１）
ｉ
【００３８】
エントロピーを記憶すると、すでに選択した条件以外に、他の組合せ（例えば「平日、かつ、Ｃ９、かつ、昼」「平日、かつ、「Ｌ６→Ｃ９」、かつ、夏」など考えうる組合せ）があるか否かを判定し（ステップｂ８）、あるときは、その条件を選択して同様の動作を繰り返す。
【００３９】
そして、全ての条件の組合せについてエントロピーを計算し終えると、記憶しているエントロピーの値が最も小さい条件の組合せを、最適な検索用条件として決定する（ステップｂ１０）。すなわち、移動先を予測するために行う移動履歴の検索において、用いられるキーの種類およびカテゴリーが、検索用条件として決定される。
【００４０】
図４に戻り、条件決定部１０７によって検索用条件が決定されると、予測部１０８は検索用条件に従って移動履歴を検索し、この検索結果に基づいて、車が進行する移動先を予測する。ここでは、移動履歴から作成された遷移状態情報を参照して、今後の遷移先ノードを決定する（ステップａ７）。ノードの決定は、例えば、予測確率が最も高いノードを選択する方法、予測確率値に応じてノードに範囲を与え、乱数値が属する範囲をもつノードを選択する方法、所定値以上の確率値をもつノードは全て選択する方法、または、確率値の高いものから所定数のノードを選択する方法など、様々な方法によって実行できる。また、遷移先のノードが予測されると、遷移状態情報を参照することによって当然、予測されたノードまでの経路も予測することは可能である。
【００４１】
遷移先のノードが予測されると、ノード間所要時間算出部１０９は、現在のノードと予測先のノードとの間の所要時間を予想する（ステップａ８）。例えば、現在のノードと予測先のノードをキーとして遷移状態情報を検索し、過去にこれら２つのノード間を走行するのに要した時間の平均値を、予想所要時間とする。このとき、検索対象を日付や時間帯等の条件でさらに絞ってから所要時間を求めてもよいし、遷移状態情報に表されていない情報が履歴蓄積ＤＢ１０４に記憶されている場合は、履歴蓄積ＤＢ１０４を参照して所要時間を計算してもよい。
【００４２】
提示情報決定部１１０は、地図情報ＤＢ１０３を参照して、予測されたノードの名称やその他の情報、予想所要時間や予想到着時刻に関する情報など、ユーザに提示すべき情報を決定する（ステップａ９）。その情報は情報提示部１１１によりユーザ（ドライバや同乗者）に提示される。ユーザに情報提示する画面の一例を図７に示す。
【００４３】
なお提示する情報は、ネットワークを経由して取得することも可能である。この場合、カーナビが、受信した情報から予測された移動先または移動経路に関連する情報を選別して提示してもよいし、予測された移動先または移動経路を示す情報をカーナビからネットワーク上のサーバにアップし、サーバが関連する情報を選別し、カーナビはサーバで選別された情報のみを受信するようにしてもよい。
【００４４】
さらに後者の場合、履歴ＤＢ１０４に蓄積された履歴情報をサーバにアップロードして、サーバが、移動先の予測と予測結果に基づく情報選別との両方を行うようにしてもよい。ただし、ユーザによっては、プライバシー保護の観点から、自分の移動履歴を全てサーバにアップすることに心理的抵抗感を持つ人もいると考えられる。このようなユーザに対しては、予測された移動先という最低限の情報のみをアップする方が合理的である。すなわち、許可が得られたユーザに対してのみ、移動履歴を全てサーバにアップする、というようにしてもよい。
【００４５】
なお、本実施形態では、移動履歴から遷移状態情報を作成するとき、所定の頻度以上出現するノードのみを選別するものとしたが、これは、検索対象となるデータサイズをコンパクトにして検索効率を向上させるためである。すなわち、検索効率に特に制約がない場合等は、ノードを選別する必要は必ずしもなく、履歴蓄積ＤＢ１０４に蓄積されている全てのノードを利用して、遷移状態情報を作成するようにしてもよい。
【００４６】
また本実施形態では、遷移状態情報を、予測において利用する可能性のある状態情報を全て含むように作成し、その後、遷移状態情報を参照して、エントロピーが最小値となる条件の組合せを検索用条件として決定し、予測を行った。これ以外にも、条件決定部１０７が履歴蓄積ＤＢ１０４を参照して本実施形態と同様な処理を行って適切な条件を予め決定しておき、その条件でもって、遷移状態情報作成部１０６が遷移状態情報を作成する、という方法も考えられる。
【００４７】
なおここでは、検索用条件の決定を、ノードの遷移確率（予測した移動先の予測確率）のエントロピーを計算することによって行ったが、本発明はこれに限られるものではない。例えば、他の統計処理に基づいて、検索用条件を決定してもよい。
【００４８】
＜検索用条件の決定手法の他の例＞
（その１）
条件決定部１０７における処理の他の例について、図３１に示すフローチャートを用いて説明する。ここでは、条件のバリエーションとして，図２９に示すような、「日付」「時刻」「天気」といった各キーの種類に関する、階層化されたカテゴリー構造を想定する。
【００４９】
いま、現在までの経路情報を「Ｌ６→Ｃ９」、現在ノードをＣ９、現在の状態を「月曜日」「１４時」「晴れ」とする。
【００５０】
まず図５に示す遷移状態情報から、経路情報「Ｌ６→Ｃ９」を満たす現在ノードを検索する（ステップｆ１）。図５では、ノード５０１がこれに該当する。
【００５１】
次に、上述した方法と同様に、条件Condを経路情報「Ｌ６→Ｃ９」とした場合における各遷移候補ノードへの遷移確率を算出して、そのエントロピーを計算し、これを基準エントロピーとする（ステップｆ２）。
【００５２】
基準エントロピーを計算すると、図２９の条件カテゴリー階層の中から、現在の状態を満たす最も抽象度の高いカテゴリー「平日」「昼」「晴れ」の３つを条件候補として決定する（ステップｆ３）。
【００５３】
そして、これらの条件候補の中でまず「平日」を選択し（ステップｆ４）、条件Condとして経路情報「Ｌ６→Ｃ９」と「平日」を満たすものについてエントロピーを算出し（ステップｆ５）、これを記憶しておく（ステップｆ７）。
【００５４】
ステップｆ３で決定された条件候補の中で、すでに選択した「平日」以外のものが存在するか否かを判定する（ステップｆ６）。ここでは、「昼」「晴れ」というカテゴリーが残っているので、次に「昼」を選択し（ステップｆ４）、同様の処理を行う。
【００５５】
残りの「晴れ」についても同様の処理を行い、全ての条件候補について処理が終了すると、終了条件を満たすか否かを判定する（ステップｆ８）。
【００５６】
ここで、次の２つの判定基準のいずれかを満たしているとき、終了条件を満たすと判定する。第１の判定基準は、各条件候補についてのエントロピー、およびステップｆ２で算出した基準エントロピーの中で、基準エントロピーが最も小さい場合である。第２の判定基準は、各条件候補がいずれも図２９の階層構造における最下層のカテゴリーに該当し、さらなる具象カテゴリーが存在しない場合である。これらの場合は処理を終了し、現在選択されている条件を最適条件として決定する（ステップｆ９）。仮に、いまの段階で終了条件を満たしたとすると、この場合の最適条件は、経路情報「Ｌ６→Ｃ９」のみとなり、日付や時刻等の条件は選択されない。
【００５７】
ここでは、「昼」を選択したときのエントロピーが最も小さかったとする。この場合、このエントロピー値を基準エントロピーとする（ステップｆ２）とともに、カテゴリー「昼」を１つ具象化して「１４時〜１５時」とし、「平日」「晴れ」「１４時〜１５時」を新たな条件候補として決定する（ステップｆ３）。そして、これら新たな条件候補について同様の処理を行う（ステップｆ４〜ｆ６）。
【００５８】
ここで終了条件を満たしたとすると、最適条件は、経路情報「Ｌ６→Ｃ９」と「昼」となる。一方、終了条件を満たさなかったときは、例えば「平日」のエントロピーが最も小さくなったとすると、そのエントロピー値を基準エントロピーとして、さらにステップｆ２〜ｆ８の処理を、終了条件が満たされるまで繰り返す。
【００５９】
例えば、最適条件として「平日」「１４時〜１５時」「晴れ」というカテゴリーが決定されると、図５の遷移状態情報の中で、過去に経路「Ｌ６→Ｃ９」を走行し、「平日」「１４時〜１５時」「晴れ」であったものの事例のみを対象として遷移確率を計算し、遷移先ノードを決定すればよい。
【００６０】
（その２）
同じく図３１のフローチャートを用いて、条件決定部１０７における処理の他の例について説明する。いま、現在までの経路情報を「Ｌ６→Ｃ９」、現在ノードをＣ９、現在の状態を「月曜日」「１４時」「晴れ」とする。
【００６１】
まず図５に示す遷移状態情報から、経路情報「Ｌ６→Ｃ９」を満たす現在ノードを検索する（ステップｆ１）。図５ではノード５０１がこれに該当する。そして上述した方法と同様に、条件Condを経路情報「Ｌ６→Ｃ９」とした場合における各遷移候補ノードへの遷移確率を算出して、そのエントロピーを計算し、これを基準エントロピーとする（ステップｆ２）。
【００６２】
基準エントロピーを計算すると、図２９の条件カテゴリー階層において、「ＲＯＯＴ」から１段階具象化したカテゴリーを条件候補として決定する（ステップｆ３）。具体的には，日付条件において「平日」「休日」、時刻条件において「朝」「昼」「夜」、天気条件において「晴れ」「くもり」「雨」を条件候補とする。
【００６３】
これらの候補の中からまず、曜日条件を具象化したカテゴリー「平日」「休日」を選択し（ステップｆ４）、図５の遷移状態情報の中で、経路情報「Ｌ６→Ｃ９」を満たすものを対象として，「平日」「休日」というカテゴリーで分類した場合の遷移確率およびエントロピーを算出し（ステップｆ５）、エントロピー値を記憶しておく（ステップｆ７）。
【００６４】
次に、時刻条件を具象化したカテゴリー「朝」「昼」「夜」を選択し（ステップｆ４）、図５の遷移状態情報の中で、経路情報「Ｌ６→Ｃ９」を満たすものを対象として、「朝」「昼」「夜」というカテゴリーで分けた場合の遷移確率およびエントロピーを算出し（ステップｆ５）、エントロピー値を記憶しておく（ステップｆ７）。天気条件についても同様にエントロピーを計算する。
【００６５】
そしてステップｆ８では、上述したように終了条件の判定を行う。
【００６６】
例えば、時刻条件を「朝」「昼」「夜」に具象化した場合のエントロピーが最も小さいとすると、次回のステップｆ３では、「平日」「休日」というカテゴリー、「晴れ」「くもり」「雨」というカテゴリー、「朝」を具象化した「６時〜７時」「８時〜９時」「１０時〜１１時」というカテゴリー、「昼」を具象化した「１２時〜１３時」「１４時〜１５時」「１６時〜１７時」というカテゴリー、「夜」を具象化した「１８時〜１９時」「２０時〜２１時」「２２時〜２３時」というカテゴリー、以上合計５通りの条件候補を決定する。
【００６７】
上述した２つの処理の違いは、前者が、図５の遷移状態情報に示す過去の走行データの中で、曜日や時刻等の状態情報が現在状態と同一の条件を満たすもののみを対象にしてエントロピーを計算する（例えば、現在が月曜日であり曜日条件として「平日」が与えられると、同一経路であった過去の事例のうち、「平日」であったもののみのエントロピーを計算する）のに対して、後者は、同一経路であった全事例を対象にしてエントロピーを計算している点である。
【００６８】
なお、図２９のような条件カテゴリーはユーザによって異なる（例えば、あるユーザの休日は土曜と日曜だが、別のユーザの休日は月曜と火曜であるなど）ことが考えられるので、このような条件カテゴリーを取得する手段を設け、ユーザ毎に異なる条件カテゴリーを利用するようにしてもよい。
【００６９】
また本実施形態では、現在の走行を開始してから現在位置に至るまでの情報を、条件として利用するものとしたが、これ以外にも、現走行以前の走行における履歴情報（出発地や経路、日時などに関する情報）をも参照するようにしてもよい。
【００７０】
また、図２９に示すような条件カテゴリーの階層構造を、同一キー（例えば時刻条件）に対して、複数種類持たせておいてもよい。この場合、それぞれの階層構造に対してエントロピーを算出して条件を決定しておき、それらの中でエントロピーが最小となる条件を最終的な条件として予測を行えばよい。これにより、例えば「昼１２時〜１７時」の下の階層について、図２９に示す「１２時〜１３時」「１４時〜１５時」「１６時〜１７時」以外にも、「１２時〜１４時」「１５時〜１７時」というカテゴリーや、「１２時〜１３時３０分」「１３時３０分〜１５時」「１６時〜１７時」というカテゴリーなど、様々なカテゴリーを考慮することができる。
【００７１】
また本実施形態では、位置検出部１０１が位置情報を検出すると、ノード判定部１０２がノードであるか否かの判定を行い、ノードのみを履歴蓄積ＤＢ１０４に蓄積するものとしたが、それ以外にも例えば、検出された位置情報をそのまま蓄積し、その後適当なタイミングでもってノード判定部１０２が動作し、ノードのみを抽出する、という構成でもかまわない。
【００７２】
また、提示情報決定部１１０は、当初は予測された移動先の名称のみを提示情報として決定し、提示した情報に対してユーザから選択されたノードに関してのみ、予想所要時間などの情報や、その他そのノードに関連する詳細な情報を出力するようにしてもよい。あるいは、選択されたノードを目的地として、カーナビの機能である経路設定を行うようにしてもよい。
【００７３】
なお、本実施形態に係る構成に対してさらに、運転者や同乗者等のユーザを特定する情報を取得する手段を設けて、ユーザ毎に履歴蓄積データを蓄積するようにしてもよい。これにより、複数のユーザが同一のカーナビを利用している場合であっても、ユーザに応じた適切な予測が可能となり、また同乗者の違いに応じた予測も可能となる。ユーザを特定する情報の取得方法としては、ユーザに直接入力してもらう方法、ユーザが携帯する携帯電話やＰＤＡ等の情報端末とＢｌｕｅｔｏｏｔｈやＩｒＤＡなどの無線を介して通信し機器ＩＤやユーザ情報等を取得する方法、運転者を特定する情報が記憶された運転キーから判定する方法、車載カメラにより人物を判定する方法、など様々に考えられるが、特に問わない。
【００７４】
また、ユーザが登録したノード名称や固有名称以外のノード名称を表すノード情報を、地図情報ＤＢ１０３にユーザ毎に記憶しておき、取得したユーザ特定情報に応じて、参照するノード情報を変更する、といった形態が考えられる。例えば「職場」というノードを登録する場合、運転手が父親なら「○×製造株式会社」であり、長男の場合は「□△商事株式会社」である、といった事例が考えられる。さらには、各ユーザが、個別のノード情報が記録されたメモリカードを利用時にカーナビに挿入し、地図情報ＤＢ１０３およびメモリカードを参照するようにしてもよい。あるいは、ノード情報はネットワーク上に保存してもよい。
【００７５】
また、履歴蓄積ＤＢ１０４において記憶される履歴情報は、本実施形態で示したように、交差点をノードとして、ノードの系列で蓄積する以外にも、例えば、走行した道路情報（交差点と交差点を結ぶリンク）を利用して蓄積してもよい。すなわち、ノードＣ８，Ｃ２０を結ぶ道路をリンクＬｉｎｋ（８，２０）と表現するものとすると、図３（ｂ）に示す「Ｌ６」「Ｃ８」「Ｃ２０」「Ｌ１２」という蓄積情報は、「Ｌ６」「Ｌｉｎｋ（８，２０）」「Ｌ１２」という表現で記録される。このような表現で移動履歴が蓄積された場合でも、本実施形態と同様の方法によって、移動先を予測することは可能である。
（第２の実施形態）
図８は本発明の第２の実施形態に係る情報取得装置としてのカーナビの構成を示す。図８において、図１と共通の符号を付した構成要素のうち、第１の実施形態と同様の動作をするものに関しては、詳細な説明を省く。
【００７６】
図８において、８０１はネットワークや放送波などを介して外部から情報を受信する情報受信部、８０２は情報受信部８０１が受信した情報を蓄積する受信情報ＤＢである。また、８０３はユーザからの入力を受け付けて解釈を行う入力解釈部である。提示情報決定部１１０は、予測部１０８によって予測された移動先に関して、地図情報ＤＢ１０３および受信情報ＤＢ８０２、並びに入力解釈部８０３の解釈を参照して、ユーザに提示する情報を決定する。
【００７７】
図９は地図情報ＤＢ１０３に記憶されている情報の一例を示す。図９に示すように、本実施形態では、図２に示したようなノードの位置（図９では図示せず）や名称を表す情報の他に、各ノードが属するジャンルに関する情報が、地図情報ＤＢ１０３に格納されている。例えば、ノードＩＤ「Ｌ３」は、名称が「Ｃコープ」であり、ジャンル「スーパー」に属している。
【００７８】
図１０は情報受信部８０１が受信して受信情報ＤＢ８０２に蓄積された情報の例を示す。図１０の例では、情報を有するランドマークやエリアの名称、緯度・経度など位置を表す情報、関連する詳細な情報、および画像や動画などのその他の情報が蓄積されている。位置を表す情報としては、緯度・経度の他に、住所等を用いてもよい。
【００７９】
次に、本実施形態における提示情報決定部１１０の動作を図１１のフローチャートを用いて説明する。なお、本実施形態では、予測部１０８は、図１２に示すように、複数の移動先を予測するとともにその予測確率を求めるものとする。
【００８０】
まず、予測部１０８によって予測されたノードのうち１つを予測候補として選択し（ステップｃ１）、選択したノードの名称を地図情報ＤＢ１０３から検索する（ステップｃ２）。ここでは、図１２に示されたノードの中からノード「Ｌ１３１」を選択し、このノード「Ｌ１３１」の名称として「亀谷ゴルフ」を得る。
【００８１】
そして、ステップｃ１で選択したノードへの予測確率が所定値以上であるか否かを判定する（ステップｃ３）。本実施形態では、所定値は“０．２５”とする。このとき、ノード「Ｌ１３１」の予測確率は０．３１であり所定値以上であるので、提示情報の候補としてそのノード名称「亀谷ゴルフ」を記憶しておく（ステップｃ４）。
【００８２】
「Ｌ１３１」以外にまだ予測候補のノードが存在するので（ステップｃ８でＹｅｓ）、次の候補「Ｌ１８」を選択して（ステップｃ１）、ノードの名称を検索して名称「ボンジュール」を得る（ステップｃ２）。「Ｌ１８」も予測確率が０．２６であり所定値以上であるので、「Ｌ１３１」と同様にノード名称「ボンジュール」が記憶される。
【００８３】
次の候補として「Ｌ３」を選択し（ステップｃ１）、名称「Ｃコープ」を得る（ステップｃ２）。ところが、その確率値は０．１８であり所定値以下であるので（ステップｃ３でＮｏ）、地図情報ＤＢ１０３を参照してノード「Ｌ３」のジャンル名「スーパー」を取得する（ステップｃ５）。そして、ジャンル「スーパー」とノード「Ｌ３」の名称「Ｃコープ」とのリンク情報を作成し（ステップｃ６）、提示情報の候補としてそのジャンル名およびノード名を記憶する（ステップｃ７）。
【００８４】
残りのノード「Ｌ５２」に関しても同様の処理を行い、処理の結果、図１３に示すような提示情報の項目が決定される（ステップｃ９）。このようにして提示情報の項目を決定すると、受信ＤＢ８０２を参照してそれらの項目に対応する情報を検索して提示する内容を決定する（ステップｃ１０）。
【００８５】
図１４は提示情報決定部１１０によって決定され、情報提示部１１１によって提示された情報の例である。提示情報は、図１４（Ａ）のトップページから（Ｂ）または（Ｃ）（Ｄ）とリンクをたどれるように構成されており、入力解釈部８０３でユーザの指示入力が解釈されると、それに応じてリンク先の情報が提示される。さらに図１４（Ｂ）（Ｄ）に示す各店舗の画面では、受信情報ＤＢ８０２に蓄積されている情報として、テキスト情報の他に、画像や動画などの情報が再生される。
【００８６】
これらの情報がカーナビの画面でユーザに提示される例を図１５に示す。すなわち、予測確率が所定値以上の移動先「Ｌ１３１」「Ｌ１８」については、その名称「亀谷ゴルフ」「ボンジュール」を、そうでない移動先「Ｌ３」「Ｌ５２」については、そのジャンル名「スーパー」を、提示情報として決定・提示している。このように、予測確率がさほど高くない候補地をジャンルとして提示することによって、誤った予測地の提示によってユーザに不快感を与える可能性を下げることができる。
【００８７】
なお、情報提示の形態はこの他にも、「亀谷ゴルフ」や「ボンジュール」など予測確率が所定値以上のノードについてはトップページにおいて項目だけでなく関連する詳細な情報まで表示して、それ以外のノードに関しては項目のみを表示するようにしてもよい。また、予測確率に関係なく、トップページにはジャンルのみを表示するようにしてもよい。さらには、ジャンルではなく、全てノードの名称（ランドマーク名やエリア名）を表示するようにしてもよい。
【００８８】
また、提示対象となるランドマークが、ユーザの目的地であるか、あるいは予測した移動経路上のものであるかに応じて、表示を変更してもよい。例えば、目的地についてはノードの名称を、経路上のノードについてはジャンル名称を表示するようにしてもよい。
【００８９】
また、第１の実施形態で述べたように、予測部１０８によって移動先のノードが予測されると当然そのノードまでの経路についても予測可能であるので、予測されたノード（ランドマーク）に関する広告情報以外にも、予測経路付近に存在するランドマークに関して広告情報を提示するようにしてもよい。
【００９０】
また、提示情報として、第１実施形態で述べたような所要時間に関する情報を提示してもよいし、地図情報ＤＢ１０３に蓄積されている予測先に関連する情報を提示してもよい。
【００９１】
（第３の実施形態）
図１６は本発明の第３の実施形態に係る情報取得装置としてのカーナビの構成を示す。図１６において、図１および図８と共通の符号を付した構成要素のうち、第１および第２の実施形態と同様の動作をするものに関しては、詳細な説明を省く。
【００９２】
ここでは、情報受信部８０１、受信情報ＤＢ８０２、予測部１０８、ノード間所要時間算出部１０９および提示情報決定部１１０の動作について説明する。
【００９３】
情報受信部８０１はネットワークや放送波などを利用して道路・交通に関する情報を受信し、受信情報ＤＢ８０２は受信した道路・交通情報を蓄積する。
【００９４】
予測部１０８は、遷移先のノードを１つ以上予測すると、現在ノードからそれらのノードに至るまでのノードの遷移系列、すなわち移動経路を１つ以上予測する。
【００９５】
ノード間所要時間算出部１０９は、現在のノードと予測先のノード（現在の走行の目的地）との間の所要時間を算出する。例えば、第１の実施形態で述べたように、遷移状態情報作成部１０６により作成された遷移状態情報を参照して、現在ノードと予測先ノードとの間の過去の走行時間の平均値を、予想所要時間として算出する。このとき、検索対象を日付や時刻等の条件でさらに絞ってから所要時間を求めてもよいし、遷移状態情報に表されていない情報が履歴蓄積ＤＢ１０４に記憶されている場合は、履歴蓄積ＤＢ１０４を参照して所要時間を計算してもよい。このような処理以外でも、提示情報決定部１１０が受信情報ＤＢ８０２および地図情報ＤＢ１０３の情報を受けて選択した２つ以上のノードのうち、予測部１０８によって予測された移動経路に含まれる任意の２個のノード間の平均走行時間などを計算することも可能である。
【００９６】
提示情報決定部１１０は、受信情報ＤＢ８０２および地図情報ＤＢ１０３を参照して、ノード間所要時間算出部１０９に伝達すべき２つ以上のノードを選択する。また、予測部１０８によって予測された経路情報、ノード間所要時間算出部１０９によって算出された所定のノード間の予想所要時間、および受信情報ＤＢ８０２に蓄積された道路・交通情報を参照して、ユーザに提示すべき情報を決定する。
【００９７】
本実施形態における処理の流れについて、図１７のフローチャートを用いて説明する。
【００９８】
まず、予測部１０８が、１つ以上の経路情報を予測する（ステップｄ１）。図１８は予測された経路情報の一例である。経路情報の個数は、図１８のように複数であってもよいし、１個であってもよい。
【００９９】
ステップｄ１において予測がなされると、提示情報決定部１１０は受信情報ＤＢ８０２に蓄積されている道路・交通情報と、図１８に示すような予測経路情報とを比較して、予測経路に関連する道路・交通情報が存在するか否かを判定する（ステップｄ２）。図１９は道路・交通情報の具体例を示す。図１９に示すように、ここでの道路・交通情報は、道路名称、区間、および、関連する情報などの項目からなる。区間情報を構成する要素は、図２に例示したように地図情報ＤＢ１０３に記憶されているものとする。
【０１００】
ここでの判定方法について説明する。提示情報決定部１１０は、まず図１９に示すような道路・交通情報の区間情報を、地図情報ＤＢ１０３を参照して、ノード表現に変換する。例えば「巣本北〜巣本南」という区間情報は、「Ｃ１３→Ｃ２０」というようなノード情報に変換される。次に、図１８の予測経路情報と照合して、変換されたノード情報と一致する区間があるか否かを判定する。この判定の結果、優先番号１の経路に「Ｃ１３→Ｃ２０」が含まれていることが分かる。すなわち、ステップｄ２の結果、この区間「Ｃ１３→Ｃ２０」が選択される（ステップｄ３）。
【０１０１】
そしてノード間所要時間算出部１０９は、遷移状態情報を参照して、優先番号１の経路を過去に走行するのに要した平均所要時間（以下、経路平均所要時間という）、および提示情報決定部１１０により選択されたノード間「Ｃ１３→Ｃ２０」を過去に走行するのに要した平均所要時間（以下、区間平均所要時間という）を算出する（ステップｄ４）。ここでは、経路平均所要時間および区間平均所要時間が、それぞれ「８０分」「２０分」と算出されたものとする。
【０１０２】
次に、提示情報決定部１１０は、受信情報ＤＢ８０２に関連情報として蓄積されている「Ｃ１３→Ｃ２０」に相当する区間の所要時間「３０分」と、ノード間所要時間算出部１０９により算出された区間平均所要時間「２０分」とを比較して、差分時間「１０分」を算出する（ステップｄ５）。そして、この差分時間「１０分」と経路平均所要時間「８０分」を加味して、予測される所要時間として「９０分」を決定する（ステップｄ６）。
【０１０３】
提示情報決定部１１０はさらに、地図情報ＤＢ１０３を参照して、ノード番号からランドマークなどの名称への変換を行い、ユーザに提示すべき情報を決定する（ステップｄ７）。
【０１０４】
情報提示部１１１によってユーザに提示される画面の例を図２０に示す。図２０では、予想される目的地の名称、道路・交通情報を参照して求めた予想所要時間、および受信した道路・交通情報が提示されている。
【０１０５】
なお、提示情報の形態は、ここで示したものに限られず、例えば、予測経路に関連する道路・交通情報のみを提示するようにしてもよい。この場合には、ノード間所要時間算出部１０９は不要となる。
【０１０６】
（発展例）
上述の第３の実施形態を発展させた例として、図２１に示すような構成が考えられる。図２１において、図１６と異なるのは、経路探索部２１０１を設けた点である。
【０１０７】
経路探索部２１０１の動作について説明する。図１７の所要時間比較ステップｄ５または所要時間決定ステップｄ６において、今後進行が予想される経路では過去の平均所要時間よりも多くの時間が必要になると判定された場合、経路探索部２１０１は、図１８に示すような予測経路情報と受信情報ＤＢ８０２から読み出された情報を提示情報決定部１１０から受けるとともに、地図情報ＤＢ１０３を参照して、予測経路よりも所要時間が短くてすむ経路を探索する。探索のためのアルゴリズムに関しては特に問わず、ここでは詳細な説明は省略する。所要時間が短い経路を探索できたときは、この経路に関する情報を情報提示部１１１がユーザに提示する。
【０１０８】
またこのとき、経路探索部２１０１は、履歴蓄積ＤＢ１０４や遷移状態情報、またはノード間所要時間算出部１０９を参照して、過去にユーザが走行したことがありかつ所要時間がより短い別ルートを、優先的に探索することも可能である。
【０１０９】
また、別ルートの探索は、上述したような所要時間に関する制約が満たされない場合だけでなく、例えば、予想経路に関して通行止めなどの規制情報があった場合に行ってもよい。
【０１１０】
（第４の実施形態）
図２２は本発明の第４の実施形態に係る情報取得装置としてのカーナビの構成を示す。図２２において、図８と共通の符号を付した構成要素のうち、第２の実施形態と同様の動作をするものに関しては、詳細な説明を省く。
【０１１１】
２２０１は履歴蓄積ＤＢ１０４を参照して、ユーザが立ち寄ったことがある各ノード（ランドマーク、エリア）について、移動履歴に現れた頻度を計算する頻度算出部、２２０２は頻度算出部２２０１が計算した頻度を記憶するための頻度記憶ＤＢである。
【０１１２】
図２３は本実施形態において提示情報決定部１１０が提示情報を決定する動作を示すフローチャートである。
【０１１３】
提示情報決定部１１０は、予測部１０８から図１２のような予測結果を受けると、予測された移動先の中から１つを予測候補として選択する（ステップｅ１）。そして選択した予測候補の予測確率を参照し（ステップｅ２）、これが所定値以上のときは、この予測候補をユーザに提示する候補として記憶する（ステップｅ６）。一方、確率値が所定値以下のときは、頻度記憶ＤＢ２２０２を参照して、この予測候補の頻度を取得し（ステップｅ３）、これが所定値以上のときは、この予測候補をユーザに提示する候補として記憶し（ステップｅ６）、所定値以下のときは記憶しない。そして、他に予測候補があるか否かを検索し（ステップｅ５）、予測候補があるときは同様の動作を繰り返し行う。
【０１１４】
全ての予測候補について処理が終わると、記憶しておいた提示候補の予測先に関する情報を提示する項目として決定し（ステップｅ７）、これらに関連する情報を地図情報ＤＢ１０３や受信情報ＤＢ８０２を参照して提示内容として決定する（ステップｅ８）。
【０１１５】
なお、提示候補の決定方法は、ここで示したもの以外にも様々に考えることができる。例えば頻度を用いる場合、頻度が所定値以上であることを情報提示の条件とする代わりに、過去にユーザが行ったことがあるランドマークやエリアの総頻度数に占める予測候補ノードの頻度の割合が所定値以上であるか否か、という基準を用いてもよい。また、頻度記憶ＤＢ２２０２は、第２の実施形態で示したようなジャンルの単位で頻度を記憶するようにし、予測候補ノード単独の頻度ではなく、ノードが属するジャンル全体の頻度を判定の基準としてもよい。さらには、各予測候補ノードについて、予測部１０８によって得られた予測確率と、頻度記憶ＤＢ２２０２に記憶された頻度との両方の尺度を考慮して判定するようにしてもよい。
【０１１６】
（第５の実施形態）
図２４は本発明の第５の実施形態に係る情報取得装置としてのカーナビの構成を示す。図２４において、図１と共通の符号を付した構成要素のうち、上述の各実施形態と同様の動作をするものに関しては、詳細な説明を省く。
【０１１７】
２４０１は予測部１０８によって予測先が決定されると、現在の遷移状態情報と予測結果から、第１の実施形態と同様に、ユーザが予測通りに走行したと仮定したときの走行後の擬似的な遷移状態情報を作成する擬似遷移状態情報作成部である。また２４０２は、擬似遷移状態情報作成部２４０１によって作成された擬似的な遷移状態情報から、第１の実施形態と同様に、擬似的な検索用条件を決定する擬似条件決定部である。
【０１１８】
ここで、第１の実施形態において図２９のカテゴリー階層を用いて説明した２種類の動作のうち、前者の動作を擬似条件決定部２４０２が行うためには、予測した移動先を出発する際の状態（曜日や時刻、天気など）に関する情報が必要となる。なお、擬似条件決定部２４０２が後者の動作を行う場合は、このような状態情報は必要ではないが、予測部１０８においては必要となる。
【０１１９】
これらの情報の取得方法としては次のようなものが考えられる。履歴蓄積ＤＢ１０４を検索すると、現在地から予測した移動先（目的地）に到着した場合に、その目的地を出発するまでに要した時間（以下、滞在時間という）の平均を算出できる。この滞在時間を、予測した移動先への到着予想時刻に加味することによって、予測した移動先を出発する際の曜日や時刻などに関する状態を取得可能となる。
【０１２０】
履歴蓄積ＤＢ１０４を検索して滞在時間の平均を算出する際に、これらの時間の分散が大きい場合は平均値の信頼性は下がる。この場合は、滞在時間を分散の小さいいくつかのまとまりに分割し、各まとまりの平均値を滞在時間候補として算出し、これらの候補全てに関して、擬似条件決定または予測を行うようにすればよい。
【０１２１】
なお、予測された目的地を出発する状態が、予め取得していた状態情報と乖離している場合は、改めて第１の実施形態に示したような通常の予測処理を行えばよい。
【０１２２】
通常、遷移状態情報作成部１０６や条件決定部１０７における処理が完了するまでには時間がかかる。このため、現在位置を検出して移動履歴を更新し、最新の遷移状態情報を作成して最適な検索用条件を決定する、という一連の処理を、例えば車のエンジンを始動したときに行うものとすると、情報提示までに時間がかかりすぎてしまう。すなわち、ユーザがエンジンを始動した際にすぐ、予想される目的地に関する情報を提示する、といったことが困難になる。
【０１２３】
そこで、ある走行においてユーザの移動先や移動経路が予測されたとき、ユーザがその移動先を出発するための行動（例えば、エンジンを始動する、車のドアを開ける、など）を起こす前に、予め次のような処理を行っておく。
【０１２４】
すなわち、擬似遷移状態情報作成部２４０１および擬似条件決定部２４０２によって、次の走行においてエンジンを始動したとき、つまり、現在予想している目的地においてエンジンを始動したときの擬似的な遷移状態情報の作成とそのときの検索用条件の決定を行っておく。これにより、次回の走行でエンジンを始動したときは短い時間で予測を完了することができるので、予想される目的地（新たな移動先や移動経路）に関する所要時間情報やその他関連する情報などを速やかにユーザに提示することが可能となる。
【０１２５】
なお、擬似遷移状態情報や擬似条件を用いた予測は、エンジンを始動したときにのみ行われるのではなく、前もって予測しておきたいという如何なるタイミングにおいても行うことが可能である。
【０１２６】
また、擬似遷移状態情報の作成や擬似条件の決定、あるいはこれらを用いた予予測を行うタイミングとしては、他にも例えば、予測された移動先への確率値が所定の閾値を超えたとき等が考えられる。
【０１２７】
また、図２４のような構成以外でも、擬似遷移状態情報作成部２４０１や擬似条件決定部２４０２を設けない構成も考えられ、この構成では、擬似遷移状態情報や擬似条件の代わりに、予測部１０８によって予測がなされた時点で作成されている最新の遷移状態情報や検索用条件を用いるようにすればよい。
【０１２８】
また、提示する情報や予測の方法については、上述の各実施形態で示したいずれであってもよいし、提示するタイミングとしては、カーナビが起動したときのオープニング画面において提示するのが有効であるが、オープニング画面が終了した後の画面でもよい。また、ある走行が終了したときの画面に、次に走行すると予測される目的地の候補と所要時間の情報や経路上の交通情報などを提示することは、ユーザにとって、所定時刻に目的地に到着するための次の出発時刻の目安となるため、非常に有効である。そこで、例えば上述した方法により算出した出発予想時間どおりに出発したと仮定した場合の目的地の候補と到着予想時刻、交通情報を表示するようにしてもよい。または、ノードでの平均的な滞在時間に関する情報を取得することができれば、その時間を基準として３０分や１時間間隔での、各出発時刻に対する目的地の候補と到着予想時刻、交通情報を表示するようにしてもよい。走行の終了は、目的地で自車位置がしばらく変化しない、ギアがパーキングに入った、サイドブレーキがひかれた、等の事象を検知することによって、検出することができる。
【０１２９】
（第６の実施形態）
図２５は本発明の第６の実施形態に係る情報取得装置としてのカーナビの構成を示す。図２５において、図８と共通の符号を付した構成要素のうち、上述の各実施形態と同様の動作をするものに関しては、詳細な説明を省く。
【０１３０】
図２５において、提示情報決定部１１０は、上述の実施形態と同様に、予測部１０８による予測結果を受け、受信情報ＤＢ８０２に蓄積された情報のうち予測された移動先等に関する情報を提示情報として決定する。さらに本実施形態では、提示情報を決定する際に、情報提示を受けるユーザの認知的負荷を考慮する。
【０１３１】
また、２５０１は運転者等の認知的負荷の高い状態のユーザに対する情報提示を行う第一情報提示部、２５０２は例えば助手席や後部座席にいる人など運転者に比べて認知的負荷がそれほど高くないユーザに対する情報提示を行う第二情報提示部である。２５０３は提示情報決定部１１０が決定した提示情報を音声出力するためのデータを作成する音声合成部であり、第一情報提示部２５０１は提示情報決定部１１０において提示が決定されたテキスト・画像などの情報とともに、音声合成部２５０３により合成された音声情報も提示する。一方、第二情報提示部２５０２は提示情報決定部１１０において提示が決定されたテキスト・画像などの情報を提示する。
【０１３２】
いま、予測部１０８が移動先として「Ｆマート」を予測したとする。そして受信情報ＤＢ８０２に、図２６に示すような情報が「Ｆマート」について蓄積されているものとする。
【０１３３】
提示情報決定部１１０は図２６の情報を基にして、所定の規則に応じて、第一および第二情報提示部２５０１，２５０２に提示すべき情報をそれぞれ決定する。所定の規則としては、例えば「認知的負荷の高いユーザへはインデックス情報を音声読み上げで提供し、認知的負荷の低いユーザへは詳細な説明や画像・動画を含めて提供する」などが考えられる。この規則に則り、提示情報決定部１１０は、第一情報提示部２５０１への出力として図２６のインデックス情報である「特売情報」を音声で読み上げる情報を、第二情報提示部２５０２への出力として図２６の詳細な説明やその他に含まれる画像情報を提示することを決定する。
【０１３４】
図２７（Ａ）は第一情報提示部２５０１による情報提示の例を、図２７（Ｂ）は第二情報提示部２５０２による情報提示の例を、それぞれ示す。図２７（Ａ）の例の場合、ユーザに対して音声によりインデックス情報を通知した後、ユーザから音声やコマンドなどによって詳細な情報取得への要求があった場合は、図２７（Ｂ）に示すような詳細な情報の表示または音声による読み上げ等を行うようにしてもよい。
【０１３５】
このように本実施形態によると、ある情報を取得した際、情報閲覧者の認知的負荷に応じて、提示情報を決定する。例えば、認知的負荷が小さい状態で閲覧可能なユーザには、詳細な情報や画像・動画などのメディアを提供し、認知的負荷が大きい状態のユーザには、音声で読み上げたり、要約した情報を提供したりする。これにより、ユーザは、自分の認知的負荷の大小に応じた情報提供を受けることができる。
【０１３６】
なお、提供する情報内容は上述したものに限られず、ユーザの認知的な負荷を考慮して情報提示がなされればよい。
【０１３７】
また、本実施形態のように、ユーザの認知的負荷の度合に応じて情報提示部を複数個設ける代わりに、例えば、認知的負荷の度合を判定する認知的負荷判定手段を設けて、単一の情報提示部から提示する情報内容を、判定した認知的負荷の度合に応じて変更するようにしてもよい。例えば、車の状態を検出して、停車状態のときは認知的負荷が小さいと判定して詳細な情報や画像・動画等を提供する一方、走行状態のときは認知的負荷が大きいと判定して音声読み上げや要約情報により情報を提供するようにすればよい。
【０１３８】
なお、上述の各実施形態では、ユーザに情報を提供する機器としてカーナビを想定して説明を行ったが、本発明において、対象となる情報機器はカーナビに限定されるものではない。例えば、携帯電話やＰＤＡなどユーザが日常的に持つ情報端末等であっても、位置情報のセンシングが可能であれば、上述の各実施形態と同様に実施することができる。また移動手段に関しても、上述の各実施形態ではカーナビを装着した車を移動体としたが、これ以外の場合、例えば、情報機器を携帯した移動体としての人が徒歩や電車等で移動する場合でも、本発明は同様に実現可能である。
【０１３９】
また、各実施形態において、図示した構成を全てカーナビ内部に設ける例を示したが、本発明はこれに限るものではなく、少なくとも位置検出部１０１および情報提示部１１１（あるいは、第一および第二情報提示部２５０１，２５０２）がユーザのもつ情報端末に備わっていればよい。それ以外の機能の全てまたは一部は、ネットワーク接続された外部のサーバに設けるようにしてもよい。すなわち、位置検出部１０１が検出した位置情報がサーバに送信され、そのサーバに蓄積されて、サーバにおいて予測がなされたら予測地に関する情報などをカーナビに送信する、といった構成である。このような構成は、情報機器が携帯電話やＰＤＡである場合には特に有効である。
【０１４０】
また、本発明に係る情報取得方法は、情報機器およびサーバのうち少なくともいずれか一方が有するコンピュータに、プログラムを実行させることによって、実現することができる。
【０１４１】
また、情報取得のためには、ネットワークを利用する代わりに、ＶＩＣＳ（Vehcle Information and Communication System ）や放送波を利用してもよい。
【０１４２】
また、各実施形態では、情報受信部８０１が受信した情報を受信情報ＤＢ８０２に蓄積しておいて、その中から予測先に関連する情報を抽出してユーザに提示する例を示したが、それ以外にも次のような構成も考えられる。すなわち、ネットワークに対して情報を送信する情報送信部を設け、予測部１０８によって移動先が予測されると、情報送信部が予測地を表す情報をサーバに送信し、サーバが蓄積された情報の中から予測地に関連する情報を抽出してカーナビに送信し、情報受信部８０１によって受信された情報を提示するという構成である。このような構成は、必要な情報だけがネットワークを介して送受信されるので、予測を行ってから情報を提示するまでに時間的な余裕がある場合には有効な構成となる。また、現在地や予測された移動先を含む広範囲の情報を予め取得して受信情報ＤＢ８０２に蓄積しておき、予測先が定まったときに、必要な情報を抽出して提示する、といった構成も可能である。
【０１４３】
また各実施形態では、遷移状態情報作成部１０６が移動履歴から遷移状態情報を作成し、この遷移状態情報を用いて条件決定部１０７や予測部１０８が動作する例について述べたが、遷移状態情報作成部１０６を設けない構成も考えられる。この場合、条件決定部１０７および予測部１０８は、図３に示したような移動履歴の情報から直接的に、検索用条件の決定および移動先の予測を行えばよい。
【０１４４】
また、各実施形態において、閾値算出部１０５、遷移状態情報作成部１０６、条件決定部１０７および予測部１０８が動作するタイミングは、様々に考えることができる。例えば、ノードを通過する度にこれら全ての要素が動作してもよい。他にも、時刻Ｔにおける走行が開始したとき、時刻Ｔ−１における走行が終了したとき、または第５の実施形態に示したように、時刻Ｔ−１における走行の途中で時刻Ｔにおける走行の開始位置の予測が完了したときなどのタイミングで、動作してもよい。または、時刻Ｔ−１の走行終了時点で閾値算出部１０５および遷移状態情報作成部１０６が動作して遷移状態情報を予め作成し、時刻Ｔにおいて走行が開始されるとき、またはノードを走行する度に、条件決定部１０７および予測部１０８が動作して、作成されている遷移状態情報に基づいて検索用条件の決定および進路の予測を行ってもよい。さらには、時刻Ｔ−１の走行終了時点で条件決定部１０７までが動作して遷移状態情報および検索用条件を決定し、時刻Ｔにおいて走行が開始されるとき、またはノードを走行する度に、予測部１０８のみが動作するのでもよい。本発明では、特にタイミングは問わない。
【０１４５】
また、各実施形態において、ユーザに情報を提示するタイミングとしては、走行を開始したときでもよいし、走行開始時からノードを通過する度に予測を行い、予測確率値が所定の閾値を超えたときでもよいし、またはユーザが情報取得の意思表示をしたときでもよいが、特に問わない。
【０１４６】
また、各実施形態ではカーナビを対象にして説明したため、出発地（エンジン起動位置）から到着地（エンジン停止位置）までを移動履歴のデータのセグメントとしたが、これに限られるものではない。例えば、携帯電話やＰＤＡなどの携帯端末では、電源の起動から終了までというセグメント、自宅を出発してから自宅に戻るまでというセグメント、同一日付というセグメント、ランドマーク登録された場所からランドマーク登録された場所までというセグメント、など様々に考えることができる。
【０１４７】
また、各実施形態において、遷移状態情報は図５のように過去の全ての履歴を反映したものである必要はなく、過去の履歴の中で，少なくとも現在の経路情報を含んでいるものを対象として、その後の遷移状態（その後の経路や目的地）と頻度などを表現するものであればよい。例えば，現在の経路が「Ｌ６→Ｃ９」であるとき、遷移状態情報は図５に示す木構造の中で少なくともこの経路を含む部分木構造であればよい。さらには，このような木構造ではなく、テーブルやマトリックスで表現されていてもよい。
【産業上の利用可能性】
【０１４８】
本発明は、例えばカーナビや携帯電話、ＰＤＡ等の情報機器を用いて、ユーザに情報提供を行う技術に利用可能であり、ユーザの移動先について精度の高い予測を行い、適切な情報を取得できるので、有効である。
【図面の簡単な説明】
【０１４９】
【図１】本発明の第１の実施形態に係る情報取得装置の構成図である。
【図２】地図情報データベースに記憶されているノード関連情報を示す図である。
【図３】（ａ），（ｂ）は履歴蓄積データベースに蓄積される移動履歴データの一例を示す図である。
【図４】本発明の第１の実施形態における処理の流れを示すフローチャートである。
【図５】遷移状態情報の一例を示す図である。
【図６】条件決定部の動作の一例を示すフローチャートである。
【図７】ユーザに情報提示する画面例を示す図である。
【図８】本発明の第２の実施形態に係る情報取得装置の構成図である。
【図９】地図情報データベースに記憶されているジャンル情報を示す図である。
【図１０】受信情報データベースに蓄積された情報の例を示す図である。
【図１１】第２の実施形態における提示情報決定部の動作を示すフローチャートである。
【図１２】予測された移動先ノードとその予測確率を示す図である。
【図１３】決定された提示情報の項目を示す図である。
【図１４】（Ａ）〜（Ｄ）は提示情報の例を示す図である。
【図１５】ユーザに情報提示する画面例を示す図である。
【図１６】本発明の第３の実施形態に係る情報取得装置の構成図である。
【図１７】本発明の第３の実施形態における処理の流れを示すフローチャートである。
【図１８】予測された経路情報の例である。
【図１９】受信情報データベースに蓄積された道路・交通情報の具体例を示す図である。
【図２０】ユーザに提示される画面例を示す図である。
【図２１】本発明の第３の実施形態の発展例における情報取得装置の構成図である。
【図２２】本発明の第４の実施形態に係る情報取得装置の構成図である。
【図２３】本発明の第４の実施形態における提示情報決定部の動作を示すフローチャートである。
【図２４】本発明の第５の実施形態に係る情報取得装置の構成図である。
【図２５】本発明の第６の実施形態に係る情報取得装置の構成図である。
【図２６】受信情報データベースに蓄積された情報の例を示す図である。
【図２７】（Ａ），（Ｂ）は本発明の第６の実施形態における情報提示の例を示す図である。
【図２８】検索用条件となる各キーのカテゴリーの例を示す図である。
【図２９】検索用条件となる各キーの階層化されたカテゴリー構造を示す図である。
【図３０】ノードのエリア化を説明するための図である。
【図３１】条件決定部の動作の他の例を示すフローチャートである。
【技術分野】
【０００１】
本発明は、カーナビや携帯電話、ＰＤＡ等の位置情報のセンシングが可能な情報機器を用いて、ユーザの移動履歴を蓄積し、この移動履歴から移動先を予測し、予測した移動先に関連する情報をネットワーク等を利用して取得する技術に関するものである。
【背景技術】
【０００２】
インターネットの普及により、我々の身の回りには実に様々な情報があふれている。情報機器を利用するユーザは、キーワードを情報機器に入力することによって、検索したい情報にアクセスすることができるが、自分の欲する情報がある度に、情報と直接結びつくキーワードをユーザ自身が毎回入力する作業は、非常に手間がかかるものである。例えば、移動中に携帯電話などの端末に入力を行ったり、車で移動中にカーナビに設定を行うのは手間であるし、場合によっては危険な操作となる。このため、カーナビのユーザは、目的地の設定などを行わないで走行することも多い。
【０００３】
このような問題の解決策の１つとして、ユーザが必要とするであろう情報を、ユーザの行動を予測することによって予め取得し提示する方法が考案されている。
【０００４】
例えば、車載端末において運転の開始位置および終了位置をその日時などの条件とともに走行履歴として記憶しておき、ユーザのエンジン始動を検出すると、現在の位置および日時などの条件をキーとして走行履歴を検索し、過去に最も高い頻度で行った目的地と、過去にその目的地までの走行に要した時間とを参照して、ユーザに目的地および所要時間を自動的に示す車載情報装置が、提案されている（特許文献１参照）。
【０００５】
また、情報端末を所持するユーザの行動を移動行動と停止（滞在）行動という単位で分割し、ある行動に関して、出現頻度、並びに直前および直後の行動内容などの情報をひとまとまりとし、移動履歴としてサーバに記憶しておき、サービスプロバイダが指定した条件（例えば、日曜の９〜１４時の間に京都駅周辺にいること）を満たすユーザを、履歴情報から行動予測することで見つけ出し、該当するユーザに対して広告情報を提供する情報提示方法が、提案されている（特許文献２参照）。
【特許文献１】特開平１１−１４９５９６号公報（特に第１図）
【特許文献２】特開２０００−２９３５４０号公報（特に第１図）
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、上述の従来技術には、次のような問題がある。
【０００７】
まず、目的地に関する予測結果は、条件の選択（日付を指定するか、日付と出発時刻を指定するか、さらに天気を含めるのか、など）によって異なり、また必要な条件は出発地に応じても異なってくることが予想される。このため、適切な検索条件を選択することは、予測を成功させるために非常に重要である。しかしながら、上述の特許文献１，２ではいずれも、このような観点に関する記載はない。
【０００８】
また、特許文献１では、検索に用いる履歴データベースは出発地と目的地の組合せを時系列に記憶しているだけなので、データベースを検索するのに計算コストがかかり、例えばエンジン起動時に動作を開始すると、予測結果が得られるまでに時間がかかりすぎる、という問題がある。また、所要時間の算出において、過去の走行実績のみを参照し、現在の渋滞度合などは参照していないため、正確な算出ができない場合がある。さらに、履歴データベースにはユーザの走行経路までは記憶されていないので、ユーザが走行すると思われる経路に関する予測を行うことができず、現在の渋滞度合や道路情報を参照できたとしても、経路上に関連する道路情報などの有益な情報をユーザに提示することができない。さらには、出発地が分かれば目的地が特定できる、ということは少なく、走行していくに従って、出発地を含んだ経路情報が分かってはじめて予測が成り立つという場合が非常に多い。
【０００９】
また、特許文献２では、同一出発地および同一目的地を結ぶ移動行動はその経路の違いによらずひとまとまりとして記憶しているため、複数の経路が存在する際に正確な経路の予測を行うことができない。また、前後の行動との関係しか記憶されていないため、４つ以上の連続した行動に関しては、ユーザの行動を再現することができないため、不完全な予測となってしまう。また、予測を行うための条件は、サービスプロバイダまたはユーザが指定しなければならないが、上述のように、精度の高い予測ができるように適切な条件を選択することは困難である。
【００１０】
前述した問題に鑑み、本発明は、移動履歴からユーザの移動先を予測し、予測先に関連する情報を取得する技術において、移動先の予測の精度を、従来よりも向上させることを課題とする。
【課題を解決するための手段】
【００１１】
本発明は、移動体の移動先に関連する情報を取得する情報取得方法として、移動体の位置情報の履歴から得た移動経路を移動履歴としてリンク間の推移の形式で蓄積する第１のステップと、前記移動履歴を検索する際のキーの種類およびカテゴリーを検索用条件として決定する第２のステップと、前記移動履歴に対して前記検索用条件に従った検索を行い、この検索結果に基づいて、移動体が進行する移動先または移動経路を１つ以上予測する第３のステップと、予測した移動先または移動経路に関連する情報を取得する第４のステップと、前記第４のステップにおいて取得した情報を基にして、前記移動先についての提示情報を決定する第５のステップとを備えたものである。
【００１２】
本発明によると、蓄積された移動履歴を検索する際の、キーの種類およびカテゴリーが、検索用条件として決定され、この検索用条件に従った検索の結果に基づいて、移動体が進行する移動先または移動経路が予測される。ここでのキーの種類としては、時刻、日付、天気、運転者、同乗者などが挙げられる。また、ここでのカテゴリーとは、キーの区分または尺度のことをいい、例えば、時刻については、「８時３０分」という時刻に関して、「朝」「６時〜１０時」「８時〜９時３０分」など、抽象度のレベルという意味で様々な尺度のカテゴリーが考えられるし、日付については「金曜日」という曜日に関して、「平日」というカテゴリーで捉えるか「週末」というカテゴリーで捉えるか、などまとめ方についての様々な尺度のカテゴリーを考えることができる。同様に例えば、天気については「晴れ」「降水確率４０％未満」など、運転者や同乗者については「佐藤家のユーザ」「２５歳以上」「お父さん」など、を考えることができる。このように、移動履歴を検索する際の検索用条件を予め決定してから予測を行うことによって、従来よりも精度の高い予測を行うことができ、したがって適切な情報を取得することができる。さらに、移動体の移動先について、従来よりも精度の高い予測を行うことができ、適切な情報を取得することができるので、ユーザにより適切に情報を提示することができる。
【発明を実施するための最良の形態】
【００１３】
本発明の第１態様では、移動体の移動先に関連する情報を取得する情報取得方法として、移動体の位置情報の履歴から得た移動経路を移動履歴としてリンク間の推移の形式で蓄積する第１のステップと、前記移動履歴を検索する際のキーの種類およびカテゴリーを検索用条件として決定する第２のステップと、前記移動履歴に対して前記検索用条件に従った検索を行い、この検索結果に基づいて移動体が進行する移動先または移動経路を１つ以上予測する第３のステップと、予測した移動先または移動経路に関連する情報を取得する第４のステップと、前記第４のステップにおいて取得した情報と、位置と、名称と、当該位置が属するジャンル名との対応関係を表す情報を参照し、前記移動先の予測確率に基づいて、名称およびジャンル名のうち少なくともいずれか１つを、提示情報として決定する第５のステップとを備えたものを提供する。
【００１４】
以下、本発明の実施の形態について、図面を参照して説明する。以下の各実施形態では、特にカーナビ（カーナビゲーションシステム）を例にとって説明するが、本発明はこれに限定されるものではない。例えば、携帯電話やＰＤＡ、パソコンなど、普段ユーザが持ち歩くものであって位置情報を検出する手段を有する情報機器であれば、本発明は同様に実現可能である。また、カーナビが有する機能の一部を、ネットワーク上のサーバに設けるような構成も考えられる。
【００１５】
（第１の実施形態）
図１は本発明の第１の実施形態に係る情報取得装置としてのカーナビの構成を示す。図１において、１０１はカーナビの現在位置（カーナビが搭載された移動体としての車の現在位置）情報を検出する位置検出部、１０２は位置検出部１０１によって検出された現在位置が後述するノードに相当するか否かを判定するノード判定部、１０３はカーナビで使用する地図情報を記憶している地図情報データベースである。
【００１６】
また１０４は車の位置情報の履歴から得た移動経路を移動履歴として蓄積する履歴蓄積データベース（ＤＢ）であり、ここでは、ノード判定部１０２において現在位置がノードと判定されたとき、そのノードを記憶する。履歴蓄積ＤＢ１０４に蓄積されるデータ構造については後述する。また１０５は履歴蓄積ＤＢ１０４に蓄積されているノードの出現頻度の情報を利用して、後述する遷移状態情報を作成するために用いる，ノードの出現頻度に対する閾値を算出する閾値算出部、１０６は履歴蓄積ＤＢ１０４に蓄積された移動履歴から、車の過去の位置遷移を表す遷移状態情報を生成する遷移状態情報作成部であり、ここでは、閾値算出部１０５で算出された閾値以上の頻度で出現するノードについて、ノード間の遷移に関する情報を、その出現頻度や走行日時等の付加情報とともに作成する。ノード判定部１０２、履歴蓄積ＤＢ１０４、閾値算出部１０５および遷移状態情報作成部１０６によって、履歴蓄積部が構成される。
【００１７】
１０７は遷移状態情報を利用して、履歴蓄積ＤＢ１０４に蓄積されている現在の状態を示す情報から、適切な予測結果を得るための検索用条件を決定する条件決定部、１０８は条件決定部１０７によって決定された検索用条件を用いて、状態遷移情報から、今後の移動先の予測を行う予測部である。
【００１８】
また１０９は移動履歴を参照して、現在位置のノードと予測部１０８によって予測されたノードとの間の走行時間を算出するノード間所要時間算出部、１１０は地図情報ＤＢ１０３を参照して、予測部１０８によって予測されたノードについて、ユーザに提示する情報を決める提示情報決定部、１１１は提示情報決定部１１０によって決定された提示情報をユーザに提示する情報提示部である。提示情報決定部１１０は例えば、名称などのノードを特定する情報や、ノードまでの予想所要時間や予想到着時刻等を、提示情報として決定する。
【００１９】
図２は地図情報ＤＢ１０３に記憶されているノードに関連する情報を示す図である。本実施形態では、交差点やランドマーク、またはエリア名称などをノードという概念で表し、「○○交差点」や「△△遊園地」などの固有名称以外に、「職場」や「Ａ子さんの家」などのユーザに特有の名称を登録できるようになっている。
【００２０】
図２において、ノード番号はこれらノードに唯一に割り当てられたＩＤ番号を示し、交差点であれば「Ｃ○○」、ランドマークであれば「Ｌ○○」、エリアであれば「Ａ○○」等のように割り当てられている。またノードは、それぞれ代表点の緯度、経度情報などの位置を表す情報とともに記憶されている。緯度、経度情報はあくまで代表点の位置情報を示し、実際には、交差点、ランドマーク、エリアなどそれぞれに応じて範囲（代表点を中心とした半径など）を表す情報が存在する。例えば、交差点やランドマークであれば代表点を中心とした半径１０ｍの範囲であったり、エリアであれば代表点を中心とした半径１ｋｍの範囲であったりすることが考えられる。また、個々のエリア毎に範囲が異なっていてもよい。また位置情報は、緯度・経度の他に例えば住所であってもよい。
【００２１】
なお、ＩＤ番号の代わりに交差点やランドマーク、エリアの名称が記述されていてもよく、いずれにしてもそれらノードを唯一に特定できる情報であればよい。そして、交差点やランドマーク、エリア等のノードを特定する情報が、履歴蓄積ＤＢ１０４に蓄積される。
【００２２】
なお、ユーザの走行に応じてノードを追加したり削除したりすることもできる。例えば、交差点の中で、ユーザの車が２つ以上の方向に走行したことがあるものをノードとして定めるようにしてもよい。すなわち、図３０（ａ）に示すように、交差点ａ，ｃについては、ユーザの車は２方向以上に走行しているのでノードＮａ，Ｎｃとして定める一方、交差点ｂについては、ユーザは１方向にしか走行していないのでノードとはしない。
【００２３】
その後、図３０（ｂ）に示すように、交差点ｂについてユーザが新たな方向に走行したとすると、交差点ｂについては、ユーザは２方向以上に走行したことがあるのでノードＮｂとして追加する。あるいは図３０（ｃ）に示すように、交差点ａについて、過去の所定期間においてユーザが１方向にしか走行しなくなると、ノードＮａを削除する（ＤＮａ）。なお、このようなノードの設定には地図データは必ずしも必要でなく、ユーザの走行履歴のみを用いて行うことができる。
【００２４】
図３は履歴蓄積ＤＢ１０４に蓄積されるデータの一例を示す図である。図３の例では、ノード番号と通過時刻とが対になって、時系列に記憶されている。例えば、７月３１日の８時５分にノードＬ６を、同８時６分にノードＣ８を、さらに同８時８分にノードＣ１２を、発進、通過または停車したことを表している。ノードの系列は、図３（ａ）に示すように、出発地と目的地によるセグメント単位、つまり「エンジンをスタート（移動の開始）してからストップ（移動の終了）するまで」という単位で蓄積してもよいし、図３（ｂ）に示すように、「自宅を出発してから自宅に帰着するまで」というセグメント単位で蓄積してもよい。さらには「同じ日付」というセグメント単位等で蓄積してもよいし、セグメントなしに蓄積してもよい。移動履歴を、移動の開始から終了までというセグメントで蓄積することによって、詳細な経路情報に基づいた移動先への予測が可能となる。
【００２５】
なお図３では、時刻は月、日、時、分で表されているが、その他、年や秒、曜日等も記憶してよいし、これらの単位のいずれかの組合せのみを記憶してもよい。また、ノード系列が走行毎にセグメントされて蓄積される場合は、エンジンをスタートした時刻とストップした時刻を記載し、通過したノードに関してはそのノード番号のみを記載するようにしてもよい。さらに、このような時刻や日付に関連する情報だけでなく、天気、あるいは運転者や同乗者に関する情報など、条件決定部１０７で決定される検索用条件となるキーに関する情報が記憶されていればよい。
【００２６】
次に、本実施形態における処理の流れについて、図４に示すフローチャートを用いて説明する。
【００２７】
位置検出部１０１においてカーナビの現在位置が検出されると（ステップａ１）、ノード判定部１０２は地図情報ＤＢ１０３を参照して現在位置がノードであるか否かの判定を行う（ステップａ２）。ノード判定部１０２によりノードであると判定されると、そのノードを示すＩＤ番号が履歴蓄積ＤＢ１０４に蓄積される（ステップａ３）。このとき、時刻、日付、天気などの付帯情報も併せて蓄積される。
【００２８】
閾値算出部１０５は履歴蓄積ＤＢ１０４を参照して、遷移状態情報を構成するノードを選別するための，出現回数の閾値を算出する（ステップａ４）。閾値の算出方法は様々に考えることができる。例えば、履歴蓄積ＤＢ１０４に蓄積されたデータ量に応じて算出したり、全てのノードの出現数の分布を求めて算出したり、全てのノードの出現数の平均値を求めてその値に一定数を乗じて算出したりすればよい。どのように決定されるのでもよい。
【００２９】
閾値算出部１０５において閾値が算出されると、遷移状態情報作成部１０６は履歴蓄積ＤＢ１０４のデータを利用して、閾値以上の出現回数をもつノードを選択して遷移状態情報を作成する（ステップａ５）。
【００３０】
図５は遷移状態情報の一例を示す。遷移状態情報は図５のように、走行を開始したランドマークやエリアなどのノード（出発地）をルート直下の最上位に位置させ、それらのノードを基点として過去のノード遷移の履歴（交差点の走行履歴を表す）を木構造で表現し、走行を終了したランドマークやエリアなどのノード（目的地）を各枝の最下層に位置させる構造を有している。各ノードには、そのノードを出発、通過、到着したときの状態情報が付与されており（図５では、矩形枠に表現されたデータ）、例えば「平日の午前９時から１２時までに走行したノード」などの条件を検索のキーとして、木構造を探索することが可能になっている。また、付与されている状態情報の個数でもって、そのノードを出発、通過、到着した頻度が分かるようになっている。このように、遷移状態情報には遷移の度合に関する情報が含まれているので、蓄積された移動履歴を全探索するよりも効率のよい探索が可能となる。
【００３１】
図５では、図３で示した日付と時刻が状態情報として記載されているが、この他にも、上述した運転者や同乗者の情報など、検索用条件となるキーの情報を記載しておけばよい。また図５では、これらの状態情報を一部のノードにしか記載していないが、実際は全てのノードにこのような状態情報が記載されている。
【００３２】
遷移状態情報が作成されると、条件決定部１０７は、予測部１０８による予測に適切な検索用条件を決定する（ステップａ６）。図６は条件決定部１０７の動作の一例を示すフローチャートである。
【００３３】
条件決定部１０７は履歴蓄積ＤＢ１０４を参照して、現在の状態に関する情報を取得する。履歴蓄積ＤＢ１０４には、過去の履歴情報の他に、現在の走行に関する情報を記憶しておく領域が存在し、出発してから現在のノードに至るまでの経路を抽出できるようになっている。いま、現在地をノード「Ｃ９」、出発してからの走行履歴を「Ｌ６→Ｃ９」、日時を６月３日の１４時とする。このとき、日時などの条件（キーの種類）に関しては、図２８に示すようなテーブルを参照して、「平日」、「昼」、「夏」などの条件（カテゴリー）を抽出できるものとする。
【００３４】
条件決定部１０７はこれらの条件の中から１つの組合せ、例えば「平日、かつ、Ｃ９」を選択すると（ステップｂ１）、遷移状態情報からこの条件を満たすノードを検索する（ステップｂ２）。図５では、ノード５０１「Ｃ９」がこれに該当する。そしてこのノードを基点として、今後遷移する可能性のあるノード（最下層に位置するノード）を遷移候補ノードとして１つ選択し（ステップｂ３）、そのノードへの遷移確率を計算して（ステップｂ４）、その値を記憶しておく（ステップｂ６）。
【００３５】
遷移確率の計算方法としては次のようなものがある。このときの条件をCond、条件Condにおける基点Ｃ９の出現頻度をFreq（Ｃ９｜Cond）、遷移候補ノード（Ｌｎ）において条件Condを満たす頻度をFreq（Ｌｎ｜Cond）とすると、
遷移確率Ｐ（Ｌｎ｜Ｃ９）＝Freq（Ｌｎ｜Cond）／Freq（Ｃ９｜Cond）
として求めることができる。
【００３６】
このように１つの遷移候補ノードについて遷移確率が計算されると、この条件の下で他に遷移候補ノードがあるか否かを判定し（ステップｂ５）、存在するときはその遷移候補ノードについても同様に遷移確率を計算してその値を記憶する。
【００３７】
他に遷移候補がなくなったとき（ｂ５でＮｏ）、記憶された遷移確率から、その条件における遷移確率のエントロピーを計算し（ステップｂ７）、その値を条件とともに記憶する（ステップｂ９）。ある条件において、過去に走行したことのある目的地の１つＬｉへの走行確率をＰｉと表したときのエントロピーの計算方法の一例を式（１）に示す。
ΣＰｉ（−ｌｏｇ２ Ｐｉ） …（１）
ｉ
【００３８】
エントロピーを記憶すると、すでに選択した条件以外に、他の組合せ（例えば「平日、かつ、Ｃ９、かつ、昼」「平日、かつ、「Ｌ６→Ｃ９」、かつ、夏」など考えうる組合せ）があるか否かを判定し（ステップｂ８）、あるときは、その条件を選択して同様の動作を繰り返す。
【００３９】
そして、全ての条件の組合せについてエントロピーを計算し終えると、記憶しているエントロピーの値が最も小さい条件の組合せを、最適な検索用条件として決定する（ステップｂ１０）。すなわち、移動先を予測するために行う移動履歴の検索において、用いられるキーの種類およびカテゴリーが、検索用条件として決定される。
【００４０】
図４に戻り、条件決定部１０７によって検索用条件が決定されると、予測部１０８は検索用条件に従って移動履歴を検索し、この検索結果に基づいて、車が進行する移動先を予測する。ここでは、移動履歴から作成された遷移状態情報を参照して、今後の遷移先ノードを決定する（ステップａ７）。ノードの決定は、例えば、予測確率が最も高いノードを選択する方法、予測確率値に応じてノードに範囲を与え、乱数値が属する範囲をもつノードを選択する方法、所定値以上の確率値をもつノードは全て選択する方法、または、確率値の高いものから所定数のノードを選択する方法など、様々な方法によって実行できる。また、遷移先のノードが予測されると、遷移状態情報を参照することによって当然、予測されたノードまでの経路も予測することは可能である。
【００４１】
遷移先のノードが予測されると、ノード間所要時間算出部１０９は、現在のノードと予測先のノードとの間の所要時間を予想する（ステップａ８）。例えば、現在のノードと予測先のノードをキーとして遷移状態情報を検索し、過去にこれら２つのノード間を走行するのに要した時間の平均値を、予想所要時間とする。このとき、検索対象を日付や時間帯等の条件でさらに絞ってから所要時間を求めてもよいし、遷移状態情報に表されていない情報が履歴蓄積ＤＢ１０４に記憶されている場合は、履歴蓄積ＤＢ１０４を参照して所要時間を計算してもよい。
【００４２】
提示情報決定部１１０は、地図情報ＤＢ１０３を参照して、予測されたノードの名称やその他の情報、予想所要時間や予想到着時刻に関する情報など、ユーザに提示すべき情報を決定する（ステップａ９）。その情報は情報提示部１１１によりユーザ（ドライバや同乗者）に提示される。ユーザに情報提示する画面の一例を図７に示す。
【００４３】
なお提示する情報は、ネットワークを経由して取得することも可能である。この場合、カーナビが、受信した情報から予測された移動先または移動経路に関連する情報を選別して提示してもよいし、予測された移動先または移動経路を示す情報をカーナビからネットワーク上のサーバにアップし、サーバが関連する情報を選別し、カーナビはサーバで選別された情報のみを受信するようにしてもよい。
【００４４】
さらに後者の場合、履歴ＤＢ１０４に蓄積された履歴情報をサーバにアップロードして、サーバが、移動先の予測と予測結果に基づく情報選別との両方を行うようにしてもよい。ただし、ユーザによっては、プライバシー保護の観点から、自分の移動履歴を全てサーバにアップすることに心理的抵抗感を持つ人もいると考えられる。このようなユーザに対しては、予測された移動先という最低限の情報のみをアップする方が合理的である。すなわち、許可が得られたユーザに対してのみ、移動履歴を全てサーバにアップする、というようにしてもよい。
【００４５】
なお、本実施形態では、移動履歴から遷移状態情報を作成するとき、所定の頻度以上出現するノードのみを選別するものとしたが、これは、検索対象となるデータサイズをコンパクトにして検索効率を向上させるためである。すなわち、検索効率に特に制約がない場合等は、ノードを選別する必要は必ずしもなく、履歴蓄積ＤＢ１０４に蓄積されている全てのノードを利用して、遷移状態情報を作成するようにしてもよい。
【００４６】
また本実施形態では、遷移状態情報を、予測において利用する可能性のある状態情報を全て含むように作成し、その後、遷移状態情報を参照して、エントロピーが最小値となる条件の組合せを検索用条件として決定し、予測を行った。これ以外にも、条件決定部１０７が履歴蓄積ＤＢ１０４を参照して本実施形態と同様な処理を行って適切な条件を予め決定しておき、その条件でもって、遷移状態情報作成部１０６が遷移状態情報を作成する、という方法も考えられる。
【００４７】
なおここでは、検索用条件の決定を、ノードの遷移確率（予測した移動先の予測確率）のエントロピーを計算することによって行ったが、本発明はこれに限られるものではない。例えば、他の統計処理に基づいて、検索用条件を決定してもよい。
【００４８】
＜検索用条件の決定手法の他の例＞
（その１）
条件決定部１０７における処理の他の例について、図３１に示すフローチャートを用いて説明する。ここでは、条件のバリエーションとして，図２９に示すような、「日付」「時刻」「天気」といった各キーの種類に関する、階層化されたカテゴリー構造を想定する。
【００４９】
いま、現在までの経路情報を「Ｌ６→Ｃ９」、現在ノードをＣ９、現在の状態を「月曜日」「１４時」「晴れ」とする。
【００５０】
まず図５に示す遷移状態情報から、経路情報「Ｌ６→Ｃ９」を満たす現在ノードを検索する（ステップｆ１）。図５では、ノード５０１がこれに該当する。
【００５１】
次に、上述した方法と同様に、条件Condを経路情報「Ｌ６→Ｃ９」とした場合における各遷移候補ノードへの遷移確率を算出して、そのエントロピーを計算し、これを基準エントロピーとする（ステップｆ２）。
【００５２】
基準エントロピーを計算すると、図２９の条件カテゴリー階層の中から、現在の状態を満たす最も抽象度の高いカテゴリー「平日」「昼」「晴れ」の３つを条件候補として決定する（ステップｆ３）。
【００５３】
そして、これらの条件候補の中でまず「平日」を選択し（ステップｆ４）、条件Condとして経路情報「Ｌ６→Ｃ９」と「平日」を満たすものについてエントロピーを算出し（ステップｆ５）、これを記憶しておく（ステップｆ７）。
【００５４】
ステップｆ３で決定された条件候補の中で、すでに選択した「平日」以外のものが存在するか否かを判定する（ステップｆ６）。ここでは、「昼」「晴れ」というカテゴリーが残っているので、次に「昼」を選択し（ステップｆ４）、同様の処理を行う。
【００５５】
残りの「晴れ」についても同様の処理を行い、全ての条件候補について処理が終了すると、終了条件を満たすか否かを判定する（ステップｆ８）。
【００５６】
ここで、次の２つの判定基準のいずれかを満たしているとき、終了条件を満たすと判定する。第１の判定基準は、各条件候補についてのエントロピー、およびステップｆ２で算出した基準エントロピーの中で、基準エントロピーが最も小さい場合である。第２の判定基準は、各条件候補がいずれも図２９の階層構造における最下層のカテゴリーに該当し、さらなる具象カテゴリーが存在しない場合である。これらの場合は処理を終了し、現在選択されている条件を最適条件として決定する（ステップｆ９）。仮に、いまの段階で終了条件を満たしたとすると、この場合の最適条件は、経路情報「Ｌ６→Ｃ９」のみとなり、日付や時刻等の条件は選択されない。
【００５７】
ここでは、「昼」を選択したときのエントロピーが最も小さかったとする。この場合、このエントロピー値を基準エントロピーとする（ステップｆ２）とともに、カテゴリー「昼」を１つ具象化して「１４時〜１５時」とし、「平日」「晴れ」「１４時〜１５時」を新たな条件候補として決定する（ステップｆ３）。そして、これら新たな条件候補について同様の処理を行う（ステップｆ４〜ｆ６）。
【００５８】
ここで終了条件を満たしたとすると、最適条件は、経路情報「Ｌ６→Ｃ９」と「昼」となる。一方、終了条件を満たさなかったときは、例えば「平日」のエントロピーが最も小さくなったとすると、そのエントロピー値を基準エントロピーとして、さらにステップｆ２〜ｆ８の処理を、終了条件が満たされるまで繰り返す。
【００５９】
例えば、最適条件として「平日」「１４時〜１５時」「晴れ」というカテゴリーが決定されると、図５の遷移状態情報の中で、過去に経路「Ｌ６→Ｃ９」を走行し、「平日」「１４時〜１５時」「晴れ」であったものの事例のみを対象として遷移確率を計算し、遷移先ノードを決定すればよい。
【００６０】
（その２）
同じく図３１のフローチャートを用いて、条件決定部１０７における処理の他の例について説明する。いま、現在までの経路情報を「Ｌ６→Ｃ９」、現在ノードをＣ９、現在の状態を「月曜日」「１４時」「晴れ」とする。
【００６１】
まず図５に示す遷移状態情報から、経路情報「Ｌ６→Ｃ９」を満たす現在ノードを検索する（ステップｆ１）。図５ではノード５０１がこれに該当する。そして上述した方法と同様に、条件Condを経路情報「Ｌ６→Ｃ９」とした場合における各遷移候補ノードへの遷移確率を算出して、そのエントロピーを計算し、これを基準エントロピーとする（ステップｆ２）。
【００６２】
基準エントロピーを計算すると、図２９の条件カテゴリー階層において、「ＲＯＯＴ」から１段階具象化したカテゴリーを条件候補として決定する（ステップｆ３）。具体的には，日付条件において「平日」「休日」、時刻条件において「朝」「昼」「夜」、天気条件において「晴れ」「くもり」「雨」を条件候補とする。
【００６３】
これらの候補の中からまず、曜日条件を具象化したカテゴリー「平日」「休日」を選択し（ステップｆ４）、図５の遷移状態情報の中で、経路情報「Ｌ６→Ｃ９」を満たすものを対象として，「平日」「休日」というカテゴリーで分類した場合の遷移確率およびエントロピーを算出し（ステップｆ５）、エントロピー値を記憶しておく（ステップｆ７）。
【００６４】
次に、時刻条件を具象化したカテゴリー「朝」「昼」「夜」を選択し（ステップｆ４）、図５の遷移状態情報の中で、経路情報「Ｌ６→Ｃ９」を満たすものを対象として、「朝」「昼」「夜」というカテゴリーで分けた場合の遷移確率およびエントロピーを算出し（ステップｆ５）、エントロピー値を記憶しておく（ステップｆ７）。天気条件についても同様にエントロピーを計算する。
【００６５】
そしてステップｆ８では、上述したように終了条件の判定を行う。
【００６６】
例えば、時刻条件を「朝」「昼」「夜」に具象化した場合のエントロピーが最も小さいとすると、次回のステップｆ３では、「平日」「休日」というカテゴリー、「晴れ」「くもり」「雨」というカテゴリー、「朝」を具象化した「６時〜７時」「８時〜９時」「１０時〜１１時」というカテゴリー、「昼」を具象化した「１２時〜１３時」「１４時〜１５時」「１６時〜１７時」というカテゴリー、「夜」を具象化した「１８時〜１９時」「２０時〜２１時」「２２時〜２３時」というカテゴリー、以上合計５通りの条件候補を決定する。
【００６７】
上述した２つの処理の違いは、前者が、図５の遷移状態情報に示す過去の走行データの中で、曜日や時刻等の状態情報が現在状態と同一の条件を満たすもののみを対象にしてエントロピーを計算する（例えば、現在が月曜日であり曜日条件として「平日」が与えられると、同一経路であった過去の事例のうち、「平日」であったもののみのエントロピーを計算する）のに対して、後者は、同一経路であった全事例を対象にしてエントロピーを計算している点である。
【００６８】
なお、図２９のような条件カテゴリーはユーザによって異なる（例えば、あるユーザの休日は土曜と日曜だが、別のユーザの休日は月曜と火曜であるなど）ことが考えられるので、このような条件カテゴリーを取得する手段を設け、ユーザ毎に異なる条件カテゴリーを利用するようにしてもよい。
【００６９】
また本実施形態では、現在の走行を開始してから現在位置に至るまでの情報を、条件として利用するものとしたが、これ以外にも、現走行以前の走行における履歴情報（出発地や経路、日時などに関する情報）をも参照するようにしてもよい。
【００７０】
また、図２９に示すような条件カテゴリーの階層構造を、同一キー（例えば時刻条件）に対して、複数種類持たせておいてもよい。この場合、それぞれの階層構造に対してエントロピーを算出して条件を決定しておき、それらの中でエントロピーが最小となる条件を最終的な条件として予測を行えばよい。これにより、例えば「昼１２時〜１７時」の下の階層について、図２９に示す「１２時〜１３時」「１４時〜１５時」「１６時〜１７時」以外にも、「１２時〜１４時」「１５時〜１７時」というカテゴリーや、「１２時〜１３時３０分」「１３時３０分〜１５時」「１６時〜１７時」というカテゴリーなど、様々なカテゴリーを考慮することができる。
【００７１】
また本実施形態では、位置検出部１０１が位置情報を検出すると、ノード判定部１０２がノードであるか否かの判定を行い、ノードのみを履歴蓄積ＤＢ１０４に蓄積するものとしたが、それ以外にも例えば、検出された位置情報をそのまま蓄積し、その後適当なタイミングでもってノード判定部１０２が動作し、ノードのみを抽出する、という構成でもかまわない。
【００７２】
また、提示情報決定部１１０は、当初は予測された移動先の名称のみを提示情報として決定し、提示した情報に対してユーザから選択されたノードに関してのみ、予想所要時間などの情報や、その他そのノードに関連する詳細な情報を出力するようにしてもよい。あるいは、選択されたノードを目的地として、カーナビの機能である経路設定を行うようにしてもよい。
【００７３】
なお、本実施形態に係る構成に対してさらに、運転者や同乗者等のユーザを特定する情報を取得する手段を設けて、ユーザ毎に履歴蓄積データを蓄積するようにしてもよい。これにより、複数のユーザが同一のカーナビを利用している場合であっても、ユーザに応じた適切な予測が可能となり、また同乗者の違いに応じた予測も可能となる。ユーザを特定する情報の取得方法としては、ユーザに直接入力してもらう方法、ユーザが携帯する携帯電話やＰＤＡ等の情報端末とＢｌｕｅｔｏｏｔｈやＩｒＤＡなどの無線を介して通信し機器ＩＤやユーザ情報等を取得する方法、運転者を特定する情報が記憶された運転キーから判定する方法、車載カメラにより人物を判定する方法、など様々に考えられるが、特に問わない。
【００７４】
また、ユーザが登録したノード名称や固有名称以外のノード名称を表すノード情報を、地図情報ＤＢ１０３にユーザ毎に記憶しておき、取得したユーザ特定情報に応じて、参照するノード情報を変更する、といった形態が考えられる。例えば「職場」というノードを登録する場合、運転手が父親なら「○×製造株式会社」であり、長男の場合は「□△商事株式会社」である、といった事例が考えられる。さらには、各ユーザが、個別のノード情報が記録されたメモリカードを利用時にカーナビに挿入し、地図情報ＤＢ１０３およびメモリカードを参照するようにしてもよい。あるいは、ノード情報はネットワーク上に保存してもよい。
【００７５】
また、履歴蓄積ＤＢ１０４において記憶される履歴情報は、本実施形態で示したように、交差点をノードとして、ノードの系列で蓄積する以外にも、例えば、走行した道路情報（交差点と交差点を結ぶリンク）を利用して蓄積してもよい。すなわち、ノードＣ８，Ｃ２０を結ぶ道路をリンクＬｉｎｋ（８，２０）と表現するものとすると、図３（ｂ）に示す「Ｌ６」「Ｃ８」「Ｃ２０」「Ｌ１２」という蓄積情報は、「Ｌ６」「Ｌｉｎｋ（８，２０）」「Ｌ１２」という表現で記録される。このような表現で移動履歴が蓄積された場合でも、本実施形態と同様の方法によって、移動先を予測することは可能である。
（第２の実施形態）
図８は本発明の第２の実施形態に係る情報取得装置としてのカーナビの構成を示す。図８において、図１と共通の符号を付した構成要素のうち、第１の実施形態と同様の動作をするものに関しては、詳細な説明を省く。
【００７６】
図８において、８０１はネットワークや放送波などを介して外部から情報を受信する情報受信部、８０２は情報受信部８０１が受信した情報を蓄積する受信情報ＤＢである。また、８０３はユーザからの入力を受け付けて解釈を行う入力解釈部である。提示情報決定部１１０は、予測部１０８によって予測された移動先に関して、地図情報ＤＢ１０３および受信情報ＤＢ８０２、並びに入力解釈部８０３の解釈を参照して、ユーザに提示する情報を決定する。
【００７７】
図９は地図情報ＤＢ１０３に記憶されている情報の一例を示す。図９に示すように、本実施形態では、図２に示したようなノードの位置（図９では図示せず）や名称を表す情報の他に、各ノードが属するジャンルに関する情報が、地図情報ＤＢ１０３に格納されている。例えば、ノードＩＤ「Ｌ３」は、名称が「Ｃコープ」であり、ジャンル「スーパー」に属している。
【００７８】
図１０は情報受信部８０１が受信して受信情報ＤＢ８０２に蓄積された情報の例を示す。図１０の例では、情報を有するランドマークやエリアの名称、緯度・経度など位置を表す情報、関連する詳細な情報、および画像や動画などのその他の情報が蓄積されている。位置を表す情報としては、緯度・経度の他に、住所等を用いてもよい。
【００７９】
次に、本実施形態における提示情報決定部１１０の動作を図１１のフローチャートを用いて説明する。なお、本実施形態では、予測部１０８は、図１２に示すように、複数の移動先を予測するとともにその予測確率を求めるものとする。
【００８０】
まず、予測部１０８によって予測されたノードのうち１つを予測候補として選択し（ステップｃ１）、選択したノードの名称を地図情報ＤＢ１０３から検索する（ステップｃ２）。ここでは、図１２に示されたノードの中からノード「Ｌ１３１」を選択し、このノード「Ｌ１３１」の名称として「亀谷ゴルフ」を得る。
【００８１】
そして、ステップｃ１で選択したノードへの予測確率が所定値以上であるか否かを判定する（ステップｃ３）。本実施形態では、所定値は“０．２５”とする。このとき、ノード「Ｌ１３１」の予測確率は０．３１であり所定値以上であるので、提示情報の候補としてそのノード名称「亀谷ゴルフ」を記憶しておく（ステップｃ４）。
【００８２】
「Ｌ１３１」以外にまだ予測候補のノードが存在するので（ステップｃ８でＹｅｓ）、次の候補「Ｌ１８」を選択して（ステップｃ１）、ノードの名称を検索して名称「ボンジュール」を得る（ステップｃ２）。「Ｌ１８」も予測確率が０．２６であり所定値以上であるので、「Ｌ１３１」と同様にノード名称「ボンジュール」が記憶される。
【００８３】
次の候補として「Ｌ３」を選択し（ステップｃ１）、名称「Ｃコープ」を得る（ステップｃ２）。ところが、その確率値は０．１８であり所定値以下であるので（ステップｃ３でＮｏ）、地図情報ＤＢ１０３を参照してノード「Ｌ３」のジャンル名「スーパー」を取得する（ステップｃ５）。そして、ジャンル「スーパー」とノード「Ｌ３」の名称「Ｃコープ」とのリンク情報を作成し（ステップｃ６）、提示情報の候補としてそのジャンル名およびノード名を記憶する（ステップｃ７）。
【００８４】
残りのノード「Ｌ５２」に関しても同様の処理を行い、処理の結果、図１３に示すような提示情報の項目が決定される（ステップｃ９）。このようにして提示情報の項目を決定すると、受信ＤＢ８０２を参照してそれらの項目に対応する情報を検索して提示する内容を決定する（ステップｃ１０）。
【００８５】
図１４は提示情報決定部１１０によって決定され、情報提示部１１１によって提示された情報の例である。提示情報は、図１４（Ａ）のトップページから（Ｂ）または（Ｃ）（Ｄ）とリンクをたどれるように構成されており、入力解釈部８０３でユーザの指示入力が解釈されると、それに応じてリンク先の情報が提示される。さらに図１４（Ｂ）（Ｄ）に示す各店舗の画面では、受信情報ＤＢ８０２に蓄積されている情報として、テキスト情報の他に、画像や動画などの情報が再生される。
【００８６】
これらの情報がカーナビの画面でユーザに提示される例を図１５に示す。すなわち、予測確率が所定値以上の移動先「Ｌ１３１」「Ｌ１８」については、その名称「亀谷ゴルフ」「ボンジュール」を、そうでない移動先「Ｌ３」「Ｌ５２」については、そのジャンル名「スーパー」を、提示情報として決定・提示している。このように、予測確率がさほど高くない候補地をジャンルとして提示することによって、誤った予測地の提示によってユーザに不快感を与える可能性を下げることができる。
【００８７】
なお、情報提示の形態はこの他にも、「亀谷ゴルフ」や「ボンジュール」など予測確率が所定値以上のノードについてはトップページにおいて項目だけでなく関連する詳細な情報まで表示して、それ以外のノードに関しては項目のみを表示するようにしてもよい。また、予測確率に関係なく、トップページにはジャンルのみを表示するようにしてもよい。さらには、ジャンルではなく、全てノードの名称（ランドマーク名やエリア名）を表示するようにしてもよい。
【００８８】
また、提示対象となるランドマークが、ユーザの目的地であるか、あるいは予測した移動経路上のものであるかに応じて、表示を変更してもよい。例えば、目的地についてはノードの名称を、経路上のノードについてはジャンル名称を表示するようにしてもよい。
【００８９】
また、第１の実施形態で述べたように、予測部１０８によって移動先のノードが予測されると当然そのノードまでの経路についても予測可能であるので、予測されたノード（ランドマーク）に関する広告情報以外にも、予測経路付近に存在するランドマークに関して広告情報を提示するようにしてもよい。
【００９０】
また、提示情報として、第１実施形態で述べたような所要時間に関する情報を提示してもよいし、地図情報ＤＢ１０３に蓄積されている予測先に関連する情報を提示してもよい。
【００９１】
（第３の実施形態）
図１６は本発明の第３の実施形態に係る情報取得装置としてのカーナビの構成を示す。図１６において、図１および図８と共通の符号を付した構成要素のうち、第１および第２の実施形態と同様の動作をするものに関しては、詳細な説明を省く。
【００９２】
ここでは、情報受信部８０１、受信情報ＤＢ８０２、予測部１０８、ノード間所要時間算出部１０９および提示情報決定部１１０の動作について説明する。
【００９３】
情報受信部８０１はネットワークや放送波などを利用して道路・交通に関する情報を受信し、受信情報ＤＢ８０２は受信した道路・交通情報を蓄積する。
【００９４】
予測部１０８は、遷移先のノードを１つ以上予測すると、現在ノードからそれらのノードに至るまでのノードの遷移系列、すなわち移動経路を１つ以上予測する。
【００９５】
ノード間所要時間算出部１０９は、現在のノードと予測先のノード（現在の走行の目的地）との間の所要時間を算出する。例えば、第１の実施形態で述べたように、遷移状態情報作成部１０６により作成された遷移状態情報を参照して、現在ノードと予測先ノードとの間の過去の走行時間の平均値を、予想所要時間として算出する。このとき、検索対象を日付や時刻等の条件でさらに絞ってから所要時間を求めてもよいし、遷移状態情報に表されていない情報が履歴蓄積ＤＢ１０４に記憶されている場合は、履歴蓄積ＤＢ１０４を参照して所要時間を計算してもよい。このような処理以外でも、提示情報決定部１１０が受信情報ＤＢ８０２および地図情報ＤＢ１０３の情報を受けて選択した２つ以上のノードのうち、予測部１０８によって予測された移動経路に含まれる任意の２個のノード間の平均走行時間などを計算することも可能である。
【００９６】
提示情報決定部１１０は、受信情報ＤＢ８０２および地図情報ＤＢ１０３を参照して、ノード間所要時間算出部１０９に伝達すべき２つ以上のノードを選択する。また、予測部１０８によって予測された経路情報、ノード間所要時間算出部１０９によって算出された所定のノード間の予想所要時間、および受信情報ＤＢ８０２に蓄積された道路・交通情報を参照して、ユーザに提示すべき情報を決定する。
【００９７】
本実施形態における処理の流れについて、図１７のフローチャートを用いて説明する。
【００９８】
まず、予測部１０８が、１つ以上の経路情報を予測する（ステップｄ１）。図１８は予測された経路情報の一例である。経路情報の個数は、図１８のように複数であってもよいし、１個であってもよい。
【００９９】
ステップｄ１において予測がなされると、提示情報決定部１１０は受信情報ＤＢ８０２に蓄積されている道路・交通情報と、図１８に示すような予測経路情報とを比較して、予測経路に関連する道路・交通情報が存在するか否かを判定する（ステップｄ２）。図１９は道路・交通情報の具体例を示す。図１９に示すように、ここでの道路・交通情報は、道路名称、区間、および、関連する情報などの項目からなる。区間情報を構成する要素は、図２に例示したように地図情報ＤＢ１０３に記憶されているものとする。
【０１００】
ここでの判定方法について説明する。提示情報決定部１１０は、まず図１９に示すような道路・交通情報の区間情報を、地図情報ＤＢ１０３を参照して、ノード表現に変換する。例えば「巣本北〜巣本南」という区間情報は、「Ｃ１３→Ｃ２０」というようなノード情報に変換される。次に、図１８の予測経路情報と照合して、変換されたノード情報と一致する区間があるか否かを判定する。この判定の結果、優先番号１の経路に「Ｃ１３→Ｃ２０」が含まれていることが分かる。すなわち、ステップｄ２の結果、この区間「Ｃ１３→Ｃ２０」が選択される（ステップｄ３）。
【０１０１】
そしてノード間所要時間算出部１０９は、遷移状態情報を参照して、優先番号１の経路を過去に走行するのに要した平均所要時間（以下、経路平均所要時間という）、および提示情報決定部１１０により選択されたノード間「Ｃ１３→Ｃ２０」を過去に走行するのに要した平均所要時間（以下、区間平均所要時間という）を算出する（ステップｄ４）。ここでは、経路平均所要時間および区間平均所要時間が、それぞれ「８０分」「２０分」と算出されたものとする。
【０１０２】
次に、提示情報決定部１１０は、受信情報ＤＢ８０２に関連情報として蓄積されている「Ｃ１３→Ｃ２０」に相当する区間の所要時間「３０分」と、ノード間所要時間算出部１０９により算出された区間平均所要時間「２０分」とを比較して、差分時間「１０分」を算出する（ステップｄ５）。そして、この差分時間「１０分」と経路平均所要時間「８０分」を加味して、予測される所要時間として「９０分」を決定する（ステップｄ６）。
【０１０３】
提示情報決定部１１０はさらに、地図情報ＤＢ１０３を参照して、ノード番号からランドマークなどの名称への変換を行い、ユーザに提示すべき情報を決定する（ステップｄ７）。
【０１０４】
情報提示部１１１によってユーザに提示される画面の例を図２０に示す。図２０では、予想される目的地の名称、道路・交通情報を参照して求めた予想所要時間、および受信した道路・交通情報が提示されている。
【０１０５】
なお、提示情報の形態は、ここで示したものに限られず、例えば、予測経路に関連する道路・交通情報のみを提示するようにしてもよい。この場合には、ノード間所要時間算出部１０９は不要となる。
【０１０６】
（発展例）
上述の第３の実施形態を発展させた例として、図２１に示すような構成が考えられる。図２１において、図１６と異なるのは、経路探索部２１０１を設けた点である。
【０１０７】
経路探索部２１０１の動作について説明する。図１７の所要時間比較ステップｄ５または所要時間決定ステップｄ６において、今後進行が予想される経路では過去の平均所要時間よりも多くの時間が必要になると判定された場合、経路探索部２１０１は、図１８に示すような予測経路情報と受信情報ＤＢ８０２から読み出された情報を提示情報決定部１１０から受けるとともに、地図情報ＤＢ１０３を参照して、予測経路よりも所要時間が短くてすむ経路を探索する。探索のためのアルゴリズムに関しては特に問わず、ここでは詳細な説明は省略する。所要時間が短い経路を探索できたときは、この経路に関する情報を情報提示部１１１がユーザに提示する。
【０１０８】
またこのとき、経路探索部２１０１は、履歴蓄積ＤＢ１０４や遷移状態情報、またはノード間所要時間算出部１０９を参照して、過去にユーザが走行したことがありかつ所要時間がより短い別ルートを、優先的に探索することも可能である。
【０１０９】
また、別ルートの探索は、上述したような所要時間に関する制約が満たされない場合だけでなく、例えば、予想経路に関して通行止めなどの規制情報があった場合に行ってもよい。
【０１１０】
（第４の実施形態）
図２２は本発明の第４の実施形態に係る情報取得装置としてのカーナビの構成を示す。図２２において、図８と共通の符号を付した構成要素のうち、第２の実施形態と同様の動作をするものに関しては、詳細な説明を省く。
【０１１１】
２２０１は履歴蓄積ＤＢ１０４を参照して、ユーザが立ち寄ったことがある各ノード（ランドマーク、エリア）について、移動履歴に現れた頻度を計算する頻度算出部、２２０２は頻度算出部２２０１が計算した頻度を記憶するための頻度記憶ＤＢである。
【０１１２】
図２３は本実施形態において提示情報決定部１１０が提示情報を決定する動作を示すフローチャートである。
【０１１３】
提示情報決定部１１０は、予測部１０８から図１２のような予測結果を受けると、予測された移動先の中から１つを予測候補として選択する（ステップｅ１）。そして選択した予測候補の予測確率を参照し（ステップｅ２）、これが所定値以上のときは、この予測候補をユーザに提示する候補として記憶する（ステップｅ６）。一方、確率値が所定値以下のときは、頻度記憶ＤＢ２２０２を参照して、この予測候補の頻度を取得し（ステップｅ３）、これが所定値以上のときは、この予測候補をユーザに提示する候補として記憶し（ステップｅ６）、所定値以下のときは記憶しない。そして、他に予測候補があるか否かを検索し（ステップｅ５）、予測候補があるときは同様の動作を繰り返し行う。
【０１１４】
全ての予測候補について処理が終わると、記憶しておいた提示候補の予測先に関する情報を提示する項目として決定し（ステップｅ７）、これらに関連する情報を地図情報ＤＢ１０３や受信情報ＤＢ８０２を参照して提示内容として決定する（ステップｅ８）。
【０１１５】
なお、提示候補の決定方法は、ここで示したもの以外にも様々に考えることができる。例えば頻度を用いる場合、頻度が所定値以上であることを情報提示の条件とする代わりに、過去にユーザが行ったことがあるランドマークやエリアの総頻度数に占める予測候補ノードの頻度の割合が所定値以上であるか否か、という基準を用いてもよい。また、頻度記憶ＤＢ２２０２は、第２の実施形態で示したようなジャンルの単位で頻度を記憶するようにし、予測候補ノード単独の頻度ではなく、ノードが属するジャンル全体の頻度を判定の基準としてもよい。さらには、各予測候補ノードについて、予測部１０８によって得られた予測確率と、頻度記憶ＤＢ２２０２に記憶された頻度との両方の尺度を考慮して判定するようにしてもよい。
【０１１６】
（第５の実施形態）
図２４は本発明の第５の実施形態に係る情報取得装置としてのカーナビの構成を示す。図２４において、図１と共通の符号を付した構成要素のうち、上述の各実施形態と同様の動作をするものに関しては、詳細な説明を省く。
【０１１７】
２４０１は予測部１０８によって予測先が決定されると、現在の遷移状態情報と予測結果から、第１の実施形態と同様に、ユーザが予測通りに走行したと仮定したときの走行後の擬似的な遷移状態情報を作成する擬似遷移状態情報作成部である。また２４０２は、擬似遷移状態情報作成部２４０１によって作成された擬似的な遷移状態情報から、第１の実施形態と同様に、擬似的な検索用条件を決定する擬似条件決定部である。
【０１１８】
ここで、第１の実施形態において図２９のカテゴリー階層を用いて説明した２種類の動作のうち、前者の動作を擬似条件決定部２４０２が行うためには、予測した移動先を出発する際の状態（曜日や時刻、天気など）に関する情報が必要となる。なお、擬似条件決定部２４０２が後者の動作を行う場合は、このような状態情報は必要ではないが、予測部１０８においては必要となる。
【０１１９】
これらの情報の取得方法としては次のようなものが考えられる。履歴蓄積ＤＢ１０４を検索すると、現在地から予測した移動先（目的地）に到着した場合に、その目的地を出発するまでに要した時間（以下、滞在時間という）の平均を算出できる。この滞在時間を、予測した移動先への到着予想時刻に加味することによって、予測した移動先を出発する際の曜日や時刻などに関する状態を取得可能となる。
【０１２０】
履歴蓄積ＤＢ１０４を検索して滞在時間の平均を算出する際に、これらの時間の分散が大きい場合は平均値の信頼性は下がる。この場合は、滞在時間を分散の小さいいくつかのまとまりに分割し、各まとまりの平均値を滞在時間候補として算出し、これらの候補全てに関して、擬似条件決定または予測を行うようにすればよい。
【０１２１】
なお、予測された目的地を出発する状態が、予め取得していた状態情報と乖離している場合は、改めて第１の実施形態に示したような通常の予測処理を行えばよい。
【０１２２】
通常、遷移状態情報作成部１０６や条件決定部１０７における処理が完了するまでには時間がかかる。このため、現在位置を検出して移動履歴を更新し、最新の遷移状態情報を作成して最適な検索用条件を決定する、という一連の処理を、例えば車のエンジンを始動したときに行うものとすると、情報提示までに時間がかかりすぎてしまう。すなわち、ユーザがエンジンを始動した際にすぐ、予想される目的地に関する情報を提示する、といったことが困難になる。
【０１２３】
そこで、ある走行においてユーザの移動先や移動経路が予測されたとき、ユーザがその移動先を出発するための行動（例えば、エンジンを始動する、車のドアを開ける、など）を起こす前に、予め次のような処理を行っておく。
【０１２４】
すなわち、擬似遷移状態情報作成部２４０１および擬似条件決定部２４０２によって、次の走行においてエンジンを始動したとき、つまり、現在予想している目的地においてエンジンを始動したときの擬似的な遷移状態情報の作成とそのときの検索用条件の決定を行っておく。これにより、次回の走行でエンジンを始動したときは短い時間で予測を完了することができるので、予想される目的地（新たな移動先や移動経路）に関する所要時間情報やその他関連する情報などを速やかにユーザに提示することが可能となる。
【０１２５】
なお、擬似遷移状態情報や擬似条件を用いた予測は、エンジンを始動したときにのみ行われるのではなく、前もって予測しておきたいという如何なるタイミングにおいても行うことが可能である。
【０１２６】
また、擬似遷移状態情報の作成や擬似条件の決定、あるいはこれらを用いた予予測を行うタイミングとしては、他にも例えば、予測された移動先への確率値が所定の閾値を超えたとき等が考えられる。
【０１２７】
また、図２４のような構成以外でも、擬似遷移状態情報作成部２４０１や擬似条件決定部２４０２を設けない構成も考えられ、この構成では、擬似遷移状態情報や擬似条件の代わりに、予測部１０８によって予測がなされた時点で作成されている最新の遷移状態情報や検索用条件を用いるようにすればよい。
【０１２８】
また、提示する情報や予測の方法については、上述の各実施形態で示したいずれであってもよいし、提示するタイミングとしては、カーナビが起動したときのオープニング画面において提示するのが有効であるが、オープニング画面が終了した後の画面でもよい。また、ある走行が終了したときの画面に、次に走行すると予測される目的地の候補と所要時間の情報や経路上の交通情報などを提示することは、ユーザにとって、所定時刻に目的地に到着するための次の出発時刻の目安となるため、非常に有効である。そこで、例えば上述した方法により算出した出発予想時間どおりに出発したと仮定した場合の目的地の候補と到着予想時刻、交通情報を表示するようにしてもよい。または、ノードでの平均的な滞在時間に関する情報を取得することができれば、その時間を基準として３０分や１時間間隔での、各出発時刻に対する目的地の候補と到着予想時刻、交通情報を表示するようにしてもよい。走行の終了は、目的地で自車位置がしばらく変化しない、ギアがパーキングに入った、サイドブレーキがひかれた、等の事象を検知することによって、検出することができる。
【０１２９】
（第６の実施形態）
図２５は本発明の第６の実施形態に係る情報取得装置としてのカーナビの構成を示す。図２５において、図８と共通の符号を付した構成要素のうち、上述の各実施形態と同様の動作をするものに関しては、詳細な説明を省く。
【０１３０】
図２５において、提示情報決定部１１０は、上述の実施形態と同様に、予測部１０８による予測結果を受け、受信情報ＤＢ８０２に蓄積された情報のうち予測された移動先等に関する情報を提示情報として決定する。さらに本実施形態では、提示情報を決定する際に、情報提示を受けるユーザの認知的負荷を考慮する。
【０１３１】
また、２５０１は運転者等の認知的負荷の高い状態のユーザに対する情報提示を行う第一情報提示部、２５０２は例えば助手席や後部座席にいる人など運転者に比べて認知的負荷がそれほど高くないユーザに対する情報提示を行う第二情報提示部である。２５０３は提示情報決定部１１０が決定した提示情報を音声出力するためのデータを作成する音声合成部であり、第一情報提示部２５０１は提示情報決定部１１０において提示が決定されたテキスト・画像などの情報とともに、音声合成部２５０３により合成された音声情報も提示する。一方、第二情報提示部２５０２は提示情報決定部１１０において提示が決定されたテキスト・画像などの情報を提示する。
【０１３２】
いま、予測部１０８が移動先として「Ｆマート」を予測したとする。そして受信情報ＤＢ８０２に、図２６に示すような情報が「Ｆマート」について蓄積されているものとする。
【０１３３】
提示情報決定部１１０は図２６の情報を基にして、所定の規則に応じて、第一および第二情報提示部２５０１，２５０２に提示すべき情報をそれぞれ決定する。所定の規則としては、例えば「認知的負荷の高いユーザへはインデックス情報を音声読み上げで提供し、認知的負荷の低いユーザへは詳細な説明や画像・動画を含めて提供する」などが考えられる。この規則に則り、提示情報決定部１１０は、第一情報提示部２５０１への出力として図２６のインデックス情報である「特売情報」を音声で読み上げる情報を、第二情報提示部２５０２への出力として図２６の詳細な説明やその他に含まれる画像情報を提示することを決定する。
【０１３４】
図２７（Ａ）は第一情報提示部２５０１による情報提示の例を、図２７（Ｂ）は第二情報提示部２５０２による情報提示の例を、それぞれ示す。図２７（Ａ）の例の場合、ユーザに対して音声によりインデックス情報を通知した後、ユーザから音声やコマンドなどによって詳細な情報取得への要求があった場合は、図２７（Ｂ）に示すような詳細な情報の表示または音声による読み上げ等を行うようにしてもよい。
【０１３５】
このように本実施形態によると、ある情報を取得した際、情報閲覧者の認知的負荷に応じて、提示情報を決定する。例えば、認知的負荷が小さい状態で閲覧可能なユーザには、詳細な情報や画像・動画などのメディアを提供し、認知的負荷が大きい状態のユーザには、音声で読み上げたり、要約した情報を提供したりする。これにより、ユーザは、自分の認知的負荷の大小に応じた情報提供を受けることができる。
【０１３６】
なお、提供する情報内容は上述したものに限られず、ユーザの認知的な負荷を考慮して情報提示がなされればよい。
【０１３７】
また、本実施形態のように、ユーザの認知的負荷の度合に応じて情報提示部を複数個設ける代わりに、例えば、認知的負荷の度合を判定する認知的負荷判定手段を設けて、単一の情報提示部から提示する情報内容を、判定した認知的負荷の度合に応じて変更するようにしてもよい。例えば、車の状態を検出して、停車状態のときは認知的負荷が小さいと判定して詳細な情報や画像・動画等を提供する一方、走行状態のときは認知的負荷が大きいと判定して音声読み上げや要約情報により情報を提供するようにすればよい。
【０１３８】
なお、上述の各実施形態では、ユーザに情報を提供する機器としてカーナビを想定して説明を行ったが、本発明において、対象となる情報機器はカーナビに限定されるものではない。例えば、携帯電話やＰＤＡなどユーザが日常的に持つ情報端末等であっても、位置情報のセンシングが可能であれば、上述の各実施形態と同様に実施することができる。また移動手段に関しても、上述の各実施形態ではカーナビを装着した車を移動体としたが、これ以外の場合、例えば、情報機器を携帯した移動体としての人が徒歩や電車等で移動する場合でも、本発明は同様に実現可能である。
【０１３９】
また、各実施形態において、図示した構成を全てカーナビ内部に設ける例を示したが、本発明はこれに限るものではなく、少なくとも位置検出部１０１および情報提示部１１１（あるいは、第一および第二情報提示部２５０１，２５０２）がユーザのもつ情報端末に備わっていればよい。それ以外の機能の全てまたは一部は、ネットワーク接続された外部のサーバに設けるようにしてもよい。すなわち、位置検出部１０１が検出した位置情報がサーバに送信され、そのサーバに蓄積されて、サーバにおいて予測がなされたら予測地に関する情報などをカーナビに送信する、といった構成である。このような構成は、情報機器が携帯電話やＰＤＡである場合には特に有効である。
【０１４０】
また、本発明に係る情報取得方法は、情報機器およびサーバのうち少なくともいずれか一方が有するコンピュータに、プログラムを実行させることによって、実現することができる。
【０１４１】
また、情報取得のためには、ネットワークを利用する代わりに、ＶＩＣＳ（Vehcle Information and Communication System ）や放送波を利用してもよい。
【０１４２】
また、各実施形態では、情報受信部８０１が受信した情報を受信情報ＤＢ８０２に蓄積しておいて、その中から予測先に関連する情報を抽出してユーザに提示する例を示したが、それ以外にも次のような構成も考えられる。すなわち、ネットワークに対して情報を送信する情報送信部を設け、予測部１０８によって移動先が予測されると、情報送信部が予測地を表す情報をサーバに送信し、サーバが蓄積された情報の中から予測地に関連する情報を抽出してカーナビに送信し、情報受信部８０１によって受信された情報を提示するという構成である。このような構成は、必要な情報だけがネットワークを介して送受信されるので、予測を行ってから情報を提示するまでに時間的な余裕がある場合には有効な構成となる。また、現在地や予測された移動先を含む広範囲の情報を予め取得して受信情報ＤＢ８０２に蓄積しておき、予測先が定まったときに、必要な情報を抽出して提示する、といった構成も可能である。
【０１４３】
また各実施形態では、遷移状態情報作成部１０６が移動履歴から遷移状態情報を作成し、この遷移状態情報を用いて条件決定部１０７や予測部１０８が動作する例について述べたが、遷移状態情報作成部１０６を設けない構成も考えられる。この場合、条件決定部１０７および予測部１０８は、図３に示したような移動履歴の情報から直接的に、検索用条件の決定および移動先の予測を行えばよい。
【０１４４】
また、各実施形態において、閾値算出部１０５、遷移状態情報作成部１０６、条件決定部１０７および予測部１０８が動作するタイミングは、様々に考えることができる。例えば、ノードを通過する度にこれら全ての要素が動作してもよい。他にも、時刻Ｔにおける走行が開始したとき、時刻Ｔ−１における走行が終了したとき、または第５の実施形態に示したように、時刻Ｔ−１における走行の途中で時刻Ｔにおける走行の開始位置の予測が完了したときなどのタイミングで、動作してもよい。または、時刻Ｔ−１の走行終了時点で閾値算出部１０５および遷移状態情報作成部１０６が動作して遷移状態情報を予め作成し、時刻Ｔにおいて走行が開始されるとき、またはノードを走行する度に、条件決定部１０７および予測部１０８が動作して、作成されている遷移状態情報に基づいて検索用条件の決定および進路の予測を行ってもよい。さらには、時刻Ｔ−１の走行終了時点で条件決定部１０７までが動作して遷移状態情報および検索用条件を決定し、時刻Ｔにおいて走行が開始されるとき、またはノードを走行する度に、予測部１０８のみが動作するのでもよい。本発明では、特にタイミングは問わない。
【０１４５】
また、各実施形態において、ユーザに情報を提示するタイミングとしては、走行を開始したときでもよいし、走行開始時からノードを通過する度に予測を行い、予測確率値が所定の閾値を超えたときでもよいし、またはユーザが情報取得の意思表示をしたときでもよいが、特に問わない。
【０１４６】
また、各実施形態ではカーナビを対象にして説明したため、出発地（エンジン起動位置）から到着地（エンジン停止位置）までを移動履歴のデータのセグメントとしたが、これに限られるものではない。例えば、携帯電話やＰＤＡなどの携帯端末では、電源の起動から終了までというセグメント、自宅を出発してから自宅に戻るまでというセグメント、同一日付というセグメント、ランドマーク登録された場所からランドマーク登録された場所までというセグメント、など様々に考えることができる。
【０１４７】
また、各実施形態において、遷移状態情報は図５のように過去の全ての履歴を反映したものである必要はなく、過去の履歴の中で，少なくとも現在の経路情報を含んでいるものを対象として、その後の遷移状態（その後の経路や目的地）と頻度などを表現するものであればよい。例えば，現在の経路が「Ｌ６→Ｃ９」であるとき、遷移状態情報は図５に示す木構造の中で少なくともこの経路を含む部分木構造であればよい。さらには，このような木構造ではなく、テーブルやマトリックスで表現されていてもよい。
【産業上の利用可能性】
【０１４８】
本発明は、例えばカーナビや携帯電話、ＰＤＡ等の情報機器を用いて、ユーザに情報提供を行う技術に利用可能であり、ユーザの移動先について精度の高い予測を行い、適切な情報を取得できるので、有効である。
【図面の簡単な説明】
【０１４９】
【図１】本発明の第１の実施形態に係る情報取得装置の構成図である。
【図２】地図情報データベースに記憶されているノード関連情報を示す図である。
【図３】（ａ），（ｂ）は履歴蓄積データベースに蓄積される移動履歴データの一例を示す図である。
【図４】本発明の第１の実施形態における処理の流れを示すフローチャートである。
【図５】遷移状態情報の一例を示す図である。
【図６】条件決定部の動作の一例を示すフローチャートである。
【図７】ユーザに情報提示する画面例を示す図である。
【図８】本発明の第２の実施形態に係る情報取得装置の構成図である。
【図９】地図情報データベースに記憶されているジャンル情報を示す図である。
【図１０】受信情報データベースに蓄積された情報の例を示す図である。
【図１１】第２の実施形態における提示情報決定部の動作を示すフローチャートである。
【図１２】予測された移動先ノードとその予測確率を示す図である。
【図１３】決定された提示情報の項目を示す図である。
【図１４】（Ａ）〜（Ｄ）は提示情報の例を示す図である。
【図１５】ユーザに情報提示する画面例を示す図である。
【図１６】本発明の第３の実施形態に係る情報取得装置の構成図である。
【図１７】本発明の第３の実施形態における処理の流れを示すフローチャートである。
【図１８】予測された経路情報の例である。
【図１９】受信情報データベースに蓄積された道路・交通情報の具体例を示す図である。
【図２０】ユーザに提示される画面例を示す図である。
【図２１】本発明の第３の実施形態の発展例における情報取得装置の構成図である。
【図２２】本発明の第４の実施形態に係る情報取得装置の構成図である。
【図２３】本発明の第４の実施形態における提示情報決定部の動作を示すフローチャートである。
【図２４】本発明の第５の実施形態に係る情報取得装置の構成図である。
【図２５】本発明の第６の実施形態に係る情報取得装置の構成図である。
【図２６】受信情報データベースに蓄積された情報の例を示す図である。
【図２７】（Ａ），（Ｂ）は本発明の第６の実施形態における情報提示の例を示す図である。
【図２８】検索用条件となる各キーのカテゴリーの例を示す図である。
【図２９】検索用条件となる各キーの階層化されたカテゴリー構造を示す図である。
【図３０】ノードのエリア化を説明するための図である。
【図３１】条件決定部の動作の他の例を示すフローチャートである。
【特許請求の範囲】
【請求項１】
移動体の移動先に関連する情報を取得する情報取得方法であって、
移動体の位置情報の履歴から得た移動経路を、移動履歴としてリンク間の推移の形式で蓄積する第１のステップと、
前記移動履歴を検索する際のキーの種類およびカテゴリーを、検索用条件として、決定する第２のステップと、
前記移動履歴に対して前記検索用条件に従った検索を行い、この検索結果に基づいて、移動体が進行する移動先または移動経路を１つ以上予測する第３のステップとを備え、
予測した移動先または移動経路に関連する情報を、取得する第４のステップと、
前記第４のステップにおいて取得した情報と、位置と、名称と、当該位置が属するジャンル名との対応関係を表す情報を参照し、前記移動先の予測確率に基づいて、名称およびジャンル名のうち少なくともいずれか１つを、提示情報として決定するものである
ことを特徴とする情報取得方法。
【請求項１】
移動体の移動先に関連する情報を取得する情報取得方法であって、
移動体の位置情報の履歴から得た移動経路を、移動履歴としてリンク間の推移の形式で蓄積する第１のステップと、
前記移動履歴を検索する際のキーの種類およびカテゴリーを、検索用条件として、決定する第２のステップと、
前記移動履歴に対して前記検索用条件に従った検索を行い、この検索結果に基づいて、移動体が進行する移動先または移動経路を１つ以上予測する第３のステップとを備え、
予測した移動先または移動経路に関連する情報を、取得する第４のステップと、
前記第４のステップにおいて取得した情報と、位置と、名称と、当該位置が属するジャンル名との対応関係を表す情報を参照し、前記移動先の予測確率に基づいて、名称およびジャンル名のうち少なくともいずれか１つを、提示情報として決定するものである
ことを特徴とする情報取得方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【公開番号】特開２００９−８６８４（Ｐ２００９−８６８４Ａ）
【公開日】平成２１年１月１５日（２００９．１．１５）
【国際特許分類】
【出願番号】特願２００８−１８２３９１（Ｐ２００８−１８２３９１）
【出願日】平成２０年７月１４日（２００８．７．１４）
【分割の表示】特願２００５−１２６７７５（Ｐ２００５−１２６７７５）の分割
【原出願日】平成１５年１０月１０日（２００３．１０．１０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
２．ＶＩＣＳ
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成２１年１月１５日（２００９．１．１５）
【国際特許分類】
【出願日】平成２０年７月１４日（２００８．７．１４）
【分割の表示】特願２００５−１２６７７５（Ｐ２００５−１２６７７５）の分割
【原出願日】平成１５年１０月１０日（２００３．１０．１０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
２．ＶＩＣＳ
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]