JP2022123392A - 対処策提案装置および対処策提案方法 - Google Patents

Abstract

【課題】ネットワーク接続を含む情報処理に係る障害に対して適切な対処策を提案する。【解決手段】対処策提案装置は、第１の保存部、第２の保存部、カテゴリ決定部、対処策特定部、対処策提示部を備える。第１の保存部は、各端末装置の動作状態および通信状態を表す端末関連情報を障害のカテゴリ毎にグループ化して保存する。第２の保存部は、障害のカテゴリ毎に設定される対処策に係わる対処策情報を保存する。対処策特定部は、端末装置の動作状態および通信状態を表す端末関連情報を含む提案依頼を受信したときに、提案依頼に含まれる端末関連情報と保存されている端末関連情報との比較に基づいて、提案依頼の送信元において発生した障害のカテゴリを決定する。対処策特定部は、決定されたカテゴリを用いて対処策情報を検索することにより、決定されたカテゴリに対応する対処策を特定する。対処策提示部は、特定された対処策を提案依頼の送信元に提示する。【選択図】図４

Description

本発明は、障害に対して対処策を提案する装置および方法に係わる。

近年、リモートワーク或いは在宅勤務が普及してきている。これに伴い、各ユーザがリモート環境で使用する端末装置、及び／又は、端末装置とサーバコンピュータとを接続するネットワークにおいて発生する障害が増加している。ところが、すべてのユーザのＩＣＴ（Information Communication Technology）リテラシが高いわけではないので、少なくないユーザが障害に適切に対処できていないと想定される。したがって、端末装置またはネットワークにおいて発生した障害を解決するためのツールが求められている。

なお、クライアント側情報処理装置に操作過程に関するヘルプ情報をホスト装置から通信回線を利用して提供するヘルプシステムが提案されている（例えば、特許文献１）。また、ネットワーク性能解析で使用するためのデータの収集を制御する装置が提案されている（例えば、特許文献２）。更に、過去の通信品質に基づき、これから行う通信の通信品質を予測してサービスの制御を行うシステムが提案されている（例えば、特許文献３）。

特開２００１－０２７９２３号公報 特開２０１４－２２５８８３号公報 特開２０１９－０２４１５４号公報

従来の診断ツールは、例えば、端末装置の状態またはサーバコンピュータへの疎通をモニタする。しかしながら、情報処理または通信技術についての十分な知識を有していないユーザにとっては、これらのモニタ結果に基づいて障害の原因を特定して対処することは困難である。例えば、クラウドサービスを利用できなくなったとき、或いは、リモート会議の音質が悪化したときに、端末装置に原因があるのか（ＣＰＵの過負荷、メモリ不足など）、無線状態に原因があるのか（干渉または混信に起因する信号強度の低下など）、インターネット環境に原因があるのか（キャリア障害、帯域圧迫など）、クラウド側に原因があるのか（アプリケーションの障害、同時アクセス数の超過など）を特定することが困難なことがある。

本発明の１つの側面に係わる目的は、ネットワーク接続を含む情報処理に係わる障害に対して適切な対処策を提案することである。

本発明の１つの態様に係わる対処策提案装置は、各端末装置の動作状態および通信状態を表す端末関連情報を障害のカテゴリ毎にグループ化して保存する第１の保存部と、障害のカテゴリ毎に設定される対処策に係わる対処策情報を保存する第２の保存部と、端末装置の動作状態および通信状態を表す端末関連情報を含む提案依頼を受信したときに、前記提案依頼に含まれる端末関連情報と前記第１の保存部に保存されている端末関連情報との比較に基づいて、前記提案依頼の送信元の端末装置において発生した障害のカテゴリを決定するカテゴリ決定部と、前記カテゴリ決定部により決定されたカテゴリを用いて前記第２の保存部に保存されている対処策情報を検索することにより、前記カテゴリ決定部により決定されたカテゴリに対応する対処策を特定する対処策特定部と、前記対処策特定部により特定された対処策を前記提案依頼の送信元に提示する対処策提示部と、を備える。

上述の態様によれば、ネットワーク接続を含む情報処理に係わる障害に対して適切な対処策を提案できる。

