JP5418442B2 - 情報処理装置、電子機器、更新処理支援方法、更新処理支援プログラム、及び更新処理支援システム - Google Patents

Description

本発明は、情報処理装置、電子機器、更新処理支援方法、更新処理支援プログラム、及び更新処理支援システムに関し、特にプログラムの更新処理を支援する情報処理装置、電子機器、更新処理支援方法、更新処理支援プログラム、及び更新処理支援システムに関する。

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

他方において、一般的にアプリケーションは、バグ修正や機能拡張等に応じてバージョンアップが行われる。バージョンアップが行われた場合、当該アプリケーションがインストールされている画像形成装置には、当該アプリケーションの更新処理の実行が必要とされる。更新処理の実行後は、更新内容を有効にするため、画像形成装置の再起動が実行される。

しかしながら、実際のところ、全ての更新処理に関して画像形成装置の再起動が必要とされるわけではない。微小な更新であれば、再起動が必要とされない場合もある。

特に、アプリケーションをインストール可能な画像形成装置は、オフィス等において複数のユーザによって共用される。このような画像形成装置の再起動は、ユーザの業務に大きな影響を与えかねない。したがって、再起動の機会は、少なければ少ないほど望ましい。

本発明は、上記の点に鑑みてなされたものであって、プログラムの更新処理を効率化することのできる情報処理装置、電子機器、更新処理支援方法、更新処理支援プログラム、及び更新処理支援システムの提供を目的とする。

そこで上記課題を解決するため、本発明は、電子機器に対してインストール対象とされるプログラムのバージョンごとに、過去のバージョンからの更新時における前記電子機器の再起動の要否を示す再起動要否情報を記憶した再起動要否情報記憶手段と、前記電子機器にインストールされている第一のプログラムのバージョンが指定された、第二のプログラムの取得要求に応じ、前記第一のプログラムに対する前記第二のプログラムの差分情報を抽出する差分抽出手段と、前記差分情報に係るプログラムのバージョンの差分と前記再起動要否情報とに基づいて、前記第二のプログラムのインストールによる前記電子機器の再起動の要否を判定する判定手段と、前記判定手段による判定結果を返信する応答手段とを有する。

このような情報処理装置では、プログラムの更新処理を効率化することができる。

本発明によれば、プログラムの更新処理を効率化することができる。

第一の実施の形態におけるシステム構成例を示す図である。 本発明の実施の形態におけるプログラム管理サーバのハードウェア構成例を示す図である。 本発明の実施の形態における画像形成装置のハードウェア構成例を示す図である。 第一の実施の形態における画像形成装置及びプログラム管理サーバの機能構成例を示す図である。 第一の実施の形態の画像形成装置に対するアプリの更新処理の処理手順を説明するためのシーケンス図である。 インストール情報の例を示す図である。 再起動の要否の判定結果の例を示す図である。 プログラム管理サーバによる再起動要否の判定処理の処理手順を説明するためのフローチャートである。 取得対象のアプリの構成例を示す図である。 差分情報の例を示す図である。 再起動要否情報記憶部の構成例を示す図である。 差分コンポーネント情報の一例を示す図である。 第二の実施の形態におけるシステム構成例を示す図である。 第二の実施の形態の画像形成装置に対するアプリの更新処理の処理手順を説明するためのシーケンス図である。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、第一の実施の形態におけるシステム構成例を示す図である。同図において、一以上の画像形成装置２０とプログラム管理サーバ１０とは、ＬＡＮ（Local Area Network）又はインターネット等のネットワーク５０（有線又は無線の別は問わない。）を介して通信可能に接続されている。

画像形成装置２０は、電子機器の一例であり、例えば、複合機、コピー機、プリンタ、又はファクシミリ等である。但し、画像形成装置２０は、プログラムをインストール及び更新可能なものであれば、他の電子機器によって代替されてもよい。

プログラム管理サーバ１０は、画像形成装置２０にインストールされるプログラムを管理するコンピュータ（情報処理装置）である。例えば、プログラム管理サーバ１０は、画像形成装置２０からのプログラムの取得要求に応じ、取得対象のプログラムを含む応答を画像形成装置２０に返信する。

図２は、本発明の実施の形態におけるプログラム管理サーバのハードウェア構成例を示す図である。図２のプログラム管理サーバ１０は、それぞれバスBで相互に接続されているドライブ装置１００と、補助記憶装置１０２と、メモリ装置１０３と、ＣＰＵ１０４と、インタフェース装置１０５とを有する。

プログラム管理サーバ１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってプログラム管理サーバ１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

図３は、本発明の実施の形態における画像形成装置のハードウェア構成例を示す図である。図３において、画像形成装置２０は、コントローラ２１、スキャナ２２、プリンタ２３、モデム２４、操作パネル２５、ネットワークインタフェース２６、及びＳＤカードスロット２７等のハードウェアを有する。

コントローラ２１は、ＣＰＵ２１１、ＲＡＭ２１２、ＲＯＭ２１３、及びＨＤＤ２１４等を有する。ＲＯＭ２１３には、各種のプログラムやプログラムによって利用されるデータ等が記録されている。ＲＡＭ２１２は、プログラムをロードするための記憶領域や、ロードされたプログラムのワーク領域等として用いられる。ＣＰＵ２１１は、ＲＡＭ２１２にロードされたプログラムに基づいて、各種の機能を実現する。ＨＤＤ２１４には、プログラムやプログラムが利用する各種のデータ等が記録される。

