JP2005196745A - 情報処理装置、プログラム復旧方法、プログラム復旧プログラム及び記録媒体 - Google Patents

Abstract

【課題】 プログラムの更新に係り生じる問題を容易に解決し、装置及び／又はプログラムを復旧させることを目的とする。
【解決手段】 プログラムを記憶するプログラム記憶手段と、該プログラム記憶手段に記憶されているプログラムに係る更新データを受信する更新データ受信手段と、更新データに基づいて、プログラム記憶手段に記憶されている対応するプログラムを更新するプログラム更新手段と、を有する情報処理装置であって、当該情報処理装置が前回起動されていたときに、プログラム更新手段におけるプログラムの更新が中断されたかどうかを判定する更新中断判定手段（ステップＳ１１）と、更新中断判定手段（ステップＳ１１）における判定結果に応じて、対応するオペレーティングシステムを起動するオペレーティングシステム起動手段（ステップＳ１２又はステップＳ１７）と、プログラム記憶手段に記憶されているプログラムを復旧する第一プログラム復旧手段と、を有することによって上記課題を解決する。
【選択図】 図１１

Description

本発明は、情報処理装置、プログラム復旧方法、プログラム復旧プログラム及び記録媒体に関する。

従来、プリンタ、コピー、ファクシミリ、スキャナ等の装置はそれぞれ別筐体として配設されるのが一般的であった。しかし、最近では、これら各装置の機能を１つの筐体内に収納した画像形成装置が知られている。この画像形成装置は、１つの筐体内に表示部、印刷部及び撮像部等を設けると共に、プリンタ、コピー、スキャナ及びファクシミリ装置にそれぞれ対応する４種類のソフトウェアを設け、ソフトウェアの切り替えによって、当該装置をプリンタ、コピー、スキャナ及びファクシミリ装置として動作させるものである。

このような従来の画像形成装置では、プリンタ、コピー、スキャナ及びファクシミリの各機能ごとにソフトウェアを組み込んだ書き換え不可能なＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）を搭載したコントローラボードを設け、複数の機能を実現する構成としていた。

したがって、従来の画像形成装置では、各機能の変更、追加等を行う場合に、機能追加又は機能変更を反映したプログラムを組み込んだ新たなＲＯＭを用意してＲＯＭごと交換するというハードウェア的な作業が必要であり、更新作業の労力が過大なものとなっていた。

このため、最近の画像形成装置はフラッシュメモリのように電気的に内容の書き換えが可能なＲＯＭにプリンタ、コピー、スキャナ及びファクシミリの各機能を含むプログラムを組み込み、複数の機能を複合サービスとして実現している。

このような画像形成装置は、各機能の変更、追加等を行う場合に、機能追加又は機能変更を行ったプログラムを更新データとしてフラッシュカードに記録し、このフラッシュカードを画像形成装置のフラッシュカードインタフェースに挿入した状態で画像形成装置を再起動する。

このとき画像形成装置は、更新プログラムによって更新データをフラッシュカードから読み出し、読み出された更新データによってフラッシュメモリに記録されているプログラムが更新されるようになっている。このように、最近の画像形成装置では、電気的に書き換え可能というフラッシュメモリの特性を利用して、ソフトウェア的にＲＯＭ更新を行っている。

例えば特許文献１には、ソフトウェアの変更や追加に柔軟に対処することを課題とする技術が記載されている。

ところで、出願人は、表示部、印刷部及び撮像部等の画像形成処理で使用されるハードウェア資源を有し、プリンタ、コピー、スキャナ及びファクシミリ等の各ユーザサービスにそれぞれ固有の処理を行うアプリケーションを複数搭載し、これらのアプリケーションとハードウェア資源との間に介在して、ユーザサービスを提供する際に、アプリケーションの少なくとも２つが共通的に必要とするハードウェア資源の管理、実行制御並びに画像形成処理を行う各種コントロールサービスからなるプラットフォームを備えた画像形成装置を発明した（特許文献２参照。）。

なお、ユーザサービスとはユーザに提供する画像形成に係るサービスをいう。また、コントロールサービスとはアプリケーションに画像形成に係るハードウェア資源を提供するサービスをいう。

この画像形成装置によれば、アプリケーションの少なくとも２つが共通的に必要とするハードウェア資源の管理、実行制御並びに画像形成処理を行うプラットフォームを備えた構成とすることによって、通常の画像形成装置に比べて将来的なアプリケーションの追加やコントロールサービスの追加等のソフトウェア開発を容易に行うことができ、拡張性が高いものとなっている。このため、このような構成の画像形成装置では、機能追加や機能変更によるプログラム更新の必要性が従来の画像形成装置よりも非常に高くなってくる。

例えば、画像形成装置の使用契約では、プリンタ、コピー、スキャナの機能のみを使用する契約で画像形成装置を導入し稼働していたが、使用契約の変更によりファクシミリ機能を追加して画像形成装置を使用する場合も考えられる。この場合、ファクシミリ機能の追加により、ファクシミリ用のアプリケーションの追加、及びこれに伴うプラットフォームの追加、変更が必要となってくる。

このような複数のアプリケーション及び共通的な処理を行うプラットフォームを備えた構成の画像形成装置の場合には、特にこのような機能変更、機能追加の要求が不定期に且つ頻繁に生じるケースが多い。このため、従来のプログラム更新方法のように、プログラム更新を行うごとにフラッシュカードを入手し、そのフラッシュカードから更新データを読み込んでＲＯＭに格納されたプログラムの更新を行うという作業では、不定期に且つ頻繁に生じるプログラム更新のニーズに迅速に対応できない。また、フラッシュカードを用いたプログラム更新方法では、更新作業が非常に煩雑となり、作業効率が悪いという問題がある。

したがって、出願人は、ネットワーク経由でプログラムの更新データを受信し、該更新データを用いてプログラム更新を行う画像形成装置、プログラム更新方法及び記録媒体を発明した（特許文献３参照。）。
特開２００１−２６８３０６号公報 特開２００２−８２８０６号公報 特開２００３−１８２１９１号公報

しかしながら、例えば上述したネットワーク経由でプログラムの更新データを受信し、該更新データを用いてプログラム更新を行う画像形成装置では、プログラム更新中に停電やコンセント抜け、人為的電源ＯＦＦ等が起こると、次回の画像形成装置の電源ＯＮで、画像形成装置の機能の一部又は全てが使用不可能になってしまう問題があった。

以下、プログラムの更新中断後に画像形成装置の機能の一部が使用不可能になった一例を、図１を用いて説明する。図１は、プログラムの更新中断後に画像形成装置の機能の一部が使用不可能になった一例を説明するための図である。なお、画像形成装置の構成の詳細は後述する図３等を用いて説明する。

図１（Ａ）は、プラットフォームの更新前の画像形成装置の一例を示している。一方、図１（Ｂ）は、プラットフォームの更新中に、例えば人為的に電源ＯＦＦされ、再び起動した後の画像形成装置の一例を示している。

図１（Ｂ）は、図１（Ａ）と比べて、ＳＲＭと、ＳＣＳと、ＮＣＳと、は、ｖ．１．００からｖ．１．１０にプログラムが更新されているが、例えばプラットフォームを構成するプロセスの一つであるＥＣＳに係るプログラムの更新中に画像形成装置の電源がＯＦＦされたため、図１（Ｂ）ではＥＣＳが起動されておらず、コピーアプリ及びプリンタアプリ等が使用不可能となっている。

また、例えば上述したネットワーク経由でプログラムの更新データを受信し、該更新データを用いてプログラム更新を行う画像形成装置では、プログラム更新後の画像形成装置で、更新を行ったプログラムと、更新を行わなかったプログラムと、の組み合わせ等が原因で画像形成装置の機能の一部又は全てが使用不可能又は動作が不安定となった場合も、画像形成装置を容易に復旧できない問題もあった。

以下、バージョンの不整合により画像形成装置の機能の一部が使用不可能になった一例を、図２を用いて説明する。図２は、バージョンの不整合により画像形成装置の機能の一部が使用不可能になった一例を説明するための図である。

図２（Ａ）は、コピーアプリの更新前の画像形成装置の一例を示している。一方、図２（Ｂ）は、コピーアプリの更新後、コピーアプリｖ．２．００と、ＥＣＳｖ．１．００と、の組み合わせだと、コピーアプリが正常に動作しない一例を示している。

本発明は、上記の点に鑑みなされたもので、プログラムの更新に係り生じる問題を容易に解決し、装置及び／又はプログラムを復旧させることを目的とする。

そこで、上記問題を解決するため、本発明は、プログラムを記憶するプログラム記憶手段と、該プログラム記憶手段に記憶されているプログラムに係る更新データを受信する更新データ受信手段と、前記更新データに基づいて、前記プログラム記憶手段に記憶されている対応するプログラムを更新するプログラム更新手段と、を有する情報処理装置であって、当該情報処理装置が前回起動されていたときに、前記プログラム更新手段における前記プログラムの更新が中断されたかどうかを判定する更新中断判定手段と、前記更新中断判定手段における判定結果に応じて、対応するオペレーティングシステムを起動するオペレーティングシステム起動手段と、前記プログラム記憶手段に記憶されているプログラムを復旧する第一プログラム復旧手段と、を有することを特徴とする。

また、本発明は、プログラムを記憶するプログラム記憶手段と、該プログラム記憶手段に記憶されているプログラムに係る更新データを受信する更新データ受信手段と、前記更新データに基づいて、前記プログラム記憶手段に記憶されている対応するプログラムを更新するプログラム更新手段と、を有する情報処理装置であって、当該情報処理装置が前回起動されていたときに、前記プログラム記憶手段に記憶されているプログラムを復旧するため、リブートされたかどうかを判定するリブート判定手段と、前記リブート判定手段における判定結果に応じて、対応するオペレーティングシステムを起動するオペレーティングシステム起動手段と、前記プログラム記憶手段に記憶されているプログラムを復旧する第二プログラム復旧手段と、を有することを特徴とする。

なお、プログラム記憶手段は、例えば後述するフラッシュメモリ２０４に対応する。

本発明によれば、プログラムの更新に係り生じる問題を容易に解決し、装置及び／又はプログラムを復旧させることができる。

また、上記課題を解決するための手段として、プログラム復旧方法、プログラム復旧プログラム及び記録媒体としてもよい。

本発明によれば、プログラムの更新に係り生じる問題を容易に解決し、装置及び／又はプログラムを復旧させることができる。

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

図３は、画像形成装置（以下、複合機という）の構成を示すブロック図（その１）である。なお、図３では、後述するＲＯＭモニタ４１０によって、汎用ＯＳ１２１が起動された場合の複合機の構成の一例を示している。

図３に示すように、複合機１００は、プロッタ１０１と、スキャナ１０２と、ＦＣＵ（Ｆａｘ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）１０３と、その他ハードウェアリソース１０４等を有すると共に、汎用ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）１２１と、プラットフォーム１２０と、アプリケーション１３０と、から構成されるソフトウェア群１１０と、電源投入時に実行される複合機起動部１４０と、を備えている。

複合機起動部１４０は、複合機１００の電源投入時にまず始めに実行され、後述する更新中断情報に更新情報が格納されていない場合及び／又は更新中断情報にメンテナンスフラグが格納されていない場合、図３に示される汎用ＯＳ１２１や、プラットフォーム１２０、アプリケーション１３０を起動する。

プラットフォーム１２０は、アプリケーション１３０からの処理要求を解釈してハードウェア資源の獲得要求を発生させるコントロールサービスと、一又は複数のハードウェア資源の管理を行い、コントロールサービスからの獲得要求を調停するシステムリソースマネージャ（ＳＲＭ）１２３と、を有する。

コントロールサービスは、複数のサービスモジュールから形成され、ＳＣＳ（システムコントロールサービス）１２２と、ＥＣＳ（エンジンコントロールサービス）１２４と、ＭＣＳ（メモリコントロールサービス）１２５と、ＯＣＳ（オペレーションパネルコントロールサービス）１２６と、ＦＣＳ（ファックスコントロールサービス）１２７と、ＮＣＳ（ネットワークコントロールサービス）１２８と、から構成される。なお、プラットフォーム１２０は、あらかじめ定義された関数によりアプリケーション１３０から処理要求を受信可能とするアプリケーションプログラムインタフェース（ＡＰＩ）を有する。

汎用ＯＳ１２１は、ＵＮＩＸ（登録商標）等の汎用オペレーティングシステムであり、プラットフォーム１２０並びにアプリケーション１３０の各ソフトウェアをそれぞれプロセスとして並列実行する。なお、図３に示される汎用ＯＳ１２１は、プロセスに通常モードスレッドと、ＲＯＭ更新モードスレッドとが存在する場合、初め、各プロセスの通常モードスレッドを実行する。

ＭＣＳ１２５は、メモリの制御を行うプロセスとして起動される。ＭＣＳ１２５のプロセスは、画像メモリの取得及び解放、ハードディスク装置（ＨＤＤ）の利用、画像データの圧縮及び伸張等のコピー、プリンタ、ファクシミリ及びスキャナ等の複合サービスを行う通常モードスレッドと、後述するリモートＲＯＭ更新アプリ１１７によって更新データパケットから展開された更新データを格納する更新データ領域をＳＤＲＡＭ２０３等に確保する等の処理を行うＲＯＭ更新モードスレッドと、を有している。

ＯＣＳ１２６のプロセスは、オペレータと本体制御間の情報伝達手段となる操作パネル（オペレーションパネル１３１０）の制御を行う通常モードスレッドと、ＲＯＭの更新に係る情報等を操作パネル（オペレーションパネル１３１０）に表示する処理等を行うＲＯＭ更新モードスレッドと、を有している。

ＦＣＳ１２７のプロセスは、システムコントローラの各アプリ層からＰＳＴＮ／ＩＳＤＮ網を利用したファクシミリ送受信、ＢＫＭ（バックアップＳＲＡＭ）で管理されている各種ファクシミリデータの登録／引用、ファクシミリ読みとり、ファクシミリ受信印刷、複合送受信を行うためのＡＰＩを提供する等の処理を行う通常モードスレッドと、かかる機能を実行せずに単に起動されるだけのＲＯＭ更新モードスレッドと、を有している。

ＮＣＳ１２８は、ネットワークＩ／Ｏを必要とするアプリケーションに対して共通に利用できるサービスを提供するためのプロセスであり、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分けたり、アプリケーションからデータをネットワーク側に送信する際の仲介を行ったりする等の処理を行う通常モードスレッドを有している。また、ＮＣＳ１２８の通常モードスレッドでは、更に、ネットワークに接続された、例えば複合機開発元のホストコンピュータやアプリケーション開発元のサードベンダ等のリモートホストから、フラッシュメモリ２０４のＲＯＭ更新データパケットを受信する。

なお、ＮＣＳ１２８のプロセスは、フラッシュメモリ２０４のＲＯＭ更新データパケットに含まれる更新データを、後述するリモートＲＯＭ更新アプリ１１７に渡す等の処理を行う、ＲＯＭ更新モードスレッドも有している。

