サーバ装置及びナビゲーション方法
【課題】複数の移動体を早く確実に合流させるサーバ装置及びナビゲーション方法を提供する。
【解決手段】サーバ装置１と、各移動体のナビゲーション装置２とを、通信ネットワークである携帯電話網Ｋ及びインターネットＮで接続するナビゲーション方法である。サーバ装置１の送受信部１１は、各ナビゲーション装置２から前記通信ネットワーク経由で、ナビゲーション装置のグループを構成するものとして互いに関連付けられた識別情報と、ナビゲーション装置のそれぞれの位置とを受け取る。合流地点演算部１２は、受信した前記各位置に基づいて各移動体の合流地点を算出する。送受信部１１は、合流地点演算部１２が算出した前記合流地点のデータを、前記識別情報を有する前記各ナビゲーション装置２に送信する。
【解決手段】サーバ装置１と、各移動体のナビゲーション装置２とを、通信ネットワークである携帯電話網Ｋ及びインターネットＮで接続するナビゲーション方法である。サーバ装置１の送受信部１１は、各ナビゲーション装置２から前記通信ネットワーク経由で、ナビゲーション装置のグループを構成するものとして互いに関連付けられた識別情報と、ナビゲーション装置のそれぞれの位置とを受け取る。合流地点演算部１２は、受信した前記各位置に基づいて各移動体の合流地点を算出する。送受信部１１は、合流地点演算部１２が算出した前記合流地点のデータを、前記識別情報を有する前記各ナビゲーション装置２に送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の移動体を早く確実に合流させるサーバ装置及びナビゲーション方法に関するものである。
【背景技術】
【０００２】
近年、自動車とデジタル技術の普及に伴い、ナビゲーション装置などのナビゲーション技術が急速に進歩している。ナビゲーション装置は、まず、指定された目的地への最適な経路を予め用意した道路データに基づいて探索し、設定する。ナビゲーション装置は、その設定した最適な経路に自車を誘導するために、自車位置をリアルタイムに検出して周辺地図と一緒に画面表示しながら、各交差点における右左折等の誘導案内を車両の進行に応じて画面表示や合成音声などで出力するものであり、最近は、人が携帯して用いるタイプのナビゲーション装置も登場している。
【０００３】
ところで、自車以外の車や人と待ち合わせて合流しようとした場合は、当事者が電話等による直接対話で目的地を決め、片方の車だけが移動したり、ｉナビリンクなどの位置情報伝送機能搭載のカーナビゲーション装置を使い、一方の位置を他方に送信し、受信側の車だけが送られてきた位置に移動したりする手法が従来用いられてきた。また、お互いの位置情報を周期的に伝送し合うことにより、地図上に表示される相手の位置を見ながら合流する技術も知られていた。
【０００４】
しかしながら、片方だけが移動する場合は、他方はそのままの位置で待っていることになるため、時間が余計にかかり無駄も多くなる。さらに同様に複数台の車が一台の車の位置に合流する場合は、先に到着した車が、最も遠い車が到着するまで待たねばならず同様に無駄が多かった。また、互いに移動している当事者が地図上の相手を見ながら合流することは、よほど意志の疎通を徹底していないと行き違いが多く事実上困難であった。
【０００５】
そこで、複数の車両を迅速且つ容易に合流させるため、ナビゲーション装置に合流地点や合流地点までの経路を計算させる従来技術が提案された。そのように複数車両が迅速に合流するためのアルゴリズムとしては、次のようなものがあげられる。
【０００６】
特許文献１は、各出発地点から等しい距離又は所要時間の交差点を基準地点とし、そこから所定の距離や時間内にあるガソリンスタンドなどの待ち合わせ場所を検索するものである。特許文献２は、両車が同じ道路上の場合はその中間地点を合流地点としたり、両車が別の道路上の場合は、両車を結ぶ直線の中間地点に最寄の道路上に合流地点を設けるものである。特許文献３は、３台以上の場合に一番近い２台が所定の距離以上離れると警報を出し、待合せ場所を設定のうえ残りの車両へ通知し、そこに誘導させるものである。
【０００７】
【特許文献１】特開平１０−２８１７８２号公報
【特許文献２】特開２０００−８８５９１号公報
【特許文献３】特開２００１−１０８４６０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、上記のような従来技術を実際に実施しようとすると、各移動体で共通して全く同じアルゴリズムを適用することが事実上難しいという問題点が生じる。すなわち、ナビゲーションにおける経路探索等のアルゴリズムは日進月歩であって、各ナビゲーション装置間で、プログラムに基づく処理アルゴリズムの種類やバージョンが異なると、各車で探索結果が食い違って不適切な誘導の原因となる。
【０００９】
また、近年ではＧＰＳ装置の小型化や携帯電話端末との一体化も進み、合流する移動体の種類は、車両に限らず人や自転車など多様化している。例えば、人の場合、車での移動とは異なり、徒歩、鉄道、バスのように移動手段が限定される結果、移動できる場所が、現在地周辺や、駅、バス停等に限られるなど、移動体の種類によって条件が異なる。これに対し、従来はこのような合流する移動体の種類を考慮した技術は知られていなかった。
【００１０】
本発明は、上記のような従来技術の問題点を解決するために提案されたものであって、その目的は、複数の移動体を早く確実に合流させるナビゲーション方法を提供することであり、より具体的には、合流地点をサーバ装置で決めナビゲーション装置間でどのアルゴリズムを使うか伝達させることである。
【００１１】
また、本発明の他の目的は、合流しようとする移動体の種類に応じ合流地点の種類を選ぶナビゲーション方法を提供することである。
【００１２】
また、本発明の他の目的は、各種移動体の所要時間の平均化により、無駄な待ち時間や利用者間の不公平感を抑制するナビゲーション方法を提供することである。
【課題を解決するための手段】
【００１３】
上記の目的を達成するため、本発明のサーバ装置は、複数の各移動体に対応する各ナビゲーション装置から、通信ネットワーク経由で、前記ナビゲーション装置のグループを構成するものとして互いに関連付けられた識別情報と、前記ナビゲーション装置のそれぞれの位置と、を受け取る手段と、各移動体の種類に基づいて合流地点の種別を選択する手段と、受信した前記各位置に基づいて前記合流地点を算出する演算手段と、算出した前記合流地点のデータを、前記識別情報を有する前記各ナビゲーション装置に送信する手段と、をコンピュータが備えたことを特徴とする。
【００１４】
本発明の他の態様は、前記演算手段は、前記各位置からの各移動体の所要時間差が所定時間以内の地点を合流地点として算出するように構成されたことを特徴とする。
【００１５】
なお、前記の様な、複数の各移動体に対応する各ナビゲーション装置から通信ネットワーク経由で、グループを構成するものとして互いに関連付けられた識別情報と、それぞれの位置と、を受け取る手段と、各移動体の種類に基づいて合流地点の種別を選択する手段と、受信した前記各位置に基づいて前記合流地点を算出する演算手段と、算出した前記合流地点のデータを、前記識別情報を有する前記各ナビゲーション装置に送信する手段によるナビゲーション方法も、本発明の一態様である。
【発明の効果】
【００１６】
本発明によれば、合流地点をサーバ装置で決めナビゲーション装置間でどのアルゴリズムを使うか伝達させ、移動体の種類に応じ合流地点の種類を選ぶことにより、複数の移動体を早く確実に合流させるサーバ装置及びナビゲーション方法を提供することができる。
【発明を実施するための最良の形態】
【００１７】
次に、本発明に関する複数の実施の形態（以下それぞれ「実施形態」と呼ぶ）について図面を参照して具体的に説明する。なお、各実施形態は、コンピュータをプログラムで制御することにより実現できるが、この場合のハードウェアやプログラムの実現態様は各種変更可能であるから、以下の説明では、本発明及び各実施形態の各機能を実現する仮想的回路ブロックを用いる。
【００１８】
［１．第１実施形態］
第１実施形態は、合流地点算出をサーバ装置で行う例である。
［１−１．第１実施形態の構成］
第１実施形態は、図１に示すように、サーバ装置（単に「サーバ」とも呼ぶ）１と、車両等の各移動体に対応する各ナビゲーション装置２とを、通信ネットワークである携帯電話網Ｋ及びインターネットＮで接続したナビゲーションシステムである。
【００１９】
このうち、サーバ装置１は、コンピュータがプログラムに基いて、図１に示す次の要素を備えたものである。まず、送受信部１１は、合流しようとする複数の各移動体の種類及び位置の入力を受け付ける手段であり、より具体的には、各移動体のナビゲーション装置２から前記通信ネットワーク経由で、グループを構成するものとして互いに関連付けられた識別情報と、それぞれの位置と、を受け取る手段である。このようなグループごとの識別情報等のデータはグループデータ１６として格納される。
【００２０】
また、合流地点演算部１２は、受信した前記各位置に基づいて前記各移動体の合流地点を算出する演算手段である。また、経路探索部１４は、一又は二以上の前記合流地点までの各移動体の経路を、予め用意された道路データ１５に基いて探索する手段である。また、探索された各経路については所要時間が得られるが、前記合流地点演算部１２は、複数の合流地点の候補がある場合に、各候補地点までの前記各位置からの各移動体の所要時間差が所定時間以内の地点を合流地点として算出するように構成されている。
【００２１】
また、前記送受信部１１は、その移動体すなわち前記識別情報を有する前記各ナビゲーション装置２に、合流地点のデータ、すなわち合流地点及びそこまでのその移動体の経路を表すデータを、送信する手段でもある。また、種別選択部１３は、車又は人といった各移動体の種類に基づいて合流地点の種別を選択する手段である。
【００２２】
また、ナビゲーション装置２は、ＣＰＵ２１やメモリ２２を含むコンピュータがプログラムに基いて、図１に示す次の要素を備えたものである。まず、通信制御部２３は、携帯電話網Ｋに接続するための携帯電話端末２４を制御することにより、前記通信ネットワーク経由でサーバ装置１に対し、識別情報と位置情報とを送信する手段であり、また、サーバ装置１から返信される合流地点のデータを受信する手段でもある。また、経路誘導部２５は、受信した前記データに基いて、前記合流地点への経路誘導を行う手段である。なお、ナビゲーション装置２の側に、独自の経路探索部２６を設け、サーバ装置１では合流地点のみ決め、そこまでの経路は各ナビゲーション装置２側で個別に探索させるようにしてもよい。
【００２３】
［１−２．第１実施形態の作用］
上記のように構成された第１実施形態では、サーバ装置１において、望ましくは、合流地点に加えて、合流地点に至る各移動体のための誘導経路も探索する。
【００２４】
［１−２−１．合流探索の例］
まず、第１実施形態において、各移動体の位置から合流地点を計算する手法は、従来の技術の欄で例示したような従来公知のものを用いてよいが、ここで一例として、合流地点及び経路を探索する処理（以下「合流探索」と呼ぶこととする）の例を図２に、またその場合の処理手順を図３に示す。
【００２５】
すなわち、図２に示すように、Ａ車とＢ車という２台の車両の合流地点を計算する場合、Ａ車とＢ車の周辺もしくは中間地点にある目標物を、道路データ１５や施設のデータなど予め用意されたデータから検索する（ステップ０１）。すなわち、各車の合流地点は、理論的には各車の中間地点であるが、実際には何らかの目標物となる。実際の目標物の種類は自由であるが、例えばコンビニエンスストア（以下「コンビニ」と略称する）のように駐停車スペースがあって交通の妨げにならない場所が望ましい。
【００２６】
具体的には、目標物は、各車両に囲まれた範囲で、施設データなどに基くランドマークの検索により探索するが、より具体的には、待ち合わせに適した種類の場所の候補を各車両間のエリアで選択することである。但し、そのようなエリア内で適切なランドマークが発見できない場合は、最初に合流探索をかけた車両（例えばＡ車）を合流目的地としてもよい。
【００２７】
そして、候補として検索された各目標物を目的地として、各車の現在位置からのそれぞれの経路を、複数探索する（ステップ０２）。図２の例では、車が２台で目標物の候補がコンビニＶ１，Ｖ２，Ｖ３の３つであり、３組合計６個の経路を探索する。これら６つの経路は、図２において、破線矢印で示す経路ａ１とｂ１、一点鎖線矢印で示す経路ａ２とｂ２、実線矢印で示す経路ａ３とｂ３であり、ここでいう「ａ」「ｂ」はＡ車とＢ車をそれぞれ表し、「１」「２」「３」はそれぞれのコンビニＶ１，Ｖ２，Ｖ３への経路に対応する。
【００２８】
そして、この探索結果から、目標物毎に各車の到着予測時間を比べ、時間の差が最も少ない目標物、つまり予測到着所要時間がほぼ等しい探索経路を選択する（ステップ０３）。
【００２９】
つまり、地域によっては目標物が少ないため、各車両から等時間距離に目標物を設定できない場合も考えられ、この場合、最寄のある目標物を合流地点とすると、あるＡ車が先に到着し、別のＢ車はそれより遅れる事態も考えられる。そこで、前記各位置からの各移動体の所要時間差が所定時間までは許容範囲とし、その許容範囲以内の地点を合流地点として算出するが、原則としては、そのような所要時間差が最小の地点を合流地点とする。但し、これは望ましい例であり、最初から単一の合流地点及びそれへの経路を計算してもよい。
【００３０】
上記のような合流探索の前提として、グループとして行動する各車両の位置と合流探索要求がサーバ装置に通知されるが、各車両の位置を伴う合流探索要求をサーバ装置に伝えるには、以下のように、各車（のナビゲーション装置２）から要求するパターンと、代表する１台から要求するパターンとが考えられる。
【００３１】
［１−２−２．各車から要求する場合］
まず、図４は、各車から合流探索要求をサーバ装置１に送信する場合の処理手順を示す図である。この例では、Ａ車の通信制御部２３は、合流したい車（図の場合Ｂ車）に合流探索キーを生成して通信により渡す（ステップ１１，１２）。この「合流探索キー」は、同じグループであることをサーバ装置１で判断するための認識コードなどの識別情報であり、形式は自由である。
【００３２】
そして、各車の通信制御部２３はそれぞれ、自車位置と、上記の合流探索キーを合流探索要求としてサーバ装置１に送り（ステップ１３，１４）、サーバ装置１ではそれを元に、合流探索シーケンスを実行する（ステップ１５）。ここで、合流探索キーを発行したＡ車は、自車を含め何台に発行したか（グループ台数）もサーバ装置１へ送る（ステップ１３）。例えば、図２の場合、Ａ車の他１台、計２台に発行したことになる。
【００３３】
サーバ装置１では、あるグループの合流探索キーを送ってきた車両の台数がそのグループの台数になった時点で合流探索シーケンスを実行する（ステップ１５）。この合流探索シーケンスでは、概略的には、合流地点演算部１２が各車の合流地点を計算した上、その合流地点までの各車の誘導経路を経路探索部１４が計算するが、具体的には既に説明した通りである。そして、サーバ装置１の送受信部１１は、この合流探索シーケンスにて得られた最適な経路を表すデータ（誘導データと呼ぶ）をそれぞれの車に返信し、各車では、通信制御部２３で受信した誘導データに基いて、経路誘導部２５によりナビゲーションが開始される（ステップ１６，１７）。
【００３４】
［１−２−３．合流探索キーの役割］
ここで、図４で示した合流探索キーの役割を、図１を参照して説明する。すなわち、サーバ装置１には、合流探索キーによって探索結果が一時的に複数格納され、その中から最適な経路が選択される。また、一つの探索結果は各車毎の探索結果を含む。例えば、合流探索キーが「１０」で、これに対応する探索結果１０１，１０２，１０３がある場合、そのどれをとっても、Ａ車の経路とＢ車の経路とが含まれる。また、合流探索キーが「１５」の場合、探索結果１５１にも１５２にも、それぞれＸ車、Ｙ車、Ｚ車という３台分の経路が格納される。
【００３５】
［１−２−４．１台が要求する場合］
次に、図５は、合流探索要求を１台の車（ここではＡ車のみ）が行う場合の処理手順を示す図である。この場合、Ａ車以外の全車（ここではＢ車）が自車位置と自車ＩＤ及び自車アドレスを、通信制御部２３により通信でＡ車に送る（ステップ２１）。ここでいう自車「アドレス」は、例えば、外部から自車に対して誘導データ送信などの通信を行うためのメールアドレスやＩＰアドレスであり、この例では図４の場合と異なり、Ｂ車はサーバ装置１に合流探索要求を直接行わないため、サーバ装置１からＢ車に探索結果伝達のために用いる。アドレスの具体的形式は、他に、システム構成に応じて、インスタントメッセージサービスの識別名やその他のドメイン名などでもよい。
【００３６】
Ｂ車から上記のような情報を受け取ったＡ車は（ステップ２２）、各車（ここではＡ車及びＢ車）の自車位置、ＩＤ、アドレスを、合流探索要求として通信制御部２３を通じサーバ装置１に送る（ステップ２３）。サーバ装置１では、各車の位置（通常は、移動体の現在位置）を元に、合流地点演算部１２及び経路探索部１４が合流探索シーケンス（手順）を実行し、得られた最適な経路を表す誘導データを送受信部１１が各車のアドレスへ送り（ステップ２４）、各車では通信制御部２３で受信した誘導データに基き、経路誘導部２５によりナビゲーションが開始される（ステップ２５，２６）。
【００３７】
［１−２−５．車と人の合流］
また、第１実施形態は、適用対象の移動体として、車両同士の合流だけでなく車両と人との合流にも適用可能であり、その場合の処理手順を図６に示す。ここで、移動体が「人」の場合、探索される経路は、バスや電車などの公共交通機関を使った経路になり、公共交通機関の乗換案内に関しては各種公知の技術を用いてよい。
【００３８】
図６の処理手順では、まず、Ａ車は合流したい人の携帯しているナビゲーション装置に、合流探索キーを通信により渡す（ステップ５１，５２）。ここで、人の携帯するナビゲーション装置は、専用装置のほかに、例えば、ＧＰＳ機能付携帯電話端末に、予め組込みプログラムやＪａｖａ（登録商標）プログラムなどによりナビゲーション機能を付加したものなどが考えられる。
【００３９】
そして、Ａ車及び人は、現在位置と合流探索キーをサーバ装置１に送り（ステップ５３，５４）、サーバ装置１ではそれを元に、上記で説明した合流探索シーケンスを実行する。なお、合流探索キーを発行したＡ車は、グループを構成する移動体の数として、計何台もしくは何人に発行したかもサーバ装置１に送るが（ステップ５５）、図の場合、Ａ車の他１人に発行したことになる。サーバ装置１では、同じ合流探索キーを伴う合流探査供給の数が、そのグループ中の移動体の合計数になった時点で合流探索シーケンスを実行する。そして、合流探索シーケンスにて得られた最適な経路をそれぞれの車や人に返し、各車及び人においてナビゲーションが開始される（ステップ５６，５７）。
【００４０】
このように、合流対象の移動体に人が含まれる場合には、目標物を、その人の周辺、或いは、駅／バス停等とするのが好ましい。そこで、第１実施形態では、「車と車」が合流する場合と、「車と人」／「人と人」が合流する場合とで、目標物の種別の設定を自動的に変更、つまり合流対象に応じて、目標物の種別を変える。
【００４１】
例えば、合流対象が車両のみの場合の目標物は、道路に面したコンビニエンスストア、ファミリーレストランなどでよいが、合流対象に人が含まれる場合の目標物は、駅、バス停や、その人の現在地周辺、又は、駅／バス停周辺のコンビニエンスストア、ファミリーレストラン等などが望ましい。
【００４２】
このように合流地点を算出する処理手順を図７のフローチャートに示す。すなわち、移動体側のナビゲーション装置は、その型式や車又は人の種別など、各合流対象が車であるか人であるかを識別するための種類の識別データを外部へ送信するように構成し、サーバ装置１では、そのような識別データと共に、位置（通常は現在位置であり、単に「位置」とも呼ぶ）データを取得する（ステップ６１）。
【００４３】
この識別データに基づき、サーバ装置１の種別選択部１３は、合流対象として人が含まれない（ＮＯ）と判定された場合（ステップ６２）には、コンビニエンスストア、ファミリーレストランなど、停車スペースがあって交通の妨げにならない場所を目標物とするように設定を行う（ステップ６３）。一方、ステップ６２において、合流対象に人が含まれる（ＹＥＳ）と判定された場合は、駅、バス停など、人が移動しやすい場所を目標物として設定する（ステップ６４）。
【００４４】
次に、合流地点演算部１２は、上記ステップ６３又は６４で設定した種別の目標物の中から、各合流対象の出発位置の周辺、或いは各出発位置の中間にある目標物を検索する（ステップ６５）。続いて、経路探索部１４は、このように検索した各目標物へ各出発位置から到達するための最適な経路について経路演算を行い（ステップ６６）、到着時刻がほぼ等しくなる目標物が合流地点として選択される（ステップ６７）。
【００４５】
［１−３．第１実施形態の効果］
以上のように、第１実施形態では、合流地点をサーバ装置で算出するので、各移動体間のアルゴリズムの食い違いに妨げられることなく、迅速確実な合流が実現される。
【００４６】
また、第１実施形態では、各出発位置からの各移動体の所要時間差が所定時間以内の地点を合流地点とするので、各移動体の所要時間に大きな差が生じにくく、無駄な待ち時間や利用者間の不公平感が抑制される。
【００４７】
また、第１実施形態では、移動体に人が含まれる場合は合流地点を鉄道駅とするなど、移動体の種類に適した合流地点が用いられるので、多様な移動体の合流が容易になる。
【００４８】
［２．第２実施形態］
上記第１実施形態では、サーバ装置において合流地点を探索する例を説明したが、第２実施形態はサーバ装置を用いない例である。すなわち、第２実施形態におけるナビゲーション装置は、合流相手である他の移動体のナビゲーション装置と通信ネットワーク経由で互いの位置を交換したうえ、少なくとも合流地点を決定するシーケンスに基づいて移動体を合流させるものである。
【００４９】
［２−１．第２実施形態の構成］
このような第２実施形態におけるナビゲーション装置は、図８に示すように、各移動体の位置に基いて合流地点を計算する合流地点演算部２７と、合流地点への経路を計算する経路探索部２６と、経路に沿った誘導を行う経路誘導部２５に加え、シーケンス保障部２８を備える。
【００５０】
このシーケンス保障部２８は、他の移動体のナビゲーション装置２との間で前記通信ネットワーク経由で、前記シーケンスのバージョンを表す情報を交換することにより、前記シーケンスの共通性を保障する手段である。なお、ナビゲーション装置２間の通信については、独自のプロトコルでもかまわないし、インターネットにおけるＴＣＰ／ＩＰのような標準プロトコルを用いてもよい。
【００５１】
［２−２．第２実施形態の作用］
上記のように構成された第２実施形態において、１台の車が全ての経路探索を行う場合の処理手順を図９に示す。この場合、各車（図ではＢ車のみ）から、自車位置と共に、図１０に例示するような自車ＩＤ及び自車アドレスをＡ車に送ると（ステップ３１，３２）、Ａ車のナビゲーション装置は、合流地点演算部２７及び経路探索部２６により、各車の位置情報を元に、図２や図３に準じた合流探索シーケンスで最適な合流地点と経路を求め（ステップ３３）、他の各車にＩＤやアドレス（メールアドレスやＩＰアドレスなど）に基き結果を返し（ステップ３３）、各車は、受信した経路によりナビゲーションを開始する（ステップ３４）。図９の例では、少なくともＡ車のナビゲーション装置が合流地点演算部２７及び経路探索部２６を備えていればよい。
【００５２】
これより望ましい態様は、図８に示すように、各車のナビゲーション装置が合流地点演算部２７と、経路探索部２６と、シーケンス保障部２８を備え、各車がそれぞれ合流探索シーケンスを実行するもので、その場合の処理手順を図１１に示す。すなわち、この処理手順では、各車は相互に、自車位置と、自車ＩＤと、自車アドレス（メールアドレスやＩＰアドレスなど）に加え、合流探索シーケンスがどのバージョンかを交換する（ステップ４１，４２，４３，４４）。
【００５３】
そして、各車のナビゲーション装置において、合流探索シーケンスのバージョンを照合のうえ、合流地点及び経路の計算を行う（ステップ４５，４６）。ここで、図１１のステップ４５，４６にいう「照合」とは、各車のナビゲーション装置のシーケンス保障部２８が、各ナビゲーション装置間でのシーケンスの共通性を保障することである。そして、ここでいうシーケンスのバージョンは、各車が同じアルゴリズムで経路探索を行うためのキー情報である。
【００５４】
より具体的には、バージョンは、例えば、合流地点及びそこへ至る経路を得るプログラムが段階的にバージョンアップされている場合のバージョン番号でもよいし、他の例として、共通のメインプログラムに加えて、個別の付加機能や補正ルーチンなどのオプション要素が働く場合は、どの要素がオンになっているかの情報などでもよい。
【００５５】
すなわち、このようなバージョンが各移動体のナビゲーション装置間で食い違えば、互いに目的の合流地点が異なるなど、探索結果に不整合を生じ、不適切な誘導を行うことになるところ、第２実施形態では、このバージョンの交換により各ナビゲーション装置間でのシーケンスの共通性を保障する。保障する手段としては、例えば、次のようなものが考えられる。
【００５６】
（１）個々のナビゲーション装置において使用するバージョン番号を複数から選択できる場合は、全ナビゲーション装置で共通して選択可能な最新バージョン番号のものを用いる。
【００５７】
（２）上記のようなオプション要素のうち全ナビゲーション装置で共通してオンにできるもの以外を、全ナビゲーション装置で全部オフにする。
【００５８】
（３）最新バージョンのプログラムや、一部のナビゲーション装置だけが持つオプション要素を、それらを持たない他のナビゲーション装置へそっくりそのままデータ転送することにより、実行環境を統一する。
【００５９】
以上のように、各車が同じアルゴリズムを使える状態で、各車のナビゲーション装置が、他車の情報を元に、各車で合流探索シーケンス（図２，図３）を実行し（ステップ４５，４６）、その結果に基いてナビゲーションを開始する（ステップ４７，４８）。
【００６０】
なお、各ＩＤのうち、自車ＩＤの交換については、１対１なら必須ではないが、３台以上の場合、各車がそれぞれどのようなシーケンスのバージョンを使っているのかを区分けするために、必要となる。また、車両ＩＤとしては、固有製造番号などの車載機ＩＤが使用可能である。
【００６１】
［２−３．第２実施形態の効果］
以上のように、第２実施形態では、合流探索等のシーケンスについて、各ナビゲーション装置間でバージョン等の共通性が保障されるので、合流地点や経路について各移動体間で同じ結論が採用され、決定後に確認の通信を行うまでもなく、迅速確実な合流が実現される。
【００６２】
［３．他の実施形態］
なお、本発明は上記各実施形態に限定されるものではなく、次に例示するような他の実施形態も含むものである。例えば、本発明の適用対象たる移動体は、自動車や人には限定されず、各種二輪車など自由に定めることができる。また、携帯電話網に代えてＰＨＳ網やその他の通信回線を用いてもよい。また、グループ中で用いる識別情報は、全て共通でなくても、公開鍵暗号のように所定の演算処理によってグループに属していることが確認できればよい。また、上記各実施形態では、算出された合流地点のデータとして、合流地点までの経路のデータも各移動体に送信する例を示したが、合流地点の例えば座標値だけを各移動体に送り、そこまでの経路探索は各移動体で行わせるようにしてもよい。
【図面の簡単な説明】
【００６３】
【図１】本発明の第１実施形態におけるナビゲーション装置の構成を示す機能ブロック図。
【図２】本発明の実施形態における合流の例を示す図。
【図３】本発明の実施形態における合流の地点及び経路を得る処理手順を示す図。
【図４】本発明の第１実施形態において、各車から探索要求を送信する場合における処理手順を示す図。
【図５】本発明の第１実施形態において、一台の車から探索要求を送信する場合における処理手順を示す図。
【図６】本発明の第１実施形態において、車と人の合流の地点及び経路を得る処理手順を示す図。
【図７】本発明の第１実施形態において、合流対象の種類に応じて目標物の種別を選択する処理手順を示す図。
【図８】本発明の第２実施形態の構成を示す機能ブロック図。
【図９】本発明の第２実施形態における処理手順の一例を示す図。
【図１０】本発明の第２実施形態におけるＩＤ及びアドレスを示す概念図。
【図１１】本発明の第２実施形態において、シーケンスのバージョンを用いた処理手順を示す図。
【符号の説明】
【００６４】
１…サーバ装置
２…ナビゲーション装置
１１…送受信部
１２，２７…合流地点演算部
１４，２６…経路探索部
１５…道路データ
１６…グループデータ
２１…ＣＰＵ
２２…メモリ
２３…通信制御部
２４…携帯電話端末
２５…経路誘導部
２８…シーケンス保障部
Ｎ…インターネット
Ｋ…携帯電話網
【技術分野】
【０００１】
本発明は、複数の移動体を早く確実に合流させるサーバ装置及びナビゲーション方法に関するものである。
【背景技術】
【０００２】
近年、自動車とデジタル技術の普及に伴い、ナビゲーション装置などのナビゲーション技術が急速に進歩している。ナビゲーション装置は、まず、指定された目的地への最適な経路を予め用意した道路データに基づいて探索し、設定する。ナビゲーション装置は、その設定した最適な経路に自車を誘導するために、自車位置をリアルタイムに検出して周辺地図と一緒に画面表示しながら、各交差点における右左折等の誘導案内を車両の進行に応じて画面表示や合成音声などで出力するものであり、最近は、人が携帯して用いるタイプのナビゲーション装置も登場している。
【０００３】
ところで、自車以外の車や人と待ち合わせて合流しようとした場合は、当事者が電話等による直接対話で目的地を決め、片方の車だけが移動したり、ｉナビリンクなどの位置情報伝送機能搭載のカーナビゲーション装置を使い、一方の位置を他方に送信し、受信側の車だけが送られてきた位置に移動したりする手法が従来用いられてきた。また、お互いの位置情報を周期的に伝送し合うことにより、地図上に表示される相手の位置を見ながら合流する技術も知られていた。
【０００４】
しかしながら、片方だけが移動する場合は、他方はそのままの位置で待っていることになるため、時間が余計にかかり無駄も多くなる。さらに同様に複数台の車が一台の車の位置に合流する場合は、先に到着した車が、最も遠い車が到着するまで待たねばならず同様に無駄が多かった。また、互いに移動している当事者が地図上の相手を見ながら合流することは、よほど意志の疎通を徹底していないと行き違いが多く事実上困難であった。
【０００５】
そこで、複数の車両を迅速且つ容易に合流させるため、ナビゲーション装置に合流地点や合流地点までの経路を計算させる従来技術が提案された。そのように複数車両が迅速に合流するためのアルゴリズムとしては、次のようなものがあげられる。
【０００６】
特許文献１は、各出発地点から等しい距離又は所要時間の交差点を基準地点とし、そこから所定の距離や時間内にあるガソリンスタンドなどの待ち合わせ場所を検索するものである。特許文献２は、両車が同じ道路上の場合はその中間地点を合流地点としたり、両車が別の道路上の場合は、両車を結ぶ直線の中間地点に最寄の道路上に合流地点を設けるものである。特許文献３は、３台以上の場合に一番近い２台が所定の距離以上離れると警報を出し、待合せ場所を設定のうえ残りの車両へ通知し、そこに誘導させるものである。
【０００７】
【特許文献１】特開平１０−２８１７８２号公報
【特許文献２】特開２０００−８８５９１号公報
【特許文献３】特開２００１−１０８４６０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、上記のような従来技術を実際に実施しようとすると、各移動体で共通して全く同じアルゴリズムを適用することが事実上難しいという問題点が生じる。すなわち、ナビゲーションにおける経路探索等のアルゴリズムは日進月歩であって、各ナビゲーション装置間で、プログラムに基づく処理アルゴリズムの種類やバージョンが異なると、各車で探索結果が食い違って不適切な誘導の原因となる。
【０００９】
また、近年ではＧＰＳ装置の小型化や携帯電話端末との一体化も進み、合流する移動体の種類は、車両に限らず人や自転車など多様化している。例えば、人の場合、車での移動とは異なり、徒歩、鉄道、バスのように移動手段が限定される結果、移動できる場所が、現在地周辺や、駅、バス停等に限られるなど、移動体の種類によって条件が異なる。これに対し、従来はこのような合流する移動体の種類を考慮した技術は知られていなかった。
【００１０】
本発明は、上記のような従来技術の問題点を解決するために提案されたものであって、その目的は、複数の移動体を早く確実に合流させるナビゲーション方法を提供することであり、より具体的には、合流地点をサーバ装置で決めナビゲーション装置間でどのアルゴリズムを使うか伝達させることである。
【００１１】
また、本発明の他の目的は、合流しようとする移動体の種類に応じ合流地点の種類を選ぶナビゲーション方法を提供することである。
【００１２】
また、本発明の他の目的は、各種移動体の所要時間の平均化により、無駄な待ち時間や利用者間の不公平感を抑制するナビゲーション方法を提供することである。
【課題を解決するための手段】
【００１３】
上記の目的を達成するため、本発明のサーバ装置は、複数の各移動体に対応する各ナビゲーション装置から、通信ネットワーク経由で、前記ナビゲーション装置のグループを構成するものとして互いに関連付けられた識別情報と、前記ナビゲーション装置のそれぞれの位置と、を受け取る手段と、各移動体の種類に基づいて合流地点の種別を選択する手段と、受信した前記各位置に基づいて前記合流地点を算出する演算手段と、算出した前記合流地点のデータを、前記識別情報を有する前記各ナビゲーション装置に送信する手段と、をコンピュータが備えたことを特徴とする。
【００１４】
本発明の他の態様は、前記演算手段は、前記各位置からの各移動体の所要時間差が所定時間以内の地点を合流地点として算出するように構成されたことを特徴とする。
【００１５】
なお、前記の様な、複数の各移動体に対応する各ナビゲーション装置から通信ネットワーク経由で、グループを構成するものとして互いに関連付けられた識別情報と、それぞれの位置と、を受け取る手段と、各移動体の種類に基づいて合流地点の種別を選択する手段と、受信した前記各位置に基づいて前記合流地点を算出する演算手段と、算出した前記合流地点のデータを、前記識別情報を有する前記各ナビゲーション装置に送信する手段によるナビゲーション方法も、本発明の一態様である。
【発明の効果】
【００１６】
本発明によれば、合流地点をサーバ装置で決めナビゲーション装置間でどのアルゴリズムを使うか伝達させ、移動体の種類に応じ合流地点の種類を選ぶことにより、複数の移動体を早く確実に合流させるサーバ装置及びナビゲーション方法を提供することができる。
【発明を実施するための最良の形態】
【００１７】
次に、本発明に関する複数の実施の形態（以下それぞれ「実施形態」と呼ぶ）について図面を参照して具体的に説明する。なお、各実施形態は、コンピュータをプログラムで制御することにより実現できるが、この場合のハードウェアやプログラムの実現態様は各種変更可能であるから、以下の説明では、本発明及び各実施形態の各機能を実現する仮想的回路ブロックを用いる。
【００１８】
［１．第１実施形態］
第１実施形態は、合流地点算出をサーバ装置で行う例である。
［１−１．第１実施形態の構成］
第１実施形態は、図１に示すように、サーバ装置（単に「サーバ」とも呼ぶ）１と、車両等の各移動体に対応する各ナビゲーション装置２とを、通信ネットワークである携帯電話網Ｋ及びインターネットＮで接続したナビゲーションシステムである。
【００１９】
このうち、サーバ装置１は、コンピュータがプログラムに基いて、図１に示す次の要素を備えたものである。まず、送受信部１１は、合流しようとする複数の各移動体の種類及び位置の入力を受け付ける手段であり、より具体的には、各移動体のナビゲーション装置２から前記通信ネットワーク経由で、グループを構成するものとして互いに関連付けられた識別情報と、それぞれの位置と、を受け取る手段である。このようなグループごとの識別情報等のデータはグループデータ１６として格納される。
【００２０】
また、合流地点演算部１２は、受信した前記各位置に基づいて前記各移動体の合流地点を算出する演算手段である。また、経路探索部１４は、一又は二以上の前記合流地点までの各移動体の経路を、予め用意された道路データ１５に基いて探索する手段である。また、探索された各経路については所要時間が得られるが、前記合流地点演算部１２は、複数の合流地点の候補がある場合に、各候補地点までの前記各位置からの各移動体の所要時間差が所定時間以内の地点を合流地点として算出するように構成されている。
【００２１】
また、前記送受信部１１は、その移動体すなわち前記識別情報を有する前記各ナビゲーション装置２に、合流地点のデータ、すなわち合流地点及びそこまでのその移動体の経路を表すデータを、送信する手段でもある。また、種別選択部１３は、車又は人といった各移動体の種類に基づいて合流地点の種別を選択する手段である。
【００２２】
また、ナビゲーション装置２は、ＣＰＵ２１やメモリ２２を含むコンピュータがプログラムに基いて、図１に示す次の要素を備えたものである。まず、通信制御部２３は、携帯電話網Ｋに接続するための携帯電話端末２４を制御することにより、前記通信ネットワーク経由でサーバ装置１に対し、識別情報と位置情報とを送信する手段であり、また、サーバ装置１から返信される合流地点のデータを受信する手段でもある。また、経路誘導部２５は、受信した前記データに基いて、前記合流地点への経路誘導を行う手段である。なお、ナビゲーション装置２の側に、独自の経路探索部２６を設け、サーバ装置１では合流地点のみ決め、そこまでの経路は各ナビゲーション装置２側で個別に探索させるようにしてもよい。
【００２３】
［１−２．第１実施形態の作用］
上記のように構成された第１実施形態では、サーバ装置１において、望ましくは、合流地点に加えて、合流地点に至る各移動体のための誘導経路も探索する。
【００２４】
［１−２−１．合流探索の例］
まず、第１実施形態において、各移動体の位置から合流地点を計算する手法は、従来の技術の欄で例示したような従来公知のものを用いてよいが、ここで一例として、合流地点及び経路を探索する処理（以下「合流探索」と呼ぶこととする）の例を図２に、またその場合の処理手順を図３に示す。
【００２５】
すなわち、図２に示すように、Ａ車とＢ車という２台の車両の合流地点を計算する場合、Ａ車とＢ車の周辺もしくは中間地点にある目標物を、道路データ１５や施設のデータなど予め用意されたデータから検索する（ステップ０１）。すなわち、各車の合流地点は、理論的には各車の中間地点であるが、実際には何らかの目標物となる。実際の目標物の種類は自由であるが、例えばコンビニエンスストア（以下「コンビニ」と略称する）のように駐停車スペースがあって交通の妨げにならない場所が望ましい。
【００２６】
具体的には、目標物は、各車両に囲まれた範囲で、施設データなどに基くランドマークの検索により探索するが、より具体的には、待ち合わせに適した種類の場所の候補を各車両間のエリアで選択することである。但し、そのようなエリア内で適切なランドマークが発見できない場合は、最初に合流探索をかけた車両（例えばＡ車）を合流目的地としてもよい。
【００２７】
そして、候補として検索された各目標物を目的地として、各車の現在位置からのそれぞれの経路を、複数探索する（ステップ０２）。図２の例では、車が２台で目標物の候補がコンビニＶ１，Ｖ２，Ｖ３の３つであり、３組合計６個の経路を探索する。これら６つの経路は、図２において、破線矢印で示す経路ａ１とｂ１、一点鎖線矢印で示す経路ａ２とｂ２、実線矢印で示す経路ａ３とｂ３であり、ここでいう「ａ」「ｂ」はＡ車とＢ車をそれぞれ表し、「１」「２」「３」はそれぞれのコンビニＶ１，Ｖ２，Ｖ３への経路に対応する。
【００２８】
そして、この探索結果から、目標物毎に各車の到着予測時間を比べ、時間の差が最も少ない目標物、つまり予測到着所要時間がほぼ等しい探索経路を選択する（ステップ０３）。
【００２９】
つまり、地域によっては目標物が少ないため、各車両から等時間距離に目標物を設定できない場合も考えられ、この場合、最寄のある目標物を合流地点とすると、あるＡ車が先に到着し、別のＢ車はそれより遅れる事態も考えられる。そこで、前記各位置からの各移動体の所要時間差が所定時間までは許容範囲とし、その許容範囲以内の地点を合流地点として算出するが、原則としては、そのような所要時間差が最小の地点を合流地点とする。但し、これは望ましい例であり、最初から単一の合流地点及びそれへの経路を計算してもよい。
【００３０】
上記のような合流探索の前提として、グループとして行動する各車両の位置と合流探索要求がサーバ装置に通知されるが、各車両の位置を伴う合流探索要求をサーバ装置に伝えるには、以下のように、各車（のナビゲーション装置２）から要求するパターンと、代表する１台から要求するパターンとが考えられる。
【００３１】
［１−２−２．各車から要求する場合］
まず、図４は、各車から合流探索要求をサーバ装置１に送信する場合の処理手順を示す図である。この例では、Ａ車の通信制御部２３は、合流したい車（図の場合Ｂ車）に合流探索キーを生成して通信により渡す（ステップ１１，１２）。この「合流探索キー」は、同じグループであることをサーバ装置１で判断するための認識コードなどの識別情報であり、形式は自由である。
【００３２】
そして、各車の通信制御部２３はそれぞれ、自車位置と、上記の合流探索キーを合流探索要求としてサーバ装置１に送り（ステップ１３，１４）、サーバ装置１ではそれを元に、合流探索シーケンスを実行する（ステップ１５）。ここで、合流探索キーを発行したＡ車は、自車を含め何台に発行したか（グループ台数）もサーバ装置１へ送る（ステップ１３）。例えば、図２の場合、Ａ車の他１台、計２台に発行したことになる。
【００３３】
サーバ装置１では、あるグループの合流探索キーを送ってきた車両の台数がそのグループの台数になった時点で合流探索シーケンスを実行する（ステップ１５）。この合流探索シーケンスでは、概略的には、合流地点演算部１２が各車の合流地点を計算した上、その合流地点までの各車の誘導経路を経路探索部１４が計算するが、具体的には既に説明した通りである。そして、サーバ装置１の送受信部１１は、この合流探索シーケンスにて得られた最適な経路を表すデータ（誘導データと呼ぶ）をそれぞれの車に返信し、各車では、通信制御部２３で受信した誘導データに基いて、経路誘導部２５によりナビゲーションが開始される（ステップ１６，１７）。
【００３４】
［１−２−３．合流探索キーの役割］
ここで、図４で示した合流探索キーの役割を、図１を参照して説明する。すなわち、サーバ装置１には、合流探索キーによって探索結果が一時的に複数格納され、その中から最適な経路が選択される。また、一つの探索結果は各車毎の探索結果を含む。例えば、合流探索キーが「１０」で、これに対応する探索結果１０１，１０２，１０３がある場合、そのどれをとっても、Ａ車の経路とＢ車の経路とが含まれる。また、合流探索キーが「１５」の場合、探索結果１５１にも１５２にも、それぞれＸ車、Ｙ車、Ｚ車という３台分の経路が格納される。
【００３５】
［１−２−４．１台が要求する場合］
次に、図５は、合流探索要求を１台の車（ここではＡ車のみ）が行う場合の処理手順を示す図である。この場合、Ａ車以外の全車（ここではＢ車）が自車位置と自車ＩＤ及び自車アドレスを、通信制御部２３により通信でＡ車に送る（ステップ２１）。ここでいう自車「アドレス」は、例えば、外部から自車に対して誘導データ送信などの通信を行うためのメールアドレスやＩＰアドレスであり、この例では図４の場合と異なり、Ｂ車はサーバ装置１に合流探索要求を直接行わないため、サーバ装置１からＢ車に探索結果伝達のために用いる。アドレスの具体的形式は、他に、システム構成に応じて、インスタントメッセージサービスの識別名やその他のドメイン名などでもよい。
【００３６】
Ｂ車から上記のような情報を受け取ったＡ車は（ステップ２２）、各車（ここではＡ車及びＢ車）の自車位置、ＩＤ、アドレスを、合流探索要求として通信制御部２３を通じサーバ装置１に送る（ステップ２３）。サーバ装置１では、各車の位置（通常は、移動体の現在位置）を元に、合流地点演算部１２及び経路探索部１４が合流探索シーケンス（手順）を実行し、得られた最適な経路を表す誘導データを送受信部１１が各車のアドレスへ送り（ステップ２４）、各車では通信制御部２３で受信した誘導データに基き、経路誘導部２５によりナビゲーションが開始される（ステップ２５，２６）。
【００３７】
［１−２−５．車と人の合流］
また、第１実施形態は、適用対象の移動体として、車両同士の合流だけでなく車両と人との合流にも適用可能であり、その場合の処理手順を図６に示す。ここで、移動体が「人」の場合、探索される経路は、バスや電車などの公共交通機関を使った経路になり、公共交通機関の乗換案内に関しては各種公知の技術を用いてよい。
【００３８】
図６の処理手順では、まず、Ａ車は合流したい人の携帯しているナビゲーション装置に、合流探索キーを通信により渡す（ステップ５１，５２）。ここで、人の携帯するナビゲーション装置は、専用装置のほかに、例えば、ＧＰＳ機能付携帯電話端末に、予め組込みプログラムやＪａｖａ（登録商標）プログラムなどによりナビゲーション機能を付加したものなどが考えられる。
【００３９】
そして、Ａ車及び人は、現在位置と合流探索キーをサーバ装置１に送り（ステップ５３，５４）、サーバ装置１ではそれを元に、上記で説明した合流探索シーケンスを実行する。なお、合流探索キーを発行したＡ車は、グループを構成する移動体の数として、計何台もしくは何人に発行したかもサーバ装置１に送るが（ステップ５５）、図の場合、Ａ車の他１人に発行したことになる。サーバ装置１では、同じ合流探索キーを伴う合流探査供給の数が、そのグループ中の移動体の合計数になった時点で合流探索シーケンスを実行する。そして、合流探索シーケンスにて得られた最適な経路をそれぞれの車や人に返し、各車及び人においてナビゲーションが開始される（ステップ５６，５７）。
【００４０】
このように、合流対象の移動体に人が含まれる場合には、目標物を、その人の周辺、或いは、駅／バス停等とするのが好ましい。そこで、第１実施形態では、「車と車」が合流する場合と、「車と人」／「人と人」が合流する場合とで、目標物の種別の設定を自動的に変更、つまり合流対象に応じて、目標物の種別を変える。
【００４１】
例えば、合流対象が車両のみの場合の目標物は、道路に面したコンビニエンスストア、ファミリーレストランなどでよいが、合流対象に人が含まれる場合の目標物は、駅、バス停や、その人の現在地周辺、又は、駅／バス停周辺のコンビニエンスストア、ファミリーレストラン等などが望ましい。
【００４２】
このように合流地点を算出する処理手順を図７のフローチャートに示す。すなわち、移動体側のナビゲーション装置は、その型式や車又は人の種別など、各合流対象が車であるか人であるかを識別するための種類の識別データを外部へ送信するように構成し、サーバ装置１では、そのような識別データと共に、位置（通常は現在位置であり、単に「位置」とも呼ぶ）データを取得する（ステップ６１）。
【００４３】
この識別データに基づき、サーバ装置１の種別選択部１３は、合流対象として人が含まれない（ＮＯ）と判定された場合（ステップ６２）には、コンビニエンスストア、ファミリーレストランなど、停車スペースがあって交通の妨げにならない場所を目標物とするように設定を行う（ステップ６３）。一方、ステップ６２において、合流対象に人が含まれる（ＹＥＳ）と判定された場合は、駅、バス停など、人が移動しやすい場所を目標物として設定する（ステップ６４）。
【００４４】
次に、合流地点演算部１２は、上記ステップ６３又は６４で設定した種別の目標物の中から、各合流対象の出発位置の周辺、或いは各出発位置の中間にある目標物を検索する（ステップ６５）。続いて、経路探索部１４は、このように検索した各目標物へ各出発位置から到達するための最適な経路について経路演算を行い（ステップ６６）、到着時刻がほぼ等しくなる目標物が合流地点として選択される（ステップ６７）。
【００４５】
［１−３．第１実施形態の効果］
以上のように、第１実施形態では、合流地点をサーバ装置で算出するので、各移動体間のアルゴリズムの食い違いに妨げられることなく、迅速確実な合流が実現される。
【００４６】
また、第１実施形態では、各出発位置からの各移動体の所要時間差が所定時間以内の地点を合流地点とするので、各移動体の所要時間に大きな差が生じにくく、無駄な待ち時間や利用者間の不公平感が抑制される。
【００４７】
また、第１実施形態では、移動体に人が含まれる場合は合流地点を鉄道駅とするなど、移動体の種類に適した合流地点が用いられるので、多様な移動体の合流が容易になる。
【００４８】
［２．第２実施形態］
上記第１実施形態では、サーバ装置において合流地点を探索する例を説明したが、第２実施形態はサーバ装置を用いない例である。すなわち、第２実施形態におけるナビゲーション装置は、合流相手である他の移動体のナビゲーション装置と通信ネットワーク経由で互いの位置を交換したうえ、少なくとも合流地点を決定するシーケンスに基づいて移動体を合流させるものである。
【００４９】
［２−１．第２実施形態の構成］
このような第２実施形態におけるナビゲーション装置は、図８に示すように、各移動体の位置に基いて合流地点を計算する合流地点演算部２７と、合流地点への経路を計算する経路探索部２６と、経路に沿った誘導を行う経路誘導部２５に加え、シーケンス保障部２８を備える。
【００５０】
このシーケンス保障部２８は、他の移動体のナビゲーション装置２との間で前記通信ネットワーク経由で、前記シーケンスのバージョンを表す情報を交換することにより、前記シーケンスの共通性を保障する手段である。なお、ナビゲーション装置２間の通信については、独自のプロトコルでもかまわないし、インターネットにおけるＴＣＰ／ＩＰのような標準プロトコルを用いてもよい。
【００５１】
［２−２．第２実施形態の作用］
上記のように構成された第２実施形態において、１台の車が全ての経路探索を行う場合の処理手順を図９に示す。この場合、各車（図ではＢ車のみ）から、自車位置と共に、図１０に例示するような自車ＩＤ及び自車アドレスをＡ車に送ると（ステップ３１，３２）、Ａ車のナビゲーション装置は、合流地点演算部２７及び経路探索部２６により、各車の位置情報を元に、図２や図３に準じた合流探索シーケンスで最適な合流地点と経路を求め（ステップ３３）、他の各車にＩＤやアドレス（メールアドレスやＩＰアドレスなど）に基き結果を返し（ステップ３３）、各車は、受信した経路によりナビゲーションを開始する（ステップ３４）。図９の例では、少なくともＡ車のナビゲーション装置が合流地点演算部２７及び経路探索部２６を備えていればよい。
【００５２】
これより望ましい態様は、図８に示すように、各車のナビゲーション装置が合流地点演算部２７と、経路探索部２６と、シーケンス保障部２８を備え、各車がそれぞれ合流探索シーケンスを実行するもので、その場合の処理手順を図１１に示す。すなわち、この処理手順では、各車は相互に、自車位置と、自車ＩＤと、自車アドレス（メールアドレスやＩＰアドレスなど）に加え、合流探索シーケンスがどのバージョンかを交換する（ステップ４１，４２，４３，４４）。
【００５３】
そして、各車のナビゲーション装置において、合流探索シーケンスのバージョンを照合のうえ、合流地点及び経路の計算を行う（ステップ４５，４６）。ここで、図１１のステップ４５，４６にいう「照合」とは、各車のナビゲーション装置のシーケンス保障部２８が、各ナビゲーション装置間でのシーケンスの共通性を保障することである。そして、ここでいうシーケンスのバージョンは、各車が同じアルゴリズムで経路探索を行うためのキー情報である。
【００５４】
より具体的には、バージョンは、例えば、合流地点及びそこへ至る経路を得るプログラムが段階的にバージョンアップされている場合のバージョン番号でもよいし、他の例として、共通のメインプログラムに加えて、個別の付加機能や補正ルーチンなどのオプション要素が働く場合は、どの要素がオンになっているかの情報などでもよい。
【００５５】
すなわち、このようなバージョンが各移動体のナビゲーション装置間で食い違えば、互いに目的の合流地点が異なるなど、探索結果に不整合を生じ、不適切な誘導を行うことになるところ、第２実施形態では、このバージョンの交換により各ナビゲーション装置間でのシーケンスの共通性を保障する。保障する手段としては、例えば、次のようなものが考えられる。
【００５６】
（１）個々のナビゲーション装置において使用するバージョン番号を複数から選択できる場合は、全ナビゲーション装置で共通して選択可能な最新バージョン番号のものを用いる。
【００５７】
（２）上記のようなオプション要素のうち全ナビゲーション装置で共通してオンにできるもの以外を、全ナビゲーション装置で全部オフにする。
【００５８】
（３）最新バージョンのプログラムや、一部のナビゲーション装置だけが持つオプション要素を、それらを持たない他のナビゲーション装置へそっくりそのままデータ転送することにより、実行環境を統一する。
【００５９】
以上のように、各車が同じアルゴリズムを使える状態で、各車のナビゲーション装置が、他車の情報を元に、各車で合流探索シーケンス（図２，図３）を実行し（ステップ４５，４６）、その結果に基いてナビゲーションを開始する（ステップ４７，４８）。
【００６０】
なお、各ＩＤのうち、自車ＩＤの交換については、１対１なら必須ではないが、３台以上の場合、各車がそれぞれどのようなシーケンスのバージョンを使っているのかを区分けするために、必要となる。また、車両ＩＤとしては、固有製造番号などの車載機ＩＤが使用可能である。
【００６１】
［２−３．第２実施形態の効果］
以上のように、第２実施形態では、合流探索等のシーケンスについて、各ナビゲーション装置間でバージョン等の共通性が保障されるので、合流地点や経路について各移動体間で同じ結論が採用され、決定後に確認の通信を行うまでもなく、迅速確実な合流が実現される。
【００６２】
［３．他の実施形態］
なお、本発明は上記各実施形態に限定されるものではなく、次に例示するような他の実施形態も含むものである。例えば、本発明の適用対象たる移動体は、自動車や人には限定されず、各種二輪車など自由に定めることができる。また、携帯電話網に代えてＰＨＳ網やその他の通信回線を用いてもよい。また、グループ中で用いる識別情報は、全て共通でなくても、公開鍵暗号のように所定の演算処理によってグループに属していることが確認できればよい。また、上記各実施形態では、算出された合流地点のデータとして、合流地点までの経路のデータも各移動体に送信する例を示したが、合流地点の例えば座標値だけを各移動体に送り、そこまでの経路探索は各移動体で行わせるようにしてもよい。
【図面の簡単な説明】
【００６３】
【図１】本発明の第１実施形態におけるナビゲーション装置の構成を示す機能ブロック図。
【図２】本発明の実施形態における合流の例を示す図。
【図３】本発明の実施形態における合流の地点及び経路を得る処理手順を示す図。
【図４】本発明の第１実施形態において、各車から探索要求を送信する場合における処理手順を示す図。
【図５】本発明の第１実施形態において、一台の車から探索要求を送信する場合における処理手順を示す図。
【図６】本発明の第１実施形態において、車と人の合流の地点及び経路を得る処理手順を示す図。
【図７】本発明の第１実施形態において、合流対象の種類に応じて目標物の種別を選択する処理手順を示す図。
【図８】本発明の第２実施形態の構成を示す機能ブロック図。
【図９】本発明の第２実施形態における処理手順の一例を示す図。
【図１０】本発明の第２実施形態におけるＩＤ及びアドレスを示す概念図。
【図１１】本発明の第２実施形態において、シーケンスのバージョンを用いた処理手順を示す図。
【符号の説明】
【００６４】
１…サーバ装置
２…ナビゲーション装置
１１…送受信部
１２，２７…合流地点演算部
１４，２６…経路探索部
１５…道路データ
１６…グループデータ
２１…ＣＰＵ
２２…メモリ
２３…通信制御部
２４…携帯電話端末
２５…経路誘導部
２８…シーケンス保障部
Ｎ…インターネット
Ｋ…携帯電話網
【特許請求の範囲】
【請求項１】
複数の各移動体に対応する各ナビゲーション装置から、通信ネットワーク経由で、前記ナビゲーション装置のグループを構成するものとして互いに関連付けられた識別情報と、前記ナビゲーション装置のそれぞれの位置と、を受け取る手段と、
各移動体の種類に基づいて合流地点の種別を選択する手段と、
受信した前記各位置に基づいて前記合流地点を算出する演算手段と、
算出した前記合流地点のデータを、前記識別情報を有する前記各ナビゲーション装置に送信する手段と、
をコンピュータが備えたことを特徴とするサーバ装置。
【請求項２】
前記演算手段は、前記各位置からの各移動体の所要時間差が所定時間以内の地点を合流地点として算出するように構成されたことを特徴とする請求項１記載のサーバ装置。
【請求項３】
サーバコンピュータが、
複数の各移動体に対応する各ナビゲーション装置から、通信ネットワーク経由で、前記ナビゲーション装置のグループを構成するものとして互いに関連付けられた識別情報と、前記ナビゲーション装置のそれぞれの位置と、を受け取り、
各移動体の種類に基づいて合流地点の種別を選択し、
受信した前記各位置に基づいて前記合流地点を算出する演算処理を行い、
算出した前記合流地点のデータを、前記識別情報を有する前記各ナビゲーション装置に送信することを特徴とするナビゲーション方法。
【請求項４】
前記演算処理は、前記各位置からの各移動体の所要時間差が所定時間以内の地点を合流地点として算出することを特徴とする請求項３記載のナビゲーション方法。
【請求項１】
複数の各移動体に対応する各ナビゲーション装置から、通信ネットワーク経由で、前記ナビゲーション装置のグループを構成するものとして互いに関連付けられた識別情報と、前記ナビゲーション装置のそれぞれの位置と、を受け取る手段と、
各移動体の種類に基づいて合流地点の種別を選択する手段と、
受信した前記各位置に基づいて前記合流地点を算出する演算手段と、
算出した前記合流地点のデータを、前記識別情報を有する前記各ナビゲーション装置に送信する手段と、
をコンピュータが備えたことを特徴とするサーバ装置。
【請求項２】
前記演算手段は、前記各位置からの各移動体の所要時間差が所定時間以内の地点を合流地点として算出するように構成されたことを特徴とする請求項１記載のサーバ装置。
【請求項３】
サーバコンピュータが、
複数の各移動体に対応する各ナビゲーション装置から、通信ネットワーク経由で、前記ナビゲーション装置のグループを構成するものとして互いに関連付けられた識別情報と、前記ナビゲーション装置のそれぞれの位置と、を受け取り、
各移動体の種類に基づいて合流地点の種別を選択し、
受信した前記各位置に基づいて前記合流地点を算出する演算処理を行い、
算出した前記合流地点のデータを、前記識別情報を有する前記各ナビゲーション装置に送信することを特徴とするナビゲーション方法。
【請求項４】
前記演算処理は、前記各位置からの各移動体の所要時間差が所定時間以内の地点を合流地点として算出することを特徴とする請求項３記載のナビゲーション方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２００８−２９８７９１（Ｐ２００８−２９８７９１Ａ）
【公開日】平成２０年１２月１１日（２００８．１２．１１）
【国際特許分類】
【出願番号】特願２００８−１８４７９０（Ｐ２００８−１８４７９０）
【出願日】平成２０年７月１６日（２００８．７．１６）
【分割の表示】特願２００２−２８７０６３（Ｐ２００２−２８７０６３）の分割
【原出願日】平成１４年９月３０日（２００２．９．３０）
【出願人】（０００００１４８７）クラリオン株式会社 (1,722)
【Ｆターム（参考）】
【公開日】平成２０年１２月１１日（２００８．１２．１１）
【国際特許分類】
【出願日】平成２０年７月１６日（２００８．７．１６）
【分割の表示】特願２００２−２８７０６３（Ｐ２００２−２８７０６３）の分割
【原出願日】平成１４年９月３０日（２００２．９．３０）
【出願人】（０００００１４８７）クラリオン株式会社 (1,722)
【Ｆターム（参考）】
[ Back to top ]