JP2017228246A - 情報処理装置、情報処理システム、プログラム、及び情報処理方法 - Google Patents

Abstract

【課題】ファームウェアの更新が失敗した場合に、復旧すること。【解決手段】情報処理装置において、ファームウェアの更新に失敗した際の復旧に用いるバックアップデータを管理サーバに保存する保存部と、ファームウェアを更新する更新部と、前記更新部によるファームウェアの更新に失敗した場合、前記管理サーバに保存されたバックアップデータを用いて復旧を行う復旧部と、を備える。【選択図】図４

Description

本発明は、情報処理装置、情報処理システム、プログラム、及び情報処理方法に関する。

従来、情報処理装置において、ファームウェアの更新情報があると、データセンター等の外部サーバからファームウェアをダウンロードし、自身のファームウェアを更新する（書き換える、アップデートする）技術が知られている。

この技術において、ファームウェアの更新が失敗した場合、情報処理装置が正常に起動しないため復旧（リカバリー）作業が必要になる。

そこで、ファームウェアの更新処理を実施する前に、現在のファームウェアや設定データ等のバックアップを行い、ファームウェアの更新が失敗した場合に、自動で復旧する技術が知られている（例えば、特許文献１参照）。

しかしながら、例えば組み込み型の情報処理装置等においては、現在のファームウェアや設定データ等をバックアップするための記憶容量等が十分でないため、現在のファームウェアや設定データ等をバックアップできない。そのため、上述した従来技術では、ファームウェアの更新が失敗した場合に、復旧できないという問題がある。

そこで、ファームウェアの更新が失敗した場合に、復旧できる技術を提供することを目的とする。

情報処理装置において、ファームウェアの更新に失敗した際の復旧に用いるバックアップデータを管理サーバに保存する保存部と、ファームウェアを更新する更新部と、前記更新部によるファームウェアの更新に失敗した場合、前記管理サーバに保存されたバックアップデータを用いて復旧を行う復旧部と、を備える。

開示の技術によれば、ファームウェアの更新が失敗した場合に、復旧することが可能となる。

実施形態における情報処理システムの構成例を示す図である。 実施形態に係る情報処理装置のハードウェア構成の一例を示す図である。 第１の実施形態に係る情報処理システムの機能ブロック図である。 第１の実施形態に係る情報処理システムの処理の一例を示すシーケンス図である。 第１の実施形態に係る情報処理装置のファームウェア更新処理の一例を示すフローチャートである。 リカバリーモジュールの構成の一例を示す図である。 更新履歴設定処理の一例を示すフローチャートである。 更新履歴データの一例を示す図である。 リカバリーモジュール作成処理の一例を示すフローチャートである。 第２の実施形態に係る情報処理システムの機能ブロック図である。 第２の実施形態に係る情報処理システム１の処理の一例を示すシーケンス図である。 第２の実施形態に係る情報処理装置１０のファームウェア更新処理の一例を示すフローチャートである。 第２の実施形態に係る管理サーバ２０のリカバリーモジュール作成処理の一例を示すフローチャートである。

以下、図面に基づいて本発明の実施形態を説明する。図１は、実施形態における情報処理システム１の構成例を示す図である。図１において、情報処理システム「１は、情報処理装置１０、管理サーバ２０、及びファイルサーバ３０を有する。情報処理装置１０、及び管理サーバ２０は、インターネットやＬＡＮ（Local Area Network）等の通信網によって通信可能に接続される。

情報処理装置１０は、例えば組み込み型の情報処理装置、パーソナルコンピュータ、プロジェクタ、テレビ会議システム、デジタルカメラ等の情報処理装置である。

＜ハードウェア構成＞
図２は、実施形態に係る情報処理装置１０のハードウェア構成の一例を示す図である。

情報処理装置１０は、それぞれバスＢで相互に接続されているドライブ装置１０１、ＨＤＤ（Hard disk drive）１０２、メモリ装置１０３、ＣＰＵ（Central Processing Unit；演算処理装置）１０４、通信インターフェース（Ｉ／Ｆ）１０５、操作Ｉ／Ｆ１０６を有する。

ＨＤＤ１０２は、インストールされたプログラムを格納すると共に、必要なファイル、データ等を格納する。メモリ装置１０３は、コンピュータの起動時にＨＤＤ１０２からプログラムを読み出して格納する。そして、ＣＰＵ１０４はメモリ装置１０３に格納されたプログラムに従って、後述するような各種処理を実現する。

