JP2014532916A - ジオデータに対するユーザベースの事前対応型の内容訂正および強化 - Google Patents

Abstract

システムおよび方法が、地図フィーチャについての曖昧なまたは欠如している情報を判定し、曖昧なまたは欠如している情報に対処するための質問を作成し、曖昧な情報を明確にするために、あるいは欠如した情報を補充するために、フィードバックを要求するユーザを決定する。

Description

本開示は、地図フィーチャに関する情報を更新および訂正するために、オンライン・ホスト型地図システムユーザからのオンライン・フィードバックを求めるメカニズムに関する。

地図は正しくない情報をたびたび含み、その情報を訂正する現在の手法は骨が折れて費用がかかる。オンライン地図は従来の紙形式の地図よりも非常に多くの情報を含む。例えば、オンライン地図では、ユーザは、商店、宿泊施設、レストランなどの事業所の電話番号や開店時間などにアクセスできる。しかしながら、地図上の情報項目が多くなると地図に誤りがある可能性が増えてくる。地図データ中の誤り訂正は、実際に事業所の場所に出かけたり、事業所をオンラインで調査したり事業所に電話することを含む可能性があるが、それは検証される必要がある情報のタイプによる。これは骨が折れて費用がかかる。

個々のエンド・ユーザがシステムの地図への訂正を提案できるいくつかのオンライン地図ホスティング・システムがある。これらのシステムでは、エンド・ユーザによって提案された訂正を専門のレビュアがレビューして承認する必要がある。このような手法のいくつかでは、多数の提案が承認されることによってユーザが信憑性を築いた後にのみ、レビューすることなくユーザの提案した変更を受け入れる。したがって、この手法は依然として労働集約的で費用がかかり、ユーザが提案した変更を承認するために多数の専門のレビュアを必要とする。

住所以上の地図フィーチャの詳細をユーザに提供する対話形式の地図システムの普及により、ユーザはこの追加情報に頼りそれが正しいことを期待する。したがって、地図の不正確さは、過去よりも現在の方が目立ち、厄介である。

地図フィーチャに関する正しくなく時代遅れのデータによる誤りは、非常に苛立たしいユーザの経験につながる。例えば、ユーザが日曜日の午後、その日は事業所が開業していることを示すオンライン地図システムからの情報に完全に基づいて、ある特定の事業所を訪問する計画を立てる場合がある。ユーザが到着したときその事業所が実際は閉まっていた場合には、この訪問においてユーザは著しい時間とエネルギーを浪費してしまう。

システム、方法、および他の実施形態は、確認または明確化、必要とされる確認または明確化を得るためのユーザへの質問の準備、地図フィーチャの所与の地域と所与のカテゴリに対する情報を提供する際のユーザの信頼性分析に基づくクエリ対象ユーザを、地図フィーチャに関するどの情報が必要とするかを判定することにより、オンライン地図上の地図フィーチャを更新することができる。

一実施形態において、システムは、それぞれが地域とカテゴリに関連付けられており、地図の中でユーザに提示される地図フィーチャにアクセスする。システムはこれらの地図フィーチャのいずれかに対する保存された質問があるか否かを判定する。システムは信頼度スコアをユーザのユーザプロフィールから読み出す。それぞれのスコアは地図フィーチャの地域またはカテゴリと関連付けられている。どの質問またはどの複数の質問をユーザに提示するかを判定するため、システムはユーザの信頼度スコアのランクを決定し、その
ユーザの信頼度スコアの最高ランクの地域およびカテゴリに一致するフィーチャの地域およびカテゴリの質問を選択する。システムはその質問に対するユーザの回答を受信し、この回答を保存する。その後、複数のユーザからの回答を分析し、その地図フィーチャを更新または確認するための適切な情報を決定する。

本要約で記載される特徴および利点、および以下の詳細な説明は、包括的なものではない。本明細書の図面、明細書、および特許請求の範囲により、多くの他の特徴および利点が、当業者には明らかであろう。

一実施形態によるシステム環境を示す図。 一実施形態による入力要求をする属性を特定する工程を示すデータ・フロー・チャート図。 一実施形態によるユーザに入力要求を提示する方法を示すデータ・フロー・チャート図。 一実施形態による地図インターフェース中で地図フィーチャをユーザから要求する入力を示すスクリーンショット図。 一実施形態による事業所を一覧表示するインターフェース中で地図フィーチャをユーザから要求する入力を示すスクリーンショット図。 一実施形態によるユーザに提示されている地図フィーチャの属性に関する質問を示すスクリーンショット図。

