JP5064388B2

JP5064388B2 - 位置識別方法

Info

Publication number: JP5064388B2
Application number: JP2008521647A
Authority: JP
Inventors: クリストファー・エム・アテナシオ
Original assignee: グーグル・インコーポレーテッド
Priority date: 2005-07-13
Filing date: 2006-07-13
Publication date: 2012-10-31
Anticipated expiration: 2026-07-13
Also published as: JP2009501976A; US8959084B2; WO2007009074A2; EP1908042A2; WO2007009074A3; US20070015119A1

Description

本出願は、２００５年７月１３日に出願された米国仮出願番号第６０／６９８７７５の利益を主張し、その内容は、その全体が参照によって本明細書中に組込まれている。

本発明は、同じ位置又は複数の位置に対して、アドレスのような異なる識別子に応答して、緯度／経度座標又はＧＰＳ座標のような位置識別子を提供することに関する。

多くの会社のアプリケーションは、地理的位置の使用を必要とする。例えば、マッピングプログラムは、ユーザがどこにいるのか知る必要がある。旅行計画プログラムは、旅の終点に関する位置と、恐らくは終点間における多数の中間点の位置とを知る必要がある。

もう一つの例として、グーグルローカルのような“ローカル検索”は、次第に注目を集めてきている。そのようなローカル検索は、サーチャー（searcher）の周知の（又は少なくとも疑わしい）位置を活用することによって通常の検索にローカル要素を追加する。例えば、検索用語として“家具”を入力し、予め識別された彼の又は彼女の郵便番号を有するサーチャーは、近隣の家具店のような、その郵便番号内に又は近接した会社に対する検索結果のサブセットが提供されうる。また、サーチャーは、検索結果のほか、適切にターゲットにされたローカル広告結果が提供されうる。

一般に、これらシステムは、比較的正確な位置を生成する必要がある。例えば、システムが２点間の旅程を計算することになる場合、それら点がかなり近いのか、あるいは旅程の各エンドが近いとユーザが推測したままであるのかを知る必要がある。また、一般に、そのようなシステムは、曖昧でない位置を必要とする。即ち、それらが一部のポイントの周囲のエリアに対する検索を計算する必要がある場合、それらは、それらが適切なポイントを使用しており、何百キロも離れた類似の名前又は記述を備えたいくつかの他のポイントを使用していないことを知る必要がある。

同時に、これらシステムがユーザからそのような曖昧でない入力を要求しない場合が最適である。特に、ユーザは、タイプミスなしで及び完全な詳細で、正確な位置又はアドレスを提供するためにそれらを要求するシステムについて満足しない。確かに、ユーザは、位置に対する緯度及び経度を提供すること、又はグローバルポジショニングサービス（ＧＰＳ）又は他のそのような座標を提供することを望まない。

また、ユーザは、多数の正確な識別子（例えば、２つの町の何れか一方又は町及びさらには国に位置するとして技術的に記述されうるアドレス、又は番号及び事務所名及び共通名を有する道路上のアドレス）がある時、位置に対する単一の適切な識別子を入力するのを強いられることを望まない。また、ユーザは、自然言語クエリーによって等、クエリー内のどのテキストが位置を示すかを明確に識別する必要なくクエリーを入力することを望む可能性がある。また、位置又は複数の位置に対してウェブページのような内容を関連付けて、位置ベースのクエリーに応えてそのような内容を提供できるようにすることが必要な場合がある。

故に、ユーザが提供した人間の使用可能な位置識別子から正確なコンピュータ使用可能な位置識別子を生成できるシステム及び方法に対する必要性がある。また、提供されたクエリー、ウェブページ、又は他のテキストからアドレスを抽出してコンピュータ使用可能な位置識別子を生成できるシステム及び方法に対する必要性がある。また、日本のような特定のエリアにおいて、位置の識別に対する人間の使用可能な標準は、構文及びスタイルにおいてかなり多様なことがあり、そのような変換が特に困難となる。故に、特に曖昧な人間の使用可能な位置識別子を有するエリアにおいてもコンピュータ使用可能な位置識別子を生成できるシステム及び方法に対する特別な必要性がある。

本発明は、計算及び通信装置のユーザがそれら装置にデータを入力するに際して支援する方法及びシステムを開示する。一つの実施形態において、コンピュータ実行方法が開示される。方法は、リモート装置のユーザから位置識別子をクエリーで受信する過程と、入力位置識別子をパースして一つ以上の位置関連トークンを生成する過程と、一つ以上の位置関連トークンに関して位置情報のレポジトリにクエリーしてトークンに対して実質的な一致を有する一つ以上のドキュメントに対する位置を識別する過程と、ドキュメントに関連付けられた位置の地理的サイズを示す各ドキュメントに対する位置の量を使用して一つ以上のドキュメントをスコア化する過程と、位置の量を使用してディスプレイするために一つ以上のドキュメントに関する情報を示す過程とを具備する。

いくつかの実施形態において、クエリー独立地理的表示は、リモート装置から受信されて使用され、一つ以上のドキュメントをスコア化することができる。クエリー独立地理的表示は、リモート装置が位置決めされた位置と、装置上にディスプレイされた地図の境界ボックスと、ユーザが接続しているインターネットドメインに対応する領域とからなるグループから選択されうる。ドキュメントに対するスコアは、クエリー独立地理的表示と結果との間における距離に対するドキュメントの量の割合を含みうる。また、位置情報のレポジトリをクエリーする段階は、十分な数の一致が見出されるまで比較的少ない特定の情報を使用してレポジトリを再帰的にクエリーする過程を具備し、また、削除されたトークンに関してトークンの各順列に対してクエリーする過程を含みうる。また、レポジトリをクエリーする過程は、削除された一つのトークンに対する一致がなされない場合、削除された２つのトークンに関してトークンの順列毎にクエリーし、トークンの各順列を重み付けし、重み付けを使用して各順列をクエリーする過程からの結果をスコア化する過程を具備しうる（各トークンにその内容に基づき重み付けを割り当てる過程、及びクエリー内のトークンの位置に従って重み付けを適合する過程によることを含む）。

いくつかの実施形態において、クエリーは、検索リクエストを具備することができる。また、ディスプレイのために一つ以上のドキュメントに関する情報を提示する過程は、検索結果のランク付けリストを提示する過程を具備しうる。

さらにもう一つの実施形態において、位置ベースのデータ収集及び分配システムが開示される。システムは、一つ以上のリモートクライアントからデータリクエストを受信するリクエストプロセッサと、データクエリー内の位置関連トークンを識別する位置ベースのトークナイザと、一つ以上の位置関連トークンに関して位置情報のレポジトリにクエリーし、トークンに対して実質的な一致を有する一つ以上のドキュメントに対して位置を識別し、ドキュメント毎に位置の量を使用して一つ以上のドキュメントをスコア化する結果スコアラとを具備する。

さらにもう一つの実施形態において、位置ベースのデータ収集及び分配システムは、一つ以上のリモートクライアントからデータリクエストを受信するリクエストプロセッサと、データクエリー内の位置関連トークンを識別する位置ベースのトークナイザと、データリクエストに応答してアイテムをスコア化するための手段とを具備することを開示している。

