JP5494772B2 - 機器、プログラム更新方法、プログラム、及びプログラム更新システム - Google Patents

Description

本発明は、機器、プログラム更新方法、プログラム、及びプログラム更新システムに関する。

近年におけるプリンタ、コピー機、スキャナ、ファクシミリ、又はこれらの機能を一台の筐体で実現する複合機等の画像形成装置では、メモリ等の制限は厳しいものの、汎用的なコンピュータと同様にＣＰＵを備え、各機能はアプリケーションの制御によって実現されるようになっている。このような画像形成装置の中にはアプリケーションを実装及び実行するためのプラットフォームを備え、その出荷後にユーザの利用環境に適したアプリケーションを作成及びインストールすることにより、機能強化を図れるものもある（例えば、特許文献１）。

ところで、このようなアプリケーションのインストールやアップデート等を複数台の画像形成装置や、遠隔地にあるに画像形成装置に対して行う必要がある場合は、当該画像形成装置とネットワークを介して接続されたＰＣ等からリモートでインストール又はアップデートするのが効率的である。

しかしながら、リモートインストールやリモートアップデートの場合、インストール処理又はアップデート処理（以下「更新処理」で総称する。）は画像形成装置のバックグラウンドで行われるため、当該画像形成装置を操作中のユーザ（例えば、当該画像形成装置を用いてコピー等を行っているユーザ）は、更新処理が行われていることに気付かない場合がある。したがって、更新処理中に画像形成装置の電源がユーザによって落とされてしまう可能性がある。

電源断等の発生により更新処理が中断してしまうと、更新対象のファイルの破壊や、関連する複数のファイル間における不整合等が発生し、画像形成装置が正常に動作しなくなってしまうという可能性がある。

他方において、更新処理そのものは成功した場合でも、更新後のアプリケーションのメモリ消費量が増加した場合、改めて画像形成装置を起動した際にメモリ不足等の原因により画像形成装置が正常に動作しない場合も予測される。

本発明は、上記の点に鑑みてなされたものであって、プログラムの更新処理を適切に実行することのできるプログラム更新方法、プログラム、及びプログラム更新システムの提供を目的とする。

そこで上記課題を解決するため、本発明は、プログラムを実行し前記プログラムを更新可能な機器であって、前記プログラムの更新用データを外部装置より受信する受信手段と、前記更新用データに基づいて前記プログラムの更新処理を実行することにより更新プログラムを生成し、前記更新プログラムを起動対象とさせる更新手段と、前記更新処理を構成する各段階の開始に応じ、当該段階の開始を示す第一の情報を記憶装置に記録し、前記更新処理の完了に応じ、前記更新処理の完了を示す第二の情報を前記記憶装置に記録する進捗情報記録手段と、前記更新プログラムの起動後に、前記第二の情報の有無に基づいて前記更新プログラムの起動の成否を確認し、起動に失敗しているときに、保存されている更新前のプログラムを起動対象とさせる復元手段とを有することを特徴とする。

このような機器では、プログラムの更新処理を適切に実行することができる。

また、上記課題を解決するため、本発明は、上記機器におけるプログラム更新方法、又は前記プログラム更新方法をコンピュータに実行させるためのプログラムとしてもよい。

本発明によれば、プログラムの更新処理を適切に実行することのできる機器、プログラム更新方法、プログラム、及びプログラム更新システムを提供することができる。

本発明の実施の形態における画像形成装置の機能構成例を説明するための図である。 本発明の実施の形態における画像形成装置のハードウェア構成例を示すである。 本実施の形態の画像形成装置に対する更新処理の概要を説明するためのブロック図である。 本実施の形態の画像形成装置に対する更新処理の概要を説明するためのシーケンス図である。 複合機の起動処理を説明するためのシーケンス図である。 更新処理が正常に終了しなかったときの複合機の再起動時の起動処理を説明するためのフローチャートである。 リカバリ処理の処理手順を説明するためのシーケンス図である。 ＪＳＤＫプラットフォームとは別のプロセスによって管理サーバとの通信が行われる場合の画像形成装置に対する更新処理の概要を説明するためのブロック図である。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における画像形成装置の機能構成例を説明するための図である。本実施の形態では、図１の複合機１０１は、種々のハードウェア１１１と、種々のソフトウェア１１２と、複合機起動部１１３により構成される。

複合機１０１のハードウェア１１１としては、撮像部１２１と、印刷部１２２と、その他のハードウェア１２３が存在する。撮像部１２１は、読取原稿から画像（画像データ）を読み取るためのハードウェアである。印刷部１２２は、画像（画像データ）を印刷用紙に印刷するためのハードウェアである。

複合機１０１のソフトウェア１１２としては、種々のアプリケーション１３１と、種々のプラットフォーム１３２が存在する。これらのプログラムは、ＵＮＩＸ（登録商標）等のＯＳ（オペレーティングシステム）によりプロセス単位で並列的に実行される。

アプリケーション１３１としては、コピー用のアプリケーションであるコピーアプリ１４１、プリンタ用のアプリケーションであるプリンタアプリ１４２、スキャナ用のアプリケーションであるスキャナアプリ１４３、ファクシミリ用のアプリケーションであるファクシミリアプリ１４４、ネットワークファイル用のアプリケーションであるネットワークファイルアプリ１４５が存在する。更に、スクリプトパーサ１８２や、ＣＳＤＫアプリ１４６及びＪＳＤＫアプリ１４７の制御用のソフトウェアであるＳＤＫアプリケーションサービス（ＳＡＳ）１８３が存在する。

