(57)【要約】【課題】  複数の領域に格納されているファームウェアの更新をより容易にする技術を提供する。【解決手段】  装置のファームウェアが更新される装置は、別個に更新可能なＮ個（Ｎは２以上の整数）のファームウェアの格納領域を備えている。このＮ個の格納領域のうちのＭ個（Ｍは１以上Ｎ以下の整数）の格納領域を更新する統合更新データは、Ｍ個の個別更新データが連続したデータとして構成されている。各個別更新データを１つずつ順次受信する個別受信モードでは、統合更新データの先頭から１つの格納領域の更新のために必要な更新データ部分までを外部から受信した後に後続の更新データの受信を停止し、受信した更新データ部分を用いて１つの格納領域の更新し、１つの格納領域の更新の完了後に後続の更新データの受信を再開することが、更新ファームウェアの数Ｍに応じて繰り返し実行される。【選択図】  図５
2007087133.tif 000002
【特許請求の範囲】
【請求項１】
別個に更新可能なＮ個（Ｎは２以上の整数）のファームウェア格納領域を備える装置のファームウェアを更新する方法であって、
前記ファームウェア更新方法は、前記Ｎ個のファームウェア格納領域のうちのＭ個（Ｍは１以上Ｎ以下の整数）のファームウェア格納領域のためのＭ個の個別更新データを含み、前記Ｍ個の個別更新データが連続したデータとして構成されている統合更新データのうちの各個別更新データを１つずつ順次受信する個別受信モードを含み、
前記個別受信モードは、
（ａ）前記統合更新データのうちの先頭から順に、１つのファームウェア格納領域の更新のために必要な更新データ部分までを外部から受信した後に、後続の更新データの受信を停止する工程と、
（ｂ）前記受信した更新データ部分を用いて、前記１つのファームウェア格納領域の更新を実行する工程と、
（ｃ）前記１つのファームウェア格納領域の更新の完了後に、前記後続の更新データの受信を再開する工程と、
（ｄ）上記工程（ａ）ないし（ｃ）を、前記統合更新データに含まれている更新ファームウェアの数Ｍに応じて繰り返す工程と、
を備える、ファームウェア更新方法。
【請求項２】
請求項１記載のファームウェア更新方法であって、
前記Ｍ個の個別更新データのそれぞれは、対応するファームウェア格納領域に格納されるファームウェアデータと、前記ファームウェアデータに関する情報を有するファームウェアヘッダと、を含む、ファームウェア更新方法。
【請求項３】
請求項２記載のファームウェア更新方法であって、
前記工程（ａ）は、
前記ファームウェアヘッダを含むデータを外部から受信する工程と、
前記受信したデータに含まれるファームウェアヘッダに基づいて、前記更新データ部分を受信する工程と、
を含む、前記ファームウェアヘッダの解析
【請求項４】
請求項２または３記載のファームウェア更新方法であって、
前記工程（ｂ）は、前記受信した更新データ部分に含まれるファームウェアヘッダに基づいて、更新する前記１つのファームウェア格納領域を決定する工程を含む、ファームウェア更新方法。
【請求項５】
請求項１ないし４のいずれか記載のファームウェア更新方法であって、
前記ファームウェア更新方法は、さらに、
前記統合更新データの全体を受信した後、前記Ｍ個のファームウェア格納領域を更新する全体受信モードを含み、
前記個別受信モードと前記全体受信モードのうちの一方を、前記装置内で利用可能な一時メモリ量に応じて選択する、ファームウェア更新方法。
【請求項６】
別個に更新可能なＮ個（Ｎは２以上の整数）のファームウェア格納領域を備える装置であって、
前記Ｎ個のファームウェア格納領域のうちのＭ個（Ｍは１以上Ｎ以下の整数）のファームウェア格納領域のためのＭ個の個別更新データを含み、前記Ｍ個の個別更新データが連続したデータとして構成されている統合更新データのうちの各個別更新データを１つずつ順次受信する個別受信モードを有するファームウェア更新制御部を備え、
前記ファームウェア更新制御部は、
前記統合更新データのうちの先頭から順に、１つのファームウェア格納領域の更新のために必要な更新データ部分までを外部から受信した後に、後続の更新データの受信を停止し、
前記受信した更新データ部分を用いて、前記１つのファームウェア格納領域の更新し、
前記１つのファームウェア格納領域の更新の完了後に、前記後続の更新データの受信を再開することを、
前記統合更新データに含まれている更新ファームウェアの数Ｍに応じて、繰り返し実行する、装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ファームウェアを更新する技術に関する。
【背景技術】
【０００２】
スキャナ・プリンタ・コピー複合機（以下、単に「複合機」と呼ぶ）やルータ等の装置では、複合機やルータとしての機能を実現するため、これらの装置が備える中央処理装置がＲＯＭに格納された制御ソフトウェア（コンピュータプログラム）を実行する。このような制御ソフトウェア（「ファームウェア」と呼ばれる）は、装置の機能の改良等のため更新される場合がある。
【０００３】
【特許文献１】特開２００４−２７２７７０号公報
【０００４】
ところで、ファームウェアが格納されるＲＯＭが複数ある場合、個々のＲＯＭに格納されたファームウェアの更新はＲＯＭごとに実行される。そのため、複数のＲＯＭを更新する際、個々のＲＯＭごとにファームウェア更新のための更新データを準備し、その更新データによるファームウェアの更新が必要となる場合があった。この場合、ユーザには、ＲＯＭごとの更新データの準備とファームウェアの更新の操作が要求されるために、ユーザによる操作が煩雑になる場合がある。この問題は、ファームウェアが複数のＲＯＭに格納されている場合に限らず、一般に、ファームウェアが複数の領域に格納されている場合に共通する。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明は、上述した従来の課題を解決するためになされたものであり、複数の領域に格納されているファームウェアの更新をより容易にする技術を提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記目的の少なくとも一部を達成するために、本発明のファームウェア更新方法は、別個に更新可能なＮ個（Ｎは２以上の整数）のファームウェア格納領域を備える装置のファームウェアを更新する方法であって、前記ファームウェア更新方法は、前記Ｎ個のファームウェア格納領域のうちのＭ個（Ｍは１以上Ｎ以下の整数）のファームウェア格納領域のためのＭ個の個別更新データを含み、前記Ｍ個の個別更新データが連続したデータとして構成されている統合更新データのうちの各個別更新データを１つずつ順次受信する個別受信モードを含み、前記個別受信モードは、（ａ）前記統合更新データのうちの先頭から順に、１つのファームウェア格納領域の更新のために必要な更新データ部分までを外部から受信した後に、後続の更新データの受信を停止する工程と、（ｂ）前記受信した更新データ部分を用いて、前記１つのファームウェア格納領域の更新を実行する工程と、（ｃ）前記１つのファームウェア格納領域の更新の完了後に、前記後続の更新データの受信を再開する工程と、（ｄ）上記工程（ａ）ないし（ｃ）を、前記統合更新データに含まれている更新ファームウェアの数Ｍに応じて繰り返す工程と、を備えることを特徴とする。
【０００７】
この構成によれば、Ｍ個のファームウェア格納領域のそれぞれを、単一の統合更新データにより更新することができるので、複数の領域に格納されているファームウェアの更新がより容易となる。
【０００８】
前記Ｍ個の個別更新データのそれぞれは、対応するファームウェア格納領域に格納されるファームウェアデータと、前記ファームウェアデータに関する情報を有するファームウェアヘッダと、を含むものとしても良い。
【０００９】
この構成によれば、Ｍ個の個別更新データのそれぞれにファームウェアデータに関する情報が格納することができる。そのため、Ｍ個の個別更新データを結合させることで統合更新データが生成できるので、統合更新データの生成がより容易となる。
【００１０】
前記工程（ａ）は、前記ファームウェアヘッダを含むデータを外部から受信する工程と、前記受信したデータに含まれるファームウェアヘッダに基づいて、前記更新データ部分を受信する工程と、を含むものとしても良い。
【００１１】
この構成によれば、Ｍ個の個別更新データのそれぞれに１つのファームウェア格納領域の更新のために必要な更新データ部分を指定する情報を格納することができるので、統合更新データの生成がより容易となる。
【００１２】
前記工程（ｂ）は、前記受信した更新データ部分に含まれるファームウェアヘッダに基づいて、更新する前記１つのファームウェア格納領域を決定する工程を含むものとしても良い。
【００１３】
この構成によれば、ファームウェアヘッダに基づいて決定されたファームウェア格納領域が対応するファームウェアデータにより更新されるので、ファームウェアの更新をより確実に行うことができる。
【００１４】
前記ファームウェア更新方法は、さらに、前記統合更新データの全体を受信した後、前記Ｍ個のファームウェア格納領域を更新する全体受信モードを含み、前記個別受信モードと前記全体受信モードのうちの一方を、前記装置内で利用可能な一時メモリ量に応じて選択するものとしても良い。
【００１５】
この構成によれば、一時メモリの使用量が少ない個別受信モードと、統合更新データの受信に要する時間が短い全体受信モードと、を装置内で利用可能な一時メモリ量に応じて選択することができるので、ファームウェアの更新をより適切に行うことができる。
【００１６】
なお、本発明は、種々の態様で実現することが可能であり、例えば、ファームウェアを備える装置、その装置のファームウェア更新装置、方法およびシステム、それらの装置、方法またはシステムの機能を実現するためのコンピュータプログラム、そのコンピュータプログラムを記録した記録媒体、そのコンピュータプログラムを含み搬送波内に具現化されたデータ信号、等の態様で実現することができる。
【発明を実施するための最良の形態】
【００１７】
次に、本発明の実施の形態を実施例に基づいて以下の順序で説明する。
Ａ．システムの概要：
Ｂ．データ転送の制御：
Ｃ．ファームウェアの更新：
Ｄ．第２実施例：
Ｅ．変形例：
【００１８】
Ａ．システムの概要：
図１は、本発明の一実施例を適用するコンピュータシステム１００の構成を示す説明図である。このコンピュータシステム１００は、ユニバーサルプラグアンドプレイブリッジ（ＵＰｎＰブリッジ）２００に、パーソナルコンピュータ１１０と、スキャナ・プリンタ・コピー複合機（ＭＦＰ）１２０と、が接続されている。ここで、ＵＰｎＰブリッジとは、ネットワーク処理機能を持たない装置を接続し、接続された装置の機能をユニバーサルプラグアンドプレイ（Universal Plug and Play：UPnPは、UPnP Implementers Corporationの商標）におけるサービスとしてネットワークに提供するネットワーク装置をいう。
【００１９】
ＵＰｎＰブリッジ２００は、ネットワークユニット３００と、デバイスユニット４００と、ネットワークユニット３００およびデバイスユニット４００に電力を供給する電源回路２１０と、を備えている。
【００２０】
ネットワークユニット３００は、中央制御部（ＣＰＵ）３１０と、ＲＡＭ３２０と、ＲＯＭ３３０と、ネットワーク制御部３４０と、ＵＳＢホスト制御部３５０とを有している。ＲＯＭ３３０には、ネットワークユニット３００の制御ソフトウェア（「ファームウェア」と呼ばれる）が格納されている。中央制御部３１０は、このファームウェアを実行することにより、ネットワークユニット３００が有する種々の機能を実現する。
【００２１】
ネットワーク制御部３４０は、コネクタ３４２を介して有線ネットワークに接続される。ＵＳＢホスト制御部３５０は、ルートハブ３５２を有しており、ルートハブ３５２には２つのＵＳＢコネクタ３５４，３５６が設けられている。第１のＵＳＢコネクタ３５４は、ＵＳＢケーブルを介してデバイスユニット４００のＵＳＢコネクタ４６２に接続されている。第２のＵＳＢコネクタ３５６には、追加のデバイス（例えば無線ＬＡＮネットワークへ通信するための無線通信回路や他のデバイスユニット）を接続可能である。
【００２２】
デバイスユニット４００は、中央制御部（ＣＰＵ）４１０と、ＲＡＭ４２０と、２つのＲＯＭ４３０，４４０と、２つのＵＳＢデバイス制御部４５０，４６０と、操作パネル制御部４７０と、表示制御部４８０と、ＵＳＢホスト制御部４９０と、電源回路２１０を制御する電源制御部５００とを有している。
【００２３】
２つのＲＯＭ４３０，４４０のそれぞれには、デバイスユニット４００のファームウェアが格納されている。中央制御部４１０は、これら２つのＲＯＭ４３０，４４０に格納されたファームウェアを実行することにより、デバイスユニット４００が有する種々の機能を実現する。なお、ＲＯＭ４３０，４４０として、フラッシュメモリ等の電気的に書換が可能なＲＯＭを使用することにより、デバイスユニット４００のファームウェアを更新することができる。
【００２４】
デバイスユニット４００の第１のＵＳＢデバイス制御部４５０は、ＵＳＢコネクタ４５２を介してネットワークユニット３００のＵＳＢホスト制御部３５０に接続されている。第２のＵＳＢデバイス制御部４６０は、ＵＳＢコネクタ４６２を有している。本実施例では、ファームウェア更新のためＵＳＢコネクタ４６２にパーソナルコンピュータ１１０が接続されているが、一般に、ＵＳＢコネクタ４６２には、任意のＵＳＢホストを接続することが可能である。
【００２５】
操作パネル制御部４７０には、入力手段としての操作パネル４７２が接続されている。表示制御部４８０には、表示部４８２が接続されている。ユーザは、表示部４８２が有する液晶表示器やＬＥＤ表示器等によるＵＰｎＰブリッジの状態表示に応じて操作パネル４７２を操作することにより、種々の指示を入力することができる。
【００２６】
ＵＳＢホスト制御部４９０は、ルートハブ４９２を有しており、ルートハブ４９２にはＵＳＢコネクタ４９４が設けられている。本実施例では、このＵＳＢコネクタ４９４にスキャナ・プリンタ・コピー複合機１２０が接続されているが、ＵＳＢコネクタ４９４には、スキャナやプリンタやマスストレージなどの単一の機能を提供可能なＵＳＢデバイスや、複数の機能を提供可能な多機能複合周辺機器等の任意のＵＳＢデバイスを接続することが可能である。
【００２７】
デバイスユニット４００のファームウェアを更新する場合、ユーザは、デバイスユニット４００をファームウェア更新モードで起動する。デバイスユニット４００は、例えば、ユーザが操作パネル４７２の特定のボタンを押しながらＵＰｎＰブリッジ２００の電源を投入することによりファームウェア更新モードで起動する。このとき、中央制御部４１０は、ファームウェア更新モードの制御を実行するためのファームウェア更新ソフトウェアをＲＡＭ４２０に格納し、ＲＡＭ４２０に格納されたファームウェア更新ソフトウェアを実行する。ファームウェア更新ソフトウェアの実行により、デバイスユニット４００の中央制御部４１０は、ファームウェア更新処理部としての機能を実現する。なお、本実施例では、中央制御部４１０がＲＡＭ４２０に格納されたファームウェア更新ソフトウェアを実行するものとしているが、実行されるファームウェア更新ソフトウェアは、ファームウェア更新の対象とならないＲＯＭ（図示しない）に格納されたものであっても良い。
【００２８】
デバイスユニット４００のファームウェア更新モードでの起動の後、ユーザは、パーソナルコンピュータ１１０上でファームウェア更新用のアプリケーションを起動する。起動されたファームウェア更新アプリケーションにより、ＵＳＢコネクタ４６２に接続されたパーソナルコンピュータ１１０からファームウェア更新のための更新データがデバイスユニット４００に送信される。なお、送信される更新データは、予めパーソナルコンピュータ１１０が備える外部記憶装置（図示しない）に格納されている。
【００２９】
図２は、ファームウェア更新に関する機能の階層構造を示すブロック図である。図２に示すように、パーソナルコンピュータ１１０とデバイスユニット４００との間には、種々の通信チャンネルが設けられている。これらは、パーソナルコンピュータ１１０とデバイスユニット４００の同一階層間における論理的な接続を示している。
【００３０】
パーソナルコンピュータ１１０は、ファームウェア更新アプリケーション１０００から供給されるデータを、Ｄ４プロトコルの論理チャンネル（UPDATE-CONTROLおよびUPDATE-DATA）を介してデバイスユニット４００に転送するＤ４プロトコル処理部１１００を有している。なお、Ｄ４プロトコルとは、ＩＥＥＥ１２８４．４に規定されたパケット（Ｄ４パケット）を用いた通信プロトコルである。
【００３１】
Ｄ４プロトコル処理部１１００よりも下部の階層には、下から順番に、ＵＳＢホストインタフェース（ハードウェア）と、ＵＳＢシステムソフトウェアと、プリンタクラスのクライアントソフトウェアとが設けられている。
【００３２】
デバイスユニット４００のＤ４プロトコル処理部２１００は、Ｄ４プロトコルの論理チャンネルを介して転送された更新データをファームウェアの更新処理を実行するファームウェア更新処理部２０００に供給する。Ｄ４プロトコル処理部２１００よりも下部の構造としては、下から順番に、ＵＳＢデバイスインタフェース（ハードウェア）と、ＵＳＢ論理デバイスと、プリンタクラス論理インタフェースとが設けられている。
【００３３】
Ｂ．データ転送の制御：
図３（ａ）は、Ｄ４プロトコル処理部１１００，２１００間で転送されるＤ４パケットの構成を示す説明図である。このＤ４パケットを転送することにより、Ｄ４プロトコル処理部１１００，２１００間では、Ｄ４プロトコルで規定されたコマンド（Ｄ４コマンド）の転送と、データの転送が行われる。
【００３４】
Ｄ４パケットは、６バイトのヘッダ（Ｄ４ヘッダ）とボディ部分とを有している。Ｄ４ヘッダは、プライマリソケットＩＤ（ＰＳＩＤ）と、セカンダリソケットＩＤ（ＳＳＩＤ）と、パケット長と、制御情報とを含んでいる。Ｄ４ヘッダのパケット長には、Ｄ４ヘッダを含むＤ４パケット全体の長さが登録される。制御情報には、Ｄ４プロトコルにおけるデータの伝送制御を行うための情報が登録される。ボディ部分のデータには、Ｄ４コマンドとそのパラメータや、Ｄ４コマンドに対する応答（Reply）や、転送されるデータが格納される。
【００３５】
Ｄ４コマンドの転送を行う場合、プライマリソケットＩＤとセカンダリソケットＩＤとのそれぞれには、ボディ部分のデータがＤ４コマンドであることを表す０が登録される。一方、データ転送を行う場合、プライマリソケットＩＤとセカンダリソケットＩＤとには、図２に示す論理チャンネルを識別する論理チャンネルＩＤが設定される。データ転送の際に設定される論理チャンネルＩＤには、Ｄ４コマンドの転送と区別するため、０でない値が使用される。
【００３６】
Ｄ４プロトコルにおいては、データ転送のためのＤ４パケット（以下、単に「データパケット」とも呼ぶ）の転送に際し、データの受信側が送信側に対して転送可能なデータパケット数（「クレジット数」と呼ばれる）を通知する。これにより、送信側は、クレジット数までのデータパケットを受信側に送信することができる。このように、受信側から通知されたクレジット数により送信側の送信パケット数が設定されるので、受信側によるクレジット数の通知は、「クレジットの提供」とも呼ばれる。また、送信側の受信側に対するクレジット数の通知の要求は、「クレジットの要求」とも呼ばれる。
【００３７】
図３（ｂ）は、クレジット要求で使用されるＤ４コマンドの一例を示している。図３（ｂ）は、クレジット要求（CreditRequest）コマンドと呼ばれるＤ４コマンドである。このクレジット要求コマンドは、Ｄ４コマンドの送信側が受信側に対して、要求するクレジット数を指定し、受信側が受取可能なパケット数の通知を要求する。なお、クレジット要求コマンドを送信する際、Ｄ４ヘッダのプライマリソケットＩＤとセカンダリソケットＩＤには０が格納される。
【００３８】
クレジット要求コマンドを転送するＤ４パケットのボディ部分は、図３（ｂ）に示すように、クレジット要求コマンドであることを表すコマンド（Command）と、プライマリソケットＩＤと、セカンダリソケットＩＤと、要求クレジット数（Credit Requested）と、最大必要クレジット数（Maximum Outstanding Credit）と、を含んでいる。プライマリソケットＩＤと、セカンダリソケットＩＤと、要求クレジット数と、最大必要クレジット数とは、それぞれクレジット要求コマンドのパラメータとなっている。
【００３９】
クレジット要求コマンドのパラメータのうち、プライマリソケットＩＤとセカンダリソケットＩＤには、クレジット要求の対象となる論理チャンネルＩＤが指定される。要求クレジット数と最大必要クレジット数には、送信すべきデータの大きさや送信バッファの大きさ等に応じてその値を適宜設定することが可能である。また、これらの要求クレジット数と最大必要クレジット数とを特定の値に設定することにより、受信側に提供可能な最大量のクレジット数を提供することを要求する非制限クレジット（Unlimited Credit）モードのクレジット要求を行うことも可能である。なお、本実施例において、特にことわらないかぎり、クレジット要求は非制限クレジットモードのクレジット要求である。
【００４０】
図３（ｃ）は、受信側がクレジット要求コマンドに対する応答（クレジット要求応答）を転送するＤ４パケットを示している。クレジット要求コマンドに対する応答を転送するＤ４パケットのボディ部分は、図３（ｃ）に示すように、クレジット要求コマンドに対する応答であることを表すコマンドと、コマンドに対する結果を表すリザルト（Result）と、プライマリソケットＩＤと、セカンダリソケットＩＤと、提供クレジット数（Credit）と、を含んでいる。クレジット要求応答のＤ４パケットに含まれる、コマンドと、プライマリソケットＩＤと、セカンダリソケットＩＤとは、それぞれ図３（ｂ）に示すクレジット要求コマンドのＤ４パケットに含まれるものに対応する。
【００４１】
図３（ｃ）に示すクレジット要求応答のＤ４パケットに含まれるリザルトには、クレジット要求コマンドの成否を示すリザルトコードが登録される。また、クレジット要求応答のＤ４パケットに含まれる提供クレジット数は、受信側が送信側に対して通知する転送可能なデータパケット数である。
【００４２】
Ｄ４プロトコル処理部１１００，２１００（図２）よりも上位の階層で使用されるコマンド（上位コマンド）は、Ｄ４パケットのボディ部分に格納され、予め定められた特定の文字列を表すデータとして転送される。そのため、上位コマンドを転送するために、上位コマンドを転送するための論理チャンネルについてのクレジットの要求およびクレジットの提供が、上位コマンドの転送に先だって行われる。
【００４３】
Ｃ．ファームウェアの更新：
図４は、デバイスユニット４００（図１）のファームウェア更新に用いられる更新データ７００の構成を示す説明図である。図４（ａ）に示すように、更新データ７００は、第１のＲＯＭ４３０（図１）に対応する第１のＲＯＭデータ７１０と、第２のＲＯＭ４４０（図１）に対応する第２のＲＯＭデータ７１０と、を含んでいる。
【００４４】
第１のＲＯＭデータ７１０は、第１のヘッダ７１２と、第１のＲＯＭ４３０に格納される第１の格納データとを含んでいる。この第１のヘッダ７１２には、図４（ｂ）に示すように、格納データが格納されるＲＯＭのデバイス番号（１）と、格納データのバージョン番号（１．２３）と、格納データの大きさ（データサイズ＝６４Ｍ）と、格納データのチェックサム（Ｃ４８Ａ）とが、含まれている。
【００４５】
第２のＲＯＭデータ７２０は、第２のヘッダ７２２と、第２のＲＯＭ４４０に格納される第２の格納データとを含んでいる。この第２のヘッダ７２２には、図４（ｂ）に示すように、格納データが格納されるＲＯＭのデバイス番号（２）と、格納データのバージョン番号（２．３２）と、格納データのデータサイズ（３２Ｍ）と、格納データのチェックサム（４Ｄ５８）とが、含まれている。
【００４６】
なお、第１と第２のＲＯＭデータ７１０，７２０は、それぞれ第１と第２のＲＯＭ４３０，４４０の更新に使用されるデータであるので、個別更新データとも言うことができる。また、図４に示すように、更新データ７００は、個別更新データである２つのＲＯＭデータが連続したデータとして構成されているので、統合更新データであるとも言うことができる。
【００４７】
図５は、デバイスユニット４００（図１）により実行されるデバイスユニット４００のファームウェア更新実行ルーチンを示すフローチャートである。
【００４８】
ステップＳ１００において、デバイスユニット４００は、ファームウェア更新モードで起動する。デバイスユニット４００は、上述のように、ユーザによる操作に従ってファームウェア更新ソフトウェアが実行されることにより、ファームウェア更新モードで起動する。
【００４９】
ステップＳ２００において、デバイスユニット４００は、パーソナルコンピュータ１１０（図１）からデータ転送開始コマンドを受信するまで待機する。データ転送開始コマンドを受信した場合、制御はステップＳ３００ａに移される。一方、データ転送開始コマンドを受信していない場合、制御は戻され、デバイスユニット４００がデータ転送開始コマンドを受信するまでステップＳ２００が繰り返し実行される。
【００５０】
図６は、デバイスユニット４００がパーソナルコンピュータ１１０からのデータ転送開始コマンドを受信する様子を示すシーケンス図である。図６の細い矢印は、Ｄ４コマンドとＤ４コマンドに対する応答を表している。図６の太い矢印は、UPDATE-CONTROLチャンネル（図２）によるデータの転送を表している。
【００５１】
ステップ[ST1]において、パーソナルコンピュータ１１０はデバイスユニット４００に、UPDATE-CONTROLチャンネルについてクレジット要求を行う。デバイスユニット４００は、ステップ[ST2]において、ステップ[ST1]のクレジット要求に対して１のクレジットを提供する。
【００５２】
ステップ[ST3]において、パーソナルコンピュータ１１０は、UPDATE-CONTROLチャンネルを介して１つのＤ４パケットをデバイスユニット４００に送信する。送信されるＤ４パケットのボディ部分には、データ転送の開始をデバイスユニット４００に指示するコマンドが登録されている。
【００５３】
ステップ[ST4]において、パーソナルコンピュータ１１０は、デバイスユニット４００に対し１のクレジットを提供する。このクレジットの提供は、Ｄ４コマンドのクレジット提供コマンド（Credit）により行われる。デバイスユニット４００は、ステップ[ST5]においてステップ[ST4]のクレジット提供コマンドに応答する。そして、ステップ[ST6]において、データ転送を開始可能であることを表すデータ（データ転送開始応答）がボディ部分に登録された１つのＤ４パケットを、UPDATE-CONTROLチャンネルを介してパーソナルコンピュータ１１０に送信する。
【００５４】
図５のステップＳ３００ａにおいて、デバイスユニット４００は、パーソナルコンピュータ１１０から、１つのＲＯＭデータを受信する。そして、受信したＲＯＭデータに含まれる格納データにより、対応するＲＯＭを更新する。本実施例では、図４に示すように、更新データ７００の先頭のＲＯＭデータは、第１のＲＯＭ４３０（図１）に対応する第１のＲＯＭデータ７１０となっている。そのため、ステップＳ３００ａにおいては、第１のＲＯＭ４３０が第１のＲＯＭデータ７１０に含まれる第１の格納データ７１４により更新される。なお、ステップＳ３００ａにおけるＲＯＭデータの受信とＲＯＭの更新との詳細については、後述する。
【００５５】
このステップＳ３００ａが実行されている間、デバイスユニット４００は、パーソナルコンピュータ１１０にファームウェア更新の際に生じるエラーを伝達するため、ステータスをパーソナルコンピュータ１１０に送信する。
【００５６】
図７は、デバイスユニット４００がパーソナルコンピュータ１１０にステータスを送信する様子を示すシーケンス図である。図７に示すシーケンスは、ステップ[SR3]で転送されるコマンドが、図６のステップ[ST3]のデータ転送開始コマンドからステータス確認コマンドに変更されている点と、ステップ[SR6]で転送される応答が、図６のステップ[ST6]のデータ転送開始の応答からステータスの回答に変更されている点で、図６に示すシーケンスと異なっている。他の点は、図６に示すシーケンスと同じである。
【００５７】
ステップ[SR3]において、パーソナルコンピュータ１１０は、ステータスを問い合わせるステータス確認コマンドがボディ部分に登録された１つのＤ４パケットをデバイスユニット４００に送信する。デバイスユニット４００は、ステップ[SR6]において、エラー発生の有無を表すデータ（ステータス回答）がボディ部分に登録された１つのＤ４パケットを、パーソナルコンピュータ１１０に送信する。
【００５８】
図５のステップＳ３００ｂにおいて、デバイスユニット４００は、パーソナルコンピュータ１１０から、１つのＲＯＭデータを受信する。そして、受信したＲＯＭデータに含まれる格納データにより、対応するＲＯＭを更新する。このステップＳ３００ｂでは、ステップＳ３００ａと同様の処理が実行される。そのため、ステップＳ３０ａは、省略することも可能である。
【００５９】
本実施例では、図４に示すように、第１のＲＯＭデータ７１０に続くＲＯＭデータは、第２のＲＯＭ４４０（図１）に対応する第２のＲＯＭデータ７２０となっている。そのため、ステップＳ３００ｂにおいては、第２のＲＯＭデータ７２０に含まれる第２の格納データ７２４により第２のＲＯＭ４４０が更新される。
【００６０】
図５のステップＳ４００において、デバイスユニット４００は、パーソナルコンピュータ１１０（図１）からデータ転送終了コマンドを受信するまで所定の時間待機する。データ転送終了コマンドは、更新データの全体の転送が終了した際にパーソナルコンピュータ１１０からデバイスユニットに送信される。デバイスユニット４００が所定の時間内にデータ転送終了コマンドを受信した場合、ファームウェア更新実行ルーチンは終了する。一方、デバイスユニット４００が所定の時間内にデータ転送終了コマンドを受信しなかった場合、制御はステップＳ３００ｂに戻され、更新データに含まれる未転送のＲＯＭデータの受信とＲＯＭの更新が繰り返される。
【００６１】
本実施例では、図４に示すように、更新データ７００は、第１のＲＯＭデータ７１０と第２のＲＯＭデータ７２０とで構成されている。そのため、ステップＳ３００ｂにおいて更新データ７００の全体が転送されているので、パーソナルコンピュータ１１０は、デバイスユニット４００にデータ転送終了コマンドを送信する。
【００６２】
図８は、デバイスユニット４００がパーソナルコンピュータ１１０からのデータ転送終了コマンドを受信する様子を示すシーケンス図である。図８に示すシーケンスは、ステップ[ED3]で転送されるコマンドが、図６のステップ[ST3]のデータ転送開始コマンドからデータ転送終了コマンドに変更されている点と、ステップ[ED6]で転送される応答が、図６のステップ[ST6]のデータ転送開始の応答からデータ転送終了の応答に変更されている点で、図６に示すシーケンスと異なっている。具体的には、転送されるＤ４パケットのボディ部分に登録される文字列が、データ転送開始コマンドおよびデータ転送開始の応答とは異なっている点で異なっている。他の点は、図６に示すシーケンスと同じである。
【００６３】
図９は、図６のステップＳ３００ａおよびステップＳ３００ｂのそれぞれで実行されるヘッダ受信・解析ルーチンを示すフローチャートである。図１０は、図６のステップＳ３００ａおよびステップＳ３００ｂのそれぞれで実行される格納データ受信・ＲＯＭ更新ルーチンを示すフローチャートである。デバイスユニット４００は、図９に示すヘッダ受信・解析ルーチンと、図１０に示す格納データ受信・ＲＯＭ更新ルーチンとを、この順に順次実行する。図９に示すように、ヘッダ受信・解析ルーチンは、ヘッダ受信フェーズとヘッダ解析フェーズとの２つの工程からなっている。また、図１０に示すように、格納データ受信・ＲＯＭ更新ルーチンは、格納データ受信フェーズとＲＯＭ更新フェーズとの２つの工程からなっている。
【００６４】
図１１は、デバイスユニット４００が図９と図１０に示す各ルーチンを実行する際に、パーソナルコンピュータ１１０とデバイスユニット４００との間でデータが転送される様子を示すシーケンス図である。図１１の細い矢印は、Ｄ４コマンドとＤ４コマンドに対する応答を表している。図１１の太い矢印は、UPDATE-DATAチャンネル（図２）によるデータの転送を表している。
【００６５】
図９のステップＳ３２２において、デバイスユニット４００は、パーソナルコンピュータ１１０からのクレジット要求に対して提供するクレジット数を１に設定する。提供クレジット数を１に設定することにより、デバイスユニット４００は、ステップＳ３２４において１パケット分のデータを受信する。
【００６６】
１パケット分のデータを受信すると、デバイスユニット４００は、ステップＳ３２６において受信済みのデータサイズを更新する。そして、ステップＳ３２８において、更新された受信済みのデータサイズに基づいてヘッダ（図４）分のデータの受信が終了したか否かを判断する。ヘッダ分のデータの受信が終了したと判断した場合、制御はヘッダ解析フェーズのステップＳ３４２に移される。一方、ヘッダ分のデータの受信が終了していないと判断した場合、制御はステップＳ３３０に移される。
【００６７】
ステップＳ３３０では、デバイスユニット４００が所定の待機時間Ｔ１（例えば、５秒）待機する。待機中にクレジット要求コマンドを受信した場合、制御はステップＳ３２４に戻される。そして、ヘッダ分のデータの受信が終了するまで、ステップＳ３２４からステップＳ３３０が繰り返し実行される。一方、所定の待機時間Ｔ１の間に、デバイスユニット４００がクレジット要求コマンドを受信しなかった場合、制御はステップＳ３３２に移される。
【００６８】
ステップＳ３３２において、デバイスユニット４００は、パーソナルコンピュータ１１０とデバイスユニット４００間のＵＳＢを論理的に切断（以下、単に「切断」とも呼ぶ）し、パーソナルコンピュータ１１０にエラーの発生を通知する。そして、ファームウェア更新ルーチンを終了する。このＵＳＢの切断により、パーソナルコンピュータ１１０は、エラーの発生を検知し、パーソナルコンピュータ１１０上で実行されていたファームウェア更新アプリケーションが終了する。
【００６９】
ヘッダ受信フェーズでは、ステップＳ３２２において、提供クレジット数が１に設定される。そのため、パーソナルコンピュータ１１０とデバイスユニット４００との間のデータの転送は、図１１のヘッダ受信フェーズのシーケンスに示すように行われる。
【００７０】
ステップ[HR1]において、パーソナルコンピュータ１１０は、デバイスユニット４００にUPDATE-DATAチャンネルについてのクレジット要求を行う。デバイスユニット４００は、ステップ[HR2]において、ステップ[HR1]でのクレジット要求に対して、１のクレジットを提供する。パーソナルコンピュータ１１０は、ステップ[HR3]において、デバイスユニット４００に提供されたクレジットに従って１パケット分のデータをUPDATE-DATAチャンネルを介して転送する。
【００７１】
そして、デバイスユニット４００によるヘッダ分のデータの受信が終了するまで、これらのステップ[HR1]ないし[HR3]は繰り返し実行され、デバイスユニット４００は、ヘッダ分のデータを受信する。
【００７２】
このように、ヘッダ受信フェーズにおいて、デバイスユニット４００は、１パケットごとにデータを受信する。１パケットごとのデータの受信により、ヘッダ受信フェーズで受信されるデータの大きさは、ヘッダ７１２，７２２（図４）を含む格納データ７１４，７２４（図４）よりも小さくなる。そのため、ヘッダ受信フェーズとヘッダ解析フェーズにおけるＲＡＭ４２０の使用量を低減することができる。
【００７３】
図９のステップＳ３４２において、デバイスユニット４００は、パーソナルコンピュータ１１０からのクレジット要求に対して提供するクレジット数を０に設定する。
【００７４】
ステップＳ３４４において、デバイスユニット４００は、ヘッダ受信フェーズで受信したヘッダを解析する。このヘッダの解析により、デバイスユニット４００は、格納データの大きさ（格納データサイズ）や格納データのチェックサム等の情報を取得する。そして、ステップＳ３４４において、ヘッダが正しいものであるか否かを判断する。ヘッダが正しい場合、制御は格納データ受信・ＲＯＭ更新ルーチンに移される。一方、ヘッダが正しくない場合、制御は、ステップＳ３４８に移される。なお、ヘッダが正しいか否かの判断は、例えば、ヘッダの形式が所定の形式となっているか否かで判断することができる。また、ヘッダそのもののチェックサムをヘッダに格納し、格納されたチェックサムと、受信したヘッダから生成したチェックサムとを比較することによって判断することも可能である。
【００７５】
ステップＳ３４８において、デバイスユニット４００は、ステータスによりエラーの発生をパーソナルコンピュータ１１０に通知し、ファームウェア更新ルーチンを終了する。ステータスによるエラーの発生の通知により、パーソナルコンピュータ１１０は、エラーの発生を検知し、パーソナルコンピュータ１１０上で実行されていたファームウェア更新アプリケーションが終了する。なお、ステータスによるエラーの発生の通知は、エラーの発生を通知するための特定の文字列を表すデータを、図７のシーケンスのステップ[SR6]でパーソナルコンピュータ１１０に送信することによって行うことができる。
【００７６】
ヘッダ解析フェーズでは、ステップＳ３４２において、提供クレジット数が０に設定される。そのため、図１１のヘッダ解析フェーズのシーケンスに示すように、ステップ[HA1]のクレジット要求に対して、ステップ[HA2]において０のクレジットが提供される。このように０のクレジットが提供されることにより、ヘッダ解析フェーズ中は、UPDATE-DATAチャンネルを介したデータの転送が行われない。
【００７７】
このように、ヘッダ解析フェーズにおいて、パーソナルコンピュータ１１０は、デバイスユニット４００にデータを転送しない。そのため、ヘッダの解析中に転送されたデータによりデバイスユニット４００が有するデータバッファが溢れ、ＲＯＭデータの転送が失敗する可能性を低減することができる。
【００７８】
図１０のステップＳ３６２において、デバイスユニット４００は、パーソナルコンピュータ１１０からのクレジット要求に対して提供するクレジット数をＮ（Ｎは１以上の整数）に設定する。ここで、提供するクレジット数Ｎは、以下の式により算出される。
【００７９】
Ｎ＝（格納データサイズ−受信済格納データサイズ）／パケットデータサイズ
【００８０】
提供クレジット数をＮに設定することにより、デバイスユニット４００は、ステップＳ３６４においてＮパケット分のデータを受信する。
【００８１】
Ｎパケット分のデータを受信すると、デバイスユニット４００は、ステップＳ３６６において受信済みのデータサイズを更新する。そして、ステップＳ３６８において、更新された受信済みのデータサイズに基づいて格納データの受信が終了したか否かを判断する。格納データの受信が終了したと判断した場合、制御はＲＯＭ更新フェーズのステップＳ３８２に移される。一方、格納データの受信が終了していないと判断した場合、制御はステップＳ３７０に移される。
【００８２】
ステップＳ３７０では、デバイスユニット４００が所定の待機時間Ｔ２（例えば、２０秒）待機する。待機中にクレジット要求コマンドを受信した場合、制御はステップＳ３６２に戻される。そして、格納データの受信が終了するまで、ステップＳ３６２からステップＳ３７０が繰り返し実行される。一方、所定の待機時間Ｔ２の間に、デバイスユニット４００がクレジット要求コマンドを受信しなかった場合、制御はステップＳ３７２に移される。
【００８３】
ステップＳ３７２において、デバイスユニット４００は、パーソナルコンピュータ１１０とデバイスユニット４００間のＵＳＢを切断し、パーソナルコンピュータ１１０にエラーの発生を通知する。そして、ファームウェア更新ルーチンを終了する。このＵＳＢの切断により、パーソナルコンピュータ１１０は、エラーの発生を検知し、パーソナルコンピュータ１１０上で実行されていたファームウェア更新アプリケーションが終了する。
【００８４】
格納データ受信フェーズでは、ステップＳ３６２において、提供クレジット数がＮに設定される。そのため、パーソナルコンピュータ１１０とデバイスユニット４００との間のデータの転送は、図１１の格納データ受信フェーズのシーケンスに示すように行われる。格納データ受信フェーズのシーケンスは、ステップ[RR2]で提供されるクレジット数が１からＮに変わっている点と、ステップ[RR3]で送信されるデータが１パケット分のデータからＮパケット分のデータに変わっている点と、でヘッダ受信フェーズのシーケンスと異なっている。他の点は、ヘッダ受信フェーズと同様であるので、ここではその説明を省略する。
【００８５】
図１０のステップＳ３８２において、デバイスユニット４００は、パーソナルコンピュータ１１０からのクレジット要求に対して提供するクレジット数を０に設定する。
【００８６】
ステップＳ３８４において、デバイスユニット４００は、格納データ受信フェーズで受信した格納データのチェックサムを算出する。そして、ステップＳ３８６において、算出したチェックサムと、図９のステップＳ３４４において取得されたヘッダに格納されたチェックサム（図４）と、を比較して、格納データが正しいか否かを判断する。格納データが正しい場合、制御はステップＳ３８８に移される。一方、格納データが正しくない場合、制御は、ステップＳ３９０に移される。
【００８７】
ステップＳ３８８において、デバイスユニット４００は、ヘッダに格納されたデバイス番号（図４）に対応するＲＯＭを受信した格納データにより更新する。ＲＯＭの更新は、ＲＯＭを一旦電気的に消去し、その後格納データを書き込むことによって行われる。ステップＳ３８８のＲＯＭの更新の後、格納データ受信・ＲＯＭ更新ルーチンは終了し、図５のステップＳ３００ａもしくはステップＳ３００ｂにおける処理は終了する。
【００８８】
なお、本実施例では、ヘッダにデバイス番号を格納し、デバイス番号に対応するＲＯＭを更新するものとしているが、格納データの受信順序に対応するＲＯＭを更新するものとしても良い。但し、ヘッダのデバイス番号に対応するＲＯＭを更新する方が、更新の必要なＲＯＭが連続していない場合であっても、更新の必要なＲＯＭのＲＯＭデータ（ヘッダ＋格納データ）の送信でファームウェアの更新ができるので、より好ましい。
【００８９】
ステップＳ３９０において、デバイスユニット４００は、ステータスによりエラーの発生をパーソナルコンピュータ１１０に通知し、ファームウェア更新ルーチンを終了する。ステータスによるエラーの発生の通知により、パーソナルコンピュータ１１０は、エラーの発生を検知し、パーソナルコンピュータ１１０上で実行されていたファームウェア更新アプリケーションが終了する。なお、ステータスによるエラーの発生の通知は、図９のステップＳ３４８と同様に行うことができる。
【００９０】
ＲＯＭ更新フェーズにおいても、ステップＳ３８２で提供クレジット数が０に設定される。そのため、図１１のＲＯＭ更新フェーズのシーケンスに示すように、ステップ[RU1]のクレジット要求に対して、ステップ[RU2]において０のクレジットが提供される。このように０のクレジットが提供されることにより、ＲＯＭ更新フェーズ中は、UPDATE-DATAチャンネルを介したデータの転送が行われない。
【００９１】
このように、ＲＯＭ更新フェーズにおいて、パーソナルコンピュータ１１０は、デバイスユニット４００にデータを転送しない。そのため、格納データのチェックサム算出中とＲＯＭの更新中に転送されたデータによりデバイスユニット４００が有するデータバッファが溢れ、ＲＯＭデータの転送が失敗する可能性を低減することができる。
【００９２】
このように第１実施例では、単一の更新データ７００（図４）により、デバイスユニット４００の２つのＲＯＭ４３０，４４０（図１）に格納されたファームウェアを、それぞれの格納データ７１４，７２４（図４）を用いて更新することができる。また、デバイスユニット４００は、２つのＲＯＭ４３０，４４０に対応する格納データ７１４，７２４のそれぞれの格納データ全体を受信するごとに対応するＲＯＭを更新する。そのため、２つのＲＯＭ４３０，４４０を更新するために、２つの格納データ７１４，７２４を全てを取得することが抑制されるので、２つの格納データ７１４，７２４を格納するために必要なＲＡＭ４２０の容量の増大を抑制することができる。
【００９３】
なお、第１実施例では、デバイスユニット４００がヘッダの受信の後パーソナルコンピュータ１１０からのデータの転送を停止しているが、データの転送はヘッダとＲＯＭデータの双方を受信した後のみ停止するものとしても良い。一般に、データ転送の停止は、ＲＯＭの更新に先だって、デバイスユニット４００が１つのＲＯＭの更新に必要な更新データの部分を取得した後に行うものすることが可能である。
【００９４】
Ｄ．第２実施例：
図１２は、第２実施例においてファームウェア更新に用いられる更新データ７００ａの構成を示す説明図である。図１２に示す更新データ７００ａは、第１のＲＯＭデータ７１０ａの前に、ＲＯＭのデバイス数（２）と各格納データのデータサイズを含む全体ヘッダが付加されている点と、ＲＯＭデータ７１０ａ，７２０ａに含まれるヘッダ７１２ａ，７２２ａに各格納データのデータサイズが含まれていない点と、で図４に示す更新データ７００と異なっている。他の点は、図４に示す第１実施例の更新データ７００と同じである。
【００９５】
第２実施例では、更新データ７００ａの構成が第１実施例と異なっているため、図５のステップＳ２００とステップＳ３００ａとの間に全体ヘッダを受信し、各格納データのデータサイズを取得するステップが付加される。また、図９のヘッダ解析フェーズのステップＳ３４４において、ヘッダを解析することによって取得されるデータから格納データのデータサイズが除かれる。その他は、第１実施例と同じ処理が行われる。なお、全体ヘッダの受信と、各格納データのデータサイズの取得は、図９のヘッダ受信・解析ルーチンと同様である。
【００９６】
第１実施例と同様に、第２実施例によっても、単一の更新データ７００ａ（図４）により、デバイスユニット４００の２つのＲＯＭ４３０，４４０（図１）に格納されたファームウェアを、それぞれの格納データ７１４，７２４（図４）を用いて更新することができる。また、デバイスユニット４００は、２つのＲＯＭ４３０，４４０に対応する格納データ７１４，７２４のそれぞれの格納データ全体を受信するごとに対応するＲＯＭを更新する。そのため、２つのＲＯＭ４３０，４４０を更新するために、２つの格納データ７１４，７２４の全てを取得することが抑制されるので、２つの格納データ７１４，７２４を格納するために必要なＲＡＭ４２０の容量の増大を抑制することができる。
【００９７】
Ｅ．変形例：
なお、この発明は上記実施例や実施形態に限られるものではなく、その要旨を逸脱しない範囲において種々の態様において実施することが可能であり、例えば次のような変形も可能である。
【００９８】
Ｅ１．変形例１：
上記各実施例では、Ｄ４プロトコルの論理チャンネルUPDATE-CONTROLを介するデータ転送により、ステータス等の授受を行っているが、これらのデータ転送の少なくとも一部を省略することもできる。この場合、デバイスユニット４００（図１）からのエラーの発生の通知は、例えば、デバイスユニット４００の表示部４８２に表示される。
【００９９】
Ｅ２．変形例２：
上記各実施例では、パーソナルコンピュータ１１０（図１）とデバイスユニット４００（図１）との間のデータの転送にＤ４プロトコルが使用されているが、他の任意のプロトコルによりデータの転送をするものとしても良い。一般的なデータ転送プロトコルでは、受信側から送信側にデータの転送の可否が通知されるので、これによりデバイスユニット４００は、データ転送を停止させることができる。但し、受信するデータ量が個々のＲＯＭの更新に必要な大きさに抑制され、ＲＡＭ４２０の容量をより小さくすることができるので、デバイスユニット４００側でデータの転送量が制御可能なプロトコルでデータの転送を行うのがより好ましい。
【０１００】
Ｅ３．変形例３：
上記各実施例では、デバイスユニット４００は、２つのＲＯＭデータ７１０，７２０（図４）のそれぞれを受信するごとにデータ転送を停止し、受信したＲＯＭデータに対応するＲＯＭ４３０，４４０（図１）を更新しているが、ＲＯＭの更新は、複数のＲＯＭデータの全てを受信した後に、受信した複数のＲＯＭデータによりそれぞれのＲＯＭを更新するものとしても良い。この場合、個々のＲＯＭデータを受信するごとにＲＯＭを更新する個別受信モードと、複数のＲＯＭデータの全てを受信した後にＲＯＭを更新する全体受信モードとは、例えば、利用可能なＲＡＭ４２０の量に応じて選択することができる。
【０１０１】
Ｅ４．変形例４：
上記各実施例では、デバイスユニット４００（図１）に接続されたパーソナルコンピュータ１１０（図１）から更新データを供給しているが、デバイスユニット４００に供給する更新データは、他の方法により供給することも可能である。更新データは、例えば、有線ネットワークや無線ネットワークに接続されたコンピュータから、デバイスユニット４００に接続されたネットワークユニット３００（図１）を介して供給することも可能である。この場合、ネットワークユニット３００は、ネットワークから転送されるメッセージに含まれる更新データを取得し、取得した更新データをデバイスユニット４００に供給できればよい。例えば、ネットワークユニット３００がＨＴＴＰ（Hyper Text Transfer Protocol）サーバとしての機能を有していれば、ネットワークユニット３００がネットワークに接続されたコンピュータによりＰＯＳＴされた更新データをデバイスユニット４００に供給することにより、デバイスユニット４００のファームウェアの更新が可能となる。
【０１０２】
Ｅ５．変形例５：
上記各実施例では、本発明のファームウェアの更新を２つのＲＯＭ４３０，４４０を有するデバイスユニット４００に適用しているが、一般に、ファームウェアが別個に更新可能な複数の領域に格納された任意の装置に適用することができる。例えば、ＲＯＭに設けられた複数のバンクのそれぞれを複数のファームウェア格納領域とし、これらの複数のバンクごとにファームウェアを更新するものとしても良い。なお、個々のファームウェア格納領域に格納される格納データは、ファームウェアのデータであることには変わりがないので、ファームウェアデータとも呼ぶことができる。
【０１０３】
Ｅ６．変形例６：
上記実施例では、本発明のファームウェアの更新をＵＰｎＰブリッジ２００（図１）に適用しているが、本発明は、スキャナ・プリンタ・コピー複合機やルータ等のファームウェアにより種々の機能を実行する任意の装置に適用することができる。この場合、ファームウェアが、別個に更新可能な複数の領域に格納された装置であれば、本発明を適用することができる。
【図面の簡単な説明】
【０１０４】
【図１】本発明の一実施例を適用するコンピュータシステム１００の構成を示す説明図。
【図２】ファームウェア更新に関する機能の階層構造を示すブロック図。
【図３】ファームウェア更新に用いられるＤ４パケットの構成を示す説明図。
【図４】ファームウェア更新に用いられる更新データ７００の構成を示す説明図。
【図５】ファームウェア更新実行ルーチンを示すフローチャート。
【図６】デバイスユニット４００がデータ転送開始コマンドを受信する様子を示すシーケンス図。
【図７】デバイスユニット４００がステータスを送信する様子を示すシーケンス図。
【図８】デバイスユニット４００がデータ転送終了コマンドを受信する様子を示すシーケンス図。
【図９】ヘッダ受信・解析ルーチンを示すフローチャート。
【図１０】格納データ受信・ＲＯＭ更新ルーチンを示すフローチャート。
【図１１】１つのＲＯＭデータを取得しＲＯＭを更新する際にデバイスユニットがＲＯＭデータを受信する様子を示すシーケンス図。
【図１２】第２実施例においてファームウェア更新に用いられる更新データ７００ａの構成を示す説明図。
【符号の説明】
【０１０５】
１００…コンピュータシステム
１１０…パーソナルコンピュータ
１２０…スキャナ・プリンタ・コピー複合機
２００…ＵＰｎＰブリッジ
２１０…電源回路
３００…ネットワークユニット
３１０…中央制御部
３２０…ＲＡＭ
３３０…ＲＯＭ
３４０…ネットワーク制御部
３４２…コネクタ
３５０…ＵＳＢホスト制御部
３５２…ルートハブ
３５４，３５６…ＵＳＢコネクタ
４００…デバイスユニット
４１０…中央制御部
４２０…ＲＡＭ
４３０，４４０…ＲＯＭ
４５０，４６０…ＵＳＢデバイス制御部
４５２，４６２…ＵＳＢコネクタ
４７０…操作パネル制御部
４７２…操作パネル
４８０…表示制御部
４８２…表示部
４９０…ＵＳＢホスト制御部
４９２…ルートハブ
４９４…ＵＳＢコネクタ
５００…電源制御部
１０００…ファームウェア更新アプリケーション
２０００…ファームウェア更新処理部
１１００，２１００…Ｄ４プロトコル処理部
【図１】
2007087133.tif 000003
【図２】
2007087133.tif 000004
【図３】
2007087133.tif 000005
【図４】
2007087133.tif 000006
【図５】
2007087133.tif 000007
【図６】
2007087133.tif 000008
【図７】
2007087133.tif 000009
【図８】
2007087133.tif 000010
【図９】
2007087133.tif 000011
【図１０】
2007087133.tif 000012
【図１１】
2007087133.tif 000013
【図１２】
2007087133.tif 000014