通信Ｉ／Ｆ１０５は、ＵＳＢポート、無線ＬＡＮ（Local Area Network）カード、ＬＡＮカードなどで構成されており、ネットワークに接続するために用いられる。

操作Ｉ／Ｆ１０６は、キーボードやディスプレイ等で実現され、情報処理装置１０を操作するための操作画面が表示される。

後述する実施形態の情報処理方法がプログラムによって実現される場合、プログラムは例えば記録媒体１１０の配布やネットワークからのダウンロードなどによって提供される。記録媒体１１０は、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、フレキシブルディスク、光磁気ディスク等の様に情報を光学的、電気的或いは磁気的に記録する記録媒体、ＲＯＭ（Read Only Memory）、フラッシュメモリ等の様に情報を電気的に記録する半導体メモリ等、様々なタイプの記録媒体を用いることができる。

また、実施形態のプログラムを記録した記録媒体１１０がドライブ装置１０１にセットされると、記録媒体１１０からドライブ装置１０１を介してＨＤＤ１０２にインストールされる。プログラムをネットワークからダウンロードした場合は、通信Ｉ／Ｆ１０５を介してＨＤＤ１０２にインストールされる。

管理サーバ２０、及びファイルサーバ３０のハードウェア構成は、図２に示す情報処理装置１０のハードウェア構成例と同様でもよい。

（第１の実施形態）
＜機能構成＞
次に、図３を参照し、第１の実施形態に係る情報処理システム１の機能構成について説明する。図３は、第１の実施形態に係る情報処理システムの機能ブロック図である。

情報処理装置１０は、アプリケーション実行部１１、保存部１２、ファームウェア更新部１３、リカバリーモジュール作成部１４、及び復旧部１５を備える。これら各部は、情報処理装置１０にインストールされた１以上のプログラムが、情報処理装置１０のＣＰＵ１０５に実行させる処理により実現される。

アプリケーション実行部１１は、
保存部１２は、ファームウェアの更新に失敗した際の復旧に用いるバックアップデータを管理サーバ２０に保存する。

ファームウェア更新部１３は、情報処理装置１０のファームウェアを更新する。

リカバリーモジュール作成部１４は、ファームウェアの更新に失敗した場合、管理サーバ２０に保存されたバックアップデータを用いて、リカバリーデータを作成する。

復旧部１５は、ファームウェアの更新に失敗した場合、リカバリーモジュール作成部１４により作成されたリカバリーデータを用いて復旧を行う。

管理サーバ２０は、データ管理部２１を備える。データ管理部２１は、管理サーバ２０にインストールされた１以上のプログラムが、管理サーバ２０のＣＰＵ１０５に実行させる処理により実現される。

データ管理部２１は、情報処理装置１０から、ファームウェアのバージョンを示すデータや設定データ等のバックアップデータを受信し、記憶する。なお、バックアップデータに、ファームウェア自体のデータが含まれていてもよい。

データ管理部２１は、情報処理装置１０に、ファームウェアの更新や復旧を行わせる。

＜処理＞
次に、図４を参照し、情報処理システム１の処理について説明する。図４は、第１の実施形態に係る情報処理システム１の処理の一例を示すシーケンス図である。

まず、情報処理装置１０の保存部１２は、例えば定期的に、またはファームウェアの更新を行う前に、現在のファームウェアのバージョンを示すデータや設定データ等のバックアップデータを作成し、管理サーバ２０に送信する（ステップＳ１）。

続いて、管理サーバ２０のデータ管理部２１は、情報処理装置１０から受信したバックアップデータを記憶する（ステップＳ２）。

管理サーバ２０は、ファイルサーバ３０において、当該ファームウェアに対する新しいバージョンが登録されたことを検知した場合、情報処理装置１０にその旨を通知する（ステップＳ３）。

続いて、情報処理装置１０は、管理サーバ２０から、更新するファームウェアの情報（取得先ＵＲＬ等の情報）を取得する（ステップＳ４）。

続いて、情報処理装置１０は、ファイルサーバ３０から、更新されたファームウェアを取得する（ステップＳ５）。

続いて、情報処理装置１０のファームウェア更新部１３は、ファームウェアの更新処理を開始する（ステップＳ６）。