スキャナ２２は、原稿より画像データを読み取るためのハードウェアである。プリンタ２３は、印刷データを印刷用紙に印刷するためのハードウェアである。モデム２４は、電話回線に接続するためのハードウェアであり、ＦＡＸ通信による画像データの送受信を実行するために用いられる。操作パネル２５は、ユーザからの入力の受け付けを行うためのボタン等の入力手段や、液晶パネル等の表示手段を備えたハードウェアである。ネットワークインタフェース２６は、ＬＡＮ等のネットワーク（有線又は無線の別は問わない。）に接続するためのハードウェアである。ＳＤカードスロット２７は、ＳＤカード８０に記録されたプログラムを読み取るために利用される。すなわち、画像形成装置２０では、ＲＯＭ２１３に記録されたプログラムだけでなく、ＳＤカード８０に記録されたプログラムもＲＡＭ２１２にロードされ、実行されうる。なお、他の記録媒体（例えば、ＣＤ−ＲＯＭ又はＵＳＢ（Universal Serial Bus）メモリ等）によってＳＤカード８０が代替されてもよい。すなわち、ＳＤカード８０の位置付けに相当する記録媒体の種類は、所定のものに限定されない。この場合、ＳＤカードスロット２７は、記録媒体の種類に応じたハードウェアによって代替されればよい。

図４は、第一の実施の形態における画像形成装置及びプログラム管理サーバの機能構成例を示す図である。

同図において、画像形成装置２０は、一以上のアプリ２２１、一以上のファームウェア２２２、更新制御部２２３、インストール情報記憶部２２４、及び更新ファイル一時記憶部２２５等を有する。各アプリ２２１は、それぞれ、操作パネル２５を介して入力される指示に応じたジョブを画像形成装置２０に実行させるプログラムである。各ファームウェア２２２は、アプリ２２１に比較して、原始的又は低レベルな機能を画像形成装置２０に実行させるプログラムである。なお、一つのアプリ２２１又は一つのファームウェア２２２は、一又は複数のプログラムコンポーネント（プログラムファイル）を含む、プログラム（プログラムコンポーネント）の集合体（プログラム集合体）として構成されうる。プログラムコンポーネントは、一般的にプログラムモジュールとも呼ばれるソフトウェア部品である。但し、単体で実行可能なプログラム（例えば、ＥＸＥファイル等）も、本実施の形態におけるプログラムコンポーネントの概念に含まれる。プログラムコンポーネントの一例として、ＪＡＲ（Java（登録商標） Archive）ファイルや、アプリ２２１又はファームウェア２２２に関する属性情報が記述された属性ファイル等が挙げられる。但し、プログラムコンポーネントの実装形態は、所定のものに限定されない。なお、プログラムコンポーネントは、相対的な概念であるともいえる。例えば、ＪＡＲは、それ自体、一以上のクラスファイルを含む。そうすると、ＪＡＲファイルから見れば、クラスファイルはプログラムコンポーネントであるともいえる。したがって、プログラムコンポーネントは、必ずしも、細分化不能な単位ではなく、階層構造を有していてもよい。すなわち、プログラムコンポーネントは、自身より下位のレベルのプログラムコンポーネントを包含していてもよい。

本実施の形態において、プログラム集合体は、流通単位である。すなわち、アプリ２２１又はファームウェア２２２の単位で、インストール、アンインストール、又は更新（バージョンアップ）等が行われる。但し、プログラム集合体に含まれる各プログラムコンポーネントは、それぞれ独立して、改変（バージョンアップ）されうる。したがって、同一のアプリ２２１又はファームウェア２２２に属する各プログラムコンポーネントのバージョン（バージョン番号）は相互に異なりうる。また、プログラムコンポーネントごとに、バージョンの番号体系（表現形式）が異なっていてもよい。なお、プログラムコンポーネントのバージョンアップに応じ、当該プログラムコンポーネントを含むプログラム集合体のバージョンも更新（バージョンアップ）される。

更新制御部２２３は、画像形成装置２０におけるアプリ２２１又はファームウェア２２２の更新処理（アップデート処理又は置換処理）を制御する。更新処理とは、古いバージョンを新しいバージョンによって置き換える処理をいう（但し、逆方向の更新が行われてもよい。）。本実施の形態において、更新処理は、インストールの一形態であると考える。すなわち、インストールの概念の中に、更新処理は含まれる。

なお、更新制御部２２３は、画像形成装置２０にインストールされたプログラムが、画像形成装置２０のＣＰＵ２１１に実行させる処理によって実現される仮想的な手段である。

インストール情報記憶部２２４は、画像形成装置２０にインストールされている各プログラムコンポーネントの属性情報を、ＨＤＤ２１４を用いて記憶する。すなわち、属性情報は、アプリ２２１又はファームウェア２２２等のプログラム集合体単位ではなく、プログラムコンポーネント単位で管理される。アプリ２２１又はファームウェア２２２間で、同一のプログラムコンポーネントを共用する場合があり、同一のプログラムコンポーネントに関する属性情報の重複管理を回避するためである。但し、アプリ２２１ごと及びファームウェア２２２ごとに、それぞれの属性情報及びそれぞれに属するプログラムコンポーネントの属性情報が、インストール情報記憶部２２４に記憶されてもよい。なお、当該属性情報には、アプリ２２１、ファームウェア２２２、又はプログラムコンポーネント（以下、それぞれを明確に区別しない場合、単に「プログラム」という。）のプロダクトＩＤ及びバージョン等を含む。プロダクトＩＤとは、プログラムの種別を示す識別情報である。すなわち、プログラムの実体ごとに異なる値ではなく、同一の種別のプログラムであれば同一のプロダクトＩＤが付与される。

更新ファイル一時記憶部２２５は、プログラム管理サーバ１０よりダウンロードされる更新ファイルを、ＨＤＤ２１４を用いて一時的に記憶する。更新ファイルとは、更新対象のアプリ２２１又はファームウェア２２２のプログラムコンポーネントが含まれているファイル（例えば、書庫ファイル）である。但し、更新ファイルは、一つのファイルとして形成されていなくてもよい。複数のプログラムコンポーネントのそれぞれのファイルの集合であってもよい。

プログラム管理サーバ１０は、要求受信部１１、差分抽出部１２、判定部１３、応答部１３、再起動要否情報記憶部１４、及びプログラム記憶部１５等を有する。

