(57)【要約】【課題】業務上の機密に係る情報を含むログを遠隔地に送付することなく、リモートメンテナンスを可能とするリモートメンテナンスシステム等を提供する。【解決手段】リモートメンテナンスシステム１００は、保守対象計算機２と、保守対象計算機と同一のＬＡＮに接続されていない保守端末４と、保守対象計算機と同一のＬＡＮに接続され、かつ保守端末からインターネットを介してアクセス可能なリモートメンテナンス装置１とを有し、このリモートメンテナンス装置が、障害情報データを蓄積する障害情報蓄積手段１１と、蓄積された障害情報データに保守対象計算機においてエラーが発生したことを示す内容が含まれるか否かを判断する異常検出手段１２と、異常検出手段の判断に基づいて起動され、障害情報データをさらに詳しく分析し、該分析結果を保守端末に送信する分析手段１４とを有するものとした。【選択図】図１
2010049437.tif 000002
【特許請求の範囲】
【請求項１】
保守対象計算機と、前記保守対象計算機と同一のＬＡＮに接続されていない保守端末と、前記保守対象計算機と同一のＬＡＮに接続され、かつ前記保守端末からインターネットを介してアクセス可能なリモートメンテナンス装置とを有するリモートメンテナンスシステムであって、
前記保守対象計算機が、前記リモートメンテナンス装置に障害情報データを送信する障害情報送信手段を有し、
前記リモートメンテナンス装置が、
前記障害情報データを蓄積する障害情報蓄積手段と、
蓄積された前記障害情報データに前記保守対象計算機においてエラーが発生したことを示す内容が含まれるか否かを判断する異常検出手段と、
前記異常検出手段の判断に基づいて起動され、前記障害情報データをさらに詳しく分析し、該分析結果を前記保守端末に送信する分析手段と
を有することを特徴とするリモートメンテナンスシステム。
【請求項２】
前記リモートメンテナンス装置が、
前記障害情報データを種類毎に蓄積する複数の共有フォルダと、
前記異常検出手段の判断に基づいて前記分析手段からアクセス可能なように前記共有フォルダのアクセス権を設定するアクセス権設定手段と
を有することを特徴とする、請求項１に記載のリモートメンテナンスシステム。
【請求項３】
前記リモートメンテナンス装置が、前記障害情報データの種類と、前記共有フォルダおよび前記分析手段とを対応づける対応表を有することを特徴とする、請求項２に記載のリモートメンテナンスシステム。
【請求項４】
前記障害情報データが、所定の周期で前記保守対象計算機から前記リモートメンテナンス装置に送信される定期障害情報と、不定期的に前記保守対象計算機から前記リモートメンテナンス装置に送信される不定期障害情報とを含み、
前記異常検出手段が、前記定期障害情報が所定の時刻になっても書き込まれない場合、前記定期障害情報に所定の量を超える量のログが書き込まれかつ障害情報データに特定の文字列が含まれる場合、前記不定期障害情報が書き込まれかつ障害情報データに前記特定の文字列が含まれる場合、以上のうちいずれか一つに該当する場合に、前記保守対象計算機においてエラーが発生したと判断することを特徴とする、請求項２に記載のリモートメンテナンスシステム。
【請求項５】
前記共有フォルダがネットワーク共有フォルダであり、
前記保守対象計算機がログ書き出し機能を備え、このログ書き出し機能の書き出し先を前記ネットワーク共有フォルダとすることにより、このログ書き出し機能が前記障害情報送信手段として機能することを特徴とする、請求項２に記載のリモートメンテナンスシステム。
【請求項６】
前記分析手段が、イベントビューワ、ネットワークログ解析ツール、アプリケーションダンプトレーサ、負荷状況解析ツール、ダンプ解析ツールのうちいずれか１つ以上を含むことを特徴とする、請求項１ないし請求項５のうちいずれか１項に記載のリモートメンテナンスシステム。
【請求項７】
前記障害情報データが、イベントログ、ネットワークログ、アプリケーションダンプ、フルダンプのうちいずれか１つ以上を含むことを特徴とする、請求項１ないし請求項５のうちいずれか１項に記載のリモートメンテナンスシステム。
【請求項８】
保守対象計算機と同一のＬＡＮに接続され、かつ保守端末からインターネットを介してアクセス可能なリモートメンテナンス装置であって、
前記保守対象計算機から障害情報データを受信して蓄積する障害情報蓄積手段と、
蓄積された前記障害情報データに前記保守対象計算機においてエラーが発生したことを示す内容が含まれるか否かを判断する異常検出手段と、
前記異常検出手段の判断に基づいて起動され、前記障害情報データをさらに詳しく分析し、該分析結果を前記保守端末に送信する分析手段と
を有することを特徴とするリモートメンテナンス装置。
【請求項９】
保守対象計算機の障害情報データを分析する分析手段を備え、前記保守対象計算機と同一のＬＡＮに接続され、かつ保守端末からインターネットを介してアクセス可能なリモートメンテナンス装置が、前記保守対象計算機で発生したエラーの原因を解析するリモートメンテナンス方法であって、
前記保守対象計算機から受信した前記障害情報データを蓄積し、
蓄積された前記障害情報データに前記保守対象計算機においてエラーが発生したことを示す内容が含まれるか否かを判断し、
前記判断結果に基づいて前記分析手段を起動して前記障害情報データをさらに詳しく分析し、
前記分析手段による分析の結果を前記保守端末に送信する
ことを特徴とするリモートメンテナンス方法。
【請求項１０】
前記障害情報データを受信する処理は、前記障害情報データを種類毎に共有フォルダに蓄積する処理を含み、
前記判断結果に基づいて、前記分析手段が前記障害情報データにアクセス可能なように前記共有フォルダのアクセス権を設定した後に前記分析手段を起動することを特徴とする、請求項９に記載のリモートメンテナンス方法。
【請求項１１】
保守対象計算機の障害情報データを分析する分析手段を備え、前記保守対象計算機と同一のＬＡＮに接続され、かつ保守端末からインターネットを介してアクセス可能なリモートメンテナンス装置を制御するコンピュータに、
前記保守対象計算機から受信した障害情報データを蓄積する手順と、
蓄積された前記障害情報データに前記保守対象計算機においてエラーが発生したことを示す内容が含まれるか否かを判断する手順と、
前記判断結果に基づいて前記分析手段を起動して前記障害情報データをさらに詳しく分析する手順と、
前記さらに詳しい分析の結果を前記保守端末に送信する手順と
を実行させることを特徴とするリモートメンテナンスプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はコンピュータのリモートメンテナンスに関し、特にリモートメンテナンスに伴う業務上の機密情報の外部への流出のリスクを軽減することが可能なリモートメンテナンスシステム等に関する。
【背景技術】
【０００２】
コンピュータが多くの企業などに導入されるようになったことに伴い、各企業が自社のコンピュータに専従の管理者を置くことが困難である場合も多くなっている。そのような場合に、リモートメンテナンスというサービスが利用されることも多くなっている。これは、管理担当業者が、クライアントである企業の外部からネットワークを介して、各企業のコンピュータの点検やトラブル発生時の対応を行うというサービスである。
【０００３】
このリモートメンテナンスのための装置として、次のような技術文献が開示されている。特許文献１は、管理担当者がネットワークを介して、ログファイルを解析することを可能とするリモートメンテナンス装置が記載されている。また特許文献２には、ＬＡＮ（Local Area Network）上でアクセス監視および制御を行った結果を、ネットワークを介した監視制御ログに記録するという技術が記載されている。いずれも、ＬＡＮ上で取得したログを、ネットワークを介して遠隔地にいる管理担当者宛に送付している。
【０００４】
【特許文献１】特開平１１−１１０２４８号公報
【特許文献２】特開２００３−３３０８０２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
前述の特許文献１〜２の技術では、ＬＡＮ上で取得した各種ログを、ネットワークを介して遠隔地にいる管理担当者宛に送付することが必要である。しかしながら、それらのログ、たとえばイベントログ、ネットワークログ、アプリケーションログなどには、当該コンピュータで行われる業務上の機密に係る情報が多く含まれている。
【０００６】
近年、個人情報保護法などのような法制度が整備されたことに伴い、各企業においては業務上の機密情報の外部への流出というリスクに対する危機意識が高まっている。このため、当該計算機の利用部門が、それらの機密情報を含むログの社外への送付に対して難色を示す場合や、当該ログから個人情報を削除するよう指示する場合がある。これらのことが、障害復旧の遅延をもたらしている。
【０００７】
迅速な障害復旧のためには、当該ログについて、事前にアクセス許可を得ておくことが望ましい。しかしながら、そのことに対して利用部門から理解を得るためには、遠隔地に送付される障害情報の種類と、それに対する分析手段、および持ち出された障害情報ファイルが障害復旧後に削除されたという確証を明確にし、利用部門がそれらを管理可能な状態にする必要がある。前述の特許文献１〜２の技術は、このことが十分に考慮されているとは言えない。
【０００８】
本発明の目的は、業務上の機密に係る情報を含むログを遠隔地に送付することなく、リモートメンテナンスを可能とするリモートメンテナンスシステム、装置および方法、プログラムを提供することにある。
【課題を解決するための手段】
【０００９】
上記目的を達成するため、本発明に係るリモートメンテナンスシステムは、保守対象計算機と、保守対象計算機と同一のＬＡＮに接続されていない保守端末と、保守対象計算機と同一のＬＡＮに接続され、かつ保守端末からインターネットを介してアクセス可能なリモートメンテナンス装置とを有するリモートメンテナンスシステムであって、保守対象計算機が、リモートメンテナンス装置に障害情報データを送信する障害情報送信手段を有し、リモートメンテナンス装置が、障害情報データを蓄積する障害情報蓄積手段と、蓄積された障害情報データに保守対象計算機においてエラーが発生したことを示す内容が含まれるか否かを判断する異常検出手段と、異常検出手段の判断に基づいて起動され、障害情報データをさらに詳しく分析し、該分析結果を保守端末に送信する分析手段とを有することを特徴とする。
【００１０】
上記目的を達成するため、本発明に係るリモートメンテナンス装置は、保守対象計算機と同一のＬＡＮに接続され、かつ保守端末からインターネットを介してアクセス可能なリモートメンテナンス装置であって、保守対象計算機から障害情報データを受信して蓄積する障害情報蓄積手段と、蓄積された障害情報データに保守対象計算機においてエラーが発生したことを示す内容が含まれるか否かを判断する異常検出手段と、異常検出手段の判断に基づいて起動され、障害情報データをさらに詳しく分析し、該分析結果を保守端末に送信する分析手段とを有することを特徴とする。
【００１１】
上記目的を達成するため、本発明に係るリモートメンテナンス方法は、保守対象計算機の障害情報データを分析する分析手段を備え、保守対象計算機と同一のＬＡＮに接続され、かつ保守端末からインターネットを介してアクセス可能なリモートメンテナンス装置が、保守対象計算機で発生したエラーの原因を解析するリモートメンテナンス方法であって、保守対象計算機から受信した障害情報データを蓄積し、蓄積された障害情報データに保守対象計算機においてエラーが発生したことを示す内容が含まれるか否かを判断し、判断結果に基づいて障害情報データをさらに詳しく分析し、このさらに詳しい分析の結果を保守端末に送信することを特徴とする。
【００１２】
上記目的を達成するため、本発明に係るリモートメンテナンスプログラムは、保守対象計算機の障害情報データを分析する分析手段を備え、保守対象計算機と同一のＬＡＮに接続され、かつ保守端末からインターネットを介してアクセス可能なリモートメンテナンス装置を制御するコンピュータに、保守対象計算機から受信した障害情報データを蓄積する手順と、蓄積された障害情報データに保守対象計算機においてエラーが発生したことを示す内容が含まれるか否かを判断する手順と、判断結果に基づいて障害情報データをさらに詳しく分析する分析手段を起動する手順と、このさらに詳しい分析の結果を保守端末に送信する手順とを実行させることを特徴とする。
【発明の効果】
【００１３】
本発明は、上述したように保守対象計算機と同一のＬＡＮに接続されたリモートメンテナンス装置が、保守対象計算機から受信した障害情報データを解析し、その解析結果をインターネットを介して保守端末に送信するように構成したので、障害情報データそのものをインターネットを介して外部に送信しなくても、障害情報データを解析して障害の発生原因を特定することができる。これによって、業務上の機密に係る情報を含むログを遠隔地に送付することなく、リモートメンテナンスを可能とするという、従来にない優れたリモートメンテナンスシステム、装置および方法、プログラムを提供することができる。
【発明を実施するための最良の形態】
【００１４】
［第１の実施形態］
以下、本発明の実施形態の構成について添付図に基づいて説明する。
最初に、本実施形態の基本的な内容について説明し、その後でより具体的な内容について説明する。
本実施形態に係るリモートメンテナンスシステム１００は、保守対象計算機２と、保守端末４と、リモートメンテナンス装置１で構成される。ここで、保守端末４は保守対象計算機と同一のＬＡＮに接続されていない。また、リモートメンテナンス装置１は保守対象計算機２と同一のＬＡＮに接続され、かつ保守端末４からインターネット３を介してアクセス可能である。この保守対象計算機２は、リモートメンテナンス装置１に障害情報データを送信する障害情報送信手段２１を持つ。そしてリモートメンテナンス装置１は、障害情報データを蓄積する障害情報蓄積手段１１と、蓄積された障害情報データに保守対象計算機においてエラーが発生したことを示す内容が含まれるか否かを判断する異常検出手段１２と、異常検出手段１２の判断に基づいて起動され、障害情報データをさらに詳しく分析し、該分析結果を保守端末に送信する分析手段１４とを持つ。
【００１５】
さらにこのリモートメンテナンス装置１は、障害情報データを種類毎に蓄積する複数の共有フォルダ１１ａ〜ｅと、異常検出手段１２の判断に基づいて分析手段１４からアクセス可能なように共有フォルダのアクセス権を設定するアクセス権設定手段１３とを有する。  また、リモートメンテナンス装置１は、障害情報データの種類と、共有フォルダおよび分析手段とを対応づける対応表１３ａを有する。
【００１６】
ここでいう障害情報データは、所定の周期で保守対象計算機からリモートメンテナンス装置に送信される定期障害情報と、不定期的に保守対象計算機からリモートメンテナンス装置に送信される不定期障害情報とを含む。
【００１７】
また、異常検出手段１２は、「定期障害情報が所定の時刻になっても書き込まれない場合」、「定期障害情報に所定の量を超える量のログが書き込まれかつ障害情報データに特定の文字列が含まれる場合」、または「不定期障害情報が書き込まれかつ障害情報データに特定の文字列が含まれる場合」のうちいずれかに該当する場合に、保守対象計算機２においてエラーが発生したと判断する。
【００１８】
共有フォルダ１１ａ〜ｅはネットワーク共有フォルダで構成することができ、そして保守対象計算機２が備えるログ書き出し機能の書き出し先をネットワーク共有フォルダとすることによって、このログ書き出し機能を障害情報送信手段２１として機能させることができる。
【００１９】
ここでいう分析手段１４は、イベントビューワ、ネットワークログ解析ツール、アプリケーションダンプトレーサ、負荷状況解析ツール、ダンプ解析ツールのうちいずれか１つ以上を含むことができる。また障害情報データは、イベントログ、ネットワークログ、アプリケーションダンプ、フルダンプのうちいずれか１つ以上を含むことができる。
【００２０】
以下、これをより詳細に説明する。図１は、本発明の第１の実施形態に係るリモートメンテナンスシステム１００の構成を示す概略構成図である。リモートメンテナンスシステム１００は、リモートメンテナンス装置１と保守対象計算機２とがＬＡＮを介して相互に接続している。保守対象計算機２は、保守対象計算機２上で発生した障害について表す後述の障害情報データをリモートメンテナンス装置１に対して送信する障害情報送信手段２１を備えている。障害情報送信手段２１の動作については後述する。
【００２１】
また、リモートメンテナンス装置１はインターネット３を介して保守端末４と相互に接続しているコンピュータ装置であり、後述の各機能部を有する。保守端末４は管理担当者が操作するコンピュータ装置であり、管理担当者は保守端末４を操作してリモートメンテナンス装置１にインターネット３を介してログイン可能である。図１の中で、太い矢印は加工されていない障害情報の流れを示し、細い矢印はそれ以外の制御や画面情報の流れを示している。
【００２２】
リモートメンテナンス装置１は、ＣＰＵ、ＲＡＭ、ＯＳなどを含むコンピュータで、コンピュータプログラムを実行する主体であり、障害情報蓄積手段１１と、異常検出手段１２と、アクセス権設定手段１３と、分析手段１４といった各機能部を実行する。またリモートメンテナンス装置１は、これらの各機能部を制御するＣＰＵ、ＲＡＭ、ＯＳなどによって構成される制御部１５を備える。以下に述べる、リモートメンテナンス装置１の全ての動作は、制御部１５の制御に基づいて行われる。
【００２３】
障害情報蓄積手段１１は、複数の共有フォルダ１１ａ〜ｅを含む。障害情報蓄積手段１１は、障害情報送信手段２１から障害情報ファイルを受信すると、受信した障害情報ファイルをその種類に応じて共有フォルダ１１ａ〜ｅの中の所定の場所に書き込み、蓄積する。ここでいう障害情報ファイルとは、具体的にはイベントログ（１１ａ）、ネットワークログ（１１ｂ）、アプリケーションダンプ（１１ｃ〜１１ｄ）、フルダンプ（１１ｅ）などである。括弧内は、各々の障害情報ファイルに対応する共有フォルダの参照記号を表す。
【００２４】
アプリケーションダンプは、保守対象計算機２で動作するアプリケーションの種類ごとに障害情報送信手段２１が作成する。ここでは、保守対象計算機２で動作するアプリケーションＡに対応するアプリケーションダンプをアプリケーションＡダンプ（１１ｃ）といい、アプリケーションＢに対応するアプリケーションダンプをアプリケーションＢダンプ（１１ｄ）という。
【００２５】
なお、この共有フォルダの数は必ず５つである必要はなく、「共有フォルダ１１ａ〜ｅ」という表記は単に「複数の共有フォルダが存在する」ことを示すものに過ぎない。また、本実施例では、障害情報蓄積手段１１はＯＳが標準的に備えているネットワーク共有フォルダを利用する。
【００２６】
障害情報送信手段２１は、それらの障害情報ファイルをリモートメンテナンス装置１に送信する。本実施例では、障害情報送信手段２１はＯＳが標準的に備えている各種ログ（上記でいう障害情報ファイルに該当するイベントログ、ネットワークログ、アプリケーションログ、フルダンプなど）の書き出し機能であり、前述のように共有フォルダ１１ａ〜ｅであるネットワーク共有フォルダをそれらの書き出し先として指定することによって、このログ書き出し機能を障害情報送信手段２１として機能させることができる。
【００２７】
異常検出手段１２は、共有フォルダ１１ａ〜ｅに書き込まれた障害情報ファイルから保守対象計算機２の現在の稼動状況を判断する。より具体的には、所定の間隔で受信することになっている障害情報ファイルを受信しない状態が所定の時間続いた場合、当該障害情報ファイルに通常の量を超える大量のログが書き込まれた場合でかつ当該障害情報ファイルに「エラー発生」を示す特定の文字列（たとえば「ＡＰＰ＿ＥＲＲ」など）、あるいは後述の不定期障害情報が書き込まれた場合でかつ当該障害情報ファイルに前述の「エラー発生」を示す特定の文字列、以上のうちいずれかに該当すれば稼働状況に異常が発生したと判断し、その旨をアクセス権設定手段１３へ通知する。
【００２８】
アクセス権設定手段１３は、保守対象計算機２の現在の稼動状況と発生した障害についての対応方法を示す対応表１３ａを保持する。この対応表１３ａの中にフラグとして保持し、フラグにより予め定められた共有フォルダ１１ａ〜ｅに対して分析手段１４ａ〜ｅからアクセス可能なようにアクセス権を設定する。
【００２９】
図２は、図１で示した対応表１３ａのデータ構成を示す説明図である。対応表１３ａは、状況保持フラグ３１、稼働状況項目３２、利用可能障害ファイル３３、利用可能分析手段３４といった各々のデータを含む。
【００３０】
状況保持フラグ３１は、異常検出手段１２から通知された保守対象計算機２の稼動状況に応じて、該当する稼働状況項目３２に対応する状況保持フラグ３１がＯＮにされる。図２では、保守対象計算機２の稼動状況に対応するフラグがＯＮにされた状態を「○」で表している。稼働状況項目３２は、異常検出手段１２から通知された保守対象計算機２の稼動状況を示す項目名である。「通常監視」「高負荷」「アプリケーションＡエラー」「アプリケーションＢエラー」「原因不明異常」などのような項目がある。
【００３１】
利用可能障害ファイル３３、および利用可能分析手段３４は、保守対象計算機２が稼働状況項目３２に示される状況となった場合に、利用される障害情報ファイルと、当該障害情報ファイルを分析する分析手段の名称をそれぞれ示している。なお、ある一つの稼働状況項目３２に対して、複数の利用可能障害ファイル３３が存在する場合もある。利用可能障害ファイル３３は、より具体的には共有フォルダ１１ａ〜ｅに蓄積されている、イベントログ、ネットワークログ、アプリケーションログ、フルダンプなどである。
【００３２】
図２に示される例では、現在保守対象計算機２は「通常監視」状態であり、かつ「アプリケーションＡ」においてエラーが発生している状態であるので、「通常監視」「アプリケーションＡエラー」という２つの稼働状況項目３２に該当する状況保持フラグ３１がＯＮとされている。
【００３３】
稼働状況項目３２が「通常監視」の状態では、利用可能障害ファイル３３は「イベントログ」であり、このイベントログを分析する利用可能分析手段３４は「イベントビューア」である。稼働状況項目３２が「アプリケーションＡエラー」の状態では、利用可能障害ファイル３３は「アプリケーションＡダンプ」であり、このアプリケーションＡダンプを分析する利用可能分析手段３４は「アプリケーションダンプトレーサ」である。
【００３４】
この対応表１３ａで、状況保持フラグ３１がＯＮとされた稼働状況項目３２に基づいて、アクセス権設定手段１３は利用可能分析手段３４に対応する分析手段１４を起動し、かつ該分析手段が利用可能障害ファイル３３に該当する障害ファイルを読み取れるよう、この障害ファイルが書き込まれている共有フォルダ１１ａ〜ｅのアクセス権を設定する。
【００３５】
分析手段１４は、障害ファイルを分析する複数の分析手段１４ａ〜ｅを含む。より具体的には、分析手段１４ａ〜ｅは利用可能分析手段３４として図２に記載されているイベントビューワ１４ａ、ネットワークログ解析ツール１４ｂ、アプリケーションダンプトレーサ１４ｃ、負荷状況解析ツール１４ｄ、ダンプ解析ツール１４ｅなどである。そして、この分析手段１４が行った分析の結果は、インターネット３を介して保守端末４に送信される。この「分析手段１４ａ〜ｅ」もまた、単に「複数の分析手段が存在する」ことを示す表記でしかなく、分析手段の数が必ず５つであるということを示すものではない。
【００３６】
（障害情報ファイルの受信）
図３は、図１で示したリモートメンテナンス装置１が障害情報送信手段２１から障害情報ファイルを受信するという動作を示すフローチャートである。なお、この動作の前提として、保守対象計算機２が有する障害情報送信手段２１は、自身に発生した障害について示す障害情報ファイルをリモートメンテナンス装置１に送信するという動作を行っている。障害情報蓄積手段１１は、それらの定期障害情報および不定期障害情報を受信するたびに（ステップＳ１０１）、対応する共有フォルダ１１ａ〜ｅに当該障害情報を書き込んでいる（ステップＳ１０２）。
【００３７】
イベントログおよびネットワークログは、所定の間隔でリモートメンテナンス装置１に送信される。アプリケーションＡログおよびアプリケーションＢログは、保守対象計算機２で実行されるアプリケーションＡおよびアプリケーションＢでエラーが発生した場合に、それぞれリモートメンテナンス装置１に送信される。フルダンプは、保守対象計算機２で動作するＯＳでエラーが発生した場合に、リモートメンテナンス装置１に送信される。
【００３８】
以後、所定の間隔でリモートメンテナンス装置１に送信される障害情報ファイルを、定期障害情報といい、エラーが発生した場合に送信される障害情報ファイルを、不定期障害情報という。イベントログおよびネットワークログは定期障害情報であり、アプリケーションＡログ、アプリケーションＢログ、およびフルダンプは不定期障害情報である。
【００３９】
（障害の発生の検出、そして障害の解決）
図４は、図１で示したリモートメンテナンス装置１が保守対象計算機２の障害の発生を検出し、この障害を解決する動作を示すフローチャートである。異常検出手段１２は、「定期障害情報が所定の時刻になっても書き込まれない」状態（ステップＳ２０１）、「定期障害情報に通常の量を超える大量のログが書き込まれた」状態（ステップＳ２０２）、または「不定期障害情報が書き込まれた」状態（ステップＳ２０３）のうちのいずれかが発生したか否かを検知する。
【００４０】
ステップＳ２０１でＹＥＳと判断された場合はそのまま後述のステップＳ２０５に進む。
ステップＳ２０２もしくは２０３でＹＥＳと判断された場合は、異常検出手段１２は当該定期障害情報または不定期障害情報の内容を確認し、そこにエラー発生を示す内容（たとえば前述の「ＡＰＰ＿ＥＲＲ」など）が書き込まれているか否かを判断する（ステップＳ２０４）。ステップＳ２０１〜２０４のいずれもＮＯである場合、ステップＳ２０１の判断に戻る。
【００４１】
ステップＳ２０１もしくはＳ２０４でエラー発生と判断された場合、異常検出手段１２は、そのエラーによって示される保守対象計算機２の動作状態が対応表１３ａでいう稼働状況項目３２のどれに該当するかを判断し、その判断結果に基づいて、対応表１３ａで該当する項目の状況保持フラグ３１をＯＮにする（ステップＳ２０５）。
【００４２】
そしてアクセス権設定手段１３は、対応表１３ａで稼働状況項目３２に該当する利用可能障害ファイル３３に該当する障害ファイルが書き込まれている共有フォルダ１１ａ〜ｅのアクセス権を設定し（ステップＳ２０６）、この稼働状況項目３２に該当する利用可能分析手段３４に対応する分析手段１４を起動する（ステップＳ２０７）。なお、ここで分析手段１４は、対応表１３ａの記載に基づいて自動的に起動されるようにしてもよいし、また保守対象計算機２の操作者から電話などで連絡を受けた管理担当者によって手動で起動されるようにしてもよい。
【００４３】
起動された分析手段１４は、対応する障害情報ファイルに対してアクセスして、障害の詳細について解析する（ステップＳ２０８）。そして、その解析結果は、分析手段１４からインターネット３を介して保守端末４に送信される（ステップＳ２０９）。保守端末４を操作する管理担当者は、送信された解析結果を見て、電話もしくは電子メールなどによって保守対象計算機２の操作者に、そのエラーへの対応方法について伝達することが可能である。
【００４４】
より具体的な動作例について示すと、図２に示される例のように、保守対象計算機２は「通常監視」状態であり、かつ保守対象計算機２において動作する「アプリケーションＡ」においてエラーが発生している状態であるものとする。異常検出手段１２は、障害情報蓄積手段１１に蓄積された内容を読み、その結果に基づいて対応表１３ａで「通常監視」「アプリケーションＡエラー」という２つの稼働状況項目３２に該当する状況保持フラグ３１をＯＮとする（ステップＳ２０１〜２０５）。
【００４５】
ここでは、不定期障害情報であるアプリケーションＡログが書き込まれたので「不定期障害情報が書き込まれたか？」について判断するステップＳ２０３がＹＥＳとなり、さらにアプリケーションＡログにはエラー発生を示す内容が書き込まれているのでステップＳ２０４もＹＥＳとなる。
【００４６】
アクセス権設定手段１３は、対応表１３ａの内容に基づき、まず「アプリケーションＡエラー」に対応する障害情報ファイルである「アプリケーションＡダンプ」が記録されている共有フォルダ１１ｃに、対応するツールである「アプリケーションダンプトレーサ１４ｃ」がアクセスできるよう、該フォルダのアクセス権を設定する（ステップＳ２０６）。そして、アプリケーションダンプトレーサ１４ｃを起動し、「アプリケーションＡダンプ」の解析を開始させる（ステップＳ２０７〜２０８）。なお、ここでアプリケーションダンプトレーサ１４ｃは、対応表１３ａの記載に基づいて制御部１５が自動的に起動するようにしてもよいし、また保守対象計算機２の操作者から電話などで連絡を受けた管理担当者によって手動で起動されるようにしてもよい。
【００４７】
この解析の結果は、分析手段１４からインターネット３を介して保守端末４に送信される（ステップＳ２０９）。保守端末４には、表示された解析結果から、アプリケーションＡにて障害が発生しているプログラムラインを特定され、表示される。保守端末４を操作する管理担当者はこれを見て、たとえば「操作ミスが原因」などのように、保守対象計算機２の操作者に障害の発生原因と対応方法を伝えることができる。
【００４８】
管理担当者からの連絡で障害が解決した後、保守対象計算機２の操作者は対応表１３ａに含まれるフラグをリセットし、アクセス権設定手段１３によって設定されたアクセス権を初期状態に戻して、操作および作業を続行することができる。検出された稼働状況項目３２が異なっても、アクセス権を設定される共有フォルダ、および起動される分析手段１４が異なるだけで、行われる動作は上記と同一である。
【００４９】
（全体的な動作）
次に、上記の第１の実施形態の全体的な動作について説明する。本発明の第１の実施形態に係るリモートメンテナンス装置１、つまり分析手段１４を備え、保守対象計算機２と同一のＬＡＮに接続され、かつ保守端末４からインターネット３を介してアクセス可能なリモートメンテナンス装置１が、保守対象計算機２で発生したエラーの原因を解析するにあたって、保守対象計算機２から受信した障害情報データを蓄積し（図３：ステップＳ１０１〜１０２）、蓄積された障害情報データに保守対象計算機２においてエラーが発生したことを示す内容が含まれるか否かを判断し（図４：ステップＳ２０１〜２０４）、判断結果に基づいて分析手段を起動して障害情報データをさらに詳しく分析し（図４：ステップＳ２０７〜２０８）、その分析結果を保守端末４に送信する（図４：ステップＳ２０９）。
【００５０】
ここで、上記の障害情報データを受信する処理は、障害情報データを種類毎に共有フォルダ１１ａ〜ｅに蓄積する処理（図３：ステップＳ１０２）を含み、前述の図４のステップＳ２０１〜２０４の判断結果に基づいて、分析手段１４が障害情報データにアクセス可能なように共有フォルダ１１ａ〜ｅのアクセス権を設定した（図４：ステップＳ２０６）後に前述の分析手段を起動する（図４：ステップＳ２０７〜２０８）ようにすることもできる。
【００５１】
ここで、上記各動作ステップについては、これをコンピュータで実行可能にプログラム化し、これらを前記各ステップを直接実行するコンピュータであるリモートメンテナンス装置１に実行させるようにしてもよい。
【００５２】
以上説明したように、本発明においては、以上のような動作を行うことにより、次に記載するような効果を奏する。本発明に係るリモートメンテナンスシステム１００で、インターネット３を介して外部に送信されるのは、分析手段１４が行った分析の結果のみであり、決して障害ファイルそのものがインターネット３を介して外部に送信されるのではない。
【００５３】
これによって、管理担当者は保守端末４を介して、あたかも保守対象計算機２と同一のＬＡＮ上にいるかのように、インターネット３を通じて保守対象計算機２を監視し、そこに発生したエラーの原因を解析して障害を解決することができる。しかも、機密情報を含む障害ファイルが、企業外部に送信されることはない。このため、あらかじめ利用部門側に了解を得ておけば、その了解を得た種類の情報に限ってこのリモートメンテナンスに利用することができ、即ち利用部門側で障害情報から機密情報の流出のリスクを制御することを可能とすることができる。
【００５４】
さらに、たとえば障害情報ファイルから保守対象計算機２のセキュリティホールを探すツールがあったとしても、そのセキュリティホールを探す対象となる障害情報ファイルは保守端末４から直接アクセスされることはない。そのため、該ツールを保守端末４で実行されたとしても、このツールは障害情報ファイルにアクセスできないので、それによってセキュリティホールを探し当てられる可能性はない。
【００５５】
これまで本発明について図面に示した特定の実施形態をもって説明してきたが、本発明は図面に示した実施形態に限定されるものではなく、本発明の効果を奏する限り、これまで知られたいかなる構成であっても採用することができる。
【産業上の利用可能性】
【００５６】
企業内などのコンピュータのリモートメンテナンスに利用可能である。
【図面の簡単な説明】
【００５７】
【図１】本発明の第１の実施形態に係るリモートメンテナンスシステムの構成を示す概略構成図である。
【図２】図１で示した対応表のデータ構成を示す説明図である。
【図３】図１で示したリモートメンテナンス装置が障害情報送信手段から障害情報ファイルを受信するという動作を示すフローチャートである。
【図４】図１で示したリモートメンテナンス装置が保守対象計算機の障害の発生を検出し、この障害を解決する動作を示すフローチャートである。
【符号の説明】
【００５８】
１  リモートメンテナンス装置
２  保守対象計算機
３  インターネット
４  保守端末
１１  障害情報蓄積手段
１１ａ〜ｅ  共有フォルダ
１２  異常検出手段
１３  アクセス権設定手段
１３ａ  対応表
１４  分析手段
１４ａ  イベントビューワ
１４ｂ  ネットワークログ解析ツール
１４ｃアプリケーションダンプトレーサ
１４ｄ  負荷状況解析ツール
１４ｅ  ダンプ解析ツール
１５  制御部
２１  障害情報送信手段
３１  状況保持フラグ
３２  稼働状況項目
３３  利用可能障害ファイル
３４  利用可能分析手段
１００  リモートメンテナンスシステム
【図１】
2010049437.tif 000003
【図２】
2010049437.tif 000004
【図３】
2010049437.tif 000005
【図４】
2010049437.tif 000006