JP2019057037A - 情報処理装置及びプログラム - Google Patents

Abstract

【課題】ソフトウエア中の要素プログラムが更新中に他の要素プログラム群を実行できるようにする。【解決手段】通信コンポーネント２５０が更新中に、キャンした画像をメールで送信するジョブが実行されると、スキャンされた画像が画像処理され、ＨＤＤ等に蓄積された後、読取り処理コンポーネント２１０が、通信コンポーネント２５０にメール送信を依頼し、これに対する応答がないことで読取り処理コンポーネント２１０は通信コンポーネント２５０が更新中と判断する。読取り処理コンポーネント２１０は、ＵＩコンポーネント２０５にその旨を通知する。ＵＩコンポーネント２０５は、通信コンポーネント２５０を用いるジョブをユーザから受け付けないよう制御する。更新完了後、読取り処理コンポーネント２１０はメール送信の依頼を再送する。【選択図】図６

Description

本発明は、情報処理装置及びプログラムに関する。

特許文献１には、ファームウェアの更新等に伴う製品機能のダウンタイムを低減することを目指した画像形成装置が開示されている。この画像形成装置は、ファームウェアを更新することで修正される修正内容を示す内容情報を取得する取得手段と、取得手段により取得された内容情報と、画像形成装置の機器情報と、を比較し、ファームウェアの更新を行うか否かを判定する判定手段と、判定手段によりファームウェアの更新を行うと判定された場合、更新対象となるファームウェアの更新ファイルを取得する更新ファイル取得手段と、更新ファイル取得手段により取得された更新ファイルを用いてファームウェアの更新を行う更新手段と、を有する。例えば、ファームウェアの修正内容が、画像形成装置に接続されていないオプションユニットの不具合修正に関するものである場合には、ファームウェアの更新を行わない。

特許文献２に開示された方法では、ファームウェアをダウンロードすべきフラッシュメモリは、複数のメモリバンクに分割され、バンク毎に書き込み、消去を行うことができ、既存のファームウェアを構成する複数の機能プログラム（ｂｏｏｔルーチン、ｍａｉｎルーチン、デバイス制御ルーチン等）を、バージョン識別子と共に各バンクに格納している。新たなファームウェアのバイナリファイルのダウンロードは、各機能プログラム毎に、そのバージョン識別子を比較して、バージョンが異なっている機能プログラムのみを書き替えることにより行われる。この方法では、変更されている機能プログラムのみが選択的に書き換えられ、変更がない機能プログラムは書き換えられないので、ファームウェア全体を更新する方式よりも、更新に要する時間が短い。

特許第５９８４６２１号明細書 特開２００６−００４１７７号公報

情報処理装置に記憶されているソフトウエアを更新している間は、そのソフトウエア全体が実行できない。仮に、ソフトウエアを構成する複数の要素プログラムのうち変更のある要素プログラムを選択的に更新するとしても、それだけではある要素プログラムを更新している間に他の要素プログラム群を実行することはできない。

本発明は、ソフトウエア中のある要素プログラムが更新中に、他の要素プログラム群を実行できるようにすることを目的とする。

請求項１に係る発明は、プロセッサと、前記プロセッサにより実行される複数の要素プログラムを含むソフトウエアを記憶する記憶装置と、を含み、前記複数の要素プログラムのうちの少なくとも１つの要素プログラムは、他の要素プログラムが更新中である場合、当該他の要素プログラムが更新中であることに対応するための特定処理を前記プロセッサに実行させる、ことを特徴とする情報処理装置である。

請求項２に係る発明は、前記少なくとも１つの要素プログラムは、依頼対象処理を依頼した他の要素プログラムが更新中である場合に前記特定処理を実行し、前記特定処理は、前記他の要素プログラムの更新が完了した後に、前記他の要素プログラムに対して再度前記依頼対象処理を依頼することを含む、請求項１に記載の情報処理装置である。

請求項３に係る発明は、操作画面を生成する画面生成手段を更に含み、前記特定処理は、前記他の要素プログラムが更新中であることを前記画面生成手段に通知する処理を含み、前記画面生成手段は、実行されている前記要素プログラムから他の要素プログラムが更新中であることを通知された場合、前記情報処理装置がユーザに提供する複数の機能のうち、当該他の要素プログラムを用いる機能について、当該機能の利用に制約があることを示す第１の操作画面を生成する、請求項１又は２に記載の情報処理装置である。

請求項４に係る発明は、前記画面生成手段は、前記第１の操作画面として、前記複数の機能のうち更新中である前記他の要素プログラムを用いない機能については、制約なく利用を受け付ける画面を生成する、ことを特徴とする請求項３に記載の情報処理装置である。

請求項５に係る発明は、前記画面生成手段は、前記複数の機能の各々と、その機能を実現するために用いられる１以上の前記要素プログラムとの対応関係の情報に従い、前記他の要素プログラムを用いる機能を特定する、ことを特徴とする請求項３又は４に記載の情報処理装置である。

請求項６に係る発明は、前記画面生成手段は、前記複数の機能のうち使用する機能の選択をユーザから受け付けるための第２の操作画面を生成し、前記第２の操作画面に対して前記ユーザが選択した機能が、更新中である前記他の要素プログラムを用いるものである場合に、前記第１の操作画面として、当該機能が利用不可であることを示す画面を生成する、請求項４又は５に記載の情報処理装置である。

請求項７に係る発明は、前記画面生成手段は、前記複数の機能のうち、更新中であることが通知された前記他の要素プログラムが、その機能のために実行される処理の流れの中で蓄積処理以前に実行される機能については、前記第１の操作画面としてその機能が実行不可であることを示す画面を生成し、前記他の要素プログラムが、その機能のために実行される処理の流れの中で蓄積処理より後に実行される機能については、前記第１の操作画面として、その機能は実行可能だが完了までに時間がかかることを示す画面を生成する、請求項４〜６のいずれか１項に記載の情報処理装置である。

請求項８に係る発明は、前記第１の操作画面が表示されていたときに前記情報処理装置を操作していたユーザに対して、前記他の要素プログラムの更新の完了に応じて前記他の要素プログラムを用いる前記機能が利用可能となったときに、前記機能が利用可能となったことを示す通知を行う通知手段、を含む、請求項４〜７のいずれか１項に記載の情報処理装置である。

請求項９に係る発明は、前記第１の操作画面は、前記ユーザに対して前記他のプログラムの更新の完了に応じて前記機能が利用できるようになったときに通知を求めるか否かの入力を求める画像要素、を含み、前記通知手段は、前記画像要素に応じて前記通知を求める旨の入力が前記ユーザからなされた場合に、前記他の要素プログラムの更新の完了に応じて前記他の要素プログラムを用いる前記機能が利用可能となったときに前記通知を行う、請求項８に記載の情報処理装置である。

請求項１０に係る発明は、前記複数の要素プログラムの各々の使用状況を示す履歴情報を記録する履歴記録手段と、前記履歴情報に応じて前記ソフトウエアの更新を制御する更新制御手段と、を更に含む、請求項１〜９のいずれか１項に記載の情報処理装置である。

請求項１１に係る発明は、前記更新制御手段は、前記履歴情報において更新の対象である要素プログラムの使用頻度が閾値以上である期間は、当該要素プログラムの更新を行わない、請求項１０に記載の情報処理装置である。

請求項１２に係る発明は、前記更新制御手段は、前記履歴情報において更新の対象である要素プログラムの使用頻度が閾値以上である期間内でも特定の場合には当該要素プログラムの更新を行い、この場合の更新では、当該要素プログラムを構成する下位の要素プログラムの各々を単位として更新を実行する、請求項１０又は１１に記載の情報処理装置である。

