JP5894495B2 - 情報処理装置、情報処理装置におけるファームウエアの更新方法およびプログラム - Google Patents

Description

本発明は、ファームウエアの更新を行う情報処理装置、情報処理装置におけるファームウエアの更新方法およびプログラムに関する。

従来、例えば、プリンタでは、単機能印刷装置（ＳＦＰ：Ｓｉｎｇｌｅ Ｆｕｎｃｔｉｏｎ Ｐｒｉｎｔｅｒ）であったものを多機能複合装置（ＭＦＰ：Ｍｕｔｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）化するためのスキャナユニットを含む場合がある。また、測色センサを取り付けて色の測定を行うための測色ユニットを含む場合がある。このように、本体機器とは別に、追加可能に構成された周辺機器を有する製品が増えてきている。

特許文献１では、周辺機器に対応するドライバにアップデート制御機能を有しており、自動的に、最適なファームウエアをロードしてファームウエア更新が可能であることが記載されている。

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

しかしながら、特許文献１では、本体機器や周辺機器において、ファームウエアを更新する際に、機器が使用可能状態となるまでの時間が長いという問題があった。

特に周辺機器のファームウエアを更新する際に、複数機器間でファームウエアを送受信して、そのファームウエア自体のサイズが極めて大きいものである場合や、機器間の通信速度が低速である場合はこの問題が顕著となる。

本発明の目的は、このような従来の問題点を解決することにある。上記の点に鑑み、本発明は、ファームウエアの更新をする際に情報処理装置の使用が可能状態となるまでの時間を短縮する情報処理装置、情報処理装置におけるファームウエアの更新方法およびプログラムを提供することを目的とする。

上記課題を解決するため、本発明に係る情報処理装置は、接続可能である周辺機器が単体で動作するために必要な基本部分と、当該基本部分以外であるアプリケーション部分とを含む周辺機器用のファームウエアを取得する取得手段と、前記取得手段により取得された前記周辺機器用のファームウエアの基本部分を抽出する抽出手段と、前記周辺機器用のファームウエアのアプリケーション部分を送信するよりも前に、前記抽出手段により抽出された前記周辺機器用のファームウエアの基本部分を前記周辺機器へ送信する送信手段と、を備えることを特徴とする。

本発明によると、ファームウエアの更新する際にユーザによる使用が可能状態となるまでの時間を短縮することができる。

複数の装置を含むシステムの構成を示す図である。 本体機器と周辺機器に格納されたファームウエアを示す図である。 本体機器に格納されたファームウエアの更新処理の手順を示す図である。 周辺機器に格納されたファームウエアの更新処理の手順を示す図である。

以下、添付図面を参照して本発明の好適な実施例を詳しく説明する。尚、以下の実施例は特許請求の範囲に係る本発明を限定するものでなく、また本実施例で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。なお、同一の構成要素には同一の参照番号を付して、説明を省略する。

［システム構成］
図１は、複数の装置を含むシステムの構成を示す図である。図１に示すように、本実施例においては、本体機器１００と周辺機器２００とが相互に通信可能に接続されている。本体機器１００は、例えば印刷装置であり、周辺機器２００は、例えば測色器である。本体機器１００と周辺機器２００は、本体機器１００がホストとして、周辺機器２００がクライアントとして機能する関係であれば良い。従って、例えば、本体機器１００が単機能印刷装置（ＳＦＰ）であり、周辺機器２００がスキャナユニットであっても良い。

本体機器１００は、汎用的なＰＣ等の情報処理装置と同様に、ＲＯＭ１、ＣＰＵ２、ＲＡＭ３、通信インタフェース（Ｉ／Ｆ）４を含む。本体機器１００が例えば印刷装置である場合には、不図示の、印刷対象の画像データを高速で転送し、ＲＩＰ等を接続する画像バスで構成された画像処理部や、記録ヘッドや記録媒体の搬送制御を行う印刷制御部等を含む。周辺機器２００は、通信インタフェース（Ｉ／Ｆ）５、ＲＯＭ６、ＣＰＵ７、ＲＡＭ８を含む。周辺機器２００が例えば測色器である場合には、不図示の発光素子やパッチ画像等からの反射光を受光するための受光素子等の光学系制御部等を含む。本体機器１００と周辺機器２００とは、通信インタフェース４及び通信インタフェース５を介して相互に通信可能である。なお、図１には不図示であるが、本体機器１００及び周辺機器２００は、ユーザからの指示を受け付けるためのディスプレイ等の表示部や、ユーザが指示を投入するためのキーボードやハードキー等の操作パネル部や、ハードディスク等の記憶領域も有する。

