JP2008535108A - マルチモードのロケーションベースのｅ−ディレクトリサービス利用可能の方法、システム、及び装置 - Google Patents

Abstract

本発明の方法はロケーションベースの供給者情報へのユーザ要求を行うユーザへｅディレクトリサービスを提供する際の応答を準備する。方法は、ユーザが供給者情報を要求する所望ロケーションをユーザ要求から識別する工程、供給者ディレクトリを問い合わせるときに有用な情報要素をユーザ要求から識別する工程、第１の供給者ヒットの生成のため所望ロケーションと情報要素で第１の供給者ディレクトリを問い合わせる工程、ｗｗｗ供給者ヒットの生成のため所望ロケーションと情報要素でｗｗｗを問い合わせる工程、第１の供給者ヒットをｗｗｗ供給者ヒットとマージして供給者リストの供給者毎の複数事実を含む供給者リストを形成する工程、所望ロケーション近傍でリスト内全ての供給者ヒットを分類する工程、二重の供給者ヒットのパージの工程、及び供給者リストをフォーマットしユーザに対するビューデバイスに関する提示に無関係の事実を除く工程を含む。

Description

本発明は、概略、ロケーションベースのｅ−ディレクトリサービスに関し、特に、そのようなサービスを供給する通信多重モードの利用に関するが、それに限定されるものではない。

一般的なオンラインディレクトリサービスは周知であるが、大抵のものは正確性及び完全性を酷く欠如する。少数のロケーションベースのディレクトリサービスは、“自動位置検出”技術がセルラネットワークに配置されることを現在要求するが、この技術は商業用実用フォームでは未だ利用可能ではない。ＧＰＳ技術は可能な代替手段として評価されているが、この技術は、今日北米で利用される殆どの携帯電話の買い換えを要求するものである。所持者であっても他の誰であっても、そのために終日しかも毎日居場所を知られるということを多くの人々は単純に望まないのであるから、自動位置検出は尚異論の多い問題点である。

現今、携帯電話、パーソナルデジタルアシスタンス（ＰＤＡ）電子メール、及び同様のプロトコルのためのインスタントメッセージ、簡単なメッセージシステムは、馴染みのワールドワイドウエブ（“ＷＷＷ”）によりサポートされるグラフィックプロトコルではなく、テキストベースの配信に依存する。そのようなテキストベースのシステムの人気が増大することで、新しい市場が形成されそれに誘引されたユーザが登場してきており、更にそれらユーザは低帯域技術による高速のメッセージングを要求する。現在、“Ｙｅｌｌｏｗ Ｐａｇｅｓ（登録商標）”若しくはＧｏｏｇｌｅ（登録商標）／Ｙａｈｏｏ（登録商標）／ＭＳＮ（登録商標）などの膨大なデータ源が問い合わされることは無く、その結果、効果的にそのようなテキストベースのシステムに戻ることになっている。

現今、インスタントメッセージのプロダクト“ＡＩＭ”を介して、アメリカンオンライン（登録商標）（“ＡＯＬ”）は、ユーザが都市の即ちジップコードの情報を利用してローカルのＹｅｌｌｏｗ Ｐａｇｅｓ（登録商標）データベースから情報を検索できるサービスを導入した。不都合なことに、ＡＩＭには、一つのみのジップコード即ち都市が要求毎、ユーザ毎に格納されるに過ぎない、という問題点がある。また、ＡＩＭの不都合点は、（例えば、商号やカテゴリによって供給者をサーチできる）サーチのためのコマンド記述法を利用していないことであり、そのため初期成果が殆ど妥当でなく十分に妥当な結果を得るには更なる問い合わせが要求されてしまう。更に、ＡＩＭサーチエンジンは、町／市ラインを交差させておらず、従って２つの市の間のボーダ上のユーザは、供給者がどの市で活動するかに関わりなく、最も近接の供給者ではなく確認する市内の承認を位置付けるに過ぎない。それゆえ、単なる境界や人的制約により限定されない真のロケーションベースのサービスが求められている。

その実施形態の一つでは、本発明は、適時の特定地点でのユーザへの供給者の地理上の近傍に基づいて、Ｙｅｌｌｏｗ Ｐａｇｅｓ（登録商標）及び／又は他のリソースを用いて商人に関する限定された情報をユーザに検索させる新規の方法を実装する新規のシステムを含む。

