JP2013142914A - 情報処理装置 - Google Patents

Abstract

【課題】データセットの更新処理が中断された場合でも、自動的にその状態を認識して、それを踏まえた適切な更新処理を行えるようにする。
【解決手段】 バージョン情報を含むデータセットを記憶部１０３に記憶する情報処理装置において、バージョン通知部１０６がそのデータセットのバージョン情報を更新制御部１１０に通知し（Ｂ８）、更新制御部１１０が、その通知されたバージョン情報と更新用データセットのバージョン情報とに基づきデータセットの更新が必要であると判断した場合に、記憶部１０３に記憶するデータセットを更新するようにした。この場合において、バージョン通知部１０６は、記憶部１０３に記憶しているデータセットの更新が完了していない状態である場合には、上記データセットのバージョン情報に代えて、更新が完了していないことを示すバージョン情報を更新制御部１１０に通知するようにした。
【選択図】 図５

Description

この発明は、記憶手段に記憶しているデータセットを更新する情報処理装置に関する。

従来から、情報処理装置が記憶するファームウェア等のデータセットを随時更新（アップデート）することが行われている。
また、ひとつの情報処理装置が複数のＣＰＵを持つ複数のシステムから構成されている場合には、装置内に複数のファームウェアが存在する。このような装置については、ファームウェアを個別にアップデートした結果不適正な組み合わせで装置に記憶されてしまい、装置の動作に不具合を生じることを防止するため、また、ファームウェアの更新を効率的に行うため、装置内の複数のファームウェアを一括して更新する技術が知られている。

さらに、特許文献１には、このように複数のファームウェアを一括して更新する場合において、ファームウェアの更新にかかる時間を短縮するため、更新用のファームウェアのバージョンと、情報処理装置に記憶されているファームウェアのバージョンとをファームウェア毎に比較し、更新用の方が新しいバージョンであるファームウェアのみについて更新を実行することが記載されている。

ところで、ファームウェアのバージョンの情報を、ファームウェア自体の一部としてファームウェアに持たせることが行われている。この場合、ファームウェアの更新中の電源切断等により突然更新が中断してしまうと、ファームウェアの更新は終了していないにも関わらず、バージョン情報の部分は更新用のファームウェア（すなわち新しいバージョン情報）が既にメモリに書き込まれてしまっている場合がある。

このような事態が発生した場合、再度の電源投入時にファームウェアのバージョンをチェックしても、新しいバージョン情報が記録されてしまっているため、バージョン情報の比較時に更新不要と判断してしまい、正常に更新を完了できなくなってしまうという問題があった。
引用文献１に記載の技術を適用しても、このような問題を解決することはできない。また、このような問題は、ファームウェア以外のデータセットを更新する場合であっても、さらには、更新すべきデータセットが１つのみの場合であっても、同様に発生するものである。

この発明は、このような問題を解決するためになされたものであり、自身のバージョン情報を含むデータセットの更新要否を、そのバージョン情報を確認することにより判断して更新する情報処理装置において、更新処理が中断された場合でも、自動的にその状態を認識して、それを踏まえた適切な更新処理を行えるようにすることを目的とする。

上記目的を達成するため、この発明の情報処理装置は、データセットであってそのデータセットのバージョン情報を含むものを記憶する記憶手段と、更新用データセットであってその更新用データセットのバージョン情報を含むものを取得する取得手段と、上記記憶手段が記憶しているデータセットのバージョン情報を提供する提供手段と、上記取得手段が取得した更新用データセットのバージョン情報と上記提供手段が提供するバージョン情報とに基づき更新が必要であると判断した場合に上記記憶手段に記憶しているデータセットを上記更新用データセットに更新する更新手段と、上記更新手段によるデータセットの更新が完了している状態であるか否か判断する判断手段とを備え、上記提供手段は、上記判断手段が、上記データセットの更新が完了していない状態であると判断した場合には、上記記憶手段が記憶しているデータセットのバージョン情報に代えて、更新が完了していないことを示すバージョン情報を提供する手段としたものである。

以上のような構成によれば、自身のバージョン情報を含むデータセットの更新要否を、そのバージョン情報を確認することにより判断して更新する情報処理装置において、更新処理が中断された場合でも、自動的にその状態を認識して、それを踏まえた適切な更新処理を行えるようにすることができる。

この発明の一実施形態である情報処理装置のハードウェア構成を示す図である。 図１に示した情報処理装置に記憶させるファームウェアのデータ形式及び更新方式を示す図である。 図１に示した情報処理装置の機能構成を示す図である。 ファームウェアの更新に用いる更新用データの構成例を示す図である。 図１に示した情報処理装置が第１動作例において更新用データの取得に応じて各サブシステムのファームウェアを更新する動作の手順を示す図である。 その続きを示す図である。 第１動作例においてデータ書き込み部が実行する更新用ファームウェアの書き込み処理のフローチャートである。 同じくバージョン通知部が更新開始通知の受信に応じて実行する処理のフローチャートである。 同じくサブシステム更新完了判断部が更新状態問い合わせの受信に応じて実行する処理のフローチャートである。 同じく更新制御部がバージョン情報通知の受信に応じて実行する処理のフローチャートである。 第２動作例におけるファームウェア更新処理のシーケンスを示す図である。 図１に示した情報処理装置が第２動作例において起動時に実行する動作の手順を示す図である。 第２動作例において情報処理装置の起動時に更新制御部が実行する処理のフローチャートである。 図１に示した情報処理装置が第３動作例において起動時に実行する動作の手順を示す図である。 図１に示した情報処理装置が第４動作例において実行する動作の手順を示す図である。 第４動作例における機能利用可否判断部による機能利用要求の実行可否制御処理のフローチャートである。 機能利用可否判断部が図１６の処理で参照するデータの例を示す図である。 その別のデータの例を示す図である。 第５動作例において更新制御部が実行する処理のフローチャートである。 図１に示した情報処理装置が第６動作例において実行する動作の手順を示す図である。 更新の失敗したサブシステムと対応するＬＥＤの点灯制御例を示す図である。 図１に示した情報処理装置が第７動作例において実行する動作の手順を示す図である。 更新結果通知のメッセージの例を示す図である。 ファームウェア更新の進捗状況を示すデータの例を示す図である。 ファームウェア更新の再開位置について説明するための図である。

以下、この発明を実施するための形態を図面に基づいて具体的に説明する。
まず、図１に、この発明の一実施形態である情報処理装置のハードウェア構成を示す。
図１に示す情報処理装置１は、第１サブシステム１０と第２サブシステム２０の２つのサブシステムを備え、これらが連携して動作する。第１サブシステム１０は、ユーザからの操作受付や、表示装置による画面の表示を主に担当する。第２サブシステム２０は、ネットワークを介した外部装置との通信を主に担当する。また、これらのサブシステム及び図１に示す各ハードウェアは、システムバス３０により接続されている。
そして、第１サブシステム１０は、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、記憶媒体Ｉ／Ｆ１４、表示装置１５、入力装置１６を備える。

これらのうちＣＰＵ１１は、第１サブシステム１０を制御する制御手段であり、ＲＯＭ１２に記憶された種々のプログラムを実行することにより、図３等に示すものを始めとする種々の機能を実現する。このプログラムには、更新可能なファームウェアが含まれるが、そのファームウェアによらなくても、入力装置１６からの操作検出や、第２サブシステム２０との通信など、ごく基本的な動作は実行可能である。また、後述するファームウェアの更新に関する動作も実行可能である。また、情報処理装置１においては第１サブシステム１０が装置全体の制御も担い、ＣＰＵ１１はその制御のための機能も備える。

ＲＯＭ１２は、ＣＰＵ１１が実行するプログラムや固定的なパラメータ等を記憶する書き換え可能な不揮発性記憶手段である。
ＲＡＭ１３は、一時的に使用するデータを記憶したり、ＣＰＵ１１のワークメモリとして使用したりする記憶手段である。
記憶媒体Ｉ／Ｆ１４は、着脱可能な外部記憶媒体に対するデータの入出力を行うためのインタフェースである。例えばＵＳＢ（Universal Serial Bus）メモリや、メモリカード等に対応したインタフェースを設けることが考えられる。

表示装置１５は、ユーザにメッセージやＧＵＩ(Graphical User Interface)等を表示したり、装置の動作状況を知らせたりするためのディスプレイやランプ等の表示手段である。
入力装置１６は、ユーザからの操作を受け付けるためのスイッチ、ボタン、タッチパネル等の操作子である。

