JP2016502096A

JP2016502096A - 経路計算方法、経路獲得方法またはこのための装置

Info

Publication number: JP2016502096A
Application number: JP2015547859A
Authority: JP
Inventors: ホンポムアン; チェヒョクチェ
Original assignee: LG Electronics Inc
Current assignee: LG Electronics Inc
Priority date: 2012-12-13
Filing date: 2013-12-13
Publication date: 2016-01-21
Anticipated expiration: 2033-12-13
Also published as: JP6105747B2; EP2933606A4; US20160216125A1; KR20150096653A; CN104919281B; US9574887B2; CN104919281A; WO2014092504A1; EP2933606A1

Abstract

【課題】経路の再計算が必要であるか否かを決定する方法を提供する。【解決手段】サーバーによって行われ、端末が以前に報告された位置から特定の距離だけ移動すると、端末から端末の現在の位置を受信する段階、目的地が第３者の識別子と定義される第３者の位置であると、第３者の現在の位置を獲得する段階、及び獲得された第３者の現在の位置に基づいた特定の条件によって経路の再計算が必要であるか否かを決定する段階を含み、特定の条件は、（１）第３者が以前に報告された位置から予め決定された距離以上を移動した場合、（２）第３者が以前に報告された位置から予め定義された距離以上に移動しておらず、端末の現在の位置と第３者の現在の位置との間の距離がしきい値未満である場合であって、特定の条件のうち一つが満足されると、経路の再計算が必要であると決定することができる。【選択図】図６

Description

本発明は、経路を計算する方法、経路を獲得する方法、またはこのための装置に関し、より詳細には、サーバーから提供された情報を用いて経路を計算する方法またはそのための端末と、情報を提供するか否かを決定するための方法またはそのためのサーバーに関する。

従来は、ナビゲーション端末がＧＰＳ（ＧｌｏｂａｌＰｏｓｉｔｉｏｎｉｎｇＳｙｓｔｅｍ）との連結を通じて現在の位置、すなわち、出発地を検出し、使用者から旅行の目的地の入力を受け、端末機自体で経路を計算する方式が用いられた。しかし、最近、スマートフォンの普及と性能向上により、移動通信網でＰＮＤｓ（ＰｅｒｓｏｎａｌＮａｖｉｇａｔｉｏｎＤｅｖｉｃｅｓ）を用いて交通情報及び経路情報を提供するサーバーから経路情報、経路関連リアルタイム交通情報及び多様な情報を提供するサービス方式が活用されている。

特に、多様な形態のナビゲーションサービスが提供される中、ＯＭＡ（ＯｐｅｎＭｏｂｉｌｅＡｌｌｉａｎｃｅ）標準化団体では、既存の放送形態で情報が提供されるＤＭＢ（ＤｉｇｉｔａｌＭｕｌｔｉｍｅｄｉａＢｒｏａｄｃａｓｔｉｎｇ）網でＴＰＥＧ（ＴｒａｆｆｉｃＰｒｏｔｏｃｏｌＥｘｐｅｒｔＧｒｏｕｐ）情報を伝達する方式ではなく、移動通信網や無線網のＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）基盤のネットワークを介してリアルタイム交通情報をＰ２Ｐ（Ｐｅｅｒ―ｔｏ―Ｐｅｅｒ）で伝達するダイナミックナビゲーションイネーブラー（ＤｙｎａｍｉｃＮａｖｉｇａｔｉｏｎＥｎａｂｌｅｒ、ＤｙｎＮａｖ）を標準化している。該当の標準では、スマートフォンのナビゲーション端末とサービスの形態を大きく二つに分けている。

第一の形態は、複雑な経路計算をスマートフォンに搭載されたナビゲーションアプリケーションで行わず、交通情報及び経路情報を提供するサーバーで行い、該当の経路をスマートフォンに伝達する形態である。第二の形態は、スマートフォンの性能向上により、経路計算をスマートフォンに搭載されたアプリケーション自体で行う場合、または移動通信モデムを装着したナビゲーション端末機が経路計算を行う場合であって、経路情報を交通情報を提供するサーバーが伝達せず、端末が計算した経路をサーバーに登録すると、経路と関連したリアルタイム交通情報のみを既存の放送の形態でないＩＰ基盤のＰ２Ｐでサーバーからカスタマイズ型で受け取ることができる形態である。

図１は、ナビゲーション装置に対する区分を示している。ナビゲーション装置は、ＤＭＢなどの放送網を介して伝達されるＴＰＥＧ基盤の交通情報を追加的に伝達する形態１１０、移動通信網またはＷｉ―ＦｉなどのＩＰ基盤で交通情報を追加的に伝達する形態１２０、そして、他の通信媒体との連結なく、ＧＰＳとの連結を通じて車両の位置を追跡し、経路情報を生成及び提供するスタンドアローン（Ｓｔａｎｄａｌｏｎｅ）形態１３０に区分することができる。

また、ＯＭＡＬＯＣＷＧで現在標準化しているＤｙｎＮａｖは、前記の区分においてＩＰ基盤の交通情報を伝達する形態１２０、より詳細には、Ｐ２Ｐ形態で伝達する区分に属し、ＤｙｎＮａｖでは、ナビゲーション装置を下記のように２つに区分している。

１．スマートＮＤ（ＳｍａｒｔＮＤ、１２２）：自ら経路計算が可能であり、ＤｙｎＮａｖサーバーを介して経路情報を受信せず、リアルタイム交通情報のみを要請する装置

２．軽量ＮＤ（ＬｉｇｈｔｗｅｉｇｈｔＮＤ、１２１）：自ら経路計算が不可能であり、ＤｙｎＮａｖサーバーを介して経路情報を含む全てのリアルタイム交通情報を要請する装置

従来のＤｙｎＮａｖシステムでは、該当の交通情報を要請して伝達する過程をＲＥＳＴｆｕｌ基盤で行うので、次のような経路情報形式を使用し、各情報形式はＸＳＤ（ＸＭＬＳｃｈｅｍａＤｅｆｉｎｉｔｉｏｎ）として定義可能である。

１）ＴｒｉｐＳｔｒｕｃｔｕｒｅ（トリップ構造）：最初の端末が使用者から経路設定のために伝達を受けた情報であって、基本的に出発地と目的地などの情報を獲得した後、該当の情報をサーバーに伝達する。トリップ構造は、多数の経路構造に該当する部分集合からなる。

２）ＲｏｕｔｅＳｔｒｕｃｔｕｒｅ（経路構造）：トリップ構造を通じて計算された全体の経路を表現する方式であって、経路構造は、多数のセグメントで表現される。

３）ＳｅｇｍｅｎｔＳｔｒｕｃｔｕｒｅ：各セグメントを表現する構造体であって、各セグメントの長さのみならず、該当のセグメントに該当するリアルタイム交通状況を（ＴＰＥＧ）の表現基盤で定義することができる。

図２は、従来のＤｙｎＮａｖシステムにおけるスマートＮＤ（ＳｍａｒｔＮＤ）の動作を示したフローチャートである。スマートＮＤは、端末自体の性能が経路計算をサポートするので、使用者が定義した旅行（Ｔｒｉｐ）情報に基づいて自体経路計算を行い、その結果をサーバーに送信する。代表的な機能は、次に示す通りである。

１．スマートＮＤがＴｒｉｐ情報に基づいて経路を計算する。

２．スマートＮＤは、計算された経路をサーバーに伝達し、サーバーは、該当の経路のリアルタイム交通状況を伝達する。

３．スマートＮＤは、サーバーからリアルタイム交通情報通報（Ｎｏｔｉｆｉｃａｔｉｏｎ）サービスを受信するために伝達した経路に基づいてサービスに加入する。

図２に示したフローチャートの大略的な内容は、次に示す通りである。

１．使用者は、各旅行パラメーター（ｊｏｕｒｎｅｙｐａｒａｍｅｔｅｒ）を定義し、アプリケーションは、各パラメーターをサーバーに伝送する。サーバーは、アプリケーションに生成された「トリップ（ｔｒｉｐ）」リソースの位置で応答する（Ｔｈｅｓｅｒｖｅｒｒｅｐｌｉｅｓｗｉｔｈｔｈｅｌｏｃａｔｉｏｎｏｆｔｈｅｃｒｅａｔｅｄ “ｔｒｉｐ” ｒｅｓｏｕｒｃｅｔｏｔｈｅａｐｐｌｉｃａｔｉｏｎ．）。

ａ）サーバーは、生成された「トリップ」リソースの表現で応答することができる。この活用場合において、各行動は同等である（Ｉｎｔｈｉｓｕｓｅｃａｓｅｂｅｈａｖｉｏｒｓａｒｅｅｑｕｉｖａｌｅｎｔ．）。

２．アプリケーションは、リソース／｛ｔｒｉｐＩｄ｝／ｒｏｕｔｅｓに前記の計算された経路をアップロードする。サーバーは、各パフォーマンスパラメーター及び各トラフィックイベントに対する各リンクを含む、「経路（ｒｏｕｔｅ）」リソースの表現で応答することができる。

ａ）サーバーは、トラフィック情報（各パフォーマンスパラメーター及び各トラフィックイベント）で応答することができる。この場合、追加的なｇｅｔ動作がリソースの内容を検索（ｒｅｔｒｉｅｖｅ）するために必要である。

３．アプリケーションは、トリップ及び経路に対する通知サービスに加入する（ｓｕｂｓｃｒｉｂｅ）。

４．各トラフィックイベント及び／または各パフォーマンスパラメーターの各変更が加入された経路に対して発生する。通知リソースが生成される。

