JP4673284B2

JP4673284B2 - サーバ装置

Info

Publication number: JP4673284B2
Application number: JP2006339065A
Authority: JP
Inventors: 康夫廣内
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2006-12-15
Filing date: 2006-12-15
Publication date: 2011-04-20
Anticipated expiration: 2026-12-15
Also published as: US20080148268A1; JP2008152482A

Description

本発明は、サーバ装置に関し、特に、プログラムの更新のスケジュールを決定するサーバ装置に関する。

従来より、遠隔地にあるサーバが、ネットワーク上に存在するデータ処理装置に組み込まれたファームウェアを更新する技術が知られている（例えば、特許文献１参照）。この技術では、サーバが、設備情報と、ファームウェアのバージョン情報とを管理する。また、サーバは、設備情報及びファームウェアのリリース日時等の情報に基づいて、自動的にファームウェア更新対象となるデータ処理装置を選び出す。サーバは、この更新対象となるデータ処理装置に対してファームウェアと、更新手順を示したシナリオとを伝送する。データ処理装置は、伝送されたシナリオに基づいてファームウェアの更新を行う。
特開平０７−２４８９１３号公報

しかしながら、上記特許文献１に記載されたファームウェアの更新技術では、同じ機種の同じバージョンのデータ処理装置が複数台存在した場合、複数台のデータ処理装置において一斉にファームウェアの更新が実行されてしまう。そのため、ファームウェアの更新を実行する間、複数台のデータ処理装置が一斉に使用できなくなるので、ユーザの業務に大いに支障を発生させる。ユーザの業務に与える支障を軽減するに当たっては、データ処理装置でのジョブの実行状況を考慮するのが望ましい。

本発明の目的は、ジョブの実行頻度の高いクライアント装置から優先的にプログラムの更新期間を決定するとともにジョブの実行回数が最も少なくかつ隣接する期間におけるジョブの実行回数が最も少ない期間を更新期間として決定し、更に、特定のクライアント装置と他のクライアント装置がプログラムを更新する更新期間が同一期間となることを避けることができるサーバ装置を提供することにある。

上述の目的を達成するために、請求項１記載のサーバ装置は、ジョブを実行する複数のクライアント装置にプログラムを送信し、前記複数のクライアント装置にプログラムを更新させるサーバ装置であって、前記クライアント装置によって複数の期間の各々で実行されたジョブの実行状況を示す実行状況データを前記複数のクライアント装置の各々から取得する取得手段と、前記取得手段により取得された複数の前記実行状況データに基づいて、前記複数のクライアント装置の各々がプログラムを更新する更新期間をジョブの実行頻度の高いクライアント装置から優先的に決定する決定手段とを備え、前記決定手段は、前記複数のクライアント装置に含まれる特定のクライアント装置の前記更新期間を決定する際に、前記取得手段により取得された前記特定のクライアント装置の実行状況データに基づいて前記複数の期間の中から前記特定のクライアント装置におけるジョブの実行回数が最も少ない期間を検出し、前記検出した期間が単数である場合は前記検出した期間を前記特定のクライアント装置の前記更新期間として決定する一方で前記検出した期間が複数である場合は前記検出した期間に隣接する期間におけるジョブの実行回数が最も少ない期間を前記特定のクライアント装置の前記更新期間として決定するとともに、前記特定のクライアント装置がプログラムを更新する更新期間が前記複数のクライアント装置に含まれる他のクライアント装置がプログラムを更新する更新期間として決定済みである場合は、前記特定のクライアント装置がプログラムを更新する更新期間を前記決定済みの更新期間と異ならせることを特徴とする。

本発明によれば、ジョブの実行頻度の高いクライアント装置から優先的にプログラムの更新期間を決定するとともにジョブの実行回数が最も少なくかつ隣接する期間におけるジョブの実行回数が最も少ない期間を更新期間として決定し、更に、特定のクライアント装置と他のクライアント装置がプログラムを更新する更新期間が同一期間となることを避けることができる。

以下、図面を参照しながら本発明の実施の形態を詳細に説明する。

［第１の実施の形態］
図１は、第１の実施の形態に係るサーバ装置を含むデータ処理装置の内部構成を示すブロック図である。

図１において、画像処理装置１００（データ処理装置）は、ＣＰＵ（中央演算装置）１０１、フラッシュＲＯＭ１０２、ＲＡＭ（ランダムアクセスメモリ）１０３、外部記憶装置１０４、表示部１０５、及び操作部１０６を備える。また、画像処理装置１００は、エンジンＩ／Ｆ（インターフェース）１０７、ＵＳＢデバイスＩ／Ｆ１１０、セントロＩ／Ｆ１１１、ネットワークＩ／Ｆ１１２、及びFAX Unit１１３、ＲＴＣ（Real Time Clock）１１４を備える。これらは、システムバス１１５を介して互いに接続されている。また、画像処理装置１００は、スキャナエンジン１０８、及びプリンタエンジン１０９を備え、これらはエンジンＩ／Ｆ１０７に接続されている。

ＣＰＵ１０１は、画像処理装置１００全体の制御及び演算処理等を行う。フラッシュＲＯＭ１０２は、読み出し専用メモリであり、システム起動プログラムやプリンタエンジンの制御を行うプログラムや、文字データ、文字コード情報等の記憶領域である。フラッシュＲＯＭ１０２は、通常時はＲＯＭとして動作するが、プログラムにより電気的に内部のデータの消去及び書き込みが可能である。

ＲＡＭ１０３は、使用制限のないデータ記憶領域であり、ＰＤＬデータの展開領域として使用したり、ＰＤＬデータからＤＬデータへの変換、ＤＬデータからビットマップデータへの変換など様々な処理毎にプログラムやデータがロードされ実行される。また、ＲＡＭ１０３は、時間毎、曜日毎に実行されるジョブ数を記録するデータ領域として使用される。

外部記憶装置１０４は、例えばハードディスク等により構成され、画像処理装置１００が受け付けた印刷ジョブをスプールしたり、印刷ジョブに係る印刷データ等を格納したり、作業用領域として利用されたりする。また、外部記憶装置１０４は、前述したＲＡＭ１０３上に展開されている時間毎、曜日毎に実行されるジョブ数を記録するデータをファイルとして保持し、同様に数週間分のデータをファイルとして保持する。

表示部１０５は、液晶等により構成され、表示画像を展開するＶＲＡＭを有する。表示部１０５は、画像処理装置１００の設定状態や、現在の画像処理装置１００内部の処理状態、エラー状態、ファームウェアの更新に関する予告の表示を行う。操作部１０６は、ハードキーによる操作部と、表示部１０５の表面に装着されているタッチパネルとを有する。操作部１０６は、画像処理装置１００の設定の変更を行う。