ＳＲＭ１２３のプロセスは、ＳＣＳ１２２と共にシステムの制御及びリソースの管理を行うものである。ＳＲＭ１２３のプロセスは、スキャナ部やプリンタ部等のエンジン、メモリ、ＨＤＤファイル、ホストＩ／Ｏ（セントロニクスＩ／Ｆ、ＩＥＥＥ１３９４ Ｉ／Ｆ、ＵＳＢ Ｉ／Ｆ、ＮＩＣ Ｉ／Ｆ等）のハードウェア資源を利用する上位層からの要求にしたがって調停を行い、実行制御する等の処理を行う通常モードスレッドと、かかるリソース管理を実行せずに単に起動されるだけのＲＯＭ更新モードスレッドを有している。 具体的には、このＳＲＭ１２３の通常モードスレッドは、要求されたハードウェア資源が利用可能であるか（他の要求により利用されていないかどうか）を判断し、利用可能であれば要求されたハードウェア資源が利用可能である旨を上位層に伝える。また、ＳＲＭ１２３の通常モードスレッドは、上位層からの要求に対してハードウェア資源の利用スケジューリングを行い、要求内容（例えば、プリンタエンジンにより紙搬送と作像動作、メモリ確保、ファイル生成等）を直接実施している。

ＳＣＳ１２２のプロセスは、アプリ管理、操作部制御、システム画面表示、ＬＥＤ表示、リソース管理、割り込みアプリ制御等の処理を行う通常モードスレッドを有している。

また、ＳＣＳ１２２の通常モードスレッドは、後述するリモートＲＯＭ更新アプリ１１７からの要求に基づいて、プリンタアプリ１１１、コピーアプリ１１２、ファックスアプリ１１３、スキャナアプリ１１４、ネットファイルアプリ１１５や、ＥＣＳ１２４、ＭＣＳ１２５、ＯＣＳ１２６、ＦＣＳ１２７、ＮＣＳ１２８等にＲＯＭ更新モードスレッドの起動依頼を通知する。

また、ＳＣＳ１２２のプロセスは、ＲＯＭ更新モードスレッドも有し、該ＲＯＭ更新モードスレッドは、ＳＤＲＡＭ２０３等に展開された更新データの中から、複合機１００で動作するアプリケーション１３０、プラットフォーム１２０の構成に応じた更新データを選定する処理を行ったり、後述するＲＯＭ更新部４３０を起動したりする処理を行う。

ＥＣＳ１２４のプロセスは、プロッタ１０１、スキャナ１０２、ＦＣＵ（Ｆａｘ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）１０３、その他ハードウェアリソース１０４、のエンジンの制御等の処理を行う通常モードスレッドと、このようなエンジン制御を行わずに単に起動されるだけのＲＯＭ更新モードスレッドと、を有している。

このように、ＳＲＭ１２３、ＥＣＳ１２４、ＦＣＳ１２７の各ＲＯＭ更新モードスレッドはいずれも単に起動されるだけであるが、これは、ＲＯＭ更新処理時に、複合機内部で動作するコントロールサービスの存在を示すために起動されるようになっている。一方、ＳＣＳ１２２、ＭＣＳ１２５、ＯＣＳ１２６、ＮＣＳ１２８の各ＲＯＭ更新モードスレッドも、それぞれＲＯＭ更新に必要な処理を行うと共に、複合機内部で動作するコントロールサービスの存在を示すために起動されるようになっている。

アプリケーション１３０は、ページ記述言語（ＰＤＬ）、ＰＣＬ及びポストスクリプト（ＰＳ）を有するプリンタ用のアプリケーションであるプリンタアプリ１１１と、コピー用アプリケーションであるコピーアプリ１１２と、ファクシミリ用アプリケーションであるファックスアプリ１１３と、スキャナ用アプリケーションであるスキャナアプリ１１４と、ネットワークファイル用アプリケーションであるネットファイルアプリ１１５と、ＮＣＳ１２８によりネットワーク経由で受信した更新データパケットを更新データに展開し、その更新データをＭＣＳ１２５のＲＯＭ更新モードスレッドによって確保されたＳＤＲＡＭ２０３等の更新データ領域に格納する処理等を行うリモートＲＯＭ更新アプリ（以下、ＲＲＵアプリという）１１７と、を有している。

これらの各アプリも、プラットフォーム１２０と同様にそれぞれプロセスとして起動され、ＲＲＵアプリ１１７以外の各アプリは、各々上述したような処理を行う通常モードスレッドと、当該自身の存在を示すために起動されるＲＯＭ更新モードスレッドと、を有する。

以下、複合機１００のハードウェア構成の一例を、図４を用いて説明する。図４は、複合機のハードウェア構成を示すブロック図である。

図４に示すように、複合機１００は、オペレーションパネル１３１０、ＦＡＸコントロールユニット（ＦＣＵ）１０３、エンジン部１３５０（スキャナ１０２等が接続される）及びプロッタ１０１とコントローラ１３００のＡＳＩＣ１３０１とをＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ ＣｏｍＰｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バス１３０９等で接続した構成となる。

コントローラ１３００は、ＡＳＩＣ１３０１にＮＶＲＡＭ２０８、ＳＤＲＡＭ２０３、フラッシュメモリ２０４、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）１３０３等を接続すると共に、このＡＳＩＣ１３０１とＣＰＵ１３０４とをＣＰＵチップセットのＮＢ１３０５を介して接続している。このように、ＮＢ１３０５を介して接続する理由は、ＣＰＵ１３０４自体のインターフェースが公開されていないためである。

ここで、このＡＳＩＣ１３０１とＮＢ１３０５は、単にＰＣＩを介して接続されているのではなく、ＡＧＰ１３０８を介して接続されている。このようにＡＧＰ１３０８を介して接続することとした理由は、この複合機１００が図３に示したプラットフォーム１２０やアプリケーション１３０を形成する複数のプロセスを実行制御する関係上、これらを低速のＰＣＩで接続したのでは、パフォーマンスが低下するからである。

ＣＰＵ１３０４は、複合機１００の全体制御を行うものであり、具体的には、汎用ＯＳ１２１上でＳＲＭ１２３や、プラットフォーム１２０を形成するＳＣＳ１２２、ＥＣＳ１２４、ＭＣＳ１２５、ＯＣＳ１２６、ＦＣＳ１２７、ＮＣＳ１２８をそれぞれプロセスとして起動して実行させると共に、アプリケーション１３０を形成するプリンタアプリ１１１、コピーアプリ１１２、ファックスアプリ１１３、スキャナアプリ１１４、ネットファイルアプリ１１５、ＲＲＵアプリ１１７を起動して実行させる。なお、例えば、複合機１００が後述する図１０に示すような構成の場合、ＣＰＵ１３０４は、汎用レスキューＯＳ１３１上でＳＲＭ１２３や、プラットフォーム１２０を形成するＳＣＳ１２２、ＭＣＳ１２５をそれぞれプロセスとして起動して実行させる。

ＮＢ１３０５は、ＣＰＵ１３０４と、システムメモリ１３０６と、ＳＢ１３０７と、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）１３４１と、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）１３３０と、ＩＥＥＥ１３９４１３４０と、セントロニクス１３４２と、ドライバＩ／Ｆ１３４３と、ＡＳＩＣ１３０１と、を接続するためのブリッジである。

システムメモリ１３０６は、複合機の描画用メモリ等として用いるメモリであり、ＳＢ１３０７は、ＮＢ１３０５と周辺デバイスとを接続するためのブリッジである。ＳＢ１３０７は、コントローラ１３００での時間を計測するＲＴＣ（Ｒｅａｌ Ｔｉｍｅ Ｃｌｏｃｋ）を有する。また、ＳＢ１３０７は、内部にＵＳＢホストを有し、例えば、ＵＳＢ接続のカメラを接続することで画像データを取り込むことが可能であり、また、他のＵＳＢターゲットからデータを受け取ることも可能である。

ドライバＩ／Ｆ１３４３は、挿入された、プログラム又はアプリケーション等が格納されている記録媒体から、プログラム又はアプリケーション等を読み込んで、複合機１００に搭載するのに用いるＩ／Ｆである。なお、例えば記録媒体としては、ＳＤメモリカード、スマートメディア、マルチメディアカード、コンパクトフラッシュ（登録商標）等がある。

ＳＤＲＡＭ２０３は、更新データパケットをネットワーク経由で受信したときに、受信した更新データパケットから展開される更新データを格納する更新データ領域が確保される不揮発性メモリである。

ＮＶＲＡＭ２０８は、例えば後述する更新中断情報等を格納する不揮発性メモリである。

フラッシュメモリ（以下、フラッシュＲＯＭという）２０４には、上述の各アプリ、プラットフォームを構成する各コントロールサービスやＳＲＭ１２３の各プログラムが格納されている。複合機１００は、これらの各プログラムがあらかじめフラッシュＲＯＭ２０４に組み込まれた状態で出荷され、ＲＯＭ更新データパケットの受信によって、フラッシュＲＯＭ２０４のプログラムが更新されるという、リモートＲＯＭ更新の処理が実行されるようになっている。

ＨＤＤ１３０３は、画像データの蓄積、プログラムの蓄積、フォントデータの蓄積、フォームの蓄積、文書の蓄積を行うストレージであり、オペレーションパネル１３１０は、操作者からの入力操作の受け付け並びに操作者に向けた表示を行う操作部である。

ＡＳＩＣ１３０１には、ＮＶＲＡＭ２０８及びＳＤＲＡＭ２０３等を接続するためのＲＡＭインターフェースと、フラッシュＲＯＭ２０４を接続するためのＲＯＭインターフェースと、ＨＤＤ１３０３を接続するためのハードディスクインターフェースと、が設けられ、これらの記憶部に対して画像データの入出力を行う場合には、入出力先がＲＡＭインターフェース又はＲＯＭインターフェース又はハードディスクインターフェースに切り替えられる。

ＡＧＰ１３０８は、グラフィック処理を高速化するために提案されたグラフィックスアクセラレーターカード用のバスインターフェースであり、システムメモリ１３０６に高スループットで直接アクセスすることにより、グラフィックスアクセラレーターカードを高速にする。

以下、リモートＲＯＭ更新の全体処理の一例を、図５及び図６を用いて説明する。図５は、リモートＲＯＭ更新の全体処理を説明するための図（その１）である。

図５に示されるように、複合機１００が通常の複合サービスの動作を実行しているときは、通常モードスレッドと、ＲＯＭ更新モードスレッドと、を有している各アプリ、各コントロールサービス等は、何れも通常モードスレッドを実行している。

この状態で、ネットワーク経由で複合機開発元のホストコンピュータやアプリケーション開発元のサードベンダのホストコンピュータ等のリモートホストから更新データパケットが送信されてくると、ＮＣＳ１２８の通常モードスレッドは、更新データパケットを受信する（シーケンスＳＱ１。）。

ＮＣＳ１２８の通常モードスレッドは、受信したパケットの内容を判断し、更新データパケットであると判定すると、ＲＯＭの更新データパケットを受信した旨をＲＲＵアプリ１１７に通知する（シーケンスＳＱ２。）。

ＮＣＳ１２８の通常モードスレッドよりＲＯＭの更新データパケットを受信した旨を通知されたＲＲＵアプリ１１７は、ＳＣＳ１２２の通常モードスレッドに対して、ＲＯＭ更新モードスレッドの移行依頼通知の発行を要求する（シーケンスＳＱ３。）。

ＲＲＵアプリ１１７よりＲＯＭ更新モードスレッドの移行依頼通知の発行を要求されたＳＣＳ１２２の通常モードスレッドは、プリンタアプリ１１１、コピーアプリ１１２、ファックスアプリ１１３、スキャナアプリ１１４、ネットファイルアプリ１１５、ＥＣＳ１２４、ＭＣＳ１２５、ＯＣＳ１２６、ＦＣＳ１２７、ＮＣＳ１２８の各通常モードスレッドに対して、ＲＯＭ更新モードスレッドの移行依頼を通知する（シーケンスＳＱ４。）。

図６は、リモートＲＯＭ更新の全体処理を説明するための図（その２）である。

図５のシーケンスＳＱ４によって、ＳＣＳ１２２の通常モードスレッドより、ＲＯＭ更新モードスレッドの移行依頼を通知されたプリンタアプリ１１１、コピーアプリ１１２、ファックスアプリ１１３、スキャナアプリ１１４、ネットファイルアプリ１１５、ＥＣＳ１２４、ＭＣＳ１２５、ＯＣＳ１２６、ＦＣＳ１２７、ＮＣＳ１２８は、図６に示されるようにそれぞれ通常モードスレッドからＲＯＭ更新モードスレッドに移行する。

また、ＲＲＵアプリ１１７は、更新データパケットを展開するのに必要な領域を得るために、ＭＣＳ１２５のＲＯＭ更新モードスレッドに対して、更新データ領域の確保を要求する（シーケンスＳＱ５。）。

ＲＲＵアプリ１１７より更新データ領域の確保を要求されたＭＣＳ１２５のＲＯＭ更新モードスレッドは、例えば、ＳＤＲＡＭ２０３上に更新データ領域を確保して、該更新データ領域の先頭アドレスと、該更新データ領域の領域サイズと、をＲＲＵアプリ１１７に返す（シーケンスＳＱ６。）。

ＭＣＳ１２５のＲＯＭ更新モードスレッドより、更新データ領域の先頭アドレスと、該更新データ領域の領域サイズと、を受け取ったＲＲＵアプリ１１７は、ＮＣＳ１２８のＲＯＭ更新モードスレッドより更新データパケットを受け取り（シーケンスＳＱ７）、ネットワーク情報を除去し、また圧縮形式のデータを伸張した更新データパケットを、ＭＣＳ１２５のＲＯＭ更新モードスレッドから通知された更新データ領域の先頭アドレスから展開する。

以下、更新データ領域に展開された更新データパケットの一例を、図７を用いて説明する。図７は、複合機で受信した更新データパケットの展開後のデータ構造図である。

図７に示されるように、展開された更新データパケットは、ヘッダ部３０２と、データ部３０３と、を含む。

ヘッダ部３０２は、更新するモジュールに対応するように、モジュールごとのヘッダブロックに分かれている。各ヘッダブロックには、次のヘッダブロックまでのオフセットである次ヘッダオフセットと、モジュールの更新データまでのオフセットである更新データオフセットと、更新データのサイズと、モジュールの識別情報であるモジュールＩＤと、該モジュールのフラッシュＲＯＭ２０４上での相対番地を示す更新先アドレスと、該モジュールのサイズである更新先領域長と、を含む。

データ部３０３は、更新データがモジュールごとに格納されている。なお、各モジュールの更新データの先頭は、モジュールに対応するヘッダブロックの更新データオフセットにより参照できるようになっている。

図６に戻り、ＲＲＵアプリ１１７は、更新データパケットを展開した更新データ領域の先頭アドレスをＳＣＳ１２２の通常モードスレッドに通知し、更新データの選定を依頼する（シーケンスＳＱ８。）。

ＲＲＵアプリ１１７より更新データの選定依頼を受け取ったＳＣＳ１２２の通常モードスレッドは、ＳＣＳ１２２のＲＯＭ更新モードスレッドを起動し、後述する図１２に示すような処理を行い、更新データを選定する（シーケンスＳＱ９。）。

また、ＳＣＳ１２２のＲＯＭ更新モードスレッドは、後述する図９に示すＲＯＭ更新部４３０を起動し、後述する図１３に示すようなＲＯＭの更新処理を行う（シーケンスＳＱ１０。）。

以下、複合機起動部１４０の構成の一例を、図８を用いて説明する。図８は、複合機起動部の構成の一例を示すブロック図である。

