(57)【特許請求の範囲】
【請求項１】
複数のソフトウェアが複数の組み合わせで動作している保守対象のネットワーク装置において発生したソフトウェア障害に関わる障害情報を受信する障害情報受信部と、
前記障害情報を記録する障害情報データベースと、
前記障害情報に基づき障害発生ネットワーク機器の障害対処方法を決定する障害対処方法決定部と、
前記障害対処方法決定部が障害対処方法を決定する際に参照する障害情報設定テーブルと、
前記決定した障害対処方法を前記障害発生ネットワーク機器に送信する障害対処方法送信部と、を備え、
前記障害対処方法決定部が、情報端末別に見た特定ソフトウェアの障害発生回数の最大値と最小値の商が設定閾値を超えたか否かで、決定する障害対処方法を変更することを特徴とするネットワーク機器。
【請求項２】
複数のソフトウェアが複数の組み合わせで動作している保守対象のネットワーク装置において発生したソフトウェア障害に関わる障害情報を受信する障害情報受信部と、
前記障害情報を記録する障害情報データベースと、
前記障害情報に基づき障害発生ネットワーク機器の障害対処方法を決定する障害対処方法決定部と、
前記障害対処方法決定部が障害対処方法を決定する際に参照する障害情報設定テーブルと、
前記決定した障害対処方法を前記障害発生ネットワーク機器に送信する障害対処方法送信部と、を備え、
前記障害対処方法決定部が、障害発生ソフトウェアがフレームワークで動いているか否かで、決定する障害対処方法を変更することを特徴とするネットワーク機器。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、保守サービスを提供するためのネットワーク機器、および当該機器に通信ネットワークを介して接続される、保守サービスを受けるネットワーク装置に関し、特に特定のシステム保守方式および障害復旧方法に係る保守サービスを提供するネットワーク機器および当該保守サービスを受けるネットワーク装置に関する。
【背景技術】
【０００２】
従来、障害を監視・検知する技術として、ホームネットワークといったＬＡＮ内に置かれた情報処理装置で発生した障害を監視・検知し、インターネット等の通信ネットワークで繋がれた先に存在するリモート保守サーバに通知するシステムの保守を行うものがあった（例えば、特許文献１参照）。【０００３】
また、従来、障害を監視・検知する技術として、情報処理装置で発生した障害を選別してリモート保守サーバに送信するものがあった（例えば、特許文献２参照）。【０００４】
さらに、従来、障害を復旧する技術として、保守サービスを提供するネットワーク機器に通信ネットワークを介して同一構成である複数のネットワーク機器が接続され、保守を受けている状況下で、保守を受けるネットワーク機器でソフトウェア障害が発生した時に障害復旧を実施するものがあった（例えば、特許文献３参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平９−２１８８３５号公報
【特許文献２】特開２００９−１３４３９５号公報
【特許文献３】特開２００７−２６７３５２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
障害の保守には、監視・検知・対処（復旧）という３つのフェーズがあり、これを実行するために様々な技術の提案がなされている。【０００７】
まず、障害の監視・検知についての従来技術について述べる。ホームネットワークといったＬＡＮ内に置かれた情報処理装置で発生した障害を監視・検知し、インターネット等の通信ネットワークで繋がれた先に存在するリモート保守サーバに通知するといった、システムの保守を行う方式は、従来、例えば特許文献１で提案されている。しかし、該特許では、監視対象である情報処理装置で発生した障害に関わる情報をそのままの状態で保守サーバに送信する為、外部通信ネットワークの負荷や保守サーバにおける処理負荷の増大を招くという問題があった。この問題を解決したのが、特許文献２の提案方式である。この方式では、情報処理装置で発生した障害を選別してリモート保守サーバに送信する事で、上記問題を緩和出来た。【０００８】
次に、障害の対処（復旧）についての従来技術について述べる。障害の対処方法に関して、例えば特許文献３がある。この文献は、保守サービスを提供するネットワーク機器に通信ネットワークを介して同一構成である複数のネットワーク機器が接続され、保守を受けている状況下で、保守を受けるネットワーク機器でソフトウェア障害が発生した時に実施される障害復旧方法に関するものである。この文献によると、障害復旧のシナリオを纏めたテーブルを、保守サービスを提供するネットワーク機器に用意しておき、保守を受けるネットワーク機器で発生したソフトウェア障害を多く復旧する事が出来たシナリオの優先度が高くなるよう、動的に、テーブルに記述されているシナリオ毎の優先度を更新していく。そして、保守を受けるネットワーク機器で改めてソフトウェア障害が発生した際には、優先度の高いシナリオから順番に障害対処シナリオを適用していき、該障害から復旧させる、というものである。【０００９】
しかしながら、特許文献３の障害復旧方法では、多様なソフトウェアが多様な組み合わせで動作しているような保守を受けるネットワーク機器で発生したソフトウェア障害に対しては、その適用が困難であり、たとえ適用しても、該障害から復旧させるコストが高くなってしまうという問題があった。
【課題を解決するための手段】
【００１０】
本発明の代表的なものの一例を示せば以下の通りである。【００１１】
すなわち、本発明のネットワーク機器は、複数のソフトウェアが複数の組み合わせで動作している保守対象のネットワーク装置において発生したソフトウェア障害に関わる障害情報を受信する障害情報受信部と、前記障害情報を記録する障害情報データベースと、前記障害情報に基づき前記障害発生ネットワーク機器の障害対処方法を決定する障害対処方法決定部と、前記障害対処方法決定部が障害対処方法を決定する際に参照する障害情報設定テーブルと、前記決定した障害対処方法を前記障害発生ネットワーク機器に送信する障害対処方法送信部とを備えることを特徴とする。【００１２】
また、本発明のネットワーク装置は、発生したソフトウェア障害の障害情報を収集する障害情報収集部と、前記障害情報を記録する障害情報データベースと、前記障害情報に基づき障害対処方法を決定する障害情報処理決定部と、前記障害情報処理決定部が障害対処方法を決定する際に参照する障害情報設定テーブルとを備える複数のソフトウェアが複数の組み合わせで動作することを特徴とする。
【発明の効果】
【００１３】
本発明によれば、保守サービスを提供するためのネットワーク機器に少なくとも二台以上の複数の保守サービスを受けるネットワーク装置が通信ネットワークを介して接続され、そのそれぞれの保守サービスを受けるネットワーク装置において多様なソフトウェアが多様な組み合わせで動作している際に、ネットワーク機器でソフトウェア障害が発生した時、該障害発生ソフトウェアを該障害から低コストで復旧させる事が出来る。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施例１〜３の概念図である。
【図２】本発明の一実施例のシステム構成図である。
【図３】ホームゲートウェイが、リモート保守サーバ装置に対して障害情報を送信する際のフローチャートの一例図である。
【図４】リモート保守サーバが、ホームゲートウェイに対して障害対処方法を送信する際のフローチャートの一例図である。
【図５】リモート保守サーバに備わる障害情報データベースの一例図である。
【図６】リモート保守サーバに備わる障害対処情報設定テーブルの一例図である。
【図７】ホームゲートウェイに備わる障害情報収集ボタンを押下した際の、ホームゲートウェイが、リモート保守サーバ装置に対して障害情報を送信する際のフローチャートの一例図である。
【図８】ホームゲートウェイに備わるソフトウェア実行環境にフレームワークが存在していない時の、リモート保守サーバが、ホームゲートウェイに対して障害対処方法を送信する際のフローチャートの一例図である。
【図９】本発明の実施例４〜６の概念図である。
【図１０】本発明の一実施例のシステム構成図である。
【図１１】ホームゲートウェイが、自ら障害から復旧する際の、またはリモート保守サーバ装置に対して障害情報を送信する際のフローチャートの一例図である。
【図１２】リモート保守サーバが、ホームゲートウェイに対して障害対処方法を送信する際のフローチャートの一例図である。
【図１３】リモート保守サーバに備わる障害情報データベースの一例図である。
【図１４】リモート保守サーバに備わる障害対処情報設定テーブルの一例図である。
【図１５】ホームゲートウェイに備わる障害情報データベースの一例図である。
【図１６】ホームゲートウェイに備わる障害対処情報設定テーブルの一例図である。
【図１７】ホームゲートウェイに備わる障害情報収集ボタンを押下した際の、ホームゲートウェイが、自ら障害から復旧する際の、またはリモート保守サーバ装置に対して障害情報を送信する際のフローチャートの一例図である。
【図１８】ホームゲートウェイに備わるソフトウェア実行環境にフレームワークが存在していない時の、リモート保守サーバが、ホームゲートウェイに対して障害対処方法を送信する際のフローチャートの一例図である。
【発明を実施するための形態】
【００１５】
上記課題を解決する為に、本発明は以下の手段を有するものである。すなわち、本発明に係る保守サービスを提供するためのネットワーク機器において、通信ネットワークを介して接続される、多様な複数のソフトウェアが多様な組み合わせで動作している保守対象のネットワーク装置において発生したソフトウェア障害に関わる障害情報を受信する障害情報受信部と、前記障害情報を記録する障害情報データベースと、前記障害情報に基づき前記障害発生ネットワーク機器の障害対処方法を決定する障害対処方法決定部と、前記障害対処方法決定部が障害対処方法を決定する際に参照する障害情報設定テーブルと、前記決定した障害対処方法を前記障害発生ネットワーク機器に送信する障害対処方法送信部と、を備える事を特徴とする。
【００１６】
上記課題を解決する為に、本発明は、また、以下の手段を有するものである。すなわち、本発明に係る保守サービスを提供するためのネットワーク機器において、通信ネットワークを介して接続される、多様な複数のソフトウェアが多様な組み合わせで動作している保守対象のネットワーク装置において発生したソフトウェア障害に関わる障害情報を受信する障害情報受信部と、前記障害情報を記録する障害情報データベースと、前記障害情報に基づき前記障害発生ネットワーク機器の障害対処方法を決定する障害対処方法決定部と、前記障害対処方法決定部が障害対処方法を決定する際に参照する障害情報設定テーブルと、前記決定した障害対処方法を前記障害発生ネットワーク機器に送信する障害対処方法送信部と、を備え、障害対処方法決定部が、障害発生ソフトウェアの障害発生回数が設定閾値を超えたか否かで、決定する障害対処方法を変更する事を特徴とする。
【００１７】
上記課題を解決する為に、本発明は、また、以下の手段を有するものである。すなわち、本発明に係る保守サービスを提供するためのネットワーク機器において、通信ネットワークを介して接続される、多様な複数のソフトウェアが多様な組み合わせで動作している保守対象のネットワーク装置において発生したソフトウェア障害に関わる障害情報を受信する障害情報受信部と、前記障害情報を記録する障害情報データベースと、前記障害情報に基づき前記障害発生ネットワーク機器の障害対処方法を決定する障害対処方法決定部と、前記障害対処方法決定部が障害対処方法を決定する際に参照する障害情報設定テーブルと、前記決定した障害対処方法を前記障害発生ネットワーク機器に送信する障害対処方法送信部と、を備え、障害対処方法決定部が、情報端末別に見た特定ソフトウェアの障害発生回数の最大値と最小値の商が設定閾値を超えたか否かで、決定する障害対処方法を変更する事を特徴とする。
【００１８】
上記課題を解決する為に、本発明は、また、以下の手段を有するものである。すなわち、本発明に係る保守サービスを提供するためのネットワーク機器において、通信ネットワークを介して接続される、多様な複数のソフトウェアが多様な組み合わせで動作している保守対象のネットワーク装置において発生したソフトウェア障害に関わる障害情報を受信する障害情報受信部と、前記障害情報を記録する障害情報データベースと、前記障害情報に基づき前記障害発生ネットワーク機器の障害対処方法を決定する障害対処方法決定部と、前記障害対処方法決定部が障害対処方法を決定する際に参照する障害情報設定テーブルと、前記決定した障害対処方法を前記障害発生ネットワーク機器に送信する障害対処方法送信部と、を備え、障害対処方法決定部が、障害発生ソフトウェアがフレームワークで動いているか否かで、決定する障害対処方法を変更する事を特徴とする。
【００１９】
上記課題を解決する為に、本発明は、また、以下の手段を有するものである。すなわち、本発明に係る保守サービスを提供するためのネットワーク機器において、通信ネットワークを介して接続される、多様な複数のソフトウェアが多様な組み合わせで動作している保守対象のネットワーク装置において発生したソフトウェア障害に関わる障害情報を受信する障害情報受信部と、前記障害情報を記録する障害情報データベースと、前記障害情報に基づき前記障害発生ネットワーク機器の障害対処方法を決定する障害対処方法決定部と、前記障害対処方法決定部が障害対処方法を決定する際に参照する障害情報設定テーブルと、前記決定した障害対処方法を前記障害発生ネットワーク機器に送信する障害対処方法送信部と、を備え、障害対処方法決定部が、障害発生ソフトウェアの重要度に応じて、決定する障害対処方法を変更する事を特徴とする。
【００２０】
上記課題を解決する為に、本発明は、また、以下の手段を有するものである。すなわち、多様な複数のソフトウェアが多様な組み合わせで動作している保守対象のネットワーク機器において、発生したソフトウェア障害の障害情報を収集する障害情報収集部と、前記障害情報を記録する障害情報データベースと、前記障害情報に基づき障害対処方法を決定する障害情報処理決定部と、前記障害情報処理決定部が障害対処方法を決定する際に参照する障害情報設定テーブルと、を備える。
【００２１】
上記課題を解決する為に、本発明は、また、以下の手段を有するものである。すなわち、多様な複数のソフトウェアが多様な組み合わせで動作している保守対象のネットワーク機器において、発生したソフトウェア障害の障害情報を収集する障害情報収集部と、前記障害情報を記録する障害情報データベースと、前記障害情報に基づき障害対処方法を決定する障害情報処理決定部と、前記障害情報処理決定部が障害対処方法を決定する際に参照する障害情報設定テーブルと、を備え、障害情報処理決定部が、障害発生ソフトウェアの障害発生回数が設定閾値を超えたか否かで、決定する障害対処方法を変更する事を特徴とする。
【００２２】
上記課題を解決する為に、本発明は、また、以下の手段を有するものである。すなわち、多様な複数のソフトウェアが多様な組み合わせで動作している保守対象のネットワーク機器において、発生したソフトウェア障害の障害情報を収集する障害情報収集部と、前記障害情報を記録する障害情報データベースと、前記障害情報に基づき障害対処方法を決定する障害情報処理決定部と、前記障害情報処理決定部が障害対処方法を決定する際に参照する障害情報設定テーブルと、を備え、更に障害情報収集部を動作させる契機を作る障害情報収集ボタンと、を備える事を特徴とする。
【００２３】
以下、本発明によるシステム保守方式に関する一実施形態を図面により詳細に説明する。
【実施例１】
【００２４】
図１は、本発明における実施例１〜３の概念図である。本概念図では、リモート保守サーバ装置１００、ホームゲートウェイＡ１２０、及びホームゲートウェイＢ１８０と、を含む。リモート保守サーバ装置１００、ホームゲートウェイＡ１２０、ホームゲートウェイＢ１８０の間は、例えば、インターネット等の通信ネットワーク１６０によって接続される。【００２５】
リモート保守サーバ装置１００は、通信ネットワーク１６０で繋がれたホームゲートウェイで発生したソフトウェア障害のホームゲートウェイ毎の障害発生回数や、該障害発生回数の全ホームゲートウェイを纏めた総回数といった統計情報と、発生障害の対処方法を決定する障害対処方法決定部１０１を持つ。【００２６】
ホームゲートウェイＡ１２０は、フレームワークＡ１２５１やソフトウェアモジュール１２５０、１２５２、１２５３といったソフトウェアを実行するソフトウェア実行環境１２５、該実行環境１２５で動作するソフトウェアで発生した障害に関する障害情報、該障害情報をリモート保守サーバ装置１００へ送信する障害情報送信部１２２と、を備える。【００２７】
ホームゲートウェイＡに備わるソフトウェア実行環境１２５は、例えばＪＡＶＡの実行環境のような、ソフトウェアを実行する環境を示しており、該環境で動作するフレームワークＡ１２５１には、更に、該フレームワークＡ１２５１上でのみ動作するソフトウェアモジュール１２５２、１２５３が存在する。【００２８】
ホームゲートウェイＢ１８０は、フレームワークＢ１２５５やソフトウェアモジュール１２５４、１２５６、１２５７といったソフトウェアを実行するソフトウェア実行環境１２５、該実行環境１２５で動作するソフトウェアで発生した障害に関する障害情報、該障害情報をリモート保守サーバ装置１００へ送信する障害情報送信部１２２と、を備える。【００２９】
ホームゲートウェイＢに備わるソフトウェア実行環境１２５は、例えばＪＡＶＡの実行環境のような、ソフトウェアを実行する環境を示しており、該環境で動作するフレームワークＢ１２５５には、更に、該フレームワークＢ１２５５上でのみ動作するソフトウェアモジュール１２５６、１２５７が存在する。【００３０】
尚、本実施例では、ソフトウェアモジュールとフレームワーク、それらどちらもソフトウェアと呼ぶ。フレームワークは特定のソフトウェアモジュールを動作させるためのソフトウェアモジュールともいえる。【００３１】
上記した、ホームゲートウェイＡ１２０とホームゲートウェイＢ１８０に備わるフレームワークやソフトウェアモジュールに関し、複数の互いに異なるフレームワークやソフトウェアモジュールが、各ホームゲートウェイ各様にインストールされ、様々な組み合わせで動作している事を仮定する。尚、リモート保守サーバとホームゲートウェイの数は図示したものに限定されない。【００３２】
それでは、図１の障害復旧概念図を元に、ソフトウェア障害復旧の流れを簡単に説明する。ホームゲートウェイＡ１２０やホームゲートウェイＢ１８０で発生したソフトウェア障害は、障害情報として収集され、各ホームゲートウェイに備わる障害情報送信部１２２からリモート保守サーバ装置１００へ送信される。【００３３】
リモート保守サーバ１００に備わる障害対処方法決定部１０１は、通信ネットワーク１６０で繋がれた全てのホームゲートウェイから受信した障害の統計情報を用いて、障害の発生したそれぞれのホームゲートウェイに対する障害対処方法を決定した後、障害から復旧させる。【００３４】
ここで、ホームゲートウェイＡ１２０とホームゲートウェイＢ１８０のソフトウェア実行環境上で動作するソフトウェアとその組み合わせは互いに異なるものであってもよい事を改めて明記しておく。【００３５】
以上の概念を、具体的に説明していく。【００３６】
図２は、本発明の一実施例のシステム構成図である。一実施例として、情報処理システムは、リモート保守サーバ装置１００、ソフトウェア配布サーバ装置１１０、ホームゲートウェイＡ１２０、ホームゲートウェイＢ１８０、情報家電端末装置１３０、１４０、１５０、１９１と、を含む。【００３７】
リモート保守サーバ装置１００とソフトウェア配布サーバ装置１１０は、何れもプロバイダ側の管理下に置かれる。ホームゲートウェイＡ１２０、ホームゲートウェイＢ１８０、情報家電端末１３０、１４０、１５０、１９１は、何れもユーザ側の管理下に置かれる。上記情報処理システムでは、リモート保守サーバ装置１００とホームゲートウェイＡ１２０、ホームゲートウェイＢ１８０の間、ソフトウェア配布サーバ装置１１０とホームゲートウェイＡ１２０、ホームゲートウェイＢ１８０の間が、例えば、インターネット等の通信ネットワーク１６０によって接続される。【００３８】
また、ホームゲートウェイＡ１２０と各情報家電端末１３０、１４０、１５０の間、またはホームゲートウェイＢ１８０と情報家電端末１９１の間が、例えば、ホームネットワークのようなＬＡＮ１７０、１９０によって接続されるものとする。【００３９】
実際のシステムでは、プロバイダは多数存在する上に、プロバイダが設置するリモート保守サーバ装置１００やソフトウェア配布サーバ装置１１０の台数も１台とは限らない。また、ユーザ数も莫大な数であり、個々のユーザが所持するホームゲートウェイや情報家電装置の台数に関しても図示してある台数だけとは限らない。しかし、図２では、図示と説明の都合上、この台数に設定している。【００４０】
次に、上述したそれぞれの装置について詳細に解説する。【００４１】
プロバイダ側の装置であるリモート保守サーバ装置１００は、障害対処方法決定部１０１と障害対処情報設定テーブル１０２と、障害情報受信部１０３と、障害情報データベース１０４と、障害対処方法送信部１０５と、ソフトウェア情報受信部１０６と、を内蔵する。障害対処決定部１０１は、通信ネットワーク１６０を経てホームゲートウェイ１２０、１８０にアクセスし、ホームゲートウェイ１２０、１８０で発生した障害情報を、障害情報受信部１０３で受信し、障害情報データベース１０４に格納する。【００４２】
格納した障害情報と、障害対処情報設定テーブル１０２の記載内容を元に、障害対処方法決定部１０１が障害対処方法を決定し、障害対処方法送信部１０５から障害の発生したホームゲートウェイに障害対処方法を送信する。ソフトウェア情報受信部１０６は、ソフトウェア配布サーバ装置１１０から送信されたソフトウェアに関する情報を受信する。【００４３】
尚、本実施例を含め全ての実施例において、ソフトウェア障害とは、ソフトウェアにバグが混入している事を起因として、もしくは様々なソフトウェアの組み合わせ方が起因となり、ソフトウェア製作者の意図と反した挙動をソフトウェアが行う事を指す。【００４４】
具体的には、ネットワーク機器のＣＰＵやメモリなどのリソースをソフトウェア作成者の意図に反して大量に消費したり、特定のソフトウェアが動作している際に別の動作中ソフトウェアの挙動がおかしくなったりする事を指す。【００４５】
図５に、障害情報データベース１０４に格納された、ホームゲートウェイで発生した障害情報の一例を示す。本例では、ソフトウェア毎に障害情報を纏め、ソフトウェアの障害発生回数（ホームゲートウェイ毎の障害発生回数、及び各ホームゲートウェイで発生した障害発生回数の和）、公開されてから現在までの経過日数、ホームゲートウェイ別個別重要度（ウェイト）、といった情報を取り扱う事とした。個別重要度については後述する。【００４６】
尚、これらの情報は、ホームゲートウェイから送信される情報に含まれているとは限らず、リモート保守サーバ装置１００が自身で作成・更新したデータが含まれていても良い。【００４７】
図６に、障害対処情報設定テーブル１０２の一例を示す。該テーブルでは、リモート保守サーバ装置１００からホームゲートウェイに送信される障害ソフトウェアの復旧方法を決定する際に参照する設定情報が記載されている。本例では、デフォルトの設定値とソフトウェア毎の設定値について記載している。【００４８】
項目として、異常なソフトウェアか否か、フレームワーク上で動くか否か、一般的重要度、及び、公開されてから現在までの経過日数に応じた二つ閾値のベース値を挙げた。一般的重要度とは、各ソフトウェアの特性に合わせた重要度である。止まると困るような重要なソフトウェアは優先度が高くなるように設定する。【００４９】
二つの閾値ベース値について説明する。１つ目は、再起動すれば直る程度の軽い異常か否かを判定するために用いる値であり、ソフトウェアが公開されてから現在までの経過日数に応じて変化させている。【００５０】
２つ目は、ソフトウェアが異常か否かを判定するために用いる値であり、ホームゲートウェイ単位で見た、該ソフトウェアの最大障害発生数と最小障害発生数の比を示す。こちらも、ソフトウェアが公開されてから現在までの経過日数に応じて変化させている。これらのベース値を設定しない場合は、対応する一般的優先度に応じたデフォルト値が使用される。【００５１】
プロバイダ側の装置であるソフトウェア配布サーバ装置１１０は、ホームゲートウェイ１２０、１８０に対し、新たなソフトウェアを配布したり、リモート保守サーバ装置１００に対し、配布するソフトウェアの情報を送信したりするためのもので、ソフトウェア登録部１１１と、配布ソフトウェア格納部１１２と、ソフトウェア配布部１１３と、ソフトウェア情報送信部１１４と、を内蔵する。【００５２】
ソフトウェア登録部１１１は、ホームゲートウェイ１２０、１８０で動かすために新たに開発されたソフトウェアを配布ソフトウェア格納部１１２に登録するものである。また、ソフトウェア配布部１１３は、配布ソフトウェア格納部１１２に格納されたソフトウェアをホームゲートウェイ１２０、１８０に配布するものである。【００５３】
さらに、ソフトウェア情報送信部１１４は、ソフトウェア配布部１１３からホームゲートウェイ１２０、１８０へソフトウェアが配布される際に、リモート保守サーバ装置１００に対してソフトウェア情報を送信するためのものであり、このソフトウェア情報として、ソフトウェアの名前、フレームワーク上で動くものか、一般的優先度、公開されてからの経過日数に応じた再起動すれば直る程度の軽い異常か否かを判定する第一の閾値のベース値、同じく公開されてからの経過日数に応じたソフトウェアが異常か否かを判定する第二の閾値のベース値といった情報を含む。【００５４】
尚、ソフトウェアをソフトウェア登録部１１１が配布ソフトウェア格納部１１２に格納する際に、ソフトウェア登録部１１１が該ソフトウェアに登録日時の情報を付加するものとする。【００５５】
ユーザ側の装置であるホームゲートウェイＡ１２０は、障害情報収集部１２１、障害情報送信部１２２、障害情報格納部１２３、ソフトウェア受信部１２４、ソフトウェア実行環境１２５、障害対処方法受信部１２６、障害情報処理決定部１２７、障害情報収集ボタン１２８と、を内蔵する、ルータ機能を備えた装置である。【００５６】
障害情報収集ボタン１２８は無くても構わない。ソフトウェア実行環境１２５は、例えばＪＡＶＡの実行環境のような、ソフトウェアを実行する環境を示しており、該環境ではソフトウェアモジュールＸ１２５０やフレームワークＡ１２５１等のソフトウェアが動作する。更に、該フレームワークＡ１２５１上でのみ動作するソフトウェアモジュール１２５２、１２５３が存在する。【００５７】
尚、ソフトウェア実行環境１２５で動作するソフトウェアモジュールやフレームワークの種類や数は、図示したものに限定される事はない。【００５８】
ホームゲートウェイＢ１８０もホームゲートウェイＡ１２０と同様の機能を備えるが、図１では簡単の為にその大部分の機能を省略している。ホームゲートウェイＢ１８０がホームゲートウェイＡ１２０と違う部分は、ソフトウェア実行環境１２５で動作するソフトウェアである。【００５９】
ホームゲートウェイＢ１８０で動作するソフトウェア実行環境１２５は、例えばＪＡＶＡの実行環境のような、ソフトウェアを実行する環境を示しており、該環境ではソフトウェアモジュールＹ１２５４やフレームワークＢ１２５５等のソフトウェアが動作する。【００６０】
更に、該フレームワークＢ１２５５上でのみ動作するソフトウェアモジュール１２５６、１２５７が存在する。尚、ソフトウェア実行環境１２５で動作するソフトウェアモジュールやフレームワークの種類や数は、図示したものに限定される事はない。【００６１】
障害情報収集部１２１は、ソフトウェア配布サーバ装置１１０から配布され、ソフトウェア受信部１２４で受信したソフトウェアを実行中に発生した障害情報を収集するもので、収集された障害情報は、障害情報格納部１２３に格納される。【００６２】
この障害情報は、障害情報処理決定部１２７が決定した任意の時に、障害情報送信部１２２を用いてリモート保守サーバ装置１００に送信される。障害対処方法受信部１２６は、リモート保守サーバ装置１００から送信される障害対処方法を受信する。【００６３】
情報家電端末装置は、例えばＴＶ（テレビ）、ＤＶＤレコーダ・プレーヤ、ＰＣ（パーソナルコンピュータ）、冷蔵庫、電球等の、家電を含めたネットワーク機器全般を指す。【００６４】
図３に、図２記載のホームゲートウェイＡ１２０が、リモート保守サーバ装置１００に対して障害情報を送信する際の一例を示すフローチャートを示す。【００６５】
処理３００：障害情報処理決定部１２７は、ソフトウェアが正常に動作している時は待機している。【００６６】
処理３０１：ソフトウェアで障害が発生すると、障害情報処理決定部１２７が処理を開始する。【００６７】
処理３０２：障害情報収集部１２１が、発生した障害の情報を収集し、収集した障害情報を障害情報格納部１２３に格納する。尚、本フロー例にあるように障害が発生したときのみに障害情報収集部１２１が障害収集を開始するのではなく、例えば、図６のように、ホームゲートウェイＡ１２０に備わる障害情報収集ボタン１２８を押す事等を契機として障害情報収集部１２１が障害情報の収集を開始してもよい。【００６８】
処理３０３：障害情報処理決定部１２７が、収集した障害情報をサーバに送信するか否かを決定する。この、障害情報を送信するか否かに際し、障害情報を収集する度に送信してもよいし、特許文献２に記載されているように、障害レベルが高い時等、特別な時のみに送信してもよい。もし、送信しない場合には障害情報処理決定部１２７は待機状態に戻る。【００６９】
処理３０４：処理３０３で収集した障害情報を送信する事を決定した際は、障害情報送信部１２２から障害情報を送信する。【００７０】
図４に、図１記載のリモート保守サーバ１００が、ソフトウェア障害が発生したホームゲートウェイＡ１２０に対して障害対処方法を送信する際の一例を示すフローチャートを示す。【００７１】
処理４００：処理３０４でホームゲートウェイＡ１２０から送信された障害情報を、障害情報受信部１０３が受信する。【００７２】
処理４０１：受信した障害情報を、障害情報受信部１０３が障害情報データベース１０４に格納する。【００７３】
処理４０２：障害情報データベース１０４の中の、障害の発生したソフトウェアの障害発生回数を１増やす。【００７４】
処理４０３：障害の発生したソフトウェアが障害対処情報設定テーブル１０２の中で異常なソフトウェアとして登録されているか否か、障害対処方法決定部１０１がチェックする。【００７５】
処理４０４：処理４０３において、障害発生ソフトウェアが異常なソフトウェアとして登録されていた場合、その障害発生ソフトウェアが未だホームゲートウェイＡ１２０上で動作している場合は停止するよう障害対処方法送信部１０５からホームゲートウェイＡ１２０へ命令を送信し、既に停止している場合はそのまま停止させておく。尚、停止させるのが好ましくないソフトウェアである場合は、例えば、ポップアップ等でユーザに確認後に該ソフトウェアを再起動させるよう、障害対処方法送信部１０５からホームゲートウェイＡ１２０へ命令を送信してもよい。【００７６】
処理４０５：処理４０３において、障害発生ソフトウェアが異常なソフトウェアとして登録されていなかった場合、障害発生ソフトウェアの障害発生数が、再起動すれば直る程度の軽い異常か否かを判定する第一の閾値を超えたか否かを、障害対処方法決定部１０１がチェックする。【００７７】
本実施例では、障害対処情報設定テーブル１０２に記載されている第一の閾値ベース値と、障害情報データベース１０４に記載されている個別重要度（ウェイト）の積を第一の閾値として用いる。尚、障害対処情報設定テーブル１０２に前者のベース値がない場合は、設定されている一般重要度と、障害発生ソフトウェアが公開されてから現在までの経過日数に応じたデフォルトの値を用いる。【００７８】
また、障害情報データベース１０４に後者の値がない場合は、ウェイトを１とする。リモート保守サーバ装置１００の処理負荷が高い場合、もしくは処理負荷を出来得る限り抑えたいと考えるときには、障害対処情報設定テーブル１０２に記載されている第一の閾値ベース値をそのまま、第一の閾値として扱っても良い。処理４０５は、発生した障害が、再起動させれば直る程度の軽い異常か否かを判別するためのものであり、方法は上記に限定されるものではない。【００７９】
処理４０６：処理４０５において、障害発生数が第一の閾値を超えていない場合、障害発生ソフトウェアを再起動させるよう、障害対処方法送信部１０５からホームゲートウェイＡ１２０へ命令を送信する。【００８０】
処理４０７：処理４０５において、障害発生数が第一の閾値を超えている場合、障害情報データベース１０４に記載されているホームゲートウェイ毎に見た障害発生ソフトウェアの障害発生数の最大数と最小数の比が、ソフトウェアが異常か否かを判定する第二の閾値を超えたか否か、を障害対処方法決定部１０１がチェックする。この際、障害発生最小数が０の場合は１として計算する。【００８１】
本実施例では、障害対処情報設定テーブル１０２に記載されている第二の閾値ベース値と、障害情報データベース１０４に記載されている個別重要度（ウェイト）の積を第二の閾値として用いる。【００８２】
尚、障害対処情報設定テーブル１０２に前者のベース値がない場合は、設定されている一般重要度と、障害発生ソフトウェアが公開されてから現在までの経過日数に応じたデフォルトの値を用いる。また、障害情報データベース１０４に後者の値がない場合は、ウェイトを１とする。【００８３】
リモート保守サーバ装置１００の処理負荷が高い場合、もしくは処理負荷を出来得る限り抑えたいと考えるときには、障害対処情報設定テーブル１０２に記載されている第二の閾値ベース値をそのまま、第二の閾値として扱っても良い。処理４０７は、発生した障害の原因が、ソフトウェア自体にあるものか、それ以外にあるかを切り分ける為に行うものであり、方法は上記に限定されるものではない。【００８４】
処理４０８：処理４０７において、第二の閾値を超えていない場合、障害対処情報設定テーブル１０２に障害発生ソフトウェアが異常であると登録した後、その障害発生ソフトウェアが未だホームゲートウェイＡ１２０上で動作している場合は停止するよう障害対処方法送信部１０５からホームゲートウェイＡ１２０へ命令を送信し、既に停止している場合はそのまま停止させておく。尚、停止させるのが好ましくないソフトウェアである場合は、例えば、ポップアップ等でユーザに確認後に該ソフトウェアを再起動させるよう、障害対処方法送信部１０５からホームゲートウェイＡ１２０へ命令を送信してもよい。【００８５】
処理４０９：処理４０７において、第二の閾値を超えている場合、障害発生ソフトウェアがフレームワーク上で動いているか否かを、障害対処方法決定部１０１が障害対処情報設定テーブル１０２に記載されている内容を見てチェックする。これは、ソフトウェア起因ではない事が判明した障害発生の原因が、ソフトウェアが動くフレームワークにあるものかその他の理由によるものかを切り分ける為に行うものである。【００８６】
処理４１０：処理４０９において、障害発生ソフトウェアがフレームワーク上で動作しない事が判明した場合、ホームゲートウェイ自体を再起動させるよう、障害対処方法送信部１０５からホームゲートウェイＡ１２０へ命令を送信する。【００８７】
処理４１１：処理４０９において、障害発生ソフトウェアがフレームワーク上で動作する事が判明した場合、このフレームワークを障害発生ソフトウェアとして、処理４０１から処理を再開する。【００８８】
本実施例の効果として、多様なソフトウェアが多様に組み合わさって動作するホームゲートウェイでも、リモート保守サーバ装置１００を活用して複数のホームゲートウェイからソフトウェア毎の障害情報を収集してそれを活用する事でソフトウェア、フレームワーク、その他の三つに障害発生原因を切り分ける事ができ、またそれに加えて、障害から復旧させる際に閾値を判断の基準としたロジックを実施する事で障害からの復旧を低コストで行う事ができる。【００８９】
また、本実施例では、障害保守に関し、リモート保守サーバ装置１００に障害が発生した時の対処方法を決定する機能を持たせた。これは、多数のホームゲートウェイで起きた障害を、纏めてサーバで保守する事を可能とするが、通信ネットワークの負荷が高い時や、通信ネットワークの異常時に対応する為に、今回説明したリモート保守サーバ装置１００の機能をホームゲートウェイ側に一部実装する事も可能である。これに関しては、実施例４〜６で一例を説明する。
【実施例２】
【００９０】
実施例１では、障害が発生した時のみに障害発生ソフトウェアの障害情報を収集するものとしたが、もしホームゲートウェイＡ１２０に障害情報収集ボタン１２８やそれに類するものが備わっている場合は、それを押下する事を契機として障害情報収集を開始してもよい。【００９１】
図７に、図２記載のホームゲートウェイＡ１２０が、リモート保守サーバ装置１００に対して障害情報を送信する際の一例を示すフローチャートを示す。【００９２】
処理７００：障害情報処理決定部１２７は、ソフトウェアが正常に動作している時は待機している。【００９３】
処理７０１：ホームゲートウェイＡ１２０に備わる障害情報収集ボタン１２８が押下されると、障害情報処理決定部１２７が処理を開始する。【００９４】
処理７０２：障害情報収集部１２１が、発生した障害の情報を収集し、収集した障害情報を障害情報格納部１２３に格納する。【００９５】
処理７０３：障害情報処理決定部１２７が、収集した障害情報から、ホームゲートウェイＡ１２０でソフトウェア障害が発生したか否かを判定する。もし障害が発生していないと判定した場合は、障害情報処理決定部１２７は待機状態に戻る。【００９６】
処理７０４：処理７０３において、障害情報処理決定部１２７がホームゲートウェイＡ１２０でソフトウェア障害が発生していると判定した場合は、同じく障害情報処理決定部１２７が、収集した障害情報をリモート保守サーバ装置１００に送信するか否かを決定する。【００９７】
この、障害情報を送信するか否かに際し、障害情報を収集する度に送信してもよいし、特許文献２に記載されているように、障害レベルが高い時等、特別な時のみに送信してもよい。もし、送信しない場合には障害情報処理決定部１２７は待機状態に戻る。【００９８】
処理７０５：処理７０４で収集した障害情報を送信する事を決定した際は、障害情報送信部１２２から障害情報を送信する。【００９９】
その他の処理に関しては、実施例１と同様である。【０１００】
本実施例の効果として、実施例１と同様の効果に加え、ホームゲートウェイに備わる障害情報収集ボタン１２８を契機として障害発生の診断や復旧をユーザ自ら実施できる点で、よりアクティブで自由な障害復旧を行う事が出来る。
【実施例３】
【０１０１】
実施例１では、障害発生ソフトウェアがフレームワーク上で動作するか否か分からない場合を想定しているが、フレームワーク上で動作しないと予め分かっている場合は、図４の処理を図８に示すように短縮してもよい。【０１０２】
図８に、図２記載のリモート保守サーバ１００が、ソフトウェア障害が発生したホームゲートウェイＡ１２０に対して障害対処方法を送信する際の一例を示すフローチャートを示す。
処理８００：処理３０４でホームゲートウェイＡ１２０から送信された障害情報を、障害情報受信部１０３が受信する。【０１０３】
処理８０１：受信した障害情報を、障害情報受信部１０３が障害情報データベース１０４に格納する。【０１０４】
処理８０２：障害情報データベース１０４の中の、障害の発生したソフトウェアの障害発生回数を１増やす。【０１０５】
処理８０３：障害の発生したソフトウェアが障害対処情報設定テーブル１０２の中で異常なソフトウェアとして登録されているか否か、障害対処方法決定部１０１がチェックする。【０１０６】
処理８０４：処理８０３において、障害発生ソフトウェアが異常なソフトウェアとして登録されていた場合、その障害発生ソフトウェアが未だホームゲートウェイＡ１２０上で動作している場合は停止するよう障害対処方法送信部１０５からホームゲートウェイＡ１２０へ命令を送信し、既に停止している場合はそのまま停止させておく。尚、停止させるのが好ましくないソフトウェアである場合は、例えば、ポップアップ等でユーザに確認後に該ソフトウェアを再起動させるよう、障害対処方法送信部１０５からホームゲートウェイＡ１２０へ命令を送信してもよい。【０１０７】
処理８０５：処理８０３において、障害発生ソフトウェアが異常なソフトウェアとして登録されていなかった場合、障害発生ソフトウェアの障害発生数が、再起動すれば直る程度の軽い異常か否かを判定する第一の閾値を超えたか否かを、障害対処方法決定部１０１がチェックする。本実施例では、障害対処情報設定テーブル１０２に記載されている第一の閾値ベース値と、障害情報データベース１０４に記載されている個別重要度（ウェイト）の積を第一の閾値として用いる。【０１０８】
尚、障害対処情報設定テーブル１０２に前者のベース値がない場合は、設定されている一般重要度と、障害発生ソフトウェアが公開されてから現在までの経過日数に応じたデフォルトの値を用いる。また、障害情報データベース１０４に後者の値がない場合は、ウェイトを１とする。【０１０９】
リモート保守サーバ装置１００の処理負荷が高い場合、もしくは処理負荷を出来得る限り抑えたいと考えるときには、障害対処情報設定テーブル１０２に記載されている第一の閾値ベース値をそのまま、第一の閾値として扱っても良い。処理８０５は、発生した障害が、再起動させれば直る程度の軽い異常か否かを判別するためのものであり、方法は上記に限定されるものではない。【０１１０】
処理８０６：処理８０５において、障害発生数が第一の閾値を超えていない場合、障害発生ソフトウェアを再起動させるよう、障害対処方法送信部１０５からホームゲートウェイＡ１２０へ命令を送信する。【０１１１】
処理８０７：処理８０５において、障害発生数が第一の閾値を超えている場合、障害情報データベース１０４に記載されているホームゲートウェイ毎に見た障害発生ソフトウェアの障害発生数の最大数と最小数の比が、ソフトウェアが異常か否かを判定する第二の閾値を超えたか否か、を障害対処方法決定部１０１がチェックする。この際、障害発生最小数が０の場合は１として計算する。本実施例では、障害対処情報設定テーブル１０２に記載されている第二の閾値ベース値と、障害情報データベース１０４に記載されている個別重要度（ウェイト）の積を第二の閾値として用いる。【０１１２】
尚、障害対処情報設定テーブル１０２に前者のベース値がない場合は、設定されている一般重要度と、障害発生ソフトウェアが公開されてから現在までの経過日数に応じたデフォルトの値を用いる。また、障害情報データベース１０４に後者の値がない場合は、ウェイトを１とする。【０１１３】
リモート保守サーバ装置１００の処理負荷が高い場合、もしくは処理負荷を出来得る限り抑えたいと考えるときには、障害対処情報設定テーブル１０２に記載されている第二の閾値ベース値をそのまま、第二の閾値として扱っても良い。処理８０７は、発生した障害の原因が、ソフトウェア自体にあるものか、それ以外にあるかを切り分ける為に行うものであり、方法は上記に限定されるものではない。【０１１４】
処理８０８：処理８０７において、第二の閾値を超えていない場合、障害対処情報設定テーブル１０２に障害発生ソフトウェアが異常であると登録した後、その障害発生ソフトウェアが未だホームゲートウェイＡ１２０上で動作している場合は停止するよう障害対処方法送信部１０５からホームゲートウェイＡ１２０へ命令を送信し、既に停止している場合はそのまま停止させておく。尚、停止させるのが好ましくないソフトウェアである場合は、例えば、ポップアップ等でユーザに確認後に該ソフトウェアを再起動させるよう、障害対処方法送信部１０５からホームゲートウェイＡ１２０へ命令を送信してもよい。【０１１５】
処理８０９：処理８０７において、第二の閾値を超えている場合、ホームゲートウェイ自体を再起動させるよう、障害対処方法送信部１０５からホームゲートウェイＡ１２０へ命令を送信する。【０１１６】
その他の処理に関しては、実施例１と同様である。【０１１７】
本実施例の効果として、実施例１と同様の効果を得られるが、もしホームゲートウェイのソフトウェア実行環境１２５がフレームワークを含まない構成であった場合は、本実施例の方法を用いる事で、フレームワークのチェックという余計な処理を省略する事で障害復旧のコストをより低く抑える事が出来る。
【実施例４】
【０１１８】
実施例１〜３においては、ソフトウェア障害の発生回数カウントはリモート保守サーバ装置１００で行うようにしているが、このカウンタを備えるのはリモート保守サーバ１００に限らず、ホームゲートウェイＡ１２０側に備える事も可能である。実施例４では、カウンタをホームゲートウェイＡ１２０に備えた場合の一実施例について述べる。【０１１９】
図９は、本発明における実施例４〜６の概念図である。本概念図では、リモート保守サーバ装置９００、ホームゲートウェイＡ９２０、及びホームゲートウェイＢ９８０と、を含む。【０１２０】
リモート保守サーバ装置９００、ホームゲートウェイＡ９２０、ホームゲートウェイＢ９８０の間は、例えば、インターネット等の通信ネットワーク９６０によって接続される。リモート保守サーバ装置９００は、通信ネットワーク９６０で繋がれたあるホームゲートウェイで発生したソフトウェア障害が、該ソフトウェアがインストールされているホームゲートウェイ全体中の何パーセントのホームゲートウェイで起こっているかといった統計情報と、発生障害の対処方法を決定する障害対処方法決定部９０１を持つ。【０１２１】
ホームゲートウェイＡ９２０は、フレームワークＡ９２５１やソフトウェアモジュール９２５０、９２５２、９２５３といったソフトウェアを実行するソフトウェア実行環境９２５、該実行環境９２５で動作するソフトウェアで発生した障害に関する障害情報、該障害情報をもとに障害対処方法を決定する障害情報処理決定部９２７、該障害情報をリモート保守サーバ装置９００へ送信する障害情報送信部９２２と、を備える。【０１２２】
ホームゲートウェイＡに備わるソフトウェア実行環境９２５は、例えばＪＡＶＡの実行環境のような、ソフトウェアを実行する環境を示しており、該環境で動作するフレームワークＡ９２５１には、更に、該フレームワークＡ９２５１上でのみ動作するソフトウェアモジュール９２５２、９２５３が存在する。【０１２３】
ホームゲートウェイＢ９８０は、フレームワークＢ９２５５やソフトウェアモジュール９２５４、９２５６、９２５７といったソフトウェアを実行するソフトウェア実行環境９２５、該実行環境９２５で動作するソフトウェアで発生した障害に関する障害情報、該障害情報をもとに障害対処方法を決定する障害情報処理決定部９２７、該障害情報をリモート保守サーバ装置９００へ送信する障害情報送信部９２２と、を備える。【０１２４】
ホームゲートウェイＢに備わるソフトウェア実行環境９２５は、例えばＪＡＶＡの実行環境のような、ソフトウェアを実行する環境を示しており、該環境で動作するフレームワークＢ９２５５には、更に、該フレームワークＢ９２５５上でのみ動作するソフトウェアモジュール９２５６、９２５７が存在する。【０１２５】
尚、本実施例では、ソフトウェアモジュールとフレームワーク、それらどちらもソフトウェアと呼ぶ。上記した、ホームゲートウェイＡ９２０とホームゲートウェイＢ９８０に備わるフレームワークやソフトウェアモジュールに関し、複数の互いに異なるフレームワークやソフトウェアモジュールが、各ホームゲートウェイ各様にインストールされ、様々な組み合わせで動作している事を仮定する。【０１２６】
尚、リモート保守サーバとホームゲートウェイの数は図示したもののみに限定されない。【０１２７】
以上の概念を、具体的に説明していく。【０１２８】
図１０は、本発明の一実施例のシステム構成図である。一実施例として、情報処理システムは、リモート保守サーバ装置９００、ソフトウェア配布サーバ装置９１０、ホームゲートウェイＡ９２０、ホームゲートウェイＢ９８０、情報家電端末装置９３０、９４０、９５０、９１００と、を含む。【０１２９】
リモート保守サーバ装置９００とソフトウェア配布サーバ装置９１０は、何れもプロバイダ側の管理下に置かれる。ホームゲートウェイＡ９２０、ホームゲートウェイＢ９８０、情報家電端末９３０、９４０、９５０、９１００は、何れもユーザ側の管理下に置かれる。【０１３０】
上記情報処理システムでは、リモート保守サーバ装置９００とホームゲートウェイＡ９２０、ホームゲートウェイＢ９８０の間、ソフトウェア配布サーバ装置９１０とホームゲートウェイＡ９２０、ホームゲートウェイＢ９８０の間が、例えば、インターネット等の通信ネットワーク９６０によって接続される。【０１３１】
また、ホームゲートウェイＡ９２０と各情報家電端末９３０、９４０、９５０の間、またはホームゲートウェイＢ９８０と情報家電端末９１００の間が、例えば、ホームネットワークのようなＬＡＮ９７０、９９０によって接続されるものとする。【０１３２】
実際のシステムでは、プロバイダは多数存在する上に、プロバイダが設置するリモート保守サーバ装置９００やソフトウェア配布サーバ装置９１０の台数も１台とは限らない。また、ユーザ数も莫大な数であり、個々のユーザが所持するホームゲートウェイや情報家電装置の台数に関しても図示してある台数だけとは限らない。しかし、図１０では、図示と説明の都合上、この台数に設定している。【０１３３】
次に、上述したそれぞれの装置について詳細に解説する。【０１３４】
プロバイダ側の装置であるリモート保守サーバ装置９００は、障害対処方法決定部９０１と障害対処情報設定テーブル９０２と、障害情報受信部９０３と、障害情報データベース９０４と、障害対処方法送信部９０５と、ソフトウェア情報受信部９０６と、を内蔵する。障害対処決定部９０１は、通信ネットワーク９６０を経てホームゲートウェイ９２０、９８０にアクセスし、ホームゲートウェイ９２０、９８０で発生した障害情報を、障害情報受信部９０３で受信し、障害情報データベース９０４に格納する。【０１３５】
格納した障害情報と、障害対処情報設定テーブル９０２の記載内容を元に、障害対処方法決定部９０１が障害対処方法を決定し、障害対処方法送信部９０５から障害の発生したホームゲートウェイに障害対処方法を送信する。ソフトウェア情報受信部９０６は、ソフトウェア配布サーバ装置９１０から送信されたソフトウェアに関する情報を受信する。【０１３６】
図１３に、障害情報データベース９０４に格納された、ホームゲートウェイで発生した障害情報の一例を示す。本例では、ソフトウェア毎に障害情報を纏め、該ソフトウェアが動作しているホームゲートウェイの全体台数、該ソフトウェアに異常が起きたホームゲートウェイの台数、該ソフトウェアが動作しているホームゲートウェイ全体の台数に対する該ソフトウェアに異常が起きたホームゲートウェイの台数のパーセンテージ、公開されてから現在までの経過日数、といった情報を取り扱う事とした。【０１３７】
尚、これらの情報は、ホームゲートウェイから送信される情報に含まれているとは限らず、リモート保守サーバ装置９００が自身で作成・更新したデータが含まれていても良い。【０１３８】
図１４に、障害対処情報設定テーブル９０２の一例を示す。該テーブルでは、リモート保守サーバ装置９００からホームゲートウェイに送信される障害ソフトウェアの復旧方法を決定する際に参照する設定情報が記載されている。【０１３９】
本例では、デフォルトの設定値とソフトウェア毎の設定値について記載している。項目として、異常なソフトウェアか否か、フレームワーク上で動くか否か、及び、公開されてから現在までの経過日数に応じた、ソフトウェアが異常か否かを判定するために用いる閾値を挙げた。【０１４０】
この閾値は、障害が発生したソフトウェアが動作しているホームゲートウェイ全体の台数に対する、該ソフトウェアに異常が起きたホームゲートウェイの台数のパーセンテージである。この値は、ソフトウェアが公開されてから現在までの経過日数に応じて変化させている。この値を設定しない場合は、デフォルト値が使用される。【０１４１】
プロバイダ側の装置であるソフトウェア配布サーバ装置９１０は、ホームゲートウェイ９２０、９８０に対し、新たなソフトウェアを配布したり、リモート保守サーバ装置９００に対し、配布するソフトウェアの情報を送信したりするためのもので、ソフトウェア登録部９１１と、配布ソフトウェア格納部９１２と、ソフトウェア配布部９１３と、ソフトウェア情報送信部９１４と、を内蔵する。【０１４２】
ソフトウェア登録部９１１は、ホームゲートウェイ９２０、９８０で動かすために新たに開発されたソフトウェアを配布ソフトウェア格納部９１２に登録するものである。【０１４３】
また、ソフトウェア配布部９１３は、配布ソフトウェア格納部９１２に格納されたソフトウェアをホームゲートウェイ９２０、９８０に配布するものである。【０１４４】
さらに、ソフトウェア情報送信部９１４は、ソフトウェア配布部９１３からホームゲートウェイ９２０、９８０へソフトウェアが配布される際に、リモート保守サーバ装置９００に対してソフトウェア情報を送信するためのものであり、このソフトウェア情報として、ソフトウェアの名前、フレームワーク上で動くものか、ソフトウェアが公開されてからの経過日数に応じたソフトウェアが異常か否かを判定する閾値といった情報を含む。【０１４５】
尚、ソフトウェアをソフトウェア登録部９１１が配布ソフトウェア格納部９１２に格納する際に、ソフトウェア登録部９１１が該ソフトウェアに登録日時の情報を付加するものとする。【０１４６】
ユーザ側の装置であるホームゲートウェイＡ９２０は、障害情報収集部９２１、障害情報送信部９２２、障害情報データベース９２３、ソフトウェア受信部９２４、ソフトウェア実行環境９２５、障害対処方法受信部９２６、障害情報処理決定部９２７、障害情報収集ボタン９２８、障害対処情報設定テーブル９２９と、を内蔵する、ルータ機能を備えた装置である。障害情報収集ボタン９２８は無くても構わない。【０１４７】
ソフトウェア実行環境９２５は、例えばＪＡＶＡの実行環境のような、ソフトウェアを実行する環境を示しており、該環境ではソフトウェアモジュールＸ９２５０やフレームワークＡ９２５１等のソフトウェアが動作する。更に、該フレームワークＡ９２５１上でのみ動作するソフトウェアモジュール９２５２、９２５３が存在する。【０１４８】
尚、ソフトウェア実行環境９２５で動作するソフトウェアモジュールやフレームワークの種類や数は、図示したものに限定される事はない。ホームゲートウェイＢ９８０もホームゲートウェイＡ９２０と同様の機能を備えるが、図１０では簡単の為にその大部分の機能を省略している。【０１４９】
ホームゲートウェイＢ９８０がホームゲートウェイＡ９２０と違う部分は、ソフトウェア実行環境９２５で動作するソフトウェアである。ホームゲートウェイＢ９８０で動作するソフトウェア実行環境９２５は、例えばＪＡＶＡの実行環境のような、ソフトウェアを実行する環境を示しており、該環境ではソフトウェアモジュールＹ９２５４やフレームワークＢ９２５５等のソフトウェアが動作する。更に、該フレームワークＢ９２５５上でのみ動作するソフトウェアモジュール９２５６、９２５７が存在する。【０１５０】
尚、ソフトウェア実行環境９２５で動作するソフトウェアモジュールやフレームワークの種類や数は、図示したものに限定される事はない。障害情報収集部９２１は、ソフトウェア配布サーバ装置９１０から配布され、ソフトウェア受信部９２４で受信したソフトウェアを実行中に発生した障害情報を収集するもので、収集された障害情報は、障害情報データベース９２３に格納される。【０１５１】
障害情報処理決定部９２７は、障害情報データベース９２３と障害対処情報設定テーブル９２９の情報を元に、一定回数、障害からの復旧を自ら試みるが、一定回数以上に該ソフトウェアにおいて障害が発生した場合は、障害情報処理決定部９２７が決定した任意の時に、障害情報送信部９２２を用いてリモート保守サーバ装置９００に障害情報を送信する。障害対処方法受信部９２６は、リモート保守サーバ装置９００から送信される障害対処方法を受信する。【０１５２】
図１５に、障害情報データベース９２３の一例を示す。該テーブルは、ソフトウェア毎に管理され、例えば、障害発生回数、公開されてから現在までの経過日数と、を含むものとする。【０１５３】
図１６に、障害対処情報設定テーブル９２９の一例を示す。該テーブルは、ソフトウェア毎に管理され、例えば、異常なソフトウェアか否か、フレームワーク上で動くか否か、及び公開されてから現在までの経過日数に応じた、再起動すれば直る程度の軽い異常か否かを判定する閾値と、を含むものとする。【０１５４】
情報家電端末装置は、例えばＴＶ（テレビ）、ＤＶＤレコーダ・プレーヤ、ＰＣ（パーソナルコンピュータ）、冷蔵庫、電球等の、家電を含めたネットワーク機器全般を指す。【０１５５】
図１１に、図１０記載のホームゲートウェイＡ９２０が、再起動すれば直る程度の軽い異常である場合は再起動させ、そうでない場合はリモート保守サーバ装置９００に対して障害情報を送信する際の一例を示すフローチャートを示す。【０１５６】
処理１１００：障害情報処理決定部９２７は、ソフトウェアが正常に動作している時は待機している。【０１５７】
処理１１０１：ソフトウェアに障害が発生すると、障害情報処理決定部９２７が処理を開始する。【０１５８】
処理１１０２：障害の発生したソフトウェアが障害対処情報設定テーブル９２９の中で異常なソフトウェアとして登録されているか否か、障害情報処理決定部９２７がチェックする。【０１５９】
処理１１０３：処理１１０２において、障害発生ソフトウェアが異常なソフトウェアとして登録されていた場合、その障害発生ソフトウェアが未だホームゲートウェイＡ９２０上で動作している場合は停止するよう障害情報処理決定部９２７が命令し、既に停止している場合はそのまま停止させておく。尚、停止させるのが好ましくないソフトウェアである場合は、例えば、ポップアップ等でユーザに確認後に該ソフトウェアを再起動させるよう、障害情報処理決定部９２７が命令してもよい。【０１６０】
処理１１０４：処理１１０２において、障害発生ソフトウェアが異常なソフトウェアとして登録されていなかった場合、障害情報収集部９２１が、発生した障害の情報を収集し、収集した障害情報を障害情報データベース９２３に格納する。【０１６１】
処理１１０５：障害情報データベース９２３の中の、障害の発生したソフトウェアの障害発生回数を１増やす。【０１６２】
処理１１０６：障害発生ソフトウェアが再起動すれば直る程度の軽い異常か否かを、障害情報処理決定部９２７がチェックする。本実施例では、障害対処情報設定テーブル９２９に記載されている、公開されてから現在までの経過日数に応じた障害発生回数の閾値と、障害情報データベー９８２３に記載されている、障害発生回数との比較により、これを行う。処理１１０６は、発生した障害が、再起動させれば直る程度の軽い異常か否かを判別するためのものであり、方法は上記に限定されるものではない。【０１６３】
処理１１０７：もし処理１１０６において、障害発生ソフトウェアの障害発生回数が閾値を越えなかった場合は、障害情報処理決定部９２７は、障害が発生したソフトウェアを再起動させる。【０１６４】
処理１１０８：障害情報送信部９２２から障害情報を送信する。【０１６５】
図１２に、図１０記載のリモート保守サーバ９００が、ソフトウェア障害が発生したホームゲートウェイＡ９２０に対して障害対処方法を送信する際の一例を示すフローチャートを示す。【０１６６】
処理１２００：処理１１０８でホームゲートウェイ９２０から送信された障害情報を、障害情報受信部９０３が受信する。【０１６７】
処理１２０１：受信した障害情報を、障害情報受信部９０３が障害情報データベース９０４に格納する。【０１６８】
処理１２０２：障害対処方法決定部９０１が、障害情報設定テーブル９０２に障害発生ソフトウェアが異常なものとして記載されているかチェックする。【０１６９】
処理１２０３：処理１２０２で、もし障害発生ソフトウェアが異常なものとして判断されれば、障害対処方法送信部９０５から障害発生ソフトウェアが異常であるという情報をホームゲートウェイＡ９２０へ送信するとともに、その障害発生ソフトウェアが未だホームゲートウェイＡ９２０上で動作している場合は停止するよう同じく障害対処方法送信部９０５からホームゲートウェイＡ９２０へ命令を送信し、既に停止している場合はそのまま停止させておく。【０１７０】
尚、停止させるのが好ましくないソフトウェアである場合は、例えば、ポップアップ等でユーザに確認後に該ソフトウェアを再起動させるよう、障害対処方法送信部９０５からホームゲートウェイＡ９２０へ命令を送信してもよい。【０１７１】
処理１２０４：障害対処方法決定部９０１が、障害情報設定テーブル９０２に記載されている、公開されてから現在までの経過日数に応じたソフトウェアが異常か否かを判定するための閾値と、障害情報データベース９０４に記載されている、ソフトウェア異常が起きたホームゲートウェイ台数の、該ソフトウェアが動作するホームゲートウェイ全体台数に対する割合と、を比較し、障害発生ソフトウェアが異常か否かを判定する。【０１７２】
処理１２０５：処理１２０４で、もし障害が発生したホームゲートウェイ台数の全体台数に対する割合が閾値を超え、障害発生ソフトウェアが異常であると判定されれば、障害対処方法送信部９０５から障害発生ソフトウェアが異常であるという情報をホームゲートウェイＡ９２０へ送信するとともに障害対処情報設定テーブル９０２に障害発生ソフトウェアは異常であると記載した後、その障害発生ソフトウェアが未だホームゲートウェイＡ９２０上で動作している場合は停止するよう同じく障害対処方法送信部９０５からホームゲートウェイＡ９２０へ命令を送信し、既に停止している場合はそのまま停止させておく。【０１７３】
尚、停止させるのが好ましくないソフトウェアである場合は、例えば、ポップアップ等でユーザに確認後に該ソフトウェアを再起動させるよう、障害対処方法送信部９０５からホームゲートウェイＡ９２０へ命令を送信してもよい。【０１７４】
処理１２０６：障害発生ソフトウェアがフレームワーク上で動いているか否かを、障害対処方法決定部９０１が障害対処情報設定テーブル９０２に記載されている内容を見てチェックする。これは、ソフトウェア起因ではない事が判明した障害発生の原因が、ソフトウェアが動くフレームワークにあるものかその他の理由によるものかを切り分ける為に行うものである。【０１７５】
処理１２０７：処理１２０６において、障害発生ソフトウェアがフレームワーク上で動作しない事が判明した場合、ホームゲートウェイ自体を再起動させるよう、障害対処方法送信部９０５からホームゲートウェイＡ９２０へ命令を送信する。【０１７６】
処理１２０８：処理１２０６において、障害発生ソフトウェアがフレームワーク上で動作する事が判明した場合、このフレームワークを障害発生ソフトウェアとして、処理１１０１から処理を再開するよう、障害対処方法送信部９０５からホームゲートウェイＡ９２０へ命令を送信する。【０１７７】
本実施例の効果として、実施例１と同様の効果が得られるが、実施例１のリモート保守サーバ装置１００が備える障害復旧のための処理を一部ホームゲートウェイ自身に持たせる事で、ホームゲートウェイとリモート保守サーバ装置１００間の通信ネットワークの負荷を下げる事ができ、また通信ネットワークを介さない障害復旧を行う事で、より低コストに障害復旧出来る。また、これにより、通信ネットワークの異常時にも障害からの復旧が可能となる。
【実施例５】
【０１７８】
実施例４では、障害が発生した時のみにソフトウェアの障害情報を収集するものとしたが、もしホームゲートウェイＡ９２０に障害情報収集ボタン９２８やそれに類するものが備わっている場合は、それを押下する事を契機として障害情報収集を開始してもよい。【０１７９】
図１７に、図１０記載のホームゲートウェイＡ９２０が、再起動すれば直る程度の軽い異常である場合は再起動させ、そうでない場合はリモート保守サーバ装置９００に対して障害情報を送信する際の一例を示すフローチャートを示す。【０１８０】
処理１７００：障害情報処理決定部９２７は、ソフトウェアが正常に動作している時は待機している。【０１８１】
処理１７０１：ホームゲートウェイに備わる障害情報収集ボタン９２８が押下されると、障害情報処理決定部９２７が処理を開始する。【０１８２】
処理１７０２：障害情報収集部９２１が、発生した障害の情報を収集し、もし情報があれば、収集した障害情報を障害情報データベース９２３に格納する。【０１８３】
処理１７０３：障害情報処理決定部９２７が、収集した障害情報から、ホームゲートウェイＡ９２０でソフトウェア障害が発生したか否かを判定する。もし障害が発生していないと判定した場合は、障害情報処理決定部９２７は待機状態に戻る。【０１８４】
処理１７０４：障害の発生したソフトウェアが障害対処情報設定テーブル９２９の中で異常なソフトウェアとして登録されているか否か、障害情報処理決定部９２７がチェックする。【０１８５】
処理１７０５：処理１７０４において、障害発生ソフトウェアが異常なソフトウェアとして登録されていた場合、その障害発生ソフトウェアが未だホームゲートウェイＡ９２０上で動作している場合は停止するよう障害情報処理決定部９２７が命令し、既に停止している場合はそのまま停止させておく。【０１８６】
尚、停止させるのが好ましくないソフトウェアである場合は、例えば、ポップアップ等でユーザに確認後に該ソフトウェアを再起動させるよう、障害情報処理決定部９２７が命令してもよい。【０１８７】
処理１７０６：障害情報データベース９２３の中の、障害の発生したソフトウェアの障害発生回数を１増やす。【０１８８】
処理１７０７：障害発生ソフトウェアが再起動すれば直る程度の軽い異常か否かを、障害情報処理決定部９２７がチェックする。本実施例では、障害対処情報設定テーブル９２９に記載されている、公開されてから現在までの経過日数に応じた障害発生回数の閾値と、障害情報データベース９２３に記載されている、障害発生回数との比較により、これを行う。処理１７０７は、発生した障害が、再起動させれば直る程度の軽い異常か否かを判別するためのものであり、方法は上記に限定されるものではない。【０１８９】
処理１７０８：もし処理１７０７において、障害発生ソフトウェアの障害発生回数が閾値を越えなかった場合は、障害情報処理決定部９２７は、障害が発生したソフトウェアを再起動させる。【０１９０】
処理１７０９：障害情報送信部９２２から障害情報を送信する。【０１９１】
その他の処理に関しては、実施例４と同様である。【０１９２】
本実施例の効果として、実施例４と同様の効果に加え、ホームゲートウェイに備わる障害情報収集ボタン１２８を契機として障害発生の診断や復旧をユーザ自ら実施できる点で、よりアクティブで自由な障害復旧を行う事が出来る。
【実施例６】
【０１９３】
実施例４では、障害発生ソフトウェアがフレームワーク上で動作するか否か分からない場合を想定しているが、フレームワーク上で動作しないと予め分かっている場合は、図１２の処理を図１８に示すように短縮してもよい。【０１９４】
図１８に、図１０記載のリモート保守サーバ９００が、ソフトウェア障害が発生したホームゲートウェイＡ９２０に対して障害対処方法を送信する際の一例を示すフローチャートを示す。【０１９５】
処理１８００：処理１１０８でホームゲートウェイＡ９２０から送信された障害情報を、障害情報受信部９０３が受信する。【０１９６】
処理１８０１：受信した障害情報を、障害情報受信部９０３が障害情報データベース９０４に格納する。【０１９７】
処理１８０２：障害対処方法決定部９０１が、障害情報設定テーブル９０２に障害発生ソフトウェアが異常なものとして記載されているかチェックする。【０１９８】
処理１８０３：処理１８０２で、もし障害発生ソフトウェアが異常なものとして判断されれば、障害対処方法送信部９０５から障害発生ソフトウェアが異常であるという情報をホームゲートウェイＡ９２０へ送信するとともに、その障害発生ソフトウェアが未だホームゲートウェイＡ９２０上で動作している場合は停止するよう同じく障害対処方法送信部９０５からホームゲートウェイＡ９２０へ命令を送信し、既に停止している場合はそのまま停止させておく。【０１９９】
尚、停止させるのが好ましくないソフトウェアである場合は、例えば、ポップアップ等でユーザに確認後に該ソフトウェアを再起動させるよう、障害対処方法送信部９０５からホームゲートウェイＡ９２０へ命令を送信してもよい。【０２００】
処理１８０４：障害対処方法決定部９０１が、障害情報設定テーブル９０２に記載されている、公開されてから現在までの経過日数に応じたソフトウェアが異常か否かを判定するための閾値と、障害情報データベース９０４に記載されている、ソフトウェア異常が起きたホームゲートウェイ台数の、該ソフトウェアが動作するホームゲートウェイ全体台数に対する割合と、を比較し、障害発生ソフトウェアが異常か否かを判定する。【０２０１】
処理１８０５：処理１８０４で、もし障害が発生したホームゲートウェイ台数の全体台数に対する割合が閾値を超え、障害発生ソフトウェアが異常であると判定されれば、障害対処方法送信部９０５から障害発生ソフトウェアが異常であるという情報をホームゲートウェイＡ９２０へ送信するとともに障害対処情報設定テーブル９０２に障害発生ソフトウェアは異常であると記載した後、その障害発生ソフトウェアが未だホームゲートウェイＡ９２０上で動作している場合は停止するよう同じく障害対処方法送信部９０５からホームゲートウェイＡ９２０へ命令を送信し、既に停止している場合はそのまま停止させておく。【０２０２】
尚、停止させるのが好ましくないソフトウェアである場合は、例えば、ポップアップ等でユーザに確認後に該ソフトウェアを再起動させるよう、障害対処方法送信部９０５からホームゲートウェイＡ９２０へ命令を送信してもよい。【０２０３】
処理１８０６：ホームゲートウェイ自体を再起動させるよう、障害対処方法送信部９０５からホームゲートウェイＡ９２０へ命令を送信する。【０２０４】
その他の処理に関しては、実施例４と同様である。【０２０５】
本実施例の効果として、実施例４と同様の効果を得られるが、もしホームゲートウェイのソフトウェア実行環境１２５がフレームワークを含まない構成であった場合は、本実施例の方法を用いる事で、フレームワークのチェックという余計な処理を省略する事で障害復旧のコストをより低く抑える事が出来る。
【産業上の利用可能性】
【０２０６】
以上、本発明を各実施形態に基づいて具体的に説明したが、本発明は、前述の各実施形態に限定されるものではなく、その要旨を逸脱しない範囲において種々の変更が可能である。特に、本発明の上記各実施例では被保守情報機器としてホームゲートウェイを挙げているが、ソフトウェアが動作し、かつ、それに係る保守を受ける情報機器・装置であれば、カーナビ、ＰＣ、スマートメータ等、機器・装置の種類を問わず多種多様な応用分野に適用出来る。
【符号の説明】
【０２０７】
１００  リモート保守サーバ装置
１０１  障害対処方法決定部
１０２  障害対処情報設定テーブル
１０３  障害情報受信部
１０４  障害情報データベース
１０５  障害対処方法送信部
１０６  ソフトウェア情報受信部
１１０  ソフトウェア配布サーバ装置
１１１  ソフトウェア登録部
１１２  配布ソフトウェア格納部
１１３  ソフトウェア配布部
１１４  ソフトウェア情報送信部
１２０  ホームゲートウェイＡ
１２１  障害情報収集部
１２２  障害情報送信部
１２３  障害情報格納部
１２４  ソフトウェア受信部
１２５  ソフトウェア実行環境
１２６  障害対処方法受信部
１２７  障害情報処理決定部
１２８  障害情報収集ボタン
１３０  情報家電端末装置
１４０  情報家電端末装置
１５０  情報家電端末装置
１６０  通信ネットワーク
１７０  ＬＡＮ
１８０  ホームゲートウェイＢ
１９０  ＬＡＮ
１９１  情報家電端末装置
１２５０  ソフトウェアモジュールＸ
１２５１  フレームワークＡ
１２５２  ソフトウェアモジュールＡ
１２５３  ソフトウェアモジュールＢ
１２５４  ソフトウェアモジュールＹ
１２５５  フレームワークＢ
１２５６  ソフトウェアモジュールＡ
１２５７  ソフトウェアモジュールＣ
９００  リモート保守サーバ装置
９０１  障害対処方法決定部
９０２  障害対処情報設定テーブル
９０３  障害情報受信部
９０４  障害情報データベース
９０５  障害対処方法送信部
９０６  ソフトウェア情報受信部
９１０  ソフトウェア配布サーバ装置
９１１  ソフトウェア登録部
９１２  配布ソフトウェア格納部
９１３  ソフトウェア配布部
９１４  ソフトウェア情報送信部
９２０  ホームゲートウェイＡ
９２１  障害情報収集部
９２２  障害情報送信部
９２３  障害情報データベース
９２４  ソフトウェア受信部
９２５  ソフトウェア実行環境
９２６  障害対処方法受信部
９２７  障害情報処理決定部
９２８  障害情報収集ボタン
９２９  障害対処情報設定テーブル
９３０  情報家電端末装置
９４０  情報家電端末装置
９５０  情報家電端末装置
９６０  通信ネットワーク
９７０  ＬＡＮ
９８０  ホームゲートウェイＢ
９９０  ＬＡＮ
９１００  情報家電端末装置
９２５０  ソフトウェアモジュールＸ
９２５１  フレームワークＡ
９２５２  ソフトウェアモジュールＡ
９２５３  ソフトウェアモジュールＢ
９２５４  ソフトウェアモジュールＹ
９２５５  フレームワークＢ
９２５６  ソフトウェアモジュールＡ
９２５７  ソフトウェアモジュールＣ
【図１】
0005395951.tif 000002
【図２】
0005395951.tif 000003
【図５】
0005395951.tif 000004
【図６】
0005395951.tif 000005
【図９】
0005395951.tif 000006
【図１０】
0005395951.tif 000007
【図１３】
0005395951.tif 000008
【図１４】
0005395951.tif 000009
【図１５】
0005395951.tif 000010
【図１６】
0005395951.tif 000011
【図３】
0005395951.tif 000012
【図４】
0005395951.tif 000013
【図７】
0005395951.tif 000014
【図８】
0005395951.tif 000015
【図１１】
0005395951.tif 000016
【図１２】
0005395951.tif 000017
【図１７】
0005395951.tif 000018
【図１８】
0005395951.tif 000019