アプリケーション１３１は、専用のＳＤＫ（ソフトウェア開発キット）を使用して開発することができる。ＳＤＫを使用して開発したアプリケーション１３１をＳＤＫアプリと呼ぶ。専用のＳＤＫとしては、Ｃ言語でアプリケーション１３１を開発するための「ＣＳＤＫ」や、Ｊａｖａ（登録商標）言語でアプリケーション１３１を開発するための「ＪＳＤＫ」が提供される。ＣＳＤＫを使用して開発したアプリケーション１３１を「ＣＳＤＫアプリ」と呼び、ＪＳＤＫを使用して開発したアプリケーション１３１を「ＪＳＤＫアプリ」と呼ぶ。図１の複合機１０１にも、ＣＳＤＫアプリ１４６と、ＪＳＤＫアプリ１４７が存在する。図１の複合機１０１にはさらに、Ｊａｖａ（登録商標）言語で記述されたＪＳＤＫアプリ１４７の実行環境を提供し、また、ＪＳＤＫアプリ１４７とＣ言語で記述された他のソフトウェア１１２との仲介を行うソフトウェア１１２として、ＪＳＤＫプラットフォーム１４８が存在する。また、一般的にＪａｖａ（登録商標）によって実装されたアプリケーションの実行環境を実現するモジュールとして、Ｊａｖａ（登録商標）仮想マシンであるＣＶＭ（コンパクト仮想マシン）１９１や、ＪＮＩ（Ｊａｖａ（登録商標） Ｎａｔｉｖｅ Ｉｎｔｅｒｆａｃｅ）１９２等が存在する。更に、ＪＮＩ１９２を介して呼び出される、Ｎａｔｉｖｅ Ｌｉｂｒａｒｙ１９３が存在する。

プラットフォーム１３２としては、種々のコントロールサービス１５１、システムリソースマネージャ１５２、種々のハンドラ１５３が存在する。コントロールサービス１５１としては、ネットワークコントロールサービス（ＮＣＳ）１６１、ファクシミリコントロールサービス（ＦＣＳ）１６２、デリバリコントロールサービス（ＤＣＳ）１６３、エンジンコントロールサービス（ＥＣＳ）１６４、メモリコントロールサービス（ＭＣＳ）１６５、オペレーションパネルコントロールサービス（ＯＣＳ）１６６、サーティフィケーションコントロールサービス（ＣＣＳ）１６７、ユーザディレクトリコントロールサービス（ＵＣＳ）１６８、システムコントロールサービス（ＳＣＳ）１６９が存在する。ハンドラ１５３としては、ファクシミリコントロールユニットハンドラ（ＦＣＵＨ）１７１、イメージメモリハンドラ（ＩＭＨ）１７２が存在する。

ＮＣＳ１６１のプロセスは、ネットワーク通信の仲介を行う。ＦＣＳ１６２のプロセスは、ファクシミリのＡＰＩを提供する。ＤＣＳ１６３のプロセスは、蓄積文書の配信処理に関する制御を行う。ＥＣＳ１６４のプロセスは、撮像部１２１や印刷部１２２に関する制御を行う。ＭＣＳ１６５のプロセスは、メモリやハードディスクドライブに関する制御を行う。ＯＣＳ１６６のプロセスは、オペレーションパネルに関する制御を行う。ＣＣＳ１６７のプロセスは、認証処理や課金処理に関する制御を行う。ＵＣＳ１６８のプロセスは、ユーザ情報の管理に関する制御を行う。ＳＣＳ１６９のプロセスは、システムの管理に関する制御を行う。

アプリケーション１３１とプラットフォーム１３２の仲介を行うソフトウェア１１２として、仮想アプリケーションサービス（ＶＡＳ）１３５が存在する。ＶＡＳ１３５は、アプリケーション１３１をクライアントとするサーバプロセスとして動作すると共に、プラットフォーム１３２をサーバとするクライアントプロセスとして動作する。ＶＡＳ１３５は、アプリケーション１３１から見てプラットフォーム１３２を隠蔽するラッピング機能を備え、プラットフォーム１３２のバージョンアップに伴うバージョン差を吸収する役割等を担う。

複合機起動部１１３は、複合機１０１の電源投入時に最初に実行される。これにより、ＵＮＩＸ（登録商標）等のＯＳが起動され、アプリケーション１３１やプラットフォーム１３２が起動される。これらのプログラムは、ハードディスクドライブやメモリカードに蓄積されており、ハードディスクドライブやメモリカードから再生されて、メモリに起動されることになる。

図２は、本発明の実施の形態における画像形成装置のハードウェア構成例を示すである。複合機１０１のハードウェア１１１としては、コントローラ２０１と、オペレーションパネル２０２と、ファクシミリコントロールユニット（ＦＣＵ）２０３と、撮像部１２１と、印刷部１２２が存在する。

コントローラ２０１は、ＣＰＵ２１１、ＡＳＩＣ２１２、ＮＢ２２１、ＳＢ２２２、ＭＥＭ−Ｐ２３１、ＭＥＭ−Ｃ２３２、ＨＤＤ（ハードディスクドライブ）２３３、メモリカードスロット２３４、ＮＩＣ（ネットワークインタフェースコントローラ）２４１、ＵＳＢデバイス２４２、ＩＥＥＥ１３９４デバイス２４３、セントロニクスデバイス２４４により構成される。