また、第２サブシステム２０は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、記憶媒体Ｉ／Ｆ２４、ネットワークＩ／Ｆ２５を備える。
これらのうちＣＰＵ２１は、第２サブシステム２０を制御する制御手段であり、ＲＯＭ２２に記憶された種々のプログラムを実行することにより、図３等に示すものを始めとする種々の機能を実現する。このプログラムには、更新可能なファームウェアが含まれるが、そのファームウェアによらなくても、ネットワークＩ／Ｆ２５を介した単純なプロトコルでの通信や、第１サブシステム１０との通信など、ごく基本的な動作は実行可能である。また、後述するファームウェアの更新に関する動作も実行可能である。

ＲＯＭ２２は、ＣＰＵ２１が実行するプログラムや固定的なパラメータ等を記憶する書き換え可能な不揮発性記憶手段である。
ＲＡＭ２３は、一時的に使用するデータを記憶したり、ＣＰＵ２１のワークメモリとして使用したりする記憶手段である。
記憶媒体Ｉ／Ｆ２４は、記憶媒体Ｉ／Ｆ１４と同様なインタフェースであるが、対応する規格が同じである必要はない。

ネットワークＩ／Ｆ２５は、ＬＡＮ（ローカルエリアネットワーク）等のネットワークを介して外部の装置と通信を行うためのインタフェースであり、通信手段である。通信に用いるプロトコルや対応する通信規格は、有線、無線を問わず、任意のものでよい。また、ピアツーピア型の通信を行う手段であってもよい。

以上の情報処理装置は、入力装置１６により受け付けたユーザの操作に従ってあるいは自動的に外部装置と通信し、あるいは記憶媒体Ｉ／Ｆ１４，２４に接続される記憶媒体に対してデータを読み書きし、その結果を表示装置１５に表示することができる。
また、これ以外にも外部に対して物理的な入出力を行う手段を設けてもよい。例えば、画像データに基づいて用紙に画像を形成するプリントエンジンや、画像データを読み取るスキャナエンジンや、画像データに基づいてスクリーンに画像を投影する投影装置等である。これらの入出力手段の制御も、いずれかのサブシステムのＣＰＵが行う。

以上のような情報処理装置１において特徴的な点の一つは、ＲＯＭ１２及びＲＯＭ２２に記憶させるファームウェアの更新に関する機能である。以下、この点について説明する。
ここで、図２に、ＲＯＭ１２及びＲＯＭ２２に記憶させるファームウェアのデータ形式及び更新方式を示す。

情報処理装置１においては、上述したように、ＲＯＭ１２に第１のサブシステム１０で使用するファームウェアを、ＲＯＭ２２に第２のサブシステム２０で使用するフェームウェアを記憶させる。このファームウェアは、ＲＯＭ上に確保した所定の記憶領域に記憶させる。また、（ａ）に示すように、ファームウェアのデータは、そのファームウェア自身のバージョンを示すバージョン情報を含むひとかたまりのデータとして構成される。
そして、ファームウェアを新しいものに更新する場合、（ｂ）に示すように、新しいファームウェアのデータを、それまでのファームウェアのデータに上書き保存する。ただし、サイズが一致している必要はなく、一方が他方からはみ出してもよい。

ところで、ファームウェアのバージョン情報は、既に記憶されたファームウェアと、更新用のファームウェアとでバージョンを比較し、更新の要否を判断するために用いる。更新用のものの方が新しいバージョンである場合に更新する等である。古いバージョンにバージョンダウンできるようにすることも考えられる。

そして、この用途に用いるためには、ファームウェアデータ中からバージョン情報を容易に探索して読み出せるようにすることが好ましい。そこで、バージョン情報のデータは、ファームウェアのデータ中の初めの方に配置している。従って、ファームウェアの更新途中で不意の電源遮断等により更新が中断された場合、（ｂ）に示すように、更新が完了していないにも関わらず、バージョン情報の部分は新しいデータが上書きされ、最新の値になってしまうことが考えられる。
そして、この状態でファームウェアのバージョンを参照すると、最新のバージョンであると認識してしまうこととなり、それに基づいて更新不要と判断してしまうことになる。

しかし、この実施形態においては、更新要否を判断するモジュールにファームウェアのバージョン情報を提供する際に、ファームウェアの更新が正常に完了しているか（中断された状態でないか）否かを判断し、更新が完了していない状態である場合には、そのことを示すため、通常では使われることのないバージョン情報を提供するようにしている。
従って、更新要否を判断する際に、実際に記憶手段に記憶されているバージョン情報に関わらず、更新の中断されたファームウェアについて、再度更新を行う必要がある状態であることが認識できる。

次に、図３に、この機能を実現するための情報処理装置１の機能構成を示す。ただし、図４以降で説明する各動作を実現するために、図３に示す全ての機能が必須であるわけではない。
情報処理装置１は、図３に示すように、第１サブシステム１０が、サブシステム通信部１０１、データ書き込み部１０２、記憶部１０３、本体通知部１０４、起動部１０５、バージョン通知部１０６、サブシステム更新完了判断部１０７、更新入力部１０８、全システム更新完了判断部１０９、更新制御部１１０、自動更新部１１１、機能利用可否判断部１１２を備え、第２サブシステム２０が、サブシステム通信部２０１、データ書き込み部２０２、記憶部２０３、ネットワーク通知部２０４、起動部２０５、バージョン通知部２０６、サブシステム更新完了判断部２０７を備える。

なお、図３に示す各部の機能は、ＣＰＵ１１又はＣＰＵ２１が所要のプログラムを実行して情報処理装置１の各部を制御することにより実現されるものである。ただし、これらの各部の機能を実現するためのプログラムは、これらの各部の機能による更新の対象とはしていない。従って、これらの各部により更新するファームウェアが使えなくても、これらの各部の動作に特段の影響はない。
上記の各部のうち、第１サブシステム１０のサブシステム通信部１０１は、サブシステム間のデータ転送を行う機能を有する通信手段であり、他のサブシステムのサブシステム通信部との間で、各種の要求、応答及び更新用ファームウェア等のデータを送受信することができる。

データ書き込み部１０２は、記憶部１０３に対する更新用ファームウェアの書き込みを行う機能を有する書込手段である。
記憶部１０３は、第１サブシステム１０のＣＰＵ１１が実行するファームウェア及び、ファームウェアの更新制御に用いる各種データを記憶する機能を有する記憶手段である。記憶部１０３が記憶するデータは、情報処理装置１の電源がＯＦＦの状態でも保存される。

本体通知部１０４は、表示装置１５を制御して、ファームウェアの更新結果をユーザに通知する機能を有する通知手段である。
起動部１０５は、記憶部１０３に記憶しているファームウェアの起動を行う機能を有する起動手段である。また、ファームウェアの起動を禁止する機能も有する。

バージョン通知部１０６は、記憶部１０３に記憶しているファームウェアのバージョン情報を、更新制御部１１０をはじめとする各部に提供する提供手段である。ただし、必ずしも記憶部１０３から読み出したバージョン情報を提供するわけではないことは、上述の通りである。
サブシステム更新完了判断部１０７は、第１サブシステム１０におけるファームウェアの更新が完了している状態であるか否かを判断する機能を有する判断手段である。その判断手法については後述する。

更新入力部１０８は、更新用ファームウェアのデータや、ファームウェア更新指示等、ファームウェアの更新に関係するデータの入力を受け付ける機能を有する入力手段である。
全システム更新完了判断部１０９は、情報処理装置１の全てのサブシステムにおけるファームウェアの更新が完了している状態であるか否かを判断する機能を有する判断手段である。その判断手法については後述する。

更新制御部１１０は、情報処理装置１全体におけるファームウェアの更新処理の管理を行う機能を有する更新手段である。更新制御部１１０は、各部から、更新処理の進行や更新要否の判断に必要な情報を収集し、収集した情報に基づいて、各部に更新に必要な動作を要求する機能を有する。
自動更新部１１１は、ファームウェアの自動更新に関する制御を行う機能を有する。

機能利用可否判断部１１２は、ファームウェアの更新の状態に基づき、情報処理装置１に対する動作要求（ユーザの指示に基づくものも、外部装置からの要求に基づくものも、情報処理装置１が内部で自動的に生成するものもある）に応じた動作の実行可否を判断し、実行不能なものは実行させずにその旨を要求元に通知する機能を有する。例えば、あるサブシステムでファームウェアの更新が中断された状態である場合、そのサブシステムの機能を利用する動作は実行不能と判断することができる。

