JP6067066B2 - 情報をユーザに送る方法、コンピュータ読み取り可能な記録媒体、および情報収集方法 - Google Patents

Description

本発明は、エージェントベースのシステム、より厳密には、来るべきイベントのバックグラウンド情報を自動的に創作するエージェントベースのシステムに関する。

エージェントベースの技術は、様々なコンピュータベースのタスクをフォアグラウンド又はバックグラウンドモードで行なうためユーザーと対話するように設計されているアプリケーションで使用するのに、益々重要になってきている。エージェントソフトウェアは、ユーザーに代わりルーチン即ちうんざりするほど時間を費やすタスクを実行するようセットされているコンピュータプログラムを備えている。各ユーザーにとって有用であるためには、エージェントは個々のユーザーの目的、習慣、及び嗜好に個別対応していかなければならない。このようなわけで、エージェントには基本的に、効率的且つ効果的に当該ユーザーに由来するユーザー特有の知識を身に付け、それを利用してユーザーに代わってタスクを行なう必要がある。

エージェンシー即ちエージェントの使用者というコンセプトは、十分に確立されている。エージェントは、通常、本人と呼ばれる別の人物により許可された人物であり、その本人に代わって行動する。このようにして、本人は、本人がやりたくない又は行なえないタスク全てを行なう権限をエージェントに与える。例えば、保険エージェントであれば本人に求められる保険に必要な事柄全てを取り仕切り、タレントエージェントであれば演技者に代わりコンサートの日取りの段取りをするために行動することになる。

コンピュータの到来と共に、エージェント雇用の新しい領域が到来した。エクスパートシステムという領域における著しい進歩により、コンピュータユーザーに代わって、コンピュータプログラムにルーチン即ちわずらわしい時間のかかるタスクを行なわせることができるようになった。これらのコンピュータプログラムは「ソフトウェアエージェント」と呼ばれる。

加えて、最近はコンピュータ及びコミュニケーションネットワークが著しく増加してきた。これらのネットワークは、ユーザーが膨大な量の情報及びサービスに実質的に地理上の境界線なしにアクセスできるようにしている。こうして、ソフトウェアエージェントは、ユーザーに代わって多数のタスクを行なう恵まれた環境を有している。例えば、今ではエージェントは、飛行機を予約し、チケットを購入し、ユーザーに直接チケットが配達されるようにすることができる。同様に、エージェントはインターネットを走査し、最新のスポーツ又はニュースから応用物理学の特定の学士論文までを網羅する情報を得ることができる。現在のソリューションでは、エージェント技術を現行のカレンダ技術に活用して、ユーザーの来るべきイベントを目指してバックグラウンド情報を取得することはできない。

本発明の好適な実施例の包括的な態様によれば、エージェントベースのシステムは、個人が各種ソースからミーティングについての関連情報を検索するのを助けることにより、彼／彼女が来るべきミーティングに備えることを支援する。システムは、ミーティングの日時を含んでいるカレンダプログラムから、目標ミーティングを表示する文字形式の入力テキストを入手する。ミーティングの日時が近づくと、カレンダプログラムは目標イベントのテキストを入手するために問い合わせを受け、その情報はエージェントシステムへの入力として利用される。そして、エージェントシステムは入力されたミーティングテキストを構文解析し、題目、本体、参加者、場所、時間などの各種要素を抽出する。システムは又、パターンマッチングを行って、ミーティングテキスト内の特定のミーティングフィールドを識別する。この情報を使ってウェブ上で各種情報源に問い合わせを行ない、そのミーティングについての関連記事を入手して、それをカレンダリングシステムに送り返す。例えば、ある個人が争議につき討論するためにネットスケープ及びマイクロソフトとミーティングを持つ場合、システムはこの最初の情報をカレンダリングシステムから入手する。システムは次にテキストを構文解析してミーティングの会社が「ネットスケープ」と「マイクロソフト」であり、議題が「争議」であると理解する。システムはここでこの議題に関する関連情報を求めてウェブをサーフィンする。このように、本発明の目的によれば、システムは目標ミーティングに備えて収集し得る最良の情報でカレンダリングシステムを更新し、結果としてユーザーにもそれら情報を与えることになる。好適な実施例によれば、情報はカレンダシステムに内蔵されたリンクからの選択を介して得られるファイルに記憶される。

好適な実施例による代表的なハードウェア環境を示すブロック図である。 好適な実施例によるシステムのフローチャートである。 好適な実施例によるシステムの構文解析ユニットのフローチャートである。 好適な実施例によるパターンマッチングを示すフローチャートである。 好適な実施例によるサーチユニットを示すフローチャートである。 好適な実施例によるシステムプロセシング全体を示すフローチャートである。 好適な実施例によるトピックプロセッシングのフローチャートである。 好適な実施例によるミーティングレコードプロセッシングのフローチャートである。 好適な実施例によるポケット・バーゲン・ファインダのプロセスフローを示すブロック線図である。 好適な実施例による、カスタマイズされたコンテンツ・ウェブページの製作に付帯するロジックを示すブロック図である。 好適な実施例による、カスタマイズされたコンテンツ・ウェブページの製作に付帯するロジックを示すフローチャートである。 好適な実施例による、ユーザー中心コンテンツの検索に付帯する詳細なロジックを示すフローチャートである。 好適な実施例によるユーザープロフィールのデータモデルを示す図である。 好適な実施例による個人データモデルを示す図である。 好適な実施例による意図データモデルを示す図である。 好適な実施例による、エージェントの現在の統計量を生成するためのプロセッシングを示すフローチャートである。 好適な実施例による、ユーザーのために個人化された製品格付けを判定するロジックを示すフローチャートである。 好適な実施例による、中央に記憶されたプロフィールにアクセスするためのロジックを示すフローチャートである。 好適な実施例による、特定のサプライヤに対するユーザーとインテグレイタの間の対話ロジックを示すフローチャートである。 好適な実施例による、言語要約を生成するためのエージェントプロセッシングを示すフローチャートである。 好適な実施例による表示ロジックを示す図である。 好適な実施例による、管理用デイリー・ロジステイック・ディスプレイを示す図である。 好適な実施例によるユーザーメイン・ディスプレイを示す図である。 好適な実施例によるエージェント対話ディスプレイを示す図である。 好適な実施例によるアクティブ知識管理システムを示すブロック線図である。 好適な実施例によるバックエンド・サーバを示すブロック線図である。 好適な実施例によるマジックウォールを示すブロック線図である。

上記及び他の目的、態様、及び利点は、図面を参照しながら、以下の本発明の好適な実施例の詳細な説明をお読みになれば明確に理解いただけるであろう。

本発明による好適な実施例は、ＩＢＭ互換パーソナルコンピュータ、アップルマッキントッシュコンピュータ、又はＵＮＩＸ（登録商標）ベースのワークステーション等のパーソナルコンピュータと関連付けて実用化されるのが好ましい。代表的なハードウェア環境を図１に示しているが、この図には、マイクロプロセッサのような中央演算処理装置１１０と、システムバス１１２を介して相互に接続されている他の多数の装置とを有する好適な実施例によるワークステーションの典型的なハードウェア構成を示している。図１に示すワークステーションは、ランダムアクセスメモリ（ＲＡＭ）１１４、読み出し専用メモリ（ＲＯＭ）１１６、ディスク記憶装置１２０のような周辺機器をバス１１２に接続するためのＩ／Ｏアダプタ１１８、キーボード１２４、マウス１２６、スピーカ１２８、マイクロフォン１３２、及び／又はタッチスクリーン（図示せず）のような他のユーザーインターフェース機器をバス１１２に接続するためのユーザーインターフェースアダプタ１２２、ワークステーションを通信ネットワーク（例、データプロセシング・ネットワーク）に接続するための通信アダプタ１３４、及びバス１１２をディスプレイ装置１３８に接続するためのディスプレイアダプタ１３６を含んでいる。ワークステーションには、通常、マイクロソフトウィンドウズ（登録商標）ＮＴ又はウィンドウズ／９５オペレーティングシステム、ＩＢＭ ＯＳ／２オペレーティングシステム、ＭＡＣ ＯＳ、又はＵＮＩＸオペレーティングシステムのようなオペレーティングシステム（ＯＳ）が常駐している。本発明が、上記以外のプラットフォームやオペレーティングシステムにもインプリメントできることは当業者には自明であろう。

好適な実施例は、Ｊａｖａ（登録商標）、Ｃ、及びＣ++言語を使って書かれ、オブジェクト指向プログラミング技法を用いている。オブジェクト指向プログラミング（ＯＯＰ）は、複雑なアプリケーションを開発するために益々広汎に使用されるようになってきている。ＯＯＰがソフトウェア設計と開発の主流となるにつれ、各種ソフトウェアソリューションにはＯＯＰの有益性を利用するために適合化が必要となってきた。ＯＯＰのこれら原理を電子メッセージングシステムのメッセージングインターフェースに適用して、メッセージングインターフェース用のＯＯＰクラスとオブジェクトのセットを提供できるようにする必要が生じている。

ＯＯＰはオブジェクトを使ってコンピュータソフトウェアを開発するプロセスであり、問題を分析する段階、システムを設計する段階、及びプログラムを構築する段階を含んでいる。オブジェクトは、データ及び関連構造と手続きの集合体の両方を保有しているソフトウェアパッケージである。データ及び関連構造と手続きの集合体の両方を保有しているので、オブジェクトは特定タスクを行なうために他に追加の構造体、手続き、又はデータを必要としない自己充実型コンポーネントとして見ることができる。ＯＯＰは、従ってコンピュータプログラムを広い範囲で独立したコンポーネントの集合体、即ちオブジェクトと捉えるが、その各々は特定のタスクに責任を持っている。データ、構造、及び手続きを１つのコンポーネント又はモジュールにまとめるパッケージングというコンセプトはカプセル化と呼ばれている。

一般的に、ＯＯＰコンポーネントは、オブジェクトモデルに合わせたインターフェースを表しコンポーネント統合アーキテクチャを介してランタイムでアクセスされる再使用可能なソフトウェアモジュールである。コンポーネント統合アーキテクチャは、異なるプロセススペースのソフトウェアモジュールが互いの能力又は機能を使えるようにするアーキテクチャ機構のセットである。これは一般的に、共通コンポーネントオブジェクトモデル上にアーキテクチャが構築されると想定することにより行われる。

この点でオブジェクトとオブジェクトのクラスを区別することに意味がある。１つのオブジェクトは複数のオブジェクトから成るクラスの１つのインスタンスであるが、単にクラスとだけ呼ばれることもある。複数のオブジェクトから成るクラスは、そこから多数のオブジェクトが形成されることになる青写真と捉えることができる。

ＯＯＰは、プログラマが別のオブジェクトの一部であるオブジェクトを製作できるようにする。例えば、ピストンエンジンを表すオブジェクトは、ピストンを表しているオブジェクトと合成関係を持つと言われる。現実には、ピストンエンジンはピストン、バルブ、及び他にも多数の構成要素を備えているが、ピストンはピストンエンジンの一要素であるという事実は論理的であると言えるし、ＯＯＰでは意味論上２つのオブジェクトにより表現される。

ＯＯＰは又、他のオブジェクトから「垂れ下がっている」オブジェクトを製作できるようにもしている。仮に２つのオブジェクトがあり、一方はピストンエンジンを表現し他方はピストンがセラミック製であるピストンエンジンを表現しているとすると、この２つのオブジェクトの関係は合成の関係とは言えない。セラミックのピストンエンジンがピストンエンジンを構成するわけではない。むしろそれは単に一種のピストンエンジンのことであり、そのピストンはセラミック製であるという、ピストンエンジンということ以外のもう１つ別の限定を有している。この場合、セラミック製のピストンエンジンを表現しているオブジェクトは派生オブジェクトと呼ばれ、ピストンエンジンを表現しているオブジェクトの態様を全て継承しそれに更なる限定又は詳細を追加している。セラミック製ピストンエンジンを表現しているオブジェクトはピストンエンジンを表現しているオブジェクト「から垂れ下っている」わけである。これらオブジェクトの間の関係は継承と呼ばれる。

セラミック製ピストンエンジンを表現しているオブジェクト又はクラスがピストンエンジンを表現しているオブジェクトの態様の全てを継承している場合、それはピストンエンジンクラスに定義されている標準ピストンの熱特性を継承している。しかしながら、セラミック製ピストンエンジンオブジェクトは、金属ピストンに関係する熱特性とは典型的に異なるこれらセラミックに特定した熱特性をオーバーライドする。それは元のものを抜かし、セラミックピストンに関係する新しい機能を用いる。別種のピストンエンジンは別の特性を有するが、それに付帯する同じ下層機能（例、エンジン内のピストンの数、点火シーケンサ、給油など）を有することになる。どのピストンエンジンオブジェクトであれこれら機能のそれぞれにアクセスするには、プログラマは同一名を持つ同一機能を呼び出すことになるが、各タイプのピストンエンジンは異なる／オーバーライドする機能のインプリメンテーションを同一名の裏に有することになる。ある機能の別のインプリメンテーションを同一名の裏に隠すというこの能力は多相性と呼ばれ、これによりオブジェクト間の通信は大幅に簡素化される。

合成関係、カプセル化、継承、及び多相性というコンセプトを用いると、１つのオブジェクトで現実世界の何もかもについて表現ができる。実際には、我々が感じる現実性の論理的認識は、オブジェクト指向型ソフトウェアのオブジェクトになり得る物の種類を判断する上での限定にすぎない。典型的なカテゴリーの幾つかを以下に示す。
・オブジェクトは、交通流シミュレーション内の自動車、回路設計プログラム内の電気的コンポーネント、経済学モデル内の国々、又は航空管制システム内の航空機のような物理的オブジェクトを表現できる。
・オブジェクトは、ウインドウズ、メニュー、又はグラフィックオブジェクトのようなコンピュータユーザー環境のエレメントを表現できる。
・あるオブジェクトは、職員ファイル又は都市の緯度及び経度を示す表などの目録を表現できる。
・あるオブジェクトは、時刻、角度、複素数、又は平面上の点などユーザーが定義したデータタイプを表現できる。
１つのオブジェクトが論理上分離可能なあらゆる物について表現するという非常に大きな能力を備えることにより、ＯＯＰは、現実が物理的エンティティ、プロセス、システム、或いは複合物の何れであろうと、ソフトウェア開発者が現実のある態様のモデルであるコンピュータプログラムを設計しインプリメントできるようにする。オブジェクトは何でも表現できるので、ソフトウェア開発者は将来的に大型ソフトウェアプロジェクトのコンポーネントとして使えるオブジェクトを製作できる。

