(57)【要約】【課題】質問者は予想応答時間という新しい観点に基づいて回答者を選択でき、システムの利便性を向上させる。【解決手段】管理サーバとプレゼンスサーバとを備える通信システムであって、前記管理サーバは、前記ネットワークと接続されるインターフェースと、前記インターフェースと接続されるプロセッサと、前記プロセッサと接続されるメモリとを備え、前記管理サーバは、第１のユーザ端末からの質問の開始を検出すると、前記プレゼンスサーバから取得したプレゼンス情報を参照して、質問に応答する第２のユーザ端末が前記第１のユーザ端末から送信された質問の通知を受信可能になるまでの受信不能時間を計算し、前記計算された受信不能時間に基づいて、前記第２のユーザ端末の予想応答時間を見積もる。【選択図】図１
2009104288.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ端末間の通信を管理する管理サーバと、
前記ユーザ端末を使用するユーザのプレゼンス情報を管理するプレゼンスサーバと、を備え、
前記管理サーバ、前記プレゼンスサーバ及び前記ユーザ端末がネットワークを介して接続されている通信システムであって、
前記ユーザ端末は、質問を発信する第１のユーザ端末と、前記第１のユーザ端末から発信された質問に応答する第２のユーザ端末とを含み、
前記管理サーバは、前記ネットワークと接続されるインターフェースと、前記インターフェースと接続されるプロセッサと、前記プロセッサと接続されるメモリとを備え、
前記管理サーバは、
前記第１のユーザ端末からの質問の開始を検出すると、前記プレゼンスサーバから取得したプレゼンス情報を参照して、前記第２のユーザ端末が前記第１のユーザ端末から送信された質問の通知を受信可能になるまでの受信不能時間を計算し、
前記計算された受信不能時間に基づいて、前記第２のユーザ端末の予想応答時間を見積もり、
前記見積もられた予想応答時間を前記第１のユーザ端末へ通知することを特徴とする計算機システム。
【請求項２】
前記管理サーバは、
前記第２のユーザ端末による過去の質問への応答を開始するまでの応答開始時間を参照して、前記第２のユーザ端末が前記質問の通知を受信してから、前記質問への応答を開始するまでの応答開始時間を計算し、
前記計算された受信不能時間と前記計算された応答開始時間とを加えることによって前記予想応答時間を見積もることを特徴とする請求項１に記載の計算機システム。
【請求項３】
前記管理サーバは、前記取得したプレゼンス情報を参照して、前記第２のユーザ端末が相談通知を受信不能になってから受信可能になるまでの時間の過去の平均値を受信不能時間と計算することを特徴とする請求項１に記載の計算機システム。
【請求項４】
前記管理サーバは、
前記第２のユーザ端末が過去の質問に応答した確率に基づいて、前記第２のユーザ端末が通知された質問に応答する確率を計算し、
前記計算された応答確率を前記第１のユーザ端末へ通知することを特徴とする請求項１に記載の計算機システム。
【請求項５】
前記管理サーバは、
前記第２のユーザ端末が過去の質問への応答に使用した作業時間に基づいて、前記第２のユーザ端末が通知された質問への応答に使用される作業時間を計算し、
前記見積もられた予想応答時間に前記計算された作業時間を加え、
前記作業時間が加えられた予想応答時間を前記第１のユーザ端末へ通知することを特徴とする請求項１に記載の計算機システム。
【請求項６】
前記管理サーバは、
前記第１のユーザ端末によって設定された質問の回答期限と、前記加算された予想応答時間とを比較した結果に基づいて、
前記設定された回答期限までに前記質問に対する応答が不可能な前記第２のユーザ端末の順位を下げるように、前記第２のユーザ端末を選択し、
前記選択された第２のユーザ端末の一覧を前記第１のユーザ端末へ通知することを特徴とする請求項５に記載の計算機システム。
【請求項７】
前記管理サーバは、
前記第２のユーザ端末が引き受け中の質問の数、所定期間に引き受けた質問の数、及び、所定期間に通知された相談通知の数の少なくとも一つに基づいて、前記第２のユーザ端末の負荷を計算し、
前記計算された負荷が高い第２のユーザ端末の順位を下げるように、前記第２のユーザ端末を選択することを特徴とする請求項６に記載の計算機システム。
【請求項８】
前記管理サーバは、
前記質問の種類に応じた前記第２のユーザ端末の応答能力の情報を取得し、
前記取得した応答能力の情報に基づいて、前記第１のユーザ端末から送信された質問への前記第２のユーザ端末の応答能力を計算し、
前記計算された応答能力が高い第２のユーザ端末の順位を下げるように、前記第２のユーザ端末を選択することを特徴とする請求項６に記載の計算機システム。
【請求項９】
前記管理サーバは、
前記質問の種類に応じた前記第２のユーザ端末の応答能力の情報を取得し、
前記取得した応答能力の情報に基づいて、前記第１のユーザ端末から送信された質問への前記第２のユーザ端末の適性を計算し、
前記計算された適性が類似する前記第２のユーザ端末が複数選択可能な場合には、前記計算された適性が類似する第２のユーザ端末の一部の順位を下げるように、前記第２のユーザ端末を選択することを特徴とする請求項６に記載の計算機システム。
【請求項１０】
前記管理サーバは、
前記質問の種類に応じた前記第２のユーザ端末の応答能力の情報を取得し、
前記取得した応答能力の情報に基づいて、前記第１のユーザ端末から送信された質問への前記第２のユーザ端末の適性を計算し、
前記計算された適性が類似する前記第２のユーザ端末が複数選択可能な場合には、前記計算された適性が類似する第２のユーザ端末の順位を上げるように、前記第２のユーザ端末を選択することを特徴とする請求項６に記載の計算機システム。
【請求項１１】
前記管理サーバは、前記選択される第２のユーザ端末の数が所定数を超える場合に、前記所定数以下の第２のユーザ端末を選択することを特徴とする請求項６に記載の計算機システム。
【請求項１２】
前記管理サーバは、
前記第２のユーザ端末が引き受け中の質問の数、所定期間に引き受けた質問の数、及び、所定期間に通知された相談通知の数の少なくとも一つに基づいて、前記第２のユーザ端末の負荷を計算し、
前記計算された負荷を前記第１のユーザ端末へ通知することを特徴とする請求項１に記載の計算機システム。
【請求項１３】
前記管理サーバは、
前記計算された負荷を時間に換算し、
前記見積もられた予想応答時間に前記計算された負荷を加え、
前記負荷が加えられた予想応答時間を前記第１のユーザ端末へ通知することを特徴とする請求項１２に記載の計算機システム。
【請求項１４】
前記管理サーバは、前記第１のユーザ端末によって設定された質問の回答期限に基づいて、前記第１のユーザ端末から送信される質問の緊急性を計算することを特徴とする請求項１に記載の計算機システム。
【請求項１５】
前記管理サーバは、前記計算された負荷に基づいて、前記第１のユーザ端末から送信される質問の通知を遅延させて前記第２のユーザ端末へ転送することを特徴とする請求項１２に記載の計算機システム。
【請求項１６】
ユーザ端末間の通信を管理する管理サーバと、
前記ユーザ端末を使用するユーザのプレゼンス情報を管理するプレゼンスサーバと、を備え、
前記管理サーバ、前記プレゼンスサーバ及び前記ユーザ端末がネットワークを介して接続されている通信システムであって、
前記ユーザ端末は、質問を発信する第１のユーザ端末と、前記第１のユーザ端末から発信された質問に応答する第２のユーザ端末とを含み、
前記管理サーバは、前記ネットワークと接続されるインターフェースと、前記インターフェースと接続されるプロセッサと、前記プロセッサと接続されるメモリとを備え、
前記管理サーバは、
前記第２のユーザ端末による過去の質問への応答を開始するまでの応答開始時間を取得し、
前記第１のユーザ端末からの質問の開始を検出すると、前記取得した過去の応答開始時間を参照して、前記第２のユーザ端末が前記質問の通知を受信してから、前記質問への応答を開始するまでの応答開始時間を計算し、
前記計算された応答開始時間に基づいて、前記第２のユーザ端末の予想応答時間を見積もり、
前記見積もられた予想応答時間を前記第１のユーザ端末へ通知することを特徴とする計算機システム。
【請求項１７】
前記管理サーバは、
前記プレゼンスサーバから取得したプレゼンス情報を参照して、前記第２のユーザ端末が前記第１のユーザ端末から送信された質問の通知を受信可能になるまでの受信不能時間を計算し、
前記計算された受信不能時間と前記計算された応答開始時間とを加えることによって前記予想応答時間を見積もることを特徴とする請求項１６に記載の計算機システム。
【請求項１８】
ユーザ端末間の通信を管理するサーバであって、
前記ユーザ端末は、質問を発信する第１のユーザ端末と、前記第１のユーザ端末から発信された質問に応答する第２のユーザ端末とを含み、
前記通信管理サーバは、
前記ネットワークと接続されるインターフェースと、前記インターフェースと接続されるプロセッサと、前記プロセッサと接続されるメモリとを備え、
前記ユーザ端末及び前記ユーザ端末を使用するユーザのプレゼンス情報を管理するプレゼンスサーバとネットワークを介して接続されており、
前記第１のユーザ端末からの質問の開始を検出すると、前記プレゼンスサーバから取得したプレゼンス情報を参照して、前記第２のユーザ端末が前記第１のユーザ端末から送信された質問の通知を受信可能になるまでの受信不能時間を計算し、
前記計算された受信不能時間に基づいて、前記第２のユーザ端末の予想応答時間を見積もり、
前記見積もられた予想応答時間を前記第１のユーザ端末へ通知することを特徴とする通信管理サーバ。
【請求項１９】
前記第２のユーザ端末による過去の質問への応答を開始するまでの応答開始時間を参照して、前記第２のユーザ端末が前記質問の通知を受信してから、前記質問への応答を開始するまでの応答開始時間を計算し、
前記計算された受信不能時間と前記計算された応答開始時間とを加えることによって前記予想応答時間を見積もることを特徴とする請求項１８に記載の通信管理サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、１対１又は１対多の通信手段を用いた相談仲介システムに関し、特に、適切な相談相手を推薦する技術に関する。
【背景技術】
【０００２】
疑問や悩みといった課題を抱えた人（質問者）が、自分よりもその課題に詳しい相談相手を探すための従来技術は、Ｑ＆Ａサイト（Ｑ＆Ａコミュニティ）や、ＫｎｏｗＷｈｏシステムがある。
【０００３】
Ｑ＆Ａサイトとは、質問者が書き込んだ質問に対して、有識者（以下、回答者）が回答を書き込むウェブサイトである（例えば、特許文献１参照。）。一般に、Ｑ＆Ａサイトは、一つの質問に対して複数の回答が連なるスレッド型掲示板の形式である。質問者は、質問を書き込み、質問が適切な回答者の目に止まって回答が書き込まれるのを待つ。一部のＱ＆Ａサイトでは、各回答者に対して、その人の得意ジャンルに該当する質問をメールやインスタントメッセージ（ＩＭ）等でプッシュ配信するサービスを提供している。プッシュ配信された質問に回答者がすぐ回答すれば、質問者は迅速に課題を解決することができる。
【０００４】
一方、ＫｎｏｗＷｈｏシステムとは、「（誰が）何を知っているか」を対象として回答者を検索するためのシステムである（例えば、特許文献２参照）。ＫｎｏｗＷｈｏシステムは、質問者が入力する質問文や技術キーワードに基づいて、１人以上の回答者を推薦する。ＫｎｏｗＷｈｏシステムは、事前に登録されたプロフィール情報などに基づいて、回答者を推薦する。質問者は、この推薦結果を見て、電話、メール又はＩＭを用いて、回答者に１対１で相談することができる。質問者からの連絡に回答者がすぐ対応すれば、質問者は迅速に課題を解決することができる。
【特許文献１】特開２００１−２７３４３２号公報
【特許文献２】特開２００２−３１２３７５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
Ｑ＆ＡサイトやＫｎｏｗＷｈｏシステムのような相談仲介システムは、質問者の抱える課題を、質問者よりも短い時間で解決できる回答者を紹介することを目的とする。
【０００６】
しかし、既存の相談仲介システムでは、優秀な回答者ほど多くの質問が集まり、負荷が高くなりやすい（すなわち、酷使されやすい）という課題がある。既存の相談仲介システムは、相談依頼を優秀な回答者に優先的に通知するため、得意分野の多い人や、専門分野の知識が深い人に、多くの相談依頼が集中しやすい。その結果、相談仲介システムが必要とする優秀な回答者ほど、システムを利用しなくなる可能性がある。
【０００７】
従って、相談仲介システムの目的を満たしつつ、優秀な回答者への負荷を軽減することのできる、回答者の推薦方法が必要である。
【課題を解決するための手段】
【０００８】
本発明の代表的な一例を示せば以下の通りである。すなわち、ユーザ端末間の通信を管理する管理サーバと、前記ユーザ端末を使用するユーザのプレゼンス情報を管理するプレゼンスサーバと、を備え、前記管理サーバ、前記プレゼンスサーバ及び前記ユーザ端末がネットワークを介して接続されている通信システムであって、前記ユーザ端末は、質問を発信する第１のユーザ端末と、前記第１のユーザ端末から発信された質問に応答する第２のユーザ端末とを含み、前記管理サーバは、前記ネットワークと接続されるインターフェースと、前記インターフェースと接続されるプロセッサと、前記プロセッサと接続されるメモリとを備え、前記管理サーバは、前記第１のユーザ端末からの質問の開始を検出すると、前記プレゼンスサーバから取得したプレゼンス情報を参照して、前記第２のユーザ端末が前記第１のユーザ端末から送信された質問の通知を受信可能になるまでの受信不能時間を計算し、前記計算された受信不能時間に基づいて、前記第２のユーザ端末の予想応答時間を見積もり、前記見積もられた予想応答時間を前記第１のユーザ端末へ通知することを特徴とする計算機システムである。
【発明の効果】
【０００９】
本発明の一実施形態によると、相談仲介システムが質問者に対して各回答者の予想応答時間を提示することによって、質問者は予想応答時間という新しい観点に基づいて回答者を選択でき、利便性が向上する。
【発明を実施するための最良の形態】
【００１０】
まず、本発明の実施形態の概要について説明する。
【００１１】
本実施形態の発明の相談仲介システムは、回答者のプレゼンス情報、過去のプレゼンス情報の傾向、及び／又は、過去の会話の履歴に基づいて、各回答者が質問の依頼に応答するまでの時間（応答時間）を予想する。
【００１２】
また、回答者が現在引き受けている相談に関するデータ、過去に引き受けた相談に関するデータ、及び／又は、過去に通知された相談依頼に関するデータに基づいて、各回答者の負荷を数値化する。特に、この負荷を加算して予想応答時間を計算することによって、システムの利便性を向上させる。
【００１３】
本実施形態の発明の相談仲介システムは、前記予想応答時間を質問者に提示する。また、相談仲介システムは回答者の負荷を数値化して計算し、相談仲介システムは前記計算された予想応答時間及び数値化された負荷に基づいて、相談仲介システムの効率が最大になるように、質問者に対して推薦する回答者を変更する。さらに、相談仲介システムは、質問者から与えられた課題の難易度及び／又は課題解決の期限を考慮することによって、質問者に対して推薦する回答者を変更する。
【００１４】
本発明の一実施形態によると、相談仲介システムが質問者に対して各回答者の予想応答時間を提示することによって、質問者は予想応答時間という新しい観点に基づいて回答者を選択でき、利便性が向上する。これにより、質問者の能力が高いという観点だけでなく、質問者の応答時間が短いという観点によっても回答者が選ばれるようになる。そのため、能力の高い質問者への負荷が軽減される。また、質問者は、実際に相談をする前に問題解決までの時間を推測できるため、システムの利便性が向上する。
【００１５】
また、相談仲介システムは、数値化された負荷に基づいて、質問者に推薦する回答者のリストにおける表示順序を変更する。又は、負荷の高い回答者を回答者リストから除外する。これにより、負荷の高い回答者への相談依頼が減ることによって、能力の高い質問者への負荷が軽減される。また、相談仲介システムは、数値化された負荷を加算した予想応答時間を示すことによって、能力の高い質問者への相談依頼を減らすことができる。
【００１６】
また、質問者が課題の難易度及び／又は課題解決の期限を与えた場合、相談仲介システムはさらに効率的に回答者を推薦できる。例えば、簡単な相談や、課題を解決すべき期限が遠い相談については、能力の高い回答者に頼る必要性が低い。従って、相談仲介システムは、簡単かつ期限の遠い相談については、できるだけ普通の回答者を推薦し、難しい相談については、能力の高い回答者を推薦し、期限の近い相談については、予想応答時間が短くかつ能力の高い回答者を推薦する。これによって、相談仲介システムは能力の高い質問者への負荷を軽減できる。
【００１７】
このため、本実施形態の相談仲介システムは、システムの利便性を損ねることなく、システム全体での回答効率を最大化することができる。
【００１８】
以下、本発明の実施形態を図面を参照して説明する。
【００１９】
＜実施形態１＞
図１は、本発明の第１及び第２の実施形態の相談仲介システムの構成を示す構成図である。
【００２０】
本発明の実施形態の相談仲介システムは、相談仲介サーバ２、会話サーバ３、相談通知サーバ４、ｎ台のユーザ端末５−１〜５−ｎ及びプレゼンスサーバ６を備える。
【００２１】
相談仲介サーバ２は、質問者からの相談開始の受け付け、各相談に対する回答者の推薦、回答者への相談の通知、相談終了の受け付け及び回答者の評価の受け付け等を行うサーバ機器である。相談仲介サーバ２は、会話サーバ３から受信した会話ログに基づいて各回答者の負荷を計算する機能、プレゼンスサーバ６から受信したプレゼンス情報に基づいて各回答者の予想応答時間を計算する機能を備える。
【００２２】
会話サーバ３は、ユーザ同士で会話するための通信手段を、ユーザ端末５に対して提供するサーバ機器である。会話サーバ３は、既存の会話手段（メール、ＩＭ、電話、電子掲示板、Ｑ＆Ａサイト、多人数チャット、ビデオ会議等）を提供する機能、及び、ユーザ同士の会話ログを相談仲介サーバ２に送信する機能を備える。一つの相談仲介システムが、複数の種類の会話手段を提供する会話サーバ３を備えてもよい。また、会話サーバ３は、会話ログを正確に記録するために、会話データ（テキスト、音声）を中継する機能を備えるとよい。
【００２３】
会話ログは、質問者と回答者の間の会話開始日時、質問者又は回答者の発言日時及び発言内容、及び、質問者と回答者の間の会話終了日時を含むデータである。会話サーバ３によって提供される通信手段には、会話開始日時及び／又は会話終了日時を明示的に取得できないものもある。そのような場合には、相談仲介サーバ２が発言日時及び発言内容に基づいて、会話開始日時及び／又は会話終了日時を推測すればよい。
【００２４】
相談通知サーバ４は、ユーザ端末５に相談通知を配布するための通信手段を、相談仲介サーバ２に対して提供するサーバ機器である。相談通知サーバ４は、既存のデータのプッシュ配信手段（メール、ＩＭ、電話、多人数チャット、ビデオ会議等）を提供する。
【００２５】
相談通信サーバ４は、会話サーバ３とは異なり、本特許に特有の機能を備える必要はない。一つの相談仲介システムが、複数の種類の通信手段を提供する相談通知サーバ４を備えてもよい。また、１台のサーバ（例えば、拡張されたＩＭサーバ）が、会話サーバ３と相談通知サーバ４の双方の機能を兼ね備えてもよい。
【００２６】
ユーザ端末５は、本相談仲介システムの利用者が使用する、パーソナルコンピュータ（ＰＣ）や携帯端末（例えば、携帯電話機等）の機器である。本相談仲介システムの利用者は、１人１台以上のユーザ端末を利用する。本相談仲介システムでは、質問者も回答者も同じ機能を備えるユーザ端末を用いることができる。すなわち、１人のユーザは、同じユーザ端末を利用して、新しい相談を開始することも、誰かの相談に回答することもできる。
【００２７】
ユーザ端末５の上では、複数のプログラム（相談仲介サーバ２に接続する相談クライアント、会話サーバ３に接続する会話クライアント、相談通知サーバ４から相談通知を受信する相談通知クライアント、プレゼンスサーバ６に接続するプレゼンスクライアント）が動作する。システムの構成によっては、会話クライアントが相談通知クライアントの機能を兼ね備えてもよい。例えば、拡張されたＩＭサーバが会話サーバ３と相談通知サーバ４を兼ねる場合は、ＩＭクライアントは会話クライアント及び相談通知クライアントとして機能する。
【００２８】
プレゼンスサーバ６は、各ユーザのプレゼンス情報を管理するサーバ機器である。プレゼンスサーバ６は、各ユーザ端末５の上で動作するプレゼンスクライアントからプレゼンス情報を収集する。また、プレゼンスサーバ６は、プレゼンス情報を相談仲介サーバ２に送信する機能を備える必要がある。プレゼンスサーバは一般的に、プレゼンス情報を他の通信機器に提供する機能を備えるため、これは本実施形態に特有の機能を備える必要はない。
【００２９】
プレゼンス情報とは、各ユーザの現在の状態を表すデータの総称である。プレゼンス情報は、各ユーザの状態、各ユーザの現在使える通信手段、及びその他のデータを含む。ユーザの状態とは、「オンライン」、「オフライン」、「会話可能」、「退席中」、「取り込み中」等を表すデータである。ユーザの使える通信手段とは、「メール」、「ＩＭ」、「多人数チャット」、「電話」等の通信手段の種類と、そのユーザと通信するための識別子（例えば、通信手段がメールであればメールアドレス）を表すデータである。その他のデータにはユーザの位置情報等がある。
【００３０】
図２は、本発明の第１及び第２の実施形態の相談仲介システムにおける相談の流れを示す説明図である。
【００３１】
まず、質問者は相談仲介システム上で相談を開始する（Ｓ１１）。次に、その相談を解決するための回答者を検索し（Ｓ１２）、その検索結果に含まれる１人以上の回答者に相談内容を通知するメッセージ（以下、相談通知）を送る（Ｓ１３）。
【００３２】
回答者は、メール等の何らかの通信手段を通してこの相談通知を見る（Ｓ１４）。相談内容を見て回答できそうだと判断できた場合、回答者は質問者との会話を開始する（Ｓ１５）。
【００３３】
その後、回答者と質問者の間で何度かの発言が繰り返される（Ｓ１６、Ｓ１７）。そして、その回答者が課題が解決するか、又は、この回答者は課題の解決が困難であると分かった時点で、質問者か回答者のいずれかが会話を終了する（Ｓ１８）。
【００３４】
課題が解決しなければ、Ｓ１２〜Ｓ１８の手順を繰り返して他の回答者に相談する。そして、いずれかの回答者が課題を解決するか、質問者が課題の解決を諦めた時点で、質問者が相談を終了する（Ｓ１９）。
【００３５】
質問者は、相談の終了後に、回答者を評価する（Ｓ２０）。
【００３６】
本実施形態では、回答者への相談通知（Ｓ１３）から、回答者との会話開始（Ｓ１５）までにかかった時間を、その回答者の応答時間と呼ぶ。また、回答者との会話開始（Ｓ１５）から会話終了（Ｓ１８）までにかかった時間を、その回答者の作業時間と呼ぶ。会話に使われる通信手段によっては、この応答時間と作業時間との計算方法を変更してもよい。例えば、会話に使われる通信手段がメールの場合は、会話開始のための手順なしに、回答者の最初の発言（最初のメール送信）が行われる。その場合は、回答者の最初の発言時刻（Ｓ１６−１）を、会話開始の時刻（Ｓ１５）として扱うとよい。
【００３７】
以下、第１の実施形態では１対１の通信手段を用いた相談仲介システムの例を説明する。
【００３８】
図３は、本発明の第１の実施形態の通信ネットワークの構成を示す構成図である。
【００３９】
相談仲介サーバ２、インスタントメッセージングサーバ７（ＩＭサーバ７）、メールサーバ８、プレゼンスサーバ６、ｎ台のユーザ端末５−１〜５−ｎは、互いに、物理的な通信回線１０及び通信網１を介して接続されている。
【００４０】
本実施形態では、ユーザ間の会話にインスタントメッセージング（ＩＭ）を用い、相談通知にはＩＭ及び電子メールを用いる。従って、本実施形態では、ＩＭサーバ７は、会話サーバ３及び相談通知サーバ４として動作する。また、メールサーバ８は、２台目の相談通知サーバ４として動作する。また、各ユーザ端末５では、ＩＭクライアントが会話クライアント及び相談通知クライアントとして動作し、メールクライアントが予備の相談通知クライアントとして動作する。また、２台以上のユーザ端末を持つユーザの中には、メールクライアントのみが動作するユーザ端末（例えば、携帯電話機）を持つユーザがいてもよい。
【００４１】
図４は、本発明の第１の実施形態の相談仲介サーバ２の構成を示す機能ブロック図である。
【００４２】
相談仲介サーバ２は、ＩＦ２１、ＣＰＵ２２及びメモリ２３を備え、ＩＦ２１、ＣＰＵ２２及びメモリ２３は、データパス２４によって接続されている。
【００４３】
相談仲介サーバ２は、ＩＦ２１を通してパケットを送受信する。相談仲介サーバ２で実行される各プログラムはメモリ２３に格納されている。相談仲介サーバ２の動作時には、ＣＰＵ２２がデータパス２４を通して、メモリ２３に格納されたプログラムを読み出して実行する。図中の矢印は、プログラム間のデータの流れを示す。また、図中の点線矢印は、データベース操作を示す。
【００４４】
メモリ２３は、データベース２３０、サービス提供部２３１、相談管理部２３２、相談通知部２３３、会話ログ受信部２３４、プレゼンス情報受信部２３５、及び遅延通知部２３６を格納する。
【００４５】
データベース２３０は、相談仲介サーバ２の動作に必要なデータを保持している。データベース２３０に保持されるデータには、ユーザデータ１０００、ユーザ能力データ１１００、相談データ１２００、会話データ１３００、会話参加者データ１４００、相談ログ１５００、会話ログ１６００、プレゼンス情報１７００、プレゼンス情報ログ１８００、評価データ１９００、及び遅延通知データ２０００がある。本実施形態では、これらのデータは全てテーブル形式で保持されている。
【００４６】
図１８は、ユーザデータの例を示す。
【００４７】
ユーザデータ１０００は、ユーザの管理に必要な、ユーザの基本データである。本システムのユーザは、必ず一つのユーザデータを持つ。このユーザデータは、管理者又はユーザ自身によって事前に登録される。
【００４８】
列１００１には、本システム上でユーザを一意に識別するためのユーザＩＤが保持される。本実施形態では、ユーザＩＤはｅメールアドレスと同じ形式に従う文字列とする。列１００２には、相談クライアントが相談仲介サーバ２に接続するために必要なパスワードが保持される。列１００３には、そのユーザの名前が保持される。この名前は、相談クライアントや会話クライアント（ＩＭクライアント、メールクライアント、チャットクライアント等）で使用される。
【００４９】
図１９は、ユーザ能力データの例を示す。
【００５０】
ユーザ能力データ１１００には、各ユーザの得意分野や専門性を表すデータが保持される。本システムのユーザは、０又は一つ以上のユーザ能力データを持つ。このデータは、管理者又はユーザによって事前に登録される。また、相談仲介サーバ２が、相談の履歴に基づいて、ユーザ能力データ１１００を作成してもよい。また、その両者の組合せによって、ユーザ能力データ１１００を作成してもよい。
【００５１】
列１１０１には、本システム上でユーザを一意に識別するためのユーザＩＤが保持される。列１１０２には、属性の名前である。列１１０３は、能力の高さを表す数値（能力値）が保持される。
【００５２】
本実施形態では、属性に対する能力の高さを数値で表す。その属性の質問に答える能力が高いほど能力値を大きく設定する。
【００５３】
また、ユーザ能力データ１１００にない属性の評価は０（どちらでもない）とする。例えば、行１１１１は、ユーザＩＤ「ａｎｄｏ＠ｅｘａｍｐｌｅ．ｃｏｍ」のユーザ（安藤）は、属性「テレビ」を持っており、その属性に対する能力値は「０．５」であることを示している。しかし、安藤は属性が「ＨＤＤレコーダ」のユーザ能力データを持っていないため、安藤の「ＨＤＤレコーダ」属性に対する能力値は０である。
【００５４】
図２０は、相談データの例を示す。
【００５５】
相談データ１２００は、これまでに相談仲介サーバ２が扱った相談の基本データである。相談仲介サーバ２は、相談の開始時に、１回の相談について一つの相談データを作成する。
【００５６】
列１２０１には、本システム上で相談を一意に識別するための相談ＩＤが保持される。本実施形態では、相談仲介サーバ２は、相談ＩＤとして、各相談に一意な整数を割り当てる。列１２０２には、その相談を開始した質問者のユーザＩＤが保持される。列１２０３には、相談のタイトルが保持される。列１２０４には、相談の内容が保持される。列１２０５には、その相談の特徴を表すキーワードが保持される。列１２０６には、相談の難易度が保持される。列１２０７には、相談を解決すべき期限が保持される。列１２０８には、回答者の推薦に重視する点が保持される。列１２０９には、相談の状態が保持される。相談の状態は「相談中」、「評価待ち」又は「終了」のいずれかである。
【００５７】
図２１は、会話データの例を示す。
【００５８】
会話データ１３００は、相談仲介サーバ２がこれまでに設定した会話の基本データである。相談仲介サーバ２は、会話の設定時に、１回の会話について一つの会話データを作成する。
【００５９】
列１３０１には、本システム上で会話を一意に識別するための会話ＩＤが保持される。本実施形態では、相談仲介サーバ２は、会話ＩＤとして、各会話に一意な整数を割り当てられる。列１３０２には、この会話に関連する相談の相談ＩＤが保持される。本実施形態では、一つの相談について複数の会話（例えば、複数の回答者とのＩＭ通信）が行われるため、一つの相談ＩＤについて０又は一つ以上の会話データが作成される。列１３０３には、会話の状態が保持される。会話の状態は「会話中」又は「終了」のいずれかである。
【００６０】
図２２は、会話参加者データの例を示す。
【００６１】
会話参加者データ１４００は、相談仲介サーバ２が設定した会話への、各ユーザの参加状況を表すデータである。相談仲介サーバ２は、会話とその会話を通知されたユーザの組合せの数だけ会話参加者データを作成する。
【００６２】
列１４０１には、会話ＩＤが保持される。列１４０２には、その会話を通知されたユーザ（質問者又は回答者）のユーザＩＤが保持される。列１４０３には、そのユーザのその会話への参加状況が保持される。会話への参加状況は、「通知」、「参加」又は「離脱」のいずれかである。ユーザが、会話を通知されたものの、その会話にまだ一度も参加していない場合は、参加状況は「通知」が設定される。ユーザが会話に参加中のときは、参加状況は「参加」が設定される。そして、ユーザが会話を終了した後は、参加状況は「離脱」が設定される。
【００６３】
図２３は、相談ログの例を示す。
【００６４】
相談ログ１５００は、相談仲介サーバ２が扱った相談の進行状況を表すデータである。相談仲介サーバ２は一つの相談につき複数の相談ログを作成する。相談ログは、後ほど応答時間や作業時間を計算するために用いられる。
【００６５】
列１５０１には相談ＩＤが保持され、列１５０２には、会話ＩＤが保持される。列１５０３には、ログの種類が保持される。列１５０４には、ログに関連するユーザのユーザＩＤが保持される。列１５０５には、ログを作成した日時が保持される。例えば、行１５１４は、２００７年８月３０日の１０時５分に、相談ＩＤが５０の相談に関する会話（会話ＩＤが５０）を、馬場（ｂａｂａ＠ｅｘａｍｐｌｅ．ｃｏｍ）に通知したことを示している。
【００６６】
列１５０２の会話ＩＤは、会話に関するログ（「相談通知」、「会話開始」又は「会話終了」）の場合のみ、その会話の会話ＩＤが設定される。列１５０３の種類は、相談開始の日時を示す「相談開始」、回答者検索を行った日時を示す「回答者検索」、相談通知を送信した日時を示す「相談通知」、会話を開始した日時を示す「会話開始」、会話を終了した日時を示す「会話終了」、相談終了の日時を示す「相談終了」、そして回答者を評価した日時を示す「回答者評価」のいずれかである。
【００６７】
列１５０３の種類が「相談通知」の場合は、列１５０４に通知先ユーザのユーザＩＤを格納する。種類が「会話開始」又は「会話終了」の場合は、列１５０４に会話を開始又は終了したユーザのユーザＩＤを含める。
【００６８】
図２４は、会話ログの例を示す。
【００６９】
会話ログ１６００は、これまでに質問者と回答者の間で交換された会話データを表すデータである。相談仲介サーバ２は一つの会話につき０又は一つ以上の会話ログを作成する。会話ログは、後ほどユーザの負荷を計算するために用いられる。
【００７０】
列１６０１には、会話ＩＤが保持される。列１６０２には、その会話データの送信者のユーザＩＤが保持される。列１６０３には、送信された会話データが保持される。列１６０４には、その会話データの送信日時が保持される。本実施形態では、会話にＩＭを用いるため、会話データはテキストデータである。しかし、会話に電話を用いる場合は、会話データとして音声データを格納すればよい。また、会話に映像を用いる場合は、会話データとして映像及び音声データを格納すればよい。
【００７１】
図２５は、プレゼンス情報の例を示す。
【００７２】
プレゼンス情報１７００は、各ユーザの現在のプレゼンス情報を表すデータである。相談仲介サーバ２はプレゼンスサーバ４からプレゼンス情報を取得する。相談仲介サーバ２は、ユーザ１人につき一つのプレゼンス情報を保持する。
【００７３】
列１７０１には、ユーザＩＤが保持される。列１７０２には、そのユーザの状態が保持される。列１７０３には、そのユーザの現在使える通信手段が保持される。プレゼンスサーバ４から取得したプレゼンス情報にその他のデータが含まれる場合は、このプレゼンス情報１７００に列を増やして格納すればよい。
【００７４】
図２６は、プレゼンス情報ログの例を示す。
【００７５】
プレゼンス情報ログ１８００は、各ユーザの過去のプレゼンス情報を表すデータである。相談仲介サーバ２は、各ユーザのプレゼンス情報が変化する毎に、一つのプレゼンス情報ログを作成する。このプレゼンス情報ログ１８００を用いることによって、相談仲介サーバ２は各ユーザの予想応答時間の精度を上げることができる。
【００７６】
列１８０１には、プレゼンス情報の取得日時が保持される。列１８０２には、ユーザＩＤが保持される。列１８０３には、そのユーザのその時点での状態が保持される。列１８０４には、そのユーザがその時点で使えた通信手段が保持される。
【００７７】
図２７は、評価データの例を示す。
【００７８】
評価データ１９００は、過去の相談において、質問者が回答者に付けた評価を表すデータである。
【００７９】
列１９０１には、その評価が付けられた相談の相談ＩＤが保持される。列１９０２には、回答者のユーザＩＤが保持される。列１９０３には、質問者その回答者に付けた評価が保持される。列１９０４には、評価が付けられた日時が保持される。
【００８０】
本実施形態では、質問者は回答者に対する評価を”−２”〜”＋２”の値で、値が大きいほど高評価が付けられる。具体的には、−２は「とても悪い」、−１は「悪い」、０は「どちらでもない」、１は「良い」、そして２は「とても良い」に対応する。例えば、行１９１１は、相談ＩＤが５０の相談において、ユーザＩＤ「ｂａｂａ＠ｅｘａｍｐｌｅ．ｃｏｍ」の回答者（馬場）に対して、１（良い）という評価が付けられたことを示している。
【００８１】
図２８は、相談通知データの例を示す。
【００８２】
遅延通知データ２０００は、送信を後回しにしたい相談通知の内容とその待ち時間の長さを表すデータである。相談仲介サーバ２は、わけあって相談通知の送信を遅らせたい場合に、相談通知１件につき一つの遅延通信データを作成する。そして、後述する遅延通知部２３６が、この遅延通知データ２０００に基づいて相談通知を送信する。
【００８３】
列２００１には、会話ＩＤが保持される。列２００２には、相談通知の送信先のユーザＩＤが保持される。列２００３には、相談通知の作成日時が保持される。列２００４には、待ち時間が保持される。列２００５には、相談通知の内容が保持される。
【００８４】
サービス提供部２３１は、ユーザ端末５で動作する相談クライアントとの間でデータの送受信を行うプログラムである。サービス提供部２３１は、相談クライアントから受信したデータを全て相談管理部２３２に転送する。またサービス提供部２３１は、相談管理部２３２から受信したデータを、そのデータに含まれるユーザＩＤに基づいて、いずれかの相談クライアントに転送する。
【００８５】
また、サービス提供部２３１は、相談クライアントから最初のデータを受け取る前に、必ずその相談クライアントのユーザ認証を行う。具体的には、サービス提供部２３１は、相談クライアントから与えられるユーザＩＤとパスワードの組を、ユーザデータ１０００に格納されたデータと比較する。そして、両者が一致すればユーザ認証に成功したと判定する。以降の説明では、相談クライアントのユーザ認証は事前に行われていると仮定する。
【００８６】
相談管理部２３２は、相談クライアントからの要求に応じて、相談の開始・終了処理及び回答者の推薦を行うプログラムである。また、相談管理部２３２は、相談通知部２３３を通して、回答者に相談通知を送信する。
【００８７】
相談通知部２３３は、相談通知サーバ４（本実施形態では、ＩＭサーバ７及びメールサーバ８）を通して相談通知を送信するプログラムである。ＩＭサーバ７及びメールサーバ８には、相談通知を送信するためのアカウントが事前に設定される。それらのアカウントには、例えば、ＳＴＭＰ（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）サーバに接続するためのユーザ名及びパスワードを使用するとよい。相談通知部２３３はそれらのアカウントを通して相談通知を送信する。
【００８８】
会話ログ受信部２３４は、会話サーバ３（本実施形態ではＩＭサーバ７）から送信された会話ログを受信し、データベース２３０に保持するプログラムである。会話ログ受信部２３４は、会話データ１３００、会話参加者データ１４００、相談ログ１５００及び会話ログ１６００を操作する。
【００８９】
会話ログの受信方法は、プッシュ配信とプル配信のどちらでもよい。プッシュ配信とは、会話サーバ３がログ作成と同時にそのログを会話ログ受信部２３４に送信する方法である。プッシュ配信を用いることによって、最新の会話ログを即座に相談仲介サーバ２の動作に反映できる。一方、プル配信とは、相談仲介サーバ２が会話サーバ３に対して定期的に会話ログの送信を要求する方法である。プル配信を用いることによって、相談仲介サーバ２の負荷が少ない時間を選んで会話ログを処理できる。
【００９０】
本実施形態では、会話ログを即座に相談仲介サーバ２の動作に反映することを優先して、プッシュ配信を用いる。
【００９１】
プレゼンス情報受信部２３５は、プレゼンスサーバ４からプレゼンス情報を受信し、データベース２３０に保持するプログラムである。プレゼンス情報受信部２３５は、プレゼンス情報１７００及びプレゼンス情報ログ１８００を操作する。
【００９２】
プレゼンス情報の受信方法は、プッシュ配信とプル配信のどちらでもよい。プッシュ配信は、プレゼンス情報が変更されると、プレゼンスサーバ４がそれを即座にプレゼンス情報受信部２３５に送信することができる方法である。プレゼンスサーバ４は一般にＳＵＢＳＣＲＩＢＥ／ＮＯＴＩＦＹメカニズムによるプッシュ配信を提供している。プッシュ配信を用いることによって、最新のプレゼンス情報を即座に相談仲介サーバ２の動作に反映できる。一方、プル配信とは、相談仲介サーバ２がプレゼンスサーバ４に対して定期的にプレゼンス情報の送信を要求する方法である。プル配信を用いることによって、相談仲介サーバ２の負荷が少ない時間を選んでプレゼンス情報を処理できる。
【００９３】
本実施形態では、プレゼンス情報を即座に相談仲介サーバ２の動作に反映することを優先して、プッシュ配信を用いる。
【００９４】
遅延通知部２３６は、遅延通知データ２０００に基づいて相談通知を送信するプログラムである。例えば以下のような場合に、相談管理部２３２はデータベースに遅延通知データを登録する。
（１）質問者が相談通知を送ろうとしたときに、その回答者のプレゼンス情報が相談通知を受信可能なものでなかった場合（待ち時間は”０”に設定）
（２）質問者が相談通知を送ろうとしたときに、その回答者の負荷が高かった場合（待ち時間は負荷に応じた値を設定）
【００９５】
遅延通知部２３６は、周期的に（例えば、短い間隔で定期的に）及び／又は新しいプレゼンス情報の登録時に起動される。起動された遅延通知部２３６は、全ての遅延通知データについて以下の処理を行う。
【００９６】
まず、遅延通知部２３６は、作成日時２００３に待ち時間２００４を加算した時刻が現在時刻より過去か否かを検査する。加算された時刻が既に過去であれば、待ち時間は終了していると判定する。待ち時間が終了していたら、プレゼンス情報１７００に基づいて、ユーザ２００２が相談通知を受信可能か否かを検査する。ユーザ２００２が相談通知を受信可能であれば、遅延通知部２３６は、相談通知部２３３を通して、そのユーザに相談通知を送信して、その相談通知に関する遅延通知データをデータベースから削除する。
【００９７】
図５は、本発明の第１の実施形態のＩＭサーバ７の構成を示す機能ブロック図である。
【００９８】
ＩＭサーバ７は、ＩＦ７１、ＣＰＵ７２及びメモリ７３を備え、ＩＦ７１、ＣＰＵ７２及びメモリ７３は、データパス７４によって接続されている。
【００９９】
ＩＭサーバ７は、ＩＦ７１を通してパケットを送受信する。ＩＭサーバ７で実行される各プログラムはメモリ７３に格納されている。ＩＭサーバ７の動作時には、ＣＰＵ７２がデータパス７４を通して、メモリに格納されたプログラムを読み出して実行する。図中の矢印は、プログラム間のデータの流れを示している。また、図中の点線矢印は、データベース操作を表している。
【０１００】
メモリ７３はデータベース７３０、ＩＭサーバ部７３１、及び会話ログ送信部７３２を格納する。
【０１０１】
データベース７３０は、ＩＭサーバ部７３１の動作に必要なデータを保持している。そのようなデータにはＩＭサーバのアカウント情報等があるが、本実施形態に特有のデータを格納する必要はないため、本実施形態ではデータ構造の詳細の説明を省略する。
【０１０２】
ＩＭサーバ部７３１は、各ユーザ端末５で動作するＩＭクライアントとの間で会話データの送受信を行うプログラムである。ＩＭサーバ部７３１は、会話データに含まれるユーザＩＤに基づいて、一方のＩＭクライアントから送信された会話データを、もう一方のＩＭクライアントに転送する。この転送は、ＩＭサーバの一般的な動作である。
【０１０３】
会話ログ送信部７３２は、会話ログを相談仲介サーバ２に送信するプログラムである。ＩＭサーバ部７３１は、本実施形態に特有の動作として、会話データを転送する際に、その内容を会話ログの形に整形し、会話ログ送信部７３２に送る。
【０１０４】
図６Ａ〜図８は、相談の開始から終了までの動作の一例を示したシーケンス図である。この例では、ユーザＩＤ「ａｎｄｏ＠ｅｘａｍｐｌｅ．ｃｏｍ」を持ち、ユーザ端末５−１を利用する質問者（安藤）が相談を開始する場合について説明する。
【０１０５】
図６Ａ及び図６Ｂは、質問者が相談を開始してから、回答者に相談通知を送信するまでの動作の一例を示したシーケンス図である。
【０１０６】
まず、質問者はユーザ端末５−１で動作する相談クライアントに、相談内容を入力する（Ｓ１０１）。この相談内容は、回答者に相談内容を伝えるためのデータと、相談仲介サーバが回答者を推薦するためのデータとを含んでいることが必要である。
【０１０７】
図９は、相談クライアントの相談内容の入力画面の一例を示す。
【０１０８】
図９に示す相談内容の入力画面５０００は、相談のタイトル５００１、相談の内容５００２、相談の特徴を表すキーワード５００３、相談の難易度５００４、相談解決までの期限５００５、及び質問者が重視する点５００６の各入力欄を含む。また、入力画面５０００は、相談開始ボタン５００７及びキャンセルボタン５００８を含む。
【０１０９】
タイトル５００１及び内容５００２は、回答者に相談内容を伝えるための必須データである。なお、相談内容が十分伝わるなら、相談内容５００２のみでもよい。また、相談内容は、相談クライアントが録音した音声や動画として通知してもよい。
【０１１０】
キーワード５００３は、その相談の属性を表す必須データである。しかし、キーワードの入力欄を用意せずに、相談のタイトル５００１及び／又は内容５００２から相談の属性を分析して、キーワードを自動的に生成してもよい。
【０１１１】
難易度５００４は、任意の（選択自由の）データである。質問者が難易度を指定した場合は、その値を難易度の初期値として用いる。質問者は、難易度の指定方法として何らかの数値を入力する。しかし、自分の不得意な事柄の難易度を客観的に数値化することは難しい。そこで、簡単な入力方法としては、質問者がその課題についてこれまでに調べた時間を入力してもらい、その時間の長さから難易度を計算してもよい。
【０１１２】
期限５００５は、任意のデータである。質問者が期限を指定した場合は、その値を期限の初期値として用いる。なお、質問者が期限を指定しなかった場合は、相談仲介サーバは期限がないものと判断するか、又は、予め設定されたシステム共通の初期値（例えば、１日）を期限に設定してもよい。一つの相談が解決しないままいつまでも続くことを防ぎたい場合は、システム共通の初期値を設定しておくことが必要である。
【０１１３】
重視する点５００６は任意のデータである。重視する点５００６は、回答者を推薦する際に、相談仲介サーバ２が回答者の順序づけをする際に参照される。質問者が重視する点を指定しなかった場合は、予め設定されたシステム共通の初期値（例えば、応答の早さ）を重視する点に設定してもよい。
【０１１４】
本実施形態では、相談クライアントは、ユーザ端末５の上で動作する独自のクライアントとする。しかし、相談クライアントは、相談仲介サーバ２の上で動作するＷｅｂアプリケーションであってもよい。ユーザ端末５がＷｅｂブラウザを備えていれば、ユーザ端末５に独自のクライアントをインストールする必要がなくなる。
【０１１５】
次に、ユーザ端末５−１の相談クライアントは、相談開始要求を相談仲介サーバ２に送信する（Ｓ１０２）。相談開始要求は、Ｓ１０１で質問者が入力した値を含む。
【０１１６】
相談仲介サーバ２の相談管理部２３２が相談開始要求を受信すると、相談管理部２３２は、相談開始要求に含まれるデータを相談データ１２００に格納する（Ｓ１０３）。このとき、格納される相談の状態は「相談中」とする。本実施形態では、この相談（質問者が安藤）の相談ＩＤは５０である。
【０１１７】
相談データを格納すると、相談管理部２３２はサービス提供部２３１を通して、ユーザ端末５−１の相談クライアントに、相談開始応答を返信する（Ｓ１０４）。相談開始応答は、この相談に割り当てられた相談ＩＤを含む。相談クライアントは、この相談ＩＤを以後の処理で使用して、回答者検索や相談終了等の処理を相談管理部２３２に要求する。そして、相談開始応答の送信が終了すると、相談管理部２３２は、種類が「相談開始」の相談ログを作成する（Ｓ１０５）。
【０１１８】
次に、質問者は、相談クライアントに、回答者検索を指示する（Ｓ１０６）。相談クライアントは、相談ＩＤを含む回答者検索要求を、相談管理部２３２に送信する（Ｓ１０７）。なお、本実施形態では相談開始要求と回答者検索要求を別に送信したが、相談開始要求と同時に最初の回答者検索が行われてもよい。その場合、質問者の操作を減らすことができる。
【０１１９】
相談管理部２３２が回答者検索要求を受信すると、相談管理部はその相談に適した回答者の一覧（以下、回答者一覧）を作成するために必要な以下のデータを計算する（Ｓ１０８〜Ｓ１１３）。
（１）各ユーザの、その相談に対する適性
（２）各ユーザの、その相談に対する予想作業時間
（３）各ユーザの、その相談に対する予想応答時間
（４）各ユーザの、現時点での負荷
（５）その相談の難易度
（６）その相談の緊急性
（７）各ユーザ間の適性の類似度
【０１２０】
本実施形態では、これらの計算されたデータの一つ以上の組合せを必要とする。全てのデータが必須ではないが、データが多いほど効率的に回答者を推薦することができる。
【０１２１】
具体的には、まず、相談管理部２３２は、相談の特徴と各ユーザの能力から、この相談に対する各ユーザの適性を表す数値（以下、適性点）を計算する（Ｓ１０８）。
【０１２２】
適性点の計算方法の一例を示す。本実施形態では、相談の特徴として、質問者が入力したキーワードを用いる。また、各ユーザの能力は、ユーザ能力データ１１００の値を用いる。本実施形態では，キーワードと、ユーザ能力データ１１００の能力値１１０３が一致するか比較し、一致した場合はそのユーザ能力データの能力値１１０３をユーザの適性点に加算する。
【０１２３】
例えば、ユーザ能力データ（図１９）を参照すると、キーワード「ＨＤＤレコーダー」及び「Ａ社」を指定された相談に対する、ユーザＩＤ「ｂａｂａ＠ｅｘａｍｐｌｅ．ｃｏｍ」のユーザ（馬場）の能力値は、行１１１２に示されるように、”０．８”である。同様に、ユーザ能力データ（図１９）を参照すると、ユーザＩＤ「ｃｈｉｂａ＠ｅｘａｍｐｌｅ．ｃｏｍ」のユーザ（千葉）の能力値は、行１１１３と行１１１４と値を加算し、”２．５”となる。
【０１２４】
次に、相談管理部２３２は、各ユーザのその相談に対する予想作業時間を計算する（Ｓ１０９）。各ユーザの予想作業時間の計算方法の一例を示す。予想作業時間は、以下のいずれか、又は二つ以上の組合せによって計算される。
（１）全ユーザ共通に設定された固定値を加算
（２）各ユーザ毎に設定された固定値を加算
（３）各ユーザの過去の作業時間の平均値を加算
（４）各ユーザの、今回と類似の相談における過去の作業時間の平均値を加算
（５）各ユーザの、今回の相談に対する適性点を元に計算した値を加算
【０１２５】
予想作業時間の計算には、過去の作業時間を用いることができる。これは、各ユーザの作業時間に個人差があるとしても、ある１人のユーザが相談に答える時間はある程度一定だと予想できるためである（上記（３））。また、相談の特徴によって答える時間が変わる可能性を考えて、相談の特徴も考慮してもよい（上記（４））。過去の作業時間の計算には、相談データ１２００及び相談ログ１５００を用いることができる。
【０１２６】
また、Ｓ１０８で計算した適性点から、予想作業時間を計算することもできる（上記（５））。これは、ある質問への適性の高いユーザほど、その質問に迅速に答えられると予想できるからである。
【０１２７】
また、ここで相談管理部２３２は、ユーザ能力データ１１００から、各ユーザ間の適性の類似度を計算することもできる。適性の類似度とは、２人のユーザの間で、得意分野が似通っている度合いである。例えば、本実施形態では、各ユーザのユーザ能力データの中で能力値の高い属性を所定数（例えば、１０個）抽出し、抽出された能力値の間で共通する属性が多いほど類似度が高い、と判定する。しかし、適性の類似度を計算する方法はこの方法に限定されない。例えば、適性の類似度を求めるために、ユーザが属する組織図の情報や、ユーザが属する技術コミュニティの情報を、事前に相談仲介サーバ２に登録してもよい。
【０１２８】
次に、相談管理部２３２は、各ユーザのその相談に対する予想応答時間を計算する（Ｓ１１０）。
【０１２９】
図１０は、相談管理部２３２がユーザＡの予想応答時間を計算する方法の一例のフローチャートである。
【０１３０】
まず、相談管理部２３２は、ユーザＡのプレゼンス情報１７００を取得し、ユーザＡが相談通知を受信可能か否かを判定する（Ｓ２０１）。本実施形態では、相談通知の送信にＩＭ及びメールを用いる。従って、ユーザＡの現在使える通信手段にＩＭ又はメールが含まれていれば、ユーザＡは相談通知を受信可能である。
【０１３１】
ユーザＡが相談通知を受信可能でなかった場合、相談管理部２３２は、ユーザＡが現時点から相談通知を受信可能になるまでの時間の予想値Ｒ０１を計算する（Ｓ２０２）。この予想値Ｒ０１は、プレゼンス情報ログ１８００に基づいて計算することができる。一方、ユーザＡが相談通知を受信可能な場合は、前述した予想値Ｒ０１を”０”とする（Ｓ２０３）。
【０１３２】
予想値Ｒ０１の計算方法の一例を示す。まず相談管理部２３２は、プレゼンス情報ログ１８００に基づいて、ユーザＡが相談通知を受信不能になってから、再度受信可能になるまでの時間（受信不能時間）の平均値を計算する。なお、平均以外の統計処理を用いて計算してもよい。
【０１３３】
また、プレゼンス情報ログ１８００から、ユーザＡが最後に受信不能になってからの経過時間を計算して、受信不能時間の平均値と経過時間の差分をＲ０１とすることができる。ただし、Ｒ０１が負の値の場合（通常の状態よりも受信不能時間が長い場合）は、プレゼンス情報ログによる予想をすることができない。その場合は、Ｒ０１に”０”以上の値を設定する。また、プレゼンス情報によってユーザの状態を特定し、特定されたユーザの状態に応じて、予め定められた値を予想値Ｒ０１に設定してもよい。
【０１３４】
過去の受信不能時間の分析には時間がかかるため、別のプログラム（例えば、プレゼンス情報受信部２３５）でこの分析を事前に行うとよい。また、この受信不能時間を、時間帯や曜日別に計算して、分析の精度を向上させることもできる。例えば、月曜日の午前中にユーザＡが相談通知を受信不能だった場合の、受信不能時間の平均値を計算してもよい。
【０１３５】
次に、相談管理部２３２は、ユーザＡが通知を受信してから会話を開始するまでに必要な時間（すなわち、応答時間）の予想値Ｒ０２を計算する（Ｓ２０４）。
【０１３６】
予想値Ｒ０２の計算方法の一例を示す。まず、相談管理部２３２は、ユーザＡが過去に参加した全ての会話での応答時間を計算する。ユーザＡの過去の応答時間は、相談ログ１５００を参照して計算することができる。過去の応答時間の計算には、種類が「相談通知」のログの日時と、種類が「会話開始」のログの日時の差を計算すればよい。
【０１３７】
なお、ユーザＡが（通知を受けたものの）参加していない会話については、種類が「会話開始」のログが存在しない。よって、このような「会話開始」のログが存在しない会話は、この計算には用いない。その上で、全ての応答時間の平均値をＲ０２とすることができる。なお、平均以外の統計処理を用いて計算してもよい。
【０１３８】
なお、もっと単純に、予想値Ｒ０２は、全ユーザ共通又は各ユーザ毎に設定された固定値（例えば、１分）を設定してもよい。さらに、プレゼンス情報によってユーザの状態を特定し、特定されたユーザの状態に応じて、予め定められた値を予想値Ｒ０２に設定してもよい。
【０１３９】
このとき、ユーザＡが通知された会話に参加する確率Ｒ０３（応答確率Ｒ０３）は、予想値Ｒ０２には反映されていない。予想値Ｒ０２を計算すると共に、応答確率Ｒ０３を計算してもよい（Ｓ２０５）。この応答確率Ｒ０３を、予想応答時間とは別に、質問者に提示することによって、質問者は応答時間が同じ回答者２名を、応答確率という新たな観点で比較することができる。
【０１４０】
また、相談の特徴毎に、応答時間Ｒ０２及び応答確率Ｒ０３を計算してもよい。ユーザ毎に解凍パターンに特徴があるからである。例えば、得意な分野の質問にはすぐに対応するが、苦手な（好きではない）分野の質問は後回しにすることがあり得る。相談の特徴毎に過去の相談ログを分析することによって、予想値Ｒ０２及び応答確率Ｒ０３を計算することができ、予想応答時間の精度を向上することができる。しかし、相談の特徴毎に分析すると、分析に必要な十分な数の相談ログを集める必要がある。
【０１４１】
過去の応答時間及び応答確率の計算には時間が必要であるため、別のプログラム（例えば、会話ログ受信部２３４）によって、この分析を事前に行ってもよい。また、この応答時間及び応答確率を、時間帯や曜日別に計算して、分析の精度を上げることもできる。例えば、月曜日の午前中にユーザＡが相談通知を受信不能だった場合の、受信不能時間の平均値を計算してもよい。
【０１４２】
そして最後に、Ｒ０１とＲ０２との和を計算し、計算された和の値をユーザＡの現時点での予想応答時間とする（Ｓ２０６）。
【０１４３】
次に、相談管理部２３２は、各ユーザの現時点での負荷を計算する（Ｓ１１１）。
【０１４４】
図１１は、相談管理部２３２がユーザＡの負荷を計算する方法の一例のフローチャートである。
【０１４５】
相談管理部２３２は、以下に説明する負荷Ｌ０１〜Ｌ０８全てを計算する必要はなく、必要とされる推薦の精度によって、Ｌ０１〜Ｌ０８の一つ以上、又は任意の組合せを用いることができる。また、Ｌ０１〜Ｌ０８の計算に用いる値を複合的に用いて定義された負荷を計算してもよい。例えば、現在引き受け中の相談の数と、過去一定期間に引き受けた相談の数を複合的に用いて負荷を計算してもよい。
【０１４６】
まず、相談管理部２３２は、ユーザＡの会話参加者データ１４００を取得し、ユーザＡが現在引き受け中の相談があるか否かを判定する（Ｓ３０１）。引き受け中の相談がない場合は、ユーザＡの負荷Ｌ０１〜Ｌ０３を全て”０”に設定する（Ｓ３０５）。一方、引き受け中の相談がある場合は、Ｓ３０２〜Ｓ３０４にて負荷Ｌ０１〜Ｌ０３を計算する。
【０１４７】
具体的には、引き受け中の相談がある場合、相談管理部２３２は、ユーザＡが現在引き受け中の相談の数に応じた負荷Ｌ０１を計算する（Ｓ３０２）。ユーザＡが現在引き受け中の相談の数は、ユーザＡの会話参加者データ１４００を参照することによって計算することができる。
【０１４８】
次に、相談管理部２３２は、引き受け中の相談での発言量に応じた負荷Ｌ０２を計算する（Ｓ３０３）。発言量は、ユーザＡの会話ログ１６００を参照することによって計算することができる。ある会話におけるユーザＡの発言量は、以下の方法のいずれか、又は二つ以上の組合せによって計算することができる。
（１）発言回数に基づく方法（ＩＭの場合はメッセージの送信回数）
（２）発言の多さに基づく方法（ＩＭの場合はメッセージの文字数）
（３）発言の長さに基づく方法（音声の場合は声を出している時間の長さ）
【０１４９】
次に、相談管理部２３２は、ユーザＡが引き受け中の相談の予想終了時刻に応じた負荷Ｌ０３を計算する（Ｓ３０４）。Ｓ１０９で説明した方法によって、現在ユーザＡが引き受け中の相談の予想作業時間を計算し、その相談の経過時間との差を計算することによって、その相談の予想終了時刻を計算することができる。予想終了時刻までの時間が長い場合はＬ０３を大きく設定し、予想終了時刻までの時間が短ければＬ０３を短く又は”０”に設定する。なお、この負荷Ｌ０３の値は時間の次元で計算されているため、ユーザＡの負荷を予想応答時間に加算しやすい。
【０１５０】
次に、相談管理部２３２は、ユーザＡの相談ログ１５００を取得し、ユーザＡが過去一定期間（例えば、過去１日）に引き受けた相談があるか否かを判定する（Ｓ３０６）。その結果、一定期間に引き受けた相談がない場合は、ユーザＡの負荷Ｌ０４〜Ｌ０７を全て”０”に設定する（Ｓ３１１）。一方、一定期間に引き受けた相談がある場合は、Ｓ３０７〜Ｓ３１０にて負荷Ｌ０４〜Ｌ０７を計算する。
【０１５１】
具体的には、所定期間に引き受けた相談がある場合、相談管理部２３２は、ユーザＡが所定期間に引き受けた相談の数に応じた負荷Ｌ０４を計算する（Ｓ３０７）。ユーザＡが所定期間に引き受けた相談の数は、相談ログ１５００から取得することができる。
【０１５２】
次に、相談管理部２３２は、所定期間に引き受けた相談で発言量に応じた負荷Ｌ０５を計算する（Ｓ３０８）。相談における発言量は、Ｓ３０３と同様に、ユーザＡの会話ログ１６００から取得することができる。
【０１５３】
次に、相談管理部２３２は、所定期間に引き受けた相談で受けた評価に応じた負荷Ｌ０６を計算する（Ｓ３０９）。これは、相談で受けた評価と、ユーザＡがその相談に割いた労力には関連があると思われるためである。評価の代わりに、ユーザＡが解決した相談の数を用いても、同様の効果があると思われる。ユーザＡが過去に受けた評価は、評価データ１９００から取得することができる。
【０１５４】
次に、相談管理部２３２は、所定期間に引き受けた相談での会話時間に応じた負荷Ｌ０７を計算する（Ｓ３１０）。これは、会話時間の長さと、ユーザＡがその相談に割いた労力には関連があると思われるためである。ユーザＡが所定期間に引き受けた相談の会話時間は、相談ログ１５００から取得することができる。
【０１５５】
次に、相談管理部２３２は、ユーザＡの相談ログ１５００を取得し、ユーザＡへ過去一定期間（例えば、過去１日）に通知された相談があるか否かを判定する（Ｓ３１２）。その結果、そのような相談がない場合は、ユーザＡの負荷Ｌ０８を０に設定する（Ｓ３１４）。一方、一定期間に通知された相談がある場合は、Ｓ３１３にて負荷Ｌ０８を計算する。
【０１５６】
具体的には、一定期間に通知された相談がある場合、相談管理部２３２は、ユーザＡへ所定期間に通知された相談の数に応じた負荷Ｌ０８を計算する（Ｓ３１３）。ユーザＡが所定期間に通知された相談の数は、相談ログ１５００から取得することができる。
【０１５７】
最後に、相談管理部２３２は、ユーザＡの負荷Ｌ０１〜Ｌ０８に基づいて、ユーザＡの総負荷Ｌ０９を計算する（Ｓ３１４）。質問者に提示する予想応答時間に、負荷に基づく値を加算する場合は、ユーザＡの総負荷を時間に変換する必要がある。
【０１５８】
次に、相談管理部２３２は、その相談の難易度を計算する（Ｓ１１２）。
【０１５９】
相談の難易度の計算方法の一例を示す。相談の難易度は、以下のいずれか一つのデータ、又は二つ以上のデータの組合せに基づいて計算される。難易度の計算には、以下のデータの一部でもよいが、データが多ければ効率的な推薦を行うことができる。
（１）質問者が入力した難易度
（２）その相談の依頼通知を送信されたが、応答しなかった回答者の総数
（３）その相談を引き受けたが、解決できなかった回答者の総数
（４）その相談に関する総発言量
（５）その相談に関する総会話時間
【０１６０】
相談管理部２３２は、難易度の計算に用いる計算式を事前に保持している必要がある。例えば、（２）を難易度の計算に用いる場合、「（２）の総数が”０”なら難易度に”０”を加算、”１”〜”５”なら”１”を加算、”５”〜”１０”なら”２”を加算、”１１”以上なら”３”加算」という計算式が考えられる。
【０１６１】
次に、相談管理部２３２は、その相談の緊急性を計算する（Ｓ１１３）。
【０１６２】
相談の緊急性の計算方法の一例を示す。相談の緊急性は、相談データ１２００の期限１２０７に基づいて計算される。相談管理部２３２は、緊急性の計算に用いる計算式を事前に保持している必要がある。例えば、「期限までの残り時間が１日以上あれば緊急性”０”、１日〜６時間なら緊急性”１”、６時間〜１時間なら緊急性”２”、１時間〜３０分なら緊急性”３”、３０分〜１０分なら緊急性”４”、１０分以下なら緊急性”５”」という計算式が考えられる。また、相談データ１２００の期限１２０７が何も設定されていない場合は、緊急性”０”とする。
【０１６３】
以上で、回答者一覧の作成に必要な値の計算が完了する。
【０１６４】
そして、相談管理部２３２は、Ｓ１０８〜Ｓ１１３で計算したデータに基づいて、質問者に提示する回答者一覧を作成する（Ｓ１１４）。
【０１６５】
図１２は、相談管理部２３２が回答者一覧を作成する方法の一例のフローチャートである。
【０１６６】
まず、相談管理部２３２は、質問者を除く全てのユーザを回答者一覧に追加する（Ｓ４０１）。回答者一覧に追加するデータは、ユーザデータ１０００から取得した名前等を含む。
【０１６７】
次に、相談管理部２３２は、質問者の重視する点に基づいて、回答者一覧に残っているユーザの順序づけを行う（Ｓ４０４）。質問者の重視する点は、相談データ１２００の重視する点１２０８から取得することができる。
【０１６８】
そして、相談管理部２３２は、現在日時に、Ｓ１１０で計算した予想応答時間（又は、予想応答時間とＳ１０９で計算された予想作業時間との和）を足した日時が相談の期限を越えてしまうユーザを除外する（Ｓ４０２）。これによって、質問者の指定した期限に間に合わないと思われるユーザに対する無駄な相談通知を防ぐことができる。
【０１６９】
次に、相談管理部２３２は、負荷Ｌ０１〜Ｌ０９の全て又は一部が、システムに応じて規定されている閾値を超えているユーザを除外する（Ｓ４０３）。これによって、負荷の高すぎるユーザに対する更なる相談通知を防ぐことによって、各ユーザの負荷を均等化することができる。
【０１７０】
これ以降の処理（Ｓ４０５〜Ｓ４０８）では、相談管理部２３２は、相談仲介システム全体での効率を考慮して、回答者一覧に残っているユーザの一部を除外するか、又は順位を下げる。このため、相談管理部２３２は、Ｓ４０５〜Ｓ４０８の処理の一つ又は二つ以上の任意の組合せを用いることができる。又は、Ｓ４０５〜Ｓ４０８の処理を複合的に用いて求められた新たな順位付けのルールを用いてもよい（例えば、Ｓ４０５とＳ４０６の処理を複合的に行うために、適性点と負荷を同時に考慮する）。
【０１７１】
また、ユーザの一部を除外する際には、回答者一覧に残っているユーザ数も併せて考慮するのが望ましい。最終的に、回答者一覧には何人かのユーザが残っている必要があるため、回答者一覧に残っているユーザが少ない場合は、除外するユーザの数は減らした方がよい。
【０１７２】
相談管理部２３２は、相談の難易度及び緊急度に応じて、適性点の高いユーザの一部を除外するか、又はその順位を下げる（Ｓ４０５）。これは、簡単かつ緊急度の低い相談はできるだけ普通のユーザに振り分けるためである。具体的には、例えば、「難易度が”０”の質問については、適性点が”２”以上のユーザを推薦しない（又は、適性点が”２”以上のユーザの順位を下げる）」、「難易度が”１”の質問については、適性点が”２”以上のユーザを２名まで推薦してよい（２名を越える分は推薦しないか、又は推薦する順位を下げる）」等のルールを予め定義しておくとよい。
【０１７３】
相談管理部２３２は、相談の難易度及び緊急度に応じて、負荷の高いユーザの一部を除外するか、又はその順位を下げる（Ｓ４０６）。これは、簡単かつ緊急度の低い相談はできるだけ暇なユーザに振り分けるためである。具体的には、例えば、「難易度が”０”の質問については、負荷が３０分以上のユーザを推薦しない（又は、負荷が３０分以上のユーザの下げる）」、「難易度が”１”の質問については、負荷が３０分以上のユーザを２名まで推薦してよい（２名を越える分は推薦しないか、又は推薦する順位を下げる）」等のルールを予め定義しておくとよい。
【０１７４】
次に、相談管理部２３２は、回答者一覧に残っているユーザの中に、適性の類似度の高いユーザの集合が存在するか否かを検査する（Ｓ４０７）。そのような集合が存在する場合は、その集合に含まれるユーザの一部を回答者一覧から除外するか、その順位を下げるか、又は質問者のための印を付ける（Ｓ４０８）。これは、似たタイプの回答者を回答者一覧に何人も表示しないようにするためである。すなわち、得意分野が似たタイプの複数の回答者を比較するよりも、得意分野が異なった複数の回答者を比較できた方が、質問者が回答者を選びやすい場合があるためである。
【０１７５】
なお、適性の類似度の高いユーザの集合に含まれるユーザの順位を上げてもよい。これは、似たタイプの回答者を参加させて、専門的な意見を収集し、的確な回答を得るためである。
【０１７６】
次に、相談管理部２３２は、この質問に関して過去に通知又は会話した回答者がいる場合に（Ｓ４０９）、回答者一覧に残っているユーザの中に、過去の回答者と適性の類似度が高いユーザが存在するか否かを判定する（Ｓ４１０）。そのようなユーザが存在する場合、それらのユーザを回答者一覧から除外するか、その順位を下げるか、又は質問者のための印を付ける（Ｓ４１１）。これは、似たタイプの回答者に何度も相談しないようにするためである。過去の回答者と似たタイプの回答者に相談するよりも、過去の回答者とは違うタイプの回答者に相談した方が、過去の（解決に至らなかった）回答とは違う回答を得られる可能性が高いと思われるからである。
【０１７７】
そして、以上のようにして生成した回答者一覧を、相談管理部２３２はユーザ端末５−１の相談クライアントへ送信する（Ｓ１１５）。回答者一覧を送信すると、相談管理部２３２は、種類が「回答者検索」の相談ログを作成する（Ｓ１１６）。
【０１７８】
図１３は、相談クライアントによって表示される回答者一覧画面の例を示す。
【０１７９】
図１３に示す回答者一覧画面５１００は、回答者の名前５１０１、適性点５１０２、予想応答時間５１０３、予想作業時間５１０４、予想応答時間と予想作業時間の合計値５１０５、各回答者への相談通知を指示するためのボタン５１０６を含む。
【０１８０】
質問者は、この回答者一覧に表示された回答者の候補の中から、相談したい回答者を選択し、その回答者への相談通知を指示する（Ｓ１１７）。質問者が明示的に回答者を選択する場合、回答者一覧を見た上で、相談仲介サーバ２が持たない情報（質問者の知人関係等）に基づいて回答者を選択できる。
【０１８１】
なお、質問者に回答者を選択させる代わりに、相談仲介サーバが回答者一覧の上位にいる回答者を自動的に選択することもできる。回答者を自動的に選択する場合は、質問者が回答者を比較・検討する手間が省くことができる。
【０１８２】
本実施形態では、質問者が明示的に、ユーザＩＤ「ｂａｂａ＠ｅｘａｍｐｌｅ．ｃｏｍ」のユーザ（馬場）を最初の回答者として選んだ場合について説明する。
【０１８３】
次に、ユーザ端末５−１の相談クライアントは、相談開始要求を相談仲介サーバ２に送信する（Ｓ１１８）。相談開始要求は、回答者を識別するための値を含む（回答者のユーザＩＤ、又はＳ１１５の回答者一覧における順番、等）。
【０１８４】
相談管理部２３２は、この相談開始要求を受信すると、質問者及び指示された回答者に対して相談通知を送信するための通信手段を選択する（Ｓ１１９）。まず、相談管理部２３２は、各ユーザが現在使える通信手段をプレゼンス情報１７００から取得する。そして、それらの通信手段の中に、相談通知部２３３がサポート可能な通信手段が含まれているか否かを判定する。本実施形態では質問者（安藤）も回答者（馬場）もＩＭを使うことができるので、質問者及び回答者への相談通知はＩＭサーバ７を通して、各ユーザのＩＭクライアントへ送信される（Ｓ１２０〜Ｓ１２３）。
【０１８５】
図１４は、ＩＭクライアントが相談通知を表示する画面の例であって、回答者（馬場）に通知された相談通知の表示例を示す。
【０１８６】
図１４に示す相談通知表示画面５２００は、通信相手表示欄５２０１、メッセージ表示欄５２０２、会話の終了を指示するためのボタン５２０３、自分から送信するメッセージの入力欄５２０４、メッセージを送信するためのボタン５２０５を含む。
【０１８７】
メッセージ表示欄５２０２は、相談のタイトル、相談内容、相談のキーワード、相談開始日時、質問者に提示された予想応答時間、質問者に提示された予想作業時間、及び質問者からの依頼を受ける方法（質問者と通信するための識別子）を含む。このように、予想応答時間や予想作業時間を回答者に提示することによって、回答者はどのくらい急いで（又は、急がずに）回答すべきかを判断することができる。
【０１８８】
相談管理部２３２は、相談通知を送信し終わると、送信した相談通知の数だけ、種類が「相談通知」の相談ログを作成する（Ｓ１２４）。また、会話データと会話参加者データを追加する（Ｓ１２５）。
【０１８９】
しかし、ユーザがＩＭが使えず、メールのみが使える場合は、そのユーザへの相談通知はメールサーバ８を通して送信される（Ｓ１２６〜Ｓ１２７）。このように、複数の通信手段を用いて相談通知を送ることによって、システム全体で相談に回答できる回答者の数を増やすことができる。
【０１９０】
さらに、ユーザがメールもＩＭも使えない場合は、そのユーザへの相談通知をデータベース２３０上に遅延通知データ２０００として一時的に蓄積する（待ち時間は”０”に設定）。遅延通知部２３６は、そのユーザがメールかＩＭで相談通知を受信できるようになった段階で、蓄積された相談通知を送信する。
【０１９１】
図７は、質問者と回答者の間の会話が開始してから終了するまでの動作の一例を示すシーケンス図である。
【０１９２】
回答者が通知を見て、その質問者からの相談を受けることを決めた場合、まず回答者は、その通知に含まれていた質問者の識別子をＩＭクライアントに入力する（Ｓ１３１）。
【０１９３】
図１５は、ＩＭクライアントによって表示される会話画面の例であって、回答者（馬場）の端末に表示される画面の例を示す。
【０１９４】
図１５に示す会話画面５３００は、通信相手の識別子の入力欄５３０１、過去の会話データの表示欄５３０２、会話終了を指示する５３０３、自分の発言内容の入力欄５３０４、及び自分の発言内容の送信を指示するボタン５３０５を含む。回答者は、通知された質問者の識別子を、入力欄５３０１に入力する。この入力は、通知を受信した際に、ＩＭクライアントによって自動化又は半自動化（例えば、メッセージ表示欄５２０２に表示された識別子をクリックすると自動的に入力）されてもよい。
【０１９５】
回答者が質問者の識別子をＩＭクライアントに入力すると、ユーザ端末５−２のＩＭクライアントは、ＩＭサーバ７に会話開始要求を送信する（Ｓ１３２）。この会話開始要求には、会話を開始したユーザ（馬場）の識別子と、会話相手のユーザ（安藤）の識別子が含まれる。ＩＭサーバ７のＩＭサーバ部７３１は、この会話開始要求をユーザ端末５−１のＩＭクライアントに送信する（Ｓ１３３）。
【０１９６】
ユーザ端末５−１のＩＭクライアントは、会話が可能な状態であれば、会話開始応答をＩＭサーバ７へ返信する（Ｓ１３４）。この会話開始応答にも、会話を開始したユーザ（馬場）の識別子と、会話相手のユーザ（安藤）の識別子が含まれる。ＩＭサーバ部７３１は、この会話開始応答をユーザ端末５−２のＩＭクライアントに送信する。
【０１９７】
以上で、会話の開始手続きは完了する。
【０１９８】
ＩＭサーバ部７３１は、会話の開始手続きが完了すると、ユーザ端末５−１とユーザ端末５−２の間で会話が行われることをデータベース７３０に記録する。これは、今後の会話データを転送するために、ＩＭサーバで一般に行われる処理である。
【０１９９】
さらに、ＩＭサーバ部７３１は、種類が「会話開始」の会話ログを、会話ログ送信部７３２に送る。このログの取得は本実施形態の特有の動作である。ここでは、質問者と回答者が同時に会話へ参加したため、２人分の会話ログを送る。会話ログ送信部７３２は、これらのログを、相談仲介サーバ２の会話ログ受信部２３４へ送信する（Ｓ１３６）。
【０２００】
会話ログ受信部２３４は、会話ログを受信すると、受信したログを、種類が「会話開始」の相談ログを生成する（Ｓ１３７）。
【０２０１】
これ以降、ユーザ（質問者又は回答者）が発言する場合は、ＩＭクライアントに発言内容を入力して、入力された発言の送信を指示する（Ｓ１３８、Ｓ１４３）。ＩＭクライアントは、発言内容の送信の指示を受けると、会話データをＩＭサーバ７に送信する（Ｓ１３９、Ｓ１４４）。会話データには、このデータの発信元の識別子、発信先の識別子、及び発言内容が含まれる。ＩＭサーバ７のＩＭサーバ部７３１は、この会話データを、もう一方のＩＭクライアントへ転送する（Ｓ１４０、Ｓ１４５）。さらに、ＩＭサーバ部７３１は、会話ログ送信部７３２に種類が「会話データ」の会話ログを送る。種類が「会話データ」の会話ログは、会話データの発信元の識別子、発信先の識別子、及び発言内容を含む。会話ログ送信部７３２は、相談仲介サーバ２の会話ログ受信部２３４へ、会話ログを送信する（Ｓ１４１、Ｓ１４６）。会話ログ受信部２３４は、会話ログを受信すると、受信したログを会話ログに追加する（Ｓ１４２、Ｓ１４７）。
【０２０２】
以上説明した手順で会話データのやり取りを繰り返すと、いずれ質問者の課題が解決するか、又は課題が解決する見込みがないことが分かる。その時点に達すると、質問者か回答者のいずれかが会話終了の手続きをする。
【０２０３】
質問者が会話を終了することを決めたと場合、まず質問者は、ＩＭクライアントに会話の終了を指示する（Ｓ１４８）。図１５に示す画面例では、会話終了ボタン５３０３を操作することによって、会話の終了を指示することができる。
【０２０４】
質問者が会話の終了を指示すると、ユーザ端末５−１のＩＭクライアントは、ＩＭサーバ７に会話終了要求を送信する（Ｓ１４９）。この会話終了要求には、会話終了を指示したユーザ（安藤）の識別子と、会話相手（馬場）の識別子が含まれる。ＩＭサーバ７のＩＭサーバ部７３１はこの会話終了要求を、ユーザ端末５−２のＩＭクライアントに送信する（Ｓ１５０）。
【０２０５】
ユーザ端末５−２のＩＭクライアントは、会話終了要求を受信すると、会話画面を閉じて、会話終了応答をＩＭサーバ７へ返信する（Ｓ１５１）。この会話終了応答は、ＩＭサーバ部７３１を通して、ユーザ端末５−１のＩＭクライアントに送信される（Ｓ１５２）。ユーザ端末５−１のＩＭクライアントは、会話終了要求を受信すると、会話画面を閉じる。
【０２０６】
以上で会話の終了手続きは完了する。
【０２０７】
会話の終了手続きが完了すると、ＩＭサーバ部７３１は、ユーザ端末５−１とユーザ端末５−２の間で行われた会話のデータをデータベース７３０から削除する。これは、今後の会話データを転送しないために、ＩＭサーバで一般に行われる処理である。さらに、ＩＭサーバ部７３１は、種類が「会話終了」である会話ログを、会話ログ送信部７３２に送る。この処理は本実施形態特有の動作である。
【０２０８】
以上の説明では、質問者と回答者が同時に会話を終了したため、２人分の会話ログが送られる。会話ログ送信部７３２は、これらのログを相談仲介サーバ２の会話ログ受信部２３４へ送信する（Ｓ１５３）。会話ログ受信部２３４は、会話ログを受信すると、受信したログを、種類が「会話終了」の相談ログに追加する（Ｓ１５４）。
【０２０９】
図８は、質問者が相談の終了を指示してから、回答者を評価するまでの動作の一例を示すシーケンス図である。
【０２１０】
質問者は、一度回答者と会話した後、次の行動を二つの選択肢から選ぶことができる。一つは、また新たな回答者を検索する選択肢で、まだ相談が解決していない場合に選択される。もう一つは、相談を終了するという選択肢で、相談が解決したか又は相談の解決を諦めた場合に選択される。
【０２１１】
図１６は、質問者の相談クライアントによって表示される相談データ表示画面であって、次の行動を選択するための画面の例を示す。
【０２１２】
図１６に示す画面５４００は、相談のタイトルの入力欄５４０１、相談内容の入力欄５４０２、相談のキーワードの入力欄５４０３、相談開始日時の表示欄５４０４、回答者への依頼通知日時５４０５、会話開始日時５４０６、会話終了日時５４０７、回答者の再建策ボタン５４０８、相談終了ボタン５４０９、及び会話内容の表示指示ボタン５４１０を含む。
【０２１３】
質問者が再検索ボタン５４０８を操作すると、図６のＳ１０６〜Ｓ１１５の処理が再び行われる。なお、時間経過に伴ってプレゼンス情報等が変化しているため、回答者一覧は以前と同じにならない可能性が高い。
【０２１４】
一方、質問者が相談終了ボタン５４０９を操作すると、相談終了の手続きを開始する。
【０２１５】
すなわち、質問者が相談クライアントに相談終了を指示すると（Ｓ１６１）、相談クライアントは相談仲介サーバ２に相談終了要求を送信する（Ｓ１６２）。相談終了要求は、その相談の相談ＩＤ（本実施形態では”５０”）を含む。
【０２１６】
相談仲介サーバ２の相談管理部２３２は、相談終了要求を受信すると、相談終了要求によって指示される相談の状態を「評価待ち」に更新する（Ｓ１６３）。
【０２１７】
相談管理部２３２は、相談データを更新すると、ユーザ端末５−１の相談クライアントに相談終了応答を返信する（Ｓ１６４）。そして、相談管理部２３２は、相談終了応答を送信すると、種類が「相談終了」の相談ログを作成する（Ｓ１６５）。
【０２１８】
質問者は、相談終了後、この相談を引き受けた回答者を評価することができる。質問者は、回答者を評価する場合、各回答者の評価を相談クライアントに入力する（Ｓ１６６）。
【０２１９】
図１７は、相談クライアントによって表示される回答者の評価を入力するための画面の例を示す。
【０２２０】
本実施形態では、回答者の評価を５段階で入力する。また、本実施形態では馬場の次に、千葉という回答者に相談した場合について説明する（よって、２名の回答者が表示されている）。
【０２２１】
質問者が相談クライアントに回答者の評価を入力すると、相談クライアントは相談仲介サーバに回答者評価要求を送信する（Ｓ１６７）。回答者評価要求は、その相談の相談ＩＤ（本実施形態では５０）、各回答者の識別子（ユーザＩＤや、相談を通知された順番等）及び評価値（本実施形態では−２〜２の値）を含む。相談仲介サーバ２の相談管理部２３２は、回答者評価要求を受信すると、回答者評価要求に含まれていたデータを評価データ１９００に追加する（Ｓ１６８）。
【０２２２】
相談仲介サーバ２がユーザ能力データ１１００を評価データ１９００に基づいて作成している場合は、このステップで各回答者のユーザ能力データの能力値が再計算される（Ｓ１６９）。具体的には、能力値は次のように再計算される。まず、今回の相談のキーワード「Ａ社」と同じキーワードを持つ相談のうち、馬場の評価が行われた相談を全て取り出す。そして、それらの相談の評価の平均値を計算し、それを馬場の属性「Ａ社」に対する能力値とする。そして計算された能力値は、ユーザ能力データ１１００に格納される。キーワード「Ａ社」と千葉、キーワード「ＨＤＤレコーダー」と馬場、キーワード「ＨＤＤレコーダー」と千葉の組合せについても、同様に再計算する。
【０２２３】
以上の処理が終了すると、相談管理部２３２は、その相談の状態を「終了」に更新する（Ｓ１７０）。そして、相談管理部２３２は、ユーザ端末５−１の相談クライアントに回答者評価応答を返信する（Ｓ１７１）。そして、回答者評価応答を送信すると、相談管理部２３２は、種類が「回答者評価」の相談ログを生成する（Ｓ１７２）。
【０２２４】
以上で、ＩＭを用いた相談は終了する。
【０２２５】
以上説明したように、第１の実施形態では、相談仲介サーバ２が質問者に対して各回答者の予想応答時間及び／又は予想作業時間を提示することによって、質問者は時間という新しい観点に基づいて回答者を選択できるようになる。これにより、能力の高い質問者という観点だけでなく、応答時間や作業時間の短い質問者という観点でも回答者が選ばれるようになるため、能力の高い質問者への負荷を軽減することができる。さらに、質問者は、実際に相談する前に、予想応答時間及び予想作業時間に基づいて、問題解決までの時間を推測できるようになる。これにより、システムの利便性を向上することができる。
【０２２６】
また、相談仲介サーバ２は、数値化された負荷に基づいて、質問者に推薦する回答者一覧の表示順序を変更したり、又は、負荷の高い回答者を回答者一覧から除外する。これによって、負荷の高い回答者への相談依頼を減らすことができ、能力の高い質問者への負荷を軽減することができる。
【０２２７】
また、相談仲介サーバ２は、数値化された負荷を予想応答時間へ加算した値を示すことができる。これによって、能力の高い質問者への相談依頼が自然に軽減することができる。
【０２２８】
また、相談仲介サーバ２は、相談の難易度及び／又は相談解決の期限を考慮することによって、更に効率的に回答者を推薦することができる。簡単な相談や、課題を解決すべき期限が遠い相談については、能力の高い回答者に頼る必要性が低い。従って相談仲介システムは、簡単かつ期限の遠い相談には、できるだけ普通の回答者を推薦する。一方、難しい相談には能力の高い回答者を推薦し、期限の近い相談については予想応答時間が短くかつ能力の高い回答者を推薦する。これによって、能力の高い質問者への負荷を軽減することができる。
【０２２９】
＜実施形態２＞
前述した第１の実施形態では、１対１の通信手段を用いた相談仲介システムの例を説明した。第２の実施形態では、１対多の通信手段を用いた相談仲介システムの例を説明する。
【０２３０】
図２９は、第２の実施形態の通信ネットワークの構成を示す構成図である。
【０２３１】
本発明の第２の実施形態の相談仲介システムは、通信網１、相談仲介サーバ２、ｎ台のユーザ端末５−１〜５−ｎ、プレゼンスサーバ６、メールサーバ８、及び多人数チャットサーバ９を備える。
【０２３２】
通信網１、相談仲介サーバ２、多人数チャットサーバ９、メールサーバ８、プレゼンスサーバ６、ｎ台のユーザ端末５は、互いに、物理的な通信回線１０及び通信網１を介して接続されている。
【０２３３】
本実施形態では、ユーザ間の会話に多人数チャットを用い、相談通知には多人数チャットの招待機能及び電子メールを用いる。従って、本実施形態では、多人数チャットサーバ１０は、会話サーバ３及び相談通知サーバ４として動作する。また、メールサーバ８は、２台目の相談通知サーバ４として動作する。各ユーザ端末５では、多人数チャットクライアントが会話クライアント及び相談通知クライアントとして動作し、メールクライアントが予備の相談通知クライアントとして動作する。また、２台以上のユーザ端末を持つユーザの中には、メールクライアントのみが動作するユーザ端末（例えば、携帯電話機）を持つユーザがいてもよい。
【０２３４】
図３０は、本発明の第２の実施形態の相談仲介サーバ２の構成を示す機能ブロック図である。なお、第１の実施形態の相談仲介サーバ２（図４）と同じ構成は同じ符号を付し、その説明は省略する。
【０２３５】
メモリ２３は、第１の実施形態の相談仲介サーバ２の機能に加え、会話場所管理部２３７、自動通知部２３８を格納する。データベース２３０は、第１の実施形態と同じデータを全て保持する。
【０２３６】
ただし、相談データ１２００に、自動通知の有無を格納する新たな列を追加する。自動通知部２３８は、自動通知の有無を格納する列の値が「自動通知あり」である相談の新しい回答者を、自動的に繰り返し検索し、１人以上の回答者へ相談通知を送信する。
【０２３７】
また、会話データ１３００に、会話場所ＩＤを格納する新たな列を追加し、この新たな列に会話場所ＩＤを格納する。会話場所ＩＤとは、１対多の会話に使われる仮想的な場所を識別するための識別子である。本実施形態では、仮想的な会話場所として多人数チャットのためのチャットルームを使用するため、会話場所ＩＤはチャットルームＩＤである。本実施形態では、チャットルームＩＤはｅメールアドレスと同じ形式に従う文字列を用いる。
【０２３８】
会話場所管理部２３７は、会話場所（チャットルーム）の開始及び終了の手続きをするプログラムである。会話場所管理部２３７は、多人数チャットサーバ９の管理サービス提供部９３３と通信する。
【０２３９】
自動通知部２３８は、質問者が望んだ場合に、相談の状況に応じて自動的に新しい回答者を検索し、１人以上の回答者へ相談通知を送信するプログラムである。
【０２４０】
図３１は、本発明の第２の実施形態の多人数チャットサーバ９の内部構成を示す機能ブロック図である。
【０２４１】
多人数チャットサーバ９は、ＩＦ９１、ＣＰＵ９２及びメモリ９３を備え、ＩＦ９１、ＣＰＵ９２及びメモリ９３は、データパス９４によって接続されている。
【０２４２】
多人数チャットサーバ９はＩＦ９１を通してパケットを送受信する。多人数チャットサーバ９で実行される各プログラムはメモリ９３に格納されている。多人数チャットサーバ９の動作時にはＣＰＵ９２がデータパス９４を通して、メモリ９３に格納されたプログラムを読み出して実行する。図中の矢印は、プログラム間のデータの流れを示す。図中の点線矢印は、データベース操作を示す。
【０２４３】
メモリ９３は、データベース９３０、多人数チャットサーバ部９３１、会話ログ送信部９３２及び管理サービス提供部９３３を格納する。
【０２４４】
データベース７３０は、多人数チャットサーバ部９３１の動作に必要なデータを保持している。データベース７３０に保持されるデータには、多人数チャットサーバのアカウント情報等があるが、本実施形態に特有のデータは含まれないため、保持されるデータの詳細な説明は省略する。
【０２４５】
多人数チャットサーバ部９３１は、各ユーザ端末５で動作する多人数チャットクライアントとの間でメッセージの送受信を行うプログラムである。多人数チャットサーバ部９３１は、会話データに含まれるチャットルームＩＤに基づいて、ある多人数チャットクライアントから送信された会話データを、そのチャットルームに属する残りの参加者に転送する。この転送は、多人数チャットサーバの一般的な動作である。
【０２４６】
会話ログ送信部９３２と管理サービス提供部９３３は、本実施形態に特有のプログラムである。会話ログ送信部９３２は、会話ログを相談仲介サーバ２に送信するプログラムである。多人数チャットサーバ部９３１は会話データを転送する際に、その内容を会話ログの形に整形し、会話ログ送信部７３２に送る。管理サービス提供部９３３は、相談仲介サーバ２に対して、チャットルームの開始及び終了の機能を提供するプログラムである。
【０２４７】
図３２及び図３３は、本発明の第２の実施形態の相談の開始から終了までの動作の一例を示したシーケンス図である。この例では、ユーザＩＤ「ａｎｄｏ＠ｅｘａｍｐｌｅ．ｃｏｍ」を持ち、ユーザ端末５−１を利用する質問者（安藤）が相談を開始する場合について説明する。なお、第１の実施形態から変更のない処理には、図６〜図８と同じ符号を付し、その説明は省略する。
【０２４８】
図３４は、本発明の第２の実施形態の相談内容の入力画面の一例を示す。
【０２４９】
第２の実施形態では、相談内容の入力画面が一部変更される。
【０２５０】
図３４に示す第２の実施形態の相談内容の入力画面は、相談のタイトル５００１、相談の内容５００２、相談の特徴を表すキーワード５００３、相談の難易度５００４、相談解決までの期限５００５、質問者が重視する点５００６、及び自動通知の有無５００９の各入力欄を含む。また、入力画面５０００は、相談開始ボタン５００７及びキャンセルボタン５００８を含む。
【０２５１】
自動通知の有無５００９は、自動通知の有無を入力するチェックボックスである。このチェックボックスの値はＳ１０３において、相談データ１２００に新たに追加された自動通知の有無を格納する列に格納される。
【０２５２】
また、第２の実施形態では、相談データの追加（Ｓ１０３）の後にチャットルームを準備する。相談管理部２３２は、この相談で使用するチャットルームを作成するために、会話場所管理部２３７にチャットルームの作成を指示する。会話場所管理部２３７は、多人数チャットサーバ９の管理サービス提供部９３３に、チャットルーム開始要求を送信する（Ｓ５０１）。チャットルーム開始要求には、その相談のデータを含めてもよい（例えば、チャットルームのタイトルとしてその相談のタイトルを指定する）。
【０２５３】
管理サービス提供部９３３は、多人数チャットサーバ部９３１を通して新しいチャットルームを作成し、チャットルーム開始応答を返信する（Ｓ５０２）。チャットルーム開始応答には、新たに開始したチャットルームのＩＤを含む。管理サービス提供部９３３は、このチャットルームＩＤを相談管理部２３２に返信する。そして、相談管理部２３２は、このチャットルームＩＤを含む会話データを追加する（Ｓ５０３）。以上でチャットルームの準備は完了する。
【０２５４】
回答者へ相談通知を送信する方法は、Ｓ１０１で自動通知を有効にしたか否かで違う方法となる。
【０２５５】
自動通知を有効にしなかった場合は、第１の実施形態と同様の手順で、相談通知を送信する。まず、質問者は相談クライアントに回答者検索を指示し、回答者一覧を得る。回答者一覧を生成するために使用するデータは、第１の実施形態と同じである。
【０２５６】
質問者は、その回答者一覧から１人以上の回答者を選択する。このとき、相談クライアントは、選択された回答者全員に相談通知を送信した場合の予想応答時間、予想作業時間を計算する。これらの時間の計算方法の一例を以下に示す。
（１）選択された回答者のうち、少なくともＮ名が応答するまでの時間（Ｎは１以上の数値）
（２）選択された回答者のうち、少なくともＮ名が相談を解決するまでの時間（Ｎは１以上の数値）
（３）選択された回答者の、予想応答時間の平均値
（４）選択された回答者の、予想作業時間の平均値
【０２５７】
このように、質問者グループ全体での予想応答時間、予想応答時間を質問者に示すことによって、質問者は課題が解決するまでの時間をより簡単に見積もることができる。
【０２５８】
質問者が回答者を選択すると、相談仲介サーバ２はその選択された回答者に対して相談通知を送信する。第２の実施形態では、相談通知にはＳ５０２で取得したチャットルームＩＤが格納される。従って、全ての質問者及び回答者は同じチャットルームに集められる。
【０２５９】
一方、自動通知を有効にした場合は、自動通知部２３８が自動的に相談通知を送信する。自動通知部２３８は、短い間隔で周期的に（例えば、短い間隔で定期的に）及び／又は新しい会話ログの受信時に起動される。起動された自動通知部２３８は、自動通知が有効な各相談データについて、相談通知を送信すべきか否かを判定する（Ｓ５１１）。
【０２６０】
自動通知部２３８は、相談の間で回答者数の偏りが起こらないようにするために、以下のいずれか一つ又は二つ以上の組合せを検査する。
（１）過去一定期間に、その相談の相談通知を送信された回答者数Ａ０１
（２）過去一定期間に、その相談の会話場所に参加した回答者数Ａ０２
（３）現在、その相談の会話場所に参加している回答者数Ａ０３
（４）相談開始から現在までに、その相談の相談通知を送信された回答者数Ａ０４
（５）相談開始から現在までに、その相談に参加した回答者数Ａ０５
【０２６１】
（１）及び（２）は、回答者の参加頻度に関する検査である。一度に大勢の新規回答者が会話場所に参加すると、ユーザ間の意思疎通が難しくなるため、新規に参加する回答者の数を制限する。これによって、質問が長引き、結果として無駄に多くの回答者を招待する事態を防ぐことができる。Ａ０１及びＡ０２は、相談ログ１５００から計算することができる。
【０２６２】
（３）は、大勢の回答者が同時に会話に参加するのを防ぐための検査である。大勢の回答者が同時に会話すると、ユーザ間の意思疎通が難しくなるため、同時に会話する回答者の数を制限する。これによって、質問が長引き、結果として無駄に多くの回答者を招待する事態を防ぐ。Ａ０３は、会話参加者データ１４００から計算することができる。
【０２６３】
（４）及び（５）は、その相談に関わった回答者数に関する検査である。相談に回答者数の上限を設けることによって、相談の間で回答者数の偏りが起こらないようにする。Ａ０４及びＡ０５は、会話参加者データ１４００から計算することができる。
【０２６４】
自動通知部２３８は、Ａ０１〜Ａ０５のそれぞれについて、システム共通の閾値Ｔ０１〜Ｔ０５を設定している。この閾値は、相談の難易度及び／又は緊急度によって変化するものでもよい。その場合、重要な相談ほど多くの回答者を集めることができる。
【０２６５】
Ａ０１〜Ａ０５のいずれかの値が閾値を超えている場合は、新たな回答者を招待しない。一方、Ａ０１〜Ａ０５の全ての値が閾値より少ない場合は、Ｔ０１−Ａ０１、Ｔ０２−Ａ０２、Ｔ０３−Ａ０３、Ｔ０４−Ａ０４、Ｔ０５−Ａ０５のうち最小の値を、新たに相談通知可能な回答者数Ｎとする。
【０２６６】
Ｎが１以上の場合、自動通知部２３８は、第１の実施形態と同じ手順（Ｓ１０８〜Ｓ１１４）で回答者一覧を作成する（Ｓ５１３）。そして、その回答者一覧の上位Ｎ名に対して相談通知を送信する（Ｓ５１４〜Ｓ５１７）。図３２に示す例では、ユーザＩＤ「ｂａｂａ＠ｅｘａｍｐｌｅ．ｃｏｍ」のユーザ（馬場）及びユーザＩＤ「ｃｈｉｂａ＠ｅｘａｍｐｌｅ．ｃｏｍ」のユーザ（千葉）に相談通知を送信している。
【０２６７】
また、まだ質問者に相談通知を送信していない場合は、質問者にも相談通知を送信する（Ｓ５１８、Ｓ５１９）。相談通知の送信の際に相談ログと会話参加者データを追加する点は、第１の実施形態と同じである（Ｓ５２０、Ｓ５２１）。
【０２６８】
なお、自動通知を有効にした場合も、第１の実施形態と同様の手順によって、質問者が相談通知を送信してもよい。その場合、自動通知が良い回答者を推薦しない場合に、質問者が自分で回答者一覧から回答者を選択するという選択肢を提供することができる。
【０２６９】
図３５は、本発明の第２の実施形態の多人数チャットクライアントの会話画面の例を示す。
【０２７０】
図３５に示す多人数チャットクライアントの会話画面５６００は、チャットルームＩＤの表示欄５６０１、相談のタイトルの表示欄５６０２、退室を指示するためのボタン５６０４、メッセージ表示欄５６０５、チャットルームに属しているユーザの表示欄５６０６、自分から送信するメッセージの入力欄５６０７、及びメッセージを送信するためのボタン５６０８を含む。
【０２７１】
本実施形態では、チャットルームへの入室日時をそのユーザの会話開始日時、チャットルームの退室日時をそのユーザの会話終了日時とする。会話開始、会話終了、会話データに関する会話ログの記録方法は、第１の実施形態のＩＭサーバ７と同じである。そのため、本実施形態では会話ログの記録方法の説明を省略する。
【０２７２】
第２の実施形態では、最後に、相談終了要求の受信後にチャットルームの終了手続きが行われる。まず、相談管理部２３２は、会話場所管理部２３７にチャットルームの終了を指示する。会話場所管理部２３７は、多人数チャットサーバ９の管理サービス提供部９３３に対して、チャットルーム終了要求を送信する（Ｓ５４１）。チャットルーム終了要求は、そのチャットルームのチャットルームＩＤを含む。
【０２７３】
管理サービス提供部９３３は、チャットルーム終了要求を受信すると、多人数チャットサーバ部９３１を通して指示されたチャットルームを終了し、チャットルーム終了応答を返信する（Ｓ５４２）。このとき、まだチャットルームに参加しているユーザは、強制的にチャットルームから退室させられる。
【０２７４】
管理サービス提供部９３３はチャットルームの終了の成功を相談管理部２３２に通知する。相談管理部２３２は、チャットルームの終了の成功を受信すると、このチャットルームＩＤを含む会話データの状態を「終了」に更新する（Ｓ５４３）。また、相談管理部２３２は、この会話に関する全ての会話参加者データの参加状況を「離脱」に更新する（Ｓ５４４）。
【０２７５】
以上がチャットルームの終了手続きである。
【０２７６】
回答者の評価に関する処理は、第１の実施形態と同じである。そのため、本実施形態では、回答者の評価に関する処理の説明を省略する。
【０２７７】
以上説明したように、第２の実施形態では、１対多の通信手段を用いて、複数の回答者へ同時に相談できるようになる。これによって、第１の実施形態と比較して、相談解決までの時間を短縮することができる。また、複数の回答者へ同時に相談した場合の、その回答者グループ全体での予想応答時間及び／又は予想作業時間を質問者に提示することによって、質問者が相談解決までの時間を見積もることを助けることができる。
【０２７８】
また、相談仲介サーバ２は、各相談の状況に応じて、新たな回答者へ自動的に相談通知を送信することができる。これによって、会話を自動的に活性化し、相談解決までの時間を早めることができる。
【０２７９】
また、相談仲介サーバ２は、各会話のログを調べることによって、相談の間で回答者数の偏りが起こらないようにする。これにより、相談仲介システム全体での効率を向上させることができる。
【０２８０】
以上、本発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【図面の簡単な説明】
【０２８１】
【図１】本発明の第１及び第２の実施形態の相談仲介システムの構成を示す構成図である。
【図２】本発明の第１及び第２の実施形態の相談仲介システムにおける相談の流れを示す説明図である。
【図３】本発明の第１の実施形態の通信ネットワークの構成を示す構成図である。
【図４】本発明の第１の実施形態の相談仲介サーバの構成を示す機能ブロック図である。
【図５】本発明の第１の実施形態のＩＭサーバの構成を示す機能ブロック図である。
【図６Ａ】本発明の第１の実施形態の相談開始時のシーケンス図である。
【図６Ｂ】本発明の第１の実施形態の相談開始時のシーケンス図である。
【図７】本発明の第１の実施形態の会話開始時のシーケンス図である。
【図８】本発明の第１の実施形態の相談終了時のシーケンス図である。
【図９】本発明の第１の実施形態の相談クライアントの相談内容入力画面の例を示す説明図である。
【図１０】本発明の第１の実施形態のユーザの予想応答時間を計算する処理のフローチャートである。
【図１１】本発明の第１の実施形態のユーザの負荷を計算する処理のフローチャートである。
【図１２】本発明の第１の実施形態の回答者一覧を作成する処理のフローチャートである。
【図１３】本発明の第１の実施形態の相談クライアントの回答者一覧表示画面の例を示す説明図である。
【図１４】本発明の第１の実施形態のＩＭクライアントの相談通知表示画面の例を示す説明図である。
【図１５】本発明の第１の実施形態のＩＭクライアントの会話画面の例を示す説明図である。
【図１６】本発明の第１の実施形態の相談クライアントの相談データ表示画面の例を示す説明図である。
【図１７】本発明の第１の実施形態の相談クライアントの回答者評価入力画面の例を示す説明図である。
【図１８】本発明の第１の実施形態のユーザデータの例を示す説明図である。
【図１９】本発明の第１の実施形態のユーザ能力データの例を示す説明図である。
【図２０】本発明の第１の実施形態の相談データの例を示す説明図である。
【図２１】本発明の第１の実施形態の会話データの例を示す説明図である。
【図２２】本発明の第１の実施形態の会話参加者データの例を示す説明図である。
【図２３】本発明の第１の実施形態の相談ログの例を示す説明図である。
【図２４】本発明の第１の実施形態の会話ログの例を示す説明図である。
【図２５】本発明の第１の実施形態のプレゼンス情報の例を示す説明図である。
【図２６】本発明の第１の実施形態のプレゼンス情報ログの例を示す説明図である。
【図２７】本発明の第１の実施形態の評価データの例を示す説明図である。
【図２８】本発明の第１の実施形態の遅延通知データの例を示す説明図である。
【図２９】本発明の第２の実施形態の通信ネットワークの構成を示す構成図である。
【図３０】本発明の第２の実施形態の相談仲介サーバの構成を示す機能ブロック図である。
【図３１】本発明の第２の実施形態の多人数チャットサーバの内部構成を示す機能ブロック図である。
【図３２】本発明の第２の実施形態の相談開始時のシーケンス図である。
【図３３】本発明の第２の実施形態の相談終了時のシーケンス図である。
【図３４】本発明の第２の実施形態の相談クライアントの相談内容入力画面の例を示す説明図である。
【図３５】本発明の第２の実施形態の多人数チャットクライアントの会話画面の例を示す説明図である。
【符号の説明】
【０２８２】
１  通信網
２  相談仲介サーバ
３  会話サーバ
４  相談通知サーバ
５  ユーザ端末
６  プレゼンスサーバ
７  インスタントメッセージング（ＩＭ）サーバ
８  メールサーバ
９  多人数チャットサーバ
１０  通信回線
２１  ＩＦ
２２  ＣＰＵ
２３  メモリ
２４  データパス
２３０  データベース
２３１  サービス提供部
２３２  相談管理部
２３３  相談通知部
２３４  会話ログ受信部
２３５  プレゼンス情報受信部
２３６  遅延通知部
２３７  会話場所管理部
２３８  自動通知部
７１  ＩＦ
７２  ＣＰＵ
７３  メモリ
７４  データパス
７３０  データベース
７３１  ＩＭサーバ部
７３２  会話ログ送信部
９１  ＩＦ
９２  ＣＰＵ
９３  メモリ
９４  データパス
９３０  データベース
９３１  多人数チャットサーバ部
９３２  会話ログ送信部
９３３  管理サービス提供部
１０００  ユーザデータ
１１００  ユーザ能力データ
１２００  相談データ
１３００  会話データ
１４００  会話参加者データ
１５００  相談ログ
１６００  会話ログ
１７００  プレゼンス情報
１８００  プレゼンス情報ログ
１９００  評価データ
２０００  遅延通知データ
【図１】
2009104288.tif 000003
【図２】
2009104288.tif 000004
【図３】
2009104288.tif 000005
【図４】
2009104288.tif 000006
【図５】
2009104288.tif 000007
【図６Ａ】
2009104288.tif 000008
【図６Ｂ】
2009104288.tif 000009
【図７】
2009104288.tif 000010
【図８】
2009104288.tif 000011
【図９】
2009104288.tif 000012
【図１０】
2009104288.tif 000013
【図１１】
2009104288.tif 000014
【図１２】
2009104288.tif 000015
【図１３】
2009104288.tif 000016
【図１４】
2009104288.tif 000017
【図１５】
2009104288.tif 000018
【図１６】
2009104288.tif 000019
【図１７】
2009104288.tif 000020
【図１８】
2009104288.tif 000021
【図１９】
2009104288.tif 000022
【図２０】
2009104288.tif 000023
【図２１】
2009104288.tif 000024
【図２２】
2009104288.tif 000025
【図２３】
2009104288.tif 000026
【図２４】
2009104288.tif 000027
【図２５】
2009104288.tif 000028
【図２６】
2009104288.tif 000029
【図２７】
2009104288.tif 000030
【図２８】
2009104288.tif 000031
【図２９】
2009104288.tif 000032
【図３０】
2009104288.tif 000033
【図３１】
2009104288.tif 000034
【図３２】
2009104288.tif 000035
【図３３】
2009104288.tif 000036
【図３４】
2009104288.tif 000037
【図３５】
2009104288.tif 000038