特許 6389725 情報処理装置、経路案内システム、プログラム

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

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

(11)【特許番号】6389725

(24)【登録日】2018年8月24日

(45)【発行日】2018年9月12日

(54)【発明の名称】情報処理装置、経路案内システム、プログラム

(51)【国際特許分類】

   G01C 21/26 20060101AFI20180903BHJP

   G08G 1/005 20060101ALI20180903BHJP

   G09B 29/10 20060101ALI20180903BHJP

【ＦＩ】

   G01C21/26 P

   G08G1/005

   G09B29/10 A

【請求項の数】10

【全頁数】20

(21)【出願番号】特願2014-204833(P2014-204833)

(22)【出願日】2014年10月3日

(65)【公開番号】特開2016-75516(P2016-75516A)

(43)【公開日】2016年5月12日

【審査請求日】2017年3月24日

(73)【特許権者】

【識別番号】500578216

【氏名又は名称】株式会社ゼンリンデータコム

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(72)【発明者】

【氏名】西田 純

(72)【発明者】

【氏名】小野寺 宜宏

【審査官】 笹岡 友陽

(56)【参考文献】

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

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

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

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

Ｇ０１Ｃ ２１／２６

Ｇ０８Ｇ １／００５

Ｇ０９Ｂ ２９／１０

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

【請求項1】

施設が提供する対象を利用した経路を案内する情報処理装置であって、
出発地と目的地の位置情報を取得して出発地から目的地までの経路を検索する経路検索手段と、
施設の対象を利用した対象利用者の数情報が、対象利用者が通過した施設の入り口に対応づけて記憶された数情報記憶手段を参照して、
前記経路検索手段が検索した経路に含まれる施設が有する複数の入り口のうち、前記数情報記憶手段に記憶されている前記数情報が最も多い入り口を決定する入り口決定手段と、を有し、
前記経路検索手段は、前記入り口決定手段が決定した入り口を含む経路を作成する、ことを特徴とする情報処理装置。

【請求項2】

前記数情報記憶手段は、対象利用者が通過した入り口と対象利用者が利用した施設の対象に対応づけて施設の対象を利用した対象利用者の数情報を記憶しており、
前記入り口決定手段は、前記数情報記憶手段を参照し、前記経路検索手段が検索した経路に含まれる施設が有する複数の入り口のうち、該経路に含まれる対象に対応づけられた数情報が最も多い入り口を決定する、ことを特徴とする請求項１に記載の情報処理装置。

【請求項3】

前記数情報記憶手段は、対象利用者が通過した入り口、対象利用者が利用した施設の対象、及び、対象を利用する前の対象利用者の施設に対する相対位置情報に対応づけて、施設の対象を利用した対象利用者の数情報が記憶されており、
前記入り口決定手段は、前記数情報記憶手段を参照し、前記経路検索手段が検索した経路に含まれる施設が有する複数の入り口のうち、
前記経路検索手段が検索した経路に含まれる施設に対する出発地の相対位置情報と前記経路に含まれる対象に対応づけられた数情報が最も多い入り口を決定する、ことを特徴とする請求項２に記載の情報処理装置。

【請求項4】

前記数情報記憶手段には、対象が利用された時間帯ごとに対象を利用した対象利用者の数情報が記憶されており、
前記入り口決定手段は、前記数情報記憶手段を参照し、前記経路検索手段が検索した経路に含まれる施設が有する複数の入り口のうち、ユーザが入り口に到達する時間帯において、最も多い数情報が対応づけられている入り口を決定する、ことを特徴とする請求項１〜３のいずれか１項に記載の情報処理装置。

【請求項5】

前記対象利用者の位置情報を取得する位置情報取得手段と、
前記位置情報から対象利用者が利用した施設、前記対象利用者が利用した該施設の入り口及び対象を判断して、前記施設の入り口に対応づけて、前記対象を利用した対象利用者の前記数情報を前記数情報記憶手段に記憶させる蓄積手段と、
を有することを特徴とする請求項１〜４のいずれか１項に記載の情報処理装置。

【請求項6】

前記蓄積手段は、前記施設の入り口及び対象利用者が利用した前記対象に対応づけて、前記対象が利用された数の前記数情報を前記数情報記憶手段に記憶させる、ことを特徴とする請求項５に記載の情報処理装置。

【請求項7】

前記蓄積手段は、前記位置情報から対象利用者が前記施設を利用する前の前記施設に対する相対位置を判断して、前記施設の入り口、対象利用者が利用した対象及び前記相対位置に対応づけて対象を利用した前記対象利用者の前記数情報を数情報記憶手段に記憶させる、ことを特徴とする請求項６に記載の情報処理装置。

【請求項8】

前記施設が駅の場合、前記対象は路線であり、
前記施設がデパート又はショッピングモールの場合、前記対象は店舗又は化粧室であり、
前記施設が空港の場合、前記対象は航空会社であり、入り口は降車ホーム又は駐車場である、ことを特徴とする請求項１〜７のいずれか１項に記載の情報処理装置。

【請求項9】

施設が提供する対象を利用した経路を端末に案内する経路案内システムであって、
前記端末から出発地と目的地の位置情報を取得して、出発地から目的地までの経路を検索する経路検索手段と、
施設の入り口を通過して施設の対象を利用した対象利用者の数情報が、入り口に対応づけて記憶された数情報記憶手段を参照して、
前記経路検索手段が検索した経路に含まれる施設が有する複数の入り口のうち、前記数情報記憶手段に記憶されている前記数情報が最も多い入り口を決定する入り口決定手段と、
前記入り口決定手段が決定した入り口を含む経路を表示する経路表示手段と、
を有することを特徴とする経路案内システム。

【請求項10】

施設が提供する対象を利用した経路を案内する情報処理装置に、
出発地と目的地の位置情報を取得して出発地から目的地までの経路を検索する経路検索ステップと、
施設の入り口を通過して施設の対象を利用した対象利用者の数情報が、入り口に対応づけて記憶された数情報記憶手段を参照して、
前記経路検索ステップにより検索された経路に含まれる施設が有する複数の入り口のうち、前記数情報記憶手段に記憶されている前記数情報が最も多い入り口を決定する入り口決定ステップと、を実行させ、
前記経路検索ステップでは、前記入り口決定ステップにより決定された入り口を含む経路を作成する、ことを特徴とするプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、施設が提供する対象を利用した経路を案内する情報処理装置、経路案内システム及びプログラムに関する。