図８に示されるように、複合機起動部１４０は、ＲＯＭモニタ４１０と、プログラム起動部４２０と、を含む。

ＲＯＭモニタ４１０は、後述する更新中断情報に更新情報が格納されていない場合及び／又は更新中断情報にメンテナンスフラグが格納されていない場合、図３に示される汎用ＯＳ１２１を起動し、更新中断情報に更新情報が格納されている場合及び／又は更新中断情報にメンテナンスフラグが格納されている場合、後述する図１０に示されるように、汎用レスキューＯＳ１３１を起動する。

プログラム起動部４２０は、汎用ＯＳ１２１又は汎用レスキューＯＳ１３１より呼び出され、サービス層起動部４２２と、アプリ起動部４２３と、起動情報設定部４２４と、を含む。

サービス起動部４２２は、プログラム起動部４２０が汎用ＯＳ１２１より呼び出された場合は、汎用ＯＳ１２１の起動情報を取得して、プラットフォーム１２０を起動する。一方、サービス起動部４２２は、プログラム起動部４２０が汎用レスキューＯＳ１３１より呼び出された場合は、汎用レスキューＯＳ１３１の起動情報を取得して、後述する図１０に示すように、例えばＳＲＭ１２３や、ＭＣＳ１２５、ＳＣＳ１２２等を含むプラットフォーム１２０を起動する。

アプリ起動部４２３は、プログラム起動部４２０が汎用ＯＳ１２１より呼び出された場合に実行され、各アプリの起動情報を取得して各アプリを起動する。なお、後述する実施例４等に示されるように、アプリ起動部４２３は、プログラム起動部４２０が汎用レスキューＯＳ１３１より呼び出された場合であっても実行され、ＲＲＵアプリ１１７の起動情報を取得してＲＲＵアプリ１１７を起動するようにしてもよい。

起動情報設定部４２４は、プラットフォーム１２０に含まれる各コントロールサービスやＳＲＭ１２３、アプリケーション１３０に含まれる各アプリのＲＯＭ更新モードスレッドが実行されたときに起動され、各コントロールサービスや、ＳＲＭ１２３及び各アプリの起動情報を取得して、取得した起動情報を環境変数に設定する。なお、起動情報設定部４２４は、後述する各コントロールサービスやＳＲＭ１２３、アプリケーション１３０に含まれる各アプリのレスキューモードスレッドが実行されたときにも起動され、各コントロールサービスや、ＳＲＭ１２３及び各アプリの起動情報を取得して、取得した起動情報を環境変数に設定するようにしてもよい。

以下、ＳＣＳ１２２に含まれるＲＯＭ更新部４３０の一例を、後述する図９を用いて説明する。図９は、ＲＯＭ更新部の構成の一例を示すブロック図である。

図９に示されるように、ＲＯＭ更新部４３０は、更新情報格納部４３１と、領域データ蓄積部４３２と、ＲＯＭ更新部４３３と、更新情報削除部４３４と、を含む。また、後述する実施例２、３、４、５、６、７の場合は、更に表示制御部４３５を含む。また、後述する実施例４の場合は、更に送信制御部４３６を含む。

更新情報格納部４３１は、図７に示したようなモジュールＩＤや、更新先アドレス等の更新情報を更新中断情報に格納する。

領域データ蓄積部４３２は、更新される領域のデータをＨＤＤ１３０３等の二次記憶装置に蓄積する。

ＲＯＭ更新部４３３は、更新データに基づいて、該更新データに含まれるプログラムで、フラッシュＲＯＭ２０４の対応するプログラムを更新する。

更新情報削除部４３４は、更新情報格納部４３１が格納した更新情報を、更新中断情報から削除する。

表示制御部４３５は、例えばＯＣＳ１２６が起動しているかどうかを判定し、ＯＣＳ１２６が起動していると判定すると、フラッシュＲＯＭ２０４の復旧中画面を作成し、ＯＣＳ１２６を介してオペレーションパネル１３１０に表示したり、エラー画面を作成し、ＯＣＳ１２６を介してオペレーションパネル１３１０に表示したりする。

送信制御部４３６は、例えばＮＣＳ１２８が起動しているかどうかを判定し、ＮＣＳ１２８が起動していると判定すると、フラッシュＲＯＭ２０４の復旧に係る情報を、ＮＣＳ１２８を介してネットワーク経由で、複合機開発元のホストコンピュータやアプリケーション開発元のサードベンダのホストコンピュータ等のリモートホストに送信する。

以下、ＲＯＭモニタ４１０によって、汎用レスキューＯＳ１３１が起動された場合の複合機１００の構成の一例を、図１０を用いて説明する。図１０は、複合機の構成を示すブロック図（その２）である。

図１０に示されるように、汎用レスキューＯＳ１３１が起動された場合は、ＳＲＭ１２３と、ＭＣＳ１２５と、ＳＣＳ１２２と、のレスキューモードスレッドが実行される。

ＳＣＳ１２２のレスキューモードスレッドは、後述するようにレスキュー方法の判定を行い、該判定結果に基づいて、ＭＣＳ１２５のレスキューモードスレッドを介してＨＤＤ１３０３等の二次記憶装置よりプログラムの更新に係る情報やデータを取得し、ＲＯＭ更新部４３０を起動する。

ＭＣＳ１２５のレスキューモードスレッドは、ＳＣＳ１２２のレスキューモードスレッドからの要求に基づいて、ＨＤＤ１３０３等の二次記憶装置よりプログラムの更新に係る情報やデータを取得し、ＳＣＳ１２２のレスキューモードスレッドに提供したり、ＲＯＭ更新部４３０からの要求に基づいて、更新される領域のデータをＨＤＤ１３０３等の二次記憶装置に蓄積したりする。

以下、ブート時のＯＳ切り替え処理を、図１１を用いて説明する。図１１は、ブート時のＯＳ切り替え処理を説明するためのフローチャートである。

複合機１００は、電源が投入されると、ステップＳ１０において、ＲＯＭモニタ４１０を起動する。

ステップＳ１０に続いてステップＳ１１に進み、ＲＯＭモニタ４１０は、更新中断情報に更新情報が格納されているかどうかを判定する。ＲＯＭモニタ４１０は、更新中断情報に更新情報が格納されていると判定すると（ステップＳ１１においてＹＥＳ）、ステップＳ１６に進み、更新中断情報に更新情報が格納されていないと判定すると（ステップＳ１１においてＮＯ）、ステップＳ１２に進む。

ステップＳ１２では、ＲＯＭモニタ４１０が、汎用ＯＳ１２１を起動する。

ステップＳ１２に続いてステップＳ１３に進み、ステップＳ１２において起動された汎用ＯＳ１２１は、プログラム起動部４２０を起動する。

ステップＳ１３に続いてステップＳ１４に進み、プログラム起動部４２０に含まれるサービス起動部４２２は、プラットフォーム１２０を起動する。

ステップＳ１４に続いてステップＳ１５に進み、プログラム起動部４２０に含まれるアプリ起動部４２３は、アプリケーション１３０を起動する。

一方、ステップＳ１６では、ＲＯＭモニタ４１０が、起動時情報にレスキューブートフラグを格納する。

ステップＳ１６に続いてステップＳ１７に進み、ＲＯＭモニタ４１０は、汎用レスキューＯＳ１３１を起動する。

ステップＳ１７に続いてステップＳ１８に進み、ステップＳ１７において起動された汎用レスキューＯＳ１３１は、プログラム起動部４２０を起動する。

ステップＳ１８に続いてステップＳ１９に進み、プログラム起動部４２０に含まれるサービス起動部４２２は、起動時情報を参照し、レスキューブートフラグが格納されていると、レスキューモードオプションを付加して、プラットフォーム１２０を起動する。

ステップＳ１９に続いてステップＳ２０に進み、ＳＣＳ１２２は、レスキューモードスレッドを起動する。

以下、図６のシーケンスＳＱ９において説明したＳＣＳ１２２のＲＯＭ更新モードスレッドによる更新データの選定処理の一例を、図１２を用いて説明する。図１２は、ＳＣＳのＲＯＭ更新モードスレッドで実行される更新データ選定処理を説明するためのフローチャート（その１）である。

ステップＳ３０において、ＳＣＳ１２２のＲＯＭ更新モードスレッドは、ＲＲＵアプリ１１７より通知された更新データパケットを展開した更新データ領域の先頭アドレスに基づいて、更新データの先頭のヘッダブロックをシークする。

ステップＳ３０に続いてステップＳ３１に進み、ＳＣＳ１２２のＲＯＭ更新モードスレッドは、ヘッダブロックからモジュールＩＤを取得する。

ステップＳ３１に続いてステップＳ３２に進み、ＳＣＳ１２２のＲＯＭ更新モードスレッドは、ステップＳ３１において取得したモジュールＩＤと、環境変数に設定されているプラットフォーム１２０又はアプリケーション１３０の起動情報に含まれるモジュールＩＤとを比較して、一致するかどうか判定する。

ＳＣＳ１２２のＲＯＭ更新モードスレッドは、ステップＳ３１において取得したモジュールＩＤが、環境変数に設定されているプラットフォーム１２０又はアプリケーション１３０の起動情報に含まれるモジュールＩＤと一致すると判定すると（ステップＳ３２においてＹＥＳ）、ステップＳ３３に進み、ステップＳ３１において取得したモジュールＩＤが、環境変数に設定されているプラットフォーム１２０又はアプリケーション１３０の起動情報に含まれるモジュールＩＤと一致しないと判定すると（ステップＳ３２においてＮＯ）、ステップＳ３５に進む。

ステップＳ３３では、ＳＣＳ１２２のＲＯＭ更新モードスレッドが、ヘッダブロックから、更新先アドレス、更新データオフセット、更新データサイズ等を取得する。

ステップＳ３３に続いてステップＳ３４に進み、ＳＣＳ１２２のＲＯＭ更新モードスレッドは、モジュールＩＤ、更新先アドレス、更新データオフセット、更新データサイズ等を一組とした更新情報を更新対象の変数等に設定する。

ステップＳ３５では、ＳＣＳ１２２のＲＯＭ更新モードスレッドが、更新データパケットを展開した更新データ領域を参照し、次のヘッダブロックが存在するかどうかを判定する。ＳＣＳ１２２のＲＯＭ更新モードスレッドは、次のヘッダブロックが存在すると判定すると（ステップＳ３５においてＹＥＳ）、ステップＳ３６に進み、次のヘッダブロックが存在しないと判定すると（ステップＳ３５においてＮＯ）、ステップＳ３７に進む。

ステップＳ３６では、ＳＣＳ１２２のＲＯＭ更新モードスレッドが、次のヘッダブロックをシークし、ステップＳ３１からの処理を繰り返す。

一方、ステップＳ３７では、ＳＣＳ１２２のＲＯＭ更新モードスレッドが、更新対象の変数等を参照し、更新情報が設定されているかどうかを判定する。ＳＣＳ１２２のＲＯＭ更新モードスレッドは、更新対象の変数等に更新情報が設定されていると判定すると（ステップＳ３７においてＹＥＳ）、ステップＳ３８に進み、更新対象の変数等に更新情報が設定されていないと判定すると（ステップＳ３７においてＮＯ）、処理を終了する。

ステップＳ３８では、ＳＣＳ１２２のＲＯＭ更新モードスレッドが、更新データパケットを展開した更新データ領域に格納されている対応する更新データを、ＨＤＤ１３０３等の二次記憶装置に蓄積する。

このように、更新データをＨＤＤ１３０３等の二次記憶装置に蓄積しておくことによって、例えプログラムの更新中に電源がＯＦＦされても、ＨＤＤ１３０３等の二次記憶装置に蓄積されている該更新データを用いて、プログラムの更新を再実行し、復旧することができる。

ステップＳ３８に続いて、ステップＳ３９に進み、ＳＣＳ１２２のＲＯＭ更新モードスレッドは、ＳＣＳ１２２のＲＯＭ更新部４３０を起動する。

以下、ＳＣＳ１２２のＲＯＭ更新部４３０によるＲＯＭ更新処理の一例を、図１３を用いて説明する。図１３は、ＳＣＳのＲＯＭ更新部によるＲＯＭ更新処理を説明するためのフローチャート（その１）である。

ステップＳ５０において、ＳＣＳ１２２のＲＯＭ更新部４３０は、モジュールＩＤ、更新先アドレス、更新データオフセット、更新データサイズ等の更新情報の１つを更新中断情報に格納する。なお、最初にステップＳ５０を実行する際は、ＳＣＳ１２２のＲＯＭ更新部４３０は、更新情報の１番目（例えば、ｎ＝０番目）を更新中断情報に格納し、後述するステップＳ５５等においてＹＥＳと判定し、ステップＳ５０の処理に来るたびに、ｎの値を１つインクリメントし、例えば次は２番目（ｎ＝１番目）の更新情報を更新中断情報に格納する。

ステップＳ５０に続いてステップＳ５１に進み、ＳＣＳ１２２のＲＯＭ更新部４３０は、更新データによって更新されるフラッシュＲＯＭ２０４の対応する領域のデータを、ＨＤＤ１３０３等の二次記憶装置に蓄積する。

このように、更新される領域のデータをＨＤＤ１３０３等の二次記憶装置に蓄積しておくことによって、例えプログラムの更新中に電源がＯＦＦされても、ＨＤＤ１３０３等の二次記憶装置に蓄積されている該更新される領域のデータを用いて、プログラムの更新を行う前の状態に復旧することができる。

ステップＳ５１に続いてステップＳ５２に進み、ＳＣＳ１２２のＲＯＭ更新部４３０は、更新データパケットを展開した更新データ領域から対応する更新データを読み出して、該更新データで、フラッシュＲＯＭ２０４の更新先アドレスから書き換えを行う。

ステップＳ５２に続いてステップＳ５３に進み、ＳＣＳ１２２のＲＯＭ更新部４３０は、ステップＳ５２において読み出した更新データと、ステップＳ５２において書き換えを行った後のフラッシュＲＯＭ２０４の更新したモジュールのデータと、を比較して、正しく書き換えが行われたかどうか判定する。ＳＣＳ１２２のＲＯＭ更新部４３０は、正しく書き換えが行われたと判定すると（ステップＳ５３においてＹＥＳ）、ステップＳ５５に進み、正しく書き換えが行われなかったと判定すると（ステップＳ５３においてＮＯ）、ステップＳ５４に進む。

ステップＳ５４では、ＳＣＳ１２２のＲＯＭ更新部４３０が、エラー処理を行う。例えば、ＳＣＳ１２２のＲＯＭ更新部４３０は、図１２において説明したように、ＳＣＳ１２２のＲＯＭ更新モードスレッドから呼ばれた場合は、ＯＣＳ１２６のＲＯＭ更新モードスレッドを介して、エラー画面をオペレーションパネル１３１０に表示する。また、ＳＣＳ１２２のＲＯＭ更新部４３０は、後述するように、ＳＣＳのレスキューモードスレッドから呼ばれた場合は、エラー情報をＨＤＤ１３０３等に格納されているログファイルに格納する。

一方、ステップＳ５５では、ＳＣＳ１２２のＲＯＭ更新部４３０が、更新対象の変数等を参照し、次の更新情報が設定されているかどうかを判定する。ＳＣＳ１２２のＲＯＭ更新部４３０は、更新対象の変数等に次の更新情報が設定されていると判定すると（ステップＳ５５においてＹＥＳ）、ステップＳ５０からの処理を繰り返し、更新対象の変数等に次の更新情報が設定されていないと判定すると（ステップＳ５５においてＮＯ）、ステップＳ５６に進む。

