JP5801331B2

JP5801331B2 - タスク制御装置

Info

Publication number: JP5801331B2
Application number: JP2013014585A
Authority: JP
Inventors: 哲平小西; 稲村　浩; 浩稲村; 剛神山; 仁嗣川崎
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2012-06-28
Filing date: 2013-01-29
Publication date: 2015-10-28
Anticipated expiration: 2033-01-29
Also published as: EP2869196A1; JP2014029662A; EP2869196A4; WO2014003128A1

Description

本発明はタスクの制御に関する。

近年、複数のタスクを同時に実行できるマルチタスクＯＳ（Operating System）を搭載する情報処理装置が増加している。マルチタスクＯＳを搭載するものの一例として、スマートフォンがある。スマートフォンは、従来の携帯装置とは違い、液晶画面のバックライト消灯時においても、アプリケーションプログラム（以下ではアプリという）の各タスクが、サーバ装置装置とのデータ同期や、ＧＰＳ（Global Positioning System）や無線Ｌ
ＡＮ（Local Area Network）に関連した処理を行うためにＣＰＵが頻繁に稼動状態となるため電力を消費する。さらに、スマートフォンにおいては無線通信の発生回数も増加するため、基地局が処理すべき信号の信号量も増加し、基地局や移動通信網における負荷が大きくなる。また、複数のスマートフォンが同時に通信を行うこと（以下ではバーストトラフィックという）があるが、これにより基地局または移動通信網における負荷が一時的に増大する現象も発生している。

特開平８−２５５０８８号公報

複数のタスクを制御する技術として、特許文献１には、タスクを時間指定または時刻指定に分離してタスクの実行要求を制御する仕組みが開示されている。しかし、この仕組みは、タスクを２種類に分離してタイマ割り込みの機会を減らすというものに過ぎず、省電力化とネットワーク負荷の軽減という観点ではまだ十分とはいえない。
そこで、本発明は、タスクの制御によって処理負荷の軽減を行うことを目的とする。

本発明は、指定された時刻の変更を許さないように設定された第１のタスクについては、当該実行時刻に実行する一方、前記指定された時刻の変更を許すように設定された第２のタスクについては、前記第１のタスクの実行時刻とは異なる時刻に、当該第２のタスクどうしをまとめて実行するタスク制御部を備えることを特徴とするタスク制御装置を提供する。

前記タスク制御部は、前記タスクを識別するためのタスク識別情報と、当該タスクの実行時刻と、当該タスクが前記第１のタスクか前記第２のタスクであるかを示すタイプ情報を含む実行要求情報を取得し、当該タイプ情報に基づいて、当該タスクが前記第１のタスクか前記第２のタスクであるかを判断するようにしてもよい。

前記タスク制御部は、前記タスクを識別するためのタスク識別情報と、当該タスクの実行時刻とを含む実行要求情報を取得し、当該実行時刻に基づいて、当該タスクが前記第１のタスクか前記第２のタスクであるかを判断するようにしてもよい。

前記タスク制御部は、格納部と、前記第１のタスクについては、当該タスクについて設定された実行時刻を前記格納部に格納し、前記第２のタスクについては、前記第１のタスクの実行時刻とは異なる時刻であって、当該第２のタスクどうしをまとめて実行するよう

な実行時刻を設定して前記格納部に格納する格納処理部を備え、前記格納部に格納された実行時刻が到来したときに前記第１のタスク及び前記第２のタスクを実行するようにしてもよい。

前記格納処理部は、実行時期に周期性のあるタスク群と実行時期に周期性のないタスク群とを含む前記第２のタスク群のうち、実行時期に周期性のあるタスク群については、実行周期に公約数を含むタスクどうしをまとめて実行するような実行時刻を設定して前記格納部に格納するようにしてもよい。

前記格納処理部は、実行時期に周期性のあるタスク群と実行時期に周期性のないタスク群とを含む前記第２のタスク群のうち、通信処理を発生させず且つ実行時期に周期性のないタスクについては、前記第１のタスクと同時に実行するような実行時期を設定して前記格納部に格納するようにしてもよい。

前記格納処理部は、通信処理を発生させる前記第２のタスクにおいては、当該第２のタスクにおける通信開始時刻に基づいて、同時に通信が開始されるような実行時刻を設定して前記格納部に格納するようにしてもよい。

前記タスク制御部は、格納部と、前記第１のタスク及び前記第２のタスクについて設定された実行時刻を前記格納部に格納する格納処理部と、前記第１のタスクについては、当該タスクについて前記格納部に格納された実行時刻に実行する一方、前記第２のタスクについては、当該タスクについて前記格納部に格納された実行時刻を、前記第１のタスクの実行時刻とは異なる時刻であって、当該第２のタスクどうしをまとめて実行するような実行時刻に変更して実行する実行部とを備えるようにしてもよい。

前記タスク制御部は、休止状態から稼動状態に遷移する条件が、前記第２のタスクに対するイベント通知であった場合には、休止状態から稼動状態に遷移した時刻を経過した前記第２タスクの設定時刻を、休止状態から稼動状態に遷移した時刻以降に実行時刻が設定されている第２タスクのうち、最も早い実行時刻の第２タスクのものに設定するようにしてもよい。

前記タスク制御部は、休止状態から稼動状態に遷移する条件が、前記タスクの実行要求及び前記イベント通知のいずれでもない場合には、休止状態から稼動状態に遷移した時刻を経過した前記第２タスクの設定時刻を、休止状態から稼動状態に遷移した時刻以降に実行時刻が設定されている第２タスクのうち、最も早い実行時刻の第２タスクのものに設定するようにしてもよい。

自装置の状態を管理する状態管理部を備え、前記タスク制御部は、前記状態管理部によって管理されている状態に基づいて前記タスクの実行時刻を変更するか否かを判断してから、当該タスクを実行するようにしてもよい。

