JP2021047620A - 情報処理装置、ソフトウェア管理方法及びプログラム - Google Patents

Abstract

【課題】検証に失敗したソフトウェアの復旧を可能にするコスト効率のよい仕組みを実現すること。【解決手段】通信部、ソフトウェアを記憶する記憶部、前記ソフトウェアの正当性を検証する検証部、及び前記検証部により正当であると判定された前記ソフトウェアを実行する実行部、を備える情報処理装置において、前記通信部は、前記ソフトウェアに対応するソフトウェアを記憶する記憶部及び当該ソフトウェアを実行する実行部を備える他の装置と通信可能であり、前記情報処理装置の前記記憶部に記憶されている前記ソフトウェアが正当ではないと前記検証部により判定された場合に、前記通信部は、前記他の装置から、前記対応するソフトウェアを受信し、前記情報処理装置の前記記憶部は、前記通信部により受信された前記対応するソフトウェアを記憶し、前記情報処理装置の前記実行部は、前記記憶部に記憶された前記対応するソフトウェアを実行する。【選択図】図２

Description

本開示は、情報処理装置、ソフトウェア管理方法及びプログラムに関する。

情報機器に組み込まれるソフトウェアに不正にアクセスした第三者又は不正なプログラムがソフトウェアを改竄するリスクへの対策として、機器の起動時にソフトウェアの正当性を検証する手法が知られている。ソフトウェアの正当性の検証は、ソフトウェアの改竄のみならずソフトウェアの経年劣化に起因する不具合を防止する観点からも有益である。

特許文献１は、情報機器の起動時のソフトウェアの検証に失敗した場合に、正当なソフトウェアを外部の管理サーバから情報機器へダウンロードすることで、ソフトウェアを復旧する手法を開示している。

特開２０１４−１７９０４７号公報

しかしながら、特許文献１により開示された手法は、正当なソフトウェアを提供する管理サーバを予め用意しておくことを要し、システムの構築及び運用のコストを増大させる。一方、個々の装置の内部でソフトウェアのバックアップを追加的に保持する手法も考えられるが、改竄に対してロバストなメモリデバイスは一般に高価であり、バックアップを追加的に保持する手法もまたコスト面で改善の余地を有する。

そこで、本開示は、検証に失敗したソフトウェアの復旧を可能にするコスト効率のよい仕組みを実現することを目的とする。

ある観点によれば、通信部、ソフトウェアを記憶する記憶部、前記ソフトウェアの正当性を検証する検証部、及び前記検証部により正当であると判定された前記ソフトウェアを実行する実行部、を備える情報処理装置であって、前記通信部は、前記ソフトウェアに対応するソフトウェアを記憶する記憶部及び当該ソフトウェアを実行する実行部を備える他の装置と通信可能であり、前記情報処理装置の前記記憶部に記憶されている前記ソフトウェアが正当ではないと前記検証部により判定された場合に、前記通信部は、前記他の装置から、前記対応するソフトウェアを受信し、前記情報処理装置の前記記憶部は、前記通信部により受信された前記対応するソフトウェアを記憶し、前記情報処理装置の前記実行部は、前記記憶部に記憶された前記対応するソフトウェアを実行する、情報処理装置が提供される。対応する方法及びプログラムもまた提供される。

また別の観点によれば、通信部、ソフトウェアを記憶する記憶部、及び前記記憶部に記憶された前記ソフトウェアを実行する実行部、を備える情報処理装置であって、前記通信部は、他の装置に記憶されている対応するソフトウェアが正当ではないと前記他の装置において判定されたことを示す通知信号が前記他の装置から受信された場合に、前記記憶部に記憶されている前記ソフトウェアを前記他の装置へ送信する、情報処理装置が提供される。対応する方法及びプログラムもまた提供される。

本開示によれば、検証に失敗したソフトウェアの復旧を可能にするコスト効率のよい仕組みを実現することができる。

一実施形態に係る情報処理システムの構成の一例を示すブロック図。 一実施形態に係るＭＦＰの起動時の処理の流れの一例を示すフローチャート。 救援機リストの一例について説明するための説明図。 一実施形態に係るＭＦＰの救援時の処理の流れの一例を示すフローチャート。 一実施形態に係るＭＦＰの起動時の処理の流れの他の例を示すフローチャート。

以下、添付図面を参照して実施形態を詳しく説明する。なお、以下の実施形態は特許請求の範囲に係る発明を限定するものでない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一の又は同様の構成に同一の参照番号を付し、重複した説明は省略される。

＜＜１．システム構成例＞＞
＜１−１．全体的な構成＞
本節では、本開示に係る技術が複合機（Multi-Function Peripheral（ＭＦＰ））に適用される例を説明する。しかしながら、本開示に係る技術は、複合機に限定されず、いかなる種類の情報処理装置に適用されてもよい。本開示に係る技術は、プリンタ、スキャナ又はファクシミリといった画像処理装置に適用されてもよい。また、特に説明の無い限り、以下に説明する装置、デバイス、モジュール及びチップといった構成要素の各々は、単一のエンティティで構成されてもよく、又は物理的に異なる複数のエンティティから構成されてもよい。

図１は、一実施形態に係る情報処理システム１の構成の一例を示すブロック図である。図１を参照すると、情報処理システム１は、第１のＭＦＰ１０ａ、第２のＭＦＰ１０ｂ、第３のＭＦＰ１０ｃ、及びユーザ端末４０を含む。第１のＭＦＰ１０ａ、第２のＭＦＰ１０ｂ、第３のＭＦＰ１０ｃ、及びユーザ端末４０は、ネットワーク５０を介して相互に接続される。

