(57)【要約】【課題】データ処理装置におけるプログラムの更新を実行するに当たって、ユーザの業務に与える支障を軽減することができるデータ処理装置、データ処理システム及びその方法、並びにプログラムを提供する。【解決手段】サーバ２０１は、サーバ２０１自身及びクライアント２０２〜２０４が保持している数週間の曜日毎及び時間毎のジョブ数を示すデータを取得する。スケジューリングを行う装置において、取得した数週間の曜日毎及び時間毎のジョブ数を示すデータから曜日毎のジョブ数の総和を計算し、曜日毎のジョブ数の総和の少ない順に順番を決定する。ジョブ総数の少ない曜日から順に空き時間の多い時間帯を検索する。空き時間の多い時間帯を検索する曜日において、３時間連続でジョブ数が０の時間帯があるか否かを判別する。３時間連続でジョブ数が０の時間帯があるときは、その真ん中の時間帯をファームウェア更新の時間帯としてスケジューリングし、ファームウェア更新を登録する。【選択図】図２
2008152482.tif 000002
【特許請求の範囲】
【請求項１】
データ処理装置であって、
ジョブを実行する少なくとも１つのデータ処理装置によって特定の時間ごとに実行されたジョブの数を示すジョブ数データを前記少なくとも１つのデータ処理装置から取得する取得手段と、
前記取得手段により取得したジョブ数データに基づいて、前記少なくとも１つのデータ処理装置におけるプログラムの更新のスケジュールを決定するスケジューリング手段とを備えることを特徴とするデータ処理装置。
【請求項２】
前記スケジューリング手段は、前記取得手段により取得したジョブ数データに基づいて、前記少なくとも１つのデータ処理装置におけるジョブの実行が少ない時間またはジョブの実行がない時間を検出し、検出した時間に基づいて前記スケジュールを決定することを特徴とする請求項１記載のデータ処理装置。
【請求項３】
前記取得手段は、複数のデータ処理装置のそれぞれから前記ジョブ数データを取得し、
前記スケジューリング手段は、前記複数のデータ処理装置が同一の時間にプログラムの更新を行わないように、前記取得手段により前記複数のデータ処理装置から取得される前記ジョブ数データに基づいて、前記複数のデータ処理装置の各々におけるプログラムの更新のスケジュールを決定することを特徴とする請求項２記載のデータ処理装置。
【請求項４】
第１のデータ処理装置と第２のデータ処理装置とを有するデータ処理システムであって、
前記第１のデータ処理装置は、
前記第２のデータ処理装置によって特定の時間ごとに実行されたジョブの数を示すジョブ数データを前記第２のデータ処理装置から取得する取得手段と、
前記取得手段により取得したジョブ数データに基づいて、前記第２のデータ処理装置におけるプログラムの更新のスケジュールを決定するスケジューリング手段と、
前記スケジューリング手段により決定されたスケジュールに従って、前記第２のデータ処理装置にプログラムの更新に必要なデータを送信する送信手段とを備え、
前記第２のデータ処理装置は、
前記ジョブ数データを記憶する記憶手段と、
プログラムの更新に必要なデータを前記第１のデータ処理装置から受信する受信手段と、
前記ジョブを実行中でないときに前記受信手段により受信したデータに基づいてプログラムの更新を行う更新手段と、
プログラムの更新が終了した場合に、プログラムの更新が終了したことを前記第１のデータ処理装置に通知する通知手段とを備えることを特徴とするデータ処理システム。
【請求項５】
前記更新手段は、ジョブを実行中であった場合、前記実行中のジョブが終了してからプログラムの更新を行うことを特徴とする請求項４記載のデータ処理システム。
【請求項６】
前記更新手段は、ジョブを実行中であった場合、前記第１のデータ処理装置に対してプログラムの更新の再スケジューリングを依頼することを特徴とする請求項４記載のデータ処理システム。
【請求項７】
前記第２のデータ処理装置は、前記スケジューリング手段により決定されたスケジュールに従って、省電力状態から復帰する復帰手段を備えることを特徴とする請求項４乃至６のいずれか１項に記載のデータ処理システム。
【請求項８】
前記第１のデータ処理装置は、前記スケジューリング手段により決定されたスケジュールに従って、省電力状態から復帰する第２の復帰手段を備えることを特徴とする請求項４乃至７のいずれか１項に記載のデータ処理システム。
【請求項９】
ジョブを実行する少なくとも１つのデータ処理装置のプログラムを更新するためのデータ処理方法において、
前記少なくとも１つのデータ処理装置によって特定の時間毎に実行されたジョブの数を示すジョブ数データを前記少なくとも１つのデータ処理装置から取得する取得ステップと、
前記取得ステップで取得したジョブ数データに基づいて、前記少なくとも１つのデータ処理装置におけるプログラムの更新のスケジュールを決定するスケジューリングステップとを備えることを特徴とするデータ処理方法。
【請求項１０】
ジョブを実行する少なくとも１つのデータ処理装置のプログラムを更新するためのコンピュータにより読み取り可能なプログラムにおいて、
前記少なくとも１つのデータ処理装置によって特定の時間毎に実行されたジョブの数を示すジョブ数データを前記少なくとも１つのデータ処理装置から取得する取得モジュールと、
前記取得ステップで取得したジョブ数データに基づいて、前記少なくとも１つのデータ処理装置におけるプログラムの更新のスケジュールを決定するスケジューリングモジュールとを備えることを特徴とするコンピュータ読み取り可能なプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理装置、データ処理システム及びその方法、並びにプログラムに関し、特に、プログラムの更新のスケジュールを決定するデータ処理装置、データ処理システム及びその方法、並びにプログラムに関する。
【背景技術】
【０００２】
従来より、遠隔地にあるサーバが、ネットワーク上に存在するデータ処理装置に組み込まれたファームウェアを更新する技術が知られている（例えば、特許文献１参照）。この技術では、サーバが、設備情報と、ファームウェアのバージョン情報とを管理する。また、サーバは、設備情報及びファームウェアのリリース日時等の情報に基づいて、自動的にファームウェア更新対象となるデータ処理装置を選び出す。サーバは、この更新対象となるデータ処理装置に対してファームウェアと、更新手順を示したシナリオとを伝送する。データ処理装置は、伝送されたシナリオに基づいてファームウェアの更新を行う。
【特許文献１】特開平０７−２４８９１３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、上記特許文献１に記載されたファームウェアの更新技術では、同じ機種の同じバージョンのデータ処理装置が複数台存在した場合、複数台のデータ処理装置において一斉にファームウェアの更新が実行されてしまう。そのため、ファームウェアの更新を実行する間、複数台のデータ処理装置が一斉に使用できなくなるので、ユーザの業務に大いに支障を発生させる。ユーザの業務に与える支障を軽減するに当たっては、データ処理装置でのジョブの実行状況を考慮するのが望ましい。
【０００４】
本発明の目的は、データ処理装置におけるプログラムの更新を実行するに当たって、ユーザの業務に与える支障を軽減することができるデータ処理装置、データ処理システム及びその方法、並びにプログラムを提供することにある。
【課題を解決するための手段】
【０００５】
上述の目的を達成するために、請求項１記載のデータ処理装置は、データ処理装置であって、ジョブを実行する少なくとも１つのデータ処理装置によって特定の時間ごとに実行されたジョブの数を示すジョブ数データを前記少なくとも１つのデータ処理装置から取得する取得手段と、前記取得手段により取得したジョブ数データに基づいて、前記少なくとも１つのデータ処理装置におけるプログラムの更新のスケジュールを決定するスケジューリング手段とを備えることを特徴とする。
【０００６】
上述の目的を達成するために、請求項４記載のデータ処理システムは、第１のデータ処理装置と第２のデータ処理装置とを有するデータ処理システムであって、前記第１のデータ処理装置は、前記第２のデータ処理装置によって特定の時間ごとに実行されたジョブの数を示すジョブ数データを前記第２のデータ処理装置から取得する取得手段と、前記取得手段により取得したジョブ数データに基づいて、前記第２のデータ処理装置におけるプログラムの更新のスケジュールを決定するスケジューリング手段と、前記スケジューリング手段により決定されたスケジュールに従って、前記第２のデータ処理装置にプログラムの更新に必要なデータを送信する送信手段とを備え、前記第２のデータ処理装置は、前記ジョブ数データを記憶する記憶手段と、プログラムの更新に必要なデータを前記第１のデータ処理装置から受信する受信手段と、前記ジョブを実行中でないときに前記受信手段により受信したデータに基づいてプログラムの更新を行う更新手段と、プログラムの更新が終了した場合に、プログラムの更新が終了したことを前記第１のデータ処理装置に通知する通知手段とを備えることを特徴とする。
【０００７】
上述の目的を達成するために、請求項９記載のデータ処理方法は、ジョブを実行する少なくとも１つのデータ処理装置のプログラムを更新するためのデータ処理方法において、前記少なくとも１つのデータ処理装置によって特定の時間毎に実行されたジョブの数を示すジョブ数データを前記少なくとも１つのデータ処理装置から取得する取得ステップと、前記取得ステップで取得したジョブ数データに基づいて、前記少なくとも１つのデータ処理装置におけるプログラムの更新のスケジュールを決定するスケジューリングステップとを備えることを特徴とする。
【０００８】
上述の目的を達成するために、請求項１０記載のコンピュータ読み取り可能なプログラムは、ジョブを実行する少なくとも１つのデータ処理装置のプログラムを更新するためのコンピュータにより読み取り可能なプログラムにおいて、前記少なくとも１つのデータ処理装置によって特定の時間毎に実行されたジョブの数を示すジョブ数データを前記少なくとも１つのデータ処理装置から取得する取得モジュールと、前記取得ステップで取得したジョブ数データに基づいて、前記少なくとも１つのデータ処理装置におけるプログラムの更新のスケジュールを決定するスケジューリングモジュールとを備えることを特徴とする。
【発明の効果】
【０００９】
本発明によれば、データ処理装置でのジョブの実行状況に基づいて、データ処理装置におけるプログラムの更新のスケジュールを決定する。これにより、データ処理装置におけるプログラムの更新を実行するに当たって、ユーザの業務に与える支障を軽減することができる。
【００１０】
また、複数のデータ処理装置が同一の時間にプログラムの更新を行わないように、ジョブの実行が少ない又はジョブの実行がない時間に複数のデータ処理装置の各々におけるプログラムの更新のスケジュールを決定する。これにより、プログラムの更新を実行する間、複数台のデータ処理装置が一斉に使用できなくなるのを防止することができる。
【発明を実施するための最良の形態】
【００１１】
以下、図面を参照しながら本発明の実施の形態を詳細に説明する。
【００１２】
［第１の実施の形態］
図１は、第１の実施の形態に係るデータ処理装置の内部構成を示すブロック図である。
【００１３】
図１において、画像処理装置１００（データ処理装置）は、ＣＰＵ（中央演算装置）１０１、フラッシュＲＯＭ１０２、ＲＡＭ（ランダムアクセスメモリ）１０３、外部記憶装置１０４、表示部１０５、及び操作部１０６を備える。また、画像処理装置１００は、エンジンＩ／Ｆ（インターフェース）１０７、ＵＳＢデバイスＩ／Ｆ１１０、セントロＩ／Ｆ１１１、ネットワークＩ／Ｆ１１２、及びFAX Unit１１３、ＲＴＣ（Real Time Clock）１１４を備える。これらは、システムバス１１５を介して互いに接続されている。また、画像処理装置１００は、スキャナエンジン１０８、及びプリンタエンジン１０９を備え、これらはエンジンＩ／Ｆ１０７に接続されている。
【００１４】
ＣＰＵ１０１は、画像処理装置１００全体の制御及び演算処理等を行う。フラッシュＲＯＭ１０２は、読み出し専用メモリであり、システム起動プログラムやプリンタエンジンの制御を行うプログラムや、文字データ、文字コード情報等の記憶領域である。フラッシュＲＯＭ１０２は、通常時はＲＯＭとして動作するが、プログラムにより電気的に内部のデータの消去及び書き込みが可能である。
【００１５】
ＲＡＭ１０３は、使用制限のないデータ記憶領域であり、ＰＤＬデータの展開領域として使用したり、ＰＤＬデータからＤＬデータへの変換、ＤＬデータからビットマップデータへの変換など様々な処理毎にプログラムやデータがロードされ実行される。また、ＲＡＭ１０３は、時間毎、曜日毎に実行されるジョブ数を記録するデータ領域として使用される。
【００１６】
外部記憶装置１０４は、例えばハードディスク等により構成され、画像処理装置１００が受け付けた印刷ジョブをスプールしたり、印刷ジョブに係る印刷データ等を格納したり、作業用領域として利用されたりする。また、外部記憶装置１０４は、前述したＲＡＭ１０３上に展開されている時間毎、曜日毎に実行されるジョブ数を記録するデータをファイルとして保持し、同様に数週間分のデータをファイルとして保持する。
【００１７】
表示部１０５は、液晶等により構成され、表示画像を展開するＶＲＡＭを有する。表示部１０５は、画像処理装置１００の設定状態や、現在の画像処理装置１００内部の処理状態、エラー状態、ファームウェアの更新に関する予告の表示を行う。操作部１０６は、ハードキーによる操作部と、表示部１０５の表面に装着されているタッチパネルとを有する。操作部１０６は、画像処理装置１００の設定の変更を行う。
【００１８】
エンジンＩ／Ｆ１０７は、スキャナエンジン１０８及びプリンタエンジン１０９を制御するコマンドやデータ等のやり取りを行う。ＵＳＢデバイスＩ／Ｆ１１０は、外部ホストと接続する際に使用するＩ／Ｆであり、ＰＤＬデータの受信などに使用される。
【００１９】
セントロＩ／Ｆ１１１は、外部ホストと接続する際に使用するＩ／Ｆである。ネットワークＩ／Ｆ１１２は、外部ホスト、外部サーバ、又はインターネットと接続するために使用される。また、ネットワークＩ／Ｆ１１２は、外部ホストからのＰＤＬデータの受信等にも使用されると同時に、ファームウェアの送受信にも使用される。FAX Unit１１３は、ＦＡＸ送信、ＦＡＸ受信を行う際に使用する。
【００２０】
ＲＴＣ１１４は、内部に電池と時計機能を有しており、システムのＯＳが起動するに必要な時間機能を提供する。また、ＲＴＣ１１４は、タイマ、アラーム機能を有し、指定時間になれば割り込みを上げる。例えば、ＲＴＣ１１４は、低電力状態にあるシステムを起動するトリガーを発生させることができる。
【００２１】
図２及び図３は、図１の画像処理装置１００で実行されるプログラムの更新のスケジューリングを説明する図である。以下では、プログラムの一例としてファームウェアを挙げるが、他の例としてソフトウェアであっても良い。
【００２２】
図２において、サーバ２０１は、複数台ある画像処理装置１００の中の任意の１台であり、ここでは、サーバとしての役割を果たす。サーバ２０１は、今週のデータ２０５、先週のデータ２０６のように、数週間の曜日毎及び時間毎のジョブ数を示すデータを保持している。これらのデータは、特定の時間ごとに実行されたジョブ数を示すデータであれば、１週間毎のジョブ数を示すデータ、１日ごとのジョブ数を示すデータ、１０分ごとのジョブ数を示すデータであっても良い。
【００２３】
クライアント２０２〜２０３のそれぞれは、複数台ある画像処理装置１００の中の１台であり、クライアントとして動作する。クライアント２０２は、今週のデータ２０７、先週のデータ２０８のように、数週間の曜日毎及び時間毎のジョブ数を示すデータを保持している。クライアント２０３は、今週のデータ２０９、先週のデータ２１０のように、数週間の曜日毎及び時間毎のジョブ数を示すデータを保持している。
【００２４】
サーバ２０１、及びクライアント２０２〜２０３は、ネットワーク２１１を介して互いに接続されている。
【００２５】
図３において、クライアント２０４は、複数台ある画像処理装置１００の中の１台であり、クライアントとして動作する。クライアント２０４も、図２で説明した今週のデータや先週のデータのように、数週間の曜日毎及び時間毎のジョブ数を示すデータを保持している。
【００２６】
数週間分のジョブ総数は、サーバ及びクライアントのそれぞれが持つ数週間分のジョブ数の総和を示す。ファームウェア更新の優先順位は、数週間分のジョブ総数に基づいて決定され、ファームウェア更新のスケジューリングを行う上での優先順位を示す。
【００２７】
図４及び図５は、図３のサーバ２０１で実行されるファームウェア更新のスケジューリング処理のフローチャートである。サーバ２０１のＣＰＵ１０１が、図４及ぶ図５のフローチャートに基づくプログラムを実行することにより、このスケジューリング処理が行われる。
【００２８】
図４において、サーバ２０１は、サーバ２０１自身及びクライアント２０２〜２０４が保持している、数週間の曜日毎及び時間毎のジョブ数を示すデータを取得する（ステップＳ４０１）。次に、装置ごとに数週間分のジョブ総数を計算し、数週間分のジョブ総数が多いものから順にファームウェア更新の優先順位を決定する（ステップＳ４０２）。図３は、決定された優先順位の一例を示す。数週間分のジョブ総数が多い装置ほどユーザの使用頻度が高く、このような装置ではジョブを実行していない空き時間が少ないと考えられる。そのため、数週間分のジョブ総数の多い装置に対して優先的にファームウェア更新のスケジューリングを行う。
【００２９】
次に、数週間分のジョブ総数の最も多い装置（つまり、ファームウェア更新の優先順位の最も高い装置）から順にファームウェア更新のスケジューリングを行う。まず、スケジューリングの対象となる装置に関して、図６に示すように、取得した数週間の曜日毎及び時間毎のジョブ数を示すデータから曜日毎のジョブ数の総和を計算し、曜日毎のジョブ数の総和が小さい順に順番を決定する（ステップＳ４０３）。これは、ジョブ数の総和が小さい曜日ほど空き時間が多い可能性が高いためである。図６では、土曜日が最もジョブ数の総和が小さいので、順番が１となる。
【００３０】
ステップＳ４０３の計算の結果、ジョブ総数の少ない曜日から順に空き時間の多い時間帯を検索する。空き時間の多い時間帯を検索する曜日において、３時間連続でジョブ数が０の時間帯があるか否かを判別する（ステップＳ４０４）。３時間連続でジョブ数が０の時間帯は、図６の実線楕円で囲んだ部分である。
【００３１】
ステップＳ４０４の判別の結果、３時間連続でジョブ数が０の時間帯があるときは、その真ん中の時間をファームウェア更新の時間として決定し、ファームウェア更新が行われるべき曜日及び時間を登録する（ステップＳ４０６）。具体的には、図６の時間帯５０１のうち、３時をファームウェア更新の時間とし、スケジュール表における土曜日の２時（図７の６０１）に装置の名前（Ｃｌｉｅｎｔ  Ｂ）を登録する。図７は、サーバ２０１が管理するスケジュール表の一例である。図７のスケジュール表において、Ｘ時とはＸ時０分からＸ時５９分までの時間を示す。なお、３時間連続でジョブ数が０の時間帯が複数存在するときは、その前後の時間のジョブ数を含むジョブ総数（それぞれの時間におけるジョブ数がｍ，０，０，０，ｎとするとｍ＋ｎ）が最小となる時間帯の真ん中の時間を選択する。
【００３２】
次に、複数台の装置のスケジュールを組む場合、ファームウェア更新のスケジューリングを行っていない装置があるか否かを判別する（ステップＳ４１４）。この判別の結果、ファームウェア更新のスケジューリングを行っていない装置があるときは、ステップＳ４０３に戻る。一方、ファームウェア更新のスケジューリングを行っていない装置がないときは、本処理を終了する。
【００３３】
ステップＳ４０４の判別の結果、３時間連続でジョブ数が０の時間帯がないときは、３時間連続でジョブ数が０の時間帯を検索していない曜日があるか否かを判別する（ステップＳ４０５）。この判別の結果、３時間連続でジョブ数が０の時間帯を検索していない曜日があるときは、ステップＳ４０４に戻り、次の曜日について３時間連続でジョブ数が０の時間帯を検索する。一方、３時間連続でジョブ数が０の時間帯を検索していない曜日がないときは、ステップＳ４０７に進む。
【００３４】
ステップＳ４０７では、ジョブ総数の少ない曜日から順に、２時間連続でジョブ数が０の時間帯があるか否かを判別する。２時間連続でジョブ数が０の時間帯は、図６の点線楕円で囲んだ部分である。
【００３５】
ステップＳ４０７の判別の結果、２時間連続でジョブ数が０の時間帯があるときは、そのいずれかの時間をファームウェア更新の時間として決定し、ファームウェア更新が行われるべき曜日及び時間を登録し（ステップＳ４０９）、ステップＳ４１４に進む。具体的には、図６に示す時間帯５０２のうち、６時をファームウェア更新の時間とし、スケジュール表における土曜日の６時に装置の名前を登録する。なお、２時間連続でジョブ数が０の時間帯が複数存在するときは、その前後の時間のジョブ数を含むジョブ総数（それぞれの時間におけるジョブ数がｍ，０，０，ｎとするとｍ＋ｎ）が最小となる時間帯のいずれかの時間を選択する。例えば、ｍ＞ｎであれば、ｎに近い方の時間をファームウェア更新の時間とし、ｍ＜＝ｎであれば、ｍに近い方の時間をファームウェア更新の時間として決定する。なお、実施の形態の場合、同じ時間帯に他の装置のスケジュールが入っていてもよいものとする。
【００３６】
ステップＳ４０７の判別の結果、２時間連続でジョブ数が０の時間帯がないときは、２時間連続でジョブ数が０の時間帯を検索していない曜日があるか否かを判別する（ステップＳ４０８）。この判別の結果、２時間連続でジョブ数が０の時間帯を検索していない曜日があるときは、ステップＳ４０７に戻り、次の曜日について２時間連続でジョブ数が０の時間帯を検索する。一方、２時間連続でジョブ数が０の時間帯を検索していない曜日がないときは、ステップＳ４１０に進む。
【００３７】
ステップＳ４１０では、ジョブ総数の少ない曜日から順に、１時間ジョブ数が０の時間があるか否かを判別する。１時間ジョブ数が０の時間は、図６の一点鎖線楕円で囲んだ部分である。
【００３８】
ステップＳ４１０の判別の結果、１時間ジョブ数が０の時間があるときは、その時間をファームウェア更新の時間として決定し、ファームウェア更新が行われるべき曜日及び時間を登録する（ステップＳ４１２）。具体的には、図６に示す時間帯５０３のうち、２２時をファームウェア更新の時間とし、スケジュール表における土曜日の２２時に装置の名前を登録する。なお、１時間ジョブ数が０の時間が複数存在するときは、その前後の時間のジョブ数を含むジョブ総数（それぞれの時間におけるジョブ数がｍ，０，ｎとするとｍ＋ｎ）が最小となる時間を選択する。なお、実施の形態の場合、同じ時間帯に他の装置のスケジュールが入っていてもよいものとする。
【００３９】
ステップＳ４１０の判別の結果、１時間ジョブ数が０の時間がないときは、１時間ジョブ数が０の時間を検索していない曜日があるか否かを判別する（ステップＳ４１１）。この判別の結果、１時間ジョブ数が０の時間を検索していない曜日があるときは、ステップＳ４１０に戻り、次の曜日について１時間ジョブ数が０の時間を検索する。一方、１時間ジョブ数が０の時間を検索していない曜日がないときは、ステップＳ４１３に進む。
【００４０】
ステップＳ４１３では、ジョブ総数の最も少ない曜日において、ジョブ数が最も少ない時間をファームウェア更新の時間として決定し、ファームウェア更新が行われるべき曜日及び時間を登録する。なお、最も少ないジョブ数をＸとし、ジョブ数がＸの時間が複数存在するときは、その前後の時間のジョブ数を含むジョブ総数（それぞれの時間におけるジョブ数がｍ，Ｘ，ｎとするとｍ＋ｎ）が最小となる時間を選択する。
【００４１】
図４及び図５のスケジューリング処理を実行すると、図８に示すように、複数台の画像処理装置のそれぞれにおけるファームウェア更新のスケジュールが決定される。なお、本実施の形態では、同じ時間に他の装置のスケジュールが入っていてもよいものとする。ただし、サーバ２０１のファームウェア更新のスケジュールだけは、クライアント２０２〜２０４のスケジュールと同じ時間にならないようにする必要がある。
【００４２】
図４及び図５の処理によれば、ユーザの使用頻度の低い時間帯をファームウェアの更新時間として決定するので、データ処理装置におけるプログラムの更新を実行するに当たって、ユーザの業務に与える支障を軽減することができる。
【００４３】
次に、図８のファームウェア更新のスケジュール表に基づいて、サーバ２０１及びクライアント２０２〜２０４のファームウェアを更新する処理を説明する。
【００４４】
図９は、図３のサーバ２０１及びクライアント２０２〜２０４で実行されるファームウェア更新処理を説明する図である。
【００４５】
図９において、サーバ２０１は、図８のスケジュール表を管理する。サーバ２０１は、ファームウェアを更新するために必要な更新ファームウェアデータをファームウェア更新の対象となるクライアント２０２〜２０４のそれぞれに送信する。更新ファームウェアデータには、新しいファームウェアのほか、ファームウェアの更新を制御するためのコマンドなども含まれる。クライアント２０２〜２０４のそれぞれは、ファームウェアの更新を終了すると、その旨をサーバ２０１に通知する。ファームウェア更新の対象がサーバ２０１である場合には、サーバ２０１自らが更新ファームウェアデータに基づいてファームウェアの更新を行う。
【００４６】
図１０は、クライアント２０２〜２０４のそれぞれで実行されるファームウェア更新処理のフローチャートである。クライアント２０２〜２０４のそれぞれのＣＰＵ１０１が、図１０のフローチャートに基づくプログラムを実行することにより、このファームウェア更新処理が行われる。以下では、クライアント２０２がこのファームウェア更新処理を行うものとする。
【００４７】
水曜日の１時になると、サーバ２０１は、図８のスケジュール表に従って、ファームウェア更新の対象となるクライアント２０２に更新ファームウェアデータを送信する。従って、クライアント２０２は更新ファームウェアデータをサーバ２０１から受信する（ステップＳ９０１）。
【００４８】
更新ファームウェアデータを受信したクライアント２０２は、図１１に示すように表示部１０５に、数分後にファームウェアの更新が行われるため装置が使用不能になる旨を表示する（ステップＳ９０２）。また、ユーザがクライアント２０２を使用しようとした場合には、他の画像処理装置を使用するように促す。
【００４９】
次に、クライアント２０２は、現在処理中のジョブがあるか否かを判別する（ステップＳ９０３）。この判別の結果、現在処理中のジョブがあるときは、このジョブが終了するまで待つ。一方、現在処理中のジョブがないときは、クライアント２０２は、ネットワーク機能をオフラインモードに移行して新規にジョブを受け付けないようにすると共に、ＦＡＸ受信を無視するようにＦＡＸ機能を手動受信モードに移行させる（ステップＳ９０４）。これにより、クライアント２０２は、新規ジョブが投入されない状態になる。
【００５０】
次に、クライアント２０２は、ファームウェアの更新を実行する（ステップＳ９０５）。ファームウェアの更新が正常に終了した後、クライアント２０２は、ネットワーク機能をオンラインモードに移行すると共に、ＦＡＸ受信を受け付らけれるようにＦＡＸ機能を自動受信モードに移行させる（ステップＳ９０６）。これにより、クライアント２０２は、新規ジョブを受け付けられる状態になる。
【００５１】
次に、クライアント２０２は、ファームウェアの更新が正常に終了した旨をサーバ２０１に通知し（ステップＳ９０７）、本処理を終了する。その旨の通知を受けたサーバ２０１は、サーバ２０１で管理するスケジュール表（例えば図８）に、ファームウェアの更新が終了した旨を記録する。
サーバ２０１がファームウェア更新の対象となる場合には、サーバ２０１はステップＳ９０２〜Ｓ９０６を実行した上で、スケジュール表（例えば図８）に、ファームウェアの更新が終了した旨を記録する。
【００５２】
図１０の処理によれば、ユーザの使用頻度の低い時間帯にファームウェアの更新を行うので、データ処理装置におけるプログラムの更新を実行するに当たって、ユーザの業務に与える支障を軽減することができる。
【００５３】
［第２の実施の形態］
第１の実施の形態では、同じ時間帯に複数の画像処理装置のファームウェア更新が可能であるとした。一方、第２の実施の形態では、ファームウェアの更新を実行する間、複数台の画像処理装置が一斉に使用できなくなるのを防止するため、同一時間帯に複数の画像処理装置のファームウェアの更新が行われないようにする。
【００５４】
図１２〜図１６は、第２の実施の形態のファームウェア更新のスケジューリング処理のフローチャートである。サーバ２０１のＣＰＵ１０１が、図１２〜１６のフローチャートに基づくプログラムを実行することにより、このスケジューリング処理が行われる。
【００５５】
図１２において、サーバ２０１は、サーバ２０１自身及びクライアント２０２〜２０４が保持している、数週間の曜日毎及び時間毎のジョブ数を示すデータを取得する（ステップＳ１１０１）。次に、装置ごとに数週間分のジョブ総数を計算し、数週間分のジョブ総数が多いものから順にファームウェア更新の優先順位を決定する（ステップＳ１１０２）。図３は、決定された優先順位の一例を示す。数週間分のジョブ総数が多い装置ほどユーザの使用頻度が高く、このような装置ではジョブを実行していない空き時間が少ないと考えられる。そのため、数週間分のジョブ総数の多い装置に対して優先的にファームウェア更新のスケジューリングを行う。
【００５６】
次に、数週間分のジョブ総数の最も多い装置（つまり、ファームウェア更新の優先順位の最も高い装置）から順にファームウェア更新のスケジューリングを行う。まず、スケジューリングの対象となる装置に関して、図６に示すように、取得した数週間の曜日毎及び時間毎のジョブ数を示すデータから曜日毎のジョブ数の総和を計算し、曜日毎のジョブ数の総和が小さい順に順番を決定する（ステップＳ１１０３）。これは、ジョブ数の総和が小さい曜日ほど空き時間が多い可能性が高いためである。図６では、土曜日が最もジョブ数の総和が小さいので、順番が１となる。
【００５７】
ステップＳ１１０３の計算の結果、ジョブ総数の少ない曜日から順に空き時間の多い時間帯を検索する。空き時間の多い時間帯を検索する曜日において、３時間連続でジョブ数が０の時間帯があるか否かを判別する（ステップＳ１１０４）。
【００５８】
ステップＳ１１０４の判別の結果、３時間連続でジョブ数が０の時間帯があるときは、３時間連続でジョブ数が０の時間帯が複数あるか否かを判別する（ステップＳ１１０６）。この判別の結果、３時間連続でジョブ数が０の時間帯が複数あるときは、ステップＳ１１０７に進む。ステップＳ１１０７では、３時間連続でジョブ数が０の時間帯の前後の時間のジョブ数を含むジョブ総数（それぞれの時間におけるジョブ数がｍ，０，０，０，ｎとするとｍ＋ｎ）が最小となる時間帯をファームウェア更新の時間帯の候補として選択する。その上で、その時間帯の真ん中の時間をファームウェア更新の時間の候補として選択し、ステップＳ１１０９に進む。
【００５９】
一方、ステップＳ１１０６の判別の結果、３時間連続でジョブ数が０の時間帯が複数ないときは、３時間連続でジョブ数が０である唯一の時間帯をファームウェア更新の時間帯の候補として選択する。その上で、その時間帯の真ん中の時間をファームウェア更新の時間の候補として選択し（ステップＳ１１０８）、ステップＳ１１０９に進む。
【００６０】
ステップＳ１１０９では、スケジュール表と候補の時間とを比較し、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているか否かを判別する。この判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされていないときは、候補の時間をファームウェア更新の時間として決定し、スケジュール表の該当する時間に装置の名前を登録する（ステップＳ１１１０）。
【００６１】
ステップＳ１１０９の判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているときは、ステップＳ１１１１に進む。ステップＳ１１１１では、ｍ＞ｎならば、ｎに近い時間をファームウェア更新の時間の候補とし、ｍ＜＝ｎならば、ｍに近い時間をファームウェア更新の時間の候補とする。
【００６２】
次に、スケジュール表と候補の時間とを比較し、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているか否かを判別する（ステップＳ１１１２）。この判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされていないときは、候補の時間をファームウェア更新の時間として決定し、スケジュール表の該当する時間に装置の名前を登録する（ステップＳ１１１０）。
【００６３】
ステップＳ１１１２の判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているときは、ステップＳ１１１３に進む。ステップＳ１１１３では、ｍ＞ｎならば、ｍに近い時間をファームウェア更新の時間帯の候補とし、ｍ＜＝ｎならば、ｎに近い時間をファームウェア更新の時間の候補とする。
【００６４】
次に、スケジュール表と候補の時間とを比較し、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているか否かを判別する（ステップＳ１１１４）。この判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされていないときは、候補の時間をファームウェア更新の時間として決定し、スケジュール表の該当する時間に装置の名前を登録する（ステップＳ１１１０）。
【００６５】
ステップＳ１１１２の判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているときは、３時間連続でジョブ数が０の時間帯が他にあるか否かを判別する（ステップＳ１１１５）。
【００６６】
ステップＳ１１１５の判別の結果、３時間連続でジョブ数が０の時間帯が他にあるときは、現在の候補の時間帯を選択対象から除き（ステップＳ１１１６）、ステップＳ１１０６に戻る。
【００６７】
ステップＳ１１１５の判別の結果、３時間連続でジョブ数が０の時間帯が他にないときは、３時間連続でジョブ数が０の時間帯を検索していない曜日があるか否かを判別する（ステップＳ１１０５）。この判別の結果、３時間連続でジョブ数が０の時間帯を検索していない曜日があるときは、ステップＳ１１０４に戻る。一方、３時間連続でジョブ数が０の時間帯を検索していない曜日がないときは、ステップＳ１１１７に進む。ステップＳ１１１７では、ジョブ総数の少ない曜日から順に、２時間連続でジョブ数が０の時間帯があるか否かを判別する。
【００６８】
ステップＳ１１１７の判別の結果、２時間連続でジョブ数が０の時間帯があるときは、２時間連続でジョブ数が０の時間帯が複数あるか否かを判別する（ステップＳ１１１９）。この判別の結果、２時間連続でジョブ数が０の時間帯が複数ないときは、２時間連続でジョブ数が０である唯一の時間帯をファームウェア更新の時間帯の候補として選択し、ステップＳ１１２１に進む。一方、この判別の結果、２時間連続でジョブ数が０の時間帯が複数あるときは、ステップＳ１１２０に進む。ステップＳ１１２０では、時間連続でジョブ数が０の時間帯の前後の時間のジョブ数を含むジョブ総数（それぞれの時間におけるジョブ数がｍ，０，０，ｎとするとｍ＋ｎ）が最小となる時間帯をファームウェア更新の時間帯の候補として選択する。
【００６９】
ステップＳ１１２１では、ｍ＞ｎならば、ｎに近い時間をファームウェア更新の時間の候補とし、ｍ＜＝ｎならば、ｍに近い時間をファームウェア更新の時間の候補とする（ステップＳ１１２１）。
【００７０】
次に、スケジュール表と候補の時間とを比較し、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているか否かを判別する（ステップＳ１１２２）。この判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされていないときは、候補の時間をファームウェア更新の時間として決定し、スケジュール表の該当する時間に装置の名前を登録する（ステップＳ１１２３）。
【００７１】
ステップＳ１１２２の判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているときは、ステップＳ１１２４に進む。ステップＳ１１２４では、ｍ＞ｎならば、ｍに近い時間をファームウェア更新の時間の候補とし、ｍ＜＝ｎならば、ｎに近い時間をファームウェア更新の時間の候補とする。
【００７２】
次に、スケジュール表と候補の時間とを比較し、候補の時間帯に既に他の装置装置でのファームウェア更新がスケジューリングされているか否かを判別する（ステップＳ１１２５）。この判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされていないときは、候補の時間をファームウェア更新の時間として決定し、スケジュール表の該当する時間に装置の名前を登録する（ステップＳ１１２３）。
【００７３】
ステップＳ１１２５の判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているときは、２時間連続でジョブ数が０の時間帯が他にあるか否かを判別する（ステップＳ１１２６）。
【００７４】
ステップＳ１１２６の判別の結果、２時間連続でジョブ数が０の時間帯が他にあるときは、現在の候補の時間帯を選択対象から除き（ステップＳ１１２７）、ステップＳ１１１９に戻る。
【００７５】
ステップＳ１１２６の判別の結果、２時間連続でジョブ数が０の時間帯が他にないときは、２時間連続でジョブ数が０の時間帯を検索していない曜日があるか否かを判別する（ステップＳ１１１８）。この判別の結果、２時間連続でジョブ数が０の時間帯を検索していない曜日があるときは、ステップＳ１１１７に戻る。一方、２時間連続でジョブ数が０の時間帯を検索していない曜日がないときは、ステップＳ１１２８に進む。ステップＳ１１２８では、ジョブ総数の少ない曜日から順に、１時間ジョブ数が０の時間があるか否かを判別する。
【００７６】
ステップＳ１１２８の判別の結果、１時間ジョブ数が０の時間帯があるときは、１時間ジョブ数が０の時間が複数あるか否かを判別する（ステップＳ１１３０）。この判別の結果、１時間ジョブ数が０の時間が複数あるときは、ステップＳ１１３１に進む。ステップＳ１１３１では、１時間ジョブ数が０の時間の前後の時間のジョブ数を含むジョブ総数（それぞれの時間におけるジョブ数がｍ，０，ｎとするとｍ＋ｎ）が最小となる時間をファームウェア更新の時間の候補として選択し、ステップＳ１１３３に進む。
【００７７】
一方、ステップＳ１１３０の判別の結果、１時間ジョブ数が０の時間が複数ないときは、１時間ジョブ数が０である唯一の時間をファームウェア更新の時間の候補として選択し（ステップＳ１１３２）、ステップＳ１１３３に進む。
【００７８】
次に、スケジュール表と候補の時間とを比較し、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているか否かを判別する（ステップＳ１１３３）。この判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされていないときは、候補の時間をファームウェア更新の時間として決定し、スケジュール表の該当する時間に装置の名前を登録する（ステップＳ１１３４）。
【００７９】
ステップＳ１１３３の判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているときは、１時間ジョブ数が０の時間が他にあるか否かを判別する（ステップＳ１１３５）。
【００８０】
ステップＳ１１３５の判別の結果、１時間ジョブ数が０の時間が他にあるときは、現在の候補の時間を選択対象から除き（ステップＳ１１３６）、ステップＳ１１３０に戻る。
【００８１】
ステップＳ１１３５の判別の結果、１時間ジョブ数が０の時間帯が他にないときは、１時間ジョブ数が０の時間帯を検索していない曜日があるか否かを判別する（ステップＳ１１２９）。この判別の結果、１時間ジョブ数が０の時間帯を検索していない曜日があるときは、ステップＳ１１２８に戻る。一方、１時間ジョブ数が０の時間帯を検索していない曜日がないときは、ジョブ総数が最も少ない曜日を選択する（ステップＳ１１３７）。
【００８２】
次に、選択した曜日で最小のジョブ数をＸとすると、ジョブ数がＸの時間が複数あるか否かを判別する（ステップＳ１１３８）。
【００８３】
この判別の結果、ジョブ数がＸの時間が複数あるときは、ステップＳ１１３９に進む。ステップＳ１１３９では、ジョブ数がＸの時間の前後の時間のジョブ数を含むジョブ総数（それぞれの時間におけるジョブ数がｍ、Ｘ，ｎとするとｍ＋ｎ）が最小となる時間をファームウェア更新の時間の候補として選択し、ステップＳ１１４１に進む。
【００８４】
一方、ステップＳ１１３８の判別の結果、ジョブ数がＸの時間が複数ないときは、ジョブ数がＸである唯一の時間をファームウェア更新の時間の候補として選択し（ステップＳ１１４０）、ステップＳ１１４１に進む。
【００８５】
次に、スケジュール表と候補の時間とを比較し、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているか否かを判別する（ステップＳ１１４１）。この判別の結果、候補の時間に既に他の装置でのファームウェアの更新がスケジューリングされていないときは、候補の時間をファームウェア更新の時間として決定し、スケジュール表の該当する時間に装置の名前を登録する（ステップＳ１１４２）。
【００８６】
ステップＳ１１４１の判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているときは、ジョブ数がＸの時間帯が他にあるか否かを判別する（ステップＳ１１４３）。
【００８７】
ステップＳ１１４３の判別の結果、ジョブ数がＸの時間帯が他にあるときは、現在の候補の時間を選択対象から除き（ステップＳ１１４４）、ステップＳ１１３８に戻る。
【００８８】
ステップＳ１１４３の判別の結果、ジョブ数がＸの時間帯が他にないときは、ステップＳ１１３７またはＳ１１４６で全ての曜日が選択されたか否かを判別する（ステップＳ１１４５）。この判別の結果、全ての曜日が選択されていないときは、ジョブ総数が次に少ない曜日を選択し（ステップＳ１１４６）、ステップＳ１１３８に戻る。
【００８９】
一方、全ての曜日が選択されたときは、ステップＳ１１４７に進む。ステップＳ１１４７では、最初に候補となった時間をファームウェア更新の時間として決定し、スケジュール表の該当する時間に装置の名前を登録し、ステップＳ１１４８に進む。この場合は、他の装置でのファームウェアの更新と時間帯が重なってしまうことになる。
【００９０】
ステップＳ１１４８では、ファームウェア更新のスケジューリングを行っていない装置があるか否かを判別する。この判別の結果、ファームウェア更新のスケジューリングを行っていない装置があるときは、ステップＳ１１０３に戻る。一方、ファームウェア更新のスケジューリングを行っていない装置がないときは、本処理を終了する。
【００９１】
図１２〜図１６のスケジューリング処理を実行すると、図８に示すように、複数台の画像処理装置のファームウェア更新のスケジュールが決定される。なお、サーバ２０１のファームウェア更新のスケジュールだけは、クライアント２０２〜２０４のスケジュールと同じ時間にならないようにする必要がある。
【００９２】
図１２〜１５の処理によれば、同じ時間帯に他の装置でのファームウェア更新がスケジューリングされないようにするので、ファームウェアの更新を実行する間、複数台の画像処理装置が一斉に使用できなくなるのを防止する。
【００９３】
［第３の実施の形態］
第１及び第２の実施の形態では、ファームウェア更新時に処理中のジョブが存在した場合、ジョブが終了するのを待ってから、ファームウェア更新を実行した。一方、第３の実施の形態では、ファームウェア更新時に処理中のジョブが存在した場合、サーバに対してファームウェア更新の再スケジューリング依頼を行う。
【００９４】
図１７は、第３の実施の形態におけるファームウェア更新処理のフローチャートである。以下では、クライアント２０２がファームウェア更新の対象となっているものとする。
【００９５】
図１７において、ファームウェア更新の時間になると、サーバ２０１は、ファームウェア更新の対象となるクライアント２０２のステータスが“未”であるか否かを判別する（ステップＳ１２０１）。
【００９６】
図１８のスケジュール表では、サーバ２０１及びクライアント２０２〜２０４でのファームウェア更新の状況を知るために、ステータス欄を有する。
【００９７】
図４及び図５又は図１２〜図１６のスケジューリング処理でファームウェア更新のスケジュールを作成する際は、まだファームウェアの送信も更新も行われていないので、各装置のステータス欄には“未”が記載される。
【００９８】
図１９に示すように、未”のステータス１４０１は、まだファームウェアの送信も更新も行われていない状況を示す。
【００９９】
“送信済”のステータス１４０２は、装置に対して更新ファームウェアデータを送信済みである状態を示す。
【０１００】
“済”のステータス１４０３は、装置に対して更新ファームウェアデータの送信も終了し、ファームウェアの更新も正常に終了した状態を示す。
【０１０１】
ステップＳ１２０１の判別の結果、クライアント２０２のステータスが“未”であるときは、ステップＳ１２０３に進む。一方、クライアント２０２のステータスが“未”でないときは、サーバ２０１はクライアント２０２のステータスが“送信済”であるか否かを判別する（ステップＳ１２０２）。
【０１０２】
ステップＳ１２０２の判別の結果、クライアント２０２のステータスが“送信済”であるときは、ステップＳ１２０５に進む。一方、クライアント２０２のステータスが“送信済”でないときは、ステータスは“済”であるということを意味するので、本処理を終了する。
【０１０３】
ステップＳ１２０３では、サーバ２０１は、クライアント２０２に更新ファームウェアデータを送信する。送信が終了すると、サーバ２０１は、図１８のスケジュール表におけるクライアント２０２に対応するステータス欄に“送信済”と記載する（ステップＳ１２０４）。
【０１０４】
更新ファームウェアデータを受信したクライアント２０２は、図１１に示すように表示部１０５に、数分後にファームウェアの更新が行われるため装置が使用不能になる旨を表示する（ステップＳ１２０５）。これにより、ユーザにファームウェアの更新作業に自動的に入ることを通知する。
【０１０５】
次に、クライアント２０２は、現在処理中のジョブがあるか否かを判別する（ステップＳ１２０６）。この判別の結果、現在処理中のジョブがあるときは、クライアント２０２は、サーバ２０１にファームウェア更新の再スケジューリングを依頼する（ステップＳ１２０７）。この際、サーバ２０１への通知方法は、メール、又はSocket通信を伴ったハンドシェイクされた通信等、特に手段を問わない。これにより、サーバ２０１は、後述する図２０の再スケジューリング処理を実行して、ファームウェア更新の再スケジューリングを行う。
【０１０６】
次に、クライアント２０２は、ステップＳ１２０５で行ったファームウェアの更新のため装置が使用不能になる旨の表示を消す（ステップＳ１２０８）。
【０１０７】
一方、ステップＳ１２０６の判別の結果、現在処理中のジョブがないときは、ステップＳ１２１０に進む。ステップＳ１２１０では、クライアント２０２は、ネットワーク機能をオフラインモードに移行して新規にジョブを受け付けないようにすると共に、ＦＡＸ受信を無視するようにＦＡＸ機能を手動受信モードに移行させる。これにより、クライアント２０２は、新規ジョブが投入されない状態になる。
【０１０８】
次に、クライアント２０２は、ファームウェアの更新を実行する（ステップＳ１２１１）。ファームウェアの更新が正常に終了した後、クライアント２０２は、ネットワーク機能をオンラインモードに移行すると共に、ＦＡＸ受信を受け付らけれるようにＦＡＸ機能を自動受信モードに移行させる（ステップＳ１２１２）。これにより、クライアント２０２は、新規ジョブを受け付けられる状態になる。
【０１０９】
次に、クライアント２０２は、ファームウェアの更新が正常に終了した旨をサーバ２０１に通知する（ステップＳ１２１３）。その旨が通知されたサーバ２０１は、サーバ２０１で管理するスケジュール表におけるクライアント２０２に対応するステータス欄に“済”と記載し（ステップＳ１２１４）、本処理を終了する。
【０１１０】
図１９の処理によれば、ファームウェア更新をしようとする時に処理中のジョブが存在した場合、サーバに対してファームウェア更新の再スケジューリングを依頼するので、データ処理装置におけるプログラムの更新を実行するに当たって、ユーザの業務に与える支障を軽減することができる。
サーバ２０１がファームウェア更新の対象となる場合には、サーバ２０１はＳ１２０１〜Ｓ１２０２、Ｓ１２０４〜Ｓ１２０８、Ｓ１２１０〜Ｓ１２１２及びＳ１２１４を実行する。
【０１１１】
図２０は、サーバ２０１によって実行される再スケジューリング処理のフローチャートである。サーバ２０１のＣＰＵ１０１が、図２０のフローチャートに基づくプログラムを実行することにより、この再スケジューリング処理が行われる。以下でも、クライアント２０２がファームウェア更新の対象となっているものとする。
【０１１２】
図２０において、サーバ２０１は、再スケジューリングの依頼をクライアント２０２から受けると、図１８のスケジュール表に基づいて、ステータスが“未”又は“送信済”となっている装置のみをピックアップする（ステップＳ１５０１）。既にステータスが“済”となっている装置は、ファームウェア更新が終了しているので、再スケジューリングの対象としない。
【０１１３】
次に、サーバ２０１は、ステップＳ１５０１でピックアップした装置が保持している最新の数週間の曜日毎及び時間毎のジョブ数を示すデータを取得しなおす（ステップＳ１５０２）。
【０１１４】
次に、取得した数週間の曜日毎及び時間毎のジョブ数を示すデータに基づいて、図４及び図５又は図１２〜図１６のスケジューリング処理を実行して、ファームウェア更新の再スケジューリングを行い（ステップＳ１５０３）、本処理を終了する。これにより、最新の状況で、スケジュール表を作成しなおす。
【０１１５】
図２０の処理によれば、ファームウェアの更新をしようとした時に処理中のジョブが存在した場合、ファームウェア更新の再スケジューリングが自動的に行われるので、データ処理装置におけるプログラムの更新を実行するに当たって、ユーザの業務に与える支障を軽減することができる。
【０１１６】
［第４の実施の形態］
第１〜第３の実施の形態では、ファームウェア更新のスケジュールは、ユーザの使用頻度の低い時間帯を元に作成されている。このため、ファームウェア更新の時間には、画像処理装置が長時間使用されていないことにより、消費電力の低いスリープ状態に画像処理装置が移行している可能性が高い。またサーバ２０１も長時間使用されてないことにより、消費電力の低いスリープ状態にサーバ２０１が移行している可能性が高い。そこで、第４の実施の形態は、サーバ２０１又はクライアント２０２〜２０４において、スリープ状態から復帰する処理を行う。
【０１１７】
図２１は、クライアント２０２〜２０４のスリープ復帰処理のフローチャートである。クライアント２０２〜２０４のそれぞれのＣＰＵ１０１が、図２１のフローチャートに基づくプログラムを実行することにより、このスリープ復帰処理が行われる。
【０１１８】
図８や図１８のスケジュール表が作成されると、サーバ２０１は、図８や図１８のスケジュール表に基づいて、ファームウェア更新の対象となるクライアントにファームウェア更新日時を通知する。従って、クライアントは、ファームウェア更新日時の通知をサーバ２０１から受ける（ステップＳ１６０２）。この際、サーバ２０１からの通知方法は、メール、又はＰｏｒｔを特定してSocket通信によるデータの通知等、特に手段を問わない。
【０１１９】
サーバ２０１からファームウェア更新日時を通知されたクライアントは、「ファームウェア更新日時−α」の日時をＲＡＭ１０３等に記憶する（ステップＳ１６０３）。ここで−αとしたのは、クライアントがスリープしていた場合、スリープ復帰に時間がかかる場合を想定しているためである。
【０１２０】
ステップＳ１６０４では、クライアントがスリープ状態に移行するか否かを判別する。即ち、ユーザの処理又はジョブの投入が規定時間の間なかった場合に消費電力の低いスリープ状態に移行する設定が各クライアントにあり、各クライアントではその規定時間が設定可能である。従って、クライアントは、その規定時間の間、放置されているか否かを判別する。
【０１２１】
この判別の結果、クライアントがスリープ状態に移行しないときは、クライアントは、ファームウェア更新日時になったか否かを判別する（ステップＳ１６０５）。この判別の結果、ファームウェア更新日時になっていないときは、ステップＳ１６０４に戻る。一方、ファームウェア更新日時になったときは、本処理を終了する。本処理が終了した後には、ファームウェア更新処理が実行される。
【０１２２】
ステップＳ１６０４の判別の結果、クライアントがスリープ状態に移行するときは、クライアントは、ステップＳ１６０３でＲＡＭ１０３に記憶していた「ファームウェア更新日時−α」の日時をＲＴＣ１１４のアラーム時刻に設定してスリープ状態に移行する（ステップＳ１６０６）。
【０１２３】
次に、クライアントは、ユーザによりスリープ状態から復帰させられるか否かを判別する（ステップＳ１６０７）。この判別の結果、ユーザによりスリープ状態から復帰させられるときは、クライアントはスリープ状態から復帰し（ステップＳ１６１１）、ステップＳ１６０４に戻る。
【０１２４】
ステップＳ１６０７の判別の結果、ユーザによりスリープ状態から復帰させられなかったときは、クライアントは、ＲＴＣ１１４から割り込み信号が送信されたか否かを判別する（ステップＳ１６０８）。アラーム時刻になったときは、ＲＴＣ１１４がハードウェア的に割り込み信号を送信する。
【０１２５】
ＲＴＣ１１４から割り込み信号が送信されたときは、ＣＰＵ１０１に対してReset解除信号が送信され、クライアントは、スリープ状態から復帰し（ステップＳ１６１０）、本処理を終了する。本処理が終了した後には、ファームウェア更新処理が実行される。
【０１２６】
図２１の処理によれば、ファームウェアの更新が行われようとする時にクライアント２０２〜２０４がスリープ状態に移行している場合にも、ファームウェアの更新処理を実行することができる。
【０１２７】
図２２は、サーバ２０１のスリープ復帰処理のフローチャートである。サーバ２０１のＣＰＵ１０１が、図２２のフローチャートに基づくプログラムを実行することにより、このスリープ復帰処理が行われる。
【０１２８】
図８や図１８のスケジュール表が作成されると、サーバ２０１は、図８や図１８のスケジュール表に基づいて、現在時刻に最も時間の近いファームウェア更新日時を検出する（ステップＳ１７０１）。サーバ２０１は、ステップＳ１７０１で検出した「現在時刻に最も近いファームウェア更新日時−α」の日時をＲＡＭ１０３等に記憶する（ステップＳ１７０２）。ここで−αとしたのは、サーバ２０１がスリープしていた場合、スリープ復帰に時間がかかる場合を想定しているためである。
【０１２９】
ステップＳ１７０４では、サーバ２０１がスリープ状態に移行するか否かを判別する。即ち、ユーザの処理又はジョブの投入が規定時間の間なかった場合に消費電力の低いスリープ状態に移行する設定がサーバ２０１にあり、サーバ２０１ではその規定時間が設定可能である。従って、サーバ２０１は、その規定時間の間、放置されているか否かを判別する。
【０１３０】
この判別の結果、サーバ２０１がスリープ状態に移行しないときは、サーバ２０１は、ステップＳ１７０１で検出したファームウェア更新日時になったか否かを判別する（ステップＳ１７０５）。この判別の結果、ステップＳ１７０１で検出したファームウェア更新日時になっていないときは、ステップＳ１７０４に戻る。一方、ステップＳ１７０１で検出したファームウェア更新日時になったときは、本処理を終了する。本処理が終了した後には、ファームウェア更新処理が実行される。
【０１３１】
ステップＳ１７０４の判別の結果、サーバ２０１がスリープ状態に移行するときは、サーバ２０１は、ステップＳ１６０３でＲＡＭ１０３に記憶していた「現在時刻に最も近いファームウェア更新日時−α」の日時をＲＴＣ１１４のアラーム時刻に設定してスリープ状態に移行する（ステップＳ１７０６）。
【０１３２】
次に、サーバ２０１は、ユーザによりスリープ状態から復帰させられるか否かを判別する（ステップＳ１７０７）。この判別の結果、ユーザによりスリープ状態から復帰させられるときは、サーバ２０１はスリープ状態から復帰し（ステップＳ１７１１）、ステップＳ１７０４に戻る。
【０１３３】
ステップＳ１７０７の判別の結果、ユーザによりスリープ状態から復帰させられなかったときは、サーバ２０１は、ＲＴＣ１１４から割り込み信号が送信されたか否かを判別する（ステップＳ１７０８）。アラーム時刻になったときは、ＲＴＣ１１４がハードウェア的に割り込み信号を送信する（ステップＳ１７０９）。
【０１３４】
ＲＴＣ１１４から割り込み信号が送信されたときは、ＣＰＵ１０１に対してReset解除信号が送信され、サーバ２０１は、スリープ状態から復帰し（ステップＳ１７１０）、本処理を終了する。本処理が終了した後には、ファームウェア更新処理が実行される。
【０１３５】
図２１の処理によれば、ファームウェアの更新が行われようとする時にサーバ２０１がスリープ状態に移行している場合にも、ファームウェアの更新処理を実行することができる。
【０１３６】
上記の実施の形態で説明した処理、機能等は、いずれもコンピュータ読み取り可能なプログラム等で実現することもできる。
【０１３７】
この場合、上記の実施の形態で説明した処理、機能等は、システム又は装置に含まれるコンピュータ（ＣＰＵ、ＭＰＵ等でもよい）が上記のプログラム等を実行することによって実現されることになる。言い換えれば、上記のプログラム等が、システム又は装置に含まれるコンピュータに、上記の実施の形態で説明した処理、機能等を実行させることになる。また、この場合、上記のプログラム等は、コンピュータ読み取り可能な記憶媒体又はネットワークを介してシステム又は装置に含まれるコンピュータに提供されることになる。
【０１３８】
システム又は装置に含まれるコンピュータに上記のプログラム等を提供する記憶媒体には、磁気ディスク、光ディスク、光磁気ディスク、ハードディスク、磁気テープ、不揮発性メモリ等を用いることができる。
【０１３９】
また、上記のプログラム等は、その一部をコンピュータ上で稼動しているＯＳ（オペレーティングシステム）等を用いて構成してもよい。
【０１４０】
さらに、上記のプログラム等は、その一部をコンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットで実行するように構成してもよい。
【図面の簡単な説明】
【０１４１】
【図１】第１の実施の形態に係るデータ処理装置の内部構成を示すブロック図である。
【図２】図１の画像処理装置１００で実行されるプログラムの更新のスケジューリングを説明する図である。
【図３】図１の画像処理装置１００で実行されるプログラムの更新のスケジューリングを説明する図である。
【図４】図３のサーバ２０１で実行されるファームウェア更新のスケジューリング処理のフローチャートである。
【図５】図３のサーバ２０１で実行されるファームウェア更新のスケジューリング処理のフローチャートである。
【図６】図４のステップＳ４０３で用いる数週間の曜日毎及び時間毎のジョブ数を示すデータを示す図である。
【図７】図５のステップＳ４０６で用いるファームウェア更新のスケジュール表を示す図である。
【図８】図４及び図５のスケジューリング処理によって作成されるファームウェア更新のスケジュール表を示す図である。
【図９】図３のサーバ２０１及びクライアント２０２〜２０４で実行されるファームウェア更新処理を説明する図である。
【図１０】図３のサーバ２０１及びクライアント２０２〜２０４で実行されるファームウェア更新処理のフローチャートである。
【図１１】図１０のステップＳ９０２で表示される装置が使用不能になる旨の表示を示す図である。
【図１２】第２の実施の形態のファームウェア更新のスケジューリング処理のフローチャートである。
【図１３】第２の実施の形態のファームウェア更新のスケジューリング処理のフローチャートである。
【図１４】第２の実施の形態のファームウェア更新のスケジューリング処理のフローチャートである。
【図１５】第２の実施の形態のファームウェア更新のスケジューリング処理のフローチャートである。
【図１６】第２の実施の形態のファームウェア更新のスケジューリング処理のフローチャートである。
【図１７】第３の実施の形態におけるファームウェア更新処理のフローチャートである。
【図１８】図１７のファームウェア更新処理で用いられるファームウェア更新のスケジュール表を示す図である。
【図１９】図１８のスケジュール表におけるステータス欄を説明する図である。
【図２０】サーバ２０１によって実行される再スケジューリング処理のフローチャートである。
【図２１】ククライアント２０２〜２０４のスリープ復帰処理のフローチャートである。
【図２２】サーバ２０１のスリープ復帰処理のフローチャートである。
【符号の説明】
【０１４２】
１０１  ＣＰＵ
１０２  フラッシュＲＯＭ
１０３  ＲＡＭ
１０４  外部記憶装置
１０５  表示部
１０６  操作部
１１４  ＲＴＣ
【図１】
2008152482.tif 000003
【図２】
2008152482.tif 000004
【図３】
2008152482.tif 000005
【図４】
2008152482.tif 000006
【図５】
2008152482.tif 000007
【図６】
2008152482.tif 000008
【図７】
2008152482.tif 000009
【図８】
2008152482.tif 000010
【図９】
2008152482.tif 000011
【図１０】
2008152482.tif 000012
【図１１】
2008152482.tif 000013
【図１２】
2008152482.tif 000014
【図１３】
2008152482.tif 000015
【図１４】
2008152482.tif 000016
【図１５】
2008152482.tif 000017
【図１６】
2008152482.tif 000018
【図１７】
2008152482.tif 000019
【図１８】
2008152482.tif 000020
【図１９】
2008152482.tif 000021
【図２０】
2008152482.tif 000022
【図２１】
2008152482.tif 000023
【図２２】
2008152482.tif 000024
【手続補正書】
【提出日】平成19年11月27日(2007.11.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ジョブを実行するクライアント装置にプログラムを送信し、前記クライアント装置にプログラムを更新させるサーバ装置であって、
前記クライアント装置によって複数の期間の各々で実行されたジョブの実行状況を示す実行状況データを前記クライアント装置から取得する取得手段と、
前記取得手段により取得した実行状況データに基づいて、前記クライアント装置におけるプログラムの更新スケジュールを決定するスケジューリング手段とを備えることを特徴とするサーバ装置。
【請求項２】
前記スケジューリング手段は、前記取得手段により取得した実行状況データに基づいて、前記クライアント装置におけるジョブの実行が少ない時間またはジョブの実行がない時間を検出し、検出した時間に基づいて前記更新スケジュールを決定することを特徴とする請求項１記載のサーバ装置。
【請求項３】
前記取得手段は、複数のクライアント装置のそれぞれから前記実行状況データを取得し、
前記スケジューリング手段は、前記複数のクライアント装置が同一の時間にプログラムの更新を行わないように、前記取得手段により前記複数のクライアント装置から取得される前記実行状況データに基づいて、前記複数のクライアント装置の各々におけるプログラムの更新スケジュールを決定することを特徴とする請求項１又は２記載のサーバ装置。
【請求項４】
前記スケジューリング手段により決定された前記スケジュールに従って、前記クライアント装置におけるプログラムの更新に必要なデータを送信する送信手段を有することを特徴とする請求項１乃至３のいずれか１項に記載のサーバ装置。
【請求項５】
前記実行状況データは、前記クライアント装置によって複数の期間の各々で実行されたジョブの数を示すことを特徴とする請求項１乃至４のいずれか１項に記載のサーバ装置。
【請求項６】
ジョブを実行するクライアント装置と、前記クライアント装置にプログラムを送信して前記クライアント装置にプログラムを更新させるサーバ装置とを有するデータ処理システムであって、
前記サーバ装置は、
前記クライアント装置によって複数の期間の各々で実行されたジョブの実行状況を示す実行状況データを、前記クライアント装置から取得する取得手段と、
前記取得手段により取得した実行状況データに基づいて、前記クライアント装置におけるプログラムの更新スケジュールを決定するスケジューリング手段と、
前記スケジューリング手段により決定された更新スケジュールに従って、前記クライアント装置にプログラムの更新に必要なデータを送信する送信手段とを備え、
前記クライアント装置は、
前記実行状況データを記憶する記憶手段と、
プログラムの更新に必要なデータを前記サーバ装置から受信する受信手段と、
前記受信手段により受信したデータに基づいてプログラムの更新を行う更新手段とを備えることを特徴とするデータ処理システム。
【請求項７】
前記クライアント装置は、プログラムの更新が終了した場合にプログラムの更新が終了したことを前記サーバ装置に通知する通知手段とを有することを特徴とする請求項６に記載のデータ処理システム。
【請求項８】
前記受信手段が前記プログラムの更新に必要なデータを受信した際に前記クライアント装置がジョブを実行中であった場合、前記更新手段は、前記実行中のジョブが終了してからプログラムの更新を行うことを特徴とする請求項６又は７に記載のデータ処理システム。
【請求項９】
前記受信手段が前記プログラムの更新に必要なデータを受信した際に前記クライアント装置がジョブを実行中であった場合、前記更新手段は、前記サーバ装置に対してプログラムの更新の再スケジューリングを依頼することを特徴とする請求項６乃至８のいずれか１項に記載のデータ処理システム。
【請求項１０】
前記クライアント装置は、前記スケジューリング手段により決定された更新スケジュールに従って、省電力状態から復帰する復帰手段を備えることを特徴とする請求項６乃至９のいずれか１項に記載のデータ処理システム。
【請求項１１】
前記サーバ装置は、前記スケジューリング手段により決定された更新スケジュールに従って、省電力状態から復帰する第２の復帰手段を備えることを特徴とする請求項６乃至１０のいずれか１項に記載のデータ処理システム。
【請求項１２】
前記実行状況データは、前記クライアント装置によって複数の期間の各々で実行されたジョブの数を示すことを特徴とする請求項６乃至１１のいずれか１項に記載のデータ処理システム。
【請求項１３】
ジョブを実行するクライアント装置にプログラムを送信し、前記クライアント装置にプログラムを更新させるサーバ装置におけるデータ処理方法であって、
前記クライアント装置によって複数の期間の各々で実行されたジョブの実行状況を示す実行状況データを前記クライアント装置から取得する取得ステップと、
前記取得ステップで取得した実行状況データに基づいて、前記クライアント装置におけるプログラムの更新スケジュールを決定するスケジューリングステップとを備えることを特徴とするデータ処理方法。
【請求項１４】
ジョブを実行するクライアント装置にプログラムを送信し、前記クライアント装置にプログラムを更新させるサーバ装置に、
前記クライアント装置によって複数の期間の各々で実行されたジョブの実行状況を示す実行状況データを前記クライアント装置から取得する取得ステップと、
前記取得ステップで取得した実行状況データに基づいて、前記クライアント装置におけるプログラムの更新スケジュールを決定するスケジューリングステップとを実行させることを特徴とするコンピュータ読み取り可能なプログラム。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００１
【補正方法】変更
【補正の内容】
【０００１】
本発明は、サーバ装置、データ処理システム及びその方法、並びにプログラムに関し、特に、プログラムの更新のスケジュールを決定するサーバ装置、データ処理システム及びその方法、並びにプログラムに関する。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】０００４
【補正方法】変更
【補正の内容】
【０００４】
本発明の目的は、プログラムの更新によりクライアント装置が使用できなくなることに伴う不具合を軽減することができるサーバ装置、データ処理システム及びその方法、並びにプログラムを提供することにある。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】０００５
【補正方法】変更
【補正の内容】
【０００５】
上述の目的を達成するために、請求項１記載のサーバ装置は、ジョブを実行するクライアント装置にプログラムを送信し、前記クライアント装置にプログラムを更新させるサーバ装置であって、前記クライアント装置によって複数の期間の各々で実行されたジョブの実行状況を示す実行状況データを前記クライアント装置から取得する取得手段と、前記取得手段により取得した実行状況データに基づいて、前記クライアント装置におけるプログラムの更新スケジュールを決定するスケジューリング手段とを備えることを特徴とする。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】０００６
【補正方法】変更
【補正の内容】
【０００６】
上述の目的を達成するために、請求項６記載のデータ処理システムは、ジョブを実行するクライアント装置と、前記クライアント装置にプログラムを送信して前記クライアント装置にプログラムを更新させるサーバ装置とを有するデータ処理システムであって、前記サーバ装置は、前記クライアント装置によって複数の期間の各々で実行されたジョブの実行状況を示す実行状況データを、前記クライアント装置から取得する取得手段と、前記取得手段により取得した実行状況データに基づいて、前記クライアント装置におけるプログラムの更新スケジュールを決定するスケジューリング手段と、前記スケジューリング手段により決定された更新スケジュールに従って、前記クライアント装置にプログラムの更新に必要なデータを送信する送信手段とを備え、前記クライアント装置は、前記実行状況データを記憶する記憶手段と、プログラムの更新に必要なデータを前記サーバ装置から受信する受信手段と、前記受信手段により受信したデータに基づいてプログラムの更新を行う更新手段とを備えることを特徴とする。
【手続補正７】
【補正対象書類名】明細書
【補正対象項目名】０００７
【補正方法】変更
【補正の内容】
【０００７】
上述の目的を達成するために、請求項１３記載のデータ処理方法は、ジョブを実行するクライアント装置にプログラムを送信し、前記クライアント装置にプログラムを更新させるサーバ装置におけるデータ処理方法であって、前記クライアント装置によって複数の期間の各々で実行されたジョブの実行状況を示す実行状況データを前記クライアント装置から取得する取得ステップと、前記取得ステップで取得した実行状況データに基づいて、前記クライアント装置におけるプログラムの更新スケジュールを決定するスケジューリングステップとを備えることを特徴とする。
【手続補正８】
【補正対象書類名】明細書
【補正対象項目名】０００８
【補正方法】変更
【補正の内容】
【０００８】
上述目的を達成するために、請求項１４記載のコンピュータ読み取り可能なプログラムは、ジョブを実行するクライアント装置にプログラムを送信し、前記クライアント装置にプログラムを更新させるサーバ装置に、前記クライアント装置によって複数の期間の各々で実行されたジョブの実行状況を示す実行状況データを前記クライアント装置から取得する取得ステップと、前記取得ステップで取得した実行状況データに基づいて、前記クライアント装置におけるプログラムの更新スケジュールを決定するスケジューリングステップとを実行させることを特徴とする。
【手続補正９】
【補正対象書類名】明細書
【補正対象項目名】０００９
【補正方法】変更
【補正の内容】
【０００９】
本発明によれば、ジョブを実行するクライアント装置にプログラムを送信し、クライアント装置にプログラムを更新させるサーバ装置が、クライアント装置でのジョブの実行状況に基づいて、プログラムの更新スケジュールを決定するので、プログラムの更新によりクライアント装置が使用できなくなることに伴う不具合を軽減することができる。
【手続補正１０】
【補正対象書類名】明細書
【補正対象項目名】００１０
【補正方法】削除
【補正の内容】
【手続補正１１】
【補正対象書類名】明細書
【補正対象項目名】００１２
【補正方法】変更
【補正の内容】
【００１２】
［第１の実施の形態］
図１は、第１の実施の形態に係るサーバ装置を含むデータ処理装置の内部構成を示すブロック図である。
【手続補正１２】
【補正対象書類名】明細書
【補正対象項目名】０１４１
【補正方法】変更
【補正の内容】
【０１４１】
【図１】第１の実施の形態に係るサーバ装置を含むデータ処理装置の内部構成を示すブロック図である。
【図２】図１の画像処理装置１００で実行されるプログラムの更新のスケジューリングを説明する図である。
【図３】図１の画像処理装置１００で実行されるプログラムの更新のスケジューリングを説明する図である。
【図４】図３のサーバ２０１で実行されるファームウェア更新のスケジューリング処理のフローチャートである。
【図５】図３のサーバ２０１で実行されるファームウェア更新のスケジューリング処理のフローチャートである。
【図６】図４のステップＳ４０３で用いる数週間の曜日毎及び時間毎のジョブ数を示すデータを示す図である。
【図７】図５のステップＳ４０６で用いるファームウェア更新のスケジュール表を示す図である。
【図８】図４及び図５のスケジューリング処理によって作成されるファームウェア更新のスケジュール表を示す図である。
【図９】図３のサーバ２０１及びクライアント２０２〜２０４で実行されるファームウェア更新処理を説明する図である。
【図１０】図３のサーバ２０１及びクライアント２０２〜２０４で実行されるファームウェア更新処理のフローチャートである。
【図１１】図１０のステップＳ９０２で表示される装置が使用不能になる旨の表示を示す図である。
【図１２】第２の実施の形態のファームウェア更新のスケジューリング処理のフローチャートである。
【図１３】第２の実施の形態のファームウェア更新のスケジューリング処理のフローチャートである。
【図１４】第２の実施の形態のファームウェア更新のスケジューリング処理のフローチャートである。
【図１５】第２の実施の形態のファームウェア更新のスケジューリング処理のフローチャートである。
【図１６】第２の実施の形態のファームウェア更新のスケジューリング処理のフローチャートである。
【図１７】第３の実施の形態におけるファームウェア更新処理のフローチャートである。
【図１８】図１７のファームウェア更新処理で用いられるファームウェア更新のスケジュール表を示す図である。
【図１９】図１８のスケジュール表におけるステータス欄を説明する図である。
【図２０】サーバ２０１によって実行される再スケジューリング処理のフローチャートである。
【図２１】クライアント２０２〜２０４のスリープ復帰処理のフローチャートである。
【図２２】サーバ２０１のスリープ復帰処理のフローチャートである。