新しいＯＯＰソフトウェアプログラムの９０％が、前もって存在している再使用可能なオブジェクトから作られた証明済みの現存コンポーネントから成るのであれば、残り１０％分の新しいソフトウェアプロジェクトを書き、スクラッチからテストを行なえばよいだけになる。既に９０％は広範にテストされた再使用可能なオブジェクトの目録から来ているので、エラーの元となる可能性のあるドメインはプログラムの１０％ということになる。結果として、ＯＯＰは、ソフトウェア開発者が他の即ち以前に構築されたオブジェクトからオブジェクトを構築できるようにする。

このプロセスは、アッセンブリ及びサブアッセンブリから構築されている複合機械に近似している。ＯＯＰ技術は、従って、ソフトウェアが開発者にとってオブジェクトとして利用可能な現行コンポーネントから構築される点において、ソフトウェアエンジニアリングをハードウェアエンジニアリングにより近づけるものである。これが全体としてソフトウェアの品質を向上させると同時にその開発の速度を上げることになる。

プログラミング言語は、カプセル化、継承、多相性、及び合成関係のようなＯＯＰ原理の完全なサポートを開始しつつある。Ｃ++言語の出現により、多数の市販ソフトウェア開発者はＯＯＰを歓迎している。Ｃ++は迅速且つ機械が実行可能なコードを提供するＯＯＰ言語である。更に、Ｃ++は市販アプリケーションとシステムプログラミングプロジェクトの双方に適している。今や、Ｃ++は数多くのＯＯＰプログラマの間で最も人気のある選定ということになるが、Ｓｍａｌｌｔａｌｋ、Ｃｏｍｍｏｎ Ｌｉｓｐ Ｏｂｊｅｃｔ Ｓｙｓｔｅｍ（ＣＬＯＳ）及びＥｉｆｆｅｌのように、他にもＯＯＰ言語のホストが存在する。加えて、ＯＯＰ能力はＰａｓｃａｌのようなより伝統的で大衆的なコンピュータプログラミング言語に付加されてきている。

オブジェクトクラスの有益性を要約すると以下の通りである。
・オブジェクト及びそれらに対応しているクラスは、複雑なプログラミング問題を砕いて多数のより小さく且つより単純な問題にする。
・カプセル化は、強制的に、データの編成を介して、データ抽象化を互いに通信し合える小型で独立したオブジェクトにする。カプセル化は、オブジェクト内のデータを不用意な損傷から保護し、且つ他のオブジェクトが当該オブジェクトのメンバ機能と構造体を呼び出すことによりそのデータと対話できるようにする。
・サブクラス分け及び継承は、システム中で利用できる標準クラスからオブジェクトの新種を派生させることを介して、オブジェクトを拡大し修正できるようにする。こうして、スクラッチから始めることなく新たな能力が創出される。
・多相性及び多様継承は、異なるプログラムが混ざり合って多くの多種多様なクラスの特性に合うようにすることを可能にし、且つ、依然として予知可能なやり方で関連オブジェクトと共に働ける専門オブジェクトを製作できるようにする。
・クラスヒエラルキ及びコンテインメントヒエラルキは、現実世界のオブジェクトとそれらの間の関係のモデル化のための柔軟な機構を提供する。
・再使用可能なクラスのライブラリは多くの状況において有用であるが、そこには幾つかの限界もある。例えば、
・複雑性。複雑なシステムでは、関連するクラスのクラスヒエラルキは、クラス数が何ダース或いは数百という数に上ると混乱を極める。
・制御の流れ。クラスライブラリの助けを借りて書かれたプログラムは、依然として制御の流れに責任を持っており、即ち、ある特定のライブラリから製作されたオブジェクト全体の間の対話を制御せねばならない。プログラマは、どの種類のオブジェクトに対し、何時、どの機能を呼び出すか決定せねばならない。
・労力の重複。クラスライブラリが、多くの小さなコードをプログラマが使用及び再使用できるようにしているとはいえ、プログラマはそれぞれ別々のやり方でそれらの小さなコードを一緒にしている。二人の別々のプログラマが、同じセットのクラスライブラリのを使って全く同一の２つのプログラムを書くことができるが、内部構造（デザイン）は全く異なっているかもしれないし、それは作業中に各プログラマが行なう膨大な数の小さな決定により左右されるのである。必然的に、同様なコード片は、やり方は僅かに違うやり方で同様な事を行なうに留まるので、期待するほどには共に良好に作用するということはない。

クラスライブラリには十分に柔軟性がある。プログラムが成長してより複雑になるにつれ、プログラマはベーシックな問題に対するベーシックなソリューションを何度も何度も発明し直さねばならなくなる。クラスライブラリというコンセプトの比較的新しい拡大枠は、クラスライブラリのフレームワークを持つことである。このフレームワークはより複雑であって、特定のアプリケーションドメインにおける共通の要件とデザインをインプリメントする、小型のスケールパターンと主機構の両方を手にする合同クラスの大きな集合体から成る。それらは、最初は、パーソナルコンピュータ用の表示メニュ、ウインドウ、ダイアログボックス、及び他の標準的ユーザーインターフェースエレメントに関わる雑用からアプリケーションプログラマを解放するために開発された。

フレームワークは、あるプログラマが書くコードと別のプログラマにより書かれたコード間の対話についてのプラグラマの考え方における違いも表している。早期の手続き型プログラミングにおいては、プログラマは、ある特定のタスクをこなすために、オペレーティングシステムが提供するライブラリを呼び出していが、基本的にはプログラムは開始から終了までのページを実行し、制御の流れに責任を持つのはプログラマだけであった。これは、たった１通りのやり方で実行されるプログラムにより、給料支払い小切手を振り出したり、算術表を計算したり、或いは他の問題を解決したりという場合には適していた。

グラフィカルユーザーインターフェースの発展により、この手続き型プログラミングの在り方はひっくり返り始めた。これらのインターフェースは、ある動作を実行せねばならなくなったときに、プログラムロジックというよりも、むしろユーザーがプログラムをドライブして決定できるようにしている。今日では、ほとんどのパーソナルコンピュータソフトウェアは、マウス、キーボード、及び外部イベントのその他ソースをモニターするイベントループという手段によりこれを実現しており、ユーザーが実行する動作に合わせてプログラマのコードの適当な部分を呼び出す。プログラマはイベントの起きる順序をもはや決めない。代わりに、プログラムは、予期できない時期に予期できない順で呼び出される別々の細片に分割される。ユーザーに対してこうして制御を放棄することにより、開発者はより簡単に使えるプログラムを製作する。それにもかかわらず、開発者により書かれたプログラムの個々の細片は、依然として、あるタスクを実現するためにオペレーティングシステムにより提供されるライブラリを呼び出すので、プログラマはイベントループにより呼び出された後に各プログラム片内の制御の流れを決定せねばならない。アプリケーションコードは依然としてシステムの「頂点に居座っている」。

イベントループプログラムでさえ、プログラマに、全てのアプリケーションに対し別々に書かれる必要のない多数のコードを書くことを要求する。アプリケーションフレームワークのコンセプトは、イベントループ・コンセプトをより遠くにやってしまう。ベーシックメニュー、ウインドウ、及びダイアログボックスを構築するボルト、ナット類全てを処理して、これらを一まとめにして全体として作動させるということに代えて、アプリケーションフレームワークを使って、プログラマはアプリケーションコードとインターフェースエレメントを正しく配置することから開始する。その後、プログラマはフレームワークの一般的な能力の幾つかを意図されたアプリケーションの特定の能力と置き換えることによりそこから構築を開始する。

アプリケーションフレームワークは、プログラマがスクラッチから書かねばならないコードの総数を減らす。しかしながら、フレームワークは、現実にはウインドウを表示しコピーと貼り付けをサポートする等一般的なアプリケーションであるので、プログラマはイベントループプログラムが許容するよりも広い範囲まで制御を放棄することもできる。フレームワークコードはイベントハンドリング及び制御の流れのほとんど全てを取り仕切り、プログラマのコードはフレームワークが（例えば、所有権を主張できるデータ構造を製作又は操作するために）それを必要とするときしか呼び出されない。

フレームワークプログラムを書いているプログラマは、ユーザーに対する制御（イベントループプログラムの場合にも当てはまる）を放棄するだけでなく、フレームワークに対するプログラム内の制御の細かい流れも放棄する。このアプローチは、興味深いやり方でまとまって作動するより複雑なシステムが創造できるようにしており、孤立したプログラムとは反対に、特注コードを有し、同様の問題につき何度も繰り返して創造される。

以上、説明したように、フレームワークは基本的には、所与の問題ドメインに対して再使用可能な設計ソリューションを作り上げる協働するクラスの集合体である。それは通常（例えば、メニュ及びウインドウのための）デフォルト行動を提供するオブジェクトを含んでおり、プログラマは、デフォルト行動の幾つかを継承しその他の行動をオーバーライドすることによりそれを使用して、フレームワークが適時にアプリケーションコードを呼び出すようにする。

フレームワークとクラスライブラリの間には主な違いが３つある。
・行動対プロトコル。クラスライブラリは、基本的には行動の集合体であって、プログラム内でそれら個別的行動を所望する際に呼び出すことのできるものである。一方、フレームワークは行動だけでなく、行動を組み合わせるやり方を統制するプロトコル即ちルールのセットを提供するものであり、それにはプログラマが提供すると期待されるもの対フレームワークが提供するものについてのルールも含まれる。
・呼び出し対オーバーライド。クラスライブラリを使う場合、プログラマはオブジェクトを例示し、それらのメンバ機能を呼び出す。フレームワークでも同じやり方でオブジェクトを例示し呼び出す（即ち、フレームワークをクラスライブラリとして扱う）ことができるが、フレームワークの再使用可能な設計を十分活用するには、プログラマは、通常、オーバーライドしフレームワークにより呼び出されるコードを書く。フレームワークはそれらオブジェクト間の制御の流れを管理する。プログラムを書くことは、別々のソフトウェア片をどうやってまとまって作動するようにするかを規定することではなくて、むしろフレームワークに呼び出される様々なソフトウェア片の間で責任を分割することに関係している。
・インプリメンテーション対設計。クラスライブライを使う場合、プログラマはインプリメンテーションだけを再使用するが、フレームワークの場合は設計を再使用する。フレームワークは関連プログラムのファミリー又は複数片のソフトウェアが動作するやり方を具体化する。それは、所与のドメインにおける各種特定問題に適合できる普遍的設計ソリューションを代表している。例えば、ある１つのフレームワークはユーザーインターフェースが動作する方法を具体化するが、とは言っても同じフレームワークで製作された２つの異なるユーザーインターフェースが全く異なるインターフェース問題を解くこともある。

このように、各種問題とプログラミングタスクに対するソリューションのためのフレームワークの開発を通して、ソフトウェアにとっての設計及び開発努力を著しく低減することがでる。本発明の好適な実施例では、クライアントとＮｅｗｃｏの間の伝達媒体用の汎用セキュア通信プロトコルと共に、ハイパーテキストマークアップ言語（ＨＴＭＬ）を使ってインターネット上にドキュメントをインプリメントする。ＨＴＴＰ又は別のプロトコルは、無用な実験をせずとも難なくＨＴＭＬに成り代わり得る。これら製品に関する情報は、Ｔ．ベマース−リー、Ｄ．コノリーによる「ＲＦＣ１８６６、ハイパーテキスト・マークアップ言語−２．０、１９９５年１１月」及び、Ｒ．フィールディング、Ｈ．フリスティク、Ｔ．ベマース−リー、Ｊ．ジェティース、Ｊ．Ｃ．モーグルによる「ハイパーテキスト・トランスファープロトコル−ＨＴＴＰ／１．１：ＨＴＴＰワーキンググループ・インターネット・ドラフト、１９９６年５月２日」から入手できる。ＨＴＭＬは、１つのプラットホームから別のプラットホームへと持ち歩き可能なハイパーテキスト・ドキュメントを作るために使用される単純なデータフォーマットである。ＨＴＭＬドキュメントは広範なドメインからの情報を表現するのに適した普遍的意味論を備えたＳＧＭＬドキュメントである。ＨＴＭＬは１９９０年から始まった世界的な情報ワールドワイドウェブに使用されている。ＨＴＭＬはＩＳＯ標準８８７９、１９８６年情報処理テキスト及びオフィスシステムのアプリケーション、標準汎用マークアップ言語（ＳＧＭＬ）である。

現在まで、ウェブ開発ツールは、クライアントからサーバまでを範囲に含め、現行のコンピューティングリソースを使って相互動作するダイナミックなウェブアプリケーションを作る能力に限度があった。最近まで、ＨＴＭＬはウェブベースのソリューションの開発に使用される主力技術であった。しかしながら、ＨＴＭＬは以下の領分、即ち
・劣った性能、
・限定されたユーザーインターフェース能力、
・スタティックなウェブページしか作り出せない、
・現行のアプリケーション及びデータとの相互動作能力の欠如、及び
・スケーリングが不可能、
という点で適していないことが証明された。
サンマイクロシステムズ社のＪａｖａ言語は、
・クライアント側の性能を改善すること、
・ダイナミック且つリアルタイムなウェブアプリケーションの製作を可能にすること、及び、
・多種多様なユーザーインターフェース・コンポーネントを製作する能力を提供すること、
によりクライアント側の問題の多くを解決する。

Ｊａｖａを用いれば、開発者は頑強なユーザーインタフェース（ＵＩ）コンポーネントを製作することができる。特注の「仕掛け」例えば、リアルタイムな株価表示機、動画アイコンなどが作れ、クライアント側の性能が改善される。ＨＴＭＬとは違って、Ｊａｖａはクライアント側の妥当性検査の概念をサポートし、性能を向上させるために適当なプロセッシングをクライアント側にオフロードする。ダイナミック且つリアルタイムなウェブページが創造可能となる。上記の特注ＵＩコンポーネントを用いれば、ダイナミックなウェブページも創造できる。

