特許 6410596 情報処理装置、プログラム

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

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

(11)【特許番号】6410596

(24)【登録日】2018年10月5日

(45)【発行日】2018年10月24日

(54)【発明の名称】情報処理装置、プログラム

(51)【国際特許分類】

   G01C 21/28 20060101AFI20181015BHJP

   G01C 21/26 20060101ALI20181015BHJP

   G08G 1/005 20060101ALI20181015BHJP

   G09B 29/10 20060101ALN20181015BHJP

【ＦＩ】

   G01C21/28

   G01C21/26 P

   G08G1/005

   !G09B29/10 A

【請求項の数】8

【全頁数】19

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

(22)【出願日】2014年12月25日

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

(43)【公開日】2016年7月7日

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

(73)【特許権者】

【識別番号】500578216

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

(74)【代理人】

【識別番号】100107766

【弁理士】

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

(74)【代理人】

【識別番号】100070150

【弁理士】

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

(72)【発明者】

【氏名】西岡 伸朗

(72)【発明者】

【氏名】平嶋 昭裕

(72)【発明者】

【氏名】筒井 由季

【審査官】 大内 俊彦

(56)【参考文献】

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

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

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

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

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

Ｇ０８Ｇ １／００５

Ｇ０９Ｂ ２９／１０

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

【請求項1】

歩行者の歩幅を用いて歩行者の位置を推定する情報処理装置であって、
歩行者の第１の位置情報を推定する位置情報推定手段と、
前記第１の位置情報により歩行者が存在する道路が第１の道路から第２の道路に変わり、第１の道路と第２の道路のなす角が閾値以上の場合、歩行者が進路変更したと判定し、
歩行者が進路変更してから所定距離内であって、第１の道路と第２の道路を接続するノードを含まない前記第２の道路における位置を、歩幅を学習するための学習ポイントに決定する学習ポイント決定手段と、を有することを特徴とする情報処理装置。

【請求項2】

前記第１の位置情報を道路上の第２の位置情報に補正する補正手段を有し、
前記学習ポイント決定手段は、前記第２の位置情報が存在する道路が第１の道路から第２の道路に変わり、第１の道路と第２の道路のなす角が閾値以上の場合、歩行者が進路変更したと判断する、ことを特徴とする請求項１に記載の情報処理装置。

【請求項3】

目的地までのルートを示す経路情報を取得した場合、前記補正手段は、前記第１の位置情報をルート上の第３の位置情報に補正し、
前記学習ポイント決定手段は、前記第３の位置情報が存在する道路がルート内の第１の道路からルート内の第２の道路に変わり、第１の道路と第２の道路のなす角が閾値以上の場合、歩行者が進路変更したと判断する、ことを特徴とする請求項２に記載の情報処理装置。

【請求項4】

前記学習ポイント決定手段は、歩行者が進路変更した直後を学習ポイントに決定する、ことを特徴とする請求項１〜３のいずれか１項に記載の情報処理装置。

【請求項5】

前記学習ポイント決定手段は、前記学習ポイントを決定した場合、直前の前記学習ポイントから今回の前記学習ポイントまでの距離を算出して歩幅学習部に出力すると共に、該歩幅学習部に対し前記距離と２つの学習ポイント間の歩数により歩幅を学習させる、ことを特徴とする請求項１〜４のいずれか１項に記載の情報処理装置。

【請求項6】

前記位置情報推定手段は、衛星からの電波を利用した測位により前記第１の位置情報を検出することができない場合に、歩行者の歩幅を用いて歩行者の前記第１の位置情報を推定するものであり、
前記補正手段が前記第１の位置情報を道路上の位置に補正して得られた前記第２の位置情報、又は、前記補正手段が前記第１の位置情報をルート上の位置に補正して得られた前記第３の位置情報を地図内に表示する表示手段を、有することを特徴とする請求項３に記載の情報処理装置。

【請求項7】

歩行者の歩幅を用いて歩行者の位置を推定する情報処理装置であって、
歩行者の第１の位置情報を推定する位置情報推定手段と、
前記第１の位置情報により歩行者が存在する道路が第１の道路から第２の道路に変わり、第１の道路と第２の道路のなす角が閾値以上の場合、歩行者が進路変更したと判定し、
歩行者が進路変更してから所定距離内であって、第１の道路と第２の道路を接続するノードを含まない前記第２の道路における位置を、歩行者の歩幅を学習するための学習ポイントに決定する学習ポイント決定手段と、
前記学習ポイントであるという指示を受けて、２つの前記学習ポイントの間の距離と歩数により歩幅を学習する歩幅学習手段と、を有することを特徴とする情報処理装置。