請求項１３に係る発明は、前記履歴記録手段は、前記第２の操作画面において前記ユーザが機能を選択した場合に、その機能が更新中である前記他の要素プログラムを用いるために使用不可であっても、その機能に用いられる各要素プログラムがそのとき使用されたことを示す履歴情報を記録する、請求項５を引用する請求項１０〜１２のいずれか１項に記載の情報処理装置である。

請求項１４に係る発明は、情報処理装置に含まれる記憶装置内に記憶される複数の要素プログラムを含むプログラムであって、前記複数の要素プログラムのうちの少なくとも１つの要素プログラムは、他の要素プログラムが更新中である場合、当該他の要素プログラムが更新中であることに対応するための特定処理を前記情報処理装置内のプロセッサに実行させる、プログラムである。

請求項１又は１４に係る発明によれば、ソフトウエア中のある要素プログラムが更新中に、他の要素プログラム群を実行できる。

請求項２に係る発明によれば、他の要素プログラムの更新が完了した後、中断していた処理を再開することができる。

請求項３〜５に係る発明によれば、更新中の要素プログラムがある場合に、その影響のない機能については利用を受け付けつつも、影響のある機能についてはそれに応じた表示を行うことができる。

請求項６に係る発明によれば、更新中の要素プログラムのために利用できない機能がユーザに選択されるのを抑制できる。

請求項７に係る発明によれば、要素プログラムが更新中であっても、機能を実現するための一連の処理の途中のデータを蓄積して更新完了後にその蓄積したデータを用いて処理を再開できる場合には、その機能の利用を受け付けることができる。

請求項８又は９に係る発明によれば、要素プログラムの更新のために機能の利用が認められなかったユーザに、更新の完了を知らせることができる。

請求項１０に係る発明によれば、各要素プログラムの使用状況に応じてソフトウエアの更新を制御できる。

請求項１１に係る発明によれば、更新の対象である要素プログラムがよく使用されるときにその要素プログラムの更新を行わないようにすることができる。

請求項１２に係る発明によれば、更新の対象である要素プログラムをまとめて更新する場合と比べて、その要素プログラムに対応するすべての機能が一度に使えなくなる状況を抑制することができる。

請求項１３に係る発明によれば、実際に使用されなくてもユーザの需要があった機能のための要素プログラムを記録し、使用頻度が閾値以上の期間の決定に反映させることができる。

複合機のファームウエアの構成を例示する図である。 ファームウエア中のメインコントローラの構成を例示する図である。 各コンポーネントの概略構成を示す図である。 コンポーネント内の実行制御部の処理手順を例示する図である。 スキャン・トゥ・メール処理が実行される際の各コンポーネントの動作の流れを示す図である。 通信コンポーネントがアップデート中にスキャン・トゥ・メール処理が実行されたときの各コンポーネントの動作の流れを示す図である。 通信コンポーネントがアップデート中であることを検知されたときに複合機のＵＩに表示される画面の例を模式的に示す図である。 通信コンポーネントがアップデート中に表示されるメインメニュー画面の例を模式的に示す図である。 通信コンポーネントがアップデート中に表示される、スキャン機能の設定画面の例を模式的に示す図である。 通信コンポーネントがアップデート中に表示される、スキャン機能の設定画面の別の例を模式的に示す図である。 ＵＩ画面上の各項目とファームウエア内の要素プログラムとの依存関係を示すテーブルの例を示す図である。 ファームウエアがアップデート中に表示される、アップデート完了後の通知の要否の指示を受け付ける画面の例を模式的に示す図である。 アップデートに関する画面表示等の制御を行うジョブ実行制御コンポーネントを含むメインコントローラの構成を例示する図である。 ジョブ実行制御コンポーネントの処理手順を例示する図である。 ジョブ実行制御コンポーネントの処理手順の別の例を示す図である。 変形例におけるメインコントローラの構成を例示する図である。 複合機の各機能の利用履歴の集計結果を例示する図である。 アップデート管理コンポーネントの処理手順を例示する図である。

以下では、複合機（プリンタ、スキャナ、コピー機、ＦＡＸ（ファクシミリ）装置等の機能を兼ね備えた装置）に内蔵される情報処理装置（内蔵コンピュータ）のファームウェアの更新を例にとって説明する。

複合機内の情報処理装置のファームウエア１０は、例えば、図１に示すように、コピーコントローラ１２、印刷コントローラ１４、スキャンコントローラ１６、ＦＡＸコントローラ１８、メインコントローラ２０、オプションコントローラ２２を含む。このうちメインコントローラ２０以外のものは、複合機が提供するアプリケーション機能（サービス）を実現するためのプログラムである。すなわち、コピーコントローラ１２は、コピーサービスのための情報処理を行うプログラムである。印刷コントローラ１４は、ネットワーク経由での印刷指示を実行する印刷サービスのためのプログラムである。スキャンコントローラ１６は、スキャンサービスを実現するためのプログラムである。ＦＡＸコントローラ１８は、ＦＡＸサービスのためのプログラムである。オプションコントローラ２２は、複合機に装着されたオプション装置（例えばステープル留めを行う後処理装置）を用いたオプションサービスを実現するプログラムである。複合機には複数のオプション装置が装着される可能性があり、オプションコントローラ２２はそれらオプション装置毎に設けられる。

メインコントローラ２０は、複合機の基本機能の制御ためのプログラムである。基本機能の制御には、例えば複合機内のハードウエア機構の制御や、複数のサービスに共通して用いられる機能などがある。図２に、メインコントローラ２０の詳細な構成を例示する。

図２の例では、メインコントローラ２０は、読取り処理コンポーネント２１０、画像処理コンポーネント２２０、蓄積処理コンポーネント２３０、印刷処理コンポーネント２４０、通信コンポーネント２５０、及びセキュリティコンポーネント２６０を含む。読取り処理コンポーネント２１０は、スキャン機構を用いた原稿画像の読取り処理を制御するプログラムである。画像処理コンポーネント２２０は、スキャンや印刷データの展開などにより複合機内で生成された画像データに対する画像処理（例えば色空間変換やノイズ除去）を制御するプログラムである。蓄積処理コンポーネント２３０は、複合機内で生成された画像データや画像処理コンポーネント２２０により処理された画像データを、複合機が有する大容量記憶装置（ハードディスクドライブ等）に蓄積したり、蓄積した画像データを読み出したりする処理を行う。また、蓄積される画像データの圧縮や、蓄積された圧縮画像データの伸張を行う。印刷処理コンポーネント２４０は、画像データを用紙等の媒体に印刷する際の印刷機構の制御を司る。通信コンポーネント２５０は、ローカルエリアネットワークやインターネット等のネットワークを介した通信処理を司るプログラムである。セキュリティコンポーネント２６０は、複合機の情報セキュリティのための処理を担うプログラムである。

なお、図示は省略したが、メインコントローラ２０には、ＵＩ（ユーザインタフェース）処理を行うコンポーネントや、ジョブの実行管理を行うコンポーネント等が含まれていてもよい。

各印刷処理コンポーネント２４０は、更に複数のモジュールに細分されていてもよい。図２の例では、通信コンポーネント２５０とセキュリティコンポーネント２６０がそれぞれ含んでいるモジュール群を示している。

