JP2004303248A - ロケーション・アウェアネスのアーキテクチャとシステム - Google Patents

Abstract

【課題】 位置サービスと方法は、色々なタイプの位置アウェアネスプロバイダがこのサービスを操作可能にすることで拡張可能な位置アウェアコンピューティングデバイスを実現する。
【解決手段】 方法は、位置コンテクスト要求の受信、１つまたは複数の位置検出デバイスから現在の位置に関連するデータの取得、階層型プロセスおよびメトリック・プロセスの一方又は双方の適用により現在の位置に関係する不整合に対する取得済みデータの調整、アプリケーションからアクセス可能な位置オブジェクトの生成、の各機能を備える。サービスは、位置データを送り届けるように構成された位置管理構成要素、位置データから生成された位置レポートを受信し、位置レポート間のコンフリクトを調整し、位置オブジェクトを生成するように構成したｆｕｓｅｒエンジン、および該エンジンからアプリケーションに位置オブジェクトを送る、位置管理構成要素に結合した位置ＡＰＩを備える。
【選択図】 図４

Description

本発明は、一般的には、コンピュータ・システムに関するものであり、具体的には、コンピュータ・システムおよびコンピュータ・デバイスのロケーション・アウェアネス（location awareness）に関するものである。

インターネットが出現し、コンピュータ・ユーザーが利用できる対話型アプリケーションが増えるにつれ、ユビキタス・コンピューティング（ubiquitous computing）に対する要求がますます高まってきている。このようなコンテクストで、ユビキタス・コンピューティングとは、コンピュータがユーザーの日々のタスクに影響を及ぼすことができるということを意味する。コンピュータが「コンピュータ（計算機）」と呼ばれるのは、「計算する」つまり数学に関するタスクを実行することができるからである。コンピュータは、もはや、単なるコンピューティング・マシンつまり計算機とはみなされず、パーソナル・デジタル・アシスタント（ＰＤＡ）およびスケジュール管理（ＰＩＭ）、高機能携帯電話などの形で社会組織にとけ込んでいるパーソナル・コンパニオン（personal companions）なのである。

今やコンピュータは、πを小数点以下２０桁まで計算するのにオフィスほどの広さを必要としなくなったが、それどころか、同じ計算能力がありながら手のひらに収まるようになった。より新しいコンピューティング・ツールのパーソナル・コンパニオンのペルソナ（personal companion persona）をよく認識しているソフトウェア開発者は、コンピュータの計算機能に関する側面をユーザーからほぼ見えなくした使い勝手のよいアプリケーションを作成する。このような技術を採用することで、ユーザー・インターフェースは、かつて必要であった従来技術のコンピュータ可読パンチ・カードとは際だって対照的に、人間型のインターフェースに極めてよく似たものとなっている。コンピューティングの遍在するという（ユビキタスな）性質に影響を及ぼす、成長段階にある他の技術として、無線技術がある。無線通信および有線通信ネットワークの利用が増え、新しいタイプの無線ネットワークは、コンピュータ側がコンピュータの通信機能を有効活用する需要を生じさせた。無線とは、もはや、以前にそうであったような、自動車内にハード配線で組み込まなければならない携帯電話を意味していない。近年のリチウム・イオン電池およびその他の小型であるが強力な電池を採用することで、携帯電話、ＰＩＭ、ＰＤＡ、およびノートブック・コンピュータを充電せずに一度に何時間も動作させることができる。コンピューティング・デバイスは長時間動作するので、ユーザーはデバイスを使用しながら充電を心配せずにあちらこちらに移動することができる。しかし、ユーザーによる長時間運用が現実になると、以前には必要であると思われなかった、あるいは可能であるとすら考えられなかった新しいコンピューティング製品の開発の好機が巡ってきた。新しいコンピューティング製品の一種は、ロケーション・アウェアネス製品タイプと呼ばれる。

現在のロケーション・アウェアネス・デバイスは断片化されており、ひとまとまりとして動作せず、拡張性も統一性もない。例えば、グローバル・ポジショニング・システム、ホーム・ネットワーキング・システム、ローカル・エリア・ネットワーク（ＬＡＮ）、およびコンピューティング・システムに接続されている無線電話はすべて、ロケーション・データをコンピュータ・システムに供給することができる。これらのシステムに、ロケーション・データの連携利用を可能にするような公約数的なものはない。それぞれのデバイスはロケーション・データをさまざまな形式で出力する。したがって、必要なものは、ロケーション・アウェアネス製品間の連携を可能にし、ユーザーによるコンピュータ・システム体験を向上させるロケーション・アウェアネス・システムである。

そこで、このロケーション・サービス（location service）は、情報のプロバイダとその情報を提供するために使用される技術に捕らわれないロケーション情報を提供する拡張性のある方法を提供する。この方法は、コンピューティング・デバイスのロケーション・コンテクストの要求を受け取ること、１つまたは複数のロケーション検出デバイス（location detection devices）から現在のロケーションに関連するデータを取得すること、現在のロケーションに関係する不整合性に対して、取得済みデータを調整する（reconciling）こと、アプリケーションにアクセス可能なロケーション・オブジェクトを生成することに向けられる。このサービスは、複数の方法、例えば、階層型プロセスおよびメトリック型プロセス（metric process）のいずれかまたは両方を適用することにより取得済みデータを調整する。

この方法を実施するために、該当するサービスは、ロケーション・データの経路を選択するように構成されているロケーション管理コンポーネント（location management component）と、例えば、データのプロバイダを介して、またデータに関するコンフリクトを解決（resolve）するように構成されているソフトウェアを介して、ロケーション・データから生成された１つまたは複数のロケーション・レポートを受信し、ロケーション・レポート間のコンフリクトを調整し、ロケーション・オブジェクトを生成する、ロケーション管理コンポーネントに結合されているｆｕｓｅｒエンジンと、このｆｕｓｅｒエンジンからアプリケーションにロケーション・オブジェクトを送信するためにロケーション管理コンポーネントに結合されている１つまたは複数のロケーション・アプリケーション・プログラミング・インターフェース（ＡＰＩ）と、を備える。ロケーション・オブジェクトは、サービスが動作しているコンピュータの利用可能な最新のロケーション・コンテクストをアプリケーションに動的に供給する。

他の実施形態は、サービスのセキュリティおよびプライバシー面の課題を対象とする。例えば、ユーザー設定またはデフォルト設定により、取得されるデータについてのプロバイダの信頼性を決定することができる。電子署名を用意しているプロバイダ、または知られている発信元からのプロバイダ、またはユーザーが信頼しているプロバイダは、ロケーション・データについて信頼性の高いプロバイダとして設定できる。さらに、独立のセキュリティおよびプライバシーのフレームワークが、サード・パーティのコードがケーション・サービスのセキュリティを傷つけることのないように、また適切なプライバシー・ポリシーが機能していない場合にアプリケーションがサービスにアクセスできないように、構成される。

本発明の他の特徴および利点は、添付図を参照して進められている説明目的の実施形態の以下の詳細な説明から明白であろう。

請求項で本発明の特徴を詳細に述べているが、本発明は、その目的および利点とともに、添付図面に関する以下の詳細な説明から最もよく理解できると思われる。

図面では、類似の参照番号は類似の要素を指しており、本発明は適当なコンピューティング環境に実装されているものとして説明されている。必要とされているわけではないが、本発明を、パーソナル・コンピュータによって実行されるプログラム・モジュールなどのコンピュータ実行可能命令の一般的コンテクストで、説明する。一般に、プログラム・モジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。さらに、当業者には、本発明が、携帯型デバイス、マルチ・プロセッサ・システム、マイクロ・プロセッサ・ベースのまたはプログラム可能な家電製品、ネットワークＰＣ、ミニ・コンピュータ、メインフレーム・コンピュータなど、他のコンピュータ・システム構成でも実施できることは明白であろう。また、本発明は、通信ネットワークを通じてリンクされているリモート処理デバイスによりタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラム・モジュールは、ローカルとおよびリモートの両方のメモリ記憶デバイス内に配置することができる。

図１は、本発明を実装するのに適しているコンピューティング・システム環境１００の一実施例の図である。コンピューティング・システム環境１００は、適当なコンピューティング環境の一例にすぎず、本発明の用途または機能性の範囲に関する制限を示唆する意図はない。コンピューティング環境１００は、オペレーティング環境例１００に示されている１つのコンポーネントまたはその組合せに関係する依存関係または要求条件を備えているものと解釈すべきでない。

本発明は、他の数多くの汎用または専用コンピューティング・システム環境または構成の下で動作する。本発明とともに使用するのに適していると思われるよく知られているコンピューティング・システム、環境、および／または構成の例として、パーソナル・コンピュータ、サーバ・コンピュータ、携帯型またはラップトップ・デバイス、タブレット・デバイス、マルチ・プロセッサ・システム、マイクロ・プロセッサ・ベースのシステム、セットトップボックス、プログラム可能な家電製品、ネットワークＰＣ、ミニ・コンピュータ、メインフレーム・コンピュータ、上記システムまたはデバイスを含む分散コンピューティング環境などがあるが、これらに限定されるものではない。

本発明は、コンピュータによって実行される、プログラム・モジュールなどのコンピュータ実行可能命令の一般的コンテクストに関して説明することができる。一般に、プログラム・モジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。また、本発明は、通信ネットワークを通じてリンクされているリモート処理デバイスによりタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラム・モジュールをメモリ記憶デバイスなどのローカルおよび／またはリモート・コンピュータ記憶媒体に配置できる。

図１では、本発明を実装するシステム例は、コンピュータ１１０の形態をとる汎用コンピューティング・デバイスを備える。コンピュータ１１０のコンポーネントはこれらに限定されるものではないが、処理装置１２０、システム・メモリ１３０、およびシステム・メモリを含むさまざまなシステム・コンポーネントを処理装置１２０に結合するシステム・バス１２１を備えることができる。システム・バス１２１には、さまざまなバス・アーキテクチャを使用するメモリ・バスまたはメモリ・コントローラ、周辺機器バス、およびローカル・バスを含む数タイプのバス構造がある。例えば、このようなアーキテクチャとしては、Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ ＩＳＡ（ＥＩＳＡ）、Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカル・バス、およびＭｅｚｚａｎｉｎｅバスとも呼ばれるＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスがあるが、それらに限定されない。

コンピュータ１１０は通常、さまざまなコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０によってアクセスできる媒体であればどのような媒体でも使用でき、揮発性および不揮発性媒体、取り外し可能および取り外し不可能媒体を含む。例えば、コンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を含むことができるが、それらに限定されない。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造体、プログラム・モジュール、またはその他のデータなどの情報を格納する方法または技術で実装される揮発性および不揮発性、取り外し可能および取り外し不可能媒体を含む。コンピュータ記憶媒体としては、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）またはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶デバイス、または目的の情報を格納するために使用することができコンピュータ１１０によりアクセスできるその他の媒体があるが、それらに限定されない。通信媒体は、通常、コンピュータ可読命令、データ構造体、プログラム・モジュール、または搬送波またはその他のトランスポート・メカニズムなどの変調データ信号によるその他のデータを実現し、さらに情報配信媒体を含む。「変調データ信号」という用語は、信号内の情報を符号化する方法でその特性のうち１つまたは複数が設定または変更された信号を意味する。例えば、通信媒体としては、有線ネットワークまたは直接配線接続などの有線媒体、および、音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体があるが、それらに限定されない。上記のいずれの組合せもコンピュータ可読媒体の範囲に収まらなければならない。

システム・メモリ１３０は、読み取り専用メモリ（ＲＯＭ）１３１およびランダム・アクセス・メモリ（ＲＡＭ）１３２などの揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体を備える。起動時などにコンピュータ１１０内の要素間の情報伝送を助ける基本ルーチンを含む基本入出力システム１３３（ＢＩＯＳ）は通常、ＲＯＭ １３１に格納される。通常、ＲＡＭ １３２には、処理装置１２０に直接アクセス可能な、かつ／または処理装置１２０により現在操作されているデータおよび／またはプログラム・モジュールを格納する。例えば、図１は、オペレーティング・システム１３４、アプリケーション・プログラム１３５、その他のプログラム・モジュール１３６、およびプログラム・データ１３７を示しているが、それらに限定されない。

コンピュータ１１０はさらに、その他の取り外し可能／取り外し不可能な揮発性／不揮発性コンピュータ記憶媒体を備えることもできる。例えば（単なる例であるが）、図１は、取り外し不可能な不揮発性磁気媒体の読み出しまたは書き込みを行うハードディスク・ドライブ１４１、取り外し可能な不揮発性磁気ディスク１５２の読み出しまたは書き込みを行う磁気ディスク・ドライブ１５１、およびＣＤ−ＲＯＭまたはその他の光媒体などの取り外し可能な不揮発性光ディスク１５６の読み出しまたは書き込みを行う光ディスク・ドライブ１５５を示している。オペレーティング環境例で使用できる他の取り外し可能／取り外し不可能な揮発性／不揮発性コンピュータ記憶媒体としては、磁気テープカセット、フラッシュ・メモリ・カード、デジタル多目的ディスク、デジタル・ビデオ・テープ、ソリッド・ステートＲＡＭ、ソリッド・ステートＲＯＭなどがあるが、それらに限定されない。ハードディスク・ドライブ１４１は、通常、インターフェース１４０などの取り外し不可能なメモリ・インターフェースを介してシステム・バス１２１に接続され、磁気ディスク・ドライブ１５１および光ディスク・ドライブ１５５は、通常、インターフェース１５０などの取り外し可能なメモリ・インターフェースによりシステム・バス１２１に接続される。

図１に示されている上記のドライブおよび関連コンピュータ記憶媒体は、コンピュータ１１０用のコンピュータ読み取り可能命令、データ構造体、プログラム・モジュール、およびその他のデータを格納する機能を備える。例えば、図１では、ハードディスク・ドライブ１４１は、オペレーティング・システム１４４、アプリケーション・プログラム１４５、その他のプログラム・モジュール１４６、およびプログラム・データ１４７を格納するものとして示されている。これらのコンポーネントは、オペレーティング・システム１３４、アプリケーション・プログラム１３５、その他のプログラム・モジュール１３６、およびプログラム・データ１３７と同じである場合もあれば異なる場合もあることに注意されたい。オペレーティング・システム１４４、アプリケーション・プログラム１４５、その他のプログラム・モジュール１４６、およびプログラム・データ１４７に対しては、ここで、異なる番号を割り当てて、最低でも、それが異なるコピーであることを示している。ユーザーは、タブレット、電子デジタイザ１６４、マイク１６３、キー・ボード１６２、および一般にマウス、トラック・ボール、タッチ・パッドなどと呼ばれるポインティング・デバイス１６１などの入力デバイスを介してコンピュータ１１０にコマンドおよび情報を入力できる。他の入力デバイス（図に示されていない）としては、ジョイスティック、ゲーム・パッド、衛星放送受信アンテナ、スキャナなどがある。これらの入力デバイスやその他の入力デバイスは、システム・バスに結合されているユーザー入力インターフェース１６０を介して処理装置１２０に接続されることが多いが、パラレル・ポート、ゲームポート、またはユニバーサル・シリアル・バス（ＵＳＢ）などの他のインターフェースおよびバス構造により接続することもできる。モニタ１９１またはその他のタイプの表示デバイスも、ビデオ・インターフェース１９０などのインターフェースを介してシステム・バス１２１に接続される。モニタ１９１はさらに、タッチ・スクリーン・パネルなどと一体化することもできる。モニタおよび／またはタッチ・スクリーン・パネルは、タブレット型パーソナル・コンピュータなどの、コンピューティング・デバイス１１０が組み込まれているハウジングに物理的に結合できることに注意されたい。さらに、コンピューティング・デバイス１１０などのコンピュータは、スピーカ１９７およびプリンタ１９６などの他の周辺出力デバイスも備えることができ、これらは出力周辺インターフェース１９４などを介して接続することができる。