【請求項8】

歩行者の歩幅を用いて歩行者の位置を推定する情報処理装置に、
歩行者の第１の位置情報を推定する位置情報推定ステップと、
前記第１の位置情報により歩行者が存在する道路が第１の道路から第２の道路に変わり、第１の道路と第２の道路のなす角が閾値以上の場合、歩行者が進路変更したと判定し、
歩行者が進路変更してから所定距離内であって、第１の道路と第２の道路を接続するノードを含まない前記第２の道路における位置を、学習ポイントに決定する学習ポイント決定ステップ、
を実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、歩行者の歩幅を学習するための学習ポイントを決定する情報処理装置に関する。

【背景技術】

【0002】

従来から車載されたナビゲーション装置が知られているが、スマートフォンなどの可搬型の端末の普及に伴い端末にナビゲーション用のアプリケーションソフトウェアを実行させナビゲーション装置として機能させることができるようになった。このため、端末を自動車に搭載してカーナビゲーション装置として用いるだけでなく、端末を徒歩で移動する場合の歩行者用ナビゲーション装置として用いることが可能になっている。また、出発地から目的地まで、電車、飛行機、クルマ、バス、徒歩などの様々な交通手段の最適な組み合わせを提案する経路案内システムも実用化されている。したがって、徒歩による移動時にも適切なタイミングで次の進行方向を指示することなどが要請される。

【0003】

例えば、経路案内する場合、ナビゲーション装置はユーザが進行方向を変更する少し手前で次の進行方向を指示するが、ユーザの現在位置を正確に検出していないとこのタイミングを誤ることになる。経路案内しない場合でも、ユーザの現在位置と地図上のユーザの位置が大きく異なることは好ましくない。

【0004】

ナビゲーション装置がＧＮＳＳ（Global Navigation Satellite System）を利用できる状況では、ユーザの現在位置はある誤差範囲で検出されるため比較的正確な現在位置を検出可能である。しかし、ナビゲーション装置がＧＮＳＳを利用できない状況では、自律航法により現在位置を推定するため、現在位置を正確に検出できるとは限らない。

【0005】

そこで、従来から自律航法による移動時に現在位置の精度を向上させる技術が考案されている（例えば、特許文献１参照。）。特許文献１には、ＧＰＳによる測位再開地点の位置データと、ＧＰＳ測位が再開された時点での自律航法により測位された位置データとの差異量が所定値よりも大きい場合に、自律航法による移動経路の経路長とＧＰＳによる移動経路の経路長に基づいて、自律航法による移動経路の各地点の位置データを補正する測位装置が開示されている。

【先行技術文献】

【特許文献】

【0006】

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

【発明の概要】

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

【0007】

しかしながら、特許文献１に記載された測位装置では、ＧＰＳ衛星の電波を補足できるまでは自律航法による位置データを補正できないという不都合がある。

【0008】

このため、ＧＰＳ衛星の電波を補足できない状態でも、自律航法により検出される現在位置を補正する方法として、距離が既知の２点間を歩行者が移動したことを利用する方法が検討される。

【0009】

図１は、距離が既知の２点間を歩行者が移動したことを利用した自律航法の位置の補正について説明する図の一例である。端末２２は歩行者の推定位置を送出するセンサー部１２とセンサー部１２が送出する推定位置を利用するアプリ１１とを有している。

【0010】

図１（ａ）に示すように、アプリ１１は端末２２のユーザの歩幅の初期値（平均的な値やユーザが設定した値）を保持しており、センサー部１２にこの歩幅を与えておく。センサー部１２の現在地推定部４７は振動などから歩行を検知して直前の位置から歩幅だけ離れた位置を推定しアプリ１１に推定位置を通知する。アプリ１１は地図上にユーザの位置を表示できる。

【0011】

したがって、歩幅が正確でないとセンサー部１２が推定する推定位置も正確でなくなるおそれがある。そこで、図１（ｂ）に示すように、センサー部１２は歩幅を学習する機能として歩幅学習部４８を有している。歩幅学習部４８は、アプリ１１から学習ポイントであるという指示と２点間の距離（直前の学習ポイントと今回の学習ポイントの距離）を取得してユーザの歩幅を学習する。

【0012】

歩幅学習部４８は、直前の学習ポイントから今回指示された学習ポイントまでの歩数をカウントしているので、下式によりこのユーザの歩幅を学習することができる。