本発明に係る実施形態によれば、ロケーションベースの供給者情報に対するユーザ要求を行うユーザへｅ−ディレクトリサービスを提供する際に、応答を準備する方法が提示される。該方法は、ユーザが供給者情報を要求する所望のロケーションを、上記ユーザ要求から識別するステップ、供給者のディレクトリを問い合わせるときに有用な少なくとも一の情報要素を、上記ユーザ要求から識別するステップ、第１の供給者ヒットを生成するために、上記所望のロケーションと上記情報要素を利用して、第１の供給者ディレクトリを問い合わせるステップ、ワールドワイドウエブ（ｗｗｗ）供給者ヒットを生成するために、上記所望のロケーションと上記情報要素を利用して、ワールドワイドウエブ（ｗｗｗ）を問い合わせるステップ、上記第１の供給者ヒットを上記ｗｗｗ供給者ヒットとマージして、供給者リスト内の個々の供給者に関する複数の事実を含む供給者リストを形成するステップ、上記所望のロケーションの近傍で、上記リスト内の全ての供給者ヒットを分類するステップ、二重の供給者ヒットをパージするステップ、及び、上記供給者のリストをフォーマットして、上記ユーザに対するビューデバイスに関する提示に無関係の事実を除去するステップを含む。

先行技術の不都合点を克服するために、モバイルデバイスの実際の帯域幅が増加する際に、グラフィックサポートに妥協することなく、テキストベースの環境で現在の技術の問題点を扱う新しい技術が提供される。ユーザ要求は、セル／Ｂｌａｃｋｂｅｒｒｙ（登録商標）／ＰＤＡを利用して音声電話により初期化され、ＳＭＳ／ＩＭ若しくはＢｌａｃｋｂｅｒｒｙメールも利用して応答されてもよい。今日他の周知の検索手段では利用可能で無い新しい機能は、問い合わせに関するインプットとアウトプットを分離できることである。例えば、自動車でドライブしている間に、ユーザは音声利用可能システムを利用してサービスを問い合わせることができ、ＳＭＳを介してユーザの携帯電話に、更にｅメールを介してユーザのＢｌａｃｋｂｅｒｒｙに、アウトプットを送信でき（、ユーザがドライブを停止した後、問い合わせの結果を見ることができ）る。ユーザが好む市場に係る振る舞いを定義するユーザプロファイルの利用が、別の特性である。例えば、ユーザは、エアマイルプログラムの一部であるように特定でき、サービスはより高いエアマイルを提供する供給者をリストする。

本発明に係る一つの実施形態によると、ユーザからの最小限のキー打ちの相互作用でロケーション文脈サーチが可能になる。該実施形態は、受信契約者が小スクリーンセルフォン、カラーＰＤＡ、ラップトップコンピュータ、若しくは他のデバイスであっても、最適なデータフローを保証する独占の帯域幅及びデバイス管理アルゴリズムと、ユーザの経験を、利用する。アーキテクチャは、どのサイズの受信契約者ベース及び／又は商人データベースの要求にも適合するように、拡大可能、延長可能、及び、拡張可能である。該アーチテクチャは、現存のデジタルワイヤレスネットワークへの変更を要求せず、システムに対するパートナの一部に関して資本投資を要求しない。更に、該アーキテクチャは今日のどの利用可能なウエブデジタル携帯電話ででも稼動するので、契約者に新しい“Ｂｒｅｗ”や“３Ｇ”の新しい携帯電話を買うことを要求しない。よりパワフルなビューデバイス出現しても、システムは、より大きいフォーマットデバイスで拡張経験を提供するプラットフォームと統合する。

商人、商品、カテゴリ、サービスに対するロケーション文脈感知サーチは、最小限のユーザのキー打ちにより、支持され得る。問い合わせ結果は、携帯電話、ＰＤＡ、若しくは“Ｐｏｃｋｅｔ ＰＣ”に直接に配信され、自動的に個々のデバイスに適合するようにフォーマットされる。これらの結果は、リストの頂点のユーザに最も近いことを示すユーザの問い合わせ、及び如何に離れているかに関する情報に適合する結果を識別するユーザのロケーションの近傍により、構築される。ユーザは、メニューへ掘り下げて、商人、製品若しくはサービスに関する更なる情報を取得し、更にターゲットを位置付ける助けとなる駆動命令及び地図を蓄えることができる。

