JP2011248900A - 汎用検索インターフェースシステム及び方法 - Google Patents

Abstract

【課題】情報読み出し及び通信機能性を強化するためのシステム及び方法を提供する。
【解決手段】ユーザーコンピュータ上に常駐する複数のアプリケーションとインターフェースするように構成可能であり、且つ遠隔システム上の検索知能と通信するための持続的二方向通信チャネルを提供する、汎用インターフェースを使用する。共有可能であり動作可能であるラベルとラベルのコードブックは、ユーザーによって定義される。各ラベルは、自然言語フォーマットで定義してもよく、また、ユーザーシステム上で実行可能な特定のアプリケーション又はアプリケーションのセットに対するマッピングを含んでいてもよい。ユーザーシステム間でのラベル及びコードブックの転送によって、ユーザー間での情報交換及び取り出し、並びにユーザーシステムによる情報交換の追跡及び分析が可能となる。
【選択図】図５

Description

本発明は、概括的にはネットワーク及びインターネット検索及びインターフェースシステムに関し、より具体的には検索機能性を強化した検索システムに関する。本発明は、更に、各種検索機能性を提供するとともに、ユーザーのコンピュータ上の各種アプリケーションと相互作用して汎用情報交換ツールを提供するインターフェースシステム及び方法にも関する。

本出願は、２００３年４月４日出願の米国仮特許出願第６０／４６０，２２２号の非仮出願であり、同仮特許出願に対する優先権を主張するとともに、同仮特許出願の開示内容全体を参考文献としてここに援用する。

インターネットのようなネットワークの出現と、ワールドワイドウェブ（ウェブ）上でユーザーが利用可能なウェブページ及びメディアコンテンツの増加に伴い、ネットワーク又はウェブから所望の情報をフィルタリング及び入手するため、無駄を省いて合理化した方法をユーザーに提供することが必要となっている。このユーザーが所望の情報を入手したいという要求に応える検索システム及び処理が開発されてきた。このような技術の例として、Yahoo!、Googleなどのサイトを通してアクセスすることがある。通常、ユーザーが照会を入力すると、検索処理が当該照会に関する１つ又は複数のリンクを戻す。戻されたリンクは、ユーザーが実際に探しているものと関連性が非常に高いこともあれば、全く見当違いな場合もある。照会に対する結果の「関連性の高さ」は、一部には、入力された実際の照会の機能並びに使用されている検索システム（下位の収集システム）の頑強性による。

ユーザーが入力する照会は、通常、１つ又は複数の単語で構成されている。例えば「ハワイ」は照会であり、「ニューヨーク市」も然り、「ニューヨーク市法執行機関」もそうである。つまり、照会は全体として人間の脳にとっては必要不可欠というわけではない。別の言い方をすれば、人間は、自然に、照会という観点から物事を考えるわけではない。照会は、一部には、検索エンジンに照会する必要性又はライブラリカタログを見る必要性により我々に課された人工構造物である。人間は、普通は、たった一語だけで物を考えることはない。人間が何に関して思考するのかといえば、それは自然のコンセプトである。例えば、「ハワイ」と「ニューヨーク市」は単語数から測った長さの点では大きく異なる照会であるが、両者はそれぞれ共に１つのコンセプトを成しているという１つの重要な特性を共に有している。しかしながら、照会「ニューヨーク市法執行機関」は、「ニューヨーク市」と「法執行機関」という２つのはっきりと区別できるコンセプトから成り立っているので、別物である。人間は、単純に様々な長の単語の連続体ではなく、１つ又は複数の自然なコンセプトを入力することにより、自然に照会を組み立てているのである。

例えば、MSN、Googleなど主要な検索プロバイダ、又は他の主な検索エンジンの何れにおいても、現在の技術は、人間が照会を作成するのと同じやり方で照会を理解してはいない。これが、恐らくは、検索プロバイダがユーザーの意向を理解して最適な検索結果とコンテンツを提供できないようにしている最も重大な理由である。

米国仮特許出願第６０／４６０，２２２号 米国特許出願第１０／７１３，５７６号

理解頂けるように、ユーザーが興味を持っている実際のコンセプトにもっと一致している結果を提供する、改良された検索及びインターフェース技術が必要とされている。

本発明は、ユーザーに提供される検索機能性を強化するためのシステム及び方法を提供している。本発明は、或る態様では、ユーザーコンピュータに常駐している複数のアプリケーションとインターフェースをとることができるように構成可能であると共に遠隔システム上の検索知能と通信するための持続的な二方向通信チャネルを提供する汎用インターフェースを使用することにより、情報検索及び通信機能を強化するためのシステム及び方法を提供している。或る態様では、本発明は、照会を、ユーザーが興味を持っているコンセプトに関係する構成単位に自動的に分解する。

本発明は、ユーザー定義の又は事前に定義された、特定の対象にマップするためのラベル、コード、及びパラメータを、作成、記憶、てこ入れするためのシステム及び方法も提供している。例えば、ユーザーは、ラベル又はコードが入力された場合には何時でも、１つ又は複数のアプリケーションにアクセスするといったような、取るべき動作を指定するラベルやコードを作成することができる。このようなラベル又はコードは、基礎をなすラベル又はコードマッピングに従って処理されることを意図する引数を含んでいる。例えば、汎用インターフェースで、ユーザーによる入力があると、システムは、当該ラベル又はコードを、取るべき動作は何か又は引数があればそれをどのように処理するかを識別するための、マッピング表に対するキーとして使用する。或る態様では、このようなラベル、コード、パラメータなどは、ユーザーがラベル、コードなどを理解し易い自然な言語構成体としてユーザーにより作成される。このようなラベル、コードなどは、他のユーザー及びシステムに転送され及び使用されてもよい。このようなラベル又はコードを受信した側は、指示対象又はラベルの名称、又はラベル、コードなどの他の属性を変更してもよい。

本発明の或る態様によれば、ユーザー入力を処理してクライアントシステム内のユーザー入力のコンテンツに基づいて取るべき動作を決めるための、コンピュータにより実行される方法が提供されている。本方法は、通常、クライアントシステムに関係付けられたグラフィカルユーザーインターフェース表示上にダイアログボックスを表示する段階と、当該ダイアログボックスへのユーザー入力を受け取る段階と、ユーザー入力のコンテンツを処理してユーザー入力のコンテンツに基づいて取るべき動作を決める段階を含んでいる。ある態様では、当該動作には、ユーザー入力を検索照会として使用しながら検索を実行すること、及びクライアントシステム上に在る１つ又は複数のアプリケーションにアクセスして、前記コンテンツに基づいて更なる処理を実行すること、の内の１つが含まれる。

本発明の別の態様によれば、複数のクライアントシステムの間で動作可能なラベルを共有するための方法が提供されている。本方法は、通常、第１クライアントシステム上で実行可能な少なくとも１つの特定のアプリケーションにマップすることを含む第１ラベルを第１クライアントシステム上に作成する段階と、ネットワークを通して当該ラベルを第２クライアントシステムに転送する段階と、当該第１ラベルを第２クライアントシステムのメモリ装置に記憶する段階と、を含んでいる。本方法は、更に、通常は、第２クライアントシステム上でユーザー入力を処理する段階と、ユーザー入力により第１ラベルが識別できた場合は、第２システム上に少なくとも１つの特定のアプリケーションを呼び出す段階と、少なくとも１つの特定のアプリケーションを使ってユーザー入力を処理する段階を含んでいる。

本発明の或る実施形態による情報検索通信システムの概略図である。 本発明の或る実施形態による、メディアコンテンツを伝送するための情報検索通信ネットワークを示している。 本発明の或る実施形態による、照会ログファイルを処理してユニットディクショナリを導入するように構成されている照会処理エンジンを含むシステムを示している。 本発明のある実施形態による、或る態様の照会処理エンジンを含む、ユニットディクショナリ並びに付帯する処理知能を含んでいるシステムを示している。 或る実施形態による、コード、レベル、及びパラメータの転送、記憶、及び検索の一例を示している。 或る実施形態による、ユニバーサルダイアログボックス（ＵＤＢ）を含んでいるＧＵＩ表示ページの一例を示している。 本発明のＵＤＢインターフェースシステム及び方法論によって提供される機能性を使ってクライアントシステムに提供されるウェブページの例を示している。 本発明のＵＤＢインターフェースシステム及び方法論によって提供される機能性を使ってクライアントシステムに提供されるウェブページの例を示している。

図面及び特許請求の範囲を含む本明細書の残りの部分を参照すれば、本発明のこの他の特徴及び利点が明らかとなるであろう。本発明の詳しい特徴及び利点、並びに本発明の各種実施形態の構造及び作用について、これより添付図面を参照しながら詳細に説明する。図中、同一又は機能的に同様な要素には同じ符号を付して示している。

図１は、本発明の或る実施形態による、クライアントシステム２０を含む情報検索通信ネットワーク１０の概略図を示している。コンピュータネットワーク１０では、クライアントシステム２０は、インターネット４０又は他の通信ネットワークを通して、例えばＬＡＮ又はＷＡＮ接続を通して、サーバシステム５０₁から５０_Nに連結されている。これから説明するが、クライアントシステム２０は、サーバシステム５０₁から５０_Nの何れとも通信し、例えば、メディアコンテンツ又はウェブページのような他の情報にアクセスして、その情報を受信し、読み出し、表示することができるように本発明に従って構成されている。

図１に示すシステムの要素には、ここで詳しく説明する必要のない従来からの既知の要素も幾らか含まれている。例えば、クライアントシステム２０には、デスクトップ型パーソナルコンピュータ、ワークステーション、ラップトップ、ＰＤＡ、携帯電話、又は何らかのＷＡＰ使用可能機器、又はインターネットと直接又は間接的にインターフェース可能な他のコンピュータ機器が含まれる。クライアントシステム２０は、通常、マイクロソフト社のInternet Explorer^TMブラウザ、Netscape Navigator^TMブラウザ、Mozilla^TMブラウザ、Operaブラウザ、又は携帯電話、ＰＤＡ、又は他の無線装置などの場合にはＷＡＰ使用可能ブラウザなどの、ブラウザプログラムを実行し、クライアントシステム２０のユーザーが、インターネット４０を通してサーバシステム５０₁から５０_Nから、ユーザーに利用可能な情報及びページにアクセスし、これらを処理して閲覧できるようにしている。クライアントシステム２０は、更に、通常、サーバシステム５０₁から５０_N又は他のサーバによって提供されるページ、型式、又は他の情報と結び付けて、表示装置（例えば、モニター画面、ＬＣＤ表示装置など）上でブラウザによって提供されるグラフィカルユーザーインターフェース（ＧＵＩ）と対話するための、キーボード、マウス、タッチスクリーン、ペンなどのような、１つ又は複数のユーザーインターフェース機器２２も含んでいる。本発明は、特定の世界規模の相互接続ネットワークを指すインターネットと共に使用するのに適している。しかしながら、インターネットに代えて又はこれに追加して、イントラネット、エクストラネット、仮想私的ネットワーク（ＶＰＮ）、非ＴＣＰ／ＩＰベースのネットワーク、各種ＬＡＮ又はＷＡＮなど、を使用してもよいと理解されたい。

或る実施形態によれば、クライアントシステム２０とその全ての構成要素は、Internet Pentium^TMプロセッサ、AMD Athlon^TMプロセッサのような中央処理装置、又は複数のプロセッサを使用して実行されるコンピュータコードを含むアプリケーションを使ってオペレータが構成することができる。クライアントシステム２０を操作し構成して、ここに説明しているように、データ及びメディアコンテンツを伝送し、処理し、表示するためのコンピュータコードは、ダウンロードしてハードディスクに記憶するのが望ましいが、プログラムコードの全体又はその一部を、周知のように、ＲＯＭ又はＲＡＭのような各種揮発性又は不揮発性メモリ媒体又は装置に記憶してもよいし、或いはコンパクトディスク（ＣＤ）媒体、デジタル多目的ディスク（ＤＶＤ）媒体、フロッピー（登録商標）ディスクなどのような、プログラムコードを記憶することができる各種媒体で提供してもよい。更に、プログラムコードの全体又はその一部は、周知のように、例えばインターネットを通してサーバシステム５０₁−５０_Nの１つからクライアントシステム２０に送信するなど、ソフトウェアソースから送信し及びダウンロードしてもよいし、或いは周知のように各種通信媒体及びプロトコル（例：ＴＣＰ／ＩＰ、ＨＴＴＰ、ＨＴＴＰＳ、イーサネット（登録商標）など）を使って、周知のその他の従来型ネットワーク接続（例：エクストラネット、ＶＰＮ、ＬＡＮなど）を通して送信してもよい。また、本発明の態様を実施するためのコンピュータコードは、Ｃ、Ｃ⁺、ＨＴＭＬ、ＸＭＬ、Ｊａｖａ（登録商標）、JavaScript（登録商標）、VBScriptのようなスクリプト言語、又はクライアントシステム上で実行できるプログラム言語ならどのような言語でも実施できるものと理解されたい。実施形態の中には、クライアントシステム２０にはコードを全くダウンロードせず、必要なコードがサーバにより実行されるか、又はクライアントシステム２０に既に存在しているコードが実行されるものもある。

図２は、本発明の或る実施形態により、メディアコンテンツを伝送するための別の情報検索通信ネットワーク１１０を示している。図示のように、ネットワーク１１０は、クライアントシステム１２０、サーバシステム１５０、及びサーバシステム１６０を含んでいる。ネットワーク１１０では、クライアントシステム１２０は、インターネット１４０又は他の通信ネットワークを通して、サーバシステム１５０及び１６０に通信可能に接続されている。先に述べたように、クライアントシステム１２０とその構成要素は、サーバシステム１５０及び１６０並びに他のサーバシステムと、インターネット１４０又は他の通信ネットワークを通して通信するように構成されている。

或る実施形態によれば、クライアントシステム１２０上で実行されているクライアントアプリケーション（モジュール１２５と表示）は、クライアントシステム１２０及びその構成要素を制御して、サーバシステム１５０及び１６０と通信し、ここで説明しているように、そこから受信したデータコンテンツを処理し表示するためのインストラクションを含んでいる。クライアントアプリケーション１２５は、遠隔のサーバシステム（例えば、サーバシステム１５０、サーバシステム１６０、又は他のサーバシステム）のようなソフトウェアソースからクライアントシステム１２０に送信されダウンロードされるのが望ましいが、クライアントアプリケーションモジュール１２５は、先に述べたようにフロッピー（登録商標）ディスク、ＣＤ、ＤＶＤなどのようなどのようなソフトウェア記憶媒体で提供してもよい。例えば、或る態様では、クライアントアプリケーションモジュール１２５は、後で説明するように、データを操作し、各種オブジェクト、フレーム、及びウインドウにデータをレンダリングするための、例えば内蔵型JavaScript（登録商標）又はActive Xコントロールのような様々な制御を含んでいるＨＴＭＬラッパで、インターネット１４０を通してクライアントシステム１２０に提供される。

また、クライアントアプリケーションモジュール１２５は、データ及びメディアコンテンツを処理するための各種ソフトウェアモジュールを含んでいる。例えば、アプリケーションモジュール１２５は、検索要求及び検索結果データを処理するため検索モジュール１２６と、データ及びメディアコンテンツをテキスト、データフレーム、及びアクティブウインドウ、例えばブラウザウインドウ及びダイアログボックスにレンダリングするためのユーザーインターフェースモジュール１２７と、クライアント１２０上で実行されている各種アプリケーションとインターフェースを取り通信するためのアプリケーションインターフェースモジュール１２８、の内の１つ又はそれ以上を含んでいてもよい。本発明の態様に従って、インターフェースモジュール１２８がインターフェースを取るように好適に構成されている、クライアントシステム１２０上で実行されている各種アプリケーションの例としては、各種ｅメールアプリケーション、インスタントメッセージング（ＩＭ）アプリケーション、ブラウザアプリケーション、ドキュメント管理アプリケーション、データベースアプリケーションなどが挙げられる。更に、ユーザーインターフェースモジュール１２７は、クライアントシステム１２０上に構成されたデフォルトブラウザのようなブラウザ又は別のブラウザを含んでいる。一例として、或る実施形態によるクライアントアプリケーションモジュール１２５は、ＵＲＬ：http//help.yahoo.com/help/us/sbc/browser/を使って、Yahoo!Inc.からダウンロードすることができる。