【0013】

歩幅＝２点間の距離／歩数
現在地推定部４７は、この歩幅を用いて推定位置を推定するので、より正確な推定位置をアプリ１１に送出できるようになる。

【0014】

ここで、アプリ１１は通常、センサー部１２が推定する推定位置をマップマッチング又はルートマッチングして得られた現在地を地図の道路上に補正する。したがって、学習ポイントとしては、２点間の距離が知られている交差点を利用でき、さらにルート検索済みであれば（ルートマッチングしている場合は）ルート上の曲がり角を利用することができる。ルート上の曲がり角はユーザが進路方向を変更する場所なのでその付近で推定位置が推定される可能性が高く、センサー部１２が誤った学習をする可能性が低いためである。しかしながら、ルート上の曲がり角を学習ポイントとして決定することには以下のような不都合がある。

【0015】

図２は、曲がり角を学習ポイントとする場合の不都合を説明する図の一例である。図２で使用されているマークは以下のとおりである。
実線の矢印…ルート検索された目的地までのルートｃ１
破線の矢印…距離学習範囲ｃ２
△…センサー部１２が推定する推定位置ｅ１〜ｅ１５
○…ルートマッチング後の現在地ｒ１〜ｒ１５
★…学習ポイント（ルート上の曲がり角）Ｐ１，Ｐ２
アプリ１１は、△で示す推定位置ｅ１〜ｅ１５をルートマッチングによりルート上に補正する（引き込む）。一般に、推定位置ｅ１〜ｅ１５との距離が最も短いルート上に補正する。補正後の位置が現在地ｒ１〜ｒ１５である。

【0016】

このような補正の結果、現在地（図では現在地ｒ４）が学習ポイントＰ１と一致すると、アプリ１１は学習ポイントであると判断し、２点間の距離（出発地から曲がり角までの距離、又は、曲がり角から次の曲がり角までの距離）をセンサー部１２に通知する。しかしながら、曲がり角を学習ポイントとすることは必ずしも適切でない場合がある。

【0017】

これは、推定位置ｅ１〜ｅ１５（図では推定位置ｅ４）から最も近いルート上の位置が曲がり角と一致することは希であるため、ユーザがルート上の曲がり角に最も接近したタイミングを学習ポイントに決定することが困難なためである。

【0018】

推定位置ｅ１〜ｅ１５がルート上の曲がり角とある程度接近したら、曲がり角と一致したとみなしてもよい。しかし、この場合、ユーザの実際の位置が学習ポイントからかなり離れていたり、センサー部１２が検出した歩数が実際の歩数と大きく異なっている可能性があったりするため、学習する歩幅が正確にならないおそれがある。

【0019】

したがって、距離が既知の２点間を移動したことを利用して歩幅を学習する場合、学習ポイントを曲がり角とすると、必ずしも学習される歩幅が正確でないという問題があった。

【0020】

本発明は、上記課題に鑑み、歩幅の学習精度が向上された情報処理装置を提供することを目的とする。

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

【0021】

上記課題に鑑み、本発明は、歩行者の歩幅を用いて歩行者の位置を推定する情報処理装置であって、歩行者の第１の位置情報を推定する位置情報推定手段と、前記第１の位置情報により歩行者が存在する道路が第１の道路から第２の道路に変わり、第１の道路と第２の道路のなす角が閾値以上の場合、歩行者が進路変更したと判定し、歩行者が進路変更してから所定距離内であって、第１の道路と第２の道路を接続するノードを含まない前記第２の道路における位置を、歩幅を学習するための学習ポイントに決定する学習ポイント決定手段と、を有することを特徴とする。

【発明の効果】

【0022】

歩幅の学習精度が向上された情報処理装置を提供することができる。

【図面の簡単な説明】

【0023】

【図1】距離が既知の２点間を歩行者が移動したことを利用した自律航法の位置の補正について説明する図の一例である。

【図2】曲がり角を学習ポイントとする場合の不都合を説明する図の一例である。

【図3】本実施形態における学習ポイントの一例を示す図である。

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

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

【図6】経路案内システムが備える各機能を図示した機能ブロック図の一例である。

【図7】ルートマッチングについて説明する図の一例である。

【図8】ユーザが曲がった先を学習ポイントとする場合の学習ポイントの決定を模式的に示す図の一例である。

【図9】センサー部がカウントする歩数と学習ポイントの対応を示す図の一例である。

【図10】端末の動作手順を示すフローチャート図の一例である。

