JP2019500680A - データ処理方法及び装置 - Google Patents

Abstract

本発明の実施形態は、データ処理方法および装置を提供する。この方法は、ユーザとサーバとの間のインタラクションデータを取得するステップと、前記インタラクションデータに基づいて異常事象が発生したかどうかを検出するステップと、異常事象が発生した場合に、前記ユーザの属性情報を取得するステップと、ローカルに記憶された、前記異常事象に対応する属性情報、原因、及び重みの間の第１の対応関係を検索して前記属性情報と最大の重みとを含むレコードを特定するステップと、異常事象の原因を前記レコード内の原因と特定するステップとを含む。この全プロセスにおいて、ユーザはカスタマーサービス担当者と通信する必要はなく、カスタマーサービス担当者はユーザとの通信によって異常事象の原因を特定する必要はなく、異常事象の原因は、ユーザの属性情報と、異常事象に対応する属性情報、原因、及び重みの間の第１の対応関係とを用いることで特定される。したがって、人件費が節約される。

Description

本願は、２０１５年１１月１０日に提出され「データ処理方法及び装置」と題された中国特許出願第２０１５１０７６３２９０．Ｘ号の優先権を主張し、上記中国特許出願は参照によってその全体が本願に組み込まれる。

本発明は、コンピュータ技術の分野に関し、より詳細には、データ処理方法及び装置に関する。

現在、ユーザは、Ｗｅｂ（ウェブ）ページを閲覧したり、オンラインで支払いをしたり、端末装置にアカウントを登録するなどの操作を頻繁に行う。しかし、これらの操作は種々の理由で正常に実行できないことがある。たとえば、オンライン決済が失敗したり、閲覧されたＷｅｂページを表示することができなかったりすることがある。

一般的に、問題に遭遇した場合、ユーザは通常、手助けを得るためカスタマー（顧客）サービス担当者を呼び出す。この呼び出しの後、ユーザは、問題に関連する症状や、ユーザによって実行された直近の操作、あるいはサーバによって返された情報といった、問題に関する事項をカスタマーサービス担当者に説明する必要がある。カスタマーサービス担当者は、ユーザからの説明とカスタマーサービス担当者の専門知識に基づいて問題の原因を特定し、ユーザが問題を解決する手助けを行う。

しかしながら、ユーザが問題を明確に説明できない場合や、問題の見方が異なるために、カスタマーサービス担当者がユーザの説明を即座に完全には理解できない場合がある。その結果、カスタマーサービス担当者が問題の原因を突き止めるために追加の通信時間を要し、それによって人件費を増加させることがある。

本願発明は、関連する技術における問題を解決するための、データ処理方法及び装置を提供するものである。

本発明の実施形態の第１の態様によれば、データ処理方法が提供され且つサーバに適用され、当該方法は、ユーザとサーバとの間のインタラクションデータを取得するステップと；前記インタラクションデータに基づいて、異常事象が発生したかどうかを検出するステップと；異常事象が発生した場合にユーザの属性情報を取得するステップと；ローカルに記憶された、前記異常事象に対応する属性情報、原因、及び重みの間の第１の対応関係を検索して、前記属性情報と最大重みを含むレコードを特定するステップと；前記異常事象の原因を前記レコード内の原因と特定するステップと；を含むものである。

また、当該方法は、前記特定された原因に基づいて異常事象を処理するステップと；を含むものである。また、複数の異常事象が発生した場合における、前記特定された原因に基づいて異常事象を処理するステップは、前記複数の異常事象を所定の異常事象順に並べ替えるステップと；前記並べ替えられた異常事象の順序で、前記異常事象の発生原因に基づいて前記異常事象を順次処理するステップと；を含むものである。

前記特定された原因に基づいて異常事象を処理するステップは、ローカルに記憶された、前記異常事象に対応する原因とその解決方法との間の第２の対応関係を取得するステップと；前記第２の対応関係から、前記特定された原因に対応する解決方法を取得するステップと；前記解決方法に基づいて前記異常事象を処理するステップと；を含むものである。

前記特定された原因に基づいて異常事象を処理した後に、前記異常事象を処理したサーバから得られた処理結果に基づいて前記ユーザがフィードバックしたフィードバックデータを受信するステップと；前記フィードバックデータが同意識別子を含む場合にあっては、前記属性情報と前記特定された原因とを含むレコードの前記第１の対応関係における重みを加算するステップ；あるいは、前記フィードバックデータが不同意識別子を含む場合にあっては、カスタマーサービス担当者が前記ユーザと通信した後に、前記カスタマーサービス担当者によって送信された前記異常事象の原因を受信するステップと；前記第１の対応関係が前記属性情報及び前記受信された原因を含むレコードを含む場合において、前記属性情報及び前記受信された原因を含む前記レコードの重みを加算するステップ、または、前記第１の対応関係が前記属性情報と前記受信した原因とを含むレコードを含まない場合において、初期の重みを設定し、前記属性情報、前記受信された原因、及び前記初期の重みを単一のレコードとして第１の対応関係に記憶するステップ；を含むものである。

