JP2014075048A - 配信システム、情報処理方法及びプログラム - Google Patents

Abstract

【課題】予約時間内にファームウェアのアップデートを完了する。
【解決手段】画像形成装置にファームウェアを配信する際の配信スケジュールを登録し、ファームウェアのサイズと、ネットワーク環境情報とに基づき、画像形成装置にファームウェアを配信するのに要すると想定される配信想定時間を取得し、ファームウェアを配信した際の配信時間と、配信想定時間との差が閾値以内であるか否かを判断し、閾値以内であると判断した場合、画像形成装置からの配信情報要求に対して登録している配信スケジュールを応答し、ファームウェアの配信要求に対してファームウェアについての情報を応答し、閾値以内でないと判断した場合、ファームウェアを配信した際の配信時間に基づいて再スケジュールした配信スケジュールと、画像形成装置に配信スケジュールの定期的な問い合わせを行わせる指示とを応答することで課題を解決する。
【選択図】図１７

Description

本発明は、配信システム、情報処理方法及びプログラムに関する。

従来、画像形成装置のファームウェアのアップデートは、機能アップ又は障害等の理由により更新する必要が生じた場合に行われる。アップデート方法として、ユーザは、インターネット経由で配信サーバからファームウェアを配信しアップデートを行うか、ＵＳＢ経由／イントラネット経由のアップデートツールを使用することでアップデートを行う。
配信サーバで画像形成装置のファームウェアのアップデートを行う場合、ユーザは、Ｗｅｂ画面で配信対象の画像形成装置を指定し、配信日時を設定して、インターネット経由で配信を行う。
最近では、配信サーバにおいて、データ配信時間に許容時間を設けて配信を行うシステムが提案されている（特許文献１）。特許文献１の技術は、データ配信スケジュールの管理を行う管理サーバと、管理サーバからの指示によりデータ配信を行い、データ配信が完了すると配信結果を管理サーバに返す配信サーバとから構成されるサーバシステムを有している。
前記管理サーバは、配信開始、終了の時刻と共に指定時刻前後の配信の許容時間に関する情報（配信開始遅延許容時間、配信終了遅延許容時間、先行配信許容時間）を事前に設定し、データ配信時には、指定時刻前の先行配信を許容する。前記管理サーバは、直前のデータ配信が長引いた場合には、データ配信開始の遅延を許容することにより、データ配信時間の変動に対して柔軟な配信スケジュール管理を実現する。

特開２０００−１２２９５３号公報

配信サーバによるインターネットでのファームウェア配信では、ユーザは、配信予約時間を配信サーバのＷｅｂ画面から設定可能である。その際、配信サーバは、顧客の業務時間や、ネットワーク環境を考慮することなく、配信予約を受け付けている。そのため、配信サーバを使用して、ファームウェアの大量配信を行った場合、想定時間内にファームウェアのアップデートが完了せず、顧客の業務時間にアップデートを行ってしまう場合がある。大手顧客の場合、配信サーバから数万台の画像形成装置に対して一括で大量配信するケースがあるため、顧客の業務時間にアップデートされることを防ぎたいという要望がある。また、ネットワーク回線の弱い地域の場合、ファームウェアのダウンロードに時間を要するため、その間に顧客のネットワーク帯域を占有してしまうという課題がある。例えば、アジア地域の場合、数百ＭＢのファームウェアのダウンロードに数日を要する顧客が存在する。
以上、配信予約時間内にファームウェアのアップデートを完了することができない場合があることが課題である。

そこで、本発明は、ネットワークを介して通信可能な少なくとも１台以上の画像形成装置にファームウェアを配信する際の配信スケジュールを登録する登録手段と、前記ファームウェアのサイズと、ネットワーク環境情報とに基づいて、配信対象の前記画像形成装置に対して前記ファームウェアを配信するのに要すると想定される配信想定時間を取得する取得手段と、前記ファームウェアを配信した際の配信時間と、前記取得手段により取得された前記配信想定時間との差が、閾値以内であるか否かを判断する判断手段と、前記判断手段により閾値以内であると判断された場合、前記画像形成装置からの配信情報要求に対して、前記登録手段により登録されている配信スケジュールを応答する第１の応答手段と、前記画像形成装置からのファームウェアの配信要求に対して、ファームウェアについての情報を応答する第２の応答手段と、を有し、前記第１の応答手段は、前記判断手段により閾値以内でないと判断された場合、前記画像形成装置からの要求に対して、前記ファームウェアを配信した際の配信時間に基づいて再スケジュールされた配信スケジュールと、前記画像形成装置に配信スケジュールの定期的な問い合わせを行わせる指示とを応答することを特徴とする。

本発明によれば、配信予約時間内にファームウェアのアップデートを完了することができる。

ファームウェア配信システムのシステム構成の一例を示す図である。 配信サーバ等のハードウェア構成の一例を示す図である。 画像形成装置のハードウェア構成の一例を示す図である。 画像形成装置のクライアントモジュールの一例を示す図である。 監視センタホスト、配信サーバのソフトウェア構成の一例を示す図である。 監視装置、画像形成装置のソフトウェア構成の一例を示す図である。 メモリマップの構造の一例を示す図である。 配信サーバによるファームウェアの配信概念の一例を示す図である。 配信日が入力された配信サーバの配信画面の一例を示す図である。 配信可能曜日が入力された配信サーバの配信画面の一例を示す図である。 ファームウェアの配信内容、前倒し処理、後倒し処理の一例を示す図である。 配信サーバと、画像形成装置との通信テストログの一例を示す図である。 機種マスタの一例を示す図である。 顧客マスタの一例を示す図である。 クラインアントモジュールと配信サーバとの通信シーケンスの一例を示す図である。 配信結果等が記された配信スケジュールの一例を示す図である。 ポーリング間隔等が記された配信スケジュールの一例を示す図である。 配信サーバによる配信予約受け付け処理の一例を示すフローチャートである。 配信に関する登録データの一例を示す図である。 配信予約情報の一例を示す図である。 配信サーバによる配信の前倒し、後ろ倒し処理の一例を示すフローチャートである。 配信サーバによるポーリング及び配信処理の一例を示すフローチャートである。 クライアントモジュールによる処理の一例を示すフローチャートである。 通信テストのシーケンスの一例を示す図である。 配信サーバによる１：００〜４：００での再計算処理の一例を示す図である。 配信サーバによる５：００〜６：００での再計算処理の一例を示す図である。

以下、本発明の実施形態について図面に基づき説明する。

＜実施形態１＞
図１は、本実施形態におけるファームウェア配信システムのシステム構成の一例を示す図である。
図１において、本システムは、操作システム１０１を始めとするネットワークを介して通信可能な複数のシステムを含む。
操作システム１０１は、ホスト１０２と、データベース１０３と、データベース１０３へのデータ登録や修正等の制御を行なうＰＣ１０４とを含む。なお、本実施形態を含む以下の実施形態では、複数のデータのみならず、複数のデータを記憶するＨＤＤ等の記憶装置のことを含めてデータベースという。
ＰＣ１０４は、監視センタホスト１１１及び配信サーバ１３３が提供するＷｅｂサイトへアクセスしてデータの閲覧及びファームウェアの配信予約等を行う。
ホスト１０２、データベース１０３及びＰＣ１０４は、ＬＡＮ１０５で接続されている。なお、本実施形態における操作システム１０１は、複数の装置から構成されているが、後述する各機能を達成すれば他の構成でもよい。例えば、データベース１０３は、物理的にホスト１０２内に存在してもよい。また、データベース１０３は、ホスト１０２からアクセス可能であれば、インターネットを経由した別の場所に存在してもよい。つまり、操作システム１０１は、複数の装置から構成されるようにしてもよいし、１つの装置から構成されるようにしてもよい。
外部システム１０６は、ＬＡＮ１０９で接続されているホスト１０７（以後、外部サーバ１０７という）と、データベース１０８とを含む。外部システム１０６は、配信サーバのファームウェアを高速に配信するためサービス機能を持つ。

次に、監視センタホスト１１１について説明する。
データベース１１２は、監視のための情報や、少なくとも１台以上の画像形成装置の稼働状態等の情報を蓄積する。
監視センタホスト１１１と、データベース１１２とは、インターネットに接続可能なＬＡＮ１１３で接続されている。なお、データベース１１２は、物理的に監視センタホスト１１１内に存在してもよい。また、データベース１１２は、監視センタホスト１１１からアクセス可能であれば、インターネットを経由した別の場所に存在してもよい。
監視センタホスト１１１は、監視装置１１７、１２２、１２３及び１３１から監視対象としての画像形成装置の情報や稼働状態等の情報を収集、蓄積、加工し、警告等を外部に提供する機能を有する。

次に、配信サーバ１３３について説明する。
データベース１３４は、画像形成装置に適用するためのファームウェアを蓄積する。
配信サーバ１３３と、データベース１３４とは、インターネットに接続可能なＬＡＮ１３５で接続されている。なお、データベース１３４は、物理的に配信サーバ１３３内に存在してもよい。また、データベース１３４は、配信サーバ１３３からアクセス可能であれば、インターネットを経由した別の場所に存在してもよい。なお、ＬＡＮ１１３と、ＬＡＮ１３５とは、同一のＬＡＮであってもよい。また、データベース１３４と、データベース１１２とは、データを共有してもよい。
図１は、監視センタホスト１１１、データベース１１２、配信サーバ１３３及びデータベース１３４を、１つずつ示している。しかし、実際には、操作システム１０１は、多くの画像形成装置及び監視装置からの情報収集や、ファームウェア配信の負荷分散を行なうため、複数の監視センタホスト、データベースに分散処理をさせるシステムとしてもよい。

次に、顧客側のシステム構成について説明する。
顧客側の環境は、異なる複数のシステムを含む。
図１では、顧客システム１１４、１１９、１２９を示している。
顧客システム１１４（Ａ社Ｘ事業所）では、監視装置１１７が、インターネットに接続されたＬＡＮ１１８に接続されている画像形成装置１１５及び１１６を管理している。なお、監視装置１１７は、インターネット経由で監視センタホスト１１１と通信している。
顧客システム１１９（Ａ社Ｙ事業所）では、監視装置１２２及び１２３が、インターネットに接続されたＬＡＮ１２８上の画像形成装置を管理している。なお、監視装置１２２は、画像形成装置１２０、１２１、１２４及び１２５を管理している。一方、監視装置１２３は、画像形成装置１２６及び１２７を管理している。
顧客システム１２９（Ｂ社）では、インターネットに接続されたＬＡＮ１３０上の画像形成装置１３１自身が、直接インターネット経由で監視センタホスト１１１と通信している。画像形成装置１３１は、監視装置１１７、１２２及び１２３と同等の機能を有しており、自身の稼働情報を監視センタホスト１１１に送信する。