例えば通信コンポーネント２５０は、ＦＴＰ（File Transfer Protocol）通信モジュール２５２、メール通信モジュール２５４、ＨＴＴＰ（HyperText Transfer Protocol）通信モジュール２５６、ＳＭＢ（Server Message Block）通信モジュール２５８等のように、ネットワーク経由での通信に用いる通信プロトコル毎に、そのプロトコルの処理のためのモジュール（プログラム）を有している。また、図示は省略したが、通信コンポーネント２５０には、図に示したプロトコル毎のモジュールの他に、それら複数のプロトコルのモジュールのための共通の処理を行う共通処理モジュールが含まれていてもよい（例えば図３に示す実行制御部３４。詳細は後述）。

またセキュリティコンポーネント２６０は、証明書管理モジュール２６２、暗号エンジンモジュール２６４、履歴管理モジュール２６６、ＨＤＤ消去／暗号化モジュール２６８を含む。証明書管理モジュール２６２は、複合機がネットワーク経由で行う通信等において用いるデジタル証明書（複合機のものや通信相手のもの）を管理するためのモジュールである。暗号エンジンモジュール２６４は、データの暗号化及び復号のためのプログラムであり、例えばネットワークを介して他の装置とやりとりするデータの暗号化や復号化の際に使用される。履歴管理モジュール２６６は、複合機の利用履歴を記録し、管理するためのモジュールである。ＨＤＤ消去／暗号化モジュール２６８は、複合機が内蔵する大容量記憶装置であるＨＤＤ（ハードディスクドライブ）内の情報保護のためのモジュールであり、例えばＨＤＤに保存するデータを暗号化したり、複合機の廃棄時等にＨＤＤ内のデータを消去したりする。また、図示は省略したが、セキュリティコンポーネント２６０は、図に示したプロトコル毎のモジュールの他に、それら複数のプロトコルのモジュールのための共通の処理を行う共通処理モジュールを含んでいてもよい。

図１及び図２に示したように、ファームウエア１０は、階層構造をなす要素プログラム群から構成されている。要素プログラムとは、ファームウエア１０を構成する要素となるプログラムのことである。図示例では、ファームウエア１０は、コントローラレベル（第１階層：図１）の複数の要素プログラムから構成され、コントローラは、コンポーネントレベル（第２階層：図２）の複数の要素プログラムから構成され、コンポーネントは、モジュールレベル（第３階層：図２）の複数の要素プログラムから構成されている。本実施形態では、ファームウエア１０のアップデートは、ファームウエア全体をまとめて行う（すなわちファームウエア全体を１つの要素プログラムとする場合）ほか、コントローラ単位、コンポーネント単位、モジュール単位といった各レベルの要素プログラムを単位として行うこともできる。なお、以上に示した３階層の階層構造はあくまで一例に過ぎない。

本実施形態では、ファームウエア１０内のある要素プログラムのアップデート（更新）を行っている際に、この要素プログラムを用いない処理は実行できるようにする。このために、要素プログラムは、他の要素プログラムがアップデート中である場合に、アップデートに対応するための処理を実行する機能（「アップデート対応機能」と呼ぶ）を備える。アップデート対応機能には、他の要素プログラムがアップデート中であることを検知する処理、他の要素プログラムがアップデート中であることをＵＩコンポーネント（図示省略）に通知する処理、のうちの少なくとも１つが含まれる。また、アップデート対応機能には、他の要素プログラムのアップデートが終わるまで自分の処理を保留して待機し、アップデートの終了を検知すると、保留していた処理を再開する機能が含まれていてもよい。ここで、要素プログラムのアップデート対応機能が対応する「他の要素プログラム」とは、例えば、当該要素プログラムが処理を依頼する依頼先の要素プログラムである。例えば、アップデート対応機能は、当該要素プログラムから依頼先要素プログラムに処理を依頼した際、所定時間以内に応答がない場合、その依頼先要素プログラムがアップデート中であると判定し、ＵＩコンポーネントにその依頼先要素プログラムがアップデート中であることを通知する。ＵＩコンポーネントは、その通知によりその依頼先要素プログラムがアップデート中であることを知り、例えばその依頼先要素プログラムを必要とする処理の実行指示をユーザから受け付けないようにする。

読取り処理コンポーネント２１０や通信コンポーネント２５０のようなコンポーネント３０は、図３に示すように、本体処理部３２と実行制御部３４を有する。本体処理部３２は、当該コンポーネントが外部（ユーザ、他の装置又は他の要素プログラム等）に提供する機能のための処理を担う部分であり、例えば通信コンポーネント２５０における各プロトコルのためのモジュール（図２のＦＴＰ通信モジュール２５２〜ＳＭＢ通信モジュール２５８等）がこれに該当する。一方、実行制御部３４は、本体処理部３２の処理の実行を制御するものであり、他の要素プログラムとの指示やデータのやりとりの機能、前述のアップデート対応機能等を備える。実行制御部３４の処理手順の例を図３に示す。この処理の前提として、ユーザが複合機のＵＩに対してジョブの実行を指示した場合、ファームウエア内のそのジョブに関係する各コントローラ、各コンポーネント、各モジュール等の要素プログラムが、順に動作してそのジョブのための処理を実行する。ジョブの内容に応じて、どの要素プログラムがどのような順で動作するかは決まっており、その順に従ってそれら要素プログラムが実行されていく。例えば、ジョブの実現のために実行される一連の要素プログラムが、それぞれ前の要素プログラムから処理依頼を受けて処理を実行し、次の要素プログラムにその処理の次の処理の実行を依頼する。例えば、そのジョブを構成する各要素プログラムが、そのジョブにおける要素プログラムの実行順序を規定したジョブデータを参照することで、次に処理を実行する要素プログラム（すなわち処理依頼の送信先）を特定する。図４の手順は、このようなジョブの処理の中での、１つのコンポーネント３０が実行する処理を示している。

実行制御部３４は、他の要素プログラムから処理依頼を受け取ると、図４の処理手順を開始する。実行制御部３４は、本体処理部３２にその処理依頼に対応する処理を実行させる（Ｓ１０）。その処理が完了すると、実行制御部３４は、次の処理を担うコンポーネント３０に処理依頼を送信する（Ｓ１２）。依頼先のコンポーネント３０は、処理依頼を受け取ると受領応答を返す。実行制御部３４は、Ｓ１２で送信した処理依頼に対して受領応答が返ってくるのを所定時間待つ（Ｓ１４）。所定時間以内に受領応答が返ってくれば、依頼先のコンポーネント３０は正常に動作していると言うことなので、実行制御部３４は処理を終える。所定時間以内に受領応答が返ってこない場合、依頼先のコンポーネント３０はアップデート中で動作していないということを示す。この場合、実行制御部３４は、ＵＩコンポーネントに対して、依頼先のコンポーネント３０がアップデート中であることを通知する（Ｓ１６）。この通知を受けて、ＵＩコンポーネントは、例えば、そのジョブがアップデートのため中断され、アップデートが終了次第再開される旨をＵＩ画面に表示する。また実行制御部３４は、例えば、その依頼先のコンポーネント３０への処理依頼を保留（記憶）し（Ｓ１８）、依頼先のコンポーネント３０のアップデートが完了するのを待つ（Ｓ２０）。例えば実行制御部３４が定期的にその依頼先に問合せを送り、応答が返ってきたらアップデートが完了したと判定することで行えばよい。依頼先コンポーネントのアップデート完了を検知すると、実行制御部３４は、依頼先コンポーネントのアップデートが完了したことをＵＩコンポーネントに通知する（Ｓ２２）。ＵＩコンポーネントは、依頼先コンポーネントのアップデートが完了した旨の通知を受け取ると、中断中のジョブが再開した旨をＵＩ画面に表示する。また実行制御部３４は、保留していた処理依頼を依頼先コンポーネントに再送し（Ｓ２４）、ジョブの実行を再開する。