本発明の実施形態の第２の態様に基づき、データ処理装置が提供され且つサーバに適用され、当該装置は、サーバに適用されるデータ処理装置であって、ユーザと前記サーバとの間のインタラクションデータを取得するように構成された第１の取得モジュールと、前記インタラクションデータに基づいて、異常事象が発生したかどうかを検出するように構成された検出モジュールと、異常事象が発生したときに前記ユーザの属性情報を取得する第２の取得モジュールと、ローカルに記憶された、前記異常事象に対応する属性情報、原因、及び重みの間の第１の対応関係を検索して、前記属性情報と最大重みとを含むレコードを特定する検索モジュールと、前記異常事象の原因を前記レコード内の原因と特定するように構成された特定モジュールと、を含むものである。

また、当該装置は、特定された原因に基づいて異常事象を処理するように構成された処理モジュールをさらに含むものである。また、複数の異常事象が発生した場合において、前記処理モジュールは、複数の異常事象を所定の異常事象順に並べ替えるソート部と、異常事象の処理が終了するまで、異常事象の原因に基づいて、異常事象を並べ替えられた異常事象の順に順次処理する第１の処理部と、を含むものである。

前記処理モジュールは、ローカルに記憶された、前記異常事象に対応する原因と解決方法との間の第２の対応関係を取得するように構成された第１の取得部と、前記第２の対応関係から、前記特定された原因に対応する解決方法を取得する第２の取得部と、解決方法に基づいて異常事象を処理するように構成された第２の処理部と、を含むものである。

当該装置はさらに、前記異常事象を処理した前記サーバから得られた処理結果に基づいて前記ユーザによってフィードバックされるフィードバックデータを受信する第１の受信モジュールと、前記フィードバックデータが同意識別子を含む場合にあっては、前記属性情報と前記特定された原因とを含むレコード内の前記第１の対応関係における重みを加算するように構成された第１の加算モジュール；あるいは、前記フィードバックデータが不同意識別子を含む場合にあっては、カスタマーサービス担当者が前記ユーザと通信した後に送信される前記異常事象の原因を受信する第２の受信モジュール、及び、前記第１の対応関係が前記属性情報及び前記受信された原因を含むレコードを含む場合において、前記属性情報及び前記受信された原因を含む前記レコード内の重みを加算する第２の加算モジュール、または、前記第１の対応関係が前記属性情報を含むレコードを含まない場合において、初期の重みを設定し、前記属性情報、前記受信された原因、及び前記初期の重みを単一のレコードとして第１の対応関係に記憶する記憶モジュール；を含むものである。

本発明の実施形態で提供される技術的な解決手段は、以下の有益な効果をもたらすことができる。本発明では、ユーザとサーバとの間のインタラクションデータが取得され、前記インタラクションデータに基づいて異常事象が発生したか否かを検出し、異常事象が発生した場合にはそのユーザの属性情報を取得し、ローカルに記憶された、前記異常事象に対応する前記属性情報、前記原因、及び前記重みの間の前記第１の対応関係を検索して前記属性情報と前記最大重みとを含むレコードを特定し、このレコード内の原因が異常事象の原因と特定される。このプロセスでは、ユーザはカスタマーサービス担当者と通信する必要はなく、カスタマーサービス担当者はユーザとの通信によって異常事象の原因を特定する必要はなく、異常事象の原因は、ユーザの属性情報と、異常事象に対応する属性情報、原因、及び重みの間の第１の対応関係を示す情報を用いることで特定される。したがって、人件費が節約される。

前述の一般的な説明及び以下の詳細な説明は単なる例であり、説明的なものであることを理解されたい。そしてこれらは本発明を限定するものではない。

本明細書の添付の図面は、本明細書に組み込まれ、本明細書の一部を構成し、本発明による実施形態を示し、本発明の原理を説明するために明細書と共に使用される。

図１は、実施例に基づくデータ処理方法を示すフローチャートである。

図２は、実施例に基づく決定木モデルを示す概略図である。

図３は、実施例に基づくデータ処理方法を示すフローチャートである。

図４は、実施例に基づくデータ処理方法を示すフローチャートである。

図５は、実施例に基づくデータ処理装置を示すブロック図である。

実施例はここで詳細に説明され、この実施の一例が添付の図面に示されている。以下の説明は、添付の図面と関連している場合、別段の指定がない限り、異なる添付の図面における同一符号は、同一または類似の要素を表す。以下の実施形態で説明される実施形態は、本発明に基づく実施形態の全てを示したものではない。それらは、添付の特許請求の範囲に詳細に記載される本発明のいくつかの態様に基づく装置及び方法の単なる例を代替的に示したものである。

図１は、実施例に基づくデータ処理方法を示すフローチャートである。図１に示すように、この方法はサーバに適用され、この方法は以下のステップを含む。

ステップＳ１０１において、ユーザとサーバとの間のインタラクション（interaction、対話）データが取得される。