本体機器１００と周辺機器２００はそれぞれ、不揮発性メモリであるＲＯＭ１及びＲＯＭ６に、各機器のハードウエア資源を制御するためのファームウエアを格納している。
詳細は後述するが、本体機器１００のＲＯＭ１に格納されているファームウエアは、本体機器１００自身が単体で動作するために最低限必要な起動用プログラム部分（基本部分ともいう）と、起動用プログラム部分以外の部分とが区別されて格納されている。本体機器１００の起動用プログラム部分としては、例えばＣＰＵ２等の制御関連のハードウエア資源を制御するための、システム起動処理に必要な起動用プログラム部分が挙げられる。以下、ファームウエアのうち、上記の起動用プログラム部分以外（基本部分以外）の部分をアプリケーション部分とする。

周辺機器２００のＲＯＭ６に格納されているファームウエアは、周辺機器２００自身が単独で動作するために最低限必要な起動用プログラム部分と、起動用プログラム部分以外の部分とが区別して格納されている。周辺機器２００の起動用プログラム部分としては、例えば、ＣＰＵ７等の制御関連のハードウエア資源を制御するための、システム起動処理に必要な起動用プログラム部分が挙げられる。以下、ファームウエアのうち、上記の起動用プログラム部分以外の部分をアプリケーション部分とする。

本実施例では、本体機器１００のＲＯＭ１には、本体機器１００用のファームウエアだけでなく、周辺機器２００用のファームウエアも格納されている。本体機器１００のＣＰＵ２は、その格納された周辺機器２００用のファームウエアを、周辺機器２００のＲＯＭ６に格納されているファームウエアを更新するために、周辺機器２００に送信する。周辺機器２００でファームウエアが更新されることにより、本体機器１００用のファームウエアと周辺機器２００用のファームウエアとでバージョン等の整合をとることができる。

［ファームウエア格納状態］
図２は、本体機器１００と周辺機器２００それぞれに格納されたファームウエアを示す図である。本実施例においては、各機器用のファームウエアは、システムを起動させるために必要な起動用プログラムと、システムの起動には必要のないアプリケーションとに記憶領域上で区別されて格納されている。すなわち、ファームウエアとして複数のプログラムが存在するが、それぞれが起動用プログラムと、アプリケーションとに区別して管理されている。

ここで、起動用プログラムとは、各機器が単独で動作するために最低限必要な基本部分であり、上述の起動用プログラム部分に対応している。本実施例では、起動用プログラムは、ブートプログラムと、その他各機器が単独で動作するために最低限必要なプログラムとを含む。ブートプログラム以外で機器が単独で動作するために最低限必要なプログラムとしては、例えばカーネルが挙げられる。また、アプリケーションとは、上述のアプリケーション部分に対応している。

本体機器１００のＲＯＭ１には、本体機器１００用のファームウエア（情報処理装置用ファームウエア）と、周辺機器２００用のファームウエア（周辺機器用ファームウエア）とが含まれる。

図２の本体機器起動用プログラム９と本体機器用アプリケーション１０とが本体機器１００用のファームウエアに対応する。図２のＨｏｓｔ Ｂｏｏｔ Ｐｒｏｇｒａｍ９は、一般的なブートプログラムのみを指すものではなく、上述した本体機器起動用プログラムに対応する。ここで、本体機器起動用プログラム９は、ブートプログラム、本体機器１００自身が単独で動作するために最低限必要なプログラム、及び周辺機器２００に更新情報を送信するために必要なプログラムを含む。一方、本体機器用アプリケーション１０は、例えば、周辺機器２００との連動機能（パッチ画像を測色させる機能等）についてハードウエア資源を制御する。本体機器１００のファームウエアは、詳細は後述するが、図示しない外部装置（パーソナルコンピュータ、サーバ、ＵＳＢ等）からファームウエアの更新情報を受信し、ＲＯＭ１に記憶され、更新処理が実行されことで更新される。

図２の周辺機器起動用プログラム１１と、周辺機器用アプリケーション１２及び１３とが周辺機器２００用のファームウエアに対応する。周辺機器２００用ファームウエアとは、本体機器１００自身が使用するプログラムではなく、周辺機器２００に少なくとも送信するためのプログラムである。周辺機器用アプリケーション１２及び１３は、例えば、測色器の乾燥ファンの駆動についてハードウエア資源を制御する。図２では、周辺機器用アプリケーション１２及び１３は、２つ示されているが、１つであっても良いし、各用途に対応して３つ以上であっても良い。本体機器用アプリケーション１０も１つとして示されているが、複数であっても良い。