図４の例では、依頼先のコンポーネント３０がアップデート中と判断した場合、実行制御部３４は、処理依頼を保留し、アップデートが完了した後でその処理依頼を依頼先のコンポーネント３０に再送した。すなわち、この例では、ジョブの実行を依頼先のコンポーネント３０の直前で中断し、アップデートの完了後にその依頼先のコンポーネント３０からそのジョブの処理を再開する。

別の例として、依頼先のコンポーネント３０がアップデート中であることを検知した場合、それまで実行していたジョブを中止してもよい。この場合、実行制御部３４は、図４の手順のＳ１４で依頼先がアップデート中であることを検知すると、Ｓ１６でその旨をＵＩコンポーネントに通知すると共に、ジョブを中止する（例えばそのジョブの管理情報である上述のジョブデータを破棄するか、又はそのジョブデータにジョブが中止された旨を記録する）。この例では、依頼先コンポーネントがアップデート中である旨の通知を受けたＵＩコンポーネントは、ジョブが中止されたことを表示した後、通常のメニュー画面の表示に戻る。ただし、その依頼先コンポーネントのアップデートが完了するまでの間は、ＵＩコンポーネントは、その依頼先コンポーネントを用いるジョブの実行指示を受け付けない。ＵＩコンポーネントは、その依頼先コンポーネントのアップデートが完了したことを知る（例えば依頼先コンポーネント自体がアップデート完了後に起動した際、ＵＩにアップデート完了を通知する）と、これまで受付禁止にしていたジョブを受け付け可能とする。

図３及び図４の例はコンポーネント３０を例にとったものであったが、コントローラレベル、モジュールレベルの要素プログラムも、同様の制御を行ってよい。

図５及び図６を参照して、具体的なジョブについての処理の流れを説明する。図５及び図６は、「スキャン・トゥ・メール」ジョブの実行時の、メインコントローラ２０内の各コンポーネント間での処理の流れを示している。「スキャン・トゥ・メール」ジョブは、原稿をスキャンし、これにより得られた画像を、ユーザの指定した宛先に電子メールで送信するジョブである。このジョブは、ＵＩコンポーネント２０５、読取り処理コンポーネント２１０、画像処理コンポーネント２２０、蓄積処理コンポーネント２３０、通信コンポーネント２５０が、この順に動作することにより実行される。

図５は、通常時、すなわちそれら５つのコンポーネントがすべて稼働中である場合の「スキャン・トゥ・メール」ジョブの流れである。

（１）この流れでは、ユーザが、原稿を原稿送り装置にセットした後、ＵＩ画面上にスキャン画面を開き、読取り方式（モノクロかカラーか）、データ形式（ＰＤＦ等）を指定し、送信プロトコルとして電子メールを指定すると共に、宛先のメールアドレスを選択又は入力する。そして、ユーザがジョブの実行開始の指示を入力すると、ＵＩコンポーネント２０５が、「スキャン・トゥ・メール」ジョブの一連の流れの最初の処理を担当する読取り処理コンポーネント２１０にジョブ開始を指示する。この指示には、「スキャン・トゥ・メール」ジョブの流れを示す読取り処理コンポーネント２１０、画像処理コンポーネント２２０、蓄積処理コンポーネント２３０、通信コンポーネント２５０というコンポーネントの並びの情報が含まれる。

（２）読取り処理コンポーネント２１０は、ジョブ開始指示を受けて、原稿送り装置上の原稿を読み取る。

（３）読取りが完了すると、読取り処理コンポーネント２１０は、次の処理を担当する画像処理コンポーネント２２０に画像処理依頼を送る。この依頼には、読み取りにより得た画像データのアドレスが含まれる。

（４）画像処理コンポーネント２２０は、その依頼に応じて、その画像データに対して所定の画像処理を実行する。

（５）画像処理が完了すると、画像処理コンポーネント２２０は、次の処理を担当する蓄積処理コンポーネント２３０に蓄積処理依頼を送る。この依頼には、画像処理後の画像データのアドレスが含まれる。

（６）蓄積処理コンポーネント２３０は、その依頼に応じて、その画像データを、例えば圧縮した後、ＨＤＤ等の大容量記憶装置に保存する。ここで、蓄積処理コンポーネント２３０は、その画像データを、その画像データを特定する識別情報と対応付けて蓄積する。この識別情報は、ジョブの開始の際に例えば読取り処理コンポーネント２１０が生成し、蓄積処理コンポーネント２３０に伝達したものである。識別情報を蓄積先のパス名とし、そのパス名に画像データを蓄積する方式であってもよい。

（７）読取り処理コンポーネント２１０は、通信コンポーネント２５０に対して、外部送信開始依頼を送る。この依頼には、蓄積処理コンポーネント２３０により蓄積された画像データを特定する識別情報と、送信プロトコル（この場合は電子メール）の指定と、宛先の情報が含まれる。

（８）通信コンポーネント２５０は、外部送信開始依頼を受け取ると、その依頼に含まれる識別情報を蓄積処理コンポーネント２３０に渡し、蓄積されたデータを要求する。蓄積処理コンポーネント２３０は、受け取った識別情報に対応する画像データを大容量記憶装置から読み出し（読み出したデータが圧縮されている場合は伸張し）、読み出した画像データを通信コンポーネント２５０に渡す。

（９）通信コンポーネント２５０は、蓄積処理コンポーネント２３０から取得した画像データを添付した電子メールを、外部送信開始依頼に含まれる宛先に対して送信する。

（１０）スキャン結果の画像データの送信が完了すると、通信コンポーネント２５０は、依頼元である読取り処理コンポーネント２１０に完了通知を送る。

（１１）通信コンポーネント２５０から完了通知を受け取った読取り処理コンポーネント２１０は、ジョブが完了した旨の通知をＵＩコンポーネント２０５に送る。この通知を受けたＵＩコンポーネント２０５は、例えば、「スキャン・トゥ・メール」ジョブが完了した旨を示すバナーを表示したあと、メインメニュー画面３００の表示に戻る。

図６は、ユーザから「スキャン・トゥ・メール」ジョブの実行が指示された時に、通信コンポーネント２５０がアップデート中である場合の処理の流れを示す。読取り処理コンポーネント２１０、画像処理コンポーネント２２０、蓄積処理コンポーネント２３０は稼働中である。

図６に示す処理の流れのうち（１）〜（７）は通常時（図５）と同じである。

（Ａ）上記ステップ（７）の依頼に対し、依頼先である通信コンポーネント２５０はアップデート中なので、所定時間待っても応答が返ってこない。この場合、読取り処理コンポーネント２１０（の実行制御部３４）は、その依頼先がアップデート中であると判断する。読取り処理コンポーネント２１０は、そのジョブを一時中断し、アップデートが完了するのを待つ。

（Ｂ）また読取り処理コンポーネント２１０は、ＵＩコンポーネント２０５に対して、通信コンポーネント２５０がアップデート中であることを通知する。ＵＩコンポーネント２０５は、その通知に応じて画面表示を制御し、ユーザからのジョブ受付を制限する（詳細な例は後述）。

（Ｃ）読取り処理コンポーネント２１０は、通信コンポーネント２５０のアップデートが完了するのを待ち、その完了を検知する。

（Ｄ）通信コンポーネント２５０のアップデートが完了すると読取り処理コンポーネント２１０は、通信コンポーネント２５０のアップデートが完了したことを示すジョブ再開通知をＵＩコンポーネント２０５に送る。ＵＩコンポーネント２０５は、その通知に応じて、ジョブ受付の制限を解除する。

（Ｅ）読取り処理コンポーネント２１０は、保留していた外部送信開始依頼を通信コンポーネント２５０に再送する。

