JP2010066841A - ヘルプデスク支援システム - Google Patents

Abstract

【課題】 ヘルプデスク業務において、過去の問合せ履歴情報を格納したデータベースから対応策を検索する検索時間を削減し、検索結果の精度を向上させる。
【解決手段】 ヘルプデスク支援システム（７００）は、ユーザＰＣ（１００）からログ情報、リソース情報を取得し、データベース群（４００）に格納する。ユーザから障害についての問合せを受けたヘルプデスクオペレータは、検索に用いるキーワードに加え、ユーザの利用するユーザＰＣ（１００）の識別番号をヘルプデスク端末（６００）に入力する。ヘルプデスク支援システム（７００）は、ヘルプデスク端末（６００）から受信した識別番号により障害の発生したユーザＰＣ（１００）のログ情報およびリソース情報を特定し、通常のキーワード検索に加え、特定したログ情報およびリソース情報を用いて、過去の問合せ履歴情報を格納したデータベースを検索する。
【選択図】 図１

Description

本発明は、端末装置を使用しているユーザからの問合せ内容に対しての回答を行うヘルプデスク業務を支援する技術に関する。その中でも特に、ヘルプデスクオペレーターが回答する際に、対応履歴ＤＢからある程度、問合せ内容に対する回答（対応策）を効率的に絞り込む技術に関する。

社内などで使用している端末装置で発生した障害に対して、ヘルプデスクでは、まず障害が発生した端末装置のユーザからの電話、メール、FAXなどをヘルプデスクオペレーターが受け付ける。ヘルプデスクオペレーターはユーザから障害に対する状況情報を収集した上で、過去の問合せ履歴情報について履歴情報データベースを検索し、該当する障害情報があれば、その対応策をユーザへ回答する。回答を受けたユーザはヘルプデスクオペレーターから指示された対応策をもとに障害の対応を行う。ヘルプデスクオペレーターが、過去の問合せ履歴情報検索し、確認できなかった場合、システム担当者などへ対応依頼をしていた。

従来、このようなヘルプデスクの業務を支援する技術として、特許文献１に開示される技術が開示されている。特許文献１においては、ヘルプデスクシステムが過去のＱ＆Ａが蓄積されたデータベースを保有しており、この過去のＱ＆Ａをもって、ヘルプデスクオペレーターと専門家の２段階の回答ルートをもつ回答自動送付方式を取り入れたアイディアである。

特開平１１−０２５１７４号公報

しかしながら、特許文献１においては、予め登録されている顧客からの問い合わせ内容に対して、過去のＱ＆Ａが蓄積されたデータベースから検索を行っているため、同じ障害に対する問合せ内容も表現によっては検索に時間を要してしまい、適切な回答を得るまでに時間がかかるという課題がある。また、問い合わせ内容によっては原因が複数考えられることもあり、それらによって提示する解決策も複数挙がってくるため、最適な解決策を顧客に回答するまでに時間を要してしまい、効率的ではない。

そこで、本発明では、過去の問合せ履歴情報（問合せおよび回答）に対応付けて、端末装置が障害発生時に出力するエラーログやリソース使用状況についての情報を記憶装置に記憶しておく。また、ユーザの使用する端末装置から出力されるエラーログやリソース使用状況についても端末装置の識別情報と共に記憶装置に記憶する。ヘルプデスクのオペレータがユーザからの問合せを受けた際には、問合せを行った顧客の利用する端末装置の識別番号をオペレータが利用するオペレータ端末に入力することで、入力された識別番号により識別される端末装置が出力したエラーログやリソース状況の情報を記憶装置から抽出する。更に、抽出されたエラーログやリソース状況についての情報に対応付けられた過去の問合せ履歴情報（問合せおよび回答）を記憶装置から抽出することにより、ユーザの問合せについての対応策を絞り込んで特定することができる。