サン社のＪａｖａ言語は「インターネットをプログラミングする」ための、業界が認めた言語として登場した。サン社はＪａｖａを、「単純、オブジェクト指向型、分散型、解釈型、頑強、安全、アーキテクチャ・ニュートラル、ポータブル、高性能、マルチスレッデッド、ダイナミック、且つ専門語対応可能な汎用プログラミング言語」と定義づけている。Ｊａｖａはプラットホーム非依存型Ｊａｖａアプレットという形でインターネットのためのプログラミングをサポートする。Ｊａｖａアプレットは、サン社のＪａｖａアプリケーションプログラミングインタフェース（ＡＰＩ）を遵守する小型の専門アプリケーションであり、開発者が「インタラクティブ・コンテンツ」をウェブドキュメント（例、単純動画、ページ装飾、及び基本的ゲーム等）に付け足すことができるようにしている。アプレットはＪａｖａ互換ブラウザ（例、ネットスケープナビゲータ）内で、サーバからクライアントへコードをコピーすることにより実行する。言語の観点から見ると、Ｊａｖａのコア特性のセットは、Ｃ++が基礎となっている。サン社のＪａｖａ文献には、Ｊａｖａは基本的には「Ｃ++言語がよりダイナミックな方法解決策を求めてオブジェクトＣから拡張したものである」と述べられている。

Ｊａｖａに同様の機能を提供する別の技術は、マイクロソフト並びにアクティブＸテクノロジーズにより提供され、開発者とウェブデザイナーにインターネット及びパーソナルコンピュータ用のダイナミックコンテンツを構築するのに必要な手段を提供する。アクティブＸは、動画開発、３−Ｄバーチャルリアリティ、ビデオ、及び他のマルチメディアコンテンツ用のツールを含んでいる。ツールはインターネット標準を使用し、複数のプラットホームで動作し、１００を超える会社によりサポートされている。グループが構成しているブロックはアクティブＸコントロールズと呼ばれ、開発者がソフトウェアのパーツをハイパーテキスト・メークアップ言語（ＨＴＭＬ）ページに埋め込むことができるようにする小型で高速のコンポーネントである。アクティブＸコントロールズは、マイクロソフトビジュアルＣ++、ボーランドデルフィ、マイクロソフトビジュアルベーシックプログラミングシステムを始めとする多様なプログラミング言語で動作し、将来的にはマイクロソフト社のＪａｖａ用開発ツールのコードネーム「ジャカルタ」で動作できる。当業者には、アクティブＸが、本発明を実用化するに当たり無用な実験をしなくともＪａｖａの代わりと成りうることが自明であろう。

好適な実施例によれば、バックグラウンドファインダー（ＢＦ）は、個人が来るべきミーティングに備える場合に、彼／彼女が各種ソースからそのミーティングについての関連情報を検索することを助けることにより準備に責任を持つエージェントとしてインプリメントされている。ＢＦは、目標ミーティングを表示する文字形式の入力テキストを入手する。入力テキストは、好適な実施例によるとミーティングの日時を含むカレンダプログラムにより生成される。ミーティングが近づくと、カレンダプログラムは目標イベントのテキストを入手するために問い合わせを受け、その情報はエージェントシステムへの入力として利用される。そこで、エージェントシステムは入力されたミーティングテキストを構文解析して、題目、本体、参加者、場所、時間などの各種要素を抽出する。システムは、パターンマッチングも行って、ミーティングテキスト内の特定のミーティングフィールドを識別する。この情報を使ってウェブ上で各種情報源に問い合わせを行ない、現在のミーティングについての関連記事を入手して、それをカレンダリングシステムに送り返す。例えば、ある個人が争議につき討論するためにネットスケープ及びマイクロソフトとミーティングを持つ場合、システムはこの最初の情報をカレンダリングシステムから入手する。システムは次にテキストを構文解析してミーティングの会社が「ネットスケープ」と「マイクロソフト」であり、議題が「争議」であると理解する。システムはここでこの議題に関する関連情報を求めてウェブに問い合わせをする。このように、本発明の目的によれば、システムは目標ミーティングに備えて収集し得る最良の情報でカレンダリングシステムを更新し、結果としてユーザーにもそれら情報を与えることになる。好適な実施例によれば、情報はカレンダシステムに内蔵されたリンクからの選択を介して得られるファイルに記憶される。

［プログラム編成］
好適な実施例によれば、コンピュータプログラムは５つの区別できるモジュール、即ち、ＢＦ．Ｍａｉｎ、ＢＦ．Ｐａｒｓｅ、Ｂａｃｋｇｒｏｕｎｄ Ｆｉｎｄｅｒ、Ｅｒｒｏｒ、ＢＦ．ＰａｔｔｅｒｎＭａｔｃｈｉｎｇ、及びＢＦ．Ｓｅａｒｃｈで編成されている。デバッグ目的にのみ使用されるユーザーインターフェースを提供するｆｒｍＭａｉｎもある。好適な実施例によれば、実行可能なプログラムはユーザーインターフェースでは絶対に実行できず、マイクロソフト社のウィンソック制御を介してカレンダリングシステムに戻されるだけである。システムの好適な実施例は、カレンダリングシステムにより戻された共通ラインの下に規定できる２つの異なるモードで実行する。システムが単純モードで起動している場合、キーワード照会を実行して外部サーチエンジンに実行依頼する。複雑モードで起動している場合、システムはサーチエンジンに送る照会を形成する前にパターンマッチングを行なう。

［データ構造］
好適な実施例によるシステムは、３つのユーザー定義型構造、即ち、
１．ＴＭｅｅｔｉｎｇＲｅｃｏｒｄ；
２．ＴＰａｔｔｅｒｎＥｌｅｍｅｎｔ；
３．ＴｐａｔｔｅｒｎＲｅｃｏｒｄ
を使用する。

ユーザー定義型構造ｔＭｅｅｔｉｎｇＲｅｃｏｒｄは、１つのミーティングに関する全ての関連情報を記憶するために使用される。この情報には、ユーザーＩＤ、ミーティングのオリジナルの記述、ミーティングの題目及び本体から抽出されたキーワードのリスト等が含まれる。好適な実施例によれば、ミーティング記録はシステムのインスタンス毎に１つしか作られないということは重要なので留意頂きたい。これは、来るべきミーティングを担当するためにシステムが生まれる都度、システムはたった１つのミーティングのために情報を検索するというタスクを割当てられるからである。従って、作られたミーティング記録は現在調査中のミーティングに対応している。ＰａｒｓｅＭｅｅｔｉｎｇＴｅｘｔはこのミーティング記録をある場所に置き、次にその記録は巡回されて他の機能にミーティングについての情報が提供される。

仮にＧｏＰａｔｔｅｒＭａｔｃｈがある特定のミーティングフィールドに対してある値を組み合わせることができれば、ミーティング記録内の対応するエントリも更新される。各フィールドが括弧で記述されているｔＭｅｅｔｉｎｇＲｅｃｏｒｄの構造を、好適な実施例により以下に示す。

パターンマッチングに利用される個別パターンを保有するために作られる構造が他にも２つある。記録ｔＡＰａｔｔｅｒＲｅｃｏｒｄは、パターンの全コンポーネント／エレメントを保有しているアレイである。タイプｔＡＰａｔｔｅｒＥｌｅｍｅｎｔは、パターン内のエレメントを表すストリングのアレイである。各エレメント毎に多数の「置換」が存在するかもしれないので、置換が全て何であるかを見失わないようにするためにストリングのアレイが必要になる。ｔＡＰａｔｔｅｒｎＥｌｅｍｅｎｔ及びｔＡＰａｔｔｅｒｎＲｅｃｏｒｄは好適な実施例によれば以下のように表現される。

［一般ユーザー定義型定数］
プログラムの各宣言部において多くの定数が定義されるが、好適な実施例によれば、システムを保守するプロセスの一部として周期的に更新する必要がある。定数は、システムのダイナミックな構成がコードを保守するための更新として起きるようにするために、アクセス可能である。

以下の表に掲載されているのは、時々に最も修正される可能性が高いと考えられる各モジュールからの定数のリストである。しかしながら、以下のリストには含まれていないが、コードに使用される定数が他にもある。これら含まれていない定数は決して変更されないということではない。それらも変更されるがその頻度はずっと少ないというだけのことである。

パターンマッチングモジュール（ＢＦＰａｔｔｅｒｎＭａｔｃｈ）：頻繁な更新を必要とする定数は本モジュールには無い。

［一般的プロセスの流れ］
プロセスフロー及び各機能間のコーディネーションを示す最良の方法は、図２から６に図示す５つのフローチャートを用いることである。図２は好適な実施例による全体的なプロセスの流れを示している。プロセッシングは図の一番上の機能ブロック２００から始まるが、これはプログラムが開始されるときに動き始める。好適な実施例によれば、機能ブロック２１０に示すように、アプリケーションが開始されると、コマンドラインは構文解析されて適当なミーティングテキストを移動させ、バックグラウンド・ファインド・オペレーションの目標を初期化する。広域停止リストは、機能ブロック２２０に示すように、目標が定められた後で生成される。次に、ブロック２３０に示すように、マッチングオペレーションに使用される全パターンが生成される。チャートを追っていくと、機能ブロック２００はＧｏＢＦ２４０を呼び出すが、これは特定目標サーチエンジンのために正確なサーチ照会情報をラッピングすることに関連付けられたロジカルプロセッシングに責任を持つものである。例えば、機能ブロック２４０は機能ブロック２５０へとつながり、そこで機能ブロック２６０に示すＧｏＰａｔｔｅｒｎＭａｔｃｈを呼び出す。ＧｏＰａｔｔｅｒｎＭａｔｃｈのプロセスフローを理解するため、本図を「ＢＦのパターンマッチングユニットのためのプロセスフロー」と題することにする。

１つ重要なことは、図中同一レベルに示される機能は左から右の順（又は上から下の順）で共通の親機能に呼び出される点である。例えばＭａｉｎ２００はＰｒｏｃｅｓｓＣｏｍｍａｎｄＬｉｎｅ２１０を呼び出し、続いてＣｒｅａｔＳｔｏｐＬｉｓｔ２２０、そしてＣｒｅａｔＰａｔｔｅｒｓ２３０、次にＧｏＢａｃｋＦｉｎｄｅｒ２４０の順に呼び出すわけである。図３から６はプログラム全体のロジック、構文解析ユニット、パターンマッチングユニット、及びサーチユニットをそれぞれ詳しく示した図である。図６はＢａｃｋｇｒｏｕｎｄＦｉｎｄｅｒを介してキー情報のデータフローを決定するロジックを詳細に表し、そのような情報を製作し又は処理することに責任を持つ機能を示している。

［単純な照会モード下の詳細なサーチ構造］
［アルタビスタサーチ］
（図２の機能ブロック２７０）
アルタビスタサーチエンジンは、図２の機能ブロック２７０に示すように、識別を使って現下のミーティングに関連する議題についての一般情報を戻す。好適な実施例によるシステムは、オリジナルのミーティングテキストの題目部分からキーワードを全て抜き出し、アルタビスタに送るためのアドバンスド照会を作り上げる。キーワードは照会内で互いに論理的に組み合わせられる。その結果も、同じキーワードのセットに基づいてランク付けされる。当業者には、データ制限又は編集者基準により、検索を望んでいる事柄がやり易くなることが容易に理解されよう。好適な実施例によれば、トップにランクされた記事のセットがカレンダリングシステムに戻される。

［ニュースページ］
（図２の機能ブロック２７５）
ＮｅｗｓＰａｇｅサーチシステムは、目標ミーティングに関連する最新ニューストピックを我々に与えることに責任を持っている。このシステムはオリジナルのミーティングテキストの題目部分からキーワードを全て抜き出し、ＮｅｗｓＰａｇｅサーチエンジンに送るための照会を作り上げる。キーワードは照会内で互いに論理的に組み合わせられる。最近発行された記事しか検索されない。ＮｅｗｓＰａｇｅサーチシステムは、ユーザーの好みによりユーザーが設定できるデータ限定基準を提供する。トップにランクされた記事がカレンダリングシステムに戻される。

図３は、好適な実施例によるユーザープロフィールデータモデルである。プロセッシングは機能ブロック３００で開始されるが、このブロックはメインモジュールからプログラムを呼び出すことに責任を持っている。次に、機能ブロック３１０では、ラッパ機能が呼び出され、機能ブロック３２０のキーワード抽出プロセッシングに備える。キーワードが抽出された後、プロセッシングは機能ブロック３３０に進み、区切記号が正しく位置づけられたか否かを判定する。そして、機能ブロック３４０で、特定ストリング中のワード数が計算され、特定フィールドに対する区切記号及びミーティングテキストからの特定フィールドが機能ブロック３５０で検索される。次に機能ブロック３８０で、ストリングの区切記号が再度チェックされ、それらが確実に正しく配置されるようにする。最後に、機能ブロック３６０で、メッセージの題目及び本体からの各ワードの抽出が１度に１ワードずつ行なわれるが、その抽出は、入力フレーズ内の最も近いワード区切記号を見つける機能ブロック３６２、ワードから不要なマテリアルを取り除く機能ブロック３６４、及びワードが停止リストに載っているかどうかを判定してワードが停止リストに載っていればエラーを戻す機能ブロック３６６のロジックを利用して行なわれる。

［好適な実施例によるパターンマッチング］
単純なサーチ方法に関連する制限は以下の通りである。
１．ミーティングテキストからキーワードのセットを抽出するためには不要ワードの停止リストに依存することになるので、停止リストがどれほど包括的であるかにより限界が決まる。ミーティングテキストのどの部分を捨てるべきかを計算する代わりに、ミーティングテキストのどの部分が欲しいのかに焦点を置くべきである。
２．好適な実施例による単純サーチ方法は、ミーティング題目からのキーワードだけを使ってアルタビスタとＮｅｗｓＰａｇｅに送信する照会を作る。これは、照会のための代わりの情報源、即ちミーティング告示の本体を無視することである。我々の照会を作るためにはミーティング本体からのキーワードは含まない、というのも、余りも長すぎて複雑であるため意味のある結果を得ることができないということがしばしば生じるからである。
３．我々には各キーワードが何を表現しているか分からない。例えば、２つのキーワード「アンディ」と「グローブ」を抽出するとしよう。しかしながら、単純に割り切ったサーチでは「アンディ・グローブ」が実は人物の名前であることを知る術がない。我々が何らかの方法で「アンディ・グローブ」は人物名であると聡明にも推定できたならという可能性を想像して頂きたい。彼がアンデルセンという人物であるか否か、そしてそうであれば彼が以前にどんな種類のプロジェクトに携わっていたか等は我々にも分かる。
４．要約すると、不要なワードを構文解析するために停止リストだけに依存することにより、我々は「情報のオーバーロード」に悩まされるのである。