５．サーバーは、更新された各パフォーマンスパラメーター及びトラフィック情報を含むトリップ及び経路を含む、前記の変更された各リソースに対する各リンクを用いてアプリケーションに通知リソースを伝達する。

６．アプリケーションは、更新された各リソースにアクセスし、各リソースを読み取る。

７．アプリケーションは、前記の受信されたリソースを用いて新たな経路を計算することに決定する。

８．アプリケーションは、リソース／｛ｔｒｉｐＩｄ｝／ｒｏｕｔｅｓに新たに計算された経路をアップロードする。サーバーは、各経路パフォーマンス及び各イベントに対する各リンクを含む、「経路」リソースの表現で応答する。この段階は、パフォーマンス制約を満足する経路が発見されるまで数回繰り返すことができる。

９．アプリケーションは、新たに加入された経路に対する通知を追加する加入設定（ｓｕｂｓｃｒｉｐｔｉｏｎｓｅｔｔｉｎｇ）を変更するように要請する。

図３は、図２を参照して説明したスマートＮＤの動作において、目的地が第３の端末（すなわち、目的端末３４）である場合の動作を示す。

ナビゲーションサービスを行う前に、実際にナビゲーション端末（すなわち、ソース端末３１）と位置サーバー３３との間の速いＧＰＳ接続及び追加サポート情報のために、位置情報伝達プロトコルを用いて測位援助情報（Ａ／Ｄ；ＡｓｓｉｓｔａｎｃｅＤａｔａ）をソース端末と位置サーバーとの間で共有する。

Ｓ３０１：ソース端末３１が目的端末３４の位置を目的地として設定するサービスを行う。該当の過程で目的端末を明示するときは、目的端末を区分できる識別子（ｉｄｅｎｔｉｆｉｅｒ；ＩＤ）を使用する。ここで、該当の識別子には、ＩＰｖ４、ＩＰｖ６、ＭＳＩＳＤＮ、ＩＭＳＩなどの端末のグローバルに（ｇｌｏｂａｌｌｙ）固有の値が使用される。

Ｓ３０２：ソース端末は、前記の明示した目的端末の識別子値を伝達し、交通情報サーバー３２に目的端末の位置を目的地として設定するサービスを行うことを明示する。該当の過程で、サービスのために、ソース端末は自身の位置情報を交通情報サーバーに伝達する。

Ｓ３０３：交通情報サーバーは、目的端末の位置情報活用及びサービス進行に対する同意を目的端末に問い合わせて要請し、該当の要請を受諾する。該当の過程で目的端末が要請を受諾しないと、該当のサービスは行われない。

Ｓ３０４：Ｓ３０３で目的端末がサービス遂行を受諾すると、ナビゲーションサービスが開始される。

Ｓ３０５：交通情報サーバーは、ナビゲーションサービスの開始と同時に、位置サーバー３３を通じて目的端末の位置情報を要請する。

Ｓ３０６：位置サーバーは、交通情報サーバーの要請に応じて目的端末の位置情報を獲得する。

Ｓ３０７：位置サーバーは、Ｓ３０６で獲得した目的端末の位置を交通情報サーバーに伝送する。

Ｓ３０８：交通情報サーバーは、Ｓ３０７で獲得した目的端末の位置情報をソース端末に伝達する。これと同時に、部分交通情報が提供され得るが、部分交通情報は、基本的にＳ３０２でソース端末が伝達したソース端末の位置とＳ３０７で位置サーバーが伝達した目的端末の位置に基づいて、出発地付近（一定半径以内）には詳細交通情報（ＰｅｒｆｏｒｍａｎｃｅＰａｒａｍｅｔｅｒ）と出発地から目的地までの交通イベント情報（ＴｒａｆｆｉｃＥｖｅｎｔ）を伝達することを意味する。

Ｓ３０９：Ｓ３０８で受信した目的端末の位置と部分交通情報に基づいて、ソース端末は最適な経路を計算する。

Ｓ３１０：ソース端末は、Ｓ３０９で獲得した経路を交通情報サーバーに登録する。交通情報サーバーに登録する理由は、ソース端末が登録された経路に基づいた現在の交通状況と追加的に前記の登録された経路に基づいた該当の経路の交通状況変化（すなわち、交通情報＝詳細交通情報＋交通イベント情報）を交通情報サーバーから受け取るためである。

Ｓ３１１：交通情報サーバーは、前記の登録された経路情報の現在の交通状況をソース端末に伝達する。その理由は、基本的にソース端末が該当の経路に対する予想到着時間を計算できるようにするためである。基本的に、Ｓ３０８で経路内の交通事故や工事などの情報を伝達するので、経路の再計算は行われない。

Ｓ３１２：位置サーバーは、目的端末の位置を指定された周期（時間的な周期）に基づいて追跡し、該当の位置情報を交通情報サーバーに伝達したり、目的端末の位置を持続的に追跡し、移動した距離を満足する場合のみに該当の位置情報を交通情報サーバーに伝達することができる。該当の方式は、サービスの形態や具現の形態によって異なり得る。

Ｓ３１３：交通情報サーバーは、前記の受信された目的端末の位置をソース端末に伝達する。

Ｓ３１４：ソース端末は、前記の受信された目的端末の位置に基づいて経路を再計算（または再探索）する。経路を再計算した後は、Ｓ３０９に戻り、Ｓ３０９〜Ｓ３１４過程を繰り返す。

一方、図２及び図３と関連して説明した従来のＤｙｎＮａｖシステムのスマートＮＤは、いくつかの問題を有している。

１）指定された周期に基づいて動作する場合の問題

時間的周期で位置サーバーが目的端末の位置を持って来て、該当の情報をソース端末に伝達する場合、例えば、５分単位で位置サーバーが目的端末の位置を持って来ると仮定し、該当の５分間ソース／目的端末の位置が大きく変わっていないと仮定する。このような状況で５分の周期が訪れて目的端末の位置をソース端末が獲得し、該当の獲得した位置に基づいて経路を再計算したとき、前記の再計算された経路は、基本的に既存の経路と大きく変わらないこともある。この場合は、不要に経路を再計算した場合であって、その結果、データ処理及び送受信にオーバーヘッドが発生する。

２）経路再計算をソース端末が決定することに対する問題

ソース端末は、基本的に交通状況情報を有しておらず、自身の位置と目的端末の位置のみを用いて経路再計算を決定し、このような決定過程は、実際の交通状況をより詳細に反映しないこともあるという問題を有する。すなわち、目的端末の現在の位置が既存の経路にない場合、既存の経路から目的端末の現在の位置までの交通状況情報がないので、再計算された経路は、実際の交通状況を完全に反映していない経路である可能性が非常に高い。

本発明では、上述した従来に提案されたサービスの形態で発生する問題、すなわち、経路再計算の非効率性及び短所を解消するための方式を提案することを主要な目的とする。

本発明で達成しようとする技術的課題は、技術的課題に制限されず、言及していない更に他の技術的課題は、下記の記載から本発明の属する技術分野で通常の知識を有する者に明確に理解され得るだろう。

本発明の一実施例に係る交通情報（ｔｒａｆｆｉｃｉｎｆｏｒｍａｔｉｏｎ）を用いて出発地と目的地で識別される旅行（ｔｒｉｐ）の経路の再計算が必要であるか否かを決定するための方法であって、前記方法は、サーバーによって行われ、端末が以前に報告された位置から特定の距離だけ移動すると、前記端末から前記端末の現在の位置を受信する段階、前記目的地が第３者の識別子（ｉｄｅｎｔｉｆｉｅｒ；ＩＤ）として定義される前記第３者の位置であると、前記第３者の現在の位置を獲得する段階、及び前記の獲得された第３者の現在の位置に基づいた特定の条件によって前記経路の再計算が必要であるか否かを決定する段階を含み、前記特定の条件は、（１）前記第３者が以前に報告された位置から予め決定された距離以上を移動した場合、または（２）前記第３者が前記以前に報告された位置から予め定義された距離以上に移動しておらず、前記端末の現在の位置と前記第３者の現在の位置との間の距離がしきい値未満である場合であって、前記特定の条件のうち一つが満足されると、前記経路の再計算が必要であると決定することができる。

好ましくは、前記経路の再計算が必要であると決定されると、前記方法は、前記の獲得された第３者の現在の位置及び現在進行中の経路に関する更新された交通情報を前記端末に伝送する段階を含むことができる。

好ましくは、前記端末は、前記の獲得された第３者の現在の位置及び現在進行中の経路に関する更新された交通情報に基づいて前記経路を再計算するように構成することができる。

好ましくは、前記端末から前記端末の現在の位置が受信されると、前記方法は、位置サーバーに前記第３者に対する位置情報を要請する段階、及び前記要請に対応して前記位置サーバーから前記第３者に対する位置情報を受信する段階を含むことができる。

好ましくは、前記経路の再計算が必要でないと決定されると、前記方法は、前記端末が前記端末の現在の位置から前記特定の距離だけ移動するまで待機する段階を含むことができる。