３つのＭＦＰ１０ａ、１０ｂ及び１０ｃは、同種の又は互いに派生関係にある種類のＭＦＰである。図１では、第１のＭＦＰ１０ａ及び第２のＭＦＰ１０ｂについて、個々の装置の機能ブロックが示されており、第３のＭＦＰ１０ｃについて装置の外観が示されている。なお、これ以降の説明において、ＭＦＰ１０ａ、１０ｂ及び１０ｃをＭＦＰ１０と総称することがある。

ユーザ端末４０は、情報処理システム１を利用し又は管理するユーザ又はエンジニアにより使用される端末装置である。ユーザ端末４０は、例えばＰＣ（Personal Computer）又はスマートフォンといった、任意の種類の端末装置であってよい。ネットワーク５０は、例えばオフィス又は家庭といった任意の場所に設置され得るネットワークである。ネットワーク５０は、有線ネットワークであってもよく、又は無線ネットワークであってよい。

＜１−２．装置の構成＞
上述したように、第１のＭＦＰ１０ａ、第２のＭＦＰ１０ｂ及び第３のＭＦＰ１０ｃは、同種の又は互いに派生関係にある種類のＭＦＰである。そのため、ここでは１つのＭＦＰ１０に焦点を当てて、その構成の一例を説明する。他のＭＦＰもまた同様に構成されてよいが、本実施形態の要旨に関連しない部分において、ＭＦＰの構成は互いに相違してもよい。

図１を参照すると、ＭＦＰ１０は、コントローラ１１、スキャナデバイス１２、プリンタデバイス１３、操作デバイス１４、認証デバイス１５、節電ボタン１６、及び電力制御部１７を備える。コントローラ１１は、記憶デバイス３１、通信Ｉ／Ｆ３２及び制御ユニット３３を含む。

スキャナデバイス１２は、コントローラ１１からの指示に応じて、原稿を光学的に読取って読取画像の画像データを生成する。プリンタデバイス１３は、コントローラ１１から入力される印刷用の画像データに基づいて、画像を用紙へ印刷する。

操作デバイス１４は、対話的なユーザインタフェースをユーザに提供するデバイスである。例えば、操作デバイス１４は、タッチパネル２０及び操作キー２１を有し、ＭＦＰ１０に対する操作又は情報の入力を受け付ける。また、操作デバイス１４は、例えばタッチパネル２０の画面又はＬＣＤ（Liquid Crystal Display）のような別個のディスプレイの画面上に視覚的な情報を表示する。操作キー２１は、印刷部数などの数値の入力用の数字キー、コピーボタン、及び停止ボタンといった、物理的な入力手段を含み得る。認証デバイス１５は、ＭＦＰ１０を利用するユーザを認証するためのデバイスである。例えば、ＩＤ／パスワード認証又は生体認証といった手段で認証デバイス１５により成功裏に認証されたユーザのみが、ＭＦＰ１０を操作し又はＭＦＰ１０の機能を利用することを許可されてもよい。

節電ボタン１６は、物理的に操作デバイス１４の近傍又は同一ユニット上に配置され得る、複数の電力モードの間の切替えのためのボタン（又はスイッチ）である。節電ボタン１６は、後述する電力制御部１７によって操作デバイス１４の電源がオフとされている場合にも操作を検出できるように、他のデバイスから電気的に分離され、独立してコントローラ１１へ接続される。ユーザは、節電ボタン１６を押下することにより、通常モード、節電モード及びスタンバイモードといったモードの間でＭＦＰ１０の電力モードをトグルする（遷移させる）ことができる。電力制御部１７は、ＭＦＰ１０を構成する各デバイスへの電力の供給を制御するコントローラである。電力制御部１７は、電力モードに依存して、図示しないスイッチをオン／オフすることで、例えばコントローラ１１、スキャナデバイス１２、プリンタデバイス１３、操作デバイス１４及び認証デバイス１５に電源から適時に電力を供給させる。

記憶デバイス３１は、ＭＦＰ１０により生成され、通信され又は利用される多様なデータ及びプログラムを記憶するデバイスである。記憶デバイス３１は、例えば、ＨＤＤ（Hard Disk Drive）であってもよい。例えば、記憶デバイス３１は、スキャナデバイス１２により生成された読取画像の画像データを記憶する。また、記憶デバイス３１は、プリンタデバイス１３により印刷されるべき画像の印刷用データを記憶する。通信インタフェース（Ｉ／Ｆ）３２は、ＭＦＰ１０によるネットワーク５０を介する他の装置との間の通信のためのインタフェースである。即ち、ＭＦＰ１０は、通信Ｉ／Ｆ３２を介して他の装置と通信可能である。通信Ｉ／Ｆ３２は、例えば、ＬＡＮ（Local Area Network）Ｉ／Ｆであってもよい。例えば、通信Ｉ／Ｆ３２は、スキャナデバイス１２により生成された読取画像の画像データを指定された宛先へ送信する。また、通信Ｉ／Ｆ３２は、プリンタデバイス１３により印刷されるべき画像の印刷用データを受信する。さらに、通信Ｉ／Ｆ３２は、後述するソフトウェアの復旧時の装置間の通信のためにも使用される。

制御ユニット３３は、１つ以上の制御プログラムを実行することにより、ＭＦＰ１０の上述した機能の全般を制御するユニットである。図１に示したように、制御ユニット３３は、プロセッサ３４、ＳＰＩ（Serial Peripheral Interface）フラッシュ３５及びＲＡＭ（Random Access Memory）３６を含む。

