JP5803886B2 - 画像形成装置およびプログラム - Google Patents

Description

本発明は、ＭＦＰ（マルチ・ファンクション・ペリフェラル（Multi-Functional Peripheral））などの画像形成装置およびそれに関連する技術に関する。

端末装置のアップデートデータを送信する技術が存在する。たとえば、特許文献１においては、アップデートデータ配信装置（たとえばサーバ）を頂点として複数の端末装置を階層構造で多層に論理接続し、上位階層の端末装置から下位階層の端末装置へと順次にアップデートデータを送信していく技術が示されている。この技術によれば、アップデートデータ配信装置（サーバ等）への負荷集中を緩和することが可能である。

特開２００７−３３４６０２号公報

ところで、複数の画像形成装置（ＭＦＰ等）においてそのファームウエアなどのプログラムをアップデートする際においても、アップデートデータ配信装置（サーバ等）への負担を軽減することが好ましい。

上記特許文献１の技術を用いることによれば、アップデートデータ配信装置（サーバ等）への負担を軽減することが可能である。

しかしながら、上記特許文献１に記載の技術において、階層構造内の或る端末装置からその下位階層の複数の端末装置に対してアップデートデータを配信する際に、当該複数の端末装置の中に非常に高い負荷の処理を実行している端末装置（高負荷装置）が含まれている場合に、次のような問題が生じ得る。

具体的には、当該複数の端末装置のうち高負荷装置へのアップデート処理を先に行った場合には、当該高負荷装置へのアップデート処理に非常に長い時間を要し、当該高負荷装置へのアップデート処理の完了が大きく遅延する。そのため、複数の端末装置のうち当該高負荷装置を含む比較的多数の装置に対するアップデート処理の完了が遅延する。

そこで、この発明の課題は、さらに効率的にアップデート処理を実行することが可能な技術を提供することにある。

上記課題を解決すべく、請求項１の発明は、階層構造で複数層に論理接続される多数の画像形成装置のうちのいずれかの画像形成装置であって、前記画像形成装置よりも１つ下位階層の複数の画像形成装置である複数の子装置のそれぞれの処理余力を取得する状態取得手段と、前記複数の子装置に対して、各装置のファームウエアに関するアップデートデータを送信する配信制御手段と、を備え、前記配信制御手段は、前記複数の子装置の各処理余力に基づいて前記複数の子装置に関する配信順序を決定し、当該配信順序に従って前記複数の子装置に対して前記アップデートデータを送信することを特徴とする。

請求項２の発明は、請求項１の発明に係る画像形成装置において、前記配信制御手段は、前記複数の子装置のうち、最も高い処理余力を有する装置を優先送信先装置として決定し、前記複数の子装置のうち前記優先送信先装置に向けて他の装置よりも先に前記アップデートデータを送信することを特徴とする。

請求項３の発明は、請求項１または請求項２の発明に係る画像形成装置において、前記配信制御手段は、前記複数の子装置のうちの特定の子装置の処理余力が第１の基準値よりも大きいことを条件に、前記特定の子装置への前記アップデートデータの送信動作を実行することを特徴とする。

請求項４の発明は、請求項１ないし請求項３のいずれかの発明に係る画像形成装置において、前記配信制御手段は、前記画像形成装置の処理余力が第２の基準値よりも大きいことを条件に、前記複数の子装置への前記アップデートデータの送信動作を実行することを特徴とする。

請求項５の発明は、請求項１ないし請求項４のいずれかの発明に係る画像形成装置において、前記状態取得手段は、前記複数の子装置のうちの一の装置における実行処理種類の変更に応じて前記一の装置の処理余力を前記一の装置から随時取得し、前記配信制御手段は、前記状態取得手段によって随時取得された前記一の装置の処理余力にも基づいて、前記配信順序を随時決定することを特徴とする。

請求項６の発明は、請求項１ないし請求項５のいずれかの発明に係る画像形成装置において、前記配信順序に関するユーザ指示を受け付ける受付手段、をさらに備え、前記配信制御手段は、前記ユーザ指示が存在する場合には、当該ユーザ指示を反映して前記配信順序を決定することを特徴とする。

請求項７の発明は、請求項１ないし請求項６のいずれかの発明に係る画像形成装置において、前記各処理余力は、前記複数の子装置のそれぞれにおいて利用可能なＣＰＵリソースに応じた指標値として取得されることを特徴とする。

請求項８の発明は、請求項１ないし請求項６のいずれかの発明に係る画像形成装置において、前記各処理余力は、前記複数の子装置のそれぞれにおいて利用可能なメモリリソースに応じた指標値として取得されることを特徴とする。

請求項９の発明は、請求項１ないし請求項６のいずれかの発明に係る画像形成装置において、前記各処理余力は、前記複数の子装置のそれぞれにおいて利用可能なネットワーク通信リソースに応じた指標値として取得されることを特徴とする。

請求項１０の発明は、請求項１ないし請求項６のいずれかの発明に係る画像形成装置において、前記各処理余力は、前記複数の子装置のそれぞれにおいて利用可能なネットワーク通信リソース、ＣＰＵリソースおよびメモリリソースの少なくとも１つの要素を含む複数の要素に応じた指標値として取得されることを特徴とする。

請求項１１の発明は、請求項１０の発明に係る画像形成装置において、前記各処理余力は、前記複数の要素にそれぞれ対応する複数の指標値のうち、最も低い処理能力に対応する値として取得されることを特徴とする。

請求項１２の発明は、請求項１０の発明に係る画像形成装置において、前記各処理余力は、前記複数の要素にそれぞれ対応する複数の指標値の加重平均値として取得されることを特徴とする。

請求項１３の発明は、階層構造で複数層に論理接続される多数の画像形成装置のうちのいずれかの画像形成装置に内蔵されたコンピュータに、ａ）前記画像形成装置よりも１つ下位の階層の複数の画像形成装置である複数の子装置のそれぞれの処理余力を取得するステップと、ｂ）前記複数の子装置の各処理余力に基づいて前記複数の子装置に対する配信順序を決定するステップと、ｃ）前記配信順序に従って前記複数の子装置に対してアップデートデータを送信するステップと、を実行させるためのプログラムであることを特徴とする。
請求項１４の発明は、階層構造で複数層に論理接続される多数の画像形成装置のうちのいずれかの画像形成装置であって、各装置のファームウエアに関するアップデートデータを受信するデータ取得手段と、前記アップデートデータが前記データ取得手段によって受信されると、前記画像形成装置よりも１つ下位階層の複数の画像形成装置である複数の子装置のそれぞれの処理余力を取得する状態取得手段と、前記複数の子装置の各処理余力に基づいて前記複数の子装置に関する配信順序を決定するとともに、当該配信順序に従って前記複数の子装置に対して前記アップデートデータの送信を開始する配信制御手段と、を備え、前記状態取得手段は、前記アップデートデータの送信が未だ開始されていない装置である未送信先装置のうちの一の装置であって、前記複数の子装置のうち実行処理状況の変更が生じた一の装置の処理余力を前記一の装置から再び取得し、前記配信制御手段は、再び取得された前記一の装置の処理余力にも基づいて前記未送信先装置に関する配信順序を決定し直し、決定し直された当該配信順序に従って前記未送信先装置に対して前記アップデートデータを送信することを特徴とする。
請求項１５の発明は、階層構造で複数層に論理接続される多数の画像形成装置のうちのいずれかの画像形成装置であって、各装置のファームウエアに関するアップデートデータを受信するデータ取得手段と、前記アップデートデータが前記データ取得手段によって受信されると、前記画像形成装置よりも１つ下位階層の複数の画像形成装置である複数の子装置のそれぞれの処理余力を取得する状態取得手段と、当該各処理余力に基づいて前記複数の子装置に関する配信順序を決定するとともに、当該配信順序に従って前記複数の子装置に対して前記アップデートデータの送信を開始する配信制御手段と、を備え、前記状態取得手段は、前記複数の子装置のうち前記アップデートデータの送信が未だ開始されていない装置である未送信先装置のうちの少なくとも一の装置の処理余力を再び取得し、前記配信制御手段は、再び取得された前記少なくとも一の装置の処理余力にも基づいて前記未送信先装置に関する配信順序を一定時間間隔で決定し直し、決定し直された当該配信順序に従って前記未送信先装置に対して前記アップデートデータを送信することを特徴とする。
請求項１６の発明は、請求項１４または請求項１５の発明に係る画像形成装置において、前記配信制御手段は、前記複数の子装置のうち処理余力が所定の基準値よりも大きい子装置に対して、前記アップデートデータの送信を開始し、前記複数の子装置のうち処理余力が前記所定の基準値よりも小さい子装置に対しては、前記アップデートデータの送信を開始しないことを特徴とする。
請求項１７の発明は、階層構造で複数層に論理接続される多数の画像形成装置のうちのいずれかの画像形成装置に内蔵されたコンピュータに、ａ）各装置のファームウエアに関するアップデートデータを受信するステップと、ｂ）前記アップデートデータが前記ステップａ）にて受信されると、前記画像形成装置よりも１つ下位階層の複数の画像形成装置である複数の子装置のそれぞれの処理余力を取得するステップと、ｃ）前記複数の子装置の各処理余力に基づいて前記複数の子装置に関する配信順序を決定するステップと、ｄ）当該配信順序に従って前記複数の子装置に対して前記アップデートデータの送信を開始するステップと、ｅ）前記アップデートデータの送信が未だ開始されていない装置である未送信先装置のうちの一の装置であって、前記複数の子装置のうち実行処理状況の変更が生じた一の装置の処理余力を前記一の装置から再び取得するステップと、ｆ）前記ステップｅ）にて再び取得された前記一の装置の処理余力にも基づいて前記未送信先装置に関する配信順序を決定し直すステップと、ｇ）前記ステップｆ）にて決定し直された当該配信順序に従って前記未送信先装置に対して前記アップデートデータを送信するステップと、を実行させるためのプログラムであることを特徴とする。
請求項１８の発明は、階層構造で複数層に論理接続される多数の画像形成装置のうちのいずれかの画像形成装置に内蔵されたコンピュータに、ａ）各装置のファームウエアに関するアップデートデータを受信するステップと、ｂ）前記アップデートデータが前記ステップａ）にて受信されると、前記画像形成装置よりも１つ下位階層の複数の画像形成装置である複数の子装置のそれぞれの処理余力を取得するステップと、ｃ）当該各処理余力に基づいて前記複数の子装置に関する配信順序を決定するステップと、ｄ）当該配信順序に従って前記複数の子装置に対して前記アップデートデータの送信を開始するステップと、ｅ）前記複数の子装置のうち前記アップデートデータの送信が未だ開始されていない装置である未送信先装置のうちの少なくとも一の装置の処理余力を再び取得するステップと、ｆ）前記ステップｅ）にて再び取得された前記少なくとも一の装置の処理余力にも基づいて前記未送信先装置に関する配信順序を一定時間間隔で決定し直すステップと、ｇ）前記ステップｆ）にて決定し直された当該配信順序に従って前記未送信先装置に対して前記アップデートデータを送信するステップと、を実行させるためのプログラムであることを特徴とする。
請求項１９の発明は、請求項１７または請求項１８の発明に係るプログラムにおいて、前記ステップｄ）においては、前記複数の子装置のうち処理余力が所定の基準値よりも大きい子装置に対して、前記アップデートデータの送信が開始され、前記複数の子装置のうち処理余力が前記所定の基準値よりも小さい子装置に対しては、前記アップデートデータの送信が開始されないことを特徴とする。

