JP2015507789A - コンテキスト信号に関して返される情報の精度の向上 - Google Patents

Abstract

本開示は、受信されたコンテキスト・データに関して少なくとも１つのデータ・ソースによって提供されるコンテキストベースの情報の精度を高めるテクノロジーを対象としている。ルック・アップされたコンテキストベースの情報の使用に関連付けて受信された正確さ情報が、ログに記録される。データ・ソースを修正することによって、および／または正確さ情報を介して特定された複数のデータ・ソースの間から正確である可能性が最も高い部分（セグメント）を含むブレンドされたデータ・ソースを作成することによって、全体的な精度を高めるために正確さ情報が処理されることが可能である。

Description

本発明は、概して、多数のユーザ入力要求のコンテクスチュアル信号（コンテキスト・データ）をデータ・ソースとともに正規化するテクノロジーに関する。

ユーザは、ソフトウェア・システムによって使用される前に正規化されることがしばしば必要であるコンテクスチュアル信号を生成する。例としては、ＩＰ（インターネット・プロトコル）アドレス、Ｗｉ−Ｆｉ信号、およびセル・タワー情報が含まれ、これらは、いくつかのソフトウェア・システムによって使用されるためには、それらのシステムが、ＧＰＳロケーションへと、または都市、州、国のタプル（など）へと変換しておく必要がある。別の例としては、天気予報アプリケーションが含まれ、これは、ユーザのＧＰＳロケーションを与えられていることに基づいている。さらに別の例は、逆引き電話帳サービスであり、この場合、電話番号を与えられると、このサービスは、その番号の持ち主に関する情報（たとえば、名前および住所）を返す。

ロケーションベースのシナリオおよび他のこうしたシナリオにおいては、要求されている情報を提供することができる複数のデータ・ソースが存在する場合がある。たとえば、ＩＰアドレスを与えられるとロケーションを提供することができる複数のデータ・ソースが存在し、同様の状況が、Ｗｉ−Ｆｉとセル・タワーとのマッピング情報に関しても存在する。データが集められた方法、およびいつデータが収集されたかに起因して、入力信号および実際のロケーションに関して、これらのソースの間において矛盾するマッピングが存在する場合がある。たとえば、同じＩＰアドレスが、あるデータ・ソース上ではワシントンＤＣにマップしていて、別のデータ・ソース上ではオランダにマップしている場合がある。

ソフトウェア・サービスは、さまざまなタイプのユーザ入力を受け入れるが、こうしたあいまいな信号の正規化は、そのサービスのもとで稼働しているアプリケーションに影響を与える。これは、信号のあいまいさを低減するためのロジックを実施することがそれぞれのアプリケーションにとって困難であるという理由だけでなく、コンテクスチュアル情報がアプリケーションどうしの間において整合している必要があるという理由にも起因する。正規化は通常、大きなマッピング・テーブルを必要とするが、それぞれのこうしたマッピング・テーブルがいかに正確であるかを評価することは、しばしば困難である。たとえば、ＩＰアドレスからロケーションへの変換は、ＩＰアドレスのレンジを都市名、国名などにマップするために大きなルックアップ・テーブルを必要とする。テーブル・フォーマットは比較的シンプルであるが、テーブルのサイズが大きく、それによって、それぞれのＩＰレンジのマッピングが正確であることを確認することは、本質的に非現実的である。

この「発明の概要」は、以降の「発明を実施するための形態」においてさらに説明される代表的なコンセプトの抜粋を、簡略化された形式で紹介するために提供されている。この「発明の概要」は、特許請求される対象事項の主要な特徴または必要不可欠な特徴を特定することを意図されておらず、特許請求される対象事項の範囲を限定することになるいかなる方法で使用されることも意図されていない。

簡潔に言えば、本明細書において説明されている対象事項のさまざまな態様は、受信されたコンテキスト・データから少なくとも１つのデータ・ソースによって提供されるコンテキストベースの情報の精度を、そのコンテキストベースの情報の使用に関連付けて受信される正確さ情報を処理することによって高めるテクノロジーを対象としている。非限定的な一例として、データ・ソースを介してユーザの可能性の高いロケーションをルックアップするために、ＩＰアドレスなどのユーザ・コンテキスト信号が使用されることが可能であり、別のエンティティー（ユーザ・フィードバック、および／または、補足的なロケーション・データを提供する、さらに正確である可能性が高いソースなど）が、正確さ情報を提供することができる。

一態様においては、１つまたは複数のデータ・ソースによって提供されるコンテキストベースの情報は、少なくとも１つのロケーションベースの結果を含む結果セットを提供するために使用されることが可能であるロケーション情報を含むことができる。正確さ情報は、ロケーションベースの結果が正確である可能性が高いかどうかを示す受信されたフィードバックを含むことができる。

一態様においては、ロケーション情報が補足的なロケーション情報と整合しない場合にデータ・ソースを修正することによって、全体的な精度を高めるために正確さ情報が処理されることが可能である。

一態様においては、補足的なロケーション情報に基づいてロケーション情報が不正確であるとわかった場合にデータ・ソースの出力を動的に修正することによって、全体的な精度を高めるために正確さ情報が処理されることが可能である。

一態様においては、データ・ソースどうしの間において複数のカウンターパート・セグメントを提供するためにそれぞれのデータ・ソースを複数のセグメントへとセグメント化することによって、複数のデータ・ソースの全体的な精度が高められることが可能である。それぞれのカウンターパート・セグメントに関する正確さの測定値を特定し、それぞれのカウンターパート・セグメントに関する正確さの測定値に少なくとも部分的に基づいて、カウンターパート・セグメントどうしの間からブレンドされたデータ・ソースに関する選択されるセグメントを選択するために、正確さ情報が処理されることが可能である。

一実施態様においては、サンプリング・サービスが、複数のサンプル要求の少なくともいくつかに関する正確さデータをログに記録し、これにおいて、それぞれのサンプル要求は、コンテキスト・データに関連付けられる。情報がログに記録されるそれぞれのサンプル要求に関して、サンプリング・サービスは、その要求に関連付けられているコンテキスト・データに基づいて１つまたは複数のデータ・ソースにおいてルック・アップされたコンテキストベースの情報に関連した正確さの測定値を、１つまたは複数のデータ・ソース以外の少なくとも１つのエンティティーから得る。ルック・アップされたコンテキストベースの情報に基づいて返された情報の全体的な精度を高めるために、ログに記録されたデータが処理されることが可能である。

その他の利点は、以降の詳細な説明から、図面とともに理解したときに、明らかになり得る。

本発明は、添付の図において、限定ではなく、例として示されており、それらの図においては、同様の参照番号は、類似した要素を示している。
例示的な一実施形態による、ルックアップされたデータの可能性の高い正確さに関するデータをログに記録するように構成されている例示的なコンポーネントを表すブロック図である。 例示的な一実施形態による、ログに記録されるデータに基づいて、どのデータ・ソースのどのカウンターパート・サブセット（セグメント）が最も正確なカウンターパート・サブセット（セグメント）であるかを特定するために、ログに記録されるデータを処理するように構成されている１つまたは複数の例示的なコンポーネントを表すブロック図である。 例示的な一実施形態による、データ・ソースの最も正確なカウンターパート・セグメントが仮想の（または実際の）ブレンドされたデータ・ソースへといかにマージされるかの表示である。 例示的な一実施形態による、データ・ソースを修正するために、ログに記録されるデータを処理するように構成されている１つまたは複数の例示的なコンポーネントを表すブロック図である。 例示的な一実施形態による、ＩＰアドレスベースの（またはその他の）ロケーション・ルックアップ結果に関してログに記録されるユーザ満足フィードバックを収集するための例示的なステップを表す流れ図である。 例示的な一実施形態による、ブレンドされたデータ・ソースを作成する目的で、フィードバックに基づいて、どのデータ・ソース・セグメントが最も正確であるかを特定するために、ログに記録されるユーザ・フィードバックを処理するための例示的なステップを表す流れ図である。 本明細書において説明されているさまざまな実施形態が実施されることが可能である例示的な非限定的なネットワーク化された環境を表すブロック図である。 本明細書において説明されているさまざまな実施形態の１つまたは複数の態様が実施されることが可能である例示的な非限定的なコンピューティング・システムまたはオペレーティング環境を表すブロック図である。