ステップＳ５６では、ＳＣＳ１２２のＲＯＭ更新部４３０が、更新中断情報に格納されている更新情報を削除する。

以下、図１１のステップＳ２０において起動されたＳＣＳ１２２のレスキューモードスレッドによる更新データの選定処理の一例を、図１４を用いて説明する。図１４は、ＳＣＳのレスキューモードスレッドで実行される更新データ選定処理を説明するためのフローチャート（その１）である。

ステップＳ６０において、ＳＣＳ１２２のレスキューモードスレッドは、例えばＨＤＤ１３０３等に格納されている複合機１００の定義ファイル等を参照して、予め設定されているレスキュー方法を選択する。ＳＣＳ１２２のレスキューモードスレッドは、レスキュー方法として、「中断された更新を再実行する」を選択すると、ステップＳ６３に進み、「更新を行う１つ前の状態に戻す」を選択すると、ステップＳ６１に進む。

ステップＳ６１では、ＳＣＳ１２２のレスキューモードスレッドが、図１３のステップＳ５１等において蓄積された、更新されるフラッシュＲＯＭ２０４の領域のデータをＨＤＤ１３０３等の二次記憶装置より取得する。

ステップＳ６１に続いてステップＳ６２に進み、ＳＣＳ１２２のレスキューモードスレッドは、図１３のステップＳ５０等において格納された更新情報を更新中断情報から取得する。

一方、ステップＳ６３では、ＳＣＳ１２２のレスキューモードスレッドが、図１２のステップＳ３８等において蓄積された更新データを、ＨＤＤ１３０３等の二次記憶装置より取得する。

ステップＳ６３に続いてステップＳ６４に進み、ＳＣＳ１２２のレスキューモードスレッドは、ステップＳ６３において取得した更新データの先頭のヘッダブロックをシークする。

ステップＳ６４に続いてステップＳ６５に進み、ＳＣＳ１２２のレスキューモードスレッドは、ヘッダブロックからモジュールＩＤを取得する。

ステップＳ６５に続いてステップＳ６６に進み、ＳＣＳ１２２のレスキューモードスレッドは、ステップＳ６５において取得したモジュールＩＤと、図１３のステップＳ５０等において格納された更新情報に含まれるモジュールＩＤと、が一致するかどうかを判定する。

ＳＣＳ１２２のレスキューモードスレッドは、ステップＳ６５において取得したモジュールＩＤと、図１３のステップＳ５０等において格納された更新情報に含まれるモジュールＩＤと、が一致すると判定すると（ステップＳ６６においてＹＥＳ）、ステップＳ６７に進み、ステップＳ６５において取得したモジュールＩＤと、図１３のステップＳ５０等において格納された更新情報に含まれるモジュールＩＤと、が一致しないと判定すると（ステップＳ６６においてＮＯ）、ステップＳ６９に進む。

ステップＳ６７では、ＳＣＳ１２２のレスキューモードスレッドが、ヘッダブロックから、更新先アドレス、更新データオフセット、更新データサイズ等を取得する。

ステップＳ６７に続いてステップＳ６８に進み、ＳＣＳ１２２のレスキューモードスレッドは、モジュールＩＤ、更新先アドレス、更新データオフセット、更新データサイズ等を一組とした更新情報を更新対象の変数等に設定する。

ステップＳ６９では、ＳＣＳ１２２のレスキューモードスレッドが、次のヘッダブロックが存在するかどうかを判定する。ＳＣＳ１２２のレスキューモードスレッドは、次のヘッダブロックが存在すると判定すると（ステップＳ６９においてＹＥＳ）、ステップＳ７０に進み、次のヘッダブロックが存在しないと判定すると（ステップＳ６９においてＮＯ）、ステップＳ７１に進む。

ステップＳ７０では、ＳＣＳ１２２のレスキューモードスレッドが、次のヘッダブロックをシークし、ステップＳ６５からの処理を繰り返す。

一方、ステップＳ７１では、ＳＣＳ１２２のレスキューモードスレッドが、更新対象の変数等を参照し、更新情報が設定されているかどうかを判定する。ＳＣＳ１２２のレスキューモードスレッドは、更新対象の変数等に更新情報が設定されていると判定すると（ステップＳ７１においてＹＥＳ）、ステップＳ７２に進み、更新対象の変数等に更新情報が設定されていないと判定すると（ステップＳ７１においてＮＯ）、処理を終了する。

ステップＳ７２では、ＳＣＳ１２２のレスキューモードスレッドが、ＳＣＳ１２２のＲＯＭ更新部４３０を起動する。

ＳＣＳ１２２のレスキューモードスレッドによって起動されたＳＣＳ１２２のＲＯＭ更新部４３０は、図１３に示したような処理を行い、フラッシュＲＯＭ２０４の更新を行う。

以下、複合機１００のメモリ構造の一例を、図１５を用いて説明する。図１５は、メモリ構造の一例を示すための図である。

図１５に示されるように、例えば、更新中断情報は、ＮＶＲＡＭ空間に含まれ、ＲＯＭ空間には、ＲＯＭモニタ４１０に対応するプログラムや、図１０に示したようなソフトウェア群１１０のプログラムに対応するレスキューシステムや、図３に示したようなプラットフォーム１２０のプログラムに対応する通常システムや、各アプリのプログラムに対応するアプリ１、アプリ２等が含まれている。

以下、図１５に示したように、更新中断情報をＮＶＲＡＭ空間に格納する場合の更新中断情報のレイアウトの一例を、図１６を用いて説明する。図１６は、更新中断情報をＮＶＲＡＭに格納する場合の更新中断情報のレイアウトを説明するための図（その１）である。

図１６に示されるように、更新中断情報は、例えば１６バイトのモジュールＩＤと、４バイトの更新先アドレスと、を含む。

以下、ＨＤＤ１３０３のディレクトリ及びファイル構成の一例を、図１７を用いて説明する。図１７は、ＨＤＤのディレクトリ及びファイル構成を説明するための図（その１）である。

図１７に示されるように、ＨＤＤ１３０３には、更新データ及び／又は更新される領域のデータを保持するディレクトリとしてｂａｃｋｕｐディレクトリを有し、該ｂａｃｋｕｐディレクトリには、更新データ及び／又は更新される領域のデータとしてｂａｃｋｕｐ．ｂｉｎファイルが格納されている。

以下、ＨＤＤ１３０３のディレクトリ及びファイル構成の他の例を、図１８を用いて説明する。図１８は、ＨＤＤのディレクトリ及びファイル構成を説明するための図（その２）である。

図１５及び図１６に示したように、更新中断情報をＮＶＲＡＭ２０８に格納するのではなく、図１８に示されるように更新中断情報を保持するディレクトリとして、ｒｏｍｕｐｄａｔｅディレクトリをＨＤＤ１３０３に設け、該ｒｏｍｕｐｄａｔｅディレクトリに、更新中断情報を含むファイルとして更新中断情報ファイルを格納するようにしてもよい。

以下、更新中断情報ファイルの内容の一例を、図１９を用いて説明する。図１９は、更新中断情報ファイルの内容の一例を説明するための図である。

図１９に示されるように、更新中断情報ファイルには、モジュールＩＤと、更新先アドレスと、が含まれている。

上述した実施例１では、例えば、図１３のステップＳ５２においてフラッシュＲＯＭ２０４の更新中に複合機１００の電源がＯＦＦされても、次回、複合機１００の電源がＯＮされれば、汎用レスキューＯＳ１３１が起動され、フラッシュＲＯＭ２０４の更新を再開するか又はフラッシュＲＯＭ２０４を更新前の状態に戻すことによって、プログラムを復旧させることができたが、複合機１００のオペレーションパネル１３１０に何ら表示されないため、ユーザは、汎用レスキューＯＳ１３１が起動され、プログラムの復旧（ＲＯＭのアップデート）が行われているのかどうか等知ることができない問題があった。

したがって、実施例２では、汎用レスキューＯＳ１３１が起動された場合も、オペレーションパネル１３１０にフラッシュＲＯＭ２０４の更新に係る画面等を表示して、上記問題を解決する。なお、以下では、実施例１とは異なる点について説明を行い、実施例１と同じ点は説明を省略する。

以下、ＲＯＭモニタ４１０によって、汎用レスキューＯＳ１３１が起動された場合の複合機１００の構成の他の例を、図２０を用いて説明する。図２０は、複合機の構成を示すブロック図（その３）である。

図２０に示される複合機１００の構成は、実施例１の図１０に示される複合機１００の構成と比べて、ＯＣＳ１２６のレスキューモードスレッドが含まれている。

ＯＣＳ１２６のレスキューモードスレッドは、オペレータと本体制御間の情報伝達手段となる操作パネル（オペレーションパネル１３１０）の制御を行い、例えば後述する画面等を、オペレーションパネル１３１０に表示する。

以下、実施例２におけるブート時のＯＳ切り替え処理の一例を、図２１を用いて説明する。図２１は、ブート時のＯＳ切り替え処理を説明するためのフローチャート（その２）である。

図２１のステップＳ１００からステップＳ１０９までの処理は、図１１のステップＳ１０からステップＳ１９までの処理と同様である。

ステップＳ１０９に続いてステップＳ１１０に進み、ＯＣＳ１２６のレスキューモードスレッドは、起動時画面をオペレーションパネル１３１０に表示する（図２２参照。）。

図２２に示されるように、起動時の画面をオペレーションパネル１３１０に表示することによって、例えば、ユーザにレスキューモードで起動されていることを知らせることができる。

ステップＳ１１０に続いてステップＳ１１１に進み、ＳＣＳ１２２は、レスキューモードスレッドを起動する。

ＳＣＳ１２２のレスキューモードスレッドは、図１４に示したような処理を行い、ＳＣＳ１２２のＲＯＭ更新部４３０を起動する。

以下、ＳＣＳ１２２のＲＯＭ更新部４３０によるＲＯＭ更新処理の他の例を、図２３を用いて説明する。図２３は、ＳＣＳのＲＯＭ更新部によるＲＯＭ更新処理を説明するためのフローチャート（その２）である。

ステップＳ１２０において、ＳＣＳ１２２のＲＯＭ更新部４３０は、モジュールＩＤ、更新先アドレス、更新データオフセット、更新データサイズ等の更新情報を更新中断情報に格納する。

ステップＳ１２０に続いてステップＳ１２１に進み、ＳＣＳ１２２のＲＯＭ更新部４３０は、更新データによって更新されるフラッシュＲＯＭ２０４の対応する領域のデータを、ＨＤＤ１３０３等の二次記憶装置に蓄積する。

このように、更新される領域のデータをＨＤＤ１３０３等の二次記憶装置に蓄積しておくことによって、例えプログラムの更新中に電源がＯＦＦされても、ＨＤＤ１３０３等の二次記憶装置に蓄積されている該更新される領域のデータを用いて、フラッシュＲＯＭ２０４を、プログラムの更新を行う前の状態に復旧することができる。

ステップＳ１２１に続いてステップＳ１２２に進み、ＳＣＳ１２２のＲＯＭ更新部４３０は、更新データパケットを展開した更新データ領域から対応する更新データを読み出して、該更新データで、フラッシュＲＯＭ２０４の更新先アドレスから書き換えを行う。

ステップＳ１２２に続いてステップＳ１２３に進み、ＳＣＳ１２２のＲＯＭ更新部４３０は、ＯＣＳ１２６のレスキューモードスレッドが起動されているかどうかを判定する。

ＳＣＳ１２２のＲＯＭ更新部４３０は、ＯＣＳ１２６のレスキューモードスレッドが起動されていると判定すると（ステップＳ１２３においてＹＥＳ）、ステップＳ１２４に進み、ＯＣＳ１２６のレスキューモードスレッドが起動されていないと判定すると（ステップＳ１２３においてＮＯ）、ステップＳ１２５に進む。

ＳＣＳ１２２のＲＯＭ更新部４３０は、例えば、環境変数等を参照し、ＯＣＳ１２６のレスキューモードスレッドが起動されているかどうかを判定する。

ステップＳ１２４では、ＳＣＳ１２２のＲＯＭ更新部４３０が、ＯＣＳ１２６のレスキューモードスレッドを介して、オペレーションパネル１３１０に復旧中画面を表示する（図２４参照。）。

図２４に示されるように、フラッシュＲＯＭ２０４の復旧中の画面をオペレーションパネル１３１０に表示することによって、ユーザに、ＲＯＭをアップデートしている旨及びＲＯＭをアップデートしているため、電源を切らないで欲しい旨等、通知することができる。

ステップＳ１２５では、ＳＣＳ１２２のＲＯＭ更新部４３０が、ステップＳ１２２において読み出した更新データと、ステップＳ１２２において書き換えを行った後のフラッシュＲＯＭ２０４の更新したモジュールのデータと、を比較して、正しく書き換えが行われたかどうか判定する。ＳＣＳ１２２のＲＯＭ更新部４３０は、正しく書き換えが行われたと判定すると（ステップＳ１２５においてＹＥＳ）、ステップＳ１２８に進み、正しく書き換えが行われなかったと判定すると（ステップＳ１２５においてＮＯ）、ステップＳ１２６に進む。

ステップＳ１２６では、ＳＣＳ１２２のＲＯＭ更新部４３０が、ＯＣＳ１２６のレスキューモードスレッドが起動されているかどうかを判定する。

ＳＣＳ１２２のＲＯＭ更新部４３０は、ＯＣＳ１２６のレスキューモードスレッドが起動されていると判定すると（ステップＳ１２６においてＹＥＳ）、ステップＳ１２７に進み、ＯＣＳ１２６のレスキューモードスレッドが起動されていないと判定すると（ステップＳ１２６においてＮＯ）、処理を終了する。

ステップＳ１２７では、ＳＣＳ１２２のＲＯＭ更新部４３０が、ＯＣＳ１２６のレスキューモードスレッドを介して、オペレーションパネル１３１０にエラー画面を表示する（図２５参照。）。

図２５に示されるように、エラー時の画面をオペレーションパネル１３１０に表示することによって、ユーザにＲＯＭのアップデート中にエラーが生じたので、サービスセンターに連絡する必要がある旨等、通知することができる。

一方、ステップＳ１２８では、ＳＣＳ１２２のＲＯＭ更新部４３０が、更新対象の変数等を参照し、次の更新情報が設定されているかどうかを判定する。ＳＣＳ１２２のＲＯＭ更新部４３０は、更新対象の変数等に次の更新情報が設定されていると判定すると（ステップＳ１２８においてＹＥＳ）、ステップＳ１２０からの処理を繰り返し、更新対象の変数等に次の更新情報が設定されていないと判定すると（ステップＳ１２８においてＮＯ）、ステップＳ１２９に進む。

ステップＳ１２９では、ＳＣＳ１２２のＲＯＭ更新部４３０が、更新中断情報に格納されている更新情報を削除する。

上述した実施例１及び実施例２では、フラッシュＲＯＭ２０４の更新が中断された場合の復旧方法等について説明を行ったが、以下の実施例では、フラッシュＲＯＭ２０４の更新後、更新を行ったプログラムと、更新を行わなかったプログラムと、の組み合わせ等が原因で複合機１００の機能の一部又は全てが使用不可能又は動作が不安定となった場合の復旧方法等について説明を行う。なお、以下では、実施例１及び実施例２と異なる点について説明を行い、実施例１及び実施例２と同じ点は説明を省略する。

