JP2011086093A - 画像形成装置、制御方法、及びプログラム - Google Patents

Abstract

【課題】ユーザによるファームウェアのアップデート処理の利便性を向上させることを可能とした画像形成装置、制御方法、及びプログラムを提供する。
【解決手段】画像形成装置は、ＣＰＵ３０４、フラッシュメモリ３０７〜３１０を備える。ＣＰＵ３０４は、アップデートサーバ３１１から更新が発生した差分パッケージを特定して取得し、差分パッケージからパッケージ情報を取得する。更にパッケージ情報から差分パッケージのインストール先となるフラッシュメモリを特定し、差分パッケージを該フラッシュメモリにインストールする際のアップデート処理時間を算出する。更に算出したアップデート処理時間を操作部１０７に表示しユーザに報知する。
【選択図】図５

Description

本発明は、ファームウェアのアップデートに関する情報をユーザに通知可能な画像形成装置、制御方法、及びプログラムに関する。

従来、デジタル複合機等の画像形成装置で使用するファームウェアのアップデートは、販売会社のサービスマンが顧客先に出向いて実施するのが一般的であった。しかし、昨今はインターネット環境が整い、ファームウェアの更新部分のみをインターネット経由で画像形成装置に通知することが可能となっている。これにより、サービスマンが画像形成装置が設置されている顧客先に出向くことなく、ユーザによってファームウェアのアップデートを実施することが可能になってきている。

ユーザが画像形成装置のファームウェアのアップデートを実施する際には、ユーザは画像形成装置の使用状況に合わせてファームウェアをアップデートするタイミングを判断しなければならない。ユーザがアップデートのタイミングを判断するためには、ファームウェア提供元から判断材料となるアップデートに関する情報をユーザに提供することが必要である。

提供する情報のうちユーザにとって重要な情報として、ファームウェアのアップデートにかかる処理時間が挙げられる。ユーザにファームウェアのアップデートにかかる処理時間を通知するためには、アップデートが発生するたびに一律に予測される処理時間を設定し、ユーザの画像形成装置に表示することが考えられる。しかし、画像形成装置の同じ機種でもファームウェアにはさまざまな構成が存在し、最終的に同じ内容になるはずのアップデートでも、アップデートされる差分のファームウェアに違いが発生し、一律に処理時間を予測することはできない。

そこで、従来、ファームウェアのアップデートにかかる更新処理時間を算出する方法が提案されている（例えば、特許文献１参照）。特許文献１の提案では、ファームウェアのアップデートを行う際に、ソフトウェアを構成するモジュールの版数から更新が発生するモジュールを判断し、データの転送時間、書換時間、書換位置決めのオーバーヘッド時間を合算することで、更新処理時間を算出する。

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

実際の画像形成装置におけるファームウェアのアップデート処理では、システムを切り替えるためのリブートが複数回発生し、リブートの回数とリブートにかかる時間が全体のアップデートの処理時間に影響する。そのため、ファームウェアのアップデートにかかる更新処理時間の算出には、リブートの発生回数、リブートにかかる時間を考慮する必要がある。また、ユーザが安心してファームウェアのアップデートを実施するためには、アップデート処理中に、実際に更新処理がどの部分に行われているのか、リブートが何回行われるか、いつリブートが行われるかなど、アップデート状況の通知が重要である。しかし、従来の更新処理時間算出方法では、アップデート時のリブートを考慮していないという問題があった。

本発明の目的は、ファームウェアのアップデート処理の利便性を向上させることを可能とした画像形成装置、制御方法、及びプログラムを提供することにある。

上記目的を達成するために、本発明は、記憶手段を備える画像形成装置であって、ファームウェアを構成するモジュールの供給源から更新されたモジュールを特定し取得する第１の取得手段と、前記第１の取得手段により取得したモジュールから該モジュールに含まれるモジュール情報を取得する第２の取得手段と、前記第２の取得手段により取得したモジュール情報に基づき、前記第１の取得手段により取得したモジュールのインストール先となる記憶手段を特定する特定手段と、前記第１の取得手段により取得したモジュールを前記特定手段により特定した記憶手段にインストールする際のアップデート処理時間を算出する算出手段と、前記算出手段により算出したアップデート処理時間を報知する報知手段と、を備えることを特徴とする。