本発明の一実施例に係る交通情報（ｔｒａｆｆｉｃｉｎｆｏｒｍａｔｉｏｎ）を用いて出発地と目的地で識別される旅行（ｔｒｉｐ）の経路の再計算が必要であるか否かを決定するための方法であって、前記方法は、端末によって行われ、前記端末が以前に報告された位置から特定の距離だけ移動すると、前記サーバーに前記端末の現在の位置を伝送する段階、前記目的地が第３者の識別子（ｉｄｅｎｔｉｆｉｅｒ;ＩＤ）として定義される前記第３者の位置である場合、前記第３者の現在の位置に基づいた特定の条件によって前記経路の再計算が必要であると決定されると、前記サーバーから前記第３者の現在の位置及び現在進行中の経路に関する更新された交通情報を受信する段階を含み、前記特定の条件は、（１）前記第３者が以前に報告された位置から予め決定された距離以上を移動した場合、または（２）前記第３者が前記以前に報告された位置から予め定義された距離以上に移動しておらず、前記端末の現在の位置と前記第３者の現在の位置との間の距離がしきい値未満である場合であって、前記特定の条件のうち一つが満足されると、前記経路の再計算が必要であると決定することができる。

好ましくは、前記方法は、前記の受信された第３者の現在の位置及び現在進行中の経路に関する更新された交通情報に基づいて前記経路を再計算する段階を含むことができる。

好ましくは、前記経路の再計算が必要でないと決定されると、前記方法は、前記端末の現在の位置から前記特定の距離だけ移動するまで待機する段階を含むことができる。

本発明の一実施例に係る交通情報（ｔｒａｆｆｉｃｉｎｆｏｒｍａｔｉｏｎ）を用いて出発地と目的地で識別される旅行（ｔｒｉｐ）の経路の再計算が必要であるか否かを決定するように構成されたサーバーであって、端末と通信するように構成された送受信機、及び前記端末から受信される経路に対する交通情報を提供するように構成されたプロセッサを含み、前記プロセッサは、前記端末が以前に報告された位置から特定の距離だけ移動すると、前記端末から前記端末の現在の位置を受信し、前記目的地が第３者の識別子（ｉｄｅｎｔｉｆｉｅｒ;ＩＤ）として定義される前記第３者の位置であると、前記第３者の現在の位置を獲得し、そして、前記の獲得された第３者の現在の位置に基づいた特定の条件によって前記経路の再計算が必要であるか否かを決定するように構成され、前記特定の条件は、（１）前記第３者が以前に報告された位置から予め決定された距離以上を移動した場合、または（２）前記第３者が前記以前に報告された位置から予め定義された距離以上に移動しておらず、前記端末の現在の位置と前記第３者の現在の位置との間の距離がしきい値未満である場合であって、前記特定の条件のうち一つが満足されると、前記経路の再計算が必要であると決定することができる。

好ましくは、前記経路の再計算が必要であると決定されると、前記プロセッサは、前記の獲得された第３者の現在の位置及び現在進行中の経路に関する更新された交通情報を前記端末に伝送するように構成することができる。

好ましくは、前記端末から前記端末の現在の位置が受信されると、前記プロセッサは、位置サーバーに前記第３者に対する位置情報を要請し、前記要請に対応して前記位置サーバーから前記第３者に対する位置情報を受信するように構成することができる。

好ましくは、前記経路の再計算が必要でないと決定されると、前記プロセッサは、前記端末が前記端末の現在の位置から前記特定の距離だけ移動するまで待機するように構成することができる。

本発明の一実施例に係る交通情報（ｔｒａｆｆｉｃｉｎｆｏｒｍａｔｉｏｎ）を用いて出発地と目的地で識別される旅行（ｔｒｉｐ）の経路の再計算が必要であるか否かを決定するように構成された端末であって、サーバーと通信するように構成された送受信機、及び前記サーバーから受信される経路に対する交通情報及び／または目的地の位置に基づいて経路を計算するように構成されたプロセッサを含み、前記プロセッサは、前記端末が以前に報告された位置から特定の距離だけ移動すると、前記サーバーに前記端末の現在の位置を伝送し、前記目的地が第３者の識別子（ｉｄｅｎｔｉｆｉｅｒ;ＩＤ）として定義される前記第３者の位置である場合、前記第３者の現在の位置に基づいた特定の条件によって前記経路の再計算が必要であると決定されると、前記サーバーから前記第３者の現在の位置及び現在進行中の経路に関する更新された交通情報を受信するように構成され、前記特定の条件は、（１）前記第３者が以前に報告された位置から予め決定された距離以上を移動した場合、または（２）前記第３者が前記以前に報告された位置から予め定義された距離以上に移動しておらず、前記端末の現在の位置と前記第３者の現在の位置との間の距離がしきい値未満である場合であって、前記特定の条件のうち一つが満足されると、前記経路の再計算が必要であると決定することができる。

好ましくは、前記プロセッサは、前記の受信された第３者の現在の位置及び現在進行中の経路に関する更新された交通情報に基づいて前記経路を再計算するように構成することができる。

好ましくは、前記経路の再計算が必要でないと決定されると、前記プロセッサは、前記端末の現在の位置から前記特定の距離だけ移動するまで待機するように構成することができる。

前記技術的解決方法は、本発明の各実施例の一部に過ぎなく、本願発明の技術的特徴が反映された多様な実施例は、当該技術分野で通常の知識を有する者によって以下で説明する本発明の詳細な説明に基づいて導出されて理解され得る。

本発明の実施例によると、ナビゲーション装置（または応用プログラム）とサーバーとの間に発生し得る不要なデータ伝送及び伝達を減少させ、これを通じて、サービス品質及び／または使用者のサービス経験（ＱｏＥ：ＱｕａｌｉｔｙｏｆＥｘｐｅｒｉｅｎｃｅ）を高めることができる。

本発明に関する理解を促進するために詳細な説明の一部として含まれる添付の図面は、本発明に対する実施例を提供し、詳細な説明と共に本発明の技術的思想を説明する。

ナビゲーション装置に対する区分を示す図である。従来のＤｙｎＮａｖシステムにおけるスマートＮＤ（ＳｍａｒｔＮＤ）の動作を示したフローチャートである。図２に加えて、経路の目的地が移動可能な端末（すなわち、目的端末）である場合のスマートＮＤ（ＳｍａｒｔＮＤ）の動作を示したフローチャートである。本発明のナビゲーションシステムであるＩＰ基盤のＤｙｎＮａｖシステム全般を説明するためのネットワーク構成図である。ＴＰＥＧの階層構造を示す図である。本発明の一実施例に係る動作のフローチャートである。図６と関連した実施例の一例を示す図である。本発明の各実施例が具現され得る装置のブロック図である。

以下では、本発明に係る好ましい実施形態を添付の図面を参照して詳細に説明する。添付の図面と共に、以下で開示する詳細な説明は、本発明の例示的な実施形態を説明するためのものであって、本発明が実施され得る唯一の実施形態を示すためのものではない。以下の詳細な説明は、本発明の完全な理解を提供するために具体的な細部事項を含む。しかし、当業者であれば、本発明がこのような具体的な細部事項がなくても実施され得ることが分かる。

いくつかの場合、本発明の概念が曖昧になることを避けるために、公知の構造及び装置は省略したり、各構造及び装置の核心機能を中心にしたブロック図の形式で図示することができる。また、本明細書全体にわたって同一の構成要素に対しては、同一の図面符号を使用して説明する。

一方、本明細書で使用される用語について定義する。

アプリケーション（Ａｐｐｌｉｃａｔｉｏｎ）

本明細書において、アプリケーションは、使用者の代わりに業務を行う、よく定義されたが、標準化されていない各機能のセットの具現を意味する。アプリケーションは、ソフトウェア及び／またはハードウェア要素、そして、関連した使用者インターフェースからなり得る（Ａｎｉｍｐｌｅｍｅｎｔａｔｉｏｎｏｆａｗｅｌｌ―ｄｅｆｉｎｅｄｂｕｔｎｏｔｓｔａｎｄａｒｄｉｚｅｄｓｅｔｏｆｆｕｎｃｔｉｏｎｓｔｈａｔｐｅｒｆｏｒｍｓｗｏｒｋｏｎｂｅｈａｌｆｏｆｔｈｅｕｓｅｒ．Ｉｔｍａｙｃｏｎｓｉｓｔｏｆｓｏｆｔｗａｒｅａｎｄ／ｏｒｈａｒｄｗａｒｅｅｌｅｍｅｎｔｓａｎｄａｓｓｏｃｉａｔｅｄｕｓｅｒｉｎｔｅｒｆａｃｅｓ．）。

サーバー（Ｓｅｒｖｅｒ）

一般に、本発明の属する技術分野において、サーバーは、各要請に応答して各クライアントに各資源を提供するエンティティに該当する（ＡｎｅｎｔｉｔｙｔｈａｔｐｒｏｖｉｄｅｓｒｅｓｏｕｒｃｅｓｔｏＣｌｉｅｎｔｓｉｎｒｅｓｐｏｎｓｅｔｏｒｅｑｕｅｓｔｓ．）。

クライアント（Ｃｌｉｅｎｔ）

一般に、本発明の属する技術分野において、クライアントは、サービスの受信者として動作するデバイス、使用者エージェントまたは他のエンティティに該当する（Ａｄｅｖｉｃｅ，ｕｓｅｒａｇｅｎｔ，ｏｒｏｔｈｅｒｅｎｔｉｔｙｔｈａｔａｃｔｓａｓｔｈｅｒｅｃｅｉｖｅｒｏｆａｓｅｒｖｉｃｅ．）。

ＤｙｎＮａｖアプリケーション（ＤｙｎＮａｖＡｐｐｌｉｃａｔｉｏｎ）