以下、ＲＯＭモニタ４１０によって、汎用レスキューＯＳ１３１が起動された場合の複合機１００の構成の他の例を、図２６を用いて説明する。図２６は、複合機の構成を示すブロック図（その４）である。

図２６に示される複合機１００の構成は、実施例２の図２０に示される複合機１００の構成と比べてＮＣＳ１２８のレスキューモードスレッドと、ＲＲＵアプリ１１７と、が含まれている。

ＮＣＳ１２８のレスキューモードスレッドは、ネットワークに接続された、例えば複合機開発元のホストコンピュータやアプリケーション開発元のサードベンダ等から、フラッシュＲＯＭ２０４のＲＯＭ更新データパケットを受信する。

また、ＲＲＵアプリ１７は、上述したように、ＮＣＳ１２８によりネットワーク経由で受信した更新データパケットを更新データに展開し、その更新データをＭＣＳ１２５のレスキューモードスレッドによって確保されたＳＤＲＡＭ２０３等の更新データ領域に格納する処理等を行う。

以下、実施例３におけるブート時のＯＳ切り替え処理の一例を、図２７を用いて説明する。図２７は、ブート時のＯＳ切り替え処理を説明するためのフローチャート（その３）である。

複合機１００は、電源が投入されると、ステップＳ２００において、ＲＯＭモニタ４１０を起動する。

ステップＳ２００に続いてステップＳ２０１に進み、ＲＯＭモニタ４１０は、更新中断情報にメンテナンスフラグが格納されているかどうかを判定する。ＲＯＭモニタ４１０は、更新中断情報にメンテナンスフラグが格納されていると判定すると（ステップＳ２０１においてＹＥＳ）、ステップＳ２１０に進み、更新中断情報にメンテナンスフラグが格納されていないと判定すると（ステップＳ２０１においてＮＯ）、ステップＳ２０２に進む。

ステップＳ２０２では、ＲＯＭモニタ４１０が、汎用ＯＳ１２１を起動する。

ステップＳ２０２に続いてステップＳ２０３に進み、ＲＯＭモニタ４１０は、ステップＳ２０２において起動された汎用ＯＳ１２１が正常に起動したかどうかを判定する。ＲＯＭモニタ４１０は、汎用ＯＳ１２１が正常に起動したと判定すると（ステップＳ２０３においてＹＥＳ）、ステップＳ２０４に進み、汎用ＯＳ１２１が正常に起動しなかったと判定すると（ステップＳ２０３においてＮＯ）、ステップＳ２０８に進む。

ステップＳ２０４では、汎用ＯＳ１２１がプログラム起動部４２０を起動する。

ステップＳ２０４に続いてステップＳ２０５に進み、プログラム起動部４２０に含まれるサービス起動部４２２は、プラットフォーム１２０を起動する。

ステップＳ２０５に続いてステップＳ２０６に進み、プログラム起動部４２０に含まれるアプリ起動部４２３は、アプリケーション１３０を起動する。

ステップＳ２０６に続いてステップＳ２０７に進み、プログラム起動部４２０は、ステップＳ２０５及びステップＳ２０６において起動したプラットフォーム１２０及びアプリケーション１３０の起動すべき全てのプログラムが正常起動したかどうかを判定する。プログラム起動部４２０は、ステップＳ２０５及びステップＳ２０６において起動したプラットフォーム１２０及びアプリケーション１３０の起動すべき全てのプログラムが正常起動したと判定すると（ステップＳ２０７においてＹＥＳ）、処理を終了し、ステップＳ２０５及びステップＳ２０６において起動したプラットフォーム１２０及びアプリケーション１３０の起動すべき全てのプログラムが正常起動しなかったと判定すると（ステップＳ２０７においてＮＯ）、ステップＳ２０８に進む。

ステップＳ２０８では、ＲＯＭモニタ４１０又はプログラム起動部４２０が、メンテナンスフラグを更新中断情報に格納する。

ステップＳ２０８に続いてステップＳ２０９に進み、ＲＯＭモニタ４１０又はプログラム起動部４２０は、複合機１００をリブートする。

一方、ステップＳ２１０では、ＲＯＭモニタ４１０が、起動時情報にレスキューブートフラグを格納する。

ステップＳ２１０に続いてステップＳ２１１に進み、ＲＯＭモニタ４１０は、汎用レスキューＯＳ１３１を起動する。

ステップＳ２１１に続いてステップＳ２１２に進み、ステップＳ２１１において起動された汎用レスキューＯＳ１３１は、プログラム起動部４２０を起動する。

ステップＳ２１２に続いてステップＳ２１３に進み、プログラム起動部４２０に含まれるサービス起動部４２２は、起動時情報を参照し、レスキューブートフラグが格納されていると、レスキューモードオプションを付加して、プラットフォーム１２０を起動する。

ステップＳ２１３に続いてステップＳ２１４に進み、ＯＣＳ１２６のレスキューモードスレッドは、後述する図２８に示される復旧メニュー画面をオペレーションパネル１３１０に表示する。なお、以下では、後述する図２８（Ａ）の画面において、ユーザに「行う」を選択されたものとして説明を行う。

ステップＳ２１４に続いてステップＳ２１５に進み、ＯＣＳ１２６のレスキューモードスレッドは、後述する図２８（Ｂ）の画面において選択された復旧内容（復旧方法）に従いメンテナンス内容フラグを更新中断情報に格納する。

ステップＳ２１５に続いてステップＳ２１６に進み、ＳＣＳ１２２は、後述する図２９に示すようなメンテナンス内容フラグチェック処理を行う。

以下、復旧メニュー画面の一例を、図２８を用いて説明する。図２８は、復旧メニュー画面を示すための図（その１）である。

図２８（Ａ）に示されるように、ＯＣＳ１２６のレスキューモードスレッドは、初めに、復旧作業を行うかどうかの選択画面をオペレーションパネル１３１０に表示する。ＯＣＳ１２６のレスキューモードスレッドは、ユーザが「行う」を選択したと判定すると、図２８（Ｂ）に示されるような復旧内容の選択画面をオペレーションパネル１３１０に表示し、ユーザが「行わない」を選択したと判定すると、図２８（Ｃ）に示されるような復旧作業を中止する旨を表す画面をオペレーションパネル１３１０に表示する。

以下、ＳＣＳ１２２によるメンテナンス内容フラグチェック処理の一例を、図２９を用いて説明する。図２９は、ＳＣＳによるメンテナンス内容フラグチェック処理を説明するためのフローチャート（その１）である。

ステップＳ２２０において、ＳＣＳ１２２は、図２７のステップＳ２１５において更新中断情報に格納されたメンテナンス内容フラグをチェックする。ＳＣＳ１２２は、メンテナンス内容フラグをチェックして、図２８の画面（Ｂ）においてユーザが復旧内容として「リモートホストより更新データパケットを送信する。」を選択したと判定すると、ステップＳ２２２に進み、図２８の画面（Ｂ）においてユーザが復旧内容として「機器に蓄積されているソフトウェアに戻す。」を選択したと判定すると、ステップＳ２２１に進む。

ステップＳ２２１では、ＳＣＳ１２２が、ＳＣＳ１２２のレスキューモードスレッドを起動する。

一方、ステップＳ２２２では、ＳＣＳ１２２が、ＲＲＵアプリ１１７より更新データの選定依頼を受け取ったかどうかを判定する。ＳＣＳ１２２は、ＲＲＵアプリ１１７より更新データの選定依頼を受け取ったと判定すると（ステップＳ２２２においてＹＥＳ）、ステップＳ２２３に進み、ＲＲＵアプリ１１７より更新データの選定依頼を受け取っていないと判定すると（ステップＳ２２２においてＮＯ）、ステップＳ２２２の処理を繰り返す。

ステップＳ２２３では、ＳＣＳ１２２が、ＳＣＳ１２２のＲＯＭ更新モードスレッドを起動する。

なお、図２９において説明を省略したが、ステップＳ２２０においてＳＣＳ１２２が図２８の画面（Ｂ）においてユーザが復旧内容として「リモートホストより更新データパケットを送信する。」を選択したと判定した場合、ＯＣＳ１２６のレスキューモードスレッドは、オペレーションパネル１３１０に受信待機中画面を表示するようにしてもよい（図３０参照。）。

以下、図２９のステップＳ２２１において起動されたＳＣＳ１２２のレスキューモードスレッドで実行される更新データ選定処理の一例を、図３１を用いて説明する。図３１は、ＳＣＳのレスキューモードスレッドで実行される更新データ選定処理を説明するためのフローチャート（その２）である。

ステップＳ２３０においてＳＣＳ１２２のレスキューモードスレッドは、ＨＤＤ１３０３等より正常動作する出荷時のプログラムを取得する。

ステップＳ２３０に続いてステップＳ２３１に進み、ＳＣＳ１２２のレスキューモードスレッドは、ＨＤＤ１３０３等より正常動作する出荷時のプログラムのモジュールＩＤや、更新先アドレス、更新データサイズ等のモジュール情報を取得する。

ステップＳ２３１に続いてステップＳ２３２に進み、ＳＣＳ１２２のレスキューモードスレッドは、ＳＣＳ１２２のＲＯＭ更新部４３０を起動する。

図３１に示したように、出荷時のプログラムを取得し、ＳＣＳ１２２のＲＯＭ更新部４３０を起動して、フラッシュＲＯＭ２０４を更新することによって、プログラムを正常に動作していた出荷時の状態に戻すことができる。

以下、図２９のステップＳ２２３において起動されたＳＣＳ１２２のＲＯＭ更新モードスレッドで実行される更新データ選定処理の一例を、図３２を用いて説明する。図３２は、ＳＣＳのＲＯＭ更新モードスレッドで実行される更新データ選定処理を説明するためのフローチャート（その２）である。

ステップＳ２４０において、ＳＣＳ１２２のＲＯＭ更新モードスレッドは、ＲＲＵアプリ１１７より通知された更新データパケットを展開した更新データ領域の先頭アドレスに基づいて、更新データの先頭のヘッダブロックをシークする。

ステップＳ２４０に続いてステップＳ２４１に進み、ＳＣＳ１２２のＲＯＭ更新モードスレッドは、ヘッダブロックからモジュールＩＤを取得する。

ステップＳ２４１に続いてステップＳ２４２に進み、ＳＣＳ１２２のＲＯＭ更新モードスレッドは、ヘッダブロックから、更新先アドレス、更新データオフセット、更新データサイズ等を取得する。

ステップＳ２４２に続いてステップＳ２４３に進み、ＳＣＳ１２２のＲＯＭ更新モードスレッドは、モジュールＩＤ、更新先アドレス、更新データオフセット、更新データサイズ等を一組とした更新情報を更新対象の変数等に設定する。

ステップＳ２４３に続いてステップＳ２４４に進み、ＳＣＳ１２２のＲＯＭ更新モードスレッドは、次のヘッダブロックが存在するかどうかを判定する。ＳＣＳ１２２のＲＯＭ更新モードスレッドは、次のヘッダブロックが存在すると判定すると（ステップＳ２４４においてＹＥＳ）、ステップＳ２４５に進み、次のヘッダブロックが存在しないと判定すると（ステップＳ２４４においてＮＯ）、ステップＳ２４６に進む。

ステップＳ２４５では、ＳＣＳ１２２のＲＯＭ更新モードスレッドが、次のヘッダブロックをシークし、ステップＳ２４１からの処理を繰り返す。

ステップＳ２４６では、ＳＣＳ１２２のＲＯＭ更新モードスレッドが、更新対象の変数等を参照し、更新情報が設定されているかどうかを判定する。ＳＣＳ１２２のＲＯＭ更新モードスレッドは、更新対象の変数等に更新情報が設定されていると判定すると（ステップＳ２４６においてＹＥＳ）、ステップＳ２４７に進み、更新対象の変数等に更新情報が設定されていないと判定すると（ステップＳ２４６においてＮＯ）、処理を終了する。

ステップＳ２４７では、ＳＣＳ１２２のＲＯＭ更新モードスレッドが、更新データパケットを展開した更新データ領域に格納されている対応する更新データを、ＨＤＤ１３０３等の二次記憶装置に蓄積する。

ステップＳ２４７に続いてステップＳ２４８に進み、ＳＣＳ１２２のＲＯＭ更新モードスレッドは、ＳＣＳ１２２のＲＯＭ更新部４３０を起動する。

図２９及び図３２に示したように、リモートホストより更新データを取得して、ＳＣＳ１２２のＲＯＭ更新モードスレッド及びＳＣＳ１２２のＲＯＭ更新部４３０を起動して、フラッシュＲＯＭ２０４を更新することによって、プログラムを修正することができる。

以下、ＳＣＳ１２２のＲＯＭ更新部４３０によるＲＯＭ更新処理の他の例を、図３３を用いて説明する。図３３は、ＳＣＳのＲＯＭ更新部によるＲＯＭ更新処理を説明するためのフローチャート（その３）である。

ステップＳ２５０において、ＳＣＳ１２２のＲＯＭ更新部４３０は、モジュールＩＤ、更新先アドレス、更新データオフセット、更新データサイズ等の更新情報を更新中断情報に格納する。

ステップＳ２５０に続いてステップＳ２５１に進み、ＳＣＳ１２２のＲＯＭ更新部４３０は、更新データによって更新されるフラッシュＲＯＭ２０４の対応する領域のデータを、ＨＤＤ１３０３等の二次記憶装置に蓄積する。

ステップＳ２５１に続いてステップＳ２５２に進み、ＳＣＳ１２２のＲＯＭ更新部４３０は、更新データパケットを展開した更新データ領域から対応する更新データを読み出して、該更新データで、フラッシュＲＯＭ２０４の更新先アドレスから書き換えを行う。

ステップＳ２５２に続いてステップＳ２５３に進み、ＳＣＳ１２２のＲＯＭ更新部４３０は、ＯＣＳ１２６のレスキューモードスレッドを介して、オペレーションパネル１３１０に復旧中画面を表示する（図２４参照。）。

ステップＳ２５３に続いてステップＳ２５４に進み、ＳＣＳ１２２のＲＯＭ更新部４３０は、ステップＳ２５２において読み出した更新データと、ステップＳ２５２において書き換えを行った後のフラッシュＲＯＭ２０４の更新したモジュールのデータと、を比較して、正しく書き換えが行われたかどうか判定する。ＳＣＳ１２２のＲＯＭ更新部４３０は、正しく書き換えが行われたと判定すると（ステップＳ２５４においてＹＥＳ）、ステップＳ２５６に進み、正しく書き換えが行われなかったと判定すると（ステップＳ２５４においてＮＯ）、ステップＳ２５５に進む。

ステップＳ２５５では、ＳＣＳ１２２のＲＯＭ更新部４３０が、ＯＣＳ１２６のレスキューモードスレッドを介して、オペレーションパネル１３１０にエラー画面を表示する（図２５参照。）。

一方、ステップＳ２５６では、ＳＣＳ１２２のＲＯＭ更新部４３０が、更新対象の変数等を参照し、次の更新情報が設定されているかどうかを判定する。ＳＣＳ１２２のＲＯＭ更新部４３０は、更新対象の変数等に次の更新情報が設定されていると判定すると（ステップＳ２５６においてＹＥＳ）、ステップＳ２５０からの処理を繰り返し、更新対象の変数等に次の更新情報が設定されていないと判定すると（ステップＳ２５６においてＮＯ）、ステップＳ２５７に進む。