続いて、情報処理装置１０のリカバリーモジュール作成部１４は、ファームウェアの更新に失敗したことを検知した場合、管理サーバ２０から、復旧用モジュールの情報（取得先ＵＲＬ等の情報）を取得する（ステップＳ７）。なお、復旧用モジュールの情報は、データ管理部２１が、情報処理装置１０から受信したバックアップデータに含まれるファームウェアのバージョンを示すデータに応じて決定してもよい。

続いて、情報処理装置１０のリカバリーモジュール作成部１４は、ファイルサーバ３０から、復旧用モジュールを取得する（ステップＳ８）。

続いて、情報処理装置１０のリカバリーモジュール作成部１４は、管理サーバ２０から、バックアップデータを取得する（ステップＳ９）。

続いて、情報処理装置１０の復旧部１５は、復旧用モジュールとバックアップデータに基づいてリカバリーを行う（ステップＳ１０）。

次に、図５を参照し、ファームウェアを更新する際の情報処理装置１０の処理について説明する。図５は、第１の実施形態に係る情報処理装置１０のファームウェア更新処理の一例を示すフローチャートである。

ファームウェア更新部１３は、管理サーバ２０からファームウェアの更新情報を受信する（ステップＳ１０１）。

続いて、ファームウェア更新部１３は、アプリケーション実行部１１に、実行中のプロセスを終了させる（ステップＳ１０２）。

続いて、ファームウェア更新部１３は、管理サーバ２０から、更新するファームウェアの取得先情報（取得先ＵＲＬ等の情報）を取得する（ステップＳ１０３）。

続いて、ファームウェア更新部１３は、ファームウェアの取得先情報に応じて、ファイルサーバ３０から更新ファームウェアを取得する（ステップＳ１０４）。

続いて、ファームウェア更新部１３は、アプリケーション実行部１１に、取得したファームウェアを適用する（ステップＳ１０５）。

続いて、復旧部１５は、ファームウェアの更新が成功したか否かを判定する（ステップＳ１０６）。

ファームウェアの更新が成功した場合（ステップＳ１０６でＹＥＳ）、後述するステップＳ１１２の処理に進む。

ファームウェアの更新が成功しなかった場合（ステップＳ１０６でＮＯ）、リカバリーモジュール作成部１４は、管理サーバ２０から、バックアップデータを取得する（ステップＳ１０７）。

続いて、リカバリーモジュール作成部１４は、管理サーバ２０から復旧用モジュールの取得先情報を取得する（ステップＳ１０８）。

続いて、リカバリーモジュール作成部１４は、復旧用モジュールの取得先情報に応じて、ファイルサーバ３０から、復旧用モジュールを取得する（ステップＳ１０９）。

続いて、リカバリーモジュール作成部１４は、復旧用モジュール及びバックアップデータに基づいてリカバリーモジュールを作成する（ステップＳ１１０）。図６は、リカバリーモジュールの構成の一例を示す図である。リカバリーモジュールの構成は、情報処理装置１０が動作するためのモジュール構成と同様でもよい。例えば、情報処理装置１０が動作するためのモジュール構成が図６に示す構成である場合、リカバリーモジュールの構成も図６に示す構成としてもよい。

続いて、復旧部１５は、更新に失敗したファームウェア及び関連データを削除する（ステップＳ１１１）。

続いて、復旧部１５は、アプリケーション実行部１１に、リカバリーモジュールに基づいて復旧したファームウェア及び設定データ等を適用する（ステップＳ１１２）。

続いて、復旧部１５は、アプリケーション実行部１１に、ステップＳ１０２で終了させたプロセスを起動させ（ステップＳ１１３）、処理を終了する。

≪更新履歴設定処理≫
次に、図７、図８を参照し、ステップＳ１０６の、ファームウェアの更新が成功したか否かを判定する際に実行する、更新履歴設定処理について説明する。図７は、更新履歴設定処理の一例を示すフローチャートである。

リカバリーモジュール作成部１４は、更新履歴データ１４１において、「after_update」フラグを「true」に設定する（ステップＳ２０１）。

続いて、リカバリーモジュール作成部１４は、「update_firmware_success」フラグを設定する（ステップＳ２０２）。リカバリーモジュール作成部１４は、「update_firmware_success」フラグを、ファームウェアのインストールが正常に完了した場合は「true」に設定し、正常に完了しない（失敗した）場合は「false」に設定する。

続いて、リカバリーモジュール作成部１４は、「update_settings_success」フラグを設定する（ステップＳ２０３）。リカバリーモジュール作成部１４は、「update_settings_success」フラグを、設定ファイルの設定（更新）が正常に完了した場合は「true」に設定し、正常に完了しない場合は「false」に設定する。

