JP2013019902A - ナビゲーション・アプリケーション・インターフェース - Google Patents

Abstract

【課題】アプリケーション・プログラミング・インターフェース（ＡＰＩ）を含むナビゲーション・システムの提供。
【解決手段】ナビゲーション・ソリューション１２０とインターフェースするためのアプリケーション・インターフェースを含むナビゲーション・プラットフォーム１１０を備えるナビゲーション・システムであって、前記インターフェースが、前記ナビゲーション・ソリューションによって提供される対応する関数と協働するように適合された予め定義された関数のセットを含む、ナビゲーション・システム。
【選択図】図１

Description

この出願は、車両ナビゲーション・システムを含むナビゲーション・システムの分野に関する。より具体的には、本出願は、アプリケーション・プログラミング・インターフェース（ＡＰＩ）を含むナビゲーション・システムに関する。

ナビゲーション・システムは、ナビゲーション・アプリケーションを実行する指定された手持ち式ユニット又は移動電話のような車両搭載システム又は携帯型デバイスである場合がある。しばしば、車両ナビゲーション・システムの場合には、システムは、より大きいインフォテインメント・システムの一部であり、これは車両ユーザに娯楽サービス及び情報サービスを提供する。ナビゲーション・システムは、典型的に、ナビゲーション・プラットフォームと、ナビゲーション・ソリューションとも称される基本となるナビゲーション・コア・アプリケーションとを含む。ナビゲーション・プラットフォームは、典型的に、ハードウェア・アーキテクチャと、オペレーティング・システムを含むソフトウェア・フレームワークと、ナビゲーション・ソリューションの実行及びこれとユーザとの対話をサポートする、関連するユーザ・インターフェースとを含む。ナビゲーション・ソリューションは、典型的に、「バックエンド」ソフトウェアと、ルート選定及び案内のようなコア・ナビゲーション機能、並びに地図、住所、及び関心地点（ＰＯＩ）情報を提供する、関連するデータベースである。

ナビゲーション・システム、特に車両ナビゲーション・システムは、複雑な特注で作られるシステムに発展しており、これは歴史的に相手先商標製品製造会社（ＯＥＭ製）によって、ナビゲーション・プラットフォームとナビゲーション・ソリューションとの両方が単一システムとして一緒に開発され構築される組込み情報システムとして開発されている。より最近の傾向では、ＯＥＭ製は外部のナビゲーション・ソリューションの専門技術を活用しており、ナビゲーション・ソリューションの外部業者に頼っている。典型的な開発サイクルでは、ナビゲーション又はインフォテインメント・システムＯＥＭは、車両製造業者のような顧客によって定義された要件に基づいて新しいナビゲーション・プラットフォームを設計する場合がある。次に、ナビゲーション・システムＯＥＭは、ナビゲーション・プラットフォームへの統合に関する具体的要件を満たすことができる特注で作られるナビゲーション・ソリューションを必要とするであろう。ナビゲーション・ソリューションの統合ステップは、ナビゲーション・プラットフォームが具体的且つ複雑な方法でナビゲーション・ソリューションとインターフェースするように構成されるため、しばしば複雑であり、入り組んでいる。したがって、特定の提供業者により開発されたナビゲーション・ソリューションは、特定のＯＥＭナビゲーション・プラットフォームに具体的に特注で作られることになり、プラットフォームが非常に具体的且つしばしば複雑な方法でソリューションとインターフェースすることを必要とするであろう。ナビゲーション・ソリューションの特定の提供業者に頼っているナビゲーション・システムＯＥＭは、将来のソリューションの調達についてもその提供業者に幾分委ねられる可能性がある。したがって、ナビゲーション・システム開発の経済性は、付加費用と能率の悪さによって特徴付けられ、これは、ナビゲーション・プラットフォームへのナビゲーション・ソリューションの統合に対してより高い柔軟性が提供されれば低減される可能性がある。

別の問題は、ナビゲーション・プラットフォームとナビゲーション・ソリューションとのそれぞれの異なる開発サイクルに関係する。ナビゲーション・プラットフォームの開発は、年ごとのサイクル又は車両モデルのサイクルであり、一方、ナビゲーション・ソリューションの開発サイクルは、そのように限定されず、典型的にはより速い。新技術は、ナビゲーション・ソリューションの特徴及び機能を頻繁にアップグレードできるようにする可能性がある。他方では、ナビゲーション・システムへのこうした特徴及び機能の統合は、次世代のナビゲーション・プラットフォームが開発されるまで待たなければならない場合がある。例として、ユーザに最良の車線を提案する新しい車線推奨特徴を提供するために適切なデータベース情報でアップグレードされているナビゲーション・ソリューションを考える。現在の技術環境及び経済環境では、こうした特徴をＯＥＭナビゲーション・システムに追加することは、新しい特徴にアクセスするためにナビゲーション・プラットフォームへの大きな修正又は完全な再設計さえも普通は必要とするであろう。したがって、ナビゲーション・プラットフォームがナビゲーション・ソリューションで利用可能な新しい機能を発見し及び統合するための方法を提供することが有利となるであろう。

また別の問題は、ナビゲーション・ソリューションの性能と互換性を、普通はナビゲーション・ソリューションがホスト・ナビゲーション・プラットフォームに統合されるまでは十分に評価することができないことである。同様に、ＯＥＭ製ナビゲーション・システムは、プラットフォームとソリューションとの両方が仕上がるまではナビゲーション・ソリューションとプラットフォームとの互換性を試験する難しさを有する。したがって、ホスト・ナビゲーション・プラットフォームの開発に依存せずにナビゲーション・ソリューションのプロトタイピングを進めることができるようにすることが望ましいであろう。

したがって、当該技術分野では、上述の問題に対処し、且つナビゲーション・プラットフォームへのナビゲーション・ソリューションのより効率的且つ柔軟な統合を容易にする改善が必要とされている。上述の短所及び他の短所は、本発明の態様に係るナビゲーション・システム及び関係する方法によって対処される。

本発明は、標準化されたアプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用するナビゲーション・システムを提供する。ＡＰＩは、ナビゲーション・ソリューションの根底にある複雑さの抽象化を提供する。したがって、ソリューションの中にある複雑なナビゲーション関数は、比較的簡単な要求を用いてナビゲーション・プラットフォームによってアクセスされてもよい。さらに、ナビゲーション・プラットフォームとナビゲーション・ソリューションとの両方は、予め定義されたＡＰＩを通じてインターフェースするように開発されてもよく、したがって開発及び統合におけるより高い柔軟性及び効率を可能にする。

ＡＰＩは、高速プロトタイピング、初期化、ビュー設定、情報発見及び交換、車両位置、ルート案内、ナビゲーション音声、及びトラフィック・メッセージ・チャンネル（ＴＭＣ）コンポーネントに対するインターフェース・コンポーネントを含む。これらのインターフェース・コンポーネントは、ナビゲーション・プラットフォームとナビゲーション・ソリューションとの間の高レベル対話を達成するために標準関数セットによって定義される。

高速プロトタイピング・インターフェース・コンポーネントは、ナビゲーション・ソリューションとナビゲーション・プラットフォームとの効率的な統合を保証するのに必要最小限のＡＰＩ関数セットを含んでもよい。ホスト・ナビゲーション・プラットフォームとナビゲーション・ソリューションは、高速プロトタイピング・インターフェース・コンポーネントに従ってインターフェースするように構成されてもよく、これにより互換性が保証される。したがって、ナビゲーション・ソリューションは、既存のナビゲーション・プラットフォームへのフル統合を必要とすることなく開発され、プロトタイプ製作されてもよい。初期化インターフェース・コンポーネントは、ナビゲーション・ソリューション及びプラットフォームに対する標準初期化シーケンスを提供する。

情報発見及び交換インターフェース・コンポーネントは、ナビゲーション・ソリューションによって与えられるすべての情報及び機能をナビゲーション・プラットフォームが発見し及び使用することを可能にする。したがって、ナビゲーション・ソリューションにおいて提供される開示された機能は、ナビゲーション・プラットフォームの修正を必要とすることなく発見され及び使用される可能性がある。

本発明の実装の例によれば、ＡＰＩは、クライアント−サーバ・アーキテクチャに実装されてもよい。ナビゲーション・プラットフォームは、ナビゲーション・ソリューションによって提供されるナビゲーション・サーバ・コンポーネントとＡＰＩを介してインターフェースするように構成された、ナビゲーション・クライアント・コンポーネントを含んでもよい。ナビゲーション・クライアント・コンポーネントは、ナビゲーション・サーバ・コンポーネントに要求コマンドを発行してもよい。同様に、ナビゲーション・サーバ・コンポーネントは、クライアント・コンポーネントに応答コマンド又はメッセージを発行する。要求及び応答メッセージは、高レベル関数呼出しとして実装されてもよく、Ｃ＋＋のようなオブジェクト指向プログラミング言語で定義されてもよい。

本発明の他のデバイス、装置、システム、方法、特徴、及び利点は、当業者には明らかであろう、又は以下の図面及び詳細な説明を考察することによって明らかとなるであろう。この説明の中でのすべてのこうした付加的なシステム、方法、特徴、及び利点は、本発明の範囲内となる及び添付の請求項によって保護されることを意図される。

本発明は、以下の図面を参照することによってより良く理解されるであろう。図中のコンポーネントは必ずしも原寸に比例しておらず、代わりに、本発明の原理を例証することに重点が置かれている。図面では、異なる図の全体を通して同様の参照番号は対応する部分を表す。

例えば、本願発明は以下の項目を提供する。
（項目１）
ナビゲーション・ソリューションとインターフェースするためのアプリケーション・インターフェースを含むナビゲーション・プラットフォームを備えるナビゲーション・システムであって、前記インターフェースが、前記ナビゲーション・ソリューションによって提供される対応する関数と協働するように適合された予め定義された関数のセットを含む、ナビゲーション・システム。
（項目２）
前記アプリケーション・インターフェースが、前記ナビゲーション・プラットフォームから独立してナビゲーション・ソリューションが機能的に評価されることを可能にするための高速プロトタイピング・インターフェース・コンポーネントを含む、上記項目に記載のナビゲーション・システム。
（項目３）
前記ナビゲーション・ソリューションの視覚出力を構成するための関数が、前記ナビゲーション・プラットフォーム上のディスプレイ・デバイス上に前記ナビゲーション・ソリューションの視覚出力を位置付けるための関数を含む、上記いずれかの項目に記載のナビゲーション・システム。
（項目４）
前記予め定義された関数が、前記ナビゲーション・ソリューションへの要求を作成し、及び前記ナビゲーション・ソリューションからの応答を受信させ、これによりクライアント−サーバ・アーキテクチャを実装するように構成される、上記いずれかの項目に記載のナビゲーション・システム。
（項目５）
前記アプリケーション・インターフェースが、前記ナビゲーション・ソリューションから利用可能な情報を発見するための情報発見及び交換インターフェース・コンポーネントを含む、上記いずれかの項目に記載のナビゲーション・システム。
（項目６）
前記情報交換インターフェース・コンポーネントが、前記ナビゲーション・ソリューションから利用可能な前記情報のタイプを判定するための少なくとも１つの関数を含む、上記いずれかの項目に記載のナビゲーション・システム。
（項目７）
前記情報交換インターフェース・コンポーネントが、前記ナビゲーション・ソリューションから利用可能な情報タイプのリストを要求するための少なくとも１つの関数を含む、上記いずれかの項目に記載のナビゲーション・システム。
（項目８）
前記ナビゲーション・プラットフォームと前記ナビゲーション・ソリューションとの間のプロセス間通信を可能にするためのプロセス間通信インターフェースをさらに備える、上記いずれかの項目に記載のナビゲーション・システム。
（項目９）
ナビゲーション・プラットフォームにナビゲーション・ソリューションを統合する方法であって、
前記ナビゲーション・プラットフォーム上のアプリケーション・プログラミング・インターフェースであり、予め定義された関数のセットを含む、アプリケーション・プログラミング・インターフェースを提供するステップと、
前記アプリケーション・プログラミング・インターフェースを伴うナビゲーション・ソリューションを提供するステップと、
前記予め定義された関数のセットを介して、前記ナビゲーション・ソリューションからの情報を要求するステップと、
を含む方法。
（項目１０）
前記アプリケーション・プログラミング・インターフェースが、高速プロトタイピング・インターフェース・コンポーネントを含み、且つ、前記高速プロトタイピング・インターフェース・コンポーネントを用いて前記ナビゲーション・ソリューションを評価するステップをさらに含む、上記項目に記載の方法。
（項目１１）
前記アプリケーション・プログラミング・インターフェースが、情報発見及び交換コンポーネントを含み、前記情報発見及び交換コンポーネントを用いて前記ナビゲーション・ソリューションから利用可能な情報を発見するステップをさらに含む、上記いずれかの項目に記載の方法。