ステップＳ２５７では、ＳＣＳ１２２のＲＯＭ更新部４３０が、更新中断情報に格納されている更新情報を削除する。

なお、ＳＣＳ１２２のＲＯＭ更新部４３０は、実施例２の図２３に示したようにＯＣＳ１２６のレスキューモードスレッドが起動されているかどうかを判定する処理を行い、ＯＣＳ１２６のレスキューモードスレッドが起動されていたら、ステップＳ２５３やステップＳ２５５の処理を行うようにしてもよい。図３３では説明の簡略化のため、ＯＣＳ１２６のレスキューモードスレッドが起動されているものとして説明を行っている。

以下、複合機１００が正常起動した後から、正常に動作していないアプリケーション１３０等が存在して、レスキューモードに移行する場合の処理の一例を、図３４を用いて説明する。図３４は、正常起動後からのレスキューモード移行処理を説明するためのフローチャート（その１）である。

ステップＳ２６０において、ＯＣＳ１２６の通常モードスレッドは、オペレーションパネル１３１０に表示している画面（図３５参照）のレスキューボタンが押下されたかどうかを判定する。ＯＣＳ１２６の通常モードスレッドは、オペレーションパネル１３１０に表示している画面のレスキューボタンが押下されたと判定すると（ステップＳ２６０においてＹＥＳ）、ステップＳ２６１に進み、レスキューボタンが押下されていないと判定すると（ステップＳ２６０においてＮＯ）、ステップＳ２６０の処理を繰り返す。

ステップＳ２６１では、ＯＣＳ１２６の通常モードスレッドが、レスキューモード移行の確認画面をオペレーションパネル１３１０に表示する（図３６参照。）。

ステップＳ２６１に続いてステップＳ２６２に進み、ＯＣＳ１２６の通常モードスレッドは、図３６のレスキューモード移行確認画面の実行ボタンが押下されたかどうかを判定する。ＯＣＳ１２６の通常モードスレッドは、図３６のレスキューモード移行確認画面の実行ボタンが押下されたと判定すると（ステップＳ２６２においてＹＥＳ）、ステップＳ２６３に進み、中止ボタンが押下さたと判定すると（ステップＳ２６２においてＮＯ）、図３５に示した画面をオペレーションパネル１３１０に表示し、ステップＳ２６０からの処理を繰り返す。

ステップＳ２６３では、ＯＣＳ１２６の通常モードスレッドより、レスキューモード移行確認画面の実行ボタンが押下された旨を通知された、例えばＳＣＳ１２２の通常モードスレッドが、メンテナンスフラグを更新中断情報に格納する。

ステップＳ２６３に続いてステップＳ２６４に進み、例えばＳＣＳ１２２の通常モードスレッドより通知を受けたＲＯＭモニタ４１０又はプログラム起動部４２０は、複合機１００をリブートする。

図３４に示す処理によってリブートされた複合機１００は、図２７に示したような処理を行う。

以下、更新中断情報をＮＶＲＡＭ空間に格納する場合の更新中断情報のレイアウトの他の例を、図３７を用いて説明する。図３７は、更新中断情報をＮＶＲＡＭに格納する場合の更新中断情報のレイアウトを説明するための図（その２）である。

図３７に示されるように、更新中断情報は、例えば１６バイトのモジュールＩＤと、４バイトの更新先アドレスと、１バイトのメンテナンスフラグと、１バイトのメンテナンス内容フラグと、を含む。

なお、図１８及び図１９に示したように、更新中断情報をＨＤＤ１３０３に格納する場合、メンテナンスフラグやメンテナンス内容フラグを、例えば更新中断情報ファイルに含めるようにしてもよい。

以下、ＨＤＤ１３０３のディレクトリ及びファイル構成の他の例を、図３８を用いて説明する。図３８は、ＨＤＤのディレクトリ及びファイル構成を説明するための図（その３）である。

図３８に示されるように、ＨＤＤ１３０３には、正常動作する出荷時のデータ（プログラム）を保持するディレクトリとしてｓｔｏｒｅディレクトリを有し、該ｓｔｏｒｅディレクトリには、アプリケーション１３０やプラットフォーム１２０等を構成する各モジュールに対応する、正常動作する出荷時のデータ（プログラム）と、前記モジュールに係るモジュール情報ファイルと、が格納されている。

以下、モジュール情報ファイルの一例として、正常動作する出荷時のプリンタアプリのモジュール情報ファイルの内容の一例を、図３９を用いて説明する。図３９は、正常動作する出荷時のプリンタアプリのモジュール情報ファイルの内容の一例を説明するための図である。

図３９に示されるように、モジュール情報ファイルには、モジュールＩＤと、更新先アドレスと、モジュールのサイズと、が含まれる。

なお、図２８（Ｂ）において、「機器に蓄積されているソフトウェアに戻す。」のみを表示又は選択可能とした場合は、図２６に示した複合機１００の構成において、ＮＣＳ１２８のレスキューモードスレッドや、ＲＲＵアプリ１１７は、含まれなくてもよい。

上述した実施例３では、図３３に示したように、ＳＣＳ１２２のＲＯＭ更新部４３０が、復旧情報を、ＯＣＳ１２６のレスキューモードスレッドを介して、オペレーションパネル１３１０に、復旧中画面として表示した。しかしながら、復旧情報を、オペレーションパネル１３１０に表示すると共に、ＳＣＳ１２２のＲＯＭ更新部４３０が、復旧情報を、ＮＣＳ１２８のレスキューモードスレッドを介して、リモートホストに送信するようにしてもよい。

以下、ＳＣＳ１２２のＲＯＭ更新部４３０によるＲＯＭ更新処理の他の例を、図４０を用いて説明する。図４０は、ＳＣＳのＲＯＭ更新部によるＲＯＭ更新処理を説明するためのフローチャート（その４）である。

ステップＳ３００において、ＳＣＳ１２２のＲＯＭ更新部４３０は、モジュールＩＤ、更新先アドレス、更新データオフセット、更新データサイズ等の更新情報を更新中断情報に格納する。

ステップＳ３００に続いてステップＳ３０１に進み、ＳＣＳ１２２のＲＯＭ更新部４３０は、更新データによって更新されるフラッシュＲＯＭ２０４の対応する領域のデータを、ＨＤＤ１３０３等の二次記憶装置に蓄積する。

ステップＳ３０１に続いてステップＳ３０２に進み、ＳＣＳ１２２のＲＯＭ更新部４３０は、更新データパケットを展開した更新データ領域から対応する更新データを読み出して、該更新データで、フラッシュＲＯＭ２０４の更新先アドレスから書き換えを行う。

ステップＳ３０２に続いてステップＳ３０３に進み、ＳＣＳ１２２のＲＯＭ更新部４３０は、ＯＣＳ１２６のレスキューモードスレッドを介して、オペレーションパネル１３１０に復旧中画面を表示する（図２４参照。）。

ステップＳ３０３に続いてステップＳ３０４に進み、ＳＣＳ１２２のＲＯＭ更新部４３０は、ＮＣＳ１２８のレスキューモードスレッドが起動されているかどうかを判定する。

ＳＣＳ１２２のＲＯＭ更新部４３０は、ＮＣＳ１２８のレスキューモードスレッドが起動されていると判定すると（ステップＳ３０４においてＹＥＳ）、ステップＳ３０５に進み、ＮＣＳ１２８のレスキューモードスレッドが起動されていないと判定すると（ステップＳ３０４においてＮＯ）、ステップＳ３０６に進む。

ＳＣＳ１２２のＲＯＭ更新部４３０は、例えば、環境変数等を参照し、ＮＣＳ１２８のレスキューモードスレッドが起動されているかどうかを判定する。

ステップＳ３０５では、ＳＣＳ１２２のＲＯＭ更新部４３０が、ＮＣＳ１２８のレスキューモードスレッドを介して、リモートホストに復旧情報を送信する。

ステップＳ３０６では、ＳＣＳ１２２のＲＯＭ更新部４３０が、ステップＳ３０２において読み出した更新データと、ステップＳ３０２において書き換えを行った後のフラッシュＲＯＭ２０４の更新したモジュールのデータと、を比較して、正しく書き換えが行われたかどうか判定する。ＳＣＳ１２２のＲＯＭ更新部４３０は、正しく書き換えが行われたと判定すると（ステップＳ３０６においてＹＥＳ）、ステップＳ３０８に進み、正しく書き換えが行われなかったと判定すると（ステップＳ３０６においてＮＯ）、ステップＳ３０７に進む。

ステップＳ３０７では、ＳＣＳ１２２のＲＯＭ更新部４３０が、ＯＣＳ１２６のレスキューモードスレッドを介して、オペレーションパネル１３１０にエラー画面を表示する（図２５参照。）。

一方、ステップＳ３０８では、ＳＣＳ１２２のＲＯＭ更新部４３０が、更新対象の変数等を参照し、次の更新情報が設定されているかどうかを判定する。ＳＣＳ１２２のＲＯＭ更新部４３０は、更新対象の変数等に次の更新情報が設定されていると判定すると（ステップＳ３０８においてＹＥＳ）、ステップＳ３００からの処理を繰り返し、更新対象の変数等に次の更新情報が設定されていないと判定すると（ステップＳ３０８においてＮＯ）、ステップＳ３０９に進む。

ステップＳ３０９では、ＳＣＳ１２２のＲＯＭ更新部４３０が、更新中断情報に格納されている更新情報を削除する。

なお、ＳＣＳ１２２のＲＯＭ更新部４３０は、実施例２の図２３に示したようにＯＣＳ１２６のレスキューモードスレッドが起動されているかどうかを判定する処理を行い、ＯＣＳ１２６のレスキューモードスレッドが起動されていたら、ステップＳ３０３やステップＳ３０７の処理を行うようにしてもよい。図４０では説明の簡略化のため、ＯＣＳ１２６のレスキューモードスレッドが起動されているものとして説明を行っている。

以下、実施例３の図２９に示したＳＣＳ１２２によるメンテナンス内容フラグチェック処理の他の例を、図４１を用いて説明する。図４１は、ＳＣＳによるメンテナンス内容フラグチェック処理を説明するためのフローチャート（その２）である。なお、以下では、上述した実施例とは異なる点について説明を行い、上述した実施例と同じ点は説明を省略する。

ステップＳ３１０において、ＳＣＳ１２２は、実施例３の図２７のステップＳ２１５等において更新中断情報に格納されたメンテナンス内容フラグをチェックする。ＳＣＳ１２２は、メンテナンス内容フラグをチェックして、実施例３の図２８の画面（Ｂ）等においてユーザが復旧内容として「リモートホストより更新データパケットを送信する。」を選択したと判定すると、ステップＳ３１２に進み、図２８の画面（Ｂ）等においてユーザが復旧内容として「機器に蓄積されているソフトウェアに戻す。」を選択したと判定すると、ステップＳ３１１に進む。

ステップＳ３１１では、ＳＣＳ１２２が、ＳＣＳ１２２のレスキューモードスレッドを起動する。

一方、ステップＳ３１２では、ＳＣＳ１２２が、予め定められたタイムアウト時間（例えば、４秒）が超過したか否かを判定する。ＳＣＳ１２２は、予め定められたタイムアウト時間を超過したと判定すると（ステップＳ３１２においてＹＥＳ）、ステップＳ３１１に進み、予め定められたタイムアウト時間を超過していないと判定すると（ステップＳ３１２においてＮＯ）、ステップＳ３１３に進む。なお、ステップＳ３１２において、ＳＣＳ１２２が、予め定められたタイムアウト時間を超過したと判定すると、ＯＣＳ１２６のレスキューモードスレッドは、オペレーションパネル１３１０に強制復旧移行画面を表示し（図４２参照）、ステップＳ３１１に進むようにしてもよい。

ステップＳ３１３では、ＳＣＳ１２２が、ＲＲＵアプリ１１７より更新データの選定依頼を受け取ったか否かを判定する。ＳＣＳ１２２は、ＲＲＵアプリ１１７より更新データの選定依頼を受け取ったと判定すると（ステップＳ３１３においてＹＥＳ）、ステップＳ３１４に進み、ＲＲＵアプリ１１７より更新データの選定依頼を受け取っていないと判定すると（ステップＳ３１３においてＮＯ）、ステップＳ３１２からの処理を繰り返す。

ステップＳ３１４では、ＳＣＳ１２２が、ＳＣＳ１２２のＲＯＭ更新モードスレッドを起動する。

以下、強制復旧移行画面の一例を、図４２に示す。図４２は、強制復旧移行画面の一例を示す図である。

図４２に示されるように、強制復旧移行画面には、更新データパケットの受信待機タイムアウトを起こしたため、機器（複合機１００）に蓄積されているソフトウェア（又はプログラム）に戻す旨の情報が表示されている。

実施例５に示したような処理、及び／又は後述する実施例に示す処理を行うことによって、リモートホストからの更新データパケット受信の待機状態がタイムアウトしたときに、全プログラム又はユーザに選択されたプログラムを出荷時、又は過去バーションのプログラムに戻すことができる。

以下、複合機１００が正常起動した後から、正常に動作していないアプリケーション１３０等が存在して、レスキューモードに移行する場合の処理の他の例を、図４３を用いて説明する。図４３は、正常起動後からのレスキューモード移行処理を説明するためのフローチャート（その２）である。なお、以下では、上述した実施例とは異なる点について説明を行い、上述した実施例と同じ点は説明を省略する。

ステップＳ３２０において、ＯＣＳ１２６の通常モードスレッドは、オペレーションパネル１３１０に表示している画面（実施例３の図３５参照）のレスキューボタンが押下されたかどうかを判定する。ＯＣＳ１２６の通常モードスレッドは、オペレーションパネル１３１０に表示している画面のレスキューボタンが押下されたと判定すると（ステップＳ３２０においてＹＥＳ）、ステップＳ３２１に進み、レスキューボタンが押下されていないと判定すると（ステップＳ３２０においてＮＯ）、ステップＳ３２０の処理を繰り返す。

ステップＳ３２１では、ＯＣＳ１２６の通常モードスレッドが、レスキューモード移行の確認画面をオペレーションパネル１３１０に表示する（実施例３の図３６参照。）。

ステップＳ３２１に続いてステップＳ３２２に進み、ＯＣＳ１２６の通常モードスレッドは、図３６のレスキューモード移行確認画面の実行ボタンが押下されたかどうかを判定する。ＯＣＳ１２６の通常モードスレッドは、図３６のレスキューモード移行確認画面の実行ボタンが押下されたと判定すると（ステップＳ３２２においてＹＥＳ）、ステップＳ３２３に進み、中止ボタンが押下さたと判定すると（ステップＳ３２２においてＮＯ）、図３５に示した画面をオペレーションパネル１３１０に表示し、ステップＳ３２０からの処理を繰り返す。

ステップＳ３２３では、ＯＣＳ１２６の通常モードスレッドが、メンテナンスを行うモジュールをユーザに選択させるメンテナンスモジュール一覧画面をオペレーションパネル１３１０に表示する（後述する図４４参照。）。