ＣＰＵ２１１は、種々の情報処理用のＩＣである。ＡＳＩＣ２１２は、種々の画像処理用のＩＣである。ＮＢ２２１は、コントローラ２０１のノースブリッジである。ＳＢ２２２は、コントローラ２０１のサウスブリッジである。ＭＥＭ−Ｐ２３１は、複合機１０１のシステムメモリである。ＭＥＭ−Ｃ２３２は、複合機１０１のローカルメモリである。ＨＤＤ２３３は、複合機１０１のストレージである。メモリカードスロット２３４は、メモリカード２３５をセットするためのスロットである。ＮＩＣ２４１は、ＭＡＣアドレスによるネットワーク通信用のコントローラである。ＵＳＢデバイス２４２は、ＵＳＢ規格の接続端子を提供するためのデバイスである。ＩＥＥＥ１３９４デバイス２４３は、ＩＥＥＥ１３９４規格の接続端子を提供するためのデバイスである。セントロニクスデバイス２４４は、セントロニクス仕様の接続端子を提供するためのデバイスである。

オペレーションパネル２０２は、オペレータが複合機１０１に入力を行うためのハードウェア（操作部）であると共に、オペレータが複合機１０１から出力を得るためのハードウェア（表示部）である。

上記のような複合機１０１において、アプリケーション１３１の更新処理（インストール、アンインストール、アップデート等）を実行する例について説明する。

図３は、本実施の形態の画像形成装置に対する更新処理の概要を説明するためのブロック図である。図３中、図１と同一部分には同一符号を付し、その説明は省略する。

図３において、管理サーバ３０は、ネットワークを介して一台以上の画像形成装置と接続し、各画像形成装置の状態等を管理する装置であり、例えば、ＰＣによって構成される。本実施の形態において管理サーバ３０は、複合機１０１に対してリモート更新処理の実行を指示すると共に、リモート更新処理に必要なデータ（更新用データ３１０）を送信する。

管理サーバ３０より送信されるリモート更新処理の実行指示や更新用データ３１０は、ＪＳＤＫプラットフォーム１４８の一部を構成するリモート更新用通信部１４８１が受信する。リモート更新用通信部１４８１は、受信した更新用データ３１０を、複合機１０１のＨＤＤ２３３又はメモリカード２３５等に保存する。

更新用データ３１０には、更新処理に必要なデータとして、更新処理対象のアプリケーション自体の他、更新処理の実行情報（例えば、更新部分を示す情報や、更新処理を構成する命令等）が記述されたスクリプトファイル等が圧縮されて格納されている。

スクリプトパーサ１８２は、更新用データ３１０に格納されているスクリプトファイルの記述内容を解釈する。ＳＡＳ１８３は、スクリプトパーサ１８２によって解釈された命令を実行することにより更新処理全体を制御する。

なお、図３において、破線３２０で囲まれた部分（以下「更新対象データ３２０」という。）は、リモート更新処理によって更新対象となり得る部分である。すなわち、ＪＳＤＫアプリ１４７、ＳＤＫＫプラットフォーム１４８、ＣＶＭ１９１、ＪＮＩ１９１、Ｎａｔｉｖｅ Ｌｉｂｒａｒｙ１９３、及びスクリプトパーサ１８２等が更新対象となり得る。

以下、複合機１０１の処理手順について説明する。図４は、本実施の形態の画像形成装置に対する更新処理の概要を説明するためのシーケンス図である。

例えば、管理サーバ３０に対するユーザによる入力又はプログラム等による自動的かつ定期的なトリガーに応じて、管理サーバ３０は、複合機１０１のリモート更新用通信部１４８１に対して機器情報の取得を要求する（Ｓ１０１）。リモート更新用通信部１４８１は、複合機１０１の機器情報を収集し、当該機器情報を例えば、ＸＭＬ（eXtensible Markup Language）形式のデータにして管理サーバ３０に返信する（Ｓ１０２）。機器情報には、例えば、複合機１０１のシリアル番号、メモリ空き容量、ＪＳＤＫプラットフォーム１４８のバージョン情報、及びインストール済みのＪＳＤＫアプリ１４７のアプリケーション情報等のソフトウェア構成に関する情報が含まれる。各ＪＳＤＫアプリ１４７のアプリケーション情報には、アプリケーションごとに一意のプロダクトＩＤ、バージョン情報、インストールされている場所を示す情報（例えば、パス名）等が含まれる。

管理サーバ３０は、機器情報を受信すると、当該機器情報を解析することにより、更新すべきモジュール（ＪＳＤＫプラットフォーム１４８やＪＳＤＫアプリ１４７等）を判定し、その判定結果に応じた内容で更新用データ３１０を生成する（Ｓ１０３）。例えば、複合機１０１にインストールされているアプリケーション１３１のうち、新たなバージョンのアプリケーションが管理サーバ３０に登録されている場合や、インストールされていないアプリケーション等がある場合には、それらのアプリケーションが更新用データ３１０に含められる。続いて、管理サーバ３０は、生成された更新用データ３１０を複合機１０１に送信する（Ｓ１０４）。複合機１０１のリモート更新用通信部１４８１は、更新用データ３１０を受信し、ＨＤＤ２３３又はメモリカード２３５に保存する。以下、更新用データ３１０が保存される記憶領域を「更新用データ保存領域」という。続いて、管理サーバ３０は、リブート（再起動）要求を複合機１０１に送信する（Ｓ１０５）。