図２に示すように、或る実施形態によれば、サーバシステム１６０は、検索結果データ及びメディアコンテンツをクライアントシステム１２０に提供するように構成されており、サーバシステム１５０は、例えばサーバシステム１６０により提供された検索結果ページ内で選択されたリンクに応じて、ウェブページのようなデータ及びメディアコンテンツをクライアントシステム１２０に提供するように構成されている。後に詳しく説明するが、或る実施形態のサーバシステム１６０は、例えば、ページ、ページに対するリンクなどの、１つ又は複数のインデクスを導入するため、各種収集技術を参照する。このような収集技術としては、自動ウェブクローラ、スパーダーなどと共に、階層構造内でウェブページを分類及び順位付けするための手動又は半自動の分類アルゴリズム及びインターフェースが挙げられる。或る態様では、サーバ１６０は、例えばGoogleによるPageRankアルゴリズムのような、ウェブページの処理及び順位付けのための検索関連アルゴリズムを備えた構成となっている。サーバ１６０は、また、ユーザー照会活動を照会ログファイルの形式で記録するように構成されているのが望ましい。

サーバシステム１６０は、クライアントシステム、特に検索モジュール１２６から受信した各種検索要求に応えるデータを提供するように構成されている。サーバシステム１５０及び１６０は、単一の編成体の一部、例えばYahoo!Inc.によりユーザーに提供されるもののような分散型サーバであってもよい。サーバシステム１５０、１６０は、それぞれ、少なくとも１つのサーバ及び関係付けられたデータベースシステムを含んでいてもよいし、複数のサーバとこれらに関係付けられたデータベースシステムを含んでいてもよいし、図では１つのブロックとなっているが、地理的に分散していてもよい。例えば、サーバシステム１６０の全てのサーバは、互いに近接して（例えば単一のビル又はキャンパス内に配置されたサーバファーム内に）配置してもよいし、或いは互いに離れた場所に分散配置してもよい（例えば、Ａ市に１つ又は複数個のサーバ、Ｂ市に１つ又は複数個のサーバを置く）。本願では、「サーバシステム」という用語は、通常、局所的に、又は１つ又は複数の地理的地点に亘って分散配置された１つ又は複数の論理的及び／又は物理的に接続されたサーバを含むものとする。また、「サーバ」という用語は、通常、当技術では周知のように、コンピュータシステム及び付帯する記憶システム並びにデータベースアプリケーションを含むものとする。

或る実施形態によれば、サーバ１６０は、クライアントシステム１２０から受信した検索照会に応じて検索結果をユーザーに提供するための１つ又は複数のページインデクス及びアルゴリズムを備えて構成されている。或る態様では、サーバシステム１６０は、更に、クライアントシステム１２０からの検索要求に応じて、新規で且つ強化された検索照会分析及び分類機能を提供するように構成されている。

或る実施形態では、例えば、サーバ１６０で実行されている処理は、検索照会及び／又は検索結果のコンテキスト分析を行って、コンテキストでグループ分類された検索結果の提示で応える。多くの検索用語には、意図されたコンテキストによってそれぞれ異なる意味がある。例えば、ユーザーが用語"Java（登録商標）"を使って検索を行った場合、意図されたコンテキストは明確ではない。ユーザーは、Java（登録商標）コンピュータ言語に興味があるのかもしれないし、インドネシアのジャワ島、若しくは口語的にしばしばジャワと呼ばれるコーヒーに興味があるのかもしれない。つまり、それぞれの単語は異なる語意及びコンテキストを有する。本発明は、検索照会及び／又は結果を分析して、その結果をコンテキストによりグループ分類してユーザーのコンピュータ１２０に表示する点で好都合である。例えば、上記検索用語"Java（登録商標）"の例では、サーバ１６０は３つ（又は、他のコンテキストが認識された場合には更に多く）のコンテキスト又は語意、即ち、コンピュータ言語のJava（登録商標）、島のJava（登録商標）、及びコーヒーのjava（登録商標）、にグループ分けした検索結果を戻す。システムは、各コンテキストに関係付けて提供されたリンクを伴うセットで結果を表示するか、或いは、システムはリンク無しでコンテキストだけを（当該ユーザーに対してコンテキストを見分けるだけの十分な情報と共に）表示して、ユーザーが所望のコンテキストを選択して関係するリンクを表示できるようにする。Yahoo!ネットワークシステムでは、例えば、一組のコンテキストが、検索インデクス、スポンサー一致に関係付けられたリンク、ディレクトリ一致に関係付けられたリンク、及びInsideYahoo!(IY)一致に関係付けられたリンク、からのページへの一組のリンクを有する各コンテキストと共に表示される。

Java（登録商標）のような曖昧な意味を有する単語又は句に加えて、本発明のシステムは、或る実施形態では、結果を必ずしも曖昧でない検索用語のコンテキストにグループ分類するように構成されている。一例として、「ハワイ」という検索用語に対して戻される結果がある。この用語「ハワイ」それ自体、独自には、曖昧ではないが、このような用語に対して戻される結果は性格上幅が広く、文字通り「ハワイ」を論じる又は言及している全ての事物に関係する。ユーザーに対してより有用な結果を提供するために、本発明のシステムは、検索結果が実際に関係付けられる対象の知識をてこ入れすることによって、検索結果をコンテキストに好適に編成する。例えば、ハワイの場合、システムは、結果を、「ハワイ：旅行」、「ハワイ：気候」、「ハワイ：地理」、「ハワイ：文化」など、様々なコンテキストにグループ分けして戻す。例えば、或る態様では、コンテキスト識別子はインデクスのページリンクに関係付けて記憶されるので、検索が行われると、リンクは識別子に従ってグループ分けされる。ページリンクは複数のコンテキスト識別子に関係付けられていてもよい。このような識別子は、ユーザーが関係する検索を行うときに、システムによって自動的にリンクに関係付けられるのが望ましいが、識別子は、１つ又は複数のアドミニストレータのチームによって手動で変更され、リンクに関係付けられてもよい。この様に、多数の検索から拾い集めて分かったことをシステムにフィードバックして、コンテキストを定義し、再定義して、表示される検索結果を要求側のユーザーにとって更に価値ある有用なものにする。

或る実施形態では、サーバ１６０で実行されている処理は、ユーザーに対してより意味のある結果を提供するために、検索用語のコンセプト発見及びコンセプト分析を行う。例えば、検索句「ニューヨーク市」の場合、ユーザーがニューヨーク（州）の或る都市ではなくニューヨーク市（市又は地域）に関連するサイトに興味があることはかなり明白である。同じく、「ニューヨーク市法執行機関(New York City law enforcement)」の場合であれば、ユーザーがニューヨーク市の法執行機関（例えば、職業の区分）に関連するサイトに興味があることが明白である。しかしながら、殆どの検索エンジンは、検索句として使われている用語の順序とは無関係に、個々の用語「ニュー(New)」、「ヨーク(York)」、「市(City)」、「法(law)」、「執行機関(enforcement)」を用いて検索するのみである。本発明は、検索照会を形成する１つ又は複数のコンセプトを識別するために、用語を検索句として分析するので好都合である。好適な態様では、本システムは、コンセプトを識別して検索結果を分類するために、検索用語が提示された順序を使用する。例えば、「ニューヨーク市法執行機関(New York City law enforcement)」を検索句として使うと、システムは、例えばハッシングにより、検索句内に「ニューヨーク市(New York City)」と「法執行機関(law enforcement)」の２つのコンセプトを識別して、これら２つのコンセプトに応じた結果を戻す。「ニューヨーク市の法執行機関(law enforcement in New York City)」でも同じ結果が戻されるはずである。しかしながら、「ニューヨークの市法執行機関(city law enforcement in New York)」は、コンセプトが、「法執行機関(law enforcement)」と「ニューヨーク(New York)」と「市(city)」、或いは「市法執行機関(city law enforcement)」と「ニューヨーク(New York)」、のどちらに基づくかで異なる結果が戻されることになる。同様に、「ニューヨーク市の法の執行機関(enforcement of law in New York City)」であれば、「ニューヨーク市(New York City)」と「法(law)」と「執行機関(enforcement)」というコンセプトを含むものとして認識されることになる。このように、コンセプトの順序は、コンセプトを作っている用語の順序ほどに重要ではない。好適な態様では、コンセプトはページインデクスに含まれるか、又はそれぞれ別のコンセプトインデクスが実施される。なお、「(law enforcement)法執行機関」は、コンテキスト次第で、「(enforcement of law)法の執行機関、又は法の強化」と同一と見なされる場合もあればそうでない場合もあると理解されたい。

本発明の好適な態様では、照会処理エンジンは、照会を処理して照会を構成単位に分解するために設けられている。本発明の照会処理エンジンは、システムが、コンセプト発見及び分析処理並びにコンテキスト分析、曖昧性除去、及び検索照会に応えてユーザーに戻される結果の品質を高めることができる他の処理、を実施できるようにしている。本発明による照会処理エンジンは、ネットワークに接続されたスタンドアローン装置又はシステム、例えば、ここに説明している各種照会処理及び分析アルゴリズム並びに処理を実行するコンピュータシステムとして実施することもできるし、又はサーバシステム１６０のような検索サーバ又は他のサーバシステムの一部として含まれていてもよい。

図３は、本発明の或る実施形態による照会処理エンジンを含むシステムを示している。図示のエンジン３００は、インターネット上で、又はＬＡＮ、ＷＡＮ、直接リンク、配布媒体（例えば、ＣＤ、ＤＶＤ、フロッピー（登録商標））など各種ネットワーク接続を通して、様々なソースから照会ログファイル（又は実際の照会）を受信する。ソースの例としては、検索サーバ１６０（図１）、又は検索サーバの分散型ネットワーク内の複数の検索サーバ１６０、及び１つ又は複数のサーバ１５０が挙げられる。照会ログファイルソースは、通常、同じ機構又はエンティティ、例えばYahoo!サーバに関係付けられているが、必ずしもというわけではない。照会ログファイル（照会ログ）は、情報理論に使用されているような統計学的方法又は相互情報のようなコンセプトを使用して、照会エンジン３００によって処理される。好適な態様では、毎日照会ログを使用しているが、必要に応じて、例えば、時間、週など異なる周期のログを使用してもよい。照会ログは、通常、ユーザーの提出した実際の照会を含んでいるが、照会を行っているユーザーの地理的場所、タイムスタンプ、クライアントシステムのＩＰアドレス、クッキー、クライアントの種類（例えば、ブラウザの種類）などのような追加の有用な情報を含んでいる場合もある。照会処理エンジン３００は、各種照会ログを処理して、そこからユニットを生成する。ユニット及び発生頻度のような関連統計値は、メモリ又はデータベースファイル３１０に記憶される。

２００３年１１月１２日出願の米国特許出願第１０／７１３，５７６号（弁理士事件番号０１７８８７−０１１０１０ＵＳ）「検索照会からコンセプトユニットを生成するためのシステム及び方法」には、照会及び照会ログを処理してユニットを生成するため、及びユニットに基づく提案を生成するための方法論を含む、照会処理エンジンの態様の例が記載されており、同出願の内容を参考文献として本願に援用する。

或る態様では、照会処理エンジン３００はサーバシステム１６０側に実装されている。ユーザー及びページインデクス１６５とインターフェースを取る検索応答処理に加えて、例えば、照会処理、ユニット分解、ユニットディクショナリ導入、及び統計学的分析、を実施するためのソフトウェアは、サーバシステム１６０側で実行してもよい。他の態様では、照会処理エンジン３００は、図４に示すような別のシステムで実行される。ユーザーシステム１２０からの照会に応えて、サーバシステムは、照会をシステム１８０に伝送し、ユニットと統計値が戻されるように要求する。サーバ１６０は、システム１８０から受信したユニットとあれば統計値を処理して、ユーザーの照会に応える結果を、提案及び他の情報と共にユーザーに戻す。或る態様では、提案は、ユーザーが検索システムのダイアログを継続することを含んでいる。提案は、ユニットとして捕捉されたユーザーのニーズ並びにその拡張及び関連をかなり正確に理解することに基づき、ユーザーが次に何を探索することを望んでいるかについてのヒントと助言である。

或る態様では、実際の検索結果に加えて又はその代わりにユーザーに提示する提案を生成するために、ユニットディクショナリ３１０を使用しており好都合である。例えば、検索サーバ１６０又は他の検索知能は、照会を、ユニットディクショナリを制御している専用サーバ、例えば図４のサーバ１８０に送ってもよいし、又はユニットディクショナリのインスタンスを検索サーバ１６０に記憶してもよい。先に参考文献として援用している、２００３年１１月１２日出願の米国特許出願第１０／７１３，５７６号「検索照会からコンセプトユニットを生成するためのシステム及び方法」には、例えば、ユニット生成用の上記擬似コードに定義されている拡張及び関連を使って、或る実施形態に従って提案を生成するための方法論の一例が記載されている。

或る態様によれば、本発明は、検索オプションを従来のシステムよりも明瞭に、且つより役立つ様式で開示している。或る実施形態では、例えば、ユーザーはリンクしているサイト内で検索することができる。例えば、「Compaqコンピュータ」という検索に応えて、ユーザーには、とりわけ、Compaqコンピュータの販売業者に対する各種リンクを含む検索結果が提供される。本発明によれば、ユーザーには、リンクサイト内で直接検索できる能力が提供される。例えば、ユーザーが、ダイアログボックスに別の検索用語、例えば「ラップトップ」と入力してサイトを選択すると、これに応えて、新しい検索用語を使って選択されたサイト内で検索が行われる。このシステムは、リンクサイトにより提供された検索機能性があればこれにインターフェースできるように、又はリンクサイトにより検索機能性が提供されていない場合にはサイト内の検索を自発的に行うように、構成されているのが望ましい。戻される結果には、サイト内の１つ又は複数のページに対するリンクが含まれているか、そうでなければ、結果は、当該ページに関係付けられた検索機能性によって提供された結果ページとなる。例えば、選択されたリンクサイトがたまたまAmazon.comであれば、システムはAmazon.comサイトにより提供されている検索機能性に自動的にアクセスして、提供されている検索用紙に適切な検索用語を挿入することになる。

別の実施形態では、ユーザーには、同様の又は関連するサイトの現場検索、即ち「サイドウェイ」検索を行う能力が与えられている。例えば、ユーザーが、Ｗ日の地点Ａから地点Ｂまでの航空便情報に興味があるとする。この場合、ユーザーは、航空会社のサイト、例えばアメリカンエアラインのサイトに直接アクセスして当該サイト内で検索を行ってもよいし、或いは、ユーザーは、「航空会社」又は「空の旅」又は「アメリカの航空会社」などの検索を要求して、表示された検索結果内のリンクから特定のサイト、例えばアメリカンエアラインのサイト、にアクセスして、このアクセスしたサイト内でＷ日の地点Ａから地点Ｂまでの航空便情報を要求することもできる。ユーザーは、これで、要求された情報について、恐らくは各利用可能な航空便に関係する価格情報を含む情報を、アメリカンエアラインのサイトから閲覧することができる。本発明を使用すると、ユーザーは、手動で新しいサイトにサクセスして所望の情報を再度入力し直すこと無く、同一の情報、例えばＷ日の地点Ａから地点Ｂまで、という情報を使って、別のサイトを検索して同様の結果を得ることができ、好都合ある。本発明の或る態様によれば、ユーザーは、例えば、後で詳細に述べるように、汎用ダイアログボックスのようなダイアログボックスに、コマンド、例えば"$United"又は"$Unitedairlines.com"又は何か似たもの、を入力することによりサイドウェイ検索を行って、ユナイテッドエアラインのサイトで同じ検索を行ってもよいし、又は右クリックを使用して、或いは「サイドウェイ検索」アイコンを選択した後に、というように特別なやり方で、検索結果ページ内のリンク、例えばユナイテッドエアラインのリンク、を選択することにより同様の検索を行ってもよい。システムは、識別されたサイトにインターフェースして、所望の検索結果、例えばＷ日の地点Ａから地点Ｂまでの航空便に関する価格情報の一覧を載せている識別されたサイトのページ、を提供する。ユーザーがあるサイトに直接アクセスして、このアクセス先のサイトに関係付けられた用紙に検索情報を入力した場合、検索モジュール１２６はこの入力情報を記憶して、サイドウェイ検索が要求され、関連サイトでの用紙記入に必要に成った場合に、この情報を使用する。ユーザーは、無論、新たな選択先サイトの要件によっては、当該サイトで追加的な情報を入力する必要がある。このようにして、ユーザーには、同様の情報を求めて異なるウェブサイトに亘って行われる同様の検索の無駄を省いて合理化する能力が与えられる。