ステップＳ３２３に続いてステップＳ３２４に進み、ＯＣＳ１２６の通常モードスレッドは、図４４のメンテナンスモジュール一覧画面においてメンテナンスモジュールが選択されたか否かを判定する。ＯＣＳ１２６の通常モードスレッドは、図４４のメンテナンスモジュール一覧画面においてメンテナンスモジュールが選択されたと判定すると（ステップＳ３２４においてＹＥＳ）、ステップＳ３２５に進み、メンテナンスモジュールが選択されていないと判定すると（ステップＳ３２４においてＮＯ）、ステップＳ３２４の処理を繰り返す。

ステップＳ３２５では、ＯＣＳ１２６の通常モードスレッドが、選択したモジュールをユーザに確認させる選択モジュール確認画面をオペレーションパネル１３１０に表示する（後述する図４５参照。）。

ステップＳ３２５に続いてステップＳ３２６に進み、ＯＣＳ１２６の通常モードスレッドは、図４５の選択モジュール確認画面において「はい」ボタンが押下されたか否かを判定する。ＯＣＳ１２６の通常モードスレッドは、図４５の選択モジュール確認画面において「はい」ボタンが押下されたと判定すると（ステップＳ３２６においてＹＥＳ）、ステップＳ３２７に進み、「いいえ」ボタンが押下されたと判定すると（ステップＳ３２６においてＮＯ）、ステップＳ３２０からの処理を繰り返す。

ステップＳ３２７では、ＯＣＳ１２６の通常モードスレッドより、メンテナンス対象のモジュールを識別するＩＤ等を渡された、例えばＳＣＳ１２２の通常モードスレッドが、メンテナンスフラグと、メンテナンス対象のモジュールのモジュール情報と、を更新中断情報に格納する。

ステップＳ３２７に続いてステップＳ３２８に進み、例えばＳＣＳ１２２の通常モードスレッドより通知を受けたＲＯＭモニタ４１０又はプログラム起動部４２０は、複合機１００をリブートする。

以下、メンテナンスモジュール一覧画面の一例を、図４４に示す。図４４は、メンテナンスモジュール一覧画面の一例を示す図である。

図４４に示されるように、メンテナンスモジュール一覧画面には、メンテナンス対象のモジュールの一覧が表示されている。ユーザは、図４４に示されるようなメンテナンスモジュール一覧画面を参照し、メンテナンス対象、つまり正常動作していたプログラムに戻す１又は複数のモジュールを選択する。

以下、選択モジュール確認画面の一例を、図４５に示す。図４５は、選択モジュール確認画面の一例を示す図である。

図４５に示されるように、選択モジュール確認画面には、ユーザが選択したモジュールを確認する旨の情報が表示されている。

以下、ＳＣＳ１２２のレスキューモードスレッドで実行される更新データ選定処理の他の例を、図４６を用いて説明する。図４６は、ＳＣＳのレスキューモードスレッドで実行される更新データ選定処理を説明するためのフローチャート（その３）である。

ステップＳ３３０においてＳＣＳ１２２のレスキューモードスレッドは、更新中断情報にモジュールＩＤ及び更新先アドレスが格納されているか否かを判定する。ＳＣＳ１２２のレスキューモードスレッドは、更新中断情報にモジュールＩＤ及び更新先アドレスが格納されていると判定すると（ステップＳ３３０においてＹＥＳ）、ステップＳ３３１に進み、更新中断情報にモジュールＩＤ及び更新先アドレスが格納されていないと判定すると（ステップＳ３３０においてＮＯ）、ステップＳ３３３に進む。

ステップＳ３３３では、ＳＣＳ１２２のレスキューモードスレッドが、ＨＤＤ１３０３等より正常動作する出荷時の全プログラムを取得する。

ステップＳ３３３に続いてステップＳ３３４に進み、ＳＣＳ１２２のレスキューモードスレッドは、ＨＤＤ１３０３等より正常動作する出荷時の全プログラムのモジュールＩＤや、更新先アドレス、更新データサイズ等のモジュール情報を取得し、ステップＳ３３５に進む。

一方、ステップＳ３３１では、ＳＣＳ１２２のレスキューモードスレッドが、更新中断情報に格納されているモジュールＩＤに対応するプログラム、つまりユーザによって選択された１又は複数のモジュールに対応する正常動作する出荷時のプログラムをＨＤＤ１３０３等より取得する。

ステップＳ３３１に続いてステップＳ３３２に進み、ＳＣＳ１２２のレスキューモードスレッドは、ＨＤＤ１３０３等より、更新中断情報に格納されているモジュールＩＤに対応するプログラム、つまりユーザによって選択された１又は複数のモジュールに対応するプログラムのモジュールＩＤや、更新先アドレス、更新データサイズ等のモジュール情報を取得し、ステップＳ３３５に進む。

ステップＳ３３５では、ＳＣＳ１２２のレスキューモードスレッドが、ＳＣＳ１２２のＲＯＭ更新部４３０を起動する。

図４６に示したように、出荷時の全プログラム又はユーザに選択されたモジュールに対応するプログラムを取得し、ＳＣＳ１２２のＲＯＭ更新部４３０を起動して、フラッシュＲＯＭ２０４を更新することによって、全プログラム又はユーザに選択された１又は複数のモジュールに対応するプログラムを正常に動作していた出荷時の状態に戻すことができる。

以下、更新中断情報をＮＶＲＡＭ空間に格納する場合の更新中断情報のレイアウトの他の例を、図４７を用いて説明する。図４７は、更新中断情報をＮＶＲＡＭに格納する場合の更新中断情報のレイアウトを説明するための図（その３）である。

図４７に示されるように、更新中断情報は、例えば１バイトのメンテナンスフラグと、１バイトのメンテナンス内容フラグと、少なくとも１つ以上の、１６バイトのモジュールＩＤと、該モジュールＩＤに対応するモジュールに係る４バイトの更新先アドレスと、を含む。

なお、上述した実施例に示したように、更新中断情報をＨＤＤ１３０３に格納する場合、図４７に示した内容を、例えば更新中断情報ファイル等に含めるようにしてもよい。

実施例６に示したような処理を行うことによって、全プログラム又はユーザに選択された１又は複数のモジュールに対応するプログラムを正常に動作していた出荷時の状態に戻すことができる。

以下、ＳＣＳ１２２のＲＯＭ更新部４３０によるＲＯＭ更新処理の他の例を、図４８を用いて説明する。図４８は、ＳＣＳのＲＯＭ更新部によるＲＯＭ更新処理を説明するためのフローチャート（その５）である。なお、以下では、上述した実施例とは異なる点について説明を行い、上述した実施例と同じ点は説明を省略する。

ステップＳ３４０において、ＳＣＳ１２２のＲＯＭ更新部４３０は、モジュールＩＤ、更新先アドレス、更新データオフセット、更新データサイズ等の更新情報を更新中断情報に格納する。

ステップＳ３４０に続いてステップＳ３４１に進み、ＳＣＳ１２２のＲＯＭ更新部４３０は、更新データによって更新されるフラッシュＲＯＭ２０４の対応する領域のデータを、ＨＤＤ１３０３等の二次記憶装置に蓄積する。

ステップＳ３４１に続いてステップＳ３４２に進み、ＳＣＳ１２２のＲＯＭ更新部４３０は、更新データによって更新されるフラッシュＲＯＭ２０４の対応する領域のデータを、ＨＤＤ１３０３等の二次記憶装置に蓄積できたか否かを判定する。ＳＣＳ１２２のＲＯＭ更新部４３０は、更新データによって更新されるフラッシュＲＯＭ２０４の対応する領域のデータを、ＨＤＤ１３０３等の二次記憶装置に蓄積できたと判定すると（ステップＳ３４２においてＹＥＳ）、ステップＳ３４７に進み、二次記憶装置に蓄積できなかったと判定すると（ステップＳ３４２においてＮＯ）、ステップＳ３４５に進む。

ステップＳ３４５では、ＳＣＳ１２２のＲＯＭ更新部４３０が、二次記憶装置内の、後述する図５０や、図５１等に示されるような（モジュールＩＤ）.ｌｏｇの先頭に記述されている蓄積ファイル名に対応する、ＨＤＤ１３０３等の二次記憶装置に蓄積されている蓄積ファイルを削除する。

ステップＳ３４５に続いてステップＳ３４６に進み、ＳＣＳ１２２のＲＯＭ更新部４３０は、（モジュールＩＤ）.ｌｏｇの先頭に記述されている蓄積ファイルの情報を削除し、ステップＳ３４１からの処理を繰り返す。

一方、ステップＳ３４７では、ＳＣＳ１２２のＲＯＭ更新部４３０が、（モジュールＩＤ）.ｌｏｇに、蓄積ファイル名、バージョン、利用した最終時刻（現在時刻）を記入する。

ステップＳ３４７に続いてステップＳ３４８に進み、ＳＣＳ１２２のＲＯＭ更新部４３０は、更新データパケットを展開した更新データ領域から対応する更新データを読み出して、該更新データで、フラッシュＲＯＭ２０４の更新先アドレスから書き換えを行う。

ステップＳ３４８に続いてステップＳ３４９に進み、ＳＣＳ１２２のＲＯＭ更新部４３０は、ステップＳ３４８において読み出した更新データと、ステップＳ３４８において書き換えを行った後のフラッシュＲＯＭ２０４の更新したモジュールのデータと、を比較して、正しく書き換えが行われたかどうか判定する。ＳＣＳ１２２のＲＯＭ更新部４３０は、正しく書き換えが行われたと判定すると（ステップＳ３４９においてＹＥＳ）、ステップＳ３６０に進み、正しく書き換えが行われなかったと判定すると（ステップＳ３４９においてＮＯ）、ステップＳ３５０に進む。 ステップＳ３５０では、ＳＣＳ１２２のＲＯＭ更新部４３０が、エラー処理を行う。例えば、ＳＣＳ１２２のＲＯＭ更新部４３０は、ＳＣＳ１２２のＲＯＭ更新モードスレッドから呼ばれた場合は、ＯＣＳ１２６のＲＯＭ更新モードスレッドを介して、エラー画面をオペレーションパネル１３１０に表示する。また、ＳＣＳ１２２のＲＯＭ更新部４３０は、ＳＣＳのレスキューモードスレッドから呼ばれた場合は、エラー情報をＨＤＤ１３０３等に格納されているログファイルに格納する。

一方、ステップＳ３６０では、ＳＣＳ１２２のＲＯＭ更新部４３０が、更新対象の変数等を参照し、次の更新情報が設定されているかどうかを判定する。ＳＣＳ１２２のＲＯＭ更新部４３０は、更新対象の変数等に次の更新情報が設定されていると判定すると（ステップＳ３６０においてＹＥＳ）、ステップＳ３４０からの処理を繰り返し、更新対象の変数等に次の更新情報が設定されていないと判定すると（ステップＳ３６０においてＮＯ）、ステップＳ３６１に進む。

ステップＳ３６１では、ＳＣＳ１２２のＲＯＭ更新部４３０が、更新中断情報に格納されている更新情報を削除する。

図４８に示されるような処理を行うことによって、二次記憶装置に蓄積された、更新される領域のデータを、ログ情報ファイルと対応付けて、過去のバージョンとして二次記憶装置に蓄積することができる。このような構成とすることによって、後述するように、ユーザは、１又は複数のプログラムを、所定の過去のバージョンのプログラムに戻すことができる。

以下、更新中断情報をＮＶＲＡＭ空間に格納する場合の更新中断情報のレイアウトの他の例を、図４９を用いて説明する。図４９は、更新中断情報をＮＶＲＡＭに格納する場合の更新中断情報のレイアウトを説明するための図（その４）である。

図４９に示されるように、更新中断情報は、例えば１バイトのメンテナンスフラグと、１バイトのメンテナンス内容フラグと、少なくとも１つ以上の、１６バイトのモジュールＩＤと、該モジュールＩＤに対応するモジュールに係る４バイトの更新先アドレスと、該モジュールのバージョンに係る後述する図５０に示されるような４バイトの通し番号と、を含む。

なお、上述した実施例に示したように、更新中断情報をＨＤＤ１３０３に格納する場合、図４９に示した内容を、例えば更新中断情報ファイル等に含めるようにしてもよい。

以下、ＨＤＤ１３０３のディレクトリ及びファイル構成の他の例を、図５０を用いて説明する。図５０は、ＨＤＤのディレクトリ及びファイル構成を説明するための図（その４）である。

図５０に示されるように、ＨＤＤ１３０３のｓｔｏｒｅディレクトリ配下には、アプリケーション１３０やプラットフォーム１２０等を構成する各モジュールに対応する、正常動作する出荷時のデータ（プログラム）と、モジュールに係るモジュール情報ファイルと、が格納されている。

また、図５０に示されるように、ＨＤＤ１３０３のｂａｃｋｕｐディレクトリ配下には、図４８のステップＳ３４１等において蓄積したデータ（プログラム）や、該データに係るログ情報が記述された、後述する図５１に示すようなログ情報ファイル等が格納されている。なお、データの名称は、“（モジュールＩＤ）．（通し番号）”でＨＤＤ１３０３のｂａｃｋｕｐディレクトリ配下に格納され、ログ情報ファイルは、“（モジュールＩＤ）．ｌｏｇ”でＨＤＤ１３０３のｂａｃｋｕｐディレクトリ配下に格納される。

以下、ログ情報ファイルの内容の一例を、図５１を用いて説明する。図５１は、ログ情報ファイルの内容の一例を説明するための図である。

図５１に示されるように、ログ情報ファイルには、蓄積ファイル名と、バージョンと、利用した最終時刻（蓄積された時刻）と、が含まれる。

以下、プログラムを過去バージョンに戻す処理に係る復旧メニュー画面の他の例を、図５２を用いて説明する。図５２は、復旧メニュー画面を示すための図（その２）である。

図５２（Ａ）に示されるように、ＯＣＳ１２６のレスキューモードスレッドは、初めに、復旧作業を行うかどうかの選択画面をオペレーションパネル１３１０に表示する。ＯＣＳ１２６のレスキューモードスレッドは、ユーザが「行う」を選択したと判定すると、図５２（Ｂ）に示されるような復旧内容の選択画面をオペレーションパネル１３１０に表示し、ユーザが「行わない」を選択したと判定すると、図５２（Ｃ）に示されるような復旧作業を中止する旨を表す画面をオペレーションパネル１３１０に表示する。

また、ＯＣＳ１２６のレスキューモードスレッドは、図５２（Ｂ）に示されるような復旧内容の選択画面において、ユーザが「機器に蓄積されているソフトウェアに戻す」を選択したと判定すると、図５２（Ｄ）に示されるような復旧するモジュールの選択画面をオペレーションパネル１３１０に表示し、ユーザが、例えばモジュールの少なくとも１つを選択したと判定すると、選択された該モジュールでよいか否かを確認する図５２（Ｅ）に示されるような選択モジュール確認画面をオペレーションパネル１３１０に表示する。

ＯＣＳ１２６のレスキューモードスレッドは、図５２（Ｅ）に示されるような選択モジュール確認画面においてユーザが「はい」ボタンを選択したと判定すると、図５２（Ｆ）に示されるような、複合機１００が蓄積している対応するプログラムのバージョンの選択画面をオペレーションパネル１３１０に表示し、ユーザが、例えばバージョンの１つを選択したと判定すると、選択された該バージョンでよいか否かを確認する図５２（Ｇ）に示されるような選択バージョン確認画面をオペレーションパネル１３１０に表示する。