（摘要）
ナビゲーション・システムは、ナビゲーション・ソリューションをナビゲーション・プラットフォームに効率的に統合できるようにするためにアプリケーション・プログラミング・インターフェースを備える。システムは、クライアント−サーバ・アーキテクチャを含み、ＡＰＩは、それぞれクライアント及びサーバにおいて定義された要求関数と応答関数の標準化されたセットと共に実装される。ＡＰＩは、特定のナビゲーション・プラットフォームから独立してナビゲーション・ソリューションを開発できるようにするための高速プロトタイピング・インターフェース・コンポーネントを含む。情報発見及び交換インターフェース・コンポーネントは、ナビゲーション・プラットフォーム（クライアント）がナビゲーション・ソリューション（サーバ）ナビゲーション・ソリューションから利用可能な情報を発見し及び検索することを可能にする。

本発明の一実装の例に係るナビゲーション・システムのブロック図である。 本発明の実装の例に係るＡＰＩを含む図１のナビゲーション・システムに適用可能なナビゲーション・システム・アーキテクチャのブロック図である。 本発明の一実装の例に係る図１のナビゲーション・システムのコンポーネント及びインターフェースを例証するブロック図である。 本発明の実装の例に係るＡＰＩのインターフェース・コンポーネントを示すブロック図である。 初期化インターフェースのための要求−応答ダイアログの一例を例証するシーケンス図である。 情報発見及び交換インターフェース・コンポーネントを実装するのに適した情報ツリー構造の一例を示す情報ツリー図である。 情報発見及び交換のための例となるプロセスを例証するシーケンス図である。 情報発見及び交換インターフェースにおいて国情報を得るためのプロセスの一例を例証するシーケンス図である。 情報交換インターフェースにおいて州情報を得るための例となるプロセスを例証するシーケンス図である。 情報交換インターフェースにおいて州情報を得るための例となるプロセスを例証するシーケンス図である。 ナビゲーション音声インターフェース・コンポーネントによって行われる例となるプロセスを示すシーケンス図である。

この出願に含まれた図面と組み合わせて説明される１つ又は複数のプロセス、サブプロセス、又はプロセスステップは、ハードウェア及び／又はソフトウェアによって行われてもよいことが当業者によって理解され及び認識されるであろう。プロセスがソフトウェアによって行われる場合、ソフトウェアは、図面に概略的に描かれた機能コンポーネント又はモジュールのうちの１つ又は複数のような適切な電子処理コンポーネント又はシステムのソフトウェア・メモリにあってもよい。ソフトウェア・メモリにおけるソフトウェアは、論理関数（すなわち、デジタル回路又はソースコードのようなデジタル形式又はアナログ回路又はアナログソース、例えばアナログ電気信号、音、又はビデオ信号のようなアナログ形式のいずれかで実装されてもよい「論理」）を実装するための実行可能な命令の順序付けられたリストを含んでもよく、命令実行システム、装置、又はデバイスから命令を選択的にフェッチし及び命令を実行してもよいコンピュータベースのシステム、プロセッサを含んでいるシステム、又は他のシステムのような命令実行システム、装置、又はデバイスによって又はこれらと組み合わせて用いられる任意のコンピュータ可読媒体において選択的に具体化されてもよい。この開示との関連において、「コンピュータ可読媒体」は、命令実行システム、装置、又はデバイスによって又はこれらと組み合わせて用いられるプログラムを収容し又は格納してもよい任意の手段である。コンピュータ可読媒体は、選択的に、例えば、これらに限定はされないが、電子、磁気、光、電磁気、赤外線、又は半導体システム、装置、又はデバイスであってもよい。コンピュータ可読媒体の、網羅的なリストではないが、より具体的な例は、携帯型コンピュータ・ディスケット（磁気）、ＲＡＭ（電子）、読出し専用メモリ「ＲＯＭ」（電子）、消去可能プログラム可能読出し専用メモリ（ＥＰＲＯＭ又はフラッシュメモリ）（電子）、及び携帯型コンパクト・ディスク読出し専用メモリ「ＣＤＲＯＭ」（光学）を含むであろう。プログラムは、例えば、紙の光学走査、パンチカードの読取り、又は他の媒体を介して電子的に取り込まれ、次いで必要な場合に適切な様態でコンパイルされ、解釈され、又は他の方法で処理され、次いでコンピュータメモリに格納されてもよいため、コンピュータ可読媒体は、プログラムがその上に恒久的に固定される紙又は別の適切な媒体であってもよいことに留意されたい。本明細書で開示される場合のプロセッサは、マイクロプロセッサ、中央処理装置（ＣＰＵ）、デジタル信号プロセッサ、若しくはコンピュータ可読媒体に格納された命令を実行するための機械を構成する他のデジタル又はアナログコンポーネントを含んでもよい。

図１は、本発明の一実装の例に係るナビゲーション・システム１００のブロック図である。ナビゲーション・システム１００は、ナビゲーション・プラットフォーム１１０と、以下で詳細に説明されることになるアプリケーション・プログラミング・インターフェース１３０を通じて協働するナビゲーション・ソリューション１２０とを含む。ナビゲーション・プラットフォーム１１０は、ナビゲーション・コンピュータ１４０、ヒト−機械インターフェース（ＨＭＩ）１５０、搭載センサ１７０、及び通信ユニット１８０を含む。

ナビゲーション・コンピュータ１４０は、一般に、バス１４６を介して電子通信するプロセッサ１４２及び記憶装置１４４を含む。記憶装置１４４は、情報の記憶を提供する電子メモリコンポーネントであり、プロセッサ１４２、及び固定記憶装置（内部ハードディスク又は統合型ソリッドステートメモリ）、並びにリムーバブル記憶装置コンポーネント（フラッシュディスク、リムーバブルメモリカードなど）に対するデータ及び命令を含んでもよい。認識されるように、記憶装置要素１４４は、ローカル記憶装置とリモート記憶装置（例えば、ネットワーク接続を介して遠隔的にアクセス可能なクラウドベースの記憶装置コンポーネント）との両方を表す。記憶装置１４４は、データ１４６の記憶とプロセッサ１４２に対する命令を提供する。命令は、オペレーティング・システム１４８と、指定されたタスクを行うためにプロセッサ１４２を介してオペレーティング・システム１４８内で実行する１つ又は複数のアプリケーション１４９を提供してもよい。バス１４６はまた、指定されたグラフィックス処理コンポーネントを含むグラフィックス処理装置１４１と通信し、信号をディスプレイ１５２に提供してもよい。ナビゲーション・コンピュータ１４０は、車両バスインターフェース１４３を通じて車両サブシステムと通信してもよい。

ＨＭＩ１５０は、ナビゲーション・プラットフォーム１１０とのユーザ対話を可能にし、ディスプレイ１５２、音声入力デバイス１５４、音声出力デバイス１５６、及び触覚入力デバイス１５８を含んでもよく、触覚入力デバイス１５８は、ユーザがナビゲーション・プラットフォーム１００と触覚的な方法で対話することを可能にするキーボード、タッチスクリーン、ダッシュボード、若しくはコンソール制御又は他のデバイスを含んでもよい。

コントローラ・エリア・ネットワーク（ＣＡＮ）バス規格に準拠するバスを含んでもよい車両搭載バス１６０は、車両サブシステムのコンポーネントとナビゲーション・コンピュータ１４４との間の電子通信を可能にする。搭載センサ１７０は、ＧＰＳ、速度、ジャイロスコープ、及び他のパラメータに対するセンサを含んでもよい。通信ユニット１８０は、ワイド・エリア・ネットワーク（ＷＡＮ）又は他の接続を含んでもよい。

当業者によって認識されるように、ナビゲーション・ソリューション１２０とＡＰＩ１３０は、ナビゲーション・プラットフォーム１１０との特定の関係性において例証されるが、ナビゲーション・プラットフォーム１１０と異なる方法で協働してもよい。例えば、ナビゲーション・ソリューション１２０とＡＰＩ１３０は、記憶装置１４４に局所的に格納されるアプリケーションとして実装されてもよい。代替的に、ナビゲーション・ソリューション１２０は、クラウド・コンピューティング及び／又はｓｏｆｔｗａｒｅ−ａｓ−ａ−ｓｅｒｖｉｃｅモデルの下で通信ユニット１８０を介し無線リンクを介してアクセス可能なリモートサービスとして提供されてもよい。

図２は、ナビゲーション・システムのアーキテクチャ構成を例証するブロック図である。システム・アーキテクチャは、ナビゲーション・プラットフォーム層２００、ＡＰＩ層２２０、ナビゲーション・ソリューション層２４０、及びデバイス層２６０を含む。ナビゲーション・プラットフォーム層２００は、図１に関して上記で説明されたＨＭＩ１５０、並びにＡＰＩ層２２０と協働するクライアント・コンポーネント２１０を含み、ＨＭＩ１５０はＡＰＩ層２２０を通じてナビゲーション・ソリューション層２４０にアクセスすることになる。認識されるように、クライアント・コンポーネント２１０は、ＨＭＩ１５０に統合されてもよく、又は図２で例証されるように別個のコンポーネントとして構成されてもよい。クライアント・コンポーネント２１０は、以下でより詳細に説明されるようにＡＰＩ層２２０を介してナビゲーション・ソリューション層２４０とインターフェースする機能を提供する。

ナビゲーション・ソリューション層２４０は、サーバ・コンポーネント２４４を提供し且つナビゲーション・データベース２４６及び地図スタイル／構成データベース２４８と協働する、コア・ナビゲーション・アプリケーション２４２を含む。ナビゲーション・データベース２４６は、ナビゲーション・ルート、道路、関心地点に関係する情報、及び他のトラベル関連情報を含む。地図スタイル／構成データベース２４８は、地図スタイルに関係する情報と、ルート案内グラフィックス（すなわち、道路説明図）と組み合わされた層として典型的に表示されるグラフィカル地図表示に関係する表現／表示基本設定とを含む。ナビゲーション・コア・アプリケーション２３２はまた、ユーザがコア・ナビゲーション・アプリケーション２４２の出力をグラフィック形式で視覚化することを可能にするのに必要な出力を提供する、視覚化エンジン２４１と対話する。サーバ・コンポーネント２４４は、以下でより詳細に説明されるようにＡＰＩ層２２０と協働する。

デバイス層２６０は、多数のデバイス及び対応するインターフェースを含み、これらはナビゲーション・ソリューション層２４０と協働する。これらは、グラフィックス処理装置１４１、測位エンジン２４２、ＴＭＣデバイス２４４、及びテキストを音声に変換する（ｔｅｘｔ ｔｏ ｓｐｅｅｃｈ）（ＴＴＳ）デバイス２４６を含む。それぞれのインターフェースは、これらのデバイスが、グラフィックスＡＰＩ２５０、測位ＡＰＩ２５２、トラフィック・メディアセンターＡＰＩ２５４、及び音声ＡＰＩ２５６を含むナビゲーション・ソリューション層２４０と協働できるようにするために提供される。測位エンジン２４４は、センサ１７０から車両センサ情報を得る。認識されるように、デバイス層２６０は、図１で例証されたナビゲーション・プラットフォーム１１０と共通して、センサ及びＨＭＩ要素のような要素を有する可能性があるにもかかわらず、概念的な目的で図２では別個の層として例証される。

サーバ・コンポーネント２４４との関連において１つ又は幾つかのサーバが提供されてもよいことを当業者は理解するであろう。例えば、１つのサーバは、ナビゲーション・コア・アプリケーション２４２の基本ルート案内能力のための機能を提供してもよく、一方、別のサーバは、ナビゲーション・コア・アプリケーション２４２の三次元シティ・ビューア又はグローブ・ズーム能力のための機能を提供してもよい。

図３は、本発明の態様に係るナビゲーション・システムにおけるクライアント−サーバ・アーキテクチャに関するさらなる詳細を例証するブロック図である。ナビゲーション・アプリケーション・プログラミング・インターフェース１３０は、クライアント・コンポーネント２１０とナビゲーション・サーバ・コンポーネント２４０との間の対話を容易にする。本発明の態様によれば、クライアント・コンポーネント２１０は、サーバ・コンポーネント２４０への要求を開始するために多数の要求関数２１２を提供する。サーバ・コンポーネント２４０は、クライアント・コンポーネント２１０への応答を生成するために多数の応答関数２４２を提供する。プロセス間通信（ＩＰＣ）チャンネル２５０は、クライアント・コンポーネント２１０及びサーバ・コンポーネント２４０によって行われるプロセスのうち、メッセージを含むデータのプロセス間交換を提供する。当業者には分かるように、ＩＰＣチャンネルは、メッセージの受け渡し、同期、共有メモリ、及びリモート手続き呼出し（ＲＰＣ）のような公知の方法によって実装されてもよい。さらに、ＩＰＣチャンネルを実装するのに用いられる方法は、スレッドの間の通信の帯域幅及び待ち時間、並びに通信されるデータのタイプに基づいて変化してもよい。ＩＰＣチャンネルは、メッセージ処理のためにＩＰＣライブラリ・コンポーネント２５２を使用してもよい。サーバ・コンポーネントはまた、グラフィックス出力ライブラリ２６０、ナビゲーション測位（ＮＰ）ライブラリ２７０、及び音声出力ライブラリ２８０を含んでもよい、システムレベルのリソースへのインターフェースを含む。