［好適な実施例によれば、パターンマッチングはこれらの制限を克服する］
ここで、パターンマッチングシステムが、どのようにして対応する上記問題それぞれに取り組むことができるのかを好適な実施例により示す。
１．パターンマッチングを行なうことにより、我々は欲しいと思うミーティングの部分だけを取り上げてそれらの部分だけを抽出する。
２．ミーティング本体に関してパターンマッチングを行ない、我々が欲しいと思う部分だけをミーティング本体から抽出することにより、我々のミーティング本体はそれらを完全に無駄にすることはなくなる。
３．パターンマッチングは、我々が規定するテンプレートのセットに基づいているので、人物名、会社名等をミーティングテキストから識別することができる。
４．要約すると、パターンマッチングを用いれば、我々はもはや「情報のオーバーロード」に悩まされることはない。無論、大きな問題は、我々のパターンマッチングがどれほど良好に作動するかという点である。我々が専ら人工知能プロセッシングに頼るのであれば、１００％のヒット率は望めない。我々は提示された全会社名のうち約２０％を識別できる。

［パターン］
好適な実施例のコンテクストにおけるパターンは、我々がミーティングテキスト内に捜しているフレーズの構造を規定しているテンプレートである。好適な実施例によりサポートされるパターンは、それらがだれかのミーティングテキストに現れる確率が高いフレーズのテンプレートであるという理由で選択される。例えば、あるミーティングをカレンダーに入力しようとするとき、多くの人は“Ｍｅｅｔ ｗｉｔｈ Ｂｏｂ Ｄｕｔｔｏｎ ｆｒｏｍ Ｓｔａｎｆｏｒｄ Ｕｎｉｖｅｒｓｉｔｙ ｎｅｘｔ Ｔｕｅｓｄａｙ．”（来週スタンフォード大学のボブ・ダットンと会う）というようなことを書き込む。一般的なパターンというのは“ｗｉｔｈ”というワードの後に人物名（本例ではボブ・ダットン）が続き、その後に“ｆｒｏｍ”が続き、組織名（本例ではスタンフォード大学）で終わるというようなものである。

［パターンマッチング専門用語］
パターンマッチングに関係する一般的な専門用語を以下に説明する。
・パターン。パターンはミーティングテキストを結びつけようと思うフレーズの構造を規定するテンプレートである。これはサブユニットを保有している。
・エレメント。パターンは多数のサブユニットを含んでいる。これらサブユニットはエレメントと呼ばれる。例えば、“ｗｉｔｈ＄ＰＥＯＰＬＥ＄ｆｒｏｍ＄ＣＯＭＰＡＮＹ＄”というパターンにおいて、“ｗｉｔｈ”、“＄ＰＥＯＰＬＥ＄”、“ｆｒｏｍ”、“＄ＣＯＭＰＡＮＹ＄”はエレメントである。
・プレースホルダ。プレースホルダとは、ある値を結びつけたいと思う特種なエレメントのことである。上記の例を用いるなら“＄ＰＥＯＰＬＥ＄”がプレースホルダである。
・インジケータ。インジケータとは、我々がミーティングテキスト中に見つけたいと思う別種のエレメントであるが、それに結びつけるには値は不要である。あるパターン内で捜しているインジケータが２つ以上のこともしばしばあろう。それはインジケータが「原子」タイプではないからである。
・置換。置換とは、全て互いの同義語であるインジケータのセットである。入力内に置換えの１つでも見つけられれば良好といえる。
各ミーティング毎に識別されるフィールドが５つある。
・会社（＄ＣＯＭＰＡＮＹ＄）
・人々（＄ＰＥＯＰＬＥ＄）
・場所（＄ＬＯＣＡＴＩＯＮ＄）
・時刻（＄ＴＩＭＥ＄）
・議題（＄ＴＯＰＩＣ＿ＵＰＰＥＲ＄）又は（＄ＴＯＰＩＣ＿ＡＬＬ＄）
括弧内は、自分のコードで使用されるプレースホルダであり、対応しているミーティングフィールドの表現である。

各プレースホルダには以下ような意味がある。
・＄ＣＯＭＰＡＮＹ＄：大文字ワードのストリングを結合する（例えば、Ｍｅｅｔ ｗｉｔｈ Ｊｏｅ Ｃａｒｔｅｒ ｏｆ ＜Ａｎｄｅｒｓｏｎ Ｃｏｎｓｕｌｔｉｎｇ＞）（＜アンダーセンコンサルティング＞のジョー・カーターと会う）。
・＄ＰＥＯＰＬＥ＄：“，”“ａｎｄ”又は“＆”により接続される可能性のある大文字ワード２語のストリングのシリーズを結合する（例えば、Ｍｅｅｔ ｗｉｔｈ ＜Ｊｏｅ Ｃａｒｔｅｒ＞ ｏｆ Ａｎｄｅｒｓｏｎ Ｃｏｎｓｕｌｔｉｎｇ、Ｍｅｅｔ ｗｉｔｈ ＜Ｊｏｅ Ｃａｒｔｅｒ ａｎｄ Ｌｕｋｅ Ｈｕｇｈｅｓ＞ ｏｆ Ａｎｄｅｒｓｏｎ Ｃｏｎｓｕｌｔｉｎｇ）（アンダーセンコンサルティングの＜ジョー・カーター＞と会う、アンダーセンコンサルティングの＜ジョー・カーター並びにルーク・ヒューズ＞と会う）。
・＄ＬＯＣＡＴＩＯＮ＄：大文字ワードのストリングを結合する（例えば、Ｍｅｅｔ Ｓｕｓａｎ ａｔ ＜Ｐａｌｏ Ａｌｔｏ Ｓｑｕａｒｅ＞）（＜パロアルトスクエア＞でスーザンに会う）。
・＄ＴＩＭＥ＄：フォーマット＃：＃＃を含んでいるストリングを結合する（例えば、Ｄｉｎｎｅｒ ａｔ ＜６：３０ｐｍ＞）（＜午後６時３０分＞に夕食）。
・＄ＴＯＰＩＣ＿ＵＰＰＥＲ＄：我々の議題に関する大文字ワードのストリングを結合する（例えば、＜Ｓｔａｎｆｏｒｄ Ｅｎｇｉｎｅｅｒｉｎｇ Ｒｅｃｒｕｉｔｉｎｇ＞Ｍｅｅｔｉｎｇ ｔｏ ｔａｌｋ ａｂｏｕｔ ｎｅｗ ｈｉｒｅｓ．）（新規雇用について論議するための＜スランフォードエンジニアリング社員募集＞会議）。
・＄ＴＯＰＩＣ＿ＡＬＬ＄：大文字か否かを問題にしないワードのストリングを結合する（例えば、Ｍｅｅｔ ｔｏ ｔａｌｋ ａｂｏｕｔ ＜ｕｂｉｑｕｉｔｏｕｓ ｃｏｍｐｕｔｉｎｇ＞）（＜ユービキタスコンピューティング＞を論じるために会う）。

ここにＢＦによりサポートされる全パターンを表している表を示す。各パターンはあるパターングループに属している。あるパターングループ内の全パターンは同じフォーマットを共用しており、置換えとして使われるインジケータが何かという点においてしか区別できない。尚、灰色にされたパターンもコードで解説される。ＢＦはこれらのパターンをサポートする能力を有するが、これらのパターンをマッチングさせることは現時点では必要ではないと決めた。

図４は、好適な実施例によるパターンマッチングの詳細なフローチャートである。プロセシングは機能ブロック４００に始まり、ここでメインプログラムがパターンマッチングアプリケーションを呼び出して制御を機能ブロック４１０に渡すとパターンマッチングプロセッシングが開始される。機能ブロック４２０で、ラッパ機能はループしながら各パターンを処理するが、これには、機能ブロック４３０に示すように、テキストストリングの一部があるパターンに結びつくかどうかを判定することも含まれている。次に、機能ブロック４４０で、各種プレースホルダは値が存在する場合にはその値に結びつけられ、機能ブロック４４１では句読点により分離された名前のリストが結びつけられ、機能ブロック４４２では、フルネームとして大文字ワード２語を見つけ、あるワードの後のスペースの後の次の文字をそれが大文字かどうかを判定するために入手することによりフルネームが処理される。次に機能ブロック４４３で、適切な方法でストリングから時刻が構文解析され、機能ブロック４４４では空白スペース後の次のワードが構文解析される。そして、機能ブロック４４５では、会社、議題、場所のような大文字ワードの連続フレーズが結びつけられ、機能ブロック４４６では、空白後の次のワードが好適な実施例による以後のプロセッシングに向け入手される。突き合わせミーティングフィールドプロセッシングに続き、機能ブロック４５０を使ってパターンのヘッドであるインジケータを見つけ、機能ブロック４５２に示すように空白の後の次のワードが入手され、そのワードは機能ブロック４５４に示すように、インジケータであるか否かを判定するために調べられる。そして、機能ブロック４６０で、ストリングが構文解析され、パターンの終りではないインジケータが発見されると、改行やキャリッジリターンの後にくるような不要な空白の後の次のワードが機能ブロック４６２に示すように処理され、そのワードは機能ブロック４６４に示すように、分析され、それがインジケータであるか否かが判定される。次に、機能ブロック４７０で、一時的記録はナルにリセットされて次のストリング処理のための準備をし、機能ブロック４８０でミーティング記録が更新され、機能ブロック４８２でチェックが行なわれ、ミーティング記録が再度構文解析される前にミーティング記録に対してエントリが既にあったかどうかが判定される。

［識別されたミーティングフィールドを使用する］
現在ミーティングテキスト内に我々が重要だと見なすフィールドを識別している時点で、それを使ってできることはほとんど無い。パターンマッチングの最重要アプリケーションは、最終的にはアルタビスタ及びＮｅｗｓ Ｐａｇｅに提出されることになる我々が構築する照会を改善する過程である。ＢＦに追加できるパターンマッチングの結果を利用するオプション及び強化策は他にもたくさんある。これら他のオプションは次の節で説明することにしよう。本節の目的は読者に、パターンマッチングから得られる結果が、より良好なサーチ結果を得るのを援助するためにどのように利用できるかをよく理解して頂くことである。

図５は、好適な実施例による照会の準備及びインターネットからの情報入手の詳細なプロセッシングを示すフローチャートである。プロセッシングは機能ブロック５００に始まり、直ぐに機能ブロック５１０に進んで、ウェブサーチエンジンを使ってインターネットサーチに備えるためにラッパ機能性を処理する。サーチがアルタビスタサーチエンジンを利用する場合、機能ブロック５３０で、システムはミーティング記録から情報を取り出し、機能ブロック５４０から５６０でサーチエンジンに提出する照会を形成する。サーチがＮｅｗｓＰａｇｅサーチエンジンを利用する場合、機能ブロック５２０で、システムはミーティング記録から情報を取り出し、機能ブロック５２１から５２８で照会を形成する。

［アルタビスタサーチエンジン］
アルタビスタサーチエンジンの強度は、柔軟性を強化することができるほどのものである。そのアドバンス照会方法を使えば、全種類のブール式照会を構築でき、どのようであれ希望するようにサーチをランク付けすることができる。しかしながら、アルタビスタの最大の欠点の１つは大規模な照会を扱うのが苦手で、的外れな結果を返す可能性が高いということである。ミーティングテキスト内の議題と会社を識別できるのであれば、かなり短くても包括的な問い合わせを作ることができるであろうし、その方が結果が良いと思われる。見つけられる議題にも焦点を当ててみたい。ユーザーが会社を既によく知っておりそれらの会社と何度もミーティングを持ったことがある場合には特にそうであるが、会社についての情報を発見することはユーザーにとって大したメリットとはなりえない。ユーザーが調べたいのは議題である。

［Ｎｅｗｓ Ｐａｇｅサーチエンジン］
Ｎｅｗｓ Ｐａｇｅサーチエンジンの強度は、仮に有効な会社名を与えられるのであれば、最新のニュースのサーチに多大な仕事をするというほどである。従って、ニュースページウェブサイトにある問い合わせを提出するとき、我々は識別できるなら何れの会社名をも送信し、会社名が見つけられないときに限り見つけられた議題を使って問い合わせを作成する。両方とも見つからないときには、サーチは行なわれない。アルタビスタに提出される問い合わせの作成に使用されるアルゴリズムを図７に示している。Ｎｅｗｓ Ｐａｇｅに提出する問い合わせの作成に我々が使用するアルゴリズムは図８に示す。

以下の表は、好適な実施例による各機能を詳細に説明している。機能はできる限りプロセスの流れに合わせた順に示している。数度呼び出しを受ける機能がある場合には、それを呼び出す最初の機能の後にその機能を掲載しており、後続の機能がそれを呼び出す都度その後に説明が重複して示されることはない。

図６は好適な実施例による、アルタビスタ及びＮｅｗｓ Ｐａｇｅサーチエンジンに対するサーチを準備し提出するために使用される実際のコードのフローチャートである。プロセッシングは機能ブロック６１０に始まり、ここでコマンドラインを使ってカレンダエントリを特定のカレンダ情報で更新する。メッセージは次に、機能ブロック６２０で転記され、機能ブロック６３０で、現在のミーティング情報を記憶するためにミーティング記録が作成される。次に、機能ブロック６４０で問い合わせがアルタビスタサーチエンジンに提出され、機能ブロック６５０で問い合わせがＮｅｗｓ Ｐａｇｅサーチエンジンに提出される。サーチエンジンからメッセージが戻されると、機能ブロック６６０に示すように、結果データ構造に記憶され、機能ブロック６７０に詳細に示すように、情報は処理されてミーティングの準備に用いられるように要約形式でファイルに記憶される。

図７は好適な実施例による、問い合わせを作成する際の詳細を示している。プロセッシングは機能ブロック７１０に始まり、ここでミーティング記録が構文解析され、考えられる会社、人物、議題、場所及び時間が入手される。次に、機能ブロック７２０で少なくとも１つの議題が識別され、機能ブロック７３０で少なくとも１つの会社名が識別され、最後に機能ブロック７４０で、ユーザーが最終的に使用するファイルに何のマテリアルを送信するかにつき決定が下される。

図８は、図７に示す問い合わせテーマのバリエーションである。ミーティング記録は機能ブロック８００で構文解析され、機能ブロック８２０で会社が識別され、機能ブロック８３０で議題が識別され、最後に機能ブロック８４０で問い合わせ作成にその議題及び／又は会社が使用される。

特定のユーザーのために様々な特定の特性を付加するための代わりの実施例を以下に説明する。