以下、ＳＣＳ１２２のレスキューモードスレッドで実行される更新データ選定処理の他の例を、図５３を用いて説明する。図５３は、ＳＣＳのレスキューモードスレッドで実行される更新データ選定処理を説明するためのフローチャート（その４）である。

ステップＳ３７０においてＳＣＳ１２２のレスキューモードスレッドは、ＨＤＤ１３０３等より、ユーザによって選択されたモジュールで、且つユーザによって選択されたバージョンのプログラムを取得する。

ステップＳ３７０に続いてステップＳ３７１に進み、ＳＣＳ１２２のレスキューモードスレッドは、ＨＤＤ１３０３等より、ユーザによって選択されたモジュールで、且つユーザによって選択されたバージョンのプログラムのモジュールＩＤや、更新先アドレス、更新データサイズ等のモジュール情報を取得する。

ステップＳ３７１に続いてステップＳ３７２に進み、ＳＣＳ１２２のレスキューモードスレッドは、ＳＣＳ１２２のＲＯＭ更新部４３０を起動する。

図５３に示したように、ユーザによって選択されたモジュールで、且つユーザによって選択されたバージョンのプログラムを取得し、ＳＣＳ１２２のＲＯＭ更新部４３０を起動して、フラッシュＲＯＭ２０４を更新することによって、ユーザによって選択されたプログラムを、ユーザによって選択された、正常に動作していたバージョンの状態に戻すことができる。

実施例７に示したような処理を行うことによって、ユーザからの要求等に応じて、指定された１又は複数のプログラムを、指定された過去のバージョンに戻すことができる。

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

プログラムの更新中断後に画像形成装置の機能の一部が使用不可能になった一例を説明するための図である。 バージョンの不整合により画像形成装置の機能の一部が使用不可能になった一例を説明するための図である。 複合機の構成を示すブロック図（その１）である。 複合機のハードウェア構成を示すブロック図である。 リモートＲＯＭ更新の全体処理を説明するための図（その１）である。 リモートＲＯＭ更新の全体処理を説明するための図（その２）である。 複合機で受信した更新データパケットの展開後のデータ構造図である。 複合機起動部の構成の一例を示すブロック図である。 ＲＯＭ更新部の構成の一例を示すブロック図である。 複合機の構成を示すブロック図（その２）である。 ブート時のＯＳ切り替え処理を説明するためのフローチャートである。 ＳＣＳのＲＯＭ更新モードスレッドで実行される更新データ選定処理を説明するためのフローチャート（その１）である。 ＳＣＳのＲＯＭ更新部によるＲＯＭ更新処理を説明するためのフローチャート（その１）である。 ＳＣＳのレスキューモードスレッドで実行される更新データ選定処理を説明するためのフローチャート（その１）である。 メモリ構造の一例を示すための図である。 更新中断情報をＮＶＲＡＭに格納する場合の更新中断情報のレイアウトを説明するための図（その１）である。 ＨＤＤのディレクトリ及びファイル構成を説明するための図（その１）である。 ＨＤＤのディレクトリ及びファイル構成を説明するための図（その２）である。 更新中断情報ファイルの内容の一例を説明するための図である。 複合機の構成を示すブロック図（その３）である。 ブート時のＯＳ切り替え処理を説明するためのフローチャート（その２）である。 起動時画面を示すための図である。 ＳＣＳのＲＯＭ更新部によるＲＯＭ更新処理を説明するためのフローチャート（その２）である。 復旧中画面を示すための図である。 エラー画面を示すための図である。 複合機の構成を示すブロック図（その４）である。 ブート時のＯＳ切り替え処理を説明するためのフローチャート（その３）である。 復旧メニュー画面を示すための図（その１）である。 ＳＣＳによるメンテナンス内容フラグチェック処理を説明するためのフローチャート（その１）である。 受信待機中画面を示すための図である。 ＳＣＳのレスキューモードスレッドで実行される更新データ選定処理を説明するためのフローチャート（その２）である。 ＳＣＳのＲＯＭ更新モードスレッドで実行される更新データ選定処理を説明するためのフローチャート（その２）である。 ＳＣＳのＲＯＭ更新部によるＲＯＭ更新処理を説明するためのフローチャート（その３）である。 正常起動後からのレスキューモード移行処理を説明するためのフローチャート（その１）である。 正常起動後の画面を示すための図である。 レスキューモード移行確認画面を示すための図である。 更新中断情報をＮＶＲＡＭに格納する場合の更新中断情報のレイアウトを説明するための図（その２）である。 ＨＤＤのディレクトリ及びファイル構成を説明するための図（その３）である。 正常動作する出荷時のプリンタアプリのモジュール情報ファイルの内容の一例を説明するための図である。 ＳＣＳのＲＯＭ更新部によるＲＯＭ更新処理を説明するためのフローチャート（その４）である。 ＳＣＳによるメンテナンス内容フラグチェック処理を説明するためのフローチャート（その２）である。 強制復旧移行画面の一例を示す図である。 正常起動後からのレスキューモード移行処理を説明するためのフローチャート（その２）である。 メンテナンスモジュール一覧画面の一例を示す図である。 選択モジュール確認画面の一例を示す図である。 ＳＣＳのレスキューモードスレッドで実行される更新データ選定処理を説明するためのフローチャート（その３）である。 更新中断情報をＮＶＲＡＭに格納する場合の更新中断情報のレイアウトを説明するための図（その３）である。 ＳＣＳのＲＯＭ更新部によるＲＯＭ更新処理を説明するためのフローチャート（その５）である。 更新中断情報をＮＶＲＡＭに格納する場合の更新中断情報のレイアウトを説明するための図（その４）である。 ＨＤＤのディレクトリ及びファイル構成を説明するための図（その４）である。 ログ情報ファイルの内容の一例を説明するための図である。 復旧メニュー画面を示すための図（その２）である。 ＳＣＳのレスキューモードスレッドで実行される更新データ選定処理を説明するためのフローチャート（その４）である。

符号の説明

１００ 複合機
１１１ プリンタアプリ
１１２ コピーアプリ
１１３ ファックスアプリ
１１４ スキャナアプリ
１１５ ネットファイルアプリ
１１７ リモートＲＯＭ更新アプリ（ＲＲＵアプリ）
１２１ 汎用ＯＳ
１２２ ＳＣＳ
１２３ ＳＲＭ
１２４ ＥＣＳ
１２５ ＭＣＳ
１２６ ＯＣＳ
１２７ ＦＣＳ
１２８ ＮＣＳ
１３１ 汎用レスキューＯＳ
４１０ ＲＯＭモニタ
４２０ プログラム起動部
４２２ サービス層起動部
４２３ アプリ起動部
４２４ 起動情報設定部
４３０ ＲＯＭ更新部
４３１ 更新情報格納部
４３２ 領域データ蓄積部
４３３ ＲＯＭ更新部
４３４ 更新情報削除部
４３５ 表示制御部
４３６ 送信制御部

Claims (24)

1. プログラムを記憶するプログラム記憶手段と、該プログラム記憶手段に記憶されているプログラムに係る更新データを受信する更新データ受信手段と、前記更新データに基づいて、前記プログラム記憶手段に記憶されている対応するプログラムを更新するプログラム更新手段と、を有する情報処理装置であって、
   当該情報処理装置が前回起動されていたときに、前記プログラム更新手段における前記プログラムの更新が中断されたかどうかを判定する更新中断判定手段と、
   前記更新中断判定手段における判定結果に応じて、対応するオペレーティングシステムを起動するオペレーティングシステム起動手段と、
   前記プログラム記憶手段に記憶されているプログラムを復旧する第一プログラム復旧手段と、
   を有することを特徴とする情報処理装置。
2. 前記更新データを記憶する更新データ記憶手段を更に有することを特徴とする請求項１記載の情報処理装置。
3. 前記プログラム更新手段において更新される前のプログラムを記憶する更新前プログラム記憶手段を更に有することを特徴とする請求項１又は２記載の情報処理装置。
4. 前記第一プログラム復旧手段は、前記プログラム記憶手段に記憶されているプログラムを、前記更新データ記憶手段に記憶されている更新データに含まれるプログラムで書き換えることを特徴とする請求項２記載の情報処理装置。
5. 前記第一プログラム復旧手段は、前記プログラム記憶手段に記憶されているプログラムを、前記更新前プログラム記憶手段に記憶されているプログラムで書き換えることを特徴とする請求項３記載の情報処理装置。
6. プログラムを記憶するプログラム記憶手段と、該プログラム記憶手段に記憶されているプログラムに係る更新データを受信する更新データ受信手段と、前記更新データに基づいて、前記プログラム記憶手段に記憶されている対応するプログラムを更新するプログラム更新手段と、を有する情報処理装置であって、
   当該情報処理装置が前回起動されていたときに、前記プログラム記憶手段に記憶されているプログラムを復旧するため、リブートされたかどうかを判定するリブート判定手段と、
   前記リブート判定手段における判定結果に応じて、対応するオペレーティングシステムを起動するオペレーティングシステム起動手段と、
   前記プログラム記憶手段に記憶されているプログラムを復旧する第二プログラム復旧手段と、
   を有することを特徴とする情報処理装置。
7. 当該情報処理装置の出荷時のプログラムを記憶する出荷時プログラム記憶手段を更に有することを特徴とする請求項６記載の情報処理装置。
8. 前記第二プログラム復旧手段は、前記プログラム記憶手段に記憶されているプログラムを、前記出荷時プログラム記憶手段に記憶されているプログラムで書き換えることを特徴とする請求項７記載の情報処理装置。
9. 前記第二プログラム復旧手段は、前記プログラム記憶手段に記憶されている対応する１又は複数のプログラムを、前記出荷時プログラム記憶手段に記憶されている１又は複数のプログラムで書き替えることを特徴とする請求項８記載の情報処理装置。
10. 前記第二プログラム復旧手段は、前記プログラム記憶手段に記憶されているプログラムを、前記更新データ受信手段において新たに受信した前記更新データに含まれるプログラムで書き換えることを特徴とする請求項６又は７記載の情報処理装置。
11. 前記更新データを記憶する更新データ記憶手段を更に有することを特徴とする請求項６記載の情報処理装置。
12. 前記プログラム更新手段において更新される前のプログラムを記憶する更新前プログラム記憶手段を更に有することを特徴とする請求項７又は１１記載の情報処理装置。
13. 前記更新前プログラム記憶手段によって記憶された、更新される前のプログラムに係るログ情報を記憶するログ情報記憶手段を更に有し、
    前記第二プログラム復旧手段は、前記プログラム記憶手段に記憶されている対応する１又は複数のプログラムを、対応する前記ログ情報記憶手段に記憶されている前記ログ情報に基づいて、前記更新前プログラム記憶手段に記憶されている１又は複数の更新される前のプログラムで書き替えることを特徴とする請求項１２記載の情報処理装置。
14. 前記プログラム記憶手段に記憶されているプログラムに係る更新データに係る待機状態がタイムアウトしたか否かを判定するタイムアウト判定手段を更に有し、
    前記タイムアウト判定手段においてタイムアウトしたと判定すると、前記第二プログラム復旧手段は、前記プログラム記憶手段に記憶されている１又は複数のプログラムを、前記出荷時プログラム記憶手段に記憶されている１又は複数のプログラムで書き換えるか、又は前記ログ情報記憶手段に記憶されている前記ログ情報に対応する前記更新前プログラム記憶手段に記憶されている１又は複数の更新される前のプログラムで書き替えることを特徴とする請求項１２又は１３記載の情報処理装置。
15. 前記情報処理装置は、画像を形成する画像形成装置であることを特徴とする請求項１乃至１４何れか一項記載の情報処理装置。
16. プログラム記憶手段に記憶されているプログラムに係る更新データを受信する更新データ受信手段と、前記更新データ受信手段において受信した前記更新データに基づいて、前記プログラム記憶手段に記憶されている対応するプログラムを更新するプログラム更新手段と、を有する情報処理装置におけるプログラム復旧方法であって、
    当該情報処理装置が前回起動されていたときに、プログラムの更新が中断されたかどうかを判定する更新中断判定段階と、
    前記更新中断判定段階における判定結果に応じて、対応するオペレーティングシステムを起動するオペレーティングシステム起動段階と、
    前記プログラム記憶手段に記憶されているプログラムを復旧する第一プログラム復旧段階と、
    を有することを特徴とするプログラム復旧方法。
17. 前記情報処理装置は、前記更新データを記憶する更新データ記憶手段を更に有し、
    前記第一プログラム復旧段階は、前記プログラム記憶手段に記憶されているプログラムを、前記更新データ記憶手段に記憶されている更新データに含まれるプログラムで書き換えることを特徴とする請求項１６記載のプログラム復旧方法。
18. 前記情報処理装置は、前記プログラム更新段階において更新される前のプログラムを記憶する更新前プログラム記憶手段を更に有し、
    前記第一プログラム復旧段階は、前記プログラム記憶手段に記憶されているプログラムを、前記更新前プログラム記憶手段に記憶されているプログラムで書き換えることを特徴とする請求項１６記載のプログラム復旧方法。
19. プログラム記憶手段に記憶されているプログラムに係る更新データを受信する更新データ受信手段と、前記更新データ受信手段において受信した前記更新データに基づいて、前記プログラム記憶手段に記憶されている対応するプログラムを更新するプログラム更新手段と、を有する情報処理装置におけるプログラム復旧方法であって、
    当該情報処理装置が前回起動されていたときに、前記プログラム記憶手段に記憶されているプログラムを復旧するため、リブートされたかどうかを判定するリブート判定段階と、
    前記リブート判定段階における判定結果に応じて、対応するオペレーティングシステムを起動するオペレーティングシステム起動段階と、
    前記プログラム記憶手段に記憶されているプログラムを復旧する第二プログラム復旧段階と、
    を有することを特徴とするプログラム復旧方法。
20. 前記情報処理装置は、当該情報処理装置の出荷時のプログラムを記憶する出荷時プログラム記憶手段を更に有し、
    前記第二プログラム復旧段階は、前記プログラム記憶手段に記憶されているプログラムを、前記出荷時プログラム記憶手段に記憶されているプログラムで書き換えることを特徴とする請求項１９記載のプログラム復旧方法。
21. 前記第二プログラム復旧段階は、前記プログラム記憶手段に記憶されているプログラムを、新たに受信した前記更新データに含まれるプログラムで書き換えることを特徴とする請求項１９記載のプログラム復旧方法。
22. 前記情報処理装置は、前記プログラム更新手段において更新される前のプログラムを記憶する更新前プログラム記憶手段と、前記更新前プログラム記憶手段によって記憶された、更新される前のプログラムに係るログ情報を記憶するログ情報記憶手段と、を更に有し、
    前記第二プログラム復旧段階は、前記プログラム記憶手段に記憶されている対応する１又は複数のプログラムを、前記ログ情報記憶手段に記憶されている前記ログ情報に対応する前記更新前プログラム記憶手段に記憶されている１又は複数の更新される前のプログラムで書き替えることを特徴とする請求項１９記載のプログラム復旧方法。
23. 請求項１６乃至２２何れか一項記載のプログラム復旧方法をコンピュータに実行させるためのプログラム復旧プログラム。
24. 請求項２３記載のプログラム復旧プログラムを記録したコンピュータ読み取り可能な記録媒体。

Images