もう一つの実施形態において、ドキュメントのコーパス内の位置ベースの情報を識別する方法が開示される。方法は、ドキュメントのコーパス内のドキュメントをパースして一つ以上のトークンを生成する過程と、位置ベースのレポジトリ内のトークンの組合せに対して近接して生成されたトークンの組合せを比較する過程と、位置ベースのレポジトリ内の一致を有する近接したトークンの組合せを使用して一般のデータベースをクエリーする過程と、クエリーが十分な数の一致を生成する場合、ドキュメントに対する位置として近接して生成されたトークンを割り当てる過程とを具備する。

一つの実施形態において、位置ベースのレポジトリは、比較的大きなレポジトリからのトークンバイグラムを具備してもよく、位置ベースのレポジトリ内のトークンの組合せに対して近接して生成されたトークンを比較することは、一組の３つの連続したトークンからの重複バイグラムを比較することを含みうる。また、トークンは、近接して生成されたトークンに追加されて拡大された一組のトークンを作成してもよく、拡大された一組のトークンは、位置ベースのレポジトリと比較されてもよい。また、近接したトークンは、反復して追加され拡大された一組のトークンを作成してもよく、結果が一致しなくなるまで、拡大された一組のトークンは、位置ベースのレポジトリと比較され、一般のデータベースは、最大の拡大された一組のトークンに関してクエリーされてもよい。また、最大の拡大された一組のトークンは、低減されて、クエリーに対する一致がない場合、低減された一組のトークンを生成してもよく、一般のデータベースは、低減された一組のトークンを必要とする。また、一般のデータベースは、インターネット上のドキュメントから抽出された情報を比較してもよい。

本明細書中で説明されたシステム及び技術は、一つ以上の以下の利点を提供しうる。システムは、米国、英国、日本、中国、韓国、インド、又は上記エリアよりも異なるアドレススキームを使用している他の位置におけるユーザの位置に対して、効率的で自動的な位置結果を独立して提供しうる。一度データがレポジトリに組込まれると、ドイツ語、英語、又はヘブライ語かに応答する。また、システムは、迅速に正確な情報を提供し、詳細なアドレスレベルへ下げることによってユーザを支援することができる。また、システム及び技術は、アプリケーション作者から多量の仕事を必要としない柔軟な態様で各種アプリケーションに対して互換可能に使用されうる。

本明細書中で説明されるシステム及び方法は、システムのユーザによって受信されたクエリー及び的確な位置情報を提供する意図がなかった人々によって認可されたウェブページ等の、不的確なデータソースから、緯度及び経度又は特定エリア等の、的確な位置データの取得に対する支援に関する。一般に、システムは、受信した文字列をパースして関連する位置でありうるトークンを識別すること、及び周知の位置識別子にトークンを一致させることによって動作する。その後、特定のトークン又は一組のトークンは、トークンの位置量に従ってスコア化され、恐らくはクエリーを提示するユーザの現在位置等の位置ヒントと一緒にスコア化されうる。また、ドキュメントは、トークンの組合せが任意のヒントを生成するか否かを判断するために、トークンの組合せを使用して、ドキュメントをトークン化すること、及びデータベースを検索することによって位置情報に関してスキャンされ、それら組合せが任意のヒントを生成するかを判断しうる。ヒントを生成する組合せは、ドキュメントで識別された位置であると考えうる。

図１は、各種アプリケーションに対する位置識別子を検索するためのシステム１０を概略的に示す。システム１０において、各種アプリケーションは、位置情報のレポジトリ１２に連絡する。レポジトリは、かなり可視的になるよう構築されるので、最小の効果で多目的に使用されうる。そのように情報を集中させるアプローチは、システムが位置情報の重複を回避するよう支援し、さらに追加的な位置ベースのアプリケーション開発を簡易化する。

レポジトリ１２は、多数の位置ドキュメント１２ａ〜１２ｃを含み、各ドキュメントは、世界中の固有の位置を記述する（但し、多数のドキュメントは、重複した位置を有することがあり、適切な状況において同一の位置を記述することもある）。各位置ドキュメントは、ｉｄ、アドレス、構造化アドレス、量、及び位置識別子からなる、多数の共通の属性を含みうる。ｉｄは、共通のストリートアドレス、又は地域名等の、固有の識別子文字列にすることができる。アドレスは、位置を称呼する名前を含むことができる。アドレスは、ｉｄに類似するが、より可読な形式にすることができる。構造化アドレスは、アドレスの形式であって細分化されるので、システム１０は、どのように各種アドレスの一部が表示又は提供されるかについて、さらに制御できる。

量は位置に関して、重要度の記述であって、一般に数字である。一つの形式において、量は、位置に含まれるポイントアドレスの略数である。例えば、単一のアドレスは、１の量を有することができ、町は、（町における単一のアドレスの総数からなる）１０００の量を有することができ、国は、数十万の量を有することができる。最後に、位置識別子は、地図等の事項を計算するためのシステムによって使用可能な任意の適切な識別子を含むことができる。特に、位置識別子は、ラトロング（lat-long）ポイント又は組合せ、地域に対する境界ボックスの座標、又はポリゴンを含むことができる。レポジトリドキュメントの編成は、以下図２に関して詳細に説明される。

再び図１を参照すると、いくつかのアプリケーションがレポジトリ１２にアクセスしているのが示される。例えば、アドレス記述１６は、地図プログラムへのアクセスを試みるユーザによって入力されたクエリーのローテキスト（raw text）でもよい。一般に、レポジトリ１２は、そのようなシナリオでジオコーディングサービスを提供する。ジオコードは、“私は、世界における位置を記述する小塊のテキストを有する；それが最も記述する位置は何か？”の質問に回答する。そのように、アドレス記述１６は、人間が可読なアドレスをレポジトリに提供することができる（又はより正確には、レポジトリと協働するアプリケーションを提供してもよい）。システム１０は、情報をパースして、レポジトリにそれを提供して、レポジトリは、位置ドキュメントからの位置ＩＤ等の、クエリーに関する機械使用可能な位置識別子を戻すことができる。

また、クエリーアプリケーション１８は、レポジトリ１２にリクエストを提供することができる。クエリーアプリケーション１８は、ユーザから又は他のアプリケーションからリクエストを受信する各種アプリケーションを含むので、リクエストに対する応答を提供することができる。例えば、クエリーは、テキストの文字列としてレポジトリ１２（又は、レポジトリと共に動作するアプリケーション）に伝えられ、その一部は、実質的クエリーに関し、もう一部は、位置に関する。例えば、クエリーは、“ニューヨークシティーの寿司レストラン”でもよい。そのような例において、レポジトリは、ニューヨークシティーの境界を示すエリアの位置ＩＤ等の記述子を戻すことができる。

クエリーアプリケーションの一つの共通的な例は、共通の検索エンジンであって、それによりユーザは、任意の適切な形式でクエリーを入力でき、クエリーに最も一致する多数のウェブドキュメント（例えば、ウェブページ）又は他のドキュメントを応答として提供されうる。クエリーが位置関連情報を含む場合、検索結果が、ユーザによって提供された位置関連情報と検索によって位置決めされたドキュメントの、又はそれに関する任意の位置関連情報との間の相互関係によって部分的に提供及びソートされうる。