或る態様では、ページ上に現れる全コンテンツの殆どが、ユーザーにより「変更可能」である。例えば或る態様では、コンテンツ全体が、ユーザーが変更したいと思うかもしれない全ての事柄について（例えば、テキストボックス、ドロップダウンボックスなどに）事前記入済みの用紙のような形で現れる。そのため、この場合には、航空会社名、旅行日、価格（例えば、「入力金額よりも安価なもの」を示唆）、座席指定、目的地、航空便名など、の変更オプションが提供される。或る態様では、ユーザーは、ページ上のアンカーテキスト又はページリンクを変更して、それをユーザーが定義するコード又はラベルにする。例えば、ユーザーは、Yahoo!Mailのようなメールページへのリンクを選択して、これをラベル又はコードとして使用してもよい。ユーザーは、ここで参照名を例えば「メール１」というように変更してもよい。この場合、システムは、（例えば、ＨＴＭＬページの一部として）Yahoo!Mailへのリンクを表示するように言われる度に、当該リンクを「メール１」として識別されるリンクに置き換えるが、このような選択のやり方でもユーザーはYahoo!Mailアカウントにアクセスすることができる。同じく、ユーザーは、「メール１」ラベルの対象を変更して、Hotmailアカウントのような別のｅメールアカウント（又はこの事柄の何か他の対象物）を参照することを、選択することもできる。システムは、このコード又はラベルのマッピングを記憶することになり、このマッピングは、ユーザーがこのラベルを入力するか、ユーザーが当該ラベルを表している表示リンクを選択する度に、識別された対象にアクセスが行われることを示すことになる。

他の態様では、本システムは、インデクスを制御すること無く検索結果に関連する動的情報を提供するため、会社のサイト又はサーバとリアルタイムの通信リンクを確立するように構成されている。例えば、或る実施形態では、サーバ１６０は、加入会社のサーバ１５０_N-2と、リアルタイム又は周期的な、例えば数時間毎の通信リンクを確立して、インデクス参照先のページ又は製品の注釈、新規要約、更新、プロモーションその他の情報を入手する。例えば、ユーザーがラップトップコンピュータの検索を行うと、膨大な数の結果（例えばリンク）が戻され表示されることになる。この結果には、ラップトップコンピュータの供給者及び小売店が多数含まれている。或る実施形態では、本発明は、供給者（例えばCompaq又はSony）のような加入会社に、検索結果ページ上に表示することのできる動的情報を提供する能力を提供している。この情報には、ユーザーが探しているもの、この場合には加入会社などによって製造又は販売されているラップトップコンピュータ、に関する注釈、要約、プロモーションなどが含まれる。当該情報は、表示された結果リンクとは明白な関係無しに表示されてもよいし、又は、例えば会社のサイト又は関連サイトのページに近いリンクが表示されてもよい。

好適な態様では、サーバ１６０との通信のために、加入会社のサーバ、例えばサーバ１５０上で実行されるように構成されている処理が、加入会社に提供される（例えば、コンピュータ読取可能媒体のコードとして、又はネットワーク接続を通して送信）。このような処理は、背景で常時実行されており、サーバ１６０からの照会に応じて、インデクスによる参照対象の、又は個々の検索の結果としてのページ及び製品を識別している所望の情報を提供するのが望ましい。手動情報更新も実施されるが、その場合、会社側のオペレータが、所望の情報を、特定時に又はサーバ１６０からの要求に応じて提供する。

或る態様では、このような加入会社によってオークション機能がサーバ１６０を使って実現されている。例えば、ユーザーが「ラップトップコンピュータ」のような検索要求を入力すると、サーバ１６０は、インデクスの検索を行い、ユーザーに提供されるインデクスからページリンクを識別する。結果により複数の加入会社が結果の参照対象となった場合、会社は、結果ページの嗜好の順位、例えば、結果ページ上のリンクの嗜好の順位、プロモーション又は他の情報の嗜好の順位、にリアルタイムで値付けすることができる。好適な態様では、このようなオークション及び動的更新機能性は、インデクスを変更すること無く実施される。例えば、ユーザーが検索を入力すると、結果は、加入会社又はエンティティに関係付けられたサイトに何ら服従することなく、インデクスを利用してリンクとユーザーに戻すべき情報を識別して求められる。求められた検索結果が当たった加入会社又はエンティティ（例えば、検索結果に関係するリンクを有するエンティティ）には、オークションに入力するか又は情報を更新する能力が提供され、情報を検索結果ページに表示することができる。オークション入札及び動的更新情報は、検索が行われる前に提供されてもよいが、これによりインデクス検索が影響されることはない。例えば、加入者は、値付けを載せるか、又はインデクス内の特定の検索用語又は用語群に関係付けられた更新情報を入力することができる。値付け及び更新情報は、インデクスに結び付けられるか又はインデクスと統合されており（例えば、ポインタを使って論理列のインデクスエントリに関係付けて記憶され）、検索結果が識別された場合のみ使用される。次いで、システムは、検索結果に関係する結びついたオークションの値付けがあればこれに基づいて優先順位を決める。

或る態様では、それぞれのサイトが用いるオークション戦略は、ユーザーが誰であるのかを考慮に入れる。例えば、或る種のユーザーは或るサイトにとってはより有益であり、従ってそれらのサイトは、そのユーザーを他のユーザー達以上に引き付けようとする。他の態様では、オークションのプロセスは、多数回の繰り返しによって進行する。例えば、一回目が終了すると、各競合業者は、他社の値付けに照らし合わせて自分の値付けを再評価して、変更する。

或る態様では、ＵＲＬ、検索要求、ルックアップ、更新、リンクなどのような、動作可能な情報を入力するための単一の入力検索ボックスが提供されている。入力ボックスは、広くネットワーク全体に亘って利用可能になっているのが望ましい。本願では、入力ボックスは、検索ボックス又は汎用ダイアログボックス（ＵＤＢ）を指すものとする。汎用ダイアログボックスには、デフォルトのサイズと場所が与えられているが、ユーザーは、必要に応じてこのサイズと場所を構成し直すことができる。例えば、ユーザーは、例えば一度に数個の検索を入力できるように、或いは大量の動作可能情報を入力できるように、大きなボックスを要求することができる。また、ユーザーは、ボックスがツールバーに含まれるように、又はブラウザウインドウ側の狭いウインドウ又は別個のウインドウ枠としてウェブページ上に提示されるように指定してもよい。

ユーザーは単一の検索要求用語又は数個の要求／検索のような情報を同時に入力することができる（例えば、完全にコード化された、又は一部コード化されたフォーマットを用いて）。これに続く複数のＵＲＬ、照会、リンクなども同時に入力することができる。結果は、例えば空間／時間的順序で１つずつ表示してもよいし、或いは同一又は複数のページ内に編集してもよい。汎用ダイアログボックスを使用すると、ユーザーは自分の必要なありとあらゆるものを入力することができる。結果は、その生成に何が関わっていても、一様なインターフェースに現れるのが望ましい。或る態様では、コンテンツの意味論及びコンテキストにより、とるべき動作が決まり、従ってどのアプリケーションを呼び出すかが決まるが、これについては後に述べる。

従って、本発明は、ユーザーのマインドシェアを捉えると共に、大量の高品質なユーザー挙動データへアクセスできるという利点を獲得する、単純且つ独自のやり方を提供している。別の捉え方をすると、これは受動情報が動作可能にされていると考えることができる。今日、ユーザーは、ウェブページと自分のお気に入りの検索エンジンを設定したり、ブックマークを作成したり、それらについてｅメールを書いたり、それらについて送ったり、或いはそれらについてウェブログを書いたりすることができる。これらは全て受動的でばらばらなオブジェクトである。コンテンツがそこにあるだけである。対照的に、本発明では、能動的な情報、即ちそうしたいと思えば誰でも動作させることのできる情報、をユーザーが構築できるようにするシステム及び方法を提供している。

これまで、受動的な情報を動作可能な情報に変換するための努力は、一部には、コンテンツが通常どの様にまたどの様なフォーマットで生成されるかという理由で、完全には成功していなかった。大量の情報が実行されているテキストに載せられているだけで、自然言語理解システムは、コンテンツを動作可能にすることができる程度に、実行されているテキストを「理解する」のには十分でなかった。本発明は、個々の照会及び照会句を理解するのを支援するために、自然言語理解を式に組み込んだ方式を提供しており、照会も照会句も自動的に理解される。

或る態様では、本発明は、ユーザーに対してショートカット機能も提供している。或る実施形態では、例えば、汎用ダイアログボックスアプリケーション、例えばインターフェース１２８は、コンピュータシステム１２０上で実行されている複数のアプリケーションにインターフェースするように構成されている。ユーザーには、ユーザーが所望する機能性次第で各種パラメータを入力するダイアログボックスを含む表示が提示される。或る態様では、ダイアログボックスは、入力されたパラメータの種類に基づいて各種機能を行うように構成されている。例えば、ユーザーがＵＲＬを入力すると、ダイアログボックスインターフェース、例えばインターフェースモジュール１２８は、入力されたパラメータがＵＲＬであることを識別し、望ましくはブラウザアプリケーションを呼び出して、ＵＲＬによって識別されたサイトへの接続を確立する。ユーザーが単純な用語又は句を入力した場合、例えばインターフェースモジュール１２８は、検索モジュール１２６にアクセスして、入力された用語の検索を行う。例えば、「メール受信」コマンドが入力されると、インターフェースモジュールは、着信ｅメールメッセージ、又は望ましくは着信ｅメールメッセージの一覧を読み出すためにシステム１２０上に構成された１つ又は複数のｅメールアプリケーションにアクセスする。例えば、ユーザーが「メール送信」コマンドを入力し、続いてテキストメッセージ及び／又はアッタチメントの表示を入力すると、インターフェースモジュールは、ｅメールアプリケーションにアクセスしてメッセージを送信する。アッタチメントが識別されると、ファイルシステム、ドキュメント管理アプリケーション、又は他のアプリケーション、例えばワードのアッタチメント用のＭＳワード、にアクセスして識別されたアッタチメントが読み出される。同様に、インスタントメッセージ（ＩＭ）アプリケーションの場合、インスタントメッセージアプリケーションにアクセスすべきことをインターフェースモジュール１２８に対して確認するためにパラメータが入力される。

インターフェースモジュール１２８は、システム１２０上に駐在するどの様な数のアプリケーションとでもインターフェースするように構成可能であるのが望ましい。或る実施形態では、インターフェースモジュール１２８が取る動作は、入力されたパラメータの種類によって決まる。例えば、ＵＲＬ及び単純なテキスト句のような事前に構成されたパラメータの種類を使用することができ、更に、より高度なパラメータの種類、例えば「メール受信」と「メール送信」又は「ＩＭ送信」などを実施してもよい。また、或る態様によれば、ユーザー構成可能パラメータが使用される。例えば、ユーザーは、或るパラメータを、アクセスすべきアプリケーション及び／又は取るべき動作の識別子として定義してもよい。一例として、"update.calendar[date.time.description]"、又は単に"calendar[d.t.desc]"、又は適したフォーマット又はシンタックスを使ったユーザー所望するもの、が挙げられる。このようなパラメータは、カレンダーアプリケーション、例えばMicrosoft Outlook^TM、Yahoo!Calendar、又は他のアプリケーションが、入力された日付と時刻に関する記述で更新されることを、インターフェースモジュール１２８に対して確認する。ユーザーは、複数のアプリケーションにリンクするパラメータを定義してもよい。一例としては、"calendar.send[date,time,desc.,recepientlist]"があり、これにより、カレンダーアプリケーション、例えばMicrosoftOutlook^TM、Yahoo!Calendar、又は他のアプリケーションが、入力された日付と時刻に関する記述で更新されること、及び同一の情報が、ｅメールアプリケーション、例えばMS Outlook^TM、Yahoo!Mail、又は他のｅメールアプリケーションを使って、識別された受信者にｅメール送信されること、が確認される。ｅメールアプリケーションはアクセスされ、アドレス指定され、情報が送られる。ネットワーク内の特定サイト、例えばインターネット上又は私的ネットワーク上の特定のサイト、を識別するために他のパラメータ又はラベルを作成してもよい。一例としては、ラベル"Amazon（引数）"があり、これが使用されると、インターフェースモジュール１２８に対してAmazon.comウェブサイトが識別され、モジュールは、Amazon.comウェブサイト内で「引数」の検索を行い、Amazon.comからの結果ページをユーザーに戻す。好適な態様では、ユーザーが、パラメータを定義して、それをアプリケーションにリンクして、後の使用に備えてメモリに記憶することができるようにするショートカットウィザード又はツールが提供される。

或る態様では、事前に定義され特定のユーザーが指定したパラメータ、ラベル、及びコマンドと、それらが関係付けられた対応するアプリケーション又は機能との間のマッピングを記憶するための表又は他のデータ構造が、システム内に保持されている。表は、マッピングを読み出し、新しいマッピングを記憶し、及びマッピングを他のシステム及びユーザーに転送するために、インターフェースモジュール１２８がアクセスする。図５は、コード、ラベル、及びパラメータの転送、記憶、及び読み出しを実施するシステムの一例を示している。図示のように、クライアントシステム４２０は、相互に、及びインターネットのようなネットワーク４６０を通してサーバシステム４６０に、通信可能に連結されている。サーバシステム４６０は、或る態様では、任意のユーザーによる使用に備えて、事前に定義されたコード、ラベル、及び／又はパラメータのセット４６２を記憶している。ユーザーが定義したコード、パラメータ、ラベルは、どれも、事前に定義されたセット４６２と共にメモリ４６４に記憶される。例えば、ユーザーにより作成されたカストムセットを１つ又は複数の別々のマッピング表に記憶させてもよいし、それらを事前に定義されたセット４６２の一部又は全部と共により大きな表に入れてもよい。クライアントシステム４２０に記憶されているコードブックは、通常、周知のように、ＲＡＭ、ＲＯＭ、ハードドライブ、又はポータブル媒体（例えばＣＤ、ＤＶＤなど）のようなメモリモジュールに記憶される。数字４００は、コードブック（符号（Ｃ）で表示）がクライアントシステム４２０とサーバシステム４６０によって読み出され、それらの間を転送されていることも示している。各コードブックが、１つのマッピング、例えば１つのコード、ラベル、又はパラメータを含んでいてもよいし、複数のマッピングを含んでいてもよい。好適な態様では、コードブックは、ＨＴＴＰ、ＦＴＰ、ＤＭＡなどの周知のプロトコル又は技法を使って、転送、要求、送信、アクセスなどが行われるオブジェクトである。

好適な態様では、汎用ダイアログボックスは、ユーザー、例えばシステム１２０と、サーバシステム１６０の間に、二方向の永続的な通信チャネルを提供する。また、汎用ダイアログボックスは、ユーザーのブラウザが何を表示しているかに関わらず、ユーザーがダイアログボックスを利用できるように、各種ウェブページ上でユーザーに目に付き易いように表示されているのが望ましい。例えば、ユーザーがどのアプリケーションを使用するか、又はネットワークへアクセスしている場合は、当該ネットワーク内のどの様なページ又はサイトにユーザーが現在アクセスしているのか、とは無関係に、汎用ダイアログボックスは常にユーザーに表示されるのが望ましい。この様にして、ダイアログボックスの検索及びインターフェース機能性並びにサーバ１６０の知能が常にユーザーに提供される。代わりに、汎用ダイアログボックスは、通常は提示状態にあるツールバー内に設けてもよい。図６は、或る実施形態によるＵＤＢ５００を含んでいるＧＵＩ表示ページの例を示している。図示のように、ＵＤＢ５００は、例えば、キーボード、マウスなどのようなインターフェース装置を使ったユーザー入力を受信するための入力インターフェースを提供している。図６に示す特定のＧＵＩ表示ページは、Yahoo!システム内でメールサーバにより提供されているYahoo!Mailユーザーページである。

或る態様では、サーバ１６０上で実行中の処理は、ダイアログボックス使用時には、ユーザーにとって情報転送を最適化するため、ユーザーによる活動を追跡することができる。例えば、サーバ１６０は、現在及び過去の活動に基づいてユーザーの検索要求を予想し、又は、ユーザー宛又はユーザー発の情報転送に関して過去の情報を活用して、将来のデータ転送の最適化を図るように構成されている。後者の例として、或るユーザーがシステム１２０からシステム２２０の第２のユーザーに、ｅメールを送信している場合が考えられる。サーバ１６０は、第２ユーザーの永続的な二方向チャネルを通して第２ユーザーの活動を追跡し、第２ユーザーが、通常はｅメールではなくＩＭアプリケーションを介して連絡を受信する方を好むことを識別することができる。サーバ１６０は、この情報を第１ユーザーに連絡するように構成されており、或いはサーバ１６０は仲介者の役目を果たし、ｅメールメッセージを第２ユーザーの好みのＩＭアプリケーションを使ったインスタントメッセージに変換する。同様に、ユーザーシステム上のインターフェースモジュール１２８は、情報及びメッセージを単独で又はサーバ１６０と協同で、連絡及び変換するように構成することができる。代わりに、インターフェースモジュール１２８及び／又はサーバ１６０は、状況、つまり連絡のコンテキスト及び／又はメッセージのコンテキストが何であるか、に基づいて行動してもよい。即ち、ユーザーは、短いメッセージはインスタントメッセージにより配達され、長いメッセージはｅメールにより配達されることを望んでいるかもしれないし、或いは、ユーザーは或る特定ユーザーからのメッセージ、又は特定のサブジェクトに関するメッセージは、ある特定の手段によって配達されるように決めるかもしれない。サーバ１６０及び／又はモジュール１２８は、このようなユーザーが構成した動作に基づいて、又はユーザーによる使用のパターン（ユーザーはオーバーライドする場合もある）に基づいて、適切な動作を取ることができる。

