(57)【要約】  コンピュータ機能性をパーソナライズするシステムおよび方法を開示すること。エンドユーザに、例えば複数の単純なＩＦ−ＴＨＥＮ命題ロジックを使用することによる、豊富で複雑なプリファレンスを簡単に記述するツールを与える。次に、プリファレンスを、クエリに変換し、構造化データに対して効率的に実行する。満足されたプリファレンスは、通知の提供または特定のフォルダへのデータの保管などのアクションを実行する。さらに、本発明の態様によれば、なかんずくデータ、ロジック、イベントのすべてが図式化され、これによって、アプリケーションコンポーネントの間およびアプリケーションにまたがるデータの共有が可能になる。
2007518151.tif 000002
【特許請求の範囲】
【請求項１】
図式化されたデータを保管するデータストアコンポーネントと、
エンドユーザ指定のプリファレンスを含むアプリケーションをコンパイルし、これらを前記データストアに保管するコンパイラと、
１つまたは複数のイベントの発生時に前記データストアに保管されたプリファレンスを評価する実行エンジンと
を含むことを特徴とするプリファレンス評価システム。
【請求項２】
条件的に有効なプリファレンスによって指定される１つまたは複数のアクションを行うアクションコンポーネントをさらに含むことを特徴とする請求項１に記載のプリファレンス評価システム。
【請求項３】
前記アクションコンポーネントは、１つまたは複数のユーザ通信デバイスに関するユーザプリファレンスに基づいて前記実行エンジンによって生成される通知データを変換し、フォーマットする通知コンポーネントを含むことを特徴とする請求項２に記載のプリファレンス評価システム。
【請求項４】
前記通知デバイスは、携帯電話機、ポケットベル、ＰＤＡ、およびコンピュータを含むことを特徴とする請求項１に記載のプリファレンス評価システム。
【請求項５】
イベントソースからイベントデータを抽出し、前記データを前記データストアに保管するイベントコンポーネントをさらに含むことを特徴とする請求項１に記載のプリファレンス評価システム。
【請求項６】
前記イベントソースは、サブスクリプションサービスであることを特徴とする請求項５に記載のプリファレンス評価システム。
【請求項７】
前記イベントソースは、前記データストアコンポーネントであることを特徴とする請求項５に記載のプリファレンス評価システム。
【請求項８】
所与の時のエンドユーザコンテキストを示すコンテキストデータを作り、前記コンテキストデータを前記データストアに保管するコンテキストアナライザをさらに含むことを特徴とする請求項１に記載のプリファレンス評価システム。
【請求項９】
アプリケーションと相互作用する１つまたは複数のＡＰＩをさらに含むことを特徴とする請求項１に記載のプリファレンス評価システム。
【請求項１０】
重いアプリケーションおよび軽いプリファレンスアプリケーションの両方を、前記コンパイラはコンパイルでき、前記実行エンジンは実行できることを特徴とする請求項１に記載のプリファレンス評価システム。
【請求項１１】
前記実行エンジンは、前記データストアに保管されたデータに対してクエリを実行することによってプリファレンスを評価することを特徴とする請求項１に記載のプリファレンス評価システム。
【請求項１２】
エンドユーザプリファレンスは、開発者指定のスキーマに基づくことを特徴とする請求項１に記載のプリファレンス評価システム。
【請求項１３】
エンドユーザプリファレンスおよび前記開発者スキーマに関する情報が、前記データストア内の１つまたは複数のテーブルに保管されることを特徴とする請求項１２に記載のプリファレンス評価システム。
【請求項１４】
基礎テーブルのセットを確立することと、
インストールされるアプリケーションに関連するアプリケーションデータを用いて前記基礎テーブルを更新することと
を含むことを特徴とするアプリケーションをインストールする方法。
【請求項１５】
前記アプリケーションは、ユーザ定義プリファレンスを使用することを特徴とする請求項１４に記載の方法。
【請求項１６】
前記アプリケーションデータは、データとして保管されるアプリケーションプロシージャを含むことを特徴とする請求項１４に記載の方法。
【請求項１７】
請求項１４に記載の方法を実行する命令を保管されたことを特徴とするコンピュータ可読メディア。
【請求項１８】
開発者スキーマに基づいてユーザプリファレンスを指定することと、
前記プリファレンスをデータストア内の１つまたは複数のテーブルに保管することと、
イベントの発生時に前記データストア内の前記テーブルを照会することと、
結果テーブルを作ることと、
前記結果テーブル内のデータに基づいてアクションを実行することと
を含むことを特徴とするプリファレンスを使用する方法。
【請求項１９】
ユーザプリファレンスが、一時に１つ宣言的プログラミングモデルを使用することによって指定されることを特徴とする請求項１８に記載の方法。
【請求項２０】
ユーザプリファレンスが、条件およびアクションを指定するために、１つまたは複数のＯｎ−ｅｖｅｎｔ−ｉｆ−ＴｈｅｎステートメントおよびＢｏｏｌｅａｎ演算子を使用して指定されることを特徴とする請求項１９に記載の方法。
【請求項２１】
前記テーブルの照会は、照会言語ステートメントを実行することを含むことを特徴とする請求項２０に記載の方法。
【請求項２２】
前記開発者スキーマは、ＸＭＬスキーマであることを特徴とする請求項１９に記載の方法。
【請求項２３】
請求項１９に記載の方法を実行するコンピュータ実行可能命令を保管された命令を有することを特徴とするコンピュータ可読メディア。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、全般的にはコンピュータシステムに関し、具体的には、コンピュータシステムをパーソナライズするシステムおよび方法に関する。
【背景技術】
【０００２】
本願は、参照によってその全体を本明細書に組み込まれる、２００３年１０月２４日出願の米国特許仮出願第１０／６９３，７３５号明細書、名称「SYSTEM AND METHOD FOR PREFERENCE APPLICATION INSTALLATION AND EXECUTION」の優先権を主張するものである。
【０００３】
コンピュータおよびコンピューティング関連テクノロジのユーザは、通常、２つの別個のカテゴリすなわち、高い技量および知識を有する個人とそれ以外に分けられる。技量および知識を有する個人は、豊富な形でコンピュータを使用し、思いのままにこれらを混合して、プログラムを作り、豊富で価値のある挙動を容易にする方法を知っている。残りのコンピュータユーザの世界は、技量および知識を有する個人のなすがままである。というのは、これらのユーザが、必要に合わせてコンピュータを働かせるための知識、情報、または能力への簡単または安価なアクセスを拒否されているからである。
【０００４】
テクノロジが、アクセスへの障壁を破壊した場合に、コンピューティングの主要なブレークスルーが発生した。メインフレームの世界では、コンピュータが、大企業以外には持つのに高価にすぎた。ミニコンピュータおよびその後のパーソナルコンピュータ（ＰＣ）の出現が、コスト障壁を破壊し、コンピュータを小企業および個人が入手可能なものにした。１９８０年代に、プログラマが、グラフィカルユーザインターフェース（ＧＵＩ）アプリケーションを作ろうと努力した。豊富で一貫性のあるＧＵＩがなければ、プログラマは、ＰＣユーザに価値のあるアプリケーションを作ることができなかった。Ｖｉｓｕａｌ  Ｂａｓｉｃ革命ならびにコントロールおよびイベントベースＧＵＩ構成を使用することによって、アプリケーション開発者が、簡単に豊富なアプリケーションを作れるようになった。その後、より多くのエンドユーザがこれらのアプリケーションを利用できる、有効なサイクルが確立された。１９９０年代に、エンドユーザは、情報へのアクセスの欠如を克服しようと努力した。インターネットの成長が、この空間を変容させ、ほとんどすべての価値のある情報が、ブラウザを有するすべての人に入手可能になった。しかし、克服を必要とする多数の障壁がまだある。
【０００５】
従来のコンピューティングは、パーソナルではない。いわゆるパーソナルコンピュータに関して、真に「パーソナル」であるものはごくわずかである。ローカルディスクに保管されたデータがパーソナルであることは真実である。しかし、機械の挙動すなわち、機械がユーザの代わりに実行するアクションは、数百万人のユーザの間でほぼ同一である。非常に強力な汎用コンピュータを所有してはいるが、平均的なユーザは、それを、通信エンドポイントして有用な、検索エントリポイントとして有用な、缶詰にされたマスマーケットアプリケーションの実行に有用な静的ツールであるが、それ以外にはこの言葉の真の意味での「パーソナルコンピューティング」を行えないものとして扱う。現在のアプリケーションで使用可能なパーソナライゼーション機能は、可能であり望ましいものの上っ面を撫でるに過ぎない。
【０００６】
さらに、普通のコンピューティングは、自動化されているのではなく、手動であり、ユーザが、判断を行い、適当な時に操作することを必要とする。ほとんどのコンピュータエンドユーザの日常の作業を考慮されたい。とりわけ、エンドユーザは、情報を集め、通信に反応し、通信を開始するか応答し、情報を編成する。コンピュータは、人の間の改善された通信を有し、情報への改善されたアクセスを有する。しかし、コンピュータは、判断を行い、正しい時に操作するという責任からエンドユーザをほとんど解放していない。
【０００７】
さらに、伝統的なコンピューティングは、コンテキスト的ではない。コンピュータソフトウェアは、通常、どちらかといえば静的であり、ユーザの実際のコンテキストに無関係なオプション設定を提供する。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
必要なものは、真にパーソナライズされたコンピュータシステムすなわち、エンドユーザの必要およびプリファレンスを知り、この必要ならびにユーザコンテキストによって案内される形で働くシステムである。さらに、コンピュータシステムおよびソフトウェアは、１人または複数のエンドユーザが関心を持つ情報の収集および取捨と、ユーザによって指定される形でのその情報に対する自動的反応とに関するパーソナルアシスタントをすべてのエンドユーザに提供しなければならない。
【課題を解決するための手段】
【０００９】
次に、本発明のいくつかの態様の基本的な理解を提供するために、本発明の単純化された要約を提示する。この要約は、本発明の詳細な概要ではない。本発明の主要な／クリティカルな要素を識別することおよび本発明の範囲を区切ることは、意図されていない。この要約の唯一の目的は、後で提示する詳細な説明の前置きとして、単純化された形で本発明の一部の概念を提示することである。
【００１０】
情報エージェントシステム、アプリケーション、および方法論を、本明細書で開示する。情報エージェントシステムは、情報エージェントアプリケーション（時々本明細書でＩＡアプリケーションと称する）を実行するプラットフォームを提供する。ＩＡアプリケーションは、エンドユーザがプログラムでき、エンドユーザ実行アシスタントまたはエンドユーザ実行エージェントとして使用することができる。エージェントは、エンドユーザの個人的生産性を大きく高め、デスクトップアプリケーションおよびすべてのパーソナル通信メディア（例えば、携帯電話機、ポケットベル、ＰＤＡなど）を統合するように働くことができる。
【００１１】
情報アプリケーションシステムの中心は、データの図式化（ｓｃｈｅｍａｔｉｚａｔｉｏｎ）である。図式化は、周知の明確に定義されたパターンでのデータの構造化であり、これによって、複数のアプリケーションが互いを認識し、互いに相互作用できるようになる。情報プロパティ、情報イベント、および判断ロジックのすべてを、図式化することができる。図式化された情報プロパティは、エンドユーザアプリケーションの基礎であるデータ（例えば、電子メール、人、グループ、位置など）を参照する。情報プロパティを図式化して、複数の異なるアプリケーションのデータの一貫性のある解釈を可能にすることができる。情報イベントは、プログラムロジックをアタッチするフックを提供する。これらのイベントは、高水準であり、経験のないエンドユーザによる理解を容易にするために情報フローに結び付けられる。イベントも図式化することができる。さらに、判断ロジックを図式化することができる。エンドユーザは、訓練された開発者ではないので、伝統的なプログラミング言語で記述されたプログラムを期待することは無理である。そうではなく、図式化された論理構成ブロック（例えば、ＩＦ−ＴＨＥＮ命題）をエンドユーザに提供でき、その結果、エンドユーザが、単純だが豊富な組合せでそれらをつなぎ合わせることによってプログラムできるようになる。データの図式化、情報フック（イベント）、およびエンドユーザプログラミング機能によって、エンドユーザに、エンドユーザロジックを介して結合され、協同作業するアプリケーションの豊富なエコシステムを伴う大きな価値が与えられ、これによって、初心者のエンドユーザがシステムインテグレータになることが可能になる。
【００１２】
さらに、本発明の態様によれば、情報アプリケーションシステムに、重い情報アプリケーションおよび軽い情報アプリケーションの両方をコンパイルでき、実行できる柔軟な実行エンジンが含まれる。重いアプリケーションに、とりわけ、しばしばハイエンドサーバで実行され、高スループットおよびスケーラビリティを必要とするアプリケーションが含まれる。軽いアプリケーションは、しばしば、パーソナルコンピュータなどのより小さいシステムで実行され、短い待ち時間、小さいデータベースフットプリント、および小さいワーキングセットを必要とするアプリケーションである。より小さいアプリケーションでは、待ち時間とスループットの間のトレードオフが、より大きいサーバアプリケーションに関して逆転する。したがって、本発明の実行エンジンは、特定のシステム要件（例えば、短い待ち時間、小さいデータベースフットプリントなど）を強調するためにトレードオフを行うことによって、複数の異なるアプリケーションプラットフォームでアプリケーションをコンパイルでき、実行できるという点で、柔軟である。
【００１３】
本発明のもう１つの態様によれば、エンドユーザプリファレンスまたはルールが、一時に１つの形で開発され、セットで実行される。一時に１つのプログラミングモデルは、開発者にとって最も自然なモデルであり、開発者が、１つのプリファレンスに対して１つのイベントを指定できるようにする。しかし、本発明の態様によれば、このシステムは、一時に１つプログラム宣言を検索し、セット指向の形で実行される条件クラスクエリを作成し、これによって、インデクシングおよび重複削除などの技法を利用する。これは、プリファレンスが非常に効率的な形で評価されると同時に、開発者およびエンドユーザに、一時に１つの形でプログラムを概念化し、記述させるという点で有益である。
【００１４】
本発明のもう１つの態様によれば、新しいアプリケーションインストールのシステムおよび方法が提供される。従来のシステムでは、アプリケーションインストールに、データベースオブジェクト、テーブル、およびストアドプロシージャの急増が含まれる。いくつかの場合に、アプリケーションは、完全に新しいデータベースを作成する。本発明は、基礎テーブルのセットを提供することによって、アプリケーションインストールを単純化し、促進する。アプリケーションをインストールするために、システムは、単に基礎テーブルを更新する。これは、プログラムアクション、条件、イベント、およびプロシージャをデータとして保管することによって達成することができる。例えば、プロシージャに関して、これらを１ロールのテキストとして作成することができ、このテキストが、データストアに保管される。そのようなプロシージャを実行するために、プログラムテキストを、単純にデータストアから引き出し、実行することができる。
【００１５】
本発明のもう１つの態様によれば、システムが、条件／アクションが情報の異なるドメインにまたがる情報を関連させられるようにするためにアクセッサ定数（ａｃｃｅｓｓｏｒ  ｃｏｎｓｔａｎｔ）をサポートすることができる。アクセッサ定数は、異なるドメインにまたがる情報交換またはデータの共有を容易にする。例えば、アクセッサ定数ＭｙＦａｍｉｌｙを定義し、アクセッサ機能が、電子メールアプリケーションまたはカレンダアプリケーションによって保管されたデータを照会することによって、ＭｙＦａｍｉｌｙのメンバを判定することができる。図式化されたロジックとアクセッサの組合せは、少なくとも、非プログラマが効率的なクロスドメインクエリを記述できるようにするので、有益である。さらに、比較的少数のメンバのアクセッサ定数と組み合わされた比較的少数の条件クラスは、そうでなければアプリケーション開発者によって提供された多数の興味深い条件を使用できるようにする。
【００１６】
本発明のもう１つの態様によれば、ユーザ定義のプリファレンスを拡張して、アプリケーションの間の関係を可能にすることができる。かなりの範囲まで、ＩＡアプリケーションの基準は、ユーザに提示される機能によって決定される。したがって、ＩＡアプリケーションが拡張可能である度合は、既存アプリケーションのコンテキスト内で新しいプリファレンスを定義する新しい条件およびアクションをユーザから使用可能にする範囲によって決定することができる。アプリケーション拡張性は、オリジナルアプリケーションの作成者によるさらなる介入なしで、アプリケーションがインストールされた時の後に新しい条件およびアクションをアプリケーションに追加することを可能にすることを主に狙う。したがって、エンドユーザは、開発者入力なしで、異なるアプリケーションによって提供される条件およびアクションを利用するプリファレンスを作成でき、これによって、アプリケーションの間の豊富な関係が可能になる。
【００１７】
さらに、本発明のシステムは、情報エージェントアプリケーションをサポートする。本発明の態様によれば、そのようなアプリケーションの１つは、フォルダ、データコンテナ、またはデータストアおよび関連するファイルシステム（例えば、階層システム、任意のまたは明示的な関係を介して関連するファイル）によって提供される他のデータ編成システムに関係することができる。パーソナライズされたフォルダが、エンドユーザ指定のロジックまたはプリファレンスによって定義され、制御される。したがって、エンドユーザは、イベントの発生時にフォルダの内容を制御する条件およびアクションを定義することができる。本発明の一態様では、イベントは、フォルダデータの変更（例えば、文書の追加、削除、または変更）に対応する。プリファレンス（例えば、条件、アクション）は、この要約において、３つのカテゴリすなわち、ユーザの代わりにアクションを行うプリファレンス（例えば、出費レポートに関する電子メールを類似する名前のフォルダに移動する）、フォルダの内容を制御するプリファレンス（例えば、最近２週間に聞いたジャズの全曲を現在のＪａｚｚフォルダに保存する）、およびこの２つの組合せ（例えば、ある金額未満の出費レポートのすべてを承認済みフォルダに保管し、このアクションについてエンドユーザに知らせる電子メールをそのエンドユーザに送信する）に要約することができる。
【００１８】
本発明のもう１つの態様に従ってアクティブフォルダを使用することによって、ワークフロー風のアクティビティを使用することができる。この場合に、プリファレンスを使用するエンドユーザは、フォルダ内のアイテムを介して表されるマルチステップタスクまたは作業を指定することができる。その後、フォルダアイテムに対してアクションを行って、タスクまたは作業を完了することができる。
【００１９】
クロニクル（ｃｈｒｏｎｉｃｌｅ）フォルダも、本発明の態様に従って使用することができる。クロニクルは、システムの１人または複数のユーザに関するヒストリおよびコンテキスト情報を表す。本発明の態様によれば、クロニクルを、データストアに保管し、エンドユーザが自由にアクセス可能にすることができる。したがって、エンドユーザは、ヒストリカルデータに対する制御を維持し、それに基づいてプリファレンスを記述することができる。例えば、ユーザは、ワークグループの誰もが、ある株価に関するヒストリカル情報を見られるようにすることができ、そのユーザが自分の机にいるか会議中であるかなどのコンテキスト情報を制限することを望むことができる。
【００２０】
前述および関連する目的を達成するために、本発明のある例示的態様を、次の説明および添付図面に関して本明細書で説明する。これらの態様は、本発明を実施できる様々な形を示し、そのすべてが、本発明に含まれることが意図されている。本発明の他の利益および新規の特徴は、図面と共に検討される場合に、本発明の次の詳細な説明から明白になる。
【発明を実施するための最良の形態】
【００２１】
本発明を、添付図面を参照して説明するが、図面全体を通じて、同一の符号が同一の要素を指す。しかし、図面およびそれに対する詳細な説明が、開示される特定の形態に本発明を制限することを意図されていないことを理解されたい。そうではなく、本発明は、本発明の趣旨および範囲に含まれるすべての修正形態、同等物、および代替形態を含む。
【００２２】
本明細書で使用される用語「コンポーネント」および「システム」は、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのいずれであれ、コンピュータ関連の実体を指すことが意図されている。例えば、コンポーネントは、プロセッサで動作するプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行のスレッド、プログラム、および／またはコンピュータとすることができるが、これに制限はされない。例えば、サーバで動作するアプリケーションとサーバの両方を、コンポーネントとすることができる。１つまたは複数のコンポーネントが、１つのプロセスおよび／または実行のスレッド内に存在することができ、１つのコンポーネントを、１つのコンピュータにローカライズし、および／または複数のコンピュータの間で分散することができる。
【００２３】
本明細書で使用する用語「推論」は、一般に、システム１０、環境、および／またはユーザの状態の、イベントおよび／またはデータを介して取り込まれた観察の組からの推理または推論の過程を指す。例えば、推論を使用して、特定のコンテキストまたはアクションを識別することができ、状態に関する確率分布を生成することができる。推論は、蓋然論的すなわち、データおよびイベントの考慮に基づく、関心を持たれた状態に対する確率分布の計算とすることができる。推論は、イベントおよび／またはデータの組から上位イベントを構成するのに使用される技法を指すこともできる。そのような推論は、イベントが時間的に近い近接で相関するか否かにかかわらず、イベントおよびデータが１つまたは複数のイベントソースおよびデータソースのいずれから来るかにかかわらず、観察されたイベントおよび／または保管されたイベントデータの組からの新しいイベントまたはアクションの構成をもたらす。
【００２４】
情報エージェントプラットフォーム
まず図１を見ると、本発明の態様による情報エージェントシステム１００が示されている。情報エージェントシステム１００に、アプリケーションプログラミングインターフェース（ＡＰＩ）１１０、コンパイラ１２０、イベントコンポーネント１３０、コンテキストアナライザ１４０、図式化データストア１５０、プリファレンス実行エンジン１６０、アクションコンポーネント１７０、および通知コンポーネント１８０が含まれる。システム１００は、様々な情報エージェントアプリケーションの実行を容易にするプラットフォームを提供する。システム１００は、自律システムまたはより大きいシステムのコンポーネント部分とすることができる。システム１００を、本発明の態様に従って、コンピュータオペレーティングシステムと共に使用することができ、このオペレーティグシステムは、パーソナルコンピュータと、電話機および携帯情報端末（ＰＤＡ）などのモバイルデバイスとを含むがこれに制限されない複数の異なるコンピューティングデバイスで使用することができる。システム１００を、サーバで（例えば、ＳＱＬＳｅｒｖｅｒ、ＷｉｎＦＳサーバ）およびサブスクリプションサービスと共に使用することもできる。したがって、システム１００を使用して、クライアント、サーバ、およびクライアント−サーバ−クラウドサービス（例えば、Ｏｕｔｌｏｏｋ、Ｅｘｃｈａｎｇｅ、およびＨｏｔｍａｉｌ）で様々な製品およびサービス提供情報エージェントの間の協同作用を提供することができる。
【００２５】
ＡＰＩ１１０は、システム１００との相互作用を容易にするためにシステム１００に含まれる。ＡＰＩ１１０は、開発者が、情報エージェントシステム１００の様々なコンポーネントをセットアップするのに使用することができる。さらに、ＡＰＩ１１０を使用して、システム１００で動作する情報エージェントアプリケーションから使用可能な１つまたは複数のイベントソースからの複数のイベントおよび／または現在のユーザコンテキストを構成することができる。さらに、ＡＰＩ１１０を使用して、データストア１５０に保管された論理スキーマで反映し、プリファレンスをデータストア１５０に書き込むことができる。本発明の範囲に含まれることが意図されるＡＰＩ１１０の多数の他の使用が、本明細書を読む時に当業者に明白になることを諒解されたい。
【００２６】
データストア１５０は、図式化されたデータの豊富な構造化ストアである。データの図式化すなわち、周知の定義されたパターンへのデータの構造化は、複数のアプリケーション相互作用を可能にするので、本発明にとって特に重要である。下で詳細に説明するように、データストア１５０を、情報エージェントアプリケーションによって使用して、なかんずく、例えば、イベントおよびプリファレンスのテーブルなど、アプリケーションに関連するデータを保管することができる。さらに、データストア１５０は、情報エージェントシステム１００に含まれるものとして図示されているが、データストア１５０が、このシステムの外部のコンポーネントと相互作用できることを諒解されたい。
【００２７】
コンパイラ１２０も、システム１００に含まれる。コンパイラ１２０は、コンパイラ情報エージェントアプリケーションに対して動作する。具体的に言うと、コンパイラ１２０は、開発者スキーマおよびエンドユーザプリファレンスをコンパイルする。本発明の一態様によれば、例えば、データストア１５０内の、テーブルへの保管のためのスキーマおよびエンドユーザプリファレンスのデータへの変換を容易にする。
【００２８】
システム１００に、イベントコンポーネント１３０も含まれる。イベントは、プリファレンス評価を開始し、これに情報を提供するトリガである。イベントは、イベントソースから発し、イベントソースは、アプリケーションによる内部状態変化および／または世界の外部変化のいずれかとすることができる。イベントコンポーネント１３０は、アプリケーションからＡＰＩを介してサブミットされたイベントをキャプチャし、プリファレンス評価を開始することができる。例えば、イベントは、新しいＳＭＴＰ（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）メッセージを受信したＳＭＴＰプロバイダ、データストア１５０内のデータ変化、オペレーティングシステムアクション、明示的ユーザアクション、および／または他のプリファレンスのアクションによって送出することができる。イベントコンポーネント１３０は、サードパーティプロバイダから、ならびにインターネット通信、ネットワークベース通信、および電話通信などの通信、ならびにソフトウェアサービス、ＸＭＬファイル、アプリケーション、およびデータベースを含むがこれに制限されない複数の異なるタイプのソースから、イベントを収集するかイベントを受け取ることができる。さらに、イベントコンポーネント１３０は、様々な方法を介してデータを監視し、収集することができる。データ収集の例示的方法に、ファイル追加に関するディレクトリの監視、あるタイプのエントリに関するシステムログファイルおよびアプリケーションログファイルの検査、アプリケーションからの警告のトラップ、ウェブページの監視、データベーステーブルの変化の追跡、およびウェブサービスによって提供されるデータの再検討が含まれるが、これに制限はされない。
【００２９】
データを収集するためにイベントコンポーネント１３０によって使用できる様々な異なるモデルもある。これらのモデルは、どれほど頻繁に、どの状況の下で、イベントコンポーネント１３０が様々なイベントソースからイベントを収集するかに影響することができる。
【００３０】
イベントコンポーネント１３０は、少なくとも２つの形の１つでデータについて通知されるか、データを供給されることができる。イベントコンポーネント１３０は、情報が「プッシュ」されるか送信されるのを待つことができ、あるいは、ソースをポーリングし、新しいデータまたは更新されたデータを収集することによって、ソースから情報を「プル」することができる。例えば、ユーザが、お気に入りのニュースページの見出しストーリーが変化するたびに通知されることを望む場合に、イベントコンポーネント１３０を、例えば、そのページを監視し、見出しテキストの変化を検索するように実装することができる。テキストが変化した場合に、イベントコンポーネント１３０は、新しい見出しデータを抽出し、例えば、データストア１５０内のイベントテーブルに保管することによって、そのデータをシステム１００に供給することができる。上の例では、イベントコンポーネントが、必要なデータを収集する責任を負う。というのは、このデータが、プッシュ方法論の使用の場合のようにイベントソースからイベントコンポーネント１３０に供給されるのではないからである。
【００３１】
さらにまたはその代わりに、イベントコンポーネント１３０は、スケジュールまたは事前定義の判断基準を満足するイベントの発生のいずれかに基づいて、システム１００のためにイベントデータを入手することができる。スケジューリングされたイベントコンポーネント１３０は、アプリケーション開発者によって実施される設定に基づいて、周期的に動作することができる。スケジューリングされたイベントコンポーネント１３０は、実行を開始し、新しいイベントデータを検索し、サブミットし、その後、次のスケジューリングされたトリガの時までハイバーネートすることができる。イベントドリブンのイベントコンポーネント１３０も、継続的に動作することによってイベントソースを監視することができる。その後、収集に関する特定の判断基準を満足するデータの場合に、イベントコンポーネントは、イベントの発生を収集するか示すことができる。その代わりに、イベントドリブンのイベントコンポーネント１３０が、コールバック関数または他の外部刺激に応答してのみ動作することができる。この外部関数は、その後、収集すべき有効なイベントデータがあるかどうかを判定し、そのようなデータを収集する手段としてイベントコンポーネント１３０を使用する。イベントコンポーネント１３０が、外部イベントソースからデータを収集したならば、イベントコンポーネント１３０は、そのデータをイベントテーブルに書き込み、そのイベントテーブルをデータベース１５０に保存することができる。
【００３２】
イベントの収集に使用される方法またはシステムが何であるかにかかわらずに、効率のために、バッチでイベントを書き込み、処理することができることを諒解されたい。本明細書で一般的に定義されるバッチは、グループとして処理されるデータ（例えば、イベント、プリファレンス）のセットとすることができる。グループまたはバッチのサイズは、システムセットアップ中に開発者が判定し、指定することができ、および／または例えば、コントロールパネルを介してユーザが指定することができる。
【００３３】
本発明の一態様に従ってコンテキストアナライザ１４０によって収集される情報は、このアナライザによって判定されるコンテキスト情報を含む。コンテキスト情報は、アナライザ１４０によって、本明細書の後のセクションで詳細に説明するように、１つまたは複数のコンテキスト情報ソース（図示せず）に基づいて、ユーザの位置および注意状況を識別することによって判定される。例えば、コンテキストアナライザは、ユーザの自動車またはセル電話機の一部である全世界測位システム（ＧＰＳ）を介して、ユーザの実際の位置を正確に判定できる場合がある。アナライザは、静的モデルを使用して、バックグラウンド査定および／または日のタイプ、時刻、ユーザのカレンダ内のデータ、およびユーザのアクティビティに関する観察などの情報の検討を介して収集される観察を考慮することによって、ユーザが注意の所与の状態である可能性を判定することもできる。その後、注意の所与の状態を、ユーザ定義プリファレンスに関するイベントまたは条件として使用することができる。
【００３４】
プリファレンス実行エンジン１６０を、アクション処理にも用いることができる。プリファレンスロジックは、実際には結果の組を作るだけであるが、これを、その代わりに、本明細書で、これがそのような結果の共通の影響なので、アクションと呼ぶ。アクションを実行するのにプリファレンス実行エンジン１６０を使用することは、アクションを実行できる形の１つにすぎない。アクションは、システム１００からプリファレンス結果を単純に取り出し、それらに作用するアプリケーションによって実行することもできる。システム１００の一部としての実行エンジンによるアクションの実行は、アクティブエージェントの特色を有するが、アプリケーションによるアクションの実行は、受動的判断ロジックの特色を有する。したがって、システム１００は、システム１００がイベントコンポーネント１３０に関するイベント取り出しおよび処理に関するホスティングサービスを提供する形に似た形でアクションを取り出し、実行できるアプリケーションアクションハンドラ用のホスティングサービスを提供することができる。さらに、本発明の一態様によれば、データに近いアクション（例えば、特定のフォルダへの電子メールの移動）は、プリファレンス評価と同期してならびに同一トランザクションの一部として実行エンジン１６０によってシステム１００内で実行することができることを諒解されたい。
【００３５】
システム１００のプリファレンス実行エンジン１６０は、なかんずく、プリファレンスを処理し、評価する。プリファレンスは、イベントの発生によってトリガされる、エンドユーザ定義のルールである。システム１００によってサポートできる２つのアクティベーションモデルすなわち、同期および非同期がある。同期アクティベーションモードでは、イベントサブミッションとプリファレンス評価の間にとるに足らない遅延がある。すなわち、プリファレンス評価は、イベントサブミッションに対する応答が返される前に完了することができる。対照的に、非同期アクティベーションモードでは、イベントサブミッションの完了とプリファレンス評価の完了の間に大きい遅延がある。例えば、非同期アクティベーションを実装する１つの方法によれば、サブミットされたイベントは、操作できるようになるまでキューに入れられる。システム１００は、一方または両方のモデルのアクティベーションをサポートすることができる。さらに、本発明の態様によれば、同期挙動または非同期挙動を、バッチサイズおよび処理に使用可能な時間を含むがこれに制限されない複数の考慮事項に従って、バッチサブミッション中に動的に選択することができる。プリファレンス処理のもう１つの態様に、分離およびトランザクション境界が含まれる。例えば、単一のバッチイベントに関連するプリファレンスの処理は、トランザクション的とすることができる。その代わりに、多数のイベントバッチを、１つのトランザクション単位として一緒に処理することができる。システム１００は、上のモデルシナリオの一方または両方をサポートすることができる。さらに、プリファレンス実行エンジン１６０は、イベントサブミッションおよびプリファレンス処理のトランザクションスコープを処理する。システム１００は、次の２つのモデルの一方または両方をサポートすることができる。第１に、イベントサブミッションおよびプリファレンス処理が、同一のトランザクションを共有でき、これによって、一緒に実行されることが可能である。そうでない場合に、イベントサブミッションおよびプリファレンス処理を、異なるトランザクションで行うことができる。
【００３６】
本発明の態様によれば、実行エンジン１６０およびシステム１００は、軽いおよび／または重い情報エージェントまたはプリファレンスアプリケーションの両方をサポートすることができる。軽いアプリケーションは、短い待ち時間、小さいデータベースフットプリント、および小さいワーキングセットを必要とするアプリケーションである。高いスループットおよびスケーラビリティは、軽いアプリケーションのファーストオーダー要件ではない。重いアプリケーションは、高スループット、スケーラビリティ、高い信頼性、厳しい正しさの保証、予測可能なクラッシュリカバリ、および簡単なマネージャビリティを必要とするアプリケーションである。短い待ち時間およびリソース消費は、重いアプリケーションについては最高優先順位でない。高性能サーバが、通常、重いアプリケーションを実行するが、軽いアプリケーションは、通常、パーソナルコンピュータおよびモバイルデバイスを含むがこれに制限されないより低い性能のシステムで使用される。したがって、実行エンジン１６０は、重いアプリケーションと軽いアプリケーションを区別できなければならず、特定のアプリケーションタイプに最も反応する形で実行するように変更を行えなければならない（例えば、高スループット対短待ち時間）。一般に、実行エンジンは、データベースフットプリント、コンポーネントアクティベーションの待ち時間、処理、メモリフットプリント、および永続プロセスに最も関係する。重いアプリケーションの実行は、（１）なかんずく、複数のデータベース、テーブル、ビュー、ストアドプロシージャ、およびユーザ定義関数をサポートするための大きいデータベースフットプリントの割り当て、（２）イベント収集、通知生成、および通知配布のための短いポーリング間隔、および（３）情報のバッチ処理を必要とする場合がある。軽いアプリケーションの実行は、これらが、（１）最小限のメモリおよびデータベースフットプリントを用いて使用でき、（２）イベント収集、通知生成、および通知配布（イネーブルされる場合に）により長いポーリング間隔を使用でき、（３）小さいバッチでまたは個別にイベントなどの情報を処理できるという点で、異なる。さらに、本発明の態様によれば、ホスティングされるイベントプロバイダおよびある通知配布が、システム応答時間と干渉する継続的に動作するプロセスを必要とするので、軽いアプリケーションでサポートされない場合がある。しかし、実行エンジン１６０が、使用可能なリソースおよびテクノロジの状態に応じてアプリケーション「軽さ」の増分的変動をサポートできるという点で柔軟であることを諒解されたい。
【００３７】
システム１００に、アクションコンポーネント１７０も含まれることに留意されたい。プリファレンスの成功裡の評価の際に、プリファレンス実行エンジン１６０は、アクションコンポーネント１７０を呼び出して、１つまたは複数の有効なプリファレンスに従うアクションを実行することができる。アクションは、データストア１５０に影響し（例えば、データを挿入し、削除し、または変更する）および／またはシステム１００内またはその外の他のコンポーネントおよびシステムに影響することができる。１つの特定のタイプのアクションが、ユーザ通知である。したがって、アクションコンポーネントは、通知コンポーネント１８０と共に図示されている。
【００３８】
図２を参照すると、通知コンポーネント１８０が詳細に示されている。通知コンポーネント１８０に、フォーマッタ２７２および配布プロトコル２７４が含まれる。通知コンポーネント１８０は、入力として生の通知データを受け取り、最終的ユーザデバイス（例えば、コンピュータ、ＰＤＡ、携帯電話機）に到着するフォーマットされた通知を出力する。生の通知データが通知コンポーネント１８０によって受け取られた後に、通知が、宛先デバイス用および多分ユーザの好みの言語用にフォーマットされた可読通知に変換され、配布プロトコル２７４を介してデバイスに送られる。コンテンツフォーマッティングは、１つまたは複数のコンテンツフォーマッタコンポーネント２７２によって処理されるタスクである。コンテンツフォーマッタ２７２は、配列にパッケージ化された通知データを入力としてとる。標準的な配布に関して、この配列に１つの要素だけが存在しなければならず、この要素に、単一の通知レコードに関する情報が含まれる。複数の通知を単一のメッセージでサブスクライバに送信することを試みるダイジェスト配布に関して、配列に複数の要素が存在することができ、この要素のそれぞれに、１つの通知からのデータが含まれる。コンテンツフォーマッタ２７２は、例えば、通知データに含まれる受信者情報を使用して、適当なフォーマッティングを決定することによって、表示のためにデータをフォーマットする。さらに、ダイジェスト配布が使用される場合に、コンテンツフォーマッタ２７２は、通知情報を適当に集約する責任も負う。内部的には、コンテンツフォーマッタ２７２は、適当なスキームを使用して通知をフォーマットすることができる。例えば、そのようなスキームは、基本的なストリング操作を使用することなどの単純なものとすることができ、あるいは、ＸＳＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｓｔｙｌｅｓｈｅｅｔ  Ｌａｎｇｕａｇｅ）変換またはＡＳＰ．ＮＥＴレンダリングの使用などの複雑なものとすることができる。コンテンツフォーマッタがその作業を完了した場合に、コンテンツフォーマッタは、フォーマットされたデータを含むストリングを出力する。ストリングは、生成できるある通知ヘッダ情報と共に、配布プロトコルコンポーネント２７４に渡される。
【００３９】
通知配布は、配布プロトコル２７４を介して達成することができる。通知のバッチが使用可能になる場合に、通知コンポーネント１８０は、通知のサブスクライバデータを読み取って、正しいフォーマッティングを決定する。通知コンポーネント１８０は、次に、例えば、．ＮＥＴ  ＡｌｅｒｔｓサーバまたはＳＭＴＰサーバなどの配布サービスに、配布プロトコル２７４によって通知を送ることができる。具体的に言うと、アプリケーションが走っている場合に、通知コンポーネント１８０は、各通知を読み取って、サブスクライバ配布デバイスおよびロケールを入手することができる。次に、ディストリビュータは、デバイスおよびロケールの組合せを特定のフォーマッタオブジェクトに一致させて、最終的な通知を生成する。通知自体に、生の通知データ、フォーマッティング時に計算されたデータ、ならびにコンテンツフォーマッタ２７２によって指定されるテキストの組合せを含めることができる。これらのオプションは、プロフェッショナルでユーザフレンドリな通知テキストと、ウェブリンクおよびブランディング情報を含めることを可能にする。
【００４０】
システム１００は、内部通知（例えば、ポップアップ通知）を処理することができるが、システム１００は、外部サードパーティデバイスへの通知の最終的な配布を扱う必要がない。その代わりに、システムは、配布チャネル（図示せず）を使用することができ、この配布チャネルは、電子メールゲートウェイまたは．ＮＥＴ  Ａｌｅｒｔｓサーバなどの配布サービスへのパイプと考えることができる。具体的に言うと、配布チャネルは、プロトコルおよびエンドポイントアドレスからなるものとすることができる。システム１００は、配布プロトコル２７４を構成して、通知コンポーネント１８０から、通知を受信者に送信する外部配布システムへのパイプラインを提供することができる。次に、通知コンポーネントは、配布プロトコルコンポーネント２７４を使用して通知をプロトコルパケットにパッケージ化し、その通知を１つまたは複数の配布チャネルに送信する。配布チャネルは、その後、そのパケットを外部配布サービスに提示し、この外部配布サービスは、最終的に、通知を所期の受信者に送信することができる。
【００４１】
情報エージェントアプリケーション
図３を参照すると、本発明の態様による情報エージェントアプリケーション３００が示されている。アプリケーション３００は、システム１００の開発の単位であり、論理スキーマ３１０、ユーザインターフェース３２０、判断ロジックコンポーネント３３０、イベントプログラミングコンポーネント３４０、およびタスクスケジュールコンポーネント３５０を含む。論理スキーマ３１０は、エンドユーザが一緒にすることができる図式化された論理の構成ブロックまたはテンプレートを定義する。スキーマ開発者は、論理スキーマ３１０ならびにデフォルト挙動および例外が発生した場合の挙動を構成する責任を負う。実際には、論理スキーマ３１０は、エンドユーザロジックの実際の表現力を制限し、これによって、訓練されないエンドユーザが実際にアプリケーションを「プログラム」することを実用的で実行可能にする。論理構成ブロックに、プリファレンスクラス、条件クラス定義のセット、および潜在的な結果またはアクションのセットを含めることができる。条件およびアクションは、関連するアプリケーション３００および／またはユーザコンテキストの機能性に関係することができる。さらに、本発明の態様によれば、論理スキーマ３１０を、ＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）を使用して定義できることを諒解されたい。
【００４２】
本発明の態様によれば、論理スキーマ３１０をそのために定義できる２種類の構成ブロックすなわち、テンプレート化されたＢｏｏｌｅａｎ関数を定義する条件クラスおよびテンプレート化されたプロシージャを定義するアクションクラスがある。プリファレンスクラスは、情報エージェントスキーマ開発の単位である。プリファレンスに、許容される条件クラス（例えば、ＩｓＦｒｏｍ（Ｘ）、ＩｓＴｏ（Ｙ））およびアクションクラス（例えば、ＭｏｖｅＴｏＦｏｌｄｅｒ（Ｚ）、Ｄｅｌｅｔｅ（））のセットが含まれる。さらに、すべてのプリファレンスが、アクションを開始するために特定のイベントクラスまたはトリガ（例えば、ＥｍａｉｌＥｖｅｎｔ）に関連する。論理スキーマ３１０が指定された後に、スキーマ３１０を、コンパイラ１２０によってコンパイルすることができ、スキーマ３１０は、データストア１５０内の正規化されたシステムメタテーブルで永続することができる。さらに、コンパイル期間中に、プリファレンスを評価できるストアドプロシージャを作成することができる。スキーマ論理３１０およびプロシージャの両方を、後のアクセスおよび実行のために図式化データストア１５０に保管することができる。その後、ユーザが、指定しようとする場合に、プリファレンスを論理スキーマ３１０と比較して、その形式的準拠を検証し、その後、データストア１５０内、例えば、プリファレンスの１つまたは複数のテーブルに保管することができる。適当なイベントが発生する場合に、システム１００は、コンパイル時中に作成されたストアドプロシージャを実行することによって、適当なプリファレンスが評価されることを保証することができる。本発明の態様によれば、ストアドプロシージャは、セット指向の形で、インデクシングおよび重複除去（下で説明する）などの技法を使用して、複数のプリファレンスを一緒に効率的に評価することができる。
【００４３】
ユーザインターフェース３２０は、プリファレンスオーサリングインターフェースまたはプリファレンスプログラミングインターフェースをエンドユーザに提示する。エンドユーザは、訓練された開発者ではなく、したがって、標準的な手続きプログラミングまたはスクリプティングは、ユーザがロジックを指定するための実行可能なオプションではない。したがって、論理は、例えば、ユーザインターフェース３２０を介する、クリックアンドドラッグまたはコピーアンドペーストの形で視覚的に表現し、エンドユーザに提示することができる。ユーザインターフェース３２０を、アプリケーション３００内のツールバーまたは完全に独立のグラフィカルユーザインターフェース（ＧＵＩ）とすることができることに留意されたい。さらに、アプリケーション３００が、ユーザインターフェース３２０を含むものとして図示されているが、アプリケーション３００が、プリファレンスを定義するそれ自体のユーザインターフェースを有する必要がないことを諒解されたい。アプリケーションは、論理作成のためにオペレーティングシステムまたはアプリケーション固有のユーザインターフェースを使用するように設計することができる。
【００４４】
アプリケーション３００に、プリファレンスまたは様々な機能性のプログラムを作るのにエンドユーザが使用できる３つのコンポーネントすなわち、判断ロジックコンポーネント３３０、イベントプログラミングコンポーネント３４０、およびタスクスケジュールコンポーネント３５０も含まれる。判断ロジックコンポーネント３３０は、エンドユーザが、判断ロジック（別名エンドユーザロジック）を定義できるようにする。アプリケーションは、定義されたエンドユーザロジックによって様々な決定を制御させることができる。例えば、エンドユーザは、どの場合に、いつ、どのように警告を画面にポップアップし、ユーザに割り込むかを指定することができる。アプリケーションは、エンドユーザが判断ロジックをアタッチできるイベントを公開することもできる。例えば、電子メールアプリケーションは、新しいメールがフォルダに到着する時に必ずイベントを送出することができる。イベントプログラミングコンポーネント３４０は、エンドユーザが、例えば、メッセージの内容およびユーザのコンテキストに依存して発生し得る挙動を指定するプリファレンスまたはルールをアタッチできるようにする。ルールの条件は、他のアプリケーションからのデータ（例えば、送信者が同一のワークグループ内にいるかどうかを検査するためにアクティブディレクトリ）にアクセスすることができ、アクションは、本発明の一態様に従って、他のアプリケーションをもたらすか別のイベントを送出することができる。タスクスケジュールコンポーネント３５０は、エンドユーザが、アドホックなタスクまたは事前定義のタスクをイベントオカレンスにアタッチできるようにする。例えば、新しい顧客苦情が生じる場合に、エンドユーザは、その苦情を処理するために事前定義のワークフローを開始することを選択することができる。
【００４５】
判断ロジックコンポーネント３３０は、エンドユーザが、開発者によって提供される条件テンプレートおよび結論テンプレートを組み合わせることによって、判断ロジックプログラムまたはエンドユーザロジックプログラムを記述できるようにする。判断ロジックは、「ＩＦ（条件）ＴＨＥＮ（結果）」プリファレンスまたはルールを使用することによって指定することができる。このタイプのロジックは、エンドユーザ指定に特に適当である。というのは、絶対的にプログラミング経験がまったくないエンドユーザであっても、そのようなルールをすぐに理解でき、作成できるからである。例えば、次の例を検討されたい：ＩＦ（ＴｈｅＤｏｇＢａｒｋｓ（犬がほえる））ＯＲ（ＴｈｅＢｅｅＳｔｉｎｇｓ（ハチが刺す））ＴＨＥＮ（ＩＦｅｅｌＳａｄ（私は悲しい））。このルールは、非開発者が、および子供であっても、正しいユーザインターフェースを与えられれば理解でき、表現できるものである。このタイプのＩＦ−ＴＨＥＮ論理プログラミングは、少なくとも推理および言葉によるコミュニケーションという人間の概念と一致するので、エンドユーザ指定に適当である。単一のルールのセマンティクスは、宣言的であり、明確に理解される、すなわち、結果は、条件が真の場合に限って真である。さらに、エンドユーザが、アクティブコンテキストでプリファレンスロジックを適用することは、直観的である。結果は、自明の理の単純な陳述ではなく、行われるアクションになる。例えば、ＩＦ（ＴｈｅＤｏｇＢａｒｋｓ（犬がほえる）ＯＲ  ＴｈｅＢｅｅＳｔｉｎｇｓ（ハチが刺す））ＴＨＥＮ（ＴｈｉｎｋＡｂｏｕｔＲａｉｎｄｒｏｐｓＯｎＲｏｓｅｓ（レインドロップスオンローズという曲について考える））である。単一のＩＦ−ＴＨＥＮルール内であっても、許容される表現力の豊かさの様々な度合がありえる。前の例は、おおむね、命題論理に対応する。命題論理は、単純な真／偽命題を組み合わせて、論理ステートメントを作ることができるという概念に基づく。しかし、述部論理、制約論理、および再帰を含むがこれに制限されない、平均的なエンドユーザが指定するには複雑すぎる可能性がある論理のより豊かな形を、本発明と共に使用することもできる。
【００４６】
プリファレンスは、ユーザインターフェース（例えば、コントロールパネル、ツールバー）を介して指定することができる。スキーマ開発者は、条件ロジックの構成ブロックとして基本的な述部のセットを提供することができる。エンドユーザは、その後、適当な条件を選び、適当な場合にパラメータ値を割り当て、Ｂｏｏｌｅａｎ演算子（例えば、ＡＮＤ、ＯＲ、ＮＯＴ）を用いてそれらを組み合わせることができる。同様に、エンドユーザは、適当な結果を選び、適当な場合にパラメータ値を割り当てることができる。エンドユーザ指定のプログラムの豊かさは、開発者によって提供される図式化されたロジックに由来する。これらの条件テンプレートおよび結果テンプレートは、エンドユーザアプリケーションの構造化データを含む、様々な情報を査定することによって、その内部ロジックにおいて豊富なものとすることができる。すべての条件テンプレートまたは結果テンプレートが、パラメータリストを記述したスキーマを有することができる。エンドユーザは、適当なパラメータ値を単純に提供することによって、これらの構成ブロックを使用することができる。
【００４７】
ここまでで説明したものは、情報エージェントシステム１００の受動的使用であり、より能動的なスタイルを、下で説明する。システム１００の受動的使用によれば、アプリケーションは、適当なステージで判断ロジックを呼び出し、必要なパラメータを供給する責任を負う。アプリケーションは、結果に作用するために別のアプリケーションを呼び出す責任を負うこともできる。さらに、プログラムインフラストラクチャであるシステム１００が、プリファレンスを評価し、複数のプリファレンスの間の衝突を処理し、結果の正しいセットを判定するインタープリタ（図示せず）をも必要とする場合があることに留意されたい。
【００４８】
イベントプログラミングコンポーネント３４０は、情報エージェントアプリケーション３００に、少なくとも３つの機能を提供する。第１に、イベントプログラミングコンポーネント３４０は、エンドユーザプログラムのフックとして働くことができる、図式化された情報イベントのセット（例えば、スキーマ開発者によって定義される）を提供することができる。各イベントは、それと共に、構造化されたデータを伝えることができる。イベントインスタンスキャプチャの複数の機構がある（例えば、イベントサブミッション用のＡＰＩ）。情報イベントのいくつかのサブクラスもある。イベントの１つのサブクラスが、図式化データストア１５０内で変化するデータに対応する。したがって、イベントプログラミングコンポーネント３４０は、ストア内のデータ変化にアクセスし、図式化された変化イベントとしてこれを使用可能にする機構を提供することができる。イベントのもう１つのサブクラスは、再帰するタイマイベントに対応することができ、このイベントは、スケジューリングされたプリファレンスアクティビティに重要になる可能性がある。イベントプログラミングコンポーネント３４０は、エンドユーザ「ハンドラ」ロジックを、指定されたイベントの発生に関連付ける能力も提供することができる。さらに、イベントプログラミングコンポーネント３４０は、イベントを取り込み、適当な判断ロジックを適用し、判断結果を実行するためにアクションハンドラを呼び出すサービスを提供することができる。
【００４９】
イベントプログラミングコンポーネント３４０は、判断ロジックコンポーネント３３０と相互作用して、追加の機能性を提供することができる。例えば、エンドユーザは、判断ロジックコンポーネント３３０を使用することによって、新しいイベントが到着する時に繰り返して適用される持続的な判断ロジックをセットアップすることができる。したがって、システムおよび／またはその上で走るアプリケーションは、すべてのトリガするイベントが適当な判断ロジックの評価を引き起こすという点で、アクティブになることができる。具体的に言うと、トリガするイベントは、判断ロジックへの入力を形成することができ、プリファレンスロジック評価の結果は、イベントプログラミングコンポーネント３４０がエンドユーザの代わりに実行できるアクションを形成することができる。さらに、アクションは、その後にイベントプログラミングコンポーネント３４０によってさらなるロジックを実行させる新しいイベントを送出することができる。その結果、アドホックなチェーニングされたイベントプログラミングという概念がある。
【００５０】
タスクスケジュールコンポーネント３５０は、エンドユーザタスクスケジュールまたはワークフローを管理する。本明細書で使用されるスケジュールは、その間に特定のシーケンシングまたはステージングを有する、タスクの編成されたセットである。タスクの全体を実行することの目的は、通常は、ある実世界の目的、例えば、４人の人との会議のスケジューリングを達成することである。会議の例では、スケジュールに含まれるタスクに、なかんずく、最初の会議要求を送り出すことと、肯定および否定の応答を処理することを含めることができる。ワークフローは、ビジネスプロセスオートメーションで一般的であるが、本発明に関して説明されるタスクスケジュールまたはワークフローは、エンドユーザアクティビティに関連する（例えば、会議のスケジューリング、文書の再検討、要求の委任）。これらのワークフローの多くが、単純なプロセスであるが、これらは、カスタマイズ可能であり、エンドユーザに透過的である。
【００５１】
タスクスケジュールコンポーネント３５０は、判断ロジックコンポーネント３３０およびイベントプログラミングコンポーネント３４０の両方と相互作用し、これらによって提供される機能性を活用することができる。イベントプログラミングコンポーネント３４０は、タスクスケジュールを呼び出すための理想的なフックを提供する。例えば、作業要求を含む新しいメールの到着が、タスクスケジュールを開始することができる。一部のタスクスケジュールは、明確なプロセスフローに関して硬直している。多数の他のタスクスケジュールは、柔軟であり、エンドユーザが異なるパスの間で選択することを可能にする。例えば、会議要求が、複数の招待された人によって拒絶される場合に、その会議を、再スケジューリングするか、その代わりに会議を進行することができる。これは、エンドユーザプリファレンスおよび判断ロジックコンポーネント３３０を使用するのによい領域である。さらに、本発明の代替の態様によれば、スケジューリングに変更への反応および適当なアクションの呼び出しが含まれるので、タスクスケジュールコンポーネント３５０をイベントプログラミングコンポーネント３４０に組み込めることに留意されたい。要するに、タスクスケジュールの一部は、開発者によってハードコードされる可能性があるが、フローを、時々エンドユーザプログラミングを介して自動化される明示的ユーザ判断によって構成される、動的なものにすることによって、かなりの価値が追加される。
【００５２】
本明細書で説明する情報エージェントの概念に、少なくとも２つの中央要素がある。第１に、アプリケーション挙動を制御する判断ロジックを提供するエンドユーザの能力が、重要である。これは、単純に、アプリケーションのエンドユーザプログマビリティであり、実際には、エンドユーザの代わりに働くエージェントを伴わない。これを、本明細書では、エンドユーザロジックの受動的呼び出しと称する。第２に、情報エージェント概念の重要な要素が、エンドユーザがアクティブである判断ロジックを提供する能力である。アクティブである判断ロジックは、適当な情報イベントが発生する場合に繰り返して適用することができ、これによって、エンドユーザの代わりにソフトウェアエージェントとして働く。両方の場合で、判断ロジックは、通常はコンテキスト的であり、ユーザのコンテキストおよびアプリケーションの状態に依存する。この２つのコンテキストカテゴリ内の様々な種類のシナリオを、下で説明する。さらに、情報エージェントが引き受けることのできる異なる「ペルソナ（ｐｅｒｓｏｎａ）」の形のエンドツーエンドシナリオも説明する。
【００５３】
エンドユーザロジックの受動的呼び出しの１つの例が、情報エージェントを使用してユーザの割込みを制御するオペレーティングシステムである。あるアプリケーションが、スクリーンにサウンドと共にポップアップを上げることを望む時に、必ず、オペレーティングシステムは、ＡＰＩを使用して、情報エージェント判断ロジックコンポーネントを呼び出して、発生すべきものを決定する。ディスプレイ、遅延、削除、および転送を含む、判断ロジックコンポーネントによって明らかにされる可能性がある複数の可能な結論がある。判断ロジックコンポーネント３３０が何をすべきかを伝えたならば、オペレーティングシステムは、実際の判断を実施することができる。
【００５４】
判断ロジックコンポーネント３３０は、普通のプログラムのオプションをカスタマイズするのに使用することもできる。例えば、普通の電子メールプログラムは、受け取ったものの読み取り、署名の適用、およびメール優先順位に関するオプションを提供する。受け取ったものの読み取りによれば、しばしば、受け取ったものの読み取りをイネーブルするか否かを示すチェックボックスがある。判断ロジックコンポーネント３３０は、このオプションをカスタマイズして、重要なメッセージまたは使用者に送られたメッセージだけの受け取ったものの読み取りをイネーブルすることができる。さらに、ユーザは、通常、進行中のメッセージに署名を適用することができるが、判断ロジックコンポーネント３３０を使用することによって、この動作を、所期の受信者に応じてメッセージに署名を付加することによって、より価値のあるパーソナライズされたものにすることができる。最後に、電子メール優先順位レベルは、通常は、送信者によって決定され、設定される。判断ロジックコンポーネント３３０を使用することによって、メール優先順位を、例えば、受信者の現在のコンテキストに応じて、受信者によって決定することもできる。さらに、エンドユーザロジックを使用して、上記などの状況で行うべきこと（例えば、署名を付加する）を決定するだけではなく、アクションの内容をどうすべきか（例えば、どの署名を実際に付加するか）を決定することもできる。
【００５５】
判断ロジックコンポーネント３３０を介するエンドユーザロジックの能動的呼び出しは、複数の情況で使用することができる。例えば、能動的ロジックを使用して、カメラからダウンロードされる時に写真を分類する、または受信時に編成ルールに従って電子メールを分類するなど、データを編成することができる。能動的ロジックを使用して、新しいメールが到着し、受信者が自分の机にいない場合に携帯電話機に転送するなど、変化に反応することもできる。能動的ロジックを使用して、例えば、ユーザが電話に出られない場合にユーザの電話に応答し、ユーザが次に電話に出られる時を応えるなど、通信を機能強化することもできる。さらに、能動的ロジックを使用して、例えば、旅の目的地で悪天候が期待される場合にユーザが通知を受けられるようにするなど、公表される情報にサブスクライブすることができる。さらに、能動的ロジックを使用して、コンテキストを維持することができる。例えば、ユーザが、異なる位置で会議に加わり、去る時に、適当にコンテキストを更新することができる（例えば、リモートまたはローカル、ビジーまたはフリー）。
【００５６】
情報エージェントは、実際の人間のエージェントがユーザのために行うものと同じ様々な役割を演じることができる。したがって、情報エージェントは、通信を機能強化する秘書、情報を編成する司書、プリンシパル／ユーザが好機を知ることを保証するサービスエージェント、プリンシパル／ユーザが困らないことを保証する付き添い、およびプリンシパル／ユーザが外見がよく、精神状態がよいようにする従者を含むがこれに制限されない様々なペルソナを有することができる。秘書として、情報エージェントは、プリンシパル／ユーザが電話に出られない場合の留守番電話、電話に出られないユーザのボイスメールへの発呼者の転送、電話が切れたことを示すユーザへのインスタントメッセージングなど、様々な機能を実行することができる。司書として機能する場合に、情報エージェントは、デジタル写真および電子メールを編成することができる。サービスエージェントとして、情報エージェントは、例えば、株式または不動産を売買する機会についてプリンシパルに知らせ続けることができる。付き添いとして働く情報エージェントは、銀行口座の残高が最小残高を下回る場合にプリンシパルに知らせ、クレジットカード限度に近い場合にプリンシパルに知らせ、請求が期限に支払われることを保証するために通知を提供し、および／またはコンピュータのバッテリまたは満杯のディスクについてプリンシパルに警告することができる。従者として、情報エージェントは、重要な顧客からの着呼に関連するすべての文書および電子メールを引き上げ、および／または当惑させる通知がプレゼンテーションの途中でポップアップしないことを保証することができる。
【００５７】
論理スキーマ
図４を見ると、本発明の態様による例示的な論理スキーマ４００が示されている。論理スキーマ４００に、条件クラス４１０、アクションクラス４１５、イベントクラス４２０、プリファレンスクラス４２５、バインディング４３０、クロニクル４３５、衝突解決４４５、明示的実行順序付け４５０、必要条件およびアクション４５５、テンプレート４６０、ならびにスケジューリングされたプリファレンスおよび再帰プリファレンス４６５が含まれる。例示的な論理スキーマ４００および前述のスキーマコンポーネントは、説明を単純にするために提供される。したがって、論理スキーマ４００に、前述のコンポーネントのすべて、そのサブセット、および／または図示されていない追加スキーマコンポーネントを含めることができることを諒解されたい。前に述べたように、スキーマ開発者は、エンドユーザが一緒にすることができる図式化された論理構成ブロックを定義する。２種類の構成ブロックが、条件クラス４１０およびアクションクラス４１５である。条件クラス４１０は、テンプレート化されたＢｏｏｌｅａｎ関数を定義することができ、アクションクラス４１５は、テンプレート化されたプロシージャを定義することができる。プリファレンスクラス４２５は、情報エージェントスキーマ開発の単位である。プリファレンスクラス４２５に、なかんずく、許容される条件クラスおよびアクションクラスのセット、バインディング４３０、衝突解決４４５、および必要条件４５５を含めることができる。さらに、すべてのプリファレンスクラス４２５を、特定のイベントクラス４２０に関連付けることができ、このイベントクラス４２０は、プリファレンスに関するトリガするイベントを定義する。次は、情報エージェント電子メールアプリケーションのプリファレンスクラスの例である。
【００５８】
【表１】
2007518151.tif 000003
【００５９】
プリファレンスは、エンドユーザロジックの単位である。プリファレンスは、「ＯＮ（イベント）ＩＦ（条件）ＴＨＥＮ（アクションセット）」の形の論理ステートメントとすることができる。したがって、すべてのプリファレンスが、次のプロパティを有しなければならないが、それを要求されない。第１に、プリファレンスは、プリファレンスクラスに属さなければならない。第２に、プリファレンスは、あるユーザまたはプリンシパルによって所有されなければならない。第３に、条件は、条件クラスの１つまたは複数のインスタンスを組み合わせる宣言的Ｂｏｏｌｅａｎ式でなければならず、ここで、すべての条件インスタンスが、条件クラスのパラメータ値を定義する。最後に、アクションセットは、アクションクラスのセットでなければならない。すべてのアクションインスタンスが、アクションクラスのパラメータ値を定義する。例えば、：
【００６０】
【表２】
2007518151.tif 000004
【００６１】
エンドユーザは、イベントハンドラを定義することによって「プログラムする」ことができる。各イベントハンドラは、同一のプリファレンスクラスのプリファレンスのセットによって定義され、したがって、同一のイベントによってトリガされる。例えば、：
【００６２】
【表３】
2007518151.tif 000005
【００６３】
その後、特定のイベントが発生する（例えば、電子メールが到着する）場合に、複数のプリファレンスが有効な条件を有する可能性があり、複数のアクションの実行の可能性につながる。様々な衝突解決機構を、下で説明するように適用することができる。
【００６４】
さらに、すべての条件が、単純に、その呼び出しパラメータを伴うＢｏｏｌｅａｎ関数であることを諒解されたい。本発明の一態様によれば、アプリケーション境界をまたぐために、図ロジックが必要である。したがって、条件は、複数の異なるアプリケーションによって作られたデータを見ることができる必要がある。例えば：
【００６５】
【表４】
2007518151.tif 000006
【００６６】
上の例のすべてが、ユーザコンテキストを扱う。ユーザコンテキストは、コンテキストアナライザ１４０（図１）によって判定でき、情報エージェントアプリケーションによる使用のためにデータストア１５０（図１）に保管することができる。したがって、「Ｂｏｏｌ  ＩｓＯｎｌｉｎｅ（Ｘ）」などの関数は、渡された人Ｘの識別およびコンテキストアナライザによって判定されるその人のプレゼンスコンテキストに基づいて、真または偽を返すことができる。
【００６７】
上の例を続けると、ＩｎＢｏｘＰｒｅｆｅｒｅｎｃｅＣｌａｓｓなどのプリファレンスクラスのスキーマ開発者は、エンドユーザによる使用のために条件クラス４１０を提供する必要がある。これを行う複数の形がある。例えば、条件クラスを、ＩｓＯｎｌｉｎｅ（）とすることができる。この場合に、エンドユーザは、「ＩＦ（ＩｓＯｎｌｉｎｅ（Ｅｍａｉｌ．Ｓｅｎｄｅｒ））ＴＨＥＮ．．．」の形でプレゼンスを定義することができる。その代わりに、条件クラスをＳｅｎｄｅｒＩｓＯｎｌｉｎｅ（）とすることができ、その宣言で、スキーマ開発者が、これをＩｓＯｎｌｉｎｅ（Ｘ）にバインドし、ＸをＥｍａｉｌ．Ｓｅｎｄｅｒにバインドすることができる。したがって、エンドユーザは、「ＩＦ（ＳｅｎｄｅｒＩｓＯｎｌｉｎｅ（））ＴＨＥＮ．．．」としてプリファレンスまたはルールを定義することができる。本発明は、条件クラス４１０を指定する複数の形をサポートするが、上で説明した形に大きい相違があることに留意されたい。第１の形は、伝統的なプレディケーテッドカルキュラスルール形式（ｐｒｅｄｉｃａｔｅｄ  ｃａｌｃｕｌｕｓ  ｒｕｌｅ  ｆｏｒｍ）であり、ここで、ルールをオーサリングする人（例えばエンドユーザ）が、スキーマおよび変数バインディングについて推理する。第２の形は、より柔軟性が少ないが、エンドユーザが使用するために明らかにより単純である。したがって、条件クラス４１０は、スキーマ開発者がエンドユーザロジックの表現力を制限できる領域であり、これによって、未経験のエンドユーザが情報エージェントアプリケーションを「プログラムする」ことが、より実用的で実現可能になる。
【００６８】
短く言うと、スキーマ開発者が、プリファレンスクラス４２５をオーサリングする場合に、条件クラス宣言４１０のセットが作られる。各条件クラス宣言は、実装関数および、開発者定義の式によってバインドされるその関数へのパラメータを定義する。残りのパラメータは、プリファレンスをセットアップする場合にエンドユーザによってすべての条件インスタンスについて提供される定数である。アクションは、アクションクラス４１５のインスタンスである。各アクションクラス４１５は、パラメータを有するプロシージャである。条件と同様に、パラメータは、開発者によってバインドすることができ、あるいは、エンドユーザによって定数として割り当てることができる。さらに、イベントクラス４２０は、イベントの定義を提供する。イベントクラスは、開発者によって指定されるかエンドユーザによって割り当てられるイベントの情報内容を定義し、このイベントは、プリファレンス評価によってトリガされる。
【００６９】
本明細書全体を通じて注記されるように、本発明の態様によれば、エンドユーザは、経験のあるプログラマであることを期待されない。したがって、プリファレンスは、直観的な名前（例えば、ＥｍａｉｌＩｓＦｒｏｍ（））を有する条件に基づいて作成され、条件への引数は、単純なユーザ定義定数（例えば、Ｍａｒｙ）とすることができる。これによって、エンドユーザが、ＥｍａｉｌＩｓＦｒｏｍ（Ｍａｒｙ）によってトリガされるプリファレンスを記述できるようになる。しかし、ユーザが提供するストリング定数だけに基づく引数を有することは、制限的にすぎる。したがって、バインディング４３０を、プリファレンスクラス４２５の一部として論理スキーマ４００で指定して、プログラミングをエンドユーザにとって簡単にすると同時に、情報を取り出すことができるドメインを拡張することができる。スキーマ４００で指定できる、少なくとも３つのタイプのパラメータバインディングがある。第１に、定数を事前に定義する定数バインディングを指定することができる。定数バインディングの指定は、少なくとも、エンドユーザが定数を選択するか指定する必要がなくなるので、有益である。イベントにバインディングされた式を、条件およびアクションへの引数として提供される値にバインドすることもできる。具体的に言うと、イベントフィールドおよび定数を使用して値を計算する式を、定義することができる。例えば：
【００７０】
【表５】
2007518151.tif 000007
【００７１】
最後に、定数アクセッサを定義することができる。定数アクセッサは、ユーザが各オブジェクトを手動で指定しなければならないことの代わりに、条件およびアクションへの引数を提供するオブジェクトの名前付きグループである。
【００７２】
定数アクセッサは、様々なドメインをナビゲートし、そこから情報を取り出すことができるプリファレンスおよび条件を記述できるようにする非常に強力な定数である。これらの定数は、単純に、正しい情報すなわち定数の名前に関連するグループのメンバを見つけ、実体化するように動作する関数の上辺を飾る名前である。短く図５を見ると、本発明の態様による、定数値を取り出すシステム５００が示されている。システム５００に、アクセッサ入力コンポーネント５１０、リンクコンポーネント５２０、ならびに複数のドメイン５３０、５４０、および５５０（ＤＯＭＡＩＮ１からＤＯＭＡＩＮＮ、ただし、Ｎは１より大きい）が含まれる。アクセッサ入力コンポーネント５１０は、入力としてＭｙＦａｍｉｌｙ、ＭｙＣｏｗｏｒｋｅｒｓ、またはＭｙＦｒｉｅｎｄｓなどの定数を受け取り、その定数をアクセッサコンポーネント５２０に供給する。アクセッサコンポーネント５２０は、すべての可能なドメイン５３０、５４０、および５５０を検索して、試み、入力によって指定されるグループのメンバに関連する値を解決またはリンクするように動作する。本発明の一態様によれば、ドメイン５３０、５４０、および５５０は、図式化データストアに保管されたアプリケーションとすることができる。例えば、ドメイン５３０を、電子メールアプリケーションとすることができ、ドメイン５４０を、カレンダアプリケーションとすることができ、ドメイン５５０を、顧客アカウントアプリケーションとすることができる。したがって、アクセッサコンポーネント５２０は、定数（例えば、ＭｙＦａｍｉｌｙ）の値を判定することを試みて、電子メールアプリケーションまたはローカル化されたデータレジストリにアクセスすることができる。コンポーネント５２０が、そのドメインまたはローカル化されたデータレジストリで値を解決できない場合に、コンポーネント５２０は、定数値を判定するかすべての使用可能なドメインを検査し終えるまで、追加のアクセス可能なドメインを検査し続けることができる。一例で、アクセッサコンポーネントは、電子メールアプリケーションで次のようなデータを見つけることができる。
【００７３】
【表６】
2007518151.tif 000008
【００７４】
定数ＭｙＦａｍｉｌｙに関連するグループのメンバのＸＭＬ表現が、例示だけのために使用されていることに留意されたい。グループの母集団は、本発明によって多数の形で定義し、および／または実現することができる。したがって、アクセッサコンポーネント５２０は、電子メールアプリケーションから取り出したデータに基づいて、ＭｙＦａｍｉｌｙをＢｏｂ  Ｊｏｎｅｓ、Ｂａｒｂ  Ｊｏｎｅｓ、Ｍｉｃｈａｅｌ  Ｊｏｎｅｓ、およびＪａｓｏｎ  Ｊｏｎｅｓに解決するかリンクすることができる。しかし、アクセッサコンポーネント５２０は、他のドメインの検査を継続して、データの完全さおよび正確さを保証することができる。例えば、アクセッサコンポーネントは、カレンダアプリケーションで＜ＭｙＳｉｓｔｅｒ＞Ｊｅｎｎｉｆｅｒ  Ｊｏｎｅｓ＜／ＭｙＳｉｓｔｅｒ＞を見つけることができ、この値を、定数ＭｙＦａｍｉｌｙに関係する値のストリングに追加することができる。
【００７５】
これまでに述べた定数（例えば、ＭｙＦａｍｉｌｙ、ＭｙＣｏｗｏｒｋｅｒｓ、ＭｙＦｒｉｅｎｄｓ、ＭｙＦａｖｏｒｉｔｅ  Ｍｕｓｉｃｉａｎｓ）は、所与のユーザに関して定義されるので、ファーストオーダー定数と称する。アクセッサコンポーネント５２０またはアクセッサは、ユーザの識別または他の開始点のキーオフ（ｋｅｙ  ｏｆｆ）することができる。プリファレンスを使用して前に定義されたグループ（例えば、定数によって命名された）を組み合わせることによって、第Ｎオーダー定数をユーザが構成し、保存することができることに留意されたい。例えば、前置詞句のセマンティクスに似た機能性を提供する定数の名前を有するグループの組合せを検討されたい。例えば、ユーザは、ＦｒｉｅｎｄｓＯｆＭｙＦａｍｉｌｙまたはＥｍａｉｌｓＦｒｏｍＰｒｅｆｅｒｒｅｄＣｕｓｔｏｍｅｒｓＩｎＡｐｐｏｉｎｔｍｅｎｔｓＴｏｄａｙのようなグループを表す定数を構成し、保存することができる。別の展望から、定数式は、定数アクセッサとして表し、他の定数と組み合わせることもできるアイテムのフィールドに対する条件に類似する。
【００７６】
したがって、定数アクセッサは、異なるドメインにまたがるデータへのナビゲーションを提供する。図式化されたロジックとナビゲーション的アクセッサの組合せによって、非プログラマがクロスドメインプリファレンスを記述することが可能になる。さらに、比較的少数のアクセッサ制約に組み合わされた比較的少数の条件クラスは、そうでなければアプリケーション開発者によって予想される必要がある、多数の重要で強力な条件の指定を容易にする。
【００７７】
さらに、プリファレンスグループも指定できることに留意されたい。エンドユーザによって定義された判断ロジックは、プリファレンスの１つまたは複数のセットによって表される。したがって、プリファレンスグループを、関連するプリファレンスのグループのコンテナとして定義することができる。プリファレンスグループ内のプリファレンスは、（１）同一のプリファレンスクラスに属し、（２）一緒に評価することができ、その結果は、衝突解決の対象になる。さらに、プリファレンスグループ内のプリファレンスを、集合的にイネーブルし、ディスエーブルすることができる。プリファレンスの集合的なイネーブルおよびディスエーブルは、多数のシナリオで有用になる可能性がある。例えば、エンドユーザが、仕事場にいる場合にプリファレンスの１つのセットを有し、家にいる場合にプリファレンスの別のセットを有することができる。したがって、プリファレンスグループを、ユーザコンテキストに基づいてイネーブルまたはディスエーブルすることができる。
【００７８】
論理スキーマ４００に、クロニクル４３５も含めることができる。多数の情報エージェントアプリケーションが、分別のある判断を行うために、状態を維持することを必要とする。単純な例として、ニュース出版情報エージェントアプリケーションを検討されたい。エンドユーザは、興味のあるニュース記事をサブスクライブする。イベントフィードは、ニュース記事の安定したストリームを伝える。１つの問題が、わずかに異なる内容と同一のタイトルを有する同一の記事が複数回到着する場合があることである。このコンテキストでは、分別のある条件が、ＩｓＮｅｗＡｒｔｉｃｌｅ（）になる。この条件は、タイトルが前に見られたものでないことを検査することができる。もう１つの例は、更新の安定したストリームが、記事を速報にするかどうかを検査することである。このタイプの機能性をイネーブルするために、イベントが処理される際に状態を維持する必要がある。この状態は、アプリケーションヒストリの表現なので、本明細書では、この状態をクロニクルと呼ぶ。
【００７９】
情報エージェントスキーマ開発者は、クロニクルを定義することができる（例えば、リレーショナルデータベースのテーブルとして、またはオペレーティングシステムによって管理されるフォルダ内で）。より重要なことに、スキーマ開発者は、アプリケーション状態を更新するために、イベント処理のクリティカルなステージで実行することができるロジックを定義することができる。例えば、イベントが速報に対応するかどうかを計算するのに適当な時は、イベントが処理される前である。さらに、ニュース記事が処理され、その結果、同一タイトルの後続イベントが重複として示されるという事実を記録するのに適当な時は、イベントが処理された後である。さらに、クロニクルを使用して、アクションヒストリならびにイベントヒストリを記録することもできることに留意されたい。
【００８０】
開発者は、論理スキーマ４００内のプリファレンスクラス４２５の一部として、衝突解決コンポーネント４４５で衝突解決のプロシージャまたはロジックを指定することができる。イベントが発生する場合に、複数のプリファレンスがそのイベントと一致するならば、複数のアクションが起こることができる。したがって、実行の順序および／または最終的に行われるアクションを決定するシステムおよび方法が望まれる。複数アクションのトリガを扱う、少なくとも３つの形がある。第１に、スキーマ４００は、エンドユーザがアクションまたはプリファレンスの優先順位を定義することを可能にすることができる。例えば、エンドユーザは、すべてのプリファレンスに優先順位を割り当てることができる。さらに、エンドユーザは、あるプリファレンスに処理停止インジケータ（例えばフラグ）を割り当てることができる。したがって、あるイベントが複数のアクションをトリガする場合に、アクションを、優先順位の順序で実行することができる。さらに、その代わりに、複数のプリファレンスが、プリファレンスグループ内で一致する場合に、最高優先順位のプリファレンスを実行し、それ以外を破棄することができる。さらに、スキーマ４００は、インジケータを含むプリファレンスが他のプリファレンスと同時にトリガされる状況を扱うためにユーザが処理停止インジケータをあるプリファレンスにアタッチすることを可能にするなど、エンドユーザが衝突解決プロシージャを指定することを可能にすることができる。衝突を解決できるもう１つの形が、スキーマ４００内でアクションクラス優先順位を定義することである。したがって、スキーマ開発者は、アクションクラス優先順位を指定することができる。例えば、ＭｏｖｅＴｏＦｏｌｄｅｒアクションクラスに、Ｄｅｌｅｔｅアクションクラスより高い優先順位を指定することができる。同一アクションクラスの複数のアクションが同時にトリガされる場合に、他の衝突シナリオが生じる可能性がある。スキーマ開発者は、複数の衝突解決ロジックを定義して、このタイプの状況を処理することができる。例えば、所望のポップアップのボリュームをセットするアクションクラス（例えば、ＳｅｔＶｏｌｕｍｅ（））があると仮定する。さらに、あるイベントが、２つのアクション、ＳｅｔＶｏｌｕｍｅ（５０）およびＳｅｔＶｏｌｕｍｅ（７０）をトリガすると仮定する。この場合に、衝突解決コンポーネント４４５で定義される衝突ロジックを、２つのレベルの最小値、最大値、または平均に対応するアクションが行われるように定義することができる。
【００８１】
プリファレンス実行順序は、明示的実行コンポーネント４５０を介してスキーマ４００で指定することもできる。いくつかの情況で、あるプリファレンスのアクションが別のプリファレンスの条件に影響する可能性があるので、プリファレンスの明示的順序付けが必要である。例えば、電子メールプリファレンスに関して、あるプリファレンスを使用して、着信メッセージの優先順位を判断することができ、別のプリファレンスを記述して、メッセージの優先順位に反応し、それを操作する方法を決めることができる。エンドユーザプリファレンス作成者は、通常は、経験のないプログラマである。本発明の態様によれば、エンドユーザは、副作用を有し、したがって順序付け要件を有するプリファレンスまたはルールを記述する必要がない。スキーマ開発者が、エンドユーザから順序付け依存性を隠蔽できることが好ましい。これは、プリファレンスクラス順序付け、明示的チェーニング、およびプリファレンスグループ順序付けを含むがこれに制限されない複数の異なる形で達成することができる。プリファレンスグループ順序付けによって、スキーマ開発者が、別のプリファレンスクラスの前に実行されるように、あるプリファレンスクラスを順序付けることができる。前述の例では、メッセージプロパティ（例えば、優先順序）を確立するプリファレンスクラスが、メッセージに反応するプリファレンスクラスの前に来なければならない。本発明の態様によれば、エンドユーザに提示されるユーザインターフェースをペインに分割し、各プリファレンスクラスがそれ自体のペインを有するようにすることができる。明示的チェーニングによれば、スキーマ開発者は、新しいイベントを送出するアクションおよびその順序付けを指定することができる。したがって、プリファレンスクラスを、プリファレンスクラス順序付けではなく、アクション−イベントチェーニングを用いて実施することができる。さらに、スキーマ開発者は、プリファレンスグループを使用することによって実行順序付けを指定することができる。プリファレンスグループ順序付けを使用することによって、プリファレンスクラス順序付けと同一の機能が、より柔軟な形で提供される。例えば、すべてのプリファレンスグループは、その中に正確に１つのプリファレンスを有することができ、これは、プリファレンスの完全に順序付けられたシーケンシャルリストの同等物につながる。
【００８２】
「必要な」条件およびアクションを、必要条件およびアクションコンポーネント４５５を使用することによって、プリファレンスクラス４２５の一部としてスキーマ４００で指定することもできる。すべてのプリファレンスクラスに、必要条件および必要アクションが含まれる。必要条件および必要アクションを使用して、すべてのプリファレンスに共通するあるパターンを強制することができる。例えば、サーバで適用される馴染みのある電子メール処理の例で、Ｉｎｂｏｘプリファレンスに対する必要条件を、そのプリファレンスの所有者が電子メールの受信者でもあることとすることができる。
【００８３】
テンプレート４６０も、論理スキーマ４００で定義することができる。経験のないエンドユーザによるロジックのオーサリングを容易にするために、エンドユーザが採用し、利用するために、開発者またはサードパーティンがテンプレートを提供することができる。その結果、テンプレートが、エンドユーザが使用可能である場合に、システム１００は、プリファレンステンプレートの抽象化をサポートしなければならない。これは、単に、パラメータの一部を指定されていない、永続した完全なプリファレンス（条件式およびアクションが選択される）に対応することができる。
【００８４】
スケジューリングされたプリファレンスおよび再帰プリファレンスコンポーネント４６５を介して、スケジューリングされたプリファレンスおよび再帰プリファレンスを扱うようにスキーマ４００を定義することもできる。多くの情報エージェントアプリケーションが、再帰するスケジュールで評価されるプリファレンスを使用することを望む可能性がある。多数の例の１つに、すべての就業日の午後５時にサマリ状況を送信するプリファレンスが含まれる。本発明の一態様によれば、スケジューリングされ再帰する機能性を、２つの抽象化を使用することによってスキーマ４００で実施することができる。第１に、システム定義のイベントクラス（例えば、ＴｉｍｅｒＥｖｅｎｔ）を使用して、スケジューリングされたアクティビティのイベントフックを提供することができる。このイベントクラスは、様々な定期的な粒度に構成することができる。さらに、イベントに関連するデータに、現在時刻および前の発火時刻を含めることができる。第２に、すべてのスケジューリングされたプリファレンスに、次のような条件を含めることができる。
RecurrenceInWindow(RecurrenceSchedule, StartTime, EndTime)、ただし、
・  ＲｅｃｕｒｒｅｎｃｅＳｃｈｅｄｕｌｅは、エンドユーザ指定からキャプチャされる、所望の再帰するパターンを表し；
・  ＳｔａｒｔＴｉｍｅは、開発者によって、タイマイベントの前の時刻にバインドされ；
・  ＥｎｄＴｉｍｅは、開発者によって、タイマイベントの現在の発火時刻にバインドされる。
【００８５】
要するに、論理スキーマ４００に、エンドユーザプリファレンスの論理構成ブロックを提供するために、複数の異なるコンポーネントまたはセクションを含めることができる。スキーマは、任意の形、例えばＸＭＬファイルの形をとることができる。スキーマが完了したならば、スキーマを、データベース表現にコンパイルし、例えばデータストア１５０（図１）に保管することができる。スキーマファイルを、直接にオーサリングすることができ、あるいは、Ｖｉｓｕａｌ  Ｓｔｕｄｉｏなどのアプリケーションを使用して構成することができることを諒解されたい。したがって、システムコンパイラは、複数のスキーマエディタアプリケーションを使用して作成されたスキーマファイルをサポートできなければならない。
【００８６】
アプリケーション実行
情報エージェントアプリケーションの実行を、３つの別個のカテゴリすなわち、イベント処理、プリファレンス処理、およびアクション処理に副分割することができる。イベント処理は、イベントがどのようにキャプチャされ、それらのイベントがプリファレンスロジックをどのようにアクティベートするかを処理する。プリファレンス処理は、部分的に異なるプリファレンス処理モードに依存して、複数の異なる形で達成することができる。最後に、アプリケーション実行は、アクションをどのように処理するかの決定を伴う。
【００８７】
イベントは、システムＡＰＩ１１０（図１）を使用して、一部のアプリケーションによって、明示的にイベントをサブミットすることによってキャプチャすることができる。イベントは、個別にまたはバッチとして一緒にサブミットすることができる。イベントキャプチャに関する、次を含むがこれに制限されない多数のシナリオがある。
・  通常のアプリケーションロジックの一部として。例えば、Ｅｘｃｈａｎｇｅ  ＳＭＴＰプロバイダが、新しいＳＭＴＰメッセージを受信し、情報エージェントイベントを明示的に送出することができる。
・  データ変化から。例えば、データがデータストア１５０内で変化する場合にＩＡロジックのイベントがトリガされる。
・  オペレーティングシステムから。例えば、アプリケーションが、オペレーティングシステムおよび／またはそれに関連するランタイムをリスンし、特定のアクションの検出時にイベントを送出することができる。
・  情報エージェントプリファレンスから。あるプリファレンスのアクションが、プリファレンス評価にまたがるチェーニングにつながるもう１つのイベントを送出することができる。
・  ユーザが、イベントが生成されることを明示的に指定することができる。例えば、ユーザは、フォルダの各ファイルに対応するイベントを生成することを指定することができる。
【００８８】
さらに、システム１００が、より大きいアプリケーションの能動的実行を必要としないイベントキャプチャロジック用のホスティングサービスを提供することができる。例えば、情報エージェントアプリケーションが、あるオペレーティングシステムイベントがアプリケーションアクティビティをトリガすることを望む場合がある。その結果、この機能性だけのために別々のアプリケーションを実行することを必要とするのではなく、サービスでこのイベントプロバイダをホスティングすることが可能である。
【００８９】
プリファレンスは、イベントの発生によってアクティベートされる。その処理は、同期式、非同期式、またはこの２つの組合せのいずれかとすることができる。同期処理では、イベントサブミッションとプリファレンス評価の間にとるに足らない遅延がある。その一方で、非同期処理は、イベントサブミッションとプリファレンス評価の間のかなりの遅延を有する。本発明のシステムは、処理の両方のモデルをサポートし、イベントバッチサブミッションに基づいて、リアルタイムでこのモデルの間で選択することができる。
【００９０】
さらに、本発明の一態様によれば、プリファレンス処理は、プリファレンスを効率的に処理するために、データベースクエリの威力を利用する。開発者に、および最終的にエンドユーザに公開されるのが、一時に１つモデルに従って条件機能を指定できるようにする宣言的プログラミングモデルである。一時に１つプログラミングモデルは、使用が最も自然であり、開発者およびユーザが１つのプリファレンスに対して１つのイベントを指定できるようにするモデルである。しかし、本発明の態様によれば、システム１００は、セット指向の形で実行され、インデクシングおよび重複除去などの技法を使用する、条件クラスクエリを作成する。これは、プリファレンスが効率的な形で評価されると同時に、開発者およびエンドユーザに、一時に１つの形でプログラムを概念化させ、記述させるという点で、有益であり、これは、理解および記述が簡単であるが、複数のプリファレンスを実行する効率的でない形である。さらに、複数のプリファレンスをバッチで処理することができるが、プリファレンスを、イベント発生時に個別に評価できることに留意されたい。
【００９１】
図６を見ると、本発明の態様によるプリファレンス評価のシステム６００が示されている。システム６００に、データストア１５０、複数のテーブル６１０、プリファレンス実行エンジン１６０、および結果テーブル６３０が含まれる。データストア１５０に、複数のテーブル６１０が収容され、この複数のテーブル６１０は、開発者スキームならびにエンドユーザプリファレンスから、システム１００によって作られる。イベントの発生の結果として、プリファレンス実行エンジンが、例えばデータストア１５０に保管されたテーブルから、プリファレンスを受け取るか取り出す。次に、実行エンジン１６０は、プリファレンスならびにいくつかのストアドプロシージャ（データとして保管することもできる）を使用して、テーブル６１０を照会し、結果テーブル６３０を作る。結果テーブル６３０には、指定されたアクションをそれに対して開始できる、その条件が満足されたプリファレンスが保管される。
【００９２】
テーブル６１０の個数および複雑さは、エンドユーザプリファレンスをサポートするために開発者によって記述されたスキーマの複雑さに依存して変化する可能性がある。下で、システム６００が、プリファレンスを処理するためにデータベーステーブルおよびクエリをどのように使用するかを明らかにするために、例を提示する。この例では、プリファレンスの複数のグループを使用しようとする２人の個人、ＪａｃｋおよびＪｉｌｌがいる。上で説明したように、ＪａｃｋおよびＪｉｌｌがエンドユーザプリファレンスを指定する前に、スキーマを作らなければならない。スキーマは、上で述べたように複数の部分を有するが、理解を簡単にするために、非常に単純なスキーマを、本明細書で説明する。スキーマの本質的な部分の１つが、イベントクラスの定義である。この例では、２つのイベントクラス、ＥｍａｉｌＥｖｅｎｔｓおよびＳｔｏｃｋｅｖｅｎｔｓを検討する。本明細書に添付された付録を見ると、この２つのイベントクラスおよび３つのプリファレンスクラスのスキーマ定義を示す擬似コードが示されている。２つのプリファレンスクラスは、ＥｍａｉｌＥｖｅｎｔｓに基づき、第３のクラスは、ＳｔｏｃｋＥｖｅｎｔｓに基づく。情報システム１００は、このスキーマを使用して、プリファレンスクラステーブルおよび条件クラスを作ることができ、これをデータストア１５０に保管することができる。例えば：
【００９３】
【表７】
2007518151.tif 000009
【００９４】
次に、ＪａｃｋおよびＪｉｌｌは、プリファレンスを定義することができる。この例において、Ｊａｃｋが、３つのプリファレンスグループ、ＰＧ（Ｊａｃｋ，１）、ＰＧ（Ｊａｃｋ，２）、およびＰＧ（Ｊａｃｋ，３）を定義すると仮定する。さらに、Ｊａｃｋは、次のように、このグループの間に分散する５つのプリファレンスを定義する。
【００９５】
【表８】
2007518151.tif 000010
【００９６】
この例において、Ｊｉｌｌが、２つのプリファレンスグループ、（Ｊｉｌｌ，１）および（Ｊｉｌｌ，２）を定義すると仮定する。さらに、Ｊｉｌｌが、次のようにこのグループの間で分散する５つのプリファレンスを指定すると仮定する。
【００９７】
【表９】
2007518151.tif 000011
【００９８】
情報エージェントシステム１００は、これらのプリファレンスを使用して、プリファレンスおよびそれに関連する条件を記載した追加のリレーショナルデータベーステーブルを作ることができる。次の例のテーブルを一時に１つ検討し、これらがプリファレンスの評価にどのように使用されるかを検討されたい。
【００９９】
下に示されたＰｒｅｆｅｒｅｎｃｅＧｒｏｕｐｓテーブルに、ＪａｃｋおよびＪｉｌｌが定義したプリファレンスグループごとに１行の、５つの行が含まれる。さらに、プリファレンスグループがイネーブルされるかどうかを示す列が指定されていることに留意されたい。上で説明したように、これは、例えば、ユーザが、家庭にいる場合にイネーブルされるプリファレンスのグループと、仕事場にいる場合にイネーブルされるプリファレンスのもう１つのグループを指定したい場合に有用である。ここでは、すべてのプリファレンスグループが、イネーブルされたものとして示されている。
【０１００】
【表１０】
2007518151.tif 000012
【０１０１】
ＰｒｅｆｅｒｅｎｃｅＧｒｏｕｐＭｅｍｂｅｒＳｈｉｐテーブルも、どのプリファレンスがどのプリファレンスグループのメンバであるかを要約するために定義することができる。下に示されたこのテーブルには、プリファレンスごとに１つの、１１個の行が含まれる。
【０１０２】
【表１１】
2007518151.tif 000013
【０１０３】
下のｐｒｅｆｅｒｅｎｃｅテーブルをデータストア１５０に保管して、ユーザによって定義されたプリファレンスに関するデータを要約することができる。このテーブルには、１０個のプリファレンスのそれぞれに対応する１０行が含まれる。このテーブルが、重要な列および行だけを示すために連結されていることに留意されたい。
【０１０４】
【表１２】
2007518151.tif 000014
【０１０５】
上のｐｒｅｆｅｒｅｎｃｅテーブルに合計１４個のＡＮＤグループがあることにも留意されたい。さらに、上には合計１９個の条件がある。これらのＡＮＤグループおよび条件に関する情報は、次のように追加テーブルにキャプチャすることができる。
【０１０６】
【表１３】
2007518151.tif 000015
【０１０７】
ＡＮＤグループｉｄは、前のテーブルから順次番号を付けられている。ＣｏｎｄｉｔｉｏｎＣｏｕｎｔレコードは、ＡＮＤによって接続される条件の数を記録する。上のテーブルの唯一の驚くべき行が、下に示す行である。
7                11                  1      -- From (Bob) AND !Contains
(Work)
【０１０８】
ＣｏｎｄｉｔｉｏｎＣｏｕｎｔが、期待される２ではなく１であることに留意されたい。クエリ評価のＮＯＴの存在を考慮に入れるために、条件カウントは、ＡＮＤグループ内の、その前にＮｏｔ（！）がない条件だけの合計と定義される。その前にＮＯＴがある条件は、下に示された別々のテーブルで要約することができる。
【０１０９】
ＡＮＤＧｒｏｕｐｓを、さらに、次の連結されたテーブルに示されているように、テーブルでＡＮＤＧｒｏｕｐＭｅｍｂｅｒｓｈｉｐに関して定義することができる。
【０１１０】
【表１４】
2007518151.tif 000016
【０１１１】
上で注記したように、ＮＯＴを有する条件は、特殊な事例と考えることができ、次のようにそれ自体のテーブルで要約することができる。
【０１１２】
【表１５】
2007518151.tif 000017
【０１１３】
条件値テーブルも作成して、プリファレンスで指定された条件の値を保管することができる。このテーブルが、各条件に関連する２つのパラメータ値だけを許容することに留意されたい。この例において、これは、部分的に、すべての条件が１つのパラメータ値だけを有するので効率的であるが、条件が、２つを越える値を関連付けられることを許容される場合には、このテーブルを拡張することができ、あるいはその代わりに、別のテーブルをインスタンス化して、余分の条件値を保持することができる。
【０１１４】
【表１６】
2007518151.tif 000018
【０１１５】
ＣｏｎｄｉｔｉｏｎｓＲｅｓｕｌｔｓテーブルも設けることができる。ＣｏｎｄｉｔｉｏｎｓＲｅｓｕｌｔｓテーブルは、最終的な結果テーブル６３０の先駆物として使用することができる。ＣｏｎｄｉｔｉｏｎｓＲｅｓｕｌｔｓテーブルは、条件クエリが実行される時に取り込まれる。条件クエリがまだ実行されていない時には、このテーブルにはまだ行がない。条件を評価し、このテーブルに取り込む例示的プロシージャを、下で開示する。
【０１１６】
【表１７】
2007518151.tif 000019
【０１１７】
前に述べたように、本発明の態様の１つは、条件機能の開発者への一時に１つモデルの公開を可能にするが、データベースクエリ効率を利用するセット指向の形で実行される条件クラスクエリを最終的に作成する宣言的プログラミングシステムを提示することである。したがって、１対１条件クラス宣言をクエリに変換することができる。例えば、ＥｍａｉｌＥｖｅｎｔｓで、エンドユーザプリファレンスが、電子メールの送信者に依存するアクションを行うことができる（例えば、ＪａｃｋのＰ１）。したがって、エンドユーザは、ユーザインターフェースを介してＭａｉｌＩｓＦｒｏｍ（Ｍａｒｙ）を記述することができる。しかし、プリファレンスを実行する場合に、システム６００は、ユーザ条件ステートメントを表すデータベースクエリを実行する。例えば、システムは、ユーザ宣言の代わりに次のＳＱＬクエリステートメントを実行することができる。ここで、ＣＶ．ＰａｒａｍＶａｌｕｅ１＝「Ｍａｒｙ」である。
【０１１８】
【表１８】
2007518151.tif 000020
【０１１９】
したがって、開発者は、各条件のクエリコードを定義し、テーブルに保管しなければならない。可能ではあるが、新しいテーブルをこの明示的な目的のために作成する必要はない。前に定義したＣｏｎｄｉｔｉｏｎＣｌａｓｓｅｓテーブルを単純に変更して、下の擬似コードに示されているようにクエリテキストを含めることができる。
【０１２０】
【表１９】
2007518151.tif 000021
【０１２１】
テーブル６１０のすべてを定義したならば、そのようなデータに対してプリファレンスを評価して、結果テーブル６３０に取り込み、その後、それに関連するアクションを実行することができる。プリファレンスは、クエリを評価することによって実行することができる。クエリは、１つまたは複数のプロシージャを使用することによって評価し、処理することができ、このプロシージャは、データストア１５０にデータとして保管することができ、本発明の態様に従って、オンデマンドで構成することができる。複数のプロシージャを、条件およびプリファレンスの評価専用にすることができ、その後、結果テーブルに、関連するアクションの実行を開始できるように、プリファレンスおよびそのプリファレンスが真と評価されたどうかを示すしるしを取り込むことができる。例えば、次のプロシージャを使用して、条件を評価するか照会し、結果をＣｏｎｄｉｔｉｏｎＲｅｓｕｌｔｓテーブルに保管することができ、その後、その結果を評価して、結果テーブル６３０に取り込むことができる。
【０１２２】
【表２０】
2007518151.tif 000022
【０１２３】
さらに、すべての条件クエリが実行されるように、上のプロシージャをループと共に使用することができることを諒解されたい。しかし、上のプロシージャを、条件ごとに１回呼び出して、増分条件評価を可能にすることが好ましい可能性がある。すべての条件を評価したならば、別のプロシージャを使用して、プリファレンスを評価することができ、このプロシージャは、しばしば、プリファレンスの間のＢｏｏｌｅａｎ演算子を有する条件である。
【０１２４】
本明細書で説明するすべてのプロシージャと同様に、なかんずく、プログラマスタイル、効率、および構成されるテーブルの性質に依存して、プロシージャを記述できる複数の異なる形がある。理解のために、下のプロシージャを、本発明の態様に従ってプリファレンスを評価するのに使用できるクエリの例として提供する。単一の実行ではなく、プリファレンスの異なるＡＮＤＧｒｏｕｐｓを増分的に評価する、より効率的なクエリプロシージャを使用できることに留意されたい。
【０１２５】
【表２１】
2007518151.tif 000023
【０１２６】
上のプロシージャが、最終的な結果テーブル６３０の行をどのように作るかを明確にするために、少数の例を下に示す。
【０１２７】
例１：
ＣｏｎｄｉｔｉｏｎＲｅｓｕｌｔｓが、次の２行を有すると仮定する。
【０１２８】
【表２２】
2007518151.tif 000024
【０１２９】
プリファレンス１の２つの条件の間にＡＮＤがある。その結果、このプリファレンスは、上の条件の両方が真である場合に限って真になる。この両方の条件が、条件カウントが２である第１のＡＮＤＧｒｏｕｐに属する。したがって、上のテーブルが、ＡｎｄＧｒｏｕｐＭｅｍｂｅｒｓｈｉｐテーブルと結合される場合に、次のテーブルがもたらされる。
【０１３０】
【表２３】
2007518151.tif 000025
【０１３１】
ｇｒｏｕｐ  ｂｙを実行した後に、次の行が得られる。
【０１３２】
【表２４】
2007518151.tif 000026
【０１３３】
ここで、（Ｐｒｅｆ．Ｉｄ，ＡＮＤＧｒｏｕｐＩｄ）が、ＡＮＤＧｒｏｕｐｓテーブルのキーを形成する。そこでのルックアップは、２の条件カウントを提供し、これはｓｕｍ（Ｂｏｏｌ）と等しい。したがって、このプリファレンスは真であり、結果テーブル６３０に追加することができる。
【０１３４】
例２：
ＣｏｎｄｉｔｉｏｎＲｅｓｕｌｔｓが次の２行を有すると仮定する。
【０１３５】
【表２５】
2007518151.tif 000027
【０１３６】
プリファレンス２の２つの条件の間に、ＯＲがある。したがって、このプリファレンスは、２つの条件のいずれかが真である場合に限って真と評価される。これらの条件は、それぞれ２番目および３番目のＡＮＤＧｒｏｕｐｓに属し、条件カウントは、両方とも１である。したがって、上のテーブルをＡｎｄＧｒｏｕｐＭｅｍｂｅｒｓｈｉｐテーブルと結合する場合に、次のテーブルがもたらされる。
【０１３７】
【表２６】
2007518151.tif 000028
【０１３８】
上のテーブルをグループ化した後に、次が得られる。
【０１３９】
【表２７】
2007518151.tif 000029
【０１４０】
上の行の両方が、ｈａｖｉｎｇ文節を満足し、したがって、ｄｉｓｔｉｎｃｔを適用した後に、プリファレンス（Ｐｒｅｆ．Ｉｄ＝２，Ｅｖｅｎｔ  Ｉｄ＝１０１）が結果テーブル６３０にコピーされることがわかる。
【０１４１】
例３：
この最後の例について、ＣｏｎｄｉｔｉｏｎＲｅｓｕｌｔｓテーブルが次の２行を有すると仮定する。
【０１４２】
【表２８】
2007518151.tif 000030
【０１４３】
プリファレンス７の条件が、実際には、
From (Bob) and !Contains (Work)
であったことを想起されたい。ＮＯＴが存在すると、上の２行目の１が、本発明の態様に従って−１に変更される。次は、そのような機能性を提供する例示的クエリである。
【０１４４】
【表２９】
2007518151.tif 000031
【０１４５】
さらに、スマートクエリオプティマイザが使用される場合に、ＮＯＴテーブルが空であることに留意すると、このクエリが即座にリターンすることに留意されたい。したがって、上のテーブルは、次のようになる。
【０１４６】
【表３０】
2007518151.tif 000032
【０１４７】
この条件の両方が、１１番目のＡＮＤＧｒｏｕｐに属する。ＡＮＤＧｒｏｕｐテーブルから、このプリファレンス（ｐｒｅｆｅｒｅｎｃｅ，ＡＮＤＧｒｏｕｐ）の条件カウントが１であると判定することができる。０≠１なので、このプリファレンス評価クエリから生じる行はない。しかし、第２行がｃｏｎｄｉｔｉｏｎＲｅｓｕｌｔｓテーブルにない場合に、１（＝１）の合計を有し、プリファレンス７が真と評価されることに留意されたい。
【０１４８】
結果テーブル６３０に取り込んだ後に、プリファレンスアクションを実行することができる。アクションは、情報エージェントシステム１００によって、または、システム１００からプリファレンス結果を取り出し、これらに作用することによって、情報エージェントアプリケーションによって実行することができる。アクションが、情報エージェントシステム１００ではなくアプリケーションによって実行される場合に、イベントサブミッションアプリケーションまたは他のアプリケーションを使用することによって、アクションをシステム１００から取り出すことができる。システム１００によって、ホスティングサービスを、アクションを取り出し、実行することができるアプリケーションアクションハンドラにシステム１００によって供給することができる。
【０１４９】
優先順位アクションおよびコンテキスト分析
次の議論は、通知またはメッセージなどの生成されたアクションに関連する複数の情報に、例えばユーザまたはシステムへの送信のために優先順位システムによって自動的に優先順位を付けることを可能にするシステムおよび方法に関する。さらに、この議論は、説明を単純にするために通知の優先順位およびコンテキスト分析に焦点を合わせるが、どのアクションでも、類似する形で優先順位およびコンテキスト分析を使用できることを諒解されたい。優先順位システムは、ユーザにとっての学習された重要性に従って１つまたは複数の受け取られるメッセージに優先順位を付けるために明示的におよび／または暗黙のうちにトレーニングできるクラシファイヤを使用することができる。例として、通知を、類似する度合の重要性を有する例のトレーニングセットまたは通知のタイプを介して、高、中、低、または他の重要性の度合として分類することができる。バックグラウンドモニタを設けて、メッセージ処理に関するユーザのアクティビティを監視して、メッセージ重要性に関するユーザの個人的判断に従ってクラシファイヤをさらに洗練またはチューニングすることができる。他の優先順位分類に、メッセージの遅れた再検討または処理の時間に関連する損失に関する判定を含めることができる。
【０１５０】
メッセージまたは他の通知に自動的に優先順位を付けた後に、ユーザは、複数のより重要でないおよび／または関連しないメッセージをソートする必要なしに、より重要なメッセージを再検討することができる。メッセージを、さらに、重要性に関して１つまたは複数のフォルダに収集することができ、ここで、ユーザは、望みの時に、類似する分類された重要性を有するメッセージを再検討することができる。情報エージェントシステム１００などの他のシステム（例えば、通知コンポーネント１８０を介して）は、判定された優先順位に基づいて、メッセージを１つまたは複数の通知シンク（例えば、携帯電話機、ハンドヘルドコンピュータ）に向けることができる。例えば、電子メールメッセージが、高い重要性を有すると判定される場合に、情報エージェントシステム１００は、ユーザが現在自分の机にいてメッセージを受け取るかどうかを判定することができる。そうでない場合には、通知プラットフォームは、セル電話機または家庭のラップトップコンピュータなど、現在ユーザが自由に使える可能性が最も高い通信デバイスにメッセージをリダイレクトすることができ、ユーザは、重要なメッセージまたは緊急のメッセージについて通知を受けることができる。
【０１５１】
図７を参照すると、システム７００に、本発明の態様による優先順位システム７１２および通知アクションアーキテクチャが示されている。優先順位システム７１２は、１つまたは複数のメッセージまたは通知７１４を受け取り、関連するメッセージの優先順位または重要性の尺度（例えば、メッセージが高い重要性または低い重要性を有する確率値）を生成し、１つまたは複数のメッセージを関連する優先順位と共に出力７１６に供給する。下で詳細に説明するように、クラシファイヤは、メッセージ７１４に優先順位の尺度を自動的に割り当てるように構成し、トレーニングすることができる。例えば、出力７１６をフォーマットし、メッセージに、高、中、低のカテゴリ、または他のカテゴリの重要性の度合にそのメッセージが属する確率を割り当てることができる。メッセージを、例えば重要性の判定されたカテゴリに従って、電子メールプログラム（図示せず）のｉｎ  ｂｏｘで自動的にソートすることができる。ソートに、重要性の定義されたラベルを有するシステムフォルダにファイルを向けることも含めることができる。これに、フォルダに、低、中、高などの重要性の度合を用いてラベルを付けさせることを含めることができ、特定の重要性を有すると判定されたメッセージは、関連するフォルダにソートされる。同様に、１つまたは複数のオーディオサウンドまたはビジュアルディスプレイ（例えば、アイコン、シンボル）を適合させて、所望の優先順位を有するメッセージを受け取ったことをユーザに警告することができる（例えば、高優先順位メッセージに３回ビープ、中に２回ビープ、低に１回ビープ、高優先順位に赤または点滅する警告シンボル、中優先順位メッセージを受け取ったことを示す緑の点滅しない警告シンボル）。
【０１５２】
本発明のもう１つの態様によれば、情報エージェントシステム７１７（図１の１００）を、優先順位システム７１２と共に使用して、ユーザがアクセス可能な１つまたは複数の通知シンクに優先順位付きメッセージを向けることができる。下で詳細に説明するように、ＩＡシステム７１７は、優先順位付きメッセージ７１６を受け取り、例えば、いつ、どこで、どのようにユーザに通知するかに関する判断を行うように適合させることができる。例として、ＩＡシステム７１７は、通信モーダリティ（例えば、セル電話機、携帯情報端末（ＰＤＡ）などのユーザの現在の通知シンク７１８）と、ユーザのありそうな位置および／またはユーザの注意のありそうなフォーカスを判定することができる。高重要性電子メールが受信された場合に、例えば、ＩＡシステム７１７は、ユーザ位置／フォーカスを判定し、ユーザに関連する通知シンク７１８にメッセージを向ける／再フォーマットすることができる。低優先順位のメッセージ７１６が受信された場合に、ＩＡシステム７１７を、例えば望み通りに後に再検討するためにその電子メールをユーザのｉｎ−ｂｏｘに残すように構成することができる。下で詳細に説明するように、他のルーティングおよび／または警告システム７１９を使用して、優先順位付きメッセージ７１６をユーザおよび／または他のシステムに向けることができる。
【０１５３】
この説明の次のセクションでは、電子メールなどのテキストファイルの優先順位の生成を、自動分類システムおよびプロセスを介して説明する。説明するテキストの優先順位の生成は、下で詳細に説明する通知プラットフォームなどの他のシステムで使用することができる。このセクションの説明は、図８および図９に関して提供されるが、前者は、テキストクラシファイヤの明示的および暗黙のトレーニングを示す図であり、後者は、テキストクラシファイヤに入力されることによってテキストの優先順位がどのように生成されるかを示す図である。説明は、図１０および図１１に関しても提供され、これらは、それに従ってテキストの優先順位を分類できる異なるスキーマの図であり、図８および図１１に関して、テキストタイプに依存して適用可能とすることができるコスト関数を示すグラフである。
【０１５４】
図８を参照すると、テキスト／データクラシファイヤ８２０は、優先順位に関する分類を実行するために、矢印８２２によって表されるように明示的にトレーニングすることができ、矢印８２４によって表されるように暗黙のうちにトレーニングすることができる。矢印８２２によって表される明示的トレーニングは、一般に、クラシファイヤ８２０構成の初期フェーズで行われ、矢印８２４によって表される暗黙のトレーニングは、通常、クラシファイヤ８２０が構成された後に、例えばバックグラウンドモニタ８３４を介してクラシファイヤ８２０を微調整するために行われる。本明細書で、分類トレーニングおよび実施手法を示す例示のために、ＳＶＭクラシファイヤを参照して具体的な説明を行う。他のテキスト分類手法に、ベイジアンネットワーク、決定木、および独立性の異なるパターンを提供する確率分類モデルが含まれる。本明細書で使用されるテキスト分類は、優先順位のモデルを展開するのに使用される統計的回帰を含む。
【０１５５】
本発明の一態様によれば、明確に理解されるサポートベクトルマシン（Ｓｕｐｐｏｒｔ  Ｖｅｃｔｏｒ  Ｍａｃｈｉｎｅ、ＳＶＭ）が、クラシファイヤ８２０として使用される。ナイーブベイズ、ベイズネット、決定木、および他の学習モデルなど、他のクラシファイヤモデルも使用できることを諒解されたい。ＳＶＭは、クラシファイヤコンストラクタおよび特徴選択モジュール８２６内の学習フェーズまたはトレーニングフェーズを介して構成される。クラシファイヤは、入力属性ベクトルｘ＝（ｘ１，ｘ２，ｘ３，ｘ４，ｘｎ）を、入力がクラスに属する信頼度すなわちｆ（ｘ）＝ｃｏｎｆｉｄｅｎｃｅ（ｃｌａｓｓ）に写像する関数である。テキスト分類の場合に、属性は、単語、句、または単語から導出される他のドメイン固有属性（例えば、音声の一部、キー用語の存在）であり、クラスは、関心をもたれたカテゴリまたは領域（例えば、優先順位のレベル）である。
【０１５６】
ＳＶＭおよび他の帰納学習手法の態様は、ラベル付けされたインスタンスのトレーニングセットを使用して、分類関数を自動的に学習することである。トレーニングセットは、クラシファイヤコンストラクタ８２６に関連するデータストア８３０内に図示されている。図からわかるように、トレーニングセットに、特定のカテゴリに関連する潜在的なおよび／または実際の要素または要素の組合せ（例えば、単語または句）を示すグルーピングＧ１からＧＮのサブセットを含めることができる。データストア８３０に、複数のカテゴリ１からＭも含まれ、グルーピングを、１つまたは複数のカテゴリに関連付けることができる。学習中に、入力特徴をクラスの信頼度に写像する関数が学習される。したがって、モデルを学習した後に、カテゴリは、入力特徴の重み付きベクトルとして表される。
【０１５７】
カテゴリ分類に関して、バイナリ特徴値（例えば、単語がカテゴリに現れるか否か）または実数値の特徴（例えば、単語が重要性重みｒを有して現れる）が、しばしば使用される。カテゴリ集合に、多数の独自の用語が含まれる可能性があるので、特徴選択は、一般に、カテゴリ化に機械学習技法を適用する場合に使用される。特徴の数を減らすために、特徴を、総合的な頻度カウントに基づいて除去することができ、カテゴリへのあてはめに基づく少数の特徴に従って選択することができる。カテゴリへのあてはめは、相互情報量、情報利得、χ二乗、および／または実質的にすべての他の統計選択技法を介して判定することができる。これらのより小さい記述が、ＳＶＭへの入力として働く。線形ＳＶＭが、適当な一般化精度を提供し、適度に高速の学習を提供することに留意されたい。非線形ＳＶＭの他のクラスに、多項式クラシファイヤおよびラジアル基底関数（ｒａｄｉａｌ  ｂａｓｉｓ  ｆｕｎｃｔｉｏｎ）が含まれ、これらを、本発明に従って使用することもできる。
【０１５８】
クラシファイヤコンストラクタ８２６は、データストア８３０内のグルーピングおよび関連するカテゴリを分析して、入力ベクトルをクラスの信頼度に写像する関数を「学習」するために、学習モデル８３２を使用する。ＳＶＭを含む多数の学習モデルについて、カテゴリのモデルを、特徴重みｗのベクトルとして表すことができ、カテゴリごとに１つの学習された重みのベクトルを設けることができる。重みｗが学習される場合に、新しいテキストが、ｘとｗの内積を計算することによって分類され、ここで、ｗは、学習された重みのベクトルであり、ｘは、新しいテキストを表すベクトルである。シグモイド関数を設けて、ＳＶＭの出力を確率Ｐに変換することもできる。確率は、それから優先順位を決定できる、カテゴリまたはクラスにまたがる匹敵するスコアを提供する。
【０１５９】
ＳＶＭは、関数形式がトレーニングの前に定義される、パラメータ化された関数である。ＳＶＭは、例のセットから関数をあてはめるので、ＳＶＭのトレーニングは、一般に、ラベル付けされたトレーニングセットを必要とする。トレーニングセットは、Ｎ個の例のセットからなるものとすることができる。各例は、入力ベクトルｘｉとカテゴリラベルｙｊからなり、カテゴリラベルは、入力ベクトルがカテゴリに含まれるかどうかを記述する。カテゴリごとに、Ｎ個の例を用いてトレーニングされたＳＶＭに、Ｎ個の自由パラメータを設けることができる。これらのパラメータを見つけるために、二次計画法（ＱＰ）問題を、よく理解されているように解く。ＱＰ問題を解く、複数の周知の技法がある。これらの技法に、Ｓｅｑｕｅｎｔｉａｌ  Ｍｉｎｉｍａｌ  Ｏｐｔｉｍｉｚａｔｉｏｎ技法ならびに他の技法を含めることができる。図９からわかるように、入力ベクトルｘに変換されたテキスト入力９３６が、カテゴリごとにクラシファイヤ９２０に適用される。クラシファイヤ９２０は、クラシファイヤコンストラクタ８２６によって判定された学習された重みベクトルｗ（例えば、カテゴリごとに１つの重みベクトル）を使用し、内積を形成して優先順位出力９３８を形成し、ここで、確率Ｐを入力テキスト９３６に割り当てて、１つまたは複数の関連する優先順位（例えば、高、中、低）を示すことができる。
【０１６０】
図８に戻って、矢印８２２によって表されるテキストクラシファイヤ８２０のトレーニングに、特徴選択を使用することを含む、８２６内のクラシファイヤを構成することが含まれる。明示的トレーニングフェーズでは、クラシファイヤ８２０に、例えば、時間にクリティカルなテキストおよび時間にクリティカルでないテキストの両方を提示することができ、その結果、クラシファイヤがこの２つを区別できるようにすることができる。このトレーニングセットは、ユーザによって提供することができ、あるいは、標準のまたはデフォルトのトレーニングセットを使用することができる。トレーニングコーパスを与えられれば、クラシファイヤ８２０は、まず特徴選択プロシージャを適用し、このプロシージャは、最も識別力のある特徴を見つけることを試みる。このプロセスでは、相互情報量分析を使用する。特徴選択は、自然言語処理を用いてタグ付けされた句または音声の一部など、使用可能にされた１つまたは複数の単語または上位の区別を操作することができる。すなわち、テキストクラシファイヤ８２０を、特別にタグ付けされたテキストを用いてシーディングして、重要と思われるテキストの特徴を区別することができる。
【０１６１】
テキスト分類の特徴選択では、通常、単一の単語の検索を実行する。単一の単語に頼ること以外に、ドメイン固有の句および特徴の上位パターンも使用可能にされる。特殊なトークンによって、分類を機能強化することもできる。例えば、電子メールクリティカル性に関する学習されるクラシファイヤの質は、異なる時間クリティカル性を有する電子メールの間の区別に有用として識別された手細工で作られた特徴を特徴選択プロシージャに入力することによって、高めることができる。したがって、特徴選択中に、１つまたは複数の単語ならびに、異なるレベルの時間クリティカル性を有するメッセージの間の区別に有用である句およびシンボルが、検討される。
【０１６２】
次の例からわかるように、メッセージのクリティカル性を識別するトークンおよび／または値のパターンに、下記の区別および下記のＢｏｏｌｅａｎ組合せが含まれる。
【０１６３】
メッセージヘッダ内の情報
例えば：
ＴＯ：フィールド（受信者情報）
ユーザだけにあてられている
ユーザを含む少数の人にあてられている
別名および少数の人にあてられている
複数の別名および少数の人にあてられている
ユーザにＣｃ：されている
ユーザにＢｃｃ：されている
ＦＲＯＭ：フィールド（送信者情報）
潜在的に様々なクラスの個人（例えば、家族、友人）にセグメント化される、重要な人の事前に決定されたリストにある名前
ユーザの会社／組織の内部として識別された送信者
ユーザが報告する上司、
ユーザの上司の上司、
ユーザに報告する人
など、オンライン組織図から引き出された、ユーザに関する組織での関係の構造に関する情報
外部のビジネスピープル
【０１６４】
過去時制情報
これには、次のような、既に発生したイベントに関する記述が含まれる。
Ｗｅ  ｍｅｔ
ｍｅｅｔｉｎｇ  ｗｅｎｔ
ｈａｐｐｅｎｅｄ
ｇｏｔ  ｔｏｇｅｔｈｅｒ
ｔｏｏｋ  ｃａｒｅ  ｏｆ
ｍｅｅｔｉｎｇ  ｙｅｓｔｅｒｄａｙ
【０１６５】
未来時制情報
Ｔｏｍｏｒｒｏｗ
Ｔｈｉｓ  ｗｅｅｋ
Ａｒｅ  ｙｏｕ  ｇｏｉｎｇ  ｔｏ
Ｗｈｅｎ  ｃａｎ  ｗｅ
Ｌｏｏｋｉｎｇ  ｆｏｒｗａｒｄ  ｔｏ
Ｗｉｌｌ  ｔｈｉｓ
Ｗｉｌｌ  ｂｅ
【０１６６】
会議および調整情報
Ｇｅｔ  ｔｏｇｅｔｈｅｒ
Ｃａｎ  ｙｏｕ  ｍｅｅｔ
Ｗｉｌｌ  ｇｅｔ  ｔｏｇｅｔｈｅｒ
Ｃｏｏｒｄｉｎａｔｅ  ｗｉｔｈ
Ｎｅｅｄ  ｔｏ  ｇｅｔ  ｔｏｇｅｔｈｅｒ
Ｓｅｅ  ｙｏｕ
Ａｒｒａｎｇｅ  ａ  ｍｅｅｔｉｎｇ
Ｌｉｋｅ  ｔｏ  ｉｎｖｉｔｅ
Ｂｅ  ａｒｏｕｎｄ
【０１６７】
解決された日付
明示的にまたは次のように省略される、日時を述べるテキストのパターンから示される将来および過去の日時
Ｏｎ  ５／２
Ａｔ  １２：００
【０１６８】
質問
疑問符（？）に隣接する単語、句
個人的要求の表示
Ｃａｎ  ｙｏｕ
Ａｒｅ  ｙｏｕ
Ｗｉｌｌ  ｙｏｕ
ｙｏｕ  ｐｌｅａｓｅ
Ｃａｎ  ｙｏｕ  ｄｏ
Ｆａｖｏｒ  ｔｏ  ａｓｋ
Ｆｒｏｍ  ｙｏｕ
【０１６９】
必要の表示
Ｉ  ｎｅｅｄ
Ｈｅ  ｎｅｅｄｓ
Ｓｈｅ  ｎｅｅｄｓ
Ｉ’ｄ  ｌｉｋｅ
Ｉｔ  ｗｏｕｌｄ  ｂｅ  ｇｒｅａｔ
Ｉ  ｗａｎｔ
Ｈｅ  ｗａｎｔｓ
Ｓｈｅ  ｗａｎｔｓ
Ｔａｋｅ  ｃａｒｅ  ｏｆ
【０１７０】
時間クリティカル性
ｈａｐｐｅｎｉｎｇ  ｓｏｏｎ
ｒｉｇｈｔ  ａｗａｙ
ｄｅａｄｌｉｎｅ  ｗｉｌｌ  ｂｅ
ｄｅａｄｌｉｎｅ  ｉｓ
ａｓ  ｓｏｏｎ  ａｓ  ｐｏｓｓｉｂｌｅ
ｎｅｅｄｓ  ｔｈｉｓ  ｓｏｏｎ
ｔｏ  ｂｅ  ｄｏｎｅ  ｓｏｏｎ
ｄｏｎｅ  ｒｉｇｈｔ  ａｗａｙ
ｔｈｉｓ  ｓｏｏｎ
ｂｙ［日付］
ｂｙ［時刻］
【０１７１】
重要性
ｉｓ  ｉｍｐｏｒｔａｎｔ
ｉｓ  ｃｒｉｔｉｃａｌ
【０１７２】
単語、句＋！
明示的な優先順位フラグ状況（低、なし、高）
メッセージの長さ
新しいメッセージのコンポーネントのバイト数
商業的およびアダルトコンテンツのジャンク電子メールのしるし
Ｆｒｅｅ！！
単語＋！！！
Ｕｎｄｅｒ  １８
Ａｄｕｌｔ’ｓ  ｏｎｌｙ
大文字で始まる単語の比率
非英数字文字の比率
【０１７３】
上で示した単語または句のグルーピングが、クラシファイヤトレーニングを行うのに使用することができる例示的な単語、グルーピング、または句を示すことに留意されたい。他の類似する単語、グループ、または句を同様に使用することができ、したがって、本発明が、示された例に制限されないことを諒解されたい。
【０１７４】
さらに、図８を参照すると、矢印８２４によって表されるクラシファイヤ８２０の暗黙のトレーニングを、例えばユーザのデスクトップコンピュータまたはモバイルコンピュータに常駐できるバックグラウンドモニタ８３４を介してユーザの作業または使用パターンを監視することによって、行うことができる。例えば、ユーザが働き、メールのリストを再検討する際に、時間にクリティカルなメッセージが最初に読まれ、優先順位の低いメッセージが、後で再検討され、および／または削除されると仮定することができる。すなわち、新しい電子メールを提示される場合に、ユーザを監視して、ユーザがその電子メールを即座に、どの順序で開くか、開かずに削除するか、および／または比較的短い時間で電子メールに返答するかを判定することができる。したがって、クラシファイヤ８２０は、ユーザが、働くかシステムを操作している間に監視されるように適合され、クラシファイヤは、バックグラウンドでのトレーニングによって周期的に洗練され、機能強化されたリアルタイムの意思決定のために更新される。クラシファイヤを作るためのバックグラウンド技法は、新しいトレーニングメッセージを用いてクラシファイヤ８２０を更新する技法から拡張することができる。
【０１７５】
代替案では、大量のメッセージを収集することができ、ここで、新しいフィルタを、毎日のスケジュール、トレーニングセットに入れられるメッセージの新しい量の数、および／またはその組合せのいずれかによって、バッチプロセスで作成することができる。クラシファイヤに入力されるメッセージごとに、例えば、クラシファイヤの新しい事例を作成することができる。事例は、例えば高優先順位または低優先順位のいずれかのテキストの肯定および否定の例として保管される。例として、１つまたは複数の低、中、高の緊急性クラスを認識し、これらのクラスのそれぞれへのメンバシップの確率を使用して、期待されるクリティカル性を作ることができる。より多数のクリティカル性クラスを使用して、より高い分解能を求めることができる。例えば、図９からわかるように、メッセージのトレーニングセット９４０（例えば、超高、高、中、普通、低、超低など）を最初に使用して、９４２に示されているようにリアルタイム分類を達成するように、クラシファイヤ９４２をトレーニングすることができ、ここで、新しいメッセージは、トレーニングセット９４０によって解決される例の数に従って分類される。図９では、例示のために３つのそのようなカテゴリが示されているが、様々な度合の所望の重要性に従って、複数のそのようなカテゴリをトレーニングできることを諒解されたい。図からわかるように、新しいメッセージ９４４に、例えば、クラシファイヤ９４２によって割り当てられた優先順位に従って、ラベルを付け、タグを付け、および／または１つまたは複数のフォルダ９４６にソートすることができる。下で詳細に説明するように、割り当てられた優先順位を、さらに、後続システムによって使用して、メッセージをフォーマットし、ユーザに配布し、およびユーザのためのモーダリティ判定を行うことができる。
【０１７６】
本発明のもう１つの態様によれば、数または値の推定は、例えば、フォルダのセットの１つとして事例またはメッセージにラベルを付けるのではなく、電子メールとのユーザ対話を監視することによって達成することができる。したがって、クラシファイヤは、更新され続けるが移動するウィンドウを有することができ、ここで、ユーザによって指定されるある年齢より新しいメッセージまたは文書の事例が、検討される。
【０１７７】
例えば、メッセージの遅れた再検討に関連する一定の割合の損失を、メッセージの期待されるクリティカル性（ｅｘｐｅｃｔｅｄ  ｃｒｉｔｉｃａｌｉｔｙ、ＥＣ）と称し、
【０１７８】
【数１】
2007518151.tif 000033
【０１７９】
である。ここで、Ｃはコスト関数、ｄは遅延、Ｅはイベント、Ｈは電子メールのクリティカル性クラスであり、ＥＣは、潜在的なクラスのコスト関数Ｃによって記述される損失の割合によって重みを付けられたクラスの尤度の合計として表される。
【０１８０】
例として、図９を参照すると、電子メールメッセージなどのテキスト９３６が、クラシファイヤ９２０に入力され、クラシファイヤ９２０は、これに基づいて、テキスト９３６の優先順位９３８を生成する。すなわち、クラシファイヤ９２０は、例えば０から１００％までの比率として測定された、優先順位９３８を生成する。この比率は、クラシファイヤ９２０の前のトレーニングに基づく、テキスト９３６が高優先順位または他の優先順位である尤度の尺度とすることができる。
【０１８１】
上で説明した本発明では、クラシファイヤ９２０および優先順位９３８が、例えばトレーニング句の電子メールが高優先順位または低優先順位のいずれかとして構成されるスキームに基づくものとすることができる。このスキームを、図１０に関して示すが、図１０では、テキストクラシファイヤ１０２０が、高優先順位であるものとして事前に決定されるテキストのグループ１０４７および低優先順位であるものとして事前に決定されるテキストのグループ１０４８によってトレーニングされる。分析されるテキストは、クラシファイヤ１０２０に入力され、クラシファイヤ１０２０は、例えば分析されるテキストが高優先順位または低優先順位である尤度を測定したスカラ数１０４９を出力する。
【０１８２】
例えば、図１０および図１１を参照すると、これらの図には、テキスト１０３６、１１３６が低優先順位、中優先順位、および高優先順位に分類されるスキームが示されている。上で説明したように、複数の他のトレーニングセットを使用して、優先順位のより高い分解能の区別を提供することができる。テキストクラシファイヤ１０２０、１１２０は、高優先順位であるテキストのグループ１０４７、１１４７、低優先順位であるテキストのグループ１０８４、１１４８、ならびに中優先順位であるテキストのグループ１１５０によってトレーニングされる。したがって、分析されるテキスト１０３６、１１３６は、クラシファイヤ１０２０、１１２０に入力され、クラシファイヤ１０２０、１１２０は、スカラ数１０４９、１１４９を出力し、スカラ数１０４９、１１４９によって、例えば、分析されるテキストが、高優先順位、中優先順位、または低優先順位である尤度を測定することができる。クラシファイヤ１１２０は、クラス１１５２も出力することができ、このクラス１１５２は、テキスト１１３６が含まれる可能性が最も高い、低優先順位、中優先順位、または高優先順位のクラスを示す。望まれる場合に、さらなるクラスを追加することもできる。
【０１８３】
本発明は、優先順位の定義に制限されない。というのは、この用語が、電子メールメッセージなどのテキストに優先順位を割り当てるのに、クラシファイヤ１０２０、１１２０によって使用されるからである。優先順位は、例えば、損失関数に関して定義することができる。具体的に言うと、優先順位は、受信の後にテキストが再検討される際の遅れ時間あたりの損失の機会の期待されるコストに関して定義することができる。すなわち、テキストの遅れた処理に関して生じる期待される損失または期待されるコストである。損失関数は、さらに、受信されたテキストのタイプに従って変化させることができる。
【０１８４】
例えば、一般的な事例を図１２に示すが、図１２は、テキストの優先順位に依存する線形コスト関数のグラフ１２５４である。グラフ１２５４では、時間が経つにつれて、テキストを再検討しないことのコストも増える。しかし、コストは、線１２５８によって示される中優先順位メッセージまたは線１２６０によって示される低優先順位メッセージと比較して、線１２５６によって示されるように、高優先順位メッセージについてより多く増加する。例えば、高優先順位線１２５６が、１００の傾斜を有し、中優先順位線１２５８が、１０の傾斜を有し、低優先順位線１２６０が、１の傾斜を有する場合がある。これらの傾斜の値は、例えば回帰分析によって、所与のテキストに優先順位を割り当てる際に、クラシファイヤ１０２０、１１２０によって使用することができる。
【０１８５】
しかし、一部のメッセージは、線形コスト関数の使用によって、そのプロパティをよく近似されない。例えば、会議に関するメッセージは、会議の時刻が近づくにつれて増えるコスト関数を有し、その後、このコスト関数は、急激に減少する。すなわち、会議を逃した後に、一般に、ユーザがそれに関して行えることはさほどない。この状況は、図１３に示された非線形コスト関数によって、よりよく近似される。グラフ１３６２では、コスト関数１３６４が、線１３６６によって画定される会議の時刻に達するまで急速に増加し、その後、急速に減少する。メッセージタイプに応じて、コスト関数を、線形および非線形の両方の、多数の異なる代表的なコスト関数の１つによって近似することができる。
【０１８６】
したがって、説明したように、テキストの優先順位は、クラシファイヤの出力に基づく、それが複数の優先順位の１つである尤度とするか、やはりクラシファイヤの出力に基づく、そのテキストが適用される最もありそうな優先順位クラスとすることができる。その代わりに、電子メールメッセージなどのテキストの期待される時間クリティカル性を判定することができる。これは、次のように書くことができる。
【０１８７】
【数２】
2007518151.tif 000034
【０１８８】
ここで、ＥＬは、期待される損失であり、ｐ（ｃｒｉｔｉｃａｌｉ）は、テキストがクリティカル性ｉを有する確率であり、Ｃ（ｃｒｉｔｉｃａｌｉ）は、テキストがクリティカル性ｉを有することに関するコスト関数であり、ｎは、クリティカル性クラスの総数から１を引いたものである。コスト関数は、説明したように、線形または非線形とすることができる。関数が線形である場合に、コスト関数は、時間に伴う損失の一定の割合を定義する。非線形関数の場合に、損失の割合は、テキストの遅れた再検討または処理に伴って変化し、遅れの量に応じて増減することができる。
【０１８９】
ｎ＝１の場合に、２つの優先順位クラス、低および高だけがあることを指定すると、期待される損失を、次のように定式化し直すことができる。
ＥＣ＝ｐ（ｃｒｉｔｉｃａｌｈｉｇｈ）Ｃ（ｃｒｉｔｉｃａｌｈｉｇｈ）＋［１−ｐ（ｃｒｉｔｉｃａｌｌｏｗ）］Ｃ（ｃｒｉｔｉｃａｌｌｏｗ）
【０１９０】
ここで、ＥＣは、テキストの期待されるクリティカル性である。さらに、低クリティカル性メッセージのコスト関数に０がセットされる場合に、この式は、
ＥＣ＝ｐ（ｃｒｉｔｉｃａｌｈｉｇｈ）Ｃ（ｃｒｉｔｉｃａｌｈｉｇｈ）
になる。テキストの再検討の時までの総損失は、期待されるクリティカル性の積分すなわち
【０１９１】
【数３】
2007518151.tif 000035
【０１９２】
として表すことができる。ここで、ｔは、文書を再検討する前の時間遅れである。
【０１９３】
重要性によって、電子メールメッセージなどの文書をランキングする値メトリックと一致する他の尺度。上の議論は、時間クリティカル性として優先順位に焦点を合わせたが、「重要性」の他の概念もトレーニングすることができる。例えば、これは、トレーニングフォルダのセットに、「Ｈｉｇｈ  Ｉｍｐｏｒｔａｎｃｅ（高重要性）」から「Ｌｏｗ  Ｉｍｐｏｒｔａｎｃｅ（低重要性）」までのラベルを付けることによって達成することができ、ここで、「期待される重要性」の尺度を判定することができる。もう１つのメトリックは、セマンティックラベル「messages that I would wish to hear about within 1 day while traveling（旅行中に１日以内に聞きたいメッセージ）」に基づくものとして、旅行中のユーザへの転送に関するメッセージの優先順位付けの尺度を判定することができる。さらに、使用されるメトリックの１つが、緊急性または時間クリティカル性である。というのは、これが、意思決定、選別、およびルーティングの明瞭なセマンティクスを有するからである。この場合に、クラスは、緊急性の異なるレベルに従ってラベルを付けられ、メッセージが各クラスに含まれることの推論された確率からの各メッセージの期待される緊急性として計算される。
【０１９４】
前のセクションで説明した、クリティカル性に対する拡張も、本発明に従って提供することができる。例えば、分類に、特徴のクラスの中またはその間の高支払い（ｈｉｇｈ−ｐａｙｏｆｆ）特徴の組合せの自動検索を含めることができる。例として、特殊な区別、構造などの、あるユーザに特に有用であることがわかっている単語との組合せを検索し、分類プロセスで使用することができる。２つの特徴の組合せを、ダブレット（ｄｏｕｂｌｅｔ）と呼び、３つの特徴の組合せを、トリプレット（ｔｒｉｐｌｅｔ）と呼ぶ。特徴の組合せは、改善された分類を可能にすることができる。
【０１９５】
分類は、クラシファイヤで移動するウィンドウを使用する増分インデクシングの使用によって改善することもできる。これによって、古いデータがタイムアウトし、新しいデータが持ち込まれる際に、クラシファイヤを日常的にリフレッシュできるようになる。
【０１９６】
分類は、メッセージで指定されるイベントの日時の判定に基づくものとすることもできる。この判定によって、クラシファイヤが使用できる特徴をメッセージに割り当てることができる。例えば、割り当てられる特徴に、本日４時間以内、本日８時間以内、翌日、今週、今月、および来月以降を含めることができる。これによって、クラシファイヤが、分類されるメッセージに関する改善された精度を有することが可能になる。一般に、分類は、イベントが将来か過去かを考慮して、参照されるイベントの時刻に基づくものとすることができる。したがって、将来のイベントに関して、分類で、イベントが発生する将来の時刻への送信者の言及を考慮する。
【０１９７】
他の新しい特徴を、分類プロセスに統合することもできる。例えば、組織図を使用して、図での送信者の位置によってメッセージがどれほど重要であるかを判定することができる。言葉の特徴を、クラシファイヤに統合することができる。異なる言語に対処するために、出身者の生まれ、および／またはメッセージが書かれた言語に応じて特徴を変更することができる。分類は、メッセージが保管される異なるフォルダならびに他のスケーリングルールおよび制御ルールに応じて、変化させることができる。電子メールおよび他のソースの他に、分類を、インスタントメッセージと、株式ティッカなどの他の情報のソースに対して実行することができる。
【０１９８】
一般に、送信者−受信者の構造的関係を、分類プロセスで考慮することができる。例えば、ユーザが、メッセージの実質的に唯一の受信者である場合に、このメッセージを、少数の人に送られるメッセージより重要と考えることができる。少数の人に送信されるメッセージは、ユーザにブラインドコピー（ｂｃｃ）またはカーボンコピー（ｃｃ）されるメッセージより重要である可能性がある。送信者に関して、送信者の名前が認識されるかどうかに基づいてクリティカル性を割り当てることができる。クリティカル性は、送信者が、ユーザが関連する組織の内部または外部のどちらであるかに応じて割り当てることもできる。
【０１９９】
分類で考慮できる他の区別に、メッセージの長さ、質問が検出されるかどうか、およびユーザの名前がメッセージに含まれるかどうかが含まれる。時間クリティカル性に関連する言葉によって、メッセージの重要性を高めることができる。例えば、「ｈａｐｐｅｎｉｎｇ  ｓｏｏｎ」、「ｒｉｇｈｔ  ａｗａｙ」、「ａｓ  ｓｏｏｎ  ａｓ  ｐｏｓｓｉｂｌｅ」、「ＡＳＡＰ」、および「ｄｅａｄｌｉｎｅ  ｉｓ」などの句によって、メッセージをよりクリティカルにすることができる。未来時制と比較した過去時制の使用ならびに「ｇｅｔ  ｔｏｇｅｔｈｅｒ」、「ｃａｎ  ｗｅ  ｍｅｅｔ」などの句によって指定される協力タスクを考慮することができる。ジャンクメールの証拠によって、メッセージの優先順位を下げることができる。組織図でユーザに隣接する送信者からの短い質問など、組合せを表す述部も、分類プロセスで考慮することができる。
【０２００】
この説明の次のセクションでは、高優先順位テキスト、例えば、ユーザ設定の閾値を超えるか決定論的推理によって判定される閾値を超える高い優先順位を有する可能性が高いテキストについて、ユーザに警告すべき場合の決定を提供するプロセスを説明する。すなわち、時間にクリティカルなメッセージについて知ることの他に、例えばユーザが直接に着信電子メールを見ていない場合に、時間にクリティカルなメッセージについてユーザに警告すべき場合を決定することも重要である。一般に、時間にクリティカルなメッセージについて知るために、現在取り組まれている仕事からユーザの気をそらすことのコストを判定する。
【０２０１】
代替案では、警告および通知に関する様々なポリシを使用することができる。これらのポリシは、例えば下で詳細に説明する、通知プラットフォームアーキテクチャ内で実施することができる。このポリシの一部に、次が含まれる。
・  総損失に関するユーザ指定の上限の設定。このポリシは、メッセージの遅れた再検討に関連する総損失が、事前に指定された「許容可能な」損失「ｘ」を超える場合に、システムが警告を生成しなければならないことを指定する。
・  もう１つのポリシは、ＮＥＶＡ＝ＥＶＴＡ−ＥＣＡ−ＴＣなどのより複雑な決定論的分析に基づく費用便益分析とすることができ、ここで、ＮＥＶＡは、警告の正味の期待される価値、ＥＶＴＡは、警告の期待される価値、ＥＣＡは、警告の期待されるコスト、ＴＣは、メッセージの通信に関連する伝送コストである。
【０２０２】
一般に、時刻ｔにメッセージを再検討しない場合にユーザがこうむる期待される損失が、ユーザに警告することの期待されるコストより大きいことが費用便益分析から示される場合に、ユーザに警告しなければならない。すなわち、
ＥＬ−ＥＣ＞０
の場合に警告を行わなければならず、ここで、ＥＬは、現在時刻ｔにテキストを再検討しないことの期待される損失であり、ＥＣは、現在時刻ｔにテキストについてユーザに警告することの期待されるコストである。期待される損失は、この説明の前のセクションで説明した。
【０２０３】
しかし、ユーザが、しばしば、将来に自分でメッセージを再検討するので、上の定式化は最も正確とはいえない。したがって、実際上、ユーザは、一般に、ＥＶＴＡと称する警告の期待される価値が正である場合に警告されなければならない。したがって、警告の期待される価値は、ユーザが後に警告なしで自分でメッセージを再検討することの価値に対立するものとしての、今、テキストについてユーザに警告することの価値から警告のコストを引いたものを検討しなければならない。これは、
ＥＶＡ＝ＥＬａｌｅｒｔ−ＥＬｎｏ−ａｌｅｒｔ−ＥＣ
を表すことができ、ここで、ＥＬａｌｅｒｔは、ＥＬｎｏ−ａｌｅｒｔに対立するものとしての、警告された時にユーザがメッセージを今再検討する場合のユーザがメッセージを再検討することの期待される損失であり、ＥＬｎｏ−ａｌｅｒｔは、警告されずに、ある時点でユーザが自分でメッセージを再検討することの期待される損失であり、ＥＣは、気をそらすことの考慮および情報を伝送することの直接のコストに基づく警告の期待されるコストである。
【０２０４】
さらに、複数のメッセージからの情報を、一緒に、単一の複合警告にグループ化することができる。１つの警告で複数のメッセージに関する情報を再検討することは、単一のメッセージに関する情報を中継する警告よりコストが高い可能性がある。そのような気をそらすことの増加は、警告のコストを、その情報の複雑さの関数にすることによって表すことができる。電子メールメッセージのＥＶＡが、他の電子メールメッセージのＥＶＡと独立であると仮定することができる。例えば、ＥＶＡ（Ｍｉ，ｔ）は、時刻ｔに単一のメッセージＭｉに関してユーザに警告することの価値を指し、ＥＣＡ（ｎ）は、ｎ個のメッセージの内容を中継することの期待されるコストを指す。したがって、ｎ個のメッセージのセットに関する情報を中継することの期待される価値を一緒に合計することによって、複数のメッセージを検討することができる。ここで、
【０２０５】
【数４】
2007518151.tif 000036
【０２０６】
である。
【０２０７】
警告の期待されるコストを判定するために、ユーザが存在するか否かに関する情報を推論するか、これに直接にアクセスすることが有用である。赤外線センサおよび圧力センサなど、ユーザがオフィスいる場合を示すセンサを使用することができる。しかし、そのようなデバイスが使用可能でない場合に、ユーザがオフィスにいる確率を、例えば最後に観察されたマウスまたはキーボードのアクティビティからの時間など、コンピュータでのユーザアクティビティの関数として割り当てることができる。さらに、カレンダで使用可能なスケジューリング情報を使用して、ユーザの距離および配置に関する推論を行い、異なるプロセスによってユーザにメッセージを転送するコストを考慮することもできる。
【０２０８】
高い時間クリティカル性を有するメッセージに関する情報によってユーザに割り込むことに関する判断を行う際に、ユーザがどれほど忙しいかを知ることも重要である。これは、ユーザがコンピュータで作業しているかどうか、およびその割合、またはユーザが電話をかけているか、誰かと話しているか、別の位置の会議に出席しているかどうかに関して推理することができる（例えば、推論的意思決定）。図１４に示されているように、複数のクラスの証拠を使用して、ユーザのアクティビティまたは注意のフォーカスを査定することができる。次に、ベイジアンネットワークを使用して、ユーザのアクティビティに関する推論を実行することができる。そのようなネットワークの例を、図１５に示す。
【０２０９】
一般に、いつどのようにメッセージについてユーザに警告し、サービスを提供するかに関する判断を、期待されるクリティカル性およびユーザアクティビティの推論に基づいて行わなければならない。判断は、例えば判断モデルを使用することによって実行することができる。図１６から図１８は、警告判断を行うのにそのような判断モデルをどのように使用できるかを示す、影響の図である。図１６に、現在のアクティビティ、メッセージの期待される時間クリティカル性、および通信モーダリティに依存する警告のコストを考慮する、ユーザに割り込むことに関する判断のための判断モデルを示す。図１７には、現在位置を表す変数と、アクティビティに対するその変数の影響と、代替メッセージング技法のコストも含まれる。さらに、図１８は、かなりのグラフィックス内容を有するメッセージが、グラフィックス内容を提示せずにユーザに転送される場合の忠実度の損失に関連するコストを考慮するために拡張されている。
【０２１０】
代替案では、いつどのようにユーザに警告するかに関する判断を、警告に関するポリシを定義するユーザ指定の閾値およびパラメータのセットを使用することによって行うことができる。ユーザの存在は、例えばマウスまたはキーボードのアクティビティに基づいて推論することができる。したがって、ユーザは、例えば、アクティビティおよび非アクティビティの推論された状態に関する警告の閾値を入力することをイネーブルされることができる。ユーザは、警告がより低いクリティカル性で発生する場合の、アクティビティに続くアイドルアクティビティの量も入力することができる。実質的にコンピュータアクティビティが検出されない時間に基づいてユーザがいないと判定される場合に、メッセージを保管することができ、メッセージは、ユーザがコンピュータと対話するために戻ってきた場合に、クリティカル性の順番でユーザに報告される。さらに、ユーザは、期待されるクリティカル性、最大の期待される損失、およびユーザに警告することの価値を含む量の関数として、ルーティングオプションおよびページングオプションを指定することができる。
【０２１１】
通知および／または警告システムは、ユーザが戻ると期待される前に重要と期待される優先順位を送信するために、ユーザが戻ると期待される時を推定することもできる。これは、経時的な、ユーザの存在および不在のパターンを学習することによって達成することができる。次に、ユーザは、そのユーザがシステムに戻ると期待される時に関する適当なポリシをセットして、警告されずに優先順位を再検討することができる。システムによる戻ると期待される時の判定は、例えば、非常に緊急のメッセージの送信者に自動的に伝達することができる。この形で、メッセージ送信者は、いつユーザが戻り、メッセージに応答できるかのフィードバックを受け取る。送信者に、その送信者のメッセージがユーザのモバイルデバイスなどに伝達されたことを知らせることもできる。
【０２１２】
図１９に、本発明の態様による、優先順位の生成および優先順位に基づく警告判断の実行の方法論を示す。説明を単純にするために、この方法論を、一連の動作として図示し、説明するが、本発明によれば、一部の動作を、図示し、本明細書で説明するものと異なる順序でおよび／または他の動作と同時に実行できるので、本発明が、動作の順序によって制限されないことを理解し、諒解されたい。例えば、当業者は、この方法論を、その代わりに、状態図でなど、一連の相互に関係する状態またはイベントとして表現できることを理解し、諒解するであろう。さらに、示された動作のいずれかが、本発明による方法論の実施に必要ではない可能性がある。
【０２１３】
図１９を参照すると、流れ図１９７４に、本発明に従って優先順位が生成され、使用される方法論が示されている。１９８０で、優先順位を割り当てられるテキストなどのデータを受け取る。このデータは、電子メールメッセージあるいは実質的にすべての他のタイプのデータまたはテキストとすることができる。１９８２で、上で説明したように、クラシファイヤに基づいて、データの優先順位を生成する。さらに、１９８２に、上で説明した、クラシファイヤの初期トレーニングおよび後続トレーニングを含めることができる。
【０２１４】
１９８４で、データの優先順位を出力する。図１９からわかるように、これには、１９８６、１９８８、１９９０、１９９２、および１９９４での処理を含めることができる。１９８６で、現在時刻ｔにデータを再検討しないことの期待される損失を判定する。この判定では、上で説明したように、ユーザが、警告されずに、自分でテキストを再検討するという前提に基づいて、将来の時のテキストを検討しないことの期待される損失を考慮する。１９８８で、やはり上で説明したように、警告することの期待されるコストを判定する。１９９０で、損失がコストより大きい場合に、１９９２で、時刻ｔに警告を行わず、処理は、新しい現在時刻ｔで、１９８６に戻る。１９８６に戻る処理は、時間が進行した時に、１９９０での計算が変化し得るなど、期待される損失が、ある時点で警告コストを上回る可能性があるので、実行することができる。期待される損失が警告コストを超える時には、１９９４で、ユーザまたは他のシステムへの警告を実行する。
【０２１５】
ユーザまたは他のシステムへの警告の出力を、これから説明する。ユーザは、警告判断基準に基づいて電子デバイスで警告を受けることができ、この警告判断基準は、優先順位付きのテキストについてユーザが警告されなければならない場合を示す。ユーザが警告される電子デバイスは、ポケットベル、セル／デジタル携帯電話機、または下で詳細に説明する他の通信モーダリティとすることができる。ポケットベルまたは携帯電話機などの電子デバイスでのユーザへの警告は、例えばユーザの位置、推論された作業、および／または注意のフォーカスに関する情報に敏感になるように適合させることができる警告判断基準に基づくものとすることができる。そのような情報は、不確実性の下で推論することができ、あるいは、オンライン情報ソースからアクセスすることができる。例えば、オンラインカレンダからの情報を適合させて、使用される判断基準を制御して、下で詳細に説明する通知シンクなどのデバイスへの情報中継に関する判断を行うことができる。
【０２１６】
優先順位付きのテキストまたは他のデータを、ルーティング判断基準に基づいてルーティングすることによって、警告を実行することができる。テキストのルーティングに、テキストの転送、および／またはテキストが電子メールである場合のテキストの送信者への返答を含めることができる。例えば、優先順位付きの文書についてユーザに警告するために、サウンドを再生することができる。代替案では、エージェントまたは自動化されたアシスタントを開くことができる（例えば、対話型ディスプレイウィザード）。すなわち、エージェントをディスプレイスクリーンに表示して、優先順位付き文書についてユーザに通知することができる。さらに、スクリーンに表示するなど、優先順位付き文書を開くことができる。文書は、フォーカスを受け取ることができる。これに、文書の優先順位が高いほど、大きいウィンドウに表示されるなど、優先順位に基づいて文書のサイズを変更すること、および／または優先順位に基づいてディスプレイで文書を中央に配置することを含めることもできる。
【０２１７】
図２０すなわち、本発明の態様によるテキスト生成および優先順位システム２０００の図を参照する。システム２０００に、プログラム２００２およびクラシファイヤ２００４が含まれる。プログラム２００２およびクラシファイヤ２００４に、コンピュータのプロセッサによって、そのコンピュータのコンピュータ可読メディアから実行されるコンピュータプログラムを含めることができることに留意されたい。
【０２１８】
プログラム２００２は、クラシファイヤ２００４に入力されるテキストを生成する。このプログラムには、テキストとして働く電子メールを受信する電子メールプログラムが含まれる。クラシファイヤ２００４は、関連するメッセージの優先順位を生成する。上で説明したように、クラシファイヤ２００４は、ベイジアンクラシファイヤ、サポートベクトルマシンクラシファイヤ、または他のタイプのクラシファイヤとすることができる。クラシファイヤ２００４によって出力されるテキストの優先順位を、上で説明した費用便益分析と共に使用して、さらなる出力および／またはそれに基づく警告をもたらすことができる。
【０２１９】
図２１を見ると、本発明の態様によるプリファレンス実行エンジンとコンテキストアナライザが一緒にどのように機能するかが示されている。システム２１００に、コンテキストアナライザ２１２２、プリファレンス実行エンジン２１２４、１つまたは複数のイベントまたは通知のソース１からＮ、２１２６、２１２７、２１２８、通知ソースとして動作できる優先順位システム２１３０、および１つまたは複数のアクションまたは通知のシンク１からＭ、２１３６、２１３７、２１３８が含まれ、ＮおよびＭは、それぞれ整数である。本発明の態様によれば、ソースを、イベントパブリッシャとも呼ぶことができ、シンクを、イベントサブスクライバと呼ぶこともできる。任意の個数のシンクおよびソースを設けることができる。一般に、実行エンジン２１２４は、コンテキストアナライザ２１２２に保管され、および／またはこれによってアクセスされるパラメトリック情報に部分的に基づいて、ソース２１２６〜２１２８からシンク２１３６〜２１３８に、イベントまたは警告とも称する通知を伝達する。
【０２２０】
コンテキストアナライザ２１２２は、通知判断に影響する、ユーザの変数およびパラメータに関する情報を保管／分析する。例えば、パラメータに、ユーザの通常の位置および注意のフォーカスまたは時刻および曜日ごとのアクティビティなどのコンテキスト情報と、ユーザが異なる位置でアクセスできる傾向があるデバイスなどの、そのようなパラメータに対して条件付けられる追加パラメータを含めることができる。そのようなパラメータは、１つまたは複数のセンサを介して自律的に行われる観察の関数とすることもできる。例えば、全世界測位システム（ＧＰＳ）サブシステムによって提供できるユーザの位置に関する情報、使用されるデバイスのタイプおよび／またはデバイスの使用のパターンに関する情報、および特定のタイプのデバイスがユーザによって最後にアクセスされた時刻に基づいて、１つまたは複数のプロファイル（図示せず）を選択するか変更することができる。さらに、下で詳細に説明するように、自動化された推論を使用して、位置および注意などのパラメータまたは状態を動的に推論することもできる。プロファイルパラメータは、ユーザが編集できるユーザプロファイルとして保管することができる。事前定義のプロファイルのセットまたは動的推論に頼る他に、この通知アーキテクチャは、例えば次の「ｘ」時間の間または所与の時刻まで、ユーザが重要な通知を除いて応えることができないなど、ユーザのリアルタイムの状態をユーザが指定できるようにすることができる。
【０２２１】
パラメータに、異なるセッティングで異なるタイプの通知によって邪魔されることに関するユーザのプリファレンスに関するデフォルト通知プリファレンスパラメータも含めることができ、これは、実行エンジン２１２４が通知判断をそこから行い、ユーザがそれに対する変更を開始できる基礎として使用することができる。パラメータに、ユーザが異なる情況でどのように通知されることを望むか（例えば、セル電話による、ポケットベルによる）に関するデフォルトパラメータを含めることができる。パラメータに、異なるセッティングで異なるモードによって通知されることに関連する中断のコストなどの査定を含めることができる。これに、ユーザが異なる位置にいる尤度、異なるデバイスが使用可能である尤度、および所与の時のユーザの注意状況の尤度を示すコンテテキストパラメータならびにユーザが所与の時にどのように通知されることを望むかを示す通知パラメータを含めることができる。
【０２２２】
本発明の一態様に従ってコンテキストアナライザ２１２２によって保管される情報は、アナライザによって判定されるコンテキスト情報を含む。コンテキスト情報は、この説明の後のセクションで詳細に説明するように、１つまたは複数のコンテキスト情報ソース（図示せず）に基づいてユーザの位置および注意状況を識別することによって、アナライザ２１２２によって判定される。コンテキストアナライザ２１２２は、例えば、ユーザの自動車またはセル電話機の一部である全世界測位システム（ＧＰＳ）を介して、ユーザの実際位置を正確に判定することができる場合がある。アナライザは、統計モデルを使用して、その日のタイプ、時刻、ユーザのカレンダのデータ、およびユーザのアクティビティに関する観察などの情報の考慮を介して収集されるバックグラウンド査定および／または観察を考慮することによって、ユーザが注意の所与の状態である尤度を判定することもできる。注意の所与の状態に、ユーザが通知を自由に受け取ることができるか、忙しく、通知を受け取ることができないかを含めることができ、ウィークデイ、週末、祝日、および／または他の時／期間などの他の考慮事項を含めることができる。
【０２２３】
ソース２１２６〜２１２８および２１３０は、ユーザおよび／または他のエンティティのための通知を生成する。例えば、ソース２１２６〜２１２８に、インターネットおよびネットワークベースの通信、電話通信などの通信ならびにソフトウェアサービスを含めることができる。通知ソースは、一般に、本明細書では、情報、サービス、および／またはシステムあるいは世界イベントについてユーザまたはユーザのプロキシに警告することを意図された、通知または警告と呼ぶこともできるイベントを生成するものとして定義される。通知ソースを、イベントソースと呼ぶこともできる。
【０２２４】
例えば、優先順位を付けられるように、優先順位システム２１３０によって通知として電子メールを生成することができ、ここで、通知を生成するアプリケーションプログラムまたはシステムは、ユーザに対する電子メールのありそうな重要性または緊急性に対応する相対優先順位を電子メールに割り当てる。電子メールを、ユーザに対する相対的な重要性に関わりなく送信することもできる。インターネット関連サービスに、例えば、時々の現在のニュースの見出しおよび株式市況など、ユーザがサブスクライブした情報を含む通知を含めることができる。
【０２２５】
通知またはイベントのソース２１２６〜２１２８自体は、プッシュタイプのソースまたはプルタイプのソースとすることができる。プッシュタイプのソースは、サブスクライブの後に情報を自動的に送信する、見出しニュースまたは他のインターネット関連サービスなど、対応する要求なしで自動的に情報を生成し、送信するソースである。プルタイプのソースは、メールサーバがポーリングされた後に受け取られる電子メールなど、要求に応答して情報を送信するソースである。別の通知ソースに、次が含まれる。
・  カレンダシステムなどの電子メールデスクトップアプリケーション
・  コンピュータシステム（例えば、システムアクティビティまたは問題に関する警告に関する情報であるメッセージによってユーザに警告することができる）
・  インターネット関連のサービス、予約情報、スケジューリング照会
・  １つまたは複数の共有フォルダ内の文書の変化またはある種類の文書の数の変化
・  情報に関する持続的な照会に応答する新しい文書の使用可能性、および／または
・  人およびそのプレゼンス、位置の変化、近接（例えば、私が移動している場合に別の同僚または友人が１６ｋｍ（１０マイル）以内にいる場合に知らせる）、または求めに応じられること（例えば、Ｓｔｅｖｅが、会話に応えられるか、フルビデオテレビ会議をサポートできる高速リンクの近くにいる場合に知らせる）に関する情報の情報ソース。
【０２２６】
通知アクションシンク２１３６〜２１３８は、ユーザに通知を供給することができる。例えば、そのような通知アクションシンク２１３６〜２１３８に、デスクトップ機および／またはラップトップ機などのコンピュータ、ハンドヘルドコンピュータ、セル電話機、陸線電話機、ポケットベル、自動車ベースのコンピュータ、ならびに諒解できる他のシステム／アプリケーションを含めることができる。シンク２１３６〜２１３８の一部が、他のシンクより豊かに通知を伝達できることに留意されたい。例えば、デスクトップコンピュータは、通常は、スピーカおよび比較的大きいカラーディスプレイを結合され、ローカルネットワークまたはインターネットに結合される場合に情報を受け取るための高い帯域幅を有する。したがって、デスクトップコンピュータによって、比較的豊富な形でユーザに通知を伝達することができる。逆に、例えば、多くのセル電話機は、白黒である可能性がある、より小さいディスプレイを有し、比較的少ない帯域幅で情報を受信する。それに対応して、セル電話機によって伝達される通知に関連する情報を、例えば、より短く生成し、電話のインターフェース能力に合わせることができる。したがって、通知の内容は、セル電話機またはデスクトップコンピュータのどちらに送信されるかに応じて異なるものとすることができる。本発明の一態様によれば、通知シンクは、例えばイベントまたは通知への、イベントサブスクリプションサービスを介して、それがサブスクライブするものを参照することができる。
【０２２７】
実行エンジン２１２４は、コンテキストアナライザによって保管され、および／または判定された情報にアクセスし、ソース２１２６〜２１２８から受け取った通知のどれをどのシンク２１３６〜２１３８に伝達するかを決定する。さらに、エンジン２１２４は、情報を送るためにどのシンク２１３６〜２１３８が選択されたかに応じて、通知をどのように伝達するかを決定することができる。例えば、選択されたシンク２１３６〜２１３８に供給する前に通知を要約しなければならないと決定することができる。
【０２２８】
本発明は、どの通知をどの通知シンクに伝達するかおよび通知を伝達する形に関してエンジン２１２４がどのように判断するかに制限されない。一態様によれば、決定論的分析を使用することができる。例えば、ユーザの位置、注意、デバイス可用性、および警告がない場合にユーザが情報にアクセスするまでの時間の長さを含む変数に関する重要な不確実性を推論するように、実行エンジン２１２４を適合させることができる。実行エンジン２１２４は、通知についてユーザに警告するかどうかに関する通知判断を行うことができ、そうする場合に、要約の性質および通知の中継に使用される適当なデバイスに関する通知判断を行うことができる。一般に、実行エンジン２１２４は、通知の正味の期待される価値を判定する。それを行う際に、実行エンジンは、次を検討することができる。
・  各使用可能な通知シンクの忠実度および伝送信頼性
・  ユーザの気をそらすことの注意コスト
・  ユーザにとっての情報の新規性
・  ユーザが自分でこの情報を再検討するまでの時間
・  情報の潜在的にコンテキスト依存の価値、および／または
・  通知に含まれる情報の経時的な価値の増減
【０２２９】
したがって、不確実性に関して行われる推論は、例えば、ユーザのある注意状態に対する特定のデバイスの特定のモードの使用に伴う、ユーザの中断のコストなどの価値の期待される尤度として生成することができる。実行エンジン２１２４は、次のうちの１つまたは複数に関する判断を行うことができる。
・  ユーザが現在注意を払い、行っていること（例えば、コンテキスト情報に基づいて）
・  ユーザ現在どこにいるか
・  その情報がどれほど重要であるか
・  通知を遅らせることのコストはどれほどか
・  その通知がどれほど気をそらせるか
・  ユーザに達する尤度はどれほどか
・  所与の通知シンクの特定のモードの使用に関連する忠実度の損失はどれほどか
【０２３０】
したがって、実行エンジン２１２４は、保留中のアクティブな通知の、決定論的分析などの分析を実行し、情報シンクおよび情報ソースによって提供されるコンテキスト依存の変数を評価し、ユーザが情報を再検討する可能性が高くなるまでの時間と、ユーザの位置および現在の注意状態などの選択された不確実性を推論することができる。
【０２３１】
さらに、実行エンジン２１２４は、パーソナライズされた決定論的分析の代わりにまたはこれをサポートするために、コンテキストアナライザ２１２２によってユーザプロファイルに保管された情報にアクセスすることができる。例えば、ユーザプロファイルは、所与の時に、ユーザがポケットベルを介して通知されることを好み、通知が所定の重要性レベルを有する場合に限ることを示すことができる。そのような情報は、決定論的分析を開始するベースラインとして使用することができ、あるいは、ユーザに通知するかどうかおよびユーザにどのように通知するかを実行エンジン２１２４が判定する形とすることができる。
【０２３２】
本発明の一態様によれば、通知プラットフォームアーキテクチャ２１００は、イベントインフラストラクチャまたはメッセージングインフラストラクチャに常駐するレイヤとして構成することができる。しかし、本発明は、特定のイベンティングインフラストラクチャに制限されない。そのようなイベンティングおよびメッセージングのシステムおよびプロトコルに、次を含めることができる。
・  ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）、または当技術分野で既知のＨＴＴＰ拡張
・  当技術分野で既知のＳｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）
・  当技術分野で既知のＷｉｎｄｏｗｓ（登録商標）  Ｍａｎａｇｅｍｅｎｔ  Ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ（ＷＭＩ）
・  当技術分野で既知のＪｉｎｉ
・  例えばパケット交換プロトコルに基づくものなど、事実上すべてのタイプの通信プロトコル
【０２３３】
さらに、当業者が諒解できるように、このアーキテクチャは、柔軟な分散計算インフラストラクチャに常駐するレイヤとして構成することができる。したがって、通知プラットフォームアーキテクチャ２１００は、例えば、ソースが通知、警告、およびイベントを送信する形として、およびシンクが通知、警告、およびイベントを受信する形として、基礎になるインフラストラクチャを使用することができる。しかし、本発明は、これに制限されない。
【０２３４】
図２２を参照すると、この説明の前のセクションで説明した情報エージェントシステムアーキテクチャのコンテキストアナライザ２１２２が、システム２２００内で、より詳細に示されている。図２２に示されたコンテキストアナライザ２２２２に、ユーザ通知プリファレンスストア２２４０と、ユーザコンテキストプロファイルストア２２６２およびホワイトボード２２６４を含むユーザコンテキストモジュール２２６０が含まれる。本発明の一態様によるコンテキストアナライザ２２２２は、コンピュータのプロセッサによって、メモリを含むがこれに制限されないそのコンピュータの機械可読媒体から実行可能な１つまたは複数のコンピュータプログラムとして実施することができる。
【０２３５】
プロファイルストア２２６２は、例えばユーザが編集し、変更することができるユーザプロファイルなど、ユーザのデフォルト通知プリファレンスなどのユーザの通知パラメータを保管する。プロファイルストア２２６２は、ユーザがどのように通知されるかに影響するパラメータに関する情報を保管するものと見なすことができる。本明細書で説明したように、プリファレンスは、ユーザが図式化されたロジックを使用することによって、例えばＩＦ−ＴＨＥＮフォーマットで、指定することができる。ユーザコンテキストモジュール２２６０は、例えばホワイトボード２２６４にパブリッシュされる１つまたは複数のコンテキスト情報ソース２２８０に基づいて、ユーザの現在のコンテキストを判定する。ユーザコンテキストプロファイルストア２２６２は、ユーザが編集し変更することができる、ユーザのデフォルトコンテキストセッティングなどのユーザに関するコンテキストパラメータを保管する。すなわち、ユーザコンテキストモジュール２２６０は、プロファイルストア２２６２からの情報にアクセスし、および／または１つまたは複数のコンテキスト情報ソース２２８０を介してライブセンシングを用いてストア２２６２内の信念の前の組を更新することによって、ユーザの現在のコンテキスト情報に関する最良の推測または推定を提供する。プロファイルストア２２６２は、例えばユーザがどこにおり、何をしているかを先験的に保管するものと見なすことができる。
【０２３６】
ユーザコンテキストプロファイルストア２２６２は、決定論的プロファイルまたは確率的プロファイルなどの情報を取り込む事前に査定され、および／または事前に定義されたユーザプロファイルとすることができる。プロファイルは、通常の位置、アクティビティ、デバイス可用性、ならびに、時刻、日のタイプ、および１つまたは複数のデバイスとのユーザ対話などの観察の関数としての異なるクラスの通知のコストおよび価値とすることができる。日のタイプに、例えばウィークデイ、週末、および祝日を含めることができる。ユーザコンテキストモジュール２２６０は、ユーザの現在または将来の位置および注意状態などのユーザのコンテキストまたは状態の諸態様を能動的に判定または推論することができる。さらに、コンテキストの実際の状態を、ホワイトボード２２６４を介してコンテキスト情報ソース２２８０から直接にアクセスすることができ、および／または下で詳細に説明するように、ベイジアン推理などの推論方法を介して、様々な観察から推論することができる。
【０２３７】
コンテキスト情報ソース２２８０は、ユーザの注意状態および位置に関する情報をホワイトボード２２６４を介してユーザコンテキストモジュール２２６０に供給することができ、この情報から、モジュール２２６０は、ユーザの現在のコンテキスト（例えば、ユーザの現在の注意状態および位置）に関する判定を行うことができる。さらに、本発明は、コンテキスト情報ソース２２８０の特定の個数またはタイプに制限されず、ユーザコンテキストモジュール２２６０によって推論またはアクセスされる情報のタイプに制限されない。しかし、コンテキストソース２２８０に、例えば、マウス情報、キーボード情報、アプリケーション情報（例えば、どのアプリケーションが現在ユーザのフォーカスを受け取っているか）、環境音および発言情報、デスクトップのウィンドウ内のテキスト情報などの複数のデスクトップ情報およびイベントを含めることができる。ホワイトボード２２６４に、共通ストレージ領域を含めることができ、これに対して、コンテキスト情報ソース２２８０が、情報をパブリッシュでき、これから、ソースおよびコンテキストモジュール２２６０を含む複数のコンポーネントが、この情報にアクセスすることができる。通知または警告とも称するイベントまたはアクションに、一般に、世界の１つまたは複数の状態に関する観察に関する情報を含めることができる。そのような状態に、システムコンポーネントの状況、ユーザのアクティビティ、および／または環境に関する測定を含めることができる。さらに、測定デバイスおよび／またはイベントのソースの能動的ポーリングによって、支払いに対して送信される情報の受け取りによって、および／または一定のまたは可変のイベントハートビートごとに、イベントを生成することができる。
【０２３８】
他のタイプのコンテキストソース２２８０に、ユーザの個人情報マネージャ（ＰＩＭ）情報が含まれ、これは、一般に、例えばユーザのスケジュールに関するスケジューリング情報を提供することができる。現在時刻ならびにユーザの位置（例えば、全世界測位システム（ＧＰＳ）および／または位置を判定できるセル電話機、ＰＤＡ、またはラップトップ機のユーザによるアクセスによって判定される）も、コンテキストソース２２８０のタイプである。さらに、リアルタイムモバイルデバイス使用が、コンテキストソース２２８０の１タイプである。例えば、セル電話機などのモバイルデバイスは、それが現在ユーザによってアクセスされつつあるかどうか、ならびにデバイスの方位および傾き（例えば、やはりデバイス使用に関する情報を示す）と加速および速度（例えば、ユーザが移動しつつあるか否かに関する情報を示す）を判定できる場合がある。
【０２３９】
図２３を参照すると、上で説明した通知ソースが詳細に示されている。通知ソース２３２６〜２３２８は、一般に、通知実行エンジン２３２４に伝達される通知を生成し、通知実行エンジン２３２４は、通知を行うべき場合を判定し、そうである場合に、その通知を通知シンク２３３６〜２３３８のどれにどの順序で伝達すべきかを判定する。
【０２４０】
本発明の一態様によれば、通知ソース２３２６〜２３２８は、本明細書で通知ソーススキーマまたはソーススキーマと称する、属性および関係の標準的な記述内で、次のパラメータのうちの１つまたは複数を有することができる。スキーマは、上で説明したように、ソースについて、シンクについて、およびコンテキスト情報ソースについて設けることができることに留意されたい。そのようなスキーマは、異なるコンポーネントに関する宣言的情報を提供し、ソース２３２６〜２３２８、通知エンジン２３２４、シンク２３３６〜２３３８、およびコンテキストアナライザが、互いにセマンティック情報を共有することを可能にする。したがって、異なるスキーマは、通知に関連する性質、緊急性、およびデバイスシグナリングモーダリティに関する情報を提供する。すなわち、スキーマは、一般に、例えば、クラスと、イベントまたは通知のクラス、ソース、ターゲット、イベントまたは通知のセマンティックス、オントロジ的内容情報、観察信頼性、および実質的にすべてのサービス品質属性を含む情報を含む通知およびイベントの構造を定義するクラスの間の関係との集合として定義することができる。
【０２４１】
通知ソーススキーマのパラメータ（図示せず）に、メッセージクラス；関連性；重要性；時間クリティカル性；新規性；内容属性；忠実度トレードオフ、および／またはソース情報サマリ情報のうちの１つまたは複数を含めることができる。通知ソースによって生成される通知のメッセージクラスは、例えば、電子メール、インスタントメッセージ、数値金融更新、およびデスクトップサービスなどの通知の通信のタイプを示す。通知ソースによって生成される通知の関連性は、その通知に含まれる情報が、１つまたは複数の指定されたコンテキストに関連する尤度を示す。例えば、関連性は、ソースが所与のコンテキストに関連するか否かを示す論理フラグによって提供することができる。通知の新規性は、ユーザが通知に含まれる情報を既に知っている尤度を示す。すなわち、新規性は、経時的に、情報がユーザにとって新しいかどうかである（ユーザがその情報を知っているかどうかと、それについて警告されずに、将来、いつその情報を知るかを示す）。
【０２４２】
通知に関連する忠実度トレードオフは、例えば、指定された許容される切り捨ておよび／または要約の異なる形から生じる可能性がある通知内の情報の価値の損失を示す。そのような切り捨ておよび／または要約は、最初に生成された通知全体をシンクが受け取ることを阻む帯域幅制限および／または他の制限を有する可能性があるタイプの通知シンク２３３６〜２３３８に通知を伝達するために必要になる場合がある。一般に、忠実度は、通知に関連するオリジナル内容の性質および／または完全さの度合を指す。例えば、長い電子メールメッセージは、切り捨てられるか、セル電話機によって許容される最大１００文字までに要約され、忠実度の損失をこうむる場合がある。同様に、テキストおよびグラフィックスの内容を含むオリジナルメッセージが、テキスト機能だけを有するデバイスを介して送信される場合に、忠実度の損失を被る。さらに、デバイスが、ソースから入手可能な解像度全体の一部を示すことだけができる場合がある。忠実度トレードオフは、順序付け（例えば、まずグラフィックス、次にサウンドの順番でのレンダリングの重要性）および／または忠実度の変化に伴って通知の内容の総価値がどれほど減るかを示すコスト関数のいずれかに関して述べられたソースの忠実度プリファレンスのセットを指す。例えば、忠実度トレードオフは、完全な電子メールメッセージの送信に関連する価値全体が、切り捨ての量が増えるにつれてどのように変化するかを記述することができる。内容属性は、例えば、内容の性質の要約を含めることができ、コアメッセージにテキストコンポーネント、グラフィックスコンポーネント、およびオーディオコンポーネントが含まれるかどうかに関する情報などを表す。内容自体は、通知のメッセージ内容を構成する実際のグラフィックス、テキスト、および／またはオーディオである。
【０２４３】
通知の重要性は、情報が現在のコンテキストに関連すると仮定して、ユーザにとっての、通知に含まれる情報の価値を指す。例えば、重要性は、ユーザにとっての情報の価値のドル額として表すことができる。時間クリティカル性は、通知に含まれる情報の、時間依存の価値の変化すなわち、情報の価値が経時的にどのように変化するかを示す。すべてではないがほとんどの場合に、通知の情報の価値は、時間に伴って減少する。これを、図２４に示す。グラフ２４００に、経時的にマッピングされた通知の有用性を示す。最初の時を表すグラフの点２４０２で、通知の重要性が示されるが、曲線２４０４は、経時的な有用性の減少を示す。
【０２４４】
図２３に戻って、異なる通知ソースまたはソースタイプのデフォルト属性およびスキーマテンプレートは、図２２のストア２２４０などのユーザ通知プリファレンスストアに保管された通知ソースプロファイルで使用可能にすることができる。そのようなデフォルトテンプレートに、通知ソースによって提供される値をオーバーライドするか、ソースによって提供されるスキーマに欠けている場合に属性を提供するように指示することができる。ソースサマリ情報は、ソースが、ソースから使用可能な情報の状況の全般的なサマリおよび潜在的な通知をポストすることを可能にする。例えば、メッセージングソースからのソースサマリ情報に、少なくともある優先順位を有する未読メッセージの総数、ユーザと通信しようとする人による試みの状況、および／または他のサマリ情報に関する情報を含めることができる。
【０２４５】
通知シンク２３３６〜２３３８は、ユーザまたは他のエンティティが通知に含まれる情報について通知を受けることができる事実上すべてのデバイスまたはアプリケーションとすることができる。特定の通知を伝達するのにどのシンクを使用するかに関する選択は、通知エンジン２３２４によって決定される。
【０２４６】
通知シンク２３３６〜２３３８は、スキーマ内で提供される次のパラメータのうちの１つまたは複数を有することができる。このパラメータには、例えば、デバイスクラス；シグナリング（警告）のモード；および、関連するモードについて、忠実度／レンダリング能力、伝送信頼性、通信の実際のコスト、および／または中断の注意コストを含めることができる。警告属性のパラメータ化された制御に適合されたデバイスについて、そのデバイスのスキーマに、さらに、警告属性およびその属性を制御するためのパラメータの記述と、警告属性の異なるセッティングに伴って他の属性（例えば、伝送信頼性、配布のコスト）がそれによって変化する関数を含めることができる。通知シンクのスキーマは、通知デバイスがその性質および機能に関するセマンティック情報を通知実行エンジン２３２４および／またはシステムの他のコンポーネントと通信する形を提供する。異なるデバイスタイプのデフォルトの属性およびスキーマテンプレートは、前のセクションで説明した図２２のストア２２４０など、ユーザ通知プリファレンスストアに保管されたデバイスプロファイルで使用可能にすることができる。そのようなデフォルトテンプレートは、デバイスによって提供される値をオーバーライドするか、そのようなデバイスによって提供されるスキーマに欠けている場合に属性を提供するように指示することができる。
【０２４７】
スキーマパラメータのそれぞれを、これから順番に説明する。デバイスのクラスは、例えば、セル電話機、デスクトップコンピュータ、およびラップトップコンピュータなど、デバイスのタイプを指す。クラスは、モバイルデバイスまたは固定デバイスなど、より一般的なものとすることもできる。シグナリングのモードは、所与のデバイスが通知についてユーザに警告できる形を指す。デバイスは、１つまたは複数の通知モードを有することができる。例えば、セル電話機は、振動のみ、あるボリュームのベルのみ、および／または振動とベルの両方を行うことができる。さらに、警告システム用のデスクトップディスプレイは、複数の別個のモードに分解することができる（例えば、ディスプレイの右上の小さい通知ウィンドウ対スクリーン最上部の小さいサムネイル（オーディオ告知ありまたはオーディオ告知なし））。事前定義の挙動のセットに制限される他に、デバイスは、デバイス定義の一部として、パラメータの関数である警告属性を有するモードをイネーブルすることができる。あるモードのそのような連続的警告パラメータは、例えば、警告がデスクトップに表示されるボリューム、セル電話機のベル、警告ウィンドウのサイズなどのコントロールを表す。
【０２４８】
通知シンク２３３６〜２３３８のモードの伝送信頼性は、そのモードを用いてそのシンクを介してユーザに伝達される通知に関する通信される警告をユーザが受け取る尤度を示す。伝送信頼性は、デバイス可用性およびユーザのコンテキストに依存する可能性があり、あるデバイスの異なるモードの伝送信頼性は、ユーザの位置および注意などのコンテキスト的属性によって条件付けることができる。属性の抽象化として作成される分離として定義される（例えば、家庭から離れたすべての位置について、午後８時から正午までの時間期間で）独自の位置および独自の注意状態などの属性のクロス乗積によって定義される１つまたは複数の独自のコンテキスト的状態の伝送信頼性も、指定することができる。例えば、ユーザが現在どこにいるかに応じて、セル電話機に送信される情報が、特にユーザが間欠的カバレッジの領域内にいる場合、またはユーザがこの位置でセル電話機を有する傾向がない（例えば家族との休日）場合に、必ずしもユーザに達しない場合がある。コンテキストは、環境雑音および／またはコンテキストの他のマスキング特性または気をそらす特性の故に、伝送信頼性に影響する可能性もある。
【０２４９】
通信の実際のコストは、シンクに伝達される通知に含まれる場合のユーザへの情報の通信の実際のコストを示す。例えば、このコストに、セル電話送信に関連する料金を含めることができる。中断のコストに、特定のコンテキストでの、デバイスの特定のモードによって使用される警告に関連する中断に関連する注意コストが含まれる。注意コストは、通常は、ユーザの注意の特定のフォーカスに敏感である。忠実度／レンダリング機能は、モードを与えられた場合の、デバイスのテキスト機能、グラフィックス機能、およびオーディオ／触覚機能の記述である。例えば、セル電話機のテキスト限度は、単一のメッセージについて１００文字とすることができ、電話機は、グラフィックス機能を有しない場合がある。
【０２５０】
図２５を見ると、例示的インターフェース２５００に、ユーザの現在のコンテキストを判定する際にコンテキストアナライザによって使用できる、ユーザが選択可能なコンテキスト指定が示されている。ユーザによる直接指定によるユーザコンテキストおよび／またはユーザ変更可能なプロファイルの判定を説明する。ユーザのコンテキストに、ユーザの注意フォーカスすなわち、ユーザが現在通知警告の受け取りに反応できるかどうか、ならびにユーザの現在位置を含めることができる。しかし、本発明は、それに制限されない。
【０２５１】
ユーザによるコンテキストの直接指定によって、ユーザが、警告の受け取りに応えることができるかどうかと、それを受け取ることを望む場所を示すことが可能になる。デフォルトプロファイル（図示せず）を使用して、デフォルトの注意状態およびユーザが警告を受け取れるデフォルト場所を示すことができる。デフォルトプロファイルは、ユーザが望み通りに変更することができる。
【０２５２】
図２５を参照すると、インターフェース２５００に、本発明の態様に従って、コンテキストの直接指定がどのように実施されるかが示されている。例えば、ウィンドウ２５０２は、注意フォーカスセクション２５２０および位置セクション２５４０を有する。フォーカスセクション２５２０内で、ユーザは、例えば、ユーザがいつでも警告を受け取ることができるかどうか；ユーザが絶対に警告を受け取ることができないかどうか；およびユーザが所定の閾値を超える重要性レベルを有する警告だけを受け取ることができるかどうかを示す、１つまたは複数のチェックボックス２５２２にチェックマークを付けることができる。他の可用性選択を提供できることを諒解されたい。図２５からわかるように、閾値は、ドル単位で測定することができるが、これは例示のみを目的とし、本発明はこれに制限されない。ユーザは、新しい値を直接に入力することによって、または矢印２５２６を介して閾値を増減することによって、ボックス２５２４内の閾値を増やすことができる。
【０２５３】
位置セクション２５４０内で、ユーザは、ユーザが警告を伝達させることを望む場所を示すために、１つまたは複数のチェックボックス２５４２にチェックマークを付けることができる。例えば、ユーザは、デスクトップ機に、電子メールによって、ラップトップ機に、セル電話機で、自動車内で、ポケットベルで、携帯情報端末（ＰＤＡ）デバイスでなど、警告を伝達させることができる。しかし、これらが、例示のみであり、本発明自体が、それに制限されないことを諒解されたい。
【０２５４】
ウィンドウ２５０２は、セクション２５２０のチェックボックス２５２２およびボックス２５２４ならびにセクション２５４０のチェックボックス２５４２のプリセットデフォルトを設けることができるが、デフォルトユーザプロファイルと考えることができる。プロファイルは、ユーザが自分の望みの選択によってデフォルト選択をオーバーライドできるという点で、ユーザ変更可能である。他のタイプのプロファイルを、本発明に従って使用することもできる。
【０２５５】
図２６を参照すると、本発明の態様による、例えば１つまたは複数のセンサを使用する、直接測定によるユーザコンテキストの判定が示されている。ユーザのコンテキストに、ユーザの注意フォーカスならびにユーザの現在位置を含めることができる。しかし、本発明自体は、それに制限されない。コンテキストの直接測定は、センサを使用して、ユーザが現在警告の受け取りに反応できるかどうかを検出し、ユーザが現在どこにいるかを検出できることを示す。本発明の一態様によれば、この説明の後のセクションで説明するように、推論分析を直接測定と共に使用して、ユーザコンテキストを判定することができる。
【０２５６】
図２６を参照すると、ユーザコンテキストの直接測定を達成できるシステム２６００が示されている。例えば、システム２６００に、コンテキストアナライザ２６０２と、それに通信的に結合された複数のセンサ２６０４〜２６１６すなわち、セル電話機２６０４、ビデオカメラ２６０６、マイクロホン２６０８、キーボード２６１０、ＰＤＡ２６１２、車両２６１４、およびＧＰＳ２６１６が含まれる。図２６に示されたセンサ２６０４〜２６１６は、例示のみを目的とし、本発明自体に対する制限または制約を表すものではない。本明細書で使用される用語センサは、一般的で過度に包括的な用語であり、コンテキストアナライザ２６０２が、それによってユーザの現在の注意フォーカスが何であり、および／またはユーザの現在位置がどこであるかを判定できるすべてのデバイスまたは形を意味する。
【０２５７】
例えば、ユーザが、セル電話機２６０４をオンにしている場合に、これは、ユーザがセル電話機２６０４で警告を受け取れることを示すことができる。しかし、ユーザが、現在、セル電話機２６０４で通話中である場合に、これは、ユーザの注意フォーカスが他の何か（すなわち、現在の電話呼び出し）にあり、ユーザが、現在通知警告によって邪魔されてはならないことを示すことができる。ビデオカメラ２６０６は、例えば、ユーザのオフィスにあって、ユーザがオフィスにいるかどうか（すなわちユーザの位置）と、他者もユーザのオフィスにおり、ユーザが彼らと会っており、ユーザの邪魔をしてはならない（すなわちユーザのフォーカス）ことが示されるかどうかを検出することができる。同様に、マイクロホン２６０８も、ユーザのオフィスに置いて、ユーザが誰かと話しており、ユーザの邪魔をしてはならないか、キーボードをタイプしており（例えば、それから発する音を介して）、やはり現在ユーザの邪魔をしてはならないかどうかを検出することができる。キーボード２６１０を使用して、ユーザが現在それをタイプしているかどうかを判定することもでき、例えば、ユーザが非常に早くタイプしている場合に、これは、ユーザが、コンピュータ関連のアクティビティに焦点を合わせており、不当に邪魔をしてはならないことを示すことができる（また、ユーザが、実際にオフィスにいることを示すことができる）。
【０２５８】
ＰＤＡデバイス２６１２が、ユーザによってアクセスされつつある場合に、これは、ユーザが、デバイス２６１２で警告を受け取ることができることを示すことができる。すなわち、通知を伝達すべき位置は、デバイス２６１２がある場所である。デバイス２６１２は、ユーザの現在の注意フォーカスを判定するのにも使用することができる。車両２６１４は、ユーザが現在車両内にいるかどうか、すなわち、車両が、ユーザによって現在操作されつつあるかどうかを判定するのに使用することができる。さらに、車両の速度を考慮して、例えば、ユーザのフォーカスが何であるかを判定することができる。例えば、速度が所定の速度より高い場合に、ユーザが運転に焦点を合わせており、通知警告で邪魔してはならないと判定することができる。ＧＰＳデバイス２６１６も、当技術分野で既知のように、ユーザの現在位置を確認するのに使用することができる。
【０２５９】
この詳細な説明の次のセクションでは、ユーザが変更可能なルールに従うユーザコンテキストの判定を説明する。ユーザのコンテキストに、ユーザの注意フォーカスならびにユーザの現在位置を含めることができる。しかし、本発明はこれに制限されない。ルールを介するコンテキストの判定は、ｉｆ−ｔｈｅｎルールの階層セットに従って、ユーザの位置および／または注意フォーカスを判定できることを示す。
【０２６０】
図２７を参照すると、図に、ルールの例示的な階層順序付きセット２７００が示されている。ルールのセット２７００に、例えば、ルール２７０２、２７０４、２７０６、２７０８、２７１０、２７１２、および２７１４が示されている。他のルールを、同様に構成できることに留意されたい。図２７からわかるように、ルール２７０４および２７０６は、２７０２に従属し、ルール２７０６は、ルール２７０４に従属し、ルール２７１４は、ルール２７１２に従属する。ルールは、ルール２７０２が最初にテストされ、真であるとわかった場合に、ルール２７０４がテストされ、ルール２７０４が真であるとわかった場合に、ルール２７０６がテストされるように順序付けられている。ルール２７０４が偽であるとわかった場合には、ルール２７０８をテストする。ルール２７０２が偽であるとわかった場合には、ルール２７１０をテストし、これが真であるとわかった場合には、ルール２７１２をテストし、これが真であるとわかった場合には、ルール２７１４をテストする。ルールは、ユーザ作成可能および／または変更可能であることが望ましい。他のタイプのルールも、ルールのセット２７００に含めることができる（例えば、ｉｆ−ｔｈｅｎルールが偽であるとわかった場合に、ｏｔｈｅｒｗｉｓｅルールが制御することができる）。
【０２６１】
したがって、ユーザのコンテキストが判定されるように、ユーザがルールのセットを構成することができる。例えば、位置に関して、ルールのセットを、現在の日がウィークデイであるかどうかを第１ルールがテストするものとすることができる。そうである場合に、第１ルールに従属する第２ルールで、現在時刻が午前９時と午後５時の間であるかどうかをテストする。そうである場合に、第２ルールは、ユーザがオフィスにいることを示し、そうでない場合にはユーザが自宅にいることを示す。第１ルールが偽である、すなわち、現在の日が週末であってウィークデイでないとわかった場合に、ｏｔｈｅｒｗｉｓｅルールが、ユーザが自宅にいると述べることができる。この例が、本発明の制限的な例を意味するものではなく、１つまたは複数の他のルールを、同様に構成できることに留意されたい。
【０２６２】
この説明の次のセクションでは、統計モデルおよび／またはベイジアンモデルを使用することによるなど、推論分析によるユーザコンテキストの判定を説明する。推論分析を介するコンテキスト判定が、前に説明したセンサを介する直接判定など、他の判定のある態様に頼ることができることに留意されたい。本明細書で使用される推論分析は、出力変数すなわち、ユーザの現在のコンテキストを作るために、複数の入力変数に対して推論プロセスを使用することを指す。この分析に、一態様で、統計モデルおよび／またはベイジアンモデルの使用を含めることができる。
【０２６３】
図２８を参照すると、システム２８００の図に、本発明の態様による、ユーザコンテキスト２８０４を判定するために推論分析が推論エンジン２８０２によって実行されるシステム２８００の図が示されている。エンジン２８０２は、一態様で、メモリなど、コンピュータのコンピュータ可読メディアからコンピュータのプロセッサによって実行されるコンピュータプログラムである。ユーザコンテキスト２８０４は、エンジン２８０２の出力変数と考えることができる。
【０２６４】
エンジン２８０２は、１つまたは複数の入力変数を処理して、コンテキスト判断を行うことができる。そのような入力変数に、例えば、この説明の前のセクションでコンテキスト判定の直接測定手法に関して説明したセンサなどの１つまたは複数のセンサ２８０８、ならびにユーザのスケジューリングプログラムまたは個人情報マネージャ（ＰＩＭ）コンピュータプログラムおよび／またはユーザのＰＤＡデバイスでアクセスできるクロック２８１０およびカレンダ２８１２によって表されるものなどの現在日時を含めることができる。図２８に示されたもの以外の他の入力変数も、検討することができる。図２８の変数は、本発明自体に対する制限または制約となることを意図されたものではない。
【０２６５】
図２９および３０を参照すると、本発明の態様による、上で説明した推論エンジンによって実行できる統計モデルおよび／またはベイジアンモデルによって提供されるものなどの例示的推論モデルが示されている。一般に、コンピュータシステムは、ユーザの状態の詳細に関して多少不確かである可能性がある。したがって、不確実性の下でユーザの注意または他の状態に関する推論を行うことができる、確率モデルを構成することができる。ベイジアンモデルは、ユーザの注意のフォーカスに関する確率分布を推論することができる。そのような注意の状態は、プロトタイプ的状況のセットまたはユーザによって対処される認識の課題の別個のクラスのセットのより抽象的な表現として定式化することができる。その代わりに、注意フォーカスの継続的測定値に関する推論を行うモデルおよび／または異なるタイプの通知の割込みのコストに対する確率分布を直接に推論するモデルを定式化することができる。
【０２６６】
ユーザのアクティビティおよび位置に関する観察のセットに基づいて代替アクティビティコンテキストまたは状態の確率を推論できるベイジアンネットワークを使用することができる。例として、図２９に、単一時間期間のユーザの注意のフォーカスを推論するベイジアンネットワーク２９００を示す。変数の状態、注意のフォーカス２９２０は、デスクトップコンテキストおよび非デスクトップコンテキストを指す。このモデルで検討される例示的な注意コンテキストに、例えば、状況の意識、キャッチアップ、非特有バックグラウンドタスク、フォーカスのあるコンテンツの生成または再検討、軽いコンテンツの再生または再検討、文書のブラウズ、オフィスでの会議、オフィスの外での会議、プレゼンテーションの傾聴、プライベートタイム、家族との時間、個人的フォーカス、軽い会話、および旅行が含まれる。ベイジアンネットワーク２９００は、ユーザの現在の注意および位置が、ユーザのスケジューリングされた面会予定２９３０、時刻２９４０、および締切の近接２９５０によって影響されることを示す。ユーザの注意に関する確率分布は、例えば、ユーザのオフィスで監視される環境音響信号２９６０の状況のサマリによっても影響される。経時的な環境音響信号２９６０のセグメントは、アクティビティおよび会話の存在に関する手がかり／入力を提供する。ソフトウェアアプリケーションの状況および構成と、コンピュータと対話するユーザによって生成されるユーザアクティビティの進行中のストリームも、ユーザの注意に関する証拠のソースを提供する。
【０２６７】
ネットワーク２９００からわかるように、現在、オペレーティングシステムまたは他の環境の最上位のフォーカスにあるソフトウェアアプリケーション２９７０は、ユーザのフォーカスおよびタスクの性質に影響し、ユーザの注意の状況およびフォーカスのあるアプリケーションは、一緒に、計算中心型アクティビティに影響する。そのようなアクティビティに、マウスおよびキーボードのアクションのシーケンスから作られるユーザアクティビティのストリームと、より広い計画対象期間にわたるアプリケーション使用の高水準パターンが含まれる。そのようなパターンに、電子メールセントリックおよびワードプロセッサセントリックが含まれ、複数のアプリケーションがインターリーブされる形を伴うアクティビティのプロトタイプ的クラスが参照される。
【０２６８】
図３０に、異なる時間の期間でのコンテキスト変数の間でのユーザの注意フォーカスのベイジアンモデル３０００を示す。マルコフ時間依存性のセットが、モデル３０００によって示され、コンテキスト変数の過去の状態は、ユーザの状態の現在の判定で検討される。リアルタイムで、そのようなベイジアンモデル３０００が、例えば、オンラインカレンダによって提供される情報と、イベント感知システム（図示せず）によって報告される部屋の音響およびユーザアクティビティに関する観察のストリームを検討し、ユーザの注意の確率分布に関する推論結果を提供し続ける。
【０２６９】
図３１および３２に、本発明に従って、コンテキストアアナライザおよび通知エンジンなどの通知アーキテクチャの諸部分を提供する方法論を示す。説明を単純にするために、この方法論を、一連の動作として図示し、説明するが、本発明によれば、一部の動作を、図示し、本明細書で説明するものと異なる順序でおよび／または他の動作と同時に実行できるので、本発明が、動作の順序によって制限されないことを理解し、諒解されたい。例えば、当業者は、この方法論を、その代わりに、状態図でなど、一連の相互に関係する状態またはイベントとして表現できることを理解し、諒解するであろう。さらに、示された動作のいずれかが、本発明による方法論の実施に必要ではない可能性がある。
【０２７０】
図３１を参照すると、流れ図３１００に、本発明によるユーザのコンテキストの判定が示されている。この処理には、３１０２でユーザの位置を判定することと、３１４０でユーザのフォーカスを判定することが含まれる。これらの動作は、前に説明した手法のうちの１つまたは複数によって達成することができる。例えば、プロファイルを使用することができ；ユーザが自分のコンテキストを指定することができ；コンテキストの直接測定を使用することができ；ルールのセットに従うことができ；ベイジアンモデルまたは統計モデルを介するなどの推論分析を実行することもできる。他の分析を使用して、ユーザのコンテキストを判定できることを諒解されたい。例えば、誰かがコンピュータの前にいるかどうかおよびその人がコンピュータを見ているかどうかに注目する一体化されたビデオカメラソースを設けることができる。しかし、このシステムが、カメラありまたはカメラなしで動作できることに留意されたい。すべてのソースについて、このシステムは、コンテキストに関して推論するために特定のソースを必要とするのではなく、実質的にすべての使用可能なソースと共に動作することができる。さらに、他の態様で、ユーザの位置および注意の感知を与える、小さいＰＤＡ上の一体化された加速度計、マイクロホン、および近接検出器を設けることができる。
【０２７１】
図３２を参照すると、流れ図３２００に、本発明の態様による通知エンジンの判断プロセスが示されている。３２０２で、１つまたは複数の通知ソースが、通知を生成し、この通知が、通知エンジンによって受け取られる。３２０４で、コンテキストアナライザが、ユーザに関するコンテキスト情報を生成／判定し、これが、３２０６で、通知エンジンによって受け取られる。すなわち、本発明の一態様によれば、３２０６で、この説明の前のセクションで説明したように、コンテキストアナライザが、ユーザの現在の注意状況および位置を示すユーザコンテキスト情報プロファイルにアクセスし、および／または１つまたは複数のコンテキスト情報ソースからユーザの現在の注意状況および位置に関するリアルタイム情報を査定する。３２０８で、通知エンジンが、コンテキストアナライザから受け取ったコンテキスト情報に部分的に基づいて、どの通知をどの通知シンクに伝達するかを決定する。通知エンジンは、コンテキストアナライザによって保管されたユーザの通知パラメータに関する情報に基づく判定も行う。すなわち、一態様によれば、３２０８で、エンジンは、ユーザが所与の通知について警告されなければならないかどうかと、ユーザにどのように通知しなければならないかに関する、決定論的分析を実行する。下で詳細に説明するように、決定論的なおよび／またはヒューリスティックな分析、決定、およびポリシを、３２０８で使用することができる。ユーザに関する通知パラメータを使用して、欠けている値を満たすことによるか、ソースまたはシンクのスキーマで提供されるパラメータをオーバーライドすることによって、分析をパーソナライズすることができる。通知プリファレンスは、決定論的分析の代わりに使用されるポリシ（例えば、ヒューリスティック）も提供することができる。この決定に基づいて、通知エンジンは、３２１０で通知をディストリビュータに伝達する。
【０２７２】
データ駆動アプリケーションインストール
本発明のもう１つの態様によれば、事前定義のテーブルを更新することによって、情報エージェントアプリケーションのインストールを達成することができる。従来の通知システムならびに他のアプリケーションプログラムには、通常、それがインストールされる場合のデータベースオブジェクトの急増が伴う。すべてのアプリケーションが、慣習的に、インストールプロセス中にプロシージャならびに大量のテーブルおよびデータベースを保管しなければならなかった。しかし、本発明は、異なる手法を使用する。第１に、情報エージェントシステム１００などのシステムまたはプラットフォームがインストールされる場合に、テーブルの基礎セットを作成することができる。したがって、アプリケーションインストールには、単に、既存テーブルにデータを挿入することが含まれる。この手法では、インストールされるアプリケーションの数が増える際のデータベースオブジェクトの急増が除去され、拡張性が可能になる（下で説明する）。
【０２７３】
前述を達成するために、イベント、プリファレンス、およびプロシージャのすべてを、データとして保管することができる。これによって、システムが、データベースエンジンおよびクエリのますます高まる処理能力を活用して、情報エージェントアプリケーション３００（図３）などの複数のアプリケーションを実行することが可能になる。上で説明したように、プリファレンスは、エンドユーザによって定義され、その後、テーブルおよびデータベース内の高水準データフィールドに抽出することができる。イベントをキャプチャするか取り出し、その後、データベースに保管することができる。クエリ評価プロシージャなどの従来のストアドプロシージャも、プロシージャを作成し、そのテキストを１つまたは複数のデータベーステーブルにロールすることによって、データとして表すことができる。その後、プロシージャが実行される場合に、プロシージャを表すテキストのストリングが、データベーステーブルから引き出され、データベース内で動的に評価される。この手法は、アプリケーションが作成する必要のあるストアドプロシージャの数を劇的に減らし、アプリケーションインストールを、単なるＤＭＬ（データ操作言語）データ駆動動作にする。
【０２７４】
結合可能性（ｃｏｍｐｏｓａｂｉｌｉｔ）および拡張性
このセクションでは、最初の作成の時に情報エージェントアプリケーションがどのように構成され、後にどのように拡張されるかを説明する。情報エージェントアプリケーション（ＩＡアプリケーション）は、エンドユーザが、ｅｖｅｎｔ−ｃｏｎｄｉｔｉｏｎ−ａｃｔｉｏｎ（ＥＣＡ）モデルを介して基礎になるシステムまたはアプリケーションドメインと対話することを可能にするように設計される。具体的に言うと、情報エージェントアプリケーションは、特に、ユーザコンテキストへの感度が重要である情報のルーティング、フィルタリング、および処理を扱う問題ドメインに関して、他のアプリケーション機能をどのように適用するかを制御するプリファレンスをユーザが記述できることを可能にするように設計される。これに基づいて、情報エージェントアプリケーションの結合可能性および拡張性は、基礎になるシステムまたはアプリケーションドメインの構成または拡張を対象とするのではなく、ユーザがプリファレンスを効果的に作成する能力（新ＥＣＡインスタンス化）を対象とすると理解されたい。
【０２７５】
新しいアプリケーション、コンポーネント、またはシステムモデルを作成することは、情報エージェントアプリケーションの結合可能性および拡張性の目標ではない（これは可能であり、本発明の範囲内で検討されなければならないが）。そうではなく、目標は、ユーザがＥＣＡモデル（例えば判断ロジックコンポーネント３３０）を介してプリファレンスロジックを指定できるようにするレイヤまたはシステムのコンポーネントへの動的拡張を可能にすることである。具体的に言うと、所与のアプリケーションがインストールされた時の後に、新しい条件およびアクション（ＥＣＡのＣＡ部分）をエンドユーザが使用可能にすることを可能にすることである。さらに、イベント（ＥＣＡのＥ部分）も、類似する形で動的に拡張できることも諒解されたい。
【０２７６】
本発明の一態様によれば、情報エージェントアプリケーションは、プリファレンスを定義するためにそれ自体のユーザインターフェースを有するのではなく、その代わりに、プリファレンス作成に関してオペレーティングシステムインターフェースまたはアプリケーション固有ユーザインターフェースのいずれかを使用する。このコンテキストで、情報エージェントアプリケーションの結合可能性および拡張性は、その後に既存ユーザインターフェースを使用して、ユーザが新しい条件およびアクションを有する新しいプリファレンスを作成できるようにすることができる形で新しい条件およびアクションを追加するように設計される。これに関して、ＩＡアプリケーションは、新しい機能性のシグネチャを拡張を提供する記述と共に適当に表示できて、新しい条件およびアクションをいつどのように適当に使用するかに関するエンドユーザコンテキストを提供するように、新しい条件およびアクションに対するリフレクションをサポートすることができる。
【０２７７】
情報エージェントアプリケーションの、様々なコンテキスト内で様々な時に、多様性が存在する。具体的に言うと、ＩＡアプリケーションは、それ自体で完全な自立したものとすることができるが、多数のＩＡアプリケーションは、実際には、他のＩＡアプリケーションと相互作用し、これらによって提供される機能性を活用する。具体的には、あるアプリケーションによって定義された条件およびアクションの機能を、他のアプリケーションによって使用することもできる。ＩＡエージェントは、複数の他の形で互いに相互作用することもできる。例えば、あるＩＡアプリケーションでのプリファレンス評価が、別のＩＡアプリケーションにサブミットされるイベントを作るアクションにトリガをかけることができる。
【０２７８】
結合可能性と拡張性の間の区別は、情報エージェントアプリケーションの集合がどのように相互作用し、展開するかを理解するのに重要である。結合可能性は、アプリケーションが最初に作成される時に存在し、他の情報エージェントアプリケーションによって提供される機能に基づいて作られる新しい情報エージェントアプリケーションが作成される場合に使用される概念である。拡張性は、既に存在する情報エージェントアプリケーションを、そのアプリケーションが作成またはインストールされた後に作られた新しい機能性によって拡張する概念および処理を指す。さらに、共通の機構のセットが、結合可能性および拡張性の両方のサポートに使用されるので、そのような共通の機構が、結合可能性と拡張性の多少異なる目的を達成するのにどのように使用されるかの微妙な相違を理解することが重要である。ＩＡアプリケーション結合可能性という概念は、単一のＩＡアプリケーションを個々の部分のセットから構成するプロセスにも適用可能である。結合可能性のこの態様は、モジュールの形でのＩＡアプリケーションの開発というソフトウェアエンジニアリング目標に対処する。ＩＡアプリケーションシステムに導入されつつある拡張性という概念は、拡張性の伝統的な概念と一貫する。すなわち、新しい機能性が、ＩＡアプリケーションの最初の定義の後に追加され、これによって、そのアプリケーションの機能が拡張される。
【０２７９】
かなりの程度まで、ＩＡアプリケーションの尺度は、ユーザに提示される機能によって決定される。したがって、ＩＡアプリケーションが拡張可能である度合は、既存アプリケーションのコンテキスト内で新しいプリファレンスを定義するユーザに新しい条件およびアクションが使用可能にされる範囲によって決定することができる。ＩＡアプリケーション拡張性は、主に、最初のアプリケーションの作成者によるさらなる介入なしで、アプリケーションがインストールされた時の後に新しい条件およびアクションをアプリケーションに追加することを可能にすることを目指す。これをどのように行うかを理解するために、アクションまたは条件の機能の定義が最終的に情報エージェントアプリケーションのエンドユーザからアクセス可能になる進化チェーンを強調することが重要である。
【０２８０】
図３３を見ると、本発明の態様による条件／アクション進化チェーン３３００が示されている。条件およびアクションは、３３１０で、条件機能またはアクション機能として開始される。この機能指定は、例えばＳＱＬ呼び出し可能間数／ストアドプロシージャの定義の形式シグネチャを参照する場合に使用することができる。新しい条件機能またはアクション機能が定義される時と、機能が対応する条件またはアクションの宣言によって既存アプリケーションにバインドされる時の間に、機能は、候補機能と考えられる。３３２０で、候補機能の開発者は、ターゲットの拡張されるアプリケーションが候補条件または候補アクションと称する機能から条件またはアクションを作成できるようにするバインディングを指定する。この段階で、条件またはアクションは、アプリケーションが条件またはアクションを使用できるが、それを受け入れる必要がない、既存の拡張されるアプリケーションによる使用のための候補である。拡張されるアプリケーションの受入ロジックは、例えば提案される拡張／バインディングに誰が署名したかに基づいて、そのバインディングを受け入れるか否かを決定する。アプリケーションが、そのプリファレンスクラスを条件機能またはロジック機能にバインドしたならば、候補条件または候補アクションが、３３３０で、単純に条件またはアクションになる。最後に、エンドユーザが、新たに定義されたプリファレンスのコンテキスト内で条件またはアクションを使用する場合に、そのアクションまたは条件が、チェーンの３３４０に示されているように、インスタンス化されると言う。
【０２８１】
図３４に、本発明の態様によるアプリケーション相互作用のシステム３４００を示す。システム３４００に、インスタンスレジストリコンポーネント３４１０、定義レジストリ３４１２、バインディングレジストリ３４１４、アプリケーションＡ３４３０、アプリケーションＢ３４４０、バインディング３４５０、および拡張コンポーネント３４２０が含まれる。拡張性の一実施形態で、開発の単位は、アプリケーションまたは拡張である。インスタンスは、アプリケーションまたはアプリケーションデータファイル（ＡＤＦ）を追加することによって拡張される。ＡＤＦは、単一アプリケーションが展開されている場合に使用するために開発者によって作成することができる。ＡＤＦは、一般に、アプリケーションの中央ロジックを定義し、なかんずく、イベント、条件、および通知などのアクションのスキーマを含めることができる。アプリケーションは、拡張または拡張データファイル（ＥＤＦ）を追加することによって拡張することができる。ＥＤＦは、誰でも作成でき、インスタンスおよびアプリケーションが作成された後（アプリケーションの最初のインストールを含む）のいつでも使用される。
【０２８２】
アプリケーションが機能性を共有するために、アプリケーションは、お互いを知る必要がある。本発明の態様によれば、これは、機能に関する情報および機能がアプリケーションにどのようにバインドされるかを保管する、定義レジストリ３４１２およびバインディングレジストリ３４１４からなるインスタンスレジストリ３４１０を使用することによって達成することができる。インスタンスレジストリ３４１０は、アプリケーションがデータを保管する共有位置を提供する。インスタンスレジストリ３４１０に、定義レジストリ３４１２およびバインディングレジストリ３４１４が含まれる。
【０２８３】
定義レジストリ３４１２は、アプリケーション機能に関する情報を保管する。本発明の態様によれば、アプリケーション（例えば、ＩＡアプリケーション）によって使用されるアプリケーション機能を、定義レジストリ３４１２に登録または保管することができる。定義レジストリ３４１２での機能の登録によって、その機能が、システムで動作するすべてのアプリケーションにパブリックになる。したがって、アプリケーションによって使用される機能は、それが定義レジストリに登録されていないことを意味する完全プライベート、または定義レジストリに登録され、他のすべてのアプリケーションからアクセス可能であることを意味するパブリックのいずれかである。これが、定義レジストリを実施する形の１つにすぎないことに留意されたい。もう１つの実施機構では、機能がパブリックまたはプライベートのどちらであるかを示すインジケータを保管することができる。定義レジストリに組み込むことができる例の情報に、次が含まれる。
【０２８４】
【表３１】
2007518151.tif 000037
【０２８５】
バインディングレジストリ３４１４は、複数のアプリケーションからの、バインディング、条件、アクション、および機能へのアクセッサを保管することができる。これは、その機能が、最初の定義またはアプリケーションに対する後の拡張のどちらから導出されるかに無関係に真である。さらに、本発明の態様によれば、パブリック機能は、バインドするメタデータなしでは使用可能でないことに留意されたい。バインドするメタデータは、パブリック機能をアプリケーションデータイベントデータにどのようにバインドするかを指定する情報である。バインディングレジストリ３４１４にパブリック機能を登録することによって、アプリケーションに機能がバインドされる。これは、１対多関係であり、１つの機能を多数の異なるアプリケーションにバインドすることができる。
【０２８６】
バインディングレジストリ３４１４に登録されたバインディングは、複数の状況を有することができる。例えば、バインディングを、候補バインディングとすることができる。候補バインディングは、機能の定義者によって作成され、他のアプリケーションから使用可能にされる。バインディングは、特定のアプリケーッションが所与の条件機能またはアクション機能にどのようにバインドされるかを表す、バインディングが所与のアプリケーションに固有であることを示すバインドされた機能の状況を有することもできる。さらに、バインディングが、「受け入れられない」状況を有することができる。これらは、特定のアプリケーションをターゲットとするが、ターゲットにされたアプリケーションの受入ロジックによって受け入れられなかった候補機能である。受入ロジックは、ＡＤＦで宣言でき、とりわけ、ＥＤＦソースが真正であり（例えば、デジタル署名を使用する）、許可され（例えば、信頼されるソースのリストから）、証明される（ＥＤＦが信頼されるソースによって署名されている）ことを保証するコンポーネントを含めることができる。バインディングレジストリ３４１４に収容できるさらなる情報に、次が含まれるが、これに制限はされない。
【０２８７】
【表３２】
2007518151.tif 000038
【０２８８】
拡張コンポーネント３４２０は、候補機能に基づいて、条件およびアクションを作成する。拡張コンポーネント３４２０は、候補機能をアプリケーションにバインドするために、インストール時にインストールスクリプトによって呼び出すことができる。新しい候補機能エントリが、バインディングレジストリ３４１４内で作られる場合に、ターゲットアプリケーションの側で行われるアクションまたはアクションの欠如に応じて、複数のことが起こる可能性がある。例えば、ターゲットアプリケーションがインストールされていない場合に、エントリを無視することができる。ターゲットアプリケーションがインストールされているが、拡張を受け入れるように構成されていない場合に、やはり、エントリを無視することができる。しかし、ターゲットアプリケーションがインストールされており、候補機能を受け入れる場合には、新しい条件、アクション、またはアクセッサのバインディングが、そのアプリケーション用に作成され、拡張コンポーネント３４２０を使用してアプリケーションにバインドされる。したがって、システム３４００で、アプリケーションＡ３４３０に、アプリケーションＢ３４４０から使用可能にされることが望まれるローカル機能「ＣｏｎｄｉｔｉｏｎＦｕｎｃｘ」が含まれる。この機能は、拡張データファイル（ＥＤＦ）を追加することによってアプリケーションＢ３４４０から使用可能にすることができる。その後、この機能が、アプリケーションＢ３４４０から使用可能になる形でインスタンスレジストリ３４１０に保管される。例えば、ＣｏｎｄｉｔｉｏｎＦｕｎｃＸを、定義レジストリ３４１２に登録することができ、候補機能を、バインディングレジストリ３４１４に保管することができる。拡張コンポーネント３４２０は、バインディングレジストリ３４１４から候補機能を読み取り、アプリケーションＢ３４４０にバインドすることによって条件Ａを作成することができる。したがって、バインディング３４５０が作成され、条件ＡがアプリケーションＡのＣｏｎｄｉｔｉｏｎＦｕｎｃＸにバインドされる。
【０２８９】
バインディングまたは依存性が確立されたならば、これらを多数の形で破壊できることに留意されたい。例えば、アプリケーションによって実装される機能は、そのアプリケーションがアンインストールされた場合に使用不能になる可能性がある（すなわち、破壊された依存性）。依存性を破壊できるもう１つの例が、新しいアプリケーションが、もはや使用可能でない機能にバインドされた新しい条件、アクション、またはアクセッサと共にインストールされる場合である。アプリケーションがもはやすべてまたは特定の拡張を受け入れないように再構成される場合に、さらなる依存性を破壊することができる。したがって、既存プリファレンスは、もはや使用可能でない条件、アクション、またはアクセッサに対する依存性を有する場合がある。破壊された依存性は、多数の形で補償することができる。本発明の態様によれば、使用不能状態を定義することができる。例えば、アプリケーションが、結局依存性を破壊することを許可される前に、他のすべてのアプリケーションは、依存性プリファレンスを「ＮｏｔＡｖａｉｌａｂｌｅ（使用不能）」状態にすることができるように通知されることができる。その後、アプリケーションがインストールされる場合に、システムまたはアプリケーションは、使用不能状態を使用可能に変更でき、プリファレンスを利用できるようにするために、依存性が再確立されたかどうかを検査することができる。
【０２９０】
プリファレンスを、情報エージェントアプリケーションの間で作成することができる。プリファレンスインストールは、ＩＡアプリケーションの間の相互作用を達成できる方法を表す。本発明の態様によれば、複数のＩＡアプリケーションで機能にアクセスするプリファレンスをユーザが作成できるようにする少なくとも２つの機構を提供することができる。１つの機構が、ＥＤＦバインディングである。アプリケーション開発者は、ＥＤＦバインディングを作成して、あるアプリケーションのプリファレンスクラスが他のアプリケーションで定義された条件およびアクションを参照できるようにすることができる。これによって、エンドユーザが、複数のアプリケーションからの条件およびアクションを参照するプリファレンスをインスタンス化できるようになる。イベントサブミッションアクションは、複数のアプリケーションによって提供される機能を利用することもできる。イベントサブミッションアクション機能は、イベントクラスがアプリケーションによって定義される場合に暗黙のうちに作成することができる。その後、これらのイベントサブミッションアクション機能を、他のアプリケーションによって使用されるＥＤＦを介してアクションにバインドすることができ、これによって、新たに作成されるユーザプリファレンスの潜在的な機能性が豊かになる。
【０２９１】
アプリケーションが、エンドユーザではなくアプリケーション開発者によって指定されるプリファレンスを直接にインスタンス化することを可能にするために、追加の機構またはコンポーネントが必要になる場合がある。１つの機構またはコンポーネントが、プリファレンステンプレートに対応することができる。プリファレンステンプレートは、プリファレンスクラスのコンテキストで定義することができ、条件およびクラスのセットを含む。プリファレンスクラスの構文を、テンプレートを定義するための新しいタグを用いて拡張することができる。その後、このタグを、新しいテンプレートを用いてアプリケーションを拡張するためにＥＤＦによって使用することができる。プリファレンスインスタンス化アクションを使用することもできる。新しいプリファレンステンプレートが作成される場合に、アクション機能を暗黙のうちに作成して、指定されたテンプレートからプリファレンスをインスタンス化することができる。そのアクション機能へのパラメータは、そのテンプレートの条件アクションの固定されたセットからプリファレンスをインスタンス化するのに必要な定数を表す。
【０２９２】
開発者は、エンドユーザによる明示的干渉なしに、アプリケーション内およびアプリケーション間の両方でプリファレンスをインスタンス化することもできる。複数の機構を使用して、この機能性を達成することができる。例えば、新しいＡＤＦタグをプリファレンスクラスに追加して、アプリケーション定義時に直接にＡＤＦ内でプリファレンスをインスタンス化することを可能にすることができる。その代わりに、新しいＥＤＦタグを、プリファレンスクラスに追加することができる。これによって、アプリケーションの定義中およびその後の両方に、プリファレンスをインスタンス化することが可能になる。さらに、プリファレンスインスタンス化は、例えばシステムＡＰＩの使用を介して、スキーマ定義の外部でスクリプト（例えばＳＱＬスクリプト）を介して達成することができる。
【０２９３】
前述の機能があれば、１つのアプリケーションがイベントを送る時、条件／アクションを評価する時、または他のアプリケーションでプリファレンスをインスタンス化する時に、アプリケーション（例えば、ＩＡアプリケーション）相互作用を行うことができる。そのような相互作用は、開発者によって直接に、またはエンドユーザ定義のプリファレンスを介して達成することができる。
【０２９４】
アプリケーションの結合可能性および拡張性の様々な態様のさらなる理解のために、複数の例を下で提供する。ＳｈｅｌｌＡｐｐは、オペレーティングシステム情報エージェントアプリケーションである。Ｏｆｆｉｃｅも、情報エージェントアプリケーションである。
【０２９５】
例１  構成
構成は、既存の既知の機能をバインドするために新しいアプリケーションがオーサリングされる場合に定義することができる。この場合に、ＳｈｅｌｌＡｐｐが、まずインストールされ、その後、Ｏｆｆｉｃｅがインストールされる。Ｏｆｆｉｃｅがオーサリングされた場合に、開発者は、ＳｈｅｌｌＡｐｐのＦｕｎｃＸ条件機能について知っており、これを活用するようにＯｆｆｉｃｅアプリケーションを設計した。Ｏｆｆｉｃｅがインストールされる場合に、Ｏｆｆｉｃｅは、ＦｕｎｃＸ条件機能（古い機能）をＯｆｆｉｃｅアプリケーション（新しいアプリケーション）の条件にバインドするバインディングをバインディングレジストリに登録する。Ｏｆｆｉｃｅアプリケーションインストールスクリプトが、拡張コンポーネントを呼び出し、この拡張コンポーネントが、バインディングレジストリを読み取る。拡張コンポーネントは、条件定義が既にある（「組み込まれている」）ことを検出でき、したがって、インスタンス全体でＮｏｔＡｖａｉｌａｂｌｅ状態を再評価する次のステップをスキップする。このＯｆｆｉｃｅアプリケーションを、ＳｈｅｌｌＡｐｐによって拡張されたと言う。
【０２９６】
例２  拡張
拡張は、新しい機能を用いて古いアプリケーションを拡張する場合に定義することができる。この例では、上と同様に、ＳｈｅｌｌＡｐｐがインストールされ、その後、Ｏｆｆｉｃｅがインストールされる。Ｏｆｆｉｃｅがオーサリングされた場合に、開発者は、ＳｈｅｌｌＡｐｐで使用できるアクション機能ＦｕｎｃＹを作成した。Ｏｆｆｉｃｅがインストールされる場合に、Ｏｆｆｉｃｅは、アクション機能を定義レジストリに登録し、ＯｆｆｉｃｅアプリケーションのＦｕｎｃＹ（新しい機能）をＳｈｅｌｌＡｐｐ（古いアプリケーション）のアクションにバインドするバインディングをバインディングレジストリに登録する。Ｏｆｆｉｃｅアプリケーションのスクリプトが、拡張コンポーネントを呼び出して、ＳｈｅｌｌＡｐｐに対応するアクションがない新しいバインディングがあることを検出し、したがって、そのアクションをＳｈｅｌｌＡｐｐ内で作成することによって、そのアクションを内部化する。次に、このスクリプトは、インスタンス全体のＮｏｔＡｖａｉｌａｂｌｅ状態を再評価する。ＳｈｅｌｌＡｐｐは、Ｏｆｆｉｃｅアプリケーションによって拡張されたと言う。
【０２９７】
例３  パッチ拡張
パッチは、機能とアプリケーションの両方がシステムに既にインストール済みである場合に行うことができる。したがって、ＳｈｅｌｌＡｐｐとＯｆｆｉｃｅの両方がシステムにインストールされており、その後、オフィスサービスパックがインストールされると仮定する。Ｏｆｆｉｃｅアプリケーションの公開の後に、開発者は、ＳｈｅｌｌＡｐｐが使用できるアクション機能がＯｆｆｉｃｅにあることを理解する。サービスパックに、なかんずく、新しいＯｆｆｉｃｅアプリケーション条件をＯｆｆｉｃｅアプリケーションの条件機能にバインドするバインディングを定義するＥＤＦが含まれる。このサービスパックがインストールされる場合に、このサービスパックは、そのバインディングをバインディングレジストリに登録し、拡張コンポーネントを呼び出すことができる。拡張コンポーネントは、ターゲットアプリケーションに対応するアクションまたは条件を有しない新しいバインディングがあることを検出し、その後、これらをＳｈｅｌｌＡｐｐおよびＯｆｆｉｃｅアプリケーションで作成することができる。次に、拡張コンポーネントは、インスタンス全体のＮｏｔａｖａｉｌａｂｌｅ状態を再評価することができる。ＳｈｅｌｌＡｐｐが、Ｏｆｆｉｃｅアプリケーションによって拡張されたと言い、Ｏｆｆｉｃｅは、ＳｈｅｌｌＡｐｐによって拡張されたと言うことができる。
【０２９８】
例４  アンインストール
前にインストールされたＯｆｆｉｃｅアプリケーションが、アンインストールされており、その処理中に、定義レジストリおよびバインディングレジストリからすべての登録を削除したと仮定する。ＳｈｅｌｌＡｐｐは、今は除去されているＯｆｆｉｃｅによって実装された機能に依存するアクションを有する可能性がある。したがって、使用不能またはＮｏｔＡｖａｉｌａｂｌｅ状態を、破壊された依存性を有するすべてのアクションについて宣言することができる。次に、エンドユーザは、欠けている依存性に関する手がかりを受け取ることができる。次に、エンドユーザは、使用不能なプリファレンスまたはアクションをそのままにする（例えば、Ｏｆｆｉｃｅが戻される場合に備えて）または単純にそれらを削除することを選ぶことができる。
【０２９９】
例５  再インストール
前にアンインストールされたＯｆｆｉｃｅというアプリケーションが、再インストールされ、インストール中に、アクション機能およびＳｈｅｌｌＡｐｐへのバインディングが再登録されたと仮定する。Ｏｆｆｉｃｅインストールスクリプトは、拡張コンポーネントを呼び出して、ＳｈｅｌｌＡｐｐ内でアクションを作成することができる。しかし、拡張コンポーネントは、条件、アクション、またはアクセッサが既にターゲットアプリケーションに存在する（例えば、アプリケーションが前にインストールされた）場合を単純に検出することができ、作成ステップをスキップする。その後、機能のＮｏｔａｖａｉｌａｂｌｅ状態を再評価して、アクティブになり得るすべての機能がイネーブルされた状態にされることを保証することができる。
【０３００】
パーソナライズされたフォルダ
上で述べ、説明したシステムは、情報アプリケーションの構成を容易にし、この情報アプリケーションは、イベントの所与のセットに関する判断およびアクションの処理を自動化する。したがって、デスクトップ通知および電子メールの到着を含むがこれに制限されないイベントへの応答をエンドユーザがパーソナライズすることを可能にするアプリケーションを作成することができる。そのようなアプリケーションの１つが、下で説明するパーソナライズされたフォルダアプリケーションである。本発明は、とりわけ図式化されたデータストアおよび図式化されたロジックを使用することによって、パーソナライズされたイベント処理などの機能性を可能にする。
【０３０１】
図３５を見ると、本発明の態様によるパーソナライズされたシステム３５００が示されている。システム３５００に、データストア１５０および情報エージェントアプリケーション３００が含まれ、情報エージェントアプリケーション３００には、パーソナライズされたフォルダ３５１０およびプリファレンス３５１２が含まれる。パーソナライズされたフォルダ３５１０は、エンドユーザが直観的に指定できる条件式に基づいてアイテムを含むか除外することができるフォルダまたはデータコンテナを指す。一例で、フォルダ３５１０を、オペレーティングシステムのコンポーネントによって、階層的な形で配置し、実装することができる。しかし、用語フォルダおよびデータコンテナの使用が、制限的な形であることを意味しないことに留意されたい。フォルダ３５１０は、関係のセットによって定義されるリンク、ポインタ、またはデータのすべての集合に拡張することができる。情報エージェントプリファレンス３５１２は、非技術的なエンドユーザが、図式化されたロジックと図式化されたデータを組み合わせて（例えば、データストア１５０を介して）、豊富なパーソナライズされたアプリケーションおよび環境を提供する能力を表す。対照的に、従来のプリファレンスは、単に、単純な条件をストリング定数が提供される直観的な名前と共に使用する。プリファレンス３５１２は、例えば、Ｏｎ  イベント  ＩＦ  条件  ＴＨＥＮ  アクションまたはよりアプリケーション固有のＯｎ  フォルダイベント  ＩＦ  条件  ＴＨＥＮ  ｉｎｃｌｕｄｅ／ｅｘｃｌｕｄｅアクションなどの馴染みのある形のロジックを使用してエンドユーザが指定することができる。さらに、プリファレンス３５１２は、ユーザアクションに基づいてユーザプリファレンスを学習するのに統計モデルおよび／またはベイジアンモデルを使用することによるなど、推論分析によって開発することができることに留意されたい。本明細書で使用される推論分析は、出力変数すなわち、ユーザプリファレンスまたはプリファレンス開発ツールへの入力を作るために、複数の入力変数に対して推論プロセスを使用することを指す。この分析に、一態様で、統計モデルおよび／またはベイジアンモデルの使用を含めることができるが、これに制限はされない。条件およびアクションの他に、プリファレンスに、プリファレンスの評価を開始するトリガが含まれる。本発明の一態様によれば、そのようなトリガに、明示的なユーザ指示、時間によるスケジューリング、および／または文書の追加、文書の削除、および／またはフォルダ内の文書の変更の際の自動的を含めることができる。さらに、プリファレンス３５１２をグループ化して、単一の式を介して簡単に作成するには複雑すぎる結果セットを達成できることを諒解されたい（例えば、フォルダに特定のアイテムを含める／除外する、複数のクエリの影響を組み合わせる）。さらに、個別のおよびグループのプリファレンス３５１２を、ユーザがフォルダ３５１０の間でドラッグし、ドロップし、切り取り、貼り付けることができる物理的エンティティとして表すことができることに留意されたい。フォルダ３５１０に、データのコピーまたは単純にストレージデバイスに保管されたデータへのポインタ���別名仮想フォルダ）を含めることができる。保管されたデータに、ワードプロセッシング文書、スプレッドシート、写真、および音楽を含めることができるが、これに制限はされない。さらに、パーソナライズされたフォルダ３５１０は、複数の異なるドメインのアイテムに関係する関連するプリファレンス３５１２を有することができる。そのような機能性をサポートするために、事前定義の定数を導入することができる。具体的に言うと、１つのアイテムドメインからの事前定義の定数（例えば、ＭｙＧｒａｎｄｐａｒｅｎｔ）を、他のドメインからの条件への引数として使用することができる（例えば、Ｐｈｏｔｏｓｆｒｏｍ（ＭｙＧｒａｎｄｐａｒｅｎｔ））。事前定義の条件および定数の組合せによって、エンドユーザが様々なアイテムドメインを関連付ける単純で直観的な形が提供される。もちろん、ユーザ定義の定数を、パーソナライズされたフォルダの条件に提供することもできる。単純な条件を、アイテムドメインのスキーマから推論することができる。例えば、条件ＥｍａｉｌＩｓＦｒｏｍ（）またはＳｕｂｊｅｃｔＣｏｎｔａｉｎｓ（）は、電子メールスキーマから推論することができる。しかし、スキーマ開発者は、確かに、有用な条件の豊富なセットと最小限のセットの両方を明示的に指定することができる。さらに、新しい条件を、アプリケーション３００に追加し（拡張性）、その後、エンドユーザが新しいプリファレンスを定義することによって使用できることにも留意されたい。新しいスキーマがインストールされる時に、フォルダをパーソナライズする新しい機能が可能になる。
【０３０２】
フォルダ３５１０は、本発明の態様によれば、アクティブまたは派生として分類することができる。アクティブフォルダは、フォルダで、何か興味深いこと（例えば、イベント−ファイル文書の追加、削除、または変更）が起きる場合に、ユーザの代わりにアクションを行う。例えば、写真を、デジタルカメラからＭｙＰｉｃｔｕｒｅｓという名前のフォルダにダウンロードすることができる。同時にまたはそれから短い時間のうちに、アクティブフォルダは、カレンダアプリケーションに相談して、写真を撮った時にユーザが行っていたことを判定し、その後、適当なタイトル（例えば釣り旅行）を有する新しいフォルダを作成し、その写真を新しいフォルダに移動することができる。電子メールのコンテキストでは、電子メールアプリケーションは、メッセージに出費レポートが含まれる場合を判定し、それがある値未満である場合に、そのレポートを承認済み出費レポートフォルダに移動することができる。アクティブフォルダのもう１つの例示的な使用では、音楽を、アクティブフォルダにダウンロードすることができ、このアクティブフォルダは、アーティストジャンル（例えば、ジャズ、クラシック、ラップ、ロックなど）を判定し、音楽を適当なフォルダに移動する。
【０３０３】
派生フォルダは、プリファレンスを使用して、特定のファイルをフォルダに含めるか除外するかを判断する。さらに、派生フォルダを、ファイルへのマッピングまたはポインタを提供する仮想フォルダとすることができることに留意されたい。仮想フォルダは、データを収容する実際のフォルダとして働くが、このフォルダは、実際の物理的な存在を有しない。派生フォルダの使用の１つの例に、ユーザが、最近２週間にそのユーザが少なくとも３回聞いたすべてのジャズ音楽を含むフォルダを定義する状況が含まれる。派生フォルダは、ある例外を有する、特定のタイプのすべてのファイルを含むように、プリファレンスによって定義することもできる。例えば、ジャズ音楽家マイルスデイビスのすべてのトラックを含むが、特定の曲トラック（例えば、ヒューマンネイチャおよびニュールンバ）を除外するように、フォルダを定義することができる。さらに、ユーザが、フォルダにファイルをドラッグアンドドロップでき、フォルダが、ドラッグされたファイルが定義されたタイプであるかどうかを確認するように、プリファレンスを定義することができることに留意されたい。ファイルが、許容されるタイプである場合には、そのフォルダに追加することができ、そうでない場合に、そのファイルを、拒絶する（例えば、フォルダにコピーしない）か、その代わりに、ユーザに、その特定のファイルについて例外が作成されなければならないことのプロンプトを出すことができる。
【０３０４】
さらに、あるフォルダが、アクティブフォルダと派生フォルダの両方の特性を示すことができることに留意されたい。したがって、一部のフォルダは、どのアイテムがフォルダに含まれるかを指定する、それに関連付けられたプリファレンスと、あるイベントがこれらのアイテムに対して発生する場合に行うべきアクションを指定するプリファレンスを有することができる。
【０３０５】
アプリケーションを、システム１００の実行エンジンを使用して処理することができる。前に開示したように、プリファレンスを、データとして保管し、データクエリの形で実行することができる。データストア１５０は、１つまたは複数のテーブルにデータを保管することができ、このテーブルを、プリファレンス情報を使用して照会することができる。従来、テーブルのデータベースに対するクエリの実行は、計算的に実行不能である。というのは、フォルダ内のデータが最新状態に保たれることを保証するために、比較的短い間隔でクエリを継続的に実行しなければならないからである。これは、プロセッサが、フォルダデータを更新するために継続的にクエリを実行しながら複数のプログラムを効率的に実行できないパーソナルコンピュータなどの軽いシステムで特に非実用的である。しかし、本発明は、データが追加され、削除され、または変更される場合など、イベントの発生時にクエリを実行することによって、この問題を克服する。したがって、プロセッサは、継続的にクエリを実行するという重荷を負わず、フォルダデータが最新に保たれる。
【０３０６】
アクティブフォルダに基づくワークフロー様のアクティビティ
パーソナライゼーション（例えば、ＥＣＡルール）は、ワークフローまたはタスクスケジュールと別個である。ワークフローまたはタスクスケジュールは、フォルダ内のアイテムを介して表現できる、作業のマルチステップの部分である。パーソナライゼーションは、エンドユーザが、エンドユーザに意味のあるイベント（例えば、電子メール到着）またはシステム／アプリケーション挙動（例えば、ユーザコンテキストに基づくデスクトップ割込みの制御）の処理を自動化するためにシステム／アプリケーションインターセプトポイントで適用されるプリファレンスをエンドユーザが指定することを可能にするという概念である。パーソナライゼーションは、そのロジックが所与のインターセプトポイント（例えば、イベント、フロー内の点）にローカライズされたプリファレンスをエンドユーザが表現することを可能にすることに関する。単一のプリファレンスのアクションに起因する複数のプリファレンスのカスケードされた評価は、偶発的であり、計画されたものではない。したがって、パーソナライゼーションは、小さい形のワークフローではなく、ワークフローとパーソナライゼーションは、完全に異なるものである。イベントを処理するためのプリファレンスの偶発的カスケードは、ワークフローでのタスク／ルールの計画されたチェーニングと異なる。さらに、パーソナライゼーションは、ワークフローまたはタスクスケジュールが伴うか否かに独立に、電子メール、電話呼び出し、デスクトップ割込み、および他の多数のタイプのエンドユーザイベントに適用することができる。パーソナライズされたワークフローは、パーソナライゼーションが、ワークフローに対する、独立だが相補的な概念であるという前提に基づく。
【０３０７】
パーソナライゼーションは、エンドユーザ判断が関係する時にいつでも、ワークフローまたはタスクスケジュールに適用することができる。タスクのパーソナライゼーション、ワークフロー開始のパーソナライゼーション、ワークフロータスクのパーソナライゼーション、およびワークフロースケジューリングのパーソナライゼーションに、ワークフローのパーソナライゼーションの様々な機会がある。タスクのパーソナライゼーションの例が、ユーザが、ある人の直接レポートによるある金額の注文の自動承認などのタスクの処理を自動化するための判断ロジックを指定する場合である。ワークフロー開始は、関心をもたれたイベント（例えば、電話呼び出し、電子メール到着）に基づくワークフローのオープン／開始の判断を扱う。計画されたパーソナライゼーションは、潜在的に、追跡されるスケジュールなどと相互作用する適当な能力によってラップすることによってワークフロータスクにすることができる。言い換えると、パーソナライゼーションは、ワークフロー内で計画されたタスクとして使用することができ、ここで、ユーザプリファレンスが、タスクの解決を完全に決定する。最後に、パーソナライゼーションは、ワークフロースケジューリングに用いることができる。ワークフローの次のステップに関する選択が存在する場合に、パーソナライゼーションを使用して、ユーザがそのような判断のプリファレンスを指定できるようにすることができる。
【０３０８】
上記のカテゴリのうちの多数を含むパーソナライズされたワークフローの実用的な例を、出費レポートの処理とすることができる。この例では、電子メールが、ｉｎｂｏｘに到着し、電子メールのタイプが、検出され（例えば、件名行、出費レポートとしてフラグを立てられるなど）、電子メールデータが、スキャンされ、インボイス額がある金額未満である場合に、レポートが、承認済みフォルダに移動される。その後、レポート承認済み状況を示す電子メールを、送信者に送り返すことができる。その後、ユーザによる月次再検討のためにジャーナルを作成することができ、承認された総額を記録することができる。
【０３０９】
ワークフローのパーソナライゼーションの上のカテゴリのすべてが、ワークフローの価値を高めるが、そのような利益の適用可能性は、ワークフローに制限されない。これらの利益は、通信処理、ルーティング、またはパーソナライゼーションを含むがこれに制限されない多数の他のドメインに適用することができ、そのようなドメインは、ワークフローに参加しない場合がある。
【０３１０】
クロニクルフォルダ
本発明の態様によるクロニクルは、システムの１人または複数のユーザに関係するヒストリ情報およびコンテキスト情報を表す。通知システムに、しばしば、前のアクションに基づいてあるアクションンを行うか否かの評価の一部として使用できるヒストリカルデータという概念が含まれる。例えば、ユーザが、「notify me when shares of MSFT hit a new high for the day（ＭＳＦＴの株がその日の新高値をつけた場合に通知せよ）」というプリファレンスをセットアップすることを望む場合がある。この場合に、システムは、１日中ＭＳＦＴ株の最高価格点を維持し、新高値に達した場合にこの情報を更新することができる。
【０３１１】
本発明の態様によれば、クロニクルは、データストアに保管され、ユーザインターフェース（例えば、オペレーティングシステムによって供給される）を介して、ユーザが自由にアクセス可能である。したがって、エンドユーザは、このヒストリカルデータに対する制御を有し；他のファイルをバックアップする途中でバックアップすることができ、家庭またはオフィスの他のコンピュータと同期化することができ、普通のファイル共有機構を介して共有することができ、このコンテキスト情報に正確に誰がアクセスできるかを制御するためにアクセス許可および他のセキュリティセッティングをセットすることができる。例えば、ユーザは、自分のワークグループの誰もがこのＭＳＦＴ株価に関するヒストリカル情報を見ることを許可することができるが、そのユーザが自分の机にいるか会議中であるなどのコンテキスト情報を制限することを望むことができる。
【０３１２】
さらに、本発明のシステムは、「監査」クロニクルを作成する能力を含む、「組み込み」クロニクル作成／維持ロジックとして、ある共通の挙動を公開することができ、ユーザの代わりに行われるすべてのアクションが、クロニクルに保管され、このクロニクルは、システムが見た特定の種類のイベントまたはアクションの個数のカウントを保存する「カウント」クロニクルと；ある時間期間にわたるヒストリカルな最高値および最低値を追跡できる「高低ウォーターマーク」クロニクルである。
【０３１３】
さらに、本発明は、これらのクロニクルを、情報エージェントアプリケーションについて何も知らないアプリケーションによって更新することを可能にすることができる。多数の通知プラットフォームが、ユーザルール（本明細書ではプリファレンスとも呼ぶ）の普通の処理中にコンテキスト情報を更新することを可能にするが、本発明は、ルール処理またはプリファレンス処理の一部として、データストアに保管された図式化されたデータを使用するので、このシステムは、すべてのアプリケーションによって作成されたコンテキスト情報を使用することができる。例えば、ユーザは、リアルタイム株式市況をユーザコンピュータにストリーミングする、ＮＡＳＤＡＱによって記述されたアプリケーションをダウンロードし、実行することができる。ＮＡＳＤＡＱアプリケーションは、シンボルごとにファイルを作成することができ、ユーザは、これらのファイルの中の関連情報に関心を持ち、保存する。本発明の情報エージェントアプリケーションは、一態様によれば、このタイプの外部化されたコンテキスト情報を使用するように作られるので、情報エージェントシステムは、ルール処理またはプリファレンス処理中に、クロニクルとしてこれらのファイルを利用することができる。
【０３１４】
クロニクルは、アクティブフォルタと共に使用することもできる。パーソナライズされたフォルダシステムに、特定のフォルダを監視する能力が含まれるので、そのようなフォルダで作成され、変更され、またはそこに移動されるフォルダアイテムを、特定のクロニクルまたはクロニクルのセットに対するコンテキスト更新として扱うことができる。この形で、ユーザが、彼らの代わりにプログラマが記述したコードを実行することなく、クロニクルを維持することが可能になる。そうではなく、エンドユーザは、単に、オペレーティングシステムの既存のファイル操作機構を使用して、彼らのコンテキスト情報を最新状態に保つことができる。
【０３１５】
したがって、本発明は、ソフトウェア、ファームウェア、ハードウェア、またはこれらの組合せを作る標準的なプログラミング技法および／またはエンジニアリング技法を使用する方法、装置、または製造品として実施することができる。本明細書で使用される用語「製造品」（またはその代わりに「コンピュータプログラム製品」）は、すべてのコンピュータ可読デバイス、担体、またはメディアからアクセス可能なコンピュータプログラムを含むことが意図されている。もちろん、当業者は、本発明の範囲から逸脱せずに、この構成に対して多数の変更を行えることを理解するであろう。
【０３１６】
上で説明した例示的システムに鑑みて、本発明に従って実施できる方法論は、図３６から４１の流れ図に関してよりよく諒解される。説明を単純にするために、この方法論を、一連のブロックとして図示し、説明するが、本発明によれば、一部のブロックを、図示し、本明細書で説明するものと異なる順序でおよび／または他のブロックと同時に実行できるので、本発明が、ブロックの順序によって制限されないことを理解し、諒解されたい。さらに、示されたブロック動作のいずれかが、本発明による方法論の実施に必要ではない可能性がある。
【０３１７】
図３６を見ると、本発明の態様による、プリファレンスを使用する方法論３６００が示されている。３６１０で、プリファレンスが、エンドユーザによって、例えば開発者スキーマ（例えば、ＸＭＬスキーマ）に基づいて指定され、データストアのテーブルに保管される。次に、３６２０で、１つまたは複数のイベントを、受け取るか検出することができる。次に、３６３０で、プリファレンスを実行するか評価し、クエリ言語（例えば、ＳＱＬ）を使用して、データテーブルを照会することができる。３６４０で、結果テーブルを作るか、有効な条件的に有効なプリファレンスを取り込む。最後に、３６５０で、結果テーブルの結果に基づいてめいめいのアクションを実行することができる。
【０３１８】
図３７を見ると、本発明の態様による、アプリケーションをインストールする方法論３７００が示されている。３７１０で、インストールされるアプリケーションを実行するシステムまたはプラットフォームに関連するデータストア（例えば、情報エージェントシステムデータストア１５０）内で基礎テーブルをセットアップする。その後、３７２０で、インストールされるアプリケーションについて厳密に新しいテーブルおよびデータベースを作成するのではなく、アプリケーションデータを用いて基礎テーブルを更新する。３７３０で、例えば、アプリケーションプロシージャ用に指定されたベースドテーブル内に、データとしてアプリケーションプロシージャを保管する。実行するために、テキストのアプリケーションプロシージャストリングが、データベースから除去され、一態様に従ってリアルタイムで実行される。
【０３１９】
図３８に、本発明の態様によるアプリケーションを拡張する方法論３８００を示す。３８１０で、開発者からＥＤＦを受け取る。ＥＤＦに、あるアプリケーションのプリファレンスクラスが他のアプリケーションで定義された条件、アクション、およびイベントを参照できるようにすることに関連する情報が含まれる。その後、３８２０で、機能バインディングを、インスタンスレジストリなどの中央位置で登録する。３８３０で、拡張コンポーネントが、バインディング情報を取り出すか受け取る。その後、３８４０で、受入ロジックを、バインディングに適用することができる。ＥＤＦがインストールされる場合に、バインディングが使用可能にされるが、これらは、本発明の一態様によれば、アプリケーションに自動的には適用されない。そうではなく、受入ロジックを適用して、ＥＤＦを受け入れるかどうかを判定する。受入ロジックは、受け入れるかどうかを判定するために、なかんずく、バインディングの真正性、許可、および／または信頼されるソースによる証明を問い合わせる。３８５０で、アプリケーションがバインディングを受け入れるかどうかに関する判定が、アプリケーションによって行われる。「ｎｏ」の場合には、この処理は、バインディングなしで単純に終了する。「ｙｅｓ」の場合に、３８６０で、候補機能バインディングを、第１アプリケーションから第２アプリケーションにバインドする。
【０３２０】
図３９は、本発明の態様によるアプリケーションのアンインストールの方法論３９００を示す流れ図である。３９１０で、アンインストールされるアプリケーションが、そのすべての登録を中央ストア位置から除去する。中央ストレージ位置は、定義レジストリおよびバインディングレジストリを有するインスタンスレジストリとすることができる。３９２０で、アプリケーションコンポーネントを除去することができる。依存アプリケーションに、アンインストールされたアプリケーションについて通知することができる（例えば、拡張コンポーネントによって）。さらに、上で注記したように、方法論３９００のブロックを、任意の順序にすることができる。したがって、本発明のもう１つの態様に、アンインストールプロセスまたは除去プロセスの前に依存アプリケーションに通知することが含まれる。
【０３２１】
図４０は、本発明の態様によるアプリケーションにまたがるプログラム的定数の拡張の方法を示す流れ図である。４０１０で、定数を受け取る。４０２０で、アプリケーションドメインにまたがる検索によって、定数の値を決定する。例えば、定数ＭｙＭａｎａｇｅｒが受け取られる場合に、この方法論は、電子メールアプリケーションを介して検索し、ＭｙＭａｎａｇｅｒの値を決定することができる。
【０３２２】
図４１に、本発明の態様によるコンピュータ機能性をパーソナライズする方法論４１００を示す。４１１０で、エンドユーザが、提供されたスキーマに従って、プリファレンスを記述する。プリファレンスは、任意の形とすることができるが、本発明の一態様によれば、プリファレンスに、Ｂｏｏｌｅａｎ演算子によって区切られた複数のＩＦ−ＴＨＥＮステートメントが含まれる。スキーマは、エンドユーザプログラミングを制約し、これによって単純にするために、アプリケーション開発者が提供することができる。４１２０で、イベントの発生時にプリファレンスを実行する。イベントは、フォルダデータの変化または株価の変化を含むがこれに制限されない、発生するすべてのこととすることができる。プリファレンスの実行または評価は、データストアコンポーネント内のデータを照会することによる使用によって行うことができる。４１２０で、条件的に有効なプリファレンスに基づいてアクションを行う。
【０３２３】
本発明の様々な態様のコンテキストを提供するために、図４２および４３ならびに次の議論は、本発明の様々な態様を実施できる適切なコンピューティング環境の短い全般的な説明を提供することを意図されたものである。本発明を、上で、１つのコンピュータおよび／または複数のコンピュータで動作するコンピュータプログラムのコンピュータ実行可能命令の全般的な文脈で説明したが、本発明を、他のプログラムモジュールと組み合わせて実施することもできることを、当業者は理解するであろう。一般に、プログラムモジュールに、特定のタスクを実行し、および／または特定の抽象データ型を実施するルーチン、プログラム、コンポーネント、データ構造などが含まれる。さらに、本発明の方法を、単一プロセッサまたはマルチプロセッサのコンピュータシステム、ミニコンピューティングデバイス、メインフレームコンピュータ、ならびにパーソナルコンピュータ、ハンドヘルドコンピューティングデバイス、マイクロプロセッサベースまたはプログラマブルなコンシューマ電子機器、および類似物を含む、他のコンピュータシステム構成と共に実践できることを、当業者は諒解するであろう。本発明の図示された態様は、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される分散コンピューティング環境で実践することもできる。しかし、本発明の、すべてではないにしてもいくつかの態様を、独立型コンピュータで実践することができる。分散コンピューティング環境では、プログラムモジュールを、ローカルとリモートの両方のメモリストレージデバイスに配置することができる。
【０３２４】
図４２を参照すると、本発明の様々な態様を実施する例示的環境４２１０に、コンピュータ４２１２が含まれる。コンピュータ４２１２に、処理ユニット４２１４、システムメモリ４２１６、およびシステムバス４２１８が含まれる。システムバス４２１８は、システムメモリ４２１６を含むがこれに制限されないシステムコンポーネントを処理ユニット４２１４に結合する。処理ユニット４２１４は、様々な使用可能なプロセッサのいずれかとすることができる。デュアルマイクロプロセッサおよび他のマルチプロセッサアーキテクチャも、処理ユニット４２１４として使用することができる。
【０３２５】
システムバス４２１８に、メモリバスまたはメモリコントローラ、周辺バスまたは外部バス、および／または、１１ビットバス、Ｉｎｄｕｓｔｒｉａｌ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）、マイクロチャネルアーキテクチャ（ＭＳＡ）、Ｅｘｔｅｎｄｅｄ  ＩＳＡ（ＥＩＳＡ）、Ｉｎｔｅｌｌｉｇｅｎｔ  Ｄｒｉｖｅ  Ｅｌｅｃｔｒｏｎｉｃｓ（ＩＤＥ）、ＶＥＳＡ  Ｌｏｃａｌ  Ｂｕｓ（ＶＬＢ）、Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）、Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ（ＵＳＢ）、Ａｄｖａｎｃｅｄ  Ｇｒａｐｈｉｃｓ  Ｐｏｒｔ（ＡＧＰ）、Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ  Ｍｅｍｏｒｙ  Ｃａｒｄ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ａｓｓｏｃｉａｔｉｏｎバス（ＰＣＭＣＩＡ）、およびＳｍａｌｌ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍｓ  Ｉｎｔｅｒｆａｃｅ（ＳＣＳＩ）を含むがこれに制限されない様々なバスアーキテクチャを使用するローカルバスを含む複数のタイプのバス構造のいずれかとすることができる。
【０３２６】
システムメモリ４２１６に、揮発性メモリ４２２０および不揮発性メモリ４２２２が含まれる。スタートアップ中などにコンピュータ４２１２内の要素の間で情報を転送する基本ルーチンを含む基本入出力システム（ＢＩＯＳ）が、不揮発性メモリ４２２２に保管される。制限ではなく例として、不揮発性メモリ４２２２に、読取専用メモリ（ＲＯＭ）、プログラマブルＲＯＭ（ＰＲＯＭ）、電気的プログラム可能ＲＯＭ（ＥＰＲＯＭ）、電気的消去可能ＲＯＭ（ＥＥＰＲＯＭ）、またはフラッシュメモリを含めることができる。揮発性メモリ４２２０に、外部キャッシュメモリとして働くランダムアクセスメモリ（ＲＡＭ）が含まれる。制限ではなく例として、ＲＡＭは、ｓｙｎｃｈｒｏｎｏｕｓ  ＲＡＭ（ＳＲＡＭ）、ｄｙｎａｍｉｃ  ＲＡＭ（ＤＲＡＭ）、ｓｙｎｃｈｒｏｎｏｕｓ  ＤＲＡＭ（ＳＤＲＡＭ）、ｄｏｕｂｌｅ  ｄａｔａ  ｒａｔｅ  ＳＤＲＡＭ（ＤＤＲ  ＳＤＲＡＭ）、ｅｎｈａｎｃｅｄ  ＳＤＲＡＭ（ＥＳＤＲＡＭ）、Ｓｙｎｃｈｌｉｎｋ  ＤＲＡＭ（ＳＬＤＲＡＭ）、およびｄｉｒｅｃｔ  Ｒａｍｂｕｓ  ＲＡＭ（ＤＲＲＡＭ）などの多数の形で入手可能である。
【０３２７】
コンピュータ４２１２に、取外し可能／取外し不能、揮発性／不揮発性のコンピュータストレージメディアも含まれる。図４２に、例えば、ディスクストレージ４２２４を示す。ディスクストレージ４２２４に、磁気ディスクドライブ、フロッピー（登録商標）ディスクドライブ、テープドライブ、Ｊａｚドライブ、Ｚｉｐドライブ、ＬＳ−１００ドライブ、フラッシュメモリカード、またはメモリスティックなどのデバイスが含まれるが、これに制限はされない。さらに、ディスクストレージ４２２４に、他のストレージメディアと別々にまたはこれと組み合わせて、コンパクトディスクＲＯＭデバイス（ＣＤ−ＲＯＭ）、ＣＤ  ｒｅｃｏｒｄａｂｌｅドライブ（ＣＤ−Ｒドライブ）、ＣＤ  ｒｅｗｒｉｔａｂｌｅドライブ（ＣＤ−ＲＷドライブ）またはデジタル多用途ディスクＲＯＭドライブ（ＤＶＤ−ＲＯＭ）などの光学ディスクドライブを含むがこれに制限されないストレージメディアを含めることができる。システムバス４２１８へのディスクストレージ４２２４の接続を容易にするために、インターフェース４２２６などの取外し可能インターフェースまたは取外し不能インターフェースが、通常は使用される。
【０３２８】
図４２に、ユーザと、適切なオペレーティング環境４２１０で説明される基本的なコンピュータリソースとの間の仲介として働くソフトウェアが記載されていることを諒解されたい。そのようなソフトウェアに、オペレーティングシステム４２２８が含まれる。オペレーティングシステム４２２８は、ディスクストレージ４２２４に保管することができるが、コンピュータシステム４２１２のリソースを制御し、割り当てるように働く。システムアプリケーション４２３０が、システムメモリ４２１６またはディスクストレージ４２２４のいずれかに保管されたプログラムモジュール４２３２およびプログラムデータ４２３４を介して、オペレーティングシステム４２２８によるリソースの管理を利用する。本発明を、様々なオペレーティングシステムまたはオペレーティングシステムの組合せを用いて実施できることを諒解されたい。
【０３２９】
ユーザは、入力デバイス４２３６を介してコンピュータ４２１２にコマンドまたは情報を入力する。入力デバイス４２３６に、マウスなどのポインティングデバイス、トラックボール、スタイラス、タッチパッド、キーボード、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナ、ＴＶチューナカード、デジタルカメラ、デジタルビデオカメラ、ウェブカメラ、および類似物が含まれるが、これに制限はされない。これらおよび他の入力デバイスは、インターフェースポート４２３８を介し、システムバス４２１８を介して処理ユニット４２１４に接続される。インターフェースポート４２３８に、例えば、シリアルポート、パラレルポート、ゲームポート、およびｕｎｉｖｅｒｓａｌ  ｓｅｒｉａｌ  ｂｕｓ（ＵＳＢ）が含まれる。出力デバイス４２４０は、入力デバイス４２３６と同一のタイプのポートの一部を使用する。したがって、例えば、ＵＳＢポートを使用して、コンピュータ４２１２に入力を供給し、コンピュータ４２１２から出力デバイス４２４０に情報を出力することができる。出力アダプタ４２４２は、出力デバイス４２４０の中に、モニタ、スピーカ、およびプリンタなど、特殊なアダプタを必要とするいくつかの出力デバイス４２４０があることを示すために提供される。出力アダプタ４２４２に、制限ではなく例として、出力デバイス４２４０とシステムバス４２１８の間の接続の手段を提供する、ビデオカードおよびサウンドカードが含まれる。リモートコンピュータ４２４４など、他の出力デバイスおよび／またはデバイスのシステムが、入力機能および出力機能の両方を提供することに留意されたい。
【０３３０】
コンピュータ４２１２は、リモートコンピュータ４２４４など、１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク化された環境で動作することができる。リモートコンピュータ４２４４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ワークステーション、マイクロプロセッサベースのアプライアンス、ピアデバイス、または他の一般的なネットワークノードおよび類似物とすることができ、通常は、コンピュータ４２１２に関して説明した要素の多数またはすべてを含む。図を簡単にするために、メモリストレージデバイス４２４６だけを、リモートコンピュータ４２４４と共に図示した。リモートコンピュータ４２４４は、ネットワークインターフェース４２４８を介して論理的にコンピュータ４２１２に接続され、次に、通信接続４２５０を介して物理的に接続される。ネットワークインターフェース４２４８は、ローカルエリアネットワーク（ＬＡＮ）および広域ネットワーク（ＷＡＮ）などの通信ネットワークを含む。ＬＡＮ技術に、Ｆｉｂｅｒ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｄａｔａ  Ｉｎｔｅｒｆａｃｅ（ＦＤＤＩ）、Ｃｏｐｐｅｒ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｄａｔａ  Ｉｎｔｅｒｆａｃｅ（ＣＤＤＩ）、Ｅｔｈｅｒｎｅｔ（登録商標）／ＩＥＥＥ  １１０２．３、Ｔｏｋｅｎ  Ｒｉｎｇ／ＩＥＥＥ  １１０２．５および類似物が含まれる。ＷＡＮ技術に、ポイントツーポイントリンク、サービス総合デジタル網（ＩＳＤＮ）およびその変形などの回路交換網、パケット交換網、およびデジタル加入者回線（ＤＳＬ）が含まれるが、これに制限はされない。
【０３３１】
通信接続４２５０は、ネットワークインターフェース４２４８をバス４２１８に接続するのに使用されるハードウェア／ソフトウェアを指す。通信接続４２５０は、図を明瞭にするためにコンピュータ４２１２内に示されているが、コンピュータ４２１２の外部とすることもできる。ネットワークインターフェース４２４８への接続に必要なハードウェア／ソフトウェアに、例示のみとして、通常の電話等級モデム、ケーブルモデム、およびＤＳＬモデムを含むモデム、ＩＤＳＮアダプタ、およびイーサネット（登録商標）カードなどの内蔵技術および外付け技術が含まれる。
【０３３２】
図４３は、本発明が相互作用できるサンプルコンピューティング環境４３００の概略ブロック図である。システム４３００に、１つまたは複数のクライアント４３１０が含まれる。クライアント４３１０は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）とすることができる。システム４３００に、１つまたは複数のサーバ４３３０も含まれる。サーバ４３３０も、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）とすることができる。サーバ４３３０は、例えば本発明を使用することによって変換を実行するスレッドを収容することができる。クライアント４３１０とサーバ４３３０の間の１つの可能な通信が、複数のコンピュータプロセスの間で伝送されるように適合されたデータパケットの形である。システム４３００に、クライアント４３１０とサーバ４３３０の間の通信を容易にするのに使用できる通信フレームワーク４３５０が含まれる。クライアント４３１０は、クライアント４３１０にローカルに情報を保管するのに使用できる１つまたは複数のクライアントデータストア４３６０に動作可能に接続される。同様に、サーバ４３３０は、サーバ４３３０にローカルに情報を保管するのに使用できる１つまたは複数のサーバデータストア４３４０に動作可能に接続される。
【０３３３】
上で説明したものに、本発明の例が含まれる。もちろん、本発明の説明においてコンポーネントまたは方法論のすべての考えられる組合せを記述することは不可能であるが、当業者は、本発明の多数のさらなる組合せおよび置換が可能であることを諒解するであろう。したがって、本発明は、本発明の趣旨および範囲に含まれる、すべてのそのような代替形態、修正形態、および変形形態を含むことが意図されている。さらに、詳細な説明または請求項のいずれかで用語「ｉｎｃｌｕｄｅｓ」が使用される範囲まで、そのような用語は、前後を接続する単語が請求項で使用される場合に用語「ｃｏｍｐｒｉｓｉｎｇ」が解釈されるのに類似する形で包括的であることが意図されている。
【０３３４】
【表３３−１】
2007518151.tif 000039
【０３３５】
【表３３−２】
2007518151.tif 000040
【０３３６】
【表３３−３】
2007518151.tif 000041
【図面の簡単な説明】
【０３３７】
【図１】本発明の態様による情報エージェントシステムを示すブロック図である。
【図２】本発明の態様による通知コンポーネントを示すブロック図である。
【図３】本発明の態様による情報エージェントアプリケーションを示すブロック図である。
【図４】本発明の態様による例示的論理スキーマを示すブロック図である。
【図５】本発明の態様による定数アクセッサを評価するシステムを示すブロック図である。
【図６】本発明の態様によるプリファレンス評価システムを示すブロック図である。
【図７】本発明の態様による優先順位システムを示すブロック図である。
【図８】本発明の態様によるクラシファイヤを示すブロック図である。
【図９】本発明の態様によるメッセージ分類を示す概略ブロック図である。
【図１０】本発明の態様によるスケーラクラシファイヤ出力を示す概略ブロック図である。
【図１１】本発明の態様によるクラスおよびスケーラ出力に従って分類されるテキストを示す概略ブロック図である。
【図１２】本発明の態様による線形優先順位モデルを示す図である。
【図１３】本発明の態様による非線形優先順位モデルを示す図である。
【図１４】本発明の態様によるユーザアクティビティを判定するモデルを示す図である。
【図１５】本発明の態様による現在のユーザアクティビティを判定する推論ベースモデルを示す図である。
【図１６】本発明の態様による警告コストを判定する推論ベースモデルを示す図である。
【図１７】本発明の態様による警告コストを判定するより詳細な推論ベースモデルを示す図である。
【図１８】本発明の態様による忠実度ロスに関する警告コストを判定するより詳細な推論ベースモデルを示す図である。
【図１９】本発明の態様による優先順位の生成および決定の方法論を示す流れ図である。
【図２０】本発明の態様によるテキスト生成プログラムおよびクラシファイヤを示す図である。
【図２１】本発明の態様による実行エンジンとコンテキストアナライザの間のシステマチックな協力を示す概略ブロック図である。
【図２２】本発明の態様によるコンテキストアナライザを示すブロック図である。
【図２３】本発明の態様によるソースおよびシンクを示すブロック図である。
【図２４】経時的にマッピングされた通知の有用性を示すグラフである。
【図２５】本発明の態様による例示的インターフェースを示す図である。
【図２６】本発明の態様による直接測定によるユーザコンテキストの判定の方法論を示す図である。
【図２７】本発明の態様によるコンテキストを判定するルールの例示的な階層順序付きセットを示すブロック図である。
【図２８】本発明の態様による、ユーザコンテキストを判定するために推論エンジンによって実行される推論分析を示すシステムを示す概略ブロック図である。
【図２９】本発明の態様による単一時間期間の注意のユーザの注意のフォーカスを推論する例示的ベイジアンネットワークを示す図である。
【図３０】本発明の態様による異なる時間の期間でのコンテキスト変数の間でのユーザの注意フォーカスのベイジアンモデルを示す図である。
【図３１】本発明の態様に従って、ユーザのコンテキストがどのように判定されるかを示す流れ図である。
【図３２】本発明の態様による通知伝達プロセスを示す流れ図である。
【図３３】本発明の態様によるアクション／条件進化チェーンを示す図である。
【図３４】本発明の態様によるアプリケーション相互作用のシステムを示すブロック図である。
【図３５】本発明の態様によるパーソナライズされたシステムを示すブロック図である。
【図３６】本発明の態様によるプリファレンスを使用する方法論を示す流れ図である。
【図３７】本発明の態様によるアプリケーションをインストールする方法論を示す流れ図である。
【図３８】本発明の態様によるアプリケーションを拡張する方法論を示す流れ図である。
【図３９】本発明の態様によるアプリケーションのアンインストールを示す流れ図である。
【図４０】本発明の態様によるアプリケーションにまたがるプログラム的定数の拡張の方法を示す流れ図である。
【図４１】本発明の態様によるコンピュータ機能性をパーソナライズする方法論を示す流れ図である。
【図４２】本発明の態様による適切なオペレーティング環境を示す概略ブロック図である。
【図４３】本発明が相互作用できるサンプルコンピューティング環境を示す概略ブロック図である。
【図１】
2007518151.tif 000042
【図２】
2007518151.tif 000043
【図３】
2007518151.tif 000044
【図４】
2007518151.tif 000045
【図５】
2007518151.tif 000046
【図６】
2007518151.tif 000047
【図７】
2007518151.tif 000048
【図８】
2007518151.tif 000049
【図９】
2007518151.tif 000050
【図１０】
2007518151.tif 000051
【図１１】
2007518151.tif 000052
【図１２】
2007518151.tif 000053
【図１３】
2007518151.tif 000054
【図１４】
2007518151.tif 000055
【図１５】
2007518151.tif 000056
【図１６】
2007518151.tif 000057
【図１７】
2007518151.tif 000058
【図１８】
2007518151.tif 000059
【図１９】
2007518151.tif 000060
【図２０】
2007518151.tif 000061
【図２１】
2007518151.tif 000062
【図２２】
2007518151.tif 000063
【図２３】
2007518151.tif 000064
【図２４】
2007518151.tif 000065
【図２５】
2007518151.tif 000066
【図２６】
2007518151.tif 000067
【図２７】
2007518151.tif 000068
【図２８】
2007518151.tif 000069
【図２９】
2007518151.tif 000070
【図３０】
2007518151.tif 000071
【図３１】
2007518151.tif 000072
【図３２】
2007518151.tif 000073
【図３３】
2007518151.tif 000074
【図３４】
2007518151.tif 000075
【図３５】
2007518151.tif 000076
【図３６】
2007518151.tif 000077
【図３７】
2007518151.tif 000078
【図３８】
2007518151.tif 000079
【図３９】
2007518151.tif 000080
【図４０】
2007518151.tif 000081
【図４１】
2007518151.tif 000082
【図４２】
2007518151.tif 000083
【図４３】
2007518151.tif 000084