説明

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

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

【発明の詳細な説明】
【技術分野】
【0001】
この出願は、車両ナビゲーション・システムを含むナビゲーション・システムの分野に関する。より具体的には、本出願は、アプリケーション・プログラミング・インターフェース(API)を含むナビゲーション・システムに関する。
【背景技術】
【0002】
ナビゲーション・システムは、ナビゲーション・アプリケーションを実行する指定された手持ち式ユニット又は移動電話のような車両搭載システム又は携帯型デバイスである場合がある。しばしば、車両ナビゲーション・システムの場合には、システムは、より大きいインフォテインメント・システムの一部であり、これは車両ユーザに娯楽サービス及び情報サービスを提供する。ナビゲーション・システムは、典型的に、ナビゲーション・プラットフォームと、ナビゲーション・ソリューションとも称される基本となるナビゲーション・コア・アプリケーションとを含む。ナビゲーション・プラットフォームは、典型的に、ハードウェア・アーキテクチャと、オペレーティング・システムを含むソフトウェア・フレームワークと、ナビゲーション・ソリューションの実行及びこれとユーザとの対話をサポートする、関連するユーザ・インターフェースとを含む。ナビゲーション・ソリューションは、典型的に、「バックエンド」ソフトウェアと、ルート選定及び案内のようなコア・ナビゲーション機能、並びに地図、住所、及び関心地点(POI)情報を提供する、関連するデータベースである。
【発明の概要】
【発明が解決しようとする課題】
【0003】
ナビゲーション・システム、特に車両ナビゲーション・システムは、複雑な特注で作られるシステムに発展しており、これは歴史的に相手先商標製品製造会社(OEM製)によって、ナビゲーション・プラットフォームとナビゲーション・ソリューションとの両方が単一システムとして一緒に開発され構築される組込み情報システムとして開発されている。より最近の傾向では、OEM製は外部のナビゲーション・ソリューションの専門技術を活用しており、ナビゲーション・ソリューションの外部業者に頼っている。典型的な開発サイクルでは、ナビゲーション又はインフォテインメント・システムOEMは、車両製造業者のような顧客によって定義された要件に基づいて新しいナビゲーション・プラットフォームを設計する場合がある。次に、ナビゲーション・システムOEMは、ナビゲーション・プラットフォームへの統合に関する具体的要件を満たすことができる特注で作られるナビゲーション・ソリューションを必要とするであろう。ナビゲーション・ソリューションの統合ステップは、ナビゲーション・プラットフォームが具体的且つ複雑な方法でナビゲーション・ソリューションとインターフェースするように構成されるため、しばしば複雑であり、入り組んでいる。したがって、特定の提供業者により開発されたナビゲーション・ソリューションは、特定のOEMナビゲーション・プラットフォームに具体的に特注で作られることになり、プラットフォームが非常に具体的且つしばしば複雑な方法でソリューションとインターフェースすることを必要とするであろう。ナビゲーション・ソリューションの特定の提供業者に頼っているナビゲーション・システムOEMは、将来のソリューションの調達についてもその提供業者に幾分委ねられる可能性がある。したがって、ナビゲーション・システム開発の経済性は、付加費用と能率の悪さによって特徴付けられ、これは、ナビゲーション・プラットフォームへのナビゲーション・ソリューションの統合に対してより高い柔軟性が提供されれば低減される可能性がある。
【0004】
別の問題は、ナビゲーション・プラットフォームとナビゲーション・ソリューションとのそれぞれの異なる開発サイクルに関係する。ナビゲーション・プラットフォームの開発は、年ごとのサイクル又は車両モデルのサイクルであり、一方、ナビゲーション・ソリューションの開発サイクルは、そのように限定されず、典型的にはより速い。新技術は、ナビゲーション・ソリューションの特徴及び機能を頻繁にアップグレードできるようにする可能性がある。他方では、ナビゲーション・システムへのこうした特徴及び機能の統合は、次世代のナビゲーション・プラットフォームが開発されるまで待たなければならない場合がある。例として、ユーザに最良の車線を提案する新しい車線推奨特徴を提供するために適切なデータベース情報でアップグレードされているナビゲーション・ソリューションを考える。現在の技術環境及び経済環境では、こうした特徴をOEMナビゲーション・システムに追加することは、新しい特徴にアクセスするためにナビゲーション・プラットフォームへの大きな修正又は完全な再設計さえも普通は必要とするであろう。したがって、ナビゲーション・プラットフォームがナビゲーション・ソリューションで利用可能な新しい機能を発見し及び統合するための方法を提供することが有利となるであろう。
【0005】
また別の問題は、ナビゲーション・ソリューションの性能と互換性を、普通はナビゲーション・ソリューションがホスト・ナビゲーション・プラットフォームに統合されるまでは十分に評価することができないことである。同様に、OEM製ナビゲーション・システムは、プラットフォームとソリューションとの両方が仕上がるまではナビゲーション・ソリューションとプラットフォームとの互換性を試験する難しさを有する。したがって、ホスト・ナビゲーション・プラットフォームの開発に依存せずにナビゲーション・ソリューションのプロトタイピングを進めることができるようにすることが望ましいであろう。
【0006】
したがって、当該技術分野では、上述の問題に対処し、且つナビゲーション・プラットフォームへのナビゲーション・ソリューションのより効率的且つ柔軟な統合を容易にする改善が必要とされている。上述の短所及び他の短所は、本発明の態様に係るナビゲーション・システム及び関係する方法によって対処される。
【課題を解決するための手段】
【0007】
本発明は、標準化されたアプリケーション・プログラミング・インターフェース(API)を使用するナビゲーション・システムを提供する。APIは、ナビゲーション・ソリューションの根底にある複雑さの抽象化を提供する。したがって、ソリューションの中にある複雑なナビゲーション関数は、比較的簡単な要求を用いてナビゲーション・プラットフォームによってアクセスされてもよい。さらに、ナビゲーション・プラットフォームとナビゲーション・ソリューションとの両方は、予め定義されたAPIを通じてインターフェースするように開発されてもよく、したがって開発及び統合におけるより高い柔軟性及び効率を可能にする。
【0008】
APIは、高速プロトタイピング、初期化、ビュー設定、情報発見及び交換、車両位置、ルート案内、ナビゲーション音声、及びトラフィック・メッセージ・チャンネル(TMC)コンポーネントに対するインターフェース・コンポーネントを含む。これらのインターフェース・コンポーネントは、ナビゲーション・プラットフォームとナビゲーション・ソリューションとの間の高レベル対話を達成するために標準関数セットによって定義される。
【0009】
高速プロトタイピング・インターフェース・コンポーネントは、ナビゲーション・ソリューションとナビゲーション・プラットフォームとの効率的な統合を保証するのに必要最小限のAPI関数セットを含んでもよい。ホスト・ナビゲーション・プラットフォームとナビゲーション・ソリューションは、高速プロトタイピング・インターフェース・コンポーネントに従ってインターフェースするように構成されてもよく、これにより互換性が保証される。したがって、ナビゲーション・ソリューションは、既存のナビゲーション・プラットフォームへのフル統合を必要とすることなく開発され、プロトタイプ製作されてもよい。初期化インターフェース・コンポーネントは、ナビゲーション・ソリューション及びプラットフォームに対する標準初期化シーケンスを提供する。
【0010】
情報発見及び交換インターフェース・コンポーネントは、ナビゲーション・ソリューションによって与えられるすべての情報及び機能をナビゲーション・プラットフォームが発見し及び使用することを可能にする。したがって、ナビゲーション・ソリューションにおいて提供される開示された機能は、ナビゲーション・プラットフォームの修正を必要とすることなく発見され及び使用される可能性がある。
【0011】
本発明の実装の例によれば、APIは、クライアント−サーバ・アーキテクチャに実装されてもよい。ナビゲーション・プラットフォームは、ナビゲーション・ソリューションによって提供されるナビゲーション・サーバ・コンポーネントとAPIを介してインターフェースするように構成された、ナビゲーション・クライアント・コンポーネントを含んでもよい。ナビゲーション・クライアント・コンポーネントは、ナビゲーション・サーバ・コンポーネントに要求コマンドを発行してもよい。同様に、ナビゲーション・サーバ・コンポーネントは、クライアント・コンポーネントに応答コマンド又はメッセージを発行する。要求及び応答メッセージは、高レベル関数呼出しとして実装されてもよく、C++のようなオブジェクト指向プログラミング言語で定義されてもよい。
【0012】
本発明の他のデバイス、装置、システム、方法、特徴、及び利点は、当業者には明らかであろう、又は以下の図面及び詳細な説明を考察することによって明らかとなるであろう。この説明の中でのすべてのこうした付加的なシステム、方法、特徴、及び利点は、本発明の範囲内となる及び添付の請求項によって保護されることを意図される。
【0013】
本発明は、以下の図面を参照することによってより良く理解されるであろう。図中のコンポーネントは必ずしも原寸に比例しておらず、代わりに、本発明の原理を例証することに重点が置かれている。図面では、異なる図の全体を通して同様の参照番号は対応する部分を表す。
【0014】
例えば、本願発明は以下の項目を提供する。
(項目1)
ナビゲーション・ソリューションとインターフェースするためのアプリケーション・インターフェースを含むナビゲーション・プラットフォームを備えるナビゲーション・システムであって、前記インターフェースが、前記ナビゲーション・ソリューションによって提供される対応する関数と協働するように適合された予め定義された関数のセットを含む、ナビゲーション・システム。
(項目2)
前記アプリケーション・インターフェースが、前記ナビゲーション・プラットフォームから独立してナビゲーション・ソリューションが機能的に評価されることを可能にするための高速プロトタイピング・インターフェース・コンポーネントを含む、上記項目に記載のナビゲーション・システム。
(項目3)
前記ナビゲーション・ソリューションの視覚出力を構成するための関数が、前記ナビゲーション・プラットフォーム上のディスプレイ・デバイス上に前記ナビゲーション・ソリューションの視覚出力を位置付けるための関数を含む、上記いずれかの項目に記載のナビゲーション・システム。
(項目4)
前記予め定義された関数が、前記ナビゲーション・ソリューションへの要求を作成し、及び前記ナビゲーション・ソリューションからの応答を受信させ、これによりクライアント−サーバ・アーキテクチャを実装するように構成される、上記いずれかの項目に記載のナビゲーション・システム。
(項目5)
前記アプリケーション・インターフェースが、前記ナビゲーション・ソリューションから利用可能な情報を発見するための情報発見及び交換インターフェース・コンポーネントを含む、上記いずれかの項目に記載のナビゲーション・システム。
(項目6)
前記情報交換インターフェース・コンポーネントが、前記ナビゲーション・ソリューションから利用可能な前記情報のタイプを判定するための少なくとも1つの関数を含む、上記いずれかの項目に記載のナビゲーション・システム。
(項目7)
前記情報交換インターフェース・コンポーネントが、前記ナビゲーション・ソリューションから利用可能な情報タイプのリストを要求するための少なくとも1つの関数を含む、上記いずれかの項目に記載のナビゲーション・システム。
(項目8)
前記ナビゲーション・プラットフォームと前記ナビゲーション・ソリューションとの間のプロセス間通信を可能にするためのプロセス間通信インターフェースをさらに備える、上記いずれかの項目に記載のナビゲーション・システム。
(項目9)
ナビゲーション・プラットフォームにナビゲーション・ソリューションを統合する方法であって、
前記ナビゲーション・プラットフォーム上のアプリケーション・プログラミング・インターフェースであり、予め定義された関数のセットを含む、アプリケーション・プログラミング・インターフェースを提供するステップと、
前記アプリケーション・プログラミング・インターフェースを伴うナビゲーション・ソリューションを提供するステップと、
前記予め定義された関数のセットを介して、前記ナビゲーション・ソリューションからの情報を要求するステップと、
を含む方法。
(項目10)
前記アプリケーション・プログラミング・インターフェースが、高速プロトタイピング・インターフェース・コンポーネントを含み、且つ、前記高速プロトタイピング・インターフェース・コンポーネントを用いて前記ナビゲーション・ソリューションを評価するステップをさらに含む、上記項目に記載の方法。
(項目11)
前記アプリケーション・プログラミング・インターフェースが、情報発見及び交換コンポーネントを含み、前記情報発見及び交換コンポーネントを用いて前記ナビゲーション・ソリューションから利用可能な情報を発見するステップをさらに含む、上記いずれかの項目に記載の方法。
【0015】
(摘要)
ナビゲーション・システムは、ナビゲーション・ソリューションをナビゲーション・プラットフォームに効率的に統合できるようにするためにアプリケーション・プログラミング・インターフェースを備える。システムは、クライアント−サーバ・アーキテクチャを含み、APIは、それぞれクライアント及びサーバにおいて定義された要求関数と応答関数の標準化されたセットと共に実装される。APIは、特定のナビゲーション・プラットフォームから独立してナビゲーション・ソリューションを開発できるようにするための高速プロトタイピング・インターフェース・コンポーネントを含む。情報発見及び交換インターフェース・コンポーネントは、ナビゲーション・プラットフォーム(クライアント)がナビゲーション・ソリューション(サーバ)ナビゲーション・ソリューションから利用可能な情報を発見し及び検索することを可能にする。
【図面の簡単な説明】
【0016】
【図1】本発明の一実装の例に係るナビゲーション・システムのブロック図である。
【図2】本発明の実装の例に係るAPIを含む図1のナビゲーション・システムに適用可能なナビゲーション・システム・アーキテクチャのブロック図である。
【図3】本発明の一実装の例に係る図1のナビゲーション・システムのコンポーネント及びインターフェースを例証するブロック図である。
【図4】本発明の実装の例に係るAPIのインターフェース・コンポーネントを示すブロック図である。
【図5】初期化インターフェースのための要求−応答ダイアログの一例を例証するシーケンス図である。
【図6】情報発見及び交換インターフェース・コンポーネントを実装するのに適した情報ツリー構造の一例を示す情報ツリー図である。
【図7】情報発見及び交換のための例となるプロセスを例証するシーケンス図である。
【図8】情報発見及び交換インターフェースにおいて国情報を得るためのプロセスの一例を例証するシーケンス図である。
【図9A】情報交換インターフェースにおいて州情報を得るための例となるプロセスを例証するシーケンス図である。
【図9B】情報交換インターフェースにおいて州情報を得るための例となるプロセスを例証するシーケンス図である。
【図10】ナビゲーション音声インターフェース・コンポーネントによって行われる例となるプロセスを示すシーケンス図である。
【発明を実施するための形態】
【0017】
この出願に含まれた図面と組み合わせて説明される1つ又は複数のプロセス、サブプロセス、又はプロセスステップは、ハードウェア及び/又はソフトウェアによって行われてもよいことが当業者によって理解され及び認識されるであろう。プロセスがソフトウェアによって行われる場合、ソフトウェアは、図面に概略的に描かれた機能コンポーネント又はモジュールのうちの1つ又は複数のような適切な電子処理コンポーネント又はシステムのソフトウェア・メモリにあってもよい。ソフトウェア・メモリにおけるソフトウェアは、論理関数(すなわち、デジタル回路又はソースコードのようなデジタル形式又はアナログ回路又はアナログソース、例えばアナログ電気信号、音、又はビデオ信号のようなアナログ形式のいずれかで実装されてもよい「論理」)を実装するための実行可能な命令の順序付けられたリストを含んでもよく、命令実行システム、装置、又はデバイスから命令を選択的にフェッチし及び命令を実行してもよいコンピュータベースのシステム、プロセッサを含んでいるシステム、又は他のシステムのような命令実行システム、装置、又はデバイスによって又はこれらと組み合わせて用いられる任意のコンピュータ可読媒体において選択的に具体化されてもよい。この開示との関連において、「コンピュータ可読媒体」は、命令実行システム、装置、又はデバイスによって又はこれらと組み合わせて用いられるプログラムを収容し又は格納してもよい任意の手段である。コンピュータ可読媒体は、選択的に、例えば、これらに限定はされないが、電子、磁気、光、電磁気、赤外線、又は半導体システム、装置、又はデバイスであってもよい。コンピュータ可読媒体の、網羅的なリストではないが、より具体的な例は、携帯型コンピュータ・ディスケット(磁気)、RAM(電子)、読出し専用メモリ「ROM」(電子)、消去可能プログラム可能読出し専用メモリ(EPROM又はフラッシュメモリ)(電子)、及び携帯型コンパクト・ディスク読出し専用メモリ「CDROM」(光学)を含むであろう。プログラムは、例えば、紙の光学走査、パンチカードの読取り、又は他の媒体を介して電子的に取り込まれ、次いで必要な場合に適切な様態でコンパイルされ、解釈され、又は他の方法で処理され、次いでコンピュータメモリに格納されてもよいため、コンピュータ可読媒体は、プログラムがその上に恒久的に固定される紙又は別の適切な媒体であってもよいことに留意されたい。本明細書で開示される場合のプロセッサは、マイクロプロセッサ、中央処理装置(CPU)、デジタル信号プロセッサ、若しくはコンピュータ可読媒体に格納された命令を実行するための機械を構成する他のデジタル又はアナログコンポーネントを含んでもよい。
【0018】
図1は、本発明の一実装の例に係るナビゲーション・システム100のブロック図である。ナビゲーション・システム100は、ナビゲーション・プラットフォーム110と、以下で詳細に説明されることになるアプリケーション・プログラミング・インターフェース130を通じて協働するナビゲーション・ソリューション120とを含む。ナビゲーション・プラットフォーム110は、ナビゲーション・コンピュータ140、ヒト−機械インターフェース(HMI)150、搭載センサ170、及び通信ユニット180を含む。
【0019】
ナビゲーション・コンピュータ140は、一般に、バス146を介して電子通信するプロセッサ142及び記憶装置144を含む。記憶装置144は、情報の記憶を提供する電子メモリコンポーネントであり、プロセッサ142、及び固定記憶装置(内部ハードディスク又は統合型ソリッドステートメモリ)、並びにリムーバブル記憶装置コンポーネント(フラッシュディスク、リムーバブルメモリカードなど)に対するデータ及び命令を含んでもよい。認識されるように、記憶装置要素144は、ローカル記憶装置とリモート記憶装置(例えば、ネットワーク接続を介して遠隔的にアクセス可能なクラウドベースの記憶装置コンポーネント)との両方を表す。記憶装置144は、データ146の記憶とプロセッサ142に対する命令を提供する。命令は、オペレーティング・システム148と、指定されたタスクを行うためにプロセッサ142を介してオペレーティング・システム148内で実行する1つ又は複数のアプリケーション149を提供してもよい。バス146はまた、指定されたグラフィックス処理コンポーネントを含むグラフィックス処理装置141と通信し、信号をディスプレイ152に提供してもよい。ナビゲーション・コンピュータ140は、車両バスインターフェース143を通じて車両サブシステムと通信してもよい。
【0020】
HMI150は、ナビゲーション・プラットフォーム110とのユーザ対話を可能にし、ディスプレイ152、音声入力デバイス154、音声出力デバイス156、及び触覚入力デバイス158を含んでもよく、触覚入力デバイス158は、ユーザがナビゲーション・プラットフォーム100と触覚的な方法で対話することを可能にするキーボード、タッチスクリーン、ダッシュボード、若しくはコンソール制御又は他のデバイスを含んでもよい。
【0021】
コントローラ・エリア・ネットワーク(CAN)バス規格に準拠するバスを含んでもよい車両搭載バス160は、車両サブシステムのコンポーネントとナビゲーション・コンピュータ144との間の電子通信を可能にする。搭載センサ170は、GPS、速度、ジャイロスコープ、及び他のパラメータに対するセンサを含んでもよい。通信ユニット180は、ワイド・エリア・ネットワーク(WAN)又は他の接続を含んでもよい。
【0022】
当業者によって認識されるように、ナビゲーション・ソリューション120とAPI130は、ナビゲーション・プラットフォーム110との特定の関係性において例証されるが、ナビゲーション・プラットフォーム110と異なる方法で協働してもよい。例えば、ナビゲーション・ソリューション120とAPI130は、記憶装置144に局所的に格納されるアプリケーションとして実装されてもよい。代替的に、ナビゲーション・ソリューション120は、クラウド・コンピューティング及び/又はsoftware−as−a−serviceモデルの下で通信ユニット180を介し無線リンクを介してアクセス可能なリモートサービスとして提供されてもよい。
【0023】
図2は、ナビゲーション・システムのアーキテクチャ構成を例証するブロック図である。システム・アーキテクチャは、ナビゲーション・プラットフォーム層200、API層220、ナビゲーション・ソリューション層240、及びデバイス層260を含む。ナビゲーション・プラットフォーム層200は、図1に関して上記で説明されたHMI150、並びにAPI層220と協働するクライアント・コンポーネント210を含み、HMI150はAPI層220を通じてナビゲーション・ソリューション層240にアクセスすることになる。認識されるように、クライアント・コンポーネント210は、HMI150に統合されてもよく、又は図2で例証されるように別個のコンポーネントとして構成されてもよい。クライアント・コンポーネント210は、以下でより詳細に説明されるようにAPI層220を介してナビゲーション・ソリューション層240とインターフェースする機能を提供する。
【0024】
ナビゲーション・ソリューション層240は、サーバ・コンポーネント244を提供し且つナビゲーション・データベース246及び地図スタイル/構成データベース248と協働する、コア・ナビゲーション・アプリケーション242を含む。ナビゲーション・データベース246は、ナビゲーション・ルート、道路、関心地点に関係する情報、及び他のトラベル関連情報を含む。地図スタイル/構成データベース248は、地図スタイルに関係する情報と、ルート案内グラフィックス(すなわち、道路説明図)と組み合わされた層として典型的に表示されるグラフィカル地図表示に関係する表現/表示基本設定とを含む。ナビゲーション・コア・アプリケーション232はまた、ユーザがコア・ナビゲーション・アプリケーション242の出力をグラフィック形式で視覚化することを可能にするのに必要な出力を提供する、視覚化エンジン241と対話する。サーバ・コンポーネント244は、以下でより詳細に説明されるようにAPI層220と協働する。
【0025】
デバイス層260は、多数のデバイス及び対応するインターフェースを含み、これらはナビゲーション・ソリューション層240と協働する。これらは、グラフィックス処理装置141、測位エンジン242、TMCデバイス244、及びテキストを音声に変換する(text to speech)(TTS)デバイス246を含む。それぞれのインターフェースは、これらのデバイスが、グラフィックスAPI250、測位API252、トラフィック・メディアセンターAPI254、及び音声API256を含むナビゲーション・ソリューション層240と協働できるようにするために提供される。測位エンジン244は、センサ170から車両センサ情報を得る。認識されるように、デバイス層260は、図1で例証されたナビゲーション・プラットフォーム110と共通して、センサ及びHMI要素のような要素を有する可能性があるにもかかわらず、概念的な目的で図2では別個の層として例証される。
【0026】
サーバ・コンポーネント244との関連において1つ又は幾つかのサーバが提供されてもよいことを当業者は理解するであろう。例えば、1つのサーバは、ナビゲーション・コア・アプリケーション242の基本ルート案内能力のための機能を提供してもよく、一方、別のサーバは、ナビゲーション・コア・アプリケーション242の三次元シティ・ビューア又はグローブ・ズーム能力のための機能を提供してもよい。
【0027】
図3は、本発明の態様に係るナビゲーション・システムにおけるクライアント−サーバ・アーキテクチャに関するさらなる詳細を例証するブロック図である。ナビゲーション・アプリケーション・プログラミング・インターフェース130は、クライアント・コンポーネント210とナビゲーション・サーバ・コンポーネント240との間の対話を容易にする。本発明の態様によれば、クライアント・コンポーネント210は、サーバ・コンポーネント240への要求を開始するために多数の要求関数212を提供する。サーバ・コンポーネント240は、クライアント・コンポーネント210への応答を生成するために多数の応答関数242を提供する。プロセス間通信(IPC)チャンネル250は、クライアント・コンポーネント210及びサーバ・コンポーネント240によって行われるプロセスのうち、メッセージを含むデータのプロセス間交換を提供する。当業者には分かるように、IPCチャンネルは、メッセージの受け渡し、同期、共有メモリ、及びリモート手続き呼出し(RPC)のような公知の方法によって実装されてもよい。さらに、IPCチャンネルを実装するのに用いられる方法は、スレッドの間の通信の帯域幅及び待ち時間、並びに通信されるデータのタイプに基づいて変化してもよい。IPCチャンネルは、メッセージ処理のためにIPCライブラリ・コンポーネント252を使用してもよい。サーバ・コンポーネントはまた、グラフィックス出力ライブラリ260、ナビゲーション測位(NP)ライブラリ270、及び音声出力ライブラリ280を含んでもよい、システムレベルのリソースへのインターフェースを含む。
【0028】
以下は、本発明の態様に係るナビゲーションAPIを実装するのに適した例となる関数のリストである。リストは、網羅的となること又は如何なる様態にも自ら制限することを意図されない。加えて、説明される関数に対して用いられる命名法は任意であって、如何なる様態にも限定することを意図されない。各言葉に対する機能もまた含まれるが、その機能が達成される方法は、この出願で説明される実装における如何なる方法にも限定されない。
【0029】
これらの関数が適切なプログラミング言語である、C++のようなオブジェクト指向プログラミング言語で実装されてもよいことが当業者には認識されるであろう。さらに、関数名に「request」という言葉を組み入れている命名法は、ナビゲーション・クライアント・コンポーネント上で実行される関数呼出しを表すことが当業者には分かるであろう。同様に、「response」という言葉を組み入れている関数名は、ナビゲーション・サーバ・コンポーネント上で実行される関数呼出しを表す。上述のインターフェース・コンポーネントを実装するのに適した関数が以下で説明されることになる。関数によって渡される例となる値又はパラメータを表すために括弧が用いられる。
【0030】
認識されるように、ナビゲーション・ソリューションのサーバ・コンポーネントによって提供される例となる応答関数は、ナビゲーション・ソリューションの中の複雑な機能の抽象化層を提供する。したがって、ナビゲーション・プラットフォームは、ナビゲーション・ソリューションの根底にある複雑さに関連した複雑なプロセスを必要とせずに比較的簡単なコマンドとして作られる要求関数によって、ナビゲーション・ソリューションの中の全機能にアクセスしてもよい。
【0031】
本発明の態様によれば、図4で例証されるように、本発明に係る例となるAPIは、全APIの関数のサブセットによって実装される多数の機能的インターフェース・コンポーネントを含む。これらのインターフェース・コンポーネントは、高速プロトタイピング・インターフェース・コンポーネント410、初期化インターフェース・コンポーネント412、情報交換インターフェース・コンポーネント414、車両位置情報インターフェース・コンポーネント516、ナビゲーション・ルート・インターフェース・コンポーネント518、ナビゲーション音声インターフェース・コンポーネント520、及びトラフィック・メディア・チャンネル(TMC)インターフェース・コンポーネント522を含む。それぞれ以下でさらに詳細に説明されることになる。
【0032】
(高速プロトタイピング・インターフェース・コンポーネント)
本発明の態様によれば、高速プロトタイピング・インターフェース・コンポーネントは、ナビゲーション・ソリューションの高速プロトタイピングを可能にするために実装される。高速プロトタイピング・インターフェース・コンポーネントは、ホスト・ナビゲーション・プラットフォームの存在から独立してナビゲーション・ソリューションを機能評価し及び試験できるようにするのに必要最小限の機能のセットを提供する。高速プロトタイピング・インターフェース・コンポーネントは、初期化、スクロール、回転、及びルート案内機能を容易にする。これらの機能は、既存のOEMナビゲーション・プラットフォームに事前に統合する必要なしに、ナビゲーション・ソリューションの開発者が彼らのソリューションを評価することを可能にする。これは、ソリューションを現実の生活環境で評価するためにリソースに対する最小量の努力及び開発時間であらゆるソリューションの統合を可能にする。例となる高速プロトタイピング・インターフェース・コンポーネントを定義する関数は、以下の説明及びこの出願で参照される図面で詳細にされる。
【0033】
requestInit(VID)−関数requestInitは、システムにおいてナビゲーション・クライアント・コンポーネント216がスタートした後でナビゲーション・サーバ・コンポーネント238を初期化するためにナビゲーション・クライアント・コンポーネント216によって呼び出される。関数呼出しは、視覚コンポーネントID(VID)を、デバイス層240の基本となるグラフィカル・サブシステムに対する識別子としてナビゲーション・サーバ・コンポーネントに渡してもよい。ナビゲーション・サーバ・コンポーネントは、responseInitメッセージを発行する前に、ナビゲーション・クライアント・コンポーネントからの対話なしに、自分で上手く初期化し、必要なステップ、例えばシステム・インターフェースとの通信又は内部データ初期化を行う。
【0034】
responseInit(errorCode)−関数呼出しresponseInitは、requestInitが呼び出された後でクライアントに返答を提供し、サーバは、responseInitを用いて応答し、ナビゲーション・サーバ・コンポーネントが適正に初期化されるのを何かが阻んだ場合にゼロに等しくないエラーコードを渡す。errorCodeパラメータは、サーバ側及びクライアント側で予め定義され及び確立されたエラーコードを表す。エラーコードは、ナビゲーション・ソリューションの提供業者に固有のものである。ゼロに等しいエラーコードは、エラーのない初期化を示す。
【0035】
requestSetScreenViewport(xTopLeft,yTopLeft,xBottomRight,yBottomRight)−この関数呼出しは、ナビゲーション・ソリューションの視覚出力をスクリーン上に位置付け、ナビゲーションの視覚コンポーネントの可視矩形の左上の角と右下の角を指定することによって位置を定義するために呼び出されてもよい。スクリーンは、左上の角から(0,0)で測定されてもよい。すべての絶対スクリーン座標は、角(0,0)から開始する。したがって、関数呼出しは、4つの座標、すなわちxTopLeft、yTopLeft、xBottomRight、及びyBottomRightをパラメータとして渡してもよい。
【0036】
requestSetMeasurementSystem(unitSystem)−この関数呼出しは、視覚動作及び非視覚動作に対するナビゲーション・ソリューションの現在の測定系を設定するであろう。これは初期化中並びにランタイム中に呼び出されてもよい。測定系の指定は、ナビゲーション・クライアント・コンポーネント216からナビゲーション・サーバ・コンポーネント238に正しい距離関連情報が渡され及び戻されるのに不可欠である。unitSystemは、不定、英ヤード、英フィート、又はメートルのうちの可能な値を有する列挙データ・タイプとして定義されてもよい。
【0037】
requestSetCoordinateSystem(eCoordinateSystem,CoordinateSystem)−ナビゲーション・ソリューションの現在座標系は、初期化中並びにランタイム中に呼び出されてもよいrequestSet−CoordinateSystem関数によって設定される。座標系の指定は、クライアント側からサーバに正しい位置関連情報が渡される及び戻されるのに不可欠である。eCoordinateSystemパラメータは、利用可能な座標系を表す値を有する列挙データ・タイプとして定義されてもよい。
【0038】
requestSetZoomScale(double,zoomscale)−この関数は、現在の単位測定系を考慮に入れて、視覚出力をズームイン又はズームアウトするのに用いられる。パラメータzoomScaleは、ego位置(車)が位置するところでのディスプレイのセンチメートルあたりの視覚出力のメートルの単位のスケールを表す。これはまた斜視図にも当てはまる。例えば、値500を渡すことは、ディスプレイ上のセンチメートルあたりのワールド座標における500メートルとなる。この関係は、現在のego位置(車)を通じて水平線上では正確である。
【0039】
requestSetRotation(degree,threshold)−この関数は、サーバからの視覚出力の回転を要求する。degreeパラメータは、単位が度である可視出力の回転量を表す。0は北を表し、有効な値は、0°から359°まで及び−1°から−359°までの範囲である。負の角度は、反時計回りの回転となり、正の角度は、時計回りの回転となる。閾値パラメータは、その回転後に中間フレームが描画されるべき回転レベルを示す。−1のパラメータ値は、中間フレームがないが、特定された角度への中間回転が存在することを定義する。閾値が度数値よりも高い場合、閾値は無視されることになり、中間フレームは描画されない。
【0040】
requestSetPosition(xCoordinate,yCoordinate,coordinateType)−この関数は、現在の座標系を考慮に入れて渡されたワールド座標又はディスプレイ座標(coordinateTypeによって示される)での視覚出力を位置付ける。現在のユーザ位置は、「ego」位置として定義され、2つの異なる座標セットと関連付けられてもよく、1つの座標セットはスクリーンのゼロ点から測定した絶対座標であり、1つの座標セットはビューポートのゼロ点から測定した相対座標セットである。
【0041】
requestSetOrientation(eOrientation,orientation)−渡された向きパラメータに従って視覚出力の向きを設定する。パラメータは、northUp(ノースアップの向きを識別する)、headingUp(ヘディングアップの向きを識別する)、又はdestinationUp(目的地が上にある向きを識別する)のうちの可能な値を有する列挙データ・タイプであってもよい。
【0042】
requestScrolling(mode,direction,speed)−この関数は、視覚ナビゲーション出力をスクロールし、スクロールからの出力をストップし、及び現在のego位置にジャンプバックするであろう。関数は、パラメータの異なる組合せで提供されてもよい。モード・パラメータは、start(スクロールのスタートを識別する)、stop(スクロールのストップを識別する)、jumpBackToCarPosition(スクロールのストップ+車位置へのジャンプバックを識別する)、又はdetachFromCarPosition(スクロールが車位置から切り離される)のうちの可能な値を有する列挙データ・タイプであってもよい。パラメータは、このスクロール要求に対して用いられるモードを特定する。startを用いる複数の要求は、パラメータが変化した場合にのみスクロールを変化させ、他の場合には呼出しは無視される。他のモードを用いるその後の呼出しは、現在位置でのスクロールをストップする最初のstop呼出しを除いて無視されることになり、この場合、jumpBackToCarPositionがスクロールをストップし、位置を車位置にジャンプバックさせる。stopが呼び出された後で、startへの呼出しが現在位置でスクロールをスタートし、jumpBackToCarPositionへの呼出しが位置を車位置にジャンプバックさせる。directionパラメータは、単位が度である要求されたスクロール方向を表す(0は北を表し、有効な値は0から359度までの範囲である)。speedパラメータは、スクロール・ステップあたりにスクロールされたピクセルの量を表す。
【0043】
requestSetVisible(visibleState)−この関数は、ナビゲーションの視覚出力の可視性又は不可視性を制御する。visibleStateパラメータは、可視性がオン又はオフのいずれに切換えられるかを示すバイナリインジケータである。
【0044】
requestSetAppearanceStyle(appearanceStyle)−ナビゲーションの視覚出力のスタイルは、例えば昼間モード又は夜間モードでrequestSetAppearanceStyleを呼び出すことによって制御される。スタイルセットの色は、ナビゲーション・プラットフォームの提供業者に典型的に固有のものである。パラメータappearanceStyleは、視覚出力上で表示されるべき値を示し、day(デイカラー)、night(ナイトカラー)、又はautoStyle(自動設定を識別する)の値をもつ列挙されたデータ・タイプであってもよい。列挙は、昼間及び夜間の交通強調表示(traffic highlighting)をサポートするためにビットマスクとして取り扱われてもよい。dayとnightとの両方が設定される場合、day設定のみが表示されることになる。
【0045】
requestTranslateDestinationToCoordinate−場所入力は、EIS(encoded information string(エンコードされた情報文字列))タイプに基づいている。スペラ(speller)から又は格納された目的地から目的地文字列が検索された後で、エンコードされた文字列は、requestTranslateDestinationToCoordinateを呼び出すことによって、立ち寄り場所又は目的地として用いられるべき座標に翻訳される必要がある。
【0046】
responseTranslateDestinationToCoordinate−EISが座標に翻訳されるべきナビゲーション・サーバに渡された後で、サーバは、応答を対応する要求に合致させるために、座標自体、EISを上手く翻訳することができた場合にはステータス、及び渡されたEIS自体を渡す、responseTranslateDestinationTo−Coordinateを呼び出すことによってこの要求に応答する。
【0047】
requestSetDestination(xCoordinate,yCoordinate)−目的地又は立ち寄り場所としての複数の目的地は、requestSetDestinationを用いて設定されてもよい。
【0048】
requestStartRoute( )−この関数は、少なくとも1つの目的地が設定された後で呼び出される。ルート案内に対して要求されるモードは、パラメータとして渡され、ルート案内がすぐにスタートする。パラメータは、組み合わされたルートをサポートするために32ビットのビットマスクとして取り扱われることになる。requestSetDestinationによって目的地が設定されていない場合、この呼出しは無視されることになる。設定された目的地は、ルートをスタートするための第1の要求に対してのみ有効である。すべての新しい要求は、ルートをスタートする前に対応する目的地の設定を有する必要がある。
【0049】
requestStopRoute( )−この関数はルート案内をストップする。ルート案内がアクティブである場合、ルーティングは、requestStopRouteを呼び出すことによってストップされてもよい。ルート案内がアクティブではない場合、呼出しは無視されることになる。
【0050】
requestSetDemoMode(demoState,xCoordinateCar,yCoordinateCar)−この関数は、ナビゲーション・デモ・モードを有効にする又は無効にする。デモ・モードでは、ルート案内は、GPSデバイスなしにスタートされてもよい。ナビゲーション・デバイスは、自身でルートを移動するであろう。xCoordinateCarパラメータ及びyCoordinateCarパラメータは、デモ車位置の座標を表す。デモ・モードがオフに切換えられることをdemoStateパラメータが示す場合、渡されたデモ車位置の値は無視されることになる。
【0051】
informDemoModeEnabled−この関数は、ナビゲーション・クライアントにデモ・モード状態を提供する。サーバは、初期化後に及び変化時に信号を一度送信する。
【0052】
上記の関数は、本発明の態様に係る例となる高速プロトタイピング・インターフェース・コンポーネントを定義する。前述の高速プロトタイピング・インターフェース関数に加えて、図4を再び参照すると、本発明の態様に係る予め定義されたAPI関数は、初期化、ビュー設定(視覚出力構成)、情報発見及び交換、車両位置、ルート案内、ナビゲーション音声、及びTMCに対する関数を含んでもよい。これらは以下で説明されることになる。
【0053】
(初期化インターフェース・コンポーネント)
上記で説明されたrequestInit及びresponseInit関数はまた、初期化関数セットに属することになるが、高速プロトタイピング・インターフェース・コンポーネント関数リストにおいて既にカバーされている。
【0054】
requestShutdown−これは、ナビゲーション・サーバ・コンポーネントのシャットダウンを要求するためのクライアント・コンポーネントからの関数呼出しである。
【0055】
responseShutdown−この関数は、シャットダウン要求に応答してサーバ・コンポーネントをシャットダウンするであろう。
【0056】
(ビュー設定インターフェース・コンポーネント)
requestSetViewType(viewType)−この関数は、地図のビュータイプを設定する。パラメータviewTypeは、view2D(2Dビュー)、view3D(3Dビュー)、viewBird(高さ情報なしの斜視図)、viewGarage(プレビューガレージにおける車両モデルのみを表示する3D斜視図)、及びviewPreview(ルートプレビュー地図を識別する)の可能な値を伴う列挙である。
【0057】
requestSetComponentContext−この関数は、視覚コンポーネントにその後の呼出しに従わせる。その後のすべての呼出しは、単一のナビゲーション・クライアントに対する複数の地図をサポートすることにのみ該当する。この呼出しは排他的であってもよく、それらのコンテキストがこの要求によってアクティブ化されるまでクライアントのすべての他の視覚コンポーネントに呼出しを無視させる。この呼出しは、それらのコンテキストがアクティブ化された後で呼び出されることになる異なる地図をサポートする。異なる出力は、異なるクライアントによってサポートされてもよい。
【0058】
requestSetScreenViewportFrame−この関数は、その後の動作のためのスクリーン・ビューポート・フレームを設定するであろう。スクリーン・ビューポート・フレームは、スクリーン・ビューポートの解像度に影響しない。フレームは、ルート全体像のような全体像又は交通事象にズームするために限定されたスクリーン領域をサポートするように設定される。
【0059】
requestSetVisualAssistance−この関数は、視覚障害のあるユーザに対する視覚支援を有効にする及び無効にする。
【0060】
requestBlock−この関数は、視覚出力のさらなる更新をブロックする。その後のあらゆる要求は、スクリーン上での如何なるレンダリング又は描画をも引き起こさずにサーバ側の状態のみを設定するであろう。状態設定要求は、格納されてもよく、後で以下の関数requestUnblockによってサーバがブロック解除されるとすぐに描画のために適用されてもよい。ブロックは、クライアントの視覚出力の送信にのみ適用され、他のクライアントに対する影響をもたない。
【0061】
requestUnblock−この関数は、上記のrequestBlock関数によってブロックされた視覚出力への更新をブロック解除するであろう。その後のクライアントからの描画に対する要求は、即座の描画につながるであろう。ブロック解除関数は、クライアントの視覚出力の呼出しにのみ適用され、他のクライアントに対する影響をもたない。
【0062】
responseUnblock−この関数は、視覚出力がブロック解除され、結果として完全なフレームが描画された後で、クライアントに応答する。requestBlock関数に関して上記で説明されたように、クライアントからのすべての格納された状態設定要求は、結果として生じるフレームに適用されるであろう。すべての格納された状態設定要求の適用の後で、応答がクライアントに送信されるであろう。
【0063】
requestSetEgoPosition−この関数は、視覚ナビゲーション・コンポーネントのスクリーン・ビューポート内のスクリーン上の相対スクリーン座標におけるego位置を設定するであろう。ego位置は、スクリーン上の現在位置を示すために車のオーバーヘッド像のような適切なアイコンによって示されてもよい。位置は相対スクリーン座標である。
【0064】
requestGetEgoPosition−この関数は、視覚ナビゲーション・コンポーネントのスクリーン・ビューポート内のスクリーン上の相対スクリーン座標における現在のego位置を得るであろう。
【0065】
responseGetEgoPositionOnScreen−この関数は、視覚ナビゲーション・コンポーネントのスクリーン・ビューポート内のスクリーン上の相対スクリーン座標における現在のego位置を戻す。
【0066】
前述の初期化及びビュー設定関数、並びに例となるナビゲーション・システムのクライアント−サーバ・アーキテクチャにおけるそれらの対話が、図5で例証されるシーケンス図に関してさらに説明される。シーケンスは、クライアント・コンポーネントで始まり、サーバにrequestInit関数を出す。requestInit関数は、視覚コンポーネントIDを表すパラメータ、この場合は(16)をサーバに渡す。サーバは、次いで、初期化プロセスを開始し、これはナビゲーション・ソリューションの初期化を含むであろう。サーバの初期化は、クライアントから独立して行われ、したがって、サーバ・コンポーネントは、システム・グラフィック・ライブラリ及びセンサのようなすべてのシステム・コンポーネントとの通信を確立することを必要とするであろう。完了したときに、サーバ・コンポーネントは、初期化が成功したか否かを示すためにエラー・フラグを含むresponseInitコマンドを介して応答する。
【0067】
サーバが初期化要求に応答した後で、クライアントは、前述の関数を用いてサーバに多数の状態設定メッセージを発行する。これらのメッセージは、スタートアップ値、例えば、視覚出力又は要求されるズームレベルに対するビューポートを設定するであろう。スタートアップ値は、必要な時にはいつでも設定されてもよいが、典型的には、ナビゲーション・サーバがさらなるアクションを行うことを要求される前に設定される。ここまでは、サーバは、如何なる視覚出力をもレンダリングする又は示すことを要求されない。サーバからすべての状態設定要求が作成された後で、ナビゲーション・プラットフォーム上のグラフィック出力デバイス上に描画されたフレームをレンダリングするようにサーバに指示するために、クライアントからrequestSetVisibleコマンドが発行される。
【0068】
(情報発見及び交換インターフェース・コンポーネント)
本発明の一態様によれば、ナビゲーション・プラットフォームがナビゲーション・ソリューション上で利用可能な情報のタイプ、したがって能力及び機能を発見すること、及びナビゲーション・ソリューションと情報を交換することを可能にする、情報交換インターフェース・コンポーネントが提供される。情報交換インターフェース・コンポーネントは、以下でさらに詳述されるように要求関数と応答関数のセットとして実装されてもよい。
【0069】
例となるシステムは、ナビゲーション・ソリューションにおいて利用可能であってナビゲーション・プラットフォームによって検索される情報の識別を可能にするために、エンコードされた情報文字列(EIS)を使用してもよい。EISは、フォーム<>のトークン又はタグによって識別される情報を含む。例えば、トークン<IFT>は情報タイプ識別子(information type identifier)を表し、<CTR>は国情報(country information)を識別し、<ITR>は(交差する又は第2のストリートによって)交差点を識別する情報(information identifying an intersection)を表す。以下の関数記述のうちの幾つかでは、さらなる例となるEISが用いられるであろう。
【0070】
情報発見及び交換インターフェース・コンポーネント414が図6を参照してさらに説明され、図6は、ナビゲーション・ソリューションが利用できるようにされた情報タイプ、関連するEISタグ(「<>」で示す)、及び情報値を系統立てるための例となる情報ツリーを例証する。加えて、図7、図8、図9A、及び図9Bは、図6の例となる情報ツリーで説明された情報を用いる、及びナビゲーション・プラットフォーム(クライアント)がナビゲーション・ソリューション(サーバ)から利用可能な情報のタイプを発見するためのシーケンスを例証する、及び例えば選択された国及び州場所データを検索するシーケンス図である。
【0071】
図6で見られるように、ナビゲーション・ソリューションから利用可能な情報は、EISのように<IFT>として表される場合があるルート識別子(Information Type(情報タイプ))を含んでもよい。この例では、ナビゲーション・ソリューションは、ナビゲーション・プラットフォームによって用いられる4つの情報タイプ、すなわち、(1)Location Input(場所入力)、(2)Point of Interest(関心地点)、(3)Map(地図)、及び(4)TMC情報タイプを提示する。これらの情報タイプのそれぞれは、情報ツリーにおけるそれぞれのブランチによって表される付加的なサブタイプを含む。例えば、Location Inputタイプの情報は、サブタイプ、すなわち、Country(国)、State(州)、及びZip Code(ジップコード)を含む。それぞれ、ナビゲーション・クライアントによって作成される要求及びナビゲーション・サーバによって与えられる応答における適切なEISによって表されてもよい。
【0072】
requestGetAvailableInformation(inputEIS)−この関数は、現在の情報に対する次の利用可能な洗練のリストを要求する。パラメータinputEISは、要求された情報を表すエンコードされた情報文字列(EIS)であり、各情報タイプに対して利用可能なアイテムの特定のレベル及びカウントでのすべての利用可能な情報タイプのリストを含むであろう。NULLポインタ(空の文字列)が渡される場合、トップレベル又はルートレベルの利用可能な情報がクライアントに戻される。
【0073】
responseGetAvailableInformation(inputEIS,availableTypesEIS)−このサーバ応答関数は、渡された情報に基づいてナビゲーション・ソリューション上で利用可能な情報が提供される、情報ツリー構造における次の利用可能な情報タイプのリストを提供するであろう。パラメータ入力EISは、クライアント側がサーバからの応答を発行されたオリジナル要求に合致させてもよいように、要求コマンドにおいて渡されたものと同じEISである。戻されたパラメータavailableTypesEISは、それぞれが値として全アイテムカウントを伴う利用可能な情報タイプを表す。NULLポインタは、応答を無効にする。
【0074】
requestGetDetails(inputEIS,requestedFields)−この関数は、inputEIS文字列に関して提供された情報に基づいて詳細な情報を要求する。要求されたフィールドにおける文字列はすべて、タグインジケータ<>によって囲まれるEISトークンとしてフォーマットされるであろう。例えば、<GEO>又は<ALL>である。パラメータrequestedFieldsは、ナビゲーション・サーバが提供するための要求されたフィールドを表す。
【0075】
responseGetDetails(inputEIS,validState,requestedFields,outputEIS)。これは、requestGetDetailsコマンドに応答して提供される情報の詳細を戻すための応答関数である。パラメータvalidStateは、要求が成功したかどうかを示す、状態の妥当性を示す可能な有効値又は無効値を有する列挙である。requestedFieldsパラメータは、要求を応答と合致させるために要求コマンドで要求されたのと同じフィールドを含む。outputEISパラメータは、付加されたフィールドを伴うoutputEISを含む。
【0076】
requestGetList(inputEIS,startIndex,resultCount,sortOptions,fieldOptions,cancelState)−この関数は、入力EISに対する情報のリストを要求する。パラメータstartIndexは、リスト・ウインドウの第1の要素を表し、カウントは1でスタートする。resultCountは、ウィンドウに対するアイテムの要求された量を表す。より少ない量が戻されることになり、利用可能なカウントは、要求された量よりも少ない。−1の値は、すべての利用可能なアイテムを戻すことを示す。パラメータsortOptionは、データをソートする方法を表し、デフォルトのソーティング文字列は「Default(デフォルト)」である。パラメータsortOptionは、defaultSort(デフォルトのソーティングを識別する)、ascending(昇順ソート)、descending(降順ソート)、nearFirst(最も近い最初のソート(nearest first sorting))、farFirst(最も遠い最初のソート(farther first sorting))、hierarchicalSort(より高階層の最初のソーティング)、hierarchicalDescSort(より低階層の最初のソーティング)のうちの可能な値を伴う列挙である。パラメータfieldOptionsは、現在の要求に対して戻すために要求されたフィールドを伴う文字列アレイ構造を表す。デフォルトのフィールド文字列は「Default(デフォルト)」である。パラメータcancelStateは、キャンセル状態を表す。真の値は、前の要求が同じパラメータで作成されていたときに現在処理待ちの要求をキャンセルするのに用いられ、真に設定された完全なフラグを伴う応答として確認が送られ、偽の値は、別個の要求として取り扱われるであろう。クライアントが入力EISにおける<IFT>タグのすぐ後ろに<VIM>、<PATH>、及び<LANG>タグを付加する場合、情報のリストはまた、itemListにおける入力の代わりに共有メモリにおけるファイルとして戻されてもよい。
【0077】
responseGetList(inputEIS,validState,startIndex,resultCount,sortOptions,fieldOptions,itemList,outputEIS,completeState)−この関数は、要求された情報のリストを提供する。この応答の挙動は、偽を伴う完全なフラグをマークすることによって1つの応答で要求されたデータのすべて又は要求された結果のうちの幾つかのみを伴う部分的結果を柔軟にサポートする。したがって、単一のrequestGetList呼出しに対する複数の応答を受信することが可能である。入力EISで特定された<PATH>が予め計算されたリストに対するものであった場合、実際の<PATH>はoutputEISで戻されるであろう。validStateは、要求が成功したかどうかを示す状態を表す。startIndex、resultCount、sortOptions、及びfieldOptionsは、requestGetListコマンドで説明されたのと同様である。ItemListは、要求されたアイテムのリストである。パラメータoutputEISは、オリジナル要求とは異なる場合に付加的な情報を含む。パラメータcompleteStateは、リストが完全であるか否かを示す。
【0078】
requestGetListInformation(inputEIS)−この関数は、現在の情報に対する可能なソート及びフィールド・データ・タイプを要求する。音声認識に用いられるときに、ナビゲーション・クライアントはまた、特定の音声入力型に関する情報を要求するために、EISにおいて<VIM>(音声入力モード)タグ、そのすぐ後に<IFT>(情報タイプ)タグを含んでもよい。
【0079】
responseGetListInformation(inputEIS,validState,sortOptions,fieldOptions,outputEIS)−この関数は、要求された情報に対する可能なソート及びフィールド・データ・タイプを提供する。リストが事前にコンパイル済み(pre−compiled)<PCP>であるのか又はサーバによって動的に生成されることになるのかの情報を提供する。このデータは、ユーザにどのようにして情報を提示するかを決めるためにクライアントによって使用されるであろう。サーバは、クライアントが要求<VIM>において音声入力モードを提供するときに、この情報を提供することだけを要求される。パラメータvalidStateは、要求が成功したかどうかを示す。パラメータsortOptionsは、現在のノードに対する利用可能なソーティング・オプションのベクトルを表すStringArray構造である。パラメータfieldOptionsは、フィールド・オプションのベクトルを表すStringArray構造である。パラメータoutputEISは、<PCP>タグを含む付加されたフィールドを伴うoutputEISを含む(<VIM>と共に要求される場合)。<LANG>タグは、利用可能な各言語に対して提供されるべきである(<VIM>と共に要求される場合)。
【0080】
requestGetSpell(inputEIS)−この関数は、EISレコードにおける最後の選択基準に基づいて現在の情報(inputEISによって表される)を綴るための利用可能な文字のセットを要求する。
【0081】
responseGetSpell(inputEIS,validState,nextAvailableCharacters,count,isFullMatch)−この関数は、inputEISで表される情報に対する次の利用可能な文字及び残りのカウントを提供する。パラメータvalidStateは、要求が成功したか否かを示す。パラメータnextAvailableCharactersは、残りの次の利用可能な文字のセットを表す。パラメータcountは、現在の入力に合致するアイテムのカウントを表す。パラメータisFullMatchは、入力された文字列がアイテムを完全に特定するかどうかを示す。
【0082】
図7で例証されるシーケンス図を参照すると、前述の例となるrequestGetAvailableInformation関数を用いて、ナビゲーション・プラットフォーム(ナビゲーション・クライアント)からの要求を介して、ナビゲーション・ソリューション(図7のナビゲーション・サーバ)から利用可能な情報が最初に発見される。利用可能な情報に対するルート要求を示すためにコマンドにヌル値が与えられる。サーバは、inputEIS値(この場合はヌルであり、メッセージ制御/アカウンティングの目的でクライアントに戻される)を含むresponseGetAvailableInformationメッセージで応答する。結果コードは、ルート要求からの1つの結果を示し、この結果は「InfoType」であり、(4)の値を示す。ナビゲーション・クライアントは、次いで、ルートInfoTypeに関連付けられた4つの情報タイプのリストを要求するためにGetList要求を発行する。これに応答して、サーバは、4つの情報タイプ、すなわちLDB、LI、POI、及びTMCのリストを提供するresponseGetListメッセージを提供する。したがって、ナビゲーション・ソリューションは、ナビゲーション・プラットフォームが用いるのに利用可能な情報タイプを識別する。
【0083】
図8は、ナビゲーション・ソリューションからの場所情報のさらなる検索を示すシーケンス図である。クライアントは、ここでは場所情報(location information)(LI)としてInfoTypeを特定するEISを伴うGetAvailableInformation要求を発行する。availableInfoフィールドにおいてサーバから戻される情報は、「Country(国)」情報タイプ識別子及び2つのさらなる情報タイプを特定するパラメータである。次いで、2つの「country」情報タイプのリストを検索するために、クライアントによってGetList要求が発行される。(2)のアイテムカウントと「CANADA(カナダ)」及び「USA」を示すリストがサーバから戻される。
【0084】
図9A及び図9Bは、州場所情報の検索に対する同様のシーケンス図を例証する。クライアントとサーバとの間の交換は、前述の国情報プロセスと類似した方法で進められた。しかしながら、availableInfoフィールド(53の州)において多数の結果が戻されるので、GetSpell関数は、サーバからの情報の検索を絞り込むために2回用いられる。第1のGetSpell応答は、利用可能な文字のリストと“State=”基準(53)を満たす結果の数を戻す。第2のGetSpell要求は、文字“M”で始まる州のサブセットを検索するように構成され、8つのアイテムと利用可能な文字“AIO”を示す応答を生じる。基準を満たす州のリストを得るためにGetList関数が再び用いられる。
【0085】
明らかであるように、前述の関数及びシーケンスは、ナビゲーション・ソリューションから利用可能なすべての情報を識別してもよい情報発見及び交換インターフェース・コンポーネント414を実装するのに用いられてもよい。ナビゲーション・ソリューションから及び情報交換インターフェースを介して利用可能な情報をエンコードするためのスキームは、4つの例となる情報タイプに限定されないが、ルート及び交差点情報に延長され、ナビゲーション・ソリューションによって事実上すべての情報タイプが利用可能にされる。
【0086】
さらなる例として、以下で説明されるステップ並びに関連する要求関数及び応答関数に記載の交差点情報が使用されてもよい。
【0087】
【表1】