本明細書において説明されているテクノロジーのさまざまな態様は概して、多数のユーザ入力要求のコンテクスチュアル信号（コンテキスト・データ）をデータ・ソースとともに正規化するテクノロジーを対象としている。この目的のため、関連付けられているコンテキスト信号を有する今後の要求のために、返されるデータの精度を改善する目的で、ユーザ要求、およびデータ・ソースからの返された回答に関する正確さの測定が使用される。

たとえば、検索エンジンに対するユーザ・クエリーは、複数の逆引きＩＰアドレス・データベースのうちの１つを使用して、逆引きＩＰアドレス・ルックアップ（ＩＰアドレスから、都市、州、および国を含むロケーションへのマッピング）に基づいて、ロケーションベースの結果が返されるという結果につながる場合がある。この逆引きＩＰアドレス・ルックアップがいかに正確であったかを特定するために、ロケーションベースの結果に伴うユーザ満足の測定、たとえば、返されたロケーションベースの結果をユーザがクリックしたか（満足の可能性が高いということを示している）、または別のクエリーをサブミットしたか（不満の可能性が高いということを示している）が、使用されることが可能である。データ・ソースのうちのそれぞれを、セグメントと呼ばれるサブセットへと分割して、最も高いレベルの測定された正確さ（たとえば、満足）を伴うセグメントをそれぞれのデータ・ソースから選択することによって、さらに高いレベルの精度を伴って今後の要求を返すために、「ブレンドされた」データ・ソースが作成されることが可能である。さらに、今後のルックアップ要求を与えられた際のさらに正確な出力のためにデータ・ソースを修正する目的で、正確さ情報が使用されることが可能である。

本明細書における例のうちのいずれもが非限定的であるということを理解されたい。たとえば、例および説明のうちのいくつかは、概して逆引きＩＰアドレス・ルックアップを対象としているが、利用可能な結果の中に不整合またはエラーの可能性があるいかなる１つもしくは複数のサービスおよび／または１つもしくは複数のデータ・ソースも、本明細書において説明されているテクノロジーから利益を得ることができる。したがって本発明は、本明細書において説明されているいかなる特定の実施形態、態様、コンセプト、構造、機能、または例にも限定されない。むしろ、本明細書において説明されている実施形態、態様、コンセプト、構造、機能、または例のうちのいずれもが非限定的であり、本発明は、一般にさらに正確な結果を計算して提供する際に利益および利点を提供するさまざまな方法で使用されることが可能である。

図１は、例示的な一実施態様におけるさまざまなコンポーネントを示すブロック図である。概して、ユーザ要求１０２は、サービス１０４によって処理され、サービス１０４は、関連するドキュメントへのリンクを得るためにユーザ・クエリーが検索エンジンにサブミットされる場合などに、結果を提供する。理解されるように、サービス１０４は、結果を提供する際にサービス１０４を支援するためのさらなる情報を得る、あるいはそうした情報にアクセスする場合がある。たとえば、サービス１０４は、コンテキスト信号（たとえば、ＩＰアドレス・データ、Ｗｉ−Ｆｉステーション識別子を含む信号などのＷｉ−Ｆｉ関連データ、および／またはセル・タワー関連データ）をルックアップ・サービス１０６に提供して、ルックアップ・サービス１０６がこれら信号を受け取り、該信号を用いてユーザ・ロケーションをルックアップして返すことなどによって、ユーザのロケーションを特定することを試みることができる（ルックアップ・サービス１０６は、サービス１０４とは別個のエンティティーであることが可能であり、またはそうでないことも可能であるということに留意されたい）。さらに特定の例としては、ユーザのＩＰアドレスを与えられると、検索エンジンは、逆引きＩＰアドレス・ルックアップ・サービスからユーザのロケーションを得ることができ、それによって検索エンジンは、返されたユーザのロケーションに基づいて、さらに関連性の高い結果を返すことができる。

一実施態様において、ルックアップ・サービス１０６は、コンテキストベースの情報をルックアップするために複数のデータ・ソースのうちの少なくとも１つにアクセスすることができる。しかしながら、これらのデータ・ソースは、エラーを含んでいる場合があり、ひいては、ルックアップを要求しているアプリケーションまたはサービスは、不正確な情報を受信する場合がある。これらのデータ・ソースは、データ・ソース自体が保持している情報に関してしばしば一貫性がない。たとえば、ＩＰアドレスを与えられると、逆引きＩＰアドレス・ルックアップ・サービスがロケーションを得るために使用する４つのデータ・ソースのうちの３つが正確なロケーション情報を含んでいる一方で、４つめのデータ・ソースが正確なロケーション情報を含んでいない場合があり、ひいては、結果の精度は、そのサービスが所与のクエリーに関してどのデータ・ソースを使用するかに依存する。単にその４つめのデータ・ソースを使用しないことは、つたないソリューションである。なぜなら、別のＩＰアドレスに関しては、その４つめのデータ・ソースが、その他のデータ・ソースと比較して、最も正確な情報を有している可能性があるためである。すべてのそのようなエラーがそれらのデータ・ソースのうちのどこに存在するかは、事前にはわからず、実用的に特定することもできない。

図１において表されているように、要求を行っているユーザに１つまたは複数の結果を返す目的で使用されるデータ・ソースの正確さに関する情報を得るために、受信された要求のうちのいくつかがランダムに（またはその他の形で）サンプリングされることが可能である。したがって、図１の例においては、ユーザ要求１０２は、通常の要求として処理される代わりに、サービス・サンプル・グループ・システム１０８によって選択されるものとして例示されている。

この例において、ユーザ要求１０２は、Ｎ個のサンプル・グループのうちの１つへとグループ化され、この場合、Ｎは、情報が得られることが可能であるデータ・ソースの数を表す。図１の例において、ユーザ要求は、サンプル・グループ１１０_２として実線を介して示されている、Ｎ個のサンプル・グループ（１１０_１〜１１０_Ｎ）のうちの１つに割り振られ、サンプル・グループ１１０_２は、利用可能なデータ・ソース１１２_１〜１１２_Ｎのうちのデータ・ソース１１２_２に対応している。たとえば、ユーザのロケーションを確立するための逆引きＩＰアドレス・ルックアップに関して、一実施態様においては４つのデータ・ソース（Ｎ＝４）が使用される。

この選択されたデータ・ソース１１２_２から得られたルックアップされた結果は、何らかの方法で、返される結果１１４を介してユーザに返されることが可能である。たとえば、検索クエリーを与えられると、検索エンジンは、ユーザのＩＰアドレスを与えられたユーザのロケーションを、４つのデータベースのうちの１つからルックアップし、検索結果をそのロケーションに合わせることができる。この例において、上記４つのデータベースのうちの１つは、選択されたデータ・ソース１１２_２に対応する。さらに特定の例としては、ユーザは、「ピザ」とクエリーする場合があり、返された結果のうちのいくつかは、ユーザのロケーションの近くのピザ・レストランへのドキュメント・リンクに関するものである場合があり、この場合、そのロケーションは、データ・ソース１１２_２を介して実行された逆引きＩＰアドレス・ルックアップから得られたものである。

