特許 5944770 行先提案システム、行先提案方法、およびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5944770

(24)【登録日】2016年6月3日

(45)【発行日】2016年7月5日

(54)【発明の名称】行先提案システム、行先提案方法、およびプログラム

(51)【国際特許分類】

   G01C 21/26 20060101AFI20160621BHJP

   G06F 17/30 20060101ALI20160621BHJP

   G09B 29/00 20060101ALI20160621BHJP

【ＦＩ】

   G01C21/26

   G06F17/30 340B

   G06F17/30 170C

   G09B29/00 A

【請求項の数】9

【全頁数】14

(21)【出願番号】特願2012-158794(P2012-158794)

(22)【出願日】2012年7月17日

(65)【公開番号】特開2014-20877(P2014-20877A)

(43)【公開日】2014年2月3日

【審査請求日】2015年2月19日

(73)【特許権者】

【識別番号】502324066

【氏名又は名称】株式会社デンソーアイティーラボラトリ

(73)【特許権者】

【識別番号】000004260

【氏名又は名称】株式会社デンソー

(74)【代理人】

【識別番号】100113549

【弁理士】

【氏名又は名称】鈴木 守

(74)【代理人】

【識別番号】100115808

【弁理士】

【氏名又は名称】加藤 真司

(72)【発明者】

【氏名】水野 伸洋

(72)【発明者】

【氏名】清水 泰博

【審査官】 小川 恭司

(56)【参考文献】

【文献】 特開２００４−２８７８０７（ＪＰ，Ａ）

【文献】 特開２００８−２９９３７１（ＪＰ，Ａ）

【文献】 特開２００９−３００４５０（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０８Ｇ １／００−９９／００

Ｇ０１Ｃ２１／００−２１／３６

２３／００−２５／００

Ｇ０６Ｆ１７／３０

Ｇ０９Ｂ２９／００

(57)【特許請求の範囲】

【請求項1】

施設の名称及び属性のデータを記憶した地図データベースと、
車両の走行履歴データを記憶した走行履歴データベースと、
前記走行履歴データに基づいて、所定の回数以上の出発回数を有する地点をハブ地点として、当該ハブ地点から行った回数または頻度が所定の基準を満たす地点を旅地点として求める旅地点決定部と、
前記ハブ地点から複数の前記旅地点までの距離または所要時間を求め、複数の前記旅地点までの距離または所要時間の最頻値を求める最頻値算出部と、
前記最頻値に基づく距離または所要時間の範囲にある施設を、前記施設の名称及び属性のデータを記憶した地図データベースから検索する施設検索部と、
ユーザに行先案内する場合に、前記施設検索部にて検索された施設をユーザに提示する出力部と、
を備える行先提案システム。

【請求項2】

前記走行履歴データに基づいて、出発回数の最も多い地点をハブ地点として求めるハブ地点決定部を備える請求項１に記載の行先提案システム。

【請求項3】

行先提案を求める施設の属性の入力を受け付ける入力部を備え、
前記最頻値算出部は、旅地点の属性ごとに前記距離または所要時間の最頻値を求め、
前記施設検索部は、入力された属性と同じ属性の旅地点までの距離または所要時間の最頻値の範囲にある、入力された属性と同じ属性の施設を検索する請求項１または２に記載の行先提案システム。

【請求項4】

出発してから戻るまでの希望時間の入力を受け付ける入力部を備え、
前記最頻値算出部は、前記ハブ地点を出発してから戻るまでに要した時間ごとに前記距離または所要時間の最頻値を求め、
前記施設検索部は、前記ハブ地点を出発してから戻るまでに前記希望時間と同じ時間を要した旅における旅地点までの距離または所要時間の最頻値の範囲にある施設を検索する請求項１または２に記載の行先提案システム。

【請求項5】

前記旅地点決定部は、所定の期間内に行った回数が所定の回数以下の地点を旅地点として求める請求項１ないし４のいずれかに記載の行先提案システム。

【請求項6】

前記旅地点決定部は、定期的に行っている地点ではない地点を前記旅地点として決定する請求項１ないし５のいずれかに記載の行先提案システム。

【請求項7】