コンピュータ１１０は、リモート・コンピュータ１８０などの１つまたは複数のリモート・コンピュータへの論理接続を使用してネットワーク環境で動作することも可能である。リモート・コンピュータ１８０は、パーソナル・コンピュータ、サーバ、ルーター、ネットワークＰＣ、ピア・デバイス、またはその他の共通ネットワーク・ノードでもよく、通常は、コンピュータ１１０に関係する上述の要素の多くまたはすべてを含むが、メモリ記憶デバイス１８１だけを図１に示してある。図１に示されている論理接続は、ローカル・エリア・ネットワーク（ＬＡＮ）１７１とワイド・エリア・ネットワーク（ＷＡＮ）１７３を含むが、他のネットワークを含むこともできる。このようなネットワーキング環境は、オフィス、事業全体のコンピューター・ネットワーク、イントラネット、およびインターネットでは一般的なものである。例えば、本発明では、コンピュータ・システム１１０は、データがそこから移送されるソース・マシンを含み、リモート・コンピュータ１８０は、宛先マシンを含むことができる。しかし、ソース・マシンおよび宛先マシンは、ネットワークまたは他の手段で接続されている必要はないが、その代わり、データがソース・プラットフォームによる書き込みおよび宛先プラットフォームによる読み出しを行うことができる何らかの媒体を介して移送されることが可能であることに注意されたい。

ＬＡＮネットワーキング環境で使用する場合、コンピュータ１１０はネットワーク・インターフェースまたはアダプタ１７０を介してＬＡＮ １７１に接続される。ＷＡＮネットワーキング環境で使用する場合、コンピュータ１１０は通常、モデム１７２またはインターネットなどのＷＡＮ １７３上で通信を確立するための他の手段を備える。モデム１７２は、内蔵でも外付けでもよいが、ユーザー入力インターフェース１６０またはその他の適切なメカニズムを介してシステム・バス１２１に接続できる。ネットワーク環境では、コンピュータ１１０またはその一部に関して述べたプログラム・モジュールは、リモート・メモリ記憶デバイスに格納できる。例えば（限定しない例として）、図１には、リモート・アプリケーション・プログラム１８５がメモリ・デバイス１８１に置かれているように示されている。図に示されているネットワーク接続は例であり、コンピュータ間に通信リンクを確立するのに別の手段を使用できることは理解されるであろう。

以下の説明では、特に断りのない限り、１つまたは複数のコンピュータにより実行される活動（acts）および動作の記号的表現を参照しながら本発明を説明する。したがって、そのような活動および動作（operation）は、ときには「コンピュータに実行される」と呼ばれることもあるが、構造化された形式でデータを表現する電気的信号の、コンピュータの処理装置による操作（manipulation）を含むことは理解されるであろう。この操作は、データを変換したり、またはコンピュータのメモリシステム内の複数のロケーションにデータを保持したり、当業者であればよく理解している方法でコンピュータの動作を再構成したり、あるいは他の形に変更したりする。データが保持されているデータ構造は、データの形式により定められた特定の特性を備えるメモリの物理的な場所に存在する。しかし、本発明は前述のコンテクストの中で説明されているが、制限する意図はなく、当業者であれば以下で説明する各種の活動および動作がハードウェアに実装できることは周知のことであろう。

図２のブロック図の例で、ロケーション・アウェアネス・サービス２１０のアーキテクチャの概要を説明している。図に示されているように、ロケーション・サービス２１０はユーザー・モード・サービス２１２とすることができ、コンピュータ１１０または携帯型コンピューティング・デバイスなどのコンピュータ上にインストールすることができる。ロケーション・サービス２１０は、複数のアプリケーション２２０（１〜３）から、またデバイス／コンピュータ２１４の外部からデータを受信する。ロケーション・サービス２１０は、デバイス内で、ドライバ２２２（１〜２）などのカーネル・モード２１５コンポーネントおよびＷｉｎｄｏｗｓ（登録商標）ファイル・システム・コンポーネント２２４に結合される。ドライバ２２２（１〜２）およびＷｉｎｄｏｗｓ（登録商標）ファイル・システム・コンポーネント２２４は、ハードウェア２１６に結合されているものとして図に示されている。各デバイス・ドライバ２２２（１〜２）は、それぞれのハードウェア・デバイス２２６（１〜２）に結合されているものとして図に示されている。Ｗｉｎｄｏｗｓ（登録商標）ファイル・システム・コンポーネント２２４は、メモリ・デバイス２３０に結合されているものとして図に示されており、これは、Ｗｉｎｄｏｗｓ（登録商標）ファイル・システム・データを保持するためのデータベースとすることもできる。ロケーション・サービス２１０はさらに、ＭａｐＰｏｉｎｔ（登録商標）アプリケーションまたはロケーション情報のクエリを実行するように構成され、本明細書の実施形態、つまりロケーション・データを供給するデバイス２４０と整合性がとれている他のアプリケーションに結合することもできる。また、ロケーション・サービス２１０は、ライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）２５０を介してＡｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ ２６０に結合される。ロケーション・サービス２１０は、さらに、外部のデバイス／クライアント２８０に結合することもでき、さらにこれは、通信チャネル２１４を介してプレゼンス・サーバ（presence server）２７０に結合することも可能である。より具体的には、ロケーション・サービス２１０は、例えば、リアルタイム通信（ＲＴＣ）クライアントにより取り出すことができるロケーション情報を供給することができる。その後、ＲＴＣクライアントは、情報を存在サーバ２７０に送信する。

次に図３を参照すると、ブロック図にロケーション・サービス２１０が詳細に示されている。図からわかるように、ロケーション・サービス２１０は、１つまたは複数のロケーション・アプリケーション・プログラミング・インターフェース（ＡＰＩ）３５０、ｆｕｓｅｒエンジン３４０、およびロケーション管理コンポーネント３３０を含む。ロケーション管理コンポーネント３３０は、プロバイダ・プラグイン３１０”およびリゾルバ３２０と情報をやり取りする。一実施形態では、ロケーション管理コンポーネント３３０は、ユーザー・エージェント３３２、キャッシュ３３４、マスター・リゾルバ３３６、およびプラグイン・マネージャ３３８を含む。図３はさらに、プロバイダ３１０’を示しており、これは、センサ特有のデータなど、少なくとも何らかの解釈を必要とする感知されたデータのプロバイダとすることができる。例えば、グローバル・ポジショニング・プロバイダは、緯度と経度を提供することができる。一実施形態では、プロバイダ３１０’は感知されたデータをプロバイダ・プラグイン３１０”にデバイスからのデバイス特有のロケーション情報またはセンサ特有のデータとして送信する。プロバイダ・プラグイン３１０”は、データを正規化し、データを標準形式に変換し、そのデータをロケーション管理コンポーネント３３０に送信する。他の実施形態では、プロバイダ３１０’は、データをプロバイダ・プラグイン３１０”に送信する前にデータを変換することができる。プロバイダ３１０’の能力は、設計上の要件および制限事項に左右される。例えば、ロケーション管理コンポーネント３３０は、プロバイダ３１０’または他の発信元を介して生のデバイス情報を１つまたは複数のデバイスから取得することができる。一実施形態では、ロケーション管理コンポーネント３３０はデータを正規化し、そのデータをロケーション・レポート（location reports）に変換する。

一実施形態では、ロケーション管理コンポーネント３３０は、ロケーション・サービス２１０内に構成される。プロバイダ・プラグイン３１０”は、データを正規化するが、ロケーション管理システムの一部であるプラグイン・マネージャ３３８はさらに、そのデータを受け付けてマスター・リゾルバ３３６に渡す前にデータを正規化する。マスター・リゾルバ３３６、ｆｕｓｅｒエンジン３４０、プラグイン・マネージャ３３８の各コンポーネントは、情報を受け入れる用意ができていることを示す。一実施形態では、これ以降、データを取り出すアプリケーションおよびコンポーネントは、コンポーネント３３６、３３８、および３４０に取り出す用意のできているデータがある場合のみ取り出しを実行する。

リゾルバ３２０は、感知され変換されたデータ、場合によっては、デバイス特有のロケーション情報などの生のロケーション・データを受け取り、そのデータを解釈する。リゾルバ３２０は、ロケーション・サービス２１０へのプラグインとして実装することができ、デバイス特有のロケーション情報トランスレータ（information translators）およびデータ・ソースを備えることができる。リゾルバ３２０では、既存のデータから新しいデータを推測するために用意されているデータ・ソースを使用してデバイス特有のロケーション情報をリッチ・ロケーション情報（rich location information）に変換する機能を持つ。一実施形態では、リゾルバ３２０は、１つまたは複数のデバイスから受信したデータの少なくとも一部を変換することができる。各リゾルバ３２０は、プロバイダ３１０から少なくとも１つのタイプの生データまたは部分的に復号化されたデータを解釈することができる可能性もある。例えば、リゾルバ３２０を８０２．１１タイプのデータのみを解釈する機能専用とすることもできる。すると、リゾルバは８０２．１１タイプのデータのみを解釈するものとしてロケーション管理３３０に登録し、そのタイプのデータのみを受け取ることになる。さらに、他のリゾルバの情報を変換するように各リゾルバ３２０を構成することができるが、その場合、リゾルバは生データまたは部分的に復号化されたデータを変換することができないことがある。また、図３はロケーション・サービス２１０からデータを受信するＷｉｎｄｏｗｓ（登録商標）ファイル・システム・コンポーネント３６０を示している。

ｆｕｓｅｒエンジン３４０は、現在のロケーション・オブジェクトを生成する。ロケーション・サービス２１０は、プロバイダ・プラグイン３１０”およびリゾルバ・プラグイン３２０を含む、１つまたは複数のプラグインを介して現在のロケーション・データを検査する。このコンテクストでは、プラグインを１つまたは複数の動的ロード可能ライブラリまたは動的リンク・ライブラリ（ＤＬＬ）またはソフトウェア、ファームウェア、またはシステム・コンポーネントの機能を拡張することができる他の動的ロード可能モジュールとして実装することができる。

システムの概要
図４を参照すると、ロケーション・システム２１０および周辺コンポーネントのブロック図は、一般的に、ロケーション・サービス２１０がアプリケーションにこだわらないフレームワークとして動作し、情報がそこから取得されるデバイスおよびデータ・ソースに関してもこだわらないことを示している。ロケーション・サービス２１０は、ｆｕｓｅｒエンジン３４０、キャッシュ３３４、ユーザー・エージェント３３２、プラグイン・マネージャ３３８、およびマスター・リゾルバ３３６を含むものとして示されている。ロケーション・サービス２１０はさらに、ＷｉｎＦＳ ＳＱＬサーバ４５０、ロケーション・プロバイダＡＰＩ ４０４、ロケーション・リゾルバＡＰＩ ４１４、ロケーション通知サービスＡＰＩ ４１６、ロケーション・ユーザーＡＰＩ ４１８、およびロケーション管理ＡＰＩ ４２０を含む。ＷｉｎＦＳ ＳＱＬサーバ４５０は、ロケーション・サービス２１０を通知サービス４６０に結合し、さらにユーザー通知ＡＰＩ ＬｏｃＵｓｒ ４１８およびロケーション通知ＡＰＩ ４１６に結合する。ＡＰＩ ４１６および４１８は、アプリケーション２２０と情報をやり取りすることができる。

ロケーション・ユーザーＡＰＩ ４１８は、ロケーション・サービス２１０を実行しているコンピュータの現在のロケーションについてアプリケーションがクエリを実行することを可能にする。ロケーション・リゾルバＡＰＩ ４１４は、サービスに登録するためにプラグインにより実装する必要のある機能を指定する。図に示されているように、ロケーション・ユーザーＡＰＩ ４１８は、ＷｉｎＦＳサーバ４５０からデータを受け取り、そのデータを１つまたは複数のアプリケーション２２０（１〜ｎ）に渡す。ロケーション管理ＡＰＩ ４２０は、ｆｕｓｅｒエンジン３４０、ユーザー・エージェント３３２、キャッシュ３３４、プラグイン・マネージャ３３８、およびマスター・リゾルバ３３６などの複数のロケーションからデータを受け取り、１つまたは複数のアプリケーション２２０との間でデータをやり取りする。ロケーション管理ＡＰＩ ４２０は、サービスおよびコンポーネントのパラメータを構成することを可能にする。さらに、ロケーション管理ＡＰＩ ４２０は、プロバイダおよびリゾルバの追加、削除を行うこともできる。ロケーション通知ＡＰＩ ４１６は、通知サービス４６０からデータを受け取り、データをアプリケーション２２０に渡す。ロケーション通知ＡＰＩ ４１６は、サービスを実行しているコンピュータのロケーションが変更されたときにそのことを通知するようにアプリケーションが登録することを可能にする。一実施形態では、独立のＡＰＩである、アプリケーション登録ＡＰＩが、アプリケーションが通知の登録を行うことを可能にし、現在のロケーションを決定することができる。この実施形態では、アプリケーションはまず、ロケーション・データを取得するように登録しなければならない。登録された後、アプリケーションは所定の理由の結果としての通知を受け取ることを選択できる。ロケーション・リゾルバＡＰＩ ４１４は、プラグイン・マネージャ３３８およびマスター・リゾルバ３３６とデータを送受信し、そのデータをロケーション・リゾルバのユーザー／Ｗｉｎｄｏｗｓ（登録商標）データベース４０８（１）、ロケーション・リゾルバのＡｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ４０８（２）、およびロケーション・リゾルバのＭａｐＰｏｉｎｔ（登録商標）４０８（３）、さらに、ロケーション・データを利用できる他のロケーション・リゾルバに送信する。マスター・リゾルバ３３６は、ロケーション情報の解決を管理する役割を持つ。プラグイン・マネージャ３３８がマスター・リゾルバ３３６にデバイス特有のロケーション情報を渡すと、マスター・リゾルバ３３６は、空いておりかつ情報の解決を行えるリゾルバにデータを届ける。

特に、図４を参照すると、ロケーション・サービス２１０を通る流れは、プロバイダ４０２から例により説明することができる。プロバイダ、例えば８０２．１１プロバイダは走査データを取得する。プロバイダ４０２は、新しいアクセス・ポイントができたと判断すると、媒体アクセス制御（ＭＡＣ）アドレスおよび信号強度情報を８０２．１１レポートに組み込む。８０２．１１プロバイダは、情報が準備ができたことをプラグイン・マネージャ３３８に信号で知らせる。プラグイン・マネージャ３３８は、情報の集合をピックアップし、マスター・リゾルバ３３６に、解決すべき新しいロケーション・レポートがあることを信号で知らせる。

次に、マスター・リゾルバ３３６は、プラグイン・マネージャ３３８からロケーション・レポートを取り出す。次に、マスター・リゾルバ３３６は、ロケーション・レポートをユーザー・エージェント３３２に渡す。

ユーザー・エージェント３３２は、このロケーション・レポートについてキャッシュ３３４内をチェックする。キャッシュ３３４は、場合によっては、ミス（miss）を返すこともある。その場合、キャッシュ３３４はデータをキャッシュし、バックエンドをチェックする。キャッシュのバックエンドをチェックすることにより、ロケーション・レポートに基づいてユーザーのロケーションを決定することもできる。キャッシュでユーザーのロケーションが決まらない場合、ユーザー・エージェント３３２がミス（miss）を生成する。

ユーザー・エージェント３３２がミスを生成した後、マスター・リゾルバ３３６はロケーション・レポートを、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ（ＡＤ）リゾルバ４０８（２）などのリゾルバ４０８に渡す。ＡＤリゾルバ４０８（２）は、ロケーション・レポート内のＭＡＣアドレス情報を特定し、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙに接続し、アクセス・ポイントのロケーションを見つける。次に、ＡＤリゾルバ４０８（２）は、アクセス・ポイントのロケーションをロケーション・レポートとしてマスター・リゾルバ３３６に返す。次に、マスター・リゾルバ３３６は、ロケーション・レポートをユーザー・エージェント３３２に渡す。ユーザー・エージェント３３２は、ＡＤリゾルバ４０８（２）によって返されたロケーション・レポートと一致するのがあるかキャッシュ３３４をチェックする。キャッシュ３３２がミスを生成した場合、ユーザー・エージェント３３２はＡＤレポートをキャッシュする。次に、ユーザー・エージェント３３２は、ＷｉｎＦＳ ４５０をチェックし、ＡＤリゾルバ４０８（２）によって生成されたロケーション・レポートに関係する保存済みのロケーションを見つける。何も見つからない場合、ユーザー・エージェント３３２は、追加データのないことをマスター・リゾルバ３３６に通知する。次に、マスター・リゾルバ３３６は、取り出すデータがまだ残っていることをｆｕｓｅｒエンジン３４０に信号で伝える。ｆｕｓｅｒエンジン３４０は、８０２．１１ロケーション・レポートおよびＡＤロケーション・レポートを含む、２つのロケーション・レポートを取り出す。