複合機１０１は、管理サーバ１０からの要求に応じ、リブートを実行する（Ｓ１０６）。リブートの実行により電源が落とされ、続けて再起動を実行する過程において、複合機１０１は、更新用データ３１０に基づいて更新処理を実行する（Ｓ１０７）。但し、何らかのジョブが実行中である場合（例えば、コピー処理中等の場合）、リブートの実行は待機又は回避される。

更新処理が完了すると、複合機１０１は、更新処理の結果（更新処理の成否を示す情報）を管理サーバ３０に通知（送信）する（Ｓ１０８）。この際、更新処理に失敗した場合は、その原因を示す情報も送信される。管理サーバ３０側では、当該通知に基づいて、更新処理の成否を確認することができ、複合機１０１において動作しているプログラムのバージョン管理等を適切に行うことができる。

なお、更新処理の結果は、複合機１０１が能動的に送信しなくてもよい。例えば、管理サーバ３０が、リブート要求後にポーリングを行うことにより更新処理の結果を定期的に問い合わせ、複合機１０１は、その問い合わせに対して更新結果を応答するようにしてもよい。

なお、図４では、管理サーバ３０からの要求に応じて複合機１０１が機器情報を送信する例について説明したが、複合機１０１が能動的に管理サーバ３０に対して機器情報を送信し、それをトリガーとして、ステップS１０３以降の処理が実行されるようにしてもよい。

続いて、ステップＳ１０７において、リブートにより複合機１０１が再び起動する際に実行される処理について説明する。図５は、複合機の起動処理を説明するためのシーケンス図である。

複合機１０１の起動処理において、ＳＡＳ１８３は、少なくとも更新対象部分３２０より前にプロセス又はスレッドとして起動される。なお、更新対象データ３２０又は更新処理によって起動の可否に関して影響を受けるプログラムの中では、ＣＶＭ１９１→ＪＳＤＫプラットフォーム１４８→ＪＳＤＫアプリ１４７ａの順でプロセス又はスレッドとして起動される。但し、ＪＳＤＫアプリ１４７ａは、複合機１０１が起動する過程においては起動されず、当該アプリケーションの実行が指示された際に起動される。したがって、本実施の形態において、ＪＳＤＫプラットフォーム１４８は、更新処理によって起動の可否に関して影響を受けるプログラムの中で、更新処理に続いて起動されるプログラムのうち最後に起動されるプログラムに相当する。

ＳＡＳ１８３は、起動されると、更新用データ保存領域における更新用データ３１０の有無を確認する（Ｓ２０１）。更新用データ３１０が存在しない場合、ステップＳ２０２以降の更新処理は実行されず、通常の起動処理が実行される。更新用データ３１０が存在する場合、ＳＡＳ１８３は、更新用データ３１０を取得し、解凍する（Ｓ２０２）。以降の処理は、解凍された更新用データ３１０に含まれているスクリプトファイルの記述内容がスクリプトパーサ１８２によって解釈されることにより実行される。

まず、ＳＡＳ１８３は、状態ファイル４１０として、「ｐｈａｓｅ＿１」というファイル名のファイル（以下、「ｐｈａｓｅ＿ｘ」というファイル名のファイルを「ｐｈａｓｅ＿ｘファイル」という。）をＨＤＤ２３３又はメモリカード２３５における所定の記憶領域（以下「状態ファイル記録領域」という。）に作成する。

ここで、状態ファイル４１０とは、更新処理の進捗状況を記録及び識別するためのファイルであり、そのファイル名自体が更新処理の進捗状況の識別情報（進捗情報）となっている。したがって、ステップＳ２０３におけるｐｈａｓｅ＿１ファイルの作成は、これからフェーズ（段階）１の処理が開始されることが記録されたことを意味する。

続いて、ＳＡＳ１８３は、バックアップエリア４２０より、前回の更新処理において作成されたバックアップファイルを削除する（Ｓ２０４）。ここで、バックアップエリア４２０とは、更新対象とされるファイルが退避される記憶領域をいい、例えば、ＨＤＤ２３３又はメモリカード２３５が用いられる。また、バックファップファイルとは、バックアップエリア４２０に退避されたファイルをいう。

続いて、ＳＡＳ１８３は、今回の更新処理において更新対象とされるファイル（更新対象ファイル３２０ａ）をバックアップエリア４１０にコピーする（更新対象ファイル３２０ａの複製を生成する）ことによりバックアップを実行する（Ｓ２０５）。バックアップが正常に完了すると、ＳＡＳ１８３は、ｐｈａｓｅ＿２ファイルを状態ファイル４１０として作成し（Ｓ２０６）、続けてｐｈａｓｅ＿１ファイルが有る場合はｐｈａｓｅ＿１ファイルを削除する（Ｓ２０７）。ｐｈａｓｅ＿２ファイルが作成され、ｐｈａｓｅ＿１ファイルが削除されることで、フェーズ２の処理の開始と、フェーズ１の処理（更新対象ファイル３２０ａのバックアップ）の完了が記録されたことになる。