ユーザーが定義したパラメータとラベルは相互交換可能であるのが望ましい。例えば、ユーザーシステム１２０は、パラメータ又はラベル、又はパラメータ又はラベルのセットを、個人的なコードブックでシステム２２０の第２ユーザーに提供する。パラメータを各種アプリケーションとリンクさせる基礎をなすコード（例えば、マッピングを保持している表／データ構造）も転送される。１つのラベル又はパラメータ或いはコードブックの転送は、ファイル送信などで直接行ってもよいし、転送は、例えばｅメール又はＩＭなどの通信にパラメータ又はラベルを使用して実施してもよい。通信でラベル又はパラメータを受信する第２ユーザーは、メッセージ内のＵＲＬの場合のように、例えばラベル又はパラメータをクリックすることにより、それにアクセスすることができる。ラベル又はパラメータ或いはコードブックの選択は、基礎をなすリンク用コードの第２ユーザーへの転送も実施するのが望ましく、受領及び記憶、変更（例えば、アプリケーションごとにリンク又は参照を変える）は随意である。この様にして個人的なラベルを共用することにより、ユーザー間の情報伝達が大幅に強化される。例えば、第１ユーザーの「今週のお気に入り映画」を参照する共用のラベルは、毎週変更されることになる。第１ユーザーは、その様な情報を第２ユーザーに定期的に再送信しなければならないのではなく、異なる映画に対するリンクへの参照を修正しさえすればよい。第２ユーザーにアクセスされ又は選択されると、インターフェースモジュール１２８は、例えばサーバ１６０を通して、更新された参照にアクセスして、この更新済みの情報を（第２）ユーザーのシステムに表示することになる。

次の節では、とりわけ、本発明の各種態様及び実施形態による均一ダイアログボックス、コード及びラベル、の様々な利点、特徴、態様、及び用途をリストアップしている。

或る態様では、汎用ダイアログボックスは、ネットワーク又はその他の場所の何処かに深く埋もれているかもしれない情報をユーザーが即座に入手するための機構を提供している。例えば、ユーザーの中には自分のカレンダーをオンラインで保守しているユーザーがいる。本発明を用いれば、ユーザーは、単純な句である"my cal next"を打ち込みさえすれば次のアポイントメントが、"my cal today"と打ち込めば今日のアポイントメントが、手に入るわけである。ユーザーは自分のカレンダーの更新を行うこともできる。例えば、"my cal update David Tue 10 am"と打てば、このアポイントメントをカレンダー内に適切に配置することができる。ユーザーは、このような単純なオペレーションのためにカレンダーにまで出向く必要はない。同様に、ユーザーは、"my portfolio"のような単純な句を打ち込むだけで、瞬時にして自分の株券のポートフォリオがどれほどの価値なのかが分かる。ユーザーは、同じやり方で自分の"my Yahoo!"ページ内のエントリを更新することもできる。従って、例えば、ユーザーは、$.がその人の地元の空港を表すものとして"$.Chicago next Tuesday"のような（コード化された）句を入力することにより、次の火曜日にユーザーの居住地からシカゴへ飛ぶ場合の最も安い航空券を見つけることができるわけである。

或る態様の汎用ダイアログボックスは、そこであらゆる事柄を片付ける能力をユーザーに提供するシェルプロンプト又はリスプ・インタープリタプロンプトによく似ている。例えば、それらは計算を行い、５５４３＋３４３*３２１＝を計算すると正確な結果がでる。ユーザーは、通貨換算、Ａ＄４０＝ＵＳ？を行うことができる。時間帯変換も行える。世界中の現地時刻が分かる。国内国際を問わず電話番号を与えると、現地時刻が分かると共に、電話をかけるのに最もよい時刻も分かる。或る態様では、本発明はあらゆる類の厳密な問い合わせに対する厳密な回答もサポートしている。例えば、この中の幾つかは、プロログ形式、アルゼンチンの人口は？、でもよい。従って、ユーザーは真／偽による問いかけを行うことができる。「アルゼンチンの人口は少なくとも６千万人」。同様に、「ｘｙｚの上映時刻」と尋ねれば、上映時刻が返って来る。「仮説」の照会も提供することができる。従って、例えば、ユーザーは、ＹＨＯＯが５０に跳ね上がると自分の株券ポートフォリオはどうなるのか、と尋ねることができる。

ユーザーは単純な式を作成して保存することができる。或る態様では、既存の式の大きなライブラリが設けられている。例えば、ユーザーは、複利計算を行うための式を入力してもよい。その際、或る特殊な状況におけるユーザーの資本の複利計算による価値を算出するのに、開始資本、利率、及び期間を示すだけでよい。

ＵＤＢにより提供される特注仕様化と独自化が、これを頑強なシステムにするキーである。RealNames及びＡＯＬショートカットなどは、出回って久しいが、成否合い交った結果を出している。本発明は、或る態様では、上記システムとは対照を成し、ユーザーは自分が参照したいものなら何であれ、どのように参照したいかを制御する。特定のキーワードではなく一般的なキーワード（利益が最大となるもの）についてのマッピングが確立される。先行技術によるシステムは、その様なマッピングを提供することはできない。

或る態様では、ジップコード、年齢、及び性別に基づく独自化が提供されている。例えば、照会「天気」は、ユーザーの住所に基づいて処理され、当該ユーザーに対して当該地域の天気の概要を作成する。

ショートカットは、ユーザーをどこか他の場所に素早く連れて行く、つまりは純粋なナビゲーション手段であるだけではなく、あらゆる種類の必要なものをコンパクト且つ簡単に入力し、それらがどこにあろうとも全てのものが直接的に実行／完遂されるようにする均一な手段を、ユーザーに提供する技法である。ショートカットは、ユーザーが様々なやり方（複雑なやり方も予想される）で操作したいと希望するオブジェクトを参照できるようにするコンパクトな手段でもある。ショートカットを考えることのできる幾つかの方法をまとめて、ユーザーが混乱しないような最も直感的に認識できるやり方を作り上げるべきである。キーは、ナビゲーションの視点と「どこにあろうとタスクをやり切る」視点とは、それほどかけ離れていないことを認識することである。この視点では、ユーザーが自分の必要なものは「ゲーム」であると表明した場合に、ユーザーに例えばYahoo!Gamesを与えることは、ユーザーが「天気！」又は「ボストン天気！」と打ち込んだ場合にユーザーにボストンの天気を与えることと、それほど違うわけではない。

或る態様では、ウェブに現在存在しているコンテンツ、即ちブックマークやディレクトリ一覧のようなものを活用できるようにして、ユーザーが望めば、自動的にマップするように翻訳できるようにしている。同様に、Yahoo!のようなサーバ又はサーバ群のコンテンツは、例えば、マッピングに対するディレクトリを含め、変換される。従って、例えば、"Cat$15"は、ユーザーを特定のカテゴリ内の１５番目のリンクにそのまま連れて行くことになる。アンカーテキスト、ＵＲＬ、照会対結果マップなどは、活用することができる既存の他のマッピングの例である。

汎用ダイアログボックスは、必要に応じてユーザーが自分の必要なものを直ちに直接入力するための或る中心位置を提供している。ユーザーは予期される必要性、即ち将来何時か起こりうる必要性、も入力することができる。この必要性が、全インターフェースが必要なものであれば、切替の必要性が認識され、例えば適切なアプリケーションを呼び出すことにより、途切れることなく移行が起こる。

ユーザーは、ある種の目的を実現するために、やり遂げる必要のある高い水準の目標又はタスクに関わって当然である。この観点では、一般的に、ｅメールをある個人に送ることは、それ自体はしっかりと定義された目的ではない。この目的のもっと良いステートメントは、或る人が或る情報を別の人に搬送する必要があり、ｅメールはそれを行う（数ある中の）１つの特定の機構である、ということになる。その情報は既にオブジェクトとして存在しているかもしれないし、或いはその種のオブジェクトを作成するのに適当な或る種の均一的な方法で、ユーザーは初めてそれを作成するのかもしれない。次に、それを別の人に搬送するという問題が浮上し、ユーザーがしなければならないことは、所望する通信の種類、即ち、同期、非同期、遅延、特定の時刻又は特定のコンテキスト、音声、テキストなどで利用可能にするなど、を特定するだけであり、そうすると適切な下位ルーチン及びアプリケーショ、即ち、ｅメール、インスタントメッセージ又はボイスメールなど、が適時に適当なやり方で呼び出され、オベジェクトが運搬される。なお、マッピング（マップ）及びパターンが確立されているため、ユーザーは、情報をどのように搬送するかを特定する必要はない。コンテキスト、状況、コンテンツの意味論などから、殆どの場合、システムは何をすべきかを正しく把握することができる。曖昧さが存在する可能性がある場合、ユーザーにはガイドとして手伝うことが求められる。例えば、"meet David 10 am"は、カレンダー入力を行い、ｅメールを送信し、警告を設定するなどには十分である。或る態様では、メッセージは或るモードで送信者から最適に発信されるが、特定のコンテキストと受信者側の状況により、別のモードで受信者に届けられる。

この観点では、「オブジェクトをｅメールで送信」は、「ウェブページを送信」、「Yahooメッセージを送信」、「ウェブページを発行（ホストに送信）」などに、より密に結びつく。一方、ｅメールを読むことは、「ウェブページを読む」、「ローカルファイルを読む」、「Yahooメッセージを読む」などに、より密に結びつく。ユーザーインターフェースの観点からは、アプリケーション、即ちｅメール、カレンダー、旅行予約、連絡先一覧などは、何か必須の、全体的な、統合された、分割不能なものと捉えなくともよい。事実、それらはユーザーにとってはかなり透明であり、単に或る下位機構の一部であり、つまりは多くの場合、ユーザーは気づく必要がないものである。では一般にはどうかというと、ユーザーには行うべきタスク又はルックアップを特定する必要があるだけで、そうすれば、ＵＤＢシステムは正しい機能性／ツール／アプリケーション／ルックアップを自動的に提供してくれる。

なお、汎用ダイアログボックス方式は、インターフェースの変更であるばかりでなく、サービスをユーザーに提供するやり方の基本的転換であるという点に注目することが肝要である。また、「ショートカット」は、ラベル付け／コード化マップよりも、もっと一般的なものであること、即ち、ユーザーが自分の必要性を単純な（例えば、自然な又は統制された語彙、命令形）言語で表現することができ、ユーザーの希望をできる限り直接的に満たそうとしているものであること、を認識することも重要である。

本発明により活用される重要な識見の１つに、以下のこと、即ち、特定のユーザーが有する情報の必要性はかなり複雑であるということ、がある。しかしながら、ユーザーがする必要のあることの殆ど（８０−９０％）は、ユーザー（又は、例えばユーザー群の中の誰か他のユーザー）が過去に行ったことと類似しており、適切にパラメータ化されている。これは、ユーザーが過去に行ったことに基づいてパターンが作成されている場合には、ユーザーにとっては非常に有益であるということが理由であり、これを活用してユーザーは将来もっと簡単に物事を処理できるわけである。ラベル／コードマップは、パターンを作成してその後活用するための手段である。ユーザーがカレンダーに入力する際、常にｅメールで秘書に通知している場合には、オペレーションを自動化することができる。ユーザーが或る事柄を大量に行いたい場合、例えば、大量のｅメールを送受信し、カレンダーを広範囲に編成し、拡大的株券ポートフォリオの分析を実施するなどの場合、ユーザーは、対応するアプリケーション又はツールが提供する完全なインターフェースを使用するほうが良い、ということは否定できない。しかしながら実際は、今日の多忙な業務環境では、人は上記類の事柄のそれぞれを間欠的に行わざるをえない。典型的なユーザーのタスクパターンシーケンスは、傾向としては、ｅメールに返信し、電話に応対し、集計表にデータを入力し、着信したばかりの新しいｅメールを読み、ミーティングスケジュールを自分のカレンダーに入力し、ウェブ上で競合相手についての情報を調べる、等々である。或る態様では、汎用ダイアログボックスインターフェースは、この作業パターンを念頭に置いて設計されている。

ショートカットは、システム上又はネットワークを通してのどちらであってもよいが、システムに利用できる情報／ツール／アプリケーションの完全な価値をシステムに公開する機会を提供している。個々のユーザーに特定のマップが確立されると、特定のユーザーが要求する多くの事柄は自動的に起きることになる。

肝心な点は、汎用ダイアログボックスが、ユーザーとウェブ（Yahoo!を含む）の間の双方向対話を強化するのに役立つことである。ユーザー側の主導権が積極的に採用され、要求に応えるだけではなく、追加の予想の動作が行われる。従って、或る態様では、ＵＤＢシステムは、好適に先行予測活動を行い、ユーザの必要性を予想する。単純な思考実験が、本方式の力を極めて適切に確立する。職場及び家庭における人の一日の生活において、ネット上（又はコンピュータ上）で何かを行おうと考えたが、それはそれほど単純に行えない事柄であることから断念した場合の、全ての例を考察しよう。今日、事によっては４段階の処理を要するものもあり、それは多分２段階でも多すぎる。一定期間に亘って、我々一人一人とって、我々の要求を行動で示すことを妨げているのは、実現したいと思うことを成し遂げることが比較的困難であるという事実だという場合が数多くある。汎用ダイアログボックスは、これら数多くの場合を、数十、又は数個、又は１つにまで減らす方策を提供している。

コード／ラベルマップは、日常生活に共通しているが、ウェブ上では有意な形式で存在していないものを捕捉する手段である。日会話の中で、人々は自分及び他人のオブジェクト、好きなもの嫌いなもの、好み、これまでに起こった或いはこれから起こりそうな出来事（例えば、２ヶ月以内に結婚するとか）、これまでに行った又は行おうと計画している行動など、の幾つかを参照している。本発明は、ユーザーが、友人、同僚、家族、又更にはウェブ全体との、このような参照を捕捉及び共有することができる独自のやり方を提供している。

或るユーザーインターフェース設計は、汎用ダイアログボックスを、ページの側部に細くて長いスクロール可能なウインドウとして現れるようにしたものである。この空間の様々な箇所に、ユーザーは要求を入力することができる。ユーザーの過去の対話の全部（又は一部）の履歴がユーザーに利用可能となる。このようなダイアログボックスの１つの利点は、ユーザーが次の要求を入力するために、上下へのスクロールを使用可能にする必要がないことである。ボックスが狭くて高い場合、ユーザーは、入力する照会を、各行に１つのコンセプトが含まれるようにして何行かに区切ってもよい。例えば、ユーザーは、１行目に「天気」、２行目に「ニューヨーク」、３行目に「今週」と入力すればよい。一方で、ユーザーの照会を複数のコンセプトに区切るのに、上記のような洗練されたアルゴリズムが提供されており、照会を一連のコンセプトして入力するようにユーザーに奨励することで、ユーザーとの対話を幾分簡単で実のあるものにしている。

ショートカットは、特定のアプリケーション用の別のインターフェースにユーザーが行かなくてはならない必要を無くすだけでなく、同一のコンテキストで幾つかを同時に呼び出せるように、異なるツール及びアプリケーションが提供することのできる付加価値を解釈するものである。例えば、ｅメールと編成チャートとをリンクさせてもよい。或いは、ユーザーに或るオフィスビル内の事務所に出向くように求めるｅメールを、或る人が受け取った場合、所在地を示しているビルの地図が自動的に提供又は表示される。この種の他の付加価値的な特徴が、汎用ダイアログボックスを通して提供され、これらの特徴は、ユーザーが何か特定のアプリケーション用の完全なインターフェースに行く場合には得ることができないものである。

ユーザーは、現在のオブジェクトが何であろうと、Perlのような$_を使ってそのオブジェクトを参照できる。照会、ウェブサイト、リンク、又は何か他のオブジェクトが参照対象となる。また、$4のようなコードは、例えば、お気に入りの検索エンジンを参照する。従って、例えば、別の検索エンジンで実行したばかりの照会を実行する場合、ユーザーは$5と打ち込みさえすればよい。

本発明の或る態様では、各種Unix（登録商標）型の強力なデータ／オブジェクト操作オプションが提供されている。例えば、ユーザーは＜何かのサイト、検索ストリング＞と入力すると、当該サイトからその検索ストリングに対する結果が得られる（我々の検索エンジン、又は、存在すれば、サイトの検索エンジンの何れか、或いは両方で実行）。