図２に示すように、各機器用のファームウエアは記憶領域上でそれぞれが起動用プログラムとアプリケーションの２種類に区別されて格納されているが、予めユーザにより起動用プログラムとアプリケーションに各対応した複数のファイルで用意されて、記憶領域上に区別して格納するようにしても良い。若しくは、ファームウエアのヘッダ情報を参照して、起動用プログラム部分とアプリケーション部分とを抽出して記憶領域に区別して格納する構成を本体機器１００が有するようにしても良い。

周辺機器２００のＲＯＭ６には、周辺機器２００用のファームウエアが格納されている。周辺機器用ブートプログラム１４、周辺機器用アプリケーション１５及び１６が周辺機器２００用のファームウエアに対応する。図２のＣｌｉｅｎｔ Ｂｏｏｔ Ｐｒｏｇｒａｍ１４は、一般的なブートプログラムのみを指すものではなく、上述した周辺機器用起動プログラムに対応する。ここで、周辺機器用起動プログラムは、ブートプログラム及び周辺機器２００自身が単独で動作するために最低限必要なプログラムを含む。

周辺機器２００のファームウエアの更新処理については、詳細は後述するが、本体機器１００のＲＯＭ１に格納されている周辺機器２００用のファームウエアにより、周辺機器２００に格納されているファームウエアが更新される。すなわち、本体機器１００のＲＯＭ１の周辺機器２００用のファームウエアが周辺機器２００に送信されることにより、周辺機器２００に格納されているファームウエアが更新される。例えば、その送信の際に、本体機器１００のＣＰＵ２は、送信したファームウエアに対応する、周辺機器２００のＣＰＵ７にＲＯＭ６に格納されている周辺機器用のファームウエアについての更新を指示する。

また、周辺機器２００においてファームウエアが更新されると、更新された情報が周辺機器２００から本体機器１００に送信されて、本体機器１００のＲＯＭ１に記憶される。これにより、本体機器１００は、周辺機器２００のファームウエアの更新状態を管理することができる。

周辺機器２００のＲＯＭ６に格納されている周辺機器起動用プログラム１４は、本体機器１００のＲＯＭ１に格納されている周辺機器起動用プログラム１１に対応する。また、周辺機器２００のＲＯＭ６に格納されている周辺機器用アプリケーション１５は、本体機器１００のＲＯＭ１に格納されている周辺機器用アプリケーション１２に対応する。また、周辺機器２００のＲＯＭ６に格納されている周辺機器用アプリケーション１６は、本体機器１００のＲＯＭ１に格納されている周辺機器用アプリケーション１３に対応する。

［ファームウエア更新処理］
以下、本体機器１００用のファームウエアを更新してから、周辺機器２００用のファームウエアを更新するまでの処理について順に説明する。

図３は、本体機器１００用のファームウエアの更新処理の手順を示すフローチャートである。図３に示す処理は、例えば、本体機器１００のＣＰＵ２によりインストーラ（プログラム）を実行することでなされる処理である。

まず、Ｓ３０１において、ＣＰＵ２は、本体機器１００用のファームウエアとともに、周辺機器２００用のファームウエアも取得する。例えば、ＣＰＵ２は、外部のサーバ装置等から、本体機器１００用のファームウエアと周辺機器２００用のファームウエアとを含むインストーラをパッケージ形式で受信する。Ｓ３０１で受信した各機器用のファームウエアには、起動用プログラム部分と、アプリケーション部分と、各部分のアドレス情報が記述されたヘッダとが含まれている。また、インストーラにはそれぞれのプログラムの実行順序が規定されており、起動用プログラム部分の更新が先に行われるように規定されている。

Ｓ３０２において、ＣＰＵ２は、Ｓ３０１で取得した本体機器１００用のファームウエアにより、本体機器１００のファームウエアを更新する。本実施例では、現在のＲＯＭ１に格納されている本体機器起動用プログラム９のみを更新する。具体的には、まず、ＣＰＵ２は、Ｓ３０１で取得した本体機器１００用のファームウエアのヘッダを参照し、起動用プログラム部分の開始アドレスと終端アドレスとを取得し、起動用プログラム部分を抽出する。そして、ＣＰＵ２は、その抽出された起動用プログラム部分により、現在のＲＯＭ１に格納されている本体機器起動用プログラム９を更新する。その更新時には、チェックサムやＭＤ５等を用いたハッシュ値チェックや、ＲＯＭサイズチェックを行って、更新したファームウエアの妥当性を検証するようにしても良い。