【0088】
【表2】

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

【0090】
【表4】

認識されるように、全ルート・リストに対する各リスト・アイテムは、それが属する<RTE>を含むべきである。
【0091】
ナビゲーション・ソリューションから利用可能な情報を識別するこの態様は、ナビゲーション・ソリューションによって提供されるべき新しい情報タイプの追加と、ナビゲーション・プラットフォームによるこうした発見に適応することも当業者には分かるであろう。すなわち、次世代ナビゲーション・ソリューション上で利用可能にされた新しい機能及び情報は、ナビゲーション・プラットフォームをアップグレードすることなく既存のナビゲーション・プラットフォームによって使用されてもよい。例えば、ナビゲーション・ソリューション上の車線推奨特徴及び利用可能な関連情報の追加は、EISトークンの新しいセット及び図6に描かれた情報ツリー上の対応する付加的なブランチ(図示せず)を伴う「車線推奨」で指定される新しい情報タイプの追加によってナビゲーション・プラットフォームに識別されてもよい。
【0092】
(車両位置情報インターフェース・コンポーネント)
requestVehicleLocationInformationDetails(updateMode,updateInterval)−この関数は、特定された時間間隔に基づいて位置情報の更新を有効にする又は無効にする。updateModeパラメータは、どのようにして向きの更新が送信されるべきかを示し、disable(更新を無効にする)、once(一回更新する)、onChange(向きの変化時に更新する)、及びfrequency(定義された更新頻度)の可能な値を伴う列挙である。updateIntervalパラメータは、位置の更新がクライアントに供給されることになる最大速度を表す。更新は、典型的には変化時にのみ供給されるであろう。値はmsの単位である。
【0093】
informVehicleLocationInformationDetails(posInfo)−この関数は、posInfoによって特定される現在の場所の詳細を提供する。これは、geo位置、機首方向(heading)、及びすべての利用可能な国、州、都市、現在のストリート情報、最も近い交差道路などを含む。これはまた、速度制限、タイムゾーン、車線推奨を含んでもよい。
【0094】
(ナビゲーション・ルート・インターフェース・コンポーネント)
requestBlockRoute(operation,items)−この関数は、ルート(単数又は複数)計算からアイテム(単数又は複数)を追加又は削除し、ルート毎にグローバルに及び/又はローカルに回避するためにルート又はセグメントを表すベクトル又は他のアイテムを特定するのに用いられてもよい。ルート・ハンドルの空のリストが供給される場合、ブロックされたアイテムは、グローバルに適用され、すべての新しいルート計算及び現在アクティブなルートに影響するであろう。一度に1つのルートにつき1つだけの距離ブロックがこの関数によってサポートされる。第2のブロックが特定される場合、これは前の距離ブロックと置き換わるであろう。operationパラメータは、ルート計算中に考慮事項に追加され又は考慮から削除されるべきセグメントを示し、これは考慮事項からセグメントを削除することになる値AddBlock、又はブロックされたリストからセグメントを除去し、したがって再考慮させることになる値RemoveBlockを有する可能性がある列挙である。パラメータitemsは、ルート計算から省略するアイテムを表すEISのリストであり、道路セグメント、ルート操作(route maneuvers)、又はルートの先の距離(distance ahead on the route)を含むことができる。
【0095】
responseBlockRoute(operation,items,validState)−これは、requestBlockRouteへのサーバ応答である。operationパラメータ及びitemsパラメータは、前述のパラメータと同様である。パラメータvalidstateは、要求が成功したか否かを示す。
【0096】
requestNewTrip(destinations,routeModes)−この関数は、新しいトリップを作成する。新しいルート・ハンドル、すなわち、特定されたルート・オプションの各セットに対して作製される特定のルート・モードによって定義される、計算されたルートを識別する独自の識別子が存在するであろう。パラメータdestinationsは、ルート計算において用いられるべきルート要素を表す要素のリストである。パラメータrouteModesは、ルート・モードを表す要素のリストである。渡された各ルート・モードに対してルート要素が作製されるであろう。
【0097】
responseNewTrip(destinations,routeModes,validState,handles)−この関数は、特定されたルート・オプションの各セットに対するルート・ハンドル識別子を戻す。パラメータhandlesは、ルート・ハンドルのリストである。リストの中のルート・ハンドルの順序は、特定されたルート・オプションの順序と合致する。ゼロのルート・ハンドル値は、ゼロ位置でのルート・オプションを伴うルートを識別する。
【0098】
requestKillTrip(handles)−ルート・ハンドルのリストを破壊する。ターン・リスト及びルート詳細は、ルートに関連付けられた情報ツリーにおいてもはや利用可能ではないであろう。アクティブなルート・ハンドルの破壊は案内を取り消すであろう。この場合、以下で説明される関数informActiveRouteDescriptionは、適宜更新されるであろう。
【0099】
responseKillTrip(handles)−この関数は、破壊されているルート・ハンドルに対するサーバ応答である。
【0100】
requestStartGuidance(routeHandle)−この関数は、routeHandleによって表される特定されたルート・ハンドルに関連付けられたルートをスタートする。関数informActiveRouteDescriptionは自動的に更新されるであろう。
【0101】
requestStopGuidance( )−すべてのルーティングをストップする。ActiveRouteDescriptionは、自動的に更新されるであろう。案内がストップされるとき、ActiveRouteDescriptionにおけるルート・ハンドルは−1となるであろう。
【0102】
informActiveRouteDescription(routeDesc)−目的地としても知られているアクティブなルート要素及び操作(maneuver)としても知られているアクティブなルート・セグメントを識別する。−1のルート・ハンドルは、アクティブなルートがないことを示す。パラメータrouteDescは、現在のアクティブなルート記述情報を表す。
【0103】
informNextManeuverInfo(timeDist,nextManInfo)−次の操作までの残り時間及び距離を提供する。この関数は、ActiveRouteDescriptionが有効なルート・ハンドルを含むときにのみ有効である。
【0104】
informNextDestinationInfoFunction(nextDestInfo)−次の目的地までの残り時間及び距離を提供する。ActiveRouteDescriptionが有効なルート・ハンドルを含むときにのみ有効である。パラメータnextDestInfoは、次の目的地に関する情報を表す。
【0105】
informCalculationState(routeHandle,calcState,calcPercent)−この関数は、変化したルート計算状態についての情報を戻す。この応答は、ルートが選定された、計算された、再計算された、又は目的地に到着したときにクライアントに知らせるために送られる。これは、ルート・セグメント・リスト(ターン・リスト)を得ることをトリガする。パラメータrouteHandleは、変化したルート・ハンドルを表し、calcStateは、新しい計算状態(アイドル、選定中、選定済み、計算中、計算済み、ルーティング中、ルーティング済み、又は失敗)を表し、calcPercentは、計算されたルートの全パーセンテージを表す(0〜100又は利用可能ではない場合は−1)。
【0106】
上記の関数は、ナビゲーション・プラットフォームがナビゲーション・ソリューションによって提供されるルーティング関数に影響を及ぼすのに好都合な方法を提供する可能性がある。例えば、特定された先の距離の特定のルートをブロックするコマンドをナビゲーション・ソリューションに発行するために、requestBlockRoute及びresponseBlockRoute関数が用いられてもよい。例えば、5000メートル先のルートをブロックするために、クライアントは以下のコマンドを送信するであろう:
【0107】
【表5】