本発明は、正しいと期待できる汎用ラベル化を行う。人々は、何でも好きなものを好きなように呼ぶことができる。ラベルとコードは本質的に任意であり、ユーザーが望むものに完全に独自化される。それらは、文字と数字のストリング、シーケンス、又はアイコン又は各々を何らかの形に混ぜ合わせたものであってもよい。各ユーザーは、幅広い種類のラベル／マップが入っているコードブックを持つ。何でもラベル化できる。人々もラベル化でき、本や雑誌やＣＤなど、現実世界のその他のオブジェクトもラベル化できる。照会のような任意のシーケンスの単語もラベル化できるし、特定の出来事もラベル化でき、全てのオンライン特性及びウェブサイトもラベル化でき、ウェブページ群もラベル化でき、著名人、場所、ジップコードなどもラベル化できる。従って、例えば、「明日の私の航空便」は、或る時点では或る特定のオブジェクト、別の時点では別のオブジェクト、を参照するラベルである。ラベルは、自動的に調整できるようにパラメータ化される。例えば、「次週の私の航空便」は、その週が過ぎてしまえば「今週の私の航空便」になる。

ラベルは個人的なものである。ユーザーは、どんなラベルを選定したにせよ、割当に際しては完全に柔軟性がある。マップに対する提案は、一部には、ユーザー又はユーザー群の暗黙の挙動に基づいて提供される。同じく、本発明は、ユーザーの必要性が確実に満たされるのを支援するため、ユーザーに対して独自化された助言を提供する。

コードブックには、友人及び家族の連絡情報を含めることができる。また、救急時の連絡先番号も含めることができる。従って、エミィが「リチャードの電話番号」を打ち込むと（望ましければコード化形式で）、その番号は瞬時にそのまま返される。コード形式としては"$f4ph"が考えられるが、この場合には私の４番目の友人の電話番号を意味する。全てのコード及びラベルは、電話により、デスクトップを用いて、又は何らかの携帯装置を用いてなど、ユーザーがどの様にサービスを呼び出すかに関わらず利用可能であるのが望ましい。

コードブックは、全体でも一部でもよいが、共有可能であるのが望ましい。例えば、コードブックには幾つかの公的又は私的部分があってもよい。コードブックの諸部分は、全世界と共有してもよいし、或る部分は友人及び家族だけと共有し、或る部分は職場の同僚と共有し、などとしてもよい。コードブックはグループ群又は組織群内で使用するために構築してもよい。それらは組織内で共有してもよい。ユーザーの中には、彼らの汎用ダイアログボックス対話が、リアルタイムで、又は何らかのフィルタリング後に、数人又は全員と共有することができることを嬉しく感じるユーザーもいる。どんな分野であれ専門家が情報を発見して使用するやり方により、他の全員がこうして益を受けることができる。従って、ユーザーは、友人のコードを使用し、ある特定の時点では誰か見知らぬ人物のコードでさえ使用するように選択することができる。例えば、彼らは「リチャードのお気に入りＳＥ」又は「先週末にリチャードが見た映画」を尋ねることができる。

前から在るコード及びラベル、例えばＳＭＳで使われているものなどを、活用することもできる。コード自体へのショートカットがあってもよい。例えば、複数の意味による複数レベルのコードがあってもよい。例えば、コード$1から$5は５つの異なる検索エンジンということにしてもよいが、ここで、ユーザーは、特定の時点では上記５つのＳＥのうちの特定のエンジンを指すことになる「私のお気に入りの検索エンジン」のコードを有していてもよい。ＵＤＢは、コードに基づいて適用可能な検索エンジン（並びにブラウザアプリケーション）を呼び出す。同一コード／ラベルが、時点が違えば異なるオブジェクトを参照してもよい。例えば、対象物を動的に変更できる。例えば、コード「この定期刊行物の最新問題」なら、何であれ最も新しい問題を参照する。コードの特別のカテゴリは、永続的であることを要件にしてもよい。同様に、コード「私の友人リチャードのお気に入りの本屋」の対象物は、リチャードのお気に入りの本屋が変われば（リチャードが表明）、自動的に変更される。

コードを用いることにより、オブジェクト群、即ち、照会、ＵＲＬ、リンクなど、を一度に取り出すことができる。

コードは逆のやり方で使うこともできる。即ち、対象物が与えられると、それを指す全てのコードが識別される。ユーザーが気に入れば、参照対象のオブジェクトに対する参照があるところは何処でも、ラベルが自動的に追加又は置き換えられることになる。

完全な形式のコードは複数レベルである。そのようなコードには幾つかの事前に定義されたテンプレートがある。例えば、＜誰のコードブック、トピック、特定オブジェクト＞は、或るコードのセットのフォーマットである。コード<$f5,$t1,$3>では、$f5は特定の友人、$t1は「数学」、$3はその友人のお気に入りの確率の教科書ということになる。同様に、別のテンプレートとして＜製造業者、製品＞が挙げられる。この場合、<$2,$p1>はSonyのＶＣＲ、<$2,$p2>はSonyのデジタルカメラである。

「この」演算子の等価物をショートカット用に設けることができる。例えば、$31!qなら、その場合ユーザーには、照会のためサイト$3を検索という意味になる。事前定義済みのコードとしては、!cは当コンテキスト、!sは当サイト、!!sは以前のサイト、!pは当ページ、!!pは以前のページ、!!-は汎用ダイアログボックス内の以前のコマンド、等々、がある。

本発明が提供している別の関係する特徴は、或るオブジェクトの一部を選択的に変更して照会を再度実行する能力である。例えば、ユーザーが「マイアミのホテル」を検索し、次に、!m タンパと入力すると、この新しい照会は「タンパのホテル」と解釈される。事実、我々は、コンセプトのカテゴリについて持ち合わせている知識を活用する更に強力な機能性をサポートすることができる。例えば、第２の照会「!q タンパ」は、「タンパのホテル」の検索には十分である。カテゴリ情報を活用すると、「タンパ」は「ホテル」ではなく「マイアミ」の置き換えである、ということが分かるわけである。しかしながら、ユーザーが「!qレストラン」と入力したら、新しい照会は「マイアミのレストラン」となるはずである。

前回の照会には、全種類の単語並びにフィルタを、例えば、単純に連ねて付け加えることができる。

ある種のコードブックは、家族間、友人間、及び同僚間で構築して共有することができる。それらは、人々の群全体で、例えば会社内部の技術チームにとって、有用なラベルを含んでいてもよい。

以下の種類の前方照応的参照、即ち、私の住所、私の隣人(!n)、私の時間帯、私のお気に入りperlチュートリアル、私のお気に入りの物理学教科書、私のジップコード(!z)、私の銀行、私の株券ポートフォリオ、私のペット店、私の薬屋、私の美容院、私の靴屋、私の妻の銀行、私の図書館、私の友人のお気に入りperlサイト、私の友人の会社、私が最後に寄ったスポーツサイト、私が最後に寄った予言サイト、私が予言サイトの後に寄ったサイト、クリケットに関して私が行った最後の検索（筋が通る場合には「私」を「私たち」に置き換え可能）もサポートされる。

ある種の参照は、物理的な店舗（又はそれら店舗のオンライン版）に対してであってもよい。例えば、「私の本屋」はAmazonであり、「私の検索エンジン」はYahoo!であることが考えられる。「私のＣＤ店」ならYahoo!Shoppingがある。参照によってはオフラインのオブジェクトの場合もある。例えば、<$2,0,11,7>は、印刷された新聞の時事問題の１１ページの７番目のＵＲＬに対する参照かもしれない。どのようなコンテキストでも、オブジェクトの全範囲を、範囲演算子を使って特定することができる。従って、$7:12は７から１２までの全てのコードを指すことになる。

コードは接頭部が設計により自由にできる。例えば、$2378は、$2$3$4$8と書くところをコンパクトにしたものとなる。

各種ラベルに対する好適な表示法は、ユーザーが時間経過に合わせて案出する必要がある。例えば「ベースボールに関して私が最後に寄ったサイト」では、コード !sbaseball だけで用が足りる。コードは、プログラム言語のマクロのような挙動をすると捉えることができ、普通テキストと相互に混在させてもよい。例えば、$t1が哲学で、$2がニーチェである場合、$tl@2ean 美学、は「ニーチェの美の哲学」ということになり、$tl@03は、哲学者ニーチェを指す。

ラベル／コードは、現在の時刻、この時間、今日、昨日、先週など、に対して設けてもよい。例えば、ユーザーはコンパクトに「先週のログ」又は「先週の定義刊行物」と尋ねてもよい。ユーザーはどの年のどの月のカレンダーを呼び出してもよい。

一般に、コードはユーザが自分の気に入るように作成する。システムが、コードは後刻利用されるはずであると考えたときに、ユーザーはコードを作成するよう促される。例えば、ユーザーが複雑な照会を打ち込んで、結果のセットが有用であるようであれば、システムは、その有用な照会を何か思い出しやすいコードで参照するように、というオプションをユーザーに提供する。ここで、無論、このような照会は再使用可能であり、コードブックが共用可能であることから、再使用されて共用可能となる。

コード／ラベルは、それ自体は複雑な構造である。コードは、それぞれ、短い表記もあれば長い表記もある。他の属性も幾つかある。ユーザーには、これら複雑な構造の幾つかの態様を、ユーザーがそう望む場合には直接的に操作するためのインターフェースが提供されている。どんなコンテキストであっても、多層コード状況における上位コードは、当面スティッキーにされる。例えば、ユーザーが承認されたリチャードのコードブックを持っていれば、当座は、使用される全てのコードはそこから引き出されるものと仮定することができる。ある種のコードブックが当該コードを解釈できなければ、別物のより一般的／特定の筋の通ったコードコードブックを調べるように、代案が遠まわしに提示される。

或るサイト群に関するコードの例として、「私が毎夜大抵立ち寄る全てのサイト」というのがある。特定のタスク及びスクリプト用のコード／ラベルがあってもよい。例えば、「ブックトラベル」ならコード$1としてもよい。「先週私が見た映画」、「今週末私が見た映画」、「明日私が見る予定の映画」、「私の友人リチャードが２週間前に見た映画」などのようなコンセプトに対するコード／ラベルがあってもよい。Yahoo!ネットワークで上映時間を調べ又は予約した場合は、そのようなマップを設定するようにユーザーに対するプロンプトが提供される。

本発明は、オブジェクトがどこにあろうと、ラベルから当該オブジェクトまでのマッピングを提供する。例えば、ユーザーの中には「私の旅行代理店」がExpediaである、というユーザーもいるかもしれない。ＵＤＢはそのようなユーザーをそこに、即座に、直接、苦も無く連れて行く。

コードブックは共有可能であり、実施にはウイルス効果が組み入れられている。ユーザーがマッピングを設定すると、ユーザーの家族や友人に、これからこの特徴に寄与することを通知したいか否かが問われる。同じく、新しいマッピングがコードブックに追加されると、興味のあるユーザーには通知される。同様に、マップの対象物が変更になると、興味のあるユーザーにはそれが自動的に通知される。

番号によってブックマーク、ページ上のリンクなどを指すことができる。例えば、$b37は、或るカテゴリの37番目のブックマークを指す。予想される曖昧さ解除を可能にするのに十分な頭文字を入力することにより、それを見つけることもできる。

ユーザーには照会を表現する特別なやり方が提供される。例えば、「〜並びに何々」を前に付けて二重引用符を入れる代わりに、単に接頭語として＼w.を入れればよい。コードは、照会の特定の解釈を強制するのにも使用できる。例えば、「$a９７ホンダ」はこれがアドレスであることを意味する。照会は、検索エンジンにある種のデフォルト挙動をオーバーライドさせる特別なエスケープシーケンスを含んでいてもよい。例えば、ＵＲＬ（コードによる参照又は完全参照）は、その特定のウェブサイトに直接行く要求として解釈されることになるが、或いはＵＲＬの前の一文字によって表されなくともよい。

ステップの順序は、単純なコードとして符号化される。例えば、ページＰに行き、リンクＬをクリックし、出てきたページでリンクＬ’をクリックし、対応するページを私に戻せ、に相当するコードがある。（パラメータ化された場合、これはもっと筋が通ったものとなる。）この場合の特別な事例として、直進型「アイ・フィール・ラッキー」特性があり、これはどんな照会ｑの場合にも、ユーザーを何であれ最初の結果に連れて行く。

マップの中にはアイテムのセットにできるものもある。例えば、$sは、５から１０個の検索エンジンをマップする。「ＢＢＣをプレイ」又は「ＢＢＣを立ち上げ」は、Yahoo!又は他のポータルでＢＢＣをプレイするために設定される。特定のユーザーが「ＢＢＣ」に関連してこれまで行ってきたことが唯一その立ち上げである場合は、照会「ＢＢＣ」だけで十分事足りる。この様に、数種類のこの種のコマンドが突然使用可能になる。従来の種類のブックマークは、この種の機能性をサポートできない。

ユーザーは、意のままに他の人のラベル／コード／ブックマークを拾うことができる。ユーザーは、あらゆる種類のスクリプト、パターン、マクロなども拾うことができる。

サポートされている機能性の他の例としては、「mail$5：１分以内に会いましょう」又は「未読メールを表示せよ」又は「２４時間内に受信した全メール（及び／又はメッセージ）を表示せよ」又は「このメール／メッセージを$7フォルダに移動せよ」などが挙げられる。大型版の汎用ダイアログボックスを使って長いｅメールを書くこともできる。（汎用ダイアログボックスは、寸法調整可能なｘ−ウインドウと考えられる。ユーザーがどんな大きさを選定しようが、別大きさを選定するまではその大きさのままで固定される。）多分、汎用ダイアログボックスのもっと良い呼び名は汎用ダイアログウインドウ、即ち、誰もが、情報、ツール、及びアプリケーションの（ネットワーク化された）世界に必要な唯一無二のウインドウである。

サポートされている他のカテゴリのコマンドとしては、「私のGeocitiesページでこれを発行せよ」、「私のデスクトップに以下のファイルを表示せよ」、「このウェブページを（次のコメントを付けて）$5に送信せよ」などが挙げられる。サポートされている別の種類のコマンドには、「$_でデービッドを見つけて」があり、この場合、現在のコンテキストはウェブページ、ｅメール、ウェブサイト。ｅメールフォルダなどである。

本発明は、照会のマップの概念を２つの方法で特定の結果に拡張する。照会は、意味論的に照会に対応する全てのパターンを含むように拡大することができる。例えば、ユーザーは「シアトルのホテル」又は「ＷＡのシアトルのホテル」又は「シアトルホテル」と打ち込めば同じ結果を得ることになる。マップの結果を、１つの結果以上の何かに拡張することもできる。例えば、ユーザーがある種の照会の結果を２回、３回ないしは４回見ることを規則的に行っているようであれば、当該照会を結果の正にそのサブセットにリンクさせるマップが提供される。本発明は、或る結果から次の結果に直接導く簡単なやり方も提供している。

連絡先情報は、アクセスして、直接、追加／変更することができる。ユーザーは、あらゆる種類の一覧作成に汎用ダイアログボックスを使用することもでき、例えば、やるべきことの一覧、ショッピングリスト、食料品店一覧など、何でも作成することができる。或る態様では、ユーザーがこのようなリストの要素を自動的に作成するのを支援するために、ツール及びアプリケーションが提供されている。これらのリストがどこに存在していても、ユーザーはアクセス可能である。例えば、ユーザーは、次にどこに行くべきか、又は、移動中、例えば職場からの帰り道で他に何を買う必要があるか、を忘れているかもしれない。ユーザーは車から携帯電話でシステムにアクセスして、テキスト対音声技術を使って一覧の関連部分を読み出してもらうことができる。

或る態様では、全種類の受動的コンテンツが動作可能である。これには、リンクではなくただの普通テキストであるコンテンツが含まれる。例えば、ページのどこかに表記の一覧が提示されると、ユーザーは"$q$57"を要求することができ、これは5番目と7番目の表記を照会として実行するという意味である。マップは、必ずしも１つの対象物種に対する唯１つのアイテムである必要はない。マップはパターンを指定するための規則的な表記を使用することを含んでいる。例えば、ユーザーは、ユーザーが出す或る種の照会、例えば米国国内都市という照会など、どのような照会であってもこれに対するものを、これこれの結果及び情報がこれこれの順序で現れるように求めることができる。従って、一般に、マップは、照会／必要性パターンから対象物（１つ又は多数）までを含んでいる。照会パターンは、ユーザーが提案してもよいし、本発明の照会分類化アルゴリズムで発見してもよい。

マップは、特定の照会又は特定のパターンの場合は、ネットワークサイトの一部、例えばＩＹ（Inside Yahoo!）（コンテンツを直接見る場合）に直接アクセスすることもできる。同様に、マップ対ディレクトリコンテンツも可能である。