【背景技術】

【0002】

従来から車載されたナビゲーション装置が知られているが、スマートフォンの普及に伴いスマートフォンにナビゲーション用のアプリケーションソフトウェアを実行させることによりナビゲーション装置として機能させることができるようになった。また、ＰＮＤ（Portable Navigation Device）などと呼ばれる持ち運び可能なナビゲーション装置も知られている。これらのユーザは、スマートフォンやＰＮＤを自動車に搭載してカーナビゲーション装置として用いたり、徒歩で移動する場合の歩行者用ナビゲーション装置として用いたりできる。また、出発地から目的地まで、電車、飛行機、クルマ、バス、徒歩などの様々な交通手段の最適な組み合わせを提案するナビゲーションも実用化されている。

【0003】

この歩行者用ナビゲーション装置にユーザが目的地までの経路案内をさせる場合、歩行者用ナビゲーション装置が列車を使用した経路を案内する場合がある。複数の路線を利用できるような大きな駅を経由地とする場合、駅には多数の出入り口が存在するが、その全てがユーザの経路に含まれる列車の路線に適切であるとは言えず、ユーザの路線に最適な出入り口が存在すると考えられる。

【0004】

このような背景に対し、従来から出入り口が複数ある場合に最適な出入り口を表示するナビゲーションシステムが考案されている（例えば、特許文献１参照。）。特許文献１には、目的地の出入口に対応する交通路線・運行情報と該交通機関の乗降口を表示する歩行者用ナビゲーションシステムが開示されている。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特開２００２−５６８３号公報

【発明の概要】

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

【0006】

しかしながら、特許文献１に記載されたナビゲーションシステムでは、路線の利用者により出入り口が実際に利用されているか否かが考慮されておらず、表示される出入り口の精度が低い場合があるという問題がある。

【0007】

本発明は、上記課題に鑑み、施設に複数の入り口がある場合に適切な入り口を案内する情報処理装置を提供することを目的とする。

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

【0008】

上記課題に鑑み、本発明は、施設が提供する対象を利用した経路を案内する情報処理装置であって、出発地と目的地の位置情報を取得して出発地から目的地までの経路を検索する経路検索手段と、施設の対象を利用した数の数情報が、対象利用者が通過した施設の入り口に対応づけて記憶された数情報記憶手段を参照して、前記経路検索手段が検索した経路に含まれる施設が有する複数の入り口のうち、前記数情報記憶手段に記憶されている前記数情報が最も多い入り口を決定する入り口決定手段と、を有し、前記経路検索手段は、前記入り口決定手段が決定した入り口を含む経路を作成する、ことを特徴とする。

【発明の効果】

【0009】

施設に複数の入り口がある場合に適切な入り口を案内する情報処理装置を提供することができる。

【図面の簡単な説明】

【0010】

【図1】本実施形態のナビゲーションサーバによる経路案内の概略を説明する図の一例である。

【図2】駅の入り口と改札口の関係を説明する図の一例である。

【図3】経路案内システムのシステム構成図の一例である。

【図4】ナビゲーションサーバ及び端末のハードウェア構成図の一例である。

【図5】経路案内システムが備える機能ブロック図の一例である。

【図6】施設情報ＤＢに記憶されている施設情報を模式的に示す図の一例である。

【図7】方面路線データＤＢに記憶されている方面路線データを模式的に示す図の一例である。

【図8】方面路線データの蓄積を模式的に説明する図の一例である。

【図9】路線利用者のプローブデータを模式的に示す図の一例である。

【図10】方面路線データを利用した入り口の判断方法を説明する図の一例である。

【図11】端末（経路案内用）の表示装置に表示されたナビ画面の一例を示す図である。

【図12】ナビゲーションサーバが方面路線データを蓄積する手順を示すシーケンス図の一例である。

【図13】ナビゲーションサーバが入り口を判断して経路情報を作成する手順を示すシーケンス図の一例である。

【図14】施設がデパートやショッピングモールの場合の方面路線データを示す図の一例である。

【図15】時間帯別に蓄積された方面路線データの一例を示す図である。

【図16】駅の入り口、改札口、及び、路線の関係を模式的に示す図の一例である。

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

【0011】

以下、本発明を実施するための形態について図面を参照しながら説明する。

【0012】

＜本実施形態のナビゲーションサーバの概略的特徴＞
まず、図１を用いて本実施形態のナビゲーションサーバによる経路案内の概略を説明する。図１（ａ）は比較のために示した従来の経路案内を説明する図の一例である。図１（ｂ）は本実施形態のナビゲーションサーバの経路案内を説明する図の一例である。なお、ユーザは後述する端末を携帯している。

【0013】

図示する駅１０には４つの入り口１１（以下、区別する場合、入り口Ａ〜Ｄという）が存在する。図１（ａ）に示すように、駅１０の北側から接近したユーザに対し、従来はユーザに最も近い北側の入り口Ａを案内していた。

【0014】

これに対し、本実施形態では、入り口ごとに、路線利用者の接近方面（接近方面は相対位置情報の一例である）と路線に対応づけて蓄積された路線利用者の数（又は数に相関する情報であればよく数情報の一例である。）を利用して、入り口を案内する。路線利用者の数を蓄積することで、例えば以下のような情報が得られる。
・北側から路線Ｉに乗車する人は入り口Ｂを利用することが多い。
・南側から路線Ｉに乗車する人は入り口Ｃを利用することが多い。

【0015】