プロセッサ３４は、例えばＣＰＵ（Central Processing Unit）又はＭＰＵ（Micro Processing Unit）であってよく、ＭＦＰ１０の機能を制御するための制御プログラムを実行する。例えば、プロセッサ３４は、ＭＦＰ１０の電源が投入されると、内部のＲＯＭ（Read Only Memory）に予め書き込まれているブートプログラムをＲＡＭ３６へロードして実行する。プロセッサ３４は、ブートプログラムに従って、ＳＰＩフラッシュ３５に記憶されているソフトウェアであるＢＩＯＳ（Basic Input/Output System）プログラムをＲＡＭ３６へロードする。ＳＰＩフラッシュ３５内のＢＩＯＳプログラムは、カーネルからはファイルとしてアクセス不能である。本実施形態において、プロセッサ３４は、ＢＩＯＳの一部であり又はＢＩＯＳから独立したプログラムコードを実行することにより、ＳＰＩフラッシュ３５からロードされる１つ以上のソフトウェアの正当性を検証する。プロセッサ３４は、検証の結果として正当であると判定されたソフトウェアを実行し、それによりＭＦＰ１０の各デバイスが安全に制御され、ＭＦＰ１０の正常な動作が保証される。

本実施形態において、正当性検証の対象のソフトウェアは、後続して実行されるべきプログラムをロードするためのローダ、及びオペレーティングシステムの中心的機能を担うカーネルなど、いかなる種類のソフトウェアであってもよい。ＳＰＩフラッシュ３５とは異なる記憶部（例えば、記憶デバイス３１又は他のメモリ）に記憶されるソフトウェアが正当性検証の対象に含められてもよい。

このように、本実施形態において、ＭＦＰ１０のプロセッサ３４及びＲＡＭ３６は、ＳＰＩフラッシュ３５に記憶されているソフトウェアの正当性を検証する検証部として機能する。プロセッサ３４及びＲＡＭ３６は、さらに、検証の結果として正当であると判定されたソフトウェアを実行する実行部としても機能する。

＜１−３．課題及び解決策の検討＞
ＭＦＰ１０への不正なアクセス又は不正なプログラムの実行に起因して、ＳＰＩフラッシュ３５に記憶されているソフトウェアが改竄されることがあり得る。また、装置の経年劣化によってソフトウェアのビットが書き換わることもあり得る。このように開発者の意図に反して変化した（改竄され又は劣化した）ソフトウェアが実行されると、ＭＦＰ１０の動作に不具合が生じる。上述したソフトウェアの正当性の検証は、こうしたＭＦＰ１０の動作の不具合を防止するための対策である。ソフトウェアの検証に失敗した場合に、正当でないソフトウェアを正当なソフトウェアに置き換えることで、ＭＦＰ１０の状態を復旧することができる。ここで、例えば外部の管理サーバに正当なソフトウェアを予め用意しておくことが考えられるが、そうした追加的なサーバの導入は、システムの構築及び運用のコストを増大させる。個々の装置の内部でソフトウェアのバックアップを保持しておくことも、装置の実装コストを増大させる点で、最適な解決策ではない。

そこで、本開示に係る技術では、ある装置においてソフトウェアの検証が失敗した場合に、当該装置が、同一のシステム内に存在する他の装置から、復旧のためのソフトウェアを受信するものとする。復旧のためのソフトウェアは、バックアップではなく、当該他の装置の通常の動作の際に実行されるソフトウェアである。それにより、別個の管理サーバを導入する必要性も、バックアップ用のソフトウェアのためにハードウェアリソースを増強する必要性も回避される。

具体的には、本実施形態において、情報処理システム１の各ＭＦＰ１０は、検証失敗時に他のＭＦＰ１０へソフトウェアの提供を要求する要求側装置になり得ると共に、他のＭＦＰ１０からの要求に応じてソフトウェアを提供する提供側装置にもなり得る。以下の説明では、前者のＭＦＰ１０を異常機、後者のＭＦＰ１０を救援機という。

概略的な説明のために、ここでは、第１のＭＦＰ１０ａが異常機、第２のＭＦＰ１０ｂが救援機であるものとする。第１のＭＦＰ１０ａは、第１のＭＦＰ１０ａにおける実行用の第１のソフトウェアが正当ではないと判定した場合、第２のＭＦＰ１０ｂから第２のＭＦＰ１０ｂにおける実行用の第２のソフトウェアを通信Ｉ／Ｆ３２を介して受信する。そして、第１のＭＦＰ１０ａは、受信した第２のソフトウェアをＳＰＩフラッシュ３５に記憶させて（例えば、第１のソフトウェアと置き換えて）、当該第２のソフトウェアをプロセッサ３４において実行する。一方、第２のＭＦＰ１０ｂは、第１のＭＦＰ１０ａにおける実行用の第１のソフトウェアが正当ではないと判定されたことを示す通知信号を第１のＭＦＰ１０ａから受信する。そして、第２のＭＦＰ１０ｂは、第２のＭＦＰ１０ｂにおける実行用の第２のソフトウェアを、第２のＭＦＰ１０ｂの通信Ｉ／Ｆ３２を介して第１のＭＦＰ１０ａへ送信する。

なお、各ＭＦＰ１０において、ソフトウェアの正当性の検証、ソフトウェアの実行、及び検証失敗時の正当なソフトウェアの送信及び受信は、単一のプロセッサ（例えば、プロセッサ３４）によって行われてもよい。また、これら処理は、互いに連携する複数のプロセッサによって行われてもよい。例えば、各ＭＦＰ１０は、プロセッサ３４とは別個の、ソフトウェアの正当性の検証のための専用のプロセッサを有していてもよい。なお、本明細書におけるソフトウェアとの用語は、コンピュータプログラム、コンピュータ命令、ファームウェア、プロシージャ、及びコードシーケンスなどを広く包含するものとする。ここで説明した解決策のいくつかのより詳細な実施例について、以下でさらに説明する。