＜ハードウェア構成＞
図２は、監視センタホスト１１１及び配信サーバ１３３のハードウェア構成の一例を示す図である。なお、図２は、ホスト１０２、監視装置１１７、１２２、１２３及びＰＣ１０４のハードウェア構成図にも該当する。
ＣＰＵ２０１は、ＨＤＤ２０４等に格納されているプログラムに基づいて処理を実行することにより、後述する配信サーバ１３３の機能（ソフトウェアの機能）及び配信サーバ１３３に関するフローチャートに係る処理を実現する。なお、上記のＣＰＵ２０１による処理については、監視センタホスト１１１、ホスト１０２、監視装置１１７、１２２、１２３及びＰＣ１０４の場合においても同様である。
書換え不可能なＲＯＭ２０２は、本装置の各処理に関するプログラム、データを記憶する。
ＲＡＭ２０３は、本装置の各処理に関する一時的なデータを電気的に記憶でき、かつ、書き換え可能なメモリである。
ＨＤＤ２０４は、本装置の各処理に関するプログラムやデータ、一時的なデータ、監視対象の画像形成装置に関する情報及び画像形成装置から収集した情報等を記憶する。例えば、ＨＤＤ２０４は、稼働情報等を記憶する。
操作部２０５は、本装置への指示入力を受け付けるキーボード等である。
表示部２０６は、本装置の動作状況や、ＣＰＵ２０１が本装置上で動作する各プログラムを実行することにより出力する情報等を表示する。
外部機器Ｉ／Ｆ２０７は、本装置と、外部記憶機器等とを接続するインターフェースである。
以上の各構成要素は、システムバス２０９により相互に接続され、データのやりとりをする。
ＮｅｔｗｏｒｋＩ／Ｆ２０８は、本装置をネットワーク経由でＬＡＮ及びインターネットに接続し、外部と情報交換を行う。

図３は、画像形成装置１１５、１１６、１２０、１２１、１２４、１２５、１２６、１２７及び１３１におけるハードウェア構成の一例を示す図である。
より具体的には、画像形成装置の一例として、プリンタ及びファクシミリ機能が統合的に設けられた複合機、ＰＣ等からデータを受信し印刷するプリンタ（電子写真方式及びインクジェット方式を含む）、スキャナー、ファクシミリ等が挙げられる。図３では、画像形成装置の一例である複合機の構成を示している。
ＣＰＵ３０６は、ＨＤＤ３０９等に格納されているプログラムに基づいて処理を実行することにより、後述する画像形成装置の機能（ソフトウェアの機能）及び画像形成装置に関するフローチャートに係る処理を実現する。また、ＣＰＵ３０６は、画像形成装置の動作状態を監視し、障害等の特定のイベントが発生した場合には、その状態を示す状態情報を、予め定めた宛先へ送信する。宛先とは、例えば、監視センタホスト１１１や監視装置等である。
イメージリーダ３０２は、原稿給送部３０１で原稿を読み込む。
画像形成部３０３は、イメージリーダ３０２で読み込んだ原稿やネットワーク経由で受信したデータを印刷画像に変換及び印刷出力する。
排紙部３０４は、印刷出力した紙を排出し、ソートやステイプルといった処理をする。
ＮｅｔｗｏｒｋＩ／Ｆ３０５は、ネットワーク経由でＬＡＮ及びインターネットに接続し、外部と情報交換を行う。
ＲＯＭ３０７は、本装置の各処理に関するプログラムやデータを記憶する。
書き換え可能なＲＡＭ３０８は、本装置の各処理に関する一時的なデータを電気的に記憶する。
ＨＤＤ３０９は、本装置の各処理に関するプログラムやデータ、一時的なデータ及び本装置へ送信されてきたユーザデータ等を記憶する。
操作部３１０は、本装置への指示入力を受け付ける。
表示部３１１は、本装置の動作状況及び操作部３１０に対する操作に関する情報を表示する。
以上の各構成要素は、システムバス３１２により相互に接続され、データのやりとりをする。
なお、画像形成装置自身が監視のための情報を送信する機能を持つ画像形成装置１３１は、ＲＯＭ３０７又はＨＤＤ３０９内に監視データ送信処理に関するプログラムやデータ等を保持している。
図４に示されるクライアントモジュール３１３は、画像形成装置内のモジュールである。クライアントモジュール３１３は、配信サーバ１３３からファームウェアをダウンロードし、画像形成装置にインストールする。また、ＣＰＵ３０６が、ＨＤＤ３０９に記憶されたクライアントモジュール３１３のプログラムを実行することによって、クライアントモジュール３１３が実現される。

図５は、監視センタホスト１１１及び配信サーバ１３３における通信部分のソフトウェア構成の一例を示す図である。
ＳＯＡＰ通信部４０１は、監視装置１１７、１２２、１２３又は画像形成装置１３１よりＮｅｔｗｏｒｋＩ／Ｆ２０８を介して受信したＳＯＡＰデータを、ＳＯＡＰメッセージ解析部４０２に送信する。また、ＳＯＡＰ通信部４０１は、ＳＯＡＰメッセージ作成部４０３で作成されたＳＯＡＰデータをＮｅｔｗｏｒｋＩ／Ｆ２０８を介して監視装置１１７、１２２、１２３又は画像形成装置１３１に送信する。
収集情報処理部４０４は、監視装置１１７、１２２、１２３又は画像形成装置１３１から受信した情報を、そのまま又は加工した状態で、データベースアクセス部４０６を介してデータベース１１２又はデータベース１３４に格納する。
監視センタホスト１１１における監視制御部４０５は、監視装置１１７、１２２、１２３又は画像形成装置１３１のスケジュール管理等の制御を行なう。配信サーバ１３３における監視制御部４０５は、監視装置１１７、１２２、１２３又は画像形成装置１３１のポーリング処理等の制御を行う。

図６は、監視装置１１７、１２２、１２３又は画像形成装置１３１における通信部分のソフトウェア構成の一例を示す図である。
ＳＯＡＰ通信部５０１は、監視センタホスト１１１又は配信サーバ１３３からＮｅｔｗｏｒｋＩ／Ｆ２０８を介して受信したＳＯＡＰデータを、ＳＯＡＰメッセージ解析部５０３に送信する。また、ＳＯＡＰ通信部５０１は、ＳＯＡＰメッセージ作成部５０２で作成されたＳＯＡＰデータをＮｅｔｗｏｒｋＩ／Ｆ２０８を介して監視センタホスト１１１又は配信サーバ１３３に送信する。
監視制御部５０４は、情報蓄積部で保持されている監視画像形成装置の情報の更新や、画像形成装置１１５、１１６の情報取得等を行なう。
デバイス情報処理部５０５は、画像形成装置の稼働情報を情報蓄積部５０６に蓄積する。
情報蓄積部５０６は、蓄積したデータを、デバイス情報処理部５０５を介してそのままＳＯＡＰメッセージ作成部５０２に送信する。また、ＳＯＡＰメッセージ作成部５０２は、デバイス情報処理部５０５を介して情報蓄積部５０６から受信したデータをＳＯＡＰ通信部５０１と、ＮｅｔｗｏｒｋＩ／Ｆ２０８とを介して監視センタホスト１１１、配信サーバ１３３へ送信する。

図７は、監視センタホスト１１１、配信サーバ１３３、監視装置１１７、１２２、１２３又は各画像形成装置におけるメモリマップの構造の一例を示す図である。
より具体的には、図７は、監視センタホスト１１１、配信サーバ１３３、監視装置１１７、１２２、１２３のＣＰＵ２０１がプログラムを実行する際に、ＲＡＭ２０３上にプログラムをロードしたメモリマップの構造の一例を示す図である。また、同様に、図７は、各画像形成装置のＣＰＵ３０６がプログラムを実行する際に、ＲＡＭ３０８上にプログラムをロードしたメモリマップの構造の一例を示す図である。
本実施形態におけるメモリマップは、基本Ｉ／Ｏプログラム６０１、システム・プログラム６０２、本実施形態のプログラムを初めとする各種処理プログラム６０３、関連データを格納するエリア６０４及びプログラムのワークエリア６０５を含む。
基本Ｉ／Ｏプログラム６０１は、本装置上の入出力を司る。
システム・プログラム６０２は、各処理プログラムに動作環境を提供する。

図８は、配信サーバ１３３によるファームウェアの配信概念の一例を示す図である。
前提として、配信サーバ１３３で画像形成装置のファームウェアのアップデートを行う場合、ユーザは、図９Ａ、９Ｂに示される配信サーバ１３３のＷｅｂ画面から予約設定する。より具体的には、ユーザは、配信対象の画像形成装置を指定し、配信日時、配信予約時間等を予約設定して、インターネット経由で配信を行う。
図９Ａは、配信サーバ１３３の配信予約画面の一例を示す図である。
１４０１は、配信サーバのＷｅｂ画面であり、配信予約画面の一例である。
１４０２は、画像形成装置ＩＤである。
１４０３は、画像形成装置の現在のファームウェアバージョンである。
１４０４は、配信予約における配信日である。
１４０５は、配信可能な曜日である。
１４０６は、配信時刻（Ｆｒｏｍ）であり、配信開始時刻である。
１４０７は、配信時刻（Ｔｏ）であり、配信終了時刻である。なお、配信予約時間とは、配信開始時刻である配信時刻１４０６と、配信終了時刻である配信時刻１４０７とを含む。
１４０８は、配信するファームウェアのバージョンである。
１４０９は、ＯＫボタンである。ユーザは、ＯＫボタンを押下することで配信予約を登録する。
１４１０は、キャンセルボタンである。ユーザは、キャンセルボタンを押下することで配信予約をキャンセルする。

図９Ｂは、図９Ａとは別の内容の配信サーバ１３３の配信予約画面の一例を示す図である。より具体的には、図９Ａは配信日１４０４が設定されているのに対し、図９Ｂは配信可能曜日１５０５が設定されている点が異なる。
１５０１は、配信サーバのＷｅｂ画面であり、配信予約画面の一例である。
１５０２は、画像形成装置ＩＤである。
１５０３は、画像形成装置の現在のファームウェアバージョンである。
１５０４は、配信予約における配信日である。
１５０５は、配信可能な曜日である。
１５０６は、配信時刻（Ｆｒｏｍ）であり、配信開始時刻である。
１５０７は、配信時刻（Ｔｏ）であり、配信終了時刻である。
１５０８は、配信するファームウェアのバージョンである。
１５０９は、ＯＫボタンである。ユーザは、ＯＫボタンを押下することで配信予約を登録する。
１５１０は、キャンセルボタンである。ユーザは、キャンセルボタンを押下することで配信予約をキャンセルする。