以上の各部のうち、全システム更新完了判断部１０９、更新制御部１１０、及び自動更新部１１１は、情報処理装置１が備える複数のサブシステムのうち１つのみに設け、全サブシステムにおけるファームウェアの更新に関与させる。ここでは、全体の制御を担う第１サブシステム１０に設けたものである。
サブシステム通信部１０１、データ書き込み部１０２、記憶部１０３、起動部１０５、バージョン通知部１０６、サブシステム更新完了判断部１０７は、サブシステム毎に設ける。第２サブシステム２０に設けたこれらと同名の各部は、第１サブシステム１０における各部と同様な機能を有する。

本体通知部１０４、更新入力部１０８及び機能利用可否判断部１１２については、表示装置１５を制御する機能、ファームウェアの更新用データの入力を受け付ける機能、および動作要求を受け付ける機能を第１サブシステム１０に設けたことに伴いここに設けたものである。しかし、これらの機能を他のサブシステムに設けたり、複数のサブシステムに分散させて設けたりするのであれば、それに応じてこれら各部をそのサブシステムに設ければよい。

また、第２サブシステム２０のネットワーク通知部２０４は、ファームウェアの更新結果をネットワークを介してユーザに通知する機能を有する通知手段である。ネットワークＩ／Ｆ２５を制御する機能を第２サブシステム２０に設けているため、ネットワーク通知部２０４もここに設けた。
以下、いくつかの動作例を用いて、これらの各部が行う動作及び処理について説明する。これらの動作及び処理は、実際にはＣＰＵ等のハードウェアが行うものであるが、説明の便宜のため、図３に示した各部が行うものとして説明する。

〔第１動作例：図４乃至図１０〕
まず、情報処理装置１の第１の動作例として、更新用データを取得して各サブシステムのファームウェアを更新する動作について説明する。
図４に、ファームウェアの更新に用いる更新用データの構成例を示す。
図４に示す更新用データは、ヘッダ部とデータ部とからなり、データ部に、各サブシステムの記憶部に記憶させるファームウェアのデータを含む。また、ファームウェア毎に、そのファームウェアのバージョンを示すバージョン情報を含む。このファームウェア１つ１つが、更新に用いる１セットのデータ、すなわち更新用データセットである。

また、ヘッダ部には、更新用データ全体のバージョン情報と、各ファームウェアのサイズ、及び、各ファームウェアのデータ部中の位置を示すオフセットの情報を含む。図３に示した更新制御部１１０は、これらの情報をもとに、図４に示す更新用データから各サブシステムと対応する更新用ファームウェアを取り出すことができる。

次に、図５及び図６に、情報処理装置１が更新用データの取得に応じて各サブシステムのファームウェアを更新する動作の手順を示す。
なお、これらの図及び以降の対応する図において、特に断らない限り、初めの１文字が「Ａ」及び「Ｘ」であるステップは、全体的な更新動作の管理に関する処理を示す。初めの１文字が「Ｂ」であるステップは、第１サブシステム１０のファームウェアを更新する動作の手順を示す。同じく「Ｃ」であるステップは、第２サブシステム２０のファームウェアを更新する動作の手順を示す。

また、これらの図及び以降の対応する図に示す手順は、第１及び第２サブシステム双方のファームウェアの更新を最後まで行う場合について示したものである。途中の処理において第１及び第２サブシステムの一方又は双方について更新不要と判断した場合には、それに応じて、初めの１文字が「Ｂ」及び「Ｃ」であるステップの一部又は全部が実行されないことになる。

図５の説明に移る。
図５に示すように、情報処理装置１に更新用データが入力されると、更新入力部１０８がこれを受け付ける（Ａ１）。この入力は、情報処理装置１が記憶媒体Ｉ／Ｆ１４に接続されたＵＳＢメモリから読み出すといった能動的な取得でもよいし、ネットワークＩ／Ｆ２５を介して外部装置から受信するといった受動的な取得でもよい（ただし、後者の経路の場合、第２サブシステムに更新入力部１０８を設けることになる）。

そして、更新用データを受け付けた更新入力部１０８は、ＲＡＭ１３にその更新用データを一時記憶させつつ、更新用データを受け付けた旨を示す更新データ受付通知及び、そのデータを用いたファームウェアの更新を指示する更新要求を、更新制御部１１０に渡す（Ａ２）。
これらの通知及び要求を受けた更新制御部１１０は、第１及び第２サブシステム１０，２０におけるファームウェア更新に係る制御を開始する。

まず、このうち第１サブシステム１０におけるファームウェア更新に係る動作について説明する。
更新制御部１１０はまず、起動部１０５に、ファームウェアの更新を開始することを示す更新開始通知を送信する（Ｂ１）。起動部１０５は、これを受け取ると、これから更新するファームウェアを動作させないようにロックする（Ｂ２）。すなわち、そのファームウェアの起動を禁止すると共に、既に起動中であれば終了させる。

また、更新制御部１１０は、バージョン通知部１０６にも更新開始通知を送信する（Ｂ３）。この更新開始通知は、ファームウェアの更新開始を通知すると共に、第１サブシステムにおける更新要否を判断するために、第１サブシステム１０において記憶部１０３に現在記憶されているファームウェアのバージョン情報を要求するものである。
バージョン通知部１０６は、この更新開始通知を受信すると、サブシステム更新完了判断部１０７に対し、第１サブシステム１０におけるファームウェアの現在の更新状態を問い合わせる（Ｂ４）。これは、以前のファームウェアの更新が中断された状態であるか、正常に完了した状態であるかを問い合わせるものである。

サブシステム更新完了判断部１０７は、この問い合わせを受けると、記憶部１０３から、更新状態を示す更新中フラグの値を読み出し（Ｂ５）、その値に基づいて、更新が中断された状態であるか、完了した状態であるかをバージョン通知部１０６に応答する（Ｂ６）。この更新中フラグについては後述する。
バージョン通知部１０６は、サブシステム更新完了判断部１０７からの応答を受け取ると、それに応じて更新制御部１１０に通知するファームウェアのバージョン情報を決定する。

まず、更新が完了した状態であれば、現在は記憶部１０３に何らかのバージョンのファームウェアが正常に記憶されていると考えられる。そこで、記憶部１０３からそのファームウェアのバージョン情報を読み出して（Ｂ７）、そのバージョン情報を更新制御部１１０に通知する（Ｂ８）。

一方、更新が中断された状態であれば、現在は記憶部１０３にはファームウェアが正常に記憶されていないと考えられる。しかし、この状態でも、図２（ｂ）に示すように、記憶部１０３にアクセスすればバージョン情報は正常に読み出せてしまうことが考えられる。そこで、記憶部１０３から読み出したバージョン情報ではなく、更新が完了していないことを示すバージョン情報として、通常では取り得ない値のバージョン情報を、更新制御部１１０に通知する（Ｂ８）。

更新制御部１１０は、バージョン通知部１０６から何らかのバージョン情報を受け取ると、図６に示すように、そのバージョン情報と、第１サブシステム１０用の更新用ファームウェアのバージョン情報とに基づき、第１サブシステム１０（通知元のバージョン通知部と対応するサブシステム）におけるファームウェアの更新要否を判断する（Ａ２１）。
具体的には、受信したバージョン情報よりも、更新用ファームウェアのバージョン情報が新しいバージョンを示していれば、更新要と判断する。逆に、両者が同じか受信したバージョン情報が新しいバージョンを示していれば、更新不要と判断する。

また、受信したバージョン情報が、通常では取り得ない値であった場合は、更新要と判断する。この場合、以前の更新が中断されたままであり、これを放置しては第１サブシステム１０を有効に動作させられないと考えられるためである。この場合において、記憶部１０３に実際に記憶されているバージョン情報を参照する必要はない。少なくとも、更新が中断したままよりは何らかの（例え古いものであっても）バージョンのファームウェアを記憶させる方が好ましいと考えられるためである。また、同様に、この場合には更新用ファームウェアのバージョン情報も参照する必要はないと言える。

なお、これらの更新要否の判断は、サブシステム毎に行う。
図５の説明に戻ると、更新制御部１１０は、データ受付通知及び更新要求を受信した後、第２サブシステム２０に対しても、ファームウェアのロックと記憶部２０３に記憶しているファームウェアのバージョン情報の取得を行うため、更新開始通知を送信する。この更新開始通知の宛先は、第１サブシステム１０の場合と同様、起動部２０５とバージョン通知部２０６であるが（Ｃ３，Ｃ５）、その転送は、第１サブシステム１０側及び第２サブシステム２０側のサブシステム通信部１０１，２０１を介して行う（Ｃ１，Ｃ２）。