［パターンマッチングの目標レートを強化する］
ＢＦの性能を向上させるために、多くのパターン／パターングループが手続き“ＣｒｅａｔｅＰａｔｔｅｒｎｓ”に加えられる。パターンを宣言するための現行コードは将来のパターンに備えるテンプレートとして用いることができる。全てがダイナミックアレイとして記憶されるため、コード切り取りと貼り付けにより再使用するのが好都合である。ＢｉｎｄＮａｍｅ、ＢｉｎｄＴｉｍｅ、ＢｉｎｄＣｏｍｐａｎｙＬｏｃＴｏｐｉｃの機能はある値をプレースホルダに結びつける責任を担っているが、これらは強化される。強化は、結びつける値の数を増やすためにあるミーティングフィールドを結びつけるための基準のセットを増やすことにより実現される。例えば、ＢｉｎｄＴｉｍｅは現在＃＃：＃＃又は＃：＃＃という形式で全ての値を受け取り結びつける。結びつけ可能な回数を増やすためには、ＢｉｎｄＴｉｍｅにも１から１２の数に、より感覚的な時間専門用語である“ｏ‘ｃｌｏｃｋ”を付けて読み込んでもらいたい。語彙バースの認識アルゴリズムと、正確なレートを各推量に割り付けることにより、ＢＦはある閾値に当てはまる推量しか有効とならないようにできる。

パターンマッチングを通してシステムがどの場所を識別するかにより、或いはユーザーがどの場所をミーティング場所として示すかにより、好適な実施例によるシステムは、昼食／夕食／朝食というワードを検知した場合にはいつでも立派なレストランを複数個提案する。我々は、会社ファインダのようなサイトを使って、我々が手にしたものが実際に会社名かどうかを確認することもできるし、又はパターンマッチングが識別できる会社名が存在しないのであれば「辞書」のような会社ファインダウェブサイトを使って、ある大文字ワードが会社名を表しているかどうかを我々が判断することもできる。我々は我々が識別した会社に関する株価及びブレーキングニュースを表示することもできる。

［好適な実施例による無線バーゲン識別］
図９は、従来の物理的な非ウェブ小売り環境で、ウェブベースの比較ショッピングができるように設計されている装置及びソフトウェアシステム用の、ハードウェア及び制御に関する論理的流れを示すフローチヤートである。インターネットプロトコル能力を有する無線電話又は類似のハンドヘルド無線装置９２０は、小型バーコードリーダー９１０（電話内又はショートケーブル上のどちらかにインストールされている）と組み合わせられ、本又は別の製品のユニバーサルプロダクトコード（ＵＰＣ）バーコードを走査するのに用いられる。無線装置９２０は、バーコードをアンテナ９３０経由でポケットバーゲンファインダサービスモジュール（ウェブサーバー上で稼働している）９４０へ送り、ポケットバーゲンファインダサービスモジュールは、それを、その国際標準書籍番号又は（他の製品の場合は）識別子が適切な何れかの番号に変換する。次にサービスモジュールは、様々なウェブサプライヤ９５０からの、その製品に関する価格、納期及び有効な情報を見つけるために、適切なサードパーティのウェブサイトに接触する。この情報はフォーマットされ、ハンドヘルド装置のスクリーン上に表示される。ＩＰ無線電話又は他のハンドヘルド無線装置９２０は、メトリコム社のリコシェットＳＥ無線モデムのような無線モデムを利用する。この装置を利用すれば、ユーザーは、キーボードの危険なほど近くでラッテをぽちゃぽちゃさせながら、ガタついた小さなテーブルの上に載せた携帯コンピュータを使って、喫茶店にいながら、電話線を経由する直接接続に匹敵する速度でインターネットにアクセスすることができる。

８オンスのリコシェットＳＥ無線モデムはタバコ１箱の大きさとほぼ同じで、セットアップは非常に簡単であり、添付されているベルクロのマジックテープ（登録商標）で携帯のスクリーンの後ろにモデムを取り付け、ケーブルをシリアルポートに差し込み、短くて太いアンテナをぐいと上げ、送信するだけである。ソフトウェアのセットアップも同じく簡単で、直接インストーラーがリコシェットモデムドライバを加え、接続アイコンをデスクトップ上に置く。そのモデムの機能の態様は、伝統的な電話モデムのそれと全く同じである。

勿論、無線性能は、従来のダイヤル電話接続ほど信頼できない。我々は、窓の近くに居る限りは、幾つかのサンフランシスコのロケーションと強力な接続ができた。しかしＣＮＥＴの総レンガ造りの本社の中では、リコシェットは全く繋がらなかった。オンラインと繋ぐ場合、２８．８ｋｂｐｓまでの性能が使えるが、徐々に効率は低下して低速になる。しかし、低速でも失望しなかった。セルラーモデムを通して接続する場合と比べると、リコシェットは、速いし、信頼性があり、安価である。当然、ＳＥ無線の電源はバッテリーである。モデムの持続バッテリー寿命は１２時間もある。更に、好適な実施例によれば、我々はリコシェットが弱まる前に、携帯コンピュータの２つのセルを停止させた。

このように、好適な実施例によれば、無線モデムを使えば、ユーザーは、正しい製品を識別する９５０ためにウェブサーバーソフトウェア９４０を利用し、次に、適切な装置のキーを用いてサプライヤを選択し、注文を出すことができる。次に、バーゲンファインダサービスモジュールは、適切なサードパーティのウェブサプライヤを使ってその注文を完了させる９６０。

［ｍｙＳｉｔｅ！個人ウェブサイト及びインテンションバリューネットワークプロトタイプ］
ｍｙＳｉｔｅ！は、バイヤー中心の世界で個人のウェブサイトを通して各消費者へサービスを配信し、個人向け経験を提供するというテーマに焦点を当てている好適な実施例による、インパクトの強いインターネットベースのアプリケーションである。サービスは、広大な計画の判断や、財政計画、健康管理、個人的及び専門的自己啓発、家族生活、その他の関心事のような複数の問題にまたがる調整を必要とする根本的な生活上の必要性並びに目的など、消費者の意図を満足させるものの周りに感覚的に組織されている。各メンバーはそれぞれのプロファイルを所有して維持しており、そのメンバーは、自分だけに目標が定められたシステム内でコンテンツを作成しブラウジングすることができる。製品又はサービスに対する要求が入力されたときから支払いの完了まで、検索を実施し、取引を実行し、アドバイスを提供するために、知的エージェントが利用される。高度なプロファイリング及びフィルタリングを用いることにより、知的エージェントはユーザーについて学習し、配信するサービスを改善する。消費者の意向には、デイリーなロジスティックの管理（例えば、ｅメール、カレンダー、面会、予定リスト、請求書の支払い、ショッピング、旅行計画）と、新しいコミュニティへの移動（例えば、住まい探し、引越し、旅行及び船旅の保険の適用、社用及び個人的面会の通知、新しいコミュニティについての学習）とが含まれている。消費者の立場からすると、ｍｙＳｉｔｅ！は、ユーザーが、非常に簡単且つ便利に当を得た製品及びサービスにアクセスできて、日々のタスクを遂行できる中心的ロケーションを提供する。

ビジネスの観点からすると、ｍｙＳｉｔｅ！は、消費者を効果的に惹きつけ、サービスし、保持し続けるため、付加価値のある画期的な方法を提示している。ユーザーは、インテンションバリューネットワークにより、個人向けサイトを通じて参入できるし、学習する知的エージェントの支援で、ネットワークの参加者と途切れなく対話できる。好適な実施例によるインテンションバリューネットワークは、すばらしい価値を提供する。それは、カスタマイズされた情報、アドバイス及び製品に、週に７日、１日２４時間のアクセスを提供する。その情報は、個人向けになっているので、各メンバーが、ターゲットユーザーに対し確実に当を得たコンテンツを見ることになる。

［自己中心型インターフェース］
自己中心型インターフェースは、特定ユーザーのニーズ、嗜好及び現在のコンテクストを満たすように綿密に作成されたユーザーインターフェースである。インターフェースをカスタマイズするために、中央プロファイルデータベース内に記憶されているユーザーの個人情報が利用される。ユーザーは、インタフェースエレメントとコンテンツにに対してセキュリティ許可を設定し、嗜好を設定することができる。自己中心型インターフェースに統合されているコンテンツは、ユーザーについての関連情報を使ってカスタマイズされる。コンテンツを表示する場合、自己中心型インターフェースには、コンテンツがユーザーとどのように関っているのかを示すやり方で、コンテンツとユーザーとの関係をが含まれることになる。例えば、ユーザーが参加する次の空の旅についての情報を表示する場合は、インターフェースには、空の旅の間にその領域内にいるであろう別の人々のような、ユーザーの個人カレンダー及び面会リストからのイベントについての情報が含まれることになる。これによって、新情報が、個々のユーザーに馴染みのあるコンテンツに挿入される。

図１０Ａは、ワールト・ワイド・ウェブ用のインテンションバリューネットワークアーキテクチャのインプリメンテーションを示している。簡単のために、図は、セキュリティ、スケーラビリティ及びプライバシーに関する複雑な様態を省いている。顧客は、インターネット又はパーソナルデジタルアシスタントに無線機能を使って接続されているパソコン上で実行されているネットスケープナビゲータ又はマイクロソフトインターネットエクスプロアーのような、何れかのインターネットウェブブラウザ１０１０を用いて、インテンションバリューネットワークにアクセスできる。インテンションバリューネットワークにアクセスするための多様な方法の更に詳細な説明については、図１７を参照されたい。顧客は、インテグレイタのウェブサーバー１０２０に関わる独自のネーム又はＩＰアドレスを使って、インテンションバリューネットワークにアクセスする。インテグレイタは、インテンションデータベース１０３０、コンテンツデータベース１０４０、サプライヤプロファイルデータベース１０５０、顧客プロファイルデータベース１０６０のようなリソースの組み合わせを使って、インテンションバリューネットワークを作成する。

インテンションデータベース１０３０は、意向を満たすのに必要な製品及びサービスの意向及びタイプの構造に関する全情報を記憶している。このデータベース内の情報には、意向ステップ、関心事の領域、レイアウトテンプレート及び個人化されたテンプレートが含まれている。コンテンツデータベース１０４０は、アドバイス、関連情報、個人化されたコンテンツ、満足度のランク付け、製品のランク付け及び進展報告のような、意向に関する全情報を記憶している。

サプライヤプロファイルデータベース１０５０は、インテンションに統合されている製品及びサービスプロバイダに関する全情報を含んでいる。このデータベース内に含まれる情報は、インテンションフレームワークとサプライヤとの間にリンクを提供する。それは、製品リスト、特徴及び解説、及びサプライヤの製品のウェブサイトのアドレスを含んでいる。顧客プロファイルデータベース１０６０は、名前、住所、社会保障番号及びクレジットカードに関する情報、個人的嗜好、行動情報、履歴及びウェブサイトレイアウトの嗜好のような顧客に関する個人情報を含んでいる。サプライヤのウェブサーバー１０７０は、顧客に情報及び取引のサポートを提供するのに必要な全てのサプライヤデータベースへのアクセスを提供する。

製品情報データベース１０８０は、特徴、入手性、価格のような製品に関する全情報を記憶している。製品オーダーデータベース１０９０は、全ての顧客オーダーを記憶している。このデータベースへのインターフェースは、ＳＡＰ、バーン、オラクル又は他社が提供するエンタープライズリソースプランニングアプリケーションを通すか、或いはサプライヤのウェブサーバー又はアプリケーションサーバーを通して直接アクセスできる。顧客情報データベース１０９１は、サプライヤが取引を完了させるか又は消費者の記録を維持するのに必要な、全ての顧客情報を記憶している。

図１０Ｂは、自己中心型インターフェース内でウェブページを作成するのに利用されるロジックを提供するフローチャートである。この環境は、ウェブサーバーとウェブブラウザとが、公衆インターネット又は専用インターネットを使うようなＴＣＰ／ＩＰネットワークを通じて接続されていると仮定している。ウェブサーバーには、マイクロソフトインターネット情報サーバー、ネットスケープエンタープライズサーバー又はアパッチ等が含まれる。ウェブブラウザには、マイクロソフトインターネットエクスプローラ又はネットスケープナビゲータ等が含まれる。クライアント（即ちウェブブラウザ）は、特定のウェブページに対してサーバー（即ちウェブサーバー）へ要求を作成する１００１。これは、通常は、ユーザーがウェブページ内のボタン又はリンクをクリックすることにより行われる。ウェブサーバーは、クライアント（即ちウェブブラウザ）内に記憶されている独自のユーザーＩＤで開錠されるデータベース及びユーザープロファイルデータベース１００３に要求することによって、その特定ユーザーのレイアウト及びコンテンツの嗜好１００２を入手する。次にウェブサーバーは、コンテンツデータベース１００５から要求されていたページの内容を検索する１００４。次に、カレンダー、ｅメール、面会リスト及びタスクリスト項目のような関連のあるユーザー中心コンテンツが検索される１００６。このプロセスの更に詳細な説明については図１１を参照されたい。データベースへの問い合わせは、ユーザープロファイルデータベース１００３内のユーザープロファイルの一部分として記憶されているユーザーコンテンツ嗜好を利用し、戻されるコンテンツにフィルタを掛ける。戻されるコンテンツは、ユーザープロファイルに定義されているレイアウトの嗜好に従って、ウェブページ１００７にフォーマットされる。次に、ウェブページはクライアントに戻され、ユーザーに表示される１００８。

図１１は、ユーザー中心コンテンツを検索してウェブページに加えるプロセスを説明している。このプロセスは、図１０Ｂの１００６を更に詳細に示したものである。サーバーはユーザープロファイル及びこのページに統合されようとしている現存コンテンツを既に入手していると仮定している。サーバーは、例えばイベント、面会者名前及びｅメールアドレスを検索しながら、フィルタを掛けられたコンテンツを構文解析する１１１０。これらの何れかが見つかれば、タグ付けされて、一時的な保持スペース内に記憶される。次にサーバーは、様々なデータベース内に記憶されているあらゆるユーザー中心コンテンツを検索しようとする１１２０。これには、一時的保管場所内でタグ付けされた項目と、カレンダデータベース１１４０内のカレンダ項目１１３０、ｅメールデータベース１１１４内のｅメール項目１１１５、面会データベース１１６８内の面会項目１１１７、タスクリストデータベース１１１８内のタスクリスト項目１１１９及びニュースデータベース１１２０内のニュース項目１１２１とのマッチングが含まれている。あらゆる関連ユーザー中心コンテンツを検索した後で、それは一緒にコンパイルされて、戻される１１２２。

