JP2016009885A - 多機能処理装置及びその制御方法とプログラム - Google Patents

Abstract

【課題】第１の周期処理と第２の周期処理の実行周期とが一致していない場合は、第１及び第２の周期処理の２回目以降の開始時間が一致しなくなり、通常動作モードへの復帰回数が増えて消費電力の低減を阻害することになる。
【解決手段】周期的に実行される周期処理を登録できる多機能処理装置とその制御方法であって、アプリケーションで実行される周期処理の実行日時と実行周期を登録し、第１アプリケーションが登録されているときに、第２アプリケーションを登録する際、第１のアプリケーションの第１の周期処理の実行周期に合わせて第２のアプリケーションの第２の周期処理の実行周期を調整し、その調整した第２の周期処理の実行周期を登録し、その登録された実行周期に従って、各アプリケーションの周期処理を実行する。
【選択図】 図４

Description

本発明は、多機能処理装置及びその制御方法とプログラムに関するものである。

近年、環境保護の観点から事務機器の低消費電力化が求められている。これを実現するために、複写機等の事務機器では一定時間何も動作していない待機状態が続くと、装置内の各資源（印刷部、読取部、表示部、制御部等）への電力供給を停止して省電力モードへ移行する技術が知られている。

複写機能、プリンタ機能、スキャナ機能等の複数の機能を有する複合機（多機能処理装置）には、周期的に動作する様々な機能（周期処理）が実装されている。これら周期処理を実行する際は、複合機が省電力モードで動作であっても、その処理のために複合機は通常動作モードに復帰する。このため、これら周期処理の数が増大すると、複合機が省電力モードで動作している時間が少なくなり、消費電力の低減を実現できなくなるという課題がある。

例えば特許文献１には、このような消費電力の低減を阻害する要因を除去する方法が記載されている。これによれば、第１の周期処理に対する開始時間と実行周期とを記憶し、第２の周期処理の開始時間と実行周期とが設定されると、第２の周期処理の開始時間を第１の周期処理の開始時間に一致させている。

特開２００６−４１９７１号公報

上記特許文献１に記載の発明によれば、第２の周期処理の初回開始時間を第１の周期処理の次回の開始時間と一致させることにより、第２の周期処理が開始されることにより複合機の動作モードが通常モードへ復帰するのを防止できる。しかしながら、第１の周期処理と第２の周期処理の実行周期とが一致していない場合は、第１及び第２の周期処理の２回目以降の開始時間が一致しなくなり、通常動作モードへの復帰回数が増えて消費電力の低減を阻害することになる。

本発明の目的は、上記従来技術の問題点を解決することにある。

本発明の特徴は、複数のアプリケーションによる周期処理が発生する場合でも、それら周期処理を同期させて実行することにより、周期処理による消費電力の低減が阻害されるのを防止する技術を提供する。

上記目的を達成するために本発明の一態様に係る多機能処理装置は以下のような構成を備える。即ち、
周期的に実行される周期処理を登録できる多機能処理装置であって、
アプリケーションで実行される周期処理の実行日時と実行周期を登録する登録手段と、
前記登録手段に第１アプリケーションが登録されているときに、第２アプリケーションを前記登録手段に登録する際、前記第１のアプリケーションの第１の周期処理の実行周期に合わせて前記第２のアプリケーションの第２の周期処理の実行周期を調整する調整手段と、
前記調整手段によって調整した前記第２の周期処理の実行周期を前記登録手段に登録し、前記登録手段に登録された実行周期に従って、各アプリケーションの周期処理を実行する制御手段と、を有することを特徴とする。

本発明によれば、複数のアプリケーションによる周期処理が発生する場合でも、それら周期処理を同期させて実行することにより、例えば周期処理により省電力モードから復帰する回数を削減して消費電力の低減を阻害する要因を少なくできる。

本発明のその他の特徴及び利点は、添付図面を参照とした以下の説明により明らかになるであろう。なお、添付図面においては、同じ若しくは同様の構成には、同じ参照番号を付す。

添付図面は明細書に含まれ、その一部を構成し、本発明の実施の形態を示し、その記述と共に本発明の原理を説明するために用いられる。
本発明の実施形態１に係る画像処理装置の一例である複合機（ＭＦＰ）を含むシステム構成例を説明する図。 実施形態１に係るＭＦＰの構成を説明するブロック図。 本実施形態１に係るＭＦＰのソフトウェア構造の一例を示す図。 本発明の実施形態１，２に係る周期処理制御部の構成例を示すブロック図。 実施形態に係るアプリケーション管理テーブルのデータ構成例を示す図。 本実施形態１に係るＭＦＰにおけるアプリケーションによる周期処理の登録から実行までの基本的な処理の流れを説明するフローチャート。 実施形態１に係るＭＦＰの周期処理制御部の基本動作を説明するフローチャート。 Ｓ７０５の起動処理を説明するフローチャート。 図７のＳ７０４のアプリケーション管理テーブルの更新処理を説明するフローチャート。 図９のＳ９０７の基準アプリを抽出する処理を説明するフローチャート。 実施形態２に係る周期処理制御部の基本的な処理を説明するフローチャート。 Ｓ１１０７で一時保管したパケット情報の一例を示す図。 実施形態２に係るＳ１１０９及びＳ１１０４のテーブル更新処理を説明するフローチャート。 実施形態３に係るアプリケーション管理テーブルの一例を示す図。

以下、添付図面を参照して本発明の実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。

［実施形態１］
図１は、本発明の実施形態１に係る多機能処理装置の一例である複合機（ＭＦＰ）１０１，１０２を含むシステム構成例を説明する図である。