次に、ｆｕｓｅｒエンジン３４０は、これらのレポートを融合し、融合されたレポート、および両方のロケーション・レポートを表すロケーション・オブジェクトを現在のロケーションとしてＷｉｎＦＳ ３５０に書き込む。

次に、ＷｉｎＦＳの上で実行されるように構成することができる、通知サービス４６０が通知を生成する。生成された通知は、ロケーション通知ＡＰＩを通り、通知のため登録されているアプリケーションに渡される。

ロケーション・リゾルバＡＰＩ ４１４は、ロケーション・サービス２１０とリゾルバとの間のインターフェースである。さらに、ロケーション・リゾルバＡＰＩ ４１４により、各リゾルバは、新しいロケーション情報がリゾルバにあることをロケーション・サービス２１０に通知することができる。ロケーション・リゾルバＡＰＩ ４１４により、リゾルバはこの情報をロケーション・サービス２１０に転送することができる。

ロケーション・プロバイダＡＰＩ ４０４は、８０２．１１プロバイダ、Ｂｌｕｅｔｏｏｔｈプロバイダ、グローバル・ポジショニング・システム・プロバイダ、およびロケーション・データの他のタイプのプロバイダを含むことができるプロバイダ４０２（１〜ｎ）などのロケーション・プロバイダとの間でデータをやり取りする。ロケーション・プロバイダＡＰＩ ４０４は、ロケーション・サービス２１０とプロバイダとの間のインターフェースである。ロケーション・プロバイダＡＰＩ ４０４により、各プロバイダは、新しいロケーション情報があることをサービスに通知することができ、この情報をサービスに転送する。

一実施形態では、ロケーション・プロバイダＡＰＩ ４０４およびロケーション・リゾルバＡＰＩ ４１４は両方とも、プラグイン・マネージャＡＰＩの一部である。プラグイン・マネージャＡＰＩはさらに、プラグイン・マネージャ３３８とプロバイダ・プラグイン４０２との間のインターフェースである、プラグイン・マネージャ・プラグインを含む。プラグイン・マネージャのプラグイン・インターフェースは、データをプロバイダインターフェースとリゾル・バインターフェースの両方に提供する。この実施形態によれば、プロバイダ４０２であるためには、ロケーション・プロバイダＡＰＩとプラグイン・マネージャのプラグインの両方を実装しなければならない。

ｆｕｓｅｒエンジン３４０は、マスター・リゾルバ３３６から得られたデータを融合する（fuse）機能を持つ。ｆｕｓｅｒエンジン３４０は、一般に、コンフリクトを解決し、ロケーション・プロバイダから受け取ったロケーション・アウェアネスの異なる解決（resolution）から受け取った「レポート」を統一する。ロケーションに関するデータは、マスター・リゾルバ３３６経由で到着し、このマスター・リゾルバ３３６は、データをフィルタ処理し、データをキャッシュ３３４に送り、その後ｆｕｓｅｒエンジン３４０に送る。

ユーザー・エージェント３３２は、キャッシュ３３４をチェックし、さらにキャッシュされているデータを使用して現在のロケーション・レポートを解決できるかどうかを判定する機能を持つ。ユーザー・エージェント３３２は、さらにＷｉｎＦＳ ４５０をチェックし、現在のロケーション・レポートにユーザーが保存したロケーションが示されているかどうかを調べる。

キャッシュ３３４は、解決ツリー（resolution trees）を格納する機能を持つ。解決ツリーにより、ロケーション・サービス２１０は解決サイクルの数を減らすことができる。

図４は、ロケーション・サービス２１０を使用することにより、現在のロケーションについてのクエリを実行する機能と、ユーザーのロケーションが変更されたときにそのことを通知する機能をアプリケーション２２０に付加することができるアーキテクチャの一実施形態を示している。図４は、さらに、ロケーションＡＰＩ ３５０が３層になっていることも示している。特に、これらのＡＰＩは、プロバイダ４０２からロケーション・サービス２１０、リゾルバ４０８からロケーション・サービス２１０、アプリケーション２２０からロケーション・サービス２１０への複数の層を実現している。

一実施形態では、リゾルバ・プラグイン４０８は、リゾルバ・プラグイン４０８が変換できる情報のタイプおよびその他の機能を登録するように、構成されている。ロケーション・サービス２１０では、変換可能な情報のタイプおよびその他の機能に関するデータを用いて、リゾルバ・プラグイン４０８を効率よく使用し、これを使用しない場合には別のところで実行され、処理が重複することになるプロセスを実行することができる。さらに、登録は、ｆｕｓｅｒエンジン３４０が知られているタイプとのデータ内のコンフリクトを効率よく解決し、ユーザー・ロケーションが変更されたときにアプリケーション２２０から通知できるようにするイベント・メカニズムを実現することができる。さらに、ロケーション・サービス２１０内の登録およびその他のプロセスを使用すると、ロケーション２１０に関連付けられているロケーション・オブジェクトのインスタンス化で、すべてのロケーション情報を、ロケーション・オブジェクトの拡張機能として、アプリケーション２２０に渡すことができる。ロケーション・オブジェクトは、一般的なタイプのロケーション情報コンポーネントとして構成することができ、これは異なるタイプまたは新しいタイプのロケーション情報をアプリケーションがコンポーネントに挿入することを可能にする。この一般的なタイプのロケーション情報コンポーネントは、例えば、基本ロケーション・レポートの拡張として構成することができる。

一実施形態では、ロケーション・サービス２１０は拡張可能であり、開発者は追加プラグインを作成することができる。図に示されているように、プラグイン４０２、４０８は、ＡＰＩ ４１４、４１６、４１８、４２０、４２２の層を介してロケーション・サービス２１０に結合することができ、これらのＡＰＩにより、ロケーション・サービス２１０はデバイスおよびデータ・ソースと新しいタイプのロケーション・データとの通信を調整することができる。さらに、各プラグイン４０２、４０８、およびロケーション・サービス２１０内のコンポーネントは、エラーを発生させることなく、１つまたは複数のプラグインまたはコンポーネントを無効にできるようにまたは取り外せるようにモジュール形式で構成することもできる。この実施形態では、ロケーション・サービス２１０は、無効にされた／取り外されたプラグイン、ｆｕｓｅｒエンジン３４０、または通知コンポーネントおよび他のコンポーネントがあっても、ロケーション・サービス２１０は取り外されたプラグインまたはコンポーネントを必要とするプロセスの一部をスキップするように動作する。例えば、ｆｕｓｅｒエンジン３４０が無効にされていた場合、当実施形態によれば、ロケーション・サービス２１０は、ロケーション・レポートの経路をプラグインからロケーション・ユーザーＡＰＩ ４１８への経路に設定することができる。

他の実施形態では、アプリケーション２２０のうちの１つを、ロケーション・サービス２１０に関連付けられているユーザー・インターフェースとして実装することも可能なユーザー制御アプリケーションとすることができる。ユーザー制御アプリケーションは、さらに、プラグイン４０８および４０２などのプラグインの追加／取り外しをユーザー側で行うためのＡＰＩと連携して動作するか、またはそれらのＡＰＩを備え、ｆｕｓｅｒエンジン３４０の機能を変更することができるプロバイダ・プラグイン４０２およびリゾルバ４９８の優先度を変更するように構成することができる。さらに、ユーザー制御アプリケーションは、マスター・リゾルバ３３６と１つまたは複数のリゾルバ４０８との間の反復回数を変更するように構成することができる。

図４と合わせて図５Ａと５Ｂを参照すると、それらの図ではロケーション・サービス２１０の内部動作が説明されている。ブロック５１０では、プロバイダは生デバイス・データを非同期に受信することができる。ブロック５２０では、各プロバイダは受信後受信したデータを正規化する。このような正規化により、少なくとも一部のデータは破棄される。ブロック５３０では、正規化されたデータを標準形式に変換し、ブロック５４０では、データをマスター・リゾルバ３３６に送信する。ブロック５４２では、マスター・リゾルバ３３６は、ロケーション・プロバイダＡＰＩ ４０４を介して１つまたは複数のプロバイダから標準化され正規化されたデータを受け取ることができる。ブロック５５０では、マスター・リゾルバ３３６はデータを１つまたは複数のリゾルバ４０８に分配することができる。リゾルバ４０８は、そのデータに作用し、ブロック５６０に示されているように、新しいデータをマスター・リゾルバ３３６に返す。ブロック５６１では、ｎがｎ＋１になるようにカウンタを増分する。次に、決定ブロック５６２は、「ｎ」が所定の限界に到達したかどうかを決定する。限界に達していなければ、このプロセスは次に、ライン５６４により示されているように、反復する。所定の反復回数に達したら、またはマスター・リゾルバ３３６によって受信されたメトリック（metric）またはキューに応じて、ブロック５７０に示されているように、データがｆｕｓｅｒエンジン３４０に受け渡される。

ブロック５７４では、ｆｕｓｅｒエンジン３４０は、マスター・リゾルバ３３６からデータを受信する。ブロック５８０では、ｆｕｓｅｒエンジン３４０がマスター・リゾルバ３３６から受信したデータを操作し、コンフリクトを解決する。ブロック５９０では、ｆｕｓｅｒエンジン３４０は、コンフリクトを解決した後、ロケーション・サービス２１０を実行するコンピュータの現在位置をカプセル化したロケーション・オブジェクトを作成する。決定ブロック５９１で、新しいロケーション・オブジェクトを作成する必要があるかどうかを決定する。必要であれば、ブロック５９２において、ｆｕｓｅｒ ３４０が新しいロケーション・オブジェクトを作成した場合、ｆｕｓｅｒ ３４０はロケーションをＷｉｎＦＳ ４５０に書き込む。ブロック５９３では、通知サービス４６０がｆｕｓｅｒエンジン３４０での正しいロケーションであると判断されるロケーションをチェックし、そのロケーションが通知サービス４６０によってアプリケーション２２０に関連付けられるロケーションと一致するかどうかを調べる。その後、通知サービス４６０は、ロケーション通知ＡＰＩ ４１６を介して該当するアプリケーション２２０に通知する。アプリケーション２２０は、ロケーション通知ＡＰＩ ４１６を介して、まずサービス２１０を使用するコンピュータの現在のロケーションのロケーション・サービス２１０の最良の推測を表すロケーションを求めるクエリを実行することにより、通知サービス４６０と情報をやり取りする。次に、アプリケーション２２０をＷｉｎＦＳ ４５０とともに実行される通知サービス４６０に登録し、ロケーション・サービス２１０を実行するコンピュータのロケーションが変更されたときにそのことをアプリケーション２２０に通知するようにする。アプリケーション２２０がロケーション・サービス２１０からロケーション・データを受信した場合、返されるデータにはプロバイダ４０２からのレポートだけでなくリゾルバ４０８からのレポートも含めることができる。したがって、アプリケーション２２０は、リゾルバ４０８の１つにより追加されたコンテクスト情報を含むリッチ・データ（rich data）を受け取ることができる。

図４に示され、図４および５Ａと５Ｂを参照して説明されているアーキテクチャは、運用されると、必要なときに適切な資源を提供することにより、モバイル・ナレッジ・ワーカ（mobile knowledge worker）などのユーザーが職務に応じて方向付けられることを可能にする。このアーキテクチャは、ロケーション情報を決定するアプリケーション２２０ための方法を提供する。アプリケーション２２０は、ロケーション情報に基づき、ユーザーから利用できる資源（例えば、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙなどの他の機能を使用して決定することができる資源）を探索し、ユーザー近傍の資源を見つけることができる。

モバイル・ナレッジ・ワーカに関しては、一例として、複数の企業サイト間を移動するユーザーを含めることができる。各サイトで、このアーキテクチャは、プリンタ、プロジェクタ、ホワイト・ボード、スキャナなどを含むことができる資源の位置をユーザーが突きとめることアプリケーション２２０がを支援することを、可能にする。一実施形態では、モバイル・ナレッジ・ワーカは、「Ｎｅａｒ Ｍｅ」オブジェクトなどのロケーション・オブジェクトをクリックすることによりドキュメントに使用するプリンタを特定することができる。ロケーション・サービス２１０は、プロバイダ４０２からデータを受け取り、このデータは、リゾルバを介して解決され、ｆｕｓｅｒエンジン３４０により融合され、ｆｕｓｅｒエンジン３４０、ＷｉｎＦＳ ４５０、および適切なロケーションＡＰＩを介してアプリケーション２２０に供給される。こうして、１つまたは複数のプリンタ・ネットワークが、プリンタおよびロケーションのリストをアプリケーションに供給するように構成されている場合、そのアプリケーションはデータを組み合わせて、近くにあるプリンタのリストを提供することができる。一実施形態では、ロケーション・オブジェクトは、ユーザーが、クリックするか、または他の方法でリスト内のプリンタの１つを指示し、選択したプリンタに出力することを可能にするリンクによって関連付けられる。

他の実施例では、モバイル・ナレッジ・ワーカは、在宅勤務者または、主な事務所例えば本社以外の外部コンピュータのユーザーとすることができる。例えば、家庭用ノートブック・コンピュータは、家庭用無線ネットワークに接続することができる。一実施形態によれば、ロケーション・サービス２１０は、プロバイダ４０２を介してデータを受信し、ユーザーが家庭用ネットワークに接続されていることを示す、ユーザーから見える、アプリケーションに送信する。ユーザーが仕事場に接続できるようにするため、ロケーション・サービス２１０は、例えば、「Ｍy Networks Activity center」などを介して、仕事場に接続する指示をユーザーから受け取ることができる。ユーザーが仕事場のネットワークに接続されていないことを示すデータを受信するので、ロケーション・サービス２１０は、アプリケーションが、例えば、ネットワーク活動センター、ファイヤ・ウォールなどを介してネットワークに接続できるように、アプリケーションがネットワークを識別することを、可能にするができる。

本明細書の開示から利益を得るモバイル・ナレッジ・ワーカの他の例として、複数のモバイル・ナレッジ・ワーカが含まれる。例えば、複数のモバイル・ナレッジ・ワーカのうちの１人が必要とされる場合、ロケーション・サービス２１０は、複数のモバイル・ナレッジ・ワーカのうちの少なくとも１人を突き止めることができる。ユーザーが複数の社員のうちの１人を必要とする場合、各社員がそのユーザーに対し、ユーザーのコンピュータ上で実行されているロケーション・サービス２１０にロケーションを送信できるようにする、許可を与えるようにすることで、一人の社員を特定することができる。例えば、Ｗｉｎｄｏｗｓ Ｍｅｓｓｅｎｇｅｒ（登録商標）などのアプリケーション２２０を、ユーザーが、そのようにする許可を得ている各社員から存在データを受信するように構成することができる。そこで、例えば、ユーザーは、ロケーションに関するデータを使用して、どの社員が最も近いか、最も遠く離れているかを決定し、それに応じてタスクを割り当てることができる。

マスター・リゾルバ
図４と合わせて図６および図７にマスター・リゾルバ３３６が詳細に説明されている。マスター・リゾルバ３３６は、プロバイダ４０２からリゾルバ４０８に、およびリゾルバ４０８からｆｕｓｅｒエンジン３４０にデータを分配するプロセスを管理する。マスター・リゾルバ３３６内では、各デバイスおよび各プロバイダおよび各リゾルバ４０８からのロケーション・レポートの現在のリストを含む、複数のデータ構造が維持されている。マスター・リゾルバ３３６はさらに、リゾルバ４０８により解決されているロケーション・レポート、ロケーション・レポートの現在のサイクル、およびｆｕｓｅｒエンジン３４０に送られる準備のできているレポートのサイクルの追跡を維持する。