商人は、ユーザに特売品やクーポンを提供できる。消費者と商人は、アフィニティグループ、頻繁な購入者プログラム及び連合との提携を利用する。受信契約者は、指定された製品、サービス若しくはカテゴリのための販売促進及びクーポンを受信するように選択できる。この選択メカニズムにより、簡素な限定された時間枠受信ウインドウ、及び年次再発イベントウインドウが可能になる。消費者は、所与の商人若しくはサービスプロバイダで入手可能な製品若しくはサービスを見て、オンラインで商品及びサービスを購入若しくは予約する機会がある。

本明細書に組み込まれ一部を構成する添付の図面は、本発明に係る方法、システム及び装置の例示の形態を示すものであり、本発明の実施形態の特性を説明するように機能する。

添付の図面を参照して、例示としてのみであるが、本発明に係る一つ又はそれ以上の実施形態を説明する。

以下の説明では、膨大な具体的詳細は、実施形態の全体的理解を進めるために為されている。しかしながら、当業者であれば、一つ又はそれ以上の具体的詳細が無くても、若しくは他の方法、要素、部材が有れば、本発明は実施され得ることを、認識し得る。本発明の形態を不明瞭にすることを避けるために、別の例では、周知の構造、部材若しくは操作を示さず説明していない。

この明細書を通して“一つの実施形態”若しくは“実施形態”という表示は、その実施形態に関連して説明する特定の特性、構造若しくは特徴は少なくとも一つの実施形態に含まれるということを意味する。従って、この明細書を通して種々の位置での“一つの実施形態における”若しくは“実施形態における”というフレーズの登場は、全て同じ実施形態を参照するものであるとは限らない。更に、特定の特性、構造若しくは特徴は、一つ又はそれ以上の実施形態に適切に組み合わされ得る。

図１及び図３を参照して、識別されたユーザ（図示せず）に対するｅディレクトリサービスの供給をなし得る本発明のシステムに関する、概略符号１００が付される一つの実施形態が示される。あらゆる代替の通信モード１０１を介して、若しくは第１のインスタントメッセージモード１０５を介して、誰もが、上記の供給のためのサービスから、あらゆる若しくは全てのデバイス１０６、１０７、１０８を所持する契約している識別ユーザに、情報を要求できる。適切な通信エージェント１０９は、どれもそのような要求の受理を受け入れて、到着のユーザ要求２０１の形態で装置によって（例えば、バディスクリプトを利用して）利用の準備することができる（図２も参照）。システム１００の一つの実施形態によると、装置１１０は（図３に詳述する）ソフトウエアモジュールであり、該ソフトウエアモジュールは、（例えば、単体の供給者の複数例などの）冗長な情報を多少ともパージし、（例えば、独自仕様のフォーマットを伴うウエブなどの）異なる種類のデータをマージし、更に、携帯電話１０６、パーソナルデジタルアシスタンス（ＰＤＡ）１０７、ポータルコンピュータ１０８、若しくは他のクライアントデバイスなどの限定された帯域のモバイルデバイスによって実効的に消費されるように、そのような統合データにつき書式を再設定する。

例えば、システム１００に係る一つの実施形態によると、少なくともユーザのロケーション、若しくは、ユーザが情報を要求するロケーション、及び、そのユーザにより要求される情報の性質を判定するために、装置１１０は要求２０１の部位を（例えば、データのストリングを構文解析することにより）分割若しくは分離する。要求されたロケーションのユーザロケーションは、（例えば、Ｍａｐｔｕｉｔ若しくは他のマッピングエンジンなどの）マップユーティリティ１２０に対して、（例えば、Ｙｅｌｌｏｗ Ｐａｇｅｓ（登録商標）、若しくは他のディレクトリなどの）第１のデータベース１２５で相互参照される適切な手段により示されるのであり、その第１のデータベース１２５は、通常、ユーザがシステム１００を介して（申込みなどにより）アクセスする資格があるような種類の詳細な情報を含むディレクトリである。個々のユーザ要求に応答するため最も関連する内容を集める過程でウエブデータを他のデータフォーマット（例えば、Ｙｅｌｌｏｗ Ｐａｇｅｓ（登録商標）独自のフォーマット）とマージする際、装置１１０が（ＰＷＳモジュール３２５により）独自アルゴリズム値判定を介して考慮に入れる関連情報を求めて（例えばＧｏｏｇｌｅやスパイダサーチを介して）グローバルに問い合わせることを許容するｗｗｗ１２６に、通常、装置１１０も接続する。