図１に示すように、本実施形態１では、ＭＦＰ１０１，１０２がＬＡＮ等のネットワーク１０４を介してサーバ（ＰＣ）１０３と互いに通信可能に接続されている。これらＭＦＰ１０１，１０２は、サーバ１０３にＭＦＰの操作画面に表示すべき画面情報を要求し、Ｗｅｂサーバ１０３は、その要求された画面情報を生成して、その要求元のＭＦＰに送信する。

図２は、実施形態１に係るＭＦＰ１０１（１０２）の構成を説明するブロック図である。尚、ＭＦＰ１０１，１０２はともに基本的な構成が同一であるため、ここではＭＦＰ１０１について説明する。

図２において、制御部２０８は、ＣＰＵ２１０，ＲＯＭ２１１及びＲＡＭ２１２を含み、ＭＦＰ１０１全体の動作を制御する。ＣＰＵ２１０は、ＲＯＭ２１１に記憶されたブートプログラムにより、ＨＤＤ２０９に記憶されている制御プログラムを読み出してＲＡＭ２１２に展開し、その展開したプログラムに従って読取制御や送信制御などの各種制御処理を実行する。尚、その制御プログラムはＲＯＭ２１１に記憶されていても良い。ＲＡＭ２１２は、ＣＰＵ２１０の主メモリ、ワークエリアとして使用される。また制御部２０８は、表示部２０２、スキャナ部２０３及びプリンタ部２０４を有する機能部２０１と接続され、それらの動作を制御する。表示部２０２には、タッチパネル機能を有する液晶等の表示部やキーボードが配置されている。また表示部２０２はブラウザ機能を備えており、ブラウザは、サーバ１０３から受信したＨＴＭＬファイルを解析し、その解析したＨＴＭＬファイルの記述に基づく操作画面を表示部２０２に表示する。プリンタ部２０４は、制御部２０８から出力された画像データに従ってシートに画像を印刷する。スキャナ部２０３は、原稿の画像を読み取って画像データを生成し、その画像データを制御部２０８に出力する。

インターフェース部２０６は、制御部２０８をネットワーク１０４に接続して外部の情報処理装置（ＰＣ：不図示）から印刷用の画像データを受信したり、表示部２０２で表示する画面データを受信する。ＨＤＤ２０９は、画像データや後述するテーブルや、各種プログラム等を記憶する。尚、外部の情報処理装置から受信した印刷用の画像データは、画像メモリ２０７に一時的に格納され、制御部２０８を介してプリンタ部２０４により印刷される。

図３は、本実施形態１に係るＭＦＰ１０１のソフトウェア構造の一例を示す図である。尚、図３に示す各ソフトウェアは、ＲＯＭ２１１或いはＨＤＤ２０９に格納され、ＣＰＵ２１０によって実行されるものとする。

ＯＳ（オペレーティングシステム）層３０１は、一般的にはリアルタイムＯＳが使用されるが、Ｌｉｎｕｘ（登録商標）等の汎用ＯＳを用いても良い。ＪａｖａＶＭ３０２は、Ｊａｖａ（登録商標）などの仮想マシンであり、アプリケーションの実行環境を提供する。アプリケーションフレームワーク３０３は、アプリケーションのライフサイクルを管理する機能を提供する。このアプリケーションフレームワーク３０３は、後述する周期処理制御部４０１（図４）を有する。インストーラサービス３０４は、後述のアプリケーションＡ，Ｂなどの複数のアプリケーションを、アプリケーションフレームワーク３０３に登録することでインストール処理を行う。アプリケーションＡ３０５，アプリケーションＢ３０６は、インストーラサービス３０４によってインストールされたアプリケーションで、ＭＦＰ１０１上で様々な機能を提供する。例えば、アプリケーションＡ３０５は、ＭＦＰ１０１からステータスを取得し、表示部２０２に、そのステータス情報を表示することができる。またアプリケーションＢ３０６は、ＭＦＰ１０１の消耗品情報を取得し、インターフェース部２０６を介して、ネットワーク１０４のＰＣなどに定期的に送信する。これらアプリケーションＡ３０５，アプリケーションＢ３０６は、ＭＦＰ１０１の外部からダウンロードしてインストールすることが可能である。Ｎａｔｉｖｅ機能３０７は、ＭＦＰ１０１に組み込まれた機能を提供する。例えば、インターフェース部２０６を介して受信した印刷データに基づいてプリンタ部２０４で印刷を行う機能がＮａｔｉｖｅ機能の一例である。尚、実施形態１では、ＪａｖａＶＭ３０２、アプリケーションフレームワーク３０３、アプリケーションＡ３０５、アプリケーションＢ３０６は、ＨＤＤ２０９に格納されているものとする。また、Ｎａｔｉｖｅ機能３０７はＲＯＭ１１０に格納されているものとする。

図４（Ａ）は、本発明の実施形態１に係るＭＦＰのアプリケーションフレームワーク３０３に設けられた周期処理制御部４０１の構成例を示すブロック図である。

周期処理制御部４０１は、周期的に動作する様々な機能の実行を制御する。周期処理制御部４０１は、開始調整部４０４、時間間隔調整部４０５、テーブル管理部４０２、アプリケーション管理テーブル４０３を有する。テーブル管理部４０２が、アプリケーション毎に周期処理の情報を管理するテーブルをＨＤＤ２０９等に作成して管理する。開始調整部４０４及び時間間隔調整部４０５は、アプリケーション管理テーブル４０３を参照し、各アプリケーションの周期処理の実行タイミングを調整し、必要に応じてアプリケーション管理テーブル４０３を修正する。また周期処理制御部４０１は、アプリケーションフレームワーク３０３の機能を利用してアプリケーションＡ３０５，アプリケーションＢ３０６と相互に通信できる。また周期処理制御部４０１は、アプリケーションＡ３０５，アプリケーションＢ３０６からコールバック関数の登録が可能であり、その登録したコールバック関数を呼び出すことも可能である。

