(57)【要約】【課題】  メッセージ送信側と受信側との間の通信が立ち入りすぎるのを緩和し、より礼儀正しくシームレスで適時の対話を容易にするためのシステムおよび方法を提供する。【解決手段】  一態様では、インスタントメッセージング、およびプッシュツートーク音声通信など他の形の通信を、時間限度付きポリシーおよびパラメータを利用することによって改善することができる。フリー時（Ｗｈｅｎ−Ｆｒｅｅ）通信により、ユーザはフリー時メッセージを送信することができ、フリー時メッセージは、ユーザまたは受信者がビジー状態または対応不可能状態として定義された状態のリストのうちの１つでなくなるまで待機する、インスタントに近いメッセージとして働く。送信側は、メッセージが消去または撤回されるか別の通信モダリティに移行される前にどのくらい長く生存しているべきかを、素早いジェスチャーまたは固定プロファイルによって符号化することができる。【選択図】  図１
2006018833.tif 000002
【特許請求の範囲】
【請求項１】
通知を搬送するのを容易にするシステムであって、
メッセージと共に符号化される時間パラメータと、
前記時間パラメータと受信者について決定されたビジー状態とに部分的に基づいて、前記メッセージを前記受信者に転送するかどうかを判定するメッセージ受信コンポーネントと
を備えたことを特徴とするシステム。
【請求項２】
エンドポイントデバイスにいる受信者にメッセージを送信するメッセージ送信コンポーネントをさらに備えたことを特徴とする請求項１に記載のシステム。
【請求項３】
前記メッセージ送信コンポーネントは、通信コンポーネント、インスタントメッセージングシステム、電話機またはセルホン、あるいはｅメールコンポーネントを含むことを特徴とする請求項２に記載のシステム。
【請求項４】
前記メッセージ受信コンポーネントは音声メールコンポーネントを含むことを特徴とする請求項１に記載のシステム。
【請求項５】
前記メッセージは、メッセージが受信者のデバイスまたはコンポーネントにいつどのように送信または伝送されるか、ならびに送信または伝送されるかどうかを制御するための、１つまたは複数のプロパティを含むことを特徴とする請求項１に記載のシステム。
【請求項６】
前記時間パラメータは、送信側が前記メッセージをどのくらい長くアクティブにしておくつもりであるかを指定する生存時間（ＴＴＬ）プロパティに関連することを特徴とする請求項１に記載のシステム。
【請求項７】
前記メッセージが前記ＴＴＬパラメータよりも長くキュー中に残っている場合は、前記メッセージはメッセージ受信者に届かないよう撤回されることを特徴とする請求項６に記載のシステム。
【請求項８】
前記キューはクライアントまたはサーバコンポーネント内で適合され、前記クライアントまたはサーバコンポーネントはメッセージの送信側または受信側に関連することを特徴とする請求項７に記載のシステム。
【請求項９】
前記時間パラメータを構成するか前記メッセージを作成するために利用されるユーザインタフェースをさらに備えたことを特徴とする請求項１に記載のシステム。
【請求項１０】
メッセージが撤回前にどのくらい長くアクティブであるべきかについて、メッセージを音声キューまたはテキストキューに対して自動的に分析するためのコンポーネントをさらに備え、前記コンポーネントは時間パラメータを自動的に構成することを特徴とする請求項９に記載のシステム。
【請求項１１】
前記ビジー状態は限度付き延期コンポーネントを介して決定されることを特徴とする請求項１に記載のシステム。
【請求項１２】
前記メッセージの送信側と受信側との間で他のデータを交換するためのステータスコンポーネントをさらに備えたことを特徴とする請求項１に記載のシステム。
【請求項１３】
前記データはさらに、前記メッセージが受信デバイスからレンダリングされたときに送信されるメッセージ受信済み確認をさらに含むことを特徴とする請求項１２に記載のシステム。
【請求項１４】
前記データはさらに、メッセージタイムアウトが生じて前記メッセージが送信されなかったことを伝える情報をさらに含むことを特徴とする請求項１２に記載のシステム。
【請求項１５】
前記データは、タイムアウト間近のメッセージはタイムアウトするのではなくメッセージ受信者まで突破できることを指定することを特徴とする請求項１２に記載のシステム。
【請求項１６】
前記データは、メッセージ受信者の保留状態の対応可能性またはビジーステータスを指定することを特徴とする請求項１２に記載のシステム。
【請求項１７】
前記データは代替メッセージ提案を指定することを特徴とする請求項１２に記載のシステム。
【請求項１８】
前記データは、インスタントメッセージがキュー中にあることを示す送信側の画像または送信側に関連するテキストを含むことを特徴とする請求項１２に記載のシステム。
【請求項１９】
メッセージ受信者によって定期的にチェックすることのできるアクティビティログをさらに備え、前記アクティビティログは、送信されたメッセージの量、関連するメッセージ内容、あるいは、通信を試みたが成功または失敗したかもしれないメッセージ送信側の識別を示すことを特徴とする請求項１に記載のシステム。
【請求項２０】
受信者にとって価値のある情報を含むメッセージを前記メッセージ受信者に気付かせるための最終期限に関連する限度付き延期期間をさらに含み、延期の許容範囲は前記情報の緊急性によって決まることを特徴とする請求項１に記載のシステム。
【請求項２１】
前記限度付き延期期間は、ユーザが忙しくてアラートを現在にまたは将来の所定時まで受信できないかどうかを判定するための、センサ、カレンダ情報、アラートタイプ、時刻のうちの少なくとも１つに関連することを特徴とする請求項２０に記載のシステム。
【請求項２２】
メッセージ受信者にとっての現在の割込みコストまたはビジー状態を決定するセンサをさらに備えたことを特徴とする請求項１に記載のシステム。
【請求項２３】
優先システムをさらに備え、限度付き延期期間は、前記メッセージについて推論された緊急性または優先度の関数であることを特徴とする請求項１に記載のシステム。
【請求項２４】
請求項１に記載のコンポーネントを実現するためのコンピュータ可読命令を記憶したことを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項２５】
通知を搬送するのを容易にするシステムであって、
ユーザの注意状態とユーザの位置とのうちの少なくとも一方に関係するデータを収集する、前記ユーザに関連するデバイスと、
通知の提供に関して前記データの少なくとも一部を利用する通知コンポーネントとを備え、
前記通知は、前記通知の寿命を制限する時間パラメータに関連付けられる
ことを特徴とするシステム。
【請求項２６】
通信を容易にするシステムであって、
時間パラメータを通知に関連付ける手段と、
メッセージ受信側の状態を感知する手段と、
前記通知を前記ユーザに搬送することに関して、前記感知された状態および前記時間パラメータを利用する手段と
を備えたことを特徴とするシステム。
【請求項２７】
通知を搬送するのを容易にする方法であって、
少なくとも１つのデバイスを使用してユーザの注意状態または位置に関する情報を決定または推論するステップと、
前記通知がどのくらい長くアクティブであるべきかを示す、時間によって制限されるパラメータを通知に関連付けるステップと、
通知を前記ユーザに搬送することについての決定に関して、前記情報と前記時間によって制限されるパラメータとを利用するステップと
を備えることを特徴とする方法。
【請求項２８】
前記決定に関して決定モデルを利用するステップをさらに含み、前記決定モデルは、アクションの価値とアクションのコストとのうちの少なくとも一方を処理して、前記通知を前記ユーザに搬送することに関する期待効用を決定することを含むことを特徴とする請求項２７に記載の方法。
【請求項２９】
前記アクションの価値およびアクションのコストは、前記ユーザの注意フォーカスおよび作業負荷を考慮することから部分的に決定されることを特徴とする請求項２８に記載の方法。
【請求項３０】
前記ユーザの注意フォーカスおよび作業負荷は、知覚センサ、デバイス対話、カレンダ、日、時間のうちの少なくとも１つを考慮することによって部分的に決定されることを特徴とする請求項２９に記載の方法。
【請求項３１】
前記ユーザの注意状態または位置は、時間的決定モデルから決定されることを特徴とする請求項２７に記載の方法。
【請求項３２】
メッセージを搬送するのを容易にするシステムであって、
メッセージに関連するポリシーパラメータと、
前記ポリシーパラメータとメッセージ受信者について決定された状態とに部分的に基づいて、前記メッセージを受信者に送信するかどうかを判定するメッセージ送信または受信コンポーネントと
を備えたことを特徴とするシステム。
【請求項３３】
前記ポリシーパラメータにより、メッセージ送信側は、メッセージ受信側が存在する場合またはメッセージ受信側のビジーまたはフリーポリシーの定義に従ってフリーである場合に、メッセージ受信側まで突破するインスタントメッセージ（ＩＭ）またはメッセージ受信側の注意を引くインスタントメッセージ（ＩＭ）を送信するオプションが可能であることを特徴とする請求項３２に記載のシステム。
【請求項３４】
前記ポリシーパラメータは、メッセージ送信時にデフォルト時間またはフラグに関連付けられることを特徴とする請求項３２に記載のシステム。
【請求項３５】
前記ポリシーパラメータは、対応不可能コンテキストまたは対応不可能パラメータに関連することを特徴とする請求項３２に記載のシステム。
【請求項３６】
前記対応不可能コンテキストは、ｘ分以内にメッセージに応答しない状況、ｘ分を超えてデスクトップでアクティブでなかった状況、少なくとも１つの指定状態にあってビジーである状況のうちの少なくとも１つの状況を含み、ｘは整数であることを特徴とする請求項３５に記載のシステム。
【請求項３７】
前記指定状態は、ｘ分以内に他の誰かとのインスタントメッセージ会話を送信または受信して、他の誰かとのインスタントメッセージが進行中である状態と、フォアグラウンドのアプリケーションの指定を含めたデスクトップ状態とのうちの少なくとも一方を含むことを特徴とする請求項３６に記載のシステム。
【請求項３８】
前記ポリシーパラメータをオーバーライドする例外パラメータをさらに備えたことを特徴とする請求項３５に記載のシステム。
【請求項３９】
前記対応不可能ポリシーは、
インスタントメッセージをｅメールに変換して、前記ｅメールを受信箱に入れること、
自動生成応答で送信側へのインスタントメッセージを生成すること、
前記生成された応答に指定の情報を含めること
のうちの少なくとも１つを含むことを特徴とする請求項３５に記載のシステム。
【請求項４０】
前記自動生成応答はリスト中の人に送信されることを特徴とする請求項３９に記載のシステム。
【請求項４１】
前記自動生成応答は、受信者とｅメールで連絡が取れることを送信側に知らせることを特徴とする請求項３９に記載のシステム。
【請求項４２】
前記自動生成応答は、前記受信者へのカーボンコピー（ｃｃ：）付きでメッセージ送信側宛に自動的に生成され、後でスレッドをｅメール中で継続できるように開始インスタントメッセージが組み込まれることを特徴とする請求項３９に記載のシステム。
【請求項４３】
受信者または送信側の選好に従ってｅメールメッセージから生成されるインスタントメッセージをさらに備えたことを特徴とする請求項４２に記載のシステム。
【請求項４４】
前記ポリシーパラメータはインスタントメッセージ通信またはプッシュツートーク通信に適用されることを特徴とする請求項３２に記載のシステム。
【請求項４５】
前記プッシュツートーク通信は抑制されてローカルバッファ中で保持され、メッセージ受信者が所定時間内にフリーになった場合にレンダリングされることを特徴とする請求項４４に記載のシステム。
【請求項４６】
前記メッセージ受信者が割り当てられた時間内でフリーになれない場合は、メッセージを消去することができ、先のメッセージが届かなかったことを示す自動の録音済みメッセージが送信側に提供され、あるいは、メッセージを後で検討することのできる形式に変換させるオプションが前記受信者または前記送信側に提供されることを特徴とする請求項４５に記載のシステム。
【請求項４７】
受信者が現在ビジーであってメッセージがまだ送達されていないこと、および前記メッセージがレンダリングされたときに知らされることを発呼側に伝える自動録音を返信するポリシーをさらに備えたことを特徴とする請求項４４に記載のシステム。
【請求項４８】
タイムアウトポリシーと、受信者の電話またはアカウントが対応不可能であることに関する可能な自動応答とをさらに備え、メッセージは前記受信者のデバイスまたはサーバによってローカルで保持されることを特徴とする請求項４４に記載のシステム。
【請求項４９】
受信者が対応不可能なためまたは現在の割込みコストのために抑制されていたメッセージを後で検討するのを容易にするための検討コンポーネントをさらに備えたことを特徴とする請求項４８に記載のシステム。
【請求項５０】
前記検討コンポーネントは、送信側と接触するための手動プロセス、または通信コンテキストを再確立するための自動ツールを含むことを特徴とする請求項４９に記載のシステム。
【請求項５１】
前記自動ツールは、受信者が１回押すだけで会話再確立プローブを呼び出せるようにすることを特徴とする請求項５０に記載のシステム。
【請求項５２】
前記プローブは、送信側との会話に立ち返るための通信を含むことを特徴とする請求項５１に記載のシステム。
【請求項５３】
前記プローブは、メッセージの送信側または話題に関係する、情報またはコンテキストを含むことを特徴とする請求項５２に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に、デバイス、システム、プロセス、および／または個人の間の通信を容易にするための、通知を搬送するのを容易にするシステムおよび方法に関する。より詳細には、本発明は、通知が中断を引き起こすのを最小限に抑えるために、様々な通信システムで限度付き延期ポリシーに従って利用されるエンドポイントデバイスをスマート感知する、通知を搬送するのを容易にするシステム、記録媒体、通信を容易にするシステム、通知を搬送するのを容易にする方法、およびメッセージを搬送するのを容易にするシステムに関する。
【背景技術】
【０００２】
人々が世界を感知、記憶、推測する素晴らしい能力にもかかわらず、認識能力は、非常に特徴的な形で極度に制限されている。具体的には、心理学者らは、人々が乏しい注意リソースおよび限られた作業メモリと格闘していることを見出した。このような制限は、人々が短期間で手に余るほどの新しい観念または事項を覚えているように要求されて、事項の背景パターンに対して重要なターゲットを認識するとき、または複数の作業を交互に配置するときに、顕著になる。
【０００３】
これらの結果は、人々が通常、的を限定した注意によって世界を精査しなければならないことを示している。したがって、ほとんどの人はしばしば、何に選択的に注目しているか、およびどのくらい深くフォーカスを合わせているかに関して、暗黙的および明示的に手掛かりを生成する。限られた注意リソースに関する発見は、計算システムおよびインタフェースがどのように設計されるかにとって重大な意味を持つ。注意リソースに関して、電子通信は通常、一方的に伝送され、メッセージの受信側または受信者は、それらの通信を処理することができるかどうかに関係なく、メッセージ送達時に通知を受ける。したがって、例えばインスタントメッセージングでは、送信側が通信したいと思っていることを示すポップアップウィンドウがインスタントメッセージの受信側に提供される。しかし、このタイプの割込みは、受信者がこのようなメッセージの受信に対応できるかどうか、または現在の会話への参加に対応できるかどうかを考慮しない。
【０００４】
いくつかの文献に上述のような従来の技術に関連した技術内容が開示されている（例えば、特許文献１参照）。
【０００５】
【特許文献１】米国特許第５、４９３、６９２号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００６】
従来のシステムには上述したような種々の問題があり、さらなる改善が望まれている。
【０００７】
本発明は、このような状況に鑑みてなされたもので、その目的とするところは、フリー時メッセージングによってデバイス、システム、プロセス、および／または個人の間の通信を容易にする、通知を搬送するのを容易にするシステムおよび方法を提供することにある。
【課題を解決するための手段】
【０００８】
以下、本発明のいくつかの態様に関する基本的な理解を提供するために、本発明を簡略化した概要を提示する。この概要は、本発明の広範な概観ではない。この概要は、本発明の鍵となる／クリティカルな要素を識別するものでもなく、本発明の範囲を表すものでもない。この概要の唯一の目的は、本発明のいくつかの概念を、後で提示するより詳細な説明への前置きとして、単純化した形で提示することである。
【０００９】
本発明は、メッセージ送信側と受信側との間の通信が立ち入りすぎるのを緩和し、より礼儀正しくシームレスで適時の対話を容易にするためのシステムおよび方法に関する。一態様では、インスタントメッセージングおよびその他の形の通信を、時間限度付きポリシーおよびパラメータを利用することによって改善することができる。例えば、インスタントメッセージングの使用に伴う問題の１つは、インスタントメッセージを受け入れる準備ができていないかもしれない受信者に対してこのようなメッセージングが中断を引き起こす可能性があることである。フリー時（Ｗｈｅｎ−Ｆｒｅｅ）メッセージングにより、ユーザはフリー時メッセージを送信することができ、フリー時メッセージは、ユーザまたは受信者がビジー状態として定義された状態のリストのうちの１つでなくなるまで待機する、インスタントに近いメッセージとして働く。送信側は、メッセージが消去または撤回される前にどのくらい長く生存しているべきかを、素早いジェスチャーまたは固定プロファイルによって符号化することができ、それにより送信側は、例えば「Ｗｈｅｎ  Ｆｒｅｅ：こんにちは。昼食を食べに行きませんか（生存時間（ＴＴＬ）：１０分）」というメッセージを送信することができる。したがって、メッセージは、受信者がＴＴＬ（time to live；生存時間、有効期間、有効期限）範囲内でフリーになった場合にだけ届くことになる。
【００１０】
メッセージがレンダリングされたときは、任意選択でメッセージ受信済み確認を送信することができ、あるいは、メッセージの寿命が尽きるまでにメッセージが受信者に届かなかった場合は、メッセージがタイムアウトして消去されたことを知らせる通知を送信側に送信することができる。受信者は、望むなら、タイムアウト間近のメッセージはタイムアウトするのではなく受信側まで突破（break through）できることを指定することができ、また、保留状態の対応可能性ステータスがフィードバックとしてメッセージ送信側に送信されるようにすることができる。インスタントメッセージングおよびその他の通信形式のフリー時プロセスは、メッセージングに関して礼儀正しくする方法をもたらすので、インスタントメッセージを他者に、特に送信側がよく知らないかもしれない人に送信することに対する障害を低くするのを容易にする。フリー時手法はまた、例えばｅメールや音声メールなど、他の通信媒体にも適用することができる。
【００１１】
本発明は、重要なメッセージまたは伝達を通信するのを容易にするためのシステムおよび方法に関する。メッセージ送達の最終期限内で最良の時を決定する際に、推論された割込みコスト、またはそのようなコストに代わる直接感知されたものを考慮することを含めて、ユーザの現在状況を考慮するポリシーについて述べる。送達の最終期限は、メッセージの送信側、タイプ、内容から推論または検出された、情報の緊急性によって決まる。適した時が最終期限内で検出されない場合は、情報は最終期限時に送達される。適した時が最終期限内で達成されないと判定された場合は、情報はすぐに送信される。送達に適した時は、加速度計、マイクロホン、タッチ感知、視線および頭部姿勢の検出を含めて、１つまたは複数のセンサをエンドポイントデバイス上またはその付近で使用することによって決定することができる。ユーザのカレンダ上に示されたアポイントメントステータス、時刻、前にアクセスされた対応可能性パターンを含めて、その他の情報も、アラートの延期に関する決定で利用することができる。エンドポイントセンサ、カレンダ情報、対応可能性パターンはまた、情報がデバイスにおいて受信される可能性を識別するのにも使用される。このような情報は、直接にまたは要約として中央通知マネージャに返すこともでき、あるいはアラートの特徴および繰返しを決定する際にローカルで使用することもできる。
【００１２】
本発明の特定の一態様は、通知に関連して中断が引き起こされることを緩和することによって、当事者間における効率的で適時の通信を容易にするシステムおよび方法に関する。本発明の特定の一態様は、小型デバイス（例えば電話機、ＰＤＡ、スマートペン、腕時計、アイウェア）を、メッセージ通知および／または最良モードと共に利用して、通信を実施することに関する。本発明によれば、小型デバイスは、ユーザの注意ステータスおよび／または位置に関係する様々なメトリクスがわかっているか、少なくとも部分的にわかっているものとすることができる。注意ステータスおよび／または位置に関して小型デバイスによって決定および／または推論された情報は、小型デバイス間で、ならびに異種デバイスまたはシステム（例えば中央通知管理システム）と共有することができる。この情報は、他のデバイスに対して個別にあるいは直列または並列で広めることができ、また集約することができる。この情報を利用して、通知サービスの提供を容易にすることができ、かつ／あるいは、ユーザとの通信およびユーザ間の通信を実施するのに最良なモードを決定または推論するのを容易にすることができる。
【００１３】
例示的な一態様では、メッセージ特有の最終期限に達する前に受信したメッセージを中継することをローカルデバイスが約束するという、限度付き延期ポリシーを採用することができる。本発明によるデバイスは、割り当てられた期間内で割込みに最適な時を決定または推論しようと試みる。このような決定または推論は、統計ベース、および／または確率ベース、および／または効用ベース（例えば割込みコストが与えられた場合の割込み利益）の技法を利用することができる。本発明によるデバイスは、ユーザの注意ステータスおよび／または位置を学習または推論することに関して、様々な感知モダリティ（例えばＭＥＭＳベースのセンサ、温度センサ、加速度計、ジャイロスコープ、光ベースのセンサ、時間ベースのセンサ、ＧＰＳ、８０２．１１信号強度、赤外線近接検出器、タッチセンサなど）を利用することができる。感知された状態の共有および／または送信については、感知された状態のすべて、またはそのサブセット、または要約を通信することができることを理解されたい。
【００１４】
本発明の別の態様では、デバイスの状態ならびに周囲環境も考慮に入れることができる。例えば、デバイスの伝送信頼性（ｔｒａｎｓｒｅｌ）を考慮することができる。（例えば、Ｐ（ｔｒａｎｓｒｅｌ｜ｃｏｎｔｅｘｔ）を表すスライディングスケール上で。これは、コンテキスト（例えばｆ（コンテキスト）やｆ（感知された状態）などの関数）が与えられた場合にデバイス上で届く尤度である。）
前述および関連の目的を達成するために、本明細書では、本発明のいくつかの例示的な態様を以下の記述および添付の図面に関して述べる。これらの態様は、本発明を実施することのできる様々な方法を示し、これらはすべて本発明によってカバーされるものとする。本発明の他の利点および新規な特徴は、本発明に関する以下の詳細な説明を図面と共に考察すれば明らかになるであろう。
【発明の効果】
【００１５】
本発明によれば、フリー時メッセージングによってデバイス、システム、プロセス、および／または個人の間の通信を容易にすることができる。
【発明を実施するための最良の形態】
【００１６】
以下、図面を参照して本発明を適用できる実施形態を詳細に説明する。
【００１７】
本発明は、ユーザのコンテキストを考慮することに基づいて当事者間の通信を容易にするためのシステムおよび方法に関し、コンテキストは、ユーザのディジタルカレンダ上に符号化されたユーザのアポイントメントステータスや、デバイス上またはその付近のセンサを介してローカルで感知された情報など、背景情報を含むように取り込まれる。メッセージ受信側の対応可能性に基づいて（例えば限度付き延期ポリシーに基づいて）、本発明は、メッセージが受信されるのに好ましい時間範囲（ｔｉｍｅ  ｈｏｒｉｚｏｎ）をメッセージ送信側が符号化することのできるフリー時メッセージングアーキテクチャを提供する。メッセージが受信側の対応可能性により時間範囲内に受信されなかった場合、メッセージは、メッセージ割込みで受信側を煩わせる前に、自動的に撤回されるものとすることができる。ステータスを双方向に交換して、それ以上の通信も容易にすることができる。
【００１８】
上述のフリー時アーキテクチャは、電子テキストメッセージならびに従来のアナログ通信を含めたほぼ任意のタイプのメッセージングに関して、いくつかの通信シナリオまたは適用例をサポートできることに留意されたい。例えば、送信側によって誘導される「フリー時」メッセージングのシナリオの１つでは、礼儀正しさに対する責任は送信側の責任である。すなわち、受信者が存在する場合にだけ、または受信者が自身のビジー／フリーポリシーの定義に従ってフリーである場合にだけ、受信者まで突破するインスタントメッセージ（ＩＭ）または受信者の注意を引くインスタントメッセージ（ＩＭ）を送信するオプションが、送信側に可能である。したがって、ＩＭには、失効するまでに存在する時間が、例えばデフォルトとして（例えば５分）または特別に設定されたフラグとして、送信時に与えられる。以下にいくつかの可能な例を示す。
【００１９】
Ｗｈｅｎ  Ｆｒｅｅ「リック、昼食を食べに行きませんか？」−＞失効１５分。この例では、ユーザがメッセージを見なかった（例えば不在だった）場合またはビジー状態のままだった場合、メッセージは完全に消滅する（ユーザまで突破せず、送信されたことも示されない）。このように、フリー時メッセージングは、他者にＩＭを送信する際に人々が気分良く感じることに対する障害を低くすることができる。
【００２０】
別の適用例では、受信側によって定義されたポリシーを利用することができ、失効したＩＭとｅメールとの間のリンクを提供することができる。この状況では、入来インスタントメッセージを処理するためのポリシーが受信側によって定義され、受信者がたまたまビジーまたは不在であったときにＩＭを処理する単純なポリシーが可能になる。これは、送信側によるＩＭの開始に受信者が対応できない状況、または、例えば、ユーザがビジーになったり、別のユーザとのインスタントメッセージングセッションに携わることになったり、立ち去ったりしたせいで、確立されたが決着のついていないＩＭのやりとりの最後（長い休止があるなど）に受信者が対応不可能になる状況を取り込む。
【００２１】
これらの状況では、ユーザは例えば以下のように指定することができる。
１．私の「対応不可能（Unavailable）」コンテキスト
例：私は次のいずれかの場合は対応できません。
ｘ分以内にＩＭに応答しない場合。
ｘ分を超えて私のデスクトップでアクティブでなかった場合。
次の状態例のうちの１つにあってビジーである場合：
他の誰かとのＩＭが進行中である（ｘ分以内に他の誰かとのＩＭ会話を送信または受信した）状態。
デスクトップ状態（フォアグラウンドのアプリケーションを指定する。例えばＯｕｔｌｏｏｋでｅメール作成中、Ｐｏｗｅｒｐｏｉｎｔ表示モードでアクティブ、Ｅｘｃｅｌでアクティブなど）。
許容される例外：
ユーザは例外を指定することができる。
例：次のユーザはビジー状態を無視することができます。特別リスト＝｛スティーブ、スミス、マイクジョーンズ、私の配偶者、重要な仲間リスト、私が今日ＩＭ通信した人、私が今日ｅメールを送信した人など｝
【００２２】
２．私の「ＩＭ対応不可能ポリシー」
私が対応できない場合（例えば上記からの「ｘ分以内にＩＭに応答しない場合」「ｘ分にわたって私のデスクトップでアクティブでなかった場合」など）、またはビジー状態（単純な状態リストで定義される）のうちの１つにある場合は、（例示的なポリシー）：
［  ］ＩＭをｅメールに変換して私の受信箱にこのｅメールを入れる。
［  ］自動生成応答で送信側へのＩＭを生成し、私がＩＭの閲覧や応答に対応できないことを伝える。
［  ］以下の情報を（ＩＭまたはｅメールの自動応答に）含める：
ユーザのＩＭ対応不可能ポリシーの一部として、受信者は、全員、または選択された人／グループ（例えばユーザのＩＭ対応不可能通信ホワイトリストからの）に対して、自動応答メッセージを指定することができる：
例：自動応答ｅメールまたはＩＭ応答は、ｔｉｍ＠ｈｏｔｍａｉｌ．ｃｏｍにｅメールを送信することによって受信者と連絡が取れることを、送信側に伝える。
【００２３】
あるいは別法として：
［  ］ＩＭをｅメールスレッドに変換し、私へのｃｃ：付きで、ＩＭメッセージを私から送信側へのｅメールに組み込む。
［  ］以下の情報を（ＩＭまたはｅメールの自動応答に）含める：
すなわち、受信者は、全員または何人か（通信ホワイトリストに従う）に対して、送信側へのｅメールが受信者へのｃｃ：付きで自動的に生成されるよう指定することができ、このｅメールには、受信者または送信側の選好に従って後でこのｅメールメッセージからすぐにスレッドをｅメールまたはＩＭ中で継続できるように、開始ＩＭが組み込まれる。この手法は常に、ＩＭビジー状況を、後でｅメールまたはＩＭ中で続けることのできるｅメールに移行する。（ｅメールを読む時点で、メッセンジャーの存在ステータスに従って、ＩＭに対するユーザの現在対応可能性を適所に表示することができる。）これにより、ＩＭとｅメールとの好適な網目組織が可能になり、モードを移行することまたは後でＩＭを再確立することが可能になる。また、対応不可能性とアクションポリシーとに関する一様なポリシーが、（例えば後で）特別な「ホワイト通信リスト」（同僚リスト）を導入し、選択的な対応不可能性（例えばその他の人に対して）およびアクションポリシーを指定する。
【００２４】
別の適用状況では、同様のフリー時ポリシー（送信側指示ポリシーと受信側定義ポリシーの両方）をプッシュツートーク（ｐｕｓｈ−ｔｏ−ｔａｌｋ）シナリオで適用することができる。プッシュツートークは普及しつつあるが、通信の両側で（受信側による誘導と送信側による誘導で）、ＩＭと同様の問題を被る。具体的な例では、第１の建設業者がプッシュツートーク通信デバイスを利用して別の仕事場にいる別の業者に話し、通信者が両方ともビジーになる場合を考えてみる。第１の業者がビジーの場合、例えば他の誰かと話している場合に、フリー時方法をいくつかの方式でサポートすることができる。ある手法では、プッシュツートークメッセージのレンダリングは抑制されてローカルバッファ中で保持され、所定時間内に受信側業者がフリーになった場合にレンダリングされる。割り当てられた時間内に送信できない場合は、メッセージは消去することができ、先のメッセージが届かなかったことを送信側に知らせる自動の録音済みメッセージが送信側に返され、かつ／または、メッセージを後で検討することのできる形式（例えばｅメール中のメディア抜粋や、「今日、サムとの会話の最後にこのメッセージを聞き逃しました」という受信箱中の音声メールなど）に変換させるオプションが、受信者（事前定義済みポリシーに従って）または送信側に与えられる。
【００２５】
別の手法では、受信者は、時間が経てばメッセージが消去されるようにするのではなく、自分が現在ビジーであってメッセージがまだ送達されていないことを送信側に伝える自動録音を返信するポリシーを設定することができ、メッセージがレンダリングされたときに知らされることを発呼側に伝える。
【００２６】
別の手法では、タイムアウトした後、さらに場合によっては受信者の電話機またはアカウントが対応不可能であることに関する自動応答が送信された後、受信者のデバイスまたはサーバがメッセージをローカルで保持しておくことができる。受信者は後で、受信者が対応不可能なためまたは現在の割込みコストのために抑制されていたメッセージを検討することができ、次いで、前の会話の相手にかけ直すことによって手動で応答するか、またはコンテキストを再確立するための自動ツールを介して応答することを決定することができる。このような自動ツールは、容易なコンテキスト再確立ツールを提供することができる。例えば、受信者が１回押すだけで、会話再確立プローブ「［録音音声］：次の件に関するロバートとの会話に戻ります［サムからの録音］：「ロバート、赤セラミックでいくべきだと思うよ！」」を呼び出せるようにするツールなどである。この時点で、ロバートとサムは会話を再開することができる。
【００２７】
本明細書で使用する用語「コンポーネント」「サービス」「モデル」「システム」は、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、実行中のソフトウェアのいずれかであるコンピュータ関連エンティティを指すものとする。例えばコンポーネントは、限定しないが、プロセッサ上で実行されるプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行のスレッド、プログラム、および／またはコンピュータとすることができる。例として、サーバ上で実行されるアプリケーションもサーバも両方とも、コンポーネントとすることができる。１つまたは複数のコンポーネントが１つのプロセスおよび／または実行スレッド内にあるものとすることができ、また、１つのコンポーネントが１つのコンピュータ上に局所化されてもよく、かつ／または、複数のコンピュータ間で分散されてもよい。
【００２８】
本明細書で使用する用語「推論」は、一般に、システム、環境、および／またはユーザの状態を、イベントおよび／またはデータを介して取り込まれた観察のセットから推測または推論するプロセスを指す。推論は、特定のコンテキストまたはアクションを識別するのに使用することができ、あるいは、例えば複数の状態にわたる確率分布を生成することができる。推論は確率的とすることができる。すなわち、データおよびイベントの考慮に基づいた、当該の複数の状態にわたる確率分布の計算とすることができる。推論はまた、決定論的または論理的な推測技法を指すこともでき、イベントおよび／またはデータのセットからより高レベルのイベントを構成するのに利用される方法が含まれる。このような推論の結果、イベントが時間的に近接して相関していようとそうでなかろうと、またイベントおよびデータの出所であるイベントソースおよびデータソースが１つであろうと複数であろうと、観察されたイベントおよび／または記憶されたイベントデータのセットから新しいイベントまたはアクションが構築される。
【００２９】
最初に図１を参照すると、システム１００は、本発明の一態様による「フリー時」アーキテクチャを示している。システム１００は、エンドポイントデバイス１２０にいる受信者にメッセージを送信するメッセージ送信コンポーネント１１０を備える。メッセージ送信コンポーネント１１０には、インスタントメッセージングシステム、電話機またはセルホン、ｅメール、音声メールなど、ほぼ任意の通信デバイスまたはコンポーネントを含めることができる。本発明により送信されるメッセージは、メッセージが受信者のデバイスまたはコンポーネント１２０にいつどのように送信または伝送されるか、ならびに送信または伝送されるかどうかを制御するための、１つまたは複数のプロパティを含む。一態様では、メッセージは、１３０に示すように生存時間（ＴＴＬ）プロパティ付きで送信することができる。ＴＴＬプロパティは、メッセージが実際にユーザに割り込まないよう撤回される前に送信側がメッセージをどのくらい長く（例えばクライアントまたはサーバの一時メッセージキュー中で）アクティブにしておくつもりであるかを指定する。例えば、ユーザは送信デバイス１１０で、「あと１０分でミーティングに出られますか？」というメッセージを送信することができる。このメッセージに関連して、ユーザは１０分のＴＴＬパラメータを構成することができ、これはメッセージと共に送信される。このような構成はユーザインタフェース１４０を介して達成することができ、ユーザインタフェース１４０はメッセージの作成にも利用することができる。あるいは、メッセージが撤回前にどのくらい長くアクティブであるべきかについて、メッセージが音声キューまたはテキストキューに対して自動的に分析されるものとすることもできる。
【００３０】
前の例を参照すると、ユーザが上のミーティングメッセージを１０分以内に受信するのに対応できない場合、ミーティングに関するこのメッセージは、メッセージのユーザまたは意図された受信者に割り込むことなく自動的に撤回されるものとすることができる。意図された受信者がメッセージ受信に対応できるかどうかは、受信側のカレンダから得られる情報など、複数の異なるプロセスで判定することができる。一態様では、メッセージ受信者が対応できる期間を決定する限度付き延期コンポーネント１５０が、エンドポイントデバイス１２０に関連している。したがって、上の例の場合、限度付き延期コンポーネント１５０は、ユーザがあと５分でメッセージの受信に対応できると判定することができる。メッセージはその指定ＴＴＬ期間（例えば１０分）を超えるまでは受信可能なままなので、５分の期間の終わりに、ユーザは上の例示的なミーティングメッセージを受信することになる。あるいは、受信者はＴＴＬ期間よりも長い期間にわたって対応不可能だと判定される。後でより詳細に述べるように、メッセージ送信側と受信側の間で様々なステータス情報を交換して、送信されるメッセージの成功または失敗の可能性、ならびに邪魔にならない通信のためのその他の指示を示すことができる。
【００３１】
図２を参照すると、システム２００は、本発明の一態様による例示的なステータス交換を示している。図１に関して上述したように、フリー時メッセージングにより、ユーザはフリー時メッセージを送信することができ、フリー時メッセージは、ユーザまたは受信者がビジー状態として定義された状態のリストのうちの１つでなくなるまで待機する、インスタントに近いメッセージとして働く。送信側は、メッセージが消去または撤回される前にどのくらい長く生存しているべきかを、素早いジェスチャーまたは固定プロファイルによって符号化することができ、それにより送信側はメッセージを送信することができる。これを２１０に示すが、送信デバイスは、符号化された１つまたは複数のパラメータを有するメッセージ２２０を送信する。例えば、メッセージ２２０は、Ｗｈｅｎ  Ｆｒｅｅ：「こんにちは。昼食を食べに行きませんか」（生存時間（ＴＴＬ）：１０分）のように見えるものとすることができる。したがって、メッセージ２２０は、受信者がＴＴＬ範囲内でフリーになった場合にだけ届くことになる。メッセージが受信デバイス２４０からレンダリングされたときは、任意選択で、２３０でメッセージ受信済み確認を送信することができ、あるいは、メッセージ２２０の寿命が尽きるまでにメッセージ２２０が受信者に届かなかった場合は、メッセージがタイムアウトして消去されたことを知らせる通知２５０を送信側２１０に送信することができる。
【００３２】
受信者は、望むなら、受信デバイス２４０を介して、タイムアウト間近のメッセージはタイムアウトするのではなく受信者まで突破できることを指定することができ、また、保留状態の対応可能性ステータス２６０がフィードバックとしてメッセージ送信側に送信されるようにすることができる（例えば「あと１５分でメッセージに対応できるようになります」）。受信者が受信デバイス２４０を突破メッセージ対応として構成した場合は、例えばメッセージの優先度が十分に高い場合または選択された送信側サブセットからのメッセージである場合に、２７０で代替提案、例えば「あと２０分で会えます」を送信することができる。パラメータ化されたメッセージ２２０に加えて、送信デバイス２１０は２８０で、誰が受信者と接触を試みているかもしれないかについての細かい手掛かり（例えばインスタントメッセージがキュー中にあることを示す送信側の画像またはテキスト）を送信することもできる。アクティビティログ２９０を提供することもでき、メッセージ受信者は、送信されたメッセージの量、メッセージ内容、通信を試みたが失敗したかもしれないメッセージ送信側の識別を示すログファイルを定期的にチェックすることができる。これはまた、失敗した通信の試みだけでなく成功した通信の試みも含めて、すべてのメッセージアクティビティをログすることを含むことができる。
【００３３】
次に図３を参照すると、システム３００は、本発明の一態様によるエンドポイントデバイス通信を示している。１つまたは複数のエンドポイントデバイス３１０が、１つまたは複数のセンサ３１４（例えば運動、近接）および限度付き延期データ３２０に関連付けられて、ユーザとの通信を容易にする。限度付き延期データ３２０は通常、様々な通知ソース３３４からエンドポイントデバイス３１０に通知をルーティングする通知マネージャ３３０によって決定および生成される。本発明によりエンドポイントデバイス３１０が限度付き延期データ３２０を決定することもできることに留意されたい。
【００３４】
エンドポイントデバイス３１０に対する限度付き延期データ３２０は、延期期間と呼ばれる許容期間を考慮して決定され、延期期間は一般に、通知送信側および／または送達されるメッセージのタイプに応じたものである。メッセージがエンドポイントデバイス３１０によって受信されると、デバイスはそのセンサ３１４をローカルで利用して、指示された限度付き延期期間内でユーザにアラートするのに適した時を決定する。通常、メッセージが緊急であるほど延期期間は短い。例えば、通知マネージャ３３０は、通知ソース３３４からメッセージを受信したところであり、限度付き延期データ３２０によって指定された限度付き延期期間に従ってメッセージを送達しようとする。通常は、通知マネージャ３３０は、通知ルーティングに関する一般的な決定を行い、エンドポイントデバイス３１０に依拠して、決定された延期期間内で実際にメッセージをユーザに送達する。しかし、エンドポイントデバイス３１０は、ユーザが現在精力的なアクティビティに携わっていることを検出する（例えば加速度計が高速運動を示す）。そのため、限度付き延期データ３２０によって定義されたようにメッセージ送達の最終期限が近づいているにもかかわらず、エンドポイントデバイス３１０は、検出されたユーザのアクティビティまたは注意状態に基づいてメッセージの送達を遅延させることができる。
【００３５】
限度付き延期は一般に、ユーザにとって価値のある情報を含むメッセージをユーザに気付かせるための最終期限を指定する限度付き延期許容範囲がローカルでまたは中央でメッセージに割り当てられるという概念に関係し、延期の許容範囲は情報の緊急性によって決まることに留意されたい。また、後でより詳細に述べるように、エンドポイント感知が与えられた場合にメッセージがユーザに届く確率、および／または背景情報が与えられた場合の推定値に関係する、ローカルで感知された情報に場合により基づいて、伝送信頼性を考慮することもできる。
【００３６】
ローカルセンサ、カレンダ情報、アラートタイプ、および／または時刻によって限度付き延期パラメータを決定して、例えば、ユーザが忙しくてアラートを今または次のｘ分で受信できないことを判定することができる。最終期限に達し、アラートがまだ送達されていない場合は、最終期限で送達される。最終期限を過ぎるのが確実であり（例えばカレンダ情報から判定される）、「よりよい時」を待機する意味がない場合は、待機しても得られるものがないのでアラートはすぐに実施される。
【００３７】
ユーザが現在ビジーである時やユーザがメッセージの受信に対応できる時を決定するなど、様々な決定にセンサを利用することができる。センサはまた、伝送信頼性がどのくらいかを我々に示すこともできる。このようなセンサ情報は、中央通知マネージャ、例えばどこにメッセージを送信するかを検討している一般通知プラットフォームに直接渡すこともでき、あるいは別の適用例では、エンドポイントデバイス自体がそのセンサから伝送信頼性（ｔｒａｎｓｒｅｌと略す）を計算し、要約された伝送信頼性を中央通知マネージャに返し、中央通知マネージャがこれをその検討で考慮することもできる。例えば、セルホン上の温度センサが、セルホンが現在まさにユーザのポケット中にあることをセルホンに対して示すことができ、したがって、ユーザに届くようにセルホンを振動させるかベルを鳴らすことに対する高いｔｒａｎｓｒｅｌがある。
【００３８】
本発明の会話ダイアログシステムまたは態様の１つでは、限度付き延期の概念を使用して、対話式ダイアログ実施システムが会話を開始できるようにするか、またはユーザの注意が作業または別の会話のためにどこかに逸れたことによって中断した会話を継続できるようにすることができる。例えば、自動システムがユーザと共に作業に取り組んでおり、誰かが戸口に入ってきてユーザと話すことでダイアログが中断された場合、システムは、ダイアログを継続する時間クリティカル性に応じて、待機していくらかの時間量だけ前から継続すること、および謝って割り込んで継続することができる。
【００３９】
限度付き延期は、ユーザ体験の多くの面にリンクさせることができることに留意されたい。例えば、限度付き延期ポリシーをカレンダ情報にリンクさせることができ、アポイントメントは、ユーザの対応可能性に対する決定性限度と見なされる（例えば「ユーザのアポイントメントはあと１０分で終わる。したがって待機してもよい」と、これに対して「ユーザのアポイントメントはあと２０分で終わる。アポイントメントまたは作業の終了は延期許容範囲よりも後になる。したがって単純に割り込んでユーザにすぐアラートするのが最良である」）。カレンダ情報の他に、コンピューティングシステムは、他の作業の継続時間に関する情報にもアクセスすることができる。例えば、ユーザがメディアを見ているコンテキストで、所定の長さの作業が利用可能な場合がある（例えばユーザが見ている映画や再生があと７．５分で終わる、コマーシャル中断があと１４分で来る、など）。
【００４０】
同様に、ユーザは、時刻および曜日に基づいて、自分の対応可能性に関する様々なオプションを指定することができる（例えばユーザは、通知マネージャ中で符号化される選好において「アラートに関連する延期許容範囲に従った最終期限に達しない限り、午前８時以前および午後１１時以降はアラートを中継しないで下さい」と指定することができる）。したがってシステムは、可能なら、待機してアラートを好ましい期間（例えば午前８時と午後１１時の間）まで遅らせるよう試みることが課されるものとすることができる。しかし、待機できない場合は他の時に突破することになる。また、限度付き延期ポリシーは、アラートのタイプによって決まるものとすることもできる（例えば、デバイスはすぐに穏やかに振動することができるが、延期許容範囲に達する前に確認がない場合は、デバイスは大きい音でユーザにアラートする）。
【００４１】
別の手法では、延期許容範囲に達したときに突破するのではなく、エンドポイントデバイスは、中央通知マネージャまたはアラート送信側にメッセージを返信して、デバイスがメッセージの中継に失敗したことを通知マネージャに通知するように命令されるものとすることができる。
【００４２】
通知マネージャ３３０およびエンドポイントデバイス３１０は、通知をユーザに誘導するかまたは割り込ませるとき、決定理論的手法を採用することができることに留意されたい。これについては後でより詳細に述べる。大域的な限度付き延期ポリシーは、より詳細な決定理論的分析の近似と見なすことができる。詳細な決定理論的分析では、アラートは、各メッセージおよびコンテキストごとにアラートの詳細なコストと利益を考慮して、ケースバイケースで処理される。限度付き延期ポリシーは、様々な緊急性のメッセージに対する総遅延の限度、したがって時間に伴う情報価値の総損失の限度を指定することを可能にする。メッセージがユーザまで突破するときなどに複数メッセージ対話を考慮するとき、他の当事者も、自分だけではユーザまで突破しなかったであろう場合でも到達できるものとすることができる。一例では、より短い延期をもたらす複数メッセージの価値、例えば独立した複数のメッセージの価値の価値合計（または他の関数）を決定することができる。
【００４３】
また、まだ達していない比較的長い延期許容範囲（時間クリティカル性が低いため）を有するいくつかのメッセージを出し控えていたシステムは、より短い延期許容範囲を有するより時間クリティカルなメッセージがユーザまで突破するときに、これらのよりクリティカル性の低いメッセージも伝えることができる。このような突破に情報伝達コストのほとんどがかかる場合があり、それにより他のメッセージは低インクリメントのコストで通過することができる。例えば、ある人へのミーティングリマインダに関するアラートが、このユーザの現在位置およびミーティング位置に基づいて、ユーザが予定されたミーティングまで移動するのに十分な時間を伴って突破する場合を考えてみる。突破時、追加メッセージを受信するコストは最初の突破コストよりもそれほど大きくない場合がある。そのため、システムはユーザに、メッセージ「あと２０分でベルビューのダブルツリーホテルでミーティングがあります」をアラートすることができ、このアラートがレンダリングされ処理された後、より時間クリティカル性の低いメッセージ「ついでに伝えておきますが、明日はスティーブンの誕生日で、来週ジョージョーンズが町に来ます」をユーザに伝えることができる。
【００４４】
通知をユーザにルーティングするために、通知マネージャ３３０および／またはエンドポイントデバイス３１０は、ユーザ状態（例えば注意状態、忙しさ）を推測するための１つまたは複数のモデルを備えることができる。このようなモデルには、例えばベイズネットワーク、ナイーブベイズ分類器、および／またはサポートベクターマシン（ＳＶＭ）などのベイズ依存モデルを生成することのできる、ベイズ学習の使用を含む統計／数学モデルやプロセスなど、ほぼ任意のタイプのシステムを含めることができる。その他のタイプのモデルまたはシステムには、例えばニューラルネットワークや隠れマルコフモデルを含めることができる。本発明により、精巧な推測モデルを採用することができるが、その他の手法を利用してもよいことを理解されたい。例えば、より徹底した確率的手法ではなく、決定論的仮定を採用することもできる（例えば、Ｘ時間量にわたってセルホンアクティビティがない場合、規則としてこれは、ユーザが電話で対応できないことを意味するものとすることができる）。このように、後でより詳細に述べる不確定性の下での推測に加えて、ユーザおよび／または関連デバイスのステータス、位置、コンテキスト、フォーカスなどに関して論理的決定を行うこともできる。
【００４５】
次に図４を参照し、図４００に、本発明の一態様による例示的な限度付き延期ポリシーを示す。この態様によれば、通知またはメッセージは通常、時間限度が検出されない限り、対応可能なフリー状態に達するまで送達されない。例えば、参照番号４０２および４０４にフリー状態を示す。ユーザのビジー状態の間（フリー状態４０２、４０４の反対として示す）、優先度の高いメッセージ４０６および低いメッセージ４０８が、通知エージェントまたはマネージャ（図示せず）によってキューに入れられる。４１０で、優先度の高いメッセージの最大延期時間に設定された時間限度に達し、そのため、優先度の高いメッセージは４１２でユーザに送達される。優先度の低いメッセージ４０８は、図４に示す例では時間限度に達しない。そのため、優先度の低いメッセージは、４０４で次の対応可能フリー状態になるまで送達されない。このようにして、ユーザによって受信される通知が中断を引き起こすのが緩和される。時間限度は、作業負荷、受信したメッセージの数、通知内容の時間依存性など、ユーザのコンテキストの影響を受ける可能性があることに留意されたい。
【００４６】
本発明によれば、デスクトップおよびエンドポイントデバイスのアラートのために、様々なアルゴリズムおよび／またはプロセスが提供される。これらのプロセスは、（１）ユーザがデスクトップまたはエンドポイントデバイスにいる状況、（２）ユーザがデスクトップまたはエンドポイントデバイスから離れている状況、（３）ユーザがデスクトップまたはエンドポイントデバイスから離れていた後で、戻ったかまたはログインしたところである状況など、複数の状況に適用することができる。
【００４７】
ユーザがデスクトップまたはエンドポイントデバイスにいることが検出された場合、以下のプロセスを一般に適用することができる。
１．通知が受信されると、その古さが０に設定され、その優先度が認識され、例外のリストがチェックされる。
２．その緊急性に対する最大延期時間の前に、ユーザのアクティビティを監視することによって「対応できる可能性が高い」状態が観察された場合、通知はユーザまで通過する。
３．そうでない場合は、通知は、図４に関して上述したように通知の延期許容範囲に達したときに中継される。
【００４８】
平均して、通常のデスクトップまたはエンドポイントデバイスアクティビティの間は、一般に「対応できる可能性が高い」状態が少しはあるため、ほとんどの通知は最大延期時間よりも前に送達される傾向があることになる。しかし、ユーザがフリーの時に通知が行われる傾向がより高いので、通知が受信された時に単純にユーザまで通過する場合よりも、ユーザは平均して通知システムに対してより満足するあろう。対応できる可能性が高い状態を検出する機会は時間量の増加に伴って多くなるので、フリー状態に達する確率は一般に、時間に伴って高くなる。フリーの可能性が高い状態の確率が時間量の増加に伴って高くなるので、これらのフリーの可能性が高い状態の間、優先度のより低いメッセージが生じる可能性がより高くなる傾向があり、メッセージの優先度が高くなるにつれて、中断される確率も高くなる。
【００４９】
本発明の別の態様によれば、通知の表示（例えばジャーナル、ブラウザ、受信箱、セルホンメッセージボックス）は、待機していた複数のまたはプールされた通知を含むことができ、それにより、グループ化された通知のチャンクを含む単一の通知をユーザに送信することができる。このようなチャンク化は、通知のチャンクを、最高優先度、最高の古さ、グループの最高優先度などで順序付けられたリストで提示することができる。例えば、フリーの可能性が高い状態が検出されていない場合であって、しかも優先度の高い通知によって最大延期時間が達した場合、優先度の高い通知の最大延期時間に達したときは、グループ化された通知の中で保留されているより低い優先度の通知がこの時点で関連の最大延期に達してなくても、これらのより低い優先度の通知に関する情報も含めることができる。この種のチャンク化には、主要アラートを標準的な通知表示で送信して、他の保留中のアラートを表示の下部にリストで要約することを含めて、いくつかの態様が可能である。ユーザはそれぞれの項目をクリックして、検討および／またはクリアすることができる。
【００５０】
本発明の別の態様によれば、即座通過のマークが付いた通知の場合を除いては割り込まれるべきでない（例えば、いずれかの安全な時点まで、ミーティング終了後１０分）割込み不可能なミーティング（例えばプレゼンテーション、ビデオ会議、電話ミーティング）をユーザが指定できるようにするために、カレンダを調べることができる。これは、重要なミーティングには別個の最大延期テーブルおよび／または関数を利用することに一般化することができる。これはさらに、カレンダ項目をいくつかのアポイントメントクラスの１つとし、異なるミーティングクラスに対して異なる最大延期テーブルまたは関数を採用できるようにすることによって、一般化することができる。
【００５１】
本発明の別の態様では、いくつかの優先度カテゴリを提供するのではなく、緊急性スコアに対して０〜１００などの連続的な範囲を提供することができ、最大延期は、様々な線形および非線形関数を含めて、通知の優先度の関数とすることができる（例えば優先度の増加に伴って最大延期時間が指数関数的に減少する）。例えば以下のとおりである。
最大延期（優先度）＝ｅ−ｋ（優先度）×１５分
【００５２】
これは以下と等価である。
最大延期（優先度）＝ｅ−ｋ（優先度）×最大延期（０優先度）
【００５３】
さらに、ユーザは、日のタイプ（例えば週末、休日、平日）や時刻に応じたコンテキスト、ならびに、様々なクラスおよびサブクラスのメッセージ（例えば家族からと、それに対する仕事仲間からのｅメールおよびインスタントメッセンジャー通信）に対して値の割当てを変更するその他の基本的なコンテキストを指定することができる。
【００５４】
別の態様では、まだユーザの気付いていない項目に関する通知ジャーナルを提供することができる。これは、ほぼすべての通知に関する大域的な通知ジャーナルを維持することを含むことができ、例えば、ユーザが前に受信した通知を返すこと、およびそれらの通知にアクセスすることを可能にする。これはまた、リッチな表示および対話を提供することを含むこともできる。例えば、通知ウィンドウまたはエンドポイントデバイスウィンドウ中のジャーナル化された項目をクリックすると、通知を提示させることができる。通知をクリックすると、通知のソースに関するより多くの情報または適切なユーザインタフェースが提示される。例えば、来るべきアポイントメントに関する通知をクリックすると、通知によって参照されるアポイントメントの完全な表示が提示される。また、強調表示リンクを通知内に表示して、ユーザが通知に関連するウェブページ、アプリケーション、または情報にジャンプできるようにすることもできる。さらに、通知がレンダリングされるとき、広告、特別な背景、および／またはその他の銘柄情報（ソースからの）を通知ウィンドウに表示することもできる。
【００５５】
別の態様では、アクティブ持続時間および／または失効日を伴う通知を、当該の日が過ぎた後にアクティブキューから削除することができる。ユーザがこの種のアクティビティの履歴を見ることに関心がある場合は、ジャーナル中の通知を失効済みとしてリストすることができる。また、通知が報告している情報の世界状態に関する更新を提供するために、例えばグローバル一意識別子（ＧＵＩＤ）で識別される情報更新で本質的に置換可能として、通知のクラスにタグ付けすることもできる。
【００５６】
ユーザがメッセージに優先度情報を付加できるようにする、あるいはより単純に通常の送信またはフリー時送信を行えるようにする、ユーザインタフェースツールを提供することができる。フリー時送信は、前述の限度付き延期システムを介してポートされることになる。通常送信は、限度なしの通信として機能することができる。通知には、コンテキストのセットからのアプリケーション特有（または寿命特有）コンテキスト（例えばフォーカスされているＭＳ  Ｗｏｒｄ、フォーカスされているＭＳ  Ｏｕｔｌｏｏｋなど）でタグ付けすることもでき、通知が失効していなければアクティブコンテキスト内に通知をレンダリングすることができる。例えば、ワードプロセッサがフォーカスされているときは、通知システムによってレンダリングされるワードプロセッサ使用に関する助言が、一般に提供されるべきである。このアプリケーションがフォーカスされていない場合は、助言は単にジャーナル化されるべきである。
【００５７】
より高度な機能を提供することもできる。例えば、ユーザの「対応できる可能性が高い時」の頻度や、ユーザがデスクトップで作業している時またはエンドポイントデバイスを使用している時や、各クラスでアラートがユーザによって受信される頻度を観察および学習することができ、次にフリーの可能性が高い状態になるまでの予想時間を、ユーザのアクティビティから（アプリケーション、時刻、予想されるユーザ位置などに基づいて）推論することができる。この情報を利用して、それぞれの通知優先度クラスに対する最大延期時間を自動的に設定することができ、それにより、各優先度クラスのアラートの場合に邪魔される確率を通知システムが制限できるようにすることができる。これはデフォルトで設定してもよく、あるいはユーザが各優先度クラスごとの確率を指定できるようにしてもよく、したがって、例えば低優先度のアラートの場合は時間の５％、通常優先度のアラートの場合は時間の１０％、高優先度のアラートの場合は時間の２５％よりも多く邪魔されたくない（すなわちビジーの時にアラートされたくない）ことをシステムに伝えることができる。すなわち、ユーザは、各優先度クラスごとに中断のターゲット「許容確率」を指定することができ、システムは、これらのクラスに対する最大延期時間を設定することができる。
【００５８】
重要な通知に気付いたことの確認を受信することができる。例えば、通知の上でホバーさせることが「これを得た」という信号であるという規定を採用することができ、このフィードバックは、ユーザがプロファイルを介して提出することのできるオプションとして利用することができる。すなわち、ユーザは以下のオプションを有効にすることを選択することができる。
［  ］私がエンドポイントデバイス上でマウスまたはキーストロークで確認するまで、［ｘ］分ごとにクリティカルな情報について私に通知し続けて下さい。
【００５９】
ユーザがｘ分（デフォルトとしてまたはユーザ指定の時間量として設定済み）を超えてデスクトップデバイスから離れているとき、デスクトップイベントを延期することができ、代わりに通知をモバイルデバイスまたはエンドポイントデバイスに送信することができる。デスクトップアラートについて指定されたのと同様の最大延期時間を採用することもでき、あるいはそうではなく「不在」条件に対する最大延期時間の代替セットにアクセスすることもできる。すなわち、不在状況に対する最大延期時間を制御するための別のテーブルまたは関数を採用することができる。
【００６０】
デスクトップ状況と同様、即座通過のマークが付いた通知の場合を除いては割り込まれるべきでないプレゼンテーションやその他のミーティングなど、割込み不可能なミーティングがあるかどうか見るために、ユーザのカレンダにアクセスすることができる。デスクトップ設定で提供されるそれぞれの方式での情報利用など、デスクトップ設定で上述したのと同様のカレンダに従った一般化を採用することもでき、あるいはモバイルまたはエンドポイント設定のための特別な一般化を有することもできる。
【００６１】
別の態様では、特定の時間帯（例えば深夜および早朝、週末）に通知を制限するための時刻制約設定を提供することができる。ユーザは、受信することになるアラートのクラスを特定の時に指定することができる。例えば、すべてのビジネス関連ｅメールおよび株情報は、週末にはモバイルデバイスに送信されない。
【００６２】
セルホンまたはページャに送信されたメッセージは、通知マネージャによってジャーナル化することができ、ユーザが通知ジャーナル表示のデスクトップに戻ったとき、またはモバイルデバイスまたはエンドポイントデバイス上のジャーナル表示にアクセスしたときに利用可能とすることができる。前述のデスクトップと同様のアラートのチャンク化を、モバイル設定にも採用することができる。
【００６３】
組込み自動パーソナルコンピュータ（オートＰＣ）や、適切に装備されたハンドヘルドパーソナルコンピュータ（ＨＰＣ）（すなわち加速度計を有するもの）などのモバイルデバイスまたはエンドポイントデバイスを、本発明と共に利用することができる。これらのデバイスでは、存在情報を使用して、例えば接触および／または加速に基づいてデバイスがアクティブであることが推論される。いくつかの重要なおよび／または別個のモバイル設定ごとに、フリーである可能性が高い状態のリスト（例えば運転中および歩行中の場合ごとの状態セット）が作成される。例えば運転中の場合、フリー状態には、例えば「赤信号またはその他の停止で停車したところであり、会話はない」や「比較的一定の速度で走行中」を含めることができる。
【００６４】
その他のシステムは、様々なレベルの注意を考慮することもできる（例えば速度、ブレーキ操作の複雑さ、ステアリングなどの考慮）。ＨＰＣの場合、ユーザが車内にいることを加速度計で推論（例えばベイズ推論）することができ、車内に搭載された自動車コンピュータからの直接のフィードがなくても同様の区別を推論することができる。ＨＰＣの場合、デバイスを手に取った時、歩行または走行が止まった時、会話が止まった時、あるいはユニットを置いて休ませた時を検出することができる。このようなモバイルデバイスまたはエンドポイントデバイスでは、通知をローカルでキャッシュして、フリーの可能性が高い状態に従ってレンダリングすることができる。検出可能な双方向接続がない場合は、このような情報を、モバイルデバイスに送信されたデスクトップ通知ジャーナルなどのジャーナル中で提供することができる。通知ジャーナルはエンドポイントデバイスによって維持することもできることを理解されたい。
【００６５】
ユーザは、「不在状態」が検出された後で最初にデスクトップ（またはラップトップデバイス）に戻った時にモバイル通知ジャーナルの単一通知を中継できるように、通知システムを構成することができ、それにより、特定の項目を選択して、ユーザがデスクトップにいれば気付いていたであろう通知を見ることができる。例えばユーザは、モバイルデバイスを持っていないか、サービス中のモバイルデバイスを持っていないか、単に「デスクトップ限定」のモダリティで通知システムが機能するよう指定したい場合がある。この場合、以下のことを実施することができる。
【００６６】
ユーザが「ユーザ不在」から「ユーザがデスクトップデバイスにいる」に移行したことに通知システムが気付いたとき、ユーザの不在中に最大延期時間を超えたすべての通知についての通知ジャーナルがユーザに提示される。あるいはユーザの選好に従って、最大延期時間に先行してすべてのアラートがこのようなジャーナルに掲示される（例えば、メッセージクラス、優先度、日付によって、または、最高緊急性のアラートを含むメッセージクラスや、クラス内での優先度または時間によるソートなどの組合せによって、ユーザ選好に従って様々な方法でソートされる）。ユーザが不在であると検出されたときは、追加で通知ジャーナルをデスクトップ上に（例えば事前に割り当てられた領域に）掲示し続け、最大延期時間を超えた通知をジャーナルに加えること（および通知の優先度または時間によってソートすること）を継続することができ、あるいは、最大延期時間に先行してほぼすべてのアラートをこのようなジャーナルに掲示することができる。このようなジャーナルが存在するときは、ユーザが戻った時またはログインした時に、ジャーナルがユーザを待機していることをオーディオ合図でユーザにアラートすることができる。表示は抑制され、戻った時にオーディオ合図としてレンダリングされ、ジャーナルを表示するための動作をユーザに行わせる。ユーザがモバイルデバイスを利用していた設定では、ユーザがまだ見ていない項目をソートすることおよび／または素早く目を通すことができるように、ジャーナル項目がモバイルデバイスに送信されると自動的にそのジャーナル項目はデスクトップジャーナルから削除されるものとすることができ、あるいはモバイルデバイスに送信済みとして通知にマークが付くものとすることができる。ジャーナルを掲示するのではなく、ジャーナル化される項目の量に応じて、通知ジャーナル、チャンク化されたアラート（前述のチャンク化ポリシーに従う）、または単一のアラートを表示するよう決定することもできる。
【００６７】
さらに、通知システムがこのような「戻った時に表示する」ポリシーを遅延させることを、ユーザが指定できるようにすることもでき、それにより、ユーザが戻った時に作業に取りかかれるようにし（ユーザが戻って何かを行いたいと思ったときにアラートを受けるフラストレーションを回避するため）、かつ／または、次の「フリーの可能性が高い」状態が現れるのを待機する。通知がこのような抑制を免除されるように、特別な「通り道」を提供することができる。このような機能のために、追加の「フリーの可能性が高い」状態を、「離れていたユーザが戻ったがアプリケーションまたはシステムとアクティブな作業を開始しない」として定義することができる。すなわち、ユーザが自分のデスクトップまたはエンドポイントデバイスに戻った時にすぐに作業を開始するかどうか検出することができ、代わりに「対応できる可能性が高い」状態に達するまで待機することができる。ユーザが戻ったが作業を開始しない場合、この新しいフリーの可能性が高い状態が認識され、したがって保留中の通知が表示される。ユーザが戻ったがビジーである場合、システムは、最大延期を超えた通知を表示することもでき、あるいはユーザ選好に従って、次の「フリーの可能性が高い」状態が現れるまで何も表示しないこともできる。このとき、ジャーナル化される項目の量に応じて、ジャーナル、チャンク化されたアラート、または単一のアラートがユーザに表示される。
【００６８】
モバイルデバイスまたはエンドポイントデバイスを利用しているユーザは、デバイスをオフにしているか、サービスのない領域にいる場合がある。セルホンをオンにすることも結局、デスクトップに戻ることと同様にして機能することができる。すなわち、まだ見られていないアラートのジャーナル表示が現れることができ、ユーザは各アラートを閲覧および表示することができる。本発明の他の態様では、例えばモバイルデバイス上でメッセージが検討されると、デスクトップジャーナルが更新されるものとすることができる。
【００６９】
図５に移り、図５００に、本発明の一態様による例示的な限度付き延期パラメータを示す。５１０で、送信側の識別またはメッセージ内容の性質をローカルで分析することに基づいて、限度付き延期に関するパラメータをローカルで計算または決定することができる。５２０で、これらのパラメータを、メタデータまたは制御データの一部として中央通知マネージャから受け取ることができる（すなわち、限度付き延期または推奨される限度付き延期をメッセージの通知スキーマに含めることができる）。５２４で、延期パラメータは、別のユーザによって設定された変数（例えばメッセージの緊急性を示すためにメッセージ送信側によって設定された優先度フラグ）の単純な関数とすることができ、あるいは通知マネージャによって設定された優先度値または他のパラメータの関数とすることができる。５３０で、パラメータには、ほぼどんな限度を含めることもできる。例えば、単に適した時を待機する、および／または、（何らかの失効最終期限を超えて）遅すぎる場合は消去または記録する、などである。
【００７０】
次に図６を参照し、システム６００に、本発明の一態様による、エンドポイントデバイスに対する様々な適用モデル６１０を示す。適用モデル６１０は、エンドポイントデバイスが利用することのできるいくつかの例示的な感知コンポーネントを記述する。サンプル適用例６１０は、６１４でローカルカレンダ情報を使用して、映画または番組あるいはその他のミーティングの終了後までアラートを抑えるようデバイスを誘導することを含む。６２０では、マイクロホンまたはその他の音声受容器を利用して、誰かが話すのを止めた時またはその他の大きい背景雑音、例えば自動車を運転する雑音やカーラジオなどを感知することができ、限度内でｔよりも長い静寂期間までアラートを延期することを試みる。６２４では、加速度計などの運動デバイスが、アラートが例えば限度内でレンダリングされるように、例えば赤信号や停止標識で自動車が停止した時や、人が歩行や話を止めた時を感知する。
【００７１】
一例では、適用例は、限度に達した後でベルを鳴らし、静かになった後でまたはその他のセンサ条件の後で、再びバックアップとして鳴らすという概念を考慮する。別の場合では、人が近付くまでまたはデバイスに触れるまで待機した後で、通知を送達する。適用モデル６１０は、電話の自動延期を考慮することもできる。単純な場合では、話が止むのを待機しながら、静かなときは最初の数回のベル音を消す。より精巧な場合では、ユーザが一時的にビジーであることが感知された場合に電話を取るエージェントを利用し、エージェントは少しの間（呼に対する限度付き延期の間）待つようユーザに求め、次いでユーザが話を止めた時または限度（例えば１分）に達した時に「あと３０秒だけお待ち下さい。まだ接続を試みています」と組み合わせて電話を掛ける。これが失敗した場合は、発呼側を留守番電話に向けるか、発呼側をユーザに繋ぐ。この概念は、特別な人または特別に指示されたグループ内の人（「１時間以内に会う予定の人」など）だけに対して電話発信の延期を実施することと組み合わせることができる。エンドポイントデバイスが利用することのできるその他のセンサには、６３０の全地球測位システム（ＧＰＳ）、６３４の８０２．１１信号強度センサ、６４０の赤外線近接センサ、６４４のタッチセンサが含まれる。
【００７２】
図７および８に、本発明による限度付き延期通知を提供する方法を示す。説明を簡単にするために、この方法を一連の動作として図示および記述するが、本発明によりいくつかの動作は図示および記述するのとは異なる順序で、かつ／または他の動作と同時に実施することができるので、本発明は動作の順序によって限定されないことを理解および認識されたい。例えばこの方法は、別法として、一連の相関した状態またはイベントとして状態図などで表すこともできることは当業者なら理解および認識するであろう。さらに、本発明による方法を実施するのに、図示する動作すべてが必要であるとは限らない。
【００７３】
図７を参照すると、７０２で新しい通知を受信する。７０４で、受信した通知をメッセージキューに入れる。７０６で、受信した通知をすぐにユーザまで通過させるべきかどうかを判定する。これは、通知を通過させるべきかどうかを示すフラグなどの設定を観察することによって達成することができる。通知を通過させるべきである場合は、プロセスは図８に示す８２０に進む。通知を通過させるべきでない場合は、プロセスは７０８に進む。７０８で、前述の最大延期時間などの初期時間を通知に関連付ける。動作７１０、７１２、７１６は、刻時サービスルーチンの一部として、または割込みイベントとして実行することができ、これらの動作は図７および８に示すプロセスの各部分から定期的に実行されることに留意されたい。７１０で、キューに入れられた通知の古さを更新する。７１２で、通知が失効したかどうかを判定する。失効した場合は、失効した通知をキューから削除する。７１２で通知が失効していない場合は、プロセスは図８に示すプロセスに戻る／進む。
【００７４】
次に図８を参照するが、図７の７０６からの分岐に関して８２０で判定を行う。８２０で、ユーザがデスクトップまたはエンドポイントデバイスにいるかどうかを判定する。いる場合は、プロセスは８２４に進み、特定の通知をキューから削除し、通知を表示し、通知ジャーナルを更新する。８２０でユーザがデスクトップにいない場合は、８２８で、ユーザのモバイルデバイスまたはエンドポイントデバイスがイネーブルかどうかを判定する。イネーブルでない場合は、プロセスは通知ジャーナルを更新する。８２８でモバイルデバイスがイネーブルである場合は、プロセスは８３０に進む。８３０で、カレンダが割込み不可能ミーティングを示しているかどうかを判定する。示している場合は、通知ジャーナルを更新し、ミーティング後にユーザにアラートする。８３０でこのようなミーティングがない場合は、通知をモバイルデバイスまたはエンドポイントデバイスに送信し、通知ジャーナルを更新する。
【００７５】
８４０を参照すると、図７に示した動作７１０〜７１６からの回帰が提供されている。８４０で、ユーザがデスクトップまたはエンドポイントデバイスにいるかどうかを判定する。いない場合は、８４２で、いずれかの通知が図７の７０８で設定された最大延期時間に達したかどうかを判定する。達した場合は、プロセスは８４４に進み、特定の通知をキューから削除し、前述の８２８に進む。８４０でユーザがデスクトップまたはエンドポイントデバイスに戻って来たところである場合は、まだ見られていない通知をレンダリングし、通知ジャーナルを更新する。８４０でユーザがデスクトップにいた場合は、プロセスは８４８に進む。８４８で、対応できる可能性が高い状態が検出されたかどうかを判定する。検出された場合は、保留中の通知をレンダリングし、通知ジャーナルを更新する。８４８で対応できる可能性が高い状態が検出されなかった場合は、プロセスは８５０に進む。８５０で、いずれかの通知が図７の７０８で設定された最大延期時間に達したかどうかを判定する。達した場合は、プロセスは８２４に進み、特定の通知をキューから削除し、通知の表示および通知ジャーナルの更新に進む。
【００７６】
図９〜１２は、通知処理および注意モデリングの様々な態様を記述したものである。前述のように、本発明は、システムがどのようにユーザの注意に関する情報にアクセスしてそれを使用することができるかを考慮する。注意に関する細かい手掛かりがしばしば利用可能であり、これらの手掛かりのいくつかは、ユーザの注意ステータスに関する直接の信号と見なすことができる。例えば、様々な状況でデバイスに触れたりデバイスを持ち上げたりするなどの単純なジェスチャーのパターンを感知することにより、注意に関する証拠を中継することができ、これを既存のいくつかの方法で利用することができる。より精度の高い感知に移り、本発明は、視線追跡システム、および、様々な適用例における視覚的注意のフォーカスに関する信号を利用することができる。視線センサの信頼性が向上しコストが低下するのに伴い、視覚的注意の的がいつどのようにデバイスに呼び掛けるかを認識する様々なデバイスを利用することができる。
【００７７】
それにもかかわらず、観察に鑑みたユーザの注意フォーカスおよび作業負荷、ならびに様々なコンテキストでの代替アクションの価値については、しばしば不確定性がある。したがって、本発明は、ユーザの注意を推測すること、および不確定性の下で取るべき理想的な、注意の影響を受けるアクションを推測することに利用できるモデルを採用する。このようなモデルおよび推測は、新しい機能およびユーザ体験を解放することができる。いくつかの場合では、モデルは手作業で構築することができ、かつ／またはデータベイズモデルから学習することができる。データベイズモデルは、自動化された「注意検出器」の作業を実施するものと見なすことができ、不確定性の下での現在または未来の注意を、進行中の手掛かりのストリームから明らかにするように働く。ベイズ注意モデルは、注意に関する証拠のストリームを提供するセンサを入力として、ユーザの注意および意図にわたる確率分布を計算する手段を提供する。
【００７８】
図９は、ユーザの注意フォーカスおよび作業負荷を、いくつかのセンサによって観察されたステータスの影響を受ける確率変数として考える、高レベルの決定モデル９００である。知覚センサには、周囲の音響情報または発話を聞くマイクロホン、ユーザの視線または姿勢の視覚的分析をサポートするカメラ、デバイスの動きのパターンを検出する加速度計、ＧＰＳおよび無線信号の分析による位置感知が含まれる。しかし、より従来型のイベントソースも、価値ある手掛かりを提供することができる。これらのソースには、ユーザのオンラインカレンダや、曜日および時刻の考慮が含まれる。別のリッチな証拠ストリームは、ユーザとソフトウェアおよびデバイスとの対話を監視することによって収穫することができる。最後に、ユーザの関心の履歴と、前のアクティビティおよび注意のパターンとに関する背景情報も、注意に関する情報の価値あるソースを提供することができる。
【００７９】
複数のセンサからの証拠を融合することのできる確率的注意モデル９００を構築するために、本発明は、不確定性の下で推測および決定するための表現を利用する。このような作業は、ベイズネットワークおよび影響図を含めた推論方法および表現をもたらした。すなわち、確率的な推論を不確定性の下でのアクションの考慮に拡張するグラフィカルモデルをもたらした。これらのグラフィカル表現から結果にわたる確率分布およびアクションの期待効用を計算することを可能にする、アルゴリズムを開発することができる。
【００８０】
図９は、不確定性の下でのユーザの注意のコンテキストにおけるセンサ融合および決定を表す高レベルの影響図を示している。図に描かれているように、感知された証拠を表す変数（楕円ノード）のセットが、ユーザの注意ステータスを表す確率変数に影響を与え、確率変数は、代替アクションまたは構成の期待価値に影響を与える。様々な結果を伴う中間コスト変数および利益変数を導入することができる。理想的なコンピュータアクションに関する決定（長方形ノード）が、ユーザの注意に関する不確定性が与えられた場合のコストと利益を考慮する。最後に、期待効用（菱形ノード）が、アクション、およびコストと利益の影響を受ける。
【００８１】
追加の中間変数、および変数間の鍵となる相互依存関係を含む、よりリッチなモデルを構築することによって、高レベルの教育的な図を拡張することができる。また、デバイスも人も両方とも時間に巻き込まれるので、本発明は、変数の状態を点別に考慮することを超えて、時間の流れに伴って変化する観察および信念を表す、より忠実度の高い時間的注意モデルを構築する。これには、時間の経過に伴う注意および位置の状態を表現および推測するための、動的ベイズネットワークおよび隠れマルコフモデルを含めることができる。
【００８２】
図１０に、隣接するタイムスライス中の変数間の鍵となる依存関係（破線矢印）を強調した時間的ベイズ注意モデル１０００を示す。モデル１０００は、時間的注意モデルの隣接する２つのタイムスライスを示している。このようなモデルは、ユーザへのメッセージおよび通信を選択的にフィルタリングすることを可能にするアプリケーションのために生み出された、ユーザの作業負荷およびタスクにわたる確率分布を提供する。この場合、注意ステータスは、約１５個の離散的な状態を含む（より多いか少ない状態を含むこともできる）。
【００８３】
図１１を参照すると、システム１１１０は、本発明の一態様による優先システム１１１２および通知アーキテクチャを示している。優先システム１１１２は、１つまたは複数のメッセージまたは通知１１１４を受け取り、関連するメッセージの優先度または重要性尺度（例えばメッセージが高いまたは低い重要性を有する確率値）を生成し、この１つまたは複数のメッセージを、関連する優先度値と共に出力１１１６で提供する。以下でより詳細に述べるように、分類器を構築し、優先度尺度をメッセージ１１１４に自動的に割り当てるように訓練することができる。例えば、メッセージが高、中、低、またはその他の程度の重要性カテゴリに属する確率がメッセージに割り当てられるように、出力１１１６をフォーマットすることができる。メッセージは、例えば決定された重要性カテゴリに従って、ｅメールプログラムの受信箱（図示せず）中で自動的にソートすることができる。ソートはまた、定義された重要性ラベルを有するシステムフォルダに向けてファイルを送ることを含むこともできる。これは、低、中、高などの重要性の程度でフォルダをラベル付けすることを含むことができ、特定の重要性を有すると判定されたメッセージは、関連するフォルダにソートされる。同様に、所望の優先度のメッセージが受信されたことをユーザにアラートするように、１つまたは複数のオーディオ音声または視覚表示（例えばアイコン、シンボル）を適合させることができる（例えば、高い優先度のメッセージならビープ３回、中程度の優先度ならビープ２回、低い優先度ならビープ１回。高い優先度なら赤色または点滅するアラートシンボル、中程度の優先度のメッセージが受信されたことを示すには緑色の点滅しないアラートシンボル）。
【００８４】
本発明の別の態様によれば、通知プラットフォーム１１１７を優先システム１１１２と共に利用して、優先度付きメッセージをユーザによってアクセス可能な１つまたは複数の通知シンクに向けて送ることができる。以下でより詳細に述べるように、通知プラットフォーム１１１７は、優先度付きメッセージ１１１６を受け取って、例えばいつどこでどのようにユーザに通知するかを決定するように、適合させることができる。例えば、通知プラットフォーム１１１７は、通信モダリティ（例えばセルホンやパーソナルディジタルアシスタント（ＰＤＡ）など、ユーザの現在の通知シンク１１１８）と、可能性の高いユーザ位置および／または可能性の高いユーザの注意フォーカスとを決定することができる。例えば、重要性の高いｅメールを受け取った場合、通知プラットフォーム１１１７は、ユーザの位置／フォーカスを決定し、メッセージをユーザに関連する通知シンク１１１８に向けて送信／再フォーマットすることができる。優先度の低いメッセージ１１１６を受け取った場合、通知プラットフォーム１１１７は、例えば後で望むように検討することができるよう、ｅメールをユーザの受信箱に残すように構成することができる。後でより詳細に述べるように、他のルーティングおよび／またはアラートシステム１１１９を利用して、優先度付きメッセージ１１１６をユーザおよび／または他のシステムに向けて送ることもできる。
【００８５】
次に図１２に移ると、システム１２００は、本発明の一態様によりどのように通知エンジンとコンテキストアナライザが共に機能するかを示している。システム１２００は、コンテキストアナライザ１２２２と、通知エンジン１２２４と、１つまたは複数の通知ソース１からＮ、１２２６、１２２７、１２２８と、通知ソースとして動作することのできる優先システム１２３０と、１つまたは複数の通知シンク１からＭ、１２３６、１２３７、１２３８とを備え、ＮおよびＭはそれぞれ整数である。ソースはイベントパブリッシャとも呼ばれ、シンクはイベントサブスクライバとも呼ばれる。シンクおよびソースはいくつあってもよい。一般に、通知エンジン１２２４は、コンテキストアナライザ１２２２によって記憶および／またはアクセスされるパラメータ情報に部分的に基づいて、通知（イベントまたはアラートとも呼ばれる）をソース１２２６〜１２２８からシンク１２３６〜１２３８に搬送する。
【００８６】
コンテキストアナライザ１２２２は、通知決定に影響を与えるユーザの変数およびパラメータに関する情報を記憶／分析する。例えば、パラメータには、時刻および曜日によるユーザがよくいる位置や注意フォーカスまたはアクティビティなどのコンテキスト情報と、様々な位置でユーザがアクセスする傾向のあるデバイスなど、このようなパラメータに左右される追加のパラメータとを含めることができる。このようなパラメータはまた、１つまたは複数のセンサによって自律的に行われた観察に応じたものとすることもできる。例えば、全地球測位システム（ＧＰＳ）サブシステムによって提供することのできるユーザ位置に関する情報や、使用されているデバイスのタイプおよび／またはデバイスの使用パターンや、特定タイプのデバイスがユーザによって最後にアクセスされた時に基づいて、１つまたは複数のプロファイル（図示せず）を選択または修正することができる。さらに、後でより詳細に述べるように、自動推論を利用して、位置や注意などのパラメータまたは状態を動的に推論することもできる。プロファイルパラメータは、ユーザによって編集できるユーザプロファイルとして記憶することができる。事前定義済みプロファイルのセットまたは動的推論に依拠することの他に、この通知アーキテクチャでは、ユーザは例えば、重要な通知を除いてあと「ｘ」時間または所与の時までは対応できないなど、リアルタイムで自分の状態を指定することもできる。
【００８７】
パラメータには、様々な状況で様々なタイプの通知によって邪魔されることに関するユーザの選好について、デフォルトの通知選好パラメータを含めることもでき、これは通知エンジン１２２４が通知決定を行う際の基準として、またユーザが変更を開始することのできる基準として使用することができる。パラメータには、ユーザが様々な状況でどのように通知を受けたいか（例えばセルホンで、ページャで、など）に関するデフォルトパラメータを含めることができる。パラメータには、様々な状況で様々なモードで通知されることに関連する中断のコストなどの評価を含めることができる。これには、ユーザが様々な位置にいる可能性、様々なデバイスが利用できる可能性、所与の時におけるユーザの注意ステータスの可能性を示すコンテキストパラメータ、ならびに、所与の時にユーザがどのように通知を受けたいかを示す通知パラメータを含めることができる。
【００８８】
コンテキストアナライザ１２２２によって記憶される情報には、本発明の一態様によれば、アナライザによって決定されるコンテキスト情報が含まれる。コンテキスト情報は、本記述の後のセクションでより詳細に述べるように、アナライザ１２２２が１つまたは複数のコンテキスト情報ソース（図示せず）に基づいてユーザの位置および追加ステータスを識別することによって決定される。コンテキストアナライザ１２２２は、例えば、ユーザの自動車またはセルホンの一部である全地球測位システム（ＧＰＳ）によってユーザの実際の位置を正確に決定できるものとすることができる。アナライザはまた、統計モデルを利用して、日のタイプ、時刻、ユーザのカレンダ中のデータ、ユーザのアクティビティに関する観察などの情報を考慮することで収集された背景評価および／または観察を考慮することによって、ユーザが所与の注意状態にある可能性を決定することもできる。所与の注意状態には、ユーザが通知の受信を受け入れているか、ビジーであり通知の受信を受け入れていないかを含めることができ、また、平日、週末、休日、および／または他の機会／期間など、その他の考慮を含めることもできる。
【００８９】
ソース１２２６〜１２２８、１２３０は、ユーザおよび／またはその他のエンティティへの通知を生成する。例えば、ソース１２２６〜１２２８には、インターネットおよびネットワークベースの通信や電話通信などの通信、ならびにソフトウェアサービスを含めることができる。通知ソースは、本明細書では一般に、情報、サービス、および／あるいはシステムイベントまたは世界イベントについて、ユーザまたはユーザのプロキシにアラートするよう意図されたイベント（通知およびアラートと呼ぶこともできる）を生成するものとして定義される。通知ソースはイベントソースと呼ぶこともできる。
【００９０】
例えば、ｅメールが優先システム１２３０によって通知として生成され、それにより優先度が付けられるものとすることができ、通知を生成するアプリケーションプログラムまたはシステムは、ユーザにとってのｅメールの重要性または緊急性の可能性に対応する相対的な優先度をｅメールに割り当てる。ｅメールは、ユーザにとっての相対的な重要性に関係なく送信することもできる。インターネット関連サービスには、例えば時々の現在ニュースのヘッドラインや株相場など、ユーザが申し込んだ情報を含む通知を含めることができる。
【００９１】
通知ソース１２２６〜１２２８はそれ自体、プッシュタイプまたはプルタイプのソースとすることができる。プッシュタイプのソースは、申込み後に自動的に情報を送信するヘッドラインニュースやその他のインターネット関連サービスなど、対応する要求がなくても自動的に情報を生成し送信するものである。プルタイプのソースは、メールサーバがポーリングされた後でｅメールが受信されるなど、要求に応答して情報を送信するものである。その他の通知ソースには、以下のものが含まれる。
・カレンダシステムなどのｅメールデスクトップアプリケーション
・コンピュータシステム（例えば、システムアクティビティまたは問題について知らせるメッセージでユーザにアラートすることができる）
・インターネット関連サービス、アポイントメント情報、スケジューリング照会
・１つまたは複数の共有フォルダ中の文書またはいくつかの種類の文書の変更
・情報を求める固定のまたは継続的な照会に応答した、新しい文書の入手可能性、ならびに／あるいは
・人およびその存在、その位置の変化、その近接（例えば「私の移動中に別の同僚または友人が私から１０マイル以内にいれば知らせて下さい」）、またはその対応可能性（例えば「スティーブが会話に出ることができて完全ビデオ遠隔会議をサポートできる高速リンクの近くにいるときは知らせて下さい」）に関する情報の情報ソース
【００９２】
通知シンク１２３６〜１２３８は、ユーザに通知を提供することができる。例えば、このような通知シンク１２３６〜１２３８には、デスクトップおよび／またはラップトップコンピュータなどのコンピュータ、ハンドヘルドコンピュータ、セルホン、地上通信線電話機、ページャ、自動車ベースのコンピュータ、ならびに、理解できるであろうがその他のシステム／アプリケーションを含めることができる。シンク１２３６〜１２３８のいくつかは、他のシンクよりもリッチに通知を搬送することができることに留意されたい。例えば、デスクトップコンピュータの場合は通常、スピーカおよび比較的大きいカラー表示装置が結合されており、また、ローカルネットワークまたはインターネットに結合されたときに情報を受信するための帯域幅がより広い。したがって、デスクトップコンピュータからは、比較的リッチな方式で通知をユーザに搬送することができる。反対に多くのセルホンは、例えば、場合によっては白黒のより小さい表示装置を有し、比較的狭い帯域幅で情報を受信する。したがって、セルホンによって搬送される通知に関連する情報は一般に、例えば、より短く、電話機のインタフェース機能向けに適合されている場合がある。このように、通知の内容は、通知がセルホンに送信されるかデスクトップコンピュータに送信されるかによって異なる場合がある。本発明の一態様によれば、通知シンクは、例えばイベント加入サービスを介してイベントまたは通知を申し込む通知シンクを指すことができる。
【００９３】
通知エンジン１２２４は、コンテキストアナライザによって記憶および／または決定された情報にアクセスし、ソース１２２６〜１２２８から受け取った通知のどれをシンク１２３６〜１２３８のどれに搬送するかを決定する。さらに、通知エンジン１２２４は、シンク１２３６〜１２３８のどれを情報送信先に選択したかに応じて、どのように通知を搬送するかを決定することもできる。例えば、通知を選択されたシンク１２３６〜１２３８に提供する前に要約すべきであると決定することができる。
【００９４】
本発明は、どの通知をどの通知シンクに搬送するか、およびどのようにして通知を搬送するかについて、エンジン１２２４が決定する方式には限定されない。一態様では、決定理論的分析を利用することができる。例えば、通知エンジン１２２４は、ユーザの位置、注意、デバイス利用可能性、アラートがなかった場合にユーザが情報にアクセスするまでの時間量を含めた変数に関して、重要な不確定性を推論するように適合させることができる。次いで、通知エンジン１２２４は、ユーザに通知をアラートするかどうかの通知決定を行うことができ、アラートする場合は、要約の性質、および通知を中継するのに利用する適した１つまたは複数のデバイスを決定することができる。一般に、通知エンジン１２２４は、通知の正味期待価値を決定する。このようにする際、以下のことを考慮することができる。
・利用可能な各通知シンクの忠実度および伝送信頼性
・ユーザの邪魔をすることの注意コスト
・ユーザにとっての通知の目新しさ
・ユーザが自分で情報を検討するまでの時間
・コンテキストの影響を受ける可能性のある情報価値、ならびに／あるいは
・通知に含まれる情報の、時間の経過に伴う価値の増大および／または減少
【００９５】
したがって、不確定性についてなされる推論を、価値の期待尤度として生成することができる。例えば、何らかのユーザ注意状態が与えられた場合の、特定モードの特定デバイスを使用するユーザを中断させるコストなどの期待尤度として生成することができる。通知エンジン１２２４は、以下の１つまたは複数を決定することができる。
・ユーザが現在何に携わっており何をしているか（例えばコンテキスト情報に基づいて）
・ユーザが現在どこにいるか
・情報がどのくらい重要か
・通知を延期するコストはどれだけか
・通知がどのくらい気を逸らせることになるか
・ユーザに届く可能性はどれだけあるか
・特定モードの所与の通知シンクを使用することに関連する忠実度損失はどれだけか
【００９６】
したがって、通知エンジン１２２４は、保留中のおよびアクティブな通知に関して決定理論的分析などの分析を実施することができ、情報シンクおよびソースから提供されたコンテキスト依存変数を評価し、ユーザが情報を検討する可能性が高くなるまでの時間やユーザの位置および現在の注意状態など、選択された不確定性を推論する。さらに、通知エンジン１２２４は、個人化された決定理論的分析の代わりに、またはそれをサポートするために、コンテキストアナライザ１２２２によってユーザプロファイルに記憶された情報にアクセスすることができる。例えばユーザプロファイルは、所与の時にユーザが、通知が所定の重要性レベルを有する場合にだけページャで通知を受信するのを好むことを示すことができる。このような情報は、決定理論的分析を開始する際のベースラインとして利用することができ、あるいは、通知エンジン１２２４がどのようにユーザに通知するか、またはユーザに通知するかどうかを判定するための方式とすることができる。本発明の一態様によれば、通知プラットフォームアーキテクチャは、イベンティングまたはメッセージングインフラストラクチャ全体にわたって存在するレイヤとして構成することができる。ただし、本発明はどんな特定のイベンティングインフラストラクチャにも限定されない。
【００９７】
さらに、このアーキテクチャは、当業者なら理解できるように、フレキシブルな分散型計算インフラストラクチャ全体にわたって存在するレイヤとして構成することができる。したがって、この通知プラットフォームアーキテクチャは、例えば、ソースが通知、アラート、イベントを送信する方式として、またエンドポイントデバイスなどのシンクが通知、イベント、アラートを受信する方式として、基礎をなすインフラストラクチャを利用することができる。ただし、本発明はこのように限定されない。
【００９８】
図１３を参照すると、本発明の様々な態様を実施するための例示的な環境１３１０は、コンピュータ１３１２を含む。コンピュータ１３１２は、プロセッサ１３１４、システムメモリ１３１６、システムバス１３１８を備える。システムバス１３１８は、限定しないがシステムメモリ１３１６を含めた様々なシステムコンポーネントを、プロセッサ１３１４に結合する。プロセッサ１３１４は、様々な利用可能なプロセッサのいずれかとすることができる。デュアルマイクロプロセッサおよびその他のマルチプロセッサアーキテクチャも、プロセッサ１３１４として利用することができる。
【００９９】
システムバス１３１８は、様々な利用可能なバスアーキテクチャのいずれかを用いたメモリバスまたはメモリコントローラ、周辺バスまたは外部バス、および／またはローカルバスを含めて、いくつかのタイプのバス構造のいずれかとすることができる。これらのバスアーキテクチャには、限定しないが１１ビットバス、ＩＳＡ（Ｉｎｄｕｓｔｒｉａｌ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）、ＭＣＡ（Ｍｉｃｒｏ−Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ）、ＥＩＳＡ（Ｅｘｔｅｎｄｅｄ  ＩＳＡ）、ＩＤＥ（Ｉｎｔｅｌｌｉｇｅｎｔ  Ｄｒｉｖｅ  Ｅｌｅｃｔｒｏｎｉｃｓ）、ＶＬＢ（ＶＥＳＡ  Ｌｏｃａｌ  Ｂｕｓ）、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）、ＡＧＰ（Ａｄｖａｎｃｅｄ  Ｇｒａｐｈｉｃｓ  Ｐｏｒｔ）、ＰＣＭＣＩＡ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ  Ｍｅｍｏｒｙ  Ｃａｒｄ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ａｓｓｏｃｉａｔｉｏｎ）バス、ＳＣＳＩ（Ｓｍａｌｌ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｆａｃｅ）が含まれる。
【０１００】
システムメモリ１３１６は、揮発性メモリ１３２０および不揮発性メモリ１３２２を含む。不揮発性メモリ１３２２には、起動中などにコンピュータ１３１２内の要素間で情報を転送するための基本ルーチンを含むＢＩＯＳ（ｂａｓｉｃ  ｉｎｐｕｔ／ｏｕｔｐｕｔ  ｓｙｓｔｅｍ）が記憶されている。限定ではなく例として、不揮発性メモリ１３２２には、読取り専用メモリ（ＲＯＭ）、プログラム可能ＲＯＭ（ＰＲＯＭ）、電気的プログラム可能ＲＯＭ（ＥＰＲＯＭ）、電気的消去可能ＲＯＭ（ＥＥＰＲＯＭ）、またはフラッシュメモリを含めることができる。揮発性メモリ１３２０には、ランダムアクセスメモリ（ＲＡＭ）が含まれ、これは外部キャッシュメモリとして働く。限定ではなく例として、ＲＡＭは、シンクロナスＲＡＭ（ＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、ダブルデータレートＳＤＲＡＭ（ＤＤＲ  ＳＤＲＡＭ）、エンハンスドＳＤＲＡＭ（ＥＳＤＲＡＭ）、Ｓｙｎｃｈｌｉｎｋ  ＤＲＡＭ（ＳＬＤＲＡＭ）、ダイレクトＲａｍｂｕｓ  ＲＡＭ（ＤＲＲＡＭ）など、多くの形で利用可能である。
【０１０１】
コンピュータ１３１２は、取外し可能／取外し不可能、揮発性／不揮発性コンピュータ記憶媒体も備える。図１３には、例としてディスク記憶装置１３２４が示してある。ディスク記憶装置１３２４には、限定しないが磁気ディスクドライブ、フロッピー（登録商標）ディスクドライブ、テープドライブ、Ｊａｚドライブ、Ｚｉｐドライブ、ＬＳ−１００ドライブ、フラッシュメモリカード、メモリスティックなどのデバイスが含まれる。また、ディスク記憶装置１３２４には、限定しないがコンパクトディスクＲＯＭデバイス（ＣＤ−ＲＯＭ）、ＣＤ記録可能ドライブ（ＣＤ−Ｒドライブ）、ＣＤ書換え可能ドライブ（ＣＤ−ＲＷドライブ）、ディジタル多用途ディスクＲＯＭドライブ（ＤＶＤ−ＲＯＭ）などの光ディスクドライブを含めた記憶媒体を、他の記憶媒体と別個でまたは共に含めることもできる。ディスク記憶デバイス１３２４をシステムバス１３１８に接続するのを容易にするために、通常はインタフェース１３２６などの取外し可能または取外し不可能インタフェースが使用される。
【０１０２】
図１３には、ユーザと、適した動作環境１３１０で述べた基本的なコンピュータリソースとの間の媒介として働くソフトウェアが記述されていることを理解されたい。このようなソフトウェアには、オペレーティングシステム１３２８が含まれる。オペレーティングシステム１３２８は、ディスク記憶装置１３２４に記憶されているものとすることができ、コンピュータシステム１３１２のリソースを制御および割振りするように働く。システムアプリケーション１３３０は、システムメモリ１３１６またはディスク記憶装置１３２４に記憶されたプログラムモジュール１３３２およびプログラムデータ１３３４を介して、オペレーティングシステム１３２８によるリソース管理を利用する。本発明は様々なオペレーティングシステム、またはオペレーティングシステムの組合せで実施できることを理解されたい。
【０１０３】
ユーザは、入力デバイス１３３６を介してコマンドまたは情報をコンピュータ１３１２に入力する。入力デバイス１３３６には、限定しないが、マウスなどのポインティングデバイス、トラックボール、スタイラス、タッチパッド、キーボード、マイクロホン、ジョイスティック、ゲームパッド、衛星受信アンテナ、スキャナ、ＴＶチューナカード、ディジタルカメラ、ディジタルビデオカメラ、ウェブカメラなどが含まれる。これらおよびその他の入力デバイスは、インタフェースポート１３３８によってシステムバス１３１８を介してプロセッサ１３１４に接続する。インタフェースポート１３３８には、例えばシリアルポート、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）が含まれる。出力デバイス１３４０は、入力デバイス１３３６と同じタイプのポートのいくつかを使用する。したがって例えば、ＵＳＢポートを使用して、コンピュータ１３１２に入力を提供することができ、またコンピュータ１３１２から出力デバイス１３４０に情報を出力することができる。出力デバイス１３４０の中でもとりわけ、モニタ、スピーカ、プリンタのように特別なアダプタを必要とするいくつかの出力デバイス１３４０があることを示すために、出力アダプタ１３４２が提供されている。出力アダプタ１３４２には、限定ではなく例として、出力デバイス１３４０とシステムバス１３１８との間の接続手段を提供するビデオカードおよびサウンドカードが含まれる。その他のデバイス、および／またはデバイスのシステムは、リモートコンピュータ１３４４など、入力と出力の両方の機能を提供することに留意されたい。
【０１０４】
コンピュータ１３１２は、リモートコンピュータ１３４４など１つまたは複数のリモートコンピュータへの論理接続を用いて、ネットワーク化された環境で動作することができる。リモートコンピュータ１３４４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ワークステーション、マイクロプロセッサベースの機器、ピアデバイス、またはその他の一般的なネットワークノードなどとすることができ、通常はコンピュータ１３１２に関して述べた要素の多くまたはすべてを備える。簡潔にするために、メモリ記憶デバイス１３４６だけがリモートコンピュータ１３４４と共に示してある。リモートコンピュータ１３４４は、ネットワークインタフェース１３４８を介してコンピュータ１３１２に論理接続され、次いで通信接続１３５０を介して物理接続される。ネットワークインタフェース１３４８には、ローカルエリアネットワーク（ＬＡＮ）やワイドエリアネットワーク（ＷＡＮ）などの通信ネットワークが含まれる。ＬＡＮ技術には、ファイバ分散データインタフェース（ＦＤＤＩ）、銅分散データインタフェース（ＣＤＤＩ）、イーサネット（登録商標）／ＩＥＥＥ８０２．３、トークンリング／ＩＥＥＥ８０２．５などが含まれる。ＷＡＮ技術には、限定しないが、ポイントツーポイントリンク、統合ディジタルサービス通信網（ＩＳＤＮ）およびこれらの変形などの回路交換ネットワーク、パケット交換ネットワーク、ディジタル加入者線（ＤＳＬ）が含まれる。
【０１０５】
通信接続１３５０は、ネットワークインタフェース１３４８をバス１３１８に接続するのに利用されるハードウェア／ソフトウェアを指す。通信接続１３５０は、図示を分かりやすくするためにコンピュータ１３１２の内部に示してあるが、コンピュータ１３１２の外部にあってもよい。ネットワークインタフェース１３４８への接続に必要なハードウェア／ソフトウェアには、例にすぎないが、通常の電話グレードモデムやケーブルモデムやＤＳＬモデムを含めたモデム、ＩＳＤＮアダプタ、イーサネット（登録商標）カードなどの、内部技術および外部技術が含まれる。
【０１０６】
図１４は、本発明が対話することのできる例示的なコンピューティング環境１４００の概略ブロック図である。システム１４００は、１つまたは複数のクライアント１４１０を含む。クライアント１４１０は、ハードウェアおよび／またはソフトウェア（例えばスレッド、プロセス、コンピューティングデバイス）とすることができる。システム１４００は、１つまたは複数のサーバ１４３０も含む。サーバ１４３０もまた、ハードウェアおよび／またはソフトウェア（例えばスレッド、プロセス、コンピューティングデバイス）とすることができる。サーバ１４３０は、例えば、本発明を利用して変換を実行するためのスレッドを格納することができる。クライアント１４１０とサーバ１４３０との間の可能な通信の１つは、複数のコンピュータプロセス間で伝送されるように適合されたデータパケットの形とすることができる。システム１４００は、クライアント１４１０とサーバ１４３０との間の通信を容易にするのに利用できる通信フレームワーク１４５０を含む。クライアント１４１０は、クライアント１４１０にとってローカルな情報を記憶するのに利用できる１つまたは複数のクライアントデータストア１４６０に動作可能に接続される。同様に、サーバ１４３０は、サーバ１４３０にとってローカルな情報を記憶するのに利用できる１つまたは複数のサーバデータストア１４４０に動作可能に接続される。
【０１０７】
以上の記述は、本発明の実施例を含む。当然、本発明を記述するために、考えられるあらゆる組合せのコンポーネントおよび方法について述べることは不可能である。しかし、本発明に関するその他多くの組合せおよび置換が可能であることは、当業者なら理解するであろう。したがって本発明は、添付の特許請求の趣旨および範囲に含まれるこのようなすべての改変、修正、変形を含むものとする。さらに、「ｉｎｃｌｕｄｅ（含む、備える）」という語が詳細な説明または特許請求の範囲で使用される限り、このような語は、請求項における移行語として採用されたときに解釈される「ｃｏｍｐｒｉｓｉｎｇ（含む、備える）」という語と同様にして包括的とする。
【図面の簡単な説明】
【０１０８】
【図１】本発明の一態様によるフリー時メッセージングアーキテクチャを示す概略ブロック図である。
【図２】本発明の一態様による例示的なステータス交換を示すブロック図である。
【図３】本発明の一態様によるエンドポイントデバイス通信を示す概略ブロック図である。
【図４】本発明の一態様による例示的な限度付き延期ポリシーを示す図である。
【図５】本発明の一態様による例示的な限度付き延期パラメータを示す図である。
【図６】本発明の一態様によるエンドポイントデバイスに対する適用モデルを示す図である。
【図７】本発明の一態様による限度付き延期処理を示す流れ図である。
【図８】本発明の一態様による限度付き延期処理を示す流れ図である。
【図９】本発明の一態様による注意フォーカスおよび作業負荷のモデルを示す影響図である。
【図１０】本発明の一態様による時間的ベイズ注意モデルを示す影響図である。
【図１１】本発明の一態様による優先システムの概略ブロック図である。
【図１２】本発明の一態様による通知エンジンとコンテキストアナライザとの間の系統的協働を示す概略ブロック図である。
【図１３】本発明の一態様による適した動作環境を示す概略ブロック図である。
【図１４】本発明が対話することのできる例示的なコンピューティング環境の概略ブロック図である。
【符号の説明】
【０１０９】
１００  システム
１１０  メッセージ送信コンポーネント
１２０  エンドポイントデバイス
１３０  生存時間（ＴＴＬ）プロパティ付きメッセージ
１４０  ユーザインタフェース
１５０  限度付き延期コンポーネント
【図１】
2006018833.tif 000003
【図２】
2006018833.tif 000004
【図３】
2006018833.tif 000005
【図４】
2006018833.tif 000006
【図５】
2006018833.tif 000007
【図６】
2006018833.tif 000008
【図７】
2006018833.tif 000009
【図８】
2006018833.tif 000010
【図９】
2006018833.tif 000011
【図１０】
2006018833.tif 000012
【図１１】
2006018833.tif 000013
【図１２】
2006018833.tif 000014
【図１３】
2006018833.tif 000015
【図１４】
2006018833.tif 000016