前記旅地点決定部は、前記行った回数が所定の回数以上である所定長さの期間が存在しない地点を前記旅地点として決定する請求項１ないし６のいずれかに記載の行先提案システム。

【請求項8】

行先提案システムが、走行履歴データベースに記憶された車両の走行履歴データに基づいてユーザに行先を提案する方法であって、
前記行先提案システムが、前記走行履歴データに基づいて、所定の回数以上の出発回数を有する地点をハブ地点として、当該ハブ地点から行った回数または頻度が所定の基準を満たす地点を旅地点として求めるステップと、
前記行先提案システムが、前記ハブ地点から複数の前記旅地点までの距離または所要時間を求め、複数の前記旅地点までの距離または所要時間の最頻値を求めるステップと、
前記行先提案システムが、前記最頻値に基づく距離または所要時間の範囲にある施設を、施設の名称及び属性のデータを記憶した地図データベースから検索するステップと、
ユーザに行先案内する場合に、前記行先提案システムが、検索された施設をユーザに提示するステップと、
を備える行先提案方法。

【請求項9】

走行履歴データベースに記憶された車両の走行履歴データに基づいてユーザに行先を提案するためのプログラムであって、コンピュータに、
前記走行履歴データに基づいて、所定の回数以上の出発回数を有する地点をハブ地点として、当該ハブ地点から行った回数または頻度が所定の基準を満たす地点を旅地点として求めるステップと、
前記ハブ地点から、複数の前記旅地点までの距離または所要時間を求め、複数の前記旅地点までの距離または所要時間の最頻値を求めるステップと、
前記最頻値に基づく距離または所要時間の範囲にある施設を、施設の名称及び属性のデータを記憶した地図データベースから検索するステップと、
ユーザに行先案内する場合に、検索された施設をユーザに提示するステップと、
を実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、行先を提案するシステムに関する。

【背景技術】

【0002】

従来から、目的地の候補を提案するアプリケーションが知られていた（特許文献１）。特許文献１に記載されたアプリケーションでは、車両内での乗員の発言内容を単語単位に分解し、音声認識手段がジャンルを認識する。そして、目的地ジャンル候補について最終決定条件が満足されたときに当該ジャンルに該当する目的地候補を提示する。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２００９−１１５５９４号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

上述したような従来のアプリケーションでは、ユーザが望むジャンルの目的地を提案することができるが、ユーザの行動範囲ではない地域にある行先が提案され、ユーザにとって使いづらい場合があった。

【0005】

そこで、本発明は上記背景に鑑み、ユーザが出かけやすい場所にある行き先を提案できる行先提案システムを提供することを目的とする。

【課題を解決するための手段】

【0006】

本発明の行先提案システムは、施設のデータを記憶した地図データベースと、車両の走行履歴データを記憶した走行履歴データベースと、前記走行履歴データに基づいて、所定の回数以上の出発回数を有する地点をハブ地点として、当該ハブ地点から行った回数または頻度が所定の基準を満たす地点を旅地点として求める旅地点決定部と、前記ハブ地点から複数の前記旅地点までの距離または所要時間を求め、複数の前記旅地点までの距離または所要時間の最頻値を求める最頻値算出部と、前記最頻値に基づく距離または所要時間の範囲にある施設を前記地図データベースから検索する施設検索部と、ユーザに行先案内する場合に、前記施設検索部にて検索された施設をユーザに提示する出力部とを備える。なお、ハブ地点は、前記走行履歴データに基づいて出発回数の最も多い地点を求めてもよいし、ユーザの自宅をハブ地点として登録しておいてもよい。

【0007】

このように過去に行った旅地点までの距離または所要時間の最頻値の範囲にある施設を提示することにより、ユーザが持っている日程感に合った行先を提案することができる。本明細書において、「旅地点」という用語は、ユーザが遊びに行った地点を指し、何か用事があってどうしても行かなければならなかった地点（会社、病院等）とは異なる地点を指すものとして用いる。

【0008】