以下は、本発明の態様に係るナビゲーションＡＰＩを実装するのに適した例となる関数のリストである。リストは、網羅的となること又は如何なる様態にも自ら制限することを意図されない。加えて、説明される関数に対して用いられる命名法は任意であって、如何なる様態にも限定することを意図されない。各言葉に対する機能もまた含まれるが、その機能が達成される方法は、この出願で説明される実装における如何なる方法にも限定されない。

これらの関数が適切なプログラミング言語である、Ｃ＋＋のようなオブジェクト指向プログラミング言語で実装されてもよいことが当業者には認識されるであろう。さらに、関数名に「ｒｅｑｕｅｓｔ」という言葉を組み入れている命名法は、ナビゲーション・クライアント・コンポーネント上で実行される関数呼出しを表すことが当業者には分かるであろう。同様に、「ｒｅｓｐｏｎｓｅ」という言葉を組み入れている関数名は、ナビゲーション・サーバ・コンポーネント上で実行される関数呼出しを表す。上述のインターフェース・コンポーネントを実装するのに適した関数が以下で説明されることになる。関数によって渡される例となる値又はパラメータを表すために括弧が用いられる。

認識されるように、ナビゲーション・ソリューションのサーバ・コンポーネントによって提供される例となる応答関数は、ナビゲーション・ソリューションの中の複雑な機能の抽象化層を提供する。したがって、ナビゲーション・プラットフォームは、ナビゲーション・ソリューションの根底にある複雑さに関連した複雑なプロセスを必要とせずに比較的簡単なコマンドとして作られる要求関数によって、ナビゲーション・ソリューションの中の全機能にアクセスしてもよい。

本発明の態様によれば、図４で例証されるように、本発明に係る例となるＡＰＩは、全ＡＰＩの関数のサブセットによって実装される多数の機能的インターフェース・コンポーネントを含む。これらのインターフェース・コンポーネントは、高速プロトタイピング・インターフェース・コンポーネント４１０、初期化インターフェース・コンポーネント４１２、情報交換インターフェース・コンポーネント４１４、車両位置情報インターフェース・コンポーネント５１６、ナビゲーション・ルート・インターフェース・コンポーネント５１８、ナビゲーション音声インターフェース・コンポーネント５２０、及びトラフィック・メディア・チャンネル（ＴＭＣ）インターフェース・コンポーネント５２２を含む。それぞれ以下でさらに詳細に説明されることになる。

（高速プロトタイピング・インターフェース・コンポーネント）
本発明の態様によれば、高速プロトタイピング・インターフェース・コンポーネントは、ナビゲーション・ソリューションの高速プロトタイピングを可能にするために実装される。高速プロトタイピング・インターフェース・コンポーネントは、ホスト・ナビゲーション・プラットフォームの存在から独立してナビゲーション・ソリューションを機能評価し及び試験できるようにするのに必要最小限の機能のセットを提供する。高速プロトタイピング・インターフェース・コンポーネントは、初期化、スクロール、回転、及びルート案内機能を容易にする。これらの機能は、既存のＯＥＭナビゲーション・プラットフォームに事前に統合する必要なしに、ナビゲーション・ソリューションの開発者が彼らのソリューションを評価することを可能にする。これは、ソリューションを現実の生活環境で評価するためにリソースに対する最小量の努力及び開発時間であらゆるソリューションの統合を可能にする。例となる高速プロトタイピング・インターフェース・コンポーネントを定義する関数は、以下の説明及びこの出願で参照される図面で詳細にされる。

ｒｅｑｕｅｓｔＩｎｉｔ（ＶＩＤ）−関数ｒｅｑｕｅｓｔＩｎｉｔは、システムにおいてナビゲーション・クライアント・コンポーネント２１６がスタートした後でナビゲーション・サーバ・コンポーネント２３８を初期化するためにナビゲーション・クライアント・コンポーネント２１６によって呼び出される。関数呼出しは、視覚コンポーネントＩＤ（ＶＩＤ）を、デバイス層２４０の基本となるグラフィカル・サブシステムに対する識別子としてナビゲーション・サーバ・コンポーネントに渡してもよい。ナビゲーション・サーバ・コンポーネントは、ｒｅｓｐｏｎｓｅＩｎｉｔメッセージを発行する前に、ナビゲーション・クライアント・コンポーネントからの対話なしに、自分で上手く初期化し、必要なステップ、例えばシステム・インターフェースとの通信又は内部データ初期化を行う。

ｒｅｓｐｏｎｓｅＩｎｉｔ（ｅｒｒｏｒＣｏｄｅ）−関数呼出しｒｅｓｐｏｎｓｅＩｎｉｔは、ｒｅｑｕｅｓｔＩｎｉｔが呼び出された後でクライアントに返答を提供し、サーバは、ｒｅｓｐｏｎｓｅＩｎｉｔを用いて応答し、ナビゲーション・サーバ・コンポーネントが適正に初期化されるのを何かが阻んだ場合にゼロに等しくないエラーコードを渡す。ｅｒｒｏｒＣｏｄｅパラメータは、サーバ側及びクライアント側で予め定義され及び確立されたエラーコードを表す。エラーコードは、ナビゲーション・ソリューションの提供業者に固有のものである。ゼロに等しいエラーコードは、エラーのない初期化を示す。

ｒｅｑｕｅｓｔＳｅｔＳｃｒｅｅｎＶｉｅｗｐｏｒｔ（ｘＴｏｐＬｅｆｔ，ｙＴｏｐＬｅｆｔ，ｘＢｏｔｔｏｍＲｉｇｈｔ，ｙＢｏｔｔｏｍＲｉｇｈｔ）−この関数呼出しは、ナビゲーション・ソリューションの視覚出力をスクリーン上に位置付け、ナビゲーションの視覚コンポーネントの可視矩形の左上の角と右下の角を指定することによって位置を定義するために呼び出されてもよい。スクリーンは、左上の角から（０，０）で測定されてもよい。すべての絶対スクリーン座標は、角（０，０）から開始する。したがって、関数呼出しは、４つの座標、すなわちｘＴｏｐＬｅｆｔ、ｙＴｏｐＬｅｆｔ、ｘＢｏｔｔｏｍＲｉｇｈｔ、及びｙＢｏｔｔｏｍＲｉｇｈｔをパラメータとして渡してもよい。

ｒｅｑｕｅｓｔＳｅｔＭｅａｓｕｒｅｍｅｎｔＳｙｓｔｅｍ（ｕｎｉｔＳｙｓｔｅｍ）−この関数呼出しは、視覚動作及び非視覚動作に対するナビゲーション・ソリューションの現在の測定系を設定するであろう。これは初期化中並びにランタイム中に呼び出されてもよい。測定系の指定は、ナビゲーション・クライアント・コンポーネント２１６からナビゲーション・サーバ・コンポーネント２３８に正しい距離関連情報が渡され及び戻されるのに不可欠である。ｕｎｉｔＳｙｓｔｅｍは、不定、英ヤード、英フィート、又はメートルのうちの可能な値を有する列挙データ・タイプとして定義されてもよい。

ｒｅｑｕｅｓｔＳｅｔＣｏｏｒｄｉｎａｔｅＳｙｓｔｅｍ（ｅＣｏｏｒｄｉｎａｔｅＳｙｓｔｅｍ，ＣｏｏｒｄｉｎａｔｅＳｙｓｔｅｍ）−ナビゲーション・ソリューションの現在座標系は、初期化中並びにランタイム中に呼び出されてもよいｒｅｑｕｅｓｔＳｅｔ−ＣｏｏｒｄｉｎａｔｅＳｙｓｔｅｍ関数によって設定される。座標系の指定は、クライアント側からサーバに正しい位置関連情報が渡される及び戻されるのに不可欠である。ｅＣｏｏｒｄｉｎａｔｅＳｙｓｔｅｍパラメータは、利用可能な座標系を表す値を有する列挙データ・タイプとして定義されてもよい。

ｒｅｑｕｅｓｔＳｅｔＺｏｏｍＳｃａｌｅ（ｄｏｕｂｌｅ，ｚｏｏｍｓｃａｌｅ）−この関数は、現在の単位測定系を考慮に入れて、視覚出力をズームイン又はズームアウトするのに用いられる。パラメータｚｏｏｍＳｃａｌｅは、ｅｇｏ位置（車）が位置するところでのディスプレイのセンチメートルあたりの視覚出力のメートルの単位のスケールを表す。これはまた斜視図にも当てはまる。例えば、値５００を渡すことは、ディスプレイ上のセンチメートルあたりのワールド座標における５００メートルとなる。この関係は、現在のｅｇｏ位置（車）を通じて水平線上では正確である。

ｒｅｑｕｅｓｔＳｅｔＲｏｔａｔｉｏｎ（ｄｅｇｒｅｅ，ｔｈｒｅｓｈｏｌｄ）−この関数は、サーバからの視覚出力の回転を要求する。ｄｅｇｒｅｅパラメータは、単位が度である可視出力の回転量を表す。０は北を表し、有効な値は、０°から３５９°まで及び−１°から−３５９°までの範囲である。負の角度は、反時計回りの回転となり、正の角度は、時計回りの回転となる。閾値パラメータは、その回転後に中間フレームが描画されるべき回転レベルを示す。−１のパラメータ値は、中間フレームがないが、特定された角度への中間回転が存在することを定義する。閾値が度数値よりも高い場合、閾値は無視されることになり、中間フレームは描画されない。

ｒｅｑｕｅｓｔＳｅｔＰｏｓｉｔｉｏｎ（ｘＣｏｏｒｄｉｎａｔｅ，ｙＣｏｏｒｄｉｎａｔｅ，ｃｏｏｒｄｉｎａｔｅＴｙｐｅ）−この関数は、現在の座標系を考慮に入れて渡されたワールド座標又はディスプレイ座標（ｃｏｏｒｄｉｎａｔｅＴｙｐｅによって示される）での視覚出力を位置付ける。現在のユーザ位置は、「ｅｇｏ」位置として定義され、２つの異なる座標セットと関連付けられてもよく、１つの座標セットはスクリーンのゼロ点から測定した絶対座標であり、１つの座標セットはビューポートのゼロ点から測定した相対座標セットである。

ｒｅｑｕｅｓｔＳｅｔＯｒｉｅｎｔａｔｉｏｎ（ｅＯｒｉｅｎｔａｔｉｏｎ，ｏｒｉｅｎｔａｔｉｏｎ）−渡された向きパラメータに従って視覚出力の向きを設定する。パラメータは、ｎｏｒｔｈＵｐ（ノースアップの向きを識別する）、ｈｅａｄｉｎｇＵｐ（ヘディングアップの向きを識別する）、又はｄｅｓｔｉｎａｔｉｏｎＵｐ（目的地が上にある向きを識別する）のうちの可能な値を有する列挙データ・タイプであってもよい。

ｒｅｑｕｅｓｔＳｃｒｏｌｌｉｎｇ（ｍｏｄｅ，ｄｉｒｅｃｔｉｏｎ，ｓｐｅｅｄ）−この関数は、視覚ナビゲーション出力をスクロールし、スクロールからの出力をストップし、及び現在のｅｇｏ位置にジャンプバックするであろう。関数は、パラメータの異なる組合せで提供されてもよい。モード・パラメータは、ｓｔａｒｔ（スクロールのスタートを識別する）、ｓｔｏｐ（スクロールのストップを識別する）、ｊｕｍｐＢａｃｋＴｏＣａｒＰｏｓｉｔｉｏｎ（スクロールのストップ＋車位置へのジャンプバックを識別する）、又はｄｅｔａｃｈＦｒｏｍＣａｒＰｏｓｉｔｉｏｎ（スクロールが車位置から切り離される）のうちの可能な値を有する列挙データ・タイプであってもよい。パラメータは、このスクロール要求に対して用いられるモードを特定する。ｓｔａｒｔを用いる複数の要求は、パラメータが変化した場合にのみスクロールを変化させ、他の場合には呼出しは無視される。他のモードを用いるその後の呼出しは、現在位置でのスクロールをストップする最初のｓｔｏｐ呼出しを除いて無視されることになり、この場合、ｊｕｍｐＢａｃｋＴｏＣａｒＰｏｓｉｔｉｏｎがスクロールをストップし、位置を車位置にジャンプバックさせる。ｓｔｏｐが呼び出された後で、ｓｔａｒｔへの呼出しが現在位置でスクロールをスタートし、ｊｕｍｐＢａｃｋＴｏＣａｒＰｏｓｉｔｉｏｎへの呼出しが位置を車位置にジャンプバックさせる。ｄｉｒｅｃｔｉｏｎパラメータは、単位が度である要求されたスクロール方向を表す（０は北を表し、有効な値は０から３５９度までの範囲である）。ｓｐｅｅｄパラメータは、スクロール・ステップあたりにスクロールされたピクセルの量を表す。