本発明によれば、アップデート処理時間の報知により、ユーザはアップデートのタイミングを判断し、アップデートを実行することが可能となる。これにより、ファームウェアのアップデート処理の利便性を向上させることが可能となる。

本発明の実施の形態に係る画像形成装置の構成を示すブロック図である。 画像形成装置のコントローラ部の詳細構成を示すブロック図である。 画像形成装置のメインコントローラボード、エンジンコントローラボード、アクセサリボードに各々搭載されたＣＰＵ及びフラッシュメモリの構成を示すブロック図である。 （ａ）、（ｂ）は、画像形成装置が有するパッケージのリストの例を示す図である。 画像形成装置のファームウェアのアップデート処理の概要を示すフローチャートである。 画像形成装置のダウンロード開始画面を示す図である。 画像形成装置のアップデート開始画面を示す図である。 （ａ）、（ｂ）は、画像形成装置で取得したパッケージ情報の例を示す図である。 画像形成装置のアップデート処理の例を示すフローチャートである。 画像形成装置のアップデート処理の例を示すフローチャートである。 画像形成装置のアップデート中画面を示す図である。

以下、本発明の実施の形態を図面に基づいて説明する。尚、本発明の実施の形態に記載されている構成要素はあくまで例示であり、本発明の範囲を実施の形態のみに限定するものではない。

図１は、本発明の実施の形態に係る画像形成装置の構成を示すブロック図である。

図１において、画像形成装置１０１は、ＬＡＮ１０２により接続された情報処理装置（本実施の形態では第１のホストコンピュータ１０３、第２のホストコンピュータ１０４、後述のアップデートサーバ）と通信が可能なデジタル複合機として構成されている。ＬＡＮ１０２は、例えばイーサネット（登録商標）等から構成されている。

画像形成装置１０１は、リーダ部１０５、プリンタ部１０６、操作部１０７、コントローラ部１０８を備えている。コントローラ部１０８は、リーダ部１０５、プリンタ部１０６、操作部１０７に接続されると共に各部の制御を司る。操作部１０７は、画像形成装置の各種機能や画像の表示、画像形成装置に対する各種設定に用いる。

リーダ部１０５は、原稿給紙ユニット１０９とスキャナユニット１１０を備えており、原稿から画像を読み取る読取処理を行う。原稿給紙ユニット１０９は、読取対象の原稿を原稿読取位置に搬送する。スキャナユニット１１０は、原稿から画像を光学的に読み取って電気信号としての画像データに変換する。

プリンタ部１０６は、給紙ユニット１１１とマーキングユニット１１２と排紙ユニット１１３を備えており、記録紙に画像を印刷する印刷処理を行う。給紙ユニット１１１は、記録紙を収容する複数段の給紙カセットを備えている。マーキングユニット１１２は、給紙ユニット１１１から供給される記録紙に画像を転写し定着させる印刷処理を行う。排紙ユニット１１３は、マーキングユニット１１２で印刷処理が行われた記録紙を画像形成装置１０１に接続された後処理装置または画像形成装置１０１の排紙部に排出する。

本実施の形態では、画像形成装置１０１に後処理装置（フィニッシャ）としてアクセサリユニット１１４が接続されている。アクセサリユニット１１４は、マーキングユニット１１２で印刷処理が行われた記録紙にソート処理やステイプル処理等のフィニッシング処理を施して排紙部に排出する。

図２は、画像形成装置のコントローラ部の詳細構成を示すブロック図である。

図２において、コントローラ部１０８は、メインコントローラ３２、ネットワークコントローラ４２、入出力制御部５１等を備えている。メインコントローラ３２は、ＣＰＵ３３、バスコントローラ３４、各種コントローラ回路を含む機能ブロックを内蔵している。メインコントローラ３２は、ＤＲＡＭインタフェース（Ｉ／Ｆ）３７を介してＤＲＡＭ３８と接続されている。更に、メインコントローラ３２は、コーデックＩ／Ｆ３９を介してコーデック４０と接続され、ネットワークＩ／Ｆ４１を介してネットワークコントローラ４２と接続されている。