このインタラクションデータには、ユーザがサーバに送信したデータと、サーバがユーザに返信したデータが含まれる。

例えばユーザは、Ｗｅｂページを取得する必要が生じたとき、そのＷｅｂページのリンクを含む、そのＷｅｂページを取得するための取得要求をサーバに送信することが可能である。取得要求を受信したサーバは、そのリンクに基づいてそのＷｅｂページを取得し、取得要求に基づく取得応答をユーザに返信することが可能である。この取得要求及び取得応答が、ユーザとサーバとの間のインタラクションデータである。

他の例として、商品の支払いをオンラインで行う必要が生じたとき、ユーザはサーバにユーザアカウント、商品の価格、及び売主アカウントを含む支払要求を送信する。支払要求を受信したサーバは、この支払い要求に対して、例えば、ユーザアカウントに含まれる残高から商品の価格を差し引いた後、売主アカウントの残高に商品の差し引いた価格を加算して、ユーザへ支払い応答を返信するといった処理を行う。この支払要求及び支払応答が、ユーザとサーバとの間のインタラクションデータである。

ステップＳ１０２では、インタラクションデータに基づいて異常事象が発生したか否かを検出する。

例えば、ユーザがサーバに送ったＷｅｂページを取得するための取得要求に含まれるリンクのフォーマットが正しくない場合、サーバはそのリンクに基づいてＷｅｂページを取得することができない。この場合、Ｗｅｂページが取得されていないことを通知する取得応答をユーザに返信する。この取得応答は、ユーザとサーバとの間のインタラクションデータであり、またこの取得応答は、Ｗｅｂページが正常に取得されなかったことを示すものである。したがって、異常事象が発生したと判断することができる。

他の例として、支払要求を受信した後、サーバは、ユーザアカウントに含まれる残高から商品の価格を差し引く。しかし、ユーザアカウントに含まれる残高が商品の価格よりも低い場合には、商品の価格をユーザアカウントの残高から正常に差し引くことができず、商品の価格を売主アカウントの残高に加算することができない。その結果、要求が処理されず、支払い要求が処理できなかったことを通知するための支払い応答がユーザに返信される。この支払い応答は、ユーザとサーバとの間のインタラクションデータであり、またこの支払い応答は、その商品の支払いが失敗したことを示すものである。したがって、異常事象が発生したと判断することができる。

異常事象が発生すると、ステップＳ１０３において、そのユーザの属性情報を取得する。

ユーザの属性情報とは、ユーザアカウントに格納された、ユーザの性別や年齢等、ユーザアカウントが銀行カードに拘束されているかどうか、ユーザアカウントに対して実名認証が行われているかどうか、及びユーザアカウントの支払い機能が有効にされているかどうか等である。

ステップＳ１０４では、ローカル（ローカルディスク）に記憶されている、異常事象に対応する属性情報、原因、及び重みの間の第１の対応関係を検索し、その属性情報と最大の重みとを含むレコード（record、記録）を特定する。

異常事象に対応する属性情報、原因及び重みの間の初期の対応関係は、技術者が予め設定することで取得してもよいし、自動学習（auto-leaning）によりサーバが取得してもよい。

サーバは、自動学習により、異常事象に対応する属性情報、原因、及び重みの間の対応関係を、以下の処理により取得することができる。

歴史的なプロセスとして、ユーザとサーバとの間の交信中に異常事象が発生した場合、カスタマーサービス担当者はユーザと通信する（communicate）ことができる。通信中に、カスタマーサービス担当者は、ユーザの属性情報と、ユーザによって説明された異常事象に関する情報とに基づいて異常事象の原因を特定し、特定したユーザの属性情報およびその原因をサーバに入力する。サーバは、カスタマーサービス担当者が入力した属性情報とその原因を受け取る。

ローカルに記憶された、異常事象に対応する属性情報、原因、及び重みの間の第１の対応関係が検索され、カスタマーサービス担当者によって入力された属性情報と原因とを含むレコードが特定される。レコードがカスタマーサービス担当者によって入力された属性情報と原因とを含む場合にあっては、カスタマーサービス担当者によって入力された属性情報と原因を含むレコード内の重みが加算される。カスタマーサービス担当者が入力した属性情報と原因を含むレコードがない場合には、初期設定の重みが設定され、カスタマーサービス担当者が入力した属性情報及び原因と初期設定の重みとが、第１の対応関係に単一のレコードとして記憶される。

第１の対応関係内のいくつかのレコードは、属性情報、原因、および重みを含む。歴史的なプロセスにおいて、ユーザの属性情報がレコードの属性情報であり、原因がレコードの原因である場合、重みは、異常事象が発生した回数とすることができる。これは、第１の対応関係内の他のレコードについても当てはまる。

したがって、このステップでは、第１の対応関係を検索して属性情報を含むレコードを特定することができる。レコードに属性情報が含まれている場合において、その属性情報を含むレコードの中から最大の重みを含むレコードを選択し、ステップＳ１０５を実行する。