したがって、北側から路線Ｉに乗車するユーザが駅１０に接近する場合、ナビゲーションサーバは蓄積されている路線利用者の数を参照して、ユーザの接近方面と利用する路線に最適な入り口を案内する。図１（ｂ）に示すように、路線Ｉを利用するユーザが北側から接近した場合、過去の路線利用者の数によれば入り口Ｂが多く利用されるので、ナビゲーションサーバはユーザに入り口Ｂを案内する。路線利用者の数が多い入り口は、多くの路線利用者が接近方面と路線を考慮した場合に利用することが合理的であると判断した入り口であると考えられるので、ナビゲーションサーバは最適な入り口をユーザに案内できる。

【0016】

＜入り口について＞
本実施形態における施設の入り口１１について説明する。入り口１１は、ユーザが駅１０などの施設に入ることが可能な場所であるが、施設の一部（敷地内）にあるとは限らない。また、入り口１１は通常、出口としても使用可能である。

【0017】

図２を用いて、施設として駅１０が利用される場合の入り口１１について説明する。図２は、駅１０の入り口１１と改札口１２の関係を説明する図の一例である。図２（ａ）では駅１０の入り口１１の直後に改札口１２が設置されており、駅１０を利用するために入り口１１を通過した路線利用者は必ずこの改札口１２を利用する。このように入り口１１と改札口１２が一体と見なせる構造の場合、入り口と改札口１２を厳密に区別する必要はなく、入り口１１を案内することと改札口１２を案内することを同一視できる。しかしながら、このような構造の入り口１１と改札口１２は希であり、図２（ｂ）に示すように１つの改札口１２に対し複数の入り口（入り口Ａ〜Ｃ）が存在する場合が少なくない。

【0018】

図２（ｂ）では１つの改札口１２に３つの入り口Ａ〜Ｃが設けられている。入り口Ａ、入り口Ｂは駅１０の手前側の道路に設けられており、改札口１２と地下道や歩道橋（ペデストリアンデッキ）等でつながっている。路線利用者は入り口Ａ〜Ｃのいずれを通過しても改札口１２に到達できる。そして、改札口１２が１つでも入り口Ａ〜Ｃを利用する路線利用者の数に偏りが生じる場合がある。これは、エスカレータやエレベータの有無、入り口１１を通過後の道の広さ・凹凸、雨や日差しを避けられるか否か、歩行時間などに違いがあるためである。日常的に駅１０を使用している路線利用者は自分にとって合理的な入り口１１を選ぶため、多く使用される入り口１１は総合的に多くの路線利用者に支持されている入り口１１であると推定できる。よって、本実施形態のナビゲーションサーバは、路線利用者に支持されている入り口をこの駅１０をあまり利用しないユーザに対し提案できる。

【0019】

また、図２（ｃ）に示すように、比較的大きな駅１０では複数の改札口１２を有することが多い。図２（ｃ）では、駅１０に路線Iの改札口Ａと路線IIの改札口Ｂとが設けられている。例えば、入り口Ａ〜Ｃは改札口Ａと改札口Ｂのどちらにも通じているが、入り口Ｃから改札口Ｂへ到達するための通路が狭かったり、階段の上り下りが多い場合、Ｘ方向から到達する路線利用者の多くは入り口Ｂを使用する状況が生じうる。本実施形態のナビゲーションサーバは、路線IIを利用する端末のユーザに対し、多く使用される入り口Ｂをユーザに提案できるので、この駅１０をあまり利用しないユーザに対し路線利用者に支持されている入り口を提案できる。

【0020】

このように、本実施形態では図２（ｂ）（ｃ）のように改札口へつながる入り口が１つでない場合に適切な入り口を提案できる。

【0021】

また、本実施形態の路線とは鉄道路線をいい、異なる鉄道会社が運営する路線は区別して扱われる。また、同じ鉄道会社であっても行き先の異なる路線は区別される。

【0022】

本実施形態の入り口の案内は、駅以外の施設についても適用可能であるが詳細は後述する。

【0023】

また、本実施形態では路線を利用する者を路線利用者、端末２２を利用する者をユーザと称するが、路線利用者がユーザとなることもあるため便宜的な区別に過ぎない。路線利用者は対象利用者の一例である。

【0024】

＜システムなどの構成例＞
図３は、本実施形態にかかる経路案内システム１００のシステム構成図の一例である。経路案内システム１００は、ネットワーク１３を介して接続されたナビゲーションサーバ２１及び端末２２を有している。

【0025】

ネットワーク１３は、主にインターネット、ＷＡＮやＬＡＮなどの主に有線で構築される通信網と、携帯電話網や無線ＬＡＮなどの主に無線で構築される通信網とを有している。有線のみ又は無線のみで構築されていてもよい。端末２２は無線で基地局１４やアクセスポイント１５にアクセスすることでネットワーク１３に接続する。

【0026】

ナビゲーションサーバ２１は、端末２２に対し、ナビゲーションに関するサービス・機能を提供するサーバ装置である。ナビゲーションサーバ２１は情報処理装置の一例である。例えば、端末２２から現在地と目的地を取得して経路を検索し、経路情報とナビ画面を端末２２に送信する。

【0027】

端末２２は、路線利用者又はユーザが利用するナビゲーション端末である。端末２２は、汎用的な情報処理端末２２１である場合とナビゲーション専用端末２２２の場合がある。ナビゲーション専用端末２２２はＰＮＤ（Portable Navigation Device）とも呼ばれる。なお、本実施形態の端末２２は、情報処理端末２２１又はナビゲーション専用端末２２２以外でもよい。

【0028】

情報処理端末２２１としての端末２２は、例えば、スマートフォン、タブレット端末、携帯電話、ＰＤＡ（Personal Digital Assistant）、ノートＰＣ、及び、ウェアラブルＰＣなどである。情報処理端末２２１はこれらに限定されるものではなく、経路案内に適切な装置であればよい。これらの装置は、普段は情報処理端末として利用されるが、ナビゲーションのためのアプリケーションソフトウェアを実行すると、ナビゲーション専用端末２２２と同様、ルート検索及び経路案内等を行う。情報処理端末２２１は情報処理装置の一例である。

【0029】

また、端末２２は、汎用的な情報処理端末２２１とナビゲーション専用端末２２２のどちらの場合でも、車載された状態と携帯可能な状態の切り替えが可能であってもよい。