ユーザーは、自分の（カストム化可能な）環境変数を好きなように設定することができる。或る環境変数値は、ユーザーが照会／必要性を入力開始する前でも、一連のコマンドを介して設定することができる。既存のカストム化オプションは、ユーザーが汎用ダイアログボックス内で変更することのできる環境変数に単純に変換される。次のようなもっと複雑なオペレーション、「$2の今週の会談日時を見つけて」もサポートされており、この場合、$2は或るプロジェクトに関わっている人々の特定のチームを指している。

別の一般的なオペレーションの型としては、「一覧ｘ」という形式のものがあり、ｘは各種事物のどんなものでもよい。ある種の態様では、一覧同士の交差と結合もサポートされている。例えば、「一覧ｘとｙ」は、この２つの一覧に共通するものを示せという意味であり、「一覧ｘ又はｙ」は、一方又は両方にあるものを示せという意味である。

日の出、日の入り、月の位相、個人のホロスコープなども、ここ汎用ダイアログボックスで利用可能である。例えば、「私のホロスコープ」では、ユーザーは日毎の又は週毎のホロスコープを入手することになる。ユーザーはマップをどこか別の場所からインポートすることを奨励される。例えば、ユーザーは、自分の個人的なブックマーク全てをマップとしてインポートすることを要求してもよい。事前に定義されたラベルに対する参照さえも、ユーザーが事前に定義されたラベルの内どのラベルを参照するのにも自身のラベルを選定できるように、カストム化される。ユーザーは興味のある特定の領域をコンパクトに参照することができる。例えば、ユーザーが「私のエンターテイメントブックマーク」を要求した場合、システムは、エンタテイメントカテゴリに属しているブックマークをユーザーに示してもよい。

ユーザーは、結果の番号を入力するだけで、直接特定の結果にたどり着くことができる。例えば、$r$7であれば、ユーザーは、結果のブロック内の7番目の結果に直接連れて行かれる。これは、スポンサー付き検索の結果、例えばＩＹの場合、並びに主な検索結果にも機能する。ユーザーは、「クリア」などのコマンドを使うことにより、ＵＤＢの消去を、或いは当セッションの間の全履歴の消去をも、要請することができる。

オブジェクトの束にラベル付けすることができる。例えば、照会ストリングに嗜好を随伴させる。同様に、コード並びにコードブックの関連部分もそのようにして、コードのアプリケーションの結果がユーザー間でより簡単に共有できるようにする。ＵＲＬ完成も、「ebayに進む」が「www.ebay.comに進む」と解釈されるように、自動的に行われる。或る態様では、個別及び集合の両方で、ユーザーに提供するのに最も適した挙動を決めるために、ユーザーの意図が活用される点も重要である。

次のような種類のイエローページ照会もサポートされており、地元のFry's店の営業時間を見つける場合の「営業時間Fry's$.」などがサポートされている。

検索結果ページ（及び他のページ）のブロックが明確にマークされると、ユーザーは、単純なコードを使って幾つかある箇所の何処にでもジャンプすることができる。例えば、"$s4"は、ユーザーを4番目のスポンサー付き検索に連れて行き、"$i3"であればユーザーを３番目のＩＹ結果に連れて行くなどである。ユーザーは訪ねようとする幾つかのリンクを一度に指定することができる。例えば、スポンサー付き検索３とウェブ結果１４を意味する"$s3r14"と入力してもよい。ユーザーは、汎用ダイアログボックス内にマップを明示的に確立することもできる。例えば、ユーザーの好きな或る記事の句が与えられた場合、ユーザーは"phrase:$_"と打ち込むだけでその句をそのウェブページにマップすることができる。

マップは対象物の性質について非常に精密に作成することができる。今日のアンカーテキスト、ＵＲＬ、及び照会は、この属性をサポートしていない。例えば、或るマップは、その対象が１つのウェブページ又はウェブサイト、又はウェブサイトのセットであることを明確に示す。それらは上記オブジェクトの特定の部分を指すこともできる。

ユーザーは、参照したいと希望する対象物が何であろうと、自然言語又は私的言語でラベルを作成することができる。例えば、ユーザーは、英語のコンテンツに対して中国語のラベルを作成してもよい。ユーザーは、英語の句と中国語の句の間に自身のマップを設定することさえできる。ユーザーが、どこからのコンテンツでも良いが英語のコンテンツを見るとき、元のテキストに加えて又はそれに代えて、英語のエントリに対応する中国語の句が利用可能にされる。一覧としての対象物もサポートされる。例えば、ユーザーは、最近のゴシップを見つけることに特に傾注している著名人の一覧を保守することを希望するかもしれない。ユーザーは、汎用ダイアログボックスを使って、思いのままにそのような一覧を追加したり、又はそのような一覧からアイテムを削除したりすることができる。

汎用ダイアログボックスを介して、ユーザーが過去に使用したどんな特定のツール又はアプリケーションの履歴でも、直接呼び出すことができる。而して、例えば、ユーザーは読み／書きした直近の５通のｅメールを入手することができ、YahooMapsで行った直近の７つのルックアップを入手することができ、或いはYahooイエローページを使って調べた直近の１０の事業をルックアップすることができるわけである。より厳密には、ツール又はアプリケーションは、背景にあり、明示的に言及する必要はない。即ち、単純に「最後の５つの方向」又は「最後の５つの事業ルックアップ」などを求めればよい。ＵＤＢシステムは、どんなツールが関わっていたのかを判断して、彼等に正しい一覧を戻す。これは、ユーザーには最近見たものを再度見る必要が生じる可能性が非常に高いという意味での「最新性」の効果により、非常に重要な特徴である。

本発明は、インターネット上の記事を即座に調べる能力も提供している。例えば、汎用ダイアログボックスを使用して、会議室の同僚の電話番号を見つけることもできる。ユーザーはどこに入力したデータであっても、データを繰り返すことができる。ユーザーが入力したデータは、自動的にマップに変換される。例えば、当セッション中に５つの異なる形式で１０アイテムのデータを入力した場合、それに対する参照を入れるだけで、どんな形式ででも入力したものを取り戻すことができる。

複雑な照会は、ユーザーが、作成したい旅行計画を完全に特定できる前に、記入せねばならない場合が時々ある幾つかの用紙のように、幾つかの段階を経て作り上げられる。

或る態様では、ＵＤＢシステムは、コードマップ特徴のチューリング完全セットをサポートしている。例えば、"if"及び"while"ステートメントの両方が支援されている。例えば、「ifYHOO＞25なら、証券代理店サイトに行ってこれこれの情報を得よ」というマップとして構築されているパターンもある。

人間の頭脳は、テキストよりも視認アイコンをより効率的に知覚するよう調整されているので、アイコンをマップ内の参照に使用することも実施されている。

本発明は、マップの対象物をマップ自体にすることができる。本発明は、最初のオペレーションの結果に適用されることになるlispスタイルの "eval"型演算子の等価物もサポートしている。例えば、"eval（「先週末にリチャードが見た映画」）"であれば、ユーザーを検索結果ページ又はその特定の映画用の特定のページに連れて行くことになる。

或る態様では、ユーザーが必要なものに関して知っている限りのことを入力するように奨励されているので、より複雑な照会の場合に支援するため、大型の汎用ダイアログボックスが設けられている。例えば、ユーザーは、長い間音信不通の友人を探している場合にその友人について知っている全ての事柄、即ち、名前、通った大学、住んでいた所、働いていたところなど、を入力する。すると検索機能は、情報を処理して、上記のようにコンセプトユニットを求め、一連の照会を生成して、対応する検索結果を配合して、配合済みの結果をユーザーに提供する。

本発明は、洗練された照会完成特徴を提供している。ユーザーが打ち込むと、関係する単語とユニットが示される（ドロップダウンボックス内に表示）。これらは、関連検索に基づいているが、個々のユーザーに独自化されている。例えば、ユーザーが"sf"と打ち込むと、天気、ホテル、レストランなどを示すドロップダウンボックスが、一部には、このユーザーが以前に"sf"について検索したものに基づいて、表示される。ユーザーは、照会の一部を不変に他を可変に保持するのと同様に、明示的にせよ暗示的にせよクロス乗積である照会を入力することができる。例えば、地点ＡからＢとＣを経由して地点Ｄまで飛行する場合、それらの地点の天気を一度に調べることができる。また、地点Ｄについて、方向、マップ、レストラン、及び付近のホテルも一度に調べることができる。

クロス乗積照会は、ユーザーがマップとして持つことになった２つ以上の一覧を交差させることにより作成される。例えば、ユーザーは、旅行先の都市の一覧、及び各都市について見つける必要のある物の一覧を有している。これら一覧のそれぞれが４つのアイテムを有している場合、ユーザーは「１１ｘ１２」のような単純なコマンドで１６の照会を生成することができる。

ユーザーがラベル及び照会を容易に入力できるようにするため、本発明は、ユーザーが自分の必要性をより詳しく特定するにつれて増分的に現れるドロップダウンボックスを提供している。本発明は、ユーザーが、要求を作成したいときに、テキストストリング、アイコン、コードなどを入力できるように、ドラッグアンドドロップ照会生成インターフェースも提供している。

ユーザーは、特定のニュースアイテム又はオークションアイテム（又は、追跡しているもの何でも）にマップすることができる。例えば、新しい記事が中断されたが、ユーザーが強い興味を示しているような場合、システムは、以降の展開をもっと簡単に追跡できるようにユーザーがそれに対してコード／ラベルを作成することを望むか否かを尋ねる。

ユーザーは、必要としているもののセットを（コード化形式で）一度に特定することができ、するとそれらは、一枚のページ上に、又は緊密に結びついたページ群として別々に、現れる。例えば、$2$5$7$9であれば、サンフランシスコの地図、天気とホテルの全てが一度に戻される。従って、ユーザーは、追っかけている試合が何であれ、その瞬間の「最新のクリケットスコア」を見出すことができる。ユーザーは、追跡している航空便が何であれ、「最新の航空便情報」を見出すことができる。総合的な可能性も存在する。例えば、ユーザーは、特定カテゴリの検索について（同僚の中で）最も人気の検索エンジンで検索を実施することを要求することができる。ユーザーは、或るカテゴリの検索に対し、最初に１つの特定の検索サービスのセットと相談できるように、マップを設定することもできる。

大型の汎用ダイアログボックスを使えば、ユーザーに、関連した検索を、ユーザーの元の要求の直ぐ次に示すことができる。要求が曖昧な場合、システムはユーザーに予想される解釈の一覧を提示し、ユーザーはその中からそのときに表現しようとしていたものを選択することができる。照会が曖昧であれば、システムは、同じ結果ページに（はっきりと分かれたブロックとして、又は数ページの緊密に結び付けられたページとして）、必要物の最も異なる解釈と予想されるものに対応する結果を示す。ユーザーがどれに興味を持つにせよ、システムはそれを更に詳しく示す。例えば、ユーザーが要求として"java（登録商標）"と打ち込むと、１ブロックの結果はプログラム用語という解釈に対応するものであり、別のブロックはコーヒー豆という解釈に対応しており、更に別のブロックはインドネシアの島という解釈に対応したものになる。

ユーザーは、複雑で多重ステップのオペレーションをコンパクトな形式で表現することができる。Unix（登録商標）スタイルパイプとの類比を作ることができる。例えば、プログラム言語としてのJava（登録商標）に関係する結果を示せ、を意味する「Java（登録商標）|プログラム言語」を要求することができる。「Java（登録商標）|プログラム言語を除く」を要求してもよい。大事なのは、システムがユーザーに、彼らの何らかの選択基準に基づいて結果をろ過することを求める能力を提供しているという点である。ユーザーは、或るソースからの情報が別の場所に送られるようにすることもできる。例えば、"$.Hawaii wed 1 week | mail $5"は、私の住んでいるところからハワイまで水曜日発で１週間の最も安価な旅行オプションを入手してそれを$5にメールせよ、という意味になる。この情報は、ユーザーの画面にも提示される。同様に、ユーザーが何かをカレンダーに入力すると、それが秘書にメールされ又は会談予定の人物にメールされるように、プログラムすることができる（又は明示的に頼んでもよい）。例えば、"update David 10 Wed | mail $7"というふうに。

幾つかのソースからのデータ及びそれらソースでの計算処理を含んでいる興味深い機能性もサポートされている。例えば、"$_ | publish anchor text: _…"は、読み出したばかりのｅメールのアッタチメントを、アンカーテキストが提供された状態で、ユーザーのホームページへのリンクとして発行することができる。ユーザーは、何らかのコンテンツを何らかのファイルに入れるために、リダイレクション演算子を使用することもできる。ユーザーは、或るコンテンツが或るファイルから読み出されるように要求することもできる。例えば、照会の幾つかはファイル内にあってもよい。ユーザーは、全部を1つずつ順に実行するように要求してもよい。同様に、ＵＲＬはファイル内にあってもよく、その場合ユーザーは、対応するページを1ページずつ訪ねるよう希望してもよい。

「デービッドの最後のｅメールのＵＲＬに行け」のような表現も理解され、即時に実行に移される。ユーザーは全ての種類の共有オブジェクトへのアクセスを要求することができる。例えば、ユーザーは"calendar David today"と打ち込んで、友人又は同僚のデービッドのカレンダーを直接入手して見ることができる。

ユーザーが複雑な照会を作成できるように、ドラッグアンドドロップ式又は他の様式の単純なインターフェースが提供されている。それらは、オペレーションを表現しているボックスと、データフローを表現しているオペレーションの間の矢印とで、視覚的に示すことができる。全ての照会は、どんなに複雑でどれほどコンテンツが豊かな照会であっても、記憶可能、共有可能、且つ再利用可能である。全種類のパターン（如何に複雑であろうと）を必要に応じて記憶し、パラメータ化して、対象物が時間経過に伴って変化できるようにしてもよい。

ユーザーは、"$4;$3;$7;$9"と打ち込むだけで、１つの連続した合理的なやり方の中で、４つまでの異なるサイトで、航空会社、ホテル、レストラン、及びレンタカーを予約することができ、この場合、前記４つのコードは上記の何れかを予約する機能を提供している４つのサイトである。マップは、何らかのコンテンツの特定の部分に対するものであってもよく、例えば、どこかの、つまりは特定のウェブサービス又はポータルのコンテンツ内の、又はウェブ上のどこかのコンテンツ内の、１つの画像又は段落に対するものであってもよい。これは、人々が、正にウェブ上でコンテンツの特定の部分を参照し共有する方法を提供している。マップは、どんなコンテンツの特定の部分に対するものであってもよく、例えば、どこかの、つまりはウェブサイトのコンテンツ内の、又はウェブ上のどこかのコンテンツ内の、１つの画像又は段落に対するものであってもよい。これは、正にウェブを介して、人々がコンテンツの特定の部分を参照し共有する方法を提供している。

人々の中には、元よりマップ作りに長けた人がいるものであり、（それを共有可能にする限り）彼らの努力がより多くの人に喜ばれることになる。ユーザーは他社のマップを使用することができ、それらに票を投じることもできる。

ユーザに提供されている他の特徴としては、摂氏と華氏の温度換算、ポンドとキログラムの換算、センチメートルとインチの換算などがある。また、温度と風速が与えられ、体感温度を求めるというような、幾分複雑な計算も含まれる。郵送料、ジップコード、類語辞典、辞書、百科事典、スペルチェック、イエローページ、ホワイトページ、電話番号逆調べ、テレビ番組予定、映画上映予定なども、汎用ダイアログボックスを介して入手可能である。ユーザーは、緊急／中断状況について発見し、通知を受けることができる。例えば、"$.alert"照会は、現在の天候関連警報があれば、或る値を戻すことになる。同様に、その区域に一般的な停電があるかどうかが分かる。ユーザーは、どんな種類の符号を入力することも、それらを調べることもできる。ユーザーはあらゆる種類の簡単な（又はより詳細な）ログを保持することができる。ユーザーは助言及びヒントを入力することができる。ユーザーは、例えばある人の名前をどう発音すべきかのような、覚えにくい事柄を見失わないようにするために記憶力の助けとしてこの特徴を利用することもできる。

或る態様では、Yahooメッセンジャーセッション全体を、汎用ダイアログボックス内で実行することができる。ユーザーは、一人又は複数の人々と対話することができる。同様に、ＵＤＢは基本的なウェブ会議をサポートしている。汎用ダイアログボックスは、現場照会を扱う場合にも利用できる。これは、ユーザーが旅行を調べて、アメリカンエアラインを利用して地点Ａから地点Ｂまで旅行するのに利用できるオプションをちょうど発見したという場合に、"$. United"と尋ねるだけで、ユナイテッド航空で同じルックアップの結果が戻されるようにすることができる。"buy $.At Amazon"のようなコマンドもサポートされており、この場合、$.は現在の本の題名／照会を表している。