ＤＲＡＭ３８は、ＣＰＵ３３が動作するための作業領域や画像データを蓄積するための記憶領域として使用される。コーデック４０は、ＤＲＡＭ３８に蓄積されたラスタイメージデータをＭＨ／ＭＲ／ＭＭＲ／ＪＢＩＧ等の周知の圧縮方式で圧縮し、また圧縮されたデータをラスタイメージデータに伸長する。コーデック４０には、ＳＲＡＭ４３が接続されている。ＳＲＡＭ４３は、コーデック４０の一時的な作業領域として使用される。ネットワークコントローラ４２は、ネットワークコネクタ４４を介してＬＡＮ１０２との間で所定の制御動作を行い、第１のホストコンピュータ１０３、第２のホストコンピュータ１０４、後述のアップデートサーバとの間の通信を司る。

また、メインコントローラ３２は、スキャナバス４５を介してスキャナＩ／Ｆ４６に接続され、プリンタバス４７を介してプリンタＩ／Ｆ４８に接続されている。更に、メインコントローラ３２は、ＰＣＩバス等の汎用高速バス４９を介して拡張ボードを接続するための拡張コネクタ５０及び入出力制御部５１に接続されている。入出力制御部５１は、リーダ部１０５とプリンタ部１０６との間で制御コマンドを送受信するための調歩同期式のシリアル通信コントローラ５２を２チャンネル装備している。シリアル通信コントローラ５２は、Ｉ／Ｏバス５３を介してスキャナＩ／Ｆ４６及びプリンタＩ／Ｆ４８に接続されている。

スキャナＩ／Ｆ４６は、第１の調歩同期シリアルＩ／Ｆ５４及び第１のビデオＩ／Ｆ５５を介してスキャナコネクタ５６に接続されている。スキャナコネクタ５６は、リーダ部１０５のスキャナユニット１１０に接続されている。スキャナＩ／Ｆ４６は、スキャナユニット１１０から受信した画像データに対し２値化処理と主走査方向及び／又は副走査方向の変倍処理を行う。また、スキャナＩ／Ｆ４６は、スキャナユニット１１０から送られてくるビデオ信号に基づいて制御信号を生成し、スキャナバス４５を介してメインコントローラ３２に転送する。

プリンタＩ／Ｆ４８は、第２の調歩同期シリアルＩ／Ｆ５７及び第２のビデオＩ／Ｆ５８を介してプリンタコネクタ５９に接続されている。プリンタコネクタ５９は、プリンタ部１０６のマーキングユニット１１２に接続されている。プリンタＩ／Ｆ４８は、メインコントローラ３２から出力された画像データにスムージング処理を施してマーキングユニット１１２に出力する。また、プリンタＩ／Ｆ４８は、マーキングユニット１１２から送られてくるビデオ信号に基づいて、生成された制御信号をプリンタバス４７に出力する。例えば、第１及び第２のホストコンピュータ１０３、１０４から受信したＰＤＬ（ページ記述言語）データを解釈し、ラスタイメージデータに展開する処理を行う。

バスコントローラ３４は、スキャナＩ／Ｆ４６に接続されたリーダ部１０５、プリンタＩ／Ｆ４８に接続されたプリンタ部１０６、拡張コネクタ５０に接続された外部機器等から入出力されるデータ転送を制御する。バスコントローラ３４は、バス競合時のアービトレーション（調停）やＤＭＡデータ転送の制御を行う。例えば、ＤＲＡＭ３８とコーデック４０との間のデータ転送、スキャナユニット１１０からＤＲＡＭ３８へのデータ転送、ＤＲＡＭ３８からマーキングユニット１１２へのデータ転送等は、バスコントローラ３４により制御され、ＤＭＡ転送される。