自装置に入力される情報に基づいて前記タスク制御部の挙動を変更する制御ポリシー変更部を備え、前記タスク制御部は、前記制御ポリシー変更部によって変更された制御ポリシーに従ってタスクの実行を制御するようにしてもよい。

前記タスク制御部は、自タスク制御装置を備えた情報処理装置を含む複数の情報処理装置に一斉に配信される同報情報を受取ったことを検知する同報受信検知部を備え、前記格納処理部は、前記同報受信検知部が前記同報情報を検知した場合に、当該検知した時点において実行時刻が経過している前記第２のタスクがあれば、当該第２のタスクについての実行時刻を、当該検知した時点以降の実行時刻に上書きして前記格納部に格納するようにしてもよい。

前記タスク制御部は、自タスク制御装置を備えた情報処理装置を含む複数の情報処理装置に一斉に配信される同報情報を受取ったことを検知する同報受信検知部を備え、前記格納処理部は、前記同報受信検知部が前記同報情報を検知した場合に、当該検知した時点において実行時刻が経過している前記第２のタスクがあれば、当該検知した時点において実行時刻が経過している前記第２のタスクについての実行時刻を削除するようにしてもよい。

本発明によれば、タスクの制御によって処理負荷の軽減を行うことが可能となる。

本発明の実施形態に係る情報処理装置の構成を示すブロック図である。情報処理装置の機能構成を示すブロック図である。情報処理装置の基本的な動作のタイミングチャートである。実行要求情報のフォーマットの一例を示す図である。情報処理装置の動作を示すフローチャートである。情報処理装置の動作を示すフローチャートである。動作の一例を説明する図である。動作の一例を説明する図である。変形例に係る情報処理装置の機能構成を示すブロック図である。変形例に係る実行要求情報のフォーマットの一例を示す図である。変形例に係る情報処理装置の動作を示すフローチャートである。変形例に係る情報処理装置の機能構成を示すブロック図である。変形例に係る情報処理装置の機能構成を示すブロック図である。変形例に係る情報処理装置の動作を示すフローチャートである。変形例に係る動作を一例を説明する図である。変形例に係る情報処理装置の動作を示すフローチャートである。変形例に係る情報処理装置の機能構成を示すブロック図である。変形例に係る情報処理装置の機能構成を示すブロック図である。変形例に係る情報処理装置の動作を示すフローチャートである。

以下、図面を参照して、本発明に係る情報処理装置の好適な実施形態について詳細に説明する。
＜構成＞
図１は、実施形態に係る情報処理装置１００の全体構成を示す一例である。情報処理装置１００は、例えば通話及びデータ通信が可能な携帯電話機などのコンピュータであり、移動通信網を介して他の移動通信装置やサーバ装置装置との間で通話やデータ通信を実現する。情報処理装置１００は、本発明に係るタスク制御装置に相当する。情報処理装置１００は、アプリケーション２００、フレームワーク３００、ライブラリ４００、カーネル５００及びハードウェア６００を有する。アプリケーション２００は、例えば、タスク２１１とタスク２１２によって構成されるアプリケーション２１０と、タスク２２１とタスク２２２によって構成されるアプリケーション２２０を含む。フレームワーク３００は、例えば、タスク２１１、２１２の実行要求に従いこれらを実行するタスク制御部３１０と、ＣＰＵやメインメモリなどのリソースを管理するリソース管理部３２０と、情報処理装置１００の位置を管理する位置情報管理部３３０をと含む。ライブラリ４００は、例えば、データベースライブラリ４１０と、電力制御ライブラリ４２０と、Java（登録商標）VM（Virtual Machine）４３０とを含む。カーネル５００は、情報処理装置１００の電源の
管理を行う電源管理部５１０と、表示部６４０の管理を行う画面管理部５２０と、情報処理装置１００におけるプロセスの管理を行うプロセス管理部５３０とを含む。ハードウェア６００は、例えば、ベースバンドチップ６１０、ＣＰＵ（Central Processing Unit）
６２０、メモリ（主記憶装置及び補助記憶装置）６３０、表示部６４０、操作部６５０、無線ＬＡＮ通信部６６０を有する。

タスク制御部３１０は、タスク制御部３１０が提供する関数を利用して登録されたタスクを、その実行要求情報に応じて実行する。タスクの実行要求情報は、そのタスクを実行する実行時刻と、その実行時刻がプログラマ乃至ユーザ（以下単にプログラマと言う）によって設定された実行時刻か又は情報処理装置１００のシステムによって設定された実行時刻かを表す設定時刻タイプとからなる。

プログラマによって設定された時刻を実行時刻とするタスク（本発明に係る第１のタスク、以降、P-Taskという）の例として、目覚まし時計に関するタスクがある。目覚まし時計に関するタスクは、プログラマが用意した時刻群の中からユーザが指定した実行時刻（例えば毎朝７時）に動作するタスクである。つまり、P-Taskは、設定された実行時刻とは異なる時刻に実行されしまうと、サービスとしての価値がないタスクであり、指定された絶対的な実行時刻の変更を許さないように設定されたタスクである。

一方、プログラマが実行時刻を指定したとしても、システムによって最適化された時刻を実行時刻とするタスク（本発明に係る第２のタスク、以降S-Taskという）には、実行時刻に周期性のあるタスクと周期性のないタスクの２種類がある。周期性のあるタスクの例として、情報処理装置１００が移動通信網を介して通信を行うサーバ装置装置とのセッションを維持するためのKeep Aliveと呼ばれるタスクがある。このタスクが実行される周期さえ守れば、サーバ装置装置とのセッションは維持されるため、例えば毎朝７時というような絶対的な時刻にタスクが実行される必要はない。従って、システムは、このタスクの初回の実行時刻を自由に決定することができ、また、その後は、前回のタスク実行との相対的な実行時刻に実行すればよい。また、周期性のないタスクは、実行時刻の制約がなく、いつ実行されてもよいため、このタスクについてもシステムが実行時刻を自由に決定できる。従って、S-Taskは、絶対的な時刻以外の時刻に動作するタスクであり、プログラマによって指定された時刻の変更を許すように設定されたタスクである。