【0030】

端末２２の動作態様には大きく２つある。１つは、端末２２が例えば専用のアプリケーションソフトウェアやＷｅｂブラウザを起動してナビゲーションサーバ２１と通信し、経路案内に関する情報を受信して表示するクライアント型の動作態様である。もう１つは、原則的に地図の描画などの処理を端末内で完結し、地図データの取得など必要な場合にのみナビゲーションサーバ２１と通信するアプリケーション型の動作端末である。本実施形態では、クライアント型を例に説明するが、アプリケーション型に対しても本実施形態の経路案内を好適に適用できる。

【0031】

なお、ユーザは２台の端末２２を用いて、経路案内システム１００を利用してもよい。例えば、ノートＰＣなどの端末２２でドライブポータルサイトにアクセスして、出発地から目的地までのルートを事前に検索しておく。ドライブポータルサイトは、運転者（ドライバ）のための情報サービスサイトである。検索されたルートはドライブポータルサイトに登録しておき、任意のタイミングでスマートフォンなどの端末２２から登録されている経路情報をダウンロードする。

【0032】

図４は、ナビゲーションサーバ２１及び端末２２のハードウェア構成図の一例である。図４（ａ）に示すように、ナビゲーションサーバ２１は、ハードウェア構成として、ＣＰＵ（Central Processing Unit）２１１、ＲＯＭ（Read Only Memory）２１５、ＲＡＭ（Random Access Memory）２１６、補助記憶装置２１７、入力装置２１２、表示装置２１３、及び、通信装置２１４を有する。

【0033】

また、図４（ｂ）に示すように、端末２２は、ハードウェア構成として、ＣＰＵ２１１、ＲＯＭ２１５、ＲＡＭ２１６、補助記憶装置２１７、入力装置２１２、表示装置２１３、通信装置２１４、音声入出力装置２１８、及び、ＧＰＳ受信装置２１９を有する。

【0034】

ＣＰＵ２１１は、各種プログラムの実行や演算処理を行う。ＲＯＭ２１５には、起動時に必要なプログラムなどが記憶されている。ＲＡＭ２１６は、ＣＰＵ２１１での処理を一時的に記憶したり、データを記憶したりする作業エリアである。補助記憶装置２１７は、各種データ及びプログラム２１０１、２１０２を格納する不揮発性のメモリである。入力装置２１２は、例えばキーボードやマウスである。表示装置２１３は、ディスプレイであり、例えば、ナビ画面等が表示される。通信装置２１４は、ネットワーク１３に接続して他装置との通信を行う。音声入出力装置２１８は、音声の入出力を行う装置であり、例えば、ナビゲーションの音声ガイダンスが出力される。ＧＰＳ受信装置２１９は、ＧＰＳ衛星の電波を受信して現在位置を算出する。

【0035】

なお、端末２２の入力装置２１２は、キーボードやマウスに代え又はこれらに加えて、画面に対する接触位置（タッチ座標）を検知可能なタッチパネルにより実現されうる。また、入力装置２１２は、音声入出力装置２１８が入力させた音声を認識する音声認識装置としての機能を有していてもよい。

【0036】

ナビゲーションサーバ２１又は端末２２の補助記憶装置２１７に記憶されているプログラム２１０１，２１０２は、不図示の記憶媒体に記憶された状態で配布される。あるいは、不図示のサーバからダウンロードすることで配布される。端末２２のプログラム２１０２は経路案内に専用のアプリケーションソフトウェアでもよいし、ブラウザソフトウェアでもよい。

【0037】

＜経路案内システムの機能構成例＞
図５は、本実施形態の経路案内システム１００が備える機能ブロック図の一例である。経路案内システム１００は、ナビゲーションサーバ２１、端末（蓄積用）２２ａ、及び、端末（経路案内用）２２ｂを有している。端末（蓄積用）２２ａは後述する方面路線データを蓄積するための端末２２であり、端末（経路案内用）２２ｂは蓄積された方面路線データを利用して経路案内などを行うための端末２２である。図４では説明のため、端末（蓄積用）２２ａと端末（経路案内用）２２ｂがそれぞれ図示されているが、端末（蓄積用）２２ａが端末（経路案内用）２２ｂとして使用される場合も生じるので、便宜的な区別に過ぎない。

【0038】

端末（蓄積用）２２ａはプローブデータ送信部３１と位置情報取得部３２を有している。プローブデータ送信部３１と位置情報取得部３２は、図４に示したＣＰＵ２１１がプログラム２１０２を実行して端末２２のハードウェアと協働することで実現される機能又は手段である。これらの機能の一部又は全てがＩＣなどのハードウェア回路により実現されてもよい。

【0039】

端末（蓄積用）２２ａはプローブデータをナビゲーションサーバ２１に送信する。プローブデータとは移動軌跡情報ともいい、厳密な定義はないが、例えば、移動軌跡を特定できる程度の頻度で取得される、以下のような情報である。

【0040】

「時刻、位置情報（経度・緯度・標高）、速度、及び、端末２２の識別情報などを含む情報」
端末（蓄積用）２２ａがプローブデータを送信することで、ナビゲーションサーバ２１では、路線利用者がどのような経路で移動したかが判明する。

【0041】

位置情報取得部３２は、端末の現在地の位置情報を取得する。例えば、ＧＰＳ受信装置２１９により位置を検出してもよいし、屋内であればIMES（Indoor MEssaging System）、Wi-Fi（複数の無線ＬＡＮのアクセスポイントからの電波強度などから位置を算出する）、超音波（複数の音源を検出して３点測量により位置を算出する）、BLE(Bluetooth Low Energy)などにより位置を検出できる。

【0042】

プローブデータ送信部３１は、定期的にプローブデータをナビゲーションサーバ２１に送信する。定期的に限られず、位置が所定値以上変動した場合や路線利用者の操作を契機にして送信してもよい。

【0043】

なお、端末（蓄積用）２２ａは目的地までの経路が検索された経路情報（ルートデータ）を有していてもよい。しかし、端末（蓄積用）２２ａが経路情報を有し経路案内が行われていても、プローブデータは端末（蓄積用）２２ａが実際に移動した移動経路に基づいて送信される。