【図11】ルートマッチング及びマップマッチングが行われない場合の学習ポイントの決定を模式的に示す図の一例である。

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

【0024】

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

【0025】

＜本実施形態の概略的特徴＞
図３は、本実施形態における学習ポイントの一例を示す図である。本実施形態のアプリ１１は、ユーザが交差点を曲がった直後を学習ポイントに決定することが特徴の１つとなる。ルートマッチングしている場合、ルートマッチングにより得られた現在地はルートとほぼ一致するので、ルートに沿ってユーザが交差点を曲がったことを精度よく検出できる。また、ユーザが実際に交差点を曲がった直後なら曲がってからの移動距離が短いので、既知の２点間の距離（直前の学習ポイントから今回の学習ポイントまでの距離）とユーザが実際に移動した距離が近い状態であると推定できる。したがって、センサー部１２はユーザの歩幅を精度よく学習できる。

【0026】

＜本実施形態で用いられる用語について＞
ルートマッチングとは、センサー部が推定した推定位置から最も近いルート上の位置（推定位置からルートに下ろした垂線との交点）が現在地であると推定することである。

【0027】

マップマッチングとは、推定位置から最も近いリンク上の位置（推定位置からリンクに下ろした垂線との交点）が現在地であると推定することである。

【0028】

本実施形態の交差点とは、少なくとも２つ道路が交差すればよく、三つ叉路（Ｔ字路・Ｙ字路）、４〜７叉路などを含む。したがって、ユーザが曲がる角度は交差点の形状に応じたものであり９０度とは限らない。

【0029】

ユーザが曲がるとはルートや道路形状に沿って進路変更することを言う。ただし、ルートや道路形状に沿っていることが検知されているか否かは問われない。

【0030】

ユーザが移動するために脚を一歩前に出すことを「歩行」するという。

【0031】

＜システムなどの構成例＞
図４は、本実施形態にかかる経路案内システム１００のシステム構成図の一例である。経路案内システム１００は、ネットワーク１３を介して接続されたナビゲーションサーバ２１及び端末２２を有している。ネットワーク１３は、インターネット、ＷＡＮやＬＡＮなどの主に有線で構築される通信網と、携帯電話網や無線ＬＡＮなどの主に無線で構築される通信網とを有している。有線のみ又は無線のみで構築されていてもよい。端末２２は無線で基地局１４やアクセスポイント１５にアクセスすることでネットワーク１３に接続する。

【0032】

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

【0033】

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

【0034】

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

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

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

【0040】

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

【0041】

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

【0042】

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

【0043】

＜経路案内システムの機能構成例＞
図６は、本実施形態の経路案内システム１００が備える各機能を図示した機能ブロック図の一例である。ナビゲーションサーバ２１は、サーバ送受信部３１、ナビ画面作成部３２、及び、ルート検索部３３を有している。サーバ送受信部３１、ナビ画面作成部３２、及び、ルート検索部３３は、図５に示したＣＰＵ２１１がプログラム２１０１を実行してナビゲーションサーバ２１のハードウェアと協働することで実現される機能又は手段である。これらの機能の一部又は全てがＩＣなどのハードウェア回路により実現されてもよい。

【0044】

また、ナビゲーションサーバ２１は、地図ＤＢ３４、道路ネットワークＤＢ３５、及び、歩行者ネットワークＤＢ３６を有している。これらは、例えばナビゲーションサーバ２１の補助記憶装置２１７に構築されるが、ナビゲーションサーバ２１が直接有していなくてもよく、ナビゲーションサーバ２１がアクセス可能な場所にあればよい。

【0045】

地図ＤＢ３４は、ナビ画面を描画するためのデータを記憶している。ナビ画面に表示される情報には、都道府県などの区画、緑地や河川、道路や鉄道、記号や注記など多くの表示対象があるため、性質の似たものに分類し各分類ごとに描画できるようになっている。それぞれに分類された表示対象又は表示対象が描画された状態をレイヤーといい、地図はいくつかのレイヤーを重ねることで描画される。各レイヤーの地図データは、ベクトルデータ又はラスターデータのうち表示対象に適したフォーマットで記述されている。また、地図データは経度・緯度などが既知のメッシュ状に区切られており、１つ以上のメッシュを結合してナビ画面が作成される。ベクトルベータの場合は、緯度・経度でポイント、ポリライン、ポリゴンの位置が定められている。また、ラスターデータの場合は緯度・経度に対応づけて縮尺に応じたデータが用意されている。

【0046】