入出力制御部５１は、ＬＣＤコントローラ６０及びキー入力Ｉ／Ｆ６１を介してパネルＩ／Ｆ６２に接続されている。パネルＩ／Ｆ６２は、操作部１０７に接続されている。また、入出力制御部５１は、Ｅ−ＩＤＥコネクタ６３を介してハードディスクドライブ８及び９、フラッシュメモリ９９に接続されている。フラッシュメモリ９９は、メインコントローラ制御用の各種制御プログラム及び各種データ記憶領域を記憶する。更に、入出力制御部５１は、画像形成装置内で管理する日付と時刻を更新／保存するリアルタイムクロックモジュール（ＲＴＣ）６４に接続されている。ＲＴＣ６４は、バックアップ用電池６５に接続されバックアップされている。

図３は、画像形成装置１０１のメインコントローラボード３０１、エンジンコントローラボード３０２、アクセサリボード３０３に各々搭載されたＣＰＵ及びフラッシュメモリの構成を示すブロック図である。

図３において、メインコントローラボード３０１は、画像形成装置全体の制御を司るものであり、図１のコントローラ部１０８に相当する。エンジンコントローラボード３０２は、図１のプリンタ部１０６の印刷制御を司るものであり、図１のプリンタ部１０６内に搭載され、図２のプリンタコネクタ５９に接続されている。アクセサリボード３０３は、図１のアクセサリユニット１１４の制御を司るものであり、アクセサリユニット１１４内に搭載され、エンジンコントローラボード３０２に接続されている。

メインコントローラボード３０１は、画像形成装置全体の制御を司るＣＰＵ３０４、メインフラッシュメモリ３０７及びサブフラッシュメモリ３０８を備えている。即ち、１つのフラッシュメモリ（図２のフラッシュメモリ９９）がメインフラッシュメモリ３０７とサブフラッシュメモリ３０８にパーティションが分かれている。メインフラッシュメモリ３０７には、通常の画像形成装置全体の制御を実行するプログラムモジュール（以下モジュール）群が格納されている。サブフラッシュメモリ３０８には、アップデート処理を担当するモジュールが格納されている。

エンジンコントローラボード３０２は、プリンタ部１０６の制御を司るＣＰＵ３０５、エンジンフラッシュメモリ３０９を備えている。エンジンフラッシュメモリ３０９には、エンジンコントローラモジュールが格納されている。

アクセサリボード３０３は、アクセサリユニット１１４の制御を司るＣＰＵ３０６、アクセサリフラッシュメモリ３１０を備えている。アクセサリフラッシュメモリ３１０には、画像形成装置１０１のアクセサリ機能（アクセサリユニット１１４）のモジュールが格納されている。

上記の各フラッシュメモリに格納されているモジュールがアップデートされる場合は、画像形成装置１０１ではＬＡＮ１０２を介してアップデートサーバ３１１と通信を行うことで、新規モジュールを取得してインストールすることになる。

次に、上記の構成を備える本実施の形態の画像形成装置１０１の動作について図４乃至図１０を参照しながら説明する。

＜ファームウェアのアップデートの仕組み＞
まず、画像形成装置１０１のファームウェアのアップデートの仕組みについて図４、図５、図６、図７を用いて説明する。

図４（ａ）、図４（ｂ）は、画像形成装置１０１が有するパッケージのリストの例を示す図である。

図４（ａ）、図４（ｂ）において、リスト４０１、４０２、４０８は、画像形成装置１０１が持つ「パッケージ」と呼ばれるモジュールのリストの例である。画像形成装置１０１のファームウェアは、これらのパッケージ群により構成されている。

例えば図４（ａ）のリスト４０１では、パッケージ４０４「ａａａ−０．０．０−０」〜「ｆｆｆ−０．０．０−０」が、メインコントローラボード３０１のメインフラッシュメモリ３０７に格納されている。また、パッケージ４０５「ｕｐｄａｔｅｒ−０．０．０−０」が、サブフラッシュメモリ３０８に格納されている。また、パッケージ４０６「ｅｎｇｉｎｅｃｏｎ−０．０．０−０」が、エンジンコントローラボード３０２のエンジンフラッシュメモリ３０９に格納されている。また、パッケージ４０７「ａｃｃｅｓｓｏｒｙ−０．０．０−０」が、アクセサリボード３０３のアクセサリフラッシュメモリ３１０に格納されている。