しかしながら、属性情報が含まれているレコードがない場合には、サーバは異常事象の原因を正確に判断するために、サーバとユーザの端末装置との接続をサーバとカスタマーサービス担当者の端末装置との接続に結び付けることができ、そのため、ユーザの端末装置がカスタマーサービス担当者の端末装置に直接接続され、カスタマーサービス担当者がユーザと直接通信することができる。通信中、カスタマーサービス担当者は、ユーザによって説明された異常事象の情報に基づいてその異常事象の原因を特定し、特定された原因をサーバに入力することができる。

例えば、本発明の実施形態では、異常事象に対応する属性情報、原因、及び重みの間の第１の対応関係は、決定木モデル（a decision tree model）とすることができる。例えば、決定木モデルのルート（root、根）ノードには異常事象が格納される。このルートノードは、少なくとも１つのレベル２ノードを指向する。各レベル２ノードは属性情報を格納することができ、各レベル２ノードは少なくとも１つのレベル３ノードを指向することができる。各レベル３ノードは原因を格納することができる。各レベル２ノードと、レベル２ノードが指向するレベル３ノードとの間には、重みが設定される。

図２に示すように、ルートノードは異常事象Ｘを格納し、ルートノードは２つのレベル２ノード、すなわち第１のレベル２ノードと第２のレベル２ノードを指向し、第１のレベル２ノードには属性情報１を格納し、第２のレベル２ノードには属性情報２を格納する。

第１のレベル２ノードは、第１のレベル３ノード、第２のレベル３ノード、および第３のレベル３ノードの計３つのレベル３ノードを指向する。第１のレベル３ノードは原因Ａを格納し、第２のレベル３ノードは原因Ｂを格納し、第３のレベル３ノードは原因Ｃを格納する。

重み１は、第１のレベル２ノードと第１のレベル２ノードが指向する第１のレベル３ノードとの間に設定され、重み２は、第１のレベル２ノードと第１のレベル２ノードが指向する第２のレベル３ノードとの間に設定され、重み３は、第１のレベル２ノードと第１のレベル２ノードが指向する第３のレベル３ノードとの間に設定される。

第２のレベル２ノードは、３つのレベル３ノード、すなわち第４のレベル３ノード、第５のレベル３ノード、および第６のレベル３ノードを指向する。第４のレベル３ノードは原因Ｄを格納し、第５のレベル３ノードは原因Ｅを格納し、第６のレベル３ノードは原因Ｆを格納する。

重み４は、第２のレベル２ノードと第２のレベル２ノードが指向する第４のレベル３ノードとの間に設定され、重み５は、第２のレベル２ノードと第２のレベル２ノードが指向する第５のレベル３ノードとの間に設定され、重み６は、第２のレベル２ノードと第２のレベル２ノードが指向する第６のレベル３ノードとの間に設定される。

異常事象Ｘが発生した場合において、そのユーザの属性情報が属性情報１であると仮定する。図２の決定木モデルに示すように、ルートノードを起点として、ルートノードが指向するレベル２ノードを検索し、属性情報１を格納するレベル２ノードを特定し、属性情報１が格納されているレベル２ノードが第１のレベル２ノードであると特定する。

第１のレベル２ノードが指向する各レベル３ノードは、第１のレベル２ノードから始まる異なる原因を格納するので、第１のレベル２ノードが指向する各レベル３ノードを検索し、第１のレベル２ノードとの重みが最も大きいレベル３ノードを特定し、この特定されたレベル３ノードに格納されている原因が異常事象Ｘの原因として特定される。重み２が重み１よりも大きく、重み１が重み３よりも大きいと仮定する。第２のレベル３ノードと第１のレベル２ノードとの間の重みが最大の重みであるから、第２のレベル３ノードに記憶された原因２が異常事象Ｘの原因として特定される。

ステップＳ１０５では、レコード内の原因が異常事象の原因であると特定される。

ステップＳ１０４において複数のレコードが選択された場合、すなわち、第１の対応関係においては重みの最も大きい属性情報を含むレコードが複数ある場合には、選択された複数のレコードの中からランダムに１のレコードが選択され、選択されたレコードに関連付けられた原因が異常事象の原因として特定される。ステップＳ１０４において１のレコードのみが選択された場合には、選択されたレコードに関連する原因が異常事象の原因として特定される。

図１に示す本発明の実施形態では、ユーザとサーバとの間のインタラクションデータが得られ、このインタラクションデータに基づいて異常事象が発生したか否かを検出し、異常事象が発生した場合にはそのユーザの属性情報を取得し、ローカルに記憶された、この異常事象に対応する属性情報、原因、及び重みの間の第１の対応関係を検索して当該属性情報と最大重みとを含むレコードを特定し、当該レコード内の原因が異常事象の原因として特定される。このプロセスでは、ユーザはカスタマーサービス担当者と通信する必要はなく、カスタマーサービス担当者はユーザとの通信によって異常事象の原因を特定する必要はなく、異常事象の原因は、ユーザの属性情報と、異常事象に対応する属性情報、原因、及び重みの間の第１の対応関係を示す情報を用いることで特定できる。したがって、人件費を節約することができる。