ある場合では、要求２０１がその人のために形成されるユーザは、要求を、マップユーティリティ１２０と第１のデータベース１２５とのクロスリファレンスに基づいて装置１１０により選択された供給者情報と、更により実効的に適合せしめるために、価値付加データベース１４０内に好ましい情報を格納できることになる。更に、署名しているユーザ若しくは署名している供給者が拡張されたサービス特性が与えられた場合には、装置１１０は、価値付加データベース１４０内で利用可能なデータを含む、様々な基準に基づいて第１のデータベース１２５から選択された供給者に、外部データベースアレイ１５０からの情報をマッチさせようとする。

ユーザの要求に関して潜在的に供給者をマッチする仮のリストが整理され（一時データアレイ（ＴＤＡ）３０１内に格納され）ると、装置１１０は、供給者の二重のエントリを除去し、処理されるユーザ要求２０１の例に適用され得る基準に最も良くマッチする供給者の優先リストを形成するために、残余の供給者を分類して比較する。個々の署名しているユーザがシステム１００から更なる要求を作成すると、価値付加データベース１４０内に格納される好ましい情報により装置１１０はマッチング及び優先順位付けがより洗練されることになる。装置１１０がユーザ要求２０１に関する全ての可能な処理を完了させると、装置は、一つ又はそれ以上の特定のデバイス（例えば、デバイス１０６、１０７、１０８）により受信され表示されるのに実効的なフォーマットで、それら特定のデバイスをビューするための識別ユーザに対する配信の応答を準備する。例えば、応答を携帯電話に送るとき、装置１１０は、供給者から利用可能であるがこの時点では所望されているわけではない非本質的なグラフィック情報を奪い取ってもよい。供給者から奪い取られ優先順位付けされたリストは、特定モード（例えば、インスタントメッセージ１０５）を介して転送するのに適切であるフォーマットにより限定サイズのデータブロックに再パッケージされ、携帯電話１０６や他の要求されるデバイスへの配信のために通信エージェント１０９に戻される。

一つの実施形態のシステム１００によれば、通信エージェント１０９の役割は、適切なライセンスの下では装置１１０内に組み込まれることが、理解される。

一つの実施形態のシステム１００によれば、署名しているユーザは一つの通信モードを用いて要求２０１を送り、完全に異なるモードを介して装置１１０の応答を受け取ることが、更に理解されるべきである。例えば、ホテルに向かう途中のビジネスパーソンが、インスタントメッセージと彼女のＰＤＡ内へとプログラムされたスクリプトとを用いて、彼女のホテルから所与の距離内で“ティータイム”に関する情報を無線で要求し、続いて、彼女が適宜の装いに着替えた後ホテルのバーでホットスポット内の彼女のラップコンピュータを用いてより詳細で魅力的なグラフィックの応答を受信してもよい。ホテルに居ながらにして、ユーザは、装置１１０により、自分のコンピュータ１０８に供給されるが、自分の携帯電話１０６には配信されないリンクを用いてウエブサイトを眺めた後、ティータイムをよりよく選択することができる。

図２を参照して、ステップ２０１で装置１１０が、一つ又はそれ以上の限定数の定義された型の情報を求めるユーザの要求を通常エージェント１０９から受信する、概略２００が付される本発明に係る方法の一つの実施形態が示される。ステップ２０１の入ってくる要求は、システム１００が協働するように設計された殆どどの通信手段を介して到着してもよいことが理解されるべきである。ステップ２０５では、入ってくる要求メッセージは、ユーザロケーション（ＵＬ）及び／又は要求タイプ（ＲＴ）などの、ユーザにより作成された要求の特異性に基づいて、（例えば、構文解析により）複数のコンポーネント部分に分割される。