一実施形態では、図７のＮｕｍＩｔｅｒで示されているように、マスター・リゾルバ３３６は、リゾルバ４０８までのすべての反復に対するタイムアウト、一つのリゾルバ反復の情報に関するタイムアウト、およびリゾルバ反復回数を含む、ユーザーによる構成が可能な、少なくとも４つのパラメータを保持する。したがって、本開示の利点に関して当業者であれば周知のように、保持されるパラメータの個数およびタイミングは、設計上の選択に応じて変更することができ、これは本実施形態の範囲内にある。

図６に示されているように、マスター・リゾルバ３３６は初期化され（ブロック６０２）、ブロック６０４でマスター・リゾルバ３３６がプラグイン・マネージャ３３８から通知を受け取るまで待機する。通知された後、マスター・リゾルバ３３６は、プラグイン・マネージャ３３８により保存されたロケーション・レポートの集まりを取り出して保存する（ブロック６０５）。次に、決定ブロック６０６に示されているように、マスター・リゾルバ３３６は、各リゾルバをチェックし、リゾルバがレポートの解決に利用できるかどうかを調べる。リゾルバが新しいロケーション・レポートの解決に利用できる場合、マスター・リゾルバ３３６は、そのリゾルバが、保存されているロケーション・レポートの集まりに含まれるロケーション・レポートのタイプの１つに対し構成されているか、つまりブロック６０７に示されているようにレポートを解決できるかどうか、を調べる。リゾルバによりレポートを解決できる場合、ブロック６０８に示されているように、マスター・リゾルバ３３６は最大反復回数に達したかどうかを決定する。最大反復回数に達していない場合、ブロック６０９で、マスター・リゾルバ３３６はレポートをユーザー・エージェント３３２に転送する。ユーザー・エージェント３３２は、ＷｉｎＦＳおよびキャッシュ３３４とやり取りして、レポートにデータを追加する。キャッシュされているデータを使用することにより、リゾルバに必要以上のデータを送信しないようにして、そのレポートを保護する。ユーザー・エージェント３３２およびキャッシュ３３４が必要なデータを追加できない場合、マスター・リゾルバ３３６はデータを適切なリゾルバに転送し、関連するタイマーを起動し、ブロック６１０で示されているように、反復回数をインクリメントする。

利用できるリゾルバがない場合、または最大反復回数に達した場合、レポートは融合する準備ができていると判定される（ブロック６１１）。一実施形態では、マスター・リゾルバ３３６は、データを解釈するリゾルバに応じて、ロケーション・レポートを送信することができる。

タイマーがタイムアウトになる前に、特定のロケーション・レポートの解決が完了したことをリゾルバ４０８がマスター・リゾルバ３３６に通知した場合、マスター・リゾルバ３３６は、ブロック６１２でその特定のリゾルバにより生成された以前のロケーション・レポートの集まりを上書きする。

ブロック６１３では、タイマーがタイムアウトになると、マスター・リゾルバ３３６は最新のロケーション・レポートを、ｆｕｓｅｒエンジン３４０に送る用意ができているロケーション・レポートの集まりに追加する。さらに、マスター・リゾルバ３３６は、各リゾルバとともに古いすべてのロケーション・レポートを無視するように、そのタイマーに関連付けられているリゾルバをリセットし、、このロケーション・レポートの集まりは、ｆｕｓｅｒエンジン３４０に送られる。マスター・リゾルバ３３６はさらに、空きリゾルバのそれぞれについて、新規ロケーション・レポートの解決に利用できるかどうかをチェックする。

ｆｕｓｅｒエンジン３４０は、データにを操作し、ブロック６１４で、マスター・リゾルバ３３６はｆｕｓｅｒエンジン３４０から、最新のロケーション・オブジェクト（ＬａｔＬｏｃ）の形で更新を、受け取る。ＬａｔＬｏｃを受け取った後、ブロック６１６で、ｆｕｓｅｒエンジン３４０はＬａｔＬｏｃをＷｉｎＦＳに転送し、これにより、新しいロケーション・オブジェクトに注目する必要があることを、通知サービス４６０にトリガして知らせることができる。

一実施形態では、マスター・リゾルバ３３６は、コンフリクトを解決するためにｆｕｓｅｒエンジン３４０に送る準備のできているロケーション・レポートの現在の集まり、解決する準備のできているロケーション・レポートの最新の集まり、ｆｕｓｅｒエンジン３４０に送信する最新のロケーション拡張オブジェクト（location extension object）、およびリゾルバ４０８により解決されている可能性のある現在のロケーション・レポート、のサイクルを示すカウンタを保持する。一実施形態では、どのロケーション・レポートをマスター・リゾルバ３３６からｆｕｓｅｒエンジン３４０に送信すべきかについての決定は、このカウンタに基づいて決定される。この実施形態では、このカウンタは、マスター・リゾルバ３３６に陳腐化したデータを送信することを避けることよって、役立つ。陳腐化したデータは、ｏｌｄｅｒサイクルに割り当てることが適するという状態でタグ付けされることができる。

ある実施形態は、コンピュータのロケーションについてのマスター・リゾルバ３３６の解釈を表すスナップ・ショットは、いつでも利用できるということを提供する。このスナップ・ショットは、指定時刻にｆｕｓｅｒエンジン３４０に送信する準備のできているデータを表す。それぞれのロケーション・レポートは、関連付けられているプロバイダ４０２が生成するロケーション・レポートの集まりを識別する。また、ロケーション・レポートは、他のロケーション・レポートから間接的に生成することもでき、その場合、その複数のロケーション・レポートをリンクするようにポインタを構成することができる。

上の表１で、マスター・リゾルバ３３６に関連付けられているデータ構造例は、リゾルバ４０８およびその対応する値を示している。これからわかるように、最新のロケーション・レポートは、各リゾルバ４０８による操作を受けている間保持されている。他の実施形態では、ロケーション・レポートは階層型データ構造である。

図７は、マスター・リゾルバ３３６の一実施形態による状態図である。状態図は、マスター・リゾルバの開始を７０２で示している。マスター・リゾルバ３３６は、ライン７０４で示されているようにキャッシュ３３４から通知が来るのを待つ。通知を受け取った後、ノード７０３で、マスター・リゾルバ３３６はロケーション・レポートを取り出す（７０６）。マスター・リゾルバは、プラグイン・マネージャ３３８にデータがないかチェックする。用意ができたら、マスター・リゾルバ３３６はデータを取り出して、キャッシュ３３４の中に一致するデータがないかチェックする。一致するデータがない場合、マスター・リゾルバ３３６はリゾルバをチェックし、古くなったレポートを上書きする（７０８）。

ノード７０９は、リゾルバ４０８でロケーション・レポートを解決できるかできないかの判別の開始を示す。リゾルバがレポートを解決できる場合（７１０）、状態図はノード７１１に進む。リゾルバも、キャッシュ３３４も、またはユーザー・エージェント３３２もレポートを解決できない場合、マスター・リゾルバ３３６はライン７１２を介してｆｕｓｅｒエンジン３４０に書き込む。ノード７１５は、ｆｕｓｅｒエンジン３４０への書き込みを表す。ｆｕｓｅｒエンジン３４０に書き込んだ後、このプロセスは、ライン７１３で示されているように、反復する。ノード７１１で、反復回数が限度「ｎ」よりも小さい場合、レポートはリゾルバ４０８に送られ、同時にタイマーが開始され、、ライン７１６で示されているようにカウンタが増分される。ノード７１９で、リゾルバ４０８から送られた通知が受信され、ライン７１８で示されているように、ロケーション・レコードが記録される。

リゾルバ
上述のように、リゾルバ４０８は、マスター・リゾルバ３３６からロケーションの情報を取り出す。リゾルバ４０８は、ロケーション・レポートにリッチ情報を入れ、アップグレードされたロケーション・レポートをマスター・リゾルバ３３６に送り返すように構成することができる。リゾルバは、インストールによって、リゾルバが解決することができるロケーション・データの型に関して、ロケーション・サービス２１０に通知することが予期されている。リゾルバ４０８は、一定の型のデータを理解するように構成されている。リゾルバ４０８がデータのその型に関係する情報を見つけることができる場合、リゾルバは、データを１つまたは複数のロケーション・レポートとしてマスター・リゾルバ３３６に渡す。

一実施形態では、リゾルバ４０８は１つまたは複数の発信元と通信して、情報を変換する。また、リゾルバ４０８は、発信元からのデータのキャッシュとの間でやり取りする。一実施形態では、リゾルバ４０８は、リゾルバ４０８がデータの発信元と連絡を取れるか、あるいは取るべきかを判断するポリシーに従う。リゾルバ４０８はさらに、変換可能なロケーション・レポートのリストなどの、ロケーション・サービス２１０によりアドレス指定可能なデータ構造、を備えることができるが、これはリゾルバ特有のものであってもよい。リゾルバ内の他のデータ構造は、現在変換途中のレポートおよび任意の変換済みオブジェクトの識別を含む。

ロケーション・レポートのリストを作成する適切なデータ構造を次のように実装することができる。

List[LReport]can_translate;
動作中、リゾルバ４０８はマスター・リゾルバ３３６から通知を待つ。通知されると、解決するために、ロケーション・レポートが取り出される。解決することにより、ロケーション・レポートが作成され、マスター・リゾルバ３３６に返される。

プラグイン・マネージャ
図８Ａおよび８Ｂを参照すると、プラグイン・マネージャ３３８の機能が示されている。一般に、プラグイン・マネージャ３３８は、ロケーション・サービス２１０と登録済みプラグインとの間の情報のやり取りおよびデータ交換を受け持つ。より具体的には、一実施形態では、プラグイン・マネージャ３３８は、２つの主要な機能が実装し、これは、プラグインとの情報をやり取りするための中央管理機能（central management）を提供することおよびプロバイダを発信元とする更新通知を解釈する中央着信監視機能（central listening function）を提供すること、を含む。中央マネージャとして、プラグイン・マネージャ３３８は、管理ＡＰＩ（ＬｏｃＭｇｍｔＡＰＩ）からのユーザー管理要求（user administrative requests）を受け取る中央コンポーネントである。プラグイン・マネージャ３３８は、それらの要求を、ロケーション・プラグインＡＰＩを介して持ち越されるアクションに変換するが、これはプロバイダに対し、リゾルバに対して、またはその両方に対してとすることができる。プラグイン・マネージャ３３８の管理制御の役割は、ロケーション・サービス２１０とリゾルバおよびプロバイダとのインターフェースをとることである。一実施形態では、プラグイン・マネージャ３３８は、その時点で登録されているすべてのプラグインを表すプロバイダおよびリゾルバ・プラグインを表すオブジェクトの集まりを保持する。プラグイン・マネージャ３３８は、その集まりのマネージャとして、ロケーション・サービス２１０に登録されているプラグインのリストを提供すること、およびユーザー／アプリケーションの要求に基づいて、サービス起動時または動的に、プラグインの登録することおよび登録解除すること、を受け持つ。例えば、登録／登録解除は、ＬｏｃＭｇｍｔＲｅｇｉｓｔｅｒＰｌｇ／ＬｏｃＭｇｍｔＵｎｒｅｇｉｓｔｅｒＰｌｇとして実装することも可能な管理ＡＰＩを介して、およびプラグインの構成に対してアプリケーションが読み取り専用／読み書きアクセスを行う場合のアービトレーションを介して、およびプラグインとの間のクエリと設定呼び出し、ＬｏｃＭｇｍｔＱｕｅｒｙ／ＳｅｔＰｌｇ、および構成データをインターフェースすることを介して、行うことができる。

一実施形態では、プラグイン・マネージャ３３８は、ロケーション・プロバイダ・プラグインから発信したデバイス更新通知の着信を監視する中央コンポーネントとして実装される着信監視コンポーネントである。

登録されるプラグインの内部表現は、以下の表３に示されている構造を備えるオブジェクトにより一般的な形で説明される。
表３

表３（続き）

表３に示されているデータ構造には６つのデータ構造が含まれる。その１つは、ｍ＿ｅＰｌｇＴｙｐｅであり、これは、プラグインのタイプを識別する列挙型を指定し、ロケーション・プロバイダ・プラグイン（ｅＰｌｇＰｒｏｖｉｄｅｒ）またはロケーション・リゾルバ・プラグイン（ｅＰｌｇＲｅｓｏｌｖｅｒ）のいずれかである。第２のデータ構造は、ｍ＿ｗｓｚＧｕｉｄであり、これは、Ｇｌｏｂａｌｌｙ Ｕｎｉｑｕｅ ＩＤ（ＧＵＩＤ）でプラグインを一意に識別する。ＧＵＩＤは、L"a Q1A11' ｛xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx｝"の形式でフィールドｗｓｚＰｌｇＧｕｉｄに格納でき、またプラグイン自体によりハード・コーディングすることができる。ロケーション・サービス２１０は、登録時にプラグインのＧＵＩＤを取り出す。

第３のデータ構造は、ｍ＿ｗｓｚＢｉｎａｒｙであり、これは、プラグインを実装するバイナリの名前を指定する。１つのバイナリで、複数のプラグインを実装できるため、このデータ構造では、一般的に、特定のプラグインが一意に識別されない。

第４のデータ構造は、ｍ＿ｈＭｏｄｕｌｅであり、これは、プラグインを実装するデータ・リンク・ライブラリ（ＤＬＬ）へのハンドルを指定する。

第５のデータ構造は、ｍｈＮｔｆＥｖｅｎｔであり、これは、何らかのデバイスのロケーションに関して重要なデータ（デバイス・レポート）に変更があった場合またはロケーション・レポートが推論された場合に、ロケーション・プロバイダ／リゾルバ・プラグインにより送られる通知イベントを、指定する。プラグインは、コールされて初期化関数に入ったときに通知イベントを作成し、このイベントへのハンドルをサービスに送り返すことができる。その後、プラグインに更新されたデバイス・レポート／ロケーション・レポートがあれば、その更新に関してロケーション・サービス２１０に通知するためにこのイベントを送るだけでよい。

第６のデータ構造は、ｍ＿ｐｆｎＬｏｃＰｌｇ＊であり、これは、プラグインによってエクスポートされる関数へのポインタを指定する。プラグイン・コンテクストが作成されると（登録時またはサービス起動時に）、ロケーション・サービス２１０は、それらがロケーション・プラグインＡＰＩとして識別されるような所定の関数へのポインタで、それらを初期化する。

さらに、プラグインは、識別クラスＣＰｒｏｖＰｌｕｇｉｎおよびＣＲｅｓＰｌｕｇｉｎを有し、リゾルバ・プラグインまたはプロバイダ・プラグインのいずれかとして識別する。以下の表４に示されている定義例はＣＰｌｕｇｉｎから導かれるものであり、定義は以下のとおりである。

マネージャ３３８は、以下の表５に説明されているようなオブジェクトとしてロケーション・サービス２１０内で、内部的に表されている。

プラグイン・マネージャ３３８のメンバは、７つのタイプのデータ構造を持つ。第１のタイプはｍ＿ｍａｐＰｒｏｖおよびｍ＿ｍａｐＲｅｓで、これらは登録されているすべてのプロバイダおよびリゾルバ・プラグインの集まりである。これらの集まりには、ＣＰｌｕｇｉｎオブジェクトへの参照が含まれ、それぞれ特性および各プラグインとのインターフェースを内部的に表す。

第２のタイプのデータ構造は、プラグイン・マネージャ３３８の通知イベントを指定するｍ＿ｈＮｔｆＥｖｅｎｔである。プラグイン・マネージャ３３８がプロバイダ・プラグインからレポートを更新する毎に、データ構造によりこのイベントが設定される。マスター・リゾルバ３３６がこのイベントに登録され、プラグイン・マネージャ３３８の通知が感知され、用意ができたときに更新がプルされる。

第３のタイプのデータ構造は、プラグイン・マネージャ３３８の初期化および終了ハンドルを指定するＩｎｔｉａｌｉｚｅおよびＴｅｒｍｉｎａｔｅである。

第４のタイプのデータ構造は、登録済みプラグインの集まりに対する管理制御ハンドラを指定するＬｏａｄＰｌｕｇｉｎ、ＵｎｌｏａｄＰｌｕｇｉｎ、ＯｐｅｎＰｌｕｇｉｎ、およびＣｌｏｓｅＰｌｕｇｉｎを含む。