続いて、ＳＡＳ１８３は、更新処理によって上書きされる更新対象ファイル３２０ａを削除する（Ｓ２０８）。更新対象ファイル３２０ａの削除が正常に完了すると、ＳＡＳ１８３は、ｐｈａｓｅ＿３ファイルを状態ファイル４１０として作成し（Ｓ２０９）、続けてｐｈａｓｅ＿２ファイルが有る場合はｐｈａｓｅ＿２ファイルを削除する（Ｓ２１０）。ｐｈａｓｅ＿３ファイルが作成され、ｐｈａｓｅ＿２ファイルが削除されることで、フェーズ３の処理の開始と、フェーズ２の処理（更新対象ファイル３２０ａの削除）の完了が記録されたことになる。

続いて、ＳＡＳ１８３は、更新用データ保存領域に保存されている更新用データ３１０を対象パス（インストールされるべき位置）にコピーすることにより、更新用データ３１０に含まれるプログラムを起動対象として生成する（Ｓ２１１）。更新用データ３１０のコピーが正常に完了すると、ＳＡＳ１８３は、ｐｈａｓｅ＿４ファイルを状態ファイル４１０として作成し（Ｓ２１２）、続けてｐｈａｓｅ＿３ファイルが有る場合はｐｈａｓｅ＿３ファイルを削除する（Ｓ２１３）。ｐｈａｓｅ＿４ファイルが作成され、ｐｈａｓｅ＿３ファイルが削除されることで、フェーズ４の処理の開始と、フェーズ３の処理（更新用データ３１０のコピー）の完了が記録されたことになる。

続いて、ＳＡＳ１８３は、更新用データ保存領域より更新用データ３１０を削除する（Ｓ２１４）。更新用データ３１０の削除が正常に完了すると、ＳＡＳ１８３は、ｐｈａｓｅ＿５ファイルを状態ファイル４１０として作成し（Ｓ２１５）、続けてｐｈａｓｅ＿４ファイルが有る場合はｐｈａｓｅ＿４ファイルを削除する（Ｓ２１６）。ｐｈａｓｅ＿４ファイルが削除されることで、フェーズ４の処理（更新用データ３１０の削除）の完了が記録されたことになる。

本実施の形態では、フェーズ４の完了をもって更新処理は完了する。その後は通常の起動処理として、ＣＶＭ１９１→ＪＳＤＫプラットフォーム１４８の順でそれぞれのプロセス又はスレッドが起動される。ＪＳＤＫプラットフォーム１４８は、起動後、ｐｈａｓｅ＿５ファイルの存在を確認し、ｐｈａｓｅ＿５ファイルが存在する場合、ｐｈａｓｅ＿５ファイルを削除することで進捗情報を更新する（Ｓ２１７）。ここで、ｐｈａｓｅ＿５ファイルは、更新処理によって更新された、又は更新処理によって起動の可否に関して影響を受けるＣＶＭ１９１及びＪＳＤＫプラットフォーム１４８の双方が正常に起動されたときに初めて削除される。したがって、ｐｈａｓｅ＿５ファイルの削除は、ＣＶＭ１９１及びＪＳＤＫプラットフォーム１４８の双方が正常に起動されたことの記録を意味する。すなわち、ＪＳＤＫプラットフェーム１４８によって更新されたプログラムの起動の成否が判定され、その判定結果が記録される。

続いて、ＪＳＤＫプラットフォーム１４８は、バックアップエリア４２０に退避されているバックアップファイルを削除する（Ｓ２１８）。

なお、ＪＳＤＫプラットフォーム１４８は、起動に失敗した場合、その原因を示す情報を（プログラム内において発生した例外の内容等）をエラー情報ファイルに格納して、ＨＤＤ２３３に記録する。エラー情報ファイルは、図４のステップＳ１０８において、更新結果を示す情報として管理サーバ３０に送信される。管理サーバ３０側では、エラー情報ファイルの内容に基づいて、更新処理の失敗の原因を把握することができ、どのようにリトライすべきかを判断することができる。

ところで、更新処理中に、ユーザによって電源を切られた場合や、停電等が発生した場合は、当該更新処理は中断してしまう。かかる場合において、複合機１０１に再度電源が投入されたときの処理手順について説明する。図６は、更新処理が正常に終了しなかったときの複合機の再起動時の起動処理を説明するためのフローチャートである。

ＳＡＳ１８３は、起動されると、更新用データ保存領域における更新用データ３１０の有無を確認する（Ｓ３０１）。更新用データ３１０が存在しない場合（Ｓ３０２でＮｏ）、通常の起動処理が実行される（Ｓ３０７）。なお、ステップＳ３０１の処理は、図５におけるステップＳ２０１の処理に相当する。すなわち、ＳＡＳ１８３は、リブートによって複合機１０１が起動される際だけでなく、ユーザによって電源が投入される際にも複合機更新用データ３１０の存在を確認する。したがって、仮に図４のステップＳ１０６のリブート処理が回避された場合であっても、その後に電源が投入された際に、図５の処理は実行される。

更新用データ３１０が存在する場合（Ｓ３０２でＹｅｓ）、ＳＡＳ１８３は、状態ファイル記録領域における状態ファイル４１０の有無を確認する（Ｓ３０３）。状態ファイル記録領域にｐｈａｓｅ＿１ファイル〜ｐｈａｓｅ４ファイルまでのいずれかのファイルが存在する場合（Ｓ３０４でｐｈａｓｅ＿１〜ｐｈａｓｅ＿４）、更新処理は完了していないことになる。したがって、ＳＡＳ１８３は、残っている状態ファイル４１０のファイル名に応じて、図５の更新処理のうち実行されていない残りの処理を実行する（Ｓ３０５）。