また、更新開始通知を受信した起動部２０５がこれから更新するファームウェアをロックする点（Ｃ４）及び、同じくバージョン通知部２０６がバージョン情報を更新制御部１１０に送信する点（Ｃ１０〜Ｃ１２）は、第１サブシステム１０側の場合と同様である。バージョン通知部２０６がサブシステム更新完了判断部２０７にファームウェアの更新状態を問い合わせ（Ｃ６）、その応答（Ｃ７，Ｃ８）に応じて、記憶部２０３から読み出したバージョン情報（Ｃ９）と更新が完了していないことを示すバージョン情報のいずれを送信するか決定する点も、第１サブシステム１０の場合と同様である。

図６の説明に移る。
更新制御部１１０は、上述したように、バージョン通知部１０６，２０６から受け取ったバージョン情報と、更新用ファームウェアに含まれるバージョン情報とに基づき、各サブシステムにおけるファームウェアの更新要否をサブシステム毎に判断する（Ａ２１）。そして、更新要と判断したサブシステムについて、以下のファームウェア更新に係る処理を行う。

第１サブシステム１０側については、データ書き込み部１０２に対し、記憶部１０３に記憶されているファームウェアを、受付済みの更新用データに含まれる更新用ファームウェアに更新することを要求する更新要求を送信する（Ｂ２１）。そして、これを受け取ったデータ書き込み部１０２は、ＲＡＭ１３に一時記憶されている更新用データのうち、第１サブシステム１０用のファームウェア（更新用ファームウェア）のデータを読み出し、記憶部１０３の、ファームウェアを記憶させる所定の領域に書き込む（Ｂ２２）。この書き込みは、それまで記憶されているファームウェアに上書きして行うことになる。そして、書き込みが完了（又は失敗）すると、更新制御部１１０にその旨を更新結果として通知する（Ｂ２３）。以上で第１サブシステム１０側の更新に係る処理は終了である（書き込み失敗の場合には更新完了とはならない）。

第２サブシステム２０側についても基本的な流れは同様である。更新制御部１１０は、サブシステム通信部１０１，２０１を介し、データ書き込み部２０２に更新要求を送信する（Ｃ２１〜Ｃ２３）。そして、これを受け取ったデータ書き込み部２０２は、ＲＡＭ１３に一時記憶されている更新用データのうち、第２サブシステム２０用のファームウェアのデータを、第１サブシステム１０と不図示のステップによる通信を行って取得し、記憶部２０３の、ファームウェアを記憶させる所定の領域に書き込む（Ｃ２４）。そして、更新結果を更新制御部１１０に通知する（Ｃ２５〜Ｃ２７）

なお、図６では、第１サブシステム１０側と第２サブシステム２０側との双方の更新処理を示したが、これらの一方又は両方が不要である場合もある。
そして、更新制御部１１０では、更新を行う各サブシステムのデータ書き込み部からの更新結果に基づき全サブシステムでの更新処理終了を確認すると（Ａ２２）、ファームウェアの更新に係る動作を終了する。この後、必要に応じてシステムの再起動を行う。また、書き込み失敗の結果が通知された場合には、そのサブシステムについて再度の更新を試みてもよい。

以上の動作により、情報処理装置１は、記憶部に既に記憶されているファームウェアに含まれるバージョン情報を読み出して更新用ファームウェアのバージョンと比較することにより更新要否を判断できるようにしつつ、更新処理が中断されたような場合でも、更新制御部１１０における同じ更新要否の判断ルーチンによりこれを識別し、更新要と判断することができる。従って、更新処理も行うことができる。

以下、図５及び図６を用いて説明した動作において各部が実行する処理のいくつかを、より具体的に説明する。なお、以下、フローチャートの説明においては、第１，第２サブシステム１０，２０の双方に対応する構成要素がある場合、第１サブシステム側の構成要素を代表して採り上げることにする。

まず、図７に、データ書き込み部１０２が実行する更新用ファームウェアの書き込み処理（Ｂ２２）のフローチャートを示す。
データ書き込み部１０２は、図４のステップＢ２１で送信される更新要求を検出すると、図７のフローチャートに示す処理を開始する。そしてまず、記憶部１０３が記憶している更新中フラグをオンにする（Ｓ１１）。なお、更新中フラグは、ファームウェアの記憶領域外に記憶されているとする。
その後、記憶部１０３の所定の記憶領域に更新用ファームウェアのデータを書き込み（Ｓ１２）、これが完了すると、記憶部１０３が記憶している更新中フラグをオフにして（Ｓ１３）、処理を終了する。

以上の処理により、ファームウェアの更新（書き込み）が正常に完了している限りは、更新中フラグの値をオフに保つことができる。しかし、書き込み中（ステップＳ１２の実行中）に突然情報処理装置１の電源が切断されたり、エラーが発生したりして処理が中断した場合、更新中フラグの値はオンとなったままである。この状態は、次に情報処理装置１が起動した場合でも保たれる。
従って、サブシステム更新完了判断部１０７は、更新中フラグの値を参照することにより、直前のファームウェアの更新が正常に完了した状態であるか、中断した状態であるかを把握することができる。

次に、図８に、バージョン通知部１０６が更新開始通知の受信に応じて実行する処理のフローチャートを示す。
バージョン通知部１０６は、図４のステップＢ３で送信される更新開始通知を受信すると、図８のフローチャートに示す処理を開始する。そしてまず、サブシステム更新完了判断部１０７に、更新状態問い合わせを送信して応答を取得する（Ｓ２１：図５のＢ４及びＢ６と対応）。その後、取得した応答が更新完了であるか否か判断し、完了であれば（Ｓ２２のＹｅｓ）、記憶部１０３が記憶しているファームウェアのバージョン情報を読み出して更新制御部１１０に通知する（Ｓ２３：図５のＢ７，Ｂ８と対応）。完了でなければ（Ｓ２２のＮｏ）、更新が完了していないことを示すバージョン情報を更新制御部１１０に通知する（Ｓ２４：図５のＢ８と対応）。そして、いずれの場合も処理を終了する。

次に、図９に、サブシステム更新完了判断部１０７が更新状態問い合わせの受信に応じて実行する処理のフローチャートを示す。
サブシステム更新完了判断部１０７は、図５のステップＢ４で送信される更新状態問い合わせを受信すると、図９のフローチャートに示す処理を開始する。そしてまず、記憶部１０３から更新中フラグの値を読み出す（Ｓ３１：図５のＢ５と対応）。その後、読み出した更新中フラグの値がオンであれば、記憶部１０３のファームウェアは更新完了状態と判断し、オフであれば、更新未完了（中断）状態と判断する（Ｓ３２〜３４）。いずれの場合も、判断結果を問い合わせ元であるバージョン通知部１０６に応答し（Ｓ３５：図５のＢ６と対応）、処理を終了する。

バージョン通知部１０６及びサブシステム更新完了判断部１０７が以上の処理を行うことにより、更新制御部１１０に対し、バージョンの新旧により更新要否の判断を行うためのバージョン情報を提供しつつ、更新中断状態の場合には、同じ形式で、そのことを示す情報を提供することができる。

次に、図１０に、更新制御部１１０がバージョン情報通知の受信に応じて実行する処理のフローチャートを示す。
更新制御部１１０は、図４のステップＢ８及びＣ１２で、全てのサブシステムのバージョン通知部からバージョン情報通知を受けると、図１０のフローチャートに示す処理を開始する。そしてまず、各サブシステムを順次処理対象として、ステップＳ４１乃至Ｓ４４の処理を繰り返す。

すなわち、まず、処理対象のサブシステムについて、バージョン通知部から通知されたバージョン情報と、更新入力部１０８が受け付けた更新用データに含まれる更新用ファームウェアのバージョン情報とを比較する（Ｓ４１）。そして、更新用ファームウェアのバージョンの方が新しい場合には（Ｓ４２のＹｅｓ）、処理対象のサブシステムはファームウェアの更新要と判断する（Ｓ４３）。そうでない場合、すなわち通知されたバージョン情報の方が新しいか両者が同じ場合には（Ｓ４２のＮｏ）、処理対象のサブシステムはファームウェアの更新不要と判断する（Ｓ４４）。