エラーログ、リソース使用状況に関する情報を用いて、過去の問合せ履歴情報を格納したデータベースから対応策を絞り込みながら検索を行えることから、よりユーザに対して確実性の高い対応策を提示し、ユーザへの回答時間を短縮することができる

以下、本発明の実施形態を図面に基づいて説明する。
図１は、本実施形態によるヘルプデスク支援システムの全体構成を示す図である。

図1に示すように、ヘルプデスク支援システム（７００）はログ監視システム（２００）、リソース監視システム（３００）、データベース群（４００）、対応業務サーバ（５００）及びヘルプデスクオペレーターが使用するヘルプデスク端末（６００）とを備えて構成されている。

ユーザＰＣ（１００）は、企業の会社員等に個別に割り当てられたＰＣである。ユーザＰＣ（１００）は、ソフトウェアやハードウェアで発生した事象をイベントログとして出力し、ログ監視サーバ（２００）へ送信している。ログ監視サーバ（２００）のイベントログ監視部（２１０）によって、イベントログの種類のエラーのみを受信し、その他のイベントログの種類に関しては破棄する。また、リソース情報について、日付、時刻、ＣＰＵ利用率（％）、メモリ使用量（Ｂ）、ディスク使用量（Ｂ）、ネットワーク利用率（％）の情報蓄積を行っている。リソース情報の取得タイミングは障害が発生した時である。

ユーザＰＣ（１００）では、ユーザＰＣ（１００）で出力したイベントログをログ監視サーバへ送信している。イベントログとは、ユーザＰＣのハードウェア（ＨＷ）（８３４）、ソフトウェア（ＳＷ）上で発生した事象をオペレーションシステム（ＯＳ）が検知した際、どのような事象が発生したかを記録した情報である。検知した事象がデータベースに随時格納されていく仕組みになっている。

図１４に、イベントログについて概念図を示す。ＨＷ（８３４）上で発生した障害情報をＯＳ（８３３）が検知し、データベース（８３５）に格納する。また、ＡＰ（８３１）上で発生した障害情報をＡＰＩ（８３２）を介してＯＳが検知し、データベース（８３５）に格納する。矢印は障害情報の流れを示す。イベントログは、イベント種類、イベントソース、イベントＩＤ、イベントメッセージから成り立っている。イベント種類には、障害のレベルに応じて、情報、警告、エラーの３種類がある。

図１５にイベントソースとイベントＩＤを説明するための概念図を示す。ＯＳ上では、複数のアプリケーション（ＡＰ）およびハードウェア（ＨＷ）が動作しており、その中で、様々な機能を有している。イベントソース（８４１）は、事象を発生させたアプリケーションやハードウェアを区別するための名称である。つまり、ＯＳ上の複数のアプリケーションやハードウェアの内、どのアプリケーションやハードウェアで障害が発生しているのかを特定することができる。イベントＩＤ（８５１）は、アプリケーションやハードウェアのどの機能に対して障害が発生しているかの詳細を知ることができる。イベントメッセージはアプリケーションやハードウェアで発生した事象についての詳細な説明が記載されている。イベントログは、イベント種類、イベントソース、イベントＩＤによって、ユーザＰＣ内で起こっている事象を詳細に知る事ができるように構成されている。

ログ監視サーバ（２００）は、ユーザＰＣ（１００）で出力されたイベントログを監視してイベントログの種類がエラーであるかを判定するイベントログ監視部（２１０）と、エラーと判定されたイベントログを抽出するイベントログ抽出部（２２０）と、イベントログ抽出部（２２０）で抽出したイベントログをイベントログＤＢ（４１０）に格納するためのイベントログ登録部（２３０）で構成されている。

リソース監視サーバ（３００）は、ユーザＰＣ（１００）で出力されたリソース情報を抽出するリソース情報抽出部（３１０）と、抽出したリソース情報をＤＢに格納するためのリソース情報登録部（３２０）から構成されている。