＜＜２．第１実施例＞＞
＜２−１．起動時の処理の流れ＞
情報処理システム１の第１のＭＦＰ１０ａ、第２のＭＦＰ１０ｂ及び第３のＭＦＰ１０ｃの各々は、起動時に１つ以上のソフトウェアの正当性を検証する。その検証の結果、どのＭＦＰ１０も異常機となる可能性がある。ここでは、そうした異常機としての処理を含む、第１実施例に係るＭＦＰ１０の起動時の処理の流れについて、図２のフローチャートを用いて説明する。

図２に示した処理は、例えばＭＦＰ１０のプロセッサ３４により実行される。この処理に先立って、ＭＦＰ１０の記憶デバイス３１には、復旧用のソフトウェアを提供可能な１つ以上の装置のリスト（以下、救援機リストという）が登録されているものとする。この救援機リストについて、後にさらに説明する。なお、以下の説明では、処理ステップをＳ（ステップ）と略記する。

まず、Ｓ２００で、ＭＦＰ１０のプロセッサ３４は、ユーザによるＭＦＰ１０の電源の投入に応じて、ブートプログラムを実行し、それによりＢＩＯＳプログラムをＳＰＩフラッシュ３５からＲＡＭ３６へロードする。

次いで、Ｓ２０２で、プロセッサ３４は、ロードしたＢＩＯＳプログラムを実行することにより、ＢＩＯＳを起動する。ここでは、ＢＩＯＳは、正当性検証用のプログラムコードを含むものとする。Ｓ２０４で、プロセッサ３４は、ＢＩＯＳの動作の一部として、ＭＦＰ１０の１つ以上のソフトウェア（例えば、ローダ及びカーネル）の正当性を検証する。

ソフトウェアの正当性の検証は、例えば、デジタル署名技術に基づいて実現され得る。具体的には、まず、正当性検証の対象のソフトウェアがＭＦＰ１０へ組み込まれる前に、ソフトウェアのプログラムデータからソフトウェアのダイジェスト値（ハッシュ値）が導出される。さらに、そのダイジェスト値を公開鍵暗号の鍵ペアのうちの秘密鍵で暗号化することにより、ソフトウェアのデジタル署名が生成される。生成されたデジタル署名は、鍵ペアのうちの公開鍵と共に、例えばプロセッサ３４によりアクセス可能な不揮発性のメモリに記憶される。正当性の検証の際に、プロセッサ３４は、検証の対象のソフトウェアのダイジェスト値を導出し、及びメモリに記憶しておいたデジタル署名を公開鍵で復号する。そして、導出したソフトウェアのダイジェスト値がデジタル署名の復号により得られた正しいダイジェスト値に一致する場合には、ソフトウェアは正当であると判定される。一方、ダイジェスト値が一致しない場合には、ソフトウェアは（改竄又は劣化といった）何らかの原因で変化しているために正当でないと判定される。

図２の処理は、こうした正当性検証の結果に依存して、Ｓ２０６で分岐する。ソフトウェアは正当であるとプロセッサ３４が判定した場合、処理はＳ２０８へ進む。一方、ソフトウェアは正当でないとプロセッサ３４が判定した場合、処理はＳ２１２へ進む。

Ｓ２０６で、プロセッサ３４は、正当であると判定したソフトウェアを実行する。例えば、プロセッサ３４は、プログラムローダを実行することにより、後続して実行されるべきプログラムをＲＡＭ３６へロードする。次いで、プロセッサ３４は、カーネルを実行することにより、ＭＦＰ１０のオペレーティングシステムを起動する。その結果、Ｓ２１０で、ＭＦＰ１０の起動が全体として成功し、ＭＦＰ１０はユーザによる操作を待受ける状態に入る。

一方、Ｓ２１２では、プロセッサ３４は、ソフトウェアが正当ではないと判定したため、復旧用のソフトウェアを提供可能な装置のリスト、即ち上述した救援機リストから、救援機を選択する。

図３は、一例としての救援機リスト３００の構成を示している。図３を参照すると、救援機リスト３００は、ホスト３０１、ＩＰアドレス３０２及びステータス３０３という３つのデータ項目を有する。ホスト３０１は、救援機の候補として登録された装置の各々を識別する名称を表す。ＩＰアドレス３０２は、各装置に割り当てられたＩＰアドレスを表す。各装置のＩＰアドレス３０２の値は、例えば、エンジニアにより予め静的に割り当てられてもよく、又はシステムにより動的に割り当てられてもよい。ステータス３０３は、各装置の現在の動作ステータス（例えば、稼働中であるか否か）を表す。

図３の例では、救援機リスト３００に、それぞれ「ＭＦＰ−Ｂ」、「ＭＦＰ−Ｃ」及び「ＭＦＰ−Ｄ」というホスト名を有する３つの装置が登録されている。これら装置には固有のＩＰアドレスが割り当てられている。ホスト「ＭＦＰ−Ｂ」及び「ＭＦＰ−Ｃ」のステータスは「ＯＮ」（即ち、稼働中）であり、ホスト「ＭＦＰ−Ｄ」のステータスは「ＯＦＦ」である。なお、救援機リスト３００において、図示した項目のいくつかが省略されてもよく、又は他の項目が追加されてもよい。例えば、救援機リスト３００は、救援機の候補のＩＰアドレスのみを列挙した単なる配列であってもよい。