本明細書において説明されているように、結果１１４の正確さの何らかの測定値が特定され、正確さ測定値１１６を介して図１において表され、類似したユーザ要求に応答して提供されるルックアップおよび／または今後の結果の精度を高めるために使用される。一例として、クエリーに応答して結果が提供された場合には、それらの結果に伴うユーザ満足などのユーザ・フィードバックが測定されることが可能である。フィードバックは、黙示的であることが可能であり、それによって、ユーザ応答またはその他の行動アクション（まったくアクションを取らないことを含む）から推測され、あるいは、たとえば、正確さの何らかの測定値、たとえば、満足または不満をユーザが示す際に用いる１つまたは複数のボタンのセットを介して、明示的であることが可能である。

推測される正確さ測定値のさらに特定の例として、結果のうちのいくつかがロケーションベースであり、ロケーションベースの結果のうちの１つ（たとえば、ピザ・レストラン・リンク）をユーザがクリックした場合、こうしたフィードバックは、ユーザが結果に満足した可能性が高いということ、ひいては、ロケーションは正確であった可能性がより高いということを示している。代わりに、ユーザがリンクをクリックせずに別のクエリーをサブミットした場合、ユーザは不満であった可能性がより高く、ロケーションは不正確であった可能性がより高いということを示している。このフィードバック／正確さ情報は、数千人または数百万人ものユーザから得られた同様の「クラウド由来の」情報とともにログ１１８内に記録されること、およびその後に、それぞれのデータ・ソースがそのＩＰアドレスベースのロケーション情報に関していかに正確であるかを特定するために処理されることが可能である。理解されるように、このテクノロジーは、満足または不満など、ユーザの応答を観察すること、および情報の精度に関する結論を引き出すことを可能にするために、十分な量のユーザ対話入力を有することから利益を得る。

ロケーション・ベースではないリンク、たとえば、ピザの歴史を示す参考ウェブサイトへのリンクをユーザがクリックした場合、ユーザはロケーション関連情報を求めていなかった可能性が高いため、情報はまったくログに記録されないことが可能である（しかしながら、こうした情報は、他の目的で使用される可能性があり、したがって、ログに記録されることも可能であるが、たとえば、ＮＵＬＬまたはゼロのロケーション正確さスコアを伴うことが、実現可能である）ということに留意されたい。より精巧なクエリー（たとえば、「ベルビューのピザ」）など、さらなる情報をユーザが提供した場合、そのさらなる情報は、精度を改善するために使用されることも可能であるということにさらに留意されたい。またさらに、応答しないことは、不満の表明（たとえば、ユーザは別の検索エンジンに行ってしまった）として取り扱われることが可能であるが、これは、スコアを付ける際には、不満のさらに確かな表明よりも低い重みを与えられることが可能である。なぜなら、もしかするとユーザは、（電話番号などの）スニペット・テキストからの所望の情報を入手し、したがって、さらなる対話を必要としなかったためである。いずれにしても、十分な数のユーザを与えられれば、ユーザ満足に基づくデータベース（またはその任意の部分）の精度に関する統計上のトレンドが認識されることが可能である。

さらに、満足／不満スコアリング・システムを特定するためのトレーニングおよび他のメカニズムが使用されることが可能である。たとえば、既知の正確な情報にユーザがどのように反応する傾向があるかを確立するために、実際の使用シナリオにおける場合を含む、正確である場合も正確でない場合もある既存のルックアップ・サービスの確認されていない情報とは対照的に、いくらかの量の確認された既知の正確な（グランド・トゥルース）情報が使用されることが可能である。不正確な情報にユーザがどのように応答するかを確立するために、（たとえば、不良な情報を意図的に提供することを避けるためのトレーニングまたはその他のコントロールされたシナリオにおける）既知の不良な情報が返されることが可能である。

図２および図３は、正確さ測定値情報が、いったんログに記録されると、使用されることが可能である１つの一般的な方法を示している。この例において、それぞれのデータ・ソース３１２_Ａ〜３１２_Ｄのうちで最も高い正確さスコアを有する部分（セグメント）に対応する「ブレンドされた」データ・ソース３３０（図３）を作成するためにログ１１８が処理され、この場合、正確さは、測定されたユーザ満足に基づく。概して、比較的多数のユーザから正確さ測定値情報が収集された後、サンプリングされたユーザに割り振られているデータ・ソースの質を評価するために、ユーザ応答のログ１１８が分析される。

この例において、それぞれのデータ・ソースが、セグメントと呼ばれるサブセットへと分割されることに基づいて、ログ１１８が処理され、たとえば、図３において示されているように、データ・ソース３１２_Ａは、セグメントＳ１Ａ〜Ｓ４Ａへと分割され、データ・ソース３１２_Ｂは、セグメントＳ１Ｂ〜Ｓ４Ｂへと分割される、といった具合である。したがって、１つのデータ・ソースのそれぞれのセグメントは、互いのデータ・ソース内にカウンターパート・セグメントを有する。たとえば、ＩＰアドレス・ロケーション・ルックアップ・データ・ソースに関するそれぞれのセグメントは、ＩＰアドレスの１つのレンジに対応することが可能である。図３においては、簡潔にするために、データ・ソースごとに４つのセグメントが示されているが、所与のアプリケーションにとって適切な数として、数十程度、数百程度、数千程度など、データ・ソースごとに任意の数のセグメントがシステムによって確立されることが可能であるということに留意されたい。

データ・ソースのセグメントに関するスコアを計算する際に、セグメント・スコア計算メカニズム２２０（図２）は、データ・ソース・セグメンタ２２２を介して、正確さ測定値（たとえば、ユーザ満足または不満応答）がどのデータ・ソースおよびセグメントに属するかを特定する。一代替実施態様において、固定されたＩＰアドレス・レンジが事前に特定されている場合など、それぞれの応答に関するデータ・ソース・セグメントが事前に特定されることが可能であり、ひいては、データ・ソース・セグメント情報は、ログを処理する時点でＩＰアドレスから特定されるよりもむしろ、ロギングの時点で記録されることが可能であるということに留意されたい。しかしながら、ログを処理する時点でセグメントを特定することは、セグメントが、固定されたレンジである必要はなく、代わりに他のコンセプト、たとえば、セグメントごとに応答の数を均等にすることなどに基づくことが可能であり、それは、ロギングが完了されるまでわからなくてもよい、という点で有利である場合がある。

したがってセグメント化は、固定されたサイズ、または固定されたサイズ以外のコンセプトに基づくことが可能である。たとえば、セグメント化は、応答の数、トラフィックの均等化などに基づくことが可能である。いかなるセグメントも、所望に応じて複数のサブセグメントへと分割されることが可能であり、あるいは、同じデータ・ソース内の場合を含めて、複数のセグメントが結合されて、より大きな１つのセグメントになることが可能である。この実施態様において、それぞれのデータ・ソース内のセグメントどうしの相対的なサイズにかかわらず（たとえば、図３において、セグメントＳ２Ａは、セグメントＳ３Ａとはサイズが異なってよい）、データ・ソースはそれぞれ、データ・ソースどうしの間におけるあらゆるカウンターパート・セグメント（たとえば、３ＳＡ、３ＳＢ、３ＳＣ、および３ＳＤ）が互いに同じサイズであるように一貫して区分されている。