より詳しくは、ｐｈａｓｅ＿１ファイルのみが残っている場合、ＳＡＳ１８３は、ステップＳ２０３以降の処理を実行する。ｐｈａｓｅ＿２ファイルのみが残っている場合、ＳＡＳ１８３は、ステップＳ２０８以降の処理を実行する。ｐｈａｓｅ＿２ファイルとｐｈａｓｅ＿１ファイルとが残っている場合、ＳＡＳ１８３は、ステップＳ２０７以降の処理を実行する。ｐｈａｓｅ＿３ファイルのみが残っている場合、ＳＡＳ１８３は、ステップＳ２１１以降の処理を実行する。ｐｈａｓｅ＿３ファイルとｐｈａｓｅ＿２ファイルとが残っている場合、ＳＡＳ１８３は、ステップＳ２１０以降の処理を実行する。ｐｈａｓｅ＿４ファイルのみが残っている場合、ＳＡＳ１８３は、ステップＳ２１４以降の処理を実行する。ｐｈａｓｅ＿４ファイルとｐｈａｓｅ＿３ファイルとが残っている場合、ＳＡＳ１８３は、ステップＳ２１３以降の処理を実行する。

また、ステップＳ３０４において、ｐｈａｓｅ＿５のファイルが存在する場合、更新処理は完了したが、何らかの原因（例えば、ファイル破壊、メモリ等のリソース不足等の発生等）によりＣＶＭ１９１又はＪＳＤＫプラットフォーム１４８の起動に失敗したことが考えられる。ｐｈａｓｅ＿５ファイルは、ＪＳＤＫプラットフォーム１４８の起動に成功したときに初めて削除されるからである。したがって、この場合、複合機１０１は、リカバリ処理を実行する（Ｓ３０６）。リカバリ処理の詳細については後述する。

更に、ステップＳ３０４において、いずれの状態ファイル４１０も存在しない場合、更新処理は正常に行われ、かつ、ＣＶＭ１９１及びＪＳＤＫプラットフォーム１４８も正常に起動されたことになる。したがって、この場合、複合機１０１は、通常の起動処理を実行する（Ｓ３０７）。

次に、図６のステップＳ３０７におけるリカバリ処理の詳細について説明する。図７は、リカバリ処理の処理手順を説明するためのシーケンス図である。

状態ファイル記録領域にｐｈａｓｅ＿５ファイルの存在を検出した場合、ＳＡＳ１８３は、バックアップエリア４２０に退避してあるバックアップファイルを復元する（Ｓ３７１）。すなわち、バックアップファイルを元の場所にコピーすることにより、更新対象データ３２０の状態を、更新処理の実行される前に戻し、更新前におけるプログラムを起動対象とする。

続いて、通常の起動処理として、ＣＶＭ１９１→ＪＳＤＫプラットフォーム１４８の順でそれぞれのプロセス又はスレッドが起動される。ここで、ＣＶＭ１９１及びＪＳＤＫプラットフォーム１４８等は、正常に起動されていた状態に復元されているため正常に起動される可能性が高い。ＪＳＤＫプラットフォーム１４８は、起動後、ｐｈａｓｅ＿５ファイルの存在を確認し（Ｓ３７２）、ｐｈａｓｅ＿５ファイルが存在する場合、ｐｈａｓｅ＿５ファイルを削除する（Ｓ３７３）。続いて、ＪＳＤＫプラットフォーム１４８は、バックアップエリア４２０におけるバックアップファイルを削除する（Ｓ３７３）。

上述したように、本実施の形態における複合機１０１によれば、状態ファイル４１０に基づいて更新処理の進捗状況を管理する。したがって、更新処理が何らかの理由により中断した場合であっても、電源の再投入時に実行できなかった処理を識別し、残りの処理を実行することができる。

また、複合機１０１は、ｐｈａｓｅ＿５ファイルに基づいてファイル破壊、リソース不足等によりＣＶＭ１９１やＪＳＤＫプラットフォーム１４８等が起動できなかったことを検出し、リカバリ処理を実行する。したがって、少なくとも更新処理が実行される前の状態での動作が可能となる。特に、本実施の形態において更新対象とされ得るプログラムは、アプリケーションの実行環境を提供（実現）するプログラムである。したがって、当該プログラムの状態が適切にリカバリされることにより、複合機１０１のアプリケーションが動作不能なってしまうといった致命的な事態の発生を回避することができる。

また、ＪＳＤＫプラットフォーム１４８は、リモート更新処理において管理サーバ３０との通信を行うリモート更新用通信部１４８１を含むプログラムである。したがって、ＪＳＤＫプラットフォーム１４８が起動できない場合、改めてリモート更新処理によって、更新用データ３１０を複合機１０１に送り込むことはできない。このように、本実施の形態における技術は、リモート更新処理によって通信機能を担う部分が更新対象となり得る場合に特に効果的であると言える。なお、リカバリ処理の要否の判断（すなわち、ｐｈａｓｅ＿５ファイルの存在のチェック）及びリカバ処理は、更新処理の実行後、複合機１０１の再起動時ではなく、更新処理の過程において、所定時間の経過後に行うようにしてもよい。