エンジンＩ／Ｆ１０７は、スキャナエンジン１０８及びプリンタエンジン１０９を制御するコマンドやデータ等のやり取りを行う。ＵＳＢデバイスＩ／Ｆ１１０は、外部ホストと接続する際に使用するＩ／Ｆであり、ＰＤＬデータの受信などに使用される。

セントロＩ／Ｆ１１１は、外部ホストと接続する際に使用するＩ／Ｆである。ネットワークＩ／Ｆ１１２は、外部ホスト、外部サーバ、又はインターネットと接続するために使用される。また、ネットワークＩ／Ｆ１１２は、外部ホストからのＰＤＬデータの受信等にも使用されると同時に、ファームウェアの送受信にも使用される。FAX Unit１１３は、ＦＡＸ送信、ＦＡＸ受信を行う際に使用する。

ＲＴＣ１１４は、内部に電池と時計機能を有しており、システムのＯＳが起動するに必要な時間機能を提供する。また、ＲＴＣ１１４は、タイマ、アラーム機能を有し、指定時間になれば割り込みを上げる。例えば、ＲＴＣ１１４は、低電力状態にあるシステムを起動するトリガーを発生させることができる。

図２及び図３は、図１の画像処理装置１００で実行されるプログラムの更新のスケジューリングを説明する図である。以下では、プログラムの一例としてファームウェアを挙げるが、他の例としてソフトウェアであっても良い。

図２において、サーバ２０１は、複数台ある画像処理装置１００の中の任意の１台であり、ここでは、サーバとしての役割を果たす。サーバ２０１は、今週のデータ２０５、先週のデータ２０６のように、数週間の曜日毎及び時間毎のジョブ数を示すデータを保持している。これらのデータは、特定の時間ごとに実行されたジョブ数を示すデータであれば、１週間毎のジョブ数を示すデータ、１日ごとのジョブ数を示すデータ、１０分ごとのジョブ数を示すデータであっても良い。

クライアント２０２〜２０３のそれぞれは、複数台ある画像処理装置１００の中の１台であり、クライアントとして動作する。クライアント２０２は、今週のデータ２０７、先週のデータ２０８のように、数週間の曜日毎及び時間毎のジョブ数を示すデータを保持している。クライアント２０３は、今週のデータ２０９、先週のデータ２１０のように、数週間の曜日毎及び時間毎のジョブ数を示すデータを保持している。

サーバ２０１、及びクライアント２０２〜２０３は、ネットワーク２１１を介して互いに接続されている。

図３において、クライアント２０４は、複数台ある画像処理装置１００の中の１台であり、クライアントとして動作する。クライアント２０４も、図２で説明した今週のデータや先週のデータのように、数週間の曜日毎及び時間毎のジョブ数を示すデータを保持している。

数週間分のジョブ総数は、サーバ及びクライアントのそれぞれが持つ数週間分のジョブ数の総和を示す。ファームウェア更新の優先順位は、数週間分のジョブ総数に基づいて決定され、ファームウェア更新のスケジューリングを行う上での優先順位を示す。

図４及び図５は、図３のサーバ２０１で実行されるファームウェア更新のスケジューリング処理のフローチャートである。サーバ２０１のＣＰＵ１０１が、図４及ぶ図５のフローチャートに基づくプログラムを実行することにより、このスケジューリング処理が行われる。

図４において、サーバ２０１は、サーバ２０１自身及びクライアント２０２〜２０４が保持している、数週間の曜日毎及び時間毎のジョブ数を示すデータを取得する（ステップＳ４０１）。次に、装置ごとに数週間分のジョブ総数を計算し、数週間分のジョブ総数が多いものから順にファームウェア更新の優先順位を決定する（ステップＳ４０２）。図３は、決定された優先順位の一例を示す。数週間分のジョブ総数が多い装置ほどユーザの使用頻度が高く、このような装置ではジョブを実行していない空き時間が少ないと考えられる。そのため、数週間分のジョブ総数の多い装置に対して優先的にファームウェア更新のスケジューリングを行う。

次に、数週間分のジョブ総数の最も多い装置（つまり、ファームウェア更新の優先順位の最も高い装置）から順にファームウェア更新のスケジューリングを行う。まず、スケジューリングの対象となる装置に関して、図６に示すように、取得した数週間の曜日毎及び時間毎のジョブ数を示すデータから曜日毎のジョブ数の総和を計算し、曜日毎のジョブ数の総和が小さい順に順番を決定する（ステップＳ４０３）。これは、ジョブ数の総和が小さい曜日ほど空き時間が多い可能性が高いためである。図６では、土曜日が最もジョブ数の総和が小さいので、順番が１となる。

ステップＳ４０３の計算の結果、ジョブ総数の少ない曜日から順に空き時間の多い時間帯を検索する。空き時間の多い時間帯を検索する曜日において、３時間連続でジョブ数が０の時間帯があるか否かを判別する（ステップＳ４０４）。３時間連続でジョブ数が０の時間帯は、図６の実線楕円で囲んだ部分である。

ステップＳ４０４の判別の結果、３時間連続でジョブ数が０の時間帯があるときは、その真ん中の時間をファームウェア更新の時間として決定し、ファームウェア更新が行われるべき曜日及び時間を登録する（ステップＳ４０６）。具体的には、図６の時間帯５０１のうち、３時をファームウェア更新の時間とし、スケジュール表における土曜日の２時（図７の６０１）に装置の名前（ＣｌｉｅｎｔＢ）を登録する。図７は、サーバ２０１が管理するスケジュール表の一例である。図７のスケジュール表において、Ｘ時とはＸ時０分からＸ時５９分までの時間を示す。なお、３時間連続でジョブ数が０の時間帯が複数存在するときは、その前後の時間のジョブ数を含むジョブ総数（それぞれの時間におけるジョブ数がｍ，０，０，０，ｎとするとｍ＋ｎ）が最小となる時間帯の真ん中の時間を選択する。

次に、複数台の装置のスケジュールを組む場合、ファームウェア更新のスケジューリングを行っていない装置があるか否かを判別する（ステップＳ４１４）。この判別の結果、ファームウェア更新のスケジューリングを行っていない装置があるときは、ステップＳ４０３に戻る。一方、ファームウェア更新のスケジューリングを行っていない装置がないときは、本処理を終了する。

ステップＳ４０４の判別の結果、３時間連続でジョブ数が０の時間帯がないときは、３時間連続でジョブ数が０の時間帯を検索していない曜日があるか否かを判別する（ステップＳ４０５）。この判別の結果、３時間連続でジョブ数が０の時間帯を検索していない曜日があるときは、ステップＳ４０４に戻り、次の曜日について３時間連続でジョブ数が０の時間帯を検索する。一方、３時間連続でジョブ数が０の時間帯を検索していない曜日がないときは、ステップＳ４０７に進む。