システムの概要
図１は、一実施形態によるシステム環境の図である。地理情報サーバ１００は、質問エンジン１０１、フィードバック・エンジン１０３、検索ログ・データベース１０５、地理情報データベース１０７、ユーザプロフィール・データベース１０９、質問データベース１１１、および検索エンジン１１３を含む。簡単にするため、１つの質問エンジン１０１、１つのフィードバック・エンジン１０３、１つの検索ログ・データベース１０５、１つの地理情報データベース１０７、１つのユーザプロフィール・データベース１０９、１つの質問データベース１１１、および１つの検索エンジン１１３のみが図示されているが、実際にはこれらのそれぞれの多くの数のものが動作することができる。

地理情報サーバ１００は、そのフロント・エンド１３０およびネットワーク１１０を介してクライアント１１５と通信する。ネットワーク１１０は一般にはインターネットであるが、ＬＡＮ、ＭＡＮ、ＷＡＮ、モバイル、有線または無線ネットワーク、電話ネットワーク、プライベート・ネットワークあるいはバーチャル・プライベート・ネットワーク、およびこれらの任意の組み合わせなどの任意のネットワークであってよいが、これらに限定されるものではない。

クライアント１１５は、ネットワーク１１０を介して地理情報サーバ１００にアクセスするよう構成される任意のタイプの装置である。クライアントの例には、ディスクトップ・コンピュータ、および、ハンドヘルド・コンピュータ、ラップトップ・コンピュータ、タブレット・コンピュータ、携帯電話または携帯情報端末（ＰＤＡ）、地図情報を受信する装置、ナビゲーション装置などの無線位置情報システムなどのモバイル装置があるが、これらに限定されるものではない。これらは、本明細書で記載される構造および機能を提供するよう構成されている。最も基本的には、クライアント１１５は、地図フィーチャに関する情報を表示し、地図フィーチャに関するユーザからの情報を受信し、その情報を地理情報サーバ１００に送信するよう構成される。

さまざまなタイプのクライアント１１５は、本開示された方法によりさまざまな利点を有する。モバイル装置を使用するユーザは、探している場所にいる、あるいはその場所に向かう途中である場合がある。これらのユーザは、ストリート番地および開店時間などの特定のタイプの情報を検証できる方が望ましい。より小さい携帯クライアント１１５を使用するユーザが、大きな画面を持ち質問を表示するより広い余白を持つこともありうる。

クライアント１１５は、地図フィーチャに関する情報を表示し、地図フィーチャに関するユーザの入力情報を受信するためのクライアント・アプリケーションをさらに含む。一実施形態では、クライアント・アプリケーションはブラウザ１１７である。ブラウザ１１７は当該分野で知られている任意のブラウザである。簡単にするため、１つのクライアント１１５のみが図示されている。実際には、多数（例えば数１００万）のクライアント１１５またはハードウェアおよびソフトウェアの実装でサポートできる多くのクライアント１１５が、いつでも地理情報サーバ１００と通信することができる。

地理情報サーバ１００は、１つまたは複数のサーバクラスのコンピュータ上で実行するサーバ・プログラムとして実装される。それぞれの地理情報サーバは、ＣＰＵ、メモリ、ネットワーク・インターフェース、周辺装置インターフェース、および他の既知のコンポーネントを含む。コンピュータ自体は、ＬＩＮＵＸ（登録商標）などのオープンソースのオペレーティング・システムを実行し、一般に複数の高性能ＣＰＵ、１Ｇ以上のメモリ、１００Ｇ以上のディスク記憶装置を有することが好ましい。もちろん他のタイプのコンピュータを利用でき、将来より高性能のコンピュータが開発されるにつれ、それらは本明細書で述べる教示に従って構成可能であることが期待される。任意の諸要素によって実装される機能性は、コンピュータがアクセスできる有形の記憶媒体（例えばＲＡＭ、ハード・ディスク、または光／磁気媒体）に格納されるコンピュータ・プログラム製品から、またはハードウェアおよび／またはファームウェアにおける等価な実装によって、提供することができる。

質問エンジン１０１は、どの入力が欠落情報を満たすために必要であるか、またはどの入力が地図フィーチャに関する曖昧または矛盾する情報を明確にするために必要であるかを判定し、所望の情報を得るためにユーザに提供できる質問を決定する。質問エンジン１０１の一実施形態における動作を、図２を参照してより詳細に記載する。

フィードバック・エンジン１０３は、地図フィーチャの検索に応答して返送される結果のセットの一部として、ユーザに表示されるべき１つまたは複数の質問を選択する。フィードバック・エンジン１０３はまた、ユーザからの回答を受信し、その回答を処理し、その回答に基づいて地理情報データベース１０７を更新する。フィードバック・エンジン１０３の一実施形態における動作を、図３を参照してより詳細に記載する。

