(57)【特許請求の範囲】
【請求項１】
通信路を介して複数の顧客装置から障害通報（Ａ）を受け付けたとき、それ以前に同一顧客からの障害通報（Ｂ）があったかを調べ、
上記障害通報（Ｂ）がある場合、上記受け付けた障害通報（Ａ）と上記障害通報（Ｂ）との組み合わせが、障害通報の組み合わせを関連通報として登録した関連通報データベースに存在するかを調べ、上記組み合わせが登録されているとき、上記受け付けた障害通報（Ａ）を、上記障害通報（Ｂ）の関連通報として扱い、システム管理者への通知を省略するか、もしくは関連通報があったことをシステム管理者に通知する障害通報の通知方法であって、
障害通報（Ａ）を受け付けたとき、所定時間内に同一顧客からの障害通報があったかを調べ、該当する障害通報（Ｃ）があったとき、該障害通報（Ｃ）と上記受け付けた障害通報（Ａ）との組み合わせを、関連通報の候補として保持し、
上記組み合わせの候補が複数回発生したとき、該候補となった障害通報（Ａ，Ｃ）の組み合わせを関連通報として、上記関連通報データベースに登録する
ことを特徴とする障害通報の通知方法。
【請求項２】
通信路を介して顧客装置からの障害通報を受け付ける障害通報管理サーバと、受け付けた障害通報をシステムの管理者に通知する端末装置とから構成され、
上記障害通報管理サーバは、受け付けた障害通報を選択的に上記端末装置へ通知するための通報処理部と、障害通報の履歴を格納した障害通報履歴データベースと、障害通報の組み合わせを関連通報として格納した関連通報データベースとを備え、
上記通報処理部は、通信路を介して複数の顧客装置から障害通報（Ａ）を受け付けたとき、それ以前に同一顧客からの障害通報（Ｂ）があったかを調べ、
上記障害通報（Ｂ）がある場合、上記受け付けた障害通報（Ａ）と、上記障害通報（Ｂ）との組み合わせが、上記関連通報データベースに登録されているかを調べ、上記組み合わせが登録されているとき、上記受け付けた障害通報（Ａ）を、上記障害通報（Ｂ）の関連通報として扱い、システム管理者への通知を省略するか、もしくは関連通報があったことをシステム管理者に通知する障害通報の通知システムであって、
上記障害通報管理サーバは、さらに、関連通報作成部と、上記関連通報データベースを更新する更新部とを備え、
上記関連通報作成部は、障害通報（Ａ）を受け付けたとき、所定時間内に同一顧客からの障害通報があったかを調べ、該当する障害通報（Ｃ）があったとき、該障害通報（Ｃ）と上記受け付けた障害通報（Ａ）との組み合わせを、関連通報の候補として保持し、
上記更新部は、上記組み合わせの候補が複数回発生したとき、該候補となった障害通報（Ａ，Ｃ）の組み合わせを関連通報として、上記関連通報データベースに登録する
ことを特徴とする障害通報の通知システム。
【請求項３】
通信路を介して顧客装置からの障害通報を受け付ける障害通報管理サーバと、受け付けた障害通報をシステムの管理者に通知する端末装置から構成される障害通報の通知システムであって、
上記障害通報管理サーバは、受け付けた障害通報を選択的に上記端末装置へ通知するための通報処理部と、
障害通報の履歴を格納した障害通報履歴データベースと、
同一顧客から第２の所定時間（Ｔ２）内に受け付けた障害通報の組み合わせを関連通報として格納した関連通報データベースと、
関連通報作成部と、上記関連通報データベースを更新する更新部とを備え、
上記通報処理部は、障害通報（Ａ）を受け付けたとき、上記障害通報履歴データベースを参照して、第１の所定時間（Ｔ１）内に、同一顧客から障害通報があったかを調べ、  上記第１の所定時間（Ｔ１）内に、同一顧客から障害通報があったとき、上記受け付けた障害通報（Ａ）と、上記第１の所定時間（Ｔ１）内に同一顧客から受け付けた障害通報（Ｂ）との組み合わせが、上記関連通報データベースに存在するかを調べ、
上記関連通報データベースに、上記障害通報（Ａ，Ｂ）の組み合わせが登録されているとき、上記受け付けた障害通報（Ａ）を、上記第１の所定時間内に受け付けた同一顧客からの障害通報（Ｂ）の関連通報として扱い、システム管理者への通知を省略するか、もしくは関連通報があったことをシステム管理者に通知し、
第１の所定時間（Ｔ１）内に、同一顧客から障害通報がなかったとき、もしくは、上記関連通報データベースに上記障害通報の組み合わせが登録されていないとき、上記受け付けた障害通報（Ａ）をシステム管理者に通知し、
上記関連通報作成部は、障害通報（Ａ）を受け付けたとき、上記障害通報履歴データベースから、上記障害通報（Ａ）を受け付けた時刻から第２の所定時間（Ｔ２）内に受け付けた同一顧客からの障害通報（Ｃ）を抽出して、上記受け付けた障害通報と組合せ、該障害通報（Ｃ）と上記受け付けた障害通報（Ａ）との組み合わせを、関連通報の候補として保持し、
上記更新部は、上記関連障害通報の候補の発生回数をカウントし、このカウント値が所定値に達したとき、上記関連障害通報の候補を上記関連通報データベースに登録する
ことを特徴とする障害通報の通知システム。
【請求項４】
上記通報処理部は、受け付けた障害通報（Ａ）と上記第１の所定時間（Ｔ１）内に同一顧客から受け付けた障害通報（Ｂ）との組み合わせが、上記関連通報データベースに存在するかを調べる際、障害通報（Ａ）および障害通報（Ｂ）と、関連通報データベースに登録された障害通報の組み合わせの各障害通報における装置種類情報と障害メッセージとをそれぞれ比較し、それらのすべてが同一の場合に、上記障害通報（Ａ，Ｂ）の組み合わせが関連通報データベースに登録されていると判断する
ことを特徴とする請求項２または請求項３に記載の障害通報の通知システム。
【請求項５】
上記通報処理部は、上記関連通報データベースに、受け付けた障害通報（Ａ）に関連する障害通報との組み合わせが登録されているとき、
障害通報履歴データベースを参照して、該受け付けた障害通報（Ａ）に関連する最初に受け付けた障害通報（Ｄ）を調べ、上記受け付けた障害通報（Ａ）を該最初に受け付けた障害通報（Ｄ）に関連した障害通報としてシステム管理者に通知する
ことを特徴とする請求項２，３または請求項４に記載の障害通報の通知システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信路を介して複数の顧客装置からの障害通報を受け付け、受け付けた障害通報をコールセンター等に通知する障害通報の通知方法およびシステムに関する。
【背景技術】
【０００２】
顧客側装置とコールセンター（以下センターという）間をネットワークで接続し、装置の障害発生時にセンターに自動的に障害通報をｅ−ｍａｉｌなどで通知するサービスが行われている。
上記複数の装置が相互に接続されたシステムにおいて、ある装置に障害が発生すると、障害通報が通知されるが、その障害を相互に接続された装置がそれぞれ検知して、同様な通報が複数発生し、センターに通知されてしまうことがある。
例えば、図１４（ａ）に示すように、装置Ａで問題が発生した場合、装置Ａからの通報が発生するが、これを検知した装置Ｂ、装置Ｃからの通報も発生し、一つの問題が発生しただけなのにコールセンターには複数の通報が送られる。
すなわち、ある一装置の障害であるにもかかわらず、複数の障害通報が発生することでセンタに多数の通報が届き、通報対応のため、センターでは通報を一件一件確認していくことになり、多くの工数がかかってしまう。
【０００３】
以上のような問題を解決するものとして、例えば特許文献１には、同一障害メッセージの出力要求の発生回数が特定時間内において所定回数になったかをカウントし、このカウント結果に基づき、所定数の同一障害メッセージをマージして出力することにより、ネットワークのトラヒック量を削減するとともに、監視制御装置の負荷軽減するようにした障害発生通知抑制方法が記載されている。
また、特許文献２には、障害通報を一定時間データ格納テーブルに蓄積し、蓄積されたデータの範囲内で同一障害メッセージを一つだけ残し、さらに主原因障害のみを残して、影響障害を削除することにより、システム全体の負荷を軽減するようにした対象外情報の削除方式が記載されている。
【特許文献１】特開２００３−６００４号公報
【特許文献２】特開平５−９５３５７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上記従来技術に記載のものは、同一障害メッセージをマージしたり削除するものであるが、障害メッセージが異なっていても実質的には関連した通報であるという状況が生じることもあり、このような場合に上記公知例では処理することができない。
例えば、各々の装置のバージョンやメーカーが異なる場合に同一の障害であっても、障害メッセージが必ずしも同一とは限らない。
上記問題を解決するには、例えば、予め、同一の原因により発生した関連した通報（以下、関連通報と言う）として考えられる障害メッセージの組合せをデータベース（以下ＤＢともいう）に登録しておき、障害メッセージを受信した際に、その前に受信した障害メッセージとの組み合わせが、上記ＤＢに登録された障害メッセージの組合せと同一であれば、関連通報であると判断して送信しないようにすることが考えられる。
例えば図１４（ｂ）に示すように、装置Ａ，Ｂ，Ｃからの通報を上記ＤＢを参照することにより同一原因により発生した関連通報と判断し、選別してセンター対応者に渡す。
しかし、この場合には、上記ＤＢを手作業で入力するなどして作成する必要があり、ＤＢの作成作業が煩雑となるとともに、上記ＤＢを適宜更新していく必要があり、更新作業も困難である。
本発明は上記問題点を解決するためになされたものであって、本発明の目的は、障害メッセージが異なっていても、同一原因から生じた通報であると考えられる場合には関連通報として処理することで、コールセンターの障害通報確認業務の工数を削減するとともに、上記関連通報として扱うべき障害メッセージの組合せを自動的に判断し、関連通報と考えられる障害メッセージの組合せを登録したデータベースを自動的に更新できるようにすることである。
【課題を解決するための手段】
【０００５】
本発明においては、上記課題を次のように解決する。
（１）通信路を介して複数の顧客装置から障害通報（Ａ）を受け付けたとき、それ以前に同一顧客からの障害通報（Ｂ）があったかを調べ、上記障害通報（Ｂ）がある場合、上記受け付けた障害通報（Ａ）と上記障害通報（Ｂ）との組み合わせが、障害通報の組み合わせを関連通報として登録した関連通報データベースに存在するかを調べ、上記組み合わせが登録されているとき、上記受け付けた障害通報（Ａ）を、上記障害通報（Ｂ）の関連通報として扱い、システム管理者への通知を省略するか、もしくは関連通報があったことをシステム管理者に通知する障害通報の通知方法もしくはシステムにおいて、以下のようにして上記関連通報データベースに関連する障害通報の組合せを登録する。
障害通報（Ａ）を受け付けたとき、所定時間内に同一顧客からの障害通報があったかを調べ、該当する障害通報（Ｃ）があったとき、該障害通報（Ｃ）と上記受け付けた障害通報（Ａ）との組み合わせを、関連通報の候補として保持し、上記組み合わせの候補が複数回発生したとき、該候補となった障害通報（Ａ，Ｃ）の組み合わせを関連通報として、上記関連通報データベースに登録する。
（２）通信路を介して顧客装置からの障害通報を受け付ける障害通報管理サーバと、受け付けた障害通報をシステムの管理者に通知する端末装置から構成される障害通報の通知システムにおいて、上記障害通報管理サーバに、受け付けた障害通報を選択的に上記端末装置へ通知するための通報処理部と、障害通報の履歴を格納した障害通報履歴データベースと、同一顧客から第２の所定時間（Ｔ２）内に受け付けた障害通報の組み合わせを関連通報として格納した関連通報データベースと、関連通報作成部と、上記関連通報データベースを更新する更新部とを設ける。
上記通報処理部は、障害通報（Ａ）を受け付けたとき、上記障害通報履歴データベースを参照して、第１の所定時間（Ｔ１）内に、同一顧客から障害通報があったかを調べ、上記第１の所定時間（Ｔ１）内に、同一顧客から障害通報があったとき、上記受け付けた障害通報（Ａ）と、上記第１の所定時間（Ｔ１）内に同一顧客から受け付けた障害通報（Ｂ）との組み合わせが、上記関連通報データベースに存在するかを調べる。
そして、関連通報データベースに、上記障害通報（Ａ，Ｂ）の組み合わせが登録されているとき、上記受け付けた障害通報（Ａ）を、上記第１の所定時間内に受け付けた同一顧客からの障害通報（Ｂ）の関連通報として扱い、システム管理者への通知を省略するか、もしくは関連通報があったことをシステム管理者に通知する。
また、第１の所定時間（Ｔ１）内に、同一顧客から障害通報がなかったとき、もしくは、上記関連通報データベースに上記障害通報の組み合わせが登録されていないとき、上記受け付けた障害通報（Ａ）をシステム管理者に通知する。
さらに、上記関連通報作成部は、障害通報（Ａ）を受け付けたとき、上記障害通報履歴データベースから、上記障害通報（Ａ）を受け付けた時刻から第２の所定時間（Ｔ２）内に受け付けた同一顧客からの障害通報（Ｃ）を抽出して、上記受け付けた障害通報と組合せ、該障害通報（Ｃ）と上記受け付けた障害通報（Ａ）との組み合わせを、関連通報の候補として保持し、
上記更新部は、上記関連障害通報の候補の発生回数をカウントし、このカウント値が所定値に達したとき、上記関連障害通報の候補を上記関連通報データベースに登録する。
（３）上記（２）において、通報処理部は、受け付けた障害通報（Ａ）と上記第１の所定時間（Ｔ１）内に同一顧客から受け付けた障害通報（Ｂ）との組み合わせが、上記関連通報データベースに存在するかを調べる際、障害通報（Ａ）および障害通報（Ｂ）と、関連通報データベースに登録された障害通報の組み合わせの各障害通報における装置種類情報と障害メッセージとをそれぞれ比較し、それらのすべてが同一の場合に、上記障害通報（Ａ，Ｂ）の組み合わせが関連通報データベースに登録されていると判断する。
（４）上記通報処理部は、上記関連通報データベースに、受け付けた障害通報（Ａ）に関連する障害通報との組み合わせが登録されているとき、障害通報履歴データベースを参照して、該受け付けた障害通報（Ａ）に関連する最初に受け付けた障害通報（Ｄ）を調べ、上記受け付けた障害通報（Ａ）を該最初に受け付けた障害通報（Ｄ）に関連した障害通報としてシステム管理者に通知する。
【発明の効果】
【０００６】
本発明においては、以下の効果を得ることができる。
（１）同一原因から生じた障害通報を関連通報として処理し、システム管理者への通知を省略するか、もしくは関連通報があったことをシステム管理者に通知するようにしたので、コールセンター等における障害通報確認業務の工数を削減することができる。
関連通報を直近の通常通報の参考情報として、コールセンター等に通知することにより、障害の波及の程度を知る上での参考となる。
（２）関連通報として扱うべき障害メッセージの組合せを自動的に判断し、関連通報データベースを自動的に更新することができる。
このため、人手を要することなく、関連通報データベースを常に最新のものに更新し、これに基づき関連通報を自動的に判別することが可能となる。
【発明を実施するための最良の形態】
【０００７】
図１は本発明の実施例のシステム構成を示す図である。
同図において、障害通報管理サーバ１０はネットワーク３０を介して複数の顧客装置２０と接続されており、顧客装置２０で障害が発生したとき、顧客装置２０が発する障害通報を受け付ける。障害通報は図２に示すように、例えば、装置ＩＤ、障害メッセージ、日時などの情報からなる。
また、障害通報管理サーバ１０はオペレータ端末２１と接続されており、障害通報管理サーバ１０は後述するように受け付けた障害通報を選択的にオペレータ端末（以下端末という）２１へ通知する。
障害通報管理サーバ１０は、顧客装置２０からの障害通報を受け付ける受付部１と、受け付けた障害通報を選択的に端末２１に通知するための通報処理部２、障害通報を端末２１に出力する出力部５と、通報履歴ＤＢ１１、顧客情報ＤＢ１２を参照して受け付けた障害通報を組合せ、関連通報データを作成する関連通報データ作成部３と、候補ＤＢ１３、関連通報ＤＢ１４を更新する更新部４を備える。
【０００８】
図３は上記顧客情報ＤＢ１２に格納された情報の一例を示す図であり、同図に示すように、顧客を識別するための顧客ＩＤ、該顧客の装置ＩＤが格納される。
図４は上記通報履歴ＤＢ１１に格納される情報の一例を示す図であり、同図に示すように、顧客装置２０から通報された障害通報（日時、装置ＩＤ、メッセージ等）が日時順に格納される。なお、上記日時は障害発生日時、あるいは受信日時のいずれでもよい。
障害通報管理サーバ１０の受付部１が障害通報Ａを受け付けると、通報処理部２は、上記通報履歴ＤＢ１１、顧客情報ＤＢ１２を参照して、同一顧客からの障害通報が、予め定められた第１の所定時間Ｔ１内の過去にあったかを調べる。
そして、同一顧客からの障害通報が、予め定められた第１の所定時間Ｔ１内になかった場合には、該顧客からの通常の障害通報（以下、通常通報という）であるとして、この障害通報を端末２１へ通知する。また、同一顧客からの障害通報が、予め定められた第１の所定時間Ｔ１内の過去にあった場合には、受け付けた障害通報Ａと、上記所定時間Ｔ１内にあった同一顧客からの障害通報Ｂの組合せが関連通報ＤＢ１４に登録されているかを調べ、障害通報Ａ，Ｂの組合せが関連通報ＤＢ１４に登録されていれば、障害通報Ａを関連通報として扱う。関連通報の場合は、端末２１への通知を省略するか、関連通報であることを通知する。そして、受け付けた障害通報Ａを上記通報履歴ＤＢ１１に格納する。
【０００９】
図５は候補ＤＢ１３に格納される情報の一例を示す図である。候補ＤＢ１３は、関連通報作成部３で作成された障害通報の組合せを、関連通報の候補として保持するためのものであり、同図に示すように、同一顧客から所定時間内に通報された障害通報（装置名、メッセージ）の組合せ（関連通報の候補）と、その組合せが過去に何回発生したかを示すカウント値を保持する。
図６は上記関連通報ＤＢ１４に格納される情報の一例を示す図である。関連通報ＤＢ１４には、同図に示すように関連通報として扱うべき障害通報の組合せが格納される。
関連通報作成部３は、障害通報Ａを受け付けると、障害通報が通知されたとき、上記通報履歴ＤＢ１１、顧客情報ＤＢ１２を参照して、同一顧客からの障害通報が、予め定められた第２の所定時間Ｔ２内の過去にあったかを調べる。
そして、同一顧客からの障害通報が、予め定められた第２の所定時間Ｔ２内にあった場合は、所定時間Ｔ２内にあった障害通報Ｂと上記受け付けた障害通報Ａを組合せ、障害通報の組合せを、関連通報の候補とし上記候補ＤＢ１３に登録し、最初に登録したときにはカウント値を１とし、上記関連通報の候補が再度発生した場合にはカウント値をカウントアップする。
前記更新部４は、上記候補ＤＢ１３に格納された関連通報の候補の内、カウント値が予め設定された任意の設定値Ｎ１を超えた障害通報の組合せを関連通報として上記関連通報ＤＢ１４に登録する。
【００１０】
図７は上記障害通報の組合せの例を示す図である。同図に示すように、例えば『装置型名「ＭＦＶ５５５０」、障害メッセージ「ハードディスク故障」』という障害通報に対して、第１の第２の所定時間Ｔ２内に同一顧客から『装置型名「ＧＰＰ５３３４」、障害メッセージ「ハードディスク故障」』という障害通報があると、この障害通報の組合せが、関連通報の候補として上記候補ＤＢ１３に登録され、この障害通報の組合せが上記Ｎ１以上発生すると、関連通報として、関連通報ＤＢに登録される。
上記第１の所定時間（関連通報処理時の通報履歴検索時間間隔）Ｔ１、第２の所定時間（関連通報作成時の通報履歴検索時間間隔）Ｔ２、カウント値の設定値（関連通報確定任意カウント数）Ｎ１は、例えば図８に示すようにテーブルに格納される。
なお、上記第１、第２の所定時間をＴ１＞Ｔ２とすれば、関連通報を関連通報ＤＢの登録する際の判断基準を、関連通報として扱うか否かを判断するときの判断基準より厳しくすることができる。
【００１１】
図９は本実施例の動作を説明するためタイムチャートであり、同図により、通報を受け付けたときの動作を説明する。
（１）関連通報ＤＢに関連通報が登録される前の動作。
(i) 顧客装置側からの障害通報Ａを受け付けると、通報履歴ＤＢを参照し、障害通報Ａを受け付けてからＴ１時間遡り、その時間内に同一顧客から通報があったかを調べる。
Ｔ１時間内に通報がなければ、この通報を通常通報として、オペレータ側に通知する。なお、この段階では、関連通報ＤＢおよび候補ＤＢには障害通報の組合せは入っていないとする。
(ii)顧客装置側からの障害通報Ｂを受け付けると、通報履歴ＤＢを参照し、障害通報Ｂを受け付けてからＴ１時間内に同一顧客から通報があったかを調べる。
通報履歴ＤＢに登録されている障害通報Ａと障害通報ＢがＴ１時間内に受け付けたものであっても、同一顧客からの通報でなければ、この障害通報Ｂは、通常通報としてオペレータ側に通知される。
一方、上記障害通報Ａと障害通報Ｂが同一顧客からの通報の場合、障害通報Ａと障害通報Ｂの組合せが関連通報ＤＢに登録されているかを調べる。この段階では、関連通報ＤＢには関連通報が登録されていないので、障害通報Ｂは障害通報Ａの関連通報としては扱われず、障害通報Ｂは通常通報として、オペレータ側に通知される。
また、上記障害通報Ｂを受け付けてからＴ２時間内に同一顧客からの障害通報Ａが受け付けられていれば、障害通報Ａと障害通報Ｂの組み合わせを、候補ＤＢに追加する。
【００１２】
(iii) 以下同様に、障害通報Ａを受け付けたとき、関連通報ＤＢに関連通報が登録されていない場合には、受け付けた障害通報Ａを通常通報として処理しオペレータ側に通知する。
また、前記したように、通報履歴ＤＢを参照し、障害通報Ａを受け付けてからＴ２時間内に同一顧客から通報があったかを調べ、Ｔ２時間内に同一顧客からの障害通報Ｂが受け付けられていれば、障害通報Ａと障害通報Ｂの組み合わせを、候補ＤＢに追加（カウント値をカウントアップ）する。  
(iv)次いで、障害通報Ａを受け付けると、受け付けた障害通報Ａを通常通報として処理しオペレータ側に通知するとともに、通報履歴ＤＢを参照し、障害通報Ａを受け付けてからＴ２時間内に同一顧客から通報があったかを調べ、Ｔ２時間内に同一顧客からの障害通報Ｂあれば、候補ＤＢのカウント値をカウントアップする。
そして、候補ＤＢにおける障害通報Ａと障害通報Ｂの組み合わせのカウント値が前記した設定値Ｎ１に達すると、この障害通報Ａと障害通報Ｂの組み合わせが、関連通報ＤＢに関連する通報の組み合わせとして登録される。また、候補ＤＢに登録されている上記組み合わせは削除される。
【００１３】
（２）関連通報ＤＢに関連通報が登録されている場合における動作。
(i) 顧客装置側からの障害通報Ｂを受け付けると、通報履歴ＤＢを参照し、障害通報Ｂを受け付けてからＴ１時間内に同一顧客から通報があったかを調べる。
上記障害通報Ａと障害通報Ｂが同一顧客からの通報の場合、障害通報Ａと障害通報Ｂの組合せが関連通報ＤＢに登録されているかを調べる。関連通報ＤＢに障害通報Ａと障害通報Ｂの組み合わせが登録されている場合、障害通報Ｂは障害通報Ａの関連通報と判断する。
上記関連通報ＤＢに障害通報Ａと障害通報の組み合わせが登録されているかの判断は、各障害通報における装置種類情報と障害メッセージとをそれぞれ比較し、それらのすべてが同一の場合に、関連通報ＤＢに障害通報Ａと障害通報の組み合わせが登録されていると判断するのが望ましい。
受け付けた障害通報が関連通報と判断された場合、以下のような処理行なうことができる。
・直近の通常通報Ａの参考通報として、オペレータに通知する。
・直近の通常通報により状況が判明していることから、関連通報を削除しオペレータには通知しない。
【００１４】
(ii)次いで、障害通報Ａを受け付けると、上記と同様に、障害通報Ａを受け付けたときから遡ってＴ１時間内に同一顧客から通報があったかを調べる。同一顧客からの障害通報Ｂがあれば、障害通報Ａと障害通報Ｂの組合せが関連通報ＤＢに登録されているかを調べ、関連通報ＤＢに障害通報Ａと障害通報Ｂの組み合わせが登録されている場合、障害通報Ｂは障害通報Ａの関連通報と判断する。
そして、上記したように直近の通常通報Ａの参考通報として、オペレータに通知するか、あるいは、通報を削除する。
(iii) 次いで、障害通報Ｂを受け付けると、上記と同様に、障害通報Ｂを受け付けたときから遡ってＴ１時間内に同一顧客から通報があったかを調べる。この場合、Ｔ１時間内に同一顧客からの障害通報はないので、受け付けた障害通報を通常通報として、オペレータに通知する。
【００１５】
ここで、上記のように障害通報Ｂが関連通報として判断され、この関連通報を直近の通常通報Ａの参考通報としてオペレータに通知する場合、直近の通常通報Ａは例えば、次のようにして求めることができる。
・障害通報を通報履歴ＤＢに格納する際、各障害通報にＩＤを付す。
・障害通報Ｂがあり、この障害通報Ｂが障害通報Ａの関連通報の場合、通報履歴ＤＢの障害通報Ｂに、障害通報Ａに付されたＩＤと同一のＩＤを付す。
・次に、通報履歴ＤＢに格納された障害通報の内、障害通報Ｂと同一のＩＤが付されたものを調べ、その中で受け付けた時間の最も早い障害通報Ｃを抽出し、受け付けた障害通報Ｂは、通常通報である障害通報Ｃに関連した参考通報とする。
【００１６】
図１０〜図１３は本発明の実施例の処理を示すフローチャートであり、以下、同図により本実施例の処理について説明する。なお、図１０、図１１は、前記第１、第２の所定時間Ｔ１，Ｔ２の大小関係を規定しない場合、図１２、図１３はＴ１＞Ｔ２とした場合の処理を示すフローチャートである。
図１０、図１１において、ステップＳ１〜Ｓ６までの処理（図１０）は前記通報処理部における処理を示し、ステップＳ７〜Ｓ１７（図１１）の処理は関連通報データ作成部におけ処理を示している。
図１０において、障害通報を受信すると（ステップＳ１）、通報履歴ＤＢを参照して、ステップ１で受信した通報Ａより、任意に定められた時間Ｔ１遡った過去に通報があるかを調べる（ステップＳ２）。
時間Ｔ１遡った過去に通報がなければ、ステップＳ６に行き、受信した障害通報Ａを通常処理として処理する。
時間Ｔ１遡った過去に通報Ｂがあれば、顧客情報ＤＢを参照して、ステップＳ１で受信した障害通報Ａと、通報履歴ＤＢに格納されていた過去の障害通報Ｂが同一顧客ＩＤの装置からの通報であるかを調べる（ステップＳ３）。
同一顧客からの通報でなければ、ステップＳ６に行き、受信した障害通報Ａを通常処理として処理する。
【００１７】
また、同一顧客からの通報の場合、関連通報ＤＢに、前記ステップＳ１で受信した通報Ａと、通報履歴ＤＢに格納されていた過去の通報Ｂの組み合わせが存在しているかを調べる（ステップＳ４）。ここで、通報Ａ，Ｂの組み合わせが、関連通報ＤＢに格納されているか否かの判断は、装置型名、メッセージが一致しているかで判断する。
通報Ａ，Ｂの組み合わせが、関連通報ＤＢに格納されていない場合には、ステップＳ６に行き、受信した障害通報Ａを通常処理として処理する。
また、通報Ａ，Ｂの組み合わせが、関連通報ＤＢに格納されている場合には、ステップＳ１で受信した障害通報Ａを関連通報として処理する（ステップＳ５）。
障害通報Ａが関連通報と判断された場合には、前記したように直近の通常通報Ａの参考通報として、オペレータに通知するか、あるいは、通報を削除する。
【００１８】
次いで、図１１に行き、通報履歴ＤＢを参照して、ステップＳ１で受信した通報Ａより任意に定められた時間Ｔ２遡った過去に通報があるかを調べる（ステップＳ７）。
時間Ｔ２遡った過去に通報がなければ、ステップＳ１６に行く。
時間Ｔ２遡った過去に通報Ｃがあれば、顧客情報ＤＢを参照して、ステップＳ１で受信した障害通報Ａと、通報履歴ＤＢに格納されていた過去の障害通報Ｃが同一顧客ＩＤの装置からの通報であるかを調べる（ステップＳ８）。
同一顧客からの通報でなければ、ステップＳ１６に行く。
【００１９】
また、同一顧客からの通報の場合、関連通報ＤＢに、前記ステップＳ１で受信した通報Ａと、通報履歴ＤＢに格納されていた過去の通報Ｃの組み合わせが存在しているかを調べる（ステップＳ９）。通報Ａ，Ｃの組み合わせが、関連通報ＤＢに格納されている場合には、ステップＳ１６に行く。
また、通報Ａ，Ｃの組み合わせが、関連通報ＤＢに格納されていない場合には、候補ＤＢを参照して、通報Ａ，Ｃの組み合わせが存在しているかを調べる（ステップＳ１０）。  通報Ａ，Ｃの組み合わせが候補ＤＢに存在している場合には、候補ＤＢの通報Ａ，Ｃの組み合わせのカウント数を１増加する（ステップＳ１２）。また、通報Ａ，Ｃの組み合わせが候補ＤＢに存在していない場合には、候補ＤＢへ、通報Ａ，Ｃの組み合わせを追加する。また、追加した組合せのカウント数を１に設定する（ステップＳ１１）。
【００２０】
次いで、ステップＳ１３に行き、候補ＤＢを参照し、通報Ａ，Ｃの組み合わせのカウント数が、予め任意に設定されたカウント数Ｎ１に達しているかを調べる（ステップＳ１３）。カウント数がＮ１に達していなければ、ステップＳ１６に行く。
また、カウント数がＮ１に達すると、該当する通報Ａ，Ｃの組合せを関連通報ＤＢへ追加する（ステップＳ１４）。そして、該当する通報Ａ，Ｃの組み合わせを候補ＤＢから削除する（ステップＳ１５）。
次に、ステップＳ１６で、通報履歴ＤＢにステップＳ１で受信した通報を追加し、処理を終わる。
【００２１】
図１２、図１３はＴ１＞Ｔ２とした場合の処理を示すフローチャートである。前記と同様、ステップＳ１〜Ｓ６までの処理（図１２）は前記通報処理部における処理を示し、ステップＳ７〜Ｓ１７（図１３）の処理は関連通報データ作成部におけ処理を示している。  図１２、図１３のフローでは、Ｔ１＞Ｔ２としているので、ステップＳ４で、障害通報Ａと障害通報Ｂの組合せが関連通報ＤＢに登録されているとき、関連通報データ作成処理を行うことなく、ステップＳ１６へ行くようにするとともに、図１１に示したステップＳ９を削除したものであり、その他の処理は前記図１０、図１１に示したものと同じである。
【００２２】
なお、上記した実施例では、関連通報データベースにデータを追加登録していく場合について説明したが、関連通報データベースに登録されている関連通報の内、アクセス回数の少ない通報の組合せや、登録から所定期間経過した通報の組合せを自動的に削除するようにしてもよい。
【図面の簡単な説明】
【００２３】
【図１】本発明の実施例のシステム構成を示す図である。
【図２】障害通報の一例を示す図である。
【図３】顧客情報ＤＢに格納された情報の一例を示す図である。
【図４】通報履歴ＤＢに格納される情報の一例を示す図である。
【図５】候補ＤＢに格納される情報の一例を示す図である。
【図６】関連通報ＤＢに格納される情報の一例を示す図である。
【図７】障害通報の組合せの例を示す図である。
【図８】関連通報処理時及び関連通報作成時の通報履歴検索時間間隔Ｔ１，Ｔ２、関連通報確定カウント数Ｎ１を格納したテーブルの一例を示す図である。
【図９】本発明の実施例の動作を示すタイムチャートである。
【図１０】本発明の実施例の処理を示すフローチャート（１）である。
【図１１】本発明の実施例の処理を示すフローチャート（２）である。
【図１２】本発明の実施例の処理を示すフローチャート（３）である。
【図１３】本発明の実施例の処理を示すフローチャート（４）である。
【図１４】障害通報をコールセンターへ通報するシステムにおける問題点を説明する図である。
【符号の説明】
【００２４】
１      受付部
２      通報処理部
３      関連通報データ作成部
４      更新部
５      出力部
１０    障害通報管理サーバ
１１    通報履歴ＤＢ
１２    顧客情報ＤＢ
１３    候補ＤＢ
１４    関連通報ＤＢ
２０    顧客装置
２１    オペレータ端末
３０    ネットワーク
【図１】
0004679314.tif 000002
【図２】
0004679314.tif 000003
【図３】
0004679314.tif 000004
【図４】
0004679314.tif 000005
【図５】
0004679314.tif 000006
【図６】
0004679314.tif 000007
【図７】
0004679314.tif 000008
【図８】
0004679314.tif 000009
【図９】
0004679314.tif 000010
【図１０】
0004679314.tif 000011
【図１１】
0004679314.tif 000012
【図１２】
0004679314.tif 000013
【図１３】
0004679314.tif 000014
【図１４】
0004679314.tif 000015