データベース群（４００）は、イベントログＤＢ（４１０）、リソース情報ＤＢ（４２０）、顧客情報ＤＢ（４３０）、イベントコードＤＢ（４４０）、対応履歴ＤＢ（４５０）、リソースコードＤＢ（４６０）で構成されている。

イベントログＤＢ（４１０）はユーザＰＣから収集したイベントログを格納している。イベントログＤＢ（４１０）では図５のように、日付、時刻、ソース、イベント種類、イベントＩＤ、コンピュータ名が格納されている。イベントログＤＢ（４１０）のソースとイベントＩＤによって、イベントコードＤＢ（４４０）のイベントコードを検索することが出来る。

リソース情報ＤＢ（４２０）はユーザＰＣから収集したリソース情報を格納している。リソース情報ＤＢ（４２０）では図６のように、コンピュータ名、日付、時刻、ＣＰＵ利用率（％）、メモリ使用量（Ｂ）、ディスク使用量（Ｂ）、ネットワーク利用率（％）が格納されている。リソース情報ＤＢ（４２０）はＣＰＵ利用率（％）、メモリ使用量（Ｂ）、ディスク使用量（Ｂ）、ネットワーク利用率（％）によって、リソースコードＤＢ（４６０）のリソースコードを検索することが出来る。

顧客情報ＤＢ（４３０）は図７のように、ユーザＩＤ、コンピュータ名、所属部署、住所、氏名、外線、内線、ＦＡＸ、メールアドレスが格納されている。顧客情報ＤＢ（４３０）のユーザＩＤからコンピュータ名を検索することができる。

イベントコードＤＢ（４４０）は図８のように、イベントコード、ソース、イベント種類、イベントＩＤが格納されている。

対応履歴ＤＢ（４５０）は図９のように、ユーザＩＤ、コンピュータ名、イベントコード、リソースコード、原因、現象、対策が格納されている。

リソースコード（４６０）は図１０のように、リソースコード、ＣＰＵ利用率（％）、メモリ使用量（Ｂ）、ディスク使用量（Ｂ）、ネットワーク利用率（％）が格納されている。イベントコードＤＢ（４４０）、対応履歴ＤＢ（４５０）、リソースコード（４６０）はイベントコードとリソースコードによって対応付けられている。

対応業務サーバ（５００）はヘルプデスク端末（６００）からの情報を受信してデータベース群のデータを検索する装置であり、リソース情報検索部（５１０）、顧客情報検索部（５２０）、イベントログ検索部（５３０）、対応履歴登録部（５４０）、キーワード検索部（５５０）、イベントコード検索部（５６０）、リソースコード検索部（５７０）で構成されている。

リソース情報検索部（５１０）では、データベース群（４００）のリソース情報ＤＢ（４２０）を、コンピュータ名をキーに、日付、時刻、ＣＰＵ利用率（％）、メモリ使用量（Ｂ）、ディスク使用量（Ｂ）、ネットワーク利用率（％）を検索することができる。顧客情報検索部（５２０）では、データベース群（４００）の顧客情報ＤＢ（４３０）を、ユーザＩＤをキーに、コンピュータ名、所属部署、住所、氏名、外線、内線、ＦＡＸ、メールアドレスを検索することができる。

イベントログ検索部（５３０）では、データベース群（４００）のイベントログＤＢを、コンピュータ名をキーに、日付、時刻、ソース、イベントＩＤを検索することができる。

対応履歴登録部（５４０）では、データベース群（４００）の対応履歴ＤＢ（４５０）へ、ユーザＩＤ、コンピュータ名、イベントコード、リソースコード、原因、現象、対策を登録することができる。

キーワード検索部（５５０）では、データベース群（４００）の対応履歴ＤＢ（４５０）に格納された文字列データをキーワードで検索することができる。

イベントコード検索部（５６０）では、データベース群（４００）のイベントコードＤＢ（４４０）を、ソースとイベントＩＤをキーに、イベントコードを検索することができる。