検索ログ・データベース１０５は、オンライン地図システムのユーザによって要求された検索を格納する。この情報は、質問エンジン１０１によって使用され質問の優先度を決定する。

地理情報データベース１０７は、地図フィーチャおよびそれらの属性を格納する。地図フィーチャは地理的な位置（地点または地域のいずれか）と関連するエンティティである。このエンティティは、現在または過去のある時点でそこに存在する地理的な位置に関連する場合がある。エンティティの例には、関心対象のポイント（ＰＯＩ）、貯水域、山、森、都市、住所、通り、事業所、建物、近隣地区、史跡、歴史的なイベント（例えば、カスター将軍の最後の戦いの場所またはウッドストック・コンサートの開催場所）およびランドマークなどがあるが、これらに限定されるものではない。

地図フィーチャの属性は、エンティティを特定し、位置付け、記載する地図フィーチャの特性である。さまざまなタイプの地図フィーチャが、さまざまな属性セットを持つことができる。例えば属性は、地図フィーチャの緯度と経度、地図フィーチャの名称、地図フィーチャのカテゴリ、地図フィーチャに対する固有の識別子、および地理情報サーバ１００のユーザの間での地図フィーチャの人気度などを含む。地図フィーチャ・カテゴリは、一般的なもの、すなわち、レストラン、ホテル、公園、ランドマークなどを記載する。地図フィーチャの人気度は、検索に応答してユーザに表示される回数、すなわちインプレッションの数である。これに代えて、人気度は、回数の尺度、すなわちユーザが地図フィーチャの説明へとクリック・スルーする回数を組み込んだものである。追加属性は、地図フィーチャのカテゴリに応じて適切なものである。ストリート番地は地図フィーチャの多数のカテゴリの属性である。事業所の地図フィーチャの属性は、電話番号、ファクス番号、ウェブサイトのアドレス、電子メール・アドレス、クレジット・カードの使用可否、および開店時間を含む。レストランの属性はまた、服装、価格、予約の可否を含む。一般に、属性は地図ユーザに役立つ地図フィーチャについての情報の任意の断片であり、地図フィーチャの物理的、文脈的、意味的な態様を記載することができる。

各属性の値も特性を持つ。値の特性は、その値のソースと、その値の信用度（ｃｏｎｆｉｄｅｎｃｅ）とを含む。値のソース、例えば事業所を一覧表示するウェブサイトのソースは、電話会社である可能性もあり、地図フィーチャに関連する人またはユーザによって提供される可能性がある。一実施形態では、値の信用度は、４つの値、すなわち、低、中、高、無しまたはロック済みのうちの１つをとる。無しは属性値が存在しないことを指す。ロック済みは値が変化できないことを指す。値は、ホワイトリスト中で特定される場合、ロック済みである。これに代えて、属性値の信用度は数値のスコアとすることができる。信用度は、その値のソースに基づくことができる。事業所を一覧表示する特定のウェブサイトは品質の高い情報で知られている場合があり、したがって、そのようなウェブサイトから得られた値は、高い信用度スコアが割り当てられる。信用度スコアは、属性の値の正確さ、その値のソースの歴史または評判を手動でチェックすること、または値の正確さに関するユーザ投票により決定することができる。

各属性も優先度を持つ。優先度は、地図フィーチャの特定の属性がいかに重要かを示すスコアである。これはフィードバックを求めるために属性に優先順位を付けるために使用される。一実施形態では、優先度は以前に受信した検索クエリおよびそれらに関連付けられる検索結果についての情報を含む検索ログの分析に基づいて決定される。地図フィーチャは検索クエリに応答して返送され、ユーザがその地図フィーチャの個々の属性をクリック・スルーする。例えば、アドレスをクリック・スルーしてそのアドレスの地図へ行くことで、地図フィーチャのそのアドレス属性に対する優先度が増加する。地図フィーチャの電話番号をクリックして電話を掛けると、その地図フィーチャのその電話番号属性の優先度が増加するであろう。電話番号のクリック・スルーは、例えば、ユーザが携帯電話であるクライアント装置１１５を使用して検索している場合で起こる。電話番号を選択することで携帯電話はその電話番号に電話を掛ける。これに代えて、クライアント装置１１５がインターネット電話を装備したディスクトップまたはラップトップ・コンピュータならば、電話番号をクリック・スルーすることで、電話ソフトウェアがその電話番号をダイアルすることになる。