要求受信部１１は、更新対象とされるアプリ２２１又はファームウェア２２２の取得要求を画像形成装置２０より受信する。当該取得要求には、取得対象のアプリ２２１又はファームウェア２２２（プログラム集合体）のプロダクトＩＤ及びバージョンと、画像形成装置２０にインストールされているプログラムコンポーネントの属性情報の一覧が含まれる。

差分抽出部１２は、取得対象のプログラム集合体に含まれているプログラムコンポーネントについて、画像形成装置２０にインストールされているプログラムコンポーネントに対する差分情報を抽出する。差分情報には、例えば、取得対象のプログラム集合体に含まれているが画像形成装置２０にインストールされていないプログラムコンポーネントのプログラムＩＤ及びバージョンが含まれる。また、既に画像形成装置２０にインストールされているプログラムコンポーネントについて、取得対象のプログラム集合体に含まれるプログラムコンポーネントとバージョンが異なる場合は、当該プログラムコンポーネントのプログラムＩＤ及び双方のバージョンも差分情報に含まれる。双方のバージョンとは、画像形成装置２０にインストールされているバージョンと、取得対象のプログラム集合体に含まれているバージョンとを意味する。

判定部１３は、差分情報と再起動要否情報記憶部１４とに基づいて、取得対象とされたプログラム集合体の更新処理後（インストール後）における画像形成装置２０の再起動の要否を判定する。

応答部１３は、判定部１３による判定結果及び取得対象とされたプログラム集合体等を画像形成装置２０に返信する。

再起動要否情報記憶部１４は、プログラムコンポーネントのバージョンごとに、過去のバージョンからの更新時における画像形成装置２０の再起動の要否を示す情報を補助記憶装置１０２を用いて記憶する。

プログラム記憶部１５は、パッケージ化（例えば、書庫化）された状態のアプリ２２１又はファームウェア２２２の実体（ファイル）を、補助記憶装置１０２を用いて記憶する。但し、プログラムコンポーネントにばらされた状態が管理されていてもよい。この場合、ダウンロード対象とされたアプリ２２１又はファームウェア２２２に応じて、動的にアプル又はファームウェア２２２としてのパッケージ（プログラム集合体）が作成されればよい。

以下、画像形成装置２０及びプログラム管理サーバ１０の処理手順について説明する。なお、以下においては、便宜上、更新対象のプログラム集合体をアプリ２２１として説明する。但し、ファームウェア２２２が更新対象とされる場合も、基本的に処理手順に相違はない。

図５は、第一の実施の形態の画像形成装置に対するアプリの更新処理の処理手順を説明するためのシーケンス図である。同図の処理手順の実行の前提として、画像形成装置２０において、更新対象のアプリ２２１が操作パネル２５を介してユーザによって選択されていることとする。

ステップＳ１１において、画像形成装置２０の更新制御部２２３は、更新対象として選択されたアプリ２２１のプロダクトＩＤ及びバージョンを指定して、当該アプリ２２１の取得要求をプログラム管理サーバ１０に送信する。バージョンが指定されない場合は、最新版等、既定のバージョンが指定されたこととして扱われてもよい。また、当該取得要求には、インストール情報記憶部２２４に記録されている、画像形成装置２０にインストール済みのプログラムコンポーネントの属性情報の一覧（以下、「インストール情報」という。）も含まれる。

図６は、インストール情報の例を示す図である。同図に示されるように、インストール情報は、画像形成装置２０にインストールされているプログラムコンポーネントごとに、プロダクトＩＤ、バージョン、及びファイル名等の属性情報を含む。なお、ファイル名は、必須ではない。プロダクトＩＤによって各プログラムコンポーネントを識別することが可能だからである。但し、ファイル名によって各プログラムコンポーネントを識別する場合、プロダクトＩＤは必須ではない。

なお、取得対象のアプリ２２１が複数のプログラムコンポーネントを含む場合、当該取得要求は、複数のプログラム（プログラムコンポーネント）の取得要求に相当する。

当該取得要求は、プログラム管理サーバ１０の要求受信部１１によって受信される。プログラム管理サーバ１０は、当該取得要求において取得対象として指定されたアプリ２２１が画像形成装置２０において更新（インストール）された場合の、画像形成装置２０の再起動の要否等を判定する（Ｓ１２）。続いて、プログラム管理サーバ１０の応答部１３は、取得対象として指定されたアプリ２２１を含む更新ファイルと、再起動の要否の判定結果とを更新制御部２２３に返信する（Ｓ１３）。なお、当該アプリ２２１は、取得要求に指定されたプロダクトＩＤ及びバージョンに基づいて、プログラム記憶部１５より取得される。すなわち、プログラム記憶部１５には、プロダクトＩＤ及びバージョンに関連付けられて、アプリ２２１及びファームウェア２２２が記録されている。

更新制御部２２３は、プログラム管理サーバ１０からの応答を受信すると、当該応答に含まれている更新ファイルを更新ファイル一時記憶部２２５に保存する（Ｓ１４）。

続いて、更新制御部２２３は、プログラム管理サーバ１０からの応答に含まれている、再起動の要否の判定結果に基づいて、画像形成装置２０の再起動を実行するか否かを判定する。

図７は、再起動の要否の判定結果の例を示す図である。同図では、判定結果がＸＭＬ（eXtensible Markup Language）形式によって表現された例が示されている。すなわち、ｒｅｂｏｏｔ要素の値として判定結果が示されている。「ｔｒｕｅ」は、再起動は必要であることを示し、「ｆａｌｓｅ」は、再起動は不要であることを示す。なお、判定結果は、ＸＭＬ以外の形式によって表現されてもよい。

プログラム管理サーバ１０からの応答に含まれている判定結果が、再起動は必要であることを示す場合（再起動を要求するものである場合）、更新制御部２２３は、再起動の実行の許否を問い合わせる画面（以下、「再起動確認画面」という。）を操作パネル２５に表示させる。再起動確認画面において、再起動の拒否が選択された場合、更新制御部２２３は、図５の処理を終了させる。この場合、再起動及びアプリ２２１の更新処理は実行されない。したがって、ユーザは、更新対象のアプリ２２１について、更新前のバージョンの使用を継続することができる。すなわち、ユーザは、現在の画像形成装置２０の利用状況において、再起動が適切でない場合は再起動を拒否することにより、画像形成装置２０の利用の中断を強制されることなく、画像形成装置２０を利用して業務等を継続することができる。