［ユーザーペルソナ］
本システムは、ユーザーが、複数の異なるペルソナを作成し、プロファイル情報を異なるコンテクストで有用なセットにまとめることができるようにする。ユーザーは、自宅用の買い物をするとき１つのペルソナを作成することができる。このペルソナは彼の自宅の住所を含み、このユーザーが買い物をする時に買い得商品を探そうと閲覧しているということを示すかもしれない。同じユーザーが、仕事に入っている場合に用いることができる第２ペルソナを作成してもよい。このペルソナは、ユーザーの職場の住所を記憶し、ユーザーが、あるベンダーを好み、ディスカウントプログラムを備えている或る会社で働いていることを示すかもしれない。仕事関連のものを購入する際に、ユーザーは、このペルソナを用いるであろう。ペルソナは、ルール及び制限を含んでいてもよい。例えば、仕事ペルソナは、ユーザーが、１つの旅行エージェントだけを使って航空券の予約を取ること、及び雇用者によって設定されている予約ルールを使うこと等の制限してもよい。

図１２は、ユーザー、ユーザーの複数のペルソナ、及びユーザーの複数のプロファイルとの間の関係を示している。ユーザープロファイル１２００は、ユーザーレベルにある。このプロファイルは、ユーザー及びユーザーの口座に関する情報を記述している。口座を有する各ユーザーに対して、データベース内に１つの固有の記録がある。複数のペルソナ１２２０、１２３０、１２４０が、各ユーザーに接続されている。これらのペルソナは、複数のプロファイルを有用なコンテクストへ分類するのに用いられる。例えば、サンフランシスコに住んで、パロ・アルトで働いているが、タホー湖に山小屋を所有しているユーザーについて考えてみる。彼は、自分のサイトにアクセスできる３つの異なるコンテクストを有する。１つのコンテクストは仕事関係である。他の２つは家庭生活に関係しているが異なるロケーションにある。ユーザーは、仕事のためのペルソナ１２２０と、家庭のためのペルソナ１２３０と、山小屋での生活のためのペルソナ１２４０とを作成することができる。各ペルソナは、異なる全般プロファイル１２５０、１２６０及び１２７０を参照し、それはそれぞれそのロケーションのアドレスを含んでいる。従って、３つの全般プロファイルがある。更に、各ペルソナは、２つの旅行プロファイルの内の１つを参照する。ユーザーは、チケット予約や予約の取り付けに関する全ビジネスルールを含む仕事旅行プロファイル１２８０を維持している。このプロファイルは、例えば、この人はビジネス又はファーストクラスでしか旅行せず、愛用の航空会社はユナイテッド航空であるということを示しているかもしれない。仕事ペルソナは、この仕事旅行プロファイルを参照する。ユーザーは更に、家族旅行プロファイル１２９０を維持しており、列車の普通席で旅行することが好きであり、一般的に安いので、払い戻しなしの料金のものを探していることを示しているかもしれない。家庭のためのペルソナと山小屋生活のためのペルソナとの両方が家族旅行プロファイルを指している。

図１３は、ペルソナの概念をサポートするデータモデルを示している。ユーザーテーブル１３１０は、システム内に口座を有する各ユーザーの記録を含んでいる。このテーブルは、独自の識別子並びにユーザーネーム及びパスワード１３２０を含んでいる。各ユーザーは、複数のペルソナ１３３０を有することができ、複数のペルソナは、プロファイル１３４０と呼ばれる更に専門化された構造に関するコンテナとして作用する。プロファイルは、プロファイルフィールド１３５０の記録として、詳細な個人情報を含んでいる。各プロファイルには、プロファイル制限１３６０記録のセットが付けられている。これらのそれぞれが、ネーム１３７０及びルール１３８０を含み、制限を定義している。ルールは、ルールをある用途に制限できる（ｘならｙ）のようなパターンの形式である。例えばプロファイル制限は、ユーザーがリスト内に含まれている或る航空会社のフライトを予約してはならないと指図するルールであるかもしれない。このプロファイル制限が、例えばユーザーの雇用者により設定された「仕事」ペルソナの「旅行」プロファイル内に含まれることもある。各プロファイルフィールドは、更に、その記録に含まれている許可セット１３９０を含んでいる。これらの許可は、誰が、特定のプロファイルフィールド情報にどんなアクセス権を有するかを指定する。

［意向中心型インターフェース］
退職又は移住に関する計画のような顧客の意向を満たすには、専門的なインターフェースが必要である。顧客の意向は、経済保証、住まい、輸送から、特に健康管理、個人的及び専門的自己啓発、娯楽に至る広範な領域に亘る計画と調整を必要とする。意向を満たすには、消費者のニーズに合わせて、複数の産業に亘り働く補完的ビジネスのネットワークが必要である。

意向中心型インターフェースは、ユーザーが個人の意向を上手く管理するのを助けるように設計されているユーザーインターフェースである。所与の何れのポイントにおいても、インターフェースのコンテンツは、特定の意向に関するコンテンツだけを示すようにカスタマイズされる。意向中心型インターフェースは、ユーザーが、その特定の意向を満たすプロセスを上手く管理できるようにする。このことには、一連の独立したステップとユーザーがアクセスできる一式のコンテンツ領域とが含まれている。何れのポイントにおいても、ユーザーは、インターフェースを切り替えて、異なる意向を管理することができ、この行為は、新しく選択された意向の充足に関わるコンテンツだけを含むように、インターフェースのコンテンツを変更することになる。

図１４は、意向中心型インターフェースをサポートするのに必要なデータモデルを詳細に説明している。各ユーザーのペルソナ１４１０（ペルソナのデータモデルの更に詳細な説明については図１３を参照）は、幾つかの稼動中のユーザーの意向１４２０を有する。各稼動中のユーザー意向には、ニックネーム１４３０が与えられて、それが、ユーザーがスクリーン上で見る表示ネームである。各稼動中のユーザー意向は、更に、ユーザーとの対話を通じて収集されたあらゆるユーザーデータを含む複数のデータフィールド１４４０を含んでいる。例えば、ユーザーがスクリーン上の書類に記入済みで、フィールドの１つが社会保障番号であった場合、対応するデータフィールドには、ネーム＝「ＳＳＮ」１４５０、値＝「９９９−９９−９９９９」１４６０が含まれることになる。更に各ユーザーの意向は、意向ステップ１４７０の完了状況の軌跡を保存する。完了１４８０のフィールドは、ユーザーがステップを完了しているかどうかを示す。全ユーザー意向は、全般的意向１４９０のユーザー特定バージョンであり、全てのユーザーに関するその意向に対するデフォルトモデルである。全般的意向は、意向内のサブステップに取り付けられているカスタムルール１４１１及び１４１２を通してカスタマイズされる。これらのカスタムルールは、個々のユーザーのプロファイル情報を使って、各ユーザー毎に、システムがどのように意向をカスタマイズするかを記述するパターンである。

［統計エージェント］
エージェントは、各ユーザー毎に、キーとなる統計の軌跡を保存する。これらの統計は、タマゴッチ・バーチャルリアリティのペットトイと同様の方法で用いられ、ユーザーからの或る行動を助長する。記録されている統計は、一定の期間内に実行されたタスク数で測定されるロジックの頻度、ニュース記事のようなコンテンツのレーティングの頻度、及びエージェントのアクティビティである。システムはこの情報を用いて、或る行動を喚起させるようにユーザーに感情的にアピールする。

図１５は、エージェントの現在の統計を表すページを作成するためのプロセスを示している。ユーザーがクライアントブラウザを使ってエージェント統計ページを要求する１５１０と、サーバーは、ユーザーのプロファイルデータベース１５３０からユーザーの統計を検索する１５２０。サーバーは次に、必要な数学演算を実行して、正規化された一式の統計を作成する１５４０。次にサーバーは、ユーザー中心型統計を計算するのに用いられるコンテンツデータベース１５６０から公式を検索する１５５０。次に、一般的な公式及びそのユーザーの統計を使ってグラフが作成される１５７０。これらのグラフがテンプレートに挿入され、統計ページが作成される１５８０。次に、このページはユーザーに戻される１５９０。
［個人向け製品レポートサービス］
本システムは、ユーザープロファイルに基づいてユーザー毎にカスタマイズされた消費者レポートのようなサービスを提供する。システムは、様々な面から製品の品質及び好感度に関する、ユーザーからのランク付けを記録して提供する。このシステムと伝統的な製品品質測定サービスとの相違点は、ユーザーに戻ってくるランク付けが各個人に合わせられているという点である。このサービスは、ユーザーのプロファイルに最もマッチし、且つ問い合わされた製品を先にランク付けした人を検索することにより行われる。このアルゴリズムを使えば、ユーザーに送り返される製品レポートが、確実に、そのユーザーに似ている人からの統計だけを含むようにすることができる。

図１６は、ユーザーのための個人向け製品ランク付けを決定するためのアルゴリズムを表している。ユーザーが製品Ｘの製品レポートを要求する１６１０と、アルゴリズムは、その製品を先にランク付けしたユーザーの（製品のランク付けを含む）プロファイルデータベース１６３０からプロファイルを検索する１６２０。次に、システムは、コンテンツデータベース１６５０から、プロファイルマッチングアルゴリズムに対するデフォルト閾値を検索する１６４０。次に、システムは、プロファイルマッチングアルゴリズムに指定された幾つかの項目に沿って、ユーザーの全ショートリストをマップする１６６０。次に、最も近くにあるｎ個（閾値変数として先に指定されている）が選ばれ、それらが、セット内のユーザープロファイルの距離ｙ内（同じく、閾値変数として先に指定されている）にあるかどうか判断する１６７０ため、プロファイルマッチングアルゴリズムからの結果を使ってテストが行なわれる。それらが閾値内にない場合、閾値変数は緩められ１６８０、もう一度テストが実施される。このプロセスは、テストが真を戻すまで繰り返される。次に、ｎ個の最も近いものの小セットからの製品のランク付けは、幾つかの項目に沿って複数の製品統計を判断するのに用いられる。これらの統計は、製品レポートテンプレートに挿入され１６９５、製品レポートとしてユーザーに戻される１６９７。
［個人プロファイル及びサービスの遍在］
このシステムは、１人のプロファイルに１つの中央記憶場所を提供する。この記憶場所は、公衆インターネットを通して入手できるサーバーであり、インターネットに接続されており、適切なアクセスを有していれば、どんな装置でもアクセス可能である。プロファイルのアクセス可能性が遍在しているので、ユーザーのプロファイルに基づいてそのユーザー用にサービスをカスタマイズするには、多数のアクセス装置を用いることができる。例えば、商人のウェブサイトは、このプロファイルを利用して個人向けのコンテンツをユーザーに提供することができる。インターネットアクセスを備えたパーソナルデジタルアシスタント（ＰＤＡ）は、インターネットサイト内に記憶されているバージョンを使って、個人のカレンダー、ｅメール、面会リスト、タスクリスト及びノートをＰＤＡ上で同期させることができる。このことにより、個人は、このデータの１つのバージョンだけを維持しておけば、必要なときはいつでも、且つ必要ならばどんなフォーマットででも、それを入手できるようになる。

図１７は、この集中的に記憶されているプロファイルにアクセスするための多くの異なる方法に関連する詳細なロジックを示している。プロファイルデータベース１７１０は、ユーザーのプロファイル情報の中央記憶場所である。プロファイルゲートウェイサーバー１７２０は、プロファイル情報に関する全要求を、ユーザー自身からであれ、サービスをユーザーに提供しようと試みている商人からであれ受信する。プロファイルゲートウェイサーバーは、プロファイル所有者が特別に許可を認めた場合にだけ、情報が与えられることを保証することに責任を負っている。ＴＣＰ／ＩＰ（標準的ネットワーク通信プロトコル）を通して公衆インターネット１７３０にアクセスできる装置は全て、インテリジェントなＨＴＴＰの要求を通して、プロファイルデータベースからの情報を要求できる。消費者は、テレビ、携帯電話、スマートカード、ガスメータ、水道メータ、台所の設備、セキュリティシステム、デスクトップコンピュータ、ラツプトップコンピュータ、ポケットオーガナイザ、ＰＤＡ及び自動車などの装置から、サービスへアクセスすることができる。同様に、商人１７５０は（各プロファイルを所有する消費者から許可があれば）これらのプロファイルにアクセスすることが可能であり、これによって、消費者にカスタマイズされた個人向けサービスを提供することができる。

遍在プロファイルに関して可能な利用法の１つは、ホテルのチェーンである。消費者は、自身を独自に識別するデジタル証書を保持するスマートカードを携帯できる。このスマートカードのデジタル証書は、システムによって発行されており、自身のプロファイル情報をプロファイルデータベースへ記録している。消費者は、このカードをホテルのチェーンに入れてチェック・インする。ホテルの従業員は、スマートカードを読み取り機に通し、消費者はピン番号を打ち込み、デジタル証書を開錠する。証書は（安全な送信プロトコルを使って）プロファイルゲートウェイサーバーに送られ、正しいと証明される。次にホテルには、先に指定されている消費者プロファイルの或る部分へのアクセスが与えられる。次にホテルは、ホテルルームの好み、並びに消費者の勘定情報全てを検索することができる。ホテルは、消費者の映画及び食事の好みにもアクセスすることができるので、その両方に関してカスタマイズされたメニューを提案できる。ホテルは、ｅメールを消費者の配偶者へ送り、その人がホテルにチェックインし、安全であることを相手に知らせることもできる。ホテルは彼がチェックインした後で、全取引情報を消費者のプロファイルへアップロードすることができる。このことにより、ホテルのパートナーは（再度、消費者の許可が与えられれば）ホテルが集めた消費者に関する情報を利用できるようになる。

［インテンションバリューネットワーク］
インテンションバリューネットワークでは、全体インテグレイタシステムが製品及びサービスのユーザーへの配信を調整する。インテグレイタは、ユーザーのプロファイル内に反映されているユーザーの好みに基づいて、物理的及び抽象的な製品及びサービスをユーザーへ提供する承認されたサプライヤのネットワークを管理する。インテグレイタは、サプライヤと消費者との関係を管理し、サプライヤが消費者の意向を満たすように調整する。インテグレイタは、消費者に製品及びサプライヤについての情報を提供し、とりわけ客観的なアドバイスを提供することにより、これを行う。

図１８は、消費者と１つのサプライヤを含むインテグレイタとの間の対話を詳細に開示している。ユーザーはウェブブラウザ１８１０にアクセスし、インテグレイタからの製品及び価格情報を要求する。要求は、ユーザーのブラウザからインテグレイタのウェブ／アプリケーションサーバー１８２０へ送られる。ユーザーの好み及び個人情報は、インテグレイタの顧客プロファイルデータベース１８３０から入手され、ウェブ／アプリケーションサーバーへ戻される。要求されている製品情報は、サプライヤの製品データベース１８４０から検索され、特定の顧客のためにカスタマイズされる。ウェブ／アプリケーションサーバーは、顧客に関する問い合わせ情報を使って、サプライヤの顧客情報データベース１８５０を更新する。次に、製品及び価格情報は、ウェブページ１８６０にフォーマットされ、顧客のウェブブラウザへ戻される。