地図フィーチャの属性を格納するスキーマの１例を下記に示す。各地図フィーチャ、地図フィーチャ１および地図フィーチャ２は、属性を持つ。各属性に対して、値、優先度、ソース、信用度が表示される。両方の地図フィーチャは地図フィーチャに固有の識別子であるｄｏｃｉｄ、地図上またはユーザに示される事業所一覧でのフィーチャの出現回数であるインプレッション・カウント、事業所のタイプ（地図フィーチャ１ではレストラン、地図フィーチャ２ではホテル）、地図フィーチャの緯度と経度である位置、および電話番
号を持つ。地図フィーチャの位置は、近似であってもよい。各地図フィーチャはまた、地図フィーチャのタイプに特有の属性を持つ。地図フィーチャ１はレストランであり、開店時間（この例では現在欠落しており、したがってユーザに対する質問の候補であろう）、現金以外の受諾可否、車椅子でのアクセス可否、予約の必要性の可否、服装の種類に関する属性を持つ。地図フィーチャ２のホテルは、獲得した星の数および価格範囲の追加属性を持つ。

ユーザプロフィール・データベース１０９は、地理情報サーバ１００のユーザのプロフィールを格納する。ユーザプロフィールは、地図フィーチャ属性に関する情報を提供することによってシステムに喜んで参加するか否か、喜んで参加する場合には、検索および／または地図フィーチャ、ユーザが専門知識を持つ地理的な地域、およびユーザが専門知識を持つ地図フィーチャのカテゴリのどのタイプ対して、どのくらいの頻度で行ったかについてユーザが入力した好みとともに、ユーザに対する識別子を含む。ユーザプロフィールはさらに質問への回答におけるユーザの信頼度スコアを含む。このスコアは、フィードバック・エンジン１０３によって決定される。

質問データベース１１１は、質問エンジン１０１によって作成された質問を格納し、質問をユーザに提示する必要がある場合には、フィードバック・エンジン１０３によってアクセスされる。

処理概要−質問の作成
図２は、入力を必要とする地図フィーチャの属性を特定する工程を示すデータ・フロー・チャートである。質問エンジン１０１は、処理のために地理情報データベース１０７から地図フィーチャ・レコードのサブセットにアクセスする（２０５）。地図フィーチャ・レコードのこのサブセットに対して、質問エンジン１０１は、中または低の信用度の値を持つか、その値が欠如している地図フィーチャ属性を、可能な質問作成の候補属性として特定する（２１０）。属性値の信用度および属性の優先度は、その属性値に対する質問スコアを決定するべく、地図フィーチャの人気度と組み合わされる（２２０）。質問スコアは地図フィーチャがどれだけ人気があるかだけでなく、その属性がいかに重要であるか、およびシステムが現在の属性値をどれだけ信用しているかを考慮している。したがって、システムは十分に知られていないが人気のある地図フィーチャに対する重要な属性の情報を探し求めるために質問の優先順位を付ける。一実施形態では、質問スコアは次のようになる。

質問スコア＝Ａｌｏｇ（フィーチャ 人気度）＋Ｂｌｏｇ（（属性 優先度）×（１−属性値 信用度））
ここでＡおよびＢは、例えば機械学習によって決定される定数である。

質問スコアは、候補となる地図フィーチャ属性のセットのランクを決定し、そのランクに基づいて候補となる地図フィーチャ属性のサブセットを選択するために使用される。この方法では、低い信頼度を持つ値の人気のある地図フィーチャに対する高い優先度の属性が、フィードバックを求めることについて最初にランク決定される一方、高い信頼度を持つ値の（人気があってもなくても）地図フィーチャに対する低い優先度の属性は、フィードバックを求めることについて低いランクが付けられる。候補となる地図フィーチャ属性の選択されたサブセットは、質問スコアが閾値を超える候補となる地図フィーチャ属性を含む。選択されたそれぞれの候補となる地図フィーチャ属性に対して、質問エンジン１０１はその属性値に対するフィードバックを求める場合に使用される質問を作成する（２２０）。

質問のタイプは、自由形式の質問、真／偽形式の質問、および複数選択形式の質問を含む。作成される質問のタイプは、検証されようとしている属性のタイプ、およびその属性に対して既知の値の現在の数に依存する。複数の電話番号など、１つの属性に対して複数の既知の値がある場合には、作成される質問は、選択肢としていくつかの（または、すべての）既知の電話番号値を使用する複数選択形式の質問となることもある。例えば、次のような質問をすることができる。「このレストランの電話番号は、ａ）１２３−４５６−７８９０、ｂ）４５６−２５８−７８９４、ｃ）１２３−４５６−７８８０のうちのどれですか？」。

１つの属性に対して１つの値のみが格納されているが、その信頼度は低い場合、質問では、その値が正しいかを尋ねることができる。例えば、次のような質問をすることができる。「このレストランの電話番号は１２３−４５６−７８９０ですか？」。