本発明の実施形態に係わるシステム構成の一例を示す図である。 対処策の提案を対処策提案装置に依頼する端末装置の処理の一例を示すフローチャートである。 提案依頼の一例を示す図である。 対処策提案装置の構成の一例を示す図である。 端末関連情報データベースおよびリコメンドテーブルの実施例を示す図である。 端末装置に表示される診断結果および対処策の提案の一例を示す図である。 端末装置および対処策提案装置の処理シーケンスの一例を示す図である。 対処策提案装置の処理の一例を示すフローチャートである。 更新後の端末関連情報データベースおよびリコメンドテーブルの実施例を示す図である。 対処策提案装置が端末装置に対処策を提示する手順を模式的に示す図（その１）である。 対処策提案装置が端末装置に対処策を提示する手順を模式的に示す図（その２）である。

図１は、本発明の実施形態に係わるシステム構成の一例を示す。図１において、対処策提案装置１は、端末装置２と通信可能に構成されている。すなわち、端末装置２は、ネットワークを介して対処策提案装置１に接続することができる。また、端末装置２は、例えば、パーソナルコンピュータ、スマートフォン、タブレット等の通信機能を有する情報処理機器により実現される。

端末装置２において障害が発生したとき、端末装置２は、ユーザからの指示に応じて、対処策提案装置１に対してその障害の対処策の提案を依頼することができる。例えば、端末装置２ａは、ユーザＡからの指示に応じて、対処策提案装置１に対して障害の対処策の提案を依頼できる。障害は、端末装置２の動作の異常および端末装置２による通信の異常を含む。そして、端末装置２は、端末装置２の動作状態および通信状態を表わす端末関連情報を取得し、その端末関連情報を対処策提案装置１に送信する。そうすると、対処策提案装置１は、端末装置２からの依頼に応じて１または複数の対処策を提示する。

ユーザは、対処策提案装置１から提示された対処策を実行する。そして、ユーザは、提示された対処策の実行結果を対処策提案装置１に通知する。例えば、対処策提案装置１から対処策Ｋ１～Ｋ３が提示され、ユーザが対処策Ｋ３を実行することで問題が解決したものとする。この場合、対処策Ｋ３を実行することで問題が解決したことを表す評価結果が端末装置２から対処策提案装置１に送信される。

対処策提案装置１は、各端末装置２から受信した端末関連情報をデータベースに蓄積する。このとき、端末関連情報は、障害のカテゴリ毎にグループ化されて記憶装置に保存される。また、端末関連情報は、ユーザにより実行された対処策に紐づけて記憶装置に保存される。そして、対処策提案装置１は、問題を解決するための対処策の提案の依頼を受信すると、これらの情報に基づいて対処策を特定して提示する。

図２は、障害に対する対処策の提案を対処策提案装置１に依頼するときの端末装置２の処理の一例を示すフローチャートである。なお、この実施例では、端末装置２の動作状態および通信状態を診断する診断プログラムが端末装置２にインストールされているものとする。

障害発生時には、端末装置２のユーザは、この診断プログラムを使用する。診断プログラムが起動されると、端末装置２の表示デバイスに初期画面が表示される。初期画面は、診断開始ボタンを含む。そして、ユーザにより診断開始ボタンが押下されると、診断プログラムにより図２に示すフローチャートの処理が実行される。

Ｓ１において、診断プログラムは、端末装置（図２では、ＰＣ）２の動作状態を診断する。たとえば、診断プログラムは、アプリケーションインタフェース等を利用して、端末装置２のＣＰＵの使用率およびメモリの使用率などを検出する。そして、診断プログラムは、端末装置２において障害が発生しているか否かを判定する。一例としては、ＣＰＵ／メモリの使用率が５０パーセント以下であれば「良好（○）」、５１～９０パーセントであれば「警告（△）」、９０パーセントを越えるときは「異常（×）」と判定される。この後、診断プログラムは、Ｓ２において、端末装置２の動作状態についての判定結果を表示デバイスに表示する。

Ｓ３において、診断プログラムは、端末装置２とルータとの間が有線接続であるか無線接続（図２では、ＷｉＦｉ）であるかを判定する。また、診断プログラムは、アプリケーションインタフェース等を利用して、信号強度および使用周波数帯などを検出する。そして、診断プログラムは、端末装置２において障害が発生しているか否かを判定する。例えば、ＷｉＦｉの信号レベル（ＲＳＳＩ：Received Signal Strength Indicator）が－６０ｄＢｍ以上であれば「良好（○）」、－６１ｄＢｍ～－７０ｄＢｍであれば「警告（△）」、－７０ｄＢｍより低ければ「異常（×）」と判定される。この後、診断プログラムは、Ｓ４において、端末装置２とルータとの間の接続状態についての判定結果を表示デバイスに表示する。