一つの実施形態の方法２００によると、ステップ２０５で分離されたコンポーネントを用いて、ステップ２１０ではシステム１００は、郵便番号やジップコードに係る（例えば、Ｍａｐｔｕｉｔや他のマッピングエンジンの）サードパーティデータベースなどの資源からユーザロケーションに関する標準化された情報を経済的に取得する。本発明に係る方法の更なる実施形態によると、ステップ２１０は、電話番号の逆引き、都市名、更に都市内の通りの交差点に基づいて実施されてもよい。そして、システム１００の更なる実施形態によると、（適切な設備を有するユーザの同意により）ユーザロケーション情報は、ＧＰＳ決定座標から計算されてもよく、携帯電話塔を利用して局所的に三角測量されてもよい。更に、“９１１”緊急サービスロケーショングリッドが個々の自治体で拡張しており、行政体及び権限ある坦体は、ステップ２１０を実施する別手段としてシステム１００が利用しうる資源を、利用可能なものに為し得る。

適切な手段により、ユーザが要求するロケーションの近位で情報を決定して、装置１１０は、第１のデータベース（例えば、Ｙｅｌｌｏｗ Ｐａｇｅｓ（登録商標）ディレクトリ）、若しくは、要求を作成するユーザにより識別される種類の供給者がそこから配置する同様の資源に問い合わせを行うことによって、ステップ２１５を実行し得る。ステップ２１５では、識別された供給者に関する実質的であるが変動量の詳細情報を含む、複数の可能な供給者の生のリストが集められる。ステップ２２０では、個々の供給者が唯一である優先順位付けされた初期リストを形成する一方で、二重のエントリを除去するために（例えば、近似、コスト、手持ちの品揃えなどの）様々な定義基準に基づいて、リストが分類される。

ステップ２２０で生じる優先順位付けされた初期リストの拡張が、ｗｗｗ１２６の問い合わせが、上記リストに既にある供給者に関する追加の関連情報と、上記リストに基づかないが装置１１０により考慮され得る追加の供給者を収集するステップ２２５で、選択的に開始する。このリストに関する（例えば、新しい供給者、若しくはリストされた供給者に関する新しい情報をマージするなどの）追加の処理はステップ２２５で生じ、そこでは潜在的に新しい供給者の認識印象と変更されたランニングとの両方が生じる。ステップ２２５で生じたリストの更なる選択的な拡張はステップ２３０で生じ得、そこでは内部データベース１４０（例えば、署名された同意のみに基づいて収集され蓄積されたユーザプロファイル情報）及び／又は追加の外部データベース１５０が、供給者の品揃え、及びユーザにより為されるタイプの要求に関連する広範な事項に関する他の関連事項のために、装置１１０により問い合わされ（、識別された供給者に関する販売促進及び他の情報を相互参照す）る。ステップ２３０では、広範な増大する関連考慮事項に基づいて繰り返し精査され入れ替えられるリストとなり、システム１００が、署名しているユーザに非常に高品質の応答を配信できることが好ましい。

ステップ２０５の要求内容に関連する新しい情報が、一つ又はそれ以上のリストされた供給者に対して配置されるならば、これはステップ２４１において、所与の供給者がその供給者に関する印象を何ら有さないユーザに曝されるように、リストのランキングを変更し得る。その結果として、ステップ２４０にて、システム１００のオペレータは、ステップ２３０の追加の処理、変更されるランキング、若しくは関連する公開を（ユーザ若しくは供給者、又は両方に）負担させることにより追加の収益を得る機会が存在し得る。

ステップ２５０にて一つの実施形態の方法２００によると、全ての外部データはリストされた個々の供給者の記述から奪取され、リスト内容は特定ユーザに送信する準備がされる。個々の追加の問い合わせが供給者情報の種々の要素を収集するが、そのうちには特定ユーザのデバイスに転送するのに適切でないものもあるので、一つ又はそれ以上のユーザデバイスで効率よく眺めるべく整理されたデータセットを準備するために、その情報が適用される識別された供給者に関する本質的な基本情報とともに適切な価値付加情報が含まれるように、ステップ２５０は最終リストを再フォーマットする。

関連する全ての処理の結果に実質的に影響することなく、方法２００を実行する効率に影響し得る様々な順序で、ステップ２２０、２２５、２３０及び２５０は実施され得ることが理解されるべきである。一つの実施形態では、ステップ２２０、２２５、２３０、及び２５０の少なくともいくつか、及び／又は、他のステップ若しくは本明細書に示す他の機能のうちの少なくともいくつかは、機械読み取り可能媒体に格納されたソフトウエア若しくは他の機械読み取り可能命令でインプリメントされ、一つ又はそれ以上のプロセッサにより実行され得る。