リソースコード検索部（５７０）では、データベース群（４００）のリソースコードＤＢ（４６０）を、ＣＰＵ利用率（％）、メモリ使用量（Ｂ）、ディスク使用量（Ｂ）、ネットワーク利用率（％）をキーに、リソースコードを検索することができる。

次に図２のフローチャートに従って説明する。
ログ監視サーバ（２００）のイベントログ監視部（２１０）は、ユーザＰＣ（１００）で出力されるイベントログを監視（取得）することにより（Ｓ１００）、
イベントログの種類を判定する。イベントログの種類がエラーと判定された場合、ログ監視サーバ（２００）のイベントログ抽出部（２２０）はエラーと判定されたイベントログをユーザＰＣ（１００）から抽出する（Ｓ１０２）。ログ監視サーバ（２００）のイベントログ登録部（２３０）は、イベントログ抽出部（２２０）によって抽出されたイベントログをイベントログＤＢへ格納する（Ｓ１０４）。イベントログの種類がエラーと判定されなければ、イベントログ登録部（２３０）はイベントログをイベントログDBに格納せずに、ログ監視サーバのメモリからイベントログを削除する。

また、イベントログ抽出部（２２０）は、イベントログを抽出した場合、エラーフラグ：１を出力し、エラーフラグの情報をリソース監視サーバ（３００）に送信するし（Ｓ１０３）。リソース監視サーバ（３００）はログ監視サーバ（２００）から送信されたエラーフラグ：１の情報を受信する（Ｓ１０５）。リソース監視サーバ（３００）のリソース情報抽出部（３１０）は、エラーフラグ：１の情報を受信すると、ユーザＰＣ（１００）からリソース情報を抽出（取得）する（Ｓ１０６）。

リソース監視サーバ（３００）のリソース情報登録部（３２０）は、ユーザＰＣからリソース情報を抽出したら、抽出したリソース情報データベース群（４００）のリソース情報ＤＢ（４２０）に格納する。

次に図３及び図４のフローチャートについて実施例を用いて説明する。
まず現場（営業所、公務所など）のユーザから障害の問合せがヘルプデスクオペレーターへ上がると、まずヘルプデスクオペレーターはユーザからユーザＩＤを聞きだし、また障害が発生した時刻を聞きだす。ヘルプデスクオペレーターはヘルプデスク端末画面上の図１１に示す検索画面において、ユーザＩＤ、キーワード（問合せ内容）、ログ・リソース検索範囲を入力し、検索ボタンを押し検索を開始する。

対応業務サーバ（５００）は、ヘルプデスク端末から入力された情報（ユーザＩＤ、キーワード、ログ・リソース検索範囲、等）を受信する。対応業務サーバ（５００）の顧客情報検索部（５２０）は、受信したユーザＩＤから顧客情報ＤＢ（４３０）に格納されているコンピュータ名を検索する（Ｓ２００）。次に、対応業務サーバ（５００）のキーワード検索部（５５０）は、受信したキーワードにより、対応履歴ＤＢ（４５０）の「現象」（障害の現象に関する情報が格納）に格納された文字列データを検索する。本例では、キーワード「メール送信」により、対応履歴ＤＢの「現象」に格納された文字列データにキーワードが含まれるか検索する（Ｓ２０１）。

対応業務サーバ（５００）は、検索結果の件数が、予め設定された対応策を絞り込むための閾値の件数を超えるかを判定する。検索結果の件数が閾値の件数を超えない場合、検索結果の一覧をヘルプデスク端末画面上に表示する（Ｓ２０４）。検索結果の件数が閾値の件数以上の場合、対応業務サーバ（５００）のイベントログ検索部（５３０）は、Ｓ２００で検索したコンピュータ名からイベントログＤＢ（４１０）に格納されているイベントログの検索を行う（Ｓ２０３）。なお、Ｓ２０３でイベントログＤＢ（４１０）を検索する際には、受信したログ・リソース検索範囲（日時の検索範囲）のなかでの検索を行う。