本明細書において、ＤｙｎＮａｖは、最適な経路、リアルタイム及び未来に予想される交通情報及び補助データを得るためにＤｙｎＮａｖサーバーと相互作用する責任を有するエンティティに該当する（ＡｎｅｎｔｉｔｙｔｈａｔｉｓｉｎｃｈａｒｇｅｏｆｉｎｔｅｒａｃｔｉｎｇｗｉｔｈａＤｙｎＮａｖＳｅｒｖｅｒｔｏｇｅｔｏｐｔｉｍａｌｒｏｕｔｅ（ｓ），ｒｅａｌ―ｔｉｍｅａｎｄｆｏｒｅｃａｓｔｅｄｔｒａｆｆｉｃｉｎｆｏｒｍａｔｉｏｎａｎｄｃｏｍｐｌｉｍｅｎｔａｒｙｄａｔａ．）。したがって、ＤｙｎＮａｖアプリケーションは、スマートフォン、モバイルフォン、ナビゲーションデバイスなどを含む端末に搭載され、これによって、本明細書において、ＤｙｎＮａｖアプリケーションは、端末と相互交換可能なものと称することができる。このような側面で、ＤｙｎＮａｖアプリケーションは、クライアントの一種に該当する。本発明においては、ＤｙｎＮａｖアプリケーションをソース端末または目的端末、あるいはそのまま「端末」と称する。ソース端末は、目的端末位置基盤の経路設定サービスを要請する端末を意味し、目的端末は、該当のサービスで目的地となる個体を意味する。

ＤｙｎＮａｖサーバー（ＤｙｎＮａｖＳｅｒｖｅｒ）

本明細書において、ＤｙｎＮａｖサーバーは、アプリケーションに最適な経路、リアルタイム及び未来に予想される交通情報及び補助データを提供する責任を有するエンティティに該当する（Ａｎｅｎｔｉｔｙｔｈａｔｉｓｉｎｃｈａｒｇｅｏｆｐｒｏｖｉｄｉｎｇｔｏｔｈｅａｐｐｌｉｃａｔｉｏｎｏｐｔｉｍａｌｒｏｕｔｅ（ｓ），ｒｅａｌ―ｔｉｍｅａｎｄｆｏｒｅｃａｓｔｅｄｔｒａｆｆｉｃｉｎｆｏｒｍａｔｉｏｎ，ａｎｄｃｏｍｐｌｉｍｅｎｔａｒｙｄａｔａ．）。このような側面で、ＤｙｎＮａｖサーバーは、サーバーの一種に該当する。本発明においては、ＤｙｎＮａｖサーバーを「交通情報サーバー」または単純に「サーバー」と称する。

位置ＵＲＩ（ＬｏｃａｔｉｏｎＵＲＩ）

本明細書において、位置ＵＲＩは、位置を獲得するプロトコルを用いてデバイスの現在の位置が特定の位置サーバーから獲得されるようにするＵＲＩに該当する（ＡＵＲＩｔｈａｔｅｎａｂｌｅｓｔｈｅｃｕｒｒｅｎｔｌｏｃａｔｉｏｎｏｆａｄｅｖｉｃｅｔｏｂｅｏｂｔｉｎｅｄｆｒｏｍａｐａｒｔｉｃｕｌａｒｌｏｃａｔｉｏｎｓｅｒｖｅｒｕｓｉｎｇａｐａｒｔｉｃｕｌａｒｄｅｒｅｆｅｒｅｎｃｉｎｇｐｒｏｔｏｃｏｌ．）。

ナビゲーションデバイス（ＮａｖｉｇａｔｉｏｎＤｅｖｉｃｅ（ＮＤ））

本明細書において、ナビゲーションデバイスは、ＧＮＳＳ（ＧｌｏｂａｌＮａｖｉｇａｔｉｏｎＳａｔｅｌｌｉｔｅＳｙｓｔｅｍ）サービスを用いて最終目的地に到逹するために正しい経路を示す運転手を補助するエンティティに該当する。このエンティティは、使用者の選好度によってリアルタイム及び予測された交通情報を処理し、最適な経路を動的に推定することができる（Ａｎｅｎｔｉｔｙｔｈａｔ，ｕｓｉｎｇＧＮＳＳｓｅｒｖｉｃｅ，ａｓｓｉｓｔｓｔｈｅｄｒｉｖｅｒｓｈｏｗｉｎｇｃｏｒｒｅｃｔｒｏｕｔｅｔｏｒｅａｃｈｔｈｅｆｉｎａｌｄｅｓｔｉｎａｔｉｏｎ．Ｔｈｉｓｅｎｔｉｔｙｍａｙｐｒｏｃｅｓｓｒｅａｌ―ｔｉｍｅａｎｄｐｒｅｄｉｃｔｅｄｔｒａｆｆｉｃｉｎｆｏｒｍａｔｉｏｎａｎｄｄｙｎａｍｉｃａｌｌｙｅｓｔｉｍａｔｅｓｔｈｅｏｐｔｉｍａｌｒｏｕｔｅ，ａｃｃｏｒｄｉｎｇｔｏｕｓｅｒｐｒｅｆｅｒｅｎｃｅｓ．）。

軽量ＮＤ（ＬｉｇｈｔｗｅｉｇｈｔＮＤ）

本明細書において、軽量ＮＤは、経路計算のための機能がなく、サーバーから計算された経路を要請及び受信するナビゲーションデバイスを意味し、ローカルマップデータベースが利用可能でないと、各経路予測機能のために、そして、道路形状（ｓｈａｐｅ）表現を検索するためにサーバーにアクセスするナビゲーションデバイスに該当する（Ａｎａｖｉｇａｔｉｏｎｄｅｖｉｃｅｔｈａｔａｃｃｅｓｓｅｓｔｏａｓｅｒｖｅｒｆｏｒｒｏｕｔｅｅｓｔｍａｔｉｏｎｆｕｎｃｔｉｏｎａｌｉｔｉｅｓａｎｄｆｏｒｒｅｔｒｅｉｖｉｎｇｒｏａｄｓｓｈａｐｅｒｅｐｒｅｓｅｎｔａｔｉｏｎ，ｉｆｎｏｔａｖａｉｌａｂｌｅｉｎａｌｏｃａｌｍａｐｄａｔａｂａｓｅ．）。

スマートＮＤ（ＳｍａｒｔＮＤ）

本明細書において、スマートＮＤは、デバイス自体で利用可能な道路ネットワークデータベースを用いて経路を計算できるナビゲーションデバイスに該当する（Ａｎａｖｉｇａｔｉｏｎｄｅｖｉｃｅｔｈａｔｉｓａｂｌｅｔｏｃａｌｃｕｌａｔｅｔｈｅｒｏｕｔｅ（ｓ），ｕｓｉｎｇａｒｏａｄｓｎｅｔｗｏｒｋｄａｔａｂａｓｅａｖａｉｌａｂｌｅｏｎｔｈｅｄｅｖｉｃｅｉｔｓｅｌｆ．）。

関心ポイント（ＰｏｉｎｔＯｆＩｎｔｅｒｅｓｔ；ＰＯＩ）

本明細書において、関心ポイントは、名前、カテゴリー、固有識別子または市内住所などの各位置に関する情報を説明する（ＰＯＩｄｅｓｃｒｉｂｅｓｉｎｆｏｒｍａｔｉｏｎａｂｏｕｔｌｏｃａｔｉｏｎｓｓｕｃｈａｓｎａｍｅ，ｃａｔｅｇｏｒｙ，ｕｎｉｑｕｅｉｄｅｎｔｉｆｉｅｒ，ｏｒｃｉｖｉｃａｄｄｒｅｓｓ．）。

セグメント（Ｓｅｇｍｅｎｔ）

道路を区分する単位であって、一般道路では各交差路間の連続した道路をセグメントといい、高速道路では、各高速道路の政策によって道路を分けてセグメントと定義する。このようなセグメント単位で交通の停滞や通過時間などを決定することができる。本明細書においては、セグメントを道路区間と相互互換可能に使用する。

セグメントシーケンス（ＳｅｇｍｅｎｔＳｅｑｕｅｎｃｅ）

一つ以上の連続したセグメントの集合を称する。必要に応じて、一つのセグメントで構成されたセグメントシーケンスも可能である。また、例えば、二つ以上のセグメントで構成されたセグメントシーケンスは、１番目のセグメントの終了ポイントが２番目のセグメントの開始ポイントと同一である。

ポリライン（Ｐｏｌｙｌｉｎｅ）

本明細書において、ポリラインは、各セグメントの各端点を特定することによって定義された、一つ以上の線セグメントで構成されたグラフィックコンピューティングに使用される連続線に該当する（Ａｃｏｎｔｉｎｕｏｕｓｌｉｎｅｕｓｅｄｉｎｇｒａｐｈｉｃｃｏｍｐｕｔｉｎｇｃｏｍｐｏｓｅｄｏｆｏｎｅｏｒｍｏｒｅｌｉｎｅｓｅｇｍｅｎｔｓ，ｄｅｆｉｎｅｄｂｙｓｐｅｃｉｆｙｉｎｇｔｈｅｅｎｄｐｏｉｎｔｓｏｆｅａｃｈｓｅｇｍｅｎｔ．）。

経路情報（ＲｏｕｔｅＩｎｆｏｒｍａｔｉｏｎ）

本明細書において、経路情報は、定義された出発地から目的地までのセグメントの集合及び補助データの各座標の情報に該当する（Ｉｎｆｏｒｍａｔｉｏｎｗｈｉｃｈｃｏｏｒｄｉｎａｔｅｓｏｆｓｅｇｍｅｎｔｅｎｄｐｏｉｎｔｓａｎｄｃｏｍｐｌｉｍｅｎｔａｒｙｄａｔａｆｒｏｍｔｈｅｄｅｆｉｎｅｄｏｒｉｇｉｎａｎｄｔｈｅｄｅｓｔｉｎａｔｉｏｎ）。

