(57)【要約】  本システムおよび方法は、コンピュータ機能を個別設定するシステムを開示する。エンドユーザは、たとえば、複数の単純なＩＦ−ＴＨＥＮ命題論理を用いることによって、豊富かつ複雑なプレファレンスを容易に書くためのツールを与えられる。プレファレンスは次いで、クエリに変換され、構造化データに対して効率的に実行される。条件が満たされるプレファレンスは次いで、通知を提供し、または特定のフォルダにデータを格納するなどのアクションを実行する。さらに、本発明の態様によると、なかでも、データ、論理、イベントがすべて体系化され、そうすることによって、アプリケーションコンポーネントの間での、かつ複数のアプリケーションに渡る、データの共有を可能にする。
2007509416.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションプレファレンスクラスを拡張するシステムであって、
インスタンスレジストリコンポーネントと、
前記レジストリコンポーネントに登録される１つまたは複数の関数を含む第１のアプリケーションと、
前記インスタンスレジストリから候補関数を読み出し、第２のアプリケーションが第１のアプリケーションの前記関数を使用し得るように、前記第２のアプリケーションと前記第１のアプリケーションの間にバインディングを作成する拡張コンポーネントとを備えることを特徴とするシステム。
【請求項２】
前記インスタンスレジストリコンポーネントは、関数定義を格納する定義レジストリと、バインディングデータを格納するバインディングレジストリとを備えることを特徴とする請求項１に記載のシステム。
【請求項３】
前記関数は、条件を提供することを特徴とする請求項１に記載のシステム。
【請求項４】
前記関数は、イベントを提供することを特徴とする請求項１に記載のシステム。
【請求項５】
前記関数は、アクセス機構を提供することを特徴とする請求項１に記載のシステム。
【請求項６】
候補関数は、特定のアプリケーションへのバインディングに対してのみ使用可能であることを特徴とする請求項１に記載のシステム。
【請求項７】
前記バインディングレジストリは、拡張データファイル（ＥＤＦ）から関数バインディング情報を受け取ることを特徴とする請求項２に記載のシステム。
【請求項８】
前記バインディングは、前記関数を提供するアプリケーションが削除されると破壊されることを特徴とする請求項１に記載のシステム。
【請求項９】
条件定数を拡張するシステムであって、
プログラマチック定数を受け取る入力コンポーネントと、
複数のドメインに渡って格納されているデータから、前記定数の値を判定するアクセス機構コンポーネントとを備えることを特徴とするシステム。
【請求項１０】
前記定数は一次定数であることを特徴とする請求項９に記載のシステム。
【請求項１１】
前記定数はＮ次定数であることを特徴とする請求項９に記載のシステム。
【請求項１２】
アプリケーションプレファレンスクラス機能を拡張する方法であって、
候補関数バインディングについての情報を含む拡張データファイル（ＥＤＦ）を受け取ること、
１つまたは複数の関数バインディングを中央データストアに登録すること、および
中央データストア中に置かれたバインディング関数情報を使用して、第１のアプリケーションの関数を第２のアプリケーションにバインドすることを含むことを特徴とする方法。
【請求項１３】
前記第２のアプリケーションが前記バインディングを受諾するかどうか判定するために、受諾論理を適用することをさらに含むことを特徴とする請求項１２に記載の方法。
【請求項１４】
請求項１２に記載の方法を実施するコンピュータ実行可能命令が格納されていることを特徴とするコンピュータ可読媒体。
【請求項１５】
アプリケーションをアンインストールする方法であって、
中央の記憶場所から、アプリケーションの全登録内容を削除すること、
プログラムコンポーネントを削除すること、および
依存アプリケーションに通知することを含むことを特徴とする方法。
【請求項１６】
前記中央の記憶場所は、インスタンスレジストリであることを特徴とする請求項１５に記載の方法。
【請求項１７】
前記インスタンスレジストリは、定義レジストリおよびバインディングレジストリを備えることを特徴とする請求項１６に記載の方法。
【請求項１８】
登録内容を削除することは、前記定義レジストリおよび前記バインディングレジストリ中の登録内容を削除することを含むことを特徴とする請求項１７に記載の方法。
【請求項１９】
依存アプリケーションに前記通知することは、依存アプリケーションに、その依存関係をＮｏｔＡｖａｉｌａｂｌｅ状態におかせることを特徴とする請求項１５に記載の方法。
【請求項２０】
請求項１５に記載の方法を実施するコンピュータ実行可能命令が格納されていることを特徴とするコンピュータ可読媒体。
【請求項２１】
プログラマチック定数を拡張する方法であって、
プログラマチック定数を受け取ること、および
アプリケーションドメインを検索することによって、前記定数の前記値を解決することを含むことを特徴とする方法。
【請求項２２】
前記定数は一次定数であることを特徴とする請求項２１に記載の方法。
【請求項２３】
前記定数はＮ次定数であることを特徴とする請求項２１に記載の方法。
【請求項２４】
請求項２１に記載の方法を実施するコンピュータ実行可能命令が格納されていることを特徴とするコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概してコンピュータシステムに関し、より詳細には、コンピュータシステムを個別設定(personalize)するシステムおよび方法に関する。
【背景技術】
【０００２】
コンピュータおよびコンピューティング関連技術のユーザは一般に、２つの異なるカテゴリ、すなわち高い能力および知識を有する個々人ならびにそれ以外の人に分けられてきた。高い能力および知識を有する個々人は、コンピュータの使い方をよく知っており、その知識を、プログラムを作り、豊富かつ有益な振舞いを容易にしようという意志に向けている。コンピュータユーザのそれ以外の世界は、高い能力および知識を有する個々人に支配されている。というのは、こうした人達は、知識、情報、またはコンピュータを自分達の必要性に役立たせる能力への容易または低コストのアクセスを拒否しているからである。
【０００３】
技術が、アクセスに対するこうした障壁の一部を打破したとき、コンピューティングにおける飛躍的な進歩が起こった。メインフレームの世界において、コンピュータは、大企業以外が購入するのには高価すぎた。ミニコンピュータ、次いでパーソナルコンピュータ（ＰＣ）の出現が、コスト障壁を打破し、コンピュータを中小企業および個人に対して使用可能にした。１９８０年代、プログラマは、グラフィカルユーザインターフェイス（ＧＵＩ）アプリケーションを構築するために奮闘した。豊富かつ整合性のあるＧＵＩなしでは、プログラマは、ＰＣユーザにとって有益なアプリケーションを構築することができなかった。Ｖｉｓｕａｌ  Ｂａｓｉｃという変革ならびにコントロールおよびイベントに基づくＧＵＩ構成の使用が、豊富なアプリケーションをアプリケーション開発者が容易に構築することを可能にした。続いて、さらに多くのエンドユーザがこうしたアプリケーションを有効利用することができる、好循環が確立された。１９９０年代、エンドユーザは、情報へのアクセスの欠如を克服するために奮闘した。インターネットの普及は、この領域を一変させ、ほぼすべての有益な情報を、ブラウザを有する誰に対してもアクセス可能にした。しかし、克服される必要がある巨大な障壁が依然として存在する。
【０００４】
従来のコンピューティングは、個人向けではない。いわゆるパーソナルコンピュータには、真に「個人向け」であるものはごくわずかしかない。ローカルディスクに格納されているデータが個人向けであることは事実である。しかし、マシンの振舞い、すなわちマシンがユーザのために実施するアクション（群）は、数百万人のユーザに対してほぼ同一である。驚異的なほど高性能の汎用コンピュータを所有しているにもかかわらず、平均的なユーザは、そのようなコンピュータを、通信エンドポイントとして有用であり、検索エントリポイントとして有用であり、大市場向けの何らかの既製アプリケーションの実行に有用であるが、その他の点では、言葉の真の意味での「パーソナルコンピューティング」では全くない静的ツールとして扱う。現在のアプリケーションで使用可能な個別設定機能は、可能であり望ましいことの表面のみを扱っているに過ぎない。
【０００５】
さらに、従来のコンピューティングは、自動化されているのではなく手作業によるものであり、ユーザが適切なときに決定を行いその決定に基づいて操作を行うことを要求する。コンピュータのごく一般的なエンドユーザの毎日の作業を考えてみる。エンドユーザはなかでも、情報を集め、通信に反応し、通信を開始しまたは応答し、情報を組織化する。コンピュータは、人々の間の通信を改善し、情報へのアクセスを改善した。しかし、コンピュータは、適切なときに決定を行いその決定に基づいて操作を行うという責任からエンドユーザを免れさせるようなことはほとんどしなかった。
【０００６】
さらに、従来のコンピューティングは、コンテキストに即していない。コンピュータソフトウェアは通常、かなり静的であるとともにユーザの実際のコンテキストに無関係なオプションの設定を提供する。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
必要とされるのは、本当の意味で個別設定されるコンピュータシステム、すなわちエンドユーザの必要性および好みに気づき、そうした必要性ならびにユーザコンテキストによって指示されたように作用するシステムである。さらに、コンピュータシステムおよびソフトウェアは、１人または複数のエンドユーザにとって興味ある情報を集め選別するとともにユーザによって指定された方法でその情報に自動的に反応するパーソナルアシスタントを、すべてのエンドユーザに提供するべきである。
【課題を解決するための手段】
【０００８】
以下は、本発明のいくつかの態様の基本的な理解をもたらすために、本発明の簡略化した要約を表す。この要約は、本発明の包括的な概要ではない。本発明の主要な／重大な要素を明らかにすることも、本発明の範囲を詳述することも意図されない。その唯一の目的は、後で提示されるより詳細な説明の前置きとして、本発明のいくつかの概念を簡略化した形で提示することである。
【０００９】
情報エージェントシステム、アプリケーション、および方法が、本明細書で開示される。情報エージェントシステムは、情報エージェントアプリケーション（本明細書では、ＩＡアプリケーションと呼ばれることもある）を実行するプラットフォームを提供する。ＩＡアプリケーションは次いで、エンドユーザによってプログラミングされ、エンドユーザの実行アシスタントまたはエージェントとして利用されることができる。エージェントは次いで、エンドユーザ個人の生産性を大幅に高め、デスクトップアプリケーションおよび全パーソナル通信媒体（たとえば、携帯電話、ページャ、ＰＤＡなど）を統合するように作用し得る。
【００１０】
情報アプリケーションシステムの中心は、データの体系化である。体系化は、公知であり明確なパターンでのデータの構造化であり、複数のアプリケーションが相互に認識し作用することを可能にする。情報プロパティ、情報イベント、および決定論理はすべて、体系化されることができる。体系化された情報プロパティは、エンドユーザアプリケーションの基本となるデータ（たとえば、ｅメール、人々、グループ、場所など）を指す。情報プロパティは、異なる複数のアプリケーションに渡って、一貫性のあるデータ翻訳を可能にするように体系化され得る。情報イベントは、プログラム論理を付加するためのフックを提供する。こうしたイベントは、ハイレベルであり、経験の浅いエンドユーザによる理解を容易にするために、情報の流れに連結される。イベントも、体系化され得る。さらに、決定論理も体系化され得る。エンドユーザは、トレーニングを受けた開発者ではないので、プログラムが従来のプログラミング言語で書かれることを期待するのは妥当でない。そうではなく、体系化された論理的ビルディングブロック（たとえば、ＩＦ−ＴＨＥＮ命題）がエンドユーザに提供されることができ、そうすることによって、エンドユーザは、単純ではあるが豊富な組合せで、ブロックをつなぎ合わせることによってプログラミングすることができる。データの体系化、情報フック（イベント）、およびエンドユーザプログラミング機能は、結合されるとともにエンドユーザ論理を介して協働するアプリケーションからなる豊富なエコシステムを有する大きな価値をエンドユーザに与え、このエコシステムは次いで、未熟なエンドユーザがシステムインテグレータになることを可能にする。
【００１１】
さらに、本発明の態様によると、情報アプリケーションシステムは、重いおよび軽い情報アプリケーション両方をコンパイルし実行することができる柔軟な実行エンジンを含む。重いアプリケーションは、しばしばハイエンドサーバ上で実行されるとともに、なかでも高スループットおよびスケーラビリティを要求するアプリケーションを含む。軽いアプリケーションは、しばしばパーソナルコンピュータなど、より小規模のシステム上で実行されるとともに低遅延、データベースの占有スペースが小さいこと、および小型ワーキングセットを要求するアプリケーションである。比較的小さいアプリケーションでは、待ち時間とスループットの間のトレードオフが、比較的大きいサーバアプリケーションに対して反対にされる。したがって、本発明の実行エンジンは、特定のシステム要件（たとえば、低遅延、データベースの占有スペースが小さいことなど）を強化するようにトレードオフを行うことによって、異なる複数のアプリケーションプラットフォーム上でアプリケーションをコンパイルし、実行することができるという点において柔軟である。
【００１２】
本発明の別の態様によると、エンドユーザプレファレンスまたは規則は、逐次方式で開発されるが、組として実行される。逐次プログラミングモデルとは、開発者にとって最も自然なモデルであり、開発者が１つのプレファレンスに対して１つのイベントを指定することを可能にする。しかし、本発明の態様によると、システムは、逐次プログラム宣言を取得し、集合指向式で実行される条件クラスクエリを作り、そうすることによって、索引づけおよび重複除去のような技術を開発する。このことは、プレファレンスが、非常に効率的に評価され、開発者およびエンドユーザが、プログラムを逐次方式で概念化し、書くことに専念できるという点で、有益である。
【００１３】
本発明の別の態様によれば、新しいアプリケーションインストールシステムおよび方法が提供される。従来のシステムでは、アプリケーションのインストールは、データベースオブジェクト、テーブル、およびストアドプロシージャの急増を伴う。いくつかの例では、アプリケーションは、全く新しいデータベースを作成する。本発明は、１組の基底テーブルを提供することによって、アプリケーションのインストールを簡潔にし、促進する。アプリケーションをインストールするために、システムは、単に基底テーブルをアップデートする。アップデートは、プログラムアクション、条件、イベント、およびプロシージャをデータとして格納することによって遂行され得る。たとえば、プロシージャに関して言うと、プロシージャは、データストアに格納される一続きのテキストとして作成され得る。このようなプロシージャを実行するために、プログラムテキストは、単にデータストアから引き出され、実行されることができる。
【００１４】
本発明のさらに別の態様によると、システムは、条件／アクションに、異なる情報ドメインに渡って情報を関連づけさせるためのアクセス定数をサポートすることができる。アクセス定数は、異なるドメインに渡る情報交換またはデータ共有を容易にする。たとえば、アクセス定数ＭｙＦａｍｉｌｙは、アクセス関数が、ｅメールアプリケーションまたはカレンダアプリケーションによって格納されているデータを照会することによって、ＭｙＦａｍｉｌｙのメンバを判定することができるように定義され得る。体系化された論理およびアクセス機構(accessor)の複合は、少なくとも、プログラマ以外の人が効率的なドメイン間クエリを書くことを可能にするので、有益である。さらに、比較的少数のアクセス機構制約と複合される比較的少数の条件クラスが、それ以外の場合にはアプリケーション開発者によって提供されていなかった可能性がある、関心をひく複数の条件が利用されることを可能にする。
【００１５】
本発明のさらに別の態様によると、ユーザ定義プレファレンスは、アプリケーションの間の関係づけを可能にするように拡張され得る。かなりの程度まで、ＩＡアプリケーションの測度(measure)は、ユーザに提示される機能によって決定される。したがって、ＩＡアプリケーションが拡張可能である程度は、既存のアプリケーションのコンテキストにおいて新しいプレファレンスを定義する新しい条件およびアクションが、ユーザに対して使用可能とされる限度によって決定され得る。アプリケーションの拡張性は主として、アプリケーションがインストールされると、引き続き、元のアプリケーションの作者（達）によるそれ以上の介入なしで、新しい条件およびアクションがアプリケーションに追加されることを可能にすることを目指す。したがって、エンドユーザは、開発者による入力なしで、異なるアプリケーションによって提供される条件およびアクションを使用し、そうすることによって、アプリケーションの間の豊富な関係づけを可能にするプレファレンスを作成することができる。
【００１６】
さらに、本発明のシステムは、情報エージェントアプリケーションをサポートする。本発明の態様によると、このようなアプリケーションの１つは、データストアおよび関連するファイルシステム（たとえば、階層システム、恣意的または明示的関係により関連づけられるファイル）によって提供されるフォルダ、データコンテナ、または他のデータ組織システムの個別設定に関し得る。個別設定フォルダは、エンドユーザ指定論理またはプレファレンスによって定義されコントロールされる。したがって、エンドユーザは、イベントが起こるとフォルダの内容をコントロールする条件およびアクションを定義することができる。本発明の一態様では、イベントは、フォルダデータの変更（たとえば、ドキュメントが追加され、消去され、または修正される）に対応する。プレファレンス（たとえば、条件、アクション）は、この要約の目的のために、３つのカテゴリ、すなわちユーザに代わってアクションをとる（たとえば、経費報告に関するｅメールを、同様の名前のフォルダに移動する）プレファレンス、フォルダの内容をコントロールする（たとえば、最近２週間のうちに聞かれたすべてのジャズソングを、現在のジャズフォルダに保存する）プレファレンス、および最初の２つのプレファレンスの複合（たとえば、一定の金額より少ないすべての経費報告を、承認されたフォルダに格納し、エンドユーザに、このアクションを知らせるｅメールを送る）に凝縮され得る。
【００１７】
本発明のさらに別の態様によるアクティブフォルダを用いて、ワークフローのような活動が利用され得る。この場合、プレファレンスを使用するエンドユーザは、フォルダ中の項目により表される多段階タスクまたは工程を指定することができる。続いて、タスクまたは工程を完了するために、フォルダ項目に対してアクションがとられ得る。
【００１８】
クロニクル(chronicle)フォルダも、本発明の態様に従って使用され得る。クロニクルは、システムの１人または複数のユーザに関連する履歴およびコンテキスト情報を表す。本発明の態様によると、クロニクルは、データストアに格納され、エンドユーザに対して自由にアクセス可能とされることができる。したがって、エンドユーザは、履歴データに対する制御を保ち、制御に基づいてプレファレンスを書くことができる。たとえば、ユーザは、自分のワークグループの全員が、ある特定の株価についての履歴情報を見ることを可能にし得るが、グループのメンバが自分の席にいるか、それともミーティング中であるか、などのコンテキスト情報を制限することを望む場合もある。
【００１９】
上記の目的および関連する目的を達成するために、本発明の例示的な態様が、本明細書において、以下の記述および添付の図面に関連して説明される。こうした態様は本発明が実施され得る様々な方法を示すに過ぎず、こうした方法はすべて、本発明によって包含されることを意図する。本発明の他の利点および新規の特徴が、本発明の以下の詳細な説明を図面と併せ読むことにより、明らかになるであろう。
【発明を実施するための最良の形態】
【００２０】
ここで図面を参照して本発明が説明されるが、同じ参照番号は、全体を通して同じ要素を指すのに使われる。ただし、図面および図面に対する詳細な説明は、開示される具体的な形に本発明を限定する意図はない。そうではなく、本発明の精神および範囲内であるすべての修正形態、等価物、および代替形態を包含することを意図していることが理解されるべきである。
【００２１】
本出願において使われる「コンポーネント」および「システム」という用語は、コンピュータ関連のエンティティ、すなわちハードウェア、ハードウェアおよびソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのいずれかを指すことを意図している。たとえば、コンポーネントは、プロセッサ上で実行される処理、プロセッサ、オブジェクト、実行ファイル、実行スレッド、プログラム、および／またはコンピュータでよいが、それに限定されない。例として、サーバ上で実行されるアプリケーションおよびそのサーバ両方がコンピュータのコンポーネントとなり得る。１つまたは複数のコンポーネントが実行の処理および／またはスレッド中に常駐することができ、コンポーネントは、１台のコンピュータに配置され、かつ／または２台以上のコンピュータの間に分散されることができる。
【００２２】
本明細書で使用する「推論」という用語は概して、イベントおよび／またはデータを介して捕捉される１組の観察結果から、システム１００、環境、および／またはユーザの状態を類推し、または推論するプロセスを指す。推論は、たとえば、特定のコンテキストまたはアクションを識別するのに利用されることもでき、状態に関する確率分布を生成することもできる。推論は、確率的でよい。つまり、データおよびイベントの考慮に基づく興味の状態に関する確率分布の計算でよい。推論は、１組のイベントおよび／またはデータからより高レベルのイベントを構成するために利用される技術も指し得る。このような推論は、イベントが、時間が非常に近接して相関されるかどうか、ならびにイベントおよびデータが、１つまたは複数のイベントおよびデータソースからのものであるかに関わらず、観察された１組のイベントおよび／または格納されているイベントデータからの新しいイベントまたはアクションの構成を結果としてもたらす。
【００２３】
（情報エージェントプラットフォーム）
最初に図１に移ると、本発明の態様による情報エージェントシステム１００が示されている。情報エージェントシステム１００は、アプリケーションプログラミングインターフェイス（群）（ＡＰＩ）１１０、コンパイラ１２０、イベントコンポーネント１３０、コンテキストアナライザ１４０、体系化されたデータストア１５０、プレファレンス実行エンジン１６０、アクションコンポーネント１７０、および通知コンポーネント１８０を備える。システム１００は、様々な情報エージェントアプリケーションの実行を容易にするためのプラットフォームを提供する。システム１００は、自律システムでも、より大型のシステムのコンポーネント部でもよい。システム１００は、本発明の態様によると、コンピュータのオペレーティングシステムとともに利用されることができ、オペレーティングシステムは、パーソナルコンピュータならびに電話、および携帯情報端末（ＰＤＡ）などのモバイルデバイスを含むが、それに限定されない異なる複数のコンピューティングデバイス上で利用され得る。システム１００は、サーバ（たとえば、ＳＱＬＳｅｒｖｅｒ、ＷｉｎＦＳサーバ）上でも、加入サービスとも利用され得る。したがって、システム１００は、クライアント、サーバ、およびクライアントサーバ群サービス（たとえば、Ｏｕｔｌｏｏｋ、Ｅｘｃｈａｎｇｅ、およびＨｏｔｍａｉｌ）において情報エージェント機能を提供する様々な製品とサービスの間の相乗効果をもたらすために使用され得る。
【００２４】
ＡＰＩ１１０は、システム１００との対話を容易にするために、システム１００に含まれる。ＡＰＩ１１０は、情報エージェントシステム１１０内の様々なコンポーネントをセットアップするために、開発者によって使用され得る。さらに、ＡＰＩ１１０は、システム１００上で実行される情報エージェントアプリケーションに対して使用可能な、１つまたは複数のイベントソースおよび／または現在のユーザコンテキストから、複数のイベントを構築するのに使われ得る。さらに、ＡＰＩ１１０は、データストア１５０に格納されている論理スキーマを反映するとともにデータストア１５０にプレファレンスを書くのに使われ得る。本主題の範囲内であることが意図される、ＡＰＩ１１０の他の多くの使用法が、本明細書を読めば当業者には明らかになることが理解されるべきである。
【００２５】
データストア１５０は、体系化されたデータ用の、豊富な構造化ストアである。データの体系化、すなわち公知であり明確なパターンへのデータの構造化は、様々なアプリケーション対話を可能にするので、本発明にとって特に重要である。後でさらに詳しく説明されるように、データストア１５０は、情報エージェントアプリケーションによって、なかでも、たとえばイベントおよびプレファレンスのテーブルなど、アプリケーションに関連づけられたデータを格納するのに使われ得る。さらに、データストア１５０は、情報エージェントシステム１００に含まれるものとして示されているが、データストア１５０は、システム外部のコンポーネントとも相互作用し得ることが理解されるべきである。
【００２６】
コンパイラ１２０も、システム１００に含まれる。コンパイラ１２０は、情報エージェントアプリケーションをコンパイルするように作用する。具体的には、コンパイラ１２０は、開発者スキーマおよびエンドユーザプレファレンスをコンパイルする。本発明の一態様によると、テーブル、たとえばデータストア１５０に格納するために、コンパイラ１２０は、スキーマおよびエンドユーザプレファレンスの、データへの翻訳を容易にする。
【００２７】
システム１００は、イベントコンポーネント１３０も備える。イベントは、プレファレンス評価を開始し、評価に情報を提供するトリガである。イベントは、イベントソースから生じ、アプリケーションまたはデータに関する内部状態変更、および／または世界中の外部変更のいずれかでよい。イベントコンポーネント１３０は、ＡＰＩを介してアプリケーションから提出されたイベントを捕捉し、プレファレンス評価を開始することができる。たとえば、イベントは、新しいＳＭＴＰメッセージ、データストア１５０におけるデータ変更、オペレーティングシステムのアクション、明示的ユーザ操作、および／または他のプレファレンスアクションを受け取る簡易メール転送プロトコル（ＳＭＴＰ）プロバイダによって引き起こされ得る。イベントコンポーネント１３０は、サードパーティプロバイダから、かつインターネットおよびネットワークベースの通信、電話通信などの通信、ならびにソフトウェアサービス、ＸＭＬファイル、アプリケーション、およびデータベースを含むが、それに限定されない異なる複数のタイプのソースから、イベントを集めることも、イベントを受け取ることもできる。さらに、イベントコンポーネント１３０は、様々な方法によりデータを監視し、集めることができる。データを集める例示的な方法は、ファイルの追加に対するディレクトリの監視、ある特定のタイプのエントリに対する、システムおよびアプリケーションログファイルの調査、アプリケーションからの警告のトラッピング、ウェブページの監視、データベーステーブルにおける変更の追跡、ならびにウェブサービス（群）によって提供されるデータの検討を含むが、それに限定されない。
【００２８】
イベントコンポーネント１３０によってデータを収集するのに利用され得る、異なる様々なモデルも存在する。こうしたモデルは、どれだけ頻繁に、かつどのような状況で、イベントコンポーネント１３０が、様々なイベントソースからイベントを収集するかに影響し得る。
【００２９】
イベントコンポーネント１３０は、通知を受けることも、２つの方式の少なくとも一方で、データを与えられることもできる。イベントコンポーネント１３０は、情報が「プッシュ」される、すなわち送られるのを待つこともでき、ソースをポーリングするとともに新しいまたはアップデートされたどのデータも集めることによって、ソースから情報を「プル」することもできる。たとえば、ユーザが、気に入っているニュースページでヘッドラインストーリーが変わる度に通知されることを望む場合、イベントコンポーネント１３０は、たとえば、そのページを監視し、ヘッドラインテキストに対する変更を検索するように実装され得る。テキストが変わると、イベントコンポーネント１３０は、新しいヘッドラインデータを抽出し、たとえば、データストア１５０中のイベントテーブルにデータを格納することによって、このデータをシステム１００に与えることができる。上記の例において、プッシュ方法を利用する場合でのように、イベントソースからイベントコンポーネント１３０にデータが与えられないので、イベントコンポーネントは、必要とされるデータの収集を担当する。
【００３０】
さらに／あるいは、イベントコンポーネント１３０は、スケジュールに基づいて、または予め定義された基準を満たすイベントの出現に基づいて、システム１００用のイベントデータを得ることができる。スケジュールされたイベントコンポーネント１３０は、アプリケーション開発者によって実装された設定に基づいて周期的に実行され得る。スケジュールされたイベントコンポーネント１３０は、実行を開始し、新しいイベントデータを取得し提出し、次いで、スケジュールされた次のトリガ時間まで休眠することができる。イベント駆動型イベントコンポーネント１３０は、継続的に実行されることによって、イベントソースを監視することもできる。その後、データが、コレクションに対する特定の基準を満たすとき、イベントコンポーネントは、イベントの出現を収集し、または示すことができる。あるいは、イベント駆動型イベントコンポーネント１３０は、コールバック関数または他の何らかの外部刺激にのみ応答して実行され得る。この外部関数は次いで、収集すべき有効なイベントデータがあるかどうか判定し、このようなデータを収集する手段として、イベントコンポーネント１３０を使う。イベントコンポーネント１３０は、外部イベントソースからデータを収集すると、イベントテーブルにデータを書き、データベース１５０にイベントテーブルを保存することができる。
【００３１】
イベントを集め、かつ／または収集するのに、どのような方法（群）またはシステム（群）が使用されようとも、イベントは、効率のためにバッチとして書かれ、処理され得ることが理解されるべきである。バッチとは、本明細書においては一般的に定義されるが、グループとして処理される１組のデータ（たとえば、イベント、プレファレンスなど）でよい。グループまたはバッチの大きさは、たとえば、システムのセットアップ中に開発者によって決定され指定され、かつ／または制御パネルを介してユーザによって指示されることができる。
【００３２】
コンテキストアナライザ１４０によって集められた情報は、本発明の一態様によると、アナライザによって判定されるコンテキスト情報を含む。コンテキスト情報は、本実施形態の後のセクションにおいてより詳しく説明されるように、１つまたは複数のコンテキスト情報ソース（図示せず）に基づいて、ユーザがいる場所および注目状況を認識することによって、アナライザ１４０によって判定される。コンテキストアナライザ１４０は、たとえば、ユーザの車またはセル電話の一部である全地球位置発見システム（ＧＰＳ）により、ユーザの実際の場所を正確に判定することができる。アナライザは、ユーザのカレンダにおける日のタイプ、時刻、データ、およびユーザの活動についての観察のような情報を考慮して集められた、バックグラウンドでの評価および／または観察を考慮することによって、ユーザが所与の注目状態にある確度を判定するのに、統計モデルを利用することもできる。所与の注目状態は次いで、ユーザが定義したプレファレンスに対するイベントまたは条件として利用され得る。
【００３３】
プレファレンス実行エンジン１６０は、アクション処理にも関わり得る。プレファレンス論理は実際には、１組の結果を生じるに過ぎないが、この組は、このような結果に共通の効果なので、本明細書において、アクションとも呼ばれる。アクションを実行するためのプレファレンス実行エンジン１６０の利用は、アクションが実行され得る一方法に過ぎない。アクションは、単にシステム１００からプレファレンス結果を取得するとともにその結果に対して作用するアプリケーションによって実行されることもできる。システム１００の一部としての実行エンジンによるアクションの実行は、むしろアクティブエージェントの類であり、アプリケーションによるアクションの実行は、むしろ受動決定論理の類である。したがって、システム１００は、システム１００が、イベントコンポーネント１３０に対してイベント取得および処理のためのホスティングサービスを提供するのと同様の方法で、アクションを取得し実行し得るアプリケーションアクションハンドラ用のホスティングサービスを提供することができる。さらに、本発明の一態様によると、データに密接するアクション（たとえば、特定のフォルダへのｅメールの移動）が、プレファレンス評価ならびに同じトランザクションの一部と同期して、実行エンジン１６０によってシステム１００の内部で実行され得ることが理解されるべきである。
【００３４】
システム１００のプレファレンス実行エンジン１６０は、なかでも、プレファレンスを処理し、または評価する。プレファレンスは、イベントの出現によってトリガされるエンドユーザ定義規則である。システム１００によってサポートされ得る、同期および非同期という２つの活動化モデルがある。同期活動化モードでは、イベント提出とプレファレンス評価の間にはそれ程遅れがない。つまり、プレファレンス評価は、イベント提出への応答が返される前に完了し得る。対照的に、非同期活動化モードでは、イベント提出の完了とプレファレンス評価の完了の間に大幅な遅れがある。たとえば、一実装方法によると、非同期活動化によって提出されたイベントは、作用を受けることができるまで、キューに入れられる。システム１００は、一方または両方のモデルの活動化をサポートすることができる。さらに、本発明の態様によると、同期または非同期の振舞いは、処理に使用可能なバッチサイズおよび時間を含むが、それに限定されない複数の検討事項に従って、バッチ提出中に動的に選ばれ得る。プレファレンス処理の別の側面は、分離およびトランザクション境界を含む。たとえば、単一のイベントバッチに関連づけられたプレファレンスの処理は、トランザクション的でよい。あるいは、多くのイベントバッチが、１つのトランザクション単位としてまとめて処理され得る。システム１００は、上記モデルのシナリオの一方または両方をサポートすることができる。さらに、プレファレンス実行エンジン１６０は、イベント提出およびプレファレンス処理のトランザクション範囲を扱う。システム１００は、以下の２つのモデルの一方または両方をサポートすることができる。第一に、イベント提出およびプレファレンス処理は、同じトランザクションを共有することができ、そうすることによって、まとめて実行されることができる。あるいは、イベント提出およびプレファレンス処理は、異なるトランザクションにおいて起こり得る。
【００３５】
本発明の態様によると、実行エンジン１６０およびシステム１００は、軽いおよび／または重い情報エージェントあるいはプレファレンスアプリケーション両方をサポートすることができる。軽いアプリケーションは、低遅延、データベースの占有スペースが小さいこと、および小型ワーキングセットを要求するアプリケーションである。高スループットおよびスケーラビリティは、軽いアプリケーションに対する一次要件ではない。重いアプリケーションは、高スループット、スケーラビリティ、高い信頼性、厳密な正確さの保証、予測可能なクラッシュ回復、および容易な管理を要求するアプリケーションである。低遅延およびリソース消費は、重いアプリケーションに対する最優先事項ではない。高性能サーバは一般に、重いアプリケーションを実行し、軽いアプリケーションは通常、パーソナルコンピュータおよびモバイルデバイスなどを含むが、それに限定されない、比較的性能が低いシステム上で利用される。したがって、実行エンジン１６０は、重いアプリケーションと軽いアプリケーションとを区別し、特定のアプリケーションタイプ（たとえば、高スループット対低遅延）に最も反応して実行されるように変更を行わなければならない。概して、実行エンジンは、データベースの占有領域、コンポーネントの活動化における遅延、処理、メモリ占有領域、および永続プロセスに最も関連する。重いアプリケーションの実行は、（１）なかでも、複数のデータベース、テーブル、ビュー、ストアドプロシージャ、およびユーザ定義機能をサポートするような、広いデータベース占有領域の割振り、（２）イベント収集、通知生成、および通知分散のための短いポーリング間隔、ならびに（３）情報のバッチ処理を要求し得る。軽いアプリケーションの実行は、（１）最小のメモリおよびデータベース占有領域で利用され、（２）イベント収集、通知生成、および通知の配信（可能な場合）のために比較的長いポーリング間隔を使用し、かつ（３）イベントなどの情報を、小さいバッチで、または個別に処理することができる点で異なる。さらに、本発明の態様によると、ホストされるイベントプロバイダおよび特定の通知の配信は、システム応答時間の妨げとなると考えられる継続実行プロセスを必要とするので、軽いアプリケーションにおいてはサポートされることができない。ただし、実行エンジン１６０は、使用可能なリソースおよび現況技術に応じて、アプリケーションの「軽さ」の増分変化をサポートし得る点で柔軟であることが理解されるべきである。
【００３６】
システム１００は、アクションコンポーネント１７０も含むことが留意されるべきである。プレファレンスの評価が成功すると、プレファレンス実行エンジン１６０は、アクションコンポーネント１７０を呼び出して、１つまたは複数の有効なプレファレンスに従って何らかのアクションを実施することができる。アクションは、データストア１５０に影響を与え（たとえば、データを挿入し、消去し、または修正する）、かつ／あるいはシステム１００内部または外部の他のコンポーネントおよびシステムに影響を与え得る。アクションの具体的な一タイプは、ユーザ通知である。したがって、アクションコンポーネントは、通知コンポーネント１８０を有して示されている。
【００３７】
図２を参照すると、通知コンポーネント１８０がさらに詳しく示されている。通知コンポーネント１８０は、フォーマッタ２７２および配信プロトコル２７４を備える。通知コンポーネント１８０は、未加工の通知データを入力として受け取り、最終的にユーザデバイス（たとえば、コンピュータ、ＰＤＡ、携帯電話など）に届く、フォーマットされた通知を出力する。未加工の通知データが通知コンポーネント１８０によって受け取られた後、通知は、宛先デバイス用に、かつおそらくはユーザが好む言語向けにフォーマットされた可読通知に変換され、次いで、配信プロトコル（群）２７４によりデバイスに送られる。内容のフォーマット化は、１つまたは複数の内容フォーマッタコンポーネント２７２によって扱われるタスクである。内容フォーマッタ（群）２７２は、アレイにパッケージ化されている通知データを、入力として受け取る。標準的な配信に対して、アレイには、１つの通知記録用の情報を含むただ１つの要素があるべきである。１通のメッセージの中で複数の通知が利用者に送られようとされるダイジェスト配信に対しては、アレイ中に複数の要素が存在することができ、こうした要素はそれぞれ、１つの通知のデータを含む。内容フォーマッタ２７２は次いで、適切なフォーマット化を決定するのに、たとえば通知データに含まれる受信者情報を使用して、表示用にデータをフォーマットする。さらに、ダイジェスト配信が利用される場合、内容フォーマッタ２７２は、通知情報の適切な集約も担当する。内部的には、内容フォーマッタ２７２は、通知をフォーマットするのに、適切などの方式も用いることができる。たとえば、このような方式は、基本的な文字列操作の利用のように容易でもよく、拡張可能スタイルシート言語（ＸＳＬ）変換およびＡＳＰ．ＮＥＴレンダリングなどの使用のように、より複雑でもよい。内容フォーマッタは、タスクを完了すると、フォーマットされたデータを含む文字列を出力する。生成され得る何らかの通知ヘッダ情報を伴う文字列は、配信プロトコルコンポーネント２７４に渡される。
【００３８】
通知の配信は、配信プロトコル２７４により遂行される。通知のバッチが使用可能になると、通知コンポーネント１８０は、通知（群）の中の利用者データを読んで、適正なフォーマット化を決定する。通知コンポーネント１８０は次いで、配信プロトコル２７４を用いて、たとえば．ＮＥＴアラートやＳＭＴＰサーバなどの配信サービスに通知（群）を送ることができる。より具体的には、アプリケーションが実行中のとき、通知コンポーネント１８０は、各通知を読んで、利用者の配信デバイスおよびロケールを得ることができる。ディストリビュータは次いで、デバイスおよびロケールが複合されたものを、特定のフォーマッタオブジェクトと突き合わせて、最終的な通知を生成する。通知自体は、未加工の通知データ、フォーマット時に計算されるデータ、ならびに内容フォーマッタ２７２によって指定されたテキストの複合を含み得る。こうした選択肢は、専門的でユーザフレンドリーな通知テキスト、ならびにウェブリンクおよび商標情報の包含を可能にする。
【００３９】
システム１００は、内部通知（たとえば、ポップアップ通知）を扱うことができるが、システム１００は、外部サードパーティデバイスへの最終的な通知配信を扱わなくてよい。そうではなく、システムは、ｅメールゲートウェイや．ＮＥＴアラートサーバなどの配信サービスへのパイプと考えられ得る配信チャネル（図示せず）を使うことができる。具体的には、配信チャネルは、プロトコルおよびエンドポイントアドレスからなるものでよい。システム１００は、受信者に通知を送信する、通知コンポーネント１８０から外部配信システムへのパイプラインを提供するように、配信プロトコル２７４を構成することができる。通知コンポーネントは次いで、配信プロトコルコンポーネント２７４を使用して、通知をプロトコルパケットにパッケージし、１つまたは複数の配信チャネルに通知を送ることができる。配信チャネルは続いて、外部配信サービスにパケットを提示し、外部配信サービスは、最終的に指定受信者に通知（群）を送ることができる。
【００４０】
（情報エージェントアプリケーション（群））
図３を参照すると、本発明の態様による情報エージェントアプリケーション３００が示されている。アプリケーション３００は、システム１００上での展開単位であり、論理スキーマ３１０、ユーザインターフェイス３２０、決定論理コンポーネント３３０、イベントプログラミングコンポーネント３４０、およびタスクスケジュールコンポーネント３５０を備える。論理スキーマ３１０は、体系化された論理ビルディングブロックまたはエンドユーザによってまとめられ得るテンプレートを定義する。スキーマ開発者は、論理スキーマ３１０、ならびにデフォルトの振舞い、および例外が起きたときの振舞いの構築を担当する。実際には、論理スキーマ３１０は、エンドユーザ論理の実際の表現力を抑制し、そうすることによって、トレーニングを受けていないエンドユーザがアプリケーションを実際に「プログラミング」するのを現実的かつ実行可能にする。論理ビルディングブロックは、プレファレンスクラス、１組の条件クラス定義、および１組の起こり得る結果またはアクションを含み得る。条件およびアクションは、関連づけられたアプリケーション３００の機能および／またはユーザコンテキストに関連づけられ得る。さらに、本発明の態様によると、論理スキーマ３１０は、ＸＭＬ（拡張マークアップ言語）を使って定義され得ることが理解されるべきである。
【００４１】
本発明の態様によると、スキーマ論理３１０が定義することができる２種類のビルディングブロック、すなわちテンプレートされたブール関数を定義する条件クラス、およびテンプレートされたプロシージャを定義するアクションクラスがある。プレファレンスクラスとは、情報エージェントのスキーマ開発単位である。プレファレンスは、１組の許容条件クラス（たとえば、ＩｓＦｒｏｍ（Ｘ）、ＩｓＴｏ（Ｙ））およびアクションクラス（たとえば、ＭｏｖｅＴｏＦｏｌｄｅｒ（Ｚ）、Ｄｅｌｅｔｅ（））を含む。さらに、すべてのプレファレンスは、アクション（たとえば、ＥｍａｉｌＥｖｅｎｔ）を開始するための特定のイベントクラスまたはトリガに関連づけられる。スキーマ論理３１０が指定された後、スキーマ３１０は、コンパイラ１２０によってコンパイルされ、データストア１５０内の正規化されたシステムメタテーブルで維持されることができる。さらに、プレファレンスを評価することができるストアドプロシージャが、コンパイル期間中に作成され得る。スキーマ論理３１０およびプロシージャは両方とも、以後のアクセスおよび実行のために、体系化されたデータストア１５０に格納され得る。その後、ユーザがプレファレンスを指定しようとすると、プレファレンスは、その形式の整合性を検証するために論理スキーマ３１０と比較され、次いで、データストア１５０、たとえばプレファレンスからなる１つまたは複数のテーブルに格納されることができる。適切なイベントが起こると、システム１００は次いで、コンパイル時に作成されたストアドプロシージャを実行することによって、適切なプレファレンスが評価されるようにすることができる。本発明の態様によると、ストアドプロシージャは、索引づけおよび重複除去のような技術（後で説明される）を利用して、複数のプレファレンスを、集合指向方式でまとめて効率的に評価することができる。
【００４２】
ユーザインターフェイス３２０は、エンドユーザにプレファレンスオーサリングまたはプログラミングインターフェイスを提示する。エンドユーザは、トレーニングを受けた開発者ではないので、標準手続き型プログラミングまたはスクリプト記述は、ユーザにとって、論理を指定するのに実行できる選択肢ではない。したがって、論理は、たとえば、ユーザインターフェイス３２０を介して、クリックアンドドラッグまたはコピーアンドペースト方式で、エンドユーザに視覚的に表され提示されることができる。ユーザインターフェイス３２０は、アプリケーション３００内部のツールバーでも、完全に独立したグラフィカルユーザインターフェイス（ＧＵＩ）でもよいことが留意されるべきである。さらに、アプリケーション（群）３００は、ユーザインターフェイス３２０を含んで示されているが、アプリケーション（群）３００が、プレファレンスを定義するそれ自体のユーザインターフェイスを有することは必要ないことが理解されるべきである。アプリケーション（群）は、論理作成のために、オペレーティングシステムまたはアプリケーション特有のユーザインターフェイスを使用するように設計され得る。
【００４３】
アプリケーション（群）３００は、エンドユーザによって、プレファレンスまたは可変機能からなるプログラムを作成するのに利用され得る３つのコンポーネント、すなわち決定論理コンポーネント３３０、イベントプログラミングコンポーネント３４０、およびタスクスケジュールコンポーネント４３０も含む。決定論理コンポーネント３３０は、エンドユーザが決定論理（別名エンドユーザ論理）を定義することを可能にする。アプリケーションは次いで、様々な決定が、定義済みのエンドユーザ論理によって制御されることを可能にし得る。たとえば、エンドユーザは、警告がスクリーンにポップアップ表示され、ユーザを妨害し得るかどうか、また、それが、いつ、どのようにして行われるかを指定することができる。アプリケーションは、エンドユーザが決定論理をそれに対して付加し得るイベントを公開することもできる。たとえば、電子メールアプリケーションは、新しいｅメールがフォルダに届くと常にイベントを起こし得る。イベントプログラミングコンポーネント３４０は、エンドユーザが、たとえばメッセージの内容およびユーザのコンテキストに応じて起こり得る振舞いを指定するプレファレンスまたは規則を付加することを可能にする。規則中の条件は、他のアプリケーションのデータ（たとえば、送信者が同じワークグループであるかどうかを調べるためのアクティブディレクトリ）にアクセスすることができ、アクションは、本発明の一態様によると、他のアプリケーション４５０に影響を与えることも、別のイベントを起こすこともできる。タスクスケジュールコンポーネント３５０は、エンドユーザが、アドホックまたは予め定義されたタスクをイベント出現に付加することを可能にする。たとえば、顧客からの新しい苦情が発生すると、エンドユーザは、苦情を処理するために、予め定義されたワークフローの開始を選ぶことができる。
【００４４】
決定論理コンポーネント３３０は、エンドユーザが、開発者によって与えられた条件および結論テンプレートを組み合わせることによって、決定論理またはエンドユーザ論理プログラムを書くことを可能にする。決定論理は、「ＩＦ（ｃｏｎｄｉｔｉｏｎ）ＴＨＥＮ（ｒｅｓｕｌｔｓ）」というプレファレンスまたは規則を用いて指定され得る。このタイプの論理は、プログラミング経験が全くないエンドユーザであっても、このような規則を容易に理解し作成することができるので、エンドユーザによる指定に特に適している。たとえば、ＩＦ（ＴｈｅＤｏｇＢａｒｋｓ）ＯＲ（ＴｈｅＢｅｅＳｔｉｎｇｓ）ＴＨＥＮ（ＩＦｅｅｌＳａｄ）を考えてみる。この規則は、開発者ではない人、および子供でさえも、正しいユーザインターフェイスを与えられると、理解し表すことができるようなものである。このタイプのＩＦ−ＴＨＥＮ論理プログラミングは、少なくとも、人間の類推概念および言語コミュニケーションに合致するので、エンドユーザによる指定に適している。１つの規則のセマンティクスは、宣言的であり汎用的である。すなわち、条件が真である場合のみ、結果が真である。さらに、アクティブなコンテキストにおいてプレファレンス論理を適用することは、エンドユーザにとって直観的である。結果は、単なる自明のステートメント以上のものを受け取るアクションとなる。たとえば、ＩＦ（ＴｈｅＤｏｇＢａｒｋｓ  ＯＲ  ＴｈｅＢｅｅＳｔｉｎｇｓ）ＴＨＥＮ（ＴｈｉｎｋＡｂｏｕｔＲａｉｎｄｒｏｐｓＯｎＲｏｓｅｓ）となる。単一のＩＦ−ＴＨＥＮ規則においてさえも、許容される表現力の豊かさの程度は変わり得る。上の例は、命題論理にほぼ対応する。命題論理は、単純な真／偽命題が、論理ステートメントを作るように複合され得るという概念に基づく。ただし、述部論理、制約論理、および再帰を含むが、それに限定されないものを平均的なエンドユーザが指定するには複雑すぎる可能性があるより豊かな形の論理も、本発明とともに利用され得る。
【００４５】
プレファレンスは、ユーザインターフェイス（たとえば、制御パネル、ツールバー）を介して指定され得る。スキーマ開発者は、条件論理のビルディングブロックとして、１組の基本的な述部を与えることができる。エンドユーザは続いて、適切な条件を選び、適切な箇所にパラメータ値を割り当て、その値をブール演算子（たとえば、ＡＮＤ、ＯＲ、ＮＯＴ）で結合することができる。同様に、エンドユーザは、適切な結果を選び、適切な箇所にパラメータ値を割り当てることができる。エンドユーザ指定プログラムの豊富さは、開発者によって与えられる、体系化された論理による。こうした条件および結果テンプレートは、その内部論理、非常に様々な情報へのアクセス、エンドユーザアプリケーションの構造化データの包含において豊かであり得る。すべての条件も結果テンプレートも、パラメータリストを記述するスキーマを有することができる。エンドユーザは、適切なパラメータ値を単に与えることによって、こうしたビルディングブロックを使用することができる。
【００４６】
上述されてきたことは、情報エージェントシステム１００の受動使用であり、よりアクティブなスタイルが、後で説明される。システム１００の受動使用によると、アプリケーションは、適切な段階での決定論理の呼出し、および必要なパラメータの提供を担当する。アプリケーションは、結果に対して作用するための別のアプリケーションのコールも担当し得る。さらに、プログラムインフラストラクチャ、すなわちシステム１００は、プレファレンスを評価し、複数のプレファレンスの間の競合を扱い、適正な結果の組を判定するために、インタープリタ（図示せず）も必要とし得ることが留意されるべきである。
【００４７】
イベントプログラミングコンポーネント３４０は、情報エージェントアプリケーション３００用に、少なくとも３つの関数を提供する。最初に、イベントプログラミングコンポーネント３４０は、エンドユーザプログラムに対してフックとして作用し得る（たとえば、スキーマ開発者によって定義される）体系化された１組の情報イベントを提供することができる。各イベントは、構造化データを運ぶことができる。イベントインスタンスの捕捉のための、いくつかの機構（たとえば、イベント提出用ＡＰＩ）がある。情報イベントのいくつかのサブクラスもある。イベントの１つのサブクラスは、体系化されたデータストア１５０内で変化するデータに対応する。したがって、イベントプログラミングコンポーネント３４０は、ストア４２０におけるデータ変更にアクセスするための機構を提供し、こうした変更を、体系化された変更イベントとして利用可能にすることができる。イベントの別のサブクラスは、スケジュールされたプレファレンス活動にとって重要であり得る再発タイマイベントに対応し得る。イベントプログラミングコンポーネント３４０は、エンドユーザの「ハンドラ」論理を特定のイベントの出現に関連づける能力も提供することができる。さらに、イベントプログラミングコンポーネント３４０は、イベントを捕捉し、適切な決定論理を適用し、アクションハンドラを呼び出して決定の結果を実行するためのサービスを提供することができる。
【００４８】
イベントプログラミングコンポーネント３４０は、決定論理コンポーネント３３０と相互作用して、付加機能を提供することができる。たとえば、エンドユーザは、新しいイベントが届いたときに繰り返し適用される決定論理コンポーネント３３０を用いて、永続的な決定論理をセットアップすることができる。したがって、システムおよび／またはその上で実行されるアプリケーションは、すべてのトリガイベントが適切な決定論理の評価を引き起こすので、アクティブになり得る。より具体的には、トリガイベントは、決定論理への入力となることができ、プレファレンス論理評価の結果は、イベントプログラミングコンポーネント３４０がエンドユーザに代わって実行し得るアクションとなることができる。さらに、アクションは、新着イベントを引き起こすことができ、新着イベントは続いて、プログラミングコンポーネント３４０によって実行されるさらなる論理を引き起こす。したがって、アドホック連鎖式イベントプログラミングという概念が存在する。
【００４９】
タスクスケジュールコンポーネント３５０は、エンドユーザのタスクスケジュールまたはワークフローを管理する。本明細書において利用されるスケジュールとは、特定の順序づけまたは段階付けをその間に有する、組織化された１組のタスクである。タスク全体を実行する目的は一般に、たとえば４人の人々とのミーティングのスケジューリングという、実世界での何らかの目的を遂行することである。ミーティングの例では、スケジュールにおけるタスクは、なかでも、最初のミーティング要求の送出、ならびに肯定および否定応答の処理を含み得る。ワークフローは、ビジネスプロセスの自動化においてよく用いられ、本発明に関連して説明されるタスクスケジュールまたはワークフローは、エンドユーザ活動（たとえば、ミーティングのスケジューリング、ドキュメントの吟味、要求の委任など）に関連づけられる。こうしたワークフローの多くは、単純なプロセスであるが、カスタマイズ可能であり、エンドユーザに透過である。
【００５０】
タスクスケジュールコンポーネント３５０は、決定論理コンポーネント３３０およびイベントプログラミングコンポーネント３４０両方によって提供される機能と相互作用し、その機能を利用することができる。イベントプログラミングコンポーネント３４０は、タスクスケジュールをコールするための理想的なフックを提供する。たとえば、作業要求を含む新しいｅメールの到着が、タスクスケジュールを開始させ得る。いくつかのタスクスケジュールは、明快なプロセスフローを有して固定しているが、他の多くのタスクスケジュールは、柔軟であり、エンドユーザにいくつかのパスを選択させる。たとえば、ミーティング要求が、２人以上の出席者によって拒否された場合、ミーティングはスケジュールし直されてもよく、あるいはミーティングが開催されてもよい。このミーティングの例は、エンドユーザプレファレンスおよび決定論理コンポーネント３３０の使用にとって、都合のよい領域である。さらに、本発明の代替態様によると、スケジューリングが、変更に対する反応および適切なアクションの呼出しを伴うので、タスクスケジュールコンポーネント３５０は、イベントプログラミングコンポーネント３４０に組み込まれ得ることが留意されるべきである。要するに、タスクスケジュールの一部は、開発者によってハードコードされ得るが、エンドユーザプログラミングにより自動化されるものである明示的なユーザ決定によって構成される流れを動的にすることによって、大幅な価値が加えられる。
【００５１】
本明細書において説明される情報エージェント概念に対して、少なくとも２つの中心要素がある。第一に、アプリケーションの振舞いを制御する決定論理を提供するエンドユーザの能力が重要である。この能力は、単にエンドユーザのアプリケーションプログラミング能力であり、エンドユーザに代わって作用するエージェントを実際には伴わない。このことは、本明細書において、エンドユーザ論理の受動呼出しと呼ばれる。第二に、情報エージェント概念における重要な要素は、エンドユーザが、アクティブである決定論理を提供する能力である。アクティブである決定論理は、適切な情報イベントが起こると繰り返し適用されることができ、そうすることによって、エンドユーザの代わりにソフトウェアエージェントとして作用する。どちらの場合でも、決定論理は通常、コンテキストに関わり、すなわち、ユーザのコンテキストおよびアプリケーションの状態に依存する。こうした２つのコンテキストカテゴリにおける様々な種類のシナリオが、これ以降説明される。さらに、情報エージェントがとり得る様々な「人物」の形でのエンドツーエンドのシナリオも説明される。
【００５２】
エンドユーザ論理の受動呼出しの一例は、情報エージェントを使用してユーザへの割込みをコントロールするオペレーティングシステムである。何らかのアプリケーションが、音とともにスクリーンにポップアップ表示を起こそうとすると必ず、オペレーティングシステムは、何が起こるか判定するために、情報エージェント決定論理コンポーネントをコールするＡＰＩを使用することができる。表示、保留、消去、および転送など、決定論理コンポーネントによって示され得るいくつかの結論が起こり得る。何をすべきかを決定論理コンポーネント３３０が知らせると、オペレーティングシステムは次いで、実際の決定を実施することができる。
【００５３】
決定論理コンポーネント３３０は、従来のプログラムの選択肢をカスタマイズするのにも利用され得る。たとえば、従来のｅメールプログラムは、受信確認を読み、署名を加えるための、かつメールの優先順位に対する選択肢を提供する。受信確認の読取りに関して、しばしば、受信確認を読むことが可能にされるべきかどうかを示すチェックボックスがある。決定論理コンポーネント３３０は、この選択肢をカスタマイズし、重要なメッセージ、または自分が処理するように送られたメッセージに対してのみ、受信確認の読取りを可能にすることができる。さらに、ユーザは通常、発信メッセージに署名を加えることができるが、決定論理コンポーネント３３０の利用は、動作をより有益にし、指定受信者に応じてメッセージに署名を添付することによって、個別設定させることができる。最後に、ｅメールの優先レベルは通常、送信者によって決定され設定される。決定論理コンポーネント３３０を使用することによって、メールの優先順位は、たとえば受信者の現在のコンテキストに応じて、受信者によって決定されることもできる。さらに、エンドユーザ論理は、上記のような状況において何をするか（たとえば、署名の付加）を決定するためだけでなく、アクションの内容がどのようなものであるべきか（たとえば、どのような署名が実際に付加されるべきか）を決定するのにも使用され得ることが留意されるべきである。
【００５４】
決定論理コンポーネント３３０を介したエンドユーザ論理のアクティブな呼出しは、複数の状況において使用され得る。たとえば、画像がカメラからダウンロードされる際の画像のカテゴリ分類や、組織化規則に従って受け取られるｅメールなど、データを組織化するのに、アクティブロジックが利用され得る。アクティブロジックは、新しいｅメールが届き、受信者が自分の席にいないとき、メールを受信者の携帯電話に転送するなど、変化に対して反応するのにも使用され得る。アクティブロジックは、ユーザが応答可能でないときに、たとえばユーザの電話に応答し、たとえばユーザが電話を受けることができるようになったときに返答することによって通信を改善するのにも使われ得る。さらに、アクティブロジックは、ユーザが、たとえば出張先で悪天候が予想されるときに通知され得るように、情報の発行に登録するのに用いられ得る。さらに、アクティブロジックは、コンテキストを維持するのに利用され得る。たとえば、ユーザが異なる場所でミーティングに参加し退席するとき、コンテキストは適切にアップデートされ得る（たとえば、遠くまたは近くにいる、忙しいまたは時間に余裕がある、など）。
【００５５】
情報エージェントは、実際の人間のエージェントがユーザに対して行うのと全く同じように、様々な役割を果たし得る。したがって、情報エージェントは、通信を改善する秘書、情報を組織化する図書館司書、プリンシパル(principal)／ユーザに機会を気づかせるサービスエージェント、プリンシパル／ユーザが面倒なことに巻き込まれないようにする監視人、およびプリンシパル／ユーザのルックアンドフィールをよくする従者を含むが、それに限定されない様々な人物になり得る。秘書として、情報エージェントは、プリンシパル／ユーザが応対可能でないときに電話に応答し、発信者を、応対可能でないユーザのボイスメールに転送し、電話が応対されなかったことを示すインスタントメッセージをユーザに送るなど、様々な機能を実施し得る。図書館司書として機能するとき、情報エージェントは、デジタル写真およびｅメールを組織化することができる。サービスエージェントとして、情報エージェントは、プリンシパルに、たとえば株または不動産を売買する機会を継続して知らせることができる。監視人として働く情報エージェントは、銀行口座の残高が最低残高を下回ったときにプリンシパルに通知し、クレジットカードの利用額が利用限度額に近づいたときにプリンシパルに通知し、請求が期限通りに支払われるように通知を与え、かつ／またはコンピュータのバッテリまたはディスクが一杯になっていることをプリンシパルに警告することができる。従者として、情報エージェントは、重要な顧客からの着呼に関する全ドキュメントおよびｅメールを前に出し、かつ／または、プレゼンテーションの最中に、動揺を与えるような通知がポップアップ表示されないようにする。
【００５６】
（論理スキーマ）
図４に移ると、本発明の態様による例示的な論理スキーマ４００が示されている。論理スキーマ４００は、条件クラス４１０、アクションクラス４１５、イベントクラス４２０、プレファレンスクラス４２５、バインディング４３０、クロニクル４３５、競合解決４４５、明示的実行順序４５０、必要条件およびアクション４５５、テンプレート４６０、ならびにスケジュールされた再発プレファレンス４６５を備える。例示的な論理スキーマ４００および上述したスキーマコンポーネントは、説明を簡単にするために与えられている。したがって、論理スキーマ４００は、上述したコンポーネントすべて、コンポーネントの部分集合、および／または本明細書において記述されない追加スキーマコンポーネントを含み得ることが理解されるべきである。上述したように、スキーマ開発者は、エンドユーザによってまとめられ得る体系化された論理ビルディングブロックを定義する。２種類のビルディングブロックとは、条件クラス４１０およびアクションクラス４１５である。条件クラス４１０は、テンプレートされたブール関数を定義することができ、アクションクラス４１５は、テンプレートされたプロシージャを定義することができる。プレファレンスクラス４２５は、情報エージェントスキーマの開発単位である。プレファレンスクラス４２５は、なかでも、１組の許容条件クラスおよびアクションクラス、バインディング４３０、競合解決４４５、ならびに必要条件４５５を含み得る。さらに、すべてのプレファレンスクラス４２５は、プレファレンス用にトリガイベントを定義する特定のイベントクラス４２０に関連づけられ得る。以下は、情報エージェントのｅメールアプリケーション用のプレファレンスクラスの例である。
【００５７】
【表１】
2007509416.tif 000003
【００５８】
プレファレンスは、エンドユーザ論理の単位である。プレファレンスは、「ＯＮ（ｅｖｅｎｔ）ＩＦ（ｃｏｎｄｉｔｉｏｎ）ＴＨＥＮ（ａｃｔｉｏｎｓｅｔ）」の形の論理ステートメントでよい。すべてのプレファレンスはしたがって、次のプロパティをもつことは要求されるべきでない。第一に、プレファレンスは、プレファレンスクラスに属すべきである。第二に、プレファレンスは、何らかのユーザまたはプリンシパルによって所有されるべきである。第三に、条件は、条件クラスの１つまたは複数のインスタンスを複合した宣言型ブール値表現であるべきであり、すべての条件インスタンスは、条件クラス用のパラメータ値を定義する。最後に、アクションセットは、１組のアクションクラスであるべきである。すべてのアクションインスタンスは、アクションクラス用のパラメータ値を定義する。たとえば、次のようになる。
【００５９】
【表２】
2007509416.tif 000004
【００６０】
エンドユーザは次いで、イベントハンドラを定義することによって、「プログラミング」することができる。各イベントハンドラは、同じプレファレンスクラスの１組のプレファレンスによって定義され、したがって、同じイベントによってトリガされる。たとえば、次のようになる。
【００６１】
【表３】
2007509416.tif 000005
【００６２】
続いて、特定のイベントが起こる（たとえば、ｅメールが届く）と、複数のプレファレンスが、有効な１つの条件をもつ場合があり、複数のアクションを実行する可能性につながる。様々な競合解決機構が次いで、後で説明されるように適用され得る。
【００６３】
さらに、すべての条件は、呼出しパラメータを伴うブール関数に過ぎないことが理解されるべきである。本発明の一態様によるとセマンティック論理は、アプリケーション境界に及ぶことが要求される。したがって、条件は、異なる複数のアプリケーションによって作成されたデータを閲覧できる必要がある。たとえば、次のようになる。
【００６４】
【表４】
2007509416.tif 000006
【００６５】
上記の例はすべて、ユーザコンテキストを扱う。ユーザコンテキストは、コンテキストアナライザ１４０（図１）によって決定され、情報エージェントアプリケーションが使うためにデータストア１５０（図１）に格納されることができる。したがって、「Ｂｏｏｌ  ＩｓＯｎｌｉｎｅ（Ｘ）」のような関数は、渡されるＸという人の識別、およびコンテキストアナライザによって判定されるＸの現在のコンテキストに基づいて、真または偽を返すことができる。
【００６６】
上記の例で続けると、ＩｎＢｏｘＰｒｅｆｅｒｅｎｃｅＣｌａｓｓなどのプレファレンスクラスのスキーマ開発者は、エンドユーザが使うために、条件クラス４１０を与える必要がある。条件クラスが与えられ得るための、いくつかの方法がある。たとえば、条件クラスは、ＩｓＯｎｌｉｎｅ（）でよい。この場合、エンドユーザは、「ＩＦ（ＩｓＯｎｌｉｎｅ（Ｅｍａｉｌ．Ｓｅｎｄｅｒ））ＴＨＥＮ．．．」の形のプレファレンスを定義することができる。あるいは、条件クラスは、ＳｅｎｄｅｒＩｓＯｎｌｉｎｅ（）でもよく、クラスの宣言において、スキーマ開発者は、ＳｅｎｄｅｒＩｓＯｎｌｉｎｅ（）をＩｓＯｎｌｉｎｅ（Ｘ）にバインドし、ＸをＥｍａｉｌ．Ｓｅｎｄｅｒにバインドすることができる。したがって、エンドユーザは、プレファレンスまたは規則を「ＩＦ（ＳｅｎｄｅｒＩｓＯｎｌｉｎｅ（））ＴＨＥＮ．．．」と定義することができる。本発明は、条件クラス４１０を指定する複数の形をサポートするが、上述した形には大きな違いがあることが留意されるべきである。第１の形は、従来の叙述計算規則の形であり、規則をオーサリングする人（すなわち、エンドユーザ）は、スキーマおよび変数バインディングを類推する。第２の形は、比較的柔軟性がないが、エンドユーザが利用するのに、確実により容易である。したがって、クラス条件４１０は、スキーマ開発者がエンドユーザ論理の表現力を制限することができるエリアであり、そうすることによって、経験の浅いエンドユーザが情報エージェントアプリケーションを「プログラミング」するのをより現実的かつ実行可能にする。
【００６７】
要するに、スキーマ開発者がプレファレンスクラス４２５をオーサリングするとき、１組の条件クラス宣言４１０が作られる。各条件クラス宣言は、実装関数およびその関数に対する、開発者定義表現によってバインドされるいくつかのパラメータを識別する。それ以外のパラメータは、プレファレンスをセットアップするときに、エンドユーザによってすべての条件インスタンスに対して与えられる定数である。アクションは、アクションクラス４１５のインスタンスである。各アクションクラス４１５は、パラメータを有するプロシージャである。条件と同様、パラメータは、開発者によってバインドされることもでき、エンドユーザによって定数として割り当てられることもできる。さらに、イベントクラス４２０は、イベントの定義を提供する。イベントクラスは、開発者によって指定され、またはエンドユーザによって割り当てられるように、プレファレンス評価をトリガするイベントの情報内容を定義する。
【００６８】
本明細書全体において述べるように、また、本発明の態様によると、エンドユーザは、経験を積んだプログラマであることは期待されない。したがって、プレファレンスは、直観的名称（たとえば、ＥｍａｉｌＩｓＦｒｏｍ（））を有する条件に基づいて作成され、条件への引数は、単純なユーザ定義定数（たとえば、Ｍａｒｙ）でよい。このことは、エンドユーザが、ＥｍａｉｌＩｓＦｒｏｍ（Ｍａｒｙ）によってトリガされるプレファレンスを書くことを可能にする。ただし、ユーザによって与えられる文字列定数にのみ基づく引数をもつのは、制限が多すぎる。したがって、バインディング４３０は、エンドユーザにとってプログラミングをより容易にするとともに、情報がそこから取得され得るドメインを拡大するように、論理スキーマ４００においてプレファレンスクラス４２５の一部として指定され得る。スキーマ４００において指定され得る、少なくとも３タイプのパラメータバインディングがある。第一に、定数を予め定義する定数バインディングが指定され得る。定数バインディングの指定は、少なくとも、定数を選び、または指定する義務からエンドユーザを解放するので、有益である。イベントにバインドされる表現も、条件およびアクションに引数として与えられる値にバインドされ得る。より具体的には、値を計算するのにイベントフィールドおよび定数を使う表現が定義され得る。たとえば、次のようになる。
【００６９】
【表５】
2007509416.tif 000007
【００７０】
最後に、定数アクセス機構が定義され得る。定数アクセス機構は、オブジェクトからなる、このような各オブジェクトを手作業で指定しなければならないユーザに代わって、条件およびアクションに引数を与える、名前をつけられたグループである。
【００７１】
定数アクセス機構は、様々なドメインから情報をナビゲートし、取得することができるプレファレンスおよび条件が書かれることを可能にする、非常に強力な定数である。こうした定数は、正しい情報、すなわち、定数名に関連づけられたグループのメンバを見つけ、実体化するように動作する関数に表面的につけられた名前に過ぎない。手短に図５に移ると、本発明の態様による定数値を取得するシステム５００が示されている。システム５００は、アクセス機構入力コンポーネント５１０、アクセス機構コンポーネント５２０、ならびに複数のドメイン５３０、５４０、および５５０（ドメイン１からドメインＮであり、Ｎは１より大きい）を備える。アクセス機構入力コンポーネント５１０は、入力としてＭｙＦａｍｉｌｙ、ＭｙＣｏｗｏｒｋｅｒｓ、またはＭｙＦｒｉｅｎｄｓなどの定数を受け取り、こうした定数をアクセス機構コンポーネント５２０に与える。アクセス機構コンポーネント５２０は、アクセス可能な全ドメイン５２０、５３０、および５４０を検索して、試行および解決を行い、または入力定数によって指定されたグループのメンバに関連づけられた値（群）にリンクするように動作可能である。本発明の一態様によると、ドメイン５３０、５４０、および５５０は、体系化されたデータストアに格納されているアプリケーションでよい。たとえば、ドメイン５２０はｅメールアプリケーションでよく、ドメイン５３０はカレンダアプリケーションでよく、ドメイン５４０は、顧客口座アプリケーションでよい。したがって、アクセス機構コンポーネント５２０は、定数（たとえば、ＭｙＦａｍｉｌｙ）の値を決定しようと試みる際、ｅメールアプリケーションにも、局所的なデータレジストリにもアクセスすることができる。コンポーネント５２０は、そのドメインまたは局所的なデータレジストリにおいて値を解決することができない場合、定数値を決定するまで、または使用可能な全ドメインを調べ終わるまで、アクセス可能なそれ以外のドメインを調べ続けることができる。一例では、アクセス機構コンポーネントは、ｅメールアプリケーションにおいて、次のようなデータを見つけることができる。
【００７２】
【表６】
2007509416.tif 000008
【００７３】
定数ＭｙＦａｍｉｌｙに関連づけられたグループのメンバのＸＭＬ表現は、例示のためにのみ使われることが留意されるべきである。グループの投入は、本発明によって多くの方法で定義され、かつ／または実現され得る。したがって、アクセス機構コンポーネント５２０は、ｅメールアプリケーションから取得されたデータに基づいて、ＭｙＦａｍｉｌｙを、Ｂｏｂ  Ｊｏｎｅｓ、Ｂａｒｂ  Ｊｏｎｅｓ、Ｍｉｃｈａｅｌ  Ｊｏｎｅｓ、およびＪａｓｏｎ  Ｊｏｎｅｓに解決することもリンクすることもできる。ただし、アクセス機構コンポーネント５２０は、データの完全性および正確さを確実なものにするために、他のドメインを調べ続けることができる。たとえば、アクセス機構コンポーネントは、カレンダアプリケーションにおいて＜ＭｙＳｉｓｔｅｒ＞Ｊｅｎｎｉｆｅｒ  Ｊｏｎｅｓ＜／ＭｙＳｉｓｔｅｒ＞を見つけ、この値を、定数ＭｙＦａｍｉｌｙに関する値の文字列に追加することができる。
【００７４】
ここまで論じた定数（たとえば、ＭｙＦａｍｉｌｙ、ＭｙＣｏｗｏｒｋｅｒｓ、ＭｙＦｒｉｅｎｄｓ、ＭｙＦａｖｏｒｉｔｅ  Ｍｕｓｉｃｉａｎｓ）は、所与のユーザに関して定義されるので、一次定数として知られる。アクセス機構コンポーネント５１０またはアクセス機構は次いで、ユーザの識別または他の開始点から入力データを受け取ることができる。予め定義された（たとえば、定数によって命名された）グループを複合するのにプレファレンスを使うことによって、Ｎ次定数も、ユーザによって構成され保存され得ることも留意されるべきである。例として、前置詞句のセマンティクスと同様の機能を提供する、定数によって命名されたグループの複合を考えてみる。たとえば、ユーザは、ＦｒｉｅｎｄｓＯｆＭｙＦａｍｉｌｙやＥｍａｉｌｓＦｒｏｍＰｒｅｆｅｒｒｅｄＣｕｓｔｏｍｅｒｓＩｎＡｐｐｏｉｎｔｍｅｎｔｓＴｏｄａｙのようなグループを表す定数を構成し保存することができる。別の観点から見ると、定数の拡張は、定数アクセス機構として表され、他の定数と複合される項目フィールドに対する条件と同様である。
【００７５】
したがって、定数アクセス機構は、異なるドメインに及ぶデータのナビゲーションを提供する。ナビゲーションアクセス機構と体系化された論理の複合は、プログラマ以外の人が、ドメイン間プレファレンスを書くことを可能にする。さらに、比較的少数のアクセス機構制約と複合された比較的少数の条件クラスは、それ以外の場合にはアプリケーション開発者によって期待されなければならない、興味を惹く複数の強力な条件の指示を容易にする。
【００７６】
さらに、プレファレンスグループも指定され得ることが留意されるべきである。エンドユーザによって定義される決定論理は、１組または複数の組のプレファレンスによって表される。したがって、プレファレンスグループは、関連づけられたプレファレンスのグループ用のコンテナとして定義され得る。プレファレンスグループ中のプレファレンスは次いで、（１）同じプレファレンスクラスに属し、（２）併せて評価されることができ、その結果は、競合解決の対象となる。さらに、プレファレンスグループ中のプレファレンスは、まとめて使用可能にされ使用不能にされ得る。プレファレンスをまとめて使用可能にし、使用不能にすることは、無数のシナリオにおいて有用であり得る。たとえば、エンドユーザは、職場で１組のプレファレンスを有し、自宅では別の１組のプレファレンスを有し得る。したがって、プレファレンスグループは、ユーザコンテキストに基づいて、可能にされることも、使用不能にされることもできる。
【００７７】
論理スキーマ４００は、クロニクル４３５も含み得る。多くの情報エージェントアプリケーションは、妥当な決定を行うために、状態を維持する必要がある。簡単な例として、ニュースを公開する情報エージェントアプリケーションを考える。エンドユーザは、興味があるニュース記事に登録する。イベント供給は、絶え間なくニュース記事のストリームを搬送する。１つの問題は、内容がわずかに修正されているが、同じタイトルをもつ同じ記事が何度も届き得ることである。このコンテキストにおいて、妥当な条件とは、ＩｓＮｅｗＡｒｔｉｃｌｅ（）であろう。この条件は、同じタイトルがこれまでに見られていなかったことを調べることができる。別の例は、絶え間なく流れてくるアップデートが、記事を速報とするかどうかを調べることである。このタイプの機能を可能にするために、イベントが処理されるときに状態が維持される必要がある。この状態は、アプリケーション履歴の表現なので、本明細書においてクロニクルと呼ばれる。
【００７８】
情報エージェントのスキーマ開発者は、（たとえば、リレーショナルデータベース中、またはオペレーティングシステムによって管理されるフォルダ中のテーブルとして）クロニクルを定義することができる。より重要なことは、スキーマ開発者は、アプリケーションの状態をアップデートするために、イベント処理の限界状態で実行することができる論理を定義することができる。たとえば、イベントが、速報に対応するかどうかの計算に適切な時は、イベントが処理される前であろう。さらに、同じタイトルをもつ、それ以降のイベントが重複として現れるようにニュース記事が処理されたことを記録するのに適切な時は、イベントが処理された後であろう。さらに、クロニクルは、アクション履歴ならびにイベント履歴を記録するのにも利用され得ることが留意されるべきである。
【００７９】
開発者は、競合解決コンポーネント４４５において、競合解決プロシージャまたは論理を、論理スキーマ４００中のプレファレンスクラス４２５の一部として指定することができる。イベントが起きたとき、複数のプレファレンスがそのイベントに合致する場合、複数のアクションが発生し得る。したがって、実行および／または最終的なアクションがとられる順序を決定するシステムおよび方法が望まれる。複数のアクションのトリガを扱う、少なくとも３つの方法がある。第一に、スキーマ４００は、エンドユーザがアクションまたはプレファレンスの優先順位を定義することを可能にすることができる。たとえば、エンドユーザは、すべてのプレファレンスに優先順位を割り当てることができる。さらに、エンドユーザは、特定のプレファレンスに、処理停止インジケータ（たとえば、フラグ）を割り当てることができる。したがって、イベントが、複数のアクションをトリガすると、アクションは、優先順序通りに実行され得る。さらに／あるいは、複数のプレファレンスが、プレファレンスグループ中で一致する場合、最も優先順位の高いプレファレンスが実行されることができ、それ以外のプレファレンスは破棄される。さらに、スキーマ４００は、エンドユーザが、状況を扱うために、特定のプレファレンスに処理停止インジケータを付加するなど、競合解決プロシージャを指定することを可能にし得る。この場合、インジケータを含むプレファレンスは、他のプレファレンスと同時にトリガされる。競合が解決され得る別の方法は、スキーマ４００中でアクションクラスの優先順位を定義することによるものである。したがって、スキーマ開発者は、アクションクラスの優先順位を指定することができる。たとえば、ＭｏｖｅＴｏＦｏｌｄｅｒアクションクラスは、Ｄｅｌｅｔｅアクションクラスより高い優先順位を指定され得る。同じアクションクラスの複数のアクションが同時にトリガされると、他の競合シナリオも発生し得る。スキーマ開発者は、このタイプの状況を扱うための、複数の競合解決論理を定義することができる。たとえば、所望のポップアップ表示のボリュームを設定するアクションクラス（たとえば、ＳｅｔＶｏｌｕｍｅ（））があると仮定する。さらに、あるイベントが、２つのアクション、ＳｅｔＶｏｌｕｍｅ（５０）およびＳｅｔＶｏｌｕｍｅ（７０）をトリガすると仮定する。この場合、競合解決コンポーネント４４５において定義される競合論理は、とられるアクションが、２つのレベルの最小、最大、または平均に対応するように定義され得る。
【００８０】
プレファレンス実行順序は、明示的実行コンポーネント４５０により、スキーマ４００においても指定され得る。いくつかの状況において、あるプレファレンスのアクションが、別のプレファレンスにおける条件に影響し得るので、プレファレンスの明示的順序づけが必要である。たとえば、ｅメールプレファレンスを用いると、あるプレファレンスは、着信メッセージの優先順位を決定するのに使われることができ、別のプレファレンスは、メッセージの優先順位に反応し、メッセージに対してどのように作用するかを決定するように書かれることができる。エンドユーザのプレファレンスを書く人は通常、経験の浅いプログラマである。本発明の態様によると、エンドユーザは、副次作用、したがって順序づけ要件を有するプレファレンスまたは規則を書くことを要求されない。スキーマ開発者は、順序づけ依存をエンドユーザから隠すことが好ましい。この隠蔽は、プレファレンスクラスの順序づけ、明示的連鎖、およびプレファレンスグループの順序づけを含むが、それに限定されない異なる複数の方法で遂行され得る。プレファレンスグループの順序づけによって、スキーマ開発者は、あるプレファレンスクラスが、別のプレファレンスクラスの前に実行されるように順序づけることができる。上述した例において、メッセージのプロパティ（たとえば、優先順位）を確立するプレファレンスクラスは、メッセージに反応するプレファレンスクラスの前に来るべきである。本発明の態様によると、エンドユーザに提示されるユーザインターフェイスは、各プレファレンスクラスが独自のペインをもつように、ペインに分けられ得る。明示的チェーンに関して、スキーマ開発者は、新着イベントおよびその順序づけを引き起こすアクションを指定することができる。したがって、プレファレンスクラスは、プレファレンスクラスの順序づけではなく、アクションとイベントのチェーンを有して実装され得る。さらに、スキーマ開発者は、プレファレンスグループを用いて、実行順序を指定することができる。プレファレンスグループの順序づけの使用は、プレファレンスクラスの順序づけと同じであるが、より柔軟な形の能力をもたらす。たとえば、すべてのプレファレンスグループは、グループの中にただ１つのプレファレンスをもつことができ、その結果、全体が順序づけられた、プレファレンスからなる連続リストと等価になる。
【００８１】
「必要」条件およびアクションも、スキーマ４００において、必要条件およびアクションコンポーネント４５５を使って、プレファレンスクラス４２５の一部として指定され得る。すべてのプレファレンスクラスは、必要条件およびアクションを含み得る。必要条件およびアクションは、全プレファレンスにおける特定の共通パターンを強化するのに利用され得る。たとえば、サーバ上で適用される、よく知られているｅメール処理の例において、Ｉｎｂｏｘプレファレンスに対する必要条件は、プレファレンスの所有者が、ｅメールの受信者でもあってもよいというものでよい。
【００８２】
テンプレート４６０も、論理スキーマ４００において定義され得る。未経験のエンドユーザが論理を作成するのを容易にするために、開発者またはサードパーティによって、エンドユーザが採用し使用するためのテンプレートが与えられ得る。したがって、エンドユーザに対してテンプレートが利用可能な場合、システム１００は、プレファレンステンプレートの抽象化をサポートするべきである。テンプレートは単に、パラメータの一部が指定されていない、存続型の完全なプレファレンス（条件表現およびアクションが選ばれる）に相当し得る。
【００８３】
スキーマ４００は、スケジュールされた再発プレファレンスコンポーネント４６５により、スケジュールされた再発プレファレンスを扱うようにも定義され得る。多くの情報エージェントアプリケーションが、再発スケジュールにおいて、評価されるプレファレンスの使用を望み得る。数多くある例の１つは、全労働日の午後５時に要約状況を送るプレファレンスを含む。本発明の一態様によると、スケジュールされた再発機能は、２つの抽象化を用いて、スキーマ４００中に実装され得る。第一に、システム定義イベントクラス（たとえば、ＴｉｍｅｒＥｖｅｎｔ）が、スケジュールされた活動用のイベントフックを提供するのに利用され得る。このイベントクラスは、様々な規則的精度で構成され得る。さらに、イベントに関連づけられたデータは、現在の時刻および前回の始動時刻を含み得る。第二に、すべてのスケジュールされたプレファレンスは、次のような条件を含み得る。
ＲｅｃｕｒｒｅｎｃｅＩｎＷｉｎｄｏｗ（ＲｅｃｕｒｒｅｎｃｅＳｃｈｅｄｕｌｅ，ＳｔａｒｔＴｉｍｅ，ＥｎｄＴｉｍｅ）において、
・ＲｅｃｕｒｒｅｎｃｅＳｃｈｅｄｕｌｅは、エンドユーザの指定から捕捉される、所望の再発パターンを表す定数であり、
・ＳｔａｒｔＴｉｍｅは、開発者によって、タイマイベントの前回の時刻にバインドされ、
・ＥｎｄＴｉｍｅは、開発者によって、タイマイベントの現在の始動時刻にバインドされる。
【００８４】
要するに、論理スキーマ４００は、エンドユーザプレファレンス用の論理ビルディングブロックを提供するように、異なるいくつかのコンポーネントまたはセクションを含み得る。スキーマは、たとえばＸＭＬファイルなど、どの形もとり得る。スキーマは、完成されると、データベース表現にコンパイルされ、たとえばデータストア１５０（図１）に格納され得る。スキーマファイルは、直接オーサリングされることも、Ｖｉｓｕａｌ  Ｓｔｕｄｉｏなどのアプリケーションを使って構築されることもできることが理解されるべきである。したがって、システムコンパイラは、複数のスキーマエディタアプリケーションを使って作成されたスキーマファイルをサポートすることができるべきである。
【００８５】
（アプリケーションの実行）
情報エージェントアプリケーションの実行は、３つの異なるカテゴリ、すなわちイベント処理、プレファレンス処理、およびアクション処理に下位分割され得る。イベント処理は、イベントがどのようにして捕捉され、プレファレンス論理を活動化するかを扱う。プレファレンス処理は、異なるプレファレンス処理モードに部分的に応じて、異なる複数の方法で遂行され得る。最後に、アプリケーションの実行は、どのようにしてアクションを処理するかという決定を伴う。
【００８６】
イベントは、システムＡＰＩ１１０（図１）を用いてイベントを明示的に提出する何らかのアプリケーションによって捕捉され得る。イベントは、個別に、またはバッチとしてまとめて提出され得る。イベントの捕捉には、次のものを含むが、それに限定されない、無数のシナリオがある。
・正規の適用論理の一部として、たとえば、Ｅｘｃｈａｎｇｅ  ＳＭＴＰプロバイダが、新しいＳＭＴＰメッセージを受け取り、情報エージェントイベントを明示的に起こし得る。
・データがデータストア１５０中で変更されると、データ変更から、たとえば、ＩＡ論理に対してイベントがトリガされる。
・オペレーティングシステムから、たとえば、アプリケーションが、オペレーティングシステムおよび／またはそれに関連づけられたランタイムをリッスンし、特定のアクションを検出するとイベントを起こし得る。
・情報エージェントプレファレンスから、あるプレファレンスのアクションが、プレファレンス評価に及ぶチェーンにつながる別のイベントを起こし得る。
・ユーザが、イベントが生成されることを明示的に指定し得る。たとえば、ユーザは、フォルダ中の各ファイルに対応するイベントが生成されることを指定し得る。
さらに、システム１００は、比較的大きいアプリケーションがアクティブに実行中であることを要求しないイベント捕捉論理用に、ホスティングサービスを提供し得ることが留意されるべきである。たとえば、情報エージェントアプリケーションは、特定のオペレーティングシステムイベントがアプリケーション活動をトリガすることを望み得る。したがって、別個のアプリケーションが単にこの機能のために実行されることを要求するのではなく、このイベントプロバイダをサービスにおいてホストすることが可能である。
【００８７】
プレファレンスは、イベントの出現によって活動化される。プレファレンスの処理は、同期、非同期、またはこの２つの組合せのいずれかでよい。同期処理を用いると、イベント提出とプレファレンス評価の間に些細な遅れを伴う。一方、非同期処理は、イベント提出とイベント処理の間に大幅な遅れを伴う。本発明のシステムは、両方の処理モデルをサポートし、イベントバッチ提出に基づいて、どちらかのモデルをリアルタイムに選ぶことができる。
【００８８】
さらに、本発明の一態様によると、プレファレンス処理は、プレファレンスを効率的に評価するのに、データベースクエリの力を利用する。開発者、および最終的にはエンドユーザに公開されるのは、宣言型プログラミングモデルであり、逐次モデルに従って条件関数が指定されることを可能にする。逐次プログラミングモデルとは、最も使いやすく、開発者およびユーザが１つのプレファレンスに対して１つのイベントを指定することを可能にするモデルである。しかし、本発明の態様によると、システム１００は、索引づけおよび重複除去のような技術を利用して、集合指向式で実行される条件つきクラスクエリを作る。このようなクエリの作成は、プレファレンスが効率的に評価され、開発者およびエンドユーザは、理解し書くのは容易であるが、複数のプレファレンスを実行するには非効率な方法である逐次方式で、プログラムを概念化し書くことに専念できる点で有益である。さらに、複数のプレファレンスがバッチで処理され得るが、プレファレンスは、イベントが起こると個別に評価され得ることが留意されるべきである。
【００８９】
図６に移ると、本発明の態様によるプレファレンス評価用システム６００が示されている。システム６００は、データストア１５０、複数のテーブル６１０、プレファレンス実行エンジン１６０、および結果テーブル６３０を備える。データストア１５０は、システム１００によって開発者スキーマならびにエンドユーザプレファレンスから作成される複数のテーブル６１０を収容する。イベント出現の結果として、プレファレンス実行エンジンは、プレファレンスを、たとえばデータストア１５０に格納されているテーブルから受け取り、または取得する。実行エンジン１６０は次いで、プレファレンスならびにいくつかのストアドプロシージャ（やはりデータとして格納され得る）を使用して、テーブル６１０を照会し、結果テーブル６３０を生じる。結果テーブル６３０は、指定されたアクションがそれに対して開始され得るように条件が満たされているプレファレンスを格納することができる。
【００９０】
テーブル６１０の数および複雑さは、エンドユーザプレファレンスをサポートするための、開発者によって書かれたスキーマの複雑さに応じて変わり得る。システム６００が、プレファレンスを処理するのにどのようにしてデータベーステーブルおよびクエリを使用するかを明確にするために、これ以降一例が提示される。この例において、いくつかのプレファレンスグループを使おうとする２人の個人、ＪａｃｋおよびＪｉｌｌがいる。論じてきたように、ＪａｃｋおよびＪｉｌｌがエンドユーザプレファレンスを指定し得る前に、スキーマが作成されていなければならない。スキーマは、上述したようにいくつかの部分を有するが、理解しやすくするために、非常に単純なスキーマが、本明細書において説明される。スキーマの本質的な部分の１つは、イベントクラスの定義である。この例において、２つのイベントクラス、ＥｍａｉｌＥｖｅｎｔｓおよびＳｔｏｃｋｅｖｅｎｔｓが検討される。本明細書に添付されたＡｐｐｅｎｄｉｘに移ると、２つのイベントクラスならびに３つのプレファレンスクラスのスキーマ定義を示す擬似コードが示されている。２つのプレファレンスクラスは、ＥｍａｉｌＥｖｅｎｔｓに基づき、第３のクラスは、ＳｔｏｃｋＥｖｅｎｔｓに基づく。情報システム１００は次いで、このスキーマを使用して、プレファレンスクラステーブルおよび条件クラスを作成することができ、この２つは、データストア１５０に格納され得る。たとえば、次のようになる。
【００９１】
【表７】
2007509416.tif 000009
【００９２】
ＪａｃｋおよびＪｉｌｌは次いで、自身のプレファレンスを定義することができる。この例示のために、Ｊａｃｋが、３つのプレファレンスグループＰＧ（Ｊａｃｋ，１）、ＰＧ（Ｊａｃｋ，２）、およびＰＧ（Ｊａｃｋ，３）を定義すると仮定する。さらにＪａｃｋは、次のような、グループの間で引き渡される５つのプレファレンスを定義する。
【００９３】
【表８】
2007509416.tif 000010
【００９４】
この例示のために、Ｊｉｌｌは、２つのプレファレンスグループ（Ｊｉｌｌ，１）および（Ｊｉｌｌ，２）を定義すると仮定する。さらに、Ｊｉｌｌは、次のような、グループの間で引き渡される５つのプレファレンスを指定すると仮定する。
【００９５】
【表９】
2007509416.tif 000011
【００９６】
情報エージェントシステム１００は次いで、こうしたプレファレンスを使用して、プレファレンスおよびそれに関連づけられた条件を記述する追加リレーショナルデータベーステーブルを作成することができる。以下の例示的なテーブルを１つずつ検討し、こうしたテーブルが、プレファレンスを評価するのにどのようにして利用されるかを検討する。
【００９７】
以下に示されるプレファレンスグループのテーブルは、５つの行を含み、各行は、ＪａｃｋおよびＪｉｌｌが定義したプレファレンスグループそれぞれに対応する。さらに、プレファレンスグループが使用可能になっているかどうかを示すための列が指定されることに留意されたい。上述したように、この列は、たとえば、ユーザが、自宅にいるとき、使用可能になっている１つのプレファレンスグループを指定し、仕事中のときは、使用可能になっている別のプレファレンスグループを指定したい場合に有用である。ここでは、全プレファレンスグループが、使用可能になって示されている。
【００９８】
【表１０】
2007509416.tif 000012
【００９９】
どのプレファレンスがどのプレファレンスグループのメンバであるかを要約するために、ＰｒｅｆｅｒｅｎｃｅＧｒｏｕｐＭｅｍｂｅｒＳｈｉｐテーブルも定義され得る。次に示されるテーブルは、１１行を含み、各行は各プレファレンスに対応する。
【０１００】
【表１１】
2007509416.tif 000013
【０１０１】
ユーザによって定義されるプレファレンスに関するデータを要約するための次のプレファレンステーブルは、データストア１５０に格納され得る。このテーブルは、１０個のプレファレンスそれぞれに対応する１０行を含む。このテーブルは、重要な列および名前のみを示すように連結されていることに留意されたい。
【０１０２】
【表１２】
2007509416.tif 000014
【０１０３】
上記のプレファレンステーブルには、合計１４個のＡＮＤグループがあることにも留意すべきである。
【０１０４】
さらに、上記のテーブルには、合計１９個の条件がある。こうしたＡＮＤグループおよび条件についての情報は、次のように付加テーブルに取り込まれ得る。
【０１０５】
【表１３】
2007509416.tif 000015
【０１０６】
ＡＮＤグループｉｄは、その前のテーブルから順に番号をつけられる。ＣｏｎｄｉｔｉｏｎＣｏｕｎｔは、ＡＮＤでつながる条件の数を記録する。上記のテーブルにおいて予想に反する行エントリは、以下に示される行のみである。
７  １１  １  −−Ｆｒｏｍ（Ｂｏｂ）ＡＮＤ！Ｃｏｎｔａｉｎｓ
【０１０７】
（Ｗｏｒｋ）
ＣｏｎｄｉｔｉｏｎＣｏｕｎｔは、期待されるであろう２ではなく、１であることに留意されたい。クエリ評価においてＮＯＴの存在を考慮するために、条件カウントは、ＡＮＤ  Ｇｒｏｕｐ中の、Ｎｏｔ（！）が前にない条件のみの和となるように定義される。条件の前にＮＯＴがあるものは、以前示したように別個のテーブルに要約され得る。
【０１０８】
ＡＮＤＧｒｏｕｐｓはさらに、次の連結テーブルが示すように、ＡＮＤＧｒｏｕｐＭｅｍｂｅｒｓｈｉｐというテーブル中で定義され得る。
【０１０９】
【表１４】
2007509416.tif 000016
【０１１０】
上述したように、ＮＯＴつきの条件は、特殊な場合と見なされ、次のようにそれ自体のテーブルにおいて要約されることができる。
【０１１１】
【表１５】
2007509416.tif 000017
【０１１２】
指定された条件の値をプレファレンスに格納するために、条件値テーブルも作成され得る。このテーブルは、各条件に関連づけられた２つのパラメータ値のみを認めることが留意されるべきである。少なくとも、条件はすべて１つのパラメータ値のみをもつのでこの例示には十分であるが、条件が２つより多い関連づけられた値を含むことを許容される場合、特別な条件値を示すために、テーブルが拡張されることもでき、別のテーブルが、インスタンス化されることもできる。
【０１１３】
【表１６】
2007509416.tif 000018
【０１１４】
ＣｏｎｄｉｔｉｏｎｓＲｅｓｕｌｔｓテーブルも提供され得る。ＣｏｎｄｉｔｉｏｎｓＲｅｓｕｌｔｓテーブルは、最終結果テーブル６３０の先行として使用され得る。条件クエリが実行されると、ＣｏｎｄｉｔｉｏｎｓＲｅｓｕｌｔｓテーブルに投入が行われる。条件クエリが実行されていないときは、テーブルの中に行はない。条件を評価しテーブルに投入を行う例示的なプロシージャが、後で開示される。
【０１１５】
【表１７】
2007509416.tif 000019
【０１１６】
前述したように、本発明の態様の１つは、条件関数の開発者への逐次モデルの公開を可能にするが、最終的には、データベースクエリ効率を利用するために、集合指向式に実行される条件つきクラスクエリを作る宣言型プログラミングシステムを提示するためのものである。したがって、１対１の条件クラス宣言が、クエリに変換され得る。たとえば、ＥｍａｉｌＥｖｅｎｔｓにおいて、エンドユーザプレファレンスは、ｅメールの送信者に応じたアクション（たとえば、ＪａｃｋのＰ１）を行うことができる。したがって、ユーザインターフェイスを介しているエンドユーザは、ＭａｉｌＩｓＦｒｏｍ（Ｍａｒｙ）を書くことができる。ただし、プレファレンスを実行するとき、システム６００は、ユーザの条件ステートメントを表すデータベースクエリを実行することになる。たとえば、システムは、ＣＶ．ＰａｒａｍＶａｌｕｅ１＝「Ｍａｒｙ」であるユーザ宣言の代わりに、次のＳＱＬクエリステートメントを実行することができる。
【０１１７】
【表１８】
2007509416.tif 000020
【０１１８】
したがって、開発者は、各条件に対してクエリコードを定義し、このコードをテーブルに格納するべきである。可能ではあるが、新しいテーブルは、これを表すために作成される必要はない。予め定義されたＣｏｎｄｉｔｉｏｎＣｌａｓｓｅｓテーブルは、単に、次の擬似コードに示されるように、クエリテキストを含むように修正され得る。
【０１１９】
【表１９】
2007509416.tif 000021
【０１２０】
テーブル６１０がすべて定義されると、プレファレンスは、結果テーブル６３０に投入を行い、その後、データに関連づけられたアクションを実行するように、このようなデータに突き合わされて評価され得る。プレファレンスは、クエリを評価することによって実行され得る。クエリは、１つまたは複数のプロシージャを利用することによって評価され処理されることができ、こうしたプロシージャは、データとしてデータストア１５０に格納され、本発明の態様による要望があると、構築されることができる。いくつかのプロシージャは、条件およびプレファレンスを評価し、次いで、たとえばプレファレンスと関連づけられたアクションの実行が開始され得るように、プレファレンスが真と評価されるかどうかを示す印とを結果テーブルに投入するのに専用でよい。たとえば、条件を評価しまたは照会し、ＣｏｎｄｉｔｉｏｎＲｅｓｕｌｔｓテーブルに結果を格納するのに、次のプロシージャが利用されることができ、テーブルは続いて、結果テーブル６３０に投入を行うために評価され得る。
【０１２１】
【表２０】
2007509416.tif 000022
【０１２２】
さらに、上記のプロシージャは、全条件クエリが実行されるように、ループとともに利用され得ることが理解されるべきである。ただし、増分条件評価を可能にするように、各条件に対して上記のプロシージャを一度呼び出すことが好ましい場合がある。条件がすべて評価されると、プレファレンスを評価するのに別のプロシージャが使用されることができ、こうしたプレファレンスはしばしば、ブール演算子でつながれた条件である。
【０１２３】
本明細書に記載されるプロシージャすべてと同様に、なかでも、プログラマのスタイル、効率、および構築されるテーブルの性質に応じてプロシージャが書かれ得る、異なる複数の方法がある。プロシージャの理解のために、本発明の態様に従って、プレファレンスを評価するのに使用され得るクエリの例として、次のものが挙げられる。プレファレンスの、異なるＡＮＤＧｒｏｕｐｓを一度の実行においてではなく増分的に評価する、より効率的なクエリプロシージャが用いられ得ることが留意されるべきである。
【０１２４】
【表２１】
2007509416.tif 000023
【０１２５】
上記のプロシージャが、どのようにして最終結果テーブル６３０用の行を作成するように作用するかを明確にするために、いくつかの例が次に挙げられる。
【０１２６】
（例１：）
ＣｏｎｄｉｔｉｏｎＲｅｓｕｌｔｓテーブルは、次の２行を有すると仮定する。
【０１２７】
【表２２】
2007509416.tif 000024
【０１２８】
プレファレンス１において、こうした２つの条件の間にはＡＮＤがある。したがって、このプレファレンスは、上記の条件が両方とも真である場合のみ、真であると評価される。こうした条件は両方とも、条件カウントが２である第１のＡＮＤＧｒｏｕｐに属す。したがって、上記のテーブルが、ＡｎｄＧｒｏｕｐＭｅｍｂｅｒｓｈｉｐテーブルと結合されると、次のテーブルが生じる。
【０１２９】
【表２３】
2007509416.tif 000025
【０１３０】
ｇｒｏｕｐｂｙが実施された後、次の行を得る。
【０１３１】
【表２４】
2007509416.tif 000026
【０１３２】
ここで、（Ｐｒｅｆ．Ｉｄ，ＡＮＤＧｒｏｕｐＩｄ）は、ＡＮＤＧｒｏｕｐｓテーブル用の鍵となる。テーブルのルックアップは、ｓｕｍ（Ｂｏｏｌ）に等しい２という条件カウントをもたらす。したがって、プレファレンスは真であり、結果テーブル７３０に追加され得る。
【０１３３】
（例２：）
ＣｏｎｄｉｔｉｏｎＲｅｓｕｌｔｓテーブルは、次の２行を有すると仮定する。
【０１３４】
【表２５】
2007509416.tif 000027
【０１３５】
プレファレンス２において、こうした２つの条件の間にはＯＲがある。したがって、このプレファレンスは、２つの条件のどちらかが真である場合のみ、真であると評価される。こうした条件は、それぞれ、条件カウントが両方とも１である第２および第３のＡＮＤＧｒｏｕｐに属す。したがって、上記のテーブルが、ＡｎｄＧｒｏｕｐＭｅｍｂｅｒｓｈｉｐテーブルと結合されると、次のテーブルが生じる。
【０１３６】
【表２６】
2007509416.tif 000028
【０１３７】
上記のテーブルがグループ化された後、次のものを得る。
【０１３８】
【表２７】
2007509416.tif 000029
【０１３９】
上記の行は両方とも、節をもつことを満たし、したがって、違いが適用された後、プレファレンス（Ｐｒｅｆ．Ｉｄ＝２，ＥｖｅｎｔＩｄ＝１０１）が、結果テーブル７０３にコピーされることがわかる。
【０１４０】
（例３：）
この最後の例に対して、ＣｏｎｄｉｔｉｏｎＲｅｓｕｌｔｓテーブルは、次の２行を有すると仮定する。
【０１４１】
【表２８】
2007509416.tif 000030
【０１４２】
プレファレンス７に対する条件は実際には、
Ｆｒｏｍ（Ｂｏｂ）ａｎｄ！Ｃｏｎｔａｉｎｓ（Ｗｏｒｋ）
であったことを思い起こされたい。ＮＯＴがあるので、上の２行目にある１は、本発明の態様に従って−１に変更される。以下は、このような機能を提供する例示的なクエリである。
【０１４３】
【表２９】
2007509416.tif 000031
【０１４４】
さらに、スマートクエリオプティマイザが利用され、ＮＯＴテーブルが空であることを通知する場合、クエリは、すぐに戻るべきであることが留意されるべきである。したがって、上記のテーブルは、
【０１４５】
【表３０】
2007509416.tif 000032
【０１４６】
となる。こうした条件は両方とも、１１番目のＡＮＤＧｒｏｕｐに属す。ＡＮＤＧｒｏｕｐテーブルから、このプレファレンス（ｐｒｅｆｅｒｅｎｃｅ，ＡＮＤＧｒｏｕｐ）の条件カウントは１であると判定され得る。０≠１なので、プレファレンス評価クエリから行が生じない。ただし、ｃｏｎｄｉｔｉｏｎＲｅｓｕｌｔｓテーブルに第２行がなかった場合、１（＝１）の和を得ることになり、プレファレンス７は、真と評価されることに留意されたい。
【０１４７】
結果テーブル７３０に投入が行われた後、プレファレンスアクションが実行され得る。アクションは、システム１００からプレファレンス結果を取得するとともに結果に対して作用することによって、情報エージェントシステム１００によっても、情報エージェントアプリケーション（群）によっても実行され得る。アクションが、情報エージェントシステム１００ではなくアプリケーションによって実行される場合、アクションは、システム１００から取得され得る。システム１００に関して、ホスティングサービスは、システム１００によって、アクションを取得し実行することができるアプリケーションアクションハンドラ用に提供され得る。
【０１４８】
（優先順位アクションおよびコンテキスト分析）
以下の説明は、たとえば通知やメッセージなど、生成されたアクションに関連づけられた複数の情報が、ユーザまたはシステムへの伝送のために、優先順位システムによって自動的に優先順位をつけられることを可能にするためのシステムおよび方法に関する。さらに、この考察は、説明を簡単にするために、通知およびコンテキスト分析の優先順位に焦点を当てるが、どのアクション（群）も、優先順位およびコンテキスト分析を同様に使用し得ることが理解されるべきである。優先順位システムは、学習された、ユーザにとっての重要度に従って、１つまたは複数の受け取られたメッセージに優先順位をつけるように、明示的に、かつ／または暗黙的にトレーニングされ得る分類器を使用することができる。一例として、通知は、同様の重要度を有する通知の例またはタイプからなるトレーニングセットを介して、高、中、低、または他の重要度として分類され得る。メッセージの重要度に関するユーザ個人の決定に従って分類器をさらに洗練しまたは調整するように、メッセージ処理に関するユーザの活動を監視するためのバックグラウンドモニタが提供され得る。他の優先順位分類は、メッセージの吟味または処理の遅れに対する、時間関連損失に関する判定を伴い得る。
【０１４９】
メッセージまたは他の通知が自動的に優先順位をつけられた後、ユーザは、より重要でない、かつ／または無関係の複数のメッセージをソートする必要なく、より重要なメッセージを吟味することができる。メッセージはさらに、重要度によって１つまたは複数のフォルダに収集されることができ、ユーザは、同様のカテゴリ別の重要度のメッセージを所望のときに吟味することができる。情報エージェントシステム１００など、他のシステムは（たとえば、通知コンポーネント１８０を介して）、決定された優先順位に基づいて、１つまたは複数の通知シンク（たとえば、携帯電話、ハンドヘルドコンピュータ）にメッセージを向けることができる。たとえば、ｅメールメッセージが、重要度が高いと判定された場合、情報エージェントシステム１００は、ユーザが現在、自分の席にいてメッセージを受け取るかどうか、判定することができる。席にいない場合、通知プラットフォームは、セル電話や自宅のラップトップコンピュータなど、現在ユーザが使っている可能性が最も高い通信デバイスにメッセージを転送することができ、ユーザは、重要なまたは緊急のメッセージを通知され得る。
【０１５０】
図７を参照すると、システム７００は、本発明の態様による優先順位システム７１２および通知アクションアーキテクチャを示す。優先順位システム７１２は、１つまたは複数のメッセージまたは通知７１４を受け取り、関連するメッセージに対する優先順位または重要度（たとえば、メッセージの重要度が高いまたは低い確率を示す値）を生成し、関連づけられた優先順位の値を有する１つまたは複数のメッセージを出力７１６で提供する。後でより詳しく説明されるように、メッセージ７１４に優先順位を自動的に割り当てるように、分類器が構築されトレーニングされることができる。たとえば、メッセージが高い、中位、低いカテゴリ、または他の重要度のカテゴリに属す確率をメッセージが割り当てられるように、出力７１６がフォーマットされ得る。メッセージは、たとえば、決定された重要度カテゴリによって、ｅメールプログラムのインボックス（図示せず）に自動的にソートされ得る。ソートは、確定した重要度ラベルをもつシステムフォルダにファイルを向けることも含み得る。ソートは、フォルダを、低、中、および高などの重要度でラベルづけさせることも含むことができ、具体的な重要度が決定されたメッセージが、関連づけられたフォルダに格納される。同様に、１つまたは複数のオーディオサウンドまたは視覚表示（たとえば、アイコン、記号）が、所望の優先順位を有するメッセージが受信されたことをユーザに警告するように適合され得る（たとえば、優先順位が高いメッセージには３回のビープ音、中位の場合は２回のビープ音、低い場合は１回のビープ音、優先順位が高い場合は赤または点滅警告記号、優先順位が中位のメッセージが受信されたことを示す緑または点滅しない警告記号）。
【０１５１】
本発明の別の態様によると、情報エージェントシステム７１７（図１の１００）は、ユーザにとってアクセス可能な１つまたは複数の通知シンクに優先順位つきメッセージを向けるように、優先順位システム７１２とともに利用され得る。後でより詳しく説明されるように、ＩＡシステム７１７は、優先順位つきメッセージ７１６を受け取るとともに、たとえばいつ、どこで、どのようにしてユーザに通知するかに関して決定を行うように適合され得る。一例として、ＩＡシステム７１７は、通信様式（たとえば、セル電話や携帯情報端末（ＰＤＡ）など、ユーザの現在の通知シンク７１８）と、ユーザがいる可能性が高い場所および／またはユーザが注目している可能性が高い対象とを決定することができる。たとえば、重要度が高いｅメールが受け取られた場合、ＩＡシステム７１７は、ユーザの居場所／注目対象を判定し、ユーザに関連づけられた通知シンク７１８にメッセージを向け／フォーマットし直すことができる。比較的低い優先順位のメッセージ７１６が受け取られた場合、ＩＡシステム７１７は、たとえば、要望に応じて後で吟味するために、ｅメールをユーザのインボックスに残すように構成され得る。後でより詳しく説明されるように、ユーザおよび／または他のシステムに優先順位つきメッセージ７１６を向けるのに、他の経路指定および／または警告システム７１９が使用され得る。
【０１５２】
本説明の以下のセクションでは、自動分類システムおよびプロセスによる、ｅメールなどのテキストファイル用の優先順位生成が記述される。説明されるテキスト用の優先順位生成は次いで、後でより詳しく説明される通知プラットフォームなど、他のシステムにおいて利用され得る。このセクションにおける説明は、図８および図９とともに行われ、図８は、テキスト分類器の明示的および暗黙的トレーニングを示す図であり、図９は、テキストに対する優先順位が、テキスト分類器への入力によってどのようにして生成されるかを示す図である。本説明はまた、テキストの優先順位がそれに従って分類され得る異なるスキーマの図である図１０および１１とともに、かつ、テキストタイプに応じて適用可能であり得るコスト関数を示すグラフである図８および１１とともに行われる。
【０１５３】
ここで図８を参照すると、テキスト／データ分類器８２０が優先順位によって分類を実施するために、矢印８２２で表されるように明示的に、かつ矢印８２４で表されるように暗黙的にトレーニングされ得る。矢印８２２で表される明示的トレーニングは概して、分類器８２０を構築する初期フェーズで行われ、矢印８２４で表される暗黙的トレーニングは通常、分類器８２０が構築された後に行われて、たとえば、バックグラウンドモニタ８３４を介して分類器８２０を微調整する。具体的な説明が本明細書において、分類トレーニングおよび実装手法を例示するために、ＳＶＭ分類器を参照して行われる。他のテキスト分類手法は、ベイズのネットワーク、決定ツリーを含み、異なる独立パターンを提供する確率的分類モデルが利用され得る。本明細書で使用するテキスト分類は、優先順位モデルを発展させるのに使用される統計的回帰も含む。
【０１５４】
本発明の一態様によると、よく知られているサポートベクトルマシン（ＳＶＭ）が、分類器８２０として利用される。Ｎａｉｖｅ  Ｂａｙｅｓ、Ｂａｙｅｓ  Ｎｅｔ、決定ツリー、および他の学習モデルなど、他の分類器モデルも使用され得ることが理解されるべきである。ＳＶＭは、分類器コンストラクタおよび特徴選択モジュール８２６内部で、学習またはトレーニングフェーズにより構成される。分類器とは、入力属性ベクトル、すなわちｘ＝（ｘ１、ｘ２、ｘ３、ｘ４、ｘｎ）を、入力クラス、つまりｆ（ｘ）＝ｃｏｎｆｉｄｅｎｃｅ（ｃｌａｓｓ）に属す信頼性にマップする関数である。テキスト分類の場合、属性は、単語またはフレーズあるいは単語（たとえば、品詞、キー用語の存在）から派生される他のドメイン固有属性であり、クラスは、興味のあるカテゴリまたは領域（たとえば、優先レベル）である。
【０１５５】
ＳＶＭおよび他の機能的学習手法の一側面は、分類関数を自動的に学習するのに、ラベルつきインスタンスからなるトレーニングセットを利用することである。トレーニングセットは、分類器コンストラクタ８２６に関連づけられたデータストア８３０内部に示されている。図に示すように、トレーニングセットは、特定のカテゴリに関連づけられる、潜在的、および／または実際の要素または要素の組合せ（たとえば、単語またはフレーズ）を示すグループ分けＧ１からＧＮからなるサブセットを含み得る。データストア８３０は、複数のカテゴリ１からＭも含み、グループ分けは、１つまたは複数のカテゴリに関連づけられ得る。学習の間、入力特徴をクラスの信頼性にマップする関数が学習される。したがって、モデルを学習した後、カテゴリは、入力特徴の重み付きベクトルとして表される。
【０１５６】
カテゴリ分類のために、バイナリ特徴値（たとえば、単語がカテゴリ中に出現し、または出現しない）、あるいは実数値特徴（たとえば、単語が、重要度の重みｒをもって出現する）が、しばしば利用される。カテゴリコレクションは、独自の複数の用語を含み得るので、概して、マシン学習技術をカテゴリ化に適用するとき、特徴選択が利用される。特徴の数を削減するために、特徴は、全体の頻度カウントに基づいて削除され、次いで、カテゴリへの適合に基づいて、より少数の特徴に従って選択されることができる。カテゴリへの適合は、共通の情報、情報の取得、カイ２乗および／または実質的に他のどの統計的選択技術を介しても判定され得る。こうした比較的小さい記述は次いで、ＳＶＭへの入力として働く。線形ＳＶＭは、適切な汎化の正確さをもたらし、適度に速い学習をもたらすことが留意されるべきである。他のクラスの非線形ＳＶＭは、多項式分類器および動径基底関数を含み、本発明に従って使用されることもできる。
【０１５７】
分類器コンストラクタ８２６は、データストア８３０中のグループ分けおよび関連づけられたカテゴリを分析して、入力ベクトルをクラスの信頼性にマップする関数を「学習」するのに、学習モデル８３２を利用する。ＳＶＭを含む多くの学習モデルに対して、カテゴリに対するモデルは、重み特徴ｗのベクトルとして表されることができ、学習された、各カテゴリごとに重みベクトルが存在し得る。重みｗが学習されると、ｘおよびｗの内積を計算することによって新しいテキストが分類され、ｗは、学習された重みベクトルであり、ｘは、新しいテキストを表すベクトルである。ＳＶＭの出力を確率Ｐに変換するために、Ｓ字関数も提供され得る。確率は、優先順位がそこから決定され得るカテゴリまたはクラスに渡って、比較可能なスコアをもたらす。
【０１５８】
ＳＶＭは、その機能的形態がトレーニング前に定義される、パラメータ化された関数である。ＳＶＭのトレーニングは概して、ＳＶＭが１組の例からの関数に適合するので、ラベルつきトレーニングセットを必要とする。トレーニングセットは、１組のＮ個の例からなり得る。各例は、入力ベクトルｘｉ、および入力ベクトルがカテゴリ中にあるかどうかを記述するカテゴリラベルｙｊからなる。各カテゴリごとに、Ｎ個の例でトレーニングされたＳＶＭに、Ｎ個の自由パラメータがあり得る。こうしたパラメータを見つけるために、よく理解されている二次計画（ＱＰ）問題が解決される。ＱＰ問題を解決する、公知の複数の技術がある。こうした技術は、逐次最適化（Ｓｅｑｕｅｎｔｉａｌ  Ｍｉｎｉｍａｌ  Ｏｐｔｉｍｉｚａｔｉｏｎ）技術ならびに他の技術を含み得る。図９に示すように、入力ベクトルｘに変換されたテキスト入力９３６が、各カテゴリ用の分類器９２０に与えられる。分類器９２０は、分類器コンストラクタ８２６によって決定された、学習された重みベクトルｗ（たとえば、各カテゴリごとに１つの重みベクトル）を使用し、優先順位出力９３８をもたらすための内積をなし、確率Ｐは、関連づけられた１つまたは複数の優先順位（たとえば、高い、中位、低い）を示す入力テキスト９３６に割り当てられ得る。
【０１５９】
図８に戻ると、矢印８２２で表されるテキスト分類器８２０のトレーニングは、特徴選択の使用を含む、８２６での分類器の構築を含む。明示的トレーニングフェーズにおいて、分類器８２０は、緊急および即時性のないテキスト両方を提示されることができ、そうすることによって、分類器は、たとえばこの２つを判別することができるようになる。このトレーニングセットは、ユーザによって与えられることもでき、標準またはデフォルトのトレーニングセットが使用されることもできる。トレーニングコーパスを与えられると、分類器８２０は最初に、最も弁別的な特徴を見つけようと試みる特徴選択プロシージャを適用する。このプロセスは、相互情報分析を利用する。特徴選択は、自然言語処理でタグをつけられたフレーズおよび品詞など、使用可能にされている１つまたは複数の単語にも、より高度な区別にも作用し得る。つまり、テキスト分類器８２０は、重要とみなされるテキストの特徴を判別するための、特殊なタグつきテキストを最初に埋め込まれ得る。
【０１６０】
テキスト分類のための特徴選択は一般に、単語の検索を実施する。単語への依拠を超えて、ドメイン固有フレーズおよび高度な特徴パターンも使用可能にされる。特殊トークンも、分類を向上させ得る。ｅメールの即時性に関する学習を行った分類器の質は、たとえば、即時性が異なるｅメールを区別するのに有用であると識別される、作成済みの特徴を特徴選択プロシージャに入力することによって向上され得る。したがって、特徴選択の間、即時性レベルが異なるメッセージを見分けるのに有用な、１つまたは複数の単語ならびにフレーズおよび記号が検討される。
【０１６１】
次の例が示すように、メッセージの即時性の識別における値のトークンおよび／またはパターンは、次のような区別を含み、次のようなブール値の組合せを含む。
【０１６２】
（メッセージヘッダ中の情報の例）
たとえば、
ＴＯ：フィールド（受信者情報）
ユーザに対してのみアドレス指定される、
ユーザを含む数人の人々にアドレス指定される、
少人数の人々を有するエイリアスにアドレス指定される、
少人数の人々を有するいくつかのエイリアスにアドレス指定される、
ユーザにＣｃされる、
ユーザにＢｃｃされる。
【０１６３】
ＦＲＯＭ：フィールド（送信者情報）
様々なクラスの個々人に分割されている可能性が高い、所定の重要人物リストに対する名称（たとえば、家族、友人）、
ユーザの会社／組織にとって内部であると識別された送信者、
オンライン組織図から引き出された、ユーザに対する組織関係の構造についての情報。たとえば、
ユーザが報告を行うマネージャ、
ユーザのマネージャのマネージャ、
ユーザに報告を行う人々、
外部の取引先。
【０１６４】
（過去時制情報）
この情報は、次のような、既に起こったイベントについての記述を含む。
Ｗｅ  ｍｅｔ、
ｍｅｅｔｉｎｇ  ｗｅｎｔ、
ｈａｐｐｅｎｅｄ、
ｇｏｔ  ｔｏｇｅｔｈｅｒ、
ｔｏｏｋ  ｃａｒｅ  ｏｆ、
ｍｅｅｔｉｎｇ  ｙｅｓｔｅｒｄａｙ。
【０１６５】
（未来時制情報）
Ｔｏｍｏｒｒｏｗ、
Ｔｈｉｓ  ｗｅｅｋ、
Ａｒｅ  ｙｏｕ  ｇｏｉｎｇ  ｔｏ、
Ｗｈｅｎ  ｃａｎ  ｗｅ、
Ｌｏｏｋｉｎｇ  ｆｏｒｗａｒｄ  ｔｏ、
Ｗｉｌｌ  ｔｈｉｓ、
Ｗｉｌｌ  ｂｅ。
【０１６６】
（ミーティングおよび調整情報）
Ｇｅｔ  ｔｏｇｅｔｈｅｒ、
Ｃａｎ  ｙｏｕ  ｍｅｅｔ、
Ｗｉｌｌ  ｇｅｔ  ｔｏｇｅｔｈｅｒ、
Ｃｏｏｒｄｉｎａｔｅ  ｗｉｔｈ、
Ｎｅｅｄ  ｔｏ  ｇｅｔ  ｔｏｇｅｔｈｅｒ、
Ｓｅｅ  ｙｏｕ、
Ａｒｒａｎｇｅ  ａ  ｍｅｅｔｉｎｇ、
Ｌｉｋｅ  ｔｏ  ｉｎｖｉｔｅ、
Ｂｅ  ａｒｏｕｎｄ。
【０１６７】
（確定日付）
テキストパターンから示される、明示的に日時を述べるための未来対過去の日時、または次のような一般的な短縮形。
Ｏｎ  ５／２、
Ａｔ  １２：００。
【０１６８】
（疑問）
疑問符（？）が隣にある単語、フレーズ
（個人的な要求の指示：）
Ｃａｎ  ｙｏｕ、
Ａｒｅ  ｙｏｕ、
Ｗｉｌｌ  ｙｏｕ、
ｙｏｕ  ｐｌｅａｓｅ、
Ｃａｎ  ｙｏｕ  ｄｏ、
Ｆａｖｏｒ  ｔｏ  ａｓｋ、
Ｆｒｏｍ  ｙｏｕ。
（必要を示す：）
Ｉ  ｎｅｅｄ、
Ｈｅ  ｎｅｅｄｓ、
Ｓｈｅ  ｎｅｅｄｓ、
Ｉ’ｄ  ｌｉｋｅ、
Ｉｔ  ｗｏｕｌｄ  ｂｅ  ｇｒｅａｔ、
Ｉ  ｗａｎｔ、
Ｈｅ  ｗａｎｔｓ、
Ｓｈｅ  ｗａｎｔｓ、
Ｔａｋｅ  ｃａｒｅ  ｏｆ。
【０１６９】
（即時性）
ｈａｐｐｅｎｉｎｇ  ｓｏｏｎ、
ｒｉｇｈｔ  ａｗａｙ、
ｄｅａｄｌｉｎｅ  ｗｉｌｌ  ｂｅ、
ｄｅａｄｌｉｎｅ  ｉｓ、
ａｓ  ｓｏｏｎ  ａｓ  ｐｏｓｓｉｂｌｅ、
ｎｅｅｄｓ  ｔｈｉｓ  ｓｏｏｎ、
ｔｏ  ｂｅ  ｄｏｎｅ  ｓｏｏｎ、
ｄｏｎｅ  ｒｉｇｈｔ  ａｗａｙ、
ｔｈｉｓ  ｓｏｏｎ、
ｂｙ  ［ｄａｔｅ］、
ｂｙ  ［ｔｉｍｅ］。
【０１７０】
（重要度）
ｉｓ  ｉｍｐｏｒｔａｎｔ、
ｉｓ  ｃｒｉｔｉｃａｌ、
Ｗｏｒｄ、ｐｈｒａｓｅ＋！、
明示的優先順位フラグ状況（低、なし、高）。
【０１７１】
（メッセージの長さ）
新しいメッセージコンポーネントのバイト数。
【０１７２】
（商用およびアダルト向け内容のジャンクＥメールの印）
Ｆｒｅｅ！！、
Ｗｏｒｄ＋！！！、
Ｕｎｄｅｒ  １８、
Ａｄｕｌｔ’ｓ  ｏｎｌｙ、
大文字で書かれている単語の割合、
英数字以外の文字の割合。
【０１７３】
上に示される単語またはフレーズのグループ分けは、分類器がトレーニングをそこから行うのに使用され得る例示的な単語、グループ分け、またはフレーズを示すことが留意されるべきである。他の同様の単語、グループ、またはフレーズも同様に利用されることができ、したがって本発明は上に挙げた例に限定されないことが理解されるべきである。
【０１７４】
さらに、引き続き図８を参照すると、矢印８２４で表される分類器８２０の暗黙的トレーニングは、たとえばユーザのデスクトップまたはモバイルコンピュータに常駐し得るバックグラウンドモニタ８３４を介してユーザの作業または使用パターンを監視することによって行われ得る。たとえば、ユーザが作業を行い、メールのリストが吟味されるとき、緊急のメッセージが最初に読まれ、より優先順位が低いメッセージは後で吟味され、かつ／または消去されると仮定され得る。つまり、新しいｅメールを提示されると、ユーザがｅメールをすぐに開くかどうか、どのような順序で、ｅメールを開かずに消去し、かつ／または比較的短時間でｅメールに返信するかを判定するために、ユーザが監視される。したがって、分類器８２０は、システムを動作させ、または操作する間にユーザが監視されるように適合され、リアルタイムの意思決定を向上するために、分類器は周期的に、バックグラウンドでトレーニングすることによって洗練されアップデートされる。分類器を構築するバックグラウンド技術は、分類器８２０を新しいトレーニングメッセージでアップデートする技術から拡張し得る。
【０１７５】
あるいは、比較的大量のメッセージが集められることもでき、この場合、新しいフィルタが、毎日のスケジュール単位、トレーニングセットへの追加が新たに認められたメッセージ数の単位、および／またはその組合せごとに、バッチプロセスで作成される。分類器に入力される各メッセージごとに、たとえば、分類器用の新しいケースが作成され得る。こうしたケースは、たとえば優先順位が高いまたは低い、テキストの否定的および肯定的例として格納される。一例として、緊急性が低い、中位、および高い１つまたは複数のクラスが、こうしたクラスそれぞれにおける帰属関係の確率が、期待される即時性を構築するのに使用されるように認識され得る。比較的複数の即時性クラスが、より高度な解決を求めるのに使用され得る。たとえば、図９に示したように、メッセージのトレーニングセット（たとえば、非常に高い、高い、中位、普通、低い、非常に低い、など）９４０が、９４４に示されるようにリアルタイムの分類が達成されるように、分類器９４２をトレーニングするのに最初に利用されることができ、この場合、新しいメッセージは、トレーニングセット９４０によって確定された例の数に従って分類される。図９に、このような３つのカテゴリが、例示のために示されているが、このような複数のカテゴリが、変わり得る所望の重要度に従ってトレーニングされ得ることが理解されるべきである。図に示すように、新しいメッセージ９４４は、たとえば、分類器９４２によって割り当てられる優先順位に従って、ラベルをつけられ、タグをつけられ、かつ／あるいは１つまたは複数のフォルダ９４６にソートされることができる。後でより詳しく説明されるように、割り当てられる優先順位は、後続システムによって、ユーザへの／ユーザ向けのメッセージ形式、配信、および様式判定を行うのにさらに使用され得る。
【０１７６】
本発明の別の態様によると、数または値の推定は、たとえば、ケースまたはメッセージを１組のフォルダの１つとしてラベルづけすることではなく、ｅメールとのユーザの相互作用を監視することによって達成され得る。したがって、分類器は、アップデートされ続けられ得るが、ある時期より新しいメッセージまたはドキュメントのケースが、ユーザによって指定されたように検討される移動窓を有する。
【０１７７】
たとえば、メッセージの吟味の遅れに関連する損失定数レートは、メッセージの期待される即時性（ＥＣ）と呼ばれ、次のようになる。
【０１７８】
【数１】
2007509416.tif 000033
【０１７９】
上式で、Ｃはコスト関数であり、ｄは遅れであり、Ｅはイベントであり、Ｈはｅメールの即時性クラスであり、ＥＣは、潜在的クラス（群）に対する、コスト関数Ｃによって記述される損失レートによって重み付けされたクラス（群）の確度に渡る和として表される。
【０１８０】
一例として、さらに図９を参照すると、ｅメールメッセージなどのテキスト９３６は、分類器９２０に入力され、分類器９２０は、それに基づいて、テキスト９３６に対する優先順位９３８を生じる。つまり、分類器９２０は、たとえば、０から１００％のパーセンテージとして示される優先順位９３８を生じる。このパーセンテージは、分類器９２０の以前のトレーニングに基づく、テキスト９３６が高いまたは他の何らかの優先順位である確度でよい。
【０１８１】
本発明では、上述されたように、分類器９２０および優先順位９３８は、トレーニングフェーズにおけるｅメールが、たとえば、優先順位が高い、または優先順位が低いと解釈される方式に基づき得ることが留意されるべきである。この方式は、図１０を参照して示されており、図１０において、テキスト分類器１０２０は、優先順位が高いと予め定められているテキスト群１０４７、および優先順位が低いと予め定められているテキスト群１０４８によってトレーニングされる。分析されるテキストは、分類器１０２０に入力され、分類器は、たとえば、分析されているテキストの優先順位が高いまたは低い確度を示す、スカラー数１０４９を出力する。
【０１８２】
たとえば、図１０および１１を参照すると、この２つの図は、テキスト１０３６、１１３６が、低い、中位、および高い優先順位にカテゴリ化される方式を示す。上述したように、より優れた、またはより程度の高い優先順位の解決特徴をもたらすために、他の複数のトレーニングセットが利用され得る。テキスト分類器１０２０、１１２０は、優先順位が高いテキスト群１０４７、１１４７および優先順位が低いテキスト群１０４８、１１４８によって、かつ優先順位が中位のテキスト群１１５０によってトレーニングされる。したがって、分析されるテキスト１０３６、１１３６は、分類器１０２０、１１２０に入力され、こうした分類器は、分析されているテキストの優先順位が、たとえば、高いと所望される場合は高い確度も、優先順位が中位の、または優先順位が低い確度も示し得るスカラー数１０４９、１１４９を出力する。分類器１０２０、１１２０は、クラス１１５２を出力することもでき、クラス１１５２は、テキスト１１３６が該当する可能性の最も高い、優先順位が低い、中位、または高いクラスを示す。所望される場合、それ以外のクラスも追加され得る。
【０１８３】
本発明は、優先順位が、分類器１０２０、１１２０によって、ｅメールメッセージなどのテキストにこのような優先順位を割り当てるのに利用される際の、優先順位という用語の定義に限定されない。優先順位は、たとえば損失関数に関して定義され得る。より具体的には、優先順位は、テキストが受け取られた後、そのテキストの吟味における時間の遅れに対する、失われた機会において予期されるコストに関して定義され得る。つまり、テキスト処理の遅れの結果生じるであろう、予期される損失またはコストである。損失関数は、受け取られるテキストのタイプに従ってさらに変わり得る。
【０１８４】
たとえば、テキストの優先順位に依存する線形コスト関数のグラフ１２５４である、一般的な場合が図１２に示されている。グラフ１２５４において、時間が経過すると、テキストを吟味していないコストが高くなる。ただし、コストは、線１２５８で示される優先順位が中位のメッセージ、または線１２６０で示される優先順位が低いメッセージと比較して、線１２５６で示されるように、優先順位が高いメッセージに対してより高くなる。たとえば、優先順位が高い線１２５６は、傾斜が１００であり、優先順位が中位の線１２５８は、傾斜が１０であり、優先順位が低い線１２６０は、傾斜が１であり得る。こうした傾斜値は次いで、分類器１０２０、１１２０によって、たとえば、回帰分析による、所与のテキストへの優先順位の割当てに使用され得る。
【０１８５】
しかし、いくつかのメッセージは、線形コスト関数を使用して、メッセージの優先順位を十分に近似させていない。たとえば、ミーティングに関するメッセージは、ミーティングの時間が近づくにつれてそのコスト関数を上昇させ、その後、コスト関数は急速に低下する。つまり、ミーティングを欠席した後、ユーザがそのことに対してできることはほとんどない。この状況は、図１３に示すように、非線形コスト関数によってより十分に近似される。グラフ１３６２において、コスト関数１３６４は、線１３６６で定められたミーティングの時間に到達するまで急速に上昇し、ミーティング時間の後は急速に低下する。メッセージのタイプに応じて、コスト関数は、線形および非線形両方の、異なる多くの代表的コスト関数の１つによって近似され得る。
【０１８６】
したがって、説明されたように、テキストの優先順位は、分類器の出力に基づく複数の優先順位の１つである確度であればよく、やはり分類器の出力に基づく、テキストが該当する可能性が最も高い優先順位クラスでもよい。あるいは、ｅメールメッセージなどのテキストの、期待される即時性が判定され得る。即時性は、次のように書かれ得る。
【０１８７】
【数２】
2007509416.tif 000034
【０１８８】
上式で、ＥＬは、期待損失であり、ｐ（ｃｒｉｔｉｃａｌｉ）は、テキストが即時性ｉを有する確率であり、Ｃ（ｃｒｉｔｉｃａｌｉ）は、即時性ｉを有するテキストに対するコスト関数であり、ｎは、即時性クラスの総数マイナス１である。コスト関数は、説明されたように、線形でも非線形でもよい。関数が線形の場合、コスト関数は、時間に伴う損失定数レートを定義する。非線形関数の場合、損失レートは、テキストの吟味または処理の遅れとともに変わり、遅れの量に応じて上昇することも低下することもできる。
【０１８９】
ｎ＝１の場合、２つの優先順位クラス、すなわち低いおよび高いクラスのみがあると指定すると、期待損失は、次のように公式化し直され得る。
ＥＣ＝ｐ（ｃｒｉｔｉｃａｌｈｉｇｈ）Ｃ（ｃｒｉｔｉｃａｌｈｉｇｈ）＋［１−ｐ（ｃｒｉｔｉｃａｌｌｏｗ）］Ｃ（ｃｒｉｔｉｃａｌｌｏｗ）
【０１９０】
上式で、ＥＣは、テキストの期待される即時性である。さらに、即時性が低いメッセージのコスト関数がゼロに設定される場合、上の式は、
ＥＣ＝ｐ（ｃｒｉｔｉｃａｌｈｉｇｈ）Ｃ（ｃｒｉｔｉｃａｌｈｉｇｈ）
となる。テキストを吟味するときまでの全損失は、表される即時性の統合、すなわち、
【０１９１】
【数３】
2007509416.tif 000035
【０１９２】
と表され得る。上式で、ｔは、ドキュメントを吟味するまでの時間の遅れである。
【０１９３】
重要度によって、ｅメールメッセージなどのドキュメントに順位をつける基準値を与える他の測度もある。上記の説明は、即時性としての優先順位に焦点を当てたが、他の「重要度」概念もトレーニングされ得る。たとえば、このようなトレーニングは、「重要度が高い」ものから「重要度が低い」ものまですべてに渡って、１組のトレーニングフォルダにラベルをつけることによって遂行されることができ、「期待される重要度」の測度が決定され得る。別の基準値は、「旅行中、１日以内に知らせを受けたいメッセージ」というセマンティックラベルに基づいて、旅行中のユーザに転送するメッセージに優先順位をつける測度を決定することができる。さらに、使用される１つの基準値は、意思決定、選別、および経路指定のための明白なセマンティクスを有するので、緊急性または即時性である。この場合、クラスは、様々なレベルの緊急性に従ってラベルづけされ、メッセージが各クラス中にあると推論される確率から、各メッセージに対して期待される緊急性として計算される。
【０１９４】
即時性分類に対する拡張は、先行セクションで説明したように、本発明に従って提供されることもできる。たとえば、分類は、特徴クラス内部での、またはクラス間での見返りの大きい特徴の複合を求める自動検索を含み得る。一例として、特定のユーザにとって特に有用であることが発見された単語との、特殊な区別、構造などの複合が検索され、分類プロセスにおいて使用されることができる。２つの特徴の複合はダブレットと呼ばれ、３つの特徴の複合はトリプレットと呼ばれ、以下同様になる。特徴の複合は、分類の向上を可能にし得る。
【０１９５】
分類は、分類器において移動窓を利用する増分索引づけを使用しても改善され得る。この索引づけは、古いデータがタイムアウトされ、新しいデータが持ち込まれるのに従って、分類器が定常的にリフレッシュされることを可能にする。
【０１９６】
分類は、メッセージ中で指定されたイベント日時の判定にも基づき得る。この判定は、分類器によって使用され得るメッセージに特徴を割り当てることができる。たとえば、割り当てられる特徴は、今日の４時間以内、今日の８時間以内、明日、今週、今月、および来月ならびにそれ以降を含み得る。このことは、分類器が、分類されるメッセージに関して、向上した正確さを有することを可能にする。概して、分類は、イベントが未来のものであるか、それとも過去のものであるかを考慮して、言及されるイベントの時間に基づき得る。未来のイベントに関して、分類はしたがって、イベントが起こりそうなとき、送信者の、未来の時間への言及を考慮する。
【０１９７】
他の新しい特徴も、分類プロセスに統合され得る。たとえば、組織図における送信者の場所によって、メッセージがどの程度重要であるかを判定するために、組織図が使用され得る。言語特徴が、分類器に統合され得る。異なる言語に適応させるために、特徴は、送信者の起点、および／またはメッセージが書かれる言語に応じて修正され得る。分類は、メッセージが格納される異なるフォルダ、ならびに他のスケーリングおよび制御規則に応じて変わり得る。ｅメールおよび他のソースに加えて、分類は、インスタントメッセージ、および、株価表示器など、他の情報ソースに対して実施され得る。
【０１９８】
概して、送信者および受信者の間の構造的関係が、分類プロセスにおいて考慮され得る。たとえば、ユーザが、実質的にメッセージのただ１人の受信者である場合、このメッセージは、少人数の人々に送られるメッセージより重要と見なされ得る。一方、少人数の人々に送られるメッセージは、ユーザにブラインドコピーで送られ（ｂｃｃされ）、またはカーボンコピーで送られる（ｃｃされる）メッセージより重要な場合がある。送信者に関して、送信者名が認識されるかどうかに基づいて、即時性が割り当てられ得る。即時性は、送信者が、ユーザが関わる組織に対して内部であるか、それとも外部であるかに応じても割り当てられ得る。
【０１９９】
分類において考慮され得る他の区別は、メッセージの長さ、質問が検出されているかどうか、およびメッセージ中にユーザ名があるかどうかを含む。即時性に関連する言葉は、メッセージの重要度を高め得る。たとえば、「まもなく起こる」、「今すぐ」、「できるだけ早く」、「ＡＳＡＰ」、および「期限」などのフレーズは、メッセージをより即時的にさせ得る。未来時制と比較して過去時制の使用、ならびに、たとえば「ｇｅｔ  ｔｏｇｅｔｈｅｒ」、「ｃａｎ  ｗｅ  ｍｅｅｔ」などのフレーズによって指定される協調的タスクも考慮され得る。ジャンクメールであるという証拠は、メッセージの優先順位を下げ得る。組織図においてユーザに最も近い送信者からの短い質問など、複合を表す述部も、分類プロセスにおいて考慮され得る。
【０２００】
本説明の次のセクションにおいて、優先順位が高いテキスト、たとえば、ユーザ設定閾値より大きい、または決定論的類推によって決定された閾値より大きい、優先順位が高い確度を有するテキストを、いつユーザに警告するかという判定をもたらすプロセスが説明される。つまり、緊急のメッセージについて知っているだけでなく、たとえばユーザが着信ｅメールを直接見ていない場合、ユーザに緊急のメッセージをいつ警告するかを決定することも重要である。概して、緊急のメッセージについて学習するために、対処中の現在のタスクからユーザの注意を散逸させるコストが決定される。
【０２０１】
あるいは、警告および通知用の様々なポリシーが利用され得る。こうしたポリシーは、たとえば、後でより詳しく説明される通知プラットフォームアーキテクチャにおいて実装され得る。こうしたポリシーの一部は、次のものを含む。
・ユーザが指定した上限を全損失に対して設定する。このポリシーは、メッセージの、吟味の遅れに関連する全損失が、予め指定された一定の「許容」損失「ｘ」を超えると、システムが警告を生成するように指定する。
・別のポリシーは、ＮＥＶＡ＝ＥＶＴＡ−ＥＣＡ−ＴＣなど、より完全な決定論的分析に基づくコスト対利益分析であり得る。上式で、ＮＥＶＡは警告の純期待値であり、ＥＶＴＡは警告の期待値であり、ＥＣＡは警告の期待コストであり、ＴＣはメッセージの通信に関連づけられた伝送コストである。
【０２０２】
概して、時間ｔでメッセージを吟味しない場合に、ユーザが被ることになる期待損失が、ユーザへの警告の期待コストより大きいことを、コスト対利益分析が示唆するとき、ユーザは警告を受けるはずである。つまり、警告は、
ＥＬ−ＥＣ＞０
の場合に行われるべきである。上式で、ＥＬは、現在時刻ｔでテキストを吟味していないときの期待損失であり、ＥＣは、現在時刻ｔでユーザにテキストについて警告する際の、期待されるコストである。期待損失は、本実施形態の先行セクションにおいて説明された通りである。
【０２０３】
しかし、ユーザはしばしば、メッセージを将来自分で吟味するので、上記の公式化は、最も正確なわけではない。したがって、実際には、ユーザは概して、ＥＶＴＡと呼ばれる警告の期待値が正数であるときに警告されるはずである。警告の期待値はしたがって、ユーザが、メッセージを後で自分で吟味する際の値とは対照的に、現時点でユーザにテキストについて警告する際の値を、警告なしで、すなわち警告コストを差し引いて考慮すべきである。警告の期待値は、次のように規定され得る。
ＥＶＡ＝ＥＬａｌｅｒｔ−ＥＬｎｏ−ａｌｅｒｔ−ＥＣ
【０２０４】
上式で、ＥＬａｌｅｒｔは、警告されてから、ユーザがメッセージを現時点で吟味する場合の、メッセージを吟味するユーザの期待損失であり、対照的に、ＥＬｎｏ−ａｌｅｒｔは、警告されることなく、メッセージをいつか自分で吟味するユーザの期待損失であり、−ＥＣは、注意散逸の考慮および情報伝送の直接コストに基づく警告の期待コストである。
【０２０５】
さらに、いくつかのメッセージからの情報は、まとめて一度の複合警告にグループ化され得る。複数のメッセージについての情報を一度の警告において吟味することは、１通のメッセージについての情報を中継する際の警告よりコストがかかり得る。このような注意散逸の増加は、警告コストを、その情報の複雑さの関数にすることによって表され得る。ｅメールメッセージのＥＶＡは、他のｅメールメッセージのＥＶＡに依存しないと仮定され得る。ＥＶＡ（Ｍｉ，ｔ）は、たとえば、時間ｔにおいて１通のメッセージＭｉについてユーザに警告する値を指し、ＥＣＡ（ｎ）は、ｎ通のメッセージの内容の、中継の期待コストを指す。したがって、１組のｎ通のメッセージについての情報を中継する期待値を合計することによって、複数のメッセージが考慮されることができ、次のようになる。
【０２０６】
【数４】
2007509416.tif 000036
【０２０７】
警告の期待コストを判定するために、ユーザがいるかいないかについての情報を推論し、またはその情報に直接アクセスすることが有用であることも留意されるべきである。ユーザが職場にいるときを示す赤外線センサおよび圧力センサなどのセンサが利用され得る。しかし、このようなデバイスが使用可能でない場合、ユーザが職場にいる確率は、たとえば、最後に観察されたマウスまたはキーボード活動からの時間など、ユーザのコンピュータ活動に応じて割り当てられ得る。さらに、カレンダにおいて利用可能なスケジューリング情報も、ユーザの距離および配置の推論を行い、異なるプロセスによってユーザにメッセージを転送するコストを検討するのに利用され得る。
【０２０８】
即時性が高いメッセージについての情報で、ユーザへの割込みを決定する際に、ユーザがどれ程忙しいかを知ることも重要である。ユーザがコンピュータで作業をしているかどうか、および作業をしている比率、またはユーザが電話で誰かと話しているか、それとも別の場所でミーティングをしているかについて、類推され得る（たとえば、推論的意思決定）。ユーザの活動またはユーザの注目を推定するのに、図１４に示されるようないくつかの証拠クラスが利用され得る。ベイズのネットワークが次いで、ユーザの活動についての推論の実施に使用され得る。このようなネットワークの例が、図１５に示されている。
【０２０９】
概して、決定は、いつ、およびどのようにしてユーザにメッセージを警告するか、ならびに期待される即時性およびユーザ活動の推論に基づいてサービスを提供するかについて、行われるべきである。決定は、たとえば、決定モデルを使用することによって実施され得る。図１６〜１８は、このような決定モデルが、警告決定を行うのにどのようにして使用され得るかを示す影響図である。図１６は、現在の活動、メッセージの期待される即時性、および通信様式に応じた警告コストを考慮した、ユーザへの割込みについて決定する決定モデルを表す。図１７は、現在の場所を表す変数ならびにその変数が活動および代替メッセージ通信技術のコストに対して与える影響も含む。さらに、図１８は、かなりのグラフィックスコンテンツを有するメッセージが、グラフィカルなコンテンツなしでユーザに転送されるときの忠実度の損失に関連するコストを考慮するように拡張される。
【０２１０】
あるいは、いつ、およびどのようにしてユーザに警告するかに関する決定は、警告に関するポリシーを定義する１組のユーザ指定閾値およびパラメータを利用して行われ得る。ユーザの存在は、たとえばマウスやキーボード活動に基づいて推論され得る。したがって、ユーザは、たとえば、活動および非活動という推論状態に関する警告に対する閾値を入力することを可能にされ得る。ユーザは、より低い即時性で警告が起こる活動に続く待機状態量を入力することもできる。実質的にコンピュータ活動が検出されない時間に基づいて、ユーザが応対できないと判定された場合、メッセージは、格納されることができ、ユーザがコンピュータと対話しに戻ったとき、即時性順でユーザに報告される。さらに、ユーザは、期待される即時性、最大期待損失、およびユーザへの警告値を含む量に応じて、経路指定およびページング選択肢を指定することができる。
【０２１１】
通知および／または警告システムも、ユーザが戻ると期待されるときを推定することができ、そうすることによって、ユーザが戻ることが期待される前に、重要であると期待される優先順位を送信する。この推定は、ユーザがいるパターンおよびユーザ不在パターンを、時間をかけて学習することによって達成され得る。ユーザは次いで、ユーザが、優先順位について警告されることなく、優先順位を吟味するためにシステムに戻ると期待されるときに関して、適切なポリシーを設定することができる。システムによって判定を返すことが期待される時間は、たとえば、緊急性の高いメッセージの送信者に自動的に伝えられ得る。このようにして、メッセージ送信者は、ユーザがメッセージに返信し得るように、いつ戻ることが期待されるかというフィードバックを受け取る。送信者は、自分のメッセージがユーザのモバイルデバイスなどに伝えられていることも知らされ得る。
【０２１２】
図１９は、本発明による、優先順位を生成し、優先順位に基づいて警告決定を実施する方法を示す。説明を簡単にするために、方法は、一連の作用として示され説明されるが、本発明は作用の順序によって限定されないことが理解されるべきである。というのは、いくつかの作用は、本発明に従って異なる順序で起こることもでき、かつ／または本明細書において示され説明される他の作用と同時に起こることもできるからである。たとえば、方法は、状態図でのように、相関する一連の状態またはイベントとしても表され得ることを当業者は理解するであろう。さらに、例示されるすべての作用が、本発明による方法の実装に必要とされ得るわけではない。
【０２１３】
図１９を参照すると、フローチャート１９７４は、本発明に従って優先順位が生成され、使用される方法を示す。１９８０で、優先順位を割り当てられているテキストなどのデータが受け取られる。データは、ｅメールメッセージでも、実質的に他のどのタイプのデータまたはテキストでもよい。１９８２で、データに対する優先順位が、説明されたように、分類器に基づいて生成される。さらに、１９８２は、説明されたように、分類器の初期および後続トレーニングを含み得る。
【０２１４】
データの優先順位は次いで、１９８４で出力される。図１９に示されるように、１９８４は、１９８６、１９８８、１９９０、１９９２、および１９９４での処理を含み得る。１９８６で、現在時刻ｔでのデータ未検討の期待損失が判定される。この判定は、説明されたようにユーザが、警告されることなくテキストを自分で検討するという仮定に基づいた、将来のテキスト未検討の期待損失を考慮する。１９８８で、警告の期待コストが、説明されたように判定される。損失が１９９０でのコストより大きい場合、１９９２の時間ｔでは警告は行われず、プロセスは、新しい現在時刻ｔの１９８６に戻る。時間が経過すると、期待損失がどこかで警告コストを上回る場合があり、その結果１９９０での計算が変わり得るので、１９８６に戻ることが実施され得る。期待損失が警告コストを上回ると、ユーザまたは他のシステムへの警告が１９９４で実施される。
【０２１５】
ユーザまたは他のシステムに対する警告の出力が、次に説明される。ユーザは、優先テキストについていつユーザが警告されるべきかを示す警告基準に基づいて、電子デバイス上で警告され得る。ユーザが警告を受ける電子デバイスは、後でより詳しく説明されるように、ページャ、セルラー／デジタル移動電話、または他の通信様式でよい。ページャや携帯電話などの電子デバイスでの、ユーザに対する警告は、たとえば場所、推論されるタスク、および／またはユーザの注目についての情報に敏感であるように適合され得る警告基準に基づき得る。このような情報は、不確実性下で推論されることもでき、オンライン情報ソースからアクセスされることもできる。たとえば、オンラインカレンダからの情報は、後でより詳しく説明される通知シンクなど、デバイスへの情報中継についての決定を行うのに利用される基準を制御するように適合され得る。
【０２１６】
警告は、経路指定基準に基づいて、優先テキストまたは他のデータを経路指定することによって実施され得る。テキストの経路指定は、テキストがｅメールの場合、テキストの転送、および／またはテキストの送信者への返信を含み得る。たとえば、ユーザに優先ドキュメントを警告するのに、音が鳴らされ得る。あるいは、エージェントまたは自動化されたアシスタントが開かれ得る（たとえば、インタラクティブ表示ウィザード）。つまり、エージェントは、表示画面上に現れて、ユーザに優先ドキュメントを通知することができる。さらに、優先ドキュメントが、スクリーン上に表示されるなどして、開かれ得る。ドキュメントは、注目を受けることができる。このことは、ドキュメントの優先順位が高い程、ドキュメントが表示されるウィンドウが大きくなるように、優先順位に基づいてドキュメントのサイズを変更すること、および／または優先順位に基づいてドキュメントをディスプレイの中央に配置することも含み得る。
【０２１７】
ここで図２０を参照すると、図２０は、本発明の態様によるテキスト生成および優先順位システム２０００の図である。システム２０００は、プログラム２００２および分類器２００４を含む。プログラム２００２および分類器２００４は、コンピュータのプロセッサによって、プロセッサのコンピュータ可読媒体から実行されるコンピュータプログラムを含み得ることが留意されるべきである。
【０２１８】
プログラム２００２は、分類器２００４への入力用テキストを生成する。プログラムは、その後テキストとして働くｅメールを受け取る電子メールプログラムを含む。分類器２００４は、関連するメッセージに対する優先順位を生成する。上述したように、分類器２００４は、ベイズの分類器、サポートベクトルマシン分類器、または他のタイプの分類器でよい。分類器２００４によって出力されるテキストの優先順位は次いで、説明されたように、コスト対利益分析に関連して使用されて、それ以上の出力および／または出力に基づく警告を引き起こすことができる。
【０２１９】
次に図２１に移ると、システム２１００は、本発明の態様に従って、プレファレンス実行エンジンおよびコンテキストアナライザがどのようにして合同で機能するかを示す。システム２１００は、コンテキストアナライザ２１２２、プレファレンス実行エンジン２１２４、１つまたは複数のイベントまたは通知ソース１からＮ、２１２６、２１２７、２１２８、通知ソースとして働き得る優先順位システム２１３０、ならびに１つまたは複数のアクションまたは通知シンク１からＭ（ＮおよびＭはそれぞれ整数）、２１３６、２１３７、２１３８を含む。本発明の態様によると、ソースは、イベント発行元と呼ばれる場合もあり、シンクは、イベント登録側と呼ばれる場合もある。任意の数のシンクおよびソースが存在し得る。概して、実行エンジン２１２４は、コンテキストアナライザ２１２２に格納されている、かつ／またはそれによってアクセスされるパラメータ情報に部分的に基づいて、イベントまたは警告とも呼ばれる通知を、ソース２１２６〜２１２８からシンク２１３６〜２１３８に伝える。
【０２２０】
コンテキストアナライザ２１２２は、通知意思決定に影響するユーザの変数およびパラメータに関する情報を格納し／分析する。たとえば、パラメータは、時刻および曜日ごとの、ユーザの通常の居場所および注目対象または活動などのコンテキスト情報と、ユーザが様々な場所でそれに対するアクセス権をもつことが多いデバイスなどのようなパラメータを必要条件とする追加パラメータとを含み得る。このようなパラメータは、１つまたは複数のセンサを介して自律的に行われる観察の結果の関数でもよい。たとえば、１つまたは複数のプロファイル（図示せず）が、全地球位置発見システム（ＧＰＳ）サブシステムによって与えられ得るユーザの居場所についての情報、使われているデバイスのタイプについての情報、および／またはデバイスの使用パターン、ならびに特定のタイプのデバイスがユーザによって最後にアクセスされたときに基づいて、選択されることも修正されることもできる。さらに、後でより詳しく説明されるように、場所および注目などのパラメータまたは状態を動的に推論するのに、自動化推論も利用され得る。プロファイルパラメータは、ユーザによって編集され得るユーザプロファイルとして格納され得る。予め定義されたプロファイルの組または動的推論に依拠するだけでなく、通知アーキテクチャは、たとえば、重要な通知以外、ユーザは、これから「ｘ」時間の間または所与の時間まで連絡がつかないなど、ユーザが自分の状態をリアルタイムに指定することを可能にし得る。
【０２２１】
パラメータは、実行エンジン２１２４による通知決定を行うための根拠として使用されることができるとともにユーザが変更を開始し得るきっかけとなる、様々な設定における様々なタイプの通知によって妨害されることに関する、ユーザのプレファレンスに関するデフォルトの通知プレファレンスパラメータも含み得る。パラメータは、ユーザがそれぞれの状況においてどのようにして（たとえば、セル電話、ページャなどによって）通知されることを望むかに関するデフォルトパラメータを含み得る。パラメータは、様々な設定において様々なモードによって通知されることに関連する中断コストのような査定を含み得る。このコストは、ユーザがそれぞれの場所にいる確度、それぞれのデバイスが使用可能である確度、および所与の時間でのユーザの注目状況の確度を示すコンテキストパラメータ、ならびにユーザが、所与の時間にどのようにして通知されることを望むかを示す通知パラメータを含み得る。
【０２２２】
コンテキストアナライザ２１２２によって格納されている情報は、本発明の一態様によると、アナライザによって判定されたコンテキスト情報を含む。コンテキスト情報は、本説明の後のセクションでより詳しく説明されるように、アナライザ２１２２によって、１つまたは複数のコンテキスト情報ソース（図示せず）に基づいてユーザの居場所および注目状況を見分けることによって判定される。コンテキストアナライザ２１２２は、たとえば、ユーザの車またはセル電話の一部である全地球位置発見システム（ＧＰＳ）により、ユーザの実際の場所を正確に判定することができる。アナライザは、統計モデルを利用して、バックグラウンドでの査定および／または日のタイプ、時刻、ユーザのカレンダ中のデータのような情報を考慮して集められた観察結果、およびユーザの活動についての観察結果を考慮することによって、ユーザが所与の注目状態にある確度を判定することもできる。所与の注目状態は、ユーザが、通知を受け取る用意ができているか、忙しくて通知を受け取る用意ができていないかということを含むことができ、平日、週末、休日、および／または他の場合／時期など、他の検討事項を含むことができる。
【０２２３】
ソース２１２６〜２１２８、優先順位システム２１３０は、ユーザおよび／または他のエンティティに向けられる通知を生成する。たとえば、ソース２１２６〜２１２８は、インターネットおよびネットワークベースの通信、電話通信などの通信、ならびにソフトウェアサービスを含み得る。通知ソースは概して、本明細書において、ユーザまたはユーザ代理に、情報、サービス、および／またはシステムもしくは世界中のイベントについて警告することを意図した、通知および警告とも呼ばれ得るイベントを生成するものとして定義される。通知ソースは、イベントソースとも呼ばれ得る。
【０２２４】
たとえば、ｅメールが、優先順位をつけられて、優先順位システム２１３０によって通知として生成されることができ、通知を生成するアプリケーションプログラムまたはシステムは、ユーザにとっての、ｅメールの、可能性の高い重要度または緊急性に対応する相対優先順位をｅメールに割り当てる。ｅメールは、ユーザにとっての相対重要度とは無関係に送られることもできる。インターネット関連サービスは、ユーザが、たとえば、しばしば最新ニュースのヘッドラインおよび株式相場などに申し込んだという情報を含む通知を含み得る。
【０２２５】
通知またはイベントソース２１２６〜２１２８自体は、プッシュタイプでもプルタイプソースでもよい。プッシュタイプソースは、登録された後で自動的に情報を送るヘッドラインニュースおよび他のインターネット関連サービスなど、情報を、対応する要求なしで自動的に生成し、送るソースである。プルタイプソースは、メールサーバがポーリングされた後で受信されるｅメールなど、要求に応答して情報を送るソースである。さらに他の通知ソースは、次のものを含む。
・カレンダシステムなど、ｅメールのデスクトップアプリケーション、
・コンピュータシステム（たとえば、システム活動または問題についての警告を通知するメッセージでユーザに警告することができるシステム）、
・インターネット関連サービス、予定情報、スケジューリングクエリ、
・１つまたは複数の共有フォルダ中の、ドキュメントまたは特定の種類のドキュメント数の変化、
・情報を求める永続的または未解決のクエリに応答した、新しいドキュメントの可用性、ならびに／あるいは、
・人々およびその存在、居場所の変更、近接（たとえば、私が旅行中のとき、別の同僚または友人が私の１０マイル（１６ｋｍ）圏内にいたら知らせる」）、または応対可能性（たとえば、Ｓｔｅｖｅが会話できる状態にあり、完全なテレビ会議をサポートし得る高速リンクの近くにいたら知らせる」）についての情報用の情報ソース。
【０２２６】
通知アクションシンク２１３６〜２１３８は、ユーザに通知を与えることができる。たとえば、このような通知アクションシンク２１３６〜２１３８は、デスクトップおよび／またはラップトップコンピュータなどのコンピュータ、ハンドヘルドコンピュータ、セル電話、陸線電話、ページャ、車載コンピュータ、ならびに理解され得るように他のシステム／アプリケーションを含み得る。シンク２１３６〜２１３８の一部は、他のシンクより、通知を豊富に伝え得ることが留意されるべきである。たとえば、デスクトップコンピュータは一般に、スピーカおよび比較的大型のカラーディスプレイが結合され、かつ、ローカルネットワークまたはインターネットに結合されると、情報を受け取るより高い帯域幅を有する。したがって、通知は、デスクトップコンピュータによってユーザに比較的豊富に伝えられ得る。逆に、多くのセル電話は、たとえば、白黒の場合もある比較的小型のディスプレイを有し、比較的低い帯域幅で情報を受け取る。同様に、セル電話によって伝えられる通知に関連づけられた情報は概して、比較的短くてよく、たとえば、電話のインターフェイス機能向けに連動され得る。したがって、通知内容は、セル電話に送られるか、それともデスクトップコンピュータに送られるかに応じて異なり得る。本発明の一態様によると、通知シンクは、イベント加入サービスを介して、たとえば、イベントまたは通知に登録するシンクを指し得る。
【０２２７】
実行エンジン２１２４は、コンテキストアナライザによって格納されている、かつ／または決定された情報にアクセスし、通知のどれがソース２１２６〜２１２８から受け取られて、シンク２１３６〜２１３８のどれに伝えるべきか判定する。さらに、エンジン２１２４は、情報を送るのに、シンク２１３６〜２１３８のどれが選択されているかに応じて、通知がどのようにして伝えられるべきかを決定することができる。たとえば、選択されたシンク２１３６〜２１３８に与えられる前に、通知が要約されるべきであるということが決定され得る。
【０２２８】
本発明は、エンジン２１２４が、通知のどれを通知シンクのどれに伝えるか、かつ、どのような方法で通知が伝えられるかについての決定をどのようにして行うかということに限定されない。一態様によると、決定論的分析が使用され得る。たとえば、実行エンジン２１２４は、ユーザの居場所、注目、デバイスの使用可能性、および警告がなかった場合にユーザが情報にアクセスするまでの時間の長さを含む変数に関する重要な不確実性を推論するように適合され得る。通知エンジン２１２４は次いで、ユーザに通知を警告するかどうかについて、ならびに、警告する場合は、要約の性質および通知の中継に利用するのに適した１つまたは複数のデバイスについて、通知決定を行うことができる。概して、実行エンジン２１２４は、通知の純期待値を決定する。決定の際、エンジン２１２４は、次のものを考慮することができる。
・使用可能な各通知シンクの忠実度および伝送信頼性、
・ユーザ妨害の注目コスト、
・ユーザへの情報の新規性、
・ユーザが情報を自分で検討するまでの時間、
・情報の潜在的コンテキスト依存の値、および／または、
・通知に含まれる情報の、時間とともに上昇し、かつ／もしくは減少する値。
【０２２９】
不確実性について行われる推論はしたがって、たとえばユーザの何らかの注目状態を前提として、特定のデバイスの特定のモードを使用したユーザへの中断コストなど、値の期待確度として生成され得る。実行エンジン２１２４は、次の１つまたは複数に関して決定を行うことができる。
・ユーザが現在、何に注意を向けており、何をしているか（たとえば、コンテキスト情報に基づく）、
・ユーザが現在いるところ、
・情報の重要度、
・通知保留コスト、
・通知の注意散逸度、
・ユーザに連絡がつく確度、および、
・所与の通知シンクの特定のモードの使用に関連する忠実度損失。
【０２３０】
したがって、実行エンジン２１２４は、保留されている通知およびアクティブな通知の決定論的分析などの分析を実施することができ、情報シンクおよびソースによって与えられるコンテキスト依存変数を評価し、ユーザが情報を吟味し得るまでの時間ならびにユーザの居場所および現在の注目状態など、選択された不確実性を推論する。
【０２３１】
さらに、実行エンジン２１２４は、個別設定された決定論的分析の代わりに、またはそれをサポートするために、コンテキストアナライザ２１２２によって、ユーザプロファイルとして格納されている情報にアクセスすることができる。たとえば、ユーザプロファイルは、所与のときに、ユーザがページャを介して、通知が所定の重要度レベルを有する場合のみ通知されることを好むと示し得る。このような情報は、決定論的分析を開始するための基準線として使用されることもでき、実行エンジン２１２４が、どのようにしてユーザに通知するか、および通知するかどうかを決定するための方法にもなり得る。
【０２３２】
本発明の一態様によると、通知プラットフォームアーキテクチャ２１００は、イベント通信またはメッセージ通信インフラストラクチャの上に常駐する層として構成され得る。ただし、本発明は、特定のどのイベント通信インフラストラクチャにも限定されない。このようなイベント通信およびメッセージ通信システムおよびプロトコルは、次のものを含み得る。
・ハイパーテキストトランスポートプロトコル（ＨＴＴＰ）、または当該分野において公知なＨＴＴＰの拡張、
・当該分野において公知なシンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）、
・当該分野において公知なＷｉｎｄｏｗｓ（登録商標）  Ｍａｎａｇｅｍｅｎｔ  Ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ（ＷＭＩ）、
・当該分野において公知なＪｉｎｉ、および、
・たとえばパケット交換プロトコルに基づくプロトコルなど、実質的にあらゆるタイプの通信プロトコル。
【０２３３】
さらに、アーキテクチャは、当業者によって理解され得るように、柔軟な分散型コンピュータインフラストラクチャの上に常駐する層として構成され得る。したがって、通知プラットフォームアーキテクチャ２１００は、たとえば、ソースが通知、警告、およびイベントを送る方法として、かつシンクが通知、警告、およびイベントを受け取る方法として、基底インフラストラクチャを使用することができる。ただし、本発明はそのように限定されない。
【０２３４】
ここで図２２を参照すると、本実施形態の先行セクションで説明された情報エージェントシステムアーキテクチャのコンテキストアナライザ２１２２が、ここではシステム２２００内により詳しく示されている。図２２に示されるコンテキストアナライザ２２２２は、ユーザ通知プレファレンスストア２０４０と、ユーザコンテキストプロファイルストア２２６２およびホワイトボード２２６４を含むユーザコンテキストモジュール２２６０とを含む。本発明の一態様によるコンテキストアナライザ２２２２は、コンピュータのプロセッサによって、メモリを含むが、それに限定されない、プロセッサのマシン可読媒体から実行可能な１つまたは複数のコンピュータプログラムとして実装され得る。
【０２３５】
プレファレンスストア２２６２は、ユーザ用のデフォルトの通知プレファレンスなど、ユーザ用の通知パラメータ、たとえばユーザによって編集され修正され得るユーザプロファイルを格納する。プレファレンスストア２２６２は、ユーザがどのようにして通知されるかに影響するパラメータについての情報を格納するものと見なされ得る。本明細書において説明されたように、プレファレンスは、たとえば、ＩＦ−ＴＨＥＮ形式で体系化された論理を使用して、ユーザによって指定され得る。ユーザコンテキストモジュール２２６０は、たとえばホワイトボード２２６４上で公開される、１つまたは複数のコンテキスト情報ソース２２８０に基づいて、ユーザの現在のコンテキストを判定する。ユーザコンテキストプロファイルストア２２６２は、ユーザによって編集され修正され得る、ユーザ用のデフォルトのコンテキスト設定など、ユーザ用のコンテキストパラメータを格納する。つまり、ユーザコンテキストモジュール２２６０は、プロファイルストア２２６２からの情報にアクセスし、かつ／またはストア２２６２中の、先行する１組の確信を、１つまたは複数のコンテキストソース２２８０により有効な感知でアップデートすることによって、ユーザの現在のコンテキスト情報についての最良の推量または推定をもたらす。プロファイルストア２２６２は、たとえば、ユーザがどこにいるか、およびユーザが何をしているかを先験的に格納するストアと見なされ得る。
【０２３６】
ユーザコンテキストプロファイルストア２２６２は、決定的または確率的プロファイルのような情報を捕捉する、予め査定され、かつ／または予め定義されたユーザプロファイルでよい。プロファイルは、時刻、日のタイプ、および１つまたは複数のデバイスとのユーザ対話のような観察に応じた、一般的な場所、活動、デバイスの使用可能性、ならびに様々なクラスの通知コストおよび値に関するものでよい。日のタイプは、たとえば平日、週末、および休日を含み得る。ユーザコンテキストモジュール２２６０は次いで、ユーザの現在または今後の居場所および注目状態など、ユーザのコンテキストまたは状態の側面をアクティブに判定しまたは推論することができる。さらに、コンテキストの実際の状態は、コンテキスト情報ソース２２８０から、ホワイトボード２２６４を介して直接アクセスされることができ、かつ／または、後でより詳しく説明されるベイズの推論などの推論方法により、このような様々な観察から推論されることができる。
【０２３７】
コンテキスト情報ソース２２８０は、ホワイトボード２２６４を介して、コンテキストモジュール２２６０にユーザの注目状態および居場所に関する情報を与えることができ、この情報から、モジュール２２６０は、ユーザの現在のコンテキスト（たとえば、ユーザの現在の注目状態および居場所）に関して、判定を行うことができる。さらに、本発明は、コンテキストソース２２８０の具体的な数またはタイプにも、ユーザコンテキストモジュール２２６０によって推論され、またはアクセスされる情報のタイプにも限定されない。ただし、コンテキストソース２２８０は、たとえば、マウス情報、キーボード情報、アプリケーション情報など、様々なデスクトップ情報およびイベント（たとえば、どのアプリケーションが、現在ユーザの注目を受けているか）、周囲の音および発話情報、デスクトップにあるウィンドウ中のテキスト情報を含み得る。ホワイトボード２２６４は、コンテキスト情報ソース２２８０がそれに対して情報を発行することができ、この情報にソースおよびコンテキストモジュール２２６０を含む複数のコンポーネントがそこからアクセスすることができる、共通の記憶領域を含み得る。通知または警告とも呼ばれるイベントまたはアクションは概して、世界の１つまたは複数の状態の観察についての情報を含み得る。このような状態は、システムコンポーネントの状況、ユーザの活動、および／または環境についての測定値を含み得る。さらに、イベントは、測定デバイスおよび／またはイベントソースのアクティブなポーリングによって、変更があると送られる情報の受信によって、かつ／あるいは一定または可変イベントハートビートの度に生成され得る。
【０２３８】
他のタイプのコンテキストソース２２８０は、たとえばユーザのスケジュールに関するスケジューリング情報を概して提供し得る、ユーザの個人情報マネージャ（ＰＩＭ）情報を含む。現在の時刻、ならびに、たとえば全地球位置発見システム（ＧＰＳ）および／または場所を判定され得るセル電話、ＰＤＡ、もしくはラップトップへのユーザのアクセスによって判定されるユーザの居場所も、コンテキストソース２２８０のタイプである。さらに、リアルタイムのモバイルデバイス使用も、一種のコンテキストソース２２８０である。たとえば、セル電話などのモバイルデバイスは、デバイスが現在ユーザによってアクセスされているかどうか、ならびにデバイスの方向および傾き（たとえば、デバイスの使用に関する情報も示す）と、加速度および速度（たとえば、ユーザが移動中かどうかに関する情報を示す）とを判定することができる。
【０２３９】
ここで図２３を参照すると、上述した通知ソースが、より詳しく示されている。通知ソース２３２６〜２３２８は概して、通知実行エンジン２３２４に伝えられる通知を生成し、エンジン２３２４は、通知がいつ起こるか、および、起こる場合は、通知のどれが通知シンク２３３６〜２３３８のどれに、どのような順序で伝えられるかを決定する。
【０２４０】
本発明の一態様によると、通知ソース２３２６〜２３２８は、本明細書において通知ソーススキーマまたはソーススキーマと呼ばれる、属性および関係の標準的な記述中に、以下のパラメータの１つまたは複数をもつことができる。スキーマは、上述したソース、シンク、およびコンテキスト対情報ソース用に提供され得ることが留意されるべきである。このようなスキーマは、異なるコンポーネントについての宣言情報を与え、ソース２３２６〜２３２８、通知エンジン２３２４、シンク２３３６〜２３３８、およびコンテキストアナライザ２１２２が、意味情報を相互に共有することを可能にし得る。したがって、異なるスキーマが、通知に関連づけられた性質、緊急性、およびデバイス信号様式についての情報を与える。つまり、スキーマは概して、たとえば、イベントまたは通知クラス、ソース、目標、イベントまたは通知セマンティクス、存在論的内容情報、観察の信頼性、および実質的にどのサービス品質属性も含む情報を含む通知およびイベントの構造を定義する、クラスおよびクラス間の関係からなるコレクションとして定義され得る。
【０２４１】
通知ソーススキーマ用パラメータ（図示せず）は、メッセージクラス、適合性、重要度、即時性、新規性、内容属性、忠実度トレードオフ、および／またはソース情報要約情報の１つまたは複数を含み得る。通知ソースによって生成された通知に対するメッセージクラスは、たとえばｅメール、インスタントメッセージ、金融に関する数値のアップデート、およびデスクトップサービスなど、通知の通信タイプを示す。通知ソースによって生成された通知の適合性は、通知に含まれる情報が、指定された１つまたは複数のコンテキストに適合している確度を示す。たとえば、適合性は、ソースが所与のコンテキストに適合しているかどうかを示す論理フラグによって与えられ得る。通知の新規性は、ユーザが、通知に含まれる情報を既に知っている確度を示す。つまり、新規性は、時間が経過しても、情報がユーザにとって新しいかどうかである（ユーザが現時点でその情報を知っているかどうか、および、学習するとしても、ユーザが警告されることなくその情報をいつ学習するかを示す）。
【０２４２】
通知に関連づけられた忠実度トレードオフは、たとえば、指定された様々な形の許容される短縮および／または要約の結果生じ得る、通知中の情報の価値の損失を示す。このような短縮および／または要約は、帯域幅および／または元々生成された完全な通知をシンクが受け取るのを妨げる他の制限を有し得る、ある特定のタイプの通知シンク２３３６〜２３３８に伝えられる通知に必要とされ得る。忠実度は概して、通知に関連づけられた元の内容の完全さの性質および／または程度を指す。たとえば、長いｅメールメッセージは、セル電話によって許容される最大１００文字に短縮され、あるいは要約される場合があり、忠実度の損失を被る。同様に、テキストおよびグラフィックスコンテンツを含む元のメッセージは、テキスト機能しかもたないデバイスを介して伝送されるとき、忠実度における損失を受ける。さらに、デバイスは、ソースから入手可能な最大解像度の一部を示すことしかできない場合がある。忠実度トレードオフは、順序づけ（たとえば、最初にグラフィックス、次いで音、という順序の描画重要度）および／または通知内容の合計値が、忠実度の変化とともにどの程度減じるかを示すコスト関数のいずれかによって記載されるソースの１組の忠実度プレファレンスを指す。たとえば、忠実度トレードオフは、完全なｅメールメッセージの伝送に関連づけられた完全な値が、一層大幅な短縮に伴ってどのように変化するかを記述することができる。内容属性は、たとえば、コアメッセージがテキスト、グラフィックス、および音声コンポーネントを含むかどうかというような情報を表す、内容の性質の要約を含み得る。内容自体は、通知のメッセージ内容を作り上げる実際のグラフィックス、テキスト、および／または音声である。
【０２４３】
通知の重要度は、情報が現在のコンテキストにおいて適切であると仮定した場合、ユーザへの通知に含まれる情報の価値を指す。たとえば、重要度は、ユーザにとっての情報の価値のドル値として表現され得る。即時性は、通知に含まれる情報の価値における時間依存変更、つまり、情報の価値が時間とともにどのように変化するかを示す。すべてではないがほとんどの場合、通知の情報の価値は、時間とともに減衰する。この減衰は、図２４に示されている。グラフ２４００は、時間にマップされた通知の有用性を示す。開始時間を表すグラフ中の点２４０２で、通知の重要度が示され、曲線２４０４は、時間の経過に伴う有用性の減衰を示す。
【０２４４】
図２３に戻ると、異なる通知ソースまたはソースタイプ用のデフォルト属性およびスキーマテンプレートは、図２２のストア２２４０などのユーザ通知プレファレンスストアに格納されている通知ソースプロファイル中で使用可能にされ得る。このようなデフォルトテンプレートは、通知ソースによって与えられた値をオーバーライドし、またはソースによって与えられるスキーマから属性がなくなっているときにそうした属性を提供するように指示され得る。ソース要約情報は、情報の状況概要およびソースから入手可能な潜在的通知をソースが投稿することを可能にする。たとえば、メッセージ通信ソースからのソース要約情報は、少なくともある程度の優先度を有する未読メッセージの総数についての情報、ユーザと通信しようとする、人々による試行状況、および／または他の要約情報を含み得る。
【０２４５】
通知シンク２３３６〜２３３８は、ユーザまたは他のエンティティが通知に含まれる情報を通知され得るための、実質的にどのデバイスでもアプリケーションでもよい。１つまたは複数のどのシンクが特定の通知を伝えるのに利用されるかに関する選択は、通知エンジン２３２４によって決定される。
【０２４６】
通知シンク２３３６〜２３３８は、スキーマ中で与えられる以下のパラメータの１つまたは複数をもつことができる。こうしたパラメータは、たとえば、デバイスクラス、信号（警告）モード、ならびに、関連するモードに対する、忠実度／レンダリング機能、伝送信頼性、実際の通信コスト、および／または中断の注目コストを含み得る。警告属性のパラメータ化制御用に適合されるデバイスの場合、デバイス用のスキーマは、警告属性の記述およびその属性を制御するパラメータ、ならびに他の属性（たとえば、伝送信頼性、配信コスト）が警告属性の異なる設定とともにそれによって変化する関数をさらに含み得る。通知シンク用のスキーマは、通知デバイスが、通知実行エンジン２３２４および／またはシステムの他のコンポーネントを用いてデバイスの性質および機能のセマンティック情報を伝達する方法をもたらす。異なるデバイスタイプ用のデフォルト属性およびスキーマテンプレートは、先行セクションで説明された図２２のストア２２４０などのユーザ通知プレファレンスストアに格納されているデバイスプロファイル中で使用可能にされ得る。このようなデフォルトテンプレートは、デバイスによって与えられた値をオーバーライドし、またはこのようなデバイスによって与えられるスキーマから属性がなくなっているときにそうした属性を提供するように指示され得る。
【０２４７】
スキーマパラメータがそれぞれ、次で明確に説明される。デバイスのクラスは、たとえばセル電話、デスクトップコンピュータ、およびラップトップコンピュータなど、デバイスのタイプを指す。クラスは、モバイルや固定デバイスなど、より全般的でもよい。信号のモードは、所与のデバイスがユーザに通知を警告し得る方式を指す。デバイスは、１つまたは複数の通知モードを有し得る。たとえば、セル電話は、振動するだけでもよく、ある程度のボリュームで音を鳴らすだけでもよく、かつ／または振動しながら音を鳴らしてもよい。さらに、警告システム用のデスクトップ表示は、別個のいくつかのモード（たとえば、音声による通知を伴い、または伴わない、ディスプレイの右上方の小さい通知ウィンドウ、スクリーン上部の小さいサムネイル）に分解され得る。予め定義された１組の振舞いに限定されるのに留まらず、デバイスは、デバイス定義の一部として、パラメータの関数である警告属性を有するモードを可能にし得る。モード用のこのような連続警告パラメータは、たとえば、このような制御を、デスクトップで警告が行われるボリューム、セル電話での呼出し音、および警告ウィンドウの大きさとして表す。
【０２４８】
通知シンク２３３６〜２３３８のモードに関する伝送信頼性は、シンクを介してそのモードでユーザに伝えられる、通知についての、伝達される警告をユーザが受け取る確度を示す。伝送信頼性は、デバイスの使用可能性およびユーザのコンテキストに依存し得るので、様々なデバイスモードの伝送信頼性は、ユーザの居場所および注目のようなコンテキスト属性を条件とし得る。このような（たとえば、自宅から離れているどの場所、午前８時以降、正午前のどの期間にも関する）属性の抽象化として作成された論理和として定義される、独自の場所および独自の注目状態のような属性の外積によって定義される、独自の１つまたは複数のコンテキスト状態に対する伝送信頼性も指定され得る。たとえば、ユーザが現在どこにいるかに応じて、セル電話に伝送される情報は、特にユーザが断続性のあるカバー領域を有する領域にいる場合、またはユーザがその場所でセル電話を持とうとしない場合（たとえば、家族で過ごす休日）には、ユーザに常に届くわけではない。コンテキストは、周囲のノイズおよび／またはコンテキストの他のマスキングもしくは注意散逸プロパティのせいで、伝送信頼性にも影響し得る。
【０２４９】
通信の実際のコストは、シンクに伝えられる通知に含まれる場合、ユーザに情報を伝達する実際のコストを示す。たとえば、このコストは、セル電話伝送に関連する料金を含み得る。中断コストは、特定のコンテキストにおいて、デバイスの特定のモードで利用される警告に関連する中断に関連する注目コストを含む。注目コストは通常、ユーザの特定の注目に反応する。忠実度／レンダリング性能は、やはりあるモードを前提とする、テキスト記述、グラフィックス、およびデバイスの音声／触覚機能である。たとえば、セル電話のテキストの上限は、どの１通のメッセージに対しても１００文字でよく、電話は、グラフィックス機能をもたない場合もある。
【０２５０】
次に図２５に移ると、例示的なインターフェイス２５００が、コンテキストアナライザによってユーザの現在のコンテキストの決定に使用され得る、ユーザによって選択可能なコンテキスト指定を示す。ユーザの直接指定によるユーザコンテキストの決定、および／またはユーザによって修正可能なプロファイルが記述されている。ユーザのコンテキストは、ユーザの注目、つまり、ユーザが現在、通知警告を快く受け取るかどうか、ならびにユーザの現在の居場所を含み得る。ただし、本発明はそのように限定されない。
【０２５１】
ユーザによるコンテキストの直接指定は、ユーザが警告を受けることが可能かどうか、およびユーザが警告をどこで受けることを望むかを、ユーザが指示することを可能にする。デフォルトの注目状態、およびユーザが警告を受けることができるデフォルトの場所を指示するのに、デフォルトプロファイル（図示せず）が利用され得る。デフォルトプロファイルは、ユーザによって所望通りに修正され得る。
【０２５２】
図２５を参照すると、インターフェイス２５００は、本発明の態様に従って、コンテキストの直接指定がどのように実装され得るかを示す。ウィンドウ２５０２は、たとえば、注目セクション２５２０および場所セクション２５４０を有する。注目セクション２５２０において、ユーザは、たとえば、ユーザが常に警告を受けることができるかどうか、ユーザがいつでも警告を受けることができないかどうか、および、ユーザが所定の閾値より大きい重要度レベルを有する警告のみを受けることができるかどうかを示す、１つまたは複数のチェックボックス２５２２にチェックマークをつけることができる。他の可能性の選択も提供され得ることが理解されるべきである。図２５に示すように、閾値は、ドルで表され得るが、これは例示に過ぎず、本発明は、そのように限定されない。ユーザは、新しい値を直接入力することによって、または矢印２５２６により閾値を増減させることによって、ボックス２５２４で閾値を増加させることができる。
【０２５３】
場所セクション２５４０において、ユーザは、ユーザがどこで警告を伝えられることを望むかを指示するために、チェックボックス２５４２の１つまたは複数にチェックマークをつけることができる。たとえば、ユーザは、デスクトップで、ｅメールによって、ラップトップで、セル電話で、自分の車の中で、ページャで、または携帯情報端末（ＰＤＡ）デバイスなどで、警告を伝えさせることができる。ただし、これらは例に過ぎず、本発明自体はそのように限定されないことが理解されるべきである。
【０２５４】
ウィンドウ２５０２には、セクション２５２０のチェックボックス２５２２およびボックス２５２４ならびにセクション２５４０のチェックボックス２５４２に対する予め設定されたデフォルトがあってよく、ウィンドウ２５０２は、デフォルトのユーザプロファイルと見なされ得る。プロファイルは、ユーザが、デフォルトの選択を自分が望む選択でオーバーライドし得るという点で、ユーザによる修正が可能である。他のタイプのプロファイルも、本発明に従って使用され得る。
【０２５５】
今度は図２６を参照すると、本発明による、たとえば、１つまたは複数のセンサを使用する、直接測定によるユーザコンテキストの判定が示されている。ユーザのコンテキストは、ユーザの注目、ならびに自分の現在の居場所を含み得る。ただし、本発明自体はそのように限定されない。コンテキストの直接測定は、ユーザが現在、快く警告を受けるかどうかを検出し、ユーザが現在どこにいるかを検出するのに、センサ（群）が利用され得ることを示す。本発明の一態様によると、直接測定に関連する推論分析は、本説明の後のセクションで説明されるように、ユーザコンテキストを決定するのに使用され得る。
【０２５６】
図２６を参照すると、ユーザコンテキストの直接測定が達成され得るシステム２６００が示されている。システム２６００は、コンテキストアナライザ２６０２、ならびにアナライザ２６０２に通信可能に結合されている、いくつかのセンサ２６０４〜２６１６、すなわち、たとえばセル電話２６０４、ビデオカメラ２６０６、マイクロホン２６０８、キーボード２６１０、ＰＤＡ２６１２、車２６１４、およびＧＰＳ２６１６を含む。図２６に示されるセンサ２６０４〜２６１６は例示に過ぎず、本発明自体に対する限定も制限も表さない。本明細書で使用するセンサという用語は、かなり広範な包含的用語であり、ユーザの現在の注目が何であるか、および／またはユーザの現在の居場所が何であるかをコンテキストアナライザ２６０２が判定し得るための、どのデバイスも方式も意味する。
【０２５７】
たとえば、ユーザがセル電話２６０４をオンにしている場合、このことは、ユーザがセル電話２６０４で警告を受けることができることを示し得る。ただし、ユーザが、セル電話２６０４で通話中の場合、このことは、ユーザは、他のもの（すなわち、現在の通話）に自分の注意を向けているので、今は通知警告で妨害されるべきではないことを示し得る。ビデオカメラ２６０６が、たとえば、ユーザの職場にあって、ユーザが自分の職場にいるかどうか（すなわち、ユーザの居場所）、および、ミーティング中の場合は、ユーザは妨害されるべきでないと考えられるので、他の人がユーザの職場にいるかどうか（すなわち、ユーザの注目）を検出することができる。同様に、マイクロホン２６０８も、ユーザの職場にあって、ユーザは、他の誰かと会話していて、妨害されるべきでないかどうか、（たとえば、キーボードから発せられる音により）キーボードでタイプ入力していて、やはり今は妨害されるべきでないかどうかを検出することができる。キーボード２６１０も、ユーザが現在、キーボードでタイプ入力しているかどうかを判定するのに利用されることができ、そうすることによって、たとえば、ユーザが非常に速くタイプ入力している場合、このことは、ユーザは、コンピュータ関連活動に集中しており、過度に妨害されるべきでないことを示し得る（かつ、ユーザが実際に自分の職場にいることも示し得る）。
【０２５８】
ＰＤＡデバイス２６１２が、ユーザによってアクセスされている場合、このことは、ユーザがデバイス２６１２で警告を受け得ること、つまり、通知が伝えられるべき場所は、どこであろうともデバイス２６１２が置かれている場所であることを示し得る。デバイス２６１２は、ユーザの現在の注目を判定するのにも使用され得る。車２６１４は、ユーザが現在、車の中にいるかどうか、つまり、車が現在、ユーザによって運転されているかどうか判定するのに使用され得る。さらに、たとえば、ユーザの注目が何であるか判定するのに、車の速度が考慮され得る。たとえば速度が所定の速度を超えている場合、ユーザは、運転に集中しており、通知警告で煩わされるべきでないと判定され得る。ＧＰＳデバイス２６１６も、当該分野において公知であるように、ユーザの現在の居場所を確認するのに利用され得る。
【０２５９】
詳細な説明の以下のセクションにおいて、ユーザによって修正可能な規則によるユーザコンテキストの判定が記述される。ユーザのコンテキストは、ユーザの注目、ならびにユーザの現在の居場所を含み得る。ただし、本発明は、そのように限定されない。規則によるコンテキストの判定は、階層状の１組のｉｆ−ｔｈｅｎ規則が、ユーザの居場所および／または注目を判定するために従われ得ることを示す。
【０２６０】
図２７を参照すると、図２７は、階層状に順序づけられた、例示的な１組の規則２７００を示す。規則２７００の組は、たとえば規則２７０２、２７０４、２７０６、２７０８、２７１０、２７１２、および２７１４を示す。他の規則も同様に構成され得ることが留意されるべきである。図２７に示されるように、規則２７０４および２７０６は、２７０２に従属し、規則２７０６は、規則２７０４に従属し、規則２７１４は、規則２７１２に従属する。こうした規則は、規則２７０２が最初にテストされ、真であることがわかった場合、規則２７０４がテストされ、規則２７０４が真であることがわかった場合、規則２７０６がテストされ、以下同様に続くように順序づけられる。規則２７０４が偽であることがわかった場合、規則２７０８がテストされる。規則２７０２が偽であることがわかった場合、規則２７１０がテストされ、規則２７１０は、真であることがわかった場合、規則２７１２のテストを引き起こし、規則２７１２は、真であることがわかった場合、規則２７１４のテストを引き起こす。こうした規則は望ましくは、ユーザによって作成可能であり、かつ／または修正可能である。それ以外のタイプの規則も、（たとえば、ｉｆ−ｔｈｅｎ規則が偽であることがわかった場合、それ以外の規則が支配している）規則２７００の組に含まれ得る。
【０２６１】
したがって、１組の規則がユーザによって構築され得ることによって、ユーザのコンテキストが判定される。たとえば、場所に関して、規則の組は、その日が平日であるかどうかを第１の規則がテストするようなものでよい。平日の場合、第１の規則に従属する第２の規則が、現在時刻が午前９時から午後５時の間であるかどうかをテストする。その間の時刻である場合、第２の規則は、ユーザが自分の職場にいることを示し、その間の時刻でない場合は、ユーザが自宅にいることを示す。第１の規則が偽であること、つまり、その日は週末であって平日ではないことがわかった場合、それ以外の規則が、ユーザが自宅にいることを示し得る。この例は、本発明自体に対する制限的な例であることも限定的な例であることも意図されず、他の１つまたは複数の規則も同様に構成され得ることが留意されるべきである。
【０２６２】
本説明の以下のセクションにおいて、たとえば統計的および／またはベイズのモデルを利用した、推論分析によるユーザコンテキストの判定が記述される。推論分析によるコンテキスト判定は、説明されたように、いくつかの側面において、センサ（群）による直接測定など、他の判定に依拠し得ることが留意されるべきである。本明細書で使用する推論分析は、出力変数（群）、すなわちユーザの現在のコンテキストを生じるための、いくつかの入力変数に対する推論プロセス（群）の使用を指す。分析は、一側面において、統計モデルおよび／またはベイズのモデルの使用を含み得る。
【０２６３】
図２８を参照すると、本発明の態様に従って、ユーザのコンテキスト２８０４を判定するために、推論エンジン２８０２によって推論分析が実施されるシステム２８００の図が示されている。エンジン２８０２は、一側面では、コンピュータのプロセッサによって、メモリなどのコンピュータ可読媒体から実行されるコンピュータプログラムである。ユーザコンテキスト２８０４は、エンジン２８０２の出力変数と見なされ得る。
【０２６４】
エンジン２８０２は、１つまたは複数の入力変数を処理して、コンテキスト決定を行うことができる。このような入力変数は、本説明の先行セクションにおいて、コンテキスト決定のための直接測定手法に関連して述べられたセンサ（群）など、１つまたは複数のセンサ（群）２８０８、ならびに、たとえばユーザのスケジューリングもしくは個人情報マネージャ（ＰＩＭ）コンピュータプログラム中で、かつ／またはユーザのＰＤＡデバイス上でアクセスされ得る時計２８１０およびカレンダ２８１２で表される現在の日時を含み得る。図２８に示されているもの以外に、他の入力変数も考慮され得る。図２８の変数は、本発明自体に対する限定であることも制限であることも意図されない。
【０２６５】
ここで図２９および３０を参照すると、本発明による、上述した推論エンジンによって実行され得る例示的な推論モデル、たとえば統計的および／またはベイズのモデルによって提供される推論モデルが示されている。概して、コンピュータシステムは、ユーザの状態の詳細についてある程度不確実な場合がある。したがって、ユーザの注目または他の不確実な状態について推論を行うことができる確率的モデルが構築され得る。ベイズのモデルは、ユーザの注目対象に渡る確率分布を推論することができる。このような注目状態は、１組の原型的状況としても、ユーザによって対処される１組の異なるクラスの認知的課題のより抽象的な表現としても定式化され得る。あるいは、注目対象の連続測度について推論を行うモデル、および／または異なるタイプの通知のための割込みのコストに渡る確率分布を直接推論するモデルが定式化され得る。
【０２６６】
ユーザの活動および場所についての１組の観察に基づいて、代替活動コンテキストまたは状態の確率を推論することができるベイズのネットワークが利用され得る。一例として、図２９は、単一の期間、ユーザの注目対象を推論するベイズのネットワーク２９００を表す。注目対象２９２０という変数の状態は、デスクトップおよび非デスクトップコンテキストを指す。モデル中で考慮される例示的な注目コンテキストは、たとえば、状況認識、遡及、非特異的バックグラウンドタスク、注目されている内容生成または見直し、軽微な内容生成または見直し、ドキュメントのブラウジング、職場でのミーティング、職場外でのミーティング、プレゼンテーションの聴講、プライベートな時間、家族で過ごす時間、個人的な注目、気軽な会話、および旅行を含む。ベイズのネットワーク２９００は、ユーザの現在の注目および居場所が、ユーザの、スケジュールされた予定２９３０、時刻２９４０、および期限２９５０が迫っていることによって影響されることを示す。ユーザの注目に関する確率分布も、たとえば、ユーザの職場において監視される周囲の音響信号２９６０の状況の要約によって影響される。時間経過に伴う周囲の音響信号２９６０のセグメントは、活動および会話の存在についての手がかり／入力を与える。ソフトウェアアプリケーションの状況および構成ならびにコンピュータと対話しているユーザによって生成されたユーザ活動の継続中のストリームも、ユーザの注目についての証拠のソースを提供する。
【０２６７】
ネットワーク２９００に表されるように、現在、オペレーティングシステムまたは他の環境において最高レベルの注目を受けているソフトウェアアプリケーション２９７０は、ユーザの注目およびタスクの性質に影響し、ユーザの注目状況および注目されているアプリケーションは合同で、コンピュータを中心とする活動に影響する。このような活動は、マウスおよびキーボードアクションのシーケンスから構築されるユーザ活動のストリームならびにより広い計画対象時間に渡るより高度なパターンのアプリケーション使用を含む。このようなパターンは、ｅメールを中心とする、およびワードプロセッサを中心とするパターンを含み、複数のアプリケーションがインターリーブされる方法を伴う活動の原型クラスを参照する。
【０２６８】
図３０は、異なる期間での、コンテキスト変数の間の、ユーザの注目対象のベイズのモデル３０００を示す。１組のマルコフ時間依存が、モデル３０００によって示されており、コンテキスト変数の過去の状態が、現在のユーザの状態の判定において考慮される。リアルタイムで、このようなベイズのモデル３０００は、たとえば、オンラインカレンダによって与えられる情報、ならびに一連の室内音響およびイベント感知システム（図示せず）によって報告されたユーザ活動についての観察を考慮し、ユーザの注目の確率分布についての推論結果を提供し続ける。
【０２６９】
図３１および３２は、本発明によるコンテキストアナライザおよび通知エンジンなどの通知アーキテクチャの部分を提供する方法を示す。説明を簡単にするために、方法は、一連の作用として示され説明されるが、本発明は作用の順序によって限定されないことが理解されるべきである。というのは、いくつかの作用は、本発明に従って異なる順序で起こることもでき、かつ／または本明細書において示され説明される他の作用と同時に起こることもできるからである。たとえば、方法は、状態図でのように、相関する一連の状態またはイベントとしても表され得ることを当業者は理解するであろう。さらに、例示されるすべての作用が、本発明による方法の実装に必要とされ得るわけではない。
【０２７０】
図３１を参照すると、フローチャート３１００は、本発明によるユーザのコンテキストの決定を示す。プロセスは、３１０２でのユーザの居場所、および３１０４でのユーザの注目の判定を含む。こうした作用は、前述された手法の１つまたは複数によって遂行され得る。たとえば、プロファイルが利用されることができ、ユーザが自分のコンテキストを指定することができ、コンテキストの直接測定が使用されることができ、１組の規則が従われることができ、ベイズのモデルや統計モデルなどによる推論分析も実施されることができる。ユーザのコンテキストを決定するのに、他の分析も利用され得ることが理解されるべきである。たとえば、誰かがコンピュータの前にいるかどうか、その人がコンピュータを見ているかどうかに気づく一体型ビデオカメラソースが存在し得る。ただし、システムは、カメラがあってもなくても動作し得ることが留意されるべきである。ソースすべてに対して、システムは、コンテキストについての推論のために特定のいかなるソースも要求することなく、利用可能な実質的にどの入力ソースとでも動作し得る。さらに、他の側面では、一体化された加速度計、マイクロホン、およびユーザの居場所および注目を感知する、小型ＰＤＡの近接検出器が存在し得る。
【０２７１】
ここで図３２を参照すると、フローチャート３２００は、本発明の態様による、通知エンジン用の決定プロセスを示す。３２０２で、１つまたは複数の通知ソースが通知を生成し、こうした通知は、通知エンジンによって受け取られる。３２０４で、コンテキストアナライザが、ユーザに関するコンテキスト情報を生成し／判定し、この情報は、３２０６で、通知エンジンによって受け取られる。つまり、本発明の一態様によると、３２０４で、コンテキストアナライザは、本説明の先行セクションで説明されたように、ユーザの現在の注目状況および居場所を示し、かつ／あるいは１つまたは複数のコンテキスト情報ソースから、ユーザの現在の注目状況および居場所に関するリアルタイムの情報を査定するユーザコンテキスト情報プロファイルにアクセスする。３２０８で、通知エンジンは、コンテキストアナライザから受け取られるコンテキスト情報に部分的に基づいて、通知のどれを、通知シンクのどれに伝えるか決定する。通知エンジンは、コンテキストアナライザによって格納されている、ユーザの通知パラメータに関する情報にも基づいて、判定を行う。つまり、一態様によると、３２０８で、エンジンは、ユーザが、与えられた通知を警告されるべきかどうか、およびどのようにしてユーザが通知されるべきかに関して、決定論的分析を実施する。後でより詳しく説明されるように、決定論的ならびに／または発見的分析、判定、およびポリシーが、３２０８で利用され得る。ユーザに関する通知パラメータは、欠けている値を埋めることによって、またはソースもしくはシンクのスキーマにおいて与えられたパラメータを上書きすることによって、分析を個別設定するのに使用され得る。通知プレファレンスは、決定論的分析の代わりに利用される（たとえば、発見的）ポリシーを与えることもできる。この判定に基づいて、通知エンジンは、３２１０で、ディストリビュータに通知を伝える。
【０２７２】
（データ駆動型アプリケーションのインストール）
本発明の別の態様によると、情報エージェントアプリケーションのインストールは、予め定義されたテーブルをアップデートすることによって遂行され得る。従来の通知システムならびに他のアプリケーションは通常、インストールされるとき、データベースオブジェクトの急増を伴う。すべてのアプリケーションは従来、インストールプロセス中に、プロシージャならびに複数のテーブルおよびデータベースを格納しなければならなかった。しかし、本発明は、異なる手法をとる。最初に、情報エージェントシステム１００などのシステムまたはプラットフォームがインストールされると、基本の１組のテーブルが作成され得る。したがって、アプリケーションのインストールは、既存のテーブルへのデータの挿入のみを伴う。この手法は、インストールされるアプリケーションの数が増加すると、データベースオブジェクトの急増を解消し、拡張性を可能にする（後で論じられる）。
【０２７３】
上記のことを遂行するために、イベント、プレファレンス、およびプロシージャはすべて、データとして格納され得る。この格納は、システムが、データベースエンジンの向上し続ける処理能力、および情報エージェントアプリケーション３００（図３）など、複数のアプリケーションを実行するためのクエリを利用することを可能にする。上述されたように、プレファレンスは、エンドユーザによって定義され、次いで、テーブルおよびデータベース中の高度なデータフィールドに抽象化されることができる。イベントは、捕捉され、または取得され、次いで、データベースに格納されることができる。クエリ評価プロシージャなど、従来のストアドプロシージャも、プロシージャを作成するとともに１つまたは複数のデータベーステーブルにテキストを送り込むことによって、データとして表され得る。その後、プロシージャが実行されることになると、プロシージャを表すテキスト文字列が、データベーステーブルから引き出され、データベース中で動的に評価されることができる。この手法は、アプリケーションによって作成されることが必要とされるストアドプロシージャの数を劇的に削減し、ＤＭＬ（データ操作言語）データ駆動動作に過ぎない、アプリケーションのインストールを行う。
【０２７４】
（構成可能性および拡張性）
このセクションは、情報エージェントアプリケーションが初期作成時にどのように構成され、後でどのように拡張され得るかを説明する。情報エージェントアプリケーション（ＩＡアプリケーション）は、何らかの基底システムまたはアプリケーションドメインを有するイベント−条件−アクション（ＥＣＡ）モデルを介してエンドユーザが対話を行うことを可能にするように設計される。より具体的には、情報エージェントアプリケーションは、特に、ユーザコンテキストに対する感度が重要である、情報の経路指定、フィルタリング、および処理を扱う問題ドメインに他のアプリケーション機能がどのように適用されるかを制御するプレファレンスをユーザが指定し得ることを可能にするように設計される。これに基づいて、情報エージェントアプリケーションの構成可能性および拡張性は、基底システムまたはアプリケーションドメインを構成し、または拡張することに向けられるのではなく、プレファレンスを効果的に作成する（新しいＥＣＡの開始）ためのユーザの能力をターゲットとすると理解されるべきである。
【０２７５】
新しいアプリケーション、コンポーネント、またはシステムモデルを作成すること（作成は可能であり、本発明の範囲内と見なされるべきであるが）は、情報エージェントアプリケーションの構成可能性および拡張性の目標ではない。そうではなく、目標は、ＥＣＡモデルを介してユーザにプレファレンス論理を指定させる、システムの層またはコンポーネント（たとえば、決定論理コンポーネント３３０）への動的拡張を可能にすることである。具体的には、所与のアプリケーションがインストールされたときに続いて、新しい条件およびアクション（ＥＣＡのＣＡ部）をエンドユーザに使用可能にさせることが目標である。さらに、イベント（ＥＣＡのＥ部）も、同様にして動的に拡張され得ることも理解されるべきである。
【０２７６】
本発明の一態様によると、情報エージェントアプリケーションは、プレファレンスを定義するための独自のユーザインターフェイスをもたず、オペレーティングシステムインターフェイスまたはアプリケーション特有のユーザインターフェイスのいずれかを、プレファレンスの作成に使用する。このコンテキストにおいて、情報エージェントアプリケーションの構成可能性および拡張性は、既存のユーザインターフェイスがその後、新しい条件およびアクションを有する新しいプレファレンスをユーザに作成させ得るような方法で、新しい条件およびアクションを追加するように設計される。この点に関して、ＩＡアプリケーションは、このような新しい条件およびアクションの反映をサポートすることができ、そうすることによって、このような新しい機能のシグニチャが、拡張によって与えられる記述に沿って適切に表示されて、いつ、どのようにして新しい条件およびアクションを適切に使用するかに関して、エンドユーザにコンテキストを提供し得る。
【０２７７】
様々なコンテキストにおいて、かつ様々なときに、情報エージェントアプリケーションに対して多様性が存在する。特に、ＩＡアプリケーションが自給し独立し得る間、多くのＩＡアプリケーションが、実際に対話し、他のＩＡアプリケーションによって提供される機能を利用する。具体的には、あるアプリケーションによって定義される条件およびアクション関数は、他のアプリケーションによっても使われ得る。ＩＡエージェントは、他のいくつかの方法で、別のＩＡエージェントとも対話することができる。たとえば、あるＩＡアプリケーションにおけるプレファレンス評価が、別のＩＡアプリケーションに提出されるイベントを作成するアクションをトリガし得る。
【０２７８】
構成可能性と拡張性との区別は、情報エージェントアプリケーションのコレクションがどのようにして対話し発達するかを理解するのに重要である。構成可能性とは、既存であるとともにアプリケーションが最初に作成されるときに他の情報エージェントアプリケーションによって提供される機能に積み重なる新しい情報エージェントアプリケーションが作成されるときに用いられる概念である。拡張性は、アプリケーションが作成され、またはインストールされた後に生じられた新しい機能で、既存の情報エージェントアプリケーションが拡張されるための概念およびプロセスを指す。さらに、構成可能性および拡張性両方をサポートするのに、共通の１組の機構が用いられるので、構成可能性および拡張性という、ある程度異なる目的を達成するために、このような共通の機構がどのように用いられるかにおける些細な違いを理解することが重要である。ＩＡアプリケーションの構成可能性という概念は、単一のＩＡアプリケーションが１組の個々の部分から構築されるプロセスにも適用可能である。構成可能性のこの側面は、ＩＡアプリケーションをモジュール方式で開発するというソフトウェアエンジニアリング目標に対処する。ＩＡアプリケーションシステムに導入されつつある拡張性概念は、従来の拡張性概念と調和する。すなわち、ＩＡアプリケーションの元の定義に続いて、新しい機能が追加され、この追加が、アプリケーションの機能を高める。
【０２７９】
ＩＡアプリケーションの測度は、かなりの程度まで、ユーザに提示される機能によって決定される。したがって、ＩＡアプリケーションが拡張可能である程度は、新しい条件およびアクションが、既存のアプリケーションのコンテキストにおいて新しいプレファレンスを定義するユーザに対して使用可能にされる程度によって決定され得る。ＩＡアプリケーションの拡張性は、アプリケーションがインストールされるときに続いて、元のアプリケーションの作者（達）によるそれ以上の介入なしで、新しい条件およびアクションがアプリケーションに追加されることを可能にすることを主に目指している。これがどのように行われるかを理解するには、アクションまたは条件関数の定義が、最終的に情報エージェントアプリケーションのエンドユーザに対してアクセス可能になるための進化的チェーンを強調することが重要である。
【０２８０】
図３３に移ると、本発明の態様による条件／アクションの進化的チェーン３３００が示されている。条件およびアクションは、３３１０で、条件またはアクション関数として始まる。この関数指示は、たとえば、ＳＱＬ呼出し可能関数／ストアドプロシージャの定義の正式なシグニチャを参照するときに使われ得る。新しい条件またはアクション関数が定義されてから、関数が、対応する条件またはアクションの宣言によって既存のアプリケーションにバインドされるまでの間、関数は、候補関数であると見なされる。候補関数の開発者は、３３２０で、拡張される目標アプリケーションに、候補条件またはアクションと呼ばれる候補関数から条件またはアクションを作成させるバインディングを指定する。この段階で、条件またはアクションは、既存の被拡張アプリケーションが使うための候補であり、したがって、アプリケーションは、条件またはアクションを使うことができるが、こうした条件またはアクションを受諾することは要求されない。拡張されるアプリケーションにおける受諾論理は、たとえば、提案された拡張／バインディングに誰が署名したかに基づいて、このようなバインディングが受諾されるかどうか判定する。アプリケーションが、そのプレファレンスクラスを条件または論理関数候補にバインドすると、条件またはアクションは、３３３０で、単に条件またはアクションとなる。最後に、エンドユーザが、新しく定義されたプレファレンスのコンテキストにおいて条件またはアクションを使用すると、そのアクションまたは条件は、３３４０で、チェーンに示されているように、インスタンス化されると言われる。
【０２８１】
図３４は、本発明の態様によるアプリケーション対話用システム３４００を示す。システム３４００は、インスタンスレジストリコンポーネント３４１０、定義レジストリ３４１２、バインディングレジストリ３４１４、アプリケーションＡ３４３０、アプリケーションＢ３４４０、バインディング３４５５、および拡張コンポーネント３４２０を備える。拡張性の一実装形態において、展開単位は、アプリケーションまたは拡張である。インスタンスは、アプリケーションまたはアプリケーションデータファイル（ＡＤＦ）を追加することによって拡張される。ＡＤＦは、単一のアプリケーションが展開中であるときに使うために、開発者によって作成され得る。ＡＤＦは概して、アプリケーションの中心論理を定義し、なかでも、通知などのイベント、条件、およびアクション用のスキーマを含み得る。アプリケーションは、拡張または拡張データファイル（ＥＤＦ）を追加することによって拡張され得る。ＥＤＦは、誰によっても作成されることができ、インスタンスおよびアプリケーションが作成された後（アプリケーションの初期インストールを含む）、いつでも使用される。
【０２８２】
アプリケーションは、機能を共有するために、互いに気づいている必要がある。本発明の態様によると、このことは、関数、および関数がどのようにアプリケーションにバインドされるかについての情報を格納するための定義レジストリ３４１２およびバインディングレジストリ３４１４からなるインスタンスレジストリ３４１０を使用することによって遂行され得る。インスタンスレジストリ３４１０は、アプリケーションがデータを格納するための共有場所を提供する。インスタンスレジストリ３４１０は、定義レジストリ３４１２およびバインディングレジストリ３４１４を含む。
【０２８３】
定義レジストリ３４１２は、アプリケーション関数に関する情報を格納する。本発明の態様によると、アプリケーション（たとえば、ＩＡアプリケーション）によって使用されるアプリケーション関数は、定義レジストリ３４１２に登録され、または格納されることができる。定義レジストリ３４１２への関数の登録は、関数を、システム上で実行される全アプリケーションに対してパブリックにさせる。したがって、アプリケーションによって使用される関数は、完全にプライベートになって、定義レジストリに定義されないか、またはパブリックになって、定義レジストリに登録されるとともに他の全アプリケーションにとってアクセス可能となる。これは、定義レジストリを実装する一方式に過ぎないことが留意されるべきである。別の実装形態機構は、関数がパブリックであるか、それともプライベートであるかを信号で通知するインジケータを格納するものでよい。定義レジストリに組み込まれ得る、例示的な一部の情報は、次のものを含む。
【０２８４】
【表３１】
2007509416.tif 000037
【０２８５】
バインディングレジストリ３４１４は、すべてのバインディング、条件、アクション、および複数のアプリケーションから関数へのアクセス機構を格納することができる。このことは、そうした関数が、初期定義から派生するか、それともアプリケーションへの後の拡張から派生するかに関わらず、当てはまり得る。さらに、本発明の態様によると、パブリック関数は、バインディングメタデータなしでは使用可能でないことが留意されるべきである。バインディングメタデータは、パブリック関数がどのようにアプリケーションデータのイベントデータにバインドされるかを指定する情報である。バインディングレジストリ３４１４へのパブリック関数の登録は、関数をアプリケーションにバインドする。このバインディングは、１対多の関係であり、１つの関数が、異なる多くのアプリケーションにバインドされ得る。
【０２８６】
バインディングレジストリ３４１４に登録されているバインディングは、いくつかの状況を有し得る。たとえば、バインディングは、候補バインディングでよい。候補バインディングは、関数の定義子によって作成され、他のアプリケーションに対して使用可能にされている。バインディングは、特有のアプリケーションが所与の条件またはアクション関数にどのようにバインドするかを表す、バインディングが所与のアプリケーションに特有であることを示す、バインドされている関数の状況も有し得る。さらに、バインディングは、「受諾不可」という状況を有し得る。こうしたバインディングは、特有のアプリケーションにおいて目標であったが、目標アプリケーションの受諾論理によって受諾されなかった候補関数である。受諾論理は、ＡＤＦにおいて宣言されることができ、なかでも、ＥＤＦソースが、（たとえば、デジタル署名を用いて）認証され、（たとえば、信頼できるソースのリストから）認可され、証明される（ＥＤＦが、信頼できるソースによって署名されている）ことを保証するコンポーネントを含み得る。バインディングレジストリ３４１４に収容され得るそれ以外の情報は、次のものを含むが、それに限定されない。
【０２８７】
【表３２】
2007509416.tif 000038
【０２８８】
拡張コンポーネント３４２０は、候補関数に基づいて、条件およびアクションを作成する。拡張コンポーネント３４２０は、候補関数をアプリケーションにバインドするために、インストール時に、インストールスクリプトによってコールされ得る。新しい候補関数エントリが、バインディングレジストリ３４１４中に作られる場合、目標アプリケーションの一部においてとられるアクションまたはアクションの欠如に応じて、いくつかのことが起こり得る。たとえば、目標アプリケーションがインストールされない場合、エントリは無視され得る。目標アプリケーションがインストールされるが、拡張を受諾しないように構成される場合、やはりエントリは無視され得る。しかし、目標アプリケーションがインストールされ、候補関数を受諾する場合、新しい条件、アクション、またはアクセス機構のバインディングが、アプリケーション用に作成され、拡張コンポーネント３４２０を使用するアプリケーションにバインドされる。したがって、システム３４００において、アプリケーションＡ３４３０は、アプリケーションＢ３４４０に対して使用可能にすることを望むローカル関数「ＣｏｎｄｉｔｉｏｎＦｕｎｃｘ」を含む。この関数は、拡張データファイル（ＥＤＦ）を追加することによって、アプリケーションＢ３４４０に対して使用可能にされ得る。その後、この関数は、アプリケーションＢ３４４０に対して関数を使用可能にするように、インスタンスレジストリ３４１０に格納される。たとえば、ＣｏｎｄｉｔｉｏｎＦｕｎｃＸは、定義レジストリ３４１２に登録されることができ、候補関数は、バインディングレジストリ３４１４に格納されることができる。拡張コンポーネント３４２０は次いで、バインディングレジストリ３４１４から候補関数を読み出すことができ、条件ＡをアプリケーションＢ３４４０にバインドすることによって、条件Ａを作成することができる。したがって、条件ＡをアプリケーションＡのｃｏｎｄｉｔｉｏｎＦｕｎｃＸにバインドするバインディング３４５０が作成される。
【０２８９】
バインディングまたは依存が確立されると、バインディングまたは依存は、複数の方法で破壊され得ることが留意されるべきである。たとえば、アプリケーションによって実装された関数は、アプリケーションがアンインストールされた場合、使用不可能となり得る（すなわち、依存が破壊される）。依存が破壊され得る方法の別の例は、新しいアプリケーションが、新しい条件、アクション、またはアクセス機構でインストールされた場合、アプリケーションは、もはや使用可能でない関数にバインドされることである。さらに、アプリケーションが、すべてまたは特定の拡張を受諾しないように再構成された場合、依存は破壊され得る。したがって、既存のプレファレンスは、もはや使用可能でない条件、アクション、またはアクセス機構への依存を有する場合がある。破壊された依存は、複数の方法で補償され得る。本発明の態様によると、使用不可能な状態が定義され得る。たとえば、アプリケーションが、許容されることになったとしても、許容される前に、依存を破壊するために、依存プレファレンスを「ＮｏｔＡｖａｉｌａｂｌｅ」状態に置くことができるように、他のすべてのアプリケーションが通知され得る。その後、アプリケーションがインストールされると常に、システムまたはアプリケーションは、使用不可能な状態が、使用可能に変えられることができるとともにプレファレンスが使用されることができるように、依存が再構築されているかどうかを調べることができる。
【０２９０】
プレファレンスは、情報エージェントアプリケーションの間で作成され得る。プレファレンスのインスタンス化は、ＩＡアプリケーションの間の対話が達成され得るための方法を表す。本発明の態様によると、複数のＩＡアプリケーションにおいて機能にアクセスするプレファレンスをユーザが作成することを可能にする、少なくとも２つの機構が提供され得る。１つの機構が、ＥＤＦバインディングである。アプリケーション開発者は、他のアプリケーションにおいて定義される条件およびアクションを、あるアプリケーションにおけるプレファレンスクラスが参照することを可能にするためのＥＤＦバインディングを作成することができる。このバインディング作成は、複数のアプリケーションから条件およびアクションを参照するプレファレンスをエンドユーザがインスタンス化することを可能にする。イベント提出アクションは、複数のアプリケーションによって提供される機能も利用する。イベントクラスがアプリケーションによって定義されると、イベント提出アクション関数が暗黙的に作成され得る。その後、こうしたイベント提出アクション関数は、ＥＤＦにより、他のアプリケーションによって使われるアクションにバインドされることができ、そうすることによって、新しく作成されたユーザプレファレンスの潜在機能を豊かにする。
【０２９１】
追加機構またはコンポーネントが、アプリケーションがプレファレンスを、エンドユーザとは対照的にアプリケーション開発者によって指定されたように直接インスタンス化することを可能にする目的で必要とされ得る。１つの機構またはコンポーネントが、複数のプレファレンステンプレートに対応し得る。プレファレンステンプレートは、プレファレンスクラスのコンテキストにおいて定義されることができ、１組の条件およびクラスを含む。プレファレンスクラスのシンタクスは、テンプレートを定義する目的で、新規タグで拡張され得る。続いて、このタグは、アプリケーションを新しいテンプレートで拡張する目的で、ＥＤＦによって使われ得る。プレファレンスのインスタンス化アクションも利用され得る。新しいプレファレンステンプレートが作成されると、指定されたテンプレートからプレファレンスをインスタンス化するために、アクション関数が暗黙的に作成され得る。そのアクション関数へのパラメータは、テンプレートの、条件アクションの固定された組からプレファレンスをインスタンス化するのに必要とされる定数を表す。
【０２９２】
開発者は、エンドユーザによる明示的介入なしで、アプリケーションの内部において、かつ複数のアプリケーションに渡って、プレファレンスをインスタンス化することもできる。この機能を遂行するのに、いくつかの機構が利用され得る。たとえば、アプリケーション定義時にＡＤＦにおいてプレファレンスを直接インスタンス化させるために、新しいＡＤＦタグがプレファレンスクラスに追加され得る。あるいは、新しいＥＤＦタグがプレファレンスクラスに追加され得る。このことは、アプリケーションが定義される間、かつその後にプレファレンスをインスタンス化させることになる。さらに、プレファレンスのインスタンス化は、スキーマ定義外のスクリプト（たとえば、ＳＱＬスクリプト）により、たとえばシステムＡＰＩの使用により遂行され得る。
【０２９３】
上述した機能を用いると、あるアプリケーションがイベントを送り、条件／アクションを評価し、または他のアプリケーションにおいてプレファレンスをインスタンス化するとき、アプリケーション（たとえば、ＩＡアプリケーション）対話が起こり得る。このような対話は、直接開発者によっても、エンドユーザ定義プレファレンスを介しても遂行され得る。
【０２９４】
アプリケーションの構成可能性および拡張性の様々な側面をさらに理解するために、これ以降、いくつかの例が与えられる。ＳｈｅｌｌＡｐｐは、オペレーティングシステムの情報エージェントアプリケーションである。Ｏｆｆｉｃｅも、情報エージェントアプリケーションである。
【０２９５】
（例１：合成）
合成は、新しいアプリケーションが、既存の既知の関数にバインドするようにオーサリングされるときに定義され得る。この例において、ＳｈｅｌｌＡｐｐが最初にインストールされ、Ｏｆｆｉｃｅがその後にインストールされる。Ｏｆｆｉｃｅがオーサリングされたとき、開発者は、Ｏｆｆｉｃｅアプリケーションについて知っており、ＳｈｅｌｌＡｐｐのＦｕｎｃＸ条件関数を利用するように設計した。Ｏｆｆｉｃｅは、インストールされると、ＦｕｎｃＸ条件関数（古い関数）をＯｆｆｉｃｅアプリケーション（新しいアプリケーション）での条件にバインドするバインディングを、バインディングレジストリに登録する。Ｏｆｆｉｃｅアプリケーションのインストールスクリプトは次いで、バインディングレジストリから読出しを行う拡張コンポーネントをコールする。拡張コンポーネントは次いで、定義済みの（「組み込まれている」）条件があることを検出し、したがって、次のステップにスキップすることができ、このステップで、インスタンス全体に渡るＮｏｔＡｖａｉｌａｂｌｅ状態を再度評価する。Ｏｆｆｉｃｅアプリケーションは、ＳｈｅｌｌＡｐｐによって拡張されると言われる。
【０２９６】
（例２：拡張）
拡張は、古いアプリケーションが新しい関数で拡張されるとき、定義され得る。この例において、上記のように、ＳｈｅｌｌＡｐｐがインストールされ、次いで、Ｏｆｆｉｃｅがインストールされる。Ｏｆｆｉｃｅがオーサリングされたとき、開発者は、ＳｈｅｌｌＡｐｐにおいて使われ得るアクション関数ＦｕｎｃＹを作成した。Ｏｆｆｉｃｅは、インストールされると、定義レジストリにアクション関数を登録し、ＯｆｆｉｃｅアプリケーションのＦｕｎｃＹ（新しい関数）をＳｈｅｌｌＡｐｐ（古いアプリケーション）でのアクションにバインドするバインディングをバインディングレジストリに登録する。Ｏｆｆｉｃｅアプリケーションスクリプトは、拡張コンポーネントをコールして、ＳｈｅｌｌＡｐｐにおいて対応するアクションをもたない新しいバインディングがあることを検出し、したがって、ＳｈｅｌｌＡｐｐ中でそのアクションを作成することによって、アクションを内在化する。スクリプトは次いで、インスタンス全体に渡るＮｏｔＡｖａｉｌａｂｌｅ状態を再度評価する。ＳｈｅｌｌＡｐｐは、Ｏｆｆｉｃｅアプリケーションで拡張されていると言われる。
【０２９７】
（例３：パッチ拡張）
パッチは、関数およびアプリケーションが両方とも、既にシステム上でインストールされていると起こり得る。したがって、ＳｈｅｌｌＡｐｐおよびＯｆｆｉｃｅが両方ともシステム上でインストールされていると仮定すると、オフィスサービスパックがインストールされている。Ｏｆｆｉｃｅアプリケーションの解放後、開発者は、ＳｈｅｌｌＡｐｐが使うことができるアクション関数がＯｆｆｉｃｅにあることを認識する。サービスパックは、なかでも、新しいＯｆｆｉｃｅアプリケーション条件をＯｆｆｉｃｅアプリケーションでの条件関数にバインドするバインディングを定義するＥＤＦを含む。サービスパックは、インストールされると、バインディングをバインディングレジストリに登録し、拡張コンポーネントをコールすることができる。拡張コンポーネントは、目標アプリケーションにおいて対応するアクションも条件ももたない新しいバインディングを検出し、その後、ＳｈｅｌｌＡｐｐおよびＯｆｆｉｃｅアプリケーションにおいて新しいバインディングを作成することができる。次いで、拡張コンポーネントは、インスタンス全体に渡るＮｏｔａｖａｉｌａｂｌｅ状態を再度評価することができる。ＳｈｅｌｌＡｐｐは次いで、Ｏｆｆｉｃｅアプリケーションによって拡張されていると言われることができ、Ｏｆｆｉｃｅは、ＳｈｅｌｌＡｐｐによって拡張されていると言われることができる。
【０２９８】
（例４：アンインストール）
以前インストールされたＯｆｆｉｃｅアプリケーションが、アンインストールされていると仮定すると、アンインストールのプロセス中に、Ｏｆｆｉｃｅアプリケーションは、その登録内容をすべて、定義およびバインディングレジストリから削除する。ＳｈｅｌｌＡｐｐはこの時点で、Ｏｆｆｉｃｅによって実装された、今削除される関数に依存するアクションを有し得る。したがって、破壊された依存を有する全アクションに対して、使用不可能、すなわちＮｏｔＡｖａｉｌａｂｌｅ状態が宣言され得る。エンドユーザは次いで、失われた依存についての合図を受け取ることができる。エンドユーザは次いで、（たとえば、Ｏｆｆｉｃｅがいずれ復活した場合）使用不可能なプレファレンスまたはアクションを保つことを選ぶことも、そうしたプレファレンスまたはアクションを単に消去することもできる。
【０２９９】
（例５：再インストール）
以前アンインストールされた、Ｏｆｆｉｃｅのアプリケーションがここで再インストールされると仮定すると、インストール中に、アプリケーションは、そのアクション関数およびバインディングをＳｈｅｌｌＡｐｐに再登録する。Ｏｆｆｉｃｅインストールスクリプトは次いで、拡張コンポーネントをコールして、ＳｈｅｌｌＡｐｐにおいてアクションを作成することができる。ただし、拡張コンポーネントは、条件、アクション、またはアクセス機構が目標アプリケーション中に既に存在する（たとえば、アプリケーションが以前インストールされた）かどうかを単に検出し、作成ステップをスキップすることができる。関数のＮｏｔａｖａｉｌａｂｌｅ状態は次いで、アクティブになり得る全関数が、使用可能状態に確実に置かれるようにするために、再度評価され得る。
【０３００】
（個別設定フォルダ）
上述され説明されたシステムは、情報アプリケーションの構成を容易にし、こうしたアプリケーションは、所与の１組のイベントに対する決定およびアクション処理を自動化する。したがって、エンドユーザがデスクトップ通知およびｅメールの到着を含むが、それに限定されないイベントへの応答を個別設定することを可能にするアプリケーションが構築され得る。このような１つのアプリケーションが、これ以降で記述される個別設定フォルダアプリケーションである。本発明は、このような機能を、なかでも、体系化されたデータストアおよび体系化された論理を使用することによって、個別設定されたイベント処理として可能にする。
【０３０１】
図３５に移ると、本発明の態様による、個別設定されたシステム３５００が示されている。システム３５００は、データストア１５０と、個別設定フォルダ（群）３５１０およびプレファレンス３５１２を含む情報エージェントアプリケーション３００とを備える。個別設定フォルダ（群）３５１０は、エンドユーザによって直観的に指定され得る条件つき表現に基づいて、項目を含むことも除外することもできるフォルダまたはデータコンテナを指す。一例では、フォルダ（群）３５１０は、階層状に配列され、オペレーティングシステムのコンポーネントによって実装されることができる。ただし、フォルダまたはデータコンテナという用語の使用は、限定的な意味を意図しないことが留意されるべきである。フォルダ（群）３５１０は、１組の関係によって定義されるリンク、ポインタ、またはデータのどのコレクションにも拡張し得る。情報エージェントプレファレンス３５１２は、技術者でないエンドユーザが、（たとえば、データストア１５０を介して）体系化された論理および体系化されたデータを組み合わせて、豊富な個別設定されたアプリケーションおよび環境を提供するための能力を表す。対照的に、従来のプレファレンスは、文字列定数が与えられる、直観的名称をもつ単純な条件を使用するだけである。プレファレンス３５１２は、たとえば「Ｏｎ  ｅｖｅｎｔ  ＩＦ  ｃｏｎｄｉｔｉｏｎｓ  ＴＨＥＮ  ａｃｔｉｏｎｓ」や、よりアプリケーション特有の用語では、「Ｏｎ  ｆｏｌｄｅｒ  ｅｖｅｎｔ  ＩＦ  ｃｏｎｄｉｔｉｏｎｓ  ＴＨＥＮ  ｉｎｃｌｕｄｅ／ｅｘｃｌｕｄｅ  ａｃｔｉｏｎｓ」など、ユーザにとってわかりやすい論理を用いて、エンドユーザによって指定され得る。さらに、プレファレンス３５１２は、ユーザ操作に基づいてユーザプレファレンスを学習するのに、統計的および／またはベイズのモデルを利用するなどして、推論分析によって開発され得ることが留意されるべきである。本明細書で使用する推論分析は、出力変数（群）、すなわち、プレファレンス開発ツールへのユーザプレファレンスまたは入力をもたらすための、いくつかの入力変数に対する推論プロセス（群）の使用を指す。分析は、一側面では、統計モデルおよび／またはベイズのモデルの使用を含み得るが、それに限定されない。条件およびアクションに加えて、プレファレンスは、プレファレンスの評価を開始するトリガを含む。本発明の一態様によると、このようなトリガは、明示的なユーザ指示、時間でスケジュールされるトリガ、および／またはドキュメントを追加し、ドキュメントを消去し、かつ／もしくはフォルダ中のドキュメントを修正すると自動的に行われるトリガを含み得る。さらに、プレファレンス３５１２は、複雑すぎて、単一表現（たとえば、特定の項目をフォルダに含む／除外する、複数のクエリの影響を複合する）を介して容易に作成することができない結果セットを達成するようにグループ化され得ることが理解されるべきである。さらに、個別およびグループプレファレンス３５１２は両方とも、ユーザがフォルダ３５１０の間でプレファレンスをドラッグし、ドロップし、カットし、ペーストすることができるように、物理エンティティとして明示され得ることが留意されるべきである。フォルダ３５１０は、データのコピー、または単に記憶デバイス（別名仮想フォルダ）に格納されているデータへのポインタを含み得る。格納されているデータは、単語処理ドキュメント、スプレッドシート、画像、および音楽を含み得るが、それに限定されない。さらに、個別設定フォルダ３５１０は、異なる複数のドメイン内の項目に関連する、関連づけられたプレファレンス３５１２を有することができる。このような機能をサポートするために、予め定義された定数が導入され得る。より具体的には、１つの項目ドメインからの予め定義された定数（たとえば、ＭｙＧｒａｎｄｐａｒｅｎｔ）は、他のドメインからの条件への引数（たとえば、Ｐｈｏｔｏｓｆｒｏｍ（ＭｙＧｒａｎｄｐａｒｅｎｔ））として使われ得る。予め定義された条件および定数の複合は、エンドユーザが様々な項目ドメインを関係づけるための、容易で、直観的な方法をもたらす。当然ながら、ユーザが定義した定数も、個別設定フォルダの条件に与えられ得る。単純な条件は、項目ドメイン用のスキーマから推論され得る。たとえば、条件ＥｍａｉｌＩｓＦｒｏｍ（）またはＳｕｂｊｅｃｔＣｏｎｔａｉｎｓ（）は、ｅメールスキーマから推論され得る。ただし、スキーマ開発者は、有用な条件からなる、より豊富であるとともにより最小である組を特に明示的に指定することができる。さらに、新しい条件は、アプリケーション３００に追加され（拡張性）、続いて、新しいプレファレンスを定義するエンドユーザによって使用され得ることも留意されるべきである。新しいスキーマがインストールされると、フォルダを個別設定する新しい機能が可能になる。
【０３０２】
フォルダ３５１０は、本発明の態様によると、アクティブまたは派生として分類され得る。アクティブフォルダは、フォルダ中で興味のあること（たとえば、ファイルドキュメントが追加され、消去され、または修正されるイベント）が起こると、ユーザに代わってアクションをとる。たとえば、画像が、デジタルカメラから、ＭｙＰｉｃｔｕｒｅｓと呼ばれるアクティブフォルダにダウンロードされ得る。同時に、またはその後短時間のうちに、アクティブフォルダは、カレンダアプリケーションに問い合わせて、画像が撮られたときにユーザが何をしていたか判定し、次いで、適切なタイトル（たとえば、釣り）を有する新しいフォルダを作成し、新しいフォルダに画像を移動することができる。ｅメールコンテキストにおいて、ｅメールアプリケーションは、メッセージが経費報告を含むときを判定することができ、経費報告が一定の値を下回る場合、承認済み経費報告フォルダに報告書を移動することができる。アクティブフォルダのさらに別の例示的な使用においては、音楽が、アクティブフォルダにダウンロードされることができ、アクティブフォルダは次いで、音楽のジャンル（たとえば、ジャズ、クラシック、ラップ、ロックなど）を決定し、適切なフォルダに音楽を移動する。
【０３０３】
派生フォルダは、特定のファイルをフォルダに含めるか、それとも除外するか決定するのに、プレファレンスを使用する。さらに、派生フォルダは、ファイルへのマッピングまたはポインタを提供する仮想フォルダでよいことが留意されるべきである。仮想フォルダは、データを収容する実フォルダとして作用するが、フォルダは、実際の物理的存在をもっていない。派生フォルダの使用の一例は、ユーザによって最近２週間の間に少なくとも３度聴かれたすべてのジャズ音楽を含むように、ユーザがフォルダを定義する状況を含む。派生フォルダは、一定の例外はあるが特定のタイプの全ファイルを含むように、プレファレンスによって定義されることもできる。たとえば、フォルダは、ジャズミュージシャンであるマイルズデービスによる全トラックを含むが、特定の歌のトラック（たとえば、Ｈｕｍａｎ  ＮａｔｕｒｅおよびＮｅｗ  Ｒｕｍｂａ）を除外するように定義され得る。さらに、プレファレンスは、ユーザがファイルをフォルダにドラッグアンドドロップすることができるとともにドロップされたファイルが定義されているタイプであるかどうかをフォルダが確かめるように定義され得ることが留意されるべきである。ファイルは、認められたタイプである場合、フォルダに追加されることができ、認められたタイプでない場合、ファイルは、拒否されることができ（たとえば、フォルダにコピーされない）、あるいは、ユーザは、特定のファイルに対して例外が作成されるべきかどうかに関してプロンプトを出され得る。
【０３０４】
さらに、特定のフォルダが、アクティブフォルダおよび派生フォルダ両方の特性を示し得ることが留意されるべきである。したがって、いくつかのフォルダは、フォルダ、ならびにそうした項目に対して特定のイベントが起こったとき、どのようなアクションをとるかを指定するプレファレンスにどの項目が含まれるかを指定する、関連づけられたプレファレンスを有し得る。
【０３０５】
アプリケーションは、システム１００の実行エンジンを使って処理され得る。上で開示されたように、プレファレンスは、データとして格納され、データクエリの形で実行され得る。データストア１５０は、データを１つまたは複数のテーブルに格納することができ、こうしたテーブルは次いで、プレファレンス情報を使用して照会され得る。従来、テーブルからなるデータベースに対するクエリの実行はコンピュータによる実行が不可能であった。というのは、フォルダ中のデータが最新に保たれるようにするために、クエリは、比較的短い間隔で連続して実行されなければならなかったからである。このようなクエリの実行は、特に、フォルダデータをアップデートするためにクエリを絶えず実行する間、プロセッサが複数のプログラムを効率的に実行することができない、パーソナルコンピュータのような軽いシステムでは現実的でない。しかし、本発明は、データが追加され、消去され、または修正されるときなど、イベントが起こるとクエリを実行することによって、この問題を克服する。したがって、プロセッサは、クエリを連続して実行するという負荷を負わされず、フォルダデータは最新に保たれる。
【０３０６】
（アクティブフォルダに基づくワークフローのような活動）
個別設定（たとえば、ＥＣＡ規則）は、ワークフローまたはタスクスケジュールとは異なる。ワークフローまたはタスクスケジュールは、フォルダ中の項目により表され得る多段階工程である。個別設定とは、エンドユーザにとって意味のあるイベント（たとえば、ｅメールの到着）またはシステム／アプリケーションの振舞い（たとえば、デスクトップでの割込みを、ユーザコンテキストに基づいて制御する）の処理を自動化する目的で、システム／アプリケーションインターセプトポイントで適用されるプレファレンスをエンドユーザが指定することを可能にする概念である。個別設定は、プレファレンスの論理が所与のインターセプトポイント（たとえば、イベント、フロー中のポイントなど）に局所化されるプレファレンスをエンドユーザが表すことを可能にすることに関わる。単一のプレファレンスのアクションに起因する、複数のプレファレンスのどのカスケード式評価も偶発的であり、計画されたものではない。したがって、個別設定は、ワークフローの短縮形ではなく、ワークフローおよび個別設定は、全く異なるものである。イベントを扱うプレファレンスの偶発的カスケード処理は、ワークフローにおける計画された一連のタスク／規則とは異なる。さらに、個別設定は、ワークフローまたはタスクスケジュールが含まれるかどうかに関わらず、ｅメール、電話の通話、デスクトップでの割込み、および他の多くのタイプのエンドユーザイベントに適用され得る。個別設定されたワークフローは、個別設定が、独立しているが、ワークフローに対して補足的な概念であるという前提に基づく。
【０３０７】
個別設定は、エンドユーザの決定が適切な場合はいつでも、ワークフローにもタスクスケジュールにも適用され得る。タスクの個別設定におけるワークフローの個別設定、ワークフロー開始の個別設定、ワークフロータスクの個別設定、およびワークフロースケジューリングの個別設定のために、様々な機会がある。タスクの個別設定の例は、ある人の直属の部下による一定の金額の手形を自動的に承認するなど、特定のタスクの処理を自動化するための決定論理をユーザが指定する事例でよい。ワークフローの開始は、興味のあるイベント（たとえば、電話での通話、ｅメールの到着など）に基づいて、ワークフローを開く／開始するかどうかという決定を扱う。計画された個別設定は、おそらく、追跡されるスケジュールと対話するなどの適切な機能でラップすることによって、ワークフロータスクに変えられ得る。言い換えると、個別設定は、ワークフローにおいて、ユーザプレファレンスがタスクの解決を完全に決定する、計画されたタスクとして使われ得る。最後に、個別設定は、ワークフロースケジューリングに含まれ得る。ワークフロー中の次のステップに関する選択肢が存在する場合、個別設定が、ユーザにこのような決定のためのプレファレンスを指定させるために使われ得る。
【０３０８】
上記のカテゴリの多くを含む、個別設定されるワークフローの実際の例は、経費報告の処理でよい。この例において、ｅメールがインボックスに届き、ｅメールのタイプが検出され（たとえば、サブジェクト行、経費報告としてフラグが立てられている、など）、ｅメールデータが走査され、インボイス価額が一定の金額より低い場合、報告は、承認済みフォルダに移動される。その後、報告が承認されたという状況を示すｅメールが、送信者に返送され得る。続いて、ユーザによる毎月の見直しのために刊行物が作成されることができ、承認された合計量が集計されることができる。
【０３０９】
ワークフローの個別設定の上記のカテゴリはすべて、ワークフローの価値を高めるが、このような利益の適用可能性は、ワークフローに限られるものではない。そうした利益は、通信処理、経路指定、または個別設定を含むが、それに限定されない他の多くの領域に適用されることができ、このような領域は、ワークフローに関与しなくてもよい。
【０３１０】
（クロニクルフォルダ）
本発明の態様によるクロニクルは、システムの１人または複数のユーザに関する履歴およびコンテキスト情報を表す。通知システムはしばしば、先行アクションに基づいてアクションをとるかどうかという評価の一部として使われ得る履歴データの概念を含む。たとえば、ユーザは、「ＭＳＦＴの株がその日の新高値を記録したときに通知を行う」という、プレファレンスのセットアップを望む場合がある。この場合、システムは、その日のＭＳＦＴ株の最高値ポイントを維持し、新高値が達成されたときにこの情報をアップデートすることができなければならない。
【０３１１】
本発明の態様によると、クロニクルは、データストアに格納され、（たとえば、オペレーティングシステムによって与えられる）ユーザインターフェイスを介してユーザに対して自由にアクセス可能である。したがって、エンドユーザが、この履歴データに対する制御を有する。ユーザは、他のファイルがバックアップされる方法でデータのバックアップをとり、自宅または職場にある他のコンピュータとデータを同期させることができ、標準のファイル共有機構を介してデータを共有することができ、誰が正確にこのコンテキスト情報にアクセスすることができるかを制御するように、アクセス許可および他のセキュリティ設定を設定することができる。たとえば、ユーザは、自分のワークグループの全員がＭＳＦＴの株価についての履歴情報を見るのを許可することができるが、グループのメンバが自分の席にいるか、それともミーティング中であるかなど、コンテキスト情報の制限を望む場合がある。
【０３１２】
さらに、本発明のシステムは、特定の共通の振舞いを、「監査」クロニクルを作成するための能力を含む「内蔵型」クロニクル作成／維持論理として公開することができ、ユーザに代わってとられるすべてのアクションが、次のようなクロニクルに保存される。すなわち、システムが、特定の種類のイベントまたはアクションを、これまでにいくつ見てきたかをカウントする「カウント」クロニクルと、一定の期間に渡ってそれまでに見られた最高および最低の値を追跡することができる「高／低水準線」クロニクルとである。
【０３１３】
さらに、本システムは、こうしたクロニクルが、アプリケーションによってアップデートされることを可能にすることができ、こうしたクロニクルは、情報エージェントアプリケーションについて何も知らない。多くの通知プラットフォームが、ユーザ規則（本明細書において、プレファレンスとも呼ばれる）の通常処理の間にコンテキスト情報がアップデートされることを可能にするが、本発明は、データストアに格納されている体系化されたデータを規則またはプレファレンス処理の一部として使用するので、システムは、どのアプリケーションによって作成されたコンテキスト情報も使うことができる。たとえば、ユーザは、ユーザのコンピュータにリアルタイムの株式相場を流す、ＮＡＳＤＡＱによって書かれたアプリケーションをダウンロードし、実行することができる。ＮＡＳＤＡＱアプリケーションは、ユーザが興味をもっている記号それぞれに対してファイルを作成し、関連する情報を、こうしたファイルに保存することができる。本発明の情報エージェントアプリケーションは、一態様によると、このタイプの、外部化されたコンテキスト情報を使用するように構築されるので、情報エージェントシステムは、こうしたファイルを、ユーザ規則またはプレファレンス処理中にクロニクルとして使用することができる。
【０３１４】
クロニクルは、アクティブフォルダとともに使われることもできる。個別設定フォルダシステムは、特定のフォルダを見張る能力を含むので、作成され、修正され、またはこのようなフォルダに移動されるフォルダ項目は、特定のクロニクルまたは１組のクロニクルに対する、コンテキストのアップデートとして扱われ得る。このようにして、ユーザは、プログラマによって書かれたどのコードも自分の代わりに実行させずに、クロニクルを維持することができる。そうではなく、エンドユーザは、自分のコンテキスト情報を最新に保つために、オペレーティングシステムの既存のファイル操作機構を使用するだけでよい。
【０３１５】
したがって、本発明は、方法、機器、あるいはソフトウェア、ファームウェア、ハードウェア、またはこれらのどの組合せも製造するための標準プログラミングおよび／または工学技術を用いた製造品として実装され得る。本明細書で使用する「製造品」（あるいは、「コンピュータプログラム製品」）という用語は、どのコンピュータ可読デバイス、搬送波、または媒体からもアクセス可能なコンピュータプログラムを包含することを意図している。当然ながら、この構成に対して、本発明の範囲から逸脱することなく、多くの修正が行われ得ることを、当業者は理解するであろう。
【０３１６】
上で説明した例示的なシステムを念頭において、図３６〜４１のフローチャートを参照すると、本発明によって実装することができる方法がよりよく理解されよう。説明を簡単にするために、この方法を一連のブロックとして示し説明するが、本発明はブロックの順序に限定されないことを理解されたい。というのは、いくつかのブロックは、本発明によって、異なる順序で起こることもでき、かつ／または本明細書において示され説明される他のブロックと同時に起こることもできるからである。さらに、図示したすべてのブロックが、本発明による方法の実装に必要とされるわけではない。
【０３１７】
図３６に移ると、本発明の態様による、プレファレンスを利用する方法３６００が示されている。３６１０で、プレファレンスが、開発者スキーマ（たとえば、ＸＭＬスキーマ）に基づいて、エンドユーザによって指定され、たとえば、データストア中のテーブルに格納される。次いで、３６２０で、１つまたは複数のイベントが受け取られ、または検出されることができる。プレファレンスは次いで、３６３０で、データテーブルを照会するための照会言語（たとえば、ＳＱＬ）を使用して実行され、または評価されることができる。３６４０で、結果テーブルが作成され、または条件が有効なプレファレンスを投入されることができる。最後に、３６５０で、結果テーブルの結果に基づいて、それぞれのアクションが実行され得る。
【０３１８】
図３７に移ると、本発明の態様による、アプリケーションをインストールする方法３７００が示されている。３７１０で、基底テーブルが、インストールされたアプリケーションにおいて実行されることになる、システムまたはプラットフォームに関連づけられたデータストア（たとえば、情報エージェントシステムデータストア１５０）にセットアップされる。基底テーブルは続いて、３７２０で、インストールされたアプリケーション用に厳密に新しいテーブルおよびデータベースを作成するのではなく、アプリケーションデータでアップデートされる。３７３０で、アプリケーションプロシージャが、たとえば、アプリケーションプロシージャ用に指定された基本となるテーブルに、データとして格納される。実行のために、アプリケーションプロシージャのテキスト列がデータベースから削除され、一側面に従ってリアルタイムに実行される。
【０３１９】
図３８は、本発明の態様による、アプリケーションを拡張する方法３８００を示す。３８１０で、ＥＤＦが開発者から受け取られる。ＥＤＦは、他のアプリケーションで定義される条件、アクション、およびイベントを参照するために、あるアプリケーションにおいてプレファレンスクラスを使用可能にすることに関する情報を含む。その後、３８２０で、関数バインディングが、インスタンスレジストリなど、中心的な場所に登録される。３８３０で、バインディング情報が、拡張コンポーネントによって取得され、または受け取られる。続いて、３８４０で、受諾論理が、バインディングに適用され得る。ＥＤＦがインストールされると、バインディングが使用可能にされるが、本発明の一態様に従って、アプリケーションに自動的に適用されるわけではない。そうではなく、受諾論理は、ＥＤＦが受諾されるべきかどうか判定するために適用される。受諾論理は、ＥＤＦが受諾されるかどうか判定するために、なかでも、バインディングの真正性、認可、および／または信頼できるソースによる認証を調べる。３８５０で、アプリケーションがバインディングを受諾するかどうかに関して、アプリケーションによって判定が行われる。「ｎｏ」の場合、プロセスは、バインディングなしで単に終了する。「ｙｅｓ」の場合、３８６０で、候補関数バインディングが、第１のアプリケーションから第２のアプリケーションにバインドされる。
【０３２０】
図３９は、本発明の態様による、アプリケーションをアンインストールする方法３９００のフローチャートを示す。３９１０で、アンインストールされるアプリケーションが、その登録内容をすべて、中心的な格納場所から削除する。中心的な記憶場所は、定義を有するインスタンスレジストリおよびバインディングレジストリでよい。アプリケーションコンポーネントは次いで、３９２０で削除され得る。従属アプリケーションが次いで、アンインストールされたアプリケーションを（たとえば、拡張コンポーネントによって）通知され得る。さらに、上述したように、方法３９００のブロックは、どの順序でもよい。したがって、本発明の別の態様は、従属アプリケーションが、どのアンインストールまたは除去プロセスにも先行して通知を受けることを含む。
【０３２１】
図４０は、本発明の態様による、プログラマチック定数を複数のアプリケーションに渡って拡張する方法のフローチャートを示す。４０１０で、定数が受け取られる。４０２０で、定数の値が、アプリケーションドメインを検索することによって決定される。たとえば、定数ＭｙＭａｎａｇｅｒが受け取られた場合、本方法は、ｅメールアプリケーションを検索し、ＭｙＭａｎａｇｅｒの値を決定することができる。
【０３２２】
図４１は、本発明の態様による、コンピュータ機能を個別設定する方法４１００を示す。４１１０で、エンドユーザが、提供されたスキーマに従ってプレファレンスを書く。プレファレンスは、どのような形でもよいが、本発明の一態様によると、ブール演算子によって区切られる複数のＩＦ−ＴＨＥＮステートメントを含む。スキーマは、制限を課すためにアプリケーション開発者によって提供され、そうすることによって、エンドユーザによるプログラミングを簡素化することができる。４１２０で、イベントが起こると、プレファレンスが実行される。イベントは、フォルダデータの変更や株価の変動を含むが、それに限定されないどのような出来事でもよい。プレファレンスの実行または評価は、データストアコンポーネント中のデータの照会を使用して行われ得る。４１２０で、条件が有効なプレファレンスに基づいてアクションがとられる。
【０３２３】
本発明の様々な態様に関する状況を提供するために、図４２および４３ならびに以下の説明は、本発明の様々な態様が実装され得る適切な計算機環境の、簡潔で一般的な説明を提供することを意図している。これまでは、一台のコンピュータおよび／または複数のコンピュータ上で実行されるコンピュータプログラムのコンピュータ実行可能命令という一般的な状況において本発明が説明されたが、本発明は他のプログラムモジュールとの組合せでも実装され得ることを当業者は理解するであろう。概して、プログラムモジュールは、特定のタスクを実施し、かつ／または特定の抽象データタイプを実装するルーチン、プログラム、コンポーネント、データ構造などを含む。さらに、本発明の方法は、他のコンピュータシステム構成とともに実施され得ることを当業者は理解するであろう。他のコンピュータシステム構成は、シングルプロセッサコンピュータシステムまたはマルチプロセッサコンピュータシステム、ミニコンピュータデバイス、メインフレームコンピュータ、ならびにパーソナルコンピュータ、ハンドヘルドコンピューティングデバイス、マイクロプロセッサベースの家電製品またはプログラム可能な家電製品などを含む。例示される本発明の態様は、通信ネットワークを介してリンクされるリモート処理デバイスによってタスクが実施される分散型計算機環境でも実施され得る。ただし、すべてではなくともいくつかの本発明の態様は、スタンドアロンコンピュータにおいても実施され得る。分散型計算機環境では、プログラムモジュールは、ローカルメモリ記憶デバイスおよびリモートメモリ記憶デバイス内両方に配置され得る。
【０３２４】
図４２を参照すると、本発明の様々な態様を実装する例示的な環境４２００は、コンピュータ４２１２を含む。コンピュータ４２１２は、処理ユニット４２１４、システムメモリ４２１６、およびシステムバス４２１８を含む。システムバス４２１８は、システムメモリ４２１６を含むがそれに限定されないシステムコンポーネントを処理ユニット４２１４に結合する。処理ユニット４２１４は、市販されている様々なプロセッサのいずれでもよい。デュアルマイクロプロセッサおよび他のマルチプロセッサアーキテクチャも、処理ユニット４２１４として利用され得る。
【０３２５】
システムバス４２１８は、市販されている様々などのバスアーキテクチャも用いるメモリバスもしくはメモリコントローラ、周辺バスもしくは外部バス、および／またはローカルバスを含むいくつかのタイプのバス構造（群）のどれでもよく、こうしたバス構造は、１１ビットバス、ＩＳＡ（業界標準アーキテクチャ）、ＭＳＡ（マイクロチャネルアーキテクチャ）、ＥＩＳＡ（拡張ＩＳＡ）、ＩＤＥ（インテリジェントドライブエレクトロニクス）、ＶＬＢ（ＶＥＳＡローカルバス）、ＰＣＩ（周辺装置相互接続）、ＵＳＢ（ユニバーサルシリアルバス）、ＡＧＰ（拡張グラフィックスポート）、ＰＣＭＣＩＡ（ＰＣカードアダプタ）、およびＳＣＳＩ（小型コンピュータシステムインターフェイス）を含むが、それに限定されない。
【０３２６】
システムメモリ４２１６は、揮発性メモリ４２２０および不揮発性メモリ４２２２を含む。たとえば起動中に、コンピュータ４２１２内部の要素の間で情報を転送するための基本ルーチンを含む基本入出力システム（ＢＩＯＳ）が、不揮発性メモリ４２２２に格納される。限定ではなく例として、不揮発性メモリ４２２２は、ＲＯＭ（読出し専用メモリ）、ＰＲＯＭ（プログラム可能ＲＯＭ）、ＥＰＲＯＭ（電気的プログラム可能ＲＯＭ）、ＥＥＰＲＯＭ（電気的消去可能ＲＯＭ）、またはフラッシュメモリを含み得る。揮発性メモリ４２２０は、外部キャッシュメモリとして作用するＲＡＭ（ランダムアクセスメモリ）を含む。限定ではなく例として、ＲＡＭは、ＳＲＡＭ（同期ＲＡＭ）、ＤＲＡＭ（ダイナミックＲＡＭ）、ＳＤＲＡＭ（シンクロナスＤＲＡＭ）、ＤＤＲ  ＳＤＲＡＭ（ダブルデータレート方式ＳＤＲＡＭ）、ＥＳＤＲＡＭ（拡張ＳＤＲＡＭ）、ＳＬＤＲＡＭ（シンクリンクＤＲＡＭ）、およびＤＲＲＡＭ（ダイレクトランバスＲＡＭ）など、多くの形で市販されている。
【０３２７】
コンピュータ４２１２は、取外し可能／固定式、揮発性／不揮発性コンピュータ記憶媒体も含む。図４２は、たとえばディスク記憶装置４２２４を示す。ディスク記憶装置４２２４は、磁気ディスクドライブ、フロッピー（登録商標）ディスクドライブ、テープドライブ、Ｊａｚドライブ、Ｚｉｐドライブ、ＬＳ−１００ドライブ、フラッシュメモリカード、またはメモリスティックなどのデバイスを含むが、それに限定されない。さらに、ディスク記憶装置４２２４は、記憶媒体を、別個に含むことも、ＣＤ−ＲＯＭ（コンパクトディスクＲＯＭデバイス）、ＣＤ−Ｒドライブ（書込み可能ＣＤドライブ）、ＣＤ−ＲＷドライブ（書換え可能ＣＤドライブ）、またはＤＶＤ−ＲＯＭ（デジタルビデオディスクＲＯＭドライブ）などの光ディスクドライブを含むがそれに限定されない他の記憶媒体と組み合わせて含むこともできる。システムバス４２１８へのディスク記憶装置４２２４の接続を容易にするために、取外し可能または固定式インターフェイスは通常、インターフェイス４２２６などとして使われる。
【０３２８】
図４２は、適切な動作環境４２１０において述べられる、ユーザと基本的なコンピュータリソースとの間の媒介として作用するソフトウェアを示すことが理解されるべきである。このようなソフトウェアは、オペレーティングシステム４２２８を含む。オペレーティングシステム４２２８は、ディスク記憶装置４２２４に格納されることができ、コンピュータシステム４２１２のリソースを制御し割り振るように作用する。システムアプリケーション４２３０は、システムメモリ４２１６またはディスク記憶装置４２２４のどちらかに格納された、プログラムモジュール４２３２およびプログラムデータ４２３４を介して、オペレーティングシステム４２２８によるリソース管理を活用する。本発明は、様々なオペレーティングシステム、またはオペレーティングシステムの組合せを用いて実装され得ることが理解されるべきである。
【０３２９】
ユーザは、入力デバイス（群）を介して、コマンドまたは情報をコンピュータ４２１２に入力する。入力デバイス４２３６は、ポインティングデバイス、たとえばマウス、トラックボール、スタイラス、タッチパッド、キーボード、マイクロホン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナ、ＴＶチューナカード、デジタルカメラ、デジタルビデオカメラ、ウェブカメラなどを含むが、それに限定されない。こうしたおよび他の入力デバイスは、インターフェイスポート（群）４２３８を介して、システムバス４２１８によって処理ユニット４２１４に接続される。インターフェイスポート（群）４２３８は、たとえば、シリアルポート、パラレルポート、ゲームポート、およびＵＳＢ（ユニバーサルシリアルバス）を含む。出力デバイス（群）４２４０は、入力デバイス（群）４２３６と同じタイプのポートの一部を使う。したがって、たとえば、ＵＳＢポートは、コンピュータ４２１２への入力を可能にし、コンピュータ４２１２から出力デバイス４２４０に情報を出力するのに用いられ得る。出力アダプタ４２４２は、他の出力デバイス４２４０の中でも、専用アダプタを必要とする、モニタ、スピーカ、およびプリンタのようないくつかの出力デバイス４２４０があることを示すために図示されている。出力アダプタ４２４２は、限定ではなく例として、出力デバイス４２４０とシステムバス４２１８の間の接続手段を提供するビデオカードおよびサウンドカードを含む。リモートコンピュータ（群）４２４４など、他のデバイスおよび／またはデバイスからなるシステムは、入力および出力機能両方を提供することが留意されるべきである。
【０３３０】
コンピュータ４２１２は、１つまたは複数のリモートコンピュータ、たとえばリモートコンピュータ（群）４２４４への論理接続を使用してネットワーク接続された環境において動作することができる。リモートコンピュータ（群）４２４４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ワークステーション、マイクロプロセッサベースの機器、ピアデバイスまたは他の共通ネットワークノードなどでよく、通常、コンピュータ４２１２に関連して説明された要素の多くまたはすべてを含む。簡潔にするために、メモリ記憶装置４２４６のみがリモートコンピュータ（群）４２４４とともに示されている。リモートコンピュータ（群）４２４４は、ネットワークインターフェイス４２４８を介してコンピュータ４２１２に論理的に接続され、さらに通信接続４２５０を介して物理的に接続される。ネットワークインターフェイス４２４８は、ＬＡＮ（ローカルエリアネットワーク）およびＷＡＮ（ワイドエリアネットワーク）などの通信ネットワークを包含する。ＬＡＮ技術は、ＦＤＤＩ（光ファイバ分散データインターフェイス）、ＣＤＤＩ（銅線配線データインターフェイス）、イーサネット（登録商標）／ＩＥＥＥ１１０２．３、トークンリング／ＩＥＥＥ１１０２．５などを含む。ＷＡＮ技術は、二地点間リンク、ＩＳＤＮ（統合サービスデジタルネットワーク）のような回路交換ネットワークおよびその変換、パケット交換ネットワーク、ならびにＤＳＬ（デジタル加入者線）を含むが、それに限定されない。
【０３３１】
通信接続（群）４２５０は、ネットワークインターフェイス４２４８をバス４２１８に接続するのに利用されるハードウェア／ソフトウェアを指す。通信接続４２５０は、わかりやすくするためにコンピュータ４２１２内部に示されているが、コンピュータ４２１２の外部にあってもよい。ネットワークインターフェイス４２４８への接続に必要なハードウェア／ソフトウェアは、単なる例として、標準的な電話レベルのモデム、ケーブルモデム、およびＤＳＬモデムを含むモデム、ＩＳＤＮアダプタ、ならびにイーサネット（登録商標）カードなど、内部および外部技術を含む。
【０３３２】
図４３は、本発明と相互作用し得る例としての計算機環境４３００の概略的なブロック図である。システム４３００は、１つまたは複数のクライアント（群）４３１０を含む。クライアント（群）４３１０は、ハードウェアおよび／またはソフトウェア（たとえば、スレッド、処理、コンピューティングデバイス）でよい。システム４３００は、１つまたは複数のサーバ（群）４３３０も含む。サーバ（群）４３３０は、ハードウェアおよび／またはソフトウェア（たとえば、スレッド、プロセス、コンピューティングデバイス）でよい。サーバ４３３０は、たとえば、本発明を利用して変換を実施するためのスレッドを収容することができる。クライアント４３１０とサーバ４３３０の間で起こり得る１つの通信は、２つ以上のコンピュータ処理の間で伝送されるように適合されたデータパケットの形をとり得る。システム４３００は、クライアント（群）４３１０とサーバ（群）４３３０の間の通信を容易にするのに利用され得る通信フレームワーク４３５０を含む。クライアント（群）４３１０は、クライアント（群）４３１０にローカルな情報を格納するのに利用され得る、１つまたは複数のクライアントデータストア（群）４３６０に動作可能に接続される。同様に、サーバ（群）４３３０は、サーバ４３３０にローカルな情報を格納するのに利用され得る、１つまたは複数のサーバデータストア（群）４３４０に動作可能に接続される。
【０３３３】
上記の説明内容は、本発明のいくつかの例を含む。当然ながら、本発明を説明するためのコンポーネントまたは方法のあらゆる組合せを説明することはできないが、本発明のさらに多くの組合せおよび入替えが可能であることを、当業者は理解できるであろう。したがって、本発明は、添付の特許請求の範囲の精神および範囲内であるこのようなすべての変更形態、修正形態、および変形形態を包含することを意図したものである。さらに、詳細な説明または特許請求の範囲において「含む」という用語が使われている限りでは、「備える」は、使用される場合、請求項においては接続語として解釈されるが、「含む」のような用語は、「備える」という用語と同様に包括的であることを意図している。
【０３３４】
【表３３−１】
2007509416.tif 000039
【０３３５】
【表３３−２】
2007509416.tif 000040
【０３３６】
【表３３−３】
2007509416.tif 000041
【図面の簡単な説明】
【０３３７】
【図１】本発明の態様による情報エージェントシステムを示すブロック図である。
【図２】本発明の態様による通知コンポーネントを示すブロック図である。
【図３】本発明の態様による情報エージェントアプリケーションを示すブロック図である。
【図４】本発明の態様による例示的な論理スキーマを示すブロック図である。
【図５】本発明の態様による、定数アクセス機構評価システムを示すブロック図である。
【図６】本発明の態様によるプレファレンス評価システムを示すブロック図である。
【図７】本発明の態様による優先順位システムを示す概略的なブロック図である。
【図８】本発明の態様による分類器を示すブロック図である。
【図９】本発明の態様によるメッセージ分類を示す概略的なブロック図である。
【図１０】本発明の態様によるスカラー分類器の出力を示す概略的なブロック図である。
【図１１】本発明の態様による、クラスおよびスカラー出力に従って分類されたテキストを示す概略的なブロック図である。
【図１２】本発明の態様による線形優先順位モデルを示す図である。
【図１３】本発明の態様による非線形優先順位モデルを示す図である。
【図１４】本発明の態様による、ユーザ活動を判定するモデルを示す図である。
【図１５】本発明の態様による、現在のユーザ活動を判定する、推論に基づくモデルを示す図である。
【図１６】本発明の態様による、警告コストを決定する、推論に基づくモデルを示す図である。
【図１７】本発明の態様による、警告コストを決定する、推論に基づくより詳細なモデルを示す図である。
【図１８】本発明の態様による、忠実度損失を考慮して警告コストを決定する、推論に基づくより詳細なモデルを示す図である。
【図１９】本発明の態様による、優先順位を生成し決定する方法を示すフローチャートである。
【図２０】本発明の態様によるテキスト生成プログラムおよび分類器を示す図である。
【図２１】本発明の態様による、実行エンジンとコンテキストアナライザの間の組織的な協働を示す概略的なブロック図である。
【図２２】本発明の一態様によるコンテキストアナライザを示すブロック図である。
【図２３】本発明の一態様によるソースおよびシンクを示すブロック図である。
【図２４】時間の経過にマップされた、通知の有用性を示すグラフである。
【図２５】本発明の態様による例示的なインターフェイスを示す図である。
【図２６】本発明の態様による、直接測定によってユーザコンテキストを判定する方法を示す図である。
【図２７】本発明の態様による、階層状に順序づけられた、コンテキストを判定する例示的な１組の規則を示すブロック図である。
【図２８】本発明の態様による、推論エンジンによって実施される、ユーザのコンテキストを判定するための推論分析を示すシステムを示す概略的なブロック図である。
【図２９】本発明の態様による、単一期間に対してユーザの注目を推論する例示的なベイズのネットワークを示す図である。
【図３０】本発明の態様による、コンテキスト変数の中での、異なる期間でのユーザの注目のベイズのモデルを示す図である。
【図３１】本発明の態様による、ユーザのコンテキストがどのようにして判定されるかを示すフローチャートである。
【図３２】本発明の態様による通知伝達プロセスを示すフローチャートである。
【図３３】本発明の態様によるアクション／条件の進化チェーンを示す図である。
【図３４】本発明の態様によるアプリケーション対話用システムを示すブロック図である。
【図３５】本発明の態様による、個別設定されたシステムを示すブロック図である。
【図３６】本発明の態様による、プレファレンス利用方法を示すフローチャートである。
【図３７】本発明の態様による、アプリケーションインストール方法を示すフローチャートである。
【図３８】本発明の態様による、アプリケーション実行方法を示すフローチャートである。
【図３９】本発明の態様による、アプリケーションのアンインストールを示すフローチャートである。
【図４０】本発明の態様による、複数のアプリケーションに渡ってプログラム定数を拡張する方法を示すフローチャートである。
【図４１】本発明の態様による、コンピュータ機能の個別設定方法を示すフローチャートである。
【図４２】本発明の態様による、適切な動作環境を示す概略的なブロック図である。
【図４３】本発明と相互作用し得る、一例である計算機環境を示す概略的なブロック図である。
【図１】
2007509416.tif 000042
【図２】
2007509416.tif 000043
【図３】
2007509416.tif 000044
【図４】
2007509416.tif 000045
【図５】
2007509416.tif 000046
【図６】
2007509416.tif 000047
【図７】
2007509416.tif 000048
【図８】
2007509416.tif 000049
【図９】
2007509416.tif 000050
【図１０】
2007509416.tif 000051
【図１１】
2007509416.tif 000052
【図１２】
2007509416.tif 000053
【図１３】
2007509416.tif 000054
【図１４】
2007509416.tif 000055
【図１５】
2007509416.tif 000056
【図１６】
2007509416.tif 000057
【図１７】
2007509416.tif 000058
【図１８】
2007509416.tif 000059
【図１９】
2007509416.tif 000060
【図２０】
2007509416.tif 000061
【図２１】
2007509416.tif 000062
【図２２】
2007509416.tif 000063
【図２３】
2007509416.tif 000064
【図２４】
2007509416.tif 000065
【図２５】
2007509416.tif 000066
【図２６】
2007509416.tif 000067
【図２７】
2007509416.tif 000068
【図２８】
2007509416.tif 000069
【図２９】
2007509416.tif 000070
【図３０】
2007509416.tif 000071
【図３１】
2007509416.tif 000072
【図３２】
2007509416.tif 000073
【図３３】
2007509416.tif 000074
【図３４】
2007509416.tif 000075
【図３５】
2007509416.tif 000076
【図３６】
2007509416.tif 000077
【図３７】
2007509416.tif 000078
【図３８】
2007509416.tif 000079
【図３９】
2007509416.tif 000080
【図４０】
2007509416.tif 000081
【図４１】
2007509416.tif 000082
【図４２】
2007509416.tif 000083
【図４３】
2007509416.tif 000084
【国際調査報告】
2007509416.tif 000085
2007509416.tif 000086