次に、画像形成装置１０１のファームウェアのアップデート処理の概要を図５のフローチャートに基づき説明する。

図５は、画像形成装置１０１のファームウェアのアップデート処理の概要を示すフローチャートである。本処理は、画像形成装置１０１のメインコントローラボード３０１のメインフラッシュメモリ３０７に格納されたプログラム（プログラムコード）に従ってＣＰＵ３０４により実行される。

図５において、メインコントローラボード３０１のＣＰＵ３０４は、アップデートサーバ３１１（モジュールの供給源）からファームウェアのアップデート通知を受信する（ステップＳ５０１）。このとき、ＣＰＵ３０４は、サブフラッシュメモリ３０８内のアップデータツール（リスト４０１のパッケージ４０５「ｕｐｄａｔｅｒ−０．０．０−０」）を起動する。もしくは、ユーザが操作部１０７を介してアップデータツールを起動し、操作部１０７に表示した図６のダウンロード開始画面６００の「ダウンロード」ボタン６０１を押下し、アップデートサーバ３１１に更新パッケージの問い合わせを行ってもよい。

次に、ＣＰＵ３０４は、アップデートサーバ３１１から受信したアップデート通知の内容から、更新が発生した差分パッケージ（アップデート対象の更新されたモジュール）を特定する（ステップＳ５０２）。例えば、図４（ａ）に示すように、アップデート前のパッケージのリスト４０１とアップデートサーバ３１１から通知されたアップデート後のリスト４０２を比較し、差分パッケージ４０３の特定を行う。次に、ＣＰＵ３０４は、アップデートサーバ３１１からステップＳ５０２で特定した差分パッケージをダウンロードする（ステップＳ５０３：第１の取得手段）。

次に、ＣＰＵ３０４は、ダウンロードした差分パッケージに含まれるパッケージ情報ファイルに記載されたパッケージ情報（モジュール情報）を取得する（ステップＳ５０４：第２の取得手段）。次に、ＣＰＵ３０４は、取得したパッケージ情報と、画像形成装置１０１の機器構成情報（画像形成装置１０１におけるオプション機器の接続の有無等の機器構成を示す情報）も用いて、アップデートにかかる予測処理時間を計算する（ステップＳ５０５）。予測処理時間の計算方法の詳細については後述する。

予測処理時間を算出した後、ＣＰＵ３０４は、操作部１０７に図７のアップデート開始画面（インストール開始画面）７００を表示する（ステップＳ５０６）。アップデート開始画面７００では、ユーザに対して、アップデートの予測時間７０１、「インストール」ボタン７０２、「後で行う」ボタン７０３、「キャンセル」ボタン７０４が表示される。アップデート開始画面７００におけるアップデートの予測時間７０１の表示（報知）により、ユーザはアップデートの予測時間を確認することが可能である。

次に、ＣＰＵ３０４は、操作部１０７に表示されたアップデート開始画面７００に対するユーザの操作に伴い、操作部１０７を介してユーザから指示を受信したかどうかを判断する（ステップＳ５０７）。ユーザから「インストール」の指示を受信した場合、ＣＰＵ３０４は、アップデート処理を実行する（ステップＳ５０８）。ユーザから「後で行う」の指示を受信した場合、ＣＰＵ３０４は、一定時間待機し（ステップＳ５０９）、再びステップＳ５０６でアップデート開始画面７００を表示する。ユーザから「キャンセル」の指示を受信した場合、ＣＰＵ３０４は、そのまま本処理を終了する。