請求項１ないし請求項１９に記載の発明によれば、比較的多くの子装置へのデータ送信処理を早期に完了することが可能である。したがって、効率的なアップデート処理を実行することが可能である。

特に、請求項３に記載の発明によれば、特定の子装置における実行中処理の大きな効率低下を回避しつつ、効率的なアップデート処理を実行することが可能である。

また特に、請求項４に記載の発明によれば、当該画像形成装置自身における実行中処理の大きな効率低下を回避しつつ、効率的なアップデート処理を実行することが可能である。

また特に、請求項５に記載の発明によれば、複数の子装置のうちの一の装置における実行処理種類の変更に応じて当該一の装置の処理余力が当該一の装置から随時取得される。したがって、子装置の処理余力を比較的早期に知得して、子装置への配信動作を早い段階で変更することが可能である。

また特に、請求項６に記載の発明によれば、ユーザの事情に応じて、アップデートデータの配信順序を柔軟に変更することが可能である。

第１実施形態に係る画像形成システムを示す図である。 ＭＦＰの概略構成を示す機能ブロック図である。 親装置の動作を示すフローチャートである。 子装置の動作を示すフローチャートである。 画像形成システムにおける配信動作を示す概念図である。 ＣＰＵリソースに関する処理余力を示す図である。 ネットワークリソースに関する処理余力を示す図である。 メモリリソースに関する処理余力を示す図である。 画像形成システムにおける配信動作を示す概念図である。 画像形成システムにおける配信動作を示す概念図である。 画像形成システムにおける配信動作を示す概念図である。 画像形成システムにおける配信動作を示す概念図である。 変形例に係る画像形成システムを示す図である。 第２実施形態に係る親装置の動作を示すフローチャートである。 第２実施形態に係る親装置の動作を示すフローチャートである。 第２実施形態に係る子装置の動作を示すフローチャートである。 画像形成システムにおける配信動作を示す概念図である。 画像形成システムにおける配信動作を示す概念図である。 第３実施形態に係る親装置の動作を示すフローチャートである。 複数の子装置の優先順位を指定する設定画面を示す図である。 複数の子装置の優先順位を指定する設定画面を示す図である。 第４実施形態に係る親装置の動作を示すフローチャートである。

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

＜１．第１実施形態＞
＜１−１．構成概要＞
図１は、第１実施形態に係る画像形成システム１を示す図である。図１に示すように、この画像形成システム１は、複数の画像形成装置１０を備える。また、画像形成システム１は、サーバコンピュータ（単にサーバとも称する）５０をも備える。

本システム１における各要素１０，５０は、それぞれ、ネットワークＮＷを介して互いに通信可能に接続される。ネットワークＮＷは、ＬＡＮ（Local Area Network）およびインターネットなどによって構成される。より詳細には、複数の画像形成装置１０は、或るＬＡＮ（たとえば社内ネットワーク）に接続され、サーバ５０は当該ＬＡＮの外部のネットワークに接続される。そして、画像形成装置１０とサーバ５０とはいわゆるインターネットを介して接続される。なお、ネットワークＮＷに対する接続態様は、有線接続であってもよく、或いは無線接続であってもよい。

システム１においては、各画像形成装置１０のファームウエアのアップデートデータ（更新用データ）がサーバコンピュータ５０から各画像形成装置１０へと配信される。そのため、システム１は、アップデートデータ配信システムであるとも称され、サーバ５０は、アップデートデータ配信装置であるとも称される。

このシステム１においては、アップデートデータ配信装置（サーバ）５０を頂点として多数の画像形成装置１０が階層構造で多層（複数層）に論理接続される。

ここで、階層構造で多層に論理接続される多数の画像形成装置のうち、所定の装置の１つ下位階層（直下の階層）の装置であって当該所定の装置に対して直接的に論理接続されている装置を、当該所定の装置に関する「子装置」（ないし送信先装置）と称するものとする。また、階層構造で多層に論理接続される複数の画像形成装置のうち、所定の装置の１つ上位階層（直上の階層）の装置であって当該所定の装置に対して直接的に論理接続されている装置を、当該所定の装置に関する「親装置」（ないし送信元装置）と称するものとする。

システム１における各画像形成装置１０は、自装置の「親装置」（直系の上位階層の画像形成装置）と「子装置」（直系の下位階層の画像形成装置）との双方を知得している。具体的には、各画像形成装置１０は、それぞれの格納部５（図２）（後述）内に階層構造情報ＨＭを記憶している。階層構造情報ＨＭには、当該画像形成装置１０の「親装置」の識別番号およびネットワークアドレス等、ならびに当該画像形成装置１０の「子装置」の識別番号およびネットワークアドレス等が記憶されている。階層構造情報ＨＭは、管理者による操作等に応じて生成され、画像形成装置１０（格納部５）内に格納される。

そして、本システム１においては、比較的上位階層の画像形成装置１０から比較的下位階層の画像形成装置１０へと順次にアップデートデータＵＤが送信される。詳細には、親装置から子装置へとアップデートデータＵＤが送信され、さらに当該子装置から当該子装置の子装置（孫装置とも称する）へとアップデートデータＵＤが送信される。このように複数の階層（複数の世代）にわたってアップデートデータＵＤが順次に転送される。なお、以下では、第ｉ階層ＬＶｉの画像形成装置１０を装置ＡＲｉなどとも表記する。

具体的には、図１に示すように、まず、サーバ５０から、ゲートウエイＧＷを介して、第１階層（最上位階層）ＬＶ１の画像形成装置１０（装置ＡＲ１）へと、アップデートデータＵＤが送信される。

その後、第１階層ＬＶ１の画像形成装置１０（装置ＡＲ１）が、その「子装置」である第２階層ＬＶ２の画像形成装置１０（装置ＡＲ２（詳細にはＡＲ２１，ＡＲ２２））へとアップデートデータＵＤを送信する。

さらに、第２階層ＬＶ２の画像形成装置１０（装置ＡＲ２（ＡＲ２１，ＡＲ２２））が、それぞれの「子装置」である第３階層ＬＶ３の画像形成装置１０（装置ＡＲ３）へとアップデートデータＵＤを送信する。より詳細には、第２階層ＬＶ２の装置ＡＲ２１が、その「子装置」である第３階層ＬＶ３の画像形成装置１０（装置ＡＲ３（ＡＲ３１，ＡＲ３２））へとアップデートデータＵＤを送信する。同様に、第２階層ＬＶ２の装置ＡＲ２２が、その「子装置」である第３階層ＬＶ３の画像形成装置１０（装置ＡＲ３（ＡＲ３３，ＡＲ３４））へとアップデートデータＵＤを送信する。

このように、ＬＡＮ内において、比較的上位階層の画像形成装置１０（詳細には、「親装置」）から比較的下位階層の画像形成装置１０（詳細には、「子装置」）へと順次にアップデートデータＵＤが送信される。これによれば、サーバ５０からのデータ転送は最初の１回のみで済む。そのため、各画像形成装置１０が個別にサーバ５０から直接的にアップデートデータＵＤを受信する場合に比べて、サーバ５０（アップデートデータ配信装置）への負荷集中を緩和することが可能である。