７０１、７０２及び７０３は、顧客に設置された画像形成装置の台数及びネットワーク環境を示す。
１３３は、配信サーバを示す。
１３２は、インターネットを示す。
７０４、７０５及び７０６は、画像形成装置に対する配信サーバ１３３のファームウェアの配信方法を示している。
７０４の場合、顧客７０１の配信台数は１００台であり、通信速度は１００Ｍｂｐｓである。この場合、配信サーバ１３３は、通信速度と、配信予約時間とを検証し、通常の配信で問題なしと判断する。なお、通信速度は、ネットワーク環境情報に含まれる情報の一例である。
７０５の場合、顧客７０２の配信台数は２００台であり、通信速度は５０Ｍｂｐｓである。この場合、配信サーバ１３３は、通信速度と、配信予約時間とを検証し、通常の配信で問題なしと判断する。
７０６の場合、顧客７０３の配信台数は７００台であり、通信速度は１０Ｍｂｐｓである。この場合、配信サーバ１３３は、通信速度と、配信予約時間とを検証し、配信台数が大量であるにもかかわらず、通信速度が遅いため、通常の配信では行えないと判断する。そこで、配信サーバ１３３は、再スケジュール及び動的配信への切り替え処理を行う。ここで、動的配信とは、画像形成装置と配信サーバ１３３との間においてポーリングを伴う配信のことである。詳細については、後述の図１５等で説明する。

図１０は、本実施形態におけるファームウェアの配信予約内容、ファームウェア配信の前倒し処理及び後ろ倒し処理の一例を示す図である。
配信予約内容８０１は、配信サーバ１３３による配信予約内容が毎週土日の０：００−６：００に１画像形成装置当たり４００秒間隔で予約されていることを示している。この場合、ユーザは、図９Ａ、９Ｂに示される予約内容で、配信サーバ１３３のＷｅｂ画面を使用して予約を登録する。
配信サーバ１３３は、１画像形成装置当たり４００秒間隔で予約する判断を図１１に示される通信テストのログ情報から求める。
図１１は、配信サーバ１３３のデータベース１３４に登録されている通信テストのログの一例である。
１７０２は、通像形成装置ＩＤである。
１７０３は、画像形成装置の機種名である。
１７０４は、画像形成装置の現在のファームウェアのバージョンである。
１７０５は、通信速度である。
１７０６は、グローバルＩＰアドレスである。配信サーバ１３３のＣＰＵ２０１は、グローバルＩＰアドレスを、ＴＣＰ／ＩＰのリクエスト元からのヘッダ情報より、取得する。なお、グローバルＩＰアドレスは、ネットワーク上での画像形成装置のアドレス情報であり、画像形成装置を識別する識別情報の一例である。

本実施形態では、配信サーバ１３３は、ファームウェアのファイルサイズをＭＢ（ＭｅｇａＢｙｔｅ）で計算する。また、配信サーバ１３３は、通信速度をＭｂｐｓ（Ｍｅｇａｂｉｔｐｅｒｓｅｃｏｎｄ）で計算する。また、配信サーバ１３３は、Ｍｂｐｓ（Ｍｅｇａｂｉｔｐｅｒｓｅｃｏｎｄ）をＭＢ／Ｓｅｃ（ＭｅｇａＢｙｔｅｐｅｒｓｅｃｏｎｄ）に変換する際に以下の式１を使用する。
＜式１＞
１Ｍｂｐｓ＝０．１２５ＭＢ／Ｓｅｃ
１画像形成装置に要するファームウェアのダウンロード時間は以下の式２となる。
＜式２＞
１画像形成装置に要するファームウェアダウンロード時間（Ｓｅｃ）＝ファイルサイズ（ＭＢ）／（０．１２５×通信速度（Ｍｂｐｓ））
例えば、５００ＭＢのファームウェアを、１０Ｍｂｐｓの通信速度で転送する場合、式２を使用すると、以下のように４００秒となる。
４００（Ｓｅｃ）＝５００（ＭＢ）／（０．１２５×１０（Ｍｂｐｓ））
本実施形態では、配信サーバ１３３は、同一グローバルＩＰアドレス上の画像形成装置で、かつ、同一機種について配信予約を行う。

配信サーバ１３３は、図１１に示される通信テストのログに登録されている通信速度１７０５を使用して、以下の式３より同一グローバルＩＰアドレス上の画像形成装置で平均通信速度を求める。
＜式３＞
平均通信速度（Ｍｂｐｓ）＝全画像形成装置の通信速度（Ｍｂｐｓ）の合計値／画像形成装置の台数（台）
配信サーバ１３３は、式３において、同一グローバルＩＰアドレス上の画像形成装置の判断を図１１に示されるグローバルＩＰアドレス１７０６から判断する。また、配信サーバ１３３は、同一機種の判断を図１１の機種名１７０３から判断する。
次に、配信サーバ１３３は、式３で求めた平均通信速度を、以下の式４に代入してダウンロード平均時間を求める。
＜式４＞
ダウンロード平均時間（Ｓｅｃ）＝配信するファームウェアのサイズ（ＭＢ）／（０．１２５×平均通信速度（Ｍｂｐｓ））

配信サーバ１３３は、式４において、配信するファームウェアのサイズを図１２Ａに示される機種マスタのファイルサイズ１８０４から求める。
図１２Ａは、配信サーバ１３３のデータベース１３４に登録されている機種マスタの一例を示す図である。
１８０１は、機種マスタである。
１８０２は、画像形成装置の機種名である。
１８０３は、ファームウェアのバージョンである。
１８０４は、ファームウェアのファイルサイズである。
また、図１２Ｂは、図１２Ａに示される機種名と、画像形成装置ＩＤと、顧客名と、グローバルＩＰアドレスとを対応付けた顧客マスタの一例を示す図である。
１８０６は、画像形成装置ＩＤである。
１８０７は、顧客名である。
１８０８は、グローバルＩＰアドレスである。
１８０９は、機種名である。
配信予約内容８０１の場合、配信サーバ１３３は、式４によりダウンロード平均時間を４００秒と求めたので、４００秒間隔で配信予約を行う。また、配信サーバ１３３は、後述する図１５における配信予約において、以下の式５を用いて配信予約可能時間を計算する。
＜式５＞
配信予約可能時間（Ｓｅｃ）＞ダウンロード平均時間（Ｓｅｃ）×配信予約台数（台）

前倒し８０２は、配信サーバ１３３によるファームウェアの配信処理において、直近の一時間の配信で、平均２００秒で処理できたことを示している。配信サーバ１３３は、計測方法として、ファームウェアの配信開始時間から終了時間までを計測し、その差分から上記の時間を求めている。
図１３に示されるクライアントモジュール３１３と、配信サーバ１３３とのシーケンスにおいて、配信サーバ１３３は、クライアントモジュール３１３によるファーム配信情報要求９０５から受信完了通知９０７までの時間を配信の所要時間としている。なお、図１３の詳細な説明については、後述する。
配信サーバ１３３は、図１４Ａ、図１４Ｂに示される配信スケジュールの配信結果１６０７に示される各画像形成装置への配信に要した時間である配信結果をデータベース１３４に格納する。

図１４Ａ、図１４Ｂは、配信サーバ１３３のデータベース１３４に登録されている配信スケジュールの一例を示す図である。
１６０１は、配信スケジュールのマスタ（１）である。１６０２は、画像形成装置ＩＤである。１６０３は、配信開始時刻である。１６０４は、予約ＩＤである。１６０５は、ポーリング開始フラグである。１６０６は、配信中止フラグである。１６０７は、配信結果である。１６０８は、配信スケジュールのマスタ（２）である。なお、１６０８のマスタは、予約ＩＤ１６０４毎に保持される。１６０９は、配信終了時刻である。１６１０は、ポーリングを行う時間的な間隔を示すポーリング間隔である。なお、ポーリング間隔は、問い合わせ間隔を示す時間情報の一例である。１６１１は、閾値である。１６１２は、配信想定時間である。１６１３は、配信可能曜日である。

配信サーバ１３３は、前倒し８０２の場合、配信予約内容が４００秒間隔のままでは無駄が生じるので、配信間隔を２００秒間隔で前倒しする。そして、配信サーバ１３３は、終了時刻８０４までに予約を入れる余裕があれば、次週にスケジューリングされている予約を詰め込む。つまり、配信サーバ１３３は、配信対象の画像形成装置の台数を最初の予約に追加して処理を行う。
後倒し８０３は、配信サーバ１３３によるファームウェアの配信処理において、直近の一時間の配信で、平均６００秒で処理できたことを示している。この場合、配信サーバ１３３は、配信予約内容の４００秒間隔のままでは終了時刻８０４までに配信を完了できないため、配信間隔を６００秒間隔で後倒しする。そして、配信サーバ１３３は、終了時刻８０４までに完了できない予約は、次週にスライドさせるか、キャンセルする。つまり、配信サーバ１３３は、配信対象の画像形成装置の台数を最初の予約から削減して処理を行う。
なお、後倒し８０３の場合、配信サーバ１３３によるファームウェアの配信が重複する時間帯がある。ファームウェアの配信が重複すると、単独で実行するのと比べて転送に時間がかかる。そのため、配信サーバ１３３によるファームウェアの配信が、平均６００秒であったとしても、単独のファームウェアダウンロード時間は６００秒より短くなる。しかし、そのずれは、配信サーバ１３３により再スケジュールが繰り返される中で補正されるので、本実施形態では重複する時間帯は考慮しない。
以上、上述したように、配信サーバ１３３は、ファームウェアを配信した際の配信所要時間によって、前倒し８０２や後倒し８０３のようにファームウェアを配信するスケジュールを変動させる。