ログに記録されたエントリーが処理される際に、スコア計算メカニズム２２０は、応答データとともにログに記録されている正確さ測定値に基づいて、そのデータ・ソースとセグメントとの組合せに関するスコアを調整する。システムを十分な時間にわたって稼働させ、ユーザの応答に基づいてスコアにおける差を比較することによって、システムは、それぞれのセグメントに関してそれぞれの異なるデータ・ソースの質を判断することができる。スコアリング・メカニズムの一例は、満足応答に関するセグメント・スコアをインクリメントして、不満応答に関するスコアをデクリメントし、それが済んだら、それぞれのセグメントに関するスコアを所望に応じて何らかの方法で、たとえばパーセンテージなどに正規化することである。この方法においては、ログ１１８を処理すると、結果として、複数のセグメント・スコア２２４が、すなわち、セグメントＳ１Ａ〜Ｓ４Ｄに関して示されているスコアを介して図３において表されているようなそれぞれのデータベースのそれぞれのセグメントごとに１つのスコアが得られる。

これらスコアは、本明細書において説明されているように全体的なシステム精度を改善することを含めて、任意の方法で使用されることが可能である。全体的なシステム精度を改善するための１つの簡単な方法は、データ・ソースのうちのそれぞれの間において最も高いスコアを有するカウンターパート・セグメントを選択し、次いで、選択されたセグメントを使用して、ブレンドされたデータ・ソースを構築するブレンディング・メカニズム（アルゴリズム）に基づく。

図２および図３の例において、セグメント・ブレンディング・メカニズム２２６は、セグメント・スコア２２４を使用して、データ・ソース３１２_Ａ〜３１２_Ｄのそれぞれからのフィードバック・スコアに基づいて「最も正確な」セグメントを選択し、この「最も正確な」セグメントは、この例においてはセグメントＳ１Ｃ、Ｓ２Ａ、Ｓ３Ｄ、およびＳ４Ａであり、それぞれのセグメントは、その他のデータ・ソースの間におけるそのカウンターパート・セグメントと比較して、最も高いスコアを有している。その結果が、ブレンドされたセグメント・データ２２８であり、これは、図３のブレンドされたデータ・ソース３３０に対応する。同点の場合、この同点には実際の同点または統計上の同点があり得、セグメントどうしの間において選択を行うために競合解消メカニズム（たとえば、過去のデータを使用すること、最も高い合計スコアを有するデータ・ソースを使用すること、および／またはその他）が使用されることが可能であるということに留意されたい。

説明の目的で、図３は、ブレンドされたデータ・ソース３３０を、ルックアップのさらに正確なオンライン・サービシングのために使用されることが可能である単一のエンティティーとして表しているが、システムは、選択されたセグメントどうしを結合する実際の単一のデータ・ソースを構築する必要はないということがわかる。むしろ、オンライン使用中に、サービスは、ブレンドされたセグメント・データ２２８に基づいてデータ・ソースのうちのどのセグメントを使用するかを動的に選ぶために、選択されたセグメントに対応するマッピングにアクセスすることができる。たとえば、入ってくるＩＰアドレスを仮定すると、このＩＰアドレスは（そのＩＰアドレス・レンジを介して）或るセグメントに対応し、システムは、ブレンドされたセグメント・データ２２８にアクセスして、そのＩＰアドレスを、複数のデータ・ソースの中から選択されたそのレンジに関する最も正確なセグメントにマップし、それによって、その特定のマップされたセグメントからロケーション結果を得る。したがって、ブレンドされたデータ・ソース３３０は、実際の結合された物理的なデータ・ソースではなく、ブレンドされたセグメント・データ２２８などを介して選択された仮想データ・ソースであることが可能である。

この例示的なシナリオにおいて、いったんブレンドされたセグメント・データが得られると、一般にユーザは、その後、仮想の（または場合によっては実際の）ブレンドされたデータ・ソースの利点を与えられるということに留意されたい。しかしながら、精度を再び高めるために、正確さを特定するための（たとえば、ランダムに選択されたユーザのうちのいくらかの小さなパーセンテージの）サンプリングが、任意の時点で継続または再開することが可能である。たとえば、サンプリングは、継続的であることが可能であり、あるいはときおりオンもしくはオフにされることが可能である、といった具合である。サンプリングは、データ・ソースが著しく変更された場合はいつでも、たとえば、更新後に週１回など、新たな正確さデータが必要とされていることを示す何らかの変化に基づくことが可能である。サンプリング・パーセンテージは、１つまたは複数の基準に基づいてなど、増大または低減されることが可能であり、かつ／あるいは時間とともに変化することが可能である。

上述の例は概して、ユーザ満足または不満に基づいてそれぞれのデータ・ソースのどのセグメントが最も正確な情報を提供するかを見つけ出すために複数のデータ・ソースをセグメント化することを対象としたが、正確さを測定して精度を改善するための他の方法が実行されることも可能である。たとえば、正確さは、より正確であることがわかっている他の既知の情報に基づくことが可能である。さらに、上述のように、複数のデータ・ソースが、ログに記録されている情報から利益を得ることができるが、単一のデータ・ソースのみが修正されることさえ可能である。

例として、あるデータ・ソースが、たとえば、どのＷｉ−Ｆｉステーション／アクセス・ポイント（または、この例示的な説明においては、単にアクセス・ポイント）がどこのロケーションにあるかをマップするために、ロケーションとＷｉ−Ｆｉ信号との間におけるマッピングを保持していると考えられたい。したがって、あるエンティティーのロケーションは、使用中のアクセス・ポイントに基づいて特定されることが可能である。しかしながら、ときおりアクセス・ポイントは移動される場合があり、それによって、データ・ソースが更新されなければ、いずれかの以前にマップされたロケーションが正確でなくなる。

検索結果を提供する際に使用されるロケーションを提供するためにアクセス・ポイント・ロケーションが使用される場合、これらの結果に対するユーザの反応は、類似したＩＰアドレスベースのロケーション・ルックアップに関して概して上述したように、格納されているアクセス・ポイント・ロケーションの正確さを特定するための１つの可能な方法である。しかしながら、他の正確さ情報が利用可能である場合がある。たとえば、アクセス・ポイントを介した無線ネットワーキングのためにスマートフォンを使用していて、それによって、アクセス・ポイント・ロケーションがルック・アップされることが可能であるユーザについて考えられたい。何らかのユーザ満足測定値の代わりに（または、それに加えて）、ＧＰＳデータおよび／またはセルラー方式の特定されたロケーション・データ（たとえば、信号強度／三角測量に基づく）を、利用可能な場合に使用して、補足的なロケーションを取得して、データ・ソースの格納されているロケーションが補足的なロケーション・データと対比して正確であるかどうかを確かめることが可能である。データ・ソースは、必ずしも正確であるとは限らないため、コンテキストどうし（たとえば、ロケーションどうし）が矛盾する場合があり、参照により本明細書に援用される米国特許第７，４４４，５９４号が、コンピュータ・ユーザのコンテキスト・データにおける矛盾をとりなすことについて概して説明している。

ユーザ・フィードバックを得るための別の方法は、ユーザがより正確なロケーションを得るために装置（たとえば、スマートフォン）上で自分の設定または他の入力を変更する場合である。たとえば、ロケーションを得るためにＷｉ−Ｆｉアクセス・ポイント・データを使用して、ユーザが「ピザ」に関するクエリーを行い、検索結果を得た後に、そのクエリーを「ピザ９８０４０」（この場合、「９８０４０」は郵便番号を表している）に変更した場合、これは、ロケーションに対するユーザの不満を示すために使用されることができる信号になり得る。

図４において表されているように、１つのソースから得られたこうした修正情報４４０は、修正情報４４０を他のこうした情報とともにログに記録し、別のデータ・ソースを適切な時点で更新することなどによって、別のデータ・ソースを修正するために使用されることが可能である。これは、図４において、データ・ソース更新４４４を提供するデータ・ソース修正メカニズム４４２を介して表されている。