一般に、異常事象の原因が特定された場合、異常事象を解決するための手助け（ヘルプ）をユーザに提供する必要がある。したがって、本発明の別の実施形態に係る方法では、図３に示されているように、以下のステップをさらに含む。

ステップＳ２０１では、特定された原因に基づいて異常事象が処理される。

本発明のこの実施形態では、異常事象について、技術者は、歴史的なプロセスにおいて異常事象の共通原因および各原因に対応する解決方法を収集する。例えば、ユーザがオンラインでの商品の支払いに失敗した場合において、異常事象は支払いの失敗である。次に、異常事象の原因は、ユーザアカウント内の残高が不十分であることであり、好ましい解決方法は、ユーザアカウントに補充をするために使用される補充用ページを直接送信することであると判断される。このように、補充用ページを受信した後、ユーザは、補充用ページを使用してユーザアカウントへ十分な額を直接補充することができ、その額を使用して支払いを成功させることができる。異常事象の原因について、サーバは、ローカルに記憶された、異常事象の原因と対応する解決方法との間の第２の対応関係に、原因とこの原因に対応する解決方法を単一のレコードとして記憶することができる。この異常事象の他の原因については、上述の操作を同様に行うことで処理できる。

したがって、このステップでは、異常事象の原因と対応する解決方法との間の第２の対応関係を得ることができ、特定された原因に対応する解決方法が第２の対応関係から求められ、得られた解決方法に基づいて異常事象が処理される。

さらに、前述の実施形態では、時折複数の異なる異常事象が特定されることがある。このような場合、サーバはこれらの異常事象を順次処理する必要がある。技術者は、あらかじめサーバ上で異常事象処理命令を設定することができ、この異常事象処理命令は、処理優先度に関する指示を含む異常事象の識別子を格納することができる。

その結果、本発明の実施形態では、異なる複数の異常事象が特定された場合に、その複数の異常事象をあらかじめ定められた異常事象処理順序で特定することができ、並べ替え（ソート）後に異常事象が順次処理され、これらの異常事象の処理はその処理が完了するまでその異常事象の原因に基づいて処理される。

特定された原因に基づいてサーバが異常事象を処理した後、処理の成功または処理の失敗であるところの処理結果が取得される。

例えば、異常事象が支払いの失敗であった場合において、サーバが異常事象を処理した後、ユーザが再試行中に支払いを成功させることができれば、処理結果は処理が成功した旨を示すことができる。または、サーバが異常事象を処理した後、ユーザが再試行を経ても支払いを成功できない場合、処理結果は処理が失敗した旨を示すことができる。

本発明のこの実施形態では、ユーザは、サーバの処理結果にフィードバックを提供することができる。フィードバックには、異常事象の処理結果の同意情報または処理結果の不同意情報が含まれる。

例えば、サーバが異常事象を処理した後、ユーザが再試行中に支払いを正常に行うことができれば、ユーザは異常事象を処理したサーバから得られた処理結果に同意することができる。サーバが異常事象を処理した後、ユーザが再試行を経ても支払いを成功できない場合は、ユーザは異常事象を処理したサーバから得られた処理結果に同意することができない。

本発明のさらに別の実施形態では、サーバによって第１の対応関係に基づいて特定される異常事象の原因を特定する精度を後に向上させるために、ユーザからのフィードバックに基づいて第１の対応関係を更新することができる。図４に示すように、この方法は、以下のステップをさらに含む。

ステップＳ３０１では、異常事象を処理したサーバからの処理結果に基づいてユーザがフィードバックしたフィードバックデータを受信する。

このフィードバックデータは、所定のフラグビット（flag bit、標識ビット）を含むことができる。所定のフラグビットは、同意識別子または不同意識別子を格納することができる。例えば、「１」は同意識別子を示し、「０」は不同意識別子を示すことができる。

ユーザは、異常事象を処理したサーバからの処理結果に同意すると、処理結果の同意を示す同意ボタンを端末装置で動作させる（trigger）ことができる。端末装置は、ユーザから同意ボタンを動作させる操作を受け付けると、フィードバックデータを生成し、フィードバックデータの所定のフラグビットに同意識別子「１」を加えて、サーバに同意識別子「１」が付加されたフィードバックデータを送信する。フィードバックデータを受信したサーバは、フィードバックデータに含まれた識別子が同意識別子「１」であるか不同意識別子「０」であるかを判断し、フィードバックデータに同意識別子「１」が含まれていると判断した場合には、このフィードバックデータは同意フィードバックデータであると特定される。

先の実施形態においては、サーバが異常事象を特定すると、異常事象に対応する属性情報、原因、及び重みの間の第１の対応関係を検索して当該属性情報を含むレコードを特定し、この属性情報を含む特定されたレコードの中から最大の重みを含むレコードが選択される。そして、この最大の重みを含むレコードに関連付けられた原因が、異常事象の原因として用いられる。しかし、異常事象の実際の原因が、最大の重みを含むレコードに関連付けられた原因ではない場合がある。原因が誤って特定された場合、特定された原因に基づいて解決方法が取得されるため、異常事象を解決することはできない。