ステップＳ４０７では、ジョブ総数の少ない曜日から順に、２時間連続でジョブ数が０の時間帯があるか否かを判別する。２時間連続でジョブ数が０の時間帯は、図６の点線楕円で囲んだ部分である。

ステップＳ４０７の判別の結果、２時間連続でジョブ数が０の時間帯があるときは、そのいずれかの時間をファームウェア更新の時間として決定し、ファームウェア更新が行われるべき曜日及び時間を登録し（ステップＳ４０９）、ステップＳ４１４に進む。具体的には、図６に示す時間帯５０２のうち、６時をファームウェア更新の時間とし、スケジュール表における土曜日の６時に装置の名前を登録する。なお、２時間連続でジョブ数が０の時間帯が複数存在するときは、その前後の時間のジョブ数を含むジョブ総数（それぞれの時間におけるジョブ数がｍ，０，０，ｎとするとｍ＋ｎ）が最小となる時間帯のいずれかの時間を選択する。例えば、ｍ＞ｎであれば、ｎに近い方の時間をファームウェア更新の時間とし、ｍ＜＝ｎであれば、ｍに近い方の時間をファームウェア更新の時間として決定する。なお、実施の形態の場合、同じ時間帯に他の装置のスケジュールが入っていてもよいものとする。

ステップＳ４０７の判別の結果、２時間連続でジョブ数が０の時間帯がないときは、２時間連続でジョブ数が０の時間帯を検索していない曜日があるか否かを判別する（ステップＳ４０８）。この判別の結果、２時間連続でジョブ数が０の時間帯を検索していない曜日があるときは、ステップＳ４０７に戻り、次の曜日について２時間連続でジョブ数が０の時間帯を検索する。一方、２時間連続でジョブ数が０の時間帯を検索していない曜日がないときは、ステップＳ４１０に進む。

ステップＳ４１０では、ジョブ総数の少ない曜日から順に、１時間ジョブ数が０の時間があるか否かを判別する。１時間ジョブ数が０の時間は、図６の一点鎖線楕円で囲んだ部分である。

ステップＳ４１０の判別の結果、１時間ジョブ数が０の時間があるときは、その時間をファームウェア更新の時間として決定し、ファームウェア更新が行われるべき曜日及び時間を登録する（ステップＳ４１２）。具体的には、図６に示す時間帯５０３のうち、２２時をファームウェア更新の時間とし、スケジュール表における土曜日の２２時に装置の名前を登録する。なお、１時間ジョブ数が０の時間が複数存在するときは、その前後の時間のジョブ数を含むジョブ総数（それぞれの時間におけるジョブ数がｍ，０，ｎとするとｍ＋ｎ）が最小となる時間を選択する。なお、実施の形態の場合、同じ時間帯に他の装置のスケジュールが入っていてもよいものとする。

ステップＳ４１０の判別の結果、１時間ジョブ数が０の時間がないときは、１時間ジョブ数が０の時間を検索していない曜日があるか否かを判別する（ステップＳ４１１）。この判別の結果、１時間ジョブ数が０の時間を検索していない曜日があるときは、ステップＳ４１０に戻り、次の曜日について１時間ジョブ数が０の時間を検索する。一方、１時間ジョブ数が０の時間を検索していない曜日がないときは、ステップＳ４１３に進む。

ステップＳ４１３では、ジョブ総数の最も少ない曜日において、ジョブ数が最も少ない時間をファームウェア更新の時間として決定し、ファームウェア更新が行われるべき曜日及び時間を登録する。なお、最も少ないジョブ数をＸとし、ジョブ数がＸの時間が複数存在するときは、その前後の時間のジョブ数を含むジョブ総数（それぞれの時間におけるジョブ数がｍ，Ｘ，ｎとするとｍ＋ｎ）が最小となる時間を選択する。

図４及び図５のスケジューリング処理を実行すると、図８に示すように、複数台の画像処理装置のそれぞれにおけるファームウェア更新のスケジュールが決定される。なお、本実施の形態では、同じ時間に他の装置のスケジュールが入っていてもよいものとする。ただし、サーバ２０１のファームウェア更新のスケジュールだけは、クライアント２０２〜２０４のスケジュールと同じ時間にならないようにする必要がある。

図４及び図５の処理によれば、ユーザの使用頻度の低い時間帯をファームウェアの更新時間として決定するので、データ処理装置におけるプログラムの更新を実行するに当たって、ユーザの業務に与える支障を軽減することができる。

次に、図８のファームウェア更新のスケジュール表に基づいて、サーバ２０１及びクライアント２０２〜２０４のファームウェアを更新する処理を説明する。

図９は、図３のサーバ２０１及びクライアント２０２〜２０４で実行されるファームウェア更新処理を説明する図である。

図９において、サーバ２０１は、図８のスケジュール表を管理する。サーバ２０１は、ファームウェアを更新するために必要な更新ファームウェアデータをファームウェア更新の対象となるクライアント２０２〜２０４のそれぞれに送信する。更新ファームウェアデータには、新しいファームウェアのほか、ファームウェアの更新を制御するためのコマンドなども含まれる。クライアント２０２〜２０４のそれぞれは、ファームウェアの更新を終了すると、その旨をサーバ２０１に通知する。ファームウェア更新の対象がサーバ２０１である場合には、サーバ２０１自らが更新ファームウェアデータに基づいてファームウェアの更新を行う。

図１０は、クライアント２０２〜２０４のそれぞれで実行されるファームウェア更新処理のフローチャートである。クライアント２０２〜２０４のそれぞれのＣＰＵ１０１が、図１０のフローチャートに基づくプログラムを実行することにより、このファームウェア更新処理が行われる。以下では、クライアント２０２がこのファームウェア更新処理を行うものとする。

水曜日の１時になると、サーバ２０１は、図８のスケジュール表に従って、ファームウェア更新の対象となるクライアント２０２に更新ファームウェアデータを送信する。従って、クライアント２０２は更新ファームウェアデータをサーバ２０１から受信する（ステップＳ９０１）。

更新ファームウェアデータを受信したクライアント２０２は、図１１に示すように表示部１０５に、数分後にファームウェアの更新が行われるため装置が使用不能になる旨を表示する（ステップＳ９０２）。また、ユーザがクライアント２０２を使用しようとした場合には、他の画像処理装置を使用するように促す。

次に、クライアント２０２は、現在処理中のジョブがあるか否かを判別する（ステップＳ９０３）。この判別の結果、現在処理中のジョブがあるときは、このジョブが終了するまで待つ。一方、現在処理中のジョブがないときは、クライアント２０２は、ネットワーク機能をオフラインモードに移行して新規にジョブを受け付けないようにすると共に、ＦＡＸ受信を無視するようにＦＡＸ機能を手動受信モードに移行させる（ステップＳ９０４）。これにより、クライアント２０２は、新規ジョブが投入されない状態になる。