それにもかかわらず、任意のデータ・ソース修正がさらに動的であることが可能である。たとえば、緯度、経度データ・ソースに対するＧＰＳが、特定のロケーションに関して所与の方向においていくらかの距離によってオフであるものとして別のビーコン（たとえば、セルラー・ビーコン）によって検知されると考えられたい。動的な修正データ４４６が、緯度、経度データ・ソースに対するそのＧＰＳの任意の出力に対して、たとえばオフセットとして適用されて、その出力を修正し、今後のルックアップ要求のためにさらに正確なロケーションを提供することが可能である。

図５は、たとえば、検索クエリーに応答してユーザに返されたロケーションベースの結果に関するユーザ・フィードバックを収集することに関連したさまざまな例示的なステップを要約している流れ図であり、ステップ５０２において開始し、ステップ５０２では、ユーザ要求が受信される。ステップ５０４は、この要求をサンプリングするかどうかを決定する。典型的には、ほとんどのユーザ要求は、サンプリングされず、代わりにそれらの要求は、ステップ５０６において、以前に作成されたブレンドされたデータ・ソースを介して（または、本明細書において説明されているように、ブレンドされたデータ・ソースが最初に作成されるまでは、通常の方法で）処理されるということに留意されたい。

本明細書において説明されているように、少なくともいくつかのユーザ要求が、サンプリングのために選択される。その選択は、１００個のユーザ要求ごとに１つなど、任意のスキームに基づくことが可能であり、それによって、サンプリングされたＩＰアドレスは一般に、ランダムに受信される。別の例示的なスキームは、たとえば、それぞれのＩＰアドレス・レンジごとにいくらか等しい数のサンプルを得ることを試みるために、ＩＰアドレス分散に基づくことが可能である。これらおよび他のスキームとともに、選択のための他のメカニズムが使用されることが可能であり、たとえば、米国のロケーションにマップすると思われるＩＰアドレスのみをサンプリングすることなど、サンプリングを検討する前にフィルタリングを実行することが可能である。

サンプリングのために選択されたユーザに関して、ステップ５０８は、そのユーザに関する、データ・ソースのうちの１つに対応する、サンプル・グループを特定する。この選択は、ラウンド・ロビン分散、ランダム分散、または他の任意のスキームによることが可能である。別のスキームの一例としては、サンプル・グループ／データ・ソースの間において合計応答の数のバランスを取るのではなく、（たとえば、ログに記録されているすべての応答が、ロケーションベースのリンクに対応することができるとは限らないため、）ロケーションベースの満足または不満タイプの応答の数のバランスを取るために、所与のサンプル・グループ／データ・ソースに関して、より多くのユーザが選択されることが可能である。

ステップ５１０は、データ・ソースからロケーション情報を入手し、次いでそのロケーション情報は、ステップ５１２において１つまたは複数の結果を返すために使用される。検索に関して、ルック・アップされるロケーション情報が与えられると、返される、ドキュメント、広告などへのリンクのうちのいくつかは、ロケーション・ベースであることが可能である。

ステップ５１４は、返された結果に基づいてユーザからフィードバックを得ることに相当する。ステップ５１６において、データ、たとえば、ユーザのＩＰアドレス（または、可能性として、レンジが固定されている場合には、セグメント）、ユーザが割り振られたデータ・ソース、およびユーザのフィードバックが、ログに記録される。フィードバックは、スコアなど、たとえば、ユーザが満足したことをユーザ応答が示した場合には１、および不満の場合には−１であることが可能であり、その場合には、イベントステップ５１４はさらに、フィードバックを得ることの一部としてスコアなどを特定することに相当する。

ステップ５１８は、固定された数など、望まれるだけ多くのユーザ要求に関して、ログが満杯になるまで、時間ウィンドウに基づいてなど、このプロセスを繰り返す。同じログに、または後で結合される別々のログに書き込みを行っている、並行して機能している多くの同様のプロセスが存在する場合があるということに留意されたい。ステップ５２０は、さらなる処理のために、たとえば、上の図２および図３、ならびに以降の図６を参照して説明されているようにセグメントどうしをブレンドするための分析を実行するためにログを閉じることに相当する。

図６は、例示的なデータ・ソース・ブレンディングを実行するための流れ図の例示的なステップを表しており、ステップ６０２において開始し、ステップ６０２では、ログに記録されているそれぞれのエントリーが、処理のために選択される。ステップ６０４は、ログに記録されているＩＰアドレスからセグメントを特定する。ただし、上述のように、このエントリーに関するセグメントが事前にわかっていて、既にログに記録されている場合は除く。

ステップ６０６は、満足の場合には現在までの合計をインクリメントすること、または不満の場合にはその合計をデクリメントすることなど、フィードバックに基づいてこのエントリーのデータ・ソース・セグメントに関するスコアを調整することに相当する。別のスキームは、応答カウントおよび満足応答のカウントに関する現在までの合計を保持することである。スコアリング・スキームがロギングの一部として実施されなかった場合、ステップ６０６はさらに、スコアリング・スキームを実施すること、たとえば、ログに記録されるユーザ・アクション（クリックもしくは新たなクエリー、または、場合により、他のアクション、もしくはアクションを取らないこと）を、セグメントのスコアを調整するための値へと変換することに相当する。

ステップ６０８は、ログが処理されて、それぞれのデータ・ソースのそれぞれのセグメントに関してスコアが得られるまで、ログ処理を繰り返す。ステップ６１０は、カウンターパート・セグメントどうしの間における等しくない数の関連した応答を考慮するためになど、必要な場合にはスコアを正規化することに相当する。

ステップ６１２は、セグメントどうしを、たとえば仮想上でブレンドして、ブレンドされたセグメント・データにする。この時点で、最初のまたは更新されたブレンドされたソースが、要求を取り扱う際に使用するために利用可能となる。

したがって、理解され得るように、関連付けられているルックアップを含む、返される情報の精度を改善するためのスケーラブルな方法が説明されている。これは、未知の精度を有する、推測されたまたは明示的なクラウド由来のデータを使用する潜在的に競合するデータ・ソースどうしの間をとりなすことを含むことができる。

例示的なネットワーク化され分散された環境
本明細書において説明されているさまざまな実施形態および方法は、コンピュータ・ネットワークの一部として、または分散コンピューティング環境において展開されることが可能であり、かつ任意の種類の１つまたは複数のデータ・ストアに接続されることが可能である任意のコンピュータまたはその他のクライアントもしくはサーバ装置に関連して実施されることが可能であるということを、当業者は理解するであろう。この点について、本明細書において説明されているさまざまな実施形態は、任意の数のメモリ・ユニットまたは記憶装置ユニットを有する任意のコンピュータ・システムまたは環境、ならびに任意の数の記憶装置ユニットにわたって生じる任意の数のアプリケーションおよびプロセスにおいて、実施されることが可能である。このことには、リモート記憶装置またはローカル記憶装置を有する、ネットワーク環境において展開されるサーバ・コンピュータおよびクライアント・コンピュータを伴う環境、または分散コンピューティング環境を含むが、これらに限定されない。

分散コンピューティングは、コンピューティング装置とシステムとの間における通信のやり取りによってコンピュータ・リソースおよびサービスの共有を提供する。これらのリソースおよびサービスは、ファイルなどのオブジェクトのための情報のやり取り、キャッシュ記憶、およびディスク記憶を含む。これらのリソースおよびサービスはさらに、ロード・バランシング、リソースの拡張、処理の特化などのために複数の処理ユニットにわたって処理能力を共有することを含む。分散コンピューティングは、ネットワーク接続性を利用し、クライアントどうしが自分たちの集まったパワーを活用して企業全体に利益をもたらすことを可能にする。この点について、さまざまな装置が、本開示のさまざまな実施形態に関して説明されているようなリソース・マネージメント・メカニズムに関与することができるアプリケーション、オブジェクト、またはリソースを有することができる。