図５（Ａ）は、実施形態１に係るアプリケーション管理テーブル４０３のデータ構成例を示す図である。ここでは１つのアプリケーションが登録されている。

アプリＩＤ５０１は、周期処理を実施するアプリケーションのＩＤである。例えば、行５１１には、アプリケーションＩＤとして「００１」が登録されている。次実行日時５０２は、そのアプリケーションが実行する周期処理の次回の実行日時を示す。例えば行５１１では、次回実行日時として「６／３０ １０：００」（６月３０日午前１０時）が登録されている。実行周期５０３は、そのアプリケーションが実行する周期処理の実行周期（秒）である。例えば、行５１１には、実行周期として「６００」秒が登録されている。要求周期５０４は、そのアプリケーションの登録時に、そのアプリケーションが要求している周期処理の実行時間間隔の要求値（要求周期）である。例えば、行５１１では、要求周期として「６００」秒が登録されている。変更可否５０５は、そのアプリケーションが実行する周期処理の実行周期及び実行日時の変更が可能かどうかを示す。例えば、行５１１では、変更可否には変更可能であることを示す「可」が登録されている。下限値５０６は、そのアプリケーションが要求する実行周期を短くできる下限値を示す。例えば、行５１１では、下限値として「６０」秒が登録されているため、その実行周期の最小値は５４０（秒）（＝６００−６０）まで変更可能となる。上限値５０７は、そのアプリケーションが要求する実行周期を長くできる上限値を示す。例えば、行５１１では、上限値として「６０」秒が登録されているため、その実行周期の最大値は６６０（秒）（＝６００＋６０）まで変更可能である。基準アプリＩＤ５０８は、そのアプリケーションが実行する周期処理の基準となるタイミングで周期処理を実行する基準アプリケーションのＩＤを登録する。例えば、行５１１では、基準アプリケーションＩＤとして「００１」、即ち、自分自身のアプリケーションＩＤが登録されている。即ち、このアプリケーションは、ＩＤが「００１」で、そのアプリケーションが実行する周期処理の実行周期の要求値は６００秒、その変更可能な範囲は５４０秒から６６０秒である。そして周期処理制御部４０１によって、そのアプリケーションの実行周期が６００秒で登録されたことを示している。

図６は、実施形態１に係るＭＦＰ１０１におけるアプリケーションによる周期処理の登録から実行までの基本的な処理の流れを説明するフローチャートである。各ステップは、ＣＰＵ２１０がＲＯＭ２１１或いはＨＤＤ２０９に記憶されるアプリケーションプログラムをＲＡＭ２１２に展開し、そのプログラムを実行すること実現される。ここでは説明を簡便にするために、アプリケーションの初期化処理、終了処理、インストール処理等に係るアプリケーション独自の処理の説明を省略し、周期処理の登録と実行の共通処理について説明する。また、ステータスの取得等の周期処理の内容の説明も省略する。ステータスの取得処理と、サーバへのアップロード処理のように、１つのアプリケーションが複数の周期処理を実施することもある。このフローチャートで示す処理は、周期処理の実行開始ごとに起動される。

まずＳ６０１で、アプリケーションは周期処理を登録する。ここでは予め定められた手順に従って周期処理制御部４０１と通信し、図５（Ａ）に示すテーブルを作成するのに必要な情報を通知し、周期処理をコールバック関数として登録する。周期処理制御部４０１が、その登録されたコールバック関数を呼び出すことで周期処理が実行される。次にＳ６０２でアプリケーションは、周期処理制御部４０１からＳ６０１で登録したコールバック関数が呼ばれるまで待機する。そしてＳ６０２でコールバック関数が呼ばれたと判定するとＳ６０３に進み、コールバック関数の処理を実施する。それ以外の場合はＳ６０２に進む。

図７は、実施形態１に係るＭＦＰ１０１の周期処理制御部４０１の基本動作を説明するフローチャートである。このフローチャートで示す処理は、ＣＰＵ２１０がＲＯＭ２１１或いはＨＤＤ２０９に記憶されるアプリケーションプログラムをＲＡＭ２１２に展開し、そのプログラムを実行すること実現される。尚、ここでは周期処理制御部４０１による処理として説明する。

先ずＳ７０１で周期処理制御部４０１は、アプリケーションの登録要求が発生したかどうかを判定する。即ち、アプリケーションがアプリケーションフレームワーク３０３の機能を利用して周期処理制御部４０１と通信し、図６のＳ６０１の登録処理を実施すると、登録要求が発生したと判定する。登録要求が発生したと判定すると周期処理制御部４０１は、Ｓ７０１でアプリケーションが通知した情報及び、コールバック関数を受け取る。こうしてＳ７０２に進み周期処理制御部４０１は、アプリケーション管理テーブル４０３を作成済みかどうかを判定する。即ち、ＨＤＤ２０９等の記憶部にアプリケーション管理テーブル４０３が作成済みかどうかを判定する。Ｓ７０２でアプリケーション管理テーブル４０３が作成済みでないと判定したときはＳ７０３に進み、周期処理制御部４０１は、新規にアプリケーション管理テーブル４０３を作成しＨＤＤ２０９に保存してＳ７０１に進む。ここでは、例えば図５（Ａ）に示すようなアプリケーション管理テーブル４０３を作成してＨＤ２０９に保存する。例えば、初期値として、アプリＩＤ５０１が「１」、基準アプリＩＤ５０８には自分自身のアプリＩＤである「１」を設定する。更に、実行周期５０３、要求周期５０４には、Ｓ７０１でアプリケーションから受け取った周期処理の要求周期（例えば、６００秒を示す６００）を設定する。更に、変更可否５０５には、変更可能を意味する「可」、次実行日時５０２には、現日時（例えば、６／３０ ９：５０）に要求周期を加算した日時（６／３０ １０：００）を設定する。更に、下限値５０６、上限値５０７には、それぞれ、Ｓ７０１でアプリケーションから受け取った周期処理の周期（時間間隔）を変更できる下限値（例えば６０秒を意味する６０）、上限値（例えば６０秒を意味する６０）を設定する。