ところで、本実施の形態では、更新処理の進捗状況を管理するための情報として、状態ファイル４１０のファイル名を用いたが、進捗状況を管理するための情報は、必ずしも状態ファイル４１０のファイル名に限定されない。例えば、一つのファイル内に進捗状況を書き込んでもよい。但し、一つのファイルに進捗状況を逐次書き込むような方法は、進捗状況の書き込み中に電源が落とされた場合、当該ファイルが破壊されてしまい、再起動時において進捗状況が識別できなくなってしまう可能性がある。そこで、本実施の形態では、かかる事態の発生を回避するため、更新処理のフェーズの進行に応じて、常に次のフェーズの状態ファイル４１０を作成した後に、前のフェーズの状態ファイル４１０を削除するといった手順で進捗状況の管理を行っているのである。このような手順であれば、必ずしもファイルではなく、例えば、ＮＶＲＡＭ等の不揮発性のメモリに対してフェーズを示すフラグ情報を記録するようにしてもよい。

なお、状態ファイル４１０のファイル名に基づいて更新処理の進捗状況が把握され、状態ファイル４１０のファイル名の改竄による不正な複製等が実行されるのを防止するため、状態ファイル４１０のファイル名について、機体番号等に基づく暗号化を行うようにしてもよい。

また、本実施の形態では、更新対象とされるファイルの複製を生成することにより、更新前の状態のバックアップを行う例について説明したが、バックアップの方法はこれだけに限られない。例えば、更新対象とされるファイルと異なる記憶領域に更新後のファイル（プログラム）を生成することにより、実質的に更新前の状態をバックアップするようにしてもよい。すなわち、更新前のファイル（プログラム）が保存された状態において、更新処理が行われればよい。

ところで、上記実施の形態では、更新対象データ３２０に含まれるＪＳＤＫプラットフォーム１４８のリモート更新用通信部１４８１によって更新用データ３１０の受信等、管理サーバ３０との通信が行われる例を説明した。但し、管理サーバ３０との通信は、ＪＳＤＫプラットフォーム１４８とは別のプロセスとして起動されるプログラムによって実行されてもよい。

図８は、ＪＳＤＫプラットフォームとは別のプロセスによって管理サーバとの通信が行われる場合の画像形成装置に対する更新処理の概要を説明するためのブロック図である。図８では、ＪＳＤＫプラットフォームとは別プロセスであるＳＡＳ１８３が、管理サーバ３０との通信（更新データ３１０の受信等）を行う。したがって、ＪＳＤＫプラットフォーム１４８において、リモート更新用通信部１４８１は不要となる。

この場合、ＳＡＳ１８３は、更新用データ３１０の受信に応じて更新対象用データ３１０に含まれる各プログラムのプロセスを停止し、その状態において、スクリプトパーサ１８２によるスクリプトファイルの解釈に基づいて更新処理を実行する。更新処理の完了後、ＳＡＳ１８３は、停止したプロセスを再起動する。プロセスの再起動においてＪＳＤＫプラットフォーム１４８の起動に失敗したら、ＳＡＳ１８３は、ＪＳＤＫプラットフォーム１４８以前に起動されたプロセスを停止し、リカバリ処理を実行した後、改めて、各プロセスを起動する。

したがって、この場合、各プロセスが安全に停止できることが保証されれば、複合機１０１のリブート（管理サーバ３０からのリブート要求）は不要とすることができる。なお、更新処理専用のプログラム（プロセス）によって、図８におけるＳＡＳ１８３の機能を実現してもよい。

また、図８の形態において、バックアップファイルを複合機１０１内に保持するのではなく、管理サーバ３０に保持させるようにしてもよい。この場合、例えば、ＳＡＳ１８３が、バックアップファイルを管理サーバ３０に送信すればよい。

また、スクリプトパーサ１８２は、更新処理を実行するプログラム（本実施の形態では、ＳＡＳ１８３）のプラグインとして実装してもよい。プラグインとして実装することにより、スクリプトファイルの記述内容の仕様変更に対して柔軟に対応することができる。

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

３０ 管理サーバ
１０１ 複合機
１１１ ハードウェア
１１２ ソフトウェア
１１３ 複合機起動部
１２１ 撮像部
１２２ 印刷部
１２３ その他のハードウェア
１３１ アプリケーション
１３２ プラットフォーム
１３３ アプリケーションプログラムインタフェース
１３４ エンジンインタフェース
１３５ 仮想アプリケーションサービス
１４１ コピーアプリ
１４２ プリンタアプリ
１４３ スキャナアプリ
１４４ ファクシミリアプリ
１４５ ネットワークファイルアプリ
１４６ ＣＳＤＫアプリ
１４７ ＪＳＤＫアプリ
１４８ ＪＳＤＫプラットフォーム
１５１ コントロールサービス
１５２ システムリソースマネージャ
１５３ ハンドラ
１６１ ネットワークコントロールサービス
１６２ ファクシミリコントロールサービス
１６３ デリバリコントロールサービス
１６４ エンジンコントロールサービス
１６５ メモリコントロールサービス
１６６ オペレーションパネルコントロールサービス
１６７ サーティフィケーションコントロールサービス
１６８ ユーザディレクトリコントロールサービス
１６９ システムコントロールサービス
１７１ ファクシミリコントロールユニットハンドラ
１７２ イメージメモリハンドラ
１８２ スクリプトパーサ
１８３ ＳＤＫアプリケーションサービス
１９１ ＣＶＭ
１９２ ＪＮＩ
１９３ Ｎａｔｉｖｅ Ｌｉｂｒａｒｙ
２０１ コントローラ
２０２ オペレーションパネル
２０３ ファクシミリコントロールユニット
２１１ ＣＰＵ
２１２ ＡＳＩＣ
２２１ ＮＢ
２２２ ＳＢ
２３１ ＭＥＭ−Ｐ
２３２ ＭＥＭ−Ｃ
２３３ ＨＤＤ
２３４ メモリカードスロット
２３５ メモリカード
２４１ ＮＩＣ
２４２ ＵＳＢデバイス
２４３ ＩＥＥＥ１３９４デバイス
２４４ セントロニクスデバイス
１４８１ リモート更新用通信部

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