［要約エージェント］
アプリケーション及びウェブサーバー上で実行されている一式のソフトウェアエージェントは、ユーザーの繰り返しの又はありきたりなタスクを引き受けるためにプログラムされている。エージェントは、ユーザーにより設定されたルールに従って働き、ユーザーにより明らかに定義されているタスクを実行することだけが許されている。エージェントは、ユーザーの請求書の支払いと、コンテンツ及びｅメールのフィルタリングと、タスク及びエージェント活動の要約ビューへの提供とを引き受けることができる。エージェントに対するユーザーインターフェースは、特定のユーザーに適するように修正することができる。

図１９は、ユーザーに対し言葉による要約を作成するために、エージェントにより処理される、好適な実施例によるロジックを開示している。ユーザーが要約ページを要求する１９００と、サーバーは、ユーザープロファイルデータベース１９３０から、エージェントタイプ、ルール及び要約レベルのようなユーザーのエージェントの好みを取得する１９２０。サーバーは、ｅメール、予定事項、ニュース、請求書のようなコンテンツ１９４０をコンテンツデータベース１９５０から入手する。エージェントは、プロファイルデータベース内に記憶されているルールを使ってこのコンテンツ全てを解析し、コンテンツを要約する１９６０。コンテンツは、テンプレートに従ってウェブページにフォーマットされる１９７０。コンテンツデータベース１９９０からのコンテンツと、データベース内に記憶されている音声テンプレートとを使って、エージェントの音声に関するテキストが生成される１９８０。この音声テキストが、ウェブページに挿入され１９９５、ページがユーザーに戻される１９９７。

［信用サードパーティ］
上記のシナリオは、ウェブサイトに、発行されたポリシーに従って情報のプライバシーの保証を維持することを要求する。このシステムは顧客の信用サードパーティであり、商業的機会を鼓舞するというよりも情報のプライバシーを失するような全ケースおいて、顧客に代わって活動する。信用サードパーティは、適所に、告知されたポリシーとの整合性を保証する一式のプロセスを有する。

［ｍｅＣｏｍｍｅｒｃｅ］
この用語は「ｅコマース」という用語を「個人向け電子コマース」という意味に拡張している。図２０は、好適な実施例によるディスプレイロジックを示している。ディスプレイは、情報を収集し、ユーザーの個人的な要件について対話するために、システムとの対話のプロセスを通じてユーザーをカスタマイズされ個人向けに処理された様々なシステムコンポーネントにガイドするエージェント２０００によって、マイクロソフトインターネットエクスプローラアプリケーションとして実行される。ユーザーは２０１０でユーザーネームを入力し、２０２０でパスワードを入力し、ボタンを選択する２０４０と、ログイン手続きが開始される。ロゴ２０３０が示唆するように、システムは電子コマースを個人向けの、いわゆる「ｍｅ」コマースへ変換する。

図２１は、好適な実施例による、毎日のロジスティックを管理するディスプレイを示している。ユーザーは、個人向けメッセージ２１９０を有するアニメエージェントによる挨拶を受ける２１００。ユーザーは、要件に基づいて、旅行２１１０、家庭の雑用２１２０、経済２１３０及び市場の動向２１４０を含む様々な活動から選択できる。又、ｅメール、カレンダリング及び書類準備などの日課のアイコン２１４２が、１つの作業から別の作業への迅速なナビゲーションが容易になるように設けられている。更に、ニュース及び関心のある他の項目を送信できるように、ダイレクトリンク２１４６が設けられている。ユーザーが置かれている場所に基づいて、様々なプロファイルを選択することができる。例えば、仕事、家庭又は休暇である。ユーザーが他の場所用の新しいプロファイルを要求する場合は、そのプロファイルを加えることができる。様々な努力をサポートするために、個人情報の様々な項目２１８０が、ユーザーから収集される。更に、情報がタイムリーで最新であることを保証するために、許可２１５０が項目２１８０に対して設定されている。

図２２は、好適な実施例によるユーザーのメインディスプレイを示している。世界のニュース２２２０及びローカルニュース２２１０が、ユーザーの好みに基づいて提供される。ユーザーは、更に、メインディスプレイに直に情報を提供する項目として、不動産２２３０も選択している。更に、異なるエージェント２２２０は、ユーザーの好みに基づいて提供される。

図２３は、好適な実施例によるエージェントの対話を示している。エージェント２３１０は、情報２３００をユーザーに連絡して、ユーザーの生命保険は変更が必要なことを示し、ユーザーに、ユーザーのための情報を最適に要約しているチャートを指し示している。現在のユーザーの統計に基づくより詳細な情報が使い易くなるよう、特別な情報２３９５が提供されている。更に、ユーザーの生命保険の必要性に関するチャート２３７０は、ディスプレイの中央で目立つように表示されており、ユーザーが適切な行為を決定するのを支援する。ボタン２３８０は、ポリシーの変更を容易にするために提供されており、一式のボタン２３９０は、ユーザーの保険要件の様々な視点を選択する際にユーザーを支援するために設けられている。

［イベントバックグラウンダ］
イベントバックグラウンダとは、イベントの直前にユーザーに送られてくる、来るべきイベントの短い説明である。イベントバックグラウンダは、このイベントに関する最新の情報により定期的に更新される。旅程及び宿舎のような適切な情報が含まれており、他にも、その場所にいるはずのユーザーの知人のような有用な情報も含まれている。イベントバックグラウンダの目的は、イベントに関する最新情報を、公衆ウェブサイトや、ユーザーのカレンダ及び面会リストのような多数のリソースから引き出して提供し、ユーザーが、所与の状況において最適に反応することができるようにすることである。

［周辺フレンドファインダ］
このソフトウェアは、友人、家族又は知人がユーザーの近くに居るか又は来る予定になっている場合に、ユーザーに通知する機会を探すものである。このソフトウェアは来るべきイベントを探してユーザーのカレンダを走査する。次にこのソフトウェアは、地図マップを使ってこれらのカレンダのイベントをユーザーの面会リストに登録されている人のカレンダイベントと比較する。次にこのソフトウェアは、照合をユーザーに通知し、特定の時にユーザーの近くに誰かがいる予定であることを告げる。

［情報オーバーロード］
情報オーバーロードという用語は、今では、その示唆するもの及び結果、並びに定義の両方において比較的よく理解されている。人々の、一時に使える注意量には限界があるが、その注意を要するものは日々増大している。つまり、過剰な情報と少な過ぎる時間が、現代の最高の知識人の生活を混乱させている主な要因である。

情報オーバーロードをダイナミックに扱うための最初の試みは、焦点が主に、情報量を減らすというような情報の知的なフィルタリングに置かれていた。しかし、これらのアプローチのほとんどは、単に情報ビットをランダムに取り除くのではなく、どんな情報が最終的にユーザーに示されるかということについて知ろうと努力した。これは、ユーザーの関心事に基づいて各書類を評価し、相当しないものは破棄することにより達成された。そのため、情報の質も高められた。

情報のフィルタリングは、単に、この新しい時代の情報を扱う第１ステップである。一度ミーティングに入ったら、事前にオフィスに届けられた、ミーティングの主題に関する重要な情報を含んだ書類など価値がない。ビジネスのスピードは、相互接続の技術によって加速され続けるので、どんなときでも、どんな場所でも質の高い情報を受信する能力が重要になる。この新しいアプローチは、知的情報配信と呼ばれ、新しい情報時代の先駆けである。

好適な実施例は、情報のオーバーロードを減らすだけでなく、ユーザーが必要とすればどこでもいつでも高品質の情報を配信するという試みの中で、上記の知的情報配信のセオリーを示している。言い換えれば、本システムは、正しい情報を、正しいユーザーに、正しい時間に、正しい場所で配信する。

（アクティブ・ナレッジ・マネジメントシステムの説明）
図２４は、好適な実施例によるアクティブ・ナレッジ・マネジメントシステムのブロック図である。システムは、１つ又は複数のサーバーに接続されているバックエンド２４００、個人の携帯無線クライアント（アウェアネスマシン）２４３０、２４３６、公衆クライアント（マジックウォール）２４１０、２４２０、ウェブクライアント２４４６、２４４８、ｅメールクライアント２４５０、２４６０から構成される。

（バックエンドサーバー（２４００）プロセス）
図２５は、好適な実施例によるバックエンドサーバーのブロック図である。バックエンド（図２４の２４００）は、次のソフトウェア、即ち、知的エージェントコーディネータ（Ｍｕｎｉｎ）２５８０、情報優先順位付けサブシステム２５３０、継続的且つ定期的に実行される情報を集めて処理する一式の知的エージェント２５００、２５０２、２５０４、ユーザープロファイルデータベース２５４２及び支援ソフトウェア、情報チャネルデータベース２５４０及び支援ソフトウェア、通信ソフトウェア２５５０、情報転送ソフトウェア２５６０、補助ソフトウェアが稼動するコンピュータシステムである。

（アウェアネスマシン（図２４の２４４６、２４４８））
アウェアネスマシンは、ハードウェア装置とソフトウェアアプリケーションの組み合わせである。ハードウェアは、ハンドヘルドパーソナルコンピュータと無線通信装置とから構成される。アウェアネスマシンは、少量づつの無線情報を継続して受信することにより、定期的に更新されるステート・オブ・オーナーズ・ワールドを反映する。一式の知的エージェントにより発掘され、処理されたこの情報は、メールメッセージ、各ユーザーの好みに合ったニュース、スケジュール更新、次のミーティング及びイベントのバックグランド情報、並びに天気及び交通から構成される。アウェアネスマシンは別の特許アプリケーションでカバーされている。

図２６は、好適な実施例によるマジックウォールのブロック図である。

（マジックウォール）
マジックウォールハードウェアには、以下のものが含まれる。
・バックエンドサーバーに接続されているコンピュータシステム２６４０
・存在、位置及び個人のアイデンティティを検知するセンサーアレイ２６３４、２６３０及び２６３２
・大きなタッチセンシティブディスプレイ２６２０
・音声入力２６１０／出力２６１４ハードウェア
マジックウォールソフトウェアは、以下をサポートする。
・現在のウェブ標準と互換性のあるマルチメディア
・音声認識
・タッチ入力
・音声使用可能なアニメキャラクターの形態をした知的エージェント表示
マジックウォールは、以下のように作動する。
１．ユーザーがマジックウォールの周辺に現れると、センサーアレイは、個人のＩＤ及び位置を含む環境キューを知的エージェントコーディネータへ送る「ユーザーがここにいる」イベントをトリガする。
２．ユーザーは、センサーアレイにより戻される情報に基づいて識別される。
３．マジックウォールは「ユーザーにロック」モードに切り替える。別のユーザーがアプローチすれば、システムはそのユーザーに、現在のユーザーにサービスする間は別のユーザーにサービスできないことを通知する。
４．知的エージェントコーディネータには、ユーザーの存在が通知される。
５．知的エージェントコーディネータは、そのユーザーとマジックウォール位置に適した、提示すべき時間感受性情報（例えば、交通レポート、ミーティングの催促）があるかどうかを判断する。そのような情報が存在する場合は、配信に向けて準備される。存在しない場合は、コントロールが情報優先順位付けサブシステムへ送られる。
６．情報優先順位付けサブシステムは、個人プロファイル、情報の新鮮度及び知的エージェントコーディネータの前の指示に基づいて、そのユーザーに最適な情報が何かを判断する。
７．その時と場所で、そのユーザーに最適であると識別された情報のページが示される。情報配信の行為には、知的エージェント表示のアニメーション及び音声の出力を含めることもできる。
８．ユーザーが望めば、ユーザーは、特定のページを示すことをマジックウォールに求めることができる。マジックウォールは音声の断片を認識し、要求されたページを識別して示す。
９．ユーザーがマジックウォール領域から離れると、センサーアレイは「ユーザー離脱」イベントをトリガする。
１０．マジックウォールは、待ち状態へ戻る。

（他のクライアント）
ウェブのクライアントは、ユーザーがマジックウォールを通して入手可能な同一の情報を見ることができるウェブページのセットへナビゲートする標準的ブラウザである。

ｅメールックライアントは、何れかの標準的ｅメールプログラムである。

（知的エージェントコーディネータの説明）
このコードは、アクティブ・ナレッジ・マネジメントシステム用のコーディネートエージェント（又はメタエージェント）である。このことは、異なる下位エージェント間での通信同様、システムと各ユーザーの間の全通信が、知的エージェントコーディネータにより操作される（コーディネートされる）ことを意味する。これらの下位エージェントの例は以下の通りである。
・バックグランドファインダー：ミーティングのテキストを、重要なキーワード及びフレーズを判断しながら構文解析し、各ユーザー毎にミーティングに関するバックグランド情報を見つけだすエージェント。
・交通ファインダー：ユーザーが居る場所に基づいて、各ユーザー毎に交通情報を見つけだすエージェント。
・各ユーザーのプロファイル内のデータの統計分析を行い、そのデータに関係するフィールドを更新することに責任を持つ別の幾つかのエージェント。

図２５の知的エージェントコーディネータ２５８０は、ユーザーのシステムへの「インターフェース」であり、ユーザーがそれを使ってシステムと対話する場合はいつでも、ＧＵＩか、又は別のエンドユーザーのインターフェースであるかにかかわらず、ユーザーは、最終的に知的エージェントコーディネータを取り扱っている（質問をするか又は指令を送る）ことになる。知的エージェントコーディネータは、１）ユーザーの活動をモニタする、２）情報要求を取り扱う、３）各ユーザーのプロファイルを維持する、４）ユーザーから他の各エージェントへの情報、及びその逆の情報を送る、という４つの主要な責任を負っている。

（ユーザーの活動をモニタする）
ユーザーがセンサーをトリガするときはいつでも、知的エージェントコーディネータが「環境キュー」を受信する。これらのキューにより、知的エージェントコーディネータは、情報を配信するためにユーザーがいる場所を理解するだけでなく、各個人の生活の標準パターン（到着時間、出発時間など）を学習できる。これらのパターンは、情報を配信する際のシステムの知性を高める意図で、継続して更新され、リファインされる。例えば、今日では、１個人が、複数のｅメール口座（仕事ベース、家庭ベース、携帯ベースなど）並びにそれらの全口座に関する検索プロセス内に含まれる複数の異なるコンピュータを有するのも珍しくない。従って、知的エージェントコーディネータが情報を正しい位置に配信することに成功するには、ユーザーが情報を見る確率を最大にするために、それらの全口座、及びユーザーがそれらにアクセスするであろう時間を考慮に入れなければならない。このことは、別のセクションで更に議論することにする。