この後のステップ（８）〜（１１）の処理は、図５に示した通常時の流れと同じである。

図６の処理のステップ（Ｂ）の通知を受けた場合にＵＩコンポーネント２０５が表示するＵＩ画面の例を以下に説明する。

この通知を受けたＵＩコンポーネント２０５は、１つの例では、例えば図７に示すように、表示中の画面（この例ではメインメニュー画面３００）上に、アップデート中であることを示すメッセージバナー３１０を表示する。この例では、通信コンポーネント２５０のアップデートが完了次第ジョブを再開するので、このメッセージバナー３１０には、例えば、処理の完了（すなわちスキャン画像を添付したメールの送信の完了）までに時間がかかることを知らせる文言が表示される。なお、この時点では、原稿のスキャンは終わっているので、ユーザは複合機から離れても問題はない。

また、メッセージバナー３１０の表示が終了した後、ＵＩコンポーネント２０５は、別のジョブの実行指示を受け付けてもよい。ただし、この時点では、通信コンポーネント２５０のアップデート中であるため、通信コンポーネント２５０を利用するジョブは実行できない。そこで、ＵＩコンポーネント２０５は、通信コンポーネント２５０を利用するジョブを受付不可状態としたＵＩ画面を表示する。図８に、その状態のメインメニュー画面３００を例示する。メインメニュー画面３００上には、コピーボタン３０２、印刷ボタン３０４、スキャンボタン３０６等の、各機能の設定画面を呼び出すためのＧＵＩ（グラフィカルユーザーインターフェース）ボタンが表示されている。ユーザが、タッチパネルに表示されたメインメニュー画面３００上のいずれかのボタンを押下すると、ＵＩコンポーネント２０５は、そのボタンに対応する機能の設定画面を表示し、ユーザからその機能についての個々の設定項目の入力を受け付ける。ここで、通信コンポーネント２５０がアップデート中で動作していない場合、インターネット経由での通信が不可能なので、スキャン機能は利用できない。スキャン結果の画像を電子メールその他の通信プロトコルで送信することができないからである。スキャン以外のコピーや印刷等の機能は、通信コンポーネント２５０が動作していなくても、通常通り利用できる（ＦＡＸ送信は、電話回線を経由するため、通信コンポーネント２５０を利用しない）。このため、メインメニュー画面３００上のスキャンボタン３０６は、利用不可であることを示すためにグレーアウト状態（グレー色の目立たない表示状態）となっており、ユーザがスキャンボタン３０６を押しても、ＵＩコンポーネント２０５はスキャンのための設定画面を開かない。スキャン以外の他の機能のボタンは通常状態であり、これらのボタンが押下されると、ＵＩコンポーネント２０５は、対応する機能についての設定画面を開く。

図８は、アップデート中の要素プログラム（例えば通信コンポーネント２５０）の影響で使用できない機能を、メインメニュー画面３００上で受付不可とするものであった。しかし、これは一例にすぎない。この代わりに、使用できない機能をメインメニュー画面３００上では選択（対応するボタンの押下）可能とし、選択後に開くその機能の設定画面上で、その機能が使用できないことを表示してもよい。図９に、図８と同じく通信コンポーネント２５０がアップデート中に、メインメニュー画面３００上のスキャンボタン３０６が押下されることで開かれたスキャン設定画面３２０を例示する。スキャン設定画面３２０には、原稿設定、スキャン設定、保存形式、送信プロトコル等を指定するための入力欄が表示される。また、この例では、そのスキャン設定画面３２０の上に、ユーザが指定した機能（この場合はスキャン機能）が、ファームウエアのアップデートのためにしばらく利用できないことを示すメッセージバナー３２２が表示されている。ユーザは、このメッセージバナー３２２により、スキャン機能がしばらく利用できないことを知る。

また、複合機のスキャン機能が、スキャン結果をネットワーク経由で送信する方式に加え、スキャン結果をローカルに接続された可搬型記録媒体に書き出す方式もサポートしている場合、通信コンポーネント２５０がアップデート中であっても、後者の方式は利用できる。この場合、ＵＩコンポーネント２０５は、メインメニュー画面３００上でスキャンボタン３０６を押下可能とし、その押下により開いたスキャンの設定画面３２０（図１０参照）上で、スキャン結果を送信する送信プロトコルの選択欄３２４を入力不可（グレーアウト状態）としてもよい。

また、図示は省略するが、通信コンポーネント２５０中の例えばＦＴＰ通信モジュール２５２だけがアップデート中である場合、図１０の設定画面３２０上で、送信プロトコルの選択欄３２４のうち、ＦＴＰのみを選択不可（グレーアウト）としてもよい。このように、モジュール単位でアップデートが行われている場合は、アップデートされているモジュールに依存する機能（ＵＩ画面の表示項目に対応）のみを選択不可としてもよい。

このように、ＵＩコンポーネント２０５は、アップデート中の要素プログラムを用いなくても実行可能な機能については、ＵＩ画面上で選択を受け付ける。

図８〜図１０に例示した受付可能な機能を制限したＵＩ画面を生成するために、ＵＩコンポーネント２０５は、ＵＩ画面上の各項目と各要素プログラムとの依存関係を示すテーブルを持っている。このテーブルの例を図１１に示す。この例のテーブルの縦軸には、第１階層（「階層１」）の画面（メインメニュー画面３００）に表示される項目（スキャンボタン３０６等）毎に、その項目が選択された際に開かれる第２階層の画面（例えばスキャンの設定画面３２０）に表示される項目（例えば原稿設定等の選択欄に示される選択肢）が示されている。また、そのテーブルの横軸には、各コンポーネントが示されている。そして、階層２の項目の行とその項目が依存しているコンポーネントの列とが交わるセルに、依存関係があることを示す値（図では黒丸で表示）がセットされている。例えば、送信プロトコルの選択肢であるＦＴＰは、通信コンポーネント２５０に依存しているが、他のコンポーネントには依存していない。ＵＩコンポーネント２０５は、階層２の項目が依存しているコンポーネントがアップデート中は、ユーザからその項目の選択を受け付けない。例えば、通信コンポーネント２５０がアップデート中の場合、送信プロトコルについての４つの選択肢（ＦＴＰ等）についてのユーザからの選択は受け付けない。

図１１には、コンポーネントレベルでの依存関係のテーブルを例示したが、ＵＩコンポーネント２０５は、この他にモジュールレベル（図２のＦＴＰ通信モジュール２５２等）やコントローラレベル（図１参照）での依存関係のテーブルも持っている。ＵＩコンポーネント２０５は、アップデート中である要素プログラムのレベルに応じたテーブルを参照して、ＵＩ画面中の各項目の入力受付の可否を決定する。例えば、図６の処理の例では、ＵＩコンポーネント２０５は、通信コンポーネント２５０がアップデート中であることを読取り処理コンポーネント２１０からの通知で検知し、図１１に示すコンポーネントレベルでの依存関係テーブルを参照して、階層２の画面（スキャンの設定画面３２０）における送信プロトコルの選択肢を無効化（入力受付不可）する。

さて、図８〜図１０に例示した画面表示によれば、ユーザは自分の希望する機能が現在利用できないことを知ることはできるが、いつになったらアップデートが終了してその機能が利用可能になるかは分からない。そこで、ユーザが希望する場合に、アップデートの完了時に、その旨を例えば電子メールでそのユーザに通知してもよい。例えば、オフィス内の複合機のように、ユーザが複合機に登録されており、ユーザ認証情報入りのＩＣカード等を用いてログインして複合機を使用する形態の場合、そのユーザのアカウントにそのユーザの電子メールアドレスを登録しておけば、複合機はユーザに電子メールを送ることができる。例えば、図１２に示すように、アップデート中で利用できない旨を示すメッセージバナー３２２Ａ内に、アップデート完了時の通知を希望するかどうかを問い合わせる文言と、希望の有無を入力するボタン３２６、３２８を表示する。ユーザが、アップデート完了時の通知を希望した場合、複合機は、そのユーザの電子メールアドレスに対して、アップデートが完了した旨を示す電子メールを送る。