図７は、例示的なネットワーク化されたまたは分散されたコンピューティング環境の概略図を提供する。この分散コンピューティング環境は、コンピューティング・オブジェクト７１０、７１２など、およびコンピューティング・オブジェクトまたは装置７２０、７２２、７２４、７２６、７２８などを含み、これらは、例示的なアプリケーション７３０、７３２、７３４、７３６、７３８によって表されているようなプログラム、方法、データ・ストア、プログラマブル・ロジックなどを含むことができる。コンピューティング・オブジェクト７１０、７１２など、およびコンピューティング・オブジェクトまたは装置７２０、７２２、７２４、７２６、７２８などには、さまざまな装置、たとえば、携帯情報端末（ＰＤＡ）、オーディオ／ビデオ装置、モバイル電話、ＭＰ３プレーヤ、パーソナル・コンピュータ、ラップトップなどを含むことができることを理解されたい。

それぞれのコンピューティング・オブジェクト７１０、７１２など、およびコンピューティング・オブジェクトまたは装置７２０、７２２、７２４、７２６、７２８などは、直接または間接的に通信ネットワーク７４０を経由して１つまたは複数の他のコンピューティング・オブジェクト７１０、７１２など、およびコンピューティング・オブジェクトまたは装置７２０、７２２、７２４、７２６、７２８などと通信することができる。通信ネットワーク７４０は、図７においては単一の要素として示されているが、図７のシステムにサービスを提供する他のコンピューティング・オブジェクトおよびコンピューティング装置を含むことができ、かつ／あるいは、図示されていない複数の相互接続されているネットワークに相当することが可能である。それぞれのコンピューティング・オブジェクト７１０、７１２など、またはコンピューティング・オブジェクトもしくは装置７２０、７２２、７２４、７２６、７２８などは、さらに、ＡＰＩを使用することができるアプリケーション７３０、７３２、７３４、７３６、７３８などのアプリケーション、または、本開示のさまざまな実施形態に従って提供されるアプリケーションとの通信もしくはそうしたアプリケーションの実施に適している他のオブジェクト、ソフトウェア、ファームウェア、および／もしくはハードウェアを含むこともできる。

分散コンピューティング環境をサポートするさまざまなシステム、コンポーネント、およびネットワーク構成が存在する。たとえば、コンピューティング・システムどうしは、有線システムまたは無線システムによって、ローカル・ネットワークまたは広く分散されたネットワークによって、ともに接続されることが可能である。現在、多くのネットワークがインターネットに結合されており、インターネットは、広く分散されたコンピューティングのためのインフラストラクチャーを提供し、多くの異なるネットワークを包含するが、さまざまな実施形態において説明されているようなシステムに付随させられる例示的な通信のために任意のネットワーク・インフラストラクチャーが使用されることが可能である。

したがって、クライアント／サーバ、ピアツーピア、またはハイブリッド・アーキテクチャーなど、多くのネットワーク・トポロジーおよびネットワーク・インフラストラクチャーのホストが活用されることが可能である。「クライアント」は、自分が関連していない別のクラスまたはグループのサービスを使用するクラスまたはグループのメンバーである。クライアントは、別のプログラムまたはプロセスによって提供されるサービスを要求するプロセス、たとえば大まかに言えば、命令またはタスクのセットであることが可能である。クライアント・プロセスは、要求されているサービスを、その他のプログラムまたはそのサービスそのものに関するいかなる機能詳細も「知る」必要なく、活用する。

クライアント／サーバ・アーキテクチャー、特にネットワーク化されたシステムにおいて、クライアントは通常、別のコンピュータ、たとえばサーバによって提供される共有されているネットワーク・リソースにアクセスするコンピュータである。図７の例示において、非限定的な一例として、コンピューティング・オブジェクトまたは装置７２０、７２２、７２４、７２６、７２８などは、クライアントと考えられることが可能であり、コンピューティング・オブジェクト７１０、７１２などは、サーバと考えられることが可能であり、この場合、サーバとして機能するコンピューティング・オブジェクト７１０、７１２などは、クライアント・コンピューティング・オブジェクトまたは装置７２０、７２２、７２４、７２６、７２８などからデータを受信すること、データを格納すること、データを処理すること、クライアント・コンピューティング・オブジェクトまたは装置７２０、７２２、７２４、７２６、７２８などにデータを送信することなどのデータ・サービスを提供するが、状況に応じて、任意のコンピュータが、クライアント、サーバ、またはその両方とみなされることも可能である。

サーバは、典型的には、インターネットまたは無線ネットワーク・インフラストラクチャーなどのリモート・ネットワークまたはローカル・ネットワークを介してアクセス可能なリモート・コンピュータ・システムである。クライアント・プロセスは、第１のコンピュータ・システムにおいてアクティブであることが可能であり、サーバ・プロセスは、第２のコンピュータ・システムにおいてアクティブであることが可能であり、通信媒体を介して互いに通信し、ひいては、分散された機能を提供し、複数のクライアントがサーバの情報収集機能を利用することを可能にする。

通信ネットワーク７４０またはバスがインターネットであるネットワーク環境において、たとえば、コンピューティング・オブジェクト７１０、７１２などは、ウェブ・サーバであることが可能であり、他のコンピューティング・オブジェクトまたは装置７２０、７２２、７２４、７２６、７２８などは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）など、複数の既知のプロトコルのうちの任意のプロトコルを介して、そのウェブ・サーバと通信する。サーバとして機能するコンピューティング・オブジェクト７１０、７１２などは、クライアント、たとえば、コンピューティング・オブジェクトまたは装置７２０、７２２、７２４、７２６、７２８などとして機能することもでき、これは、分散コンピューティング環境の特徴であると言える。

例示的なコンピューティング装置
言及したように、有利なことに、本明細書において説明されている技術は、いかなる装置にも適用されることが可能である。したがって、すべての種類のハンドヘルド、ポータブル、および他のコンピューティング装置およびコンピューティング・オブジェクトは、さまざまな実施形態と関連した使用を想定されているということを理解されたい。したがって、以降の図８において説明されている下記の汎用リモート・コンピュータは、コンピューティング装置の一例にすぎない。

実施形態は部分的に、装置またはオブジェクトのためのサービスの開発者による使用のためにオペレーティング・システムを介して実装されることが可能であり、かつ／あるいは本明細書において説明されているさまざまな実施形態の１つまたは複数の機能態様を実行するように機能するアプリケーション・ソフトウェア内に含まれることが可能である。ソフトウェアは、クライアント・ワークステーション、サーバ、または他の装置などの１つまたは複数のコンピュータによって実行される、プログラム・モジュールなどのコンピュータ実行可能命令という一般的なコンテキストにおいて説明されることが可能である。コンピュータ・システムは、データを通信するために使用されることが可能であるさまざまな構成およびプロトコルを有し、したがって、いかなる特定の構成またはプロトコルも、限定するものとはみなされないということを、当業者には理解されたい。

したがって図８は、本明細書において説明されている実施形態の１つまたは複数の態様が実装されることが可能である適切なコンピューティング・システム環境８００の一例を示しているが、上で明らかにされたように、コンピューティング・システム環境８００は、適切なコンピューティング環境の一例にすぎず、使用または機能の範囲に関して何らかの限定を提示することを意図されているものではない。加えて、コンピューティング・システム環境８００は、例示的なコンピューティング・システム環境８００内に示されているコンポーネントのうちの任意の１つまたは組合せに関して何らかの依存性を有すると解釈されることを意図されているものではない。