＜アップデート処理時間算出方法＞
アップデートの処理時間の内訳は以下の通りである。
(1)各フラッシュメモリに対する差分パッケージ（モジュール）のインストール時に必ずかかる固定処理時間（差分パッケージの圧縮時間、及び、フラッシュメモリへの書きこみ時間）
(2)各フラッシュメモリにインストールする差分パッケージ（モジュール）のファイルサイズ（モジュールサイズ）に依存した時間（差分パッケージの展開時間、または、差分パッケージの転送時間）
(3) アップデート処理に伴い発生するリブート時間（リブート回数×１回のリブート時間）
上記(1)(2)(3)の各処理時間を合算することにより、アップデート処理にかかる時間を算出することができる。各処理時間は、特定した差分パッケージがどのフラッシュメモリにインストールされるかによって決定される。上述した通り、画像形成装置１０１ではアップデート処理時にはアップデートサーバ３１１から差分パッケージのみ取得しインストールを行う。そのため、差分パッケージの組み合わせにより、インストール先のフラッシュメモリやリブート回数が変わってくる。

＜差分パッケージのインストール先とインストール処理時間の特定方法＞
アップデート時の各差分パッケージのインストール先とインストール処理時間の特定方法について説明する。

図５のステップＳ５０４で説明したように、画像形成装置１０１においてアップデートサーバ３１１からダウンロードした各差分パッケージから、各差分パッケージに含まれるパッケージ情報ファイルを読み出し、パッケージ情報を取得する。パッケージ情報の例を図８（ａ）、図８（ｂ）に示す。

パッケージ情報（モジュール情報）には、パッケージ名（モジュール名）、ファイルタイプ、バージョン、管理者、インストール先、インストール時間、等の情報が含まれる。図８（ａ）では、インストール先は、「インストール先：」からメインフラッシュメモリ３０７であることが分かる。また、インストール先に対応したインストールに要する時間は、「インストール時間：」から、メインフラッシュメモリ３０７の固定処理時間が1200sec、ファイルサイズに依存した時間が1secであることが分かる。

同様に、図８（ｂ）では、インストール先は、エンジンフラッシュメモリ３０９であることが分かる。また、インストール先に対応したインストールに要する時間は、エンジンフラッシュメモリ３０９の固定処理時間が2400sec、ファイルサイズに依存した時間が60secであることが分かる。

ただし、インストール時間は、上記のようにパッケージ情報に予め値を記載しておくだけでなく、画像形成装置１０１内に各フラッシュメモリのサイズあたりの平均処理速度を保持しておき、各パッケージファイルのサイズから算出することも可能である。

また、パッケージ情報に記載されたインストール先が画像形成装置１０１の機器構成にないものであった場合、その差分パッケージはインストールされず、処理時間の算出にも積み上げられない。例えばアクセサリと呼ばれるフィニッシャ等のオプション機器は、画像形成装置の種類によっては存在しないので、その場合は、図５のステップＳ５０２で更新が発生する差分パッケージとして特定されてもインストールするパッケージからは外すことになる。

＜リブート回数の特定方法＞
上記(3)リブート時間（リブート回数×１回のリブート時間）を算出するためのリブート回数の特定方法について説明する。

アップデート処理時にリブートを実施する理由は、アップデートを実行するにはシステムを切り替える必要があるためである。本実施の形態の画像形成装置１０１では、ジョブ処理等を行う通常のモード（以下「通常モード」と呼ぶ）から、アップデートが実行可能なメンテナンス用のモード（以下「メンテナンスモード」と呼ぶ）に切り替える。

通常モードではメインフラッシュメモリ３０７から画像形成装置１０１を起動しているが、アップデート処理時はサブフラッシュメモリ３０８からメンテナンスモード（これを「メインメンテナンスモード」とする）で起動する。そして、メインフラッシュメモリ３０７、エンジンフラッシュメモリ３０９、アクセサリフラッシュメモリ３１０のアップデートを実行する。

また、サブフラッシュメモリ３０８に格納されるｕｐｄａｔｅｒ（上記メインメンテナンスモードでアップデートを実行するモジュール）そのものがアップデートされる場合は、次のアップデートを実行する。メインフラッシュメモリ３０７からメンテナンスモード（これを「サブメンテナンスモード」とする）で起動し、サブフラッシュメモリ３０８のアップデートを実行する。このモードの切り替えの度にリブートが発生するので、差分パッケージのインストール先のフラッシュメモリの特定によって切り替わるモードが決定され、リブート回数が特定される。