第５のタイプのデータ構造は、プラグイン・マネージャ３３８から更新されたレポートをピックアップする必要が生じたときにマスター・リゾルバ３３６により呼び出されるハンドラを指定するＰｕｌｌＰｒｏｖＲｅｐｏｒｔｓを含む。

第６のタイプのデータ構造は、１つまたは複数のレポートをリゾルバ・プラグインにディスパッチする必要がある場合にマスター・リゾルバ３３６により呼び出されるハンドラを指定するＰｕｓｈＲｅｓＲｅｐｏｒｔｓを含む。

第７のタイプのデータ構造は、プラグイン・マネージャ３３８の管理ハンドラを指定するＱｕｅｒｙＣｏｎｆｉｇおよびＳｅｔＣｏｎｆｉｇを含む。

その通知リスナーの役割において、プラグイン・マネージャ３３８は、プラグインによって生成される更新信号を監視する。通知の取り扱いは、その通知と関連するプラグインのタイプに応じて異なる。

一実施形態では、予期しない方法で到着するプロバイダ・プラグインを発信元とする通知は、受け入れおよび／または処理のときに頻度閾値を課すように特別な配慮を払って、プラグイン・マネージャ３３８によって処理される。閾値自体は、ＬｏｃＭｇｍｔＱｕｅｒｙ／ＳｅｔＰｌｇなどの管理呼び出しを介して、ユーザーが構成可能な値とすることができる。

リゾルバ・プラグインから発信される通知は、ロケーション・サービス２１０によりリゾルバに渡されるロケーション・レポートへの応答として生成されるため、閾値の制限は必要ない。

プロバイダ通知を感知し、更新されたレポートを取り出すためにプラグイン・マネージャ３３８によって使用される論理は、頻度閾値のチェックのため各プロバイダ・プラグイン・オブジェクト上で動作する有限状態機械として、図８Ａに示されている。

通知が感知されたときに開始８０２から動作が始まる。ノード８０４により、初期化８０４、初期状態ハンドラが識別される。このハンドラは、プロバイダに「ｕｎｉｎｉｔｉａｌｉｚｅｄ」というマークを付け、プロバイダ・タイマーを所定のプロバイダ閾値Ｐｒｏｖｉｄｅｒ．ｌａｓｔ＿ｎｔｆ＿ｔｉｍｅ＜−０に設定し、更新通知のためプロバイダに登録する。通知はプル（pull）８１２を宛先とする。

タイムアウト後、状態機械８００は、ノード８０６に進み、そこで、着信監視状態ハンドラを識別する。着信監視状態ハンドラ８０６は、プロバイダ時刻を所定のプロバイダ閾値に設定し、未初期化のプロバイダを初期化に設定する。次に、着信監視状態ハンドラ８０６は、通知イベント、Ｓｅｔ ＰｌｇＭｇｒ Ｎｏｔｉｆｉｃａｔｉｏｎ ｅｖｅｎｔイベント（信号ＰｌｇＭｇｓｒ）を設定する。プロバイダによって更新通知が生成された場合、状態機械８００は、ノード８０８に進み、そこで、チェック状態ハンドラを識別する。チェック状態ハンドラ８０８は、プロバイダ・タイマーをリセットし、最後（最新の）の通知時間が所定のプロバイダ閾値以上（ＴｉｍｅＮｏｗ−Ｐｒｏｖｉｄｅｒ．ｌａｓｔ＿ｎｔｆ＿ｔｉｍｅ＞＝Ｐｒｏｖｉｄｅｒ．ｔｈｒｅｓｈｏｌｄ）かどうかを決定する。そうならば、通知頻度閾値がチェックされて合格しており、プロバイダ通知は、プロバイダの閾値よりも広い時間間隔に含まれていたということである。通知が時間範囲内であった場合、状態機械８００は通知をプル８１２に送る。プロバイダ閾値以上でない場合、通知頻度閾値がチェックされたが不合格であり、通知はプロバイダの設定済み閾値よりも時間的に接近しているということである。

不合格の場合、状態機械８００は一時停止８１４を行うが、これは、プロバイダ通知からプロバイダを登録解除する状態ハンドラとなっており、プロバイダ・タイマーを、最後の通知時間（ＴｉｍｅＮｏｗ−Ｐｒｏｖｉｄｅｒ．ｌａｓｔ＿ｎｔｆ＿ｔｉｍｅ）に等しいプロバイダ閾値に設定する。タイムアウトの後、状態機械８００は再開８１６に移動し、プロバイダ通知の登録を再開する。その後、状態機械８００はプル８１２に移動する。

上述のように、再開８１６、チェック８０８、および初期化８０４はそれぞれ、プル８１２に向かっており、これにより、プル状態ハンドラが識別される。プル状態ハンドラは、最後の通知時間Ｐｒｏｖｉｄｅｒ．ｌａｓｔ＿ｎｔｆ＿ｔｉｍｅ＜−ＴｉｍｅＮｏｗに応じてプロバイダから更新済みレポートをプルする。また、プロバイダが未初期化状態であれば、そのプロバイダに初期化済みのマークが付けられ、他に未初期化プロバイダがなければ、プラグイン・マネージャ通知イベントが設定される。

状態機械８００に関して説明したアクションにより、ロケーション・サービス２１０は２つの特別なケースでオーバーロードさせる通知レートから保護される。特に、第１の場合、起動時に、各プロバイダは、基本デバイスから初期データの集まりの一部として更新通知を生成することが期待されている。これらの通知が、無条件で処理される場合、各デバイス・データからロケーション・コンテクストを構築することが増大するので、ロケーション・サービス２１０はきりきり舞い（スピン）する。この状態機械が実装する優れたオプションは、初期化時に、登録されているすべてのプロバイダがそれらの初期状態に到達するのを待ち、その後、更新が利用できるマスター・リゾルバなどの、他のロケーション・サービス２１０のサブ・システムへのデータおよび信号を収集することにつきる。その結果として起こる特別な場合として、プロバイダ（他のプラグインと同様に）が正しいことをすると信じることができないという仮定に基づくと、プロバイダによる初期通知の遅延が長すぎて、ロケーション・サービス２１０に許容できない遅延を引き起こす可能性もある。許容できない遅延を防止するために、ロケーション・サービス２１０は、初期通知を待ちながらプロバイダの閾値に等しいタイムアウトを設定する。このようなタイムアウトが発生した場合、プロバイダは、データが存在していない場合であっても初期化されているとみなされ、ロケーション・サービス２１０は、ブロック解除される。

第２の特別な場合、ロケーション・サービス２１０は、各プロバイダに固有の閾値を通じて通知が過剰に行われないように保護される。プラグイン・マネージャ３３８は、プロバイダ通知を処理するときに、プロバイダ・コンテクストにおいて通知にタイムスタンプを付加する。許容される閾値よりも短い間隔で次の通知が感知された場合、プラグイン・マネージャ３３８は、プロバイダの通知イベントから登録を解除し、残りの閾値期間にタイマーを起動する。プラグイン・マネージャ３３８は、プロバイダから最新のレポートをプルし、タイマーがタイムアウトになった後に限り通知の再登録を行う。それまでは、ロケーション・サービス２１０は絶縁され、不作法にふるまうプロバイダから保護されている。

状態機械８００の論理にも拘わらず、プロバイダに対する管理作業が許されており、それは、プラグインのアンロード／登録取消まで、を含んでいる。

一実施形態では、プラグイン・マネージャ３３８は、受け取ったプロバイダ・レポートの最後のサイクルを維持するように実装されている。最新のプロバイダ・レポートは、デバイスに関連付けられている各プロバイダ４０２からのレポートを含む。プラグイン・マネージャ３３８には、最新のプロバイダ・レポートをマスター・リゾルバ４０６に送信する役割を持つ。この実施形態では、図８Ａに関して上で説明したように、プラグイン・マネージャ３３８はプロバイダからレポートを受け取る際のタイムアウトに関係する少なくとも１つの構成可能パラメータを持つ。ロケーション・サービス２１０は、高速なまたは有害なプロバイダが、上述のように、ロケーション・サービスをレポート攻めにするのを防止するという点でタイムアウト利用している。以下の表６は、それぞれのレポートの集まりがプロバイダおよびデバイスによってインデックスが付けられて、プロバイダ・レポートの最新の集まりを格納する際のデータ構造構成例を示している。

図８を参照すると、図８Ｂのブロック８１０では、プロバイダ４０２から通知を受け取った後、プラグイン・マネージャ３３８はタイマーを起動し、サイクルをインクリメントし、プロバイダ４０２からのレポートを記録する。ブロック８２０では、プラグイン・マネージャ３３８は（プロバイダ、デバイス）それぞれのペアについてのロケーション・レポートの最新の集まりのみを格納する。例えば、表１を参照して、指定されたペアから最新のデータのみを取り出し、旧いデータを破棄することにより、冗長さを避けている。ブロック８３０で、タイマーがタイムアウトになる前に、プロバイダがプラグイン・マネージャ３３８に通知すると、そのプロバイダ４０２からのレポートは記録される。ブロック８４０で、タイマーがタイムアウトになった後、プラグイン・マネージャ３３８はプラグイン・マネージャのキャッシュから記録されているレポートを抽出し、それをデータ構造「ＰＬＵＧＩＮ ＭＡＮＡＧＥＲ」に書き込む。

次に図９を参照すると、プラグイン・マネージャ３３８によって操作される各プロバイダに適切な状態遷移図が示されている。状態図９００は、初期化９１０から始まる。プロバイダからの通知がライン９２０で示されているように受信された場合、プラグイン・マネージャは、ノード９１２で、ロケーション・レポートを記録するようにプラグイン・マネージャ３３８内のコードを開始させ、タイマーを始動させる。ライン９３０により、ロケーション・レポートの通知の反復ループおよびノード９２２のレポートの記録が識別される。ライン９４０により、タイマーがいつタイムアウトになるかが識別され、ノード９３２でデータがＰＬＵＧＩＮ ＭＡＮＡＧＥＲに書き込まれる。タイマーがタイムアウトにならない場合、ライン９５０により、プロセスがノード９１２にループバックすることが示される。一実施形態では、ロケーション・レポートを記録するコードは、プラグイン・マネージャ３３８がレポートを保持する各デバイスのロケーション・レポートの新しい集まりを作成することを規定する。さらに、このコードは、ロケーション・レポートのすべての集まりをグループ化し、サイクルに関係する識別子をレポートに刻印し、プラグイン・マネージャ３３８の外部に送信する用意ができているレポートにフラグを立てるように構成することができる。

ｆｕｓｅｒ
次に図１０を参照すると、ブロックが、ｆｕｓｅｒエンジン３４０の基本機能を示している。ｆｕｓｅｒエンジン３４０は、ロケーション・レポートおよびキャッシュ３３４から読み込んだロケーション・レポートに基づいて、コンピュータのロケーションの最良の推測を表す矛盾のない１つのロケーション・オブジェクトを生成する。ｆｕｓｅｒエンジン３４０は、本明細書で融合（fusion）と呼んでいるプロセスを通じてこの作業を実行する。融合は、コンフリクトの解決、統合、およびコンフリクトしているレポートの調整（reconciliation）を行う。

図１０のブロック１０１０では、ｆｕｓｅｒエンジン３４０がロケーション・レポートの集まり、およびそのロケーション・レポートの集まりに関連するロケーション・レポートの集まり、を受け取る。これらのレポートは、複数のプロバイダおよびリゾルバから個別に送るか、またはそれらのレポートを、マスター・リゾルバ３３６などから、グループとして受け取ることができる。一部のレポートは、互いにコンフリクトするかも知れない。例えば、ロケーション・レポートに示されているコンピュータのロケーションの部屋番号が異なることもあり得る。ブロック１０２０で、ｆｕｓｅｒエンジン３４０は、コンフリクトしているレポートの間で、加重投票プロセスなどの、１つまたは複数の統計的プロセスを適用することにより、これらのコンフリクトを解決する。重みは所定の発信元の集まりから得られ、プロバイダの重み、リゾルバの重み、リゾルバの分割率（resolver split rate）、空間的不確定性、およびレポートの経過時間（age）を含めることができる。

ブロック１０３０では、ｆｕｓｅｒエンジン３４０は、報告された最終的なロケーション・オブジェクトのさまざまなフィールドを、利用可能なロケーション・レポートで埋めることにより、レポートを統合する。例えば、部屋番号を指定するレポートは部屋フィールドに関係し、ビルディング番号を指定するレポートはビルディング・フィールドに関係する。

一実施形態では、ロケーション・レポートは、ｆｕｓｅｒエンジン３４０によって、ロケーション・レポートをリゾルバ・レポートのツリーとして受信し、ｆｕｓｅｒエンジン３４０はこれを、単一のロケーション・レポート、またはロケーション・サービス２１０の外部のアプリケーションなどで使用するロケーション・オブジェクトに変換する。単一のロケーション・レポートは、ＭａｐＰｏｉｎｔ（登録商標）または他の適切なアプリケーションによって定義されているＭｉｃｒｏｓｏｆｔ Ｌｏｃａｔｉｏｎ Ｒｅｐｏｒｔ形式などの所定の形式（format）にまとめることができる。

一実施形態では、ロケーション・サービス２１０は、２つのタイプのレポートをｆｕｓｅｒエンジン３４０に渡す。あるものは、緯度、経度、および高度を含むメトリック・レポートも含む。メトリック・レポートはさらに、Ｙ軸およびＸ軸ロケーションを使用可能にする場合のようにｘ成分およびｙ成分を含むこともできる。ロケーション・サービス２１０がｆｕｓｅｒエンジン３４０に渡すことができる他のタイプのレポートとして、例えば、「ビルのフロア、部屋」、「住所、市、州、国」、または「宇宙、銀河、太陽系、惑星」などを示す階層型レポートも含む。さらに、階層型レポートの要素は、ｆｕｓｅｒエンジン３４０で階層型レポートを作成したり、またはまとめたりすることを可能にするリンクを含む個別のロケーション・レポートとして表すこともできる。ｆｕｓｅｒエンジン３４０に渡されるレポートのタイプは、適切なファネル（funnel）によって受信される。ファネルは、ｆｕｓｅｒ ３４０がその情報を融合することができるように、ｆｕｓｅｒ ３４０に渡される情報のタイプを識別する。

一実施形態では、レポートをｆｕｓｅｒエンジン３４０に送る前に、ロケーション・サービス２１０の他のコンポーネントは、各レポート内の各要素またはレポート自体に、融合を有効にする重みとともにタグを付ける。プロバイダ重み、リゾルバ分割重み、空間的不確定性、リゾルバ重み、およびレポートの経過時間などの重みは、整数または０から１までの間の実数として表すことができる。

重みに関して、一実施形態では、プロバイダ重みはプロバイダの信頼性を表す。詳しく言うと、プロバイダの信頼性は、レポートに関連付けられている指定されたプロバイダが正しいデータを供給しているとロケーション・サービス２１０により決定される確率である。一実施形態では、プロバイダの信頼性は、ユーザー・インターフェースを介してユーザーにより判定され、このインターフェースによりユーザーは信頼できないプロバイダに低い重みを付けることができる。例えば、ユーザーは、ロケーション・データが不正確であるとことで知られている携帯電話プロバイダに低い重みを付けることができる。

リゾルバ重みは、レポートに関連付けられている指定されたリゾルバが正しいデータを供給しているという、ロケーション・サービス２１０により決定された、リゾルバの信頼性とすることができる。複数のリゾルバがレポートに関連付けられている場合、１つの確率パラメータで、複数のリゾルバ信頼性パラメータを考慮に入れることができる。

空間的確定性重みは、指定されたレポートの精度に関連付けられた重みとすることができる。例えば、レポートにおいて、８０２．１１タイプのアクセス・ポイントに基づいて部屋番号またはロケーションが指定されており、そのアクセス・ポイントは約１００室の部屋に対応している場合、レポートの空間的確定性パラメータは１／１００となる。

経過時間重みは、時間の関数である経過時間信頼性とすることができる。レポートは、レポート経過時間に比例して低い重みが付けられる。レポートの経過時間とともに、経過時間重みは小さくなる。一実施形態では、経過時間重みは、時間の負の指数関数を適用することにより決定され、これには、最低の重みとレポートの重みがなくなるタイムアウトを含めることができる。