なお、ここでは、複数の画像形成装置１０が３層の階層構造で論理接続される態様が例示されるが、これに限定されない。たとえば、複数の画像形成装置１０が２層の階層構造で論理接続されるようにしてもよく、あるいは、４層以上の階層構造で論理接続されるようにしてもよい。

また、ここでは、１つの親装置に対して２つの子装置が論理接続される態様が例示されるが、これに限定されない。たとえば、１つの親装置に対して３つ以上の子装置が論理接続されるようにしてもよい（図１３参照）。図１３においては、親装置ＡＲ２２に対して３つの「子装置」ＡＲ３（ＡＲ３３，ＡＲ３４，ＡＲ３５））が論理接続される態様が示されている。また、全ての親装置に対してそれぞれ複数の子装置が論理接続されていることを要さず、たとえば一部の親装置に対しては単一の子装置のみが論理接続されるようにしてもよい。ただし、アップデートデータＵＤの転送効率を向上させるためには、比較的多数の親装置に対して複数の「子装置」を論理接続してアップデートデータＵＤの分岐転送処理を行うことが好ましい。換言すれば、比較的下位階層の装置の数が比較的上位階層の装置の数よりも大きくなるように、階層構造が規定されることが好ましい。

＜１−２．画像形成装置１０の構成＞
この実施形態では、画像形成装置１０として、ＭＦＰ（マルチ・ファンクション・ペリフェラル（Multi-Functional Peripheral））を例示する。

図２は、ＭＦＰ１０の概略構成を示す機能ブロック図である。なお、ここでは最上位階層（第１階層）ＬＶ１のＭＦＰ１０（図１参照）の機能ブロックを中心に説明する。第２階層以下の各階層のＭＦＰ１０も同様の構成を有する。

ＭＦＰ１０は、スキャン機能、コピー機能、ファクシミリ機能およびボックス格納機能などを備える装置（複合機とも称する）である。具体的には、ＭＦＰ１０は、図２の機能ブロック図に示すように、画像読取部２、印刷出力部３、通信部４、格納部５、入出力部６およびコントローラ９等を備えており、これらの各部を複合的に動作させることによって、各種の機能を実現する。

画像読取部２は、ＭＦＰ１０の所定の位置に載置された原稿を光学的に読み取って（すなわちスキャンして）、当該原稿の画像データ（原稿画像なしいスキャン画像とも称する）を生成する処理部である。この画像読取部２は、スキャン部であるとも称される。

印刷出力部３は、印刷対象に関するデータに基づいて紙などの各種の媒体に画像を印刷出力する出力部である。

通信部４は、公衆回線等を介したファクシミリ通信を行うことが可能な処理部である。さらに、通信部４は、ネットワークＮＷを介したネットワーク通信を行うことも可能である。このネットワーク通信では、たとえば、ＴＣＰ／ＩＰ（Transmission Control Protocol / Internet Protocol）等の各種のプロトコルが利用される。当該ネットワーク通信を利用することによって、ＭＦＰ１０は、所望の相手先との間で各種のデータを授受することが可能である。

格納部５は、ハードディスクドライブ（ＨＤＤ）等の記憶装置で構成される。格納部５には、各種のデータが格納される。たとえば、格納部５には、各種の設定情報（階層構造情報ＨＭを含む）および各種ジョブに係る画像データ等が格納される。また、ＭＦＰ１０のファームウエア（プログラム）ＰＧ１に関するアップデートデータＵＤ等も格納部５に格納される。

入出力部６は、ＭＦＰ１０に対する入力を受け付ける操作入力部６ａと、各種情報の表示出力を行う表示部６ｂとを備えている。このＭＦＰ１０においては、液晶表示パネルに圧電センサ等が埋め込まれて構成されたタッチパネル（タッチスクリーンとも称する）を有する操作パネル部６ｃ（不図示）が設けられている。この操作パネル部６ｃは、操作入力部６ａの一部としても機能するとともに、表示部６ｂの一部としても機能する。

コントローラ９は、ＭＦＰ１０に内蔵され、ＭＦＰ１０を統括的に制御する制御装置である。コントローラ９は、ＣＰＵおよび各種の半導体メモリ（ＲＡＭおよびＲＯＭ）等を備えるコンピュータシステムとして構成される。コントローラ９は、ＣＰＵにおいて、ＲＯＭ（例えば、ＥＥＰＲＯＭ）内に格納されている所定のソフトウエアプログラム（ファームウエア、あるいは単にプログラムとも称する）ＰＧ１を実行することによって、各種の処理部を実現する。なお、当該プログラムＰＧ１は、ＵＳＢメモリなどの可搬性の記録媒体に記録され、当該記録媒体を介してＭＦＰ１０にインストールされるようにしてもよい。あるいは当該プログラムＰＧ１は、ネットワークＮＷ等を介してダウンロードされてＭＦＰ１０にインストールされるようにしてもよい。

図２に示すように、コントローラ９は、プログラムＰＧ１を実行することによって、状態取得部１１と状態通知部１２と配信制御部１５とデータ取得部１６とを含む各種の処理部を実現する。

状態取得部１１は、子装置１０から当該子装置１０の余力状態（負荷状態）を取得する処理部であり、状態通知部１２は、親装置１０に対して自装置１０の余力状態（負荷状態）を通知する処理部である。

具体的には、或る装置（親装置）（たとえば第１階層ＬＶ１の装置ＡＲ１）の状態取得部１１は、子装置（第２階層の装置ＡＲ２）に対して、処理余力の通知依頼（問合せ指令）ＲＱを送信し、当該子装置（第２階層の装置ＡＲ２）の状態通知部１２は、自装置（第２階層の装置ＡＲ２）の処理余力ＳＴを親装置（第１階層の装置ＡＲ１）に対して通知する。これにより、親装置（第１階層の装置ＡＲ１）の状態取得部１１は、子装置（第２階層の装置ＡＲ２）の処理余力ＳＴを取得する。同様に、さらに下位の階層の各装置においても同様の動作が実行される。たとえば、第２階層の装置（新たな親装置ＡＲ２）の状態取得部１１は、その子装置（第３階層の装置ＡＲ３）に対して、処理余力の通知依頼（問合せ指令）ＲＱを送信し、当該子装置（第３階層の装置ＡＲ３）の状態通知部１２は、自装置（第３階層の装置ＡＲ３）の処理余力ＳＴをその親装置（第２階層の装置ＡＲ２）に対して通知する。これにより、親装置（第２階層の装置ＡＲ２）の状態取得部１１は、子装置（第３階層の装置ＡＲ３）の処理余力ＳＴを取得する。

また、配信制御部（アップデートデータ送信制御部とも称する）１５は、アップデートデータを子装置に配信する動作を制御する処理部であり、データ取得部（アップデートデータ受信制御部とも称する）１６は、親装置からアップデートデータを受信する処理部である。

具体的には、或る装置のデータ取得部１６は、さらにその親装置からアップデートデータを受信する。たとえば、第１階層の装置ＡＲ１（親装置）のデータ取得部１６は、さらにその親装置（第０階層の装置（サーバ５０））からアップデートデータを受信する。そして、親装置（第１階層の装置）ＡＲ１の配信制御部１５は、さらにその親装置（第０階層の装置（サーバ５０））から取得したアップデートデータＵＤを子装置（第２階層の装置）ＡＲ２に配信する。子装置（第２階層の装置）ＡＲ２のデータ取得部１６は、親装置（第１階層の装置）ＡＲ１からアップデートデータＵＤを受信する。

同様に、さらに下位の階層の各装置においても同様の動作が実行される。たとえば、第２階層の装置（新たな親装置）ＡＲ２のデータ取得部１６は、さらにその親装置（第１階層の装置）ＡＲ１からアップデートデータを受信すると、当該新たな親装置（第２階層の装置）ＡＲ２の配信制御部１５は、その親装置（第１階層の装置）ＡＲ１から取得したアップデートデータＵＤを、当該装置ＡＲ２の子装置（第３階層の装置）ＡＲ３に配信する。そして、当該子装置（第３階層の装置）ＡＲ３のデータ取得部１６は、その親装置（第２階層の装置）ＡＲ２からアップデートデータＵＤを受信する。

また、後述するように、特に、親装置の配信制御部１５は、複数の子装置の各負荷状態（処理余力）に基づいて、当該複数の子装置の中から優先的にアップデートデータＵＤを送信すべき子装置を選択（決定）し、当該選択された子装置に対して優先的にアップデートデータＵＤを送信する。これによれば、アップデートデータＵＤの配信動作の効率を向上させることが可能である。

＜１−３．動作＞
つぎに、本システム１における動作を更に詳細に説明する。

上述のように、複数の画像形成装置１０は、多層に論理接続されている。そして、サーバ５０から最上位階層（第１階層）ＬＶ１の画像形成装置１０（ＡＲ１）に対してアップデートデータＵＤが送信された後において、比較的上位の階層の端末装置から比較的下位の階層の端末装置へと順次にアップデータが送信される。