＜基本動作＞
図２は、情報処理装置の機能構成の一例を示す図であり、図３は情報処理装置の基本的な動作のタイミングチャートである。タスク制御部３１０は、格納処理部３１１、格納部３１２及び実行部３１３を備える。格納部３１２はメモリ６３０によって実現され、格納処理部３１１及び実行部３１３はＣＰＵ６２０によって実現される。図３に示すように、各アプリケーション（アプリＡ、アプリＢ）の実行中において、各タスク（タスクＡ、Ｂ）は、タスク制御部３１０の関数を呼び出し、引数である実行要求情報をその関数に引き渡すことで、格納処理部３１１は実行要求情報を取得する（ステップＳ１）。格納処理部３１１は、その実行要求情報を順次格納部３１２に格納する（ステップＳ２）。ここまでがタスク実行要求格納スレッドである。

ここで、実行要求情報のフォーマットの一例を図４に示す。図４（Ａ）に示すように、実行要求情報は、タスク名、設定時刻タイプ(P-taskかS-taskか)及び実行時刻を含む。なお、タスク名は、タスクを識別する識別情報であればよい。また、図４（Ｂ）に示すように、実行要求情報は、タスク名、設定時刻タイプ(P-taskかS-taskか) )及び実行時刻のほか、通信の有無情報、通信開始時刻、通信終了時刻及びリソース消費量を含んでいてもよい。

一方、タスク実行スレッドは、実行部３１３の休止状態（いわゆるスリープ）が解除されて稼動状態に遷移することを契機として開始される。実行部３１３が格納部３１２の実行要求情報へアクセスし（ステップＳ３）、実行要求情報を確認する（ステップＳ４）。実行部３１３が休止状態から稼動状態に遷移する条件は、（１）タスクの実行要求に基づくもの、（２）電池残量の変化やネットワーク状況などのイベント通知を行うことに基づくもの、（３）上記（１）（２）以外のもの（例えばカーネルのデバイス管理のためのものや、操作部６５０の押下によるもの）がある。実行部３１３は、実行要求情報を確認した結果、上記（１）に該当する場合には、稼動の契機となったタスク（図３ではタスクＡとする）を実行する実行命令をアプリケーションＡに対して発行する（ステップＳ５）。これによりタスクＡが実行される。

＜格納処理部の動作＞
格納処理部３１１が実行要求情報を格納部３１２に格納するときの動作を、図５を用いて説明する。まず、アプリケーションＡの新たなタスクＡが格納処理部３１１の関数を呼び出し、引数としての実行要求情報が引き渡された際に、格納処理部３１１はタスクのタイプがP-TaskかS-Taskかを判断する（ステップＳ１００）。P-Taskであった場合（ステップＳ１００；P-Task）、格納処理部３１１は、そのタスクＡが保持している実行要求情報を、そのまま格納部３１２へ格納する（ステップＳ２００）。S-Taskであった場合（ステップＳ１００；S-Task）は、格納処理部３１１は、S-Taskの格納処理を行う（ステップＳ３００）。

＜S-Taskの格納処理＞
次に、S-Taskの格納処理を図６〜８を用いて説明する。まず、格納処理部３１１は、タスクＡが周期性を持つタスクかを判断する(ステップＳ３０１)。周期的なタスクであった場合には（ステップＳ３０１；Ｙｅｓ）、格納処理部３１１は、既に格納部３１２に格納されている実行要求情報の周期を取得し（ステップＳ３０２）、実行要求情報の周期とタスクＡの周期との間に、周期の最小単位（例えば１（分））よりも大きい公約数があるかどうかを判断する（ステップＳ３０３）。そのような公約数がある場合（ステップＳ３０３；Ｙｅｓ）、格納処理部３１１は、タスクＡの周期をメモリ６３０に記録する（ステップＳ３０４）。

公約数がない場合（ステップＳ３０３；Ｎｏ）、格納処理部３１１は、格納部３１２にまだ比較していないタスクがあるか否かを判断する（ステップＳ３０５）。格納部３１２にまだ比較していないタスクがある場合（ステップＳ３０５；Ｙｅｓ）、格納処理部３１１は、もう一度ステップＳ３０２へ戻って上記と同じ処理を行う。全て比較し終えた場合には（ステップＳ３０５；Ｎｏ）、格納処理部３１１は、ステップＳ３０４で記録した周期のうちで最大のものを特定する（ステップＳ３０６）。そして、格納処理部３１１は、最大の周期をもつタスクの次回実行時刻をタスクＡの初回実行時刻として、タスクＡの実行要求情報を格納部３１２に格納する（ステップＳ３０７）。

ステップＳ３０１〜３０７の一例を図７を用いて説明する。周期が１０であるタスクＢの実行要求情報と、周期が３０であるタスクＣの実行要求情報が既に格納部３１２に格納されている場合に、時刻Ｔにおいて、周期が１５のタスクＡの実行要求情報が新たに生成されたとする。この場合、タスクＡとタスクＢとの最大公約数は５であり、タスクＡとタスクＣとの最大公約数は１５であるから、タスクＡの初回実行時刻は、タスクＣの次回実行時刻である３０となる。