また、単一のプロバイダ・レポートの分割を複数のリゾルバに分担させて、解決分割重み(resolve split weight)をレポートに適用することもできる。例えば、８０２．１１プロバイダはそのレポートを、緯度、経度を提供する２つの異なるリゾルバに送ることができる。この場合、リゾルバ分割重みは０．５であり、１つのプロバイダ・レポートが２つのリゾルバに分割されたという現実を反映する。このことは、複数のリゾルバに分割することにより、単一のプロバイダ・レポートが大きすぎる重みを付けられることを防止する。

一実施形態では、メトリック・タイプのレポートなどの、ある種のレポートの場合、複数の重みを乗算することにより、複数の重みは、単一の重みに統合される。

式１に示されているように、メトリック・レポートの集まりは、重み付き平均を適用することにより表すことができる。詳しく言うと、式１は、レポートｉ上に４つの重みが、ｗ_１ｉ、ｗ_２ｉ、ｗ_３ｉ、およびｗ_４ｉに付けられている場合、ｆｕｓｅｒは乗算ｗ_ｉ＝ｗ_１ｉｗ_２ｉｗ_３ｉｗ_４ｉによりそれらを１つの重みに統合する。（ｘ_ｉ，ｙ_ｉ）、ｉ＝１Ｋ Ｎなどのメトリック・レポートの集まりでは、融合されたレポートは以下のように重み付き平均とすることができる。

（式１）

重み付き平均ではなく階層タイプのレポートの場合、ｆｕｓｅｒエンジン３４０は、重み付き階層型投票プロセスを適用する。例えば、表３では、４つの階層型レポートの例が取り上げられている。各レポートには、ビルディング、部屋、およびフロアの要素が示されている。重みは、各レポートの各要素に関連付けられている。ｆｕｓｅｒエンジン３４０は、レポートのツリーからそれらの要素をまとめる。一実施形態では、このレポートのツリーはマスター・リゾルバ３３６内で作成される。

表７を参照すると、４つのレポートが考察されており、１から４までのラベルが付いている。重み付き階層型投票は、階層の物理的に最も大きなレベルから始まる。表７では、最大要素がビルディングである。各候補の重みの総和をとる。例えば、表７において、ビルディング４０は、０．９＋０．８＋０．９＝２．６という組合せ重みを持ち、これは、ビルディング４１に関連付けられた組合せ重み０．３よりも高い組合せ重みとなっている。

一実施形態では、最大レベルの階層要素が考慮対象から除外されると、その最大レベルよりも下のレベルも自動的に排除される。したがって、例えば、ビルディング４１が除外されると、ビルディング４１の下位レベルも除外れる。こうして、ビルディング４１内のフロアがロケーションの対象から外される。残りのフロアのうち、残っている重み付き平均は、フロア３が正しい最高の確率を有していることを示している。フロア３が識別された後、フロア４および１、およびフロア４および１の部屋が排除される。残りの部屋の間では部屋３１４１が、高い重みを有している。したがって、ｆｕｓｅｒエンジン３４０により示されたロケーションは、ビルディング４０、フロア３、および部屋３１４１である。

ｆｕｓｅｒエンジン３４０では、ロケーション・サービス２１０により決定された各種の階層について、表３などのような表を作成することができる。階層は１つまたは複数のレベルからなる。１レベル階層型では、ｆｕｓｅｒエンジン３４０は投票方式を適用し、その１レベルに関して、最も確率の高いロケーションを決定する。

通知サービス
通知アプリケーションは、ＷｉｎＦＳ通知プラットフォームとともに動作する。通知アプリケーションでは、アプリケーションから申し込める通知のタイプ、アプリケーションに通知する場合にそのタイミング、および方法を定義する。通知アプリケーションは、申し込みスキーマ（subscription schemas）、通知スキーマ（notification schemas）、イベント・ソース（event source）、イベント・スキーマ（event schema）、通知生成規則（notification generation rules）、および通知書式設定（notification formatting）を含む。

申し込みスキーマは、Ｏｕｔｌｏｏｋなどのアプリケーションが登録を望む場合に発生するイベントを定義する。例えば、ロケーション・サービスの申し込みスキーマは、現在のロケーションが「ｈｏｍｅ」である場合に、Ｏｕｔｌｏｏｋに通知するように登録することを可能にする。通知スキーマは、通知されたときに、Ｏｕｔｌｏｏｋにどのような情報が届くかを定義する。例えば、通知スキーマは、Ｏｕｔｌｏｏｋが、日時、および現在のロケーションを、受信することを可能にする。イベント・ソースは、イベントの発信元を決定する。イベントとは、通知の登録しているアプリケーションにとって重要と思われる、発生する出来事である。例えば、ｆｕｓｅｒ３４０が新しいロケーションをＷｉｎＦＳに書き込むことは、１つのイベントである。このイベント・ソースはＷｉｎＦＳである。

イベント・スキーマは、イベントに必要な情報を定義する。例えば、イベントには、日時およびロケーションが必要である。通知生成規則により、イベントと申し込みスキーマとの照合が行われ、アプリケーションに通知する必要があるかを調べる。例えば、現在のロケーションが「ｈｏｍｅ」であるとし、そのロケーションが「ｈｏｍｅ」であったときにアプリケーションに通知するように登録しているとすると、このような一致をチェックし、通知を発生するのが通知生成規則である。通知形式は、通知がアプリケーションに向かう方法で、ＳＱＬ言語からアプリケーションを抽象化する場合に使用する方法を定義する。

通知サービス４６０は、ロケーションのリストに関連付けられているアプリケーション識別子のマップを保持することができる。このマッピングにより、通知サービス４６０に登録されているアプリケーションは、ロケーション・オブジェクトがアプリケーション識別子と一致するロケーションを識別したときに、通知を受信することができる。

通知ディスパッチャに適切なデータ構造の一例として以下のものがある。
Map[Application, List[Location]] registered;

次に図１１を参照すると、流れ図に通知サービス４６０の方法が示されている。ブロック１１０２で、通知サービスはキャッシュ３３４から通知が来るのを待つ。他の実施形態では、通知は、ｆｕｓｅｒエンジン３４０などのロケーション・サービス２１０の他のコンポーネントを発信元とすることができる。ブロック１１１０で、通知サービス４６０はキャッシュ３３４から通知を受信する。ブロック１１２０で、通知サービス４６０はＷｉｎＦＳからロケーション・オブジェクトを取り出す。決定ブロック１１３０では、通知サービス４６０は、アプリケーションへのロケーションにマッチングするデータ構造をチェックする。ロケーション・オブジェクトにマッチングするロケーションがリストに置かれている場合、識別されたアプリケーションに対しブロック１１４０で通知される。識別されたアプリケーションがない場合、通知サービス４６０は、キャッシュ３３４からの他の通知が受信されるまで、ブロック１１０２で、待機状態に入っている。

プロバイダ
プロバイダは、センサからデバイス特有のロケーション情報を取り出し、情報を正規化し、情報を標準形式に変換し、情報をプラグイン・マネージャ３３８に送信する。ロケーション・サービス２１０とともに使用するに適しているプロバイダ４０２は、タイマーＴ、およびそれが受け持つ各デバイスから取得される最終レポート、を持つ。タイマーＴは、ある時刻に設定することで、プロバイダ・プラグインおよびロケーション・サービス２１０に殺到することからデバイスを保護するためのスロットル（絞り弁）として働く。

一実施形態では、センサおよび／またはプロバイダは、プロバイダ／センサが機能するロケーション・サービス２１０のバージョンを示すバージョン番号も発行する。例えば、ＧＵＩＤで、センサ／プロバイダを一意に識別することができる。一実施形態では、プロバイダは、ロケーション・サービス２１０によりプロバイダを安全に識別できるように、強い名前（strong name）で１つの集まりとして実装することができる。

さらに、プロバイダ４０２は各デバイスから得られた最終レポートを保持し、認知されたロケーションに著しい変更が生じたかどうかをチェックする。変更が生じた場合、プロバイダはプラグイン・マネージャ３３８に通知する。プロバイダ内にデータを保持するデータ構造の例を以下に示す。
Map[Device, Device Report] LastReport;

図１２を参照して、プロバイダ４０２によって実行されるプロセスについて詳述する。詳しく言うと、ブロック１２１０において、最初にセンサからの通知が届くと、プロバイダはレポートを取り出す。プロバイダは、そのレポートを適切なデータ構造に保存する。次に、ブロック１２２０で、プロバイダはレポートをロケーション・レポートに変換する。続いて、ブロック１２３０で、プロバイダはロケーション・レポートをプラグイン・マネージャ３３８に送り、タイマーＴを起動する。

決定ブロック１２４０で、タイマーＴがタイムアウトになったかどうかを判定する。タイムアウトになっていなくて、センサから通知が届いた場合、プロバイダは、ブロック１２５０で、そのレポートを無視する。タイムアウトになった場合、センサから通知が届くと、プロバイダは、レポートを取り出す（１２６０）。ブロック１２７０で、プロバイダはレポートをそのセンサから得られた最終レポートと比較する。決定ブロック１２７２で、著しい変更が生じているかどうかを判定する。ブロック１２８０で、著しい変更がある場合、「ＮｅｅｄＴｏＳｅｎｄ」がＴＲＵＥに設定され、著しい変更はない場合、ブロック１２９０で、「ＮｅｅｄＴｏＳｅｎｄ」はＦＡＬＳＥに設定される。「ＮｅｅｄＴｏＳｅｎｄ」がＴＲＵＥの場合、ブロック１２９２で、レポートを送り、タイマーをリセットする。「ＮｅｅｄＴｏＳｅｎｄ」がＦＡＬＳＥの場合、ブロック１２９４で、センサから次の通知が来るのを待つ。

データ構造
本開示の利点に関して当業者には周知のことであるが、ロケーション・サービス２１０を最大限に利用するために、複数のデータ構造がロケーション・サービス２１０に用意されている。多くの追加または組み合わせたデータ構造は、本明細書に示されている実施形態の範囲内にある。データ形式（data format）およびデータ構造の例として、ロケーション・レポート（LReport）、ロケーション・レポートの集合（ColLReport）、ロケーション・オブジェクト（Location）、ロケーション拡張オブジェクト（LocattionEX）を含めることができる。

ロケーション・レポートは、プロバイダ・プラグイン３１０”によって生成されるレポートとすることができる。ロケーション・レポートは、情報の１つの自律的な断片を表すことができ、したがって、プロバイダに複数のセンサに関する情報がある場合、プロバイダは複数のロケーション・レポートを生成することができる。一実施形態では、ロケーション・レポートは、信頼度（confidence）、レポート識別子、レポート・タイプに関するデータを持つデータ構造が含まれる。一実施形態では、ロケーション・サービス２１０は、ロケーション・レポートから継承した内部ロケーション・レポートを供給することをプロバイダが要求する。内部ロケーション・レポートには、識別子、ＮＤＭｅｄｉａＴｙｐｅ、ＦｕｎｎｅｌＴｙｐｅ、および１つまたは複数のｆｕｓｅｒ重みを含めることができる。

ロケーション・レポートに対応して、他のデータ構造としてロケーション・レポートの集まりがある。ロケーション・レポートの集合は、受信した各ロケーション・レポートについて１つまたは複数のレポートを生成する複数のリゾルバ４０８に対して適切なものである。ＳｅｔＬＲｅｐｏｒｔを使用して、リゾルバが出力するものを表す。データ構造の例として、以下のように構造体が考えられる。
typedef SetLReport = Set[LReport]

ロケーション・サービス２１０のさまざまなコンポーネントと関連する上述のデータ構造はロケーション・オブジェクトである。ロケーション・オブジェクトは、上述のように、ｆｕｓｅｒエンジン３４０により融合プロセスの一部として生成される。ロケーション・サービス２１０に適合するように構成されているアプリケーションは、サービスを実行しているコンピュータのロケーションを判別するために、ロケーション・レポートの集合であるロケーション・オブジェクトを使用することが予期されている。一実施形態では、この集合には、位置、アドレス、階層型ロケーション、およびメタ・データが含まれる。

一実施形態では、ロケーション・レポートには、２つタイプのレポート、アプリケーション・ロケーション・レポートおよび内部ロケーション・レポートが含まれる。内部ロケーション・レポートは、ロケーション・レポートから継承される。内部ロケーション・レポートとアプリケーション・ロケーション・レポートとの違いは、内部ロケーション・レポートはｆｕｓｅｒの利用を想定して構成されているという点にある。内部ロケーション・レポートは、ｆｕｓｅｒ ３４０、プロバイダ４０２、およびリゾルバ４０８により作成することができる。アプリケーション・ロケーション・レポートは、アプリケーションでの使用を想定して構成されている。したがって、アプリケーション・ロケーション・レポートは、ｆｕｓｅｒ重みおよびファネルタイプなどのｆｕｓｅｒに必要なデータとは独立している。アプリケーション・ロケーション・オブジェクトは、アプリケーション・ロケーション・レポートの集合を含む。一実施形態では、拡張オブジェクトは、内部ロケーション・レポートの集合とすることができ、ロケーション・オブジェクトは、上述のように、アプリケーション・ロケーション・レポートの明確に定義された集合とすることができる。ロケーション拡張オブジェクトは、ユーザーの現在のロケーションに関する内部ロケーション・レポートの集合を含むことができる。

図４に戻ると、複数のＡＰＩにより、ロケーション・サービス２１０はアプリケーション、プラグイン、およびロケーション・サービス２１０内の内部コンポーネントとの間で情報をやり取りすることができることがわかる。上述のＡＰＩの１つは、ロケーション管理ＡＰＩ（ＬｏｃＭｇｍｔ）４２０である。ロケーション管理ＡＰＩ ４２０を使用することで、アプリケーションは、リゾルバ・プラグイン４０８、キャッシュ３３４、マスター・リゾルバ３３６、およびｆｕｓｅｒエンジン３４０などのプラグインを構成することができる。ＬｏｃＭｇｍｔ ４２０は、プラグインを構成するための以下の機能を備える。一実施形態では、ＬｏｃＭｇｍｔ ４２０はファイル・ハンドル・モデルに従う。したがって、この実施形態では、プラグインを開くと、そのプラグインのハンドルが作成される。任意の一時点に、プラグインに対してただ１つのｒｅａｄｗｒｉｔｅハンドルを開くことができるが、読み込みについては、同時に複数のハンドルを開くことができる。プラグインは、読み込みおよび書き込みを実行する前に開く必要がある。プラグインを閉じると、そのプラグインのハンドルも閉じる。
プラグインをロケーション・サービスに登録する
入力パラメータ：プラグインＧＵＩＤ、プラグイン名
存在するすべてのプラグインを列挙する
出力パラメータ：ＧＵＩＤ、名前、および型を含むすべてのプラグインのリスト
構成情報を読み込むまたは書き込むためプラグインのハンドルを開く
入力パラメータ：プラグインＧＵＩＤ、読み込み、または書き込み
出力パラメータ：プラグインのハンドル
開いているプラグインからパラメータを読み込む
入力パラメータ：プラグインのハンドル
出力パラメータ：プラグイン/パラメータ、成功または失敗
開いているプラグインにパラメータを書き込む
入力パラメータ：プラグインのハンドル、プラグイン/パラメータ
出力パラメータ：成功または失敗
プラグインのハンドルを閉じる
入力パラメータ：プラグインのハンドル
プラグインをサービスから登録解除する
入力パラメータ：プラグインのハンドル

ＬｏｃＭｇｍｔ ＡＰＩ ４２０の他の機能として、キャッシュ３３４を構成するための以下の機能を備える。プラグインとともに使用するモデルの場合と同様、ＡＰＩはファイル・ハンドル・タイプ・モデルに従うことができる。
構成情報を読み込むまたは書き込むためロケーション・キャッシュへのハンドルを開く
入力パラメータ：読み込みまたは書き込み
出力パラメータ：キャッシュのハンドル
キャッシュからパラメータを読み込む
入力パラメータ：キャッシュのハンドル
出力パラメータ：キャッシュ・パラメータ、成功または失敗
キャッシュにパラメータを書き込む
入力パラメータ：キャッシュのハンドル、キャッシュ・パラメータ
出力パラメータ：成功または失敗
キャッシュのハンドルを閉じる
入力パラメータ：キャッシュのハンドル