次に、対応業務サーバ（５００）は、Ｓ２０３において、イベントログＤＢからの検索結果が存在するか（イベントログのエラーが発生しているか）を判定する（Ｓ２０６）。

検索結果が存在しなかった場合には、問合せ対象のユーザ端末（１００）からはイベントログのエラーが出力されなかったことになるので、問合せの原因としてはオペレーションミスである可能性が高いので、対応履歴ＤＢ（４５０）の「原因」（障害の原因を示す情報が格納）に格納された情報が「オペレーションミス」である項目を抽出し、ヘルプデスク端末の画面上に表示する。また、障害の原因が「オペレーションミス」である可能性が高いことを示すメッセージもヘルプデスク端末の画面上に表示する（Ｓ２０５）。

例えば、ユーザから、「メール送信ができない。」という問合せ内容があった場合、ヘルプデスクオペレーターはユーザからユーザＩＤを聞きだし、図１１の検索画面（８００）にユーザＩＤとキーワード（「メール送信」）とログ・リソース検索範囲を入力し検索する。

ログ・リソース検索範囲に関しては、ユーザから障害が発生した時刻を参考に、例えば、その発生時刻の30分前後に設定する。30分前後に発生しているイベントログのエラーとリソース情報を検索する。

ここでは、ユーザＩＤが1111222201のユーザから2008/01/15の18:32:30に発生した障害の問合せとし、問合せ時刻が2008/01/15の18:37:20だった場合、検索範囲は18:07:20から19:07:20と設定する。

キーワードに関しては、対応履歴ＤＢ（４５０）の現象に格納されている文章に一致するキーワードを確認する。図９の対応履歴ＤＢより、ここでは該当する障害履歴が５件導き出すことが出来る。イベントログが発生していなかったら、ユーザによるオペレーションミスということになり、図９の対応履歴ＤＢに格納されているオペレーションミスによる原因に該当する対応策を絞り込む。
オペレーションミスによる対応策の一例として、「送信先アドレスの入力」などである。今回の例ではイベントログが発生しているものとする。イベントログが発生していることから図９の障害履歴ＤＢ（４５０）に格納されている障害履歴が４件に絞ることが出来る。

検索結果が存在した（イベントログのエラーが検出された）場合、対応業務サーバ（５００）のリソース情報検索部（５１０）は、受信したコンピュータ名からリソース情報ＤＢに登録されているリソース情報を検索する。次に、リソース情報検索部（５１０）は、検索したリソース情報に基づいてリソースコードＤＢ（４６０）を検索し、ユーザＰＣ（１００）のリソース情報が分類されるリソースコードを特定する（Ｓ３００）。次に、対応業務サーバ（５００）は、リソースコードを特定できたかを判定する（Ｓ３０１）。

リソースコードを特定できた場合、特定したリソースコードにより対応履歴ＤＢを検索し、検索結果（特定したリソースコードに該当する対応履歴）が存在するかを判定する（Ｓ３０２）。
リソースコードが特定できなかった場合、イベントコードの検索（Ｓ３０５）に移る。

また、Ｓ３０２において検索結果が存在しなかった（対応履歴ＤＢに格納されている対応履歴がなかった）場合も同様にイベントコードの検索（Ｓ３０５）に移る。
Ｓ３０２において検索結果（該当する対応履歴）が存在した場合、検索結果の件数が、予め設定された対応策を絞り込むための閾値の件数を超えるかを判定する（Ｓ３０４）。

検索結果の件数が閾値の件数を超えない場合、検索結果の一覧をヘルプデスク端末画面上に表示する（Ｓ３１１）。