図６の説明に戻り、タスクＡが周期性を持たないタスクだった場合（ステップＳ３０１；Ｎｏ）、格納処理部３１１は、既に格納部３１２に格納されている実行要求情報に係るタスクの周期を取得し（ステップＳ３０８）、そのタスクが周期性のあるタスクであるか否かを判断する（ステップＳ３０９）。周期性のあるタスクである場合（ステップＳ３０９；Ｙｅｓ）、格納処理部３１１は、そのタスクの現在時刻以降で直近の実行時刻をメモリ６３０に記録する（ステップＳ３１０）。格納部３１２にまだ取得していないタスクがある場合（ステップＳ３１１；Ｙｅｓ）、格納処理部３１１は、もう一度ステップＳ３０８へ戻って上記と同じ処理を行う。全て取得し終えた場合には（ステップＳ３１１；Ｎｏ）、格納処理部３１１は、ステップＳ３１０で記録した実行時刻のうち、現在時刻に最も近いものをタスクＡの初回実行時刻として、タスクＡの実行要求情報を格納部３１２に格納する。

ステップＳ３０１〜３０７の一例を図８を用いて説明する。タスクＢ，Ｃ，Ｄの実行要求情報が既に格納部３１２に格納されている場合に、時刻Ｔにおいて、タスクＡの実行要求情報が新たに生成されたとする。タスクＢ，Ｃ，Ｄのうち、タスクＣ，Ｄは実行時間に周期性があるタスクであり、タスクＢは実行時間に周期性がないタスクとする。この場合、タスクＢについては周期性がないため、格納処理部３１１は、ステップＳ３０９からステップＳ３１１の処理へ遷移する。ここでは全タスクの周期を取得していないため（ステップＳ３１１；Ｎｏ）、格納処理部３１１は、ステップＳ３０８の処理に戻り、次のタス

クＣの周期性の有無を判断する。タスクＣは周期性があるため、格納処理部３１１は、ステップＳ３１０でタスクＣの直近の次回実行時刻である２０をメモリ６３０に格納する。同様にタスクＤについても直近の次回実行時刻である５０がメモリに格納される。格納処理部３１１は、ステップＳ３１２でメモリに格納されている２０と５０とを比較し、小さい方の２０をタスクＡの初回実行時刻として格納部３１２に格納する。

以上のようにして、格納部３１２に実行要求情報が格納されると、その実行要求情報に含まれる実行時刻が到来したタイミングで実行部３１３によりタスクが実行される。

＜変形例＞
上述した実施形態は次のような変形が可能である。以下の変形例を互いに組み合わせて実施してもよい。
＜変形例１＞
実施形態では、情報処理装置１００が休止状態から稼動状態に遷移したときの条件がタスクの実行要求によるものである場合には、稼動の契機となったタスクを実行していた。これを、実行部３１３が、情報処理装置１００の状態に関する状態情報（例えば表示部のバックライトの点灯又は消灯、電池残量、リソースの消費量、ネットワーク状態、情報処理装置と電源ケーブルとの切断又は接続などの関する情報）をフレームワークの提供するＡＰＩ（Application Program Interface）から取得し、この状態情報を用いてタスク実
行を制御するようにしてもよい。この場合、図９に示すように、タスク制御部３１０は、状態情報を管理する状態管理部３１４を備える。この状態管理部３１４はＣＰＵ６２０及びメモリ６３０によって実現される。図１０は格納部３１２に格納される実行要求情報のフォーマットの一例を示す図である。情報処理装置１００の状態によっては、実行時刻を変更せずに、元々設定されていた実行時刻にタスクを実行することもあるので、タスクの実行時刻の変更前後のものが格納部３１２に格納される。タスク制御部３１０は、変更前後の実行時刻のうち、タスクの同時実行をしたほうがよいか又はしないほうがよいかという判断に基づいて、いずれの実行時刻を選択してタスクを実行する。

状態情報として表示部６４０の点灯及び消灯を用いる場合、タスク制御部３１０は、表示部６４０が点灯時にはタスクの同時実行を行わず、消灯時はタスクの同時実行を行うよう、処理を切り替える。表示部６４０の点灯時は、例えばウェブブラウジングなどユーザが表示部６４０を閲覧している可能性が高く、操作に対する処理実行の応答性への要求が高い。このようなときにタスクを同時実行することにより、タスク実行の応答性が低下してしまうと、ユーザの利便性が低下する可能性が高くなる。一方、表示部６４０の消灯時は、ユーザが表示部６４０を閲覧していない可能性が高いため、操作に対する処理実行の応答性への要求が低い。そこで、表示部６４０の消灯時は、タスクの実行時刻を変更し、省エネルギー化とネットワーク負荷の軽減を行うようタスクの同時実行を行うことが望ましい。

図１１に示すように、状態管理部３１４は、表示部６４０が点灯か消灯かを実行部３１３に通知し（ステップＳ８００）、実行部３１３は表示部６４０が点灯状態であるか消灯状態であるかを判断する（ステップＳ８１０）。点灯状態であった場合（ステップＳ８１０；Ｙｅｓ）、実行部３１３は、格納部３１２内の変更前の実行時刻を参照し（ステップＳ８２０）、その実行時刻に実行処理を行う(ステップＳ８３０)。一方、表示部６４０が消灯状態だった場合（ステップＳ８１０；Ｎｏ）、実行部３１３は、格納部３１２内の変更後の実行時刻を参照し（ステップＳ８４０）、その時刻に実行処理を行う（ステップＳ８３０）。

状態情報として、タスクを実行したときの情報処置装置１００におけるリソースの消費量を用いる場合、タスク制御部３１０は、同時実行の対象となる各タスクによるリソース

消費量を足し合わせた合計値が閾値を超えた場合は、その合計値が閾値以下に収まるよう、リソース消費量の多いタスクから同時実行の処理対象から外していく。例えば、データ量がメインメモリの上限に達した場合、タスクがフリーズまたはクラッシュし、正しく動作しなくなる可能性があるため、このような場合に同時実行の対象となるタスクの数を減らすほうがよい。各タスクによるリソース消費量を示す情報は各タスクの実行要求情報に予め含まれていてタスク制御部３１０がそれを参照してもよいし、タスク制御部３１０がタスク実行の際にリソースの状況をモニタリングしてリソース消費量を学習してもよい。