続いて、リカバリーモジュール作成部１４は、「update_database_success」フラグを設定する（ステップＳ２０４）。リカバリーモジュール作成部１４は、「update_database_success」フラグを、アプリケーションが使用するデータベースの設定（更新）が正常に完了した場合は「true」に設定し、正常に完了しない場合は「false」に設定する。

続いて、リカバリーモジュール作成部１４は、「start_up_complete_success」フラグを設定する（ステップＳ２０５）。リカバリーモジュール作成部１４は、「start_up_complete_success」フラグを、ファームウェア更新後、正常に起動した場合は「true」に設定し、正常に起動しない場合は「false」に設定する。

図８は、更新履歴データ１４１の一例を示す図である。図８において、「after_update」は、ファームウェア更新後であるか否かを示すフラグである。「update_firmware_success」は、ファームウェアの更新が正常に完了したか否かを示すフラグである。「update_settings_success」は、設定ファイルの更新が正常に完了したか否かを示すフラグである。「update_database_success」は、データベースの更新が正常に完了したか否かを示すフラグである。「start_up_complete_success」は、ファームウェア更新後、正常に起動したか否かを示すフラグである。

≪リカバリーモジュール作成処理≫
次に、図９を参照し、ステップＳ１０９、ステップＳ１１０の、復旧用モジュールを取得してリカバリーモジュールを作成する処理について説明する。図９は、リカバリーモジュール作成処理の一例を示すフローチャートである。

リカバリーモジュール作成部１４は、更新履歴データ１４１において、「after_update」フラグを判定する（ステップＳ３０１）。

「after_update」フラグが「false」であれば（ステップＳ３０１で「false」）、処理を終了する。

「after_update」フラグが「true」であれば（ステップＳ３０１で「true」）、リカバリーモジュール作成部１４は、「after_update」フラグを「false」に設定し（ステップＳ３０２）、「update_firmware_success」フラグを判定する（ステップＳ３０３）。

「update_firmware_success」フラグが「false」であれば（ステップＳ３０３で「false」）、リカバリーモジュール作成部１４は、ファイルサーバ３０から、更新前のファームウェアを復旧するための復旧用モジュールを取得する（ステップＳ３０４）。

続いて、リカバリーモジュール作成部１４は、取得した復旧用モジュール及びバックアップデータに基づいてリカバリーモジュールを作成し（ステップＳ３０５）、処理を終了する。

これにより、例えば情報処理装置１０にて更新に使用したファームウェアが適切ではない場合に、実行前の状態に戻すことができる。なお、更新前のファームウェアを復旧するための復旧用モジュールを識別する情報は、情報処理装置１０にて記憶しておいてもよいし、管理サーバ２０から取得したバックアップデータから取得してもよい。

「update_firmware_success」フラグが「true」であれば（ステップＳ３０３で「true」）、リカバリーモジュール作成部１４は、「update_settings_success」フラグを判定する（ステップＳ３０６）。

「update_settings_success」フラグが「false」であれば（ステップＳ３０６で「false」）、リカバリーモジュール作成部１４は、ファイルサーバ３０から、最新のファームウェアを復旧用モジュールとして取得する（ステップＳ３０７）。

続いて、リカバリーモジュール作成部１４は、最新のファームウェア及びバックアップデータに基づいてリカバリーモジュールを作成し（ステップＳ３０８）、処理を終了する。これにより、ファームウェアの更新は成功しており、設定データを正しく更新できれば正常動作できる場合に、最新のファームウェアと、管理サーバ２０から取得したバックアップデータに含まれる設定データを用いて、ファームウェア更新が正常に完了したときの状態とすることができる。

「update_settings_success」フラグが「true」であれば（ステップＳ３０６で「true」）、リカバリーモジュール作成部１４は、「update_database_success」フラグを判定する（ステップＳ３０９）。

「update_database_success」フラグが「false」であれば（ステップＳ３０９で「false」）、ステップＳ３０７の処理に進む。これにより、ファームウェアの更新は成功しており、データベースを正しく更新できれば正常動作できる場合に、最新のファームウェアと、管理サーバ２０から取得したバックアップデータに含まれるデータベースを用いて、ファームウェア更新が正常に完了したときの状態とすることができる。