また、アドレス抽出器２０は、レポジトリ１２と相互作用することができる。特に、アドレス抽出器２０は、クローリング処理によって識別されたウェブページからの内容を示すドキュメント等の各種ドキュメントをレビューでき、位置に関連しうるそれらドキュメントから情報を抽出でき、レポジトリ１２に対して情報を一致させることができるので、情報が位置に関するか否かを確認することができる。この方法で、位置又は複数の位置は、ドキュメントに関連付けできるので、ドキュメントは、その他のコンテンツによってドキュメントが一致することを識別するのに追加して、又はその代わりに、位置又は複数の位置に基づき一致するとして識別されうる。

丁度言及したレポジトリ１２の使用における各態様は、以下で詳細に検討される。一般に、レポジトリ１２との通信は、レポジトリ１２と相互作用する制御ロジックから単一のリモートプロシージャコール（ＲＰＣ）によって実行されうる。一つの実施形態において、ジオコーディング及びクエリーパースは、各方向における単一のアーギュメントを通過させる単一のＲＰＣインタフェースを使用するサーバ側動作であり、それは、コールを備えた文字列と応答を備えた機械使用可能な位置識別子とである。これらアプリケーションに対するレポジトリの同一位置は、レポジトリに対する往復の遅延を低減し、比較的力強いフィードバック駆動のアルゴリズムを可能にする。また、それは、実行メンテナンスを簡易化しうる。アドレス抽出は、低レベルＲＰＣを介してレポジトリとインタフェースするクライアントロードヘビーライブラリとして実行されうる。そのような配列により、大きなアドレス抽出は、特に最小のレポジトリロードと並行して可能になる。

図２は、位置レポジトリに対する例示的な編成を示す。レポジトリの各位置は、位置ドキュメントによって示され、ここでは簡略的にテーブルのコラムとして示されている。位置ドキュメントに対する各種パラメータ、ｉｄ、アドレス、構造化アドレス、量、及び位置識別子は、３つの例示的な位置毎に示されている。第１位置は、カリフォルニア、マウンテンビューのグーグルキャンパス上のビルディング４２である。第２位置は、ドイツ、ウルムの町である。第３位置は、日本、東京の渋谷列車駅である。

図に示す通り、ｉｄは、多くの形式をとることができる一方、アドレスは一般に、位置を称呼する名前に対してより正式なフォーマットを取る。構造化アドレスもより正式であって、国、州（又は行政エリア）、町（又は地方）、ストリート（又は通路）等のアドレスの各一部のアドレスに対応するタグ又はメタデータを含む。上記の通り、量は、位置の重要性を示し、それは、位置の境界内に含まれたポイントアドレスの数ごとに位置の“サイズ”によって測定されうる。最後に、位置識別子は、任意の適切な機械使用可能で的確な方法であって、それにより地理的ポイント又は地理的エリアを表現する。一つのそのような共通のアプローチは、緯度及び経度である。

図３は、位置関連情報を含むドキュメント又はクエリーの提供に応答して位置識別子を取得するためのシステム４０の概略図である。システム４０は、中央に位置決めされた一群のサービスにしうるサブシステム４２と、各種機能を実行するように接続されたクライアントとを含む。例えば、サブシステム４２の要素は、単一の編成によって所有及び動作でき、各種要素は、ＲＰＣ又は他の技術による等の、編成内でプログラマによってアクセス可能である。

サブシステム４２は、インターネット４６等のネットワークと順番に通信しうるインタフェース４４を介して他の世界と通信しうる。このように、ワイヤレスネットワーク５０を介して動作するワイヤレス装置４８（例えば、ＰＤＡ、ワイヤレス電話、及び他の通信装置を含みうる）、及びホーム又はビジネスコンピュータ５２等のリモート装置は、サブシステム４２と通信することができる。そのような通信は、検索リクエスト等のリクエストと共に、検索リクエストの結果へのリンク等の応答も含むことができる。インタフェース４４は、任意の適切な形式をとることができ、イーサネット（登録商標）、インフィニバンド、及びその他等の周知の規格に従って各種ネットワークハードウェア及びソフトウェアを含むことができる。サブシステム４２における要素の特定配列は、本明細書で検討される動作に必須ではない。

サブシステム４２の一つの特徴は、検索エンジン６６でもよく、クローリング処理による等インターネット上のドキュメント又はウェブページに関する情報を収集するために、インデックスデータベース７０における等それらドキュメントにインデックスを付けるために、それらドキュメントに関するリクエストを受信するために、及びそれらリクエストに対する結果を生成するために必要とされる全ての要素を含むことができる。ユーザからのリクエストは、リクエストプロセッサ５４によって初期に扱われることができ、サブシステム４２によって扱うためにリクエストをフォーマット及びルートするようにする。同様に、応答フォーマッタ５６は、サブシステム４２によって生成された情報を取り、システム４０のユーザに送信するためにそれをフォーマットすることができる。例えば、リクエストプロセッサ５４及び応答フォーマッタ５６は、通常のウェブサーバの要素でも良く、ユーザに送信されたアイテムに関連する宣伝資料を結合する等、追加の機能を提供しうる。

特定のリクエストは、位置識別システムの一部であるパーサ／トークナイザ６０に転送されうる。以下に詳細に説明する通り、パーサ／トークナイザは、検索リクエストからテキストの文字列等のテキストを受信し、相異なる部分（トークン）にそれを分割し、相異なる部分は、それらが位置ベースの情報を示すか否かを判断してそうである場合にその情報が何かについて分析されうる。

トークン化された情報は、パーサ／トークナイザからスコアラ６２へ通すことができる。以下に詳細に説明する通り、スコアラは、それが特定のアプリケーションにどれだけ関連性があるかを判断するためにトークンにおける情報に目を向ける要素である。例えば、スコアラは、位置レポジトリ６８におけるトークン化された情報と位置ドキュメントとの間の一致又はほぼ一致を位置決めするために等、位置レポジトリ６８に記憶された周知の位置情報とトークン化された情報とを比較することができる。スコア化は、以下の詳細な説明を含む任意の適切なアプローチに従って行われうる。

アプリケーション６４は、位置ベースの情報に関する各種機能を実行するためにサブシステム４２の他の要素と相互作用することができる。各種アプリケーションが、パーサ／トークナイザ６０とスコアラ６２とによって提供されたサービスへのアクセスを直ちに有することができ、任意の適切な方法でそれら要素から取得された情報を使用できることを示すように、アプリケーション６４は、図において一般に示される。実際、パーサ／トークナイザ６０及びスコアラ６２は、特に他の要素が単にＲＰＣを発行して応答を待機する必要がある場合に、サブシステム４２の他の要素に対して単一の要素に類似しうる。また、パーサ／トークナイザ６０及びスコアラ６２は、それらの役割を達成するのに必要な追加の機能に実際に結合されてそれを備えることができる。また、それらは、それらの役割を実行することにおいて、他の要素のリクエストを作成するか又はそれに連絡することができる。

全部で、システム４０は、モジュラー要素態様でユーザが必要とするものを提供するための柔軟なメカニズムを提供する。各種アプリケーションは、丁度説明した位置検出基盤を使用するために開発されうる。それらアプリケーションが追加の情報を必要とする場合、それらは、位置検出構造から受信するものに追加しうる。そのような情報が共通的に要求される場合、それを提供する機能性は、位置検出構造に追加されうる。