状態情報として、移動通信網の基地局との通信又は無線ＬＡＮにおける電波受信強度や、通信スループットなどのネットワークに関する情報を用いてもよい。この場合、タスク制御部３１０は、通信可能な帯域が余っていると判断した場合は、同時実行するタスクの数を増やしてもよい。

状態情報として電池残量を用いてもよい。この場合、タスク制御部３１０は、電池残量が閾値以下の場合はタスクを同時実行して省電力化を図る。この閾値はユーザが任意の値を設定してもよいし、情報処理装置１００のシステムが自動で設定してもよい。

状態情報として、情報処理装置１００が商用電源に繋がる電源ケーブルと接続されているか否かという情報を用いてもよい。この場合、タスク制御部３１０は、電源ケーブル切断時にはタスクを同時実行して省電力化を図る。

＜変形例２＞
変形例１では、情報処理装置１００の状態に応じて、タスクの実行時刻を変更して同時実行するかどうかを切り替えていた。これを、情報処理装置１００内の情報からは得られない外部からの入力情報に基づいて制御ポリシーを変更するようにしてもよい。このようにすれば、ユーザまたは開発者の意図や、ネットワーク状況或いは他の情報処理装置の状況などを反映した制御が可能になる。この場合、図１２に示すように、タスク制御部３１０は、外部からの入力情報に応じて制御ポリシーを変更する制御ポリシー変換部３３０を備える。この制御ポリシー変換部３３０はＣＰＵ６２０及びメモリ６３０によって実現される。この変形例２においても、変形例１と同様に、制御ポリシーによっては、実行時刻を変更せずに、元々の実行時刻でタスクを実行することがあるので、タスクの実行時刻の変更前後のものが格納部３１２に格納される。

例えば図１３に示すように、制御ポリシー変換部３３０は、サーバ装置１０００が記憶する各アプリの実行要求情報の変換ルール１２００に従って、制御ポリシーを変換してもよい。実行部３１３によるタスクの実行履歴（タスク名、実行時刻、通信の有無など）を実行履歴格納部３１４に格納し、この実行履歴を実行履歴監視部３１５が監視する。実行履歴監視部３１５は、各タスクまたはアプリが、特定の時刻で実行されていないかとか、更新頻度が高くないかなどの傾向の有無を判断する。そういった傾向があった場合、実行履歴監視部３１５は、サーバ装置１０００のアプリリスト１１００に、タスクまたはアプリ名と実行要求情報を登録する。サーバ装置１０００は、登録された情報に基づき、変換ルール１２００を変更する。例えば、アプリが特定の時刻に集中して通信を行う場合、その時刻での通信を避けるような制御ポリシーに変換する。変換ルール１２００が更新されると、サーバ装置１０００は全ての情報処理装置１００の制御ポリシーを変更する。なお、実行履歴格納部３１４はメモリ６３０によって実現され、実行履歴監視部３１５はＣＰＵ６２０によって実現される。

上記の例では、実行履歴監視部３１５は、サーバ装置１０００のアプリリスト１１００に、タスクまたはアプリ名と実行要求情報を登録していたが、ユーザ自身が明示的にサーバ装置１０００のアプリリスト１１００へ登録してもよい。また、この変換ルール１２０

０とアプリリスト１１００は各情報処理装置１００が保持しておき、各情報処理装置１００がこれらに基づきタスクを制御してもよい。

移動通信網の基地局または交換機と制御ポリシー変換部３３０が通信を行い、特定の時刻に通信が集中して発生しないようタスクの実行時刻を変更してもよい。例えば、基地
局または交換機が、毎日午前７：００にバーストトラフィックの発生を観測した場合、いくつかの情報処理装置１００に対して午前７：００に通信を伴うタスクを実行しないよう、午前７：００に通信を行っているタスクの実行時刻を変更する。

また、開発者が開発段階のアプリをテストする際は、情報処理装置１００は、タスクの実行時刻を変更せず、元々設定されている実行時刻通りに実行してもよい。この場合、アプリのテストかどうかを判断するために、アプリに開発中であることを表すフラグをつけ、このフラグが付加されているアプリはタスクの実行時刻を変更しない機能をタスク制御部３１０に付加する。

＜変形例３＞
実施形態では、格納処理部３１１がタスクの実行時刻を変更したうえで格納部３１２に格納していた。これを、格納処理部３１１はタスクの実行時刻を変更せずに格納部３１２に格納し、実行部３１３がタスクを実行する際にその実行時刻を変更するようにしてもよい。この場合、図１４において、まず実行部３１３は、休止状態から稼動状態へ遷移すると、格納部３１２から実行要求情報を取得し、現在時刻と同時刻に設定されているタスクがあるか否かを確認する（ステップＳ４００）。現在時刻と同時刻に設定されているタスクがある場合、つまり休止状態から稼動状態へ遷移した条件がタスクの実行要求によるものであった場合（ステップＳ４００；Ｙｅｓ）、実行部３１３は、タスクの実行命令を発行して（ステップＳ４１０）、タスクを実行する（ステップＳ４２０）。一方、現在時刻と同時刻に設定されているタスクがない場合、つまり休止状態から稼動状態へ遷移した条件がタスクの実行要求によるものではなかった場合（ステップＳ４００；Ｎｏ）、実行部３１３は、格納部３１２に格納されているS-Taskの実行要求情報を取得する（ステップＳ４３０）。そして、実行時刻を経過したS-Taskがあった場合には（ステップＳ４４０；Ｙｅｓ）、実行部３１３は、S-Taskの実行時刻を現在時刻以降で直近のタスク（実行時刻に周期性のあるタスク）の実行時刻に書き換えて再び格納部３１２に格納する（ステップＳ４５０）。このようにすれば、情報処理装置１００の稼動状態への遷移の契機が各タスクに対するイベント通知によるものであった場合や、タスクの実行要求でもイベント通知でもない場合において、タスクの分散実行を回避でき、タスクを複数同時実行する機会が増える。