本発明の行先提案システムは、行先提案を求める施設の属性の入力を受け付ける入力部を備え、前記最頻値算出部は、旅地点の属性ごとに前記距離または所要時間の最頻値を求め、前記施設検索部は、入力された属性と同じ属性の旅地点までの距離または所要時間の最頻値の範囲にある、入力された属性と同じ属性の施設を検索してもよい。

【0009】

この構成により、旅地点の属性ごとに、適切な距離または所要時間の範囲にある施設を提示することができる。ここで属性とは、例えば、観光地、レストラン、デパート等であり、地図データベースに施設データとして記憶されている。

【0010】

本発明の行先提案システムにおいて、出発してから戻るまでの希望時間の入力を受け付ける入力部を備え、前記最頻値算出部は、前記ハブ地点を出発してから戻るまでに要した時間ごとに前記距離または所要時間の最頻値を求め、前記施設検索部は、前記ハブ地点を出発してから戻るまでに前記希望時間と同じ時間を要した旅地点までの距離または所要時間の最頻値の範囲にある施設を検索してもよい。

【0011】

この構成により、ユーザが希望する旅行時間（３時間、６時間、９時間、１泊２日等）に応じて、適切な距離または所要時間にある施設を提示することができる。

【0012】

本発明の行先提案システムにおいて、前記旅地点決定部は、所定の期間内に行った回数が所定の回数以下の地点、定期的に行っている地点ではない地点、または、前記行った回数が所定の回数以上である所定長さの期間が存在しない地点を旅地点として求めてもよい。

【0013】

この構成により、例えば、会社や病院等のように何か用事があって頻繁に行く地点を旅地点から除外することができる。ここで「行った回数が所定の回数以上である所定長さの期間が存在しない地点」とは、例えば、１か月などの所定長さの期間内に、所定の回数（例えば５回）以上、集中的に行っている地点は、例えば、通院していた等の理由が考えられるので、そういった期間がある地点は旅地点から除外するためである。

【0014】

本発明の行先提案方法は、行先提案システムが走行履歴データベースに記憶された車両の走行履歴データに基づいてユーザに行先を提案する方法であって、前記行先提案システムが、前記走行履歴データに基づいて、所定の回数以上の出発回数を有する地点をハブ地点として、当該ハブ地点から行った回数または頻度が所定の基準を満たす地点を旅地点として求めるステップと、前記行先提案システムが、前記ハブ地点から複数の前記旅地点までの距離または所要時間を求め、複数の前記旅地点までの距離または所要時間の最頻値を求めるステップと、前記行先提案システムが、前記最頻値に基づく距離または所要時間の範囲にある施設を地図データベースから検索するステップと、ユーザに行先案内する場合に、前記行先提案システムが、検索された施設をユーザに提示するステップとを備える。

【0015】

本発明のプログラムは、走行履歴データベースに記憶された車両の走行履歴データに基づいてユーザに行先を提案するためのプログラムであって、コンピュータに、前記走行履歴データに基づいて、所定の回数以上の出発回数を有する地点をハブ地点として、当該ハブ地点から行った回数または頻度が所定の基準を満たす地点を旅地点として求めるステップと、前記ハブ地点から複数の前記旅地点までの距離または所要時間を求め、複数の前記旅地点までの距離または所要時間の最頻値を求めるステップと、前記最頻値に基づく距離または所要時間の範囲にある施設を地図データベースから検索するステップと、ユーザに行先案内する場合に、検索された施設をユーザに提示するステップとを実行させる。

【発明の効果】

【0016】

本発明は、過去に行った旅地点までの距離または所要時間の最頻値の範囲にある施設を提示することにより、ユーザが持っている日程感に合った行先を提案することができるという効果を有する。

【図面の簡単な説明】

【0017】

【図1】第１の実施の形態の行先提案システムの構成を示す図である。

【図2】走行履歴データベースに記憶されたデータの例を示す図である。

【図3】旅地点までの所要時間の最頻値を求める例を示す図である。

【図4】第１の実施の形態の行先提案システムのハードウェア構成を示す図である。

【図5】第１の実施の形態の行先提案システムの動作を示す図である。

【図6】旅地点の決定の動作を示す図である。

【図7】第２の実施の形態の行先提案システムにて旅地点までの所要時間の最頻値を求めた例を示す図である。