例えば、図４（ａ）の場合、差分パッケージ４０３はすべてメインフラッシュメモリ３０７に格納されるパッケージなので、インストールはメインフラッシュメモリ３０７にのみ発生する。このとき、アップデート処理は図９（ａ）に示すようになり、リブート回数は２回となる。

図９ａは、画像形成装置１０１のアップデート処理の例を示すフローチャートである。

図９ａにおいて、画像形成装置１０１でアップデートを実行するため、「通常モード」から（ステップＳ９０１）、リブートによるモード切り替えにより（ステップＳ９０２）、「メインメンテナンスモード」に移行する（ステップＳ９０３）。その後、メインフラッシュメモリ３０７のアップデートを実行し（ステップＳ９０４）、リブートによるモード切り替えにより（ステップＳ９０５）、「通常モード」に戻る（ステップＳ９０６）。

また、図４（ｂ）の場合、アップデート後にリスト４０８の状態になるとすると、差分パッケージは４０９のようになり、メインフラッシュメモリ３０７、サブフラッシュメモリ３０８、エンジンフラッシュメモリ３０９にインストールが発生することになる。このとき、アップデート処理は図９（ｂ）に示すようになり、リブート回数は３回となる。

図９ｂは、画像形成装置１０１のアップデート処理の例を示すフローチャートである。

図９ｂにおいて、画像形成装置１０１でアップデートを実行するため、「通常モード」から（ステップＳ９１１）、リブートによるモード切り替えにより（ステップＳ９１２）、「メインメンテナンスモード」に移行する（ステップＳ９１３）。その後、メインフラッシュメモリ３０７のアップデートを実行し（ステップＳ９１４）、エンジンフラッシュメモリ３０９のアップデートを実行する（ステップＳ９１５）。

次に、リブートによるモード切り替えにより（ステップＳ９１６）、「サブメンテナンスモード」に移行する（ステップＳ９１７）。その後、サブフラッシュメモリ３０８のアップデートを実行し（ステップＳ９１８）、リブートによるモード切り替えにより（ステップＳ９１９）、「通常モード」に戻る（ステップＳ９２０）。

画像形成装置１０１において１回のリブートにかかる時間は一定であるとして、メインフラッシュメモリ３０７に１回のリブート時間の値を保持しておく。そして、アップデート処理の度に算出されるリブート回数と１回のリブート時間の積を求めることで、上記(3)のリブート時間を求める。

＜アップデートに関するユーザに対する情報の通知＞
アップデートに関するユーザに対する情報の通知について図１０を用いて説明する。

ユーザが画像形成装置１０１の操作部１０７に表示された図７のアップデート開始画面７００の「インストール」ボタン７０２を押下すると、ＣＰＵ３０５はリブートを開始し、通常モードからメンテナンスモードへの移行を開始する。リブート後、操作部１０７には図１０のアップデート処理中であることを示すアップデート中画面１０００が表示される。アップデート中画面１０００には、アップデート処理時間の算出にも利用したリブート回数１００１を表示する。また、アップデート開始前にも表示したアップデート処理時間１００２も表示する。これにより、アップデート処理時間をユーザに報知することが可能となる。

また、アップデート中画面１０００には、アップデート状況１００３を表示し、カーソル１００４により現在のアップデート／リブートの進捗状況を表示することも可能である。このとき、アップデート状況１００３において上述したアップデート処理時間の算出の合算前の値（各ボードの各フラッシュメモリのアップデート処理にかかる時間、リブートの発生タイミング）を表示することも可能である。これにより、より詳細な処理時間をユーザに報知することも可能となる。

以上詳細に説明したように、本実施の形態によれば、画像形成装置は、アップデートサーバから更新が発生した差分パッケージを特定して取得し、差分パッケージからパッケージ情報を取得する。更にパッケージ情報から差分パッケージのインストール先となるフラッシュメモリを特定し、差分パッケージを該フラッシュメモリにインストールする際のアップデート処理時間を算出する。更にアップデート処理中は、アップデート処理時間、リブート回数、リブートの発生タイミング、アップデート対象を操作部に表示しユーザに報知する。