図１３は、クライアントモジュール３１３と、配信サーバ１３３との通信シーケンスの一例を示す図である。
外部サーバ１０７は、ファームウェアの配信を高速に行うためのサーバであり、Ｗｅｂコンテンツをインターネット経由で配信するために最適化されたネットワークを持つ。
クライアントモジュール３１３は、配信サーバ１３３のデータベース１３４に登録されている配信スケジュール（図１４Ａ、図１４Ｂ）の確認のために配信情報要求９０３を行う。なお、クライアントモジュール３１３は、１日に１回の定期的なタイミングで配信サーバ１３３に配信情報要求９０３の問い合わせを行う。
配信サーバ１３３は、配信スケジュールがある場合、クライアントモジュール３１３からの配信情報要求９０３に対する応答として、配信開始時刻１６０３と、ポーリング開始フラグ１６０５との情報を返信する。なお、クライアントモジュール３１３が前記ファームウェアの配信スケジュールを受信する処理は、配信スケジュール受信処理の一例である。なお、配信開始時刻１６０３と、ポーリング開始フラグ１６０５とは、図１４Ａの配信スケジュールに含まれている。前記配信スケジュールの情報は、配信サーバ１３３のデータベース１３４に登録されている。
ポーリング開始フラグ１６０５がＯＦＦの場合、クライアントモジュール３１３は、配信情報要求９０３の応答として指定された配信開始時刻１６０３になると、予約情報確認９０４を実行する。一方、ポーリング開始フラグ１６０５がＯＮの場合、クライアントモジュール３１３は、予約情報確認９０４をデフォルトのポーリング間隔で実行する。なお、本実施形態におけるデフォルトのポーリング間隔は、３６００秒とする。
上述のように、クライアントモジュール３１３は、配信サーバ１３３に対して予約情報確認９０４を行う。そして、配信サーバ１３３は、予約情報確認９０４の応答として、配信開始時刻１６０３、配信中止フラグ１６０６、及びポーリング間隔１６１０をクライアントモジュール３１３に返信する。

クライアントモジュール３１３は、ファームウェアの配信を要求するためにファーム配信情報要求９０５を配信サーバ１３３に行う。なお、ポーリング開始フラグ１６０５がＯＦＦの場合、クライアントモジュール３１３は、予約情報確認９０４の後にファーム配信情報要求９０５を実行する。一方、ポーリング開始フラグ１６０５がＯＮの場合、クライアントモジュール３１３は、現在時刻が配信開始時刻１６０３になった場合にファーム配信情報要求９０５を実行する。
配信サーバ１３３は、ファーム配信情報要求９０５の応答として、ダウンロード先ＵＲＬリストをクライアントモジュール３１３に返信する。ここで、ダウンロード先ＵＲＬリストは、ファームウェアの格納場所情報の一例である。
クライアントモジュール３１３は、配信サーバ１３３よりダウンロード先ＵＲＬリストを受信する。なお、本処理は、クライアントモジュール３１３による格納場所情報受信処理の一例である。クライアントモジュール３１３は、外部サーバ１０７と通信し、ダウンロード先ＵＲＬリストに基づいたファーム配信要求９０６を行う。
外部サーバ１０７は、クライアントモジュール３１３からのファーム配信要求９０６に対する応答として、ダウンロード先ＵＲＬリストに指定されているファームウェアを送信する。
クライアントモジュール３１３は、ファームウェアを受信すると、ファームウェア受信通知として受信完了通知９０７を配信サーバ１３３に送信する。

図１５は、配信サーバ１３３のＣＰＵ２０１による配信予約受付処理の一例を示すフローチャートである。
Ｓ１００１で、ＣＰＵ２０１は、ファームウェアの配信予約を実行し、処理をＳ１００２に進める。より具体的には、ＣＰＵ２０１は、図９Ａ、図９Ｂに示されるＷｅｂ画面上からのユーザの操作による配信予約を受け付ける。ＣＰＵ２０１は、図１６Ａ、図１６Ｂに示されるフォーマットで配信予約を配信サーバ１３３のＨＤＤ２０４に格納する。
図１６Ａ、図１６Ｂは、配信データのデータフォーマットの一例を示す図である。
１９０１は、配信登録データのフォーマットである。
１９０２は、配信予約情報１０００１１１１である。
ＣＰＵ２０１は、図１６Ａに示されたデータのうち、機種名、画像形成装置ＩＤ、グローバルＩＰアドレス、現在のバージョン及び通信速度の情報を、画像形成装置が配信サーバ１３３にアクセスした際の通信テストログ（図１１）から取得する。なお、ＣＰＵ２０１は、図１６Ａに示されるデータのうち上記以外のデータを、ユーザによる図９Ａ、９Ｂに示される画面の入力操作から取得する。また、ＣＰＵ２０１は、ユーザにより配信予約が入力されると、ユニークなＩＤである予約ＩＤを生成し、配信予約に関わる情報を前記予約ＩＤと関連づけて管理する。
Ｓ１００２で、ＣＰＵ２０１は、配信予約対象の画像形成装置のグローバルＩＰアドレスより、１顧客における画像形成装置の台数を割り出し、処理をＳ１００３に進める。なお、顧客毎の画像形成装置の台数確認は、同一機種、同一グローバルＩＰアドレスの台数確認に等しい。ＣＰＵ２０１は、Ｓ１００１の処理において配信日、配信時刻（Ｆｒｏｍ）及び配信時刻（Ｔｏ）が入力された画像形成装置の数をカウントすることにより１顧客における画像形成装置の台数を割り出す。

Ｓ１００３で、ＣＰＵ２０１は、クライアントモジュール３１３と、配信サーバ１３３と間で実施した通信テストのログ（図１１）から、顧客環境の通信速度を割り出し、処理をＳ１００４に進める。なお、通信テストとは、画像形成装置と、配信サーバ１３３とを接続する際のテストである。ＣＰＵ２０１は、図１１に示されるような通信テストが行われた際のログをデータベース１３４に保持している。また、通信テストのログ情報は、上述したように図１６Ｂに示されるようなフォーマットでＣＰＵ２０１によりＨＤＤ２０４に格納されている配信予約情報に含まれる。ＣＰＵ２０１は、通信テストで１ＭＢのファイルの授受を行うため、その通信時間から画像形成装置個別の通信速度を求めることができる。更に、ＣＰＵ２０１は、Ｓ１００１の処理において配信日、配信時刻（Ｆｒｏｍ）、配信時刻（Ｔｏ）が入力された画像形成装置に関連する同一ネットワーク内の通信速度を平均する。例えば、図１６Ｂに示される配信予約情報の場合、配信対象の画像形成装置の各々の通信速度は、１０．００ＭＢｐｓ、１１．００ＭＢｐｓ、１１．００ＭＢｐｓなので、ＣＰＵ２０１は、平均の通信速度を１０．６６ＭＢｐｓと求める。
Ｓ１００４で、ＣＰＵ２０１は、Ｓ１００１で配信予約された画像形成装置に対し、式５を用いて配信予約可能時間を計算し、処理をＳ１００５に進める。例えば、ＣＰＵ２０１は、１０００台の画像形成装置を１０Ｍｂｐｓの顧客環境で配信予約する場合、１ファームセット（約５００ＭＢ）の配信時間は４００秒なので、配信予約可能時間を４０万秒＝１１１時間と計算する。ここで、配信予約可能時間は、配信対象の全画像形成装置に対する配信想定時間の一例である。

Ｓ１００５で、ＣＰＵ２０１は、配信予約時間以内にファームウェアを配信可能か否か判断し、配信可能と判断すれば処理をＳ１００６に進め、配信不可能と判断すれば処理をＳ１００７に進める。なお、本処理は、ＣＰＵ２０１による配信可否判断処理の一例である。より具体的には、ＣＰＵ２０１は、Ｓ１００１で配信予約した配信予約時間が、Ｓ１００４で計算した配信予約可能時間よりも長ければ配信可能と判断し、短ければ配信不可能と判断する。例えば、ユーザが、図９Ａに示されるように配信日１４０４、配信時刻（Ｆｒｏｍ）１４０６及び配信時刻（Ｔｏ）１４０７を設定した場合、ＣＰＵ２０１は、配信予約した時間（１４０６〜１４０７）が、配信予約可能時間よりも長いと判断する。一方、ユーザが、図９Ｂに示されるように配信可能曜日１５０５を設定した場合、ＣＰＵ２０１は、単に配信可能と判断する。
Ｓ１００７で、ＣＰＵ２０１は、新たに配信可能な時間帯の入力を指示し、処理をＳ１００８に進める。より具体的には、ユーザは、ＣＰＵ２０１がＳ１００４で計算した配信予約可能時間よりも長い時間で配信予約時間を入力設定する。
Ｓ１００８で、ＣＰＵ２０１は、ユーザから再入力された配信予約に対して配信予約可能時間を計算し、処理をＳ１００９に進める。なお、ＣＰＵ２０１による計算方法は、Ｓ１００４と同様である。

Ｓ１００９で、ＣＰＵ２０１は、Ｓ１００８で計算した時間で配信可能か否かを判断すし、配信可能と判断すれば処理をＳ１０１０に進め、配信不可能と判断すれば処理をＳ１００７に進める。なお、ここでのＣＰＵ２０１による判断方法は、Ｓ１００５と同様であるため説明を省略する。
Ｓ１０１０で、ＣＰＵ２０１は、画像形成装置にポーリング指示をかけるため、ポーリングフラグ設定をＯＮにし、処理をＳ１０１１に進める。クライアントモジュール３１３は、ＣＰＵ２０１によりポーリング開始フラグの属性がＯＮと通知されると、定期的に配信サーバ１３３とポーリングを行う。なお、ポーリングメソッドは、予約情報確認９０４であり、クライアントモジュール３１３と、配信サーバ１３３とは、このメソッドを定期的に通信させることで、スケジュール変更に柔軟に対応する。本実施形態では、ポーリングがＯＮにされたファームウェア配信を動的配信とし、ポーリングがＯＦＦにされたファームウェアの配信を通常配信とする。
Ｓ１０１１で、ＣＰＵ２０１は、ポーリングを伴う配信なので、動的配信として処理を行い、処理を終了する。
一方、Ｓ１００６で、ＣＰＵ２０１は、ポーリングを伴わない配信なので、通信処理として処理を行い、処理を終了する。
なお、ＣＰＵ２０１は、図１５に示される処理で設定した配信予約を、図１４Ａ、図１４Ｂに示される配信スケジュールに反映させる。