以下では、まず、当該第１階層ＬＶ１の画像形成装置１０（親装置ＡＲ１）から次の第２階層ＬＶ２の画像形成装置１０（子装置ＡＲ２）へと当該アップデートデータＵＤがさらに転送される動作について説明する。

図３は、アップデートデータＵＤの転送元装置（親装置）の動作を示すフローチャートであり、図４は、アップデートデータＵＤの転送先装置（子装置）の動作を示すフローチャートである。また、図５は、画像形成システムにおける配信動作を示す概念図である。

まず、ステップＳ１１において、親装置である第１階層ＬＶ１の画像形成装置１０（装置ＡＲ１）が、サーバ５０からのアップデートデータＵＤの受信を完了したか否かを判定する。

自らによるアップデートデータＵＤの受信が完了していると判定されると、次のステップＳ１３に進む。ステップＳ１３では、親装置（比較的上位階層の装置）ＡＲ１は、処理余力ＳＴの通知依頼（負荷状態の通知依頼とも称される）ＲＱ（ＲＱ１）を、画像形成装置ＡＲ２（画像形成装置ＡＲ１の子装置ＡＲ２１，ＡＲ２２）にそれぞれ送信する（図５も参照）。

一方、図４に示すように、各子装置ＡＲ２１，ＡＲ２２は、それぞれ、親装置ＡＲ１からの通知依頼ＲＱ１を受信する（ステップＳ２１）。当該受信に応答して、各子装置ＡＲ２１，ＡＲ２２における処理は、それぞれ、ステップＳ２１からステップＳ２３に進む。そして、各子装置ＡＲ２１，ＡＲ２２は、自装置（ＡＲ２１あるいはＡＲ２２）の処理余力ＳＴ（詳細には、処理余力指数（後述））を取得するとともに当該処理余力ＳＴを親装置ＡＲ１に通知する（ステップＳ２３）。換言すれば、各子装置ＡＲ２１，ＡＲ２２は、それぞれ、自装置の負荷状態を取得するとともに当該負荷状態を親装置ＡＲ１に通知する。

図６は、画像形成装置１０のＣＰＵリソースに関する処理余力、より詳細には、新たな処理に割当可能な（利用可能な）ＣＰＵリソースに応じた指標値（処理余力指数とも称する）を示す図である。図６においては、画像形成装置１０における実行中の処理の種類（実行処理種類）との処理余力との関係が示されている。

図６の最上段においては、画像形成装置１０において「ＯＣＲ処理」が実行されているときには、ＣＰＵリソースのうちの９０％が使用されており（非常に高い負荷状態）、「１０％」の処理余力が存在することが示されている。同様に、画像形成装置１０において「リアルタイムプレビュー処理」が実行されているときには、ＣＰＵリソースのうちの７０％が使用されており、「３０％」の処理余力が存在することが示されている。また、画像形成装置１０において「コピー処理」が実行されているときには、ＣＰＵリソースのうちの４０％が使用されており、「６０％」の処理余力が存在することが示されている。さらに、画像形成装置１０が「アイドリング」状態であるときには、ＣＰＵリソースのうちの０％が使用されており、「１００％」の処理余力が存在することも示されている。

この実施形態においては、画像形成装置１０の処理余力がＣＰＵリソースの処理余力に基づいて判定される（ステップＳ２３）。たとえば、子装置ＡＲ２１が「コピー処理」中であるときには、当該子装置ＡＲ２１の処理余力（詳細には処理余力指数）は「６０％」であると判定される。また、子装置ＡＲ２２が「リアルタイムプレビュー処理」中であるときには、当該子装置ＡＲ２２の処理余力は「３０％」であると判定される。そして、各子装置ＡＲ２１，ＡＲ２２は、それぞれ、自装置ＡＲ２１，ＡＲ２２の処理余力「６０％」，「３０％」を親装置ＡＲ１に通知する（ステップＳ２３）。

その後、親装置ＡＲ１は、子装置ＡＲ２から返信されてきた処理余力通知ＮＴ２を取得する（図５も参照）。ステップＳ１４において、全ての子装置ＡＲ２１，ＡＲ２２からの処理余力通知ＮＴ２１，ＮＴ２２が受信された旨が判定されると、ステップＳ１５に進む。

ステップＳ１５においては、親装置ＡＲ１は、各処理余力通知ＮＴ２（ＮＴ２１，ＮＴ２２）によって通知された各子装置の処理余力に基づいて、アップデートデータＵＤの配信順序（送信順序）を決定する。具体的には、親装置ＡＲ１の配信制御部１５は、アップデートデータＵＤを未だ送信していない複数の子装置ＡＲ２１，ＡＲ２２のうち、最も高い処理余力を有する装置を「優先送信先装置」として決定する。たとえば、図５に示すように、子装置ＡＲ２１の処理余力が６０％であり、子装置ＡＲ２２の処理余力が３０％であるときには、比較的大きな処理余力を有する子装置ＡＲ２１が「優先送信先装置」として決定される。換言すれば、子装置ＡＲ２１が第１の優先順位を有する送信先装置として決定される。また、子装置ＡＲ２２は、第２の優先順位を有する送信先装置として決定される。このように、全ての子装置ＡＲ２１，ＡＲ２２のそれぞれについて配信順位（配信先としての優先順位）が決定される。

そして、ステップＳ１６において、親装置ＡＲ１の配信制御部１５は、当該配信順位（送信順位とも称する）に従って複数の子装置ＡＲ２１，ＡＲ２２に対してアップデートデータＵＤを送信する。具体的には、まず、複数の子装置ＡＲ２１，ＡＲ２２のうち、優先送信先装置（第１順位の送信先装置）ＡＲ２１に向けて他の装置（ＡＲ２２）よりも優先的に（先に）アップデートデータＵＤ（ＤＳ１）が送信される（図９も参照）。そして、第１順位の子装置ＡＲ２１向けのアップデートデータＵＤの送信完了後に、第２順位の子装置ＡＲ２２に向けてアップデートデータＵＤが送信される（図１０も参照）。

全ての子装置ＡＲ２１，ＡＲ２２へのアップデートデータＵＤの配信が完了した旨がステップＳ１９で判定されると、親装置ＡＲ１における図３の動作は終了する。

このようにして、第１階層の画像形成装置ＡＲ１から第２階層の画像形成装置ＡＲ２への転送動作が完了する（図５参照）。

同様に、第２階層の画像形成装置ＡＲ２から第３階層の画像形成装置ＡＲ３への転送動作が実行される（図５参照）。

具体的には、第２階層の画像形成装置ＡＲ２１から第３階層の画像形成装置ＡＲ３１，ＡＲ３２への転送動作が実行されるとともに、第２階層の画像形成装置ＡＲ２２から第３階層の画像形成装置ＡＲ３３，ＡＲ３４への転送動作が実行される。

この際には、第２階層の画像形成装置ＡＲ２１が第３階層の画像形成装置ＡＲ３１，ＡＲ３２の親装置として機能し、第２階層の画像形成装置ＡＲ２２が第３階層の画像形成装置ＡＲ３３，ＡＲ３４の親装置として機能する。逆に言えば、第３階層の画像形成装置ＡＲ３１，ＡＲ３２が第２階層の画像形成装置ＡＲ２１の子装置として機能し、第３階層の画像形成装置ＡＲ３３，ＡＲ３４が第２階層の画像形成装置ＡＲ２２の子装置として機能する。

たとえば、第２階層の画像形成装置ＡＲ２１から第３階層の画像形成装置ＡＲ３１，ＡＲ３２への転送動作は、次のようにして行われる。

まず、ステップＳ１１において、親装置である第２階層ＬＶ２の画像形成装置１０（装置ＡＲ２１）が、第１階層ＬＶ１の画像形成装置１０（更なる親装置ＡＲ１）からのアップデートデータＵＤの受信を完了したか否かを判定する。

自らによるアップデートデータＵＤの受信が完了していると判定されると、次のステップＳ１３に進む。ステップＳ１３では、親装置（比較的上位階層の装置）ＡＲ２１は、処理余力の通知依頼ＲＱ（ＲＱ２）を、画像形成装置ＡＲ３（画像形成装置ＡＲ２の子装置ＡＲ３１，ＡＲ３２）にそれぞれ送信する（図５も参照）。

一方、各子装置ＡＲ３１，ＡＲ３２は、それぞれ、図４に示すように、親装置ＡＲ２から通知依頼ＲＱ２を受信すると、ステップＳ２１からステップＳ２３に進み、自装置（ＡＲ３１あるいはＡＲ３２）の処理余力（詳細には、処理余力状況）を取得するとともに当該処理余力を親装置ＡＲ２に通知する。

その後、親装置ＡＲ２１は、子装置ＡＲ３１，ＡＲ３２から返信されてきた処理余力通知ＮＴ３（ＮＴ３１，ＮＴ３２）を取得する。ステップＳ１４において、全ての子装置ＡＲ３１，ＡＲ３２からの処理余力通知ＮＴ３１，ＮＴ３２が受信された旨が判定されると、ステップＳ１５に進む。

