プラグインバージョン管理システム
【課題】オプションハードウェアの安定動作を自動で保障することにより、正常に動作しないソフトウェア状態を避けることができ、プラグインカスタマイズをどれだけ実施してもすぐにユーザのシステム環境を元に戻すことのできるプラグインバージョン管理システムを提供する。
【解決手段】コンピュータ組み込み機器におけるソフトウェアのバックアップおよびリカバリを管理するシステムであって、バックアップの指示を受けたときに、システム構成全体および個々のプラグインソフトのバージョン情報ならびにプラグインソフトに対応するオプションハードウェアの識別情報を対応付け、管理情報として登録する手段と、リカバリの指示を受けたときに、上記管理情報に基づきバックアップデータからプラグインソフトを復旧し、上記管理情報に含まれる識別情報が対応するか否かによりオプションハードウェアの動作確認を行う手段とを備える。
【解決手段】コンピュータ組み込み機器におけるソフトウェアのバックアップおよびリカバリを管理するシステムであって、バックアップの指示を受けたときに、システム構成全体および個々のプラグインソフトのバージョン情報ならびにプラグインソフトに対応するオプションハードウェアの識別情報を対応付け、管理情報として登録する手段と、リカバリの指示を受けたときに、上記管理情報に基づきバックアップデータからプラグインソフトを復旧し、上記管理情報に含まれる識別情報が対応するか否かによりオプションハードウェアの動作確認を行う手段とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＭＦＰ（Multi Function Printer）等のコンピュータ組み込み機器に適用可能なプラグインバージョン管理システムに関し、より詳しくは、ソフトウェアのリカバリ時にプラグインソフトおよびオプションハードウェアの動作保障を行うことのできるプラグインバージョン管理システムに関する。
【背景技術】
【０００２】
ＭＦＰ等のコンピュータ組み込み機器では、基本的なシステムやアプリケーションのソフトウェアの他に、ユーザの選択で追加されたオプションハードウェアに対応するプラグインソフト（アプリケーションソフト）が複数インストールされる。なお、プラグインソフトにも複数のバージョンが存在し、それぞれ機能が異なるため、適切なバージョンのプラグインソフトをインストールする必要がある。
【０００３】
従って、ソフトウェアに障害が発生した場合、全てのソフトウェアにつきバージョンをチェックしながら再インストールするのは困難であるため、正常に動作していた過去のある時点でのバックアップデータを保持しておき、障害発生後にバックアップデータを機器にリストアすることによりリカバリする方法がとられることが多い。
【特許文献１】特開２００４−２３４１５１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上述したように、従来はソフトウェア障害に対してバックアップデータのリストアによるリカバリが行われていたが、単にバックアップデータを記憶領域に再配置するものであったため、次のような問題点が指摘されていた。
【０００５】
すなわち、現状とは異なる環境におけるバックアップデータである可能性があることから、リカバリ後、接続されていないハードウェアデバイスドライバを利用しようとして失敗したり、プラグインソフトのバージョンが違っていたりする等により、ソフトウェアが期待通りに動作しない現象が起こるケースがある。例えば、エラーが発生して処理が継続できなくなったり、課金装置を搭載したＭＦＰの場合に不適切な課金装置を誤用して正しい課金額にならなくなったりする等の事態が考えられる。
【０００６】
また、ユーザが期待通り動作しないことを確認した場合、別のバックアップデータがある場合はそれを用いて再度リカバリを行う必要があり、操作が煩雑であるという問題があった。
【０００７】
更に、このようにバックアップデータのリストアによるリカバリには難しい点があることから、ユーザによるリカバリを推奨せず、再設定のためにＣＥ（Customer Engineer）が顧客先に出向くことも多く、サービス業務への影響も大きかった。
【０００８】
一方、特許文献１にはネットワーク経由で画像形成装置のプログラムを更新する技術が開示されているが、バックアップデータのリストアによるリカバリについては触れられていない。
【０００９】
本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、オプションハードウェアの安定動作を自動で保障することにより、正常に動作しないソフトウェア状態を避けることができ、プラグインカスタマイズをどれだけ実施してもすぐにユーザのシステム環境を元に戻すことのできるプラグインバージョン管理システムを提供することにある。
【課題を解決するための手段】
【００１０】
上記の課題を解決するため、本発明にあっては、請求項１に記載されるように、コンピュータ組み込み機器におけるソフトウェアのバックアップおよびリカバリを管理するシステムであって、バックアップの指示を受けたときに、システム構成全体および個々のプラグインソフトのバージョン情報ならびにプラグインソフトに対応するオプションハードウェアの識別情報を対応付け、管理情報として登録する手段と、リカバリの指示を受けたときに、上記管理情報に基づきバックアップデータからプラグインソフトを復旧し、上記管理情報に含まれる識別情報が対応するか否かによりオプションハードウェアの動作確認を行う手段とを備えるプラグインバージョン管理システムを要旨としている。
【００１１】
また、請求項２に記載されるように、請求項１に記載のプラグインバージョン管理システムにおいて、上記オプションハードウェアの動作確認は、当該オプションハードウェアに対応するプラグインソフトに行わせるようにすることができる。
【００１２】
また、請求項３に記載されるように、請求項１に記載のプラグインバージョン管理システムにおいて、上記オプションハードウェアの動作確認は、上記管理情報に含まれるオプションハードウェアの識別情報とオプションハードウェアから取得した識別情報とが一致するか否かで判断するようにすることができる。
【００１３】
また、請求項４に記載されるように、請求項１に記載のプラグインバージョン管理システムにおいて、上記オプションハードウェアの動作確認が失敗した場合、使用中のバックアップデータが初期バージョンでないことを条件に、一つ前のバージョンのバックアップデータを取得し、リカバリを再度行う手段を備えるようにすることができる。
【００１４】
また、請求項５に記載されるように、請求項１に記載のプラグインバージョン管理システムにおいて、上記オプションハードウェアの動作確認が失敗した場合、使用中のバックアップデータが初期バージョンでないことを条件に、現在接続中のオプションハードウェアの識別情報に対応する情報を含むバージョンのバックアップデータを取得し、リカバリを再度行う手段を備えるようにすることができる。
【００１５】
また、請求項６に記載されるように、請求項１に記載のプラグインバージョン管理システムにおいて、上記オプションハードウェアの動作確認につき、上記プラグインソフトはバックアップデータからオプションハードウェアの識別情報を取得し、また、オプションハードウェアから識別情報を取得するようにすることができる。
【００１６】
また、請求項７に記載されるように、請求項１に記載のプラグインバージョン管理システムにおいて、上記オプションハードウェアの動作確認につき、上記プラグインソフトは初期状態でバックアップデータに含まれるオプションハードウェアの識別情報を与えられ、また、オプションハードウェアから識別情報を取得するようにすることができる。
【００１７】
また、請求項８〜１２に記載されるように、プラグインバージョン管理方法として構成することができる。
【発明の効果】
【００１８】
本発明のプラグインバージョン管理システムにあっては、オプションハードウェアの安定動作を自動で保障することにより、正常に動作しないソフトウェア状態を避けることができ、プラグインカスタマイズをどれだけ実施してもすぐにユーザのシステム環境を元に戻すことができる。
【発明を実施するための最良の形態】
【００１９】
以下、本発明の好適な実施形態につき説明する。
【００２０】
＜システム構成＞
図１は本発明の一実施形態にかかるプラグインバージョン管理システムの構成例を示す図である。図１において、プラグインバージョン管理システムは、ユーザが操作するユーザインタフェース部１と、データをバージョン情報ごとに管理するバージョン管理部２と、システムに対して自由に付け外しが可能で、所定のハードウェアを制御するプラグインソフト３と、プラグインソフト３による制御に基づいて動作するオプションハードウェア４と、データを保存するデータ保存部５とを備えている。なお、プラグインソフト３とオプションハードウェア４は複数存在することがある。また、データとしては、システム全体で持つデータ（機器ＩＤ等）と、プラグイン固有のデータ（プラグイン名、プラグインＩＤ，バージョン情報、オプションハードウェアの機器名等）とがある。
【００２１】
図２はプラグインソフト３およびオプションハードウェア４等の具体例を含むシステム構成例を示す図であり、プラグインソフト３として、スキャン用のプラグインソフト３Ａとプロット用のプラグインソフト３Ｂと磁気カード課金用のプラグインソフト３Ｃとを設け、オプションハードウェア４として、スキャナのオプションハードウェア４Ａとプロッタのオプションハードウェア４Ｂと磁気カード課金装置のオプションハードウェア４Ｃとを設けたものである。また、データ保存部５はローカルＨＤＤ（Hard Disk Drive）としている。
【００２２】
図３はプラグインソフト３のソフトウェア構成上の位置付けを示す図であり、オペレーティングシステム６の上で動作するミドルウェア７の更に上に、プラグインソフト３Ａ〜３Ｃは位置するものである。
【００２３】
図４はプラグインソフト３の構成例を示す図であり、ＳＤＫ（Software Development Kit）８に設けられた抽象的なプラグインソフト（共通機能を有し、バックアップ機能を他モジュールで実装）をベースに、変動分の機能（スキャン機能、プロット機能、磁気カード課金機能等）を実装することでプラグインソフト３Ａ〜３Ｃを構成する。
【００２４】
＜バックアップ時の処理＞
図５はバックアップ時の処理例を示すシーケンス図である。
【００２５】
図５において、先ず、ユーザインタフェース部１は、管理者から入力された「システムバックアップ指示（ログ、ラベル等を含む）」をバージョン管理部２に送信する（ステップＳ１０１）。ここで、ログとラベルはバックアップの状況を示すものであり、例えば、ログは「２００６／１０／３ ＣＥが作成」、ラベルは「初期セットアップ済み」といった内容である。
【００２６】
バージョン管理部２は、自身が持つプラグインソフト名一覧テーブル（図示せず）を参照してバックアップ対象となるプラグインソフト３を特定し、特定したプラグインソフト３に対して「プラグインバックアップ指示」を送信する（ステップＳ１０２）。この「プラグインバックアップ指示」の送信はプラグインソフトの個数分行う。
【００２７】
プラグインソフト３は、「プラグインバックアップ指示」を受け付けると、対応するオプションハードウェア４に「オプションハードウェア名の取得指示」を送信する（ステップＳ１０３）。
【００２８】
オプションハードウェア４は、「オプションハードウェア名の取得指示」に基づいてオプションハードウェア名を含む戻りをプラグインソフト３に送信する（ステップＳ１０４）。図６はオプションハードウェア名（機器名称）の例を示す図であり、ここでは「社員証リーダ」となっている。なお、オプションハードウェア名（機器名称）に代えて製造番号を使用することもでき、一般的にはオプションハードウェアを識別することができる識別情報であればよい（以下同様）。
【００２９】
図５に戻り、プラグインソフト３は、「オプションハードウェア名の取得指示」の戻り（オプションハードウェア名を含む）を受信すると、自身が持つプラグインデータテーブル（図示せず）から、プラグインＩＤとバージョン情報を取得し、これらを１つのテーブルにまとめ直して、そのテーブルをバージョン管理部２に送信する（ステップＳ１０５）。図７はプラグインＩＤ、バージョン情報およびオプションハードウェア名をまとめたテーブルの例を示す図である。
【００３０】
図５に戻り、バージョン管理部２は、「プラグインバックアップ指示」の戻り（テーブルを含む）を送信対象とした全てのプラグインから受信すると、自身の持つデータテーブル（図示せず）から構成バージョン情報を取得し、既に「システムバックアップ指示」（ステップＳ１０１）の際に得たログ情報・ラベルとあわせ、これらを１つのテーブルにまとめ直し、そのテーブルの「セーブ（登録）指示」をデータ保存部５に送信する（ステップＳ１０６）。図８は構成バージョン情報、ログ、ラベル、プラグインＩＤ、バージョン情報およびオプションハードウェア名をまとめたテーブルの例を示す図である。
【００３１】
図５に戻り、データ保存部５は、「セーブ（登録）指示」からバージョン情報・ログ情報・ラベル等を得ると、これらをバックアップデータの管理情報として保存（更新を含む）し、保存が完了した旨を「セーブ（登録）指示」の戻りとしてバージョン管理部２に送信する（ステップＳ１０７）。
【００３２】
バージョン管理部２は、保存が完了した旨を受信すると、その旨を「システムバックアップ指示」の戻りとしてユーザインタフェース部１に通知する（ステップＳ１０８）。
【００３３】
これらの動作は、システム構成が変わったときや設定を変えたとき、あるいは定期的に行われ、併せてプログラム本体のバックアップデータも保存され、データ保存部５にデータが蓄積されていく。図９はデータ保存部５に登録される情報の例を示す図であり、システム構成情報の構成バージョン情報に関連付けられて、構成バージョン情報、ログ、ラベル、プラグインＩＤ、バージョン情報およびオプションハードウェア名をまとめたテーブルが蓄積されている。データ保存部５内には、認証機構プラグイン本体や紙束整形プラグイン本体についてもバージョン毎に保持されている。ここで、認証機構は、バージョン「１」はＩＣカード利用不能で社員証リーダ利用可能であるが、バージョン「２」はＩＣカード利用可能で社員証リーダ利用不能となっており、バージョンにより機能が異なる。
【００３４】
＜リカバリ時の処理＞
図１０はリカバリ時の処理例を示すシーケンス図である。
【００３５】
図１０において、先ず、ユーザインタフェース部１は、管理者から入力された「リストア（構成ｖｅｒを含む）」指示をバージョン管理部２に送信する（ステップＳ２０１）。
【００３６】
バージョン管理部２は、「リストア（構成ｖｅｒを含む）」指示を受信すると、構成ｖｅｒを確認し、入力された構成ｖｅｒが、自身の構成ｖｅｒ（現時点のバージョン）と等しい場合は、以下の処理を行わず最後のシーケンスに移動し、リストア不要であることをユーザインタフェース部１に送信する（ステップＳ２１５）。
【００３７】
入力された構成ｖｅｒが、自身の構成ｖｅｒと等しくない場合、バージョン管理部２は、データ保存部５に「バックアップデータの一覧をロード（構成ｖｅｒを含む）」指示を送信する（ステップＳ２０２）。
【００３８】
データ保存部５は、「バックアップデータの一覧をロード（構成ｖｅｒを含む）」指示を受信すると、構成ｖｅｒに相当するデータ（管理情報）を検索し、当該データを「バックアップデータの一覧をロード（構成ｖｅｒを含む）」指示の戻りとしてバージョン管理部２に送信する（ステップＳ２０３）。
【００３９】
バージョン管理部２は、データ保存部５からの「バックアップデータの一覧をロード」指示の戻り（プラグインＩＤ、プラグインｖｅｒを含む）の返信を受けて、プラグインＩＤ，プラグインｖｅｒからロード対象のプラグイン本体を特定し、データ保存部５に「プラグインの本体データをロード（プラグインＩＤとプラグインｖｅｒを含む）」指示を送信する（ステップＳ２０４）。この指示はプラグインの個数分行う。
【００４０】
データ保存部５は、バージョン管理部２からの「プラグインの本体データをロード」指示を受信すると、当該プラグイン本体データを検索し、そのデータ本体を「プラグインの本体データをロード」指示の戻りとしてバージョン管理部２に返信する（ステップＳ２０５）。
【００４１】
バージョン管理部２は、データ保存部５から「プラグインの本体データをロード」指示の戻り（プラグインデータの本体を含む）を受信すると、システムにプラグインを組み込む（メモリ上にロードする）ために、「プラグイン本体をメモリ上に展開」を実施する（ステップＳ２０６）。この振る舞いは、ロードしたてのプラグインは、ファイルのまま（例えば、ｚｉｐファイルに圧縮されていたりする）であり、機能を提供できないため実施する。
【００４２】
バージョン管理部２は、「プラグイン本体をメモリ上に展開」の終了後、プラグインソフト３に「整合性チェック」指示を送信する（ステップＳ２０７）。
【００４３】
プラグインソフト３は、バージョン管理部２から「整合性チェック」指示を受信すると、バックアップのシーケンス（図５）において自身がデータ保存部５に送信した情報を参照するために、「オプションハードウェア名の取得（プラグインＩＤ、プラグインｖｅｒを含む）」をバージョン管理部２に送信する（ステップＳ２０８）。
【００４４】
バージョン管理部２は、プラグインソフト３からの「オプションハードウェア名の取得」を受信すると、「バックアップデータの一覧をロード（構成ｖｅｒを含む）」指示の戻り（ステップＳ２０３）にて得たデータテーブルより当該機器名称を抽出し、バージョン管理部２に返信する（ステップＳ２０９）。
【００４５】
プラグインソフト３は、オプションハードウェア４に対し、「オプションハードウェア名の取得」指示を送信する（ステップＳ２１０）。
【００４６】
オプションハードウェア４は、「オプションハードウェア名の取得」指示を受信すると、自身のファームウェア情報を参照して機器名称を取得し、プラグインソフト３に返信する（ステップＳ２１１）。
【００４７】
プラグインソフト３は、オプションハードウェア４から「オプションハードウェア名の取得」指示の戻り（機器名称を含む）を受信すると、バージョン管理部２から取得した機器名称とオプションハードウェア４から取得した機器名称がマッチするかどうかで適切なハードか確認する（ステップＳ２１２）。すなわち、両者がマッチする場合は、プラグイン安定動作可能、マッチしない場合はプラグイン安定動作不能、という結果を算出する（ステップＳ２１３）。
【００４８】
図１１は適切なハードか確認する処理の例を示すフローチャートであり、処理を開始すると（ステップＳ３０１）、バックアップデータから取得した名前と機器から直接に取得した名前とを比較し（ステップＳ３０２）、両者が一致する場合（ステップＳ３０３のＹｅｓ）は正常動作できると判断し（ステップＳ３０４）、両者が一致しない場合（ステップＳ３０３のＮｏ）はエラー報告（リカバリ失敗）とする（ステップＳ３０５）。オプションハードウェア４の確認処理をプラグインソフト３側で行うようにしているため、バージョン管理部２側はオプションハードウェア４のインタフェースを意識する必要がなく、プラグインソフト３にオプションハードウェア４の違いを吸収させることができる。
【００４９】
図１０に戻り、プラグインソフト３は、判定結果を、「整合性チェック」の戻り（プラグイン安定動作 可／不可を含む）としてバージョン管理部２に返信する（ステップＳ２１４）。
【００５０】
バージョン管理部２は、送信対象とした全てのプラグインソフト３から返信（プラグイン安定動作 可／不可を含む）を受信し、受信内容が全て「プラグイン安定動作 可」だった場合、利用者（管理者）に「システム安定動作 可」を返信する（ステップＳ２１５）。なお、一つでも「プラグイン安定動作 不可」があった場合は、利用者（管理者）に「システム安定動作 不可」を返信する（ステップＳ２１５）。
【００５１】
＜オートリカバリ処理＞
図１２はリカバリ失敗時の処理例を示すフローチャートであり、リカバリ失敗と判断された場合であっても、可能な限りリカバリできるようにしたものである。
【００５２】
図１２において、リカバリ失敗により処理を開始すると（ステップＳ３１１）、現在のバックアップデータのバージョンを確認する（ステップＳ３１２）。
【００５３】
ここで、バージョンが１より大きくない場合、すなわちバージョンが１の場合（ステップＳ３１３のＮｏ）は、初期バージョンであってそれ以前のバージョンのバックアップデータは存在しないため、リカバリ失敗を確定する（ステップＳ３１４）。
【００５４】
また、バージョンが１よりも大きい場合（ステップＳ３１３のＹｅｓ）は、データベースに一つ前のバージョンのバックアップデータを問い合わせ（ステップＳ３１５）、バックアップデータの一覧取得に戻る（ステップＳ３１６）。すなわち、この場合は処理を終了せず、図１０のバックアップデータの一覧をロードする処理（ステップＳ２０２）から処理を繰り返す。
【００５５】
図１３はリカバリ失敗時の他の処理例を示すフローチャートであり、予め動かない機器とプラグインの組合せがわかっているため、データベース上のデータのマッチング処理でリカバリすべきバックアップデータの絞込みをするようにしたものである。
【００５６】
図１３において、リカバリ失敗により処理を開始すると（ステップＳ３２１）、現在のバックアップデータのバージョンを確認する（ステップＳ３２２）。
【００５７】
ここで、バージョンが１より大きくない場合、すなわちバージョンが１の場合（ステップＳ３２３のＮｏ）は、初期バージョンであってそれ以前のバージョンのバックアップデータは存在しないため、リカバリ失敗を確定する（ステップＳ３２４）。
【００５８】
また、バージョンが１よりも大きい場合（ステップＳ３２３のＹｅｓ）は、データベースに一つ前のバージョンのバックアップデータを問い合わせ（ステップＳ３２５）、バックアップデータ中に現在接続中の機器名があるか探す（ステップＳ３２６）。
【００５９】
そして、機器名が含まれない場合（ステップＳ３２７のＮｏ）は、一つ前のバージョンのバックアップデータの問い合わせ（ステップＳ３２５）に戻る。
【００６０】
また、機器名が含まれる場合（ステップＳ３２７のＹｅｓ）は、そのバックアップデータを用いたリカバリ処理に移る（ステップＳ３２８）。すなわち、この場合は処理を終了せず、図１０のバックアップデータの一覧をロードする処理（ステップＳ２０２）から処理を繰り返す。
【００６１】
＜リカバリ時の処理（他パターン）＞
図１４はリカバリ時の他の処理例を示すシーケンス図である。図１０に示した処理例との差異は、バージョン管理部２が「プラグイン本体をメモリ上に展開」を実施するとき（ステップＳ４０６）に、同時にバックアップデータからバージョン管理部２が取得済みのオプションハードウェア機器名称の情報を渡してしまうことにより、プラグインソフト３が改めてバージョン管理部２に同情報（機器名称）を問い返すメッセージのやり取りを不要にしている点にある。
【００６２】
図１４において、先ず、ユーザインタフェース部１は、管理者から入力された「リストア（構成ｖｅｒを含む）」指示をバージョン管理部２に送信する（ステップＳ４０１）。
【００６３】
バージョン管理部２は、「リストア（構成ｖｅｒを含む）」指示を受信すると、構成ｖｅｒを確認し、入力された構成ｖｅｒが、自身の構成ｖｅｒ（現時点のバージョン）と等しい場合は、以下の処理を行わず最後のシーケンスに移動し、リストア不要であることをユーザインタフェース部１に送信する（ステップＳ４１２）。
【００６４】
入力された構成ｖｅｒが、自身の構成ｖｅｒと等しくない場合、バージョン管理部２は、データ保存部５に「バックアップデータの一覧をロード（構成ｖｅｒを含む）」指示を送信する（ステップＳ４０２）。
【００６５】
データ保存部５は、「バックアップデータの一覧をロード（構成ｖｅｒを含む）」指示を受信すると、構成ｖｅｒに相当するデータを検索し、当該データを「バックアップデータの一覧をロード（構成ｖｅｒを含む）」指示の戻りとしてバージョン管理部２に送信する（ステップＳ４０３）。
【００６６】
バージョン管理部２は、データ保存部５からの「バックアップデータの一覧をロード」指示の戻り（プラグインＩＤ、プラグインｖｅｒを含む）の返信を受けて、プラグインＩＤ，プラグインｖｅｒからロード対象のプラグイン本体を特定し、データ保存部５に「プラグインの本体データをロード（プラグインＩＤとプラグインｖｅｒを含む）」指示を送信する（ステップＳ４０４）。この指示はプラグインの個数分行う。
【００６７】
データ保存部５は、バージョン管理部２からの「プラグインの本体データをロード」指示を受信すると、当該プラグイン本体データを検索し、そのデータ本体を「プラグインの本体データをロード」指示の戻りとしてバージョン管理部２に返信する（ステップＳ４０５）。
【００６８】
バージョン管理部２は、データ保存部５から「プラグインの本体データをロード」指示の戻り（プラグインデータの本体を含む）を受信すると、システムにプラグインを組み込む（メモリ上にロードする）ために、「プラグイン本体をメモリ上に展開」を実施する（ステップＳ４０６）。この振る舞いは、ロードしたてのプラグインは、ファイルのまま（例えば、ｚｉｐファイルに圧縮されていたりする）であり、機能を提供できないため実施する。このとき（初期化時）に、機器名称の情報も同時にプラグインソフト３に送信する。
【００６９】
プラグインソフト３は、オプションハードウェア４に対し、「オプションハードウェア名の取得」指示を送信する（ステップＳ４０７）。
【００７０】
オプションハードウェア４は、「オプションハードウェア名の取得」指示を受信すると、自身のファームウェア情報を参照して機器名称を取得し、プラグインソフト３に返信する（ステップＳ４０８）。
【００７１】
プラグインソフト３は、オプションハードウェア４から「オプションハードウェア名の取得」指示の戻り（機器名称を含む）を受信すると、バージョン管理部２から既に通知されている機器名称とオプションハードウェア４から取得した機器名称がマッチするかどうかで適切なハードか確認する（ステップＳ４０９）。すなわち、両者がマッチする場合は、プラグイン安定動作可能、マッチしない場合はプラグイン安定動作不能、という結果を算出する（ステップＳ４１０）。
【００７２】
プラグインソフト３は、バージョン管理部２にプラグインがハード込みで動作可能か報告し（ステップＳ４１１）、バージョン管理部２は、送信対象とした全てのプラグインソフト３から返信（プラグイン安定動作 可／不可を含む）を受信し、受信内容が全て「プラグイン安定動作 可」だった場合、利用者（管理者）に「システム安定動作 可」を返信する（ステップＳ４１２）。なお、一つでも「プラグイン安定動作 不可」があった場合は、利用者（管理者）に「システム安定動作 不可」を返信する（ステップＳ４１２）。
【００７３】
また、これらの処理に対し、図１２、図１３に示した処理を適用することができる。
【００７４】
＜総括＞
このように、本発明では、バックアップデータをリカバリする際にプラグインソフトによりセルフチェックを実行し、所定のオプションハードウェアが利用できるかチェックしている。
【００７５】
従って、様々なカスタマイズ環境を手軽に利用可能であり、別のシステムでとった（セットアップ済み）バックアップを用いて容易にセットアップすることもできる。
【００７６】
以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。
【００７７】
＜特許請求の範囲との対応関係＞
請求項１、８における「バックアップの指示を受けたときに、システム構成全体および個々のプラグインソフトのバージョン情報ならびにプラグインソフトの識別情報を対応付け、管理情報として登録する手段（工程）」は、バージョン管理部２（図１、２）に対応し、その処理内容は図５におけるステップＳ１０２〜Ｓ１０８に対応する。
【００７８】
請求項１、８における「リカバリの指示を受けたときに、バックアップデータからプラグインソフトを復旧し、上記管理情報に含まれる識別情報が対応するか否かによりオプションハードウェアの動作確認を行う手段（工程）」は、バージョン管理部２（図１、２）に対応し、その処理内容は図１０におけるステップＳ２０２〜Ｓ２１５、もしくは、図１４におけるステップＳ４０２〜Ｓ４１２に対応する。
【００７９】
請求項４、１１における「上記オプションハードウェアの動作確認が失敗した場合、使用中のバックアップデータが初期バージョンでないことを条件に、一つ前のバージョンのバックアップデータを取得し、リカバリを再度行う手段（工程）」は、バージョン管理部２（図１、２）に対応し、その処理内容は図１２に対応する。
【００８０】
請求項５、１２における「上記オプションハードウェアの動作確認が失敗した場合、使用中のバックアップデータが初期バージョンでないことを条件に、現在接続中のオプションハードウェアの識別情報に対応する情報を含むバージョンのバックアップデータを取得し、リカバリを再度行う手段（工程）」バージョン管理部２（図１、２）に対応し、その処理内容は図１３に対応する。
【図面の簡単な説明】
【００８１】
【図１】本発明の一実施形態にかかるプラグインバージョン管理システムの構成例を示す図である。
【図２】プラグインソフトおよびオプションハードウェア等の具体例を含むシステム構成例を示す図である。
【図３】プラグインソフトのソフトウェア構成上の位置付けを示す図である。
【図４】プラグインソフトの構成例を示す図である。
【図５】バックアップ時の処理例を示すシーケンス図である。
【図６】オプションハードウェア名の例を示す図である。
【図７】プラグインＩＤ、バージョン情報およびオプションハードウェア名をまとめたテーブルの例を示す図である。
【図８】構成バージョン情報、ログ、ラベル、プラグインＩＤ、バージョン情報およびオプションハードウェア名をまとめたテーブルの例を示す図である。
【図９】データ保存部に登録される情報の例を示す図である。
【図１０】リカバリ時の処理例を示すシーケンス図（その１）である。
【図１１】適切なハードか確認する処理の例を示すフローチャートである。
【図１２】リカバリ失敗時の処理例を示すフローチャート（その１）である。
【図１３】リカバリ失敗時の処理例を示すフローチャート（その２）である。
【図１４】リカバリ時の処理例を示すシーケンス図（その２）である。
【符号の説明】
【００８２】
１ ユーザインタフェース部
２ バージョン管理部
３、３Ａ〜３Ｃ プラグインソフト
４、４Ａ〜４Ｃ オプションハードウェア
５ データ保存部
６ オペレーティングシステム
７ ミドルウェア
８ ＳＤＫ
【技術分野】
【０００１】
本発明は、ＭＦＰ（Multi Function Printer）等のコンピュータ組み込み機器に適用可能なプラグインバージョン管理システムに関し、より詳しくは、ソフトウェアのリカバリ時にプラグインソフトおよびオプションハードウェアの動作保障を行うことのできるプラグインバージョン管理システムに関する。
【背景技術】
【０００２】
ＭＦＰ等のコンピュータ組み込み機器では、基本的なシステムやアプリケーションのソフトウェアの他に、ユーザの選択で追加されたオプションハードウェアに対応するプラグインソフト（アプリケーションソフト）が複数インストールされる。なお、プラグインソフトにも複数のバージョンが存在し、それぞれ機能が異なるため、適切なバージョンのプラグインソフトをインストールする必要がある。
【０００３】
従って、ソフトウェアに障害が発生した場合、全てのソフトウェアにつきバージョンをチェックしながら再インストールするのは困難であるため、正常に動作していた過去のある時点でのバックアップデータを保持しておき、障害発生後にバックアップデータを機器にリストアすることによりリカバリする方法がとられることが多い。
【特許文献１】特開２００４−２３４１５１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上述したように、従来はソフトウェア障害に対してバックアップデータのリストアによるリカバリが行われていたが、単にバックアップデータを記憶領域に再配置するものであったため、次のような問題点が指摘されていた。
【０００５】
すなわち、現状とは異なる環境におけるバックアップデータである可能性があることから、リカバリ後、接続されていないハードウェアデバイスドライバを利用しようとして失敗したり、プラグインソフトのバージョンが違っていたりする等により、ソフトウェアが期待通りに動作しない現象が起こるケースがある。例えば、エラーが発生して処理が継続できなくなったり、課金装置を搭載したＭＦＰの場合に不適切な課金装置を誤用して正しい課金額にならなくなったりする等の事態が考えられる。
【０００６】
また、ユーザが期待通り動作しないことを確認した場合、別のバックアップデータがある場合はそれを用いて再度リカバリを行う必要があり、操作が煩雑であるという問題があった。
【０００７】
更に、このようにバックアップデータのリストアによるリカバリには難しい点があることから、ユーザによるリカバリを推奨せず、再設定のためにＣＥ（Customer Engineer）が顧客先に出向くことも多く、サービス業務への影響も大きかった。
【０００８】
一方、特許文献１にはネットワーク経由で画像形成装置のプログラムを更新する技術が開示されているが、バックアップデータのリストアによるリカバリについては触れられていない。
【０００９】
本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、オプションハードウェアの安定動作を自動で保障することにより、正常に動作しないソフトウェア状態を避けることができ、プラグインカスタマイズをどれだけ実施してもすぐにユーザのシステム環境を元に戻すことのできるプラグインバージョン管理システムを提供することにある。
【課題を解決するための手段】
【００１０】
上記の課題を解決するため、本発明にあっては、請求項１に記載されるように、コンピュータ組み込み機器におけるソフトウェアのバックアップおよびリカバリを管理するシステムであって、バックアップの指示を受けたときに、システム構成全体および個々のプラグインソフトのバージョン情報ならびにプラグインソフトに対応するオプションハードウェアの識別情報を対応付け、管理情報として登録する手段と、リカバリの指示を受けたときに、上記管理情報に基づきバックアップデータからプラグインソフトを復旧し、上記管理情報に含まれる識別情報が対応するか否かによりオプションハードウェアの動作確認を行う手段とを備えるプラグインバージョン管理システムを要旨としている。
【００１１】
また、請求項２に記載されるように、請求項１に記載のプラグインバージョン管理システムにおいて、上記オプションハードウェアの動作確認は、当該オプションハードウェアに対応するプラグインソフトに行わせるようにすることができる。
【００１２】
また、請求項３に記載されるように、請求項１に記載のプラグインバージョン管理システムにおいて、上記オプションハードウェアの動作確認は、上記管理情報に含まれるオプションハードウェアの識別情報とオプションハードウェアから取得した識別情報とが一致するか否かで判断するようにすることができる。
【００１３】
また、請求項４に記載されるように、請求項１に記載のプラグインバージョン管理システムにおいて、上記オプションハードウェアの動作確認が失敗した場合、使用中のバックアップデータが初期バージョンでないことを条件に、一つ前のバージョンのバックアップデータを取得し、リカバリを再度行う手段を備えるようにすることができる。
【００１４】
また、請求項５に記載されるように、請求項１に記載のプラグインバージョン管理システムにおいて、上記オプションハードウェアの動作確認が失敗した場合、使用中のバックアップデータが初期バージョンでないことを条件に、現在接続中のオプションハードウェアの識別情報に対応する情報を含むバージョンのバックアップデータを取得し、リカバリを再度行う手段を備えるようにすることができる。
【００１５】
また、請求項６に記載されるように、請求項１に記載のプラグインバージョン管理システムにおいて、上記オプションハードウェアの動作確認につき、上記プラグインソフトはバックアップデータからオプションハードウェアの識別情報を取得し、また、オプションハードウェアから識別情報を取得するようにすることができる。
【００１６】
また、請求項７に記載されるように、請求項１に記載のプラグインバージョン管理システムにおいて、上記オプションハードウェアの動作確認につき、上記プラグインソフトは初期状態でバックアップデータに含まれるオプションハードウェアの識別情報を与えられ、また、オプションハードウェアから識別情報を取得するようにすることができる。
【００１７】
また、請求項８〜１２に記載されるように、プラグインバージョン管理方法として構成することができる。
【発明の効果】
【００１８】
本発明のプラグインバージョン管理システムにあっては、オプションハードウェアの安定動作を自動で保障することにより、正常に動作しないソフトウェア状態を避けることができ、プラグインカスタマイズをどれだけ実施してもすぐにユーザのシステム環境を元に戻すことができる。
【発明を実施するための最良の形態】
【００１９】
以下、本発明の好適な実施形態につき説明する。
【００２０】
＜システム構成＞
図１は本発明の一実施形態にかかるプラグインバージョン管理システムの構成例を示す図である。図１において、プラグインバージョン管理システムは、ユーザが操作するユーザインタフェース部１と、データをバージョン情報ごとに管理するバージョン管理部２と、システムに対して自由に付け外しが可能で、所定のハードウェアを制御するプラグインソフト３と、プラグインソフト３による制御に基づいて動作するオプションハードウェア４と、データを保存するデータ保存部５とを備えている。なお、プラグインソフト３とオプションハードウェア４は複数存在することがある。また、データとしては、システム全体で持つデータ（機器ＩＤ等）と、プラグイン固有のデータ（プラグイン名、プラグインＩＤ，バージョン情報、オプションハードウェアの機器名等）とがある。
【００２１】
図２はプラグインソフト３およびオプションハードウェア４等の具体例を含むシステム構成例を示す図であり、プラグインソフト３として、スキャン用のプラグインソフト３Ａとプロット用のプラグインソフト３Ｂと磁気カード課金用のプラグインソフト３Ｃとを設け、オプションハードウェア４として、スキャナのオプションハードウェア４Ａとプロッタのオプションハードウェア４Ｂと磁気カード課金装置のオプションハードウェア４Ｃとを設けたものである。また、データ保存部５はローカルＨＤＤ（Hard Disk Drive）としている。
【００２２】
図３はプラグインソフト３のソフトウェア構成上の位置付けを示す図であり、オペレーティングシステム６の上で動作するミドルウェア７の更に上に、プラグインソフト３Ａ〜３Ｃは位置するものである。
【００２３】
図４はプラグインソフト３の構成例を示す図であり、ＳＤＫ（Software Development Kit）８に設けられた抽象的なプラグインソフト（共通機能を有し、バックアップ機能を他モジュールで実装）をベースに、変動分の機能（スキャン機能、プロット機能、磁気カード課金機能等）を実装することでプラグインソフト３Ａ〜３Ｃを構成する。
【００２４】
＜バックアップ時の処理＞
図５はバックアップ時の処理例を示すシーケンス図である。
【００２５】
図５において、先ず、ユーザインタフェース部１は、管理者から入力された「システムバックアップ指示（ログ、ラベル等を含む）」をバージョン管理部２に送信する（ステップＳ１０１）。ここで、ログとラベルはバックアップの状況を示すものであり、例えば、ログは「２００６／１０／３ ＣＥが作成」、ラベルは「初期セットアップ済み」といった内容である。
【００２６】
バージョン管理部２は、自身が持つプラグインソフト名一覧テーブル（図示せず）を参照してバックアップ対象となるプラグインソフト３を特定し、特定したプラグインソフト３に対して「プラグインバックアップ指示」を送信する（ステップＳ１０２）。この「プラグインバックアップ指示」の送信はプラグインソフトの個数分行う。
【００２７】
プラグインソフト３は、「プラグインバックアップ指示」を受け付けると、対応するオプションハードウェア４に「オプションハードウェア名の取得指示」を送信する（ステップＳ１０３）。
【００２８】
オプションハードウェア４は、「オプションハードウェア名の取得指示」に基づいてオプションハードウェア名を含む戻りをプラグインソフト３に送信する（ステップＳ１０４）。図６はオプションハードウェア名（機器名称）の例を示す図であり、ここでは「社員証リーダ」となっている。なお、オプションハードウェア名（機器名称）に代えて製造番号を使用することもでき、一般的にはオプションハードウェアを識別することができる識別情報であればよい（以下同様）。
【００２９】
図５に戻り、プラグインソフト３は、「オプションハードウェア名の取得指示」の戻り（オプションハードウェア名を含む）を受信すると、自身が持つプラグインデータテーブル（図示せず）から、プラグインＩＤとバージョン情報を取得し、これらを１つのテーブルにまとめ直して、そのテーブルをバージョン管理部２に送信する（ステップＳ１０５）。図７はプラグインＩＤ、バージョン情報およびオプションハードウェア名をまとめたテーブルの例を示す図である。
【００３０】
図５に戻り、バージョン管理部２は、「プラグインバックアップ指示」の戻り（テーブルを含む）を送信対象とした全てのプラグインから受信すると、自身の持つデータテーブル（図示せず）から構成バージョン情報を取得し、既に「システムバックアップ指示」（ステップＳ１０１）の際に得たログ情報・ラベルとあわせ、これらを１つのテーブルにまとめ直し、そのテーブルの「セーブ（登録）指示」をデータ保存部５に送信する（ステップＳ１０６）。図８は構成バージョン情報、ログ、ラベル、プラグインＩＤ、バージョン情報およびオプションハードウェア名をまとめたテーブルの例を示す図である。
【００３１】
図５に戻り、データ保存部５は、「セーブ（登録）指示」からバージョン情報・ログ情報・ラベル等を得ると、これらをバックアップデータの管理情報として保存（更新を含む）し、保存が完了した旨を「セーブ（登録）指示」の戻りとしてバージョン管理部２に送信する（ステップＳ１０７）。
【００３２】
バージョン管理部２は、保存が完了した旨を受信すると、その旨を「システムバックアップ指示」の戻りとしてユーザインタフェース部１に通知する（ステップＳ１０８）。
【００３３】
これらの動作は、システム構成が変わったときや設定を変えたとき、あるいは定期的に行われ、併せてプログラム本体のバックアップデータも保存され、データ保存部５にデータが蓄積されていく。図９はデータ保存部５に登録される情報の例を示す図であり、システム構成情報の構成バージョン情報に関連付けられて、構成バージョン情報、ログ、ラベル、プラグインＩＤ、バージョン情報およびオプションハードウェア名をまとめたテーブルが蓄積されている。データ保存部５内には、認証機構プラグイン本体や紙束整形プラグイン本体についてもバージョン毎に保持されている。ここで、認証機構は、バージョン「１」はＩＣカード利用不能で社員証リーダ利用可能であるが、バージョン「２」はＩＣカード利用可能で社員証リーダ利用不能となっており、バージョンにより機能が異なる。
【００３４】
＜リカバリ時の処理＞
図１０はリカバリ時の処理例を示すシーケンス図である。
【００３５】
図１０において、先ず、ユーザインタフェース部１は、管理者から入力された「リストア（構成ｖｅｒを含む）」指示をバージョン管理部２に送信する（ステップＳ２０１）。
【００３６】
バージョン管理部２は、「リストア（構成ｖｅｒを含む）」指示を受信すると、構成ｖｅｒを確認し、入力された構成ｖｅｒが、自身の構成ｖｅｒ（現時点のバージョン）と等しい場合は、以下の処理を行わず最後のシーケンスに移動し、リストア不要であることをユーザインタフェース部１に送信する（ステップＳ２１５）。
【００３７】
入力された構成ｖｅｒが、自身の構成ｖｅｒと等しくない場合、バージョン管理部２は、データ保存部５に「バックアップデータの一覧をロード（構成ｖｅｒを含む）」指示を送信する（ステップＳ２０２）。
【００３８】
データ保存部５は、「バックアップデータの一覧をロード（構成ｖｅｒを含む）」指示を受信すると、構成ｖｅｒに相当するデータ（管理情報）を検索し、当該データを「バックアップデータの一覧をロード（構成ｖｅｒを含む）」指示の戻りとしてバージョン管理部２に送信する（ステップＳ２０３）。
【００３９】
バージョン管理部２は、データ保存部５からの「バックアップデータの一覧をロード」指示の戻り（プラグインＩＤ、プラグインｖｅｒを含む）の返信を受けて、プラグインＩＤ，プラグインｖｅｒからロード対象のプラグイン本体を特定し、データ保存部５に「プラグインの本体データをロード（プラグインＩＤとプラグインｖｅｒを含む）」指示を送信する（ステップＳ２０４）。この指示はプラグインの個数分行う。
【００４０】
データ保存部５は、バージョン管理部２からの「プラグインの本体データをロード」指示を受信すると、当該プラグイン本体データを検索し、そのデータ本体を「プラグインの本体データをロード」指示の戻りとしてバージョン管理部２に返信する（ステップＳ２０５）。
【００４１】
バージョン管理部２は、データ保存部５から「プラグインの本体データをロード」指示の戻り（プラグインデータの本体を含む）を受信すると、システムにプラグインを組み込む（メモリ上にロードする）ために、「プラグイン本体をメモリ上に展開」を実施する（ステップＳ２０６）。この振る舞いは、ロードしたてのプラグインは、ファイルのまま（例えば、ｚｉｐファイルに圧縮されていたりする）であり、機能を提供できないため実施する。
【００４２】
バージョン管理部２は、「プラグイン本体をメモリ上に展開」の終了後、プラグインソフト３に「整合性チェック」指示を送信する（ステップＳ２０７）。
【００４３】
プラグインソフト３は、バージョン管理部２から「整合性チェック」指示を受信すると、バックアップのシーケンス（図５）において自身がデータ保存部５に送信した情報を参照するために、「オプションハードウェア名の取得（プラグインＩＤ、プラグインｖｅｒを含む）」をバージョン管理部２に送信する（ステップＳ２０８）。
【００４４】
バージョン管理部２は、プラグインソフト３からの「オプションハードウェア名の取得」を受信すると、「バックアップデータの一覧をロード（構成ｖｅｒを含む）」指示の戻り（ステップＳ２０３）にて得たデータテーブルより当該機器名称を抽出し、バージョン管理部２に返信する（ステップＳ２０９）。
【００４５】
プラグインソフト３は、オプションハードウェア４に対し、「オプションハードウェア名の取得」指示を送信する（ステップＳ２１０）。
【００４６】
オプションハードウェア４は、「オプションハードウェア名の取得」指示を受信すると、自身のファームウェア情報を参照して機器名称を取得し、プラグインソフト３に返信する（ステップＳ２１１）。
【００４７】
プラグインソフト３は、オプションハードウェア４から「オプションハードウェア名の取得」指示の戻り（機器名称を含む）を受信すると、バージョン管理部２から取得した機器名称とオプションハードウェア４から取得した機器名称がマッチするかどうかで適切なハードか確認する（ステップＳ２１２）。すなわち、両者がマッチする場合は、プラグイン安定動作可能、マッチしない場合はプラグイン安定動作不能、という結果を算出する（ステップＳ２１３）。
【００４８】
図１１は適切なハードか確認する処理の例を示すフローチャートであり、処理を開始すると（ステップＳ３０１）、バックアップデータから取得した名前と機器から直接に取得した名前とを比較し（ステップＳ３０２）、両者が一致する場合（ステップＳ３０３のＹｅｓ）は正常動作できると判断し（ステップＳ３０４）、両者が一致しない場合（ステップＳ３０３のＮｏ）はエラー報告（リカバリ失敗）とする（ステップＳ３０５）。オプションハードウェア４の確認処理をプラグインソフト３側で行うようにしているため、バージョン管理部２側はオプションハードウェア４のインタフェースを意識する必要がなく、プラグインソフト３にオプションハードウェア４の違いを吸収させることができる。
【００４９】
図１０に戻り、プラグインソフト３は、判定結果を、「整合性チェック」の戻り（プラグイン安定動作 可／不可を含む）としてバージョン管理部２に返信する（ステップＳ２１４）。
【００５０】
バージョン管理部２は、送信対象とした全てのプラグインソフト３から返信（プラグイン安定動作 可／不可を含む）を受信し、受信内容が全て「プラグイン安定動作 可」だった場合、利用者（管理者）に「システム安定動作 可」を返信する（ステップＳ２１５）。なお、一つでも「プラグイン安定動作 不可」があった場合は、利用者（管理者）に「システム安定動作 不可」を返信する（ステップＳ２１５）。
【００５１】
＜オートリカバリ処理＞
図１２はリカバリ失敗時の処理例を示すフローチャートであり、リカバリ失敗と判断された場合であっても、可能な限りリカバリできるようにしたものである。
【００５２】
図１２において、リカバリ失敗により処理を開始すると（ステップＳ３１１）、現在のバックアップデータのバージョンを確認する（ステップＳ３１２）。
【００５３】
ここで、バージョンが１より大きくない場合、すなわちバージョンが１の場合（ステップＳ３１３のＮｏ）は、初期バージョンであってそれ以前のバージョンのバックアップデータは存在しないため、リカバリ失敗を確定する（ステップＳ３１４）。
【００５４】
また、バージョンが１よりも大きい場合（ステップＳ３１３のＹｅｓ）は、データベースに一つ前のバージョンのバックアップデータを問い合わせ（ステップＳ３１５）、バックアップデータの一覧取得に戻る（ステップＳ３１６）。すなわち、この場合は処理を終了せず、図１０のバックアップデータの一覧をロードする処理（ステップＳ２０２）から処理を繰り返す。
【００５５】
図１３はリカバリ失敗時の他の処理例を示すフローチャートであり、予め動かない機器とプラグインの組合せがわかっているため、データベース上のデータのマッチング処理でリカバリすべきバックアップデータの絞込みをするようにしたものである。
【００５６】
図１３において、リカバリ失敗により処理を開始すると（ステップＳ３２１）、現在のバックアップデータのバージョンを確認する（ステップＳ３２２）。
【００５７】
ここで、バージョンが１より大きくない場合、すなわちバージョンが１の場合（ステップＳ３２３のＮｏ）は、初期バージョンであってそれ以前のバージョンのバックアップデータは存在しないため、リカバリ失敗を確定する（ステップＳ３２４）。
【００５８】
また、バージョンが１よりも大きい場合（ステップＳ３２３のＹｅｓ）は、データベースに一つ前のバージョンのバックアップデータを問い合わせ（ステップＳ３２５）、バックアップデータ中に現在接続中の機器名があるか探す（ステップＳ３２６）。
【００５９】
そして、機器名が含まれない場合（ステップＳ３２７のＮｏ）は、一つ前のバージョンのバックアップデータの問い合わせ（ステップＳ３２５）に戻る。
【００６０】
また、機器名が含まれる場合（ステップＳ３２７のＹｅｓ）は、そのバックアップデータを用いたリカバリ処理に移る（ステップＳ３２８）。すなわち、この場合は処理を終了せず、図１０のバックアップデータの一覧をロードする処理（ステップＳ２０２）から処理を繰り返す。
【００６１】
＜リカバリ時の処理（他パターン）＞
図１４はリカバリ時の他の処理例を示すシーケンス図である。図１０に示した処理例との差異は、バージョン管理部２が「プラグイン本体をメモリ上に展開」を実施するとき（ステップＳ４０６）に、同時にバックアップデータからバージョン管理部２が取得済みのオプションハードウェア機器名称の情報を渡してしまうことにより、プラグインソフト３が改めてバージョン管理部２に同情報（機器名称）を問い返すメッセージのやり取りを不要にしている点にある。
【００６２】
図１４において、先ず、ユーザインタフェース部１は、管理者から入力された「リストア（構成ｖｅｒを含む）」指示をバージョン管理部２に送信する（ステップＳ４０１）。
【００６３】
バージョン管理部２は、「リストア（構成ｖｅｒを含む）」指示を受信すると、構成ｖｅｒを確認し、入力された構成ｖｅｒが、自身の構成ｖｅｒ（現時点のバージョン）と等しい場合は、以下の処理を行わず最後のシーケンスに移動し、リストア不要であることをユーザインタフェース部１に送信する（ステップＳ４１２）。
【００６４】
入力された構成ｖｅｒが、自身の構成ｖｅｒと等しくない場合、バージョン管理部２は、データ保存部５に「バックアップデータの一覧をロード（構成ｖｅｒを含む）」指示を送信する（ステップＳ４０２）。
【００６５】
データ保存部５は、「バックアップデータの一覧をロード（構成ｖｅｒを含む）」指示を受信すると、構成ｖｅｒに相当するデータを検索し、当該データを「バックアップデータの一覧をロード（構成ｖｅｒを含む）」指示の戻りとしてバージョン管理部２に送信する（ステップＳ４０３）。
【００６６】
バージョン管理部２は、データ保存部５からの「バックアップデータの一覧をロード」指示の戻り（プラグインＩＤ、プラグインｖｅｒを含む）の返信を受けて、プラグインＩＤ，プラグインｖｅｒからロード対象のプラグイン本体を特定し、データ保存部５に「プラグインの本体データをロード（プラグインＩＤとプラグインｖｅｒを含む）」指示を送信する（ステップＳ４０４）。この指示はプラグインの個数分行う。
【００６７】
データ保存部５は、バージョン管理部２からの「プラグインの本体データをロード」指示を受信すると、当該プラグイン本体データを検索し、そのデータ本体を「プラグインの本体データをロード」指示の戻りとしてバージョン管理部２に返信する（ステップＳ４０５）。
【００６８】
バージョン管理部２は、データ保存部５から「プラグインの本体データをロード」指示の戻り（プラグインデータの本体を含む）を受信すると、システムにプラグインを組み込む（メモリ上にロードする）ために、「プラグイン本体をメモリ上に展開」を実施する（ステップＳ４０６）。この振る舞いは、ロードしたてのプラグインは、ファイルのまま（例えば、ｚｉｐファイルに圧縮されていたりする）であり、機能を提供できないため実施する。このとき（初期化時）に、機器名称の情報も同時にプラグインソフト３に送信する。
【００６９】
プラグインソフト３は、オプションハードウェア４に対し、「オプションハードウェア名の取得」指示を送信する（ステップＳ４０７）。
【００７０】
オプションハードウェア４は、「オプションハードウェア名の取得」指示を受信すると、自身のファームウェア情報を参照して機器名称を取得し、プラグインソフト３に返信する（ステップＳ４０８）。
【００７１】
プラグインソフト３は、オプションハードウェア４から「オプションハードウェア名の取得」指示の戻り（機器名称を含む）を受信すると、バージョン管理部２から既に通知されている機器名称とオプションハードウェア４から取得した機器名称がマッチするかどうかで適切なハードか確認する（ステップＳ４０９）。すなわち、両者がマッチする場合は、プラグイン安定動作可能、マッチしない場合はプラグイン安定動作不能、という結果を算出する（ステップＳ４１０）。
【００７２】
プラグインソフト３は、バージョン管理部２にプラグインがハード込みで動作可能か報告し（ステップＳ４１１）、バージョン管理部２は、送信対象とした全てのプラグインソフト３から返信（プラグイン安定動作 可／不可を含む）を受信し、受信内容が全て「プラグイン安定動作 可」だった場合、利用者（管理者）に「システム安定動作 可」を返信する（ステップＳ４１２）。なお、一つでも「プラグイン安定動作 不可」があった場合は、利用者（管理者）に「システム安定動作 不可」を返信する（ステップＳ４１２）。
【００７３】
また、これらの処理に対し、図１２、図１３に示した処理を適用することができる。
【００７４】
＜総括＞
このように、本発明では、バックアップデータをリカバリする際にプラグインソフトによりセルフチェックを実行し、所定のオプションハードウェアが利用できるかチェックしている。
【００７５】
従って、様々なカスタマイズ環境を手軽に利用可能であり、別のシステムでとった（セットアップ済み）バックアップを用いて容易にセットアップすることもできる。
【００７６】
以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。
【００７７】
＜特許請求の範囲との対応関係＞
請求項１、８における「バックアップの指示を受けたときに、システム構成全体および個々のプラグインソフトのバージョン情報ならびにプラグインソフトの識別情報を対応付け、管理情報として登録する手段（工程）」は、バージョン管理部２（図１、２）に対応し、その処理内容は図５におけるステップＳ１０２〜Ｓ１０８に対応する。
【００７８】
請求項１、８における「リカバリの指示を受けたときに、バックアップデータからプラグインソフトを復旧し、上記管理情報に含まれる識別情報が対応するか否かによりオプションハードウェアの動作確認を行う手段（工程）」は、バージョン管理部２（図１、２）に対応し、その処理内容は図１０におけるステップＳ２０２〜Ｓ２１５、もしくは、図１４におけるステップＳ４０２〜Ｓ４１２に対応する。
【００７９】
請求項４、１１における「上記オプションハードウェアの動作確認が失敗した場合、使用中のバックアップデータが初期バージョンでないことを条件に、一つ前のバージョンのバックアップデータを取得し、リカバリを再度行う手段（工程）」は、バージョン管理部２（図１、２）に対応し、その処理内容は図１２に対応する。
【００８０】
請求項５、１２における「上記オプションハードウェアの動作確認が失敗した場合、使用中のバックアップデータが初期バージョンでないことを条件に、現在接続中のオプションハードウェアの識別情報に対応する情報を含むバージョンのバックアップデータを取得し、リカバリを再度行う手段（工程）」バージョン管理部２（図１、２）に対応し、その処理内容は図１３に対応する。
【図面の簡単な説明】
【００８１】
【図１】本発明の一実施形態にかかるプラグインバージョン管理システムの構成例を示す図である。
【図２】プラグインソフトおよびオプションハードウェア等の具体例を含むシステム構成例を示す図である。
【図３】プラグインソフトのソフトウェア構成上の位置付けを示す図である。
【図４】プラグインソフトの構成例を示す図である。
【図５】バックアップ時の処理例を示すシーケンス図である。
【図６】オプションハードウェア名の例を示す図である。
【図７】プラグインＩＤ、バージョン情報およびオプションハードウェア名をまとめたテーブルの例を示す図である。
【図８】構成バージョン情報、ログ、ラベル、プラグインＩＤ、バージョン情報およびオプションハードウェア名をまとめたテーブルの例を示す図である。
【図９】データ保存部に登録される情報の例を示す図である。
【図１０】リカバリ時の処理例を示すシーケンス図（その１）である。
【図１１】適切なハードか確認する処理の例を示すフローチャートである。
【図１２】リカバリ失敗時の処理例を示すフローチャート（その１）である。
【図１３】リカバリ失敗時の処理例を示すフローチャート（その２）である。
【図１４】リカバリ時の処理例を示すシーケンス図（その２）である。
【符号の説明】
【００８２】
１ ユーザインタフェース部
２ バージョン管理部
３、３Ａ〜３Ｃ プラグインソフト
４、４Ａ〜４Ｃ オプションハードウェア
５ データ保存部
６ オペレーティングシステム
７ ミドルウェア
８ ＳＤＫ
【特許請求の範囲】
【請求項１】
コンピュータ組み込み機器におけるソフトウェアのバックアップおよびリカバリを管理するシステムであって、
バックアップの指示を受けたときに、システム構成全体および個々のプラグインソフトのバージョン情報ならびにプラグインソフトに対応するオプションハードウェアの識別情報を対応付け、管理情報として登録する手段と、
リカバリの指示を受けたときに、上記管理情報に基づきバックアップデータからプラグインソフトを復旧し、上記管理情報に含まれる識別情報が対応するか否かによりオプションハードウェアの動作確認を行う手段とを備えたことを特徴とするプラグインバージョン管理システム。
【請求項２】
請求項１に記載のプラグインバージョン管理システムにおいて、
上記オプションハードウェアの動作確認は、当該オプションハードウェアに対応するプラグインソフトに行わせることを特徴とするプラグインバージョン管理システム。
【請求項３】
請求項１に記載のプラグインバージョン管理システムにおいて、
上記オプションハードウェアの動作確認は、上記管理情報に含まれるオプションハードウェアの識別情報とオプションハードウェアから取得した識別情報とが一致するか否かで判断することを特徴とするプラグインバージョン管理システム。
【請求項４】
請求項１に記載のプラグインバージョン管理システムにおいて、
上記オプションハードウェアの動作確認が失敗した場合、使用中のバックアップデータが初期バージョンでないことを条件に、一つ前のバージョンのバックアップデータを取得し、リカバリを再度行う手段を備えたことを特徴とするプラグインバージョン管理システム。
【請求項５】
請求項１に記載のプラグインバージョン管理システムにおいて、
上記オプションハードウェアの動作確認が失敗した場合、使用中のバックアップデータが初期バージョンでないことを条件に、現在接続中のオプションハードウェアの識別情報に対応する情報を含むバージョンのバックアップデータを取得し、リカバリを再度行う手段を備えたことを特徴とするプラグインバージョン管理システム。
【請求項６】
請求項１に記載のプラグインバージョン管理システムにおいて、
上記オプションハードウェアの動作確認につき、
上記プラグインソフトはバックアップデータからオプションハードウェアの識別情報を取得し、また、オプションハードウェアから識別情報を取得することを特徴とするプラグインバージョン管理システム。
【請求項７】
請求項１に記載のプラグインバージョン管理システムにおいて、
上記オプションハードウェアの動作確認につき、
上記プラグインソフトは初期状態でバックアップデータに含まれるオプションハードウェアの識別情報を与えられ、また、オプションハードウェアから識別情報を取得することを特徴とするプラグインバージョン管理システム。
【請求項８】
コンピュータ組み込み機器におけるソフトウェアのバックアップおよびリカバリを管理する方法であって、
バックアップの指示を受けたときに、システム構成全体および個々のプラグインソフトのバージョン情報ならびにプラグインソフトに対応するオプションハードウェアの識別情報を対応付け、管理情報として登録する工程と、
リカバリの指示を受けたときに、上記管理情報に基づきバックアップデータからプラグインソフトを復旧し、上記管理情報に含まれる識別情報が対応するか否かによりオプションハードウェアの動作確認を行う工程とを備えたことを特徴とするプラグインバージョン管理方法。
【請求項９】
請求項８に記載のプラグインバージョン管理方法において、
上記オプションハードウェアの動作確認は、当該オプションハードウェアに対応するプラグインソフトに行わせることを特徴とするプラグインバージョン管理方法。
【請求項１０】
請求項８に記載のプラグインバージョン管理方法において、
上記オプションハードウェアの動作確認は、上記管理情報に含まれるオプションハードウェアの識別情報とオプションハードウェアから取得した識別情報とが一致するか否かで判断することを特徴とするプラグインバージョン管理方法。
【請求項１１】
請求項８に記載のプラグインバージョン管理方法において、
上記オプションハードウェアの動作確認が失敗した場合、使用中のバックアップデータが初期バージョンでないことを条件に、一つ前のバージョンのバックアップデータを取得し、リカバリを再度行う工程を備えたことを特徴とするプラグインバージョン管理方法。
【請求項１２】
請求項８に記載のプラグインバージョン管理方法において、
上記オプションハードウェアの動作確認が失敗した場合、使用中のバックアップデータが初期バージョンでないことを条件に、現在接続中のオプションハードウェアの識別情報に対応する情報を含むバージョンのバックアップデータを取得し、リカバリを再度行う工程を備えたことを特徴とするプラグインバージョン管理方法。
【請求項１】
コンピュータ組み込み機器におけるソフトウェアのバックアップおよびリカバリを管理するシステムであって、
バックアップの指示を受けたときに、システム構成全体および個々のプラグインソフトのバージョン情報ならびにプラグインソフトに対応するオプションハードウェアの識別情報を対応付け、管理情報として登録する手段と、
リカバリの指示を受けたときに、上記管理情報に基づきバックアップデータからプラグインソフトを復旧し、上記管理情報に含まれる識別情報が対応するか否かによりオプションハードウェアの動作確認を行う手段とを備えたことを特徴とするプラグインバージョン管理システム。
【請求項２】
請求項１に記載のプラグインバージョン管理システムにおいて、
上記オプションハードウェアの動作確認は、当該オプションハードウェアに対応するプラグインソフトに行わせることを特徴とするプラグインバージョン管理システム。
【請求項３】
請求項１に記載のプラグインバージョン管理システムにおいて、
上記オプションハードウェアの動作確認は、上記管理情報に含まれるオプションハードウェアの識別情報とオプションハードウェアから取得した識別情報とが一致するか否かで判断することを特徴とするプラグインバージョン管理システム。
【請求項４】
請求項１に記載のプラグインバージョン管理システムにおいて、
上記オプションハードウェアの動作確認が失敗した場合、使用中のバックアップデータが初期バージョンでないことを条件に、一つ前のバージョンのバックアップデータを取得し、リカバリを再度行う手段を備えたことを特徴とするプラグインバージョン管理システム。
【請求項５】
請求項１に記載のプラグインバージョン管理システムにおいて、
上記オプションハードウェアの動作確認が失敗した場合、使用中のバックアップデータが初期バージョンでないことを条件に、現在接続中のオプションハードウェアの識別情報に対応する情報を含むバージョンのバックアップデータを取得し、リカバリを再度行う手段を備えたことを特徴とするプラグインバージョン管理システム。
【請求項６】
請求項１に記載のプラグインバージョン管理システムにおいて、
上記オプションハードウェアの動作確認につき、
上記プラグインソフトはバックアップデータからオプションハードウェアの識別情報を取得し、また、オプションハードウェアから識別情報を取得することを特徴とするプラグインバージョン管理システム。
【請求項７】
請求項１に記載のプラグインバージョン管理システムにおいて、
上記オプションハードウェアの動作確認につき、
上記プラグインソフトは初期状態でバックアップデータに含まれるオプションハードウェアの識別情報を与えられ、また、オプションハードウェアから識別情報を取得することを特徴とするプラグインバージョン管理システム。
【請求項８】
コンピュータ組み込み機器におけるソフトウェアのバックアップおよびリカバリを管理する方法であって、
バックアップの指示を受けたときに、システム構成全体および個々のプラグインソフトのバージョン情報ならびにプラグインソフトに対応するオプションハードウェアの識別情報を対応付け、管理情報として登録する工程と、
リカバリの指示を受けたときに、上記管理情報に基づきバックアップデータからプラグインソフトを復旧し、上記管理情報に含まれる識別情報が対応するか否かによりオプションハードウェアの動作確認を行う工程とを備えたことを特徴とするプラグインバージョン管理方法。
【請求項９】
請求項８に記載のプラグインバージョン管理方法において、
上記オプションハードウェアの動作確認は、当該オプションハードウェアに対応するプラグインソフトに行わせることを特徴とするプラグインバージョン管理方法。
【請求項１０】
請求項８に記載のプラグインバージョン管理方法において、
上記オプションハードウェアの動作確認は、上記管理情報に含まれるオプションハードウェアの識別情報とオプションハードウェアから取得した識別情報とが一致するか否かで判断することを特徴とするプラグインバージョン管理方法。
【請求項１１】
請求項８に記載のプラグインバージョン管理方法において、
上記オプションハードウェアの動作確認が失敗した場合、使用中のバックアップデータが初期バージョンでないことを条件に、一つ前のバージョンのバックアップデータを取得し、リカバリを再度行う工程を備えたことを特徴とするプラグインバージョン管理方法。
【請求項１２】
請求項８に記載のプラグインバージョン管理方法において、
上記オプションハードウェアの動作確認が失敗した場合、使用中のバックアップデータが初期バージョンでないことを条件に、現在接続中のオプションハードウェアの識別情報に対応する情報を含むバージョンのバックアップデータを取得し、リカバリを再度行う工程を備えたことを特徴とするプラグインバージョン管理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２００７−３１０８０７（Ｐ２００７−３１０８０７Ａ）
【公開日】平成１９年１１月２９日（２００７．１１．２９）
【国際特許分類】
【出願番号】特願２００６−１４１６７３（Ｐ２００６−１４１６７３）
【出願日】平成１８年５月２２日（２００６．５．２２）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
【公開日】平成１９年１１月２９日（２００７．１１．２９）
【国際特許分類】
【出願日】平成１８年５月２２日（２００６．５．２２）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
[ Back to top ]