ここで、通知されたバージョン情報が更新が完了していないことを示すバージョン情報であった場合には、更新用ファームウェアのバージョン情報によらず、処理対象のサブシステムはファームウェアの更新要と判断するようにする。しかし、更新が完了していないことを示すバージョン情報として、通常は使われないVer. 0.0のように、更新用ファームウェアのバージョンが何であってもステップＳ４２の判断がＹｅｓとなるような値を用いれば、更新が完了していないことを示すバージョン情報を見分けるための専用のステップを設ける必要はない。しかし、更新が完了していないことを示すバージョン情報として他の値を用い、これを見分けるための専用のステップを設けるようにしてもよい。

また、更新制御部１１０は、全てのサブシステムについてステップＳ４１〜Ｓ４４の処理を完了すると、そこまでの処理において更新が必要と判断したサブシステムのデータ書き込み部に、更新要求を送信してファームウェアの更新を行わせ（Ｓ４５：図６のＢ２１及びＣ２１〜Ｃ２３と対応）、処理を終了する。

更新制御部１１０が以上の処理を行うことにより、バージョンの新旧と、更新が中断した状態か否かとの双方を考慮した、サブシステム毎のファームウェアの更新要否の判断を、バージョン情報を参照するのみで適切に行うことができる。従って、ファームウェアの更新が中断された後に再起動されたような場合でも、さらに、記憶部１０３においてはファームウェアのバージョン情報が更新されてしまっている場合でも、更新が中断されたことを適切に検出して再度ファームウェアの更新処理を行うことができる。
また、バージョンの新旧のみを考慮した更新要否判断を行う更新制御部１１０を何ら改変することなく、あるいはわずかに改変するのみで、更新が中断した状態か否かも考慮した判断を行えるようにすることができる。

〔第２動作例：図１１乃至図１３〕
次に、情報処理装置１の第２の動作例として、情報処理装置１の起動時（電源投入時だけでなく、リセット後の再起動時等も含む、以下特に断らない限り同じ）に、ファームウェアの更新が適切に行われていないことを検出した場合にリカバリモードで起動する動作について説明する。
この第２の動作例の場合も、ファームウェアの更新については、第１の動作例の場合と同様に行う。ただし、更新の開始前及び終了後に、記憶部１０３へ更新状況を示すフラグの書き込みを行う。

図１１に、第２の動作例におけるファームウェア更新処理のシーケンスを示す。
更新制御部１１０が更新要求の受信（Ｓ５１）に応じて図５及び図６等を用いて説明したファームウェア更新処理（Ｓ５４）を行う場合、これに先立ち、更新開始を通知する更新状況通知を全システム更新完了判断部１０９に送信する（Ｓ５２）。そして、これを受け取った全システム更新完了判断部１０９は、記憶部１０３にアクセスし、全体更新状況フラグをオンに設定する（Ｓ５３）。このことにより、情報処理装置１においてファームウェアの更新処理を実行中であることを記録することができる。

また、更新制御部１１０は、ファームウェア更新処理が終了すると、更新終了を通知する更新状況通知を全システム更新完了判断部１０９に送信する（Ｓ５５）。そして、これを受け取った全システム更新完了判断部１０９は、記憶部１０３にアクセスし、全体更新状況フラグをオフに設定する（Ｓ５６）。このことにより、情報処理装置１はファームウェアの更新処理が正常に完了した状態であることを記録することができる。

第２動作例においては、これらの各部が図１１に示した処理を行うことにより、更新処理の実行中に突然情報処理装置１の電源が切断されたりエラーが発生したりして処理が中断した場合、次に情報処理装置１が起動した際に値がオンとなっていることをもって、更新が正常に完了していない状態であることを示すことができる。第１の動作例における更新中フラグの場合と同様である。なお、全体更新状況フラグも、更新中フラグと同様、ファームウェアの記憶領域外に記憶させる。

次に、図１２に、第２の動作例において情報処理装置１が起動時に実行する動作の手順を示す。
図１２に示す動作においては、更新制御部１１０が、全システム更新完了判断部１０９に対し、装置全体におけるファームウェアの更新状況を問い合わせる（Ｘ１）。全システム更新完了判断部１０９は、この問い合わせを受けると、記憶部１０３から図１１の処理で設定した全体更新状況フラグの値を読み出し、その値に基づき、情報処理装置１が、ファームウェア更新処理が正常に完了した状態か、更新処理が完了していない状態かを判断する（Ｘ２）。そして、その結果を更新制御部１１０に返す（Ｘ３）。

更新制御部１１０は、ステップＸ３で受信した応答が、更新処理が正常に完了した状態であれば、それ以上特別な処理は行わない。この場合、通常の起動手順に従い、各サブシステムの起動部１０５，２０５が記憶部１０３，２０３に記憶しているファームウェアを起動し、情報処理装置１を、通常の機能を発揮できる状態に移行させる。

しかし、ステップＸ３で受信した応答が、更新処理が中断した状態であれば、そのまま起動を続行すると、いずれかのサブシステムでファームウェアが更新途中の異常な状態であることがわかる。
そこで、更新制御部１１０は、各サブシステムの起動部１０５，２０５に更新開始通知を送信し、ファームウェアをロックさせる（Ｂ１，Ｂ２，Ｃ１〜Ｃ４）。この処理は、図５に示した同名のステップの処理と、意味合いは異なるが同じ処理である。ファームウェアを実行できないようにしたいという点で目的は同じであるので、ソフトウェアの規模低減のため、同じコマンドでロックを指示するようにしている。

以上の処理を行うことにより、更新制御部１１０が、情報処理装置１の起動時にファームウェア更新の成否を自動的に確認し、更新が完了していないと判断した場合には、更新対象となり得る全てのファームウェアの動作を禁止することができる。従って、更新が中断したままの異常なファームウェアを実行してサブシステムが不測の動作を行うといった不具合を防止することができる。

なお、このような起動を行った状態をリカバリモードと呼ぶ。この状態でも、更新対象のファームウェアによらない図３に示した各部の機能は維持されるが、それ以外の機能は基本的に使えない状態となる。

また、どのサブシステムにおいて更新が中断したかを把握したい場合には、図５のステップＢ３〜Ｂ８等と同じ処理により、ファームウェアのバージョン情報を取得すればよい。更新が中断しているサブシステムのバージョン通知部からは、そのことを示すバージョン情報が通知される。
また、リカバリモードの状態でも、更新入力部１０８が更新用データの入力を受け付けると、図５及び図６の場合と同様にファームウェアの更新に係る動作を行うことができる。

ここで、図１３に、第２の動作例において情報処理装置１の起動時に更新制御部１１０が実行する処理のフローチャートを示す。
更新制御部１１０は、情報処理装置１の起動処理中で所定のトリガを検出すると、図１３に示す処理を開始する。

そしてまず、全システム更新完了判断部に装置全体におけるファームウェアの更新情報を問い合わせ、その応答を取得する（Ｓ６１：図１２のＸ１〜Ｘ３と対応）。その後、応答に基づき情報処理装置１は全体としてファームウェアの更新が完了している状態であるか否か判断する（Ｓ６２）。ここで更新されている場合は、更新入力部１０８からの更新要求があるか否か判断する（Ｓ６３）。この更新要求は、例えば図５のステップＡ２で更新入力部１０８が送信するものである。更新入力部１０８を、更新用データが格納されたＵＳＢメモリが記憶媒体Ｉ／Ｆ１４に接続されていた場合に自動的にその更新用データを読み出すように構成した場合、情報処理装置１の起動中にステップＡ２の送信が行われる場合がある。

そして、ステップＳ６３でＹｅｓであれば、全システム更新完了判断部１０９にファームウェアの更新を開始する旨を通知し（Ｓ６４：図１１のＳ５２と対応）、第１動作例の場合と同様に各サブシステムのファームウェアを更新する（Ｓ６５，Ｓ６６：図１１のＳ５４と対応）。そして、全ての更新が完了したら（Ｓ６７のＹｅｓ）、全システム更新完了判断部１０９に、ファームウェアの更新を完了した旨を通知し（Ｓ６８：図１１のＳ５５と対応）、情報処理装置１を再起動して（Ｓ６９）、処理を終了する。

更新が何らかの理由で正常に完了しなかった場合は、ステップＳ６８での通知を行わずに再起動（Ｓ６９）を行う。なお、再起動に代えてエラー通知を行ってもよい。いずれの場合も、全体更新状況フラグの値は、更新が正常に完了しなかったことを反映してオンのままとなる。