道路ネットワークＤＢ３５は、車両が通行可能な道路の構造を表すデータであって、ノードテーブルとリンクテーブルとを有している。ノードテーブルには、緯度・経度に対応づけて道路網表現上の結節点が登録されている。結節点をノードという。ノードは例えば交差点、分岐点、合流点、屈曲点などである。リンクテーブルにはノードのノード番号に対応づけて車両が通行可能な道路が登録されている。車両が通行可能な道路は、一般道、高速道路、専用道路、私道などである。また、リンクテーブルには、リンク種別、幅員、リンク長などが登録されている。２つのノード間の道路をリンクといい、リンクはノード同士を結ぶ線分となる。

【0047】

歩行者ネットワークＤＢ３６は、ノードテーブルとリンクテーブルとを有する点で道路ネットワークＤＢ３５と同様である。ただし、歩行者ネットワークＤＢ３６には、歩行者が通行可能な道（歩道、横断歩道、歩道橋、地下道、通り抜け可能な通路など）のリンクと、リンクの始点と終点のノード等が登録されている。

【0048】

この他、様々な交通手段の最適な組み合わせを提案するナビゲーションでは、電車の路線図、バスの運行地図、飛行機の運航地図、及び、これらの時刻表が用いられるが、図では省略されている。

【0049】

サーバ送受信部３１は、端末２２からナビゲーションに関する種々の要求を受け付ける。この要求は、例えば目的地までの検索要求、ナビ画面の更新要求（拡大・縮小、表示範囲の変更など）などがある。これらの要求は、ナビ画面作成部３２とルート検索部３３に振り分けられる。

【0050】

ルート検索部３３は、検索要求に対し、道路ネットワークＤＢ３５又は歩行者ネットワークＤＢ３６の少なくとも一方を用いてルート検索し、経路情報を作成する。経路情報には、出発地から目的地までの経路を示すリンクやノード、進路変更するノード、ノードの位置情報、進路変更を案内する位置などが含まれている。

【0051】

本実施形態では主に歩行者ネットワークＤＢ３６が参照される。ルート検索には、リンク長や幅員をコストに換算して、出発地から目的地までのコストの合計が最も少なくなる経路を選ぶダイクストラ法が知られている。なお、ダイクストラ法以外の検索方法が用いられてもよい。また、ルート検索においては、有料道路の利用有無、地下道を優先するなどのユーザ設定が考慮される。

【0052】

ルート検索部３３は、検索して得られた出発地から目的地までの経路情報をナビ画面作成部３２に送出する。ナビ画面作成部３２は、出発地から目的地までの領域を含み、経路、出発地及び目的地が強調表示されたナビ画面を作成する。さらに、ユーザの現在位置を表示してもよい。また、ユーザが移動を開始すると、ナビ画面作成部３２は案内に適した縮尺のナビ画面を作成する。また、端末２２から更新要求を取得すると、ナビ画面作成部は要求された縮尺や表示範囲に応じてナビ画面を作成する。サーバ送受信部３１はこのようにして作成された経路情報とナビ画面を端末２２に送信する。

【0053】

端末２２は、端末送受信部４１、アプリ１１、及び、センサー部１２を有している。アプリ１１は操作受付部４２、ルート案内部４３、ナビ画面表示部４４、及び、学習ポイント決定部４５を有している。これらは、図５に示したＣＰＵ２１１がプログラム（アプリ１１）２１０２を実行して端末２２のハードウェアと協働することで実現される機能又は手段である。これらの機能の一部又は全てがＩＣなどのハードウェア回路により実現されてもよい。

【0054】

端末送受信部４１は、ナビゲーションサーバ２１に検索要求や更新要求を送信したり、ナビゲーションサーバ２１からナビ画面や経路情報を受信したりする。

【0055】

操作受付部４２は、ユーザから、出発地と目的地、拡大・縮尺、表示範囲変更などの操作入力を受け付ける。ナビ画面表示部４４は、表示装置２１３にナビ画面を表示する。また、センサー部１２から取得した推定位置をルート上に補正して（ルートマッチングして）、ユーザの現在地としてナビ画面に表示する。経路情報が検索されていない状態では、道路や道などユーザが存在するはずのリンク上に補正するマップマッチングを行う。なお、ルートマッチング又はマップマッチングはナビゲーションサーバ２１が行ってもよい。

【0056】

センサー部１２が送出する推定位置には、ＧＰＳ受信装置２１９が検出したものと自律航法により推定されたものとがある。本実施形態では主に自律航法により推定された推定位置が扱われる場合を説明する。