ｒｅｑｕｅｓｔＳｅｔＶｉｓｉｂｌｅ（ｖｉｓｉｂｌｅＳｔａｔｅ）−この関数は、ナビゲーションの視覚出力の可視性又は不可視性を制御する。ｖｉｓｉｂｌｅＳｔａｔｅパラメータは、可視性がオン又はオフのいずれに切換えられるかを示すバイナリインジケータである。

ｒｅｑｕｅｓｔＳｅｔＡｐｐｅａｒａｎｃｅＳｔｙｌｅ（ａｐｐｅａｒａｎｃｅＳｔｙｌｅ）−ナビゲーションの視覚出力のスタイルは、例えば昼間モード又は夜間モードでｒｅｑｕｅｓｔＳｅｔＡｐｐｅａｒａｎｃｅＳｔｙｌｅを呼び出すことによって制御される。スタイルセットの色は、ナビゲーション・プラットフォームの提供業者に典型的に固有のものである。パラメータａｐｐｅａｒａｎｃｅＳｔｙｌｅは、視覚出力上で表示されるべき値を示し、ｄａｙ（デイカラー）、ｎｉｇｈｔ（ナイトカラー）、又はａｕｔｏＳｔｙｌｅ（自動設定を識別する）の値をもつ列挙されたデータ・タイプであってもよい。列挙は、昼間及び夜間の交通強調表示（ｔｒａｆｆｉｃ ｈｉｇｈｌｉｇｈｔｉｎｇ）をサポートするためにビットマスクとして取り扱われてもよい。ｄａｙとｎｉｇｈｔとの両方が設定される場合、ｄａｙ設定のみが表示されることになる。

ｒｅｑｕｅｓｔＴｒａｎｓｌａｔｅＤｅｓｔｉｎａｔｉｏｎＴｏＣｏｏｒｄｉｎａｔｅ−場所入力は、ＥＩＳ（ｅｎｃｏｄｅｄ ｉｎｆｏｒｍａｔｉｏｎ ｓｔｒｉｎｇ（エンコードされた情報文字列））タイプに基づいている。スペラ（ｓｐｅｌｌｅｒ）から又は格納された目的地から目的地文字列が検索された後で、エンコードされた文字列は、ｒｅｑｕｅｓｔＴｒａｎｓｌａｔｅＤｅｓｔｉｎａｔｉｏｎＴｏＣｏｏｒｄｉｎａｔｅを呼び出すことによって、立ち寄り場所又は目的地として用いられるべき座標に翻訳される必要がある。

ｒｅｓｐｏｎｓｅＴｒａｎｓｌａｔｅＤｅｓｔｉｎａｔｉｏｎＴｏＣｏｏｒｄｉｎａｔｅ−ＥＩＳが座標に翻訳されるべきナビゲーション・サーバに渡された後で、サーバは、応答を対応する要求に合致させるために、座標自体、ＥＩＳを上手く翻訳することができた場合にはステータス、及び渡されたＥＩＳ自体を渡す、ｒｅｓｐｏｎｓｅＴｒａｎｓｌａｔｅＤｅｓｔｉｎａｔｉｏｎＴｏ−Ｃｏｏｒｄｉｎａｔｅを呼び出すことによってこの要求に応答する。

ｒｅｑｕｅｓｔＳｅｔＤｅｓｔｉｎａｔｉｏｎ（ｘＣｏｏｒｄｉｎａｔｅ，ｙＣｏｏｒｄｉｎａｔｅ）−目的地又は立ち寄り場所としての複数の目的地は、ｒｅｑｕｅｓｔＳｅｔＤｅｓｔｉｎａｔｉｏｎを用いて設定されてもよい。

ｒｅｑｕｅｓｔＳｔａｒｔＲｏｕｔｅ（ ）−この関数は、少なくとも１つの目的地が設定された後で呼び出される。ルート案内に対して要求されるモードは、パラメータとして渡され、ルート案内がすぐにスタートする。パラメータは、組み合わされたルートをサポートするために３２ビットのビットマスクとして取り扱われることになる。ｒｅｑｕｅｓｔＳｅｔＤｅｓｔｉｎａｔｉｏｎによって目的地が設定されていない場合、この呼出しは無視されることになる。設定された目的地は、ルートをスタートするための第１の要求に対してのみ有効である。すべての新しい要求は、ルートをスタートする前に対応する目的地の設定を有する必要がある。

ｒｅｑｕｅｓｔＳｔｏｐＲｏｕｔｅ（ ）−この関数はルート案内をストップする。ルート案内がアクティブである場合、ルーティングは、ｒｅｑｕｅｓｔＳｔｏｐＲｏｕｔｅを呼び出すことによってストップされてもよい。ルート案内がアクティブではない場合、呼出しは無視されることになる。

ｒｅｑｕｅｓｔＳｅｔＤｅｍｏＭｏｄｅ（ｄｅｍｏＳｔａｔｅ，ｘＣｏｏｒｄｉｎａｔｅＣａｒ，ｙＣｏｏｒｄｉｎａｔｅＣａｒ）−この関数は、ナビゲーション・デモ・モードを有効にする又は無効にする。デモ・モードでは、ルート案内は、ＧＰＳデバイスなしにスタートされてもよい。ナビゲーション・デバイスは、自身でルートを移動するであろう。ｘＣｏｏｒｄｉｎａｔｅＣａｒパラメータ及びｙＣｏｏｒｄｉｎａｔｅＣａｒパラメータは、デモ車位置の座標を表す。デモ・モードがオフに切換えられることをｄｅｍｏＳｔａｔｅパラメータが示す場合、渡されたデモ車位置の値は無視されることになる。

ｉｎｆｏｒｍＤｅｍｏＭｏｄｅＥｎａｂｌｅｄ−この関数は、ナビゲーション・クライアントにデモ・モード状態を提供する。サーバは、初期化後に及び変化時に信号を一度送信する。

上記の関数は、本発明の態様に係る例となる高速プロトタイピング・インターフェース・コンポーネントを定義する。前述の高速プロトタイピング・インターフェース関数に加えて、図４を再び参照すると、本発明の態様に係る予め定義されたＡＰＩ関数は、初期化、ビュー設定（視覚出力構成）、情報発見及び交換、車両位置、ルート案内、ナビゲーション音声、及びＴＭＣに対する関数を含んでもよい。これらは以下で説明されることになる。

（初期化インターフェース・コンポーネント）
上記で説明されたｒｅｑｕｅｓｔＩｎｉｔ及びｒｅｓｐｏｎｓｅＩｎｉｔ関数はまた、初期化関数セットに属することになるが、高速プロトタイピング・インターフェース・コンポーネント関数リストにおいて既にカバーされている。

ｒｅｑｕｅｓｔＳｈｕｔｄｏｗｎ−これは、ナビゲーション・サーバ・コンポーネントのシャットダウンを要求するためのクライアント・コンポーネントからの関数呼出しである。

ｒｅｓｐｏｎｓｅＳｈｕｔｄｏｗｎ−この関数は、シャットダウン要求に応答してサーバ・コンポーネントをシャットダウンするであろう。

（ビュー設定インターフェース・コンポーネント）
ｒｅｑｕｅｓｔＳｅｔＶｉｅｗＴｙｐｅ（ｖｉｅｗＴｙｐｅ）−この関数は、地図のビュータイプを設定する。パラメータｖｉｅｗＴｙｐｅは、ｖｉｅｗ２Ｄ（２Ｄビュー）、ｖｉｅｗ３Ｄ（３Ｄビュー）、ｖｉｅｗＢｉｒｄ（高さ情報なしの斜視図）、ｖｉｅｗＧａｒａｇｅ（プレビューガレージにおける車両モデルのみを表示する３Ｄ斜視図）、及びｖｉｅｗＰｒｅｖｉｅｗ（ルートプレビュー地図を識別する）の可能な値を伴う列挙である。

ｒｅｑｕｅｓｔＳｅｔＣｏｍｐｏｎｅｎｔＣｏｎｔｅｘｔ−この関数は、視覚コンポーネントにその後の呼出しに従わせる。その後のすべての呼出しは、単一のナビゲーション・クライアントに対する複数の地図をサポートすることにのみ該当する。この呼出しは排他的であってもよく、それらのコンテキストがこの要求によってアクティブ化されるまでクライアントのすべての他の視覚コンポーネントに呼出しを無視させる。この呼出しは、それらのコンテキストがアクティブ化された後で呼び出されることになる異なる地図をサポートする。異なる出力は、異なるクライアントによってサポートされてもよい。

ｒｅｑｕｅｓｔＳｅｔＳｃｒｅｅｎＶｉｅｗｐｏｒｔＦｒａｍｅ−この関数は、その後の動作のためのスクリーン・ビューポート・フレームを設定するであろう。スクリーン・ビューポート・フレームは、スクリーン・ビューポートの解像度に影響しない。フレームは、ルート全体像のような全体像又は交通事象にズームするために限定されたスクリーン領域をサポートするように設定される。

ｒｅｑｕｅｓｔＳｅｔＶｉｓｕａｌＡｓｓｉｓｔａｎｃｅ−この関数は、視覚障害のあるユーザに対する視覚支援を有効にする及び無効にする。

ｒｅｑｕｅｓｔＢｌｏｃｋ−この関数は、視覚出力のさらなる更新をブロックする。その後のあらゆる要求は、スクリーン上での如何なるレンダリング又は描画をも引き起こさずにサーバ側の状態のみを設定するであろう。状態設定要求は、格納されてもよく、後で以下の関数ｒｅｑｕｅｓｔＵｎｂｌｏｃｋによってサーバがブロック解除されるとすぐに描画のために適用されてもよい。ブロックは、クライアントの視覚出力の送信にのみ適用され、他のクライアントに対する影響をもたない。

ｒｅｑｕｅｓｔＵｎｂｌｏｃｋ−この関数は、上記のｒｅｑｕｅｓｔＢｌｏｃｋ関数によってブロックされた視覚出力への更新をブロック解除するであろう。その後のクライアントからの描画に対する要求は、即座の描画につながるであろう。ブロック解除関数は、クライアントの視覚出力の呼出しにのみ適用され、他のクライアントに対する影響をもたない。

ｒｅｓｐｏｎｓｅＵｎｂｌｏｃｋ−この関数は、視覚出力がブロック解除され、結果として完全なフレームが描画された後で、クライアントに応答する。ｒｅｑｕｅｓｔＢｌｏｃｋ関数に関して上記で説明されたように、クライアントからのすべての格納された状態設定要求は、結果として生じるフレームに適用されるであろう。すべての格納された状態設定要求の適用の後で、応答がクライアントに送信されるであろう。

ｒｅｑｕｅｓｔＳｅｔＥｇｏＰｏｓｉｔｉｏｎ−この関数は、視覚ナビゲーション・コンポーネントのスクリーン・ビューポート内のスクリーン上の相対スクリーン座標におけるｅｇｏ位置を設定するであろう。ｅｇｏ位置は、スクリーン上の現在位置を示すために車のオーバーヘッド像のような適切なアイコンによって示されてもよい。位置は相対スクリーン座標である。

ｒｅｑｕｅｓｔＧｅｔＥｇｏＰｏｓｉｔｉｏｎ−この関数は、視覚ナビゲーション・コンポーネントのスクリーン・ビューポート内のスクリーン上の相対スクリーン座標における現在のｅｇｏ位置を得るであろう。

ｒｅｓｐｏｎｓｅＧｅｔＥｇｏＰｏｓｉｔｉｏｎＯｎＳｃｒｅｅｎ−この関数は、視覚ナビゲーション・コンポーネントのスクリーン・ビューポート内のスクリーン上の相対スクリーン座標における現在のｅｇｏ位置を戻す。

前述の初期化及びビュー設定関数、並びに例となるナビゲーション・システムのクライアント−サーバ・アーキテクチャにおけるそれらの対話が、図５で例証されるシーケンス図に関してさらに説明される。シーケンスは、クライアント・コンポーネントで始まり、サーバにｒｅｑｕｅｓｔＩｎｉｔ関数を出す。ｒｅｑｕｅｓｔＩｎｉｔ関数は、視覚コンポーネントＩＤを表すパラメータ、この場合は（１６）をサーバに渡す。サーバは、次いで、初期化プロセスを開始し、これはナビゲーション・ソリューションの初期化を含むであろう。サーバの初期化は、クライアントから独立して行われ、したがって、サーバ・コンポーネントは、システム・グラフィック・ライブラリ及びセンサのようなすべてのシステム・コンポーネントとの通信を確立することを必要とするであろう。完了したときに、サーバ・コンポーネントは、初期化が成功したか否かを示すためにエラー・フラグを含むｒｅｓｐｏｎｓｅＩｎｉｔコマンドを介して応答する。