Ｓ５において、診断プログラムは、インターネット環境を診断する。例えば、診断プログラムは、ＷｅｂＡＰＩまたはＨＴＴＰ／ＩＣＭＰなどを利用して、端末装置２とサーバコンピュータとの間の疎通状態などを確認する。そして、診断プログラムは、インターネット環境に障害が発生しているか否かを判定する。一例としては、診断プログラムは、インターネット上に設けられているＤＮＳサーバにＤＮＳパケットを送信し、名前解決が成功したときには「良好（○）」、名前解決が失敗したときには「異常（×）」と判定される。この後、診断プログラムは、Ｓ６において、インターネット環境についての判定結果を表示デバイスに表示する。

Ｓ７において、診断プログラムは、端末装置２が利用しているサービス（または、アプリケーソン）の状態を診断する。例えば、診断プログラムは、ＷｅｂＡＰＩまたはＨＴＴＰ／ＩＣＭＰなどを利用して、スループット、遅延時間、ジッタ（ゆらぎ）、パケット損失率（一定時間枠またはバースト）、経路の安定性などを検出する。そして、診断プログラムは、サービスの状態が正常であるか否かを判定する。すなわち、対象サービスの通信要件が満たされているか否かが判定される。一例としては、スループットが２Ｍｂｐｓ以上、遅延時間が１００ミリ秒以下、ジッタが任意の１５秒間隔で３０ミリ秒以下、かつパケット損失率が任意の１５秒間隔で１パーセント以下であれば「良好（○）」、いずれか１つの項目が満たされないときは「警告（△）」、すべての項目が満たされないときは「異常（×）」と判定される。この後、診断プログラムは、Ｓ８において、サービスの状態についての判定結果を表示デバイスに表示する。なお、Ｓ７～Ｓ８は、サービス毎に実行される。

Ｓ９において、診断プログラムは、Ｓ１～Ｓ８の診断において「異常」が検出されたか否かを判定する。そして、「異常」が検出されたときは、診断プログラムは、Ｓ１０において、Ｓ１～Ｓ８において得られた診断結果（即ち、端末装置２の動作状態および通信状態を表す端末関連情報）を含む提案依頼を対処策提案装置１に送信する。

図３は、提案依頼の一例を示す。提案依頼は、端末装置２において実行された診断プログラムを識別するクライアントＩＤおよび診断結果を含む。診断結果は、端末装置２の動作状態および通信状態を表す端末関連情報に相当し、文字列として、ＪＳＯＮ形式などでｈｔｔｐ／ｈｔｔｐｓを用いて対処策提案装置１に送信される。なお、図３に示す実施例では、端末装置２は、リモート会議サービスを使用している。そして、端末装置２の動作状態およびインターネット環境は「良好」である。ただし、ルータからの受信レベルがやや低く、ＷｉＦｉ環境は「警告」である。また、リモート会議サービスにおける遅延時間が大きく、その診断結果は「異常」である。

図４は、対処策提案装置１の構成の一例を示す。対処策提案装置１は、カテゴリ決定部１１、対処策特定部１２、対処策提示部１３、テーブル更新部１４、端末関連情報データベース２１、リコメンドテーブル２２を備える。なお、対処策提案装置１は、図４に示していない他の機能または要素を備えてもよい。

図５（ａ）は、端末関連情報データベース２１の一例を示す。端末関連情報データベース２１には、対処策提案装置１が過去に受信した提案依頼に含まれていた端末関連情報が保存される。図５（ａ）に示す例では、クライアントＥＶＵＥＫＪＤＪ、クライアントＣＩＯＮＢＮＫＳ、・・・、クライアントＳＨＪＳＢＶＮＫ、クライアントＪＧＩＲＨＵＢＭ・・・から受信した端末関連情報が端末関連情報データベース２１に保存されている。

端末関連情報は、障害に対応するカテゴリ毎にグループ化されて端末関連情報データベース２１に保存される。各障害カテゴリの内容は、例えば、対処策提案装置１の管理者により予め定義される。この実施例では、端末装置２と対象サービスを提供するサーバとの間の疎通の有無、対象サービスが要求する通信条件、ＷｉＦｉの電波強度、端末装置２が使用しているオペレーティングシステムなどの組合せに基づいて障害カテゴリが定義される。例えば、障害カテゴリＥＲＲ＿０１０５は、端末装置２と対象サービスを提供するサーバとの間の疎通が良好であり、且つ、対象サービスにおいて遅延時間が許容値を超えており、且つ、ＷｉＦｉの電波強度が警告レベルであり、且つ、端末装置のオペレーティングシステムがＷ＿ｖｅｒ１０である状態を識別する。また、障害カテゴリＥＲＲ＿０１０１は、端末装置２と対象サービスを提供するサーバとの間の疎通が不良であり、且つ、対象サービスにおいてジッタが許容値を超えており、且つ、対象サービスにおいてパケット損失率が許容値を超えており、且つ、ＷｉＦｉの電波強度が異常レベルであり、且つ、端末装置２のオペレーティングシステムがＷ＿ｖｅｒ８である状態を識別する。なお、端末関連情報データベース２１は、各端末装置の動作状態および通信状態を表す端末関連情報を障害のカテゴリ毎にグループ化して保存する保存部の一例である。

