(57)【要約】【課題】状態通知による処理負荷の上昇を軽減すること。【解決手段】状態変化に関する状態変化情報を通知先に通知する情報処理装置１０は、タスクによって発生した状態変化を検知する検知部１０１と、検知部１０１によって検知された状態変化の発生元であるタスクの挙動種別を取得する取得部と、検知部１０１によって検知された状態変化に関する状態変化情報の通知先への通知方法を、取得部によって取得された当該状態変化の発生元であるタスクの挙動種別に基づいて決定し、決定された通知方法に基づいて当該状態変化情報を通知先に通知する通知部１０３と、を備える。【選択図】図３
2014115975.tif 000002
【特許請求の範囲】
【請求項１】
状態変化に関する状態変化情報を通知先に通知する情報処理装置であって、
タスクによって発生した状態変化を検知する検知手段と、
前記検知手段によって検知された状態変化の発生元であるタスクの挙動種別を取得する取得手段と、
前記検知手段によって検知された状態変化に関する状態変化情報の通知先への通知方法を、前記取得手段によって取得された当該状態変化の発生元であるタスクの挙動種別に基づいて決定し、決定された通知方法に基づいて当該状態変化情報を通知先に通知する通知手段と、
を備える情報処理装置。
【請求項２】
前記通知手段は、挙動種別が、特定の時刻に偏って実行されやすいタスクであることを示す大域同期型である場合、通知先への状態変化情報の通知を回避する、ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記通知手段は、挙動種別が、特定の時刻に偏って実行されやすいタスクであることを示す大域同期型である場合、状態変化情報を通知先に遅延して通知する、ことを特徴とする請求項１に記載の情報処理装置。
【請求項４】
前記通知手段は、挙動種別が、特定の時刻に偏って実行されやすいタスクであることを示す大域同期型である場合、状態変化情報と共に通知先の処理を制御する指示情報を通知先に通知する、ことを特徴とする請求項１に記載の情報処理装置。
【請求項５】
前記通知手段は、挙動種別が、特定の時刻に偏って実行されやすいタスクであることを示す大域同期型であり、かつ通知先が通信可能である場合、通知先への状態変化情報の通知を回避する、又は状態変化情報を通知先に遅延して通知する、又は状態変化情報と共に通知先の通信を制御する指示情報を通知先に通知する、ことを特徴とする請求項１に記載の情報処理装置。
【請求項６】
前記通知手段によって状態変化情報が通知先に通知された際に、通知先にて当該通知に基づいて通信が発生したか否かを通信履歴として保持する通信履歴保持手段を更に備え、
前記通知手段は、通知先が通信可能であるか否かを前記通信履歴保持手段によって保持された通信履歴に基づいて決定する、
ことを特徴とする請求項５に記載の情報処理装置。
【請求項７】
前記通知手段は、挙動種別が特定の時刻に偏って実行されやすいタスクであることを示す大域同期型であり、かつ、当該状態変化が予め制御の対象外として指定されたもの及び通知先が予め制御の対象外として指定されたものの少なくとも一方に該当する場合、状態変化情報を通知先に通知する、ことを特徴とする請求項１に記載の情報処理装置。
【請求項８】
前記取得手段は、前記検知手段によって検知された状態変化の発生元であるタスクについて、当該タスクの実行を予約した時刻が実時間を基準にした絶対時刻である場合、当該挙動種別を、特定の時刻に偏って実行されやすいタスクであることを示す大域同期型として取得する、ことを特徴とする請求項１〜７の何れか一項に記載の情報処理装置。
【請求項９】
前記通知手段は、前記取得手段によって状態変化の発生元であるタスクの挙動種別が取得できず、かつ、前記検知手段によって検知された当該状態変化が予め設定されている状態変化に該当する場合、当該タスクの挙動種別を、特定の時刻に偏って実行されやすいタスクであることを示す大域同期型とする、ことを特徴とする請求項１に記載の情報処理装置。
【請求項１０】
前記通知手段は、
前記検知手段によって検知された状態変化に関する状態変化情報を通知先に通知する既存通知手段と、
前記検知手段によって検知された状態変化に関する状態変化情報の通知先への通知方法を、前記取得手段によって取得された当該状態変化の発生元であるタスクの挙動種別に基づいて決定し、決定された通知方法に基づいて前記既存通知手段による通知を制御する通知制御手段と、
から構成される請求項１に記載の情報処理装置。
【請求項１１】
状態変化に関する状態変化情報を通知先に通知する情報処理装置により実行される状態通知方法であって、
タスクによって発生した状態変化を検知する検知ステップと、
前記検知ステップにおいて検知された状態変化の発生元であるタスクの挙動種別を取得する取得ステップと、
前記検知ステップにおいて検知された状態変化に関する状態変化情報の通知先への通知方法を、前記取得ステップにおいて取得された当該状態変化の発生元であるタスクの挙動種別に基づいて決定し、決定された通知方法に基づいて当該状態変化情報を通知先に通知する通知ステップと、
を含む状態通知方法。
【請求項１２】
コンピュータを、
タスクによって発生した状態変化を検知する検知手段と、
前記検知手段によって検知された状態変化の発生元であるタスクの挙動種別を取得する取得手段と、
前記検知手段によって検知された状態変化に関する状態変化情報の通知先への通知方法を、前記取得手段によって取得された当該状態変化の発生元であるタスクの挙動種別に基づいて決定し、決定された通知方法に基づいて当該状態変化情報を通知先に通知する通知手段、
として機能させる状態通知プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は情報処理装置、状態通知方法及び状態通知プログラムに関する。
【背景技術】
【０００２】
近年、複数のタスクを同時に実行できるマルチタスクＯＳ（Operating  System）を搭載する情報処理装置が増加している。マルチタスクＯＳを搭載するものの一例として、スマートフォンがある。スマートフォンは、従来の情報処理装置とは違い、液晶画面のバックライト消灯時においても、アプリケーションプログラム（以下ではアプリという）の各タスクが、サーバ装置とのデータ同期を行っており、無線通信の発生回数も増加するため、基地局が処理すべき信号の信号量が増加し、基地局や移動通信網における負荷が大きくなる。また、複数のスマートフォンが同時に通信を行うことがあるが、これにより基地局または移動通信網における負荷が一時的に増大する現象も発生している。
【０００３】
このような通信集中の原因の１つとして、情報処理装置による、状態変化に関する状態変化情報を通知先に通知する状態通知が挙げられる。状態通知を行う情報処理装置は、例えば、サーバとの同期や装置内の絶対時間指定による動作などにより、複数の装置間で同一のタイミングに状態変化が発生し、通知先の通信を伴うタスクが複数の装置上で一斉に起動してしまう。ここで、例えば、情報処理装置における状態通知を行う技術として、非特許文献１には、タスクが事前に指定した種類の状態変化に対する通知を受け取る仕組みが開示されている。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】ＢｒｏａｄｃａｓｔＩｎｔｅｎｔ、ＢｒｏａｄｃａｓｔＲｅｃｅｉｖｅｒ（http://developer.android.com/guide/components/intents-filters.html）
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、非特許文献１に開示されている仕組みを利用すると、状態変化に対する通知を契機にタスクを起動するプログラムがアプリに備わっている場合、特定の時刻に発生する状態変化や、外部からの通信や環境変化に対応して発生する状態変化による通知により、複数の情報処理装置において同時にタスクが起動することとなり、通信の集中が発生する要因となることが懸念される。
【０００６】
本発明はそのような課題を解決するためになされたものであり、状態通知による処理負荷の上昇を軽減することができる情報処理装置、状態通知方法及び状態通知プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記目的を達成するために、本発明に係る情報処理装置は、状態変化に関する状態変化情報を通知先に通知する情報処理装置であって、タスクによって発生した状態変化を検知する検知手段と、検知手段によって検知された状態変化の発生元であるタスクの挙動種別を取得する取得手段と、検知手段によって検知された状態変化に関する状態変化情報の通知先への通知方法を、取得手段によって取得された当該状態変化の発生元であるタスクの挙動種別に基づいて決定し、決定された通知方法に基づいて当該状態変化情報を通知先に通知する通知手段と、を備えることを特徴とする。
【０００８】
本発明に係る情報処理装置では、検知手段が、タスクによって発生した状態変化を検知し、取得手段が、検知された状態変化の発生元であるタスクの挙動種別を取得する。そして、通知手段が、検知された状態変化に関する状態変化情報の通知先への通知方法を、取得された当該状態変化の発生元であるタスクの挙動種別に基づいて決定し、決定された通知方法に基づいて当該状態変化情報を通知先に通知する。このように、検知された状態変化に関する状態変化情報の通知先への通知方法が、状態変化の発生元であるタスクの挙動種別に基づいて決定されるため、例えば、特定の挙動種別である場合は通知を回避、又は遅延させることで、状態通知による特定時刻に集中した処理負荷の上昇を軽減することができる。
【０００９】
通知手段は、挙動種別が、特定の時刻に偏って実行されやすいタスクであることを示す大域同期型である場合、通知先への状態変化情報の通知を回避することとしてもよい。例えば、複数の情報処理装置において、挙動種別が大域同期型であるタスクによって発生した状態変化が通知先に通知され、当該通知に基づいて通知先が処理を行う場合、当該処理が同時に行われることになり、処理負荷が上昇する要因となる。この構成によれば、挙動種別が大域同期型であるタスクが状態変化の発生元である場合、通知先への状態変化情報の通知を回避するため、通知先での処理が行われず、状態通知による処理負荷の上昇を軽減することができる。
【００１０】
通知手段は、挙動種別が、特定の時刻に偏って実行されやすいタスクであることを示す大域同期型である場合、状態変化情報を通知先に遅延して通知することとしてもよい。例えば、複数の情報処理装置において、挙動種別が大域同期型であるタスクによって発生した状態変化が通知先に通知され、当該通知に基づいて通知先が処理を行う場合、当該処理が同時に行われることになり、処理負荷が上昇する要因となる。この構成によれば、挙動種別が大域同期型であるタスクが状態変化の発生元である場合、状態変化情報を例えば装置毎に異なる時間だけ通知先に遅延して通知することで、それぞれの装置における通知先での処理のタイミングが変わり、状態通知による処理負荷の上昇を軽減することができる。
【００１１】
通知手段は、挙動種別が、特定の時刻に偏って実行されやすいタスクであることを示す大域同期型である場合、状態変化情報と共に通知先の処理を制御する指示情報を通知先に通知することとしてもよい。例えば、複数の情報処理装置において、挙動種別が大域同期型であるタスクによって発生した状態変化が通知先に通知され、当該通知に基づいて通知先が処理を行う場合、当該処理が同時に行われることになり、処理負荷が上昇する要因となる。この構成によれば、挙動種別が大域同期型であるタスクが状態変化の発生元である場合、状態変化情報と共に通知先の処理を制御する指示情報を通知先に通知するため、例えば、処理を実行しない旨の指示情報を通知することで、通知先での処理が行われず、状態通知による処理負荷の上昇を軽減することができる。
【００１２】
通知手段は、挙動種別が、特定の時刻に偏って実行されやすいタスクであることを示す大域同期型であり、かつ通知先が通信可能である場合、通知先への状態変化情報の通知を回避する、又は状態変化情報を通知先に遅延して通知する、又は状態変化情報と共に通知先の通信を制御する指示情報を通知先に通知することとしてもよい。この構成によれば、例えば、複数の情報処理装置において、挙動種別が大域同期型であるタスクによって発生した状態変化が通知先に通知され、当該通知に基づいて通知先が処理を行う場合、当該処理が同時に行われることになり、通信集中の要因となる。この構成によれば、挙動種別が大域同期型であるタスクが状態変化の発生元であり、かつ通知先が通信可能である場合、通知先への状態変化情報の通知を回避することで通知先での通信が実行されず、又は状態変化情報を通知先に遅延して通知することで通知先での処理のタイミングが変わり、又は状態変化情報と共に通知先の通信を制御する指示情報を通知先に通知すること、例えば通信処理を実行しない旨の指示情報を通知することで通知先での通信処理が行われず、状態通知による通信集中を軽減することができる。
【００１３】
通知手段によって状態変化情報が通知先に通知された際に、通知先にて当該通知に基づいて通信が発生したか否かを通信履歴として保持する通信履歴保持手段を更に備え、通知手段は、通知先が通信可能であるか否かを通信履歴保持手段によって保持された通信履歴に基づいて決定することとしてもよい。この構成によれば、通知先が通信可能であるか否かを過去の通信履歴に基づいてより正確に判定することができる。
【００１４】
通知手段は、挙動種別が、特定の時刻に偏って実行されやすいタスクであることを示す大域同期型であり、かつ、当該状態変化が予め制御の対象外として指定されたもの及び通知先が予め制御の対象外として指定されたものの少なくとも一方に該当する場合、状態変化情報を通知先に通知することとしてもよい。この構成により、例えば、通知を行っても通知先で通信が発生しないことが分かっている状態変化を予め制御の対象外として指定しておくことで、当該タスクが大域同期型であっても状態変化情報が通知先に通知されるため、従来装置での挙動を前提としたタスクでも動作させることができる。また、この構成により、例えば、通知を行っても通知先で通信が発生しないことが分かっている通知先のタスクを予め制御の対象外として指定しておくことで、当該タスクが大域同期型であっても状態変化情報が通知され、通知先タスクでは通信の発生しない処理しか実行されないため、従来装置での挙動を前提としたタスクでも動作させることができる。
【００１５】
取得手段は、検知手段によって検知された状態変化の発生元であるタスクについて、当該タスクの実行を予約した時刻が実時間を基準にした絶対時刻である場合、当該挙動種別を、特定の時刻に偏って実行されやすいタスクであることを示す大域同期型として取得することとしてもよい。この構成により、挙動種別が大域同期型であるか否かの判定がより具体化される。
【００１６】
通知手段は、取得手段によって状態変化の発生元であるタスクの挙動種別が取得できず、かつ、検知手段によって検知された当該状態変化が予め設定されている状態変化に該当する場合、当該タスクの挙動種別を、特定の時刻に偏って実行されやすいタスクであることを示す大域同期型とすることとしてもよい。この構成により、取得手段によって挙動種別が取得できない場合でも適切に挙動種別を決定することができる。
【００１７】
通知手段は、検知手段によって検知された状態変化に関する状態変化情報を通知先に通知する既存通知手段と、検知手段によって検知された状態変化に関する状態変化情報の通知先への通知方法を、取得手段によって取得された当該状態変化の発生元であるタスクの挙動種別に基づいて決定し、決定された通知方法に基づいて既存通知手段による通知を制御する通知制御手段と、から構成されることとしてもよい。この構成により、既存通知手段を備える既存の情報処理装置においても、容易に本発明を適用することができる。
【００１８】
ところで、本発明は、上記のように情報処理装置の発明として記述できる他に、以下のように状態通知方法及び状態通知プログラムの発明としても記述することができる。これはカテゴリが異なるだけで、実質的に同一の発明であり、同様の作用及び効果を奏する。
【００１９】
即ち、本発明に係る状態通知方法は、状態変化に関する状態変化情報を通知先に通知する情報処理装置により実行される状態通知方法であって、タスクによって発生した状態変化を検知する検知ステップと、検知ステップにおいて検知された状態変化の発生元であるタスクの挙動種別を取得する取得ステップと、検知ステップにおいて検知された状態変化に関する状態変化情報の通知先への通知方法を、取得ステップにおいて取得された当該状態変化の発生元であるタスクの挙動種別に基づいて決定し、決定された通知方法に基づいて当該状態変化情報を通知先に通知する通知ステップと、を含むことを特徴とする。
【００２０】
また、本発明に係る状態通知プログラムは、コンピュータを、タスクによって発生した状態変化を検知する検知手段と、検知手段によって検知された状態変化の発生元であるタスクの挙動種別を取得する取得手段と、検知手段によって検知された状態変化に関する状態変化情報の通知先への通知方法を、取得手段によって取得された当該状態変化の発生元であるタスクの挙動種別に基づいて決定し、決定された通知方法に基づいて当該状態変化情報を通知先に通知する通知手段、として機能させることを特徴とする。
【発明の効果】
【００２１】
本発明によれば、状態通知による処理負荷の上昇を軽減することができる。
【図面の簡単な説明】
【００２２】
【図１】本発明の実施形態に係る情報処理システムの全体構成を示す図である。
【図２】本発明の実施形態に係る情報処理装置のハードウェア構成を示すブロック図である。
【図３】本発明の実施形態に係る情報処理装置が実現する機能構成を示すブロック図である。
【図４】本発明の実施形態に係る情報処理装置で実行される処理（状態通知方法）を示すフローチャートである。
【図５】従来装置においてタスクの処理が実行されるタイミングを示す図である。
【図６】本発明の実施形態に係る情報処理装置においてタスクの処理が実行されるタイミングを示す図である。
【図７】本発明の実施形態に係る状態通知プログラムの構成を記憶媒体と共に示す図である。
【図８】挙動種別テーブルの一例を示すテーブル図である。
【図９】受取通知種別テーブルの一例を示すテーブル図である。
【図１０】本発明の実施形態に係る情報処理装置で実行される処理（状態通知方法）の基本形を示すフローチャートである。
【図１１】本発明の実施形態に係る情報処理装置においてタスクの処理が実行されるタイミングを示す図である。
【図１２】本発明の実施形態の変形例に係る情報処理装置が実現する機能構成を示すブロック図である。
【発明を実施するための形態】
【００２３】
以下、本発明の実施形態に係る情報処理システムについて説明する。
【００２４】
［構成］
図１は、本発明の実施形態に係る情報処理システム１の全体構成を示す図である。情報処理システム１は、情報処理装置１０と、ネットワーク２と、サーバ装置２０とを具備する。
【００２５】
情報処理装置１０は、ＣＰＵ（Central  Processing  Unit）を備えて情報を処理する装置である。情報処理装置１０は、移動体通信や無線ＬＡＮの規格等に基づいて無線通信を行う。ネットワーク２は、移動体通信網及びインターネット等を含む通信回線である。ネットワーク２には、サーバ装置２０が接続されており、また、情報処理装置１０が無線通信を行っているときにはその情報処理装置１０も接続される。サーバ装置２０は、ネットワーク２を介して、情報処理装置１０と通信を行う装置である。
【００２６】
図２は、情報処理装置１０のハードウェア構成を示すブロック図である。情報処理装置１０は、制御装置１１と、音声入出力装置１２と、通信装置１３と、操作装置１４と、表示装置１５と、記憶装置１６と、電源制御装置１７とを備える。
【００２７】
制御装置１１は、ＣＰＵ、ＲＯＭ（Read  Only  Memory）、ＲＡＭ（Random  Access  Memory）を有するマイクロプロセッサとリアルタイムクロックとを備えている。ＣＰＵは、ＲＡＭをワークエリアとして用いてＲＯＭや記憶装置１６に記憶されたプログラムを実行することによって、情報処理装置１０が備える各装置の動作を制御する。このように、制御装置１１は、情報処理装置１０を制御するコンピュータである。リアルタイムクロックは、現在の日時を算出する機能を有している。
【００２８】
音声入出力装置１２は、スピーカ、マイクロホン及び音声処理回路等を有し、通話等の音声の入出力を行う。
【００２９】
通信装置１３は、信号の発信及び受信を行うアンテナと、移動体通信及び無線ＬＡＮの規格に基づいて無線通信を行うための通信回路とを備え、ネットワーク２を介してサーバ装置２０と通信を行う通信手段である。通信装置１３は、制御装置１１とデータをやり取りし、制御装置１１は、通信装置１３を介してサーバ装置２０とデータをやり取りする。
【００３０】
操作装置１４は、例えば表示装置１５に重ねて設けられたタッチスクリーンと物理キーとを有し、ユーザの操作に応じた操作信号を制御装置１１に供給する。制御装置１１は、この操作信号に応じた処理を行う。
【００３１】
表示装置１５は、表示面を有するＬＣＤ（Liquid  Crystal  Display）等の表示手段であり、制御装置１１からの指示に応じて、記憶装置１６に記憶されているデータが示す画像等を表示面に表示する。
【００３２】
記憶装置１６は、例えばＥＥＰＲＯＭ（Electronically  Erasable  and  Programmable  ROM）やフラッシュメモリ等の記憶手段であり、制御装置１１が制御に用いるデータやプログラム等を記憶している。また、記憶装置１６は、情報処理装置１０において用いられる閾値等の定められた数値を示すデータを記憶している。
【００３３】
なお、記憶装置１６は、リムーバブルメディア等の着脱可能な記憶手段を含んでもよいし、ＵＩＭ（User  Identity  Module）カードやＳＩＭ（Subscriber  Identity  Module）カードのような、ユーザ（又は情報処理装置１０）を識別するためのデータが記録された記憶手段を含んでもよい。また、このユーザ（又は情報処理装置１０）を識別するためのデータが外部サーバに記憶されていて、情報処理装置１０がこれを通信により取得する構成であってもよい。
【００３４】
電源制御装置１７は、バッテリーの残量や外部からの電源供給を監視するとともに、バッテリーの充電状態等を制御する。
【００３５】
以上の構成を有する情報処理装置１０は、例えばスマートフォンであるが、携帯電話端末やタブレット端末、パーソナルコンピュータ、ＰＤＡ（Personal  Digital  Assistant）等の、複数のプログラムを実行する情報処理装置であればよい。また情報処理装置１０は、上記構成以外にも、所定時間継続してユーザの操作が行われなかった場合に省電力モードに移行する機能を実現するための構成等、汎用のスマートフォンと同等の構成を有している。情報処理装置１０が省電力モードであるときには、表示装置１５の表示領域は消灯した状態となるが、その状態においても制御装置１１は処理を実行する稼働状態であってもよい。また、情報処理装置１０は、バイブレータや情報処理装置１０の傾きを検出するための加速度センサ等、各種センサを備えてもよい。
【００３６】
情報処理装置１０は、上述したハードウェア構成に基づき、例えば、あるプログラムの処理により表示装置１５の表示領域が消灯した状態へ変化する等の装置内における状態変化や、通信装置１３を介してサーバ装置２０からの通信を受信した等の外部からの要因による装置の状態変化が発生した際に、装置の状態をアプリ、又はアプリに含まれる任意のタスクに対し通知する。なお、以降の説明では、アプリ及びタスクを統一してタスクと記載する。タスクと記載した場合、アプリ及びタスクの何れか一方あるいは両方を示す。通知を受けたタスクは必要に応じて処理を実行する。つまり、当該通知は通知先の振る舞いの契機となる。このような装置の状態変化に応じて通知する処理を、以下では「状態通知処理」という。
【００３７】
装置内における状態変化には、表示装置１５の表示領域の点灯や消灯の他に、電源制御装置１７で監視しているバッテリーの残量や外部電源供給の有無等の状態における変化や、記憶装置１６における着脱可能な記憶手段の着脱状態における変化や、記憶されているアプリの追加や削除等の情報処理装置１０の内部で発生する状態変化を含めてもよい。
【００３８】
また、外部からの要因による装置の状態変化には、サーバ装置２０からの通信の受信の他に、操作装置１４が備える物理キー等への操作による状態変化や、情報処理装置１０の傾きをユーザが変化させることによる加速度センサ等の測定結果の状態変化を含めてもよい。
【００３９】
情報処理装置１０は、事前にタスクが通知を受けたい状態変化の種類（以下では「受取通知種別」という）についての指定を記憶しており、状態変化が発生した際には、該当する状態変化の通知を指定しているタスク（以下では「通知先タスク」という）に対して通知を行う。これにより、タスクは不要な通知について処理が必要かどうかの判定処理を行う必要がない。通知先タスクが複数ある場合、全ての通知先タスクに一斉に状態変化を通知する方法と、事前に指定された優先順位に基づき各通知先タスクに順序付けて通知を行う方法とがあり、何れの方法を用いるかは状態変化の種類に応じて決定される。なお、優先順位は事前に静的に決定されたものに限らず、通知先タスクでの処理が完了するまでの時間の長さや、発生した通信量など通知先タスクの状態に応じて動的に決定しても良い。なお、通知先タスクも通知元と同様に、各アプリまたは各アプリに含まれる１つ以上の各タスクを識別する情報であるタスク識別子に対応した属性情報に含まれる通信種別を持っている。具体的には、通知先タスクのタスク識別子に対応した属性情報に含まれる通信種別には、状態変化の通知を受けることにより通信が発生する／しないの情報が含まれる。
【００４０】
ここで、タスクに含まれる属性情報について説明を補足する。タスクに含まれる属性情報は、当該タスクのタスク識別子に対応付けられて記憶部１０２等により記憶される。属性情報には、挙動種別、受取通知種別、優先度、及び通信種別を含む。なお、属性情報には、優先度及び通信種別の何れか一方あるいは両方が含まれていなくてもよい。
【００４１】
以上の通り、タスクは各々通知しあう関係にある。タスクは、他のタスクや端末の外部から通知を受けると共に、他のタスクや端末の外部に通知を行うことができる。
【００４２】
情報処理装置１０においては、特定の時刻に開始される処理（以下では「特定時刻処理」という）や、通信網を通じて一斉に配信される情報を受取ること（以下では「同報受信」という）により、状態変化が対応する通知先タスクに通知されて集中して実行されることになる。情報処理装置１０は、そのように集中して実行される通知先タスクの処理を分散させるための処理を行う。情報処理装置１０は、上述した各特定時刻処理と通知先タスクの処理とをそれぞれ実行するための複数のプログラム（状態通知プログラム）を記憶装置１６に記憶している。制御装置１１がこれらのプログラムを実行して図２に示す各装置を制御することで、図３に示す機能が実現される。
【００４３】
図３は、情報処理装置１０が実現する機能構成を示すブロック図である。情報処理装置１０は、検知部１０１（検知手段）と、通知部１０３（取得手段、通知手段）と、記憶部１０２（取得手段）とを備える。
【００４４】
検知部１０１は、装置内や外部要因による装置の状態変化等、タスクによって発生した状態変化を検知する検知手段である。検知部１０１は、例えば、制御装置１１、音声入出力装置１２、通信装置１３、操作装置１４及び電源制御装置１７が協働して実現する機能である。検知部１０１は、具体的には、次の方法でこれらの状態変化を検知する。
【００４５】
制御装置１１には、外部からの音声入力や外部への音声出力が発生することで音声入出力装置１２から入出力状態を通知する信号が供給される。制御装置１１（検知部１０１）は、この通知された信号に基づき、例えば、音声の出力が無音状態から何らかの音声が再生されている状態に変化したことを検出する。
【００４６】
なお、音声入出力装置１２は情報処理装置１０に対して、音声入出力用の外部装置が接続可能な構成において、外部装置の接続状態を通知する信号を制御装置１１に供給してもよい。この場合において、制御装置１１（検知部１０１）は、例えば外部装置が未接続状態から接続状態に変化したことを検出する。
【００４７】
また、制御装置１１には、外部からの通信を受信する通信装置１３から通信状態を通知する信号が供給される。制御装置１１（検知部１０１）は、この通知された信号に基づき、例えば、通信不可能な状態から通信可能な状態に変化したことを検出する。
【００４８】
通信状態として、その他に、サーバ装置２０を経由して通信網から特定のデータを受信した状態が発生したことを制御装置１１（検知部１０１）は検知してもよい。これは、例えば、電子メールの受信や音声入出力装置１２を用いた音声通話の開始指示の受信である。
【００４９】
また、制御装置１１には、ユーザにより操作された操作装置１４から操作信号が供給される。制御装置１１（検知部１０１）は、この通知された信号に基づき、例えば、情報処理装置１０に備え付けられた特定のボタンが非押下状態から押下状態へと変化したことを検出する。
【００５０】
なお、物理的なボタンに限らず、タッチセンサーへの接触や、タッチパネル上における特定操作の入力を検出してもよい。
【００５１】
また、制御装置１１には、電源の状態を監視する電源制御装置１７から電源状態を通知する信号が供給される。制御装置１１（検知部１０１）は、この通知された信号に基づき、例えば、情報処理装置１０がバッテリーを備える構成において、バッテリーが充電状態から放電状態へと変化したことを検出する。この他、外部電源への接続状態が変化したことや、バッテリーの残量が変化したことを制御装置１１（検知部１０１）は検出してもよい。
【００５２】
制御装置１１（検知部１０１）は、制御装置１１内でタスクのプログラムを実行したことにより発生した状態変化、例えば、通信処理の開始や表示領域の点灯等について、状態変化を引き起こしたタスクを判別する。情報処理装置１０において、例えば、予めユーザが設定した時刻において表示領域を点灯するとともにアラーム音を発生することで、設定時刻となった旨を通知する機能を持つアラームタスクをタイマーアプリが含んでおり、表示領域の点灯がアラームタスクによってなされたものであれば、検知した状態変化に対し、その状態変化の発生要因となったタスクがタイマーアプリに含まれるアラームタスクであることを制御装置１１（検知部１０１）は検知する。
【００５３】
以上の通り、検知部１０１は装置内や外部要因による装置の状態変化を検知する。
【００５４】
記憶部１０２は、各タスクの受取通知種別を記憶する記憶手段である。記憶部１０２は、例えば、制御装置１１及び記憶装置１６が協働して実現する機能である。記憶部１０２は、具体的には、次の方法でこれらの受取通知種別を記憶する。
【００５５】
情報処理装置１０において、新たなタスクがインストールされた時点で、制御装置１１はタスクに含まれる属性情報に基づいて、受取通知種別と、優先度と、各タスクの処理が複数の情報処理装置１０において特定の時刻に偏って実行されやすいかどうかを示す挙動種別とを判断する。挙動種別として、複数の情報処理装置１０において特定の時刻に偏って実行されやすいタスクであることを示す情報（以下では「大域同期型」という）や、複数の情報処理装置１０において分散された時刻で実行されやすいタスクであることを示す情報（以下では「大域非同期型」という）がある。大域同期型であるタスクとしては、例えば、データを同期するために毎日０時にサーバ装置２０と通信するように指定されたタスクや、サーバ装置２０から複数の情報処理装置１０に対して一斉に同報された通知を受取るタスクがある。一方で、大域非同期型であるタスクとしては、ユーザが情報処理装置１０の操作を開始し、操作装置１４における状態変化を受けて動作を開始するタスクや、データを同期するために乱数を用いて生成した時刻においてサーバ装置２０と通信するように指定されたタスクがある。
【００５６】
なお、挙動種別は大域同期型、大域非同期型の２種類以外に、情報処理装置１０内において、あるタスクの挙動により同期して実行されるタスクを端末内同期型として区別してもよい。
【００５７】
記憶装置１６（記憶部１０２）には、タスク識別子と、挙動種別とを対応付けたテーブル（以下では「挙動種別テーブル」という）、および、タスク識別子と、受取通知種別と、優先度とを対応付けたテーブル（以下では「受取通知種別テーブル」という）が記憶されており、制御装置１１は判断したタスク識別子と挙動種別を挙動種別テーブルに追加するとともに、受取通知種別と優先度とタスク識別子を受取通知種別テーブルに追加する。なお、受取通知種別テーブルには、優先度が対応付いてなくてもよい。
【００５８】
また、アプリがアンインストールされた場合は、対応するタスク識別子等の保持情報を挙動種別テーブル、および受取通知種別テーブルから削除する。
【００５９】
なお、受取通知種別テーブルはアプリのインストールやアンインストール時に限って更新されるものではなく、実行中のタスクから随時、受取通知種別の追加や変更、削除を行ってもよい。これにより、タスクは不要な通知を受け取らずに済み、処理負荷の低減が図れる。
【００６０】
また、同様に実行中のタスクから随時、挙動種別の変更を行ってもよい。
【００６１】
以上の通り、記憶部１０２は各タスクの受取通知種別を記憶する。
【００６２】
また、タスク識別子について説明を補足する。複数のアプリについて、それぞれに同一の処理を行うタスク（例えば、画面表示を行うタスク）があった場合でも、それぞれのタスクは異なるタスク識別子を持つ。すなわち、複数のタスクにおいて同一のタスク識別子は存在しない。
【００６３】
図８に、挙動種別テーブルの一例を示す。図８に示す挙動種別テーブルでは、タスク識別子と挙動種別とが対応付いて記憶されている。なお、挙動種別テーブルは、アプリ単位ではなくタスク単位でのみ挙動種別を管理してもよい。
【００６４】
図９に、受取通知種別テーブルの一例を示す。図９に示す受取通知種別テーブルでは、タスク識別子と受取通知種別とが対応付いて記憶されている。図９に示す通り、受取通知種別として、事前にタスクが通知を受けたい状態変化を識別する情報や、事前にタスクが通知を受けたい状態変化の起因となるタスクを識別する情報（タスク識別子など）、及びそれらを組み合わせた情報などを記憶してもよい。
【００６５】
通知部１０３は、検知部１０１が検知した状態変化に関する状態変化情報をタスクに通知する通知手段である。当該通知がタスクの振る舞いの契機となる。通知部１０３は、例えば、制御装置１１及び記憶装置１６が協働して実現する機能である。
【００６６】
通知部１０３は、検知部１０１によって検知された状態変化の発生元であるタスクの挙動種別などの属性情報やタスク識別子など、タスクの情報を取得する取得部（不図示）を含んでいてもよい。そして、通知部１０３は、検知部１０１によって検知された状態変化に関する状態変化情報の通知先への通知方法を、取得部によって取得された当該状態変化の発生元であるタスクの挙動種別などの属性情報に基づいて決定し、決定された通知方法に基づいて当該状態変化情報を通知先に通知する。通知部１０３は、挙動種別が大域同期型である場合、通知先への状態変化情報の通知を回避してもよい。なお、本実施形態では、便宜上「状態変化情報の通知」を「状態変化の通知」として説明する場合がある。
【００６７】
通知部１０３は、具体的には、次の方法で状態変化を通知する。
【００６８】
制御装置１１（通知部１０３）は、検知部１０１により状態変化を検知すると、記憶部１０２に保持されている受取通知種別テーブルに基づいて、当該の状態変化を通知すべきタスクを判定し通知を行う。この際、通知先のタスクが複数である場合、制御装置１１（通知部１０３）は、状態変化により、全てのタスクに対して一斉に通知を行うか、各タスクが受取通知種別を指定した際の優先度に基づいて逐次に通知を行うかの判断も併せて行う。
【００６９】
一斉に通知を行う場合は、制御装置１１（通知部１０３）により、優先度に関わらず全ての通知先タスクに対して同時に状態通知処理が行われる。逐次に通知を行う場合は、制御装置１１（通知部１０３）により、全ての通知先タスクの優先度を比較し、最も高い優先度を持つ通知先タスクに対して通知が行われ、通知先タスクでの処理が完了した後に、次に高い優先度を持つ通知先タスクに対する通知が行われ、最終的には最も優先度の低い通知先タスクの処理が完了した時点で状態通知処理が完了する。なお、優先度が同等となる通知先タスクが複数存在する場合、制御装置１１（通知部１０３）は、何れの通知先タスクを優先するかは事前に定めた条件に基づいて判定する。ただし、条件を定めずにどちらを優先するかが不定であってもよい。また、制御装置１１（通知部１０３）は、優先度を明示的に指定せず、タスクの識別子や種別等の事前に定めた条件に基づいて優先度を付与してもよい。
【００７０】
なお、状態変化の発生要因がタスクのプログラム実行に伴うものであった場合、制御装置１１（通知部１０３）は、発生要因となったタスクの挙動種別を挙動種別テーブルから取得し、状態通知処理を行うかどうか判断する。例えば、発生要因であるタスクが大域同期型である場合には通知部１０３は通知先タスクに状態通知処理を行わず、大域非同期型である場合には状態通知処理を行う。これにより、複数の情報処理装置１０においてほぼ同一の時刻に状態通知処理が行われて通知先タスクが動作を開始してしまうことを防ぎ、サーバ装置２０に対して一斉に通信処理が発生しないようにすることができる。
【００７１】
以上の通り、通知部１０３は状態変化をタスクに通知する。
【００７２】
［動作］
以上の構成に基づき、情報処理装置１０は、状態通知処理を行う。状態通知処理は、情報処理装置１０の電源が投入され、状態通知処理を実行するためのプログラムが制御装置１１により実行開始されて以降、他のタスクによる処理と並行して繰り返し行われる。
【００７３】
以下、図１０を参照して、状態通知処理において情報処理装置１０が行う動作の基本形について説明する。
【００７４】
図１０は、状態通知処理で情報処理装置１０が行う動作の基本形の一例を示すフローチャートである。まず、情報処理装置１０は、現在の端末状態を取得する（ステップＳ１）。情報処理装置１０は、前回取得した端末状態と比較して、端末状態に変化がないと判断した場合には（ステップＳ２：ＮＯ）、所定の時間（例えば０．１秒）が経過したあとにステップＳ１の動作を再び行う。前回取得した端末状態から端末状態に変化がある場合には（ステップＳ２：ＹＥＳ）、端末状態の変化を発生させた要因がタスクに因るものであるかを判定する（ステップＳ３）。情報処理装置１０は、ステップＳ３において端末状態の変化がタスクに因るものでない場合には（ステップＳ３：ＮＯ）、ステップＳ６−１へと進み、状態変化から受取通知種別を参照し、通知先タスクへの通知を行う。端末状態の変化がタスクに因るものである場合には（ステップＳ３：ＹＥＳ）、端末状態の変化を発生させたタスクのタスク識別子を取得する（ステップＳ４）。タスク識別子に対応する挙動種別を挙動種別テーブルから取得し、挙動種別が大域同期型である場合には（ステップＳ５：ＹＥＳ）、通知先タスクへの通知は行わずに処理を終了する（ステップＳ６−２）。挙動種別が大域同期型以外である場合には（ステップＳ５：ＮＯ）、前述のステップＳ６−１へ進む。
【００７５】
続いて、図４を参照して、状態通知処理において情報処理装置１０が行う別の動作について説明する。図４は、状態通知処理で情報処理装置１０が行う動作の別の一例を示すフローチャートである。なお、ステップＳ１〜Ｓ５は図１０と同様のため、説明を省略する。
【００７６】
図４において、ステップＳ３がＮＯ、あるいはステップＳ５がＮＯの場合、状態変化の通知方法が一斉通知であるかを判定する（ステップＳ６）。情報処理装置１０は、ステップＳ６において状態変化の通知方法が一斉通知である場合には（ステップＳ６：ＹＥＳ）、状態変化を受取通知種別として指定している通知先タスクに対して、一斉に状態変化の通知を行う（ステップＳ７）。また、ステップＳ６において状態変化の通知方法が一斉通知ではない場合には（ステップＳ６：ＮＯ）、まず、通知の対象となる通知先タスクのうちで優先度の最も高い通知先タスクに対して状態変化の通知を行う（ステップＳ８）。状態変化を受取通知種別として指定している通知先タスクのうち、状態変化の通知が完了していない通知先タスクがある場合には（ステップＳ９：ＮＯ）、既に通知が完了した通知先タスクを除いた通知先タスクを対象としてステップＳ８の動作を再び行う。状態変化を受取通知種別として指定している通知先タスクの全てに状態変化の通知が完了している場合には（ステップＳ９：ＹＥＳ）、処理を終了する。
【００７７】
［効果］
情報処理装置１０が上記の状態通知処理を実行した場合の、状態変化の発生要因となったタスクと通知先タスクの各処理が実行されるタイミングについて説明する。
【００７８】
図５、図６、図１１は、各タスクの処理が実行されるタイミングを説明するための図である。図５、６及び１１において、実線矢印は、タスクが実行中であることを示し、破線矢印は、状態変化が通知されていることを示す。状態通知処理において、状態変化がタスクに起因するもので、かつ、そのタスクが大域同期型である際においても通知を行う情報処理装置（これを従来装置という）は、タスクの実行に伴い端末状態が変化した際に図５に示すように通知を行い通知先タスクが実行される。
【００７９】
従来装置では時刻Ｔ１においてサーバ装置２０からの通信Ｕ１を受け、通信を受け取ったタスクＡＰ２が処理を開始する。タスクＡＰ２の処理において、時刻Ｔ２では第１の状態変化を発生させ、時刻Ｔ３では第２の状態変化を発生させる。同様に、時刻Ｔ４においてサーバ装置２０からの通信Ｂ１を受け、通信を受け取ったタスクＡＰ１が処理を開始する。タスクＡＰ１の処理において、時刻Ｔ５では第１の状態変化を発生させ、時刻Ｔ６では第２の状態変化を発生させる。また、タスクＡＰ３は第１の状態変化、タスクＡＰ４は第２の状態変化が発生したタイミングで実行される処理であり、事前に受取通知種別が指定されている。タスクＡＰ３は第１の状態変化を通知された際に、サーバ装置２０との通信を発生する処理を実行させ、時刻Ｔ２での通知を受け通信Ｕ２を、時刻Ｔ５での通知を受け通信Ｕ３を発生する。
【００８０】
なお、通信Ｕ１、Ｕ２、Ｕ３は単一の情報処理装置とサーバ装置２０との間で行われる通信であり、通信Ｂ１は単一のサーバ装置２０から複数の情報処理装置に対して行われる同報通信である。したがって、通信Ｕ１は複数の情報処理装置間では異なった時刻に為され、通信Ｂ１は複数の情報処理装置間で同一の時刻に為される事となる。
【００８１】
タスクＡＰ１は同報通信を行うため、大域同期型の挙動種別を付与される。タスクＡＰ２、ＡＰ３、ＡＰ４は大域非同期型の挙動種別であるものとする。
【００８２】
従来装置においては、時刻Ｔ１にて通信Ｕ１を受けたタスクＡＰ２が処理を開始し、この処理において時刻Ｔ２で第１の状態変化が発生すると、状態変化の通知Ｓ１がタスクＡＰ３に通知され処理が実行される。この処理においてタスクＡＰ３は通信Ｕ２が発生する。また、時刻Ｔ３で第２の状態変化が発生すると、状態変化の通知Ｓ２がタスクＡＰ４に通知され処理が実行される。タスクＡＰ４は処理において通信を発生させない。通信Ｕ１は複数の情報処理装置間で発生時刻が異なるため、通信Ｕ２の発生時刻も情報処理装置間で異なっており、サーバ装置２０での輻輳や処理負荷の急激な増加は発生しづらい。
【００８３】
また、通信Ｂ１は同報通信であり複数の情報処理装置間において同一の時刻である時刻Ｔ４にて通信Ｂ１を受けたタスクＡＰ１が処理を開始し、この処理において時刻Ｔ５で第１の状態変化が発生すると、状態変化の通知Ｓ３がタスクＡＰ３に通知され処理が実行される。同様に、時刻Ｔ６で第２の状態変化が発生すると、状態変化の通知Ｓ４がタスクＡＰ４に通知され、処理が実行される。このため、通信Ｕ３が発生する時刻も複数の情報処理装置においてほぼ同一の時刻となり、通信が集中することでサーバ装置２０での輻輳の発生や処理負荷のピークが大きくなってしまう。
【００８４】
一方で、情報処理装置１０は、タスクの実行に伴い端末状態が変化した際に図６に示すように通知を行い通知先タスクが実行される。情報処理装置１０においては、時刻Ｔ１にて通信Ｕ１を受けたタスクＡＰ２が処理を開始し、この処理において時刻Ｔ２で第１の状態変化が発生すると、状態変化の起因となるタスクＡＰ２の挙動種別が参照されるが、大域同期型ではないため、従来装置と同様に状態変化の通知Ｓ１、Ｓ２がタスクＡＰ３、ＡＰ４に通知され、タスクＡＰ３、ＡＰ４は従来装置と同様の挙動となる。
【００８５】
また、時刻Ｔ４にて通信Ｂ１を受けたタスクＡＰ１が処理を開始し、この処理において時刻Ｔ５で第１の状態変化が発生すると、状態変化の起因となるタスクＡＰ１の挙動種別が参照され、大域同期型であるため、通知先のタスクＡＰ３、ＡＰ４へ状態変化の通知は行われない。したがって、タスクＡＰ３、ＡＰ４の何れも実行されず、通信も発生しない。つまり、サーバ装置２０での輻輳の発生を回避することや処理負荷のピークを小さくすることができる。
【００８６】
このように、情報処理装置１０においては、状態通知処理において、状態変化がタスクに起因するもので、かつ、そのタスクが大域同期型である際に通知を行わないことで、サーバ装置２０での輻輳の発生を回避することや処理負荷のピークを小さくする。
【００８７】
図１１は、図６の変形版である。図１１において、時刻Ｔ４にて通信Ｂ１を受けたタスクＡＰ１が処理を開始し、この処理において時刻Ｔ６で第２の状態変化が発生すると、状態変化の起因となるタスクＡＰ１の挙動種別が参照され、大域同期型であると判断する。しかしながら、通知先のタスクＡＰ４の通信種別を参照し、タスクＡＰ４は処理において通信を発生しないことを判定し、通知先のタスクＡＰ４へ状態変化の通知Ｓ４を通知する。
【００８８】
続いて、上述した一連の情報処理装置１０による処理をコンピュータに実行させるための状態通知プログラム７０を説明する。図７に示すように、状態通知プログラム７０は、コンピュータに挿入されてアクセスされる、あるいはコンピュータが備える記録媒体８０に形成されたプログラム格納領域８１内に格納される。
【００８９】
状態通知プログラム７０は、検知モジュール７００と、通知モジュール７０１とを備えて構成される。検知モジュール７００と、通知モジュール７０１とを実行させることにより実現される機能は、上述した情報処理装置１０の検知部１０１と、通知部１０３との機能とそれぞれ同様である。
【００９０】
なお、状態通知プログラム７０は、その一部若しくは全部が、通信回線等の伝送媒体を介して伝送され、他の機器により受信されて記録（インストールを含む）される構成としてもよい。また、状態通知プログラム７０の各モジュールは、１つのコンピュータでなく、複数のコンピュータのいずれかにインストールされてもよい。その場合、当該複数のコンピュータから成るコンピュータシステムによって上述した一連の状態通知プログラム７０の処理が行われる。
【００９１】
［変形例］
上述した実施形態は、本発明の実施の一例に過ぎず、以下のように変形させてもよい。また、上述した実施形態及び以下に示す各変形例は、必要に応じて組み合わせて実施してもよい。
【００９２】
（変形例１）
記憶部１０２は、挙動種別を判断する際に、タスクの属性情報や実行中のタスクによる挙動種別の指定だけでなく、タスクが定期動作するために将来の実行時刻を指定する際の指定時刻や指定方法から判断してもよい。実行時刻の指定時刻や指定方法が複数の情報処理装置１０間で同一時刻となる可能性が高い場合は大域同期型と判断し、それ以外のタスクは大域非同期型と判断する。例えば、日付が変わった際に処理を実行することを意図して指定時刻が００：００のように正時ちょうどに設定するタスクや、正時ちょうどではないが「毎日０６：３８」のように常に毎回同じ時刻を設定するタスクを大域同期型と判断する。さらに、実行時刻の指定方法が情報処理装置１０の起動時刻からの経過時間のような相対時刻指定ではなく、カレンダーや時計に基づく絶対時刻指定を用いているタスクであれば大域同期型と判断してもよい。
【００９３】
なお、挙動種別の判断は記憶部１０２内でのみ行わずに、サーバ装置２０と協調して判断してもよい。この場合、情報処理装置１０は各タスクにより設定された実行時刻をサーバ装置２０に送信し、サーバ装置２０は複数の情報処理装置１０から受取った実行時刻のうちで、一定数以上の情報処理装置１０で指定されている実行時刻を設定しているタスクについて大域同期型と判断する。サーバ装置２０は判断結果を情報処理装置１０へ送信する。
【００９４】
なお、上記では記憶部１０２が大域同期型の判断を行うと説明したが、取得部が判断してもよい。具体的には、取得部は、検知部１０１によって検知された状態変化の発生元であるタスクについて、当該タスクの実行を予約した時刻が実時間を基準にした絶対時刻である場合、当該挙動種別を大域同期型として取得してもよい。
【００９５】
（変形例２）
記憶部１０２は、挙動種別を判断する際に、タスクの属性情報や実行中のタスクによる挙動種別の指定だけでなく、サーバ装置２０から送信される挙動種別テーブルを用いてもよい。サーバ装置２０は、事前に各タスクの挙動種別の判断結果を挙動種別テーブルとして保持しておき、記憶部１０２からの要求に応じて挙動種別テーブルを送信する。
【００９６】
（変形例３）
通知部１０３は、状態変化の発生要因となったタスクが大域同期型である場合においても、通知先タスクのうち、処理にて通信が発生しないタスク（以下では「非通信タスク」という）については、状態変化の通知を行ってもよい。これにより、サーバ装置２０での輻輳の発生を回避することや処理負荷のピークを小さく抑えつつ、非通信タスクについては従来装置での挙動を維持することができる。タスクに含まれる属性情報から非通信タスクであるかどうかを判断するが、属性情報だけで判断できない場合には、状態変化の通知を行い、その際に通信が発生したかどうかの履歴（通信履歴）を、不図示の通信履歴保持部（通信履歴保持手段）が保持することで判断してもよい。すなわち、通信履歴保持部は、通知部１０３によって状態変化情報が通知先に通知された際に、通知先にて当該通知に基づいて通信が発生したか否かを通信履歴として保持する。そして、通知部１０３は、通知先タスクが通信可能であるか否かを通信履歴保持部によって保持された通信履歴に基づいて決定する。
【００９７】
なお、非通信タスクの処理において別のタスクと連携して動作する場合においては、連携して動作する別のタスクが通信を発生するかどうかも併せて判断し、通信が発生する場合は非通信タスクであっても通知を行わないようにしてもよい。
【００９８】
（変形例４）
通知部１０３は、状態変化の発生要因となったタスクが大域同期型である場合においても、例えば、当該状態変化が予め制御の対象外として指定されたもの及び通知先が予め制御の対象外として指定されたものの少なくとも一方に該当する場合、状態変化情報を通知先に通知することとしてもよい。なお、当然のことながら事前に指定していない状態変化は通知が制御される。この構成により、例えば、通知を行っても通知先で通信が発生しないことが分かっている状態変化を予め制御の対象外として指定しておくことで、当該タスクが大域同期型であっても状態変化情報が通知先に通知されるため、従来装置での挙動を前提としたタスクでも動作させることができる。また、この構成により、例えば、通知を行っても通知先で通信が発生しないことが分かっている通知先タスクについては、タスク識別子を予め制御の対象外として指定しておくことで、通知部１０３により当該通信種別が参照されて通信の有無が判断され、当該タスクが大域同期型であっても状態変化情報が通知されることとなり、通知先タスクでは通信の発生しない処理のみが実行されるため、従来装置での挙動を前提としたタスクでも動作させることができる。
【００９９】
（変形例５）
通知部１０３は、状態変化の発生要因となったタスクが大域同期型である場合においても、乱数的に生成した時間だけ遅延させて、状態変化の通知を行ってもよい。これにより、通知先タスクの処理により通信は発生するが、複数の情報処理装置１０間では通信の発生するタイミングが分散するため、サーバ装置２０での輻輳の発生を回避することや処理負荷のピークを小さく抑えつつ、従来装置での挙動を維持することができる。
【０１００】
（変形例６）
通知部１０３は、状態変化の発生要因となったタスクが大域同期型である場合においても、通知先タスクでの通信を一定時間だけ遮断するように指定したうえで、状態変化の通知を行ってもよい（例えば、状態変化情報と共に通知先タスクでの通信を一定時間だけ遮断するように指定する指示情報を通知先に通知する）。これにより、通知先タスクの処理により通信を試みようとするが実際には通信が遮断されているため、サーバ装置２０での輻輳の発生を回避することや処理負荷のピークを小さくすることができる。なお、通信を遮断するように指定するのではなく、通信の開始を乱数的に生成した時間だけ遅延させるように指定してもよい。また、通信を遮断するように指定するのではなく、通知先タスクでの処理を制御させるように指定してもよい。通知部１０３は、例えば、挙動種別が大域同期型である場合、状態変化情報と共に通知先の処理を制御する指示情報を通知先に通知してもよい。
【０１０１】
（変形例７）
通知部１０３は、挙動種別が大域同期型であり、かつ通知先が通信可能である場合、通知先への状態変化情報の通知を回避する、又は状態変化情報を通知先に遅延して通知する、又は状態変化情報と共に通知先の通信を制御する指示情報を通知先に通知してもよい。
【０１０２】
（変形例８）
記憶部１０２は、挙動種別の判断を行わず、通知部１０３において挙動種別を判断してもよい。具体的には、状態変化を引き起こしたタスクを検知できない、または、状態変化を引き起こしたタスクに挙動種別が設定されていない場合、検知部１０１により検知された端末の状態変化が事前に定める状態変化に該当していれば、状態変化を引き起こしたタスクの挙動種別を大域同期型とみなす。この構成においては、記憶部１０２において挙動種別テーブルを持たなくてもよい。なお、状態変化を引き起こしたタスクが検知できない場合、表示領域に表示されているタスクを、状態変化を引き起こしたタスクであるとみなす。
【０１０３】
また、表示領域への表示を伴わないタスクであっても、前記状態変化の通知を受取通知種別として指定しているタスクであれば、状態変化を引き起こしたタスクであるとみなしてもよい。
【０１０４】
前記状態変化が起こった際に大域同期型であるとみなしたタスクであっても、状態変化を引き起こしたタスクが終了、または、表示領域から非表示となった時点、および、前記状態変化が起こってから一定時間経過した時点、および、事前に定める状態変化（例えば、表示領域の消灯）が起こった時点において、以降に動作する（大域同期型であるとみなしていた）タスクの挙動種別を大域非同期型であるとみなしてもよい。
【０１０５】
また、検知部１０１は、状態変化を引き起こしたタスクを取得しない既存技術における検知部から構成され、記憶部１０２は受取通知種別テーブルを保持する既存技術における記憶部と、挙動種別テーブルを保持する挙動種別記憶部とから構成され、通知部１０３は、挙動種別に応じて通知方法を異ならせることのない既存技術における通知部と、通知部から配信される通知を挙動種別に応じて破棄するよう制御を行う通知制御部とから構成されてもよい。
【０１０６】
図１２は、本変形例における情報処理装置１０ａが実現する機能構成を示すブロック図である。情報処理装置１０ａは、図３に示す各部と比べ、状態変化を引き起こしたタスクを取得しない既存技術における検知部１０６と、受取通知種別テーブルを保持する既存技術における記憶部１０７と、挙動種別テーブルを保持する挙動種別記憶部１０８と、挙動種別に応じて通知方法を異ならせることのない既存技術における通知部１０４（既存通知手段）と、通知制御部１０５（通知制御手段）とを備える。
【０１０７】
通知制御部１０５は、既存技術における通知部１０４から配信される通知のうち逐次に行われる通知を制御対象とする。ただし、これに限定されるものではなく、一斉に行われる通知を制御対象としてもよい。具体的な制御手順としては、既存技術における通知部１０４は、検知部１０１によって検知された状態変化に関する状態変化情報を通知先に通知し、通知制御部１０５は、検知部１０１によって検知された状態変化に関する状態変化情報の通知先への通知方法を、取得部によって取得された当該状態変化の発生元であるタスクの挙動種別に基づいて決定し、決定された通知方法に基づいて既存技術における通知部１０４による通知を制御する。
【０１０８】
通知制御部１０５は他のタスクと同様に受取り通知種別を登録するが、その際の優先度は他の全ての通知先タスクよりも高い値とすることにより既存技術における通知部１０４からの通知を最初に受け取るとともに、状態変化を引き起こしたタスクの挙動種別を取得し、大域同期型である場合は通知先タスクに対して通知を配信しないよう、既存技術における通知部１０４に対して通知を中止する処理を実行させる。一方で、大域非同期型である場合は、既存技術における通知部１０４に対して次に優先度の高いタスクへ通知を行わせる。
【０１０９】
なお、通知制御部１０５の制御は、大域同期型である場合において通知を中止する処理を実行するだけではなく、乱数的に生成した時間だけ待ってから、既存技術における通知部１０４に対して優先度の高い順に通知先タスクへの通知を行わせるようにしてもよい。
【符号の説明】
【０１１０】
１…情報処理システム、２…ネットワーク、１０・１０ａ…情報処理装置、１１…制御装置、１２…音声入出力装置、１３…通信装置、１４…操作装置、１５…表示装置、１６…記憶装置、１７…電源制御装置、２０…サーバ装置、６０…記憶媒体、６１…プログラム格納領域、７０…状態通知プログラム、１０１…検知部、１０２…記憶部、１０３…通知部、１０４…既存技術における通知部、１０５…通知制御部、１０６…既存技術における検知部、１０７…既存技術における記憶部、１０８…挙動種別記憶部、７００…検知モジュール、７０１…通知モジュール。
【図１】
2014115975.tif 000003
【図２】
2014115975.tif 000004
【図３】
2014115975.tif 000005
【図４】
2014115975.tif 000006
【図５】
2014115975.tif 000007
【図６】
2014115975.tif 000008
【図７】
2014115975.tif 000009
【図８】
2014115975.tif 000010
【図９】
2014115975.tif 000011
【図１０】
2014115975.tif 000012
【図１１】
2014115975.tif 000013
【図１２】
2014115975.tif 000014