ステップＳ１５においては、親装置ＡＲ２１は、受信した全ての処理余力通知ＮＴ３１，ＮＴ３２に基づいて、アップデートデータＵＤの配信順序を決定する。具体的には、親装置ＡＲ２１の配信制御部１５は、アップデートデータＵＤを未だ送信していない複数の子装置ＡＲ３１，ＡＲ３２のうち、最も高い処理余力を有する装置を「優先送信先装置」として決定する。たとえば、図５に示すように、子装置ＡＲ３１の処理余力が３０％であり、子装置ＡＲ３２の処理余力が６０％であるときには、比較的大きな処理余力を有する子装置ＡＲ３２が「優先送信先装置」として決定される。換言すれば、子装置ＡＲ３２が第１の優先順位を有する送信先装置として決定される。また、子装置ＡＲ３１は、第２の優先順位を有する送信先装置として決定される。このように、全ての子装置ＡＲ３１，ＡＲ３２のそれぞれについて配信順位（配信先としての優先順位）が決定される。

そして、ステップＳ１６において、親装置ＡＲ２の配信制御部１５は、当該配信順位に従って複数の子装置ＡＲ３１，ＡＲ３２に向けてアップデートデータＵＤを送信する。具体的には、まず、複数の子装置ＡＲ３１，ＡＲ３２のうち、優先送信先装置（第１順位の送信先装置）ＡＲ３２に向けて他の装置（ＡＲ３１）よりも優先的に（先に）アップデートデータＵＤの送信を実行する（図１０も参照）。そして、第１順位の子装置ＡＲ３２向けのアップデートデータＵＤの送信完了後に、第２順位の子装置ＡＲ３１に向けてアップデートデータＵＤが送信される（図１１も参照）。

全ての子装置ＡＲ３１，ＡＲ３２へのアップデートデータＵＤの配信が完了すると、親装置ＡＲ２１における図３の動作は終了する。

このようにして、第２階層の画像形成装置ＡＲ２１から第３階層の画像形成装置ＡＲ３１，ＡＲ３２への転送動作が完了する（図５参照）。

同様にして、第２階層の画像形成装置ＡＲ２２から第３階層の画像形成装置ＡＲ３３，ＡＲ３４への転送動作も実行される（図５参照）。

なお、装置ＡＲ１から装置ＡＲ２１へのアップデートデータＵＤの転送が完了（図９参照）すると、装置ＡＲ１から装置ＡＲ２２へのアップデートデータＵＤの転送処理と、装置ＡＲ２１から装置ＡＲ３２へのアップデートデータＵＤの転送処理とがほぼ同時期に開始される（図１０参照）。この結果、特に、第３階層の装置のうちの装置ＡＲ３２に対しては、比較的早期にアップデートデータＵＤが配信され得る。また、その後、装置ＡＲ２２，ＡＲ２１の負荷状況等にも依存するが、更なる転送処理が適宜の順序で実行される。たとえば、装置ＡＲ２１から装置ＡＲ３１へのアップデートデータＵＤの転送処理（図１１参照）、装置ＡＲ２２から装置ＡＲ３３へのアップデートデータＵＤの転送処理（図１１参照）、および装置ＡＲ２２から装置ＡＲ３４へのアップデートデータＵＤの転送処理（図１２参照）がこの順序で実行される。

以上のような態様においては、親装置ＡＲ１は、まず、複数の子装置ＡＲ２１，ＡＲ２２のうち、最も高い処理余力を有する（最も低い負荷状態の）子装置ＡＲ２１から順次にアップデートデータの送信処理を実行する。

これによれば、最も高い処理余力を有する子装置ＡＲ２１へのデータ送信処理を比較的早期に完了することができる。したがって、最も低い処理余力を有する（最も高い負荷状態の）の子装置（たとえば子装置ＡＲ２２）へのデータ送信処理から実行する場合に比べて、複数の子装置のうちの一の子装置へのデータ送信処理を早期に完了することができる。また、その後、比較的高い処理余力を有する子装置へのデータ送信処理が順次に実行される。そのため、より多数の子装置（たとえば、装置ＡＲ２１，ＡＲ３２，...）へのデータ転送処理を早期に完了することが可能である。換言すれば、複数の画像形成装置１０のうち高負荷装置へのアップデート処理を先に行った場合に比べて、アップデート終了前の或る時点におけるアップデートデータ受信済み装置の台数を増大させることが可能である。

また、低負荷状態の子装置ＡＲ２１への配信開始時点では高負荷状態であった子装置ＡＲ２２の負荷状況は、当該子装置ＡＲ２２における実行中の処理が子装置ＡＲ２１への配信処理期間内に完了することなどによって、好転（低負荷化）することも多い。したがって、子装置ＡＲ２１へのアップデートデータ送信処理を先に行い、子装置ＡＲ２２に対するアップデートデータ送信処理を後回しにすることによれば、子装置ＡＲ２２に対するアップデートデータ処理に要する時間の長大化を抑制することも可能である。そのため、非常に効率的な配信動作を行うことが可能である。

なお、上記においては、画像形成装置１０の処理余力がＣＰＵリソースに応じた処理余力指数に基づいて判定されている（ステップＳ１５）が、これに限定されない。たとえば、画像形成装置１０の処理余力は画像形成装置１０のネットワーク通信リソースの処理余力（図７参照）に基づいて判定されるようにしてもよい。

図７は、このような態様を示す図である。図７は、画像形成装置１０のネットワーク通信リソース（ネットワーク通信速度）に関する処理余力、より詳細には、画像形成装置１０において新たな処理に割当可能な（利用可能な）ネットワーク通信リソースに応じた指標値（処理余力指数）を示す図である。図７においては、実行中の処理との処理余力との関係が示されている。

図７の最上段においては、画像形成装置１０にて「プリントデータ受信」処理が実行されているときには、ネットワークリソースのうちの７０％が使用されており、「３０％」の処理余力が存在することが示されている。同様に、画像形成装置１０において「スキャン画像の送信」処理が実行されているときには、ネットワークリソースのうちの６０％が使用されており、「４０％」の処理余力が存在することが示されている。

たとえば、子装置ＡＲ２２が「プリントデータ受信」処理中であるときには、当該子装置ＡＲ２２の処理余力は「３０％」であると判定され、子装置ＡＲ２２は、自装置ＡＲ２２の処理余力「３０％」を親装置ＡＲ１に通知するようにすればよい。

あるいは、画像形成装置１０の処理余力は画像形成装置１０のメモリ容量の処理余力に基づいて判定されるようにしてもよい。

図８は、このような態様を示す図である。図８は、画像形成装置１０のメモリリソース（メモリ容量）に関する処理余力を示す図である。図８においては、実行中の処理との処理余力との関係が示されている。

図８は、このような態様を示す図である。図８は、画像形成装置１０のメモリリソース（メモリ容量）に関する処理余力、より詳細には、画像形成装置１０において新たな処理に割当可能な（利用可能な）メモリリソースに応じた指標値（処理余力指数）を示す図である。図７においては、実行中の処理との処理余力との関係が示されている。

図８の最上段においては、画像形成装置１０にて「プリントデータ受信」処理が実行されているときには、メモリリソースの４０％が使用されており、「６０％」の処理余力が存在することが示されている。同様に、画像形成装置１０において「リアルタイムプレビュー処理」が実行されているときには、メモリリソースの６０％が使用されており、「４０％」の処理余力が存在することが示されている。また、画像形成装置１０が「ＦＡＸ受信」中であるときには、メモリリソースのうちの８０％が使用されており、「２０％」の処理余力が存在することも示されている。

たとえば、子装置ＡＲ２１が「プリントデータ受信処理」中であるときには、当該子装置ＡＲ２１の処理余力は「６０％」であると判定され、子装置ＡＲ２１は、自装置ＡＲ２１の処理余力「６０％」を親装置ＡＲ１に通知するようにすればよい。

また、利用可能なＣＰＵリソース、利用可能なネットワーク通信リソース、利用可能なメモリリソースなどを含む複数の要素に応じた指標値に基づいて、画像形成装置１０の処理余力が求められるようにしてもよい。

具体的には、画像形成装置１０の処理余力は、当該複数の要素にそれぞれ対応する複数の指標値のうち最も低い処理能力に対応する値（複数の処理余力指数のうち最も低い処理余力指数）として取得されるようにしてもよい。たとえば、ＣＰＵリソースに基づく処理余力が「６０％」であり、ネットワーク通信リソースに基づく処理余力が「４０％」であり、メモリリソースに基づく処理余力が「３０％」である場合には、これらのうち最も低い処理余力である「３０％」が画像形成装置１０の処理余力として求められればよい。

あるいは、画像形成装置１０の処理余力は、当該複数の要素にそれぞれ対応する複数の指標値の加重平均値として取得されるようにしてもよい。たとえば、ＣＰＵリソースに基づく処理余力が「６０％」であり、ネットワーク通信リソースに基づく処理余力が「４０％」であり、メモリリソースに基づく処理余力が「３０％」である場合を想定する。この場合には、これらの指標値を１：２：１の加重割合で加重平均化した値「４２．５％」（＝（６０％＋４０％＊２＋３０％）／４）が画像形成装置１０の処理余力として求められればよい。

＜２．第２実施形態＞
第２実施形態は、第１実施形態の変形例である。以下では、第１実施形態との相違点を中心に説明する。