画像形成装置ＩＤ１６０２は、図９Ａ、図９Ｂに示される配信予約画面でユーザにより配信対象として選択された画像形成装置に対応する。
配信開始時刻１６０３は、図９Ａ、図９Ｂに示される配信予約画面でユーザにより入力された配信時刻（Ｆｒｏｍ）から配信時刻（Ｔｏ）までの間に、配信想定時間１６１２の間隔でＣＰＵ２０１によりシーケンシャルに設定される。
予約ＩＤ１６０４は、Ｓ１００１でＣＰＵ２０１により生成される。
ポーリング開始フラグ１６０５は、ＣＰＵ２０１による通常配信（Ｓ１００６）の場合、ＯＦＦであるとし、ＣＰＵ２０１による動的配信（Ｓ１０１１）の場合、ＯＮであるとする。
配信中止フラグ１６０６は、デフォルトでＯＦＦである。
配信結果１６０７は、外部サーバ１０７から画像形成装置にファームウェアが配信され、画像形成装置から配信サーバ１３３に受信完了通知９０７が通知された際に、ＣＰＵ２０１が時間を計測し反映させた値である。
配信終了時刻１６０９は、図９Ａ、図９Ｂに示される配信予約画面でユーザにより入力された配信時刻（Ｔｏ）とする。
ポーリング間隔１６１０は、デフォルトで３６００秒である。
閾値１６１１は、＋−１００秒とし、固定の値である。
配信想定時間１６１２は、１画像形成装置に要すると想定されるファームウェアダウンロード時間である。なお、ＣＰＵ２０１は、Ｓ１００３で顧客環境の通信速度を求める過程で、上述した式２に基づいた計算により配信想定時間１６１２を得る。
配信可能曜日１６１３は、図９Ａ、図９Ｂに示される配信予約画面でユーザにより配信可能曜日が入力された場合、ＣＰＵ２０１によりその曜日が設定される。

図１７は、配信サーバ１３３のＣＰＵ２０１による配信処理における前倒し及び後ろ倒し処理の一例を示すフローチャートである。
Ｓ１１０１で、ＣＰＵ２０１は、配信予約されている画像形成装置のクライアントモジュール３１３から配信情報要求を受け付け、処理をＳ１１０２に進める。
Ｓ１１０２で、ＣＰＵ２０１は、配信予約されている画像形成装置のクライアントモジュール３１３に対して、配信開始時刻１６０３及びポーリング開始フラグ１６０５を返信し、処理をＳ１１０３に進める。
Ｓ１１０３で、ＣＰＵ２０１は、配信予約されている画像形成装置に対して配信処理を行い、処理をＳ１１０４に進める。Ｓ１１０３の処理の詳細については、図１８のフローチャートを用いて後述する。
Ｓ１１０４で、ＣＰＵ２０１は、図１４Ａ、図１４Ｂの配信スケジュールを参照し、同一予約ＩＤでの、本日分の配信が終了したか否かを判断し、終了したと判断すれば処理をＳ１１１９に進め、終了していないと判断すれば処理をＳ１１０５に進める。なお、図１４Ａ、図１４Ｂに示される予約ＩＤとは、ユーザが配信予約をする際に配信予約ごとに割り当てられるＩＤである。図９Ｂに示されるように、ユーザにより毎週土日０：００−６：００で配信予約された場合、ＣＰＵ２０１は、全ての画像形成装置に配信が完了するまで予約ＩＤを保持する。また、上述した図１６Ｂの１９０２に示される配信予約情報１０００１１１１も、予約ＩＤの一例である。

Ｓ１１０５で、ＣＰＵ２０１は、Ｓ１１０３での配信開始時刻１６０３又は再計算処理後（Ｓ１１０６以降の一連の処理）から一定時間が経過したか否かを判断し、経過したと判断すれば処理をＳ１１０６に進める。一方、Ｓ１１０５で、ＣＰＵ２０１は、経過していないと判断すれば処理をＳ１１０３に進める。ここで、一定時間とは、ポーリング間隔１６１０を意味する。図１４Ｂに示されるポーリング間隔１６１０は３６００秒なので、ＣＰＵ２０１は、Ｓ１１０３での配信開始時刻１６０３又は再計算処理後（Ｓ１１０６以降の一連の処理）から３６００秒経過したか否かを判断する。ＣＰＵ２０１は、３６００秒経過したと判断した場合、処理をＳ１１０６に進め、経過していないと判断した場合、処理をＳ１１０３に進める。なお、本実施形態では一例として、ポーリング間隔１６１０を３６００秒としたが、これに限る必要はない。
Ｓ１１０６で、ＣＰＵ２０１は、現在時刻＋ポーリング間隔１６１０以降の時間で、画像形成装置に対して、ファームウェアの配信結果の平均時間と、想定時間との差分を計算し、処理をＳ１１０７に進める。より具体的には、ＣＰＵ２０１は、Ｓ１１０３での配信処理が想定する時間内で行われているかを判断するために、配信結果１６０７と、配信想定時間１６１２との差分を以下の式６を用いて計算する。
＜式６＞
差分＝配信結果１６０７の平均時間−配信想定時間１６１２
ＣＰＵ２０１は、図１４Ｂに示される配信スケジュールに配信想定時間１６１２を記述する。なお、ＣＰＵ２０１は、前述した式４から配信想定時間１６１２を求める。また、ＣＰＵ２０１は、図９Ａ、図９Ｂに示される配信予約画面でユーザの操作により配信予約がされると、配信予約された画像形成装置に対する配信処理を配信想定時間１６１２の間隔でスケジューリングする。
配信結果１６０７は、Ｓ１１０３でＣＰＵ２０１が画像形成装置に対して行った配信処理の所要時間である。

Ｓ１１０７で、ＣＰＵ２０１は、Ｓ１１０６で計算した差分が閾値以内か否かを判断し、閾値以内であると判断すれば処理をＳ１１０３に進め、閾値以内でないと判断すれば処理をＳ１１０８に進める。
図１４Ｂの１６１１は、閾値を示す。図１４Ｂでは、閾値１６１１を＋−１００秒としているので、ＣＰＵ２０１は、Ｓ１１０７での比較の結果、＋−１００秒以上の差異があれば、閾値以内でないと判断する。なお、閾値は、ユーザにより予め設定された値であり、他の配信スケジュールの情報と共にデータベース１３４に格納されている情報である。また、本実施形態では閾値を＋−１００秒としたが、これに限る必要はない。
Ｓ１１０８で、ＣＰＵ２０１は、Ｓ１１０６で計算した差分が０未満であるか否かを判断する。ＣＰＵ２０１は、０未満であると判断した場合、配信想定時間１６１２よりも早く配信処理が行われていることになるので、処理をＳ１１０９に進める。一方、ＣＰＵ２０１は、０未満でないと判断した場合、配信想定時間１６１２よりも遅く配信処理が行われていることになるので、処理をＳ１１１３に進める。
Ｓ１１０９で、ＣＰＵ２０１は、配信処理の前倒し処理を行い、処理をＳ１１１０に進める。より具体的には、ＣＰＵ２０１は、前倒し処理として、図１４Ｂに示される配信想定時間１６１２にＳ１１０６で計算した配信結果１６０７の平均値を設定する。次に、ＣＰＵ２０１は、配信終了時刻１６０９を確認し、前倒し可能な画像形成装置の数を計算する。なお、本処理は、ＣＰＵ２０１による配信可能台数確認処理の一例である。

まず、ＣＰＵ２０１は、計算方法として以下の式７を用いて配信設定可能な時間を計算する。なお、前提として、ＣＰＵ２０１が未配信の全画像形成装置に対して設定を完了するためには、ポーリング間隔分の時間が必要となるため、配信設定可能な時間の計算方法は式７のようになる。
＜式７＞
配信設定可能な時間（Ｓｅｃ）＝配信終了時刻（Ｓｅｃ）−（現在時刻（Ｓｅｃ）＋ポーリング間隔（Ｓｅｃ））
次に、ＣＰＵ２０１は、以下の式８のように、配信設定可能な時間をＳ１１０６で計算した配信想定時間１６１２で割ることで、前倒し可能な画像形成装置の数を計算する。
＜式８＞
前倒し可能な画像形成装置（台）＝配信設定可能な時間（Ｓｅｃ）／配信想定時間（Ｓｅｃ）

Ｓ１１１０で、ＣＰＵ２０１は、前倒し対象の画像形成装置の全台に対し、配信想定時間１６１２の間隔で配信開始時刻１６０３を変更し、図１４Ａ、図１４Ｂに示される配信スケジュールに反映させ、処理をＳ１１１１に進める。ＣＰＵ２０１は、Ｓ１１１０の処理において、式８で計算した前倒し可能な画像形成装置の台数分ループさせて配信スケジュールに反映させる。
Ｓ１１１１で、ＣＰＵ２０１は、式７を用いて計算した配信設定可能な時間が、ポーリング間隔１６１０以内か否かを判断する。図１４Ｂの例では、ポーリング間隔１６１０が３６００秒、配信終了時刻１６０９が６：００なので、ＣＰＵ２０１は、現在時刻が５：００を過ぎたか否かを判断する。ＣＰＵ２０１は、配信設定可能な時間がポーリング間隔１６１０以内であれば、処理をＳ１１１２に進め、ポーリング間隔１６１０以内でなければ、処理をＳ１１０３に進める。
Ｓ１１１２で、ＣＰＵ２０１は、現在時刻＋ポーリング間隔以降の時間で配信が予定されている画像形成装置に対してポーリング間隔を早めるように、図１４Ｂに示される配信スケジュールに反映させ、処理をＳ１１０３に進める。ＣＰＵ２０１は、Ｓ１１０６で計算した配信想定時間１６１２を新たなポーリング間隔１６１０とする。