このように、本実施例では、Ｓ３０１で取得した本体機器１００用のファームウエアにより、本体機器起動用プログラム９と本体機器用アプリケーション１０の両方を更新するのではなく、まず、本体機器起動用プログラム９のみを更新する。従来では、本体機器１００用のファームウエアの更新の際には、起動用プログラム部分とアプリケーション部分とを区別せず、両方を一括して更新していた。従って、その更新後に再起動等により本体機器１００のシステムを起動させて初めて、本体機器１００がユーザ使用可能な状態となっていた。一方、本実施例では、本体機器１００用のファームウエアの更新の際、まず、本体機器起動用プログラム９についてのみ行うので、最低限本体機器１００が動作できる部分の更新時間が従来に比べて短縮される。従って、本体機器１００がより早くユーザ使用可能な状態となることができる。これにより、例えば、ユーザによる操作パネルが可能となったり、ユーザが投入した印刷ジョブを処理したりすることができる。また、本体機器１００のシステムが起動することにより、アプリケーション部分の更新がされていなくても、後述するように、周辺機器２００にファームウエアを送信し、ファームウエアを更新させることができる。

Ｓ３０３において、ＣＰＵ２は、本体機器１００に周辺機器２００が接続されているか否かを判定する。例えば、ＣＰＵ２は、周辺機器２００のＣＰＵ７とテスト通信を行うことにより接続を確認するようにしても良い。Ｓ３０３で接続されていると判定された場合には、Ｓ３０４に進む。一方、接続されていないと判定された場合には、Ｓ３０５に進む。

Ｓ３０４において、ＣＰＵ２は、周辺機器起動用プログラム１１と周辺機器用アプリケーション１２及び１３のそれぞれについてファームウエア強制更新フラグが設定されたフラグデータを生成する。ここで、ファームウエア強制更新フラグとは、周辺機器２００に、ファームウエアのバージョン確認処理をスキップさせてファームウエアの更新を強制的に開始させるためのフラグである。ファームウエア強制更新フラグを設定することにより、不要なチェックを行う必要がなくなり、バージョンが一致していてもファームウエアが正しく更新できていなかった場合にも更新することができる。Ｓ３０４では、ＣＰＵ２は、ＲＯＭ１に格納されている周辺機器起動用プログラム１１と、周辺機器２００のＲＯＭ６に格納されている周辺機器起動用プログラム１４とが整合していないと判定した場合に、周辺機器起動用プログラム１１についてのファームウエア強制更新フラグを有効に設定する。例えば、ＣＰＵ２は、バックアップとして確保しておいた更新前の周辺機器起動用プログラム１４についてのバージョン情報と、現在の周辺機器起動用プログラム１１のバージョン情報とを比較して異なっていれば、ファームウエア強制更新フラグを有効に設定するようにしても良い。周辺機器用アプリケーション１２及び１３と、周辺機器用アプリケーション１５及び１６との整合性の判定についても同様に行う。

Ｓ３０５において、ＣＰＵ２は、更新した本体機器起動用プログラム９を用いてシステム起動処理を行うために、本体機器１００の再起動を行う。なお、再起動前に、ＣＰＵ２は、Ｓ３０１で取得した本体機器１００用のファームウエアと周辺機器２００用のファームウエアは、ハードディスク等の記憶領域に保存しておく。本実施例では、再起動が完了することで、更新処理が完了となる。

図４は、周辺機器２００用のファームウエアの更新処理の手順を示すフローチャートである。周辺機器２００用のファームウエアの更新は、図３の本体機器１００用のファームウエア（本実施例では、本体機器１００用のファームウエアのうち起動用プログラムのみ）を更新した後に開始される。周辺機器２００用のファームウエアの更新は、本体機器１００のファームウエアの更新の際に本体機器１００に周辺機器２００が接続されている場合は、図３のファームウエアの更新と連続して行えばよいが、これに限定されるものではない。本体機器１００に周辺機器２００が接続されていない状態で、図３の処理により本体機器起動用プログラムが更新された場合には、その後に周辺機器２００が本体機器１００に接続された際に周辺機器２００のファームウエアの更新処理が開始される。Ｓ４０１において、本体機器１００のＣＰＵ２は、本体機器１００を起動する。本体機器１００に周辺機器２００が接続されている状態で、図３のＳ３０５の処理が行われた場合は、Ｓ４０１は、図３のＳ３０５に対応する。