一方、Ｓ７０２でアプリケーション管理テーブル４０３を作成済みと判定したときはＳ７０４に進み、ＨＤＤ２０９のアプリケーション管理テーブル４０３を更新してＳ７０１に進む。このアプリケーション管理テーブル４０３の更新処理の詳細は後述する。

またＳ７０１で周期処理制御部４０１は、登録要求が発生しなかったと判定した場合はＳ７０５に進んで、後述する周期処理の起動処理を実行してＳ７０１へ戻る。

図８は、Ｓ７０５の起動処理を説明するフローチャートである。

Ｓ８０１で周期処理制御部４０１は、アプリケーション管理テーブル４０３を参照して、そこに登録されている一つのアプリケーションの情報（レコード）を取得し、ＲＡＭ２１２の予め確保されたワークエリアに保存する。次にＳ８０２に進み周期処理制御部４０１は、そのアプリケーションの呼び出し時間が到着しているか否かを判定する。ここでは、アプリケーション管理テーブル４０３に登録されている、そのアプリケーションの次実行日時が現日時を過ぎているものは呼び出し時間が到着していると判定する。Ｓ８０２で、呼び出し時間が到着していないと判定するとＳ８０１に進んで次のレコードを取得するが、到着していると判定するとＳ８０３に進み、Ｓ８０１で取得した、そのアプリケーションが登録したコールバック関数を呼び出す。そしてＳ８０４に進み周期処理制御部４０１は、次実行日時を更新する。ここでは、Ｓ８０１で取得した、そのアプリケーションの次実行日時の値に、そのアプリケーションの実行周期の値を加算し、アプリケーション管理テーブル４０３の、そのアプリケーションの次実行日時５０２に保存する。こうしてＳ８０５に進み周期処理制御部４０１は、アプリケーション管理テーブル４０３の全てのアプリケーションの情報（レコード）に対して、上述の処理を完了したか否かを判定する。Ｓ８０５で全てのレコードに対する処理を完了したと判定すると、この周期処理の起動処理を終了する。またＳ８０５で全てのレコードに対する処理を完了していないと判定するとＳ８０１に進んで、前述の処理を繰り返す。

図９は、図７のＳ７０４のアプリケーション管理テーブル４０３の更新処理を説明するフローチャートである。前述のＳ７０１で登録要求が発生したと判定したときは、周期処理制御部４０１は、その登録要求の発行元であるアプリケーションから周期処理に関する情報を受け取っている。そして周期処理制御部４０１は、その受け取った情報をテーブル管理部４０２に渡している。

先ずＳ９０１でテーブル管理部４０２は、周期処理制御部４０１から受け取った次実行日時、要求周期、要求周期の変更可能な下限値、上限値、変更可否を、それぞれ、変数Next_req，T_req，min，max，modifiableに設定する。これら変数T_req（要求周期）、変数Next_req（実行日時）、変数min（下限値）、変数max（上限値）、変数modifiable（変更可否）はＲＡＭ２１２に記憶される。更に、テーブル管理部４０２は、後述する各種変数を初期化する。ここでは、ＲＡＭ２１２に予め確保した変数Ｔ_tempを「０」に、Next_temp を「1/1 00:00」に、Reference_tmpを「０」に設定する。ここでT_tempは実行周期、Next_tempは次実行日時、Reference_tmpは基準アプリケーションのＩＤを示す変数である。

次にＳ９０２に進みテーブル管理部４０２は、周期処理の実行周期を変更可能か否かを判定する。即ち、変数modifiableの値を調べ、変更可能を意味する値のときは変更可能と判定する。ここで変更不可能と判定したときはＳ９０８に進みテーブル管理部４０２は、これら変数を、Ｓ９０１で取得した要求値に変更する。即ち、変数T_tempに変数T_reqの値を、変数Next_tempにNext_reqの値を、変数Reference_tmpに自分のアプリＩＤをそれぞれ設定してＳ９１２に進む。このようにして、実行周期が変更できないアプリケーションは、そのアプリケーションが要求した実行周期に従って周期処理を実行することになる。

一方、Ｓ９０２でテーブル管理部４０２が変更可能と判定したときはＳ９０３に進み、テーブル管理部４０２は、後述するＳ９０４以降の処理がアプリケーション管理テーブル４０３の全てのレコード分終了したかを判定する。Ｓ９０３で全レコード分の処理が終了したと判定するとＳ９１０に進むが、そうでないときはＳ９０４に進みテーブル管理部４０２は、アプリケーション管理テーブル４０３からアプリケーションの情報を１レコード分取得する。更にテーブル管理部４０２は、その取得した１レコード分の情報から実行周期を変数Tに、次実行日時を変数Nextに、アプリＩＤを変数AppIDにそれぞれ設定する。これら変数T、変数Next、変数AppIDは、ＲＡＭ２１２に予め用意したワークエリアの格納領域に記憶される。