汎用ダイアログボックスでは、ユーザーはアイテムのセットを入力して、それらに近いものをもっと見つけることを求めることができる。例えば、ユーザーは或る照会を入力して、それに近い他の照会を求めることができる。或いは、ユーザーはウェブページ又はサイトへの参照を入力して、それに類似したページをもっとたくさん求めることができる。「比較ｘｙ」というコマンドは、多種多様なｘとｙに関して利用可能である。例えば、ｘとｙは、２つのライバル製品であってもよい。ユーザーは、あらゆる種類の個人的な情報を直接見ることができる。例えば、ディビッドはユーザーの友人又は同僚であると仮定する。そして、例えば「ディビッドの写真」と打ち込めばディビッドの写真が戻され、「ディビッドの誕生日」と打ち込めばディビッドの生年月日が戻されるという具合である。ユーザーは、或る日付又は日付の範囲を指定して、仲間、即ち友人、家族、同僚、又は著名人のグループの中から、誕生日が当該期間に当てはまる者を見つけ出すことができる。

返答が示されたときは何時でも、ユーザーは、元の完全なコンテキストでその返答を目にすることになる（直接、又はリンクに従うことによって）。而して、例えば、或るｅメールを見ると、ユーザーは、それをフル装備のｅメールプログラムのコンテキスト内に示すように求めることができる。

ある種の特徴／機能は、一年のうちの或る特定の時期により顕著に公表される。例えば、税金関連情報は、税金の還付が通例のごとく準備される期間が近づくと、より簡単にアクセス可能にされる。

ゲームも、汎用ダイアログボックスを介して入手可能である。例えば、「パズルをください」であれば、ランダムパズル（ユーザーによる特注仕様化又はユーザーの才能をシステムが前もって知っているために、ちょうど良い難易度のパズル）が現れることになる。同様に、ユーザーはアナグラムや、別の種類のクロスワード解答ヒントを求めることもできる。コンピュータや他のユーザーと単純なゲームをすることもできる。

ユーザーには、何であれ希望する警報を正にネットワーク上に拡張するオプションが与えられている。例えば、警報は汎用ダイアログボックスの横に配置することができ、例えば、主要なニュース速報警報、メール着信警報、オークション進行報告警報などである。ユーザーは、元はそこに無かったリンクをページ上に入力することもできる。ユーザーがそれらのページに移動するたびに、当該リンクが現れる。

ユーザーは、フィードバック、要約記入、見直し記入などを行うのに、汎用ダイアログボックスを使用することができる。例えば、ユーザーはhpに対するメッセージ、「最新のパビリオンは良くない旨をhpに告げよ」と打ち込むことができる。ユーザーはまた、関連／関係のある利害関係者の考え方を介してコンテンツを見ることを選択することもできる。例えば、ユーザーが任意のサイトで或るビジネスを得る方向性を探りたいと望んでいる場合、ビジネスは、当該方向は必ずしも正しいとは言えず、むしろこれこれである旨を指摘することができる。パターンをあらゆる種類の状況に適用できるように作ってもよい。例えば、ユーザーが過去にｅメールをどのように分類したかに基づいて、ｅメールの分類を支援するようにパターンを設定してもよい。ユーザーが読むべきｅメールを受信すると、"move $_ to folder $45"と提案して、デフォルトで、又はユーザーが同意している場合には、その通りのことが起きる。

様々な事前に選択された種類のどれであろうと照会が示される照会チッカーも、休止期間中には汎用ダイアログボックスに現れている。数個の照会チッカーを同時に実行させていてもよい。同様に、スポーツスコアチッカー、株式チッカー、ニュース速報チッカーなどがあるが、これらは全て特定のユーザーに対して独自化されてものである。

翻訳は、汎用ダイアログボックス内でサポートされているもう１つの特徴である。ユーザーは或る言語でテキストを入力又は貼り付けて、選択した言語にそれを翻訳してもらうことができる。

「次」や「これに近いものをもっと」のような演算子は、極端な意味で多形性である。従って、検索結果ページのコンテキストでは、「次」は、ユーザーを同じ照会に対する次の結果のセットに連れて行くことになる。特定の検索結果のコンテキストでは、「次」は、ユーザーを次の結果に連れて行くことになる。同様に、「これに近いものをもっと」は、所与の照会に関係する検索をもっと入手するため、又は所与のサイトに類似しているサイトをもっと入手するなど、のために使用される。

ユーザーは、何か他のオブジェクトを見ているとき、何れのソースからでも充実要素（付加価値）を求めることができる。これは、ユーザーが望ましい様式で情報が流れることを明示的に求めねばならないという１回限りのことではない。そうではなくて、パターンは、或る特定の付加価値がちょうど全ての正しい環境に現れるように、一部には我々の提案に基づいて、ユーザーが設定することができる。これは、例えば、特にビジネス設定では、例えばメーリングリストの特定のｅメールの送信者がどの様な役割又は集団に属しているかを知るのを支援する。単純に組織表情報を送信者のｅメールアドレスに結びつけるだけで、受信者にとって利用価値のある送信者情報が表示されるか、少なくとも直接入手可能になる。ボード上で利用可能となる別の種類の付加価値に、スペルチェックがある。どんな検索ボックスにユーザーが照会を入力しようと、間違いは訂正され、最適な代替案が提示される。

充実要素は、元の情報のフィルタリング及び分類化の形態を取ることができる。例えば、或る会社の従業員の誕生日の長いリストが与えられた場合、ユーザーは、もしいれば、彼らの同僚のだれがそのリストに含まれているかを容易に見つけることができることになる。

ユーザーは、開始時に照会／必要性の全体を特定せねばならないが、一旦システムがユーザーの意思を認識してしまえば、ユーザーからの短いヒントだけで、所望の事柄が起きるのに十分である。同様に、ユーザーにとって最もなじみの深いオブジェクト及び最も頻繁にアクセスを必要とするオブジェクトの場合、コードは最も短く且つ使用するのに最も容易なものになる。本方式は、独自化に基づいているために精密に機能するという事実に注目することが重要である。世界中の全てのユーザーがかつて必要とした全てのものをカバーすることのできる十分に短いコードは有り得ない。

どんな特定のコンテキストにおいても、例えば特定のユーザー及びタスク及び状況によって特定されているコンテキストにおいても、発生する可能性の最も高い必要性を満たす方法が、瞬時にして利用可能になる。例えば、ユーザーが近隣の或る特定の店に興味を示した場合、ユーザーの尋ねそうな質問が予想される。この場合には、最もありそうな質問は、営業時間、電話番号、地図及び方向などであろう。

コード／ラベルの役立つ点として、一部には、どんなコードが存在しており、それらの最新の参照が何であるかを単に見出す際に有用となることが挙げられる。例えば、「先週末にリチャードが見た映画」というラベルの場合、先週末リチャードが映画を見たかどうかによって（異なる）参照がある。例えば、ユーザーは、或るラベルの対象物が存在する時期及びそれがある期間中に変更されたか否かが通知されるように、特定のマップ上に警報を載せることができる。ユーザーは、その瞬間には対象物が存在しなくとも、特定のラベルに関して警報を設定することができる。だれかが（共有可能な）ラベルを、指定されたラベルに一致させて設定すると、直ちに、ユーザーは警報を受信することになる。

ユーザーは、自分のラベル又は他人のラベルに対して注釈を加えてもよい。中には、恐らくこれこれの対象物が、今の時点では、或る参照についてはより良好なマップであることを指摘するユーザーもいる。マップの或る注釈及び特性は、当該マップが使用される時期を制御することができる。特定のマップが多少なりとも役立ちそうな時期を示してもよい。見たい注釈を見るのも、希望する注釈を利用するのも、ユーザー次第である。

コード／マップは、推薦機構を構築する方法も提供している。例えば、特定の職場の同僚の「私の歯科医」マップは、当該地域では誰が良い歯科医であるかを反映している。これは、マップにも注釈が付けられているときに特に役立つ。例えば、同僚は、直近の診療時での「私の歯科医」とのいやな経験について備考を付けることができる。それら備考も活用される。

或る態様では、汎用ダイアログボックスは、ブラウザウインドウの一方の側の細長いウインドウとして実施されている。ユーザーは、自分が見ている行の横に単語又は句の位置を入力するだけで、見ているテキストからの単語及び句を含む照会を入力することができる。例えば、ページの上２７行目の横に、$6:8と入力すると、これは、次の検索が、その行の単語の順序の６番目と８番目の位置の間についてのものであるという意味になる。他のインターフェースを使って同様の機能性をサポートすることもできる。例えば、ユーザーは、浴びせられる照会について、彼らにとって興味のある行の部分を選択してもよい。

マッピングを自分のマップに付加できるようにするため、ユーザーには利口なインターフェースが提供されている。例えば、製品一覧表示内の各製品の横の小さな赤い点に「タッチング」（マウスをオブジェクトの一番上、例えば赤い点、に少しの間持っていく）すると、その製品がマップの一部となる。

人は、ウェブページで読んだ或る表現が非常に気に入ってしまうことがときどきある。人はそれを覚えておきたいと望む。本発明は、ユーザーにその表現をマップとして保持できる機能を提供している。ユーザーは、それを汎用ダイアログボックスに貼り付けるだけでよい。次にその句を探すときに、対応するウェブページが直接入手可能にされ当該句の箇所が強調表示された状態で提示されるように、所望により、コンテキストが自動的に保持される。今日、本の読者は、興味のある表現又は文章に下線を付けたり、強調表示したり、括弧でくくったりすることが多い。本発明は、この種の機能性をより充実させてユーザーに提供している。

アンカーテキストとナビゲーショナル照会は、ある種のオブジェクトに対する既存のマップの例である。本発明は、ユーザーに、このようなオブジェクトに対して自身のラベルを持つ可能性を提供している。ユーザーが好めば、各対象物は保持したまま、ウェブページ上の既存のアンカーテキストをユーザーのラベルで置き換えることができる。

ユーザーは、背景ブラウジング機能を使用することもでき、ここでは、設定されたパターン、プロファイル、及び状況に基づく、ある種のコンテンツがダウンロードされて背景に編成される。例えば、毎朝、列車に乗って職場に出かける前に、一連の新聞から最も関連性がある記事を、ユーザーが職場に携行するラップトップにダウンロードして編成することができる。

ユーザーは、或る参照コードについては対象物の完全な履歴を見るように要求してもよい。例えば、６ヶ月間に亘って「先週末にリチャードが見た映画」の参照を求めることにより、ユーザーは、最近の６ヶ月の間にリチャードの見た映画の完全な一覧を目にすることができる。どんな種類のパターンが与えられても、ユーザーは、それに対応するオブジェクトの一覧が時間又は空間で横断されるように、要求することができる。表示をサポートしているスライドショー機構も装備される。

コードとラベルには、ユーザーにとって数えきれないほどの利点がある。その一つは、コードが幾つかのタイプミスを防止することである。例えば、人々が「ブリットニー・スピアーズ」とタイプするのではなく、これを表している絶対に信頼できるコードを使用すれば、認知負荷がかなり小さくなり間違いもずっと少なくなる。

ラベルは、ネットワークインターフェース又はサーバシステム、例えば、図２に示されているサーバ１６０又は図５に示されているサーバ４６０のような、Yahoo!サーバシステムに記憶されるのが望ましく、そうすると、ユーザーは、コンピュータからコンピュータに、装置から装置に移動して、いつでもネットワークを通してラベルとマッピングにアクセスし、更に全ての利益を得ることができる。

永続的な汎用ダイアログボックスの別の利点は、"&"シェル演算子の等価物を自動的に使用できる可能性である。単調で終りのない要求対応答、要求対応答の連なるユーザーの行為は存在しなくなる。そうではなくて、ユーザーは一度にいくつものコマンドを打ち込むことができ、或いは最初のコマンドが未だ処理されている間に別のコマンドを打ち込むことができる。同様に、システムは幾つかの返答とこれに続くものを一度に提供することができる。応答が複雑な要求に備えている場合には何時も、無論これは完全な元のコンテキストで示される。場合によっては、複雑な照会に対する応答の提示準備ができるまで、ユーザーは幾つか別の場所を通ってナビゲートしてもよい。

汎用ダイアログボックス方式の別の利点は、同一の均一な使い易いインターフェースで各種ツール及びアプリケーションにより、ユーザーに全種類の情報が見えるようになることである。この発想の影響はユーザーに対して、従って、本発明が提供している情報、ツール、及びアプリケーションの使用に対して、非常に能動的である。

或る態様では、作成されたマップは、より効果的な照会分類法、即ち、どの照会又は照会パターンがどんな結果カテゴリを示すのか、又どんな順序で示すのか、を決めるために活用されている。非常に重要な暗示的フィードバックループが出現しつつある。このコンテキストにおいても、集まったパワー、即ち頭脳集団が目に見えるものとなる。例えば、異なるユーザーの一群が照会「ラップトップ」（又は対応する照会パターン）をibm、dell、sony、及びhpにマップしてしまえば、システムは、検索結果としてユーザーに入手可能な（評判又は何かもう少し複雑なものによって順序づけられている）最も人気のあるマッピングを作成することができる。マッピングは、如何に多くの人がそれを作成したかだけでなく、如何に多くの人がそれを使いまたそれを使い続けているか、に基づいて人気があると見なされる。また、マップの設定だけが監視されるのではなく、それらの使用法、参照並びに対象物の使用法も監視される。而して、ブックマークなどとは異なり、本システムではユーザーの意思の把握は、どんなときでもユーザーが本当に興味を持っているのは何かに基づいている。ブックマークファイルを分析するだけであれば、何か致命的なものを見落とすことになる。平均的には、ユーザーは膨大な数のブックマークを持っているが、その殆どは全く使用されないことが観察されている。

ユーザーによっては、打ち込むのは好きだけれども、マウスをリンクに置いてクリックせねばならないのはあまり楽しくないというユーザーもいる。第１の対話の仕方よりも第２の対話の仕方の方が簡単であるというユーザーもいる。本発明は、ユーザーがその時点でユーザーにとって最も役立つ方を選択できるように、両方の選択肢を均等に提供している。

マップ／コードは、或る分野の専門家がどのように考え作業するのかを、初心者が理解できるようにする方法も提供している。参照と、専門家のマップの参照の、両方を見ることにより、特定の分野への洞察を深めることができる。

本発明は、何か、即ちツール及びアプリケーション、がどのように名付けられるかではなく、必要性（ユーザーがどう使うか）によりラベル付けを行う能力を、ユーザーに提供している。例えば、ユーザーの中には、或るものを探すのに何処へ行けばよいかを見出すのに苦労する者もいる。例えば、彼らは、或るものを、イエローページか、マップか、又は何か別のものか、何を使って見つけるのかがよく分からない。本システムは、彼等に対して、必要性を汎用ダイアログボックスに一様なやり方で入力する機会を与えると共に、彼らの必要性を同じ汎用インターフェース内で満たすことにより、縦方向のどんなサービスがどんな機能を提供しているのかを理解し記憶する必要性を省いている。

アンカーテキストのような既存のマップの例は、様々な理由で劣っている。その主な理由の１つは、例えば、アンカーテキストの場合、ウェブコンテンツの作成者が別のオブジェクトへの参照の仕方を決めている。対照的に、本発明が提供する種類のマップでは、各ユーザーが、参照したいものが何であれ希望する参照の仕方を決めることができるようになっている。ショートカットは、必要性を移動体装置に、又は音声で入力するのにも非常に役立つ。ショートカットを使用すれば、普通の照会／必要性を取り扱うやり方も提供することができる。例えば、"w:"コードを用いて天気情報を呼び出すショートカット使用法を活用することにより、本システムは、コンセプトの正しいカテゴリ、この場合には世界の諸都市、を判定することができる。本システムは、コンセプト及び照会の益々効果的になった分類化を利用して、ユーザーにより関連性の深いコンテンツを、例えばIYなどから提供することができる。

コードは、デフォルトで、コンテキストに敏感であるのが望ましい。従って、コンテキストが適切に曖昧さを排除すれば、$3は第３の検索エンジン又は第３のレストランを参照することができる。

オブジェクト指向方式は、本システムの一体となった一部分である。多様性は広範囲に（プログラム言語のように）採用されている。例えば、同じシンボルが、コンテキスト次第でそれぞれ別々のものを表現することができる。継承性は、本発明の別の態様である。コードブックは継承される。コードが、ユーザーのコードブックを使って解読できない場合は、所属している集団のコードブックがデフォルトで使用される。

どんな特定のユーザーにも、任意の数のマッピングがサポートされている。勿論、どれほど多くのマッピングがあろうと、小さいサブセットのマッピングしか頻繁には使用されないので、それらがキャッシュされる。