Ｓ４０２において、本体機器１００のＣＰＵ２は、Ｓ３０３と同様に、本体機器１００に周辺機器２００が接続されているか否かを判定する。ここで、周辺機器２００が接続されていないと判定された場合には、図４の本処理を終了する。一方、周辺機器２００が接続されていると判定された場合には、本体機器１００のＣＰＵ２は、再起動前に保存しておいた周辺機器２００用のファームウエアから、そのヘッダに基づいて、起動用プログラム部分とアプリケーション部分とを抽出する。本体機器１００のＣＰＵ２は、周辺機器２００用のファームウエアから抽出した起動用プログラム部分とアプリケーション部分により、ＲＯＭ１の周辺機器起動用プログラム１１と周辺機器用アプリケーション１２及び１３を更新する。また、本体機器１００のＣＰＵ２は、周辺機器２００に対して通信インタフェース４を介して、Ｓ３０４で生成されたフラグデータと、抽出された起動用プログラム部分及びアプリケーション部分とを個別に送信してＳ４０３に進む。

Ｓ４０３において、周辺機器２００のＣＰＵ７は、本体機器１００から受信したフラグデータを参照して、周辺機器起動用プログラム１１についての強制更新フラグが有効に設定されているか否かを判定する。ここで、有効に設定されていると判定された場合には、Ｓ４０４に進む。一方、有効に設定されていないと判定された場合には、Ｓ４０５に進む。

Ｓ４０４において、周辺機器２００のＣＰＵ７は、本体機器１００から受信した周辺機器起動用プログラム部分により、現在ＲＯＭ６に格納されている周辺機器起動用プログラム１４を更新する。

Ｓ４０３で有効に設定されていないと判定された場合には、Ｓ４０５において、周辺機器２００のＣＰＵ７は、本体機器１００から受信した周辺機器起動用プログラム部分と、現在ＲＯＭ６に格納されている周辺機器起動用プログラム１４とのバージョンを比較する。ここで、バージョンが一致していない場合には、Ｓ４０４の処理が実行される。一方、バージョンが一致している場合には、周辺機器起動用プログラム１４の更新を行わずに、Ｓ４０６に進む。また、Ｓ４０３において、強制更新フラグの設定内容が何らかの理由により確認できない場合には、更新を行わないとすると周辺機器２００が正常に起動できないおそれがあるので、周辺機器起動用プログラム１４の更新を行うこととする。

ここまでの処理で、周辺機器起動用プログラム１４は最新の状態、即ち、周辺機器起動用プログラム１１に更新されたことになる。つまり、周辺機器２００も、システム起動処理に必要な起動用プログラムの更新が完了したということなので、周辺機器２００を再起動してシステム起動処理を開始することができる。

このように、本実施例においては、周辺機器２００用のファームウエアについても、まず、周辺機器起動用プログラムについてのみ更新を行う。従って、周辺機器２００についても、周辺機器２００が最低限動作できる部分の更新時間が従来に比べて短縮され、その結果、周辺機器２００がより早くユーザ使用可能状態（例えば、ユーザ指示に従って周辺機器２００を設定する等）となることができる。

また、周辺機器２００におけるＳ４０３〜Ｓ４０５の処理中に、本体機器１００側では、本体機器１００自身の処理を並行して進行させることができる。つまり、本体機器１００のＣＰＵ２が本体機器１００自身の処理中のタイミングで周辺機器２００に対して周辺機器起動用プログラムを送信することができるので、本体機器１００のシステム起動処理と周辺機器２００のシステム起動処理とを並行して行うことが可能となる。その結果、本体機器１００及び周辺機器２００の構成全体としても、従来に比べてより早くユーザ使用可能な状態となることができる。

また、図４のＳ４０４に記載したように、ＲＯＭ６に格納されている周辺機器起動用プログラム１４を更新した後は、周辺機器２００のＣＰＵ７は、その更新後、強制更新フラグを無効に設定して、本体機器１００に返信する。本体機器１００のＣＰＵ２は、その返信により、周辺機器２００において周辺機器起動用プログラムの更新が行われたことを認識することができる。なお、周辺機器起動用プログラムの更新後に周辺機器２００が正常に起動できない場合には、通信エラーもしくはファームウエア送受信エラーとしてディスプレイ等やＬＥＤ等でエラー表示を行う。

Ｓ４０６以降は、周辺機器用アプリケーションの更新についての処理である。Ｓ４０６以降の処理は、本体機器１００のシステム起動処理中のタイミングで実行される場合もあるが、その他のタイミングで実行される場合もある。例えば、システム起動処理後の本体機器１００のアイドル中やスリープ処理前のタイミングや、周辺機器用アプリケーションの実行前や実行中のタイミングで実行される場合もある。