図５（ｂ）は、リコメンドテーブル２２の一例を示す。リコメンドテーブル２２には、各障害カテゴリに対する対処策が登録されている。この実施例では、障害カテゴリＥＲＲ＿０１０５に対して３つの対処策Ｋ１～Ｋ３が登録されている。なお、各障害カテゴリに対して登録される対処策は、例えば、対処策提案装置１の管理者により予め決定される。或いは、後で記載するが、ユーザからの通知に基づいて対処策が追加されるようにしてもよい。

加えて、リコメンドテーブル２２には、各対処策について解決数が登録される。解決数は、ユーザに対して提案した対処策がそのユーザにより実行され、実際に問題が解決したケースの数を表す。この実施例では、「ＥＲＲ＿０１０５」により識別される障害に対して対処策Ｋ１～Ｋ３が提案され、対処策Ｋ１を実行することで問題が解決したケースが５０件、対処策Ｋ２を実行することで問題が解決したケースが１００件、対処策Ｋ３を実行することで問題が解決したケースが７０件あったことを表している。なお、リコメンドテーブル２２は、障害カテゴリ毎に設定される１または複数の対処策に係わる対処策情報を保存する保存部の一例である。この場合、図５（ｂ）に示す「対処策」および「解決数」は、対処策に係わる対処策情報の一例である。

図４の説明に戻る。図４において、対処策提案装置１に提案依頼が到着すると、カテゴリ決定部１１、対処策特定部１２、および対処策提示部１３は、１または複数の対処策を特定して提案依頼の送信元に提示する。

カテゴリ決定部１１は、対処策提案装置１に到着した提案依頼に係わる障害が属するカテゴリを決定する。このとき、カテゴリ決定部１１は、端末関連情報データベース２１において、提案依頼に含まれる端末関連情報と最も類似する端末関連情報を含むクライアントＩＤを特定する。図５（ａ）に示す例では、端末装置２と対象サービスを提供するサーバとの間の疎通の有無、対象サービスが要求する通信条件、ＷｉＦｉの電波強度、端末装置２が使用しているオペレーティングシステムの組合せに基づいてクライアントＩＤが特定される。なお、数値データの比較においては、閾値範囲（例えば、±５パーセント）を設定してもよい。

例えば、図３に示す提案依頼が対処策提案装置１に到着するものとする。このケースでは、提案依頼の送信元の端末装置２において、対象サービスを提供するサーバとの間の疎通が良好であり、対象サービスの遅延時間が１１５ミリ秒であり、ＷｉＦｉの電波強度が－６３ｄＢｍである。そして、この提案依頼に含まれる端末関連情報は、図５（ａ）に示す端末関連情報データベース２１の１番目または２番目のレコードに記録されている端末関連情報と類似する。よって、この場合、「障害カテゴリＩＤ＝ＥＲＲ＿０１０５」が得られる。すなわち、カテゴリ決定部１１は、提案依頼の送信元において、「ＥＲＲ＿０１０５」により識別される障害が発生していると推定する。なお、対処策提案装置１に新たに到着した提案依頼に含まれる端末関連情報は、カテゴリ決定部１１が決定した障害カテゴリＩＤに紐づけられて端末関連情報データベース２１に追加される。

対処策特定部１２は、カテゴリ決定部１１が決定した障害カテゴリＩＤを用いてリコメンドテーブル２２を参照し、その障害カテゴリに対応する対処策を特定する。この実施例では、上述したように、カテゴリ決定部１１により「障害カテゴリＩＤ＝ＥＲＲ＿０１０５」が得られている。この場合、対処策特定部１２は、「ＥＲＲ＿０１０５」を用いて図５（ｂ）に示すリコメンドテーブル２２を検索することにより、複数の対処策Ｋ１～Ｋ３を得る。