【図8】第３の実施の形態の行先提案システムにて旅地点までの所要時間の最頻値を求めた例を示す図である。

【図9】ネットワークによって接続された行先提案システムの構成の例を示す図である。

【発明を実施するための形態】

【0018】

以下、本発明の実施の形態の行先提案システムについて図面を参照しながら説明する。
（第１の実施の形態）
図１は、第１の実施の形態の行先提案システム１０の構成を示す図である。第１の実施の形態の行先提案システム１０は、車両に搭載して用いられる。行先提案システム１０は、地図データを記憶した地図データベース（以下、「地図ＤＢ」という）１２と、車両の走行履歴を記憶する走行履歴データベース（以下、「走行履歴ＤＢ」という）１４と、行先提案のリクエストを入力する入力部１６と、行先を出力する出力部１８と、提案すべき行先を求める制御部２０とを有している。

【0019】

行先提案システム１０は、現在位置検出部３０及びイグニッションキー３２と接続されている。現在位置検出部３０は、例えば、車両の絶対方位を検出するための地磁気センサ、車両の相対方位を検出するためのジャイロスコープ、車両の走行距離を検出する距離センサ、および衛星からの電波に基づいて車両の位置を測定するグローバルポジショニングシステム（ＧＰＳ）のためのＧＰＳ受信機を有している。これらのセンサ等はそれぞれが性質の異なる誤差を持っているため、複数のセンサ等により各々を補完しながら使用するように構成されている。なお、精度によっては、上述したうちの一部のセンサで現在位置検出部３０を構成してもよいし、更に、図示しないステアリングの回転センサ、各転動輪の車速センサ等を用いてもよい。

【0020】

地図ＤＢ１２は、道路地図のデータと、施設の名称や属性、その詳細情報などの施設データを有している。地図ＤＢ１２は、ネットワーク上に備えられたサーバから、最新の地図データをダウンロードすることとしてもよい。

【0021】

図２は、走行履歴ＤＢ１４に記憶されたデータの例を示す図である。走行履歴ＤＢ１４には、出発日時、出発地点、到着日時、到着地点のデータが記憶されている。行先提案システム１０は、現在位置検出部３０にて検出された車両の現在位置データに基づいて、走行履歴データを更新する。

【0022】

出発日時及び出発地点は、車両のエンジンがスタートしたときに取得した時刻及び位置のデータである。到着日時及び到着地点は、車両のエンジンが切られたときに取得した時刻及び位置のデータである。これらのデータは、イグニッションキー３２のオン／オフのデータを取得した時刻、および、そのときに現在位置検出部３０にて検出した現在位置のデータを取得することで、走行履歴ＤＢ２４に蓄積することができる。

【0023】

出発地点及び到着地点の名称は、出発地点、到着地点の位置データに対応する施設を地図ＤＢ１２から読み出して特定したものである。なお、図２に示すデータは、走行履歴データの一例であり、図２に示す以外の形式で走行履歴データと保有してもよい。例えば、現在位置検出部３０にて検出された位置データを時系列に保持することも可能である。

【0024】

入力部１６は、例えば、キーパッドなどにより構成される。入力部１６は、行先提案のリクエストを受け付ける。出力部１８は、例えば、ディスプレイなどにより構成される。出力部１８は、行先提案のリクエストに応じて行先を提示する。出力部１８はタッチパネルによって構成され、入力部１６の一部の機能を担ってもよい。

【0025】