【0044】

端末（経路案内用）２２ｂは端末送受信部３３、案内要求受付部３４、及び、経路案内部３５を有している。端末送受信部３３、案内要求受付部３４、及び、経路案内部３５は、図４に示したＣＰＵ２１１がプログラム２１０２を実行して端末２２のハードウェアと協働することで実現される機能又は手段である。これらの機能の一部又は全てがＩＣなどのハードウェア回路により実現されてもよい。

【0045】

端末送受信部３３は、ナビゲーションサーバ２１に案内要求を送信したり、ナビゲーションサーバ２１からナビ画面や経路情報を受信したりする。案内要求受付部３４は、出発地又は現在地（以下、出発地（現在地）という）から目的地までの経路案内をナビゲーションサーバ２１に対し要求する。案内要求は、例えば以下のような情報を有している。

【0046】

「出発地（現在地）、及び、目的地など」
経路案内部３５は、ナビゲーションサーバ２１から送信されたナビ画面を表示装置２１３に表示したり、経路情報を用いて進路変更の手前などで目的地までの経路を案内する。経路情報は、例えば以下のような情報を有している。

【0047】

「出発地から目的地までの経路（リンクやノード）、進路変更する位置」
ナビゲーションサーバ２１はサーバ送受信部４１、方面路線データ蓄積部４２、経路検索部４３、及び、入り口判断部４４を有している。サーバ送受信部４１、方面路線データ蓄積部４２、経路検索部４３、及び、入り口判断部４４は、図４に示したＣＰＵ２１１がプログラム２１０１を実行してナビゲーションサーバ２１のハードウェアと協働することで実現される機能又は手段である。これらの機能の一部又は全てがＩＣなどのハードウェア回路により実現されてもよい。

【0048】

また、ナビゲーションサーバ２１は、方面路線データＤＢ４６と施設情報ＤＢ４７を有している。これらは、例えばナビゲーションサーバ２１の補助記憶装置２１７に構築されるが、ナビゲーションサーバ２１が直接有していなくてもよく、ナビゲーションサーバ２１がアクセス可能な場所にあればよい。

【0049】

なお、ナビゲーションサーバ２１は、一般に、地図を描画するための例えばベクトルデータやラスタデータを記憶した地図ＤＢ、ノードデータ及びリンクデータからなる道路ネットワークデータを記憶した道路ネットワークＤＢ、及び、歩行者が通行可能な歩道（横断歩道、歩道橋、建物内や公園内の通り抜け可能な歩行者用通路など）のノードデータ及びリンクデータを記憶した歩行者ネットワークＤＢを有している。しかしながら、図では便宜的に省略されている。

【0050】

サーバ送受信部４１は、端末（蓄積用）２２ａ及び端末（経路案内用）２２ｂと通信し、例えばプローブデータや案内要求を受信する。方面路線データ蓄積部４２は、施設情報ＤＢ４７を参照してプローブデータを方面路線データに加工し、方面路線データＤＢ４６に記憶させる。詳細は、図８，９にて説明する。なお、プローブデータは一次的に、バッファに記憶されるがこのバッファは図示が省略されている。

【0051】

経路検索部４３は、案内要求に基づき例えばダイクストラ法を用いて目的地までの経路を検索し、ナビ画面や経路情報を作成する。経路情報に駅１０やデパート、ショッピングモールなどの特定の施設が含まれている場合、経路検索部４３は、入り口判断部４４に入り口判断要求を出力する。なお、特定の施設か否かは例えば施設の属性に含まれている。入り口判断要求は例えば以下の情報を有している。

【0052】

「駅などの施設、施設に接近する接近方面、及び、利用する路線など」
なお、利用する路線は、施設がデパートやショッピングモールの場合は、施設内の店舗や化粧室などの位置情報となる。

【0053】

入り口判断部４４は、方面路線データＤＢ４６を参照して、ユーザの接近方面及び利用する路線に最適な入り口を経路検索部４３に返す。経路検索部４３は、施設情報ＤＢ４７を参照して最適な入り口情報の入り口を通過する経路情報を作成し、サーバ送受信部４１が経路情報を端末（経路案内用）２２ｂに送信する。

【0054】

＜＜施設情報ＤＢ＞＞
図６は、施設情報ＤＢ４７に記憶されている施設情報を模式的に示す図の一例である。施設情報ＤＢ４７には、各施設の入り口ごとに位置情報が登録されている。位置情報は例えば緯度・経度・標高であるが、最寄りの道路のリンク番号などで特定されていてもよい。また、高さを示す情報として標高ではなく入り口があるフロアの階数が含まれていてもよい。

【0055】

＜＜方面路線データＤＢ＞＞
図７は、方面路線データＤＢ４６に記憶されている方面路線データを模式的に示す図の一例である。図７（ａ）は入り口Ａの方面路線データを、図７（ｂ）は入り口Ｂの方面路線データをそれぞれ示している。方面路線データは、駅１０への接近方面と路線に路線利用者の数が対応づけられた構造となっている。例えば、入り口Ａでは、接近方面が「北」で利用した路線が「Ｉ」の路線利用者の数は"４０"であり、接近方面が「東」で利用した路線が「Ｉ」の路線利用者の数は"３０"である。

【0056】

図７では、入り口Ａと入り口Ｂだけが示されているが、図示するような方面路線データが各駅の入り口ごとに（好ましくは全ての入り口に対し）作成されている。このような方面路線データにより、ナビゲーションサーバ２１は利用される路線と接近方面に応じて最適な入り口を決定できる。例えば、接近方面が「北」で利用する路線が「Ｉ」のユーザに対しては、路線利用者の数が最も多い入り口Ｂを案内できる。

【0057】