救援機リスト３００は、例えば、情報処理システム１のエンジニアにより、ＭＦＰ１０の操作デバイス１４又はユーザ端末４０を用いて予め作成され、各ＭＦＰ１０の記憶デバイス３１に記憶され得る。プロセッサ３４は、救援機リスト３００に登録されている装置の動作の開始及び終了といったステータスの変更を、ＳＮＭＰ（Simple Network Management Protocol）のような管理プロトコルを用いて監視してもよい。そして、プロセッサ３４は、その監視を通じて検知されるステータスの変更に基づいて、救援機リスト３００を更新してもよい。また、情報処理システム１のエンジニアが、各ＭＦＰ１０の救援機リスト３００を（作成時と同様の手段で）更新してもよい。

例えば、第１のＭＦＰ１０ａの救援機リスト３００に登録される装置は、第１のＭＦＰ１０ａからネットワークを介して到達可能な装置であって、第１のＭＦＰ１０ａと同一のソフトウェア（例えば、ローダ及びカーネル）を有している装置である。例えば、第１のＭＦＰ１０ａと同じ種類の又は派生関係にある種類のＭＦＰは、第１のＭＦＰ１０ａにとっての救援機の候補であり得る。

次いで、Ｓ２１４で、プロセッサ３４は、救援機リスト３００から選択した他のＭＦＰ１０へ、自装置での実行用のソフトウェアの検証に失敗したことを示す通知信号を送信する。この通知信号は、例えばＳＮＭＰトラップ信号であってもよい。例えば、ソフトウェア検証失敗に関連付けられる固有のトラップ番号を用いた拡張トラップ信号として、通知信号を実装することができる。通知信号は、正当ではないと判定されたソフトウェアを識別するソフトウェア識別情報を含んでもよい。ソフトウェア識別情報は、例えば、ビットのオン／オフによってソフトウェアごとの検証の成功／失敗を示すビット列、又は検証に失敗したソフトウェアの識別子若しくはファイル名などであってよい。また、通知信号は、異常機の機種を示す機種情報を含んでもよい。

次いで、Ｓ２２０で、プロセッサ３４は、通知信号の送信先の救援機からの応答信号の受信を待受ける。例えば、一定の時間内に救援機から応答信号が受信された場合には、処理はＳ２３０へ進む。一方、救援機から応答信号が受信されない場合には、処理はＳ２２２へ進む。

救援機から応答信号が受信されない場合、Ｓ２２２で、プロセッサ３４は、救援機リスト３００内に救援機の候補である他の装置が残っているか否かを判定する。救援機の候補が残っている場合には、処理はＳ２１２へ戻り、プロセッサ３４は、救援機リスト３００内の次の候補を選択して、選択した候補へ上述した通知信号を送信する。救援機の候補が残っていない場合には、ソフトウェアは復旧されず、Ｓ２２４でＭＦＰ１０の起動は失敗に終わる。

通知信号に対する応答として救援機から受信される応答信号には、救援機における実行用のソフトウェアのコピーにアクセス可能なアドレスが記述される。このアドレスは、例えばＵＲＬ（Uniform Resource Locator）形式であり得る。Ｓ２３０で、プロセッサ３４は、受信した応答信号において指定されるアドレスへアクセスすることにより、救援機からソフトウェアを通信Ｉ／Ｆ３２を介して受信する。ここでの救援機へのアクセスは、例えば、応答信号において指定されたアドレスを含むＨＴＴＰ（Hypertext Transfer Protocol）要求を用いて行われてよい。プロセッサ３４は、復旧を要するソフトウェアの数だけＨＴＴＰ要求を繰り返してもよい。

次いで、Ｓ２３２で、プロセッサ３４は、Ｓ２０４での検証において正当ではないと判定したソフトウェアを、Ｓ２３０で救援機から受信したソフトウェアに置換する。そして、Ｓ２３４で、プロセッサ３４はＭＦＰ１０を再起動し、再起動後にソフトウェアは正当であると判定され、Ｓ２１０でＭＦＰ１０が全体として成功裏に起動する。

なお、図２では、異常機が救援機リスト内の候補への通知信号の送信と応答信号の待受けとを順次繰り返す例を説明したが、本実施例はかかる例には限定されない。例えば、異常機は、救援機リスト内の候補の全てに並列的に通知信号を送信してもよい。そのケースにおいて、複数の救援機から応答信号が受信された場合、異常機は、例えば応答信号の受信タイミングが最も早かった救援機など、任意の基準で実際にアクセスする救援機を選択してもよい。

このように、本実施形態では、正当なソフトウェアを提供可能な特別な管理サーバが用意されなくても、ソフトウェアの検証に失敗した情報処理装置が、システム内の他の装置からソフトウェアを受信して復旧を行うことができる。バックアップ用のソフトウェアもまた不要である。

＜２−２．救援時の処理の流れ＞
情報処理システム１のＭＦＰ１０の各々は、成功裏に起動した後、スキャン及び印刷といった目的に供されつつ、他の装置のための救援機としての役割も担う。ここでは、そうした救援機としての処理の流れについて、図４のフローチャートを用いて説明する。図４に示した処理は、例えばＭＦＰ１０のプロセッサ３４により実行される。

まず、ＭＦＰ１０のプロセッサ３４は、Ｓ４００で、ＭＦＰ１０の電源の投入に応じてＢＩＯＳプログラムをＲＡＭ３６へロードし、Ｓ４０２でＢＩＯＳを起動する。その後、図２を用いて説明した起動時の処理を経て、Ｓ４０４でＭＦＰ１０の起動が全体として成功したものとする。これ以降の処理は、例えばカーネルのプログラムコードをプロセッサ３４が実行することにより実現され得る。