電話番号属性に関する何の値も保存されていない場合、その値を取得するために「このレストランの電話番号は？」などのような自由形式の質問を作成できる。
質問エンジン１０１で作成された質問は、質問データベースに格納される（２２５）。
質問しようとしている地図フィーチャ属性も格納される。通常、地図フィーチャはｄｏｃｉｄによって特定され、ｄｏｃｉｄ自体は地図フィーチャの１つの属性である。場合により質問の作成を導いた地図フィーチャ属性に対する質問スコアが質問とともに保存される。これらの属性に関するより多くの情報を提供する質問を決定するための地図フィーチャおよび地図フィーチャ属性の処理は、１日１回、または１週間に１回などのように、周期的にオフラインで実行できる。

処理概要−フィードバックの取得
質問へのフィードバックを取得する工程は、例えば、検索エンジン１１３に地図関連情報に対するクエリを送信することによって、ユーザがクライアント装置１１５から地図にアクセスするという状況で起こる。一実施形態では、ユーザのクライアント装置１１５は携帯電話である。

ユーザは、クライアント装置１１５から検索エンジン１１３へ検索クエリを送信する（３０１）。そのクエリは曖昧さのないものにすることができ、例えば、都市、事業所、地理的な特徴などの名称を含む検索要求である。またそのクエリは曖昧なものにすることもでき、ユーザの現在位置に基づいた地図への要求などである。モバイル・クライアント装置１１５の多くは、ＧＰＳ機能を持っているため高精度で装置の位置を正確に示すことができる。クエリ・タイプの詳細にかかわらず、検索エンジンは検索クエリに応答する地図フィーチャを決定する（３０３）。クエリに応答する地図フィーチャは、クエリに基づいて表示される地図の地域内にあるものを含む。検索エンジン１１３は、フィードバック・エンジン１０３からこれらの地図フィーチャに対する質問を要求する（３０５）。検索エンジン１１３からの要求は、ユーザに返送される地図フィーチャの複数の識別子および検索を要求しているユーザに関連する１つの識別子を含む。

図３には図示されていないが、フィードバック・エンジン１０３は、ユーザのクエリに応答する地図フィーチャの属性に関連する質問が質問データベース１１１内にあるかどうかを最初に判定する。そのような質問が（例えば、応答してもらう地図フィーチャのすべての属性が既知の高い信頼度の値を持っているために）質問データベース１１１に存在しない場合、フィードバック・エンジンは検索エンジン１１３にヌル回答を返し、検索エンジン１１３はクライアント装置１１５への地図フィーチャにフィードバックする質問がないことを提供する。

しかしながら、フィードバック・エンジンが受信したクエリに応答する地図フィーチャに関連する１つまたは複数の質問を質問データベース１１１内で特定した場合、フィードバック・エンジン１０３はユーザプロフィール・データベース１０９から地図フィーチャが表示されるユーザに対するユーザ・データにアクセスする（３０７）。フィードバック・エンジンは、アクセスされたユーザ・データを使用してそのユーザに質問を提供するか否かを判定する（３１０）。そのユーザ・データはそのユーザが喜んでフィードバックを提供してくれるか否かを示しており、喜んで提供してくれる場合には、どの質問をそのユーザに提供するかを判定するための評価基準を含む。ユーザ・データが、そのユーザがフィードバックの提供を望んでいないことを示している場合には、そのユーザに返送するための質問が検索エンジン１１３に提供されない。一実施形態では、ユーザがフィードバック提供に肯定的にオプトインしない場合には、そのユーザは、そのユーザのクエリに応答する地図フィーチャに関する質問を提供されない。これに代えて、別の実施形態では、積極的にオプトアウトするユーザのみを質問を提供する対象から除外する。

そのユーザが喜んでフィードバックを提供する（例えば、オプトインする、またはオプトアウトしない）ことをユーザ・データが示している場合には、フィードバック・エンジン１０３は、ユーザが喜んでフィードバックを提供するフィーチャに対する評価基準に、
表示すべきどの地図フィーチャが一致するかを判定する。そのような評価基準は、例えば、地図フィーチャのカテゴリ、位置、属性のタイプ、地図フィーチャとのユーザ・イントラクションのレベルを含むことができる。例えば、ユーザがレストランおよび書店などの地図フィーチャの特定のカテゴリのみについてフィードバックを提供する意志を示している場合がある。または、ユーザは、ニューヨーク市またはボストンなどのある特定の地域のみで、フィードバックを提供する意志を示している場合がある。または、ユーザは、ユーザが以前にクリック・スルーして地図フィーチャのすべてのページの説明を表示したその地図フィーチャに対してのみフィードバックを提供する意志を示している場合がある。あるユーザが（具体的にオプトインするか、またはその代わりにオプトアウトしないかのどちらかで示されるように）喜んでフィードバックを提供するならば、また、ユーザが喜んでフィードバックを提供する地図フィーチャに、表示すべき少なくとも１つの地図フィーチャが一致するならば、フィードバック・エンジン１０３は処理を進めてそのユーザに表示されるべき質問を選択する。