検索結果の件数が閾値の件数以上の場合、イベントソース検索部（５６０）はイベントソースとイベントＩＤに基づいてイベントコードＤＢからイベントコードを検索し、（Ｓ３０５）検索結果（該当するイベントコード）が存在するかどうかを判定する（Ｓ３０６）。
Ｓ３０６において検索結果が存在しなかった場合、未知の案件であることを示すメッセージをヘルプデスク端末に通知する（Ｓ３１０）。
Ｓ３０６において検索結果が存在した場合、対応業務サーバ（５００）はＳ３０２で検索した結果に対して、Ｓ３０５で特定したイベントコード（Ｓ３０６の検索結果）で更に検索することで、対応策の絞込みを行う（Ｓ３０７）。

対応業務サーバ（５００）は、Ｓ３０７において検索結果（イベントコードに該当する対応履歴）が存在するかを判定する（Ｓ３０８）。
Ｓ３０８において検索結果が存在しなかった場合、未知の案件であることを示すメッセージをヘルプデスク端末に通知する（Ｓ３１０）。
Ｓ３０８において検索結果が存在した場合、対応業務サーバ（５００）は、検索結果の件数が、予め設定された対応策を絞り込むための閾値の件数を超えるかを判定する（Ｓ３０９）。

検索結果の件数が閾値の件数を超えない場合、対応業務サーバ（５００）は、検索結果の一覧をヘルプデスク端末画面上に表示する（Ｓ３１１）。

検索結果の件数が閾値の件数以上の場合、対応業務サーバ（５００）は、未知の案件であることを示すメッセージをヘルプデスク端末に通知する（Ｓ３１０）。

例えば、イベントログの検索を行い、イベントログＤＢにユーザが使用しているコンピュータからイベントログが検出されたら、そのイベントログと同時に検出されたリソース情報を検索する。ユーザＩＤ1111222201からコンピュータ名ＦＢＤ10200079238を検出し、コンピュータ名からリソース情報を検索する。そのリソース情報からリソースコードＤＢからリソースコードを検索する。今回のリソース情報からリソースコードは1が検索される。この検索結果より図９の障害履歴ＤＢ（４５０）に格納されている障害履歴が３件に絞ることが出来る。

リソースコード1とキーワード（「メール送信ができない」）だけでは、対応履歴ＤＢから対応策を絞り込むことができないと判断された場合（該当件数以上だった場合）、イベントログを検索する。コンピュータ名と日付と時刻からイベントログＤＢに格納されているイベントソースとイベントＩＤを検索する。ここでは、イベントソースはＳＷＭＡＩＬ、イベントＩＤは３を検出することができる。イベントソース、イベントＩＤよりイベントコードＤＢに格納されているイベントコードを検索する。

ここでは、イベントコードがＣ280と検索される。キーワード（「メール送信できない」）とイベントコードとリソースコードより対応履歴ＤＢから原因がソフトウェアと１件に絞り込むことができ、対応策（「メールソフトのインストール」）を検索結果画面に表示することができる。

次に履歴登録方法について説明する。履歴登録方法は、ヘルプデスク端末から図１３の対応履歴登録画面（８２０）を開き、原因、対応策、コンピュータ名、ユーザＩＤ、イベントコード、リソースコード、キーワード（現象）が入力され、登録ボタンを押されることによって登録が完了する。

本実施の形態によれば、ヘルプデスク業務の支援システムにおいて、キーワードといった定性的情報に加え、エラーログ、リソース使用状況に関する定量的情報を用いて、過去の問合せ履歴情報を格納したデータベースから対応策を絞り込みながら検索を行えることから、よりユーザに対して確実性の高い対応策を提示し、ユーザへの回答時間を短縮することができる
以上、本発明の実施の形態について、その実施の形態に基づき具体的に説明したが、これに限定されるものではなく、その要旨を逸脱しない範囲で変更可能である。