なお、方面路線データには路線利用者の数でなく比率を登録してもよい。この場合、接近方面と路線の組み合わせに対し比率を取るべきなので、例えば入り口Ａの接近方面「北」・路線「Ｉ」の比率は以下のように算出される。
入り口Ａの比率＝４０／（入り口Ａの接近方面「北」・路線「Ｉ」の路線利用者の数＋入り口Ｂの接近方面「北」・路線「Ｉ」の路線利用者の数＋…）
方面路線データの蓄積期間は、十分に大きい路線利用者の数が蓄積される期間を満たせば短い期間の方が好ましい。このような期間は施設ごとに異なると考えられるが、接近方面と路線の組み合わせに対し閾値以上の路線利用者の数の蓄積が得られる期間を実験的に定めることで決定できる。

【0058】

この期間が経過した古いデータを削除して新しいデータを蓄積することで、状況の変化に早期に対応できる。例えば、図２（ｃ）の入り口Ｂが工事により使用禁止となったものとする。まず、入り口Ｂが使用禁止になった日から方面路線データに入り口Ｃを使用する路線利用者の数が増大して蓄積されはじめる。蓄積される期間が短いほど入り口Ｂを利用した路線利用者の記録が早期に削除され、入り口Ｃの路線利用者の数が早期に最も大きくなるので、入り口Ｃをユーザに案内しやすくなる。

【0059】

＜方面路線データの蓄積＞
図８、９を用いて、方面路線データの蓄積について説明する。図８は、方面路線データの蓄積を模式的に説明する図の一例である。路線利用者１〜３が路線を利用するまでのプローブデータがすでにナビゲーションサーバ２１に送信されているものとする。路線利用者１は北から接近し入り口Ｂを通過して路線Ｉを利用し、路線利用者２は北から接近し入り口Ｂを通過して路線IIを利用した。路線利用者３は東から接近し入り口Ｂを通過して路線Iを利用した。

【0060】

この場合、方面路線データ蓄積部４２は、図９のようなプローブデータを参照して、方面路線データを蓄積する。図９は路線利用者１のプローブデータを模式的に示す図の一例である。路線利用者１の端末（蓄積用）２２ａが検出した位置情報と速度が時系列に登録されている。なお、速度は、端末（蓄積用）２２ａの加速度センサなどから算出されたものであり本実施形態では用いなくてもよい。

【0061】

プローブデータを方面路線データに加工する手順を説明する。
(i)方面路線データ蓄積部４２は、プローブデータの位置情報と一致したとみなせる施設情報ＤＢ４７の施設の入り口１１を検索し、適合した入り口１１が対応づけられている駅１０を特定する。
(ii)また、検索に適合した入り口１１を路線利用者が通過したと判断する。
(iii)入り口１１を通過する前に路線利用者が駅１０に接近した方向を判断するため、入り口を通過する前の位置情報に基づき、接近方面を判断する。例えば、時系列の位置情報を直線に近似してその傾きを、接近方面（８方向：東西南北、東南、南西、北西、北東のいずれか）に分類する。また、本実施形態では接近方面を東西南北に分類しているが、路線利用者は歩行してくるので歩行した道路を判別してもよい。この場合、方面路線データＤＢ４６には歩行した道路（例えばリンク番号）と路線の組み合わせの数が蓄積される。接近方向（東西南北）や路線利用者が歩行した道路は、駅１０に対する路線利用者の相対位置と表現できる。
(iv)次に、方面路線データ蓄積部４２は路線利用者が路線を利用したか否か、利用した場合はどの路線を利用したかを判断する。すなわち、入り口を通過した後の位置情報を監視し、駅１０の別の入り口を出て移動したと判断される場合は、路線を利用しなかったと判断する。また、入り口を通過した後の位置情報が別の駅又は別の駅の入り口の位置と一致したと見なせる場合、路線利用者は別の駅まで路線で移動したと判断する。方面路線データ蓄積部４２は２つの駅を結ぶ路線を路線図などから判断する。

【0062】

このようにして、方面路線データ蓄積部４２は、路線利用者が使用した駅、入り口、接近方面、及び、路線を判断して、方面路線データを蓄積する。

【0063】

なお、路線利用者が目的地までの経路を検索している場合、ナビゲーションサーバ２１が端末（蓄積用）２２ａに送信した経路情報を一部に利用して方面路線データを蓄積してもよい。すなわち、経路情報には、経路の一部となる駅、入り口及び路線、が含まれており、経路の検索のために使用された出発地（現在地）も既知である。したがって、駅と路線は経路情報から判断できる。実際に路線利用者が通過した入り口は上記(i)と同様に決定できる。接近方面は、出発地（現在地）と、プローブデータのうち入り口と判断された位置情報とを直線で結ぶことなどにより判断できる。

【0064】

このようにして、路線利用者１〜３が利用する駅、入り口、接近方面、及び、路線を判断した方面路線データ蓄積部４２は、図８に示すように、方面路線データを１つずつ計数していく。路線利用者１について、入り口Ｂの接近方面「北」と路線「Ｉ」の組み合わせに対し"１"を加算する。また、路線利用者２について、入り口Ｂの接近方面「北」と路線「II」の組み合わせに対し"１"を加算する。また、路線利用者３について、入り口Ｂの接近方面「東」と路線「I」の組み合わせに対し"１"を加算する。

【0065】

＜方面路線データを利用した入り口の判断＞
図１０を用いて、ユーザに最適な入り口の判断方法について説明する。図１０は、方面路線データを利用した入り口の判断方法を説明する図の一例である。入り口の判断に必要なのは、施設、接近方面及び路線である。

【0066】

ユーザは端末（経路案内用）２２ｂを操作して出発地（現在地）から目的地までの案内要求（出発地（現在地）及び目的地）をナビゲーションサーバ２１に送信する。

【0067】

経路検索部４３は案内要求を入り口判断要求（駅などの施設、施設に接近する接近方面、及び、利用する路線）に変換する。まず、経路検索により施設と路線を特定できる。次に、施設と出発地（現在地）から接近方面を特定できる。

【0068】

このようにして変換された入り口判断要求により、入り口判断部４４は方面路線データＤＢ４６を参照して、入り口を特定する。図１０に示すように、ユーザが駅１０に北から接近し、路線Ｉを使用する場合、入り口判断部４４はこの駅１０の各入り口の方面路線データを参照する。すると、入り口Ｂを利用するユーザが最も多いことが分かるので、入り口判断部４４は最適入り口情報として入り口Ｂを経路検索部４３に返す。したがって、ナビゲーションサーバ２１は、入り口Ｂを案内することができる。