次にＳ９０５に進みテーブル管理部４０２は、登録済みアプリケーションの実行周期と、登録要求を発行したアプリケーションの要求周期との差分（同期ずれ量）を計算する。即ち、Ｓ９０４で取得した変数Tを、要求周期T_reqで除算したときの余りを求めて差分sabunに設定する。従って、この差分sabunは、mod(T,T_req)でも表される。例えば図５（Ｃ）の例では、要求周期T_reqが「１１００」で、登録済のアプリケーションの周期Tが「６００」のときは、差分sabunは「６００」になる。この変数sabunは、ＲＡＭ２１２の格納領域に保存される。次にＳ９０６に進みテーブル管理部４０２は、Ｓ９０５で求めた差分（同期ずれ量）が０かどうか判定する。これは変数sabunの値が「０」かどうか判定することに該当する。ここで変数sabunの値が「０」と判定すると、取得したレコードの実行周期が、要求周期の整数倍であることを示す。Ｓ９０６で差分が「０」でないと判定したときはＳ９０７に進み、図１０を参照して後述する基準アプリの抽出処理を実行してＳ９０３に進む。

一方、Ｓ９０６で差分が「０」であると判定したときはＳ９０９に進み、テーブル管理部４０２は、一時変数を、Ｓ９０４で取得した値に基づいて変更する。即ち、変数T_tempに要求周期T_reqの値を、変数Next_tempに変数Nextの値を、変数Reference_tmpに自分のアプリＩＤの値をそれぞれ設定してＳ９１２に進む。こうして登録要求を発行したアプリケーションの次実行日時、実行周期が、登録済のアプリケーションの次実行日時（変数Next）、実行周期（変数T）と等しくなり、その基準アプリＩＤは、その登録済のアプリケーションのアプリＩＤとなる。こうしてＳ９１２で登録された状態の一例を図５（Ｂ）に示す。尚、図５（Ｂ）では変数Tと要求周期T_reqとが一致した場合を示している。

またＳ９０３で全てのレコードに対する処理が終了したと判定したときはＳ９１０に進みテーブル管理部４０２は、一時変数を設定済みかどうか判定する。ここでは変数T_tempが「０」でないときは、一時変数が設定済みであると判定する。Ｓ９１０で一時変数が設定済みと判定した場合はＳ９１２に進むが、一時変数が設定済みでないと判定した場合はＳ９１１に進み、エラー処理を実行する。

従って、このエラー処理は、以下の２つの条件が同時に成立したときに実行される。
（１）アプリケーション管理テーブル４０３で管理されているアプリケーションに、登録要求元のアプリケーションが要求した周期処理の実行周期と一致するか、或いは整数倍の実行周期を持つアプリケーションが存在しない。
（２）登録元のアプリケーションが要求した要求周期の変更可能範囲（要求周期に上限値を加算した範囲から下限値を減算した範囲）に含まれる実行周期のアプリケーションが存在しない。

また、このエラー処理では、実行周期の変更、或いは、実行周期の変更可能範囲の変更を促すメッセージを登録元のアプリケーションに通知することも行われる。

Ｓ９１２でテーブル管理部４０２は、アプリケーション管理テーブル４０３に登録要求元のアプリケーションを追加する。即ち、アプリケーション管理テーブル４０３にエントリを１つ追加し、Ｓ９０８或いはＳ９０９で設定された各項目を含む項目を登録する。このときアプリＩＤ５０１には、そのアプリケーションを識別するＩＤを、次実行日時５０２には変数Next_tempの値を、実行周期５０３には変数 T_tempの値をそれぞれ設定する。また要求周期にはT_req の値を、変更可否５０５には変数modifiableの値を、下限値５０６には変数minの値を、上限値５０７には変数maxの値をそれぞれ設定する。更に、基準アプリＩＤには、Referecne_tempの値を設定する。

例えば、図５（Ｂ）は、既に図５（Ａ）に示すように登録されている第１アプリケーションに、アプリＩＤが「００２」の第２アプリケーションを追加した例を示す。行５１２は、この第２アプリケーションのデータを示す。ここで第２アプリケーションの要求周期が６００秒であり、第１アプリケーションの実行周期の６００秒と一致する。よって、第２アプリケーションの基準アプリＩＤ５０８は、第１アプリケーションを示す「００１」に、次実行日時５０２は、第１アプリケーションの次実行日時と同じになる。

また図５（Ｃ）は、アプリケーション管理テーブル４０３にアプリＩＤが「００３」の第３アプリケーションを追加した例を示す。行５１３は、この第３アプリケーションのデータを示す。ここで、この第３アプリケーションは、現在時刻「９：４８」に要求周期５０４を「１１００」、下限値５０６を「１００」、上限値５０７を「２００」で登録要求した結果を示す。従って、この第３アプリケーションの実行周期は、１０００秒〜１２００秒の範囲の値を取り得ることになる。従って、ここでは第１アプリケーションの実行周期（６００秒）を基準に、第３アプリケーションの実行周期は、第１アプリケーションの実行周期の倍数である「１２００」秒に調整されて登録されている。これにより、第１アプリケーション〜第３アプリケーションの周期処理が同期して実行できるため、周期処理により省電力モードから通常モードに復帰する回数を少なくできる。

図１０は、図９のＳ９０７の基準アプリを抽出する処理を説明するフローチャートである。