Ｓ１１１３で、ＣＰＵ２０１は、配信処理の後ろ倒し処理を行い、処理をＳ１１１４に進める。ＣＰＵ２０１は、後ろ倒し処理として、配信想定時間１６１２に、Ｓ１１０６で計算した配信結果１６０７の平均時間を設定する。次に、ＣＰＵ２０１は、配信終了時刻１６０９を確認し、後ろ倒し可能な画像形成装置の数を計算する。なお、ＣＰＵ２０１は、本処理において前述の式７、式８を用いて計算する。
Ｓ１１１４で、ＣＰＵ２０１は、後ろ倒し対象の画像形成装置の全台に対し、新たな配信想定時間１６１２の間隔で配信開始時刻１６０３を変更し、図１４Ａ、図１４Ｂに示される配信スケジュールに反映させると、処理をＳ１１１５に進める。ＣＰＵ２０１は、Ｓ１１１４の処理において、式８で計算した前倒し可能な画像形成装置の台数分ループさせて配信スケジュールに反映させる。
Ｓ１１１５で、ＣＰＵ２０１は、Ｓ１１１４で反映させたスケジュールで配信処理をした場合、配信終了時刻１６０９までに配信できない画像形成装置があるか否かを判断する。なお、ＣＰＵ２０１は、配信終了時刻１６０９から、配信想定時間１６１２を引いた時刻よりも後に、配信開始時刻１６０３が設定されている画像形成装置を配信できない画像形成装置と判断する。ＣＰＵ２０１は、配信終了時刻１６０９までに配信できない画像形成装置があると判断した場合、処理をＳ１１１６に進め、配信できない画像形成装置はないと判断した場合、処理をＳ１１１１に進める。
Ｓ１１１６で、ＣＰＵ２０１は、配信終了時刻１６０９までに配信できない画像形成装置に対して、翌日以降の予約に再スケジュール可能か否かを判断し、可能と判断すれば処理をＳ１１１７に進め、不可能と判断すれば処理をＳ１１１８に進める。なお、ＣＰＵ２０１は、判断方法として、図１４Ｂに示される配信可能曜日１６１３が設定されていれば、再スケジュール可能と判断し、配信可能曜日１６１３が設定されていなければ、再スケジュール不可能と判断する。
Ｓ１１１７で、ＣＰＵ２０１は、配信終了時刻１６０９までに配信できない画像形成装置に対して翌日以降の予約を再スケジュールし、図１４Ａ、１４Ｂに示される配信スケジュールに反映させ、処理をＳ１１１１に進める。ＣＰＵ２０１は、再スケジュール方法として、完了できなかった画像形成装置の配信処理を翌日以降の最初の配信処理１１０３にスライドさせるように、配信開始時刻１６０３を設定する。なお、ＣＰＵ２０１は、再スケジュールする以前から翌日以降に配信予約されていた画像形成装置に対しては、順次スライドさせる（図示外）。
Ｓ１１１８で、ＣＰＵ２０１は、配信できない画像形成装置の予約をキャンセルし、処理をＳ１１１１に進める。ＣＰＵ２０１は、配信キャンセル処理として、対象となる画像形成装置において、図１４Ａに示される配信中止フラグ１６０６をＯＮにする。

以下、Ｓ１１０４で、ＣＰＵ２０１が、本日分の配信が終了していないと判断した場合の処理について説明する。
Ｓ１１１９で、ＣＰＵ２０１は、本日分の配信が終了したので、同一予約ＩＤで、翌日以降に配信する予定のファームウェアがあるか否かを、図１４Ａに示される配信スケジュールから確認し、処理をＳ１１２０に進める。
Ｓ１１２０で、ＣＰＵ２０１は、Ｓ１１１９で確認した配信スケジュールから明日以降に配信する予定のファームウェアがあるか否かを判断し、配信する予定のファームウェアがあると判断した場合、処理をＳ１１２１に進める。一方、Ｓ１１２０で、ＣＰＵ２０１は、明日以降に配信する予定のファームウェアはないと判断した場合、処理を終了する。
Ｓ１１２１で、ＣＰＵ２０１は、無駄なポーリング通信を防ぐため、次の画像形成装置の配信開始時刻の２４時間前まで、ポーリング間隔を遅くするように、配信スケジュールのポーリング間隔１６１０を変更し、処理を終了する。配信開始時刻１６０３が２４時間前を切った場合、ＣＰＵ２０１は、ポーリング間隔１６１０をデフォルトに戻す（図示外）。なお、本実施形態におけるデフォルトのポーリング間隔は、３６００秒とする。

図１８は、配信サーバ１３３のＣＰＵ２０１による配信処理の一例を示すフローチャートである。なお、図１８に示されるフローチャートは、図１７のＳ１１０３の処理の詳細を示すフローチャートである。
Ｓ１２０１で、ＣＰＵ２０１は、クライアントモジュール３１３からアクセスが来るまで待機し、アクセスが来れば処理をＳ１２０２に進める。
Ｓ１２０２で、ＣＰＵ２０１は、クライアントモジュール３１３から予約情報確認９０４が通知されたか否かを判断し、通知されたと判断すれば処理をＳ１２０３に進め、通知されていないと判断すれば処理をＳ１２０５に進める。
Ｓ１２０３で、ＣＰＵ２０１は、クライアントモジュール３１３から予約情報確認を受け付け、処理をＳ１２０４に進める。
Ｓ１２０４で、ＣＰＵ２０１は、クライアントモジュール３１３に配信開始時刻１６０３、配信中止フラグ１６０６、及びポーリング間隔１６１０を返信し、処理をＳ１２０１に進める。なお、ＣＰＵ２０１によるＳ１２０４の処理は、第１の応答手段の一例である。

Ｓ１２０５で、ＣＰＵ２０１は、ファーム配信情報要求９０５がクライアントモジュール３１３から通知されたか否かを判断し、通知されたと判断すれば処理をＳ１２０６に進め、通知されていないと判断すれば処理をＳ１２０８に進める。
Ｓ１２０６で、ＣＰＵ２０１は、クライアントモジュール３１３からファーム配信情報要求９０５を受け付け、処理をＳ１２０７に進める。
Ｓ１２０７で、ＣＰＵ２０１は、クライアントモジュール３１３にダウンロード先ＵＲＬを返信し、処理をＳ１２０１に進める。なお、ＣＰＵ２０１によるＳ１２０７の処理は、第２の応答手段の一例である。
Ｓ１２０８で、ＣＰＵ２０１は、受信完了通知９０７がクライアントモジュール３１３から通知されたかを判断し、通知されたと判断すれば処理をＳ１２０９に進め、通知されていないと判断すれば処理をＳ１２０１に進める。
Ｓ１２０９で、ＣＰＵ２０１は、クライアントモジュール３１３から受信完了通知９０７を受け付け、処理を終了する。

図１９は、クライアントモジュール３１３のＣＰＵ３０６による処理の一例を示すフローチャートである。
Ｓ１３０１で、ＣＰＵ３０６は、配信サーバ１３３に配信情報要求９０３を行い、配信サーバ１３３に自身の画像形成装置に対する配信情報があるか否かを問い合わせ、処理をＳ１３０２に進める。なお、ＣＰＵ３０６は、配信予約確認ポーリングにより、配信サーバ１３３に１日１回、配信情報要求９０３の問い合わせを行う。また、ＣＰＵ３０６は、Ｓ１３０１の処理を図１３に示されるタイミングで実行する。
Ｓ１３０２で、ＣＰＵ３０６は、配信情報要求９０３の返答として、配信サーバ１３３から配信開始時刻１６０３及びポーリング開始フラグ１６０５を受信し、処理をＳ１３０３に進める。
Ｓ１３０３で、ＣＰＵ３０６は、Ｓ１３０２で配信サーバ１３３から受信したポーリング開始フラグ１６０５がＯＮであるか又はＯＦＦであるかを判断し、ＯＮであると判断すれば処理をＳ１３０４に進め、ＯＦＦであると判断すれば処理を１３０５に進める。
Ｓ１３０４で、ＣＰＵ３０６は、配信サーバ１３３に対して、デフォルトの間隔でポーリングを開始し、処理をＳ１３０５に進める。

Ｓ１３０５で、ＣＰＵ３０６は、ポーリング用のメソッドである予約情報確認９０４で、配信サーバに問い合わせを行い、処理をＳ１３０６に進める。なお、ＣＰＵ３０６は、Ｓ１３０５の処理を図１３に示されるタイミングで実行する。
Ｓ１３０６で、ＣＰＵ３０６は、予約情報確認９０４の返答として、配信サーバ１３３から配信開始時刻１６０３、配信中止フラグ１６０６及びポーリング間隔１６１０を受信すると、処理をＳ１３０７に進める。
Ｓ１３０７でＣＰＵ３０６は、配信スケジュールの配信開始時刻１６０３又はポーリング間隔に変更があるか否かを判断し、変更があると判断すれば処理をＳ１３０８に進め、変更がないと判断すれば処理をＳ１３０９に進める。より具体的には、ＣＰＵ３０６は、Ｓ１３０６で配信サーバ１３３から受信した配信開始時刻１６０３及びポーリング間隔１６１０と、Ｓ１３０２で受信した配信開始時刻１６０３及びデフォルトのポーリング間隔とを比較する。Ｓ１３０７で、ＣＰＵ３０６は、前記比較に基づいて、配信スケジュールの配信開始時刻１６０３又はポーリング間隔に変更があるか否かを判断する。

Ｓ１３０８で、ＣＰＵ３０６は、Ｓ１３０２で配信サーバ１３３から受信した配信開始時刻１６０３及びデォルトのポーリング間隔１６１０を、Ｓ１３０６で受信した配信開始時刻１６０３及びポーリング間隔１６１０に変更する。Ｓ１３０８で、ＣＰＵ３０６は、前記変更処理を実行すると、処理をＳ１３０９に進める。
Ｓ１３０９で、ＣＰＵ３０６は、次のポーリング時間又は配信開始時刻まで待機し、処理をＳ１３１０に進める。
Ｓ１３１０で、ＣＰＵ３０６は、次のポーリング時間になったか否かを判断し、次のポーリング時間になったと判断すれば処理をＳ１３０５に進め、次のポーリング時間になっていないと判断すれば処理をＳ１３１１に進める。より具体的には、ＣＰＵ３０６は、Ｓ１３０８で変更したポーリング間隔１６１０と、経過時刻とを比較することで、次のポーリング時間になったか否かを判断する。

Ｓ１３１１で、ＣＰＵ３０６は、配信開始時刻になったか否かを判断し、配信開始時刻になったと判断すれば処理をＳ１３１２に進め、配信開始時刻になっていないと判断すれば処理をＳ１３０９に進める。より具体的には、ＣＰＵ３０６は、Ｓ１３０８で変更した配信開始時刻１６０３と、経過時刻とを比較することで、配信開始時刻になったか否かを判断する。
Ｓ１３１２で、ＣＰＵ３０６は、配信開始時刻になったので、ファーム配信情報要求９０５で、配信サーバ１３３にＵＲＬリスト取得のリクエストを発行し、処理をＳ１３１３に進める。なお、ＣＰＵ３０６は、Ｓ１３１２の処理を図１３に示されるタイミングで実行する。
Ｓ１３１３で、ＣＰＵ３０６は、ファーム配信情報要求９０５の返答として、配信サーバ１３３からダウンロード先ＵＲＬリストを受信し、処理をＳ１３１４に進める。