図１に戻って、説明する。制御部２０は、提案すべき行先を求めるための構成として、ハブ地点決定部２２と、旅地点決定部２４と、最頻値算出部２６と、施設検索部２８とを有する。ハブ地点とは、ユーザの行動の拠点となる地点であり、走行履歴データから見ると、複数の目的地を有する地点、すなわち、複数の地点に対して出発した履歴を有する地点である。ハブ地点の典型例は自宅であるが、例えば、帰省先などもハブ地点になり得る。ハブ地点決定部２２は、走行履歴ＤＢ１４に記憶されたデータに基づいて出発回数の最も多い地点をハブ地点として求める。出発回数の多い地点は、それに応じて目的地の数も多くなるので、本実施の形態では、出発回数を用いてハブ地点を求めているが、出発地点ごとに目的地の数を数えて、所定数の目的地を有する地点、または、最大数の目的地を有する地点をハブ地点としてもよい。具体的には、例えば、図２に示す出発地点「自宅」を例にとると、自宅を出発地点として到着した目的地は、「会社」「遊園地」「スーパー」「病院Ｂ」がある。したがって、この例では、自宅を出発地点とする目的地の数は４つである。このようにして出発地点に対応する目的地の数をカウントし、その数に基づいてハブ地点を決定する。なお、あらかじめユーザの自宅がハブ地点として登録されている場合には、ハブ地点決定部２２は不要である。

【0026】

旅地点決定部２４は、到着地点の中から旅地点を求める機能を有する。旅地点決定部２４は、何か用事があってどうしても行かなければならない場所（会社、病院等）を除き、遊びに行ったと思われる場所を旅地点として求める。

【0027】

旅地点決定部２４は、まず、到着地点別にデータを集計し、到着地点での滞在時間の平均値および到着回数を求める。滞在時間の平均値が所定の閾値（例えば、１０分）以下の到着地点については、別の場所へ行く途中で立ち寄っただけの立寄地であると判断し、旅地点からは除く。滞在時間の平均値が所定の閾値より大きい到着地点は、そこが終点であったと判断する。

【0028】

次に、旅地点決定部２４は、終点のうち、到着回数が所定の閾値（例えば、５回）より少ない終点を求める。到着回数が所定の閾値以上の終点は、よく行く場所であって、そこへ行く理由があると判断されるので、旅地点から除外する。到着回数が所定の閾値より少ない終点が旅地点として求められる。なお、本実施の形態では、到着回数が所定の閾値より少ないかどうかで旅地点かどうかを判断することとしているが、定期的に行っている地点ではない地点、または、行った回数が所定の回数以上である所定長さの期間が存在しない地点かどうかを判定してもよい。到着回数が少ない場合にも、定期的に行っている場合や、所定の期間内に集中して行っている場合には、その場所に行く理由（例えば、通院等）があったとも考えられるからである。

【0029】

最頻値算出部２６は、ハブ地点から、複数の旅地点のそれぞれまでの所要時間を求め、複数の前記旅地点までの所要時間の最頻値を求める。

【0030】

図３は、複数の旅地点までの所要時間と行った回数を示すヒストグラムである。図３に示す例では、所要時間が１５〜３０分のところにある旅地点に行った回数は５回、３０〜４５分のところにある旅地点に行った回数は８回、４５〜６０分のところにある旅地点に行った回数は１０回・・・であると分かる。なお、図３に示すように、どの旅地点であるかということや旅地点の属性は考慮せず、旅地点に出かけるときの所要時間のみを問題としている。図３に示す結果によれば、このユーザが旅地点に行くとき（つまり、遊びに行くとき）の所要時間の最頻値は４５〜６０分である。

【0031】

施設検索部２８は、ハブ地点から所要時間の最頻値のところにある施設を検索する。図３に示す例によれば、施設検索部２８は、ハブ地点からの所要時間が４５〜６０分のところにある施設を検索する。

【0032】

図４は、本実施の形態の行先提案システム１０のハードウェア構成を示す図である。行先提案システム１０は、ＣＰＵ４０と、メモリ４２と、ＲＯＭ４４と、外部記憶装置４８と、キーパッド５０と、タッチパネル５２と、通信部５４とがバス５６によって接続されて構成されている。ＲＯＭ４４には、上述した行先提案システム１０の機能を実現するためのプログラム４６が格納されている。このようなプログラム４６も本発明の範囲に含まれる。外部記憶装置４８には、地図ＤＢ１２や走行履歴ＤＢ１４が記憶される。通信部５４は、車両に搭載された各種の機器（現在位置検出部３０、イグニッションキー３２を含む）と通信を行う機能を有している。

【0033】

