(57)【要約】【課題】  通知プラットフォームのフレームワークで使用することができる様々なアプリケーションに従って通知の自動化された配信を円滑にするシステムおよび方法を提供する。【解決手段】  アプリケーションを、ユーザが通知プラットフォームと容易に／便利に対話することができるモデルで記述する。そのようなモデルには、所望のサービスのユーザ定義を受け取り、プラットフォームに従ってユーザにサービスバンドルを配信するためにそのようなサービスを連鎖させるサードパーティとして作用する仲介モデルが含まれる。例えば、通知サービスの量価格設定割引などの様々なファクタに従う動的価格設定モデルを提供できる。また、サービスへの加入／加入取消しをユーザが便利に行なえる加入アクセスモデルを提供し、他方、代替のサービスのデリバリに関するオプションをユーザに与えるのにプッシュ／プルモデル等を使用できる。【選択図】  図１
2004259261.tif 000002
【特許請求の範囲】
【請求項１】
イベント処理および加入処理を円滑にするように処理に先立って前記イベントおよび前記加入をデータとしてモデル化する受け取られたイベント情報および加入情報を処理するデータベースエンジンと、
前記処理されたイベント情報および加入情報に従って加入者に通知を配信する通知プラットフォームと、
前記通知を生成する少なくとも１つのソースに対して加入および加入取消しを行うことを容易にする少なくとも１つのアプリケーションモデルと
を含むことを特徴とする通知システム。
【請求項２】
前記通知プラットフォームは、通知を生成する１つまたは複数のイベントソースから、前記イベントソースからの情報を受信する少なくとも１つの通知シンクに情報を配布する少なくとも１つのサーバを含むことを特徴とする請求項１に記載の通知システム。
【請求項３】
前記アプリケーションモデルは、仲介モデル、動的価格設定モデル、加入アクセスモデル、プッシュモデル、プルモデル、コンテキストモデル、デバイスモデル、および料金請求モデルの少なくとも１つを含むことを特徴とする請求項１に記載の通知システム。
【請求項４】
前記通知プラットフォームは、複数のイベントソースからのデータを処理し、前記少なくとも１つの通知シンクに通知を配布する結合操作を行う、少なくとも１つのＳＱＬサーバを含むことを特徴とする請求項２に記載の通知システム。
【請求項５】
前記仲介モデルは、ユーザから通知指定を受け取り、前記指定を満たす通知サービスを決定することを特徴とする請求項３に記載の通知システム。
【請求項６】
前記仲介モデルは、通知仲介構成要素および加入仲介構成要素の少なくと１つを含むことを特徴とする請求項５に記載の通知システム。
【請求項７】
前記仲介モデルは、サービスバンドル、および通知をユーザに配信するのに通知プラットフォームによって使用される通知バンドルの少なくとも１つを生成することを特徴とする請求項６に記載の通知システム。
【請求項８】
前記仲介モデルは、クエリおよび自発的（ｕｎｓｏｌｉｃｉｄｅｄ）要求の少なくとも１つを介して前記通知指定を受け取ることを特徴とする請求項５に記載の通知システム。
【請求項９】
前記動的価格設定モデルは、グループ構成要素、量構成要素、時間ベースの構成要素、場所ベースの構成要素、コンテキストベースの構成要素、使用ベースの構成要素、および関連ベースの構成要素の少なくとも１つを含み、通知アーキテクチャ内で価格調整を円滑にすることを特徴とする請求項３に記載の通知システム。
【請求項１０】
前記動的価格設定モデルは、ユーザプロファイル、前記ユーザプロファイルに関連する属性、およびパフォーマンス構成要素の少なくとも１つに関連して前記価格調整を決めることを特徴とする請求項９に記載の通知システム。
【請求項１１】
前記加入アクセスモデルは、加入スイッチ、短期コントロール、断続的コントロール、試用加入コントロール、および転換コントロールの少なくとも１つを含み、加入調整を円滑にすることを特徴とする請求項３に記載の通知システム。
【請求項１２】
前記プルモデルは、ユーザの現在の加入に従わない通知を受信する前記ユーザの要求に関連することを特徴とする請求項３に記載の通知システム。
【請求項１３】
前記プッシュモデルは、ユーザに提供された誘因によって主導されることを特徴とする請求項３に記載の通知システム。
【請求項１４】
前記プッシュモデルは、情報が前記ユーザにプッシュされることを不可にするコントロールをさらに備えることを特徴とする請求項１３に記載の通知システム。
【請求項１５】
前記コンテキストモデルを、少なくとも１つの通知サービスに関連する加入を調整するのに使用することを特徴とする請求項１に記載の通知システム。
【請求項１６】
前記コンテキストモデルは、コンテキストソース、コンテキスト特徴付け構成要素、コンテキスト消費側、コンテキストを獲得する構成要素、コンテキスト伝播構成要素、およびコンテキストを開示する構成要素の少なくとも１つを含むことを特徴とする請求項１５に記載の通知システム。
【請求項１７】
前記デバイスモデルは、受信構成要素、機能構成要素、フィルタ構成要素、配信条件構成要素、およびデバイス条件構成要素の少なくとも１つを含み、通知プラットフォームおよび少なくとも１つの加入とのやりとりを円滑にすることを特徴とする請求項３に記載の通知システム。
【請求項１８】
前記料金請求モデルは、加入プラットフォームサービスおよび処理エンジンの少なくとも１つを含み、通知プラットフォームに従って自動化された料金請求を円滑にすることを特徴とする請求項３に記載の通知システム。
【請求項１９】
前記処理エンジンは、バランス影響エンジン、資格付与エンジン、および提供エンジンの少なくとも１つを含み、少なくとも１つの通知サービスに関連するアカウントを管理することを特徴とする請求項１８に記載の通知システム。
【請求項２０】
前記料金請求モデルは、加入ストア、リソースバランスストア、料金請求影響ストア、製品カタログ、および格付け済みイベントストアの少なくとも１つをさらに備えることを特徴とする請求項１８に記載の通知システム。
【請求項２１】
請求項１に記載の通知システムを実施するためのコンピュータ実行可能構成要素を記憶していることを特徴とするコンピュータ可読媒体。
【請求項２２】
イベント情報および加入情報を獲得する手段と、
前記イベント情報および前記加入情報を処理する手段と、
前記イベントデータおよび前記加入データから通知データを生成する手段と、
少なくとも１つのアプリケーション構成要素に従って加入者に通知を配信する手段と
を備えることを特徴とする通知システム。
【請求項２３】
前記アプリケーション構成要素は、ブローカ構成要素、価格構成要素、加入制御構成要素、プッシュ構成要素、プル構成要素、コンテキスト構成要素、デバイス構成構成要素、および料金請求構成要素の少なくとも１つをさらに備えることを特徴とする請求項２２に記載の通知システム。
【請求項２４】
少なくとも１つのアプリケーションモデルを定義すること、
前記アプリケーションモデルと通知プラットフォームのインターフェースをとること、および
前記通知プラットフォームに関連する通知サービスに対して加入すること、および加入取消しを行うことの少なくとも１つのために前記アプリケーションモデルを使用すること
を有することを特徴とする通知方法。
【請求項２５】
前記通知プラットフォームのユーザプロファイル調整パフォーマンスを定義することをさらに有することを特徴とする請求項２４に記載の通知方法。
【請求項２６】
デバイス機能およびシステム機能の少なくとも１つに対して前記ユーザプロファイルを調整することをさらに有することを特徴とする請求項２５に記載の通知方法。
【請求項２７】
クエリおよび自発的な要求の少なくともどちらかを介して通知指定を受け取り、前記指定に基づいて前記通知サービスをパッケージ化することをさらに有することを特徴とする請求項２４に記載の通知方法。
【請求項２８】
前記通知サービスは、グループ構成要素、量構成要素、時間ベースの構成要素、場所ベースの構成要素、コンテキストベースの構成要素、使用ベースの構成要素、および関連ベースの構成要素の少なくとも１つに基づいて割引を提供することを特徴とする請求項２４に記載の通知方法。
【請求項２９】
加入スイッチ、短期コントロール、断続的コントロール、試用加入コントロール、および転換コントロールの少なくとも１つに基づいて加入を調整することをさらに有することを特徴とする請求項２４に記載の通知方法。
【請求項３０】
誘因に基づいてユーザに情報をプッシュすること、およびユーザ制御に基づいてユーザに情報をプッシュすることの少なくとも１つをさらに有することを特徴とする請求項２４に記載の通知方法。
【請求項３１】
コンテキストを使用して加入を調整することをさらに有することを特徴とする請求項２４に記載の通知方法。
【請求項３２】
前記通知プラットフォームを自動化された料金請求システムに関連付けるステップをさらに含むことを特徴とする請求項２４に記載の通知方法。
【請求項３３】
通知システムのための信号であって、
通知イベントおよび加入情報の少なくとも１つを伝送する第１のデータパケットと、
前記通知イベントおよび加入に従って通知を加入者に配信する第２のデータパケットとを備え、前記通知、前記通知イベント、および前記加入の少なくとも１つが、前記加入のステータスを自動的に調整することができるアプリケーションモデルに関連付けられることを特徴とする信号。
【請求項３４】
前記アプリケーションモデルは、ブローカモデル、価格モデル、アクセスモデル、プッシュ／プルモデル、コンテキストモデル、デバイスモデル、および料金請求モデルの少なくとも１つを含むことを特徴とする請求項３３に記載の信号。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、コンピュータシステムに関し、より詳細には、通知プラットフォームに加入し、通知プラットフォームとインターフェースをとることを容易にする様々なアプリケーションに従って通知を配信するためのシステムおよび方法に関する。
【背景技術】
【０００２】
本出願は、参照により全体が本明細書に組み込まれている「通知を提供するためのシステムおよび方法」という名称の２００２年７月２６日に出願した米国特許出願公開第１０／１８０，３６０号の一部継続出願である。
【０００３】
人々が情報に通じた判断を行うことができるようにすることが、今日のペースの速い環境においてますます重要になっている。個人に妥当で適時な情報を提供することは、そのような情報に通じた判断を容易にするのに基本的な要素である。ただし、一部の人々には雑音である或る情報が、他の人々には非常に貴重である可能性がある。さらに、一部の情報は、時間的にクリティカルでもある可能性があり、このため、そのような情報の適時の配信に関連する相当な価値が存在する可能性がある。さらに、一部の個人は、クリティカルでなくても、情報を知らされていることを選好する。課題は、個人の情報および配信の選好が大きく異なっているにも関わらず、所望の仕方で情報を提供することである。
【０００４】
情報を収集する多くの従来の方法は、率先して情報を要求および探索を行うことを必要とし、しばしば、数十のメッセージ、数百の記事をふるいにかけること、または報告書の中の数字または傾向を参照することを要求する。さらに、既存の技術は、そのような情報を所望する個人がコンピュータのところにいて、情報を検索する時間と能力を有するものと想定している。さらに、人々は、ますます移動するようになっており、コンピュータのすぐ付近に常にいることはできない。この結果、インターネット対応モバイルデバイスが、ますます普及しており、可用でアクセス可能である適切なデバイスであれば、どれにでも、場所に関わらず適時の個人化された情報を配信するサービスの需要を生じさせている。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
一部では、関心対象の情報を自動的に配信するアプリケーションに個人が加入することができるようにするシステムを構築することにより、そのような需要に対応する試みが行われている。ただし、そのような情報配信システムのほとんどは、場当たりの技術を使用して不十分な構成がなされている。さらに、従来のシステムには、多数の異質のイベントまたは発表に関連する有意義なクエリを処理すること、ならびに個人の配信選好のタイプおよび受信側デバイスのタイプが様々であることを考えて結果を加入者に配信することに関連する複雑さのために、拡張（ｓｃａｌｉｎｇ）に関して難点がある。したがって、従来の通知システムは、非効率であり、維持管理するのが困難であり、信頼できず、大規模なアプリケーションをホストするのに不十分である。
【課題を解決するための手段】
【０００６】
以下に、本発明のいくつかの態様の基本的な理解を提供するために、本発明の簡単な要約を提示する。この要約は、本発明の幅広い概要ではない。この要約は、本発明の主要な／クリティカルな要素を特定すること、または本発明の範囲を画定することを意図するものではない。この要約の唯一の目的は、本発明の一部の概念を簡略化した形態で、後に提示するより詳細な説明の前置きとして提示することである。
【０００７】
本発明は、通知プラットフォームに従って通知を配信するためのシステムおよび方法に関する。通知の効率的で適時の配信を円滑にする１つまたは複数のアプリケーションモデルを提供する。アプリケーションモデルは、通知プラットフォーム内部に組み込み、かつ／または通知プラットフォームに関連付けて、通知のタイプ、タイミング、および／または量を調整するための適合可能であり、構成可能なインターフェースまたはプラットフォームをユーザに提供することができる。モデルは、所望される場合、通知を受信する際にデバイスエンドからドライブされることが可能であり、ユーザは、１つまたは複数の配信ガイドラインを定義する複数のパラメータを構成することができる。また、このガイドラインは、例えば、大域パラメータの維持のため、またはデバイスの能力が限られている場合、プラットフォームエンドで記憶される／ドライブされることが可能である。さらに、モデルは、ユーザの加入体験を向上させるのに使用することができ、それにより、ユーザは、１つまたは複数の通知サービスに対して容易に、経済的に加入および加入取消しを行うことができる。さらに、加入は、ユーザからの明示的なコマンドに基づいて動的に調整すること、コンテキスト上のユーザ状態から推定すること、および／またはユーザに向けられた誘因またはその他の要因に基づくことが可能である。
【０００８】
本発明の一態様によれば、前述したアプリケーションモデルは、ユーザから通知仕様を受け取り、その仕様に基づき、そのような仕様に合うように、つまり満足させるように通知サービス／プロバイダを周旋する（ｂｒｏｋｅｒ）、またはリンクする仲介モデル（ｂｒｏｋｅｒｉｎｇ  ｍｏｄｅｌ）を含む。グループ内の加入者の数に基づき、団体、または他のタイプのグループに加入割引が与えられることが可能な動的価格設定モデルを提供することが可能である。他のタイプの価格設定には、サービスが使用された時間、または加入者によってサービスが消費された量に基づいてサービス割引またはサービス価格設定が加入者に提供される（例えば、購入された１０時間毎に、１時間のサービスが無料で追加される）使用ベースの価格設定が含まれることが可能である。さらに別のモデルでは、加入アクセスモデルを使用して、サービスに対する効率的な加入および加入取消しを円滑にすることができる。例えば、ユーザは、宇宙の惨事などのクリティカルなイベント中にマルチプロバイダニュースソースに加入することを所望するが、しばらく後、そのサービスを解約することを所望する（例えば、自動的な対処、手動の対処、および／または所定の対処）可能性がある。
【０００９】
他のタイプのモデルには、ユーザが、誘因または他の要因に基づいて通知の量およびタイプを調整することを可能にするプッシュタイプモデルおよびプルタイプモデルが含まれる。１つのプッシュ例では、ユーザが代替の通知サービスを受け入れる用意がある場合、ユーザに１ヶ月間の無料株式通知サービスなどの誘因が提供されることが可能である。プルタイプの例では、ユーザが、所定の加入パス以外の通知の受信が容認できるかどうか、どのような場合に容認できるかを制御する。また、どのように通知が受信されるかをユーザが制御することができるようにするデバイスモデルおよびフィルタリングモデルも提供されることが可能である。一部のケースでは、ユーザは、自由に使えるデバイスのタイプに基づき、異なる配信の状況または条件を所望する可能性がある。不要な通知の量を減らすためにフィルタリングが提供されることが可能である。本発明の別の態様は、自動化された料金請求−加入サービスに対する通知プラットフォーム対話が含まれる。したがって、料金請求サービスに関連する加入情報に基づいた通知が生成されることが可能であり、通知は、料金請求サービスによって料金請求される／コンタクトされる数量、ユーザ、および／またはエンティティが決められる、通知を介する一括料金請求（ｍａｓｓ  ｂｉｌｌｉｎｇ）のような態様を含むことが可能である。
【００１０】
一般に、以上のフレームワークおよびプロトコルは、拡張性が高く、複数の異なる加入サービスのプロバイダおよび加入者に関して大量のクエリを処理することができる通知アーキテクチャを介して通知サービスを提供することを円滑にする、自動化された通知システムに適合している。本発明の一態様は、信頼のおける高性能の拡張可能なアプリケーションを構築し、維持することを円滑にする分散通知プラットフォームを提供する。より詳細には、本発明のプラットフォームは、イベントスキーマ、加入スキーマ、通知スキーマ、および規則を豊かな仕方（例えば、ＸＭＬ）で表現するやり方を提供するとともに、加入サービスプロバイダが、通知を配信することに関連して実装される可能性があるコンテンツフォーマットおよびプロトコルを表現することを可能にする。本発明は、前述したスキーマに従って伝播される情報、フォーマット、およびプロトコルを組み込んで拡張性の高い通知サービスを提供する実行エンジンを含む。
【００１１】
本発明の別の態様は、加入情報および加入者情報（所望される場合、イベント情報も）を高レベルクラス（例えば、データフィールド）に抽出することを提供する。したがって、本発明は、そのような通知関連の情報をデータとしてモデル化することを提供する。これにより、加入アプリケーションを、例えば、複雑な加入クエリおよび加入者情報をデータフィールドとして定義することができる高レベルで開発することができる。データフィールドに従ったデータベースを加入／加入者特有の情報とともに伝播させることができる。本発明は、データベースエンジン（例えば、ＳＱＬサーバ）に関連する処理能力を活用して、テーブル（例えば、加入テーブル、加入者テーブル、およびイベントテーブル）の結合操作（ｊｏｉｎ  ｏｐｅｒａｔｉｏｎ）を行うことを介して通知を生成する。したがって、通知は、相当なコンピューティングリソースを消費する可能性がある加入者ごとの加入ごとにではなく、一括で生成される。通知関連の情報（例えば、加入クエリ、加入者情報、イベント情報等）をデータとしてモデル化し、リレーショナルデータベースの能力を活用して、そのデータに対してセット指向操作（ｓｅｔ−ｏｒｉｅｎｔｅｄ  ｍａｎｉｐｕｌａｔｉｏｎ）を効率的に行うことにより、本発明は、拡張性が高く効率的な通知システムを提供する。
【００１２】
以上の目的および関連する目的を達するため、本発明のいくつかの例示的な態様を本明細書で、以下の説明および添付の図面に関連して説明する。それらの態様は、本発明を実施することができる様々なやり方を示し、その様々なやり方のすべてが、本発明の範囲に含まれるものとする。本発明の他の利点および新規の特徴は、図面と併せて考慮した際、本発明の以下の詳細な説明から明白となり得る。
【発明を実施するための最良の形態】
【００１３】
本発明は、通知プラットフォームのフレームワークで使用することができる様々なアプリケーションに従って通知の自動化された配信を円滑にするシステムおよび方法に関する。アプリケーションを、ユーザが通知プラットフォームと容易に／便利に対話することができるようにするモデルによって説明する。１つのそのようなモデルには、所望のサービスのユーザ定義を受け取り、プラットフォームに従ってサービスバンドルをユーザに配信するためにそのようなサービスを連鎖させるサードパーティとして作用する仲介モデルが含まれる。動的価格設定モデルを提供して、通知サービスに関する量価格設定割引などの様々な要因に従ってサービスのデリバリを円滑にすることが可能である。加入アクセスモデルを提供して、ユーザがサービスに対して便利に加入および加入取消しを行うことができるようにし、他方、プッシュ／プルモデルを使用して、代替サービスのデリバリに関する１つまたは複数のオプションをユーザに提供することが可能である。現在のコンテキスト状態（例えば、休暇中である場合、戻るまでサービスを解約する）に基づいてユーザが自らの加入を変更することができるようにするコンテキストモデルを提供することが可能である。デバイスフィルタモデルが、通知のタイプおよび量を変えるためのコントロールをユーザに提供する（例えば、加入が行われた通知だけを許す、午前中にユーザＡおよびＢからの通知を許す、午後にユーザＡおよびＣからの通知を許す）。料金請求モデルが、自動化された料金請求と加入サービスとの間の対話、および通知プラットフォームの１つまたは複数との対話を記述することを含み、料金請求システムにおける１名または複数名のユーザに関連する加入イベント／メッセージが、通知プラットフォームを介してユーザに配信されることが可能である（例えば、サービスが解約された、先月の加入使用に関して口座に１０．００ドルの料金請求が行われた）。
【００１４】
本出願で使用する「構成要素」、「モデル」、「プロトコル」、「システム」等の用語は、ハードウェア、ハードウェアとソフトウェアとの組合せ、ソフトウェア、または実行中のソフトウェアであるコンピュータ関連のエンティティを指すものとする。例えば、構成要素は、プロセッサ上で実行されているプロセス、プロセッサ、オブジェクト、実行ファイル、実行のスレッド、プログラム、および／またはコンピュータであることが可能であるが、以上には限定されない。例として、サーバ上で実行されているアプリケーションとサーバとはともに、構成要素であることが可能である。１つまたは複数の構成要素がプロセス内および／または実行のスレッド内に存在することが可能であり、構成要素は、１つのコンピュータ上に局所化されていること、および／または２つまたはそれより多くのコンピュータの間に分散されていることが可能である。
【００１５】
本明細書で使用する「推論」という用語は、一般に、イベントおよび／またはデータを介して捕捉された１組の観察から、システム、環境、および／またはユーザの状態について推論する、またはその状態を推定するプロセスを指す。推論を使用して、例えば、特定のコンテキストまたは動作を明らかにすること、あるいは状態に関する確率分布を生成することができる。推論は、確率論的であること、つまりデータおよびイベントの考慮に基づく関心の状態に関する確率分布の計算であることが可能である。また、推論は、１組のイベントおよび／またはデータからより高いレベルのイベントを構成するために使用される技術も指すことが可能である。そのような推論により、イベントが非常に時間的に近く相関しているか否か、イベントおよびデータが１つのイベントソースおよびデータソースに由来するか、いくつかのイベントソースおよびデータソースに由来するかに関わらず、１組の観察されたイベントおよび／または記憶されたイベントデータからの新しいイベントまたは動作の構成をもたらす。
【００１６】
最初に図１を参照すると、本発明の態様による通知配信システム１００が示されている。システム１００は、通知を生成する１つまたは複数のイベントソース１１４から、通知プラットフォーム１１０を使用して、ソースから情報を受信する１つまたは複数の通信シンク１２０に情報を配信する。イベントソース１１４から情報を受信するため、１つまたは複数の加入１２４が獲得されて、イベントソースのいずれにより、通知シンク１２０において自動化された通知が行われるようにされるべきかが判定される。例えば、ニュース加入は、発表ニュース（ｂｒｅａｋｉｎｇ  ｎｅｗｓ）ソース、スポーツソース、およびビジネスニュースソースなどの３つの異なるニュースソースからの通知を含むことが可能である。加入者がこのタイプのニュース加入に適切に加入している場合、その３つのソースのいずれから生成された通知も、通知シンク１２０に送られることが可能であり、通知プラットフォーム１１０により、イベントソース１１４からの情報がシンクにいつ送られる、または転送されるかどうかが選択される。別の例では、様々な株式ソースから収集された情報を、株式通知をシンク１２０に配信する金融サービスに従って送ることが可能である。
【００１７】
通知プラットフォーム１１０は、複数のイベントソース１１４からのデータを処理し、結合操作を行って通知をシンク１２０に配信するＳＱＬサーバなどの様々な構成要素を含むことが可能であり、通知プラットフォーム１１０は、様々なデータベース操作および通信操作を行うことに留意されたい。したがって、通知プラットフォーム１１０は、１つまたは複数のイベントソース１１４からの情報を収集し、または集約し、収集された情報を通知シンク１２０に配信することができる。また、以下により詳細に説明する通知プラットフォーム１１０、イベントソース１１４、および通知シンク１２０の間の動作を円滑にするように様々なシステムおよび構成要素が提供されることが可能であることにも留意されたい。
【００１８】
通知の効率的で適時の配信を円滑にする１つまたは複数のアプリケーションモデル１３０が提供される。アプリケーションモデルは、通知プラットフォーム１１０内部に組み込まれ、かつ／または通知プラットフォーム１１０に関連付けられて、例えば、通知のタイプ、タイミング、および／または量を調整するための適合可能で構成可能なインターフェースまたはプラットフォームをユーザに提供することが可能である。さらに、アプリケーションモデル１３０は、イベントソース１１４、通知シンク１２０、および／または加入１２４に関連付けられ、かつ／または組み込まれることも可能である。モデルは、所望される場合、通知を受信する際に通知シンク１２０からドライブされることが可能であり、ユーザは、１つまたは複数の配信ガイドラインを定義する複数のパラメータを構成することができる。また、このガイドラインを、例えば、大域パラメータの維持のため、またはデバイスの能力が限られている場合、プラットフォームエンド１１０（または他の構成要素）で記憶する／ドライブすることが可能である。図示するとおり、通知を受信する際のユーザの所望を捕捉する／推定するユーザプロファイルおよび／またはユーザパラメータ１３４を提供することが可能である。このプロファイル／パラメータ１３４を、ファイルとして、または構造化された関係データとして、システム１００で示す構成要素の１つまたは複数において保持することが可能である。
【００１９】
アプリケーションモデル１３０を使用してユーザの加入体験を向上させることができ、ユーザは、容易に、経済的／自動的に１つまたは複数の通知サービスに対して加入および加入取消しを行うことができる。さらに、加入１２４は、以下により詳細に説明するとおり、ユーザからの明示的なコマンドに基づいて動的に調整すること、コンテキスト上のユーザ状態から推定すること、および／またはユーザに向けられた誘因またはその他の要因に基づくことが可能である。
【００２０】
本発明の一態様によれば、アプリケーションモデル１３０は、ユーザから通知仕様を受け取り、その仕様に基づき、そのような仕様（例えば、ＥＳＰＮおよび３つのラスベガスのホテルから通知を受け取るスポーツ加入を要望する）に合うように、つまり満足させるように通知サービス／プロバイダを周旋する、またはリンクする仲介モデル１４０を含む。したがって、仲介モデル１４０が、要求されたサービスを供給するサービスプロバイダを探索し、仕様を一括して加入１２４にして、加入情報（例えば、指定された通知サービスからの通知をユーザに送信するように通知プラットフォームに知らせるメッセージまたはデータ）を通知プラットフォーム１１０に通信することができる。
【００２１】
グループ内の加入者の数／タイプに基づいて加入割引がグループまたはグループ化に与えられることが可能な（例えば、会社Ａからのすべての加入者が１０％の割引を得る）動的価格設定モデル１４４が、本発明の別の態様に従って提供されることが可能である。他のタイプの価格設定には、サービス割引またはサービス価格設定が、サービスが消費された時間または量によって影響を受ける使用ベースの価格設定が含まれることが可能である。理解できるように、動的価格設定モデル１４４は、複数の要因または要因の組合せを使用して加入価格設定を変更する、または改変することができる。例えば、ある時間帯の間、または通知を受信するユーザの場所に基づき、所与の割引がユーザに与えられることが可能である。割引は、ある使用カテゴリに当てはまるユーザに、別のタイプの加入に関するクレジットが与えられることが可能である（例えば、医療警報のすべてのユーザが、栄養警報に対するクレジットを受ける）ような非金銭形態であることが可能である。さらに別のモデルでは、加入アクセスモデル１５０を使用して、サービスに対する効率的な加入および加入取消しを円滑にすることができる。例えば、ユーザは、株式市場の大暴落などのクリティカルなイベント中にマルチプロバイダニュースソースに加入することを所望するが、ある時間の後、または他の要因の後、そのサービスを解約することを所望する可能性がある。そのようなモデル１５０は、ユーザの通知の所望（例えば、２時間にわたって加入することを要望する、午前中に加入して、夜に加入取消しを行うことを要望する、１７日間の加入を要望する）により即したサービスの散発的な使用または断続的な使用を円滑にすることができる。
【００２２】
他のタイプのアプリケーションモデル１３０には、ユーザが誘因または他の要因に基づいて通知の量およびタイプを調整することができるようにするプッシュタイプおよびプルタイプのモデル１５４が含まれる。一例では、ユーザが代替の通知サービスを受け入れる用意がある場合、ユーザには、１ヶ月間の無料メール通知サービスなどの誘因（例えば、プラットフォーム１１０からプッシュされた通知）が提供されることが可能である。その他の誘因は、毎月１０の広告通知を受け入れる場合、現在のサービスの１つまたは複数に関してクレジットを受けるなどのより広いベースを有することが可能である。別の例では、ユーザは、所定の加入パス以外の通知の受信が容認できるかどうか、どのような場合に容認できるかを制御する。したがって、ユーザは、現在、受信されている情報に加えての情報をプラットフォーム１１０からプルすることをユーザが所望することを示す制御をユーザプロファイルおよびユーザパラメータ１３４において開始することができる。
【００２３】
コンテキストモデル１６０を使用して加入１２４を動的に変更すること、および／または通知プラットフォーム１１０の自動化された動作の変更を生じさせることができる。例えば、ユーザは、特定のコンテキストの間だけサービスに加入し、異なるコンテキストの間に他のサービスに加入することを所望することが可能である（例えば、仕事中、自宅の趣味の加入が使用不可にされることを要望し、忙しくないとき、３つのエンターテイメント通知サービスに加入する用意がある）。ユーザがどのように通知が受信されるかを制御することができるようにするデバイスモデル１６４およびフィルタリングモデル１６４も提供することが可能である。一部のケースでは、ユーザは、自由に使用できるデバイスのタイプに基づき、異なる配信の状況または条件を所望する可能性がある（例えば、セル電話機だけにアクセスを有する場合、デスクトップ加入が非アクティブにされることを要望する）。ジャンク／スパムメールフィルタおよび／またはユーザによって定義された規則などの様々なフィルタリングオプションに従って不要の通知の量を減らすようにフィルタリングが提供されることが可能である。別の態様では、料金請求モデル１７０が、自動化された料金請求−加入サービスに対する通知プラットフォームの対話／機能を含む。したがって、料金請求モデル１７０に関連する加入情報に基づく通知が生成されることが可能であり、通知は、料金請求モデルによって料金請求される／コンタクトされる数量、ユーザ、エンティティ、および／または他のファクタが決められる、通知プラットフォーム１１０によって生成された通知を介する一括料金請求または対象を絞った料金請求などの態様を含むことが可能である。本発明の様々な組合せに従って協働するようにアプリケーションモデル１３０の１つまたは複数を使用すること、および／または適合させることが可能であることに留意されたい。例えば、一態様では、加入アクセスモデル１５０とともに動作するようにプッシュ／プルモデル１５４を適合させることができる。別の例では、仲介モデル１４０をコンテキストモデル１６０、料金請求モデル１７０等に適合させることができる。
【００２４】
次に図２を参照すると、本発明の態様による仲介システム２００が示されている。本発明のこの態様では、通知ブローカ（ｂｒｏｋｅｒ）２１０（またはブローカ群）が、符号２２４で、遠隔デバイス２２０（またはデバイス群）にクエリを行う（遠隔デバイスからブローカにクエリが向けられることを含むことも可能である）。クエリ２２４は、電子メール、ネットワークポスティング（ｐｏｓｔｉｎｇ）、セル電話メッセージ、ポップアップウインドウなどの通知サービスのオファーを含むことが可能である。以下により詳細に説明するとおり、実質的にあらゆるタイプの通知シンクを含むことが可能である遠隔デバイス２２０が、インターフェース（図示せず）（例えば、ディスプレイ、テキストメッセージ）にクエリ２２４を向け、デバイスのユーザが、そのクエリ（例えば、リストからサービス、またはサービスのサブセットを選択するようにユーザに求めるＷｅｂクエリ）に加入するか否かを決める。したがって、遠隔デバイス２２０によって応答２３０が生成され、応答２３０の中で、オファーが行われた１つまたは複数の通知サービスにユーザが加入することを所望するか否かが示される（例えば、フラグ応答が、「はい」または「いいえ」、リスト選択を示し、スキーマ応答が、対抗のオファー、または他の条件を示す）ことが可能である。本発明の別の態様では、ユーザが、加入すべき１つまたは複数のサービスを要求する／指定する自発的な（ｕｎｓｏｌｉｃｉｔｅｄ）応答すなわち自発的な要求２３４をブローカ２１０に送るように遠隔デバイス２２０に指示する。
【００２５】
通知サービスに関する応答を受信した後（またはクエリの前に）、ブローカ２１０は、通知加入を組み立てる。例えば、ブローカ２１０は、１つまたは複数のサービスプロバイダ２４０と交渉して、そのサービスプロバイダが要求の通知サービスのデリバリを行うことができるかどうかを判定する。一例では、遠隔デバイス２２０のユーザは、「一般的なビジネス警報、会社Ｘに特有の警報、自分の普通預金（ｓａｖｉｎｇｓ  ａｃｃｏｕｎｔ）に影響を与える銀行業務警報、ならびに発表された地域ニュースおよび全国ニュースを配信する通知サービスを要望する」と指定することができる。すると、ブローカ２１０は、サービスプロバイダ２４０のいずれが、ユーザの応答２３０および／または自発的な要求２３４に関係する通知、または通知イベントを生成することができるかを求め、あるいは判定する。
【００２６】
本発明の一態様では、ブローカ２１０は、ブローカが、ユーザの要求に関係する通知を並ばせ、その通知を通知バンドル２４４で通知プラットフォーム２５０に送り、次に、通知プラットフォーム２５０が、遠隔デバイス２２０（またはデバイス群）におけるユーザにその通知を配信する通知仲介（ｎｏｔｉｆｉｃａｔｉｏｎ  ｂｒｏｋｅｒｉｎｇ）２４２を提供することができる。別の態様では、ブローカ２１０は、加入仲介２５２を行い、要求の通知サービスのデリバリを行うことができる利用可能なサービスプロバイダ２４０を決定する。決定の後、ブローカ２１０は、サービスバンドル２５４（例えば、通知サービスの構成要素、および構成要素を供給するサービスプロバイダを記述するファイルまたはスキーマ）を生成し、そのバンドルを加入として通知プラットフォーム２５０に送る。通知プラットフォーム２５０は、サービスバンドル２５４の中で示された任意のイベントに対する応答をセットアップし、そのバンドルから通知が生成された場合、そのバンドルに関連する遠隔デバイス２２０および／または通知シンクにそのような通知を向かわせる。理解することができるとおり、ユーザは、通知を受けることを所望するサービスのタイプを記述する、または定義することに加えて、いずれのデバイスが通知を受信するかを指定することができる。さらに、デリバリが行われたサービスに関するアカウント管理（例えば、配信された通知に関してユーザアカウントに課金すること）が、ブローカ２１０により、通知プラットフォーム２５０により、かつ／または以下により詳細に説明する自動化された料金請求−加入サービス／システムに従って提供されることが可能である。
【００２７】
図３を参照すると、本発明の態様による動的価格設定システム３００が示されている。この態様では、通知プラットフォーム３１０が、規則またはガイドラインを含むファイルまたは記憶媒体である動的価格設定構成要素３２０と対話し、この規則またはガイドラインから加入価格設定または配信条件を変更する、または改変することが可能である。動的価格設定構成要素３２０に含まれる価格設定オプションがユーザ、ユーザのサブセット、および／またはグループに適用されるかどうかを判定するため、そのようなユーザ／グループに関連するユーザプロファイル３３０が提供され（例えば、通知シンク／プラットフォームに関連するプロファイル）、選択されたグループにおけるメンバシップなどのユーザに関する情報、および通知サービスの利用に関するパターン情報を示す１つまたは複数の属性３４０が提供される。通知プラットフォーム３１０は、パフォーマンス構成要素３５０を使用して、その属性３４０が、動的価格設定構成要素３２０によって記述される価格設定プロモーションまたは価格設定割引の資格を与えるかどうかを判定する。例えば、価格割引があるグループのメンバシップに関して与えられ、属性３４０によりユーザがグループメンバであることが示される場合、パフォーマンス構成要素３５０を介してそれぞれのユーザにグループ割引の資格が与えられることが可能である（価格設定構成要素がそのように構成されていることを前提に）。
【００２８】
動的価格設定構成要素３２０は、ユーザが通知サービスに加入している間、価格設定調整を受けることができるようにする１つまたは複数のガイドラインを含む。前述したとおり、ガイドラインには、通知プラットフォーム３１０がグループのメンバとして資格のあるユーザに割引（例えば、金銭／使用のクレジット）を提供するグループ割引を含めることが可能である。別の態様では、量割引（ｖｏｌｕｍｅ）を与えることが可能である。したがって、１名または複数名のユーザが所定の数のサービスに加入する場合、所定の数に達すること、または加入すること、あるいは所定のしきい値を獲得することに基づいて量割引を適用することが可能である。動的価格設定構成要素３２０によって提供される他の割引には、時間ベースの考慮が含まれる。例えば、ユーザは、時刻、週、または月などの他の構成要素に基づいて加入するサービスに関する割引を受けることが可能である。したがって、そのような通知サービスにより、選択された時間中にサービスを使用する誘因がユーザに与えられることが可能である。ユーザが拠点とする場所に同様の考慮を与えることも可能である。例えば、カリフォルニア州／ＩＰアドレス（または他の場所）に居住するすべてのユーザが、１週間の無料サービス（または他の誘因）を受ける。
【００２９】
別の考慮またはガイドラインは、コンテキストベースの割引または調整であることが可能である（例えば、現在、忙しくない状態にあるすべてのユーザが休暇通知を受ける）。コンテキストおよび加入に関わる他の考慮は、図６に関連して以下により詳細に説明する。別の価格設定考慮は、ユーザベースであることが可能である（例えば、毎月Ｘ分間より多く通知プラットフォームを利用するすべてのユーザが割引を受ける）。さらに別の価格設定考慮には、関連ベースの調整が含まれる。そのような調整には、他の特定されたサービスの使用または加入に基づいてサービスまたは割引を提供することを含むことができる（例えば、ニュースサービスに加入したすべてのユーザに関して、追加費用なしにスポーツサービスが追加される）。
【００３０】
図４は、本発明の態様による加入制御システム４００を示している。この態様によれば、通知プラットフォーム４２０によって提供される通知サービスに対する加入および／または加入取消しを円滑にするように１つまたは複数の加入コントロール４１０が提供される。通知プラットフォーム４２０は、１つまたは複数の通知シンク４３０に送られる加入を使用可能にするため、および使用不可にするための加入構成要素４２４を含む。通知シンク４３０を操作するユーザと通知プラットフォーム４２０との間の関連するサービス合意またはサービス契約に従ってサービス使用、およびクレジットまたは料金請求を把握しておくため、アカウント構成要素４３４も提供することが可能である。
【００３１】
加入コントロール４１０（例えば、ファイルまたはスキーマ）により、サービスの加入および加入取消しを行うための様々な機構が提供される。一態様では、通知シンク４３０で提供されるボタンまたはグラフィカルユーザインターフェースによってオンまたはオフにすることができる加入スイッチまたは加入スイッチ４４０を提供することができる（例えば、グリーンのボタンが選択された場合、金融サービスに加入し、音声によって符号化または活動化されるフラグが、サービスの加入取消しを要望することを示す）。別の態様では、短期加入４４４を示すことが可能である。そのような加入には、１時間、または２日間、または他の期間にわたって加入することを要望するなどのオプションが含まれ、期間は、通知シンク４３０において入力されることが可能である。別のコントロールには、断続的加入４５０における断続的な加入が含まれる（例えば、月曜日と火曜日に関して加入し、日曜日まで加入取消しすることを要望する）。別のタイプのコントロールにはユーザが試用加入４５４で試みの加入できるようにすることが含まれる（例えば、自分の加入が自動的に終了する試みの期間の加入を要望する）。転換オプション４６０で、１つまたは複数の転換オプションを選択することが可能である。そのようなオプションには、あるタイプの加入を別のタイプの加入に転換すること（例えば、スポーツ加入を健康通知加入で置き換える）、およびある期間を別の期間に転換すること（例えば、長期加入を短期加入に転換する、試みの加入を恒久的な加入に転換する）が含まれる。理解されるとおり、様々な組合せおよびオプションが加入コントロール４１０に提供されて、サービスに対する加入および／または加入取消しを円滑にすることが可能である。
【００３２】
図５は、本発明の態様によるプッシュ／プルシステム５００を示している。この態様では、通知プラットフォーム５１０（ブローカを含むことが可能である）と遠隔デバイス５２０との間で他の通知（加入された通知以外の）を交換することが可能である。一態様では、通知プラットフォーム５１０によってどのようなサービスが提供されるかを決定するため、プル要求５３０が遠隔デバイス５２０によって生成される。これには、通知プラットフォーム５１０が、加入されていない通知またはメッセージを送信することを許すコントロールをユーザプロファイル５３４内で設定することが含まれる。例えば、遠隔デバイス５２０が、プラットフォーム５１０内の様々なサービスを売り込む請求されていない通知または広告を受け取ることを所望する可能性がある（ユーザプロファイル内でコントロールが変更されるまで）。そのような情報には、例えば、価格設定情報および他のサービスとの比較情報を含めることが可能である。また、これには、複数の異なる、または同様の／競合するソースからサンプル通知を受け取ることを含めることも可能である。
【００３３】
本発明の別の態様では、符号５４０で、誘因および／または他のタイプの情報が、ユーザに対してプッシュされることが可能である。一例では、符号５４０で、それぞれサービスを使用するようにユーザを誘導することを試みる複数のオファー、誘因、および／またはオプションが、ユーザに提供されることが可能である。例えば、誘因は、「スポーツサービスに加入すれば、ニュースサービスで５０％の割引が貴方に与えられます」といったような言い回しになっていることが可能である。別の例には、「貴方が、６：００台に通知を介して請求されていない広告を受け取ることに合意する場合、貴方は、１ヶ月間、無料サービスを受けます」が含まれる。理解することができるとおり、複数のそのような誘因が提供されることが可能である。遠隔デバイス５２０を操作するユーザがオファーを受け入れる／拒否することを決めた場合、ユーザは、応答５５０を通知プラットフォーム５１０に送り返すメニューオプションまたはデバイス機構を選択することができる。ユーザは、いずれのプッシュタイプの通知も軽減する、または無くすことができるコントロールをユーザプロファイル５３４内で設定できることに留意されたい。
【００３４】
図６は、本発明の態様による加入−コンテンツ構成要素６００を示している。この態様では、ユーザコンテキストを使用して加入活動を制御することが可能である。例えば、加入構成要素６０４が、コンテキストモデル６１０から導出されたコンテキスト情報に応じて１つまたは複数の加入を活動化または非活動化させることが可能である。一態様では、コンテキスト状態または他のコンテキストデータに応じて、コンテキストモデル６１０によって提供される１つまたは複数の態様に基づいて加入は加入が行われること、または加入取消しが行われることが可能である。例として、一部のユーザは、検出されたコンテキストに応じてあるタイプの通知を要望するが、現在の活動に起因して通知を受け取ることをコンテキストが許さない時間中、サービスに加入することを要望しない可能性がある（例えば、コンテキストが仕事である場合、趣味通知ソースに対する加入取消しを行い、職業ソースに加入する）。理解することができるとおり、加入構成要素６０４は、加入を実際に活動化すること、および非活動化することを行わず、単に、コンテキスト、またはコンテキストを指定する規則によって通知の適切な受信が許されない期間中、ユーザのアカウントに払戻しを行うことが可能である。コンテキストモデル６１０に関連し、加入構成要素６１０を変更する、または加入構成要素６１０に影響を与える可能性がある他の態様を以下に説明する。
【００３５】
コンテキスト情報（またはコンテキスト）は、システムが、ユーザのために通知を生成し、経路指定することをインテリジェントに行うことを可能にするユーザ、およびユーザの活動に関する情報である。コンテキスト情報の例には、以下が含まれる。
・インスタント・メッセンジャ存在情報
・交換カレンダ情報
・セル電話網またはＧＰＳ受信機によって報告される物理位置情報
・ユーザがキーボードでタイプ入力しているか、マウスをクリックしているか、またはフルスクリーンモデルにおいてアプリケーションを実行しているかなどのユーザのシステムによって収集される情報
【００３６】
コンテキスト情報は、通常、コンテキストソース６２０を起点とし、加入構成要素６０４などのコンテキスト消費側（Ｃｏｎｓｕｍｅｒ）によって使用される。コンテキスト情報は、コンテキストサービスによってコンテキストソース６２０からコンテキスト消費側に伝播されることが可能である。コンテキストソース６２０の場所が、コンテキスト起点（または起点）である。コンテキスト消費側の場所が、コンテキスト宛先（または宛先）である。  
コンテキスト情報は、多種多様なコンテキストソース６２０によって供給されることが可能である。
【００３７】
（ハードウェアコンテキストソース）
システムは、ハードウェアデバイスのステータスを監視することによってコンテキスト情報を収集することができる。
１．キーボード活動
２．マウス活動
３．電話活動（電話がオン／オフになっている、電話会話が進行中等）
４．ＰＤＡ活動
５．セル電話網内の物理的場所
６．ＧＰＳ受信機によって報告される物理的場所
７．イメージ認識にリンクされたＷｅｂカメラ
８．音声認識にリンクされたマイクロホン
９．動きセンサ
１０．赤外線センサ
【００３８】
（ソフトウェアコンテキストソース）
システムは、オペレーティングシステム、および実装されたアプリケーションからコンテキスト情報を収集することができる。
１．Ｗｉｎｄｏｗｓ（登録商標）
ａ．ユーザがログインしている
ｂ．ユーザがフルスクリーンアプリケーションを実行している
２．Ｅｘｃｈａｎｇｅ
ａ．Ｅｘｃｈａｎｇｅが電子メールを読むのに使用されている
ｂ．Ｅｘｃｈａｎｇｅカレンダデータ
ｃ．Ｅｘｃｈａｎｇｅ「アウトオブオフィス（Ｏｕｔ  ｏｆ  Ｏｆｆｉｃｅ）」ステータス
３．ＩＭ
ａ．ＩＭメッセージを送受信するのにＩＭクライアントが使用されている
ｂ．ユーザがＩＭステータスに入った
４．Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒまたは他のブラウザ
ａ．ＩＥがＷｅｂをブラウズするのに使用されている
５．Ｏｆｆｉｃｅ
ａ．プレゼンテーションモードを供与するのにＰｏｗｅｒｐｏｉｎｔが使用されている
ｂ．電子メールをブラウズするのにＯｕｔｌｏｏｋが使用されている
ｃ．ドキュメントを作成するのにＷｏｒｄまたはＥｘｃｅｌが使用されている
６．Ｗｉｎｄｏｗｓ（登録商標）  Ｍｅｄｉａ  Ｐｌａｙｅｒ
ａ．音楽またはビデオを再生するのにＷｉｎｄｏｗｓ（登録商標）  Ｍｅｄｉａ  Ｐｌａｙｅｒが使用されている
７．サードパーティアプリケーションが、コンテキスト情報を提供することができる
【００３９】
（パターン検出コンテキストソース）
システムおよびアプリケーションプログラムが、行動パターンを認識することによってコンテキスト情報を推定することができる。例えば、システムは、ユーザが、通常、平日の予測可能な時間帯にログインおよびログアウトを行うことを認識することが可能である。
【００４０】
符号６３０で、コンテキスト特徴付けが行われることが可能である。コンテキスト情報は、以下のとおり特徴付けられることが可能である。
コンテキストソース
誰がコンテキストを提供するかを指定する
コンテキスト消費側
誰がコンテキストを消費するかを指定する
有用性
通知を生成する際、または送る際にコンテンツ情報がどれだけ有用であるかを指定する。有用性は、高い、中間、または低い（または他の指定）として指定される。
精度
システムがコンテキスト情報にどれだけ信頼をおくことができるかを指定する。一部のコンテキスト情報は、絶対的に正確であり、信頼でき、他のコンテキスト情報は、ヒューリスティックであるか、または部分的にだけ信頼できる可能性がある。精度は、高い、中間、または低い（または他の指定）として指定される。
センシティブ度（ｓｅｎｓｉｔｉｖｉｔｙ）
意図しない開示からコンテキスト情報を守るのにどれだけの労力をシステムが費やさなければならないかを指定する。センシティブ度は、高い、中間、または低い（または他の指定）として指定される。
起点／宛先／伝播距離
起点は、コンテキスト情報が起点とする場所を指定する。起点は、デスクトップ、デバイス、企業サーバ、ネットワークサーバ、キャリアネットワーク等として指定される。宛先は、コンテキスト情報が消費される場所を指定する。宛先は、デスクトップ、企業サーバ、ネットワークサービス等として指定される。伝播距離は、コンテキスト情報を起点から宛先まで動かすのにコンテキスト情報がどれだけの距離だけ伝播されなければならないかを指定する。伝播距離は、ローカル（またはシステム内）、イントラネット、またはインターネットとして指定することができる。伝播距離は、コンテキスト情報伝播のパフォーマンス、信頼性、およびセキュリティに影響を与える可能性がある。
不安定度（Ｖｏｌａｔｉｌｉｔｙ）
コンテキスト情報がコンテキストソースにおいてどれだけ頻繁に変化するかを指定する。不安定度は、秒、分、時、日、週、月、または年あたりの変化に換算して指定される。
アクセス頻度
コンテキスト情報がどれだけの頻度でコンテキスト消費側によってアクセスされるかを指定する。アクセス頻度は、秒、分、時、日、週、月、または年あたりのアクセスに換算して指定される。
サイズ
どれだけのコンテキスト情報が提供され、伝播され、キャッシュに入れられ、消費されるかを指定する。サイズは、バイト数で指定される。
保持するためのユーザ労力
正確なコンテキスト情報を保持するのにどれだけの労力をユーザが費やさなければならないかを指定する。システムがユーザのために自動的に保持し、ユーザ労力を全く必要としないコンテキスト情報の方が、ユーザが手作業で保持しなければならないコンテキスト情報よりも保持される可能性が高いものと想定することができる。また、そのコンテキスト情報の方が、より正確である可能性も高い。保持するためのユーザ労力は、高い、中間、または低いとして指定される。
【００４１】
符号６４０で、コンテキスト消費側の特徴付けが行われることが可能である。コンテキスト消費側は、以下のとおり特徴付けられることが可能である。
コンテキスト消費側
コンテキスト消費側は誰か？
コンテキスト消費側の場所
コンテキスト消費側の場所は、コンテキストソースにローカルか、またはコンテキストソースから離れているか？
コンテキスト要件
コンテキスト消費側はどのようなコンテキストを必要とするか。コンテキスト消費側はどのような形態のコンテキストを必要とするか。すなわち、１つまたは複数の個々のコンテキストソースからの現在のコンテキストか、１つまたは複数の個々のコンテキストソースからのコンテキストステータスの変化か、多数のコンテキストソースからの要約されたコンテキストか？
コンテキストアクセス頻度
コンテキスト消費側はどれだけの頻度でコンテキストにアクセスするか？
コンテキスト新鮮度（Ｆｒｅｓｈｎｅｓｓ）
コンテキストはどれだけ新しく、つまり新鮮でなければならないか？
コンテキスト待ち時間
コンテキスト消費側は、新鮮な獲得するのにどれだけ待つことができる余裕があるか？
【００４２】
符号６５０で、コンテキストモデルが、コンテキストソースからコンテキストを獲得することを記述する。コンテキストソースは、以下の仕方でコンテキスト情報をコンテキストサービスに供給することができる。
変化時のプッシュ（Ｐｕｓｈ  ｏｎ  Ｃｈａｎｇｅ）
コンテキストソースは、コンテキスト情報が変化するたびに毎回（またはコンテキスト情報が変化するたびに毎回、ただし指定された間隔よりも低い頻度で）、コンテキスト情報をコンテキストサービスにプッシュすることができる。
スケジュールどおりのプッシュ（Ｐｕｓｈ  ｏｎ  Ｓｃｈｅｄｕｌｅ）
コンテキストソースは、指定されたスケジュールどおりコンテキスト情報をコンテキストサービスにプッシュすることができる。
スケジュールどおりのプル（Ｐｕｌｌ  ｏｎ  Ｓｃｈｅｄｕｌｅ）
コンテキストサービスは、指定されたスケジュールどおりコンテキストソースからコンテキスト情報をプルすることができる
要求に応じたプル（Ｐｕｌｌ  ｏｎ  Ｄｅｍａｎｄ）
コンテキストサービスは、コンテキスト消費側がコンテキスト情報を必要とする場合にだけコンテキストソースからコンテキスト情報をプルすることができる。
【００４３】
符号６６０で、コンテキスト伝播が考慮される。  
コンテキストサービスは、コンテキスト情報を受け取った際、コンテキスト情報を起点から宛先に以下の仕方で伝播させることができる。コンテキストソースは、１つのモデルを使用してコンテキストサービスにコンテキスト情報を供給することができ、一方、コンテキストサービスは、異なるモデルを使用して起点から宛先にコンテキスト情報を伝播させることができることに留意されたい。
変化時のプッシュ（Ｐｕｓｈ  ｏｎ  Ｃｈａｎｇｅ）
コンテキストサービスは、起点において、コンテキスト情報が変化するたびに毎回（またはコンテキスト情報が変化するたびに毎回であるが、指定された間隔よりも低い頻度で）コンテキスト情報を宛先にプッシュすることができる。
スケジュールどおりのプッシュ（Ｐｕｓｈ  ｏｎ  Ｓｃｈｅｄｕｌｅ）
コンテキストサービスは、起点において、指定されたスケジュールに従ってコンテキスト情報を宛先にプッシュすることができる。
スケジュールどおりのプル（Ｐｕｌｌ  ｏｎ  Ｓｃｈｅｄｕｌｅ）
コンテキストサービスは、宛先において、指定されたスケジュールに従って起点からコンテキスト情報をプルすることができる。
要求に応じたプル（Ｐｕｌｌ  ｏｎ  Ｄｅｍａｎｄ）
宛先におけるコンテキストサービスが、コンテキスト消費側がコンテキスト情報を要求した際に起点からコンテキスト情報をプルすることができる。  
起点が通知サービスインスタンスを含む場合、コンテキストサービスは、イベントによってトリガされる、またはスケジュール設定される通知サービス加入を使用して前述のモデルを実装することができる。変化時のプッシュを、イベントによってトリガされる加入として実施することが可能である。スケジュールどおりのプッシュ、およびスケジュールどおりのプルを、スケジュール設定された加入として実施することができる。要求に応じたプルを、「１回限りの」スケジュール設定された加入として実施することができる。
【００４４】
符号６７０で、モデルがコンテキスト情報をコンテキスト消費側に開示する。コンテキストは、通知サービス生成器内または情報エージェントルータ内で実施される規則によって消費される。規則は、コンテキストクラスの基礎にあるコンテキストテーブルからコンテキスト情報を取得するコンテキストファンクションを呼び出すことによってコンテキスト情報を取得する。以上に鑑みて、加入構成要素６０４は、それぞれの加入を活動化するか、あるいは非活動化するかを決める際、コンテキストモデル６１０の１つまたは複数の態様を使用することができる。
【００４５】
図７は、本発明の態様による通知を受信するためのデバイス構成７００を示している。この態様では、通知シンクは、どのように通知がシンクに配信されるかをユーザが調整する、または調節することができるようにする１つまたは複数の通知態様を構成する。図示するとおり、以上の態様は、どのように通知をシンク７１０に配信するかを決める際に通知プラットフォームまたはブローカによって読み取られるユーザプロファイル７２０の中に記憶することができる。符号７３０で、通知を受信するデバイスが指定される。例えば、ユーザは、情報警報がセル電話機および無線ラップトップコンピュータに向けられることを所望する可能性があるが、他方、ハイエンド（ｈｉｇｈ−ｅｎｄ）のグラフィックス通知は、デスクトップコンピュータだけに送信されるべきである。あるいはまた、ユーザは、サービスＡおよびサービスＢが通知をデスクトップに向かわせるべきであり、他方、サービスＣは、通知を自宅電子メールアドレスに向かわせるべきであると指定することができる。符号７３４で、１つまたは複数のデバイス能力が指定される。この態様では、指定された機能に応じて、通知サービスは、デバイス能力に基づいて通知出力、または加入を変更する、または調整することができる（例えば、セル電話機ディスプレイに関して、メッセージチャンキング（ｃｈｕｎｋｉｎｇ）規則を活動化する）。
【００４６】
符号７４０で、１つまたは複数のデバイスフィルタオプションを選択することが可能である。このオプションには、不要な通知の受信を軽減するようにジャンクフィルタオプション、またはスパムフィルタオプションを活動化することが含まれる可能性がある。他のオプションには、通知が加入した通知サービス、および／または指定した通知ソースから受信されることだけを許すようにコントロールを設定することが含まれる。さらに他のオプションには、通知を制限する、または軽減するのに使用することができる１つまたは複数の規則の指定が含まれることが可能である（例えば、仕事時間中にメッセージが趣味通知サービスから受信された場合、通知を廃棄するか、または帰宅するまでメッセージを待ち行列に入れる）。符号７４４で、１つまたは複数の配信条件を指定することが可能である（例えば、セル電話機が可用である場合にだけ、加入した通知をデスクトップの待ち行列に入れ、昼休みでない時間中にデスクトップにいる場合、仕事の後に通知を送る）。符号７５０で、１つまたは複数のデバイス条件を指定することが可能である（例えば、緊急通知だけをセル電話機に経路指定し、個人通知をラップトップおよびデスクトップに経路指定し、デスクトップから離れている場合、ビジネス通知の加入取消しを行う）。
【００４７】
図８および９は、本発明に従って通知プラットフォーム、および／または通知プラットフォームに関連する構成要素で使用することができる自動化された料金請求サービスおよび加入サービスを示している。図８を参照すると、システム８００は、本発明の態様による分散コンピューティング環境における料金請求−提供処理アーキテクチャを示している。システム８００は、通知プラットフォームに関連するパーティとエンティティとの間の様々な料金請求関係をサポートするインフラストラクチャを提供する。外部料金請求イベントおよび提供イベント８１４に応答し、それぞれの処理エンジン８１２に関連する複数の規則８１６に従って動作する１つまたは複数の処理エンジン８１２が提供される。イベント８１４は、処理エンジン８１２内部に内部で決定されたイベント（不図示）を含むことができ、一般に、加入イベントモデルに適合する。モデルは、加入ライフサイクル（例えば、電子メールなどのオンラインサービスに関する加入）において加入が通る可能性がある状態遷移を表わす。そのようなイベント８１４の例には、加入事前購入、加入購入、加入後援、加入キャンセル、加入不可（ｄｉｓａｂｌｅ）、加入可能（ｅｎａｂｌｅ）,加入転換元（Ｃｏｎｖｅｒｔ  Ｏｕｔ  ｏｆ）、加入転換先（Ｃｏｎｖｅｒｔ  ｉｎｔｏ）、加入更新、加入使用イベント報告、失効する加入、ユーザサービスプロファイル変更、加入失効、サービス割振り、サービス割振り解除、サービス中断、サービスイネーブルが含まれることが可能である。他のそのようなイベントも本発明に従って定義することができることを理解されたい。
【００４８】
規則８１６には、サービスデリバリ規則、資格付与（ｑｕａｌｉｆｉｃａｔｉｏｎ）規則、格付け規則、および／または処理エンジン８１２に従って料金請求処理および提供処理を円滑にする他のタイプの規則を含めることが可能である。イベント８１４の性質に応じて、処理エンジン８１２は、そのイベントに関連する規則８１６のセットまたはサブセットを適用する。例えば、サービスデリバリ規則は、サービスのタイプ、サービスレベルデリバリ、および／またはサービスのパフォーマンスおよび支払いに関係する関連したリソースバランスについてのデータを含む、デリバリされるサービスの最小単位を定義する。資格付与規則は、それぞれのサービスの購入の適格性要件を定義する。以上の規則は、限られた１組のユーザ、ユーザ言語、通貨、国、テナント、サービスプロバイダ、既存のサービスおよび／または所有されるオファー、特定のテナントとの提携、特定の方法による支払い等にサービスの購入を制限し、かつ／または変更するように生成することができる。レーティング規則は、課金をもたらし、かつ／またはサービスの消費および割振りを監視する非通貨を含む通貨バランスに対するバランスの影響（ｂａｌａｎｃｅ  ｉｍｐａｃｔ）を決めることを円滑にする。以上の規則は、前述した加入イベントモデルのコンテキストにおいて処理される個別のオファーの範囲内で定義することができる。以下により詳細に説明するとおり、システム８００内部の料金請求および提供、ならびに処理エンジン８１２による関連する加入／イベント処理をサポートするように１つまたは複数のデータストア８１８が提供される。
【００４９】
１つまたは複数のテナント８３０、１つまたは複数のサービスプロバイダ８３４、および１名または複数名の顧客８４０の間で料金請求関係、提供関係、およびアカウント関係を確立し、保持するために、１つまたは複数の加入プラットフォームオブジェクト（ＳＰＯ）８２４を含む加入プラットフォームサービス（ＳＰＳ）８２０が提供される。一般に、テナント８３０は、サービスプロバイダ８３４によって行われるサービスを顧客８４０に売り、そのようなサービスに関するそれぞれの料金請求アカウントを生成し、管理するのにＳＰＳ８２０が使用される。テナント８３０は、サービス、またはサービス（関係するか、または無関係の）のパッケージをサービスの顧客８４０に、つまり消費側に提供する。オファーは、システム８００におけるサービスに関連する売れる品目の最小単位を含むことが可能である。オファーは、サービスデリバリ規則、資格付与規則、およびレーティング規則の集合を含むことが可能であり、加えて、それぞれの適格な言語に関する複数の言語記述および価格設定記述を含み、システム８００によって使用される追加のメタデータを含めることができる。加入は、それぞれのエンドユーザまたは顧客８４０に関連するオファーのインスタンスを提供する。
【００５０】
サービスに対する加入が所望される場合、テナント８３０は、顧客８４０からクレジットカード情報、または他のタイプの料金請求協定を取得し、顧客と法的情報または契約情報を交換し、そのサービスまたはサービス群に関して規則的に、または定期的にその顧客に課金する額を決める。テナント８３０は、ＳＰＳ８２０を使用して料金請求アカウントを生成し、顧客のクレジットカードまたは他の手段を関連する金融機関で認定し、顧客８４０にサービスを提供することを始めるようにサービスプロバイダ８３４に通知する。サービスがサービスプロバイダ８３４によって行われるにつれ、ＳＰＳ８２０は、顧客のアカウントに料金請求を行う。システム８００内に示した他の構成要素が、本発明に従ってサービスを顧客８４０に提供、販売することができることを理解されたい。例えば、サービスプロバイダ８３４は、それぞれのテナント８３０と対話することなく顧客８４０にサービスを提供し、販売することができる。
【００５１】
ＳＰＳ８２０が関与する他のパーティまたはエンティティには、顧客アカウントの進行中のサポートおよび管理を符号８４４で提供する顧客サービス構成要素が含まれる。符号８５０で支払いプロバイダ（例えば、銀行、金融機関）が、顧客アカウントの支払いを円滑にし、他方、金融オペレーション、ビジネスオペレーション、および製品オペレーションの態様が符号８５４で示されている。金融オペレーションおよびビジネスオペレーションは、所望される場合、データの操作および解析のためにＳＰＳ８２０を使用することができ、他方、製品オペレーションは、ＳＰＳ８２０を利用して、例えば、パッケージ化されたサービスを伴うような製品カタログ提供を決定し、提供することができる。
【００５２】
本発明の一態様によれば、アプリケーションプログラムインターフェースセット（ＡＰＩ）８６０〜８７０が提供され、それぞれのエンティティ８３０〜８５４がＳＰＳ８２０と対話することが可能である。ＡＰＩセット８６０〜８７０は、一般に、ＳＰＳ８２０に対するインターフェースとして働く。テナント８３０、サービスプロバイダ８３４、顧客８４０、顧客サービス代理店８４４、支払いプロバイダ８５０、および／または金融／その他のオペレーション８５４が、加入プラットフォームサービス８２０の１つまたは複数の機能にアクセスするのはＡＰＩセット８６０〜８７０を介してである。例えば、ＡＰＩセット８６０〜８７０は、アカウント管理、製品カタログの探索および操作、加入管理、ユーザ許可、ユーザイベント、オンラインステートメント／セルフケア、顧客サービスユーティリティ、ビジネスオペレーションおよび製品オペレーション、ユーティリティ、イベントおよび通知、および／または提供サポートなどの態様の１つまたは複数を開示することができる。
【００５３】
提供、料金請求、および／または顧客ケアのためのプラットフォームオブジェクト８２４を定義する拡張可能なマークアップ言語（ＸＭＬ）スキーマを提供することが可能である。例えば、オブジェクト８２４には、可能なオブジェクト機能を挙げると、アカウント、支払い手段、オファー、サービス構成要素、加入、サービスインスタンス、役割割当て、許可証、リソース、料金請求書期間情報、料金請求書支払い情報、料金請求書細目、コメント、および／または清算情報を含めることが可能である。エンティティ８３０〜８５４は、ＳＰＳ８２０と対話すること、および／またはネットワーク８７０を介しておよびプロトコル８７４によりエンティティ間で対話することもできる。
【００５４】
プロトコル８７４は、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）を含むことが可能である。ただし、理解することができるとおり、他のプロトコルを選択することも可能である。ＳＯＡＰは、例として、情報交換のための構成要素としてハイパーテキスト転送プロトコル（ＨＴＴＰ）および／またはＸＭＬを利用することにより、あるタイプのオペレーティングシステムで実行されるプログラムが、同一の種類のオペレーティングシステム、または別の種類のオペレーティングシステムのプログラムと通信するのを円滑にする。オプションのパートナサポートオブジェクト（ＰＳＯ）８８０が、エンティティ８３０〜８５４に提供されてエンティティとＳＰＳ８２０との間の通信を円滑にすることが可能である。例えば、ＰＳＯ８８０により、ＳＰＳ８２０に対する接続を確立するためのヘルパインターフェースが提供され、かつ／または動作を円滑にするためにオブジェクトの接続プーリング（ｐｏｏｌｉｎｇ）が提供されることが可能である。ＰＳＯ８８０は、一般に、接続インターフェースなどの単一のＡＰＩを開示する。ＰＳＯ８８０をインストールした後、それぞれのエンティティ８３０〜８５４は、所望される場合、認証、許可、および／または他の通信のためにＰＳＯ８８０を利用することができる。
【００５５】
システム８００内に図示した構成要素を、異なるマシン上または異なるコンピュータ上で別個に実行することが可能であり、それぞれの構成要素自体、複数のマシン上、または複数のコンピュータ上で実行することが可能であり、したがって、分散コンピューティング環境におけるマルチレベル構成要素分散が提供される。本発明の一態様によれば、いくつかのマシン（例えば、パーティション）にわたる加入および料金請求情報の区分化を扱うように経路指定機構、またはプロトコルが提供されることが可能である。これにより、システム８００を通るより高いレベルのトラフィックを処理することが容易になるが、それでも、システムにおけるあるレベルの耐故障性が維持される。例えば、情報の特定のアイテムがどのパーティションに配置されることが可能であるかを決めるハッシュアルゴリズムとデータベース（例えば、タワー）の組合せを介して情報を区分化することができる。
【００５６】
次に図９を参照すると、システム９００は、本発明によるイベント処理アーキテクチャを示している。システム９００は、加入プラットフォームサービス（ＳＰＳ）層９１０を介して外部パーティとのランタイム通信を指向する多層アーキテクチャに編成することができる。ＳＰＳ９１０は、システム９００と通信するパートナに関連する層におけるパートナごとの許可の実施を容易にするパートナ許可マネージャ（ＰＰＭ）９１４を含む。ＰＰＭ９１４は、トランザクションごとにパートナ許可モデルを実施するのに使用され、適切な許可を有するそれぞれのパートナが個々の加入およびサービス状態を変更することができるようにする。パートナ許可モデルは、システム９００内の個々の加入、アカウント、および／またはサービス状態をパートナが変更する能力を定義する、登録されたパートナ（例えば、テナントおよび／またはサービスプロバイダ）に関連する権利を記述する。
【００５７】
ＳＰＳ９１０は、システム９００内の様々なエンジン９２０による処理を調整し、一般に、様々なデータストア９２４の中にデータを書き込むこと、およびそのデータを更新することを制御する。サービス構成要素定義、パートナ許可、および／またはオファーメタデータのカタログを記憶する定義されたＳＱＬサーバデータベースを含むことが可能な製品カタログ９３０が提供される。また、製品カタログ９３０は、個々のオファーに関連するレーティング規則、資格付与規則、および／またはサービスデリバリ規則も含むことが可能である。製品カタログ９３０によってサポートされるさらなる特徴には、サービス構成要素登録（例えば、構成要素ＩＤ割当て、パートナＩＤ、ＵＲＬ、サポート情報）、マルチサービス構成要素オファーおよびクロスパートナバンドル（ｃｒｏｓｓ  ｐａｒｔｎｅｒ  ｂｕｎｄｌｅ）を含むクロスパートナオファーが含まれる。カタログ９３０は、実質的にサービスのあらゆる組合せをマップするオファーのグループを提供することに加え、複数の国、言語、関連する通貨、関税、および税金に従った世界的規模に広げられたオファーを含むことが可能である。
【００５８】
オファー情報は、製品カタログ９３０の中に記憶することも可能である。この情報には、ベース情報、アップグレード情報、ダウングレード情報、更新情報、アドオン情報、およびサービス間の相互排他性情報を含めることが可能である。さらに、販売の日付、パートナ、言語、国、通貨、アカウント当たりの最大所有者、および有効な支払い手段に関する適格性情報を提供することが可能である。他のオファー情報は、料金請求サイクル（例えば、月々の料金請求、複数月の料金請求、２８日の料金請求、先払い（ｆｏｒｗａｒｄ）／後払い（ａｒｒｅｒｓ）サイクル料金請求）に関する。また、これには、自動的な更新または確認された更新などの更新に関係する情報、およびアカウントを清算する猶予期間に関係する情報も含めることが可能である。他のカタログ項目には、関連するイベントが生じた際に実行されるべき規則のサブセットを定義する、エントリをマップするイベントの規則を含めることが可能である。
【００５９】
バランス影響格付けエンジン（ｂａｌａｎｃｅ  ｉｍｐａｃｔ  ｒａｔｉｎｇ  ｅｎｇｉｎｅ）９３４が、加入ストア９９０の中に記憶することができる加入および関連する加入イベントのコンテキストにおいてそれぞれ、製品カタログ９３０および格付け済みイベントストア（ｒａｔｅｄ  ｅｖｅｎｔ  ｓｔｏｒｅ）９３２からの拡張可能な１組の格付け規則および／または格付けイベントを処理する。このエンジン９３４は、多数のサービスプロバイダ、テナント、顧客、および／または他のエンティティのスケールで提供された複数のバランス影響イベント（例えば、サービスの支払いおよび利用に影響を与えるイベント）を処理することができる。バランス影響イベントは、符号９９４で、料金請求影響ストアの中に記憶され、処理されることが可能である。リソースバランスストア９５０が、バランス影響格付けエンジン９３４による格付け規則の処理からもたらされたそれぞれのアカウントに関する総額を保持する。バランスは、表わされるサービスのユニットに関する値を示すように「タイプ付けする」ことが可能であり、１つまたは複数のサービスデリバリ規則にスコープすることができる。これには、通貨リソースおよび非通貨リソースを処理すること、ならびに、例えば、購入、キャンセル、サイクル、使用報告、転換（ｃｏｎｖｅｒｔ  ｔｏ／ｆｒｏｍ）、更新、中断、および再開などのユーザ主導イベント（ＵＤＥ）に応答する格付け規則を処理することを含めることが可能である。さらに、期間に従って格付け可能なイベントを区分化し、即時の清算、および／または選択された支払い手段ごとに集計された清算額を提供する。エンジン９２０構成要素および／またはシステム９００構成要素は、実質的にあらゆるオブジェクトモデルフレームワーク（例えば、ＣＯＭ、ＤＣＯＭ、ＣＯＲＢＡ、．ＮＥＴ）で実装できることに留意されたい。
【００６０】
資格付与エンジン９５４は、オンラインサービス加入の購入、キャンセル、および／または転換を行う個人ユーザの適格性を評価する。このエンジン９５４は、例えば、エンドユーザプロファイルの属性、および関連する加入を使用して、所与のオファーに関連する資格付与規則（製品カタログ９３０の中に記憶された）を処理する。提供エンジン９６０は、前述した加入イベントモデルで提供された適切なイベントに応答して共通のサービスプロバイダを介する定義された提供方法のトランザクション処理を調整する。このエンジン９６０により、エンドユーザに対するサービスの正確で適時のデリバリが円滑になる。提供方法は、サービスまたはサービス群の指定されたユーザに対する指定されたサービスのデリバリを行う、または阻止するのに必要とされる状態（例えば、料金請求の不払いに基づいてフラグまたは条件を設定する）を設定する動作を含む。提供エンジン９６０は、提供イベントに応答するのに１つまたは複数のＡＰＩ９６０、９７０を使用するサービスプロバイダ９３４、テナント９３０、または他のエンティティ（図示せず）に対する通信の流れも制御する。
【００６１】
パートナ構成ツール（ＰＣＴ）９７０およびパートナ構成ローダ９７４は、所望される場合、帯域外プロセスを介して製品カタログ９３０と通信することが可能である。通信は、製品カタログデータを構成するため、および／またはロードするための適切なセキュリティ資格証明を有する管理者に従っていなければならない。ＰＣＴ９７０は、他のパラメータに加えて、サービスデリバリ規則、オファー、資格付与規則、および／またはテナントごとの許可を構成するグラフィカルユーザインターフェース（ＧＵＩ）ツールとして実装することができる。パートナ構成ローダ９７４は、多数のシステム環境に１つまたは複数のパートナ構成ファイル（ＰＣＦ）９７８をロードして、共同の開発／試験を容易にし、パートナの試験および開発を介して、多数の製造環境、および製造前の環境にロードする。また、パートナ構成ローダ９７４により、システム９００内のパートナアカウントの生成も容易になり、それぞれのパートナに対する保護されたデータの実質的にセキュアな伝送が提供される。システム９００をハッキングしようとする試みを軽減するため、例えば、帯域外で保護鍵を伝送することができる。ＰＣＦ９７８は、所望される場合、ＸＭＬフォーマットでオファーおよび関連する資格付与の定義、格付けサービスデリバリ規則、および／またはパートナ許可を含む非常駐スキーマファイルであることが可能である。このフォーマットには、ＰＣＴ９７０によって使用される設計時属性、および／またはシステム９００内の様々なエンジン９２０によって使用されるランタイム属性を含めることが可能である。
【００６２】
以上に説明したシステム、構成要素、および／またはプロセス、ならびに以下に説明するシステム、構成要素、および／またはプロセスは、個々の構成要素またはプロセスとして実施すること、および／または様々な組合せで組み合わせることが可能であることを理解されたい。さらに、前述した構成要素および／またはプロセスの１つまたは複数は、所望される場合、単一の構成要素で、または構成要素の組合せですべての構成要素および／またはすべてのプロセスを提供することを含め、様々な他の構成要素および／またはプロセスに従って組み合わせることができる。
【００６３】
図１０は、本発明による通知デリバリ処理のための方法を示している。説明を簡単にするため、方法を一続きの動作として示し、説明するが、本発明は、動作の順序によって限定されないことを理解し、認識されたい。というのは、一部の動作は、本発明に従って、異なる順序で行われることが可能であり、かつ／または本明細書で図示し、説明する他の動作と同時に行われることが可能だからである。例えば、本発明は、代替として、状態図などの一続きの相互関連する状態またはイベントとして表わすことができることが、当業者には理解され、認められよう。さらに、本発明に従って方法を実施するのに例示するすべての動作は必要とされない可能性がある。
【００６４】
図１０は、本発明による通知配信プロセス１０００を示している。１０１０に進むと、通知プラットフォームと対話することができる１つまたは複数のアプリケーションモデルを定義する。前述したとおり、そのようなモデルには、仲介モデル、価格設定モデル、加入アクセスモデル、プッシュ／プルモデル、コンテキストモデル、および／または料金請求モデルを含めることが可能である。１０１４で、アプリケーションモデルと通知プラットフォームのインターフェースがとられている。言い換えれば、アプリケーションモデルの１つまたは複数は、ユーザおよび／またはマシンに対する通知の配信を円滑にするように通知プラットフォームの動作フレームワークに従って使用可能にされている。１０１８で、所望の通知パフォーマンスを記述するユーザプロファイルを定義する。１０２２で、ユーザ能力、デバイス能力、および／またはシステム能力に従ってユーザプロファイルを調整する。これには、アプリケーションモデル、通知プラットフォーム、通知プラットフォームに関連する構成要素、および／またはシステムダイナミクスの１つまたは複数の調整を円滑にするインターフェースおよびコントロールを提供することを含めることが可能である。１０２６で、アプリケーションモデルを使用して通知サービスに対して加入および／または加入取消しを行う。
【００６５】
図１１を参照すると、システム１１００が、本発明の一態様による通知アプリケーションアーキテクチャを示している。通知システム１１００により、アプリケーションに加入したエンティティに対する情報の配信が円滑になる。システム１１００は、高い拡張性を提供し、特定の加入者選好に従って所望の仕方で加入者に情報を配布することを可能にする。加入者は、通知システム１１００に加入したエンティティ（例えば、個人またはアプリケーション）である。本発明による加入は、ある情報（例えば、株式価格、またはスポーツイベントの結果）に対する明示された関心、および配信モード（例えば、電子メール、音声メール、ＰＤＡ、デスクトップコンピュータ、セルラー電話機、テレビジョン等を介する配信）の指定であることが可能である。さらに、本発明は、個人の現在の状態、および現在の状態に応じた関連する配信選好を考慮に入れることも可能にする。したがって、通知システムは、配信されるべき情報のタイプ、情報に関連するクリティカル度（ｃｒｉｔｉｃａｌｉｔｙ）、加入者の現在の状態、および前述した他のパラメータを所与とした配信選好を所与として、配信モードを動的に変更することを可能にする。システム１１００がそのような拡張性の高い通知サービスを提供するのを円滑にする本発明の一態様は、加入をデータとしてモデル化することを使用することである。そのような加入モデル化により、加入者ごとのイベントごとにクエリを個々に実行する必要性が軽減される。したがって、複数の加入者に関して多くのイベントを同時に処理することができ、個々の加入者の選好に従って意味のある仕方でそれぞれの加入者に妥当な通知を提供することができる。
【００６６】
加入者が関心を有する情報が、イベントとして収集される。例えば、特定の時刻の株式価格がイベントであることが可能であり、スポーツのスコア、または製品配達メッセージもそうであり、ほとんどすべての適切な現実世界の「出来事」が、本発明に従って１つまたは複数のイベントとして表現されることが可能である。通知は、加入に関係する情報を含む加入者別のデバイスに配信されるメッセージである。通知は、例えば、特定の株式に関する新しい高値、またはスポーツイベントに関する最終スコアに関するメッセージを含むことが可能である。サーバ通知サービスは、加入およびイベントを収集するためのインターフェースを提供し、そのデータに基づいて通知を生成する。
【００６７】
個々の加入をクエリとして扱う代わりに、通知システム１１００は、個々の加入をパラメータデータとして扱う（例えば、アプリケーション開発者が、それぞれが加入クラスであることが可能な１組のパラメータ化されたクエリを定義することができる）。すなわち、多数の加入の評価が、データベースエンジン（例えば、ＳＱＬサーバ）がよく適しているセット指向のデータ処理問題になる。これが、本発明の通知システム−プログラミングフレームワークの基礎である。このモデルでは、イベントによってトリガされる加入が、単にイベントと潜在的に大きい１組の加入との間でデータベース結合を実行することによって評価される。一般に、加入をデータとしてモデル化することの概念は、通知システム１１００が様々な領域を定義する場合、多くのクエリが共通の構造を有するという想定に基づいている。例えば、多くの加入者が株式価格に興味を有するが、より細かい細分性では、それぞれの加入者が異なる価値の異なる株式に関する情報を所望している。したがって、特定の株式に対する興味を「ＳＴＯＣＫＳＹＭＢＯＬ」および「ＴＲＩＧＧＥＲＰＲＩＣＥ」として表現して、そのような情報に関する共通のフレームワークまたはパラメータを提供するようにすることができる。イベントデータとの関係でこれらのパラメータ値がどのように解釈されるかの意味論は、アプリケーションによって定義されることが可能である。したがって、アプリケーションは、どのように加入パラメータが解釈されるかの論理（例えば、あるアプリケーションは、現在価格＞トリガ価格である場合に警報を行うことを望み、別のアプリケーションは、現在価格＜トリガ価格である場合に警報を行うことを望む可能性がある）を設定する。すなわち、そのような意味論は、アプリケーション開発者によってあらかじめ解決し、加入者が新しい意味論を導入することができないように設計することが可能である。
【００６８】
以下により詳細に説明するとおり、本発明は、加入アプリケーションを構築するためのプログラミングモデルも包含する。加入アプリケーションでは、ユーザが、ある種の目標とされる情報に対する加入または関心の宣言を確立する。その後、情報が利用可能になった際、加入アプリケーションが通知を加入者に送信する。加入アプリケーションの機能は、入来データをユーザ加入のセットとマッチさせて、どのような通知を配信する必要があるかを判定することである。本件のプログラミングモデルにより、アプリケーション開発者が、少量のアプリケーション特有コード（例えば、ＸＭＬ、ＳＱＬ、Ｃ＃、Ｃ＋＋、ＶＢ、および．ＮＥＴフレームワークによるサポートに適した他の言語の混合）を書いて、完全に機能する豊かな加入アプリケーションを構築することができるようになる。そのような機能を可能にするため、例えば、ＳＱＬサーバおよび．ＮＥＴフレームワークの上に、加入アプリケーションに共通の基本的なデータ構成体および実行論理を実施する実行エンジンを構築することが可能である。したがって、本件のプログラミングモデルは、開発時間を短縮し、アプリケーション保守を容易にし、加入−イベントマッチングを行うのに、サーバ、例えば、ＳＱＬサーバの能力を活用することによってアプリケーション効率を向上させる。
【００６９】
本発明は、加入アプリケーションを構築するための宣言型プログラミングモデルを含む。プログラミングモデルは、アプリケーション構造のための基本フレームワークを提供し、開発者は、基本フレームワークを適用して、特定のアプリケーションを構築することができる。
【００７０】
システム１１００の高レベルの概略図に関して、通知サービスの５つの構成要素が協働して前述した機能を提供する。加入管理アプリケーション１１１０により、加入者がシステム１１００に対する入力として加入をサブミットするためのインターフェースが提供される。詳細には、加入管理アプリケーション１１１０は、エンティティがシステム１１００を介して加入サービスを提供するのを容易にする多数のアプリケーションプログラマインターフェース（ＡＰＩ）を提供する。ＡＰＩについては、以下により詳細に説明する。イベントデータも、イベントプロバイダ１１２０を介して外部ソースから収集することが可能である。例えば、本発明によるイベントプロバイダは、複数のリソース（例えば、新聞、雑誌、Ｗｅｂサイト、図書館、個人、雇用主、政府等）から妥当なイベントを収集するか、そのようなイベントをプッシュされる。データベースエンジン１１４０は、イベントおよび／または加入をデータストア１１４２の中に記憶し、Ｔｒａｎｓａｃｔ−ＳＱＬステートメントなどのステートメント、および記憶された手続きを実行することも行う。データベースエンジン１１４０は、情報を持続的に記憶することなく、リアルタイムでイベント対加入を処理することもできることを理解されたい。通知アプリケーションサーバ１１３０は、１組のイベントに基づいて加入を処理し、加入者に配信され、および所望される場合データストア１１４２の中に記憶されることが可能な、通知を最終的に生成する。最後に、配信チャネル１１５０は、Ｅｘｃｈａｎｇｅサーバ、ＳＭＳサーバ、および．ＮＥＴ  Ａｌｅｒｔ  Ｗｅｂサービスを含むことができるが、以上には限定されないものであって、配信サービス１１６０に、生成された通知を送る。
【００７１】
図１２は、本発明の一態様による通知生成−配信システム１２００を示している。システム１２００は、加入管理システム（１つまたは複数の加入管理アプリケーション）１２１０、通知サービス１２２０、サーバデータエンジン１２３０、データベース１２３２、配信サービス１２４０、および通知システム１２００によってホストされる１つまたは複数の加入サービス１２５０を含む。サーバデータエンジン１２３０は、インスタンスおよびアプリケーションデータを処理すること、および記憶することを提供する。詳細には、サーバデータエンジン１２３０は、データベース１２３２からインスタンスおよびアプリケーション情報を記憶し、取得する。また、サーバデータエンジン１２３０は、通知サービス１２２０によって使用される他のサービスも提供する。例えば、通知サービス１２２０は、Ｔｒａｎｓａｃｔ−ＳＱＬ言語を使用して、サーバデータエンジン１２３０を介してイベントと加入データとを結合することができる。そのような統合により、拡張可能なパフォーマンス向上が提供される。というのは、サーバデータエンジン１２３０は、ＳＱＬサービスによって与えられる情報処理機能の結果、結合に関して極めて最適化されている可能性が高いからである。加入管理システム１２１０は、加入者データおよび加入データを収集するとともに、様々な固有の加入サービス１２５０に対応するユーザインターフェースのためのホスト環境を提供する。加入管理システムは、加入者データおよび加入データをサブミットするためにＷｉｎｄｏｗｓ（登録商標）アプリケーションを使用することができ、あるいは、別のシステムから加入者データおよび加入データをロードするために自動化されたプロセスを使用することができる。配信サービス１２４０（例えば、．ＮＥＴ  ＡｌｅｒｔおよびＭｉｃｒｏｓｏｆｔ  Ｅｘｃｈａｎｇｅ  Ｓｅｒｖｅｒ）は、通知サービス１２２０から通知を受信し、その通知を適切な加入者に送信する。
【００７２】
機能上、イベントは、通知サービス１２２０内のホストされたイベントプロバイダを介してサーバデータエンジン１２３０にサブミットされるか、または通知サービス外のホストされないイベントプロバイダを介してサブミットされる。ホストされないイベントプロバイダを使用する場合、Ｗｅｂサーバなどのイベントプロバイダをサポートする別のシステムを使用することができる。さらに、通知サービス１２２０は、単一のサーバ上に配備すること、または多数のサーバにわたって拡張することが可能であることは認められよう。
【００７３】
次に図１３を参照すると、本発明の一態様による通知サービスアーキテクチャ１３００が示されている。アーキテクチャ１３００は、イベントプロバイダ１３０４、中央データベース１３０６、アプリケーション特有データベース１３０８、通知エンジン１３１０、コンテキスト解析器１３１２、通知配信器（ｄｉｓｔｒｉｂｕｔｏｒ）１３１４、および加入者１３１６を含む通知サービスシステム１３０２を含む。通知サービスシステム１３０２は、イベントおよび加入者データの形態で入力を受け取り、出力、つまり通知を加入者１３１６に供給する。
【００７４】
イベントプロバイダ１３０４は、通知サービスシステム１３０２のためにイベントソースからイベントを獲得する。イベントは、外部世界におけるデータ変更を表わす。例えば、特定の時刻の株式価格がイベントであり、スポーツのスコア、または製品配達メッセージもそうである。別の言い方をすると、イベントは、一部のセットのユーザの興味を引く可能性がある項目であり、そのセットのユーザにより、加入を介する特定の入力データが定義される。イベントプロバイダ１３０４を使用して、通知サービス１３０２のためにイベントソースから選択されたイベントが収集される。さらに、イベントプロバイダ１３０４は、インターネット通信やネットワークベースの通信などの通信、電話通信、ならびにソフトウェアサービス、ＸＭＬファイル、アプリケーション、およびデータベースを含むが、以上には限定されない複数の異なるソースからイベントデータを収集することができる。
【００７５】
イベントソースは、本明細書で一般に、イベントを生成するソースとして定義される。そのソースを、通知または警報と呼ぶこともでき、情報、サービス、および／またはシステムイベントまたは世界イベントに関してユーザ、またはユーザのプロキシに警報を出すことを目的とすることもできる。さらに、イベントプロバイダ１３０４が、様々な方法を介してデータを監視し、収集することができる。データを収集する例示的な方法には、ファイル追加のためにディレクトリを監視すること、あるタイプのエントリに関してシステムログファイルおよびアプリケーションログファイルを調べること、アプリケーションからの警報を捕らえること、Ｗｅｂページを監視すること、データベーステーブル内の変化を追跡すること、およびＷｅｂサービスによって提供されるデータを精査することが含まれるが、以上には限定されない。ほとんどの場合、イベントプロバイダは、任意の適切なリソースからデータを収集することができ、ただし、そのリソースからイベントを取得するアプリケーションが準備されているという条件付である。一般に、データを収集するのにイベントプロバイダ１３０４が使用することができる様々な異なるモデルが存在する。これらのモデルは、どれだけ頻繁に、どのような状況下でイベントプロバイダ１３０４がイベントソースからイベントを収集するかに影響を与えることができる。
【００７６】
さらに、イベントプロバイダ１３０４に、２つのやり方の少なくとも１つでデータを通知する、または提供することができる。イベントプロバイダ１３０４は、情報が「プッシュされる」、つまり送られるのを待つこと、あるいはソースのポーリングを行い、新しいデータまたは更新されたデータが存在すればそれを収集することによってソースから情報を「プルする」ことができる。例えば、ユーザが、好みのニュースページ上の見出しの記事が変わるたびに毎回、通知を受けることを所望する場合、例えば、そのページを監視し、見出しのテキストに対する変更を探索するようにイベントプロバイダ１３０４を実装することができる。テキストが変化した場合、イベントプロバイダ１３０４は、通知サービスシステム１３０２のためにその新しい見出しデータを抽出することができる。前述の例では、イベントプロバイダ１３０４が、必要とされるデータを収集することを担う。というのは、データは、プッシュ方法が使用される場合に行われるようにイベントソースからイベントプロバイダに提供されることはないからである。
【００７７】
さらに、イベントプロバイダ１３０４は、スケジュール、または事前定義された基準を満たすイベントの出現に基づいて通知システム１３０２のために新しいデータを獲得することができる。スケジュール設定されたイベントプロバイダが、アプリケーション開発者によって実施された設定に基づいて定期的に実行されることが可能である。スケジュール設定されたイベントプロバイダは、実行を開始し、新しいイベントデータを取得して、サブミットした後、次のスケジュール設定されたトリガ時刻まで休止状態になる。イベント駆動型イベントプロバイダが、常時、実行されてイベントソースを監視することが可能である。その後、収集のための特定の基準を満たすデータが供与された際、イベントプロバイダは、そのイベントを収集してサブミットする。あるいはまた、イベント駆動型イベントプロバイダは、コールバック機能、または何らかの他の外部刺激に応答する際にのみ、実行されることも可能である。すると、その外部機能により、収集されるべき妥当なイベントデータが存在するかどうかが判定され、そのようなデータを収集する手段としてイベントプロバイダが使用される。イベントプロバイダ１３０４は、外部イベントソースからデータを収集すると、イベントテーブルにバッチでデータを書き込み、そのイベントテーブルをデータベース１３０８に保存する。
【００７８】
データは、好ましくは、効率のためにバッチで扱われる。つまり、イベントデータと通知データはともにバッチ処理される。本明細書で一般的に定義するバッチは、グループとして処理される１組のデータであることが可能である。例えば、イベントバッチは、一度に通知サービス１３０２にサブミットされる１組のイベントであることが可能である。イベントは、個々に、またはグループとしてシステムに書き込まれることが可能である。単一のイベントがシステムに書き込まれ、開いているイベントバッチが存在しない場合、開いたイベントバッチが自動的に生成されることが可能である。すると、新しいイベントおよび後続のイベントが、その自動的に生成されたバッチに関連付けられる。それらのイベントを提供するイベントプロバイダは、現在のイベントバッチを定期的に閉じるようにプログラミングされ、閉じることにより、イベントのそのバッチが通知生成の際に使用されるようにサブミットされる。次に、最初の新しいイベントのサブミットとともに新しいイベントバッチが生成され、サイクルが再び開始される。さらに、イベントがグループとしてシステムに書き込まれる場合、各グループにイベントバッチが自動的に割り当てられる。書込みプロセスが完了した際、それらのイベントが通知生成プロセスのために利用可能であるようにイベントバッチが閉じられる。本発明の１つの特定の実施形態では、バッチは、最小単位（ａｔｏｍｉｃ）である（例えば、バッチ全体がサブミットされるか、または何もサブミットされない）。
【００７９】
図１４を参照すると、ＡＤＦ１４００を描いたブロック図、およびＡＤＦ１４００の構成要素が本発明の態様に従って示されている。ＡＤＦ１４００は、アプリケーションの中心論理を定義し、イベント、加入、および通知のためのスキーマすなわちイベントを加入とマッチさせるための規則を含み、生成された通知をフォーマットするのに使用されるファイルの名前を提供することが可能である。ＡＤＦ１４００は、一般に、５つの構成要素、すなわち、イベント定義１４１０、通知定義１４２０、加入論理１４３０、加入スキーマ１４４０、および実行設定１４５０を含む。様々な構成要素の機能を組み合わせてより少ない数の構成要素にすること、または延長して（ｅｘｔｒａｐｏｌａｔｅ）より大きいセットにすることができることが認められよう。
【００８０】
イベント定義１４１０により、イベントデータの構造、データを収集するイベントプロバイダ、およびアプリケーションによって使用されるあらゆるイベントクロニクル（ｃｈｒｏｎｉｃｌｅ）の構造が指定される。通知定義１４２０により、生の通知データの構造、加入者に送信されるメッセージのためのフォーマット、およびメッセージを送信するのに使用される配信プロトコルが指定される。加入論理１４３０により、加入がどのように評価されるかが定義される。例えば、Ｔｒａｎｓａｃｔ−ＳＱＬステートメントが、加入をイベントにマッチさせること、またはある繰返しの回数で加入を評価することが可能である。さらに、加入論理１４３０を明確に規定されたやり方でパラメータ化して、個々の加入により加入論理が個人化されることが可能であるようにすることができる。さらに、加入スキーマ１４４０により、加入パラメータの構造が定義され、評価時刻により、加入がいつ評価されるかが定義される。最後に、実行設定１４５０により、アプリケーション開発者が、通知サービスによって実行される際のアプリケーションの挙動およびパフォーマンスを向上させることが可能になる。
【００８１】
さらに、アプリケーション開発者は、アプリケーション定義ファイル（ＡＤＦ）のいくつかのセクションにおいてアプリケーション設定を定義することができる。その設定により、通知サービスをホストするマシン、通知サービス機能に関する実行スケジュールのような項目が指定される。また、その設定により、ＡＤＦ自体に関するメタデータもドキュメントされる。メタデータには、アプリケーションが入力として受け入れるイベントおよび加入の構造、およびアプリケーションが生成する通知の構造が含まれる。以下に詳細に説明するそのようなメタデータの例には、生成器設定、配信器設定、バキューミング（ｖａｃｕｕｍｉｎｇ）、バージョン設定、通知履歴、アプリケーションデータベース情報、アプリケーション実行設定、および配信器情報が含まれるが、以上には限定されない。
【００８２】
通知サービス構成要素１２２０（図１２）は、イベントを加入にマッチさせ、最終的に通知を生成する通知エンジン１３１０（図１３）内の生成器構成要素（図示せず）を含む。生成器設定の考慮事項（ｃｏｎｓｉｄｅｒａｔｉｏｎ）は、ＡＤＦの中の＜生成器＞ノードにおいて定義することができる。考慮に入れられるべき１つの考慮事項は、イベントバッチを処理するのに生成器がどれだけのスレッドを使用することができるかである。そのようなファクタは、アプリケーション速度を向上させることとシステムリソースを独占することの間のトレードオフと見なすことができる。そのような考慮事項の一部が、より多くのスレッドを追加することによってどれだけの利益を得ることができるかを評価することである。一部の動作は、並列性による効率の向上に適しておらず、ときとして、効率が低下する可能性がある。この情報を示すため、＜Ｇｅｒａｔｏｒ＞ノードにおける＜ＴｈｒｅａｄＰｏｏｌＳｉｚｅ＞要素の中で値を指定することができる。
【００８３】
機能上、通知サービス生成器は、イベントクロニクル規則を並列に実行することを試み、次に、加入規則（イベント規則とスケジュール設定された規則の両方）を実行する。生成器は、規則を実行している間、スレッドプール内で利用可能なスレッドを利用しようと試みる。ただし、生成器は、イベントクロニクル規則を並列に実行すべきでないことに留意されたい。
【００８４】
図１５を参照すると、システム１５１０が、本発明の態様による優先システム１５１２および通知アーキテクチャを示している。優先システム１５１２は、１つまたは複数のメッセージまたは通知１５１４を受け取り、関連するメッセージに関する優先度、または重要度（例えば、メッセージが高い重要性、または低い重要性を有する確率値）を生成し、出力１５１６においてその１つまたは複数のメッセージに関連する優先度値を提供する。以下により詳細に説明するとおり、メッセージ１５１４に優先度を自動的に割り当てる分類器（ｃｌａｓｓｉｆｉｅｒ）を構成し、訓練することができる。例えば、メッセージが重要性の高いカテゴリ、中間のカテゴリ、低いカテゴリ、または他の度合いのカテゴリに属する確率がメッセージに割り当てられるように出力１５１６をフォーマットすることができる。メッセージが、所定の重要度カテゴリに従って、例えば、電子メールプログラム（図示せず）の受信ボックス内で自動的にソートされることが可能である。ソートには、定義された重要度ラベルを有するシステムフォルダにファイルを向かわせることも含めることが可能である。これには、特定の重要度の決められたメッセージが関連するフォルダにソートされるように、低い、中間、および高いなどの重要度のラベルをフォルダに付けることを含めることが可能である。同様に、所望の優先度を有するメッセージが受信されたことをユーザに警報するように１つまたは複数の音声サウンドまたは視覚表示（例えば、アイコン、記号）を適合させることができる（例えば、高い優先度のメッセージの場合、３つのビープ音、中間の場合、２つのビープ音、低い場合、１つのビープ音、高い優先度の場合、赤の警報記号または点滅する警報記号、中間の優先度のメッセージが受信されたことを示す緑の点滅しない警報記号）。
【００８５】
本発明の別の態様によれば、通知プラットフォーム１５１７を優先システム１５１２と併せて使用して、ユーザがアクセス可能な１つまたは複数の通知シンクに優先されるメッセージを向かわせることができる。以下により詳細に説明するとおり、通知プラットフォーム１５１７は、例えば、優先されるメッセージ１５１６を受信し、いつ、どこで、どのようにユーザに通知を行うかに関する決定を行うように適合させることができる。例として、通知プラットフォーム１５１７は、通信様式（例えば、セル電話機、またはパーソナルデジタルアシスタント（ＰＤＡ）などのユーザの現在の通知シンク１５１８）、ならびにユーザの見込まれる位置、および／または見込まれる注意の対象を判定することができる。例えば、高い重要度の電子メールが受信された場合、通知プラットフォーム１５１７は、ユーザの位置／注意対象を判定し、ユーザに関連する通知シンク１５１８にメッセージを向かわせ／フォーマットしなおすことができる。例えば、低い方の優先度のメッセージ１５１６が受信された場合、通知プラットフォーム１５１７を、所望に応じて後に閲覧するためにユーザの受信ボックスの中にその電子メールを置いておくように構成することが可能である。以下により詳細に説明するとおり、他の経路指定システムおよび／または警報システム１５１９を利用して、優先されるメッセージ１５１６をユーザおよび／または他のシステムに向かわせることも可能である。
【００８６】
次に図１６を参照すると、システム１６００が、本発明の態様に従ってどのように通知エンジンとコンテキスト解析器が一緒に機能するかを示している。システム１６００は、通知ソースとして動作することが可能な、コンテキスト解析器１６２２、通知エンジン１６２４、１つまたは複数の通知ソース１ないしＮ、１６２６、１６２７、１６２８、優先システム１６３０、ならびに１つまたは複数の通知シンク１ないしＭ、１６３６、１６３７、１６３８を含み、ＮおよびＭはそれぞれ整数である。ソースは、イベント発行元（ｐｕｂｌｉｓｈｅｒ）とも呼ばれ、シンクは、イベント加入者とも呼ばれる。任意の数のシンクおよびソースが存在することが可能である。一般に、通知エンジン１６２４は、コンテキスト解析器１６２２の中に記憶され、かつ／または解析器１６２２によってアクセスされるパラメータ情報にある程度、基づいてソース１６２６〜１６２８からシンク１６３６〜１６３８に、イベントまたは警報とも呼ばれる通知を伝送する。
【００８７】
コンテキスト解析器１６２２は、通知決定に影響を与えるユーザの変数およびパラメータに関する情報を記憶／解析する。例えば、パラメータには、ユーザの通常の位置および注意の対象、または時刻による活動、および曜日による活動などのコンテキスト情報、ならびに異なる場所においてユーザがアクセスを有する傾向にあるデバイスなどのパラメータを条件とする追加のパラメータを含めることが可能である。そのようなパラメータは、１つまたは複数のセンサを介して自律的に行われる観察に応じることも可能である。例えば、ＧＰＳ（ｇｌｏｂａｌ  ｐｏｓｉｔｉｏｎｉｎｇ  ｓｙｓｔｅｍ）サブシステムが提供することができるユーザの位置に関する情報、使用されているデバイスのタイプ、および／またはデバイスの使用パターン、および特定のタイプのデバイスにユーザが最後にアクセスしたのはいつかに関する情報に基づき、１つまたは複数のプロファイル（図示せず）を選択し、変更することが可能である。さらに、以下により詳細に説明するとおり、自動化された推定を使用して、位置および注意などのパラメータまたは状態を動的に推定することもできる。プロファイルパラメータを、ユーザが編集することができるユーザプロファイルとして記憶することが可能である。事前定義されたプロファイルまたは動的推定のセットに依拠することを超えて、通知アーキテクチャは、例えば、ユーザが、次の「ｘ」時間にわたり、または所与の時刻まで、重要な通知以外は利用できないといったような自らの状態をリアルタイムで指定することを可能にする。
【００８８】
また、パラメータには、異なる状況において異なるタイプの通知に気をとられる（ｄｉｓｔｒｕｂｅｄ）ことに関するユーザの選好に関するデフォルトの通知選好パラメータも含まれることが可能であり、このパラメータを、通知エンジン１６２４が通知決定を行う基準として使用することが可能であり、ユーザが変更を行う開始点とすることができる。パラメータには、ユーザが異なる状況においてどのように通知を受けることを所望するかについてのデフォルトのパラメータを含めることが可能である（例えば、セル電話機による、ページャによるなどの）。パラメータは、異なる状況において異なる様式で通知を受けることに関連する割込み（ｄｉｓｒｕｐｔｉｏｎ）の費用などの評価を含むことが可能である。これには、ユーザが異なる場所にいる尤度、異なるデバイスが利用可能である尤度、および所与の時点におけるユーザの注意ステータスの尤度を示すコンテキスト上のパラメータ、ならびに所与の時点でユーザがどのように通知を受けることを所望するかを示す通知パラメータが含まれることが可能である。
【００８９】
コンテキスト解析器１６２２によって記憶される情報は、本発明の一態様によれば、解析器によって特定されたコンテキスト情報を含む。コンテキスト情報は、説明の以下のセクションでより詳細に説明するとおり、１つまたは複数のコンテキスト情報ソース（図示せず）に基づいてユーザの場所および注意ステータスを見分けることによって解析器１６２２によって特定される。コンテキスト解析器１６２２は、例えば、ユーザの自動車またはセル電話機の一部分であるＧＰＳを介してユーザの現在位置を正確に特定できることが可能である。また、解析器は、統計モデルを使用して、背景評価、および／または日のタイプ、時刻、ユーザのカレンダ内のデータなどの情報を考慮することを介して収集された観察、およびユーザの活動に関する観察を考慮することによってユーザが所与の注意状態にある尤度を特定することもできる。所与の注意状態には、ユーザが通知を受け取る余裕があるか、忙しく、通知を受け取る余裕がないかを含めることが可能であり、平日、週末、休日、および／または他の時機／期間などの他の考慮も含めることが可能である。
【００９０】
ソース１６２６〜１６２８、符号１６３０は、ユーザおよび／または他のエンティティを宛先とする通知を生成する。例えば、ソース１６２６〜１６２８には、インターネットおよびネットワークベースの通信、電話通信などの通信、ならびにソフトウェアサービスを含めることが可能である。通知ソースは、本明細書では一般に、情報、サービス、および／またはシステムイベントまたは世界イベントに関して、ユーザ、またはユーザのプロキシに警報することを目的とする、通知や警報とも呼ぶことができるイベントを生成するソースとして定義される。通知ソースは、イベントソースと呼ぶこともできる。
【００９１】
例えば、電子メールは、優先されるように優先システム１６３０によって通知として生成されることが可能であり、通知を生成するアプリケーションプログラムまたはシステムが、ユーザにとっての電子メールの見込まれる重要性または緊急性に対応する相対優先度を電子メールに割り当てる。また、電子メールを、ユーザにとっての相対重要度に関わりなく送信することも可能である。インターネット関連サービスには、例えば、時折の最新ニュースの見出しや株価などの、ユーザが加入した情報を含む通知を含めることが可能である。
【００９２】
通知ソース１６２６〜１６２８自体、プッシュタイプのソースまたはプルタイプのソースであることが可能である。プッシュタイプのソースは、加入が行われた後に情報を自動的に送信する見出しニュースや他のインターネット関連サービスなどの、対応する要求なしに情報を自動的に生成し、送信するソースである。プルタイプのソースは、メールサーバにポーリングが行われた後に電子メールが受信されるなどの、要求に応答して情報を送信するソースである。さらに他の通知ソースには、以下が含まれる。すなわち、
・カレンダシステムなどの電子メールデスクトップアプリケーション
・（例えば、システム活動またはシステム問題に関する警報に関する情報のメッセージでユーザに警報することが可能な）コンピュータシステム
・インターネット関連サービス、アポイントメント情報、スケジュール設定クエリ
・１つまたは複数の共用フォルダ内のドキュメントの変更、またはある種のドキュメントの数の変更
・情報に関する存続しているクエリ、または持続しているクエリに応答する新しいドキュメントが利用できること、および／または
・人々およびその人々がいること、人々の位置の変化、人々の近さ（例えば、移動中、別の同僚または友人が自分から１０マイル（１６．０６ｋｍ）以内にいる場合には知らせてもらいたい）、または人々が応対できるか（ａｖａｉｌａｂｉｌｉｔｙ）（例えば、スティーブが会話に応対でき、フルビデオ遠隔会議をサポートすることができる高速リンクの近くにいる場合、知らせてもらいたい）についての情報ソース。
【００９３】
通知シンク１６３６〜１６３８は、通知をユーザに提供することができる。例えば、そのような通知シンク１６３６〜１６３８には、理解されるとおり、デスクトップコンピュータおよび／またはラップトップコンピュータ、ハンドヘルドコンピュータなどのコンピュータ、セル電話機、陸線電話機、ページャ、自動車ベースのコンピュータ、ならびに他のシステム／アプリケーションを含めることが可能である。シンク１６３６〜１６３８のいくつかは、他のシンクよりも豊富に通知を伝えることができることに留意されたい。例えば、デスクトップコンピュータには、通常、スピーカ、および比較的大きいカラーディスプレイが結合されているとともに、ローカルネットワークまたはインターネットに結合される場合、情報を受信するためのより高い帯域幅も有する。したがって、通知を、デスクトップコンピュータによってユーザに比較的豊かな仕方で伝えることが可能である。反対に、例えば、多くのセル電話機は、白黒であることが可能なより小さいディスプレイを有し、比較的低い帯域幅で情報を受信する。これに相応して、例えば、セル電話機によって伝えられる通知に関連する情報は、一般に、より短く、電話機のインターフェース機能に適合されていることが可能である。したがって、通知の内容は、セル電話機に送信されるか、またはデスクトップコンピュータに送信されるかに応じて異なる可能性がある。本発明の一態様によれば、通知シンクは、イベント加入サービスを介して、例えば、イベントまたは通知に加入するシンクを指すことが可能である。
【００９４】
通知エンジン１６２４は、コンテキスト解析器によって記憶され、かつ／または特定された情報にアクセスし、ソース１６２６〜１６２８から受信された通知のいずれをシンク１６３６〜１６３８のいずれに伝送するかを決める。さらに、通知エンジン１６２４は、シンク１６３６〜１６３８のいずれが情報の送信先として選択されたかに応じて、どのように通知を伝送するべきかを決めることができる。例えば、通知が要約されてから、選択されたシンク１６３６〜１６３８に提供されるべきことを決めることが可能である。
【００９５】
本発明は、通知のいずれを通知シンクのいずれに伝送するか、その通知がどのような仕方で伝送されるかに関する決定をエンジン１６２４がどのように行うかに限定されない。一態様によれば、決定理論的解析を利用することができる。例えば、ユーザの位置、注意、デバイスの可用性、および警報が行われない場合にユーザが情報にアクセスするまでの時間を含む変数に関する重要な不確実度を推定するように通知エンジン１６２４を適合させることができる。通知エンジン１６２４は、ユーザを通知に気付かせるかどうかに関する通知決定を行い、気付かせる場合、要約の性質、および通知を中継するために使用する適切なデバイスまたはデバイス群に関する決定を行うことができる。一般に、通知エンジン１６２４は、通知の純期待値（ｎｅｔ  ｅｘｐｅｃｔｅｄ  ｖａｌｕｅ）を決定する。これを行う際、通知エンジン１６２４は、以下を考慮することができる。すなわち、
・それぞれ可用な通知シンクの忠実度および伝送の信頼性
・ユーザに割込みを行うことの注目の費用
・ユーザにとっての情報の斬新さ
・ユーザが情報を自ら閲覧するまでの時間
・情報の場合によりコンテキストの影響を受けやすい（ｃｏｎｔｅｘｔ−ｓｅｎｓｉｔｉｖｅ）値
・通知に含まれる情報の時間の経過とともに増大する値および／または低下する値
【００９６】
したがって、不確実度に関して行われる推定は、例えば、ユーザの何らかの注目状態を所与として、特定のデバイスの特定の様式を使用してユーザに割込みを行う費用などの値の予期される尤度として生成することができる。通知エンジン１６２４は、以下の１つまたは複数に関して決定を行うことができる。すなわち、
・（例えば、コンテキスト情報に基づき）ユーザが、現在、何に注意を払い、行っているか
・ユーザが、現在、どこにいるか
・その情報がどれだけ重要であるか
・通知を延期する費用はどのぐらいであるか
・通知はどれだけ気を散らすことになるか
・ユーザに伝わる尤度はどのぐらいであるか
・所与の通知シンクの特定の様式の使用に関連する忠実度の損失はどれぐらいであるか
したがって、通知エンジン１６２４は、待ち状態の通知およびアクティブな通知の決定理論的解析などの解析を行うことができ、情報シンクおよび情報ソースによって提供されるコンテキスト依存変数を評価し、ユーザが情報を閲覧すると見込まれるまでの時間、ユーザの位置および現在の注意状態などの選択された不確実度を推定する。
【００９７】
さらに、通知エンジン１６２４は、個人化された決定理論的解析の代わりに、またはそれをサポートするためにコンテキスト解析器１６２２によってユーザプロファイルの中に記憶された情報にアクセスすることができる。例えば、ユーザプロファイルは、所与の時点で、ユーザがページャを介し、通知が所定の重要度レベルを有する場合にだけ通知を受けることを選好することを示すことが可能である。そのような情報は、決定理論的解析を開始するベースラインとして利用されることができ、あるいは通知エンジン１６２４がどのようにユーザに通知を行うか、通知を行うかどうかを決めるやり方であることが可能である。
【００９８】
本発明の一態様によれば、通知プラットフォームアーキテクチャ１６００は、イベント送信（ｅｖｅｎｔｉｎｇ）インフラストラクチャまたはメッセージ送信（ｍｅｓｓａｇｉｎｇ）インフラストラクチャの上に存在する層として構成することができる。ただし、本発明は、いずれの特定のイベント送信インフラストラクチャにも限定されない。そのようなイベント送信およびメッセージ送信のシステムおよびプロトコルには、以下が含まれることが可能である。すなわち、
・当技術分野で知られるハイパーテキスト転送プロトコル（ＨＴＴＰ）またはＨＴＴＰ拡張
・当技術分野で知られるシンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）
・当技術分野で知られるウインドウズマネージメントインスツルメンテーション（Ｗｉｎｄｏｗｓ（登録商標）  Ｍａｎａｇｅｍｅｎｔ  Ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ）（ＷＭＩ）
・当技術分野で知られるＪｉｎｉ
・例えば、パケット交換プロトコルに基づくプロトコルなどの実質的にあらゆるタイプの通信プロトコル
【００９９】
さらに、それらアーキテクチャは、当業者が理解することができるとおり、柔軟性のある分散コンピュータインフラストラクチャ上に存在する層として構成することもできる。したがって、通知プラットフォームアーキテクチャは、例えば、ソースが通知、警報、およびイベントを送信するやり方として、またシンクが通知、警報、およびイベントを受信するやり方として基礎にあるインフラストラクチャを利用することができる。ただし、本発明は、そのように限定されない。
【０１００】
図１７を参照すると、本発明の様々な態様を実施するための例示的な環境１７１０が、コンピュータ１７１２を含んでいる。コンピュータ１７１２は、処理ユニット１７１４、システムメモリ１７１６、およびシステムバス１７１８を含む。システムバス１７１８は、システムメモリ１７１６から処理ユニット１７１４までを含むが、これらには限定されないシステム構成要素を結合する。処理ユニット１７１４は、様々な可用なプロセッサのいずれであることも可能である。また、デュアルマイクロプロセッサおよび他のマイクロプロセッサアーキテクチャも、処理ユニット１７１４として使用することができる。
【０１０１】
システムバス１７１８は、１１ビットバス、インダストリスタンダードアーキテクチャ（Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）（ＩＳＡ）、マイクロチャネルアーキテクチャ（Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ）（ＭＣＡ）、エクステンデッドＩＳＡ（Ｅｘｔｅｎｄｅｄ  ＩＳＡ）（ＥＩＳＡ）、インテリジェントドライブエレクトロニクス（Ｉｎｔｅｌｌｉｇｅｎｔ  Ｄｒｉｖｅ  Ｅｌｅｃｔｒｏｎｉｃｓ）（ＩＤＥ）、ＶＥＳＡローカルバス（ＶＬＢ）、ペリフェラルコンポーネントインターコネクツ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔｓ）（ＰＣＩ）、ユニバーサルシリアルバス（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）（ＵＳＢ）、アドバンストグラフィックスポート（Ａｄｖａｎｃｅｄ  Ｇｒａｐｈｉｃｓ  Ｐｏｒｔ）（ＡＧＰ）、パーソナルコンピュータメモリカードインターナショナルアソシエーション（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ  Ｍｅｍｏｒｙ  Ｃａｒｄ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ａｓｓｏｃｉａｔｉｏｎ）バス（ＰＣＭＣＩＡ）、およびスモールコンピュータシステムズインターフェース（Ｓｍａｌｌ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍｓ  Ｉｎｔｅｒｆａｃｅ）（ＳＣＳＩ）を含むが、以上には限定されない任意の様々な可用なバスアーキテクチャを使用するメモリバスまたはメモリコントローラ、周辺バスまたは外部バス、および／またはローカルバスを含むいくつかのタイプのバス構造のいずれであることも可能である。
【０１０２】
システムメモリ１７１６は、揮発性メモリ１７２０および不揮発性メモリ１７２２を含む。始動中などにコンピュータ１７１２内部の要素間で情報を転送する基本ルーチンを含むＢＩＯＳ（ｂａｓｉｃ  ｉｎｐｕｔ／ｏｕｔｐｕｔ  ｓｙｓｔｅｍ）が、不揮発性メモリ１７２２の中に記憶される。例として、限定としてではなく、不揮発性メモリ１７２２には、読取り専用メモリ（ＲＯＭ）、プログラマブルＲＯＭ（ＰＲＯＭ）、電気的にプログラミング可能なＲＯＭ（ＥＰＲＯＭ）、電気的に消去可能なＲＯＭ（ＥＥＰＲＯＭ）、またはフラッシュメモリが含まれることが可能である。揮発性メモリ１７２０には、外部キャッシュメモリとして動作するランダムアクセスメモリ（ＲＡＭ）が含まれる。例として、限定としてではなく、ＲＡＭは、シンクロナス（ｓｙｎｃｈｒｏｎｏｕｓ）ＲＡＭ（ＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、ダブルデータレートＳＤＲＡＭ（ＤＤＲ  ＳＤＲＡＭ）、エンハンスト（ｅｎｈａｎｃｅｄ）ＳＤＲＡＭ（ＥＳＤＲＡＭ）、シンクリンク（Ｓｙｎｃｈｌｉｎｋ）ＤＲＡＭ（ＳＬＤＲＡＭ）、およびダイレクトラムバス（ｄｉｒｅｃｔ  Ｒａｍｂｕｓ）ＲＡＭ（ＤＲＲＡＭ）などの多くの形態で入手可能である。
【０１０３】
コンピュータ１７１２は、取外し可能な／取外し不可能な、揮発性／不揮発性のコンピュータ記憶媒体も含む。図１７は、例えば、ディスクストレージ１７２４を示している。ディスクストレージ１７２４には、磁気ディスクドライブ、フロッピー（登録商標）ディスクドライブ、テープドライブ、Ｊａｚドライブ、Ｚｉｐドライブ、ＬＳ−１００ドライブ、フラッシュメモリカード、またはメモリスティックのようなデバイスが含まれるが、以上には限定されない。さらに、ディスクストレージ１７２４には、コンパクトディスクＲＯＭデバイス（ＣＤ−ＲＯＭ）、ＣＤレコーダブル（ｒｅｃｏｒｄａｂｌｅ）ドライブ（ＣＤ−Ｒドライブ）、ＣＤリライタブル（ｒｅｗｒｉｔａｂｌｅ）ドライブ（ＣＤ−ＲＷドライブ）、またはデジタル多目的ディスクＲＯＭドライブ（ＤＶＤ−ＲＯＭ）などの光ディスクドライブを含むが、以上には限定されない、他の記憶媒体とは独立の、または他の記憶媒体と組合せの記憶媒体も含まれることが可能である。システムバス１７１８に対するディスク記憶デバイス１７２４の接続を容易にするため、インターフェース１７２６のような取外し可能なインターフェース、または取外し不可能なインターフェースが、通常、使用される。
【０１０４】
図１７は、ユーザと適切な動作環境１７１０に図示した基本コンピュータリソースとの間の仲介として動作するソフトウェアを説明していることが認められよう。そのようなソフトウェアには、オペレーティングシステム１７２８が含まれる。ディスクストレージ１７２４上に記憶されることが可能なオペレーティングシステム１７２８は、コンピュータシステム１７１２のリソースを制御し、割り振るように動作する。システムアプリケーション１７３０は、システムメモリ１７１６の中、またはディスクストレージ１７２４上に記憶されたプログラムモジュール１７３２およびプログラムデータ１７３４を介してオペレーティングシステム１７２８によるリソースの管理を活用する。本発明は、様々なオペレーティングシステム、またはオペレーティングシステムの組合せを使用して実施できることが認められよう。
【０１０５】
ユーザは、入力デバイス１７３６を介してコマンドまたは情報をコンピュータ１７１２に入力する。入力デバイス１７３６には、マウス、トラックボール、スタイラス、タッチパッドなどのポインティングデバイス、キーボード、マイクロホン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナ、ＴＶチューナカード、デジタルカメラ、デジタルビデオカメラ、Ｗｅｂカメラ等が含まれるが、以上には限定されない。以上の入力デバイス、およびその他の入力デバイスは、インターフェースポート１７３８を介してシステムバス１７１８を通じて処理ユニット１７１４に接続される。インターフェースポート１７３８には、例えば、シリアルポート、パラレルポート、ゲームポート、およびユニバーサルシリアルバス（ＵＳＢ）が含まれる。出力デバイス１７４０は、入力デバイス１７３６と同じタイプのポートのいくつかを使用する。したがって、例えば、ＵＳＢポートを使用して入力をコンピュータ１７１２に提供することができ、コンピュータ１７１２から出力デバイス１７４０に情報を出力することができる。他にも出力デバイス１７４０が存在するが、特別なアダプタを必要とするモニタ、スピーカ、およびプリンタのようないくつかの出力デバイス１７４０が存在することをとりわけ示すために、出力アダプタ１７４２を提示している。出力アダプタ１７４２には、例として、限定としてではなく、出力デバイス１７４０とシステムバス１７１８との間で接続の手段を提供するビデオカードおよびサウンドカードが含まれる。遠隔コンピュータ１７４４のような他のデバイスおよび／またはデバイスのシステムは、入力機能と出力機能をともに提供することに留意されたい。
【０１０６】
コンピュータ１７１２は、遠隔コンピュータ１７４４のような１つまたは複数の遠隔コンピュータに対する論理接続を使用するネットワーク化された環境において動作することができる。遠隔コンピュータ１７４４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ワークステーション、マイクロプロセッサベースの機器、ピアデバイス、または他の一般的なネットワークノード等であることが可能であり、通常、コンピュータ１７１２に関連して説明した要素の多く、またはすべてを含む。簡明にするため、メモリストレージデバイス１７４６だけを遠隔コンピュータ１７４４とともに示している。遠隔コンピュータ１７４４は、ネットワークインターフェース１７４８を介してコンピュータ１７１２に論理接続され、通信接続１７５０を介して物理接続される。ネットワークインターフェース１７４８は、ローカルエリアネットワーク（ＬＡＮ）やワイドエリアネットワーク（ＷＡＮ）などの通信網を包含する。ＬＡＮ技術には、ファイバ分散データインターフェース（Ｆｉｂｅｒ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｄａｔａ  Ｉｎｔｅｒｆａｃｅ）（ＦＤＤＩ）、銅線分散データインターフェース（Ｃｏｐｐｅｒ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｄａｔａ  Ｉｎｔｅｒｆａｃｅ）（ＣＤＤＩ）、イーサネット（登録商標）／ＩＥＥＥ  １１０２．３、トークンリング／ＩＥＥＥ  １１０２．５等が含まれる。ＷＡＮ技術には、ポイントツーポイントリンク、デジタル総合サービス網（ＩＳＤＮ）やその変種のような回線交換網、パケット交換網、デジタル加入者線（ＤＳＬ）が含まれるが、以上には限定されない。
【０１０７】
通信接続１７５０とは、ネットワークインターフェース１７４８をバス１７１８に接続するのに使用されるハードウェア／ソフトウェアを指す。図面を明瞭にするためにコンピュータ１７１２内部に通信接続１７５０を示しているが、通信接続は、コンピュータ１７１２外部にあることも可能である。ネットワークインターフェース１７４８に接続するために必要なハードウェア／ソフトウェアには、単に例として、通常の電話等級の（ｔｅｌｅｐｈｏｎｅ  ｇｒａｄｅ）モデム、ケーブルモデルおよびＤＳＬモデム、ＩＳＤＮアダプタ、ならびにイーサネット（登録商標）カードを含むモデムなどの内部技術および外部技術が含まれる。
【０１０８】
図１８は、本発明が相互作用することが可能なサンプルのコンピューティング環境１８００の概略ブロック図である。システム１８００は、１つまたは複数のクライアント１８１０を含む。クライアント１８１０は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）であることが可能である。システム１８００は、１つまたは複数のサーバ１８３０も含む。サーバ１８３０は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）であることも可能である。サーバ１８３０は、例えば、本発明を使用することによって変換を行うスレッドを収容することができる。クライアント１８１０とサーバ１８３０との間の１つの可能な通信は、２つまたはそれより多くのコンピュータプロセスの間で伝送されるデータパケットの形態であることが可能である。システム１８００は、クライアント１８１０とサーバ１８３０との間の通信を円滑にするのに使用することができる通信フレームワーク１８５０を含む。クライアント１８１０は、クライアント１８１０にローカルな情報を記憶するのに使用することができる１つまたは複数のクライアントデータストア１８６０に動作上、接続される。同様に、サーバ１８３０は、サーバ１８３０にローカルな情報を記憶するのに使用することができる１つまたは複数のサーバデータストア１８４０に動作上、接続される。
【０１０９】
以上に説明したことは、本発明の例を含む。もちろん、本発明を説明する目的で構成要素または方法の考えられるすべての組合せを説明することは不可能であるが、本発明の多くのさらなる組合せおよび置換が可能であることを当業者は認識できよう。したがって、本発明は、添付の特許請求の範囲の精神とその範囲とに含まれるすべてのそのような改変形態、変更形態、および変形形態を包含するものとする。さらに、「含む（ｉｎｃｌｕｄｅ）」が詳細な説明、あるいは特許請求の範囲で使用される限りにおいて、この用語は、「含む（ｃｏｍｐｒｉｓｉｎｇ）」が、請求項において他動詞的な語（ｔｒａｎｓｉｔｉｏｎａｌ  ｗｏｒｄ）として使用される場合に解釈される「ｃｏｍｐｒｉｓｉｎｇ」という用語と同様に包含的（ｉｎｃｌｕｓｉｖｅ）であるものとする。
【図面の簡単な説明】
【０１１０】
【図１】本発明の一態様による通知配信システムおよびアプリケーションモデルを示す概略ブロック図である。
【図２】本発明の一態様による仲介システムを例示する概略ブロック図である。
【図３】本発明の一態様による動的価格設定システムを例示する図である。
【図４】本発明の一態様による加入制御システムを例示する図である。
【図５】本発明の一態様によるプッシュ／プルシステムを例示する図である。
【図６】本発明の一態様による加入構成要素およびコンテキスト構成要素を例示する図である。
【図７】本発明の一態様によるデバイス構成を例示する図である。
【図８】本発明の一態様による料金請求−提供処理アーキテクチャを例示する図である。
【図９】本発明によるイベント処理アーキテクチャを例示する図である。
【図１０】本発明の一態様による通知配信プロセスを例示するフロー図である。
【図１１】本発明の一態様による通知アプリケーションアーキテクチャを示す概略ブロック図である。
【図１２】本発明の一態様による通知生成−配信システムを示す概略ブロック図である。
【図１３】本発明の一態様による通知サービスアーキテクチャを例示する概略ブロック図である。
【図１４】本発明の一態様によるＡＤＦおよびその構成要素を描いたブロック図である。
【図１５】本発明の一態様による優先システムを示す概略ブロック図である。
【図１６】本発明の一態様による通知エンジンとコンテキスト解析器との間の体系的な協調を示す概略ブロック図である。
【図１７】本発明の一態様による適切な動作環境を例示する概略ブロック図である。
【図１８】本発明が相互作用することが可能なサンプルのコンピューティング環境を示す概略ブロック図である。
【符号の説明】
【０１１１】
１００  通知配信システム
１１０  通知プラットフォーム
１１４  イベントソース
１２０  シンク
１２４  加入
１３０、１４０、１４４、１５０、１５４、１６０、１６４、１７０  アプリケーションモデル
１３４  ユーザプロファイルおよびユーザパラメータ
【図１】
2004259261.tif 000003
【図２】
2004259261.tif 000004
【図３】
2004259261.tif 000005
【図４】
2004259261.tif 000006
【図５】
2004259261.tif 000007
【図６】
2004259261.tif 000008
【図７】
2004259261.tif 000009
【図８】
2004259261.tif 000010
【図９】
2004259261.tif 000011
【図１０】
2004259261.tif 000012
【図１１】
2004259261.tif 000013
【図１２】
2004259261.tif 000014
【図１３】
2004259261.tif 000015
【図１４】
2004259261.tif 000016
【図１５】
2004259261.tif 000017
【図１６】
2004259261.tif 000018
【図１７】
2004259261.tif 000019
【図１８】
2004259261.tif 000020