再起動確認画面において、再起動の許可が選択された場合、更新制御部２２３は、画像形成装置２０を再起動（リブート）させる（Ｓ１５）。

画像形成装置２０が再び起動する過程において、更新制御部２２３は、更新ファイル一時記憶部２２５に更新ファイルが保存されているか否かを確認する。更新ファイルが保存されている場合、当該更新ファイルに含まれているアプリ２２１について、更新処理を実行する（Ｓ１６）。更新処理に成功した場合、更新制御部２２３は、更新ファイルを更新ファイル一時記憶部２２５より削除する。すなわち、更新ファイル一時記憶部２２５に更新ファイルの保存されている状態は、画像形成装置２０の起動時において、当該更新ファイルに基づいてアプリ２２１の更新処理が実行される必要があることを示す。したがって、再起動確認画面において、再起動の拒否が選択された場合であっても、次回の画像形成装置２０の起動時において、更新制御部２２３は、更新ファイル一時記憶部２２５に保存されている更新ファイルによって、アプリ２２１の更新処理を実行する。

一方、プログラム管理サーバ１０からの応答に含まれている判定結果が、再起動は不要であることを示す場合（再起動を要求しないものである場合）、更新制御部２２３は、再起動確認画面を表示させることなく、更新処理を実行する（Ｓ１６）。但し、直ちに更新処理を開始してよいか否かを問い合わせる画面（以下、「更新確認画面」という。）が操作パネル２５に表示されてもよい。更新確認画面において更新の開始の許可が選択された場合、更新制御部２２３は、直ちに更新処理を実行する。更新確認画面において更新の開始の拒否が選択された場合、更新制御部２２３は、更新処理は開始せずに図５の処理を終了させる。したがって、ユーザは、更新対象のアプリ２２１について、更新前のバージョンの使用を継続することができる。なお、更新の開始の拒否が選択された場合であっても、次回の画像形成装置２０の起動時には、更新制御部２２３によって自動的に更新処理が実行される。

続いて、ステップＳ１２において、プログラム管理サーバ１０によって実行される処理の詳細について説明する。

図８は、プログラム管理サーバによる再起動要否の判定処理の処理手順を説明するためのフローチャートである。

ステップＳ１２１において、差分抽出部１２は、取得要求に指定されたプロダクトＩＤ及びバージョンに対応するアプリ２２１を、プログラム記憶部１５より取得する。本実施の形態では、図９に示されるようなアプリ２２１ａが取得対象とされたこととする。

図９は、取得対象のアプリの構成例を示す図である。同図において、アプリ２２１ａは、ａａａ．ｊａｒ、ｂｂｂ．ｊａｒ、ｃｃｃ．ｊａｒ、及びｄｄｄ．ｊａｒ等のプログラムコンポーネントを含む。括弧内の番号は、それぞれのバージョンを示す。バージョンは、それぞれに付随する属性ファイルに記述されていてもよいし、それぞれのファイル名の一部に含まれていてもよい。また、アプリ２２１ａ及び各プログラムコンポーネントには、それぞれのプロダクトＩＤも付与されているが、便宜上、図示は省略されている。

なお、アプリ２２１ａが、図９に示される構成を有することは、アプリ２２１ａの書庫ファイルを開くことによって確認されてもよいし、アプリ２２１ごとに図９に示されるような構成情報が、補助記憶装置１０２に別途記録されており、当該構成情報を参照することにより確認されてもよい。

続いて、差分抽出部１２は、アプリ２２１ａに含まれるプログラムコンポーネントについて、インストール情報との差分を示す差分情報を抽出する（Ｓ１２２）。

図１０は、差分情報の例を示す図である。同図に示されるように差分情報は、アプリ２２１ａに含まれるプログラムコンポーネントのうち、画像形成装置２０に既にインストール済みのプログラムコンポーネントに対して差分となるプログラムコンポーネントについて、プログラムＩＤ、現バージョン、新バージョン、及びファイル名等を含む。

現バージョンは、画像形成装置２０に既にインストールされているバージョン（すなわち、インストール情報に含まれていたバージョン）である。なお、画像形成装置２０にインストールされていないプログラムコンポーネントについては、現バージョンの値は空（同図では、「−」で表記されている。）とされている。新バージョンは、アプリ２２１ａに含まれているバージョンである。

同図に示される差分情報は、図６に示されるインストール情報に対する、アプリ２２１ａ（図９）に関する差分情報である。図９を図６と比較すると、「ａａａ．ｊａｒ」及び「ｃｃｃ．ｊａｒ」については、双方のバージョンは一致し、差分はない。一方、「ｂｂｂ．ｊａｒ」については、バージョンが異なる。すなわち、インストール情報のバージョンは「１．２」であるのに対し、アプリ２２１ａに含まれるバージョンは「１．５」である。また、「ｄｄｄ．ｊａｒ」は、インストール情報に含まれていない（すなわち、画像形成装置２０にインストールされていない。）。したがって、「ｂｂｂ．ｊａｒ」及び「ｄｄｄ．ｊａｒ」が差分のプログラムコンポーネント（差分コンポーネント）として抽出され、当該差分コンポーネントに関する情報が差分情報として、図６に示されるように抽出される。

続いて、判定部１３は、抽出された差分情報と再起動要否情報記憶部１４とを用いて、差分コンポーネントごとに、更新処理による画像形成装置２０の再起動の要否を判定する（Ｓ１２３）。

