通知プラットフォームアーキテクチャ
【課題】１つまたは複数の通知ソースに関連する様々な情報を、通知プラットフォームアーキテクチャを介して１つまたは複数の通知シンクに向けることを可能にするシステムおよび方法を提供する。
【解決手段】アーキテクチャ１０には、位置および注意のフォーカスなどのユーザの状態を判定するコンテキストアナライザ２２が含まれ、ユーザの状態は、例えば通知ソース２６〜２８によって生成された情報のどれを、いつ、どのように通知シンク３６〜３８に転送しなければならないかに関する決定を行うために通知マネージャ２４によって使用される。この決定には、ユーザに通知することの利益よりユーザを中断することのコストが大きいかどうかに関する考慮が与えられる、費用便益分析を含めることができる。決定理論的ポリシおよび／または多少フォーマルでないヒューリスティックポリシを使用して、通知マネージャ内の意思決定処理を可能にすることができる。
【解決手段】アーキテクチャ１０には、位置および注意のフォーカスなどのユーザの状態を判定するコンテキストアナライザ２２が含まれ、ユーザの状態は、例えば通知ソース２６〜２８によって生成された情報のどれを、いつ、どのように通知シンク３６〜３８に転送しなければならないかに関する決定を行うために通知マネージャ２４によって使用される。この決定には、ユーザに通知することの利益よりユーザを中断することのコストが大きいかどうかに関する考慮が与えられる、費用便益分析を含めることができる。決定理論的ポリシおよび／または多少フォーマルでないヒューリスティックポリシを使用して、通知マネージャ内の意思決定処理を可能にすることができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、全般的にはコンピュータシステムに関し、具体的には、ユーザへの伝達のために様々なデバイスおよびアプリケーションによって生成されるアラートの受取および通知を容易にするアーキテクチャを提供するシステムおよび方法に関する。
【背景技術】
【０００２】
多くのコンピュータユーザが、現在、多数の異なるソースから情報を受け取り、この情報にアクセスするために多数の異なるデバイスまたはモーダリティ（ｍｏｄａｌｉｔｙ）を使用する。例えば、ユーザは、コンピュータを介して電子メールまたはインスタントメッセージを、ポケットベルを介して呼び出しを、携帯（「セル」）電話または陸線電話などの電話を介して音声メールを、コンピュータを介してニュース情報を受け取ることができる。入手可能な情報の量がますます増え、そのような情報を通信するモーダリティが多数あるので、ユーザが居合わせた場所、ユーザがどのような気分または状態にあるか、およびユーザがアクセスできる通信モーダリティに従って、ユーザが情報を受け取り、処理することが困難になる。
【０００３】
一例として、ユーザが、自分のコンピュータから離れているが、重要な電子メールを受信する場合がある。しかし、多くの場合に、ユーザは、携帯電話またはポケットベルへのアクセスだけを有する。したがって、あるモーダリティ（例えば電子メール）を介して送信されたメッセージは、別のモーダリティに自動的に転送も通信もされない。その結果、ユーザが実際にメッセージを受け取る前に、重要な時間が経過する可能性がある。いくつかの場合に、メッセージ自体が所与の時間枠以内のユーザによる応答またはアクションを必要とするので、メッセージは、実際に受け取られる前に有用でなくなる可能性がある。もう１つの例として、ユーザが、コンピュータを使っているが、コンピュータに集中している間に気が散らないようにするために、電話機の呼出音発生機能および音声メールインジケータをオフにしている場合がある。しかし、重要な音声メールがこの時間中に放置された場合に、ユーザは、一般に、定期的に音声メールをチェックしていなければ、重要なメッセージを受信したかどうかを知る方法がない。
【０００４】
重要なメッセージまたはアラートに潜在的に応答しないこととは対照的に、受け取られる多くのメッセージ／アラートが、ユーザにとって重要でない可能性がある。例えば、ユーザの管理者または協働者からの電子メールは、一般に、最新のスポーツ点数スコアの受信またはレビューより高い優先順位で受信されなければならない。したがって、メッセージまたはアラートに含まれる情報の価値と、ユーザに対する中断に関連するコストとのバランスをとらなければならない。しかし、コストおよび価値は、コンテキスト依存（ｃｏｎｔｅｘｔ ｓｅｎｓｉｔｉｖｅ）である可能性がある。これには、ユーザが居合わせた場所、ユーザが現在かかわっているアクティビティ、ユーザがアクセスできる通信モーダリティを含めることができる。上で説明した通信および関連するモーダリティの管理の他に、ユーザは、様々な他のメッセージおよび／またはアラートも受け取り、後に処理する。これには、例えば、増加する多数のサービスからのアラート、エラーメッセージ、およびコンピュータ化されたアシスタンスの提示を含めることができる。
【発明の概要】
【０００５】
以下では、本発明のいくつかの態様の基本的な理解を提供するために、本発明の単純化された要約を提示する。この要約は、本発明の広範囲の概要ではない。本発明の鍵となる要素またはクリティカルな要素を識別することも、本発明の範囲を示すことも、意図されていない。この要約の唯一の目的は、後に提示されるより詳細な説明の前置きとして、単純化された形で本発明のいくつかの概念を提示することである。
【０００６】
本発明は、通知プラットフォームのアーキテクチャを提供するシステムおよび方法に関する。本発明の一態様によれば、このアーキテクチャに、コンテキストアナライザ（ｃｏｎｔｅｘｔ ａｎａｌｙｚｅｒ）またはコンテキストコンポーネントと、１つまたは複数の通知ソースおよび通知シンクと、通知マネージャが含まれる。コンテキストアナライザは、ユーザのデフォルト通知プリファレンス（ｐｒｅｆｅｒｅｎｃｅ）などのユーザの通知パラメータに関するユーザプロファイル情報を保管し、ユーザコンテキスト識別および更新サービスを提供する。通知ソースは、ユーザに向けられた通知を生成し、通知シンクは、ユーザへの通知を提供する。通知マネージャが、コンテキストアナライザによって保管され判定される情報と、通知の緊急性に関する提供されるか推定された情報とに基づいて、ソースによって生成された通知をシンクに伝えるか向ける。例えば、通知マネージャは、ユーザのコンテキスト（例えば、ユーザの現在位置および注意のフォーカス（集中、焦点；focus））にアクセスするか、これを推定することができる。これは、コンテキスト情報の複数のソースの見当に基づいて達成することができる。そのような情報のソースには、例えば、ユーザのコンテキストプロファイル、ユーザのオンラインカレンダ、時刻、世界に関するイベント、組織、システム、および／またはユーザのアクティビティを含めることができる。その後、通知を、情報のコンテキストおよび緊急性の分析を介して判定することができる。これには、通知のどれを、どのシンクを介して、そのシンクによって提供される形またはモーダリティのどれで、ユーザに伝えなければならないかの判定を含めることができる。
【０００７】
本発明の他の態様によれば、ユーザは、例えば、電子メールアラートを受け取り、なおかつ、望むならば、電子メールを自動的に携帯電話に向けることができる。同様に、音声メールを、通知マネージャによって適当に決定されるように、デスクトップコンピュータに向けることができる。したがって、通知ソースからの通知は、通知マネージャによって処理され、通知マネージャは、ユーザに通知しなければならないかどうかを判定する。マネージャが、ユーザに通知しなければならないと判定する場合には、マネージャは、ユーザに通知する方法も判定する。これは、所望の通知シンクに通知するための、ユーザのプリファレンスおよび現在のコンテキストなどの情報を含む、ユーザプロファイルに保管された情報に基づくものとすることができる。シンクには、例えば、デスクトップコンピュータ、携帯電話、ポケットベル、および／または他のデバイス／アプリケーションを含めることができる。
【０００８】
さらに、通知プラットフォームのアーキテクチャを、例えばデスクトップ設定またはモバイル設定でのソフトウェアコンポーネントによるサービスの潜在的な提供に関連するものを含む、実質的にすべての通知に一般化することができる。そのような通知には、下記を含めることができる。
【０００９】
・ソフトウェアアプリケーションを使っているユーザにアシスタンスまたはヒントを自動的に提供しようとするサービスおよび／またはユーザの注意のフォーカスで電子メールを検査することによるスケジューリングを自動的に実行するサービスなどのサービスに関するアラート
・これから来る面会予約または約束についてユーザに通知するアラート
・友人および同僚の位置、近接、または注意の状況の重要な変化を中継するアラート
・作成中のテキストまたはユーザがレビューしているテキストに基づいてバックグラウンド照会を発行し、そのようなバックグラウンド検索の結果をユーザに提示するアラート
【００１０】
上で説明したように、コンテキストアナライザは、ユーザの現在位置および注意の状態などのユーザの現在のコンテキストを判定する。判定されたコンテキストを使用して、例えば、ユーザに向けられた通知を伝えなければならないかどうかと、いつ、どのように伝えるかを決定することができる。本発明の他の態様によれば、コンテキストは、ユーザによる直接指定、１つまたは複数のセンサを使用する直接測定、コンテキストを示すユーザが修正可能なプロファイル、コンテキストを示す潜在的にユーザが修正可能な１つまたは複数のルール、および／またはベイズモデルまたは統計モデルなどのモデルを使用する推定分析のうちの１つまたは複数を介して判定される。したがって、ユーザの位置および注意の状態（またはフォーカス）を含むユーザのコンテキストを、ユーザに通知を伝えるのに使用することができる。
【００１１】
本発明のもう１つの態様によれば、決定理論的分析を、通知マネージャによって使用して、通知ソースから受け取った通知のどれを、通知シンクに関連する１つまたは複数のモードのどれを介して、ユーザに伝えるかを決定することができる。通知に含まれる情報の期待価値から、シンクのモードを介して通知を伝えるための中断の期待コストを引き、通知なしでユーザが通知に含まれる情報を独立に習得することの期待価値を引き、モードおよびシンクを介して通知を伝えることの実際のコストを引いた値を、通知シンクおよび関連するモードについて判定する。この値が、所定の伝達閾値より大きい場合に、通知が、例えば最も高いその値を有するシンクのモードを介して伝えられる。本発明のもう１つの態様によれば、ヒューリスティック（heuristic）通信ポリシを、通知マネージャによって使用して、通知ソースから受け取ったどの通知を、関連する通信シンクのどのモードを介してユーザに伝えなければならないかを判定する。
【００１２】
以下の説明および添付図面に、本発明のいくつかの例示的態様を詳細に示す。しかし、これらの態様は、本発明の原理を使用できる様々な形のごく少数を例示するものであり、本発明は、そのような態様のすべておよびその同等物を含むことが意図されている。本発明の他の長所および新規の特徴は、添付図面と共に検討される時に、以下の本発明の詳細な説明から明白になる。
【図面の簡単な説明】
【００１３】
【図１】本発明の一態様による、通知プラットフォームアーキテクチャを示すシステムの概略ブロック図である。
【図２】本発明の一態様による、コンテキストアナライザを示す概略ブロック図である。
【図３】本発明の一態様による、通知ソースおよび通知シンクを示す概略ブロック図である。
【図４】本発明の一態様による、通知曲線の使用を示す図である。
【図５】本発明の一態様による、通知に関するユーザ指定インタフェースを示す図である。
【図６】本発明の一態様による、コンテキスト情報ソースを示す図である。
【図７】本発明の一態様による、コンテキストを判定するためのルールベースシステムを示す図である。
【図８】本発明の一態様による、コンテキストを判定するための推定ベースシステムを示す概略ブロック図である。
【図９】本発明の一態様による、コンテキストを判定するための推定モデルを示す図である。
【図１０】本発明の一態様による、コンテキストを判定するための時間的推定モデルを示す図である。
【図１１】本発明の一態様による、コンテキストを判定する方法を示す流れ図である。
【図１２】本発明の一態様による、通知意思決定の方法を示す流れ図である。
【図１３】本発明の一態様による、通知プラットフォームの決定理論的分析を提供する方法を示す流れ図である。
【図１４】本発明の一態様による、例示的ディスプレイを示す図である。
【図１５】本発明の一態様による、様々なディスプレイを提供する方法を示す流れ図である。
【図１６】本発明の一態様による、価値対時間を示す図である。
【図１７】本発明の一態様による、ストリームサイクリングを提供する方法を示す流れ図である。
【図１８】本発明の一態様による、例示的ストリームサイクリングディスプレイを示す図である。
【図１９】本発明の一態様による、例示的ストリームスタッキングディスプレイを示す図である。
【図２０】本発明の一態様による、例示的ストリームスタッキグディスプレイを示すより詳細な図である。
【図２１】本発明の一態様による、ストリームスタッキングを提供する方法を示す流れ図である。
【図２２】本発明の代替態様による、例示的ディスプレイを示す図である。
【図２３】本発明の一態様による、適当なオペレーティング環境を示す概略ブロック図である。
【発明を実施するための形態】
【００１４】
本発明は、１つまたは複数の通知ソースに関連する様々な情報を、通知プラットフォームアーキテクチャを介して１つまたは複数の通知シンク（例えば情報を受け取るモーダリティ）に向けることを可能にするシステムおよび方法に関する。このアーキテクチャには、位置および注意のフォーカスなどのユーザの状態を判定するためのコンテキストアナライザが含まれ、ユーザの状態は、例えば通知ソースによって生成されたどの情報をいつどのように通知シンクに転送しなければならないかに関する決定を行うために、通知マネージャによって使用される。これらの決定には、ユーザに通知することの利益よりユーザを中断することのコストが大きいかどうかに関する考察が与えられる費用便益分析を含めることができる。決定理論的ポリシおよび／または多少フォーマルでないヒューリスティックポリシを使用して、通知マネージャ内の意思決定処理を可能にすることができる。
【００１５】
まず、図１を参照すると、システム１０に、本発明の一態様による通知アーキテクチャが示されている。システム１０には、コンテキストアナライザ２２、通知マネージャ２４（イベントブローカとも称する）、１つまたは複数の通知ソース（例えば、情報を提供するモーダリティ）１からＮ、２６、２７、２８、および１つまたは複数の通知シンク１からＭ、３６、３７、３８が含まれ、ＮおよびＭは、それぞれ整数である。ソースを、イベントパブリッシャ（ｅｖｅｎｔ ｐｕｂｌｉｓｈｅｒ）とも称し、シンクを、イベントサブスクライバ（ｅｖｅｎｔ ｓｕｂｓｃｒｉｂｅｒ）とも称する。任意の数のシンクおよびソースを設けることができる。一般に、通知マネージャ２４は、イベントまたはアラートとも称する通知を、ソース２６〜２８からシンク３６〜３８に、コンテキストアナライザ２２内に保管され、かつ／またはコンテキストアナライザ２２によってアクセスされるパラメトリック情報に部分的に基づいて、通知を伝える。
【００１６】
コンテキストアナライザ２２は、通知意思決定に影響するユーザの変数およびパラメータに関する情報を保管／分析する。例えば、パラメータに、ユーザの通常の位置および注意のフォーカスまたは時刻および曜日ごとのアクティビティなどのコンテキスト情報と、ユーザが異なる場所でアクセスを有する傾向があるデバイスなど、そのようなパラメータによって条件付けられる追加パラメータを含めることができる。そのようなパラメータは、１つまたは複数のセンサを介して自律的に行われる観察の関数とすることもできる。例えば、１つまたは複数のプロファイル（図示せず）を、全地球測位システム（ＧＰＳ）サブシステムによって提供することができるユーザの位置に関する情報、使用されつつあるデバイスのタイプおよび／またはデバイスの使用のパターンに関する情報、および特定のタイプのデバイスがユーザによって最後にアクセスされた時刻に基づいて選択または修正することができる。さらに、下で詳細に説明するように、自動化された推定を使用して、位置および注意などのパラメータまたは状態を動的に推定することもできる。プロファイルパラメータは、ユーザによる編集が可能なユーザプロファイルとして保管することができる。事前に定義されたプロファイルの組または動的推定に頼ることの他に、通知アーキテクチャは、ユーザが、例えばこれから「ｘ」時間の間、または所与の時刻まで、ユーザが重要な通知を除いて応じることができないなど、自分の状態をリアルタイムで指定できるようにする。
【００１７】
パラメータには、異なるタイプの通知によって異なる設定で邪魔されることに関するユーザのプリファレンスに関するデフォルト通知プリファレンスパラメータも含めることができ、これは、通知マネージャ２４による通知決定の基礎として使用することができ、これに基づいてユーザが変更を開始することができる。パラメータには、ユーザが異なる状況で（例えば、携帯電話によって、ポケットベルによってなど）どのように通知を受けたいかに関するデフォルトパラメータを含めることができる。パラメータには、異なる設定で異なるモードによって警告されることに関連する中断のコストの査定などを含めることができる。これには、ユーザが異なる位置にいる尤度、異なるデバイスが使用可能である尤度、および所与の時刻のユーザの注意の状況の尤度を示すコンテキストパラメータ、ならびに、ユーザが所与の時刻にどのように通知されることを望むかを示す通知パラメータを含めることができる。
【００１８】
コンテキストアナライザ２２によって保管された情報は、本発明の一態様に従って、アナライザによって決定されるコンテキスト情報を含む。コンテキスト情報は、アナライザ２２によって、この説明の後の節で詳細に説明するように、１つまたは複数のコンテキスト情報ソース（図示せず）に基づいてユーザの位置および注意の状況を識別することによって判定される。コンテキストアナライザ２２は、例えば、ユーザの自動車電話または携帯電話の一部である全地球測位システム（ＧＰＳ）を介して、ユーザの実際の位置を正確に判定することができる場合がある。アナライザは、曜日、時刻、ユーザのカレンダ内の日付などの情報の考慮およびユーザのアクティビティに関する観察を介して収集されたバックグラウンド査定および／または観察を考慮することによって、ユーザが所与の注意の状態である尤度を判定するために統計モデルも使用することができる。所与の注意の状態には、ユーザが通知を受けることに支障がないか、忙しく、通知を受けることに支障があるかを含めることができ、平日、週末、休日、および／または他の時／期間などの他の考慮事項を含めることができる。
【００１９】
ソース２６〜２８は、ユーザおよび／または他のエンティティに向けられた通知を生成する。例えば、ソース２６〜２８に、インターネットおよびネットワークベースの通信、ローカルデスクトップコンピュータベースの通信、および電話通信などの通信、ならびに、インテリジェントヘルプ、バックグラウンド照会、および自動化スケジューリングなどのソフトウェアサービスを含めることができる。通知ソースは、本明細書では、全般的に、情報、サービス、および／またはシステムイベントまたは世界のイベントに関する、ユーザまたはユーザの代理に向けられた、通知またはアラートとも称することができるイベントを生成するものと定義される。通知ソースを、イベントソースと呼ぶこともできる。
【００２０】
例えば、電子メールを、電子メール通知ソースによって通知として生成し、それに優先順位を付けることができ、通知を生成するアプリケーションプログラムまたはシステムが、電子メールに、ユーザにとってのその電子メールの適当な重要性または緊急性に対応する相対優先順位を割り当てる。電子メールは、ユーザにとっての相対的重要性に無関係に送信することもできる。デスクトップセントリック（ｄｅｓｋｔｏｐ−ｃｅｎｔｒｉｃ）通知には、ユーザが実行を望む潜在的に価値のあるサービス（例えば、メッセージからのスケジューリング）、ユーザが再検討することを望む情報（例えば、バックグラウンド照会から導出される）、またはデスクトップコンピュータによって生成されたエラーおよび／または他のアラートについてユーザに警告するという最終目標を持った自動化されたダイアログを含めることができる。インターネット関連サービスには、例えば時々の最新ニュースの見出しおよび株式相場などの、ユーザが購読する情報を含む通知を含めることができる。
【００２１】
他の通知には、バックグラウンド照会（例えば、ユーザが作業している間に、ユーザが現在扱っているテキストを再検討し、そのテキストに関するバックグラウンド照会が、定式化され、検索エンジンに発行される）および、スケジューリングプログラムおよび／または他のプログラムからのタスクのスケジューリングを含めることができる。通知ソース２６〜２８自体は、プッシュタイプまたはプルタイプのソースとすることができる。プッシュタイプのソースとは、購読申し込みの後に自動的に情報を送信する、ヘッドラインニュースおよび他のインターネット関連サービスなどの、対応する要求なしで自動的に情報を生成し、送信するソースである。プルタイプのソースとは、メールサーバをポーリングした後に受信される電子メールなど、要求に応答して情報を送信するソースである。他の通知ソースには、下記が含まれる。
【００２２】
・カレンダシステムなどの電子メールデスクトップアプリケーション、
・コンピュータシステム（例えば、システムアクティビティまたはシステムの問題に関する警告に関する情報をメッセージを用いてユーザに警告することができるものなど）、
・インターネット関連のサービス、予約情報、スケジューリング照会、
・１つまたは複数の共有フォルダ内の文書の変更またはある種類の文書の数の変化、
・情報に関する持続的なまたは永続的な照会に応答する新しい文書の可用性、および／または
・人とその存在、位置の変化、近接（例えば、旅行中に１０マイル以内に別の共働者または友人がいる場合に知らせて欲しいなど」）、または手が空いているかどうか（例えば、Ｓｔｅｖｅが話をする暇があり、フルビデオ会議をサポートできる高速リンクの近くにいる時に知らせて欲しいなど」）に関する情報の情報ソース。
【００２３】
通知シンク３６〜３８は、ユーザに通知を提供することができる。例えば、そのような通知シンク３６〜３８には、デスクトップおよび／またはラップトップコンピュータなどのコンピュータ、ハンドヘルドコンピュータ、携帯電話、陸線電話、ポケットベル、自動車ベースのコンピュータ、ならびに識別できる他のシステム／アプリケーションを含めることができる。シンク３６〜３８のいくつかが、他のシンクより豊富に通知を伝えることができることに留意されたい。例えば、デスクトップコンピュータは、通常はスピーカおよび比較的大きいカラーディスプレイを接続され、ローカルネットワークまたはインターネットに結合された時に情報を受信する帯域幅がより広い。したがって、通知は、デスクトップコンピュータによって、比較的豊富な形でユーザに伝えることができる。逆に、多くの携帯電話は、例えば、白黒である可能性がある、より小さいディスプレイを有し、比較的狭い帯域幅で情報を受信する。それに対応して、携帯電話によって伝えられる通知に関連する情報は、一般に、より短く、例えば電話のインタフェース機能に適応される可能性がある。したがって、通知の内容は、それが携帯電話とデスクトップコンピュータのどちらに送信されるかに応じて異なる可能性がある。本発明の一態様によれば、通知シンクが、例えばイベントまたは通知を、イベント購読サービスを介して購読する通知シンクを参照することができる。
【００２４】
通知マネージャ２４は、コンテキストアナライザによって保管され、かつ／または判定された情報にアクセスし、ソース２６〜２８から受け取った通知のどれを、シンク３６〜３８のどれに伝えるかを決定する。さらに、通知マネージャ２４は、シンク３６〜３８のどれが情報を送る先として選ばれたかに応じて、通知を伝える方法を決定することができる。例えば、選択されたシンク３６〜３８に供給する前に、通知を要約しなければならないと決定することができる。
【００２５】
本発明は、通知のどれを通知シンクのどれに伝えるか、および通知を伝える形に関してマネージャ２４が決定する方法に制限されない。一態様によれば、決定理論的分析を使用することができる。例えば、通知マネージャ２４は、ユーザの位置、注意、デバイス可用性、および、アラートがない場合にユーザが情報にアクセスするまでの時間を含む変数に関する重要な不確実性を推定するように適合させることができる。通知マネージャ２４は、ユーザに通知について警告するかどうかと、そうする場合に、要約の性質および通知を中継するのに使用される適当な１つまたは複数のデバイスに関する通知決定を行うことができる。一般に、通知マネージャ２４は、通知の正味の期待価値を判定する。それを行う際に、通知マネージャは、下記を考慮する。
【００２６】
・各使用可能な通知シンクの忠実度および送信信頼性、
・ユーザの気を散らすことの注意的なコスト、
・ユーザにとっての情報の新規性、
・ユーザが自分で情報を再検討するまでの時間、
・情報の潜在的なコンテキスト応答の価値、および／または
・通知に含まれる情報の経時的に増えるかつ／または減る価値。
【００２７】
したがって、不確実性に関して行われる推定を、例えばユーザのある注意の状態に対して、特定のデバイスの特定のモードの使用によるユーザに対する中断のコストなどの価値の期待される尤度として生成することができる。通知マネージャ２４は、下記の１つまたは複数に関する決定を行うことができる。
【００２８】
・ユーザが現在注目し、行っているもの（例えば、コンテキスト情報に基づく）、
・ユーザが現在どこにいるか、
・情報がどれほど重要か、
・通知を延期することのコストはどれほどか、
・通知がどのように気を散らすか、
・ユーザに到達する尤度はどれほどか、および、
・所与の通知シンクの特定のモードの使用に関連する忠実度の消失はどれほどか。
【００２９】
したがって、通知マネージャ２４は、保留中およびアクティブな通知の、決定理論的分析などの分析を行い、情報シンクおよび情報ソースによって提供されるコンテキスト依存変数を評価し、ユーザが情報を再検討する可能性が高い時までの時間とユーザの位置および現在の注意の状態などの選択された不確実性を推定することができる。
【００３０】
本明細書で使用される際に、推定は、一般に、イベントおよび／またはデータを介して取り込まれる一組の観察からの、システム１０、環境、および／またはユーザに関する推理またはそれらの状態の推定の処理を指す。推定は、例えば、特定のコンテキストまたはアクションを識別するのに使用することができ、あるいは、状態に関する確率分布を生成することができる。推定は、確率的すなわち、データおよびイベントの検討に基づく当の状態に関する確率分布の計算とすることができる。推定は、イベントおよび／またはデータの組からより高水準のイベントを合成するのに使用される技法を指すこともできる。そのような推定は、観察されたイベントおよび／または保管されたイベントデータの組、イベントが密な時間的近接で相関するか否か、およびイベントおよびデータが１つまたは複数のイベントソースおよびデータソースから来たかどうか、からの新しいイベントまたはアクションの構成をもたらす。
【００３１】
さらに、通知マネージャ２４は、パーソナライズされた決定理論的分析の代わりにまたはそれをサポートするために、コンテキストアナライザ２２によってユーザプロファイルに保管された情報にアクセスすることができる。例えば、ユーザプロファイルによって、所与の時刻に、通知が所定の分類（例えば重要性）レベルを有する場合に限って、ユーザが、ポケットベルを介して通知されることを好むことを示すことができる。そのような情報は、決定理論的分析を開始する基準線として使用することができ、あるいは、通知マネージャ２４が、ユーザに通知するかどうかとその方法を決定する形とすることができる。
【００３２】
本発明の一態様によれば、通知プラットフォームアーキテクチャ１０は、イベンティング（ｅｖｅｎｔｉｎｇ）インフラストラクチャまたはメッセージングインフラストラクチャの上に常駐する層として構成することができる。しかし、本発明は、特定のイベンティングインフラストラクチャに制限されない。そのようなイベンティングおよびメッセージングのシステムおよびプロトコルには、下記を含めることができる。
【００３３】
・ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）または当技術分野で既知のＨＴＴＰ拡張、
・当技術分野で既知のＳｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）、
・当技術分野で既知のＷｉｎｄｏｗｓ（登録商標） Ｍａｎａｇｅｍｅｎｔ Ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ（ＷＭＩ）、
・当技術分野で既知のＪｉｎｉ、および、
・例えばパケット交換プロトコルに基づくものなどの、実質的にすべてのタイプの通信プロトコル。
【００３４】
さらに、このアーキテクチャは、当業者が諒解できるように、柔軟な分散計算インフラストラクチャの上に常駐する層として構成することができる。したがって、通知プラットフォームアーキテクチャは、例えば、ソースが通知、アラート、およびイベントを送信する形として、また、シンクが通知、アラート、およびイベントを受信する形として、基礎となるインフラストラクチャを使用することができる。しかし、本発明は、これに制限されない。
【００３５】
図２を参照して、この説明の前の節で説明した通知アーキテクチャのコンテキストアナライザ２２を、詳細に説明する。図２に示されたコンテキストアナライザ２２には、ユーザ通知プリファレンスストア５２、ユーザコンテキストプロファイルストア５５を含むユーザコンテキストモジュール５４、およびホワイトボード５７が含まれる。本発明の一態様によるコンテキストアナライザ２２は、コンピュータのプロセッサによって、メモリなどの計算機可読媒体から実行される１つまたは複数のコンピュータプログラムとして実施することができる。
【００３６】
プリファレンスストア５２には、ユーザが編集でき修正できるユーザプロファイルなどの、ユーザのデフォルト通知プリファレンスなどの、ユーザに関する通知パラメータが保管される。プリファレンスストア５２は、ユーザに通知する方法に影響するパラメータに関する情報が保管されるストアとみなすことができる。ユーザコンテキストモジュール５４は、例えば、ホワイトボード５７に発行される１つまたは複数のコンテキスト情報ソース６０に基づいて、ユーザの現在のコンテキストを判定する。ユーザコンテキストプロファイルストア５５には、ユーザが編集でき修正できる、ユーザに関するデフォルトコンテキスト設定などの、ユーザに関するコンテキストパラメータが保管される。すなわち、ユーザコンテキストモジュール５４は、プロファイルストア５５からの情報にアクセスし、かつ／または、１つまたは複数のコンテキスト情報ソース６０を介する生のセンシングを用いてプロファイルストア５５内の前の１組のビリーフ（belief）を更新することによって、ユーザの現在のコンテキスト情報に関する最適の推測または推定を提供する。プロファイルストア５５は、例えば、先験的なユーザの位置およびユーザが行っていることが保管されるストアとみなすことができる。
【００３７】
ユーザコンテキストプロファイルストア５５は、決定的プロファイルまたは確率的プロファイルとして情報を取り込む、事前に査定され、かつ／または事前に定義されたユーザプロファイルとすることができる。プロファイルは、通常の位置と、アクティビティと、デバイス可用性と、時刻、日の種類、１つまたは他のデバイスとのユーザ対話などの観察の関数としての通知の異なるクラスのコストおよび値とすることができる。日の種類には、例えば、平日、週末、および休日を含めることができる。ユーザコンテキストモジュール５４は、ユーザの現在のまたは将来の位置および注意の状態など、ユーザのコンテキストまたは状態の諸態様を能動的に判定または推定することができる。さらに、コンテキストの実際の状態は、ホワイトボード５７を介してコンテキスト情報ソース６０から直接にアクセスすることができ、かつ／または、下で詳細に説明するベイズ推定などの推定方法を介して、様々なそのような観察から推定することができる。
【００３８】
コンテキスト情報ソース６０は、ユーザの注意の状態および位置に関して、ホワイトボード５７を介してコンテキストモジュール５４に情報を供給し、その情報から、モジュール５４が、ユーザの現在のコンテキスト（例えば、ユーザの現在の注意の状態および位置）に関する判断を行うことができる。さらに、本発明は、特定の数またはタイプのコンテキストソース６０にも、ユーザコンテキストモジュール５４によって推定またはアクセスされる情報のタイプにも制限されない。しかし、コンテキストソース６０に、例えば、マウス情報、キーボード情報、アプリケーション情報（例えば、アプリケーションが現在ユーザのフォーカス（focus）を受け取っているかどうか）、周囲の音声および発声情報、デスクトップ上のウィンドウ内のテキスト情報など、複数のデスクトップ情報およびイベントを含めることができる。ホワイトボード５７に、共通のストレージエリアを含めることができ、このストレージに、コンテキスト情報ソース６０が、情報を公開し、このストレージから、ソースおよびコンテキストモジュール５４を含む複数のコンポーネントが、この情報にアクセスすることができる。通知またはアラートとも称するイベントには、一般に、世界の１つまたは複数の状態に関する観察に関する情報を含めることができる。そのような状態には、システムコンポーネントの状況、ユーザのアクティビティ、および／または環境に関する測定値を含めることができる。さらに、イベントは、測定デバイスおよび／またはイベントのソースの能動的ポーリングによって、変更時に送信される情報の受信によって、および／または一定または可変のイベントハートビートごとに、生成することができる。
【００３９】
他のタイプのコンテキストソース６０には、ユーザの個人情報管理（ＰＩＭ）情報が含まれ、この情報は、一般に、例えば、ユーザのスケジュールに関するスケジューリング情報を提供することができる。例えば、全地球測位システム（ＧＰＳ）および／または、位置を判定できる、ユーザの携帯電話、ＰＤＡ、またはラップトップによって判定されるユーザの位置ならびに現在時刻も、コンテキストソース６０のタイプである。さらに、リアルタイムモバイルデバイス使用が、コンテキストソース６０のタイプである。例えば、携帯電話などのモバイルデバイスは、ユーザによって現在アクセスされつつあるかどうか、ならびにデバイスの方位および傾斜（例えば、デバイス使用に関する情報をも示す）と、加速度および速度（例えば、ユーザが移動中であるか否かを示す）を判定することができる。
【００４０】
図３を参照すると、上で説明した通知ソースが詳細に示されている。通知ソース２６〜２８は、通常は、通知マネージャ２４に伝えられる通知を生成し、通知マネージャ２４は、いつ通知を行わなければならないかと、そうである場合に、どの通知を通知シンク３６〜３８のどれにどの順番で伝えなければならないかを判定する。
【００４１】
本発明の一態様によれば、通知ソース２６〜２８は、本明細書で通知ソーススキーマまたはソーススキーマと称する、属性および関係の標準記述内で、下記のパラメータの１つまたは複数を有することができる。スキーマを、上で説明したソース、シンク、およびコンテキスト情報ソースについて設けることができることに留意されたい。そのようなスキーマは、異なるコンポーネントに関する宣言情報を提供し、ソース２６〜２８、通知マネージャ２４、シンク３６〜３８、およびコンテキストアナライザ２２が互いにセマンティック情報を共有できるようにすることができる。したがって、異なるスキーマによって、通知に関する性質、緊急性、およびデバイスシグナリングモーダリティに関する情報が提供される。すなわち、スキーマは、一般に、クラスおよびクラス間の関係の集合として定義することができ、これによって、例えば、イベントまたは通知クラスに関する情報、ソース、ターゲット、イベントまたは通知のセマンティクス、存在論的コンテキスト情報、観察信頼性、および実質的にすべてのサービス品質属性を含む、通知およびイベントの構造が定義される。
【００４２】
通知ソーススキーマのパラメータ（図示せず）には、メッセージクラス、関連、重要性、時間臨界、新規性、内容属性、忠実度トレードオフ、および／またはソース情報要約情報のうちの１つまたは複数を含めることができる。通知ソースによって生成される通知のメッセージクラスは、例えば、電子メール、インスタントメッセージ、数値的財務更新、およびデスクトップサービスなど、通知の通信のタイプを示す。通知ソースによって生成される通知の関連は、その通知に含まれる情報が、１つまたは複数の指定されたコンテキストに関して関連する尤度を示す。例えば、関連は、ソースが所与のコンテキストに関連するか否かを示す論理フラグによって提供することができる。通知の新規性は、ユーザが既にその通知に含まれる情報を知っている尤度を示す。すなわち、新規性は、その情報が、ユーザにとって経時的に新しいかどうかである（ユーザが今その情報を知っているかどうかを示し、それについて警告されずにユーザが将来にその情報を知る場合に、それがいつであるかを示す）。
【００４３】
通知に関連する忠実度トレードオフは、例えば指定された許容される切捨および／または要約の異なる形態から生じる可能性がある、通知内の情報の価値の消失を示す。そのような切捨および／または要約は、最初に生成された完全な通知をシンクが受信できなくする帯域幅および／または他の制限を有する、あるタイプの通知シンク３６〜３８に通知を伝えるために必要になる可能性がある。忠実度は、一般に、通知に関連する元の内容の完全さの性質および／または度合を指す。例えば、長い電子メールメッセージは、携帯電話によって許容される１００文字の最大値までに切り捨てられるか他の形で要約され、忠実度の消失をこうむる可能性がある。同様に、テキストとグラフィックスの内容を含む元のメッセージが、テキスト機能だけを有するデバイスを介して送信される時に、忠実度の消失をこうむる。さらに、あるデバイスが、ソースから入手可能な完全な解像度の一部を示すことしかできない場合がある。忠実度トレードオフは、順序付け（例えば、まずグラフィックス、次にサウンドの順でのレンダリングの重要性）および／または通知の内容の総合的価値が忠実度の変化に伴ってどのように減少するかを示すコスト関数のいずれかに関して示される、ソースの忠実度プリファレンスの組を指す。例えば、忠実度トレードオフによって、完全な電子メールメッセージの送信に関連するすべての価値が、切捨の量の増加に伴ってどのように変化するかを記述することができる。例えば、コンテキスト属性に、コアメッセージにテキスト、グラフィックス、およびオーディオのコンポーネントが含まれるかどうかなどの情報を表す、内容の性質の要約を含めることができる。内容自体は、通知のメッセージ内容を構成する、実際のグラフィックス、テキスト、および／またはオーディオである。
【００４４】
通知の重要性は、情報が現在のコンテキストに関連すると仮定して、通知に含まれる情報の、ユーザにとっての価値を指す。例えば、重要性は、ユーザにとっての情報の価値の金額として表すことができる。時間臨界は、通知に含まれる情報の価値の時間依存の変化すなわち、情報の価値が経時的にどのように変化するかを示す。すべてではないがほとんどの場合に、通知の情報の価値は、時間に伴って減少する。これを、図４に示す。グラフ８０に、経時的にマッピングされた通知の有用性が示されている。開始時を表すグラフ内の点８４で、通知の重要性が示されており、曲線８６は、経時的な有用性の減少を示す。
【００４５】
図３に戻って、異なる通知ソースまたはソースタイプのデフォルト属性およびスキーマテンプレートを、図２のストア５２などのユーザ通知プリファレンスストアに保管された通知ソースプロファイル内で使用可能にすることができる。そのようなデフォルトテンプレートに、通知ソースによって供給される値をオーバーライドするか、ソースによって供給されるスキーマにない時に属性を供給するように指示することができる。ソース要約情報によって、ソースが、情報の状況の全般的な要約およびソースから入手可能な潜在的な通知をポストできるようになる。例えば、メッセージングソースからのソース要約情報に、少なくともある優先順位である未読メッセージの総数に関する情報、ユーザと通信しようとする人による試みの状況、および／または他の要約情報を含めることができる。
【００４６】
通知シンク３６〜３８は、それによってユーザまたは他のエンティティが通知に含まれる情報について通知を受けることができる、実質的にすべてのデバイスまたはアプリケーションとすることができる。特定の通知を伝えるのにどのシンクを使用するかに関する選択は、通知マネージャ２４によって決定される。
【００４７】
通知シンク３６〜３８は、スキーマ内で供給される下記のパラメータのうちの１つまたは複数を有することができる。このパラメータには、デバイスクラス、シグナリング（警告）のモード、および、関連するモードについて、例えば、忠実度／レンダリング機能、送信信頼性、通信の実際のコスト、および／または中断の注意的コストを含めることができる。警告属性のパラメータ化された制御に適合されたデバイスについて、そのデバイスのスキーマに、さらに、警告属性およびその属性を制御するパラメタの記述、他の属性（例えば送信信頼性、配布のコストなど）を警告属性の異なる設定を用いて変更する機能を含めることができる。通知シンクのスキーマは、通知デバイスがその性質および機能に関するセマンティック情報を通知マネージャ２４および／またはシステムの他のコンポーネントと通信する形を提供する。異なるデバイスタイプのデフォルトの属性およびスキーマテンプレートは、前の節で説明した図２のストア５２などのユーザ通知プリファレンスストアに保管されたデバイスプロファイル内で使用可能にすることができる。そのようなデフォルトテンプレートに、デバイスによって供給される値をオーバーライドするか、そのようなデバイスによって提供されるスキーマにない時に属性を供給するように指示することができる。
【００４８】
スキーマパラメータのそれぞれを、これから順番に説明する。デバイスのクラスは、例えば携帯電話、デスクトップコンピュータ、およびラップトップコンピュータなどのデバイスのタイプを指す。クラスは、モバイルデバイスまたは文房具デバイスなどのより一般的なものとすることもできる。シグナリングのモードは、所与のデバイスが通知についてユーザに警告できる形を指す。デバイスは、１つまたは複数の通知モードを有することができる。例えば、携帯電話は、振動だけ、ある音量の呼び出し音だけ、および／または振動と呼び出し音の両方を与えることができる。さらに、警告システムのデスクトップディスプレイは、複数の別個のモードに分解することができる（例えば、ディスプレイの右上角の小さい通知ウィンドウ対画面最上部の小さいサムネール、音声告知ありまたはなし）。事前に定義された挙動の組に制限される以外に、デバイスは、デバイス定義の一部としてのパラメータの関数である警告属性を有するモードをイネーブルすることができる。モードに関するそのような継続的な警告パラメータは、例えば、デスクトップでアラートを再生するボリューム、携帯電話での呼び出し音、警告ウィンドウのサイズなどのコントロールを表す。
【００４９】
通知シンク３６〜３８のモードの送信信頼性は、ユーザが、そのモードのシンクを介してユーザに伝えられる通知に関する通信されたアラートを受信する尤度を示す。送信信頼性は、デバイス可用性およびユーザのコンテキストに依存する可能性があり、あるデバイスの異なるモードの送信信頼性は、ユーザの位置および注意などのコンテキスト属性によって条件付けすることができる。一意の位置および一意の注意の状態などの属性のクロス乗積として定義され、そのような属性（例えば、自宅以外のすべての位置について、午前８時から正午までのすべての時刻など）の抽象（abstraction）として作成される離接（disjunction）として定義される、１つまたは複数の一意のコンテキスト状態に関する送信信頼性を指定することもできる。例えば、ユーザが現在どこにいるかに応じて、携帯電話に送信される情報が、特にユーザが間欠性の受信地域を有する領域内にいる場合またはユーザがこの位置で携帯電話を有する傾向がない時（例えば家族の休日）に、必ずしもユーザに到達しない可能性がある。また、コンテキストは、環境ノイズおよび／またはコンテキストの他のマスキング特性または気を散らす特性に起因して、送信信頼性に影響する可能性がある。
【００５０】
通信の実際のコストは、シンクに伝えられる通知内に含まれる時の、ユーザへの情報の通信の実際のコストを示す。例えば、このコストに、携帯電話送信に関連する料金を含めることができる。中断のコストには、特定のコンテキストで、デバイスの特定のモードによって使用されるアラートに関連する中断に関連する注意のコストが含まれる。注意のコストは、通常は、ユーザの特定の注意のフォーカスに敏感である。忠実度／レンダリング機能は、やはりあるモードでの、デバイスのテキスト、グラフィックス、およびオーディオ／触覚機能の記述である。例えば、携帯電話のテキスト限界は、単一のメッセージについて１００文字とすることができ、電話は、グラフィックス機能を有しない場合がある。
【００５１】
図５に移ると、インタフェース９０に、ユーザの現在のコンテキストを判定する際にコンテキストアナライザ２２が使用することができる、ユーザによって選択可能なコンテキスト指定が示されている。ユーザによる直接指定および／またはユーザが修正可能なプロファイルによるユーザコンテキストの決定を説明する。ユーザのコンテキストには、ユーザの注意のフォーカスすなわち、ユーザが現在通知アラートの受信に敏感に反応するかどうか、ならびにユーザの現在の位置を含めることができる。しかし、本発明は、これに制限されない。
【００５２】
ユーザによるコンテキストの直接指定によって、ユーザが、自分がアラートを受け取る暇があるかどうかと、アラートの受け取りを望むかどうかを示すことができるようになる。デフォルトプロファイル（図示せず）を使用して、デフォルトの注意の状態およびユーザがアラートを受け取ることができるデフォルトの位置を示すことができる。デフォルトプロファイルは、ユーザが望み通りに修正することができる。
【００５３】
図５を参照すると、インタフェース９０に、本発明の一態様に従って、コンテキストの直接指定をどのように実施することができるかが示されている。例えば、ウィンドウ９１が、注意のフォーカスセクション９２および位置セクション９４を有する。フォーカスセクション９２では、ユーザが、１つまたは複数のチェックボックス９６にチェックマークを付けることができ、例えば、ユーザが常時アラートを受け取る暇があるかどうか（ａｌｗａｙｓ ａｖａｉｌａｂｌｅ）、ユーザがアラートを受け取る暇が絶対にないかどうか（ｎｅｖｅｒ ａｖａｉｌａｂｌｅ）、および、ユーザが、所定の閾値を超える重要性レベルを有するアラートだけを受け取る暇があるかどうか（ａｖａｉｌａｂｌｅ ｔｏ ｒｅｃｅｉｖｅ ａｌｅｒｔｓ ｔｈａｔ ｈａｓ ａｎ ｉｍｐｏｒｔａｎｃｅ ｌｅｖｅｌ ｇｒｅａｔｅｒ ｔｈａｎ）を示すことができる。他のアベイラビリティセクションを設けることができることを諒解されたい。図５からわかるように、閾値をドル単位で測定することができるが、これは例示のみを目的とし、本発明はこれに制限されない。ユーザは、ボックス９８の閾値を、新しい値を直接に入力することによって、または矢印１００を介して閾値を増減することによって、増やすことができる。
【００５４】
位置セクション９４では、ユーザが、１つまたは複数のチェックボックス１０２にチェックマークを付けて、アラートが伝えられることをユーザが望む場所を指定することができる。例えば、ユーザは、デスクトップに、電子メールによって、ラップトップに、携帯電話に、自動車の中に、ポケットベルに、または携帯情報端末（ＰＤＡ）デバイスに、などにアラートを伝えさせることができる。しかし、これが例示のみであり、本発明自体はこれに制限されないことを諒解されたい。
【００５５】
ウィンドウ９１は、セクション９２のチェックボックス９６およびボックス９８とセクション９４のチェックボックス１０２についてデフォルトを事前にセットすることができ、デフォルトユーザプロファイルとみなすことができる。プロファイルは、ユーザがデフォルト選択を自分の望みの選択にオーバーライドできるという点で、ユーザ修正可能である。他のタイプのプロファイルも、本発明に従って使用することができる。
【００５６】
図６を参照すると、本発明による、例えば１つまたは複数のセンサを使用する、直接測定によるユーザコンテキストの判定が示されている。ユーザのコンテキストには、ユーザの注意のフォーカスならびにユーザの現在位置を含めることができる。しかし、本発明自体は、これに制限されない。コンテキストの直接測定は、センサを使用して、ユーザが現在アラートの受信に敏感に反応するかどうかを検出でき、ユーザが現在どこにいるかを検出できることを示す。本発明の一態様によれば、推定分析を、直接測定と共に使用して、この説明の後の節で説明するように、ユーザコンテキストを判定することができる。
【００５７】
図６を参照すると、ユーザコンテキストの直接測定を達成できるシステム１１０が示されている。システム１１０には、コンテキストアナライザ１１２が含まれ、システム１１０は、例えば、複数のセンサ１１４〜１２０すなわち、携帯電話１１４、ビデオカメラ１１５、マイクロホン１１６、キーボード１１７、ＰＤＡ１１８、乗物１１９、およびＧＰＳ１２０に、通信的に結合される。図６に示されたセンサ１１４〜１２０は、例示のみを目的とし、本発明自体に対する制限または制約を表すものではない。用語センサは、本明細書では、全般的かつ過度に包含的な用語であり、それによってコンテキストアナライザ１１２がユーザの現在の注意のフォーカスが何であるかおよび／またはユーザの現在位置がどこであるかを判定できるすべての装置または手段を意味する。
【００５８】
例えば、ユーザが携帯電話１１４の電源を入れている場合に、これは、ユーザが携帯電話１１４でアラートを受信できることを示す。しかし、ユーザが、現在携帯電話１１４で通話中である場合には、これは、ユーザが自分の注意のフォーカスを別の何か（すなわち、現在の通話）に向け、ユーザが、現在は通知アラートで邪魔されてはならないことを示す。ビデオカメラ１１５は、例えば、ユーザのオフィスにあって、ユーザが自分のオフィスにいるかどうか（すなわちユーザの位置）を検出でき、他の人もそのオフィスにおり、彼らと会議していることが示され、ユーザを邪魔してはならない（すなわちユーザのフォーカス）かどうかを検出することができる。同様に、マイクロホン１１６も、ユーザのオフィスにあって、ユーザが誰かと話しており、ユーザを邪魔してはならないかどうか、または、ユーザがキーボードで入力中（例えば、それから発する音を介して）であり、やはり現在はユーザを邪魔してはならないかどうかを検出することができる。キーボード１１７も、ユーザが現在それによって入力中であるかどうかを判定するのに使用することができ、例えば、ユーザが非常に早く打鍵している場合に、これによって、ユーザがコンピュータ関連のアクティビティにフォーカスを合わせており、過度に邪魔してはならないことを示すことができる（および、ユーザが実際に自分のオフィスにいることを示すこともできる）。
【００５９】
ＰＤＡデバイス１１８がユーザによってアクセスされつつある場合には、これによって、ユーザデバイス１１８でアラートを受信できることを示すことができる。すなわち、通知を伝えなければならない場所は、デバイス１１８がある場所である。デバイス１１８は、ユーザの現在の注意のフォーカスを判定するのにも使用することができる。乗物１１９は、ユーザが現在その乗物の中にいるかどうか、すなわち、乗物が現在ユーザによって操作されているかどうかを判定するのに使用することができる。さらに、例えば、乗物の速度を検討して、ユーザのフォーカスが何であるかを判定することができる。例えば、速度が所定の速度を超える場合に、ユーザが運転にフォーカスを合わせており、通知アラートによって悩まされてはならないと判定することができる。ＧＰＳデバイス１２０も、当技術分野で既知のように、ユーザの現在位置を確認するのに使用することができる。
【００６０】
この詳細な説明の以下の節では、ユーザ修正可能なルールによるユーザコンテキストの判定を説明する。ユーザのコンテキストには、ユーザの注意のフォーカスならびにユーザの現在位置を含めることができる。しかし、本発明は、これに制限されない。ルールを介するコンテキストの判定によって、ｉｆ−ｔｈｅｎルールの階層セットに従って、ユーザの位置および／または注意のフォーカスを判定できることが示される。
【００６１】
図７を参照すると、図に、例示的なルールの階層順序付きセット１３０が示されている。ルールのセット１３０では、例えば、ルール１３２、１３３、１３４、１３５、１３６、１３７、および１３８が示される。他のルールを、同様に構成できることに留意されたい。図７からわかるように、ルール１３３および１３４は、１３２に従属し、ルール１３４は、ルール１３３に従属し、ルール１３８は、ルール１３８に従属する。ルールは、ルール１３２が最初にテストされ、真であることがわかった場合に、ルール１３３がテストされ、ルール１３３が真であることがわかった場合に、ルール１３４がテストされ、以下同様になるように順序付けられる。ルール１３３が偽であることがわかった場合には、ルール１３５をテストする。ルール１３２が偽であることがわかった場合には、ルール１３６をテストし、これが偽であることがわかった場合には、ルール１３７がテストされ、これが真であることがわかった場合には、ルール１３８がテストされる。ルールは、ユーザが作成可能および／または修正可能であることが望ましい。ｏｔｈｅｒｗｉｓｅタイプのルールも、ルールのセット１３０に含めることができる（例えば、あるｉｆ−ｔｈｅｎルールが偽であることがわかった場合に、ｏｔｈｅｒｗｉｓｅルールが制御ルールになる）。
【００６２】
したがって、ユーザのコンテキストが判定されるように、ルールのセットをユーザが構成することができる。例えば、位置に関して、ルールのセットを、第１のルールで現在の日が平日であるかどうかをテストするものとすることができる。そうである場合には、第１のルールに従属する第２のルールで、現在の時刻が午前９時と午後５時の間であるかどうかをテストする。そうである場合には、第２のルールから、ユーザが自分のオフィスに位置することが示され、そうでない場合には、ユーザが自宅にいる。第１のルールが偽であるとわかった（現在の日が週末であって平日でない）場合には、ｏｔｈｅｒｗｉｓｅルールで、ユーザが自宅にいることを示すことができる。この例は、本発明自体に対する限定的または制限的な例であることを意図されたものではなく、１つまたは複数の他のルールを同様に構成することもできることに留意されたい。
【００６３】
この説明の以下の節では、統計モデルおよび／またはベイズモデルを使用することによるなど、推定分析によるユーザコンテキストの判定を説明する。推定分析を介するコンテキスト判定が、いくつかの態様で、既に述べたセンサを介する直接測定などの他の判定に頼ることができることに留意されたい。本明細書で使用される推定分析は、複数の入力変数に対して推定処理を使用して、出力変数すなわちユーザの現在のコンテキストをもたらすことを指す。分析には、一態様で、統計モデルおよび／またはベイズモデルの使用を含めることができる。
【００６４】
図８を参照すると、本発明の一態様による、推定エンジン１４２によって推定分析を実行して、ユーザのコンテキスト１４４を判定するシステム１４０の図が示されている。エンジン１４２は、一態様では、メモリなどのコンピュータ可読媒体からコンピュータのプロセッサによって実行されるコンピュータプログラムである。ユーザコンテキスト１４４は、エンジン１４２の出力変数とみなすことができる。
【００６５】
エンジン１４２は、１つまたは複数の入力変数を処理して、コンテキスト決定を行うことができる。そのような入力変数には、例えば、この説明の前の節でコンテキスト判定の直接測定手法に関して説明したセンサなどの１つまたは複数のセンサ１４８、ならびに、ユーザのスケジューリングコンピュータプログラムまたは個人情報管理（ＰＩＭ）コンピュータプログラム、および／またはユーザのＰＤＡデバイスでアクセスすることができる、クロック１５０およびカレンダ１５２によって表される現在の時刻および日付を含めることができる。他の入力変数も、図８に示されたものの他に、検討することができる。図８の変数は、本発明自体に対する制限または制約になることを意図されたものではない。
【００６６】
図９および１０を参照すると、本発明による、上で説明した推定エンジンによって実行することができる統計モデルおよび／またはベイズモデルによって提供されるものなどの例示的推定モデルが示されている。一般に、コンピュータシステムは、ユーザの状態の詳細に関して多少不確実になる可能性がある。したがって、ユーザの注意または他の状態に関する推定を不確実性の下で行うことができる確率モデルを構成することができる。ベイズモデルは、ユーザの注意のフォーカスの確率分布を推定することができる。そのような注意の状態は、プロトタイプ的状況のセットまたは、ユーザによって対処される認識の課題の別個のクラスのセットのより抽象的な表現として定式化することができる。その代わりに、注意のフォーカスの連続的測定に関する推定を行うモデル、および／または、異なるタイプの通知に関する中断のコストの確率分布を直接に推定するモデルを、定式化することができる。
【００６７】
ユーザのアクティビティおよび位置に関する観察のセットに基づいて代替アクティビティコンテキストまたは状態の確率を推定することができるベイズネットワークを、使用することができる。一例として、図９に、単一の時間期間に関するユーザの注意のフォーカスを推定するベイズネットワーク１５４を示す。変数である注意のフォーカス１５６の状態は、デスクトップコンテキストおよび非デスクトップコンテキストを指す。このモデルで検討される例示的な注意のコンテキストには、例えば、状況の意識、理解、特定でないバックグラウンドタスク、フォーカスを合わされた内容の生成または再検討、軽い内容の生成または再検討、文書のブラウジング、オフィスでの会議、オフィス以外での会議、プレゼンテーションを聞くこと、プライベートな時間、家族との時間、個人的フォーカス、くつろいだ会話および旅行が含まれる。ベイズネットワーク１５４は、ユーザの現在の注意および位置が、ユーザのスケジューリングされた面会１５８、時刻１６０、および締切期限の近接１６２によって影響されることを示す。ユーザの注意の確率分布は、例えばユーザのオフィスで監視される環境音響信号１６４の状況の要約による影響も受ける。環境音響信号１６４の経時的なセグメントが、アクティビティおよび会話の存在に関する手がかり／入力を提供する。ソフトウェアアプリケーションの状況および構成と、コンピュータと対話するユーザによって生成されたユーザアクティビティの進行中のストリームも、ユーザの注意に関する証拠のソースを提供する。
【００６８】
ネットワーク１５４に示されているように、オペレーティングシステムまたは他の環境で現在最上位のフォーカス（focus）にあるソフトウェアアプリケーション１６６が、ユーザのフォーカスおよびタスクの性質に影響し、ユーザの注意の状況およびフォーカスがあるアプリケーションが、一緒に、コンピュータセントリックアクティビティに影響する。そのようなアクティビティには、マウスアクションおよびキーボードアクションのシーケンスから作成されるユーザアクティビティのストリームと、より広い時間範囲にわたるアプリケーション使用の高水準パターンが含まれる。そのようなパターンには、電子メールセントリックおよびワードプロセッサセントリックが含まれ、そのようなパターンは、複数のアプリケーションがインターリーブされる形に伴うアクティビティのプロトタイプ的クラスを指す。
【００６９】
図１０に、異なる時間の期間でのコンテキスト変数の間のユーザの注意のフォーカスのベイズモデル１６８を示す。マルコフ時間依存性のセットが、モデル１６８によって示されており、この図では、コンテキスト変数の過去の状態が、ユーザの状態の現在の判定で考慮される。リアルタイムで、そのようなベイズモデル１６８によって、例えば、オンラインカレンダによって供給される情報と、イベント感知システム（図示せず）によって報告される部屋の音響およびユーザアクティビティに関する観察のストリームを検討し、ユーザの注意の確率分布に関する推定結果を提供し続ける。
【００７０】
図１１、１２、１３、１５、１７、および２１に、本発明によるコンテキストアナライザ、通知マネージャ、およびユーザインタフェースなどの、通知アーキテクチャの諸部分を提供する方法を示す。説明を単純にするために、方法を、一連の行為として図示し、説明するが、本発明に従って、一部の行為を、図示され本明細書で説明されるものと異なる順序でおよび／または他の行為と同時に行うことができるので、本発明が、行為の順序によって制限されないことを理解し、諒解されたい。例えば、当業者は、方法を、その代わりに、状態図など、相互に関連する一連の状態またはイベントとして表現することができることを理解し、諒解するであろう。さらに、示された行為のすべてが、本発明による方法の実施に必要とは限らない。
【００７１】
この方法は、いくつかの態様で、コンピュータ実施することができる。コンピュータ実施される方法は、少なくとも部分的にコンピュータで動作する１つまたは複数のプログラムとして、すなわち、コンピュータの処理システムによってメモリなどのコンピュータ可読媒体から実行されるプログラムとして、実現されることが望ましい。プログラムは、別のコンピュータへの配布とインストールと実行のために、フロッピー（登録商標）ディスクまたはＣＤ−ＲＯＭなどの計算機可読媒体に保管可能であることが望ましい。１つまたは複数のプログラムを、下で図２３に関して説明するものなど、コンピュータシステムまたはコンピュータの一部にすることができる。
【００７２】
図１１を参照すると、流れ図１７０に、本発明によるユーザのコンテキストの判定が示されている。この処理には、１７１でユーザの位置を判定することと、１７２でユーザのフォーカスを判定することが含まれる。これらの行為は、前に説明した手法の１つまたは複数によって達成することができる。例えば、プロファイルを使用することができ、ユーザが自分のコンテキストを指定することができ、コンテキストの直接測定を使用することができ、ルールのセットに従うことができ、ベイズモデルまたは統計モデルを介するなどの推定分析を実行することもできる。他の分析を使用して、ユーザのコンテキストを判定できることを諒解されたい。例えば、誰かがコンピュータの前にいる場合に気付き、その人がコンピュータを見ているか否かに気付く、一体化されたビデオカメラソースを設けることができる。しかし、本発明のシステムは、カメラの有無にかかわらずに動作できることに留意されたい。ソースのすべてについて、システムは、コンテキストに関する推定のために特定のソースを必要とすることなく、実質的に任意の数の使用可能な入力ソースと共に動作することができる。さらに、他の態様では、ユーザの位置および注意の感知を与える、小さいＰＤＡ上の一体化された加速度計、マイクロホン、および近接検出器を設けることができる。
【００７３】
図１２を参照すると、流れ図１７３に、本発明の一態様による通知マネージャの決定処理が示されている。１７４で、１つまたは複数の通知ソースが、通知を生成し、その通知が、通知マネージャによって受信される。１７５で、コンテキストアナライザが、ユーザに関するコンテキスト情報を生成／判定し、これが、１７６で、通知マネージャによって受け取られる。すなわち、本発明の一態様によれば、１７５で、この説明の前の節で説明したように、コンテキストアナライザが、ユーザの現在の注意の状況および位置を示すユーザのコンテキスト情報プロファイルにアクセスし、かつ／または、ユーザの現在の注意の状況および位置に関するリアルタイム情報を、１つまたは複数のコンテキスト情報ソースから査定する。
【００７４】
１７７で、通知マネージャが、コンテキストアナライザから受け取ったコンテキスト情報に部分的に基づいて、どの通知をどの通知シンクに伝えるかを決定する。通知マネージャは、コンテキストアナライザによって保管されるユーザの通知パラメータに関する情報に基づく決定も行う。すなわち、一態様によれば、１７７で、マネージャが、所与の通知に関してユーザに警告しなければならないかどうかと、ユーザにどのように通知するかに関する決定理論的分析を実行する。下で詳細に説明するように、決定理論および／またはヒューリスティックによる分析、決定、およびポリシを、１７７で使用することができる。ユーザに関する通知パラメータを使用して、欠けている値に書き込むことによってもしくはソースまたはシンクのスキーマで提供されるパラメータを上書きすることによって、分析をパーソナライズすることができる。通知プリファレンスも、決定理論的分析の代わりに使用されるポリシ（例えばヒューリスティック）を提供することができる。この判定に基づいて、１７８で、通知マネージャが通知をシンクに伝える。
【００７５】
本発明の様々な態様を、ここまでは、ユーザに適用可能なものとして説明してきた。しかし、本発明自体は、それに制限されない。すなわち、本発明は、ユーザを含む実質的にすべてのタイプのエンティティに適用可能である。他のタイプのエンティティには、例えば、エージェント、プロセス、コンピュータプログラム、スレッド、サービス、サーバ、コンピュータ、機械、会社、組織、および／または店が含まれる。例えば、エージェントは、ソフトウェアエージェントとすることができ、このソフトウェアエージェントは、一般に、ユーザのためにバックグラウンドタスクを実行し、タスクが終了するかなんらかの期待されたイベントが発生した時にユーザに報告するコンピュータプログラムとして定義することができる。他のタイプのエンティティを、当業者が諒解できるように、本発明の下に含めることができる。例えば、本発明のもう１つの態様によるコンテキストアナライザを、実質的にすべてのタイプのエンティティに適用可能なコンポーネントとして一般化することができる。もう１つの例として、通知シンクが、ユーザ以外のエンティティに関する通知、アラート、およびイベントを生成することができる。同様に、通知シンクが、ユーザ以外のエンティティに関する通知、アラート、およびイベントを受け取ることができる。
【００７６】
図１３に移ると、流れ図１８０に、本発明の一態様による通知マネージャによって実行することができる、決定理論的決定を示す。１８２で、１つまたは複数の通知を受け取る。通知によって、関連する通知シンクのモードを介してユーザに伝えることができる情報が提供される。１８４で、決定理論的分析を、複数のシンクの複数のモードに対して、１８２で受け取った通知に関して実行する。分析が、シンクに関連するモードを介して通知を伝えることの正味の価値をもたらすことが望ましい。分析は、ベイズネットワークなど、確率モデルを使用して実行することができる。
【００７７】
本発明の一態様によれば、１８４でのシンクのモードによって通知を伝えることの正味の価値の判定に、図１３の１８６、１８８、１９０、および１９２の実行が含まれる。１８６で、通知に含まれる情報の、ユーザにとっての期待価値を判定する。これは、ユーザが通知される場合にユーザに対して生じる情報の価値である。１８８で、通知を伝えることの中断のユーザにとっての期待コストを判定する。これは、通知を伝えるためにユーザを中断させるコストであり、例えば、ユーザが、会議で忙しく、通知によるユーザの中断が、ユーザにとってのコストをもたらす場合がある。１９０で、通知を実際には伝えられずに、その通知に含まれる情報をユーザが独立に知ることの期待価値を判定する。この価値は、１８６で判定される価値より小さい可能性がある。というのは、ユーザが、情報について通知された場合より後に、独立に情報を知る可能性があるからである。１８８で、ユーザに通知を通信することの実際のコストを判定する。例えば、ポケットベルを介してメッセージを送信することによって、ユーザのポケットベル会社からの、ユーザが負う通信料金がもたらされる可能性があり、そのようなポケットベルは、呼び出し単位でその会社によって請求される。
【００７８】
シンクのモードを介してユーザに通知を伝えることの正味の価値は、１８４で、１８６で判定された情報の期待価値から、１８８で判定された中断の期待コストと、１９０でのユーザが情報を独立に知ることの期待価値と、１９２の通信の実際のコストを引くことによって、判定することができる。１９４で、実質的にすべてのシンクの実質的にすべてのモードのいずれかの正味の価値が、所定の伝達閾値より大きいかどうかを判定する。例えば、正味の価値がドル単位（＄）で測定される場合に、所定の伝達閾値を０にすることができる。通知の正味の価値がシンクのモードの閾値より大きい場合には、この処理は、そのような通知について１９６に進んで、そのような通知を、通知に関する最も高い正味の価値を有するシンクのモードを介してユーザに伝える。そうでない場合に、実質的にすべてシンクの実質的にすべてのモードについて閾値を超える正味の価値を有しない通知に関して、ユーザは、現在、そのような通知に含まれる情報について通知されず、この処理は、そのような通知について１９８に進んで、後処理を実行するが、この処理は、１９６からもこの後処理に進む。
【００７９】
本発明は、１９８で後処理が実行される形によって制限されない。本発明の一態様によれば、１９６でユーザに伝えられる通知を、１９６が実行されたと仮定して、削除することができる。もう１つの態様では、そのような通知は、通知が伝えられた通知シンクから、ユーザが実際に通知を受け取ったことの確認を受け取った時に削除される。通知が伝えられる通知シンクが、使用されるシンクのモードに関して閾値より高い送信信頼性を有すると判定された場合にも、伝達の後に通知を削除することができる。さらに、図１３の処理を、所定のインターバルでおよび／または新しい通知が受け取られる時に繰り返すことができる。例えば、１８４で判定される通知の正味の価値が、時間依存である限り、伝達閾値より小さい正味の価値を有する可能性がある所与の通知が、後に閾値より大きい正味の価値を有し、伝えられる可能性がある。選言的な状況も、真である可能性がある。したがって、図１３に示された処理は、シンクのモードを介して通知をユーザに伝えなければならないかどうかを判定するために決定理論的分析を実行することができる形を示し、この分析を、望みに応じて繰り返すことができる。
【００８０】
図１３に示された処理が、複数の通知シンクの複数のモードに対する通知の決定理論的分析の実行に関して説明されたことに留意されたい。しかし、本発明自体は、これに制限されない。例えば、シンクのいずれかまたはすべてについて、そのようなモードを暗黙のうちに１つだけ設けることができる。この形で、通知の分析を、明示的にモードにかまわずに、シンクに対して実行することができる。さらに、注記したように、シンクのモードに関する通知の正味の価値の判定は、この説明の次の節で説明するように実行することができる。
【００８１】
本発明の特定の一態様によれば、この説明の前の節で提示した決定理論的通知を、以下の節で説明する形で実行することができるが、本発明はこれに制限されない。例えば、反復的な「貪欲な」決定理論的分析を使用することができる。分析中に、現在のコンテキストおよびアラート送信の関連する期待価値を、検討する。将来に関する推定を実行する、将来の時刻の範囲、コンテキスト、および関連する期待価値を検討する、より近似的でない、より正確な決定理論的分析で、動的ベイズネットワークまたは、隠れマルコフモデル（ＨＭＭ）と称する動的ベイズネットワークの近似などのモデルを使用することができる。そのような技法を使用して、将来の状態でコンテキストを「予測」する、より「近視眼的」でない分析に基づく通知決定を行うことができる。当技術分野では、近視眼的分析を、より豊かな、より近視眼的でない分析に一般化することが既知である。通知プラットフォームに関して、これらの「より貪欲でない」分析で、計算の追加の量が使用される。一態様の通知マネージャは、使用可能な計算リソースの状況の監視による、現在使用可能であるか使用可能になる、計算の検討に基づいて、より近視眼的でないモードにシフトすることができるように構成される。すなわち、本発明は、説明した貪欲な手法に制限されない。より近似的でなく、より貪欲でない、通知に関する理想的な時間およびデバイスの最適化では、将来のコンテキストおよびデバイス可用性の尤度を予測することによって、将来のコンテキストおよび関連するデバイスの可用性の範囲を検討することができる。
【００８２】
時刻ｔの通知Ｎの期待価値は、通知の現在の価値とみなすことができる。通知の情報的価値は、ユーザのコンテキストおよび知識に敏感であるとみなされる。コンテキストには、ユーザの位置および注意の状況、ユーザの目標、およびコンテキスト（例えば、ユーザが電子メールを開いたばかりである）などのコンテキスト情報が含まれる。コンテキストＣでの通知Ｎの初期価値は、通知が初めてソースによって生成された時のコンテキストでの通知の価値（例えば、ドル単位で測定することができる）から、ユーザがその情報にまだ精通していない確率を引いたものである。ユーザが情報に精通していない確率を、情報の新規性と称する。この確率は、情報のタイプおよび情報が配布される形などの証拠Ｅに基づく（例えば、新聞記事は、他のチャネルを介して経時的に知られるようになり、したがって、証拠に、新聞記事の要点とエイジ（age）とを含めることができる）。
【００８３】
既に０であることがわかっている情報の価値を検討する場合に、通知の価値は
【００８４】
【数１】
【００８５】
である。コンテキスト限定性の概念を、コンテキストＣでの価値を条件付け、コンテキストに基づく価値を査定することによって導入することができる。
【００８６】
【数２】
【００８７】
ある新しい時刻ｔに、通知を送信する価値が、価値の時間依存性に基づいて変化する可能性がある。
【００８８】
【数３】
【００８９】
価値関数を、アラートが通知マネージャによって送信または受信された時刻と現在時刻の間の時間差または遅延を引数としてとる時間依存関数によって表すことができ、ここで、遅延は、ｔ−ｔ0として表される。そのような関数には、例えば、価値の消失遅延を示す線形関数、指数関数、およびシグモイド関数を含めることができる。より複雑な関数に、情報の価値が変更される（例えば減衰を開始する）前の、価値が変化しない、アラートが送信されたか受信された時刻に続く、時間の期間を指す「貯蔵寿命（ｓｈｅｌｆ ｌｉｆｅ）」を表す関数などの、線形関数、指数関数、およびシグモイド関数の連結が含まれる。他の関数によって、ある遅れに伴ってアラートの価値を高めることができるという概念を取り込むことができる。
【００９０】
本発明の一態様によれば、コンテキストも変化し、新しい時刻に異なるという事実が考慮される。したがって、式（３）を、Ｃ（ｔ）を用いて書き直すことができ、あるいは、コンテキストを、常に現在のコンテキストとして示すことができる。コンテキストの不確実性の下で、異なる潜在的なコンテキストが合計される。したがって、情報の期待価値は、
【００９１】
【数４】
【００９２】
になる。これは、ユーザが、ある時刻ｔにコンテキストＣで通知のすべての内容を受信することの価値である。
【００９３】
デバイスのモードＭを用いて情報を通信することの期待価値は、レンダリングに関連する忠実度の消失およびコンテキストＣでモードＭを用いてシグナリングされた時に情報がユーザに送信されたかどうかの検討によって、減らされる。単純にするために、送信の忠実度が、内容の送信なしの０から内容の完全な送信の１までの範囲にわたる変数として取り込まれると仮定することができる。本発明の他の態様によれば、初期内容の１つまたは複数のコンポーネントをドロップすることの損失の追加の詳細と、様々な形での内容の切捨および要約（例えば、電子メールメッセージのテキスト全体のあるパーセンテージの切捨、または、携帯電話の限られたディスプレイでの表示のためのより小さくよりコンパクトなメッセージへの要約の別の手法）を取り込む、より詳細な有用性モデルが検討される。一般的な場合に、デバイスのモードＭでの情報の送信に関連する忠実度は、コンテキストに依存する。例えば、雑音の多い環境では、オーディオ内容のオーディオ部分を聞き取ることが困難になる可能性がある。
【００９４】
情報がユーザに送信される確率も、考慮することができる。これは、一般的な場合に、やはりコンテキストに依存する。この依存性は、通常は忠実度のコンテキスト依存性より顕著なので、これを明示的に指定することができる。ユーザが情報を受信した確率としての情報の送信は、ｐ（ｒｅｃｅｉｖｅｄ｜Ｍ，Ｃ，Ｅ，ｅ）として表され、ここで、ｅは、例えば一時停止、マウスオーバー、対話などの、ユーザの通知に対する応答に関する追加の証拠を表す。
【００９５】
次に、通知の通信の期待価値は、
【００９６】
【数５】
【００９７】
として決定される。式（５）の通信の期待価値が、通知の情報の期待価値に関して記述されることに留意されたい。これは
【００９８】
【数６】
【００９９】
に類似する。一態様で、式（５）および（６）で実施される通信の期待価値を、この説明の前の節で説明したユーザにとっての情報の期待価値として使用することができる。その代わりに、情報の期待価値を、忠実度および他のパラメータ考慮なしの期待される値すなわちＥｘｐＶａｌＩｎｆｏ（Ｎi）とすることができる。しかし、本発明は、これらの手法に制限されない。
【０１００】
次に、情報のコストを検討する。中断に関連するコストは、ほとんどはユーザの注意のコンテキストを介して送信のモードおよびコンテキストに依存する。各コンテキストのユーザの中断の期待コストは、一態様ではドル単位で測定することもでき、モードＭを介する情報の送信に関連する中断を避けるためにユーザが支払うつもりがある金額に等しい。一般的な場合に、これは、送信される内容の詳細にも依存する。しかし、一態様によれば、コンテキストの不確実性の下での異なるコストが、特に検討される。したがって、モードＭの中断の期待コストは、
【０１０１】
【数７】
【０１０２】
である。モードＭを介する通知を用いて今ユーザにシグナリングすることの価値は、情報の価値とコストの間の差である。例えばサービスによって請求される料金ごとのビットを送信するコストなどの、実際の通信のドル単位のコストも、検討される。これは、通知内容および選択されたモードの関数になる可能性がある。これを、（実際の）通信コストＣｏｍＣｏｓｔ（Ｎ，Ｍ）とも称する。
【０１０３】
次に、ユーザが通知によって能動的にシグナリングされないが、ユーザが、後に情報を再検討する暇ができた時に情報を受け取る、電子メールストアまたは、一般的な目的に関して、ユーザが再検討する機会を得るまで維持される潜在的な通知のストアなどのストアから情報を能動的に検索することができる場合に（正味の）価値が０でないとみなすことができる。これを、ユーザが通知なしで情報を独立に知ることの期待価値としてこの説明の前の節で言及した、通知に含まれる情報を探すことの期待価値ＥｘｐＶａｌＳｅｅｋと称する。この値は、ユーザが通知に含まれた情報を再検討するまでの時間を考慮することによって判定することができる。この時間は、通常は、例えばユーザがそのようなストアから情報を検索するまでの時間が、位置、時刻、および現在の注意のフォーカスに依存する可能性があるので、通常はコンテキスト応答的である。情報の新規性が、変化する可能性があり、通知が保留された時間の長さの関数になる可能性があることを考慮されたい。簡単にするために、忠実度は、ユーザが情報を検索する時に最大とみなすことができるが、一般的な場合に、ユーザは、より低い忠実度を提供するデバイスを介して情報を検索する可能性がある。また、情報検索に関連する中断のコストは、ユーザが情報を能動的に追跡する注意の状態にあるので、約０であると仮定することができる。
【０１０４】
したがって、
【０１０５】
【数８】
【０１０６】
である。通知の時刻と検索されるまでの時刻の間の待ち時間の判定に関して、式（８）を実施し、判定する手法が複数存在することに留意されたい。一態様では、ｔがポアソン分布で分布し、検索の時間が、分析の時刻からユーザが通知を再検討するまでの（メモリレス）平均時間であると仮定することができる。待ち時間は、その時刻と通知の時刻の間の差として判定することができる。さらに、ベイズネットワークまたは他の確率モデルを使用して、電子メールまたはより一般的な通知ストアを再検討する異なる平均時間に関する確率分布を推定することができる。上で説明したように、ベイズネットワークまたは他の確率モデルを使用して、ユーザの注意のフォーカス、位置に関する確率分布を判定することもできる。
【０１０７】
したがって、モードＭでの通知Ｎの通信に関する、通知の通信の期待価値ＮｅｔＥｘｐＶａｌＣｏｍは、
【０１０８】
【数９】
【０１０９】
である。これは、この説明の前の節で正味の価値と称したものである。
【０１１０】
意思決定に関して、やってくる通知に関して、実質的にすべてのデバイスの実質的にすべてのモードＭについて、ＮｅｔＥｘｐＶａｌＣｏｍを検討する。最大の正のＮｅｔＥｘｐＶａｌＣｏｍを有するデバイスが検討される（すなわち、＄０の所定の伝達閾値を仮定する。というのは、この項が、この説明の前の節で表されたからである）。ＮｅｔＥｘｐＶａｌＣｏｍが、複数のデバイス（例えば通信シンク）について正である場合には、最大の価値を有するデバイスを選択し、そのデバイスを用いてユーザに信号を送る。実質的にすべてのデバイスの実質的にすべてのモードについて値が負である場合には、通知を延期することができ、後の再検討のためにジャーナリングすることができる。通知をレンダリングすることの価値は、一態様では再検討され続けるが、これは、時間と共に変化する変数を更新することによる。これには、現在時間、ユーザが自分の電子メールまたは、より一般的には自分の通知ストアを再検討するまでの期待される時間、および現在のコンテキストおよび情報の新規性などの変数が含まれる。そのような再検討は、この説明の前の節で説明した後処理の一部として実行することができる。
【０１１１】
現在対過去に関するこの反復推定が、本発明の特定の一態様で実行されるタイプの決定理論的分析であることに留意されたい。これは、貪欲な意思決定戦略である。しかし、将来の時刻でのアクティブな通知の価値およびコストを検討する、多少複雑な予測モデルに頼るより貪欲でない戦略を定式化することができる。例えば、確率モデルを使用して、ユーザの将来の注意の状態を予測することができ、そのような予測を、ますます貪欲でなくなる形の推定に使用することができる。
【０１１２】
さらに、１回シグナリングした後であっても、いくつかの態様では、通知が即座に破棄（すなわち削除）されない。例えば、通知がレンダリングされた後に、その通知がユーザに届いたかどうかを保証することは、通常はできない。しかし、システムが、例えば、ユーザがデスクトップシナリオでレンダリングされた通知の上でカーソルをホバーさせることが、ユーザがシステムに「これを受け取った」ことを示す形であることの、ユーザとシステムの間の共有される理解などの処理が実施されている場合、または他の形で通知のアクセスを自動的に監視することによって、そのような保証が可能になる。後者の例が、ユーザが自分の携帯電話でメッセージを調べたかどうかを監視することである。そのような監視の報告を、この説明の前の節で注記した、通知受信の確認とすることができる。
【０１１３】
シンクのモードは、そのコンテキストでのモードのコンテキスト応答送信信頼性（ｔｒａｎｓｒｅｌとも称する）ｔｒａｎｓｒｅｌ（Ｍ，Ｃ）を有するとみなされる。すなわち、そのモードについて、およびそのコンテキストについて、送信信頼性によって、ユーザがそのレンダリングに基づいて通知を観察した確率が与えられる。注記したように、時々、ｔｒａｎｓｒｅｌが１．０であることの確認が受け取られる可能性があり、例えば、通知との対話または通知のマウスオーバーによって、ユーザが１．０の確率で通知を観察したことになる。他の時には、モードおよびコンテキストの送信信頼性に頼ることができる。
【０１１４】
ユーザが各通知の情報を受け取った尤度ｐ（ｒｅｃｅｉｖｅ）は、各送信の後に更新される。ＨA（Ｎi）は、一般に、内部のインボックスで保留されている特定の通知の警告ヒストリを指す。警告ヒストリは、試みられた通知のシーケンスを示し、
【０１１５】
【数１０】
【０１１６】
である。Ａ（Ｎi，Ｍ）は、モードＭでの通知Ｎiに関するアラートを指す。通知ヒストリを与えられれば、現在の通知の新規性ｐ（ｎｏｔｉｆｉｃａｔｉｏｎ ｕｎｓｅｅｎ｜ＨA，Ｅ，ｅ）を判定することができる。この要因を含めることによって、通知を見ることの期待価値が適当に減らされる。
【０１１７】
具体的に言うと、まず、更新されたＥｘｐＶａｌＣｏｍおよびＥｘｐＶａｌＳｅｅｋが、
【０１１８】
【数１１】
および
【０１１９】
【数１２】
【０１２０】
になる。次に、前と似た形であるが、これらの新しいＥｘｐＶａｌＣｏｍおよびＥｘｐＶａｌＳｅｅｋＩｎｆｏの値を用いて、ＮｅｔＥｘｐＶａｌＣｏｍを判定する。したがって、
【０１２１】
【数１３】
【０１２２】
である。
【０１２３】
さらに、通知の新規性ｐ（ｎｏｔｉｆｉｃａｔｉｏｎ ｕｎｓｅｅｎ｜ＨA，Ｅ，ｅ）が、一般に更新される。本発明の一態様によれば、これは、アラートでの新しい試み（通知レンダリングまたは通知の伝達）が行われた後に、これから説明するように、例えば二項試行として試みを検討することによって判定することができる。警告ヒストリが、
ＨA（Ｎi）：｛Ａ1（Ｎi，Ｍ，Ｃ（ｔ1）），Ａ2（Ｎi，Ｍ，Ｃ（ｔ2）），Ａ3（Ｎi，Ｍ，Ｃ（ｔ3）），．．．Ａn（Ｎi，Ｍ，Ｃ（ｔn））｝
であるものとすると、通知の新規性は、
【０１２４】
【数１４】
【０１２５】
になる。
【０１２６】
また、同時通知のセットを含む通知セットを検討することによって、通知をチャンクにすることができる、すなわち、所与の通知シンクの所与のモードを介する通知のグループ化として送信について一緒にグループ化することができることにも留意されたい。
【０１２７】
【数１５】
【０１２８】
したがって、通知の価値およびコストの要約が検討され、１つの中断のペナルティが予期される。
【０１２９】
この説明のこの節では、前の節で説明した本発明の諸態様に対する様々な拡張を提示する。まず、一態様で、決定理論的ポリシをより単純なルールおよびポリシに編集し、かつ／または近似することができることに留意されたい。これには、そのような決定理論的分析をポリシに編集する形式的方法を使用することができる。さらに、下で詳細に説明するように、例えばより粗い費用便益分析を実行する、ヒューリスティックポリシなどの様々なポリシがある。
【０１３０】
さらに、決定理論的ポリシは、「情報をプルする」情況に使用することができる。すなわち、ユーザが、デスクトップならびにモバイルの情況中の要求を含めて、システムに情報を要求する時に、０になる気を散らすコストが検討され、情報を、ユーザに送信される次の最も価値のある通知に関して関係させることができる。そのような情報は、次の最も高い価値によって順序付けることができ、あるいは、認識のためにカテゴリにグループ化することができる。例えば、次の「ｎ」個の最も価値のある通知を検査し、コマンドが、この順序で通知をストリーム化するように関係させることができ、あるいは、期待される有用性の順序での「次の通知」の要求を待つことができる。
【０１３１】
その代わりに、情報を、例えば最高の期待される有用性を有する通知を含むソースの順序に基づいて、ソースのカテゴリに関して関係させることができる。通知の中継は、次の最高の値を有する通知を含むソースに移動する前に期待価値の閾値に達するまでソースカテゴリ内で継続することができ、その後、この処理を繰り返す。その代わりに、情報を、ソースの事前に定義された順序付け（例えば、音声メールメッセージが最初、インスタントメッセージがその次、電子メールがその次、その後に財務通知）によって中継することができ、その後、そのカテゴリについて期待される有用性の閾値に達するまで、カテゴリ内の期待される有用性によってソートされた、ソースのそれぞれからの通知を中継し、その後、さらに進行することができる。
【０１３２】
情報の期待価値を使用して、現在の情況の高水準の要約を調整することができる。例えば、携帯電話を介する現在の通知情況の通信のために、保留中の通知のテキスト−音声要約を作成するための、ソースにまたがる推定を設けることができる。さらに、期待価値の判定を使用して、キャッシングを達成することができる。期待価値の判定を使用して、例えば、モバイル設定およびデスクトップ設定でのダイアログを機能強化するために、ユーザが、最高の期待価値のアイテムに最も関心を持つと仮定することによって、よりよく聞き取るために音声認識システムに情報を与えることもできる。
【０１３３】
さらに、説明した本発明のもう１つの拡張は、ソースカテゴリ内の期待価値のセットを使用して、要約を調整できることである。そのような要約は、各ソースの通知の情況の概要を中継するための永続的要約に現れることができる。例えば、電子メール要約は、次のようになる可能性がある「３２ ｕｎｒｅａｄ ｍｅｓｓａｇｅｓ；９ ｏｆ ｈｉｇｈ ｕｒｇｅｎｃｙ；ｍｏｓｔ ｕｒｇｅｎｔ ｆｒｏｍ Ａｎｄｙ ｏｎ‘Ｍｅｅｔｉｎｇ ｔｈｉｓ ａｆｔｅｒｎｏｏｎ．’（３２個の未読メッセージ、９個の高緊急性、最も緊急のメッセージはＡｎｄｙからの「今夜の会議」）」。
【０１３４】
ヒューリスティック通信の決定およびポリシは、通知マネージャによって実行することができるが、これを本発明に従って説明する。例えば、より形式的な決定理論的分析をバイパスする、粗費用便益分析を利用することができる。そのようなポリシおよび関連する通知コンポーネントおよび通知インタフェースは、決定理論的ポリシの近似版またはヒューリスティック版とみなすことができる。この手法では、通知に、ソースによって、またはユーザ指定の通知プロファイルによって（例えばメッセージの属性および／またはメッセージクラスごとに）、高緊急性、中緊急性、低緊急性（または任意の範囲の緊急性）としてラベルを付けることができる。ユーザが通知を受け取る状態である可能性が高い時に関する条件のリストを作成することができ、コンテキストの粗な監視を実行して、ユーザが最小の中断で通知を受け取る暇がある可能性が高い状況を識別する。これらの状態を、「おそらく自由な（ｌｉｋｅｌｙ ｆｒｅｅ）」状態と呼ぶ。
【０１３５】
このリストには、下記の１つまたは複数（および他の状態）を含めることができる。
【０１３６】
・ユーザが、存在し、入力し、ｘ秒だけ入力を一時停止した
・ユーザが、ファイルを保存し、ｘ秒だけ一時停止した
・ユーザが、電子メールを送信し、ｘ秒だけ一時停止した
・ユーザが、アプリケーションを閉じた
・ユーザが、あるアプリケーションから別のアプリケーションに切り替えた
【０１３７】
また、緊急性レベルについて最大延期時間をセットすることができる。例えば、内部的に、例示的なテーブルに、下記をセットすることができる。
【０１３８】
・最大延期（高優先順位）：２分
・最大延期（中優先順位）：７分
・最大延期（低優先順位）：１５分
【０１３９】
これは、ユーザがセットすることができ、その代わりに、デフォルト動作についてシステム開発者がセットすることができ、このデフォルトは、ユーザが修正できる場合もそうでない場合もある。
【０１４０】
さらに、ユーザは、例えば即座にパススルーを受信するものとして例外または緊急事態をリストすることができる。
【０１４１】
下記は、本発明の一態様による例示的アルゴリズムである。
【０１４２】
・通知を受信した時に、そのエイジに０をセットし、優先順位を注記し、例外のリストを検査する。
・その緊急性の最大延期時間の前にユーザのアクティビティの監視を介して自由状態が観察される場合に、通知をユーザにパススルーする。
・そうでない場合に、通知の最大自由状態に達する時に、通知を中継する。
【０１４３】
平均して、ほとんどの通知が、一般に、最大延期時間の前に配送される。しかし、ユーザは通常、通知を受信する時に通知が単純にパススルーされた場合に、それまでより自由である時にそれが発生する傾向を有するので、よりうれしいだろう。したがって、自由状態に達する確率は、時間と共に増加する。おそらく自由な状態である確率が、時間の増加に伴って高まるので、低優先順位のメッセージは、おそらく自由な状態中により高い尤度で発生する傾向があり、中断の確率が、メッセージの優先順位が上がるにつれて高くなる。
【０１４４】
この手法は、次のように一般化することができる。一態様によれば、複数のまたはポーリングされた待っている通知を含めるために通知の表示をイネーブルして、ユーザに、グループ化された通知のチャンクを含む単一の通知を送ることができる。そのようなチャンク化では、例えば最大優先順位、最大エイジ、またはグループによる最大優先順位によって順序付けられたリストで通知のチャンクを提示することができる。例えば、おそらく自由な状態が見られず、高優先順位の通知の最大延期時間に達した場合に、高優先順位の通知の最大延期に達した時に、グループ化された通知内で保留されている低優先順位通知に関する情報が含められる。これは、低優先順位の通知がこの時にそれ自体の最大延期に達していない場合であってもこうなる。
【０１４５】
さらに、優先順位の少数のカテゴリの代わりに、緊急性スコアに関して、例えば０〜１００の連続的な範囲をイネーブルすることができ、最大延期を、様々な線形関数および非線形関数（例えば増加する優先順位に伴う最大延期時間の指数関数的減衰）を含む通知の優先順位の関数にすることができる。例えば
【０１４６】
最大遅延（優先順位）＝ｅ-k(優先順位)×１５分
または
最大遅延（優先順位）＝ｅ-k(優先順位)×最大遅延（０優先順位）
である。
【０１４７】
自由時間の確率は、ユーザの次のｘ分以内に習得することができる。これは、おそらく自由な状態の頻度と、次のおそらく自由な状態までの期待される時間を習得することによって達成することができる。次のおそらく自由な状態までの時間は、ユーザのアクティビティから判定することができ、ユーザが、最大延期時間の代わりに、ユーザが妨害される優先順位クラスの確率を指定できるようにするために、通知優先順位クラスの最大延期時間を自動的にセットすることができる。すなわち、ユーザは、優先順位クラスの中断のターゲット「許容される確率」を指定することができ、システムが、このクラスの最大延期時間をセットすることができる。すなわち、ユーザ（またはその代わりに、デフォルトでシステム開発者）が、例えば「高優先順位通知について中断の０．５の確率、中優先順位メッセージによる中断の０．２５の可能性、低優先順位通知に関する妨害の０．０５の可能性を許容するなどの形で通知システムを構成する。
【０１４８】
下で、本発明の態様によるユーザインタフェースの概要を示す。そのようなインタフェースの例が、図１４に示されており、この図では、コンピュータのディスプレイ（例えば、ラップトップコンピュータ、デスクトップコンピュータ、または他のディスプレイ）のデスクトップスクリーン３００内に、所定の領域３０２（例えば、出力の表示および／またはユーザ対話の提供のための）が設けられている。図１４からわかるように、所定の領域３０２は、スクリーン３００の右上にあるが、スクリーンの他の領域（例えば、左下、右など）を使用することができることを諒解されたい。例えば、この説明で後で説明する本発明のストリームスタッキング態様では、領域３０２を、スクリーン３００の右側の列とすることができる。スクリーン３００は、グラフィックユーザインタフェースで使用されているように、その上でユーザがカーソルカーソル３０４の移動を制御できるものであることが望ましい。図１４に示されたカーソル３０４は、矢印ポインタであるが、他のカーソルを使用することができることを諒解されたい。
【０１４９】
所定の領域３０２を、本発明の様々な態様に関連する表示に関連して使用することができる。本明細書で使用される情報は、単一の情報および／または複数の情報を指すことができる。本発明の一態様によれば、情報には、上で説明してきた、アラートまたは通知とも称する通知アラートが含まれる。したがって、本発明の様々な態様は、下で説明するデスクトップスクリーン３００の所定の領域３０２内でのそのような情報の表示を対象とする。一態様では、デスクトップスクリーン３００を、例えばワードプロセッシング文書、スプレッドシートワークブック、または他のアプリケーションを操作するなど、主要な作業にユーザが使用することができる。
【０１５０】
しかし、領域３０２内に表示される情報を、主要な作業に関連しないものとすることができる。一例として、表示される情報を、ユーザによって要求されたものでない情報とすることができる。例えば、ユーザが、自分に伝えられる所定の分類閾値を超える（例えば、重要性に従って分類された情報）電子メールを要求したが、電子メールを領域３０２に表示することを要求しなかった（「非要求」とも称する）場合に、情報によって、電子メールについてユーザに警告することができる。
【０１５１】
スクリーン３００は、例えばハイパーテキストマークアップ言語（ＨＴＭＬ）フォーマットに従ってフォーマットされた内容を含む、一般化されたレンダリングを提供することができる、ディスプレイの部分とすることができる。さらに、情報の複数のソースが、ボタン、リンク、アニメーション、オーディオなどを含む「リッチ」インタフェース（例えばソースブランディング（ｓｏｕｒｃｅ ｂｒａｎｄｉｎｇ））を送信することができ、情報が、本明細書に記載のユーザインタフェースの制約および高水準設計規約またはスタイル規約の中でレンダリングされる。しかし、本発明は、これに制限されない。
【０１５２】
この説明の以下の節では、本発明のパルシング態様、本発明のストリームサイクリング態様、および本発明のストリームスタッキング態様を説明する。これらは、それによって情報を例えばデスクトップスクリーン３００の所定の領域３０２に表示できる特定の一態様である。以下の節では、これらの態様の少なくとも１つの例を示すが、本発明自体が、これらの例に制限されないことに留意されたい。さらに、ユーザがモードの間で切り替えることができる、パルシングモード、ストリームサイクリングモード、およびストリームスタッキングモードの組合せがありえる。例えば、システムに、ディスプレイ、処理システム、および、システムによって実行される時にモードの１つに入らせるコンピュータプログラムが保管された計算機可読媒体を含めることができる。
【０１５３】
ユーザがモードを切り替えることの代わりに、一態様では、上で説明した通知マネージャが、例えば、切替の決定を実行することができる。ユーザまたは通知マネージャは、一態様で、パルシングモード、ストリームサイクリングモード、および／またはストリームスタッキングモードなど、所与のモード内で切り替え可能な特徴に関する決定も行うことができる。音声告知の有無も、一態様では、ユーザおよび／または通知マネージャに委譲された決定とすることができる。
【０１５４】
図１５を参照すると、本発明によるパルシング態様の方法４００の流れ図が示されている。４０１で、情報を受け取る。前に説明したように、情報は、ユーザの主要な作業に関係しない非要求情報である場合がある。情報には、例えば、所定の閾値によって定義される閾値より大きい重要性の値を関連付けられるなど、割り当てられた分類を有する通知アラートを含めることができる。重要性の値の測定は、本発明によって制限されず、閾値によっても制限されない。
【０１５５】
４０２で、情報を、ディスプレイの所定の領域にフェードインさせる。一態様では、情報を所定の領域に表示し、所定の領域に表示される情報のアルファ値（例えば表示画素に関連する輝度値）を、所与の速度で第１の所定のレベルまで増分することによって、情報をフェードインさせる。第１の所定のレベルは、重要性の値によって定義される情報の重要性に基づくものとすることができる。例えば、レベルは、情報の重要性に比例するものとすることができる。情報のアルファ値を増やすことによって、所定の領域での情報の表示の不透明度が増える。したがって、アルファ値を、情報の重要性に基づくレベルまで増やすことは、より重要な情報が、より重要でない情報より大きい不透明ですなわち、より低い透明度で表示されることを意味する。しかし、一態様では、所定のレベルが、１００％未満すなわち、１００％不透明ではない。さらに、所定の領域にフェードインされる情報についてユーザに警告する音声告知を、４０２で再生することもできる。音声告知は、所定の１つまたは複数のサウンドとすることができ、情報の重要性値を、サウンドの様々な態様に関連付けることができる（例えば、重要性に基づいて大きくなるか小さくなる音量、重要性に基づくサウンドの数の増減）。
【０１５６】
４０４で、情報の重要性に基づく時間の長さに関する遅延がある。例えば、時間の長さを、情報の重要性に比例するものとすることができる。したがって、遅延は、情報がユーザに表示される時間の長さであることが好ましい。したがって、より高い重要性を有する情報を、重要性の低い情報より長く表示することができる。一態様では、遅延される時間の長さの間に、処理４００の４０６、４０８、４１０、および４１２が実行されるが、本発明自体は、これに制限されない。
【０１５７】
４０６で、ディスプレイの所定の領域への情報のフェードに関連する第１の所定のユーザジェスチャを検出する。例えば、この第１ジェスチャは、ディスプレイの所定の領域の上へのカーソルの移動（例えば、ユーザが、マウスなどのポインティングデバイスの使用を介してそのような移動を引き起こすことによる）とすることができるが、本発明自体はこれに制限されない。もう１つのジェスチャに、検出される、ユーザによる特定の言語または音声を含めることができる。第１ジェスチャに応答して、４０８で、第１アクションを実行する。一態様では、アクションに、所定の領域に表示される情報のアルファ値を、第１の所定のレベルより高い、１００％などの第２の所定のレベルまで増やすことが含まれる。したがって、第１ジェスチャによって、情報をより不透明にすることができる。もう１つの態様では、第１ジェスチャに応答して、４０８で、ディスプレイの所定の領域により詳細な情報（例えば、アラートに関連するなど）を表示する。
【０１５８】
４１０で、ディスプレイの所定の領域への情報のフェードに関連する第２の所定のユーザジェスチャを検出する。例えば、この第２のジェスチャは、カーソルがもはやディスプレイの所定の領域の上にない（例えば、ユーザが、マウスまたはキーボードの移動などのポインティングデバイスの利用を介してそのような移動を引き起こすことによって）ように、ディスプレイの領域へのカーソルの移動とすることができる。もう１つのジェスチャは、検出される、ユーザによる特定の音声の発音が含まれる。第２ジェスチャに応答して、４１２で、第２アクションを実行する。このアクションに、所定の領域に表示される情報のアルファ値を、前に４０８で調整された第２の所定のレベルから、第１の所定のレベルに減らすことを含めることができる。本発明のもう１つの態様によれば、４０８でディスプレイの所定の領域に表示された可能性があるより詳細な情報を、前に４０２でそこにフェードされた情報に置換する。
【０１５９】
４１４で、４０４の遅延が経過した時に、情報をディスプレイの所定の領域からフェードアウトさせる。例えば、一態様では、これに、所定の領域に表示される情報のアルファ値を所定の速度で減らし、その後、所定の領域にその情報をそれ以上表示しなくすることが含まれる。４１６によって示されるように、４００に示された処理を繰り返すことができる。すなわち、新しい重要性を有する可能性がある新しい情報を４０１で受け取ることができ、新しい情報を、４０２でディスプレイの所定の領域にフェードインさせる。一態様では、所定の領域へのフェードインおよびフェードアウトが、諒解可能であるように、所定の領域に既に表示されているすべてのものが、そこにとどまるものであることに留意されたい。すなわち、所定の領域にフェードインされる情報は、既にそこにあるものの上に表示され、フェードインされる情報のアルファ値のレベルが増やされ、したがって、フェードインする情報がどれほど透明または不透明であるかが決定され、したがって、情報のどれだけをユーザが観察できるかが決定される。情報（スペース内に完全に伝搬してはいないが）を、部分的に観察することができる。
【０１６０】
図１５で説明した処理は、情報が、アラートまたは通知の分類（例えば重要性の値）に関連する決定された時間の間に決定されたアルファに「パルス」されるので、パルシング態様と称する。これを、図１６に関して示すが、図１６では、本発明の態様による、そのようなパルス５０２の図５００が示されている。パルス５０２は、所定の領域に表示される情報がそこまで増やされるアルファ値レベルを表す高さ５０６と、情報がこのアルファ値レベルで所定の領域に表示される時間の長さを表す長さ５０４と、情報がこのアルファ値レベルまでフェードされる速度を表す第１勾配５０８と、情報がこのレベルからフェードされる速度を表す第２勾配５１０を有する。一態様では、高さ５０６と長さ５０４が、パルスされる情報の重要性に基づく（例えば、一態様では、高さが重要性値に比例する）。一態様では、第１勾配５０８および／または第２勾配５１０が、定数であるが、本発明自体は、これに制限されない。さらに、勾配５０８および５１０を、互いに類似するものとすることができる。
【０１６１】
本発明の一態様では、タブ、ボタン、および／または他のアイテムがディスプレイ上にあり、これらのアイテムを選択することによって、ユーザが即座に次の通知の表示を引き起こすことができる。例えば、ボタンのクリックが、次の通知がそれ自体の表示の重要性値または閾値に達していない場合であっても、ユーザが次の通知を見ることを望むことを示す。そのような通知は、例えば、独立の表示に関する閾値を超える重要性を有しない可能性がある。
【０１６２】
次に、図１７を参照すると、本発明によるストリームサイクリングの態様の方法６００が流れ図によって示されている。６０１で、それぞれの数の異なる情報パケット（例えば、通知ソースからの通知またはアラートに関連する情報）の関連表示時間が判定される。情報パケットに関する表示自己案は、この情報がディスプレイの所定の領域内で表示される時間の長さである。一態様では、時間の長さは、情報の重要度に基づき、それぞれの情報パケットに重要度値が割り当てられている。例えば、表示時間は、重要度に正比例することが可能である。ただし、本発明は、そのように限定されてはいない。さらに、前述した通り、情報は、ユーザの１次タスクに関係のない要求されていない情報であることが可能である。情報は、通知アラートを含むことが可能である。
【０１６３】
６０２で、一態様では（つまり、６０２はオプションである）、それぞれの情報パケットに関する周期が判定される。情報パケットに関する周期は、所与の期間中にディスプレイの所定の領域内で情報が表示される回数である。例えば、周期は、分類に基づき、所定のプロトコル（例えば、その分類に関連する比例関係）に従って表示されることが可能である。一態様では、周期は、情報の重要度に基づき、例えば、重要度値に正比例することが可能である。したがって、所与の期間中、より重要な情報をそれほど重要でない情報より頻繁に表示することが可能である。６０２が行われない本発明の一態様では、それぞれの情報パケットは、ほぼ１に等しい、つまり、各情報を所与の期間中に１回、表示することができる周期を有することが可能である。
【０１６４】
６０４で、所与の期間中、それぞれの情報パケットが、その情報パケットの表示時間にほぼ等しい時間の長さにわたり、その情報パケットの周期にほぼ等しい回数、ディスプレイの所定の領域内で表示される。したがって、第１の情報パケットが表示され、次に第２の情報パケットが表示され、その所与の期間中にすべての情報が表示されるまで、以下同様に表示が行われることが可能である。一態様では、それぞれの情報が、説明の前の節で述べた通り、表示時間にほぼ等しい遅延を挟んで所定の領域内にフェードインし、次にフェードアウトすることが（例えば、アルファ値を上げ、遅延を行い、次にアルファ値を下げることによって）可能である。本発明のそのような態様によれば、情報パケットのアルファ値が上げられる第１の所定のレベルは、前述した通り、情報の重要度に基づくことが可能である。つまり、アルファ値は、結局、表示時間にほぼ等しい時間の長さにわたって第１の所定のレベルに設定される。一態様では、表示されるそれぞれの情報に対してユーザの注意を喚起するオーディオ通報が流される、または別法では、所定のしきい値などのしきい値を越える情報に関してオーディオ通報が流される。オーディオ通報は、前述した通り、所定の１つまたは複数の音であることが可能である。一態様では、所定の期間中（特に本発明が限定されない）、プロセス６００の６０６、６０８、６１０、および６１２が行われる。ただし、本発明自体は、そのように限定されない。
【０１６５】
６０６で、ディスプレイの所定の領域内で表示されている現行の情報パケットに関係のある第１の所定のユーザジェスチャが検出される。例えば、第１のジェスチャは、表示の所定の領域上におけるカーソルの動き（例えば、マウスなどのポインティングデバイスの利用を介してそのような動きを生じさせるユーザによる）であることが可能である。別のジェスチャには、検出され、および／または処理される、ユーザによる特定の発話または音声が含まれることが可能である。第１のジェスチャに応答して、６０８で、第１のアクションが行われる。一態様では、アクションには、所定の領域内で表示されている現行の情報を「保持」して、第２のジェスチャが６１０で検出されるまで、所定の領域内で他の情報が実質的に全く表示されないようにすることが含まれる。
【０１６６】
つまり、実質的に、現行の表示される情報の表示時間が、一時的に増加され、所与の期間が、第２のジェスチャが６１０で検出されるまで、所定の領域内で現行の情報が保持されている間の時間の長さに等しい時間の長さに増加される。別の態様では、６０８で行われる第１のアクションには、例えば、１００％といった第１の所定のレベルより大きい第２の所定のレベルに、所定の領域内で表示される現行の情報のアルファ値を増大させることが含まれる。そのような態様では、第１のジェスチャは、これにより、表示される現行の情報が、より不明瞭になるようにする。別の態様では、第１のジェスチャに応答して、６０８でディスプレイの所定の領域内でより詳細な情報（例えば、アラートに関連する）が表示される。
【０１６７】
６１０で、ディスプレイの所定の領域内で表示される現行の情報に関係のある第２の所定のユーザジェスチャが検出される。例えば、この第２のジェスチャは、カーソルがもはやディスプレイの所定の領域上にないようにディスプレイのある領域にカーソルを動かすこと（例えば、マウスなどのポインティングデバイスの利用を介してそのような動きを生じさせるユーザによる）であるのが可能である。別のジェスチャは、認識されるユーザの特定の発話である。第２のジェスチャに応答して、６１２で、第２のアクションが行われる。一態様では、第２のアクションには、所定の表示領域内で前から「保持」されていた現行の情報を「解放」して、所定の領域内で後続の情報を引き続き表示することができるようにすることが含まれる。アクションには、所定の領域内で表示される情報のアルファ値を６０８で前に増大させた、または設定した第２の所定のレベルから第１の所定のレベルまで再び低減することが含まれるのが可能である。別の態様では、６０８でディスプレイの所定の領域内で表示されている可能性があるより詳細な情報が、６０２で前に表示されていたのと同じ情報で置き換えられる。
【０１６８】
６１４で、実質的にすべての情報が６０４で表示される所与の期間が経過した後、情報が更新される。例えば、６１４には、新しい情報を追加すること、および古い情報を削除することが含まれるのが可能である。情報の削除は、例えば、最低の優先順位の情報、所定の回数、既に表示された情報等に基づくことが可能である。同様に、追加される新しい情報には、情報の重要度に関連する所定のしきい値を超える重要度の情報が含まれることが可能である。次に、６１６によって示される通り、図１７のプロセス６００が繰り返される。したがって、６０１で、更新されたそれぞれの情報パケットに関する新しい表示時間が決定される。
【０１６９】
図１７のプロセス６００に関連して説明する本発明の態様は、ストリームサイクリングと呼ばれる。というのは、情報が、「ストリーミング」される、すなわち、所与の期間中、第１の情報が所定の領域内で表示され、次に、第２の情報が表示され、以下同様に表示が行われるからである。本発明によるストリームサイクリングホイール７０２の図７００が示される図１８を参照して、これを説明する。ホイール７０２は、いくつかのスロット１ないしＮを有し、Ｎは、整数７０４〜７０８である。スロット７０４は、例えば、所与の期間中に表示される情報の一部分の実例に対応する。それぞれのスロットは、所与の期間中にどれだけ長く情報のその部分が表示されるかに対応する時間遅延を有する。例えば、スロット７０６は、弧７１０の長さによって表される時間遅延を有し、より長い弧を有するスロットが、より大きい対応する時間遅延を有している。それぞれの情報が、情報の周期にほぼ等しい数のスロットに割り振られる。したがって、１の周期を有する情報は、１スロットに割り振られる。スロット数および所与の期間は、実質的にすべての情報の周期の総計にほぼ等しくなるように増大、低減を行い、情報の実質的にすべての実例が表示される所与の期間が、その実例の時間遅延の総計にほぼ等しくなるようにするのが可能であることに留意されたい。
【０１７０】
ホイール７０２は、矢印７１２で示される通り回転し、ホイール７０２をポイントするビューイング矢印７１４が、所与の期間中、ホイール７０２の異なるスロットをポイントするようになっている。矢印７１４がポイントしているスロット７０４は、ディスプレイの所定の領域内で現在、表示されている情報を含む。したがって、所与の期間中にホイール７０２が回転するにつれ、異なるスロットが矢印７１４によってポイントされ、所定の領域内で異なる情報が表示されるようになっている。ホイール７０２の回転速度は、ホイール７０２が所与の期間中に完全に１回転することができるようになっている。図１８のホイール７０２は、本発明のストリームサイクリングの態様の概念図であり、実際には、この態様を実施するのにそのようなホイールを提供する必要はないことに留意されたい。
【０１７１】
本発明の一態様によれば、ストリームサイクリングを行うことができる情報の一部分は、現行のサイクルにおける最もクリティカルな通知の、または、より一般的には、より大きい通知ストアから取り出すことが可能なより大量の情報の高レベルの要約を含む情報である要約ページである。ユーザにより、この要約の中で特に参照される通知が選択されることにより、通知の即時の表示が行われる。一態様ではそれぞれのページが、かたまりになった関連情報を含む、情報セットのクラスタを含む１つまたは複数の要約ページ、例えば、実質的にすべての通信（例えば、インスタントメッセージ、電子メール、着信電話コール）に関する要約ページ、および／または実質的にすべての自動化されたサービスに関する要約が存在する。さらに、本発明の別の態様によれば、ユーザが情報のサイクリングを停止すること、クリックして迅速にサイクルの中を進み、一時停止したいところで一時停止すること、および／または他の情報に関して掘り下げることを行えるようにする制御の明示的セットが存在することが可能である。一態様では、ストリームサイクリングによって提示される情報を別個のディスプレイ上に表示することができる。
【０１７２】
説明の以下の節では、本発明のストリームスタッキングの態様を説明する。図１９の図が、そのようなストリームスタッキングによるディスプレイ８００を示している。ディスプレイ８００は、メイン通知ウィンドウ８０２、ジャーナルウィンドウ８０４、およびいくつかのソースサマリ（summary）ウィンドウ８０６を含み、実質的にそのすべてが、ディスプレイ８００の所定の領域（例えば、ディスプレイ８００のスクリーン）内で表示されるものとされる。前述した通り、通知ソースなどのいくつかの情報ソースが存在する。それぞれの情報ソースは、前述した通り、ユーザの１次タスクと関係のない情報を含むことが可能な要求されていない情報などの情報を生成し、対応するソースサマリウィンドウ８０６の中でその情報を表示する。やはり前述した通り、情報は、通知アラートを含むことが可能である。
【０１７３】
情報のそれぞれの部分には、重要度値を割り当てることができ、重要度値の基準は、本発明によって制限されない。例えば、所定のしきい値などのしきい値より高い重要度を有する情報が、ストリームサイクリング式にメイン通知ウィンドウ８０２の中で表示される。例えば、ストリームサイクリングは、それぞれの情報がメイン通知ウィンドウ８０２の中にある時間の長さだけフェードインされ、次にフェードアウトされる前述した本発明のストリームサイクリングの態様に従うことが可能である。ただし、本発明自体は、そのように限定されない。ストリームサイクリング式に情報を表示することを本明細書では、情報を表示ストリーミングするとも呼ぶ。一態様では、メイン通知ウィンドウ８０２の中で表示される情報は、ソースサマリウィンドウ８０６の中で表示される情報のより詳細なバージョンであることが可能である。
【０１７４】
さらに、本発明の一態様では、メイン通知ウィンドウ８０２の中で表示ストリーミングされた情報は、所定の基準に従ってジャーナルウィンドウ８０４の中にジャーナリングされる。例えば、情報の特定の部分がメイン通知ウィンドウ８０２の中で表示されたとき、その情報の１行要約が、本明細書で一般的にジャーナルエントリと呼ぶジャーナルウィンドウ８０４に追加され、ウィンドウ８０４が、そのような要約のリストを表示するようになることが可能である。一態様では、ウィンドウ８０４のリストは、ユーザによってスクロール可能であり、ユーザが、メイン通知ウィンドウ８０２の中で既に表示ストリーミングされた実質的にすべての情報を検査できるようになっている。
【０１７５】
本発明の一態様によれば、ジャーナルウィンドウ８０４にジャーナリングされ、かつ／または追加される情報を限定する所定の基準は、ユーザによって閲覧されていないことがユーザ自身によって示された情報であることである。例えば、ユーザは、ホバリングとも呼ばれる、メイン通知ウィンドウ８０２の上でカーソルを動かすことなどの所定のジェスチャを行うことにより、メイン通知ウィンドウ８０２の中に現在、表示されている情報が、自身によって閲覧されたものであることを示すことができる。ジャーナリングを行うための所定の基準をユーザが制御することも可能である。一般に、ジャーナルは、情報をユーザにリレーする試みの完全な履歴をキャプチャするのに使用する。ジャーナルエントリは、情報のソース、高レベルのタイトルおよび／または要約、および／または通知またはアラートに関して行われた可能性のあるアクションに関する情報を含むことが可能である。
【０１７６】
メイン通知ウィンドウ８０２、ソースサマリウィンドウ８０６の中で表示される、かつ／またはジャーナルウィンドウ８０４の中にジャーナリングされる情報に関係のある所定のユーザジェスチャに応答して、アクションが行われることが可能である。例えば、所定のユーザジェスチャは、メイン通知ウィンドウ８０２、ソースサマリウィンドウ８０６の上でカーソルを動かすこと、またはジャーナルウィンドウ８０４へのジャーナルエントリ、およびジャーナルウィンドウ８０４の中で表示される情報を選択することであるのが可能である。選択は、適切な入力デバイスボタンをユーザがクリックすることによって行われることが可能であるが、本発明は、そのように限定されない。このジェスチャに応答して行われるアクションは、本発明によって限定されない。ただし、一態様では、アクションには、関係のあるジェスチャの対象であった情報に関連するより詳細な情報などのさらなる情報を表示することが含まれる。
【０１７７】
以上の例を図２０に示している。ディスプレイ９００で、ユーザが、ポインタとして図２０に示すが、本発明は、特にそのように限定されないカーソル９０４をソースサマリウィンドウ８０６のソースサマリウィンドウ９０４の上で動かして、ソースサマリウィンドウ９０４の中で表示されている情報を選択したものと想定する。ウィンドウ９０４に関する情報ソースは、ユーザ所望ソースと呼ばれる。というのは、この情報ソースは、それに関係するジェスチャをユーザが行ったソースだからである。ジェスチャに応答して、あるアクションが行われており、具体的には、ソースサマリウィンドウ９０４の中で表示されている情報に関するより詳細な情報を含むことが可能なウィンドウ９０６の表示が行われている。図２０の例は、ソースサマリウィンドウ８０６のうち１つの中で表示されている情報に関係するジェスチャを行うユーザに固有であるが、本発明自体は、そのように限定されず、ジェスチャは、メイン通知ウィンドウ８０２の中で表示されている情報、またはジャーナルウィンドウ８０４の中にジャーナリングされているジャーナルエントリの情報に関係しているのも可能であることに留意されたい。
【０１７８】
理解することができる通り、前述し、図１９および図２０に関連して説明した本発明のストリームスタッキングの態様は、様々な拡張が可能である。例えば、１つまたは複数のそれぞれのウィンドウ８０２、８０４、および８０６が表示される「単純モード」トグルが、存在することが可能である。さらに、ソースサマリウィンドウ８０６の数がユーザによって増加される、低減されることが可能である。また、一態様では、ソースサマリウィンドウ８０６を最小化して、ソースサマリウィンドウ８０６の中で表示される情報が、ウィンドウ８０６に関する情報ソースを表すアイコンであり、ウィンドウ８０６のうち特定のウィンドウ上でユーザによって行われたカーソルホバリングにより、対応するソースによって生成された情報が表示されるようにすることも可能である。
【０１７９】
次に、図２１を参照すると、本発明のストリームスタッキングの態様の方法１０００が、流れ図によって示されている。方法１０００は、図１９および２０に関連して説明したストリームスタッキングの態様を含むことが可能である。
【０１８０】
１００２で、いくつかのソースからの情報が表示される。それぞれのソースからの情報が、対応するソースサマリウィンドウの中で表示される。情報は、ユーザの１次タスクに関係のない要求されていない情報であることが可能である。１００４で、所定のしきい値などのしきい値を超える重要度を有する情報の表示ストリーミングが、メイン通知ウィンドウの中で行われる。一態様では、メイン通知ウィンドウの中で表示される情報は、その情報のソースに対応するソースサマリウィンドウの中で表示される情報よりも詳細であることが可能である。１００６で、メイン通知ウィンドウの中で表示ストリーミングの行われた情報が、所定の基準に従ってジャーナルウィンドウに追加されるジャーナルエントリによるなどして、ジャーナルウィンドウの中にジャーナリングされる。
【０１８１】
前述した通り、ユーザは、特定の（ユーザ所望の）情報について所定のユーザジェスチャを行うことにより、実質的にソースサマリウィンドウ、メイン通知ウィンドウの任意のウィンドウの中で表示され、かつ／またはジャーナルウィンドウの中にジャーナリングされている実質的に任意の情報に関係するアクションが行われるようにすることができる。したがって、１００８で、ソースサマリウィンドウ、メイン通知ウィンドウのどれかの中で表示されている、かつ／またはジャーナルウィンドウの中でジャーナルエントリを有する特定の情報に関して、そのようなユーザジェスチャが検出される。この検出に応答して、１０１０で、この情報に関係のあるアクションが行われる。例えば、本発明の一態様では、情報のより詳細なバージョンを表示することが可能である。
【０１８２】
説明の以上の節で述べた本発明の様々な態様は、ストリームスタッキングとも呼ばれる。というのは、情報をメイン通知ウィンドウの中で「ストリーミングする」ことと、ソースサマリウィンドウとジャーナルウィンドウの両方の中にスタックすることをともに行うことができるからである。したがって、ユーザは、メイン通知ウィンドウを参照することによって重要な情報について知ることができ、またジャーナルウィンドウの中で情報に関する対応するジャーナルエントリを参照することにより、メイン通知ウィンドウの中で表示された過去の情報を調べることができる。また、ユーザは、ソースに関してソースサマリウィンドウを参照することにより、通知ソースなどの所与のソースによって生成されている現行の情報を観察することもできる。ソースサマリウィンドウの情報は、重要度に関わらず表示されることが可能であり、一方、より重要な情報は、一般に、メイン通知ウィンドウの中で表示され、ジャーナルウィンドウの中にジャーナリングされる。
【０１８３】
さらに、本発明の一態様では、高レベル要約情報が、それぞれのソースに関連付けられる。例えば、電子メール関連ソースが、そのソースからの情報の全体的ステータスに関する情報を表示し、所与の優先順位を有する１０の未読のメッセージが存在し、また最高優先順位のメッセージが、特定の件に関する特定のユーザからであるようにすることが可能である。この場合、ソース上でクリックする、またはホバリングすることにより、ソースアプリケーションに関するより幅広いユーザインタフェース、最新の通知等が表示されることが可能である。説明の前の節で述べた本発明のストリームサイクリングの態様の独立したバージョンなどの本発明の別の態様では、情報が各ソースディスプレイ内でストリーミングされる、またはサイクリングされる。さらに、より大きいメイン通知ウィンドウが含まれる本発明のその他の態様では、特定のソースをクリックすること、または別の仕方で選択することにより、ソース情報の詳細が表示され、この情報にフォーカスが当てられるようになる。したがって、通知の後続の選択により、この情報のさらなる詳細、および／またはこのソースに関するより幅広いユーザインタフェースが表示されることが可能である。
【０１８４】
説明の前の節では、パルスモード、ストリームサイクリングモード、およびストリームスタッキングモードを含め、情報をユーザに提示することができる様々なモードを説明してきた。説明の本節では、ユーザがそれぞれのモードを介して提示される情報と対話することができる仕方に関するさらなる説明を提供する。説明の前の節では、様々なユーザジェスチャおよびオーディオ通報について述べたが、説明の本節は、どのようにユーザ対話を行うことができるかに関してより詳細な説明を提供する。
【０１８５】
例えば、追加の情報の要望を伝えるためのユーザジェスチャ、および可能なリンクおよびサービスに関して提示された質問に返答するためのユーザジェスチャを説明する。一態様では、ユーザが、ストリームスタッキングモードにおいてソースの上でカーソルをホバリングさせているのが、要約に関してより詳細な情報を提供するようにというシステムに対する合図であることが可能である。その詳細な情報は、前述した通り、ポップアップウィンドウの中で現れることが可能である。したがって、この態様では、ユーザがウィンドウ上でカーソルをホバリングさせていることは、通知内容に関するさらなる詳細を求めるユーザからの暗黙的な要求として利用される。例えば、気象通報が存在する場合、カーソルホバリングは、湿度、５日間の予報などの天候に関するさらなる詳細をユーザが求める仕方である。
【０１８６】
その他のジェスチャも、本発明に従って検出することができる。例えば、ユーザがストリーミングされている情報の上にカーソルを置き、次に、マウスのようなポインティングデバイスのボタンをクリックするなどして情報を選択することを様々な仕方で使用するのが可能である。例えば、ディスプレイ内で提供されるユニバーサルリソースロケータ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）（ＵＲＬ）アドレスの選択により、例えば、そのアドレスによって参照される情報のアクセスが行われるのが可能である。別の例として、質問（例えば、「貴方のためにそれをスケジュールしますか」）を尋ねる情報表示の不特定の領域内でクリックすることが、サービスを受けるユーザの意図を確認する「はい」とみなされ、一方、何も選択されないデフォルトが、「いいえ」の応答であると判定されることが可能である。
【０１８７】
さらに、アプリケーションと通信するアクションおよびタイミング、通知マネージャ、および／または通知にユーザが気付いていることに関する証拠を提供することについて説明する。例えば、通知が現れた後のある時間内にキーボードまたはマウスなどの入力デバイスを利用するユーザジェスチャがユーザによって提供されて、「この通知に関してもっと私に知らせなさい」を伝えることが可能である。マウスのようなポインティングデバイスを振り動かす、またはディスプレイの事前定義された隅にカーソルを移動するなどのユーザジェスチャを利用して、ユーザに伝えられた最初の通知に応じて、ユーザが、「それは何であったのか」、「それを私に再び見せなさい」、または「これに関してもっと私に知らせなさい」を伝えることが可能である。例えば、通知がオーディオ通報であった場合、そのようなユーザジェスチャ（例えば、ディスプレイの隅におけるような）は、ユーザが「それは何であったのか」を尋ねているものと解釈して、前述したパルスモードに従って情報が通知ウィンドウの中で表示されるようになるのが可能である。
【０１８８】
また、ジェスチャを人間−コンピュータ間の対話で使用して、ユーザが通知を見たことを通知マネージャに示す、またはより明示的に通知マネージャにリレーされる情報を収集することも可能である。例えば、自身が通知を見たことを通知システムに示す仕方として、ユーザは、通知が表示された後のある時間フレーム中に通知の上でカーソルをホバリングさせることが可能である。したがって、この場合、システムは、その通知をユーザにリレーすることを再度試みることがないよう決定することができる。また、ユーザがウィンドウの中に存在するリンクを選択するなどの、より複雑な対話がこの指示を提供することも可能である。
【０１８９】
説明の前の節で述べたジャーナルなどの通知ジャーナルとのユーザ対話を次に説明する。つまり、前述した通り、通知要約を本発明のストリームスタッキングモードで通知ジャーナルの中に記憶することができる。通知要約は、時刻、通知ソース、メッセージ分類等で編成することができ、ユーザが、以前に見落とした可能性がある通知を再び訪れる、または見直すことができるようにする。したがって、ジャーナルエントリを選択することにより、ユーザは、通知を再表示できるようになる。
【０１９０】
本発明の別の態様に従って、情報の表示に代わる、または情報の表示を拡張するオーディオの使用を説明する。例えば、しきい値（所定のしきい値などの）を超える通知の表示を告示するため、オーディオ通報を使用することができ、通知に対するユーザの注意を喚起するためにさらに使用することができる。さらに、異なる音が、異なるタイプの通知に関連していることが可能である。例えば、スケジューリング関連通知は、電子メール関連通知とは異なる音を有するのが可能である。
【０１９１】
また、この適用例では、情報を表示するのに、テキストの使用および／またはテキストおよびグラフィックスの使用を説明したが、本発明は、テキストおよび／またはテキストおよびグラフィックスには限定されないことに留意されたい。例えば、一態様では、情報がグラフィックスで表示され、情報の性質および優先順位を示すのに異なる形状および異なるカラーが利用されることが可能である。別の例として、表示されるオブジェクトがディスプレイの中心に近いほど、そのオブジェクトは重要度が高く、異なるカラー領域が情報の異なるソースを表す。つまり、本発明は、情報に関連する高レベルのグラフィックスおよび／またはテキストの例えの特定の概念に限定されない。
【０１９２】
本発明の代替の情報表示の態様の例を図２３の例としての図に示す。本発明のこの態様によれば、例えば、図１４に描くデスクトップスクリーン３００の所定の領域３０２内で情報を表示することができる。さらに、一態様では、ユーザは、スコープモードを含む異なるモードの間で切り替えを行うことができる。例えば、システムは、ディスプレイ、処理システム、およびプロセッサによって実行されて、スコープモードなどのモードのどれかにエントリが行われるようにするコンピュータプログラムを記憶するマシン可読媒体を含むことが可能である。さらに、一態様では、ユーザによるモード間の切替えの他、詳細な説明の前の節で述べた通知マネージャが、例えば、モードを切り替える判定を行うことができる。
【０１９３】
図２３に描いた例としてのスコープインタフェースでは、情報の性質および優先順位を示すのに異なる形状および異なるカラーが利用される。例えば、１つまたは複数の部分に分割されたスクリーンの隅に円形の表示オブジェクト１１００（例えば、ホイール）が存在することが可能である。その他の形状も可能であることに留意されたい。それぞれの部分は、異なるカラーであり、情報の異なるタイプまたは異なるソースを示すことが可能である。例えば、円形、正方形、矢印、線などの表示オブジェクト１１００のそれぞれの部分内のオブジェクトが、それぞれの部分の情報ソースからの通知、優先順位、および／またはイベント、および／またはそれぞれの部分の情報タイプを表すことが可能である。オブジェクトが表示オブジェクト１１００の中心に近いほど、そのオブジェクトは重要度が高い、つまり、重要度値の割り当てられた通知、メッセージ、および／または他のタイプの情報である。したがって、一態様では、ホイール内の同心円が、異なる優先順位レベルを画定する。カーソルでオブジェクトの上をホバリングすることにより、そのオブジェクトに関するテキスト情報が表示されるようにすることができる。例えば、カーソルで表示オブジェクト１１００の一部分の上を（ただし、表示オブジェクト内のオブジェクトの上ではなく）をホバリングすることにより、表示オブジェクト１１００のその部分に関する情報タイプまたは情報ソースを示すテキスト情報を生じさせることができる。テキスト情報は、例えば、ツールティップ（tool tip）として表示されることが可能である。
【０１９４】
本発明の様々な態様に関するコンテキストを提供するため、図２３および以下の説明は、本発明の様々な態様を実施することができる適切なコンピュータ環境の簡単な一般的説明を提供するものである。１つまたは複数のコンピュータ上で実行されるコンピュータプログラムのコンピュータ実行可能命令の一般的コンテキストにおいて本発明を以上で説明してきたが、本発明は、その他のプログラムモジュールの組合せで実施するのも可能なことが、当分野の技術者には認められよう。一般に、プログラムモジュールには、特定のタスクを行う、かつ／または特定の抽象データタイプを実装するルーチン、プログラム、構成要素、データ構造等が含まれる。さらに、本発明の方法は、単一プロセッサ、またはマルチプロセッサのコンピュータシステム、ミニコンピュータ、メインフレームコンピュータ、ならびにパーソナルコンピュータ、ハンドヘルドコンピュータ装置、マイクロプロセッサベースの家庭用電化製品またはプログラマブル家庭用電化製品等を含むその他のコンピュータシステム構成で実施できることが、当分野の技術者には理解されよう。また、本発明の示す態様は、通信網を介してリンクされたリモート処理装置によってタスクが行われる分散コンピュータ環境においても実施することが可能である。ただし、本発明のすべてではないにしても、いくつかの態様は、独立型コンピュータ上で実施することが可能である。分散コンピュータ環境では、プログラムモジュールは、ローカルのメモリ記憶装置とリモートのメモリ記憶装置の両方の中に配置されていることが可能である。
【０１９５】
図２３を参照すると、本発明の様々な態様を実施するための例としてのシステムが、プロセッサ１２２１と、システムメモリ１２２２と、システムメモリを含む様々なシステム構成要素をプロセッサ１２２１に結合するシステムバス１２２３とを含むコンピュータ１２２０を含む。プロセッサ１２２１は、様々な市販のプロセッサのどれであることも可能である。デュアルマイクロプロセッサ、およびその他のマルチプロセッサアーキテクチャもプロセッサ１２２１として使用できることが理解されよう。
【０１９６】
システムバスは、様々な市販のバスアーキテクチャのどれかを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含むいくつかのタイプのバス構造のどれであることも可能である。システムメモリは、読取り専用メモリ（ＲＯＭ）１２２４、およびランダムアクセスメモリ（ＲＡＭ）１２２５を含むことが可能である。始動中などにコンピュータ１２２０内部の要素間における情報の転送を助ける基本ルーチンを含む基本入力／出力システム（ＢＩＯＳ）が、ＲＯＭ１２２４の中に記憶される。
【０１９７】
コンピュータ１２２０は、ハードディスクドライブ１２２７と、例えば、取外し可能なディスク１２２９に対して読取りまたは書込みを行う磁気ディスクドライブ１２２８と、例えば、ＣＤ−ＲＯＭディスク１２３１に対して読取りまたは書込みを行う、またはその他の光媒体に対して読取りまたは書込みを行うための光ディスクドライブ１２３０とをさらに含む。ハードディスクドライブ１２２７、磁気ディスクドライブ１２２８、および光ディスクドライブ１２３０は、それぞれ、ハードディスクドライブインタフェース１２３２、磁気ディスクドライブインタフェース１２３３、および光ディスクドライブインタフェース１２３４によってシステムバス１２２３に接続されている。これらのドライブおよび関連コンピュータ可読媒体は、コンピュータ１２２０のためのデータ、データ構造、コンピュータ実行可能命令等の不揮発性記憶装置を提供する。以上のコンピュータ可読媒体の説明は、ハードディスク、取外し可能な磁気ディスク、およびＣＤに関連するが、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイカートリッジ等のコンピュータによって読取り可能な他のタイプの媒体も例としての動作環境において使用することができ、さらに、任意のそのような媒体が、本発明の方法を実行するためのコンピュータ実行可能命令を含むのが可能であることが、当分野の技術者には理解されよう。
【０１９８】
オペレーティングシステム１２３５、１つまたは複数ののアプリケーションプログラム１２３６、その他のプログラムモジュール１２３７、およびプログラムデータ１２３８を含むいくつかのプログラムモジュールをドライブおよびＲＡＭ１２２５の中に記憶することができる。示すコンピュータにおけるオペレーティングシステム１２３５は、実質的にどの適切なオペレーティングシステムであるのも可能なことに留意されたい。
【０１９９】
ユーザは、キーボード１２４０、およびマウス１２４２などのポインティングデバイスを介してコマンドおよび情報をコンピュータ１２２０に入力することができる。その他の入力デバイス（図示せず）には、マイクロホン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナ等が含まれることが可能である。以上の入力デバイスおよびその他の入力デバイスは、しばしば、システムバスに結合されたシリアルポートインタフェース１２４６を介してプロセッサ１２２１に接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）（ＵＳＢ）などの他のインタフェースを介して接続されることも可能である。また、モニタ１２４７または他の表示装置も、ビデオアダプタ１２４８などのインタフェースを介してシステムバス１２２３に接続される。モニタに加えて、コンピュータは、通常、スピーカおよびプリンタなどの他の周辺出力装置（図示せず）も含む。
【０２００】
コンピュータ１２２０は、リモートコンピュータ１２４９などの１つまたは複数のリモートコンピュータに対する論理接続を使用するネットワーク化された環境で動作することが可能である。リモートコンピュータ１２４９は、ワークステーション、サーバコンピュータ、ルータ、ピア装置、またはその他の共通ネットワークノードであることが可能であり、通常、コンピュータ１２２０に関連して説明した要素の多く、またはすべてを含む。ただし、メモリ記憶装置１２５０だけを図２３で示している。図２３に描く論理接続は、ローカルエリアネットワーク（ＬＡＮ）１２５１、およびワイドエリアネットワーク（ＷＡＮ）１２５２を含むことが可能である。そのようなネットワーク環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、およびインターネットで一般的である。
【０２０１】
ＬＡＮネットワーク環境で使用する場合、コンピュータ１２２０は、ネットワークインタフェース、つまりアダプタ１２５３を介してローカルネットワーク１２５１に接続することができる。ＷＡＮネットワーク環境で利用する場合、コンピュータ１２２０は、一般に、モデム１２５４を含むことが可能であり、かつ／またはＬＡＮ上の通信サーバに接続され、かつ／またはインターネットなどのワイドエリアネットワーク１２５２を介して通信を接続するための他の手段を有する。内部または外部にあることが可能なモデム１２５４をシリアルポートインタフェース１２４６を介してシステムバス１２２３に接続することができる。ネットワーク化された環境では、コンピュータ１２２０に関して描くプログラムモジュール、またはプログラムモジュールの部分をリモートのメモリ記憶装置の中に記憶することが可能である。示したネットワーク接続は、例としてのものであり、コンピュータ間で通信リンクを確立する他の手段も使用できることが理解されよう。
【０２０２】
コンピュータプログラミング分野の技術者の慣行に従って、特に明記しない限り、本発明は、コンピュータ１２２０のようなコンピュータによって行われる処置、および動作の記号表現に関連して説明した。そのような処置および動作は、ときとして、コンピュータ実行される処置および動作と呼ばれる。処置および記号で表現される動作には、電気信号表現を結果として変換する、または減少させる、データビットを表す電気信号のプロセッサ１２２１による操作、およびメモリシステム（システムメモリ１２２２、ハードディスク１２２７、フロッピー（登録商標）ディスク１２２９、およびＣＤ−ＲＯＭ１２３１を含む）内のメモリロケーションにおいてデータビットを保持して、コンピュータシステムの動作を再構成する、または別の仕方で変更すること、ならびに他の信号処理が含まれることが理解されよう。そのようなデータビットが保持されるメモリロケーションは、データビットに対応する特定の電気特性、磁気特性、または光学特性を有する物理的ロケーションである。
【０２０３】
以上に説明したのは、本発明の様々な態様である。もちろん、本発明を説明するため、構成要素または方法の考えられるすべての組合せを説明することは不可能であるが、本発明の多数のさらなる組合せおよび変更が可能であることが、当分野の技術者には認められよう。したがって、本発明は、頭記の特許請求の範囲の中にあるすべてのそのような改変形態、変更形態、および変形形態を包含するものとする。
【産業上の利用可能性】
【０２０４】
本発明は、コンピュータ、コンピュータソフトウェア、および情報技術の分野で産業上の利用可能性を有する。
【技術分野】
【０００１】
本発明は、全般的にはコンピュータシステムに関し、具体的には、ユーザへの伝達のために様々なデバイスおよびアプリケーションによって生成されるアラートの受取および通知を容易にするアーキテクチャを提供するシステムおよび方法に関する。
【背景技術】
【０００２】
多くのコンピュータユーザが、現在、多数の異なるソースから情報を受け取り、この情報にアクセスするために多数の異なるデバイスまたはモーダリティ（ｍｏｄａｌｉｔｙ）を使用する。例えば、ユーザは、コンピュータを介して電子メールまたはインスタントメッセージを、ポケットベルを介して呼び出しを、携帯（「セル」）電話または陸線電話などの電話を介して音声メールを、コンピュータを介してニュース情報を受け取ることができる。入手可能な情報の量がますます増え、そのような情報を通信するモーダリティが多数あるので、ユーザが居合わせた場所、ユーザがどのような気分または状態にあるか、およびユーザがアクセスできる通信モーダリティに従って、ユーザが情報を受け取り、処理することが困難になる。
【０００３】
一例として、ユーザが、自分のコンピュータから離れているが、重要な電子メールを受信する場合がある。しかし、多くの場合に、ユーザは、携帯電話またはポケットベルへのアクセスだけを有する。したがって、あるモーダリティ（例えば電子メール）を介して送信されたメッセージは、別のモーダリティに自動的に転送も通信もされない。その結果、ユーザが実際にメッセージを受け取る前に、重要な時間が経過する可能性がある。いくつかの場合に、メッセージ自体が所与の時間枠以内のユーザによる応答またはアクションを必要とするので、メッセージは、実際に受け取られる前に有用でなくなる可能性がある。もう１つの例として、ユーザが、コンピュータを使っているが、コンピュータに集中している間に気が散らないようにするために、電話機の呼出音発生機能および音声メールインジケータをオフにしている場合がある。しかし、重要な音声メールがこの時間中に放置された場合に、ユーザは、一般に、定期的に音声メールをチェックしていなければ、重要なメッセージを受信したかどうかを知る方法がない。
【０００４】
重要なメッセージまたはアラートに潜在的に応答しないこととは対照的に、受け取られる多くのメッセージ／アラートが、ユーザにとって重要でない可能性がある。例えば、ユーザの管理者または協働者からの電子メールは、一般に、最新のスポーツ点数スコアの受信またはレビューより高い優先順位で受信されなければならない。したがって、メッセージまたはアラートに含まれる情報の価値と、ユーザに対する中断に関連するコストとのバランスをとらなければならない。しかし、コストおよび価値は、コンテキスト依存（ｃｏｎｔｅｘｔ ｓｅｎｓｉｔｉｖｅ）である可能性がある。これには、ユーザが居合わせた場所、ユーザが現在かかわっているアクティビティ、ユーザがアクセスできる通信モーダリティを含めることができる。上で説明した通信および関連するモーダリティの管理の他に、ユーザは、様々な他のメッセージおよび／またはアラートも受け取り、後に処理する。これには、例えば、増加する多数のサービスからのアラート、エラーメッセージ、およびコンピュータ化されたアシスタンスの提示を含めることができる。
【発明の概要】
【０００５】
以下では、本発明のいくつかの態様の基本的な理解を提供するために、本発明の単純化された要約を提示する。この要約は、本発明の広範囲の概要ではない。本発明の鍵となる要素またはクリティカルな要素を識別することも、本発明の範囲を示すことも、意図されていない。この要約の唯一の目的は、後に提示されるより詳細な説明の前置きとして、単純化された形で本発明のいくつかの概念を提示することである。
【０００６】
本発明は、通知プラットフォームのアーキテクチャを提供するシステムおよび方法に関する。本発明の一態様によれば、このアーキテクチャに、コンテキストアナライザ（ｃｏｎｔｅｘｔ ａｎａｌｙｚｅｒ）またはコンテキストコンポーネントと、１つまたは複数の通知ソースおよび通知シンクと、通知マネージャが含まれる。コンテキストアナライザは、ユーザのデフォルト通知プリファレンス（ｐｒｅｆｅｒｅｎｃｅ）などのユーザの通知パラメータに関するユーザプロファイル情報を保管し、ユーザコンテキスト識別および更新サービスを提供する。通知ソースは、ユーザに向けられた通知を生成し、通知シンクは、ユーザへの通知を提供する。通知マネージャが、コンテキストアナライザによって保管され判定される情報と、通知の緊急性に関する提供されるか推定された情報とに基づいて、ソースによって生成された通知をシンクに伝えるか向ける。例えば、通知マネージャは、ユーザのコンテキスト（例えば、ユーザの現在位置および注意のフォーカス（集中、焦点；focus））にアクセスするか、これを推定することができる。これは、コンテキスト情報の複数のソースの見当に基づいて達成することができる。そのような情報のソースには、例えば、ユーザのコンテキストプロファイル、ユーザのオンラインカレンダ、時刻、世界に関するイベント、組織、システム、および／またはユーザのアクティビティを含めることができる。その後、通知を、情報のコンテキストおよび緊急性の分析を介して判定することができる。これには、通知のどれを、どのシンクを介して、そのシンクによって提供される形またはモーダリティのどれで、ユーザに伝えなければならないかの判定を含めることができる。
【０００７】
本発明の他の態様によれば、ユーザは、例えば、電子メールアラートを受け取り、なおかつ、望むならば、電子メールを自動的に携帯電話に向けることができる。同様に、音声メールを、通知マネージャによって適当に決定されるように、デスクトップコンピュータに向けることができる。したがって、通知ソースからの通知は、通知マネージャによって処理され、通知マネージャは、ユーザに通知しなければならないかどうかを判定する。マネージャが、ユーザに通知しなければならないと判定する場合には、マネージャは、ユーザに通知する方法も判定する。これは、所望の通知シンクに通知するための、ユーザのプリファレンスおよび現在のコンテキストなどの情報を含む、ユーザプロファイルに保管された情報に基づくものとすることができる。シンクには、例えば、デスクトップコンピュータ、携帯電話、ポケットベル、および／または他のデバイス／アプリケーションを含めることができる。
【０００８】
さらに、通知プラットフォームのアーキテクチャを、例えばデスクトップ設定またはモバイル設定でのソフトウェアコンポーネントによるサービスの潜在的な提供に関連するものを含む、実質的にすべての通知に一般化することができる。そのような通知には、下記を含めることができる。
【０００９】
・ソフトウェアアプリケーションを使っているユーザにアシスタンスまたはヒントを自動的に提供しようとするサービスおよび／またはユーザの注意のフォーカスで電子メールを検査することによるスケジューリングを自動的に実行するサービスなどのサービスに関するアラート
・これから来る面会予約または約束についてユーザに通知するアラート
・友人および同僚の位置、近接、または注意の状況の重要な変化を中継するアラート
・作成中のテキストまたはユーザがレビューしているテキストに基づいてバックグラウンド照会を発行し、そのようなバックグラウンド検索の結果をユーザに提示するアラート
【００１０】
上で説明したように、コンテキストアナライザは、ユーザの現在位置および注意の状態などのユーザの現在のコンテキストを判定する。判定されたコンテキストを使用して、例えば、ユーザに向けられた通知を伝えなければならないかどうかと、いつ、どのように伝えるかを決定することができる。本発明の他の態様によれば、コンテキストは、ユーザによる直接指定、１つまたは複数のセンサを使用する直接測定、コンテキストを示すユーザが修正可能なプロファイル、コンテキストを示す潜在的にユーザが修正可能な１つまたは複数のルール、および／またはベイズモデルまたは統計モデルなどのモデルを使用する推定分析のうちの１つまたは複数を介して判定される。したがって、ユーザの位置および注意の状態（またはフォーカス）を含むユーザのコンテキストを、ユーザに通知を伝えるのに使用することができる。
【００１１】
本発明のもう１つの態様によれば、決定理論的分析を、通知マネージャによって使用して、通知ソースから受け取った通知のどれを、通知シンクに関連する１つまたは複数のモードのどれを介して、ユーザに伝えるかを決定することができる。通知に含まれる情報の期待価値から、シンクのモードを介して通知を伝えるための中断の期待コストを引き、通知なしでユーザが通知に含まれる情報を独立に習得することの期待価値を引き、モードおよびシンクを介して通知を伝えることの実際のコストを引いた値を、通知シンクおよび関連するモードについて判定する。この値が、所定の伝達閾値より大きい場合に、通知が、例えば最も高いその値を有するシンクのモードを介して伝えられる。本発明のもう１つの態様によれば、ヒューリスティック（heuristic）通信ポリシを、通知マネージャによって使用して、通知ソースから受け取ったどの通知を、関連する通信シンクのどのモードを介してユーザに伝えなければならないかを判定する。
【００１２】
以下の説明および添付図面に、本発明のいくつかの例示的態様を詳細に示す。しかし、これらの態様は、本発明の原理を使用できる様々な形のごく少数を例示するものであり、本発明は、そのような態様のすべておよびその同等物を含むことが意図されている。本発明の他の長所および新規の特徴は、添付図面と共に検討される時に、以下の本発明の詳細な説明から明白になる。
【図面の簡単な説明】
【００１３】
【図１】本発明の一態様による、通知プラットフォームアーキテクチャを示すシステムの概略ブロック図である。
【図２】本発明の一態様による、コンテキストアナライザを示す概略ブロック図である。
【図３】本発明の一態様による、通知ソースおよび通知シンクを示す概略ブロック図である。
【図４】本発明の一態様による、通知曲線の使用を示す図である。
【図５】本発明の一態様による、通知に関するユーザ指定インタフェースを示す図である。
【図６】本発明の一態様による、コンテキスト情報ソースを示す図である。
【図７】本発明の一態様による、コンテキストを判定するためのルールベースシステムを示す図である。
【図８】本発明の一態様による、コンテキストを判定するための推定ベースシステムを示す概略ブロック図である。
【図９】本発明の一態様による、コンテキストを判定するための推定モデルを示す図である。
【図１０】本発明の一態様による、コンテキストを判定するための時間的推定モデルを示す図である。
【図１１】本発明の一態様による、コンテキストを判定する方法を示す流れ図である。
【図１２】本発明の一態様による、通知意思決定の方法を示す流れ図である。
【図１３】本発明の一態様による、通知プラットフォームの決定理論的分析を提供する方法を示す流れ図である。
【図１４】本発明の一態様による、例示的ディスプレイを示す図である。
【図１５】本発明の一態様による、様々なディスプレイを提供する方法を示す流れ図である。
【図１６】本発明の一態様による、価値対時間を示す図である。
【図１７】本発明の一態様による、ストリームサイクリングを提供する方法を示す流れ図である。
【図１８】本発明の一態様による、例示的ストリームサイクリングディスプレイを示す図である。
【図１９】本発明の一態様による、例示的ストリームスタッキングディスプレイを示す図である。
【図２０】本発明の一態様による、例示的ストリームスタッキグディスプレイを示すより詳細な図である。
【図２１】本発明の一態様による、ストリームスタッキングを提供する方法を示す流れ図である。
【図２２】本発明の代替態様による、例示的ディスプレイを示す図である。
【図２３】本発明の一態様による、適当なオペレーティング環境を示す概略ブロック図である。
【発明を実施するための形態】
【００１４】
本発明は、１つまたは複数の通知ソースに関連する様々な情報を、通知プラットフォームアーキテクチャを介して１つまたは複数の通知シンク（例えば情報を受け取るモーダリティ）に向けることを可能にするシステムおよび方法に関する。このアーキテクチャには、位置および注意のフォーカスなどのユーザの状態を判定するためのコンテキストアナライザが含まれ、ユーザの状態は、例えば通知ソースによって生成されたどの情報をいつどのように通知シンクに転送しなければならないかに関する決定を行うために、通知マネージャによって使用される。これらの決定には、ユーザに通知することの利益よりユーザを中断することのコストが大きいかどうかに関する考察が与えられる費用便益分析を含めることができる。決定理論的ポリシおよび／または多少フォーマルでないヒューリスティックポリシを使用して、通知マネージャ内の意思決定処理を可能にすることができる。
【００１５】
まず、図１を参照すると、システム１０に、本発明の一態様による通知アーキテクチャが示されている。システム１０には、コンテキストアナライザ２２、通知マネージャ２４（イベントブローカとも称する）、１つまたは複数の通知ソース（例えば、情報を提供するモーダリティ）１からＮ、２６、２７、２８、および１つまたは複数の通知シンク１からＭ、３６、３７、３８が含まれ、ＮおよびＭは、それぞれ整数である。ソースを、イベントパブリッシャ（ｅｖｅｎｔ ｐｕｂｌｉｓｈｅｒ）とも称し、シンクを、イベントサブスクライバ（ｅｖｅｎｔ ｓｕｂｓｃｒｉｂｅｒ）とも称する。任意の数のシンクおよびソースを設けることができる。一般に、通知マネージャ２４は、イベントまたはアラートとも称する通知を、ソース２６〜２８からシンク３６〜３８に、コンテキストアナライザ２２内に保管され、かつ／またはコンテキストアナライザ２２によってアクセスされるパラメトリック情報に部分的に基づいて、通知を伝える。
【００１６】
コンテキストアナライザ２２は、通知意思決定に影響するユーザの変数およびパラメータに関する情報を保管／分析する。例えば、パラメータに、ユーザの通常の位置および注意のフォーカスまたは時刻および曜日ごとのアクティビティなどのコンテキスト情報と、ユーザが異なる場所でアクセスを有する傾向があるデバイスなど、そのようなパラメータによって条件付けられる追加パラメータを含めることができる。そのようなパラメータは、１つまたは複数のセンサを介して自律的に行われる観察の関数とすることもできる。例えば、１つまたは複数のプロファイル（図示せず）を、全地球測位システム（ＧＰＳ）サブシステムによって提供することができるユーザの位置に関する情報、使用されつつあるデバイスのタイプおよび／またはデバイスの使用のパターンに関する情報、および特定のタイプのデバイスがユーザによって最後にアクセスされた時刻に基づいて選択または修正することができる。さらに、下で詳細に説明するように、自動化された推定を使用して、位置および注意などのパラメータまたは状態を動的に推定することもできる。プロファイルパラメータは、ユーザによる編集が可能なユーザプロファイルとして保管することができる。事前に定義されたプロファイルの組または動的推定に頼ることの他に、通知アーキテクチャは、ユーザが、例えばこれから「ｘ」時間の間、または所与の時刻まで、ユーザが重要な通知を除いて応じることができないなど、自分の状態をリアルタイムで指定できるようにする。
【００１７】
パラメータには、異なるタイプの通知によって異なる設定で邪魔されることに関するユーザのプリファレンスに関するデフォルト通知プリファレンスパラメータも含めることができ、これは、通知マネージャ２４による通知決定の基礎として使用することができ、これに基づいてユーザが変更を開始することができる。パラメータには、ユーザが異なる状況で（例えば、携帯電話によって、ポケットベルによってなど）どのように通知を受けたいかに関するデフォルトパラメータを含めることができる。パラメータには、異なる設定で異なるモードによって警告されることに関連する中断のコストの査定などを含めることができる。これには、ユーザが異なる位置にいる尤度、異なるデバイスが使用可能である尤度、および所与の時刻のユーザの注意の状況の尤度を示すコンテキストパラメータ、ならびに、ユーザが所与の時刻にどのように通知されることを望むかを示す通知パラメータを含めることができる。
【００１８】
コンテキストアナライザ２２によって保管された情報は、本発明の一態様に従って、アナライザによって決定されるコンテキスト情報を含む。コンテキスト情報は、アナライザ２２によって、この説明の後の節で詳細に説明するように、１つまたは複数のコンテキスト情報ソース（図示せず）に基づいてユーザの位置および注意の状況を識別することによって判定される。コンテキストアナライザ２２は、例えば、ユーザの自動車電話または携帯電話の一部である全地球測位システム（ＧＰＳ）を介して、ユーザの実際の位置を正確に判定することができる場合がある。アナライザは、曜日、時刻、ユーザのカレンダ内の日付などの情報の考慮およびユーザのアクティビティに関する観察を介して収集されたバックグラウンド査定および／または観察を考慮することによって、ユーザが所与の注意の状態である尤度を判定するために統計モデルも使用することができる。所与の注意の状態には、ユーザが通知を受けることに支障がないか、忙しく、通知を受けることに支障があるかを含めることができ、平日、週末、休日、および／または他の時／期間などの他の考慮事項を含めることができる。
【００１９】
ソース２６〜２８は、ユーザおよび／または他のエンティティに向けられた通知を生成する。例えば、ソース２６〜２８に、インターネットおよびネットワークベースの通信、ローカルデスクトップコンピュータベースの通信、および電話通信などの通信、ならびに、インテリジェントヘルプ、バックグラウンド照会、および自動化スケジューリングなどのソフトウェアサービスを含めることができる。通知ソースは、本明細書では、全般的に、情報、サービス、および／またはシステムイベントまたは世界のイベントに関する、ユーザまたはユーザの代理に向けられた、通知またはアラートとも称することができるイベントを生成するものと定義される。通知ソースを、イベントソースと呼ぶこともできる。
【００２０】
例えば、電子メールを、電子メール通知ソースによって通知として生成し、それに優先順位を付けることができ、通知を生成するアプリケーションプログラムまたはシステムが、電子メールに、ユーザにとってのその電子メールの適当な重要性または緊急性に対応する相対優先順位を割り当てる。電子メールは、ユーザにとっての相対的重要性に無関係に送信することもできる。デスクトップセントリック（ｄｅｓｋｔｏｐ−ｃｅｎｔｒｉｃ）通知には、ユーザが実行を望む潜在的に価値のあるサービス（例えば、メッセージからのスケジューリング）、ユーザが再検討することを望む情報（例えば、バックグラウンド照会から導出される）、またはデスクトップコンピュータによって生成されたエラーおよび／または他のアラートについてユーザに警告するという最終目標を持った自動化されたダイアログを含めることができる。インターネット関連サービスには、例えば時々の最新ニュースの見出しおよび株式相場などの、ユーザが購読する情報を含む通知を含めることができる。
【００２１】
他の通知には、バックグラウンド照会（例えば、ユーザが作業している間に、ユーザが現在扱っているテキストを再検討し、そのテキストに関するバックグラウンド照会が、定式化され、検索エンジンに発行される）および、スケジューリングプログラムおよび／または他のプログラムからのタスクのスケジューリングを含めることができる。通知ソース２６〜２８自体は、プッシュタイプまたはプルタイプのソースとすることができる。プッシュタイプのソースとは、購読申し込みの後に自動的に情報を送信する、ヘッドラインニュースおよび他のインターネット関連サービスなどの、対応する要求なしで自動的に情報を生成し、送信するソースである。プルタイプのソースとは、メールサーバをポーリングした後に受信される電子メールなど、要求に応答して情報を送信するソースである。他の通知ソースには、下記が含まれる。
【００２２】
・カレンダシステムなどの電子メールデスクトップアプリケーション、
・コンピュータシステム（例えば、システムアクティビティまたはシステムの問題に関する警告に関する情報をメッセージを用いてユーザに警告することができるものなど）、
・インターネット関連のサービス、予約情報、スケジューリング照会、
・１つまたは複数の共有フォルダ内の文書の変更またはある種類の文書の数の変化、
・情報に関する持続的なまたは永続的な照会に応答する新しい文書の可用性、および／または
・人とその存在、位置の変化、近接（例えば、旅行中に１０マイル以内に別の共働者または友人がいる場合に知らせて欲しいなど」）、または手が空いているかどうか（例えば、Ｓｔｅｖｅが話をする暇があり、フルビデオ会議をサポートできる高速リンクの近くにいる時に知らせて欲しいなど」）に関する情報の情報ソース。
【００２３】
通知シンク３６〜３８は、ユーザに通知を提供することができる。例えば、そのような通知シンク３６〜３８には、デスクトップおよび／またはラップトップコンピュータなどのコンピュータ、ハンドヘルドコンピュータ、携帯電話、陸線電話、ポケットベル、自動車ベースのコンピュータ、ならびに識別できる他のシステム／アプリケーションを含めることができる。シンク３６〜３８のいくつかが、他のシンクより豊富に通知を伝えることができることに留意されたい。例えば、デスクトップコンピュータは、通常はスピーカおよび比較的大きいカラーディスプレイを接続され、ローカルネットワークまたはインターネットに結合された時に情報を受信する帯域幅がより広い。したがって、通知は、デスクトップコンピュータによって、比較的豊富な形でユーザに伝えることができる。逆に、多くの携帯電話は、例えば、白黒である可能性がある、より小さいディスプレイを有し、比較的狭い帯域幅で情報を受信する。それに対応して、携帯電話によって伝えられる通知に関連する情報は、一般に、より短く、例えば電話のインタフェース機能に適応される可能性がある。したがって、通知の内容は、それが携帯電話とデスクトップコンピュータのどちらに送信されるかに応じて異なる可能性がある。本発明の一態様によれば、通知シンクが、例えばイベントまたは通知を、イベント購読サービスを介して購読する通知シンクを参照することができる。
【００２４】
通知マネージャ２４は、コンテキストアナライザによって保管され、かつ／または判定された情報にアクセスし、ソース２６〜２８から受け取った通知のどれを、シンク３６〜３８のどれに伝えるかを決定する。さらに、通知マネージャ２４は、シンク３６〜３８のどれが情報を送る先として選ばれたかに応じて、通知を伝える方法を決定することができる。例えば、選択されたシンク３６〜３８に供給する前に、通知を要約しなければならないと決定することができる。
【００２５】
本発明は、通知のどれを通知シンクのどれに伝えるか、および通知を伝える形に関してマネージャ２４が決定する方法に制限されない。一態様によれば、決定理論的分析を使用することができる。例えば、通知マネージャ２４は、ユーザの位置、注意、デバイス可用性、および、アラートがない場合にユーザが情報にアクセスするまでの時間を含む変数に関する重要な不確実性を推定するように適合させることができる。通知マネージャ２４は、ユーザに通知について警告するかどうかと、そうする場合に、要約の性質および通知を中継するのに使用される適当な１つまたは複数のデバイスに関する通知決定を行うことができる。一般に、通知マネージャ２４は、通知の正味の期待価値を判定する。それを行う際に、通知マネージャは、下記を考慮する。
【００２６】
・各使用可能な通知シンクの忠実度および送信信頼性、
・ユーザの気を散らすことの注意的なコスト、
・ユーザにとっての情報の新規性、
・ユーザが自分で情報を再検討するまでの時間、
・情報の潜在的なコンテキスト応答の価値、および／または
・通知に含まれる情報の経時的に増えるかつ／または減る価値。
【００２７】
したがって、不確実性に関して行われる推定を、例えばユーザのある注意の状態に対して、特定のデバイスの特定のモードの使用によるユーザに対する中断のコストなどの価値の期待される尤度として生成することができる。通知マネージャ２４は、下記の１つまたは複数に関する決定を行うことができる。
【００２８】
・ユーザが現在注目し、行っているもの（例えば、コンテキスト情報に基づく）、
・ユーザが現在どこにいるか、
・情報がどれほど重要か、
・通知を延期することのコストはどれほどか、
・通知がどのように気を散らすか、
・ユーザに到達する尤度はどれほどか、および、
・所与の通知シンクの特定のモードの使用に関連する忠実度の消失はどれほどか。
【００２９】
したがって、通知マネージャ２４は、保留中およびアクティブな通知の、決定理論的分析などの分析を行い、情報シンクおよび情報ソースによって提供されるコンテキスト依存変数を評価し、ユーザが情報を再検討する可能性が高い時までの時間とユーザの位置および現在の注意の状態などの選択された不確実性を推定することができる。
【００３０】
本明細書で使用される際に、推定は、一般に、イベントおよび／またはデータを介して取り込まれる一組の観察からの、システム１０、環境、および／またはユーザに関する推理またはそれらの状態の推定の処理を指す。推定は、例えば、特定のコンテキストまたはアクションを識別するのに使用することができ、あるいは、状態に関する確率分布を生成することができる。推定は、確率的すなわち、データおよびイベントの検討に基づく当の状態に関する確率分布の計算とすることができる。推定は、イベントおよび／またはデータの組からより高水準のイベントを合成するのに使用される技法を指すこともできる。そのような推定は、観察されたイベントおよび／または保管されたイベントデータの組、イベントが密な時間的近接で相関するか否か、およびイベントおよびデータが１つまたは複数のイベントソースおよびデータソースから来たかどうか、からの新しいイベントまたはアクションの構成をもたらす。
【００３１】
さらに、通知マネージャ２４は、パーソナライズされた決定理論的分析の代わりにまたはそれをサポートするために、コンテキストアナライザ２２によってユーザプロファイルに保管された情報にアクセスすることができる。例えば、ユーザプロファイルによって、所与の時刻に、通知が所定の分類（例えば重要性）レベルを有する場合に限って、ユーザが、ポケットベルを介して通知されることを好むことを示すことができる。そのような情報は、決定理論的分析を開始する基準線として使用することができ、あるいは、通知マネージャ２４が、ユーザに通知するかどうかとその方法を決定する形とすることができる。
【００３２】
本発明の一態様によれば、通知プラットフォームアーキテクチャ１０は、イベンティング（ｅｖｅｎｔｉｎｇ）インフラストラクチャまたはメッセージングインフラストラクチャの上に常駐する層として構成することができる。しかし、本発明は、特定のイベンティングインフラストラクチャに制限されない。そのようなイベンティングおよびメッセージングのシステムおよびプロトコルには、下記を含めることができる。
【００３３】
・ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）または当技術分野で既知のＨＴＴＰ拡張、
・当技術分野で既知のＳｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）、
・当技術分野で既知のＷｉｎｄｏｗｓ（登録商標） Ｍａｎａｇｅｍｅｎｔ Ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ（ＷＭＩ）、
・当技術分野で既知のＪｉｎｉ、および、
・例えばパケット交換プロトコルに基づくものなどの、実質的にすべてのタイプの通信プロトコル。
【００３４】
さらに、このアーキテクチャは、当業者が諒解できるように、柔軟な分散計算インフラストラクチャの上に常駐する層として構成することができる。したがって、通知プラットフォームアーキテクチャは、例えば、ソースが通知、アラート、およびイベントを送信する形として、また、シンクが通知、アラート、およびイベントを受信する形として、基礎となるインフラストラクチャを使用することができる。しかし、本発明は、これに制限されない。
【００３５】
図２を参照して、この説明の前の節で説明した通知アーキテクチャのコンテキストアナライザ２２を、詳細に説明する。図２に示されたコンテキストアナライザ２２には、ユーザ通知プリファレンスストア５２、ユーザコンテキストプロファイルストア５５を含むユーザコンテキストモジュール５４、およびホワイトボード５７が含まれる。本発明の一態様によるコンテキストアナライザ２２は、コンピュータのプロセッサによって、メモリなどの計算機可読媒体から実行される１つまたは複数のコンピュータプログラムとして実施することができる。
【００３６】
プリファレンスストア５２には、ユーザが編集でき修正できるユーザプロファイルなどの、ユーザのデフォルト通知プリファレンスなどの、ユーザに関する通知パラメータが保管される。プリファレンスストア５２は、ユーザに通知する方法に影響するパラメータに関する情報が保管されるストアとみなすことができる。ユーザコンテキストモジュール５４は、例えば、ホワイトボード５７に発行される１つまたは複数のコンテキスト情報ソース６０に基づいて、ユーザの現在のコンテキストを判定する。ユーザコンテキストプロファイルストア５５には、ユーザが編集でき修正できる、ユーザに関するデフォルトコンテキスト設定などの、ユーザに関するコンテキストパラメータが保管される。すなわち、ユーザコンテキストモジュール５４は、プロファイルストア５５からの情報にアクセスし、かつ／または、１つまたは複数のコンテキスト情報ソース６０を介する生のセンシングを用いてプロファイルストア５５内の前の１組のビリーフ（belief）を更新することによって、ユーザの現在のコンテキスト情報に関する最適の推測または推定を提供する。プロファイルストア５５は、例えば、先験的なユーザの位置およびユーザが行っていることが保管されるストアとみなすことができる。
【００３７】
ユーザコンテキストプロファイルストア５５は、決定的プロファイルまたは確率的プロファイルとして情報を取り込む、事前に査定され、かつ／または事前に定義されたユーザプロファイルとすることができる。プロファイルは、通常の位置と、アクティビティと、デバイス可用性と、時刻、日の種類、１つまたは他のデバイスとのユーザ対話などの観察の関数としての通知の異なるクラスのコストおよび値とすることができる。日の種類には、例えば、平日、週末、および休日を含めることができる。ユーザコンテキストモジュール５４は、ユーザの現在のまたは将来の位置および注意の状態など、ユーザのコンテキストまたは状態の諸態様を能動的に判定または推定することができる。さらに、コンテキストの実際の状態は、ホワイトボード５７を介してコンテキスト情報ソース６０から直接にアクセスすることができ、かつ／または、下で詳細に説明するベイズ推定などの推定方法を介して、様々なそのような観察から推定することができる。
【００３８】
コンテキスト情報ソース６０は、ユーザの注意の状態および位置に関して、ホワイトボード５７を介してコンテキストモジュール５４に情報を供給し、その情報から、モジュール５４が、ユーザの現在のコンテキスト（例えば、ユーザの現在の注意の状態および位置）に関する判断を行うことができる。さらに、本発明は、特定の数またはタイプのコンテキストソース６０にも、ユーザコンテキストモジュール５４によって推定またはアクセスされる情報のタイプにも制限されない。しかし、コンテキストソース６０に、例えば、マウス情報、キーボード情報、アプリケーション情報（例えば、アプリケーションが現在ユーザのフォーカス（focus）を受け取っているかどうか）、周囲の音声および発声情報、デスクトップ上のウィンドウ内のテキスト情報など、複数のデスクトップ情報およびイベントを含めることができる。ホワイトボード５７に、共通のストレージエリアを含めることができ、このストレージに、コンテキスト情報ソース６０が、情報を公開し、このストレージから、ソースおよびコンテキストモジュール５４を含む複数のコンポーネントが、この情報にアクセスすることができる。通知またはアラートとも称するイベントには、一般に、世界の１つまたは複数の状態に関する観察に関する情報を含めることができる。そのような状態には、システムコンポーネントの状況、ユーザのアクティビティ、および／または環境に関する測定値を含めることができる。さらに、イベントは、測定デバイスおよび／またはイベントのソースの能動的ポーリングによって、変更時に送信される情報の受信によって、および／または一定または可変のイベントハートビートごとに、生成することができる。
【００３９】
他のタイプのコンテキストソース６０には、ユーザの個人情報管理（ＰＩＭ）情報が含まれ、この情報は、一般に、例えば、ユーザのスケジュールに関するスケジューリング情報を提供することができる。例えば、全地球測位システム（ＧＰＳ）および／または、位置を判定できる、ユーザの携帯電話、ＰＤＡ、またはラップトップによって判定されるユーザの位置ならびに現在時刻も、コンテキストソース６０のタイプである。さらに、リアルタイムモバイルデバイス使用が、コンテキストソース６０のタイプである。例えば、携帯電話などのモバイルデバイスは、ユーザによって現在アクセスされつつあるかどうか、ならびにデバイスの方位および傾斜（例えば、デバイス使用に関する情報をも示す）と、加速度および速度（例えば、ユーザが移動中であるか否かを示す）を判定することができる。
【００４０】
図３を参照すると、上で説明した通知ソースが詳細に示されている。通知ソース２６〜２８は、通常は、通知マネージャ２４に伝えられる通知を生成し、通知マネージャ２４は、いつ通知を行わなければならないかと、そうである場合に、どの通知を通知シンク３６〜３８のどれにどの順番で伝えなければならないかを判定する。
【００４１】
本発明の一態様によれば、通知ソース２６〜２８は、本明細書で通知ソーススキーマまたはソーススキーマと称する、属性および関係の標準記述内で、下記のパラメータの１つまたは複数を有することができる。スキーマを、上で説明したソース、シンク、およびコンテキスト情報ソースについて設けることができることに留意されたい。そのようなスキーマは、異なるコンポーネントに関する宣言情報を提供し、ソース２６〜２８、通知マネージャ２４、シンク３６〜３８、およびコンテキストアナライザ２２が互いにセマンティック情報を共有できるようにすることができる。したがって、異なるスキーマによって、通知に関する性質、緊急性、およびデバイスシグナリングモーダリティに関する情報が提供される。すなわち、スキーマは、一般に、クラスおよびクラス間の関係の集合として定義することができ、これによって、例えば、イベントまたは通知クラスに関する情報、ソース、ターゲット、イベントまたは通知のセマンティクス、存在論的コンテキスト情報、観察信頼性、および実質的にすべてのサービス品質属性を含む、通知およびイベントの構造が定義される。
【００４２】
通知ソーススキーマのパラメータ（図示せず）には、メッセージクラス、関連、重要性、時間臨界、新規性、内容属性、忠実度トレードオフ、および／またはソース情報要約情報のうちの１つまたは複数を含めることができる。通知ソースによって生成される通知のメッセージクラスは、例えば、電子メール、インスタントメッセージ、数値的財務更新、およびデスクトップサービスなど、通知の通信のタイプを示す。通知ソースによって生成される通知の関連は、その通知に含まれる情報が、１つまたは複数の指定されたコンテキストに関して関連する尤度を示す。例えば、関連は、ソースが所与のコンテキストに関連するか否かを示す論理フラグによって提供することができる。通知の新規性は、ユーザが既にその通知に含まれる情報を知っている尤度を示す。すなわち、新規性は、その情報が、ユーザにとって経時的に新しいかどうかである（ユーザが今その情報を知っているかどうかを示し、それについて警告されずにユーザが将来にその情報を知る場合に、それがいつであるかを示す）。
【００４３】
通知に関連する忠実度トレードオフは、例えば指定された許容される切捨および／または要約の異なる形態から生じる可能性がある、通知内の情報の価値の消失を示す。そのような切捨および／または要約は、最初に生成された完全な通知をシンクが受信できなくする帯域幅および／または他の制限を有する、あるタイプの通知シンク３６〜３８に通知を伝えるために必要になる可能性がある。忠実度は、一般に、通知に関連する元の内容の完全さの性質および／または度合を指す。例えば、長い電子メールメッセージは、携帯電話によって許容される１００文字の最大値までに切り捨てられるか他の形で要約され、忠実度の消失をこうむる可能性がある。同様に、テキストとグラフィックスの内容を含む元のメッセージが、テキスト機能だけを有するデバイスを介して送信される時に、忠実度の消失をこうむる。さらに、あるデバイスが、ソースから入手可能な完全な解像度の一部を示すことしかできない場合がある。忠実度トレードオフは、順序付け（例えば、まずグラフィックス、次にサウンドの順でのレンダリングの重要性）および／または通知の内容の総合的価値が忠実度の変化に伴ってどのように減少するかを示すコスト関数のいずれかに関して示される、ソースの忠実度プリファレンスの組を指す。例えば、忠実度トレードオフによって、完全な電子メールメッセージの送信に関連するすべての価値が、切捨の量の増加に伴ってどのように変化するかを記述することができる。例えば、コンテキスト属性に、コアメッセージにテキスト、グラフィックス、およびオーディオのコンポーネントが含まれるかどうかなどの情報を表す、内容の性質の要約を含めることができる。内容自体は、通知のメッセージ内容を構成する、実際のグラフィックス、テキスト、および／またはオーディオである。
【００４４】
通知の重要性は、情報が現在のコンテキストに関連すると仮定して、通知に含まれる情報の、ユーザにとっての価値を指す。例えば、重要性は、ユーザにとっての情報の価値の金額として表すことができる。時間臨界は、通知に含まれる情報の価値の時間依存の変化すなわち、情報の価値が経時的にどのように変化するかを示す。すべてではないがほとんどの場合に、通知の情報の価値は、時間に伴って減少する。これを、図４に示す。グラフ８０に、経時的にマッピングされた通知の有用性が示されている。開始時を表すグラフ内の点８４で、通知の重要性が示されており、曲線８６は、経時的な有用性の減少を示す。
【００４５】
図３に戻って、異なる通知ソースまたはソースタイプのデフォルト属性およびスキーマテンプレートを、図２のストア５２などのユーザ通知プリファレンスストアに保管された通知ソースプロファイル内で使用可能にすることができる。そのようなデフォルトテンプレートに、通知ソースによって供給される値をオーバーライドするか、ソースによって供給されるスキーマにない時に属性を供給するように指示することができる。ソース要約情報によって、ソースが、情報の状況の全般的な要約およびソースから入手可能な潜在的な通知をポストできるようになる。例えば、メッセージングソースからのソース要約情報に、少なくともある優先順位である未読メッセージの総数に関する情報、ユーザと通信しようとする人による試みの状況、および／または他の要約情報を含めることができる。
【００４６】
通知シンク３６〜３８は、それによってユーザまたは他のエンティティが通知に含まれる情報について通知を受けることができる、実質的にすべてのデバイスまたはアプリケーションとすることができる。特定の通知を伝えるのにどのシンクを使用するかに関する選択は、通知マネージャ２４によって決定される。
【００４７】
通知シンク３６〜３８は、スキーマ内で供給される下記のパラメータのうちの１つまたは複数を有することができる。このパラメータには、デバイスクラス、シグナリング（警告）のモード、および、関連するモードについて、例えば、忠実度／レンダリング機能、送信信頼性、通信の実際のコスト、および／または中断の注意的コストを含めることができる。警告属性のパラメータ化された制御に適合されたデバイスについて、そのデバイスのスキーマに、さらに、警告属性およびその属性を制御するパラメタの記述、他の属性（例えば送信信頼性、配布のコストなど）を警告属性の異なる設定を用いて変更する機能を含めることができる。通知シンクのスキーマは、通知デバイスがその性質および機能に関するセマンティック情報を通知マネージャ２４および／またはシステムの他のコンポーネントと通信する形を提供する。異なるデバイスタイプのデフォルトの属性およびスキーマテンプレートは、前の節で説明した図２のストア５２などのユーザ通知プリファレンスストアに保管されたデバイスプロファイル内で使用可能にすることができる。そのようなデフォルトテンプレートに、デバイスによって供給される値をオーバーライドするか、そのようなデバイスによって提供されるスキーマにない時に属性を供給するように指示することができる。
【００４８】
スキーマパラメータのそれぞれを、これから順番に説明する。デバイスのクラスは、例えば携帯電話、デスクトップコンピュータ、およびラップトップコンピュータなどのデバイスのタイプを指す。クラスは、モバイルデバイスまたは文房具デバイスなどのより一般的なものとすることもできる。シグナリングのモードは、所与のデバイスが通知についてユーザに警告できる形を指す。デバイスは、１つまたは複数の通知モードを有することができる。例えば、携帯電話は、振動だけ、ある音量の呼び出し音だけ、および／または振動と呼び出し音の両方を与えることができる。さらに、警告システムのデスクトップディスプレイは、複数の別個のモードに分解することができる（例えば、ディスプレイの右上角の小さい通知ウィンドウ対画面最上部の小さいサムネール、音声告知ありまたはなし）。事前に定義された挙動の組に制限される以外に、デバイスは、デバイス定義の一部としてのパラメータの関数である警告属性を有するモードをイネーブルすることができる。モードに関するそのような継続的な警告パラメータは、例えば、デスクトップでアラートを再生するボリューム、携帯電話での呼び出し音、警告ウィンドウのサイズなどのコントロールを表す。
【００４９】
通知シンク３６〜３８のモードの送信信頼性は、ユーザが、そのモードのシンクを介してユーザに伝えられる通知に関する通信されたアラートを受信する尤度を示す。送信信頼性は、デバイス可用性およびユーザのコンテキストに依存する可能性があり、あるデバイスの異なるモードの送信信頼性は、ユーザの位置および注意などのコンテキスト属性によって条件付けすることができる。一意の位置および一意の注意の状態などの属性のクロス乗積として定義され、そのような属性（例えば、自宅以外のすべての位置について、午前８時から正午までのすべての時刻など）の抽象（abstraction）として作成される離接（disjunction）として定義される、１つまたは複数の一意のコンテキスト状態に関する送信信頼性を指定することもできる。例えば、ユーザが現在どこにいるかに応じて、携帯電話に送信される情報が、特にユーザが間欠性の受信地域を有する領域内にいる場合またはユーザがこの位置で携帯電話を有する傾向がない時（例えば家族の休日）に、必ずしもユーザに到達しない可能性がある。また、コンテキストは、環境ノイズおよび／またはコンテキストの他のマスキング特性または気を散らす特性に起因して、送信信頼性に影響する可能性がある。
【００５０】
通信の実際のコストは、シンクに伝えられる通知内に含まれる時の、ユーザへの情報の通信の実際のコストを示す。例えば、このコストに、携帯電話送信に関連する料金を含めることができる。中断のコストには、特定のコンテキストで、デバイスの特定のモードによって使用されるアラートに関連する中断に関連する注意のコストが含まれる。注意のコストは、通常は、ユーザの特定の注意のフォーカスに敏感である。忠実度／レンダリング機能は、やはりあるモードでの、デバイスのテキスト、グラフィックス、およびオーディオ／触覚機能の記述である。例えば、携帯電話のテキスト限界は、単一のメッセージについて１００文字とすることができ、電話は、グラフィックス機能を有しない場合がある。
【００５１】
図５に移ると、インタフェース９０に、ユーザの現在のコンテキストを判定する際にコンテキストアナライザ２２が使用することができる、ユーザによって選択可能なコンテキスト指定が示されている。ユーザによる直接指定および／またはユーザが修正可能なプロファイルによるユーザコンテキストの決定を説明する。ユーザのコンテキストには、ユーザの注意のフォーカスすなわち、ユーザが現在通知アラートの受信に敏感に反応するかどうか、ならびにユーザの現在の位置を含めることができる。しかし、本発明は、これに制限されない。
【００５２】
ユーザによるコンテキストの直接指定によって、ユーザが、自分がアラートを受け取る暇があるかどうかと、アラートの受け取りを望むかどうかを示すことができるようになる。デフォルトプロファイル（図示せず）を使用して、デフォルトの注意の状態およびユーザがアラートを受け取ることができるデフォルトの位置を示すことができる。デフォルトプロファイルは、ユーザが望み通りに修正することができる。
【００５３】
図５を参照すると、インタフェース９０に、本発明の一態様に従って、コンテキストの直接指定をどのように実施することができるかが示されている。例えば、ウィンドウ９１が、注意のフォーカスセクション９２および位置セクション９４を有する。フォーカスセクション９２では、ユーザが、１つまたは複数のチェックボックス９６にチェックマークを付けることができ、例えば、ユーザが常時アラートを受け取る暇があるかどうか（ａｌｗａｙｓ ａｖａｉｌａｂｌｅ）、ユーザがアラートを受け取る暇が絶対にないかどうか（ｎｅｖｅｒ ａｖａｉｌａｂｌｅ）、および、ユーザが、所定の閾値を超える重要性レベルを有するアラートだけを受け取る暇があるかどうか（ａｖａｉｌａｂｌｅ ｔｏ ｒｅｃｅｉｖｅ ａｌｅｒｔｓ ｔｈａｔ ｈａｓ ａｎ ｉｍｐｏｒｔａｎｃｅ ｌｅｖｅｌ ｇｒｅａｔｅｒ ｔｈａｎ）を示すことができる。他のアベイラビリティセクションを設けることができることを諒解されたい。図５からわかるように、閾値をドル単位で測定することができるが、これは例示のみを目的とし、本発明はこれに制限されない。ユーザは、ボックス９８の閾値を、新しい値を直接に入力することによって、または矢印１００を介して閾値を増減することによって、増やすことができる。
【００５４】
位置セクション９４では、ユーザが、１つまたは複数のチェックボックス１０２にチェックマークを付けて、アラートが伝えられることをユーザが望む場所を指定することができる。例えば、ユーザは、デスクトップに、電子メールによって、ラップトップに、携帯電話に、自動車の中に、ポケットベルに、または携帯情報端末（ＰＤＡ）デバイスに、などにアラートを伝えさせることができる。しかし、これが例示のみであり、本発明自体はこれに制限されないことを諒解されたい。
【００５５】
ウィンドウ９１は、セクション９２のチェックボックス９６およびボックス９８とセクション９４のチェックボックス１０２についてデフォルトを事前にセットすることができ、デフォルトユーザプロファイルとみなすことができる。プロファイルは、ユーザがデフォルト選択を自分の望みの選択にオーバーライドできるという点で、ユーザ修正可能である。他のタイプのプロファイルも、本発明に従って使用することができる。
【００５６】
図６を参照すると、本発明による、例えば１つまたは複数のセンサを使用する、直接測定によるユーザコンテキストの判定が示されている。ユーザのコンテキストには、ユーザの注意のフォーカスならびにユーザの現在位置を含めることができる。しかし、本発明自体は、これに制限されない。コンテキストの直接測定は、センサを使用して、ユーザが現在アラートの受信に敏感に反応するかどうかを検出でき、ユーザが現在どこにいるかを検出できることを示す。本発明の一態様によれば、推定分析を、直接測定と共に使用して、この説明の後の節で説明するように、ユーザコンテキストを判定することができる。
【００５７】
図６を参照すると、ユーザコンテキストの直接測定を達成できるシステム１１０が示されている。システム１１０には、コンテキストアナライザ１１２が含まれ、システム１１０は、例えば、複数のセンサ１１４〜１２０すなわち、携帯電話１１４、ビデオカメラ１１５、マイクロホン１１６、キーボード１１７、ＰＤＡ１１８、乗物１１９、およびＧＰＳ１２０に、通信的に結合される。図６に示されたセンサ１１４〜１２０は、例示のみを目的とし、本発明自体に対する制限または制約を表すものではない。用語センサは、本明細書では、全般的かつ過度に包含的な用語であり、それによってコンテキストアナライザ１１２がユーザの現在の注意のフォーカスが何であるかおよび／またはユーザの現在位置がどこであるかを判定できるすべての装置または手段を意味する。
【００５８】
例えば、ユーザが携帯電話１１４の電源を入れている場合に、これは、ユーザが携帯電話１１４でアラートを受信できることを示す。しかし、ユーザが、現在携帯電話１１４で通話中である場合には、これは、ユーザが自分の注意のフォーカスを別の何か（すなわち、現在の通話）に向け、ユーザが、現在は通知アラートで邪魔されてはならないことを示す。ビデオカメラ１１５は、例えば、ユーザのオフィスにあって、ユーザが自分のオフィスにいるかどうか（すなわちユーザの位置）を検出でき、他の人もそのオフィスにおり、彼らと会議していることが示され、ユーザを邪魔してはならない（すなわちユーザのフォーカス）かどうかを検出することができる。同様に、マイクロホン１１６も、ユーザのオフィスにあって、ユーザが誰かと話しており、ユーザを邪魔してはならないかどうか、または、ユーザがキーボードで入力中（例えば、それから発する音を介して）であり、やはり現在はユーザを邪魔してはならないかどうかを検出することができる。キーボード１１７も、ユーザが現在それによって入力中であるかどうかを判定するのに使用することができ、例えば、ユーザが非常に早く打鍵している場合に、これによって、ユーザがコンピュータ関連のアクティビティにフォーカスを合わせており、過度に邪魔してはならないことを示すことができる（および、ユーザが実際に自分のオフィスにいることを示すこともできる）。
【００５９】
ＰＤＡデバイス１１８がユーザによってアクセスされつつある場合には、これによって、ユーザデバイス１１８でアラートを受信できることを示すことができる。すなわち、通知を伝えなければならない場所は、デバイス１１８がある場所である。デバイス１１８は、ユーザの現在の注意のフォーカスを判定するのにも使用することができる。乗物１１９は、ユーザが現在その乗物の中にいるかどうか、すなわち、乗物が現在ユーザによって操作されているかどうかを判定するのに使用することができる。さらに、例えば、乗物の速度を検討して、ユーザのフォーカスが何であるかを判定することができる。例えば、速度が所定の速度を超える場合に、ユーザが運転にフォーカスを合わせており、通知アラートによって悩まされてはならないと判定することができる。ＧＰＳデバイス１２０も、当技術分野で既知のように、ユーザの現在位置を確認するのに使用することができる。
【００６０】
この詳細な説明の以下の節では、ユーザ修正可能なルールによるユーザコンテキストの判定を説明する。ユーザのコンテキストには、ユーザの注意のフォーカスならびにユーザの現在位置を含めることができる。しかし、本発明は、これに制限されない。ルールを介するコンテキストの判定によって、ｉｆ−ｔｈｅｎルールの階層セットに従って、ユーザの位置および／または注意のフォーカスを判定できることが示される。
【００６１】
図７を参照すると、図に、例示的なルールの階層順序付きセット１３０が示されている。ルールのセット１３０では、例えば、ルール１３２、１３３、１３４、１３５、１３６、１３７、および１３８が示される。他のルールを、同様に構成できることに留意されたい。図７からわかるように、ルール１３３および１３４は、１３２に従属し、ルール１３４は、ルール１３３に従属し、ルール１３８は、ルール１３８に従属する。ルールは、ルール１３２が最初にテストされ、真であることがわかった場合に、ルール１３３がテストされ、ルール１３３が真であることがわかった場合に、ルール１３４がテストされ、以下同様になるように順序付けられる。ルール１３３が偽であることがわかった場合には、ルール１３５をテストする。ルール１３２が偽であることがわかった場合には、ルール１３６をテストし、これが偽であることがわかった場合には、ルール１３７がテストされ、これが真であることがわかった場合には、ルール１３８がテストされる。ルールは、ユーザが作成可能および／または修正可能であることが望ましい。ｏｔｈｅｒｗｉｓｅタイプのルールも、ルールのセット１３０に含めることができる（例えば、あるｉｆ−ｔｈｅｎルールが偽であることがわかった場合に、ｏｔｈｅｒｗｉｓｅルールが制御ルールになる）。
【００６２】
したがって、ユーザのコンテキストが判定されるように、ルールのセットをユーザが構成することができる。例えば、位置に関して、ルールのセットを、第１のルールで現在の日が平日であるかどうかをテストするものとすることができる。そうである場合には、第１のルールに従属する第２のルールで、現在の時刻が午前９時と午後５時の間であるかどうかをテストする。そうである場合には、第２のルールから、ユーザが自分のオフィスに位置することが示され、そうでない場合には、ユーザが自宅にいる。第１のルールが偽であるとわかった（現在の日が週末であって平日でない）場合には、ｏｔｈｅｒｗｉｓｅルールで、ユーザが自宅にいることを示すことができる。この例は、本発明自体に対する限定的または制限的な例であることを意図されたものではなく、１つまたは複数の他のルールを同様に構成することもできることに留意されたい。
【００６３】
この説明の以下の節では、統計モデルおよび／またはベイズモデルを使用することによるなど、推定分析によるユーザコンテキストの判定を説明する。推定分析を介するコンテキスト判定が、いくつかの態様で、既に述べたセンサを介する直接測定などの他の判定に頼ることができることに留意されたい。本明細書で使用される推定分析は、複数の入力変数に対して推定処理を使用して、出力変数すなわちユーザの現在のコンテキストをもたらすことを指す。分析には、一態様で、統計モデルおよび／またはベイズモデルの使用を含めることができる。
【００６４】
図８を参照すると、本発明の一態様による、推定エンジン１４２によって推定分析を実行して、ユーザのコンテキスト１４４を判定するシステム１４０の図が示されている。エンジン１４２は、一態様では、メモリなどのコンピュータ可読媒体からコンピュータのプロセッサによって実行されるコンピュータプログラムである。ユーザコンテキスト１４４は、エンジン１４２の出力変数とみなすことができる。
【００６５】
エンジン１４２は、１つまたは複数の入力変数を処理して、コンテキスト決定を行うことができる。そのような入力変数には、例えば、この説明の前の節でコンテキスト判定の直接測定手法に関して説明したセンサなどの１つまたは複数のセンサ１４８、ならびに、ユーザのスケジューリングコンピュータプログラムまたは個人情報管理（ＰＩＭ）コンピュータプログラム、および／またはユーザのＰＤＡデバイスでアクセスすることができる、クロック１５０およびカレンダ１５２によって表される現在の時刻および日付を含めることができる。他の入力変数も、図８に示されたものの他に、検討することができる。図８の変数は、本発明自体に対する制限または制約になることを意図されたものではない。
【００６６】
図９および１０を参照すると、本発明による、上で説明した推定エンジンによって実行することができる統計モデルおよび／またはベイズモデルによって提供されるものなどの例示的推定モデルが示されている。一般に、コンピュータシステムは、ユーザの状態の詳細に関して多少不確実になる可能性がある。したがって、ユーザの注意または他の状態に関する推定を不確実性の下で行うことができる確率モデルを構成することができる。ベイズモデルは、ユーザの注意のフォーカスの確率分布を推定することができる。そのような注意の状態は、プロトタイプ的状況のセットまたは、ユーザによって対処される認識の課題の別個のクラスのセットのより抽象的な表現として定式化することができる。その代わりに、注意のフォーカスの連続的測定に関する推定を行うモデル、および／または、異なるタイプの通知に関する中断のコストの確率分布を直接に推定するモデルを、定式化することができる。
【００６７】
ユーザのアクティビティおよび位置に関する観察のセットに基づいて代替アクティビティコンテキストまたは状態の確率を推定することができるベイズネットワークを、使用することができる。一例として、図９に、単一の時間期間に関するユーザの注意のフォーカスを推定するベイズネットワーク１５４を示す。変数である注意のフォーカス１５６の状態は、デスクトップコンテキストおよび非デスクトップコンテキストを指す。このモデルで検討される例示的な注意のコンテキストには、例えば、状況の意識、理解、特定でないバックグラウンドタスク、フォーカスを合わされた内容の生成または再検討、軽い内容の生成または再検討、文書のブラウジング、オフィスでの会議、オフィス以外での会議、プレゼンテーションを聞くこと、プライベートな時間、家族との時間、個人的フォーカス、くつろいだ会話および旅行が含まれる。ベイズネットワーク１５４は、ユーザの現在の注意および位置が、ユーザのスケジューリングされた面会１５８、時刻１６０、および締切期限の近接１６２によって影響されることを示す。ユーザの注意の確率分布は、例えばユーザのオフィスで監視される環境音響信号１６４の状況の要約による影響も受ける。環境音響信号１６４の経時的なセグメントが、アクティビティおよび会話の存在に関する手がかり／入力を提供する。ソフトウェアアプリケーションの状況および構成と、コンピュータと対話するユーザによって生成されたユーザアクティビティの進行中のストリームも、ユーザの注意に関する証拠のソースを提供する。
【００６８】
ネットワーク１５４に示されているように、オペレーティングシステムまたは他の環境で現在最上位のフォーカス（focus）にあるソフトウェアアプリケーション１６６が、ユーザのフォーカスおよびタスクの性質に影響し、ユーザの注意の状況およびフォーカスがあるアプリケーションが、一緒に、コンピュータセントリックアクティビティに影響する。そのようなアクティビティには、マウスアクションおよびキーボードアクションのシーケンスから作成されるユーザアクティビティのストリームと、より広い時間範囲にわたるアプリケーション使用の高水準パターンが含まれる。そのようなパターンには、電子メールセントリックおよびワードプロセッサセントリックが含まれ、そのようなパターンは、複数のアプリケーションがインターリーブされる形に伴うアクティビティのプロトタイプ的クラスを指す。
【００６９】
図１０に、異なる時間の期間でのコンテキスト変数の間のユーザの注意のフォーカスのベイズモデル１６８を示す。マルコフ時間依存性のセットが、モデル１６８によって示されており、この図では、コンテキスト変数の過去の状態が、ユーザの状態の現在の判定で考慮される。リアルタイムで、そのようなベイズモデル１６８によって、例えば、オンラインカレンダによって供給される情報と、イベント感知システム（図示せず）によって報告される部屋の音響およびユーザアクティビティに関する観察のストリームを検討し、ユーザの注意の確率分布に関する推定結果を提供し続ける。
【００７０】
図１１、１２、１３、１５、１７、および２１に、本発明によるコンテキストアナライザ、通知マネージャ、およびユーザインタフェースなどの、通知アーキテクチャの諸部分を提供する方法を示す。説明を単純にするために、方法を、一連の行為として図示し、説明するが、本発明に従って、一部の行為を、図示され本明細書で説明されるものと異なる順序でおよび／または他の行為と同時に行うことができるので、本発明が、行為の順序によって制限されないことを理解し、諒解されたい。例えば、当業者は、方法を、その代わりに、状態図など、相互に関連する一連の状態またはイベントとして表現することができることを理解し、諒解するであろう。さらに、示された行為のすべてが、本発明による方法の実施に必要とは限らない。
【００７１】
この方法は、いくつかの態様で、コンピュータ実施することができる。コンピュータ実施される方法は、少なくとも部分的にコンピュータで動作する１つまたは複数のプログラムとして、すなわち、コンピュータの処理システムによってメモリなどのコンピュータ可読媒体から実行されるプログラムとして、実現されることが望ましい。プログラムは、別のコンピュータへの配布とインストールと実行のために、フロッピー（登録商標）ディスクまたはＣＤ−ＲＯＭなどの計算機可読媒体に保管可能であることが望ましい。１つまたは複数のプログラムを、下で図２３に関して説明するものなど、コンピュータシステムまたはコンピュータの一部にすることができる。
【００７２】
図１１を参照すると、流れ図１７０に、本発明によるユーザのコンテキストの判定が示されている。この処理には、１７１でユーザの位置を判定することと、１７２でユーザのフォーカスを判定することが含まれる。これらの行為は、前に説明した手法の１つまたは複数によって達成することができる。例えば、プロファイルを使用することができ、ユーザが自分のコンテキストを指定することができ、コンテキストの直接測定を使用することができ、ルールのセットに従うことができ、ベイズモデルまたは統計モデルを介するなどの推定分析を実行することもできる。他の分析を使用して、ユーザのコンテキストを判定できることを諒解されたい。例えば、誰かがコンピュータの前にいる場合に気付き、その人がコンピュータを見ているか否かに気付く、一体化されたビデオカメラソースを設けることができる。しかし、本発明のシステムは、カメラの有無にかかわらずに動作できることに留意されたい。ソースのすべてについて、システムは、コンテキストに関する推定のために特定のソースを必要とすることなく、実質的に任意の数の使用可能な入力ソースと共に動作することができる。さらに、他の態様では、ユーザの位置および注意の感知を与える、小さいＰＤＡ上の一体化された加速度計、マイクロホン、および近接検出器を設けることができる。
【００７３】
図１２を参照すると、流れ図１７３に、本発明の一態様による通知マネージャの決定処理が示されている。１７４で、１つまたは複数の通知ソースが、通知を生成し、その通知が、通知マネージャによって受信される。１７５で、コンテキストアナライザが、ユーザに関するコンテキスト情報を生成／判定し、これが、１７６で、通知マネージャによって受け取られる。すなわち、本発明の一態様によれば、１７５で、この説明の前の節で説明したように、コンテキストアナライザが、ユーザの現在の注意の状況および位置を示すユーザのコンテキスト情報プロファイルにアクセスし、かつ／または、ユーザの現在の注意の状況および位置に関するリアルタイム情報を、１つまたは複数のコンテキスト情報ソースから査定する。
【００７４】
１７７で、通知マネージャが、コンテキストアナライザから受け取ったコンテキスト情報に部分的に基づいて、どの通知をどの通知シンクに伝えるかを決定する。通知マネージャは、コンテキストアナライザによって保管されるユーザの通知パラメータに関する情報に基づく決定も行う。すなわち、一態様によれば、１７７で、マネージャが、所与の通知に関してユーザに警告しなければならないかどうかと、ユーザにどのように通知するかに関する決定理論的分析を実行する。下で詳細に説明するように、決定理論および／またはヒューリスティックによる分析、決定、およびポリシを、１７７で使用することができる。ユーザに関する通知パラメータを使用して、欠けている値に書き込むことによってもしくはソースまたはシンクのスキーマで提供されるパラメータを上書きすることによって、分析をパーソナライズすることができる。通知プリファレンスも、決定理論的分析の代わりに使用されるポリシ（例えばヒューリスティック）を提供することができる。この判定に基づいて、１７８で、通知マネージャが通知をシンクに伝える。
【００７５】
本発明の様々な態様を、ここまでは、ユーザに適用可能なものとして説明してきた。しかし、本発明自体は、それに制限されない。すなわち、本発明は、ユーザを含む実質的にすべてのタイプのエンティティに適用可能である。他のタイプのエンティティには、例えば、エージェント、プロセス、コンピュータプログラム、スレッド、サービス、サーバ、コンピュータ、機械、会社、組織、および／または店が含まれる。例えば、エージェントは、ソフトウェアエージェントとすることができ、このソフトウェアエージェントは、一般に、ユーザのためにバックグラウンドタスクを実行し、タスクが終了するかなんらかの期待されたイベントが発生した時にユーザに報告するコンピュータプログラムとして定義することができる。他のタイプのエンティティを、当業者が諒解できるように、本発明の下に含めることができる。例えば、本発明のもう１つの態様によるコンテキストアナライザを、実質的にすべてのタイプのエンティティに適用可能なコンポーネントとして一般化することができる。もう１つの例として、通知シンクが、ユーザ以外のエンティティに関する通知、アラート、およびイベントを生成することができる。同様に、通知シンクが、ユーザ以外のエンティティに関する通知、アラート、およびイベントを受け取ることができる。
【００７６】
図１３に移ると、流れ図１８０に、本発明の一態様による通知マネージャによって実行することができる、決定理論的決定を示す。１８２で、１つまたは複数の通知を受け取る。通知によって、関連する通知シンクのモードを介してユーザに伝えることができる情報が提供される。１８４で、決定理論的分析を、複数のシンクの複数のモードに対して、１８２で受け取った通知に関して実行する。分析が、シンクに関連するモードを介して通知を伝えることの正味の価値をもたらすことが望ましい。分析は、ベイズネットワークなど、確率モデルを使用して実行することができる。
【００７７】
本発明の一態様によれば、１８４でのシンクのモードによって通知を伝えることの正味の価値の判定に、図１３の１８６、１８８、１９０、および１９２の実行が含まれる。１８６で、通知に含まれる情報の、ユーザにとっての期待価値を判定する。これは、ユーザが通知される場合にユーザに対して生じる情報の価値である。１８８で、通知を伝えることの中断のユーザにとっての期待コストを判定する。これは、通知を伝えるためにユーザを中断させるコストであり、例えば、ユーザが、会議で忙しく、通知によるユーザの中断が、ユーザにとってのコストをもたらす場合がある。１９０で、通知を実際には伝えられずに、その通知に含まれる情報をユーザが独立に知ることの期待価値を判定する。この価値は、１８６で判定される価値より小さい可能性がある。というのは、ユーザが、情報について通知された場合より後に、独立に情報を知る可能性があるからである。１８８で、ユーザに通知を通信することの実際のコストを判定する。例えば、ポケットベルを介してメッセージを送信することによって、ユーザのポケットベル会社からの、ユーザが負う通信料金がもたらされる可能性があり、そのようなポケットベルは、呼び出し単位でその会社によって請求される。
【００７８】
シンクのモードを介してユーザに通知を伝えることの正味の価値は、１８４で、１８６で判定された情報の期待価値から、１８８で判定された中断の期待コストと、１９０でのユーザが情報を独立に知ることの期待価値と、１９２の通信の実際のコストを引くことによって、判定することができる。１９４で、実質的にすべてのシンクの実質的にすべてのモードのいずれかの正味の価値が、所定の伝達閾値より大きいかどうかを判定する。例えば、正味の価値がドル単位（＄）で測定される場合に、所定の伝達閾値を０にすることができる。通知の正味の価値がシンクのモードの閾値より大きい場合には、この処理は、そのような通知について１９６に進んで、そのような通知を、通知に関する最も高い正味の価値を有するシンクのモードを介してユーザに伝える。そうでない場合に、実質的にすべてシンクの実質的にすべてのモードについて閾値を超える正味の価値を有しない通知に関して、ユーザは、現在、そのような通知に含まれる情報について通知されず、この処理は、そのような通知について１９８に進んで、後処理を実行するが、この処理は、１９６からもこの後処理に進む。
【００７９】
本発明は、１９８で後処理が実行される形によって制限されない。本発明の一態様によれば、１９６でユーザに伝えられる通知を、１９６が実行されたと仮定して、削除することができる。もう１つの態様では、そのような通知は、通知が伝えられた通知シンクから、ユーザが実際に通知を受け取ったことの確認を受け取った時に削除される。通知が伝えられる通知シンクが、使用されるシンクのモードに関して閾値より高い送信信頼性を有すると判定された場合にも、伝達の後に通知を削除することができる。さらに、図１３の処理を、所定のインターバルでおよび／または新しい通知が受け取られる時に繰り返すことができる。例えば、１８４で判定される通知の正味の価値が、時間依存である限り、伝達閾値より小さい正味の価値を有する可能性がある所与の通知が、後に閾値より大きい正味の価値を有し、伝えられる可能性がある。選言的な状況も、真である可能性がある。したがって、図１３に示された処理は、シンクのモードを介して通知をユーザに伝えなければならないかどうかを判定するために決定理論的分析を実行することができる形を示し、この分析を、望みに応じて繰り返すことができる。
【００８０】
図１３に示された処理が、複数の通知シンクの複数のモードに対する通知の決定理論的分析の実行に関して説明されたことに留意されたい。しかし、本発明自体は、これに制限されない。例えば、シンクのいずれかまたはすべてについて、そのようなモードを暗黙のうちに１つだけ設けることができる。この形で、通知の分析を、明示的にモードにかまわずに、シンクに対して実行することができる。さらに、注記したように、シンクのモードに関する通知の正味の価値の判定は、この説明の次の節で説明するように実行することができる。
【００８１】
本発明の特定の一態様によれば、この説明の前の節で提示した決定理論的通知を、以下の節で説明する形で実行することができるが、本発明はこれに制限されない。例えば、反復的な「貪欲な」決定理論的分析を使用することができる。分析中に、現在のコンテキストおよびアラート送信の関連する期待価値を、検討する。将来に関する推定を実行する、将来の時刻の範囲、コンテキスト、および関連する期待価値を検討する、より近似的でない、より正確な決定理論的分析で、動的ベイズネットワークまたは、隠れマルコフモデル（ＨＭＭ）と称する動的ベイズネットワークの近似などのモデルを使用することができる。そのような技法を使用して、将来の状態でコンテキストを「予測」する、より「近視眼的」でない分析に基づく通知決定を行うことができる。当技術分野では、近視眼的分析を、より豊かな、より近視眼的でない分析に一般化することが既知である。通知プラットフォームに関して、これらの「より貪欲でない」分析で、計算の追加の量が使用される。一態様の通知マネージャは、使用可能な計算リソースの状況の監視による、現在使用可能であるか使用可能になる、計算の検討に基づいて、より近視眼的でないモードにシフトすることができるように構成される。すなわち、本発明は、説明した貪欲な手法に制限されない。より近似的でなく、より貪欲でない、通知に関する理想的な時間およびデバイスの最適化では、将来のコンテキストおよびデバイス可用性の尤度を予測することによって、将来のコンテキストおよび関連するデバイスの可用性の範囲を検討することができる。
【００８２】
時刻ｔの通知Ｎの期待価値は、通知の現在の価値とみなすことができる。通知の情報的価値は、ユーザのコンテキストおよび知識に敏感であるとみなされる。コンテキストには、ユーザの位置および注意の状況、ユーザの目標、およびコンテキスト（例えば、ユーザが電子メールを開いたばかりである）などのコンテキスト情報が含まれる。コンテキストＣでの通知Ｎの初期価値は、通知が初めてソースによって生成された時のコンテキストでの通知の価値（例えば、ドル単位で測定することができる）から、ユーザがその情報にまだ精通していない確率を引いたものである。ユーザが情報に精通していない確率を、情報の新規性と称する。この確率は、情報のタイプおよび情報が配布される形などの証拠Ｅに基づく（例えば、新聞記事は、他のチャネルを介して経時的に知られるようになり、したがって、証拠に、新聞記事の要点とエイジ（age）とを含めることができる）。
【００８３】
既に０であることがわかっている情報の価値を検討する場合に、通知の価値は
【００８４】
【数１】
【００８５】
である。コンテキスト限定性の概念を、コンテキストＣでの価値を条件付け、コンテキストに基づく価値を査定することによって導入することができる。
【００８６】
【数２】
【００８７】
ある新しい時刻ｔに、通知を送信する価値が、価値の時間依存性に基づいて変化する可能性がある。
【００８８】
【数３】
【００８９】
価値関数を、アラートが通知マネージャによって送信または受信された時刻と現在時刻の間の時間差または遅延を引数としてとる時間依存関数によって表すことができ、ここで、遅延は、ｔ−ｔ0として表される。そのような関数には、例えば、価値の消失遅延を示す線形関数、指数関数、およびシグモイド関数を含めることができる。より複雑な関数に、情報の価値が変更される（例えば減衰を開始する）前の、価値が変化しない、アラートが送信されたか受信された時刻に続く、時間の期間を指す「貯蔵寿命（ｓｈｅｌｆ ｌｉｆｅ）」を表す関数などの、線形関数、指数関数、およびシグモイド関数の連結が含まれる。他の関数によって、ある遅れに伴ってアラートの価値を高めることができるという概念を取り込むことができる。
【００９０】
本発明の一態様によれば、コンテキストも変化し、新しい時刻に異なるという事実が考慮される。したがって、式（３）を、Ｃ（ｔ）を用いて書き直すことができ、あるいは、コンテキストを、常に現在のコンテキストとして示すことができる。コンテキストの不確実性の下で、異なる潜在的なコンテキストが合計される。したがって、情報の期待価値は、
【００９１】
【数４】
【００９２】
になる。これは、ユーザが、ある時刻ｔにコンテキストＣで通知のすべての内容を受信することの価値である。
【００９３】
デバイスのモードＭを用いて情報を通信することの期待価値は、レンダリングに関連する忠実度の消失およびコンテキストＣでモードＭを用いてシグナリングされた時に情報がユーザに送信されたかどうかの検討によって、減らされる。単純にするために、送信の忠実度が、内容の送信なしの０から内容の完全な送信の１までの範囲にわたる変数として取り込まれると仮定することができる。本発明の他の態様によれば、初期内容の１つまたは複数のコンポーネントをドロップすることの損失の追加の詳細と、様々な形での内容の切捨および要約（例えば、電子メールメッセージのテキスト全体のあるパーセンテージの切捨、または、携帯電話の限られたディスプレイでの表示のためのより小さくよりコンパクトなメッセージへの要約の別の手法）を取り込む、より詳細な有用性モデルが検討される。一般的な場合に、デバイスのモードＭでの情報の送信に関連する忠実度は、コンテキストに依存する。例えば、雑音の多い環境では、オーディオ内容のオーディオ部分を聞き取ることが困難になる可能性がある。
【００９４】
情報がユーザに送信される確率も、考慮することができる。これは、一般的な場合に、やはりコンテキストに依存する。この依存性は、通常は忠実度のコンテキスト依存性より顕著なので、これを明示的に指定することができる。ユーザが情報を受信した確率としての情報の送信は、ｐ（ｒｅｃｅｉｖｅｄ｜Ｍ，Ｃ，Ｅ，ｅ）として表され、ここで、ｅは、例えば一時停止、マウスオーバー、対話などの、ユーザの通知に対する応答に関する追加の証拠を表す。
【００９５】
次に、通知の通信の期待価値は、
【００９６】
【数５】
【００９７】
として決定される。式（５）の通信の期待価値が、通知の情報の期待価値に関して記述されることに留意されたい。これは
【００９８】
【数６】
【００９９】
に類似する。一態様で、式（５）および（６）で実施される通信の期待価値を、この説明の前の節で説明したユーザにとっての情報の期待価値として使用することができる。その代わりに、情報の期待価値を、忠実度および他のパラメータ考慮なしの期待される値すなわちＥｘｐＶａｌＩｎｆｏ（Ｎi）とすることができる。しかし、本発明は、これらの手法に制限されない。
【０１００】
次に、情報のコストを検討する。中断に関連するコストは、ほとんどはユーザの注意のコンテキストを介して送信のモードおよびコンテキストに依存する。各コンテキストのユーザの中断の期待コストは、一態様ではドル単位で測定することもでき、モードＭを介する情報の送信に関連する中断を避けるためにユーザが支払うつもりがある金額に等しい。一般的な場合に、これは、送信される内容の詳細にも依存する。しかし、一態様によれば、コンテキストの不確実性の下での異なるコストが、特に検討される。したがって、モードＭの中断の期待コストは、
【０１０１】
【数７】
【０１０２】
である。モードＭを介する通知を用いて今ユーザにシグナリングすることの価値は、情報の価値とコストの間の差である。例えばサービスによって請求される料金ごとのビットを送信するコストなどの、実際の通信のドル単位のコストも、検討される。これは、通知内容および選択されたモードの関数になる可能性がある。これを、（実際の）通信コストＣｏｍＣｏｓｔ（Ｎ，Ｍ）とも称する。
【０１０３】
次に、ユーザが通知によって能動的にシグナリングされないが、ユーザが、後に情報を再検討する暇ができた時に情報を受け取る、電子メールストアまたは、一般的な目的に関して、ユーザが再検討する機会を得るまで維持される潜在的な通知のストアなどのストアから情報を能動的に検索することができる場合に（正味の）価値が０でないとみなすことができる。これを、ユーザが通知なしで情報を独立に知ることの期待価値としてこの説明の前の節で言及した、通知に含まれる情報を探すことの期待価値ＥｘｐＶａｌＳｅｅｋと称する。この値は、ユーザが通知に含まれた情報を再検討するまでの時間を考慮することによって判定することができる。この時間は、通常は、例えばユーザがそのようなストアから情報を検索するまでの時間が、位置、時刻、および現在の注意のフォーカスに依存する可能性があるので、通常はコンテキスト応答的である。情報の新規性が、変化する可能性があり、通知が保留された時間の長さの関数になる可能性があることを考慮されたい。簡単にするために、忠実度は、ユーザが情報を検索する時に最大とみなすことができるが、一般的な場合に、ユーザは、より低い忠実度を提供するデバイスを介して情報を検索する可能性がある。また、情報検索に関連する中断のコストは、ユーザが情報を能動的に追跡する注意の状態にあるので、約０であると仮定することができる。
【０１０４】
したがって、
【０１０５】
【数８】
【０１０６】
である。通知の時刻と検索されるまでの時刻の間の待ち時間の判定に関して、式（８）を実施し、判定する手法が複数存在することに留意されたい。一態様では、ｔがポアソン分布で分布し、検索の時間が、分析の時刻からユーザが通知を再検討するまでの（メモリレス）平均時間であると仮定することができる。待ち時間は、その時刻と通知の時刻の間の差として判定することができる。さらに、ベイズネットワークまたは他の確率モデルを使用して、電子メールまたはより一般的な通知ストアを再検討する異なる平均時間に関する確率分布を推定することができる。上で説明したように、ベイズネットワークまたは他の確率モデルを使用して、ユーザの注意のフォーカス、位置に関する確率分布を判定することもできる。
【０１０７】
したがって、モードＭでの通知Ｎの通信に関する、通知の通信の期待価値ＮｅｔＥｘｐＶａｌＣｏｍは、
【０１０８】
【数９】
【０１０９】
である。これは、この説明の前の節で正味の価値と称したものである。
【０１１０】
意思決定に関して、やってくる通知に関して、実質的にすべてのデバイスの実質的にすべてのモードＭについて、ＮｅｔＥｘｐＶａｌＣｏｍを検討する。最大の正のＮｅｔＥｘｐＶａｌＣｏｍを有するデバイスが検討される（すなわち、＄０の所定の伝達閾値を仮定する。というのは、この項が、この説明の前の節で表されたからである）。ＮｅｔＥｘｐＶａｌＣｏｍが、複数のデバイス（例えば通信シンク）について正である場合には、最大の価値を有するデバイスを選択し、そのデバイスを用いてユーザに信号を送る。実質的にすべてのデバイスの実質的にすべてのモードについて値が負である場合には、通知を延期することができ、後の再検討のためにジャーナリングすることができる。通知をレンダリングすることの価値は、一態様では再検討され続けるが、これは、時間と共に変化する変数を更新することによる。これには、現在時間、ユーザが自分の電子メールまたは、より一般的には自分の通知ストアを再検討するまでの期待される時間、および現在のコンテキストおよび情報の新規性などの変数が含まれる。そのような再検討は、この説明の前の節で説明した後処理の一部として実行することができる。
【０１１１】
現在対過去に関するこの反復推定が、本発明の特定の一態様で実行されるタイプの決定理論的分析であることに留意されたい。これは、貪欲な意思決定戦略である。しかし、将来の時刻でのアクティブな通知の価値およびコストを検討する、多少複雑な予測モデルに頼るより貪欲でない戦略を定式化することができる。例えば、確率モデルを使用して、ユーザの将来の注意の状態を予測することができ、そのような予測を、ますます貪欲でなくなる形の推定に使用することができる。
【０１１２】
さらに、１回シグナリングした後であっても、いくつかの態様では、通知が即座に破棄（すなわち削除）されない。例えば、通知がレンダリングされた後に、その通知がユーザに届いたかどうかを保証することは、通常はできない。しかし、システムが、例えば、ユーザがデスクトップシナリオでレンダリングされた通知の上でカーソルをホバーさせることが、ユーザがシステムに「これを受け取った」ことを示す形であることの、ユーザとシステムの間の共有される理解などの処理が実施されている場合、または他の形で通知のアクセスを自動的に監視することによって、そのような保証が可能になる。後者の例が、ユーザが自分の携帯電話でメッセージを調べたかどうかを監視することである。そのような監視の報告を、この説明の前の節で注記した、通知受信の確認とすることができる。
【０１１３】
シンクのモードは、そのコンテキストでのモードのコンテキスト応答送信信頼性（ｔｒａｎｓｒｅｌとも称する）ｔｒａｎｓｒｅｌ（Ｍ，Ｃ）を有するとみなされる。すなわち、そのモードについて、およびそのコンテキストについて、送信信頼性によって、ユーザがそのレンダリングに基づいて通知を観察した確率が与えられる。注記したように、時々、ｔｒａｎｓｒｅｌが１．０であることの確認が受け取られる可能性があり、例えば、通知との対話または通知のマウスオーバーによって、ユーザが１．０の確率で通知を観察したことになる。他の時には、モードおよびコンテキストの送信信頼性に頼ることができる。
【０１１４】
ユーザが各通知の情報を受け取った尤度ｐ（ｒｅｃｅｉｖｅ）は、各送信の後に更新される。ＨA（Ｎi）は、一般に、内部のインボックスで保留されている特定の通知の警告ヒストリを指す。警告ヒストリは、試みられた通知のシーケンスを示し、
【０１１５】
【数１０】
【０１１６】
である。Ａ（Ｎi，Ｍ）は、モードＭでの通知Ｎiに関するアラートを指す。通知ヒストリを与えられれば、現在の通知の新規性ｐ（ｎｏｔｉｆｉｃａｔｉｏｎ ｕｎｓｅｅｎ｜ＨA，Ｅ，ｅ）を判定することができる。この要因を含めることによって、通知を見ることの期待価値が適当に減らされる。
【０１１７】
具体的に言うと、まず、更新されたＥｘｐＶａｌＣｏｍおよびＥｘｐＶａｌＳｅｅｋが、
【０１１８】
【数１１】
および
【０１１９】
【数１２】
【０１２０】
になる。次に、前と似た形であるが、これらの新しいＥｘｐＶａｌＣｏｍおよびＥｘｐＶａｌＳｅｅｋＩｎｆｏの値を用いて、ＮｅｔＥｘｐＶａｌＣｏｍを判定する。したがって、
【０１２１】
【数１３】
【０１２２】
である。
【０１２３】
さらに、通知の新規性ｐ（ｎｏｔｉｆｉｃａｔｉｏｎ ｕｎｓｅｅｎ｜ＨA，Ｅ，ｅ）が、一般に更新される。本発明の一態様によれば、これは、アラートでの新しい試み（通知レンダリングまたは通知の伝達）が行われた後に、これから説明するように、例えば二項試行として試みを検討することによって判定することができる。警告ヒストリが、
ＨA（Ｎi）：｛Ａ1（Ｎi，Ｍ，Ｃ（ｔ1）），Ａ2（Ｎi，Ｍ，Ｃ（ｔ2）），Ａ3（Ｎi，Ｍ，Ｃ（ｔ3）），．．．Ａn（Ｎi，Ｍ，Ｃ（ｔn））｝
であるものとすると、通知の新規性は、
【０１２４】
【数１４】
【０１２５】
になる。
【０１２６】
また、同時通知のセットを含む通知セットを検討することによって、通知をチャンクにすることができる、すなわち、所与の通知シンクの所与のモードを介する通知のグループ化として送信について一緒にグループ化することができることにも留意されたい。
【０１２７】
【数１５】
【０１２８】
したがって、通知の価値およびコストの要約が検討され、１つの中断のペナルティが予期される。
【０１２９】
この説明のこの節では、前の節で説明した本発明の諸態様に対する様々な拡張を提示する。まず、一態様で、決定理論的ポリシをより単純なルールおよびポリシに編集し、かつ／または近似することができることに留意されたい。これには、そのような決定理論的分析をポリシに編集する形式的方法を使用することができる。さらに、下で詳細に説明するように、例えばより粗い費用便益分析を実行する、ヒューリスティックポリシなどの様々なポリシがある。
【０１３０】
さらに、決定理論的ポリシは、「情報をプルする」情況に使用することができる。すなわち、ユーザが、デスクトップならびにモバイルの情況中の要求を含めて、システムに情報を要求する時に、０になる気を散らすコストが検討され、情報を、ユーザに送信される次の最も価値のある通知に関して関係させることができる。そのような情報は、次の最も高い価値によって順序付けることができ、あるいは、認識のためにカテゴリにグループ化することができる。例えば、次の「ｎ」個の最も価値のある通知を検査し、コマンドが、この順序で通知をストリーム化するように関係させることができ、あるいは、期待される有用性の順序での「次の通知」の要求を待つことができる。
【０１３１】
その代わりに、情報を、例えば最高の期待される有用性を有する通知を含むソースの順序に基づいて、ソースのカテゴリに関して関係させることができる。通知の中継は、次の最高の値を有する通知を含むソースに移動する前に期待価値の閾値に達するまでソースカテゴリ内で継続することができ、その後、この処理を繰り返す。その代わりに、情報を、ソースの事前に定義された順序付け（例えば、音声メールメッセージが最初、インスタントメッセージがその次、電子メールがその次、その後に財務通知）によって中継することができ、その後、そのカテゴリについて期待される有用性の閾値に達するまで、カテゴリ内の期待される有用性によってソートされた、ソースのそれぞれからの通知を中継し、その後、さらに進行することができる。
【０１３２】
情報の期待価値を使用して、現在の情況の高水準の要約を調整することができる。例えば、携帯電話を介する現在の通知情況の通信のために、保留中の通知のテキスト−音声要約を作成するための、ソースにまたがる推定を設けることができる。さらに、期待価値の判定を使用して、キャッシングを達成することができる。期待価値の判定を使用して、例えば、モバイル設定およびデスクトップ設定でのダイアログを機能強化するために、ユーザが、最高の期待価値のアイテムに最も関心を持つと仮定することによって、よりよく聞き取るために音声認識システムに情報を与えることもできる。
【０１３３】
さらに、説明した本発明のもう１つの拡張は、ソースカテゴリ内の期待価値のセットを使用して、要約を調整できることである。そのような要約は、各ソースの通知の情況の概要を中継するための永続的要約に現れることができる。例えば、電子メール要約は、次のようになる可能性がある「３２ ｕｎｒｅａｄ ｍｅｓｓａｇｅｓ；９ ｏｆ ｈｉｇｈ ｕｒｇｅｎｃｙ；ｍｏｓｔ ｕｒｇｅｎｔ ｆｒｏｍ Ａｎｄｙ ｏｎ‘Ｍｅｅｔｉｎｇ ｔｈｉｓ ａｆｔｅｒｎｏｏｎ．’（３２個の未読メッセージ、９個の高緊急性、最も緊急のメッセージはＡｎｄｙからの「今夜の会議」）」。
【０１３４】
ヒューリスティック通信の決定およびポリシは、通知マネージャによって実行することができるが、これを本発明に従って説明する。例えば、より形式的な決定理論的分析をバイパスする、粗費用便益分析を利用することができる。そのようなポリシおよび関連する通知コンポーネントおよび通知インタフェースは、決定理論的ポリシの近似版またはヒューリスティック版とみなすことができる。この手法では、通知に、ソースによって、またはユーザ指定の通知プロファイルによって（例えばメッセージの属性および／またはメッセージクラスごとに）、高緊急性、中緊急性、低緊急性（または任意の範囲の緊急性）としてラベルを付けることができる。ユーザが通知を受け取る状態である可能性が高い時に関する条件のリストを作成することができ、コンテキストの粗な監視を実行して、ユーザが最小の中断で通知を受け取る暇がある可能性が高い状況を識別する。これらの状態を、「おそらく自由な（ｌｉｋｅｌｙ ｆｒｅｅ）」状態と呼ぶ。
【０１３５】
このリストには、下記の１つまたは複数（および他の状態）を含めることができる。
【０１３６】
・ユーザが、存在し、入力し、ｘ秒だけ入力を一時停止した
・ユーザが、ファイルを保存し、ｘ秒だけ一時停止した
・ユーザが、電子メールを送信し、ｘ秒だけ一時停止した
・ユーザが、アプリケーションを閉じた
・ユーザが、あるアプリケーションから別のアプリケーションに切り替えた
【０１３７】
また、緊急性レベルについて最大延期時間をセットすることができる。例えば、内部的に、例示的なテーブルに、下記をセットすることができる。
【０１３８】
・最大延期（高優先順位）：２分
・最大延期（中優先順位）：７分
・最大延期（低優先順位）：１５分
【０１３９】
これは、ユーザがセットすることができ、その代わりに、デフォルト動作についてシステム開発者がセットすることができ、このデフォルトは、ユーザが修正できる場合もそうでない場合もある。
【０１４０】
さらに、ユーザは、例えば即座にパススルーを受信するものとして例外または緊急事態をリストすることができる。
【０１４１】
下記は、本発明の一態様による例示的アルゴリズムである。
【０１４２】
・通知を受信した時に、そのエイジに０をセットし、優先順位を注記し、例外のリストを検査する。
・その緊急性の最大延期時間の前にユーザのアクティビティの監視を介して自由状態が観察される場合に、通知をユーザにパススルーする。
・そうでない場合に、通知の最大自由状態に達する時に、通知を中継する。
【０１４３】
平均して、ほとんどの通知が、一般に、最大延期時間の前に配送される。しかし、ユーザは通常、通知を受信する時に通知が単純にパススルーされた場合に、それまでより自由である時にそれが発生する傾向を有するので、よりうれしいだろう。したがって、自由状態に達する確率は、時間と共に増加する。おそらく自由な状態である確率が、時間の増加に伴って高まるので、低優先順位のメッセージは、おそらく自由な状態中により高い尤度で発生する傾向があり、中断の確率が、メッセージの優先順位が上がるにつれて高くなる。
【０１４４】
この手法は、次のように一般化することができる。一態様によれば、複数のまたはポーリングされた待っている通知を含めるために通知の表示をイネーブルして、ユーザに、グループ化された通知のチャンクを含む単一の通知を送ることができる。そのようなチャンク化では、例えば最大優先順位、最大エイジ、またはグループによる最大優先順位によって順序付けられたリストで通知のチャンクを提示することができる。例えば、おそらく自由な状態が見られず、高優先順位の通知の最大延期時間に達した場合に、高優先順位の通知の最大延期に達した時に、グループ化された通知内で保留されている低優先順位通知に関する情報が含められる。これは、低優先順位の通知がこの時にそれ自体の最大延期に達していない場合であってもこうなる。
【０１４５】
さらに、優先順位の少数のカテゴリの代わりに、緊急性スコアに関して、例えば０〜１００の連続的な範囲をイネーブルすることができ、最大延期を、様々な線形関数および非線形関数（例えば増加する優先順位に伴う最大延期時間の指数関数的減衰）を含む通知の優先順位の関数にすることができる。例えば
【０１４６】
最大遅延（優先順位）＝ｅ-k(優先順位)×１５分
または
最大遅延（優先順位）＝ｅ-k(優先順位)×最大遅延（０優先順位）
である。
【０１４７】
自由時間の確率は、ユーザの次のｘ分以内に習得することができる。これは、おそらく自由な状態の頻度と、次のおそらく自由な状態までの期待される時間を習得することによって達成することができる。次のおそらく自由な状態までの時間は、ユーザのアクティビティから判定することができ、ユーザが、最大延期時間の代わりに、ユーザが妨害される優先順位クラスの確率を指定できるようにするために、通知優先順位クラスの最大延期時間を自動的にセットすることができる。すなわち、ユーザは、優先順位クラスの中断のターゲット「許容される確率」を指定することができ、システムが、このクラスの最大延期時間をセットすることができる。すなわち、ユーザ（またはその代わりに、デフォルトでシステム開発者）が、例えば「高優先順位通知について中断の０．５の確率、中優先順位メッセージによる中断の０．２５の可能性、低優先順位通知に関する妨害の０．０５の可能性を許容するなどの形で通知システムを構成する。
【０１４８】
下で、本発明の態様によるユーザインタフェースの概要を示す。そのようなインタフェースの例が、図１４に示されており、この図では、コンピュータのディスプレイ（例えば、ラップトップコンピュータ、デスクトップコンピュータ、または他のディスプレイ）のデスクトップスクリーン３００内に、所定の領域３０２（例えば、出力の表示および／またはユーザ対話の提供のための）が設けられている。図１４からわかるように、所定の領域３０２は、スクリーン３００の右上にあるが、スクリーンの他の領域（例えば、左下、右など）を使用することができることを諒解されたい。例えば、この説明で後で説明する本発明のストリームスタッキング態様では、領域３０２を、スクリーン３００の右側の列とすることができる。スクリーン３００は、グラフィックユーザインタフェースで使用されているように、その上でユーザがカーソルカーソル３０４の移動を制御できるものであることが望ましい。図１４に示されたカーソル３０４は、矢印ポインタであるが、他のカーソルを使用することができることを諒解されたい。
【０１４９】
所定の領域３０２を、本発明の様々な態様に関連する表示に関連して使用することができる。本明細書で使用される情報は、単一の情報および／または複数の情報を指すことができる。本発明の一態様によれば、情報には、上で説明してきた、アラートまたは通知とも称する通知アラートが含まれる。したがって、本発明の様々な態様は、下で説明するデスクトップスクリーン３００の所定の領域３０２内でのそのような情報の表示を対象とする。一態様では、デスクトップスクリーン３００を、例えばワードプロセッシング文書、スプレッドシートワークブック、または他のアプリケーションを操作するなど、主要な作業にユーザが使用することができる。
【０１５０】
しかし、領域３０２内に表示される情報を、主要な作業に関連しないものとすることができる。一例として、表示される情報を、ユーザによって要求されたものでない情報とすることができる。例えば、ユーザが、自分に伝えられる所定の分類閾値を超える（例えば、重要性に従って分類された情報）電子メールを要求したが、電子メールを領域３０２に表示することを要求しなかった（「非要求」とも称する）場合に、情報によって、電子メールについてユーザに警告することができる。
【０１５１】
スクリーン３００は、例えばハイパーテキストマークアップ言語（ＨＴＭＬ）フォーマットに従ってフォーマットされた内容を含む、一般化されたレンダリングを提供することができる、ディスプレイの部分とすることができる。さらに、情報の複数のソースが、ボタン、リンク、アニメーション、オーディオなどを含む「リッチ」インタフェース（例えばソースブランディング（ｓｏｕｒｃｅ ｂｒａｎｄｉｎｇ））を送信することができ、情報が、本明細書に記載のユーザインタフェースの制約および高水準設計規約またはスタイル規約の中でレンダリングされる。しかし、本発明は、これに制限されない。
【０１５２】
この説明の以下の節では、本発明のパルシング態様、本発明のストリームサイクリング態様、および本発明のストリームスタッキング態様を説明する。これらは、それによって情報を例えばデスクトップスクリーン３００の所定の領域３０２に表示できる特定の一態様である。以下の節では、これらの態様の少なくとも１つの例を示すが、本発明自体が、これらの例に制限されないことに留意されたい。さらに、ユーザがモードの間で切り替えることができる、パルシングモード、ストリームサイクリングモード、およびストリームスタッキングモードの組合せがありえる。例えば、システムに、ディスプレイ、処理システム、および、システムによって実行される時にモードの１つに入らせるコンピュータプログラムが保管された計算機可読媒体を含めることができる。
【０１５３】
ユーザがモードを切り替えることの代わりに、一態様では、上で説明した通知マネージャが、例えば、切替の決定を実行することができる。ユーザまたは通知マネージャは、一態様で、パルシングモード、ストリームサイクリングモード、および／またはストリームスタッキングモードなど、所与のモード内で切り替え可能な特徴に関する決定も行うことができる。音声告知の有無も、一態様では、ユーザおよび／または通知マネージャに委譲された決定とすることができる。
【０１５４】
図１５を参照すると、本発明によるパルシング態様の方法４００の流れ図が示されている。４０１で、情報を受け取る。前に説明したように、情報は、ユーザの主要な作業に関係しない非要求情報である場合がある。情報には、例えば、所定の閾値によって定義される閾値より大きい重要性の値を関連付けられるなど、割り当てられた分類を有する通知アラートを含めることができる。重要性の値の測定は、本発明によって制限されず、閾値によっても制限されない。
【０１５５】
４０２で、情報を、ディスプレイの所定の領域にフェードインさせる。一態様では、情報を所定の領域に表示し、所定の領域に表示される情報のアルファ値（例えば表示画素に関連する輝度値）を、所与の速度で第１の所定のレベルまで増分することによって、情報をフェードインさせる。第１の所定のレベルは、重要性の値によって定義される情報の重要性に基づくものとすることができる。例えば、レベルは、情報の重要性に比例するものとすることができる。情報のアルファ値を増やすことによって、所定の領域での情報の表示の不透明度が増える。したがって、アルファ値を、情報の重要性に基づくレベルまで増やすことは、より重要な情報が、より重要でない情報より大きい不透明ですなわち、より低い透明度で表示されることを意味する。しかし、一態様では、所定のレベルが、１００％未満すなわち、１００％不透明ではない。さらに、所定の領域にフェードインされる情報についてユーザに警告する音声告知を、４０２で再生することもできる。音声告知は、所定の１つまたは複数のサウンドとすることができ、情報の重要性値を、サウンドの様々な態様に関連付けることができる（例えば、重要性に基づいて大きくなるか小さくなる音量、重要性に基づくサウンドの数の増減）。
【０１５６】
４０４で、情報の重要性に基づく時間の長さに関する遅延がある。例えば、時間の長さを、情報の重要性に比例するものとすることができる。したがって、遅延は、情報がユーザに表示される時間の長さであることが好ましい。したがって、より高い重要性を有する情報を、重要性の低い情報より長く表示することができる。一態様では、遅延される時間の長さの間に、処理４００の４０６、４０８、４１０、および４１２が実行されるが、本発明自体は、これに制限されない。
【０１５７】
４０６で、ディスプレイの所定の領域への情報のフェードに関連する第１の所定のユーザジェスチャを検出する。例えば、この第１ジェスチャは、ディスプレイの所定の領域の上へのカーソルの移動（例えば、ユーザが、マウスなどのポインティングデバイスの使用を介してそのような移動を引き起こすことによる）とすることができるが、本発明自体はこれに制限されない。もう１つのジェスチャに、検出される、ユーザによる特定の言語または音声を含めることができる。第１ジェスチャに応答して、４０８で、第１アクションを実行する。一態様では、アクションに、所定の領域に表示される情報のアルファ値を、第１の所定のレベルより高い、１００％などの第２の所定のレベルまで増やすことが含まれる。したがって、第１ジェスチャによって、情報をより不透明にすることができる。もう１つの態様では、第１ジェスチャに応答して、４０８で、ディスプレイの所定の領域により詳細な情報（例えば、アラートに関連するなど）を表示する。
【０１５８】
４１０で、ディスプレイの所定の領域への情報のフェードに関連する第２の所定のユーザジェスチャを検出する。例えば、この第２のジェスチャは、カーソルがもはやディスプレイの所定の領域の上にない（例えば、ユーザが、マウスまたはキーボードの移動などのポインティングデバイスの利用を介してそのような移動を引き起こすことによって）ように、ディスプレイの領域へのカーソルの移動とすることができる。もう１つのジェスチャは、検出される、ユーザによる特定の音声の発音が含まれる。第２ジェスチャに応答して、４１２で、第２アクションを実行する。このアクションに、所定の領域に表示される情報のアルファ値を、前に４０８で調整された第２の所定のレベルから、第１の所定のレベルに減らすことを含めることができる。本発明のもう１つの態様によれば、４０８でディスプレイの所定の領域に表示された可能性があるより詳細な情報を、前に４０２でそこにフェードされた情報に置換する。
【０１５９】
４１４で、４０４の遅延が経過した時に、情報をディスプレイの所定の領域からフェードアウトさせる。例えば、一態様では、これに、所定の領域に表示される情報のアルファ値を所定の速度で減らし、その後、所定の領域にその情報をそれ以上表示しなくすることが含まれる。４１６によって示されるように、４００に示された処理を繰り返すことができる。すなわち、新しい重要性を有する可能性がある新しい情報を４０１で受け取ることができ、新しい情報を、４０２でディスプレイの所定の領域にフェードインさせる。一態様では、所定の領域へのフェードインおよびフェードアウトが、諒解可能であるように、所定の領域に既に表示されているすべてのものが、そこにとどまるものであることに留意されたい。すなわち、所定の領域にフェードインされる情報は、既にそこにあるものの上に表示され、フェードインされる情報のアルファ値のレベルが増やされ、したがって、フェードインする情報がどれほど透明または不透明であるかが決定され、したがって、情報のどれだけをユーザが観察できるかが決定される。情報（スペース内に完全に伝搬してはいないが）を、部分的に観察することができる。
【０１６０】
図１５で説明した処理は、情報が、アラートまたは通知の分類（例えば重要性の値）に関連する決定された時間の間に決定されたアルファに「パルス」されるので、パルシング態様と称する。これを、図１６に関して示すが、図１６では、本発明の態様による、そのようなパルス５０２の図５００が示されている。パルス５０２は、所定の領域に表示される情報がそこまで増やされるアルファ値レベルを表す高さ５０６と、情報がこのアルファ値レベルで所定の領域に表示される時間の長さを表す長さ５０４と、情報がこのアルファ値レベルまでフェードされる速度を表す第１勾配５０８と、情報がこのレベルからフェードされる速度を表す第２勾配５１０を有する。一態様では、高さ５０６と長さ５０４が、パルスされる情報の重要性に基づく（例えば、一態様では、高さが重要性値に比例する）。一態様では、第１勾配５０８および／または第２勾配５１０が、定数であるが、本発明自体は、これに制限されない。さらに、勾配５０８および５１０を、互いに類似するものとすることができる。
【０１６１】
本発明の一態様では、タブ、ボタン、および／または他のアイテムがディスプレイ上にあり、これらのアイテムを選択することによって、ユーザが即座に次の通知の表示を引き起こすことができる。例えば、ボタンのクリックが、次の通知がそれ自体の表示の重要性値または閾値に達していない場合であっても、ユーザが次の通知を見ることを望むことを示す。そのような通知は、例えば、独立の表示に関する閾値を超える重要性を有しない可能性がある。
【０１６２】
次に、図１７を参照すると、本発明によるストリームサイクリングの態様の方法６００が流れ図によって示されている。６０１で、それぞれの数の異なる情報パケット（例えば、通知ソースからの通知またはアラートに関連する情報）の関連表示時間が判定される。情報パケットに関する表示自己案は、この情報がディスプレイの所定の領域内で表示される時間の長さである。一態様では、時間の長さは、情報の重要度に基づき、それぞれの情報パケットに重要度値が割り当てられている。例えば、表示時間は、重要度に正比例することが可能である。ただし、本発明は、そのように限定されてはいない。さらに、前述した通り、情報は、ユーザの１次タスクに関係のない要求されていない情報であることが可能である。情報は、通知アラートを含むことが可能である。
【０１６３】
６０２で、一態様では（つまり、６０２はオプションである）、それぞれの情報パケットに関する周期が判定される。情報パケットに関する周期は、所与の期間中にディスプレイの所定の領域内で情報が表示される回数である。例えば、周期は、分類に基づき、所定のプロトコル（例えば、その分類に関連する比例関係）に従って表示されることが可能である。一態様では、周期は、情報の重要度に基づき、例えば、重要度値に正比例することが可能である。したがって、所与の期間中、より重要な情報をそれほど重要でない情報より頻繁に表示することが可能である。６０２が行われない本発明の一態様では、それぞれの情報パケットは、ほぼ１に等しい、つまり、各情報を所与の期間中に１回、表示することができる周期を有することが可能である。
【０１６４】
６０４で、所与の期間中、それぞれの情報パケットが、その情報パケットの表示時間にほぼ等しい時間の長さにわたり、その情報パケットの周期にほぼ等しい回数、ディスプレイの所定の領域内で表示される。したがって、第１の情報パケットが表示され、次に第２の情報パケットが表示され、その所与の期間中にすべての情報が表示されるまで、以下同様に表示が行われることが可能である。一態様では、それぞれの情報が、説明の前の節で述べた通り、表示時間にほぼ等しい遅延を挟んで所定の領域内にフェードインし、次にフェードアウトすることが（例えば、アルファ値を上げ、遅延を行い、次にアルファ値を下げることによって）可能である。本発明のそのような態様によれば、情報パケットのアルファ値が上げられる第１の所定のレベルは、前述した通り、情報の重要度に基づくことが可能である。つまり、アルファ値は、結局、表示時間にほぼ等しい時間の長さにわたって第１の所定のレベルに設定される。一態様では、表示されるそれぞれの情報に対してユーザの注意を喚起するオーディオ通報が流される、または別法では、所定のしきい値などのしきい値を越える情報に関してオーディオ通報が流される。オーディオ通報は、前述した通り、所定の１つまたは複数の音であることが可能である。一態様では、所定の期間中（特に本発明が限定されない）、プロセス６００の６０６、６０８、６１０、および６１２が行われる。ただし、本発明自体は、そのように限定されない。
【０１６５】
６０６で、ディスプレイの所定の領域内で表示されている現行の情報パケットに関係のある第１の所定のユーザジェスチャが検出される。例えば、第１のジェスチャは、表示の所定の領域上におけるカーソルの動き（例えば、マウスなどのポインティングデバイスの利用を介してそのような動きを生じさせるユーザによる）であることが可能である。別のジェスチャには、検出され、および／または処理される、ユーザによる特定の発話または音声が含まれることが可能である。第１のジェスチャに応答して、６０８で、第１のアクションが行われる。一態様では、アクションには、所定の領域内で表示されている現行の情報を「保持」して、第２のジェスチャが６１０で検出されるまで、所定の領域内で他の情報が実質的に全く表示されないようにすることが含まれる。
【０１６６】
つまり、実質的に、現行の表示される情報の表示時間が、一時的に増加され、所与の期間が、第２のジェスチャが６１０で検出されるまで、所定の領域内で現行の情報が保持されている間の時間の長さに等しい時間の長さに増加される。別の態様では、６０８で行われる第１のアクションには、例えば、１００％といった第１の所定のレベルより大きい第２の所定のレベルに、所定の領域内で表示される現行の情報のアルファ値を増大させることが含まれる。そのような態様では、第１のジェスチャは、これにより、表示される現行の情報が、より不明瞭になるようにする。別の態様では、第１のジェスチャに応答して、６０８でディスプレイの所定の領域内でより詳細な情報（例えば、アラートに関連する）が表示される。
【０１６７】
６１０で、ディスプレイの所定の領域内で表示される現行の情報に関係のある第２の所定のユーザジェスチャが検出される。例えば、この第２のジェスチャは、カーソルがもはやディスプレイの所定の領域上にないようにディスプレイのある領域にカーソルを動かすこと（例えば、マウスなどのポインティングデバイスの利用を介してそのような動きを生じさせるユーザによる）であるのが可能である。別のジェスチャは、認識されるユーザの特定の発話である。第２のジェスチャに応答して、６１２で、第２のアクションが行われる。一態様では、第２のアクションには、所定の表示領域内で前から「保持」されていた現行の情報を「解放」して、所定の領域内で後続の情報を引き続き表示することができるようにすることが含まれる。アクションには、所定の領域内で表示される情報のアルファ値を６０８で前に増大させた、または設定した第２の所定のレベルから第１の所定のレベルまで再び低減することが含まれるのが可能である。別の態様では、６０８でディスプレイの所定の領域内で表示されている可能性があるより詳細な情報が、６０２で前に表示されていたのと同じ情報で置き換えられる。
【０１６８】
６１４で、実質的にすべての情報が６０４で表示される所与の期間が経過した後、情報が更新される。例えば、６１４には、新しい情報を追加すること、および古い情報を削除することが含まれるのが可能である。情報の削除は、例えば、最低の優先順位の情報、所定の回数、既に表示された情報等に基づくことが可能である。同様に、追加される新しい情報には、情報の重要度に関連する所定のしきい値を超える重要度の情報が含まれることが可能である。次に、６１６によって示される通り、図１７のプロセス６００が繰り返される。したがって、６０１で、更新されたそれぞれの情報パケットに関する新しい表示時間が決定される。
【０１６９】
図１７のプロセス６００に関連して説明する本発明の態様は、ストリームサイクリングと呼ばれる。というのは、情報が、「ストリーミング」される、すなわち、所与の期間中、第１の情報が所定の領域内で表示され、次に、第２の情報が表示され、以下同様に表示が行われるからである。本発明によるストリームサイクリングホイール７０２の図７００が示される図１８を参照して、これを説明する。ホイール７０２は、いくつかのスロット１ないしＮを有し、Ｎは、整数７０４〜７０８である。スロット７０４は、例えば、所与の期間中に表示される情報の一部分の実例に対応する。それぞれのスロットは、所与の期間中にどれだけ長く情報のその部分が表示されるかに対応する時間遅延を有する。例えば、スロット７０６は、弧７１０の長さによって表される時間遅延を有し、より長い弧を有するスロットが、より大きい対応する時間遅延を有している。それぞれの情報が、情報の周期にほぼ等しい数のスロットに割り振られる。したがって、１の周期を有する情報は、１スロットに割り振られる。スロット数および所与の期間は、実質的にすべての情報の周期の総計にほぼ等しくなるように増大、低減を行い、情報の実質的にすべての実例が表示される所与の期間が、その実例の時間遅延の総計にほぼ等しくなるようにするのが可能であることに留意されたい。
【０１７０】
ホイール７０２は、矢印７１２で示される通り回転し、ホイール７０２をポイントするビューイング矢印７１４が、所与の期間中、ホイール７０２の異なるスロットをポイントするようになっている。矢印７１４がポイントしているスロット７０４は、ディスプレイの所定の領域内で現在、表示されている情報を含む。したがって、所与の期間中にホイール７０２が回転するにつれ、異なるスロットが矢印７１４によってポイントされ、所定の領域内で異なる情報が表示されるようになっている。ホイール７０２の回転速度は、ホイール７０２が所与の期間中に完全に１回転することができるようになっている。図１８のホイール７０２は、本発明のストリームサイクリングの態様の概念図であり、実際には、この態様を実施するのにそのようなホイールを提供する必要はないことに留意されたい。
【０１７１】
本発明の一態様によれば、ストリームサイクリングを行うことができる情報の一部分は、現行のサイクルにおける最もクリティカルな通知の、または、より一般的には、より大きい通知ストアから取り出すことが可能なより大量の情報の高レベルの要約を含む情報である要約ページである。ユーザにより、この要約の中で特に参照される通知が選択されることにより、通知の即時の表示が行われる。一態様ではそれぞれのページが、かたまりになった関連情報を含む、情報セットのクラスタを含む１つまたは複数の要約ページ、例えば、実質的にすべての通信（例えば、インスタントメッセージ、電子メール、着信電話コール）に関する要約ページ、および／または実質的にすべての自動化されたサービスに関する要約が存在する。さらに、本発明の別の態様によれば、ユーザが情報のサイクリングを停止すること、クリックして迅速にサイクルの中を進み、一時停止したいところで一時停止すること、および／または他の情報に関して掘り下げることを行えるようにする制御の明示的セットが存在することが可能である。一態様では、ストリームサイクリングによって提示される情報を別個のディスプレイ上に表示することができる。
【０１７２】
説明の以下の節では、本発明のストリームスタッキングの態様を説明する。図１９の図が、そのようなストリームスタッキングによるディスプレイ８００を示している。ディスプレイ８００は、メイン通知ウィンドウ８０２、ジャーナルウィンドウ８０４、およびいくつかのソースサマリ（summary）ウィンドウ８０６を含み、実質的にそのすべてが、ディスプレイ８００の所定の領域（例えば、ディスプレイ８００のスクリーン）内で表示されるものとされる。前述した通り、通知ソースなどのいくつかの情報ソースが存在する。それぞれの情報ソースは、前述した通り、ユーザの１次タスクと関係のない情報を含むことが可能な要求されていない情報などの情報を生成し、対応するソースサマリウィンドウ８０６の中でその情報を表示する。やはり前述した通り、情報は、通知アラートを含むことが可能である。
【０１７３】
情報のそれぞれの部分には、重要度値を割り当てることができ、重要度値の基準は、本発明によって制限されない。例えば、所定のしきい値などのしきい値より高い重要度を有する情報が、ストリームサイクリング式にメイン通知ウィンドウ８０２の中で表示される。例えば、ストリームサイクリングは、それぞれの情報がメイン通知ウィンドウ８０２の中にある時間の長さだけフェードインされ、次にフェードアウトされる前述した本発明のストリームサイクリングの態様に従うことが可能である。ただし、本発明自体は、そのように限定されない。ストリームサイクリング式に情報を表示することを本明細書では、情報を表示ストリーミングするとも呼ぶ。一態様では、メイン通知ウィンドウ８０２の中で表示される情報は、ソースサマリウィンドウ８０６の中で表示される情報のより詳細なバージョンであることが可能である。
【０１７４】
さらに、本発明の一態様では、メイン通知ウィンドウ８０２の中で表示ストリーミングされた情報は、所定の基準に従ってジャーナルウィンドウ８０４の中にジャーナリングされる。例えば、情報の特定の部分がメイン通知ウィンドウ８０２の中で表示されたとき、その情報の１行要約が、本明細書で一般的にジャーナルエントリと呼ぶジャーナルウィンドウ８０４に追加され、ウィンドウ８０４が、そのような要約のリストを表示するようになることが可能である。一態様では、ウィンドウ８０４のリストは、ユーザによってスクロール可能であり、ユーザが、メイン通知ウィンドウ８０２の中で既に表示ストリーミングされた実質的にすべての情報を検査できるようになっている。
【０１７５】
本発明の一態様によれば、ジャーナルウィンドウ８０４にジャーナリングされ、かつ／または追加される情報を限定する所定の基準は、ユーザによって閲覧されていないことがユーザ自身によって示された情報であることである。例えば、ユーザは、ホバリングとも呼ばれる、メイン通知ウィンドウ８０２の上でカーソルを動かすことなどの所定のジェスチャを行うことにより、メイン通知ウィンドウ８０２の中に現在、表示されている情報が、自身によって閲覧されたものであることを示すことができる。ジャーナリングを行うための所定の基準をユーザが制御することも可能である。一般に、ジャーナルは、情報をユーザにリレーする試みの完全な履歴をキャプチャするのに使用する。ジャーナルエントリは、情報のソース、高レベルのタイトルおよび／または要約、および／または通知またはアラートに関して行われた可能性のあるアクションに関する情報を含むことが可能である。
【０１７６】
メイン通知ウィンドウ８０２、ソースサマリウィンドウ８０６の中で表示される、かつ／またはジャーナルウィンドウ８０４の中にジャーナリングされる情報に関係のある所定のユーザジェスチャに応答して、アクションが行われることが可能である。例えば、所定のユーザジェスチャは、メイン通知ウィンドウ８０２、ソースサマリウィンドウ８０６の上でカーソルを動かすこと、またはジャーナルウィンドウ８０４へのジャーナルエントリ、およびジャーナルウィンドウ８０４の中で表示される情報を選択することであるのが可能である。選択は、適切な入力デバイスボタンをユーザがクリックすることによって行われることが可能であるが、本発明は、そのように限定されない。このジェスチャに応答して行われるアクションは、本発明によって限定されない。ただし、一態様では、アクションには、関係のあるジェスチャの対象であった情報に関連するより詳細な情報などのさらなる情報を表示することが含まれる。
【０１７７】
以上の例を図２０に示している。ディスプレイ９００で、ユーザが、ポインタとして図２０に示すが、本発明は、特にそのように限定されないカーソル９０４をソースサマリウィンドウ８０６のソースサマリウィンドウ９０４の上で動かして、ソースサマリウィンドウ９０４の中で表示されている情報を選択したものと想定する。ウィンドウ９０４に関する情報ソースは、ユーザ所望ソースと呼ばれる。というのは、この情報ソースは、それに関係するジェスチャをユーザが行ったソースだからである。ジェスチャに応答して、あるアクションが行われており、具体的には、ソースサマリウィンドウ９０４の中で表示されている情報に関するより詳細な情報を含むことが可能なウィンドウ９０６の表示が行われている。図２０の例は、ソースサマリウィンドウ８０６のうち１つの中で表示されている情報に関係するジェスチャを行うユーザに固有であるが、本発明自体は、そのように限定されず、ジェスチャは、メイン通知ウィンドウ８０２の中で表示されている情報、またはジャーナルウィンドウ８０４の中にジャーナリングされているジャーナルエントリの情報に関係しているのも可能であることに留意されたい。
【０１７８】
理解することができる通り、前述し、図１９および図２０に関連して説明した本発明のストリームスタッキングの態様は、様々な拡張が可能である。例えば、１つまたは複数のそれぞれのウィンドウ８０２、８０４、および８０６が表示される「単純モード」トグルが、存在することが可能である。さらに、ソースサマリウィンドウ８０６の数がユーザによって増加される、低減されることが可能である。また、一態様では、ソースサマリウィンドウ８０６を最小化して、ソースサマリウィンドウ８０６の中で表示される情報が、ウィンドウ８０６に関する情報ソースを表すアイコンであり、ウィンドウ８０６のうち特定のウィンドウ上でユーザによって行われたカーソルホバリングにより、対応するソースによって生成された情報が表示されるようにすることも可能である。
【０１７９】
次に、図２１を参照すると、本発明のストリームスタッキングの態様の方法１０００が、流れ図によって示されている。方法１０００は、図１９および２０に関連して説明したストリームスタッキングの態様を含むことが可能である。
【０１８０】
１００２で、いくつかのソースからの情報が表示される。それぞれのソースからの情報が、対応するソースサマリウィンドウの中で表示される。情報は、ユーザの１次タスクに関係のない要求されていない情報であることが可能である。１００４で、所定のしきい値などのしきい値を超える重要度を有する情報の表示ストリーミングが、メイン通知ウィンドウの中で行われる。一態様では、メイン通知ウィンドウの中で表示される情報は、その情報のソースに対応するソースサマリウィンドウの中で表示される情報よりも詳細であることが可能である。１００６で、メイン通知ウィンドウの中で表示ストリーミングの行われた情報が、所定の基準に従ってジャーナルウィンドウに追加されるジャーナルエントリによるなどして、ジャーナルウィンドウの中にジャーナリングされる。
【０１８１】
前述した通り、ユーザは、特定の（ユーザ所望の）情報について所定のユーザジェスチャを行うことにより、実質的にソースサマリウィンドウ、メイン通知ウィンドウの任意のウィンドウの中で表示され、かつ／またはジャーナルウィンドウの中にジャーナリングされている実質的に任意の情報に関係するアクションが行われるようにすることができる。したがって、１００８で、ソースサマリウィンドウ、メイン通知ウィンドウのどれかの中で表示されている、かつ／またはジャーナルウィンドウの中でジャーナルエントリを有する特定の情報に関して、そのようなユーザジェスチャが検出される。この検出に応答して、１０１０で、この情報に関係のあるアクションが行われる。例えば、本発明の一態様では、情報のより詳細なバージョンを表示することが可能である。
【０１８２】
説明の以上の節で述べた本発明の様々な態様は、ストリームスタッキングとも呼ばれる。というのは、情報をメイン通知ウィンドウの中で「ストリーミングする」ことと、ソースサマリウィンドウとジャーナルウィンドウの両方の中にスタックすることをともに行うことができるからである。したがって、ユーザは、メイン通知ウィンドウを参照することによって重要な情報について知ることができ、またジャーナルウィンドウの中で情報に関する対応するジャーナルエントリを参照することにより、メイン通知ウィンドウの中で表示された過去の情報を調べることができる。また、ユーザは、ソースに関してソースサマリウィンドウを参照することにより、通知ソースなどの所与のソースによって生成されている現行の情報を観察することもできる。ソースサマリウィンドウの情報は、重要度に関わらず表示されることが可能であり、一方、より重要な情報は、一般に、メイン通知ウィンドウの中で表示され、ジャーナルウィンドウの中にジャーナリングされる。
【０１８３】
さらに、本発明の一態様では、高レベル要約情報が、それぞれのソースに関連付けられる。例えば、電子メール関連ソースが、そのソースからの情報の全体的ステータスに関する情報を表示し、所与の優先順位を有する１０の未読のメッセージが存在し、また最高優先順位のメッセージが、特定の件に関する特定のユーザからであるようにすることが可能である。この場合、ソース上でクリックする、またはホバリングすることにより、ソースアプリケーションに関するより幅広いユーザインタフェース、最新の通知等が表示されることが可能である。説明の前の節で述べた本発明のストリームサイクリングの態様の独立したバージョンなどの本発明の別の態様では、情報が各ソースディスプレイ内でストリーミングされる、またはサイクリングされる。さらに、より大きいメイン通知ウィンドウが含まれる本発明のその他の態様では、特定のソースをクリックすること、または別の仕方で選択することにより、ソース情報の詳細が表示され、この情報にフォーカスが当てられるようになる。したがって、通知の後続の選択により、この情報のさらなる詳細、および／またはこのソースに関するより幅広いユーザインタフェースが表示されることが可能である。
【０１８４】
説明の前の節では、パルスモード、ストリームサイクリングモード、およびストリームスタッキングモードを含め、情報をユーザに提示することができる様々なモードを説明してきた。説明の本節では、ユーザがそれぞれのモードを介して提示される情報と対話することができる仕方に関するさらなる説明を提供する。説明の前の節では、様々なユーザジェスチャおよびオーディオ通報について述べたが、説明の本節は、どのようにユーザ対話を行うことができるかに関してより詳細な説明を提供する。
【０１８５】
例えば、追加の情報の要望を伝えるためのユーザジェスチャ、および可能なリンクおよびサービスに関して提示された質問に返答するためのユーザジェスチャを説明する。一態様では、ユーザが、ストリームスタッキングモードにおいてソースの上でカーソルをホバリングさせているのが、要約に関してより詳細な情報を提供するようにというシステムに対する合図であることが可能である。その詳細な情報は、前述した通り、ポップアップウィンドウの中で現れることが可能である。したがって、この態様では、ユーザがウィンドウ上でカーソルをホバリングさせていることは、通知内容に関するさらなる詳細を求めるユーザからの暗黙的な要求として利用される。例えば、気象通報が存在する場合、カーソルホバリングは、湿度、５日間の予報などの天候に関するさらなる詳細をユーザが求める仕方である。
【０１８６】
その他のジェスチャも、本発明に従って検出することができる。例えば、ユーザがストリーミングされている情報の上にカーソルを置き、次に、マウスのようなポインティングデバイスのボタンをクリックするなどして情報を選択することを様々な仕方で使用するのが可能である。例えば、ディスプレイ内で提供されるユニバーサルリソースロケータ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）（ＵＲＬ）アドレスの選択により、例えば、そのアドレスによって参照される情報のアクセスが行われるのが可能である。別の例として、質問（例えば、「貴方のためにそれをスケジュールしますか」）を尋ねる情報表示の不特定の領域内でクリックすることが、サービスを受けるユーザの意図を確認する「はい」とみなされ、一方、何も選択されないデフォルトが、「いいえ」の応答であると判定されることが可能である。
【０１８７】
さらに、アプリケーションと通信するアクションおよびタイミング、通知マネージャ、および／または通知にユーザが気付いていることに関する証拠を提供することについて説明する。例えば、通知が現れた後のある時間内にキーボードまたはマウスなどの入力デバイスを利用するユーザジェスチャがユーザによって提供されて、「この通知に関してもっと私に知らせなさい」を伝えることが可能である。マウスのようなポインティングデバイスを振り動かす、またはディスプレイの事前定義された隅にカーソルを移動するなどのユーザジェスチャを利用して、ユーザに伝えられた最初の通知に応じて、ユーザが、「それは何であったのか」、「それを私に再び見せなさい」、または「これに関してもっと私に知らせなさい」を伝えることが可能である。例えば、通知がオーディオ通報であった場合、そのようなユーザジェスチャ（例えば、ディスプレイの隅におけるような）は、ユーザが「それは何であったのか」を尋ねているものと解釈して、前述したパルスモードに従って情報が通知ウィンドウの中で表示されるようになるのが可能である。
【０１８８】
また、ジェスチャを人間−コンピュータ間の対話で使用して、ユーザが通知を見たことを通知マネージャに示す、またはより明示的に通知マネージャにリレーされる情報を収集することも可能である。例えば、自身が通知を見たことを通知システムに示す仕方として、ユーザは、通知が表示された後のある時間フレーム中に通知の上でカーソルをホバリングさせることが可能である。したがって、この場合、システムは、その通知をユーザにリレーすることを再度試みることがないよう決定することができる。また、ユーザがウィンドウの中に存在するリンクを選択するなどの、より複雑な対話がこの指示を提供することも可能である。
【０１８９】
説明の前の節で述べたジャーナルなどの通知ジャーナルとのユーザ対話を次に説明する。つまり、前述した通り、通知要約を本発明のストリームスタッキングモードで通知ジャーナルの中に記憶することができる。通知要約は、時刻、通知ソース、メッセージ分類等で編成することができ、ユーザが、以前に見落とした可能性がある通知を再び訪れる、または見直すことができるようにする。したがって、ジャーナルエントリを選択することにより、ユーザは、通知を再表示できるようになる。
【０１９０】
本発明の別の態様に従って、情報の表示に代わる、または情報の表示を拡張するオーディオの使用を説明する。例えば、しきい値（所定のしきい値などの）を超える通知の表示を告示するため、オーディオ通報を使用することができ、通知に対するユーザの注意を喚起するためにさらに使用することができる。さらに、異なる音が、異なるタイプの通知に関連していることが可能である。例えば、スケジューリング関連通知は、電子メール関連通知とは異なる音を有するのが可能である。
【０１９１】
また、この適用例では、情報を表示するのに、テキストの使用および／またはテキストおよびグラフィックスの使用を説明したが、本発明は、テキストおよび／またはテキストおよびグラフィックスには限定されないことに留意されたい。例えば、一態様では、情報がグラフィックスで表示され、情報の性質および優先順位を示すのに異なる形状および異なるカラーが利用されることが可能である。別の例として、表示されるオブジェクトがディスプレイの中心に近いほど、そのオブジェクトは重要度が高く、異なるカラー領域が情報の異なるソースを表す。つまり、本発明は、情報に関連する高レベルのグラフィックスおよび／またはテキストの例えの特定の概念に限定されない。
【０１９２】
本発明の代替の情報表示の態様の例を図２３の例としての図に示す。本発明のこの態様によれば、例えば、図１４に描くデスクトップスクリーン３００の所定の領域３０２内で情報を表示することができる。さらに、一態様では、ユーザは、スコープモードを含む異なるモードの間で切り替えを行うことができる。例えば、システムは、ディスプレイ、処理システム、およびプロセッサによって実行されて、スコープモードなどのモードのどれかにエントリが行われるようにするコンピュータプログラムを記憶するマシン可読媒体を含むことが可能である。さらに、一態様では、ユーザによるモード間の切替えの他、詳細な説明の前の節で述べた通知マネージャが、例えば、モードを切り替える判定を行うことができる。
【０１９３】
図２３に描いた例としてのスコープインタフェースでは、情報の性質および優先順位を示すのに異なる形状および異なるカラーが利用される。例えば、１つまたは複数の部分に分割されたスクリーンの隅に円形の表示オブジェクト１１００（例えば、ホイール）が存在することが可能である。その他の形状も可能であることに留意されたい。それぞれの部分は、異なるカラーであり、情報の異なるタイプまたは異なるソースを示すことが可能である。例えば、円形、正方形、矢印、線などの表示オブジェクト１１００のそれぞれの部分内のオブジェクトが、それぞれの部分の情報ソースからの通知、優先順位、および／またはイベント、および／またはそれぞれの部分の情報タイプを表すことが可能である。オブジェクトが表示オブジェクト１１００の中心に近いほど、そのオブジェクトは重要度が高い、つまり、重要度値の割り当てられた通知、メッセージ、および／または他のタイプの情報である。したがって、一態様では、ホイール内の同心円が、異なる優先順位レベルを画定する。カーソルでオブジェクトの上をホバリングすることにより、そのオブジェクトに関するテキスト情報が表示されるようにすることができる。例えば、カーソルで表示オブジェクト１１００の一部分の上を（ただし、表示オブジェクト内のオブジェクトの上ではなく）をホバリングすることにより、表示オブジェクト１１００のその部分に関する情報タイプまたは情報ソースを示すテキスト情報を生じさせることができる。テキスト情報は、例えば、ツールティップ（tool tip）として表示されることが可能である。
【０１９４】
本発明の様々な態様に関するコンテキストを提供するため、図２３および以下の説明は、本発明の様々な態様を実施することができる適切なコンピュータ環境の簡単な一般的説明を提供するものである。１つまたは複数のコンピュータ上で実行されるコンピュータプログラムのコンピュータ実行可能命令の一般的コンテキストにおいて本発明を以上で説明してきたが、本発明は、その他のプログラムモジュールの組合せで実施するのも可能なことが、当分野の技術者には認められよう。一般に、プログラムモジュールには、特定のタスクを行う、かつ／または特定の抽象データタイプを実装するルーチン、プログラム、構成要素、データ構造等が含まれる。さらに、本発明の方法は、単一プロセッサ、またはマルチプロセッサのコンピュータシステム、ミニコンピュータ、メインフレームコンピュータ、ならびにパーソナルコンピュータ、ハンドヘルドコンピュータ装置、マイクロプロセッサベースの家庭用電化製品またはプログラマブル家庭用電化製品等を含むその他のコンピュータシステム構成で実施できることが、当分野の技術者には理解されよう。また、本発明の示す態様は、通信網を介してリンクされたリモート処理装置によってタスクが行われる分散コンピュータ環境においても実施することが可能である。ただし、本発明のすべてではないにしても、いくつかの態様は、独立型コンピュータ上で実施することが可能である。分散コンピュータ環境では、プログラムモジュールは、ローカルのメモリ記憶装置とリモートのメモリ記憶装置の両方の中に配置されていることが可能である。
【０１９５】
図２３を参照すると、本発明の様々な態様を実施するための例としてのシステムが、プロセッサ１２２１と、システムメモリ１２２２と、システムメモリを含む様々なシステム構成要素をプロセッサ１２２１に結合するシステムバス１２２３とを含むコンピュータ１２２０を含む。プロセッサ１２２１は、様々な市販のプロセッサのどれであることも可能である。デュアルマイクロプロセッサ、およびその他のマルチプロセッサアーキテクチャもプロセッサ１２２１として使用できることが理解されよう。
【０１９６】
システムバスは、様々な市販のバスアーキテクチャのどれかを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含むいくつかのタイプのバス構造のどれであることも可能である。システムメモリは、読取り専用メモリ（ＲＯＭ）１２２４、およびランダムアクセスメモリ（ＲＡＭ）１２２５を含むことが可能である。始動中などにコンピュータ１２２０内部の要素間における情報の転送を助ける基本ルーチンを含む基本入力／出力システム（ＢＩＯＳ）が、ＲＯＭ１２２４の中に記憶される。
【０１９７】
コンピュータ１２２０は、ハードディスクドライブ１２２７と、例えば、取外し可能なディスク１２２９に対して読取りまたは書込みを行う磁気ディスクドライブ１２２８と、例えば、ＣＤ−ＲＯＭディスク１２３１に対して読取りまたは書込みを行う、またはその他の光媒体に対して読取りまたは書込みを行うための光ディスクドライブ１２３０とをさらに含む。ハードディスクドライブ１２２７、磁気ディスクドライブ１２２８、および光ディスクドライブ１２３０は、それぞれ、ハードディスクドライブインタフェース１２３２、磁気ディスクドライブインタフェース１２３３、および光ディスクドライブインタフェース１２３４によってシステムバス１２２３に接続されている。これらのドライブおよび関連コンピュータ可読媒体は、コンピュータ１２２０のためのデータ、データ構造、コンピュータ実行可能命令等の不揮発性記憶装置を提供する。以上のコンピュータ可読媒体の説明は、ハードディスク、取外し可能な磁気ディスク、およびＣＤに関連するが、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイカートリッジ等のコンピュータによって読取り可能な他のタイプの媒体も例としての動作環境において使用することができ、さらに、任意のそのような媒体が、本発明の方法を実行するためのコンピュータ実行可能命令を含むのが可能であることが、当分野の技術者には理解されよう。
【０１９８】
オペレーティングシステム１２３５、１つまたは複数ののアプリケーションプログラム１２３６、その他のプログラムモジュール１２３７、およびプログラムデータ１２３８を含むいくつかのプログラムモジュールをドライブおよびＲＡＭ１２２５の中に記憶することができる。示すコンピュータにおけるオペレーティングシステム１２３５は、実質的にどの適切なオペレーティングシステムであるのも可能なことに留意されたい。
【０１９９】
ユーザは、キーボード１２４０、およびマウス１２４２などのポインティングデバイスを介してコマンドおよび情報をコンピュータ１２２０に入力することができる。その他の入力デバイス（図示せず）には、マイクロホン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナ等が含まれることが可能である。以上の入力デバイスおよびその他の入力デバイスは、しばしば、システムバスに結合されたシリアルポートインタフェース１２４６を介してプロセッサ１２２１に接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）（ＵＳＢ）などの他のインタフェースを介して接続されることも可能である。また、モニタ１２４７または他の表示装置も、ビデオアダプタ１２４８などのインタフェースを介してシステムバス１２２３に接続される。モニタに加えて、コンピュータは、通常、スピーカおよびプリンタなどの他の周辺出力装置（図示せず）も含む。
【０２００】
コンピュータ１２２０は、リモートコンピュータ１２４９などの１つまたは複数のリモートコンピュータに対する論理接続を使用するネットワーク化された環境で動作することが可能である。リモートコンピュータ１２４９は、ワークステーション、サーバコンピュータ、ルータ、ピア装置、またはその他の共通ネットワークノードであることが可能であり、通常、コンピュータ１２２０に関連して説明した要素の多く、またはすべてを含む。ただし、メモリ記憶装置１２５０だけを図２３で示している。図２３に描く論理接続は、ローカルエリアネットワーク（ＬＡＮ）１２５１、およびワイドエリアネットワーク（ＷＡＮ）１２５２を含むことが可能である。そのようなネットワーク環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、およびインターネットで一般的である。
【０２０１】
ＬＡＮネットワーク環境で使用する場合、コンピュータ１２２０は、ネットワークインタフェース、つまりアダプタ１２５３を介してローカルネットワーク１２５１に接続することができる。ＷＡＮネットワーク環境で利用する場合、コンピュータ１２２０は、一般に、モデム１２５４を含むことが可能であり、かつ／またはＬＡＮ上の通信サーバに接続され、かつ／またはインターネットなどのワイドエリアネットワーク１２５２を介して通信を接続するための他の手段を有する。内部または外部にあることが可能なモデム１２５４をシリアルポートインタフェース１２４６を介してシステムバス１２２３に接続することができる。ネットワーク化された環境では、コンピュータ１２２０に関して描くプログラムモジュール、またはプログラムモジュールの部分をリモートのメモリ記憶装置の中に記憶することが可能である。示したネットワーク接続は、例としてのものであり、コンピュータ間で通信リンクを確立する他の手段も使用できることが理解されよう。
【０２０２】
コンピュータプログラミング分野の技術者の慣行に従って、特に明記しない限り、本発明は、コンピュータ１２２０のようなコンピュータによって行われる処置、および動作の記号表現に関連して説明した。そのような処置および動作は、ときとして、コンピュータ実行される処置および動作と呼ばれる。処置および記号で表現される動作には、電気信号表現を結果として変換する、または減少させる、データビットを表す電気信号のプロセッサ１２２１による操作、およびメモリシステム（システムメモリ１２２２、ハードディスク１２２７、フロッピー（登録商標）ディスク１２２９、およびＣＤ−ＲＯＭ１２３１を含む）内のメモリロケーションにおいてデータビットを保持して、コンピュータシステムの動作を再構成する、または別の仕方で変更すること、ならびに他の信号処理が含まれることが理解されよう。そのようなデータビットが保持されるメモリロケーションは、データビットに対応する特定の電気特性、磁気特性、または光学特性を有する物理的ロケーションである。
【０２０３】
以上に説明したのは、本発明の様々な態様である。もちろん、本発明を説明するため、構成要素または方法の考えられるすべての組合せを説明することは不可能であるが、本発明の多数のさらなる組合せおよび変更が可能であることが、当分野の技術者には認められよう。したがって、本発明は、頭記の特許請求の範囲の中にあるすべてのそのような改変形態、変更形態、および変形形態を包含するものとする。
【産業上の利用可能性】
【０２０４】
本発明は、コンピュータ、コンピュータソフトウェア、および情報技術の分野で産業上の利用可能性を有する。
【特許請求の範囲】
【請求項１】
ユーザのために１つまたは複数の通知ソースから１つまたは複数の通知シンクへ通知を伝えるためのプラットフォームに関して使用するための方法であって、
前記ユーザの現在の注意のフォーカスを判定するステップと、
前記ユーザの現在位置を判定するステップと
を備えたことを特徴とする方法。
【請求項２】
前記ユーザの前記現在の注意のフォーカスおよび前記ユーザの前記現在位置を含む前記ユーザの現在のコンテキストを出力するステップ
をさらに備えたことを特徴とする請求項１に記載の方法。
【請求項３】
前記ユーザの前記現在の注意のフォーカスを判定するステップは、１つまたは複数のセンサを介して前記フォーカスを測定することを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記ユーザの前記現在位置を判定するステップは、１つまたは複数のセンサを介して前記位置を測定することを含むことを特徴とする請求項１に記載の方法。
【請求項５】
１つまたは複数のセンサに関連して全地球測位システム（ＧＰＳ）を使用することをさらに含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記ユーザの前記現在の注意のフォーカスを判定するステップは、前記ユーザによる前記フォーカスの直接指定を受け取ることを含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記ユーザの前記現在位置を判定するステップは、前記ユーザによる前記位置の方向指定を受け取ることを含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記ユーザの前記現在の注意のフォーカスを判定するステップは、前記フォーカスを指定するユーザプロファイルおよびルールの少なくとも１つを使用することを含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記ユーザプロファイルは、前記ユーザによって修正可能なデフォルトプロファイルを含むことを特徴とする請求項８に記載の方法。
【請求項１０】
前記ユーザの前記現在位置を判定するステップは、前記フォーカスを指定するユーザプロファイルおよびルールの少なくとも１つを使用することを含むことを特徴とする請求項１に記載の方法。
【請求項１１】
前記ユーザプロファイルは、前記ユーザによって修正可能なデフォルトプロファイルを含むことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記ユーザの前記現在の注意のフォーカスを判定するステップが、前記フォーカスを推定することを含むことを特徴とする請求項１に記載の方法。
【請求項１３】
前記フォーカスを推定することは、ベイズモデルおよび統計モデルの少なくとも１つを使用することを含むことを特徴とする請求項１２に記載の方法。
【請求項１４】
前記ユーザの前記現在位置を判定するステップは、前記位置を推定することを含むことを特徴とする請求項１に記載の方法。
【請求項１５】
前記位置を推定することは、ベイズモデルおよび統計モデルの少なくとも１つを使用することを含むことを特徴とする請求項１４に記載の方法。
【請求項１６】
１つまたは複数のセンサを介して前記コンテキストを直接に測定することと、
前記ユーザによる前記コンテキストの直接指定を受け取るステップと、
前記コンテキストを指定するユーザプロファイルおよびルールの少なくとも１つを使用するステップと、
前記コンテキストを推定するステップと
の少なくとも１つを介して、ユーザの現在のコンテキストを判定するステップ
を備えた方法を実行するための、コンピュータ実行可能命令を実行のために格納したことを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項１】
ユーザのために１つまたは複数の通知ソースから１つまたは複数の通知シンクへ通知を伝えるためのプラットフォームに関して使用するための方法であって、
前記ユーザの現在の注意のフォーカスを判定するステップと、
前記ユーザの現在位置を判定するステップと
を備えたことを特徴とする方法。
【請求項２】
前記ユーザの前記現在の注意のフォーカスおよび前記ユーザの前記現在位置を含む前記ユーザの現在のコンテキストを出力するステップ
をさらに備えたことを特徴とする請求項１に記載の方法。
【請求項３】
前記ユーザの前記現在の注意のフォーカスを判定するステップは、１つまたは複数のセンサを介して前記フォーカスを測定することを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記ユーザの前記現在位置を判定するステップは、１つまたは複数のセンサを介して前記位置を測定することを含むことを特徴とする請求項１に記載の方法。
【請求項５】
１つまたは複数のセンサに関連して全地球測位システム（ＧＰＳ）を使用することをさらに含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記ユーザの前記現在の注意のフォーカスを判定するステップは、前記ユーザによる前記フォーカスの直接指定を受け取ることを含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記ユーザの前記現在位置を判定するステップは、前記ユーザによる前記位置の方向指定を受け取ることを含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記ユーザの前記現在の注意のフォーカスを判定するステップは、前記フォーカスを指定するユーザプロファイルおよびルールの少なくとも１つを使用することを含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記ユーザプロファイルは、前記ユーザによって修正可能なデフォルトプロファイルを含むことを特徴とする請求項８に記載の方法。
【請求項１０】
前記ユーザの前記現在位置を判定するステップは、前記フォーカスを指定するユーザプロファイルおよびルールの少なくとも１つを使用することを含むことを特徴とする請求項１に記載の方法。
【請求項１１】
前記ユーザプロファイルは、前記ユーザによって修正可能なデフォルトプロファイルを含むことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記ユーザの前記現在の注意のフォーカスを判定するステップが、前記フォーカスを推定することを含むことを特徴とする請求項１に記載の方法。
【請求項１３】
前記フォーカスを推定することは、ベイズモデルおよび統計モデルの少なくとも１つを使用することを含むことを特徴とする請求項１２に記載の方法。
【請求項１４】
前記ユーザの前記現在位置を判定するステップは、前記位置を推定することを含むことを特徴とする請求項１に記載の方法。
【請求項１５】
前記位置を推定することは、ベイズモデルおよび統計モデルの少なくとも１つを使用することを含むことを特徴とする請求項１４に記載の方法。
【請求項１６】
１つまたは複数のセンサを介して前記コンテキストを直接に測定することと、
前記ユーザによる前記コンテキストの直接指定を受け取るステップと、
前記コンテキストを指定するユーザプロファイルおよびルールの少なくとも１つを使用するステップと、
前記コンテキストを推定するステップと
の少なくとも１つを介して、ユーザの現在のコンテキストを判定するステップ
を備えた方法を実行するための、コンピュータ実行可能命令を実行のために格納したことを特徴とするコンピュータ読み取り可能な記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【公開番号】特開２０１２−７４０６１（Ｐ２０１２−７４０６１Ａ）
【公開日】平成２４年４月１２日（２０１２．４．１２）
【国際特許分類】
【出願番号】特願２０１１−２５１６４０（Ｐ２０１１−２５１６４０）
【出願日】平成２３年１１月１７日（２０１１．１１．１７）
【分割の表示】特願２００１−５６８１９８（Ｐ２００１−５６８１９８）の分割
【原出願日】平成１３年３月１６日（２００１．３．１６）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公開日】平成２４年４月１２日（２０１２．４．１２）
【国際特許分類】
【出願日】平成２３年１１月１７日（２０１１．１１．１７）
【分割の表示】特願２００１−５６８１９８（Ｐ２００１−５６８１９８）の分割
【原出願日】平成１３年３月１６日（２００１．３．１６）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]