図４においては、周辺機器２００のＣＰＵ７は、本体機器１００から周辺機器起動用プログラム部分とアプリケーション部分とを受信すると、自律的に、周辺機器起動用プログラム１４のみを先に更新している。しかしながら、本体機器１００のＣＰＵ２は、本体機器１００のシステム起動中に、周辺機器起動用プログラム部分のみを周辺機器２００に送信して更新させるように制御しても良い。その場合に、周辺機器２００では、当然のことながら、周辺機器起動用プログラム１４のみが更新される。そして、本体機器１００のＣＰＵ２は、その後、周辺機器２００に対して、各アプリケーション部分を送信して更新させるように制御しても良い。その場合の各アプリケーション部分の送信タイミングは、例えば、上記のような、本体機器１００のシステム起動処理中のタイミング、システム起動処理後の本体機器１００のアイドル中やスリープ処理前のタイミングや、本体機器１００の周辺機器用アプリケーションの実行前や実行中のタイミングでも良い。

また、周辺機器用アプリケーションは複数存在可能であるので、アプリケーションごとに、周辺機器用アプリケーションの更新タイミングを定義しても良い。例えば、本体機器１００が大判プリンタであり、周辺機器２００が測色器であるとする。その場合に、測色器の測色センサのランプ調整中のタイミングで、乾燥ファンについての周辺機器用アプリケーションの更新を行っても良い。又は、測色器においてパッチ印刷物の乾燥処理中のタイミングで、測色キャリッジについての周辺機器用アプリケーションの更新を行っても良い。このように、異なるアプリケーションが実行されている間に、更新対象の周辺機器用アプリケーションの更新を行うことで、ユーザにアプリケーションの更新時間を意識させることがなく、利便性を向上させることができる。

Ｓ４０６において、周辺機器２００のＣＰＵ７は、本体機器１００から受信したフラグデータを参照して、周辺機器用アプリケーション１２についての強制更新フラグが有効に設定されているか否かを判定する。ここで、有効に設定されていると判定された場合には、Ｓ４０７に進む。一方、有効に設定されていないと判定された場合には、Ｓ４０８に進む。

Ｓ４０７において、周辺機器２００のＣＰＵ７は、本体機器１００から受信した周辺機器用アプリケーション部分により、現在ＲＯＭ６に格納されている周辺機器用アプリケーション１５を更新する。周辺機器２００のＣＰＵ７は、その更新後、強制更新フラグを無効に設定して、本体機器１００に返信する。本体機器１００のＣＰＵ２は、その返信により、周辺機器２００において周辺機器用アプリケーションの更新が行われたことを認識することができる。

Ｓ４０６で有効に設定されていないと判定された場合には、Ｓ４０８において、周辺機器２００のＣＰＵ７は、本体機器１００から受信した周辺機器用アプリケーション部分と、現在ＲＯＭ６に格納されている周辺機器用アプリケーション１５とのバージョンを比較する。ここで、バージョンが一致していない場合には、Ｓ４０７の処理が実行される。一方、バージョンが一致している場合には、周辺機器用アプリケーション１５の更新を行わない。周辺機器２００のＣＰＵ７は、周辺機器用アプリケーション１６の更新についても、Ｓ４０６〜Ｓ４０８の処理と同様に行う。

本実施例においては、図２に示すように、本体機器１００及び周辺機器２００ともに、ファームウエアすべて、すなわち、起動用プログラム及びアプリケーションをＲＯＭに格納している。しかしながら、起動用プログラムとアプリケーションとを相異なる記憶領域に格納するようにしても良い。例えば、システム起動用の起動用プログラムは更新される可能性が少ないので、フラッシュＲＯＭ領域に格納し、アプリケーションは更新される可能性が高いので、プログラム実行時の実行速度を速めるためにＲＡＭ領域に格納する。

周辺機器２００のＣＰＵ７が周辺機器起動用プログラム１４〜周辺機器用アプリケーション１６の更新を行う際には、本体機器１００に対して、更新前の周辺機器起動用プログラム１４〜周辺機器用アプリケーション１６を送信するようにしても良い。その結果、本体機器１００は、更新前の周辺機器起動用プログラム１４〜周辺機器用アプリケーション１６をバックアップとして確保しておくことができる。

以上のように、本実施例においては、本体機器１００は、本体機器用のファームウエアを起動用プログラムとアプリケーションの２つに区別して記憶領域に保存することにより、別々に更新を可能にしている。その結果、本体機器１００は、ファームウエアのうち起動用プログラムのみを先に更新することにより、ファームウエアを一括して更新していた従来構成に比べて、更新時間を短縮し、より早く機器をユーザ使用可能状態とすることができる。