ＭＦＰ１０のプロセッサ３４は、ＭＦＰ１０が稼働している間、Ｓ４１０で、他のＭＦＰ１０からの通知信号の受信を待受ける。ソフトウェアの検証に失敗したことを示す通知信号が通信Ｉ／Ｆ３２を介して受信されると、処理はＳ４２０へ進む。通知信号は、上述したように、例えばＳＮＭＰトラップ信号であってよい。

Ｓ４２０で、プロセッサ３４は、ＭＦＰ１０（救援機）における実行用のソフトウェア（自装置の起動時に正当性を検証したソフトウェア）が通知信号の送信元の装置（即ち、異常機）における実行に適しているかを判定する。プロセッサ３４は、例えば、通知信号に含まれるソフトウェア識別情報により識別されるソフトウェアと同じソフトウェアを自ら実行している場合に、その実行中のソフトウェアが異常機にも適合すると判定してもよい。また、プロセッサ３４は、通知信号に含まれる機種情報により示される機種が、自装置の機種と同一であり又は派生関係にある場合に、自ら実行中のソフトウェアが異常機にも適合すると判定してもよい。ソフトウェアの適合性が肯定される場合、処理はＳ４３０へ進む。そうではない場合、処理はＳ４１０へ戻る。

Ｓ４３０で、プロセッサ３４は、救援機における実行用のソフトウェアを、異常機によりアクセス可能な記憶領域（例えば、記憶デバイス３１の所定の記憶領域）へコピーする。一例として、救援機は、ＨＴＴＰサーバとして動作することにより、異常機からのアクセスを受け付けてもよい。この場合、プロセッサ３４は、Ｓ４３０で、ＨＴＴＰサーバを起動し、ＨＴＴＰサーバの公開ディレクトリにソフトウェアをコピーし得る。ソフトウェアのコピー先のパスは、第三者による推測又は悪用を防ぐために、一時的に（例えば、ランダムに）生成されるパスであってもよい。

次いで、Ｓ４３２で、プロセッサ３４は、受信した通知信号に対する応答として、ソフトウェアへのアクセス用の上記記憶領域のアドレスを指定する応答信号を、通信Ｉ／Ｆ３２を介して異常機へ送信する。この応答信号もまた、ＳＮＭＰトラップ信号（例えば、固有のトラップ番号を用いた拡張トラップ信号）であってよい。

その後、プロセッサ３４は、Ｓ４４０で、応答信号において指定したアドレスへの異常機からのアクセスを待受ける。ここでの異常機からのアクセスをソフトウェア要求という。ソフトウェア要求は、例えば、ＵＲＬ形式のアドレスを含むＨＴＴＰ要求であってよい。ソフトウェア要求が受信されると、処理はＳ４４２へ進む。

プロセッサ３４は、ソフトウェア要求の受信に応じて、Ｓ４４２で、異常機での実行に適した正当なソフトウェアを、通信Ｉ／Ｆ３２を介して異常機へ送信する。次いで、Ｓ４４４で、プロセッサ３４は、ソフトウェア要求の待受けを終了（例えば、ＨＴＴＰサーバを停止）する。また、ソフトウェア要求の待受けは、応答信号の送信から一定の期間の経過後に終了してもよい。

なお、救援機と異常機との間の接続は、ＳＳＬ（Secure Sockets Layer）によって暗号化されてもよい（即ち、ＨＴＴＰＳが利用されてもよい）。また、ＨＴＴＰの代わりに、ＦＴＰ（File Transfer Protocol）又はＳＣＰ（Secure Copy Protocol）といった転送プロトコルが、救援機から異常機へのソフトウェアの送信のために利用されてもよい。

このように、本実施形態では、正当なソフトウェアを提供可能な特別な管理サーバが用意されなくても、システム内の複数の情報処理装置のうちの１つが救援機となって、異常機のソフトウェアの復旧を支援することができる。

＜＜３．第２実施例＞＞
第１実施例では、ソフトウェアの検証に失敗した異常機が救援機リストに含まれる救援機の候補に通知信号を個別に（例えば、ユニキャストで）送信する手法を説明した。しかしながら、通知信号を送信する手法は、かかる例には限定されない。本節で説明する第２実施例では、通知信号は、システム内にブロードキャストされるものとする。

図５は、第２実施例に係るＭＦＰの起動時の処理の流れの一例を示している。図５に示した処理は、例えばＭＦＰ１０のプロセッサ３４により実行される。本実施例では、救援機リストは利用されない。

図５のＳ２００〜Ｓ２１０は、図２に関連して説明した同じ符号の処理ステップと同様であるため、ここではそれらの説明を省略する。

ＭＦＰ１０のプロセッサ３４は、正当性検証の結果としてソフトウェアが正当ではないと判定した場合、Ｓ５１２で、情報処理システム１内に通知信号をブロードキャストする。例えば、プロセッサ３４は、自装置が属するネットワークのブロードキャストアドレスを宛先として有するＳＮＭＰトラップ信号を、通信Ｉ／Ｆ３２を介してネットワーク５０へ送信する。通知信号は、上述したように、送信元の装置がソフトウェアの検証に失敗したことを示す信号である。第１実施例と同様に、通知信号は、ソフトウェア識別情報及び機種情報の一方又は双方を含んでもよい。

次いで、Ｓ５２０で、プロセッサ３４は、ブロードキャストした通知信号を受信した装置からの応答信号の受信を待受ける。例えば、一定の時間内に応答信号が受信された場合には、処理はＳ２３０へ進む。一方、応答信号が受信されない場合には、処理はＳ２２４へ進む。

図５のＳ２２４〜Ｓ２３４は、図２に関連して説明した同じ符号の処理ステップと同様であるため、ここではそれらの説明を省略する。

