(57)【要約】通知の配信を制御するシステム（２００）。本システムは、複数のソース（sources）からの通知の配信を仲介し、順序付けする（２０６）。さらに、個々の通知に適した処置を決定するために、ユーザ・コンテクストという共通の概念を提供する。１つの実施形態において、ユーザ・コンテクストは真または偽になり得る条件と、この条件が真の場合に従う指示（instruction）で構成される。たとえば、ユーザが音楽を聴いているという条件に対して、指示は、スクリーン上に通知を表示し、しかし通知をするためにどのような音も再生しないとすることができる。ユーザ・コンテクストは、オペレーティング・システムと任意のプログラムで宣言される（２０４）。ユーザ・コンテクストは、ユーザの選好に従う変更のために、ユーザに提示することができる（２０４）。ユーザは、規則を定義して、この規則により、指定された要素を含む通知がどのように処理されるべきかを指示することもでき（２０４）、また、ユーザ・コンテクストの指示に対して例外を指定することもできる。
2006521595.tif 000002
【特許請求の範囲】
【請求項１】
ユーザに通知を配信するコンピュータ・システムにおいて、通知の配信を制御する方法であって、
少なくとも第１の状態または第２の状態になり得る第１の条件を宣言すること、
前記第１の条件がその第１の状態にあると決定した場合に、前記通知の配信を制御するために実行する第１の配信指示を規定すること、および
複数のソースから通知を受信し、前記第１の条件がその第１の状態にあると決定した場合に、前記第１の配信指示に従って前記通知の配信を制御すること
を備えることを特徴とする方法。
【請求項２】
前記第１の条件は、通知の受信に対する前記ユーザの現在の「ａｖａｉｌａｂｌｅ」な状態を少なくとも部分的に示すことを目的とするユーザ・コンテクストの一部であることを特徴とする請求項１に記載の方法。
【請求項３】
前記第１の条件は、その第１の状態にある場合に、前記ユーザは少なくとも部分的にその視覚が占有されている可能性があることを示し、前記第１の配信指示は通知をその視覚的な表示の面で制限することを特徴とする請求項１に記載の方法。
【請求項４】
前記第１の条件は、その第１の状態にある場合に、前記ユーザは少なくとも部分的に音を聞くことに占有されている可能性があることを示し、前記第１の配信指示は前記通知の配信をそのボリュームの面で制限することを特徴とする請求項１に記載の方法。
【請求項５】
前記第１の条件は、その第１の状態にある場合に、ユーザは任意の種類の通知の受信に対して「ａｖａｉｌａｂｌｅ」でない可能性があることを示しており、前記第１の配信指示は、通知の配信全体を制限することを特徴とする請求項１に記載の方法。
【請求項６】
前記第１の配信指示は、前記ユーザの選好に合わせて前記ユーザが変更できることを特徴とする請求項１に記載の方法。
【請求項７】
前記第１の条件は、前記ユーザが無効化でき、この場合は前記第１の条件がその第１の状態にあっても、前記第１の配信指示に従わないことを特徴とする請求項１に記載の方法。
【請求項８】
前記第１の条件について、その第１の状態はそれが真の場合であり、その第２の状態はそれが偽の場合であることを特徴とする請求項１に記載の方法。
【請求項９】
前記第１の条件の状態は、前記第１の条件が宣言された時点で最初に決定されることを特徴とする請求項１に記載の方法。
【請求項１０】
前記第１の条件の状態は、通知が配信された時点で決定されることを特徴とする請求項１に記載の方法。
【請求項１１】
前記第１の条件はオペレーティング・システムによって宣言されることを特徴とする請求項１に記載の方法。
【請求項１２】
前記第１の条件は、オペレーティング・システム以外のソースによって宣言されることを特徴とする請求項１に記載の方法。
【請求項１３】
前記オペレーティング・システム以外のソースはプログラムであることを特徴とする請求項１２に記載の方法。
【請求項１４】
少なくとも第１の状態または第２の状態になり得る第２の条件が宣言され、前記第２の条件がその第１の状態にある場合に、通知の配信を制御するために実行する第２の配信指示が規定されることを特徴とする請求項１１に記載の方法。
【請求項１５】
追加の条件が宣言され、対応する追加の配信指示が規定されることを特徴とする請求項１４に記載の方法。
【請求項１６】
前記条件は、オペレーティング・システムと一連のプログラムによって宣言されることを特徴とする請求項１５に記載の方法。
【請求項１７】
少なくとも第１の指定された要素を含む前記通知の配信を制御する方法を指示する第１の規則を定義することをさらに備えることを特徴とする請求項１に記載の方法。
【請求項１８】
追加の規則が定義され、２つの規則が競合する場合は、より侵襲性の高い規則が適用されることを特徴とする請求項１７に記載の方法。
【請求項１９】
前記第１の規則は、前記ユーザによって宣言されることを特徴とする請求項１７に記載の方法。
【請求項２０】
追加の規則は、前記ユーザによって宣言されることを特徴とする請求項１９に記載の方法。
【請求項２１】
前記規則は、前記ユーザの選好に合わせて前記ユーザが変更できることを特徴とする請求項２０に記載の方法。
【請求項２２】
前記第１の配信指示は、通知のルーティング、拒否、保留、配信のうちの少なくとも１つを備えることを特徴とする請求項１に記載の方法。
【請求項２３】
通知の配信を制御する方法を実装するためのコンピュータ実行可能コンポーネントを有するコンピュータ可読媒体であって、前記方法は、
少なくとも第１の状態または第２の状態になり得る第１の条件を宣言すること、
前記第１の条件がその第１の状態にあると決定した場合に、前記通知の配信を制御するために実行する第１の配信指示を規定すること、および
複数のソースから通知を受信し、前記第１の条件がその第１の状態にあると決定した場合に、前記第１の配信指示に従って前記通知の配信を制御すること
を備えることを特徴とするコンピュータ可読媒体。
【請求項２４】
前記第１の条件は、通知の受信に対する前記ユーザの現在の「ａｖａｉｌａｂｌｅ」な状態を少なくとも部分的に示すことを目的とするユーザ・コンテクストの一部であることを特徴とする請求項２３に記載の方法。
【請求項２５】
前記第１の配信指示は、通知のルーティング、拒否、保留、配信のうちの少なくとも１つを備えることを特徴とする請求項２３に記載の方法。
【請求項２６】
前記第１の配信指示は、通知の配信をその視覚的な表示の面で制限することを特徴とする請求項２３に記載の方法。
【請求項２７】
前記第１の配信指示は、通知の配信をそのボリュームの面で制限することを特徴とする請求項２３に記載の方法。
【請求項２８】
前記第１の配信指示は、前記ユーザの選好に合わせて前記ユーザが変更できることを特徴とする請求項２３に記載の方法。
【請求項２９】
前記第１の条件について、その第１の状態はそれが真の場合であり、その第２の状態はそれが偽の場合であることを特徴とする請求項２３に記載の方法。
【請求項３０】
前記第１の条件は、オペレーティング・システムによって宣言されることを特徴とする請求項２３に記載の方法。
【請求項３１】
少なくとも第１の状態または第２の状態になり得る第２の条件がオペレーティング・システム以外のソースによって宣言され、前記第２の条件がその第１の状態にある場合に通知を配信するために実行する第２の配信指示が規定されることを特徴とする請求項３０に記載の方法。
【請求項３２】
前記第２の条件を宣言するソースは、プログラムであることを特徴とする請求項３１に記載の方法。
【請求項３３】
少なくとも第１の指定された要素を含む前記通知の配信を制御する方法を規定する第１の規則を定義することをさらに備えることを特徴とする請求項２３に記載の方法。
【請求項３４】
追加の規則が定義され、２つの規則が競合する場合は、より侵襲性の高い規則が適用されることを特徴とする請求項３３に記載の方法。
【請求項３５】
前記第１の規則は、ユーザによって宣言されることを特徴とする請求項３３に記載の方法。
【請求項３６】
前記第１の規則と前記第１の配信指示は、前記ユーザの選好に合わせて前記ユーザが変更できることを特徴とする請求項３５に記載の方法。
【請求項３７】
ユーザに通知を配信するコンピュータ・システムにおいて、通知の配信を制御する方法であって、
複数のユーザ・コンテクストを宣言し、各ユーザ・コンテクストは真または偽になり得る条件、および前記条件が真の場合に従う指示、を備えること、および
複数のソースから通知を受信すること、および
ユーザ・コンテクストの前記条件が真の場合に前記通知に対して実行すべき処理を決定する前記ユーザ・コンテクストに対応する指示に従うこと
を備えることを特徴とする方法。
【請求項３８】
前記指示は通知のルーティング、拒否、保留、配信の少なくとも１つを備えることを特徴とする請求項３７に記載の方法。
【請求項３９】
前記指示は、前記ユーザの選好に合わせて前記ユーザが変更できることを特徴とする請求項３７に記載の方法。
【請求項４０】
前記複数のユーザ・コンテクストの少なくとも１つはオペレーティング・システムによって宣言されることを特徴とする請求項３７に記載の方法。
【請求項４１】
前記複数のユーザ・コンテクストの少なくとも１つはオペレーティング・システム以外のソースによって宣言されることを特徴とする請求項３７に記載の方法。
【請求項４２】
前記オペレーティング・システム以外のソースはプログラムであることを特徴とする請求項４１に記載の方法。
【請求項４３】
各規則に対応する指定された要素を含み、前記通知の配信を制御する方法を規定する複数のユーザ規則を定義することをさらに備えることを特徴とする請求項３７に記載の方法。
【請求項４４】
２つのユーザ規則が競合する場合は、より侵襲性の高い規則が適用されることを特徴とする請求項４３に記載の方法。
【請求項４５】
前記ユーザ規則は、前記ユーザによって宣言されることを特徴とする請求項４４に記載の方法。
【請求項４６】
前記ユーザ・コンテクストとユーザ規則は、前記ユーザの選好に合わせて前記ユーザが変更できることを特徴とする請求項４５に記載の方法。
【請求項４７】
通知の配信を制御する方法を実装するためのコンピュータ実行可能コンポーネントを有するコンピュータ可読媒体であって、前記方法は、
複数のユーザ・コンテクストを宣言し、各ユーザ・コンテクストは真または偽になり得る条件および条件が真の場合に従う指示を規定すること、および
複数のソースから通知を受信すること、および
ユーザ・コンテクストの前記条件が真の場合に前記通知に対して実行する処理を決定する前記ユーザ・コンテクストに対応する指示に従うこと
を備えることを特徴とするコンピュータ可読媒体。
【請求項４８】
前記指示は、通知のルーティング、拒否、保留、配信の少なくとも１つを備えることを特徴とする請求項４７に記載の方法。
【請求項４９】
前記指示は、前記ユーザの選好に合わせて前記ユーザが変更できることを特徴とする請求項４７に記載の方法。
【請求項５０】
前記複数のユーザ・コンテクストの少なくとも１つはオペレーティング・システムによって宣言されることを特徴とする請求項４７に記載の方法。
【請求項５１】
前記複数のユーザ・コンテクストの少なくとも１つはオペレーティング・システム以外のソースによって宣言されることを特徴とする請求項４７に記載の方法。
【請求項５２】
前記オペレーティング・システム以外のソースはプログラムであることを特徴とする請求項５１に記載の方法。
【請求項５３】
各規則に対応する指定された要素を含む、前記通知の配信を制御する方法を規定する複数のユーザ規則を定義することをさらに備えることを特徴とする請求項４７に記載の方法。
【請求項５４】
２つのユーザ規則が競合する場合は、より侵襲性の高い規則が適用されることを特徴とする請求項５３に記載の方法。
【請求項５５】
前記ユーザ規則は、前記ユーザによって宣言されることを特徴とする請求項５４に記載の方法。
【請求項５６】
前記ユーザ・コンテクストとユーザ規則は、前記ユーザの選好に合わせて前記ユーザが変更できることを特徴とする請求項５５に記載の方法。
【請求項５７】
前記通知の配信を制御するシステムにおいて、
少なくとも第１の状態または第２の状態になり得る第１の条件を宣言する手段と、
前記第１の条件がその第１の状態にあると決定した場合に、通知の配信を制御するために実行する第１の配信指示を規定する手段と
複数のソースから通知を受信し、前記第１の条件がその第１の状態にあると決定した場合に、前記第１の配信指示に従って前記通知の配信を制御する手段と
を備えることを特徴とするシステム。
【請求項５８】
前記ユーザの選好に合わせて、前記第１の配信指示を前記ユーザが変更できるようにする手段をさらに備えることを特徴とする請求項５７に記載のシステム。
【請求項５９】
前記第１の条件の状態を前記第１の条件が宣言された時点で決定する手段をさらに備えることを特徴とする請求項５７に記載のシステム。
【請求項６０】
前記第１の条件の状態を前記通知が配信される時点で決定する手段をさらに備えることを特徴とする請求項５７に記載のシステム。
【請求項６１】
少なくとも第１の指定された要素を含む、前記通知の配信を制御する方法を規定する第１の規則を定義する手段をさらに備えることを特徴とする請求項５７に記載のシステム。
【請求項６２】
通知のルーティング、拒否、保留、配信のうちの少なくとも１つを備える前記配信指示を実行する手段をさらに備えることを特徴とする請求項５７に記載のシステム。
【請求項６３】
通知の配信を制御するシステムであって、
各ユーザ・コンテクストが真または偽になり得る条件と、前記条件が真の場合に従う指示とを備える複数のユーザ・コンテクストを宣言する手段と
複数のソースから通知を受信する手段と
ユーザ・コンテクストの前記条件が真の場合に前記通知に対して実行する処理を決定する前記ユーザ・コンテクストに対応する指示に従う手段と
を備えることを特徴とするシステム。
【請求項６４】
通知のルーティング、拒否、保留、配信のうちの少なくとも１つを備える指示を実行する手段をさらに備えることを特徴とする請求項６３に記載のシステム。
【請求項６５】
前記ユーザの選好に合わせて、前記指示を前記ユーザが変更できるようにする手段をさらに備えることを特徴とする請求項６３に記載のシステム。
【請求項６６】
各規則に対応する指定された要素を含む、前記通知の配信を制御する方法を規定する複数のユーザ規則を定義する手段をさらに備えることを特徴とする請求項６３に記載のシステム。
【請求項６７】
前記ユーザの選好に合わせて、前記ユーザ規則を前記ユーザが変更できるようにする手段をさらに備えることを特徴とする請求項６３に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピューティング・システムおける通知に関し、より詳細には複数のソースからの通知の配信（delivery）をユーザ・コンテクストに従って制御するシステムに関する。
【背景技術】
【０００２】
（関連出願の相互参照）
本出願は、参照によりその全体を本明細書に組み込まれている、本発明と同時に出願した米国出願代理人整理番号ＭＳＦＴ−１−２０４６２、「System and Method Utilizing Test Notifications」に関する。
【０００３】
コンピュータ・システムにおいて、通知（notification）は、指定されたイベントが発生したことをユーザに知らせるプログラムからの信号形式とすることができる。このような通知には、テキスト、音、グラフィックの様々な要素を含めることができる。通知には、重要度、通知の送信者（電子メールやインスタント・メッセージングのようなチャネルの場合）、通知の有効期限など、その他のプロパティを含めることができる。また、通知には、いくつかのコードの要素を含めて、ユーザが通知と対話したり、任意のコードを起動したりする（たとえば、新しいプログラムを起動させたり、現在実行中のプログラムに関して取られるアクションを引き起こすその通知内のボタンやテキストをクリックする）ことができる。
【０００４】
オペレーティング・システムが、ネットワークの接続性や更新情報についてユーザに知らせる通知を作成することができる。「連絡先リスト」を使用するインスタント・メッセージング・プログラムは、通知をスクリーンに表示して、連絡先リストに関して何が起こったか、または連絡先がいつインスタント・メッセージの対話を開始したかをユーザに知らせることができる。その他のプログラムも、同じような通知を作成してディスプレイの同じような領域に表示できる。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
このようなタイプの通知に関する１つの問題は、一般にこのような通知が他の通知を把握していないことであり、この結果、場合によっては他の通知の上に表示されることがある。
【０００６】
既存の通知システムに関する別の問題は、それらが、不適切に、不適切な時間に通知が配信される可能性があるということである。たとえば、全スクリーンのプレゼンテーションを行っているユーザにとっては、プレゼンテーションの最中にそのスクリーン上に他のプログラムが通知を表示させることは不適切である可能性がある。こうした不適切な通知を表示するプログラムの例として、インスタント・メッセージング・プログラムがあり、このプログラムは、オペレーティング・システムのバックグラウンドで動作し、連絡先リストの連絡先がサインオンした場合やインスタント・メッセージを開始した場合に、こうした通知を表示する。プレゼンテーションの最中のこの種の「割り込み」は、ユーザが希望しないものである可能性がある。
【０００７】
本発明は、前述の問題またはその他の問題を解決するシステムを提供することを目的とする。より詳細には、本発明は、複数のソースから発生する通知のそれぞれについて適切な処理を決定する場合に、ユーザ・コンテクスト（ユーザの状況）を考慮しながら通知の配信を制御するシステムを目的とする。本発明は、複数のソースかの通知の配信を制御し、通知のそれぞれについて適切な処理を決定する場合に、ユーザ・コンテクストを考慮する、システムを目的とする。
【課題を解決するための手段】
【０００８】
通知の配信を制御するシステムを提供する。本発明の一態様によれば、本システムは複数のソースからの通知の配信を仲介し、順序付け（シリアライズ）する。さらに、個々の通知に適した処置を決定するために、ユーザ・コンテクストという共通の概念を提供する。こうした態様により、本システムが配信する通知は、ユーザが、より受け入れることのできるタイミングで配信されるという点で、より価値が高いと考えることができる。また、こうした態様により、望ましくない通知をユーザが排除することを手助けするための共通の規則が提供される。
【０００９】
本発明の別の態様により、ユーザ・コンテクストは、オペレーティング・システムと任意のプログラムによって宣言される。１つの実施形態において、ユーザ・コンテクストは、真（該当）または偽（非該当）になり得る条件と、この条件が真の場合に従う指示（instruction）を備えている。たとえば、１つの条件は「ユーザが音楽を聴いている場合」であり、対応する指示（instruction）は「スクリーンに通知を表示するが、音（sound）は無し」であってもよい。一般に、ユーザ・コンテクストの条件は、本システムで想定される、通知の配信に対してユーザが何らかの形で「ｕｎａｖａｉｌａｂｌｅ（利用できない、対応したくない、手があいていない）」状態、またはその通知を作成したプログラムによって送信された方法とは異なる方法で通知を配信する必要がある状態、と本システムが想定する状態と考えることができる。ユーザが、「ｕｎａｖａｉｌａｂｌｅ」と見なされる状態にある可能性があり、この場合は、通知は配信されないか、またはユーザが「ａｖａｉｌａｂｌｅ（利用できる、対応できる、手があいている）」状態になるまで保留にする。たとえば、ユーザが全スクリーンのアプリケーションを実行している場合は、ディスプレイ・スクリーンの領域全体をこのアプリケーションで使用または表示しているので、そのユーザは、「ｕｎａｖａｉｌａｂｌｅ」であると見なされる可能性がある。あるいは、その場合は、そのユーザが「ａｖａｉｌａｂｌｅ」である可能性があり、ただし、その通知が、そのユーザに都合のよい形に変更される必要がある、状態であると見なすことが可能である。
【００１０】
本発明の別の態様により、オペレーティング・システムがコンテクストを宣言する以外に、プログラムは、それが規定するコンテクストと、それが通知に関して有する影響（スクリーンに表示するのが適切かどうかと、スクリーンに表示するのに適した侵襲性（invasiveness）のレベル、およびサウンドを発生するのが適切かどうかとサウンドを発生する場合の相対的なボリューム、などのように）をシステムに登録して宣言し、そのコンテクストが真か偽かをシステムに知らせる。１つの実施形態において、コンテクストが真か偽かは通知を配信するときに評価することができる。１つの実施形態において、システムは、呼び出し側プログラム（calling program）のプロセスを追跡することもできる。このプロセスが存在しなくなった場合は、コンテクストを偽にリセットできる。このプロセスを追跡することで、たとえばアプリケーションがユーザはビジー状態にあると宣言したままクラッシュした場合に、通知の受信に対応できないと宣言された状態のスタック状態にユーザが放置されるといった、特定の望ましくない状態を回避できる。
【００１１】
本発明の別の態様により、通知の表示に関して様々なレベルの侵襲性を指定することができる。換言すれば、ユーザ・コンテクストに基づいて、表示された通知の段階的な変化があってもよい。このために、通知の表示形式において様々なレベルの侵襲性を指定できる。たとえば、標準の通知はクライアント領域に制約を受けずに表示され、少しの時間だけウィンドウが隠される、とすることができる。ユーザがやや限定的なコンテクストにある場合は、通知を、制約を受けずに表示するが、たとえば別のウィンドウの上には表示しないといった侵襲性を抑える形で、表示することができる。別の例として、ユーザが最大表示のアプリケーションを実行している場合に、この設定は、ユーザ・コンテクストがやや制約され、さらにユーザは現在のアプリケーションでクライアント領域全体を使用するという意志を表明している、設定であるとすることができる。この状況では、通知を表示することができるが、サイドバーに出現する場合のみに表示することができる。このように通知の表示形式における低減された侵襲性のこのタイプは、通知の影響を少なくし、認識の負荷を少なくする。
【００１２】
本発明の別の態様により、規定されたコンテクストをユーザに提示し、無効化したり（このプログラムのコンテクストの評価をユーザが承認しない場合）、配信への影響に関して変更したりすることができる。
【００１３】
本発明の別の態様により、ユーザは、規則を定義して、指定された要素を含む通知がどのように配信されるかを指示することができる。たとえば、ユーザ規則によって、「Ｊｏｈｎ  Ｄｏｅ」から受信した通知で、その件名の行に「ｕｒｇｅｎｔ（緊急）」とあるすべての通知は、直ちに配信されるべきであると、規定することができる。１つの実施形態において、こうしたユーザ規則は、ユーザ・コンテクストより優先される。このユーザ規則は、ユーザの選好に合わせてユーザが変更できるようにされる。
【００１４】
本発明の前述の態様および多くの付帯的な利点は、以下に示す実施形態に関する説明と添付の図面を組み合わせて参照することでより深く理解され、より明らかになるであろう。
【発明を実施するための最良の形態】
【００１５】
本発明は、通知を配信するシステムを目的とする。 
先行するシステムにおいては、一般に、ユーザに通知を送信しようとする多くの競合するエレメントが存在し、各エレメントは、独自の方法でこうした通知を送信するように設計されている。通常、これらの競合するエレメントは、いずれもが他の通知を認識せず、したがって、互いに、互いのアプリケーションの上に表示を行う傾向がある。したがって、各エレメントがそれぞれの通知を表示することを同時に決定した場合は、先行するシステムにおいては、競合が発生することになる。さらに、先行するシステムにおいては、ユーザ・コンテクストという共通の概念は存在しないので、特定の通知が不適切な形式で、あるいは不適切なタイミングで、配信されることになる。本発明は、オペレーティング・システムの得意とする部分で通知を構築することでこうした問題に対応しているので、本発明によって提供される通知に関するユーザ・インターフェースも類似のものになり、これにより、本システムは、通知のスクリーン表示を適切に仲介し、順序付けするので、互いの競合はなくなる。さらに、本発明が提供する通知は、ユーザがより受け入れやすいタイミングで配信されるだけでなく、共通の規則を使用することでユーザに不都合な通知を排除するという点で、より価値が高いと考えることができる。
【００１６】
図１と以下の記述は、本発明を実装できる適切なコンピューティング環境の簡単で一般的な説明を提供することを目的とするものである。必須ではないが、本発明を、パーソナル・コンピュータで実行されるプログラム・モジュールのような、コンピュータ実行可能命令（群）という一般的なコンテクストで説明する。一般に、プログラム・モジュールには、特定のタスクを実行したり、特定の抽象データ型を実装したりするルーチン、プログラム、文字、コンポーネント、データ構造などがある。当業者には認識されるように、本発明は、ハンドヘルド・デバイス、マルチ・プロセッサ・システム、マイクロ・プロセッサベースまたはプログラム可能な家庭用電子機器、ネットワークＰＣ、ミニ・コンピュータ、メインフレーム・コンピュータなどを含むその他のコンピュータ・システム構成で、実施することができる。本発明は、通信ネットワークを介してリンクするリモート処理装置でタスクを実行する分散コンピューティング環境でも実施することができる。分散コンピューティング環境では、プログラム・モジュールはローカルとリモートの両方のメモリ記憶装置内に配置できる。
【００１７】
図１を参照すると、本発明を実施するための例示的なシステムには、プロセッシング・ユニット２１、システム・メモリ２２、およびシステム・メモリ２２からプロセッサ・ユニット２１までの様々なシステム・コンポーネントを接続するシステム・バス２３を含む従来のパーソナル・コンピュータ２０の形をとる汎用コンピューティング・デバイスが含まれる。システム・バス２３は、様々なバス・アーキテクチャのいずれかを使用したメモリ・バスまたはメモリ・コントローラ、周辺バス、ローカル・バスを含む各種バス構造のいずれでもよい。システム・メモリには、読み取り専用メモリ（ＲＯＭ：read only memory）２４とランダム・アクセス・メモリ（ＲＡＭ：random access memory）２５が含まれる。起動時などにパーソナル・コンピュータ２０内のエレメント間の情報転送を支援する基本ルーチンを含む基本入出力システム２６（ＢＩＯＳ：basic input/output system）は、ＲＯＭ２４に格納される。パーソナル・コンピュータ２０には、さらにハードディスク３９に対する読み出しまたは書き込みを行うハードディスク・ドライブ２７、取り外し可能な磁気ディスク２９に対する読み出しまたは書き込みを行う磁気ディスク・ドライブ２８、ＣＤ−ＲＯＭ、または他の光媒体のような取り外し可能な光ディスク３１に対する読み出しまたは書き込みを行う光ディスク・ドライブ３０が含まれる。ハードディスク・ドライブ２７、磁気ディスク・ドライブ２８、および光ディスク・ドライブ３０は、それぞれハードディスク・ドライブ・インターフェース３２、磁気ディスク・ドライブ・インターフェース３３、および光ディスク・ドライブ・インターフェース３４を介してシステム・バス２３に接続する。ドライブとそれらの関連するコンピュータ可読媒体は、コンピュータ可読指示、データ構造、プログラム・モジュールなど、パーソナル・コンピュータ２０のデータを保存する不揮発性ストレージとして利用できる。ここに記載する例示的な環境では、ハードディスク３９、取り外し可能な磁気ディスク２９、および取り外し可能な光ディスク３１を使用しているが、磁気カセット、フラッシュ・メモリ・カード、デジタル・ビデオ・ディスク（ＤＶＤ：digital video disk）、ベルヌーイ・カートリッジ（Bernoulli cartridge）、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）などのように、コンピュータからアクセス可能なデータを保存できる他のタイプのコンピュータ可読媒体も、例示的な動作環境において使用できることは、当業者には認識されるべきである。
【００１８】
多くのプログラム・モジュールは、ハードディスク３９、磁気ディスク２９、光ディスク３１、ＲＯＭ２４、またはＲＡＭ２５に保存することが可能であり、プログラム・モジュールは、オペレーティング・システム３５、１つまたは複数のアプリケーション・プログラム３６、その他のプログラム・モジュール３７、およびプログラム・データ３８を含む。ユーザは、キーボード４０やポインティング・デバイス４２などの入力装置を使用してパーソナル・コンピュータ２０にコマンドや情報を入力できる。他の入力装置（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、サテライト・ディッシュ（satellite dish）、スキャナなどを含めてもよい。これらの入力装置および他の入力装置は、多くの場合、システム・バス２３に接続するシリアル・ポート・インターフェース４６を介してプロセッシング・ユニット２１に接続するが、パラレル・ポート、ゲーム・ポート、ユニバーサル・シリアル・バス（ＵＳＢ：universal serial bus）のような他のインターフェースで接続してもよい。モニター４７の形式のディスプレイも、ビデオ・カードまたはビデオ・アダプタ４８のようなインターフェースを介してシステム・バス２３に接続される。１つまたは複数のスピーカー５７も、オーディオ・アダプタ５６などのインターフェースを介してシステム・バス２３に接続できる。パーソナル・コンピュータには、一般にディスプレイやスピーカー以外にもプリンタなどの周辺出力装置（図示せず）が接続されている。
【００１９】
パーソナル・コンピュータ２０は、リモート・コンピュータ４９のような１台または複数台のパーソナル・コンピュータへの論理接続を使用してネットワーク環境で動作できる。リモート・コンピュータ４９は、別のパーソナル・コンピュータ、サーバー、ルーター、ネットワークＰＣ、ピア・デバイス、または他の一般的なネットワーク・ノードでもよく、通常はパーソナル・コンピュータ２０に関連して上に説明したエレメントの多くまたはすべてが含まれる。図１に示す論理接続には、ローカル・エリア・ネットワーク（ＬＡＮ：local area network）５１とワイド・エリア・ネットワーク（ＷＡＮ：wide area network）５２を含む。このようなネットワーキング環境は、職場、企業規模のコンピュータ・ネットワーク、イントラネット、およびインターネットではごく一般的である。
【００２０】
ＬＡＮネットワーキング環境で使用する場合、パーソナル・コンピュータ２０はローカル・エリア・ネットワーク５１にネットワーク・インターフェースまたはアダプタ５３を介して接続する。ＷＡＮネットワーキング環境で使用する場合、パーソナル・コンピュータ２０は一般にインターネットなどのワイド・エリア・ネットワーク（ＷＡＮ）５２を介して通信を確立するためのモデム５４またはその他の手段を備えている。モデム５４（内蔵または外付け）は、シリアル・ポート・インターフェース４６を介してシステム・バス２３に接続できる。ネットワーク環境では、パーソナル・コンピュータ２０またはその一部に関連して説明したプログラム・モジュールをリモートメモリ記憶装置に格納できる。図示されたネットワーク接続は例示的なものであり、コンピュータ間の通信リンクを確立する他の手段を使用してもよいことを認識されたい。
【００２１】
本発明は、図１に示すタイプのシステム上に実装され、ユーザへの通知の配信を規定する。より具体的には、以下の説明からさらに深く理解されるように、本発明は、複数のソースから発生する通知の配信をユーザ・コンテクストに従って制御することを規定する。
【００２２】
１つの実施形態において、本発明によるユーザ・コンテクスト・システムは、通知を処理する方法を決定するために比較される３つの要素で構成できる。第１の要素は、（オペレーティング・システムとそれを拡張する任意のプログラムで規定できる）ユーザ・コンテクストである。第２の要素は、ユーザ規則とユーザ選好（user's preferences）である。第３の要素は、（ユーザ規則に一致する可能性のあるデータやプロパティなどを含む）通知そのものである。
【００２３】
以下でより詳細に説明するように、本発明は、オペレーティング・システムと、それ以外の、ユーザ・コンテクストを宣言するプログラムによって動作し、続いて本システムが、ユーザ・コンテクストとユーザ規則を仲介する。通知は、本システムを呼び出す他のプログラムによってもたらされる。ユーザ・コンテクスト、ユーザ規則、通知の各要素が比較され、何がその通知に対して実行されるべきかについて決定がなされる。通知に対して何が実行されるべきかに対する様々なオプションの例には、拒否すること（通知が、表示することも音を出すことも許可されない場合、通知はユーザに認識されることはない）、保留（ユーザ・コンテクストが変わるまで通知を保留する、またはユーザ規則が後で配信するのが適切であると規定している）、配信（ユーザ・コンテクストとユーザ規則に従って通知の配信が許可される）、ルーティング（routing）（ユーザ規則は、本システムで通知の配信が許可されるかどうかにかかわらず、通知を別のシステムに渡すように規定している）がある。
【００２４】
通知を配信するための様々なルーチンについて、以下でより詳細に説明する。一般に、ユーザが「ｕｎａｖａｉｌａｂｌｅ」と見なされる状態にある場合は、通知を配信しないか、またはユーザが「ａｖａｉｌａｂｌｅ」になるまで保留にする。たとえば、ユーザが全スクリーンのアプリケーションを実行しているときは、ユーザはｕｎａｖａｉｌａｂｌｅであると見なされる。あるいは、ユーザは「ａｖａｉｌａｂｌｅ」であるが、ユーザに適した形に通知を変更する必要がある状態、と見なされる。たとえば、ユーザが音楽を聴いている場合、または会議中の場合に、ユーザは、通知はユーザのスクリーンに配信するが、静音または無音にする、と規定しておくことができる。
【００２５】
前述のように、ユーザ・コンテクストは１つにはユーザのスクリーンに通知を表示するかどうかを決定する。通知を表示する場合は、ユーザ・コンテクストで指定する特定の段階的レベルに基づいて表示できる。換言すれば、通知の表示形式による様々なレベルの侵襲性を指定できる。たとえば、標準の通知はクライアント領域に自由に表示され、少しの時間だけウィンドウが隠される。ユーザがやや限定的なコンテクストにある場合は、通知を表示するが、たとえば別のウィンドウの上には表示しないといった侵襲性を抑える形のみに制限してもよい。別の例として、１つの実施形態においてユーザが最大表示のアプリケーションを実行している場合に、デフォルトの設定ではコンテクストがやや限定的であり、現在のアプリケーションがクライアント領域全体を使用するという意志をユーザが表明していることを意味する。この設定では、通知の表示は許可されるが、表示できるのはサイドバーのみと考えてもよい。つまり、このように通知の表示形式を変えて侵襲性を抑えると、通知の影響が少なくなり、全体的な認識の負荷が縮小される。
【００２６】
図２は、本発明により、通知を処理するルーチン２００を示す流れ図である。ブロック２０２で、オペレーティング・システムまたは任意のプログラムが通知アプリケーション・プログラミング・インターフェース（ＡＰＩ：application programming interface）を呼び出す。ブロック２０４で、通知の要素がオペレーティング・システムと任意のプログラムで設定したユーザ・コンテクストに関して評価され、さらにユーザが設定したユーザ規則に基づいてユーザが承認したり変更したりする。ブロック２０６で、通知が配信されたり、保留されたり、拒否されたり、ルーティングされたり、あるいはユーザ・コンテクストとユーザ規則に従って処理されたりする。
【００２７】
ユーザ・コンテクストとユーザ規則について、以下に詳述する。１つの実施形態において、ユーザ・コンテクストは真または偽になり得る条件と、この条件が真の場合に従う通知の処理方法に関する指示（instruction）で構成される。一般に、ユーザ・コンテクストの条件は、通知の配信に対してユーザが何らかの形で「ｕｎａｖａｉｌａｂｌｅ（利用できない、対応したくない、手があいていない）」状態、またはその通知を作成したプログラムによって送信された方法と異なる方法で通知を配信する必要がある状態、と本システムが想定する状態と考えることができる。換言すれば、１つの実施形態において、ユーザ・コンテクストは「条件Ｘが真の場合は、受信した通知に対して実行すべき処理はこうである」というステートメント（命令文）と考えることができる。たとえば、「音楽プレーヤーが音楽を再生しているときは、受信した通知はスクリーン上に表示されるべきであり、音は出さない」でもよい。別の例では、「アプリケーションが全スクリーン・モードで動作している場合は、受信した通知は、その後まで保留にされるべきである」でもよい。
【００２８】
こうしたユーザ・コンテクストに関して、１つの実施形態においてユーザは受信した通知の処理に関して特定の規則を定義することもできる。このように、ユーザ・コンテクストの指示（instruction）に対して例外を規定できる。たとえば、ユーザ規則は、「「Ｊｏｈｎ  Ｄｏｅ」から受信した新しい電子メールの本文に「ｕｒｇｅｎｔ（緊急）」とあり、「重要度：高」のマークがある場合は、ユーザ・コンテクストにかかわらずこの電子メールを配信する」との命令文であってもよい。換言すれば、この例においてこのユーザ規則は、ユーザ・コンテクストに対する例外を規定しており、例外に該当しない場合、ユーザ・コンテクストは、受信した電子メールに関する通知をこの時点で配信するのが適切ではない、ことを示している。ユーザ規則の評価対象となる通知の各要素に関して、こうした要素には、テキスト、音、グラフィック、およびその他のプロパティで、重要度、通知の送信者（電子メールやインスタント・メッセージングなどのチャネル）、通知の有効期限、およびユーザが通知と対話して任意のコードを起動できるような（たとえば、通知内のボタンやテキストをクリックすることで新しいプログラムを起動したり、現在実行中のプログラムに対して処置（電子メールの削除など）をとったりできる）コードの要素、などのプロパティを含めることができる。
【００２９】
図３は、オペレーティング・システムまたは任意のプログラムのユーザ・コンテクストを宣言するルーチン２２０を示す流れ図である。ブロック２２２で、オペレーティング・システムまたはプログラムは、デフォルトのコンテクストとその影響を、ユーザのビジー状態に基づいて宣言する。換言すれば、プログラムは、通知に対して予定する影響（たとえば、スクリーンへの表示が適切な場合、音が適切かどうか、あるいはどのていど大きさで再生されるべきか）を含むユーザ・コンテクストをシステムに登録して、規定する。たとえば、音楽プレーヤー・プログラムは、「音楽プレーヤーが音楽を再生しているときは、受信した通知はスクリーン表示されるべきであって、音は出さない」というデフォルトのコンテクストを宣言してもよい。別の例として、オペレーティング・システムは「全スクリーン・モードで動作しているアプリケーションがある場合は、その後の時点まで保留にする」というコンテクストを宣言してもよい。
【００３０】
図３に戻り、ブロック２２４で、オペレーティング・システムまたはプログラムは宣言したコンテクストを真または偽として設定する。たとえば、「音楽プレーヤーが音楽を再生しているときは、受信した通知のスクリーン表示は必要であるが、音は使用しない」というコンテクストを宣言している音楽プレーヤーに関して、この音楽プレーヤー・プログラムは、この宣言されたコンテクストが、現在、真であるか偽であるか、についても設定する。換言すれば、この音楽プレーヤー・プログラムは、音楽プレーヤー・プログラムが現在音楽を再生しているという条件が真か偽かを、指示する。以下でより詳細に説明するように、１つの実施形態において、コンテクストが真か偽かの決定は、通知ＡＰＩが呼び出された時点、あるいはユーザ規則と例外を再評価する時点で評価することができる。追加の機能として、システムは呼び出し側プログラムのプロセス・ハンドル（process handle）を追跡することが可能であり、それにより、そのプロセスがコンテクストの値をデフォルトの「偽」の値にリセットせずに終了した場合に、本システムは、最初のプロセスがもはや存在していないことを検出すると同時に、そのコンテクストの値をリセットする（１つの実施形態では、プロセス・ハンドルの状態は、プロセスが終了したことを知らせるように設定され、その状態変化は、プロセス・ハンドルを監視するシステムによって検出される）。このことは、プロセスが予期せずに終了した場合またはコンテクストをリセットし忘れた場合に、その後の通知配信に不適切な影響がないことを保証する。たとえば、上の例では、音楽プレーヤー・プログラムが閉じてそのプロセスが存在しなくなった場合に、このコンテクストを自動的に偽にリセットできる。別の例として、プログラムが初めにユーザがビジー状態にあることを宣言し、その後プログラムがクラッシュしてプロセスが存在しなくなった場合は、通知を受信しないスタック状態にユーザが放置されるのではなく、コンテクストは自動的に偽にリセットされるようになる。いずれにしても、コンテクストがアクティブに設定されるかどうか、あるいは機能として評価されるかどうかにかかわらず、１つの実施形態においてコンテクストは一般に真と偽のいずれかに解決される。
【００３１】
図３に戻り、ブロック２２６で、システムに格納されたユーザ・コンテクストにコンテクスト情報が追加される。このプロセスは、追加のプログラムがコンテクストを宣言するたびに繰り返される。さらに、前述のように、宣言済みのコンテクストが真または偽の状態は、ユーザが様々なプログラムを開いたり、閉じたり、あるいは様々なタスクを始めたりすると、時間とともに変化する。
【００３２】
前述のように、１つの実施形態において、コンテクストの登録は宣言のプロセスである。以下でより詳細に説明するように、本発明の１つの態様により、ユーザ・コンテクストを登録することで、ユーザは特定のコンテクストパラメータを承認しない場合に、このコンテクストを採用しない、またはその意味を変更するという選択肢を与えられるように、そのコンテクストのリストがユーザに提示され、る。前述のように、１つの実施形態において、ユーザ・コンテクストは真または偽になり得る条件と、この条件が真の場合に通知に対して適用する処理に関する指示（instruction）で構成される。この点において、ユーザ・コンテクストは特定のプログラミング要素、たとえば、人間可読の文字列（エンド・ユーザが意味を理解する）、このコンテクストが真またはそうでない場合にプログラムがオペレーティング・システムに知らせるための一意の識別子（グローバル一意識別子、すなわちＧＵＩＤ）、通知のスクリーン表示に対してこのコンテクストがどういう意味をもつかを表すステートメント（侵襲性のレベル、音、ボリュームを指定してもよい）を備えることが可能な指示（instruction）、を備えることができる。以下でより詳細に説明するように、コンテクストは動的であってもよい。
【００３３】
図４は、通知ＡＰＩが呼び出された時点でコンテクストが真か偽かを評価するルーチン２３０を示す流れ図である。判断のブロック２３２で、通知ＡＰＩが呼び出された時点でユーザ・コンテクストを評価するかどうかを決定する。ユーザ・コンテクストを評価する場合は、ルーチンがブロック２３４に進む。通知ＡＰＩが呼び出された時点でユーザ・コンテクストを評価しない場合は、このルーチンは終了する。ブロック２３４で、ユーザ・コンテクストが真または偽に評価される。
【００３４】
図３と図４に示し、前述したように、コンテクストは、事前に設定することができ。あるいは、該当するタイミングで評価される機能でもある。例として、プログラムはユーザが音楽を聴いているかどうかをアクティブに確認してもよい。別の例として、通知が評価されると、プログラムがそのコールバックを、通知を評価する時点でコンテクストが真かどうかを本システムからプログラムに問い合わせるように、登録する。この第２のプロセスが特に重要な１つの例は、ユーザ・コンテクストをユーザ規則と組み合わせて動的なコンテクストを構成する場合である。（ユーザ規則については、以下でより詳細に説明する。）ユーザ・コンテクストにユーザ規則を組み合わせた具体的な例は、「私が現在参加している会議のメンバーは、私がビジー状態にあるかどうかにかかわらず、いつでも私に通知を送信できる」という規則をユーザが設定した場合である。この場合は、ユーザが現在参加している会議のメンバーという観点で「ユーザが会議に参加している」というユーザ・コンテクストをさらに評価する必要がある。この例では、会議を処理するプログラムはこれを動的なコンテクストとして登録し、通知を評価するときに、通知を送信した人物がこのコンテクストに対して評価される（それ以外の場合は、会議に参加している人物は時間の経過に伴って変わる可能性があるので、事前に真または偽として宣言することはできない）。換言すると、この特定の例では、ユーザ・コンテクストを他の人物のコンテクストに依存するユーザ規則に照らして評価する必要がある。
【００３５】
図５は、ユーザがコンテクストを調整し、新しいユーザ規則を作成することを可能とするルーチン２４０を示す流れ図である。ブロック２４２で、ユーザがコンテクストの調整を必要としているかどうかを決定する。ユーザがコンテクストの調整を必要としない場合、このルーチンは判断のブロック２４６に進む。これについては以下でより詳細に説明する。ユーザがコンテクストの調整を必要とする場合、このルーチンはブロック２４４に進み、ユーザはコンテクストを変更する。
【００３６】
１つの実施形態では、規定されたコンテクストをユーザに対して表示して、ユーザがコンテクストを無効化したり（コンテクストについてのこのプログラムの評価をユーザが承認しない場合）、通知の配信への影響という観点でコンテクストを変更したりできるようにする。より具体的な例として、ユーザ・コンテクストには「アプリケーションが全スクリーン・モードで動作しているとき」、「私が音楽またはビデオを再生しているとき」、「ミーティング・マネージャ（meeting manager）が会議中に私を表示するとき」、「不在時のオフィス・アシスタント（office assistant）が有効化されたとき」などを含めることができる。これらそれぞれに対して、ユーザは、条件のそれぞれに対応する指示（instruction）を指定でき、指定された条件が真の場合に受信した通知は指定された手順に従って処理されるべきであるという命令を指定する。この指示（instruction）には、通知をスクリーンに表示するかどうか、あるいは表示する方法、通知で使用する音またはボリュームなどを指定できる。ボリュームに関しては、特定の条件で望ましいボリュームのパーセンテージをユーザが指定してもよい。通知のスクリーン表示については、通知を全く表示しない、または指定された外部のディスプレイにのみ通知を表示する、現在のスクリーンに通知を表示するなどのオプションをユーザが規定してもよい。通知の表示に関しては、様々なレベルの侵襲性を指定してもよい。たとえば、ユーザが最大表示のアプリケーションを実行している場合は、コンテクストがやや限定的であり、侵襲性の設定では通知を表示することが可能であるが、その通知の表示はサイドバー内に限定する、といったものでもよい。
【００３７】
図５に戻り、判断のブロック２４６で、ユーザが新しいユーザ規則の作成を希望しているかどうかを決定する。ユーザが新しいユーザ規則の作成を希望していない場合、ルーチンは判断のブロック２５０に進む。これについては以下でより詳細に説明する。ユーザが新しいユーザ規則の作成を希望する場合、このルーチンはブロック２４８に進み、ここで新しい規則が作成される。一般に、ユーザ規則は特定の要素を含む通知を処理する方法を規定している。たとえば、指定された人物からの通知はいつでも直ちに配信するように規則で規定でき、すべての通知に対して、その通知がどのプログラムで発生したかにかかわらず、その通知が指定された人物からのある限り、この規則を適用することができる。より具体的な例として、その他のユーザ規則は「Ｗａｓｈｉｎｇｔｏｎ州ＢｒｅｍｅｒｔｏｎのＭＳＮ自動トラフィックアラート」や「Ｊｏｈｎ  Ｄｏｅからの重要な電子メール」のようなものを対象としてもよい。Ｊｏｈｎ  Ｄｏｅからの重要な電子メールを対象としたユーザ規則の例として、その規則は、「「Ｊｏｈｎ  Ｄｏｅ」から受信した任意の電子メールで、本文に「ｕｒｇｅｎｔ（緊急）」とあり、「重要度：高」のマークがある場合は、そのメールは指定された処理の条件に従うべきであると規定してもよい。処理の条件には、通知を直ちに配信すること、およびユーザはこれを確認する必要があること、を指定してもよい。一般に、ユーザがその通知を確認する必要があるということは、その通知が、ユーザが確認して閉じるまでスクリーンに表示されたままとなるという点で、通知の侵襲性の形に関してやや上のレベルにあることを意味している。１つの実施形態において、ユーザの確認要求は、ユーザ規則を介してのみ設定できる。別の例として、ユーザに対して特定の通知を受信したことを表すアラートを提供するように、通知に対してカスタム・サウンドを、指定されたボリュームで再生することを規定することもできる。また、ユーザが「標準」の状態にある場合と「ビジー」状態にある場合に、通知をどのように処理すべきかについては、様々な設定を選択でき、それらはユーザ・コンテクストで決定できる。処理に関する指示（instruction）には、「Ｊｏｈｎ  Ｄｏｅからの通知を私のポケット・ベルに配信する」などの、通知のルーティング・オプションのようなもの（）を含むことができる。１つの実施形態では、コンテクストを評価するときに、現在真であるコンテクストの中で最も限定的なものが適用されるコンテクストである。ユーザ規則が評価される際、ユーザが作成した規則に特定の通知が一致したことを意味している場合、この場合は、通知に一致した複数のユーザ規則の中で最も侵襲性の高い設定が適用される。換言すると、複数のユーザ規則において、ユーザは、重要事項を指定しており、この手続きはユーザの選好に合わせることを目的としている。２つの規則の間に不一致（conflict）がある場合は、侵襲性の高いものを適用する。
【００３８】
１つの実施形態において、さらにユーザ規則は特定の通知サービスからの通知の配信を制御することを目的とする。たとえば、通知サービスに従って通知を提供するオペレーティング・システムは、ユーザに、が通知の配信方法を変更する方法を規定することができる。たとえば、指定された通知サービスが「Ｓｅａｔｔｌｅに関するトラフィックアラート」を提供すると、ユーザはこのような通知を受信した場合に、システムは「通知を表示し、音を再生する」ように配信を編集することができる。
【００３９】
図５に戻り、判断のブロック２５０で、ユーザが既存のユーザ規則の調整を希望するかどうかを決定する。いずれの規則も調整する必要がない場合、このルーチンは終了する。ユーザがユーザ規則の調整を希望する場合、このルーチンはブロック２５２に進み、ユーザはここで規則を変更する。
【００４０】
図３〜図５に関連して前述したように、ユーザ・コンテクストとユーザ規則はオペレーティング・システム、プログラム、ユーザによって設定される。本システムは、ユーザの選好に合わせて通知の配信を適切に仲介し、順序付けする。ユーザ・コンテクストとユーザ規則とをユーザに対して表示し、様々なコンテクストや規則をユーザが変更または調整したり、新しい規則を作成したりできるようにする。これは、ユーザに、通知の処理方法に関する選好を集中的に管理する方法を提供する。これは、ユーザに通知を配信しようとするコンピューティング・システム内の多くの競合するエレメントを、ユーザが効果的に管理することを可能にすることを認識されたい。
【００４１】
図６は、ユーザ・コンテクストとユーザ規則に従って通知を処理するルーチン３００を示す流れ図である。ブロック３０２で、オペレーティング・システムまたは任意のプログラムが通知ＡＰＩを呼び出す。判断のブロック３０４で、通知に関するログを通知履歴に記録するかどうかを決定する。通知ログを記録する場合、このルーチンはブロック３０６に進み、通知ログを履歴に記録する。通知ログを記録しない場合、このルーチンは判断のブロック３１０に進む。
【００４２】
判断のブロック３１０で、通知が一致するユーザ規則があるかどうかを決定する。通知が一致するユーザ規則がある場合、このルーチンはブロック３１２に進み、ユーザ規則が適用される（通知の内容とユーザ・コンテクストに基づいて）。このルーチンは図７に続くポイントＡに進む。判断のブロック３１０で、通知がいずれのユーザ規則にも一致しない場合、このルーチンは判断のブロック３２０に進む。
【００４３】
１つの実施形態において、ユーザ規則は常に現在のユーザ・コンテクストより重要である。前述のように、ユーザ規則は通知の任意の要素に基づくことができる。たとえば、通知を作成した人物の評価に基づく規則は、すべての通知に対して、その通知がどのプログラムで発生したかにかかわらず、この規則が基づく人物からの通知である限り、適用できる（たとえば、「Ｊｏｈｎ  Ｄｏｅ」はいつでも私に届く）。さらに、それ以外の場合には表示しないようにするコンテクストの期間であっても、その場合にはスクリーンに通知を表示できる（たとえば、ユーザは会議中に通知を受信しないことをユーザ・コンテクストで一般的に表明している場合でも、「私と同じ会議に参加している人は、いつでも私に通知を送信できる」）。
【００４４】
図６に戻り、判断のブロック３２０で、現時点で通知を表示できるかどうかを決定する（ユーザ・コンテクストのみに基づいて）。現時点で通知を表示できる場合、このルーチンはブロック３２２に進み、通知が表示され、適切な音が適切なボリュームで再生される。現時点で通知を表示するのが適切ではない場合、このルーチンは判断のブロック３３０に進む。
【００４５】
判断のブロック３３０で、通知の有効期限が切れているかどうかを決定する。通知の有効期限が切れている場合、このルーチンはブロック３３２に進み、通知が破棄される。通知の有効期限が切れていない場合、このルーチンはブロック３３４に進み、通知が保留になる。さらにルーチンは図７に続くポイントＢに進む。
【００４６】
図７は、指定したユーザ規則に従って通知を処理するルーチン３５０を示す流れ図である。前述のように、このルーチンは図６のポイントＡから続く。図７に示すように、判断のブロック３５２で、通知をルーティング（route）するかどうかを決定する。通知をルーティングしない場合は、以下でより詳細に説明するように、このルーチンは判断のブロック３６２に進む。通知をルーティングする場合は、このルーチンはブロック３５４に進み、通知が指定どおりにルーティングされる。通知をルーティングする場合は、通知を別のシステムに渡すことを要求するユーザ規則に一致する要素が通知に含まれることを示している。これは、ユーザがビジー状態にある場合に実行してもよいし、ユーザが対応できるかどうかにかかわらず、ユーザ規則に指定された基準に一致するあらゆる通知に対して実行してもよい。例として、「ｕｒｇｅｎｔ（緊急）」ということばを含む通知はいつでもユーザのポケット・ベルに転送され、一方、他の通知はユーザ規則とユーザ・コンテクストの組合せのみに基づいてルーティングされてもよい。
【００４７】
ルーティング指示（instruction）の例には、「この通知を電子メール・アドレスに転送する」、「この通知を別のＰＣに転送する」、「この通知をポケット・ベルに転送する」、「この通知を携帯電話に転送する」、「この通知を電子メール・サーバーに転送する」などがある。以下でより詳細に説明するように、通知をルーティングする場合は、同時に通知を配信してスクリーンに表示してもよい。さらに、通知の転送先のデバイスはこれと同じコンテクスト・システムを使用してもよい。このデバイス上ではユーザ・コンテクストに関する追加の認識または別の認識があってもよい。さらに、このデバイス上のコンテクスト・システムでは通知に関する様々な処置を選択してもよい。
【００４８】
図７に戻り、判断のブロック３６２で、通知を拒否するかどうかを決定する。通知を拒否しない場合、このルーチンは判断のブロック３６６に進む。これについては、以下でより詳細に説明する。通知を拒否する場合、このルーチンはブロック３６４に進み、通知は破棄されてユーザには認識されない。つまり、拒否された通知は表示もされず、騒音も出さない。このことは、たとえば、特定の通知を拒否するように規定するユーザ規則に基づいて発生し、または図６のブロック３３２に関連して前述したように、有効期限が切れた場合に、発生する。
【００４９】
図７に戻り、判断のブロック３６６で、通知を保留にするかどうかを決定する。通知を保留にしない場合、このルーチンは判断のブロック３７０に進む。これについては、以下でより詳細に説明する。通知を保留にする場合、このルーチンはブロック３６８に進み、ユーザ・コンテクストが変わるまで通知が保留になる。その後、このルーチンは図８に続くポイントＢに進む。一般に、通知を保留にする場合は、通知が配信を許可されるが、現在のユーザ・コンテクストまたはユーザ規則により、この時点で通知を配信するのは適切ではないと考えられることを示している。図８に関連して以下でより詳細に説明するように、ユーザ・コンテクストが変わるか、あるいはその後適切であると規定している場合は、ユーザ規則とユーザ・コンテクストによって指示されるように、通知がユーザのスクリーンに配信され、表示および／または音を出すことが許可される。
【００５０】
図７に戻り、判断のブロック３７０で、通知を配信すべきかどうかを決定する。通知を配信すべきでない場合、このルーチンは終了する。通知を配信すべき場合、このルーチンはブロック３７２に進み、通知は適切な侵襲性のレベルで表示され、適切な音が適切なボリュームで再生される。換言すると、通知の配信は許可されるが、その通知はユーザ・コンテクストとユーザ規則に従って配信される（たとえば、通知の表示は許可されるが無音でなければならない）。
【００５１】
図８は、通知の配信を保留にするルーチン３８０を示す流れ図である。前述のように、このルーチンは、図６または図７のポイントＢから続く。図８に示すように、ブロック３８２で通知が保持される。ブロック３８４で、本システムは、宣言したコンテクストの真または偽の状態に変化がないか、またはユーザ規則が、ここで通知を配信するのが適切であると指示しているかを監視する。判断のブロック３８６で、ユーザ・コンテクストが変化したかどうか、またはユーザ規則がここで通知を配信するのが適切であることを指示しているかを決定する。ユーザ・コンテクストが変化しておらず、ユーザ規則がそれ以外のことを指示している場合、このルーチンは、ブロック３８２に戻り、通知は引き続き保持される。ユーザ・コンテクストが変化した場合、またはユーザ規則がここで通知を配信するのが適切であると指示する場合は、このルーチンは、図６に続くポイントＣに進む。図６に示すポイントＣから判断のブロック３０４に戻り、ここで通知を評価するプロセスが再開される。
【００５２】
図９は、様々な制限に従って通知の表示方法を決定するルーチン４００を示す流れ図である。このルーチンは、図６のブロック３２２または図７のブロック３７２のように、通知処理の一環として実装できるのは言うまでもない。一般に、本システムに通知が到着すると、現在真であるすべてのコンテクストについて評価され、ユーザの現在の状態に従って、通知に関する多くの制限の設定が適用される。図９に示すように、判断のブロック４０２で、通知の表示を完全に禁止するかどうかを決定する。通知の表示を完全に禁止する場合、このルーチンはブロック４０４に進み、通知はどのディスプレイにも表示しないように設定される。通知を表示する場合、このルーチンは判断のブロック４０６に進む。
【００５３】
判断のブロック４０６で、通知を外部にのみ表示するかどうかを決定する。通知を外部にのみ表示する場合、このルーチンはブロック４０８に進み、通知を外部のハードウェア・ディスプレイにのみ表示する。通知を外部のハードウェア・ディスプレイに表示しない場合、このルーチンは判断のブロック４１０に進む。
【００５４】
判断のブロック４１０で、通知を現在のディスプレイに表示するかどうかを決定する。通知を現在のディスプレイに表示する場合、このルーチンはブロック４１２に進み、通知が適切な侵襲性のレベルに従って現在のディスプレイに表示される。通知を現在のディスプレイに表示しない場合、このルーチンは終了する。
【００５５】
図１０は、様々な制限に従って、通知のための音を再生するボリュームを決定するルーチン４２０を示す流れ図である。図９に関連して前述したように、このルーチンは、図６のブロック３２２または図７のブロック３７２のように、通知処理の一環として実装できるのは言うまでもない。本システムに通知が到着すると、現在真であるすべてのコンテクストが評価され、ユーザの現在の状態に従って、通知に関する多くの制限の設定が適用される。図１０に示すように、判断のブロック４２２で、通知を、ミューティングする（無音にする）かどうかを決定する。通知をミューティングする場合、このルーチンはブロック４２４に進み、通知は無音で提供される。通知を無音にしない場合、このルーチンは判断のブロック４２６に進む。
【００５６】
判断のブロック４２６で、最大のボリュームより小さい指定されパーセンテージのボリュームで通知を行うかどうかを決定する。ボリュームの特定のパーセンテージが指定された場合、このルーチンはブロック４２８に進み、通知のための音が指定されたパーセンテージのボリュームで再生される。ボリュームの特定のパーセンテージが指定されない場合は、このルーチンは判断のブロック４３０に進む。
【００５７】
判断のブロック４３０で、通知のための音を最大のボリュームで再生するかどうかを決定する。最大のボリュームが指定された場合、このルーチンはブロック４３２に進み、通知のための音が最大のボリューム・レベルで再生される。最大のボリュームで再生しない場合は、このルーチンは終了する。１つの実施形態において、通知のための音を様々なボリューム・レベルで再生するだけでなく、ユーザ・コンテクストとユーザ規則に従って、通知のための音の種類を選択することもできる。
【００５８】
以上、図１〜図１０に関連付けながら説明したように、本システムはスクリーン表示を適切に仲介し、順序付して、通知が相互に競合するのを防止するように、本発明は、様々なソースからの通知の配信を制御することを認識されたい。さらに、本発明が提供する通知は、ユーザがより受け入れやすいタイミングで配信されるだけでなく、共通の規則の使用がユーザに不都合な通知を排除することを支援するので、より価値が高いと考えることができる。
【００５９】
本発明の好ましい実施形態について図示し、説明してきたが、本発明の精神と範囲を逸脱せずに、様々な変更が可能なことは認識されたい。
【図面の簡単な説明】
【００６０】
【図１】本発明を実装するのに適した汎用コンピュータ・システムを示すブロック図である。
【図２】本発明による、通知を処理する一般的なルーチンを示す流れ図である。
【図３】オペレーティング・システムまたはユーザ・コンテクストを宣言する任意のプログラムのルーチンを示す流れ図である。
【図４】通知ＡＰＩが呼び出されたときに、ユーザ・コンテクストが真か偽かを評価するルーチンを示す流れ図である。
【図５】ユーザ・コンテクストを調整し、新しいユーザ規則を作成するルーチンを示す流れ図である。
【図６】ユーザ・コンテクストとユーザ規則に従って通知を処理するルーチンを示す流れ図である。
【図７】通知のコンテントとユーザ・コンテクストに基づいてユーザ規則を実装するルーチンを示す流れ図である。
【図８】通知の配信を保留にするルーチンを示す流れ図である。
【図９】様々な限定的設定に従って通知を表示する方法を決定するルーチンを示す流れ図である。
【図１０】様々な限定的設定に従って通知のボリューム・レベルを決定するルーチンを示す流れ図である。
【図１】
2006521595.tif 000003
【図２】
2006521595.tif 000004
【図３】
2006521595.tif 000005
【図４】
2006521595.tif 000006
【図５】
2006521595.tif 000007
【図６】
2006521595.tif 000008
【図７】
2006521595.tif 000009
【図８】
2006521595.tif 000010
【図９】
2006521595.tif 000011
【図１０】
2006521595.tif 000012
【国際調査報告】
2006521595.tif 000013