また、本体機器では、周辺機器２００のファームエアを保存する構成としているので、本体機器１００に周辺機器２００が接続されていない場合でも、本体機器１００は正常に作動し、周辺機器用のファームウエアの更新情報を受信して保存することができる。したがって、例えば、本体機器１００から周辺機器２００を取り外した際に外部から周辺機器用のファームウエアの受信が行われた場合、本体機器１００に周辺機器２００が再度接続された際に、周辺機器２００のファームウエアを更新することができる。これにより、本体機器１００と周辺機器２００のファームウエアのバージョン等の不整合の発生を抑制することができる。

また、本体機器１００では、周辺機器用のファームウエアについても、起動用プログラムとアプリケーションの２つに区別して記憶領域に保存している。これにより、本体機器１００は、周辺機器２００に、起動用プログラムのみを送信することができ、一度に送信するデータ量を減らすことができる。これにより、本体機器１００と周辺機器２００の通信速度が遅い場合であっても、起動用プログラムの短時間で送信することができる。また、本体機器１００に周辺機器２００が接続され、本体機器１００が周辺機器２００のファームウエアを更新する場合においても、周辺機器２００は、起動用プログラムのみを先に更新することにより、更新時間を短縮し、より早くユーザ使用可能状態とすることができる。

また、本体機器１００は、再起動後のシステム起動処理時に、周辺機器２００に対して周辺機器起動用プログラムを送信すればよいので、両機器のシステム起動を並行して実行することができ、両機器全体としても、より早くユーザ使用可能状態とすることができる。

なお、Ｓ３０１で取得した本体機器１００用のファームウエアからそのヘッダに基づいて抽出したアプリケーション部分により、ＲＯＭ１の本体機器用アプリケーション１０を更新するタイミングは特に限定されない。例えば、Ｓ３０２において更新してもよく、また、周辺機器用のファームウエアを周辺機器２００に送信した後にＲＯＭ１の本体機器用アプリケーション１０を更新してもよい。

また、本実施例では、Ｓ３０３及びＳ３０４の後に、本体機器を再起動して本体機器起動用プログラムを更新するようにしたが、Ｓ３０２の後に、周辺機器が接続されているか確認せずに更新を行うようにしてもよい。

本実施例では、本体機器１００が周辺機器２００と接続可能なものとしたが、本体機器１００のみの場合でも、本体機器用のファームウエアを起動用プログラムとアプリケーションとに区別して記憶することにより、本発明の効果を得ることができる。なお、本実施例では、本体機器用のファームウエアを、本体機器起動用プログラム９と本体機器用アプリケーション１０とに区別するようにしたが、本体機器用のファームウエアを区別しなくてもよい。周辺機器用のファームウエアのみを、起動用プログラムと、アプリケーションとに区別するようにした場合は、周辺機器２００に対する周辺機器用のファームウエアの更新の時間を短くして、ユーザの使用可能状態となる時間を短くすることができる。

本体機器１００において、周辺機器用のファームウエアを区別してＲＯＭ１に格納するようにしたが、本体機器１００では、周辺機器用のファームウエアを区別せずに記憶し、周辺機器２００に送信するようにしてもよい。この場合は、周辺機器２００のＣＰＵ７が、まず、ＲＯＭ６に格納されている起動用プログラム１４のみを更新するようにすればよい。例えば、ＣＰＵ７は、取得したファームウエアのヘッダを参照し、起動用プログラム部分の開始アドレスと終端アドレスとを取得し、起動用プログラム部分を抽出する。そして、ＣＰＵ７は、その抽出された起動用プログラム部分により、現在のＲＯＭ６に格納されている起動用プログラム１４を更新すればよい。 本実施例では、更新後のプログラムは、再起動後に実行可能としたが、再起動させずに反映させることが可能であれば、再起動させずに実行させるようにしてもよい。

また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又はコンピュータ読取可能な各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置の、または複数のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (16)

1. 接続可能である周辺機器が単体で動作するために必要な基本部分と、当該基本部分以外であるアプリケーション部分とを含む周辺機器用のファームウエアを取得する取得手段と、
   前記取得手段により取得された前記周辺機器用のファームウエアの基本部分を抽出する抽出手段と、
   前記周辺機器用のファームウエアのアプリケーション部分を送信するよりも前に、前記抽出手段により抽出された前記周辺機器用のファームウエアの基本部分を前記周辺機器へ送信する送信手段と、
   を備えることを特徴とする情報処理装置。
2. 前記送信手段は、前記周辺機器用のファームウエアの基本部分を送信した後、前記周辺機器用のファームウエアのアプリケーション部分を送信することを特徴とする請求項１に記載の情報処理装置。
3. 前記取得手段により取得された前記周辺機器用のファームウエアを記憶する第１記憶手段、をさらに備え、
   前記送信手段により送信された前記周辺機器用のファームウエアの基本部分は、前記周辺機器が備える第２記憶手段に記憶される、
   ことを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記第１記憶手段はさらに、情報処理装置用のファームウエアを、前記情報処理装置が単体で動作するための基本部分と、当該基本部分以外であるアプリケーション部分とに区別して記憶することを特徴とする請求項３に記載の情報処理装置。
