(57)【要約】      （修正有）【課題】ファームウェア開発者の負担が少なく、かつ高速なファームウェア更新方式を提供する。【解決手段】新しいバージョンのファームウェアのイメージ（新ファームイメージ）１２０を受け取り、古いバージョンのファームウェアのイメージ（旧ファームイメージ）１３５と比較し、更新があったファイルだけを取り出し、旧ファームイメージ１３５から新ファームイメージ１２０に更新するための手順および更新データから構成される更新イメージ１４０を作成する機能を備えたサーバ１３０を設置する。【選択図】図１
2010079438.tif 000002
【特許請求の範囲】
【請求項１】
機器のソフトウェアとその構成データを含むファームウェアのイメージを更新するファームウェア更新システムであって、
前記ファームウェアで動作する機器と、前記ファームウェアを更新するための更新イメージを生成し前記機器に送信する更新イメージ生成・配布サーバと、を備え、
前記更新イメージ生成・配布サーバは、前記機器が使用中のバージョンのファームウェアイメージ（第１のファームウェアイメージ）を新しいバージョンのファームウェアイメージ（第２のファームウェアイメージ）に更新するために必要なデータである更新イメージを生成する更新イメージ生成部と、前記更新イメージを前記機器に送信するデータ通信部と、を有し、
前記機器は、前記更新イメージに基づいて、前記古いバージョンのファームウェアイメージを更新する、
ことを特徴とするファームウェア更新システム。
【請求項２】
前記更新イメージ生成・配布サーバは、さらに、最古のバージョンのファームウェアイメージと最新のバージョンのファームウェアイメージとの間における各隣接したバージョンの更新イメージである隣接バージョン更新イメージを格納する更新イメージ格納部を備え、
前記更新イメージ生成部は、前記第１のファームウェアイメージから前記第２のファームウェアイメージに更新するために必要なデータを前記更新イメージ格納部から取得し、前記更新イメージを生成することを特徴とする請求項１に記載のファームウェア更新システム。
【請求項３】
前記第１のファームウェアイメージから前記第２のファームウェアイメージの更新に直接対応する隣接バージョン更新イメージが前記更新イメージ格納部に存在する場合、前記更新イメージ生成部は、当該隣接バージョン更新イメージを前記更新イメージとし、
前記第１のファームウェアイメージから前記第２のファームウェアイメージの更新に直接対応する隣接バージョン更新イメージが前記更新イメージ格納部に無い場合、前記更新イメージ生成部は、前記第１のファームウェアイメージを前記第２のファームイメージに更新するのに必要な全ての隣接バージョン更新イメージを取得してマージすることにより、前記更新イメージを生成することを特徴とする請求項２に記載のファームウェア更新システム。
【請求項４】
前記更新イメージ生成・配布サーバは、さらに、使用頻度の多い前記更新イメージを所定数個格納する更新イメージキャッシュ部を備えることを特徴とする請求項３に記載のファームウェア更新システム。
【請求項５】
前記更新イメージ生成・配布サーバは、さらに、どんなファイルに更新があった場合にどんなサービスの再起動が必要かを示す情報を格納する再起動指示ＤＢを備え、
前記更新イメージ生成部は、前記再起動指示ＤＢを参照して、前記送信すべき更新イメージにサービスの再起動指示を挿入することを特徴とする請求項１に記載のファームウェア更新システム。
【請求項６】
前記再起動指示ＤＢは、前記ファイルが利用するライブラリに対応してサービスの再起動の必要性を示す情報を格納し、
前記更新イメージ生成部は、さらに、前記送信すべき更新イメージに前記ライブラリに対応するサービスの再起動指示をすることを特徴とする請求項５に記載のファームウェア更新システム。
【請求項７】
機器のソフトウェアとその構成データを含むファームウェアのイメージを更新するファームウェア更新システムにおいて動作し、前記ファームウェアを更新するための更新イメージを生成し前記機器に送信する更新イメージ生成・配布サーバ装置であって、
前記機器が使用中のバージョンのファームウェアイメージ（第１のファームウェアイメージ）を新しいバージョンのファームウェアイメージ（第２のファームウェアイメージ）に更新するために必要なデータである更新イメージを生成する更新イメージ生成部と、
前記更新イメージを、前記ファームウェアを使用する機器に送信するデータ通信部と、
を備えることを特徴とする更新イメージ生成・配布サーバ装置。
【請求項８】
最古のバージョンのファームウェアイメージと最新のバージョンのファームウェアイメージとの間における各隣接したバージョンの更新イメージである隣接バージョン更新イメージを格納する更新イメージ格納部を備え、
前記更新イメージ生成部は、前記第１のファームウェアイメージから前記第２のファームウェアイメージに更新するために必要なデータを前記更新イメージ格納部から取得し、前記更新イメージを生成することを特徴とする請求項７に記載の更新イメージ生成・配布サーバ装置。
【請求項９】
前記第１のファームウェアイメージから前記第２のファームウェアイメージの更新に直接対応する隣接バージョン更新イメージが前記更新イメージ格納部に存在する場合、前記更新イメージ生成部は、当該隣接バージョン更新イメージを前記更新イメージとし、
前記第１のファームウェアイメージから前記第２のファームウェアイメージの更新に直接対応する隣接バージョン更新イメージが前記更新イメージ格納部に無い場合、前記更新イメージ生成部は、前記第１のファームウェアイメージを前記第２のファームイメージに更新するのに必要な全ての隣接バージョン更新イメージを取得してマージすることにより、前記更新イメージを生成することを特徴とする請求項８に記載の更新イメージ生成・配布サーバ装置。
【請求項１０】
さらに、使用頻度の多い前記更新イメージを所定数個格納する更新イメージキャッシュ部を備えることを特徴とする請求項９に記載の更新イメージ生成・配布サーバ装置。
【請求項１１】
さらに、どんなファイルに更新があった場合にどんなサービスの再起動が必要かを示す情報を格納する再起動指示ＤＢを備え、
前記更新イメージ生成部は、前記再起動指示ＤＢを参照して、前記送信すべき更新イメージにサービスの再起動指示を挿入することを特徴とする請求項７に記載の更新イメージ生成・配布サーバ装置。
【請求項１２】
前記再起動指示ＤＢは、前記ファイルが利用するライブラリに対応してサービスの再起動の必要性を示す情報を格納し、
前記更新イメージ生成部は、さらに、前記送信すべき更新イメージに前記ライブラリに対応するサービスの再起動指示をすることを特徴とする請求項１１に記載の更新イメージ生成・配布サーバ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ファームウェア更新システム、及び更新イメージ生成・配布サーバ装置に関する。
【背景技術】
【０００２】
組込み機器をリリース後、ソフトウェアに不具合が見つかった場合、従来のファームウェアを、不具合を解決したファームウェアに書き換えることで、問題を解決するという方法が一般に行われている。このようなファームウェア更新に関する文献として、例えば次の特許文献１や特許文献２がある。なお、ここでファームウェアとは、組み込み機器の不揮発性記憶領域にあらかじめ記憶されているデータすべてを指すものとする。
【０００３】
特許文献１には、ファームウェアを全て交換するファームウェア更新方式が記載されている。また、非特許文献１には、Ｌｉｎｕｘでよく使われているソフトウェア更新プログラムであって、パッケージ単位でソフトウェアを管理し、更新のあったソフトウェアパッケージを配布することが開示されている。
【０００４】
【特許文献１】特開平１１−１１０２１８号公報
【非特許文献１】Yum: Yellow dog Updater, Modified：http://linux.duke.edu/projects/yum/
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１のような方式では、ファームウェアを全て交換するため、ファームウェア交換には時間がかかってしまう。また、非特許文献１のような方式では、ファームウェア全ての交換は発生しないものの、ファームウェアの開発者がパッケージ単位でソフトウェアを管理しなければならないという手間が生じてしまう。
【０００６】
本発明はこのような状況に鑑みてなされたものであり、ファームウェアを交換する時間が短く、かつファームウェア開発者の負担が少ない、ファームウェア交換を実現するものである。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、新しいバージョンのファームウェアのイメージ（新ファームイメージ）を受け取り、古いバージョンのファームウェアのイメージ（旧ファームイメージ）と比較し、更新があったファイルだけを取り出し、旧ファームイメージから新ファームイメージに更新するための手順および更新データから構成される更新イメージを作成する機能を備えたサーバを設置する。上記機能で必要になる更新イメージ数を減らすために、頻繁にアクセスされる更新イメージのみをキャッシュする手段を備える。組込み機器には、更新イメージ中の更新手順に従って機器上の旧ファームイメージを新ファームイメージにバージョンアップする機能を設ける。また、旧ファームイメージから新ファームイメージへの更新後にサービスの再起動が必要になることがある。どんなファイルに更新があった場合にどんなサービスの再起動が必要かというＤＢ（再起動ＤＢ）を用意し、更新イメージ中の更新手順に、サービスの再起動指示を挿入可能にする。さらに、再起動ＤＢの作成を自動化する手段も備え、ファームウェア開発者の負担を少なくする。
【０００８】
即ち、本発明によるファームウェア更新システムは、機器のソフトウェアとその構成データを含むファームウェアのイメージを更新するファームウェア更新システムであって、ファームウェアで動作する機器と、ファームウェアを更新するための更新イメージを生成し、機器に送信する更新イメージ生成・配布サーバと、を備える。ここで、更新イメージ生成・配布サーバは、機器が使用中のバージョンのファームウェアイメージ（第１のファームウェアイメージ）を新しいバージョンのファームウェアイメージ（第２のファームウェアイメージ）に更新するために必要なデータである更新イメージを生成する更新イメージ生成部と、更新イメージを前記機器に送信するデータ通信部と、を有し、機器は、更新イメージに基づいて、古いバージョンのファームウェアイメージを更新する。
【０００９】
更新イメージ生成・配布サーバは、さらに、最古のバージョンのファームウェアイメージと最新のバージョンのファームウェアイメージとの間における各隣接したバージョンの更新イメージである隣接バージョン更新イメージを格納する更新イメージ格納部を備え、更新イメージ生成部は、第１のファームウェアイメージから第２のファームウェアイメージに更新するために必要なデータを更新イメージ格納部から取得し、更新イメージを生成する。第１のファームウェアイメージから第２のファームウェアイメージの更新に直接対応する隣接バージョン更新イメージが更新イメージ格納部に存在する場合、更新イメージ生成部は、当該隣接バージョン更新イメージを更新イメージとする。一方、第１のファームウェアイメージから第２のファームウェアイメージの更新に直接対応する隣接バージョン更新イメージが更新イメージ格納部に無い場合、更新イメージ生成部は、第１のファームウェアイメージを第２のファームイメージに更新するのに必要な全ての隣接バージョン更新イメージを取得してマージすることにより、更新イメージを生成する。
【００１０】
更新イメージ生成・配布サーバは、さらに、使用頻度の多い前記更新イメージを所定数個格納する更新イメージキャッシュ部を備える。このとき、更新イメージ生成部は、最新の更新イメージを生成した場合、更新イメージキャッシュ部の最下位の更新イメージと最新の更新イメージとを入れ替える。
【００１１】
更新イメージ生成・配布サーバは、さらに、どんなファイルに更新があった場合にどんなサービスの再起動が必要かを示す情報を格納する再起動指示ＤＢを備え、更新イメージ生成部は、再起動指示ＤＢを参照して、送信すべき更新イメージにサービスの再起動指示を挿入する。さらに、再起動指示ＤＢは、ファイルが利用するライブラリに対応してサービスの再起動の必要性を示す情報を格納し、更新イメージ生成部は、さらに、送信すべき更新イメージにライブラリに対応するサービスの再起動指示をする。
【００１２】
さらなる本発明の特徴は、以下本発明を実施するための最良の形態および添付図面によって明らかになるものである。
【発明の効果】
【００１３】
本発明によれば、ファームウェアを交換する時間を短くし、かつファームウェア開発者の負担が少ない、ファームウェア交換を実現することができるようになる。
【発明を実施するための最良の形態】
【００１４】
以下、添付図面を参照して本発明の実施形態について説明する。ただし、本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。また、各図において共通の構成については同一の参照番号が付されている。
【００１５】
以下、本発明の一実施形態を図面を参照しながら説明する。
＜ファームウェア更新システムの構成＞
図１は、本発明の実施形態によるファームウェア更新システムの概略構成を示す図である。図１に示されるように、開発者１１０は、機器１６０のソフトウェアを開発し、開発したソフトウェアおよび構成ファイルをファームウェアイメージ１２０にまとめる。ファームウェアイメージ１２０は、開発者１１０が開発したソフトウェアと構成ファイルを一つのファイルとしてアーカイブしたものである（詳細な構成については図４参照）。そして、開発者１１０は、機器１６０のソフトウェア更新が必要になった時に、ファームウェアイメージ１２０を、自身のコンピュータ（図示せず）を用いて更新作成・配布サーバ１３０に送信する。
【００１６】
更新作成・配布サーバ１３０は、ネットワーク機能を備えたコンピュータとしてのハードウェアを備える。つまり、更新作成・配布サーバ１３０は、様々な制御処理を実行するＣＰＵ１３１と、ＲＡＭ１３２と、ネットワークインタフェース１３３と、各種データ・パラメータやプログラム等を格納するＨＤＤ１３４と、を備えている。
【００１７】
ＨＤＤ１３４の中には、旧版ファームウェアイメージ１３５が格納されている。そして、更新作成・配布サーバ１３０（ＣＰＵ１３１）は、開発者が開発した新しいファームウェアイメージ１２０と旧版ファームウェアイメージ１３５を比較し、更新された部分だけを取り出し、更新イメージ１４０を作成し、ネットワーク１５０を通じて機器１６０に送信する。更新イメージ１４０の詳細な構成は図２に示す通りであり、後述する。
【００１８】
機器１６０は、ネットワーク機能を備えたコンピュータとしてのハードウェアを備える。この機器１６０の例としては、ネット家電（ＴＶ）やブロードバンドルータ等が挙げられる。機器１６０が最低限備える構成は、ＣＰＵ１６１、ＲＡＭ１６２、ネットワークインタフェース１６３、フラッシュメモリ１６４である。ファームウェア更新の際には、機器１６０が、ソフトウェア更新リクエストを更新作成・配布サーバ１３０に送信し、更新イメージ１６０を受信し、フラッシュメモリ１６４に格納されたファームウェアを更新することになる。このように、プル型の構成にしてもよいし、更新作成・配布サーバ１３０から各機器１６０に対して更新イメージを適時送信するプッシュ型の構成にしてもよい。プッシュ型構成の場合には、予め機器１６０のアドレスが登録されている必要がある。
【００１９】
＜更新作成・配布サーバのＨＤＤ１３４の内部構成＞
図２は、本実施形態における更新作成・配布サーバ１３０のＨＤＤ１３４内部に格納されているデータやプログラムの構成を示す図である。ＨＤＤ１３４は、ファームウェアイメージ集１３５と、更新イメージ集２２０と、再起動指示ＤＢ２３０と、更新イメージキャッシュデータ２４０と、サービス名・ファイル対応データ２５０と、更新作成機能プログラム２６０と、再起動指示作成機能プログラム２７０と、更新配布機能プログラム２８０と、を含んでいる。
【００２０】
ファームウェアイメージ集１３５は旧版のファームウェアイメージであり、開発者１１０が過去に送信したファームウェアイメージのうち、最も古いバージョンのものと、最新のバージョンのものの２種類を保存されている。２１１の例では、バージョン１と最新のバージョン５０のファームウェアイメージが保存されていることが示されている。
【００２１】
更新イメージ集２２０には、最古のファームウェアイメージから、最新のファームウェアイメージに至るまでの更新が一バージョンごとに保存されている。つまり、最新のバージョンが５０ならば、「ファームウェアイメージバージョン１から、ファームウェアイメージバージョン２への更新を表す更新イメージ（更新イメージ１⇒２と表記する）」、「更新イメージ２⇒３」、「更新イメージ３⇒４」、「更新イメージ４⇒５」…＜中略＞…「更新イメージ４９⇒５０」が保存されている。例えば、更新イメージ２⇒５のように１つ飛び以外のケースは、そのイメージが頻繁に使用されるものである等の例外的な場合を除き、基本的に格納されていない。なお、更新イメージの構成は図５に示されるようなものである。
【００２２】
再起動指示ＤＢ２３０は、ＣＰＵ１３１が再起動指示作成機能（プログラム）２７０を実行する際に使うデータを保存している。詳細なデータ構成は図６に示されている。
【００２３】
更新イメージキャッシュデータ２４０は、更新イメージ２２１に対するアクセス頻度および更新イメージのデータ（例えば、アクセス頻度が多いトップ１０のデータ）が記録されている。詳細な構成は図７に示されているようなものである。
【００２４】
サービス名ファイル名対応データ２５０は、サービス名とそれに対応する実行ファイルの組を示す情報である。詳細な構成は図８に示されているようなものである。
【００２５】
更新作成機能プログラム２６０は、更新イメージ１４０を作成するためのプログラムである。機能の詳細については図９を用いて後述する。また、再起動指示作成機能プログラム２７０は、再起動指示ＤＢ２３０を作成するプログラムである。機能の詳細については図１０を用いて後述する。更新配布機能プログラム２８０は、機器１６０からのリクエストに応じて、更新イメージ集２２０に格納された更新イメージを配布するプログラムである。機能の詳細については図１１を用いて後述する。これらのプログラムは、ＣＰＵ１３１によって実行され、各機能が実現される。
【００２６】
＜機器のフラッシュメモリ１６４の内部構成＞
図３は本実施形態における機器１６０のフラッシュメモリ１６４に格納されているデータやプログラム等の構成を示す図である。フラッシュメモリ１６４は、機器１６０で使用中のファームウェアイメージ３１０と、バージョン番号３２０と、オペレーティングシステム３３０と、更新適用プログラム３４０と、を格納している。
【００２７】
ファームウェアイメージ３１０は、機器で動作するソフトウェアおよび構成ファイル一式が格納されたイメージデータである。バージョン番号３２０は、ファームウェアイメージ３１０のバージョンを表している。
【００２８】
オペレーティングシステム３３０は、ファームウェアイメージ３１０に格納されたソフトウェアを実行するための機能を備えている。更新適用プログラム３４０は、更新作成・配布サーバ１３０から、更新イメージ１４０を受信し、更新イメージ１４０に記述された更新をファームウェアイメージ３１０に適用する機能を備え、ＣＰＵ１６１によって実行されるプログラムである。当該機能の処理の詳細は図１２を用いて後述する。
【００２９】
＜ファームウェアイメージの構成＞
図４は、本実施形態によるファームウェアイメージ１２０の構成を示す図である。図４に示されるように、ファームウェアイメージ１２０は、バージョン番号４１０と、ファームウェアのデータ本体４２０で構成される。
【００３０】
バージョン番号４１０は、ファームウェアイメージ１２０のバージョンを表す。バージョン番号は、開発者１１０に管理されている、ファームウェアイメージ１２０のバージョン番号である。ファームウェアのデータ本体４２０は、例えば、ＵＮＩＸ系オペレーティングシステムで広く使われているｔａｒなどを使って、ファイルシステムの構造をアーカイブすることにより生成される。  
【００３１】
＜更新イメージの構成＞
図５は、本実施形態における更新イメージ１４０の構成を示す図である。更新イメージ１４０において、５１０は更新前のイメージのバージョン番号を表す。５２０は更新後のイメージのバージョン番号を表す。例えば、５１０が「４９」、５２０が「５０」の場合は、ファームウェアイメージのバージョン４９から、バージョン５０への更新であることを表す。
【００３２】
５３０〜５６０には、更新手順が記されている。５３０は、更新操作を表す。５４０は、操作対象ファイルのフルパスを表す。５５０は、該当する更新をした場合の再起動指示が記されている。５６０には、フルパス５４０に対応するファイルのデータが記録されている。例えば、行５７１は、「ファイル名／ｕｓｒ／ｓｂｉｎ／ｈｔｔｐｄに対して、５６０に格納されたデータで上書きを行い、ｈｔｔｐサービスの再起動を行う」という更新手順を表している。
【００３３】
つまり、図５は、バージョン番号４９のファームウェアイメージからバージョン番号５０のファームウェアに更新するにはどのような処理手順がなされたかを示しているのである。このような更新イメージが、隣同士のバージョンのファームウェアの全ての組み合せについて更新イメージ集２２０として更新作成・配布サーバ１３０のＨＤＤ１３４に格納されている。
【００３４】
＜再起動指示ＤＢの構成＞
図６は、本実施形態における再起動指示ＤＢ２３０の構成を示す図である。図６に示されるように、再起動指示ＤＢ２３０には、ファイル名６１０と再起動指示６２０の対応が格納されている。つまり、ファイル名６１０に示されるファイルに更新が発生した場合には、再起動指示６２０で示されるサービスの再起動が必要となるのである。
【００３５】
再起動指示ＤＢ２３０のデータは、後述のサービス名ファイル名対応データ２５０（図８）を基にして生成されるものである。
【００３６】
＜更新イメージキャッシュの構成＞
図７は、本実施形態における更新イメージキャッシュデータ２４０の構成を示す図である。更新イメージキャッシュデータは、更新種別７１０と、アクセス数７２０と、更新イメージデータ７３０と、によって構成される。
【００３７】
更新種別７１０は、リクエストされた更新のバージョンを示している。例えば、「４９⇒５０」は、バージョン４９から５０への更新リクエストを表す。アクセス数７２０は、更新種別７１０のリクエストされた頻度を示す。７３０は、更新イメージへのデータである。７３０のフォーマットは図５に示した通りである。更新イメージキャッシュデータは、７２０のアクセス数順に上位のデータ７３０のみが格納される。例えば、上位１０種類のデータ７３０のみが格納されるようにする。
【００３８】
＜サービス名ファイル名対応データ＞
図８は、本実施形態におけるサービス名ファイル名対応データ２５０の構成を示す図である。この対応データは、例えば機器メーカが予め用意する。
【００３９】
サービス名ファイル名対応データは、サービス名８１０とそれを構成する実行ファイル名８２０の組で構成されている。例えば、行８３１は、ｈｔｔｐサービスを構成する実行ファイル名は／ｓｂｉｎ／ｈｔｔｐｄであることを表している。機器のシステム構成によっては、これを自動的に用意することもできる。
【００４０】
多くのＬｉｎｕｘシステムではサービス名ごとに起動スクリプトが用意されている。例えば、／ｅｔｃ／ｉｎｉｔ．ｄ／ｈｔｔｐｄはｈｔｔｐｄサービスの起動スクリプトである。この起動スクリプトを解析し、中に含まれる実行ファイルをサービス名ファイル名対応２５０に登録する。例えば、／ｅｔｃ／ｉｎｉｔ．ｄ／ｈｔｔｐｄを解析し、／ｓｂｉｎ／ｈｔｔｐｄが含まれると分かったら、８１０にｈｔｔｐｄサービス、８２０に／ｓｂｉｎ／ｈｔｔｐｄが登録される。
【００４１】
＜更新作成機能＞
図９は、更新作成機能２６０における処理を説明するためのフローチャートである。図９によって作成されるデータは、図５に示される更新イメージである。なお、ここでは、特に断らない限り、各ステップの動作主体はＣＰＵ１３１である。つまり、ＣＰＵ１３１が、更新作成機能プログラム２６０をＲＡＭ１３２に展開して当該プログラム中の各ステップを実行していく。
【００４２】
開発者１１０から取得したファームウェアイメージ１２０を、ネットワークインタフェース１３３を介して受信する（ステップＳ９１０）と、ＣＰＵ１３１は、取得したばかりのファームウェアイメージ（新バージョン）と、１バージョン古いファームウェアイメージとを比較し、操作の種類、フルパス（ファイルパス）、ファイルのデータを抽出する（ステップＳ９２０）。より具体的には、ファームウェアイメージ集２１０には、ステップ９１０で受信したファームウェアイメージ（新ファームウェアイメージと呼ぶ）より１バージョン古いファームウェアイメージ（旧ファームウェアイメージと呼ぶ）が保存されている。例えば、ステップＳ９１０で、バージョン５０を受信したらならば、旧ファームウェアイメージのバージョンは４９である。そして、ＣＰＵ１３１は、更新イメージ（図５）の旧バージョン番号５１０、新バージョン番号５２０を埋める。例えば、ステップ９１０で受信したファームウェアイメージのバージョンが５０ならば、５１０は「４９」、５２０は「５０」となる。次に、ＣＰＵ１３１は、新ファームウェアイメージと旧ファームウェアイメージのファイルシステム構造を比較し、更新されているファイル、削除されているファイル、追加されているファイルを取り出す。そして、更新イメージの５３０、５４０、５６０を埋める（図５）。例えば、新ファームウェアイメージにて、／ｕｓｒ／ｓｂｉｎ／ｈｔｔｐｄが更新されていた場合は、操作５３０には「更新」、フルパス５４０には「／ｕｓｒ／ｓｂｉｎ／ｈｔｔｐｄ」、ファイルのデータ５６０には、新ファームウェアイメージに含まれる／ｕｓｒ／ｓｂｉｎ／ｈｔｔｐｄのデータが格納される。
【００４３】
続いて、ＣＰＵ１３１は、ファームウェアイメージ集１３５の最新のバージョンのファームウェアイメージを削除し、代わりに、ステップＳ９１０で受信したファームウェアイメージ１２０を最新バージョンとして保存する（ステップＳ９３０）。
【００４４】
また、ＣＰＵ１３１は、再起動ＤＢ２３０を参照し、フルパス５４０に対応する再起動指示６２０を見出し、更新イメージの５５０の列を埋める（ステップＳ９４０）。例えば、フルパス５４０が「／ｕｓｒ／ｓｂｉｎ／ｈｔｔｐｄ」となっていた場合は、ファイル名６１０が一致する行は６３１である。行６３１の再起動指示は「ｈｔｔｐｄサービス」となっているため、再起動指示５５０は、「ｈｔｔｐｄサービス」と記録する。なお、対応する再起動指示６２０が再起動指示ＤＢ２３０から見つからない場合は、５５０には「無し」が格納される。
【００４５】
さらに、ＣＰＵ１３１は、作成された更新イメージを、更新イメージ集２２０に保存する（ステップＳ９５０）。
【００４６】
＜再起動指示作成機能＞
図１０は、再起動指示作成機能２７０における処理を説明するためのフローチャートである。図１０によって作成されるデータは、図６に示されるデータである。ここでも、特に断らない限り、各ステップの動作主体はＣＰＵ１３１である。つまり、ＣＰＵ１３１が、再起動指示作成機能プログラム２７０をＲＡＭ１３２に展開して当該プログラム中の各ステップを実行していく。なお、サービス名ファイル名対応２５０の各行（図８参照）についてステップＳ１０２０からＳ１０４０の処理が実行される。
【００４７】
まず、ＣＰＵ１３１は、図８のサービス名ファイル名対応データ２５０を参照し、該当する行（８３１、８３２・・・等）のファイル名８２０及びサービス名８１０を再起動指示ＤＢ２３０のファイル名６１０及び再起動指示６２０にそれぞれ登録する（ステップＳ１０２０）。
【００４８】
次に、ＣＰＵ１３１は、ファイル名８２０が利用している共有ライブラリを解析する（ステップＳ１０３０）。ファイル名の中身（バイナリ）を見ると、どんなライブラリを使用しているかの依存関係が判明する。つまり、このステップでは、関連するライブラリをサーチしている。例えば、ファイル名が／ｕｓｒ／ｓｂｉｎ／ｈｔｔｐｄの場合、ｈｔｔｐｄのバイナリを解析し、利用している共有ライブラリの名前を取り出す。例えば、ｈｔｔｐｄのバイナリから、共有ライブラリの名前がｌｉｂｈｔｔｐｄ．ｓｏが取り出されたとする。共有ライブラリの検索パスから、ｌｉｂｈｔｔｐｄ．ｓｏのフルパスを取り出す。共有ライブラリの検索パスが／ｌｉｂの場合は、フルパスは／ｌｉｂ／ｌｉｂｈｔｔｐｄ．ｓｏとなる。
【００４９】
続いて、ＣＰＵ１３１は、ステップＳ１０３０で得たライブラリのフルパスを再起動指示ＤＢ２３０のファイル名６１０に登録し、再起動指示６２０については、ステップＳ１０２０で登録したサービス名を登録する（ステップＳ１０４０）。このステップでは、ステップＳ１０３０で使用していると判明したライブラリもファイル名に対応してサービスに関係しているので、再起動の対象とするためにライブラリのファイル名及びサービス名を登録する。ステップＳ１０３０の例で言うと、ファイル名６１０には、「／ｌｉｂ／ｌｉｂｈｔｔｐｄ．ｓｏ」が登録され、再起動指示６２０には「ｈｔｔｐｄサービス」が登録される。
【００５０】
＜更新配布機能＞
図１１は、本実施形態における更新配布機能２８０の処理を説明するためのフローチャートである。ここでも、特に断らない限り、各ステップの動作主体はＣＰＵ１３１である。つまり、ＣＰＵ１３１が、更新配布機能プログラム２８０をＲＡＭ１３２に展開して当該プログラム中の各ステップを実行していく。なお、ファームウェアイメージ集１３５に格納されている最新のファームウェアイメージのバージョンは「５０」として、以下のステップを説明する。
【００５１】
まず、ＣＰＵ１３１は、ネットワークインタフェース１３３を介して、機器１６０よりアップデートリクエストを受け取る（ステップＳ１１１０）。アップデートリクエストの中には、ファームウェアイメージのバージョン番号３２０が含まれている。なお、ここではプル型を例に説明をするが、プッシュ型の更新配布であってもよい。
【００５２】
次に、ＣＰＵ１３１は、更新イメージキャッシュの更新種別７１０を参照し、リクエストされたアップデートが更新イメージキャッシュに含まれるか判別する（ステップＳ１１２０）。図７の例だと、ステップＳ１１１０で受け取ったバージョン番号が「４８」だったならば、機器のファームウェアイメージのバージョンは４８であり、最新のバージョンである５０へのアップデートは７４２にあるように、更新イメージキャッシュに含まれることになる。
【００５３】
ステップＳ１１２０で、リクエストされたアップデートが更新イメージキャッシュに含まれると判断した場合は、ＣＰＵ１３１は、更新イメージキャッシュ中の対応する更新イメージ７３０を機器１６０に配信する（ステップＳ１１３０）。ステップＳ１１１０で受け取ったバージョン番号が「４８」だったならば、行７４２の更新イメージ７３０を配信する。同時に更新イメージキャッシュの対応するアクセス数７２０をインクリメントする。
【００５４】
一方、ステップＳ１１２０で、リクエストされたバージョンの更新イメージが、更新イメージキャッシュに含まれない場合には、処理はステップＳ１１４０に移行する。例えば、図７の例で、ステップ１１１０で受け取ったバージョン番号が「４７」だったならば、更新イメージキャッシュに含まれない。そして、ＣＰＵ１３１は、更新イメージ集２２０に含まれる更新イメージのマージを行い、必要な更新イメージを生成する（ステップＳ１１４０）。
【００５５】
このマージ処理の手順を、ステップ１１１０で受け取ったバージョン番号が「４７」だったとして説明する。更新イメージ集２２０に含まれる「更新イメージ４７⇒４８」、「更新イメージ４８⇒４９」、「更新イメージ４９⇒５０」をマージし、「更新イメージ４７⇒５０」を作成する。具体的には、「更新イメージ４７⇒４８」の５３０、５４０、５５０、５６０の組からなる行に対して、「更新イメージ４８⇒４９」の５３０、５４０、５５０、５６０の組からなる行を追加、同様に「更新イメージ４９⇒５０」の５３０、５４０，５５０、５６０の組からなる行を追加する。そして、新バージョン番号５２０を「５０」に書き換える。
【００５６】
続いて、ＣＰＵ１３１は、更新イメージキャッシュデータを更新する（ステップＳ１１５０）。より詳細には、更新イメージキャッシュデータのうち、アクセス数７２０が最も少ない行を削除し、代わりにステップＳ１１４０で作成した更新イメージを追加する。例えば、更新種別７１０には「４７⇒５０」、アクセス数７２０には「１」、更新イメージデータ７３０には、作成した更新イメージが格納される。
【００５７】
そして、ＣＰＵ１３１は、ステップＳ１１４０で作成した更新イメージを、ネットワークインタフェース１３３を介して機器１６０に配信する。
【００５８】
＜更新適用処理＞
図１２は、機器１６０における更新適用プログラム３４０の処理を説明するためのフローチャートである。ここでは、特に断らない限り、各ステップの動作主体はＣＰＵ１６１である。つまり、ＣＰＵ１６１が、更新適用プログラム３４０をＲＡＭ１６２に展開して当該プログラム中の各ステップを実行していく。
【００５９】
まず、ＣＰＵ１６１は、アップデートリクエストを更新作成・配布サーバ１３０に送信する（ステップＳ１２１０）。アップデートリクエストには、バージョン番号３２０が含まれている。
【００６０】
そして、ＣＰＵ１６１は、更新イメージを更新作成・配布サーバ１３０より受信する（ステップ１２２０）。ここで受信する更新イメージは、更新配布機能２８０を実行することによって作成されたものである。
【００６１】
次に、ＣＰＵ１６１は、受信した更新イメージを使い、ファームウェアイメージ３１０を更新する（ステップＳ１２３０）。例えば、図５のような更新イメージを受信した場合、行５７１〜５７３の操作５３０に従い、ファームウェアイメージを更新する。つまり、／ｕｓｒ／ｓｂｉｎ／ｈｔｔｐｄを５６０のデータで上書きし、／ｌｉｂ／ｌｉｂｆｏｏ．ｓｏ．１を削除し、／ｕｓｒ／ｓｂｉｎ／ｎａｍｅｄを５６０の内容で作成する。また、バージョン番号３２０が、５２０に書かれたバージョン番号に更新される。
【００６２】
続いて、ＣＰＵ１６１は、再起動指示５５０に従い、再起動処理を行う（ステップＳ１２４０）。図５の例では、ｈｔｔｐｄサービスの再起動を行う。
【００６３】
＜まとめ＞
以上により、ファームウェア更新を実現できる。システム全体の処理をまとめると、まず開発者１１０は、最新のファームウェアイメージ１２０を更新作成・配布サーバ１３０に送信する。機器１６０は、更新適用プログラム３４０を使い、ファームウェア更新リクエストを更新作成・配布サーバ１３０に対して送信する。更新作成・配布サーバ１３０は、更新作成機能２６０を使い、更新イメージ１４０を作成し、更新イメージ１４０を機器１６０に送信する。機器１６０は、更新イメージ１４０を受け取り、更新適用プログラム３４０を使って、ファームウェアを最新のものに更新する。
【００６４】
以上説明した本発明の実施形態を適用することにより、ファームウェアを更新する際、更新イメージ１４０に含まれるファイルのみが更新されるため、ファームウェア全てを交換するよりも、ファームウェアを更新するための時間は短くて済む。さらに、ファームウェア開発者１１０が、ファームウェアイメージ１２０を更新作成・配布サーバ１３０に送付するだけで、更新イメージ１４０が自動的に作成されるため、ファームウェア開発者１１０の負担は少ない。
【００６５】
副次的な効果として、更新イメージを格納するための領域も少なくなっている。例えば、ファームウェアの最新版のバージョンが５０ならば、更新１⇒５０、更新２⇒５０、更新３⇒５０、更新４⇒５０……更新４９⇒５０の４９種類の更新イメージが必要になるだけで、全ての組合せを格納しておく必要はない。更新１⇒５０は、４９バージョン分の差分、更新２⇒５０は４８バージョン分の差分であるため、サイズが大きい。これらを保管する代わりに、２２１のように、１バージョンずつの差分を４９個保管するようにしているため、更新イメージを格納する領域は少なくて済むようになる。
【００６６】
なお、本発明は、実施形態の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。
【００６７】
また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。
【００６８】
また、実施の形態の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ-ＲＷ、ＣＤ-Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ(又はＣＰＵやＭＰＵ)が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。
【図面の簡単な説明】
【００６９】
【図１】本発明の実施形態によるファームウェア更新システムの全体概略構成を示す図である。
【図２】更新作成・配布サーバのＨＤＤの内部データ構成を示す図である。
【図３】機器のメモリの内部データ構成を示す図である。
【図４】ファームウェアイメージの構成例を示す図である。
【図５】更新イメージの構成例を示す図である。
【図６】再起動指示ＤＢの構成例を示す図である。
【図７】更新イメージキャッシュの構成例を示す図である。
【図８】サービスファイル名対応の構成例を示す図である。
【図９】更新作成機能の処理動作を説明するためのフローチャートである。
【図１０】再起動指示作成機能の処理動作を説明するためのフローチャートである。
【図１１】更新配布機能の処理動作を説明するためのフローチャートである。
【図１２】更新適用プログラムの処理動作を説明するためのフローチャートである。
【符号の説明】
【００７０】
１１０・・・開発者
１２０・・・ファームウェアイメージ
１３０・・・更新作成・配布サーバ
１４０・・・更新イメージ
１５０・・・ネットワーク
１６０・・・機器
１３１・・・ＣＰＵ
１３２・・・ＲＡＭ
１３３・・・ネットワークインタフェース
１３４・・・ＨＤＤ
１３５・・・旧版ファームウェアイメージ
１６１・・・ＣＰＵ
１６２・・・ＲＡＭ
１６３・・・ネットワークインタフェース
１６４・・・フラッシュメモリ
【図１】
2010079438.tif 000003
【図２】
2010079438.tif 000004
【図３】
2010079438.tif 000005
【図４】
2010079438.tif 000006
【図５】
2010079438.tif 000007
【図６】
2010079438.tif 000008
【図７】
2010079438.tif 000009
【図８】
2010079438.tif 000010
【図９】
2010079438.tif 000011
【図１０】
2010079438.tif 000012
【図１１】
2010079438.tif 000013
【図１２】
2010079438.tif 000014