次に、クライアント２０２は、ファームウェアの更新を実行する（ステップＳ９０５）。ファームウェアの更新が正常に終了した後、クライアント２０２は、ネットワーク機能をオンラインモードに移行すると共に、ＦＡＸ受信を受け付らけれるようにＦＡＸ機能を自動受信モードに移行させる（ステップＳ９０６）。これにより、クライアント２０２は、新規ジョブを受け付けられる状態になる。

次に、クライアント２０２は、ファームウェアの更新が正常に終了した旨をサーバ２０１に通知し（ステップＳ９０７）、本処理を終了する。その旨の通知を受けたサーバ２０１は、サーバ２０１で管理するスケジュール表（例えば図８）に、ファームウェアの更新が終了した旨を記録する。
サーバ２０１がファームウェア更新の対象となる場合には、サーバ２０１はステップＳ９０２〜Ｓ９０６を実行した上で、スケジュール表（例えば図８）に、ファームウェアの更新が終了した旨を記録する。

図１０の処理によれば、ユーザの使用頻度の低い時間帯にファームウェアの更新を行うので、データ処理装置におけるプログラムの更新を実行するに当たって、ユーザの業務に与える支障を軽減することができる。

［第２の実施の形態］
第１の実施の形態では、同じ時間帯に複数の画像処理装置のファームウェア更新が可能であるとした。一方、第２の実施の形態では、ファームウェアの更新を実行する間、複数台の画像処理装置が一斉に使用できなくなるのを防止するため、同一時間帯に複数の画像処理装置のファームウェアの更新が行われないようにする。

図１２〜図１６は、第２の実施の形態のファームウェア更新のスケジューリング処理のフローチャートである。サーバ２０１のＣＰＵ１０１が、図１２〜１６のフローチャートに基づくプログラムを実行することにより、このスケジューリング処理が行われる。

図１２において、サーバ２０１は、サーバ２０１自身及びクライアント２０２〜２０４が保持している、数週間の曜日毎及び時間毎のジョブ数を示すデータを取得する（ステップＳ１１０１）。次に、装置ごとに数週間分のジョブ総数を計算し、数週間分のジョブ総数が多いものから順にファームウェア更新の優先順位を決定する（ステップＳ１１０２）。図３は、決定された優先順位の一例を示す。数週間分のジョブ総数が多い装置ほどユーザの使用頻度が高く、このような装置ではジョブを実行していない空き時間が少ないと考えられる。そのため、数週間分のジョブ総数の多い装置に対して優先的にファームウェア更新のスケジューリングを行う。

次に、数週間分のジョブ総数の最も多い装置（つまり、ファームウェア更新の優先順位の最も高い装置）から順にファームウェア更新のスケジューリングを行う。まず、スケジューリングの対象となる装置に関して、図６に示すように、取得した数週間の曜日毎及び時間毎のジョブ数を示すデータから曜日毎のジョブ数の総和を計算し、曜日毎のジョブ数の総和が小さい順に順番を決定する（ステップＳ１１０３）。これは、ジョブ数の総和が小さい曜日ほど空き時間が多い可能性が高いためである。図６では、土曜日が最もジョブ数の総和が小さいので、順番が１となる。

ステップＳ１１０３の計算の結果、ジョブ総数の少ない曜日から順に空き時間の多い時間帯を検索する。空き時間の多い時間帯を検索する曜日において、３時間連続でジョブ数が０の時間帯があるか否かを判別する（ステップＳ１１０４）。

ステップＳ１１０４の判別の結果、３時間連続でジョブ数が０の時間帯があるときは、３時間連続でジョブ数が０の時間帯が複数あるか否かを判別する（ステップＳ１１０６）。この判別の結果、３時間連続でジョブ数が０の時間帯が複数あるときは、ステップＳ１１０７に進む。ステップＳ１１０７では、３時間連続でジョブ数が０の時間帯の前後の時間のジョブ数を含むジョブ総数（それぞれの時間におけるジョブ数がｍ，０，０，０，ｎとするとｍ＋ｎ）が最小となる時間帯をファームウェア更新の時間帯の候補として選択する。その上で、その時間帯の真ん中の時間をファームウェア更新の時間の候補として選択し、ステップＳ１１０９に進む。

一方、ステップＳ１１０６の判別の結果、３時間連続でジョブ数が０の時間帯が複数ないときは、３時間連続でジョブ数が０である唯一の時間帯をファームウェア更新の時間帯の候補として選択する。その上で、その時間帯の真ん中の時間をファームウェア更新の時間の候補として選択し（ステップＳ１１０８）、ステップＳ１１０９に進む。

ステップＳ１１０９では、スケジュール表と候補の時間とを比較し、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているか否かを判別する。この判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされていないときは、候補の時間をファームウェア更新の時間として決定し、スケジュール表の該当する時間に装置の名前を登録する（ステップＳ１１１０）。

ステップＳ１１０９の判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているときは、ステップＳ１１１１に進む。ステップＳ１１１１では、ｍ＞ｎならば、ｎに近い時間をファームウェア更新の時間の候補とし、ｍ＜＝ｎならば、ｍに近い時間をファームウェア更新の時間の候補とする。

次に、スケジュール表と候補の時間とを比較し、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているか否かを判別する（ステップＳ１１１２）。この判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされていないときは、候補の時間をファームウェア更新の時間として決定し、スケジュール表の該当する時間に装置の名前を登録する（ステップＳ１１１０）。

ステップＳ１１１２の判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているときは、ステップＳ１１１３に進む。ステップＳ１１１３では、ｍ＞ｎならば、ｍに近い時間をファームウェア更新の時間帯の候補とし、ｍ＜＝ｎならば、ｎに近い時間をファームウェア更新の時間の候補とする。

次に、スケジュール表と候補の時間とを比較し、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているか否かを判別する（ステップＳ１１１４）。この判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされていないときは、候補の時間をファームウェア更新の時間として決定し、スケジュール表の該当する時間に装置の名前を登録する（ステップＳ１１１０）。

ステップＳ１１１２の判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているときは、３時間連続でジョブ数が０の時間帯が他にあるか否かを判別する（ステップＳ１１１５）。

ステップＳ１１１５の判別の結果、３時間連続でジョブ数が０の時間帯が他にあるときは、現在の候補の時間帯を選択対象から除き（ステップＳ１１１６）、ステップＳ１１０６に戻る。

ステップＳ１１１５の判別の結果、３時間連続でジョブ数が０の時間帯が他にないときは、３時間連続でジョブ数が０の時間帯を検索していない曜日があるか否かを判別する（ステップＳ１１０５）。この判別の結果、３時間連続でジョブ数が０の時間帯を検索していない曜日があるときは、ステップＳ１１０４に戻る。一方、３時間連続でジョブ数が０の時間帯を検索していない曜日がないときは、ステップＳ１１１７に進む。ステップＳ１１１７では、ジョブ総数の少ない曜日から順に、２時間連続でジョブ数が０の時間帯があるか否かを判別する。