5. 前記第１記憶手段は、前記周辺機器用のファームウエアを、前記周辺機器が単体で動作するために必要な基本部分と、当該基本部分以外であるアプリケーション部分とに区別して記憶することを特徴とする請求項３又は４に記載の情報処理装置。
6. 前記送信手段は、情報処理装置用のファームウエアの基本部分が更新された後且つ前記情報処理装置用ファームウエアのアプリケーション部分が更新される前に、前記周辺機器用のファームウエアの基本部分を前記周辺機器に送信する、ことを特徴とする請求項３乃至５のいずれか１項に記載の情報処理装置。
7. 前記第１記憶手段に記憶された前記周辺機器用のファームウエアの基本部分と前記第２記憶手段に記憶されている周辺機器用のファームウエアの基本部分とが整合していない場合、前記第１記憶手段に記憶された前記周辺機器用のファームウエアの強制更新フラグを設定する設定手段、をさらに備え、
   前記設定手段により前記強制更新フラグが設定された場合、前記周辺機器の前記第２記憶手段に記憶されている前記周辺機器用のファームウエアの基本部分が前記第１記憶手段に記憶されている前記周辺機器用のファームウエアの基本部分で更新される、
   ことを特徴とする請求項３乃至６のいずれか１項に記載の情報処理装置。
8. 前記第１記憶手段に記憶された前記周辺機器用のファームウエアの基本部分と前記第２記憶手段に記憶されている周辺機器用のファームウエアの基本部分との比較に基づき、前記周辺機器の前記第２記憶手段に記憶されている前記周辺機器用のファームウエアの基本部分が前記第１記憶手段に記憶されている前記周辺機器用のファームウエアの基本部分で更新されることを特徴とする請求項３乃至７のいずれか１項に記載の情報処理装置。
9. 前記第１記憶手段に記憶された前記周辺機器用のファームウエアの基本部分のバージョンと前記第２記憶手段に記憶されている前記周辺機器用のファームウエアの基本部分のバージョンとが一致していない場合に、前記周辺機器の前記第２記憶手段に記憶されている前記周辺機器用のファームウエアの基本部分が更新されることを特徴とする請求項８に記載の情報処理装置。
10. 前記第２記憶手段に記憶されている周辺機器用のファームウエアの基本部分が更新された後、前記周辺機器が周辺機器用のファームウエアのアプリケーション部分の更新を行うように前記周辺機器を制御する制御手段、をさらに備えることを特徴とする請求項３乃至９のいずれか１項に記載の情報処理装置。
11. 前記抽出手段は、前記取得手段により取得された前記周辺機器用のファームウエアのヘッダを参照して、前記取得手段により取得された前記周辺機器用のファームウエアの基本部分と、前記取得手段により取得された前記周辺機器用のファームウエアのアプリケーション部分とを抽出する、ことを特徴とする請求項１乃至１０のいずれか１項に記載の情報処理装置。
12. 前記周辺機器は、周辺機器用のファームウエアの基本部分を更新した後、周辺機器用のファームウエアのアプリケーション部分を更新するように、前記情報処理装置により制御される、ことを特徴とする請求項１乃至１１のいずれか１項に記載の情報処理装置。
13. 前記周辺機器が単体で動作するために必要な基本部分は、ブートプログラムとカーネルとを含むことを特徴とする請求項１乃至１２のいずれか１項に記載の情報処理装置。
14. 前記送信手段は、前記情報処理装置の再起動後に、前記周辺機器用のファームウエアの基本部分を送信することを特徴とする請求項１乃至１３のいずれか１項に記載の情報処理装置。
15. 情報処理装置において実行されるファームウエアの更新方法であって、
    接続可能である周辺機器が単体で動作するために必要な基本部分と、当該基本部分以外であるアプリケーション部分とを含む周辺機器用のファームウエアを取得する取得工程と、
    前記取得工程において取得された前記周辺機器用のファームウエアの基本部分を抽出する抽出工程と、
    前記周辺機器用のファームウエアのアプリケーション部分を送信するよりも前に、前記抽出工程において抽出された前記周辺機器用のファームウエアの基本部分を前記周辺機器へ送信する送信工程と、
    を有することを特徴とするファームウエアの更新方法。
16. 請求項１乃至１４のいずれか１項に記載の情報処理装置の各手段としてコンピュータを機能させるためのプログラム。

Images