或る態様では、マップ自体がファーストクラスのオブジェクトである。ユーザーは、マップを作成して、誰か他の人に提案として転送されるように要求することができる。例えば、関心のある母親は、学校にいる息子のために、学業、栄養、等々のためにマップを作ってやってもよい。マップは、集団に、そして特定のユーザーへの両方において、ユーザーをブラウジング可能にもする自身の存在論も有している。

デフォルトでサーバに記憶され、従ってどこからでも利用可能にされてはいるが、コードブックの複製版を、効率と性能面から、エッジ付近又はユーザーのデスクトップに記憶させてもよい。

ユーザーには、機会ある毎に、マッピングを構築するためのオプションが積極的に与えられるのが望ましい。例えば、特定のユーザーが"hp"を照会して、www.hp.comに連れて行ってくれる検索結果のリンクをクリックした、とシステムが（１回、２回、又は３回）判定した場合、システムは、ユーザーに照会"hp"からwww.hp.comまでのマップを作るオプションを提案することができる。ユーザーが同意を与えると、マップが作成される。システムが、パターンを活用したショートカットの利用により簡素化される可能性がある規則的な挙動パターンを発見した場合は、その状況に対して、同様の方式が適用される。

或る態様では、汎用ダイアログボックスは、プロバイダ、更にはウェブ全体が提供している全てのサービスに対して、ユーザーに一点入力を提供している。汎用ダイアログボックスの１つの捉え方は、ユーザーが何をしていようと、開いて活動している状態のユーザーとの通信チャネルをこのダイアログボックスが提供しているという見方である。ダイアログは、もはや単なるユーザー要求、プロバイダ返答、第２のユーザー要求、第２のプロバイダ返答パターンであるに留まらない。そうではなく、プロバイダは主導権を取り、ユーザーに何かに興味を持ってもらうために筋が通る場合には何時でもという意味で、かなり的を絞ったプロモーションなどを提供することができる。同様に、システムは、全種類のマップを構築する機会をユーザーに積極的に提供する。割増料金付検索サービスも有料で提供され、そのうちの幾つかの特徴は、ここに説明しているショートカット方式から引き出すことができる。

マップは、セッションからオブジェクトに対してであってもよい。例えば、ユーザーは、ブラウジングセッションの間に、或るカテゴリで或る興味深い製品を発見しているかもしれない。後で、ユーザーはその興味深い製品だけをパートナーに見せたいと思う。各オブジェクト／製品のそばに、オプションを提供することができる。どんな広告／プロモーションについても同様である。汎用ダイアログボックスでは、ユーザーは、将来必要になるであろう必要性を入力することができる。この発想には、ビジネス的に大きな可能性がある。ユーザーは、今春ヨーロッパに旅行するであろうという必要性を表明することができる。システムは、上記必要性を見失わないようにすると共に、これら必要性を満たそうと務める。例えば、ユーザーは、彼らの知り合いの誰かが今から二日後に搭乗する航空便を監視することを要求することができる。

ユーザーに付随する永続的なダイアログも、システムが、特徴、機能性、及びコンテンツを積極的に強調表示し、これにより独自のコンテンツ、及びツールとアプリケーションの強力なセットの公開を増やし、大規模な特性のセットに亘って広がるようにする機会を提供する。プロモーションは、新聞のある種の広告のように、時間経過に伴って構築されてゆき、毎日人々の好奇心をそそり、その週の終りになって初めてそれらが一体何についてであったのかが明かされるような様式で実行されるものもある。

図７と図８は、本願に記載の本発明のＵＤＢインターフェースシステムと方法論とによって提供される機能性の例を示している。具体的には、図７は、ユーザーが事前に定義されたコード又はラベルをＵＤＢ５００へ入力したのに応じて、ユーザーシステムに提供されるウェブページを示している。例えば、図６で、ユーザーがコード「！旅行」を入力すると、システムは、システム内、例えばサーバ１６０又は他のサーバシステムに記憶されているか、又はクライアントシステム内に記憶されているマッピングにアクセスし、入力されたコードが、Yahoo!により提供される「旅行」ページにマップしていると判断する。ネットワークの要求、例えばＨＴＴＰの要求は、旅行サイトにアクセスするために（クライアントシステム又はマッピング表にアクセスしたサーバからの何れかから）Yahoo!に送られ、それに応えて図７に示す旅行ページが（例えば、ＨＴＭＬを使って）ユーザーに送られる。提供されるページには、ＵＤＢ５００も目立つように表示されている。図８は、ユーザーが別の事前に定義されたコード又はラベルをＵＤＢ５００へ入力したのに応じて、ユーザーシステムに提供されるウェブページを示している。この場合、図７で、ユーザーは「（引数）定義」と入力しており、ここでいう引数とは定義の対象であるテキスト用語である。本事例では、テキスト引数は「量」である。システムは、システム内に、例えばサーバ１６０又は他のサーバシステムに記憶されているか、又はクライアントシステム内に記憶されているマッピングにアクセスして、入力されたコードは、引数に対する辞書定義が提供されるべきであることを識別している、と判断する。システムは、辞書定義を見つけ出して、それをユーザーに別のウェブページとして提供する。この例では、システムは、引数の検索を行い、その結果を定義の下に図示のように提示することも行う。

或る態様では、本発明のラベル、コード、パラメータ、及びその他のマッピングも検索可能である。また、ラベルに対する参照並びにラベルがマップしているものに対する参照も検索される。例えば、ラベル名は検索可能であり、ラベル参照も検索可能である。或る態様では、ラベルの存在論的階層が提供され、そこでラベルはネットワーク上のノードに割り当てられる。一つの例がYahoo!ディレクトリにあり、ここでは様々なノードが異なるトピックを表している。この場合、ユーザーは、ネットワーク内の各種ノードに亘ってこれらラベルを通してナビゲートする。

以上、本発明を、特定の実施形態を例として参照しながら説明してきたが、本発明はこれら開示した実施形態に限定されるものではない。反対に、当業者には自明のように、各種変更及び類似した装置も対象に入るものとする。従って、特許請求の範囲の内容は、そのような変更及び類似の装置を範囲に含めるよう、然るべく広義に解釈されるべきものとする。

Claims (40)

1. クライアントシステム内で、ユーザー入力を処理して、前記ユーザー入力のコンテンツに基づいて取るべき動作を判定する、コンピュータが実施する方法において、
   前記クライアントシステムに関係付けられたグラフィカルユーザーインターフェース表示上にダイアログボックスを表示する段階と、
   ユーザー入力をダイアログボックスに受け取る段階と、
   前記ユーザー入力のコンテンツを処理して、前記ユーザー入力のコンテンツに基づいて取るべき動作を判定する段階と、から成り、前記動作には、前記ユーザー入力を検索照会として使用しながら検索を行うことと、前記クライアントシステム上に駐在している１つ又は複数のアプリケーションにアクセスして前記コンテンツに基づいて更なる処理を行うこと、の一方が含まれていることを特徴とする方法。
2. 前記コンテンツは、特定のアプリケーションに対してマップしているユーザー定義によるラベルを含んでいることを特徴とする、請求項１に記載の方法。
3. 前記特定のアプリケーションは、ｅメールクライアント、インスタントメッセージクライアント、データベース管理クライアント、ドキュメント管理クライアント、カレンダークライアント、ブラウザクライアント、表計算クライアント、及びファイル転送クライアント、からなる群より選択されることを特徴とする、請求項１に記載の方法。
4. 前記ラベルは、前記ラベルを前記特定のアプリケーションにマップするマッピング表に記憶され、前記処理は、前記ラベルを前記特定のアプリケーションを識別するためのキーとして使用しながら前記マッピング表にアクセスする段階を含んでいることを特徴とする、請求項１に記載の方法。
5. 前記処理は、前記特定のアプリケーションを呼び出して前記コンテンツを更に処理する段階を含んでいることを特徴とする、請求項４に記載の方法。
6. 前記コンテンツは、複数の特定アプリケーションにマップするユーザー定義によるラベルを含んでいる、請求項１に記載の方法。
7. 前記複数の特定のアプリケーションは、ｅメールクライアント、インスタントメッセージクライアント、データベース管理クライアント、ドキュメント管理クライアント、カレンダークライアント、ブラウザクライアント、表計算クライアント、及びファイル転送クライアント、からなる群より選択された少なくとも１つのアプリケーションを含んでいることを特徴とする、請求項６に記載の方法。
8. 前記コンテンツは、特定の必要性を表す自然言語ラベルを含んでおり、前記自然言語ラベルは、前記コンピュータ上又は前記コンピュータに接続されているネットワーク上に駐在している１つ又は複数のアプリケーションにマップしていることを特徴とする、請求項１に記載の方法。
9. 前記検索を実行する段階は、前記クライアントシステム上にブラウザクライアントを呼び出す段階と、前記検索照会を遠隔サーバに送る段階と、を含んでいることを特徴とする、請求項１に記載の方法。
10. 前記ユーザー入力のコンテンツは、前記ユーザー入力のフォーマットに基づいて判定され、前記取るべき動作を判定する段階は前記コンテンツに基づくことを特徴とする、請求項１に記載の方法。
11. 前記ユーザー入力は、前記クライアントシステムに関係付けられた１つ又は複数のユーザー入力装置を介して受け取られることを特徴とする、請求項１に記載の方法。
12. コードブックを遠隔システムから受け取る段階であって、前記コードブックには１つ又は複数のラベルと１つ又は複数の特定アプリケーションとのマッピングが含まれており、前記コードブックラベルは別のユーザーにより定義されたものである、段階と、
    前記コードブックを前記クライアントシステムのメモリ装置に記憶する段階と、を更に含んでいることを特徴とする、請求項１に記載の方法。
13. 前期処理する段階は、前記ユーザー入力内の１つ又は複数のラベルを識別する段階を含んでおり、前記１つ又は複数のアプリケーションにアクセスする段階は、前記コードブックを使用して前記１つ又は複数のアプリケーションを識別する段階を含んでいることを特徴とする、請求項１２に記載の方法。
14. 前記１つ又は複数のアプリケーションを識別する段階は、前記１つ又は複数のラベルを、前記コードブック内の前記１つ又は複数のアプリケーションを調べるためのキーとして使用する段階を含んでいる、請求項１３に記載の方法。
15. 前記１つ又は複数のアプリケーションにアクセスする段階は、前記１つ又は複数のアプリケーションとインターフェースするように構成されている１つ又は複数のＡＰＩを実行する段階と、前記１つ又は複数のアプリケーションとインターフェースするように構成されている１つ又は複数のスクリプトを実行する段階、の内の一方を含んでいることを特徴とする、請求項１に記載の方法。
16. 複数のクライアントシステムの間で動作可能なラベルを共有する方法において、
    第１クライアントシステム上で第１ラベルを作成する段階であって、前記ラベルは、前記第１クライアントシステム上で実行可能な少なくとも１つの特定のアプリケーションへのマッピングを含んでいる、第１ラベルを作成する段階と、
    前記ラベルを第２クライアントシステムにネットワークを通して転送する段階と、
    前記第１ラベルを、前記第２クライアントシステムのメモリ装置に記憶する段階と、
    ユーザー入力を前記第２クライアントシステム上で処理し、前記ユーザー入力が前記第１ラベルを識別した場合は、
    前記少なくとも１つの特定のアプリケーションを前記第２システム上に呼び出す段階と、
    前記ユーザー入力を前記少なくとも１つの特定のアプリケーションを使用して処理する段階と、を含んでいることを特徴とする方法。
17. 前記少なくとも１つの特定のアプリケーションは、ｅメールクライアント、インスタントメッセージクライアント、データベース管理クライアント、ドキュメント管理クライアント、カレンダークライアント、ブラウザクライアント、表計算クライアント、及びファイル転送クライアント、からなる群より選択されることを特徴とする、請求項１６に記載の方法。
18. 前記第１ラベルは、構造化データ型式、非構造化データ型式、テキスト、数、画像、及びデータベース記録、からなる群より選択された複数のデータ型式の何れをも参照することを特徴とする、請求項１６に記載の方法。
19. 前記ラベルは、それぞれクライアントシステム上で実行可能な特定のアプリケーションを識別する１つ又は複数の追加的ラベルを含んでいるコードブック内で、前記第２クライアントシステムに転送されることを特徴とする、請求項１６に記載の方法。
20. 前記第１ラベルは、自然言語フォーマットであることを特徴とする、請求項１６に記載の方法。
21. 前記ラベルは、遠隔サーバのウェブサイトを識別し、前記ラベルはブラウザアプリケーションにマップすることを特徴とする、請求項２０に記載の方法。
22. 前記少なくとも１つのアプリケーションは、ブラウザアプリケーションであり、前記処理する段階は、前記ユーザー入力を使用して検索を行う段階を含んでいることを特徴とする、請求項１６に記載の方法。
23. 前記検索を行う段階は、検索照会を遠隔システムに送る段階を含んでおり、前記遠隔検索システムは、前記ユーザー入力と前記第１ラベルに基づいて検索結果を提供することを特徴とする、請求項２２に記載の方法。
24. 前記第１ラベルは、第１の対象物を識別し、前記方法は、ユーザーに要求に応じて、前記第１対象物を前記第２クライアントシステムの第２の対象物に変更する段階を更に含んでいることを特徴とする、請求項１６に記載の方法。
25. 前記呼び出す段階は、ブラウザアプリケーションを呼び出す段階を含んでおり、前記処理する段階は、前記第２対象物を使用して遠隔システムにアクセスする段階を含んでいることを特徴とする、請求項２４に記載の方法。
26. 前記第２対象物は、ＵＲＬと、遠隔サイトに対するリンク、の内の一方を含んでいることを特徴とする、請求項２５に記載の方法。
27. 前記処理する段階は、前記第１ラベルに基づいて遠隔サイトからの情報を、読み出すか、又は要求する、の内の一方を含んでいることを特徴とする、請求項１６に記載の方法。
28. 届けられるべき情報のコンテキストに基づいて、ユーザーに情報を届けるための配達アプリケーションを選択する段階を更に含んでいることを特徴とする、請求項２７に記載の方法。
29. 前記配達アプリケーションは、メールアプリケーション、インスタントメッセージアプリケーション、及びブラウザアプリケーションの内の１つを含んでいることを特徴とする、請求項２８に記載の方法。
30. 前記第１ラベルは、第１の名前を含んでおり、前記方法は、ユーザーの要求に応じて、前記第１の名前を前記第２クライアントシステムの第２の名前に変更する段階を更に含んでいることを特徴とする、請求項１６に記載の方法。
31. 前記第１ラベルは、第１対象物を識別し、前記方法は、ユーザーの要求に応じて、前記第１対象物を前記第２クライアントシステムの第２対象物に変更する段階を更に含んでいることを特徴とする、請求項３０に記載の方法。
32. 前記取るべき動作は、届けられるべき情報のコンテキストに基づいて、ユーザーに情報を届ける段階を含んでいることを特徴とする、請求項１に記載の方法。
33. 前記情報を届ける段階は、メールアプリケーション、インスタントメッセージアプリケーション、及びブラウザアプリケーションの内の１つを使用して前記情報を提供する段階を含んでいることを特徴とする、請求項３２に記載の方法。
34. 前記ユーザー入力は、複数の別々のエントリを含んでおり、前記ユーザー入力のコンテンツを処理する段階は、各エントリのコンテンツを別個に処理する段階を含んでいることを特徴とする、請求項１に記載の方法。
35. 各エントリ毎に、前記方法は、取るべき動作を判定する段階を含んでおり、各動作は、前記エントリのコンテンツに基づいて決められることを特徴とする、請求項３４に記載の方法。
36. 前記動作は、前記ユーザー入力を検索照会として使用して検索を行う段階を含んでおり、前記検索は、１つ又は複数の検索結果を提供し、前記方法は、前記検索結果の１つに関係付けられた遠隔サイトとの通信リンクを確立する段階を更に含んでいることを特徴とする、請求項１に記載の方法。
37. 前記遠隔サイトから追加的情報を受信する段階と、前記追加的情報と前記検索結果を前記クライアントシステムに提供する段階と、を更に含んでいることを特徴とする、請求項３６に記載の方法。
38. 前記取るべき動作は、前記アプリケーションの２つ又はそれ以上にアクセスする段階と、前記２つ又はそれ以上のアプリケーションそれぞれからの情報を表示する段階と、を含んでいることを特徴とする、請求項１に記載の方法。
39. 前記処理する段階は、第１アプリケーションにアクセスする段階を含んでおり、以降の処理段階は、前記コンテンツに基づいて第２アプリケーションにアクセスする段階を含んでいることを特徴とする、請求項１に記載の方法。
40. 前記第１アプリケーションは、ｅメールクライアントであり、前記第２アプリケーションは、表計算クライアント、カレンダークライアント、及びブラウザクライアント、の内の１つであることを特徴とする、請求項３９に記載の方法。

Images