図５は、行先提案システム１０の動作を示すフローチャートである。行先提案システム１０は、まず、入力部１６から行先提案のリクエストの入力を受け付ける（Ｓ１０）。本実施の形態においては、行先提案システム１０は、例えば、行先提案リクエストボタンをタッチパネルに表示し、そのボタンをタッチされたときに、行先を提案する処理を行うこととしてもよい。

【0034】

行先提案システム１０は、行先提案リクエストの入力を受け付けると、走行履歴ＤＢ１４から走行履歴データを読み出し（Ｓ１２）、走行履歴データに基づいて旅地点を検出する（Ｓ１４）。旅地点検出の動作については、図６を参照して詳細に説明する。

【0035】

行先提案システム１０は、求められた複数の旅地点までのそれぞれの所要時間を求め、旅地点までの所要時間の最頻値を求める（Ｓ１６）。そして、行先提案システム１０は、ハブ地点から所要時間の最頻値の範囲にある施設を検索し（Ｓ１８）、検索された施設を行先として提案する（Ｓ２０）。

【0036】

続いて、図６を参照して、行先提案システム１０が、旅地点を求める動作について説明する。行先提案システム１０は、走行履歴データに基づいて、到着地点別に、その到着地点への到着回数と滞在時間を集計する（Ｓ３０）。到着地点での滞在時間は、その到着地点への到着日時と、その到着地点から次に出発する出発日時との差分によって求められる。

【0037】

行先提案システム１０は、出発回数が最多の地点をハブ地点と判断する（Ｓ３２）。出発回数が最多の地点は到着回数が最多の地点であるので、本実施の形態では、前ステップＳ３２で求めた結果を利用して、到着回数が最多の地点を求める。なお、あらかじめ、ハブ地点として自宅が登録されている場合には、この処理は不要である。

【0038】

次に、行先提案システム１０は、各到着地点での平均滞在時間が閾値より大きいか否かを順に判定する（Ｓ３４）。平均滞在時間が閾値以下の場合には（Ｓ３４でＮＯ）、全到着地点について旅地点かどうかの判定を行ったか否かの判定に遷移し（Ｓ４２）、全到着地点についての判定が完了していない場合（Ｓ４２でＮＯ）、次の到着地点についての判定を行う（Ｓ３４）。

【0039】

到着地点での平均滞在時間が閾値より大きい場合には（Ｓ３４でＹＥＳ）、その到着地点は、立寄地ではない終点であると判断される（Ｓ３６）。次に、その到着地点に行った回数が所定の閾値（例えば５回）より少ないか否かを判定する（Ｓ３８）。到着回数が所定の閾値より少ない場合には（Ｓ３８でＹＥＳ）、その到着地点を旅地点と判断し（Ｓ４０）、全到着地点についての判定が完了したか否かの判定を行う（Ｓ４２）。到着地点に行った回数が所定の閾値以上の場合（Ｓ３８でＮＯ）には、その到着地点は旅地点とは判断されないで、全到着地点についての判定が完了したかの判定に遷移する（Ｓ４２）。

【0040】

走行履歴ＤＢ１４から読み出したすべての到着地点について旅地点か否かの判定が完了したら（Ｓ４２でＹＥＳ）、旅地点を求める処理を終了する。

【0041】

本実施の形態の行先提案システム１０は、過去に行った旅地点までの所要時間の最頻値の範囲にある施設を提示することにより、ユーザが持っている日程感に合った行先を提案することができる。

【0042】

なお、本実施の形態においては、行先提案システム１０は、過去に行った旅地点までの所要時間を用いたが、所要時間に代えて、ハブ地点から旅地点までの距離を用いてもよい。過去に行った旅地点までの距離の最頻値の範囲にある施設を提示することにより、ユーザにとって行きやすい範囲にある行先を提案することができる。

【0043】

本実施の形態では、出発回数が最大の地点をハブ地点として求める例について説明したが、出発回数が所定の回数（例えば、２０回等）以上の地点をハブ地点としてもよい。出発回数が最大の地点をハブ地点とすると、例えば、自家用車を会社でも使用している場合などには、会社の方が出発回数が多くなって、自宅がハブ地点と判断されなく可能性があるが、所定の回数以上とすることにより、このような不都合を防止できる。また、よく一緒に旅行する友人や親せきの家もハブ地点に含めるようなことも可能となる。ただし、出発回数が所定回数以上の地点をハブ地点とすることにより、複数のハブ地点が見つかった場合には、旅地点までの所要時間または距離を求める際には、どのハブ地点から行った旅地点かを特定したうえで、所要時間または距離を求めることが必要である。