「update_database_success」フラグが「true」であれば（ステップＳ３０９で「true」）、リカバリーモジュール作成部１４は、「start_up_complete_success」フラグを判定する（ステップＳ３１０）。

「start_up_complete_success」フラグが「false」であれば（ステップＳ３１０で「false」）、ステップＳ３０４の処理に進む。これにより、ファームウェア、設定ファイル、データベース全てが正常に更新できているにも関わらず起動できないのは異常状態であるため、正常に動作していた実行前の状態に戻すことができる。

「start_up_complete_success」フラグが「true」であれば（ステップＳ３１０で「true」）、処理を終了する。

（第２の実施形態）
第１の実施形態は、情報処理装置１０がリカバリーモジュール作成部１４を備える場合の例について説明した。第２の実施形態では、管理サーバ２０がリカバリーモジュール作成部２２を備える場合の例について説明する。なお、第２の実施形態は一部を除いて第１の実施形態と同様であるため、適宜説明を省略する。

＜機能構成＞
次に、図１０を参照し、第２の実施形態に係る情報処理システム１の機能構成について説明する。図１０は、第２の実施形態に係る情報処理システム１の機能ブロック図である。第１の実施形態と比較して、情報処理装置１０がリカバリーモジュール作成部１４を備えず、管理サーバ２０がリカバリーモジュール作成部２２を備える点が異なる。

＜処理＞
以下では第２の実施形態に係る情報処理システム１の処理の詳細について第１の実施形態との差異を説明する。

図１１は、第２の実施形態に係る情報処理システム１の処理の一例を示すシーケンス図である。

ステップＳ１乃至ステップＳ６の処理は、図４に示す第１の実施形態に係る処理と同様である。

情報処理装置１０は、ファームウェアの更新に失敗したことを検知した場合、管理サーバ２０に、ファームウェアの更新に失敗したこと、及び失敗の理由（図８の更新履歴データ）を通知する（ステップＳ７−２）。

続いて、管理サーバ２０のリカバリーモジュール作成部２２は、ファイルサーバ３０から、失敗の理由に応じた復旧用モジュールを取得する（ステップＳ８−２）。

続いて、管理サーバ２０のリカバリーモジュール作成部２２は、復旧用モジュールとバックアップデータに基づいてリカバリーモジュールを作成し、情報処理装置１０に送信する（ステップＳ９−２）。なお、リカバリーモジュール作成部２２は、図９に示すリカバリーモジュール作成処理と同様の処理により、リカバリーモジュールを作成する。

続いて、情報処理装置１０の復旧部１５は、管理サーバ２０から取得したリカバリーモジュールに基づいてリカバリーを行う（ステップＳ１０−２）。

次に、図１２を参照し、ファームウェアを更新する際の情報処理装置１０の処理について説明する。図１２は、第２の実施形態に係る情報処理装置１０のファームウェア更新処理の一例を示すフローチャートである。

ステップＳ１０１乃至ステップＳ１０６の処理は、図５に示す第１の実施形態に係る処理と同様である。

ファームウェアの更新が成功しなかった場合（ステップＳ１０６でＮＯ）、ファームウェア更新部１３は、管理サーバ２０に、ファームウェアの更新に失敗したこと、及び失敗の理由（図８の更新履歴データ）を通知する（ステップＳ１０７−２）。

続いて、復旧部１５は、管理サーバ２０から、リカバリーモジュールを取得する（ステップＳ１０８−２）。

続いて、復旧部１５は、更新に失敗したファームウェア及び関連データを削除する（ステップＳ１１１）。

続いて、復旧部１５は、アプリケーション実行部１１に、リカバリーモジュールに基づいて復旧したファームウェア及び設定データ等を適用する（ステップＳ１１２）。

続いて、復旧部１５は、アプリケーション実行部１１に、ステップＳ１０２で終了させたプロセスを起動させ（ステップＳ１１３）、処理を終了する。

次に、図１３を参照し、第２の実施形態に係る管理サーバ２０のリカバリーモジュールを作成する際の処理について説明する。図１３は、第２の実施形態に係る管理サーバ２０のリカバリーモジュール作成処理の一例を示すフローチャートである。

リカバリーモジュール作成部２２は、データ管理部２１から、情報処理装置１０のバックアップデータを取得する（ステップＳ３０１）。

続いて、リカバリーモジュール作成部２２は、データ管理部２１から復旧用モジュールの取得先情報を取得する（ステップＳ３０２）。