第２実施形態においては、子装置の処理余力が所定レベルより小さいときには各親装置は当該子装置へのアップデートデータＵＤの送信動作を実行しない。この点において、第２実施形態は第１実施形態と相違する。

また、この第２実施形態においては、各子装置は、その親装置からの通知依頼ＲＱに応じてのみ自装置（子装置）の処理余力を当該親装置に通知するのではなく、当該子装置の状況にも応じて自装置（子装置）の処理余力を親装置に通知する。この点においても、第２実施形態は第１実施形態と相違する。

図１４および図１５は、第２実施形態の動作を示すフローチャートである。図１４のステップＳ１６（Ｓ１６ｂ）および図１５のステップＳ１８では、子装置の処理余力が所定の基準値ＴＨ１より大きいことを条件に配信動作が開始される。この点で、図３のステップＳ１６とは相違する。

たとえば、図１７に示すように、或る時点において、子装置ＡＲ２１の処理余力が「６０％」であり且つ子装置ＡＲ２２の処理余力が「１０％」である状況を想定する。

この状況においては、上記第１実施形態と同様に、子装置ＡＲ２１の配信順位が第１順位に決定され、子装置ＡＲ２２の配信順位が第２順位に決定される（ステップＳ１５）。

そして、ステップＳ１６ｂにおいて、子装置ＡＲ２１の処理余力「６０％」は、所定レベル（たとえば、「２０％」（＝基準値ＴＨ１））より大きいと判定され、親装置ＡＲ１から子装置ＡＲ２１へのアップデートデータＵＤの送信が第１実施形態と同様に実行される。

ただし、子装置ＡＲ２１への送信完了後において、親装置ＡＲ１は、今度は、子装置ＡＲ２２の処理余力「１０％」が基準値ＴＨ１（「２０％」）より低い旨を判定し、当該親装置ＡＲ１から子装置ＡＲ２２へのアップデートデータＵＤの送信を保留する。

一方、各子装置は、図４の動作に代えて図１６の動作を実行する。

具体的には、図１６に示すように、ステップＳ２２において、各子装置は、自装置における実行処理種類（実行状況）に変更が生じた場合にもステップＳ２３に進み、自装置の余力状況を親装置に通知する動作を実行する。たとえば、子装置ＡＲ２２における実行状況が「ＯＣＲ処理中」から「アイドリング」へと変化したときに、子装置ＡＲ２２は、自装置ＡＲ２２の処理余力が「１０％」から「１００％」へと上昇したことを、親装置ＡＲ１に通知する。換言すれば、子装置ＡＲ２２は、実行状況変更後の自装置ＡＲ２２の処理余力が「１００％」であることを親装置ＡＲ１に通知する。

そして、親装置ＡＲ１は、ステップＳ１７（図１５）に進み、処理余力通知ＮＴ２（ＮＴ２２）を子装置ＡＲ２２から再び受信する。その後、親装置ＡＲ１は、当該処理余力通知ＮＴ２２により通知された処理余力に基づいて、送信先装置（送信対象装置）のうちの未送信先装置（詳細には、複数の子装置のうち、その装置へのアップデートデータＵＤの送信が未だ開始されていない装置）に関する配信順序を決定し、当該配信順序等に従って配信動作を開始する（ステップＳ１８）。たとえば、親装置ＡＲ１は、残りの子装置ＡＲ２２を次の配信先として決定する。さらに、親装置ＡＲ１は、子装置ＡＲ２２の処理余力が所定レベルよりも大きいことをも条件として、当該子装置ＡＲ２２に向けてアップデートデータＵＤの送信動作を実行する（ステップＳ１８）。その後、全ての子装置への送信が完了したことを判定して、図１５の動作を終了する（ステップＳ１９）。このように、上記の送信保留動作後に、当該子装置ＡＲ２２の処理余力が所定レベル（たとえば２０％）より高いレベル（たとえば「１００％」）にまで上昇したこと（図１８参照）が判定されると、親装置ＡＲ１から子装置ＡＲ２２へのアップデートデータＵＤの送信処理が実行される。

ここにおいて、子装置ＡＲ２２の処理余力が所定の基準値ＴＨ１（たとえば２０％）よりも低い状況において更にアップデートデータＵＤの通信処理を行うと、子装置ＡＲ２２にて現在実行中の他の処理（たとえばプリントデータ受信ジョブ）の処理効率が低下することがある。特に、子装置ＡＲ２２の処理余力が小さい状況にて、当該子装置ＡＲ２２にて現在実行中の他の処理とアップデートデータＵＤの通信処理とが各種の共通のハードウエア（たとえば共通の通信ポート等）を利用する場合には、現在実行中の当該他の処理の処理効率が大きく低下することがある。

一方、この第２実施形態においては、子装置ＡＲ２２の処理余力が所定の基準値ＴＨ１未満であるときには当該子装置ＡＲ２２へのアップデートデータＵＤの送信動作が実行されない。これによれば、子装置ＡＲ２２における実行中処理の大きな効率低下を回避することが可能である。

また、上記第１実施形態と同様に、親装置ＡＲ１は、複数の子装置ＡＲ２１，ＡＲ２２のうち、最も高い処理余力を有する（最も低い負荷状態の）子装置ＡＲ２１から順次にアップデートデータの送信処理を実行する。そのため、複数の子装置のうちの一の子装置へのデータ送信処理を早期に完了することができる。

このように、複数の子装置における実行中処理の大きな効率低下を回避しつつ、効率的なアップデート処理を実行することが可能である。

なお、第２実施形態の動作においては、子装置ＡＲ２２の処理余力が所定レベル（たとえば２０％）より高いレベル（たとえば「１００％」）にまで上昇したこと（状態好転）を確認して、子装置ＡＲ２２に対するアップデートデータ送信処理が実行される。そのため、子装置ＡＲ２２に対するアップデートデータ処理に要する時間の長大化を抑制することも可能である。

また、上記態様においては、子装置ＡＲ２２における実行処理種類（実行状況）が変更されるごとに、親装置ＡＲ１に対して子装置ＡＲ２２の処理余力が送信される。端的に言えば、子装置ＡＲ２２からの自発的な処理余力通知ＮＴ２が親装置ＡＲ１に対して送信される。そして、当該親装置ＡＲ１（詳細には、その配信制御部１５）は、複数の子装置のうちの一の装置ＡＲ２２における実行処理種類の変更に応じて、当該一の装置ＡＲ２２の処理余力を当該一の装置ＡＲ２２から随時取得し、取得した当該処理余力にも基づいて、当該一の装置ＡＲ２２への配信の可否を決定する。そのため、親装置ＡＲ１は子装置ＡＲ２２の処理余力を比較的早期に知得することが可能である。

また、ここでは、子装置は自装置における実行処理種類に変更があったときに自装置（子装置）の処理余力を親装置に随時通知する態様が例示されているが、これに限定されない。たとえば、子装置は、所定のタイミングで（たとえば一定時間間隔で）、親装置に当該子装置の処理余力を随時通知するようにしてもよい。このように、子装置は、親装置からの通知依頼ＲＱの受信時、自装置（当該子装置）の実行処理種類の変更時、および所定タイミングの到来時のうちの１つ以上の時点で、自装置（子装置）の処理余力を当該親装置に通知するようにしてもよい。なお、実行処理種類に変更があったときに自装置（子装置）の処理余力が親装置に随時通知されることによれば、親装置ＡＲ１は子装置ＡＲ２２の処理余力を比較的早期に知得して、配信動作を早い段階で変更することが可能である。

また、上記においては、２つの子装置ＡＲ２１，ＡＲ２２のうち一方のみの処理余力が基準値ＴＨ１よりも小さい場合における処理について例示されている。以下では、或る時点で２つの子装置ＡＲ２１，ＡＲ２２の双方の処理余力がいずれも基準値ＴＨ１よりも小さな値（たとえば、いずれも「１０％」）を有する場合について説明する。

この場合には、まず、ステップＳ１６ｂにおいて、親装置ＡＲ１は、子装置ＡＲ２１，ＡＲ２２の処理余力がいずれも基準値ＴＨ１より低い旨を判定し、当該親装置ＡＲ１から子装置ＡＲ２１，ＡＲ２２へのアップデートデータＵＤの各送信動作をいずれも保留する。

その後、複数の子装置ＡＲ２１，ＡＲ２２のうちの少なくとも一方において実行処理種類が変更が検出され、当該少なくとも一方の装置から自発的な処理余力通知ＮＴ２が親装置ＡＲ１に対して送信される。そして、当該少なくとも一方の装置における実行処理種類の変更に応じて、親装置ＡＲ１（詳細には、その配信制御部１５）は、当該少なくとも一方の装置の処理余力を随時取得し（ステップＳ１７）、取得した当該処理余力にも基づいて、当該少なくとも一方の装置への配信順序を随時決定する（ステップＳ１８）。

たとえば、子装置ＡＲ２１の処理余力が「３０％」に増大し且つ子装置ＡＲ２２の処理余力が「５０％」に増大した場合には、子装置ＡＲ２２の配信順位が第１順位に決定され、子装置ＡＲ２２の配信順位が第２順位に決定される（ステップＳ１８）。また、子装置ＡＲ２１の処理余力「３０％」と子装置ＡＲ２２の処理余力「５０％」とは、いずれも基準値ＴＨ１より大きいと判定される。そして、親装置ＡＲ１から子装置ＡＲ２１へのアップデートデータＵＤの送信動作と親装置ＡＲ１から子装置ＡＲ２２へのアップデートデータＵＤの送信動作とがこの順序で実行される。