（情報要求を操作する）
知的エージェントコーディネータは、各ユーザー毎に意図された情報を個人向けにし、各ユーザーの関心事を与えられた情報に正確に反映させるために、別のエージェントからの情報要求を操作する。これらの要求は、一般的にユーザープロファイルに関係する。例えば、あるエージェントが或るユーザーに交通レポートを準備していた場合、知的エージェントコーディネータからの、そのユーザーの交通地域（探索文字列）を要求してもよい。ユーザーのプロファイルデータへの全てのアクセスは、この方法でアクセスされる。

（ユーザープロファイルを維持する）
ユーザープロファイルは、ユーザーに関する幅広い情報を含んでいる。この情報は、ユーザー指定データと、知的エージェントコーディネータが、各ユーザーの情報及び活動から学習し、推察した情報とを混ぜ合わせたものである。プロファイル内に含まれるデータを保護するために、知的エージェントコーディネータは、全ユーザー情報要求を扱わなければならない。知的エージェントコーディネータは、より多くの日常的雑用において支援を行うために、ユーザーの活動を観察し、彼らの生活のパターンを学習しようと努力することにより、これらのプロファイルを継続して修正、更新している。知的エージェントコーディネータは、更に、別のエージェントを使って、各ユーザーの日々の活動から意味を拾い集める。これらのエージェントは、このデータを掘り起こし、各タイプの情報の定時配信に関する好み、並びに現在の関心事、長期的な関心事を発見しようと努めている。知的エージェントコーディネータの観察の別の重要な態様は、経路付けのために、各ユーザーが１日を通して居る物理的な場所を求めようというものである。

（情報経路指定）
多くの人は、一日中動いている。知的エージェントコーディネータは、観察（指示されていない学習）及び環境からのキューの両方によって、ユーザーがいる場所又は行きそうな場所を判断しようと試みることにより、この事実に敏感であろうとしている。このことは、ユーザーの情報を送る場所を決めるだけでなく、情報を送るフォーマットを決めるのに、確かに重要である。例えば、ユーザーが自分のデスクにいてウェブクライアントを使っている場合、知的エージェントコーディネータは、ユーザーのＰＣから作業に関する指示を受け取っているであろうし、そこに送るべき必要な情報を全て知っているであろう。更に、デスクトップＰＣは一般的に非常にパワフルであるので、十分に特徴のあるグラフィカルな強力バージョンを送ることができる。

しかし、別の状況、即ち、知的エージェントコーディネータが、あなたがビルを離れたという表示を（出口の隣のキーカードリーダーを経由して）受信したという状況を考えてみよう。知的エージェントコーディネータが、数分後に、あなたが緊急メッセージを受け取ったという通知を受信したとする。知的エージェントコーディネータは、あなたがビルを離れたことを知ってはいるが他の指示を受取っていなければ、あなたには、あなたのハンドヘルド装置（能力についてはわかっている）を通して連絡可能であると仮定し、グラフィカル指向バージョンではない緊急メッセージのテキストをハンドヘルド装置へと送ることになる。

（固有の革新）
アクティブ・ナレッジ・マネジメントシステムは、ナレッジマネジメント及び人間とコンピュータの対話の世界における、最も進んだ考案の幾つかを示す。主な革新には、以下のものが含まれる。
・上記に示されている知的エージェントコーディネータ。
・知的情報配信に関するセオリーの開発、実演及び理解。
・情報を配信する幾つかのチャネルへのサポートであり、それらのすべては、共通のバックエンドを利用する。例えば、ユーザーがマジックウォールの前にいれば、情報はマルチメディアリッチフォームで示される。システムが、ユーザーは移動中であると判断すれば、情報は標準テキストでアウェアネスマシンへ送られる。そのことにより、いつでもどこでもユーザーが情報を要求すれば、情報が容易に配信されるようになる。
・静的ユーザープロファイルに基づくばかりでなく、ユーザーの対話の履歴、及び「誰、何処、何時」という認識を含む現時点のリアルタイムな状況も考慮することによる、情報の個人化。
・知的エージェントコーディネータの意見、ユーザーの好み及びユーザーの対話の履歴を考慮した、迅速且つスケーラブルな情報優先順位付けサブシステムの利用。これにより、ありきたりの判断に関するロードが知的エージェントの部分から取り去られるので、エージェントが、システムのスケーラビリティを損なうことなく、更に洗練されて正確になる。
・音声認識及び音声合成を知的エージェントのアニメ化された表示及びタッチ入力と組み合わせると、システムとの能率的、直感的及び感情的に価値のある対話が提供される。

［好適な実施例によるサポーティングコード］
次のコードは、好適な実施例によるマイクロソフトアクティブサーバーページ環境に書き込みされ、実行される。これは、主にマイクロソフトＪスクリプトから成り、情報を問い合わせして、データベース内に記憶するために、複数のデータベース呼び出しがコード内に埋め込まれている。

（意向中心型インターフェース）

以上、様々な実施例を述べてきたが、それらは例として示したのであって、限定を加えるものではないことは理解頂けるであろう。従って、好適な実施の形態の幅及び範囲は、上記の実施例の何れにも限定されるものではなく、上記請求の範囲及びそれらと同等なものに従って限定されるべきである。

Claims (23)

1. 情報をユーザに送る方法であって、コンピュータプログラムによって実行される
   （ａ）電子カレンダにおいて特定される来るべきイベントに関連する情報であってメモリに記憶された情報から、目標イベントを記述する複数の用語を検索する第１の段階（２５０，３２０）であって、前記第１の段階は、前記複数の用語の抽出が前記目標イベントの予め決められた時間だけ前に自動的に始まるように、前記電子カレンダから前記目標イベントを記述する複数の用語を抽出することを含んでいる段階と、
   （ｂ）コンピュータプロセッサを使って、前記目標イベントを記述する複数の用語のうちの少なくとも１つに依存して、利用可能な複数の情報源から少なくとも１つの情報源を選択する第２の段階であって、前記少なくとも１つの情報源の数は、前記複数の利用可能な情報源の全てよりも少ない数である段階と、
   （ｃ）前記コンピュータプロセッサを使って、前記用語に基づいた問い合わせを生成する第３の段階と、
   （ｄ）前記コンピュータプロセッサを使って、前記問い合わせを使って前記少なくとも１つの情報源に前記用語について問い合わせて、目標イベントのための前記用語に関するバックグランド情報を取得する第４の段階と（２７０，２７５）、
   （ｅ）前記第４の段階によって取得した前記用語に関するバックグランド情報をメモリに記憶する第５の段階と、
   （ｆ）前記第４の段階と前記第５の段階を同一用語に関して複数回自動的に実行することによって、前記情報源から取得し、前記メモリに記憶された前記同一用語に関する複数のバックグランド情報の少なくとも一部を、ディスプレイ装置を介してユーザに送る第６の段階であって、前記複数のバックグランド情報は前記目標イベントよりも予め決められた時間だけ前に生成されるものである段階と、
   を含むことを特徴とする、情報をユーザに送る方法。
2. 前記第３の段階は、前記問い合わせを作成するために、所定の基準に基づいて前記用語を構文解析する段階を含むことを特徴とする、請求項１に記載の情報をユーザに送る方法。
3. 現在のユーザの入力に基づいてシステムをダイナミックに構成するために、システムに利用される定数を提供する第７の段階を含むことを特徴とする、請求項１に記載の情報をユーザに送る方法。
4. ミーティング規準との関連性に基づいて問い合わせの結果をランク付けする第８の段階を含むことを特徴とする、請求項１に記載の情報をユーザに送る方法。
5. 前記コンピュータプロセッサを使って前記目標イベントの情報を前記バックグランド情報で更新して前記バックグランド情報の要約を生成する第９の段階を含み、
   前記バックグランド情報の要約が以前に生成されているときは前記情報源から今回取得した前記バックグランド情報を前記要約に追加し、前記要約がまだ生成されていないときは前記情報源から取得した前記バックグランド情報に基づいて要約を作成することが含まれ、前記要約は目標イベントに先って作成又は更新されている、請求項１に記載の情報をユーザに送る方法。
6. 前記第９の段階は、ミーティング日付の近傍を前記要約のためのフィルター装置として利用することを特徴とする、請求項５に記載の情報をユーザに送る方法。
7. 前記問い合わせには、前記バックグランド情報を入手するためにインターネットに問い合わせすることが含まれる、請求項１に記載の情報をユーザに送る方法。
8. 前記問い合わせには、さらに、特定のサーチエンジンに対する問い合わせを最適化することが含まれる、請求項７に記載の情報をユーザに送る方法。
9. 情報をユーザに送るためのコンピュータプログラムが記録されたコンピュータ読み取り可能な記録媒体であって、前記コンピュータプログラムは、
   （ａ）電子カレンダにおいて特定される来るべきイベントに関連する情報から目標イベントを記述する複数の用語を検索する第１のコードセグメントと（２５０，３２０）、ここで、前記第１のコードセグメントは、前記複数の用語の抽出が前記目標イベントの予め決められた時間だけ前に自動的に始まるように、前記電子カレンダから前記目標イベントを記述する複数の用語を抽出することを含んでおり、
   （ｂ）コンピュータプロセッサを使って、前記目標イベントを記述する複数の検索された用語のうちの少なくとも１つに依存して、利用可能な複数の情報源から少なくとも１つの情報源を選択する第２のコードセグメントと、ここで、前記少なくとも１つの情報源数は、前記複数の利用可能な情報源の全てよりも少ない数であり、
   （ｃ）前記コンピュータプロセッサを使って、前記用語に基づいた問い合わせを生成する第３のコードセグメントと、
   （ｄ）前記コンピュータプロセッサを使って、前記問い合わせを使って前記少なくとも１つの情報源に前記用語について問い合わせて、目標イベントのための前記用語に関するバックグランド情報を取得する第４のコードセグメントと（２７０，２７５）、
   （ｅ）前記第４のコードセグメントによって取得した前記用語に関するバックグランド情報をメモリに記憶する第５のコードセグメントと、
   （ｆ）前記第４のコードセグメントと前記第５のコードセグメントを同一用語に関して複数回自動的に実行することによって、前記情報源から取得し、前記メモリに記憶された前記同一用語に関する複数のバックグランド情報の少なくとも一部を、ディスプレイ装置を介してユーザに送る第６のコードセグメントと、ここで前記複数のバックグランド情報は前記目標イベントよりも予め決められた時間だけ前に生成される、
   を含むものである、コンピュータ読み取り可能な記録媒体。
10. 前記第３のコードセグメントは、前記問い合わせを作成するために、所定の基準に基づいて前記用語を構文解析するコードセグメントを含んでいる、請求項９に記載のコンピュータ読み取り可能な記録媒体。
11. 前記コンピュータプログラムは、現在のユーザの入力に基づいてシステムをダイナミックに構成するために、システムに利用される定数を修正する第７のコードセグメントを含んでいる、請求項９に記載のコンピュータ読み取り可能な記録媒体。
12. 前記コンピュータプログラムは、ミーティング規準との関連性に基づいて問い合わせの結果をランク付けする第８のコードセグメントを含んでいる、請求項９に記載のコンピュータ読み取り可能な記録媒体。
13. 前記コンピュータプログラムは、前記目標イベントに関連した情報を前記バックグランド情報で更新して前記バックグランド情報の要約を生成する第９のコードセグメントを含み、
    前記バックグランド情報の要約が以前に生成されているときは前記情報源から今回取得した前記バックグランド情報を前記要約に追加し、前記要約がまだ生成されていないときは前記情報源から取得した前記バックグランド情報に基づいて要約を作成するコードセグメントを含み、前記要約は目標イベントに先って作成又は更新されている、請求項９に記載のコンピュータ読み取り可能な記録媒体。
14. 前記第９のコードセグメントは、ミーティング日付の近傍を前記要約のためのフィルター装置として利用する、請求項１３に記載のコンピュータ読み取り可能な記録媒体。
15. 前記第４のコードセグメントは、前記バックグランド情報を入手するために、インターネットに問い合わせするコードセグメントを含んでいる、請求項９に記載のコンピュータ読み取り可能な記録媒体。
16. 前記第４のコードセグメントは、特定のサーチエンジンに対する問い合わせを最適化するコードセグメントを含んでいる、請求項１５に記載のコンピュータ読み取り可能な記録媒体。
17. 前記コンピュータプログラムは、ミーティング情報の更新に応えて、前記更新に関連する追加要約情報を入手する第１０のコードセグメントを含んでいる、請求項１３に記載のコンピュータ読み取り可能な記録媒体。
18. 来るべきイベントを記述する要素の情報を保存するカレンダシステムにアクセス可能なコンピュータが実行する情報収集方法であって、
    目標イベントの発生が現時点から予め決められた時間だけ後になった場合、前記カレンダシステムから前記目標イベントの前記要素を自動的に抽出する第１の段階と、
    前記第１の段階によって抽出された前記要素について前記コンピュータにネットワークで接続された情報源に問い合わせを行って前記要素に関するバックグランド情報を取得する第２の段階と、
    前記第２の段階によって取得した前記要素に関するバックグランド情報をメモリに記憶する第３の段階と、
    前記第２の段階と前記第３の段階を同一要素に関して複数回自動的に実行することによって、前記情報源から取得し、前記メモリに記憶された前記同一要素に関する複数のバックグランド情報を前記目標イベントの発生前に利用可能にする第４の段階と、
    を有することを特徴とする情報収集方法。
19. 前記第１の段階は、前記目標イベントの前記要素にパターンマッチングを行う段階を含むことを特徴とする請求項１８に記載の情報収集方法。
20. 前記バックグランド情報の要約が以前に生成されている場合は、前記第２の段階は前記問い合わせに前記要約を含め、前記第４の段階は前記情報源から今回取得した前記バックグランド情報に基づいて前記要約を更新する段階を含み、
    前記バックグランド情報の要約が以前に生成されていない場合は、前記第４の段階は前記情報源から取得した前記バックグランド情報に基づいて前記要約を作成する段階を含むことを特徴とする請求項１８に記載の情報収集方法。
21. 前記ネットワークはインターネットを含むことを特徴とする請求項１８乃至２０のうちいずれか１項に記載の情報収集方法。
22. 前記第２の段階はサーチエンジンを利用して前記問い合わせを行うことを特徴とする請求項２１に記載の情報収集方法。
23. 前記情報源から取得した前記複数のバックグランド情報をランク付けする段階を更に有することを特徴とする請求項１８乃至２２のうちいずれか１項に記載の情報収集方法。