対処策提示部１３は、予め決められているポリシに基づいて、対処策特定部１２により特定された対処策の中から１または複数の対処策を提示する。一例としては、対処策提示部１３は、「解決数が多い順に所定数の対処策を提示する」というポリシに従って対処策を提示する。図５（ｂ）に示す例では、対処策Ｋ１、Ｋ２、Ｋ３により問題が解決したケースがそれぞれ５０件、１００件、７０件である。この場合、所定数が「２」であれば、対処策Ｋ２および対処策Ｋ３が順番に提示される。また、所定数が「３」であれば、対処策Ｋ２、対処策Ｋ３、および対処策Ｋ１が順番に提示される。

対処策提示部１３により提示される１または複数の対処策は、提案データとして、提案依頼の送信元の端末装置２に送られる。そうすると、端末装置２は、提示された対処策を表示する。すなわち、端末装置２のユーザに対処策が提示される。

図６は、端末装置２に表示される診断結果および対処策の提案の一例を示す。この実施例では、端末装置２は、リモート会議アプリを実行しようとしている。なお、図６において、「ＰＣ」「ＷｉＦｉ」「インターネット」「ＶＰＮ」「リモート会議」に付与されている「ＯＫ」または「ＮＧ」は、端末装置２にインストールされている診断プログラムによる診断結果を表す。また、「診断結果」に係わる記述も診断プログラムにより作成される。

対処策は、対処策提案装置１から通知される。この実施例では、対処策提案装置１により３つの対処策が提示されている。ここで、３つの対処策は、他のユーザによる評価結果に基づく順番で表示される。具体的には、３つの対処策は、好意的な評価の数が多い対処策から順番に並べられている。すなわち、２０５件の好意的な評価が与えられた対処策が最も上部に表示され、８４件の好意的な評価が与えられた対処策が２番目に表示され、３件の好意的な評価が与えられた対処策が最も下部に表示されている。尚、図６に示す「好意的な評価」の数は、図５（ｂ）に示す解決数に相当する。

端末装置２のユーザは、対処策提案装置１から提示された対処策を実行する。このときユーザは、好意的な評価が多い対処策から順番に実行すると考えられる。そして、ユーザは、対処策についての評価を対処策提案装置１に通知する。例えば、対処策を実行することで問題が解決した場合は、ユーザは、実行した対処策に対して「笑顔」を表すアイコンを選択する。一方、対処策を実行しても問題が解決した場合は、ユーザは、実行した対処策に対して「不満顔」を表すアイコンを選択する。そうすると、ユーザにより選択されたアイコンを識別する情報が端末装置２から対処策提案装置１に送信される。この結果、対処策提案装置１は、提示した対処策に対する評価結果（すなわち、提示した対処策によって問題が解決したか否か）を認識できる。なお、図６に示す実施例では、各対処策が２つレベルで評価されているが、３以上のレベルで評価が行われるようにしてもよい。

対処策提案装置１は、端末装置２から評価結果を受信すると、リコメンドテーブル２２を更新する。すなわち、テーブル更新部１４は、端末装置２から受信する評価結果に基づいてリコメンドテーブル２２を更新する。例えば、図５（ｂ）に示すリコメンドテーブル２２に基づいて端末装置２に対処策Ｋ１～Ｋ３が提示され、端末装置２のユーザが対処策Ｋ２を実行することにより問題が解決したものとする。この場合、対処策Ｋ２により問題が解決したことを表す評価結果が端末装置２から対処策提案装置１に通知される。そうすると、テーブル更新部１４は、リコメンドテーブル２２において、対処策Ｋ２の解決数をインクリメントする。

なお、端末関連情報データベース２１およびリコメンドテーブル２２は、記憶装置２０に保存される。記憶装置２０は、例えば、対処策提案装置１を実現するコンピュータ内に実装される。或いは、記憶装置２０は、対処策提案装置１を実現するコンピュータに接続される。

また、カテゴリ決定部１１、対処策特定部１２、対処策提示部１３、テーブル更新部１４は、対処策提案装置１を実現するコンピュータ内に実装されるプロセッサ１０が対処策提案プログラム２３を実行することにより実現される。なお、対処策提案プログラム２３は、図４に示す例では記憶装置２０に保存されているが、本発明の実施形態はこの構成に限定されるものではない。例えば、対処策提案プログラム２３は、コンピュータに着脱可能な記録媒体に記録されていてもよい。この場合、プロセッサ１０は、この記録媒体から対処策提案プログラム２３を読み込んで実行する。あるいは、対処策提案プログラム２３は、ネットワーク上に設けられた不図示のプログラムサーバに保存されてもよい。この場合、プロセッサ１０は、このプログラムサーバから対処策提案プログラム２３を取得して実行する。