＜変形例４＞
実施形態では、複数のタスクの実行時刻を揃えて同時実行した。しかし、タスクによっては、タスク実行から数秒〜数十秒経過して通信処理が発生するものもある。例えば図１５に示すように、タスクＡとタスクＢの実行時刻は同じでも、通信開始時刻がずれて制御信号発生回数は減らないというも考えられる。そこで、タスク制御部３１０は、複数のタスクを同時実行する際は、各タスクの通信開始時刻が揃うように、各タスクの実行時刻を変更する。この場合、タスクの通信開始時刻は実行要求情報に含まれてしてタスク制御部３１０がそれを参照してもよいし、タスク制御部３１０がタスクの通信開始時刻を記した実行履歴情報を元に算出してもよい。例えばタスクＡの実行時刻をＴａ、通信開始時間をＴａｒとすると、タスクＡの通信開始時刻はＴａ+Ｔａｒとなる。タスクＢについても同
様に、実行時刻をＴｂ、通信開始時間をＴｂｒとすると、タスクＢの通信開始時刻はＴｂ+Ｔｂｒとなる。タスクＡが先に格納部３１２へ格納されている場合、格納処理部３１１
はタスクＢの実行時刻を、Ｔａ+Ｔａｒ−Ｔｂｒと変更して格納部３１２へ格納する。各
タスクの通信開始時刻を示す情報は、各タスクの実行要求情報に予め含まれていてタスク

制御部３１０がそれを参照してもよいし、タスク制御部３１０がタスク実行の際に通信の状況をモニタリングして通信開始時刻を学習してもよい。

＜変形例５＞
実施形態では、バーストトラフィック回避のため、S-Task同士のみを同時実行の対象としていたが、S-Taskで通信を伴わないものに関してはP-Taskと同時実行してもバーストトラフィックの発生原因とはならない。この場合、図１６に示すように、格納処理部３１１は、タスクＡが通信を発生するタスクかを判断する(ステップＳ７００)。通信を発生しないタスクの場合（ステップＳ７００；Ｎｏ）、格納処理部３１１は、P-TaskであるかS-Taskであるかを問わず、全タスクの中で、タスクＡの実行時刻以降で実行されるタスクのうち最も早い実行時刻を設定する（ステップＳ７２０）。一方、通信を発生するタスクだった場合（ステップＳ７００；Ｙｅｓ）、実施形態と同様に、S-Task同士が同時実行するようステップＳ３０１（図６）の処理へと移る（ステップＳ７１０）。

＜変形例６＞
実施形態では、フレームワーク３００の格納処理部３１１でタスクの実行時刻の変更を実現していたが、アプリケーションプログラムによって格納処理部３１１を実現してもよい。この場合、図１７に示すように、格納処理部３１１に代えて、その格納処理部３１１と同等の機能を実現する格納処理アプリケーション２２０を備える。格納処理アプリケーション２２０は、全てまたは一部のタスクから実行要求情報を受取り、実施形態のステップＳ１００以降の処理を行う。

＜変形例７＞
情報処理装置１００は、携帯電話機のような通信装置でなくてもよく、スタンドアロン型の情報処理装置であってもよい。また、情報処理装置１００において実行されるプログラムは、磁気テープ、磁気ディスク、フロッピー（登録商標）ディスク、光記録媒体、光磁気記録媒体、ＣＤ（Compact Disk）、ＤＶＤ（Digital Versatile Disk）、ＲＡＭなどの記録媒体に記録した状態で提供し得る。

＜変形例８＞
例えば地震などの緊急事態が発生したことを通知するメッセージ（いわゆる緊急地震速報）などのように、通信網を通じて一斉に配信される情報を、いわゆるスリープなどと呼ばれる休止状態の複数の情報処理装置１００が受信した場合（以下では「同報受信」という）に、これらの情報処理装置１００はほぼ同時に休止状態から稼動状態に遷移して、そのメッセージを表示したりする。そして、複数の情報処理装置１００はそれぞれ稼動状態に遷移したことを契機として、自装置が実行すべきタスクがあればそれを実行する。この場合、複数の情報処理装置１００において、通信を伴うS-Taskがほぼ同時に実行されると、バーストトラフィックが発生してしまうことがある。そこで、このようなバーストトラフィックの対策として、図１８に示すように、タスク制御部３１０は、同報受信を検知する同報受信検知部３１７を備え、これによって同報受信が検知された場合には、格納処理部３１１が格納部３１２内のS-Taskの実行要求情報に含まれる実行時刻を書き換えるようにしてもよい。その動作は以下のとおりである。

図１９において、まず、同報受信検知部３１４が同報受信を検知すると（ステップＳ８００；ＹＥＳ）、格納処理部３１１は、格納部３１２において、次のステップＳ８１０で未だ取得していないS-Taskの実行要求情報があるか否かを判断する（ステップＳ８１０）。取得していないS-Taskの実行要求情報があれば（ステップＳ８１０；ＹＥＳ）、格納処理部３１１は、それを取得し（ステップＳ８２０）、現在時刻が実行時刻を経過しているか否かを判断する（ステップＳ８３０）。前述したように、S-Taskは、システムによって最適化された時刻を実行時刻とするタスクであるから、休止状態では、実行要求情報に含まれる実行時刻を経過しても実行されないこともあり得る。周期性のないS-Taskは、休止状態では実行時刻を経過しても実行されないことはもちろんのこと、周期性のあるS-Taskの中にも、次回の実行時刻は設定されているが、必ずしもその実行時刻を正確に守る必要が無く、或る程度の期間をおいて繰り返し実行されるだけでよいタスクもある。この変形例ではそのようなタスクもS-Taskとみなす。ステップＳ８３０では、このようなS-Taskを見つける。