【0069】

図１１は、端末（経路案内用）２２ｂの表示装置２１３に表示されたナビ画面の一例を示す図である。駅１０には３箇所の入り口Ａ〜Ｃが有り、ユーザの出発地（現在地）Ｓから入り口Ａまでの経路が強調表示されている。これにより、ユーザは路線Ｉ又は路線IIを使用する際に最適な入り口Ａから駅１０に進入できる。

【0070】

＜動作手順＞
図１２は、ナビゲーションサーバ２１が方面路線データを蓄積する手順を示すシーケンス図の一例である。
S1：端末（蓄積用）２２ａの位置情報取得部３２は例えば定期的に位置情報を取得して位置情報をプローブデータ送信部３１に送出する。
S2：プローブデータ送信部３１は位置情報に、時刻、速度及び端末２２の識別情報を加えることでプローブデータを作成する。
S3：プローブデータ送信部３１はプローブデータをナビゲーションサーバ２１のサーバ送受信部４１に送信する。
S4：サーバ送受信部４１はプローブデータを方面路線データ蓄積部４２に送出する。
S5：方面路線データ蓄積部４２は、施設情報ＤＢ４７を参照し施設と入り口を判断し、プローブデータの位置情報から接近方面、及び、路線を判断する。なお、方面路線データ蓄積部４２は、路線を判断できるまでプローブデータをバッファなどに保持しておく。
S6：方面路線データ蓄積部４２は、施設の入り口ごとに、接近方面と路線の組み合わせに対応づけられている数を１つ大きくすることで方面路線データＤＢ４６に方面路線データを蓄積する。

【0071】

図１３は、ナビゲーションサーバ２１が入り口を判断して経路情報を作成する手順を示すシーケンス図の一例である。
S1：端末（経路案内用）２２ｂの案内要求受付部３４は案内要求を受け付ける。
S2：案内要求受付部３４は案内要求を端末送受信部３３に送出する。
S3：端末送受信部３３は案内要求をナビゲーションサーバ２１に送信する。
S4：ナビゲーションサーバ２１のサーバ送受信部４１は案内要求を経路検索部４３に送出する。
S5：経路検索部４３は案内要求に基づいて経路検索すると共に、案内要求を入り口判断要求に変換し入り口判断部４４に送出する。
S6：入り口判断部４４は入り口判断要求に基づき方面路線データＤＢ４６を参照し最適な入り口を判断する。
S7：入り口判断部４４は判断した入り口を最適入り口情報として経路検索部４３に送出する。
S8：経路検索部４３は、出発地（現在地）→入り口→路線→目的地を経路とする経路情報及び出発地から目的地までのナビ画面を作成しサーバ送受信部４１に送出する。入り口の位置情報は施設情報ＤＢ４７に登録されている。
S9：サーバ送受信部４１は経路情報とナビ画面を端末（経路案内用）２２ｂに送信する。
S10：端末送受信部３３は経路情報とナビ画面を経路案内部３５に送出する。これにより、経路案内部３５はユーザに最適な入り口を含む経路を案内できる。

【0072】

以上説明したように、本実施形態の経路案内システム１００は、駅で利用可能な路線に複数の入り口から到達可能な場合に、適切な入り口を案内することができる。

【0073】

＜好適な変形例＞
本実施形態では、方面路線データにおいて、入り口ごとに接近方面と路線に対応づけて路線利用者の数が登録されていると説明した。しかしながら、図２（ｂ）にて説明したように路線が１つしかない場合は入り口ごとに路線利用者の数が登録されていれば、最適な入り口を案内できる。したがって、入り口ごとに路線利用者の数が登録された方面路線データを作成してもよい。

【0074】

また、駅に路線が複数ある場合は、利用された路線に対応づけて入り口を利用した路線利用者の数が登録されていてもよく、接近方面と路線に対応づけて路線利用者の数が登録されていなくてもよい。路線利用者が極端に遠回りして（例えば、北から接近して南に回り込む）入り口を選択することは希であり、自分の接近方向に近い範囲で都合のよい入り口を選択すると考えられる。したがって、接近方面がわからなくても路線利用者が利用する入り口を蓄積すれば、利用する路線に最適な入り口を特定できる。

【0075】

しかしながら、接近方面と路線に対応づけて路線利用者の数を蓄積することで、ユーザにより合理的な入り口を案内できる。

【0076】

＜＜駅以外の施設の一例＞＞
本実施形態では主に施設が駅１０であるとして説明したが、本実施形態の経路案内システム１００は、複数の入り口を有し利用可能な対象（駅の場合は路線）を有している施設の入り口を案内する場合に好適に適用できる。

【0077】

図１４は施設がデパートやショッピングモールの場合の方面路線データの一例を示す。図１４の方面路線データは方面店舗データと称してもよい。図１４の方面路線データでは、店舗利用者の接近方面と店舗利用者が利用した店舗の組み合わせに対し店舗利用者の数が登録されている。

【0078】

図１４の方面路線データの蓄積において利用された店舗はプローブデータに含まれる位置情報と滞在時間から判断できるし、又は、店舗に置かれたＢＬＥ端末が発信するビーコンから判断してもよい。

【0079】

方面路線データの蓄積後は、ユーザが出発地（現在地）から目的の店舗までの経路の案内要求をナビゲーションサーバ２１に送信することで、ナビゲーションサーバ２１は最適な入り口を案内できる。

【0080】

また、駅１０やデパート、ショッピングモール以外の施設として空港が挙げられる。空港では降車ホームや駐車場が複数ある場合があり、空港の場合、入り口は例えば路線利用者が空港までの移動に利用した列車などの降車ホームや空港までの移動に利用した車の駐車場が相当する。また、路線は利用する航空会社が相当する。すなわち、利用する航空会社に最適な降車ホームや駐車場を利用する空港利用者の数を蓄積しておくことで、空港をあまり利用しないユーザに対し航空会社に最適な降車ホームや駐車場を案内できる。