認識されるように、様々なルート・ブロック機能を達成するために、先のブロックを除去すること、全ルート・セグメントをブロックすること、ルート・セグメントの操作のみをブロックすることなどのナビゲーション・ルート・インターフェース・コンポーネント関数が用いられてもよい。さらに、例えば、特定のルート・ハンドルに対するルート・ブロックのリストを検索するために、図6に示された構造と類似した情報ツリー構造に格納されるルート情報と共に情報交換インターフェース・コンポーネントのGetAvailableInformation関数が用いられてもよい:
【0108】
【表6】

ブロックされたセグメント(Blocked Segment)<BLK>は、ブロックされたセグメント操作(Blocked Segment Maneuvers)及びブロックされた道路距離(Blocked Road Distance)を含むルートに対するすべてのタイプのブロックされたアイテムを含むであろう。
【0109】
【表7】

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

上記の戻されたEISは以下のことを示す:要求されたルート・オプション(Requested route options),<RTO>fastest|avoidMotorways<*>;実現されなかったルート・オプション(Unfulfilled Route Options),<URO>avoidMotorways<*>;ルートに対する回避型(Avoidance types on route),<RAT>avoidMotorways|avoidUnpaved<*>;ルート計算状態(Route Calculation state),<RCS>Calculated<*>;真の道路距離(デシメートル)(Real Road Distance(decimeters)),<RRD>245320<*>;残り移動時間(Remaining Travel Time)(ms),<TRT>3756324<*>
(ナビゲーション音声インターフェース・コンポーネント)
ナビゲーション音声インターフェース・コンポーネントは、ナビゲーション・サーバ・コンポーネントによって提供される音声サービスをナビゲーション・クライアント・コンポーネントが使用できるようにするための関数を含む。
【0111】
informPromptReady(audioSource)−この関数は、ナビゲーション・サーバ上で提供され、プロンプトの準備ができていることをクライアントに示す。パラメータaudioSourceは、audioIdle:デフォルトのナビゲーション音声ソース(ナビゲーション音声が現在再生されていないことを示す)、audioAutomatic:ナビゲーション・コアにより開始される音声ソース、例えば、操作場所への車両の接近によってトリガされるターン推奨、audioManual:例えば、ユーザがナビゲーション・プロンプトの繰返しを要求する場合にユーザにより開始される音声ソース、のうちの可能な値を有する列挙であってもよい。
【0112】
requestPromptReady(audioSource)−このクライアント関数は、プロンプトが特定された音声ソース上で再生されてもよいことをナビゲーション・サーバに示す。
【0113】
requestSetADA(adaState)−この関数は、音響運転アナウンス(acoustic driving announcement)(ADA)を有効にする又は無効にする。パラメータadaStateは、バイナリ状態表示である。同じバイナリ状態でのその後の呼出しは無視されることになる。
【0114】
informADAIsEnabled(isEnabled)−この関数は、ADAが有効にされる又は無効にされることを示す。IsEnabledがTRUEである場合、ナビゲーション音声アナウンスが再生されるであろう。IsEnabledがFALSEである場合、ナビゲーション音声アナウンスは再生されないであろう。
【0115】
requestCancelADA( )−これは、現在の音響運転アナウンス(ADA)を取り消す関数である。この関数呼出しは、現在出力されたADAにのみ影響し、その後のADAに対する影響はもたない。
【0116】
requestRepeatADA( )−これは、最後のADAを繰返す関数である。最後のADAは、繰返されることになる。これまでADAが出力されていなかった場合、呼出しは無視されることになる。
【0117】
informActiveAudioSource(audioSource)−この関数は、現在再生中の音声ソースを戻すであろう。audioSourceによって表される状態は、アイドル、自動、又は手動であってもよい。パラメータaudioSourceは、現在再生中の音声ソースを表す。
【0118】
上記の関数を用いる例となるシーケンスを、ここで図10を参照して説明する。ナビゲーション・クライアントは、対応する音声が再生される前にrequestPromptReady関数を開始してもよい。したがって、シーケンスにおける第1のステップは、ナビゲーション・サーバが音声プロンプトを再生する準備ができたことを信号送信するためにinformPromptReadyメッセージを発行する。これの次に、ナビゲーション・ソリューションが音声送達を始めるための許可を示す、requestPromptReadyコマンドの形態の、HMI(及びナビゲーション・クライアント・コンポーネント)からの通知がなされる。次いで、ナビゲーション・サーバは、informActiveAudioソースに応答してアクティブな音声ソースをアイドルから手動に変化させる。クライアントがinformPromptReadyメッセージを受信するときに、これは音声属性を現在の音声ソースに設定し、音声の再生を始めるであろう。これが終わったときに、これはAudioPrompt属性をアイドルに設定するであろう。HMIは、音声ソースを変化させるためにこのトリガを用いてもよい。
【0119】
(トラフィック・メッセージ・チャンネル・インターフェース・コンポーネント)
トラフィック・メッセージ・チャンネル・インターフェース・コンポーネントは、ナビゲーション・プラットフォームがナビゲーション・ソリューションによって提供されるTMCに関連する機能を使用できるようにするための関数のグループを含む。
【0120】
requestSetTMCMode(tmcMode)−この関数は、サーバがTMC情報を処理するのを有効にする及び無効にする。TMCが無効にされるときに、メッセージは表示された地図から削除されてもよく、TMCメッセージリストが消去される。
【0121】
informTMCMode(tmcState)−新しいTMC情報が受信されていることをクライアントに知らせる。この情報は、監視されたTMC情報を要求することのトリガである。サーバは、初期化後に及び変化時に信号を一度送信するであろう。パラメータtmcStateは、TMC処理がオン又はオフに切換えられることを示すためのバイナリインジケータである。
【0122】
requestSetTMCRouteMode(tmcRouteMode,minutes)−この関数は、TMCイベントによりサーバが新しいルートを提供するときに代替ルートの受け入れモードを設定する。パラメータtmcRouteModeは、tmcOff(ルート計算中にTMCメッセージを考慮しないことを表す)、tmcAutomatic(ルート計算中にTMCメッセージを考慮し、サーバが計算されたルートを自動的に受け入れることを表す)、tmcManual(ルート計算中にTMCメッセージを考慮するが、サーバは計算されたルートを自動的に受け入れないことを表す)、又はtmcDelay(現在のルートが特定された遅延時間を超過する場合にのみサーバが現在のルートを変化させることを表す)、の値を有する列挙であってもよい。パラメータminutesは、最小の残り時間差を表す。サーバは、新しいルートが現在のルートよりも所与の時間差だけ速い場合にのみ新しいルートを提供するであろう。差が所与の時間よりも小さい場合、計算されたルートは却下されるであろう。
【0123】
informTMCRouteMode(tmcRouteMode,minutes)−この関数は、現在のTMCルート・モードをクライアントに知らせる。サーバは、初期化後に及び変化時に信号を一度送信するであろう。
【0124】
informTMCInfoChanged(tmcInfo)−この関数は、新しいTMC情報が受信されていることをクライアントに知らせる。この情報は、監視されたTMC情報を要求することのトリガである。
【0125】
informTMCOnRouteChanged−特定されたルート・ハンドル上で新しいTMC情報が受信されていることをクライアントに知らせる。この情報は、監視されたTMC情報を要求することのトリガである。
【0126】
informTMCRoutesAvailable(routeList,tmcNewEvents,tmcDeletedEvents)−この関数は、受け入れモードがtmcManualであるときに受信したTMC情報に基づいて利用可能な代替ルートをクライアントに知らせる。パラメータrouteListは、更新されたTMC情報を伴うルート・ハンドルのリストを表す。パラメータtmcNewEventsは、代替ルートの計算をもたらす最も有意な新しいtmcイベントのリストを表す。パラメータtmcDeletedEventsは、代替ルートの計算をもたらす最も有意な削除されたtmcイベントのリストを表す。この情報は、監視されたTMC情報を要求することのトリガである。
【0127】
requestTMCIgnore−これは、無視する又は無視をストップするべきイベント又はTMCイベントのグループを特定する関数である。無視されるTMCメッセージ及びグループは、ルート計算の考慮事項から除去されるであろう。無視されたTMCメッセージは、<IFT>TMC<*><RQT>IgnoredMessages<*>で情報インターフェースにおいて利用可能となるであろう。無視されたTMCメッセージ・グループは、<IFT>TMC<*><RQT>IgnoredMessageGroups<informで情報インターフェースにおいて利用可能となるであろう。TMCIgnoresChangedは、TMCIgnore関数が完了した後でサーバによって呼び出されるであろう。これは、無視が更新されていることをクライアントに知らせるであろう。
【0128】
informTMCIgnoresChanged−無視されたTMC情報が変化していることをクライアントに知らせる関数である。この情報は、監視されたTMC情報を要求することのトリガである。
【0129】
requestTMCAvoid−回避する又は回避をストップするべきイベント又はTMCイベントのグループを特定する。回避されたTMCメッセージ及びグループは、ルート計算の目的でそれらに課される付加的なペナルティを有するであろう。回避されたTMCメッセージは、<IFT>TMC<*><RQT>AvoidedMessages<*>で情報インターフェースにおいて利用可能となるであろう。回避されたTMCメッセージ・グループは、<IFT>TMC<*><RQT>AvoidedMessageGroups<*>で情報インターフェースにおいて利用可能となるであろう。関数informTMCAvoidsChangedは、tmc回避関数が完了した後でサーバによって呼び出されるであろう。これは、回避が更新されていることをクライアントに知らせるであろう。
【0130】
informTMCAvoidsChanged−これは、回避されたTMC情報が変化していることをクライアントに知らせる。この情報は、監視されたTMC情報を要求することのトリガである。
【0131】
上述の実装が本発明を例証することを当業者は認識するであろう。APIは、ナビゲーション・ソリューションの根底にある複雑さに対する抽象化層を提供する。例えば、代替ルートを伴う複雑なルート全体像を描画するためにナビゲーション・プラットフォームが多数の複雑なプログラミングレベルコマンドをナビゲーション・ソリューションに発行することを要求する代わりに、ナビゲーション・プラットフォームは、ナビゲーション・ソリューションが例となるAPIを定義する予め定義された関数の標準セットに従って構成されるため、より高レベルのステップに関係する上記で開示された高レベルの例となる関数のような比較的より少ないコマンドを発行してもよい。さらに、APIは、ナビゲーション・プラットフォームへのナビゲーション・ソリューションの柔軟且つ効率的な統合、ホスト・ナビゲーション・プラットフォームの開発から独立しているナビゲーション・ソリューションの高速プロトタイピング、並びにあらゆるナビゲーション・ソリューションから利用可能な情報タイプ及び機能の発見を可能にする。
【0132】
上記の実装の説明は、例証する及び説明する目的で提示されている。これは網羅的なものではなく、特許請求される本発明を開示された正確な形態に限定しない。上記の説明に照らして修正及び変形が可能であり、又はこれらは本発明の実施から得られてもよい。請求項及びそれらの均等物が本発明の範囲を定義する。

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

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9A】
image rotate

【図9B】
image rotate

【図10】
image rotate


【公開番号】特開2013−19902(P2013−19902A)
【公開日】平成25年1月31日(2013.1.31)
【国際特許分類】
【出願番号】特願2012−156601(P2012−156601)
【出願日】平成24年7月12日(2012.7.12)
【出願人】(592051453)ハーマン インターナショナル インダストリーズ インコーポレイテッド (91)
【Fターム(参考)】