交通情報（ＴｒａｆｆｉｃＩｎｆｏｒｍａｔｉｏｎ）

本明細書において、交通情報は、領域または経路と関連した各交通イベント及び各ネットワークパフォーマンスパラメーターで構成された情報に該当する（Ｉｎｆｏｒｍａｔｉｏｎｗｈｉｃｈｃｏｎｓｉｓｔｓｏｆｔｒａｆｆｉｃｅｖｅｎｔｓａｎｄｎｅｔｗｏｒｋｐｅｒｆｏｒｍａｎｃｅｐａｒａｍｅｔｅｒｓｒｅｌａｔｅｄｔｏａｎａｒｅａｏｒａｒｏｕｔｅ．）。また、交通情報は、現在またはこれから発生する、すなわち、未来の交通情報を含むことができる。

交通イベント（ＴｒａｆｆｉｃＥｖｅｎｔ）

本明細書において、交通イベントは、道路ネットワーク運営者によって賦課または計画された領域または経路と関連した各イベント（すなわち、道路閉鎖を誘発する各道路工事）またはネットワーク運営者の制御外的に発生する各イベント（すなわち、各事故）に関する情報に該当する（Ｉｎｆｏｒｍａｔｉｏｎｒｅｇａｒｄｉｎｇｅｖｅｎｔｓｒｅｌａｔｅｄｔｏａｎａｒｅａｏｒａｒｏｕｔｅｔｈａｔａｒｅｅｉｔｈｅｒｉｍｐｏｓｅｄｏｒｐｌａｎｎｅｄｂｙｔｈｅｒｏａｄｎｅｔｗｏｒｋｏｐｅｒａｏｒ（ｉ．ｅ．ｒｏａｄｗｏｒｋｓｌｅａｄｉｎｇｔｏｌａｎｅｃｌｏｓｕｒｅｓ）ｏｒｅｖｅｎｔｓｔｈａｔｏｃｃｕｒｏｕｔｓｉｄｅｔｈｅｃｏｎｔｒｏｌｏｆｔｈｅｎｅｔｗｏｒｋｏｐｅａｔｏｒ（ｉ．ｅ．ａｃｃｉｄｅｎｔｓ）．）。

ネットワークパフォーマンスパラメーター（ＮｅｔｗｏｒｋＰｅｒｆｏｒｍａｎｃｅＰａｒａｍｅｔｅｒ）

本明細書において、ネットワークパフォーマンスパラメーターは、領域または経路に存在する各セグメントのパフォーマンスまたは交通の流れ（すなわち、速度、遅延及び所要時間）に関する情報に該当する（Ｉｎｆｏｒｍａｔｉｏｎｒｅｇａｒｄｉｎｇｔｈｅｐｅｒｆｏｒｍａｎｃｅｓ（ｉ．ｅ．ｓｐｅｅｄ，ｄｅｌａｙａｎｄｔｒａｖｅｌｔｉｍｅ）ｏｆｒｏａｄｓｅｇｍｅｎｔｓｒｅｌａｔｅｄｔｏａｎａｒｅａｏｒａｒｏｕｔｅ．）。

全体の経路情報（ＲｏｕｔｅＩｎｆｏｒｍａｔｉｏｎｉｎＦｕｌｌＦｏｒｍａｔ）

出発地から目的地までの全てのセグメントを含む経路情報の一形態を意味する。別途の言及がない場合、経路情報は全体の経路を意味する。

要約経路情報（ＲｏｕｔｅＩｎｆｏｒｍａｔｉｏｎｉｎＳｕｍｍａｒｉｚｅｄＦｏｒｍａｔ）

出発地から目的地までの全てのセグメントのうち情報の要約のために選択されたセグメント（選択する方式は本発明で取り扱わない）のみを含む経路情報の一形態を意味する。

本発明は、リアルタイム交通情報を反映するナビゲーションシステム、方法及び装置に関し、より詳細には、リアルタイム交通情報を提供するシステムでナビゲーション装置が、自ら経路計算が可能であり、移動通信網と連結され得る通信モデムを有している場合、最小限の通信帯域幅を使用し、リアルタイム交通情報に基づいた経路計算及び／または計算された経路をサーバーに伝送するためのナビゲーションシステム、方法及び装置に関する。最近、スマートフォンの活発な普及と共に、既存のＤＭＢ放送網を用いていた形式から逸脱し、移動通信端末機に移動経路を提供するナビゲーションサービスが普遍化されており、ＯＭＡＬＯＣＷＧでは、前記のようなサービスをＤｙｎＮａｖ（ＤｙｎａｍｉｃＮａｖｉｇａｔｉｏｎ）と称する。

本明細書において、ナビゲーション装置とは、経路案内機能を行える装置を称し、ナビゲーション装置は、スマートフォン、モバイルフォン、モバイルデバイス、ラップトップ、タブレットＰＣ、スマートパッドなどのように、携帯可能であるか、携帯可能な物体に付着可能な全ての電子的装置を含む。

図４は、本発明のナビゲーションシステムであるＩＰ基盤のＤｙｎＮａｖシステム全般を説明するためのネットワーク構成図である。図４に示したように、本発明のナビゲーションシステムは、移動通信網接続が可能なナビゲーション装置（ＮａｖｉｇａｔｉｏｎＤｅｖｉｃｅ、ＮＤ）、無線送受信のための移動通信網、交通情報を提供するために交通情報収集装置、交通情報及び経路情報提供サーバー（ＤｙｎＮａｖＳｅｒｖｅｒ）、及びナビゲーション装置の位置獲得のための補助データ（ＡｓｓｉｓｔａｎｃｅＤａｔａ）を生成して伝達する位置サーバーを含むことができる。

簡略に表現するために、本明細書において、交通情報提供サーバーまたはＤｙｎＮａｖサーバーは、「サーバー」と表現し、ナビゲーション装置は、「端末」、「ＮＤ」または各端末の能力による「ＳｍａｒｔＮＤ」や「ＬｉｇｈｔｗｅｉｇｈｔＮＤ」と表現する。

本発明において、端末（上述したように、２つの端末の形態に区分可能である）は、図面に示したように、移動通信網またはＷｉ―ＦｉなどのＩＰ網との連結が可能であり、経路案内のためのナビゲーションアプリケーションを備えており、該当のアプリケーションは、サーバーに接続して経路案内データとリアルタイム交通情報を受信し、経路を案内することができる。一方、図面には別途に示していないが、経路計算が自体的に可能な端末は、サーバーから経路案内データを受信せず、リアルタイム交通情報のみを選択的に受信することができる。

ここで、リアルタイム交通情報とは、ＤｙｎＮａｖサーバーで計算され、端末に伝達される最適な経路情報、リアルタイム及び予測交通情報、ＰＯＩ（ＰｏｉｎｔｏｆＩｎｔｅｒｅｓｔ）と天気などの交通と関連した付加情報を意味する。また、表現の重複を除去するために、ナビゲーションアプリケーションや端末を統合して端末と表現する。したがって、本明細書において、「端末」、「ＮＤ」、「ＳｍａｒｔＮＤ」、「ＬｉｇｈｔｗｅｉｇｈｔＮＤ」と「ナビゲーションアプリケーション」は、いずれも「端末」と称することができる。

上述したリアルタイム交通情報は、ＩＳＯ標準化団体で推進されているＴＰＥＧ（ＴｒａｎｓｐｏｒｔＰｒｏｔｏｃｏｌＥｘｐｅｒｔｓＧｒｏｕｐ）を通じて表現することができる。ここで、ＴＰＥＧとは、デジタル放送網を介して交通及び旅行情報を伝送する標準プロトコルを意味する。図５に表現したように、ＴＰＥＧの階層構造は、ＩＳＯ／ＯＳＩＬａｙｅｒモデルのネットワーク階層（第３の階層）からアプリケーション階層（第７の階層）に対応する。ネットワーク階層は、ＴＰＥＧフレーム同期及びルーティングを定義し、第４、第５及び第６の階層のパケット化階層では、各アプリケーションの各コンポーネントが一つのストリームに併合され、それぞれのメッセージ規格は、応用階層である第７の階層に該当する。ＤｙｎＮａｖでは、ＴＰＥＧのリアルタイム交通情報表現方式に従ってリアルタイム交通情報を端末に提供することができ、別途の表現方式を使用することができる。

図６は、本発明の一実施例に係る動作のフローチャートである。図６で適用される端末は、スマートＮＤに該当する。スマートＮＤは、自体的に経路を計算する前にサーバーから交通情報を受信することができる。端末は、最初のナビゲーション使用者から出発地及び目的地などの旅行構造（ＴｒｉｐＳｔｒｕｃｔｕｒｅ）情報を獲得し、これに基づいて経路を計算する前にサーバーに旅行構造を伝送し、関連経路上の交通情報を受信する。図６のフローチャートを詳細に説明すると、次に示す通りである。

ナビゲーションサービスを行う前に、実際にナビゲーション端末（すなわち、ソース端末３１）と位置サーバー３３との間の速いＧＰＳ接続及び追加サポート情報のために、位置情報伝達プロトコルを用いて測位補助情報（Ａ／Ｄ；ＡｓｓｉｓｔａｎｃｅＤａｔａ）をソース端末と位置サーバーとの間で共有する。