図７は、端末装置２および対処策提案装置１の処理シーケンスの一例を示す。なお、端末関連情報データベース２１およびリコメンドテーブル２２は、記憶装置２０に保存されているものとする。

端末装置２のユーザは、端末装置２の動作状態または通信状態の異常に気づいたときには、端末装置２に実装されている診断プログラムを使用して対処策の提案を受けることができる。この場合、ユーザは、診断プログラムを起動することで表示される初期画面において、診断開始ボタンを押下する。そうすると、端末装置２において診断プログラムにより図２に示すフローチャートの処理が実行される。この結果、端末装置２の動作状態および通信状態を表す端末関連情報が自動的に収集され、障害の有無が判定される。そして、障害が発生しているときは、端末装置２は、端末関連情報を含む提案依頼を対処策提案装置１に送信する。

対処策提案装置１は、提案依頼を受信すると、記憶装置２０に保存されている端末関連情報データベース２１およびリコメンドテーブル２２を参照して、端末装置２において発生している障害に対する対処策を特定する。そして、対処策提案装置１は、特定した対処策を端末装置２に提示する。なお、提案依頼に応じて対処策を特定して提示する処理は、後でフローチャートを参照して説明する。

端末装置２は、対処策提案装置１から提示される対処策を表示デバイスに表示する。例えば、図６に示すように、複数の対処策が提示される。この場合、複数の対処策は、他のユーザにより実行され、問題の解決に至った件数が多い順に表示される。そして、端末装置２のユーザは、対処策を実行する。

この後、ユーザは、対処策の評価を入力する。例えば、提示された対処策の中のある対処策を実行することにより問題が解決したときは、ユーザは、その対処策に対して、問題が解決したことを表す評価結果を入力する。一方、提示された対処策の中のある対処策を実行しても問題が解決しなかったときは、ユーザは、その対処策に対して、問題が解決しなかったことを表す評価結果を入力する。なお、対処策提案装置１から提示された対処策を実行しても問題が解決せず、他の対処策（以下、代替策）を実行することで問題が解決したときには、ユーザは、その代替策の内容を対処策提案装置１に通知してもよい。

対処策提案装置１は、端末装置２から評価結果または代替策を表す情報を受信する。そうすると、対処策提案装置１は、リコメンドテーブル２２を更新する。すなわち、評価結果を受信したときは、対処策提案装置１は、リコメンドテーブル２２において対応する対処策の解決数を更新する。例えば、図５（ｂ）に示す対処策Ｋ１～Ｋ３が端末装置２に提示され、対処策Ｋ２により問題が解決した旨の評価結果が対処策提案装置１に到着したものとする。この場合、対処策Ｋ２の解決数が１００人から１０１人に更新される。一方、代替策を表す情報を受信したときは、対処策提案装置１は、その代替策を「対処策Ｋ４」としてリコメンドテーブル２２に追加する。

図８は、対処策提案装置１の処理の一例を示すフローチャートである。なお、このフローチャートの処理は、端末装置２から提案依頼が送信されたときに実行される。提案依頼は、上述したように、端末装置２の動作状態および通信状態を表す端末関連情報を含む。ここで、提案依頼は、端末装置２において異常が検出されたときに送信される。よって、端末関連情報は、実質的に、端末装置２において発生した障害の内容を表す。

Ｓ１１において、対処策提案装置１は、端末装置２から提案依頼を受信する。即ち、対処策提案装置１は、端末装置２動作状態および通信状態を表す端末関連情報を受信する。

Ｓ１２～Ｓ１３において、カテゴリ決定部１１は、端末装置２から受信した端末関連情報と端末関連情報データベース２１に保存されている端末関連情報とを比較する。具体的には、カテゴリ決定部１１は、端末関連情報データベース２１から、端末装置２から受信した端末関連情報と一致する端末関連情報を抽出する。また、端末装置２から受信した端末関連情報と一致する端末関連情報が見つからないときは、カテゴリ決定部１１は、端末関連情報データベース２１から、受信した端末関連情報に最も類似する端末関連情報を抽出する。そして、Ｓ１４において、カテゴリ決定部１１は、受信した端末関連情報が、抽出した端末関連情報と同じ障害カテゴリに属すると判定する。すなわち、端末装置２において発生している障害のカテゴリが決定される。

Ｓ１５において、対処策特定部１２は、Ｓ１４で決定した障害カテゴリに対応する対処策を特定する。なお、各障害カテゴリに対して１または複数の対処策が予め対応づけられているものとする。例えば、図５（ｂ）に示す例では、リコメンドテーブル２２においてＥＲＲ＿０１０５により識別される障害カテゴリに対して３つの対処策Ｋ１～Ｋ３が対応づけられている。