次に、図１３〜図１５を参照して、別の例を説明する。この例では、複合機のファームウエアのメインコントローラ２０は、既に説明したＵＩコンポーネント２０５、読取り処理コンポーネント２１０、画像処理コンポーネント２２０等の他に、ジョブ実行制御コンポーネント２０８を含む。ジョブ実行制御コンポーネント２０８は、ＵＩコンポーネント２０５に対してユーザが指示したジョブの実行を制御する。すなわち、ジョブ実行制御コンポーネント２０８は、ＵＩコンポーネント２０５に対してユーザが指定したジョブの情報（ジョブデータ）を受け取り、そのジョブの処理の流れ（フロー）を構成する各コンポーネントに対して、順に処理の開始を指示していく。各コンポーネントは、ジョブ実行制御コンポーネント２０８から開始の指示を受けると、当該コンポーネントの処理を実行し、処理が完了すると、処理結果をジョブ実行制御コンポーネント２０８に応答する。ジョブ実行制御コンポーネント２０８は、その応答を受けて、次のコンポーネントに処理開始を指示する。なお、図１３では、メインコントローラ２０内にジョブ実行制御コンポーネント２０８があるとしたが、同様のジョブ実行制御機能がコントロラーレベル（図１参照）の要素プログラムとして用意されていてもよい。

さて、図１３の例では、ファームウエアの要素プログラムのアップデートが開始される際、そのアップデート処理を実行するアップデータプログラムが、ジョブ実行制御コンポーネント２０８に対して、その要素プログラムのアップデートの開始の通知を送る。この通知には、その要素プログラムの識別情報が含まれる。また、アップデータプログラムは、要素プログラムのアップデートが完了した際に、その要素プログラムの識別情報を含む完了通知をジョブ実行制御コンポーネント２０８に送る。なお、アップデータプログラムは、ファームウエア１０内に含まれていてもよいし、要素プログラムのアップデート情報と共に外部（例えばネットワーク上のサーバ、又は複合機の保守作業者が用いる端末）から複合機の情報処理部内にダウンロードされてもよい。

図１４に、ジョブ実行制御コンポーネント２０８が行うファームウエアのアップデートに関する処理の手順を例示する。図１４の手順は、アップデータプログラムからアップデートの開始が通知されたときに開始する。この手順では、まずジョブ実行制御コンポーネント２０８は、その通知が示すアップデート対象の要素プログラムに依存する機能（ＵＩ画面上の項目に対応）を特定する（Ｓ３０）。この特定は、上述の依存関係のテーブル（図１１）を用いて、上述と同様の手順で行えばよい。次に、ジョブ実行制御コンポーネント２０８は、ＵＩコンポーネント２０５に対して、Ｓ３０で特定した機能のＵＩ状態を選択不可状態に変更させる（Ｓ３２）。これにより、ＵＩコンポーネント２０５は、図８、図９又は図１０のように、アップデート中の要素プログラムに依存する機能が選択できない状態のＵＩ画面を表示する。この後、ジョブ実行制御コンポーネント２０８は、アップデータプログラムから、その要素プログラムのアップデートが完了したことを知らせる完了通知が来るのを待つ（Ｓ３４）。完了通知が来た場合、ジョブ実行制御コンポーネント２０８は、ＵＩコンポーネント２０５に対して、Ｓ３０で特定した機能のＵＩ状態を通常状態（選択や入力を受け付ける状態）に戻すよう指示する（Ｓ３６）。このあとＵＩコンポーネント２０５は、通常のＵＩ画面を表示し、ユーザから通常通り指示を受け付ける。

図１４の例は、アップデート中の要素プログラムに依存する機能の実行指示を受け付けないようにするものであった。これに対して、別の例として、アップデート中の要素プログラムに依存する機能であっても、特定の場合には実行指示を受け付けるようにしてもよい。ここでいう特定の場合とは、アップデート中の要素プログラムが、その機能（ジョブ）の処理フローにおける要素プログラムの実行順（例えば図５の例における読取り処理コンポーネント２１０から通信コンポーネント２５０までの４つのコンポーネントの並び順）において、蓄積処理より後に位置する場合である。すなわち、画像データという大きなデータを取り扱う複合機の場合、入力された画像や生成した画像をいったん大容量記憶装置に蓄積してから後続の処理を行うことがある。複合機の備えるメモリは、１ジョブの全ページ分の画像データを記憶できるとは限らない。このため、ジョブの処理フローにおける要素プログラムの実行順で仮に蓄積処理以前の要素プログラムがアップデート中で処理が実行できない場合、その要素プログラムより前の要素プログラム群の処理結果は蓄積されておらず、メモリ上に保持できるとも限らないので、アップデート中の要素プログラムの前の段階までの処理結果を保持してジョブを保留状態とすることはできない。これに対し、処理フローにおいて蓄積処理より後の要素プログラムがアップデート中である場合、蓄積処理の完了した段階でジョブをいったん保留し、アップデートが完了した後、処理フローにおける蓄積処理の次のステップ（要素プログラム）からジョブを再開することができる。この例のジョブ実行制御コンポーネント２０８の処理手順を図１５に例示する。

図１５の手順では、ジョブ実行制御コンポーネント２０８は、図１４の場合と同様、まず、アップデート対象の要素プログラムに依存する機能を特定する（Ｓ３０）。次に、ジョブ実行制御コンポーネント２０８は、特定した機能毎に、その機能のための処理フローにおいて、そのアップデート対象の要素プログラムが、蓄積処理（例えば蓄積処理コンポーネント２３０）以前（ケース（ａ））か、蓄積処理より後（ケース（ｂ））かを判定する（Ｓ４０）。ジョブ実行制御コンポーネント２０８は、各機能（ジョブ）の処理フローの情報を保持しているので、この情報を参照して判定する。そして、ケース（ａ）に該当する機能については、図１４の手順と同様選択不可状態とするようＵＩコンポーネント２０５に指示し、ケース（ｂ）に該当する機能については、アップデート中のため処理に時間がかかる旨のメッセージを表示した上で、選択を受け付ける状態とするようＵＩコンポーネント２０５に指示する（Ｓ４２）。この後、ジョブ実行制御コンポーネント２０８は、図１４の手順のＳ３４〜Ｓ３６の処理を実行する。

さて、複合機のファームウエアのアップデートは、例えば、ファームウエアのアップデート情報を配信するインターネット上のサーバからアップデート情報が配信されたとき、あるいは保守作業員が保守用端末を複合機に接続してファームウエアのアップデート処理を開始したとき、等に実行される。本実施形態では、ファームウエアのアップデート中も、アップデートの対象となっている要素プログラムに依存しない機能については利用が可能であるため、複合機が完全に利用不可能となるわけではない。とはいっても、アップデート中の要素プログラムに依存する機能を利用したいユーザにとっては、アップデート中の期間はその複合機が利用できないことになる。以下では、このようなユーザの不便を軽減する制御の例を説明する。

図１６に例示するように、この例におけるメインコントローラ２０は、履歴記録コンポーネント２７０とアップデート管理コンポーネント２８０を有する。