ソース端末３１は、目的端末３４の位置を目的地として設定するサービス（すなわち、第３者位置追跡（ｔｈｅ３^rd ｐａｒｔｙｔｒａｃｋｉｎｇ））を行うために、目的端末の位置を経路の目的地として設定することができる（Ｓ６０１）。該当の過程で目的端末を明示するときは、目的端末を区分できる識別子（ｉｄｅｎｔｉｆｉｅｒ；ＩＤ）を使用する。ここで、該当の識別子には、ＩＰｖ４、ＩＰｖ６、ＭＳＩＳＤＮ、ＩＭＳＩなどの端末のグローバルな固有値が使用される。

ソース端末は、前記の明示した目的端末の識別子値を伝達し、交通情報サーバー３２に目的端末の位置を目的地として設定するサービスを行うことを明示することができる（Ｓ６０２）。該当の過程で、サービスのために、ソース端末は、自身の位置情報を交通情報サーバーに伝達することができる。

交通情報サーバーは、目的端末の位置情報活用及びサービス進行に対する同意を目的端末に問い合わせて要請し、該当の要請を受諾する応答を受信することができる（Ｓ６０３）。該当の過程で、目的端末が要請を受諾しないと、該当のサービスは行われない。

Ｓ６０３において、目的端末が要請を受諾すると、ナビゲーションサービスが開始される（Ｓ６０４）。

交通情報サーバーは、ナビゲーションサービスの開始と同時に、位置サーバー３３を介して目的端末の位置情報を要請することができる（Ｓ６０５）。

位置サーバーは、交通情報サーバーの要請に応じて目的端末の位置情報を獲得することができる（Ｓ６０６）。位置サーバーは、Ｓ６０６で獲得した目的端末の位置を交通情報サーバーに伝送することができる（Ｓ６０７）。

交通情報サーバーは、Ｓ６０７で獲得した目的端末の位置情報をソース端末に伝達することができる（Ｓ６０８）。これと同時に、交通情報サーバーは、部分交通情報をソース端末に伝送できるが、部分交通情報は、基本的にＳ６０２でソース端末が伝達したソース端末の位置とＳ６０７で位置サーバーが伝達した目的端末の位置に基づいて、出発地付近（例えば、出発地から一定半径以内）には詳細交通情報（ＰｅｒｆｏｒｍａｎｃｅＰａｒａｍｅｔｅｒ）と出発地から目的地までの交通イベント情報（ＴｒａｆｆｉｃＥｖｅｎｔ）を伝達することを意味する。

Ｓ６０８で受信された目的端末の位置と部分交通情報に基づいて、ソース端末は、最適な経路を計算することができる（Ｓ６０９）。ソース端末は、Ｓ６０９で獲得された経路を交通情報サーバーに登録することができる（Ｓ６１０）。交通情報サーバーに登録する理由は、ソース端末が登録された経路に基づいた現在の交通状況と追加的に前記の登録された経路に基づいた該当の経路の交通状況変化を交通情報サーバーから受け取るためである。

交通情報サーバーは、登録された経路の現在の交通状況をソース端末に伝達することができる（Ｓ６１１）。その理由は、基本的にソース端末が該当の経路に対する予想到着時間を計算するためである。基本的に、Ｓ６０８で経路内の交通事故や工事などの情報が伝達されたので、Ｓ６１１による経路再計算は行われない。

ソース端末がナビゲーションサービスを行った後、一定距離を移動したか否かを判断することができる（Ｓ６１２）。ソース端末は、自らソース端末が搭載された移動体（例えば、車両）が移動することを把握できるので、一定距離を移動した場合は次の段階に進行し、そうでない場合は、一定距離を移動するまで本段階を繰り返す。すなわち、本発明の一実施例は、ソース端末が一定距離を運行する度に、本段階を含むその後の各段階（すなわち、Ｓ６１３〜Ｓ６１８）が行われるように構成される。換言すると、Ｓ６１２は、本発明の一実施例の後述する手順をトリガリングするための手順であり得る。

一定距離を移動したソース端末は、自身の位置を交通情報サーバーに提供することができる（Ｓ６１３）。ソース端末が自身の位置を報告する理由は、次に示す通りである。

１．既に進行した経路は、これ以上管理される必要がないためである。すなわち、Ｓ６１３でのソース端末の位置報告により、交通情報サーバーで管理中の経路のサイズを減少させ、サーバーの負荷を減少させることができる。また、経路のサイズを減少させることによって、それに伴う交通状況情報も減少し得る。

２．ソース端末が一定距離を移動したので、それによって目的端末の位置を確認し、追加経路の計算過程が必要であるか否かを把握するためである。また、ソース端末が一定距離を移動すると共に、目的端末も一定距離を移動することができる。すなわち、本発明の一実施例は、出発地と目的地の位置が動的に変更され得るので、周期的にソース端末の位置または目的端末の位置を報告または獲得する必要がある。

この場合、上述したソース端末の移動の代わりに、目的端末の位置の移動による以下の動作を考慮することもできる。しかし、ナビゲーションサービスを受ける主体はソース端末であって、目的端末は時間によって移動しないこともあり、ソース端末が移動していない場合は、少なくとも変更されていないソース端末の位置で以前に報告された目的端末までの経路はそのまま有効であるので、ソース端末の移動を基準にして本発明の一実施例の以下の動作をトリガリングさせることが好ましい。

Ｓ６１３でソース端末の現在の位置が受信されると、交通情報サーバーは、位置サーバーを介して目的端末の現在の位置情報を要請することができる（Ｓ６１４）。これは、経路再計算（再探索）が必要であるか否かを決定するのに使用される情報、すなわち、目的端末の現在の位置を得るためである。後述するように、目的端末の現在の位置によって経路の再計算が必要であるか否かを決定することができる。これは、以前のＳ６１２でソース端末が一定距離だけ移動した場合に発生し得る手順であって、既にＳ６１２でソース端末の位置移動は確認されたので、経路計算に（目的地の位置として）必要な目的端末の現在の位置を獲得するためであると理解することができる。

位置サーバーは、交通情報サーバーの要請に応じて目的端末の現在の位置情報を獲得することができる（Ｓ６１５）。位置サーバーは、Ｓ６１５で獲得された目的端末の位置を交通情報サーバーに伝送することができる（Ｓ６１６）。

交通情報サーバーは、Ｓ６１３で獲得されたソース端末の現在の位置とＳ６１６で獲得された目的端末の現在の位置に基づいて経路再計算が必要であるか否かを判断することができる（Ｓ６１７）。

実際の経路再計算動作はソース端末で実行されるが（ソース端末は、以前に仮定したようにスマートＮＤであるので、自体的に経路を探索／計算する）、交通情報サーバーは経路再計算が必要であるか否かを把握し、これは、次のような理由を伴う。

ソース端末は、経路を探索／計算できる性能（ｃａｐａｂｉｌｉｔｙ）は有するが、経路に対する交通状況を知ることはできない。本発明の一実施例では、交通情報サーバーが交通状況に対する情報を把握しているので、１）目的端末の位置、２）進行されたナビゲーションサービスの基準を有して目的端末の位置を伝達するとき、ソース端末の速い追加経路情報の獲得のために必要な交通情報を提供できるという特徴を有することができる。

より具体的に、Ｓ６１７では、次のような条件に基づいて経路再計算が必要であるか否かを区分する。

条件１．目的端末が以前に報告された位置で一定距離以上移動した場合

条件２．ソース端末と目的端末との距離が一定距離未満に狭まれた場合

条件１と２は、次のようにまとめることができる。

経路の再計算は、次のような特定の条件下で必要である：（１）第３者（すなわち、目的端末）が以前に報告された位置から一定距離以上移動した場合、または（２）目的端末が以前に報告された位置から特定の距離以上移動しないが、ソース端末と目的端末との間の距離がしきい値より近い場合（Ｔｈｅｒｅ―ｒｏｕｔｉｎｇｉｓｒｅｑｕｉｒｅｄｕｎｄｅｒｔｈｅｓｐｅｃｉｆｉｃｃｏｎｄｉｔｉｏｎｓ：（１）ｔｈｅ３ｒｄｐａｒｔｙｍｏｖｅｓｏｖｅｒａｃｅｒｔａｉｎｄｉｓｔａｎｃｅｆｒｏｍｐｒｅｖｉｏｕｓｌｙｒｅｐｏｒｔｅｄｐｏｓｉｔｉｏｎｏｆｔｈｅ３ｒｄｐａｒｔｙｏｒ（２）ｔｈｅ３ｒｄｐａｒｔｙｄｏｅｓｎｏｔｍｏｖｅａｃｅｒｔａｉｎｄｉｓｔａｎｃｅｂｕｔｔｈｅｄｉｓｔａｎｃｅｂｅｔｗｅｅｎＤｙｎＮａｖａｐｐｌｉｃａｔｉｏｎａｎｄｔｈｅ３ｒｄｐａｒｔｙｉｓｃｌｏｓｅｒｔｈａｎａｔｈｒｅｓｈｏｌｄｖａｌｕｅ．）

追加的には、

条件３．ソース端末と目的端末との間の経路の交通状況に大きな変化が生じた場合

があり得る。

交通情報サーバーがＳ６１７でソース端末の経路再計算が必要であると判断する場合、交通情報サーバーは、ソース端末に目的端末の現在の位置情報と現在進行中の経路（すなわち、以前の経路）に対する更新された交通状況に対する情報を伝達することができる（Ｓ６１８）。該当の手順を全て行うと、再びＳ６１９段階に進行し、ソース端末が目的端末の位置に到逹するまで該当のサービス過程を繰り返す。