サーバが初期化要求に応答した後で、クライアントは、前述の関数を用いてサーバに多数の状態設定メッセージを発行する。これらのメッセージは、スタートアップ値、例えば、視覚出力又は要求されるズームレベルに対するビューポートを設定するであろう。スタートアップ値は、必要な時にはいつでも設定されてもよいが、典型的には、ナビゲーション・サーバがさらなるアクションを行うことを要求される前に設定される。ここまでは、サーバは、如何なる視覚出力をもレンダリングする又は示すことを要求されない。サーバからすべての状態設定要求が作成された後で、ナビゲーション・プラットフォーム上のグラフィック出力デバイス上に描画されたフレームをレンダリングするようにサーバに指示するために、クライアントからｒｅｑｕｅｓｔＳｅｔＶｉｓｉｂｌｅコマンドが発行される。

（情報発見及び交換インターフェース・コンポーネント）
本発明の一態様によれば、ナビゲーション・プラットフォームがナビゲーション・ソリューション上で利用可能な情報のタイプ、したがって能力及び機能を発見すること、及びナビゲーション・ソリューションと情報を交換することを可能にする、情報交換インターフェース・コンポーネントが提供される。情報交換インターフェース・コンポーネントは、以下でさらに詳述されるように要求関数と応答関数のセットとして実装されてもよい。

例となるシステムは、ナビゲーション・ソリューションにおいて利用可能であってナビゲーション・プラットフォームによって検索される情報の識別を可能にするために、エンコードされた情報文字列（ＥＩＳ）を使用してもよい。ＥＩＳは、フォーム＜＞のトークン又はタグによって識別される情報を含む。例えば、トークン＜ＩＦＴ＞は情報タイプ識別子（ｉｎｆｏｒｍａｔｉｏｎ ｔｙｐｅ ｉｄｅｎｔｉｆｉｅｒ）を表し、＜ＣＴＲ＞は国情報（ｃｏｕｎｔｒｙ ｉｎｆｏｒｍａｔｉｏｎ）を識別し、＜ＩＴＲ＞は（交差する又は第２のストリートによって）交差点を識別する情報（ｉｎｆｏｒｍａｔｉｏｎ ｉｄｅｎｔｉｆｙｉｎｇ ａｎ ｉｎｔｅｒｓｅｃｔｉｏｎ）を表す。以下の関数記述のうちの幾つかでは、さらなる例となるＥＩＳが用いられるであろう。

情報発見及び交換インターフェース・コンポーネント４１４が図６を参照してさらに説明され、図６は、ナビゲーション・ソリューションが利用できるようにされた情報タイプ、関連するＥＩＳタグ（「＜＞」で示す）、及び情報値を系統立てるための例となる情報ツリーを例証する。加えて、図７、図８、図９Ａ、及び図９Ｂは、図６の例となる情報ツリーで説明された情報を用いる、及びナビゲーション・プラットフォーム（クライアント）がナビゲーション・ソリューション（サーバ）から利用可能な情報のタイプを発見するためのシーケンスを例証する、及び例えば選択された国及び州場所データを検索するシーケンス図である。

図６で見られるように、ナビゲーション・ソリューションから利用可能な情報は、ＥＩＳのように＜ＩＦＴ＞として表される場合があるルート識別子（Ｉｎｆｏｒｍａｔｉｏｎ Ｔｙｐｅ（情報タイプ））を含んでもよい。この例では、ナビゲーション・ソリューションは、ナビゲーション・プラットフォームによって用いられる４つの情報タイプ、すなわち、（１）Ｌｏｃａｔｉｏｎ Ｉｎｐｕｔ（場所入力）、（２）Ｐｏｉｎｔ ｏｆ Ｉｎｔｅｒｅｓｔ（関心地点）、（３）Ｍａｐ（地図）、及び（４）ＴＭＣ情報タイプを提示する。これらの情報タイプのそれぞれは、情報ツリーにおけるそれぞれのブランチによって表される付加的なサブタイプを含む。例えば、Ｌｏｃａｔｉｏｎ Ｉｎｐｕｔタイプの情報は、サブタイプ、すなわち、Ｃｏｕｎｔｒｙ（国）、Ｓｔａｔｅ（州）、及びＺｉｐ Ｃｏｄｅ（ジップコード）を含む。それぞれ、ナビゲーション・クライアントによって作成される要求及びナビゲーション・サーバによって与えられる応答における適切なＥＩＳによって表されてもよい。

ｒｅｑｕｅｓｔＧｅｔＡｖａｉｌａｂｌｅＩｎｆｏｒｍａｔｉｏｎ（ｉｎｐｕｔＥＩＳ）−この関数は、現在の情報に対する次の利用可能な洗練のリストを要求する。パラメータｉｎｐｕｔＥＩＳは、要求された情報を表すエンコードされた情報文字列（ＥＩＳ）であり、各情報タイプに対して利用可能なアイテムの特定のレベル及びカウントでのすべての利用可能な情報タイプのリストを含むであろう。ＮＵＬＬポインタ（空の文字列）が渡される場合、トップレベル又はルートレベルの利用可能な情報がクライアントに戻される。

ｒｅｓｐｏｎｓｅＧｅｔＡｖａｉｌａｂｌｅＩｎｆｏｒｍａｔｉｏｎ（ｉｎｐｕｔＥＩＳ，ａｖａｉｌａｂｌｅＴｙｐｅｓＥＩＳ）−このサーバ応答関数は、渡された情報に基づいてナビゲーション・ソリューション上で利用可能な情報が提供される、情報ツリー構造における次の利用可能な情報タイプのリストを提供するであろう。パラメータ入力ＥＩＳは、クライアント側がサーバからの応答を発行されたオリジナル要求に合致させてもよいように、要求コマンドにおいて渡されたものと同じＥＩＳである。戻されたパラメータａｖａｉｌａｂｌｅＴｙｐｅｓＥＩＳは、それぞれが値として全アイテムカウントを伴う利用可能な情報タイプを表す。ＮＵＬＬポインタは、応答を無効にする。

ｒｅｑｕｅｓｔＧｅｔＤｅｔａｉｌｓ（ｉｎｐｕｔＥＩＳ，ｒｅｑｕｅｓｔｅｄＦｉｅｌｄｓ）−この関数は、ｉｎｐｕｔＥＩＳ文字列に関して提供された情報に基づいて詳細な情報を要求する。要求されたフィールドにおける文字列はすべて、タグインジケータ＜＞によって囲まれるＥＩＳトークンとしてフォーマットされるであろう。例えば、＜ＧＥＯ＞又は＜ＡＬＬ＞である。パラメータｒｅｑｕｅｓｔｅｄＦｉｅｌｄｓは、ナビゲーション・サーバが提供するための要求されたフィールドを表す。

ｒｅｓｐｏｎｓｅＧｅｔＤｅｔａｉｌｓ（ｉｎｐｕｔＥＩＳ，ｖａｌｉｄＳｔａｔｅ，ｒｅｑｕｅｓｔｅｄＦｉｅｌｄｓ，ｏｕｔｐｕｔＥＩＳ）。これは、ｒｅｑｕｅｓｔＧｅｔＤｅｔａｉｌｓコマンドに応答して提供される情報の詳細を戻すための応答関数である。パラメータｖａｌｉｄＳｔａｔｅは、要求が成功したかどうかを示す、状態の妥当性を示す可能な有効値又は無効値を有する列挙である。ｒｅｑｕｅｓｔｅｄＦｉｅｌｄｓパラメータは、要求を応答と合致させるために要求コマンドで要求されたのと同じフィールドを含む。ｏｕｔｐｕｔＥＩＳパラメータは、付加されたフィールドを伴うｏｕｔｐｕｔＥＩＳを含む。

ｒｅｑｕｅｓｔＧｅｔＬｉｓｔ（ｉｎｐｕｔＥＩＳ，ｓｔａｒｔＩｎｄｅｘ，ｒｅｓｕｌｔＣｏｕｎｔ，ｓｏｒｔＯｐｔｉｏｎｓ，ｆｉｅｌｄＯｐｔｉｏｎｓ，ｃａｎｃｅｌＳｔａｔｅ）−この関数は、入力ＥＩＳに対する情報のリストを要求する。パラメータｓｔａｒｔＩｎｄｅｘは、リスト・ウインドウの第１の要素を表し、カウントは１でスタートする。ｒｅｓｕｌｔＣｏｕｎｔは、ウィンドウに対するアイテムの要求された量を表す。より少ない量が戻されることになり、利用可能なカウントは、要求された量よりも少ない。−１の値は、すべての利用可能なアイテムを戻すことを示す。パラメータｓｏｒｔＯｐｔｉｏｎは、データをソートする方法を表し、デフォルトのソーティング文字列は「Ｄｅｆａｕｌｔ（デフォルト）」である。パラメータｓｏｒｔＯｐｔｉｏｎは、ｄｅｆａｕｌｔＳｏｒｔ（デフォルトのソーティングを識別する）、ａｓｃｅｎｄｉｎｇ（昇順ソート）、ｄｅｓｃｅｎｄｉｎｇ（降順ソート）、ｎｅａｒＦｉｒｓｔ（最も近い最初のソート（ｎｅａｒｅｓｔ ｆｉｒｓｔ ｓｏｒｔｉｎｇ））、ｆａｒＦｉｒｓｔ（最も遠い最初のソート（ｆａｒｔｈｅｒ ｆｉｒｓｔ ｓｏｒｔｉｎｇ））、ｈｉｅｒａｒｃｈｉｃａｌＳｏｒｔ（より高階層の最初のソーティング）、ｈｉｅｒａｒｃｈｉｃａｌＤｅｓｃＳｏｒｔ（より低階層の最初のソーティング）のうちの可能な値を伴う列挙である。パラメータｆｉｅｌｄＯｐｔｉｏｎｓは、現在の要求に対して戻すために要求されたフィールドを伴う文字列アレイ構造を表す。デフォルトのフィールド文字列は「Ｄｅｆａｕｌｔ（デフォルト）」である。パラメータｃａｎｃｅｌＳｔａｔｅは、キャンセル状態を表す。真の値は、前の要求が同じパラメータで作成されていたときに現在処理待ちの要求をキャンセルするのに用いられ、真に設定された完全なフラグを伴う応答として確認が送られ、偽の値は、別個の要求として取り扱われるであろう。クライアントが入力ＥＩＳにおける＜ＩＦＴ＞タグのすぐ後ろに＜ＶＩＭ＞、＜ＰＡＴＨ＞、及び＜ＬＡＮＧ＞タグを付加する場合、情報のリストはまた、ｉｔｅｍＬｉｓｔにおける入力の代わりに共有メモリにおけるファイルとして戻されてもよい。

ｒｅｓｐｏｎｓｅＧｅｔＬｉｓｔ（ｉｎｐｕｔＥＩＳ，ｖａｌｉｄＳｔａｔｅ，ｓｔａｒｔＩｎｄｅｘ，ｒｅｓｕｌｔＣｏｕｎｔ，ｓｏｒｔＯｐｔｉｏｎｓ，ｆｉｅｌｄＯｐｔｉｏｎｓ，ｉｔｅｍＬｉｓｔ，ｏｕｔｐｕｔＥＩＳ，ｃｏｍｐｌｅｔｅＳｔａｔｅ）−この関数は、要求された情報のリストを提供する。この応答の挙動は、偽を伴う完全なフラグをマークすることによって１つの応答で要求されたデータのすべて又は要求された結果のうちの幾つかのみを伴う部分的結果を柔軟にサポートする。したがって、単一のｒｅｑｕｅｓｔＧｅｔＬｉｓｔ呼出しに対する複数の応答を受信することが可能である。入力ＥＩＳで特定された＜ＰＡＴＨ＞が予め計算されたリストに対するものであった場合、実際の＜ＰＡＴＨ＞はｏｕｔｐｕｔＥＩＳで戻されるであろう。ｖａｌｉｄＳｔａｔｅは、要求が成功したかどうかを示す状態を表す。ｓｔａｒｔＩｎｄｅｘ、ｒｅｓｕｌｔＣｏｕｎｔ、ｓｏｒｔＯｐｔｉｏｎｓ、及びｆｉｅｌｄＯｐｔｉｏｎｓは、ｒｅｑｕｅｓｔＧｅｔＬｉｓｔコマンドで説明されたのと同様である。ＩｔｅｍＬｉｓｔは、要求されたアイテムのリストである。パラメータｏｕｔｐｕｔＥＩＳは、オリジナル要求とは異なる場合に付加的な情報を含む。パラメータｃｏｍｐｌｅｔｅＳｔａｔｅは、リストが完全であるか否かを示す。