例えば、異常事象が支払いの失敗であり、属性情報はユーザアカウントの実名認証を含まず、且つユーザアカウントは銀行カードに拘束されておらず、最大の重みを含むレコードに関連付けられた原因はアカウントの残高が不十分であることであり、異常事象の実際の原因はユーザアカウントの支払い機能が無効になっていることであるような場合である。不十分な残高に起因する原因の解決方法は、ユーザにユーザアカウントの補充のために使用される補充用ページを直接送信することである。他方、無効化された支払い機能に起因する原因の解決方法は、支払い機能を有効にするために適用するアプリケーションページをユーザに提供することである。したがって、実際の支払い失敗の異常事象は、ユーザにユーザアカウントの補充のために使用される補充用ページを直接送信することによっては解決することができない。

また、ユーザは、特定された原因に基づいて異常事象を処理したサーバからの処理結果には同意しない。ユーザは、特定された原因に基づいて異常事象を処理したサーバからの処理結果にユーザが同意しない場合、処理結果の不同意を示す不同意ボタンを端末装置上で動作させることができる。端末装置は、ユーザが不同意ボタンを動作させる操作を受け付けると、フィードバックデータを生成し、フィードバックデータの所定のフラグビットに不同意識別子「０」を加えて、サーバに不同意識別子「０」が付加されたフィードバックデータを送信する。フィードバックデータを受信したサーバは、同意識別子「１」であるか不同意識別子「０」であるかを判断し、不同意識別子「０」が含まれていると判断した場合には、このフィードバックデータは不同意フィードバックデータであると特定される。

ステップＳ３０２では、フィードバックデータに同意識別子または不同意識別子が含まれているかどうかが特定される。

フィードバックデータに同意識別子が含まれている場合には、ステップＳ３０３において、属性情報と特定された原因とを含むレコードの第１の対応関係における重みを加算する。

フィードバックデータに同意識別子が含まれている場合には、ユーザが特定された原因に基づいて異常事象を処理したサーバからの処理結果に同意したものと判断し、ユーザからのこのフィードバックデータに基づいて第１の対応関係を更新するため、属性情報と特定された原因とを含むレコードの第１の対応関係における重みを加算する。

フィードバックデータが不同意識別子を含む場合には、ステップＳ３０４において、カスタマーサービス担当者によって送信された異常事象の原因が受信される。この受信した原因は、カスタマーサービス担当者がユーザと交信した後に送信されたものである。

フィードバックデータに不同意識別子が含まれている場合には、ユーザが特定された原因に基づいて異常事象を処理したサーバからの処理結果に同意していないものと判断するとともに、過去の実施の際にサーバによって特定された異常事象の原因が、異常事象の実際の原因ではない可能性があると判断する。原因が誤って特定された場合、サーバが特定した原因に基づいて解決方法が得られるため、異常事象を解決することはできない。

したがって、本発明のこの実施形態では、異常事象を解決するために、サーバは、ユーザ端末装置をカスタマーサービス担当者の端末装置と直接接続すべく、サーバとユーザの端末装置との間の接続をサーバとカスタマーサービス担当者の端末装置との間の接続に結び付けることができる。そして、カスタマーサービス担当者はユーザと直接通信することができる。通信中に、カスタマーサービス担当者は、ユーザによって説明された異常事象に関する情報に基づいて異常事象の原因を特定し、特定された原因をサーバに入力することができる。サーバはカスタマーサービス担当者が入力した原因を受け取る。一般的に、カスタマーサービス担当者がユーザと通信した後に特定した異常事象の原因は、通常、異常事象の実際の原因であるため、ステップＳ３０５を実行することができる。

本発明のさらに別の実施形態では、カスタマーサービス担当者が入力した原因を受信した後、サーバは入力された原因に基づいて異常事象を処理することができる。そして、ユーザは、入力された原因に基づいて異常事象を処理したサーバからの処理結果に基づいてフィードバックを引き続き提供することができる。サーバは、この処理結果に関するフィードバックデータをユーザから受信すると、フィードバックデータに不同意識別子が含まれていれば、サーバが依然としてユーザが異常事象を解決する手助けができていないことを示し、ユーザから同意識別子を含むフィードバックデータを受信するまで上記のステップを繰り返し実行する。フィードバック情報に同意識別子が含まれている場合には、受信した原因に基づいて異常事象を処理したサーバからの処理結果にユーザが同意したものと判断し、あるいはサーバによりユーザが異常事象を解決する手助けがなされたと判断して、ステップＳ３０５が実行される。

ステップＳ３０５では、ローカルに記憶された第１の対応関係に、属性情報と受信した原因とを含むレコードが含まれているか否かを判定する。

第１の対応関係に属性情報と受信した原因とを含むレコードが含まれている場合には、ステップＳ３０６において、属性情報と受信した原因とを含むレコードの重みを加算する。