ヘルプデスク支援システム イベントログ、リソース情報収集のフローチャート キーワード検索及びイベントログ検索によるフローチャート リソースコード検索とイベントコード検索によるフローチャート イベントログＤＢ リソース情報ＤＢ 顧客情報ＤＢ イベントコードＤＢ 対応履歴ＤＢ リソースコードＤＢ ヘルプデスク端末における対応策の検索画面 ヘルプデスク端末における検索結果画面 ヘルプデスク端末における対応履歴登録画面 イベントログの定義１ イベントログの定義２

符号の説明

１００ ユーザＰＣ
２００ ログ監視サーバ
３００ リソース監視サーバ
４００ データベース群
５００ 対応業務サーバ
６００ ヘルプデスク端末
７００ ヘルプデスク支援システム

Claims (4)

1. 顧客が使用する端末装置の障害についての問合せと前記問合せに対する回答と前記障害の発生時に前記端末装置が出力するエラーログとが対応付けて格納された回答履歴データベース、前記端末装置の識別番号と前記エラーログとが対応付けて格納されたログデータベースとを備えたヘルプデスク支援システムを用いた回答検索方法において、
   前記ヘルプデスク支援システムは、
   障害の発生した端末装置から前記エラーログを受信し、
   受信した前記エラーログを前記ログデータベースに格納し、
   障害についての顧客からの問合せを受けた端末装置の識別番号を受信し、
   受信した前記識別番号に対応付けられたエラーログを前記ログデータベースから抽出し、
   抽出したエラーログに対応付けられた問合せと前記問合せに対する回答とを前記回答履歴データベースから抽出することを特徴とする回答検索方法。
2. 顧客が使用する端末装置の障害についての問合せと前記問合せに対する回答と前記障害の発生時に前記端末装置が出力するリソース使用量を示すリソース情報とが対応付けて格納された回答履歴データベース、前記端末装置の識別番号と前記リソース情報とが対応付けて格納されたログデータベースとを備えたヘルプデスク支援システムを用いた回答検索方法において、
   前記ヘルプデスク支援システムは、
   障害の発生した端末装置から前記リソース情報を受信し、
   受信した前記リソース情報を前記ログデータベースに格納し、
   障害についての顧客からの問合せを受けた端末装置の識別番号を受信し、
   受信した前記識別番号に対応付けられたリソース情報を前記ログデータベースから抽出し、
   抽出したリソース情報に対応付けられた問合せと前記問合せに対する回答とを前記回答履歴データベースから抽出することを特徴とする回答検索方法。
3. 顧客が使用する端末装置の障害についての問合せと前記問合せに対する回答と前記障害の発生時に前記端末装置が出力するエラーログと前記障害の発生時に前記端末装置が出力するリソース使用量を示すリソース情報とが対応付けて格納された回答履歴データベース、前記端末装置の識別番号と前記エラーログと前記リソース情報とが対応付けて格納されたログデータベースとを備えたヘルプデスク支援システムを用いた回答検索方法において、
   前記ヘルプデスク支援システムは、
   障害の発生した端末装置から前記エラーログおよび前記リソース情報を受信し、
   受信した前記エラーログおよび前記リソース情報を前記ログデータベースに格納し、
   障害についての顧客からの問合せを受けた端末装置の識別番号を受信し、
   受信した前記識別番号に対応付けられたエラーログおよびリソース情報を前記ログデータベースから抽出し、
   抽出した前記リソース情報に対応付けられた問合せと前記問合せに対する回答とエラーログからなる回答結果を前記回答履歴データベースから抽出し、
   抽出した前記回答結果のなかから、前記ログデータベースから抽出した前記エラーログに対応付けられた問合せと前記問合せに対する回答とを前記回答履歴データベースから抽出することを特徴とする回答検索方法。
4. 請求項１および３に記載の回答検索方法において、
   前記ヘルプデスク支援システムは、
   受信した前記識別番号に対応付けられたエラーログを前記ログデータベースから抽出できなかった場合には、前記問合せについての回答をオペレーションミスによるものと判定することを特徴とする回答検索方法。

Images