Ｓ１６において、対処策提示部１３は、対処策特定部１２により特定された対処策を、解決数が多い順に並べる。図５（ｂ）に示すケースでは、対処策Ｋ２、対処策Ｋ３、対処策Ｋ１が順番に並べられる。そして、Ｓ１７において、対処策提示部１３は、解決数が多い順に並べられた複数の対処策を端末装置２に提示する。これにより、ユーザは、端末装置２において発生している障害を解決できる可能性が高い対処策を得ることができる。

Ｓ１８において、対処策提案装置１は、Ｓ１１で受信した端末関連情報を端末関連情報データベース２１に追加する。このとき、Ｓ１１で受信した端末関連情報は、Ｓ１４で決定した障害カテゴリに対応づけて端末関連情報データベース２１に保存される。例えば、端末関連情報データベース２１が図５（ａ）に示す状態であり、対処策提案装置１が図３に示す端末関連情報を受信したときは、端末関連情報データベース２１は図９（ａ）に示す状態に更新される。

この後、対処策提案装置１は、Ｓ１９において、端末装置２からの応答を待ち受ける。そして、端末装置２から対処策提案装置１に対処策についての評価結果が到着すると、テーブル更新部１４は、Ｓ２０において、リコメンドテーブル２２を更新する。すなわち、対処策提案装置１が提示した対処策により問題が解決したことを表す評価結果を受信したときには、テーブル更新部１４は、対応する対処策の解決数をインクリメントする。例えば、リコメンドテーブル２２が図５（ｂ）に示す状態であり、ユーザが対処策Ｋ２を実行することで問題が解決したことを表す評価結果を受信したときには、リコメンドテーブル２２は図９（ｂ）に示す状態に更新される。なお、対処策提案装置１が端末装置２に対処策を提示したときから所定期間内に応答を受信できないときは、対処策提案装置１は、図８に示すフローチャートの処理を終了してもよい。

このように、本発明の実施形態に係わる対処策提案方法によれば、ユーザが端末装置２にインストールされている診断プログラムを起動すると、端末装置２において発生した障害の内容を表す端末関連情報（端末装置２の動作状態および通信情報を表す情報を含む）が自動的に収集されて対処策提案装置１に送信される。そして、対処策提案装置１は、その端末関連情報に基づいて端末装置２で発生している障害を推定し、対応する対処策を提示する。したがって、端末装置２のユーザは、ＩＣＴに係わる知識が十分でなくても、発生した障害に対して適切な対処策を得ることができる。

加えて、端末装置２からの提案依頼に対して複数の対処策がある場合、対処策提案装置１は、過去に実際に問題を解決した件数が多い順にそれら複数の対処策を並べて端末装置２のユーザに提示する。したがって、ユーザは、問題を解決できる可能性が高い対処策から順番に実行することができる。

図１０～図１１は、対処策提案装置１が端末装置２に対処策を提示する手順を模式的に示す。この実施例では、図１０に示すように、ユーザＸが対処策提案装置１に対処策の提案を依頼する。この場合、ユーザＸが使用する端末装置から受信する端末関連情報と端末関連情報データベース２１に保存されている端末関連情報とが比較される。ここで、受信した端末関連情報とユーザＡの端末関連情報とが類似していると判定されるものとする。この場合、対処策提案装置１は、ユーザＡの端末関連情報に付与されている障害カテゴリＩＤ「０１０５」でリコメンドテーブル２２を検索して対応する対処策を特定する。この例では、３つの対処策（Ｋ１～Ｋ３）が得られる。

続いて、対処策提案装置１は、図１１に示すように、特定した３つの対処策を解決数が多い順に並べ替える。そして、対処策提案装置１は、並替え後の対処策をユーザＸの端末装置に送信する。この結果、ユーザＸは、これらの対処策を得ることができる。

＜バリエーション＞
図２に示す実施例では、端末装置２で実行される診断において異常が検出されたときに対処策提案装置１に端末関連情報が送信されるが、本発明はこの手順に限定されるものではない。例えば、診断において異常が検出されるか否かにかかわらず、端末装置２から対処策提案装置１に端末関連情報が送信されるようにしてもよい。この場合、対処策提案装置１が異常の有無を判定する。そして、異常が検出されたときは、対処策提案装置１は、図８に示す手順で端末装置２に対処策を提示する。一方、異常が検出されないときは、対処策提案装置１は、正常である旨のメッセージを端末装置２に送信する。