操作部に対する表示により、ユーザは自分の機器（画像形成装置）の使用状況に合わせてアップデートのタイミングを判断することができる。また、ユーザはアップデートの状況を確認することができ、安心してファームウェアのアップデートを実行することができる。これにより、ユーザによるファームウェアのアップデート処理の利便性を向上させることが可能となる。

〔他の実施の形態〕
上記実施の形態では、画像形成装置による新規モジュールの取得先としてアップデートサーバを例に挙げたが、これに限定されるものではない。例えばＣＤ−ＲＯＭやリムーバブルメディア等の記憶媒体を介して新規モジュールを取得することも可能である。

上記実施の形態では、画像形成装置で取得した新規モジュールを格納する記憶手段としてフラッシュメモリを例に挙げたが、これに限定されるものではない。新規モジュールを格納する記憶手段としてフラッシュメモリ以外の記憶手段を用いてもよい。

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

３０４ ＣＰＵ
３０７ メインフラッシュメモリ
３０８ サブフラッシュメモリ
３０９ エンジンフラッシュメモリ
３１０ アクセサリフラッシュメモリ

Claims (8)

1. 記憶手段を備える画像形成装置であって、
   ファームウェアを構成するモジュールの供給源から更新されたモジュールを特定し取得する第１の取得手段と、
   前記第１の取得手段により取得したモジュールから該モジュールに含まれるモジュール情報を取得する第２の取得手段と、
   前記第２の取得手段により取得したモジュール情報に基づき、前記第１の取得手段により取得したモジュールのインストール先となる記憶手段を特定する特定手段と、
   前記第１の取得手段により取得したモジュールを前記特定手段により特定した記憶手段にインストールする際のアップデート処理時間を算出する算出手段と、
   前記算出手段により算出したアップデート処理時間を報知する報知手段と、
   を備えることを特徴とする画像形成装置。
2. 前記算出手段は、前記第１の取得手段により取得したモジュールを前記特定手段により特定した記憶手段にインストールする際のモジュールの圧縮時間、書きこみ時間と、モジュールのファイルサイズに基づくモジュールの展開時間、転送時間と、アップデート処理に伴い発生するリブートの回数に基づくリブート時間とを合算することで、前記アップデート処理時間を算出することを特徴とする請求項１記載の画像形成装置。
3. 前記算出手段は、前記特定手段による１回のアップデート処理でインストールが発生する記憶手段の特定に基づき、前記リブートの回数を算出することを特徴とする請求項２記載の画像形成装置。
4. 前記モジュール情報には、モジュールのインストール先を示す情報、インストール先に対応したインストール時間を示す情報が含まれることを特徴とする請求項１記載の画像形成装置。
5. 前記報知手段は、アップデート処理中に、アップデート処理が発生している記憶手段を報知することを特徴とする請求項１記載の画像形成装置。
6. 前記報知手段は、アップデート処理中に、リブートの発生タイミングを報知することを特徴とする請求項１記載の画像形成装置。
7. 記憶手段を備える画像形成装置の制御方法であって、
   ファームウェアを構成するモジュールの供給源から更新されたモジュールを特定し取得する第１の取得ステップと、
   前記第１の取得ステップで取得したモジュールから該モジュールに含まれるモジュール情報を取得する第２の取得ステップと、
   前記第２の取得ステップで取得したモジュール情報に基づき、前記第１の取得ステップで取得したモジュールのインストール先となる記憶手段を特定する特定ステップと、
   前記第１の取得ステップで取得したモジュールを前記特定ステップで特定した記憶手段にインストールする際のアップデート処理時間を算出する算出ステップと、
   前記算出ステップで算出したアップデート処理時間を報知する報知ステップと、
   を有することを特徴とする制御方法。
8. 請求項７に記載の画像形成装置の制御方法をコンピュータに実行させるためのコンピュータで読み取り可能なプログラムコードを有するプログラム。