ステップ２６０において一つの実施形態の方法２００によると、システム１００は、供給者のサブセットに関する情報を直接に若しくはエージェントを介してユーザに戻す。サーチエンジンでしばしば生じることであるが、限定された帯域のデバイスでユーザが“トップ５”を表示させることを要求し得るように、ユーザが必要とする以上により多くの可能な供給者を配置させる。このような場合、システム１００はトップ４０の供給者を捕獲し格納するように設定されており、そのうちの３５はユーザがトップ５以上をみたいと思うときに備えて背面に一時的に保持される。一連の問い合わせの結果を管理しシステム１００による方法２００の実装の間に実施されるオペレーションを分類するのには、多数のバリエーションが想定可能であることは、当業者であれば理解し得るところである。

図３を参照して、エージェント１０９に接続され、インスタントメッセージなどの一つ又はそれ以上のモードによって通信する装置１１０に関する一つの実施形態が示される。データ要求サービス（ＤＲＳ）３００は、予め構文解析して若しくは連続的に、エージェント１０９からデータストリング（図示せず。）を受け入れる。メモリレジスタ、即ち一時データアレイ（ＴＤＡ）３０１−３０４は、データストリングが適切な処理デバイス及び通信バスにより効率的に操作される操作の例として示される。要求されたロケーション及び要求タイプの情報が分離されると、“サービシーズ”即ち要求問い合わせサービス（ＲＱＳ）などのモジュールは、広範な資源（例えば、データベース１２０−１５０）から情報を集め分析するのに利用される。図２に関して説明するように、選択される供給者“ｈｉｔｓ（ヒット）”で重複が除去され、マージが生じ、ユーザ特注サービス（ＵＣＳ）モジュール３１５によるユーザプロファイリングにより作成され得る応答のカスタマイゼーションが有効になり、その結果は優先順位重み付けサービス（ＰＷＳ）モジュール３２５により重み付けされ、署名しているユーザに対して高品質の情報内容を生成するという文脈で、リストはリスト分類サービス（ＬＳＳ）３２０により再分類される。データベースバス上のソースの関する問い合わせが進行する前に、ＰＷＳモジュール３２５は、広範な基準（例えば、信頼性、コスト、応答速度、戻される内容の豊かさ、署名している及びリストされる供給者（ＳＬＳ）の支払料金、など）に基づいて、データソースを比較するのに利用されることが理解されるべきである。以下、方法４００で示されるように、これは、ユーザに対してより良い情報をより速く促進することが好ましい。データマージングサービス（ＤＭＳ）モジュール３１８は、更に本明細書で定義するようにステップ２２５及び４２５を実施するのに利用される。同様に、ＬＳＳモジュール３２０及び二重除去サービス（ＤＥＳ）モジュール３１０は、夫々、更に本明細書で定義するようにステップ２２０を実施するのに利用される。モバイルユーザのための改良された関連性に加えて、ＸＭＬドキュメント作成サービス（ＸＤＳ）モジュール３４０及びユーザデバイスフォーマットサービス（ＵＤＦＳ）モジュール３４５は、デバイス、即ちユーザにより特定されるデバイスでのビューを最適化するように、協同して応答をフォーマットする。この効果的な組合せにより、要求を入力するのに費やす時間が少なくなり結果を利用する時間が増えるユーザはストレスが少なくなり満足度が増える。ＸＤＳモジュール３４０はＸＭＬのドキュメント作成に限定されず、別の実施形態ではＨＴＭＬ、スクリプト、テキスト、若しくは他のフォーマットなどのどの適切なフォーマットを利用してもよいことが、理解されるべきである。

図４を参照して、ステップ２０１で装置１１０が、一つ又はそれ以上の限定数の定義された型の情報を求めるユーザの要求を通常エージェント１０９から受信する、概略４００が付される本発明に係る方法の別の実施形態が示される。ステップ２０５では、入ってくる要求メッセージは、ユーザにより作成された要求の特異性に基づいて、（例えば、構文解析により）複数のコンポーネント部分に分割される。一つの実施形態の方法４００によると、ステップ２０５で分離されたコンポーネントを用いて、ステップ２１０ではシステム１００は、方法２００に関して全て上述したように、種々のソースからユーザロケーションに関する標準化された情報を取得する。