【0044】

（第２の実施の形態）
次に、第２の実施の形態の行先提案システム１０について説明する。第２の実施の形態の行先提案システム１０の基本的な構成は第１の実施の形態と同じであるが、第２の実施の形態の行先提案システム１０は、ユーザから行先の属性のデータを受け付け、その属性に合った行先の提案を行う点が異なる。

【0045】

前述したとおり、地図ＤＢ１２に記憶された施設データには施設の属性のデータが含まれている。この施設データを参照することにより、走行履歴ＤＢ１４に記憶された到着地点の属性を特定することができる。行先提案システム１０は、走行履歴ＤＢ１４に基づいて旅地点までの所要時間の最頻値を求める際に、入力された属性と同じ属性を有する旅地点までの所要時間の最頻値を求める。

【0046】

図７は、第２の実施の形態の行先提案システム１０において、「観光施設」の属性を有する旅地点までの所要時間の最頻値と、「レストラン」の属性を有する旅地点までの所要時間の最頻値を求めた例を示す図である。例えば、ユーザから「観光施設」の行先提案を求められたときには、図７の上段のヒストグラムに示すとおり、所要時間の最頻値は４５〜６０分なので、施設検索部２８は、ハブ地点から４５〜６０分の所要時間で行けるエリアから観光施設を検索し、行先を提案する。ユーザから「レストラン」の行先提案を求められたときには、図７の下段のヒストグラムに示すとおり、所要時間の最頻値は１５〜３０分なので、施設検索部２８は、ハブ地点から１５〜３０分の所要時間で行けるエリアからレストランを検索し、行先を提案する。

【0047】

このように入力された属性と同じ属性を有する過去の旅地点のデータを利用することにより、適切な行先提案を行うことができる。

【0048】

なお、本実施の形態では、所要時間を例として説明したが、ハブ地点から旅地点までの距離の最頻値を用いることも可能である。

【0049】

（第３の実施の形態）
次に、第３の実施の形態の行先提案システム１０について説明する。第３の実施の形態の行先提案システム１０の基本的な構成は第１の実施の形態と同じであるが、第３の実施の形態の行先提案システム１０は、ユーザから旅行に要する希望時間の入力を受け付け、その日数に合った行先の提案を行う点が異なる。本実施の形態では、希望時間として、旅行日数を入力する例について説明する。

【0050】

行先提案システム１０は、走行履歴ＤＢ１４に記憶された走行履歴データに基づいて旅地点を求めた後、旅地点を旅行日数ごとに分類する。旅行日数は、ハブ地点を出発してからハブ地点に戻るまでの期間によって求めることができる。例えば、ハブ地点から出発して、翌日にハブ地点に戻った場合には、旅行日数は１泊２日であり、その間に含まれる旅地点は１泊２日の旅行日数に分類される。

【0051】

図８は、第３の実施の形態の行先提案システム１０において、旅行日数が「日帰り」の場合の旅地点までの所要時間の最頻値と、「１泊２日」の場合の所要時間の最頻値を求めた例を示す図である。例えば、ユーザから「日帰り」の場合の行先提案を求められたときには、図８の上段のヒストグラムに示すとおり、所要時間の最頻値は４５〜６０分なので、施設検索部２８は、ハブ地点から４５〜６０分の所要時間で行けるエリアから施設を検索し、行先を提案する。ユーザから「１泊２日」の行先提案を求められたときには、図８の下段のヒストグラムに示すとおり、所要時間の最頻値は１８０〜２１０分なので、施設検索部２８は、ハブ地点から１８０〜２１０分の所要時間で行けるエリアからレストランを検索し、行先を提案する。

【0052】

このように入力された旅行日数と同じ旅行日数で行った過去の旅地点のデータを利用することにより、適切な行先提案を行うことができる。

【0053】