図８を参照すると、１つまたは複数の実施形態を実装するための例示的なリモート装置が、コンピュータ８１０の形態の汎用コンピューティング装置を含んでいる。コンピュータ８１０のコンポーネントは、処理ユニット８２０と、システム・メモリ８３０と、このシステム・メモリを含むさまざまなシステム・コンポーネントを処理ユニット８２０に結合するシステム・バス８２２とを含むことができるが、これらに限定されない。

コンピュータ８１０は、典型的にはさまざまなコンピュータ可読媒体を含み、このコンピュータ可読媒体は、コンピュータ８１０によってアクセスされることが可能である任意の利用可能な媒体であることが可能である。システム・メモリ８３０は、読み取り専用メモリ（ＲＯＭ）および／またはランダム・アクセス・メモリ（ＲＡＭ）などの揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体を含むことができる。限定ではなく、例として、システム・メモリ８３０は、オペレーティング・システム、アプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データを含むこともできる。

ユーザは、入力装置８４０を通じてコマンドおよび情報をコンピュータ８１０に入力することができる。さらに、モニタまたは他のタイプのディスプレイ装置が、出力インターフェース８５０などのインターフェースを介してシステム・バス８２２に接続される。コンピュータは、モニタに加えて、スピーカーおよびプリンタなどの他の周辺出力装置を含むこともでき、これらは、出力インターフェース８５０を通じて接続されることが可能である。

コンピュータ８１０は、リモート・コンピュータ８７０などの１つまたは複数の他のリモート・コンピュータへの論理接続を使用して、ネットワーク化されたまたは分散された環境において動作することができる。リモート・コンピュータ８７０は、パーソナル・コンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置もしくは他の一般的なネットワーク・ノード、または任意の他のリモート媒体消費もしくは伝送装置であることが可能であり、コンピュータ８１０に関連して上述した要素のうちのいずれかまたはすべてを含むことができる。図８において示されている論理接続は、ローカル・エリア・ネットワーク（ＬＡＮ）またはワイド・エリア・ネットワーク（ＷＡＮ）などのネットワーク８７２を含むが、他のネットワーク／バスを含むこともできる。こうしたネットワーキング環境は、家庭、オフィス、企業規模のコンピュータ・ネットワーク、イントラネット、およびインターネットにおいてよく見受けられる。

上述したように、例示的な実施形態について、さまざまなコンピューティング装置およびネットワーク・アーキテクチャーに関連して説明してきたが、基礎をなすコンセプトは、リソース使用の効率を改善することが望ましい任意のネットワーク・システムおよび任意のコンピューティング装置またはシステムに適用されることが可能である。

また、本明細書において提供されている技術をアプリケーションおよびサービスが利用することを可能にする同一または同様の機能、たとえば、適切なＡＰＩ、ツール・キット、ドライバ・コード、オペレーティング・システム、コントロール、スタンドアロンのまたはダウンロード可能なソフトウェア・オブジェクトなどを実装するための複数の方法が存在する。したがって、本明細書における実施形態は、ＡＰＩ（または他のソフトウェア・オブジェクト）の観点から、ならびに、本明細書において説明されている１つまたは複数の実施形態を実施するソフトウェアまたはハードウェア・オブジェクトから想定されている。したがって、本明細書において説明されているさまざまな実施形態は、全体がハードウェアの態様、一部がハードウェアで一部がソフトウェアの態様、ならびにソフトウェアの態様を有することができる。

「例」という語は、本明細書においては、例、事例、または例示として機能することを意味するために使用されている。疑いを避けるために、本明細書において開示されている対象事項は、そのような例によって限定されるものではない。加えて、本明細書において「例」として説明されているいかなる態様または設計も、他の態様または設計よりも好適または有利であると必ずしも解釈されるべきではなく、当業者に知られている均等な例示的な構造および技術を除外することを意図されているものでもない。さらに、「ｉｎｃｌｕｄｅｓ（含む）」、「ｈａｓ（有する）」、「ｃｏｎｔａｉｎｓ（含む）」という用語、および他の同様の語が使用されている限り、疑いを避けるために、こうした用語は、請求項において採用されている場合にはいかなるさらなる要素または他の要素も除外しないオープンな移行語としての「ｃｏｍｐｒｉｓｉｎｇ（含む）」という用語と同様に包括的であることを意図されている。

言及したように、本明細書において説明されているさまざまな技術は、ハードウェアもしくはソフトウェアと、または適切な場合には、その両方の組合せと関連して実施されることが可能である。本明細書において、「コンポーネント」、「モジュール」、「システム」などの用語は、コンピュータ関連のエンティティー、すなわち、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのいずれかを指すことを同様に意図されている。たとえば、コンポーネントは、プロセッサ上で稼働しているプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、および／またはコンピュータであることが可能であるが、これらに限定されない。例示として、コンピュータ上で稼働しているアプリケーションおよびそのコンピュータは両方とも、コンポーネントであることが可能である。１つまたは複数のコンポーネントが、１つのプロセスおよび／または実行スレッド内に常駐することが可能であり、１つのコンポーネントが、１つのコンピュータ上に局在し、かつ／あるいは複数のコンピュータの間において分散されることが可能である。

上述のシステムについては、いくつかのコンポーネントの間における対話に関連して説明してきた。こうしたシステムおよびコンポーネントは、それらコンポーネントもしくは指定されたサブコンポーネント、指定されたコンポーネントもしくはサブコンポーネントのうちのいくつか、および／またはさらなるコンポーネントを、上述のもののさまざまな順列および組合せに従って含むことができるということを、理解されたい。サブコンポーネントは、親コンポーネント内に含まれる（階層的である）のではなく、他のコンポーネントに通信可能に結合されているコンポーネントとして実装されることも可能である。加えて、１つまたは複数のコンポーネントが、集約された機能を提供する単一のコンポーネントへと結合され、あるいはいくつかの別々のサブコンポーネントへと分割されることが可能であることと、統合された機能を提供する目的で、こうしたサブコンポーネントへ通信可能に結合するために、管理レイヤなどの任意の１つまたは複数の中間レイヤが提供されることが可能であることとに、留意されたい。本明細書において説明されているあらゆるコンポーネントは、本明細書において具体的には説明されていないが当業者によって一般に知られている１つまたは複数の他のコンポーネントと対話することもできる。

本明細書において説明されている例示的なシステムを考慮すれば、説明されている対象事項に従って実施されることが可能である方法論について、さまざまな図のフローチャートを参照しながら理解することもできる。説明を簡潔にする目的で、これらの方法論は、一連のブロックとして示され説明されているが、いくつかのブロックは、本明細書において示され説明されているのとは異なる順序で、および／または他のブロックと同時に生じることが可能であるため、さまざまな実施形態は、ブロックどうしの順序によって限定されるものではないということを理解および認識されたい。不連続な、または分岐したフローが、フローチャートを介して示されている場合には、同一または同様の結果を達成するさまざまな他の分岐、フロー・パス、およびブロックの順序が実施されることが可能であることを理解されたい。その上、いくつかの示されているブロックは、以降で説明されている方法論を実施する際には任意選択である。

結論
本発明は、さまざまな変更および代替構造を受け入れる余地があるが、本発明の特定の例示されている実施形態が、図面において示されており、詳細に上述されている。しかしながら、本発明を、開示されている特定の形態に限定する意図はまったくなく、逆に、本発明の趣旨および範囲内に収まるすべての変更、代替構造、および均等物をカバーすることを意図しているということを理解されたい。