フィードバック・エンジン１０３は、ユーザに表示されるべき、およびユーザのフィードバック評価基準に一致する地図フィーチャのいずれかの属性に関連する質問データベース１１１に格納されている質問を読み出す（３３０）。

ユーザ・データは、そのユーザが以前に提供したフィードバックの信頼度（ｒｅｌｉａｂｉｌｉｔｙ）を測定する信頼度スコアを含む。一実施形態では、信頼度スコアは、ユーザのフィードバックが、その後、他のユーザが提供した回答に基づくコンセンサス（総意）回答に関して正しいと判定されたユーザのフィードバックの割合として測定される。信頼度スコアは時間の経過とともに指数関数的に低下するので、より最近のユーザ・データおよびフィードバックが、そのユーザの信頼度スコアの中でより重いウエイトを持つように保証する。他のユーザが提供した回答の中からコンセンサス回答を決定する方法は、さらに以下に記載する。

ユーザは、ユーザが提供したすべてのフィードバックに基づくグローバルな信頼度スコア、および、地図フィーチャおよび地理的な地域のある特定のカテゴリに特定の信頼度スコアを持つことができる。一実施形態では、信頼度スコアは、所与の地理的な地域における地図フィーチャに固有である。そのようなスコアは、ユーザが住んでいるエリアにあるレストランに関してそのユーザは非常に信頼できるが、そのユーザは他のエリアのレストランについて信頼できるフィードバックを提供できないという事実を反映している。

ユーザ・信頼度スコアは、地図フィーチャのカテゴリおよび地理的な地域に連動させることができ、＜カテゴリ、地域、信頼度スコア＞として表現される。ステップ３３０で質問データベース１１１から読み出された質問は、次に、この読み出された質問に関連する地図フィーチャのカテゴリおよび地理的な地域に対するユーザの信頼度スコアに従ってランク決定される（３３５）。最高ランクの１つまたは複数の質問（どれだけ多く提供するかに依存する）が、検索エンジン１１３に返される（３４０）。一実施形態では、質問に対する質問スコアも質問のランクを決定するのに考慮される。例えば、いくつかの質問が同じ信頼度スコアを持つ場合には、質問スコアを使用して上位の１つまたは複数の質問を決定する。これに代えて、各質問に対する質問スコアと信頼度スコアを常に組み合わせて、返送される質問のランク決定方法を決定する。ユーザが閾値よりも低い信頼度スコアを持つ地図フィーチャのカテゴリおよび地理的な地域に関する地図フィーチャ属性に対する質問は、場合により放棄することができる。一実施形態では、閾値を越えるユーザ・信頼度スコアがない場合には、ユーザが喜んで質問に回答することを示し、格納されている質問に対する地図フィーチャがあるとしても、何の質問もユーザに返送されない。このことは、頻繁に正しくないユーザからの、または、所与の地理的な地域または地図フィーチャのタイプに精通していないユーザに関する信頼できそうもないデータの受信を避けるのに
役立つ。

フィードバック・エンジン１０３は、ユーザの好み、ユーザに地図フィーチャを表示すべきディスプレイのサイズ、およびユーザに対するディスプレイ上の地図フィーチャの位置を含む１セットのファクタに基づいて返送する質問数を決定する。ディスプレイが小さく、すぐに画面が乱雑となるようなモバイル装置を使用するユーザにはより少数の質問が表示される。一実施形態では、モバイル装置上ではユーザに対してたった１つの質問が表示される。より大きなディスプレイ上でも、地図フィーチャの質問でディスプレイが溢れてしまうことは逆効果になる。したがって、最高ランクの複数の質問が地図フィーチャに対して存在する場合、およびそれらの質問が地図上、またはリスト中に近接して表示される場合には、（例えば、ユーザ・信頼度スコア、質問スコア、またはその両者に基づいて）最高のランクに決定された質問が表示され、他の質問は表示されない。

