"情報をユーザに送る方法であって、コンピュータプログラムによって実行されるa電子カレンダにおいて特定される来るべきイベントに関連する情報であってメモリに記憶された情報から、当該来るべきイベントを記述する複数の用語を検索する段階250,320であって、前記複数の用語を検索する段階は前記電子カレンダから前記来るべきイベントを記述する複数の用語を抽出することを含んでいる段階と、bコンピュータプロセッサを使って、前記来るべきイベントを記述する複数の用語のうちの少なくとも1つに依存して、利用可能な複数の情報源から少なくとも1つの情報源を選択する段階であって、前記少なくとも1つの情報源の数は、前記複数の利用可能な情報源の全てよりも少ない数である段階と、c前記コンピュータプロセッサを使って、前記少なくとも1つの情報源のどれが複数の情報源から選択されたかに基づいて、複数の問い合わせ生成アルゴリズムの中から1つの問い合わせ生成アルゴリズムを選択する段階と、d前記コンピュータプロセッサを使って、前記選択された1つの問い合わせ生成アルゴリズムを実行して前記用語に基づいた問い合わせ生成する段階であって、異なる問い合わせは、複数の問い合わせ生成アルゴリズムのどれが選択され実行されたかに基づいて生成される段階と、e前記コンピュータプロセッサを使って、前記問い合わせを使って前記少なくとも1つの情報源に問い合わせて、来るべきイベントのための問い合わせ情報を生成する段階と270,275、fディスプレイ装置を介して前記問い合わせ情報の少なくとも一部をユーザに送る段階であって、前記問い合わせ情報は前記イベントよりも予め決められた時間だけ前に生成されるものである段階と、を含むことを特徴とする、情報をユーザに送る方法。前記問い合わせを作成するために、所定の基準に基づいて前記用語を構文解析する段階を含むことを特徴とする、請求項1に記載の情報をユーザに送る方法。現在のユーザの入力に基づいてシステムをダイナミックに構成するために、システムに利用される定数を提供する段階を含むことを特徴とする、請求項1に記載の情報をユーザに送る方法。ミーティング規準のとの関連性に基づいて問い合わせの結果をランク付けする段階を含むことを特徴とする、請求項1に記載の情報をユーザに送る方法。さらに、前記コンピュータプロセッサを使って前記来るべきイベントに関連した情報を問い合わせ情報で更新する段階であって、当該更新には、情報の要約が以前に生成されているときは前記問い合わせ情報を前記情報の要約に追加し、情報の要約がまだ生成されていないときは情報の要約を作成することが含まれ、前記情報の要約はイベントに先って確立又は更新されている、請求項1に記載の情報をユーザに送る方法。前記来るべきイベントに関連した情報を問い合わせからの情報で更新することは、ミーティング日付の近傍を、情報の要約のためのフィルター装置として利用することを特徴とする、請求項5に記載の情報をユーザに送る方法。前記問い合わせには、関連情報を入手するためにインターネットに問い合わせすることが含まれる、請求項1に記載の情報をユーザに送る方法。前記問い合わせには、さらに、特定のサーチエンジンに対する問い合わせを最適化することが含まれる、請求項7に記載の情報をユーザに送る方法。aプロセッサ110と、bディスプレイ装置138と、c前記プロセッサ110の制御の下に情報を記憶するメモリ114とを含み、前記プロセッサは、d電子カレンダにおいて特定される来るべきイベントを記述する複数の用語を検索し250,320、ここで前記複数の用語の検索には、前記電子カレンダから来るべきイベントを記述する複数の用語を抽出することが含まれ、e前記来るべきイベントを記述する複数の検索された用語のうちの少なくとも1つに依存して、利用可能な複数の情報源から少なくとも1つの情報源選択し、ここで、前記少なくとも1つの情報源の数は、前記複数の利用可能な情報源の全てよりも少ない数であり、f前記コンピュータプロセッサを使って、前記少なくとも1つの情報源のどれが複数の情報源から選択されたかに基づいて、複数の問い合わせ生成アルゴリズムの中から1つの問い合わせ生成アルゴリズムを選択し、g少なくとも1つのプロセッサを使って、前記選択された1つの問い合わせ生成アルゴリズムを実行して前記用語に基づいた問い合わせ生成し、ここで異なる問い合わせは、複数の問い合わせ生成アルゴリズムのどれが選択され実行されたかに基づいて生成され、h前記コンピュータプロセッサを使って、前記問い合わせを使って前記少なくとも1つの情報源に問い合わせて、来るべきイベントのための問い合わせ情報を生成し270,275、iディスプレイ装置を介して前記問い合わせ情報の少なくとも一部をユーザに送り、ここで前記問い合わせ情報は前記イベントよりも予め決められた時間だけ前に生成される、ことを特徴とする、情報をユーザに送る装置。前記プロセッサは、さらに、前記来るべきイベントに関連した情報を問い合わせ情報で更新し、当該更新には、情報の要約が以前に生成されているときは前記問い合わせ情報を情報の要約に追加し、情報の要約がまだ生成されていないときは情報の要約を作成することが含まれ、前記情報の要約はイベントに先って確立又は更新されている、請求項9に記載の装置。情報をユーザに送るためのコンピュータプログラムが記録されたコンピュータ読み取り可能な記録媒体であって、前記コンピュータプログラムは、a電子カレンダにおいて特定される来るべきイベントに関連する情報から当該来るべきイベントを記述する複数の用語を検索するコードセグメントと250,320、ここで、前記複数の用語を検索するコードセグメントは、前記前記電子カレンダから前記来るべきイベントを記述する複数の用語を抽出することを含んでおり、b前記来るべきイベントを記述する複数の検索された用語のうちの少なくとも1つに依存して、利用可能な複数の情報源から少なくとも1つの情報源を選択するコードセグメントと、ここで、前記少なくとも1つの情報源数は、前記複数の利用可能な情報源の全てよりも少ない数であり、c前記コンピュータプロセッサを使って、前記少なくとも1つの情報源のどれが複数の情報源から選択されたかに基づいて、複数の問い合わせ生成アルゴリズムの中から1つの問い合わせ生成アルゴリズムを選択するコードセグメントと、d少なくとも1つのプロセッサを使って、前記選択された1つの問い合わせ生成アルゴリズムを実行して前記用語に基づいた問い合わせ生成するコードセグメントと、ここで異なる問い合わせは、複数の問い合わせ生成アルゴリズムのどれが選択され実行されたかに基づいて生成され、e前記コンピュータプロセッサを使って、前記問い合わせを使って前記少なくとも1つの情報源に問い合わせて、来るべきイベントのための問い合わせ情報を生成するコードセグメントと270,275、fディスプレイ装置を介して前記問い合わせ情報の少なくとも一部をユーザに送るコードセグメントと、ここで前記問い合わせ情報は前記イベントよりも予め決められた時間だけ前に生成される、を含むものである、コンピュータ読み取り可能な記録媒体。前記コンピュータプログラムは、前記問い合わせを作成するために、所定の基準に基づいて前記用語を構文解析するコードセグメントを含んでいる、請求項11に記載のコンピュータ読み取り可能な記録媒体。前記コンピュータプログラムは、現在のユーザの入力に基づいてシステムをダイナミックに構成するために、システムに利用される定数を修正するコードセグメントを含んでいる、請求項11に記載のコンピュータ読み取り可能な記録媒体。前記コンピュータプログラムは、ミーティング規準との関連性に基づいて問い合わせの結果をランク付けするコードセグメントを含んでいる、請求項11に記載のコンピュータ読み取り可能な記録媒体。前記コンピュータプログラムは、さらに、前記来るべきイベントに関連した情報を問い合わせ情報で更新し、当該更新には、情報の要約が以前に生成されているときは前記問い合わせ情報を情報の要約に追加し、情報の要約がまだ生成されていないときは情報の要約を作成するコードセグメントを含み、前記情報の要約はイベントに先って確立又は更新されている、請求項11に記載のコンピュータ読み取り可能な記録媒体。前記コンピュータプログラムは、ミーティング日付の近傍を、情報の要約のためのフィルター装置として利用するコードセグメントを含んでいる、請求項11に記載のコンピュータ読み取り可能な記録媒体。関連情報を入手するために、インターネットに問い合わせするコードセグメントを含んでいる、請求項11に記載のコンピュータ読み取り可能な記録媒体。特定のサーチエンジンに対する問い合わせを最適化するコードセグメントを含んでいる、請求項17に記載のコンピュータ読み取り可能な記録媒体。ミーティング情報の更新に応えて、前記更新に関連する追加要約情報を入手するコードセグメントを含んでいる、請求項15に記載のコンピュータ読み取り可能な記録媒体。本発明の好適な実施例の包括的な態様によれば、エージェントベースのシステムは、個人が各種ソースからミーティングについての関連情報を検索するのを助けることにより、彼/彼女が来るべきミーティングに備えることを支援する。システムは、ミーティングの日時を含んでいるカレンダプログラムから、目標ミーティングを表示する文字形式の入力テキストを入手する。ミーティングの日時が近づくと、カレンダプログラムは目標イベントのテキストを入手するために問い合わせを受け、その情報はエージェントシステムへの入力として利用される。そして、エージェントシステムは入力されたミーティングテキストを構文解析し、題目、本体、参加者、場所、時間などの各種要素を抽出する。システムは又、パターンマッチングを行って、ミーティングテキスト内の特定のミーティングフィールドを識別する。この情報を使ってウェブ上で各種情報源に問い合わせを行ない、そのミーティングについての関連記事を入手して、それをカレンダリングシステムに送り返す。例えば、ある個人が争議につき討論するためにネットスケープ及びマイクロソフトとミーティングを持つ場合、システムはこの最初の情報をカレンダリングシステムから入手する。システムは次にテキストを構文解析してミーティングの会社がネットスケープとマイクロソフトであり、議題が争議であると理解する。システムはここでこの議題に関する関連情報を求めてウェブをサーフィンする。このように、本発明の目的によれば、システムは目標ミーティングに備えて収集し得る最良の情報でカレンダリングシステムを更新し、結果としてユーザーにもそれら情報を与えることになる。好適な実施例によれば、情報はカレンダシステムに内蔵されたリンクからの選択を介して得られるファイルに記憶される。上記及び他の目的、態様、及び利点は、図面を参照しながら、以下の本発明の好適な実施例の詳細な説明をお読みになれば明確に理解いただけるであろう。本発明による好適な実施例は、IBM互換パーソナルコンピュータ、アップルマッキントッシュコンピュータ、又はUNIXベースのワークステーション等のパーソナルコンピュータと関連付けて実用化されるのが好ましい。代表的なハードウェア環境を図1に示しているが、この図には、マイクロプロセッサのような中央演算処理装置110と、システムバス112を介して相互に接続されている他の多数の装置とを有する好適な実施例によるワークステーションの典型的なハードウェア構成を示している。図1に示すワークステーションは、ランダムアクセスメモリRAM114、読み出し専用メモリROM116、ディスク記憶装置120のような周辺機器をバス112に接続するためのI/Oアダプタ118、キーボード124、マウス126、スピーカ128、マイクロフォン132、及び/又はタッチスクリーン図示せずのような他のユーザーインターフェース機器をバス112に接続するためのユーザーインターフェースアダプタ122、ワークステーションを通信ネットワーク例、データプロセシングネットワークに接続するための通信アダプタ134、及びバス112をディスプレイ装置138に接続するためのディスプレイアダプタ136を含んでいる。ワークステーションには、通常、マイクロソフトウィンドウズNT又はウィンドウズ/95オペレーティングシステム、IBMOS/2オペレーティングシステム、MACOS、又はUNIXオペレーティングシステムのようなオペレーティングシステムOSが常駐している。本発明が、上記以外のプラットフォームやオペレーティングシステムにもインプリメントできることは当業者には自明であろう。好適な実施例は、Java、C、及びC言語を使って書かれ、オブジェクト指向プログラミング技法を用いている。オブジェクト指向プログラミングOOPは、複雑なアプリケーションを開発するために益々広汎に使用されるようになってきている。OOPがソフトウェア設計と開発の主流となるにつれ、各種ソフトウェアソリューションにはOOPの有益性を利用するために適合化が必要となってきた。OOPのこれら原理を電子メッセージングシステムのメッセージングインターフェースに適用して、メッセージングインターフェース用のOOPクラスとオブジェクトのセットを提供できるようにする必要が生じている。OOPはオブジェクトを使ってコンピュータソフトウェアを開発するプロセスであり、問題を分析する段階、システムを設計する段階、及びプログラムを構築する段階を含んでいる。オブジェクトは、データ及び関連構造と手続きの集合体の両方を保有しているソフトウェアパッケージである。データ及び関連構造と手続きの集合体の両方を保有しているので、オブジェクトは特定タスクを行なうために他に追加の構造体、手続き、又はデータを必要としない自己充実型コンポーネントとして見ることができる。OOPは、従ってコンピュータプログラムを広い範囲で独立したコンポーネントの集合体、即ちオブジェクトと捉えるが、その各々は特定のタスクに責任を持っている。データ、構造、及び手続きを1つのコンポーネント又はモジュールにまとめるパッケージングというコンセプトはカプセル化と呼ばれている。一般的に、OOPコンポーネントは、オブジェクトモデルに合わせたインターフェースを表しコンポーネント統合アーキテクチャを介してランタイムでアクセスされる再使用可能なソフトウェアモジュールである。コンポーネント統合アーキテクチャは、異なるプロセススペースのソフトウェアモジュールが互いの能力又は機能を使えるようにするアーキテクチャ機構のセットである。これは一般的に、共通コンポーネントオブジェクトモデル上にアーキテクチャが構築されると想定することにより行われる。この点でオブジェクトとオブジェクトのクラスを区別することに意味がある。1つのオブジェクトは複数のオブジェクトから成るクラスの1つのインスタンスであるが、単にクラスとだけ呼ばれることもある。複数のオブジェクトから成るクラスは、そこから多数のオブジェクトが形成されることになる青写真と捉えることができる。OOPは、プログラマが別のオブジェクトの一部であるオブジェクトを製作できるようにする。例えば、ピストンエンジンを表すオブジェクトは、ピストンを表しているオブジェクトと合成関係を持つと言われる。現実には、ピストンエンジンはピストン、バルブ、及び他にも多数の構成要素を備えているが、ピストンはピストンエンジンの一要素であるという事実は論理的であると言えるし、OOPでは意味論上2つのオブジェクトにより表現される。OOPは又、他のオブジェクトから垂れ下がっているオブジェクトを製作できるようにもしている。仮に2つのオブジェクトがあり、一方はピストンエンジンを表現し他方はピストンがセラミック製であるピストンエンジンを表現しているとすると、この2つのオブジェクトの関係は合成の関係とは言えない。セラミックのピストンエンジンがピストンエンジンを構成するわけではない。むしろそれは単に一種のピストンエンジンのことであり、そのピストンはセラミック製であるという、ピストンエンジンということ以外のもう1つ別の限定を有している。この場合、セラミック製のピストンエンジンを表現しているオブジェクトは派生オブジェクトと呼ばれ、ピストンエンジンを表現しているオブジェクトの態様を全て継承しそれに更なる限定又は詳細を追加している。セラミック製ピストンエンジンを表現しているオブジェクトはピストンエンジンを表現しているオブジェクトから垂れ下っているわけである。これらオブジェクトの間の関係は継承と呼ばれる。セラミック製ピストンエンジンを表現しているオブジェクト又はクラスがピストンエンジンを表現しているオブジェクトの態様の全てを継承している場合、それはピストンエンジンクラスに定義されている標準ピストンの熱特性を継承している。しかしながら、セラミック製ピストンエンジンオブジェクトは、金属ピストンに関係する熱特性とは典型的に異なるこれらセラミックに特定した熱特性をオーバーライドする。それは元のものを抜かし、セラミックピストンに関係する新しい機能を用いる。別種のピストンエンジンは別の特性を有するが、それに付帯する同じ下層機能例、エンジン内のピストンの数、点火シーケンサ、給油などを有することになる。どのピストンエンジンオブジェクトであれこれら機能のそれぞれにアクセスするには、プログラマは同一名を持つ同一機能を呼び出すことになるが、各タイプのピストンエンジンは異なる/オーバーライドする機能のインプリメンテーションを同一名の裏に有することになる。ある機能の別のインプリメンテーションを同一名の裏に隠すというこの能力は多相性と呼ばれ、これによりオブジェクト間の通信は大幅に簡素化される。合成関係、カプセル化、継承、及び多相性というコンセプトを用いると、1つのオブジェクトで現実世界の何もかもについて表現ができる。実際には、我々が感じる現実性の論理的認識は、オブジェクト指向型ソフトウェアのオブジェクトになり得る物の種類を判断する上での限定にすぎない。典型的なカテゴリーの幾つかを以下に示す。オブジェクトは、交通流シミュレーション内の自動車、回路設計プログラム内の電気的コンポーネント、経済学モデル内の国々、又は航空管制システム内の航空機のような物理的オブジェクトを表現できる。オブジェクトは、ウインドウズ、メニュー、又はグラフィックオブジェクトのようなコンピュータユーザー環境のエレメントを表現できる。あるオブジェクトは、職員ファイル又は都市の緯度及び経度を示す表などの目録を表現できる。あるオブジェクトは、時刻、角度、複素数、又は平面上の点などユーザーが定義したデータタイプを表現できる。1つのオブジェクトが論理上分離可能なあらゆる物について表現するという非常に大きな能力を備えることにより、OOPは、現実が物理的エンティティ、プロセス、システム、或いは複合物の何れであろうと、ソフトウェア開発者が現実のある態様のモデルであるコンピュータプログラムを設計しインプリメントできるようにする。オブジェクトは何でも表現できるので、ソフトウェア開発者は将来的に大型ソフトウェアプロジェクトのコンポーネントとして使えるオブジェクトを製作できる。新しいOOPソフトウェアプログラムの90が、前もって存在している再使用可能なオブジェクトから作られた証明済みの現存コンポーネントから成るのであれば、残り10分の新しいソフトウェアプロジェクトを書き、スクラッチからテストを行なえばよいだけになる。既に90は広範にテストされた再使用可能なオブジェクトの目録から来ているので、エラーの元となる可能性のあるドメインはプログラムの10ということになる。結果として、OOPは、ソフトウェア開発者が他の即ち以前に構築されたオブジェクトからオブジェクトを構築できるようにする。このプロセスは、アッセンブリ及びサブアッセンブリから構築されている複合機械に近似している。OOP技術は、従って、ソフトウェアが開発者にとってオブジェクトとして利用可能な現行コンポーネントから構築される点において、ソフトウェアエンジニアリングをハードウェアエンジニアリングにより近づけるものである。これが全体としてソフトウェアの品質を向上させると同時にその開発の速度を上げることになる。プログラミング言語は、カプセル化、継承、多相性、及び合成関係のようなOOP原理の完全なサポートを開始しつつある。C言語の出現により、多数の市販ソフトウェア開発者はOOPを歓迎している。Cは迅速且つ機械が実行可能なコードを提供するOOP言語である。更に、Cは市販アプリケーションとシステムプログラミングプロジェクトの双方に適している。今や、Cは数多くのOOPプログラマの間で最も人気のある選定ということになるが、Smalltalk、CommonLispObjectSystemCLOS及びEiffelのように、他にもOOP言語のホストが存在する。加えて、OOP能力はPascalのようなより伝統的で大衆的なコンピュータプログラミング言語に付加されてきている。オブジェクトクラスの有益性を要約すると以下の通りである。オブジェクト及びそれらに対応しているクラスは、複雑なプログラミング問題を砕いて多数のより小さく且つより単純な問題にする。カプセル化は、強制的に、データの編成を介して、データ抽象化を互いに通信し合える小型で独立したオブジェクトにする。カプセル化は、オブジェクト内のデータを不用意な損傷から保護し、且つ他のオブジェクトが当該オブジェクトのメンバ機能と構造体を呼び出すことによりそのデータと対話できるようにする。サブクラス分け及び継承は、システム中で利用できる標準クラスからオブジェクトの新種を派生させることを介して、オブジェクトを拡大し修正できるようにする。こうして、スクラッチから始めることなく新たな能力が創出される。多相性及び多様継承は、異なるプログラムが混ざり合って多くの多種多様なクラスの特性に合うようにすることを可能にし、且つ、依然として予知可能なやり方で関連オブジェクトと共に働ける専門オブジェクトを製作できるようにする。クラスヒエラルキ及びコンテインメントヒエラルキは、現実世界のオブジェクトとそれらの間の関係のモデル化のための柔軟な機構を提供する。再使用可能なクラスのライブラリは多くの状況において有用であるが、そこには幾つかの限界もある。例えば、複雑性。複雑なシステムでは、関連するクラスのクラスヒエラルキは、クラス数が何ダース或いは数百という数に上ると混乱を極める。制御の流れ。クラスライブラリの助けを借りて書かれたプログラムは、依然として制御の流れに責任を持っており、即ち、ある特定のライブラリから製作されたオブジェクト全体の間の対話を制御せねばならない。プログラマは、どの種類のオブジェクトに対し、何時、どの機能を呼び出すか決定せねばならない。労力の重複。クラスライブラリが、多くの小さなコードをプログラマが使用及び再使用できるようにしているとはいえ、プログラマはそれぞれ別々のやり方でそれらの小さなコードを一緒にしている。二人の別々のプログラマが、同じセットのクラスライブラリのを使って全く同一の2つのプログラムを書くことができるが、内部構造デザインは全く異なっているかもしれないし、それは作業中に各プログラマが行なう膨大な数の小さな決定により左右されるのである。必然的に、同様なコード片は、やり方は僅かに違うやり方で同様な事を行なうに留まるので、期待するほどには共に良好に作用するということはない。クラスライブラリには十分に柔軟性がある。プログラムが成長してより複雑になるにつれ、プログラマはベーシックな問題に対するベーシックなソリューションを何度も何度も発明し直さねばならなくなる。クラスライブラリというコンセプトの比較的新しい拡大枠は、クラスライブラリのフレームワークを持つことである。このフレームワークはより複雑であって、特定のアプリケーションドメインにおける共通の要件とデザインをインプリメントする、小型のスケールパターンと主機構の両方を手にする合同クラスの大きな集合体から成る。それらは、最初は、パーソナルコンピュータ用の表示メニュ、ウインドウ、ダイアログボックス、及び他の標準的ユーザーインターフェースエレメントに関わる雑用からアプリケーションプログラマを解放するために開発された。フレームワークは、あるプログラマが書くコードと別のプログラマにより書かれたコード間の対話についてのプラグラマの考え方における違いも表している。早期の手続き型プログラミングにおいては、プログラマは、ある特定のタスクをこなすために、オペレーティングシステムが提供するライブラリを呼び出していが、基本的にはプログラムは開始から終了までのページを実行し、制御の流れに責任を持つのはプログラマだけであった。これは、たった1通りのやり方で実行されるプログラムにより、給料支払い小切手を振り出したり、算術表を計算したり、或いは他の問題を解決したりという場合には適していた。グラフィカルユーザーインターフェースの発展により、この手続き型プログラミングの在り方はひっくり返り始めた。これらのインターフェースは、ある動作を実行せねばならなくなったときに、プログラムロジックというよりも、むしろユーザーがプログラムをドライブして決定できるようにしている。今日では、ほとんどのパーソナルコンピュータソフトウェアは、マウス、キーボード、及び外部イベントのその他ソースをモニターするイベントループという手段によりこれを実現しており、ユーザーが実行する動作に合わせてプログラマのコードの適当な部分を呼び出す。プログラマはイベントの起きる順序をもはや決めない。代わりに、プログラムは、予期できない時期に予期できない順で呼び出される別々の細片に分割される。ユーザーに対してこうして制御を放棄することにより、開発者はより簡単に使えるプログラムを製作する。それにもかかわらず、開発者により書かれたプログラムの個々の細片は、依然として、あるタスクを実現するためにオペレーティングシステムにより提供されるライブラリを呼び出すので、プログラマはイベントループにより呼び出された後に各プログラム片内の制御の流れを決定せねばならない。アプリケーションコードは依然としてシステムの頂点に居座っている。イベントループプログラムでさえ、プログラマに、全てのアプリケーションに対し別々に書かれる必要のない多数のコードを書くことを要求する。アプリケーションフレームワークのコンセプトは、イベントループコンセプトをより遠くにやってしまう。ベーシックメニュー、ウインドウ、及びダイアログボックスを構築するボルト、ナット類全てを処理して、これらを一まとめにして全体として作動させるということに代えて、アプリケーションフレームワークを使って、プログラマはアプリケーションコードとインターフェースエレメントを正しく配置することから開始する。その後、プログラマはフレームワークの一般的な能力の幾つかを意図されたアプリケーションの特定の能力と置き換えることによりそこから構築を開始する。アプリケーションフレームワークは、プログラマがスクラッチから書かねばならないコードの総数を減らす。しかしながら、フレームワークは、現実にはウインドウを表示しコピーと貼り付けをサポートする等一般的なアプリケーションであるので、プログラマはイベントループプログラムが許容するよりも広い範囲まで制御を放棄することもできる。フレームワークコードはイベントハンドリング及び制御の流れのほとんど全てを取り仕切り、プログラマのコードはフレームワークが例えば、所有権を主張できるデータ構造を製作又は操作するためにそれを必要とするときしか呼び出されない。フレームワークプログラムを書いているプログラマは、ユーザーに対する制御イベントループプログラムの場合にも当てはまるを放棄するだけでなく、フレームワークに対するプログラム内の制御の細かい流れも放棄する。このアプローチは、興味深いやり方でまとまって作動するより複雑なシステムが創造できるようにしており、孤立したプログラムとは反対に、特注コードを有し、同様の問題につき何度も繰り返して創造される。以上、説明したように、フレームワークは基本的には、所与の問題ドメインに対して再使用可能な設計ソリューションを作り上げる協働するクラスの集合体である。それは通常例えば、メニュ及びウインドウのためのデフォルト行動を提供するオブジェクトを含んでおり、プログラマは、デフォルト行動の幾つかを継承しその他の行動をオーバーライドすることによりそれを使用して、フレームワークが適時にアプリケーションコードを呼び出すようにする。フレームワークとクラスライブラリの間には主な違いが3つある。行動対プロトコル。クラスライブラリは、基本的には行動の集合体であって、プログラム内でそれら個別的行動を所望する際に呼び出すことのできるものである。一方、フレームワークは行動だけでなく、行動を組み合わせるやり方を統制するプロトコル即ちルールのセットを提供するものであり、それにはプログラマが提供すると期待されるもの対フレームワークが提供するものについてのルールも含まれる。呼び出し対オーバーライド。クラスライブラリを使う場合、プログラマはオブジェクトを例示し、それらのメンバ機能を呼び出す。フレームワークでも同じやり方でオブジェクトを例示し呼び出す即ち、フレームワークをクラスライブラリとして扱うことができるが、フレームワークの再使用可能な設計を十分活用するには、プログラマは、通常、オーバーライドしフレームワークにより呼び出されるコードを書く。フレームワークはそれらオブジェクト間の制御の流れを管理する。プログラムを書くことは、別々のソフトウェア片をどうやってまとまって作動するようにするかを規定することではなくて、むしろフレームワークに呼び出される様々なソフトウェア片の間で責任を分割することに関係している。インプリメンテーション対設計。クラスライブライを使う場合、プログラマはインプリメンテーションだけを再使用するが、フレームワークの場合は設計を再使用する。フレームワークは関連プログラムのファミリー又は複数片のソフトウェアが動作するやり方を具体化する。それは、所与のドメインにおける各種特定問題に適合できる普遍的設計ソリューションを代表している。例えば、ある1つのフレームワークはユーザーインターフェースが動作する方法を具体化するが、とは言っても同じフレームワークで製作された2つの異なるユーザーインターフェースが全く異なるインターフェース問題を解くこともある。このように、各種問題とプログラミングタスクに対するソリューションのためのフレームワークの開発を通して、ソフトウェアにとっての設計及び開発努力を著しく低減することがでる。本発明の好適な実施例では、クライアントとNewcoの間の伝達媒体用の汎用セキュア通信プロトコルと共に、ハイパーテキストマークアップ言語HTMLを使ってインターネット上にドキュメントをインプリメントする。HTTP又は別のプロトコルは、無用な実験をせずとも難なくHTMLに成り代わり得る。これら製品に関する情報は、T.ベマース-リー、D.コノリーによるRFC1866、ハイパーテキストマークアップ言語-2.0、1995年11月及び、R.フィールディング、H.フリスティク、T.ベマース-リー、J.ジェティース、J.C.モーグルによるハイパーテキストトランスファープロトコル-HTTP/1.1:HTTPワーキンググループインターネットドラフト、1996年5月2日から入手できる。HTMLは、1つのプラットホームから別のプラットホームへと持ち歩き可能なハイパーテキストドキュメントを作るために使用される単純なデータフォーマットである。HTMLドキュメントは広範なドメインからの情報を表現するのに適した普遍的意味論を備えたSGMLドキュメントである。HTMLは1990年から始まった世界的な情報ワールドワイドウェブに使用されている。HTMLはISO標準8879、1986年情報処理テキスト及びオフィスシステムのアプリケーション、標準汎用マークアップ言語SGMLである。現在まで、ウェブ開発ツールは、クライアントからサーバまでを範囲に含め、現行のコンピューティングリソースを使って相互動作するダイナミックなウェブアプリケーションを作る能力に限度があった。最近まで、HTMLはウェブベースのソリューションの開発に使用される主力技術であった。しかしながら、HTMLは以下の領分、即ち劣った性能、限定されたユーザーインターフェース能力、スタティックなウェブページしか作り出せない、現行のアプリケーション及びデータとの相互動作能力の欠如、及びスケーリングが不可能、という点で適していないことが証明された。サンマイクロシステムズ社のJava言語は、クライアント側の性能を改善すること、ダイナミック且つリアルタイムなウェブアプリケーションの製作を可能にすること、及び、多種多様なユーザーインターフェースコンポーネントを製作する能力を提供すること、によりクライアント側の問題の多くを解決する。Javaを用いれば、開発者は頑強なユーザーインタフェースUIコンポーネントを製作することができる。特注の仕掛け例えば、リアルタイムな株価表示機、動画アイコンなどが作れ、クライアント側の性能が改善される。HTMLとは違って、Javaはクライアント側の妥当性検査の概念をサポートし、性能を向上させるために適当なプロセッシングをクライアント側にオフロードする。ダイナミック且つリアルタイムなウェブページが創造可能となる。上記の特注UIコンポーネントを用いれば、ダイナミックなウェブページも創造できる。サン社のJava言語はインターネットをプログラミングするための、業界が認めた言語として登場した。サン社はJavaを、単純、オブジェクト指向型、分散型、解釈型、頑強、安全、アーキテクチャニュートラル、ポータブル、高性能、マルチスレッデッド、ダイナミック、且つ専門語対応可能な汎用プログラミング言語と定義づけている。Javaはプラットホーム非依存型Javaアプレットという形でインターネットのためのプログラミングをサポートする。Javaアプレットは、サン社のJavaアプリケーションプログラミングインタフェースAPIを遵守する小型の専門アプリケーションであり、開発者がインタラクティブコンテンツをウェブドキュメント例、単純動画、ページ装飾、及び基本的ゲーム等に付け足すことができるようにしている。アプレットはJava互換ブラウザ例、ネットスケープナビゲータ内で、サーバからクライアントへコードをコピーすることにより実行する。言語の観点から見ると、Javaのコア特性のセットは、Cが基礎となっている。サン社のJava文献には、Javaは基本的にはC言語がよりダイナミックな方法解決策を求めてオブジェクトCから拡張したものであると述べられている。Javaに同様の機能を提供する別の技術は、マイクロソフト並びにアクティブXテクノロジーズにより提供され、開発者とウェブデザイナーにインターネット及びパーソナルコンピュータ用のダイナミックコンテンツを構築するのに必要な手段を提供する。アクティブXは、動画開発、3-Dバーチャルリアリティ、ビデオ、及び他のマルチメディアコンテンツ用のツールを含んでいる。ツールはインターネット標準を使用し、複数のプラットホームで動作し、100を超える会社によりサポートされている。グループが構成しているブロックはアクティブXコントロールズと呼ばれ、開発者がソフトウェアのパーツをハイパーテキストメークアップ言語HTMLページに埋め込むことができるようにする小型で高速のコンポーネントである。アクティブXコントロールズは、マイクロソフトビジュアルC、ボーランドデルフィ、マイクロソフトビジュアルベーシックプログラミングシステムを始めとする多様なプログラミング言語で動作し、将来的にはマイクロソフト社のJava用開発ツールのコードネームジャカルタで動作できる。当業者には、アクティブXが、本発明を実用化するに当たり無用な実験をしなくともJavaの代わりと成りうることが自明であろう。好適な実施例によれば、バックグラウンドファインダーBFは、個人が来るべきミーティングに備える場合に、彼/彼女が各種ソースからそのミーティングについての関連情報を検索することを助けることにより準備に責任を持つエージェントとしてインプリメントされている。BFは、目標ミーティングを表示する文字形式の入力テキストを入手する。入力テキストは、好適な実施例によるとミーティングの日時を含むカレンダプログラムにより生成される。ミーティングが近づくと、カレンダプログラムは目標イベントのテキストを入手するために問い合わせを受け、その情報はエージェントシステムへの入力として利用される。そこで、エージェントシステムは入力されたミーティングテキストを構文解析して、題目、本体、参加者、場所、時間などの各種要素を抽出する。システムは、パターンマッチングも行って、ミーティングテキスト内の特定のミーティングフィールドを識別する。この情報を使ってウェブ上で各種情報源に問い合わせを行ない、現在のミーティングについての関連記事を入手して、それをカレンダリングシステムに送り返す。例えば、ある個人が争議につき討論するためにネットスケープ及びマイクロソフトとミーティングを持つ場合、システムはこの最初の情報をカレンダリングシステムから入手する。システムは次にテキストを構文解析してミーティングの会社がネットスケープとマイクロソフトであり、議題が争議であると理解する。システムはここでこの議題に関する関連情報を求めてウェブに問い合わせをする。このように、本発明の目的によれば、システムは目標ミーティングに備えて収集し得る最良の情報でカレンダリングシステムを更新し、結果としてユーザーにもそれら情報を与えることになる。好適な実施例によれば、情報はカレンダシステムに内蔵されたリンクからの選択を介して得られるファイルに記憶される。[プログラム編成]好適な実施例によれば、コンピュータプログラムは5つの区別できるモジュール、即ち、BF.Main、BF.Parse、BackgroundFinder、Error、BF.PatternMatching、及びBF.Searchで編成されている。デバッグ目的にのみ使用されるユーザーインターフェースを提供するfrmMainもある。好適な実施例によれば、実行可能なプログラムはユーザーインターフェースでは絶対に実行できず、マイクロソフト社のウィンソック制御を介してカレンダリングシステムに戻されるだけである。システムの好適な実施例は、カレンダリングシステムにより戻された共通ラインの下に規定できる2つの異なるモードで実行する。システムが単純モードで起動している場合、キーワード照会を実行して外部サーチエンジンに実行依頼する。複雑モードで起動している場合、システムはサーチエンジンに送る照会を形成する前にパターンマッチングを行なう。[データ構造]好適な実施例によるシステムは、3つのユーザー定義型構造、即ち、1.TMeetingRecord;2.TPatternElement;3.TpatternRecordを使用する。ユーザー定義型構造tMeetingRecordは、1つのミーティングに関する全ての関連情報を記憶するために使用される。この情報には、ユーザーID、ミーティングのオリジナルの記述、ミーティングの題目及び本体から抽出されたキーワードのリスト等が含まれる。好適な実施例によれば、ミーティング記録はシステムのインスタンス毎に1つしか作られないということは重要なので留意頂きたい。これは、来るべきミーティングを担当するためにシステムが生まれる都度、システムはたった1つのミーティングのために情報を検索するというタスクを割当てられるからである。従って、作られたミーティング記録は現在調査中のミーティングに対応している。ParseMeetingTextはこのミーティング記録をある場所に置き、次にその記録は巡回されて他の機能にミーティングについての情報が提供される。仮にGoPatterMatchがある特定のミーティングフィールドに対してある値を組み合わせることができれば、ミーティング記録内の対応するエントリも更新される。各フィールドが括弧で記述されているtMeetingRecordの構造を、好適な実施例により以下に示す。パターンマッチングに利用される個別パターンを保有するために作られる構造が他にも2つある。記録tAPatterRecordは、パターンの全コンポーネント/エレメントを保有しているアレイである。タイプtAPatterElementは、パターン内のエレメントを表すストリングのアレイである。各エレメント毎に多数の置換が存在するかもしれないので、置換が全て何であるかを見失わないようにするためにストリングのアレイが必要になる。tAPatternElement及びtAPatternRecordは好適な実施例によれば以下のように表現される。[一般ユーザー定義型定数]プログラムの各宣言部において多くの定数が定義されるが、好適な実施例によれば、システムを保守するプロセスの一部として周期的に更新する必要がある。定数は、システムのダイナミックな構成がコードを保守するための更新として起きるようにするために、アクセス可能である。以下の表に掲載されているのは、時々に最も修正される可能性が高いと考えられる各モジュールからの定数のリストである。しかしながら、以下のリストには含まれていないが、コードに使用される定数が他にもある。これら含まれていない定数は決して変更されないということではない。それらも変更されるがその頻度はずっと少ないというだけのことである。パターンマッチングモジュールBFPatternMatch:頻繁な更新を必要とする定数は本モジュールには無い。[一般的プロセスの流れ]プロセスフロー及び各機能間のコーディネーションを示す最良の方法は、図2から6に図示す5つのフローチャートを用いることである。図2は好適な実施例による全体的なプロセスの流れを示している。プロセッシングは図の一番上の機能ブロック200から始まるが、これはプログラムが開始されるときに動き始める。好適な実施例によれば、機能ブロック210に示すように、アプリケーションが開始されると、コマンドラインは構文解析されて適当なミーティングテキストを移動させ、バックグラウンドファインドオペレーションの目標を初期化する。広域停止リストは、機能ブロック220に示すように、目標が定められた後で生成される。次に、ブロック230に示すように、マッチングオペレーションに使用される全パターンが生成される。チャートを追っていくと、機能ブロック200はGoBF240を呼び出すが、これは特定目標サーチエンジンのために正確なサーチ照会情報をラッピングすることに関連付けられたロジカルプロセッシングに責任を持つものである。例えば、機能ブロック240は機能ブロック250へとつながり、そこで機能ブロック260に示すGoPatternMatchを呼び出す。GoPatternMatchのプロセスフローを理解するため、本図をBFのパターンマッチングユニットのためのプロセスフローと題することにする。1つ重要なことは、図中同一レベルに示される機能は左から右の順又は上から下の順で共通の親機能に呼び出される点である。例えばMain200はProcessCommandLine210を呼び出し、続いてCreatStopList220、そしてCreatPatters230、次にGoBackFinder240の順に呼び出すわけである。図3から6はプログラム全体のロジック、構文解析ユニット、パターンマッチングユニット、及びサーチユニットをそれぞれ詳しく示した図である。図6はBackgroundFinderを介してキー情報のデータフローを決定するロジックを詳細に表し、そのような情報を製作し又は処理することに責任を持つ機能を示している。[単純な照会モード下の詳細なサーチ構造][アルタビスタサーチ]図2の機能ブロック270アルタビスタサーチエンジンは、図2の機能ブロック270に示すように、識別を使って現下のミーティングに関連する議題についての一般情報を戻す。好適な実施例によるシステムは、オリジナルのミーティングテキストの題目部分からキーワードを全て抜き出し、アルタビスタに送るためのアドバンスド照会を作り上げる。キーワードは照会内で互いに論理的に組み合わせられる。その結果も、同じキーワードのセットに基づいてランク付けされる。当業者には、データ制限又は編集者基準により、検索を望んでいる事柄がやり易くなることが容易に理解されよう。好適な実施例によれば、トップにランクされた記事のセットがカレンダリングシステムに戻される。[ニュースページ]図2の機能ブロック275NewsPageサーチシステムは、目標ミーティングに関連する最新ニューストピックを我々に与えることに責任を持っている。このシステムはオリジナルのミーティングテキストの題目部分からキーワードを全て抜き出し、NewsPageサーチエンジンに送るための照会を作り上げる。キーワードは照会内で互いに論理的に組み合わせられる。最近発行された記事しか検索されない。NewsPageサーチシステムは、ユーザーの好みによりユーザーが設定できるデータ限定基準を提供する。トップにランクされた記事がカレンダリングシステムに戻される。図3は、好適な実施例によるユーザープロフィールデータモデルである。プロセッシングは機能ブロック300で開始されるが、このブロックはメインモジュールからプログラムを呼び出すことに責任を持っている。次に、機能ブロック310では、ラッパ機能が呼び出され、機能ブロック320のキーワード抽出プロセッシングに備える。キーワードが抽出された後、プロセッシングは機能ブロック330に進み、区切記号が正しく位置づけられたか否かを判定する。そして、機能ブロック340で、特定ストリング中のワード数が計算され、特定フィールドに対する区切記号及びミーティングテキストからの特定フィールドが機能ブロック350で検索される。次に機能ブロック380で、ストリングの区切記号が再度チェックされ、それらが確実に正しく配置されるようにする。最後に、機能ブロック360で、メッセージの題目及び本体からの各ワードの抽出が1度に1ワードずつ行なわれるが、その抽出は、入力フレーズ内の最も近いワード区切記号を見つける機能ブロック362、ワードから不要なマテリアルを取り除く機能ブロック364、及びワードが停止リストに載っているかどうかを判定してワードが停止リストに載っていればエラーを戻す機能ブロック366のロジックを利用して行なわれる。[好適な実施例によるパターンマッチング]単純なサーチ方法に関連する制限は以下の通りである。1.ミーティングテキストからキーワードのセットを抽出するためには不要ワードの停止リストに依存することになるので、停止リストがどれほど包括的であるかにより限界が決まる。ミーティングテキストのどの部分を捨てるべきかを計算する代わりに、ミーティングテキストのどの部分が欲しいのかに焦点を置くべきである。2.好適な実施例による単純サーチ方法は、ミーティング題目からのキーワードだけを使ってアルタビスタとNewsPageに送信する照会を作る。これは、照会のための代わりの情報源、即ちミーティング告示の本体を無視することである。我々の照会を作るためにはミーティング本体からのキーワードは含まない、というのも、余りも長すぎて複雑であるため意味のある結果を得ることができないということがしばしば生じるからである。3.我々には各キーワードが何を表現しているか分からない。例えば、2つのキーワードアンディとグローブを抽出するとしよう。しかしながら、単純に割り切ったサーチではアンディグローブが実は人物の名前であることを知る術がない。我々が何らかの方法でアンディグローブは人物名であると聡明にも推定できたならという可能性を想像して頂きたい。彼がアンデルセンという人物であるか否か、そしてそうであれば彼が以前にどんな種類のプロジェクトに携わっていたか等は我々にも分かる。4.要約すると、不要なワードを構文解析するために停止リストだけに依存することにより、我々は情報のオーバーロードに悩まされるのである。[好適な実施例によれば、パターンマッチングはこれらの制限を克服する]ここで、パターンマッチングシステムが、どのようにして対応する上記問題それぞれに取り組むことができるのかを好適な実施例により示す。1.パターンマッチングを行なうことにより、我々は欲しいと思うミーティングの部分だけを取り上げてそれらの部分だけを抽出する。2.ミーティング本体に関してパターンマッチングを行ない、我々が欲しいと思う部分だけをミーティング本体から抽出することにより、我々のミーティング本体はそれらを完全に無駄にすることはなくなる。3.パターンマッチングは、我々が規定するテンプレートのセットに基づいているので、人物名、会社名等をミーティングテキストから識別することができる。4.要約すると、パターンマッチングを用いれば、我々はもはや情報のオーバーロードに悩まされることはない。無論、大きな問題は、我々のパターンマッチングがどれほど良好に作動するかという点である。我々が専ら人工知能プロセッシングに頼るのであれば、100のヒット率は望めない。我々は提示された全会社名のうち約20を識別できる。[パターン]好適な実施例のコンテクストにおけるパターンは、我々がミーティングテキスト内に捜しているフレーズの構造を規定しているテンプレートである。好適な実施例によりサポートされるパターンは、それらがだれかのミーティングテキストに現れる確率が高いフレーズのテンプレートであるという理由で選択される。例えば、あるミーティングをカレンダーに入力しようとするとき、多くの人はMeetwithBobDuttonfromStanfordUniversitynextTuesday.来週スタンフォード大学のボブダットンと会うというようなことを書き込む。一般的なパターンというのはwithというワードの後に人物名本例ではボブダットンが続き、その後にfromが続き、組織名本例ではスタンフォード大学で終わるというようなものである。[パターンマッチング専門用語]パターンマッチングに関係する一般的な専門用語を以下に説明する。パターン。パターンはミーティングテキストを結びつけようと思うフレーズの構造を規定するテンプレートである。これはサブユニットを保有している。エレメント。パターンは多数のサブユニットを含んでいる。これらサブユニットはエレメントと呼ばれる。例えば、withPEOPLEfromCOMPANYというパターンにおいて、with、PEOPLE、from、COMPANYはエレメントである。プレースホルダ。プレースホルダとは、ある値を結びつけたいと思う特種なエレメントのことである。上記の例を用いるならPEOPLEがプレースホルダである。インジケータ。インジケータとは、我々がミーティングテキスト中に見つけたいと思う別種のエレメントであるが、それに結びつけるには値は不要である。あるパターン内で捜しているインジケータが2つ以上のこともしばしばあろう。それはインジケータが原子タイプではないからである。置換。置換とは、全て互いの同義語であるインジケータのセットである。入力内に置換えの1つでも見つけられれば良好といえる。各ミーティング毎に識別されるフィールドが5つある。会社COMPANY人々PEOPLE場所LOCATION時刻TIME議題TOPIC_UPPER又はTOPIC_ALL括弧内は、自分のコードで使用されるプレースホルダであり、対応しているミーティングフィールドの表現である。各プレースホルダには以下ような意味がある。COMPANY:大文字ワードのストリングを結合する例えば、MeetwithJoeCarterof<AndersonConsulting><アンダーセンコンサルティング>のジョーカーターと会う。PEOPLE:,and又はにより接続される可能性のある大文字ワード2語のストリングのシリーズを結合する例えば、Meetwith<JoeCarter>ofAndersonConsulting、Meetwith<JoeCarterandLukeHughes>ofAndersonConsultingアンダーセンコンサルティングの<ジョーカーター>と会う、アンダーセンコンサルティングの<ジョーカーター並びにルークヒューズ>と会う。LOCATION:大文字ワードのストリングを結合する例えば、MeetSusanat<PaloAltoSquare><パロアルトスクエア>でスーザンに会う。TIME:フォーマット:を含んでいるストリングを結合する例えば、Dinnerat<6:30pm><午後6時30分>に夕食。TOPIC_UPPER:我々の議題に関する大文字ワードのストリングを結合する例えば、<StanfordEngineeringRecruiting>Meetingtotalkaboutnewhires.新規雇用について論議するための<スランフォードエンジニアリング社員募集>会議。TOPIC_ALL:大文字か否かを問題にしないワードのストリングを結合する例えば、Meettotalkabout<ubiquitouscomputing><ユービキタスコンピューティング>を論じるために会う。ここにBFによりサポートされる全パターンを表している表を示す。各パターンはあるパターングループに属している。あるパターングループ内の全パターンは同じフォーマットを共用しており、置換えとして使われるインジケータが何かという点においてしか区別できない。尚、灰色にされたパターンもコードで解説される。BFはこれらのパターンをサポートする能力を有するが、これらのパターンをマッチングさせることは現時点では必要ではないと決めた。図4は、好適な実施例によるパターンマッチングの詳細なフローチャートである。プロセシングは機能ブロック400に始まり、ここでメインプログラムがパターンマッチングアプリケーションを呼び出して制御を機能ブロック410に渡すとパターンマッチングプロセッシングが開始される。機能ブロック420で、ラッパ機能はループしながら各パターンを処理するが、これには、機能ブロック430に示すように、テキストストリングの一部があるパターンに結びつくかどうかを判定することも含まれている。次に、機能ブロック440で、各種プレースホルダは値が存在する場合にはその値に結びつけられ、機能ブロック441では句読点により分離された名前のリストが結びつけられ、機能ブロック442では、フルネームとして大文字ワード2語を見つけ、あるワードの後のスペースの後の次の文字をそれが大文字かどうかを判定するために入手することによりフルネームが処理される。次に機能ブロック443で、適切な方法でストリングから時刻が構文解析され、機能ブロック444では空白スペース後の次のワードが構文解析される。そして、機能ブロック445では、会社、議題、場所のような大文字ワードの連続フレーズが結びつけられ、機能ブロック446では、空白後の次のワードが好適な実施例による以後のプロセッシングに向け入手される。突き合わせミーティングフィールドプロセッシングに続き、機能ブロック450を使ってパターンのヘッドであるインジケータを見つけ、機能ブロック452に示すように空白の後の次のワードが入手され、そのワードは機能ブロック454に示すように、インジケータであるか否かを判定するために調べられる。そして、機能ブロック460で、ストリングが構文解析され、パターンの終りではないインジケータが発見されると、改行やキャリッジリターンの後にくるような不要な空白の後の次のワードが機能ブロック462に示すように処理され、そのワードは機能ブロック464に示すように、分析され、それがインジケータであるか否かが判定される。次に、機能ブロック470で、一時的記録はナルにリセットされて次のストリング処理のための準備をし、機能ブロック480でミーティング記録が更新され、機能ブロック482でチェックが行なわれ、ミーティング記録が再度構文解析される前にミーティング記録に対してエントリが既にあったかどうかが判定される。[識別されたミーティングフィールドを使用する]現在ミーティングテキスト内に我々が重要だと見なすフィールドを識別している時点で、それを使ってできることはほとんど無い。パターンマッチングの最重要アプリケーションは、最終的にはアルタビスタ及びNewsPageに提出されることになる我々が構築する照会を改善する過程である。BFに追加できるパターンマッチングの結果を利用するオプション及び強化策は他にもたくさんある。これら他のオプションは次の節で説明することにしよう。本節の目的は読者に、パターンマッチングから得られる結果が、より良好なサーチ結果を得るのを援助するためにどのように利用できるかをよく理解して頂くことである。図5は、好適な実施例による照会の準備及びインターネットからの情報入手の詳細なプロセッシングを示すフローチャートである。プロセッシングは機能ブロック500に始まり、直ぐに機能ブロック510に進んで、ウェブサーチエンジンを使ってインターネットサーチに備えるためにラッパ機能性を処理する。サーチがアルタビスタサーチエンジンを利用する場合、機能ブロック530で、システムはミーティング記録から情報を取り出し、機能ブロック540から560でサーチエンジンに提出する照会を形成する。サーチがNewsPageサーチエンジンを利用する場合、機能ブロック520で、システムはミーティング記録から情報を取り出し、機能ブロック521から528で照会を形成する。[アルタビスタサーチエンジン]アルタビスタサーチエンジンの強度は、柔軟性を強化することができるほどのものである。そのアドバンス照会方法を使えば、全種類のブール式照会を構築でき、どのようであれ希望するようにサーチをランク付けすることができる。しかしながら、アルタビスタの最大の欠点の1つは大規模な照会を扱うのが苦手で、的外れな結果を返す可能性が高いということである。ミーティングテキスト内の議題と会社を識別できるのであれば、かなり短くても包括的な問い合わせを作ることができるであろうし、その方が結果が良いと思われる。見つけられる議題にも焦点を当ててみたい。ユーザーが会社を既によく知っておりそれらの会社と何度もミーティングを持ったことがある場合には特にそうであるが、会社についての情報を発見することはユーザーにとって大したメリットとはなりえない。ユーザーが調べたいのは議題である。[NewsPageサーチエンジン]NewsPageサーチエンジンの強度は、仮に有効な会社名を与えられるのであれば、最新のニュースのサーチに多大な仕事をするというほどである。従って、ニュースページウェブサイトにある問い合わせを提出するとき、我々は識別できるなら何れの会社名をも送信し、会社名が見つけられないときに限り見つけられた議題を使って問い合わせを作成する。両方とも見つからないときには、サーチは行なわれない。アルタビスタに提出される問い合わせの作成に使用されるアルゴリズムを図7に示している。NewsPageに提出する問い合わせの作成に我々が使用するアルゴリズムは図8に示す。以下の表は、好適な実施例による各機能を詳細に説明している。機能はできる限りプロセスの流れに合わせた順に示している。数度呼び出しを受ける機能がある場合には、それを呼び出す最初の機能の後にその機能を掲載しており、後続の機能がそれを呼び出す都度その後に説明が重複して示されることはない。図6は好適な実施例による、アルタビスタ及びNewsPageサーチエンジンに対するサーチを準備し提出するために使用される実際のコードのフローチャートである。プロセッシングは機能ブロック610に始まり、ここでコマンドラインを使ってカレンダエントリを特定のカレンダ情報で更新する。メッセージは次に、機能ブロック620で転記され、機能ブロック630で、現在のミーティング情報を記憶するためにミーティング記録が作成される。次に、機能ブロック640で問い合わせがアルタビスタサーチエンジンに提出され、機能ブロック650で問い合わせがNewsPageサーチエンジンに提出される。サーチエンジンからメッセージが戻されると、機能ブロック660に示すように、結果データ構造に記憶され、機能ブロック670に詳細に示すように、情報は処理されてミーティングの準備に用いられるように要約形式でファイルに記憶される。図7は好適な実施例による、問い合わせを作成する際の詳細を示している。プロセッシングは機能ブロック710に始まり、ここでミーティング記録が構文解析され、考えられる会社、人物、議題、場所及び時間が入手される。次に、機能ブロック720で少なくとも1つの議題が識別され、機能ブロック730で少なくとも1つの会社名が識別され、最後に機能ブロック740で、ユーザーが最終的に使用するファイルに何のマテリアルを送信するかにつき決定が下される。図8は、図7に示す問い合わせテーマのバリエーションである。ミーティング記録は機能ブロック800で構文解析され、機能ブロック820で会社が識別され、機能ブロック830で議題が識別され、最後に機能ブロック840で問い合わせ作成にその議題及び/又は会社が使用される。特定のユーザーのために様々な特定の特性を付加するための代わりの実施例を以下に説明する。[パターンマッチングの目標レートを強化する]BFの性能を向上させるために、多くのパターン/パターングループが手続きCreatePatternsに加えられる。パターンを宣言するための現行コードは将来のパターンに備えるテンプレートとして用いることができる。全てがダイナミックアレイとして記憶されるため、コード切り取りと貼り付けにより再使用するのが好都合である。BindName、BindTime、BindCompanyLocTopicの機能はある値をプレースホルダに結びつける責任を担っているが、これらは強化される。強化は、結びつける値の数を増やすためにあるミーティングフィールドを結びつけるための基準のセットを増やすことにより実現される。例えば、BindTimeは現在:又は:という形式で全ての値を受け取り結びつける。結びつけ可能な回数を増やすためには、BindTimeにも1から12の数に、より感覚的な時間専門用語であるo‘clockを付けて読み込んでもらいたい。語彙バースの認識アルゴリズムと、正確なレートを各推量に割り付けることにより、BFはある閾値に当てはまる推量しか有効とならないようにできる。パターンマッチングを通してシステムがどの場所を識別するかにより、或いはユーザーがどの場所をミーティング場所として示すかにより、好適な実施例によるシステムは、昼食/夕食/朝食というワードを検知した場合にはいつでも立派なレストランを複数個提案する。我々は、会社ファインダのようなサイトを使って、我々が手にしたものが実際に会社名かどうかを確認することもできるし、又はパターンマッチングが識別できる会社名が存在しないのであれば辞書のような会社ファインダウェブサイトを使って、ある大文字ワードが会社名を表しているかどうかを我々が判断することもできる。我々は我々が識別した会社に関する株価及びブレーキングニュースを表示することもできる。[好適な実施例による無線バーゲン識別]図9は、従来の物理的な非ウェブ小売り環境で、ウェブベースの比較ショッピングができるように設計されている装置及びソフトウェアシステム用の、ハードウェア及び制御に関する論理的流れを示すフローチヤートである。インターネットプロトコル能力を有する無線電話又は類似のハンドヘルド無線装置920は、小型バーコードリーダー910電話内又はショートケーブル上のどちらかにインストールされていると組み合わせられ、本又は別の製品のユニバーサルプロダクトコードUPCバーコードを走査するのに用いられる。無線装置920は、バーコードをアンテナ930経由でポケットバーゲンファインダサービスモジュールウェブサーバー上で稼働している940へ送り、ポケットバーゲンファインダサービスモジュールは、それを、その国際標準書籍番号又は他の製品の場合は識別子が適切な何れかの番号に変換する。次にサービスモジュールは、様々なウェブサプライヤ950からの、その製品に関する価格、納期及び有効な情報を見つけるために、適切なサードパーティのウェブサイトに接触する。この情報はフォーマットされ、ハンドヘルド装置のスクリーン上に表示される。IP無線電話又は他のハンドヘルド無線装置920は、メトリコム社のリコシェットSE無線モデムのような無線モデムを利用する。この装置を利用すれば、ユーザーは、キーボードの危険なほど近くでラッテをぽちゃぽちゃさせながら、ガタついた小さなテーブルの上に載せた携帯コンピュータを使って、喫茶店にいながら、電話線を経由する直接接続に匹敵する速度でインターネットにアクセスすることができる。8オンスのリコシェットSE無線モデムはタバコ1箱の大きさとほぼ同じで、セットアップは非常に簡単であり、添付されているベルクロのマジックテープで携帯のスクリーンの後ろにモデムを取り付け、ケーブルをシリアルポートに差し込み、短くて太いアンテナをぐいと上げ、送信するだけである。ソフトウェアのセットアップも同じく簡単で、直接インストーラーがリコシェットモデムドライバを加え、接続アイコンをデスクトップ上に置く。そのモデムの機能の態様は、伝統的な電話モデムのそれと全く同じである。勿論、無線性能は、従来のダイヤル電話接続ほど信頼できない。我々は、窓の近くに居る限りは、幾つかのサンフランシスコのロケーションと強力な接続ができた。しかしCNETの総レンガ造りの本社の中では、リコシェットは全く繋がらなかった。オンラインと繋ぐ場合、28.8kbpsまでの性能が使えるが、徐々に効率は低下して低速になる。しかし、低速でも失望しなかった。セルラーモデムを通して接続する場合と比べると、リコシェットは、速いし、信頼性があり、安価である。当然、SE無線の電源はバッテリーである。モデムの持続バッテリー寿命は12時間もある。更に、好適な実施例によれば、我々はリコシェットが弱まる前に、携帯コンピュータの2つのセルを停止させた。このように、好適な実施例によれば、無線モデムを使えば、ユーザーは、正しい製品を識別する950ためにウェブサーバーソフトウェア940を利用し、次に、適切な装置のキーを用いてサプライヤを選択し、注文を出すことができる。次に、バーゲンファインダサービスモジュールは、適切なサードパーティのウェブサプライヤを使ってその注文を完了させる960。[mySite個人ウェブサイト及びインテンションバリューネットワークプロトタイプ]mySiteは、バイヤー中心の世界で個人のウェブサイトを通して各消費者へサービスを配信し、個人向け経験を提供するというテーマに焦点を当てている好適な実施例による、インパクトの強いインターネットベースのアプリケーションである。サービスは、広大な計画の判断や、財政計画、健康管理、個人的及び専門的自己啓発、家族生活、その他の関心事のような複数の問題にまたがる調整を必要とする根本的な生活上の必要性並びに目的など、消費者の意図を満足させるものの周りに感覚的に組織されている。各メンバーはそれぞれのプロファイルを所有して維持しており、そのメンバーは、自分だけに目標が定められたシステム内でコンテンツを作成しブラウジングすることができる。製品又はサービスに対する要求が入力されたときから支払いの完了まで、検索を実施し、取引を実行し、アドバイスを提供するために、知的エージェントが利用される。高度なプロファイリング及びフィルタリングを用いることにより、知的エージェントはユーザーについて学習し、配信するサービスを改善する。消費者の意向には、デイリーなロジスティックの管理例えば、eメール、カレンダー、面会、予定リスト、請求書の支払い、ショッピング、旅行計画と、新しいコミュニティへの移動例えば、住まい探し、引越し、旅行及び船旅の保険の適用、社用及び個人的面会の通知、新しいコミュニティについての学習とが含まれている。消費者の立場からすると、mySiteは、ユーザーが、非常に簡単且つ便利に当を得た製品及びサービスにアクセスできて、日々のタスクを遂行できる中心的ロケーションを提供する。ビジネスの観点からすると、mySiteは、消費者を効果的に惹きつけ、サービスし、保持し続けるため、付加価値のある画期的な方法を提示している。ユーザーは、インテンションバリューネットワークにより、個人向けサイトを通じて参入できるし、学習する知的エージェントの支援で、ネットワークの参加者と途切れなく対話できる。好適な実施例によるインテンションバリューネットワークは、すばらしい価値を提供する。それは、カスタマイズされた情報、アドバイス及び製品に、週に7日、1日24時間のアクセスを提供する。その情報は、個人向けになっているので、各メンバーが、ターゲットユーザーに対し確実に当を得たコンテンツを見ることになる。[自己中心型インターフェース]自己中心型インターフェースは、特定ユーザーのニーズ、嗜好及び現在のコンテクストを満たすように綿密に作成されたユーザーインターフェースである。インターフェースをカスタマイズするために、中央プロファイルデータベース内に記憶されているユーザーの個人情報が利用される。ユーザーは、インタフェースエレメントとコンテンツにに対してセキュリティ許可を設定し、嗜好を設定することができる。自己中心型インターフェースに統合されているコンテンツは、ユーザーについての関連情報を使ってカスタマイズされる。コンテンツを表示する場合、自己中心型インターフェースには、コンテンツがユーザーとどのように関っているのかを示すやり方で、コンテンツとユーザーとの関係をが含まれることになる。例えば、ユーザーが参加する次の空の旅についての情報を表示する場合は、インターフェースには、空の旅の間にその領域内にいるであろう別の人々のような、ユーザーの個人カレンダー及び面会リストからのイベントについての情報が含まれることになる。これによって、新情報が、個々のユーザーに馴染みのあるコンテンツに挿入される。図10Aは、ワールトワイドウェブ用のインテンションバリューネットワークアーキテクチャのインプリメンテーションを示している。簡単のために、図は、セキュリティ、スケーラビリティ及びプライバシーに関する複雑な様態を省いている。顧客は、インターネット又はパーソナルデジタルアシスタントに無線機能を使って接続されているパソコン上で実行されているネットスケープナビゲータ又はマイクロソフトインターネットエクスプロアーのような、何れかのインターネットウェブブラウザ1010を用いて、インテンションバリューネットワークにアクセスできる。インテンションバリューネットワークにアクセスするための多様な方法の更に詳細な説明については、図17を参照されたい。顧客は、インテグレイタのウェブサーバー1020に関わる独自のネーム又はIPアドレスを使って、インテンションバリューネットワークにアクセスする。インテグレイタは、インテンションデータベース1030、コンテンツデータベース1040、サプライヤプロファイルデータベース1050、顧客プロファイルデータベース1060のようなリソースの組み合わせを使って、インテンションバリューネットワークを作成する。インテンションデータベース1030は、意向を満たすのに必要な製品及びサービスの意向及びタイプの構造に関する全情報を記憶している。このデータベース内の情報には、意向ステップ、関心事の領域、レイアウトテンプレート及び個人化されたテンプレートが含まれている。コンテンツデータベース1040は、アドバイス、関連情報、個人化されたコンテンツ、満足度のランク付け、製品のランク付け及び進展報告のような、意向に関する全情報を記憶している。サプライヤプロファイルデータベース1050は、インテンションに統合されている製品及びサービスプロバイダに関する全情報を含んでいる。このデータベース内に含まれる情報は、インテンションフレームワークとサプライヤとの間にリンクを提供する。それは、製品リスト、特徴及び解説、及びサプライヤの製品のウェブサイトのアドレスを含んでいる。顧客プロファイルデータベース1060は、名前、住所、社会保障番号及びクレジットカードに関する情報、個人的嗜好、行動情報、履歴及びウェブサイトレイアウトの嗜好のような顧客に関する個人情報を含んでいる。サプライヤのウェブサーバー1070は、顧客に情報及び取引のサポートを提供するのに必要な全てのサプライヤデータベースへのアクセスを提供する。製品情報データベース1080は、特徴、入手性、価格のような製品に関する全情報を記憶している。製品オーダーデータベース1090は、全ての顧客オーダーを記憶している。このデータベースへのインターフェースは、SAP、バーン、オラクル又は他社が提供するエンタープライズリソースプランニングアプリケーションを通すか、或いはサプライヤのウェブサーバー又はアプリケーションサーバーを通して直接アクセスできる。顧客情報データベース1091は、サプライヤが取引を完了させるか又は消費者の記録を維持するのに必要な、全ての顧客情報を記憶している。図10Bは、自己中心型インターフェース内でウェブページを作成するのに利用されるロジックを提供するフローチャートである。この環境は、ウェブサーバーとウェブブラウザとが、公衆インターネット又は専用インターネットを使うようなTCP/IPネットワークを通じて接続されていると仮定している。ウェブサーバーには、マイクロソフトインターネット情報サーバー、ネットスケープエンタープライズサーバー又はアパッチ等が含まれる。ウェブブラウザには、マイクロソフトインターネットエクスプローラ又はネットスケープナビゲータ等が含まれる。クライアント即ちウェブブラウザは、特定のウェブページに対してサーバー即ちウェブサーバーへ要求を作成する1001。これは、通常は、ユーザーがウェブページ内のボタン又はリンクをクリックすることにより行われる。ウェブサーバーは、クライアント即ちウェブブラウザ内に記憶されている独自のユーザーIDで開錠されるデータベース及びユーザープロファイルデータベース1003に要求することによって、その特定ユーザーのレイアウト及びコンテンツの嗜好1002を入手する。次にウェブサーバーは、コンテンツデータベース1005から要求されていたページの内容を検索する1004。次に、カレンダー、eメール、面会リスト及びタスクリスト項目のような関連のあるユーザー中心コンテンツが検索される1006。このプロセスの更に詳細な説明については図11を参照されたい。データベースへの問い合わせは、ユーザープロファイルデータベース1003内のユーザープロファイルの一部分として記憶されているユーザーコンテンツ嗜好を利用し、戻されるコンテンツにフィルタを掛ける。戻されるコンテンツは、ユーザープロファイルに定義されているレイアウトの嗜好に従って、ウェブページ1007にフォーマットされる。次に、ウェブページはクライアントに戻され、ユーザーに表示される1008。図11は、ユーザー中心コンテンツを検索してウェブページに加えるプロセスを説明している。このプロセスは、図10Bの1006を更に詳細に示したものである。サーバーはユーザープロファイル及びこのページに統合されようとしている現存コンテンツを既に入手していると仮定している。サーバーは、例えばイベント、面会者名前及びeメールアドレスを検索しながら、フィルタを掛けられたコンテンツを構文解析する1110。これらの何れかが見つかれば、タグ付けされて、一時的な保持スペース内に記憶される。次にサーバーは、様々なデータベース内に記憶されているあらゆるユーザー中心コンテンツを検索しようとする1120。これには、一時的保管場所内でタグ付けされた項目と、カレンダデータベース1140内のカレンダ項目1130、eメールデータベース1114内のeメール項目1115、面会データベース1168内の面会項目1117、タスクリストデータベース1118内のタスクリスト項目1119及びニュースデータベース1120内のニュース項目1121とのマッチングが含まれている。あらゆる関連ユーザー中心コンテンツを検索した後で、それは一緒にコンパイルされて、戻される1122。[ユーザーペルソナ]本システムは、ユーザーが、複数の異なるペルソナを作成し、プロファイル情報を異なるコンテクストで有用なセットにまとめることができるようにする。ユーザーは、自宅用の買い物をするとき1つのペルソナを作成することができる。このペルソナは彼の自宅の住所を含み、このユーザーが買い物をする時に買い得商品を探そうと閲覧しているということを示すかもしれない。同じユーザーが、仕事に入っている場合に用いることができる第2ペルソナを作成してもよい。このペルソナは、ユーザーの職場の住所を記憶し、ユーザーが、あるベンダーを好み、ディスカウントプログラムを備えている或る会社で働いていることを示すかもしれない。仕事関連のものを購入する際に、ユーザーは、このペルソナを用いるであろう。ペルソナは、ルール及び制限を含んでいてもよい。例えば、仕事ペルソナは、ユーザーが、1つの旅行エージェントだけを使って航空券の予約を取ること、及び雇用者によって設定されている予約ルールを使うこと等の制限してもよい。図12は、ユーザー、ユーザーの複数のペルソナ、及びユーザーの複数のプロファイルとの間の関係を示している。ユーザープロファイル1200は、ユーザーレベルにある。このプロファイルは、ユーザー及びユーザーの口座に関する情報を記述している。口座を有する各ユーザーに対して、データベース内に1つの固有の記録がある。複数のペルソナ1220、1230、1240が、各ユーザーに接続されている。これらのペルソナは、複数のプロファイルを有用なコンテクストへ分類するのに用いられる。例えば、サンフランシスコに住んで、パロアルトで働いているが、タホー湖に山小屋を所有しているユーザーについて考えてみる。彼は、自分のサイトにアクセスできる3つの異なるコンテクストを有する。1つのコンテクストは仕事関係である。他の2つは家庭生活に関係しているが異なるロケーションにある。ユーザーは、仕事のためのペルソナ1220と、家庭のためのペルソナ1230と、山小屋での生活のためのペルソナ1240とを作成することができる。各ペルソナは、異なる全般プロファイル1250、1260及び1270を参照し、それはそれぞれそのロケーションのアドレスを含んでいる。従って、3つの全般プロファイルがある。更に、各ペルソナは、2つの旅行プロファイルの内の1つを参照する。ユーザーは、チケット予約や予約の取り付けに関する全ビジネスルールを含む仕事旅行プロファイル1280を維持している。このプロファイルは、例えば、この人はビジネス又はファーストクラスでしか旅行せず、愛用の航空会社はユナイテッド航空であるということを示しているかもしれない。仕事ペルソナは、この仕事旅行プロファイルを参照する。ユーザーは更に、家族旅行プロファイル1290を維持しており、列車の普通席で旅行することが好きであり、一般的に安いので、払い戻しなしの料金のものを探していることを示しているかもしれない。家庭のためのペルソナと山小屋生活のためのペルソナとの両方が家族旅行プロファイルを指している。図13は、ペルソナの概念をサポートするデータモデルを示している。ユーザーテーブル1310は、システム内に口座を有する各ユーザーの記録を含んでいる。このテーブルは、独自の識別子並びにユーザーネーム及びパスワード1320を含んでいる。各ユーザーは、複数のペルソナ1330を有することができ、複数のペルソナは、プロファイル1340と呼ばれる更に専門化された構造に関するコンテナとして作用する。プロファイルは、プロファイルフィールド1350の記録として、詳細な個人情報を含んでいる。各プロファイルには、プロファイル制限1360記録のセットが付けられている。これらのそれぞれが、ネーム1370及びルール1380を含み、制限を定義している。ルールは、ルールをある用途に制限できるxならyのようなパターンの形式である。例えばプロファイル制限は、ユーザーがリスト内に含まれている或る航空会社のフライトを予約してはならないと指図するルールであるかもしれない。このプロファイル制限が、例えばユーザーの雇用者により設定された仕事ペルソナの旅行プロファイル内に含まれることもある。各プロファイルフィールドは、更に、その記録に含まれている許可セット1390を含んでいる。これらの許可は、誰が、特定のプロファイルフィールド情報にどんなアクセス権を有するかを指定する。[意向中心型インターフェース]退職又は移住に関する計画のような顧客の意向を満たすには、専門的なインターフェースが必要である。顧客の意向は、経済保証、住まい、輸送から、特に健康管理、個人的及び専門的自己啓発、娯楽に至る広範な領域に亘る計画と調整を必要とする。意向を満たすには、消費者のニーズに合わせて、複数の産業に亘り働く補完的ビジネスのネットワークが必要である。意向中心型インターフェースは、ユーザーが個人の意向を上手く管理するのを助けるように設計されているユーザーインターフェースである。所与の何れのポイントにおいても、インターフェースのコンテンツは、特定の意向に関するコンテンツだけを示すようにカスタマイズされる。意向中心型インターフェースは、ユーザーが、その特定の意向を満たすプロセスを上手く管理できるようにする。このことには、一連の独立したステップとユーザーがアクセスできる一式のコンテンツ領域とが含まれている。何れのポイントにおいても、ユーザーは、インターフェースを切り替えて、異なる意向を管理することができ、この行為は、新しく選択された意向の充足に関わるコンテンツだけを含むように、インターフェースのコンテンツを変更することになる。図14は、意向中心型インターフェースをサポートするのに必要なデータモデルを詳細に説明している。各ユーザーのペルソナ1410ペルソナのデータモデルの更に詳細な説明については図13を参照は、幾つかの稼動中のユーザーの意向1420を有する。各稼動中のユーザー意向には、ニックネーム1430が与えられて、それが、ユーザーがスクリーン上で見る表示ネームである。各稼動中のユーザー意向は、更に、ユーザーとの対話を通じて収集されたあらゆるユーザーデータを含む複数のデータフィールド1440を含んでいる。例えば、ユーザーがスクリーン上の書類に記入済みで、フィールドの1つが社会保障番号であった場合、対応するデータフィールドには、ネーム=SSN1450、値=999-99-99991460が含まれることになる。更に各ユーザーの意向は、意向ステップ1470の完了状況の軌跡を保存する。完了1480のフィールドは、ユーザーがステップを完了しているかどうかを示す。全ユーザー意向は、全般的意向1490のユーザー特定バージョンであり、全てのユーザーに関するその意向に対するデフォルトモデルである。全般的意向は、意向内のサブステップに取り付けられているカスタムルール1411及び1412を通してカスタマイズされる。これらのカスタムルールは、個々のユーザーのプロファイル情報を使って、各ユーザー毎に、システムがどのように意向をカスタマイズするかを記述するパターンである。[統計エージェント]エージェントは、各ユーザー毎に、キーとなる統計の軌跡を保存する。これらの統計は、タマゴッチバーチャルリアリティのペットトイと同様の方法で用いられ、ユーザーからの或る行動を助長する。記録されている統計は、一定の期間内に実行されたタスク数で測定されるロジックの頻度、ニュース記事のようなコンテンツのレーティングの頻度、及びエージェントのアクティビティである。システムはこの情報を用いて、或る行動を喚起させるようにユーザーに感情的にアピールする。図15は、エージェントの現在の統計を表すページを作成するためのプロセスを示している。ユーザーがクライアントブラウザを使ってエージェント統計ページを要求する1510と、サーバーは、ユーザーのプロファイルデータベース1530からユーザーの統計を検索する1520。サーバーは次に、必要な数学演算を実行して、正規化された一式の統計を作成する1540。次にサーバーは、ユーザー中心型統計を計算するのに用いられるコンテンツデータベース1560から公式を検索する1550。次に、一般的な公式及びそのユーザーの統計を使ってグラフが作成される1570。これらのグラフがテンプレートに挿入され、統計ページが作成される1580。次に、このページはユーザーに戻される1590。[個人向け製品レポートサービス]本システムは、ユーザープロファイルに基づいてユーザー毎にカスタマイズされた消費者レポートのようなサービスを提供する。システムは、様々な面から製品の品質及び好感度に関する、ユーザーからのランク付けを記録して提供する。このシステムと伝統的な製品品質測定サービスとの相違点は、ユーザーに戻ってくるランク付けが各個人に合わせられているという点である。このサービスは、ユーザーのプロファイルに最もマッチし、且つ問い合わされた製品を先にランク付けした人を検索することにより行われる。このアルゴリズムを使えば、ユーザーに送り返される製品レポートが、確実に、そのユーザーに似ている人からの統計だけを含むようにすることができる。図16は、ユーザーのための個人向け製品ランク付けを決定するためのアルゴリズムを表している。ユーザーが製品Xの製品レポートを要求する1610と、アルゴリズムは、その製品を先にランク付けしたユーザーの製品のランク付けを含むプロファイルデータベース1630からプロファイルを検索する1620。次に、システムは、コンテンツデータベース1650から、プロファイルマッチングアルゴリズムに対するデフォルト閾値を検索する1640。次に、システムは、プロファイルマッチングアルゴリズムに指定された幾つかの項目に沿って、ユーザーの全ショートリストをマップする1660。次に、最も近くにあるn個閾値変数として先に指定されているが選ばれ、それらが、セット内のユーザープロファイルの距離y内同じく、閾値変数として先に指定されているにあるかどうか判断する1670ため、プロファイルマッチングアルゴリズムからの結果を使ってテストが行なわれる。それらが閾値内にない場合、閾値変数は緩められ1680、もう一度テストが実施される。このプロセスは、テストが真を戻すまで繰り返される。次に、n個の最も近いものの小セットからの製品のランク付けは、幾つかの項目に沿って複数の製品統計を判断するのに用いられる。これらの統計は、製品レポートテンプレートに挿入され1695、製品レポートとしてユーザーに戻される1697。[個人プロファイル及びサービスの遍在]このシステムは、1人のプロファイルに1つの中央記憶場所を提供する。この記憶場所は、公衆インターネットを通して入手できるサーバーであり、インターネットに接続されており、適切なアクセスを有していれば、どんな装置でもアクセス可能である。プロファイルのアクセス可能性が遍在しているので、ユーザーのプロファイルに基づいてそのユーザー用にサービスをカスタマイズするには、多数のアクセス装置を用いることができる。例えば、商人のウェブサイトは、このプロファイルを利用して個人向けのコンテンツをユーザーに提供することができる。インターネットアクセスを備えたパーソナルデジタルアシスタントPDAは、インターネットサイト内に記憶されているバージョンを使って、個人のカレンダー、eメール、面会リスト、タスクリスト及びノートをPDA上で同期させることができる。このことにより、個人は、このデータの1つのバージョンだけを維持しておけば、必要なときはいつでも、且つ必要ならばどんなフォーマットででも、それを入手できるようになる。図17は、この集中的に記憶されているプロファイルにアクセスするための多くの異なる方法に関連する詳細なロジックを示している。プロファイルデータベース1710は、ユーザーのプロファイル情報の中央記憶場所である。プロファイルゲートウェイサーバー1720は、プロファイル情報に関する全要求を、ユーザー自身からであれ、サービスをユーザーに提供しようと試みている商人からであれ受信する。プロファイルゲートウェイサーバーは、プロファイル所有者が特別に許可を認めた場合にだけ、情報が与えられることを保証することに責任を負っている。TCP/IP標準的ネットワーク通信プロトコルを通して公衆インターネット1730にアクセスできる装置は全て、インテリジェントなHTTPの要求を通して、プロファイルデータベースからの情報を要求できる。消費者は、テレビ、携帯電話、スマートカード、ガスメータ、水道メータ、台所の設備、セキュリティシステム、デスクトップコンピュータ、ラツプトップコンピュータ、ポケットオーガナイザ、PDA及び自動車などの装置から、サービスへアクセスすることができる。同様に、商人1750は各プロファイルを所有する消費者から許可があればこれらのプロファイルにアクセスすることが可能であり、これによって、消費者にカスタマイズされた個人向けサービスを提供することができる。遍在プロファイルに関して可能な利用法の1つは、ホテルのチェーンである。消費者は、自身を独自に識別するデジタル証書を保持するスマートカードを携帯できる。このスマートカードのデジタル証書は、システムによって発行されており、自身のプロファイル情報をプロファイルデータベースへ記録している。消費者は、このカードをホテルのチェーンに入れてチェックインする。ホテルの従業員は、スマートカードを読み取り機に通し、消費者はピン番号を打ち込み、デジタル証書を開錠する。証書は安全な送信プロトコルを使ってプロファイルゲートウェイサーバーに送られ、正しいと証明される。次にホテルには、先に指定されている消費者プロファイルの或る部分へのアクセスが与えられる。次にホテルは、ホテルルームの好み、並びに消費者の勘定情報全てを検索することができる。ホテルは、消費者の映画及び食事の好みにもアクセスすることができるので、その両方に関してカスタマイズされたメニューを提案できる。ホテルは、eメールを消費者の配偶者へ送り、その人がホテルにチェックインし、安全であることを相手に知らせることもできる。ホテルは彼がチェックインした後で、全取引情報を消費者のプロファイルへアップロードすることができる。このことにより、ホテルのパートナーは再度、消費者の許可が与えられればホテルが集めた消費者に関する情報を利用できるようになる。[インテンションバリューネットワーク]インテンションバリューネットワークでは、全体インテグレイタシステムが製品及びサービスのユーザーへの配信を調整する。インテグレイタは、ユーザーのプロファイル内に反映されているユーザーの好みに基づいて、物理的及び抽象的な製品及びサービスをユーザーへ提供する承認されたサプライヤのネットワークを管理する。インテグレイタは、サプライヤと消費者との関係を管理し、サプライヤが消費者の意向を満たすように調整する。インテグレイタは、消費者に製品及びサプライヤについての情報を提供し、とりわけ客観的なアドバイスを提供することにより、これを行う。図18は、消費者と1つのサプライヤを含むインテグレイタとの間の対話を詳細に開示している。ユーザーはウェブブラウザ1810にアクセスし、インテグレイタからの製品及び価格情報を要求する。要求は、ユーザーのブラウザからインテグレイタのウェブ/アプリケーションサーバー1820へ送られる。ユーザーの好み及び個人情報は、インテグレイタの顧客プロファイルデータベース1830から入手され、ウェブ/アプリケーションサーバーへ戻される。要求されている製品情報は、サプライヤの製品データベース1840から検索され、特定の顧客のためにカスタマイズされる。ウェブ/アプリケーションサーバーは、顧客に関する問い合わせ情報を使って、サプライヤの顧客情報データベース1850を更新する。次に、製品及び価格情報は、ウェブページ1860にフォーマットされ、顧客のウェブブラウザへ戻される。[要約エージェント]アプリケーション及びウェブサーバー上で実行されている一式のソフトウェアエージェントは、ユーザーの繰り返しの又はありきたりなタスクを引き受けるためにプログラムされている。エージェントは、ユーザーにより設定されたルールに従って働き、ユーザーにより明らかに定義されているタスクを実行することだけが許されている。エージェントは、ユーザーの請求書の支払いと、コンテンツ及びeメールのフィルタリングと、タスク及びエージェント活動の要約ビューへの提供とを引き受けることができる。エージェントに対するユーザーインターフェースは、特定のユーザーに適するように修正することができる。図19は、ユーザーに対し言葉による要約を作成するために、エージェントにより処理される、好適な実施例によるロジックを開示している。ユーザーが要約ページを要求する1900と、サーバーは、ユーザープロファイルデータベース1930から、エージェントタイプ、ルール及び要約レベルのようなユーザーのエージェントの好みを取得する1920。サーバーは、eメール、予定事項、ニュース、請求書のようなコンテンツ1940をコンテンツデータベース1950から入手する。エージェントは、プロファイルデータベース内に記憶されているルールを使ってこのコンテンツ全てを解析し、コンテンツを要約する1960。コンテンツは、テンプレートに従ってウェブページにフォーマットされる1970。コンテンツデータベース1990からのコンテンツと、データベース内に記憶されている音声テンプレートとを使って、エージェントの音声に関するテキストが生成される1980。この音声テキストが、ウェブページに挿入され1995、ページがユーザーに戻される1997。[信用サードパーティ]上記のシナリオは、ウェブサイトに、発行されたポリシーに従って情報のプライバシーの保証を維持することを要求する。このシステムは顧客の信用サードパーティであり、商業的機会を鼓舞するというよりも情報のプライバシーを失するような全ケースおいて、顧客に代わって活動する。信用サードパーティは、適所に、告知されたポリシーとの整合性を保証する一式のプロセスを有する。[meCommerce]この用語はeコマースという用語を個人向け電子コマースという意味に拡張している。図20は、好適な実施例によるディスプレイロジックを示している。ディスプレイは、情報を収集し、ユーザーの個人的な要件について対話するために、システムとの対話のプロセスを通じてユーザーをカスタマイズされ個人向けに処理された様々なシステムコンポーネントにガイドするエージェント2000によって、マイクロソフトインターネットエクスプローラアプリケーションとして実行される。ユーザーは2010でユーザーネームを入力し、2020でパスワードを入力し、ボタンを選択する2040と、ログイン手続きが開始される。ロゴ2030が示唆するように、システムは電子コマースを個人向けの、いわゆるmeコマースへ変換する。図21は、好適な実施例による、毎日のロジスティックを管理するディスプレイを示している。ユーザーは、個人向けメッセージ2190を有するアニメエージェントによる挨拶を受ける2100。ユーザーは、要件に基づいて、旅行2110、家庭の雑用2120、経済2130及び市場の動向2140を含む様々な活動から選択できる。又、eメール、カレンダリング及び書類準備などの日課のアイコン2142が、1つの作業から別の作業への迅速なナビゲーションが容易になるように設けられている。更に、ニュース及び関心のある他の項目を送信できるように、ダイレクトリンク2146が設けられている。ユーザーが置かれている場所に基づいて、様々なプロファイルを選択することができる。例えば、仕事、家庭又は休暇である。ユーザーが他の場所用の新しいプロファイルを要求する場合は、そのプロファイルを加えることができる。様々な努力をサポートするために、個人情報の様々な項目2180が、ユーザーから収集される。更に、情報がタイムリーで最新であることを保証するために、許可2150が項目2180に対して設定されている。図22は、好適な実施例によるユーザーのメインディスプレイを示している。世界のニュース2220及びローカルニュース2210が、ユーザーの好みに基づいて提供される。ユーザーは、更に、メインディスプレイに直に情報を提供する項目として、不動産2230も選択している。更に、異なるエージェント2220は、ユーザーの好みに基づいて提供される。図23は、好適な実施例によるエージェントの対話を示している。エージェント2310は、情報2300をユーザーに連絡して、ユーザーの生命保険は変更が必要なことを示し、ユーザーに、ユーザーのための情報を最適に要約しているチャートを指し示している。現在のユーザーの統計に基づくより詳細な情報が使い易くなるよう、特別な情報2395が提供されている。更に、ユーザーの生命保険の必要性に関するチャート2370は、ディスプレイの中央で目立つように表示されており、ユーザーが適切な行為を決定するのを支援する。ボタン2380は、ポリシーの変更を容易にするために提供されており、一式のボタン2390は、ユーザーの保険要件の様々な視点を選択する際にユーザーを支援するために設けられている。[イベントバックグラウンダ]イベントバックグラウンダとは、イベントの直前にユーザーに送られてくる、来るべきイベントの短い説明である。イベントバックグラウンダは、このイベントに関する最新の情報により定期的に更新される。旅程及び宿舎のような適切な情報が含まれており、他にも、その場所にいるはずのユーザーの知人のような有用な情報も含まれている。イベントバックグラウンダの目的は、イベントに関する最新情報を、公衆ウェブサイトや、ユーザーのカレンダ及び面会リストのような多数のリソースから引き出して提供し、ユーザーが、所与の状況において最適に反応することができるようにすることである。[周辺フレンドファインダ]このソフトウェアは、友人、家族又は知人がユーザーの近くに居るか又は来る予定になっている場合に、ユーザーに通知する機会を探すものである。このソフトウェアは来るべきイベントを探してユーザーのカレンダを走査する。次にこのソフトウェアは、地図マップを使ってこれらのカレンダのイベントをユーザーの面会リストに登録されている人のカレンダイベントと比較する。次にこのソフトウェアは、照合をユーザーに通知し、特定の時にユーザーの近くに誰かがいる予定であることを告げる。[情報オーバーロード]情報オーバーロードという用語は、今では、その示唆するもの及び結果、並びに定義の両方において比較的よく理解されている。人々の、一時に使える注意量には限界があるが、その注意を要するものは日々増大している。つまり、過剰な情報と少な過ぎる時間が、現代の最高の知識人の生活を混乱させている主な要因である。情報オーバーロードをダイナミックに扱うための最初の試みは、焦点が主に、情報量を減らすというような情報の知的なフィルタリングに置かれていた。しかし、これらのアプローチのほとんどは、単に情報ビットをランダムに取り除くのではなく、どんな情報が最終的にユーザーに示されるかということについて知ろうと努力した。これは、ユーザーの関心事に基づいて各書類を評価し、相当しないものは破棄することにより達成された。そのため、情報の質も高められた。情報のフィルタリングは、単に、この新しい時代の情報を扱う第1ステップである。一度ミーティングに入ったら、事前にオフィスに届けられた、ミーティングの主題に関する重要な情報を含んだ書類など価値がない。ビジネスのスピードは、相互接続の技術によって加速され続けるので、どんなときでも、どんな場所でも質の高い情報を受信する能力が重要になる。この新しいアプローチは、知的情報配信と呼ばれ、新しい情報時代の先駆けである。好適な実施例は、情報のオーバーロードを減らすだけでなく、ユーザーが必要とすればどこでもいつでも高品質の情報を配信するという試みの中で、上記の知的情報配信のセオリーを示している。言い換えれば、本システムは、正しい情報を、正しいユーザーに、正しい時間に、正しい場所で配信する。アクティブナレッジマネジメントシステムの説明図24は、好適な実施例によるアクティブナレッジマネジメントシステムのブロック図である。システムは、1つ又は複数のサーバーに接続されているバックエンド2400、個人の携帯無線クライアントアウェアネスマシン2430、2436、公衆クライアントマジックウォール2410、2420、ウェブクライアント2446、2448、eメールクライアント2450、2460から構成される。バックエンドサーバー2400プロセス図25は、好適な実施例によるバックエンドサーバーのブロック図である。バックエンド図24の2400は、次のソフトウェア、即ち、知的エージェントコーディネータMunin2580、情報優先順位付けサブシステム2530、継続的且つ定期的に実行される情報を集めて処理する一式の知的エージェント2500、2502、2504、ユーザープロファイルデータベース2542及び支援ソフトウェア、情報チャネルデータベース2540及び支援ソフトウェア、通信ソフトウェア2550、情報転送ソフトウェア2560、補助ソフトウェアが稼動するコンピュータシステムである。アウェアネスマシン図24の2446、2448アウェアネスマシンは、ハードウェア装置とソフトウェアアプリケーションの組み合わせである。ハードウェアは、ハンドヘルドパーソナルコンピュータと無線通信装置とから構成される。アウェアネスマシンは、少量づつの無線情報を継続して受信することにより、定期的に更新されるステートオブオーナーズワールドを反映する。一式の知的エージェントにより発掘され、処理されたこの情報は、メールメッセージ、各ユーザーの好みに合ったニュース、スケジュール更新、次のミーティング及びイベントのバックグランド情報、並びに天気及び交通から構成される。アウェアネスマシンは別の特許アプリケーションでカバーされている。図26は、好適な実施例によるマジックウォールのブロック図である。マジックウォールマジックウォールハードウェアには、以下のものが含まれる。バックエンドサーバーに接続されているコンピュータシステム2640存在、位置及び個人のアイデンティティを検知するセンサーアレイ2634、2630及び2632大きなタッチセンシティブディスプレイ2620音声入力2610/出力2614ハードウェアマジックウォールソフトウェアは、以下をサポートする。現在のウェブ標準と互換性のあるマルチメディア音声認識タッチ入力音声使用可能なアニメキャラクターの形態をした知的エージェント表示マジックウォールは、以下のように作動する。1.ユーザーがマジックウォールの周辺に現れると、センサーアレイは、個人のID及び位置を含む環境キューを知的エージェントコーディネータへ送るユーザーがここにいるイベントをトリガする。2.ユーザーは、センサーアレイにより戻される情報に基づいて識別される。3.マジックウォールはユーザーにロックモードに切り替える。別のユーザーがアプローチすれば、システムはそのユーザーに、現在のユーザーにサービスする間は別のユーザーにサービスできないことを通知する。4.知的エージェントコーディネータには、ユーザーの存在が通知される。5.知的エージェントコーディネータは、そのユーザーとマジックウォール位置に適した、提示すべき時間感受性情報例えば、交通レポート、ミーティングの催促があるかどうかを判断する。そのような情報が存在する場合は、配信に向けて準備される。存在しない場合は、コントロールが情報優先順位付けサブシステムへ送られる。6.情報優先順位付けサブシステムは、個人プロファイル、情報の新鮮度及び知的エージェントコーディネータの前の指示に基づいて、そのユーザーに最適な情報が何かを判断する。7.その時と場所で、そのユーザーに最適であると識別された情報のページが示される。情報配信の行為には、知的エージェント表示のアニメーション及び音声の出力を含めることもできる。8.ユーザーが望めば、ユーザーは、特定のページを示すことをマジックウォールに求めることができる。マジックウォールは音声の断片を認識し、要求されたページを識別して示す。9.ユーザーがマジックウォール領域から離れると、センサーアレイはユーザー離脱イベントをトリガする。10.マジックウォールは、待ち状態へ戻る。他のクライアントウェブのクライアントは、ユーザーがマジックウォールを通して入手可能な同一の情報を見ることができるウェブページのセットへナビゲートする標準的ブラウザである。eメールックライアントは、何れかの標準的eメールプログラムである。知的エージェントコーディネータの説明このコードは、アクティブナレッジマネジメントシステム用のコーディネートエージェント又はメタエージェントである。このことは、異なる下位エージェント間での通信同様、システムと各ユーザーの間の全通信が、知的エージェントコーディネータにより操作されるコーディネートされることを意味する。これらの下位エージェントの例は以下の通りである。バックグランドファインダー:ミーティングのテキストを、重要なキーワード及びフレーズを判断しながら構文解析し、各ユーザー毎にミーティングに関するバックグランド情報を見つけだすエージェント。交通ファインダー:ユーザーが居る場所に基づいて、各ユーザー毎に交通情報を見つけだすエージェント。各ユーザーのプロファイル内のデータの統計分析を行い、そのデータに関係するフィールドを更新することに責任を持つ別の幾つかのエージェント。図25の知的エージェントコーディネータ2580は、ユーザーのシステムへのインターフェースであり、ユーザーがそれを使ってシステムと対話する場合はいつでも、GUIか、又は別のエンドユーザーのインターフェースであるかにかかわらず、ユーザーは、最終的に知的エージェントコーディネータを取り扱っている質問をするか又は指令を送ることになる。知的エージェントコーディネータは、1ユーザーの活動をモニタする、2情報要求を取り扱う、3各ユーザーのプロファイルを維持する、4ユーザーから他の各エージェントへの情報、及びその逆の情報を送る、という4つの主要な責任を負っている。ユーザーの活動をモニタするユーザーがセンサーをトリガするときはいつでも、知的エージェントコーディネータが環境キューを受信する。これらのキューにより、知的エージェントコーディネータは、情報を配信するためにユーザーがいる場所を理解するだけでなく、各個人の生活の標準パターン到着時間、出発時間などを学習できる。これらのパターンは、情報を配信する際のシステムの知性を高める意図で、継続して更新され、リファインされる。例えば、今日では、1個人が、複数のeメール口座仕事ベース、家庭ベース、携帯ベースなど並びにそれらの全口座に関する検索プロセス内に含まれる複数の異なるコンピュータを有するのも珍しくない。従って、知的エージェントコーディネータが情報を正しい位置に配信することに成功するには、ユーザーが情報を見る確率を最大にするために、それらの全口座、及びユーザーがそれらにアクセスするであろう時間を考慮に入れなければならない。このことは、別のセクションで更に議論することにする。情報要求を操作する知的エージェントコーディネータは、各ユーザー毎に意図された情報を個人向けにし、各ユーザーの関心事を与えられた情報に正確に反映させるために、別のエージェントからの情報要求を操作する。これらの要求は、一般的にユーザープロファイルに関係する。例えば、あるエージェントが或るユーザーに交通レポートを準備していた場合、知的エージェントコーディネータからの、そのユーザーの交通地域探索文字列を要求してもよい。ユーザーのプロファイルデータへの全てのアクセスは、この方法でアクセスされる。ユーザープロファイルを維持するユーザープロファイルは、ユーザーに関する幅広い情報を含んでいる。この情報は、ユーザー指定データと、知的エージェントコーディネータが、各ユーザーの情報及び活動から学習し、推察した情報とを混ぜ合わせたものである。プロファイル内に含まれるデータを保護するために、知的エージェントコーディネータは、全ユーザー情報要求を扱わなければならない。知的エージェントコーディネータは、より多くの日常的雑用において支援を行うために、ユーザーの活動を観察し、彼らの生活のパターンを学習しようと努力することにより、これらのプロファイルを継続して修正、更新している。知的エージェントコーディネータは、更に、別のエージェントを使って、各ユーザーの日々の活動から意味を拾い集める。これらのエージェントは、このデータを掘り起こし、各タイプの情報の定時配信に関する好み、並びに現在の関心事、長期的な関心事を発見しようと努めている。知的エージェントコーディネータの観察の別の重要な態様は、経路付けのために、各ユーザーが1日を通して居る物理的な場所を求めようというものである。情報経路指定多くの人は、一日中動いている。知的エージェントコーディネータは、観察指示されていない学習及び環境からのキューの両方によって、ユーザーがいる場所又は行きそうな場所を判断しようと試みることにより、この事実に敏感であろうとしている。このことは、ユーザーの情報を送る場所を決めるだけでなく、情報を送るフォーマットを決めるのに、確かに重要である。例えば、ユーザーが自分のデスクにいてウェブクライアントを使っている場合、知的エージェントコーディネータは、ユーザーのPCから作業に関する指示を受け取っているであろうし、そこに送るべき必要な情報を全て知っているであろう。更に、デスクトップPCは一般的に非常にパワフルであるので、十分に特徴のあるグラフィカルな強力バージョンを送ることができる。しかし、別の状況、即ち、知的エージェントコーディネータが、あなたがビルを離れたという表示を出口の隣のキーカードリーダーを経由して受信したという状況を考えてみよう。知的エージェントコーディネータが、数分後に、あなたが緊急メッセージを受け取ったという通知を受信したとする。知的エージェントコーディネータは、あなたがビルを離れたことを知ってはいるが他の指示を受取っていなければ、あなたには、あなたのハンドヘルド装置能力についてはわかっているを通して連絡可能であると仮定し、グラフィカル指向バージョンではない緊急メッセージのテキストをハンドヘルド装置へと送ることになる。固有の革新アクティブナレッジマネジメントシステムは、ナレッジマネジメント及び人間とコンピュータの対話の世界における、最も進んだ考案の幾つかを示す。主な革新には、以下のものが含まれる。上記に示されている知的エージェントコーディネータ。知的情報配信に関するセオリーの開発、実演及び理解。情報を配信する幾つかのチャネルへのサポートであり、それらのすべては、共通のバックエンドを利用する。例えば、ユーザーがマジックウォールの前にいれば、情報はマルチメディアリッチフォームで示される。システムが、ユーザーは移動中であると判断すれば、情報は標準テキストでアウェアネスマシンへ送られる。そのことにより、いつでもどこでもユーザーが情報を要求すれば、情報が容易に配信されるようになる。静的ユーザープロファイルに基づくばかりでなく、ユーザーの対話の履歴、及び誰、何処、何時という認識を含む現時点のリアルタイムな状況も考慮することによる、情報の個人化。知的エージェントコーディネータの意見、ユーザーの好み及びユーザーの対話の履歴を考慮した、迅速且つスケーラブルな情報優先順位付けサブシステムの利用。これにより、ありきたりの判断に関するロードが知的エージェントの部分から取り去られるので、エージェントが、システムのスケーラビリティを損なうことなく、更に洗練されて正確になる。音声認識及び音声合成を知的エージェントのアニメ化された表示及びタッチ入力と組み合わせると、システムとの能率的、直感的及び感情的に価値のある対話が提供される。[好適な実施例によるサポーティングコード]次のコードは、好適な実施例によるマイクロソフトアクティブサーバーページ環境に書き込みされ、実行される。これは、主にマイクロソフトJスクリプトから成り、情報を問い合わせして、データベース内に記憶するために、複数のデータベース呼び出しがコード内に埋め込まれている。意向中心型インターフェース以上、様々な実施例を述べてきたが、それらは例として示したのであって、限定を加えるものではないことは理解頂けるであろう。従って、好適な実施の形態の幅及び範囲は、上記の実施例の何れにも限定されるものではなく、上記請求の範囲及びそれらと同等なものに従って限定されるべきである。"