図４は、ジオコーディングシステムにおける情報フローを示す概略図である。この特定の実施形態において、クライアント７０は、子供の本で発見することがしばしば困難な周知のキャラクタにちなんで名付けられた“Waldo Cluster”として知られる要素にＲＰＣを提供する。リクエストは、“ジオコードリクエスト（ロー）”として単にフォーマットされ、クライアント７０がクラスタ７２にテキストのロー文字列を通過させることを示す。応答は、“ジオコード応答（位置）”としてフォーマットされ、応答が単に戻って来ることを示し、位置に対する緯度及び経度の組合せを示す順序対の数字、又はｉｄ、アドレス、構造化されたアドレス等を備えた全体構造のような所定のフォーマットである。

クラスタ７４内に、ドライバ７４及びモバイル７６要素がある。ドライバ７４は、決定を行いモバイル７６とインタフェースをとる制御ループになりうる。モバイル７６は、地理的情報をデコードするためにスコアラを起動する多数のリーブを有するサーバのクラスタから順になることができる。リーブは、サーバのツリーの一部にすることができ、検索及びスコア化が、並行な分割攻略アプローチを介して実行できる場合に使用されうる。クラスタ７２、ドライバ７４、又はモバイル７６の特定の配列は、本明細書で説明された特徴の動作に必須でなく、必要なスループットを扱うことができる任意の適切な形式を取りうる。

図５は、図４に示したメッセージング処理による等、ジオコーディング情報を取得するための例示的な段階を示すフローチャートである。処理は、“クライアント”によって取られたアクション及び“サーバ”によって取られたアクションによって分割される。この表現は、明確性のために、及び処理を実行するための一例として示される。この表現によって必要とされることを意図する正式なクライアント−サーバアーキテクチャはない。むしろ、クライアントは、単に情報をシークする装置にできる一方、サーバは、情報を提供する装置でもよい。また、クライアントは、リモート装置（例えば、ワイヤレス電話又はＰＤＡ）のように、もう一つの装置に対するサーバとして作用する装置でもよい。

アクション１００において、クライアントは、ジオコードクエリーを送信する。クエリーは、単にユーザによって入力され、リモート装置（それ自身クライアントと見なせる）から受信されたラフ文字列にすることができる。例えば、クエリーは、“1060 W.Addison Street, Chicago, IL 60613”でもよい。また、クライアントは、位置“ヒント”を送信することがある。例えば、そのようなヒントは、クエリーを作成するユーザが立っている（例えば、ユーザによって提供された情報によって、ユーザの位置の三角測量によって、ユーザにサービス提供するワイヤレスタワーの位置を判断することによって、又はＧＰＳ可能装置によって生成されたメッセージヘッダのデータによって判断される）ポイントを含みうる。また、それは、地図の境界ボックス又はユーザがクエリーを作成する時に見ているビューを含みうる。代わりに、ユーザが接続しているドメインの国又はユーザのドメインによって判断されるような、ユーザが位置するエリアを境界付けるポリゴンでもよい。

サーバは、アクション１０２において、クエリーを受信することができ、それが提供される場合にヒントを受信できる。その後クエリーは、標準化及び低減されうる（アクション１０４）。例えば、頭文字が除去されてもよく、省略形が縮小又は延長されてもよく（例えば、“St.”から“street”又はその逆）、文字列の要素間の句読点が除去されてもよい。故に、例えば、以下の３つのクエリーは、以下のように低減されうる。
“Building 42 1600 Amphitheatre Parkway, Mountain View CA 94043 USA”
“Ulm Deutschland”
“日本東京都渋谷区道玄坂１丁目１渋谷駅”から
“building 42 1600 amphitheatre parkway mountain view ca 94043 usa”
“ulm deutschland”
“日本東京都渋谷区道玄坂1丁目1渋谷駅”

その後、文字列は、トークン化されうる（アクション１０６）。特に、アドレスの一部を示す個々の要素は、後の処理のために相異なるトークンに分割されうる。例えば、アドレスの各レベル、例えばユニット、ビルディング、ストリート番号、ストリート、町、州、郵便番号及び国は、位置を示すためのトークンに成されうる。トークン化処理は、任意の適切な形式を取り、特に左右欲張り一致（left-to-right greedy match）を備えた語彙ロードトライ木（lexicon-loaded trie）でもよい。上記３つのクエリーのトークン化されたバージョンは、例えば
[building_42][1600] [amphitheatre_parkway] [mountain_view]
[ca] [94043] [usa]
[ulm] [deutschland]
[日本][東京都][渋谷区][道玄坂][1丁目][1][渋谷駅]

特定のトークンシーケンスは、トークンスペースレポジトリで個々のドキュメントとしてインデックス化でき、関連する位置識別子は、判断される時、添付ファイルとして記憶されうる。トークンをインデックス化する時、バリアント形式も含まれる。例えば、左側の以下のトークンは、右側のバリアント形式を生成する。
[building_42] -> [bldg_42]
[amphitheatre_parkway] -> [amphitheatre_pkwy]
[mountain view] -> [mv]
[ca] -> [california]
[usa] -> [us]
[東京都] -> [東京]
[渋谷区] -> [渋谷]
[1丁目] -> [1]
[1] -> [1番]
[渋谷駅] -> [渋谷]

その後、トークンは、モバイル要素に提供でき（アクション１０８）、それは、要素を受信し、位置にそれらを一致させるよう試みることができる（アクション１１０）。一つの実施形態において、モバイルのルールは、順番に全てのトークンを含む全ての位置ドキュメントを検出することであって、クエリートークン毎に最大２つのレポジトリトークンを飛び越す。ヒット毎に、モバイルは、添付ファイルからドキュメントの位置を読み出し、結果にそれを添付し、以下に説明するようにスコア化で結果を使用する。

一致がない場合（アクション１１２を参照）、バックオフ方法が採用されうる。そのような状況において、レポジトリは、ユーザが見ているか又はクエリーが正しくないことがある特異性を含まなくてもよい。このバックオフアプローチにおいて、新たなクエリーは、一つのトークンを欠く多数のクエリーを結合することによって形成され、即ちトークン化された文字列の各順列は、一つのトークン未満で、レポジトリにクエリーされる。故に、レポジトリドキュメントが
[building_43] [1600] [amphitheater_parkway] [mountain_view]
[94107] [ca] [us]
であり、トークン化されたクエリーが
[396C] building_43] [1600] [amphitheatre_parkway] [94106]
である場合、２つのトークンの分割ルールを使用するヒットはない。それはなぜなら、クエリーは、レポジトリ内にないルーム指定子を含み、エリアコードがオフだからである。その後、以下のトークン化された文字列は、第１バックオフラウンドのクエリーである。
[building_43] [1600] [amphitheatre_parkway] [94106]
[396C] [1600] [amphitheatre_parkway] [94106]
[building_43] [amphitheatre_parkway] [94106]
[396C] [building_43] [1600] [94106]
[396C] [building_43] [1600] [amphitheatre_parkway]

この一組のクエリーでもヒットを生成しないので、以下のトークン化されたフレーズがクエリーされるように第２レベルのバックオフが使用される。
[1600] [amphitheatre_parkway] [94106]
[building_43] [amphitheatre_parkway] [94106]
[building_43] [1600] [94106]
[building_43] [1600] [amphitheatre_parkway]
[396C] [amphitheatre_parkway] [94106]
[396C] [building_43] [1600] [amphitheatre_parkway] [94106]
[396C] [1600] [94106]
[396C] [1600] [amphitheatre_parkway]
[396C] [building_43] [94106]
[396C] [building_43] [amphitheatre_parkway]