Ｓ１３１４では、ＣＰＵ３０６は、ファーム配信要求９０６で、ダウンロード先ＵＲＬリストのアクセス先である外部サーバ１０７にファームウェア取得のリクエストを発行し、処理をＳ１３１５に進める。なお、ＣＰＵ３０６は、Ｓ１３１４の処理を図１３に示されるタイミングで実行する。
Ｓ１３１５で、ＣＰＵ３０６は、ファーム配信要求９０６の返答として、外部サーバ１０７からファームウェアを受信し、処理をＳ１３１６に進める。
Ｓ１３１６で、ＣＰＵ３０６は、受信完了通知９０７を配信サーバ１３３に送信し、処理をＳ１３１７に進める。なお、ＣＰＵ３０６は、Ｓ１３１６の処理を図１３に示されるタイミングで実行する。
Ｓ１３１７で、ＣＰＵ３０６は、ファームウェアの配信が完了したので、ポーリングをＯＦＦし、処理を終了する。

図２０は、通信テストのシーケンスの一例を表した図である。
図２０を用いて、通信テストのシーケンスと、そこでやりとりされるデータについて説明する。
ユーザにより画像形成装置の通信テストボタン（図示外）がクリックされると、画像形成装置のクライアントモジュール３１３は、通信テストデータリクエストを配信サーバ１３３に送信する（２００１）。ここで、クライアントモジュール３１３は、データリクエストと共に画像形成装置の機種名、画像形成装置ＩＤを送信する。また、クライアントモジュール３１３と、配信サーバ１３３との通信は、ＴＣＰ／ＩＰを用いて行われ、画像形成装置のＩＰアドレスはグローバルＩＰアドレスに変換されて送信される。なお、画像形成装置のＩＰアドレスからグローバルＩＰアドレスへの変換は、Ｐｒｏｘｙサーバ（図示外）で行われる。
配信サーバ１３３は、通信テストデータリクエストをクライアントモジュール３１３から受信すると、通信テストデータ計測用ＵＲＬをクライアントモジュール３１３に返信する（２００２）。また、配信サーバ１３３は、受信した機種名、画像形成装置ＩＤ、グローバルＩＰアドレスを配信サーバ１３３のデータベース１３４に記録する。配信サーバ１３３は、既に同一の画像形成装置ＩＤのデータがデータベース１３４に存在する場合は上書きし、存在しない場合はデータを追加する。

クライアントモジュール３１３は、配信サーバ１３３から受信した外部サーバのＵＲＬにアクセスし（２００３）、外部サーバから通信テスト計測用のデータを受信する（２００４）。この際、クライアントモジュール３１３は、受信開始時刻及び終了時刻をミリ秒で保持しておく。
クライアントモジュール３１３は、受信を終了すると、以下の式９を用いて通信速度を計算する（２００５）。
＜式９＞
通信速度＝１＊１０００／（受信開始時刻−受信終了時刻）
この式は、１ＭＢのデータを何ミリ秒で受信したかを計算する式であり、秒単位に変換するために１０００を乗じている。つまり、通信速度がＭｂｐｓ（１秒間に１００万ｂｉｔのデータを受信する速度）で計算される式である。
クライアントモジュール３１３は、通信速度を計算すると、配信サーバ１３３に通信テストの結果を送信する（２００６）。より具体的には、クライアントモジュール３１３は、通信テストの成否と、成功した場合の通信速度とを配信サーバ１３３に送信する。
配信サーバ１３３は、クライアントモジュール３１３から受信した通信速度をデータベース１３４の通信速度に記憶する（２００７）。なお、通信は同一セッションで行われるため、クライアントモジュール３１３は、２００１で配信サーバ１３３に送信した画像形成装置ＩＤ等を再送しない。
配信サーバ１３３は、クライアントモジュール３１３から送信された通信速度結果（２００６）に対する応答を返信する（２００８）。ここでは、配信サーバ１３３は、データを受信したことのみをクライアントモジュール３１３に返信する。クライアントモジュール３１３が配信サーバ１３３からの返信（２００８）を受信すると、通信テストは終了する。

＜具体例＞
以下に、上述した図１５に示されるフローチャートにおける処理の具体例を示す。
まず、図１５に示されるフローチャートにおける処理の具体例について説明する。
なお、図１５は、配信サーバ１３３のＣＰＵ２０１による配信予約受付処理の一例を示すフローチャートである。
Ｓ１００１で、ＣＰＵ２０１は、１０００台の配信予約を実行し、処理をＳ１００２に進める。
＜配信予約内容＞
２０１２／４／２８ ０：００−６：００
Ｓ１００２で、ＣＰＵ２０１は、グローバルＩＰアドレスより、１顧客における画像形成装置の台数を割り出し、処理をＳ１００３に進める。ＣＰＵ２０１は、上述した図１２Ｂの顧客マスタに示されるように、同一のグローバルＩＰアドレスを１顧客とみなす。
＜１顧客における画像形成装置の台数＞
顧客Ａ：１００台、顧客Ｂ：２００台、顧客Ｃ：７００台

Ｓ１００３で、ＣＰＵ２０１は、通信テストのログから顧客環境の通信速度を割り出し、処理をＳ１００４に進める。なお、クライアントモジュール３１３と、配信サーバ１３３とは、通信テストとして１ＭＢのファイルの転送テストを行っている。ＣＰＵ２０１は、図１１に示される通信テストのログより以下を求めることができる。なお、以下の計算は、Ｓ１００４で、ＣＰＵ２０１が計算する配信予約可能時間も含む。
＜顧客環境の通信速度＞
顧客Ａ：１００Ｍｂｐｓ（１２．５ＭＢ／ｓｅｃ）。１ファームセット（約５００Ｍ）の配信時間は４０秒なので、１００台だと配信に６６分かかる。
顧客Ｂ：５０Ｍｂｐｓ（６．２５ＭＢ／ｓｅｃ）。１ファームセット（約５００Ｍ）の配信時間は８０秒なので、２００台だと配信に４．４時間かかる。
顧客Ｃ：１０Ｍｂｐｓ（１．２５ＭＢ／ｓｅｃ）。１ファームセット（約５００Ｍ）の配信時間は４００秒なので、７００台だと配信に７７時間かかる。

Ｓ１００５で、ＣＰＵ２０１は、上記の顧客環境を参照して、Ｓ１００１で実行した配信予約が設定した配信予約時間以内に配信可能か否かを判断し、配信可能と判断すれば処理をＳ１００６に進め、配信不可能と判断すれば処理をＳ１００７に進める。
・顧客Ａ、Ｂの場合
配信予約時間の範囲内なので、ＣＰＵ２０１は、予約をそのまま受け付け、処理をＳ１００６に進める。
・顧客Ｃの場合
配信に７７時間を要し、配信予約時間の範囲を大きく上回ってしまうので、ＣＰＵ２０１は、処理をＳ１００７に進め、配信可能な時間帯の再設定を指示する。ＣＰＵ２０１は、Ｓ１００７の処理終了後、処理をＳ１００８に進める。
Ｓ１００８で、ＣＰＵ２０１は、ユーザからの配信予約の入力を再度受け付けると、Ｓ１００４と同様の処理により配信予約可能時間を計算し、処理をＳ１００９に進める。
＜配信可能な時間帯＞
顧客Ｃの場合、ＣＰＵ２０１は、配信可能な時間帯を毎週土日の０：００−６：００に設定する。
顧客Ｃの環境では、１画像形成装置あたり配信に４００秒を要する。そのため、ＣＰＵ２０１は、１画像形成装置あたりの配信時間の計測を適切に行うために、例えば図１０の８０１に示されるように４００秒間隔でシーケンシャルに１画像形成装置ずつ予約する。

Ｓ１００９で、ＣＰＵ２０１は、Ｓ１００５と同様の処理による判断の結果、配信可能と判断し、処理をＳ１０１０に進める。
Ｓ１０１０で、ＣＰＵ２０１は、予約の際に対象の画像形成装置にポーリングの開始指示を行い、処理をＳ１０１１に進める。なお、ＣＰＵ２０１は、最初の予約において、直近の土曜日曜の０：００−６：００だと２１６台への配信処理が可能なので、残りの画像形成装置については次週に予約し、各画像形成装置にポーリング指示を行う。
Ｓ１０１１で、ＣＰＵ２０１は、配信開始時間になり、ファームウェアの配信中に顧客Ｃの転送速度が想定速度（１０Ｍｂｐｓ（１．２５ＭＢ／ｓｅｃ））を上回るならば、配信予約時間を前倒しして配信する（Ｓ１１０９）。逆に下回るならば、ＣＰＵ２０１は、配信予約時間を後ろ倒しにして配信する（Ｓ１１１３）。
以上、本実施形態では、ＣＰＵ２０１は、ファームウェアの配信を配信可能な時間帯である土日の０：００−６：００に行い、配信の終了時刻までに完了できるように、スケジューリングを行いつつ、アップデート処理を行う。
なお、ＣＰＵ２０１は、前倒しの場合で次週の予約を実行できるならば、次週の予約を前倒しする。また、ＣＰＵ２０１は、後ろ倒しの場合で終了時刻内に処理できなければ、処理できない予約を次週に再スケジュールするか、次週に持ち越せない場合はキャンセルする。以上により、ＣＰＵ２０１は、指定された時間内でファームウェアの配信を完了することができる。

図２１Ａ、図２１Ｂは、本実施形態の前倒し、後ろ倒しの再計算処理（Ｓ１１０６以降の一連の処理）におけるタイムスケジュールの一例を示す図である。
前提として、図９Ａ、図９Ｂに示される配信サーバの予約画面で、ユーザにより設定される配信時刻（１４０６〜１４０７）は、０：００〜６：００であるとする。
図２１Ａのタイムスケジュール（１）は、１：００〜４：００の再計算処理の一例を示す図である。
図２１Ｂのタイムスケジュール（２）は、５：００〜６：００の再計算処理の一例を示す図である。

２１０１は、ＣＰＵ２０１による１回目の再計算処理の一例を示す図である。
ＣＰＵ２０１により予約ＩＤ１６０４で配信予約されている画像形成装置の中で、最初の配信開始時刻１６０３は０：００である。ＣＰＵ２０１は、再計算処理を、配信開始時刻１６０３からポーリング間隔１６１０が経過したタイミングで実行するので、１：００に実行する。１：００の時点の再計算処理で対象となる画像形成装置は、１時間以内に全画像形成装置の反映が終わるので、２：００〜６：００に配信予約されている画像形成装置となる。
２１０２は、ＣＰＵ２０１による２回目の再計算処理の一例を示す図である。
ＣＰＵ２０１は、２１０１で１：００に再計算処理を実行したので、次に再計算処理（Ｓ１１０６以降の一連の処理）を実行するのは、２１０１からポーリング間隔１６１０が経過したタイミングの２：００となる。２：００の時点の再計算処理で対象となる画像形成装置は、１時間以内に全画像形成装置の反映が終わるので、３：００〜６：００に配信予約されている画像形成装置となる。