本実施例において、各ＭＦＰ１０の救援機としての処理は、図４を用いて説明した処理と同様であってよい。但し、Ｓ４１０においてＭＦＰ１０が待受ける通知信号は、救援機のＩＰアドレスの代わりに、ブロードキャストアドレスを宛先として有する信号であり得る。

本実施例においても、Ｓ５２０で複数の救援機から応答信号が受信された場合、異常機は、例えば応答信号の受信タイミングが最も早かった救援機など、任意の基準で実際にアクセスする救援機を選択してよい。

第１実施例と比較すると、第２実施例では、救援機リストを予め作成して救援機の情報をリストに登録しておく必要性が解消される。したがって、情報処理システム１の運用コストをより低減することができる。

＜＜４．まとめ＞＞
ここまで、図１〜図５を用いて、本開示に係る技術の実施形態を詳細に説明した。上述した実施形態は、主として、通信部、ソフトウェアを記憶する記憶部、上記ソフトウェアの正当性を検証する検証部、及び上記ソフトウェアを実行する実行部、を各々が備える複数の情報処理装置を含む情報処理システムを対象とする。但し、いくつかの情報処理装置は、検証部を備えなくてもよい。第１の情報処理装置は、自装置における実行用の第１のソフトウェアが正当ではないと判定した場合に、第２の情報処理装置から第２のソフトウェアを通信部を介して受信する。第２のソフトウェアは、第１のソフトウェアに対応する、第２の情報処理装置における実行用のソフトウェアである。第２のソフトウェアは、第１の情報処理装置における実行にも適する。第１の情報処理装置は、第２の情報処理装置から受信した第２のソフトウェアを、実行部による実行のために記憶部に記憶させる。かかる構成によれば、システムに追加的なサーバを導入することも、バックアップのためにハードウェアリソースを消費することも必要とすることなく、ソフトウェアの検証に失敗した装置がソフトウェアを復旧することが可能である。

また、上述した実施形態では、上記情報処理システムの第２の情報処理装置は、第１の情報処理装置における実行用の第１のソフトウェアが正当ではないと判定されたことを示す通知信号を上記第１の情報処理装置から受信する。この場合に、上記第２の情報処理装置は、上記第２の情報処理装置における実行用の第２のソフトウェアを上記通信部を介して上記第１の情報処理装置へ送信する。かかる構成によれば、システムに追加的なサーバを導入することも、バックアップのためにハードウェアリソースを消費することも必要とすることなく、ソフトウェアの検証に失敗した装置によるソフトウェアの復旧を支援することが可能である。

また、ある実施例では、上記第１のソフトウェアが正当ではないと判定された場合に、ソフトウェアを提供可能な１つ以上の装置のリストから選択される上記第２の情報処理装置へ通知信号が送信され得る。そして、上記第２のソフトウェアは、上記通知信号を受信した上記第２の情報処理装置から受信され得る。かかる構成によれば、特定の装置のみへ上記通知信号が送信されるため、ネットワークの帯域が浪費されず、未知の装置に異常の発生が知られる可能性も抑制される。

また、ある実施例では、上記第１のソフトウェアが正当ではないと判定された場合に、上記情報処理システム内に通知信号がブロードキャストされ得る。そして、上記第２のソフトウェアは、ブロードキャストされた上記通知信号を受信した上記第２の情報処理装置から受信され得る。かかる構成によれば、ソフトウェアを提供可能な装置のリストを作成し及び維持することなく、ソフトウェアの復旧の仕組みを低コストで運用することが可能である。

また、上述した実施形態では、上記通知信号に対する応答信号において指定されるアドレスへ上記第１の情報処理装置がアクセスすることにより、上記第２の情報処理装置から上記第２のソフトウェアが受信され得る。かかる構成によれば、第三者にとってはどこにアクセスすればソフトウェアを入手できるかが不明となるため、ソフトウェアに関連する攻撃を受けるリスクを一層低減することができる。上記アドレスは、例えば、上記第１の情報処理装置によりアクセス可能な記憶領域であって、上記第２のソフトウェアがコピーされた当該記憶領域のアドレスであり得る。かかる構成によれば、上記記憶領域でのソフトウェアの提供を一時的な期間に制限して、ソフトウェアの秘匿性を高めることができる。

また、上述した実施形態では、上記応答信号において指定される上記アドレスへのアクセスは、ＨＴＴＰ要求を用いて行われ得る。また、上記通知信号は、ＳＮＭＰトラップ信号であり得る。かかる構成によれば、データ交換のために広く活用されているＨＴＴＰ、及びネットワーク監視のためのＳＮＭＰといった汎用的なプロトコルを活用して、上述したソフトウェア復旧の仕組みを容易に構築することができる。

また、上述した実施形態では、上記通知信号は、正当ではないと判定されたソフトウェアを識別する情報を含み得る。かかる構成によれば、復旧のために必要十分な、上記第１の情報処理装置における実行に適したソフトウェアのみを、上記第２の情報処理装置から上記第１の情報処理装置へ提供することができる。それにより、システム内の最小限の通信でソフトウェアの復旧の確実性を確保することができる。

＜＜５．その他の実施形態＞＞
上記実施形態は、１つ以上の機能を実現するプログラムをネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読み出して実行する処理の形式でも実現可能である。また、１つ以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

本発明は上述した実施形態に制限されるものではなく、発明の精神及び範囲から逸脱することなく、様々な変更及び変形が可能である。したがって、発明の範囲を公にするために請求項を添付する。

１：情報処理システム、１０ａ〜１０ｃ：情報処理装置、３１：ＳＰＩフラッシュ（記憶部）、３２：通信Ｉ／Ｆ（通信部）、３４：プロセッサ（検証部、実行部）