検索エンジン１１３は、地図フィーチャ、および１つまたは複数の質問をクライアント装置１１５に提供する（３４５）。図４および図５は、ユーザへの表示例のスクリーンショットである。図４はニューヨーク市のピザに関する検索クエリに応答してユーザに提供される検索結果を示す。検索結果は、地図の横にあるパネル４１０の中に表示される検索結果の詳細とともに地図４０５上に表示される。最初の検索結果に対して、その検索結果とともに質問がユーザに返送されている。これは、ユーザにバルーン４１５として表示され、その上をユーザがクリックして質問を出現させフィードバックを提供することができる。「ｍｏｒｅ ｉｎｆｏ」リンク４２０によって、ユーザがその検索結果に関する詳細情報ページへクリック・スルーすることができる。図５は、リンク４２０をクリック・スルーして得られたジョンズ・ピッツェリア（Ｊｏｈｎ’ｓ Ｐｉｚｚｅｒｉａ）に関するページのスクリーンショットである。質問バルーン４１５は、詳細情報ページ上にいるユーザにも表示させることができる。一実施形態では、ユーザプロフィールは、結果一覧表示ページではなく詳細情報ページから地図フィーチャに対するフィードバックを提供することをユーザが選択したことを示す。このような一実施形態では、質問バルーン４１５は検索結果一覧表示ページ上に図４に示すようには表示されず、ユーザが詳細情報ページへのクリック・スルーする場合のみ表示される。

質問バルーン４１５をクリック・スルーした直後に、質問を持つダイアログ・ボックスがユーザに表示される。図６は、そのようなダイアログ・ボックスを示すスクリーンショットである。この質問は、複数選択形式である。ユーザは、正しい電話番号と信じているものを選択するためのボタン６０５を提供される。場合により、ユーザが提供している回答をどこで学んだかを質問される。例えば、ユーザは、レストランのウェブページからジョンズ・ピッツェリアの正しい電話番号を入手した可能性がある。その際には、ユーザはそのＵＲＬを入力するであろう。これに代えて、ユーザは記憶していた電話番号を回答する場合がある。回答を選択した後、ユーザは送信ボタン６１０をクリックして地理情報サーバ１００に回答を返送する。これに代えて、ユーザは回答を選択する代わりにキャンセル６１５をクリックすることができる。

図３に戻ると、ユーザの回答はクライアント装置１１５で受け取られ（３５０）、フィードバック・エンジン１０３に提供される（３５５）。フィードバック・エンジン１０３は、ユーザプロフィール・データベース１０９を更新し（３６５）、ユーザがこの質問に回答したことを示す。フィードバック・エンジン１０３はまた、ユーザが与えた回答で質問データベース１１１を更新し（３７０）、その質問が回答された回数を記録するカウンタを増分する。

１つの地図フィーチャに関する１つの所与の質問に対して、閾値の数の回答を受け取った後に、その回答がレビューされコンセンサス回答が決定される。一実施形態では、コン
センサス回答は、閾値の回答数から過半数の投票を受け取ったものである。図６の例を使用すれば、半分以上のユーザがジョンズ・ピッツェリアの電話番号として２１２−３９１−７５６０を選択した場合には、２１２−３９１−７５６０がコンセンサス回答になる。

これに代えて、各回答は、回答として受け取った投票の重み付けされたカウントであるスコアを持っており、各投票はその投票を提供するユーザの信頼度スコアで重み付けされる。テーブル２は、図６の例で集められたデータとユーザ・信頼度スコアを示す。

この例では、質問に回答するユーザに対する閾値の信頼度がないか、または非常に低く設定されている。電話番号２１２−３９１−７５６０は少数の投票だがより高い信頼度スコアを持つユーザからのものであり、平均の重みは０．６９である。電話番号３２１−６５４−８９７０に対する投票数は高いが、平均の重みは低く０．３１であり、システムをスパムするための故意の企てであったり、またはニューヨークのピザ店に精通していない善意のあるユーザの投票にすぎないこともあり得る。それにもかかわらず、電話番号に対する投票を重み付けするために信頼度スコアを使用することが、最高の重みを持つ電話番号を導き、この場合では、正しい電話番号は２１２−３９１−７５６０でありこれがコンセンサス回答である。

コンセンサス回答の決定は、自動的に、または手動でなされる場合がある。地図フィーチャに対するレコードは、地理情報データベース１０７にあるその回答で更新される。加えて、その質問に回答するユーザに対する信頼度スコアは、ユーザの回答がコンセンサス回答であったかどうかで更新される。

本発明は、いくつかの可能な実施形態に関して特に詳細に記載されてきた。本発明が他の実施形態でも実施できることが当業者には分かるであろう。第１に、コンポーネントの特定の名前付け、用語の大文字表記、属性、データ構造、あるいはいかなる他のプログラミングまたは構造的な態様は、必須または重要なものではなく、本発明または本発明の機能を実施するメカニズムは、さまざまな名称、フォーマット、あるいはプロトコルを持つことができる。さらに、本システムは、記載したように、ハードウェアおよびソフトウェアの組み合わせによって、または、完全にハードウェアの諸要素によって実施される場合がある。また、本明細書で記載されたさまざまなシステム・コンポーネント間の機能の具体的な区分は、単なる例示であり必須のものではなく、単一システム・コンポーネントで実行される機能は、代わりに複数のコンポーネントで実行されてもよく、複数のコンポー
ネントで実行される機能は、代わりに単一のコンポーネントで実行されてもよい。