このように、親装置ＡＲ１は子装置の処理余力の変更を随時知得して、配信動作を随時変更することが可能である。

＜３．第３実施形態＞
第３実施形態は、第２実施形態の変形例である。以下では、第２実施形態との相違点を中心に説明する。

第３実施形態は、各親装置が自装置の処理余力にも基づいて子装置へのアップデートデータＵＤの送信動作の実行の是非を決定する点で、第２実施形態と相違する。

図１９は、このような動作を示すフローチャートである。この第３実施形態においては、図１４のフローチャートの処理に代えて図１９のフローチャートの処理が実行される。図１９のフローチャートは、自装置の処理余力が所定レベルより大きいか否かがステップＳ１２にて判定される点で、図１４のフローチャートと相違する。

より詳細には、ステップＳ１２において、自装置の処理余力が所定レベル（たとえば、「２０％」（＝基準値ＴＨ２））より小さいときには、次のステップＳ１３に進まずに、当該自装置の処理余力が増大し所定レベルより大きくなるまで待機する。そして、自装置の処理余力が所定の基準値ＴＨ２より大きいと判断されるときのみ、次のステップＳ１３に進む。ステップＳ１３以降では、上述のように、処理余力通知依頼ＲＱの送信処理、処理余力通知ＮＴの受信処理、配信順序の決定処理、および配信処理（アップデートデータＵＤの送信処理）が実行される。

ここにおいて、自装置（たとえば、親装置ＡＲ１）の処理余力が所定レベル（たとえば２０％）よりも低い場合において更にアップデートデータＵＤの通信処理を行うと、現在実行中の他の処理（たとえばプリントデータ受信ジョブ）の処理効率が低下することがある。特に、自装置（親装置）の処理余力が小さい状態においてアップデートデータＵＤの通信処理と現在実行中の他の処理とが各種の共通のハードウエアを利用する場合には、処理効率が大きく低下することがある。

一方、図１９に示すように、親装置が、自装置の処理余力が所定レベルよりも大きいことを条件に子装置へのアップデートデータＵＤの送信動作を実行することによれば、当該親装置における実行中処理の大きな効率低下を回避することができる。

＜４．第４実施形態＞
第４実施形態は、第１実施形態の変形例である。以下、第１実施形態との相違点を中心に説明する。

第４実施形態においては、図２０に示すような設定画面ＧＳ１を用いて、装置ＡＲ１の複数の子装置のうちの優先送信先装置がユーザ（管理ユーザ等）の手動操作に応じて指定される。設定画面ＧＳ１は、操作者の操作に応じて装置ＡＲ１の操作パネル部６ｃ等に表示される。たとえば、ユーザは、親装置ＡＲ１において図２０のような設定画面ＧＳ１を用い、子装置ＡＲ２１の優先順位を子装置ＡＲ２２の優先順位よりも高く設定することができる。

また、同様にして、図２１に示すような設定画面ＧＳ２を用いて、装置ＡＲ２１の複数の子装置のうちの優先送信先装置がユーザ（管理ユーザ等）の手動操作に応じて指定される。設定画面ＧＳ２は、操作者の操作に応じて装置ＡＲ２１の操作パネル部６ｃ等に表示される。たとえば、ユーザは、親装置ＡＲ２１において図２１のような設定画面ＧＳ２を用い、子装置ＡＲ３１の優先順位を子装置ＡＲ３２の優先順位よりも高く設定することができる。

これらの設定操作は、図２２の動作に先立って、管理者等によって予め行わればよい。

その後、親装置ＡＲ１において、図２２の動作が行われる。具体的には、設定画面ＧＳ１を用いて指定された優先順位にも従って、当該親装置ＡＲ１から複数の子装置ＡＲ２１，ＡＲ２２に対するアップデートデータＵＤの配信順序がステップＳ１５（Ｓ１５ｂ）において決定される。ステップＳ１５ｂにおいては、設定画面ＧＳを用いてなされたユーザ指示が存在するときには、当該ユーザ指示を反映して、複数の子装置ＡＲ２１，ＡＲ２２に関する配信順序が決定される。たとえば、子装置ＡＲ２１の優先順位が子装置ＡＲ２２の優先順位よりも高く設定されているときには、子装置ＡＲ２１の配信順位が第１順位であり子装置ＡＲ２２の配信順位が第２順位である旨が決定される。その後、当該配信順序に従って、複数の子装置ＡＲ２１，ＡＲ２２に対する配信動作が順次実行される。

同様に、第２階層の装置ＡＲ２１において、図２２の動作が行われる。具体的には、設定画面ＧＳ２を用いて指定された優先順位にも従って、当該装置（新たな親装置）ＡＲ２１からその複数の子装置ＡＲ３１，ＡＲ３２に対するアップデートデータＵＤの配信順序がステップＳ１５ｂにおいて決定される。たとえば、子装置ＡＲ３１の優先順位が子装置ＡＲ３２の優先順位よりも高く設定されているときには、子装置ＡＲ３１の配信順位が第１順位であり子装置ＡＲ３２の配信順位が第２順位である旨が決定される。その後、当該配信順序に従って、複数の子装置ＡＲ３１，ＡＲ３２に対する配信動作が順次実行される。

この場合には、第１階層の装置ＡＲ１からのアップデートデータＵＤの送信処理は第２階層の装置ＡＲ２１，ＡＲ２２のうち装置ＡＲ２１に対して優先的に行われる。また、第２階層の装置ＡＲ２１からのアップデートデータＵＤの送信処理は第３階層の装置ＡＲ３１，ＡＲ３２のうち装置ＡＲ３１に対して優先的に行われる。

なお、このようなユーザ操作による配信順序（その複数の子装置の配信順序）が指定されていない親装置（たとえば親装置ＡＲ２２）においては、第１実施形態と同様に、その子装置ＡＲ３３，ＡＲ３４の処理余力に基づいて、配信順序が決定される。

以上のような動作によれば、ユーザの事情等に応じて、アップデートデータＵＤの配信順序を柔軟に変更することが可能である。たとえば、ユーザが特定の装置ＡＲ２１，ＡＲ３１（特に装置ＡＲ３１）を優先的にアップデートして使用したい場合に、当該特定の装置ＡＲ２１，ＡＲ３１（特に装置ＡＲ３１）へのアップデートデータＵＤの配信を優先的に実行することが可能である。

なお、上記においては、親装置において２つの子装置の優先順位を全て指定する態様が例示されているが、これに限定されない。具体的には、親装置ＡＲ２２において、３つの子装置ＡＲ３３，ＡＲ３４，ＡＲ３５（図１３参照）のうち、単一の子装置ＡＲ３３の優先順位が（第１順位に）指定される一方、その他の２つの子装置の優先順位は指定されないようにしてもよい。このように、或る親装置において、Ｎ個の子装置のうち、Ｋ個（ただし、Ｋ＜Ｎ−１）の子装置の優先順位を指定する一方、その他の（Ｎ−Ｋ）個の子装置の優先順位は指定しないようにしてもよい。この場合には、当該Ｋ個の子装置の優先順位はユーザ指示に従って決定されるとともに、その他の（Ｎ−Ｋ）個の子装置の優先順位は、当該（Ｎ−Ｋ）個の子装置の処理余力に基づいて決定されればよい。たとえば、単一の子装置ＡＲ３３の優先順位はユーザ指示に従って第１順位に決定されるとともに、その他の２個の子装置ＡＲ３４，ＡＲ３５の優先順位は、当該２個の子装置ＡＲ３４，ＡＲ３５の処理余力に基づいて決定されればよい。

＜５．変形例等＞
以上、この発明の実施の形態について説明したが、この発明は上記説明した内容のものに限定されるものではない。

たとえば、上記実施形態においては、画像形成装置１０としてＭＦＰが例示されているが、これに限定されず、様々な画像形成装置（印刷装置、コピー装置、スキャナ装置等）に対して上記の思想が適用されるようにしてもよい。

また、第４実施形態の思想は、第２実施形態および第３実施形態等に係る思想とそれぞれ組み合わせて実現されるようにしてもよい。

１ 画像形成システム
１０ ＭＦＰ（画像形成装置）
５０ サーバコンピュータ
ＡＲｉ 第ｉ階層の装置
ＧＷ ゲートウエイ
ＨＭ 階層構造情報
ＮＴ 処理余力通知
ＲＱ 処理余力通知依頼
ＵＤ アップデートデータ

Claims (19)

1. 階層構造で複数層に論理接続される多数の画像形成装置のうちのいずれかの画像形成装置であって、
   前記画像形成装置よりも１つ下位階層の複数の画像形成装置である複数の子装置のそれぞれの処理余力を取得する状態取得手段と、
   前記複数の子装置に対して、各装置のファームウエアに関するアップデートデータを送信する配信制御手段と、
   を備え、
   前記配信制御手段は、前記複数の子装置の各処理余力に基づいて前記複数の子装置に関する配信順序を決定し、当該配信順序に従って前記複数の子装置に対して前記アップデートデータを送信することを特徴とする画像形成装置。
