(57)【要約】【課題】  テスト通知を利用するシステムおよび方法を提供する。【解決手段】  アプリケーションは、ユーザコンテキストシステムに送信されるテスト通知を構築することができ、ユーザの現在のコンテキストに従ってその通知が現時点では画面にドローされるか、されないかの指示を受け取る。別の実施形態では、呼び出しアプリケーションは、通知が延期または転送されるか否か、通知を再生する場合のサウンドレベルについての詳細などのよりリッチな指示を受け取る。ポーリングを実行することにより、アプリケーションは、周期的にテスト通知を再送信しシステムを再ポーリングして変化が生じているか否かを判定することができる。サブスクリプションを実行する場合、アプリケーションは、システムをサブスクライブして、変化があった時に提供される更新を受け取ることができる。【選択図】  図１
2004295899.tif 000002
【特許請求の範囲】
【請求項１】
ユーザに通知を配信するコンピュータシステムにおいて、テスト通知を利用する方法であって、
テスト通知を受け取るステップと、
前記テスト通知を評価するが、前記テスト通知をユーザに配信しないステップと、
前記テスト通知の評価の結果についての指示を戻すステップと、
を含むことを特徴とする方法。
【請求項２】
前記テスト通知は、実際の通知をシミュレートし、前記評価の結果は、前記実際の通知が前記ユーザに配信されるか否かを指示する、ことを特徴とする請求項１に記載の方法。
【請求項３】
前記テスト通知の評価は、ユーザコンテキストに従って行われる、ことを特徴とする請求項１に記載の方法。
【請求項４】
前記ユーザコンテキストは、真または偽とすることが可能な条件と、前記条件が真である場合に従うべき命令とを含む、ことを特徴とする請求項３に記載の方法。
【請求項５】
前記ユーザコンテキストの条件は、通知を受け取ることについての前記ユーザの連絡可能性に関連することが意図され、前記命令は、前記ユーザに通知を配信すべきか否かに関連する、ことを特徴とする請求項４に記載の方法。
【請求項６】
前記テスト通知の評価は、指定された特定の内容を含む通知の対処法を指示するユーザ規則に従って行われる、ことを特徴とする請求項１に記載の方法。
【請求項７】
追加的なテスト通知を利用して前記システムを再ポールするようにポーリング法を実行し、指定された変更がいつ生じたかを判定する、ことを特徴とする請求項１に記載の方法。
【請求項８】
サブスクリプション法が実行され、前記システムは、変化が生じた時にその指示を自動的に提供する、ことを特徴とする請求項１に記載の方法。
【請求項９】
前記テスト通知の評価の結果についての前記指示は、配信の指示を含む、ことを特徴とする請求項１に記載の方法。
【請求項１０】
前記配信の指示は真または偽である、ことを特徴とする請求項９に記載の方法。
【請求項１１】
前記指示はさらに、転送または延期の指示の１つを含む、ことを特徴とする請求項９に記載の方法。
【請求項１２】
前記指示はさらに、侵入度の指示を含むことを特徴とする請求項９に記載の方法。
【請求項１３】
前記指示はさらに、音量の指示を含むことを特徴とする請求項９に記載の方法。
【請求項１４】
テスト通知を利用する方法を実行するためのコンピュータ実行可能コンポーネントを有するコンピュータ可読媒体であって、
テスト通知を受け取るステップと、
前記テスト通知を評価するが、前記テスト通知をユーザに配信しないステップと、
前記テスト通知の評価の結果についての指示を戻すステップと、
を含むことを特徴とするコンピュータ可読媒体。
【請求項１５】
前記テスト通知は、実際の通知をシミュレートし、前記評価の結果は、前記実際の通知が前記ユーザに配信されるか否かを指示する、ことを特徴とする請求項１４に記載のコンピュータ可読媒体。
【請求項１６】
前記テスト通知の評価は、条件と、前記条件の状態に応じて従うべき命令とを含むユーザコンテキストに従って、行われる、ことを特徴とする請求項１４に記載のコンピュータ可読媒体。
【請求項１７】
前記条件は真または偽であり、前記命令は前記条件が真である場合に従われる、ことを特徴とする請求項１６に記載のコンピュータ可読媒体。
【請求項１８】
前記ユーザコンテキストの条件は、通知を受け取ることについての前記ユーザの連絡可能性に関連することが意図され、前記命令は、前記ユーザに通知を配信すべきか否かに関連する、ことを特徴とする請求項１７に記載のコンピュータ可読媒体。
【請求項１９】
前記テスト通知の評価は、指定された特定の要素を含む通知の対処法を指示するユーザ規則に従って行われる、ことを特徴とする請求項１４に記載のコンピュータ可読媒体。
【請求項２０】
追加的なテスト通知を利用して前記システムを再ポルするようにポーリング法を実行し、指定された変更がいつ生じたかを判定する、ことを特徴とする請求項１４に記載のコンピュータ可読媒体。
【請求項２１】
サブスクリプション法が実行され、前記システムは、変化が生じた時にその指示を自動的に提供する、ことを特徴とする請求項１４に記載のコンピュータ可読媒体。
【請求項２２】
前記テスト通知の評価の結果についての前記指示は、配信の指示、転送の指示、または延期の指示の少なくとも１つを含む、ことを特徴とする請求項１４に記載のコンピュータ可読媒体。
【請求項２３】
ユーザに通知を配信するコンピュータシステムにおいて、テスト通知を利用する方法であって、
実際の通知をシミュレートしたテスト通知を受け取るステップと、
前記テスト通知を評価し、前記実際の通知が配信されるか否かについての指示を提供するステップと、
を含むことを特徴とする方法。
【請求項２４】
前記テスト通知は呼び出しアプリケーションから受け取られ、前記実際の通知が配信されるか否かについての前記指示は、前記呼び出しアプリケーションに戻される、ことを特徴とする請求項２３に記載の方法。
【請求項２５】
前記テスト通知の評価は、ユーザコンテキストに従って行われる、ことを特徴とする請求項２３に記載の方法。
【請求項２６】
前記ユーザコンテキストは、真または偽である条件と、前記条件が真である場合に従うべき命令とを含む、ことを特徴とする請求項２５に記載の方法。
【請求項２７】
前記ユーザコンテキストの条件は、通知を受け取ることについての前記ユーザの連絡可能性に関連することが意図され、前記命令は、前記ユーザに通知を配信すべきか否かに関連する、ことを特徴とする請求項２６に記載の方法。
【請求項２８】
前記テスト通知の評価は、指定された特定の内容を含む通知の対処法を指示するユーザ規則に従って行われる、ことを特徴とする請求項２３に記載の方法。
【請求項２９】
追加的なテスト通知を利用して前記システムを再ポールするようにポーリング法を実行し、指定された変更がいつ生じたかを判定する、ことを特徴とする請求項２３に記載の方法。
【請求項３０】
サブスクリプション法が実行され、前記システムは、変化が生じた時にその指示を自動的に提供する、ことを特徴とする請求項２３に記載の方法。
【請求項３１】
前記実際の通知が配信されるか否かについての前記指示はさらに、前記実際の通知の対処法についての追加的な指示を含む、ことを特徴とする請求項２３に記載の方法。
【請求項３２】
テスト通知を利用する方法を実行するためのコンピュータ実行可能コンポーネントを有するコンピュータ可読媒体であって、該方法は、
実際の通知をシミュレートしたテスト通知を受け取るステップと、
前記テスト通知を評価し、前記実際の通知が配信されるか否かについての指示を提供するステップと、
を含むことを特徴とするコンピュータ可読媒体。
【請求項３３】
前記テスト通知は呼び出しアプリケーションから受け取られ、前記実際の通知が配信されるか否かについての前記指示は、前記呼び出しアプリケーションに戻される、ことを特徴とする請求項３２に記載のコンピュータ可読媒体。
【請求項３４】
前記テスト通知の評価は、ユーザコンテキストに従って行われる、ことを特徴とする請求項３３に記載のコンピュータ可読媒体。
【請求項３５】
前記ユーザコンテキストは、真または偽とする条件と、前記条件が真である場合に従うべき命令とを含む、ことを特徴とする請求項３４に記載のコンピュータ可読媒体。
【請求項３６】
前記ユーザコンテキストの条件は、通知を受け取ることについての前記ユーザの連絡可能性に関連することが意図され、前記命令は、前記ユーザに通知を配信すべきか否かに関連する、ことを特徴とする請求項３５に記載のコンピュータ可読媒体。
【請求項３７】
前記テスト通知の評価は、指定された特定の内容を含む通知の対処法を指示するユーザ規則に従って行われる、ことを特徴とする請求項３３に記載のコンピュータ可読媒体。
【請求項３８】
追加的なテスト通知を利用して前記システムを再ポールするようにポーリング法を実行し、指定された変更がいつ生じたかを判定する、ことを特徴とする請求項３３に記載のコンピュータ可読媒体。
【請求項３９】
サブスクリプション法が実行され、前記システムは、変化が生じた時にその指示を自動的に提供する、ことを特徴とする請求項３３に記載のコンピュータ可読媒体。
【請求項４０】
前記実際の通知が配信されるか否かについての前記指示はさらに、前記実際の通知の対処法についての追加的な指示を含む、ことを特徴とする請求項３３に記載のコンピュータ可読媒体。
【請求項４１】
テスト通知を利用するシステムであって、
テスト通知を受け取る手段と、
前記テスト通知を評価するが、前記テスト通知をユーザに配信しない手段と、
前記テスト通知の評価の結果についての指示を戻す手段と、
を含むことを特徴とするシステム。
【請求項４２】
ユーザコンテキストに従って、前記テスト通知を評価する手段をさらに含む、ことを特徴とする請求項４１に記載のシステム。
【請求項４３】
ユーザ規則に従って、前記テスト通知を評価する手段をさらに含む、ことを特徴とする請求項４１に記載のシステム。
【請求項４４】
ポーリング法を実行する手段をさらに備え、追加的なテスト通知を利用することによりシステムを再ポールして、指定された変化がいつ生じたかを判定する、ことを特徴とする請求項４１に記載のシステム。
【請求項４５】
サブスクリプション法を実行する手段をさらに備え、前記システムは、変化が生じるとその指示を自動的に提供する、ことを特徴とする請求項４１に記載のシステム。
【請求項４６】
テスト通知を利用するシステムであって、
実際の通知をシミュレートしたテスト通知を受け取る手段と、
前記テスト通知を評価し、前記実際の通知が配信されるか否かについての指示を提供する手段と、
を含むことを特徴とするシステム。
【請求項４７】
ユーザコンテキストに従って、前記テスト通知を評価する手段をさらに含む、ことを特徴とする請求項４６に記載のシステム。
【請求項４８】
ユーザ規則に従って、前記テスト通知を評価する手段をさらに含む、ことを特徴とする請求項４６に記載のシステム。
【請求項４９】
ポーリング法を実行する手段をさらに備え、追加的なテスト通知を利用することによりシステムを再ポールして、指定された変化がいつ生じたかを判定する、ことを特徴とする請求項４６に記載のシステム。
【請求項５０】
サブスクリプション法を実行する手段をさらに備え、前記システムは、変化が生じるとその指示を自動的に提供する、ことを特徴とする請求項４６に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピューティングシステムにおける通知(notification)に関し、より詳細には、テスト通知(test notification)を利用するシステムおよび方法に関する。
【背景技術】
【０００２】
コンピュータシステムでは、通知は、指定されたイベント(event)が発生したことをユーザに知らせるプログラムからの信号の形態をとることができる。そのような通知は、各種のテキスト、サウンド、およびグラフィックの要素を含むことができる。通知と共に、優先度(priority)、通知の送信者（電子メールまたはインスタントメッセージなどのチャネルの場合）、および通知の有効期限などの他のプロパティ(property)も含まれる可能性がある。通知は、何らかのコードの要素も含むことができ、ユーザは通知と対話し、任意のコードを起動(launch)することができる（例えば通知内のボタンまたはテキストをクリックすることにより新しいプログラムを起動させる、あるいは現在実行中のプログラムでアクションを行わせることができるなど）。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
オペレーティングシステムは、ユーザにネットワークの接続性と更新について知らせる通知(notification)を作成することができる。「連絡先リスト(contact list)」を使用するインスタントメッセージングプログラム(instant messaging program)は、画面上に通知をドロー(draw)して、連絡先リストの現在の状況、あるいは連絡先がいつインスタントメッセージの会話を開始したかをユーザに知らせることができる。他のプログラムは、ディスプレイの同様の領域にドローされる同様の通知を提供することができる。この種の通知に伴う問題の１つは、このような通知は一般に他の通知を認識せず、そのため他の通知の上に通知がドローされる場合があることである。
【０００４】
既存の通知システムに伴う別の問題は、不適切な形で、あるいは不適切な時に通知を配信(deliver)する場合があることである。例えば、フルスクリーンの画面表示(presentation)を提供しているユーザにとって、その画面表示中に他のプログラムが画面に通知をドローするのは不適切である可能性がある。そのような不適切な通知をドローする可能性があるプログラムの一例はインスタントメッセージングプログラムであり、このプログラムは、オペレーティングシステムのバックグラウンドで実行され、連絡先リスト(contact list)中の連絡先がサインオンするか、またはインスタントメッセージ(instant message)を開始するとそのような通知をドローする。画面表示中のこの種の「割り込み(interruption)」は、ユーザにとって望ましくない可能性がある。
【０００５】
本発明は、前述およびその他の不都合点を克服するシステムおよび方法を提供することを目的とする。より詳細には、本発明は、テスト通知を利用するシステムおよび方法を提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明は、テスト通知を利用するシステムおよび方法を提供する。本発明の一態様によれば、呼び出しプログラム(calling program)は、実際の通知(actual notification)に似たテスト通知(test notification)を構築する。実際の通知との大きな違いは、テスト通知は実際にはユーザに配信(deliver)されないことである。
【０００７】
本発明の別の態様によれば、テスト通知は、真または偽の指示(indication of true or false)を戻す(return)。真の指示(indication of true)は、実際の通知が現在ドローされていたはずであることを意味し、偽の指示(indication of false)は、実際の通知が現在ドローできなかったはずであることを意味する。別の実施形態では、テスト通知(test notification)によって、よりリッチな戻り値(richer return value)を戻す(return)ことができる。よりリッチな戻り値の例としては、通知(notification)が延期(defer)または経路指定(route)されたはずであったかどうか、通知が再生(play)されるときのサウンドレベル(sound level)などが含まれる。
【０００８】
本発明の別の態様によれば、ポーリング法(polling method)が利用される。この形態において、呼び出しプログラムは周期的に再ポーリング(re-poll)（テスト通知を送信）することにより、ユーザの現在のコンテキスト(context)、および、呼び出しプログラム(calling program)によって送信される同報通信データ(broadcast data)をどのように変更すべきか、を判定(determine)する。同報通信データの一例は、インスタントメッセージングプログラムがビジーな状態またはフリーな状態を連絡先に同報通信するものである。別の形態では、サブスクリプションコールバック(subscription callback)の方法が利用される。この形態では、呼び出しプログラムは、コンテキスト変化(context change)の受け取りをサブスクライブ(subscribe)する。すなわち、ユーザのコンテキストは同報通信される情報のタイプに関連する形で変化するので、コンテキストエンジン(context engene)は、周期的に再ポーリングするのではなく、それらの更新(update)と共に呼び出しプログラムにコールバックする。この後者の形態には、コンテキストの変化と同報通信される内容に時間差がないという利点がある。他の事例では、１回限りのイベント(one-time event)などの場合にポーリング法がより適する場合がある。
【０００９】
本発明のこのテストシステムおよび方法により、ユーザにいつ通知(notificatin)を送信(send)するのが適切であるかをオペレーティングシステムおよび任意のプログラムが判定できることが理解されよう。テスト通知を利用する利点の１つは、プログラムがユーザコンテキスト(user's context)のよりリッチなビュー(richer view)を得られるようにすることにより、ユーザが通知を受け取れる状態になるまで不要な実際の通知(unwanted actual notification)の生成を防止できることである。また、テスト通知を利用することによりユーザコンテキストについての情報を得られるので、通知の配信(delivery of notification)に同じユーザインターフェースを利用しないプログラムに対してより高い柔軟性が与えられる。一例として、将来開発されるプログラムは、現在のユーザコンテキストシステム(user context system)ではサポートされない特殊化されたグラフィックを用いた通知を開発する可能性があるが、そのような将来のプログラムもテスト通知から得られる情報を利用して、現在の通知を送信または変更することが適切であるかどうかを判断することができる。
【００１０】
本発明の別の態様によれば、テスト通知はユーザコンテキストシステム中で利用される。ユーザコンテキストシステムは、複数ソースからの通知の配信(delivery of notification)を仲介(broker)し、順番(serialize)にする。また、各通知に適した対処法を判断するために、共有(share)されるユーザコンテキストの概念が提供される。これらの態様によれば、ユーザコンテキストシステムによって配信される通知は、ユーザがよりそれらを受け取れる状態にある時に送信されるのでより価値が高いと考えることができる。これらの態様は、ユーザが不要な通知が生成されないようにするのを助ける共通の規則も提供する。一形態では、ユーザコンテキストシステムにおけるテスト通知の使用は、基本的に、集約されたユーザコンテキスト(user's aggregated context)をカプセル化し、それを任意のプロセスに公開する機能を持つシステムツールまたはシステムによって提供される機構を提供する。
【００１１】
本発明の別の態様によれば、ユーザコンテキストシステムでは、コンテキストはオペレーティングシステムおよび任意のプログラムによって宣言(declare)される。一形態では、ユーザコンテキストは、真(true)または偽(false)とすることができる条件(condition)と、その条件が真である場合に従うべき命令(instruction)とからなる。例えば、条件は「ユーザが音楽を聴いている時」であり、それについての命令は「通知は画面に配信するが、サウンドは生成しない」等である。一般に、ユーザコンテキストの条件は、通信を配信するのにユーザを何らかの形で連絡不可能にするとシステムがみなす状態、または通知が配信される方式を、その通知をスタートしたプログラムによって送信された方式とは異なるものにする状態と考えることができる。ユーザは「連絡不可能(unavailable)」とみなされる(deemed)状態にある可能性があり、その場合通知は配信されないか、またはユーザが「連絡可能(available)」になるまで保留(hold)にされる。例えばユーザがフルスクリーンアプリケーション(full screen application)を実行中で、そのアプリケーションが表示画面の全領域を使用しているか、全領域に表示されている場合、そのユーザは連絡不可能とみなされる場合がある。あるいは、ユーザは「連絡可能」であるが、ユーザに適した形に通知を変更する必要があるような状態にある場合もある。
【００１２】
本発明の別の態様によれば、ユーザコンテキストシステム(user context system)では、オペレーティングシステムがコンテキストを宣言(declare)するのに加えて、プログラムが、そのプログラムが提供するコンテキストとコンテキストの通知に対するその影響（画面へのドローが適切かどうか、画面へのドローに適した侵入度(invasiveness)のレベル、サウンドが適切な否か、あるいはサウンド再生の際の相対的な音量などに関して）をシステムに登録し、宣言し、そしてそのコンテキストが真であるか偽であるかをシステムに知らせる。一形態では、コンテキストは、通知を配信しようとする時に真か偽かを評価(evaluate)されることもできる。一形態では、システムは呼び出しプログラムのプロセス(process of the calling program)を追跡(track)することもでき、プロセスがもはや存在しない場合はコンテキストが偽(false)にリセットされることができる。プロセスを追跡することにより望ましくない状況(undesirable situation)が回避(avoid)されることができ、例えば、アプリケーションがユーザがビジーであると宣言し、その後クラッシュ(crash)し、通知の受け取りができないと宣言された状態にユーザを置いたままにするといった状況が回避される。
【００１３】
本発明の別の態様によれば、ユーザコンテキストシステムでは、通知のドローイング(drawing of notification)について指定された異なるレベルの侵入度(invasiveness)があってよい。すなわち、ユーザコンテキストに基づいて、通知をドローするための段階があってよく、ドローされる通知の形態に様々なレベルの侵入度があってよい。例えば、通常の通知(normal notification)では自由にクライアント領域(client area)中にドローされ、一時的にウィンドウを覆い隠してよい。ユーザがわずかに制限的なコンテキスト(a slightly restrictive context)にある場合は、通知は自由に表示(free to show)してよいが、別のウィンドウの上にドローすることは許されないなど、侵入度がより低い形でのみ表示される。別の例として、ユーザが最大化されたアプリケーション(maximized application)を実行中の場合は、ユーザが現在のアプリケーションにクライアント領域全体を使用したいと明確に指示していることから、ユーザコンテキストがわずかに制限されているという設定になることが考えられる。この状況では、通知のドローはなお許可されるが、サイドバー(sidebar)にのみ表示させることができる。この種の通知ドロー形態の侵入性の低下(reduced invasiveness in the notification drawing form)は、通知の影響(impact of the notification)を小さくし、認識上の負荷(cognitive load)を小さくする。
【００１４】
本発明の別の態様によれば、ユーザコンテキストシステムでは、提供されたコンテキストはユーザに公開されることができ、オフにされることができる（例えばユーザがプログラムによるコンテキストの査定に同意しない場合など）か、または配信の影響の大きさの点から変更されることができる。
【００１５】
本発明の別の態様によれば、ユーザコンテキストシステムでは、ユーザは、指定された要素を含む通知をどのように配信すべきかを指示する規則を定義することができる。例えば、ユーザ規則(user rule)は、「Ｊｏｈｎ  Ｄｏｅ」から受信した通知で、件名に「緊急(urgent)」とある通知は直ちに配信することを指示することができる。一形態では、そのようなユーザ規則は、ユーザコンテキストに優先される。ユーザ規則は、ユーザがそのユーザの嗜好に応じて修正(modification)することができる。
【００１６】
前述の本発明の態様およびそれに伴う利点の多くは、添付の図面と併せて以下の詳細な説明を参照することによりそれらをより深く理解されるとより容易に理解されよう。
【発明を実施するための最良の形態】
【００１７】
本発明は、テスト通知を利用するシステムおよび方法を対象とする。一実施形態では、テスト通知は、ユーザコンテキストシステムによって処理されることができる。ユーザコンテキストシステムは、通知の配信を制御する。
【００１８】
従来のシステムでは、通常は、ユーザへの通知の送信を求める多数の競合する要素があり、それぞれの要素がそのような通知を送信する各自の方式を設計していた。一般には、競合する要素は他の通知を認識せず、そのため互いの通知および互いのアプリケーションの上にドローする傾向があり、その結果、各要素が各自の通知の指示を同時にレンダリングすることを選択した時に衝突が生じる場合があった。また、共有されるユーザコンテキストの概念がなく、その結果一部の通知が不適切な形で、あるいは不適切な時に配信されていた。このユーザコンテキストシステムは、オペレーティングシステムのリッチな一部分として通知を構築することによりこれらの問題に対処し、システムがそれらの画面上でのレンダリングを適切に仲介し、順番にするので、ユーザコンテキストシステムによって提供される通知のユーザインターフェースが似たものになり、そのためインターフェース同士の衝突がなくなる。また、ユーザコンテキストシステムによって提供される通知は、ユーザが通知をより受け付けられる状況にある時に配信されるのでより価値が高くなると考えることができ、さらに、共通の規則を使用することによりユーザが不要な通知を解消するのを助ける。
【００１９】
上述のように、ユーザコンテキストシステムを利用して本発明のテスト通知を処理することができる。本発明のテスト通知は、現在の状況下で実際の通知が配信されるかどうかを判定するために使用される。すなわち、テスト通知は、ユーザが現在通知を受け取れる状態にあるかどうかの指示を提供するものである。この指示は、例えば、プログラムが現時点で実際の通知を送信しようとするのを妨げるか、あるいはプログラムに通知を部分的に変更させるために使用されることができる。
【００２０】
図１および以下の説明は、本発明を実施することが可能な適切なコンピューティング環境の簡単で概略的な説明を提供するものである。これは必須ではないが、本発明は、パーソナルコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的なコンテキストで説明される。一般に、プログラムモジュールには、特定のタスクを行うか、特定の抽象データ型を実装するルーチン、プログラム、文字、コンポーネント、データ構造などが含まれる。当業者には理解されるように、本発明は、ハンドヘルド機器、マルチプロセッサシステム、マイクロプロセッサを使用した、あるいはプログラム可能な消費者家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む他のコンピュータシステム構成で実施することが可能である。本発明は、通信ネットワークを通じてリンクされた遠隔の処理デバイスによってタスクが行われる分散コンピューティング環境で実施されることもできる。分散コンピューティング環境では、プログラムモジュールは、ローカルおよびリモート両方のメモリ記憶装置に配置されることができる。
【００２１】
図１を参照すると、本発明を実施するための例示的システムは、従来のパーソナルコンピュータ２０の形態の汎用コンピューティングデバイスを含み、これは、処理ユニット２１、システムメモリ２２、システムメモリ２２を含む各種のシステム構成要素を処理ユニット２１に結合するシステムバス２３を含む。システムバス２３は、各種のバスアーキテクチャの任意のものを使用したメモリバスまたはメモリコントローラ、周辺機器バス、およびローカルバスを含む数種のバス構造のいずれでもよい。システムメモリは、読み取り専用メモリ（ＲＯＭ）２４およびランダムアクセスメモリ（ＲＡＭ）２５を含む。起動時などにパーソナルコンピュータ２０内の要素間の情報転送を助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）２６は、ＲＯＭ２４に記憶される。パーソナルコンピュータ２０はさらに、ハードディスク３９の読み書きを行うハードディスクドライブ２７、取り外し可能磁気ディスク２９の読み書きを行う磁気ディスクドライブ２８、およびＣＤ−ＲＯＭまたは他の光学媒体などの取り外し可能光ディスク３１の読み書きを行う光ディスクドライブ３０を含む。ハードディスクドライブ２７、磁気ディスクドライブ２８、および光ディスクドライブ３０は、それぞれハードディスクドライブインターフェース３２、磁気ディスクドライブインターフェース３３、および光ドライブインターフェース３４によってシステムバス２３に接続される。これらのドライブとそれに関連付けられたコンピュータ可読媒体は、パーソナルコンピュータ２０のコンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータの不揮発性の記憶を提供する。ここで説明する例示的環境は、ハードディスク３９、取り外し可能磁気ディスク２９、および取り外し可能光ディスク３１を用いるが、当業者には理解されるように、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイカートリッジ、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）など、コンピュータからアクセス可能なデータを格納することができる他の種のコンピュータ可読媒体もこの例示的動作環境で使用されることができる。
【００２２】
ハードディスク３９、磁気ディスク２９、光ディスク３１、ＲＯＭ２４またはＲＡＭ２５にはいくつかのプログラムモジュールが記憶されることができ、これにはオペレーティングシステム３５、１つまたは複数のアプリケーションプログラム３６、他のプログラムモジュール３７、およびプログラムデータ３８が含まれる。ユーザは、キーボード４０およびポインティングデバイス４２などの入力装置を通じてパーソナルコンピュータ２０にコマンドと情報を入力することができる。他の入力装置（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどが含まれる。これらおよびその他の入力装置は、システムバス２３に結合されたシリアルポートインターフェース４６を通じて処理ユニット２１に接続されることが多いが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースで接続されることもできる。モニタ４７の形態のディスプレイも、ビデオカードまたはアダプタ４８などのインターフェースを介してシステムバス２３に接続される。１つまたは複数のスピーカ５７も、オーディオアダプタ５６などのインターフェースを介してシステムバス２３に接続されることができる。ディスプレイおよびスピーカに加えて、パーソナルコンピュータは通常、プリンタなどの他の周辺出力装置（図示せず）を含む。
【００２３】
パーソナルコンピュータ２０は、リモートコンピュータ４９など１つまたは複数のパーソナルコンピュータへの論理接続を使用するネットワーク環境で動作することができる。リモートコンピュータ４９は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、あるいはその他の一般的なネットワークノードでよく、通常は、パーソナルコンピュータ２０との関係で上述した要素の多くまたはすべてを含む。図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）５１およびワイドエリアネットワーク（ＷＡＮ）５２を含む。このようなネットワーキング環境は、オフィス、企業内のコンピュータネットワーク、イントラネット、およびインターネットなどに一般的に見られる。
【００２４】
ＬＡＮネットワーキング環境で使用される場合、パーソナルコンピュータ２０は、ネットワークインターフェースまたはアダプタ５３を通じてローカルエリアネットワーク５１に接続される。ＷＡＮネットワーキング環境で使用される場合、パーソナルコンピュータ２０は、通常は、インターネットなどのワイドエリアネットワーク５２を通じて通信を確立するためのモデム５４または他の手段を含む。モデム５４は、内蔵型でも外付け型でもよく、シリアルポートインターフェース４６を介してシステムバス２３に接続される。ネットワーク環境では、パーソナルコンピュータ２０との関係で図示したプログラムモジュール、またはその一部は、リモートのメモリ記憶装置に記憶されることができる。図のネットワーク接続は例示的なものであり、コンピュータ間に通信リンクを確立する他の手段を使用してよいことは理解されよう。
【００２５】
本発明は、図１に示すタイプのシステムで実施することができる。上述のように、本発明のテスト通知は、ユーザコンテキストシステムによって評価されることができる。テスト通知を評価するユーザコンテキストシステムについて、以下の図２〜図１０について中心的に説明する。テスト通知の評価について、その後の項で図１１〜１４との関係でより詳細に説明する。
【００２６】
図２〜図１０において、複数ソースからの通知の配信を制御するユーザコンテキストシステムが提供される。一実施形態では、ユーザコンテキストシステムは、通知の処理法を決定するために比較される３つの要素からなることができる。第１の要素は、ユーザのコンテキストである（オペレーティングシステムと、オペレーティングシステムを拡張した任意のプログラムから提供されることができる）。第２の要素は、ユーザの規則と嗜好である。第３の要素は、通知自体（ユーザの規則に合致することが可能なデータおよびプロパティなどの要素を含む）である。
【００２７】
下記でより詳細に説明するように、ユーザコンテキストシステムは、オペレーティングシステムおよび他のプログラムがユーザのコンテキストを宣言することによって動作し、コンテキストの宣言後は、システムがユーザのコンテキストと規則を仲介する。通知は、システム中に呼び出される他のプログラムによって生成される。ユーザのコンテキスト、規則、および通知の要素が比較され、通知の対処法に関する判定が行われる。通知の対処法についての各種のオプションの例には、拒否（通知がドローされる、あるいは音を立てることが許されない場合。その場合通知はユーザに見られない）、延期（ユーザのコンテキストが変化するか、ユーザの規則が、配信が後に適切になることを指示するまで通知が保留にされる）配信（ユーザのコンテキストおよび規則に従って通知の配信が許可される）、および転送（通知が現在のシステムでの配信も許可されるかどうかに関係なく、ユーザの規則が通知を別のシステムに渡すことを指示する）すること、が含まれる。
【００２８】
以下、通知を配信する各種ルーチンについてより詳細に説明する。一般に、ユーザは「連絡不可能」と考えられる状態にある可能性があり、その場合通知は配信されないか、ユーザが「連絡可能」になるまで保留にされる。例えば、ユーザがフルスクリーンアプリケーションを実行中の場合、そのユーザは連絡不可能とみなされる可能性がある。あるいは、そのユーザは「連絡可能」であるが、ユーザに適した形に通知を修正する必要があるような状態にあるとみなされる場合もある。例えば、ユーザが音楽を聴いているか会合中の場合、ユーザは、通知をユーザの画面に配信するが、通知に伴うサウンドはより小さくするか、全く生じさせないように指示している場合がある。
【００２９】
上記のように、ユーザコンテキストが、通知がユーザの画面に表示されるかどうかを部分的に決定する。通知が表示される場合は、ユーザコンテキスト中のある段階(gradient)に基づいて表示されることができる。すなわち、ドローされる通知の形態の侵入度には、指定することが可能な様々なレベルがある。例えば、通常の通知は、いつでもクライアント領域中に表示され、一時的にウィンドウを覆うことができる。ユーザがわずかに制限的なコンテキストにある場合、通知は自由に表示してよいが、別のウィンドウの上にドローすることはできないなどより侵入性の低い形でのみ表示することができる。別の例として、ユーザが最大化されたアプリケーションを実行中の一実施形態におけるデフォルトの設定は、例えば、アプリケーションが最大化されていることはコンテキストがわずかに制約されていることを意味し、ユーザがそのアプリケーションにクライアント領域全域を使用したいことを明確に表明しているという設定にすることができる。この設定では、通知のドローはなお許可されることができるが、サイドバー中のみに表示されるように行われることができる。すなわち、このタイプの通知のドロー形態の侵入性の低下は、通知の影響を小さくし、全体として認知的な負荷を小さくする。
【００３０】
図２は、通知を処理するルーチン２００を説明する流れ図である。ブロック２０２で、オペレーティングシステムまたは任意のプログラムが、通知のアプリケーションプログラムインターフェース（ＡＰＩ）を呼び出す。ブロック２０４で、オペレーティングシステムおよび任意のプログラムによって設定され、さらにユーザによって承認または変更されたユーザコンテキストと、ユーザによって設定されたユーザ規則について、通知の要素が評価される。ブロック２０６で、ユーザコンテキストおよびユーザ規則に応じて通知が配信、延期、拒否、転送、またはその他の形で処理される。
【００３１】
ユーザコンテキストおよびユーザ規則について下記でより詳細に説明する。一実施形態では、ユーザコンテキストは、真または偽のどちらかである条件と、その条件が真である時の通知の対処法を決定する命令とからなる。一般に、ユーザコンテキストの条件とは、通信を配信するのにユーザを何らかの形で連絡不可能にするとシステムが見なす状態、または通知が配信される方式を、その通知をスタートしたプログラムによって送信された方式とは異なるものにする状態と考えることができる。すなわち、一実施形態では、ユーザコンテキストは「条件Ｘが真である時には、これが着信する通知に行う操作である」という文と考えることができる。一例は「音楽プレーヤが音楽を再生している時は、着信する通知はサウンドなしで画面に表示する」である。別の例は「フルスクリーンモードで実行されているアプリケーションがある時は、着信する通知は後まで延期する」である。
【００３２】
そのようなユーザコンテキストについて、一実施形態では、ユーザは着信する通知に対処する特別な規則を定義することもでき、したがって、ユーザコンテキストの命令に特別な例外を提供することができる。一例として、ユーザ規則は、「私が「Ｊｏｈｎ  Ｄｏｅ」から新しい電子メールを受信し、そのテキスト中に「緊急」とあり、「高優先度」とマークされている場合は、他のユーザコンテキストに関係なくその電子メールを配信する」と指示することができる。すなわち、この例では、このユーザ規則は、それ以外の場合は着信電子メールについての通知をその時に配信することは不適切であると指示するユーザコンテキストに例外を提供する。ユーザ規則がそれとの関係で評価される通知の要素に関して、その要素は、テキスト、サウンド、グラフィックなどの事物、および優先度、通知の送信者（電子メールやインスタントメッセージなどのチャネルの場合）、通知の有効期限などの他のプロパティ、および何らかのコード要素を含むことができ、ユーザは通知と対話し、任意のコードを起動することができる（例えば、通知中のボタンやテキストをクリックすることにより、新しいプログラムを起動させる、あるいは現在実行中のプログラムで動作（電子メールの削除など）を行わせることができる）。
【００３３】
図３は、オペレーティングシステムまたは任意のプログラムがユーザコンテキストを宣言するルーチン２２０を説明する流れ図である。ブロック２２２で、オペレーティングシステムまたはプログラムが、デフォルトのコンテキストと、ユーザのビジー状態に対するその影響を宣言する。すなわち、プログラムは、通知に対するその影響（例えば、画面へのドローが適切であるかどうか、およびサウンドが適切であるか否か、あるいはどれほどの相対的な音量でサウンドを再生すべきかなど）を含めたユーザコンテキストをシステムに登録し、提供する。一例として、音楽プレーヤプログラムは、「音楽プレーヤがユーザのために音楽を再生している時は、着信する通知は画面に表示するが、サウンドは再生しない」と指示するデフォルトコンテキストを宣言することができる。別の例として、オペレーティングシステムは、「フルスクリーンモードで実行中のアプリケーションがある時は、着信する通知は後の時間まで延期する」と指示するコンテキストを宣言することができる。
【００３４】
再び図３に戻る。ブロック２２４において、オペレーティングシステムまたはプログラムが宣言したコンテキストを真または偽として設定する。例えば、「音楽プレーヤが音楽を再生している時は、着信した通知は画面に表示するが、サウンドは再生しない」というコンテキストを宣言する音楽プレーヤの場合、その音楽プレーヤプログラムは、宣言したそのコンテキストが現在真であるか偽であるかも設定する。すなわち、音楽プレーヤプログラムは、音楽プレーヤが現在音楽を再生中であるということが真であるか偽であるかを指示する。下記でより詳細に説明するように、一実施形態では、コンテキストが真か偽かの決定は、通知ＡＰＩが呼び出される時に評価されても、ユーザ規則および例外が再度評価される時に評価されてもよい。追加的な機能として、システムは、呼び出しプログラムのプロセスハンドルを追跡することもでき、プロセスが最初にコンテキスト値をそのデフォルトの「偽」の値に再設定せずに終了した場合、システムは、最初のプロセスがもう存在しないことを検出すると直ちにそのコンテキスト値を再設定する（一実施形態では、プロセスハンドルの状態は、プロセスが終了した時にそれを伝えるように設定され、その状態の変化は、プロセスハンドルを監視するシステムによって認識(pick up)される）。これにより、プロセスが予期せずに終了した場合、あるいはプロセスがコンテキストの再設定を忘れた場合に、それ以降の通知の配信が必要以上に影響を受けないことが保証される。例えば、上述の例で音楽プレーヤプログラムが終了され、プロセスがもはや存在しない場合は、コンテキストが自動的に偽に再設定されることが可能である。別の例として、あるプログラムが最初にユーザがビジーであると宣言したが、その後そのプログラムがクラッシュしてプロセスがもはや存在しなくなった場合、通知が受信されない状態にユーザを置いたままにするのではなく、コンテキストが自動的に偽に設定されることができる。いずれにせよ、一実施形態では、コンテキストがアクティブに設定されているか、または関数として評価されているか否かに関係なく、コンテキストは一般には真または偽のいずれかに解決することができる。
【００３５】
図３のブロック２２６において、システムに記憶されたユーザコンテキストにコンテキスト情報が追加される。このプロセスは、コンテキストを宣言する追加的なプログラムによって繰り戻される。また、上述のように、すでに宣言されたコンテキストが真であるか偽であるかの状態は、ユーザが様々なプログラムを起動および終了し、様々なタスクをスタートするのに従って時間の経過と共に変化する。
【００３６】
上述のように、一実施形態では、コンテキストの登録は宣言的なプロセスである。下記でより詳細に説明するように、ユーザコンテキストシステムでは、ユーザコンテキストを登録することによりコンテキストのリストをユーザに提示することができ、ユーザはあるコンテキストを容認しないことを選択するか、ユーザがコンテキストパラメータに同意しない場合はコンテキストの意味を変更することができる。上述のように、一実施形態では、コンテキストは、真または偽である条件と、その条件が真である時の通知の処理法の命令とからなることができる。これに関して、ユーザコンテキストは、人間が読むことのできる文字列（エンドユーザにその内容を知らせる）、一意の識別子（グローバル一意識別子（ＧＵＩＤ：globally unique identifier））などの特定のプログラミング要素を含むことができ、プログラムは、そのコンテキストがいつ真であるか否かと、画面への通知の表示に関してそのコンテキストが何を意味するかを示す文を含むことができる命令（侵入度のレベル、サウンド、および音量を含むことができる）とをオペレーティングシステムに知らせることができる。下記でより詳細に説明するように、コンテキストは動的であってもよい。
【００３７】
図４は、通知ＡＰＩが呼び出される時にコンテキストが真であるか偽であるかを評価するルーチン２３０を説明する流れ図である。判定ブロック２３２で、通知ＡＰＩが呼び出される時にユーザコンテキストを評価すべきかどうかの判定が行われる。ユーザコンテキストを評価する場合は、ルーチンはブロック２３４に進む。通知ＡＰＩが呼び出される時にユーザコンテキストを評価しない場合、ルーチンは終了する。ブロック２３４で、ユーザコンテキストが真であるか偽であるかが評価される。
【００３８】
図３および図４に示し、また先に述べたように、コンテキストは前もって設定されても、または関連する時に評価される関数であってもよい。一例として、プログラムは、ユーザが音楽を聴いていることをアクティブに認識することができる。別の例として、通知が評価される時にプログラムは自身のコールバックを登録している可能性があり、通知が評価される時にそのコンテキストが真であるかどうかがシステムからプログラムに問い合わせられる。この２番目のプロセスが特に重要である事例の一例は、ユーザコンテキストがユーザ規則と組み合わせられて動的なコンテキストを形成する場合である。（ユーザ規則については下記でより詳細に説明する。）ユーザ規則と組み合わせられたユーザコンテキストの具体的な一例は、ユーザが「現在自分が会っている人々は、自分がビジーである状態に関係なく常に私に通知を送信することができる」と指示する規則を設定している場合である。この場合、「ユーザが会合中の時」というユーザコンテキストをさらにユーザがその会合で一緒である者の点から評価しなければならない。この例では、会合を扱うプログラムはこれを動的なコンテキストとして登録することができ、通知が評価される時にはその通知を送信した者がそのコンテキストに照らして評価される（会合の出席者は時間の経過と共に変わる可能性があるので、このコンテキストは動的にする以外に事前に真または偽と宣言することはできない）。すなわち、この特定の例では、他の人々のコンテキストに依存するユーザ規則に照らしてユーザのコンテキストを評価することが必要になる。
【００３９】
図５は、ユーザがコンテキストを調整し、新しい規則を作成するためのルーチン２４０を説明する流れ図である。ブロック２４２において、ユーザがコンテキストを調整したいか否かが判定される。ユーザがコンテキストの調整を希望しない場合、ルーチンは判定ブロック２４６に進む。このブロックについては下記でより詳細に説明する。ユーザがコンテキストの調整を希望する場合、ルーチンはブロック２４４に進み、ユーザがコンテキストの変更を行う。
【００４０】
一実施形態では、提供されたコンテキストは、ユーザがそのコンテキストをオフにすることができる（例えばユーザがプログラムによるそのコンテキストの査定に同意しない場合）か、または通知の配信に対する影響の点からコンテキストを変更できる形でユーザに公開されることができる。より具体的な例として、ユーザコンテキストは、「フルスクリーンモードで実行中のアプリケーションがある時」、「自分が音楽またはビデオを再生している時」、「会合マネジャが自分が会合中であると示す時」、あるいは「不在時アシスタントがオンになっている時」などの事柄を含むことができる。こうした事柄それぞれについて、与えられた条件が真である時には、着信する通知は選択された手順に従うという命令を指定する選択をユーザが行えるようにすることができる。この命令は、通知を画面にドローすることの可否またはその方式、および通知に伴うサウンドまたは音量といった事柄を指定することができる。音量について、ユーザは、所与の条件下で希望する音量のパーセンテージを指定することができる。通知を画面にドローするオプションについては、通知を一切ドローしない、あるいは指定された外部ディスプレイのみに通知をドローする、あるいは現在の画面に通知をドローするなどの選択肢がユーザに提供されることができる。通知のドローについては様々なレベルの侵入性を指定することができる。例えば、ユーザが最大化されたアプリケーションを実行中で、コンテキストがわずかに制約されている場合、侵入度の設定は、通知のドローは可能であるがサイドバー中のみに表示するという設定にすることができる。
【００４１】
図５のブロック２４６において、ユーザが新しいユーザ規則を作成することを希望するか否かが判定される。ユーザが新しいユーザ規則の作成を希望しない場合、ルーチンは判定ブロック２５０に進み、このブロックについては下記でより詳細に説明する。ユーザが新しいユーザ規則の作成を希望する場合、ルーチンはブロック２４８に進み、新しい規則が作成される。一般に、ユーザ規則は、指定された要素を含む通知をどのように扱うべきかを指示する。例えば、規則は、指定された者からの通知は常に直ちに配信すると指示することができ、その規則は、その通知が指定された者からであれば、通知を開始したプログラムに関係なくすべての通知に適用されることができる。より具体的な例として、他のユーザ規則は、「ワシントン州ブレマートンについてのＭＳＮオートの交通警報」や「Ｊｏｈｎ  Ｄｏｅからの重要な電子メール」などの事柄を対象とすることができる。Ｊｏｈｎ  Ｄｏｅからの重要な電子メールについてのユーザ規則の一例として、その規則は、Ｊｏｈｎ  Ｄｏｅから到着する電子メールで、テキスト中に「緊急」とあり、「高優先度」とマークされた電子メールは指定された処理条件に従うように指示することができる。その処理条件は、通知を直ちに配信し、通知を受信したことを相手に知らせることをユーザに要求することを指定することができる。一般に、通知を受信したことを相手に知らせることをユーザに要求することは、ユーザが明確にその通知を消すまで通知が画面に表示され続けるという点で、通知の侵入度の形態にわずかな増大があることを意味する。一実施形態では、ユーザによる受信通知の要求は、ユーザ規則を介してのみ設定することができる。別の例として、規則は、通知のために指定された音量で再生されるカスタムサウンドを指定することもでき、特別な通知が到着したというアラートをユーザに提供することができる。ユーザのコンテキストによって決定されるユーザの「通常」および「ビジー」の状態中の通知の対処法については、様々な設定が選択されることもできる。この対処命令は、「Ｊｏｈｎ  Ｄｏｅからの通知はページャに配信する」など通知の転送オプションのような事柄も含むことができる。一実施形態では、コンテキストが評価される時には、最も制限的な現在真のコンテキストが適用されるコンテキストとなる。ユーザ規則が評価されるということは、特定の通知がユーザの作成した規則と合致したことを意味し、その場合は通知と合致したユーザ規則のうち最も侵入度の高い設定が適用される。すなわち、ユーザ規則で、ユーザは重要とする何らかの事柄を指定しており、この手順はユーザの嗜好に従うものとする。２つの規則に矛盾がある場合は、最も侵入度の高い規則が適用される。
【００４２】
一実施形態では、ユーザ規則は、特定の通知サービスからの通知の配信を制御することも対象とすることができる。例えば、通知サービスに従って通知を提供するオペレーティングシステムは、通知の配信方式を変更する方法をユーザに提供することができる。例えば、指定された通知サービスが「シアトルの交通警報」を提供することができ、ユーザは、そのような通知が受信された時にはシステムが「通知を表示し、サウンドを再生する」ように配信を編集することができる。
【００４３】
図５の判定ブロック２５０において、ユーザが既存のユーザ規則の調整を希望するか否かが判定される。ユーザが規則の調整を希望しない場合、ルーチンは終了する。ユーザがユーザ規則の調整を希望する場合、ルーチンはブロック２５２に進み、ユーザが規則の変更を行う。
【００４４】
先に図３〜図５に関して述べたように、ユーザコンテキストおよびユーザ規則は、オペレーティングシステム、プログラム、およびユーザによって設定される。システムは、ユーザの嗜好に従って通知の配信を適切に仲介し、順番（直列化：serialize）にする。ユーザコンテキストおよびユーザ規則はユーザに公開されることができ、ユーザは各種のコンテキストおよび規則を変更または調整するか、または新しい規則を作成することができる。これにより、通知の対処方式についての嗜好を管理する集中化された方法がユーザに提供される。これにより、ユーザは、ユーザへの通知の送信を求める可能性があるコンピューティングシステム中の多数の競合する要素を効果的に管理できることは理解されよう。
【００４５】
図６は、ユーザコンテキストおよびユーザ規則に従って通知を処理するルーチン３００を説明する流れ図である。ブロック３０２において、オペレーティングシステムまたは任意のプログラムが通知ＡＰＩを呼び出す。判定ブロック３０４において、その通知を通知の履歴に記録すべきか否かの判定が行われる。通知を記録すべき場合は、ルーチンはブロック３０６に進み、通知が履歴に記録される。通知を記録すべきでない場合は、ルーチンは判定ブロック３１０に進む。
【００４６】
判定ブロック３１０において、通知がいずれかのユーザ規則に合致するか否かが判定される。通知が合致する規則がある場合、ルーチンはブロック３１２に進み、（通知の内容とユーザコンテキストに基づいて）そのユーザ規則に従い、ルーチンは図７に続く点Ａに進む。判定ブロック３１０で通知がどのユーザ規則にも合致しない場合、ルーチンは判定ブロック３２０に進む。
【００４７】
一実施形態では、ユーザ規則は常に現在のユーザコンテキストよりも優先される。上述のように、ユーザ規則は、任意の通知の要素に基づくことができる。例えば、通知を開始した者の評価に基づく規則は、その規則が基づく者からの通知であればどのプログラムが通知を開始したのかに関係なくすべての通知に適用されることができる（例えば「Ｊｏｈｎ  Ｄｏｅ」は常に私と連絡をとることができるなど）。また、通知は、本来はその通知をドロー(draw)させないコンテキスト中であっても画面にドローすることができる（例えば、ユーザコンテキストが、一般にはユーザは会合中には通知を受け取らないことを指示していても、「私と一緒に会合に出ている人は常に私に通知を送信できる」など）。
【００４８】
図６の判定ブロック３２０において、現時点で(at the present time)通知をドローできるか否かが（ユーザコンテキストのみに基づいて）判定される。現時点で通知をドローできる場合は、ルーチンはブロック３２２に進み、通知がドローされ、適切なサウンドと音量が提供される。現時点では通知をドローすることが適切でない場合、ルーチンは判定ブロック３３０に進む。
【００４９】
判定ブロック３３０において、通知の有効期限が切れているか否かが判定される。通知の有効期限が切れている場合、ルーチンはブロック３３２に進み、通知が破棄される。通知の有効期限が切れていない場合、ルーチンはブロック３３４に進み、通知が延期され、ルーチンは図７に続く点Ｂに進む。
【００５０】
図７は、指定されたユーザ規則に従って通知を処理するルーチン３５０を説明する流れ図である。このルーチンは、上記のように図６の点Ａから続いている。図７に示すように、判定ブロック３５２で、通知を転送すべきか否かが判定される。通知を転送すべきでない場合、ルーチンは判定ブロック３６２に進み、このブロックについては下記でより詳細に説明する。通知を転送すべき場合ルーチンはブロック３５４に進み、指定に従って通知が転送される。通知が転送される時は、その通知が、その通知を別のシステムに渡すことを必要とするユーザの規則と合致する要素を含んでいることを意味する。これは、例えばユーザがビジーである場合に行われる可能性があり、あるいは、ユーザが連絡不可能であるか否かに関係なくユーザの規則で指定される基準に合致するすべての通知で行われる可能性がある。一例として、その中に「緊急」という単語が含まれる通知は常にユーザのページャに転送されるのに対し、その他の通知はユーザの規則とコンテキストの組合せに基づいてのみ転送されるようにすることができる。
【００５１】
転送命令(routing instruction)のいくつかの例には、「その通知をある電子メールアドレスに転送する」、「その通知を別のＰＣに転送する」、「その通知をページャに転送する」、「その通知を携帯電話に転送する」、あるいは「その通知を電子メールサーバに転送する」などがある。下記でより詳細に説明するように、通知が転送される場合、その通知は配信され、画面にドローされることもできる。また、通知が転送されるデバイスはこれと同じコンテキストシステムを実装することができ、そのデバイスにはユーザのコンテキストについての追加的または異なる知識があってよく、そのデバイスのコンテキストシステムは、通知に対して異なる動作を行うことを選択することができる。
【００５２】
図７の判定ブロック３６２において、通知を拒否するか否かが判定される。通知を拒否しない場合、ルーチンは判定ブロック３６６に進み、このブロックについては下記でより詳細に説明する。通知を拒否する場合、ルーチンはブロック３６４に進み、通知が破棄され、その通知はユーザによって見られない。すなわち、拒否される通知は、ドローする、または音を立てることが許されない。通知の拒否は、例えば、特定の通知を拒否すると指示するユーザ規則に基づいて行われる場合があり、または上記で図６のブロック３３２を参照して述べたように通知の有効期限が切れている場合に行われる可能性がある。
【００５３】
図７の判定ブロック３６６において、通知を延期すべきか否かが判定される。通知を延期すべきでない場合、ルーチンは判定ブロック３７０に進み、このブロックについては下記でより詳細に説明する。通知を延期すべき場合、ルーチンはブロック３６８に進み、ユーザコンテキストが変化するまで通知が保留にされ、ルーチンは図８に続く点Ｂに進む。一般に、通知を延期するということは、通知の配信はいずれは許可されるが、ユーザの現在のコンテキストまたは規則がその時に通知を配信するには適当でないとみなされるものであることを意味する。後に図８を参照してより詳細に述べるように、ユーザのコンテキストが変化するか、あるいはユーザの規則が後に配信が適切になると示すと、ユーザ規則およびユーザコンテキストの指示に従って通知がユーザの画面に配信され、ドロー(draw)および／またはそのサウンド(sound)を生成することが許可される。
【００５４】
図７の判定ブロック３７０において、通知を配信すべきか否かが判定される。通知を配信すべきでない場合、ルーチンは終了する。通知を配信すべき場合、ルーチンはブロック３７２に進み、適切な侵入度のレベルに従って通知がドローされ、適切なサウンドと音量が提供される。すなわち、通知の配信は許可されるが、ユーザのコンテキストおよび規則に従って配信される（例えば通知をドローしてもよいが、サウンドなしでドローすることが要求されるなど）。
【００５５】
図８は、通知の配信を延期するルーチン３８０を説明する流れ図である。上記のように、このルーチンは図６または図７の点Ｂから続いている。図８に示すように、ブロック３８２で通知が保留にされる。ブロック３８４において、システムが、真または偽であるとして宣言されたコンテキストへの変更があるか否か、または通知の配信が現在適切であると示すユーザ規則があるか否かを調べる。判定ブロック３８６において、ユーザコンテキストが変化しているか否か、またはユーザ規則が通知を配信するのが現在適切であると示すか否かが判定される。ユーザコンテキストが変化しておらず、他に指示をするユーザ規則がない場合、ルーチンはブロック３８２に戻り、通知が引き続き保留にされる。ユーザコンテキストが変化しているか、通知の配信が現在適切である可能性があるとユーザ規則が示す場合、ルーチンは図６に続く点Ｃに進む。図６の点Ｃは判定ブロック３０４に戻り、ここから通知を評価するプロセスが再びスタートする。
【００５６】
図９は、各種の制約に応じて通知のドローを決定するルーチン４００を説明する流れ図である。このルーチンは、図６のブロック３２２または図７のブロック３７２など通知処理の一部として実施してよいことを理解されよう。一般に、通知がシステムに入ると、その時点で真であるすべてのコンテキストについて評価が行われ、その通知についての最も制限的な設定がその時点のユーザの状態に応じて適用される。図９に示すように、判定ブロック４０２において、通知を一切ドローすべきでないか否かが判定される。通知を一切ドローしない場合、ルーチンはブロック４０４に進み、どのディスプレイにもドローされないように通知が設定される。通知をドローすべき場合、ルーチンは判定ブロック４０６に進む。
【００５７】
判定ブロック４０６において、通知を外部でのみドローすべきか否かが判定される。通知を外部でのみドローすべき場合ルーチンはブロック４０８に進み、外部のハードウェアディスプレイのみに通知がドローされる。通知を外部のハードウェアディスプレイにドローすべきでない場合、ルーチンは判定ブロック４１０に進む。
【００５８】
判定ブロック４１０において、通知を現在のディスプレイでドローすべきか否かが判定される。通知を現在のディスプレイでドローすべき場合、ルーチンはブロック４１２に進み、該当する侵入度レベルに応じて現在のディスプレイに通知がドローされる。通知を現在のディスプレイにドローすべきでない場合、ルーチンは終了する。
【００５９】
図１０は、各種の制約に従って通知のサウンドが再生される音量を決定するルーチン４２０を説明する流れ図である。図９との関連で上述したように、このルーチンは、図６のブロック３２２または図７のブロック３７２など通知の処理の一部として実施してよいことは理解されよう。通知がシステムに入ると、その時点で真であるすべてのコンテキストの評価が行われ、その時点のユーザの状態に応じて最も制限的な設定が通知に適用される。図１０に示されるように、判定ブロック４２２において、通知を消音にすべきか否かが判定される。通知を消音にすべき場合、ルーチンはブロック４２４に進み、その通知には音量が提供されない。通知を消音にすべきでない場合、ルーチンは判定ブロック４２６に進む。
【００６０】
判定ブロック４２６において、最大のボリュームより小さいいくらかのパーセンテージの音量で通知を提供すべきか否かが判定される。いくらかのパーセンテージの音量を提供すべき場合、ルーチンはブロック４２８に進み、指定されたパーセンテージの音量で通知が再生される。指定されたパーセンテージの音量を提供すべきでない場合、ルーチンは判定ブロック４３０に進む。
【００６１】
判定ブロック４３０において、その通知に最大の音量を提供すべきか否かが判定される。最大の音量を提供すべき場合、ルーチンはブロック４３２に進み、最大の音量レベルで通知が再生される。最大の音量を提供すべきでない場合、ルーチンは終了する。一実施形態では、通知に異なる音量レベルを提供するのに加えて、ユーザのコンテキストおよび規則に従って通知に異なるサウンドを選択することも可能である。
【００６２】
図１〜図１０に関して上記で説明したユーザコンテキストシステムは、システムが各自の画面へのレンダリングを適切に仲介し、順番（直列化）にするので通知が互いと衝突しなくなるような形で各種ソースからの通知の配信を制御することは理解されよう。また、ユーザコンテキストシステムによって処理される通知は、ユーザがより通知を受け付けられる状況にある時に配信されるのでより価値が高くなると考えることができ、また、共通の規則を使用することによりユーザが不要な通知を解消するのを助ける。
【００６３】
図１１〜図１４は、テスト通知の評価(evaluation of test notification)を対象とする。下記でより詳細に説明するように、本発明の一態様によれば、テスト通知は、現在のユーザコンテキストの状態についての情報を得るために任意のプログラムによって利用されることができる。この態様の１つの利点は、そのプログラムがシステム中にすでに構築されているこのサービスを使用することを意図するか否か、あるいはそのプログラムが、通知の表示方式とその配信方式の独自の解釈を展開(roll)することによりこのサービスを拡張するか否かに関係なく、どのプログラムもユーザコンテキスト情報を得られることである。すなわち、このシステムによって提供されるレンダリングで制限されるように設計されていないより高度な通知を備える将来のプログラムも、テスト通知を利用してユーザの現在のコンテキストについての情報を得ることができる。そのようなより高度な通知は、通知方式のリッチさが成長と変化を続けるのに伴って、そして通知のための新たなユーザインターフェースが発展し続けるのに伴って出現することが考えられる。
【００６４】
一例として、将来のユーザインターフェースは、ユーザが「ビジー」でない時にのみドローされるリッチなフルスクリーン動画を提供する可能性がある。例えば、ＣＤ−ＲＯＭドライブにＣＤを入れると、ＣＤ−ＲＯＭが回転速度を上げる間に画面にＣＤの動画が提示される（技術的な制約のために、ＣＤがドライブ中にあることが分かっていてもＣＤが最初に挿入されてからＣＤを読み出せるようになるまでいくらかの時間があり、この時間中に動画を使用してシステムがＣＤを認識しているが、単にまだ読み出しが可能でないことをユーザに知らせることができる）。本発明のテスト通知を使用することにより、動画プログラムは、ユーザの現在のコンテキストについて知ることができ、ユーザがその時点で通知を受け取れない状況である場合は画面への表示を行わないことを選択することができる。
【００６５】
別の例として、将来のインスタントメッセージングプログラムは、現在の通知エンジンでは行うことができない新規の通知のユーザインターフェースを開発する可能性がある。そのような新しいユーザインターフェースの開発は、競争の激しい現在の市場で求められる柔軟性の一環として必要とされる。本発明によれば、テスト通知は、ユーザの現在のコンテキストに応じてそのようなインスタントメッセージングプログラムが備えるより高度な通知を表示すべきか／表示すべきでないかを判定するために、将来のインスタントメッセージングプログラムによって利用され続けることができる。
【００６６】
本発明の別の態様によれば、テスト通知は、不要な通知の生成を防止するために利用されることができる。この態様は、システムに通知を送信しようとする任意のプログラムに適用されることができる。すなわち、プログラムがよりリッチなユーザコンテキストのビューを得られるようにすることにより、不要な通知がプログラムによって生成されないようにすることができ、したがってユーザが通知を受け取れる状態になるまでその種の通知の生成を時間的に先んじて停止させることができる。次の例は、本発明のこの態様を例証する助けとなる。
【００６７】
一例として、インスタントメッセージングプログラムは連絡先のリストを提供することができる。テスト通知は、連絡先単位でコンテキストシステムを利用する(tap into)ことができる（例えば「トムが今インスタントメッセージを送信した場合、それは表示されるか？」と「クリスが今インスタントメッセージを送信した場合、それは表示されるか？」等）。その情報に基づいて、インスタントメッセージングプログラムは、明確なビジーな状態または暇な状態を個々の連絡先に同報通信し始めることができる。この技術を使用して、単に受信された後に抑制するのではなく、不必要な通知の生成を時間的に先んじてやめさせることができる。
【００６８】
別の例として、ユーザがビジーである場合、メールプログラムはテスト通知を使用して、送信者に自動化された返信を提供することができる（「直属の部下」や「部長」などユーザが提供した規則に基づくすべての送信者に）。この自動化された返信は、「今は忙しいが機会ができたら返事をする」ことを伝えることができる。一般に、このシステムの通信は概して、ユーザのコンテキストを任意のプログラムに公開することによって向上させることができる。
【００６９】
上述のように、本発明によれば、アプリケーションは、テスト通知を構築し、実際の通知が現時点で画面にドローされるか否かを明確に受け取ることができる。先に述べたように、これにより、通知のための新しいユーザインターフェースが開発された後でも、プログラムがこのユーザコンテキストシステムを引き続き使用することが可能になる。また、他のプログラムのためにこうした新しいよりリッチなシナリオを可能にすることにより、ユーザの振る舞いおよび嗜好についての情報へのアクセスをより多く得られる点で、このシステムを利用するすべてのプログラムはよりリッチであり、よりインテリジェントであると考えることができる。
【００７０】
図１１は、本発明によりテスト通知を処理する一般的なルーチン５００を説明する流れ図である。このルーチンは、実際の通知を処理する図２のルーチンと同様である。図１１のブロック５０２において、通知テストのＡＰＩが呼び出される。ブロック５０４において、オペレーティングシステムおよび任意のプログラムによって設定され、さらにユーザによって承認または変更されたユーザコンテキストと、ユーザによって設定されたユーザ規則とについて、テスト通知の要素が評価される。ブロック５０６において、テスト通知の評価に従ってテスト通知の対処法に関する指示が提供される。この指示(indication)は、次いで、呼び出しアプリケーション(calling application)に戻される。
【００７１】
一実施形態では、オペレーティングシステムまたは任意のプログラムが現在ユーザがどれほどビジーであるか理解する必要があると判断した時に通知テストＡＰＩが呼び出される。これが行われる時の一例は、画面に通知をドローするかしないかの判定ポイントがある場合である。別の例は、このデータを使用して、プログラムがユーザのために行いたい動作を通知するものである。
【００７２】
通知テストのＡＰＩが呼び出されると、呼び出しプログラムは、実際の通知を送信するためにユーザコンテキストシステムの通知法を使用した場合に送信する通知に近い通知を構築し、最適なテスト方法を使用する（それにより結果が返され、またその特定の通知が画面に表示されないことも保証される）。このプロセスの一例は、インスタントメッセージングプログラムが、現在のユーザのコンテキストに基づいて該当する暇な状態またはビジーの状態を各連絡先に同報通信することを求める場合である。インスタントメッセージングプログラムは、各連絡先についてのテスト通知を作成し、戻り値に基づいて異なる暇な状態またはビジーの状態を連絡先単位で同報通信する。別の例は、ユーザのコンテキストに基づく動画を表示しようとするプログラムである（例えば上述のＣＤ−ＲＯＭ動画の例）。動画を表示したいコードは、通知を構築し（この場合、通知はその通知をドローするか否かについてのテストなので、内容は単に画像または動画のシーケンスを備えた単純な通知である）、そしてこのテスト方法を使用し、返された結果は今動画を再生すべきか否かについての指針として使用されることができる。一実施形態では、一般には、呼び出し元のコードは少なくとも、テスト通知として可能な最も一般的な通知を生成する。ユーザは戻される結果に影響する可能性がある個人単位のカスタムユーザ規則を有する可能性があるので、よりリッチなデータ（連絡先リストの連絡先など）を利用できる場合は、その情報を含めることによりテスト通知がより正確になる。
【００７３】
通知テストＡＰＩに利用することが可能な実施の１つは、ポーリングの実施である。上述のインスタントメッセージングプログラムの例では、ポーリングの実施のために、インスタントメッセージングプログラムは周期的に通知テストＡＰＩを再ポーリングして、同報通信データをどのように変更するかを決定する。通知テストＡＰＩに利用することができる別の実施は、サブスクリプションコールバックの実施である。この実施では、インスタントメッセージングプログラムはコンテキストの変化を「サブスクライブ」する。そして、ユーザのコンテキストはインスタントメッセージングプログラムが同報通信できる内容を変える形で変化するので、コンテキストエンジンは、周期的に再ポーリングするのではなく、適切な更新と共にインスタントメッセージングプログラムにコールバックすることができる。シナリオによっては、コールバックは、コンテキストの変化と同報通信される内容の間に時間差がない点で有利である（対してポーリングの実施では同報通信の状態が現在のユーザコンテキストと合致しない時がある傾向がある）。他のシナリオでは、ポーリングの実施がより適切な場合がある（それらは、ＣＤがＣＤ−ＲＯＭに挿入されるなどの１回限りの事象に対する応答であるため）。
【００７４】
図１２は、テスト通知を処理し、そのテスト通知を現時点ではドローするかしないかについて真または偽の指示を戻すルーチン５２０を説明する流れ図である。ブロック５２２において、通知テストＡＰＩが呼び出される。判定ブロック５３０において、そのテスト通知と合致するユーザ規則があるか否かが判定される。テスト通知がどのユーザ規則とも合致しない場合、ルーチンは判定ブロック５５０に進み、このブロックについては下記でより詳細に説明する。テスト通知が合致するユーザ規則がある場合は、ルーチンは判定ブロック５４０に進む。
【００７５】
判定ブロック５４０において、ユーザ規則がそのテスト通知が現時点ではドローされることを指示するか否かが判定される。テスト通知が現時点ではドローされる場合、ルーチンはブロック５４２に進み、真の指示が提供される。テスト通知が現時点ではドローされない場合、ルーチンはブロック５４４に進み、偽の指示が提供される。
【００７６】
判定ブロック５５０において、テスト通知を現時点でドローすることが可能であるか否かが判定される（ユーザコンテキストとの関連でのみ）。現時点でテスト通知をドローすることが可能な場合、ルーチンはブロック５５２に進み、真の指示が提供される。現時点では通知をドローすることが可能でない場合、ルーチンはブロック５５４に進み、偽の指示が戻される。ルーチンは、ブロック５４２、５４４、５５２、および５５４から、指定された指示と共に呼び出し元のアプリケーションに戻る。
【００７７】
図１３は、通知を処理し、詳細な指示を戻す(returning detailed indication)ルーチン６００を説明する流れ図である。上述のように、図１２のルーチン５２０は、通知を現時点ではドローするか否かに関して真または偽の指示を与える戻り値を提供するだけである。下記でより詳細に説明するように、図１３のルーチン６００は、よりリッチな戻り値を戻す（例えば通知は今すぐにはドローせず、ユーザのコンテキストが変化したら直ちにドローする、あるいは別のデバイスに転送するなど）。これにより呼び出しコード(calling code)に、よりリッチなロジック(richer logic)が提供される。これにより、そのようなよりリッチな戻り値(richer return value)を利用することが可能なプログラムでは高度な機能が可能になる。
【００７８】
また、関数呼び出し(function call)の一部として戻り値(return value)を説明しているが、別の実施形態ではこのデータはコールバックの一部として渡されてもよい。すなわち、呼び出し元のアプリケーションは、通知の「サブスクリプション(subscription)」をセットアップすることができ、ユーザのコンテキストが後に変化すると（呼び出しアプリケーション(calling application)からの通知の配信に影響する可能性がある）、呼び出しアプリケーションにその変化が通知される。これにはポーリングは必要とされず、したがって事例によってはシステムの堅牢性とパフォーマンスのためにより適当である。
【００７９】
図１３のブロック６０２において、通知テストＡＰＩが呼び出されるか、またはサブスクリプションが登録される（それぞれ上述のポーリングの実施形態とサブスクリプションの実施形態との関連で）。判定ブロック６１０において、テスト通知が合致するユーザ規則があるか否かが判定される。テスト通知がどのユーザ規則とも合致しない場合、ルーチンは判定ブロック６２０に進み、このブロックについては下記でより詳細に説明する。通知が合致するユーザ規則がある場合、ルーチンはブロック６１２に進む。ブロック６１２において、ユーザ規則に従ってテスト通知が（テスト通知の内容とユーザコンテキストに基づいて）評価され、ルーチンは図１４に続く点Ｄに進み、これについては下記でより詳細に説明する。
【００８０】
判定ブロック６２０において、テスト通知を現時点でドローすることが可能であるか否かが（ユーザのコンテキストのみに基づいて）判定される。現時点ではテスト通知をドローすることが可能でない場合、ルーチンは判定ブロック６３０に進み、このブロックについては下記でより詳細に説明する。現時点でテスト通知をドローすることが可能な場合、ルーチンはブロック６２２に進む。ブロック６２２において、ルーチンは、ユーザコンテキストに応じて適切と思われるサウンドレベルを決定する。ブロック６２４において、通知がドローされる旨の指示が提供され、またこの指示はその通知に適切と思われるパーセンテージのサウンドレベルを含む。
【００８１】
判定ブロック６３０において、テスト通知を後に配信するために保留にされるか否かが判定される（テスト通知の内容とユーザ規則に基づいて）。テスト通知を後まで保留する場合は、ルーチンはブロック６３２に進み、延期の指示が提供される。テスト通知を後に配信するために保留しない場合、ルーチンはブロック６３４に進み、拒否の指示が提供される。ブロック６２４、６３２、および６３４から、ルーチンは指定された指示と共に呼び出しアプリケーション(calling application)に戻る。
【００８２】
図１４は、ユーザ規則(user rule)に従ってテスト通知を評価するルーチン６５０を説明する流れ図である。このルーチンは図１３の点Ｄから続いている。図１４に示すように、判定ブロック６５２において、テスト通知を転送すべきか否かが判定される。テスト通知を転送すべき場合、ルーチンはブロック６５４に進み、転送の指示が提供され、ルーチンは判定ブロック６６２に進む。テスト通知を転送すべきでない場合もルーチンは判定ブロック６６２に進む。
【００８３】
判定ブロック６６２において、テスト通知が拒否されるか否かが判定される。テスト通知が拒否される場合、ルーチンはブロック６６４に進み、拒否の指示が提供される。テスト通知を拒否しない場合、ルーチンは判定ブロック６６６に進む。
【００８４】
判定ブロック６６６において、テスト通知が延期されるか否かが判定される。テスト通知が延期される場合、ルーチンはブロック６６８に進み、延期の指示が提供される。テスト通知が延期されない場合、ルーチンは判定ブロック６７０に進む。
【００８５】
判定ブロック６７０において、テスト通知が配信されるか否かが判定される。テスト通知が配信される場合、ルーチンはブロック６７２に進み、配信の指示が提供される。一実施形態では、配信の指示は、指定された侵入度の指示とサウンドおよび音量の指示も含むことができる。テスト通知を配信しない場合は、ルーチンは呼び出しアプリケーションに戻る。ブロック６６４、６６８、６７２から、ルーチンは、指定された指示と共に呼び出しアプリケーションに戻る。
【００８６】
図１〜図１４に関して上記で説明した本発明は、プログラムがユーザの連絡可能性についての指示を得ることができるテスト通知を利用するシステムおよび方法を提供することは理解されよう。プログラムがよりリッチなユーザコンテキストのビューを得られるようにすることにより、不要な通知の生成をソースで阻止することができ、したがってユーザが通知を受け取れる状態にある時にのみ通知を生成することができる。また、プログラムは、一般にはそのプログラムからの通知に異なるユーザインターフェースを利用していても、このテスト通知を利用してユーザのコンテキストを判断することができる。これらの態様により、ユーザコンテキストシステムの可能な使用法により高い柔軟性が得られる。これらの態様は、他のプログラムのためのよりリッチな新しいシナリオも可能にし、システム全体がユーザの振る舞いと嗜好に基づいてよりリッチかつインテリジェントになることができる。
【００８７】
本発明の好ましい実施形態を図示し、説明したが、本発明の精神および範囲から逸脱せずに各種の変更を行えることは理解されよう。
【図面の簡単な説明】
【００８８】
【図１】本発明を実施するのに適した汎用コンピュータシステムを示すブロック図である。
【図２】本実施形態により通知を処理する一般的なルーチンを説明する流れ図である。
【図３】オペレーティングシステムまたは任意のプログラムがユーザコンテキストを宣言するルーチンを説明する流れ図である。
【図４】通知ＡＰＩが呼び出される時にユーザコンテキストが真であるか偽であるかを評価するルーチンを説明する流れ図である。
【図５】ユーザコンテキストを調整し、新しいユーザ規則を作成するルーチンを説明する流れ図である。
【図６】ユーザコンテキストおよびユーザ規則に従って通知を処理するルーチンを説明する流れ図である。
【図７】通知の内容およびユーザコンテキストに基づいてユーザ規則を実行するルーチンを説明する流れ図である。
【図８】通知の配信を延期するルーチンを説明する流れ図である。
【図９】各種の制約的な設定に従って通知のドロー方式を決定するルーチンを説明する流れ図である。
【図１０】各種の制約的な設定に従って通知の音量レベルを決定するルーチンを説明する流れ図である。
【図１１】本発明によりテスト通知を処理する一般的なルーチンを説明する流れ図である。
【図１２】テスト通知を処理し、真または偽の指示を戻すルーチンを説明する流れ図である。
【図１３】テスト通知を処理し、十分な詳細事項を含む指示を戻すルーチンを説明する流れ図である。
【図１４】ユーザ規則を使用して、テスト通知の内容と現在のユーザコンテキストに基づいてテスト通知を処理するルーチンを説明する流れ図である。
【符号の説明】
【００８９】
２０  パーソナルコンピュータ
２１  処理ユニット
２２  システムメモリ
２３  システムバス
２４  ＲＯＭ
２５  ＲＡＭ
２６  ＢＩＯＳ
２７  ハードディスクドライブ
２８  磁気ディスクドライブ
２９  磁気ディスク
３０  光ディスクドライブ
３１  光ディスク
３２  ハードディスクドライブインターフェース
３３  磁気ディスクドライブインターフェース
３４  光ドライブインターフェース
３５  オペレーティングシステム
３６  アプリケーションプログラム
３７  プログラムモジュール
３８  プログラムデータ
３９  ハードディスク
４０  キーボード
４２  ポインティングデバイス
４６  シリアルポートインターフェース
４７  モニタ
４８、５３  アダプタ
４９  リモートコンピュータ
５１  ＬＡＮ
５２  ＷＡＮ
５４  モデム
５６  オーディオアダプタ
５７  スピーカ
【図１】
2004295899.tif 000003
【図２】
2004295899.tif 000004
【図３】
2004295899.tif 000005
【図４】
2004295899.tif 000006
【図５】
2004295899.tif 000007
【図６】
2004295899.tif 000008
【図７】
2004295899.tif 000009
【図８】
2004295899.tif 000010
【図９】
2004295899.tif 000011
【図１０】
2004295899.tif 000012
【図１１】
2004295899.tif 000013
【図１２】
2004295899.tif 000014
【図１３】
2004295899.tif 000015
【図１４】
2004295899.tif 000016