この例では、「１泊２日」「日帰り」等、日数を単位として希望時間を指定する例を挙げて説明したが、「３時間」「６時間」「９時間」等のように、時間単位で希望時間を指定してもよい。

【0054】

なお、本実施の形態では、旅地点までの所要時間の最頻値を用いる例を説明したが、距離の最頻値を用いることも可能である。

【0055】

以上、本発明の行先提案システムについて実施の形態を挙げて詳細に説明したが、本発明は上記した実施の形態に限定されるものではない。上記した実施の形態では、行先提案システムが車両に搭載される例を挙げて説明したが、行先提案システムは必ずしも車両に搭載されていなくてもよく、ユーザの自宅のパソコンなどによって実現することも可能である。この場合、車両にて取得した走行履歴データを、ＵＳＢメモリなどの記録媒体にコピーしてパソコンに移すなどして、パソコンにて利用できるようにすることが必要である。

【0056】

また、所要時間または距離の最頻値の範囲にある施設を検索する場合に、ユーザがよく行く方面については、検索の範囲を拡大してもよい。例えば、所要時間４５〜６０分の範囲にある施設を検索する場合に、ユーザの会社のある方面については、４５〜７５分の範囲にある施設を検索するようにしてもよい。人は、同じ時間だけ走行しても良く知っている道路の場合には、時間を短く感じるという特性があるので、これを利用することにより、適切な行先提案が可能となる。

【0057】

上記した実施の形態では、行先提案の処理を一つの装置で処理する例について説明したが、行先提案システムは、ネットワークによって接続された複数の装置（サーバと端末）によって処理してもよいことは言うまでもない。

【0058】

図９は、入力部１６と出力部１８とを車載装置６４側に備え、それ以外の構成をサーバ６０側に備えた行先提案システムの構成を示す図である。車載装置６４とサーバ６０はそれぞれ通信部６２，６６を備えており、ネットワークを介して通信接続されている。この構成において、車載装置６４は、出発地点と到着地点のデータを取得するたびに、サーバ６０に送信する。サーバ６０は、車載装置６４から受信した出発地点と到着地点のデータを走行履歴ＤＢ１４に蓄積する。車載装置６４の入力部１６から行先提案のリクエストが入力されると、車載装置６４はこのリクエストをサーバ６０に送信し、サーバ６０は上記した実施の形態と同様にして行先を検索し、検索された施設のデータを車載装置６４に送信する。車載装置６４は、出力部１８にて、サーバ６０から受信した施設のデータを行先提案する。図９に示すのは一例であり、ネットワーク上における機能の分担の仕方はほかにも考えられる。例えば、施設を検索する範囲の計算までを車載装置６４側で行うこととし、その範囲にある施設の検索をサーバ６０で行うことも可能である。

【0059】

上記した実施の形態では、走行履歴ＤＢ１４に記憶されたデータに基づいて出発地点の中からハブ地点を決定する例について説明したが、出発地点以外をハブ地点とすることも可能である。例えば、走行履歴ＤＢに、走行した道路リンクのデータを記憶しておく。行先提案システムは、道路リンクのデータを解析して、複数の目的地への分岐点となっている交差点を検出し、その交差点をハブ地点として求めてもよい。これにより、その交差点において、適切な行先を提案することができる。

【産業上の利用可能性】

【0060】

本発明は、ユーザが持っている日程感に合った行先を提案することができるという効果を有し、例えば、ナビゲーション装置等のように車両に搭載される装置等として有用である。

【符号の説明】

【0061】

１０ 行先提案システム
１２ 地図ＤＢ
１４ 走行履歴ＤＢ
１６ 入力部
１８ 出力部
２０ 制御部
２２ ハブ地点決定部
２４ 旅地点決定部
２６ 最頻値算出部
２８ 施設検索部
３０ 現在位置検出部
３２ イグニッションキー
４０ ＣＰＵ
４２ メモリ
４４ ＲＯＭ
４６ プログラム
４８ 外部記憶装置
５０ キーパッド
５２ タッチパネル
５４ 通信部
５６ バス
６０ サーバ
６２ 通信部
６４ 車載装置
６６ 通信部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】