方法４００によると、適切な手段により、ユーザが要求するロケーションの近位で情報を決定して、装置１１０は、処理中のユーザ要求についてＵＬ及びＲＴ（の夫々若しくは両方）に対する適用性に関する履歴情報に基づいて、利用可能なデータベースソース（１２５、１２６、１４０、１５０、４５０）を先ず比較することによって、次にステップ４１５を実行（して問い合わせ処理を促進）することができる。長期にわたり装置１１０は、個々の利用可能なデータベースソース特にＵＬゾーン、及び／又は個々のＲＴカテゴリに関する信頼性データを“収得する”即ち蓄積することができることが、理解されるべきである。例えば、（Ｙｅｌｌｏｗ Ｐａｇｅｓなどの）第１のデータベース１２５が、ピザパーラーなどの高回転率の商店に関して信頼性の貧弱な履歴を蓄積しているのであれば、テーブル、若しくは、ソース比較ステップ４１５の履歴のどの他の適切なフォームも、装置１１０内のＰＷＳモジュール３２５によるソース比較のために利用可能であり、ＲＴがレストランのピザパーラーカテゴリを含む夫々のときに、システム１００が第１のデータベース１２５に問い合わせることを回避せしめる。同様に、履歴上信頼できないのが所与のグループの都市の低家賃地区内のピザパーラーのみであるならば、ＲＴとＵＬの組合せは、問い合わせに検索条件（フィルタ）を加え、ピザパーラーが失敗しがちであることが周知であるＵＬ以外で、そのタイプのＲＴを問い合わせしめるのに利用され得る。

“問い合わせフィルタ”が処理中のユーザ要求に適用され、ＰＷＳモジュール３２５によるソース比較ステップが完結すると、システム１００が問い合わせ時に通信できる残存の高品質で利用可能なデータベースソース（１２５、１２６、１４０、１５０、４５０）に関する複数の問い合わせで、収集ステップ４２０が進行し得る。この問い合わせの数は、（ユーザ、若しくはユーザの利用するデバイスにより強いられる）実際のビューの限界のために制限されてもよく、若しくは、特定のＳＬＳは、問い合わせが問い合わせフィルタ基準を生き残る限りあらゆる関連のユーザ要求に関してそれらのソースが問い合わされることを保証する料金を支払ってもよい。

ＰＷＳモジュール３２５によるソース比較が、ユーザの好み、サービスレベル、及びＲＴに依存する広範な基準によって駆動されてもよい。例えば、適用される基準は、ソースの履歴上の信頼性、ソースが更新された最新日、ＳＬＳからのリアルタイムのフィードバック、検索されるものの物理的性質（例えば、プレイグラウンドは動かないが、選択は変動してよい）、内部的生成検証データ（例えば、高信頼度）、内部的検証なき自発的パブリックソース、又は他の基準を、含む。

内部データベース１４０（例えば、署名者の同意にのみ基づき収集され蓄積されたユーザプロファイル情報）及び／又は追加の外部データベース１５０が、供給者一覧表、及び、ユーザの為すタイプの要求に係る広範な事項に関する他の関連情報を問い合わされ（、識別された供給者に関する販売促進の及び他の情報を相互参照す）ると、ステップ４２５で生じるリストの更なる選択的な拡張が発生する。

全ての問い合わせ応答がステップ４２０にてＴＤＡ３０１内に集められると、装置１１０は上記の方法２００で示したのと実質的に同じように分類とパージのステップ２２０を実行する。結果として、その時点での処理中のユーザ要求に関連するＵＬの近傍での利用可能性の観点で高い信頼性があると思われている無類の供給者ＩＤのリストとなる。ＩＤをマージするステップ４２５は、健全な根拠を配信し、この根拠に基づきステップ２４０で料金をチャージし、ＩＤが残余する個々のＳＬＳがフィルタされ分類されマージされる。好適に、システム１００の利用が増えるにつれて、所与の時期に提供物に関してより豊かな様々なデータを供給したいと望む特定のＳＬＳにより、追加の分類基準が利用可能とされるならば、ステップ２４１において、ステップ２６０でユーザデバイスに行く最終アウトプットでそれらのランクを上げるために、そのより豊かな情報について、適任なＳＬＳの小集団に再分類させる。例えば、ユーザが開店している最も近いティムホートン（Ｔｉｍ Ｈｏｒｔｏｎ）のみを探しているのではなく、その日その時のランチメニューにビーフと大麦のスープがある店も探しているのならば、所与のフランチャイズロケーションの積極的な店長ならば、より詳細なＲＴに基づき問い合わせに応じたその日のメニューを含むより詳細で豊かなデータのセットをアップロードすることを選択してもよい。ユーザがより詳細なユーザ問い合わせ１０５を転送すれば、ユーザのその時のＵＬ周辺のサーチ半径の大きさに影響し得ることが理解される。最適である最も近いティムホートン（Ｔｉｍ Ｈｏｒｔｏｎ）がＵＬからかなり離れた距離にあるならば、ユーザはステップ２６０の応答に含まれるそれを尚見てもよいが、ビーフと大麦のスープの更なるソース、若しくは、ＲＴあたりの同じカテゴリ（例えば、スープを含む種々のランチフード）を坦持する
が特定フレーバのスープの利用可能性を確約若しくは否定するのに十分詳細なメニューをあからさまに示さない近傍のレストランのリストに格下げすることを選択してもよい。

