複数のソフトウェアが複数の組み合わせで動作している保守対象のネットワーク装置において発生したソフトウェア障害に関わる障害情報を受信する障害情報受信部と、前記障害情報を記録する障害情報データベースと、前記障害情報に基づき前記障害発生ネットワーク機器の障害対処方法を決定する障害対処方法決定部と、前記障害対処方法決定部が障害対処方法を決定する際に参照する障害情報設定テーブルと、前記決定した障害対処方法を前記障害発生ネットワーク機器に送信する障害対処方法送信部とを備えることを特徴とするネットワーク機器。請求項1において、障害対処方法決定部が、障害発生ソフトウェアの障害発生回数が設定閾値を超えたか否かで、決定する障害対処方法を変更することを特徴とするネットワーク機器。請求項1において、障害対処方法決定部が、情報端末別に見た特定ソフトウェアの障害発生回数の最大値と最小値の商が設定閾値を超えたか否かで、決定する障害対処方法を変更することを特徴とするネットワーク機器。請求項1において、障害対処方法決定部が、障害発生ソフトウェアがフレームワークで動いているか否かで、決定する障害対処方法を変更することを特徴とするネットワーク機器。請求項1において、障害対処方法決定部が、障害発生ソフトウェアの重要度に応じて、決定する障害対処方法を変更することを特徴とするネットワーク機器。発生したソフトウェア障害の障害情報を収集する障害情報収集部と、前記障害情報を記録する障害情報データベースと、前記障害情報に基づき障害対処方法を決定する障害情報処理決定部と、前記障害情報処理決定部が障害対処方法を決定する際に参照する障害情報設定テーブルとを備える複数のソフトウェアが複数の組み合わせで動作することを特徴とするネットワーク装置。請求項6において、障害情報処理決定部が、障害発生ソフトウェアの障害発生回数が設定閾値を超えたか否かで、決定する障害対処方法を変更することを特徴とするネットワーク装置。請求項6において、障害情報収集部を動作させる契機を作る障害情報収集ボタンを更に備えることを特徴とするネットワーク装置。障害の保守には、監視検知対処復旧という3つのフェーズがあり、これを実行するために様々な技術の提案がなされている。まず、障害の監視検知についての従来技術について述べる。ホームネットワークといったLAN内に置かれた情報処理装置で発生した障害を監視検知し、インターネット等の通信ネットワークで繋がれた先に存在するリモート保守サーバに通知するといった、システムの保守を行う方式は、従来、例えば特許文献1で提案されている。しかし、該特許では、監視対象である情報処理装置で発生した障害に関わる情報をそのままの状態で保守サーバに送信する為、外部通信ネットワークの負荷や保守サーバにおける処理負荷の増大を招くという問題があった。この問題を解決したのが、特許文献2の提案方式である。この方式では、情報処理装置で発生した障害を選別してリモート保守サーバに送信する事で、上記問題を緩和出来た。次に、障害の対処復旧についての従来技術について述べる。障害の対処方法に関して、例えば特許文献3がある。この文献は、保守サービスを提供するネットワーク機器に通信ネットワークを介して同一構成である複数のネットワーク機器が接続され、保守を受けている状況下で、保守を受けるネットワーク機器でソフトウェア障害が発生した時に実施される障害復旧方法に関するものである。この文献によると、障害復旧のシナリオを纏めたテーブルを、保守サービスを提供するネットワーク機器に用意しておき、保守を受けるネットワーク機器で発生したソフトウェア障害を多く復旧する事が出来たシナリオの優先度が高くなるよう、動的に、テーブルに記述されているシナリオ毎の優先度を更新していく。そして、保守を受けるネットワーク機器で改めてソフトウェア障害が発生した際には、優先度の高いシナリオから順番に障害対処シナリオを適用していき、該障害から復旧させる、というものである。しかしながら、特許文献3の障害復旧方法では、多様なソフトウェアが多様な組み合わせで動作しているような保守を受けるネットワーク機器で発生したソフトウェア障害に対しては、その適用が困難であり、たとえ適用しても、該障害から復旧させるコストが高くなってしまうという問題があった。本発明の代表的なものの一例を示せば以下の通りである。すなわち、本発明のネットワーク機器は、複数のソフトウェアが複数の組み合わせで動作している保守対象のネットワーク装置において発生したソフトウェア障害に関わる障害情報を受信する障害情報受信部と、前記障害情報を記録する障害情報データベースと、前記障害情報に基づき前記障害発生ネットワーク機器の障害対処方法を決定する障害対処方法決定部と、前記障害対処方法決定部が障害対処方法を決定する際に参照する障害情報設定テーブルと、前記決定した障害対処方法を前記障害発生ネットワーク機器に送信する障害対処方法送信部とを備えることを特徴とする。また、本発明のネットワーク装置は、発生したソフトウェア障害の障害情報を収集する障害情報収集部と、前記障害情報を記録する障害情報データベースと、前記障害情報に基づき障害対処方法を決定する障害情報処理決定部と、前記障害情報処理決定部が障害対処方法を決定する際に参照する障害情報設定テーブルとを備える複数のソフトウェアが複数の組み合わせで動作することを特徴とする。本発明によれば、保守サービスを提供するためのネットワーク機器に少なくとも二台以上の複数の保守サービスを受けるネットワーク装置が通信ネットワークを介して接続され、そのそれぞれの保守サービスを受けるネットワーク装置において多様なソフトウェアが多様な組み合わせで動作している際に、ネットワーク機器でソフトウェア障害が発生した時、該障害発生ソフトウェアを該障害から低コストで復旧させる事が出来る。上記課題を解決する為に、本発明は以下の手段を有するものである。すなわち、本発明に係る保守サービスを提供するためのネットワーク機器において、通信ネットワークを介して接続される、多様な複数のソフトウェアが多様な組み合わせで動作している保守対象のネットワーク装置において発生したソフトウェア障害に関わる障害情報を受信する障害情報受信部と、前記障害情報を記録する障害情報データベースと、前記障害情報に基づき前記障害発生ネットワーク機器の障害対処方法を決定する障害対処方法決定部と、前記障害対処方法決定部が障害対処方法を決定する際に参照する障害情報設定テーブルと、前記決定した障害対処方法を前記障害発生ネットワーク機器に送信する障害対処方法送信部と、を備える事を特徴とする。上記課題を解決する為に、本発明は、また、以下の手段を有するものである。すなわち、本発明に係る保守サービスを提供するためのネットワーク機器において、通信ネットワークを介して接続される、多様な複数のソフトウェアが多様な組み合わせで動作している保守対象のネットワーク装置において発生したソフトウェア障害に関わる障害情報を受信する障害情報受信部と、前記障害情報を記録する障害情報データベースと、前記障害情報に基づき前記障害発生ネットワーク機器の障害対処方法を決定する障害対処方法決定部と、前記障害対処方法決定部が障害対処方法を決定する際に参照する障害情報設定テーブルと、前記決定した障害対処方法を前記障害発生ネットワーク機器に送信する障害対処方法送信部と、を備え、障害対処方法決定部が、障害発生ソフトウェアの障害発生回数が設定閾値を超えたか否かで、決定する障害対処方法を変更する事を特徴とする。上記課題を解決する為に、本発明は、また、以下の手段を有するものである。すなわち、本発明に係る保守サービスを提供するためのネットワーク機器において、通信ネットワークを介して接続される、多様な複数のソフトウェアが多様な組み合わせで動作している保守対象のネットワーク装置において発生したソフトウェア障害に関わる障害情報を受信する障害情報受信部と、前記障害情報を記録する障害情報データベースと、前記障害情報に基づき前記障害発生ネットワーク機器の障害対処方法を決定する障害対処方法決定部と、前記障害対処方法決定部が障害対処方法を決定する際に参照する障害情報設定テーブルと、前記決定した障害対処方法を前記障害発生ネットワーク機器に送信する障害対処方法送信部と、を備え、障害対処方法決定部が、情報端末別に見た特定ソフトウェアの障害発生回数の最大値と最小値の商が設定閾値を超えたか否かで、決定する障害対処方法を変更する事を特徴とする。上記課題を解決する為に、本発明は、また、以下の手段を有するものである。すなわち、本発明に係る保守サービスを提供するためのネットワーク機器において、通信ネットワークを介して接続される、多様な複数のソフトウェアが多様な組み合わせで動作している保守対象のネットワーク装置において発生したソフトウェア障害に関わる障害情報を受信する障害情報受信部と、前記障害情報を記録する障害情報データベースと、前記障害情報に基づき前記障害発生ネットワーク機器の障害対処方法を決定する障害対処方法決定部と、前記障害対処方法決定部が障害対処方法を決定する際に参照する障害情報設定テーブルと、前記決定した障害対処方法を前記障害発生ネットワーク機器に送信する障害対処方法送信部と、を備え、障害対処方法決定部が、障害発生ソフトウェアがフレームワークで動いているか否かで、決定する障害対処方法を変更する事を特徴とする。上記課題を解決する為に、本発明は、また、以下の手段を有するものである。すなわち、本発明に係る保守サービスを提供するためのネットワーク機器において、通信ネットワークを介して接続される、多様な複数のソフトウェアが多様な組み合わせで動作している保守対象のネットワーク装置において発生したソフトウェア障害に関わる障害情報を受信する障害情報受信部と、前記障害情報を記録する障害情報データベースと、前記障害情報に基づき前記障害発生ネットワーク機器の障害対処方法を決定する障害対処方法決定部と、前記障害対処方法決定部が障害対処方法を決定する際に参照する障害情報設定テーブルと、前記決定した障害対処方法を前記障害発生ネットワーク機器に送信する障害対処方法送信部と、を備え、障害対処方法決定部が、障害発生ソフトウェアの重要度に応じて、決定する障害対処方法を変更する事を特徴とする。上記課題を解決する為に、本発明は、また、以下の手段を有するものである。すなわち、多様な複数のソフトウェアが多様な組み合わせで動作している保守対象のネットワーク機器において、発生したソフトウェア障害の障害情報を収集する障害情報収集部と、前記障害情報を記録する障害情報データベースと、前記障害情報に基づき障害対処方法を決定する障害情報処理決定部と、前記障害情報処理決定部が障害対処方法を決定する際に参照する障害情報設定テーブルと、を備える。上記課題を解決する為に、本発明は、また、以下の手段を有するものである。すなわち、多様な複数のソフトウェアが多様な組み合わせで動作している保守対象のネットワーク機器において、発生したソフトウェア障害の障害情報を収集する障害情報収集部と、前記障害情報を記録する障害情報データベースと、前記障害情報に基づき障害対処方法を決定する障害情報処理決定部と、前記障害情報処理決定部が障害対処方法を決定する際に参照する障害情報設定テーブルと、を備え、障害情報処理決定部が、障害発生ソフトウェアの障害発生回数が設定閾値を超えたか否かで、決定する障害対処方法を変更する事を特徴とする。上記課題を解決する為に、本発明は、また、以下の手段を有するものである。すなわち、多様な複数のソフトウェアが多様な組み合わせで動作している保守対象のネットワーク機器において、発生したソフトウェア障害の障害情報を収集する障害情報収集部と、前記障害情報を記録する障害情報データベースと、前記障害情報に基づき障害対処方法を決定する障害情報処理決定部と、前記障害情報処理決定部が障害対処方法を決定する際に参照する障害情報設定テーブルと、を備え、更に障害情報収集部を動作させる契機を作る障害情報収集ボタンと、を備える事を特徴とする。以下、本発明によるシステム保守方式に関する一実施形態を図面により詳細に説明する。図1は、本発明における実施例1~3の概念図である。本概念図では、リモート保守サーバ装置100、ホームゲートウェイA120、及びホームゲートウェイB180と、を含む。リモート保守サーバ装置100、ホームゲートウェイA120、ホームゲートウェイB180の間は、例えば、インターネット等の通信ネットワーク160によって接続される。リモート保守サーバ装置100は、通信ネットワーク160で繋がれたホームゲートウェイで発生したソフトウェア障害のホームゲートウェイ毎の障害発生回数や、該障害発生回数の全ホームゲートウェイを纏めた総回数といった統計情報と、発生障害の対処方法を決定する障害対処方法決定部101を持つ。ホームゲートウェイA120は、フレームワークA1251やソフトウェアモジュール1250、1252、1253といったソフトウェアを実行するソフトウェア実行環境125、該実行環境125で動作するソフトウェアで発生した障害に関する障害情報、該障害情報をリモート保守サーバ装置100へ送信する障害情報送信部122と、を備える。ホームゲートウェイAに備わるソフトウェア実行環境125は、例えばJAVAの実行環境のような、ソフトウェアを実行する環境を示しており、該環境で動作するフレームワークA1251には、更に、該フレームワークA1251上でのみ動作するソフトウェアモジュール1252、1253が存在する。ホームゲートウェイB180は、フレームワークB1255やソフトウェアモジュール1254、1256、1257といったソフトウェアを実行するソフトウェア実行環境125、該実行環境125で動作するソフトウェアで発生した障害に関する障害情報、該障害情報をリモート保守サーバ装置100へ送信する障害情報送信部122と、を備える。ホームゲートウェイBに備わるソフトウェア実行環境125は、例えばJAVAの実行環境のような、ソフトウェアを実行する環境を示しており、該環境で動作するフレームワークB1255には、更に、該フレームワークB1255上でのみ動作するソフトウェアモジュール1256、1257が存在する。尚、本実施例では、ソフトウェアモジュールとフレームワーク、それらどちらもソフトウェアと呼ぶ。フレームワークは特定のソフトウェアモジュールを動作させるためのソフトウェアモジュールともいえる。上記した、ホームゲートウェイA120とホームゲートウェイB180に備わるフレームワークやソフトウェアモジュールに関し、複数の互いに異なるフレームワークやソフトウェアモジュールが、各ホームゲートウェイ各様にインストールされ、様々な組み合わせで動作している事を仮定する。尚、リモート保守サーバとホームゲートウェイの数は図示したものに限定されない。それでは、図1の障害復旧概念図を元に、ソフトウェア障害復旧の流れを簡単に説明する。ホームゲートウェイA120やホームゲートウェイB180で発生したソフトウェア障害は、障害情報として収集され、各ホームゲートウェイに備わる障害情報送信部122からリモート保守サーバ装置100へ送信される。リモート保守サーバ100に備わる障害対処方法決定部101は、通信ネットワーク160で繋がれた全てのホームゲートウェイから受信した障害の統計情報を用いて、障害の発生したそれぞれのホームゲートウェイに対する障害対処方法を決定した後、障害から復旧させる。ここで、ホームゲートウェイA120とホームゲートウェイB180のソフトウェア実行環境上で動作するソフトウェアとその組み合わせは互いに異なるものであってもよい事を改めて明記しておく。以上の概念を、具体的に説明していく。図2は、本発明の一実施例のシステム構成図である。一実施例として、情報処理システムは、リモート保守サーバ装置100、ソフトウェア配布サーバ装置110、ホームゲートウェイA120、ホームゲートウェイB180、情報家電端末装置130、140、150、191と、を含む。リモート保守サーバ装置100とソフトウェア配布サーバ装置110は、何れもプロバイダ側の管理下に置かれる。ホームゲートウェイA120、ホームゲートウェイB180、情報家電端末130、140、150、191は、何れもユーザ側の管理下に置かれる。上記情報処理システムでは、リモート保守サーバ装置100とホームゲートウェイA120、ホームゲートウェイB180の間、ソフトウェア配布サーバ装置110とホームゲートウェイA120、ホームゲートウェイB180の間が、例えば、インターネット等の通信ネットワーク160によって接続される。また、ホームゲートウェイA120と各情報家電端末130、140、150の間、またはホームゲートウェイB180と情報家電端末191の間が、例えば、ホームネットワークのようなLAN170、190によって接続されるものとする。実際のシステムでは、プロバイダは多数存在する上に、プロバイダが設置するリモート保守サーバ装置100やソフトウェア配布サーバ装置110の台数も1台とは限らない。また、ユーザ数も莫大な数であり、個々のユーザが所持するホームゲートウェイや情報家電装置の台数に関しても図示してある台数だけとは限らない。しかし、図2では、図示と説明の都合上、この台数に設定している。次に、上述したそれぞれの装置について詳細に解説する。プロバイダ側の装置であるリモート保守サーバ装置100は、障害対処方法決定部101と障害対処情報設定テーブル102と、障害情報受信部103と、障害情報データベース104と、障害対処方法送信部105と、ソフトウェア情報受信部106と、を内蔵する。障害対処決定部101は、通信ネットワーク160を経てホームゲートウェイ120、180にアクセスし、ホームゲートウェイ120、180で発生した障害情報を、障害情報受信部103で受信し、障害情報データベース104に格納する。格納した障害情報と、障害対処情報設定テーブル102の記載内容を元に、障害対処方法決定部101が障害対処方法を決定し、障害対処方法送信部105から障害の発生したホームゲートウェイに障害対処方法を送信する。ソフトウェア情報受信部106は、ソフトウェア配布サーバ装置110から送信されたソフトウェアに関する情報を受信する。尚、本実施例を含め全ての実施例において、ソフトウェア障害とは、ソフトウェアにバグが混入している事を起因として、もしくは様々なソフトウェアの組み合わせ方が起因となり、ソフトウェア製作者の意図と反した挙動をソフトウェアが行う事を指す。具体的には、ネットワーク機器のCPUやメモリなどのリソースをソフトウェア作成者の意図に反して大量に消費したり、特定のソフトウェアが動作している際に別の動作中ソフトウェアの挙動がおかしくなったりする事を指す。図5に、障害情報データベース104に格納された、ホームゲートウェイで発生した障害情報の一例を示す。本例では、ソフトウェア毎に障害情報を纏め、ソフトウェアの障害発生回数ホームゲートウェイ毎の障害発生回数、及び各ホームゲートウェイで発生した障害発生回数の和、公開されてから現在までの経過日数、ホームゲートウェイ別個別重要度ウェイト、といった情報を取り扱う事とした。個別重要度については後述する。尚、これらの情報は、ホームゲートウェイから送信される情報に含まれているとは限らず、リモート保守サーバ装置100が自身で作成更新したデータが含まれていても良い。図6に、障害対処情報設定テーブル102の一例を示す。該テーブルでは、リモート保守サーバ装置100からホームゲートウェイに送信される障害ソフトウェアの復旧方法を決定する際に参照する設定情報が記載されている。本例では、デフォルトの設定値とソフトウェア毎の設定値について記載している。項目として、異常なソフトウェアか否か、フレームワーク上で動くか否か、一般的重要度、及び、公開されてから現在までの経過日数に応じた二つ閾値のベース値を挙げた。一般的重要度とは、各ソフトウェアの特性に合わせた重要度である。止まると困るような重要なソフトウェアは優先度が高くなるように設定する。二つの閾値ベース値について説明する。1つ目は、再起動すれば直る程度の軽い異常か否かを判定するために用いる値であり、ソフトウェアが公開されてから現在までの経過日数に応じて変化させている。2つ目は、ソフトウェアが異常か否かを判定するために用いる値であり、ホームゲートウェイ単位で見た、該ソフトウェアの最大障害発生数と最小障害発生数の比を示す。こちらも、ソフトウェアが公開されてから現在までの経過日数に応じて変化させている。これらのベース値を設定しない場合は、対応する一般的優先度に応じたデフォルト値が使用される。プロバイダ側の装置であるソフトウェア配布サーバ装置110は、ホームゲートウェイ120、180に対し、新たなソフトウェアを配布したり、リモート保守サーバ装置100に対し、配布するソフトウェアの情報を送信したりするためのもので、ソフトウェア登録部111と、配布ソフトウェア格納部112と、ソフトウェア配布部113と、ソフトウェア情報送信部114と、を内蔵する。ソフトウェア登録部111は、ホームゲートウェイ120、180で動かすために新たに開発されたソフトウェアを配布ソフトウェア格納部112に登録するものである。また、ソフトウェア配布部113は、配布ソフトウェア格納部112に格納されたソフトウェアをホームゲートウェイ120、180に配布するものである。さらに、ソフトウェア情報送信部114は、ソフトウェア配布部113からホームゲートウェイ120、180へソフトウェアが配布される際に、リモート保守サーバ装置100に対してソフトウェア情報を送信するためのものであり、このソフトウェア情報として、ソフトウェアの名前、フレームワーク上で動くものか、一般的優先度、公開されてからの経過日数に応じた再起動すれば直る程度の軽い異常か否かを判定する第一の閾値のベース値、同じく公開されてからの経過日数に応じたソフトウェアが異常か否かを判定する第二の閾値のベース値といった情報を含む。尚、ソフトウェアをソフトウェア登録部111が配布ソフトウェア格納部112に格納する際に、ソフトウェア登録部111が該ソフトウェアに登録日時の情報を付加するものとする。ユーザ側の装置であるホームゲートウェイA120は、障害情報収集部121、障害情報送信部122、障害情報格納部123、ソフトウェア受信部124、ソフトウェア実行環境125、障害対処方法受信部126、障害情報処理決定部127、障害情報収集ボタン128と、を内蔵する、ルータ機能を備えた装置である。障害情報収集ボタン128は無くても構わない。ソフトウェア実行環境125は、例えばJAVAの実行環境のような、ソフトウェアを実行する環境を示しており、該環境ではソフトウェアモジュールX1250やフレームワークA1251等のソフトウェアが動作する。更に、該フレームワークA1251上でのみ動作するソフトウェアモジュール1252、1253が存在する。尚、ソフトウェア実行環境125で動作するソフトウェアモジュールやフレームワークの種類や数は、図示したものに限定される事はない。ホームゲートウェイB180もホームゲートウェイA120と同様の機能を備えるが、図1では簡単の為にその大部分の機能を省略している。ホームゲートウェイB180がホームゲートウェイA120と違う部分は、ソフトウェア実行環境125で動作するソフトウェアである。ホームゲートウェイB180で動作するソフトウェア実行環境125は、例えばJAVAの実行環境のような、ソフトウェアを実行する環境を示しており、該環境ではソフトウェアモジュールY1254やフレームワークB1255等のソフトウェアが動作する。更に、該フレームワークB1255上でのみ動作するソフトウェアモジュール1256、1257が存在する。尚、ソフトウェア実行環境125で動作するソフトウェアモジュールやフレームワークの種類や数は、図示したものに限定される事はない。障害情報収集部121は、ソフトウェア配布サーバ装置110から配布され、ソフトウェア受信部124で受信したソフトウェアを実行中に発生した障害情報を収集するもので、収集された障害情報は、障害情報格納部123に格納される。この障害情報は、障害情報処理決定部127が決定した任意の時に、障害情報送信部122を用いてリモート保守サーバ装置100に送信される。障害対処方法受信部126は、リモート保守サーバ装置100から送信される障害対処方法を受信する。情報家電端末装置は、例えばTVテレビ、DVDレコーダプレーヤ、PCパーソナルコンピュータ、冷蔵庫、電球等の、家電を含めたネットワーク機器全般を指す。図3に、図2記載のホームゲートウェイA120が、リモート保守サーバ装置100に対して障害情報を送信する際の一例を示すフローチャートを示す。処理300:障害情報処理決定部127は、ソフトウェアが正常に動作している時は待機している。処理301:ソフトウェアで障害が発生すると、障害情報処理決定部127が処理を開始する。処理302:障害情報収集部121が、発生した障害の情報を収集し、収集した障害情報を障害情報格納部123に格納する。尚、本フロー例にあるように障害が発生したときのみに障害情報収集部121が障害収集を開始するのではなく、例えば、図6のように、ホームゲートウェイA120に備わる障害情報収集ボタン128を押す事等を契機として障害情報収集部121が障害情報の収集を開始してもよい。処理303:障害情報処理決定部127が、収集した障害情報をサーバに送信するか否かを決定する。この、障害情報を送信するか否かに際し、障害情報を収集する度に送信してもよいし、特許文献2に記載されているように、障害レベルが高い時等、特別な時のみに送信してもよい。もし、送信しない場合には障害情報処理決定部127は待機状態に戻る。処理304:処理303で収集した障害情報を送信する事を決定した際は、障害情報送信部122から障害情報を送信する。図4に、図1記載のリモート保守サーバ100が、ソフトウェア障害が発生したホームゲートウェイA120に対して障害対処方法を送信する際の一例を示すフローチャートを示す。処理400:処理304でホームゲートウェイA120から送信された障害情報を、障害情報受信部103が受信する。処理401:受信した障害情報を、障害情報受信部103が障害情報データベース104に格納する。処理402:障害情報データベース104の中の、障害の発生したソフトウェアの障害発生回数を1増やす。処理403:障害の発生したソフトウェアが障害対処情報設定テーブル102の中で異常なソフトウェアとして登録されているか否か、障害対処方法決定部101がチェックする。処理404:処理403において、障害発生ソフトウェアが異常なソフトウェアとして登録されていた場合、その障害発生ソフトウェアが未だホームゲートウェイA120上で動作している場合は停止するよう障害対処方法送信部105からホームゲートウェイA120へ命令を送信し、既に停止している場合はそのまま停止させておく。尚、停止させるのが好ましくないソフトウェアである場合は、例えば、ポップアップ等でユーザに確認後に該ソフトウェアを再起動させるよう、障害対処方法送信部105からホームゲートウェイA120へ命令を送信してもよい。処理405:処理403において、障害発生ソフトウェアが異常なソフトウェアとして登録されていなかった場合、障害発生ソフトウェアの障害発生数が、再起動すれば直る程度の軽い異常か否かを判定する第一の閾値を超えたか否かを、障害対処方法決定部101がチェックする。本実施例では、障害対処情報設定テーブル102に記載されている第一の閾値ベース値と、障害情報データベース104に記載されている個別重要度ウェイトの積を第一の閾値として用いる。尚、障害対処情報設定テーブル102に前者のベース値がない場合は、設定されている一般重要度と、障害発生ソフトウェアが公開されてから現在までの経過日数に応じたデフォルトの値を用いる。また、障害情報データベース104に後者の値がない場合は、ウェイトを1とする。リモート保守サーバ装置100の処理負荷が高い場合、もしくは処理負荷を出来得る限り抑えたいと考えるときには、障害対処情報設定テーブル102に記載されている第一の閾値ベース値をそのまま、第一の閾値として扱っても良い。処理405は、発生した障害が、再起動させれば直る程度の軽い異常か否かを判別するためのものであり、方法は上記に限定されるものではない。処理406:処理405において、障害発生数が第一の閾値を超えていない場合、障害発生ソフトウェアを再起動させるよう、障害対処方法送信部105からホームゲートウェイA120へ命令を送信する。処理407:処理405において、障害発生数が第一の閾値を超えている場合、障害情報データベース104に記載されているホームゲートウェイ毎に見た障害発生ソフトウェアの障害発生数の最大数と最小数の比が、ソフトウェアが異常か否かを判定する第二の閾値を超えたか否か、を障害対処方法決定部101がチェックする。この際、障害発生最小数が0の場合は1として計算する。本実施例では、障害対処情報設定テーブル102に記載されている第二の閾値ベース値と、障害情報データベース104に記載されている個別重要度ウェイトの積を第二の閾値として用いる。尚、障害対処情報設定テーブル102に前者のベース値がない場合は、設定されている一般重要度と、障害発生ソフトウェアが公開されてから現在までの経過日数に応じたデフォルトの値を用いる。また、障害情報データベース104に後者の値がない場合は、ウェイトを1とする。リモート保守サーバ装置100の処理負荷が高い場合、もしくは処理負荷を出来得る限り抑えたいと考えるときには、障害対処情報設定テーブル102に記載されている第二の閾値ベース値をそのまま、第二の閾値として扱っても良い。処理407は、発生した障害の原因が、ソフトウェア自体にあるものか、それ以外にあるかを切り分ける為に行うものであり、方法は上記に限定されるものではない。処理408:処理407において、第二の閾値を超えていない場合、障害対処情報設定テーブル102に障害発生ソフトウェアが異常であると登録した後、その障害発生ソフトウェアが未だホームゲートウェイA120上で動作している場合は停止するよう障害対処方法送信部105からホームゲートウェイA120へ命令を送信し、既に停止している場合はそのまま停止させておく。尚、停止させるのが好ましくないソフトウェアである場合は、例えば、ポップアップ等でユーザに確認後に該ソフトウェアを再起動させるよう、障害対処方法送信部105からホームゲートウェイA120へ命令を送信してもよい。処理409:処理407において、第二の閾値を超えている場合、障害発生ソフトウェアがフレームワーク上で動いているか否かを、障害対処方法決定部101が障害対処情報設定テーブル102に記載されている内容を見てチェックする。これは、ソフトウェア起因ではない事が判明した障害発生の原因が、ソフトウェアが動くフレームワークにあるものかその他の理由によるものかを切り分ける為に行うものである。処理410:処理409において、障害発生ソフトウェアがフレームワーク上で動作しない事が判明した場合、ホームゲートウェイ自体を再起動させるよう、障害対処方法送信部105からホームゲートウェイA120へ命令を送信する。処理411:処理409において、障害発生ソフトウェアがフレームワーク上で動作する事が判明した場合、このフレームワークを障害発生ソフトウェアとして、処理401から処理を再開する。本実施例の効果として、多様なソフトウェアが多様に組み合わさって動作するホームゲートウェイでも、リモート保守サーバ装置100を活用して複数のホームゲートウェイからソフトウェア毎の障害情報を収集してそれを活用する事でソフトウェア、フレームワーク、その他の三つに障害発生原因を切り分ける事ができ、またそれに加えて、障害から復旧させる際に閾値を判断の基準としたロジックを実施する事で障害からの復旧を低コストで行う事ができる。また、本実施例では、障害保守に関し、リモート保守サーバ装置100に障害が発生した時の対処方法を決定する機能を持たせた。これは、多数のホームゲートウェイで起きた障害を、纏めてサーバで保守する事を可能とするが、通信ネットワークの負荷が高い時や、通信ネットワークの異常時に対応する為に、今回説明したリモート保守サーバ装置100の機能をホームゲートウェイ側に一部実装する事も可能である。これに関しては、実施例4~6で一例を説明する。実施例1では、障害が発生した時のみに障害発生ソフトウェアの障害情報を収集するものとしたが、もしホームゲートウェイA120に障害情報収集ボタン128やそれに類するものが備わっている場合は、それを押下する事を契機として障害情報収集を開始してもよい。図7に、図2記載のホームゲートウェイA120が、リモート保守サーバ装置100に対して障害情報を送信する際の一例を示すフローチャートを示す。処理700:障害情報処理決定部127は、ソフトウェアが正常に動作している時は待機している。処理701:ホームゲートウェイA120に備わる障害情報収集ボタン128が押下されると、障害情報処理決定部127が処理を開始する。処理702:障害情報収集部121が、発生した障害の情報を収集し、収集した障害情報を障害情報格納部123に格納する。処理703:障害情報処理決定部127が、収集した障害情報から、ホームゲートウェイA120でソフトウェア障害が発生したか否かを判定する。もし障害が発生していないと判定した場合は、障害情報処理決定部127は待機状態に戻る。処理704:処理703において、障害情報処理決定部127がホームゲートウェイA120でソフトウェア障害が発生していると判定した場合は、同じく障害情報処理決定部127が、収集した障害情報をリモート保守サーバ装置100に送信するか否かを決定する。この、障害情報を送信するか否かに際し、障害情報を収集する度に送信してもよいし、特許文献2に記載されているように、障害レベルが高い時等、特別な時のみに送信してもよい。もし、送信しない場合には障害情報処理決定部127は待機状態に戻る。処理705:処理704で収集した障害情報を送信する事を決定した際は、障害情報送信部122から障害情報を送信する。その他の処理に関しては、実施例1と同様である。本実施例の効果として、実施例1と同様の効果に加え、ホームゲートウェイに備わる障害情報収集ボタン128を契機として障害発生の診断や復旧をユーザ自ら実施できる点で、よりアクティブで自由な障害復旧を行う事が出来る。実施例1では、障害発生ソフトウェアがフレームワーク上で動作するか否か分からない場合を想定しているが、フレームワーク上で動作しないと予め分かっている場合は、図4の処理を図8に示すように短縮してもよい。図8に、図2記載のリモート保守サーバ100が、ソフトウェア障害が発生したホームゲートウェイA120に対して障害対処方法を送信する際の一例を示すフローチャートを示す。処理800:処理304でホームゲートウェイA120から送信された障害情報を、障害情報受信部103が受信する。処理801:受信した障害情報を、障害情報受信部103が障害情報データベース104に格納する。処理802:障害情報データベース104の中の、障害の発生したソフトウェアの障害発生回数を1増やす。処理803:障害の発生したソフトウェアが障害対処情報設定テーブル102の中で異常なソフトウェアとして登録されているか否か、障害対処方法決定部101がチェックする。処理804:処理803において、障害発生ソフトウェアが異常なソフトウェアとして登録されていた場合、その障害発生ソフトウェアが未だホームゲートウェイA120上で動作している場合は停止するよう障害対処方法送信部105からホームゲートウェイA120へ命令を送信し、既に停止している場合はそのまま停止させておく。尚、停止させるのが好ましくないソフトウェアである場合は、例えば、ポップアップ等でユーザに確認後に該ソフトウェアを再起動させるよう、障害対処方法送信部105からホームゲートウェイA120へ命令を送信してもよい。処理805:処理803において、障害発生ソフトウェアが異常なソフトウェアとして登録されていなかった場合、障害発生ソフトウェアの障害発生数が、再起動すれば直る程度の軽い異常か否かを判定する第一の閾値を超えたか否かを、障害対処方法決定部101がチェックする。本実施例では、障害対処情報設定テーブル102に記載されている第一の閾値ベース値と、障害情報データベース104に記載されている個別重要度ウェイトの積を第一の閾値として用いる。尚、障害対処情報設定テーブル102に前者のベース値がない場合は、設定されている一般重要度と、障害発生ソフトウェアが公開されてから現在までの経過日数に応じたデフォルトの値を用いる。また、障害情報データベース104に後者の値がない場合は、ウェイトを1とする。リモート保守サーバ装置100の処理負荷が高い場合、もしくは処理負荷を出来得る限り抑えたいと考えるときには、障害対処情報設定テーブル102に記載されている第一の閾値ベース値をそのまま、第一の閾値として扱っても良い。処理805は、発生した障害が、再起動させれば直る程度の軽い異常か否かを判別するためのものであり、方法は上記に限定されるものではない。処理806:処理805において、障害発生数が第一の閾値を超えていない場合、障害発生ソフトウェアを再起動させるよう、障害対処方法送信部105からホームゲートウェイA120へ命令を送信する。処理807:処理805において、障害発生数が第一の閾値を超えている場合、障害情報データベース104に記載されているホームゲートウェイ毎に見た障害発生ソフトウェアの障害発生数の最大数と最小数の比が、ソフトウェアが異常か否かを判定する第二の閾値を超えたか否か、を障害対処方法決定部101がチェックする。この際、障害発生最小数が0の場合は1として計算する。本実施例では、障害対処情報設定テーブル102に記載されている第二の閾値ベース値と、障害情報データベース104に記載されている個別重要度ウェイトの積を第二の閾値として用いる。尚、障害対処情報設定テーブル102に前者のベース値がない場合は、設定されている一般重要度と、障害発生ソフトウェアが公開されてから現在までの経過日数に応じたデフォルトの値を用いる。また、障害情報データベース104に後者の値がない場合は、ウェイトを1とする。リモート保守サーバ装置100の処理負荷が高い場合、もしくは処理負荷を出来得る限り抑えたいと考えるときには、障害対処情報設定テーブル102に記載されている第二の閾値ベース値をそのまま、第二の閾値として扱っても良い。処理807は、発生した障害の原因が、ソフトウェア自体にあるものか、それ以外にあるかを切り分ける為に行うものであり、方法は上記に限定されるものではない。処理808:処理807において、第二の閾値を超えていない場合、障害対処情報設定テーブル102に障害発生ソフトウェアが異常であると登録した後、その障害発生ソフトウェアが未だホームゲートウェイA120上で動作している場合は停止するよう障害対処方法送信部105からホームゲートウェイA120へ命令を送信し、既に停止している場合はそのまま停止させておく。尚、停止させるのが好ましくないソフトウェアである場合は、例えば、ポップアップ等でユーザに確認後に該ソフトウェアを再起動させるよう、障害対処方法送信部105からホームゲートウェイA120へ命令を送信してもよい。処理809:処理807において、第二の閾値を超えている場合、ホームゲートウェイ自体を再起動させるよう、障害対処方法送信部105からホームゲートウェイA120へ命令を送信する。その他の処理に関しては、実施例1と同様である。本実施例の効果として、実施例1と同様の効果を得られるが、もしホームゲートウェイのソフトウェア実行環境125がフレームワークを含まない構成であった場合は、本実施例の方法を用いる事で、フレームワークのチェックという余計な処理を省略する事で障害復旧のコストをより低く抑える事が出来る。実施例1~3においては、ソフトウェア障害の発生回数カウントはリモート保守サーバ装置100で行うようにしているが、このカウンタを備えるのはリモート保守サーバ100に限らず、ホームゲートウェイA120側に備える事も可能である。実施例4では、カウンタをホームゲートウェイA120に備えた場合の一実施例について述べる。図9は、本発明における実施例4~6の概念図である。本概念図では、リモート保守サーバ装置900、ホームゲートウェイA920、及びホームゲートウェイB980と、を含む。リモート保守サーバ装置900、ホームゲートウェイA920、ホームゲートウェイB980の間は、例えば、インターネット等の通信ネットワーク960によって接続される。リモート保守サーバ装置900は、通信ネットワーク960で繋がれたあるホームゲートウェイで発生したソフトウェア障害が、該ソフトウェアがインストールされているホームゲートウェイ全体中の何パーセントのホームゲートウェイで起こっているかといった統計情報と、発生障害の対処方法を決定する障害対処方法決定部901を持つ。ホームゲートウェイA920は、フレームワークA9251やソフトウェアモジュール9250、9252、9253といったソフトウェアを実行するソフトウェア実行環境925、該実行環境925で動作するソフトウェアで発生した障害に関する障害情報、該障害情報をもとに障害対処方法を決定する障害情報処理決定部927、該障害情報をリモート保守サーバ装置900へ送信する障害情報送信部922と、を備える。ホームゲートウェイAに備わるソフトウェア実行環境925は、例えばJAVAの実行環境のような、ソフトウェアを実行する環境を示しており、該環境で動作するフレームワークA9251には、更に、該フレームワークA9251上でのみ動作するソフトウェアモジュール9252、9253が存在する。ホームゲートウェイB980は、フレームワークB9255やソフトウェアモジュール9254、9256、9257といったソフトウェアを実行するソフトウェア実行環境925、該実行環境925で動作するソフトウェアで発生した障害に関する障害情報、該障害情報をもとに障害対処方法を決定する障害情報処理決定部927、該障害情報をリモート保守サーバ装置900へ送信する障害情報送信部922と、を備える。ホームゲートウェイBに備わるソフトウェア実行環境925は、例えばJAVAの実行環境のような、ソフトウェアを実行する環境を示しており、該環境で動作するフレームワークB9255には、更に、該フレームワークB9255上でのみ動作するソフトウェアモジュール9256、9257が存在する。尚、本実施例では、ソフトウェアモジュールとフレームワーク、それらどちらもソフトウェアと呼ぶ。上記した、ホームゲートウェイA920とホームゲートウェイB980に備わるフレームワークやソフトウェアモジュールに関し、複数の互いに異なるフレームワークやソフトウェアモジュールが、各ホームゲートウェイ各様にインストールされ、様々な組み合わせで動作している事を仮定する。尚、リモート保守サーバとホームゲートウェイの数は図示したもののみに限定されない。以上の概念を、具体的に説明していく。図10は、本発明の一実施例のシステム構成図である。一実施例として、情報処理システムは、リモート保守サーバ装置900、ソフトウェア配布サーバ装置910、ホームゲートウェイA920、ホームゲートウェイB980、情報家電端末装置930、940、950、9100と、を含む。リモート保守サーバ装置900とソフトウェア配布サーバ装置910は、何れもプロバイダ側の管理下に置かれる。ホームゲートウェイA920、ホームゲートウェイB980、情報家電端末930、940、950、9100は、何れもユーザ側の管理下に置かれる。上記情報処理システムでは、リモート保守サーバ装置900とホームゲートウェイA920、ホームゲートウェイB980の間、ソフトウェア配布サーバ装置910とホームゲートウェイA920、ホームゲートウェイB980の間が、例えば、インターネット等の通信ネットワーク960によって接続される。また、ホームゲートウェイA920と各情報家電端末930、940、950の間、またはホームゲートウェイB980と情報家電端末9100の間が、例えば、ホームネットワークのようなLAN970、990によって接続されるものとする。実際のシステムでは、プロバイダは多数存在する上に、プロバイダが設置するリモート保守サーバ装置900やソフトウェア配布サーバ装置910の台数も1台とは限らない。また、ユーザ数も莫大な数であり、個々のユーザが所持するホームゲートウェイや情報家電装置の台数に関しても図示してある台数だけとは限らない。しかし、図10では、図示と説明の都合上、この台数に設定している。次に、上述したそれぞれの装置について詳細に解説する。プロバイダ側の装置であるリモート保守サーバ装置900は、障害対処方法決定部901と障害対処情報設定テーブル902と、障害情報受信部903と、障害情報データベース904と、障害対処方法送信部905と、ソフトウェア情報受信部906と、を内蔵する。障害対処決定部901は、通信ネットワーク960を経てホームゲートウェイ920、980にアクセスし、ホームゲートウェイ920、980で発生した障害情報を、障害情報受信部903で受信し、障害情報データベース904に格納する。格納した障害情報と、障害対処情報設定テーブル902の記載内容を元に、障害対処方法決定部901が障害対処方法を決定し、障害対処方法送信部905から障害の発生したホームゲートウェイに障害対処方法を送信する。ソフトウェア情報受信部906は、ソフトウェア配布サーバ装置910から送信されたソフトウェアに関する情報を受信する。図13に、障害情報データベース904に格納された、ホームゲートウェイで発生した障害情報の一例を示す。本例では、ソフトウェア毎に障害情報を纏め、該ソフトウェアが動作しているホームゲートウェイの全体台数、該ソフトウェアに異常が起きたホームゲートウェイの台数、該ソフトウェアが動作しているホームゲートウェイ全体の台数に対する該ソフトウェアに異常が起きたホームゲートウェイの台数のパーセンテージ、公開されてから現在までの経過日数、といった情報を取り扱う事とした。尚、これらの情報は、ホームゲートウェイから送信される情報に含まれているとは限らず、リモート保守サーバ装置900が自身で作成更新したデータが含まれていても良い。図14に、障害対処情報設定テーブル902の一例を示す。該テーブルでは、リモート保守サーバ装置900からホームゲートウェイに送信される障害ソフトウェアの復旧方法を決定する際に参照する設定情報が記載されている。本例では、デフォルトの設定値とソフトウェア毎の設定値について記載している。項目として、異常なソフトウェアか否か、フレームワーク上で動くか否か、及び、公開されてから現在までの経過日数に応じた、ソフトウェアが異常か否かを判定するために用いる閾値を挙げた。この閾値は、障害が発生したソフトウェアが動作しているホームゲートウェイ全体の台数に対する、該ソフトウェアに異常が起きたホームゲートウェイの台数のパーセンテージである。この値は、ソフトウェアが公開されてから現在までの経過日数に応じて変化させている。この値を設定しない場合は、デフォルト値が使用される。プロバイダ側の装置であるソフトウェア配布サーバ装置910は、ホームゲートウェイ920、980に対し、新たなソフトウェアを配布したり、リモート保守サーバ装置900に対し、配布するソフトウェアの情報を送信したりするためのもので、ソフトウェア登録部911と、配布ソフトウェア格納部912と、ソフトウェア配布部913と、ソフトウェア情報送信部914と、を内蔵する。ソフトウェア登録部911は、ホームゲートウェイ920、980で動かすために新たに開発されたソフトウェアを配布ソフトウェア格納部912に登録するものである。また、ソフトウェア配布部913は、配布ソフトウェア格納部912に格納されたソフトウェアをホームゲートウェイ920、980に配布するものである。さらに、ソフトウェア情報送信部914は、ソフトウェア配布部913からホームゲートウェイ920、980へソフトウェアが配布される際に、リモート保守サーバ装置900に対してソフトウェア情報を送信するためのものであり、このソフトウェア情報として、ソフトウェアの名前、フレームワーク上で動くものか、ソフトウェアが公開されてからの経過日数に応じたソフトウェアが異常か否かを判定する閾値といった情報を含む。尚、ソフトウェアをソフトウェア登録部911が配布ソフトウェア格納部912に格納する際に、ソフトウェア登録部911が該ソフトウェアに登録日時の情報を付加するものとする。ユーザ側の装置であるホームゲートウェイA920は、障害情報収集部921、障害情報送信部922、障害情報データベース923、ソフトウェア受信部924、ソフトウェア実行環境925、障害対処方法受信部926、障害情報処理決定部927、障害情報収集ボタン928、障害対処情報設定テーブル929と、を内蔵する、ルータ機能を備えた装置である。障害情報収集ボタン928は無くても構わない。ソフトウェア実行環境925は、例えばJAVAの実行環境のような、ソフトウェアを実行する環境を示しており、該環境ではソフトウェアモジュールX9250やフレームワークA9251等のソフトウェアが動作する。更に、該フレームワークA9251上でのみ動作するソフトウェアモジュール9252、9253が存在する。尚、ソフトウェア実行環境925で動作するソフトウェアモジュールやフレームワークの種類や数は、図示したものに限定される事はない。ホームゲートウェイB980もホームゲートウェイA920と同様の機能を備えるが、図10では簡単の為にその大部分の機能を省略している。ホームゲートウェイB980がホームゲートウェイA920と違う部分は、ソフトウェア実行環境925で動作するソフトウェアである。ホームゲートウェイB980で動作するソフトウェア実行環境925は、例えばJAVAの実行環境のような、ソフトウェアを実行する環境を示しており、該環境ではソフトウェアモジュールY9254やフレームワークB9255等のソフトウェアが動作する。更に、該フレームワークB9255上でのみ動作するソフトウェアモジュール9256、9257が存在する。尚、ソフトウェア実行環境925で動作するソフトウェアモジュールやフレームワークの種類や数は、図示したものに限定される事はない。障害情報収集部921は、ソフトウェア配布サーバ装置910から配布され、ソフトウェア受信部924で受信したソフトウェアを実行中に発生した障害情報を収集するもので、収集された障害情報は、障害情報データベース923に格納される。障害情報処理決定部927は、障害情報データベース923と障害対処情報設定テーブル929の情報を元に、一定回数、障害からの復旧を自ら試みるが、一定回数以上に該ソフトウェアにおいて障害が発生した場合は、障害情報処理決定部927が決定した任意の時に、障害情報送信部922を用いてリモート保守サーバ装置900に障害情報を送信する。障害対処方法受信部926は、リモート保守サーバ装置900から送信される障害対処方法を受信する。図15に、障害情報データベース923の一例を示す。該テーブルは、ソフトウェア毎に管理され、例えば、障害発生回数、公開されてから現在までの経過日数と、を含むものとする。図16に、障害対処情報設定テーブル929の一例を示す。該テーブルは、ソフトウェア毎に管理され、例えば、異常なソフトウェアか否か、フレームワーク上で動くか否か、及び公開されてから現在までの経過日数に応じた、再起動すれば直る程度の軽い異常か否かを判定する閾値と、を含むものとする。情報家電端末装置は、例えばTVテレビ、DVDレコーダプレーヤ、PCパーソナルコンピュータ、冷蔵庫、電球等の、家電を含めたネットワーク機器全般を指す。図11に、図10記載のホームゲートウェイA920が、再起動すれば直る程度の軽い異常である場合は再起動させ、そうでない場合はリモート保守サーバ装置900に対して障害情報を送信する際の一例を示すフローチャートを示す。処理1100:障害情報処理決定部927は、ソフトウェアが正常に動作している時は待機している。処理1101:ソフトウェアに障害が発生すると、障害情報処理決定部927が処理を開始する。処理1102:障害の発生したソフトウェアが障害対処情報設定テーブル929の中で異常なソフトウェアとして登録されているか否か、障害情報処理決定部927がチェックする。処理1103:処理1102において、障害発生ソフトウェアが異常なソフトウェアとして登録されていた場合、その障害発生ソフトウェアが未だホームゲートウェイA920上で動作している場合は停止するよう障害情報処理決定部927が命令し、既に停止している場合はそのまま停止させておく。尚、停止させるのが好ましくないソフトウェアである場合は、例えば、ポップアップ等でユーザに確認後に該ソフトウェアを再起動させるよう、障害情報処理決定部927が命令してもよい。処理1104:処理1102において、障害発生ソフトウェアが異常なソフトウェアとして登録されていなかった場合、障害情報収集部921が、発生した障害の情報を収集し、収集した障害情報を障害情報データベース923に格納する。処理1105:障害情報データベース923の中の、障害の発生したソフトウェアの障害発生回数を1増やす。処理1106:障害発生ソフトウェアが再起動すれば直る程度の軽い異常か否かを、障害情報処理決定部927がチェックする。本実施例では、障害対処情報設定テーブル929に記載されている、公開されてから現在までの経過日数に応じた障害発生回数の閾値と、障害情報データベー9823に記載されている、障害発生回数との比較により、これを行う。処理1106は、発生した障害が、再起動させれば直る程度の軽い異常か否かを判別するためのものであり、方法は上記に限定されるものではない。処理1107:もし処理1106において、障害発生ソフトウェアの障害発生回数が閾値を越えなかった場合は、障害情報処理決定部927は、障害が発生したソフトウェアを再起動させる。処理1108:障害情報送信部922から障害情報を送信する。図12に、図10記載のリモート保守サーバ900が、ソフトウェア障害が発生したホームゲートウェイA920に対して障害対処方法を送信する際の一例を示すフローチャートを示す。処理1200:処理1108でホームゲートウェイ920から送信された障害情報を、障害情報受信部903が受信する。処理1201:受信した障害情報を、障害情報受信部903が障害情報データベース904に格納する。処理1202:障害対処方法決定部901が、障害情報設定テーブル902に障害発生ソフトウェアが異常なものとして記載されているかチェックする。処理1203:処理1202で、もし障害発生ソフトウェアが異常なものとして判断されれば、障害対処方法送信部905から障害発生ソフトウェアが異常であるという情報をホームゲートウェイA920へ送信するとともに、その障害発生ソフトウェアが未だホームゲートウェイA920上で動作している場合は停止するよう同じく障害対処方法送信部905からホームゲートウェイA920へ命令を送信し、既に停止している場合はそのまま停止させておく。尚、停止させるのが好ましくないソフトウェアである場合は、例えば、ポップアップ等でユーザに確認後に該ソフトウェアを再起動させるよう、障害対処方法送信部905からホームゲートウェイA920へ命令を送信してもよい。処理1204:障害対処方法決定部901が、障害情報設定テーブル902に記載されている、公開されてから現在までの経過日数に応じたソフトウェアが異常か否かを判定するための閾値と、障害情報データベース904に記載されている、ソフトウェア異常が起きたホームゲートウェイ台数の、該ソフトウェアが動作するホームゲートウェイ全体台数に対する割合と、を比較し、障害発生ソフトウェアが異常か否かを判定する。処理1205:処理1204で、もし障害が発生したホームゲートウェイ台数の全体台数に対する割合が閾値を超え、障害発生ソフトウェアが異常であると判定されれば、障害対処方法送信部905から障害発生ソフトウェアが異常であるという情報をホームゲートウェイA920へ送信するとともに障害対処情報設定テーブル902に障害発生ソフトウェアは異常であると記載した後、その障害発生ソフトウェアが未だホームゲートウェイA920上で動作している場合は停止するよう同じく障害対処方法送信部905からホームゲートウェイA920へ命令を送信し、既に停止している場合はそのまま停止させておく。尚、停止させるのが好ましくないソフトウェアである場合は、例えば、ポップアップ等でユーザに確認後に該ソフトウェアを再起動させるよう、障害対処方法送信部905からホームゲートウェイA920へ命令を送信してもよい。処理1206:障害発生ソフトウェアがフレームワーク上で動いているか否かを、障害対処方法決定部901が障害対処情報設定テーブル902に記載されている内容を見てチェックする。これは、ソフトウェア起因ではない事が判明した障害発生の原因が、ソフトウェアが動くフレームワークにあるものかその他の理由によるものかを切り分ける為に行うものである。処理1207:処理1206において、障害発生ソフトウェアがフレームワーク上で動作しない事が判明した場合、ホームゲートウェイ自体を再起動させるよう、障害対処方法送信部905からホームゲートウェイA920へ命令を送信する。処理1208:処理1206において、障害発生ソフトウェアがフレームワーク上で動作する事が判明した場合、このフレームワークを障害発生ソフトウェアとして、処理1101から処理を再開するよう、障害対処方法送信部905からホームゲートウェイA920へ命令を送信する。本実施例の効果として、実施例1と同様の効果が得られるが、実施例1のリモート保守サーバ装置100が備える障害復旧のための処理を一部ホームゲートウェイ自身に持たせる事で、ホームゲートウェイとリモート保守サーバ装置100間の通信ネットワークの負荷を下げる事ができ、また通信ネットワークを介さない障害復旧を行う事で、より低コストに障害復旧出来る。また、これにより、通信ネットワークの異常時にも障害からの復旧が可能となる。実施例4では、障害が発生した時のみにソフトウェアの障害情報を収集するものとしたが、もしホームゲートウェイA920に障害情報収集ボタン928やそれに類するものが備わっている場合は、それを押下する事を契機として障害情報収集を開始してもよい。図17に、図10記載のホームゲートウェイA920が、再起動すれば直る程度の軽い異常である場合は再起動させ、そうでない場合はリモート保守サーバ装置900に対して障害情報を送信する際の一例を示すフローチャートを示す。処理1700:障害情報処理決定部927は、ソフトウェアが正常に動作している時は待機している。処理1701:ホームゲートウェイに備わる障害情報収集ボタン928が押下されると、障害情報処理決定部927が処理を開始する。処理1702:障害情報収集部921が、発生した障害の情報を収集し、もし情報があれば、収集した障害情報を障害情報データベース923に格納する。処理1703:障害情報処理決定部927が、収集した障害情報から、ホームゲートウェイA920でソフトウェア障害が発生したか否かを判定する。もし障害が発生していないと判定した場合は、障害情報処理決定部927は待機状態に戻る。処理1704:障害の発生したソフトウェアが障害対処情報設定テーブル929の中で異常なソフトウェアとして登録されているか否か、障害情報処理決定部927がチェックする。処理1705:処理1704において、障害発生ソフトウェアが異常なソフトウェアとして登録されていた場合、その障害発生ソフトウェアが未だホームゲートウェイA920上で動作している場合は停止するよう障害情報処理決定部927が命令し、既に停止している場合はそのまま停止させておく。尚、停止させるのが好ましくないソフトウェアである場合は、例えば、ポップアップ等でユーザに確認後に該ソフトウェアを再起動させるよう、障害情報処理決定部927が命令してもよい。処理1706:障害情報データベース923の中の、障害の発生したソフトウェアの障害発生回数を1増やす。処理1707:障害発生ソフトウェアが再起動すれば直る程度の軽い異常か否かを、障害情報処理決定部927がチェックする。本実施例では、障害対処情報設定テーブル929に記載されている、公開されてから現在までの経過日数に応じた障害発生回数の閾値と、障害情報データベース923に記載されている、障害発生回数との比較により、これを行う。処理1707は、発生した障害が、再起動させれば直る程度の軽い異常か否かを判別するためのものであり、方法は上記に限定されるものではない。処理1708:もし処理1707において、障害発生ソフトウェアの障害発生回数が閾値を越えなかった場合は、障害情報処理決定部927は、障害が発生したソフトウェアを再起動させる。処理1709:障害情報送信部922から障害情報を送信する。その他の処理に関しては、実施例4と同様である。本実施例の効果として、実施例4と同様の効果に加え、ホームゲートウェイに備わる障害情報収集ボタン128を契機として障害発生の診断や復旧をユーザ自ら実施できる点で、よりアクティブで自由な障害復旧を行う事が出来る。実施例4では、障害発生ソフトウェアがフレームワーク上で動作するか否か分からない場合を想定しているが、フレームワーク上で動作しないと予め分かっている場合は、図12の処理を図18に示すように短縮してもよい。図18に、図10記載のリモート保守サーバ900が、ソフトウェア障害が発生したホームゲートウェイA920に対して障害対処方法を送信する際の一例を示すフローチャートを示す。処理1800:処理1108でホームゲートウェイA920から送信された障害情報を、障害情報受信部903が受信する。処理1801:受信した障害情報を、障害情報受信部903が障害情報データベース904に格納する。処理1802:障害対処方法決定部901が、障害情報設定テーブル902に障害発生ソフトウェアが異常なものとして記載されているかチェックする。処理1803:処理1802で、もし障害発生ソフトウェアが異常なものとして判断されれば、障害対処方法送信部905から障害発生ソフトウェアが異常であるという情報をホームゲートウェイA920へ送信するとともに、その障害発生ソフトウェアが未だホームゲートウェイA920上で動作している場合は停止するよう同じく障害対処方法送信部905からホームゲートウェイA920へ命令を送信し、既に停止している場合はそのまま停止させておく。尚、停止させるのが好ましくないソフトウェアである場合は、例えば、ポップアップ等でユーザに確認後に該ソフトウェアを再起動させるよう、障害対処方法送信部905からホームゲートウェイA920へ命令を送信してもよい。処理1804:障害対処方法決定部901が、障害情報設定テーブル902に記載されている、公開されてから現在までの経過日数に応じたソフトウェアが異常か否かを判定するための閾値と、障害情報データベース904に記載されている、ソフトウェア異常が起きたホームゲートウェイ台数の、該ソフトウェアが動作するホームゲートウェイ全体台数に対する割合と、を比較し、障害発生ソフトウェアが異常か否かを判定する。処理1805:処理1804で、もし障害が発生したホームゲートウェイ台数の全体台数に対する割合が閾値を超え、障害発生ソフトウェアが異常であると判定されれば、障害対処方法送信部905から障害発生ソフトウェアが異常であるという情報をホームゲートウェイA920へ送信するとともに障害対処情報設定テーブル902に障害発生ソフトウェアは異常であると記載した後、その障害発生ソフトウェアが未だホームゲートウェイA920上で動作している場合は停止するよう同じく障害対処方法送信部905からホームゲートウェイA920へ命令を送信し、既に停止している場合はそのまま停止させておく。尚、停止させるのが好ましくないソフトウェアである場合は、例えば、ポップアップ等でユーザに確認後に該ソフトウェアを再起動させるよう、障害対処方法送信部905からホームゲートウェイA920へ命令を送信してもよい。処理1806:ホームゲートウェイ自体を再起動させるよう、障害対処方法送信部905からホームゲートウェイA920へ命令を送信する。その他の処理に関しては、実施例4と同様である。本実施例の効果として、実施例4と同様の効果を得られるが、もしホームゲートウェイのソフトウェア実行環境125がフレームワークを含まない構成であった場合は、本実施例の方法を用いる事で、フレームワークのチェックという余計な処理を省略する事で障害復旧のコストをより低く抑える事が出来る。