ここで、一致が検出される。多数の一致があるイベントにおいて、高いスコアラは、戻される。

一度一致が検出されると、それらがスコア化されうる。スコア化は、“量”の一致、ヒント又は複数のヒント、又はその２つの組合せに基づくことができる。そのようなスコア化は、例えばユーザが単に“Mountaion View”を要求し、“Mountaion View CA”及び“Mountain View Drive, San Antonio TX”に対する一致を生成する時、結果における曖昧さを解消できる。アクション１１６において、システムは、ヒントが受信されたか否かを判断する。ヒントが受信されなかった場合、結果は、比較的低い量を有する結果より上にランク付けされた比較的高い量を有する結果と共に、それらの量に従ってスコア化されうる（アクション１１８）。

ヒントが受信された場合、ヒント（例えば、位置の形式）は、スコアを生成するために量の値に結合されうるので、ヒントに比較的近接する結果は、比較的高いスコアが与えられる（アクション１２０）。一つのそのようなスコア化技術は、ヒントと結果との間の距離を結果に対するスコアの要因に含める。公式は例えば、
Score=mass/(distance(hint,result)+C)
ここでＣは、適切に選択された定数である。

バックオフが使用された場合、トークン化された文字列の各種順列に基づく結果はまた、適切に重み付けされうる。例えば、各トークンは、その内容に基づき重さが割り当てられてもよい。例として、アスキー文字は、１の重さを有することができ、また音声utf8文字は、１の重さを有することができる。数は、utf8文字が結合されるように２の重さを有することができ、他の全ては、２０等の比較的高い重さを有することができる。その後、トークンの重さは、文字列におけるそれらの位置に従って適合でき、候補文字列のエラー又は距離は、それを形成するために落とされたトークンの重さの合計にすることができる。

スコアが一致に対して作成されると、モバイル要素は、ドライバ要素に結果又は複数の結果を通過させうる。その後ドライバ要素は、結果を分析でき、それらが満たされる場合にクライアントにそれらを戻すことができる（アクション１２２）。最後に、クライアントは、一対の緯度／経度等の結果を取り、それが起動しているアプリケーションで適切にそれらを使用することができる。

ここで、検索は、２つの局面で発生しうる。（１）クエリー（トークンシーケンス）に一致するＮ（パラメータ）ドキュメントのリストが検出される場合、検索。（２）それらが関連して順序付けられている場合、スコア化。いくつかのスコア化は、検索の間に完了され、位置の量によってドキュメントをソートできるので、頂点のＮの一致が位置スコアに単に基づく時に検出される検索の間にそれは知られうる。故に、ヒント付けされていない検索結果に対して、検索は、かなり早くすることができる。ヒント付けされた検索結果に対して、追加のクエリーが検査されることが必要なことがある。

例えば、クエリー“mountain view”が位置１で“mountain view, ca”と、位置３で“mountain view drive el paso, tx”とを上げる場合、システムは、作動のために位置ヒントクエリーに対する２つの追加の結果を検索（及びスコア化）する必要がありうる。また、及び結果として、ヒント付けは、いくつかの場合に作動しないことがある。例えば、一つの家一つの数のみ含む地図の緯度／経度境界ボックスでヒント付けされたペダンティック（pedantic）クエリー“１”は、例えば失敗する運命にある。“１”の検索は、所望のドキュメントが検出される前に多数の、多数のドキュメントをおそらく検出し、それは一般に、実際的ではない。

問題は、その緯度／経度位置を記述する一つ以上のタームをドキュメントと共にインデックス付けして適切な領域内のドキュメントのみを検索時間に検索し比較的かなり短いドキュメントリストを考慮に入れることによって取組むことができる。例えば、地球は、三角形メッシュの変化レベル、面の名前、及びその後面に対するドキュメントの関連付けを使用して示すことができる。このアプローチは、特定のアプリケーションに役立つことができる。

図６は、ドキュメントからアドレス情報を抽出してドキュメントにアドレスを割り当てるための例示的な段階を示すフローチャートである。一般に、この処理は、ドキュメントに関する位置情報のインデックスを構築してドキュメントの位置ベースの検索を後に可能にするのに適切である。一つのそのような例は、グーグルローカルサービスである。この処理は、“私はドキュメントを有する；それが含むアドレスは何か、それらが居るのは世界のどこか？”という仮説上の質問に回答する。

一般に、図示された処理は、クライアント側で小型化されたウェブレポジトリ上で発生して、継続中のクエリーを提供している通常のレポジトリ上に不必要なロードが置かれることを回避しうる。例えば、小型化されたレポジトリは、メインレポジトリで検出された特定のバイグラムのブルームフィルタでもよい。例えば、これらのバイグラムは、メインレポジトリに一部又は全ての非数バイグラムと、アドレス内の１つ又は２つのトークンを飛び越えるバイグラムとを含むことができる。特定の実施形態において、アドレス抽出ライブラリは、モバイル要素の直接的使用を行うことができる。この方法でサーバへなされたアクセスを限定することによって、サーバ上のロードは、顕著に低減されうる。

図６を参照すると、クライアントは先ず、位置レポジトリの小型形式を取得するリクエストを作成して（アクション２００）、サーバは、レポジトリのその小型形式を戻す（アクション２０２）。また、クライアントは、可能な場合、全てのレポジトリを取得することができ、それ自体レポジトリの小型バージョンを生成する多数の連絡を作成することができる。また、本明細書中で説明された各種アクションは、サーバ自身によって実行でき、他のアクションは、適宜追加、除去又は結合されてもよい。一度クライアントが小型レポジトリを有すると、それは、将来の使用２０４に備えてそれを記憶することができる。また、小型バージョンのレポジトリは、例えばメインレポジトリが更新される時ならいつでも等、周期的に更新されうる。

アクション２０４において、クライアントは、第１ドキュメントにアクセスする。ドキュメントは、分析されるべき任意の関連タイプのファイルを含むことができ、ユーザは、そのファイルに興味がある。一般的な例は、ウェブページ又は他のマークアップドキュメント、ワードプロセッサドキュメント、pdfファイル、データベース、電子メール、Usenetグループディスカッション、ブログ、カタログ等を含む。ドキュメントは、位置に関連する要素を識別するためにスキャンでき、それら要素は、上記説明したそれらに類似した方法で標準化及びトークン化されうる（アクション２０６）。その後クライアントは、良好なアドレス仮説を探すトークンを介してスキャンする。一つの実施形態において、クライアントは、３つの連続したトークンのランニング組（running set）を追跡でき、３つからなる一組における２つのペアワイズ組合せ（pairwise combination）がブルームフィルタの存在チェックを通過するか否かを探す。例えば、トークンがＡＢＣの場合、クライアントは、（ＡＢ）及び（ＢＣ）の存在についてチェックする。

一致がない場合、クライアントは、トークンの次の一組に進み（アクション２１０）、一致について再度チェックする（アクション２０８）。連続した組に一致がある場合、トークンは、ブルームフィルタ内にペアワイズ存在チェックに関する一致がもはや無くなるまで、全体の組を比較的長くするように追加される（アクション２１２）。その後クライアントは、生成されたトークンシーケンスでモバイルにクエリーする（アクション２１４、２１６）。ヒット又は複数のヒットがある場合、シーケンスが成長し、ヒットについて再度チェックされ（アクション２１８、２２０）、ヒットがない場合、シーケンスがトークンによって縮小され再試行される。処理は、最長のヒット生成トークンシーケンスが検出されるまで反復される（アクション２１６、２１８、２２０、２２２、２２４）。