図１１は、再起動要否情報記憶部の構成例を示す図である。同図において、再起動要否情報記憶部１４は、プログラム管理サーバ１０が管理している全てのプログラムコンポーネント（プロダクトＩＤ）について、バージョンごとに、直前バージョンからの更新時における、画像形成装置２０の再起動の要否を「１」又は「０」によって記憶する。「１」は、再起動要を示し、「０」は、再起動不要を示す。以下、再起動の要否を示す「１」又は「０」を、「再起動要否値」という。

例えば、ａａａ．ｊａｒについては、バージョン１．１には「０」が記録されており、バージョン１．２には「１」が記録されている。これは、バージョン１．０からバージョン１．１への更新時には再起動は不要であるが、バージョン１．１からバージョン１．２への更新時には再起動は必要であることを示す。

なお、最初のバージョン（同図では、「１．０」）に対する「１」又は「０」は、初期インストール時における再起動の要否を示す。

判定部１３は、差分コンポーネントごとに、差分情報（図１０）を再起動要否情報記憶部１４に記録されている情報（再起動要否情報）に当てはめて、再起動の要否を判定する。具体的には、ｂｂｂ．ｊａｒについては、バージョンが１．２から１．５に更新される。したがって、判定部１３は、ｂｂｂ．ｊａｒについて、バージョン１．２と１．５との差分に係る再起動要否値の論理和を算出する。具体的には、バージョン１．３、１．４、及び１．５の再起動要否値「１」、「１」、「０」の論理和として、「１」が算出される。また、判定部１３は、再起動要否情報のｄｄｄ．ｊａｒについて、バージョン１．２までの再起動要否値の論理和を算出する。具体的には、バージョン１．０、１．１、及び１．２の再起動要否値「１」、「０」、「０」の論理和として、「１」が算出される。

ここで、差分コンポーネントごとに算出された論理和は、当該差分コンポーネントの更新によって画像形成装置２０の再起動が必要か否かを示す情報である。すなわち、本実施の形態の再起動要否情報（図１１）は、直前のバージョンからの更新時のみならず、複数のバージョンを飛び越えた更新時における再起動の要否についても判定可能なように構成されている。

なお、図１１では、全てのプログラムコンポーネントに関する情報を一つのテーブルで管理する形態が示されているが、プログラムコンポーネントごと（すなわち、図１１の列ごと）に独立したテーブルが形成されてもよい。特に、プログラムコンポーネントごとにバージョン体系が異なる場合、プログラムコンポーネントごとに再起動要否情報が管理されるのが好適であると考える。

また、各プログラムコンポーネントの各バージョンについて、過去の各バージョンからの更新時の再起動の要否が管理されるようにしてもよい。具体的には、バージョン１．３については、バージョン１．２、１．１、及び１．０のそれぞれからの更新（バージョンアップ）時の再起動の要否が管理されてもよい。但し、この場合、情報量が膨大となる可能性がある。また、バージョンアップによる更新内容は累積的なものである傾向が強いことに鑑みれば、図１１に示されるように、直前のバージョンからの再起動の要否について管理し、複数のバージョンを跨いで（飛び越えて）更新が行われる場合は、その間の再起動要否値の論理和を算出することにより、再起動の要否が判定されるのが効率的である。

続いて、判定部１３は、差分コンポーネントごとに算出された全ての論理和の値の論理和を算出することにより、アプリ２２１ａの更新による再起動の要否を判定する（Ｓ１２４）。具体的には、ｂｂｂ．ｊａｒに対する「１」と、ｄｄｄ．ｊａｒに対する「１」との論理和として「１」が算出される。当該論理和が「１」であれば、画像形成装置２０の再起動は必要であると判定され、「０」であれば、画像形成装置２０の再起動は不要であると判定される。すなわち、少なくとも一つの差分コンポーネントについて再起動が必要であれば、再起動は必要であると判定される。

続いて、応答部１３は、判定部１３による判定結果（図７参照）及びアプリ２２１ａを含む応答を更新制御部２２３に返信する（Ｓ１２５）。当該応答には、図１２に示されるように、差分コンポーネントを示す情報（差分コンポーネント情報）が含められてもよい。

図１２は、差分コンポーネント情報の一例を示す図である。同図では、差分コンポーネント情報がＸＭＬ形式によって表現された例が示されている。

＜ｍｏｄｉｆｙ＞タグで囲まれた要素ｅ１は、更新対象の差分コンポーネントに関する情報を示す。すなわち、既に画像形成装置２０にインストールされているが、バージョンが更新される差分コンポーネントに関する情報である。本実施の形態では、「ｂｂｂ．ｊａｒ」が斯かる差分コンポーネントに該当する。

一方、＜ａｄｄ＞タグで囲まれた要素ｅ２は、新規追加対象のプログラムコンポーネントに関する情報を示す。すなわち、画像形成装置２０にインストールされていない差分コンポーネントに関する情報である。本実施の形態では、「ｄｄｄ．ｊａｒ」が斯かる差分コンポーネントに該当する。

なお、更新の場合と新規追加の場合とで、画像形成装置２０側の処理が変わらない場合、両者の区別は付けられなくてもよい。

また、新しいバージョンのアプリ２２１は、旧バージョンのアプリ２２１よりプログラムコンポーネントが少ない場合も考えられる。この場合、削除対象の差分コンポーネントが差分抽出部１２によって抽出される。削除対象の差分コンポーネントについては、例えば、＜ｄｅｌｅｔｅ＞タグによって囲まれる要素に、当該差分コンポーネントの情報を含めることにより、削除すべきことを画像形成装置２０に伝えればよい。

図１２に示される差分コンポーネント情報をアプリ２２１ａと共に受信した画像形成装置２０の更新制御部２２３は、アプリ２２１ａの更新処理において、更新対象を差分コンポーネントに限定する。すなわち、更新制御部２２３は、アプリ２２１ａに含まれる全てのプログラムコンポーネントについて更新処理（インストール処理）を実行するのではなく、現在の画像形成装置２０との差分に関して更新処理を限定する。そうすることにより、更新処理の効率化を図ることができる。