上記に記載のいくつかの部分は、情報に対する操作の方法および記号的表現という観点から、本発明の特徴を提示している。これらの説明および表現は、データ処理分野の当業者が仕事の内容を他の当業者に効率よく伝えるために使用される手段である。これらの操作は、機能的または論理的に記載されているが、コンピュータ・プログラムにより実装されることが理解されよう。さらに、モジュールとして、または機能の名称によって、一般性を損なうことなくこれらの操作の配置を参照することは、時として便利であることも分かるであろう。

上記の議論から明らかのように特段に記述されていない限り、説明全体に渡って、「決定すること」または「表示すること」などの用語を利用している議論は、コンピュータ・システムのメモリまたはレジスタまたは他のそのような情報ストレージ、伝送装置、または表示装置内にある物理的（電子的）な量として表現されるデータを操作および変形するコンピュータ・システム、または類似の電子計算装置の行動および処理を参照することが理解されよう。

本発明の特定の態様は、方法の形式で本明細書に記載される工程段階および命令を含む。本発明の工程段階および命令は、ソフトウェア、ファームウェア、またはハードウェアで具現化されるであろうし、ソフトウェアで具現化される場合には、リアル・タイム・ネットワーク・オペレーティング・システムによって使用されるさまざまなプラットフォームからダウンロードされて常駐し、操作されるであろうことに留意されたい。

本発明はまた、本明細書における操作を実行する装置に関する。この装置は、要求される目的のために特別に構成される場合もあるし、あるいはコンピュータがアクセスできるコンピュータ読み出し可能媒体上に格納されたコンピュータ・プログラムによって選択的に作動、または再構成される汎用コンピュータを含む場合もある。このようなコンピュータ・プログラムは、例えば、これらに限定されないが、フロッピー（登録商標）・ディスク、光ディスク、ＣＤ−ＲＯＭ、磁気光ディスク、リードオンリー・メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気または光カード、特定用途向け集積回路（ＡＳＩＣ）を含む任意のタイプのディスク、または電子的な命令を格納するのに適した任意のタイプの媒体、およびコンピュータ・システム・バスに接続されているものなど、有形のコンピュータ読み出し可能記憶媒体に格納することができる。さらに、本明細書で参照されるコンピュータは、単一プロセッサを含む場合もあるし、あるいは計算能力を増強するために複数プロセッサの設計を使用するアーキテクチャである場合もある。

本明細書で提示される方法および操作は、ある特別のコンピュータまたは他の装置に本質的に関連付けられていない。さまざまな汎用システムも本明細書の教示に従っているプログラムで使用でき、あるいは、要求される方法の工程を実行するより特殊な装置を構成するのも便利であることが分かるであろう。さまざまなこれらのシステムに対して要求される構造は、等価の変形形態とともに、当業者には明らかであろう。加えて、本発明は、特定のプログラミング言語を参考にして記載されていない。さまざまなプログラミング言語を、本明細書に記載されている本発明の教示を実装するために使用でき、特定の言語に対するいかなる参照も本発明の実施可能性および最善の状態のために提供されていることが理解されよう。

本発明は、多数のトポロジー上での多種多様なコンピュータ・ネットワーク・システムにうまく適合している。本分野では、大きなネットワークの構成と管理は、インターネット、公衆ネットワーク、プライベート・ネットワーク、またはコンピュータ・システムの
間での通信を可能にする他のネットワークなどのネットワーク上で、異機種コンピュータおよび記憶装置に通信できるように結合されている記憶装置およびコンピュータを含む。最後に、本明細書で使用される言語は、原則的に、読みやすさや教育目的のために選択されており、本発明の対象を記述または制限するために選択されていないことに留意されたい。したがって、本発明の開示は、説明に役立つことを意図しており、以下の請求項で設定される本発明の範囲を限定するものではない。

Claims (26)

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. 複数の地図フィーチャ属性のそれぞれに関する複数の質問における特定された前記質問のランクを決定するために特定された前記質問に対するスコアを使用することを含み、特定された前記質問をユーザに送信することは、特定された前記質問のランクが前記ユーザに送信すべき質問数の閾値より高いランクであることを判定することを含む、請求項１４に記載のシステム。