交通状況に対する情報は、ソース端末から目的端末までの必要な詳細な交通情報（ＰｅｒｆｏｒｍａｎｃｅＰａｒａｍｅｔｅｒ）または詳細でない交通情報（ＴｒａｆｆｉｃＥｖｅｎｔ）を全て含む。含む条件は、別途に明示せず、交通情報サーバーが必要に応じて設定することができる。

交通情報サーバーがＳ６１７でソース端末の経路再計算が必要でないと判断する場合、本発明の一実施例は、Ｓ６１２に戻り、再びソース端末が一定距離を移動するまで待機する。

図７は、図６に示した本発明の一実施例に係るより詳細な動作のフローチャートである。アプリケーション７１０は、上述したように、ＤｙｎＮａｖアプリケーションに該当し、「端末」と称することができる。したがって、図７と関連した説明において、アプリケーションを「端末」と称することにする。また、サーバー７２０は、上述したように、ＤｙｎＮａｖサーバーに該当する。

１．ＰＯＳＴ：ｃｒｅａｔｅｔｒｉｐｄｅｓｃｒｉｐｔｉｏｎ

端末７１０は、ＰＯＳＴ命令を用いて端末の使用者によって定義された各旅行パラメーター、すなわち、出発地、目的地または別途の情報を通じて旅行ディスクリプション（ｔｒｉｐｄｅｓｃｒｉｐｔｉｏｎ）を生成することができる。これに応答し、サーバー７２０は、旅行ディスクリプションに対応する旅行を生成し、それに対する識別子（ＩＤ）と定義された各パラメーターを端末に伝送することができる。

２．ＰＯＳＴ：ｃｒｅａｔｅａｒｅａｄｅｓｃｒｉｐｔｉｏｎ

端末は、旅行の出発地と目的地で識別される旅行と関連した交通情報を要請するために、ＰＯＳＴ命令を用いて領域ディスクリプション（ａｒｅａｄｅｓｃｒｉｐｔｉｏｎ）を生成することができる。帯域幅及び動作の最適化のために、サーバーは、二つの類型の交通情報で応答することができる。

ａ）出発地近隣に深刻な混雑がある場合、出発地近隣の各パフォーマンスパラメーター、換言すると、本明細書において、（ネットワーク）パフォーマンスパラメーターは、領域または経路を示すセグメントのパフォーマンスまたは交通の流れ（すなわち、速度、遅延及び所要時間）に関する情報を意味し、「２．ＰＯＳＴ：ｃｒｅａｔｅａｒｅａｄｅｓｃｒｉｐｔｉｏｎ」においてサーバーによって応答されるものは、出発地から一定半径内の領域または経路内の各パフォーマンスパラメーターであって、これら各パフォーマンスパラメーターは、一定半径内の領域または経路内に一定程度水準以上の混雑がある場合にサーバーによって提供することができる。

ｂ）旅行と関連した領域に対する各交通イベント

３．ＧＥＴ：ｒｅｑｕｅｓｔｔｈｅｔｒａｆｆｉｃｉｎｆｏｒｍａｔｉｏｎ

端末は、ＧＥＴ命令を用いてサーバーによって提供された交通情報を読み取ることができる。この交通情報は、（各事故、工事または道路混雑によって影響される）重要な各道路区間を回避しようと努力しながら、前記の定義された旅行に対する経路を推定または計算するために端末によって使用することができる。

４．ＰＯＳＴ：ｃｒｅａｔｅａｒｏｕｔｅｃａｌｃｕｌａｔｅｄｂｙａｐｐｌｉｃａｔｉｏｎ

端末は、ＰＯＳＴ命令を用いてサーバーに（端末によって計算された各経路から選ばれた）推定された経路をアップロードすることができる。サーバーは、各パフォーマンスパラメーターと各交通イベントへの各リンクを含む、「経路」資源の表現で応答することができる。

５．ＰＯＳＴ：ｓｕｂｓｃｒｉｐｔｉｏｎｔｏｔｈｅｔｒｉｐ

端末は、ＰＯＳＴ命令を用いて段階２で選択された領域に対する、そして、段階３で定義された旅行に対する通知サービスに加入することができる。端末は、前記の選択された領域及び旅行に対してアップロードされた全ての経路と関連した各パフォーマンスパラメーター及び各交通イベントに対する新規情報をサーバーから受け取ることができる。

６．ＰＵＴ：ｕｐｄａｔｅｔｈｅｔｒｉｐｐａｒａｍｅｔｅｒ

端末は、旅行リソースの出発地パラメーターを修正するために、ＰＵＴ命令を用いて自身の現在の位置を周期的にアップデートすることができる。この動作は、端末が付着した車両が以前の報告された位置から特定の距離だけ移動した場合にトリガリングされ、サーバーは、経路情報から既に運行された道路区間を削除するためにこの情報を活用することができる。

目的地が第３者の位置（すなわち、目的端末の位置）に設定されると、サーバーは、第３者の現在の位置を獲得し、端末によって経路の再計算が必要であるか否かを決定することができる。経路の再計算は、上述した各条件のうち一つ、すなわち、第３者が以前に報告された位置から一定距離以上移動した場合、第３者が以前に報告された位置から特定の距離以上移動していないが、端末と第３者との距離がしきい値より近い場合、または端末と第３者との間の経路の交通状況に大きな変化が生じた場合のうち一つが満足されると、経路の再計算が必要であると決定される。

７．ＰＯＳＴ：ｎｏｔｉｆｉｃａｔｉｏｎｕｎｄｅｒＣａｌｌＢａｃｋＮｏｔｉｆＵＲＬ

提案された各経路に沿って各交通イベント及び／または深刻な混雑がサーバーによって検出された場合、または、目的地が第３者の位置である場合に再計算が必要であると、サーバーは端末に通知することができる。サーバーは、端末によって特定されるリンクを通じてＰＯＳＴ命令を用いて現在の経路に対するアップデートされた交通情報及び／またはアップデートされた第３者の位置を提供することができる。

一方、目的地が第３者の位置である場合、第３者の位置が変更されると、端末が前記の変更された第３者の位置に基づいた代案経路を推定できるように、サーバーは、追加的な交通情報（例えば、前記の変更された第３者の位置と以前に報告された第３者の位置との間の交通情報）を提供することができる。

８．ＧＥＴ：ｒｅｑｕｅｓｔｔｈｅｔｒａｆｆｉｃｉｎｆｏｂａｓｅｄｏｎｔｈｅｎｏｔｉｆｉｃａｔｉｏｎ

端末は、ＧＥＴ命令を用いて前記の通知された経路と関連したアップデート交通情報（各交通イベント及び各パフォーマンスパラメーター）にアクセスすることができる。

９．ＰＵＴ／ＰＯＳＴ：ｍｏｄｉｆｙ／ｃｒｅａｔｅｃａｌｃｕｌａｔｅｄｒｏｕｔｅ

端末は、下記の各条件下で新たな経路を再計算することを決定することができる：

ａ）端末が段階８でアップデートされた交通情報及び／またはアップデートされた目的地を受信する。

ｂ）端末が定義された経路から逸脱または迂回したことを検出する。

端末は、端末が以前の経路を有効に維持することを望むか否かによって、存在する経路に対してＰＵＴ命令を用いたり、または新規に登録される経路に対してＰＯＳＴ命令を用いて新たに計算された経路をサーバーにアップロードすることができる。これに対して、サーバーは、各パフォーマンスパラメーターを含む「経路」資源の表現で応答することができる。

この段階は、再計算された経路の性能、すなわち、所要時間などが以前の経路より良好になるまで何回も繰り返すことができる。しかし、過程がループ（ｌｏｏｐ）に陥ることを防止するために、端末は、段階２及び３で説明した動作と類似する動作で繰り返された要請が発生した領域で交通情報を獲得するために新たな領域ディスクリプションを定義することができる。

帯域幅の最適化のために、端末は、既に定義された基準経路に対して変更された各セグメントのみをアップロードする、部分経路方式の使用を選択することができる。

１０．ＤＥＬＥＴＥ：ｒｅｓｐｏｎｓｅｔｈｅｐｒｅｖｉｏｕｓｒｏｕｔｅｒｅｓｏｕｒｃｅ

端末は、ＤＥＬＥＴＥ命令を用いて提案された一セットの経路からこれ以上使用しない以前の各経路を削除することができる。端末は、新たな経路の性能が使用中の経路より悪い場合、前記の提案された一セットの経路から新たに計算された経路を削除することができる。端末は、ＤＥＬＥＴＥを使用して通知サービスから以前の各経路の加入を解除することができる。

図８は、本発明の各実施例を具現するように構成された端末とサーバーのブロック図である。端末８１０は、サーバー８２０と通信するように構成された送受信機８１１、及びサーバーから受信される交通情報を通じて経路を計算するように構成されたプロセッサ８１２を含むことができる。サーバー８２０は、端末と通信するように構成された送受信機８２１、及び端末から受信された出発地と目的地情報などの旅行と関連したパラメーターに基づいて経路を計算したり、交通情報を収集して処理するように構成されたプロセッサ８２２を含むことができる。

図８と関連して説明する本発明の一実施例は、端末８１０がスマートＮＤである場合の実施例である。この実施例において、プロセッサ８１２は、端末が以前に報告された位置から特定の距離だけ移動すると、サーバーに端末の現在の位置を伝送することができる。また、目的地が第３者の識別子（ｉｄｅｎｔｉｆｉｅｒ;ＩＤ）と定義される第３者の位置である場合、第３者の現在の位置に基づいた特定の条件によって経路の再計算が必要であると決定されると、プロセッサ８１２は、サーバーから第３者の現在の位置及び現在進行中の経路に関する更新された交通情報を受信するように構成することができる。経路の再計算が必要であるか否かは、交通情報を管理／提供するサーバーによって決定される。

