通信方法および通信プログラム
【課題】この発明は、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしでおこなう音声通信、いわゆるＰ２Ｐ電話において、ＡＣＤを実現すること。
【解決手段】あらかじめ定められた端末装置群の各オペレータＰＣ１０６が、各自のユーザＩＤでネットワーク１００に対してログインするとともに、オペレータＰＣ１０６に接続されるＡＣＤサーバに対して、少なくとも接続可否状況に関する情報（たとえばプレゼンス情報）を送信し、ＡＣＤサーバが、発信ＰＣ１０２からの発信要求に対して、接続可否状況に関する情報に基づいて、端末装置群のうちのいずれか一つの端末装置（たとえばオペレータＰＣ１０６ｃ）を決定し、決定された端末装置のユーザＩＤ（「ｏｐｅｒｅｔｏｒ３」）に対して自動発信するように、発信ＰＣ１０２に指示する。
【解決手段】あらかじめ定められた端末装置群の各オペレータＰＣ１０６が、各自のユーザＩＤでネットワーク１００に対してログインするとともに、オペレータＰＣ１０６に接続されるＡＣＤサーバに対して、少なくとも接続可否状況に関する情報（たとえばプレゼンス情報）を送信し、ＡＣＤサーバが、発信ＰＣ１０２からの発信要求に対して、接続可否状況に関する情報に基づいて、端末装置群のうちのいずれか一つの端末装置（たとえばオペレータＰＣ１０６ｃ）を決定し、決定された端末装置のユーザＩＤ（「ｏｐｅｒｅｔｏｒ３」）に対して自動発信するように、発信ＰＣ１０２に指示する。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、通信をおこなう通信方法および通信プログラムに関する。
【背景技術】
【０００２】
近年、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなういわゆるＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）電話が普及している。具体的には、たとえば、スカイプテクノロジー社のスカイプ（Ｓｋｙｐｅ）などがあげられる。
【０００３】
また、電話を用いた業態の一つにコールセンターがあり、コールセンターなどで用いられる機能に、ＡＣＤ（Ａｕｔｏｍａｔｉｃ Ｃａｌｌ Ｄｉｓｔｒｉｂｕｔｉｏｎ：着信呼自動分配）がある。これは、代表番号に着信した電話を適宜、手の空いているオペレータに対して振り分ける操作である。
【０００４】
また、特許文献１には、顧客がＷＥＢを閲覧すると、閲覧履歴を保存し、顧客がお問い合わせボタンを押すと、顧客の閲覧履歴に応じてオペレータ端末に表示する内容を分析する。そして、あらかじめ登録されている問い合わせ先電話番号から空いている番号を一つを選び、オペレータ表示内容と紐付けて、顧客画面に該当の電話番号を表示する。顧客が上記顧客画面に表示された電話番号に発信すると、ＰＢＸ（Ｐｒｉｖａｔｅ Ｂｒａｎｃｈ Ｅｘｃｈａｎｇｅ）が、該当の電話番号を処理できる担当者グループの中から空いているオペレータを選択して、取り次ぐ。その際、オペレータ端末に上記顧客画面の作成の際に表示内容を表示することが記載されている。
【０００５】
【特許文献１】特開２００３−２９８７２４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記従来技術にかかるＰ２Ｐ電話は、通常、１対１あるいは１対多数でコミュニケーションするように設計されており、代表番号を用いた、着信を振り分ける機能を備えていないため、Ｐ２Ｐ電話を用いてＡＣＤを実現することができなかった。それゆえに、Ｐ２Ｐ電話をコールセンターで利用することができないという問題点があった。
【０００７】
また、上記特許文献１では、かかってきた電話番号に対してどのオペレータが応対をおこなうかを制御するためにＰＢＸの利用が前提となっている。そのため、ＰＢＸが存在せず、発信から着信までの間に介入できないＰ２Ｐ電話では、上記のシステムが利用できないという問題点があった。
【０００８】
また、上記特許文献１では、コールセンターへの問い合わせ状況によっては、オペレータが全員応対中である場合もある。そのような場合、上記のシステムでは、顧客は電話をかけてみたものの、オペレータが空くまで待ち状態となることになる。すなわち、表示したＷＥＢ画面上に予想待ち時間などを表示したりすることや、メールへ誘導することができないという問題点があった。
【０００９】
また、上記特許文献１では、顧客は画面に表示された電話番号を手で入力する必要がある。電話番号の入力は手間がかかる上、入力ミスなども発生する場合があり、顧客の負荷を軽減できないという問題点があった。
【００１０】
この発明は、上述した従来技術による問題点を解消するため、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしでおこなう通信において、ＡＣＤを実現することが可能な通信方法および通信プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
上述した課題を解決し、目的を達成するため、この発明にかかる通信方法は、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、通信をおこなう通信方法において、あらかじめ定められた端末装置群の各端末装置が、各自のユーザＩＤで前記ネットワークに対してログインするとともに、前記端末装置に接続されるサーバに対して、少なくとも接続可否状況に関する情報を送信し、前記サーバが、発信元端末装置からの発信要求に対して、前記接続可否状況に関する情報に基づいて、前記端末装置群のうちのいずれか一つの端末装置を決定し、決定された端末装置のユーザＩＤに対して自動発信するように、前記発信元端末装置に指示することを特徴とする。
【００１２】
また、この発明にかかる通信方法は、前記通信が、音声通信であることを特徴とする。
【００１３】
また、この発明にかかる通信方法は、前記通信が、文字通信であることを特徴とする。
【００１４】
また、この発明にかかる通信方法は、前記サーバが、発信元端末装置からの発信要求に対して、接続可能な端末装置が存在しなかった場合は、前記発信元端末装置にその旨を伝えるとともに、前記発信元端末装置に関する情報（以下「顧客情報」という）を登録し、接続可能な端末装置が存在するようになった際に、前記発信元端末装置のうちの前記顧客情報に基づいて選択された発信元端末装置へ、当該端末装置のユーザＩＤに対して自動発信するように指示することを特徴とする。
【００１５】
また、この発明にかかる通信方法は、前記発信要求に、所望する接続先に関する情報（以下「接続先情報」という）が含まれており、前記サーバが、あらかじめ登録された前記端末装置に関する情報（以下「オペレータ情報」という）および前記接続先情報に基づいて、前記端末装置群のうちのいずれか一つの端末装置を決定することを特徴とする。
【００１６】
また、この発明にかかる通信方法は、前記接続先情報および前記オペレータ情報に、対応可能な言語に関する情報が含まれていることを特徴とする。
【００１７】
また、この発明にかかる通信方法は、前記サーバが、前記発信元端末装置からの発信要求に関する情報を、決定された端末装置のユーザＩＤを関連付けして記憶し、前記発信元端末装置が、前記サーバからの指示に基づいて、決定された端末装置のユーザＩＤに対して自動発信することを特徴とする。
【００１８】
また、この発明にかかる通信方法は、前記決定された端末装置が、前記発信元端末装置からの発信があった場合に、前記発信要求に関する情報を自らのユーザＩＤに基づいて前記サーバに対して検索要求することを特徴とする。
【００１９】
また、この発明にかかる通信方法は、前記サーバが、前記発信元端末装置からの発信要求に関する情報に対して、一意の管理ＩＤを関連付けして記憶するとともに、当該管理ＩＤを前記発信元端末装置へ送信し、前記発信元端末装置が、前記サーバからの指示に基づいて、決定された端末装置のユーザＩＤに対して自動発信する際に、前記サーバから受信した前記管理ＩＤを送信することを特徴とする。
【００２０】
また、この発明にかかる通信方法は、前記決定された端末装置が、前記発信元端末装置からの発信があった場合に、前記発信要求に関する情報を前記管理ＩＤに基づいて前記サーバに対して検索要求することを特徴とする。
【００２１】
また、この発明にかかる通信方法は、前記サーバが、前記発信元端末装置からの発信要求に関する情報に対して、前記発信元端末装置のユーザＩＤを関連付けして記憶し、前記発信元端末装置が、前記サーバからの指示に基づいて、決定された端末装置のユーザＩＤに対して自動発信する際に、自らのユーザＩＤを送信することを特徴とする。
【００２２】
また、この発明にかかる通信方法は、前記決定された端末装置が、前記発信元端末装置からの発信があった場合に、前記発信要求に関する情報を前記発信元端末装置のユーザＩＤに基づいて前記サーバに対して検索要求することを特徴とする。
【００２３】
また、この発明にかかる通信方法は、前記サーバが、前記発信元端末装置からの発信要求とともに、前記発信元端末装置から送信されてきた所定のＩＤを受信し、前記発信元端末装置からの発信要求に関する情報に対して、前記所定のＩＤを関連付けして記憶し、前記発信元端末装置が、前記サーバからの指示に基づいて、決定された端末装置のユーザＩＤに対して自動発信する際に、前記所定のＩＤを送信することを特徴とする。
【００２４】
また、この発明にかかる通信方法は、前記決定された端末装置が、前記発信元端末装置からの発信があった場合に、前記発信要求に関する情報を前記所定のＩＤに基づいて前記サーバに対して検索要求することを特徴とする。
【００２５】
また、この発明にかかる通信プログラムは、上記に記載の通信方法を前記端末装置に実行させることを特徴とする。
【発明の効果】
【００２６】
本発明によれば、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで通信をおこなう場合に、複数の端末装置からなる端末装置群に対して、サーバを用いてＡＣＤ機能を確実かつ効率的に実現することが可能な通信方法および通信プログラムが得られるという効果を奏する。
【発明を実施するための最良の形態】
【００２７】
以下に添付図面を参照して、この発明にかかる通信方法および通信プログラムの好適な実施の形態を詳細に説明する。
【００２８】
（システム構成）
まず、この発明の実施の形態にかかる通信方法を実現するための通信システムの全体構成について説明する。図１は、この発明の実施の形態にかかる通信方法を実現するためのシステム構成を示す説明図である。
【００２９】
図１において、通信システムにおいて、１００はネットワークであり、１０１は発信ユーザであり、１０２は発信ユーザ１０１が使用する発信ＰＣ（パーソナルコンピュータ）であり、１０３は発信ＰＣ１０２にインストールされているＰ２Ｐ電話ソフト（ウエア）であり、１０４は、後述するＷＷＷサーバにリクエストを送信し、返信されてきたコンテンツを処理するＷＷＷブラウザソフト（ウエア）である。
【００３０】
ここで、通信システムは、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしでおこなう通信システムであり、具体的にはたとえば、具体的には、たとえば一例として、スカイプテクノロジー社のスカイプ（Ｓｋｙｐｅ）などの音声通信をおこなういわゆるＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）電話があげられる（ただし、本実施の形態は、スカイプを用いたものに限定されるものではない）。
【００３１】
また、スカイプには、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信だけでなく、互いに文字を送信しあう文字通信（たとえば、いわゆるチャットなど）をおこなうことが可能となっている。したがって、上記通信システムは、音声通信のみではなく、スカイプを用いたＰ２Ｐの文字通信などであってもよい。
【００３２】
また、１０５（１０５ａ、１０５ｂ、１０５ｃ）はオペレータであり、１０６（１０６ａ、１０６ｂ、１０６ｃ）は、オペレータ１０５が使用するオペレータＰＣ（パーソナルコンピュータ）であり、オペレータ１０５の人数と同じ台数が存在する。また、１０７（１０７ａ、１０７ｂ、１０７ｃ）は、オペレータＰＣ１０６にインストールされているオペレータソフト（ウエア）である。オペレータソフト１０７は、オペレータ１０５が使用するＰ２Ｐ電話ソフト（図示を省略）と、そのＰ２Ｐ電話ソフトを監視し、状態をＡＣＤサーバに通知するモニターソフト（図示を省略）とからなる。
【００３３】
１０８は、ＡＣＤサーバが稼働するＡＣＤサーバマシンであり、１０９は、ＷＷＷブラウザからのリクエストに応じたコンテンツを返信するＷＷＷサーバソフト（ウエア）であり、１１０は、最適なオペレータを判断する、ＷＷＷサーバ上で動くＡＣＤソフト（ウエア）である。以後、説明の便宜上、ＷＷＷサーバソフト１０９とＡＣＤソフト１１０をあわせてＡＣＤサーバソフト（ウエア）として説明する。
【００３４】
１１１は、顧客の属性情報（最終応対オペレータＩＤ、専任オペレータＩＤ、優先度など）を格納した顧客ＤＢであり、顧客ＤＢ１１１は、顧客のユーザＩＤや専用のキー情報を使って検索することができる。さらに、後述するマルチリンガルコールセンターを実現するための使用可能言語情報もあわせて格納するようにしてもよい。
【００３５】
１１２は、オペレータの属性情報（プレゼンス、稼働率、スキルなど）を格納したオペレータＤＢである。ここで、プレゼンスとはオペレータの通話状態で「通話（通信）可能、通話中、取込中、離席中、ダウン」などである。さらに、後述するマルチリンガルコールセンターを実現するためのオペレータごとの使用可能言語情報もあわせて格納する。使用可能言語情報の詳細については後述する。
【００３６】
１１３は、オペレータが空くのを待っている待ちユーザリストである。ここには、待ち状態の顧客のユーザＩＤ、待ち状態になった日時および待ち状態が解消された日時（あるいは待ち状態の継続時間）などを格納する。
【００３７】
なお、上記データベース（顧客ＤＢ１１１、オペレータＤＢ１１２、待ちユーザリスト１１３）の保存場所はＡＣＤサーバからアクセスできれば、別のマシン上でも複数のマシンに分散して保存してもよい。
【００３８】
（処理の手順）
つぎに、この発明の実施の形態にかかる通信方法の処理の手順について説明する。図２は、この発明の実施の形態にかかる通信方法におけるＷＷＷサーバの処理の手順を示すフローチャートであり、図３〜図５、図７〜図１３、図１５および図１６は、当該通信方法の処理フローを示す説明図であり、図６および図１４は、発信ＰＣの画面イメージの一例を示す説明図であり、それぞれ、「ブラウザ」はＷＷＷブラウザソフト１０４を、「Ｐ２Ｐ」はＰ２Ｐ電話ソフト１０３を、「オペレータ」はオペレータソフト１０７を、「ＡＣＤサーバ」はＷＷＷサーバソフト１０９およびＡＣＤソフト１１０を、それぞれ示している。
【００３９】
まず、図３（ログイン）に示すように、発信ユーザ１０１は発信ユーザ１０１のユーザＩＤでＰ２Ｐ電話ソフト１０３にログインする。また、各オペレータ１０５（１０５ａ、１０５ｂ、１０５ｃ）は、オペレータ１０５のユーザＩＤでオペレータソフト１０７にログインする。発信ユーザ１０１のユーザＩＤとして「ｕｓｅｒ０」を、オペレータ１０５のユーザＩＤとして「ｏｐｅｒａｔｏｒ１、ｏｐｅｒａｔｏｒ２、ｏｐｅｒａｔｏｒ３、・・・」をそれぞれ用いる（以下、各処理フロー（図４〜図５、図７〜図１３、図１５および図１６）において同様である）。
【００４０】
図４（プレゼンス情報更新）に示すように、各オペレータソフト１０７はＡＣＤサーバにプレゼンス情報を伝える。ＡＣＤサーバは、各オペレータソフト１０７から伝えられたプレゼンス情報に基づいて、オペレータＤＢ１１２のプレゼンス情報、稼働率などを更新する。以降もオペレータソフト１０７はプレゼンスが変更された場合は随時ＡＣＤサーバにその情報を伝える。ＡＣＤサーバはこれを受けてオペレータＤＢ１１２を更新する。
【００４１】
図２のフローチャートにおいて、まず、ＡＣＤサーバは、発信ユーザ１０１からのリクエストを受信したか否かを判断する（ステップＳ２０１）。図５（ＷＷＷブラウザからＡＣＤサーバにリクエストを送信）に示すように、発信ユーザ１０１はＷＷＷブラウザソフト１０４を使って特定のＵＲＩを指定し、ＡＣＤサーバにリクエストを送信する。その際、発信ユーザ１０１に関する情報（ユーザＩＤ、顧客ＤＢ１１１のキー情報など）や要件に関する情報をパラメータに付加することができる。ただし、これらの情報は敢えて付加する必要はない。
【００４２】
図６は、発信ＰＣの画面イメージを示している。図６のＰＣ画面６００において、６０１はＷＷＷブラウザソフト１０４の表示画面（ウインドウ）例であり、６０２はＰ２Ｐ電話ソフト１０３の表示画面（ウインドウ）例である。ＷＷＷブラウザソフト１０４の表示画面６０１では、「Ｃａｌｌ Ｍｅ！」部分（ボタン）をクリックすることによって、特定のＵＲＩを指定し、ＡＣＤサーバにリクエストを送信することができる。
【００４３】
ステップＳ２０１において、ＡＣＤサーバは、発信するユーザからリクエストを受信するのを待って、リクエストを受信した場合（ステップＳ２０１：Ｙｅｓ）は、つぎに、空きオペレータが存在するか否かを判断する（ステップＳ２０２）。ここで、空きオペレータが存在する場合（ステップＳ２０２：Ｙｅｓ）は、ステップＳ２０７へ移行し、空きオペレータの中から最適なオペレータを決定し（ステップＳ２０７）、ステップＳ２０８へ移行する。
【００４４】
図７（最適なオペレータを判断）に示すように、ＡＣＤサーバは、オペレータ１０５の属性情報や顧客情報などに基づいて、最適なオペレータを決定する。オペレータ１０５の属性情報は、たとえばオペレータＤＢ１１２から取得する。また、顧客情報はたとえば顧客ＤＢ１１１からユーザＩＤなどを用いて検索・取得する。発信ユーザ１０１がＡＣＤサーバにリクエストを送信する際にパラメータに付加することができる、発信ユーザ１０１に関する情報（ユーザＩＤ、顧客ＤＢ１１１のキー情報など）や要件に関する情報が付加されなかった場合は、顧客情報は判断材料に使用しない。
【００４５】
ステップＳ２０２において、空きオペレータが存在しない場合（ステップＳ２０２：Ｎｏ）は、ステップＳ２０３へ移行し、ＡＣＤサーバは、図８（待ちユーザリストに追加）に示すように、顧客情報（ユーザ情報や顧客ＤＢ１１１のキー情報など）を待ちユーザリスト１１３に登録する（ステップＳ２０３）。
【００４６】
その後、ＡＣＤサーバは、図９（待ちメッセージ）に示すように、「しばらくお待ち下さい」などのメッセージをＷＷＷブラウザソフト１０４へ返信する（ステップＳ２０４）。その場合、ＷＷＷブラウザソフト１０４はそのメッセージを表示する。ＡＣＤサーバは、このとき、たとえば待ちユーザリスト１１３の内容やオペレータＤＢ１１２の情報に基づいて待ち時間を計算し、上記メッセージに含めるようにしてもよい。ＷＷＷブラウザソフト１０４はメッセージを表示した後、再びＡＣＤサーバソフトへリクエストを送信し、ＡＣＤサーバソフトはそれを受信する。
【００４７】
つぎに、ＡＣＤサーバは、オペレータに空きができたか否かを判断する（ステップＳ２０５）。ここで、オペレータに空きができるのを待って、空きができた場合（ステップＳ２０５：Ｙｅｓ）は、ステップＳ２０６へ移行する。
【００４８】
そして、ＡＣＤサーバは、たとえば、待ちユーザリスト１１３の内容、顧客ＤＢ１１１から取得した待ちユーザの顧客情報、オペレータＤＢ１１２から取得した通話（通信）可能オペレータの属性情報に基づいて、待ちユーザリスト１１３の中から最適なユーザを選択（判定）し（ステップＳ２０６）、その後、ステップＳ２０８へ移行する。発信ユーザ１０１がＡＣＤサーバにリクエストを送信する際にパラメータに付加することができる、発信ユーザ１０１に関する情報（ユーザＩＤ、顧客ＤＢ１１１のキー情報など）や要件に関する情報が付加されなかった場合は、顧客情報は判断材料に使用しない。
【００４９】
ステップＳ２０２において、空きオペレータが存在する場合（ステップＳ２０２：Ｙｅｓ）は、ＡＣＤサーバは、最適なオペレータを決定し（ステップＳ２０７）、その後、ステップＳ２０８へ移行する。最適なオペレータの決定は、具体的には、たとえば図１０（オペレータ通話（通信）可能）に示すように、まず、オペレータ１０５が通話（通信）可能な状態になった場合、オペレータソフト１０７がＡＣＤサーバにその旨を伝える。ＡＣＤサーバは、オペレータＤＢ１１２のプレゼンス情報、稼働率などを更新する。
【００５０】
ステップＳ２０８において、ＡＣＤサーバは、図１１に示すように、上記発信ユーザ１０１のＷＷＷブラウザソフト１０４に対してリダイレクトを指示する（ステップＳ２０８）。リダイレクトは、たとえばＨＴＴＰステータスコードを用いることができ、また、ｍｅｔａタグやＪａｖａ（登録商標）Ｓｃｒｉｐｔなどを用いる方法であってもよい。この時リダイレクト先のＵＲＩは、アドレススキームがＰ２Ｐ電話ソフトであり、ホスト名やパスなどは、最適なオペレータとして決定されたオペレータ１０５のユーザＩＤとなる。具体的には、たとえば電話の場合は「ｃａｌｌｔｏ：／／ｏｐｅｒａｔｏｒ３」とすればよい。ユーザがチャットでの問合せを希望している場合は、リダイレクト先のＵＲＩは、Ｐ２Ｐ電話のチャット用ソフトに対応するものを用いるとよい。
【００５１】
つぎに、図１２（Ｐ２Ｐ電話ソフトへ連携）に示すように、ＷＷＷブラウザソフト１０４は、ＡＣＤサーバから与えられたＵＲＩのアドレススキームにしたがって、Ｐ２Ｐ電話ソフト１０３に上記ＵＲＩを渡す。そして、図１３（オペレータへ発信）に示すように、Ｐ２Ｐ電話ソフト１０３は、与えられたＵＲＩに基づいて指定されたオペレータＩＤ（「ｏｐｅｒａｔｏｒ３」）へ発信する。図１４は、発信ＰＣの画面イメージを示している。図１４のＰＣ画面６００において、Ｐ２Ｐ電話ソフト１０３の表示画面６０２がＷＷＷブラウザソフト１０４の表示画面６０１よりも前面に表示され、ｏｐｅｒａｔｏｒ３へ発信中であることを、発信ユーザ１０１へ通知する。
【００５２】
その後、ステップＳ２０９において、オペレータソフト１０７から発信ユーザ１０１のユーザＩＤ（「ｕｓｅｒ０」）とオペレータ１０５のユーザＩＤ（「ｏｐｅｒａｔｏｒ３」）を受信したか否かを判断する（ステップＳ２０９）。ここで、受信するのを待って、受信した場合（ステップＳ２０９：Ｙｅｓ）は、オペレータＤＢ１１２のプレゼンス情報、稼働率などを更新する（ステップＳ２１０）とともに、当該オペレータソフト１０７へ所定情報を送信し（ステップＳ２１１）、ステップＳ２０１へ戻る。
【００５３】
具体的には、図１５（情報取得）に示すように、オペレータソフト１０６は、架電を受けた発信ユーザ１０１のユーザＩＤとオペレータ１０５のユーザＩＤをＡＣＤサーバに渡す。ＡＣＤサーバはオペレータＤＢ１１２のプレゼンス情報、稼働率などを更新する。そして、ＡＣＤサーバは所定情報として、たとえば以下の情報をオペレータソフト１０７に送信する。
【００５４】
（１）図５においてＷＷＷブラウザソフト１０４がＡＣＤサーバにアクセスしたときのＵＲＩ。
（２）図５においてＷＷＷブラウザソフト１０４からＡＣＤサーバに渡した情報。
（３）顧客ＤＢ１１１の情報。
（４）待ちユーザリスト１１３の情報（たとえば待ち時間など）。
【００５５】
そして、オペレータ１０５はかかってきた電話をとり、発信ユーザ１０１と通話を開始する。チャットによる対応の場合は、オペレータ１０５は、所定の操作の後、備え付けられたキーボードなどを用いてユーザとチャットを開始する。
【００５６】
このように、ユーザごとに一意に定められたユーザＩＤを使用してネットワーク１００に対してログインされた端末装置どうし（発信ＰＣ１０２とオペレータＰＣ１０６）で、通信をおこなう際に、あらかじめ定められた端末装置群の各オペレータＰＣ１０６が、各自のユーザＩＤでネットワーク１００に対してログインするとともに、オペレータＰＣ１０６に接続されるＡＣＤサーバに対して、少なくとも接続可否状況に関する情報（たとえばプレゼンス情報）を送信し、ＡＣＤサーバが、発信ＰＣ１０２からの発信要求に対して、接続可否状況に関する情報に基づいて、端末装置群のうちのいずれか一つの端末装置（たとえばオペレータＰＣ１０６ｃ）を決定し、決定されたオペレータＰＣのユーザＩＤ（「ｏｐｅｒｅｔｏｒ３」）に対して自動発信するように、発信ＰＣ１０２に指示することによって、ユーザごとに一意に定められたユーザＩＤを使用してネットワーク１００に対してログインされた端末装置どうしで、通信をおこなう場合に、複数の端末装置からなる端末装置群に対して、ＡＣＤサーバを用いて確実かつ効率的に各端末装置へ着信を振り分けることができ、これによって、ＡＣＤ機能を実現することができる。
【００５７】
また、図８〜図１０に示したように、ＡＣＤサーバが、発信ＰＣ１０２からの発信要求に対して、接続可能なオペレータＰＣが存在しなかった場合は、発信ＰＣ１０２にその旨を伝えるとともに、顧客情報を登録し、接続可能なオペレータＰＣが存在するようになった際に、発信ＰＣ１０２のうちの顧客情報に基づいて選択された発信ＰＣ１０２へ、当該オペレータＰＣのユーザＩＤに対して自動発信するように指示することによって、接続待ちの顧客の管理を効率的かつ確実におこなうことができる。
【００５８】
また、発信要求に、発信ユーザに関する情報を含めることができ、ＡＣＤサーバが、あらかじめ登録されたオペレータ情報および発信ユーザに関する情報に基づいて、端末装置群のうちのいずれか一つのオペレータＰＣを決定することによって、所望のオペレータ１０５へ接続でき、これによって、顧客のニーズにあった電話対応を実現することができる。
【００５９】
（リクエスト情報とコール情報との関連付け（その１））
図１７は、リクエスト情報とコール情報との関連付けの処理フローを示す説明図である。また、図１８は、図１７の処理フローの内容を示すシーケンス図である。図１７において、顧客端末１７０１と、ＡＣＤサーバ１７０２と、エージェント端末１７０３がネットワーク１７００を介して接続可能な状態に設定されている。
【００６０】
発信ＰＣである顧客端末１７０１の（ＷＷＷ）ブラウザ１７１１から、ＡＣＤサーバ１７０２（具体的にはＣＴＩ（Ｃｏｍｐｕｔｅｒ Ｔｅｌｅｐｈｏｎｙ Ｉｎｔｅｇｒａｔｉｏｎ）ミドル（ソフトウエア）１７２１）へリクエストをおこなう（ステップＳ１８０１）。ここで、ＣＴＩミドル１７２１は、ＡＣＤサーバ１７０２全体の制御および各エージェント端末１７０３の状態管理をおこなう。またリクエストとは、たとえば顧客がホームページ上のボタンをクリックしてＡＣＤによるエージェントの割り当てを要求することである（図６を参照）。
【００６１】
つぎに、ＡＣＤサーバ１７０２（具体的にはＣＴＩミドル１７２１）は、コール先エージェントを決定する。そして、ＡＣＤサーバ１７０２は、ＤＢ１７２２に対して、顧客端末１７０１からのリクエスト情報と共にコール先エージェント（端末）１７０３のＰ２ＰＩＤをセットする（ステップＳ１８０２）。図１９は、リクエスト情報のテーブルの一例を示す説明図である。その後、ＡＣＤサーバ１７０２は、決定したコール先エージェントのＰ２ＰＩＤを、顧客端末１７０１のブラウザ１７１１あてに通知する（ステップＳ１８０３）。
【００６２】
ブラウザ１７１１は、Ｐ２Ｐ１７１２に対してコール先エージェント１７０３のＰ２ＰＩＤを渡し（ステップＳ１８０４）、Ｐ２Ｐ１７１２は、そのＰ２ＰＩＤのエージェント端末１７０３（のＰ２Ｐ１７３２）へコールを実行する（ステップＳ１８０５）。コールとは、顧客端末１７０１のＰ２Ｐ１７１２から、ＡＣＤサーバ１７０２によって割り当てられたエージェント端末１７０３のＰ２Ｐ１７３２へ発信することである。
【００６３】
エージェント端末１７０３のＰ２Ｐ１７３２は、顧客端末１７０１（のＰ２Ｐ１７１２）からのコールを受信すると、Ｐ２Ｐ制御ソフト１７３１に対して、その旨を知らせる（ステップＳ１８０６）。Ｐ２Ｐ制御ソフト１７３１は、ＡＣＤサーバ１７０３に対して、顧客端末１７０１からのコールがあった旨を含むコール情報と、エージェント端末１７０３のＰ２ＰＩＤを通知する（ステップＳ１８０７）。
【００６４】
ＣＴＩミドル１７２１は、ＤＢ１７２２にセットしたリクエスト情報テーブルから、コール先が該当するＰ２ＰＩＤで最新のレコードを特定する（ステップＳ１８０８）。具体的には、たとえば、コール先が該当するＰ２ＰＩＤにて、図１９に示したリクエスト情報テーブルの「コール先エージェントのＰ２ＰＩＤ」カラムを検索する。そして、「リクエスト日時」カラムが最新のレコードを、対応するリクエストとして特定する。
【００６５】
これによって、ステップＳ１８０１において受けた、顧客端末１７０１のブラウザ１７１１からのリクエストと、ステップＳ１８０５においてエージェント端末１７０３が受けたコールとの関連付けを実行する。このようにして関連付けをすることによって、コールを受けた際に対応するリクエスト情報（操作していたＷＥＢ画面の情報やＨＴＴＰリクエストに含まれる端末情報など）をＡＣＤサーバ１７０２からエージェント端末１７０３へ送信し、図示を省略する表示画面に表示することができる。
【００６６】
（リクエスト情報とコール情報との関連付け（その２））
図２０は、リクエスト情報とコール情報との関連付けの別の処理フローを示す説明図である。また、図２１は、図２０の処理フローの内容を示すシーケンス図である。図２０においては、図１７と同様に、顧客端末１７０１と、ＡＣＤサーバ１７０２と、エージェント端末１７０３がネットワーク１７００を介して接続可能な状態に設定されている。上記リクエスト情報とコール情報との関連付け「（その１）」との違いは、上記「（その１）」がコール先のエージェント端末１７０３のＰ２ＰＩＤを利用するのに対して、「（その２）」は、ＡＣＤサーバ１７０２において、各リクエストに対してリクエストＩＤを採番し、顧客端末１７０１に通知する。顧客端末１７０１は、通知されたリクエストＩＤをコールに添付する点にある。
【００６７】
まず、顧客端末１７０１のブラウザ１７１１から、ＡＣＤサーバ１７０２（具体的にはＣＴＩミドル１７２１）へリクエストをおこなう（ステップＳ２１０１）。そして、ＡＣＤサーバ１７０２（具体的にはＣＴＩミドル１７２１）は、上記「（その１）」と同様に、コール先エージェントを決定する。つぎに、ＡＣＤサーバ１７０２は、ＤＢ１７２２に対して、コール先エージェント（端末）１７０３のＰ２ＰＩＤの代わりに、顧客端末１７０１からのリクエストに対してリクエストＩＤを採番し、リクエスト情報と共にセットする（ステップＳ２１０２）。
【００６８】
図２２は、リクエスト情報テーブルの一例を示す説明図である。図２２において、たとえば「リクエスト管理番号」が上記リクエストＩＤに該当する。したがって、リクエスト情報テーブル「リクエスト管理番号」カラムを通知することになる。リクエスト管理番号は、たとえば、単純な連番を採用すればよい。リクエスト管理番号は、リクエスト日時、決定されたコール先エージェントのＰ２ＰＩＤなどと関連付けされる。その後、ＡＣＤサーバ１７０２は、決定したコール先エージェントのＰ２ＰＩＤおよび採番されたリクエストＩＤを、顧客端末１７０１のブラウザ１７１１あてに通知する（ステップＳ２１０３）。
【００６９】
ブラウザ１７１１は、Ｐ２Ｐ１７１２に対してコール先エージェント１７０３のＰ２ＰＩＤおよびリクエストＩＤを渡し（ステップＳ２１０４）、Ｐ２Ｐ１７１２は、そのＰ２ＰＩＤのエージェント端末１７０３（のＰ２Ｐ１７３２）へコールを実行する（ステップＳ２１０５）。コールを実行する際も、リクエストＩＤを添付しておこなう。
【００７０】
エージェント端末１７０３のＰ２Ｐ１７３２は、顧客端末１７０１（のＰ２Ｐ１７１２）からのコールを受信すると、Ｐ２Ｐ制御ソフト１７３１に対して、その旨を知らせる（ステップＳ２１０６）。Ｐ２Ｐ制御ソフト１７３１は、ＡＣＤサーバ１７０３に対して、顧客端末１７０１からのコールがあった旨を含むコール情報およびリクエストＩＤを通知する（ステップＳ２１０７）。
【００７１】
ＣＴＩミドル１７２１は、ＤＢ１７２２にセットしたリクエスト情報テーブルから、リクエストＩＤを用いてコールを特定する（ステップＳ２１０８）。具体的には、たとえばエージェント端末１７０３で取得したリクエスト管理番号にてリクエスト情報テーブル「リクエスト管理番号」カラムを検索する（必ず１件しか該当しないことになる）。
【００７２】
これによって、ステップＳ２１０１において受けた、顧客端末１７０１のブラウザ１７１１からのリクエストと、ステップＳ２１０５においてエージェント端末１７０３が受けたコールとの関連付けを実行する。このようにして関連付けをすることによって、上記「（その１）」と同様に、コールを受けた際に対応するリクエスト情報（操作していたＷＥＢ画面の情報やＨＴＴＰリクエストに含まれる端末情報など）をＡＣＤサーバ１７０２からエージェント端末１７０３へ送信し、図示を省略する表示画面に表示することができる。
【００７３】
（リクエスト情報とコール情報との関連付け（その３））
図２３は、リクエスト情報とコール情報との関連付けのさらに別の処理フローを示す説明図である。また、図２４は、図２３の処理フローの内容を示すシーケンス図である。図２３においては、図１７、図２０と同様に、顧客端末１７０１と、ＡＣＤサーバ１７０２と、エージェント端末１７０３がネットワーク１７００を介して接続可能な状態に設定されている。上記リクエスト情報とコール情報との関連付け「（その１）」との違いは、上記「（その１）」がコール先のエージェント端末１７０３のＰ２ＰＩＤを利用するのに対し、「（その３）」では、顧客端末１７０１のＰ２ＰＩＤを利用する点にある。
【００７４】
まず、顧客端末１７０１のブラウザ１７１１にて顧客端末１７０１のＰ２ＰＩＤの入力を受け付け、ＡＣＤサーバ１７０２（具体的にはＣＴＩミドル１７２１）へリクエストをおこなう（ステップＳ２４０１）。図２５は、図６と同様に、顧客端末１７０１の画面イメージを示している。図２５のＰＣ画面６００において、２５０１はブラウザ（ソフト）１７１１の表示画面（ウインドウ）例である。表示画面２５０１では、Ｐ２ＰＩＤ入力欄２５０２と、クリックボタン「Ｃａｌｌ Ｍｅ！」２５０３を備え、Ｐ２ＰＩＤ入力欄２５０２に顧客のＰ２ＰＩＤを入力して、クリックボタン２５０３をクリックすることによって、特定のＵＲＩを指定し、ＡＣＤサーバ１７０２にリクエストを送信することができる。
【００７５】
リクエストの際には、入力を受け付けられた顧客端末１７０１のＰ２ＰＩＤもあわせてＡＣＤサーバ１７０２へ通知する。そして、ＡＣＤサーバ１７０２（具体的にはＣＴＩミドル１７２１）は、上記「（その１）」、「（その２）」と同様に、コール先エージェントを決定する。そして、ＡＣＤサーバ１７０２は、ＤＢ１７２２に対して、顧客端末１７０１のＰ２ＰＩＤをリクエスト情報と共にセットする（ステップＳ２４０２）。
【００７６】
図２６は、リクエスト情報テーブルの一例を示す説明図である。図２６において、顧客端末１７０１のＰ２ＰＩＤは、たとえば「顧客Ｐ２ＰＩＤ」カラムにセットし、「顧客Ｐ２ＰＩＤ」として関連付けがされる。その後、ＡＣＤサーバ１７０２は、決定したコール先エージェントのＰ２ＰＩＤを、顧客端末１７０１のブラウザ１７１１あてに通知する（ステップＳ２４０３）。
【００７７】
ブラウザ１７１１は、Ｐ２Ｐ１７１２に対してコール先エージェント１７０３のＰ２ＰＩＤを渡し（ステップＳ２４０４）、Ｐ２Ｐ１７１２は、そのＰ２ＰＩＤのエージェント端末１７０３（のＰ２Ｐ１７３２）へコールを実行する（ステップＳ２４０５）。コールを実行する際に、顧客端末１７０１のＰ２ＰＩＤを添付しておこなう。
【００７８】
エージェント端末１７０３のＰ２Ｐ１７３２は、顧客端末１７０１（のＰ２Ｐ１７１２）からのコールを受信すると、Ｐ２Ｐ制御ソフト１７３１に対して、その旨を知らせる（ステップＳ２４０６）。Ｐ２Ｐ制御ソフト１７３１は、ＡＣＤサーバ１７０２のＣＴＩミドル１７２１に対して、顧客端末１７０１からのコールがあった旨を含むコール情報およびコール元の顧客端末１７０１のＰ２ＰＩＤを通知する（ステップＳ２４０７）。
【００７９】
ＣＴＩミドル１７２１は、ＤＢ１７２２にセットしたリクエスト情報テーブルから、顧客端末１７０１のＰ２ＰＩＤを用いてコールを特定する（ステップＳ２４０８）。取得したコール元の顧客Ｐ２ＰＩＤにてリクエスト情報テーブル「顧客Ｐ２ＰＩＤ」カラムを検索する。複数ヒットした場合は、「リクエスト日時」カラムが最新のレコードを、対応するリクエストとして特定する。
【００８０】
これによって、ステップＳ２４０１において受けた、顧客端末１７０１のブラウザ１７１１からのリクエストと、ステップＳ２４０５においてエージェント端末１７０３が受けたコールとの関連付けを実行する。このようにして関連付けをすることによって、上記「（その１）」、「（その２）」と同様に、コールを受けた際に対応するリクエスト情報（操作していたＷＥＢ画面の情報やＨＴＴＰリクエストに含まれる端末情報など）をＡＣＤサーバ１７０２からエージェント端末１７０３へ送信し、図示を省略する表示画面に表示することができる。
【００８１】
図２７および図２８は、図２５とは別の顧客端末１７０１の画面イメージを示している。図２７において、表示画面２７０１には、会員登録ページが表示されており、顧客はこの会員登録ページから会員番号、氏名、電話番号、Ｅメールアドレスのほか、Ｐ２ＰＩＤを入力し、「登録」ボタン２７０２を押下する。これによって、リクエストが実行されることになる。また、図２８に示すように、図２７において会員登録がなされたことを前提に、顧客のＰ２ＰＩＤの入力欄を設ける代わりに、会員番号を会員に入力させる会員番号入力欄２８０１を備えるようにしてもよい。
【００８２】
以上説明したように、上記方法（「（その１）」〜「（その３）」）によって、リクエスト情報とコール情報を関連付け（紐付け）することができ、エージェント端末１７０３においては、コールがあった場合に、そのコールに紐付けされたリクエスト情報を容易にＡＣＤサーバ１７０２から取得して、表示画面に表示することができる。
【００８３】
また、スカイプによって実現するチャット機能を用いてＡＣＤを実現することも可能である。この場合に、図６のＷＷＷブラウザソフト１０４の表示画面（ウインドウ）例において、「お問合せはこちらをクリック」という表示と「Ｃａｌｌ Ｍｅ！」部分（ボタン）に代えて、あるいは「お問合せはこちらをクリック」という表示と「Ｃａｌｌ Ｍｅ！」部分（ボタン）に加えて、図示は省略するが、「チャットの場合はこちらをクリック」という表示と「Ｃｈａｔ！」部分（ボタン）を設けるとよい。これによって、ユーザがチャットでの問合せを希望している場合は、リダイレクト先のＵＲＩは、Ｐ２Ｐ電話のチャット用ソフトとするとよい。さらに、通話とチャットの両方を用いる場合には、「Ｃａｌｌ Ｍｅ！」部分（ボタン）および「Ｃｈａｔ！」部分（ボタン）の両方をクリックする。これによって、通話とチャットの両方を同時に実現することも可能となる。
【００８４】
（マルチリンガルコールセンターの概要）
つぎに、上記実施の形態を利用したマルチリンガルコールセンターの概要について説明する。あらかじめ、発信ユーザ１０１は、ＷＷＷブラウザソフト１０４に自分が話せる言語を設定しておくと、ＷＷＷサーバソフト１０９は指定された言語で記述されたＨＴＭＬファイルを返すようにする機能がある。この機能はＣｏｎｔｅｎｔ Ｎｅｇｏｔｉａｔｉｏｎと呼ばれている。言語は複数設定することができ、それぞれの優先順位も指定することができる。この機能に対して上記実施の形態を利用することにより、ＷＷＷブラウザから指定された言語が話せるオペレータのユーザＩＤを返すことで、複数の言語に対応したコールセンターを構築することができる。
【００８５】
図２９は、オペレータＤＢ１１２の内容の一例を示す説明図である。図２９において、ユーザＩＤに対応して当該オペレータが使用可能な言語に関する情報が格納されている。図２９の内容から、「ｏｐｅｒａｔｏｒ１は英語と日本語が話せる。」、「ｏｐｅｒａｔｏｒ２は日本語のみ話せる。」、「ｏｐｅｒａｔｏｒ３は英語とフランス語が話せる。」ということがわかる。
【００８６】
また、以下のような内容の情報がＷＷＷブラウザソフト１０４から送られてくる。
【００８７】
Ａｃｃｅｐｔ−Ｌａｎｇｕａｇｅ： ｆｒ； ｑ＝１．０， ｅｎ； ｑ＝０．５（フランス語と英語であればＯＫだが、フランス語の方がよい）
【００８８】
上記数値は、使用可否および優先度を示している。すなわち、数値が設定されているものが使用可能であり、また、数値が高い方が優先度が高いことを示している。具体的には、上記の例では、１．０のフランス語の方が０．５の英語よりも優先度が高いことがわかる。
【００８９】
送られてきた上記の内容と、図２９の内容を比較すると、当該発信ユーザに対しては、ｏｐｅｒｅｔｏｒ２は、空いていても接続しない。ｏｐｅｒｅｔｏｒ１とｏｐｅｒｅｔｏｒ３がいずれも空いている場合は、ｏｐｅｒｅｔｏｒ３へ接続する。ということを判断することができる。
【００９０】
このように、接続先情報およびオペレータ情報に対応可能な言語に関する情報を含めることによって、ＷＷＷサーバによるＡＣＤを応用して、複数の言語に対応したコールセンターを構築することができる。
【００９１】
なお、本実施の形態で説明した通信方法は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーション等のコンピュータで実行することにより実現することができる。このプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。またこのプログラムは、インターネット等のネットワークを介して配布することが可能な伝送媒体であってもよい。
【産業上の利用可能性】
【００９２】
以上のように、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしでおこなう通信に用いるのに適している。
【図面の簡単な説明】
【００９３】
【図１】この発明の実施の形態にかかる通信方法を実現するためのシステムの概要を示す説明図である。
【図２】この発明の実施の形態にかかる通信方法におけるＷＷＷサーバの処理の手順を示すフローチャートである。
【図３】この発明の実施の形態にかかる通信方法の処理フローを示す説明図である。
【図４】この発明の実施の形態にかかる通信方法の処理フローを示す説明図である。
【図５】この発明の実施の形態にかかる通信方法の処理フローを示す説明図である。
【図６】発信ＰＣの画面イメージの一例を示す説明図である。
【図７】この発明の実施の形態にかかる通信方法の処理フローを示す説明図である。
【図８】この発明の実施の形態にかかる通信方法の処理フローを示す説明図である。
【図９】この発明の実施の形態にかかる通信方法の処理フローを示す説明図である。
【図１０】この発明の実施の形態にかかる通信方法の処理フローを示す説明図である。
【図１１】この発明の実施の形態にかかる通信方法の処理フローを示す説明図である。
【図１２】この発明の実施の形態にかかる通信方法の処理フローを示す説明図である。
【図１３】この発明の実施の形態にかかる通信方法の処理フローを示す説明図である。
【図１４】発信ＰＣの画面イメージの一例を示す説明図である。
【図１５】この発明の実施の形態にかかる通信方法の処理フローを示す説明図である。
【図１６】この発明の実施の形態にかかる通信方法の処理フローを示す説明図である。
【図１７】リクエスト情報とコール情報との関連付けの処理フローを示す説明図である。
【図１８】図１７の処理フローの内容を示すシーケンス図である。
【図１９】リクエスト情報テーブルの一例を示す説明図である。
【図２０】リクエスト情報とコール情報との関連付けの別の処理フローを示す説明図である。
【図２１】図２０の処理フローの内容を示すシーケンス図である。
【図２２】リクエスト情報テーブルの一例を示す説明図である。
【図２３】リクエスト情報とコール情報との関連付けの別の処理フローを示す説明図である。
【図２４】図２３の処理フローの内容を示すシーケンス図である。
【図２５】顧客端末の画面イメージの一例を示す説明図である。
【図２６】リクエスト情報テーブルの一例を示す説明図である。
【図２７】顧客端末の画面イメージの別の一例を示す説明図である。
【図２８】顧客端末の画面イメージの別の一例を示す説明図である。
【図２９】オペレータＤＢの内容の一例を示す説明図である。
【符号の説明】
【００９４】
１００，１７００ ネットワーク
１０１ 発信ユーザ
１０２ 発信ＰＣ（パーソナルコンピュータ）
１０３ Ｐ２Ｐ電話ソフト（ウエア）
１０４ ＷＷＷブラウザソフト（ウエア）
１０５（１０５ａ、１０５ｂ、１０５ｃ） オペレータ
１０６（１０６ａ、１０６ｂ、１０６ｃ） オペレータＰＣ（パーソナルコンピュータ）
１０７（１０７ａ、１０７ｂ、１０７ｃ） オペレータソフト（ウエア）
１０８ ＡＣＤサーバマシン
１０９ ＷＷＷサーバソフト（ウエア）
１１０ ＡＣＤソフト（ウエア）
１１１ 顧客データベース（ＤＢ）
１１２ オペレータデータベース（ＤＢ）
１１３ 待ちユーザリスト
【技術分野】
【０００１】
この発明は、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、通信をおこなう通信方法および通信プログラムに関する。
【背景技術】
【０００２】
近年、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなういわゆるＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）電話が普及している。具体的には、たとえば、スカイプテクノロジー社のスカイプ（Ｓｋｙｐｅ）などがあげられる。
【０００３】
また、電話を用いた業態の一つにコールセンターがあり、コールセンターなどで用いられる機能に、ＡＣＤ（Ａｕｔｏｍａｔｉｃ Ｃａｌｌ Ｄｉｓｔｒｉｂｕｔｉｏｎ：着信呼自動分配）がある。これは、代表番号に着信した電話を適宜、手の空いているオペレータに対して振り分ける操作である。
【０００４】
また、特許文献１には、顧客がＷＥＢを閲覧すると、閲覧履歴を保存し、顧客がお問い合わせボタンを押すと、顧客の閲覧履歴に応じてオペレータ端末に表示する内容を分析する。そして、あらかじめ登録されている問い合わせ先電話番号から空いている番号を一つを選び、オペレータ表示内容と紐付けて、顧客画面に該当の電話番号を表示する。顧客が上記顧客画面に表示された電話番号に発信すると、ＰＢＸ（Ｐｒｉｖａｔｅ Ｂｒａｎｃｈ Ｅｘｃｈａｎｇｅ）が、該当の電話番号を処理できる担当者グループの中から空いているオペレータを選択して、取り次ぐ。その際、オペレータ端末に上記顧客画面の作成の際に表示内容を表示することが記載されている。
【０００５】
【特許文献１】特開２００３−２９８７２４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記従来技術にかかるＰ２Ｐ電話は、通常、１対１あるいは１対多数でコミュニケーションするように設計されており、代表番号を用いた、着信を振り分ける機能を備えていないため、Ｐ２Ｐ電話を用いてＡＣＤを実現することができなかった。それゆえに、Ｐ２Ｐ電話をコールセンターで利用することができないという問題点があった。
【０００７】
また、上記特許文献１では、かかってきた電話番号に対してどのオペレータが応対をおこなうかを制御するためにＰＢＸの利用が前提となっている。そのため、ＰＢＸが存在せず、発信から着信までの間に介入できないＰ２Ｐ電話では、上記のシステムが利用できないという問題点があった。
【０００８】
また、上記特許文献１では、コールセンターへの問い合わせ状況によっては、オペレータが全員応対中である場合もある。そのような場合、上記のシステムでは、顧客は電話をかけてみたものの、オペレータが空くまで待ち状態となることになる。すなわち、表示したＷＥＢ画面上に予想待ち時間などを表示したりすることや、メールへ誘導することができないという問題点があった。
【０００９】
また、上記特許文献１では、顧客は画面に表示された電話番号を手で入力する必要がある。電話番号の入力は手間がかかる上、入力ミスなども発生する場合があり、顧客の負荷を軽減できないという問題点があった。
【００１０】
この発明は、上述した従来技術による問題点を解消するため、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしでおこなう通信において、ＡＣＤを実現することが可能な通信方法および通信プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
上述した課題を解決し、目的を達成するため、この発明にかかる通信方法は、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、通信をおこなう通信方法において、あらかじめ定められた端末装置群の各端末装置が、各自のユーザＩＤで前記ネットワークに対してログインするとともに、前記端末装置に接続されるサーバに対して、少なくとも接続可否状況に関する情報を送信し、前記サーバが、発信元端末装置からの発信要求に対して、前記接続可否状況に関する情報に基づいて、前記端末装置群のうちのいずれか一つの端末装置を決定し、決定された端末装置のユーザＩＤに対して自動発信するように、前記発信元端末装置に指示することを特徴とする。
【００１２】
また、この発明にかかる通信方法は、前記通信が、音声通信であることを特徴とする。
【００１３】
また、この発明にかかる通信方法は、前記通信が、文字通信であることを特徴とする。
【００１４】
また、この発明にかかる通信方法は、前記サーバが、発信元端末装置からの発信要求に対して、接続可能な端末装置が存在しなかった場合は、前記発信元端末装置にその旨を伝えるとともに、前記発信元端末装置に関する情報（以下「顧客情報」という）を登録し、接続可能な端末装置が存在するようになった際に、前記発信元端末装置のうちの前記顧客情報に基づいて選択された発信元端末装置へ、当該端末装置のユーザＩＤに対して自動発信するように指示することを特徴とする。
【００１５】
また、この発明にかかる通信方法は、前記発信要求に、所望する接続先に関する情報（以下「接続先情報」という）が含まれており、前記サーバが、あらかじめ登録された前記端末装置に関する情報（以下「オペレータ情報」という）および前記接続先情報に基づいて、前記端末装置群のうちのいずれか一つの端末装置を決定することを特徴とする。
【００１６】
また、この発明にかかる通信方法は、前記接続先情報および前記オペレータ情報に、対応可能な言語に関する情報が含まれていることを特徴とする。
【００１７】
また、この発明にかかる通信方法は、前記サーバが、前記発信元端末装置からの発信要求に関する情報を、決定された端末装置のユーザＩＤを関連付けして記憶し、前記発信元端末装置が、前記サーバからの指示に基づいて、決定された端末装置のユーザＩＤに対して自動発信することを特徴とする。
【００１８】
また、この発明にかかる通信方法は、前記決定された端末装置が、前記発信元端末装置からの発信があった場合に、前記発信要求に関する情報を自らのユーザＩＤに基づいて前記サーバに対して検索要求することを特徴とする。
【００１９】
また、この発明にかかる通信方法は、前記サーバが、前記発信元端末装置からの発信要求に関する情報に対して、一意の管理ＩＤを関連付けして記憶するとともに、当該管理ＩＤを前記発信元端末装置へ送信し、前記発信元端末装置が、前記サーバからの指示に基づいて、決定された端末装置のユーザＩＤに対して自動発信する際に、前記サーバから受信した前記管理ＩＤを送信することを特徴とする。
【００２０】
また、この発明にかかる通信方法は、前記決定された端末装置が、前記発信元端末装置からの発信があった場合に、前記発信要求に関する情報を前記管理ＩＤに基づいて前記サーバに対して検索要求することを特徴とする。
【００２１】
また、この発明にかかる通信方法は、前記サーバが、前記発信元端末装置からの発信要求に関する情報に対して、前記発信元端末装置のユーザＩＤを関連付けして記憶し、前記発信元端末装置が、前記サーバからの指示に基づいて、決定された端末装置のユーザＩＤに対して自動発信する際に、自らのユーザＩＤを送信することを特徴とする。
【００２２】
また、この発明にかかる通信方法は、前記決定された端末装置が、前記発信元端末装置からの発信があった場合に、前記発信要求に関する情報を前記発信元端末装置のユーザＩＤに基づいて前記サーバに対して検索要求することを特徴とする。
【００２３】
また、この発明にかかる通信方法は、前記サーバが、前記発信元端末装置からの発信要求とともに、前記発信元端末装置から送信されてきた所定のＩＤを受信し、前記発信元端末装置からの発信要求に関する情報に対して、前記所定のＩＤを関連付けして記憶し、前記発信元端末装置が、前記サーバからの指示に基づいて、決定された端末装置のユーザＩＤに対して自動発信する際に、前記所定のＩＤを送信することを特徴とする。
【００２４】
また、この発明にかかる通信方法は、前記決定された端末装置が、前記発信元端末装置からの発信があった場合に、前記発信要求に関する情報を前記所定のＩＤに基づいて前記サーバに対して検索要求することを特徴とする。
【００２５】
また、この発明にかかる通信プログラムは、上記に記載の通信方法を前記端末装置に実行させることを特徴とする。
【発明の効果】
【００２６】
本発明によれば、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで通信をおこなう場合に、複数の端末装置からなる端末装置群に対して、サーバを用いてＡＣＤ機能を確実かつ効率的に実現することが可能な通信方法および通信プログラムが得られるという効果を奏する。
【発明を実施するための最良の形態】
【００２７】
以下に添付図面を参照して、この発明にかかる通信方法および通信プログラムの好適な実施の形態を詳細に説明する。
【００２８】
（システム構成）
まず、この発明の実施の形態にかかる通信方法を実現するための通信システムの全体構成について説明する。図１は、この発明の実施の形態にかかる通信方法を実現するためのシステム構成を示す説明図である。
【００２９】
図１において、通信システムにおいて、１００はネットワークであり、１０１は発信ユーザであり、１０２は発信ユーザ１０１が使用する発信ＰＣ（パーソナルコンピュータ）であり、１０３は発信ＰＣ１０２にインストールされているＰ２Ｐ電話ソフト（ウエア）であり、１０４は、後述するＷＷＷサーバにリクエストを送信し、返信されてきたコンテンツを処理するＷＷＷブラウザソフト（ウエア）である。
【００３０】
ここで、通信システムは、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしでおこなう通信システムであり、具体的にはたとえば、具体的には、たとえば一例として、スカイプテクノロジー社のスカイプ（Ｓｋｙｐｅ）などの音声通信をおこなういわゆるＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）電話があげられる（ただし、本実施の形態は、スカイプを用いたものに限定されるものではない）。
【００３１】
また、スカイプには、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信だけでなく、互いに文字を送信しあう文字通信（たとえば、いわゆるチャットなど）をおこなうことが可能となっている。したがって、上記通信システムは、音声通信のみではなく、スカイプを用いたＰ２Ｐの文字通信などであってもよい。
【００３２】
また、１０５（１０５ａ、１０５ｂ、１０５ｃ）はオペレータであり、１０６（１０６ａ、１０６ｂ、１０６ｃ）は、オペレータ１０５が使用するオペレータＰＣ（パーソナルコンピュータ）であり、オペレータ１０５の人数と同じ台数が存在する。また、１０７（１０７ａ、１０７ｂ、１０７ｃ）は、オペレータＰＣ１０６にインストールされているオペレータソフト（ウエア）である。オペレータソフト１０７は、オペレータ１０５が使用するＰ２Ｐ電話ソフト（図示を省略）と、そのＰ２Ｐ電話ソフトを監視し、状態をＡＣＤサーバに通知するモニターソフト（図示を省略）とからなる。
【００３３】
１０８は、ＡＣＤサーバが稼働するＡＣＤサーバマシンであり、１０９は、ＷＷＷブラウザからのリクエストに応じたコンテンツを返信するＷＷＷサーバソフト（ウエア）であり、１１０は、最適なオペレータを判断する、ＷＷＷサーバ上で動くＡＣＤソフト（ウエア）である。以後、説明の便宜上、ＷＷＷサーバソフト１０９とＡＣＤソフト１１０をあわせてＡＣＤサーバソフト（ウエア）として説明する。
【００３４】
１１１は、顧客の属性情報（最終応対オペレータＩＤ、専任オペレータＩＤ、優先度など）を格納した顧客ＤＢであり、顧客ＤＢ１１１は、顧客のユーザＩＤや専用のキー情報を使って検索することができる。さらに、後述するマルチリンガルコールセンターを実現するための使用可能言語情報もあわせて格納するようにしてもよい。
【００３５】
１１２は、オペレータの属性情報（プレゼンス、稼働率、スキルなど）を格納したオペレータＤＢである。ここで、プレゼンスとはオペレータの通話状態で「通話（通信）可能、通話中、取込中、離席中、ダウン」などである。さらに、後述するマルチリンガルコールセンターを実現するためのオペレータごとの使用可能言語情報もあわせて格納する。使用可能言語情報の詳細については後述する。
【００３６】
１１３は、オペレータが空くのを待っている待ちユーザリストである。ここには、待ち状態の顧客のユーザＩＤ、待ち状態になった日時および待ち状態が解消された日時（あるいは待ち状態の継続時間）などを格納する。
【００３７】
なお、上記データベース（顧客ＤＢ１１１、オペレータＤＢ１１２、待ちユーザリスト１１３）の保存場所はＡＣＤサーバからアクセスできれば、別のマシン上でも複数のマシンに分散して保存してもよい。
【００３８】
（処理の手順）
つぎに、この発明の実施の形態にかかる通信方法の処理の手順について説明する。図２は、この発明の実施の形態にかかる通信方法におけるＷＷＷサーバの処理の手順を示すフローチャートであり、図３〜図５、図７〜図１３、図１５および図１６は、当該通信方法の処理フローを示す説明図であり、図６および図１４は、発信ＰＣの画面イメージの一例を示す説明図であり、それぞれ、「ブラウザ」はＷＷＷブラウザソフト１０４を、「Ｐ２Ｐ」はＰ２Ｐ電話ソフト１０３を、「オペレータ」はオペレータソフト１０７を、「ＡＣＤサーバ」はＷＷＷサーバソフト１０９およびＡＣＤソフト１１０を、それぞれ示している。
【００３９】
まず、図３（ログイン）に示すように、発信ユーザ１０１は発信ユーザ１０１のユーザＩＤでＰ２Ｐ電話ソフト１０３にログインする。また、各オペレータ１０５（１０５ａ、１０５ｂ、１０５ｃ）は、オペレータ１０５のユーザＩＤでオペレータソフト１０７にログインする。発信ユーザ１０１のユーザＩＤとして「ｕｓｅｒ０」を、オペレータ１０５のユーザＩＤとして「ｏｐｅｒａｔｏｒ１、ｏｐｅｒａｔｏｒ２、ｏｐｅｒａｔｏｒ３、・・・」をそれぞれ用いる（以下、各処理フロー（図４〜図５、図７〜図１３、図１５および図１６）において同様である）。
【００４０】
図４（プレゼンス情報更新）に示すように、各オペレータソフト１０７はＡＣＤサーバにプレゼンス情報を伝える。ＡＣＤサーバは、各オペレータソフト１０７から伝えられたプレゼンス情報に基づいて、オペレータＤＢ１１２のプレゼンス情報、稼働率などを更新する。以降もオペレータソフト１０７はプレゼンスが変更された場合は随時ＡＣＤサーバにその情報を伝える。ＡＣＤサーバはこれを受けてオペレータＤＢ１１２を更新する。
【００４１】
図２のフローチャートにおいて、まず、ＡＣＤサーバは、発信ユーザ１０１からのリクエストを受信したか否かを判断する（ステップＳ２０１）。図５（ＷＷＷブラウザからＡＣＤサーバにリクエストを送信）に示すように、発信ユーザ１０１はＷＷＷブラウザソフト１０４を使って特定のＵＲＩを指定し、ＡＣＤサーバにリクエストを送信する。その際、発信ユーザ１０１に関する情報（ユーザＩＤ、顧客ＤＢ１１１のキー情報など）や要件に関する情報をパラメータに付加することができる。ただし、これらの情報は敢えて付加する必要はない。
【００４２】
図６は、発信ＰＣの画面イメージを示している。図６のＰＣ画面６００において、６０１はＷＷＷブラウザソフト１０４の表示画面（ウインドウ）例であり、６０２はＰ２Ｐ電話ソフト１０３の表示画面（ウインドウ）例である。ＷＷＷブラウザソフト１０４の表示画面６０１では、「Ｃａｌｌ Ｍｅ！」部分（ボタン）をクリックすることによって、特定のＵＲＩを指定し、ＡＣＤサーバにリクエストを送信することができる。
【００４３】
ステップＳ２０１において、ＡＣＤサーバは、発信するユーザからリクエストを受信するのを待って、リクエストを受信した場合（ステップＳ２０１：Ｙｅｓ）は、つぎに、空きオペレータが存在するか否かを判断する（ステップＳ２０２）。ここで、空きオペレータが存在する場合（ステップＳ２０２：Ｙｅｓ）は、ステップＳ２０７へ移行し、空きオペレータの中から最適なオペレータを決定し（ステップＳ２０７）、ステップＳ２０８へ移行する。
【００４４】
図７（最適なオペレータを判断）に示すように、ＡＣＤサーバは、オペレータ１０５の属性情報や顧客情報などに基づいて、最適なオペレータを決定する。オペレータ１０５の属性情報は、たとえばオペレータＤＢ１１２から取得する。また、顧客情報はたとえば顧客ＤＢ１１１からユーザＩＤなどを用いて検索・取得する。発信ユーザ１０１がＡＣＤサーバにリクエストを送信する際にパラメータに付加することができる、発信ユーザ１０１に関する情報（ユーザＩＤ、顧客ＤＢ１１１のキー情報など）や要件に関する情報が付加されなかった場合は、顧客情報は判断材料に使用しない。
【００４５】
ステップＳ２０２において、空きオペレータが存在しない場合（ステップＳ２０２：Ｎｏ）は、ステップＳ２０３へ移行し、ＡＣＤサーバは、図８（待ちユーザリストに追加）に示すように、顧客情報（ユーザ情報や顧客ＤＢ１１１のキー情報など）を待ちユーザリスト１１３に登録する（ステップＳ２０３）。
【００４６】
その後、ＡＣＤサーバは、図９（待ちメッセージ）に示すように、「しばらくお待ち下さい」などのメッセージをＷＷＷブラウザソフト１０４へ返信する（ステップＳ２０４）。その場合、ＷＷＷブラウザソフト１０４はそのメッセージを表示する。ＡＣＤサーバは、このとき、たとえば待ちユーザリスト１１３の内容やオペレータＤＢ１１２の情報に基づいて待ち時間を計算し、上記メッセージに含めるようにしてもよい。ＷＷＷブラウザソフト１０４はメッセージを表示した後、再びＡＣＤサーバソフトへリクエストを送信し、ＡＣＤサーバソフトはそれを受信する。
【００４７】
つぎに、ＡＣＤサーバは、オペレータに空きができたか否かを判断する（ステップＳ２０５）。ここで、オペレータに空きができるのを待って、空きができた場合（ステップＳ２０５：Ｙｅｓ）は、ステップＳ２０６へ移行する。
【００４８】
そして、ＡＣＤサーバは、たとえば、待ちユーザリスト１１３の内容、顧客ＤＢ１１１から取得した待ちユーザの顧客情報、オペレータＤＢ１１２から取得した通話（通信）可能オペレータの属性情報に基づいて、待ちユーザリスト１１３の中から最適なユーザを選択（判定）し（ステップＳ２０６）、その後、ステップＳ２０８へ移行する。発信ユーザ１０１がＡＣＤサーバにリクエストを送信する際にパラメータに付加することができる、発信ユーザ１０１に関する情報（ユーザＩＤ、顧客ＤＢ１１１のキー情報など）や要件に関する情報が付加されなかった場合は、顧客情報は判断材料に使用しない。
【００４９】
ステップＳ２０２において、空きオペレータが存在する場合（ステップＳ２０２：Ｙｅｓ）は、ＡＣＤサーバは、最適なオペレータを決定し（ステップＳ２０７）、その後、ステップＳ２０８へ移行する。最適なオペレータの決定は、具体的には、たとえば図１０（オペレータ通話（通信）可能）に示すように、まず、オペレータ１０５が通話（通信）可能な状態になった場合、オペレータソフト１０７がＡＣＤサーバにその旨を伝える。ＡＣＤサーバは、オペレータＤＢ１１２のプレゼンス情報、稼働率などを更新する。
【００５０】
ステップＳ２０８において、ＡＣＤサーバは、図１１に示すように、上記発信ユーザ１０１のＷＷＷブラウザソフト１０４に対してリダイレクトを指示する（ステップＳ２０８）。リダイレクトは、たとえばＨＴＴＰステータスコードを用いることができ、また、ｍｅｔａタグやＪａｖａ（登録商標）Ｓｃｒｉｐｔなどを用いる方法であってもよい。この時リダイレクト先のＵＲＩは、アドレススキームがＰ２Ｐ電話ソフトであり、ホスト名やパスなどは、最適なオペレータとして決定されたオペレータ１０５のユーザＩＤとなる。具体的には、たとえば電話の場合は「ｃａｌｌｔｏ：／／ｏｐｅｒａｔｏｒ３」とすればよい。ユーザがチャットでの問合せを希望している場合は、リダイレクト先のＵＲＩは、Ｐ２Ｐ電話のチャット用ソフトに対応するものを用いるとよい。
【００５１】
つぎに、図１２（Ｐ２Ｐ電話ソフトへ連携）に示すように、ＷＷＷブラウザソフト１０４は、ＡＣＤサーバから与えられたＵＲＩのアドレススキームにしたがって、Ｐ２Ｐ電話ソフト１０３に上記ＵＲＩを渡す。そして、図１３（オペレータへ発信）に示すように、Ｐ２Ｐ電話ソフト１０３は、与えられたＵＲＩに基づいて指定されたオペレータＩＤ（「ｏｐｅｒａｔｏｒ３」）へ発信する。図１４は、発信ＰＣの画面イメージを示している。図１４のＰＣ画面６００において、Ｐ２Ｐ電話ソフト１０３の表示画面６０２がＷＷＷブラウザソフト１０４の表示画面６０１よりも前面に表示され、ｏｐｅｒａｔｏｒ３へ発信中であることを、発信ユーザ１０１へ通知する。
【００５２】
その後、ステップＳ２０９において、オペレータソフト１０７から発信ユーザ１０１のユーザＩＤ（「ｕｓｅｒ０」）とオペレータ１０５のユーザＩＤ（「ｏｐｅｒａｔｏｒ３」）を受信したか否かを判断する（ステップＳ２０９）。ここで、受信するのを待って、受信した場合（ステップＳ２０９：Ｙｅｓ）は、オペレータＤＢ１１２のプレゼンス情報、稼働率などを更新する（ステップＳ２１０）とともに、当該オペレータソフト１０７へ所定情報を送信し（ステップＳ２１１）、ステップＳ２０１へ戻る。
【００５３】
具体的には、図１５（情報取得）に示すように、オペレータソフト１０６は、架電を受けた発信ユーザ１０１のユーザＩＤとオペレータ１０５のユーザＩＤをＡＣＤサーバに渡す。ＡＣＤサーバはオペレータＤＢ１１２のプレゼンス情報、稼働率などを更新する。そして、ＡＣＤサーバは所定情報として、たとえば以下の情報をオペレータソフト１０７に送信する。
【００５４】
（１）図５においてＷＷＷブラウザソフト１０４がＡＣＤサーバにアクセスしたときのＵＲＩ。
（２）図５においてＷＷＷブラウザソフト１０４からＡＣＤサーバに渡した情報。
（３）顧客ＤＢ１１１の情報。
（４）待ちユーザリスト１１３の情報（たとえば待ち時間など）。
【００５５】
そして、オペレータ１０５はかかってきた電話をとり、発信ユーザ１０１と通話を開始する。チャットによる対応の場合は、オペレータ１０５は、所定の操作の後、備え付けられたキーボードなどを用いてユーザとチャットを開始する。
【００５６】
このように、ユーザごとに一意に定められたユーザＩＤを使用してネットワーク１００に対してログインされた端末装置どうし（発信ＰＣ１０２とオペレータＰＣ１０６）で、通信をおこなう際に、あらかじめ定められた端末装置群の各オペレータＰＣ１０６が、各自のユーザＩＤでネットワーク１００に対してログインするとともに、オペレータＰＣ１０６に接続されるＡＣＤサーバに対して、少なくとも接続可否状況に関する情報（たとえばプレゼンス情報）を送信し、ＡＣＤサーバが、発信ＰＣ１０２からの発信要求に対して、接続可否状況に関する情報に基づいて、端末装置群のうちのいずれか一つの端末装置（たとえばオペレータＰＣ１０６ｃ）を決定し、決定されたオペレータＰＣのユーザＩＤ（「ｏｐｅｒｅｔｏｒ３」）に対して自動発信するように、発信ＰＣ１０２に指示することによって、ユーザごとに一意に定められたユーザＩＤを使用してネットワーク１００に対してログインされた端末装置どうしで、通信をおこなう場合に、複数の端末装置からなる端末装置群に対して、ＡＣＤサーバを用いて確実かつ効率的に各端末装置へ着信を振り分けることができ、これによって、ＡＣＤ機能を実現することができる。
【００５７】
また、図８〜図１０に示したように、ＡＣＤサーバが、発信ＰＣ１０２からの発信要求に対して、接続可能なオペレータＰＣが存在しなかった場合は、発信ＰＣ１０２にその旨を伝えるとともに、顧客情報を登録し、接続可能なオペレータＰＣが存在するようになった際に、発信ＰＣ１０２のうちの顧客情報に基づいて選択された発信ＰＣ１０２へ、当該オペレータＰＣのユーザＩＤに対して自動発信するように指示することによって、接続待ちの顧客の管理を効率的かつ確実におこなうことができる。
【００５８】
また、発信要求に、発信ユーザに関する情報を含めることができ、ＡＣＤサーバが、あらかじめ登録されたオペレータ情報および発信ユーザに関する情報に基づいて、端末装置群のうちのいずれか一つのオペレータＰＣを決定することによって、所望のオペレータ１０５へ接続でき、これによって、顧客のニーズにあった電話対応を実現することができる。
【００５９】
（リクエスト情報とコール情報との関連付け（その１））
図１７は、リクエスト情報とコール情報との関連付けの処理フローを示す説明図である。また、図１８は、図１７の処理フローの内容を示すシーケンス図である。図１７において、顧客端末１７０１と、ＡＣＤサーバ１７０２と、エージェント端末１７０３がネットワーク１７００を介して接続可能な状態に設定されている。
【００６０】
発信ＰＣである顧客端末１７０１の（ＷＷＷ）ブラウザ１７１１から、ＡＣＤサーバ１７０２（具体的にはＣＴＩ（Ｃｏｍｐｕｔｅｒ Ｔｅｌｅｐｈｏｎｙ Ｉｎｔｅｇｒａｔｉｏｎ）ミドル（ソフトウエア）１７２１）へリクエストをおこなう（ステップＳ１８０１）。ここで、ＣＴＩミドル１７２１は、ＡＣＤサーバ１７０２全体の制御および各エージェント端末１７０３の状態管理をおこなう。またリクエストとは、たとえば顧客がホームページ上のボタンをクリックしてＡＣＤによるエージェントの割り当てを要求することである（図６を参照）。
【００６１】
つぎに、ＡＣＤサーバ１７０２（具体的にはＣＴＩミドル１７２１）は、コール先エージェントを決定する。そして、ＡＣＤサーバ１７０２は、ＤＢ１７２２に対して、顧客端末１７０１からのリクエスト情報と共にコール先エージェント（端末）１７０３のＰ２ＰＩＤをセットする（ステップＳ１８０２）。図１９は、リクエスト情報のテーブルの一例を示す説明図である。その後、ＡＣＤサーバ１７０２は、決定したコール先エージェントのＰ２ＰＩＤを、顧客端末１７０１のブラウザ１７１１あてに通知する（ステップＳ１８０３）。
【００６２】
ブラウザ１７１１は、Ｐ２Ｐ１７１２に対してコール先エージェント１７０３のＰ２ＰＩＤを渡し（ステップＳ１８０４）、Ｐ２Ｐ１７１２は、そのＰ２ＰＩＤのエージェント端末１７０３（のＰ２Ｐ１７３２）へコールを実行する（ステップＳ１８０５）。コールとは、顧客端末１７０１のＰ２Ｐ１７１２から、ＡＣＤサーバ１７０２によって割り当てられたエージェント端末１７０３のＰ２Ｐ１７３２へ発信することである。
【００６３】
エージェント端末１７０３のＰ２Ｐ１７３２は、顧客端末１７０１（のＰ２Ｐ１７１２）からのコールを受信すると、Ｐ２Ｐ制御ソフト１７３１に対して、その旨を知らせる（ステップＳ１８０６）。Ｐ２Ｐ制御ソフト１７３１は、ＡＣＤサーバ１７０３に対して、顧客端末１７０１からのコールがあった旨を含むコール情報と、エージェント端末１７０３のＰ２ＰＩＤを通知する（ステップＳ１８０７）。
【００６４】
ＣＴＩミドル１７２１は、ＤＢ１７２２にセットしたリクエスト情報テーブルから、コール先が該当するＰ２ＰＩＤで最新のレコードを特定する（ステップＳ１８０８）。具体的には、たとえば、コール先が該当するＰ２ＰＩＤにて、図１９に示したリクエスト情報テーブルの「コール先エージェントのＰ２ＰＩＤ」カラムを検索する。そして、「リクエスト日時」カラムが最新のレコードを、対応するリクエストとして特定する。
【００６５】
これによって、ステップＳ１８０１において受けた、顧客端末１７０１のブラウザ１７１１からのリクエストと、ステップＳ１８０５においてエージェント端末１７０３が受けたコールとの関連付けを実行する。このようにして関連付けをすることによって、コールを受けた際に対応するリクエスト情報（操作していたＷＥＢ画面の情報やＨＴＴＰリクエストに含まれる端末情報など）をＡＣＤサーバ１７０２からエージェント端末１７０３へ送信し、図示を省略する表示画面に表示することができる。
【００６６】
（リクエスト情報とコール情報との関連付け（その２））
図２０は、リクエスト情報とコール情報との関連付けの別の処理フローを示す説明図である。また、図２１は、図２０の処理フローの内容を示すシーケンス図である。図２０においては、図１７と同様に、顧客端末１７０１と、ＡＣＤサーバ１７０２と、エージェント端末１７０３がネットワーク１７００を介して接続可能な状態に設定されている。上記リクエスト情報とコール情報との関連付け「（その１）」との違いは、上記「（その１）」がコール先のエージェント端末１７０３のＰ２ＰＩＤを利用するのに対して、「（その２）」は、ＡＣＤサーバ１７０２において、各リクエストに対してリクエストＩＤを採番し、顧客端末１７０１に通知する。顧客端末１７０１は、通知されたリクエストＩＤをコールに添付する点にある。
【００６７】
まず、顧客端末１７０１のブラウザ１７１１から、ＡＣＤサーバ１７０２（具体的にはＣＴＩミドル１７２１）へリクエストをおこなう（ステップＳ２１０１）。そして、ＡＣＤサーバ１７０２（具体的にはＣＴＩミドル１７２１）は、上記「（その１）」と同様に、コール先エージェントを決定する。つぎに、ＡＣＤサーバ１７０２は、ＤＢ１７２２に対して、コール先エージェント（端末）１７０３のＰ２ＰＩＤの代わりに、顧客端末１７０１からのリクエストに対してリクエストＩＤを採番し、リクエスト情報と共にセットする（ステップＳ２１０２）。
【００６８】
図２２は、リクエスト情報テーブルの一例を示す説明図である。図２２において、たとえば「リクエスト管理番号」が上記リクエストＩＤに該当する。したがって、リクエスト情報テーブル「リクエスト管理番号」カラムを通知することになる。リクエスト管理番号は、たとえば、単純な連番を採用すればよい。リクエスト管理番号は、リクエスト日時、決定されたコール先エージェントのＰ２ＰＩＤなどと関連付けされる。その後、ＡＣＤサーバ１７０２は、決定したコール先エージェントのＰ２ＰＩＤおよび採番されたリクエストＩＤを、顧客端末１７０１のブラウザ１７１１あてに通知する（ステップＳ２１０３）。
【００６９】
ブラウザ１７１１は、Ｐ２Ｐ１７１２に対してコール先エージェント１７０３のＰ２ＰＩＤおよびリクエストＩＤを渡し（ステップＳ２１０４）、Ｐ２Ｐ１７１２は、そのＰ２ＰＩＤのエージェント端末１７０３（のＰ２Ｐ１７３２）へコールを実行する（ステップＳ２１０５）。コールを実行する際も、リクエストＩＤを添付しておこなう。
【００７０】
エージェント端末１７０３のＰ２Ｐ１７３２は、顧客端末１７０１（のＰ２Ｐ１７１２）からのコールを受信すると、Ｐ２Ｐ制御ソフト１７３１に対して、その旨を知らせる（ステップＳ２１０６）。Ｐ２Ｐ制御ソフト１７３１は、ＡＣＤサーバ１７０３に対して、顧客端末１７０１からのコールがあった旨を含むコール情報およびリクエストＩＤを通知する（ステップＳ２１０７）。
【００７１】
ＣＴＩミドル１７２１は、ＤＢ１７２２にセットしたリクエスト情報テーブルから、リクエストＩＤを用いてコールを特定する（ステップＳ２１０８）。具体的には、たとえばエージェント端末１７０３で取得したリクエスト管理番号にてリクエスト情報テーブル「リクエスト管理番号」カラムを検索する（必ず１件しか該当しないことになる）。
【００７２】
これによって、ステップＳ２１０１において受けた、顧客端末１７０１のブラウザ１７１１からのリクエストと、ステップＳ２１０５においてエージェント端末１７０３が受けたコールとの関連付けを実行する。このようにして関連付けをすることによって、上記「（その１）」と同様に、コールを受けた際に対応するリクエスト情報（操作していたＷＥＢ画面の情報やＨＴＴＰリクエストに含まれる端末情報など）をＡＣＤサーバ１７０２からエージェント端末１７０３へ送信し、図示を省略する表示画面に表示することができる。
【００７３】
（リクエスト情報とコール情報との関連付け（その３））
図２３は、リクエスト情報とコール情報との関連付けのさらに別の処理フローを示す説明図である。また、図２４は、図２３の処理フローの内容を示すシーケンス図である。図２３においては、図１７、図２０と同様に、顧客端末１７０１と、ＡＣＤサーバ１７０２と、エージェント端末１７０３がネットワーク１７００を介して接続可能な状態に設定されている。上記リクエスト情報とコール情報との関連付け「（その１）」との違いは、上記「（その１）」がコール先のエージェント端末１７０３のＰ２ＰＩＤを利用するのに対し、「（その３）」では、顧客端末１７０１のＰ２ＰＩＤを利用する点にある。
【００７４】
まず、顧客端末１７０１のブラウザ１７１１にて顧客端末１７０１のＰ２ＰＩＤの入力を受け付け、ＡＣＤサーバ１７０２（具体的にはＣＴＩミドル１７２１）へリクエストをおこなう（ステップＳ２４０１）。図２５は、図６と同様に、顧客端末１７０１の画面イメージを示している。図２５のＰＣ画面６００において、２５０１はブラウザ（ソフト）１７１１の表示画面（ウインドウ）例である。表示画面２５０１では、Ｐ２ＰＩＤ入力欄２５０２と、クリックボタン「Ｃａｌｌ Ｍｅ！」２５０３を備え、Ｐ２ＰＩＤ入力欄２５０２に顧客のＰ２ＰＩＤを入力して、クリックボタン２５０３をクリックすることによって、特定のＵＲＩを指定し、ＡＣＤサーバ１７０２にリクエストを送信することができる。
【００７５】
リクエストの際には、入力を受け付けられた顧客端末１７０１のＰ２ＰＩＤもあわせてＡＣＤサーバ１７０２へ通知する。そして、ＡＣＤサーバ１７０２（具体的にはＣＴＩミドル１７２１）は、上記「（その１）」、「（その２）」と同様に、コール先エージェントを決定する。そして、ＡＣＤサーバ１７０２は、ＤＢ１７２２に対して、顧客端末１７０１のＰ２ＰＩＤをリクエスト情報と共にセットする（ステップＳ２４０２）。
【００７６】
図２６は、リクエスト情報テーブルの一例を示す説明図である。図２６において、顧客端末１７０１のＰ２ＰＩＤは、たとえば「顧客Ｐ２ＰＩＤ」カラムにセットし、「顧客Ｐ２ＰＩＤ」として関連付けがされる。その後、ＡＣＤサーバ１７０２は、決定したコール先エージェントのＰ２ＰＩＤを、顧客端末１７０１のブラウザ１７１１あてに通知する（ステップＳ２４０３）。
【００７７】
ブラウザ１７１１は、Ｐ２Ｐ１７１２に対してコール先エージェント１７０３のＰ２ＰＩＤを渡し（ステップＳ２４０４）、Ｐ２Ｐ１７１２は、そのＰ２ＰＩＤのエージェント端末１７０３（のＰ２Ｐ１７３２）へコールを実行する（ステップＳ２４０５）。コールを実行する際に、顧客端末１７０１のＰ２ＰＩＤを添付しておこなう。
【００７８】
エージェント端末１７０３のＰ２Ｐ１７３２は、顧客端末１７０１（のＰ２Ｐ１７１２）からのコールを受信すると、Ｐ２Ｐ制御ソフト１７３１に対して、その旨を知らせる（ステップＳ２４０６）。Ｐ２Ｐ制御ソフト１７３１は、ＡＣＤサーバ１７０２のＣＴＩミドル１７２１に対して、顧客端末１７０１からのコールがあった旨を含むコール情報およびコール元の顧客端末１７０１のＰ２ＰＩＤを通知する（ステップＳ２４０７）。
【００７９】
ＣＴＩミドル１７２１は、ＤＢ１７２２にセットしたリクエスト情報テーブルから、顧客端末１７０１のＰ２ＰＩＤを用いてコールを特定する（ステップＳ２４０８）。取得したコール元の顧客Ｐ２ＰＩＤにてリクエスト情報テーブル「顧客Ｐ２ＰＩＤ」カラムを検索する。複数ヒットした場合は、「リクエスト日時」カラムが最新のレコードを、対応するリクエストとして特定する。
【００８０】
これによって、ステップＳ２４０１において受けた、顧客端末１７０１のブラウザ１７１１からのリクエストと、ステップＳ２４０５においてエージェント端末１７０３が受けたコールとの関連付けを実行する。このようにして関連付けをすることによって、上記「（その１）」、「（その２）」と同様に、コールを受けた際に対応するリクエスト情報（操作していたＷＥＢ画面の情報やＨＴＴＰリクエストに含まれる端末情報など）をＡＣＤサーバ１７０２からエージェント端末１７０３へ送信し、図示を省略する表示画面に表示することができる。
【００８１】
図２７および図２８は、図２５とは別の顧客端末１７０１の画面イメージを示している。図２７において、表示画面２７０１には、会員登録ページが表示されており、顧客はこの会員登録ページから会員番号、氏名、電話番号、Ｅメールアドレスのほか、Ｐ２ＰＩＤを入力し、「登録」ボタン２７０２を押下する。これによって、リクエストが実行されることになる。また、図２８に示すように、図２７において会員登録がなされたことを前提に、顧客のＰ２ＰＩＤの入力欄を設ける代わりに、会員番号を会員に入力させる会員番号入力欄２８０１を備えるようにしてもよい。
【００８２】
以上説明したように、上記方法（「（その１）」〜「（その３）」）によって、リクエスト情報とコール情報を関連付け（紐付け）することができ、エージェント端末１７０３においては、コールがあった場合に、そのコールに紐付けされたリクエスト情報を容易にＡＣＤサーバ１７０２から取得して、表示画面に表示することができる。
【００８３】
また、スカイプによって実現するチャット機能を用いてＡＣＤを実現することも可能である。この場合に、図６のＷＷＷブラウザソフト１０４の表示画面（ウインドウ）例において、「お問合せはこちらをクリック」という表示と「Ｃａｌｌ Ｍｅ！」部分（ボタン）に代えて、あるいは「お問合せはこちらをクリック」という表示と「Ｃａｌｌ Ｍｅ！」部分（ボタン）に加えて、図示は省略するが、「チャットの場合はこちらをクリック」という表示と「Ｃｈａｔ！」部分（ボタン）を設けるとよい。これによって、ユーザがチャットでの問合せを希望している場合は、リダイレクト先のＵＲＩは、Ｐ２Ｐ電話のチャット用ソフトとするとよい。さらに、通話とチャットの両方を用いる場合には、「Ｃａｌｌ Ｍｅ！」部分（ボタン）および「Ｃｈａｔ！」部分（ボタン）の両方をクリックする。これによって、通話とチャットの両方を同時に実現することも可能となる。
【００８４】
（マルチリンガルコールセンターの概要）
つぎに、上記実施の形態を利用したマルチリンガルコールセンターの概要について説明する。あらかじめ、発信ユーザ１０１は、ＷＷＷブラウザソフト１０４に自分が話せる言語を設定しておくと、ＷＷＷサーバソフト１０９は指定された言語で記述されたＨＴＭＬファイルを返すようにする機能がある。この機能はＣｏｎｔｅｎｔ Ｎｅｇｏｔｉａｔｉｏｎと呼ばれている。言語は複数設定することができ、それぞれの優先順位も指定することができる。この機能に対して上記実施の形態を利用することにより、ＷＷＷブラウザから指定された言語が話せるオペレータのユーザＩＤを返すことで、複数の言語に対応したコールセンターを構築することができる。
【００８５】
図２９は、オペレータＤＢ１１２の内容の一例を示す説明図である。図２９において、ユーザＩＤに対応して当該オペレータが使用可能な言語に関する情報が格納されている。図２９の内容から、「ｏｐｅｒａｔｏｒ１は英語と日本語が話せる。」、「ｏｐｅｒａｔｏｒ２は日本語のみ話せる。」、「ｏｐｅｒａｔｏｒ３は英語とフランス語が話せる。」ということがわかる。
【００８６】
また、以下のような内容の情報がＷＷＷブラウザソフト１０４から送られてくる。
【００８７】
Ａｃｃｅｐｔ−Ｌａｎｇｕａｇｅ： ｆｒ； ｑ＝１．０， ｅｎ； ｑ＝０．５（フランス語と英語であればＯＫだが、フランス語の方がよい）
【００８８】
上記数値は、使用可否および優先度を示している。すなわち、数値が設定されているものが使用可能であり、また、数値が高い方が優先度が高いことを示している。具体的には、上記の例では、１．０のフランス語の方が０．５の英語よりも優先度が高いことがわかる。
【００８９】
送られてきた上記の内容と、図２９の内容を比較すると、当該発信ユーザに対しては、ｏｐｅｒｅｔｏｒ２は、空いていても接続しない。ｏｐｅｒｅｔｏｒ１とｏｐｅｒｅｔｏｒ３がいずれも空いている場合は、ｏｐｅｒｅｔｏｒ３へ接続する。ということを判断することができる。
【００９０】
このように、接続先情報およびオペレータ情報に対応可能な言語に関する情報を含めることによって、ＷＷＷサーバによるＡＣＤを応用して、複数の言語に対応したコールセンターを構築することができる。
【００９１】
なお、本実施の形態で説明した通信方法は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーション等のコンピュータで実行することにより実現することができる。このプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。またこのプログラムは、インターネット等のネットワークを介して配布することが可能な伝送媒体であってもよい。
【産業上の利用可能性】
【００９２】
以上のように、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしでおこなう通信に用いるのに適している。
【図面の簡単な説明】
【００９３】
【図１】この発明の実施の形態にかかる通信方法を実現するためのシステムの概要を示す説明図である。
【図２】この発明の実施の形態にかかる通信方法におけるＷＷＷサーバの処理の手順を示すフローチャートである。
【図３】この発明の実施の形態にかかる通信方法の処理フローを示す説明図である。
【図４】この発明の実施の形態にかかる通信方法の処理フローを示す説明図である。
【図５】この発明の実施の形態にかかる通信方法の処理フローを示す説明図である。
【図６】発信ＰＣの画面イメージの一例を示す説明図である。
【図７】この発明の実施の形態にかかる通信方法の処理フローを示す説明図である。
【図８】この発明の実施の形態にかかる通信方法の処理フローを示す説明図である。
【図９】この発明の実施の形態にかかる通信方法の処理フローを示す説明図である。
【図１０】この発明の実施の形態にかかる通信方法の処理フローを示す説明図である。
【図１１】この発明の実施の形態にかかる通信方法の処理フローを示す説明図である。
【図１２】この発明の実施の形態にかかる通信方法の処理フローを示す説明図である。
【図１３】この発明の実施の形態にかかる通信方法の処理フローを示す説明図である。
【図１４】発信ＰＣの画面イメージの一例を示す説明図である。
【図１５】この発明の実施の形態にかかる通信方法の処理フローを示す説明図である。
【図１６】この発明の実施の形態にかかる通信方法の処理フローを示す説明図である。
【図１７】リクエスト情報とコール情報との関連付けの処理フローを示す説明図である。
【図１８】図１７の処理フローの内容を示すシーケンス図である。
【図１９】リクエスト情報テーブルの一例を示す説明図である。
【図２０】リクエスト情報とコール情報との関連付けの別の処理フローを示す説明図である。
【図２１】図２０の処理フローの内容を示すシーケンス図である。
【図２２】リクエスト情報テーブルの一例を示す説明図である。
【図２３】リクエスト情報とコール情報との関連付けの別の処理フローを示す説明図である。
【図２４】図２３の処理フローの内容を示すシーケンス図である。
【図２５】顧客端末の画面イメージの一例を示す説明図である。
【図２６】リクエスト情報テーブルの一例を示す説明図である。
【図２７】顧客端末の画面イメージの別の一例を示す説明図である。
【図２８】顧客端末の画面イメージの別の一例を示す説明図である。
【図２９】オペレータＤＢの内容の一例を示す説明図である。
【符号の説明】
【００９４】
１００，１７００ ネットワーク
１０１ 発信ユーザ
１０２ 発信ＰＣ（パーソナルコンピュータ）
１０３ Ｐ２Ｐ電話ソフト（ウエア）
１０４ ＷＷＷブラウザソフト（ウエア）
１０５（１０５ａ、１０５ｂ、１０５ｃ） オペレータ
１０６（１０６ａ、１０６ｂ、１０６ｃ） オペレータＰＣ（パーソナルコンピュータ）
１０７（１０７ａ、１０７ｂ、１０７ｃ） オペレータソフト（ウエア）
１０８ ＡＣＤサーバマシン
１０９ ＷＷＷサーバソフト（ウエア）
１１０ ＡＣＤソフト（ウエア）
１１１ 顧客データベース（ＤＢ）
１１２ オペレータデータベース（ＤＢ）
１１３ 待ちユーザリスト
【特許請求の範囲】
【請求項１】
ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、通信をおこなう通信方法において、
あらかじめ定められた端末装置群の各端末装置が、各自のユーザＩＤで前記ネットワークに対してログインするとともに、前記端末装置に接続されるサーバに対して、少なくとも接続可否状況に関する情報を送信し、
前記サーバが、発信元端末装置からの発信要求に対して、前記接続可否状況に関する情報に基づいて、前記端末装置群のうちのいずれか一つの端末装置を決定し、決定された端末装置のユーザＩＤに対して自動発信するように、前記発信元端末装置に指示することを特徴とする通信方法。
【請求項２】
前記通信は、音声通信であることを特徴とする請求項１に記載の通信方法。
【請求項３】
前記通信は、文字通信であることを特徴とする請求項１に記載の通信方法。
【請求項４】
前記サーバは、前記発信元端末装置からの発信要求に関する情報を、決定された端末装置のユーザＩＤを関連付けして記憶し、
前記発信元端末装置は、前記サーバからの指示に基づいて、決定された端末装置のユーザＩＤに対して自動発信することを特徴とする請求項１〜３のいずれか一つに記載の通信方法。
【請求項５】
前記決定された端末装置は、前記発信元端末装置からの発信があった場合に、前記発信要求に関する情報を自らのユーザＩＤに基づいて前記サーバに対して検索要求することを特徴とする請求項４に記載の通信方法。
【請求項６】
前記サーバは、前記発信元端末装置からの発信要求に関する情報に対して、一意の管理ＩＤを関連付けして記憶するとともに、当該管理ＩＤを前記発信元端末装置へ送信し、
前記発信元端末装置は、前記サーバからの指示に基づいて、決定された端末装置のユーザＩＤに対して自動発信する際に、前記サーバから受信した前記管理ＩＤを送信することを特徴とする請求項１〜３のいずれか一つに記載の通信方法。
【請求項７】
前記決定された端末装置は、前記発信元端末装置からの発信があった場合に、前記発信要求に関する情報を前記管理ＩＤに基づいて前記サーバに対して検索要求することを特徴とする請求項６に記載の通信方法。
【請求項８】
前記サーバは、前記発信元端末装置からの発信要求に関する情報に対して、前記発信元端末装置のユーザＩＤを関連付けして記憶し、
前記発信元端末装置は、前記サーバからの指示に基づいて、決定された端末装置のユーザＩＤに対して自動発信する際に、自らのユーザＩＤを送信することを特徴とする請求項１〜３のいずれか一つに記載の通信方法。
【請求項９】
前記決定された端末装置は、前記発信元端末装置からの発信があった場合に、前記発信要求に関する情報を前記発信元端末装置のユーザＩＤに基づいて前記サーバに対して検索要求することを特徴とする請求項８に記載の通信方法。
【請求項１０】
前記サーバは、前記発信元端末装置からの発信要求とともに、前記発信元端末装置から送信されてきた所定のＩＤを受信し、前記発信元端末装置からの発信要求に関する情報に対して、前記所定のＩＤを関連付けして記憶し、
前記発信元端末装置は、前記サーバからの指示に基づいて、決定された端末装置のユーザＩＤに対して自動発信する際に、前記所定のＩＤを送信することを特徴とする請求項１〜３のいずれか一つに記載の通信方法。
【請求項１１】
前記決定された端末装置は、前記発信元端末装置からの発信があった場合に、前記発信要求に関する情報を前記所定のＩＤに基づいて前記サーバに対して検索要求することを特徴とする請求項１０に記載の通信方法。
【請求項１２】
前記請求項１〜１１のいずれか一つに記載の通信方法を前記端末装置に実行させることを特徴とする通信プログラム。
【請求項１】
ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、通信をおこなう通信方法において、
あらかじめ定められた端末装置群の各端末装置が、各自のユーザＩＤで前記ネットワークに対してログインするとともに、前記端末装置に接続されるサーバに対して、少なくとも接続可否状況に関する情報を送信し、
前記サーバが、発信元端末装置からの発信要求に対して、前記接続可否状況に関する情報に基づいて、前記端末装置群のうちのいずれか一つの端末装置を決定し、決定された端末装置のユーザＩＤに対して自動発信するように、前記発信元端末装置に指示することを特徴とする通信方法。
【請求項２】
前記通信は、音声通信であることを特徴とする請求項１に記載の通信方法。
【請求項３】
前記通信は、文字通信であることを特徴とする請求項１に記載の通信方法。
【請求項４】
前記サーバは、前記発信元端末装置からの発信要求に関する情報を、決定された端末装置のユーザＩＤを関連付けして記憶し、
前記発信元端末装置は、前記サーバからの指示に基づいて、決定された端末装置のユーザＩＤに対して自動発信することを特徴とする請求項１〜３のいずれか一つに記載の通信方法。
【請求項５】
前記決定された端末装置は、前記発信元端末装置からの発信があった場合に、前記発信要求に関する情報を自らのユーザＩＤに基づいて前記サーバに対して検索要求することを特徴とする請求項４に記載の通信方法。
【請求項６】
前記サーバは、前記発信元端末装置からの発信要求に関する情報に対して、一意の管理ＩＤを関連付けして記憶するとともに、当該管理ＩＤを前記発信元端末装置へ送信し、
前記発信元端末装置は、前記サーバからの指示に基づいて、決定された端末装置のユーザＩＤに対して自動発信する際に、前記サーバから受信した前記管理ＩＤを送信することを特徴とする請求項１〜３のいずれか一つに記載の通信方法。
【請求項７】
前記決定された端末装置は、前記発信元端末装置からの発信があった場合に、前記発信要求に関する情報を前記管理ＩＤに基づいて前記サーバに対して検索要求することを特徴とする請求項６に記載の通信方法。
【請求項８】
前記サーバは、前記発信元端末装置からの発信要求に関する情報に対して、前記発信元端末装置のユーザＩＤを関連付けして記憶し、
前記発信元端末装置は、前記サーバからの指示に基づいて、決定された端末装置のユーザＩＤに対して自動発信する際に、自らのユーザＩＤを送信することを特徴とする請求項１〜３のいずれか一つに記載の通信方法。
【請求項９】
前記決定された端末装置は、前記発信元端末装置からの発信があった場合に、前記発信要求に関する情報を前記発信元端末装置のユーザＩＤに基づいて前記サーバに対して検索要求することを特徴とする請求項８に記載の通信方法。
【請求項１０】
前記サーバは、前記発信元端末装置からの発信要求とともに、前記発信元端末装置から送信されてきた所定のＩＤを受信し、前記発信元端末装置からの発信要求に関する情報に対して、前記所定のＩＤを関連付けして記憶し、
前記発信元端末装置は、前記サーバからの指示に基づいて、決定された端末装置のユーザＩＤに対して自動発信する際に、前記所定のＩＤを送信することを特徴とする請求項１〜３のいずれか一つに記載の通信方法。
【請求項１１】
前記決定された端末装置は、前記発信元端末装置からの発信があった場合に、前記発信要求に関する情報を前記所定のＩＤに基づいて前記サーバに対して検索要求することを特徴とする請求項１０に記載の通信方法。
【請求項１２】
前記請求項１〜１１のいずれか一つに記載の通信方法を前記端末装置に実行させることを特徴とする通信プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【公開番号】特開２００７−３１１８５３（Ｐ２００７−３１１８５３Ａ）
【公開日】平成１９年１１月２９日（２００７．１１．２９）
【国際特許分類】
【出願番号】特願２００６−１３６０９４（Ｐ２００６−１３６０９４）
【出願日】平成１８年５月１６日（２００６．５．１６）
【出願人】（３０２０６４７６２）株式会社日本総合研究所 (367)
【Ｆターム（参考）】
【公開日】平成１９年１１月２９日（２００７．１１．２９）
【国際特許分類】
【出願日】平成１８年５月１６日（２００６．５．１６）
【出願人】（３０２０６４７６２）株式会社日本総合研究所 (367)
【Ｆターム（参考）】
[ Back to top ]