ステップＳ１１１７の判別の結果、２時間連続でジョブ数が０の時間帯があるときは、２時間連続でジョブ数が０の時間帯が複数あるか否かを判別する（ステップＳ１１１９）。この判別の結果、２時間連続でジョブ数が０の時間帯が複数ないときは、２時間連続でジョブ数が０である唯一の時間帯をファームウェア更新の時間帯の候補として選択し、ステップＳ１１２１に進む。一方、この判別の結果、２時間連続でジョブ数が０の時間帯が複数あるときは、ステップＳ１１２０に進む。ステップＳ１１２０では、時間連続でジョブ数が０の時間帯の前後の時間のジョブ数を含むジョブ総数（それぞれの時間におけるジョブ数がｍ，０，０，ｎとするとｍ＋ｎ）が最小となる時間帯をファームウェア更新の時間帯の候補として選択する。

ステップＳ１１２１では、ｍ＞ｎならば、ｎに近い時間をファームウェア更新の時間の候補とし、ｍ＜＝ｎならば、ｍに近い時間をファームウェア更新の時間の候補とする（ステップＳ１１２１）。

次に、スケジュール表と候補の時間とを比較し、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているか否かを判別する（ステップＳ１１２２）。この判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされていないときは、候補の時間をファームウェア更新の時間として決定し、スケジュール表の該当する時間に装置の名前を登録する（ステップＳ１１２３）。

ステップＳ１１２２の判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているときは、ステップＳ１１２４に進む。ステップＳ１１２４では、ｍ＞ｎならば、ｍに近い時間をファームウェア更新の時間の候補とし、ｍ＜＝ｎならば、ｎに近い時間をファームウェア更新の時間の候補とする。

次に、スケジュール表と候補の時間とを比較し、候補の時間帯に既に他の装置装置でのファームウェア更新がスケジューリングされているか否かを判別する（ステップＳ１１２５）。この判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされていないときは、候補の時間をファームウェア更新の時間として決定し、スケジュール表の該当する時間に装置の名前を登録する（ステップＳ１１２３）。

ステップＳ１１２５の判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているときは、２時間連続でジョブ数が０の時間帯が他にあるか否かを判別する（ステップＳ１１２６）。

ステップＳ１１２６の判別の結果、２時間連続でジョブ数が０の時間帯が他にあるときは、現在の候補の時間帯を選択対象から除き（ステップＳ１１２７）、ステップＳ１１１９に戻る。

ステップＳ１１２６の判別の結果、２時間連続でジョブ数が０の時間帯が他にないときは、２時間連続でジョブ数が０の時間帯を検索していない曜日があるか否かを判別する（ステップＳ１１１８）。この判別の結果、２時間連続でジョブ数が０の時間帯を検索していない曜日があるときは、ステップＳ１１１７に戻る。一方、２時間連続でジョブ数が０の時間帯を検索していない曜日がないときは、ステップＳ１１２８に進む。ステップＳ１１２８では、ジョブ総数の少ない曜日から順に、１時間ジョブ数が０の時間があるか否かを判別する。

ステップＳ１１２８の判別の結果、１時間ジョブ数が０の時間帯があるときは、１時間ジョブ数が０の時間が複数あるか否かを判別する（ステップＳ１１３０）。この判別の結果、１時間ジョブ数が０の時間が複数あるときは、ステップＳ１１３１に進む。ステップＳ１１３１では、１時間ジョブ数が０の時間の前後の時間のジョブ数を含むジョブ総数（それぞれの時間におけるジョブ数がｍ，０，ｎとするとｍ＋ｎ）が最小となる時間をファームウェア更新の時間の候補として選択し、ステップＳ１１３３に進む。

一方、ステップＳ１１３０の判別の結果、１時間ジョブ数が０の時間が複数ないときは、１時間ジョブ数が０である唯一の時間をファームウェア更新の時間の候補として選択し（ステップＳ１１３２）、ステップＳ１１３３に進む。

次に、スケジュール表と候補の時間とを比較し、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているか否かを判別する（ステップＳ１１３３）。この判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされていないときは、候補の時間をファームウェア更新の時間として決定し、スケジュール表の該当する時間に装置の名前を登録する（ステップＳ１１３４）。

ステップＳ１１３３の判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているときは、１時間ジョブ数が０の時間が他にあるか否かを判別する（ステップＳ１１３５）。

ステップＳ１１３５の判別の結果、１時間ジョブ数が０の時間が他にあるときは、現在の候補の時間を選択対象から除き（ステップＳ１１３６）、ステップＳ１１３０に戻る。

ステップＳ１１３５の判別の結果、１時間ジョブ数が０の時間帯が他にないときは、１時間ジョブ数が０の時間帯を検索していない曜日があるか否かを判別する（ステップＳ１１２９）。この判別の結果、１時間ジョブ数が０の時間帯を検索していない曜日があるときは、ステップＳ１１２８に戻る。一方、１時間ジョブ数が０の時間帯を検索していない曜日がないときは、ジョブ総数が最も少ない曜日を選択する（ステップＳ１１３７）。

次に、選択した曜日で最小のジョブ数をＸとすると、ジョブ数がＸの時間が複数あるか否かを判別する（ステップＳ１１３８）。

この判別の結果、ジョブ数がＸの時間が複数あるときは、ステップＳ１１３９に進む。ステップＳ１１３９では、ジョブ数がＸの時間の前後の時間のジョブ数を含むジョブ総数（それぞれの時間におけるジョブ数がｍ、Ｘ，ｎとするとｍ＋ｎ）が最小となる時間をファームウェア更新の時間の候補として選択し、ステップＳ１１４１に進む。

一方、ステップＳ１１３８の判別の結果、ジョブ数がＸの時間が複数ないときは、ジョブ数がＸである唯一の時間をファームウェア更新の時間の候補として選択し（ステップＳ１１４０）、ステップＳ１１４１に進む。

次に、スケジュール表と候補の時間とを比較し、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているか否かを判別する（ステップＳ１１４１）。この判別の結果、候補の時間に既に他の装置でのファームウェアの更新がスケジューリングされていないときは、候補の時間をファームウェア更新の時間として決定し、スケジュール表の該当する時間に装置の名前を登録する（ステップＳ１１４２）。

ステップＳ１１４１の判別の結果、候補の時間に既に他の装置でのファームウェア更新がスケジューリングされているときは、ジョブ数がＸの時間帯が他にあるか否かを判別する（ステップＳ１１４３）。

ステップＳ１１４３の判別の結果、ジョブ数がＸの時間帯が他にあるときは、現在の候補の時間を選択対象から除き（ステップＳ１１４４）、ステップＳ１１３８に戻る。