また、上述の実施例では、端末装置２から受信する端末関連情報と端末関連情報データベース２１に保存されている端末関連情報とを比較することで、端末装置２において発生している障害のカテゴリが判定されるが、本発明はこの手順に限定されるものではない。例えば、各障害カテゴリを定義するパラメータの範囲を予め設定しておき、端末装置２から受信する端末関連情報と各障害カテゴリを定義するパラメータの範囲とを比較することで、端末装置２において発生している障害のカテゴリを判定してもよい。

１ 対処策提案装置
２ 端末装置
１１ カテゴリ決定部
１２ 対処策特定部
１３ 対処策提示部
１４ テーブル更新部
２１ 端末関連情報データベース
２２ リコメンドテーブル
２３ 対処策提案プログラム

Claims (6)

1. 各端末装置の動作状態および通信状態を表す端末関連情報を障害のカテゴリ毎にグループ化して保存する第１の保存部および障害のカテゴリ毎に設定される対処策に係わる対処策情報を保存する第２の保存部にアクセス可能なプロセッサに、
   端末装置の動作状態および通信状態を表す端末関連情報を含む提案依頼を受信したときに、前記提案依頼に含まれる端末関連情報と前記第１の保存部に保存されている端末関連情報との比較に基づいて、前記提案依頼の送信元の端末装置において発生した障害のカテゴリを決定し、
   決定したカテゴリを用いて前記第２の保存部に保存されている対処策情報を検索することにより、決定したカテゴリに対応する対処策を特定し、
   特定した対処策を前記提案依頼の送信元に提示する
   処理を実行させる対処策提案プログラム。
2. 前記対処策情報は、各対処策についてのユーザによる評価を表す情報を含み、
   前記提案依頼に対して複数の対処策を特定したときに、前記評価に基づく順に前記複数の対処策を並べて前記提案依頼の送信元に提示する処理を前記プロセッサにさらに実行させる
   ことを特徴とする請求項１に記載の対処策提案プログラム。
3. 前記対処策情報は、各対処策について当該対処策を実行することにより問題が解決した数を表す解決数を含み、
   前記提案依頼に対して複数の対処策を特定したときは、前記解決数の多い順に前記複数の対処策を並べて前記提案依頼の送信元に提示する処理を前記プロセッサにさらに実行させる
   ことを特徴とする請求項１に記載の対処策提案プログラム。
4. 第１の対処策を実行することにより問題が解決したことを表す情報を受信したときに、前記第２の保存部に保存されている対処策情報中の前記第１の対処策の解決数をインクリメントする処理を前記プロセッサにさらに実行させる
   ことを特徴とする請求項３に記載の対処策提案プログラム。
5. 各端末装置の動作状態および通信状態を表す端末関連情報を障害のカテゴリ毎にグループ化して保存する第１の保存部および障害のカテゴリ毎に設定される対処策に係わる対処策情報を保存する第２の保存部を備えるコンピュータを用いて、
   端末装置の動作状態および通信状態を表す端末関連情報を含む提案依頼を受信したときに、前記提案依頼に含まれる端末関連情報と前記第１の保存部に保存されている端末関連情報との比較に基づいて、前記提案依頼の送信元の端末装置において発生した障害のカテゴリを決定し、
   決定したカテゴリを用いて前記第２の保存部に保存されている対処策情報を検索することにより、決定したカテゴリに対応する対処策を特定し、
   特定した対処策を前記提案依頼の送信元に提示する
   ことを特徴とする対処策提案方法。
6. 各端末装置の動作状態および通信状態を表す端末関連情報を障害のカテゴリ毎にグループ化して保存する第１の保存部と、
   障害のカテゴリ毎に設定される対処策に係わる対処策情報を保存する第２の保存部と、
   端末装置の動作状態および通信状態を表す端末関連情報を含む提案依頼を受信したときに、前記提案依頼に含まれる端末関連情報と前記第１の保存部に保存されている端末関連情報との比較に基づいて、前記提案依頼の送信元の端末装置において発生した障害のカテゴリを決定するカテゴリ決定部と、
   前記カテゴリ決定部により決定されたカテゴリを用いて前記第２の保存部に保存されている対処策情報を検索することにより、前記カテゴリ決定部により決定されたカテゴリに対応する対処策を特定する対処策特定部と、
   前記対処策特定部により特定された対処策を前記提案依頼の送信元に提示する対処策提示部と、
   を備える対処策提案装置。

Images