一方、ステップＳ６３で更新要求がなければ、ファームウェアの更新は不要であるので、情報処理装置１の通常の起動を続ける（Ｓ７０）。この処理においては、必要に応じて各サブシステムのファームウェアを起動し、各サブシステムのファームウェア更新以外の機能を有効にする。なお、通常起動がされた後でもファームウェア更新の指示に応じて第１の動作例のようなファームウェアの更新を行うことはもちろん可能である。

また、ステップＳ６２で更新が完了していない状態であれば、全サブシステムの起動部１０５，２０５に更新開始通知を送信してファームウェアをロックさせる（Ｓ７１：図１２のＢ１〜Ｂ２，Ｃ１〜Ｃ４と対応）。この処理により、情報処理装置１は、ファームウェアを実行しないリカバリモードで起動されたことになる。また、図示は省略したが、ここで各サブシステムからファームウェアのバージョン情報を収集してもよいことは、図１２の説明で述べた通りである。

ステップＳ７１の後は、更新制御部１１０は、更新入力部１０８からの更新要求があるか否か判断する（Ｓ７２）。この更新要求も、例えば図５のステップＡ２で更新入力部１０８が送信するものである。更新入力部１０８は、ユーザの手動による更新操作に応じて更新要求を送信することも、自動的に更新用データを読み出して更新要求を送信することもある。

そして、更新要求があると、更新制御部１１０は、全システム更新完了判断部１０９に対する更新状況の通知（Ｓ７３，Ｓ７５，Ｓ７６）と、更新処理（Ｓ７４）と、再起動（Ｓ７７）とを行う。これらの処理は、ファームウェアのロックは既に行われているので行わない点以外は、ステップＳ６４乃至Ｓ６９で行う処理と同じものである。
ステップＳ７２で更新要求がない場合、そのまま処理を終了する。

以上の処理を行うことにより、起動時に情報処理装置１全体としてファームウェアの更新が完了していない状態であった場合には、全サブシステムのファームウェアの使用を禁止することができるので、異常なファームウェアを実行して情報処理装置１が不測の動作をすることを防止できる。
また、この状態であってもファームウェアの更新をリトライして情報処理装置１を正常な状態へ復帰させることができる。

〔第３動作例：図１４〕
次に、情報処理装置１の第３の動作例として、情報処理装置１の起動時に、ファームウェアの更新が適切に行われていないことを検出した場合に自動的にファームウェアの更新をリトライする動作について説明する。
図１４に、第３の動作例において情報処理装置１が起動時に実行する動作の手順を示す。

この動作例においても、第２の動作例の場合と同様に全体更新状況更新フラグの値を管理しているとする。そして、図１４に示す動作においても、更新制御部１１０が全システム更新完了判断部１０９に装置全体におけるファームウェアの更新情報を問い合わせ、その応答を取得する点は、第２動作例の場合と同様である（Ｘ１〜Ｘ３）。

そして、この応答に基づきファームウェアの更新要否を判断する（Ｘ４）。ここでは、ファームウェアの更新が正常に完了していない状態であれば、更新が必要であると判断する。この場合、自動更新部１１１に自動更新通知を送信し（Ｘ５）、自動更新の実行を指示する。

自動更新部１１１は、この通知を受けると、更新入力部１０８に対し、更新用データの受け付け開始を指示するデータ受付要求を送信する（Ｘ６）。更新入力部１０８は、この要求を受けると、更新用データが格納されたＵＳＢメモリが記憶媒体Ｉ／Ｆ１４に接続されていれば、そこから更新用データを読み出してＲＡＭ１３に一時記憶させる（Ｘ７）。これが完了すると、更新制御部１１０に対しデータ受付通知を送信する（Ｘ８）。

また、自動更新部１１１は、データ受付要求の送信とは別に、更新制御部１１０に対し更新要求を送信する（Ｘ９）。
更新制御部１１０は、ステップＸ８のデータ受付通知とステップＸ９の更新要求が揃うと、第２動作例の場合と同様なファームウェアの更新を行う。

なお、図示は省略したが、ステップＸ４で更新要と判断した時点でファームウェアのロックを行うようにするとよい。この場合の更新制御部１１０の処理フローは、図１３とほぼ同じものである。ステップＳ７２の前に自動更新部１１１に対して自動更新通知を行う点と、ステップＳ７２の判断が、ステップＸ８のデータ受付通知とステップＸ９の更新要求とが揃った場合にＹｅｓになるようにする点が異なるのみである。

以上の動作を行うことにより、情報処理装置１の起動時に、装置全体としてファームウェアの更新が正常に完了していないと判断した場合に自動的に更新をリトライすることができる。従って、ファームウェアの更新が失敗した場合でも、ユーザの手を煩わせることなく、情報処理装置１を正常な状態へ復帰させることができる。

なお、何度もリトライしても更新の失敗が続く場合に無制限にリトライを続けると、却って別の対応策の実施を妨げることになる。そこで、自動更新部１１１にリトライ回数をカウントする機能を設け、一定の期間内に所定回数以上リトライがあった場合、リトライを中止するようにするとよい。この場合、更新入力部１０８へのデータ受付要求を行わず、更新制御部１１０には更新リトライ中止を通知するとよい。また、この場合、更新制御部１１０は、情報処理装置１をリカバリモードで起動させて待機するようにするとよい。

また、リトライの中止を、ユーザの指示に応じて行うようにしてもよい。この場合、例えば、ユーザの指示があった場合に、自動更新部１１１が次回リトライを行わない旨のフラグを記憶部１０３に書き込み、起動時にそのフラグの値を確認してリトライを行うか否か決定するようにすることが考えられる。

また、更新入力部１０８がデータ受付要求に応じた更新用データの読み込みをできない場合、自動更新部１１１にその旨を通知するようにするとよい。この場合も、自動更新部１１１が更新制御部１１０に更新リトライ中止を通知し、情報処理装置１をリカバリモードで起動させて待機させるようにするとよい。

また、更新入力部１０８が複数ある場合（例えば第２サブシステム２０がネットワークＩ／Ｆ２５を介して更新用データを取得する不図示の更新入力部を備える場合）には、１つの更新入力部で更新用データを取得できない場合に、自動更新部１１１が他の更新入力部にデータ受付要求を送信して更新用データの取得を試みさせるようにするとよい。
このように、自動更新部１１１が更新用データを取得を管理するようにすれば、複数の更新入力部１０８が独自に更新用データを取得して更新用データが重複してしまうことがない。

〔第４動作例：図１５乃至図１８〕
次に、情報処理装置１の第４の動作例として、情報処理装置１の起動時に、ファームウェアの更新が適切に行われていないことを検出した場合に、適切に更新されていないサブシステムについてのみファームウェアの実行を禁止する動作について説明する。
図１５に、第４の動作例において情報処理装置１が実行する動作の手順を示す。

図１５に示す動作は、図１２を用いて説明した動作のうちファームウェアのロック（Ｂ１〜Ｂ２，Ｃ１〜Ｃ４）以外の動作を実行した後に行う動作である。すなわち、情報処理装置１の起動時にファームウェアの更新が正常に完了していない状態であることを検出し、その後、各サブシステムにおけるファームウェアのバージョン情報を取得した後に行う動作である。なお、第１及び第２の動作例で説明した通り、ここで取得されるバージョン情報は、ファームウェアの更新が正常に完了していない状態であるサブシステムについては、そのことを示すバージョン情報となる。

図１５に示す動作において、更新制御部１１０は、既に取得したバージョン情報に基づき、各サブシステムにおいてファームウェアの更新が正常に完了している状態であるか否か判断し（Ａ６１）、その結果を更新状況として機能利用可否判断部１１２に通知する（Ａ６２）。

機能利用可否判断部１１２は、これを受けて、更新が完了しているサブシステムについてのみ、起動部へファームウェアの起動を要求する。図１５には、第１サブシステム１０の起動部１０５に起動を要求する動作（Ｂ６１）と、第２サブシステム２０の起動部２０５に起動を要求する動作（Ｃ６１〜Ｃ６３）とを示しているが、これらの一方又は両方は実行されない場合がある。また、起動部１０５，２０５は、ファームウェア起動要求に応じて対応する記憶部１０３，２０３に記憶されているファームウェアを起動し、その結果を応答として機能利用可否判断部１１２に返す（Ｂ６２，Ｃ６４〜Ｃ６６）。この応答は、通常は起動成功の応答となる。
機能利用可否判断部１１２は、各起動部から応答を受信すると、それに基づき、以後、起動したサブシステムに応じて動作要求の実行可否を制御する（Ａ６３）。