履歴記録コンポーネント２７０は、複合機の利用履歴を記録する。ここでの利用履歴は、いつ、どの機能が利用されたか（あるいはどの機能についての利用を要求されたか）を示すものであればよい。ここで、複合機の機能は、要素プログラムの階層構造（図１、図２参照）に対応した階層構造を持っているので、利用履歴情報には、例えば、ジョブが実行された際、そのジョブにおいて各階層のどの機能が利用されたかを、その実行の日時と対応づけて記録する。例えば、「2017/8/30 16:37:25 スキャン、片面、モノクロ、ＰＤＦ、電子メール」のような利用履歴情報である。このうち、スキャンはコンポーネントレベルであり、残りの片面、モノクロ等はモジュールレベルである。

ここで、履歴記録コンポーネント２７０は、実際に実行されたジョブについての履歴情報だけでなく、ユーザが指示したがファームウエアのアップデートのために実行されなかった場合の履歴情報を記録してもよい。例えば、読取り処理コンポーネント２１０のアップデート中にはスキャン機能は利用できないが、上述したように、メインメニュー画面３００（図８参照）ではスキャンボタン３０６の選択を受け付け、その選択に応じて表示されるスキャンの設定画面３２０（図９参照）上で、アップデートのためスキャンが利用できない旨を表示する（メッセージバナー３２２）こともできる。このとき、ユーザがスキャン機能を利用したとして履歴に記録する。すなわち、実際にはスキャンは実行されていないが、スキャンの利用回数に加えるのである。これにより、各機能に対するユーザの需要の程度が利用履歴に記録され、次に説明する集計に反映されることになる。

また履歴記録コンポーネント２７０は、記録した利用履歴を集計する機能を有する。この集計では、各機能の利用回数の累計や、各機能がよく利用される時間帯（高利用時間帯と呼ぶ）を求める。例えば、ある機能の単位時間あたりの利用回数（あるいはその回数の当該機能の累計利用回数に対する割合）が閾値以上である時間帯を、その機能の高利用時間帯とすればよい。図１７に、履歴記録コンポーネント２７０が生成する集計結果データの例を示す。この例では、階層１（コンポーネントレベル）のスキャン機能について、その下位階層である階層２（モジュールレベル）の各機能の利用回数と高利用時間帯が示されている。なお、高利用時間帯を、平日と休日に分けて、あるいは曜日毎に求め、集計結果データに記録してもよい。

図１６の説明に戻ると、アップデート管理コンポーネント２８０は、履歴記録コンポーネント２７０が生成した利用履歴の集計結果データを参照して、ファームウエアのアップデート処理の実行を管理する。すなわち、アップデート管理コンポーネント２８０は、集計結果データに示されるある機能の高利用時間帯には、なるべくその機能が依存する要素プログラムのアップデート処理をしないように制御する。また、緊急度の高いアップデートの場合、高利用時間帯に実行しなければならなくなる場合もあるが、その場合でも、アップデート中にユーザが利用できない機能をできるだけ少なくするよう制御する。

図１８に、アップデート管理コンポーネント２８０の処理手順を例示する。この手順は、サーバ等から複合機に対してファームウエアアップデートの指示が送られてきた場合に実行される。その指示には、アップデート用のデータと、このデータがファームウエア中のどの要素プログラムについてのものかを示す情報とが含まれる。また、アップデート用のデータには、要素プログラムの階層構造（図１、図２参照）に従って各階層の要素プログラムについてのアップデート用データが識別できる形で含まれている。例えば、通信コンポーネント２５０についてのアップデート用データには、そのコンポーネントの下位のＦＴＰ通信モジュール２５２等のモジュールのうち、アップデートの対象である各モジュールについてのアップデート用データが、それぞれ識別可能な状態で含まれている。

アップデート管理コンポーネント２８０は、アップデート対象の要素プログラムについてのアップデート指示を受けると、その要素プログラムに対応する機能についての高利用時間帯を集計結果データから取得する（Ｓ５０）。例えば読取り処理コンポーネント２１０についてのアップデート指示を受けた場合、読取り処理コンポーネント２１０の高利用時間帯を取得する。次にアップデート管理コンポーネント２８０は、現在時刻が高利用時間帯に該当するか否かを判定する（Ｓ５２）。高利用時間帯に該当しない場合、指示されたアップデートを今実行してもユーザへの影響は少ないので、アップデート管理コンポーネント２８０は、そのアップデートを実行する（Ｓ５４）。このアップデートでは、アップデート対象として指示された要素プログラムを分割せずにまとめてアップデートする。

Ｓ５２で現在時刻が高利用時間帯に該当すると判定した場合、アップデート管理コンポーネント２８０は、今回のアップデートが緊急のものかどうかを判定する（Ｓ５６）。緊急か否かは、アップデート指示のパラメータとして指定されているので、そのパラメータを参照して判定すればよい。緊急でないと判定した場合、アップデート管理コンポーネント２８０は、今回指示されたアップデートを、その高利用時間帯が終わった後に実行するようアップデートスケジュールを設定する（Ｓ５８）。この後、アップデート管理コンポーネント２８０は、スケジュールした時刻が到来すると、保存していたアップデート用のデータを用いて、対象の要素プログラムのアップデートを行う。

Ｓ５６で今回のアップデートが緊急のものでないと判定した場合、アップデート管理コンポーネント２８０は、今回のアップデート対象の要素プログラムが下位レベルの要素プログラムに分けることができるかどうかを判定する（Ｓ６０）。図２の例で説明すると、今回のアップデート対象が通信コンポーネント２５０である場合、下位のＦＴＰ通信モジュール２５２等の複数のモジュールに分割できるので、Ｓ６０の判定結果はＹｅｓとなる。一方、今回のアップデート対象がＦＴＰ通信モジュール２５２である場合、ＦＴＰ通信モジュール２５２は階層構造の最下位なので、Ｓ６０の判定結果はＮｏとなる。

Ｓ６０の判定結果がＮｏの場合、アップデート管理コンポーネント２８０は、アップデート対象の要素プログラムをアップデートする（Ｓ５４）。

Ｓ６０の判定結果がＹｅｓの場合、アップデート管理コンポーネント２８０は、アップデート対象の要素プログラムをその下位レベルの複数の要素プログラムに分け、下位レベルの要素プログラムを１つずつアップデートする（Ｓ６２）。アップデート対象の要素プログラムをまとめてアップデートすると、アップデート中はその要素プログラムに依存する機能がすべて利用できない（あるいは時間がかかる等の制約が出てくる）。これに対して、下位レベルの要素プログラムごとに分けてアップデートすれば、個々の時点で利用できないのはその時点でアップデート中の下位レベルの要素プログラムに依存する機能のみであり、アップデート対象の要素プログラムに依存する機能が一度に利用できなくなることはない。なお、アップデート対象の要素プログラムをまとめてアップデートする方が、下位レベルに分けて分割アップデートするよりも所要時間が短いので、この例では、まとめてアップデートしてもユーザへの影響が少ない場合（高利用時間帯以外の場合等）にはまとめてアップデートしている。

図１８に示した処理はあくまで一例に過ぎない。別の例として、アップデートが指示された際、現在時刻がその対象の要素プログラムに依存する機能の高利用時間帯に該当しなければそのアップデートをすぐに実行し、該当すればそのアップデートを高利用時間帯の後に実行するという制御もあり得る。更に別の例として、アップデートが指示された際、現在時刻がその対象要素プログラムに依存する機能の高利用時間帯に該当しなければその要素プログラムをまとめてアップデートし、該当すれば下位レベルの要素プログラムに分割して順次アップデートするという制御もあり得る。また、単位時間あたりの利用回数が多い機能が依存している要素プログラムをアップデートする場合にはその要素プログラムを下位レベルに分割して順にアップデートし、単位時間あたりの利用回数が多い機能が依存していない要素プログラムをアップデートする場合には、その要素プログラム全体をまとめてアップデートしてもよい。