ステップＳ１１４３の判別の結果、ジョブ数がＸの時間帯が他にないときは、ステップＳ１１３７またはＳ１１４６で全ての曜日が選択されたか否かを判別する（ステップＳ１１４５）。この判別の結果、全ての曜日が選択されていないときは、ジョブ総数が次に少ない曜日を選択し（ステップＳ１１４６）、ステップＳ１１３８に戻る。

一方、全ての曜日が選択されたときは、ステップＳ１１４７に進む。ステップＳ１１４７では、最初に候補となった時間をファームウェア更新の時間として決定し、スケジュール表の該当する時間に装置の名前を登録し、ステップＳ１１４８に進む。この場合は、他の装置でのファームウェアの更新と時間帯が重なってしまうことになる。

ステップＳ１１４８では、ファームウェア更新のスケジューリングを行っていない装置があるか否かを判別する。この判別の結果、ファームウェア更新のスケジューリングを行っていない装置があるときは、ステップＳ１１０３に戻る。一方、ファームウェア更新のスケジューリングを行っていない装置がないときは、本処理を終了する。

図１２〜図１６のスケジューリング処理を実行すると、図８に示すように、複数台の画像処理装置のファームウェア更新のスケジュールが決定される。なお、サーバ２０１のファームウェア更新のスケジュールだけは、クライアント２０２〜２０４のスケジュールと同じ時間にならないようにする必要がある。

図１２〜１５の処理によれば、同じ時間帯に他の装置でのファームウェア更新がスケジューリングされないようにするので、ファームウェアの更新を実行する間、複数台の画像処理装置が一斉に使用できなくなるのを防止する。

［第３の実施の形態］
第１及び第２の実施の形態では、ファームウェア更新時に処理中のジョブが存在した場合、ジョブが終了するのを待ってから、ファームウェア更新を実行した。一方、第３の実施の形態では、ファームウェア更新時に処理中のジョブが存在した場合、サーバに対してファームウェア更新の再スケジューリング依頼を行う。

図１７は、第３の実施の形態におけるファームウェア更新処理のフローチャートである。以下では、クライアント２０２がファームウェア更新の対象となっているものとする。

図１７において、ファームウェア更新の時間になると、サーバ２０１は、ファームウェア更新の対象となるクライアント２０２のステータスが“未”であるか否かを判別する（ステップＳ１２０１）。

図１８のスケジュール表では、サーバ２０１及びクライアント２０２〜２０４でのファームウェア更新の状況を知るために、ステータス欄を有する。

図４及び図５又は図１２〜図１６のスケジューリング処理でファームウェア更新のスケジュールを作成する際は、まだファームウェアの送信も更新も行われていないので、各装置のステータス欄には“未”が記載される。

図１９に示すように、未”のステータス１４０１は、まだファームウェアの送信も更新も行われていない状況を示す。

“送信済”のステータス１４０２は、装置に対して更新ファームウェアデータを送信済みである状態を示す。

“済”のステータス１４０３は、装置に対して更新ファームウェアデータの送信も終了し、ファームウェアの更新も正常に終了した状態を示す。

ステップＳ１２０１の判別の結果、クライアント２０２のステータスが“未”であるときは、ステップＳ１２０３に進む。一方、クライアント２０２のステータスが“未”でないときは、サーバ２０１はクライアント２０２のステータスが“送信済”であるか否かを判別する（ステップＳ１２０２）。

ステップＳ１２０２の判別の結果、クライアント２０２のステータスが“送信済”であるときは、ステップＳ１２０５に進む。一方、クライアント２０２のステータスが“送信済”でないときは、ステータスは“済”であるということを意味するので、本処理を終了する。

ステップＳ１２０３では、サーバ２０１は、クライアント２０２に更新ファームウェアデータを送信する。送信が終了すると、サーバ２０１は、図１８のスケジュール表におけるクライアント２０２に対応するステータス欄に“送信済”と記載する（ステップＳ１２０４）。

更新ファームウェアデータを受信したクライアント２０２は、図１１に示すように表示部１０５に、数分後にファームウェアの更新が行われるため装置が使用不能になる旨を表示する（ステップＳ１２０５）。これにより、ユーザにファームウェアの更新作業に自動的に入ることを通知する。

次に、クライアント２０２は、現在処理中のジョブがあるか否かを判別する（ステップＳ１２０６）。この判別の結果、現在処理中のジョブがあるときは、クライアント２０２は、サーバ２０１にファームウェア更新の再スケジューリングを依頼する（ステップＳ１２０７）。この際、サーバ２０１への通知方法は、メール、又はSocket通信を伴ったハンドシェイクされた通信等、特に手段を問わない。これにより、サーバ２０１は、後述する図２０の再スケジューリング処理を実行して、ファームウェア更新の再スケジューリングを行う。

次に、クライアント２０２は、ステップＳ１２０５で行ったファームウェアの更新のため装置が使用不能になる旨の表示を消す（ステップＳ１２０８）。

一方、ステップＳ１２０６の判別の結果、現在処理中のジョブがないときは、ステップＳ１２１０に進む。ステップＳ１２１０では、クライアント２０２は、ネットワーク機能をオフラインモードに移行して新規にジョブを受け付けないようにすると共に、ＦＡＸ受信を無視するようにＦＡＸ機能を手動受信モードに移行させる。これにより、クライアント２０２は、新規ジョブが投入されない状態になる。

次に、クライアント２０２は、ファームウェアの更新を実行する（ステップＳ１２１１）。ファームウェアの更新が正常に終了した後、クライアント２０２は、ネットワーク機能をオンラインモードに移行すると共に、ＦＡＸ受信を受け付らけれるようにＦＡＸ機能を自動受信モードに移行させる（ステップＳ１２１２）。これにより、クライアント２０２は、新規ジョブを受け付けられる状態になる。

次に、クライアント２０２は、ファームウェアの更新が正常に終了した旨をサーバ２０１に通知する（ステップＳ１２１３）。その旨が通知されたサーバ２０１は、サーバ２０１で管理するスケジュール表におけるクライアント２０２に対応するステータス欄に“済”と記載し（ステップＳ１２１４）、本処理を終了する。

図１９の処理によれば、ファームウェア更新をしようとする時に処理中のジョブが存在した場合、サーバに対してファームウェア更新の再スケジューリングを依頼するので、データ処理装置におけるプログラムの更新を実行するに当たって、ユーザの業務に与える支障を軽減することができる。
サーバ２０１がファームウェア更新の対象となる場合には、サーバ２０１はＳ１２０１〜Ｓ１２０２、Ｓ１２０４〜Ｓ１２０８、Ｓ１２１０〜Ｓ１２１２及びＳ１２１４を実行する。