図１６に、機能利用可否判断部１１２によるこの動作要求の実行可否制御処理のフローチャートを示す。
なお、動作要求とは、ユーザの操作、内部的なイベント検出、外部装置から要求等に応じて、情報処理装置１の図３等に示していない各部が生成する、情報処理装置１のいずれかのサブシステムの機能を利用した動作の実行を求める要求である。例えば、情報処理装置１がプロジェクタであれば映像投影開始／停止や、投影に関する設定の変更等を求める要求が挙げられる。プリンタであれば、印刷開始や印刷に関する設定の変更等である。

機能利用可否判断部１１２は、情報処理装置１において動作要求が発生したことを検出すると、図１６の処理を開始する。
そしてまず、起動済みのサブシステムのみで検出した要求に係る動作を実行できるか否か判断する（Ｓ７１）。そして、できる場合、検出した要求を、その実行を担当する機能部に転送する（Ｓ７２）。できない場合、検出した要求に係る機能が利用できない旨をユーザに通知する（Ｓ７３）。後者の場合、検出した要求に係る動作を実行できない旨の応答を、要求元に返してもよい。いずれの場合も、以上で処理を終了する。

次に、図１７及び図１８に、ステップＳ７１の判断に用いるデータの例を示す。なお、内容をわかりやすくするため、これらの図では、サブシステムが３つある場合のデータ例を示している。
図１７に示すのは、動作要求により利用を要求される機能毎に、該機能がどのサブシステムを利用するかを示すテーブルである。図１８に示すのは、各サブシステムが現在起動中であるか否かを示すテーブルである。

図１７に示すテーブルは、情報処理装置１のメーカーが予め定めて記憶部１０３に記憶させておくものである。図１８のテーブルは、機能利用可否判断部１１２が、各起動部からのファームウェア起動要求に対する応答に基づき生成する。
そして、機能利用可否判断部１１２は、図１６のステップＳ７１の処理においては、まず、検出した機能利用要求の実行に必要な機能を特定する。そして、この機能をキーに図１７のテーブルを参照し、その機能が利用するサブシステムを特定する。
次に、そのサブシステムをキーに図１８のテーブルを参照し、利用するサブシステムが全て起動中であるか否か判断する。そして、全て起動中であればステップＳ７１の判断結果はＹｅｓとし、そうでなければＮｏとする。

情報処理装置１の各部が以上の処理を行うことにより、情報処理装置１の起動時に、更新が完了しているファームウェアのみを起動して、対応するサブシステムの機能のみ有効にすることができる。このようにすれば、情報処理装置１全体としてはファームウェアの更新が正常に完了していない状態であっても、不測の動作をさせない範囲で情報処理装置１の機能を利用可能とすることができる。

〔第５動作例：図１９〕
次に、情報処理装置１の第５の動作例として、情報処理装置１の起動時にファームウェアの更新が適切に行われていないことを検出した場合に行う動作をユーザが設定可能とした場合の動作について説明する。

この動作例においては、更新制御部１１０は、適当なタイミングでユーザの指示を受け付け、その指示に応じて、ファームウェア更新失敗の場合の起動時の動作を記憶部１０３に記憶させておく。その選択肢としては、リカバリモードでの起動（第２動作例）、自動更新の実行（第３動作例）、特定機能利用可能モードでの起動（第４動作例）等が考えられる。

ここで、図１９に、この動作例において更新制御部１１０が実行する処理のフローチャートを示す。
更新制御部１１０は、情報処理装置１の起動時に、図１２のステップＸ１〜Ｘ３の処理で全システム更新完了判断部１０９からファームウェアの更新が正常に完了していない旨の応答を受け取ると、図１９のフローチャートに示す処理を開始する。

そして、記憶部１０３からファームウェア更新失敗の場合の起動時の動作の設定情報を読み出し（Ｓ８１）、その設定内容に応じて、第２乃至第４の動作例で説明した動作のいずれかを行う（Ｓ８２〜Ｓ８５）。もちろん、図１２のステップＸ１〜Ｘ３に当たる処理の続きからでよい。
以上の処理により、情報処理装置１は、ファームウェアの更新が正常に完了していないことを検出した場合に、ユーザのニーズに合った動作を行うことができる。

〔第６動作例：図２０，図２１〕
次に、情報処理装置１の第６の動作例として、ファームウェアの更新が正常に完了していない場合にその旨をユーザに通知する動作について説明する。
図２０に、第６の動作例において情報処理装置１が実行する動作の手順を示す。

情報処理装置１は、ファームウェアの更新が正常に終了していないことを検出すると、更新制御部１１０が各サブシステムのバージョン通知部からファームウェアのバージョン情報を収集した後で、図２０に示す動作を開始する。具体的な開始タイミングとしては、例えば第２動作例で図１２を用いて説明した動作の完了後が考えられる。しかし、図２０の動作を行うのは、情報処理装置１の起動時には限らず、ファームウェア更新処理の実行中に何らかの不具合を検出して更新を中断した後にバージョン情報を収集して行うことも考えられる。

図２０の動作においてはまず、更新制御部１１０が、収集したバージョン情報に基づき、ファームウェアの更新が正常に完了していない（更新失敗の）サブシステムを特定する（Ａ８１）。その後、本体通知部に更新失敗通知を送信してその特定したサブシステムにおける更新の失敗を通知する（Ａ８２）。そして、その通知を受けた本体通知部１０４は、表示装置１５を制御して、ユーザに対して更新失敗の旨を表示する（Ａ８３）。

この表示は、例えば、図２１に示すような更新の失敗したサブシステムと対応するタイミングでＬＥＤの点灯を制御することにより行うことができる。もちろん、ＬＣＤ等にメッセージを表示してもよい。
なお、サブシステム毎の表示とせず、情報処理装置１全体としてファームウェアの更新が失敗していることを表示してもよい。この場合、バージョン情報の収集は必要ない。

〔第７動作例：図２２，図２３〕
次に、情報処理装置１の第７の動作例として、ファームウェアの更新結果をユーザに通知する別の動作について説明する。
図２２に、第７の動作例において情報処理装置１が実行する動作の手順を示す。

なお、この動作例においては、各サブシステムのデータ書き込み部１０２，２０２は、図７のステップＳ１１，Ｓ１３で更新中フラグの値を更新する際に、更新の履歴を対応する記憶部１０３，２０３に書き込むようにする。例えば、ステップＳ１１で更新処理の開始時刻を、ステップＳ１３で終了時刻を書き込む。すると、開始時刻と終了時刻が揃っている更新については正常に更新が完了したことが、開始時刻のみの更新については正常に更新が完了していないことがそれぞれわかる。
サブシステム更新完了判断部１０７は、更新中フラグの値に代えて、または加えてこの履歴を参照することにより、更新が正常に完了したか否かを把握することができる。

第７の動作例においては、情報処理装置１は、ファームウェアの更新に係る処理が終了したことを確認した場合（図６のＡ２２：更新を中断した場合も含む）、あるいは、起動時にファームウェアの更新が正常に完了していない状態であることを検出した場合、図２２に示す動作を開始する。
いずれの場合も、図２２の動作において、更新制御部１１０がネットワーク通知部２０４に結果通知要求を送信する（Ａ１０１〜Ａ１０３）。ネットワーク通知部２０４は、この要求を受信すると、各サブシステムのサブシステム更新完了判断部１０７，２０７に対し、更新履歴読み出し要求を送信する（Ｂ１０１〜Ｂ１０３，Ｃ１０１）。

この要求を受信したサブシステム更新完了判断部１０７，２０７は、それぞれ対応する記憶部１０３，２０３からファームウェア更新の履歴を読み出し（Ｂ１０４，Ｃ１０２）、ネットワーク通知部２０４に応答する（Ｂ１０５〜Ｂ１０７，Ｃ１０３）。
ネットワーク通知部２０４は、この応答を受け取ると、各サブシステムにおける更新履歴に基づき、図２３に示すような更新結果通知のメッセージを生成して、予め設定されているアドレスに送信する。図２３には、第１サブシステムでの更新は成功したが、第２サブシステムでの更新は２回続けて失敗し、ここでリトライを打ち切って装置全体として更新失敗とした場合の例を示している。このメッセージの記載形式及び送信に用いるプロトコルは任意である。図２３の例では電子メールとしているが、これに限られない。