ドキュメントに対する最大のトークンシーケンスが位置決めされると、対応する位置ドキュメントに対する位置識別子又はジオデータが検出され、ドキュメントに添付される（アクション２２６）。ドキュメントの検索が続く場合（アクション２２８）、システムはさらにドキュメントを処理するために戻る。さらにドキュメントがない場合、システムは例えば、いくつかの更なるコマンド又は追加のドキュメントが利用可能になるまで待機する（アクション２３０）。この方法で、関連アドレス又は位置情報は、ドキュメントに位置決めされ、機械使用可能な位置識別子に関連付けることができる。

図７は、位置情報のレポジトリを構築するための例示的な段階のフローチャートである。初めに、ソースデータの収集がアセンブルされうる（アクション２５０）。このデータは、例えば以下のデータのフォーマットを取りうる。
1600, AMPHITHEATRE PARKWAY, MOUNTAIN VIEW, CA,
37.422845, 41.72882261
その後システムは、ソースデータの各インスタンスの順列毎に位置ドキュメントを生成しうる。上記例に対して、順列は以下のように、“最小”から“最大”へ作動しうる。
1600 AMPHITHEATRE PARKWAY
MOUNTAIN VIEW CA -> 37.422845,
41.72882261
AMPHITHEATRE PARKWAY
MOUNTAIN VIEW CA -> 37.422845,
41.72882261
MOUNTAIN VIEW CA -> 37.422845,
41.72882261
CA -> 37.422845,
41.72882261

その後、これら４つの順列、及び全ての他のポイントに対する順列は、共通の識別子を有する全ての他の位置と結合されうる。例えば、個々の位置毎の量（一般に１）は、全ての他の位置に対する量と結合されて、例えばカリフォルニア等の比較的広範なエリアに対する量の数を形成することができる。ロジックタームにおいて、全ての基本的ポイント又はエリアの量が（結合動作毎に（per a union operation））形成され、それらポイント又はエリアに共通の識別子に関する量を形成する。同様に、共通の識別子の境界は、全ての基本的エリアの境界の結合である。その後、共通の識別子は、それらが直接リクエストされる時、又は“UNKNOWN STREET MOUNTAIN VIEW CA”等、不完全なクエリーへのフォールバックとしてリクエストされる時、アクセスされうる。

図８は、クエリーから位置情報をパースするための例示的段階のフローチャートである。この方法は、クエリーが形式ＱＬ又はＬＱで一般に提供された過程で作用し、ここでＱは、クエリー関連タームで、Ｌは、位置関連タームである。例えば、クエリー“pizza palo alto”に対して、Ｑは、“pizza”でＬは、“palo alto”である。また、追加のタームは、Ｑ及びＬタームの各エンド上に位置決めされうる。

初めに、方法は、クエリー文字列を取得し（アクション２７０）、その後上記一つの実施形態において説明したように、文字列をトークン化する（アクション２７０）。その後方法は、全ての分割ポイントがチェックされるまで、トークンを介して段階的に進行し、文字列の位置要素からクエリー要素を分割する可能な分割ポイントを識別する（アクション２７６、２７８）。各ポイントにおいて、仮の位置関連トークンは、位置レポジトリに対してテストされ、分割ポイントは、文字列を介し反復して移される。全ての分割ポイントがチェックされた時、又は十分な数がチェックされた時、処理は、適切な位置識別子として最長のトークン文字列を識別する。クエリーの残りは、クエリーの後続部分として取られる。その後、クエリー文字列のパースされた要素は、クエリーの位置ベースの部分によって収集されたローカル検索に限定されるように、クエリーの後続の部分を一致させる検索結果を生成するために等、他のアプリケーションによって適切なものとして使用されうる。

図９は、位置情報を抽出及びジオコーディングするための要素を示す関連図である。このモデルにおいて、アドレスは、標準的な書き込み形式（canonical written form）を有し、その要素は、書き込みバリアント（written variant）を有しうる。例えば、日本のアドレスにおいて、ブロック数をマークするのに使用されるローン（lone）“番”はしばしば、アスキー又はワイドダッシュで書き込まれるので、（“番”->“―”）は、良好なバリアント拡張（good variant expansion）になりうる。しかしながら、逆は、あまり正確でない拡張となりうる。さらに、全てのアドレスが標準的な形式である場合、逆のルールは、不必要になりうる。

バリアントは、ベースターム及び周知の書き込みバリアントからなる。（base -> variant）毎の拡張は、有効でありうるが、（variant -&gtp;base）は、ありえない。

位置コンバイナは、全ての入力位置を結合し、固有のアドレスを備えた一組の位置を生成する。地図の局面において、トランジションは以下の形式を取りうる。
map location -> Fingerprint (location.address()),
location;

低減局面において、トランジションは以下の形式を取りうる。
if there are multiple values
log an error;
output the first value;