図２０は、サーバ２０１によって実行される再スケジューリング処理のフローチャートである。サーバ２０１のＣＰＵ１０１が、図２０のフローチャートに基づくプログラムを実行することにより、この再スケジューリング処理が行われる。以下でも、クライアント２０２がファームウェア更新の対象となっているものとする。

図２０において、サーバ２０１は、再スケジューリングの依頼をクライアント２０２から受けると、図１８のスケジュール表に基づいて、ステータスが“未”又は“送信済”となっている装置のみをピックアップする（ステップＳ１５０１）。既にステータスが“済”となっている装置は、ファームウェア更新が終了しているので、再スケジューリングの対象としない。

次に、サーバ２０１は、ステップＳ１５０１でピックアップした装置が保持している最新の数週間の曜日毎及び時間毎のジョブ数を示すデータを取得しなおす（ステップＳ１５０２）。

次に、取得した数週間の曜日毎及び時間毎のジョブ数を示すデータに基づいて、図４及び図５又は図１２〜図１６のスケジューリング処理を実行して、ファームウェア更新の再スケジューリングを行い（ステップＳ１５０３）、本処理を終了する。これにより、最新の状況で、スケジュール表を作成しなおす。

図２０の処理によれば、ファームウェアの更新をしようとした時に処理中のジョブが存在した場合、ファームウェア更新の再スケジューリングが自動的に行われるので、データ処理装置におけるプログラムの更新を実行するに当たって、ユーザの業務に与える支障を軽減することができる。

［第４の実施の形態］
第１〜第３の実施の形態では、ファームウェア更新のスケジュールは、ユーザの使用頻度の低い時間帯を元に作成されている。このため、ファームウェア更新の時間には、画像処理装置が長時間使用されていないことにより、消費電力の低いスリープ状態に画像処理装置が移行している可能性が高い。またサーバ２０１も長時間使用されてないことにより、消費電力の低いスリープ状態にサーバ２０１が移行している可能性が高い。そこで、第４の実施の形態は、サーバ２０１又はクライアント２０２〜２０４において、スリープ状態から復帰する処理を行う。

図２１は、クライアント２０２〜２０４のスリープ復帰処理のフローチャートである。クライアント２０２〜２０４のそれぞれのＣＰＵ１０１が、図２１のフローチャートに基づくプログラムを実行することにより、このスリープ復帰処理が行われる。

図８や図１８のスケジュール表が作成されると、サーバ２０１は、図８や図１８のスケジュール表に基づいて、ファームウェア更新の対象となるクライアントにファームウェア更新日時を通知する。従って、クライアントは、ファームウェア更新日時の通知をサーバ２０１から受ける（ステップＳ１６０２）。この際、サーバ２０１からの通知方法は、メール、又はＰｏｒｔを特定してSocket通信によるデータの通知等、特に手段を問わない。

サーバ２０１からファームウェア更新日時を通知されたクライアントは、「ファームウェア更新日時−α」の日時をＲＡＭ１０３等に記憶する（ステップＳ１６０３）。ここで−αとしたのは、クライアントがスリープしていた場合、スリープ復帰に時間がかかる場合を想定しているためである。

ステップＳ１６０４では、クライアントがスリープ状態に移行するか否かを判別する。即ち、ユーザの処理又はジョブの投入が規定時間の間なかった場合に消費電力の低いスリープ状態に移行する設定が各クライアントにあり、各クライアントではその規定時間が設定可能である。従って、クライアントは、その規定時間の間、放置されているか否かを判別する。

この判別の結果、クライアントがスリープ状態に移行しないときは、クライアントは、ファームウェア更新日時になったか否かを判別する（ステップＳ１６０５）。この判別の結果、ファームウェア更新日時になっていないときは、ステップＳ１６０４に戻る。一方、ファームウェア更新日時になったときは、本処理を終了する。本処理が終了した後には、ファームウェア更新処理が実行される。

ステップＳ１６０４の判別の結果、クライアントがスリープ状態に移行するときは、クライアントは、ステップＳ１６０３でＲＡＭ１０３に記憶していた「ファームウェア更新日時−α」の日時をＲＴＣ１１４のアラーム時刻に設定してスリープ状態に移行する（ステップＳ１６０６）。

次に、クライアントは、ユーザによりスリープ状態から復帰させられるか否かを判別する（ステップＳ１６０７）。この判別の結果、ユーザによりスリープ状態から復帰させられるときは、クライアントはスリープ状態から復帰し（ステップＳ１６１１）、ステップＳ１６０４に戻る。

ステップＳ１６０７の判別の結果、ユーザによりスリープ状態から復帰させられなかったときは、クライアントは、ＲＴＣ１１４から割り込み信号が送信されたか否かを判別する（ステップＳ１６０８）。アラーム時刻になったときは、ＲＴＣ１１４がハードウェア的に割り込み信号を送信する。

ＲＴＣ１１４から割り込み信号が送信されたときは、ＣＰＵ１０１に対してReset解除信号が送信され、クライアントは、スリープ状態から復帰し（ステップＳ１６１０）、本処理を終了する。本処理が終了した後には、ファームウェア更新処理が実行される。

図２１の処理によれば、ファームウェアの更新が行われようとする時にクライアント２０２〜２０４がスリープ状態に移行している場合にも、ファームウェアの更新処理を実行することができる。

図２２は、サーバ２０１のスリープ復帰処理のフローチャートである。サーバ２０１のＣＰＵ１０１が、図２２のフローチャートに基づくプログラムを実行することにより、このスリープ復帰処理が行われる。

図８や図１８のスケジュール表が作成されると、サーバ２０１は、図８や図１８のスケジュール表に基づいて、現在時刻に最も時間の近いファームウェア更新日時を検出する（ステップＳ１７０１）。サーバ２０１は、ステップＳ１７０１で検出した「現在時刻に最も近いファームウェア更新日時−α」の日時をＲＡＭ１０３等に記憶する（ステップＳ１７０２）。ここで−αとしたのは、サーバ２０１がスリープしていた場合、スリープ復帰に時間がかかる場合を想定しているためである。

ステップＳ１７０４では、サーバ２０１がスリープ状態に移行するか否かを判別する。即ち、ユーザの処理又はジョブの投入が規定時間の間なかった場合に消費電力の低いスリープ状態に移行する設定がサーバ２０１にあり、サーバ２０１ではその規定時間が設定可能である。従って、サーバ２０１は、その規定時間の間、放置されているか否かを判別する。

この判別の結果、サーバ２０１がスリープ状態に移行しないときは、サーバ２０１は、ステップＳ１７０１で検出したファームウェア更新日時になったか否かを判別する（ステップＳ１７０５）。この判別の結果、ステップＳ１７０１で検出したファームウェア更新日時になっていないときは、ステップＳ１７０４に戻る。一方、ステップＳ１７０１で検出したファームウェア更新日時になったときは、本処理を終了する。本処理が終了した後には、ファームウェア更新処理が実行される。