ＬｏｃＭｇｍｔ ４２０は、さらに、マスター・リゾルバ３３６を構成するための以下の機能を備える。ＡＰＩは、ファイル・ハンドル・モデルに従うように構成することができる。
構成情報を読み込むまたは書き込むためマスター・リゾルバへのハンドルを開く
入力パラメータ：読み込みまたは書き込み
出力パラメータ：マスター・リゾルバのハンドル
マスター・リゾルバからパラメータを読み込む
入力パラメータ：マスター・リゾルバのハンドル
出力パラメータ：マスター・リゾルバ・パラメータ、成功または失敗
マスター・リゾルバにパラメータを書き込む
入力パラメータ：マスター・リゾルバのハンドル、マスター・リゾルバ・パラメータ
出力パラメータ：成功または失敗
マスター・リゾルバのハンドルを閉じる
入力パラメータ：マスター・リゾルバのハンドル ユーザー定義パラメータ

一実施形態では、ロケーション・サービス２１０は、ユーザー・コンピュータ上に配置され、これは移動できるデバイスでも固定されたデバイスでもよい。ロケーション・サービス２１０がユーザーに関連付けられている場合、ユーザーが関心を持っているロケーションをキャッシュするようにロケーション・サービス２１０を構成することができる。例えば、ユーザーは、ネットワークに接続されると、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙなどのロケーション情報のデータベースにアクセスすることができる。また、ユーザーはローカル・データベースであってもよい。一実施形態では、ロケーション・サービス２１０は、デフォルトのパラメータを使用し、ユーザーはサービスのパラメータを変更することを選択することもできる。

より具体的には、ユーザーが、リゾルバ・プラグイン４０８またはプロバイダ・プラグイン４０２の信頼性などの、ロケーション・サービス２１０のパラメータを変更することを選択した場合である。それとは別に、統計解析を使用して異なるプロバイダ３１０およびリゾルバ４０８の時間の経過によって変わる精度を調べるフィードバック制御システムなどの学習アルゴリズムを使用するように構成することができる。ロケーション・サービス２１０の構成に応じて、さまざまなプラグインに固有のバイアスが設定されたり、精度、ユーザー設定および応答時間に基づいて、プラグインからの情報をロケーション・サービス２１０が優先順位付けしたりすることができる。

一実施形態では、ロケーション・サービス２１０は、個々の情報を個々のアプリケーションに出力するように構成することができる。例えば、センサ特有の情報のみを受信するようにアプリケーションを構成することができる。

セキュリティ
他の実施形態は、ロケーション・サービス２１０などのロケーション・アウェア・サービスのセキュリティに向けられる。具体的には、ロケーション・サービス２１０は、セキュリティ問題を回避または対処するための構成および関連するプログラミングを含むことができる。

背景技術の説明として、本明細書で使用する「スプーフィング（spoofing）」は、データの送信者が実際にはそうではない人であると信じ込ませるようにデータの受信者を騙す行為を指す。一具体例として、プラグイン自体の取得元（source）がスプーフィングされ、プラグインが受信するデータの個々のパケットがスプーフィングされる可能性がある。本明細書で使用する「改ざんすること（Tampering）」は、受信者によって受信されたデータを変更する行為を指す。プラグインによって受信されたデータは、無線接続または有線接続で「ハッカー」により改ざんされるおそれがある。本明細書で使用する「否認（Repudiation）」は、送信者が、データが送信されたことを後から否認する出来事を指す。したがって、発信元（source）が、その発信元に関連付けられた、その後に否認されたデータをプラグインに与えることがある。本明細書で使用する「情報開示」は、意図されたものでない当事者に情報を開示する行為を指す。したがって、発信元は、プラグインによって実行されるクエリに基づいて、ユーザーのロケーションを追跡することができる。発信元は、ユーザーのロケーション情報またはプラグインによって実行されるクエリを他の発信元に転送することができる。ユーザーによって保存されたロケーションは、他のユーザーからアクセスされる可能性がある。

本明細書で使用する「サービス拒否（Denial of service）」は、正当なエンティティがロケーション・サービス２１０などのサービスを使用することを妨げることを指す。例えば、アプリケーションは、情報を求める複数の要求によりロケーション・サービス２１０に負担をかけすぎる場合がある。アプリケーション２２０に負担をかけすぎる可能性がある場合として、ロケーション・サービス２１０をロケーション変更に対して通知されるように複数の登録をすること、ユーザーが適切な量を超えたロケーションを保存すること、プラグインがロケーション・サービス２１０をデータ攻めにすること、ハッカーがプラグインに送信するデータをコピーし、連続してそのデータをプラグインに送りつけることであり、要するに、プラグインとロケーション・サービス２１０を攻め立てる場合である。

本明細書では、「特権の昇格」は、攻撃者が他のユーザーの特権でコマンドを実行することを指す。「バッファ・オーバーフロー」が生じると、実行可能コマンドによりおかしくなったプラグインによって取得されたデータはサービスと同じ特権で実行される。新しいプラグインは、故意にまたは偶然に、旧プラグインを上書きする可能性がある。

ロケーション・サービス２１０は、ユーザーのロケーション情報へのアクセスを保護するように構成される。ロケーション情報は個人情報とみなされ、各実施形態では信頼できないパーティに情報が開示されるのを防止する。

本明細書の各実施形態では、ロケーション情報の発信元、ルックアップ・サービス、ユーザー入力、アプリケーションＡＰＩ、およびプラグインとのインターフェースを含む、攻撃者の５つの侵入点に対応している。

ロケーション情報の発信元を保護することに関して、ロケーション情報の発信元はロケーション情報をプロバイダに提供するエンティティである。発信元としては、例えば、ＧＰＳ、８０２．１１、ＧＰＲＳ、およびＮＬＡがある。

ロケーション・サービス２１０は、ロケーション情報の多数の発信元をプル（獲得）し、ユーザーが発信元の信頼度を調整できるように、拡張可能である。

さらに、ロケーション・サービス２１０は、Ｗｉｎｄｏｗｓ（登録商標）．Ｎｅｔプラットフォーム内の保護されたサービスとすることができ、これにより、安定性が得られる。

ロケーション・サービス２１０は、セキュリティ問題を解決するためにプロバイダがそのデータを暗号化することを可能にするだけでなく、許可をアプリケーション・ドメインに委譲することを可能にして、例えば、サード・パーティのプラグインが、ネットワーク・アクセス環境にないアプリケーション・ドメインで実行することができるようにする。このようなアプリケーション・ドメインは、Ｍｉｃｒｏｓｏｆｔの．Ｎｅｔ Ｃｏｍｍｏｎ Ｌａｎｇｕａｇｅ Ｒｕｎｔｉｍｅ（ＣＬＲ）を使用して作成することができ、これは、共用型システム、中間言語および動的実行環境を提供し、複数のソース言語を実装できる。

ルックアップ・サービスは、以前のプロバイダまたはリゾルバ情報に基づいてより多くのロケーション情報を取得するために、リゾルバが使用するサービスである。ＭａｐＰｏｉｎｔ、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ、およびＷｉｎＦＳは、ロケーション情報に対する２つの主要なルックアップ機能となる。

ロケーション・サービス２１０は、エンドをサポートする汎用的なＷｅｂサービス・リゾルバを備える。具体的には、一実施形態では、ロケーション・サービス２１０は、Ｗｉｎｄｏｗｓ Ｐｒｉｖａｃｙ Ｐｌａｔｆｏｒｍ（ＷＰＰ）と情報をやり取りするように構成される。ＷＰＰは、開発者が、アプリケーション、Ｗｅｂページ、またはサービスの呼び出しに使用されるユーザー情報に関して通知と選択の機能を提供することを可能にする技術フレームワークである。ＷＰＰは、オペレーティング・システム上で分散施行システム（distributed enforcement system）のコア・コンポーネントとして実装することができ、Ｗａｔｓｏｎ（登録商標）、サービス品質管理（ＳＱＭ）、Ｆｕｓｉｏｎ（登録商標）、およびプライバシーに影響を及ぼす恐れのある操作を継続する前にユーザー設定を検証するためのネットワーキング層などのシステム・コンポーネント用の情報提供メカニズム（informant mechanisms）を提供する。このポリシー／同意管理のコア・フレームワークは、オペレーティング・システムのさまざまな場所からユーザー履歴を削除するため追加コンポーネント・モデルにより強化される。このコア・プログラミング層（core programmatic layer）の上で、ＷＰＰは、ユーザーの同意を得て、プライバシー通知のための一貫したユーザー・インターフェース構造の集まりを備え、機械可読プライバシー・スキーマ（machine-readable privacy schemas）で表されたプライバシー・ステートメント（privacy statements）を作成する。このように、一実施形態では、ＷＰＰは、バックエンドのプライバシー・ポリシーの取得と、ユーザー設定との比較とを行えるように、実装することができる。コンフリクトがあると、同意ユーザー・インターフェースが現れてユーザーに警告する。コンフリクトがある場合に、ユーザーに警告するため同意ユーザー・インターフェースがポップアップするように構成することができる。それ以降、ユーザーはＷｅｂサービスの例外を設定することを選択できる。

一実施形態では、ロケーション・サービス２１０は、ＷＰＰを使用して、リゾルバのプライバシー・ポリシーを取得してユーザー設定と比較する。コンフリクトがあると、同意ユーザー・インターフェースが現れてユーザーに警告する。ユーザーは、リゾルバの例外を設定することを選択できる。一実施形態では、ＣＬＲフレームワークは、リゾルバを安全に識別するように構成される。

ロケーション・サービス２１０は、サービスをセキュリティ攻撃から守るロケーション・サービス２１０により制御される中央集中管理キャッシュ３３２を備えている。さらに、ロケーション・サービス２１０は、ユーザーの現在のロケーションの完全なコンテクストを取得するリゾルバを拒否するように構成することができる。

ロケーション・サービス２１０は、ロケーション・オブジェクトが変更されたとき、およびその変更者、ロケーション・ユーザーＡＰＩ ４１８およびロケーション通知ＡＰＩ ４１６およびＡＰＩによって使用される他のアプリケーションが使用されたときおよびその使用者、およびプロバイダとリゾルバがロケーション情報を供給したとき、を記録するように構成することができる。これにより、ある程度のセキュリティ攻撃からロケーション・サービスを保護する。

ロケーション・サービス２１０は、ＷＰＰを操作してアプリケーションのプライバシー・ポリシーを取得し、それらをユーザー設定と比較するように構成することができる。コンフリクトがあると、同意ユーザー・インターフェースがユーザーに警告することがある。それ以降、ユーザーは例外を設定することを選択できる。ＣＬＲは、アプリケーションを安全に識別するために使用できる。一実施形態では、マシンの管理者のみがロケーション・サービス２１０にアプリケーションを登録または登録解除することを許されている。さらに、ロケーション・サービス２１０は、どのアプリケーションがロケーション情報を使用するかについての診断を容易にするように構成することができる。

一実施形態では、ロケーション・サービス２１０に関連付けられたるプラグインが、受信されたメッセージをカウントするように構成される。特定の時間フレーム内で受信されたメッセージが大きすぎる場合、メッセージのリスニング（listening）を停止するようにプラグインを構成できる。ランダムに設定された時間の経過後、プラグインはメッセージのリスニングを再開できる。メッセージの数がそれでも大きすぎる場合、プラグインは指数関数的バックオフ（exponential back off）を実行することができる。特に、プラグイン・マネージャ３３８に関して上で説明したように、各プラグインは同様の抑制（check）と均衡を持つように構成することができる。また、プラグインは、受け取った情報をチェックし、その情報に、実行可能コードを形成するために使用できる特別なキャラクタが含まれているか調べるように構成することもできる。

ロケーション・サービス２１０のセキュリティ機能は、さらに、アプリケーション２２０に適合されている機能を備えることもできる。例えば、ロケーション・サービス２１０は、現在のロケーションについてアプリケーション側で実行できる要求の数に関する絞りを備えるように、また通知の登録を行えるように構成することができる。さらに、不正ユーザーがサービス・パラメータの変更すること、および他のユーザーのプロファイル情報の読み書きをしたりまたは使用したりすることだけでなく、他のユーザーによって格納されているロケーションの読み書きすることまたは使用すること、も防止するように、ユーザー・アクセス制御リストを追加されたデータ構造として保持することができる。

本発明の原理を適用することができる、考え得る多くの実施形態に鑑みて、図面に関して本明細書で説明した実施形態は説明のみを目的としており、本発明の範囲を制限するものとしてみなすべきではないことは理解されるであろう。例えば、当業者であれば、ソフトウェアで示されている説明した実施形態の要素は、ハードウェアで実装することができるが、その逆も可能であること、あるいは説明した実施形態は、本発明の精神から逸脱することなくその配置および詳細を修正できることを理解するであろう。したがって、本明細書で説明した発明は、請求項およびそれと同等の条項の範囲内に納められるようなすべての実施形態を対象としている。

本発明が配置されるコンピュータ・システム例の概要を説明するブロック図である。 本発明の一実施形態によるロケーション・アウェア（location aware）アーキテクチャ例のブロック図である。 本発明の一実施形態によるロケーション・アウェア・アーキテクチャ内のロケーション・サービスのブロック図である。 本発明の一実施形態によるアプリケーション・プログラミング・インターフェースを備えるロケーション・アウェア・システムの接続例を示すブロック図である。 本発明の一実施形態による方法を説明する流れ図である。 本発明の一実施形態による方法を説明する流れ図である。 本発明の一実施形態によるロケーション・サービス内の方法の概要を説明する流れ図である。 本発明の一実施形態によるマスター・リゾルバ（master resolver）を説明する流れ図である。 本発明の一実施形態によるプラグイン・マネージャの流れ図である。 本発明の一実施形態によりプロバイダと情報をやりとりするプラグイン・マネージャの状態遷移図である。 本発明の一実施形態によるプラグイン・マネージャの状態図である。 本発明の一実施形態による方法を説明する流れ図である。 本発明の一実施形態による方法を説明する流れ図である。 本発明の一実施形態によるプロバイダ例の方法を説明する流れ図である。

符号の説明

１００ コンピューティング・システム環境
１００ オペレーティング環境例
１１０ コンピュータ
１２０ 処理装置
１２１ システム・バス
１３０ システム・メモリ
１３１ 読み取り専用メモリ（ＲＯＭ）
１３２ ランダム・アクセス・メモリ（ＲＡＭ）
１３３ 基本入出力システム
１３４ オペレーティング・システム
１３５ アプリケーション・プログラム
１３６ プログラム・モジュール
１３７ プログラム・データ
１４０ インターフェース
１４１ ハードディスク・ドライブ
１４４ オペレーティング・システム
１４５ アプリケーション・プログラム
１４６ プログラム・モジュール
１４７ プログラム・データ
１５１ 磁気ディスク・ドライブ
１５２ 取り外し可能な不揮発性磁気ディスク
１５５ 光ディスク・ドライブ
１５６ 取り外し可能な不揮発性光ディスク
１６０ ユーザー入力インターフェース
１６１ ポインティング・デバイス
１６２ キー・ボード
１６３ マイク
１６４ 電子デジタイザ
１７１ ローカル・エリア・ネットワーク（ＬＡＮ）
１７２ モデム
１７３ ワイド・エリア・ネットワーク（ＷＡＮ）
１８０ リモート・コンピュータ
１８１ メモリ記憶デバイス
１９０ ビデオ・インターフェース
１９１ モニタ
１９４ 出力周辺インターフェース
１９６ プリンタ
１９７ スピーカ
２１０ ロケーション・サービス
２１２ ユーザー・モード・サービス
２１４ デバイス／コンピュータ
２１５ カーネル・モード
２１６ ハードウェア
２２０ アプリケーション
２２２ ドライバ
２２４ Ｗｉｎｄｏｗｓ（登録商標）ファイル・システム・コンポーネント
２２６ ハードウェア・デバイス
２３０ メモリ・デバイス
２４０ デバイス
２５０ ライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）
２６０ Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ
２８０ 外部のデバイス／クライアント
２７０ 存在サーバ
３１０ プロバイダ
３１０” プロバイダ・プラグイン
３２０ リゾルバ
３３０ ロケーション管理コンポーネント
３３２ ユーザー・エージェント
３３４ キャッシュ
３３６ マスター・リゾルバ
３３８ プラグイン・マネージャ
３３９ マスター・リゾルバ
３４０ ｆｕｓｅｒエンジン
３５０ ロケーション・アプリケーション・プログラミング・インターフェース（ＡＰＩ）
３６０ Ｗｉｎｄｏｗｓ（登録商標）ファイル・システム・・コンポーネント
４０２ プロバイダ
４０４ ロケーション・プロバイダＡＰＩ
４０８（１） ユーザー／Ｗｉｎｄｏｗｓ（登録商標）データベース
４０８（２） ロケーション・リゾルバのＡｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ
４０８（３） ロケーション・リゾルバのＭａｐＰｏｉｎｔ（登録商標）
４１４ ロケーション・リゾルバＡＰＩ
４１６ ロケーション通知ＡＰＩ
４１８ ロケーション・ユーザーＡＰＩ
４１９ ユーザー通知ＡＰＩ ＬｏｃＵｓｒ
４２０ ロケーション管理ＡＰＩ
４５０ ＷｉｎＦＳ ＳＱＬサーバ
４６０ 通知サービス
５９１ 決定ブロック
７０２ マスター・リゾルバ
７０６ ロケーション・レポート
７０８ 古くなったレポート
８００ 状態機械
８０４ 初期化
８０６ ノード
８００ 状態機械