【0057】

ルート案内部４３は、ナビゲーションサーバ２１から取得した経路情報と、ルートマッチング又はマップマッチングにより得られた現在地とに基づいて、経路案内を行う。すなわち、ユーザの現在地が経路情報に含まれる進路変更すべき位置に到達すると、曲がり角などを指示する音声データを音声入出力装置２１８に出力させる。なお、音声データはナビゲーションサーバ２１から送信されてもよいし、端末２２が音声合成をおこなって作成してもよい。

【0058】

学習ポイント決定部４５は、学習ポイントであると判断すると学習ポイント指示情報をセンサー部１２に指示する。学習ポイント指示情報には以下の情報が含まれる。なお、詳しくは図８，９にて説明する。

【0059】

「現在地が学習ポイントであること、２点間の距離」
続いてセンサー部１２について説明する。センサー部１２は、アプリ１１とのインタフェースとなるＡＰＩ（Application Interface）５０、歩幅学習部４８、現在地推定部４７、及び、信号処理部４６を有している。歩幅学習部４８、現在地推定部４７、及び、信号処理部４６は、図５に示したＣＰＵ２１１がプログラム２１０２を実行して端末２２のハードウェアと協働することで実現される機能又は手段である。これらの機能の一部又は全てがＩＣなどのハードウェア回路により実現されてもよい。

【0060】

また、センサー部１２は歩幅記憶部４９を有している。歩幅記憶部４９はセンサー部１２内のフラッシュメモリなどに構築されてもよいし、端末２２の補助記憶装置２１７やＲＯＭ２１５に構築されてもよい。歩幅記憶部４９は、初期値としての歩幅、及び、過去に学習したいくつかの歩幅を記憶している。

【0061】

図示するように、センサー部１２とアプリ１１がＡＰＩ５０を介して分離されていることで、センサー部１２を異なるアプリ１１で共有したり、センサー部１２とアプリ１１の開発を別々に行ったり、センサー部１２が変わってもアプリ１１の修正を最小限にできたりすると言うメリットがある。しかしながら、図示する構成は一例であり、アプリ１１とセンサー部１２が一体であってもよい。

【0062】

信号処理部４６は加速度センサー５１、ジャイロセンサー５２、及び、ＧＰＳ受信装置２１９と接続されている。加速度センサー５１は例えばＸＹＺ軸の３方向の加速度を検出するセンサーで、ジャイロセンサー５２はＸＹ平面、ＹＺ平面、ＺＸ平面に水平な面における角速度をそれぞれ検出するセンサーである。なお、軸数や軸の向きは一例であって、ユーザの歩行の有無や進行方向を検出できればよい。また、端末２２が有するセンサーの種類は一例である。

【0063】

信号処理部４６は、加速度センサー５１、ジャイロセンサー５２、及び、ＧＰＳ受信装置２１９の信号を処理して現在地推定部４７に送出する。ＧＰＳ受信装置２１９が４つ以上のＧＰＳ衛星を補足している場合には、ＧＰＳ受信装置２１９が検出した緯度・経度・標高の位置情報を現在地推定部４７に送出する。これに対し、ＧＰＳ受信装置２１９が十分な数のＧＰＳ衛星を補足できない場合には、加速度センサー５１とジャイロセンサー５２の信号を現在地推定部４７に出力する。

【0064】

現在地推定部４７は、加速度センサー５１とジャイロセンサー５２の信号を監視してユーザが歩行したことを検出する。例えば、加速度センサー５１の信号に基づいて、前後方向の加速度が所定時間以内に所定量以上変化すること、上下方向の加速度が所定値以上又は所定値未満になることなどから判断される。

【0065】

また、現在地推定部４７は、ジャイロセンサー５２の信号を監視してユーザの進行方向を検出する。ジャイロセンサー５２の信号は角速度なのでこれを積分することで角度に変換する。任意の基準方向（例えば、ルートに沿った方向、地磁気センサーにより求めた東西南北のいずれか）に対する角度の変化により進行方向が検出される。

【0066】

現在地推定部４７は、直前の現在地を基点として現在地を推定する。歩幅記憶部４９に記録されている歩幅を読み出して、直前の現在地に対し進行方向に歩幅だけ進んだ位置を現在地として推定する。推定された現在地はアプリ１１に送出される。

【0067】

歩幅学習部４８は、アプリ１１から学習ポイント指示情報を取得した場合、２点間の距離と２点間の距離を移動するための歩数を利用して歩幅を学習する。詳細は図８，９で説明する。