ｒｅｑｕｅｓｔＧｅｔＬｉｓｔＩｎｆｏｒｍａｔｉｏｎ（ｉｎｐｕｔＥＩＳ）−この関数は、現在の情報に対する可能なソート及びフィールド・データ・タイプを要求する。音声認識に用いられるときに、ナビゲーション・クライアントはまた、特定の音声入力型に関する情報を要求するために、ＥＩＳにおいて＜ＶＩＭ＞（音声入力モード）タグ、そのすぐ後に＜ＩＦＴ＞（情報タイプ）タグを含んでもよい。

ｒｅｓｐｏｎｓｅＧｅｔＬｉｓｔＩｎｆｏｒｍａｔｉｏｎ（ｉｎｐｕｔＥＩＳ，ｖａｌｉｄＳｔａｔｅ，ｓｏｒｔＯｐｔｉｏｎｓ，ｆｉｅｌｄＯｐｔｉｏｎｓ，ｏｕｔｐｕｔＥＩＳ）−この関数は、要求された情報に対する可能なソート及びフィールド・データ・タイプを提供する。リストが事前にコンパイル済み（ｐｒｅ−ｃｏｍｐｉｌｅｄ）＜ＰＣＰ＞であるのか又はサーバによって動的に生成されることになるのかの情報を提供する。このデータは、ユーザにどのようにして情報を提示するかを決めるためにクライアントによって使用されるであろう。サーバは、クライアントが要求＜ＶＩＭ＞において音声入力モードを提供するときに、この情報を提供することだけを要求される。パラメータｖａｌｉｄＳｔａｔｅは、要求が成功したかどうかを示す。パラメータｓｏｒｔＯｐｔｉｏｎｓは、現在のノードに対する利用可能なソーティング・オプションのベクトルを表すＳｔｒｉｎｇＡｒｒａｙ構造である。パラメータｆｉｅｌｄＯｐｔｉｏｎｓは、フィールド・オプションのベクトルを表すＳｔｒｉｎｇＡｒｒａｙ構造である。パラメータｏｕｔｐｕｔＥＩＳは、＜ＰＣＰ＞タグを含む付加されたフィールドを伴うｏｕｔｐｕｔＥＩＳを含む（＜ＶＩＭ＞と共に要求される場合）。＜ＬＡＮＧ＞タグは、利用可能な各言語に対して提供されるべきである（＜ＶＩＭ＞と共に要求される場合）。

ｒｅｑｕｅｓｔＧｅｔＳｐｅｌｌ（ｉｎｐｕｔＥＩＳ）−この関数は、ＥＩＳレコードにおける最後の選択基準に基づいて現在の情報（ｉｎｐｕｔＥＩＳによって表される）を綴るための利用可能な文字のセットを要求する。

ｒｅｓｐｏｎｓｅＧｅｔＳｐｅｌｌ（ｉｎｐｕｔＥＩＳ，ｖａｌｉｄＳｔａｔｅ，ｎｅｘｔＡｖａｉｌａｂｌｅＣｈａｒａｃｔｅｒｓ，ｃｏｕｎｔ，ｉｓＦｕｌｌＭａｔｃｈ）−この関数は、ｉｎｐｕｔＥＩＳで表される情報に対する次の利用可能な文字及び残りのカウントを提供する。パラメータｖａｌｉｄＳｔａｔｅは、要求が成功したか否かを示す。パラメータｎｅｘｔＡｖａｉｌａｂｌｅＣｈａｒａｃｔｅｒｓは、残りの次の利用可能な文字のセットを表す。パラメータｃｏｕｎｔは、現在の入力に合致するアイテムのカウントを表す。パラメータｉｓＦｕｌｌＭａｔｃｈは、入力された文字列がアイテムを完全に特定するかどうかを示す。

図７で例証されるシーケンス図を参照すると、前述の例となるｒｅｑｕｅｓｔＧｅｔＡｖａｉｌａｂｌｅＩｎｆｏｒｍａｔｉｏｎ関数を用いて、ナビゲーション・プラットフォーム（ナビゲーション・クライアント）からの要求を介して、ナビゲーション・ソリューション（図７のナビゲーション・サーバ）から利用可能な情報が最初に発見される。利用可能な情報に対するルート要求を示すためにコマンドにヌル値が与えられる。サーバは、ｉｎｐｕｔＥＩＳ値（この場合はヌルであり、メッセージ制御／アカウンティングの目的でクライアントに戻される）を含むｒｅｓｐｏｎｓｅＧｅｔＡｖａｉｌａｂｌｅＩｎｆｏｒｍａｔｉｏｎメッセージで応答する。結果コードは、ルート要求からの１つの結果を示し、この結果は「ＩｎｆｏＴｙｐｅ」であり、（４）の値を示す。ナビゲーション・クライアントは、次いで、ルートＩｎｆｏＴｙｐｅに関連付けられた４つの情報タイプのリストを要求するためにＧｅｔＬｉｓｔ要求を発行する。これに応答して、サーバは、４つの情報タイプ、すなわちＬＤＢ、ＬＩ、ＰＯＩ、及びＴＭＣのリストを提供するｒｅｓｐｏｎｓｅＧｅｔＬｉｓｔメッセージを提供する。したがって、ナビゲーション・ソリューションは、ナビゲーション・プラットフォームが用いるのに利用可能な情報タイプを識別する。

図８は、ナビゲーション・ソリューションからの場所情報のさらなる検索を示すシーケンス図である。クライアントは、ここでは場所情報（ｌｏｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）（ＬＩ）としてＩｎｆｏＴｙｐｅを特定するＥＩＳを伴うＧｅｔＡｖａｉｌａｂｌｅＩｎｆｏｒｍａｔｉｏｎ要求を発行する。ａｖａｉｌａｂｌｅＩｎｆｏフィールドにおいてサーバから戻される情報は、「Ｃｏｕｎｔｒｙ（国）」情報タイプ識別子及び２つのさらなる情報タイプを特定するパラメータである。次いで、２つの「ｃｏｕｎｔｒｙ」情報タイプのリストを検索するために、クライアントによってＧｅｔＬｉｓｔ要求が発行される。（２）のアイテムカウントと「ＣＡＮＡＤＡ（カナダ）」及び「ＵＳＡ」を示すリストがサーバから戻される。

図９Ａ及び図９Ｂは、州場所情報の検索に対する同様のシーケンス図を例証する。クライアントとサーバとの間の交換は、前述の国情報プロセスと類似した方法で進められた。しかしながら、ａｖａｉｌａｂｌｅＩｎｆｏフィールド（５３の州）において多数の結果が戻されるので、ＧｅｔＳｐｅｌｌ関数は、サーバからの情報の検索を絞り込むために２回用いられる。第１のＧｅｔＳｐｅｌｌ応答は、利用可能な文字のリストと“Ｓｔａｔｅ＝”基準（５３）を満たす結果の数を戻す。第２のＧｅｔＳｐｅｌｌ要求は、文字“Ｍ”で始まる州のサブセットを検索するように構成され、８つのアイテムと利用可能な文字“ＡＩＯ”を示す応答を生じる。基準を満たす州のリストを得るためにＧｅｔＬｉｓｔ関数が再び用いられる。

明らかであるように、前述の関数及びシーケンスは、ナビゲーション・ソリューションから利用可能なすべての情報を識別してもよい情報発見及び交換インターフェース・コンポーネント４１４を実装するのに用いられてもよい。ナビゲーション・ソリューションから及び情報交換インターフェースを介して利用可能な情報をエンコードするためのスキームは、４つの例となる情報タイプに限定されないが、ルート及び交差点情報に延長され、ナビゲーション・ソリューションによって事実上すべての情報タイプが利用可能にされる。

さらなる例として、以下で説明されるステップ並びに関連する要求関数及び応答関数に記載の交差点情報が使用されてもよい。

さらなる例として、情報発見及び交換インターフェース・コンポーネント４１４を用いて、ナビゲーション・プラットフォームは、ルートにおけるすべてのセグメントに対する全ルート・リストを要求してもよい。こうした要求は、ゼロの値を伴うルート要素＜ＲＴＥ＞を参照して特定することによって指定されてもよい。これは、情報発見及び交換インターフェース・コンポーネント４１４を定義する関数を用いて、ナビゲーション・ソリューションからどのようにしてルート情報が得られる場合があるかを例証する。

認識されるように、全ルート・リストに対する各リスト・アイテムは、それが属する＜ＲＴＥ＞を含むべきである。

ナビゲーション・ソリューションから利用可能な情報を識別するこの態様は、ナビゲーション・ソリューションによって提供されるべき新しい情報タイプの追加と、ナビゲーション・プラットフォームによるこうした発見に適応することも当業者には分かるであろう。すなわち、次世代ナビゲーション・ソリューション上で利用可能にされた新しい機能及び情報は、ナビゲーション・プラットフォームをアップグレードすることなく既存のナビゲーション・プラットフォームによって使用されてもよい。例えば、ナビゲーション・ソリューション上の車線推奨特徴及び利用可能な関連情報の追加は、ＥＩＳトークンの新しいセット及び図６に描かれた情報ツリー上の対応する付加的なブランチ（図示せず）を伴う「車線推奨」で指定される新しい情報タイプの追加によってナビゲーション・プラットフォームに識別されてもよい。

（車両位置情報インターフェース・コンポーネント）
ｒｅｑｕｅｓｔＶｅｈｉｃｌｅＬｏｃａｔｉｏｎＩｎｆｏｒｍａｔｉｏｎＤｅｔａｉｌｓ（ｕｐｄａｔｅＭｏｄｅ，ｕｐｄａｔｅＩｎｔｅｒｖａｌ）−この関数は、特定された時間間隔に基づいて位置情報の更新を有効にする又は無効にする。ｕｐｄａｔｅＭｏｄｅパラメータは、どのようにして向きの更新が送信されるべきかを示し、ｄｉｓａｂｌｅ（更新を無効にする）、ｏｎｃｅ（一回更新する）、ｏｎＣｈａｎｇｅ（向きの変化時に更新する）、及びｆｒｅｑｕｅｎｃｙ（定義された更新頻度）の可能な値を伴う列挙である。ｕｐｄａｔｅＩｎｔｅｒｖａｌパラメータは、位置の更新がクライアントに供給されることになる最大速度を表す。更新は、典型的には変化時にのみ供給されるであろう。値はｍｓの単位である。

ｉｎｆｏｒｍＶｅｈｉｃｌｅＬｏｃａｔｉｏｎＩｎｆｏｒｍａｔｉｏｎＤｅｔａｉｌｓ（ｐｏｓＩｎｆｏ）−この関数は、ｐｏｓＩｎｆｏによって特定される現在の場所の詳細を提供する。これは、ｇｅｏ位置、機首方向（ｈｅａｄｉｎｇ）、及びすべての利用可能な国、州、都市、現在のストリート情報、最も近い交差道路などを含む。これはまた、速度制限、タイムゾーン、車線推奨を含んでもよい。

（ナビゲーション・ルート・インターフェース・コンポーネント）
ｒｅｑｕｅｓｔＢｌｏｃｋＲｏｕｔｅ（ｏｐｅｒａｔｉｏｎ，ｉｔｅｍｓ）−この関数は、ルート（単数又は複数）計算からアイテム（単数又は複数）を追加又は削除し、ルート毎にグローバルに及び／又はローカルに回避するためにルート又はセグメントを表すベクトル又は他のアイテムを特定するのに用いられてもよい。ルート・ハンドルの空のリストが供給される場合、ブロックされたアイテムは、グローバルに適用され、すべての新しいルート計算及び現在アクティブなルートに影響するであろう。一度に１つのルートにつき１つだけの距離ブロックがこの関数によってサポートされる。第２のブロックが特定される場合、これは前の距離ブロックと置き換わるであろう。ｏｐｅｒａｔｉｏｎパラメータは、ルート計算中に考慮事項に追加され又は考慮から削除されるべきセグメントを示し、これは考慮事項からセグメントを削除することになる値ＡｄｄＢｌｏｃｋ、又はブロックされたリストからセグメントを除去し、したがって再考慮させることになる値ＲｅｍｏｖｅＢｌｏｃｋを有する可能性がある列挙である。パラメータｉｔｅｍｓは、ルート計算から省略するアイテムを表すＥＩＳのリストであり、道路セグメント、ルート操作（ｒｏｕｔｅ ｍａｎｅｕｖｅｒｓ）、又はルートの先の距離（ｄｉｓｔａｎｃｅ ａｈｅａｄ ｏｎ ｔｈｅ ｒｏｕｔｅ）を含むことができる。

ｒｅｓｐｏｎｓｅＢｌｏｃｋＲｏｕｔｅ（ｏｐｅｒａｔｉｏｎ，ｉｔｅｍｓ，ｖａｌｉｄＳｔａｔｅ）−これは、ｒｅｑｕｅｓｔＢｌｏｃｋＲｏｕｔｅへのサーバ応答である。ｏｐｅｒａｔｉｏｎパラメータ及びｉｔｅｍｓパラメータは、前述のパラメータと同様である。パラメータｖａｌｉｄｓｔａｔｅは、要求が成功したか否かを示す。