一方、特定の条件は、（１）第３者が以前に報告された位置から予め決定された距離以上を移動した場合、または（２）第３者が以前に報告された位置から予め定義された距離以上に移動しておらず、端末の現在の位置と第３者の現在の位置との間の距離がしきい値未満である場合であって、特定の条件のうち一つが満足されると、経路の再計算が必要であると決定することができる。

プロセッサ８１２は、前記の受信された第３者の現在の位置及び現在進行中の経路に関する更新された交通情報に基づいて経路を再計算するように構成することができる。

経路の再計算が必要でないと決定されると、プロセッサ８１２は、端末の現在の位置から特定の距離だけ移動するまで待機するように構成することができる。

また、本発明の一実施例において、サーバーのプロセッサ８２２は、端末が以前に報告された位置から特定の距離だけ移動すると、端末から端末の現在の位置を受信するように構成される。また、プロセッサ８２２は、目的地が第３者の識別子（ｉｄｅｎｔｉｆｉｅｒ；ＩＤ）と定義される第３者の位置であると、第３者の現在の位置を獲得し、そして、前記の獲得された第３者の現在の位置に基づいた特定の条件によって経路の再計算が必要であるか否かを決定するように構成することができる。

特定の条件と関連した説明は、上述したプロセッサ８１２と関連して説明した部分を参照することにする。

また、経路の再計算が必要であると決定されると、プロセッサ８２２は、前記の獲得された第３者の現在の位置及び現在進行中の経路に関する更新された交通情報を端末に伝送するように構成することができる。

端末から端末の現在の位置が受信されると、プロセッサ８２２は、位置サーバーに第３者に対する位置情報を要請し、要請に対応して位置サーバーから第３者に対する位置情報を受信するように構成することができる。

経路の再計算が必要でないと決定されると、プロセッサ８２２は、端末が端末の現在の位置から特定の距離だけ移動するまで待機するように構成することができる。

一方、端末またはサーバーは、上述した各実施例のうち一つまたは二つ以上の実施例の組み合わせを行うことができ、各実施例のうち一部を組み合わせたり結合することができる。

上述したように開示された本発明の好ましい各実施例に対する詳細な説明は、当業者が本発明を具現して実施できるように提供された。以上では、本発明の好ましい各実施例を参照して説明したが、該当の技術分野で熟練した当業者であれば、下記の特許請求の範囲に記載した本発明を多様に修正及び変更させ得ることを理解できるだろう。したがって、本発明は、ここで示した各実施形態に制限されるものではなく、ここで開示した各原理及び新規の各特徴と一致する最広の範囲を付与するものである。

本発明の各実施例は、ナビゲーション装置またはサーバーに適用可能である。

Claims

交通情報を用いて出発地と目的地で識別される旅行の経路の再計算が必要であるか否かを決定するための方法であって、前記方法は、サーバーによって行われ、
端末が以前に報告された位置から特定の距離だけ移動すると、前記端末から前記端末の現在の位置を受信する段階と、
前記目的地が第３者の識別子と定義される前記第３者の位置であると、前記第３者の現在の位置を獲得する段階と、
前記獲得された第３者の現在の位置に基づいた特定の条件によって前記経路の再計算が必要であるか否かを決定する段階と、を含み、
前記特定の条件は、
（１）前記第３者が以前に報告された位置から予め決定された距離以上を移動した場合、または、
（２）前記第３者が前記以前に報告された位置から予め定義された距離以上に移動しておらず、前記端末の現在の位置と前記第３者の現在の位置との間の距離がしきい値未満である場合であって、
前記特定の条件のうち一つが満足されると、前記経路の再計算が必要であると決定されることを特徴とする、経路再計算方法。
前記経路の再計算が必要であると決定されると、
前記獲得された第３者の現在の位置及び現在進行中の経路に関する更新された交通情報を前記端末に伝送する段階を含む、請求項１に記載の経路再計算方法。
前記端末は、前記獲得された第３者の現在の位置及び現在進行中の経路に関する更新された交通情報に基づいて前記経路を再計算するように構成される、請求項２に記載の経路再計算方法。
前記端末から前記端末の現在の位置が受信されると、
位置サーバーに前記第３者に対する位置情報を要請する段階と、
前記要請に対応して前記位置サーバーから前記第３者に対する位置情報を受信する段階と、を含む、請求項１に記載の経路再計算方法。
前記経路の再計算が必要でないと決定されると、前記端末が前記端末の現在の位置から前記特定の距離だけ移動するまで待機する段階を含む、請求項１に記載の経路再計算方法。
交通情報を用いて出発地と目的地で識別される旅行の経路の再計算が必要であるか否かを決定するための方法であって、前記方法は、端末によって行われ、
前記端末が以前に報告された位置から特定の距離だけ移動すると、前記サーバーに前記端末の現在の位置を伝送する段階と、
前記目的地が第３者の識別子と定義される前記第３者の位置である場合、前記第３者の現在の位置に基づいた特定の条件によって前記経路の再計算が必要であると決定されると、前記サーバーから前記第３者の現在の位置及び現在進行中の経路に関する更新された交通情報を受信する段階と、を含み、
前記特定の条件は、
（１）前記第３者が以前に報告された位置から予め決定された距離以上を移動した場合、または
（２）前記第３者が前記以前に報告された位置から予め定義された距離以上に移動しておらず、前記端末の現在の位置と前記第３者の現在の位置との間の距離がしきい値未満である場合であって、
前記特定の条件のうち一つが満足されると、前記経路の再計算が必要であると決定されることを特徴とする、経路再計算方法。
前記受信された第３者の現在の位置及び現在進行中の経路に関する更新された交通情報に基づいて前記経路を再計算する段階を含む、請求項６に記載の経路再計算方法。
前記経路の再計算が必要でないと決定されると、前記端末の現在の位置から前記特定の距離だけ移動するまで待機する段階を含む、請求項６に記載の経路再計算方法。
交通情報を用いて出発地と目的地で識別される旅行の経路の再計算が必要であるか否かを決定するように構成されたサーバーであって、
端末と通信するように構成された送受信機と、
前記端末から受信される経路に対する交通情報を提供するように構成されたプロセッサと、を含み、
前記プロセッサは、
前記端末が以前に報告された位置から特定の距離だけ移動すると、前記端末から前記端末の現在の位置を受信し、
前記目的地が第３者の識別子と定義される前記第３者の位置であると、前記第３者の現在の位置を獲得し、
前記の獲得された第３者の現在の位置に基づいた特定の条件によって前記経路の再計算が必要であるか否かを決定するように構成され、
前記特定の条件は：
（１）前記第３者が以前に報告された位置から予め決定された距離以上を移動した場合、または
（２）前記第３者が前記以前に報告された位置から予め定義された距離以上に移動しておらず、前記端末の現在の位置と前記第３者の現在の位置との間の距離がしきい値未満である場合であって、
前記特定の条件のうち一つが満足されると、前記経路の再計算が必要であると決定されることを特徴とする、サーバー。
前記経路の再計算が必要であると決定されると、
前記プロセッサは、前記獲得された第３者の現在の位置及び現在進行中の経路に関する更新された交通情報を前記端末に伝送するように構成される、請求項９に記載のサーバー。
前記端末は、前記獲得された第３者の現在の位置及び現在進行中の経路に関する更新された交通情報に基づいて前記経路を再計算するように構成される、請求項１０に記載のサーバー。
前記端末から前記端末の現在の位置が受信されると、
前記プロセッサは、位置サーバーに前記第３者に対する位置情報を要請し、前記要請に対応して前記位置サーバーから前記第３者に対する位置情報を受信するように構成される、請求項９に記載のサーバー。
前記経路の再計算が必要でないと決定されると、
前記プロセッサは、前記端末が前記端末の現在の位置から前記特定の距離だけ移動するまで待機するように構成される、請求項９に記載のサーバー。
交通情報を用いて出発地と目的地で識別される旅行の経路の再計算が必要であるか否かを決定するように構成された端末であって、
サーバーと通信するように構成された送受信機と、
前記サーバーから受信される経路に対する交通情報または目的地の位置に基づいて経路を計算するように構成されたプロセッサと、を含み、
前記プロセッサは、
前記端末が以前に報告された位置から特定の距離だけ移動すると、前記サーバーに前記端末の現在の位置を伝送し、
前記目的地が第３者の識別子と定義される前記第３者の位置である場合、前記第３者の現在の位置に基づいた特定の条件によって前記経路の再計算が必要であると決定されると、前記サーバーから前記第３者の現在の位置及び現在進行中の経路に関する更新された交通情報を受信するように構成され、
前記特定の条件は、
（１）前記第３者が以前に報告された位置から予め決定された距離以上を移動した場合、または
（２）前記第３者が前記以前に報告された位置から予め定義された距離以上に移動しておらず、前記端末の現在の位置と前記第３者の現在の位置との間の距離がしきい値未満である場合であって、
前記特定の条件のうち一つが満足されると、前記経路の再計算が必要であると決定されることを特徴とする、端末。
前記プロセッサは、前記受信された第３者の現在の位置及び現在進行中の経路に関する更新された交通情報に基づいて前記経路を再計算するように構成される、請求項１４に記載の端末。
前記経路の再計算が必要でないと決定されると、前記プロセッサは、前記端末の現在の位置から前記特定の距離だけ移動するまで待機するように構成される、請求項１４に記載の端末。