なお、プログラム管理サーバ１０の応答部１３は、アプリ２２１ａをそのまま返信するのではなく、アプリ２２１ａより差分コンポーネントを抽出して、返信対象を当該差分コンポーネントに限定してもよい。この場合、図１２に含まれる差分コンポーネント情報は必須ではない。返信対象が既に差分に限定されており、当該差分を画像形成装置２０が判断する必要はないからである。

上述したように、第一の実施の形態によれば、プログラムの更新に関して、画像形成装置２０の現在の状態と、更新後の状態との差分に応じて動的に再起動の要否が判定される。したがって、アプリ２２１の更新時に一律に再起動が行われる場合に比べて、再起動の機会を抑制することができる。その結果、画像形成装置２０の稼働率を高めることができ、ユーザに対する利便性を向上させることができる。

次に、第二の実施の形態について説明する。第二の実施の形態では、第一の実施の形態と異なる点について説明する。

図１３は、第二の実施の形態におけるシステム構成例を示す図である。図１３中、図１と同一部分には同一符号を付し、その説明は省略する。

同図では、機器管理装置３０が、ＬＡＮ等のネットワーク４０（有線又は無線の別は問わない）を介して、一以上の画像形成装置２０と接続されている。また、機器管理装置３０は、ネットワーク５０を介してプログラム管理サーバ１０と通信可能とされている。一方、画像形成装置２０はネットワーク５０から隠蔽されていてもよい。したがって、第二の実施の形態は、画像形成装置２０を直接的にインターネット等に晒したくない場合に好適であるともいえる。

機器管理装置３０は、画像形成装置２０におけるアプリ２２１の更新処理に関して、画像形成装置２０とプログラム管理サーバ１０との間を仲介するコンピュータである。また、機器管理装置３０は、第二の実施の形態における更新処理において、ユーザによる操作対象とされる。

以下、第二の実施の形態の処理手順について説明する。図１４は、第二の実施の形態の画像形成装置に対するアプリの更新処理の処理手順を説明するためのシーケンス図である。

機器管理装置３０に対して入力される操作指示によって、更新先の画像形成装置２０が選択されると、機器管理装置３０は、選択された画像形成装置２０に対してインストール情報の送信を要求する（Ｓ２０１）。画像形成装置２０の更新制御部２２３は、インストール情報記憶部２２４よりインストール情報を取得し、機器管理装置３０に返信する（Ｓ２０２）。

続いて、機器管理装置３０は、ユーザによって入力された、更新対象のアプリ２２１のプロダクトＩＤ及びバージョン情報と、画像形成装置２０より取得されたインストール情報とを指定して、当該アプリ２２１の取得要求をプログラム管理サーバ１０に送信する（Ｓ２０３）。

当該取得要求は、プログラム管理サーバ１０の要求受信部１１によって受信される。プログラム管理サーバ１０は、当該取得要求において取得対象として指定されたアプリ２２１が画像形成装置２０において更新（インストール）された場合の、画像形成装置２０の再起動の要否等を判定する（Ｓ２０４）。ステップＳ２０４の処理内容は、図８に説明したものと同様でよい。続いて、プログラム管理サーバ１０の応答部１３は、取得対象として指定されたアプリ２２１を含む更新ファイルと、再起動の要否の判定結果とを機器管理装置３０に返信する（Ｓ２０５）。

続いて、機器管理装置３０は、更新ファイルを画像形成装置２０に送信する（Ｓ２０６）。画像形成装置２０の更新制御部２２３は、受信された更新ファイルを更新ファイル一時記憶部２２５に保存する（Ｓ２０７）。

続いて、機器管理装置３０は、プログラム管理サーバ１０からの応答に含まれている、再起動の要否の判定結果に基づいて、画像形成装置２０の再起動を実行するか否かを判定する。判定結果が再起動は必要であることを示す場合、機器管理装置３０は、再起動確認画面を機器管理装置３０の表示部（ディスプレイ）に表示させる。再起動確認画面において、再起動の拒否が選択された場合、機器管理装置３０は、図１４の処理を終了させる。すなわち、この場合、再起動及びアプリ２２１の更新処理は実行されない。したがって、ユーザは、更新対象のアプリ２２１について、更新前のバージョンの使用を継続することができる。

再起動確認画面において、再起動の許可が選択された場合、機器管理装置３０は、画像形成装置２０に再起動の実行を要求する（Ｓ２０８）。再起動の実行要求に応じ、更新制御部２２３は、画像形成装置２０を再起動（リブート）させる（Ｓ２０９）。画像形成装置２０が再び起動する過程において、更新制御部２２３は、更新ファイル一時記憶部２２５に更新ファイルが保存されているか否かを確認する。更新ファイルが保存されている場合、当該更新ファイルに含まれているアプリ２２１について、更新処理を実行する（Ｓ２１１）。

一方、プログラム管理サーバ１０からの応答に含まれている判定結果が、再起動は不要であることを示す場合、機器管理装置３０は、再起動確認画面を表示させることなく、再起動要求の代わりに更新要求を画像形成装置２０に送信する（Ｓ２１０）。但し、更新確認画面が機器管理装置３０の表示部に表示されてもよい。更新確認画面において、更新の開始の許可が選択された場合、機器管理装置３０は、直ちに更新要求を送信する。更新確認画面において、更新の開始の拒否が選択された場合、機器管理装置３０は、更新要求を送信せずに図１４の処理を終了させる。

再起動要求又は更新要求を送信してから所定時間経過後、機器管理装置３０は、更新処理の結果を画像形成装置２０に問い合わせる（Ｓ２１２）。画像形成装置２０の更新制御部２２３は、更新処理の結果（成否を示す情報）を機器管理装置３０に返信する（Ｓ２１３）。機器管理装置３０は、更新処理の結果を表示部に表示させる。

上述したように、画像形成装置２０が直接的にプログラム管理サーバ１０と通信を行わない場合であっても、第一の実施の形態と同様の効果を得ることができる。換言すれば、プログラム管理サーバ１０の通信相手は、必ずしもアプリ２２１の更新先の画像形成装置２０でなくてもよい。

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