ｒｅｑｕｅｓｔＮｅｗＴｒｉｐ（ｄｅｓｔｉｎａｔｉｏｎｓ，ｒｏｕｔｅＭｏｄｅｓ）−この関数は、新しいトリップを作成する。新しいルート・ハンドル、すなわち、特定されたルート・オプションの各セットに対して作製される特定のルート・モードによって定義される、計算されたルートを識別する独自の識別子が存在するであろう。パラメータｄｅｓｔｉｎａｔｉｏｎｓは、ルート計算において用いられるべきルート要素を表す要素のリストである。パラメータｒｏｕｔｅＭｏｄｅｓは、ルート・モードを表す要素のリストである。渡された各ルート・モードに対してルート要素が作製されるであろう。

ｒｅｓｐｏｎｓｅＮｅｗＴｒｉｐ（ｄｅｓｔｉｎａｔｉｏｎｓ，ｒｏｕｔｅＭｏｄｅｓ，ｖａｌｉｄＳｔａｔｅ，ｈａｎｄｌｅｓ）−この関数は、特定されたルート・オプションの各セットに対するルート・ハンドル識別子を戻す。パラメータｈａｎｄｌｅｓは、ルート・ハンドルのリストである。リストの中のルート・ハンドルの順序は、特定されたルート・オプションの順序と合致する。ゼロのルート・ハンドル値は、ゼロ位置でのルート・オプションを伴うルートを識別する。

ｒｅｑｕｅｓｔＫｉｌｌＴｒｉｐ（ｈａｎｄｌｅｓ）−ルート・ハンドルのリストを破壊する。ターン・リスト及びルート詳細は、ルートに関連付けられた情報ツリーにおいてもはや利用可能ではないであろう。アクティブなルート・ハンドルの破壊は案内を取り消すであろう。この場合、以下で説明される関数ｉｎｆｏｒｍＡｃｔｉｖｅＲｏｕｔｅＤｅｓｃｒｉｐｔｉｏｎは、適宜更新されるであろう。

ｒｅｓｐｏｎｓｅＫｉｌｌＴｒｉｐ（ｈａｎｄｌｅｓ）−この関数は、破壊されているルート・ハンドルに対するサーバ応答である。

ｒｅｑｕｅｓｔＳｔａｒｔＧｕｉｄａｎｃｅ（ｒｏｕｔｅＨａｎｄｌｅ）−この関数は、ｒｏｕｔｅＨａｎｄｌｅによって表される特定されたルート・ハンドルに関連付けられたルートをスタートする。関数ｉｎｆｏｒｍＡｃｔｉｖｅＲｏｕｔｅＤｅｓｃｒｉｐｔｉｏｎは自動的に更新されるであろう。

ｒｅｑｕｅｓｔＳｔｏｐＧｕｉｄａｎｃｅ（ ）−すべてのルーティングをストップする。ＡｃｔｉｖｅＲｏｕｔｅＤｅｓｃｒｉｐｔｉｏｎは、自動的に更新されるであろう。案内がストップされるとき、ＡｃｔｉｖｅＲｏｕｔｅＤｅｓｃｒｉｐｔｉｏｎにおけるルート・ハンドルは−１となるであろう。

ｉｎｆｏｒｍＡｃｔｉｖｅＲｏｕｔｅＤｅｓｃｒｉｐｔｉｏｎ（ｒｏｕｔｅＤｅｓｃ）−目的地としても知られているアクティブなルート要素及び操作（ｍａｎｅｕｖｅｒ）としても知られているアクティブなルート・セグメントを識別する。−１のルート・ハンドルは、アクティブなルートがないことを示す。パラメータｒｏｕｔｅＤｅｓｃは、現在のアクティブなルート記述情報を表す。

ｉｎｆｏｒｍＮｅｘｔＭａｎｅｕｖｅｒＩｎｆｏ（ｔｉｍｅＤｉｓｔ，ｎｅｘｔＭａｎＩｎｆｏ）−次の操作までの残り時間及び距離を提供する。この関数は、ＡｃｔｉｖｅＲｏｕｔｅＤｅｓｃｒｉｐｔｉｏｎが有効なルート・ハンドルを含むときにのみ有効である。

ｉｎｆｏｒｍＮｅｘｔＤｅｓｔｉｎａｔｉｏｎＩｎｆｏＦｕｎｃｔｉｏｎ（ｎｅｘｔＤｅｓｔＩｎｆｏ）−次の目的地までの残り時間及び距離を提供する。ＡｃｔｉｖｅＲｏｕｔｅＤｅｓｃｒｉｐｔｉｏｎが有効なルート・ハンドルを含むときにのみ有効である。パラメータｎｅｘｔＤｅｓｔＩｎｆｏは、次の目的地に関する情報を表す。

ｉｎｆｏｒｍＣａｌｃｕｌａｔｉｏｎＳｔａｔｅ（ｒｏｕｔｅＨａｎｄｌｅ，ｃａｌｃＳｔａｔｅ，ｃａｌｃＰｅｒｃｅｎｔ）−この関数は、変化したルート計算状態についての情報を戻す。この応答は、ルートが選定された、計算された、再計算された、又は目的地に到着したときにクライアントに知らせるために送られる。これは、ルート・セグメント・リスト（ターン・リスト）を得ることをトリガする。パラメータｒｏｕｔｅＨａｎｄｌｅは、変化したルート・ハンドルを表し、ｃａｌｃＳｔａｔｅは、新しい計算状態（アイドル、選定中、選定済み、計算中、計算済み、ルーティング中、ルーティング済み、又は失敗）を表し、ｃａｌｃＰｅｒｃｅｎｔは、計算されたルートの全パーセンテージを表す（０〜１００又は利用可能ではない場合は−１）。

上記の関数は、ナビゲーション・プラットフォームがナビゲーション・ソリューションによって提供されるルーティング関数に影響を及ぼすのに好都合な方法を提供する可能性がある。例えば、特定された先の距離の特定のルートをブロックするコマンドをナビゲーション・ソリューションに発行するために、ｒｅｑｕｅｓｔＢｌｏｃｋＲｏｕｔｅ及びｒｅｓｐｏｎｓｅＢｌｏｃｋＲｏｕｔｅ関数が用いられてもよい。例えば、５０００メートル先のルートをブロックするために、クライアントは以下のコマンドを送信するであろう：

認識されるように、様々なルート・ブロック機能を達成するために、先のブロックを除去すること、全ルート・セグメントをブロックすること、ルート・セグメントの操作のみをブロックすることなどのナビゲーション・ルート・インターフェース・コンポーネント関数が用いられてもよい。さらに、例えば、特定のルート・ハンドルに対するルート・ブロックのリストを検索するために、図６に示された構造と類似した情報ツリー構造に格納されるルート情報と共に情報交換インターフェース・コンポーネントのＧｅｔＡｖａｉｌａｂｌｅＩｎｆｏｒｍａｔｉｏｎ関数が用いられてもよい：

ブロックされたセグメント（Ｂｌｏｃｋｅｄ Ｓｅｇｍｅｎｔ）＜ＢＬＫ＞は、ブロックされたセグメント操作（Ｂｌｏｃｋｅｄ Ｓｅｇｍｅｎｔ Ｍａｎｅｕｖｅｒｓ）及びブロックされた道路距離（Ｂｌｏｃｋｅｄ Ｒｏａｄ Ｄｉｓｔａｎｃｅ）を含むルートに対するすべてのタイプのブロックされたアイテムを含むであろう。

以下の例は、上記の関数と共に実装されてもよいルート・オプション・ツリー拡張を例証する：

上記の戻されたＥＩＳは以下のことを示す：要求されたルート・オプション（Ｒｅｑｕｅｓｔｅｄ ｒｏｕｔｅ ｏｐｔｉｏｎｓ），＜ＲＴＯ＞ｆａｓｔｅｓｔ｜ａｖｏｉｄＭｏｔｏｒｗａｙｓ＜＊＞；実現されなかったルート・オプション（Ｕｎｆｕｌｆｉｌｌｅｄ Ｒｏｕｔｅ Ｏｐｔｉｏｎｓ），＜ＵＲＯ＞ａｖｏｉｄＭｏｔｏｒｗａｙｓ＜＊＞；ルートに対する回避型（Ａｖｏｉｄａｎｃｅ ｔｙｐｅｓ ｏｎ ｒｏｕｔｅ），＜ＲＡＴ＞ａｖｏｉｄＭｏｔｏｒｗａｙｓ｜ａｖｏｉｄＵｎｐａｖｅｄ＜＊＞；ルート計算状態（Ｒｏｕｔｅ Ｃａｌｃｕｌａｔｉｏｎ ｓｔａｔｅ），＜ＲＣＳ＞Ｃａｌｃｕｌａｔｅｄ＜＊＞；真の道路距離（デシメートル）（Ｒｅａｌ Ｒｏａｄ Ｄｉｓｔａｎｃｅ（ｄｅｃｉｍｅｔｅｒｓ）），＜ＲＲＤ＞２４５３２０＜＊＞；残り移動時間（Ｒｅｍａｉｎｉｎｇ Ｔｒａｖｅｌ Ｔｉｍｅ）（ｍｓ），＜ＴＲＴ＞３７５６３２４＜＊＞
（ナビゲーション音声インターフェース・コンポーネント）
ナビゲーション音声インターフェース・コンポーネントは、ナビゲーション・サーバ・コンポーネントによって提供される音声サービスをナビゲーション・クライアント・コンポーネントが使用できるようにするための関数を含む。

ｉｎｆｏｒｍＰｒｏｍｐｔＲｅａｄｙ（ａｕｄｉｏＳｏｕｒｃｅ）−この関数は、ナビゲーション・サーバ上で提供され、プロンプトの準備ができていることをクライアントに示す。パラメータａｕｄｉｏＳｏｕｒｃｅは、ａｕｄｉｏＩｄｌｅ：デフォルトのナビゲーション音声ソース（ナビゲーション音声が現在再生されていないことを示す）、ａｕｄｉｏＡｕｔｏｍａｔｉｃ：ナビゲーション・コアにより開始される音声ソース、例えば、操作場所への車両の接近によってトリガされるターン推奨、ａｕｄｉｏＭａｎｕａｌ：例えば、ユーザがナビゲーション・プロンプトの繰返しを要求する場合にユーザにより開始される音声ソース、のうちの可能な値を有する列挙であってもよい。

ｒｅｑｕｅｓｔＰｒｏｍｐｔＲｅａｄｙ（ａｕｄｉｏＳｏｕｒｃｅ）−このクライアント関数は、プロンプトが特定された音声ソース上で再生されてもよいことをナビゲーション・サーバに示す。

ｒｅｑｕｅｓｔＳｅｔＡＤＡ（ａｄａＳｔａｔｅ）−この関数は、音響運転アナウンス（ａｃｏｕｓｔｉｃ ｄｒｉｖｉｎｇ ａｎｎｏｕｎｃｅｍｅｎｔ）（ＡＤＡ）を有効にする又は無効にする。パラメータａｄａＳｔａｔｅは、バイナリ状態表示である。同じバイナリ状態でのその後の呼出しは無視されることになる。

ｉｎｆｏｒｍＡＤＡＩｓＥｎａｂｌｅｄ（ｉｓＥｎａｂｌｅｄ）−この関数は、ＡＤＡが有効にされる又は無効にされることを示す。ＩｓＥｎａｂｌｅｄがＴＲＵＥである場合、ナビゲーション音声アナウンスが再生されるであろう。ＩｓＥｎａｂｌｅｄがＦＡＬＳＥである場合、ナビゲーション音声アナウンスは再生されないであろう。

ｒｅｑｕｅｓｔＣａｎｃｅｌＡＤＡ（ ）−これは、現在の音響運転アナウンス（ＡＤＡ）を取り消す関数である。この関数呼出しは、現在出力されたＡＤＡにのみ影響し、その後のＡＤＡに対する影響はもたない。

ｒｅｑｕｅｓｔＲｅｐｅａｔＡＤＡ（ ）−これは、最後のＡＤＡを繰返す関数である。最後のＡＤＡは、繰返されることになる。これまでＡＤＡが出力されていなかった場合、呼出しは無視されることになる。

ｉｎｆｏｒｍＡｃｔｉｖｅＡｕｄｉｏＳｏｕｒｃｅ（ａｕｄｉｏＳｏｕｒｃｅ）−この関数は、現在再生中の音声ソースを戻すであろう。ａｕｄｉｏＳｏｕｒｃｅによって表される状態は、アイドル、自動、又は手動であってもよい。パラメータａｕｄｉｏＳｏｕｒｃｅは、現在再生中の音声ソースを表す。