Claims (15)

1. 通信部、ソフトウェアを記憶する記憶部、前記ソフトウェアの正当性を検証する検証部、及び前記検証部により正当であると判定された前記ソフトウェアを実行する実行部、を備える情報処理装置であって、
   前記通信部は、前記ソフトウェアに対応するソフトウェアを記憶する記憶部及び当該ソフトウェアを実行する実行部を備える他の装置と通信可能であり、
   前記情報処理装置の前記記憶部に記憶されている前記ソフトウェアが正当ではないと前記検証部により判定された場合に、
   前記通信部は、前記他の装置から、前記対応するソフトウェアを受信し、
   前記情報処理装置の前記記憶部は、前記通信部により受信された前記対応するソフトウェアを記憶し、
   前記情報処理装置の前記実行部は、前記記憶部に記憶された前記対応するソフトウェアを実行する、
   情報処理装置。
2. 請求項１に記載の情報処理装置であって、
   前記通信部は、前記情報処理装置の前記記憶部に記憶されている前記ソフトウェアが正当ではないと前記検証部により判定された場合に、ソフトウェアを提供可能な１つ以上の装置のリスト内の前記他の装置へ通知信号を送信し、前記通知信号を受信した前記他の装置から前記対応するソフトウェアを受信する、
   情報処理装置。
3. 請求項１に記載の情報処理装置であって、
   前記通信部は、前記情報処理装置の前記記憶部に記憶されている前記ソフトウェアが正当ではないと前記検証部により判定された場合に、前記情報処理装置が属するシステム内に通知信号をブロードキャストし、ブロードキャストされた前記通知信号を受信した前記他の装置から前記対応するソフトウェアを受信する、
   情報処理装置。
4. 請求項２又は３に記載の情報処理装置であって、前記通信部は、前記通知信号に対する応答信号において指定されるアドレスへアクセスすることにより、前記他の装置から前記対応するソフトウェアを受信する、情報処理装置。
5. 請求項４に記載の情報処理装置であって、前記通信部は、前記応答信号において指定される前記アドレスへ、ＨＴＴＰ（Hypertext Transfer Protocol）要求を用いてアクセスする、情報処理装置。
6. 請求項２乃至５のいずれか１項に記載の情報処理装置であって、前記通知信号は、ＳＮＭＰ（Simple Network Management Protocol）トラップ信号である、情報処理装置。
7. 請求項２乃至６のいずれか１項に記載の情報処理装置であって、前記通知信号は、正当ではないと判定されたソフトウェアを識別する情報を含む、情報処理装置。
8. 通信部、ソフトウェアを記憶する記憶部、前記ソフトウェアの正当性を検証する検証部、及び前記検証部により正当であると判定された前記ソフトウェアを実行する実行部、を備える情報処理装置において行われる方法であって、
   前記通信部は、前記ソフトウェアに対応するソフトウェアを記憶する記憶部及び当該ソフトウェアを実行する実行部を備える他の装置と通信可能であり、
   前記方法は、
   前記情報処理装置の前記記憶部に記憶されている前記ソフトウェアの正当性を前記検証部で検証することと、
   前記検証部により前記ソフトウェアが正当ではないと判定された場合に、
   前記他の装置から、前記対応するソフトウェアを前記通信部を介して受信することと、
   受信された前記対応するソフトウェアを前記情報処理装置の前記記憶部に記憶させることと、
   前記情報処理装置の前記実行部に、前記記憶部に記憶された前記対応するソフトウェアを実行させることと、
   を含む方法。
9. 情報処理装置のプロセッサに、請求項８に記載の方法を行わせるためのコンピュータプログラム。
10. 通信部、ソフトウェアを記憶する記憶部、及び前記記憶部に記憶された前記ソフトウェアを実行する実行部、を備える情報処理装置であって、
    前記通信部は、他の装置に記憶されている対応するソフトウェアが正当ではないと前記他の装置において判定されたことを示す通知信号が前記他の装置から受信された場合に、前記記憶部に記憶されている前記ソフトウェアを前記他の装置へ送信する、
    情報処理装置。
11. 請求項１０に記載の情報処理装置であって、前記通信部は、前記通知信号が受信された場合において、前記記憶部に記憶されている前記ソフトウェアが前記他の装置における実行に適していると判定されるときに、当該ソフトウェアを前記通信部を介して前記他の装置へ送信する、情報処理装置。
12. 請求項１０又は１１に記載の情報処理装置であって、前記通信部は、前記ソフトウェアがコピーされた記憶領域であって前記他の装置によりアクセス可能な前記記憶領域のアドレスを指定する、前記通知信号に対する応答信号を、前記通信部を介して前記他の装置へ送信する、情報処理装置。
13. 請求項１２に記載の情報処理装置であって、前記通信部は、前記応答信号において指定した前記アドレスへの前記他の装置からのＨＴＴＰ（Hypertext Transfer Protocol）要求に応じて、前記ソフトウェアを前記他の装置へ送信する、情報処理装置。
14. 通信部、ソフトウェアを記憶する記憶部、及び前記記憶部に記憶された前記ソフトウェアを実行する実行部、を備える情報処理装置において行われる方法であって、
    他の装置に記憶されている対応するソフトウェアが正当ではないと前記他の装置において判定されたことを示す通知信号が前記他の装置から受信された場合に、前記記憶部に記憶されている前記ソフトウェアを前記通信部から前記他の装置へ送信すること、
    を含む方法。
15. 情報処理装置のプロセッサに、請求項１４に記載の方法を行わせるためのコンピュータプログラム。

Images