バリアントコンバイナは、推移的拡張を実行することによって等、全てのバリアントを結合しうる：((a -> b）and (b -> c)) -> (a -> c)
別に説明すると、
map<string, hash_set<string>>variant_map;
load in all variants into variant_map
until size of variant_map ceases to grow
for each a in variant_map
for each b of variant_map[a]
for each c of variant map[b]
variant_map[a].insert(c);
write out variants;

語彙ビルダは、以下のようにバリアントタームから語彙を構築する。
set<string> lexicon;
for each Variant {
insert base into lexicon;
insert all variants into lexicon;
}
write lexicon to file;

アドレストークナイザは、文字列が与えられた時、一組の語彙ワードへそれをトークン化して、任意の認識不可能な部分を省略することができる。処理は、欲張り一致を実行しうる。処理は、それが供給された語彙へトークン化する困難な要求を有することができる。代替の表現では、
load lexicon into a trie;
while there’s text left to tokenize{
find the longest matching lexicon term;
if a term was found
add a token and advance the start pointer
by length(term);
else
advance the start pointer by 1;
}

そのようなアプローチは、中国、日本及び韓国のアドレス組に対して適切でありうる。レポジトリビルダは、一組のLocationからレポジトリを構築する。
load Variants into memory;
for each Location {
start a new document;
use an AddressTokenizer to tokenize
Location::address;
for each token {
index the token;
add index entries for all variants of the
token;
}
attach Location::score;
attach Location::plane_geometry;
}

一部のバリアントは、生成可能でありうるが（例えば、“street→st”）、他はそうでない。故に、バリアントを生成するにおいて自動的なアシスタンスを有することが助けとなりうる。手動及び自動のバリアント生成の混合が使用され、又は完全に自動又は完全に手動の生成が使用されて複雑性を低減する。また、変形は、反転され ((a -> b) -> (b -> a))、その後クエリーを拡張するようランタイムで使用されうる。

レポジトリは、（１）インデックス付けされたトークンを含む“ボディ”トークンスペースと、（２）ロケーションスコアを含む“スコア”添付ファイル（優先テーブルを構築するため及びスコア化の間に使用される）と、（３）プレーンジオメトリを含む“plane_geometry”添付ファイルとを含む合成物にすることができる。

検索は、クエリー文字列を取ること、及びそれをフレーズタームに変換することによって実行され、各サイド上で引用を効率的にスラップすることができる。[max_separation:n]修飾語句は、開始時に追加されうるので、クラフトの特定量は、仲介的なアドレス要素に出現することができる。ｎファクターは、比較的良好な結果又は実行に対して適合されうる。

抽出は、以下のように発生しうる。
tokenize the string;
prepend and append made-up(not-in-lexicon) tokens;
initialize a token range to point to the first token;
while the range-end isn’t beyond the end of the
tokens {
geocode count the number of addresses matching
the token range;
if the count is zero {
if the last count was 1
if the previous token range is a reasonable
address
geocode the previous token range to get a
Location and save it;
move the range-start forward one token;
if the range start is beyond the range end
move the range-end forward one token;
} else {
move the range-end forward one token;
}
}
return saved Locations;

また、テキストエントリに対して丁度説明された特徴は、ビデオ認証等、音声認証又は他の手段を用いてデータを取得するシステムに適用されうる。音声等のフォーマットからの入力の転換は、音声認識を他のデータエントリ技術に組込むのに使用される任意の数の周知の手段によって発生しうる。例えば、検出された音声コマンドは、VoiceXML又は他の使用可能なフォーマットのようなフォーマットに転換できる。また、システムは、各種言語で入力されたデータ上で動作しうる。

また、入力を提供するための他の方法は、適切なものとして使用されうる。例えば、装置は、入力を提供しうる加速度計を備えうる。例えば、ユーザは、装置を動かしてタームが入力されたことを示すことができる。また、ユーザは、装置を前又は後ろに傾けることによって、リスト等からアイテムを選択することができる。

本明細書中で使用された通り、ターム“電子ドキュメント”及び“ドキュメント”は、一組の電子データを意味し、ファイルに記憶された電子データとネットワーク上で受信された電子データとの両方を含む。電子ドキュメントは、ファイルに対応する必要はない。ドキュメントは、他のドキュメントを保持するファイルの一部に、対象のドキュメント専用の単一ファイルに、又は一組の調整されたファイル（coordinated file）に記憶されうる。

本明細書中に説明されたシステム及び技術の各種実施形態は、デジタル電子回路、集積回路、特に計画的（designed）ASIC（アプリケーション専用の集積回路）、コンピュータハードウェア、ファームウェア、ソフトウェア及び／又はそれらの組合せで実現されうる。これら各種実施形態は、少なくとも一つのプログラマブルプロセッサを含むプログラマブルシステム上で実行可能及び／又は解釈可能な一つ以上のコンピュータプログラムに実施形態を含むことができ、それは、記憶システム、少なくとも一つの入力装置、及び少なくとも一つの出力装置に対してデータを送受信及び命令を交わすように接続された、特定又は一般目的にすることができる。

また、これらコンピュータプログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション又はコードとしても知られる）は、プログラマブルプロセッサに対する機械命令を含み、ハイレベル手順及び／又はオブジェクト指向プログラミング言語、及び／又はアセンブリ／機械言語で実行されてもよい。本明細所で使用される通り、ターム“機械読取可能な媒体”は、プログラマブルプロセッサに機械命令及び／又はデータを提供するように使用される任意のコンピュータプログラム製品、機器及び／又は装置（例えば、磁気ディスク、光学ディスク、メモリ、プログラマブルロジックデバイス（PLD））をいい、機械読取可能な信号として機械命令を受信する機械読取可能な媒体を含む。ターム“機械読取可能な信号”は、プログラマブルプロセッサに機械命令及び／又はデータを提供するのに使用された任意の信号である。本明細書中で説明したプロセッサは、機械読取可能な媒体又は機械読取可能な信号上に記憶された命令が実行される時に実行されるコマンドとして実行されうる。

ユーザに命令を提供するために、本明細書中で説明したシステム及び技術は、ユーザに情報をディスプレイするためのディスプレイ装置（例えば、CRT（ブラウン管）又はLCD（液晶ディスプレイ）モニタ）と、ユーザがコンピュータに入力を提供できるキーボード及びポインティングデバイス（例えば、マウス又はトラックボール）とを有するコンピュータ上で実行されうる。他の装置の種類もユーザと相互作用するのに使用でき、例えばユーザに提供されたフィードバックは、感覚フィードバックの任意の形式にでき（例えば、視覚フィードバック、音声フィードバック、又は触覚フィードバック）、及びユーザからの入力は、音響、発声又は触覚入力を含む任意の形式で受信されうる。

本明細書で説明したシステム及び技術は、バックエンド要素を（データサーバとして）含み、ミドルウェア要素（例えばアプリケーションサーバ）を含み、フロントエンド要素（例えば、ユーザが本明細書で説明したシステム及び技術の実行に相互作用しうるグラフィカルユーザインタフェース又はウェブブラウザを有するクライアントコンピュータ）を含み、又はそのようなバックエンド、ミドルウェア、又はフロントエンド要素の任意の組合せを含む計算システムで実行されうる。システムの要素は、デジタルデータ通信の任意の形式又は媒体によって実行されうる（例えば、通信ネットワーク）。通信ネットワークの一例は、ローカルエリアネットワーク（“LAN”）、広域エリアネットワーク（“WAN”）及びインターネットを含む。

計算システムは、クライアント及びサーバを含むことができる。一般に、クライアント及びサーバは、互いに遠隔にあり、通信ネットワークを介して通常相互作用する。クライアントとサーバとの関係は、各コンピュータ上で起動して互いに対してクライアント−コンピュータ関係を有するコンピュータプログラムによって生じる。

一部の実施形態について詳細に説明したが、他の実施形態が可能である。本開示の一部は、制約されたキーボードを備えたポータブル装置を介する動作について検討するが、フルキーボードを備えたフル機能のコンピュータを含む任意の数の装置が支援されてもよい。また、図示されたロジックフローは、所望の結果を達成するために、図示された特定の順番又はシーケンシャルオーダを必要としない。また、他の段階が提供されてもよく、又は段階が、説明されたフローから削除されてもよく、他の要素が、説明されたシステムに対して追加又は除去されてもよい。他の実施形態は、以下の特許請求の範囲内でありうる。

図１は、各種アプリケーションに対する位置識別子を検索するためのシステムを概略的に示す。図２は、位置レポジトリに対する例示的な編成を示す。図３は、位置関連情報を含むドキュメント又はクエリーの提供に応じて位置識別子を取得するシステムの概略図である。図４は、ジオコーディングシステムの情報フローを示す概略図である。図５は、ジオコーディング情報を取得するための例示的な段階を示すフローチャートである。図６は、ドキュメントにアドレスを割り当てるためにドキュメントからアドレス情報を抽出するための例示的な段階を示すフローチャートである。図７は、位置情報のレポジトリを構築するための例示的な段階のフローチャートである。図８は、クエリーから位置情報をパースするための例示的な段階のフローチャートである。図９は、位置情報を抽出及びジオコーディングするための要素を示す関係図である。

符号の説明

６０パーサ／トークナイザ
６２スコアラ
６４アプリケーション

Claims

コンピュータ実行方法であって、
一つ以上の位置関連トークンを含むクエリーを受信する過程と、
一つ以上の位置関連トークンに関して位置情報のレポジトリにクエリーして位置関連トークンに実質的に一致する位置に関連付けられる一つ以上の位置ドキュメントを識別する過程であって、各位置ドキュメントは、位置ドキュメントに関連付けられる位置の地理的サイズを示す位置に関する量を有する、過程と、
一つより多い位置ドキュメントが識別される時に識別される位置ドキュメントをスコア化するために、位置の量を使用し、識別される位置ドキュメントから特定の位置ドキュメントを選択するために、スコアを使用する過程と、
選択される位置ドキュメントに関連付けられる位置に関してクエリーに応答する過程と、
クエリーに関してクエリー独立地理的表示を受信して、一つ以上の識別される位置ドキュメントをスコア化するために、クエリー独立地理的表示を使用する過程と
を具備することを特徴とする方法。
クエリーは、リモート装置から受信され、クエリー独立地理的表示は、リモート装置が位置決めされた位置と、装置上にディスプレイされた地図の境界ボックスと、クエリーが受信されたインターネットドメインに対応する領域とからなるグループから選択されることを特徴とする請求項１に記載の方法。
識別される位置ドキュメントをスコア化して特定の位置ドキュメントを選択するために量を使用する過程は、クエリー独立地理的表示間の距離に対するドキュメントの量の割合に基づき、位置ドキュメントに関するスコアを決定する過程を具備することを特徴とする請求項１に記載の方法。
一つ以上の位置関連トークンに関して位置情報のレポジトリをクエリーする過程は、一つ以上の位置ドキュメントが比較的少ない数の一つ以上の位置関連トークンに一致する位置を有すると識別されるまで、比較的少ない数の一つ以上の位置関連トークンを使用してレポジトリを再帰的にクエリーする過程を具備することを特徴とする請求項１に記載の方法。
比較的少ない数の一つ以上の位置関連トークンを使用してレポジトリをクエリーする過程は、一つ以上のトークンの複数の順列に関してレポジトリをクエリーする過程を具備し、各順列は、一つ以上のトークンのうち１つを削除することによって形成されることを特徴とする請求項１に記載の方法。
比較的少ない数の一つ以上の位置関連トークンを使用してレポジトリをクエリーする過程は、一つ以上のトークンの複数の順列に関してレポジトリをクエリーする過程を具備し、各順列は、一つ以上のトークンのうち２つを削除することによって形成されることを特徴とする請求項５に記載の方法。
一つ以上のトークンの各順列に重み付けする過程と、
各順列を使用してレポジトリをクエリーする過程からの結果をスコア化するために重み付けを使用する過程と
をさらに具備することを特徴とする請求項５に記載の方法。
重み付けは、その内容に基づき各トークンに重みを割り当てる過程と、
クエリー内のトークンの位置に従って重みを適合する過程と
を具備することを特徴とする請求項７に記載の方法。
クエリーは、検索リクエストを具備し、請求項１に記載の方法は、検索リクエストおよび位置識別子に基づきドキュメントを識別するために、取得した位置識別子を使用する過程をさらに具備することを特徴とする請求項１に記載の方法。
一つ以上のクエリー関連タームを決定するためにクエリーをパースする過程と、
検索結果のランク付けリストを生成するために、取得した位置識別子および一つ以上のクエリー関連タームを使用する過程と
をさらに具備することを特徴とする請求項１に記載の方法。
位置ベースのデータ収集及び分配システムであって、
一つ以上のリモートクライアントからデータクエリーを受信するリクエストプロセッサと、
データクエリー内の地理的な位置関連トークンを識別する位置ベースのトークナイザと、
位置ドキュメントに関連付けられる位置の地理的サイズを示すドキュメント毎に量を使用して、位置情報のレポジトリで位置ドキュメントをスコア化することによって、データクエリに関連付けるために、緯度および経度を取得するための手段と
を具備することを特徴とするシステム。
位置ベースのデータ収集および分配システムであって、
命令を格納する一つ以上のメモリと、
一つ以上のメモリに格納される命令を実行するよう構成される一つ以上のプロセッサであって、
一つ以上の位置関連トークンを含むクエリーを受信し、
位置関連トークンに実質的に一致する位置に関連付けられる一つ以上の位置ドキュメントを識別するために一つ以上の位置関連トークンに関して位置情報のレポジトリをクエリーし、各位置ドキュメントは、位置ドキュメントに関連付けられる位置の地理的サイズを示す位置の関連する量を有し、
一つより多い位置ドキュメントが識別される時に識別される位置ドキュメントをスコア化するために位置の量を使用し、識別される位置ドキュメントから特定の位置ドキュメントを選択するためにスコアを使用し、
選択される位置ドキュメントに関連付けられる位置に関してクエリーに応答する
ように構成されるプロセッサと
を具備することを特徴とするシステム。
一つ以上のプロセッサは、クエリーに関してクエリー独立地理的表示を受信し、一つ以上の識別される位置ドキュメントをスコア化するために、クエリー独立地理的表示を使用するようさらに構成されることを特徴とする請求項１２に記載の位置ベースのデータ収集および分配システム。
クエリーは、リモート装置から受信され、クエリー独立地理的表示は、リモート装置が位置決めされた位置と、装置上にディスプレイされた地図の境界ボックスと、クエリーが受信されたインターネットドメインに対応する領域とからなるグループから選択されることを特徴とする請求項１２に記載の位置ベースのデータ収集および分配システム。
一つ以上のプロセッサは、クエリー独立地理的表示と位置ドキュメントの関連位置との間の距離に対する位置の位置ドキュメントの量の割合で位置ドキュメント毎にスコアを決定することによって、識別される位置ドキュメントをスコア化するようさらに構成されることを特徴とする請求項１３に記載の位置ベースのデータ収集および分配システム。
一つ以上の位置関連トークンに関して位置情報のレポジトリをクエリーする構成は、一つ以上の位置ドキュメントが比較的少ない数の一つ以上の位置関連トークンに一致する位置を有すると識別されるまで、比較的少ない数の一つ以上の位置関連トークンを使用してレポジトリを再帰的にクエリーする構成を具備することを特徴とする請求項１２に記載の位置ベースのデータ収集および分配システム。
比較的少ない数の一つ以上の位置関連トークンを使用してレポジトリをクエリーする構成は、一つ以上のトークンの複数の順列に関してレポジトリをクエリーする構成を具備し、各順列は、一つ以上のトークンのうち１つを削除することによって形成されることを特徴とする請求項１６に記載の位置ベースのデータ収集および分配システム。
比較的少ない数の一つ以上の位置関連トークンを使用してレポジトリをクエリーする構成は、一つ以上のトークンの複数の順列に関してレポジトリをクエリーする構成を具備し、各順列は、一つ以上のトークンのうち２つを削除することによって形成されることを特徴とする請求項１７に記載の位置ベースのデータ収集および分配システム。
一つ以上のプロセッサは、一つ以上のトークンの各順列に重み付けし、各順列を使用してレポジトリをクエリーした結果をスコア化するために重み付けを使用するようさらに構成されることを特徴とする請求項１８に記載の位置ベースのデータ収集および分配システム。
重み付けする構成は、その内容に基づき各トークンに重み付けを割り当て、クエリー内のトークンの位置に従って重みを適合する構成を具備することを特徴とする請求項１９に記載の位置ベースのデータ収集および分配システム。