2. 請求項１に記載の画像形成装置において、
   前記配信制御手段は、前記複数の子装置のうち、最も高い処理余力を有する装置を優先送信先装置として決定し、前記複数の子装置のうち前記優先送信先装置に向けて他の装置よりも先に前記アップデートデータを送信することを特徴とする画像形成装置。
3. 請求項１または請求項２に記載の画像形成装置において、
   前記配信制御手段は、前記複数の子装置のうちの特定の子装置の処理余力が第１の基準値よりも大きいことを条件に、前記特定の子装置への前記アップデートデータの送信動作を実行することを特徴とする画像形成装置。
4. 請求項１ないし請求項３のいずれかに記載の画像形成装置において、
   前記配信制御手段は、前記画像形成装置の処理余力が第２の基準値よりも大きいことを条件に、前記複数の子装置への前記アップデートデータの送信動作を実行することを特徴とする画像形成装置。
5. 請求項１ないし請求項４のいずれかに記載の画像形成装置において、
   前記状態取得手段は、前記複数の子装置のうちの一の装置における実行処理種類の変更に応じて前記一の装置の処理余力を前記一の装置から随時取得し、
   前記配信制御手段は、前記状態取得手段によって随時取得された前記一の装置の処理余力にも基づいて、前記配信順序を随時決定することを特徴とする画像形成装置。
6. 請求項１ないし請求項５のいずれかに記載の画像形成装置において、
   前記配信順序に関するユーザ指示を受け付ける受付手段、
   をさらに備え、
   前記配信制御手段は、前記ユーザ指示が存在する場合には、当該ユーザ指示を反映して前記配信順序を決定することを特徴とする画像形成装置。
7. 請求項１ないし請求項６のいずれかに記載の画像形成装置において、
   前記各処理余力は、前記複数の子装置のそれぞれにおいて利用可能なＣＰＵリソースに応じた指標値として取得されることを特徴とする画像形成装置。
8. 請求項１ないし請求項６のいずれかに記載の画像形成装置において、
   前記各処理余力は、前記複数の子装置のそれぞれにおいて利用可能なメモリリソースに応じた指標値として取得されることを特徴とする画像形成装置。
9. 請求項１ないし請求項６のいずれかに記載の画像形成装置において、
   前記各処理余力は、前記複数の子装置のそれぞれにおいて利用可能なネットワーク通信リソースに応じた指標値として取得されることを特徴とする画像形成装置。
10. 請求項１ないし請求項６のいずれかに記載の画像形成装置において、
    前記各処理余力は、前記複数の子装置のそれぞれにおいて利用可能なネットワーク通信リソース、ＣＰＵリソースおよびメモリリソースのうちの少なくとも１つの要素を含む複数の要素に応じた指標値として取得されることを特徴とする画像形成装置。
11. 請求項１０に記載の画像形成装置において、
    前記各処理余力は、前記複数の要素にそれぞれ対応する複数の指標値のうち、最も低い処理能力に対応する値として取得されることを特徴とする画像形成装置。
12. 請求項１０に記載の画像形成装置において、
    前記各処理余力は、前記複数の要素にそれぞれ対応する複数の指標値の加重平均値として取得されることを特徴とする画像形成装置。
13. 階層構造で複数層に論理接続される多数の画像形成装置のうちのいずれかの画像形成装置に内蔵されたコンピュータに、
    ａ）前記画像形成装置よりも１つ下位の階層の複数の画像形成装置である複数の子装置のそれぞれの処理余力を取得するステップと、
    ｂ）前記複数の子装置の各処理余力に基づいて前記複数の子装置に対する配信順序を決定するステップと、
    ｃ）前記配信順序に従って前記複数の子装置に対してアップデートデータを送信するステップと、
    を実行させるためのプログラム。
14. 階層構造で複数層に論理接続される多数の画像形成装置のうちのいずれかの画像形成装置であって、
    各装置のファームウエアに関するアップデートデータを受信するデータ取得手段と、
    前記アップデートデータが前記データ取得手段によって受信されると、前記画像形成装置よりも１つ下位階層の複数の画像形成装置である複数の子装置のそれぞれの処理余力を取得する状態取得手段と、
    前記複数の子装置の各処理余力に基づいて前記複数の子装置に関する配信順序を決定するとともに、当該配信順序に従って前記複数の子装置に対して前記アップデートデータの送信を開始する配信制御手段と、
    を備え、
    前記状態取得手段は、前記アップデートデータの送信が未だ開始されていない装置である未送信先装置のうちの一の装置であって、前記複数の子装置のうち実行処理状況の変更が生じた一の装置の処理余力を前記一の装置から再び取得し、
    前記配信制御手段は、再び取得された前記一の装置の処理余力にも基づいて前記未送信先装置に関する配信順序を決定し直し、決定し直された当該配信順序に従って前記未送信先装置に対して前記アップデートデータを送信することを特徴とする画像形成装置。
15. 階層構造で複数層に論理接続される多数の画像形成装置のうちのいずれかの画像形成装置であって、
    各装置のファームウエアに関するアップデートデータを受信するデータ取得手段と、
    前記アップデートデータが前記データ取得手段によって受信されると、前記画像形成装置よりも１つ下位階層の複数の画像形成装置である複数の子装置のそれぞれの処理余力を取得する状態取得手段と、
    当該各処理余力に基づいて前記複数の子装置に関する配信順序を決定するとともに、当該配信順序に従って前記複数の子装置に対して前記アップデートデータの送信を開始する配信制御手段と、
    を備え、
    前記状態取得手段は、前記複数の子装置のうち前記アップデートデータの送信が未だ開始されていない装置である未送信先装置のうちの少なくとも一の装置の処理余力を再び取得し、
    前記配信制御手段は、再び取得された前記少なくとも一の装置の処理余力にも基づいて前記未送信先装置に関する配信順序を一定時間間隔で決定し直し、決定し直された当該配信順序に従って前記未送信先装置に対して前記アップデートデータを送信することを特徴とする画像形成装置。
16. 請求項１４または請求項１５に記載の画像形成装置において、
    前記配信制御手段は、
    前記複数の子装置のうち処理余力が所定の基準値よりも大きい子装置に対して、前記アップデートデータの送信を開始し、
    前記複数の子装置のうち処理余力が前記所定の基準値よりも小さい子装置に対しては、前記アップデートデータの送信を開始しないことを特徴とする画像形成装置。
17. 階層構造で複数層に論理接続される多数の画像形成装置のうちのいずれかの画像形成装置に内蔵されたコンピュータに、
    ａ）各装置のファームウエアに関するアップデートデータを受信するステップと、
    ｂ）前記アップデートデータが前記ステップａ）にて受信されると、前記画像形成装置よりも１つ下位階層の複数の画像形成装置である複数の子装置のそれぞれの処理余力を取得するステップと、
    ｃ）前記複数の子装置の各処理余力に基づいて前記複数の子装置に関する配信順序を決定するステップと、
    ｄ）当該配信順序に従って前記複数の子装置に対して前記アップデートデータの送信を開始するステップと、
    ｅ）前記アップデートデータの送信が未だ開始されていない装置である未送信先装置のうちの一の装置であって、前記複数の子装置のうち実行処理状況の変更が生じた一の装置の処理余力を前記一の装置から再び取得するステップと、
    ｆ）前記ステップｅ）にて再び取得された前記一の装置の処理余力にも基づいて前記未送信先装置に関する配信順序を決定し直すステップと、
    ｇ）前記ステップｆ）にて決定し直された当該配信順序に従って前記未送信先装置に対して前記アップデートデータを送信するステップと、
    を実行させるためのプログラム。
18. 階層構造で複数層に論理接続される多数の画像形成装置のうちのいずれかの画像形成装置に内蔵されたコンピュータに、
    ａ）各装置のファームウエアに関するアップデートデータを受信するステップと、
    ｂ）前記アップデートデータが前記ステップａ）にて受信されると、前記画像形成装置よりも１つ下位階層の複数の画像形成装置である複数の子装置のそれぞれの処理余力を取得するステップと、
    ｃ）当該各処理余力に基づいて前記複数の子装置に関する配信順序を決定するステップと、
    ｄ）当該配信順序に従って前記複数の子装置に対して前記アップデートデータの送信を開始するステップと、
    ｅ）前記複数の子装置のうち前記アップデートデータの送信が未だ開始されていない装置である未送信先装置のうちの少なくとも一の装置の処理余力を再び取得するステップと、
    ｆ）前記ステップｅ）にて再び取得された前記少なくとも一の装置の処理余力にも基づいて前記未送信先装置に関する配信順序を一定時間間隔で決定し直すステップと、
    ｇ）前記ステップｆ）にて決定し直された当該配信順序に従って前記未送信先装置に対して前記アップデートデータを送信するステップと、
    を実行させるためのプログラム。
19. 請求項１７または請求項１８に記載のプログラムにおいて、
    前記ステップｄ）においては、
    前記複数の子装置のうち処理余力が所定の基準値よりも大きい子装置に対して、前記アップデートデータの送信が開始され、
    前記複数の子装置のうち処理余力が前記所定の基準値よりも小さい子装置に対しては、前記アップデートデータの送信が開始されないことを特徴とするプログラム。