第１の対応関係に属性情報と受信した原因とを含むレコードが含まれていない場合には、ステップＳ３０７において、初期重みを設定し、属性情報と受信した原因と初期重みとを単一のレコードとして第１の対応関係に記憶する。

図５は、実施例に基づいたサーバに適用可能なデータ処理装置を示したものである。図５を参照すると、この装置は、
ユーザと前記サーバとの間のインタラクションデータを取得するように構成された第１の取得モジュールと、
前記インタラクションデータに基づいて、異常事象が発生したかどうかを検出するように構成された検出モジュールと、
異常事象が発生したときに前記ユーザの属性情報を取得する第２の取得モジュールと、
ローカルに記憶された、前記異常事象に対応する属性情報、原因、及び重みの間の第１の対応関係を検索して、前記属性情報と最大重みとを含むレコードを特定する検索モジュールと、
前記異常事象の原因を前記レコード内の原因と特定するように構成された特定モジュールと、を含むものである。

図５に示す本発明の実施形態では、ユーザとサーバとの間のインタラクションデータが取得され、前記インタラクションデータに基づいて異常事象が発生したか否かを検出し、異常事象が発生した場合にそのユーザの属性情報を取得し、ローカルに記憶された、前記異常事象に対応する前記属性情報と前記原因と前記重みとの間の前記第１の対応関係を検索して前記属性情報と前記最大重みとを含むレコードを特定し、このレコード内の原因が異常事象の原因であると特定される。このプロセスにおいては、ユーザはカスタマーサービス担当者と通信する必要はなく、カスタマーサービス担当者はユーザとの通信によって異常事象の原因を特定する必要はなく、異常事象の原因は、ユーザの属性情報と、異常事象に対応する属性情報、原因、及び重みの間の第１の対応関係を示す情報を用いることで特定できる。したがって、人件費を節約することができる。

また、本装置は、特定された原因に基づいて異常事象を処理するように構成された処理モジュールをさらに含むことができる。

複数の異常事象が発生した場合において、前記処理モジュールは、
複数の異常事象を所定の異常事象順に並べ替えるソート部と、
異常事象の処理が終了するまで、異常事象の原因に基づいて、異常事象を並べ替えられた異常事象の順に順次処理する第１の処理部と、を含むことができる。

前記処理モジュールは、
ローカルに記憶された、前記異常事象に対応する原因と解決方法との間の第２の対応関係を取得するように構成された第１の取得部と、
前記第２の対応関係から、前記特定された原因に対応する解決方法を取得する第２の取得部と、
解決方法に基づいて異常事象を処理するように構成された第２の処理部と、を含むことができる。

前記異常事象を処理した前記サーバから得られた処理結果に基づいて前記ユーザによってフィードバックされるフィードバックデータを受信する第１の受信モジュールと、
前記フィードバックデータが同意識別子を含む場合にあっては、前記属性情報と前記特定された原因とを含むレコード内の前記第１の対応関係における重みを加算するように構成された第１の加算モジュール；あるいは
前記フィードバックデータが不同意識別子を含む場合にあっては、カスタマーサービス担当者が前記ユーザと通信した後に送信される前記異常事象の原因を受信する第２の受信モジュール、及び、前記第１の対応関係が前記属性情報及び前記受信された原因を含むレコードを含む場合において、前記属性情報及び前記受信された原因を含む前記レコード内の重みを加算する第２の加算モジュール、または、前記第１の対応関係が前記属性情報を含むレコードを含まない場合において、初期の重みを設定し、前記属性情報、前記受信された原因、及び前記初期の重みを単一のレコードとして第１の対応関係に記憶する記憶モジュール；を含むことができる。

前述の実施形態の装置では、各モジュールが動作を実行する具体的な方法については、関連する方法の実施形態ですでに詳細に説明したので、ここでは記載を簡単にするために繰り返しとなる記載は省略している。

当業者であれば、本明細書を検討し、本明細書に開示された本発明を実施した後においては、本発明の別の実施形態を容易に想到することができる。本出願は、任意の変形、機能または適応のための変更を包含することを意図している。これらの変形、機能、または適応的な変更は、本発明における一般的な原理に従うものであり、本発明で開示されていない技術分野における共通の知識または技術的な手段を包含することができる。明細書および実施例は単なる一例に過ぎないものとして参酌されるものであり、本発明の実際の範囲および趣旨は、添付の特許請求の範囲によって示される。

本発明は、上記において説明され添付の図面に示される正確な構造には限定されないものであることを理解されるべきである。改変および変更は、本発明の範囲から逸脱することがない限り許容される。本発明の範囲は、添付の特許請求の範囲によってのみ規定される。

１１ 第１の取得モジュール
１２ 検出モジュール
１３ 第２の取得モジュール
１４ 検索モジュール
１５ 特定モジュール

Claims (10)