実行時刻を経過している場合（ステップＳ８３０；ＹＥＳ）、格納処理部３１１は、そのタスクに周期性があるかを判断する（ステップＳ８４０）。そのタスクに周期性がある場合（ステップＳ８４０：ＹＥＳ）、次式１によって得られる時刻を、ステップＳ８２０で取得した実行要求情報における実行時刻として上書きし、格納部３１２に格納する（ステップＳ８５０）。

ｎｅｗＳｅｔＴｉｍｅ＝ｓｅｔＴｉｍｅ+ｃｏｕｎｔ×ｉｎｔｅｒｖａｌ・・・式１
ただし、
ｃｏｕｎｔ＝１＋（ｎｏｗ−ｓｅｔＴｉｍｅ）／ｉｎｔｅｒｖａｌ［ただし、（ｎｏｗ−ｓｅｔＴｉｍｅ）／ｉｎｔｅｒｖａｌは整数型として算出される値］
であり、
ｎｅｗＳｅｔＴｉｍｅ：上書きする新たな実行時刻
ｓｅｔＴｉｍｅ：ステップＳ８２０で取得された、上書き前の実行要求情報に含まれている実行時刻
ｉｎｔｅｒｖａｌ：ステップＳ８２０で取得された、上書き前の実行要求情報から特定されるタスクの周期
ｎｏｗ：同報受信を検知した時刻（つまり現在時刻）
である。

例えば、ｎｏｗ＝１８：００、ｓｅｔＴｉｍｅ＝１７：５５、ｉｎｔｅｒｖａｌ＝１５（分）の場合、（ｎｏｗ−ｓｅｔＴｉｍｅ）／ｉｎｔｅｒｖａｌ＝５／１５だが、前述したようにこれは整数型なので、値は「０」となる。よって、ｃｏｕｎｔ＝１＋０＝１となり、ｎｅｗＳｅｔＴｉｍｅ＝ｓｅｔＴｉｍｅ+ｃｏｕｎｔ×ｉｎｔｅｒｖａｌ＝１７：５５＋１×１５（分）＝１８：１０となる。ｎｅｗＳｅｔＴｉｍｅは、必ず、現在時刻ｎｏｗ以降の値となる。

一方、タスクに周期性がない場合（ステップＳ８４０：ＮＯ）、格納処理部３１１は、次式２によって得られる時刻を、ステップＳ８２０で取得した実行要求情報に実行時刻として上書きし、格納部３１２に格納する（ステップＳ８６０）。

ｎｅｗＳｅｔＴｉｍｅ＝ｓｅｔＴｉｍｅ+ｃｏｕｎｔ×ｔ・・・式２
ただし、
ｃｏｕｎｔ＝１＋（ｎｏｗ−ｓｅｔＴｉｍｅ）／ｔ［ただし、（ｎｏｗ−ｓｅｔＴｉｍｅ）／ｔは整数型として算出される値］
であり、
ｎｅｗＳｅｔＴｉｍｅ：上書きする新たな実行時刻
ｓｅｔＴｉｍｅ：ステップＳ８２０で取得された、上書き前の実行要求情報に含まれている実行時刻
ｔ：所定の時間（例えば１５分）
ｎｏｗ：同報受信を検知した時刻
である。

例えば、ｎｏｗ＝１８：００、ｓｅｔＴｉｍｅ＝１７：５５、ｔ＝１０（分）の場合、（ｎｏｗ−ｓｅｔＴｉｍｅ）／ｔ＝５／１０だが、前述したようにこれは整数型なので、値は「０」となる。よって、ｃｏｕｎｔ＝１＋０＝１となり、ｎｅｗＳｅｔＴｉｍｅ＝ｓｅｔＴｉｍｅ+ｃｏｕｎｔ×ｔ＝１７：５５＋１×１０（分）＝１８：０５となる。ｎｅｗＳｅｔＴｉｍｅは、必ず、現在時刻ｎｏｗ以降の値となる。

なお、ステップＳ８４０、８５０において、格納処理部３１１は、上記の式１、式２を用いて実行時刻を算出していたが、その目的は、バーストトラフィックを防止するべく、同報受信を検知した時点以降の時刻でS-Taskの実行時刻を情報処理装置１００毎に分散して求めることである。したがって、このように実行時刻を適当に分散し得るようなアルゴリズムであれば、式１、式２に代えて使用することが可能である。

また、格納処理部３１１は、実行時刻を経過したS-Taskの実行時刻を上記のようにして上書きするのではなく、この実行時刻を削除しても構わない。この場合、実行時刻が削除されたタスクは実行されないことになるが、前述したトラフィックバーストを防止することを重視する場合には、このような実行中止という対策をとってもよい。

１００・・・情報処理装置、３１０・・・タスク制御部、３１１・・・格納処理部、３１２・・・格納部、３１３・・・実行部、３１４・・・状態管理部、３１５・・・実行履歴格納部、３１６・・・実行履歴監視部、３１７・・・同報受信検知部、３３０・・・制御ポリシー変換部、１０００・・・サーバ装置、１１００・・・アプリリスト、１２００・・・変換ルール

Claims