上記の関数を用いる例となるシーケンスを、ここで図１０を参照して説明する。ナビゲーション・クライアントは、対応する音声が再生される前にｒｅｑｕｅｓｔＰｒｏｍｐｔＲｅａｄｙ関数を開始してもよい。したがって、シーケンスにおける第１のステップは、ナビゲーション・サーバが音声プロンプトを再生する準備ができたことを信号送信するためにｉｎｆｏｒｍＰｒｏｍｐｔＲｅａｄｙメッセージを発行する。これの次に、ナビゲーション・ソリューションが音声送達を始めるための許可を示す、ｒｅｑｕｅｓｔＰｒｏｍｐｔＲｅａｄｙコマンドの形態の、ＨＭＩ（及びナビゲーション・クライアント・コンポーネント）からの通知がなされる。次いで、ナビゲーション・サーバは、ｉｎｆｏｒｍＡｃｔｉｖｅＡｕｄｉｏソースに応答してアクティブな音声ソースをアイドルから手動に変化させる。クライアントがｉｎｆｏｒｍＰｒｏｍｐｔＲｅａｄｙメッセージを受信するときに、これは音声属性を現在の音声ソースに設定し、音声の再生を始めるであろう。これが終わったときに、これはＡｕｄｉｏＰｒｏｍｐｔ属性をアイドルに設定するであろう。ＨＭＩは、音声ソースを変化させるためにこのトリガを用いてもよい。

（トラフィック・メッセージ・チャンネル・インターフェース・コンポーネント）
トラフィック・メッセージ・チャンネル・インターフェース・コンポーネントは、ナビゲーション・プラットフォームがナビゲーション・ソリューションによって提供されるＴＭＣに関連する機能を使用できるようにするための関数のグループを含む。

ｒｅｑｕｅｓｔＳｅｔＴＭＣＭｏｄｅ（ｔｍｃＭｏｄｅ）−この関数は、サーバがＴＭＣ情報を処理するのを有効にする及び無効にする。ＴＭＣが無効にされるときに、メッセージは表示された地図から削除されてもよく、ＴＭＣメッセージリストが消去される。

ｉｎｆｏｒｍＴＭＣＭｏｄｅ（ｔｍｃＳｔａｔｅ）−新しいＴＭＣ情報が受信されていることをクライアントに知らせる。この情報は、監視されたＴＭＣ情報を要求することのトリガである。サーバは、初期化後に及び変化時に信号を一度送信するであろう。パラメータｔｍｃＳｔａｔｅは、ＴＭＣ処理がオン又はオフに切換えられることを示すためのバイナリインジケータである。

ｒｅｑｕｅｓｔＳｅｔＴＭＣＲｏｕｔｅＭｏｄｅ（ｔｍｃＲｏｕｔｅＭｏｄｅ，ｍｉｎｕｔｅｓ）−この関数は、ＴＭＣイベントによりサーバが新しいルートを提供するときに代替ルートの受け入れモードを設定する。パラメータｔｍｃＲｏｕｔｅＭｏｄｅは、ｔｍｃＯｆｆ（ルート計算中にＴＭＣメッセージを考慮しないことを表す）、ｔｍｃＡｕｔｏｍａｔｉｃ（ルート計算中にＴＭＣメッセージを考慮し、サーバが計算されたルートを自動的に受け入れることを表す）、ｔｍｃＭａｎｕａｌ（ルート計算中にＴＭＣメッセージを考慮するが、サーバは計算されたルートを自動的に受け入れないことを表す）、又はｔｍｃＤｅｌａｙ（現在のルートが特定された遅延時間を超過する場合にのみサーバが現在のルートを変化させることを表す）、の値を有する列挙であってもよい。パラメータｍｉｎｕｔｅｓは、最小の残り時間差を表す。サーバは、新しいルートが現在のルートよりも所与の時間差だけ速い場合にのみ新しいルートを提供するであろう。差が所与の時間よりも小さい場合、計算されたルートは却下されるであろう。

ｉｎｆｏｒｍＴＭＣＲｏｕｔｅＭｏｄｅ（ｔｍｃＲｏｕｔｅＭｏｄｅ，ｍｉｎｕｔｅｓ）−この関数は、現在のＴＭＣルート・モードをクライアントに知らせる。サーバは、初期化後に及び変化時に信号を一度送信するであろう。

ｉｎｆｏｒｍＴＭＣＩｎｆｏＣｈａｎｇｅｄ（ｔｍｃＩｎｆｏ）−この関数は、新しいＴＭＣ情報が受信されていることをクライアントに知らせる。この情報は、監視されたＴＭＣ情報を要求することのトリガである。

ｉｎｆｏｒｍＴＭＣＯｎＲｏｕｔｅＣｈａｎｇｅｄ−特定されたルート・ハンドル上で新しいＴＭＣ情報が受信されていることをクライアントに知らせる。この情報は、監視されたＴＭＣ情報を要求することのトリガである。

ｉｎｆｏｒｍＴＭＣＲｏｕｔｅｓＡｖａｉｌａｂｌｅ（ｒｏｕｔｅＬｉｓｔ，ｔｍｃＮｅｗＥｖｅｎｔｓ，ｔｍｃＤｅｌｅｔｅｄＥｖｅｎｔｓ）−この関数は、受け入れモードがｔｍｃＭａｎｕａｌであるときに受信したＴＭＣ情報に基づいて利用可能な代替ルートをクライアントに知らせる。パラメータｒｏｕｔｅＬｉｓｔは、更新されたＴＭＣ情報を伴うルート・ハンドルのリストを表す。パラメータｔｍｃＮｅｗＥｖｅｎｔｓは、代替ルートの計算をもたらす最も有意な新しいｔｍｃイベントのリストを表す。パラメータｔｍｃＤｅｌｅｔｅｄＥｖｅｎｔｓは、代替ルートの計算をもたらす最も有意な削除されたｔｍｃイベントのリストを表す。この情報は、監視されたＴＭＣ情報を要求することのトリガである。

ｒｅｑｕｅｓｔＴＭＣＩｇｎｏｒｅ−これは、無視する又は無視をストップするべきイベント又はＴＭＣイベントのグループを特定する関数である。無視されるＴＭＣメッセージ及びグループは、ルート計算の考慮事項から除去されるであろう。無視されたＴＭＣメッセージは、＜ＩＦＴ＞ＴＭＣ＜＊＞＜ＲＱＴ＞ＩｇｎｏｒｅｄＭｅｓｓａｇｅｓ＜＊＞で情報インターフェースにおいて利用可能となるであろう。無視されたＴＭＣメッセージ・グループは、＜ＩＦＴ＞ＴＭＣ＜＊＞＜ＲＱＴ＞ＩｇｎｏｒｅｄＭｅｓｓａｇｅＧｒｏｕｐｓ＜ｉｎｆｏｒｍで情報インターフェースにおいて利用可能となるであろう。ＴＭＣＩｇｎｏｒｅｓＣｈａｎｇｅｄは、ＴＭＣＩｇｎｏｒｅ関数が完了した後でサーバによって呼び出されるであろう。これは、無視が更新されていることをクライアントに知らせるであろう。

ｉｎｆｏｒｍＴＭＣＩｇｎｏｒｅｓＣｈａｎｇｅｄ−無視されたＴＭＣ情報が変化していることをクライアントに知らせる関数である。この情報は、監視されたＴＭＣ情報を要求することのトリガである。

ｒｅｑｕｅｓｔＴＭＣＡｖｏｉｄ−回避する又は回避をストップするべきイベント又はＴＭＣイベントのグループを特定する。回避されたＴＭＣメッセージ及びグループは、ルート計算の目的でそれらに課される付加的なペナルティを有するであろう。回避されたＴＭＣメッセージは、＜ＩＦＴ＞ＴＭＣ＜＊＞＜ＲＱＴ＞ＡｖｏｉｄｅｄＭｅｓｓａｇｅｓ＜＊＞で情報インターフェースにおいて利用可能となるであろう。回避されたＴＭＣメッセージ・グループは、＜ＩＦＴ＞ＴＭＣ＜＊＞＜ＲＱＴ＞ＡｖｏｉｄｅｄＭｅｓｓａｇｅＧｒｏｕｐｓ＜＊＞で情報インターフェースにおいて利用可能となるであろう。関数ｉｎｆｏｒｍＴＭＣＡｖｏｉｄｓＣｈａｎｇｅｄは、ｔｍｃ回避関数が完了した後でサーバによって呼び出されるであろう。これは、回避が更新されていることをクライアントに知らせるであろう。

ｉｎｆｏｒｍＴＭＣＡｖｏｉｄｓＣｈａｎｇｅｄ−これは、回避されたＴＭＣ情報が変化していることをクライアントに知らせる。この情報は、監視されたＴＭＣ情報を要求することのトリガである。

上述の実装が本発明を例証することを当業者は認識するであろう。ＡＰＩは、ナビゲーション・ソリューションの根底にある複雑さに対する抽象化層を提供する。例えば、代替ルートを伴う複雑なルート全体像を描画するためにナビゲーション・プラットフォームが多数の複雑なプログラミングレベルコマンドをナビゲーション・ソリューションに発行することを要求する代わりに、ナビゲーション・プラットフォームは、ナビゲーション・ソリューションが例となるＡＰＩを定義する予め定義された関数の標準セットに従って構成されるため、より高レベルのステップに関係する上記で開示された高レベルの例となる関数のような比較的より少ないコマンドを発行してもよい。さらに、ＡＰＩは、ナビゲーション・プラットフォームへのナビゲーション・ソリューションの柔軟且つ効率的な統合、ホスト・ナビゲーション・プラットフォームの開発から独立しているナビゲーション・ソリューションの高速プロトタイピング、並びにあらゆるナビゲーション・ソリューションから利用可能な情報タイプ及び機能の発見を可能にする。

上記の実装の説明は、例証する及び説明する目的で提示されている。これは網羅的なものではなく、特許請求される本発明を開示された正確な形態に限定しない。上記の説明に照らして修正及び変形が可能であり、又はこれらは本発明の実施から得られてもよい。請求項及びそれらの均等物が本発明の範囲を定義する。

Claims (11)

1. ナビゲーション・ソリューションとインターフェースするためのアプリケーション・インターフェースを含むナビゲーション・プラットフォームを備えるナビゲーション・システムであって、前記インターフェースが、前記ナビゲーション・ソリューションによって提供される対応する関数と協働するように適合された予め定義された関数のセットを含む、ナビゲーション・システム。
2. 前記アプリケーション・インターフェースが、前記ナビゲーション・プラットフォームから独立してナビゲーション・ソリューションが機能的に評価されることを可能にするための高速プロトタイピング・インターフェース・コンポーネントを含む、請求項１に記載のナビゲーション・システム。
3. 前記ナビゲーション・ソリューションの視覚出力を構成するための関数が、前記ナビゲーション・プラットフォーム上のディスプレイ・デバイス上に前記ナビゲーション・ソリューションの視覚出力を位置付けるための関数を含む、請求項２に記載のナビゲーション・システム。
4. 前記予め定義された関数が、前記ナビゲーション・ソリューションへの要求を作成し、及び前記ナビゲーション・ソリューションからの応答を受信させ、これによりクライアント−サーバ・アーキテクチャを実装するように構成される、請求項１に記載のナビゲーション・システム。
5. 前記アプリケーション・インターフェースが、前記ナビゲーション・ソリューションから利用可能な情報を発見するための情報発見及び交換インターフェース・コンポーネントを含む、請求項１に記載のナビゲーション・システム。
6. 前記情報交換インターフェース・コンポーネントが、前記ナビゲーション・ソリューションから利用可能な前記情報のタイプを判定するための少なくとも１つの関数を含む、請求項５に記載のナビゲーション・システム。
7. 前記情報交換インターフェース・コンポーネントが、前記ナビゲーション・ソリューションから利用可能な情報タイプのリストを要求するための少なくとも１つの関数を含む、請求項５に記載のナビゲーション・システム。
8. 前記ナビゲーション・プラットフォームと前記ナビゲーション・ソリューションとの間のプロセス間通信を可能にするためのプロセス間通信インターフェースをさらに備える、請求項１に記載のナビゲーション・システム。
9. ナビゲーション・プラットフォームにナビゲーション・ソリューションを統合する方法であって、
   前記ナビゲーション・プラットフォーム上のアプリケーション・プログラミング・インターフェースであり、予め定義された関数のセットを含む、アプリケーション・プログラミング・インターフェースを提供するステップと、
   前記アプリケーション・プログラミング・インターフェースを伴うナビゲーション・ソリューションを提供するステップと、
   前記予め定義された関数のセットを介して、前記ナビゲーション・ソリューションからの情報を要求するステップと、
   を含む方法。
10. 前記アプリケーション・プログラミング・インターフェースが、高速プロトタイピング・インターフェース・コンポーネントを含み、且つ、前記高速プロトタイピング・インターフェース・コンポーネントを用いて前記ナビゲーション・ソリューションを評価するステップをさらに含む、請求項９に記載の方法。
11. 前記アプリケーション・プログラミング・インターフェースが、情報発見及び交換コンポーネントを含み、前記情報発見及び交換コンポーネントを用いて前記ナビゲーション・ソリューションから利用可能な情報を発見するステップをさらに含む、請求項９に記載の方法。

Images