２１０３は、ＣＰＵ２０１による３回目の再計算処理の一例を示す図である。
ＣＰＵ２０１が３回目の再計算処理２１０３を実行するのは、２１０２からポーリング間隔１６１０が経過したタイミングの３：００となる。３：００の時点の再計算処理で対象となる画像形成装置は、１時間以内に全画像形成装置の反映が終わるので、４：００〜６：００に配信予約されている画像形成装置となる。
２１０４は、ＣＰＵ２０１による４回目の再計算処理の一例を示す図である。
ＣＰＵ２０１が４回目の再計算処理２１０４を実行するのは、２１０３からポーリング間隔１６１０が経過したタイミングの４：００となる。４：００の時点の再計算処理で対象となる画像形成装置は、１時間以内に全画像形成装置の反映が終わるので、５：００〜６：００に配信予約されている画像形成装置となる。
更に、ＣＰＵ２０１は、４：００の再計算処理では、時間通り配信を完了させるため、ポーリング間隔１６１０を配信想定時間１６１２と同じ値に変更し、ポーリング間隔を早める（Ｓ１１１２）。ポーリング間隔１６１０は、４：００の時点で４００秒とする。

２１０５は、ＣＰＵ２０１による５回目の再計算処理の一例を示す図である。
ＣＰＵ２０１が５回目の再計算処理２１０５を実行するのは、２１０４からポーリング間隔１６１０が経過したタイミングの５：００：００となる。５：００：００の時点の再計算処理で対象となる画像形成装置は、４００秒以内に全画像形成装置の反映が終わるので、５：０６：４０〜６：００：００に配信予約されている画像形成装置となる。更に、ＣＰＵ２０１は、５：００：００の再計算処理では、時間通り配信を完了させるため、ポーリング間隔１６１０を、５：００：００の時点の再計算処理で計算された配信想定時間１６１２と同じ値に変更し、ポーリング間隔を変更する（Ｓ１１１２）。ポーリング間隔（１６１０）は、５：００：００の時点で３００秒とする。
２１０６は、ＣＰＵ２０１による６回目の再計算処理の一例を示す図である。
ＣＰＵ２０１が６回目の再計算処理２１０６を実行するのは、２１０５からポーリング間隔１６１０が経過したタイミングの５：０６：４０となる。５：０６：４０時点の再計算処理で対象となる画像形成装置は、３００秒以内に全画像形成装置の反映が終わるので、５：１１：４０〜６：００：００に配信予約されている画像形成装置となる。更に、ＣＰＵ２０１は、５：０６：４０の再計算処理では、時間通り配信を完了させるため、ポーリング間隔１６１０を、５：０６：４０の時点の再計算処理で計算された配信想定時間１６１２と同じ値に変更し、ポーリング間隔を変更する（Ｓ１１１２）。ポーリング間隔１６１０は、５：０６：４０の時点で３００秒とする。

２１０７は、ＣＰＵ２０１による７回目の再計算処理の一例を示す図である。
ＣＰＵ２０１が７回目の再計算処理２１０７を実行するのは、２１０６からポーリング間隔１６１０が経過したタイミングの５：１１：４０となる。５：１１：４０時点の再計算処理で対象となる画像形成装置は、３００秒以内に全画像形成装置の反映が終わるので、５：１６：４０〜６：００：００に配信予約されている画像形成装置となる。更に、ＣＰＵ２０１は、５：１１：４０の再計算処理では、時間通り配信を完了させるため、ポーリング間隔１６１０を、５：１１：４０時点の再計算処理で計算された配信想定時間１６１２と同じ値に変更し、ポーリング間隔を変更する（Ｓ１１１２）。ポーリング間隔１６１０は、５：１１：４０の時点で３００秒とする。
以降、ＣＰＵ２０１は、配信終了時刻１６０９の６：００：００まで、再計算処理を繰り返すことで、６：００：００までに全画像形成装置の配信を完了させる。

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

以上、上述した実施形態の処理によれば、配信予約時間内にファームウェアのアップデートを完了することを可能とすることができる。

以上、本発明の好ましい形態について詳述したが、本実施形態は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

なお、上述した実施形態では、ＣＰＵ２０１は、数式を用いて配信想定時間を算出するよう説明した。しかし、ＣＰＵ２０１は、配信サーバのＨＤＤ２０４に予め格納されている、ファームウェアのサイズと、配信対象の画像形成装置の台数と、ネットワーク環境の通信速度と、配信想定時間とが対応付けられたテーブルに基づいて配信想定時間を取得してもよい。より具体的には、ＣＰＵ２０１は、前記ファームウェアのサイズと、前記画像形成装置の台数と、前記通信速度とに基づいて前記テーブルを参照し、対応する配信想定時間を求め、取得するようにしてもよい。

Claims (9)

1. ネットワークを介して通信可能な少なくとも１台以上の画像形成装置にファームウェアを配信する際の配信スケジュールを登録する登録手段と、
   前記ファームウェアのサイズと、ネットワーク環境情報とに基づいて、配信対象の前記画像形成装置に対して前記ファームウェアを配信するのに要すると想定される配信想定時間を取得する取得手段と、
   前記ファームウェアを配信した際の配信時間と、前記取得手段により取得された前記配信想定時間との差が、閾値以内であるか否かを判断する判断手段と、
   前記判断手段により閾値以内であると判断された場合、前記画像形成装置からの配信情報要求に対して、前記登録手段により登録されている配信スケジュールを応答する第１の応答手段と、
   前記画像形成装置からのファームウェアの配信要求に対して、ファームウェアについての情報を応答する第２の応答手段と、
   を有し、
   前記第１の応答手段は、前記判断手段により閾値以内でないと判断された場合、前記画像形成装置からの要求に対して、前記ファームウェアを配信した際の配信時間に基づいて再スケジュールされた配信スケジュールと、前記画像形成装置に配信スケジュールの定期的な問い合わせを行わせる指示とを応答することを特徴とする配信システム。
2. 前記第２の応答手段は、前記ファームウェアを配信した際の配信時間が、前記取得手段により取得された前記配信想定時間よりも短い場合、前記登録手段により登録されている配信スケジュールにおける前記配信対象の画像形成装置の台数を、前記配信時間に基づいて配信可能な分だけ追加するよう前記配信スケジュールを再スケジュールして前記画像形成装置からの配信要求に応答することを特徴とする請求項１に記載の配信システム。
3. 前記第２の応答手段は、前記ファームウェアを配信した際の配信時間が、前記取得手段により取得された前記配信想定時間よりも長い場合、前記登録手段により登録されている配信スケジュールにおける前記配信対象の画像形成装置の台数を、前記配信時間に基づいて配信不可能な分だけ削減し、削減した台数分に対する前記ファームウェアの配信を翌日以降で再スケジュールするか、又はキャンセルして前記画像形成装置からの配信要求に応答することを特徴とする請求項１に記載の配信システム。
4. 前記ファームウェアについての情報には、前記ファームウェアの格納場所情報であるアドレス情報が含まれることを特徴とする請求項１乃至３の何れか１項に記載の配信システム。
5. 前記定期的な問い合わせを行わせる指示には、問い合わせ間隔を示す時間情報が含まれることを特徴とする請求項１乃至４の何れか１項に記載の配信システム。
6. 前記定期的な問い合わせを行わせる指示に従い、前記画像形成装置による前記問い合わせが、ファームウェアの配信終了時刻まで実行されることを特徴とする請求項１乃至５の何れか１項に記載の配信システム。
7. 前記登録手段により登録されている前記配信スケジュールには、ユーザにより予約設定された前記ファームウェアの配信予約時間が含まれ、
   前記配信予約時間と、前記取得手段により取得された前記配信想定時間との比較に基づいて、前記配信予約時間以内に前記ファームウェアの配信が完了するか否かを判断する配信可否判断手段を更に有し、
   前記登録手段は、前記配信可否判断手段により配信不可能と判断された場合、ユーザにより再スケジュールされた配信スケジュールを新たな配信スケジュールとして登録する請求項１乃至６の何れか１項に記載の配信システム。
8. ネットワークを介して通信可能な少なくとも１台以上の画像形成装置にファームウェアを配信する際の配信スケジュールを登録する登録ステップと、
   前記ファームウェアのサイズと、ネットワーク環境情報とに基づいて、配信対象の前記画像形成装置に対して前記ファームウェアを配信するのに要すると想定される配信想定時間を取得する取得ステップと、
   前記ファームウェアを配信した際の配信時間と、前記取得ステップにより取得された前記配信想定時間との差が、閾値以内であるか否かを判断する判断ステップと、
   前記判断ステップにより閾値以内であると判断された場合、前記画像形成装置からの配信情報要求に対して、前記登録ステップにより登録されている配信スケジュールを応答する第１の応答ステップと、
   前記画像形成装置からのファームウェアの配信要求に対して、ファームウェアについての情報を応答する第２の応答ステップと、
   を含み、
   前記第１の応答ステップでは、前記判断ステップにより閾値以内でないと判断された場合、前記画像形成装置からの要求に対して、前記ファームウェアを配信した際の配信時間に基づいて再スケジュールされた配信スケジュールと、前記画像形成装置に配信スケジュールの定期的な問い合わせを行わせる指示を応答することを特徴とする情報処理方法。
9. コンピュータに、
   ネットワークを介して通信可能な少なくとも１台以上の画像形成装置にファームウェアを配信する際の配信スケジュールを登録する登録ステップと、
   前記ファームウェアのサイズと、ネットワーク環境情報とに基づいて、配信対象の前記画像形成装置に対して前記ファームウェアを配信するのに要すると想定される配信想定時間を取得する取得ステップと、
   前記ファームウェアを配信した際の配信時間と、前記取得ステップにより取得された前記配信想定時間との差が、閾値以内であるか否かを判断する判断ステップと、
   前記判断ステップにより閾値以内であると判断された場合、前記画像形成装置からの配信情報要求に対して、前記登録ステップにより登録されている配信スケジュールを応答する第１の応答ステップと、
   前記画像形成装置からのファームウェアの配信要求に対して、ファームウェアについての情報を応答する第２の応答ステップと、
   を実行させ、
   前記第１の応答ステップでは、前記判断ステップにより閾値以内でないと判断された場合、前記画像形成装置からの要求に対して、前記ファームウェアを配信した際の配信時間に基づいて再スケジュールされた配信スケジュールと、前記画像形成装置に配信スケジュールの定期的な問い合わせを行わせる指示を応答することを特徴とするプログラム。

Images