先ずＳ１００１でテーブル管理部４０２は、前述の差分sabunが下限値以下か判定する。即ち、変数sabunの値が変数min以内であれば、差分が下限値以下であると判定する。この場合は、要求周期からの変更可能である範囲内（下限値内）にある実行周期のアプリケーションが見つかったことになる。Ｓ１００１でテーブル管理部４０２は差分が下限値以下と判定したときはＳ１００２に進み、テーブル管理部４０２は、その差分sabunが、変数T_req（要求周期）と変数T_temp（実行周期）との差分の絶対値未満かどうかを判定する。即ち、ここでは変数sabunで示される余りが、既に計算して一時保存済のアプリケーションの実行周期の候補と要求周期との差分の絶対値と比べて小さいか判定する。ここで小さいと判定したときはＳ１００３に進み、計算した実行周期の候補が一時保存済の実行周期の候補より、より要求周期に近いとする。Ｓ１００３でテーブル管理部４０２は、実行周期の候補を更新する。即ち、テーブル管理部４０２は、変数T_req（要求周期）から変数sabunの値を減算した値を変数T_temp（実行周期）に設定してＳ１００７へ進む。一方、Ｓ１００２で、差分が変数T_tempと変数T_reqの差分の絶対値未満でないと判定したときは、この基準アプリの抽出処理を終了する。

またＳ１００１でテーブル管理部４０２が、差分sabunが下限値以下でないと判定した場合はＳ１００４に進み、変数T（実行周期）から差分sabunを引いた値が上限値以下か判定する。即ち、変数T（要求周期）と変数sabunの差分が変数max以下のときは、差分が上限値以下と判定する。ここでは前述のＳ９０４で取得した、変数Tで示される１レコードの実行周期と変数sabunとの差分が変数max以下か判定する。ここで判定が「真」のときは、要求周期からの変更可能範囲内（上限値内）に該当する実行周期が見つかったことになってＳ１００５に進む。一方、Ｓ１００４で変数Tと変数sabunの差分が変数max以下でないと判定した場合は、この基準アプリの抽出処理を終了する。

Ｓ１００５でテーブル管理部４０２は、変数Tと変数sabunとの差分が、変数T_reqと変数T_tempの差分の絶対値未満かどうかを判定する。即ち、ここでは変数T（実行周期）と、変数sabunで示される余りとの差分が、要求周期と既に計算し一時保存済の実行周期の候補との差分の絶対値と比べて小さいか判定する。ここで小さいと判定したときは、その計算した実行周期の候補が一時保存済の実行周期の候補より、より要求周期に近いことになる。こうしてＳ１００５で変数Tと変数sabunの差分が、変数T_req と変数T_tempの差分の絶対値未満と判定したときはＳ１００６に進む。Ｓ１００６でテーブル管理部４０２は、実行周期の候補を更新する。即ち、テーブル管理部４０２は、変数Tから変数sabunの値を減算し、更に、変数T_req（要求周期）に、その計算した値を加算した値を変数T_tempに設定してＳ１００７へ進む。一方、Ｓ１００５で、変数Tから変数sabunの値を減算した値が、変数T_reqと変数T_tempの差分の絶対値未満でないと判定したときは、この基準アプリの抽出処理を終了する。

Ｓ１００７でテーブル管理部４０２は、基準となるアプリケーションの候補が決まったので、そのアプリケーションの次実行日時で更新する。即ち、変数Next_tempに変数Nextの値を設定し、変数Reference_temp に変数AppIDの値を設定して、この処理を終了する。

このように実施形態１によれば、登録要求元のアプリケーションの実行周期を、その要求している要求周期の許容範囲内で一致する、或いは整数倍の実行周期の登録済のアプリケーションに合わせた実行周期で登録できる。これにより登録されているアプリケーションの間で、その実行周期を同期させることができる。よって、複数のアプリケーションが実行されているときに、それらアプリケーションの周期処理により省電力モードから復帰する回数が増えて省電力の効果が得られないといった不具合を解消できる。

実施形態１によれば、周期処理を行うアプリケーションを登録する際に、登録済みのアプリケーションの周期処理の間隔に一致、或いはその整数倍に調整する。これにより、登録済みアプリケーションと次実行日時を揃えることができ、周期処理により省電力モードから復帰する機会を少なくできる。

［実施形態２］
次に本発明に実施形態２を説明する。この実施形態２では、周期処理を実行する周期を調整して登録しないアプリケーションが存在する場合を説明する。このようなアプリケーションとしては、例えば、ＰＣからＭＦＰに定期的にステータスを取得する監視アプリ等がある。ここで説明の簡便のため、実施形態１と異なる点のみ説明する。尚、この実施形態２に係るシステムやＭＦＰの構成等は前述の実施形態１と同じであるため、それらの説明を省略する。

図４（Ｂ）は、本発明の実施形態２に係る周期処理制御部４０１の構成例を示すブロック図で、前述の図４（Ａ）と共通する部分は同じ参照番号で示している。

ここではネットワーク監視部４０６が新たに設けられている。このネットワーク監視部４０６は、インターフェース部２０６を介してネットワーク１０４から受信するパケットを監視し、周期処理を見つけたらテーブル管理部４０２にアプリケーション管理テーブル４０３への登録を依頼する。

図１１は、実施形態２に係る周期処理制御部４０１の基本的な処理を説明するフローチャートである。

図１１のＳ１１０１〜Ｓ１１０４及びＳ１１０５は、前述の実施形態１の図７のＳ７０１〜Ｓ７０４及びＳ７０５と同一であるため、その説明を省略する。

Ｓ１１０６でネットワーク監視部４０６は、パケットを受信したかを判定する。ここではアプリケーションフレームワーク３０３によって、インターフェース２０６を介しネットワーク１０４から受信したデータを調べる。ここで所定のフォーマットのパケットを受信したときはパケットを受信したと判定する。ここでパケットを受信していないと判定したときはＳ１１０１へ進む。Ｓ１１０６でパケットを受信したと判定するとＳ１１０７に進み、ネットワーク監視部４０６は、Ｓ１１０６で受信したパケットの情報をＲＡＭ２１２に一時保管する。

図１２は、Ｓ１１０７で一時保管したパケット情報の一例を示す図である。