本明細書において説明されているさまざまな実施形態に加えて、これらから逸脱することなく、対応する（１つまたは複数の）実施形態の同一または均等な機能を実行するために、他の同様の実施形態が使用されることが可能であり、あるいは説明されている（１つまたは複数の）実施形態に対して変更および追加が行われることが可能であるということを、理解されたい。またさらに、複数の処理チップまたは複数の装置が、本明細書において説明されている１つまたは複数の機能の実行を共有することができ、同様にして、複数の装置にわたって格納が実施されることが可能である。したがって本発明は、いかなる単一の実施形態にも限定されるものではなく、むしろ添付の特許請求の範囲に従った広がり、趣旨、および範疇において解釈されるべきものである。

Claims (10)

1. コンピューティング環境において、少なくとも１つのプロセッサ上で少なくとも部分的に実行される方法であって、少なくとも１つのデータ・ソースによって提供されるコンテキストベースの情報に対応するコンテキスト・データを受信するステップと、前記コンテキストベースの情報の精度に対応する正確さ情報を受信するステップと、他の受信されるコンテキスト信号に関して前記少なくとも１つのデータ・ソースによって提供される他のコンテキストベースの情報に対応する全体的な精度を高めるように前記正確さ情報を処理するステップとを含む方法。
2. 前記コンテキスト・データを受信するステップは、データを受信するステップであって、前記データによって、少なくとも１つのデータ・ソースが、ロケーション情報を含む前記コンテキストベースの情報を提供する、ステップと、ａ）少なくとも１つのロケーションベースの結果を含む結果セットを提供するように前記ロケーション情報を使用するステップとを含み、前記正確さ情報を受信するステップは、前記ロケーションベースの結果が正確である可能性が高いかどうかを示すフィードバックを受信するステップを含み、またはｂ）前記正確さ情報を受信するステップは、さらに正確である可能性が高いデータ・ソースから補足的なロケーション情報を受信するステップを含み、前記全体的な精度を高めるように前記正確さ情報を処理するステップは、前記ロケーション情報が前記補足的なロケーション情報と整合しない場合に前記少なくとも１つのデータ・ソースを修正するステップを含み、またはｃ）前記正確さ情報を受信するステップは、さらに正確である可能性が高いデータ・ソースから補足的なロケーション情報を受信するステップを含み、前記全体的な精度を高めるように前記正確さ情報を処理するステップは、前記補足的なロケーション情報に基づいて前記ロケーション情報が不正確であるとわかった場合に前記少なくとも１つのデータ・ソースの出力を動的に修正するステップを含み、またはａ）、ｂ）、もしくはｃ）の任意の組合せである、請求項１に記載の方法。
3. 前記コンテキスト・データを受信するステップは、ロケーション情報を含む前記コンテキストベースの情報を得るように使用されるインターネット・プロトコル（ＩＰ）アドレス・データを受信するステップを含み、前記正確さ情報を受信するステップは、前記ロケーション情報に基づく少なくとも１つの結果を含む結果セットにユーザが満足したかまたは不満だったかを示すユーザ・フィードバックを受信するステップを含む、請求項１に記載の方法。
4. 複数のサンプルのそれぞれから収集された前記正確さ情報をログに記録するステップをさらに含み、前記少なくとも１つのデータ・ソースは、少なくともいくつかの不正確なデータをそれぞれ含む複数の独立したデータ・ソースを含み、前記全体的な精度を高めるように前記正確さ情報を処理するステップは、前記複数のデータ・ソースの中からブレンドされたデータ・ソースを作成するように前記複数のサンプルの前記ログに記録された正確さ情報を処理するステップを含み、該ステップは、前記データ・ソースどうしの間において複数のカウンターパート・セグメントを提供するようにそれぞれのデータ・ソースを複数のセグメントへとセグメント化するステップと、それぞれのカウンターパート・セグメントに関する正確さの測定値を特定するステップと、それぞれのカウンターパート・セグメントに関する正確さの前記測定値に少なくとも部分的に基づいて、前記カウンターパート・セグメントどうしの中から前記ブレンドされたデータ・ソースに関して選択されるセグメントを選択するステップとを含む、請求項１に記載の方法。
5. サンプリング・サービスを含むシステムであって、前記サンプリング・サービスは、複数のサンプル要求の少なくともいくつかに関する正確さデータをログに記録するように構成され、それぞれのサンプル要求は、コンテキスト・データに関連付けられ、情報がログに記録されるそれぞれのサンプル要求に関して、前記サンプリング・サービスは、該要求に関連付けられている前記コンテキスト・データに基づいて１つまたは複数のデータ・ソースにおいてルック・アップされたコンテキストベースの情報に関連した正確さの測定値を、前記１つまたは複数のデータ・ソース以外の少なくとも１つのエンティティーから得るように、および正確さの前記測定値を表すデータをログに記録するように構成される、システム。
6. 複数のセグメントへとセグメント化されるルックアップ・データ・ソースをさらに含み、データ・ソースのそれぞれのセグメントが、互いのデータ・ソース内にカウンターパート・セグメントを有し、当該システムは、ブレンディング・メカニズムをさらに含み、前記ブレンディング・メカニズムは、前記ログに記録された正確さデータを処理するように構成され、前記処理は、それぞれのカウンターパート・セグメントに関する正確さスコアを特定すること、および前記カウンターパート・セグメントの前記正確さスコアに基づいて、選択されたカウンターパート・セグメントどうしを、ブレンドされたデータ・ソースへとブレンドすることを含む、請求項５に記載のシステム。
7. 修正メカニズムをさらに含み、前記修正メカニズムは、前記１つもしくは複数のデータ・ソースに関する更新、または前記１つもしくは複数のデータ・ソースに関する動的な修正データ、または前記１つもしくは複数のデータ・ソースに関する更新と前記１つもしくは複数のデータ・ソースに関する動的な修正データとの双方を提供するように、前記ログに記録された正確さデータを処理するように構成される、請求項５に記載のシステム。
8. 実行されると、ステップを実行するコンピュータ実行可能命令を有する１つまたは複数のコンピュータ可読媒体であって、前記コンピュータ実行可能命令は、少なくともいくつかの不正確なデータをそれぞれ含む複数のデータ・ソースの中から、ブレンドされたデータ・ソースを作成するステップを含み、該ステップは、前記データ・ソースどうしの間において複数のカウンターパート・セグメントを提供するようにそれぞれのデータ・ソースを複数のセグメントへとセグメント化するステップと、それぞれのカウンターパート・セグメントに関する正確さの測定値を特定するように、それぞれのカウンターパート・セグメントに関連して収集された正確さデータを処理するステップと、それぞれのカウンターパート・セグメントに関する正確さの前記測定値に基づいて、前記カウンターパート・データ・ソースどうしの中から前記ブレンドされたデータ・ソースに関して選択されるセグメントを選択するステップとを含む、１つまたは複数のコンピュータ可読媒体。
9. 前記ブレンドされたデータ・ソースは、コンテキスト信号を前記の選択されたセグメントにマップする仮想データ・ソースを含み、当該１つまたは複数のコンピュータ可読媒体は、コンテキスト信号に関する情報を、前記コンテキスト信号に関する前記の選択されたセグメントにどのデータ・ソースが対応するかを特定するように前記仮想データ・ソースにアクセスすることと、前記の選択されたセグメントを介して前記情報をルック・アップすることとによって、ルックアップするステップを含むさらなるコンピュータ実行可能命令を有する、請求項８に記載の１つまたは複数のコンピュータ可読媒体。
10. それぞれのデータ・ソースを複数のセグメントへとセグメント化するステップは、コンテキスト・データ・レンジを使用するステップ、またはインターネット・プロトコル（ＩＰ）アドレスのレンジを使用するステップを含む、請求項８に記載の１つまたは複数のコンピュータ可読媒体。

Images