(57)【要約】少なくとも２つの位置決定デバイスを備えるモバイル装置内で位置情報を生成するための方法が提供される。この方法は、各位置決定デバイスに対して少なくとも一つのパラメータ値を割当て、格納するステップと、コンテクスト情報を決定するステップと、これらコンテクスト情報に依存して、各位置決定デバイスに対して割当てられた少なくとも一つのパラメータの値に基づいて対応する位置決定デバイス選択プロセスを選択するステップと、こうして選択された選択プロセスに従って位置決定デバイスを選択するステップと、こうして選択された位置決定デバイスを起動するステップと、を含む。位置ベースのサービスに適用することで、利用可能な位置決定資源をより効果的に扱うことが可能となる。
2005530427.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも２つの位置決定デバイスを備えるモバイル装置内で位置情報を生成するための方法であって、
各位置決定デバイスに対して少なくとも一つのパラメータ値が割当てられ、格納されるステップと、
コンテクスト情報を決定するステップと、
前記コンテクスト情報に依存して、各位置決定デバイスに対して割当てられた前記少なくとも一つのパラメータの値に基づいて、対応する位置決定デバイス選択プロセスを選択するステップと、
こうして選択された選択プロセスに従って位置決定デバイスを選択するステップと、
こうして選択された位置決定デバイスを起動するステップと、を含むことを特徴とする方法。
【請求項２】
各位置決定デバイスに対して少なくとも２つのパラメータ値が割当てられ、格納される、ことを特徴とする請求項1記載の方法。
【請求項３】
前記格納されるパラメータ値は、精度値、応答時間値及び消費電力値の内の少なくとも一つを含む、ことを特徴とする請求項２記載の方法。
【請求項４】
前記位置決定デバイスを選択するサブステップは：
前記選択された選択プロセスに依存して、前記位置決定デバイスをランク付けするサブステップと、
最も高くランク付けされており、かつ、利用可能な、位置決定デバイスを選択するサブステップと、から成ることを特徴とする請求項1から３のいずれかに記載の方法。
【請求項５】
更に、アプリケーション（ソフトウェア）によって要請される位置データのフォーマットを識別するステップと、
現在起動されている位置決定デバイスがそのフォーマットに従ってデータを供給するか否かを決定するステップと、
否定の場合は、前記現在起動されている位置決定デバイスによって供給される位置データを要請される位置データのフォーマットに変換するステップと、を含むことを特徴とする請求項1から４のいずれかに記載の方法。
【請求項６】
前記位置データは、物理的位置データと論理的位置データとから成る、ことを特徴とする請求項1から５のいずれかに記載の方法。
【請求項７】
前記物理的位置データは、デカルト位置座標、経度/緯度座標、或いは場合によっては経度座標から成る、ことを特徴とする請求項1から６のいずれかに記載の方法。
【請求項８】
前記論理的位置データは、無線周波数ビーコン識別子から成る、ことを特徴とする請求項６記載の方法。
【請求項９】
前記変換ステップは、テーブルから、少なくとも一つのビーコン識別子に対応する物理的座標を読み出すことから成る、ことを特徴とする請求項５と８が結合された方法。
【請求項１０】
データ処理能力を有するモバイル装置であって、
各々がモバイル装置の位置情報を特定のフォーマットにて供給する能力を有する少なくとも２つの位置決定デバイスと、
前記少なくとも２つの位置決定デバイスに対する、各々がその位置決定デバイスと関連する少なくとも一つのパラメータを格納及び検索する能力を有する、少なくとも２つのドライバと、
位置情報を供給するために、前記ドライバと通信するとともに、アプリケーションソフトウェアとも通信する能力を有する位置ハンドリングユニットとを備え、この位置ハンドリングユニットは、位置情報を得るために用いられるべき位置決定デバイスをコンテクスト情報と、前記ドライバ内に格納されているパラメータの値とに基づいて、選択する能力を有する、ことを特徴とするモバイル装置。
【請求項１１】
前記位置決定デバイスは、セルベースの位置決定デバイス、衛星ベースの位置決定デバイス及びビーコンベースの位置決定デバイスから成る一群から選択される、ことを特徴とする請求項1０記載のモバイル装置。
【請求項１２】
各ドライバは、少なくとも２つの異なるパラメータを格納及び検索する能力を有する、ことを特徴とする請求項1０或いは１１記載のモバイル装置。
【請求項１３】
前記パラメータは、位置精度パラメータ、応答時間パラメータ及び消費電力パラメータの内の少なくとも２つを含む、ことを特徴とする請求項1２記載のモバイル装置。
【請求項１４】
前記位置ハンドリングユニットは、前記アプリケーションソフトウェアからコンテクストメッセージを受信するように適合化され、パラメータの優先度は前記コンテクストメッセージの関数として設定される、ことを特徴とする請求項1２或いは１３のいずれかに記載のモバイル装置。
【請求項１５】
前記位置ハンドリングユニットは、一組の位置決定デバイスを、より高い優先度のパラメータに従って好み順に格納する能力を有するランク付け手段を備える、ことを特徴とする請求項1４記載のモバイル装置。
【請求項１６】
前記位置ハンドリングユニットは、前記一組内のある好ましい位置決定デバイスが利用可能であるか否かをチェックし、否定の場合は、次に好ましい位置決定デバイスをチェックするための利用可能性チェック手段を備える、ことを特徴とする請求項1５記載のモバイル装置。
【請求項１７】
前記位置ハンドリングユニットは、前記アプリケーションソフトウェアに、位置データをその位置データと関連する精度情報とともに供給する能力を有する、ことを特徴とする請求項1０から１４のいずれかに記載のモバイル装置。
【請求項１８】
更に、前記位置ハンドリングユニットと通信する能力を有する位置データ変換ユニットを備える、ことを特徴とする請求項1０から１７のいずれかに記載のモバイル装置。
【請求項１９】
前記位置ハンドリングユニットは、前記位置データ変換ユニットによる変換を要求するアプリケーションにより供給されたデータフォーマット要件情報に応答する、ことを特徴とする請求項1８記載のモバイル装置。
【請求項２０】
更に、複数の位置データを時間/日情報とともに格納する能力を有する位置履歴ユニットを備える、ことを特徴とする請求項1から１９のいずれかに記載のモバイル装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的には、モバイル電話、パーソナルデジタルアシスタント、ラップトップコンピュータ等のモバイル装置内で位置決定デバイス及び関連する位置データを処理するための方法及びシステムに係る。
【背景技術】
【０００２】
現代の通信サービスは、ますます、人、場所、或いは物理上若しくは計算上の物体であり得る実体（entity）の場所（location）或いは位置（position）の特徴を記述するために用いることができる任意の情報から成るコンテクスト情報（context information）を用いて、いわゆるコンテクストを意識した計算（context-aware computing）を遂行する傾向にある。つまり、コンテクスト情報を用いて、モバイル装置のユーザに、ユーザの居場所に関係なく、仕事（タスク）と関連する情報及び／或いはサービスを提供する傾向にある。
【０００３】
例えば、多くの技術が、ネットワークレベルにてある所定の位置決定技術（positioning technology）を通じて決定された若しくは得られたユーザの現在の居場所に基づいてユーザモバイルステーション或いは装置にサービスを提供するために用いられるネットワークサービス提供装置が知られている。
【０００４】
これら公知のアプローチの一つの大きな短所は、ネットワークソフトウェア及び／或いはモバイル装置内のソフトウェアは位置情報を考慮に入れるためにある特定の設計を必要とし、しかも、この設計は決定されるべき或いは得られるべき位置データのタイプに依存することにある。
【０００５】
もう一つの大きな短所は、所定のタイプの位置データは、全てのコンテクスト及びリクエストされたサービスに対して必ずしも適するわけではないということにある。
【０００６】
例えば、いわゆるセルID（cell-ID）を通じて得られる位置データ、つまり、あるモバイル電話機の圏内のあるセルラ電話網のセルの識別子は、例えば、ショッピングモール或いは他の場所における室内ナビゲーションサービス（indoor navigation service）に対しては、十分に精度が高いとはいえない。
【０００７】
もう一つの例として、高い消費電力と良好な精度を有するGPSデバイスは、低い消費電力を要求されるコンテクスト内では適当でない。
【発明の開示】
【０００８】
本発明の一つの目的は、モバイル装置内で位置情報を処理するための、あるモバイル装置用に設計された任意のアプリケーションソフトウェアに対して明白な、つまり、あるモバイル装置内に実装された任意の位置決定技術（position determination technology, ”PDT”）に対し一つの共通のインタフェースを提供し、ユーザアプリケーションソフトウェアが、自身で、そのモバイル装置内で利用可能な任意の位置決定技術（PDT）内の最もものを選択し、それらの能力（capabilities）を最大限に発揮させることを可能にする方法及びシステムを提供することにある。
【０００９】
本発明のもう一つの目的は、位置に基づくアプリケーションの開発者が、単一のインタフェースを通じての対話だけを考え、複雑な位置決定問題及び技術に関しては考慮しなくてもよいようにすることにある。
【００１０】
本発明のさらにもう一つの目的は、汎用の無線アプリケーションによって用いることができるとともに、様々な環境、例えば、自動車環境、或いはローカルネットワークに支えられた位置決定技術を用いる高精度の室内ナビゲーションアプリケーション等に対しても簡単に個別に対応することができる適合化及びカスタム化可能なデバイス及び方法を提供することにある。
【００１１】
より具体的には、本発明によるデバイス及び方法は、位置技術（location technology）を、例えば、（Java 2 Micro Editionに対する）いわゆるJ2ME環境等の標準の開発環境内において開発されたアプリケーション内に統合化するために要求される労力及び資金の削減を図る。
【００１２】
より具体的には、本発明は、第一の態様によると、少なくとも２つの位置決定デバイス（position determination devices）を備えるモバイル装置(mobile equipment)内で位置情報（position information）を生成するための方法を提供する。この方法は、
各位置決定デバイスに対して少なくとも一つのパラメータ値を割当て格納するステップと、
コンテクスト情報（context information）を決定するステップと、
このコンテクスト情報に依存して、各位置決定デバイスに対して割当てられた少なくとも一つのパラメータの値に基づいて、対応する位置決定デバイス選択プロセス（position determination devices selection process）を選択するステップと、
こうして選択された選択プロセスに従って位置決定デバイスを選択するステップと、
こうして選択された位置決定デバイスを起動するステップと、を含む。
【００１３】
これに限定されるものではないが、上述の方法の一つの実施例によると、各位置決定デバイスには少なくとも２つのパラメータ値が割当てられ、格納される。
【００１４】
もう一つの実施例によると、こうして格納されるパラメータ値は、精度値、応答時間値及び消費電力値の内の少なくとも一つを含む。
【００１５】
もう一つの実施例によると、位置決定デバイスを選択するサブステップは：
選択された選択プロセスに依存して位置決定デバイスをランク付けするサブステップと、
最良とランク付けされ、かつ、利用可能な位置決定デバイスを選択するサブステップとから成る。
【００１６】
もう一つの実施例によると、上述の方法は、更に、
あるアプリケーションソフトウェアによってリクエストされた位置データのフォーマットを識別するステップと、
現在起動されている位置決定デバイスがそのフォーマットに従ってデータを供給するか否かを決定するステップと、
否定の場合は、現在起動されている位置決定デバイスによって供給される位置データをリクエストされた位置データのフォーマットに変換するステップと、を含む。
【００１７】
位置データは物理的位置データと論理的位置データから成る。
【００１８】
物理的位置データは、デカルト座標及び緯度/経度座標及び場合によっては経度座標から成る。
【００１９】
論理的位置データは、無線周波数ビーコン識別子から成る。
【００２０】
変換ステップは、テーブルから少なくとも一つのビーコン識別子に対応する物理的座標を読み出すことから成る。
【００２１】
本発明のもう一つの態様によると、本発明は、データ処理能力（data processing capabilities）を有するモバイル装置（mobile equipment）を提供する。この装置は：
各々がモバイル装置の位置情報をある特定のフォーマットにて供給する能力を有する少なくとも２つの位置決定デバイスと、
これら少なくとも位置決定デバイスに対する、各々がその位置決定デバイスと関連する少なくとも一つのパラメータを格納及び検索する能力を有する、少なくとも２つのドライバと、
これらドライバと通信するとともに、位置情報を供給するためにアプリケーションソフトウェアと通信する能力を有する位置ハンドリングユニット（location handling unit）とを備え、この位置ハンドリングユニットは、位置情報を得るために使用すべき位置決定デバイスを、コンテクスト情報及びドライバ内に格納されているパラメータの値に基づいて、選択する能力を有する。
【００２２】
これに限定されるものではないが、上述のモバイル装置の一つの実施例によると、位置決定デバイスは、セルベースの位置決定デバイス、衛星ベースの位置決定デバイス及びビーコンベースの位置決定デバイスから成る一群から選択される。
【００２３】
各ドライバは、少なくとも２つの異なるパラメータを格納及び検索する能力を有する。
【００２４】
前記パラメータは、位置精度パラメータ、応答時間パラメータ及び消費電力パラメータの内の少なくとも２つを含む。
【００２５】
前記位置ハンドリングユニットは、前記アプリケーションソフトウェアからコンテクストメッセージ（context message）を受信するように適合化され、パラメータの優先度はこのコンテクストメッセージの関数として設定される。
【００２６】
前記位置ハンドリングユニットは、一組の位置決定デバイスを、より高い優先度のパラメータに従って好みの順（preference order）に格納する能力を有する、ランク付け手段（ranking means）を備える。
【００２７】
前記位置ハンドリングユニットは、前記一組内のある好ましい位置決定デバイスが利用可能であるか否かをチェックし、否定の場合は、次に好ましい位置決定デバイスをチェックするための利用可能性チェック手段（availability checking means）を備える。
【００２８】
前記位置ハンドリングユニットは、前記アプリケーション位置データに、そのデータに関連する精度情報を供給する能力を有する。
【００２９】
前記モバイル装置は、更に、前記位置ハンドリングユニットと通信する能力を有する位置データ変換ユニットを備える。
【００３０】
前記位置ハンドリングユニットは、前記位置データ変換ユニットによる変換を要求するアプリケーションにより供給されたデータフォーマット要件情報（data format requirement information）に応答する。
【００３１】
前記モバイル装置は、更に、複数の位置データを時間/日情報とともに格納する能力を有する位置履歴ユニット（position history unit）を備える。
【００３２】
本発明の他の目的、特徴及び長所が、添付の図面を参照しながら行なわれる本発明の好ましい実施例の以下の詳細な説明から一層明白となるものである。
【発明を実施するための最良の形態】
【００３３】
最初に、この明細書において引用される全ての商標（trademarks）はそれらの各所有者に帰属するものである。
【００３４】
１）位置処理システム
a）目的
この位置処理システムの基本的な目的は、（ネットワーク側及び／或いはモバイル側の）アプリケーションソフトウェアに対する単純な局所的インタフェース（localization interface）を提供することで、アプリケーションソフトウェアの開発において、開発者が、デバイスに実装される位置決定技術を意識しなくても済むようにすることと、（現在或いは将来の）最新の位置決定技術及び／或いは特定のハードウェアを、簡単に、かつ、最もうまくサポートできるようにすることの両方にある。
【００３５】
一方においては、単純なインタフェースが提供されるために、開発者は、位置決定問題及び技術に関する知識を有することを要求されず、全ての位置決定装置と同一の方式にて対話（インタフェース）することが可能となる。このため、システムとの協調を要求されるアプリケーションソフトウェアの開発者は、いちいち、新たな或いは異なる技術がどのように動作するかを学習する必要がなくなるとともに、信号の伝播、変調、等に関する特定の知識を有することも要求されなくなる。換言すれば、位置情報を用いるアプリケーションソフトウェアは、現存の或いは将来の位置決定技術に従って、特別に設計する必要はなくなる。
【００３６】
この位置処理システムのもう一つの目的は、ある与えられた装置の機能が完全に発揮させること、及び、全ての位置決定技術に対して共通のインタフェースを提供することで、Location Handler（位置ハンドラ）によってサポートされる製品に付加価値を加えること、及び／或いはLocation Handler仕様に順応されることにある。
【００３７】
ｂ）機能面の説明
この位置ハンドリングシステムの第一の特徴は、異なるタイプの複数の位置決定技術、つまり、動的に追加或いは取外すことができる複数の（少なくとも２つの）タイプの位置デバイス（location devices）をサポートできることにある。これとの関連で、このシステムは、１つの位置決定デバイス当り、１つのドライバ或いは”カートリッジ（cartridge）”を含み、主要素（main component）は、これと個別に通信する能力を有する。
【００３８】
この位置ハンドリングシステムの一つの関連する特徴は、実際に実装されている位置決定技術を抽象化すること、つまり、異なる、異質な位置決定技術を、単純かつ効果的に取り扱うことにある。これを達成するために、このシステムは、新たな位置決定技術及び／或いは新たなハードウェア、及び／或いは現存の技術に関する論理を簡単に、かつ、最適にサポートすることができるように、位置情報を用いるアプリケーションソフトウェアに対する、一つの共通の単純ではあるが、ただし、フレキシブルなインタフェースを提供する。
【００３９】
本発明によるシステムのもう一つの特徴は、後に説明するように、様々な状況下において、ある位置決定技術から別の技術にスイッチングできる能力にある。例えば、スイッチングは、現在用いられている位置決定技術が利用不能となった場合や、或いは現在用いられている位置決定技術が、もはや現在の状況に、その装置内で利用可能な別の位置決定技術と比べてより適当ではなくなった場合に行なわれる。
【００４０】
このような動的なスイッチングを実現するためには、位置ハンドリングシステムは、様々な異なる利用可能な位置決定技術と関連するカートリッジと協調するが、メモリ内には各カートリッジと関連させてパラメータが格納される。
【００４１】
説明の実施例においては、ある与えられたカートリッジと４つのパラメータ値が関連付けられ、システムは、各カートリッジに対するこれらパラメータを、予め定められた時間に、或いは特定のイベントが発生した際に読出し、適当なプロセス（process）を通じて、どのカートリッジが起動されるべきか、つまり、どの位置決定技術が用いられるべきかを、決定する能力を有する。
【００４２】
これら４つのパラメータは、一例として、精度（ACCURACY）、消費電力（POWER CONSUMPTION）、応答時間（RESPONSE TIME）及びカスタム（CUSTOM）から成る。
【００４３】
精度は、デフォルトモードであり、省略時には、システムは最良の位置精度を提供するカートリッジ（つまり、位置決定技術）を選択する。
【００４４】
ある与えられた技術に対するこれら精度、消費電力、応答時間に関するパラメータの値は、典型的には、位置決定技術の製造業者或いはプロバイダによって提供される技術仕様或いはデータシートから得られる。
【００４５】
カスタムなるパラメータは、開発者に利用可能な、別の現存する或いは将来の判断基準（criterion）に従って位置決定技術を選択する手段を与えるためのパラメータである。
【００４６】
各カートリッジは、それと関連する位置決定技術に依存して、物理的或いは論理的位置情報を扱う能力を有する。
【００４７】
例えば、近接技術（proximity technologies）等の技術は、Cartesian（デカルト）或いはWGS84等の物理的座標を生成する能力は有さず、単に、１つ或いは複数のIDしか識別できない。より具体的には、Bluetooth通信能力を有するモバイル装置は、圏内のビーコン（beacons）のアドレスBD＿ADDRしか得ることができない。同様に、無線周波数標準802.11bに基づく通信は、圏内のビーコンのMACアドレスを位置情報として提供し、RFタグシステム（RF tag system）は、それとのコンタクト（通信）が設定されているタグ（tags）の識別子（”RFid”）を提供する。
【００４８】
他の技術は、後に説明するように、位置情報として、物理的情報、例えば、デカルト座標（X、Y、Z）或いは標準の経度/緯度座標、及び場合によっては、好ましくは、WGS84標準に従う経度座標を提供する。
【００４９】
本発明によるシステムを用いるアプリケーションソフトウェアは、適当なメッセージを通じて、このシステムに対してそれが期待する位置データのタイプを指定することができる。
【００５０】
一例として、これらメッセージには以下が含まれる：
−”TO＿CARTESIAN”メッセージは、デカルト座標を返し；
−”TO＿WGS84”メッセージは、標準のWGS84緯度/経度及び場合によっては経度座標を返し；
−”TO＿LOGIC”メッセージは、ビーコン或いはタグ識別子等の論理的情報を返し；最後に、
−”TO＿ALL”メッセージは、物理的或いは論理的を問わず、全てのタイプの位置決定データを返す。
【００５１】
説明の実施例においては、WGS84座標を提供するGPSシステムと、圏内のBlutoothビーコンのアドレスを提供するBluetooth通信システムとの、２つの位置決定技術が考慮される。ただし、本発明の教示は他の位置決定技術にも容易に適合化できる。
【００５２】
ある与えられた位置決定デバイスが、自身では、位置情報を、アプリケーションソフトウェアによって要求されるフォーマットでは供給することができない場合に備えて、このシステムは、好ましくは、プラグ・インソフトウェアモジュール（plug-in software module）の形態にて、当業者において公知のやり方にて、ある与えられた位置フォーマットを別の位置フォーマットに変換するようにプログラムされた変換モジュールを含む。
【００５３】
例えば、この変換モジュールは、デカルト座標をWGS84座標に、或いはこの逆に変換する能力を有する。この変換モジュールは、加えて、論理的位置データから、デカルト或いはWGS84座標等の物理的位置データを決定する機能も担当する。
【００５４】
本発明のシステムは、以下のような他のタイプのプラグインモジュールを含むこともできる：
−履歴モジュール（history module）；履歴サービス、つまり、メモリ内に時間/日情報と関連させて格納された位置データを提供する能力を有し、このモジュールは、例えば、ユーザが位置履歴に対する時間窓、及びサンプリング頻度、つまり、位置データを関連する時間/日情報とともに分（時間或いは日、等）当り何回、格納すべきかを設定することを可能にする。
【００５５】
−位置情報を処理するための様々な計算モジュール；例えば、モバイル装置が様々な異なる位置決定技術から異なる位置データを生成する能力を有するときは、位置精錬プラグ・インモジュール（position refinement plug-in module）は、これらデータを入力として受け取り、これから、とりわけ、各位置決定技術の精度を考慮に入れて、精錬された位置データを計算することができる。
【００５６】
好ましくは、各プラグインモジュールは、計算分野に通じた者にとって周知のやり方にて動的に用いられる；つまり、システムは、あるプラグ・インモジュールの存在を自動的に検出し、必要とされるとき、適当なインストラクション及びパラメータを介してそのモジュール内のある与えられた実行を呼び出す。
【００５７】
例えば、変換モジュールがインストールされており、アプリケーションソフトウェア（或いはユーザ）が物理的位置データをある与えられたフォーマットにて求ているのに、起動されている位置決定技術（つまり、起動されているカートリッジ）は論理的位置データしか返すことができない場合、この変換モジュールは、自動的にこの論理的位置データをその与えられたフォーマットの物理的位置データに変換する。
【００５８】
同様にして、存在する場合、自動的に位置精錬プラグ・インモジュールが呼出され、同時に２つ或いはそれ以上の位置決定技術を用いてデータが得られ、これらデータから精度の点で精錬された位置データが生成される。
【００５９】
本発明によるシステムはアプリケーションソフトウェアと非同期的（asynchronously）モードにて通信することも、同期的（synchronously）モードにて通信することもできる。つまり、システムは、位置データをアプリケーションソフトウェアに、アプリケーションからのリクエストに応じて送ることも、指定された時間に送ることもできる。
【００６０】
この目的のためには、アプリケーションソフトウェアからシステムに様々な標準メッセージが送られる。基本的には、システムは、位置リクエストメッセージ（position request message）に応答して、リクエストされた位置データを含むメッセージを送り返す。非同期モードにおいては、システムに対して、アプリケーションソフトウェアに向けてそのメッセージ内にパラメータとして提供されるある与えられた速度（”ポーリング周波数”）にて自動的に位置データを送ることを要請するメッセージが用いられる。もう一つの可能性として、メッセージ内に、ポーリング周波数（頻度）の代わりに、パラメータとして、”RealMode”インジケータを含め、位置ハンドリングシステムが、それらが利用可能となると直ちに（非同期モード）、リフレッシュされた位置データを送り返すように求めることもできる。
【００６１】
実際的には、非同期モードは、好ましくは、”ロケーションリスナ（location listenner）”を介して実現され、これが、システム内で、位置データがリフレッシュされると直ちに位置データメッセージをアプリケーションソフトウェアに送り返すように、選択的に起動される。このロケーションリスナの不在はシステムによって自動的に検出され、この場合は、システムは、同期モード及び／或いは”オンデマンド（on demand）”モードにて動作する。
【００６２】
加えて、一つの好ましい実施例においては、アプリケーションソフトウェアは、システムが非同期モードにて動作している際に、”オンデマンド”にてローカライゼーション（on demand localization）を求める。
【００６３】
もう一つの好ましい特徴によると、各カートリッジは、システムから現在の動作モードに関する情報を受信することで、不要な位置決定動作の遂行を回避し、これによって電力消費を節約するとともに、場合によっては、応答時間を向上させる。
【００６４】
もう一つの好ましい特徴によると、システムが要求しているアプリケーションソフトウェアに対して位置データを送り返すとき、これらデータには、時間/日スタンプ及びその位置データの精度を示す精度情報が付加される。
【００６５】
一つの基本的な動作モードにおいては、この精度情報は、その位置を決定したカートリッジ内の精度（ACCURACY）パラメータの欄から直接に読み出されるか、或いはこれから派生的に得られる。
【００６６】
位置精錬モジュールが存在する場合は、このモジュールは、位置データの決定を行った２つ或いはそれ以上のカートリッジから読み出される精度パラメータを結合し、モジュールに入力される、これら精度パラメータから、結合された精度情報を計算する。
【００６７】
上述の位置、時間/日及び精度データに加えて、他の情報をアプリケーションソフトウェアに提供することもできる。
【００６８】
典型的には、これら追加の情報には、方向、速度、加速度等が含まれ、これらは、履歴データ、特定のハードウェアに関する記述子、等に基づいて計算によって決定される。
【００６９】
c）アーキテクチャ面の説明
以下では、本発明によるシステム及び方法に対する好ましいソフトウェアアーキテクチャを図１を参照しながらより詳細に説明する。
【００７０】
最初に、このアーキテクチャのコアは、位置及び関連する情報の処理を担当するLocation Handler（位置ハンドラ）と呼ばれる主位置ハンドリング要素から成る。この要素は、GPS NMEA、GPS SiRF及びBlueTooth等の複数の位置決定カートリッジを、サポートされる全ての位置決定技術に対する一つの共通のインタフェースを提供するカートリッジアプリケーションプログラミングインタフェース（cartridge application programming interface, API）（cartridge  API）を介して照会する。この主要素Location Handlerは、位置情報を用いるあらゆるアプリケーションソフトウェア（図１には示されていない）と、適当なアプリケーションプログラミングインタフェースLcation APIを通じて通信することができる。
【００７１】
上述のように、様々なプラグ・インモジュールがLcation APIにコヒーレントなサービス（coherent services）を提供するために用意される。図１には、履歴モジュールSmartHistory、変換モジュールSmartConvert及び計算モジュールSmartComputeが示されている。
【００７２】
SmartHistory、SmartConvert及びSmartCompute等のプラグインモジュールは、これらによって提供される機能のタイプの観点からは、各々、Lcation Handlerの上に構築される。
【００７３】
２）選択されたアルゴリズムの説明
以下では本発明のシステム及び方法において用いられる本質的なアルゴリズムについて説明する。
【００７４】
a）カートリッジの選択
最初に、CartridgeHandler（カートリッジハンドラ）なるプロセス或いはアルゴリズムは、現在起動されているカートリッジがまだ利用可能であるか否かをチェックし、まだ利用可能である場合は、その現在のカートリッジが選択される。その現在のカートリッジはもはや利用可能でない場合は、それは対応する資源を解放するために終了され、CartridgeHandlerプロセスは、システム内に格納されている現在のカートリッジのリスト（current cartridges list）を、利用可能な別のカートリッジを見つけるために分析する。あるカートリッジが利用可能であることが見つかった場合は、そのカートリッジが現在のカートリッジとして後に例示する選択プロセス（selection process）に従って選択される。現在のカートリッジのリストによって参照されるカートリッジのいずれも利用可能でない場合は、NoAvailableCartridgeException（利用可能なカートリッジが存在しない場合の例外処理）が立ち上げられる。
【００７５】
このカートリッジの選択は極めて単純なプロセスである。これは、ほとんどの負荷の大きな仕事（リストの更新等）は、（後に説明されるように）新たなカートリッジが追加/取り外されるとき及び／或いは新たな判断基準（criterion）或いは位置データフォーマットが設定される際に行われ、これらタイプの動作はカートリッジの選択と比べると稀にしか行なわれないためである。
【００７６】
カートリッジ選択の目的に対しては、CartridgeHandlerプロセスは、好ましくは、新たな位置が要求される度に呼出される。
【００７７】
b）カートリッジの挿入
ある新たなカートリッジがシステム内にインストールされると、CartridgeHandlerプロセスは、そのカートリッジが以前インストールされたことがあるか否かチェックする。肯定の場合は、CartridgeHandlerプロセスはなにも行なわない。否定の場合は、CartridgeHandlerプロセスは、そのインストールされたカートリッジを、Vector（ベクタ）と呼ばれるテーブル内に加えるが、このテーブルVectorは、全てのカートリッジのデータを集め、そのカートリッジの一意の識別子或いはインデックスを決定する（好ましくは、既に存在するカートリッジが１からNまでの間のインデックスを有するときは、次に利用可能な整数N+1が割当てられる）。Vectorテーブルの側には、整数値Int.の４つのアレイArrayが格納される。これら整数Arrayの一つは、位置情報（locations）をWGS84フォーマットにて返す能力を有するカートリッジのインデックスを含み、もう1つは、Cartesian（デカルト形式にて）位置情報を返す能力を有するカートリッジのインデックスを格納し、もう1つは、論理（logic）形式にて位置情報を返す能力を有するカートリッジのインデックスを格納し、最後の1つは、現在リクエストされている位置ファーマット及び望ましいとされる判断基準と一致するカートリッジのインデックスを格納する。整数値Intのこれら全てのアレイArrayは、後に説明するように、優先基準（priority criterion）に従って最も好ましいものから降順に並べられた位置決定デバイスのリストを構成する。CartridgeHandlerプロセスは、そのインストールされたカートリッジが供給することができる位置データフォーマットのタイプをチェックし、そのインデックスを対応するリスト内に書き込む。この挿入プロセスは、後により詳細に説明されるように、この好ましいとされる判断基準に基づくランク付けプロセス（ranking process）から多くの利益を受ける。
【００７８】
c）カートリッジの取り外し
カートリッジをアンインストール或いは取り外すことが必要となった場合は、CartridgeHandlerプロセスは、そのカートリッジがVectorテーブル内にリストされていたか否かをチェックする。否定の場合は、それはリストされておらず、CartridgeHandlerプロセスはなにも行なわない。肯定の場合は、CartridgeHandlerプロセスは、そのカートリッジの機能（capabilities）を検証し、これをVectorテーブルと対応するアレイArrayの両方から除去する。全てのインストールされたカートリッジが１からNの間の整数から成る一連のインデックスを有する実際的な実施例においては、Nより小さなあるインデックスを有するカートリッジの取り外しは、それより高いインデックスの変更も伴い、これらインデックスは１だけ減分される。
【００７９】
d）コンテクストに依存した設定
Location Handler（位置ハンドラ）がコンテクストが変わったこと（典型的にはこれはコンテクストメッセージとしてLocation Handler要素にパスされる）を検出すると、Location Handlerは、CartridgeHandlerプロセスに対して、パラメータに基づくカートリッジ選択に関する新たな関連する戦略（strategy）を設定し、それに基づいてアレイArray内において起動されるべきカートリッジの順番を優先順に並べ替えることを求める。
【００８０】
d）位置データフォーマットの設定
Location Handler要素がアプリケーションソフトウェアからのリクエスト或いはメッセージに基づいて、現在のフォーマットとは異なるある新たな位置データフォーマットが用いられるべきであることを決定すると、これは、CartridgeHandlerプロセスに対して、アレイArray内の現在のカートリッジのインデックスを更新し、その変更を反映されることをリクエストする。
【００８１】
e）カートリッジモードのスイッチング
あるカートリッジがサポートする作業モードに関してはいかなる想定もなされない。これは、局所モード（localization modes）（同期或いは非同期）は、より高いレベルにて扱われるべきことを意味する。他方において、幾つかの位置決定デバイスは、生来的に、ある特定のケースにおいて最良に振る舞うことができるように様々な異なるやり方にて動作する能力を有する。
【００８２】
本発明のシステムは、共通のインタフェースを提供することと、各デバイスを最大限に活用すること、の両方を目的とするために、Location Handler要素は、好ましくは、複数のモードをサポートする位置決定技術（PDT）と関連するカートリッジの動作のモードをLocation Handler要素の現在の状態に合わせてスイッチングする能力を含む。
【００８３】
例えば、ある起動されたカートリッジは、デフォルトにて、同期モードにて動作するように設定することもできる。ただし、そのカートリッジがLocation Handler要素からCartridgeHandlerプロセスを通じて、モードを同期モードから非同期モードに変更されたことを示すメッセージを受信すると、そのカートリッジは、その動作を、このモードの変更に順応させ、その位置決定技術（PDT）をそれに従って制御する。
【００８４】
逆に、Location Handler要素のモードが、元の同期モードに設定されると、CartridgeHandlerプロセスは、起動されているカートリッジのモードを、典型的には、これをいったん不能にし、その後、これを同期モードにて再起動させることで、同期モードに回復させる。
【００８５】
f）カートリッジのタイプ
説明の実施例においては、Location Handler要素は、以下の２つのタイプのカートリッジにアクセスすることができる：
‐純正（pure）Javaカートリッジ：これらはKVM標準に基づくカートリッジであり（KVMは、”K  Virtual Machine”、つまり、ある与えられた計算プラットホームに対するJava 2 Micro Edition環境の標準実装に対する略称）；この例には、シリアルポートを通じて通信するGPS NMEA位置決定技術に対するカートリッジがある。
【００８６】
‐ネイティブ（native）カートリッジ：これらは拡張KVM仮想マシーンに基づくカートリッジである（これには、例えば、標準の或いは特定のBlueToothアプリケーションプログラミングインタフェース（API）を用いるBlueToothカートリッジ、例えば、標準のKVM環境内に含まれる標準のカートリッジがある）。こうして、これらカートリッジは、ネイティブな方法（native methods）に対して特定の呼を発する能力を有する（これは、例えば、一体化されたGPSモジュールにアクセスすることができる幾つかのセルラ電話、例えば、現在Benefon社から市販されているセルラ電話の場合に当てはまる）。
【００８７】
g）あるコンテクストと関連するPDT制約の例
上述のように、各カートリッジは複数の関連するパラメータを格納し、説明の実施例においては、精度（ACCURACY）、消費電力（POWER CONSUMPTION）、応答時間（RESPONSE TIME）及びカスタム（CUSTOM）なるパラメータを格納する。
【００８８】
他方において、Location Handler要素は、アプリケーションソフトウェアからのメッセージを通じて、このシステムを実装するモバイル装置がどのようなタイプのコンテクスト或いは物理環境内で動作しているかを示す”コンテクスト（context）”情報を受信する能力或いはこれを自身で決定する能力を有する。
【００８９】
例えば、モバイル電話が、車内にあってその受話器台（cradle）上に置かれている場合、非常に単純な論理にてこの事実を知り、これに基づいてコンテクストパラメータ値In Carを設定することができる。
【００９０】
同様にしてプラグインモジュール（plug-in module）によって扱われた位置履歴SmartHistory、とりわけ、そのモバイル装置の現在の平均速度を分析することで、Location Handler要素は、そのユーザが歩行中（On Foot）であるか、或いは再び車内（In Car）に戻ったかを知ることもできる。
【００９１】
加えて、BlueToothカートリッジ等のカートリッジをポーリングし、BlueToothビーコン（beacons）が圏内に検出されるか決定することで、Location Handlerは、自身で、あるモバイル装置が室内（Indoor）にあることを決定することができる。検出されない場合は、そのモバイル装置は室外（Outdoor）に存在するものとみなされる。
【００９２】
加えて、アプリケーションソフトウェアは、このソフトウェアによって決定或いは得られた任意の他のコンテクスト情報をLocation Handler要素に与えることもできる。
【００９３】
以下のテーブルIは、Location Handler要素によって、ある与えられたコンテクスト内で最も適当なカートリッジを選択及び起動するために用いられるパラメータの優先度の例を示す。このテーブルにおいては、コンテクストは、３つのパラメータ値、つまり、ユーザの状況に関する情報（user situation information）、位置情報（location information）、及びサービス情報（service information）の組み合わせによって定義される。サービス情報は、典型的には、ある与えられたアプリケーションソフトウェアが、様々な異なるタイプのサービスを提供し、従って、用いられるべき位置決定技術に関する様々な異なる要件を有する場合に必要となる。
【表１】
2005530427.tif 000003
【００９４】
h）位置決定技術の例
本発明は、長所として、全ての現在利用可能な位置決定技術とともに用いることができる。これら技術の典型例がそれらの特性の以下のテーブルIIに与えられている：
【表２】
2005530427.tif 000004
【００９５】
”位置決定精度”及び”応答時間”なる特性としては対応する駆動カートリッジ内のパラメータを直接に用いるこができ；”消費電力”なるパラメータは、通常は、製造業者の技術データから直接的に或いは間接的に得られる。
【００９６】
i）位置決定技術の動的なスイッチングの実際例
現在、モバイル装置は、”車内室外ナビゲーション（In Car Outdoor Navigation）”コンテクスト下にあり、ユーザにユーザの現在の位置とショッピングモールとの間のリアルタイムナビゲーション指令を提供するための位置決定データが必要とされているものと想定する。
【００９７】
システムは、最初に、テーブルIIにリストされるような、全てのインストールされた位置決定技術（PDT）の中から、利用可能な位置決定技術（PDT）を決定する。説明の例においては、BlueTooth位置決定技術は利用できない（近傍においてBlueToothビーコンは検出されない）。このため、優先度パラメータは位置決定精度であるものと設定されているため、GPS PDTが最も好ましく、セルラID PDTは二番目に好ましいものとして決定される。
【００９８】
仮に、このプロセスが２つの位置決定技術（PDT）が優先度の判断基準からは同一パラメータ値を有するものと決定した場合は、このプロセスは、第二のランクに来る判断基準（ここでは、”応答時間”なる判断基準/パラメータ）から見て最良のパラメータを有する位置決定技術（PDT）を使用されるべきPDTとして選択することとなることに注意する。
【００９９】
いったん、ユーザがショッピングモールに到着すると、アプリケーションソフトウェアによって自動的に、及び／或いはユーザ自身によって、手動にて、適当な入力動作を通じて、コンテクストが”歩行中室内ナビゲーション（On Foot Indoor Navigation）”に設定される。市販のナビゲーションアプリケーションソフトウェアは、ユーザに、例えば、ショッピングモールの入り口から選択された店までの間のナビゲーション情報を提供する機能を有する。
【０１００】
システムは、この新たなコンテクストを考慮に入れて、利用可能なPDTから、１）現在利用可能であり、２）この新たなコンテクストにより適する位置決定技術（PDT）を見つけることを試みる。
【０１０１】
ユーザコンテクストとの関連で指定されているより高い優先度の判断基準、つまり”消費電力”に従うと、そして、Bluetooth PDTは現在は利用可能であり、これが最良の”消費電力”パラメータを有するものと想定すると、BlueTooth  PDTが選択され、起動されることとなる。
【０１０２】
図２、３及び４は、本発明によって遂行されるこれら基本的なプロセスを簡略的に解説する。これら図面の各々において、これら３つの枠（コラム）は、左から右に順に、アプリケーションソフトウェアレベル（”Application”）、位置ハンドリングレベル（”Dynamic Switching”）、及び位置決定技術レベル（”PDT”）を示す。
【０１０３】
図２に示すように、コンテクストが変化するときの主プロセスを図示し、新たなコンテクストがアプリケーションソフトウェアレベルで決定される。パラメータとして新たなコンテクストの指定（designation）を含む対応するメッセージが位置ハンドリングシステム（location handling  system）に送られる。このレベルにおいては、第一のテストとして任意の位置決定技術（PDT）が実装されている否か（つまり、対応するカートリッジがインストールされていりか否か）調べられる。位置決定技術（PDT）が全く実装されてない場合は、位置ハンドリングシステムは、このことを示すメッセージをアプリケーションソフトウェアに送り、こうしてこのプロセスはアボート（終端）する。
【０１０４】
位置ハンドリングシステムが少なくとも一つの位置決定技術（PDT）が実装されていることを検出したときは、対応するカートリッジに向けてメッセージを送ることで、その特性（つまり、パラメータ＋データフォーマット）が得られる。
【０１０５】
次に、位置ハンドリングシステムは、適用されるべき判断基準を、コンテクストに依存して、順番或いは優先順に、識別し、これら判断基準を一群の特性に適用することで、その新たなコンテクスト下において用いられるべきインストールされている位置決定技術（PDT）のランク付けを好み順に生成する。この目的に対しては、上述の整数IntのアレイArrayが用いられる。
【０１０６】
上述のランク付けプロセス（ranking process）において、どの位置決定技術（PDT）も新たなコンテクストによって指定される要件に適さないことが発見された場合は、対応するメッセージがアプリケーションソフトウェアに送られ、このプロセスは終端する。
【０１０７】
新たなコンテクストによって指定される要件に適する少なくとも一つの位置決定技術（PDT）が見つかった場合は、そのランクに対応する位置決定技術（PDT）の順序を付けられたリストが生成され、最も好ましいものから降順に（Arrayとして）格納される。コンテクスト変更プロセスはこれによって終端する。
【０１０８】
図３に示されるように、アプリケーションソフトウェアは、位置ハンドリングシステムに位置リクエストメッセージ（location request message）を送る。
【０１０９】
すると、位置ハンドリングシステムは、図２との関連で説明したようにメモリ内に格納されている順番を付けられたリストを、最も好ましいものから降順に分析し、各位置決定技術（PDT）が利用可能であるかチェックする。
【０１１０】
どの位置決定技術（PDT）も利用可能でないように思われる場合は、対応するメッセージがアプリケーションソフトウェアに送られ、その後、このプロセスは終端する。
【０１１１】
他方、ある位置決定技術（PDT）が利用可能である（最も適する）と決定された場合は、それに対応するカートリッジ（PDT）に向けて位置に対するリクエスト（request for position）が送られ、次に、その位置データが、位置ハンドリングシステムによってアプリケーションソフトウェアに転送される。
【０１１２】
データフォーマットの変換が要求される場合は、これは、この段階において、位置ハンドリングシステムの制御下で遂行される。
【０１１３】
図４は、図３に示されるプロセスに対する一つのバリエーションを示す。
【０１１４】
図３においては、位置データがリクエストされる度に、利用可能な最適な位置決定技術（PDT）はチェックされたが、図４のプロセスにおいては、このチェックは毎回は遂行されない。
【０１１５】
より具体的には、位置リクエストメッセージが位置ハンドリングシステムによって受信されると（勿論、コンテクストの変更はないものと想定される）、システムは、最初に、ある位置決定技術（PDT）が既に選択されている或いは起動されているか否か調べる。
【０１１６】
否定の場合は、図３に示されるのと同一のプロセスが遂行される。肯定の場合は、現在選択されている位置決定技術（PDT）の利用可能性が決定される。その位置決定技術（PDT）がまだ利用可能である場合は、その位置決定技術（PDT）に対応するカートリッジから位置データが得られ、アプリケーションソフトウェアに転送される。他方、現在選択されている位置決定技術（PDT）がもはや利用でない場合は、図３のプロセスを遂行することで、最も好ましい利用可能な位置決定技術（PDT）が見つけられる。
【０１１７】
勿論、上に説明の発明に対する様々なバリエーション及び修正が可能である。
【０１１８】
より具体的には、本発明は、多様な現在及び将来の位置決定技術（PDT）、例えば、多様な無線技術を用いてのOTD（Observed Time Difference）、従来（classical）のGPS、差分（differential）GPS、アシスティッド(assisted）GPS、Cell-ID（セルラ電話ネットワーク）、エンハンスド（Enhanced Cell-ID）、BlueTooth beacon ID、及びインテリジェントモバイル装置に対する類似のRF通信システム、距離測定能力を備えるBlueTooth等、との関連で用いることも可能である。
【図面の簡単な説明】
【０１１９】
【図１】本発明による位置ハンドリングシステムを組み込んだモバイル装置の一般アーキテクチャのブロック図である。
【図２】本発明において用いられるコンテクストの変化に係るプロセスを解説する流れ図である。
【図３】本発明において用いられるロケーションメッセージに係るプロセスを解説する流れ図である。
【図４】図３のプロセスの代替としてのプロセスを解説する流れ図である。
【図１】
2005530427.tif 000005
【図２】
2005530427.tif 000006
【図３】
2005530427.tif 000007
【図４】
2005530427.tif 000008
【国際調査報告】
2005530427.tif 000009
2005530427.tif 000010
2005530427.tif 000011