このパケット情報は、ＲＡＭ２１２に予め用意されているワーク領域に適宜保管されている。各レコードは、Ｆｒｏｍ１２０１、処理内容１２０２、プロトコル１２０３、前回実行日時１２０４、平均時間間隔１２０５、回数１２０６を含む。Ｆｒｏｍ１２０１は、パケットの送信元を示し、処理内容１２０２は周期処理の内容を示す。プロトコル１２０３は、パケットの送信プロトコル、前回実行日時１２０４は前回の受信日時、平均時間間隔１２０５はパケット受信時間間隔の平均値、回数１２０６は受信回数を示す。例えば、行１２１１には、ＩＰアドレス「１７２．１０．１０．１０」からＳＮＮＰプロトコルでステータス取得のパケットを合計１０回受信し、その平均時間間隔が６００秒、前回の受信日時が「６／３０ １０：０５：１１」が登録されている。

Ｓ１１０６で受信したパケットと、Ｆｒｏｍ、処理、プロトコルが同一であるエントリがあれば、そのレコードの「回数」に１を加算し、前回実行日時、平均時間間隔を設定する。一方、同一のエントリがない場合は、行を新規に追加して各項目を設定する。

次Ｓ１１０８で、Ｓ１１０７で一時保存したパケット情報が周期処理かどうかを判定する。即ち、一時保存したパケット情報の回数１２０６の値が、所定の回数を超えている場合は周期処理であると判定する。例えば、１０回超えた場合は周期処理と判定する。Ｓ１１０８で周期処理と判定しなかった場合はＳ１１０１へ進むが、周期処理と判定した場合はＳ１１０９に進んで、ネットワーク監視部４０６はアプリケーション管理テーブル４０３を更新してＳ１１０１に進む。

図１３は、実施形態２に係るＳ１１０９及びＳ１１０４のテーブル更新処理を説明するフローチャートである。尚、図１３のＳ１３０２〜Ｓ１３１３の処理は、実施形態１に係る図９のＳ９０１〜Ｓ９１２と同じであるため、その説明を省略する。尚、アプリケーション管理テーブル４０３への登録に必要な情報は、ネットワーク監視部４０６からテーブル管理部４０２へ渡されているものとする。

先ずＳ１３０１でテーブル管理部４０２は、外部アプリの登録要求かどうかを判定する。ここでは、テーブル更新処理を呼び出すトリガが、アプリケーションからの登録要求か、ネットワーク監視部４０６からの更新依頼であるかを判定する。ネットワーク監視部４０６からの更新依頼の場合は、外部アプリの登録要求と判定する。Ｓ１３０１で外部アプリの登録要求でないと判定するとＳ１３０２へ進み、図９を参照して説明した処理を実行する。

Ｓ１３０１で外部アプリの登録要求と判定したときはＳ１３１４に進みテーブル管理部４０２は、外部アプリをアプリケーション管理テーブル４０３に登録する。

図５（Ｄ）は、外部アプリを登録したアプリケーション管理テーブル４０３のデータを示す図である。行５１４は、外部アプリを登録した状態を示している。ここでは、変更可否５０５には変更不可能を示す「否」、下限値５０６には「０」、上限値５０７には「０」が設定され、基準アプリＩＤ５０８は、自分のアプリＩＤである「００４」が設定されている。

次にＳ１３１５に進みテーブル管理部４０２は、後述のＳ１３１６以降の処理をアプリケーション管理テーブル４０３の全レコードに対して終了したかを判定する。Ｓ１３１５で全てのレコードに対する処理が完了したと判定したときは、このテーブル更新処理を終了する。Ｓ１３１５で全てのレコードに対する処理が完了していないと判定した場合はＳ１３１６に進みテーブル管理部４０２は、アプリケーション管理テーブル４０３から登録済のアプリケーションの１レコード分の情報を取得する。更に、テーブル管理部４０２は、その取得した１レコードの情報をＲＡＭ２１２に格納する。次にＳ１３１７に進みテーブル管理部４０２は、Ｓ１３１６で取得した１レコードのデータを調べて、実行周期を変更可能かどうか判定する。Ｓ１３１７で変更可能でないと判定したときはＳ１３１５へ進む。Ｓ１３１７で変更可能と判定したときはＳ１３１８に進みテーブル管理部４０２は、基準アプリが外部アプリかどうか判定する。Ｓ１３１８で基準アプリが外部アプリであると判定したときはＳ１３１５に進むが、基準アプリが外部アプリでないときはＳ１３１９に進む。Ｓ１３１９でテーブル管理部４０２は、Ｓ１３１６で取得したレコードの値を変更し、その変更した値でアプリケーション管理テーブル４０３を更新する。即ち、基準アプリＩＤを、Ｓ１３１４で登録した外部アプリを示すＩＤに設定し、実行周期を計算して設定する。

図５（Ｄ）の行５１１〜５１３は、こうして変更された例を示す。ここでは基準アプリＩＤ５０８が外部アプリを示すＩＤ「００４」に変更され、実行周期５０３が外部アプリの実行周期（５９０秒）と同じ、或いは整数倍（１１８０秒）に再設定されている。

以上説明したように実施形態２によれば、周期処理の間隔を変更できないアプリケーションが存在する場合、そのアプリケーションの周期処理の実行周期に他のアプリケーションの周期処理を揃えることができる。

［実施形態３］
次に本発明の実施形態３を説明する。一般にネットワークの過負荷を避けるため、情報処理装置、ＭＦＰの稼働負荷を下げるために、処理は分散して実施することが行われている。実施形態３では、周期処理のタイミングを揃えることで省電力を実現しているが、ネットワーク負荷、装置の稼働負荷を上げてしまう一因になり得る。そこで省電力を実現しつつ、ネットワークの負荷を軽減する例を説明する。尚、この実施形態３に係るシステムやＭＦＰの構成等は前述の実施形態１と同じであるため、それらの説明を省略する。