１０ プログラム管理サーバ
１１ 要求受信部
１２ 差分抽出部
１３ 判定部
１３ 応答部
１４ 再起動要否情報記憶部
１５ プログラム記憶部
２０ 画像形成装置
２１ コントローラ
２２ スキャナ
２３ プリンタ
２４ モデム
２５ 操作パネル
２６ ネットワークインタフェース
２７ ＳＤカードスロット
３０ 機器管理装置
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
２１１ ＣＰＵ
２１２ ＲＡＭ
２１３ ＲＯＭ
２１４ ＨＤＤ
２２１ アプリ
２２２ ファームウェア
２２３ 更新制御部
２２４ インストール情報記憶部
２２５ 更新ファイル一時記憶部
Ｂ バス

特開２００８−０８４３０４号公報

Claims (21)

1. 電子機器に対してインストール対象とされるプログラムのバージョンごとに、当該バージョンの直前のバージョンからの更新時における前記電子機器の再起動の要否を示す再起動要否情報を記憶した再起動要否情報記憶手段と、
   前記電子機器にインストールされている第一のプログラムのバージョンが指定された、第二のプログラムの取得要求に応じ、前記第一のプログラムに対する前記第二のプログラムの差分情報を抽出する差分抽出手段と、
   前記差分情報に係るプログラムのバージョンの差分と前記再起動要否情報とに基づいて、前記第二のプログラムのインストールによる前記電子機器の再起動の要否を判定する判定手段と、
   前記判定手段による判定結果を返信する応答手段とを有し、
   前記判定手段は、前記差分情報に係るプログラムのバージョンの差分に含まれるいずれかのバージョンに対して、再起動が必要であることを示す再起動要否情報が前記再起動要否情報記憶手段に記憶されている場合に、再起動が必要であると判定する情報処理装置。
2. 前記再起動要否情報は、複数のプログラムについて、バージョンごとに、過去のバージョンからの更新時における前記電子機器の再起動の要否を示し、
   前記差分抽出手段は、複数の前記第二のプログラムの取得要求に応じ、前記第一のプログラムに対する前記第二のプログラムの差分情報を抽出し、
   前記判定手段は、前記差分情報に係る複数のプログラムのバージョンの差分と前記再起動要否情報とに基づいて、少なくとも一つの前記第二のプログラムに関して再起動が必要であれば、前記複数の第二のプログラムのインストールによる前記電子機器の再起動は必要であると判定する請求項１記載の情報処理装置。
3. 前記応答手段は、前記判定結果と前記差分情報に係るプログラムに関する情報とを返信する請求項１又は２記載の情報処理装置。
4. 前記差分抽出手段は、複数のプログラムを含むプログラム集合体の取得要求に応じ、取得対象の前記プログラム集合体に含まれる複数の前記第二のプログラムの、前記第一のプログラムに対する差分情報を抽出し、
   前記判定手段は、前記差分情報に係る複数のプログラムのバージョンの差分と前記再起動要否情報とに基づいて、少なくとも一つの前記第二のプログラムに関して再起動が必要であれば、前記プログラム集合体のインストールによる前記電子機器の再起動は必要であると判定する請求項２又は３記載の情報処理装置。
5. 前記差分情報は、前記第二のプログラムに含まれるプログラムコンポーネントのうち、前記第一のプログラムに含まれるプログラムコンポーネントに対して差分となるプログラムコンポーネントに関する情報である請求項１乃至４いずれか一項記載の情報処理装置。
6. 請求項１乃至５いずれか一項記載の情報処理装置より返信される前記判定結果が再起動を要求しないものである場合は、前記取得要求において取得対象とされたプログラムの更新後に再起動を実行しない更新制御手段を有する電子機器。
7. コンピュータが実行する更新処理支援方法であって、
   電子機器にインストールされている第一のプログラムのバージョンが指定された、第二のプログラムの取得要求に応じ、前記第一のプログラムに対する前記第二のプログラムの差分情報を抽出する差分抽出手順と、
   前記差分情報に係るプログラムのバージョンの差分と、電子機器に対してインストール対象とされるプログラムのバージョンごとに、当該バージョンの直前のバージョンからの更新時における前記電子機器の再起動の要否を示す再起動要否情報を記憶した再起動要否情報記憶手段とに基づいて、前記第二のプログラムのインストールによる前記電子機器の再起動の要否を判定する判定手順と、
   前記判定手順における判定結果を返信する応答手順とを有し、
   前記判定手順は、前記差分情報に係るプログラムのバージョンの差分に含まれるいずれかのバージョンに対して、再起動が必要であることを示す再起動要否情報が前記再起動要否情報記憶手段に記憶されている場合に、再起動が必要であると判定する更新処理支援方法。
8. 前記再起動要否情報は、複数のプログラムについて、バージョンごとに、過去のバージョンからの更新時における前記電子機器の再起動の要否を示し、
   前記差分抽出手順は、複数の前記第二のプログラムの取得要求に応じ、前記第一のプログラムに対する前記第二のプログラムの差分情報を抽出し、
   前記判定手順は、前記差分情報に係る複数のプログラムのバージョンの差分と前記再起動要否情報とに基づいて、少なくとも一つの前記第二のプログラムに関して再起動が必要であれば、前記複数の第二のプログラムのインストールによる前記電子機器の再起動は必要であると判定する請求項７記載の更新処理支援方法。
9. 前記応答手順は、前記判定結果と前記差分情報に係るプログラムに関する情報とを返信する請求項７又は８記載の更新処理支援方法。
10. 前記差分抽出手順は、複数のプログラムを含むプログラム集合体の取得要求に応じ、取得対象の前記プログラム集合体に含まれる複数の前記第二のプログラムの、前記第一のプログラムに対する差分情報を抽出し、
    前記判定手順は、前記差分情報に係る複数のプログラムのバージョンの差分と前記再起動要否情報とに基づいて、少なくとも一つの前記第二のプログラムに関して再起動が必要であれば、前記プログラム集合体のインストールによる前記電子機器の再起動は必要であると判定する請求項８又は９記載の更新処理支援方法。