なお、図２２の動作において、サブシステム更新完了判断部からネットワーク通知部２０４への履歴の通知は、更新結果通知メッセージに含める部分のみ、例えば最新の一連の更新リトライに係る部分のみでよい。
情報処理装置１が以上のような動作を行うことにより、ファームウェアの更新成否をユーザに通知することができる。なお、サブシステム毎の通知とせず、情報処理装置１全体としてのファームウェアの更新成否を通知してよいことは第６動作例の場合と同様である。

〔変形例：図２４，図２５〕
以上で実施形態の説明を終了するが、以上説明してきた実施形態及び動作例において、装置の構成や具体的な処理内容、動作手順、データの形式等が上述したものに限られないことはもちろんである。

例えば、ファームウェアの更新をリトライする際に、データ書き込み部１０２による更新用ファームウェアの書き込みを、前回実行時（中断発生時）の続きから行うようにすることが考えられる。
この場合、例えば、図２４に示すように、書き込む更新用ファームウェアのバージョン、更新済みバイト数及び全体バイト数を更新の進捗状況として管理する。これらの情報は記憶部１０３に記憶させておき、更新済みバイト数は、１バイト書き込む毎（所定バイト数毎でもよい）に更新する。また、バージョンの情報は、更新開始時に更新する。

そして、更新をリトライする際には図２４に示すデータを参照し、次もここに記録されているバージョンの更新用ファームウェアを書き込むのであれば、更新済みバイト数が示す位置の続きから書き込みを始める。すなわち、図２５に示すように、既に更新済みの領域については再度更新用ファームウェアの書き込みを行うことなく、その次の位置から、更新用ファームウェアのうちその位置と対応する部分を書き込む。
このようにすれば、一度行った書き込みを再度行う必要がないため、リトライ時の更新時間を短縮することができる。

また、上述した実施形態では、ファームウェアを更新する例について説明したが、更新する対象はファームウェアあるいは何らかのプログラムのデータに限られず、当該データセットのバージョン情報を含むものであれば、任意のデータセット（ひとかたまりのデータ）でよい。
また、情報処理装置１のサブシステム毎に１つのデータセットのみである必要もない。データセットの種類毎にバージョンの管理がなされていれば、１つのサブシステムにおいて複数種類のデータセットを更新してもよい。

逆に、サブシステムの区切りがない情報処理装置であったり、情報処理装置全体で１つのデータセットのみを更新するものであったりしてもよい。また、更新すべきデータセットのないサブシステムがあってもよい。サブシステムの数が２に限られないことも、もちろんである。
また、更新入力部１０８が取得する更新用データには、必ずしも全てのデータセットについての更新用データが含まれている必要はない。一部のデータセットについてのみ更新用データが含まれている場合、それらのデータセットについてのみ更新処理を行えばよい。

また、この発明の情報処理装置は、情報処理機能を有する任意の電子装置に上述の実施形態で説明したデータセットの更新機能を設けた装置として構成可能である。例えば、ネットワーク家電、自動販売機、医療機器、電源装置、空調システム、ガス・水道・電気等の計量システム、自動車、航空機あるいは汎用コンピュータ等にも適用可能である。
また、以上説明してきた各実施形態、動作例及び変形例の構成は、相互に矛盾しない限り任意に組み合わせて実施可能であることは勿論である。

１：情報処理装置、１０：第１サブシステム、１１，２１：ＣＰＵ、１２，２２：ＲＯＭ、１３，２３：ＲＡＭ、１４，２４：記憶媒体Ｉ／Ｆ、１５：表示装置、１６：入力装置、２０：第２サブシステム、２５：ネットワークＩ／Ｆ、３０：システムバス、１０１，２０１：サブシステム通信部、１０２，２０２：データ書き込み部、１０３，２０３：記憶部、１０４：本体通知部、１０５，２０５：起動部、１０６，２０６：バージョン通知部、１０７，２０７：サブシステム更新完了判断部、１０９：全システム更新完了判断部、１１０：更新制御部、１１１：自動更新部、１１２：機能利用可否判断部、２０４：ネットワーク通知部

特開２０１１−４４１０６号公報

Claims (8)

1. データセットであって該データセットのバージョン情報を含むものを記憶する記憶手段と、
   更新用データセットであって該更新用データセットのバージョン情報を含むものを取得する取得手段と、
   前記記憶手段が記憶しているデータセットのバージョン情報を提供する提供手段と、
   前記取得手段が取得した更新用データセットのバージョン情報と前記提供手段が提供するバージョン情報とに基づき更新が必要であると判断した場合に前記記憶手段に記憶しているデータセットを前記更新用データセットに更新する更新手段と、
   前記更新手段によるデータセットの更新が完了している状態であるか否か判断する判断手段とを備え、
   前記提供手段は、前記判断手段が、前記データセットの更新が完了していない状態であると判断した場合には、前記記憶手段が記憶しているデータセットのバージョン情報に代えて、更新が完了していないことを示すバージョン情報を提供する手段であることを特徴とする情報処理装置。
2. 請求項１に記載の情報処理装置であって、
   前記更新手段は、当該情報処理装置の起動時に前記判断手段が前記更新手段によるデータセットの更新が完了していない状態であると判断した場合には、前記取得手段に更新用データセットを取得させ、該取得させた更新用データセットのバージョン情報と前記提供手段が提供するバージョン情報とに基づき更新が必要であると判断した場合に前記記憶手段に記憶しているデータセットを該取得させた前記更新用データセットに更新する手段を備えることを特徴とする情報処理装置。
3. 請求項１又は２に記載の情報処理装置であって、
   それぞれデータセットであって該データセットのバージョン情報を含むものを記憶する記憶手段を複数備え、
   前記取得手段は、前記複数の記憶手段の少なくとも１つについて、該記憶手段が記憶するデータセットを更新するための更新用データセットを取得する手段であり、
   前記提供手段は、前記複数の記憶手段の各々について、該記憶手段が記憶しているデータセットのバージョン情報を提供する手段であり、
   前記更新手段は、前記取得手段が取得した各更新用データセットのバージョン情報と前記提供手段が提供する対応するデータセットのバージョン情報とに基づき記憶手段毎にデータセットの更新の要否判断及び更新を行う手段であり、
   前記判断手段は、記憶手段毎にその記憶手段に記憶しているデータセットの更新が完了している状態であるか否か判断する手段であることを特徴とする情報処理装置。
4. 請求項１乃至３のいずれか一項に記載の情報処理装置であって、
   当該情報処理装置の起動時に前記判断手段が少なくとも一つの前記記憶手段において前記更新手段によるデータセットの更新が完了していない状態であると判断した場合に、その記憶手段に記憶されているデータセットの使用を禁止する禁止手段を備えることを特徴とする情報処理装置。
5. 請求項４に記載の情報処理装置であって、
   当該情報処理装置の機能と、その機能を利用するために必要なデータセットとの関係を示す機能情報を記憶しておき、
   当該情報処理装置の機能の利用を要求された場合に、前記機能情報を参照して前記禁止手段が使用を禁止しているデータセットなしでその要求に係る機能を利用可能か否か判断し、利用可能の場合に該要求に係る機能の利用を許可し、利用不能の場合には該要求に関する機能の利用を許可しない利用可否判断手段を備えたことを特徴とする情報処理装置。
6. 請求項１乃至３のいずれか一項に記載の情報処理装置であって、
   当該情報処理装置の起動時に前記判断手段が少なくとも一つの前記記憶手段において前記更新手段によるデータセットの更新が完了していない状態であると判断した場合に、全ての前記記憶手段に記憶されているデータセットの使用を禁止する禁止手段を備えることを特徴とする情報処理装置。
7. 請求項１乃至６のいずれか一項に記載の情報処理装置であって、
   前記更新手段による前記データセットの更新の進捗状況を記憶する進捗状況記憶手段を備え、
   前記更新手段は、当該情報処理装置の起動時に前記判断手段が前記更新手段によるデータセットの更新が完了していない状態であると判断した場合には、前記記憶手段に記憶しているデータセットの更新を、前記進捗状況記憶手段が記憶する進捗状況に基づき、前回実行時の続きから行うことを特徴とする情報処理装置。
8. 請求項３に記載の情報処理装置であって、
   複数のサブシステムを備え、前記記憶手段は、該各サブシステムと対応して設けられ、
   前記データセットは、前記記憶手段と対応するサブシステムに実行させるファームウェアであることを特徴とする情報処理装置。

Images