ステップ２４１にて、ＲＴ内の豊富な情報に従って、再分類が為されて完結すると、システム１００は、全ての外部からのデータが個々のリストされた供給者の記述から剥がし、特定のユーザに送信する予定のリスト内容を作成する。方法２００と同様に、個々の追加の問い合わせが供給者情報の種々の要素を収集するが、そのうちには特定ユーザのデバイスに転送するのに適切でないものもあるので、一つ又はそれ以上のユーザデバイスで効率よく眺めるべく整理されたデータセットを準備するために、その情報が適用される識別された供給者に関する本質的な基本情報とともに適切な価値付加情報が含まれるように、ステップ２５０は最終リストを再フォーマットする。

関連する全ての処理の結果に実質的に影響することなく、方法４００を実行する効率に影響し得る様々な順序で、ステップ４１５、４２０、２２０、４２５、２４１、及び２５０は実施され得ることが理解されるべきである。

ステップ２６０において一つの実施形態の方法４００によると、システム１００は、システム１００による方法４００の実装が上記の方法２００と並行するものとなるように、供給者のサブセットに関する情報を直接に若しくはエージェントを介してユーザに戻す。

上記米国特許、米国特許出願公報、米国特許出願、外国特許、外国特許出願、及び本明細書で言及した非特許文献は、本明細書に参照の上全体として組み込まれる。

開示内容は本発明の好適な実施形態を記述し提示したが、本発明はこれら特定の実施形態に限定されないことが理解されるべきである。資源配分の当業者には多数の変更や修正が生じ得る。発明の範囲の完全な定義のためには、添付の請求項を参照すべきである。

本発明に係るシステムの一つの実施形態を説明するブロック図である。 装置により実装される、本発明に係る方法の一つの実施形態を説明するフローチャートである。 本発明に係る装置の一つの実施形態を説明するブロック図である。 装置により実装される、本発明に係る方法の別の実施形態を説明するフローチャートである。

符号の説明

１０５・・・ユーザ問い合わせインスタントメッセージモード、
１０６・・・携帯電話、
１０８・・・コンピュータ、
１２０・・・マップユーティリティ、
１２５・・・第１のデータベース、
１２６・・・ｗｗｗ、
１４０・・・価値付加データベース、
１５０・・・外部データベース、
３００・・・データ要求サービス（“ＤＲＳ”）モジュール、
３０１・・・一時データアレイ（“ＴＤＡ”）、
３０５・・・リソース問い合わせサービス（“ＲＱＳ”）モジュール、
３１０・・・二重除去サービス（“ＤＥＳ”）モジュール、
３１５・・・ユーザ特注サービス（“ＵＣＳ”）モジュール、
３１８・・・データマージングサービス（“ＤＭＳ”）モジュール、
３２０・・・リスト分類サービス（“ＬＳＳ”）モジュール、
３２５・・・優先順位重み付けサービス（“ＰＷＳ”）モジュール、
３５０・・・データ転送サービス（“ＤＴＳ”）モジュール、
３４０・・・ＸＭＬドキュメントサービス（“ＸＤＳ”）モジュール、
３４５・・・ユーザデバイスフォーマットサービスモジュール。

Claims (27)

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. 上記ユーザカスタマイズサービスモジュールが、供給者リストとそれらに関連する事実を受信するための、ユーザ要求を送信した送信デバイスと異なる受信デバイスを、ユーザ要求から決定することもできることを特徴とする請求項２４に記載の装置。

Images