【0081】

＜＜時間帯別の方面路線データの蓄積＞＞
図１５は、時間帯別に蓄積された方面路線データの一例を示す図である。なお、北以外の方面路線データは省略されている。図１５（ａ）は入り口Ａについて北から接近し路線Ｉを利用した路線利用者の数が時間帯別に蓄積されている。図１５（ｂ）では入り口Ｂについて北から接近し路線Ｉを利用した路線利用者の数が時間帯別に蓄積されている。なお、プローブデータには時刻が含まれているため、時間帯別の方面路線データの蓄積は容易である。どのくらいの時間間隔で方面路線データの蓄積を蓄積するかは任意である。

【0082】

このような方面路線データが蓄積されている場合、ナビゲーションサーバ２１は端末（経路案内用）２２ｂを使用するユーザが入り口を使用する時刻に応じた時間帯別の路線利用者の数を参照する。入り口を使用する時刻は、入り口に到達すると予想される時刻であることが好ましいが、ユーザが入力した時刻や案内要求を送信した時刻でもよい。

【0083】

例えば、ユーザが入り口を使用する時刻が６〜７時の間の場合、入り口Ａの路線利用者の数は"１０"であり、入り口Ｂの路線利用者の数は"０"である。したがって、ナビゲーションサーバ２１は入り口Ａをユーザに案内する。これに対し、ユーザが入り口を使用する時刻が７〜９時の間の場合、入り口Ａの路線利用者の数は"７０"であり、入り口Ｂの路線利用者の数は"１３０"である。したがって、ナビゲーションサーバ２１は入り口Ｂをユーザに案内する。

【0084】

入り口Ｂの路線利用者の数が"０"であることはその時間帯は入り口Ｂが閉鎖されている可能性が高いので、開放されている入り口Ａを案内できる。このように施設に複数の入り口が設けられている場合、常に全ての入り口が開放されているとは限らないが、本実施形態によれば入り口に到達する時間帯で開放されている入り口のみを案内できる。

【0085】

また、平日や祝祭日を区別して、方面路線データを蓄積することも好適である。平日と祝祭日では路線利用者の移動経路が異なることは少なくなく、入り口の開放時間が異なることも有り得るので、時間帯別に方面路線データを蓄積する場合は、きめ細かな案内が可能になる。

【0086】

また、最寄り駅で大きなイベントが開催される場合にだけ、開放される入り口もあり得るため、イベントの開催の有無を区別して方面路線データを蓄積してもよい。このようなイベントとしては、スポーツの試合、コンサート、花火大会、などがある。

【0087】

さらに、天候を区別して方面路線データを蓄積してもよい。例えば、雨の場合、路線利用者は時間に有利な入り口を利用するよりも雨に濡れない経路につながる入り口を利用する場合がある。また、真夏や真冬の場合、路線利用者は時間に有利な入り口を利用するよりも日射や外気を避けられる経路につながる入り口を利用する場合がある。したがって、天候や気温を区別して方面路線データを蓄積することで、ユーザに天候や気温に最適な入り口を案内できる。

【0088】

なお、雨が降っているかどうかや気温は気象情報（例えば気象サーバが提供する）を利用する。そして、平日用、祝祭日用、イベント用のそれぞれについて雨用、真夏日用、真冬日用の方面路線データを蓄積する。

【0089】

＜＜路線利用者の属性別の方面路線データの蓄積＞＞
また、路線利用者の属性別に方面路線データを蓄積してもよい。路線利用者の属性とは、例えば、年齢、性別、職業などである。路線利用者の属性別に方面路線データを蓄積すれば、例えば、高齢者に対しエレベータを利用可能な入り口を案内でき、女性には化粧品などの売り場を通る入り口を案内でき、会社員には時間的に有利な入口を案内できる。

【0090】

＜＜改札口を利用した方面路線データの蓄積＞＞
これまで説明したように本実施形態では最適な入り口を案内しているが、入り口に加え改札口１２を案内してもよい。これは路線利用者が通過した改札口１２を特定できれば実現可能である。図１６を参照して説明する。図１６は駅の入り口、改札口、及び、路線の関係を模式的に示す図の一例である。

【0091】

改札口１２を特定しない場合、例えば、入り口Ａを通過して路線Ｉを使用する路線利用者の数と入り口Ｃを通過して路線Ｉを使用する路線利用者の数とに有意な差が存在しなかったものとする。

【0092】

これに対し、入り口Ａと改札口Ａを通過して路線Ｉを使用する路線利用者の数、入り口Ａと改札口Ｄを通過して路線Ｉを使用する路線利用者の数、入り口Ｃと改札口Ａを通過して路線Ｉを使用する路線利用者の数、及び、入り口Ｃと改札口Ｄを通過して路線Ｉを使用する路線利用者の数に有意な差が有れば、ナビゲーションサーバ２１は最適な入り口と改札口へ案内できる。

【0093】

＜＜その他の変形例＞＞
以上、本発明を実施するための最良の形態について実施例を用いて説明したが、本発明はこうした実施例に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。

【0094】

例えば、図３では一台のナビゲーションサーバ２１を図示したが、ナビゲーションサーバ２１は複数台、存在してもよい。また、１台のナビゲーションサーバ２１が有する機能が複数のサーバに分散して配置されてもよい。例えば、方面路線データ蓄積部４２をサーバＡに、経路検索部４３及び入り口判断部４４をサーバＢにそれぞれ配置することができる。

【0095】

また、ナビゲーションサーバ２１の機能を端末側が有することもできる。例えば、方面路線データＤＢ４６が作成された後は、端末（経路案内用）２２ｂが経路検索部４３と入り口判断部４４を有していてもよい。この場合、方面路線データＤＢ４６は端末が保持してもよいし、ネットワーク１３上に存在してもよい。

【符号の説明】

【0096】

１０ 駅
１１ 入り口
１２ 改札口
２１ ナビゲーションサーバ
２２ 端末
１００ 経路案内システム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】