【0068】

＜ルートマッチング＞
本実施形態の学習ポイントの決定方法は、ルートマッチングが行われていなくても適用可能だが、ルートマッチングが行われることで正確な学習ポイントを決定しやすい。

【0069】

図７（ａ）は、ルートマッチングについて説明する図の一例である。ルートマッチングによりルートｃ１が得られている。そして、現在地推定部４７が推定した推定位置ｅ１〜ｅ３が現在地ｒ１〜ｒ３にルートマッチングされる。

【0070】

ここで、ルートマッチングの手順として、ナビ画面表示部４４はルートマッチングよりも先にマップマッチングを行う。これはアプリ１１のロジック上の理由（地図があるエリアではマップマッチングは常に行われている）によるものである。また、マップマッチングで現在地を補正した後にルートマッチングした方がより精度が高くなるためである。

【0071】

例えば、推定位置ｅ４は一度、マッピング位置ｍ４にマップマッチングされる。しかし、マッピング位置ｍ４はルート上でないので、再度、ルート上の現在地ｒ４にルートマッチングされる。マッピング位置ｍ４のままではユーザが交差点を曲がったと誤判定されるおそれがあるが、ルートマッチングすることで、曲がったか否かの判定精度を向上させることができる。

【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】

なす角が閾値以上である場合（Ｓ４０のＹｅｓ）、ユーザが曲がったと判断できるので、学習ポイント決定部４５は２点間の距離を算出する（Ｓ５０）。この距離は、前回、曲がったと判断された現在地から今回、曲がったと判断した現在地までの距離である。

【0097】

そして、学習ポイント決定部４５は学習ポイント指示情報をセンサー部１２に出力する（Ｓ６０）。この後、処理はステップＳ１０に戻る。

【0098】

ステップＳ３０又はＳ４０でＮｏと判断された場合、学習ポイント決定部４５はルート案内が終了したか否かを判定する（Ｓ７０）。ルート案内が終了していない場合（Ｓ７０のＮｏ）、処理はステップＳ１０に戻る。

【0099】

ルート案内が終了した場合（Ｓ７０のＹｅｓ）、図１０（ａ）の動作手順は終了する。

【0100】

図１０（ｂ）の動作手順は、例えば、アプリ１１がセンサー部１２に学習を指示するとスタートしてもよいし、常に、学習を行っていてもよい。

【0101】

センサー部１２の歩幅学習部４８は例えば、アプリ１１からの指示や学習ポイント指示情報を取得すると、歩数をゼロに初期化する（Ｓ１１０）。

【0102】

次に、現在地推定部４７が歩行したと判断したか否かを判定する（Ｓ１２０）。歩行していない場合（Ｓ１２０のＮｏ）、処理はステップＳ１７０に進む。

【0103】

歩行したと判断された場合（Ｓ１２０のＹｅｓ）、現在地推定部４７は推定位置を推定してアプリ１１に送出する（Ｓ１３０）。

【0104】

歩幅学習部４８は歩数を１つ大きくする（Ｓ１４０）。

【0105】

次に、アプリ１１に送出した推定位置に対し、歩幅学習部４８は学習ポイント指示情報を取得したか否かを判定する（Ｓ１５０）。学習ポイント指示情報を取得しない場合（Ｓ１５０のＮｏ）、ユーザは曲がっていないので処理はステップＳ１２０に戻る。

【0106】

学習ポイント指示情報を取得した場合（Ｓ１５０のＹｅｓ）、現在地が学習ポイントであるので、歩幅学習部４８は歩数で２点間の距離を除して歩幅を学習する（Ｓ１６０）。

【0107】

この後、処理はステップＳ１１０に戻り、センサー部１２は歩幅の学習を継続する。そして、ステップＳ１２０でＮｏと判定された場合、歩幅学習部４８は学習が終了したか否かを判定する（Ｓ１７０）。例えば、アプリ１１からの指示で歩幅を学習している場合は、アプリ１１からの指示で学習を終了させる。

【0108】

＜学習ポイントの決定 マップマッチングが行われている場合＞
ルートマッチングが行われておらず、マップマッチングのみが行われている場合もルートマッチングが行われている場合と同様に学習ポイントを決定できる。すなわち、ナビ画面表示部４４による推定位置の補正先がルート上でなくリンク上に変わるだけなので、曲がったか否かの判定もルートマッチングされる場合と同様でよい。

【0109】

