(57)【要約】【課題】  意味情報ネットワークを用いて、受付装置に業務が集中しない顧客対応システムを提供する。【解決手段】  受付担当イベントプレース６１と、技術担当イベントプレース６２が設けられ、それぞれに受付担当端末４１、４２、技術担当端末５１、５２が接続している。受付担当者、技術担当者の意味情報としての個人データは、各々が操作する受付担当端末、技術担当端末が保有している。受付装置１のイベント送受信部１５は、顧客端末３から受信した申告に関する意味情報を含んだ帳票受信要求を受付担当イベントプレース６１に発信する。受付担当端末の個人データと帳票受信要求がマッチングすれば、当該受付担当端末は受付装置１から帳票を受信する。受付担当端末はそれを処理できれば処理し、処理できなければ帳票受信要求を技術担当イベントプレース６２に発信する。意味情報のマッチングした技術担当端末が帳票を受信し、処理を行う。【選択図】  図１
2006053826.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して顧客の操作する顧客端末から対応依頼の申告を受け付ける受付装置と、受付担当者が操作する複数の受付担当端末とが意味情報ネットワークの受付担当イベントプレースを形成しており、前記受付装置が、前記受付担当イベントプレースを介して、前記申告の対応処理を前記複数の受付担当端末に配分する顧客対応方法であって、
前記受付装置が、前記顧客端末から受け付けた前記申告を帳票の形で保存し、前記申告に関する意味情報を含む帳票受信要求イベントを前記受付担当イベントプレースに発信する第１のステップと、
前記受付担当端末が、前記受付担当イベントプレースに前記帳票受信要求イベントの存在を検出すると、前記受付担当端末内に登録されている前記受付担当者の個人データと照合し、マッチングがとれれば、前記受付装置から前記帳票を受信する第２のステップを有する顧客対応方法。
【請求項２】
前記複数の受付担当端末と、技術担当者が操作する複数の技術担当端末とが意味情報ネットワークの技術担当イベントプレースを形成しており、
前記受付担当者が前記第２のステップで前記受付担当端末の受信した前記帳票の処理を単独で行えないと判断した場合、前記受付担当端末が、前記受付担当者の入力に基づいて、前記申告に関する意味情報を含む前記帳票受信要求イベントを前記技術担当イベントプレースに発信する第３のステップと、
前記技術担当端末が、前記技術担当イベントプレースに前記帳票受信要求イベントの存在を検出すると、これを前記技術担当端末内に登録されている前記技術担当者の個人データと照合し、マッチングがとれれば、前記受付担当端末から前記帳票を受信する第４のステップをさらに有する、請求項１に記載の方法。
【請求項３】
前記申告に関する意味情報は、当該申告が苦情か問い合わせかに関する情報と、当該申告がどの製品に関するかに関する情報と、当該申告の対応の難易度から要請される担当者の担当能力に対する信頼度に関する情報を含み、
前記受付担当者または前記技術担当者の個人データは、当該担当者が苦情担当か問い合わせ担当かに関する情報と、当該担当者の担当製品に関する情報と、担当経験に基づく当該担当者の担当能力に対する信頼度に関する情報を含む、請求項１または２に記載の方法。
【請求項４】
前記受付担当者または前記技術担当者の個人データは、当該担当者が対応可能な帳票総数に関する情報を含み、
前記受付担当端末または前記技術担当端末は、現在処理中の帳票総数をカウントしており、
前記受付担当端末または前記技術担当端末は、前記現在処理中の帳票総数が前記対応可能な帳票総数に等しい場合、それぞれ前記第２のステップまたは前記第４のステップを実行しない、請求項１から３のいずれか１項に記載の方法。
【請求項５】
前記受付担当端末または前記技術担当端末は、前記帳票の処理開始日時と処理完了日時を保存しており、
前記受付担当イベントプレースまたは前記技術担当イベントプレースに接続されているエージェントが、前記処理開始日時と前記処理完了日時をモニターし、前記処理開始日時が所定の日時以前で、前記処理完了日時がブランクとなっている帳票の前記帳票受信要求イベントを、前記受付担当端末または前記技術担当端末をして、それぞれ前記受付担当イベントプレースまたは前記技術担当イベントプレースに発信させる第５のステップをさらに有する、請求項１から４のいずれか１項に記載の方法。
【請求項６】
ネットワークを介して顧客の操作する顧客端末から対応依頼の申告を受け付け、前記申告を帳票の形で保存する手段と、前記申告に関する意味情報を含む帳票受信要求イベントを、意味情報ネットワークの受付担当イベントプレースに発信する手段を有する受付装置と、
前記受付装置とともに前記受付担当イベントプレースを形成し、前記受付担当イベントプレースに前記帳票受信要求イベントの存在を検出すると、これを登録されている受付担当者の個人データと照合する手段と、マッチングがとれれば、前記受付装置から前記帳票を受信する手段を有する、前記受付担当者によって操作される複数の受付担当端末とを有する顧客対応システム。
【請求項７】
前記受付担当端末は、前記受付担当者が前記帳票の処理を単独で行えないと判断した場合、前記受付担当者の入力に基づいて、前記申告に関する意味情報を含む前記帳票受信要求イベントを、意味情報ネットワークの技術担当イベントプレースに発信する手段をさらに有し、
前記受付担当端末とともに前記技術担当イベントプレースを形成し、前記技術担当イベントプレースに前記帳票受信要求イベントの存在を検出すると、これを登録されている技術担当者の個人データと照合する手段と、マッチングがとれれば、前記受付担当端末から前記帳票を受信する手段を有する、前記技術担当者によって操作される複数の技術担当端末をさらに有する、請求項６に記載のシステム。
【請求項８】
前記申告に関する意味情報は、当該申告が苦情か問い合わせかに関する情報と、当該申告がどの製品に関するかに関する情報と、当該申告の対応の難易度から要請される担当者の担当能力に対する信頼度に関する情報を含み、
前記受付担当者または前記技術担当者の個人データは、当該担当者が苦情担当か問い合わせ担当かに関する情報と、当該担当者の担当製品に関する情報と、担当経験に基づく当該担当者の担当能力に対する信頼度に関する情報を含む、請求項６または７に記載のシステム。
【請求項９】
前記受付担当者または前記技術担当者の個人データは、当該担当者が対応可能な帳票総数に関する情報を含み、
前記受付担当端末または前記技術担当端末は、現在処理中の帳票総数をカウントする手段と、前記現在処理中の帳票総数が前記対応可能な帳票総数に等しい場合、前記帳票の受信を中止する手段をさらに有する、請求項６から８のいずれか１項に記載のシステム。
【請求項１０】
前記受付担当端末または前記技術担当端末は、前記帳票の処理開始日時と処理完了日時を保存する手段をさらに有し、
前記受付担当イベントプレースまたは前記技術担当イベントプレースに接続され、前記処理開始日時と前記処理完了日時をモニターし、前記処理開始日時が所定の日時以前で、前記処理完了日時がブランクとなっている帳票の前記帳票受信要求イベントを、前記受付担当端末または前記技術担当端末をして、それぞれ前記受付担当イベントプレースまたは前記技術担当イベントプレースに発信させるエージェントをさらに有する、請求項６から９のいずれか１項に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、顧客端末からの問い合わせや苦情に対応する顧客対応システムに関する。
【背景技術】
【０００２】
従来の顧客対応システム、例えばコールセンタでは、サーバたる受付装置とクライアントたるオペレータ（受付担当端末や技術担当端末）がサーバクライアントシステムを構成し、サーバたる受付装置が、受付担当者や技術担当者の個人データなどを一括管理している（例えば、非特許文献１を参照）。
【０００３】
一方、サーバクライアントシステムの対概念として、Ｐ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）システムがあり、Ｐ２Ｐシステムの１つとして、意味情報ネットワーク（例えば、特許文献１を参照）がある。意味情報ネットワークでは、アドレスではなく意味情報（送信データの特性や個人の属性を記述したメタデータ）にもとづいてイベントを送信し、この意味情報に合致する登録情報（意味情報）を有するネットワーク登録者のみがこのイベントを受信する。
【非特許文献１】"日立ＩＴ／製品情報／ＣＴＮＥＴ−Ｓｅｒｖｅｒコールセンタシステム"、[ｏｎｌｉｎｅ]、[２００４年８月１２日検索]、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｈｉｔａｃｈｉ−ｉｔ．ｃｏ．ｊｐ／ｃｔｉ／ｃｔｎｅｔ＞
【特許文献１】特開２００２−９４５６１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
非特許文献１で説明されているような従来の顧客対応システムでは、サーバたる受付装置に業務が集中するため、その設備が大きくなるという問題がある。
【０００５】
そこで、本発明の目的は、意味情報ネットワークを用いて、受付装置に業務が集中しない顧客対応システムを提供することにある。
【課題を解決するための手段】
【０００６】
上記目的を達成するために、本発明の顧客対応システムは、ネットワークを介して顧客の操作する顧客端末から対応依頼の申告を受け付ける受付装置と、受付担当者が操作する複数の受付担当端末とが意味情報ネットワークの受付担当イベントプレースを形成しており、受付装置が、受付担当イベントプレースを介して、申告の対応処理を複数の受付担当端末に配分する。具体的には、受付装置が、顧客端末から受け付けた申告を帳票の形で保存し、申告に関する意味情報を含む帳票受信要求イベントを受付担当イベントプレースに発信する。そして、受付担当端末が、受付担当イベントプレースに帳票受信要求イベントの存在を検出すると、受付担当端末内に登録されている受付担当者の個人データと照合し、マッチングがとれれば、受付装置から帳票を受信する。
【０００７】
以上により、受付装置は、受付担当者の個人データなどの管理をする必要がなくなり、受付装置に業務が集中するのを防止できる。
【０００８】
さらに、本発明の顧客対応システムでは、複数の受付担当端末と、技術担当者が操作する複数の技術担当端末に、意味情報ネットワークの技術担当イベントプレースを形成させてもよい。この場合、受付担当者が帳票の処理を単独で行えないと判断した場合、受付担当端末が、受付担当者の入力に基づいて、申告に関する意味情報を含む帳票受信要求イベントを技術担当イベントプレースに発信する。そして、技術担当端末が、技術担当イベントプレースに帳票受信要求イベントの存在を検出すると、これを技術担当端末内に登録されている技術担当者の個人データと照合し、マッチングがとれれば、受付担当端末から帳票を受信する。
【０００９】
以上により、受付装置は、技術担当者の個人データなどの管理をする必要がなくなり、受付装置に業務が集中するのを防止できる。
【００１０】
なお、申告に関する意味情報は、例えば、当該申告が苦情か問い合わせかに関する情報と、当該申告がどの製品に関するかに関する情報と、当該申告の対応の難易度から要請される担当者の担当能力に対する信頼度に関する情報を含む。また、受付担当者または技術担当者の個人データは、例えば、当該担当者が苦情担当か問い合わせ担当かに関する情報と、当該担当者の担当製品に関する情報と、担当経験に基づく当該担当者の担当能力に対する信頼度に関する情報を含む。
【００１１】
さらに、本発明の顧客対応システムでは、受付担当者または技術担当者の個人データに、当該担当者が対応可能な帳票総数に関する情報を含ませ、受付担当端末または技術担当端末に、現在処理中の帳票総数をカウントさせてもよい。この場合、受付担当端末または技術担当端末は、現在処理中の帳票総数が対応可能な帳票総数に等しい場合、それぞれ帳票の受信処理を行わないようにする。
【００１２】
以上により、受付装置は、受付担当端末または技術担当端末の帳票処理の混雑状況などの管理をする必要がなくなり、受付装置に業務が集中するのを防止できる。
【００１３】
さらに、本発明の顧客対応システムでは、受付担当端末または技術担当端末に、帳票の処理開始日時と処理完了日時を保存させてもよい。そして、受付担当イベントプレースまたは技術担当イベントプレースに接続されているエージェントが、処理開始日時と処理完了日時をモニターし、処理開始日時が所定の日時以前で、処理完了日時がブランクとなっている帳票の帳票受信要求イベントを、受付担当端末または技術担当端末をして、それぞれ受付担当イベントプレースまたは技術担当イベントプレースに発信させてもよい。
【００１４】
以上により、受付装置が、受付担当端末または技術担当端末の帳票処理の進み具合を管理する必要が無くなる。さらに、処理の進んでいない帳票を他の受付担当端末または技術担当端末に回す処理もエージェントが行うので、受付装置が行う必要はない。その結果、受付装置に業務が集中するのを防止できる。
【発明の効果】
【００１５】
以上説明したように、本発明によれば、受付装置に業務が集中せず、受付装置に負荷のかからない顧客対応システムを提供できる。
【発明を実施するための最良の形態】
【００１６】
次に、本発明の実施の形態について、図面を参照して詳細に説明する。
【００１７】
図１を参照すると、本発明の一実施形態の、意味情報ネットワークを用いたＰ２Ｐ型顧客対応システムの構成が示されている。
【００１８】
図１において、顧客端末３とインターネット２以外の構成要素がＰ２Ｐ型顧客対応システムを構成し、Ｐ２Ｐ型顧客対応システムと顧客端末３が、インターネット２を介してサーバクライアントシステムを構成している。
【００１９】
そして、Ｐ２Ｐ型顧客対応システムは、受付装置１と、受付担当端末４１、４２と、技術担当端末５１、５２と、エージェント７が、意味情報ネットワークの受付担当イベントプレース６１、技術担当イベントプレース６２を介して相互に接続されることにより、構成されている。なお、受付担当端末と技術担当端末の数は、図示の便宜上それぞれ２つとしているが、無論２つには限定されない。
【００２０】
そして、受付装置１は、Ｗｅｂインタフェース１１と、帳票データベース１２と、帳票番号付与部１３と、帳票送受信部１４と、イベント送受信部１５を有している。
【００２１】
Ｗｅｂインタフェース１１は、インターネット２を介して顧客端末３から申告（対応依頼）を受け付けたり、インターネット２を介して顧客端末３に各種通知を行ったりする。帳票データベース１２は、Ｗｅｂインタフェース１１が受け付けた申告を帳票として保存する。帳票番号付与部１３は、帳票データベース１２が保存する新規帳票に帳票番号を付与したり、受付担当者や技術担当者が帳票を処理する優先度を付与したりする。帳票送受信部１４は、受付担当端末４１、４２、技術担当端末５１、５２との間で帳票を送受信する。イベント送受信部１５は、受付担当端末４１、４２、技術担当端末５１、５２との間で、帳票を送受信するためのイベントを送受信する。
【００２２】
インターネット２は、受付装置１と顧客端末を接続している。顧客端末３は、顧客によって操作される端末である。
【００２３】
図２を参照すると、受付担当端末４１の内部構成が示されている。なお、受付担当端末４２も同様な内部構成を有している。また、技術担当端末５１、５２も、技術担当フィルタ登録部（受付担当フィルタ登録部４１２に対応）と、技術担当イベント送受信部（受付担当イベント送受信部４１３に対応）と、技術担当帳票送受信部（受付担当帳票送受信部４１４に対応）が技術担当イベントプレース６２のみに接続される点を除き、同様な内部構成を有している。
【００２４】
受付担当端末４１は、受付担当個人データベース４１１と、受付担当フィルタ登録部４１２と、受付担当イベント送受信部４１３と、受付担当帳票送受信部４１４と、受付担当帳票データベース４１５と、受付担当統計情報収集部４１６と、受付担当統計情報データベース４１７を有する。
【００２５】
受付担当個人データベース４１１は、受付担当者の入力にもとづいて、受付担当者の個人データを保存する。受付担当フィルタ登録部４１２は、受付装置１のイベント送受信部１５から受付担当イベントプレース６１に発信された帳票受信要求イベントに含まれる意味情報と照合し、当該帳票を受信するか否かを決定するために、受付担当個人データベース４１１に保存されている受付担当者の個人データを登録している。受付担当イベント送受信部４１３は、受付装置１、受付担当装置４２、技術担当端末５１、５２との間で、帳票を送受信するためのイベントを送受信する。受付担当帳票送受信部４１４は、受付装置１、受付担当装置４２、技術担当端末５１、５２との間で、帳票を送受信する。受付担当帳票データベース４１５は、受付担当帳票送受信部４１４が受信した帳票を保存する。受付担当統計情報収集部４１６は、受付担当帳票データベース４１５に記入された帳票の処理開始日時や処理完了日時などのデータを収集する。受付担当統計情報データベース４１７は、受付担当統計情報収集部４１６が収集した帳票の処理開始日時や処理完了日時などのデータを保存する。
【００２６】
受付担当イベントプレース６１は、受付担当端末４１、４２によって形成される意味情報ネットワークのグループである。技術担当イベントプレース６２は、技術担当端末５１、５２によって形成される意味情報ネットワークのグループである。エージェント７は、受付担当端末４１、４２の受付担当統計情報データベース（４１７）、技術担当端末５１、５２の技術担当統計情報データベースに保存されている帳票の処理開始日時や処理完了日時などのデータを監視し、一定の場合、受付担当端末４１、４２の受付担当イベント送受信部（４１３）、技術担当端末５１、５２の技術担当イベント送受信部に未処理の帳票の受信要求を受付担当イベントプレース６１、技術担当イベントプレース６２に発信させて、他の受付担当端末、技術担当端末にその未処理の帳票を送信させる。
【００２７】
次に、本実施形態のＰ２Ｐ型顧客対応システムの動作について詳細に説明する。図３を参照すると、本実施形態のＰ２Ｐ型顧客対応システムにおける顧客対応処理の流れを説明するフローチャートが示されている。
【００２８】
ステップ３０１で、受付担当端末４１は、あらかじめ、受付担当端末４１を操作する受付担当者の入力にもとづき、当該受付担当者が苦情担当か問い合わせ担当かに関する情報、当該受付担当者の担当製品に関する情報、当該受付担当者の受付経験年数などにもとづく当該受付担当者の受付担当能力に対する信頼度、当該受付担当者が受付可能な帳票総数などの受付担当個人データを受付担当個人データベース４１１に保存する。また、受付担当個人データは、後述するように、受付装置１から受付担当イベントプレース６１に向けた発信された帳票受信要求と照合するために、受付担当フィルタ登録部４１２にも登録される。
【００２９】
なお、ステップ３０１の処理は、受付担当端末４１、技術担当端末５１、５２においても行われる。
【００３０】
ステップ３０２で、受付装置１のＷｅｂインタフェース１１は、インターネット２を介して顧客端末３から、所定の事項が記入された申告を受信する。ここで、所定事項とは、当該申告が苦情か問い合わせかに関する情報、当該申告がどの製品に関するかに関する情報、当該申告の緊急度（どのぐらい急いで当該申告に対応して欲しいかに関する情報）、当該申告のカテゴリ（カテゴリによって、例えば、当該申告の対応の難易度がわかる）、当該申告の具体的な内容などを含む。
【００３１】
ステップ３０３で、受付装置１の処理部（図１には不図示）は、受信した申告について、その申告の内容をキーとして、記憶部（図１には不図示）に当該申告に対する一次解決策があるか否かを検索する。記憶部には、申告の内容に応じた一次解決策がＦＡＱ（Ｆｒｅｑｕｅｎｃｙ Ａｓｋｅｄ Ｑｕｅｓｔｉｏｎ）として保存されている。
【００３２】
一次解決策がある場合には、ステップ３０４で、Ｗｅｂインタフェース１１は、インターネット２を介して顧客端末３にその一次解決策を通知する。
【００３３】
一次解決策がない場合には、ステップ３０５で、帳票番号付与部１３が、受信した申告について帳票の発行を行う。具体的には、受信した申告は、帳票データベース１２に移され、帳票番号付与部１３により帳票番号（以下、帳票の識別に用いられる）の付与が行われることにより、帳票となる。この際、受信した申告の記入事項は、Ｐ２Ｐ型顧客対応システム内で認識できる形で、帳票に記入される。また、受信した申告の所定事項に含まれる緊急度にもとづいて、帳票の処理の優先度の付与も行われる。帳票番号および優先度が付与された帳票は、帳票データベース１２に保存される。
【００３４】
ステップ３０６で、受付装置１のイベント送受信部１５は、帳票データベース１２に新規の帳票が保存されたのを検出すると、帳票受信要求を受付担当イベントプレース６１に向けて発信する。この帳票受信要求には、受付担当端末４１の受付担当フィルタ登録部４１２に登録されている受付担当個人データと照合されるデータが含まれている。すなわち、帳票受信要求には、当該申告が苦情か問い合わせかに関する情報、当該申告がどの製品に関するかに関する情報が含まれ、さらに、当該申告のカテゴリ（カテゴリによって、例えば、当該申告の対応の難易度がわかる）にもとづいて決定された受付担当者に対する信頼度などを含む。
【００３５】
ステップ３０７で、受付担当端末４１の受付担当フィルタ登録部４１２は、受付担当イベントプレース６１に帳票受信要求が存在しているのを検出する。受付担当フィルタ登録部４１２は、受付担当端末４１が現在対応している帳票総数をカウントする機能を有している（受付担当帳票送受信部４１４が帳票を受信すると、カウントは１増加し、受付担当帳票送受信部４１４が帳票を送信すると、カウントは１減少する）。受付担当フィルタ登録部４１２は、現在対応している帳票総数が、受付担当個人データとして登録されている当該受付担当者が受付可能な帳票総数になっていれば、帳票受信要求を受信しない。現在対応している帳票総数が、当該受付担当者が受付可能な帳票総数より小さければ、帳票受信要求を受信する。そして、受付担当フィルタ登録部４１２は、帳票受信要求（当該申告が苦情か問い合わせかに関する情報と、当該申告がどの製品に関するかに関する情報と、当該申告のカテゴリ（カテゴリによって、例えば、当該申告の対応の難易度がわかる）にもとづいて決定された受付担当者に対する信頼度が意味情報として含まれている）と、登録されている受付担当個人データ（当該受付担当者が苦情担当か問い合わせ担当かに関する情報と、当該受付担当者の担当製品に関する情報と、当該受付担当者の受付経験年数などにもとづく当該受付担当者の受付担当能力に対する信頼度が意味情報として含まれている）を照合する。帳票受信要求と登録されている受付担当個人データがマッチングすると、受付担当イベント送受信部４１３は、受付担当イベントプレース６１を介して受付装置１のイベント送受信部１５に当該帳票の送信要求を送信する。イベント送受信部１５がこの送信要求を受信すると、帳票送受信部１４は、帳票データベース１２から当該帳票を抽出し、これを、受付担当イベントプレース６１を介して受付担当端末４１の受付担当帳票送受信部４１４に送信する。
【００３６】
ステップ３０８で、受付担当帳票送受信部４１４は、受信した帳票を受付担当帳票データベース４１５に保存する。この際、帳票には処理開始日時が記入される。また、受付担当統計情報収集部４１６は、新規の帳票が受付担当帳票データベース４１５に保存されたのを検出すると、当該帳票の処理開始日時を抽出し、これを受付担当統計情報データベース４１７に保存する。受付担当統計情報データベース４１７に保存されている情報は、後述するように、エージェント７が行う処理に用いられる。
【００３７】
ステップ３０９で、受付担当端末４１の処理部（図２には不図示）は、受付担当者の入力にもとづいて、帳票に付されている優先度の高い帳票から顧客対応処理を行う。受付担当者の入力にもとづいて処理が完了できる場合、処理の完了した帳票は、受付担当帳票データベース４１５に保存される。この際、帳票には処理完了日時が記入される。また、受付担当統計情報収集部４１６は、処理の完了した帳票が受付担当帳票データベース４１５に保存されたのを検出すると、当該帳票の処理完了日時を抽出し、これを受付担当統計情報データベース４１７に保存する。受付担当統計情報データベース４１７に保存されている情報は、後述するように、エージェント７が行う処理に用いられる。
【００３８】
ステップ３１０で、受付担当帳票送受信部４１４は、処理の完了した帳票が受付担当帳票データベース４１５に保存されたのを検出すると、受付担当イベントプレース６１を介して受付装置１の帳票送受信部１４に、この帳票を送信する。帳票送受信部１４は、受信した帳票を帳票データベース１２に保存する。
【００３９】
帳票に記入されている申告内容が高度に専門技術的であり、受付担当者が自身では処理できないと判断した場合は、ステップ３０９〜３１０の代わりに、次の処理が行われる。すなわち、ステップ３１１で、受付担当イベント送受信部４１３は、受付担当者の入力にもとづいて、帳票受信要求（ステップ３０６で、受付装置１のイベント送受信部１５が発信したものと同じ）を技術担当イベントプレース６２に向けて発信する。
【００４０】
なお、上述のステップ３０７〜３１１の処理は、受付装置１と受付担当端末４２の間でも同様に行われる。
【００４１】
ステップ３１１の後、技術担当端末５１、５２における処理が行われる。この処理は、基本的に、上述のステップ３０７〜３１０の処理と同じである。異なる点は、ステップ３０７〜３１０において、受付装置１が受付担当端末４１、４２に置き換わり、受付担当端末４１が技術担当端末５１、５２に置き換わる点、受付担当イベントプレース６１の代わりに技術担当イベントプレース６２が用いられる点である。技術担当端末５１、５２における処理をステップ３１２とする。
【００４２】
エージェント７は、受付担当イベントプレース６１および技術担当イベントプレース６２を介して、受付担当端末４１、４２の受付担当統計情報データベース（４１７）、技術担当端末５１、５２の技術担当統計情報データベースを監視している。ステップ３１３で、エージェント７は、受付担当統計情報データベース、技術担当統計情報データベースに記録されている処理開始日時が所定の日時以前で、処理完了日時が記入されていない帳票があることを検出すると、処理が完了していない帳票の受信要求を受付担当イベント送受信部（４１３）、技術担当イベント送受信部に、それぞれ受付担当イベントプレース６１および技術担当イベントプレース６２に向けて発信させる。そして、上記帳票受信要求とマッチングする個人データを有する他の受付担当端末および技術担当端末に帳票処理をさせる。
【００４３】
ステップ３１４で、受付装置１のＷｅｂインタフェース１１は、帳票データベース１２に処理完了帳票が保存されたのを検出すると、インターネット２を介して顧客端末３に、処理結果の通知を行う。また、顧客端末３からの申告に含まれる緊急度に応じた期間の間に、受付担当端末、技術担当端末を見つけることができない場合にも、Ｗｅｂインタフェース１１は、インターネット２を介して顧客端末３に、混雑のために処理できない旨の通知を行う。
【００４４】
なお、本発明の受付装置１、受付担当端末４１、４２、技術担当端末５１、５２、エージェント７は、専用のハードウェアにより実現する以外に、その機能を実現するためのプログラムを、コンピュータ読み取りが可能な記録媒体に記録して、この記録媒体に記録されたプログラムを、本発明の受付装置１、受付担当端末４１、４２、技術担当端末５１、５２、エージェント７となるべきコンピュータに読み込ませて実行することにより、実現するものでもよい。コンピュータ読み取りが可能な記録媒体とは、フロッピーディスク、光磁気ディスク、ＣＤ−ＲＯＭ等の記録媒体、コンピュータシステムに内蔵されるハードディスク装置等の記憶装置を指す。さらに、コンピュータ読み取りが可能な記録媒体とは、インターネットを介してプログラムを送信する場合のように、短時間の間に、動的にプログラムを保持するもの（伝送媒体もしくは伝送波）、コンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含む。
【図面の簡単な説明】
【００４５】
【図１】本発明の一実施形態の、意味情報ネットワークを用いたＰ２Ｐ型顧客対応システムの構成を示した図である。
【図２】図１の受付担当端末４１の内部構成を示した図である。
【図３】図１のＰ２Ｐ型顧客対応システムにおける顧客対応処理の流れを説明するフローチャートである。
【符号の説明】
【００４６】
１  受付装置
１１  Ｗｅｂインタフェース
１２  帳票データベース
１３  帳票番号付与部
１４  帳票送受信部
１５  イベント送受信部
２  インターネット
３  顧客端末
４１  受付担当端末
４１１  受付担当個人データベース
４１２  受付担当フィルタ登録部
４１３  受付担当イベント送受信部
４１４  受付担当帳票送受信部
４１５  受付担当帳票データベース
４１６  受付担当統計情報収集部
４１７  受付担当統計情報データベース
４２  受付担当端末
５１  技術担当端末
５２  技術担当端末
６１  受付担当イベントプレース
６２  技術担当イベントプレース
７  エージェント
３０１〜３１４  ステップ
【図１】
2006053826.tif 000003
【図２】
2006053826.tif 000004
【図３】
2006053826.tif 000005