Claims (10)

1. プログラムを実行し前記プログラムを更新可能な機器であって、
   複数のプログラムのうちの少なくとも一つのプログラムを更新対象とする更新用データを外部装置より受信する受信手段と、
   前記更新用データに基づいて前記更新対象のプログラムの更新処理を実行する更新手段と、
   前記更新処理を構成する各段階の開始に応じ、当該段階の開始を示す第一の情報を記憶装置に記録し、前記更新処理の完了に応じ、前記更新処理の完了を示す第二の情報を前記記憶装置に記録する進捗情報記録手段と、
   前記更新処理の完了後、前記更新処理によって起動に失敗する可能性の有るプログラム中で、当該機器の起動過程において最後に起動されるプログラムが起動された場合に、前記第二の情報を削除する削除手段と、
   当該機器が起動されるときに、前記第二の情報が前記記憶装置に記録されている場合は、保存されている更新前のプログラムを起動対象とさせる復元手段とを有し、
   前記最後に起動されるプログラムが、当該機器を前記削除手段として機能させることを特徴とする機器。
2. 前記進捗情報記録手段は、開始される段階の開始を示す前記第一の情報を前記記憶装置に記録した後に、当該段階の前の段階の開始を示す前記第一の情報を前記記憶装置より削除することを特徴とする請求項１記載の機器。
3. 前記進捗情報記録手段は、前記更新処理を構成する各段階の開始に応じ、当該段階の識別情報をファイル名とするファイルを当該段階の開始を示す前記第一の情報として、前記記憶装置に記録する請求項１又は２記載の機器。
4. 前記更新手段による更新処理が中断された後、当該機器が再び起動されるときに、前記記憶装置に記録された前記第一の情報に基づいて、残りの更新処理を実行することを特徴とする請求項１乃至３いずれか一項記載の機器。
5. プログラムを実行し前記プログラムを更新可能な機器が実行するプログラム更新方法であって、
   複数のプログラムのうちの少なくとも一つのプログラムを更新対象とする更新用データを外部装置より受信する受信手順と、
   前記更新用データに基づいて前記プログラムの更新処理を実行する更新手順と、
   前記更新処理を構成する各段階の開始に応じ、当該段階の開始を示す第一の情報を記憶装置に記録し、前記更新処理の完了に応じ、前記更新処理の完了を示す第二の情報を前記記憶装置に記録する進捗情報記録手順と、
   前記更新処理の完了後、前記更新処理によって起動に失敗する可能性の有るプログラム中で、当該機器の起動過程において最後に起動されるプログラムが起動された場合に、前記第二の情報を削除する削除手順と、
   当該機器が起動されるときに、前記第二の情報が前記記憶装置に記録されている場合は、保存されている更新前のプログラムを起動対象とさせる復元手順とを有し、
   前記最後に起動されるプログラムが、当該機器に前記削除手順を実行させることを特徴とするプログラム更新方法。
6. 前記進捗情報記録手順は、開始される段階の開始を示す前記第一の情報を前記記憶装置に記録した後に、当該段階の前の段階の開始を示す前記第一の情報を前記記憶装置より削除することを特徴とする請求項５記載のプログラム更新方法。
7. 前記進捗情報記録手順は、前記更新処理を構成する各段階の開始に応じ、当該段階の識別情報をファイル名とするファイルを当該段階の開始を示す前記第一の情報として、前記記憶装置に記録する請求項５又は６記載のプログラム更新方法。
8. 前記更新手順による更新処理が中断された後、当該機器が再び起動されるときに、前記記憶装置に記録された前記第一の情報に基づいて、残りの前記更新処理を実行することを特徴とする請求項５乃至７いずれか一項記載のプログラム更新方法。
9. 請求項５乃至８いずれか一項記載のプログラム更新方法を前記機器に実行させるためのプログラム。
10. プログラムを実行し前記プログラムを更新可能な機器と、前記プログラムにネットワークを介して接続される情報処理装置とを含むプログラム更新システムであって、
    前記機器は、
    複数のプログラムのうちの少なくとも一つのプログラムを更新対象とする更新用データを外部装置より受信する受信手段と、
    前記更新用データに基づいて前記更新対象のプログラムの更新処理を実行する更新手段と、
    前記更新処理を構成する各段階の開始に応じ、当該段階の開始を示す第一の情報を記憶装置に記録し、前記更新処理の完了に応じ、前記更新処理の完了を示す第二の情報を前記記憶装置に記録する進捗情報記録手段と、
    前記更新処理の完了後、前記更新処理によって起動に失敗する可能性の有るプログラム中で、当該機器の起動過程において最後に起動されるプログラムが起動された場合に、前記第二の情報を削除する削除手段と、
    当該機器が起動されるときに、前記第二の情報が前記記憶装置に記録されている場合は、保存されている更新前のプログラムを起動対象とさせる復元手段とを有し、
    前記最後に起動されるプログラムが、当該機器を前記削除手段として機能させることを特徴とするプログラム更新システム。

Images