ステップＳ１７０４の判別の結果、サーバ２０１がスリープ状態に移行するときは、サーバ２０１は、ステップＳ１６０３でＲＡＭ１０３に記憶していた「現在時刻に最も近いファームウェア更新日時−α」の日時をＲＴＣ１１４のアラーム時刻に設定してスリープ状態に移行する（ステップＳ１７０６）。

次に、サーバ２０１は、ユーザによりスリープ状態から復帰させられるか否かを判別する（ステップＳ１７０７）。この判別の結果、ユーザによりスリープ状態から復帰させられるときは、サーバ２０１はスリープ状態から復帰し（ステップＳ１７１１）、ステップＳ１７０４に戻る。

ステップＳ１７０７の判別の結果、ユーザによりスリープ状態から復帰させられなかったときは、サーバ２０１は、ＲＴＣ１１４から割り込み信号が送信されたか否かを判別する（ステップＳ１７０８）。アラーム時刻になったときは、ＲＴＣ１１４がハードウェア的に割り込み信号を送信する（ステップＳ１７０９）。

ＲＴＣ１１４から割り込み信号が送信されたときは、ＣＰＵ１０１に対してReset解除信号が送信され、サーバ２０１は、スリープ状態から復帰し（ステップＳ１７１０）、本処理を終了する。本処理が終了した後には、ファームウェア更新処理が実行される。

図２１の処理によれば、ファームウェアの更新が行われようとする時にサーバ２０１がスリープ状態に移行している場合にも、ファームウェアの更新処理を実行することができる。

上記の実施の形態で説明した処理、機能等は、いずれもコンピュータ読み取り可能なプログラム等で実現することもできる。

この場合、上記の実施の形態で説明した処理、機能等は、システム又は装置に含まれるコンピュータ（ＣＰＵ、ＭＰＵ等でもよい）が上記のプログラム等を実行することによって実現されることになる。言い換えれば、上記のプログラム等が、システム又は装置に含まれるコンピュータに、上記の実施の形態で説明した処理、機能等を実行させることになる。また、この場合、上記のプログラム等は、コンピュータ読み取り可能な記憶媒体又はネットワークを介してシステム又は装置に含まれるコンピュータに提供されることになる。

システム又は装置に含まれるコンピュータに上記のプログラム等を提供する記憶媒体には、磁気ディスク、光ディスク、光磁気ディスク、ハードディスク、磁気テープ、不揮発性メモリ等を用いることができる。

また、上記のプログラム等は、その一部をコンピュータ上で稼動しているＯＳ（オペレーティングシステム）等を用いて構成してもよい。

さらに、上記のプログラム等は、その一部をコンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットで実行するように構成してもよい。

第１の実施の形態に係るサーバ装置を含むデータ処理装置の内部構成を示すブロック図である。図１の画像処理装置１００で実行されるプログラムの更新のスケジューリングを説明する図である。図１の画像処理装置１００で実行されるプログラムの更新のスケジューリングを説明する図である。図３のサーバ２０１で実行されるファームウェア更新のスケジューリング処理のフローチャートである。図３のサーバ２０１で実行されるファームウェア更新のスケジューリング処理のフローチャートである。図４のステップＳ４０３で用いる数週間の曜日毎及び時間毎のジョブ数を示すデータを示す図である。図５のステップＳ４０６で用いるファームウェア更新のスケジュール表を示す図である。図４及び図５のスケジューリング処理によって作成されるファームウェア更新のスケジュール表を示す図である。図３のサーバ２０１及びクライアント２０２〜２０４で実行されるファームウェア更新処理を説明する図である。図３のサーバ２０１及びクライアント２０２〜２０４で実行されるファームウェア更新処理のフローチャートである。図１０のステップＳ９０２で表示される装置が使用不能になる旨の表示を示す図である。第２の実施の形態のファームウェア更新のスケジューリング処理のフローチャートである。第２の実施の形態のファームウェア更新のスケジューリング処理のフローチャートである。第２の実施の形態のファームウェア更新のスケジューリング処理のフローチャートである。第２の実施の形態のファームウェア更新のスケジューリング処理のフローチャートである。第２の実施の形態のファームウェア更新のスケジューリング処理のフローチャートである。第３の実施の形態におけるファームウェア更新処理のフローチャートである。図１７のファームウェア更新処理で用いられるファームウェア更新のスケジュール表を示す図である。図１８のスケジュール表におけるステータス欄を説明する図である。サーバ２０１によって実行される再スケジューリング処理のフローチャートである。クライアント２０２〜２０４のスリープ復帰処理のフローチャートである。サーバ２０１のスリープ復帰処理のフローチャートである。

符号の説明

１０１ＣＰＵ
１０２フラッシュＲＯＭ
１０３ＲＡＭ
１０４外部記憶装置
１０５表示部
１０６操作部
１１４ＲＴＣ

Claims

ジョブを実行する複数のクライアント装置にプログラムを送信し、前記複数のクライアント装置にプログラムを更新させるサーバ装置であって、
前記クライアント装置によって複数の期間の各々で実行されたジョブの実行状況を示す実行状況データを前記複数のクライアント装置の各々から取得する取得手段と、
前記取得手段により取得された複数の前記実行状況データに基づいて、前記複数のクライアント装置の各々がプログラムを更新する更新期間をジョブの実行頻度の高いクライアント装置から優先的に決定する決定手段とを備え、
前記決定手段は、前記複数のクライアント装置に含まれる特定のクライアント装置の前記更新期間を決定する際に、前記取得手段により取得された前記特定のクライアント装置の実行状況データに基づいて前記複数の期間の中から前記特定のクライアント装置におけるジョブの実行回数が最も少ない期間を検出し、前記検出した期間が単数である場合は前記検出した期間を前記特定のクライアント装置の前記更新期間として決定する一方で前記検出した期間が複数である場合は前記検出した期間に隣接する期間におけるジョブの実行回数が最も少ない期間を前記特定のクライアント装置の前記更新期間として決定するとともに、前記特定のクライアント装置がプログラムを更新する更新期間が前記複数のクライアント装置に含まれる他のクライアント装置がプログラムを更新する更新期間として決定済みである場合は、前記特定のクライアント装置がプログラムを更新する更新期間を前記決定済みの更新期間と異ならせることを特徴とするサーバ装置。
前記決定手段により決定された前記更新期間に従って、前記クライアント装置におけるプログラムの更新に必要なデータを送信する送信手段を有することを特徴とする請求項１に記載のサーバ装置。
前記実行状況データは、前記クライアント装置によって複数の期間の各々で実行されたジョブの数を示し、
前記決定手段は、前記複数のクライアント装置の各々がプログラムを更新する前記更新期間を前記複数の期間の全期間にわたって実行されたジョブの総数が多いクライアント装置から優先的に決定することを特徴とする請求項１又は２に記載のサーバ装置。