1. サーバに適用されるデータ処理方法であって、
   ユーザとサーバとの間のインタラクションデータを取得するステップと；
   前記インタラクションデータに基づいて、異常事象が発生したかどうかを検出するステップと；
   異常事象が発生した場合にユーザの属性情報を取得するステップと；
   ローカルに記憶された、前記異常事象に対応する属性情報、原因、及び重みの間の第１の対応関係を検索して、前記属性情報と最大重みを含むレコードを特定するステップと；
   前記異常事象の原因を前記レコード内の原因と特定するステップと；を含む、
   データ処理方法。
2. 前記特定された原因に基づいて異常事象を処理するステップと；を含む、
   請求項１に記載の方法。
3. 複数の異常事象が発生した場合における、前記特定された原因に基づいて異常事象を処理するステップは、
   前記複数の異常事象を所定の異常事象順に並べ替えるステップと；
   前記並べ替えられた異常事象の順序で、前記異常事象の発生原因に基づいて前記異常事象を順次処理するステップと；を含む、
   請求項２に記載の方法。
4. 前記特定された原因に基づいて異常事象を処理するステップは、
   ローカルに記憶された、前記異常事象に対応する原因とその解決方法との間の第２の対応関係を取得するステップと；
   前記第２の対応関係から、前記特定された原因に対応する解決方法を取得するステップと；
   前記解決方法に基づいて前記異常事象を処理するステップと；を含む、
   請求項２に記載の方法。
5. 前記特定された原因に基づいて異常事象を処理した後に、
   前記異常事象を処理したサーバから得られた処理結果に基づいて前記ユーザがフィードバックしたフィードバックデータを受信するステップと；
   前記フィードバックデータが同意識別子を含む場合にあっては、前記属性情報と前記特定された原因とを含むレコードの前記第１の対応関係における重みを加算するステップ；あるいは、
   前記フィードバックデータが不同意識別子を含む場合にあっては、カスタマーサービス担当者が前記ユーザと通信した後に、前記カスタマーサービス担当者によって送信された前記異常事象の原因を受信するステップと；前記第１の対応関係が前記属性情報及び前記受信された原因を含むレコードを含む場合において、前記属性情報及び前記受信された原因を含む前記レコードの重みを加算するステップ、または、前記第１の対応関係が前記属性情報と前記受信した原因とを含むレコードを含まない場合において、初期の重みを設定し、前記属性情報、前記受信された原因、及び前記初期の重みを単一のレコードとして第１の対応関係に記憶するステップ；を実行する、
   請求項２乃至請求項４のいずれか１項に記載の方法。
6. サーバに適用されるデータ処理装置であって、
   ユーザと前記サーバとの間のインタラクションデータを取得するように構成された第１の取得モジュールと、
   前記インタラクションデータに基づいて、異常事象が発生したかどうかを検出するように構成された検出モジュールと、
   異常事象が発生したときに前記ユーザの属性情報を取得する第２の取得モジュールと、
   ローカルに記憶された、前記異常事象に対応する属性情報、原因、及び重みの間の第１の対応関係を検索して、前記属性情報と最大重みとを含むレコードを特定する検索モジュールと、
   前記異常事象の原因を前記レコード内の原因と特定するように構成された特定モジュールと、を備える、
   データ処理装置。
7. 特定された原因に基づいて異常事象を処理するように構成された処理モジュールをさらに備える、
   請求項６に記載の装置。
8. 複数の異常事象が発生した場合において、前記処理モジュールは、
   複数の異常事象を所定の異常事象順に並べ替えるソート部と、
   異常事象の処理が終了するまで、異常事象の原因に基づいて、異常事象を並べ替えられた異常事象の順に順次処理する第１の処理部と、を備える、
   請求項７に記載の装置。
9. 前記処理モジュールは、
   ローカルに記憶された、前記異常事象に対応する原因と解決方法との間の第２の対応関係を取得するように構成された第１の取得部と、
   前記第２の対応関係から、前記特定された原因に対応する解決方法を取得する第２の取得部と、
   解決方法に基づいて異常事象を処理するように構成された第２の処理部と、を含む、
   請求項７に記載の装置。
10. 前記異常事象を処理した前記サーバから得られた処理結果に基づいて前記ユーザによってフィードバックされるフィードバックデータを受信する第１の受信モジュールと、
    前記フィードバックデータが同意識別子を含む場合にあっては、前記属性情報と前記特定された原因とを含むレコード内の前記第１の対応関係における重みを加算するように構成された第１の加算モジュール；あるいは
    前記フィードバックデータが不同意識別子を含む場合にあっては、カスタマーサービス担当者が前記ユーザと通信した後に送信される前記異常事象の原因を受信する第２の受信モジュール、及び、前記第１の対応関係が前記属性情報及び前記受信された原因を含むレコードを含む場合において、前記属性情報及び前記受信された原因を含む前記レコード内の重みを加算する第２の加算モジュール、または、前記第１の対応関係が前記属性情報を含むレコードを含まない場合において、初期の重みを設定し、前記属性情報、前記受信された原因、及び前記初期の重みを単一のレコードとして第１の対応関係に記憶する記憶モジュール；を含む、
    請求項７乃至請求項９のいずれか１項に記載の装置。

Images