以上の例では、複合機のファームウエアのアップデートを例にとったが、本実施形態の手法は、複合機以外の情報処理装置のソフトウエアのアップデート一般に適用可能である。

以上に例示した複合機等の情報処理は、例えば、内蔵されるコンピュータにそれら各装置の機能を表すプログラムを実行させることにより実現される。ここで、コンピュータは、例えば、ハードウエアとして、ＣＰＵ等のプロセッサ、ランダムアクセスメモリ（ＲＡＭ）およびリードオンリメモリ（ＲＯＭ）等のメモリ（一次記憶）、ＨＤＤ（ハードディスクドライブ）を制御するＨＤＤコントローラ、各種Ｉ／Ｏ（入出力）インタフェース、ローカルエリアネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバスを介して接続された回路構成を有する。また、そのバスに対し、例えばＩ／Ｏインタフェース経由で、ＣＤやＤＶＤなどの可搬型ディスク記録媒体に対する読み取り及び／又は書き込みのためのディスクドライブ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び／又は書き込みのためのメモリリーダライタ、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク等の通信手段経由で、ハードディスクドライブ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがＲＡＭに読み出されＣＰＵ等のプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。

１０ ファームウエア、１２ コピーコントローラ、１４ 印刷コントローラ、１６ スキャンコントローラ、１８ ＦＡＸコントローラ、２０ メインコントローラ、２２ オプションコントローラ、３０ コンポーネント、３２ 本体処理部、３４ 実行制御部、２０５ ＵＩコンポーネント、２０８ ジョブ実行制御コンポーネント、２１０ 読取り処理コンポーネント、２２０ 画像処理コンポーネント、２３０ 蓄積処理コンポーネント、２４０ 印刷処理コンポーネント、２５０ 通信コンポーネント、２５２ ＦＴＰ通信モジュール、２５４ メール通信モジュール、２５６ ＨＴＴＰ通信モジュール、２５８ ＳＭＢ通信モジュール、２６０ セキュリティコンポーネント、２６２ 証明書管理モジュール、２６４ 暗号エンジンモジュール、２６６ 履歴管理モジュール、２６８ 暗号化モジュール、２７０ 履歴記録コンポーネント、２８０ アップデート管理コンポーネント。

Claims (14)

1. プロセッサと、
   前記プロセッサにより実行される複数の要素プログラムを含むソフトウエアを記憶する記憶装置と、
   を含み、
   前記複数の要素プログラムのうちの少なくとも１つの要素プログラムは、他の要素プログラムが更新中である場合、当該他の要素プログラムが更新中であることに対応するための特定処理を前記プロセッサに実行させる、ことを特徴とする情報処理装置。
2. 前記少なくとも１つの要素プログラムは、依頼対象処理を依頼した他の要素プログラムが更新中である場合に前記特定処理を実行し、
   前記特定処理は、前記他の要素プログラムの更新が完了した後に、前記他の要素プログラムに対して再度前記依頼対象処理を依頼することを含む、請求項１に記載の情報処理装置。
3. 操作画面を生成する画面生成手段を更に含み、
   前記特定処理は、前記他の要素プログラムが更新中であることを前記画面生成手段に通知する処理を含み、
   前記画面生成手段は、実行されている前記要素プログラムから他の要素プログラムが更新中であることを通知された場合、前記情報処理装置がユーザに提供する複数の機能のうち、当該他の要素プログラムを用いる機能について、当該機能の利用に制約があることを示す第１の操作画面を生成する、請求項１又は２に記載の情報処理装置。
4. 前記画面生成手段は、前記第１の操作画面として、前記複数の機能のうち更新中である前記他の要素プログラムを用いない機能については、制約なく利用を受け付ける画面を生成する、ことを特徴とする請求項３に記載の情報処理装置。
5. 前記画面生成手段は、前記複数の機能の各々と、その機能を実現するために用いられる１以上の前記要素プログラムとの対応関係の情報に従い、前記他の要素プログラムを用いる機能を特定する、ことを特徴とする請求項３又は４に記載の情報処理装置。
6. 前記画面生成手段は、
   前記複数の機能のうち使用する機能の選択をユーザから受け付けるための第２の操作画面を生成し、
   前記第２の操作画面に対して前記ユーザが選択した機能が、更新中である前記他の要素プログラムを用いるものである場合に、前記第１の操作画面として、当該機能が利用不可であることを示す画面を生成する、
   請求項４又は５に記載の情報処理装置。
7. 前記画面生成手段は、前記複数の機能のうち、更新中であることが通知された前記他の要素プログラムが、その機能のために実行される処理の流れの中で蓄積処理以前に実行される機能については、前記第１の操作画面としてその機能が実行不可であることを示す画面を生成し、前記他の要素プログラムが、その機能のために実行される処理の流れの中で蓄積処理より後に実行される機能については、前記第１の操作画面として、その機能は実行可能だが完了までに時間がかかることを示す画面を生成する、請求項４〜６のいずれか１項に記載の情報処理装置。
8. 前記第１の操作画面が表示されていたときに前記情報処理装置を操作していたユーザに対して、前記他の要素プログラムの更新の完了に応じて前記他の要素プログラムを用いる前記機能が利用可能となったときに、前記機能が利用可能となったことを示す通知を行う通知手段、
   を含む、請求項４〜７のいずれか１項に記載の情報処理装置。
9. 前記第１の操作画面は、前記ユーザに対して前記他のプログラムの更新の完了に応じて前記機能が利用できるようになったときに通知を求めるか否かの入力を求める画像要素、を含み、
   前記通知手段は、前記画像要素に応じて前記通知を求める旨の入力が前記ユーザからなされた場合に、前記他の要素プログラムの更新の完了に応じて前記他の要素プログラムを用いる前記機能が利用可能となったときに前記通知を行う、請求項８に記載の情報処理装置。
10. 前記複数の要素プログラムの各々の使用状況を示す履歴情報を記録する履歴記録手段と、
    前記履歴情報に応じて前記ソフトウエアの更新を制御する更新制御手段と、
    を更に含む、請求項１〜９のいずれか１項に記載の情報処理装置。
11. 前記更新制御手段は、前記履歴情報において更新の対象である要素プログラムの使用頻度が閾値以上である期間は、当該要素プログラムの更新を行わない、請求項１０に記載の情報処理装置。
12. 前記更新制御手段は、前記履歴情報において更新の対象である要素プログラムの使用頻度が閾値以上である期間内でも特定の場合には当該要素プログラムの更新を行い、この場合の更新では、当該要素プログラムを構成する下位の要素プログラムの各々を単位として更新を実行する、請求項１０又は１１に記載の情報処理装置。
13. 前記履歴記録手段は、前記第２の操作画面において前記ユーザが機能を選択した場合に、その機能が更新中である前記他の要素プログラムを用いるために使用不可であっても、その機能に用いられる各要素プログラムがそのとき使用されたことを示す履歴情報を記録する、
    請求項５を引用する請求項１０〜１２のいずれか１項に記載の情報処理装置。
14. 情報処理装置に含まれる記憶装置内に記憶される複数の要素プログラムを含むプログラムであって、
    前記複数の要素プログラムのうちの少なくとも１つの要素プログラムは、他の要素プログラムが更新中である場合、当該他の要素プログラムが更新中であることに対応するための特定処理を前記情報処理装置内のプロセッサに実行させる、プログラム。