続いて、リカバリーモジュール作成部２２は、復旧用モジュールの取得先情報に応じて、ファイルサーバ３０から、復旧用モジュールを取得する（ステップＳ３０３）。

続いて、リカバリーモジュール作成部２２は、復旧用モジュール及びバックアップデータに基づいてリカバリーモジュールを作成する（ステップＳ３０４）。

＜まとめ＞
例えば組み込み型の情報処理装置等においては、ファームウェアや設定データ等をバックアップするための記憶容量等が十分でないため、現在のファームウェアや設定データ等をバックアップできない場合がある。また、情報処理装置が、ユーザにより簡単に外部からアクセスして状態を確認したりファイル操作を行うことができないように構成されている場合、保守員が現場に行く必要があったり、情報処理装置を回収したりしてリカバリー作業を実施した後ファームウェア更新を行う必要がある。

上述した実施形態によれば、情報処理装置は、ファームウェアの更新に失敗した際の復旧に用いるバックアップデータを管理サーバに保存する。そして、情報処理装置は、ファームウェアの更新に失敗した場合、当該管理サーバに保存されたバックアップデータを用いて復旧を行う。これにより、ファームウェアの更新が失敗した場合に、復旧することができる。

なお、上述した実施形態におけるシステム構成は一例であり、用途や目的に応じて様々なシステム構成例があることは言うまでもない。例えば、管理サーバ２０とファイルサーバ３０は一体の装置として構成してもよい。

１ 情報処理システム
１０ 情報処理装置
１１ アプリケーション実行部
１２ 保存部
１３ ファームウェア更新部（「更新部」の一例）
１４ リカバリーモジュール作成部
１５ 復旧部
２０ 管理サーバ
２１ データ管理部
２２ リカバリーモジュール作成部
３０ ファイルサーバ

特開２０１５−２２５４７８号公報

Claims (8)

1. ファームウェアの更新に失敗した際の復旧に用いるバックアップデータを管理サーバに保存する保存部と、
   ファームウェアを更新する更新部と、
   前記更新部によるファームウェアの更新に失敗した場合、前記管理サーバに保存されたバックアップデータを用いて復旧を行う復旧部と、
   を備えることを特徴とする情報処理装置。
2. 前記復旧部は、前記管理サーバに保存されたバックアップデータ、及び通信網を介して取得したファームウェアを用いて復旧を行う、
   ことを特徴とする請求項１記載の情報処理装置。
3. 前記管理サーバに保存されたバックアップデータは、ファームウェアの設定データ、またはアプリケーションが使用するデータを含み、
   前記復旧部は、ファームウェアの設定に失敗した場合、またはアプリケーションが使用するデータの設定に失敗した場合、前記更新した後のファームウェアを用いて復旧を行う、
   ことを特徴とする請求項１または２記載の情報処理装置。
4. 前記復旧部は、ファームウェアのインストールに失敗した場合、またはファームウェア更新後に前記情報処理装置が正常に起動しない場合、前記更新する前のファームウェアを用いて復旧を行う、
   ことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. 前記復旧部は、前記管理サーバから取得した、前記バックアップデータ、及びファームウェアを含むリカバリーモジュールを用いて復旧を行う、
   ことを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
6. 情報処理装置、及び管理サーバを有する情報処理システムであって、
   前記情報処理装置は、
   ファームウェアの更新に失敗した際の復旧に用いるバックアップデータを管理サーバに保存する保存部と、
   ファームウェアを更新する更新部と、
   前記更新部によるファームウェアの更新に失敗した場合、前記管理サーバに保存されたバックアップデータを用いて復旧を行う復旧部と、
   を備え、
   前記管理サーバは、
   前記情報処理装置から受信した前記バックアップデータを管理する管理部と備えることを特徴とする情報処理システム。
7. コンピュータに、
   ファームウェアの更新に失敗した際の復旧に用いるバックアップデータを管理サーバに保存するステップと、
   ファームウェアを更新するステップと、
   前記更新に失敗した場合、前記管理サーバに保存されたバックアップデータを用いて復旧を行うステップと、
   を実行させるプログラム。
8. コンピュータが、
   ファームウェアの更新に失敗した際の復旧に用いるバックアップデータを管理サーバに保存するステップと、
   ファームウェアを更新するステップと、
   前記更新に失敗した場合、前記管理サーバに保存されたバックアップデータを用いて復旧を行うステップと、
   を実行する情報処理方法。

Images