(57)【要約】第１の無線情報装置が絶対位置データをアクセスできる方法であって、第１の無線情報装置は独自の絶対位置決定システムを所有していないが、独自の絶対位置決定システムを有する第２の無線情報装置からの絶対位置データを無線ネットワークを介して受信することが可能である。従って本発明によれば、無線情報装置が絶対位置データを共有することを可能にする。例えば、ＧＰＳ能力を有する携帯電話の付近にある、あらゆる装置が携帯電話の位置データを使用することができるように、パーソナルエリア無線ネットワーク（例えば、Bluetoothネットワーク）を介して携帯電話の絶対位置を付近の装置へ一斉送信するために、携帯電話をローカル「ビーコン」として使用することができる。従って、独自の位置決定システムを持たないカメラが付近のＧＰＳ装備携帯電話からBluetooth ＰＡＮを介して位置データを獲得し、カメラの画像に位置データによって電子透かしを挿入することが可能になる。【特許請求の範囲】
【請求項１】
第１の無線情報装置により絶対位置データをアクセス可能にする方法であって、
前記第１の無線情報装置は独自の絶対位置決定システムを所有していないが、無線ネットワークを介して、独自の絶対位置決定システムを有する第２の無線情報装置から絶対位置データを受信することを特徴とする方法。
【請求項２】
前記無線ネットワークは短距離パーソナルエリアネットワークであることを特徴とする請求項１に記載の方法。
【請求項３】
前記第２の無線情報装置は携帯電話であることを特徴とする請求項１に記載の方法。
【請求項４】
前記第２の無線情報装置の絶対位置決定システムは、ＧＰＳ又は到着時間システムのような無線ベースシステムであることを特徴とする請求項１に記載の方法。
【請求項５】
前記第２の無線情報装置は、その絶対位置によってプログラムされているが、独立して絶対位置を獲得できないことを特徴とする請求項１に記載の方法。
【請求項６】
前記第２の無線情報装置は、何らかの許可されたコンポーネントが、前記第２の無線情報装置で実行されているか又は前記第１の無線情報装置で実行されているかに拘わらず、位置品質パラメータを定義し、それらのパラメータに適合する、前記第２の無線情報装置で実行されている１つ或いはそれ以上の絶対位置決定システムからの位置データが送信されることを可能にするようにプログラムされていることを特徴とする請求項１に記載の方法。
【請求項７】
前記何らかの許可されたコンポーネントが、前記第２の無線情報装置で実行されているか又は前記第１の無線情報装置で実行されているかに拘わらず、前記第２の無線情報装置で実行されている位置決定システムのうちのいずれかにより発行される位置データを引用できるように発行ＡＰＩ及び引用ＡＰＩが使用されることを特徴とする請求項６に記載の方法。
【請求項８】
前記第１の無線情報装置は、前記第２の無線情報装置が進行している速度を指示するために前記第２の無線情報装置から速度データを、前記無線ネットワークを介して受信できることを特徴とする請求項１に記載の方法。
【請求項９】
前記第１の無線情報装置は、前記第２の無線情報装置が進行している方向を指示するために前記第２の無線情報装置からの方向データを、前記無線ネットワークを介して受信できることを特徴とする請求項１に記載の方法。
【請求項１０】
前記第１の無線情報装置はスチルカメラ又はビデオカメラであることを特徴とする請求項１に記載の方法。
【請求項１１】
前記第１の無線情報装置は財物追跡に使用されるタグであることを特徴とする請求項１に記載の方法。
【請求項１２】
前記第１の無線情報装置はデジタルミュージックプレイヤーであることを特徴とする請求項１に記載の方法。
【請求項１３】
前記第１の無線情報装置は、獲得される位置データを共有するために別の無線情報装置に連鎖接続されていることを特徴とする請求項１に記載の方法。
【請求項１４】
第１の無線情報装置が絶対地理データにアクセス可能にする方法であって、
前記第１の無線情報装置は独自の絶対地理発見システムを所有していないが、独自の絶対地理発見システムを有する第２の無線情報装置からの絶対地理データを無線ネットワークを介して受信することを特徴とする方法。
【請求項１５】
絶対地理データをアクセスする無線情報装置であって、
第１の無線情報装置は独自の絶対地理発見システムを所有していないが、独自の絶対地理発見システムを有する第２の無線情報装置からの絶対地理データを無線ネットワークを介して受信することを特徴とする無線情報装置。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の分野
本発明は、無線情報装置により位置データをアクセス可能にする方法に関する。この明細書で使用される「無線情報装置」という用語は、１方向又は２方向の無線通信能力を有するあらゆる種類の装置を含むと広い意味で解釈されるべきであり、無線電話、スマート電話、コミュニケータ、パーソナルコンピュータ、コンピュータ、並びにカメラ、ビデオレコーダ、財物追跡システムなどの無線通信が可能な特定アプリケーション向け装置を制限なく含む。この無線情報装置は、ＧＳＭ又はＵＭＴＳ、ＣＤＭＡ及びＷＣＤＭＡ移動無線、Bluetooth，IrDAなどのあらゆる種類のネットワークを介して任意の方式で通信することが可能である装置を含む。
【背景技術】
【０００２】
従来の技術の説明
移動インターネット装置及び第３世代移動ネットワークがより広く普及するようになるにつれて、位置利用サービスは主要な成長分野であると考えられている。位置認識に基づいて情報、コンテキスト及びサービスを提供することにより、ユーザにとっては新たな可能性及び簡略化されたインタフェースが与えられるようになり、更に、オペレータやサービスプロバイダにとっては新たな収益の道が開かれることになる。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
移動装置に対して自動的に位置情報を提供するために要求される技術は、この数十年間にわたり絶えず開発されてきた。その大半は陸海空軍への適用に根ざすものであったが、特に大都市環境においては、多くの課題に対処するために最新のコンシューマー技術も発達してきている。無線情報装置で使用するために採用されている典型的な位置決定技術の例は、ＧＰＳ及び信号到達の時間を非常に正確に測定できる基地局三角測量技術である。自身の絶対位置を判定することが可能な装置は、従来、独自の位置決定コンポーネント（例えば、ＧＰＳ受信器及び関連ソフトウェア）を含んでいなければならなかった。それらの位置決定システムは、通常、「絶対位置」を確定するものとみなされる。これは、論理的位置（例えば、特定の位置ビーコンに近い）とは異なり、ＷＧＳ−８４などの絶対基準フレームにおける物理的位置を意味している。
【課題を解決するための手段】
【０００４】
発明の概要
第１の態様においては、第１の無線情報装置が絶対位置データをアクセスすることを可能にする方法であって、第１の無線情報装置は独自の絶対位置決定システムを所有しておらず、独自の絶対位置決定システムを有する第２の無線情報装置からの絶対位置データを無線ネットワークを介して受信することが可能であるような方法がある。
【０００５】
従って本発明は、無線情報装置が絶対位置データを共有することを可能にする。例えば、ＧＰＳ能力を有する携帯電話をローカル「ビーコン」として使用し、その携帯電話の絶対位置を付近の装置へ無線ＰＡＮ（パーソナルエリア・ネットワーク、例えば、Bluetoothネットワーク）を介して一斉送信する（broadcast）ことにより、その携帯電話の付近にある、あらゆる装置がその携帯電話の位置データを使用することができる。従って、独自の位置決定システムを持たないカメラが、その付近にあるＧＰＳを装備している携帯電話からの位置データをBluetoothＰＡＮを介して獲得し、カメラの画像に位置データによって電子透かしを挿入することが可能になる。本発明は、無線情報装置により確定された絶対位置は、その装置にのみ関連するという一般的な仮定とは反対の立場をとっている。本明細書における意味での「絶対位置」は、論理的位置（例えば、特定の位置ビーコンに近い）とは異なり、ＷＧＳ−８４などの絶対基準フレームにおける物理的位置を表している。
【０００６】
第２の無線情報装置は、財物追跡で使用される単純なＲＦＩＤタグであっても良い。タグが絶対位置データを一斉送信している装置に十分に近接するたびに、そのタグはその絶対位置を記録し、それにより、そのタグの移動経路の記録を形成する。
【０００７】
また第２の無線情報装置は携帯可能な装置である必要はなく、絶対位置がプログラムされた単純な固定位置ビーコンであっても良い。また第２の無線情報装置は、その位置を独立して獲得することができなくても良いが、単純に位置をプログラムされるだけであっても良い（例えば、ＷＡＮに接続され、そのＷＡＮを介して絶対位置が送信されても良い）。
【０００８】
第２の無線情報装置は、何らかの許可されたコンポーネントが、第２の無線情報装置にあるか又は第２の無線情報装置の外にあるか（例えば、第１の無線情報装置にある）に拘わらず、位置品質（「ＱｏＰ」）パラメータを定義し、それらのパラメータに適合する、第２の無線情報装置で実行されている１つ以上の絶対位置決定システムからの位置データを送信可能にプログラムされていても良い。
【０００９】
位置データに付随する他の種類のデータも、無線ネットワークを介して第１の装置と第２の装置の間で共有されても良い。例えば、第２の無線情報装置がＧＰＳ受信器を有している場合には、絶対位置座標が生成されるばかりではなく、速度座標及び方向座標も生成される。本発明によれば、絶対位置、速度及び方向（又は実際には他のどのような絶対地理標識も）のうちのいずれか又はそれら全てを装置間で共有することができる。従って、本発明は「分散絶対地理認識」の概念、即ち、絶対地理データ：絶対位置、位置を確定するために使用されるその絶対基準フレームにおける速度又はその絶対基準フレーム内における方向（或いはそれら３つの何らかの組み合わせ）を配分又は共有するという概念を導入する。従って、本発明は、唯一の装置がその絶対地理データを実際に獲得し且つ共有する能力、又は１つの装置が１種類の絶対地理データを獲得し、別の装置は異なる種類を獲得する能力を発揮させる（leverage）。
【発明を実施するための最良の形態】
【００１０】
以下、添付図面を参照して本発明の好適な実施の形態を詳しく説明する。
【００１１】
本発明の１つの実現形態は、（ａ）自身の絶対位置を認識していると共に、そのデータ位置を送信可能な何らかの種類の装置と、（ｂ）送信されたその位置データを受信することが可能であり、何らかの理由により、絶対位置の情報を使用できることから利益を受けると思われる何らかの種類の無線装置との間での、絶対位置データの共有を可能にする。最も実用的な実現形態においては、データ送信は、Bluetoothネットワークなどの非常駐パーソナルエリア無線ネットワークを介する。更に、多くの携帯電話は、近い将来に何らかの形態の絶対位置決定能力を有するようになり、従って、その絶対位置データを、その付近の装置へ送信するための理想的な位置ビーコンを形成するであろう。
【００１２】
本発明の適用が可能であると思われる分野の広さを示すために、以下に更に使用例を挙げて説明する。
【００１３】
使用の実例
１．興味深い使用例は、MP3/OggVorbisデジタル音楽再生装置により、本発明を使用して（例えば、ユーザの位置でイネーブルになっている携帯電話から）ユーザの絶対位置をピックアップし、そのユーザにその位置を思い出させる、又はそのユーザにその位置を連想させるお気に入りの歌を再生させることである。これには、音楽再生装置が複数の位置及び各々の位置と関連する楽曲を含むデータベースを格納し、それを更新可能にする必要がある。
【００１４】
２．別のより単純な概念は、カメラで写真を撮影する場合に、カメラが葉書に場所の位置を埋め込むというものであり、その後、その場所に位置オブジェクトを含むObexを使用してネットワークを介してそのカードを送信することができる。
【００１５】
３．他の使用例は財物追跡及び車両管理サービスであり、この場合、例えば、宅配便業者が小荷物を配達するときに、サインをした者が、その署名を配達の場所と共に有効に電子透かしとして挿入する。車両管理の場合には、無線情報装置は車両に搭載された位置システムから、その位置を発見（又は計算）することができるであろう。
【００１６】
４．別の使用例は、「無線チェーン」の中の多数の装置が他の装置から獲得される位置決定データを中継してゆく位置中継のケースである。そのシナリオにおいては、そのような唯一の装置が絶対ロケーションを（例えば、ＧＰＳ又はガリレオ衛星から）獲得でき、他の装置はそれを中継する。従って、例えば、１つの建物の中で、多数の装置がその位置を、ホップ（hop）の数から計算できる誤差と共に知ることができる。そのような状況では、複数のソースを使用して三角測量も可能である。
【００１７】
５．興味深い使用の実例は、動作範囲が限定された財物追跡のケースである。例えば、ラップトップが事前に規定されたエリア／構内などを離れてはならない場合である。その場合には、そのような位置ビーコンをシークし、そのような位置識別が実行された場合には完全にロック又は破壊（自動的に又は基地への通信の後に）するようにラップトップをプログラムしておくことができる。そのラップトップ（又は他の装置）のこの場合における、独自の位置システムを持たないことの価値は、他の数多くの装置から位置ビーコンをピックアップでき、認証の後に適切な決定及びアクションを実行できる（又は実行しない）ことである。
【００１８】
６．先に述べたように、非位置データを共有することも可能である。例えば、自動車に搭載されたＧＰＳナビゲーションシステムは、自動車に搭載されたデータレコーダと速度データを共有でき、スピードを出しすぎると、ユーザに対して警告を発するであろう。自動車搭載データレコーダは、ＧＰＳシステムからの位置情報を使用して、（例えば、TomTom Navigatorなどの従来のＧＰＳナビゲーションソフトウェアと関連して）自動車が通行している道路を確定し、あらゆる道路に関する適用可能な制限速度のデータベースを使用して、自動車が速度を増しているか否かを確定することができるであろう。また、ＧＰＳナビゲーションシステムは、自動車搭載道路課金システムとも位置データを共有できるであろう。渋滞課金システムは、自動車の位置が課金エリア（例えば、有料道路、渋滞エリア）に対応している場合に機能し、適切な勘定付け又は課金又は支払いが行われることを保証できる。
【００１９】
絶対位置データを共有するために使用される方法は相対的にわかりやすい。例えば、Bluetoothを介して絶対位置情報をパーソナルエリア・ネットワークへ配分するための１つの方法は、汎用ユニーク識別子（ＵＵＩＤ）を使用して、その位置情報を提供する特定のサービスに対して、装置に位置認識装置のＳＤＰ（サービス発見プロトコル）レコードを照会させる方法である。実際には、位置認識装置は、そのＳＤＰサービスレコードにロケーションデータを含め、その結果をＳＤＰ応答に埋め込んで関心ある関係者に戻す（位置決定サービスに接続するために遠隔装置の関連情報を戻すのとは逆である）ことにより、このプロセスをはるかに単純且つ迅速に実行することができる。
【００２０】
別の方法（より多くのバッテリ電力を必要とするであろう）は、未加工のBluetooth Link Layer AUXパケットを使用して、そのようなロケーションを定期的に一斉送信／マルチキャストさせ、それにより、それを聴取できるあらゆる者に、そのロケーションをピックアップさせることを可能とする方法であろう。
【００２１】
パーソナルコンタクト情報のためのyCardフォーマットに類似する規格化位置データフォーマットが使用されても良い。
【００２２】
現在、位置情報を必要とするアプリケーションは、位置データを提供する技術に厳密に拘束されている。このため、開発担当者は、ＧＰＳ及びＧＳＭ三角測量位置技術がどのように動作するかを詳細に理解する必要があり、それは煩わしいことである。本発明は、第２の無線情報装置のＯＳにおいて、アプリケーション及びあらゆるシステムサーバを、その基礎にある決定位置技術から分離する「絶縁レイヤ」を使用して実現されても良い。従って、位置決定技術（例えば、ＧＰＳプラグイン又はＧＳＭ三角測量プラグイン）は、絶縁レイヤ（Symbian OS実現形態におけるサーバ）に位置データを提供する。このサーバ絶縁レイヤは、ジェネリックＡＰＩを介して、その位置データを必要とするあらゆるクライアント（例えば、アプリケーション又はシステムサーバ）に、その位置データに対するアクセスを与える。クライアントは、第２の無線情報装置自体にあるクライアントに限定される必要はなく、独自の位置決定システムを有していない全く別の装置に常駐していても良いということが重要である。
【００２３】
この位置決定絶縁レイヤ方式には更に利点がある。すなわち：
・アプリケーション開発担当者は、ＧＰＳなどのあらゆる位置決定技術の詳細を理解する必要なく位置利用アプリケーションを開発できる。或いは、位置データを提供しているべきである位置決定技術の種類を定義することさえできる。開発担当者は単にＡＰＩを使用できれば良いのである。
【００２４】
・位置決定技術開発担当者は、あらゆるアプリケーション又はシステムサーバの詳細を理解する必要なく位置決定技術を開発できる。この位置決定技術は、潜在的にホットスワッピング可能な（hot swappable）プラグインとして実現されても良い。
【００２５】
・位置データを必要とする装置にあるどのアプリケーション又は資源も、今や容易に位置データを獲得できる。位置データは全ＯＳを介して利用可能にされている。
【００２６】
・任意の時点でどの技術を使用すべきかを絶縁レイヤが決定するようにして、１つの装置で複数の位置決定技術を実行させても良い。アプリケーションは、これら技術間のホットスワップに関しての知識を全く必要としない。
【００２７】
・位置情報は様々に異なるシステムサーバに容易に供給されることが可能である。例えば、どのベアラ／プロトコル（bearer/protocol）を介して通信すべきかを決定するシステムサーバは、位置情報を供給され、その位置情報を自身の決定実行の一部として使用しても良い。Bluetoothポッドの範囲内にあるとき、Bluetoothに変更しても良く、その範囲外にある場合には、ＧＳＭなどに戻るようにしても良い。
【００２８】
・装置が盗まれたという適切なトリガメッセージを装置が受信した場合、その装置はその位置情報を（例えば、警察に）発信するように構成されても良い。
【００２９】
・何らかの許可されたサーバが、第２の無線情報装置で実行されているか又は第１の無線情報装置で実行されているかに拘わらず、第２の無線情報装置で実行されている複数の位置決定システムの内のいずれかより発行される位置データを引用することを可能にするために、発行ＡＰＩ（publisg API）及び引用ＡＰＩ（subscribe API）を使用することができる。
【００３０】
［付録１］
付録１は、位置認識オペレーティングシステムの適切なアーキテクチャの更に詳細な説明に加えて、いくつかの重要な設計原理の解説を含む。
【００３１】
１．ソースデータ処理
位置認識装置は、１つ或いはそれ以上の異なる位置感知技術を使用することができる。２つ以上の技術が使用される場合、複数のソースからの位置データを単一の位置推定に組み合わせるための技法が採用されても良い。これは、収集技法及び正確さに関して、様々に異なるソースが様々に異なる特性を有している場合に特に有用である。そのような処理の目的は、位置決定データの新たな正確さを個別のどのソースの正確さをも超えるように改善することである。
【００３２】
ＧＰＳデータとＩＮＳデータを組み合わせるために、カルマン（Kalman）フィルタリングが使用されることが多いが、それは、各々のデータの強さが他のデータの弱さを非常に適切に補償し、その結果、ある瞬時に、それらのデータのいずれかが提供できる正確さよりも高い正確さを有するデータが出力されるためである。
【００３３】
２．機密保護、プライバシー
位置情報の機密保護は「誰が」、「どこで」及び「いつ」に基づいている。それらは保護する重要度の順に列挙される。位置認識装置は、それが誰を表すかを、最も安全に保護すべきである。先に説明したように、人物が存在している「どこか」は、所在において他者とも合理的に共有されることが可能であり（ただし、「誰が」が共有されていない限り、議論の余地はある）、また時間は誰とでも共有されることが可能である（その他の２つを限定する）。
【００３４】
しかし、これら情報の内２つ以上が知られているとき（特に、３つ全てがある時間の範囲に亘って知られているとき）に最も危険であり、遠く離れた場所にいる者達に対して３つ全ての漏洩を保護することは、この最も微妙な組み合わせが悪の手に落ちるのを回避する最も成功率の高い方法である。従って、それら３つの各々は、「知る必要があるときだけ」を基本として発行されるべきであり、個人の装置でオープンなサービスを提供することは、ユーザの明瞭な命令に応じてのみ実行されるべきである。
【００３５】
３．位置発見とナビゲーション
サービスを区分するもう１つの方法は、位置発見（静的）と、空間を介するナビゲーティング（動的）を区分する方法である。第３のクラスはこれら２つの交差（移動しながら絶えず発見する）である。
【００３６】
発見は、
１．自身の位置（「私はどこにいるか？」）
２．他の位置（「私はどこへ向かっているか？」）
３．人物の位置（「バディファインダ（Buddy finder）」）
４．情報フィルタリング（「月曜日の朝に家から出る前の現在交通情報」）
５．アクション／イベントフィルタリング（「映画館又は上司の事務所にいるときには大きな音で音を鳴らさない」）
６．サービス位置（「最寄りの．．．を探す」）
７．位置の他の特性（地方時ゾーン、交通状態、天候など）
などの多数のエリアに対応する。ローカルサービスを、位置の特性としてみなすことができるため、終わりの２つは相当な程度で互換性を持ち、サービスは、それ自体、その位置に関する他の情報（特性）を提供できるであろう。
【００３７】
４．位置認識：アーキテクチャの考察
Ａｐｐ（アプリケーション）エンジン
位置の知識は、本質的にアプリケーションサービスであるが、位置データを使用するアプリケーションは、無線ＰＡＮを介して接続されるいくつかの装置に分散されても良いという点を理解することが重要である。
【００３８】
コンタクツ（Contacts）アプリケーション及びアジェンダ（Agenda）アプリケーションは、位置データから多くの利益を得ることができ、ジャーナリング（日記やメモ）の潜在能力もある。ローカルコンテンツ並びに遠隔コンテンツに対する位置利用の検索が容易になる。例えば、文書において、現時点では「時間」スタンプが存在している箇所に「位置」スタンプを想像することができるであろう（例えば、電子署名がなされている場所を確定するため；証拠を残すために写真に、不正に手を加えたときに直ちにわかるように、位置データを電子透かしとして挿入する）。また、記号による位置情報をログすること、又はこの情報を、一般に使用される位置に関してコンタクト、例えば、My Contacts & My Locationsに結びつけることを望む場合もあるだろう。
【００３９】
「World（世界）」マッピングアプリケーションは、位置から自動更新することができるであろう。実際には、ロケーションサーバから利用可能である情報の一部、例えば、時間ゾーン及びローカルダイアリングコードを再発行する。これらがロケーションサーバへ規格化されれば、「World」アプリケーションサーバは、単にそれらを中継すること（又はおそらくは全て完全に消滅すること）ができるであろう。
【００４０】
５．電力管理−ポーリング関係
初期利用モデルは、一般に、位置情報は、ユーザの直接介入を介してのみシークされると仮定する。これは機密保護及び電力消費に関わる数多くの問題を解決する。しかし、これは、ユーザが位置データの収集活動を開始したとき、装置はその知識を何もないところからブートストラップしなければならないために、最初の位置決定までの時間（ＴＴＦＦ）が極めて長くなる可能性があるというマイナス面を有する。将来、何らかのハードウェアが「tell me when I move（more than X meters）（私が（Ｘメートルを超えて）移動するときに知らせてください）」通知インタフェースを支援するのであれば、ＴＴＦＮは著しく短縮されることが可能であろう。これは、その装置からみて、定時にユーザが（Ｘメートルを超えて）かなり稀にしか移動しないという仮定に基づいている。ネットワーク利用の位置決定技術の場合、これにより自律アプリケーションのためのバッテリ消耗を大幅に減少させることができるであろう。
【００４１】
６．アーキテクチャ−コンポーネントレベルでの考察
アーキテクチャを更に良く理解するために、提供できる能力（responsibilities）の範囲に基づいてコンポーネントの考察を提示する。
【００４２】
示唆されるＡＰＩ及びSymbian位置認識／ＬＢＳの背後にある考え方は、
「make it easy for most and possible for the others（大多数のために容易にし、その他のために可能にする）」である。
【００４３】
従って、様々に異なって提供されるＡＰＩを明確に区別し、プラグインフレームワークからプラグインを分離させている。全体的な構造は添付の図１に示されている。以下に、主なコンポーネントを説明する。
【００４４】
６．１  ロケーションＡＰＩ
提供できる能力（Responsibilities）：
コンテキストサーバにより提供されるロケーションプリミティブを、大半のクライアントが使用できるようにするための明確で単純なインタフェースを提示する。このようなＡＰＩは、プラットフォームのようなアプリケーション、アプリケーションエンジン及びアプリケーションプロトコルの上部レイヤにロケーションプリミティブ（Location primitives）を提供する。
【００４５】
クライアントにより要求される様々なＱｏＳパラメータに基づいてロケーションを獲得するためにサービスを提供し、且つそのデータを単純で一貫したフォーマット（最もありそうなのはＷＧＳ−８４であり、おそらくはCell-IDストリング）で提示する。
【００４６】
クライアント：
アプリケーション及びアプリケーションフレームワーク
コラボレーション：
コンテキストサーバと
６．２  アドバンスドロケーションクライアントＡＰＩ
提供できる能力：
クライアントがコンテキストサーバから可変数の属性を要求し、それにより、特定の位置決定技術が提供しなければならないような、どのような能力をも利用できるようにするための完全で包括的なインタフェースを提示する。
【００４７】
また、双方向のデータ転送を可能にする。
【００４８】
クライアント：
アドバンスド及び／又は技術従属アプリケーション及びアプリケーションフレームワーク
コラボレーション：
コンテキストサーバと
６．３  位置認識サーバ
提供できる能力：
位置収集資源／技術の資源共有をカプセル化し且つ調停する。サーバは、発呼者のＱＯＳ要求に基づいて、クライアントの呼び出しを正しい技術プラグインへ経路指定する責務を負うと共に、プラットフォームの機密保護モデルに基づいてインタラクションを規制する。
【００４９】
位置収集技術プラグインをホスティングし、それらをインタフェースするために必要とされるフレームワークを提供する。
【００５０】
クライアントからの呼び出しの度にあらゆるプロセスの能力マスクを検査するように、トランザクションごとの規制を効率良く強制する。
【００５１】
クライアント：
ロケーションクライアント
コラボレーション：
位置収集技術プラグインと。
【００５２】
カーネルの発行インタフェース及び引用インタフェース
ファイルサーバ、ＤＢＭＳサーバ
ESock及び技術プラグインが必要とすると思われる全ての資源とサーバ。
【００５３】
６．４  プラグインフレームワーク
提供できる能力：
プラグインの中における再利用を可能にし、容易にすると共に、プラグイン開発を容易にする。
【００５４】
クライアント：
プラグイン及びコンテキストサーバ
コラボレーション：
ベースコンポーネント
６．５  プラグインメッセージ通過フレームワーク
提供できる能力：
緩やかな結合（例えば、ＧＰＳを使用するＡＧＰＳ）によって、プラグイン機能の再利用を行うことができるように、製品が望むのであれば全てのイベントをロギングするために聴取／フックインタフェースに対して、又は１つのプラグインが他の技術を組み合わせることにより、ロケーションデータを提供できるようなフュージョンシナリオに対して、様々に異なる位置収集プラグインがメッセージを遮断すること及び交換することを可能にする。
【００５５】
クライアント：
プラグイン及びロケーションサーバ
コラボレーション：
ロケーションサーバ
ベースコンポーネント
他のプラグイン
６．６  位置品質サービス
提供できる能力：
ロケーションクライアントＡＰＩを介してクライアントにより提供されるＱｏＰパラメータを満足させる位置決め技術を選択する。特定の位置収集技術プラグインを指定せずに、クライアントがロケーションフィックスを獲得することを可能にする。基本ＱｏＰセットは水平方向正確さ、垂直方向正確さ、位置決定までの時間、費用、電力消費を含むものとする。
【００５６】
クライアント：
プラグイン及びロケーションクライアントＡＰＩ
コラボレーション：
ロケーションサーバ
位置収集技術プラグイン
６．７  位置収集技術プラグイン
提供できる能力：
位置収集技術及びロケーションサーバとインタフェースすること。各プラグインは、特定の技術及びハードウェアとインタフェースするために必要とされる通信メカニズム及びプロトコルを提供する責務を負う。
【００５７】
また、プラグインは静的な技術特定能力、並びにサーバにおけるロケーションＱｏＳ決定実行に必要なサーバに対するランタイム能力（例えば、ＧＰＳ信号なしなど）を提供することに関連している。
【００５８】
プラグインのコストオプションは、オペレータ、時間、加入及びおそらくは位置決定（ローミングなど）にさえも従って変化すると考えられるため、プラグイン自体ではなく、オペレータ／ユーザにより提供される。
【００５９】
クライアント：
ロケーションサーバ及び他のプラグインで間接的
コラボレーション：
フレームワークを介してコンテキストサーバ他のプラグイン
ETel（ＳＭＳ、ＧＳＭ／ＧＰＲＳ、ＵＭＴＳ）
Ｃ３２サーバ、ＵＡＲＴ／いくつかの直列又はバス抽象化ドライバなど
６．８  アプリケーションフレームワーク
提供できる能力：
マップデータの変換
ＤＢＭＳ（例えば、Landmarks DB、残像、ログビューイング）とのインタフェース
設定及びサービスフィルタリングに関連するプライバシー
クライアント：
アプリケーション及び他のフレームワーク
コラボレーション：
ロケーションサーバアプリケーションエンジンとＧＵＩの間
７．クライアントＡＰＩ推奨
位置収集技術モジュール性アーキテクチャ
ロケーションサーバの基礎を成す内部アーキテクチャにおいて、そのビジョンは、技術特定サーバプラグインが、位置収集ハードウェアに対してハードウェアプロクシとして動作できるようにすることである。
【００６０】
それらの理由により、また、そのようなハードウェアの変動する過剰状態は、実施権者及びユーザにより使用されると期待されるため、サーバとそれらのプラグインとの間のインタフェースは「ロードタイム」能力の発見を可能にするであろう。実際には、プラグインはそれが必要とするだけの数の発行インタフェースを提示する。
【００６１】
これは、単純な能力発見プロトコル及び多態性工場管理プラグインdllを利用することにより実現される。
【００６２】
このスキーマを使用すると、更に、アプリケーション及び第三者がサーバ又はプラグインインタフェースを拡張する必要なく、特定のハードウェア能力を利用できるようになる。
【００６３】
少なくとも、技術プラグインは、
・ＮＭＥＡ０１８３ｖ２．０又はその何らかのサブセット
・電力管理
・Cell-ID
・基本Lon、Lat、Alt
・基本Anchor、ウェイポイント動作
・ＱｏＳ能力広告
などのインタフェースを露出させるであろうと考える。
【００６４】
技術プラグインモジュールの内部では、開発担当者はハードウェアと通信するために任意の数の方法を選択して良い。例えば、装置の潜在能力の全てを利用するために、（装置と通信するために）独占的な特定装置向けプロトコルを使用することを選択する開発担当者がいても良く、或いは時間市場上の理由により、より単純な手段（ＧＰＳ受信器用のＮＭＥＡなど）を使用すると決定する開発担当者がいても良い。いずれの場合にも、公開されるインタフェースは、それらのモジュールの後の改訂に際して変化する可能性がある内面的本質からは絶縁される。
【００６５】
第三者が新型ＧＰＳ装置の全ての潜在能力を利用する場合、受信器の独占的プロトコルを使用して通信し、ＮＭＥＡインタフェースを公開する場合には、必要に応じて生データをＮＭＥＡ文に翻訳するであろう。
【００６６】
同時に、全てのモジュールは、その静的能力及びランタイム能力をサーバ（それらがＤＢに格納されることを妨げない）と共に登録するために「ロケーションＱｏＳ能力」インタフェースを使用すると期待される。この登録により、ロケーションサーバは、クライアント要求を特定のＱｏＳ要件によって満足させるために、技術プラグインを動的に選択することができる。
【００６７】
７．プラグイン設定
インストールされたロケーションサーバプラグインモジュールは、何らかの設定が永久記憶装置に格納され、そこから読み出されることを要求する構成可能性レベルを必要とする。それらの設定の構成は、コントロールアプレット（control applets）によってユーザに対して公開される。
【００６８】
それらの設定に対する機密の、ケージングされたアクセスを実現するために、設定は（Ｐ＆Ｓメカニズムが選択されない限り）、ＤＢＭＳサーバによりホスティングされるデータベースに格納され、構造化される確率が最も高い。
【００６９】
プラグインに対するフレームワークは、ロケーションサーバを介してＤＢＭＳサーバにあるそれらの設定をアクセスするために提供される。
【図面の簡単な説明】
【００７０】
【図１】本発明を実現することができる無線情報装置のアーキテクチャを示す。
【図１】
2005528049.tif 000002
【国際調査報告】
2005528049.tif 000003
2005528049.tif 000004
2005528049.tif 000005