11. 前記差分情報は、前記第二のプログラムに含まれるプログラムコンポーネントのうち、前記第一のプログラムに含まれるプログラムコンポーネントに対して差分となるプログラムコンポーネントに関する情報である請求項７乃至１０いずれか一項記載の更新処理支援方法。
12. 請求項１乃至５いずれか一項記載の情報処理装置より返信される前記判定結果が再起動を要求しないものである場合は、前記取得要求において取得対象とされたプログラムの更新後に再起動を実行しない更新制御手順を電子機器が実行する更新処理支援方法。
13. コンピュータに、
    電子機器にインストールされている第一のプログラムのバージョンが指定された、第二のプログラムの取得要求に応じ、前記第一のプログラムに対する前記第二のプログラムの差分情報を抽出する差分抽出手順と、
    前記差分情報に係るプログラムのバージョンの差分と、電子機器に対してインストール対象とされるプログラムのバージョンごとに、当該バージョンの直前のバージョンからの更新時における前記電子機器の再起動の要否を示す再起動要否情報を記憶した再起動要否情報記憶手段とに基づいて、前記第二のプログラムのインストールによる前記電子機器の再起動の要否を判定する判定手順と、
    前記判定手順における判定結果を返信する応答手順とを実行させ、
    前記判定手順は、前記差分情報に係るプログラムのバージョンの差分に含まれるいずれかのバージョンに対して、再起動が必要であることを示す再起動要否情報が前記再起動要否情報記憶手段に記憶されている場合に、再起動が必要であると判定する更新処理支援プログラム。
14. 前記再起動要否情報は、複数のプログラムについて、バージョンごとに、過去のバージョンからの更新時における前記電子機器の再起動の要否を示し、
    前記差分抽出手順は、複数の前記第二のプログラムの取得要求に応じ、前記第一のプログラムに対する前記第二のプログラムの差分情報を抽出し、
    前記判定手順は、前記差分情報に係る複数のプログラムのバージョンの差分と前記再起動要否情報とに基づいて、少なくとも一つの前記第二のプログラムに関して再起動が必要であれば、前記複数の第二のプログラムのインストールによる前記電子機器の再起動は必要であると判定する請求項１３記載の更新処理支援プログラム。
15. 前記応答手順は、前記判定結果と前記差分情報に係るプログラムに関する情報とを返信する請求項１３又は１４記載の更新処理支援プログラム。
16. 前記差分抽出手順は、複数のプログラムを含むプログラム集合体の取得要求に応じ、取得対象の前記プログラム集合体に含まれる複数の前記第二のプログラムの、前記第一のプログラムに対する差分情報を抽出し、
    前記判定手順は、前記差分情報に係る複数のプログラムのバージョンの差分と前記再起動要否情報とに基づいて、少なくとも一つの前記第二のプログラムに関して再起動が必要であれば、前記プログラム集合体のインストールによる前記電子機器の再起動は必要であると判定する請求項１４又は１５記載の更新処理支援プログラム。
17. 前記差分情報は、前記第二のプログラムに含まれるプログラムコンポーネントのうち、前記第一のプログラムに含まれるプログラムコンポーネントに対して差分となるプログラムコンポーネントに関する情報である請求項１３乃至１６いずれか一項記載の更新処理支援プログラム。
18. 請求項１乃至５いずれか一項記載の情報処理装置より返信される前記判定結果が再起動を要求しないものである場合は、前記取得要求において取得対象とされたプログラムの更新後に再起動を実行しない更新制御手順を電子機器に実行させる更新処理支援プログラム。
19. 電子機器に対してインストール対象とされるプログラムのバージョンごとに、当該バージョンの直前のバージョンからの更新時における前記電子機器の再起動の要否を示す再起動要否情報を記憶した再起動要否情報記憶手段と、
    前記電子機器にインストールされている第一のプログラムのバージョンが指定された、第二のプログラムの取得要求に応じ、前記第一のプログラムに対する前記第二のプログラムの差分情報を抽出する差分抽出手段と、
    前記差分情報に係るプログラムのバージョンの差分と前記再起動要否情報とに基づいて、前記第二のプログラムのインストールによる前記電子機器の再起動の要否を判定する判定手段と、
    前記判定手段による判定結果を返信する応答手段とを有し、
    前記判定手段は、前記差分情報に係るプログラムのバージョンの差分に含まれるいずれかのバージョンに対して、再起動が必要であることを示す再起動要否情報が前記再起動要否情報記憶手段に記憶されている場合に、再起動が必要であると判定する情報処理装置と、
    前記情報処理装置より返信される前記判定結果が再起動を要求しないものである場合は、前記取得要求において取得対象とされたプログラムの更新後に再起動を実行しない更新制御手段を有する電子機器とを有する更新処理支援システム。
20. 前記再起動要否情報は、複数のプログラムについて、バージョンごとに、過去のバージョンからの更新時における前記電子機器の再起動の要否を示し、
    前記差分抽出手段は、複数の前記第二のプログラムの取得要求に応じ、前記第一のプログラムに対する前記第二のプログラムの差分情報を抽出し、
    前記判定手段は、前記差分情報に係る複数のプログラムのバージョンの差分と前記再起動要否情報とに基づいて、少なくとも一つの前記第二のプログラムに関して再起動が必要であれば、前記複数の第二のプログラムのインストールによる前記電子機器の再起動は必要であると判定する請求項１９記載の更新処理支援システム。
21. 前記差分情報は、前記第二のプログラムに含まれるプログラムコンポーネントのうち、前記第一のプログラムに含まれるプログラムコンポーネントに対して差分となるプログラムコンポーネントに関する情報である請求項１９又は２０記載の更新処理支援システム。
    

Images