なお、マップマッチングの場合は、ユーザが曲がっていなくても曲がったと誤判定されるおそれが高まるため、上記の条件ａ１の距離又はａ２の歩行の数をより大きな値とすることが好適である。

【0110】

＜学習ポイントの決定 ルートマッチング及びマップマッチングが行われない場合＞
マップマッチングさえ行われない場合は少ないと考えられる。また、ユーザの端末２２の持ち方などにより推定位置が安定しない場合には曲がったという判断が必ずしも正確でなく、歩幅の学習は困難になる。よって、歩幅の学習はルートマッチング又はマップマッチングが行われている場合に行うことが好ましい。しかしながら、推定位置の精度が十分に高い場合は、マップマッチングさえ行われない場合でも、歩幅の学習は可能である。

【0111】

図１１は、ルートマッチング及びマップマッチングが行われない場合の学習ポイントの決定を模式的に示す図の一例を示す。センサー部１２により出力される推定位置はほぼリンク上を移動している。このため、ユーザの現在位置をマップマッチングにより補正しなくてもリンクに沿って移動するとみなすことができる。

【0112】

ルートマッチング及びマップマッチングが行われない場合、現在のリンクが特定できないので、曲がったか否かは例えば以下のように、推定位置間の直線近似により判断する。
(i)学習ポイント決定部４５は、隣接した２つの推定位置を通過する直線を求める。これにより、出発地と推定位置ｅ１を結ぶ直線ｍ１、推定位置ｅ１とｅ２を結ぶ直線ｍ２、推定位置ｅ２とｅ３を結ぶ直線ｍ３、推定位置ｅ３とｅ４を結ぶ直線ｍ４、推定位置ｅ４とｅ５を結ぶ直線ｍ５が求められる。
(ii)最後に求めた直線とその前に求めた直線のなす角を算出する。すなわち、直線ｍ１とｍ２のなす角、直線ｍ２とｍ３のなす角、直線ｍ３とｍ４、直線ｍ４とｍ５のなす角が求められる。
(iii)なす角が閾値以上の場合、ユーザが曲がったと判断する。
(iv)学習ポイント指示情報は、２点間の距離を直線ｍ１〜ｍ５の合計値として作成する。

【0113】

このように、推定位置の精度が直線性を判断できる程度に十分であれば、ルートマッチング及びマップマッチングが行われない場合でも、ユーザが曲がった直後を学習ポイントとして判断できる。

【0114】

なお、自律航法は端末２２がＧＰＳ衛星を補足できない場合に行われるが、歩幅の学習はＧＰＳ衛星が補足されている状態で行ってもよい。ＧＰＳ衛星を補足している状態では、図１１に示すようなリンク上の測位点が得られやすいので、ルートマッチング及びマップマッチングが行われない場合でもユーザが曲がった直後を学習ポイントとして判断できる。当然ながら、ＧＰＳ衛星を補足しており、かつ、ルートマッチング又はマップマッチングが行われている状態で歩幅を学習してもよい。

【0115】

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

【0116】

例えば、本実施形態では端末２２が、ユーザが曲がったか否かの判断を端末２２が行っているが、ナビゲーションサーバ２１が判断してもよい。この場合、端末２２は推定位置又は現在地をナビゲーションサーバ２１に送信すればよい。また、センサー部１２が、ユーザが曲がったか否かの判断を行ってもよい。

【0117】

また、本実施形態ではセンサー部１２が歩幅を学習したが、アプリ１１が歩幅を学習してもよい。この場合、アプリ１１が学習ポイント間の歩数をカウントしてもよいし、センサー部１２から歩数を取得してもよい。

【0118】

また、歩幅の学習はナビゲーションサーバ２１が行ってもよい。この場合、端末２２が学習ポイントであること、２点間の距離、及び、歩数をナビゲーションサーバ２１に通知する。あるいは、ナビゲーションサーバ２１が推定位置又は現在地を取得して、学習ポイントであることを判断して２点間の距離を特定し、端末２２から歩数を取得してもよい。

【0119】

また、例えば、図４では一台のナビゲーションサーバ２１を図示したが、ナビゲーションサーバ２１は複数台、存在してもよい。また、１台のナビゲーションサーバ２１が有する機能が複数のサーバに分散して配置されてもよい。

【0120】

また、ナビゲーションサーバ２１の機能を端末２２側が有することもできる。例えば、端末２２がナビ画面作成部３２とルート検索部３３を有することができる。

【符号の説明】

【0121】

１１ アプリ
１２ センサー部
２１ ナビゲーションサーバ
２２ 端末
１００ 経路案内システム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】