指定された時刻の変更を許さないように設定された第１のタスクについては、当該実行時刻に実行する一方、前記指定された時刻の変更を許すように設定された第２のタスクについては、前記第１のタスクの実行時刻とは異なる時刻に、当該第２のタスクどうしをまとめて実行するタスク制御部を備え、
前記タスク制御部は、
格納部と、
前記第１のタスクについては、当該タスクについて設定された実行時刻を前記格納部に格納し、前記第２のタスクについては、前記第１のタスクの実行時刻とは異なる時刻であって、当該第２のタスクどうしをまとめて実行するような実行時刻を設定して前記格納部に格納する格納処理部を備え、
前記格納部に格納された実行時刻が到来したときに前記第１のタスク及び前記第２のタスクを実行し、
前記格納処理部は、実行時期に周期性のあるタスク群と実行時期に周期性のないタスク群とを含む前記第２のタスク群のうち、通信処理を発生させず且つ実行時期に周期性のないタスクについては、前記第１のタスクと同時に実行するような実行時期を設定して前記格納部に格納する
ことを特徴とするタスク制御装置。
指定された時刻の変更を許さないように設定された第１のタスクについては、当該実行時刻に実行する一方、前記指定された時刻の変更を許すように設定された第２のタスクについては、前記第１のタスクの実行時刻とは異なる時刻に、当該第２のタスクどうしをまとめて実行するタスク制御部を備え、
前記タスク制御部は、
格納部と、
前記第１のタスクについては、当該タスクについて設定された実行時刻を前記格納部に格納し、前記第２のタスクについては、前記第１のタスクの実行時刻とは異なる時刻であって、当該第２のタスクどうしをまとめて実行するような実行時刻を設定して前記格納部に格納する格納処理部を備え、
前記格納部に格納された実行時刻が到来したときに前記第１のタスク及び前記第２のタスクを実行し、
前記格納処理部は、通信処理を発生させる前記第２のタスクにおいては、当該第２のタスクにおける通信開始時刻に基づいて、同時に通信が開始されるような実行時刻を設定して前記格納部に格納する
ことを特徴とするタスク制御装置。
指定された時刻の変更を許さないように設定された第１のタスクについては、当該実行時刻に実行する一方、前記指定された時刻の変更を許すように設定された第２のタスクについては、前記第１のタスクの実行時刻とは異なる時刻に、当該第２のタスクどうしをまとめて実行するタスク制御部を備え、
前記タスク制御部は、休止状態から稼動状態に遷移する条件が、前記第２のタスクに対するイベント通知であった場合には、休止状態から稼動状態に遷移した時刻を経過した前記第２のタスクの設定時刻を、休止状態から稼動状態に遷移した時刻以降に実行時刻が設定されている第２のタスクのうち、最も早い実行時刻の第２のタスクのものに設定する
ことを特徴とするタスク制御装置。
指定された時刻の変更を許さないように設定された第１のタスクについては、当該実行時刻に実行する一方、前記指定された時刻の変更を許すように設定された第２のタスクについては、前記第１のタスクの実行時刻とは異なる時刻に、当該第２のタスクどうしをまとめて実行するタスク制御部を備え、
前記タスク制御部は、休止状態から稼動状態に遷移する条件が、前記タスクの実行要求及び前記イベント通知のいずれでもない場合には、休止状態から稼動状態に遷移した時刻を経過した前記第２のタスクの設定時刻を、休止状態から稼動状態に遷移した時刻以降に実行時刻が設定されている第２のタスクのうち、最も早い実行時刻の第２のタスクのものに設定する
ことを特徴とするタスク制御装置。
指定された時刻の変更を許さないように設定された第１のタスクについては、当該実行時刻に実行する一方、前記指定された時刻の変更を許すように設定された第２のタスクについては、前記第１のタスクの実行時刻とは異なる時刻に、当該第２のタスクどうしをまとめて実行するタスク制御部を備え、
前記タスク制御部は、
格納部と、
前記第１のタスク及び前記第２のタスクについて設定された実行時刻を前記格納部に格納する格納処理部と、
前記第１のタスクについては、当該タスクについて前記格納部に格納された実行時刻に実行する一方、前記第２のタスクについては、当該タスクについて前記格納部に格納された実行時刻を、前記第１のタスクの実行時刻とは異なる時刻であって、当該第２のタスクどうしをまとめて実行するような実行時刻に変更して実行する実行部と
を備え、
前記タスク制御部は、自タスク制御装置を備えた情報処理装置を含む複数の情報処理装置に一斉に配信される同報情報を受取ったことを検知する同報受信検知部を備え、
前記格納処理部は、前記同報受信検知部が前記同報情報を検知した場合に、当該検知した時点において実行時刻が経過している前記第２のタスクがあれば、当該第２のタスクについての実行時刻を、当該検知した時点以降の実行時刻に上書きして前記格納部に格納する
ことを特徴とするタスク制御装置。
指定された時刻の変更を許さないように設定された第１のタスクについては、当該実行時刻に実行する一方、前記指定された時刻の変更を許すように設定された第２のタスクについては、前記第１のタスクの実行時刻とは異なる時刻に、当該第２のタスクどうしをまとめて実行するタスク制御部を備え、
前記タスク制御部は、
格納部と、
前記第１のタスク及び前記第２のタスクについて設定された実行時刻を前記格納部に格納する格納処理部と、
前記第１のタスクについては、当該タスクについて前記格納部に格納された実行時刻に実行する一方、前記第２のタスクについては、当該タスクについて前記格納部に格納された実行時刻を、前記第１のタスクの実行時刻とは異なる時刻であって、当該第２のタスクどうしをまとめて実行するような実行時刻に変更して実行する実行部と
を備え、
前記タスク制御部は、自タスク制御装置を備えた情報処理装置を含む複数の情報処理装置に一斉に配信される同報情報を受取ったことを検知する同報受信検知部を備え、
前記格納処理部は、前記同報受信検知部が前記同報情報を検知した場合に、当該検知した時点において実行時刻が経過している前記第２のタスクがあれば、当該検知した時点において実行時刻が経過している前記第２のタスクについての実行時刻を削除する
ことを特徴とするタスク制御装置。