図１４は、実施形態３に係るアプリケーション管理テーブル４０３の一例を示す図である。前述の図５と共通する部分は同じ符号で示している。

このアプリケーション管理テーブル４０３では、各周期処理に対応付けて遅延時間１４０１が追加されている。遅延時間１４０１は、アプリケーション管理テーブル４０３に設定済みの次実行日時から周期処理を実施するまでの遅延時間を示す。

この遅延時間は、Ｓ７０３のアプリケーション管理テーブル４０３の新規作成時、Ｓ７０４のアプリケーション管理テーブル４０３の更新時に自動的にランダムな値が設定される。この遅延時間が取りうる範囲は、例えば実行周期の１０％以内とし、起動状態のＭＦＰが一定時間無稼働状態となったときにスリープ状態に移行する基準となる連続無稼働時間を上回らないものとする。

図１４の行１４１１では、遅延時間１４０１が「０」に設定されているので、Ｓ７０５の起動処理で周期処理制御部４０１からアプリケーションに対して遅延なく起動が指示される。一方、行１４１２では、遅延時間１４０１が１０秒に設定されているので、次実行日時５０２の時間から１０秒後に、その周期処理が起動されることになる。

以上説明したように実施形態３によれば、同一周期の複数の周期処理をずらして実施することができる。これにより、周期処理がネットワークへの通信を伴う場合でもネットワークの負荷を分散でき、ネットワーク負荷のピーク値を下げることができる。

また、周期処理を実施するＣＰＵの負荷を分散でき、負荷のピーク値を下げることができる。これによりＭＦＰの電力消費を低減することが可能となる。

（その他の実施形態）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

本発明は上記実施の形態に制限されるものではなく、本発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、本発明の範囲を公にするために、以下の請求項を添付する。

１０１，１０２…ＭＦＰ、２０９…ＨＤＤ、２１９…ＲＡＭ、４０４…開始調整部、４０５…時間間隔調整部、４０２…テーブル管理部、４０３…アプリケーション管理テーブル、４０６…ネットワーク監視部

Claims (10)

1. 周期的に実行される周期処理を登録できる多機能処理装置であって、
   アプリケーションで実行される周期処理の実行日時と実行周期を登録する登録手段と、
   前記登録手段に第１のアプリケーションが登録されているときに、第２のアプリケーションを前記登録手段に登録する際、前記第１のアプリケーションの第１の周期処理の実行周期に合わせて前記第２のアプリケーションの第２の周期処理の実行周期を調整する調整手段と、
   前記調整手段によって調整した前記第２の周期処理の実行周期を前記登録手段に登録し、前記登録手段に登録された実行周期に従って、各アプリケーションの周期処理を実行する制御手段と、
   を有することを特徴とする多機能処理装置。
2. 前記調整手段は、前記第２のアプリケーションの第２の周期処理が要求する実行周期の上限値、或いは下限値の範囲内で前記第２の周期処理を調整することを特徴とする請求項１に記載の多機能処理装置。
3. 前記調整手段は、前記第１のアプリケーションの第１の周期処理の実行周期の整数倍の周期が、前記第２のアプリケーションの第２の周期処理が要求する実行周期の上限値、或いは下限値の範囲内にあるときは、前記第２のアプリケーションの第２の周期処理の実行周期を前記第１のアプリケーションの第１の周期処理の実行周期の整数倍の周期とするように調整することを特徴とする請求項２に記載の多機能処理装置。
4. 前記登録手段に登録されている前記第１のアプリケーションと第２のアプリケーションの実行日時を調整する開始調整手段を更に有することを特徴とする請求項１乃至３のいずれか１項に記載の多機能処理装置。
5. 前記登録手段は更に、前記周期処理を実行するアプリケーションのＩＤ、前記周期処理が要求する実行周期を変更可能か否か、前記周期処理の実行周期の基準となるアプリケーションのＩＤを含むことを特徴とする請求項１乃至４のいずれか１項に記載の多機能処理装置。
6. 前記調整手段は、前記第２のアプリケーションの周期処理が要求する実行周期が変更可能でない場合、前記第１のアプリケーションの周期処理の実行周期を、前記第２のアプリケーションの周期処理が要求する実行周期に合わせて調整することを特徴とする請求項５に記載の多機能処理装置。
7. 前記第２のアプリケーションの周期処理は、ネットワークを介したパケットの受信により起動されることを特徴とする請求項６に記載の多機能処理装置。
8. 前記登録手段は、更に各アプリケーションの周期処理を開始を遅延させる遅延時間を、各周期処理に対応付けて登録することを特徴とする請求項１乃至７のいずれか１項に記載の多機能処理装置。
9. 周期的に実行される周期処理を登録できる多機能処理装置を制御する制御方法であって、
   アプリケーションで実行される周期処理の実行日時と実行周期を登録する登録工程と、
   前記登録工程で第１のアプリケーションが登録されているときに、第２のアプリケーションを前記登録工程で登録する際、前記第１のアプリケーションの第１の周期処理の実行周期に合わせて前記第２のアプリケーションの第２の周期処理の実行周期を調整する調整工程と、
   前記調整工程で調整した前記第２の周期処理の実行周期を前記登録工程で登録し、前記登録工程で登録された実行周期に従って、各アプリケーションの周期処理を実行する制御工程と、
   を有することを特徴とする多機能処理装置の制御方法。
10. コンピュータを、請求項１乃至８のいずれか１項に記載の多機能処理装置として起動するためのプログラム。

Images