Claims (42)

1. コンピュータに実装されるサービスを動作させる方法であって、
   コンピューティング・デバイスのロケーション・コンテクストの要求を受信すること、
   １つまたは複数のロケーション検出デバイスから現在のロケーションに関連するデータを取得すること、
   前記取得されたデータに少なくとも１つのプロセスを適用することにより、前記現在のロケーションに関する不整合性に対して前記取得されたデータを調整すること、および
   １つまたは複数のアプリケーションからアクセス可能なロケーション・オブジェクトを生成すること
   を備え、前記ロケーション・オブジェクトは前記コンピューティング・デバイスの調整されたロケーション・コンテクストを含むことを特徴とする方法。
2. 前記プロセスは、階層的、メトリック、文字列連結、ユニオン、論理積、不確定性処理、および不整合性解決の各プロセスのうちの１つまたは複数であることを特徴とする請求項１に記載の方法。
3. 前記取得されたデータを受信することに対する応答として、所定のメトリックに応じて前記取得されたデータを、前記取得されたデータの解決に利用でき、解決することが可能な１つまたは複数のリゾルバに送信すること、をさらに備えることを特徴とする請求項１に記載の方法。
4. 前記調整されたロケーション・コンテクストは、ロケーション・オブジェクトにカプセル化されていることを特徴とする請求項１に記載の方法。
5. 生成されたロケーション・オブジェクトを受信することに対する応答として、前記アプリケーションに関連付けられたロケーションの登録に応じて、前記ロケーション・オブジェクトを前記アプリケーションに送信することをさらに備えることを特徴とする請求項１に記載の方法。
6. 前記取得されたデータの信頼度に応じて、前記取得されたデータに優先度を割り当てることをさらに備えることを特徴とする請求項１に記載の方法。
7. 前記信頼度は、ユーザーによって割り当てられることを特徴とする請求項６に記載の方法。
8. 前記信頼度は、前記取得されたデータがセキュリティ保護された電子署名を含むか否かを決定することにより、割り当てられることを特徴とする請求項６に記載の方法。
9. ロケーション・コンテクストの要求を受信することは、通知コンポーネントでロケーション識別子を受信することを含むことを特徴とする請求項１に記載の方法。
10. 前記１つまたは複数のロケーション検出プロバイダは、８０２．１１タイプのプロバイダ、ネットワーク・ロケーション・アウェアネス（ＮＬＡ）プロバイダ、グローバル・ポジショニング・サービス（ＧＰＳ）プロバイダ、ジェネラル・パケット・ラジオ・サービス（ＧＰＲＳ）プロバイダ・データ、およびＢｌｕｅｔｏｏｔｈプロバイダの少なくとも１つを含むことを特徴とする請求項１に記載の方法。
11. 前記取得されたデータを前記調整することは、１つまたは複数の統計的プロセスを前記取得されたデータに適用し、最もあり得そうなロケーション・コンテクストを決定することを含むことを特徴とする請求項１に記載の方法。
12. 前記統計的プロセスは、考えられるロケーション・コンテクストの重み付き平均をとることを含むことを特徴とする請求項１１に記載の方法。
13. 前記ロケーション・オブジェクトは、前記コンピュータに実装されたサービス内のｆｕｓｅｒエンジンにより生成されることを特徴とする請求項１に記載の方法。
14. ロケーション・データを送り届けるように構成されているロケーション管理コンポーネントと、
    前記ロケーション管理コンポーネントに結合され、前記ロケーション・データから生成された１つまたは複数のロケーション・レポートを受信し、前記ロケーション・レポート間のコンフリクトを解決し、ロケーション・オブジェクトを生成するように構成されているｆｕｓｅｒエンジンと、
    前記ロケーション管理コンポーネントに結合された１つまたは複数のロケーション・アプリケーション・プログラミング・インターフェース（ＡＰＩ）であって、少なくとも１つは、前記ｆｕｓｅｒエンジンから前記ロケーション・オブジェクトをアプリケーションに送信するように構成されたロケーション・アプリケーション・プログラミング・インターフェースと
    を備え、前記ロケーション・オブジェクトは、前記サービスを実行しているコンピュータのロケーション・コンテクストを前記アプリケーションに動的に供給するように構成されていることを特徴とするサービス。
15. 前記ロケーションＡＰＩの少なくとも１つは、生ロケーション・データのプロバイダから前記ロケーション・データを受信するように構成されている少なくとも１つのプロバイダ・プラグインに結合され、前記プロバイダ・プラグインは、前記生ロケーション・データを正規化するように構成されていることを特徴とする請求項１４に記載のサービス。
16. 前記ロケーションＡＰＩは、前記サービスを実行している前記コンピュータの前記ロケーション・コンテクストに対して、前記アプリケーションがクエリを実行することを可能とするように構成されている少なくとも１つのロケーションＡＰＩを含むことを特徴とする請求項１４に記載のサービス。
17. 前記ロケーションＡＰＩは、プラグインにより実装された機能を指定し、前記サービスに登録するように構成されている少なくとも１つのロケーションＡＰＩを含むことを特徴とする請求項１４に記載のサービス。
18. 前記ロケーションＡＰＩは、前記ｆｕｓｅｒエンジン、ロケーション・キャッシュ、プラグイン・マネージャ、およびマスター・リゾルバのうちの１つまたは複数から前記ロケーション・データを受信するように構成されている少なくとも１つのロケーションＡＰＩを含み、前記ロケーションＡＰＩは、前記アプリケーションに前記ロケーション・データを渡すように構成されていることを特徴とする請求項１４に記載のサービス。
19. 前記ロケーションＡＰＩは、前記サービスのパラメータが構成されることを可能にするように構成されている少なくとも１つのロケーションＡＰＩを含むことを特徴とする請求項１４に記載のサービス。
20. 前記ロケーションＡＰＩは、前記サービスに対するプラグインの追加および削除を行えるように構成されている少なくとも１つのロケーションＡＰＩを含むことを特徴とする請求項１４に記載のサービス。
21. 前記ロケーションＡＰＩは、前記アプリケーションが、前記サービスを実行している前記コンピュータの前記ロケーション・コンテクストが変更された際の通知を、登録することを可能にするように構成されている少なくとも１つのロケーションＡＰＩを含むことを特徴とする請求項１４に記載のサービス。
22. 前記ロケーションＡＰＩは、少なくとも１つのプラグインとの間で前記ロケーション・データを送受信できるように構成されている少なくとも１つのロケーションＡＰＩを含み、前記プラグインは、前記ロケーション・データに基づき、また推定されるコンテクストデータに基づくリッチ・コンテンツを追加するように構成されていることを特徴とする請求項１４に記載のサービス。
23. 前記プラグインは、ユーザー定義のデフォルト・プラグインであることを特徴とする請求項２２に記載のサービス。
24. 前記ロケーション管理コンポーネントは、
    前記ロケーション情報を送り届けるように構成されているプラグイン・マネージャと、
    前記プラグイン・マネージャに結合され、前記ロケーション情報に適している１つまたは複数のリゾルバに前記ロケーション情報を割り当てるように構成されているマスター・リゾルバと
    を備えることを特徴とする請求項１４に記載のサービス。
25. 動的ロケーション情報をアプリケーション・プログラムに供給する方法であって、
    前記アプリケーション・プログラムから、ロケーション・コンテクスト・データの要求を受信すること、
    １つまたは複数のプロバイダからロケーション・コンテクスト・データを動的に収集すること、
    不整合性を解決するために統計関数により前記ロケーション・コンテクスト・データを調整すること、および
    前記アプリケーション・プログラムに、解決されたロケーション・コンテクスト・データを送信すること
    を備えることを特徴とする方法。
26. 前記統計関数は、最良推定関数であることを特徴とする請求項２５に記載の方法。
27. ロケーション・コンテクスト・データの前記動的に収集することは、前記ロケーション・コンテクスト・データを収集うるように構成され、および調整するために前記ロケーション・コンテクスト・データを分配するように構成されているロケーション管理コンポーネントによって実行されることを特徴とする請求項２５に記載の方法。
28. 前記ロケーション管理コンポーネントは、１つまたは複数のプロバイダおよび１つまたは複数のリゾルバからロケーション・コンテクスト・データを受信するように構成されていることを特徴とする請求項２７に記載の方法。
29. 前記プロバイダは、生のロケーション情報を、１つまたは複数のアクセス・ポイントおよび前記アクセス・ポイントに関連付けられている信号強度を含む無線ロケーション・データを格納している前記ロケーション管理コンポーネントに、伝達するプラグインを含むことを特徴とする請求項２８に記載の方法。
30. 前記プロバイダは、８０２．１１タイプのプロバイダ・データ、ネットワーク・ロケーション・アウェアネス・プロバイダ・データ、ＧＰＳプロバイダ・データ、ＧＰＲＳプロバイダ・データ、Ｂｌｕｅｔｏｏｔｈプロバイダ・データ、およびＡｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙデータのうちの１つまたは複数を含む前記ロケーション管理コンポーネントに生のロケーション情報を伝達するプラグインを含むことを特徴とする請求項２８に記載の方法。
31. 前記Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙデータは、アクセス・ポイントの１つまたは複数のロケーションを識別する媒体アクセス制御（ＭＡＣ）アドレスを含むことを特徴とする請求項３０に記載の方法。
32. 前記ロケーション・コンテクスト・データを、前記ロケーション・コンテクスト・データ、ユーザー固有データ、およびアプリケーション指定データの履歴の少なくとも１つを保持するように構成されているデータベースに格納することを、さらに含むことを特徴とする請求項２５に記載の方法。
33. 前記ロケーション・コンテクスト・データは、
    センサ固有デバイスからプロバイダにすでに送信されているデバイス固有のロケーション情報と、
    サービスからリゾルバにすでに送信されている発信元固有の情報と、
    前記サービスにより内部的に使用されるロケーション情報と、
    を含むことを特徴とする請求項２５に記載の方法。
34. コンピュータ・システムのロケーション・コンテクストのアウェアネスを使用可能にするコンピュータ実行可能命令を格納するコンピュータ可読媒体であって、前記コンピュータ実行可能命令は、
    前記コンピューティング・デバイスのロケーション・コンテクストの要求を受信すること、
    １つまたは複数のロケーション検出デバイスから現在のロケーションに関連するデータを取得すること、
    前記取得されたデータに不整合がないか調べて調整すること、および
    １つまたは複数のアプリケーションからアクセス可能なロケーション・オブジェクトであって、前記コンピューティング・デバイスの調整されたロケーション・コンテクストを含むロケーション・オブジェクトを生成する動作を実行すること
    を備える動作を実行することを特徴とするコンピュータ可読媒体。
35. 互換性のない複数のプロトコルに従う複数のロケーション・プロバイダの少なくとも１つから受信したデータからリッチ・ロケーション・コンテクスト・レポートを生成する方法であって、
    前記ロケーション・プロバイダの１つまたは複数からロケーション・レポートの集まりが利用可能であることの通知を受け取った後、前記ロケーション・レポートの集まりを取り出すこと、
    前記ロケーション・レポートの集まりに含まれるロケーション・レポート毎に、リゾルバが前記ロケーション・レポートを解釈可能か否か、そのために利用可能か否か、所定の反復回数を超えていないか否かを決定すること、
    リゾルバが解釈可能で、使用可能であり、所定の反復回数を超えていない場合、前記ロケーション・レポートを前記リゾルバに送信すること、
    前記互換性のないプロトコルに関連付けられた１つまたは複数のリッチ・ロケーション・レポートを１つまたは複数のリゾルバから受信すること、
    前記リッチ・ロケーション・レポートを、標準化されたデータ構造に従う各ロケーション・レポートが含まれるリッチ・ロケーション・レポートの前記集まりに、まとめること、および
    前記リッチ・ロケーション・レポートの前記集まりをｆｕｓｅｒエンジンに送信すること
    を備えることを特徴とする方法。
36. 前記ｆｕｓｅｒエンジンからロケーション・オブジェクトを受信すること、および
    前記リッチ・ロケーション・レポートの集まりを通知サービスに書き込むこと
    をさらに備えることを特徴とする請求項３５に記載の方法。
37. 前記通知サービスはファイル・システム内に配置されていることを特徴とする請求項３６に記載の方法。
38. 前記所定の時間および前記所定の反復回数のうちの１つまたは複数は、ユーザー・インターフェースを介してユーザー側で構成可能であることを特徴とする請求項３５に記載の方法。
39. コンピュータ・システムのロケーション・コンテクストの複数の非互換プロトコル・アウェアネスに従う複数のロケーション・プロバイダのうちの少なくとも１つから受信したデータから、リッチ・ロケーション・コンテクスト・レポートを生成することを可能にするコンピュータ実行可能命令を格納するコンピュータ可読媒体であって、前記コンピュータ実行可能命令は、
    前記ロケーション・プロバイダの１つまたは複数からロケーション・レポートの集まりが利用可能であることの通知を受け取った後、前記ロケーション・レポートの集まりを取り出すこと、
    前記ロケーション・レポートの集まりに含まれるロケーション・レポート毎に、リゾルバが前記ロケーション・レポートを解釈可能か否か、そのために利用可能か否か、所定の反復回数を超えていないか否かを決定すること、
    リゾルバが解釈可能で、使用可能であり、所定の反復回数を超えていない場合、前記ロケーション・レポートを前記リゾルバに送信すること、
    前記互換性のないプロトコルに関連付けられた１つまたは複数のリッチ・ロケーション・レポートを１つまたは複数のリゾルバから受信すること、
    前記リッチ・ロケーション・レポートを、標準化されたデータ構造に従う各ロケーション・レポートが含まれる一組のリッチ・ロケーション・レポートに、まとめること、および
    前記リッチ・ロケーション・レポートの集まりをｆｕｓｅｒエンジンに送信すること
    を備える動作を実行することを特徴とするコンピュータ可読媒体。
40. 前記動作は、
    前記ｆｕｓｅｒエンジンからロケーション・オブジェクトを受信すること、および
    前記ロケーション・オブジェクトが１つまたは複数のアプリケーションから利用できることを通知ディスパッチャに通知すること
    をさらに備えることを特徴とする請求項３９に記載のコンピュータ可読媒体。
41. 前記動作は、所定の時間が経過した後に、前記リッチ・ロケーション・レポートを前記ｆｕｓｅｒエンジンに送信することをさらに備えることを特徴とする請求項３９に記載のコンピュータ可読媒体。
42. 前記所定の時間および前記所定の反復回数の１つまたは複数は、ユーザー・インターフェースを介してユーザー側で構成可能であることを特徴とする請求項４１に記載の方法。
    

Images