データ処理装置、受信装置、データ処理装置の操作方法、受信装置の操作方法、及びプログラム
【課題】ユーザが現在の通知に対処し終わるまで、後続の通知の提供を抑制する。
【解決手段】
データ処理装置が提供される。当該データ処理装置は、当該データ処理装置や、当該データ処理装置に接続された他の装置におけるデータ処理イベントに応じてユーザへの通知を提供するように構成された通知コントローラと、通知された前記データ処理イベントに関するデータ処理タスクを実行するためのユーザ通知にユーザを対処させることが可能なユーザインターフェースと、を具備する。上記通知コントローラは、ユーザが上記ユーザインターフェースを用いて現在の通知に対処している間、他の通知を抑制するように構成される。
【解決手段】
データ処理装置が提供される。当該データ処理装置は、当該データ処理装置や、当該データ処理装置に接続された他の装置におけるデータ処理イベントに応じてユーザへの通知を提供するように構成された通知コントローラと、通知された前記データ処理イベントに関するデータ処理タスクを実行するためのユーザ通知にユーザを対処させることが可能なユーザインターフェースと、を具備する。上記通知コントローラは、ユーザが上記ユーザインターフェースを用いて現在の通知に対処している間、他の通知を抑制するように構成される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザ通知に関する。
【背景技術】
【０００２】
ネットワークデバイスや接続デバイスのユーザは、当該デバイスやそれに接続された他のデバイスに関するイベントについての音声による通知及び／又は映像による通知や、警告メッセージ（「アラート」）を受ける。
【０００３】
ここで、「ネットワークデバイス」や「接続デバイス」という言葉は、例えば、電気ケーブルや、光接続や、無線や、これらの組み合わせによって、少なくともひとつの他のデバイスに、そのデバイスが接続可能であることを意味する。多くの場合には、このような接続は、インターネット接続や、一方向ブロードキャスト接続を介する、例えば、コンテンツプロバイダから当該デバイスへの接続や、携帯電話のようなポータブルデバイスを用いた短距離無線接続（例えば、ブルートゥース（登録商標）接続や、無線ネットワーク（「ＷｉＦｉ」）接続や、その他の適切なプロトコル接続）や、これらの組み合わせを介してなる。当該デバイスは、例えば、テレビやラジオの受信機や、コンピュータ端末や、携帯電話や、電子手帳などである。
【０００４】
このようなネットワークデバイスの一例としてテレビ受信機を挙げると、テレビ受信機は、インターネットに接続可能であり、電子メールや映像再生サービスやインスタントメッセージサービスなどのインターネットサービスと相互に作用することが知られている。
【０００５】
このようなシステムにおいて、ユーザ通知が生じる多くの場合がある。例えば、ユーザのテレビ受信機がインターネット電子メールアプリケーションを実行しているものとする。当該電子メールアプリケーションはバックグラウンドタスクとして動作し、そのため通常ユーザには見えない。しかしながら、ユーザに電子メールメッセージが届くと、電子メールアプリケーションは表示画面の中に小さい一時的な通知を表示する。ユーザは、当該通知に対応して電子メールメッセージを開き、電子メールアプリケーションをフルスクリーンで起動するか否かを選択することができる。「インターネット接続が切断されました」などの状況通知を表示可能なテレビ受信機や他のデバイスもある。
【０００６】
ユーザにはこのような通知を表示しない便宜が図られていることが知られている。この場合、当該通知は、ユーザが再び通知を許可するときにユーザが表示されていない間に受信した通知へのアクセスが可能となるように、バッファに格納される。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】米国特許出願公開第２００２／０１２４２５２号明細書
【特許文献２】米国特許出願公開第２０１０／０１３８８５８号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００８】
特許文献１は、ユーザが、特定のテレビチャンネルや特定のテレビ番組を見ている間に表示されることを許容する警告のタイプを定義する「プロフィール」を設定することが可能なテレビ受信機を開示している。しかしながら、特定の「許容する」警告タイプの複数の密集した警告をどのように扱うかという問題が残る。
【０００９】
特許文献２は、緊急通知システムに関連するテレビ受信機を開示している。このテレビ受信機は、ユーザに影響を及ぼす（悪天候などの）潜在的な危険に関するに警告メッセージの放送を自動的に遅延させることができる。その遅延は、例えば、通知の表示が、現在見ている番組がコマーシャルや宣伝によって中断するまで引き延ばされるように、適用されうる。しかしながら、この場合にもまた、後続の警告がユーザにとって不便であるという問題が残る。
【課題を解決するための手段】
【００１０】
本発明は、データ処理装置を提供する。
当該データ処理装置は、上記装置や、上記装置に接続された他の装置におけるデータ処理イベントに応じてユーザへの通知を提供するように構成された通知コントローラと、
通知された前記データ処理イベントに関するデータ処理タスクを実行するためにユーザをユーザ通知に注目させることが可能なユーザインターフェースと、を具備する。
上記通知コントローラは、ユーザが上記ユーザインターフェースを用いて現在の通知に対処している間、他の通知を抑制するように構成される
。
【００１１】
本発明は、ある通知が、ユーザにとって有用であり便利である間は、ユーザの注意をその最初のある通知から逸らしてしまう他の通知のような一連の通知を受信することが、煩わしいものになりうることを認識している。
【００１２】
本発明は、ユーザが現在の通知に対処し終わるまで、後続の通知の提供を抑制すること（例えば、遅延させることや阻止すること）によって、この問題を解決する。
【００１３】
本発明の実施形態は、添付の図面を参照して、一例としてのみの目的によって以下に説明される。
【図面の簡単な説明】
【００１４】
【図１】ネットワーク装置一式の概略図である。
【図２】テレビ受信機の概略図である。
【図３】図２に示すテレビ受信機によるユーザ通知の処理を示した図面である。
【図４】ユーザがユーザ通知と相互作用していることを説明する概略図である。
【図５】通知を扱う概略フローチャートである。
【図６】ユーザ表示の概略図である。
【発明を実施するための形態】
【００１５】
図１は、ネットワーク装置一式を概略的に示している。図面を明確にするために、ほんの一部の装置のみが示されている。これらの装置とは、テレビ（ＴＶ）コンテンツプロバイダ１０、テレビ受信機２０、携帯電話３０、及び電子メールサーバ４０である。この全ての装置は、インターネット５０を介して通信する。更に、ＴＶコンテンツプロバイダ１０からＴＶ受信器２０への一方向放送信号パス、ＴＶ受信器２０の間の（ブルートゥース（登録商標）のような）短距離無線リンク、及びセル方式の電話ネットワーク（不図示）がある。
【００１６】
勿論、図面は簡潔な形式で示されている。例えば、大抵の場合、ＴＶコンテンツプロバイダとＴＶ受信機との間には、ＴＶ受信機からＴＶコンテンツプロバイダへ番組指定、制御メッセージ、及び統計情報を返送するための双方向リンクが存在することを理解されたい。また勿論、このタイプの実際のネットワークには、４つより遥かに多くのノードが存在する。
【００１７】
ＴＶコンテンツプロバイダからテレビ受信機への放送パスは、地上波無線リンク、衛星無線リンク、電気や光のケーブルリンク、又はこれらのさらなる組み合わせであってもよい。
【００１８】
ＴＶコンテンツプロバイダ１０はテレビ番組ガイド（ＥＰＧ）データをＴＶ受信機２０に送る。受信機は、ユーザにＥＰＧデータを表示することができる。これによりユーザは、今見るＴＶ番組を選択したり、後で見る放送予定のＴＶ番組を選択することで予約を設定したりするといった様々なことを行うことができる。
【００１９】
ＴＶ受信機２０は、そのインターネット接続を介して、電子メールサーバ４０に保存された電子メールにアクセスできるように構成されている。これを行うために、ＴＶ受信機は、電子メールアプリケーションプログラムを実行する。当該プログラムは、定期的な間隔で電子メールサーバ４０の新規電子メールチェックを行い、または新規電子メールが電子メールサーバに届いた場合はいつでも、電子メールサーバによって起動され、いわゆる「プッシュ」通知として新規電子メールを受信する。電子メールサーバは、映像再生サービス、ソーシャルネットワーキングサービスなどの、ＴＶ受信機２０がアクセス可能である多くのインターネットベースのサービスのほんの一例である。
【００２０】
ＴＶ受信機２０は、コンテンツプロバイダによって送信される音声コンテンツ／映像コンテンツを受信し、またそれをユーザへの出力として再生するように構成された多くの受信機の一例である。
【００２１】
図２は、ネットワーク装置の一例としてのテレビ受信機を概略的に示している。ＴＶ受信機２０は、バス１００と、当該バス１００に接続される、ＣＰＵ（Central Processing Unit）１１０、順番に表示スクリーン１３０とラウドスピーカ１４０とに接続される音声／映像（Ａ／Ｖ）インターフェース１２０、ＴＶコンテンツプロバイダ１０からの放送テレビ信号を受信するための信号受信機１５０、光学式キーボード１６０（テレビ受信機の筐体内に配置されていてもよい）、メモリ１７０、不揮発性記憶装置１８０、及びリモートコントローラ２００との無線接続や携帯電話３０との無線接続といったインターネット接続を確立するインプット／アウトプット（Ｉ／Ｏ）コントローラ１９０と、を具備する。
【００２２】
動作中に、ＣＰＵは、ＴＶ受信機の機能を制御するために、及び／又は、メモリ１７０に一時的に記録されうるデータを処理するために、不揮発性記憶装置１８０に格納されたソフトウェアの制御下で動作する。しかしながら、勿論、ＴＶ受信機は、少なくとも部分的には、ハードウェアや、特別な集積回路やフィールド・プログラマブル・ゲート・アレイのようなＳＰＨＷ（半プログラム制御ハードウェア）として動作する。
【００２３】
ソフトウェアは、例えば、信号受信機１５０によって受信される映像や音声の信号に適用される信号処理機能に関連していてもよい。ソフトウェアの他の特徴は、電子メールサーバ４０のような他の接続された装置との通信に関連していてもよい。このようなタイプの機能では、ソフトウェアは実質的に従来型でもよい。換言すると、ＴＶ受信機２０が（例えば）電子メールサーバと相互作用する方法は、以下に詳細に記載された特別な機能に関すること以外は、電子メールクライアントと電子メールサーバとの標準の相互作用に従う。
【００２４】
本発明の実施形態に特に関連する、このソフトウェアの更なる機能は、ユーザ警告やユーザ通知の処理に関する。
【００２５】
図３は、ユーザ通知の処理を示した概略図である。特に、図３は、通知コントローラ２１０を示す。通知コントローラ２１０は、通知データ（このようなデータのソースは後述する）や、キーボード１６０やリモートコントローラ２００からのユーザインターフェース（ＵＩ）データを受信し、格納された優先データ２２０と選択的に相互作用する。通知コントローラからの出力は、Ａ／Ｖインターフェース１２０に送られる。
【００２６】
通知コントローラ２１０は、このように、その装置や、当該装置が接続された他の装置において、（通信や、エラーや、リマインダなどの開始のような）データ処理イベントに応じたユーザへの通知を提供するように構成されている。大まかに言えば、装置におけるデータ処理イベントは、その装置によって生じるイベント、すなわち、異なるユーザや、タイマーや、異なるデータ処理装置における動作や、そのデータ処理装置の状態の変化等によって開始されるイベントを示している。
【００２７】
図２はＴＶ受信機２０の構成を示しているのに対し、図３は、ＴＶ受信機内の異なる複数の機能の論理的な相互作用について説明するために、図２と同じ構成要素を異なる視点で示している。それゆえ、通知コントローラ２１０は実際には、適切なソフトウェアを実行しているＣＰＵ１１０によって実現され、優先データ２２０は実際にメモリ１７０の適切な部分に格納され、図３に示される機能的なユニットとの間の相互作用はバス１００上のデータや他の通信に相当する。
【００２８】
ユーザ通知に関するＴＶ受信機の動作は図４ａ〜図４ｄ、図５を参照して説明される。
【００２９】
図４ａは、ＴＶ受信機２０のディスプレイ１３０上に示された（サッカーゲームの）テレビ画像の概略図である。ＴＶ受信機２０は、ユーザのために、電子メールサーバ４０のような電子メールサーバと相互作用する。このようにすることにより、ＴＶ受信機２０は新規電子メールが電子メールサーバに待機している旨の電子メールサーバからの通知を受信し、より一般的には、電子メールサーバから新規電子メールを取得し、その後ユーザが、電子メールが届いていることを知ることができるように、ユーザへの表示のための通知を生成する。このような表示通知の例２３０は、表示されたテレビ画面上に重畳されて概略的に示されている。
【００３０】
音声の通知が、表示通知の代わりに又は表示通知に加えて用いられてもよいことが理解されるであろう。また、通知は、異なる装置に提供されてもよく、例えば、ＴＶ受信機に関する通知が携帯電話３０に提供されてもよい。
【００３１】
表示通知２３０は、通知コントローラ２１０によって生成される。通知コントローラは通知データ（この場合、ＴＶ受信機の電子メールアプリケーションである）の受信に応答し、表示通知２３０を生成する。
【００３２】
ユーザは通知２３０を無視する選択もでき、この場合、通知コントローラ２１０は、無視された通知が所定期間（例えば３０秒）の後削除されるように構成されていてもよく、その代わりに通知コントローラ２１０は、通知が無視された場合、無視された通知が無期限に見える状態のままにするように構成されていてもよい。ここで、「無期限に」は、ＴＶ受信機の電源がオフにされるまで、他の通知が受信されるまで、ユーザが最終的に通知を処理するまでのいずれをも意味する。
【００３３】
ユーザ側の他の選択は通知を拒絶する（閉じる、表示をオフにする）ことである。これは、通知が表示されときに選択的なオプションとして提示されてもよい。通知の拒絶は必ずしも通知の根本的な原因に影響を与えず、例えば、新規電子メールが届いた通知を拒絶してもその電子メール自体が消去されることにはならない。しかし、通知の拒絶は、通知コントローラ２１０にディスプレイから表示通知２３０を消去させることもある。
【００３４】
更なるオプションは、ユーザが通知に対処することである。これは、ユーザがただ通知を拒絶するのではなく、通知に応答して何かをすることを意味する。例えば、その通知が電子メールの受信に関するものとすると、ユーザは（例えば、表示通知２３０と関連するメニューコマンドを選択することによって、又は単にカーソルを表示通知２３０に移動させることによって）対応する電子メールの閲覧を選ぶことができる。この状況は、図４ｂに概略的に示されており、ここでユーザは表示通知２４０として画面に示された電子メールを閲覧することを選択している。一般的に、データ処理イベントに関する通知に対処するためのデータ処理タスクを実行することは、ユーザインターフェースを介し、通知されたデータ処理イベントに関する、ユーザと当該通知との間、及び／又はユーザと装置との間の、相互作用を含む。
【００３５】
したがって、キーボード１６０やリモートコントローラ２００のようなアイテムは、ユーザが通知されたデータ処理イベントに関連するデータ処理タスクを実行するためにユーザ通知に対処するためのユーザインターフェースを提供することができる。
【００３６】
ここで、図４ａ〜図４ｄの図面において背後に示されたサッカー選手の映像画像は同一であるが、実際には、プレイ中のサッカー選手の映像は、表示通知２３０が表示されたときと、ユーザが対応するメッセージ２４０を開くときとで変化しうる。しかしここでは、単に簡略化のために同じ画像が用いられている。
【００３７】
ユーザが表示された電子メールメッセージ２４０を閲覧し、将来的にそれに応答する期間は、ユーザがその通知に対処している時間と見なされる。換言すると、ユーザは、表示通知に応答してＴＶ受信機２０を使った実質的な動作を行う。以下に記載された構成で、この通知に対処する行為は、その通知の特定の根本的な原因（例えば、特定の電子メール）を処理することにのみに関連している場合もあれば、ユーザが通知に応答した後の、電子メールアプリケーションが開いたままの状態にある連続的な時間全体に関連している場合もある。
【００３８】
図４ｃは、ユーザがメッセージ２４０として表示された電子メールを閲覧し、又は応答することにより最初の通知に対処しているときに、他の通知２３０’が通知コントローラ２１０によって表示されている、好ましくない状況を概略的に示している。これは、まさに本実施形態がその防止を目的としている状況である。ユーザは、最初の通知に対処しようとしているにもかかわらず、後続する通知によっていちいち気が散ってしまう虞がある。
【００３９】
したがって、本発明の実施形態では、後続の通知２３０’の（通知コントローラ２１０による）表示が、ユーザが最初の通知に対処することをやめるまで、例えば、電子メールアプリケーションを閉じるか又は最小化する（アイコンに収縮する）まで、抑制される。図面４ｄを参照すると、ユーザが現在の通知に対処することをやめると、通知コントローラは後続の通知２３０’を表示することを許容される。このように、通知コントローラ２１０は、ユーザがユーザインターフェースを用いて現在の通知に対処している間、更なる通知を抑制するように構成されている。
【００４０】
この技術の背後における処理の一例が、図５の概略フローチャートの参照により説明される。
【００４１】
ステップ３００では、新規な通知に起因するデータ処理イベントに関する情報が通知コントローラ２１０によって受信されるか、通知コントローラ２１０によって、通知が待ち行列（キュー）に入っていることが検出される（下記参照）。
【００４２】
ステップ３１０では、通知コントローラ２１０は、ユーザが前の通知に対処しているかどうかを検出する。これは、図５には包括的な質問「ＵＩビジー？」と略されており、いくつかの実施形態では、単に（電子メールアプリケーションやソーシャルネットワーキングアプリケーションのような）アプリケーションが現在、動作モードを実行しているか、換言すると、アプリケーションが、ユーザがデータを入力するような、又はそのアプリケーションからデータを閲覧するような状態で表示されているかどうかについてのテスト（ａ）を含む。（誤解を避けるため、本発明の実施形態では、ユーザが何らかの関連する動作を行うことなく、アイコン２３０のような通知アイコンが存在しているだけでは、ＵＩがビジーであることを表しているとは見なさないこととする。）
【００４３】
より複雑な実施形態では、現在、前に受信した通知に関するアプリケーションを開いているかどうかについての２番目のテスト（ｂ）が適用されうる。そのため、例えば、前に受信した通知が受信した電子メールに関するものであり、現在開いているアプリケーションが電子メールツールである場合、ユーザは電子メールツールが最小化するか閉じられるまで、その通知に対処すると考えられる。
【００４４】
更なるレベルのテスト（ｃ）は、ユーザが閲覧している実際の電子メールが、通知が表示された電子メールまたは当該電子メールへの返答であるか否かについてのテストである。または当該テスト（ｃ）は、ソーシャルネットワーキング通知の場合には、ユーザが現在見ている情報が、通知が関連している人物についての情報であるか否かについてのテストである。
【００４５】
ユーザが通知に対処しているかどうかについてのさらに追加的なレベルのテスト（ｄ）は、ユーザが最後に、文字入力やカーソル移動のようなＵＩコマンドを発してから経過した時間を検出することである。この時間が所定の閾値（例えば１分）を超えた場合、ユーザはもはやその通知に対処する意思がないものと見なされる。
【００４６】
これらのテスト（ａ）〜（ｄ）は、通知コントローラが、ＣＰＵ１１０によって実行される他のプロセスや、キーボード１６０及びＩ／Ｏコントローラ１９０との相互作用を介して、ユーザがまだ前の通知に対処しているかどうかを検出する方法の例示にすぎない。これらのテストは、単独で、又は他と順次置き換えられて実行され得る。
【００４７】
ユーザが前の通知に対処していないことが検出された場合、ステップ３２０において、通知コントローラは、新規に検出されたイベントをユーザに知らせるために通知を表示させる。ステップ３３０では、ユーザは上述した通知に対処することができ、処理は、その通知に関しては終了する。
【００４８】
しかしながら、ステップ３１０でユーザが前の通知に対処していることが検出された場合、ステップ３４０において、新規の通知が、通知コントローラ２１０によって（メモリ１７０に）保持されているキューに入っているか否かを検出される。通知が既にキューに入っていれば、処理は終了する。一方、通知がキューに入っていない場合、ステップ３５０において、新規の通知がキューに加えられ、処理が終了する。このように、通知コントローラ２１０は、ユーザが現在の通知に対処することをやめるまでの、ユーザがユーザインターフェースを用いて現在の通知に対処している間、いかなる他の通知も保留するように構成されていてもよい。通知コントローラは、ユーザがユーザインターフェースを用いて現在の通知に対処している間、いかなる更なる通知をも含むキューを生成及び／又は保持することによって、かつ、ユーザが現在の通知に対処し終わった時点で当該キューに関する通知を提供することによって、上記通知の保留を達成することができる。
【００４９】
通知は、その装置又はその装置に接続された他の装置におけるデータ処理イベントに応答するものである。したがって、例えば、電子メールサーバへの電子メールの到着、遠隔サーバにおけるチャットやボイスコールの開始、又はＴＶ受信機に保存されたアラーム時刻への現時刻の到達が、それぞれ通知を引き起こすデータ処理イベントと見なされる。
【００５０】
上述したように、図５に示した処理は、全く新規の通知が開始され、又は通知コントローラが、通知がキューに入っていることを検出したときに開始される。後者の場合、処理は、キューのうち先頭の通知について実行される。この先頭の通知は、例えば、キューのうち最初に受信された通知として定義され、又はこれに代わって、キューのうち直前に追加された通知として定義される。図５の処理を連続的に実行する際の処理のオーバーヘッドを回避するため、通知コントローラ２１０は、通知がキューに存在するか否かを所定の時間間隔（例えば６０秒毎）でチェックすることができる。
【００５１】
未表示の通知がキューへ格納されるのは、通知が、ユーザが前の通知に対処している間、その表示を抑制される状況における、１つの結果である。上記状況におけるもう１つの結果は、通知コントローラが、このような新規に受信した通知を、ユーザがまだ前の通知に対処しているために直ちに表示できない場合に、自動的に拒絶することである。別の形態では、通知コントローラが、通知を、ユーザに表示することなく所定時間（例えば５分）だけ、キューに保持した後に、自動的に拒絶してもよい。
【００５２】
本実施形態のシステムは、ユーザが他の装置を用いた通知に対処できるように構成されていてもよい。そのため、例えば、ユーザが携帯電話３０を操作することによってＴＶ受信機２０の通知に対処することができる。この場合、ステップ３１０は、ユーザが携帯電話３０によって通知に対処することでビジーであるかどうかについてのテストを含む。
【００５３】
図５の構成の他の形態では、通知コントローラが、異なるタイプの通知と関連しうる、図３の優先データ２２０を保持する。この優先データ２２０は、異なるタイプの通知と関連しており、特定のタイプの通知が、ユーザが現在の通知に対処している間にその提供を許容されるかどうかを定義する。この優先データは通知の優先順位を表しており、図５におけるステップ３１０の「Ｙｅｓ」の分岐とステップ３４０との間に入り込みうるさらなるテストと関連している。つまり「新規に受信した通知は、優先データの中で、ユーザが現在対処している通知よりも高い優先度にあるか？」といったテストである。（ここで、このさらなるテストがステップ３１０の一部（分岐）として明確に識別されないとすれば、上記「ユーザが現在対処している通知」は、「前の通知」と同義である。）
【００５４】
追加のテストの答えが「ｙｅｓ」である場合、制御はステップ３２０に進み、ユーザが前の通知に対処している場合であっても、ユーザには新規の通知が知らされる。上記答えがｎｏである場合、制御は上述と同様にステップ３４０に進む。
【００５５】
優先データは下記の表１に示す形態をとりうる。小さい番号の優先レベルは高い優先度を示し、例えば、優先度１通知は優先度２通知よりも高い優先度である。
【００５６】
【表１】
【００５７】
二つの通知が優先データにおいて等しいレベルであるとき、上記の新規テストに対する答えはもちろん「ｎｏ」であり、制御はステップ３４０に進む。
【００５８】
優先データの他の使用例では、例えば、その装置がハンズフリーコールを提供する携帯電話とブルートゥースで接続されたカーラジオ受信機であるとすると、交通ニュース速報が優先度１を有するものとされ、音声通話コール（着信）が優先度２を有するものとされる。このように、交通ニュースは一時的に音声コールに割り込むが、音声コールは、交通ニュースが既に始まっている場合には、交通ニュースには割り込まない。その代わりに、ＴＶ受信機では、ユーザが音声コールを受けたことの通知は、ユーザが受信メールに対処することよりも高い優先度と考えられる。
【００５９】
優先データの他の使用例は、表示のための通知のキュー（図５のステップ３４０及びステップ４５０参照）は、以下の（ａ）〜（ｃ）に示されるように維持される。
【００６０】
（ａ）通知を受信した時刻に応じ、ＵＩがビジーでなくなった場合、ユーザに知らせる次の通知はその優先度に関わらず最も早く受信した通知とする。
【００６１】
（ｂ）優先度に応じ、先に受信された低い優先度の通知よりも先に、より高い優先度の通知がユーザに知らされる。
【００６２】
（ｃ）（ａ）と（ｂ）との組み合わせとして、原則的にキューの構築順を決定するには通知の優先度が用いられるが、優先度が等しい通知間で通知順を決定するには受信時刻が用いられる。
【００６３】
優先データはまた、異なる割り込み発信元の間にも適用されうる。そのため、例えば、友達Ａから届いた電子メールは、ユーザによって（又は下記の通知コントローラによる検出によって）友達Ｂから届いた電子メールより高い優先度に設定されうる。
【００６４】
優先データは予め決定しておくことができる。その代わりに、優先データは最初に（例えば、予め決定されたデータの初期設定として）設定されるが、通知コントローラは、ユーザが通常、どのタイプの通知に対して応答する及び／又は対処するかを検出（学習）し、（ステップ３１０におけるテストを用いて）、その検出結果に応じて優先データを修正又は変更することができる。このように、システムは（予め決定されたタイプの設定から）ユーザが応答するのはどのタイプの通知であり、それゆえそのタイプの通知が重要と考えられるかを検出できる。例えば、通知コントローラは、ユーザがより高い優先度のタイプの通知よりもより低い優先度のタイプの通知への返答する可能性が（およそ）１０倍である場合、優先データにおける二つの通知タイプの優先ポジションを切り替えることができる。
【００６５】
この発明の実施形態では、ＴＶ受信機２０は、表示されている又は対処されているユーザ通知に応じて、現在表示されている番組の記録を自動的に始める。それゆえ、これは、ステップ３２０（記録が、表示された通知に応じて開始される場合）、又はステップ３３０（記録が、ユーザが対処している通知に応じて開始される場合）に関連した追加的なステップである。これは、ユーザが通知によって気が散ってしまった場合でも、ユーザが現在見ている番組の部分を見逃すのを防止できることを意味する。
【００６６】
記録の開始は様々な異なる形態を採ることができる。
（ｉ）ＴＶ受信機は、不揮発性記憶装置１８０（例えば、ハードディスクドライブ）に現在表示されている番組を記録し始める一方で、番組を表示し続けることもできる。ユーザインタフェースは、ユーザが、記録された番組を記録の最初から再生できるように構成されている。この場合、不揮発性記憶装置１８０が番組データの一部の一時的なバッファとして動作するように、記録とその後の再生はその番組の最後まで継続している必要がある。
（ｉｉ）ＴＶ受信機は、不揮発性記憶装置１８０（例えば、ハードディスクドライブ）に現在表示されている番組を記録し始める一方で、番組の表示を一時停止することもできる。ユーザインタフェースは、ユーザが、記録された番組の視聴をその一時停止された状態から継続することができるように構成されており、及び／又は一時停止からの再開が、ユーザがシステムを一時停止させている通知に対処し終わった時点で自動的に開始されることができる。この場合、不揮発性記憶装置１８０が番組データの一部の一時的なバッファとして動作するように、記録とその後の再生はその番組の最後まで継続している必要がある。
（ｉｉｉ）ＴＶ受信機が、表示された番組を不揮発性記憶装置１８０にバッファリングしてユーザに生の番組を一時停止させることが可能なタイプである場合、通知されたときや、（場合によっては）ユーザがその通知に対処しているときに、ＴＶ受信機は、自身が有する機能を用いた一時停止を開始するか、再生を継続しながら、通知が表示され又は対処された時間を示すタイムマーカ（またはフラグ）を記録する。ユーザインターフェースは、ユーザが、記録データ上で、タイムマーカに対応する時間まで戻る（スキップバックする）ことができるように構成されている。
【００６７】
特にキーボード１６０のようなＵＩが動作する方法に影響を与える通知もある。例えば、エンターキーのような特定のＵＩ制御の「制御を奪い」、このようなキーが押された場合に、それに最初に応答する最前面の表示オブジェクトとなる通知もある。そのため、例えば、ユーザがディスプレイ１３０を見ずにタイピングし、このような通知があらわれる場合、ユーザがタイピングをそのまま続けることによって、（ａ）ユーザが使っていると思っているアプリケーションよりもむしろ通知に対してタイピングが入力されてしまい、又は、（ｂ）通知が認識する文字（例えばエンターキー）が押されるまで、タイピングが無視される。これはユーザを苛立たせる場合もある。
【００６８】
これに対する解決作が、図６ａ〜図６ｄに示されている。これらの図は、ユーザが、ワードプロセッサのようなテキスト入力アプリケーションを用いたタイピングを行うディスプレイを概略的に示した現在のタイピング位置はカーソル４００によって示されている。図６ａは通知が表示される前の状態を示している。図６ｂ及び図６ｃでは、通知２３０’’が表示された状態を示しているが、両者間にはおそらく５秒ほどの遅延時間が存在している。この遅延時間の間、表示された通知は（図６ｂ及び図６ｃに概略的に示されるように）薄く表示されるが、技術的に重要な特徴はこの遅延時間の間、表示された通知は最前面のオブジェクトとはならず、そのためタイピングの対象であるオブジェクトとはならないことである。これにより、遅延期間の間、ユーザはワードプロセッサアプリケーションにタイピングし続けることができ、したがってユーザは、表示された通知が、タイピングの対象となる最前面のオブジェクトとして取って代わる前に、図６ｄに示す位置までタイピングを完了することができる。この特徴の意図は、通知が（望ましくは聴覚的な補助通知と共に）表示されたことをユーザに認識させ、及びそれによってどのオブジェクトがユーザのタイピングに応答しているかをユーザに気付かせるための時間を与えることにある。
【００６９】
別の実施形態は、例えば、電子メール、ＳＭＳ、ソーシャルネットワーク、電話といった複合的なコミュニケーションに対する処理に関する。ユーザが、ここに述べたいずれかのコミュニケーション手段によって、友達Ａにコンタクトする例について考える。通知は、コミュニケーションの到着先となるユーザに提供される。ユーザが通知に対処すると決めた場合、想定される処理は、同時期に発生しうる友達Ｂ、友達Ｃ、友達Ｄなどからのいずれのコミュニケーションに関する通知も、ユーザが友達Ａからのコミュニケーションに対処し終わるまでキャッシュに格納されるというものである。
【００７０】
他の想定される処理は、友達Ｂ、友達Ｃ、友達Ｄのうちひとり以上が友達Ａより高い優先度であり、ユーザが友達Ａに対処している間であっても、彼らからのコミュニケーションが通知されるというものである。その優先度は、この一連のコミュニケーションの前に設定される。又は、優先度は、（例えば）友達Ｂが友達Ａからの元のコミュニケーションと同じテーマついて連絡しているとか、友達Ｂが、友達Ａが友達Ｂとユーザとの両方に送った同じ電子メールに対して返答しているといった事情からも生じうる。
【００７１】
ソーシャルネットワーキングチャットコミュニケーションの場合、ユーザが既にある友達からのコミュニケーションに関する通知に対処している場合、別の友達に関する通知は、「［友達Ｂ］がこのチャットセッションに参加することを許可しますか？」といった形態でのみ許容される。ユーザの答えが「ｎｏ」である場合には、その通知はキューに戻り、その後（ユーザが現在の通知に対処し終わった時に）、友達Ｂによるリクエストが、ユーザとの一対一のコミュニケーション用のものである状況に限って、通知される。
【００７２】
この発明の実施形態は、その限りにおいて、少なくとも部分的には、ソフトウェア制御のデータ処理装置によって実行されてもよい。このようなソフトウェアは、光ディスク、磁気ディスク、半導体メモリなどのような、当該ソフトウェアを記録した（またコンピュータプログラム製品として見なされる）非一時的コンピュータ可読記録媒体と同様に、本発明の実施形態を示すものと見なされることを理解されたい。
【技術分野】
【０００１】
本発明は、ユーザ通知に関する。
【背景技術】
【０００２】
ネットワークデバイスや接続デバイスのユーザは、当該デバイスやそれに接続された他のデバイスに関するイベントについての音声による通知及び／又は映像による通知や、警告メッセージ（「アラート」）を受ける。
【０００３】
ここで、「ネットワークデバイス」や「接続デバイス」という言葉は、例えば、電気ケーブルや、光接続や、無線や、これらの組み合わせによって、少なくともひとつの他のデバイスに、そのデバイスが接続可能であることを意味する。多くの場合には、このような接続は、インターネット接続や、一方向ブロードキャスト接続を介する、例えば、コンテンツプロバイダから当該デバイスへの接続や、携帯電話のようなポータブルデバイスを用いた短距離無線接続（例えば、ブルートゥース（登録商標）接続や、無線ネットワーク（「ＷｉＦｉ」）接続や、その他の適切なプロトコル接続）や、これらの組み合わせを介してなる。当該デバイスは、例えば、テレビやラジオの受信機や、コンピュータ端末や、携帯電話や、電子手帳などである。
【０００４】
このようなネットワークデバイスの一例としてテレビ受信機を挙げると、テレビ受信機は、インターネットに接続可能であり、電子メールや映像再生サービスやインスタントメッセージサービスなどのインターネットサービスと相互に作用することが知られている。
【０００５】
このようなシステムにおいて、ユーザ通知が生じる多くの場合がある。例えば、ユーザのテレビ受信機がインターネット電子メールアプリケーションを実行しているものとする。当該電子メールアプリケーションはバックグラウンドタスクとして動作し、そのため通常ユーザには見えない。しかしながら、ユーザに電子メールメッセージが届くと、電子メールアプリケーションは表示画面の中に小さい一時的な通知を表示する。ユーザは、当該通知に対応して電子メールメッセージを開き、電子メールアプリケーションをフルスクリーンで起動するか否かを選択することができる。「インターネット接続が切断されました」などの状況通知を表示可能なテレビ受信機や他のデバイスもある。
【０００６】
ユーザにはこのような通知を表示しない便宜が図られていることが知られている。この場合、当該通知は、ユーザが再び通知を許可するときにユーザが表示されていない間に受信した通知へのアクセスが可能となるように、バッファに格納される。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】米国特許出願公開第２００２／０１２４２５２号明細書
【特許文献２】米国特許出願公開第２０１０／０１３８８５８号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００８】
特許文献１は、ユーザが、特定のテレビチャンネルや特定のテレビ番組を見ている間に表示されることを許容する警告のタイプを定義する「プロフィール」を設定することが可能なテレビ受信機を開示している。しかしながら、特定の「許容する」警告タイプの複数の密集した警告をどのように扱うかという問題が残る。
【０００９】
特許文献２は、緊急通知システムに関連するテレビ受信機を開示している。このテレビ受信機は、ユーザに影響を及ぼす（悪天候などの）潜在的な危険に関するに警告メッセージの放送を自動的に遅延させることができる。その遅延は、例えば、通知の表示が、現在見ている番組がコマーシャルや宣伝によって中断するまで引き延ばされるように、適用されうる。しかしながら、この場合にもまた、後続の警告がユーザにとって不便であるという問題が残る。
【課題を解決するための手段】
【００１０】
本発明は、データ処理装置を提供する。
当該データ処理装置は、上記装置や、上記装置に接続された他の装置におけるデータ処理イベントに応じてユーザへの通知を提供するように構成された通知コントローラと、
通知された前記データ処理イベントに関するデータ処理タスクを実行するためにユーザをユーザ通知に注目させることが可能なユーザインターフェースと、を具備する。
上記通知コントローラは、ユーザが上記ユーザインターフェースを用いて現在の通知に対処している間、他の通知を抑制するように構成される
。
【００１１】
本発明は、ある通知が、ユーザにとって有用であり便利である間は、ユーザの注意をその最初のある通知から逸らしてしまう他の通知のような一連の通知を受信することが、煩わしいものになりうることを認識している。
【００１２】
本発明は、ユーザが現在の通知に対処し終わるまで、後続の通知の提供を抑制すること（例えば、遅延させることや阻止すること）によって、この問題を解決する。
【００１３】
本発明の実施形態は、添付の図面を参照して、一例としてのみの目的によって以下に説明される。
【図面の簡単な説明】
【００１４】
【図１】ネットワーク装置一式の概略図である。
【図２】テレビ受信機の概略図である。
【図３】図２に示すテレビ受信機によるユーザ通知の処理を示した図面である。
【図４】ユーザがユーザ通知と相互作用していることを説明する概略図である。
【図５】通知を扱う概略フローチャートである。
【図６】ユーザ表示の概略図である。
【発明を実施するための形態】
【００１５】
図１は、ネットワーク装置一式を概略的に示している。図面を明確にするために、ほんの一部の装置のみが示されている。これらの装置とは、テレビ（ＴＶ）コンテンツプロバイダ１０、テレビ受信機２０、携帯電話３０、及び電子メールサーバ４０である。この全ての装置は、インターネット５０を介して通信する。更に、ＴＶコンテンツプロバイダ１０からＴＶ受信器２０への一方向放送信号パス、ＴＶ受信器２０の間の（ブルートゥース（登録商標）のような）短距離無線リンク、及びセル方式の電話ネットワーク（不図示）がある。
【００１６】
勿論、図面は簡潔な形式で示されている。例えば、大抵の場合、ＴＶコンテンツプロバイダとＴＶ受信機との間には、ＴＶ受信機からＴＶコンテンツプロバイダへ番組指定、制御メッセージ、及び統計情報を返送するための双方向リンクが存在することを理解されたい。また勿論、このタイプの実際のネットワークには、４つより遥かに多くのノードが存在する。
【００１７】
ＴＶコンテンツプロバイダからテレビ受信機への放送パスは、地上波無線リンク、衛星無線リンク、電気や光のケーブルリンク、又はこれらのさらなる組み合わせであってもよい。
【００１８】
ＴＶコンテンツプロバイダ１０はテレビ番組ガイド（ＥＰＧ）データをＴＶ受信機２０に送る。受信機は、ユーザにＥＰＧデータを表示することができる。これによりユーザは、今見るＴＶ番組を選択したり、後で見る放送予定のＴＶ番組を選択することで予約を設定したりするといった様々なことを行うことができる。
【００１９】
ＴＶ受信機２０は、そのインターネット接続を介して、電子メールサーバ４０に保存された電子メールにアクセスできるように構成されている。これを行うために、ＴＶ受信機は、電子メールアプリケーションプログラムを実行する。当該プログラムは、定期的な間隔で電子メールサーバ４０の新規電子メールチェックを行い、または新規電子メールが電子メールサーバに届いた場合はいつでも、電子メールサーバによって起動され、いわゆる「プッシュ」通知として新規電子メールを受信する。電子メールサーバは、映像再生サービス、ソーシャルネットワーキングサービスなどの、ＴＶ受信機２０がアクセス可能である多くのインターネットベースのサービスのほんの一例である。
【００２０】
ＴＶ受信機２０は、コンテンツプロバイダによって送信される音声コンテンツ／映像コンテンツを受信し、またそれをユーザへの出力として再生するように構成された多くの受信機の一例である。
【００２１】
図２は、ネットワーク装置の一例としてのテレビ受信機を概略的に示している。ＴＶ受信機２０は、バス１００と、当該バス１００に接続される、ＣＰＵ（Central Processing Unit）１１０、順番に表示スクリーン１３０とラウドスピーカ１４０とに接続される音声／映像（Ａ／Ｖ）インターフェース１２０、ＴＶコンテンツプロバイダ１０からの放送テレビ信号を受信するための信号受信機１５０、光学式キーボード１６０（テレビ受信機の筐体内に配置されていてもよい）、メモリ１７０、不揮発性記憶装置１８０、及びリモートコントローラ２００との無線接続や携帯電話３０との無線接続といったインターネット接続を確立するインプット／アウトプット（Ｉ／Ｏ）コントローラ１９０と、を具備する。
【００２２】
動作中に、ＣＰＵは、ＴＶ受信機の機能を制御するために、及び／又は、メモリ１７０に一時的に記録されうるデータを処理するために、不揮発性記憶装置１８０に格納されたソフトウェアの制御下で動作する。しかしながら、勿論、ＴＶ受信機は、少なくとも部分的には、ハードウェアや、特別な集積回路やフィールド・プログラマブル・ゲート・アレイのようなＳＰＨＷ（半プログラム制御ハードウェア）として動作する。
【００２３】
ソフトウェアは、例えば、信号受信機１５０によって受信される映像や音声の信号に適用される信号処理機能に関連していてもよい。ソフトウェアの他の特徴は、電子メールサーバ４０のような他の接続された装置との通信に関連していてもよい。このようなタイプの機能では、ソフトウェアは実質的に従来型でもよい。換言すると、ＴＶ受信機２０が（例えば）電子メールサーバと相互作用する方法は、以下に詳細に記載された特別な機能に関すること以外は、電子メールクライアントと電子メールサーバとの標準の相互作用に従う。
【００２４】
本発明の実施形態に特に関連する、このソフトウェアの更なる機能は、ユーザ警告やユーザ通知の処理に関する。
【００２５】
図３は、ユーザ通知の処理を示した概略図である。特に、図３は、通知コントローラ２１０を示す。通知コントローラ２１０は、通知データ（このようなデータのソースは後述する）や、キーボード１６０やリモートコントローラ２００からのユーザインターフェース（ＵＩ）データを受信し、格納された優先データ２２０と選択的に相互作用する。通知コントローラからの出力は、Ａ／Ｖインターフェース１２０に送られる。
【００２６】
通知コントローラ２１０は、このように、その装置や、当該装置が接続された他の装置において、（通信や、エラーや、リマインダなどの開始のような）データ処理イベントに応じたユーザへの通知を提供するように構成されている。大まかに言えば、装置におけるデータ処理イベントは、その装置によって生じるイベント、すなわち、異なるユーザや、タイマーや、異なるデータ処理装置における動作や、そのデータ処理装置の状態の変化等によって開始されるイベントを示している。
【００２７】
図２はＴＶ受信機２０の構成を示しているのに対し、図３は、ＴＶ受信機内の異なる複数の機能の論理的な相互作用について説明するために、図２と同じ構成要素を異なる視点で示している。それゆえ、通知コントローラ２１０は実際には、適切なソフトウェアを実行しているＣＰＵ１１０によって実現され、優先データ２２０は実際にメモリ１７０の適切な部分に格納され、図３に示される機能的なユニットとの間の相互作用はバス１００上のデータや他の通信に相当する。
【００２８】
ユーザ通知に関するＴＶ受信機の動作は図４ａ〜図４ｄ、図５を参照して説明される。
【００２９】
図４ａは、ＴＶ受信機２０のディスプレイ１３０上に示された（サッカーゲームの）テレビ画像の概略図である。ＴＶ受信機２０は、ユーザのために、電子メールサーバ４０のような電子メールサーバと相互作用する。このようにすることにより、ＴＶ受信機２０は新規電子メールが電子メールサーバに待機している旨の電子メールサーバからの通知を受信し、より一般的には、電子メールサーバから新規電子メールを取得し、その後ユーザが、電子メールが届いていることを知ることができるように、ユーザへの表示のための通知を生成する。このような表示通知の例２３０は、表示されたテレビ画面上に重畳されて概略的に示されている。
【００３０】
音声の通知が、表示通知の代わりに又は表示通知に加えて用いられてもよいことが理解されるであろう。また、通知は、異なる装置に提供されてもよく、例えば、ＴＶ受信機に関する通知が携帯電話３０に提供されてもよい。
【００３１】
表示通知２３０は、通知コントローラ２１０によって生成される。通知コントローラは通知データ（この場合、ＴＶ受信機の電子メールアプリケーションである）の受信に応答し、表示通知２３０を生成する。
【００３２】
ユーザは通知２３０を無視する選択もでき、この場合、通知コントローラ２１０は、無視された通知が所定期間（例えば３０秒）の後削除されるように構成されていてもよく、その代わりに通知コントローラ２１０は、通知が無視された場合、無視された通知が無期限に見える状態のままにするように構成されていてもよい。ここで、「無期限に」は、ＴＶ受信機の電源がオフにされるまで、他の通知が受信されるまで、ユーザが最終的に通知を処理するまでのいずれをも意味する。
【００３３】
ユーザ側の他の選択は通知を拒絶する（閉じる、表示をオフにする）ことである。これは、通知が表示されときに選択的なオプションとして提示されてもよい。通知の拒絶は必ずしも通知の根本的な原因に影響を与えず、例えば、新規電子メールが届いた通知を拒絶してもその電子メール自体が消去されることにはならない。しかし、通知の拒絶は、通知コントローラ２１０にディスプレイから表示通知２３０を消去させることもある。
【００３４】
更なるオプションは、ユーザが通知に対処することである。これは、ユーザがただ通知を拒絶するのではなく、通知に応答して何かをすることを意味する。例えば、その通知が電子メールの受信に関するものとすると、ユーザは（例えば、表示通知２３０と関連するメニューコマンドを選択することによって、又は単にカーソルを表示通知２３０に移動させることによって）対応する電子メールの閲覧を選ぶことができる。この状況は、図４ｂに概略的に示されており、ここでユーザは表示通知２４０として画面に示された電子メールを閲覧することを選択している。一般的に、データ処理イベントに関する通知に対処するためのデータ処理タスクを実行することは、ユーザインターフェースを介し、通知されたデータ処理イベントに関する、ユーザと当該通知との間、及び／又はユーザと装置との間の、相互作用を含む。
【００３５】
したがって、キーボード１６０やリモートコントローラ２００のようなアイテムは、ユーザが通知されたデータ処理イベントに関連するデータ処理タスクを実行するためにユーザ通知に対処するためのユーザインターフェースを提供することができる。
【００３６】
ここで、図４ａ〜図４ｄの図面において背後に示されたサッカー選手の映像画像は同一であるが、実際には、プレイ中のサッカー選手の映像は、表示通知２３０が表示されたときと、ユーザが対応するメッセージ２４０を開くときとで変化しうる。しかしここでは、単に簡略化のために同じ画像が用いられている。
【００３７】
ユーザが表示された電子メールメッセージ２４０を閲覧し、将来的にそれに応答する期間は、ユーザがその通知に対処している時間と見なされる。換言すると、ユーザは、表示通知に応答してＴＶ受信機２０を使った実質的な動作を行う。以下に記載された構成で、この通知に対処する行為は、その通知の特定の根本的な原因（例えば、特定の電子メール）を処理することにのみに関連している場合もあれば、ユーザが通知に応答した後の、電子メールアプリケーションが開いたままの状態にある連続的な時間全体に関連している場合もある。
【００３８】
図４ｃは、ユーザがメッセージ２４０として表示された電子メールを閲覧し、又は応答することにより最初の通知に対処しているときに、他の通知２３０’が通知コントローラ２１０によって表示されている、好ましくない状況を概略的に示している。これは、まさに本実施形態がその防止を目的としている状況である。ユーザは、最初の通知に対処しようとしているにもかかわらず、後続する通知によっていちいち気が散ってしまう虞がある。
【００３９】
したがって、本発明の実施形態では、後続の通知２３０’の（通知コントローラ２１０による）表示が、ユーザが最初の通知に対処することをやめるまで、例えば、電子メールアプリケーションを閉じるか又は最小化する（アイコンに収縮する）まで、抑制される。図面４ｄを参照すると、ユーザが現在の通知に対処することをやめると、通知コントローラは後続の通知２３０’を表示することを許容される。このように、通知コントローラ２１０は、ユーザがユーザインターフェースを用いて現在の通知に対処している間、更なる通知を抑制するように構成されている。
【００４０】
この技術の背後における処理の一例が、図５の概略フローチャートの参照により説明される。
【００４１】
ステップ３００では、新規な通知に起因するデータ処理イベントに関する情報が通知コントローラ２１０によって受信されるか、通知コントローラ２１０によって、通知が待ち行列（キュー）に入っていることが検出される（下記参照）。
【００４２】
ステップ３１０では、通知コントローラ２１０は、ユーザが前の通知に対処しているかどうかを検出する。これは、図５には包括的な質問「ＵＩビジー？」と略されており、いくつかの実施形態では、単に（電子メールアプリケーションやソーシャルネットワーキングアプリケーションのような）アプリケーションが現在、動作モードを実行しているか、換言すると、アプリケーションが、ユーザがデータを入力するような、又はそのアプリケーションからデータを閲覧するような状態で表示されているかどうかについてのテスト（ａ）を含む。（誤解を避けるため、本発明の実施形態では、ユーザが何らかの関連する動作を行うことなく、アイコン２３０のような通知アイコンが存在しているだけでは、ＵＩがビジーであることを表しているとは見なさないこととする。）
【００４３】
より複雑な実施形態では、現在、前に受信した通知に関するアプリケーションを開いているかどうかについての２番目のテスト（ｂ）が適用されうる。そのため、例えば、前に受信した通知が受信した電子メールに関するものであり、現在開いているアプリケーションが電子メールツールである場合、ユーザは電子メールツールが最小化するか閉じられるまで、その通知に対処すると考えられる。
【００４４】
更なるレベルのテスト（ｃ）は、ユーザが閲覧している実際の電子メールが、通知が表示された電子メールまたは当該電子メールへの返答であるか否かについてのテストである。または当該テスト（ｃ）は、ソーシャルネットワーキング通知の場合には、ユーザが現在見ている情報が、通知が関連している人物についての情報であるか否かについてのテストである。
【００４５】
ユーザが通知に対処しているかどうかについてのさらに追加的なレベルのテスト（ｄ）は、ユーザが最後に、文字入力やカーソル移動のようなＵＩコマンドを発してから経過した時間を検出することである。この時間が所定の閾値（例えば１分）を超えた場合、ユーザはもはやその通知に対処する意思がないものと見なされる。
【００４６】
これらのテスト（ａ）〜（ｄ）は、通知コントローラが、ＣＰＵ１１０によって実行される他のプロセスや、キーボード１６０及びＩ／Ｏコントローラ１９０との相互作用を介して、ユーザがまだ前の通知に対処しているかどうかを検出する方法の例示にすぎない。これらのテストは、単独で、又は他と順次置き換えられて実行され得る。
【００４７】
ユーザが前の通知に対処していないことが検出された場合、ステップ３２０において、通知コントローラは、新規に検出されたイベントをユーザに知らせるために通知を表示させる。ステップ３３０では、ユーザは上述した通知に対処することができ、処理は、その通知に関しては終了する。
【００４８】
しかしながら、ステップ３１０でユーザが前の通知に対処していることが検出された場合、ステップ３４０において、新規の通知が、通知コントローラ２１０によって（メモリ１７０に）保持されているキューに入っているか否かを検出される。通知が既にキューに入っていれば、処理は終了する。一方、通知がキューに入っていない場合、ステップ３５０において、新規の通知がキューに加えられ、処理が終了する。このように、通知コントローラ２１０は、ユーザが現在の通知に対処することをやめるまでの、ユーザがユーザインターフェースを用いて現在の通知に対処している間、いかなる他の通知も保留するように構成されていてもよい。通知コントローラは、ユーザがユーザインターフェースを用いて現在の通知に対処している間、いかなる更なる通知をも含むキューを生成及び／又は保持することによって、かつ、ユーザが現在の通知に対処し終わった時点で当該キューに関する通知を提供することによって、上記通知の保留を達成することができる。
【００４９】
通知は、その装置又はその装置に接続された他の装置におけるデータ処理イベントに応答するものである。したがって、例えば、電子メールサーバへの電子メールの到着、遠隔サーバにおけるチャットやボイスコールの開始、又はＴＶ受信機に保存されたアラーム時刻への現時刻の到達が、それぞれ通知を引き起こすデータ処理イベントと見なされる。
【００５０】
上述したように、図５に示した処理は、全く新規の通知が開始され、又は通知コントローラが、通知がキューに入っていることを検出したときに開始される。後者の場合、処理は、キューのうち先頭の通知について実行される。この先頭の通知は、例えば、キューのうち最初に受信された通知として定義され、又はこれに代わって、キューのうち直前に追加された通知として定義される。図５の処理を連続的に実行する際の処理のオーバーヘッドを回避するため、通知コントローラ２１０は、通知がキューに存在するか否かを所定の時間間隔（例えば６０秒毎）でチェックすることができる。
【００５１】
未表示の通知がキューへ格納されるのは、通知が、ユーザが前の通知に対処している間、その表示を抑制される状況における、１つの結果である。上記状況におけるもう１つの結果は、通知コントローラが、このような新規に受信した通知を、ユーザがまだ前の通知に対処しているために直ちに表示できない場合に、自動的に拒絶することである。別の形態では、通知コントローラが、通知を、ユーザに表示することなく所定時間（例えば５分）だけ、キューに保持した後に、自動的に拒絶してもよい。
【００５２】
本実施形態のシステムは、ユーザが他の装置を用いた通知に対処できるように構成されていてもよい。そのため、例えば、ユーザが携帯電話３０を操作することによってＴＶ受信機２０の通知に対処することができる。この場合、ステップ３１０は、ユーザが携帯電話３０によって通知に対処することでビジーであるかどうかについてのテストを含む。
【００５３】
図５の構成の他の形態では、通知コントローラが、異なるタイプの通知と関連しうる、図３の優先データ２２０を保持する。この優先データ２２０は、異なるタイプの通知と関連しており、特定のタイプの通知が、ユーザが現在の通知に対処している間にその提供を許容されるかどうかを定義する。この優先データは通知の優先順位を表しており、図５におけるステップ３１０の「Ｙｅｓ」の分岐とステップ３４０との間に入り込みうるさらなるテストと関連している。つまり「新規に受信した通知は、優先データの中で、ユーザが現在対処している通知よりも高い優先度にあるか？」といったテストである。（ここで、このさらなるテストがステップ３１０の一部（分岐）として明確に識別されないとすれば、上記「ユーザが現在対処している通知」は、「前の通知」と同義である。）
【００５４】
追加のテストの答えが「ｙｅｓ」である場合、制御はステップ３２０に進み、ユーザが前の通知に対処している場合であっても、ユーザには新規の通知が知らされる。上記答えがｎｏである場合、制御は上述と同様にステップ３４０に進む。
【００５５】
優先データは下記の表１に示す形態をとりうる。小さい番号の優先レベルは高い優先度を示し、例えば、優先度１通知は優先度２通知よりも高い優先度である。
【００５６】
【表１】
【００５７】
二つの通知が優先データにおいて等しいレベルであるとき、上記の新規テストに対する答えはもちろん「ｎｏ」であり、制御はステップ３４０に進む。
【００５８】
優先データの他の使用例では、例えば、その装置がハンズフリーコールを提供する携帯電話とブルートゥースで接続されたカーラジオ受信機であるとすると、交通ニュース速報が優先度１を有するものとされ、音声通話コール（着信）が優先度２を有するものとされる。このように、交通ニュースは一時的に音声コールに割り込むが、音声コールは、交通ニュースが既に始まっている場合には、交通ニュースには割り込まない。その代わりに、ＴＶ受信機では、ユーザが音声コールを受けたことの通知は、ユーザが受信メールに対処することよりも高い優先度と考えられる。
【００５９】
優先データの他の使用例は、表示のための通知のキュー（図５のステップ３４０及びステップ４５０参照）は、以下の（ａ）〜（ｃ）に示されるように維持される。
【００６０】
（ａ）通知を受信した時刻に応じ、ＵＩがビジーでなくなった場合、ユーザに知らせる次の通知はその優先度に関わらず最も早く受信した通知とする。
【００６１】
（ｂ）優先度に応じ、先に受信された低い優先度の通知よりも先に、より高い優先度の通知がユーザに知らされる。
【００６２】
（ｃ）（ａ）と（ｂ）との組み合わせとして、原則的にキューの構築順を決定するには通知の優先度が用いられるが、優先度が等しい通知間で通知順を決定するには受信時刻が用いられる。
【００６３】
優先データはまた、異なる割り込み発信元の間にも適用されうる。そのため、例えば、友達Ａから届いた電子メールは、ユーザによって（又は下記の通知コントローラによる検出によって）友達Ｂから届いた電子メールより高い優先度に設定されうる。
【００６４】
優先データは予め決定しておくことができる。その代わりに、優先データは最初に（例えば、予め決定されたデータの初期設定として）設定されるが、通知コントローラは、ユーザが通常、どのタイプの通知に対して応答する及び／又は対処するかを検出（学習）し、（ステップ３１０におけるテストを用いて）、その検出結果に応じて優先データを修正又は変更することができる。このように、システムは（予め決定されたタイプの設定から）ユーザが応答するのはどのタイプの通知であり、それゆえそのタイプの通知が重要と考えられるかを検出できる。例えば、通知コントローラは、ユーザがより高い優先度のタイプの通知よりもより低い優先度のタイプの通知への返答する可能性が（およそ）１０倍である場合、優先データにおける二つの通知タイプの優先ポジションを切り替えることができる。
【００６５】
この発明の実施形態では、ＴＶ受信機２０は、表示されている又は対処されているユーザ通知に応じて、現在表示されている番組の記録を自動的に始める。それゆえ、これは、ステップ３２０（記録が、表示された通知に応じて開始される場合）、又はステップ３３０（記録が、ユーザが対処している通知に応じて開始される場合）に関連した追加的なステップである。これは、ユーザが通知によって気が散ってしまった場合でも、ユーザが現在見ている番組の部分を見逃すのを防止できることを意味する。
【００６６】
記録の開始は様々な異なる形態を採ることができる。
（ｉ）ＴＶ受信機は、不揮発性記憶装置１８０（例えば、ハードディスクドライブ）に現在表示されている番組を記録し始める一方で、番組を表示し続けることもできる。ユーザインタフェースは、ユーザが、記録された番組を記録の最初から再生できるように構成されている。この場合、不揮発性記憶装置１８０が番組データの一部の一時的なバッファとして動作するように、記録とその後の再生はその番組の最後まで継続している必要がある。
（ｉｉ）ＴＶ受信機は、不揮発性記憶装置１８０（例えば、ハードディスクドライブ）に現在表示されている番組を記録し始める一方で、番組の表示を一時停止することもできる。ユーザインタフェースは、ユーザが、記録された番組の視聴をその一時停止された状態から継続することができるように構成されており、及び／又は一時停止からの再開が、ユーザがシステムを一時停止させている通知に対処し終わった時点で自動的に開始されることができる。この場合、不揮発性記憶装置１８０が番組データの一部の一時的なバッファとして動作するように、記録とその後の再生はその番組の最後まで継続している必要がある。
（ｉｉｉ）ＴＶ受信機が、表示された番組を不揮発性記憶装置１８０にバッファリングしてユーザに生の番組を一時停止させることが可能なタイプである場合、通知されたときや、（場合によっては）ユーザがその通知に対処しているときに、ＴＶ受信機は、自身が有する機能を用いた一時停止を開始するか、再生を継続しながら、通知が表示され又は対処された時間を示すタイムマーカ（またはフラグ）を記録する。ユーザインターフェースは、ユーザが、記録データ上で、タイムマーカに対応する時間まで戻る（スキップバックする）ことができるように構成されている。
【００６７】
特にキーボード１６０のようなＵＩが動作する方法に影響を与える通知もある。例えば、エンターキーのような特定のＵＩ制御の「制御を奪い」、このようなキーが押された場合に、それに最初に応答する最前面の表示オブジェクトとなる通知もある。そのため、例えば、ユーザがディスプレイ１３０を見ずにタイピングし、このような通知があらわれる場合、ユーザがタイピングをそのまま続けることによって、（ａ）ユーザが使っていると思っているアプリケーションよりもむしろ通知に対してタイピングが入力されてしまい、又は、（ｂ）通知が認識する文字（例えばエンターキー）が押されるまで、タイピングが無視される。これはユーザを苛立たせる場合もある。
【００６８】
これに対する解決作が、図６ａ〜図６ｄに示されている。これらの図は、ユーザが、ワードプロセッサのようなテキスト入力アプリケーションを用いたタイピングを行うディスプレイを概略的に示した現在のタイピング位置はカーソル４００によって示されている。図６ａは通知が表示される前の状態を示している。図６ｂ及び図６ｃでは、通知２３０’’が表示された状態を示しているが、両者間にはおそらく５秒ほどの遅延時間が存在している。この遅延時間の間、表示された通知は（図６ｂ及び図６ｃに概略的に示されるように）薄く表示されるが、技術的に重要な特徴はこの遅延時間の間、表示された通知は最前面のオブジェクトとはならず、そのためタイピングの対象であるオブジェクトとはならないことである。これにより、遅延期間の間、ユーザはワードプロセッサアプリケーションにタイピングし続けることができ、したがってユーザは、表示された通知が、タイピングの対象となる最前面のオブジェクトとして取って代わる前に、図６ｄに示す位置までタイピングを完了することができる。この特徴の意図は、通知が（望ましくは聴覚的な補助通知と共に）表示されたことをユーザに認識させ、及びそれによってどのオブジェクトがユーザのタイピングに応答しているかをユーザに気付かせるための時間を与えることにある。
【００６９】
別の実施形態は、例えば、電子メール、ＳＭＳ、ソーシャルネットワーク、電話といった複合的なコミュニケーションに対する処理に関する。ユーザが、ここに述べたいずれかのコミュニケーション手段によって、友達Ａにコンタクトする例について考える。通知は、コミュニケーションの到着先となるユーザに提供される。ユーザが通知に対処すると決めた場合、想定される処理は、同時期に発生しうる友達Ｂ、友達Ｃ、友達Ｄなどからのいずれのコミュニケーションに関する通知も、ユーザが友達Ａからのコミュニケーションに対処し終わるまでキャッシュに格納されるというものである。
【００７０】
他の想定される処理は、友達Ｂ、友達Ｃ、友達Ｄのうちひとり以上が友達Ａより高い優先度であり、ユーザが友達Ａに対処している間であっても、彼らからのコミュニケーションが通知されるというものである。その優先度は、この一連のコミュニケーションの前に設定される。又は、優先度は、（例えば）友達Ｂが友達Ａからの元のコミュニケーションと同じテーマついて連絡しているとか、友達Ｂが、友達Ａが友達Ｂとユーザとの両方に送った同じ電子メールに対して返答しているといった事情からも生じうる。
【００７１】
ソーシャルネットワーキングチャットコミュニケーションの場合、ユーザが既にある友達からのコミュニケーションに関する通知に対処している場合、別の友達に関する通知は、「［友達Ｂ］がこのチャットセッションに参加することを許可しますか？」といった形態でのみ許容される。ユーザの答えが「ｎｏ」である場合には、その通知はキューに戻り、その後（ユーザが現在の通知に対処し終わった時に）、友達Ｂによるリクエストが、ユーザとの一対一のコミュニケーション用のものである状況に限って、通知される。
【００７２】
この発明の実施形態は、その限りにおいて、少なくとも部分的には、ソフトウェア制御のデータ処理装置によって実行されてもよい。このようなソフトウェアは、光ディスク、磁気ディスク、半導体メモリなどのような、当該ソフトウェアを記録した（またコンピュータプログラム製品として見なされる）非一時的コンピュータ可読記録媒体と同様に、本発明の実施形態を示すものと見なされることを理解されたい。
【特許請求の範囲】
【請求項１】
データ処理装置であって、
当該データ処理装置または、当該データ処理装置に接続された他の装置におけるデータ処理イベントに応じてユーザへの通知を提供するように構成された通知コントローラと、
通知された前記データ処理イベントに関するデータ処理タスクを実行するためのユーザ通知にユーザを対処させることが可能なユーザインターフェースと、を具備し、
前記通知コントローラは、ユーザが前記ユーザインターフェースを用いて現在のユーザ通知に対処している間、さらなるユーザ通知を抑制するように構成される
データ処理装置。
【請求項２】
請求項１に記載のデータ処理装置であって、
前記通知コントローラは、ユーザが前記ユーザインターフェースを用いて現在のユーザ通知に対処している間、前記現在のユーザ通知に対処し終わるまで、全てのさらなるユーザ通知を保留するように構成される
データ処理装置。
【請求項３】
請求項２に記載のデータ処理装置であって、
前記通知コントローラは、ユーザが前記ユーザインターフェースを用いて現在の通知に対処している間、全てのさらなるユーザ通知を含む待ち行列を生成し、ユーザが前記現在のユーザ通知に対処し終わった時点で前記待ち行列に含まれるユーザ通知を提供するように構成される
データ処理装置
【請求項４】
請求項１から３のいずれか１項に記載のデータ処理装置であって、
前記通知コントローラは、異なる複数のタイプのユーザ通知に関連する優先データを保持し、
前記優先データは、特定のタイプのユーザ通知が、ユーザが前記ユーザインターフェースを用いて現在のユーザ通知に対処している間に提供を許容されるべきか否かを定義する
データ処理装置。
【請求項５】
請求項４に記載のデータ処理装置であって、
前記通知コントローラは、ユーザがどのタイプのユーザ通知に対処しているかを検出し、当該検出結果に応じて前記優先データを変更するように構成される
データ処理装置。
【請求項６】
請求項１から５のいずれか１項に記載のデータ処理装置であって、
当該データ処理装置は、コンテンツプロバイダによって送信される音声／映像コンテンツを受信し、ユーザ出力として再生するように構成された受信機である
データ処理装置。
【請求項７】
請求項６に記載のデータ処理装置であって、
受信されたコンテンツを記録するためのコンテンツレコーダーと、
前記通知コントローラによるユーザ通知の提供に応じて、前記受信されたコンテンツの記録を開始するように構成された記録コントローラと、
を具備するデータ処理装置。
【請求項８】
請求項７に記載のデータ処理装置であって、
前記記録コントローラは、前記記録が開始された時刻を示すフラグを記録するように構成される
データ処理装置。
【請求項９】
請求項７または８に記載のデータ処理装置であって、
ユーザ通知の提供に応じて、前記受信されたコンテンツの再生を一時停止するように構成される
データ処理装置。
【請求項１０】
請求項９に記載のデータ処理装置であって、
前記ユーザが前記ユーザ通知に対処し終わった時点で、前記受信されたコンテンツの再生を再開するように構成される
データ処理装置。
【請求項１１】
請求項１から１０のいずれか１項に記載のデータ処理装置であって、
前記ユーザ通知は音声による通知及び／又は映像による通知である
データ処理装置。
【請求項１２】
コンテンツプロバイダによって送信された音声コンテンツ／映像コンテンツを受信し、ユーザ出力として再生するように構成された受信装置であって、
当該受信装置または、当該受信装置が接続された別の装置におけるデータ処理イベントに応じてユーザへの通知を提供するように構成された通知コントローラと、
前記通知コントローラによるユーザ通知の提供に応じて、前記受信されたコンテンツの記録を開始するように構成された記録コントローラと
を具備する受信装置。
【請求項１３】
データ処理装置の操作方法であって、
前記データ処理装置または、前記データ処理装置が接続された別の装置におけるデータ処理イベントに応じてユーザへの通知を提供し、
通知されたデータ処理イベントに関するデータ処理タスクを実行するためのユーザ通知にユーザを対処させることが可能なユーザインターフェースを提供し、
ユーザが前記ユーザインターフェースを用いて現在の通知に対処している間、他の通知を抑制する
データ処理装置の操作方法。
【請求項１４】
コンテンツプロバイダによって送信された音声コンテンツ／映像コンテンツを受信し、ユーザアウトプットとして再生するように構成された受信装置の操作方法であって、
前記受信装置または、前記受信装置が接続された別の装置におけるデータ処理イベントに応じてユーザへの通知を提供し、
前記ユーザ通知の提供に応じて、前記受信されたコンテンツの記録を開始する
受信装置の操作方法。
【請求項１５】
請求項１３に記載のデータ処理装置の操作方法における各ステップを当該データ処理装置に実行させ、又は請求項１４に記載の受信装置の操作方法における各ステップを当該受信装置に実行させるプログラム。
【請求項１】
データ処理装置であって、
当該データ処理装置または、当該データ処理装置に接続された他の装置におけるデータ処理イベントに応じてユーザへの通知を提供するように構成された通知コントローラと、
通知された前記データ処理イベントに関するデータ処理タスクを実行するためのユーザ通知にユーザを対処させることが可能なユーザインターフェースと、を具備し、
前記通知コントローラは、ユーザが前記ユーザインターフェースを用いて現在のユーザ通知に対処している間、さらなるユーザ通知を抑制するように構成される
データ処理装置。
【請求項２】
請求項１に記載のデータ処理装置であって、
前記通知コントローラは、ユーザが前記ユーザインターフェースを用いて現在のユーザ通知に対処している間、前記現在のユーザ通知に対処し終わるまで、全てのさらなるユーザ通知を保留するように構成される
データ処理装置。
【請求項３】
請求項２に記載のデータ処理装置であって、
前記通知コントローラは、ユーザが前記ユーザインターフェースを用いて現在の通知に対処している間、全てのさらなるユーザ通知を含む待ち行列を生成し、ユーザが前記現在のユーザ通知に対処し終わった時点で前記待ち行列に含まれるユーザ通知を提供するように構成される
データ処理装置
【請求項４】
請求項１から３のいずれか１項に記載のデータ処理装置であって、
前記通知コントローラは、異なる複数のタイプのユーザ通知に関連する優先データを保持し、
前記優先データは、特定のタイプのユーザ通知が、ユーザが前記ユーザインターフェースを用いて現在のユーザ通知に対処している間に提供を許容されるべきか否かを定義する
データ処理装置。
【請求項５】
請求項４に記載のデータ処理装置であって、
前記通知コントローラは、ユーザがどのタイプのユーザ通知に対処しているかを検出し、当該検出結果に応じて前記優先データを変更するように構成される
データ処理装置。
【請求項６】
請求項１から５のいずれか１項に記載のデータ処理装置であって、
当該データ処理装置は、コンテンツプロバイダによって送信される音声／映像コンテンツを受信し、ユーザ出力として再生するように構成された受信機である
データ処理装置。
【請求項７】
請求項６に記載のデータ処理装置であって、
受信されたコンテンツを記録するためのコンテンツレコーダーと、
前記通知コントローラによるユーザ通知の提供に応じて、前記受信されたコンテンツの記録を開始するように構成された記録コントローラと、
を具備するデータ処理装置。
【請求項８】
請求項７に記載のデータ処理装置であって、
前記記録コントローラは、前記記録が開始された時刻を示すフラグを記録するように構成される
データ処理装置。
【請求項９】
請求項７または８に記載のデータ処理装置であって、
ユーザ通知の提供に応じて、前記受信されたコンテンツの再生を一時停止するように構成される
データ処理装置。
【請求項１０】
請求項９に記載のデータ処理装置であって、
前記ユーザが前記ユーザ通知に対処し終わった時点で、前記受信されたコンテンツの再生を再開するように構成される
データ処理装置。
【請求項１１】
請求項１から１０のいずれか１項に記載のデータ処理装置であって、
前記ユーザ通知は音声による通知及び／又は映像による通知である
データ処理装置。
【請求項１２】
コンテンツプロバイダによって送信された音声コンテンツ／映像コンテンツを受信し、ユーザ出力として再生するように構成された受信装置であって、
当該受信装置または、当該受信装置が接続された別の装置におけるデータ処理イベントに応じてユーザへの通知を提供するように構成された通知コントローラと、
前記通知コントローラによるユーザ通知の提供に応じて、前記受信されたコンテンツの記録を開始するように構成された記録コントローラと
を具備する受信装置。
【請求項１３】
データ処理装置の操作方法であって、
前記データ処理装置または、前記データ処理装置が接続された別の装置におけるデータ処理イベントに応じてユーザへの通知を提供し、
通知されたデータ処理イベントに関するデータ処理タスクを実行するためのユーザ通知にユーザを対処させることが可能なユーザインターフェースを提供し、
ユーザが前記ユーザインターフェースを用いて現在の通知に対処している間、他の通知を抑制する
データ処理装置の操作方法。
【請求項１４】
コンテンツプロバイダによって送信された音声コンテンツ／映像コンテンツを受信し、ユーザアウトプットとして再生するように構成された受信装置の操作方法であって、
前記受信装置または、前記受信装置が接続された別の装置におけるデータ処理イベントに応じてユーザへの通知を提供し、
前記ユーザ通知の提供に応じて、前記受信されたコンテンツの記録を開始する
受信装置の操作方法。
【請求項１５】
請求項１３に記載のデータ処理装置の操作方法における各ステップを当該データ処理装置に実行させ、又は請求項１４に記載の受信装置の操作方法における各ステップを当該受信装置に実行させるプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２０１２−１９９９１５（Ｐ２０１２−１９９９１５Ａ）
【公開日】平成２４年１０月１８日（２０１２．１０．１８）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１２−５４２９６（Ｐ２０１２−５４２９６）
【出願日】平成２４年３月１２日（２０１２．３．１２）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【出願人】（５９３０８１４０８）ソニー ヨーロッパ リミテッド (93)
【Ｆターム（参考）】
【公開日】平成２４年１０月１８日（２０１２．１０．１８）
【国際特許分類】
【出願番号】特願２０１２−５４２９６（Ｐ２０１２−５４２９６）
【出願日】平成２４年３月１２日（２０１２．３．１２）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【出願人】（５９３０８１４０８）ソニー ヨーロッパ リミテッド (93)
【Ｆターム（参考）】
[ Back to top ]