(57)【要約】【課題】この発明は、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしでおこなう音声通信、いわゆるＰ２Ｐ電話において、ＡＣＤを実現すること。【解決手段】あらかじめ定められた端末装置群（オペレータＰＣ１０５）が、各自のユーザＩＤでネットワーク１００に対してログインするとともに、端末装置群のうちのいずれかの端末装置が、ユーザＩＤとは別の、上記端末装置群を代表する代表ユーザＩＤで、ネットワーク１００に対してログインし、発信ＰＣ１０２からの代表ユーザＩＤへの発信によって、発信ＰＣ１０２と、代表ユーザＩＤでログインされたオペレータＰＣ１０５ａとが接続された場合に、オペレータＰＣ１０５ａが、他のオペレータＰＣのいずれか（オペレータＰＣ１０５ｂ）に対して、代表ユーザＩＤでログインするように指示する。【選択図】        図１
2006325172.tif 000002
【特許請求の範囲】
【請求項１】
ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなう音声通信方法において、
あらかじめ定められた端末装置群が、各自のユーザＩＤで前記ネットワークに対してログインするとともに、
前記端末装置群のうちのいずれかの端末装置が、前記ユーザＩＤとは別の、前記端末装置群を代表するユーザＩＤ（以下「代表ユーザＩＤ」という）で、前記ネットワークに対してログインし、
発信元端末装置からの前記代表ユーザＩＤへの発信によって、前記発信元端末装置と、前記代表ユーザＩＤでログインされた端末装置（以下「着信端末装置」という）とが接続された場合に、
前記着信端末装置が、前記端末装置群のうちの他の端末装置のいずれかに対して、前記代表ユーザＩＤでログインするように指示することを特徴とする音声通信方法。
【請求項２】
ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなう音声通信方法において、
あらかじめ定められた端末装置群のうちのいずれかの端末装置が、前記ユーザＩＤとは別の、前記端末装置群を代表するユーザＩＤ（以下「代表ユーザＩＤ」という）で、前記ネットワークに対してログインし、
発信元端末装置からの前記代表ユーザＩＤへの発信によって、前記発信元端末装置と、前記代表ユーザＩＤでログインされた端末装置（以下「着信端末装置」という）とが接続された場合に、
前記着信端末装置が、前記端末装置群のうちの他の端末装置のいずれかに対して、前記代表ユーザＩＤでログインするように指示することを特徴とする音声通信方法。
【請求項３】
ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなう音声通信方法において、
あらかじめ定められた端末装置群の各端末装置が、前記ユーザＩＤとは別の、前記端末装置群を代表するユーザＩＤ（以下「代表ユーザＩＤ」という）で、前記ネットワークに対してそれぞれにログインし、
発信元端末装置からの前記代表ユーザＩＤへの発信によって、前記発信元端末装置と、前記代表ユーザＩＤでログインされた各端末装置とが接続された後、
前記各端末装置のうちのいずれか一つの端末装置を残して、他の端末装置と前記発信元端末装置との接続を切断することを特徴とする音声通信方法。
【請求項４】
ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなう音声通信方法において、
あらかじめ定められた端末装置群のうちのいずれかの端末装置が、前記ユーザＩＤとは別の、前記端末装置群を代表するユーザＩＤ（以下「代表ユーザＩＤ」という）で、前記ネットワークに対してログインするとともに、前記端末装置群のうちの他の端末装置が、前記ユーザＩＤでログインし、
発信元端末装置からの前記代表ユーザＩＤへの発信によって、前記発信元端末装置と、前記代表ユーザＩＤでログインされた端末装置（以下「着信端末装置」という）とが接続された場合に、
前記着信端末装置が、前記発信元端末装置に対して、前記他の端末装置のいずれかへ発信するように指示し、前記発信元端末装置との接続を切断することを特徴とする音声通信方法。
【請求項５】
前記着信端末装置は、前記発信元端末装置へ、前記他の端末装置のうちの前記発信元端
末装置と接続させるべき端末装置のユーザＩＤを送信することを特徴とする請求項４に記載の音声通信方法。
【請求項６】
ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなう音声通信方法において、
あらかじめ定められた端末装置群のうちのいずれかの端末装置が、前記ユーザＩＤとは別の、前記端末装置群を代表するユーザＩＤ（以下「代表ユーザＩＤ」という）で、前記ネットワークに対してログインするとともに、前記端末装置群のうちの他の端末装置が、各自の前記ユーザＩＤでログインし、
発信元端末装置からの前記代表ユーザＩＤへの発信によって、前記発信元端末装置と、前記代表ユーザＩＤでログインされた端末装置（以下「着信端末装置」という）とが接続された場合に、
前記着信端末装置が、前記他の端末装置のいずれかに対して、前記発信元端末装置へ発信するように指示することを特徴とする音声通信方法。
【請求項７】
前記着信端末装置は、前記他の端末装置のうちの前記発信元端末装置と接続させるべき端末装置（以下「接続先端末装置」という）へ、前記発信元端末装置のユーザＩＤおよび接続中の発信ＩＤを送信することを特徴とする請求項６に記載の音声通信方法。
【請求項８】
前記発信元端末装置は、前記接続先端末装置からの前記発信ＩＤを含む発信があった場合に、前記発信を許可するとともに、前記着信端末装置との接続を切断することを特徴とする請求項７に記載の音声通信方法。
【請求項９】
前記請求項１〜４および６に記載の音声通信方法のうちの少なくともいずれか２つの方法を含むことを特徴とする音声通信方法。
【請求項１０】
ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなう音声通信方法において、
あらかじめ定められた端末装置群の各端末装置が、前記ユーザＩＤとは別の、前記端末装置群を代表するユーザＩＤ（以下「代表ユーザＩＤ」という）で、前記ネットワークに対してそれぞれにログインし、
前記端末装置群のうちのいずれかの端末装置（以下「受電可能端末装置」）のみが受電可能状態とするとともに、前記端末装置群のうちの前記受電可能端末装置以外の他の端末装置が受電不可状態とし、
発信元端末装置からの前記代表ユーザＩＤへの発信によって、前記発信元端末装置と前記受電可能端末装置とが接続された場合に、前記受電可能端末装置が、自装置を受電不可状態にするとともに、前記端末装置群のうちの前記受電可能端末装置以外の他の端末装置のいずれかに対して、受電可能状態とするように指示することを特徴とする音声通信方法。
【請求項１１】
ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなう音声通信方法において、
あらかじめ定められた端末装置群のうちのいずれかの端末装置が、前記ユーザＩＤとは別の、前記端末装置群を代表するユーザＩＤ（以下「代表ユーザＩＤ」という）で、前記ネットワークに対してログインするとともに、前記端末装置群のうちの他の端末装置が、各自の前記ユーザＩＤでログインし、
発信元端末装置からの前記代表ユーザＩＤへの発信によって、前記代表ユーザＩＤでログインされた端末装置（以下「着信端末装置」という）が、前記発信元端末装置からの着信があった際に受電可能である場合は、前記発信元端末装置と接続するとともに、受電可能でない場合は、前記端末装置群のうちのあらかじめ定められた前記他の端末装置へ前記着信を転送し、
前記他の端末装置が、前記着信の転送があった際に受電可能である場合は、前記発信元端末装置と接続するとともに、受電可能でない場合は、前記端末装置群のうちのあらかじめ定められた自装置以外の他の端末装置へ前記着信を転送することを特徴とする音声通信方法。
【請求項１２】
前記着信端末装置および前記他の端末装置の少なくともいずれかは、前記着信を転送した端末装置が当該転送を完了しなかった場合に、前記着信を当該端末装置の次の端末装置へ転送することを特徴とする音声通信方法。
【請求項１３】
前記請求項１〜１２のいずれか一つに記載の音声通信方法を前記端末装置に実行させることを特徴とする音声通信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなう音声通信方法および音声通信プログラムに関する。
【背景技術】
【０００２】
近年、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなういわゆるＰ２Ｐ（Ｐｅｅｒ  ｔｏ  Ｐｅｅｒ）電話が普及している。具体的には、たとえば、スカイプテクノロジー社のスカイプ（Ｓｋｙｐｅ）などがあげられる。
【０００３】
また、電話を用いた業態の一つにコールセンターがあり、コールセンターなどで用いられる機能に、ＡＣＤ（Ａｕｔｏｍａｔｉｃ  Ｃａｌｌ  Ｄｉｓｔｒｉｂｕｔｉｏｎ：着信呼自動分配）がある。これは、代表番号に着信した電話を適宜、手の空いているオペレータに対して振り分ける操作である。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記従来技術にかかるＰ２Ｐ電話は、通常、１対１あるいは１対多数でコミュニケーションするように設計されており、代表番号を用いた、着信を振り分ける機能を備えていないため、Ｐ２Ｐ電話を用いてＡＣＤを実現することができなかった。それゆえに、Ｐ２Ｐ電話をコールセンターで利用することができないという問題点があった。
【０００５】
この発明は、上述した従来技術による問題点を解消するため、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしでおこなう音声通信において、ＡＣＤを実現することが可能な音声通信方法および音声通信プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
上述した課題を解決し、目的を達成するため、この発明にかかる音声通信方法は、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなう音声通信方法において、あらかじめ定められた端末装置群が、各自のユーザＩＤで前記ネットワークに対してログインするとともに、前記端末装置群のうちのいずれかの端末装置が、前記ユーザＩＤとは別の、前記端末装置群を代表するユーザＩＤ（以下「代表ユーザＩＤ」という）で、前記ネットワークに対してログインし、発信元端末装置からの前記代表ユーザＩＤへの発信によって、前記発信元端末装置と、前記代表ユーザＩＤでログインされた端末装置（以下「着信端末装置」という）とが接続された場合に、前記着信端末装置が、前記端末装置群のうちの他の端末装置のいずれかに対して、前記代表ユーザＩＤでログインするように指示することを特徴とする。
【０００７】
また、この発明にかかる音声通信方法は、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなう音声通信方法において、あらかじめ定められた端末装置群のうちのいずれかの端末装置が、前記ユーザＩＤとは別の、前記端末装置群を代表するユーザＩＤ（以下「代表ユーザＩＤ」という）で、前記ネットワークに対してログインし、発信元端末装置からの前記代表ユーザＩＤへの発信によって、前記発信元端末装置と、前記代表ユーザＩＤでログインされた端末装置（以下「着信端末装置」という）とが接続された場合に、前記着信端末装置が
、前記端末装置群のうちの他の端末装置のいずれかに対して、前記代表ユーザＩＤでログインするように指示することを特徴とする。
【０００８】
また、この発明にかかる音声通信方法は、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなう音声通信方法において、あらかじめ定められた端末装置群の各端末装置が、前記ユーザＩＤとは別の、前記端末装置群を代表するユーザＩＤ（以下「代表ユーザＩＤ」という）で、前記ネットワークに対してそれぞれにログインし、発信元端末装置からの前記代表ユーザＩＤへの発信によって、前記発信元端末装置と、前記代表ユーザＩＤでログインされた各端末装置とが接続された後、前記各端末装置のうちのいずれか一つの端末装置を残して、他の端末装置と前記発信元端末装置との接続を切断することを特徴とする。
【０００９】
また、この発明にかかる音声通信方法は、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなう音声通信方法において、あらかじめ定められた端末装置群のうちのいずれかの端末装置が、前記ユーザＩＤとは別の、前記端末装置群を代表するユーザＩＤ（以下「代表ユーザＩＤ」という）で、前記ネットワークに対してログインするとともに、前記端末装置群のうちの他の端末装置が、前記ユーザＩＤでログインし、発信元端末装置からの前記代表ユーザＩＤへの発信によって、前記発信元端末装置と、前記代表ユーザＩＤでログインされた端末装置（以下「着信端末装置」という）とが接続された場合に、前記着信端末装置が、前記発信元端末装置に対して、前記他の端末装置のいずれかへ発信するように指示し、前記発信元端末装置との接続を切断することを特徴とする。
【００１０】
その際、前記着信端末装置は、前記発信元端末装置へ、前記他の端末装置のうちの前記発信元端末装置と接続させるべき端末装置のユーザＩＤを送信することを特徴とする。
【００１１】
また、この発明にかかる音声通信方法は、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなう音声通信方法において、あらかじめ定められた端末装置群のうちのいずれかの端末装置が、前記ユーザＩＤとは別の、前記端末装置群を代表するユーザＩＤ（以下「代表ユーザＩＤ」という）で、前記ネットワークに対してログインするとともに、前記端末装置群のうちの他の端末装置が、各自の前記ユーザＩＤでログインし、発信元端末装置からの前記代表ユーザＩＤへの発信によって、前記発信元端末装置と、前記代表ユーザＩＤでログインされた端末装置（以下「着信端末装置」という）とが接続された場合に、前記着信端末装置が、前記他の端末装置のいずれかに対して、前記発信元端末装置へ発信するように指示することを特徴とする。
【００１２】
その際、前記着信端末装置は、前記他の端末装置のうちの前記発信元端末装置と接続させるべき端末装置（以下「接続先端末装置」という）へ、前記発信元端末装置のユーザＩＤおよび接続中の発信ＩＤを送信することを特徴とする。
【００１３】
またその際、前記発信元端末装置は、前記接続先端末装置からの前記発信ＩＤを含む発信があった場合に、前記発信を許可するとともに、前記着信端末装置との接続を切断することを特徴とする。
【００１４】
また、この発明にかかる音声通信方法は、上記に記載の音声通信方法のうちの少なくともいずれか２つの方法を含むことを特徴とする。
【００１５】
また、この発明にかかる音声通信方法は、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなう音声通信方法において、あらかじめ定められた端末装置群の各端末装置が、前記ユーザＩＤとは別の、前記端末装置群を代表するユーザＩＤ（以下「代表ユーザＩＤ」という）で、前記ネットワークに対してそれぞれにログインし、前記端末装置群のうちのいずれかの端末装置（以下「受電可能端末装置」）のみが受電可能状態とするとともに、前記端末装置群のうちの前記受電可能端末装置以外の他の端末装置が受電不可状態とし、発信元端末装置からの前記代表ユーザＩＤへの発信によって、前記発信元端末装置と前記受電可能端末装置とが接続された場合に、前記受電可能端末装置が、自装置を受電不可状態にするとともに、前記端末装置群のうちの前記受電可能端末装置以外の他の端末装置のいずれかに対して、受電可能状態とするように指示することを特徴とする。
【００１６】
また、この発明にかかる音声通信方法は、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなう音声通信方法において、あらかじめ定められた端末装置群のうちのいずれかの端末装置が、前記ユーザＩＤとは別の、前記端末装置群を代表するユーザＩＤ（以下「代表ユーザＩＤ」という）で、前記ネットワークに対してログインするとともに、前記端末装置群のうちの他の端末装置が、各自の前記ユーザＩＤでログインし、発信元端末装置からの前記代表ユーザＩＤへの発信によって、前記代表ユーザＩＤでログインされた端末装置（以下「着信端末装置」という）が、前記発信元端末装置からの着信があった際に受電可能である場合は、前記発信元端末装置と接続するとともに、受電可能でない場合は、前記端末装置群のうちのあらかじめ定められた前記他の端末装置へ前記着信を転送し、前記他の端末装置が、前記着信の転送があった際に受電可能である場合は、前記発信元端末装置と接続するとともに、受電可能でない場合は、前記端末装置群のうちのあらかじめ定められた自装置以外の他の端末装置へ前記着信を転送することを特徴とする。
【００１７】
また、この発明にかかる音声通信方法は、前記着信端末装置および前記他の端末装置の少なくともいずれかは、前記着信を転送した端末装置が当該転送を完了しなかった場合に、前記着信を当該端末装置の次の端末装置へ転送することを特徴とする。
【００１８】
また、この発明にかかる音声通信プログラムは、上記に記載の音声通信方法を前記端末装置に実行させることを特徴とする。
【発明の効果】
【００１９】
本発明によれば、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなう場合に、複数の端末装置からなる端末装置群に対して、一つの代表ユーザＩＤを用いて確実かつ効率的に各端末装置へ着信を振り分けることが可能な音声通信方法および音声通信プログラムが得られるという効果を奏する。
【発明を実施するための最良の形態】
【００２０】
以下に添付図面を参照して、この発明にかかる音声通信方法および音声通信プログラムの好適な実施の形態を詳細に説明する。
【００２１】
（システム構成）
まず、この発明の実施の形態にかかる音声通信方法を実現するための音声通信システムの全体構成について説明する。図１は、この発明の実施の形態にかかる音声通信方法を実現するためのシステム構成を示す説明図である。図１において、音声通信システムにおいて、１００はネットワークであり、１０１は発信ユーザであり、１０２は発信ユーザ１０１が使用する発信ＰＣ（パーソナルコンピュータ）であり、１０３は発信ＰＣ１０２にインストールされている発信ユーザソフト（ウエア）である。
【００２２】
また、１０４（１０４ａ、１０４ｂ、１０４ｃ）はオペレータであり、１０５（１０５ａ、１０５ｂ、１０５ｃ）は、オペレータ１０４が使用するオペレータＰＣ（パーソナルコンピュータ）であり、オペレータ１０４の人数と同じ台数が存在する。また、１０６（１０６ａ、１０６ｂ、１０６ｃ）はオペレータＰＣ１０５にインストールされているオペレータソフト（ウエア）である。
【００２３】
また、１０７（１０７ａ、１０７ｂ、１０７ｃ）は、転送ＰＣ（パーソナルコンピュータ）であり、複数台が存在する。また、１０８（１０８ａ、１０８ｂ、１０８ｃ）は転送ＰＣ１０７にインストールされている転送ソフト（ウエア）である。
【００２４】
ここで、発信ユーザ１０１は、オペレータ１０４に対して発信するユーザであり、オペレータ１０４は、取り次ぐ先のユーザであって、複数人存在する。また、発信ユーザソフト１０３およびオペレータソフト１０６は、いわゆるＰ２Ｐ電話ソフトであり、転送ソフト１０８は、発信ユーザ１０１からの電話を適切なオペレータ１０４に転送するソフトであり、通常のＰ２Ｐ電話ソフトとしてログインおよび着信する機能を持っている。
【００２５】
また、各ソフト（発信ユーザソフト１０３、オペレータソフト１０６、転送ソフト１０８）間の通信は、各ハードウェア（ＰＣ１０２，１０５，１０７）が同一のネットワーク１００に属しており、各ソフト間はＩＰアドレスやポート番号などのネットワーク情報を知っていればお互いに通信することが可能である。また、転送ソフト１０８とオペレータソフト１０６は、あらかじめお互いのＩＰアドレスやポート番号などのネットワーク情報を知っており、いつでも通信をすることが可能である。
【００２６】
また、各ソフトは他のソフトと通話中の状態であっても、他の転送ソフト１０８やオペレータソフト１０６に対して通話以外のデータ通信をおこなうことが可能である。また、転送ソフト１０８とオペレータソフト１０６は常にお互いに自分の状況を伝え合い、現在どのオペレータソフト１０６が着信可能な状態なのかを把握している。また、転送ソフト１０８とオペレータソフト１０６は各オペレータソフト１０６にログインしているオペレータ１０４の属性情報を把握している。
【００２７】
（着信ソフト決定手順）
つぎに、着信ソフト決定手順の内容について説明する。具体的には、最初に着信するソフトと次に着信するソフトを決定する手順について説明する。ここで、最初に着信するソフトを「先頭着信ソフト」と呼び、その次に着信するソフトを「次着信ソフト」と呼ぶ。また、オペレータソフトのことをここでは「ノード」と呼ぶ。また、各ノードのノードＩＤ、ＩＰアドレス、ポート番号は、あらかじめ全ノードが把握しているものとする。
【００２８】
図２は、各ノードが保有する情報（ノードテーブル）を示す説明図である。各ノードは図２に示すような各ノードの情報（ノードテーブル）を保有する。図２において、項目「ノードＩＤ」には、ノードを一意に特定するＩＤを記憶する。また、項目「ＩＰアドレス」には、ノードが存在するコンピュータのＩＰアドレスを記憶する。また、項目「ポート番号」には、着信する可能性があるソフト（＝ノード）のポート番号を記憶する。また、項目「状態」には、ノードの接続状態（着信可能、着信不可能、ダウン）に関する情報を記憶する。また、項目「着信順序」には、どのノードが先頭着信ソフトと次着信ソフトなのか、および、そのソフトが接続不可能かどうかに関する情報を記憶する。
【００２９】
また、項目「ユーザＩＤ」には、そのノードにログインしているオペレータのユーザＩＤを記憶する。なお、本実施の形態においては、図３に示すように、発信ユーザ１０１のユーザＩＤとして「ｕｓｅｒ０」を、代表ユーザ（代表ユーザの内容については後述する）のユーザＩＤとして「ｕｓｅｒ１」を、オペレータ１０４のユーザＩＤとして「ｏｐｅｒａｔｏｒ１、ｏｐｅｒａｔｏｒ２、ｏｐｅｒａｔｏｒ３、・・・」をそれぞれ用いる。また、項目「オペレータ属性情報」には、そのノードにログインしているオペレータの属性情報（スキル、稼働率など）を記憶する。
【００３０】
図４−１〜図９は、着信ソフト決定手順の内容を示すフローチャートである。図４−１および図４−２は、新規ノードがネットワーク１００に参加した場合の手順を示す。ここで、新たに参加したノードを仮にＮＯＤＥ１とする。図４−１において、まず、ＮＯＤＥ１は、図２に示したノードテーブルを任意の順序に並べて、ノードリストとする（ステップＳ４０１）。その後、ＮＯＤＥ１は、ノードリストからつぎの１件を抽出する（ステップＳ４０２）。
【００３１】
そして、リストがまだあるか否かを判断する（ステップＳ４０３）。ここで、リストがもうない場合（ステップＳ４０３：Ｎｏ）は、図４−２に示すステップＳ４４１へ移行する。一方、リストがまだある場合（ステップＳ４０３：Ｙｅｓ）は、ＮＯＤＥ１は抽出したノードに接続し（ステップＳ４０４）、接続できるか否かを判断する（ステップＳ４０５）。ここで、接続できなければ（ステップＳ４０５：Ｎｏ）は、ステップＳ４０２へ戻って、次の１件を抽出する。以後ステップＳ４０２〜Ｓ４０５を繰り返しおこなう。
【００３２】
ステップＳ４０５において、接続ができる場合（ステップＳ４０５：Ｙｅｓ）は、ＮＯＤＥ１は、接続先ノードにノードテーブルの情報を問い合わせる（ステップＳ４０６）。そして、接続先ノードは、ノードテーブルの情報をＮＯＤＥ１に伝える（ステップＳ４０７）。伝えられたノードテーブルの情報において、先頭着信ソフトが存在するか否かを判断する（ステップＳ４０８）。
【００３３】
ステップＳ４０８において、先頭着信ソフトが存在する場合（ステップＳ４０８：Ｙｅｓ）は、つぎに、次着信ソフトが存在するか否かを判断する（ステップＳ４０９）。ここで、次着信ソフトが存在する場合（ステップＳ４０９：Ｙｅｓ）は、図４−２に示すステップＳ４２１へ移行する。一方、次着信ソフトが存在しない場合（ステップＳ４０９：Ｎｏ）は、図４−２に示すステップＳ４３１へ移行する。
【００３４】
ステップＳ４０８において、先頭着信ソフトが存在しない場合（ステップＳ４０８：Ｎｏ）は、ＮＯＤＥ１は、現在時刻を記憶し、記憶した現在時刻を「確認開始時刻」とする（ステップＳ４１０）。つぎに、ＮＯＤＥ１は、全ノードに先頭着信ソフトになってよいかを確認する。このときに上記「確認開始時刻」を全ノードに伝える（ステップＳ４１１）。
【００３５】
各ノードは、先頭着信ソフトになってよいかの確認中でなければ、ＮＯＤＥ１に対してＯＫを返す。確認中であれば、確認開始時刻を比較し、ＮＯＤＥ１よりも後であればＮＯＤＥ１へＯＫを返す。一方、ＮＯＤＥ１よりも前に確認を開始していればＮＧを返す（ステップＳ４１２）。
【００３６】
そして、全ノードがＯＫであったか否かを判断する（ステップＳ４１３）。ここで、全ノードがＯＫである場合（ステップＳ４１３：Ｙｅｓ）は、図４−２に示すステップＳ４４１へ移行する。一方、全ノードがＯＫでない場合、すなわちＮＧを返したノードがあった場合（ステップＳ４１３：Ｎｏ）は、ＮＧを返したノードから先頭着信ソフトとなった連絡が来るのを一定時間待つ（ステップＳ４１４）。そして、連絡がない場合（ステップＳ４１５：Ｎｏ）はステップＳ４１０へ戻る、一方、連絡があった場合（ステップＳ４１５：Ｙｅｓ）は、図４−２に示すステップＳ４３１へ移行する。
【００３７】
図４−２のステップＳ４２１において、ＮＯＤＥ１は、ノードテーブルを更新する。そして、ＮＯＤＥ１は、先頭着信ソフトと次着信ソフトにＮＯＤＥ１の情報（状態、ユーザＩＤ、オペレータ属性情報など）を伝える（ステップＳ４２２）。それを受けて、先頭着信ソフトと次着信ソフトはノードテーブルを更新し（ステップＳ４２３）、一連の処理を終了する。
【００３８】
また、ステップＳ４３１において、ＮＯＤＥ１は、先頭着信ソフトに次着信ソフトが存在しないことを確認する。そして、先頭着信ソフトは、ノードテーブルの情報をＮＯＤＥ１に伝える（ステップＳ４３２）。つぎに、次着信ソフトが存在するか否かを判断する（ステップＳ４３３）。ここで、次着信ソフトが存在する場合（ステップＳ４３３：Ｙｅｓ）は、ステップＳ４２１へ移行する。一方、次着信ソフトが存在しない場合（ステップＳ４３３：Ｎｏ）は、ＮＯＤＥ１が次着信ソフトとなり、ノードテーブルを更新する（ステップＳ４３４）。
【００３９】
つぎに、ＮＯＤＥ１は全ノードに先頭着信ソフトと次着信ソフトがどのノードになったか（次着信ソフトはＮＯＤＥ１がなったこと）を伝える（ステップＳ４３５）。それを受けて、全ノードはノードテーブルを更新し（ステップＳ４３６）、一連の処理を終了する。
【００４０】
また、ステップＳ４４１において、ＮＯＤＥ１が先頭着信ソフトとなり、ノードテーブルを更新する（ステップＳ４４１）。そして、ＮＯＤＥ１は全ノードに先頭着信ソフトと次着信ソフトがどのノードになったか（先頭着信ソフトはＮＯＤＥ１がなったこと）を伝える（ステップＳ４４２）。それを受けて、全ノードはノードテーブルを更新し（ステップＳ４４３）、一連の処理を終了する。
【００４１】
図５は、着信不可能状態から着信可能状態へ変わった場合の手順を示す。ここで、着信可能状態に変わったノードを仮にＮＯＤＥ１とする。まず、ＮＯＤＥ１は、ノードテーブルの情報を参照し（ステップＳ５０１）、その結果、先頭着信ソフトが存在するか否かを判断する（ステップＳ５０２）。ここで、先頭着信ソフトが存在しない場合（ステップＳ５０２：Ｎｏ）は、ステップＳ５１４へ移行する。一方、先頭着信ソフトが存在する場合（ステップＳ５０２：Ｙｅｓ）は、つぎに、次着信ソフトが存在するか否かを判断する（
ステップＳ５０３）。
【００４２】
ステップＳ５０３において、次着信ソフトが存在する場合（ステップＳ５０３：Ｙｅｓ）は、ステップＳ５０９へ移行する。一方、次着信ソフトが存在しない場合（ステップＳ５０３：Ｎｏ）は、ＮＯＤＥ１は先頭着信ソフトに対して、次着信ソフトが存在しないことを確認する（ステップＳ５０４）。そして、先頭着信ソフトが接続可能であるか否かを判断する（ステップＳ５０５）。
【００４３】
ステップＳ５０５において、接続が可能でない場合（ステップＳ５０５：Ｎｏ）は、ステップＳ５１４へ移行する。一方、接続が可能である場合（ステップＳ５０５：Ｙｅｓ）は、先頭着信ソフトが、ノードテーブルの情報をＮＯＤＥ１に伝える（ステップＳ５０６）。そして、伝えられたノードテーブルの情報から、次着信ソフトが存在するか否かを判断する（ステップＳ５０７）。
【００４４】
ステップＳ５０７において、次着信ソフトが存在する場合（ステップＳ５０７：Ｙｅｓ）は、ＮＯＤＥ１は、ノードテーブルを更新し（ステップＳ５０８）、先頭着信ソフトと次着信ソフトに対して、ＮＯＤＥ１が着信可能であることを伝える（ステップＳ５０９）。それを受けて、先頭着信ソフトおよび次着信ソフトは、ノードテーブルを更新し（ステップＳ５１０）、一連の処理を終了する。
【００４５】
ステップＳ５０７において、次着信ソフトが存在しない場合（ステップＳ５０７：Ｎｏ）は、ＮＯＤＥ１は、自らが次着信ソフトとなり、ノードテーブルを更新し（ステップＳ５１１）、ＮＯＤＥ１は全ノードに先頭着信ソフトと次着信ソフトがどのノードになったか（次着信ソフトはＮＯＤＥ１がなったこと）を伝える（ステップＳ５１２）。それを受けて、全ノードはノードテーブルを更新し（ステップＳ５１３）、一連の処理を終了する。
【００４６】
ステップＳ５１４〜Ｓ５１９の各ステップは、図４−１に示したステップＳ４１０〜Ｓ４１５の各ステップと同様であるので、その説明は省略する。ステップＳ５１９において、連絡がない場合（ステップＳ５１９：Ｎｏ）はステップＳ５１４へ戻る。一方、連絡があった場合（ステップＳ５１９：Ｙｅｓ）は、ＮＯＤＥ１は、先頭着信ソフトに次着信ソフトが存在しないことを確認する（ステップＳ５２０）。そして、ステップＳ５０６へ移行する。
【００４７】
また、ステップＳ５１７において、全ノードがＯＫである場合（ステップＳ５１７：Ｙｅｓ）は、ステップＳ５２１へ移行する。ステップＳ５２１〜Ｓ５２３は、図４−２に示したステップＳ４４１〜Ｓ４４３と同様であるので、その説明は省略する。
【００４８】
図６は、先頭着信ソフトに着信した場合の手順を示す。ここで、先頭着信ソフトはＮＯＤＥ１であり、次着信ソフトはＮＯＤＥ２または存在しなかったとする。まず、ＮＯＤＥ１は、ノードテーブルの情報を参照し（ステップＳ６０１）、その結果、次着信ソフトが存在するか否かを判断する（ステップＳ６０２）。
【００４９】
ステップＳ６０２において、次着信ソフトが存在しない場合（ステップＳ６０２：Ｎｏ）は、ステップＳ６１２へ移行する。一方、次着信ソフトが存在する場合（ステップＳ６０２：Ｙｅｓ）は、ＮＯＤＥ１は、ＮＯＤＥ２に対して、ＮＯＤＥ１が着信不可能状態になったことを伝える（ステップＳ６０３）。それを受けて、ＮＯＤＥ２は、ＮＯＤＥ２を先頭着信ソフトとする（ステップＳ６０４）。
【００５０】
その後、ＮＯＤＥ２は、ＮＯＤＥ１およびＮＯＤＥ２以外で着信可能なノードのリスト
を作成する（ステップＳ６０５）。そして、着信可能なノードが存在するか否かを判断する（ステップＳ６０６）。ここで、着信可能なノードが存在しない場合（ステップＳ６０６：Ｎｏ）は、ステップＳ６１４へ移行する。一方、着信可能なノードが存在する場合（ステップＳ６０６：Ｙｅｓ）は、ＮＯＤＥ２は、着信可能ノードリストの中から最適なノードを判断し、そのノードに接続し（ステップＳ６０７）、接続が可能か否かを判断する（ステップＳ６０８）。
【００５１】
ステップＳ６０８において、接続が可能でない場合（ステップＳ６０８：Ｎｏ）は、ＮＯＤＥ２はノードテーブルを更新し（ステップＳ６０９）、ステップＳ６０５へ戻る。ステップＳ６０８において、接続が可能である場合（ステップＳ６０８：Ｙｅｓ）は、つぎに、ＮＯＤＥ２は、全ノードに対して、先頭着信ソフトと次着信ソフトがどのノードになったか（先頭着信ソフトはＮＯＤＥ２がなったこと）を伝える（ステップＳ６１０）。それを受けて、全ノードはノードテーブルを更新し（ステップＳ６１１）、一連の処理を終了する。
【００５２】
ステップＳ６０２において、次着信ソフトが存在しない場合（ステップＳ６０２：Ｎｏ）は、ステップＳ６１２へ移行し、ＮＯＤＥ１は、全ノードに先頭着信ソフトと次着信ソフトが存在しないことを伝える（ステップＳ６１２）。それを受けて、全ノードはノードテーブルを更新し（ステップＳ６１３）、一連の処理を終了する。
【００５３】
また、ステップＳ６０６において、着信可能ノードが存在しない場合（ステップＳ６０６：Ｎｏ）は、ステップＳ６１４へ移行し、ＮＯＤＥ２は、全ノードに先頭着信ソフトがＮＯＤＥ２であり、次着信ソフトが存在しないことを伝える（ステップＳ６１４）。それを受けて、全ノードはノードテーブルを更新し（ステップＳ６１５）、一連の処理を終了する。
【００５４】
図７は、次着信ソフトに着信した場合の手順を示す。ここで、先頭着信ソフトはＮＯＤＥ１であり、次着信ソフトはＮＯＤＥ２または存在しなかったとする。まず、ＮＯＤＥ２は、ノードテーブルの情報を参照し（ステップＳ７０１）、ＮＯＤＥ２は、ＮＯＤＥ１に対して着信不可能状態になったことを伝える（ステップＳ７０２）。それを受けて、ＮＯＤＥ１は、ノードテーブルを更新する（ステップＳ７０３）。
【００５５】
その後、ＮＯＤＥ１は、ＮＯＤＥ１およびＮＯＤＥ２以外で着信可能なノードのリストを作成する（ステップＳ７０４）。そして、着信可能なノードが存在するか否かを判断する（ステップＳ７０５）。ここで、着信可能なノードが存在しない場合（ステップＳ７０５：Ｎｏ）は、ステップＳ７１０へ移行する。一方、着信可能なノードが存在する場合（ステップＳ７０５：Ｙｅｓ）は、ＮＯＤＥ１は、着信可能ノードリストの中から最適なノードを判断し、そのノードに接続し（ステップＳ７０６）、接続が可能か否かを判断する（ステップＳ７０７）。
【００５６】
ステップＳ７０７において、接続が可能でない場合（ステップＳ７０７：Ｎｏ）は、ステップＳ７０３へ戻る。一方、ステップＳ７０７において、接続が可能である場合（ステップＳ７０７：Ｙｅｓ）は、つぎに、ＮＯＤＥ１は、全ノードに対して、先頭着信ソフトと次着信ソフトがどのノードになったかを伝える（ステップＳ７０８）。それを受けて、全ノードはノードテーブルを更新し（ステップＳ７０９）、一連の処理を終了する。
【００５７】
また、ステップＳ７０５において、着信ノードが存在しない場合（ステップＳ７０５：Ｎｏ）は、ステップＳ７１０へ移行し、ＮＯＤＥ１は、全ノードに対して、次着信ソフトが存在しないことを伝える（ステップＳ７１０）。それを受けて、全ノードはノードテーブルを更新し（ステップＳ７１１）、一連の処理を終了する。
【００５８】
図８は、先頭着信ソフトが、定期的に次着信ソフトと接続できるかのチェックの手順を示す。図８において、先頭着信ソフトであるＮＯＤＥ１は、一定時間待つ（ステップＳ８０１）。つぎに、一定時間が経過したら、つぎに、ＮＯＤＥ１は、次着信ソフトであるＮＯＤＥ２に接続する（ステップＳ８０２）。そして、接続が可能であるか否かを判断する（ステップＳ８０３）。ここで、接続が可能な場合（ステップＳ８０３：Ｙｅｓ）は、ステップＳ８０１へ戻る。一方、接続が可能でない場合（ステップＳ８０３：Ｎｏ）は、図７に示したステップＳ７０３へ移行する。
【００５９】
同様に、図９は、次着信ソフトが、定期的に先頭着信ソフトと接続できるかのチェックの手順を示す。図９において、次着信ソフトであるＮＯＤＥ２は、一定時間待つ（ステップＳ９０１）。つぎに、一定時間が経過したら、つぎに、ＮＯＤＥ２は、先頭着信ソフトであるＮＯＤＥ１に接続する（ステップＳ９０２）。そして、接続が可能であるか否かを判断する（ステップＳ９０３）。ここで、接続が可能な場合（ステップＳ９０３：Ｙｅｓ）は、ステップＳ９０１へ戻る。一方、接続が可能でない場合（ステップＳ９０３：Ｎｏ）は、図６に示したステップＳ６０９へ移行する。
【００６０】
（処理フローの内容）
つぎに、各ノードの状態が変化した場合の処理フローの内容について説明する。図１０〜図２２は、各ノードの状態が変化した場合の処理フローの内容を示す説明図である。図１０は、いまだどのノードも起動していない状況で、ＮＯＤＥ１がネットワークに参加した場合の処理フローである。図１０において、図４−１および図４−２に示したフローチャート（新規ノードがネットワークに参加した場合）に基づいて、任意の順序で全ノードに接続を試み、どのノードもダウンしていることを認識する。そして、ＮＯＤＥ１が先頭着信ソフトになる。
【００６１】
また、図１１−１〜図１１−３は、２台目のノードがネットワークに参加する場合、すなわち、先頭着信ソフトだけが起動されている状況で、ＮＯＤＥ２がネットワークに参加した場合の処理フローである。図１１−１において、ノードテーブル情報の取得をおこなう。すなわち、図４−１および図４−２に示したフローチャート（新規ノードがネットワークに参加した場合）に基づいて、任意の順序で全ノードに接続を試み、ＮＯＤＥ１に接続する。そして、ＮＯＤＥ２はＮＯＤＥ１からノードテーブルの情報を取得する。
【００６２】
つぎに、図１１−２において、「次着信ソフト」の決定と伝達をおこなう。すなわち、ＮＯＤＥ２は、ノードテーブルの情報から次着信ソフトが存在しないことを知る。そして、ＮＯＤＥ２は、ＮＯＤＥ１に次着信ソフトが存在しないことを再度確認し、「次着信ソフト」となる。その後、ＮＯＤＥ２は、ＮＯＤＥ１に次着信ソフトとなったことを伝え、ＮＯＤＥ１はノードテーブルを更新する。
【００６３】
つぎに、図１１−３において、ハートビート、すなわち、「先頭着信ソフト」と「次着信ソフト」が互いに定期的に通信をおこない、接続できるかどうかをチェックする。
【００６４】
また、図１２−１および図１２−２は、３台目以降の場合、すなわち、先頭着信ソフトと次着信ソフトが存在している状況で、新たにＮＯＤＥ４がネットワークに参加した場合の処理フローである。図１２−１において、ノードテーブル情報の取得をおこなう。すなわち、図４−１および図４−２に示したフローチャート（新規ノードがネットワークに参加した場合）に基づいて、任意の順番で全ノードに接続を試みる。ここでは、仮に最初に接続できたノードがＮＯＤＥ２であったとする。ＮＯＤＥ４は、ＮＯＤＥ２からノードテーブルを取得する。
【００６５】
つぎに、図１２−２において、ＮＯＤＥ４は、先頭着信ソフトと次着信ソフトにＮＯＤＥ４の状態を通知する。それを受けて、先頭着信ソフトと次着信ソフトは、自身のノードテーブルを更新する。
【００６６】
また、図１３−１〜図１３−３は、着信可能なノードが全くなかった状況で、ＮＯＤＥ１が着信可能となった場合の処理フローである。図１３−１において、全ノードに問い合わせをおこなう。すなわち、図５に示したフローチャート（着信不可能状態から着信可能状態へ変わった場合）に基づいて、ＮＯＤＥ１は、全ノードに対して、先頭着信ソフトとなってよいかを問い合わせる。これに対して、各ノードは「ＯＫ」を返す。
【００６７】
図１３−２において、ＮＯＤＥ１は、全ノードからの「ＯＫ」を受けて先頭着信ソフトとなる。また、図１３−３において、ＮＯＤＥ１は、全ノードにノードテーブルの情報を渡す。これを受けて、各ノードは自身のノードテーブルを更新する。
【００６８】
また、図１４−１〜図１４−９は、同時に複数のノードが着信可能になった場合、すなわち、着信可能なノードが全くなかった状況で、ＮＯＤＥ１が着信可能となり、その直後にＮＯＤＥ３も着信可能なった場合の処理フローである。図１４−１において、ＮＯＤＥ１がまず着信可能となる。そして、図５に示したフローチャート（着信不可能状態から着信可能状態へ変わった場合）に基づいて、ＮＯＤＥ１は、全ノードに対して、先頭着信ソフトとなってよいか問い合わせる。ここでは、まずＮＯＤＥ２とＮＯＤＥ４に問い合わせたとする。
【００６９】
図１４−２において、この段階でＮＯＤＥ３が着信可能となる。図５に示したフローチャート（着信不可能状態から着信可能状態へ変わった場合）に基づいて、ＮＯＤＥ３は、全ノードに先頭着信ソフトとなってよいか問い合わせる。ここでは、ＮＯＤＥ３はＮＯＤＥ１に問い合わせたとする。
【００７０】
図１４−３において、ＮＯＤＥ１は、自身の確認開始時刻とＮＯＤＥ３の確認開始時刻を比較し、ＮＯＤＥ３へ「ＮＧ」を返す。そして、図１４−４において、ＮＯＤＥ１は、ＮＯＤＥ３に対して、先頭着信ソフトとなってよいか問い合わせる。ＮＯＤＥ３は、自身の確認開始時刻とＮＯＤＥ１の確認開始時刻を比較し、ＮＯＤＥ１へ「ＯＫ」を返す。
【００７１】
つぎに、図１４−５において、ＮＯＤＥ１は、全ノードからの「ＯＫ」を受けて先頭着信ソフトとなる。さらに、図１４−６において、ＮＯＤＥ１は、全ノードにノードテーブルの情報を渡す。これを受けて、各ノードは自身のノードテーブルを更新する。
【００７２】
そして、図１４−７において、ＮＯＤＥ３は、先頭着信ソフトであるＮＯＤＥ１に次着信ソフトが存在しないことを確認する。これに対して、ＮＯＤＥ１はＮＯＤＥ３へ「ＯＫ」を返す。そして、図１４−８において、ＮＯＤＥ３は次着信ソフトとなる。さらに、図１４−９において、ＮＯＤＥ３は、ノードテーブルの情報を全ノードに渡す。これを受けて、各ノードは自身のノードテーブルを更新する。
【００７３】
また、図１５−１〜図１５−３は、着信可能になった場合（先頭着信ソフトあり）、すなわち、ＮＯＤＥ１が先頭着信ソフトであり、それ以外は全て着信不可能な状況で、ＮＯＤＥ３が着信可能となった場合の処理フローである。図１５−１において、図５に示したフローチャート（着信不可能状態から着信可能状態へ変わった場合）に基づいて、ＮＯＤＥ３は、先頭着信ソフトであるＮＯＤＥ１に次着信ソフトが存在しないことを確認する。ＮＯＤＥ１は「ＯＫ」をＮＯＤＥ３へ返す。
【００７４】
図１５−２において、ＮＯＤＥ３は次着信ソフトとなる。そして、図１５−３において
、ＮＯＤＥ３は、ノードテーブルの情報を全ノードに渡す。これを受けて、各ノードは自身のノードテーブルを更新する。
【００７５】
また、図１６は、着信可能になった場合（先頭着信ソフト次着信ソフトあり）、すなわち、先頭着信ソフトがＮＯＤＥ１、次着信ソフトがＮＯＤＥ２の状況で、ＮＯＤＥ４が着信可能になった場合の処理フローである。図１６において、ＮＯＤＥ４は、先頭着信ソフトと次着信ソフトにＮＯＤＥ４の状態を通知する。先頭着信ソフトと次着信ソフトは自身のノードテーブルを更新する。
【００７６】
また、図１７−１〜図１７−４は、次着信ソフトが存在するときに先頭着信ソフトに着信した場合、すなわち、先頭着信ソフトがＮＯＤＥ１、次着信ソフトがＮＯＤＥ２の状況で、ＮＯＤＥ１に着信した場合の処理フローである。図１７−１において、図６に示したフローチャート（先頭着信ソフトに着信した場合）に基づいて、ＮＯＤＥ１は、着信可能から着信不可能に状態が変化する。そして、ＮＯＤＥ１は、先頭着信ソフトではなくなる。図１７−２において、ＮＯＤＥ１は、着信不可能に状態が変化したことを、次着信ソフトであるＮＯＤＥ２に伝える。これを受けて、ＮＯＤＥ２は先頭着信ソフトとなる。
【００７７】
そして、図１７−３において、ＮＯＤＥ２は、ノードテーブルの情報に基づいて次着信ソフトをどのノードにするかを決定する。着信可能状態のノードが存在しなければ、次着信ソフトはなしとする。ここでは、ＮＯＤＥ３が次着信ソフトに決定されたとする。ＮＯＤＥ２は、ＮＯＤＥ３が接続できるかどうかをチェックする。ＮＯＤＥ３が接続できれば、ＮＯＤＥ３が次着信ソフトとなる。その後、図１７−４において、新しい先頭着信ソフトであるＮＯＤＥ２は、全てのノードに対して、ノードテーブルの情報を渡す。これを受けて、各ノードは自身のノードテーブルを更新する。
【００７８】
また、図１８−１および図１８−２は、次着信ソフトが存在しないときに先頭着信ソフトに着信した場合、すなわち、先頭着信ソフトがＮＯＤＥ１、次着信ソフトが存在しない状況で、ＮＯＤＥ１に着信した場合の処理フローである。図１８−１において、図６に示したフローチャート（先頭着信ソフトに着信した場合）に基づいて、ＮＯＤＥ１は、着信可能から着信不可能に状態が変化する。そして、ＮＯＤＥ１は、先頭着信ソフトではなくなる。
【００７９】
図１８−２において、ＮＯＤＥ１は、全ノードに先頭着信ソフトと次着信ソフトが存在しないことを伝える。これを受けて、各ノードは自身のノードテーブルを更新する。
【００８０】
また、図１９−１〜図１９−４は、次着信ソフトに着信した場合、すなわち、先頭着信ソフトがＮＯＤＥ１、次着信ソフトがＮＯＤＥ２の状況で、ＮＯＤＥ２に着信した場合の処理フローである。ここでは、後述する、代表ユーザのユーザＩＤではなく、ＮＯＤＥ２のオペレータのユーザＩＤに着信した場合を想定している。図１９−１において、図７に示したフローチャート（次着信ソフトに着信した場合）に基づいて、ＮＯＤＥ２は、着信可能から着信不可能に状態が変化する。そして、ＮＯＤＥ２は、次着信ソフトではなくなる。
【００８１】
つぎに、図１９−２において、ＮＯＤＥ２は、着信不可能に状態が変化したことを先頭着信ソフトであるＮＯＤＥ１に伝える。図１９−３において、ＮＯＤＥ１は、ノードテーブルの情報に基づいて次着信ソフトをどのノードにするかを決定する。着信可能状態のノードが存在しなければ、次着信ソフトはなしとする。ここでは、ＮＯＤＥ３が次着信ソフトに決定されたとする。ＮＯＤＥ１は、ＮＯＤＥ３が接続できるかどうかをチェックする。「ＯＫ」であればＮＯＤＥ３を次着信ソフトとする。
【００８２】
図１９−４において、ＮＯＤＥ１は、全ノードに対して、ノードテーブルの情報を渡す。これを受けて、各ノードは自身のノードテーブルを更新する。
【００８３】
また、図２０−１および図２０−２は、先頭着信ソフトがダウンした場合、すなわち、先頭着信ソフトがＮＯＤＥ１、次着信ソフトがＮＯＤＥ２の状況で、ＮＯＤＥ１がダウン（ハードウェア障害、ネットワーク障害など）した場合の処理フローである。図２０−１において、図９に示したフローチャートに基づいて、ＮＯＤＥ２は、定期的にＮＯＤＥ１と接続可能かどうかを確認する。ここで、応答がないため、ＮＯＤＥ１がダウンしたことを検知する。
【００８４】
そして、図２０−２において、ＮＯＤＥ２は、次着信ソフトから、先頭着信ソフトになる。それ以降は、図１７−３以降の処理フローと同様であるため、その説明は省略する。
【００８５】
また、図２１−１〜図２１−３は、先頭着信ソフトがダウンした場合（次着信ソフトなし）、すなわち、先頭着信ソフトがＮＯＤＥ１、次着信ソフトが存在しない状況で、ＮＯＤＥ１がダウン（ハードウェア障害、ネットワーク障害など）した場合の処理フローである。
【００８６】
図２１−１において、ＮＯＤＥ１がダウンする。そうすると、図２１−２において、いずれかのノードが着信可能状態に変わる。ここではＮＯＤＥ３が着信可能になったとする。そして、図２１−３において、図５に示すフローチャート（着信不可能状態から着信可能状態へ変わった場合）に基づいて、ＮＯＤＥ３は、先頭着信ソフトであるＮＯＤＥ１に次着信ソフトが存在しないことを確認する。しかし、ＮＯＤＥ１はダウンしているため、接続できない。それ以降は、図１３−１以降と同様であるため、その説明は省略する。
【００８７】
また、図２２は、次着信ソフトがダウンした場合、すなわち、先頭着信ソフトがＮＯＤＥ１、次着信ソフトがＮＯＤＥ２の状況で、ＮＯＤＥ２がダウン（ハードウェア障害、ネットワーク障害など）した場合の処理フローである。
【００８８】
図２２において、図８に示したフローチャートに基づいて、ＮＯＤＥ１は、定期的にＮＯＤＥ２と接続可能かどうかを確認する。しかし、応答がないため、ＮＯＤＥ２がダウンしたことを検知する。それ以降は、図１０以降と同様であるため、その説明は省略する。
【００８９】
（ＡＣＤ機能の実現方法）
つぎに、ＡＣＤ機能の実現方法の具体例について、６つ方法（１．バーチャルＩＤ方法、２．ＩＤ変更方法、３．複数発信方法、４．転送方法（その１）、５．転送方法（その２）、６．複合方法）を説明する。
【００９０】
（１．バーチャルＩＤ方法）
バーチャルＩＤ方法は、ユーザＩＤとは別にバーチャルＩＤを作成し、発信ユーザからバーチャルＩＤに対して発信する方法である。図２３は、バーチャルＩＤ方法の処理の手順を示すフローチャートであり、図２４−１〜図２４−３は、バーチャルＩＤ方法の処理フローの内容を示す説明図である。
【００９１】
図２４−１〜図２４−３において、『発信』は発信ユーザソフト（ウエア）を示し、『オペ』はオペレータソフト（ウエア）を示している。バーチャルＩＤ方法において、発信ユーザソフトとオペレータソフトはＰ２Ｐ電話（音声通信）ソフトウエアとしての機能を持っている。また、オペレータソフトはユーザＩＤとは別にバーチャルＩＤでログインすることが可能である。
【００９２】
また、発信ユーザソフトはユーザＩＤとバーチャルＩＤのどちらを指定しても電話をかけることが可能である。この場合、ユーザＩＤを指定して電話をかけた場合は、そのユーザがログインしているユーザに着信する。一方、バーチャルＩＤを指定して電話をかけた場合も同じく、そのバーチャルＩＤでログインしているユーザに着信する。
【００９３】
図２３のフローチャートにおいて、まず、各オペレータソフトは、自らのユーザＩＤでログインする（ステップＳ２３０１）。図２４−１に示すように、それぞれ、ユーザＩＤ（「ｏｐｅｒａｔｏｒ１」、「ｏｐｅｒａｔｏｒ２」、「ｏｐｅｒａｔｏｒ３」）でログインする。そして、先頭着信ソフトになったか否かを判断する（ステップＳ２３０２）。
【００９４】
ステップＳ２３０２において、先頭着信ソフトでない場合（ステップＳ２３０２：Ｎｏ）は、自らのユーザＩＤへの着信があった場合は回線を接続するが、それ以外は、先頭着信ソフトになるのを待つ。先頭着信ソフトになるか否かは、たとえば、前述した着信ソフト決定ロジックによって判断されることになる。そして、先頭着信ソフトになった場合（ステップＳ２３０２：Ｙｅｓ）は、バーチャルＩＤである代表ユーザのユーザＩＤ（代表ユーザＩＤ）でログインをする（ステップＳ２３０３）。図２４−１において、先頭着信ソフトとになったオペレータソフト（ユーザＩＤ：「ｏｐｅｒａｔｏｒ１」）は、代表ユーザＩＤ：「ｕｓｅｒ１」を使用してログインをおこなう。
【００９５】
つぎに、発信ユーザからの着信があったか否かを判断する（ステップＳ２３０４）。すなわち、図２４−２に示すように、発信ユーザが代表ユーザＩＤ：「ｕｓｅｒ１」に対して電話を発信し、バーチャルＩＤ（代表ユーザＩＤ）を持つオペレータソフトによってその電話が着信されたか否かを判断する。ここで、着信するのを待って、着信した場合（ステップＳ２３０４：Ｙｅｓ）は、あらかじめ定められていた次着信ソフトに対して代表ユーザＩＤでログインするように指示する（ステップＳ２３０５）。
【００９６】
具体的には、たとえば図２４−３に示すように、着信したオペレータソフトは、前述した着信ソフト決定ロジックに従って、次着信ソフトとなったオペレータソフト（ユーザＩＤ：「ｏｐｅｒａｔｏｒ２」）に対して、代表ユーザＩＤ（「ｕｓｅｒ１」）でログインするように、データ通信機能を用いて指示をする。その指示を受けて、次のオペレータソフト（ユーザＩＤ：「ｏｐｅｒａｔｏｒ２」）は代表ユーザＩＤでログインする。これによって、次の（別の）発信ユーザが「ｕｓｅｒ１」へ発信した場合は、別のオペレータソフト、すなわち、ユーザＩＤ：「ｏｐｅｒａｔｏｒ２」であって、代表ユーザＩＤ：「ｕｓｅｒ１」）でログインしたオペレータソフトに着信することになる。
【００９７】
あらかじめ定められた端末装置群（オペレータＰＣ）が、各自のユーザＩＤで前記ネットワークに対してログインするとともに、上記端末装置群のうちのいずれかの端末装置が、上記ユーザＩＤとは別の、上記端末装置群を代表するユーザＩＤ（代表ユーザＩＤ）で、ネットワークに対してログインし、発信元端末装置（発信ＰＣ）からの代表ユーザＩＤへの発信によって、発信元端末装置と、代表ユーザＩＤでログインされた端末装置（着信端末装置）とが接続された場合に、上記着信端末装置が、端末装置群のうちの他の端末装置のいずれか（具体的には、たとえば次着信ソフトのオペレータＰＣ）に対して、代表ユーザＩＤでログインするように指示することによって、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなう場合に、複数の端末装置からなる端末装置群に対して、一つの代表ユーザＩＤを用いて確実かつ効率的に各端末装置へ着信を振り分けることができる。
【００９８】
（２．ＩＤ変更方法）
ＩＤ変更方法は、ユーザＩＤを着信後変更することによって、別の発信ユーザソフトから着信できるようにする方法である。図２５は、ＩＤ変更方法の処理の手順を示すフロー
チャートであり、図２６−１〜図２６−６は、ＩＤ変更方法の処理フローの内容を示す説明図である。ＩＤ変更方法において、発信ユーザソフトとオペレータソフトはＰ２Ｐ電話（音声通信）ソフトウエアとしての機能を持っている。また、オペレータソフトはユーザＩＤを通信中に変更することが可能である。
【００９９】
図２５のフローチャートにおいて、まず、先頭着信ソフトになったか否かを判断する（ステップＳ２５０１）。ここで、先頭着信ソフトでない場合（ステップＳ２５０１：Ｎｏ）は、先頭着信ソフトになるのを待つ。先頭着信ソフトになるか否かは、たとえば、前述した着信ソフト決定ロジックによって判断されることになる。そして、先頭着信ソフトになった場合（ステップＳ２５０１：Ｙｅｓ）は、代表ユーザＩＤでログインをする（ステップＳ２５０２）。
【０１００】
図２６−１において、先頭着信ソフトになったオペレータソフト（図中、一番上のオペレータＰＣ）は、自動的に、代表ユーザＩＤ：「ｕｓｅｒ１」を使用してログインをおこなう。ここで、上述したバーチャルＩＤ方法とは異なり、各オペレータはログインしない。ただし、この場合は、オペレータソフトに自分のユーザＩＤを伝えておくようにする。また、上記各オペレータは自ユーザＩＤでログインした状態で待っていてもよい。この場合は、先頭着信ソフトに着信があって、その先頭着信ソフトから、代表ユーザＩＤでログインするようにとの指示があった場合は、一旦ログアウトし、その後、代表ユーザＩＤでログインをすることになる。
【０１０１】
つぎに、発信ユーザからの着信があったか否かを判断する（ステップＳ２５０３）。すなわち、図２６−２に示すように、発信ユーザが代表ユーザＩＤ：「ｕｓｅｒ１」に対して電話を発信し、代表ユーザＩＤを持つオペレータソフトによってその電話が着信されたか否かを判断する。ここで、着信するのを待って、着信した場合（ステップＳ２５０３：Ｙｅｓ）は、図２６−３に示すように、自ユーザＩＤ、すなわちユーザＩＤ「ｏｐｅｒａｔｏｒ１」に再度発信するように要求する。
【０１０２】
その後、通信を切断、すなわち、図２６−４に示すように、着信したオペレータソフトは発信ユーザとの接続を切断し（ステップＳ２５０５）、自ユーザＩＤ、すなわち「ｏｐｅｒａｔｏｒ１」で再度ログインをおこなう（ステップＳ２５０６）。これによって、ユーザＩＤを変更する。
【０１０３】
そして、発信ユーザからの着信があったか否かを判断する（ステップＳ２５０７）。すなわち、図２６−５に示すように、発信ユーザは「ｏｐｅｒａｔｏｒ１」に対して発信する。その着信があったか否かを判断する。ここで、着信するのを待って、着信した場合、すなわち、ユーザＩＤ変更後「ｏｐｅｒｅｔｏｒ１」のオペレータソフトに着信した場合（ステップＳ２５０７：Ｙｅｓ）は、次着信ソフトに対して、代表ユーザＩＤでログインするように指示をする（ステップＳ２５０８）。
【０１０４】
具体的には、たとえば図２６−６に示すように、着信したオペレータソフトは、前述した着信ソフト決定ロジックに従って、次着信ソフトとなったオペレータソフト（図中、上から２番目のオペレータＰＣ）に対して、代表ユーザでログインするよう指示をする。これによって、次の（別の）発信ユーザが「ｕｓｅｒ１」へ発信した場合は、別のオペレータソフト、すなわち代表ユーザＩＤ：「ｕｓｅｒ１」でログインしたオペレータソフトに着信することになる。
【０１０５】
あらかじめ定められた端末装置群（オペレータＰＣ）のうちのいずれかの端末装置が、上記ユーザＩＤとは別の、上記端末装置群を代表するユーザＩＤ（代表ユーザＩＤ）で、ネットワークに対してログインし、発信元端末装置（発信ＰＣ）からの代表ユーザＩＤへ
の発信によって、発信元端末装置と、代表ユーザＩＤでログインされた端末装置（着信端末装置）とが接続された場合に、上記着信端末装置が、端末装置群のうちの他の端末装置のいずれかに対して、代表ユーザＩＤでログインするように指示することによって、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなう場合に、複数の端末装置からなる端末装置群に対して、一つの代表ユーザＩＤを用いて確実かつ効率的に各端末装置へ着信を振り分けることができる。
【０１０６】
（３．複数発信方法）
複数発信方法は、一度に複数のオペレータソフトに対して発信する方法である。図２７−１および図２７−２は、複数発信方法の処理の手順を示すフローチャートであり、図２８−１〜図２８−３は、複数発信方法の処理フローの内容を示す説明図である。複数発信方法において、発信ユーザソフトとオペレータソフトはＰ２Ｐ電話（音声通信）ソフトウエアとしての機能を持っている。また、同じユーザＩＤで複数のＰ２Ｐ電話ソフトにログインした場合、そのユーザＩＤに発信すると全てのＰ２Ｐ電話ソフトに発信することが可能である。
【０１０７】
図２７−１のフローチャートにおいて、まず、全てのオペレータは、代表ユーザＩＤでログインをする（ステップＳ２７０１）。図２８−１に示すように、全てのオペレータソフトは、それぞれ自動的に、代表ユーザＩＤ：「ｕｓｅｒ１」を使用してログインをおこなう。
【０１０８】
つぎに、発信ユーザからの着信があったか否かを判断する（ステップＳ２７０２）。すなわち、図２８−２に示すように、発信ユーザが代表ユーザＩＤ：「ｕｓｅｒ１」に対して電話を発信し、代表ユーザＩＤを持つ全てのオペレータソフトによってその電話が着信されたか否かを判断する。ここで、着信するのを待って、着信した場合（ステップＳ２７０２：Ｙｅｓ）は、図２８−３に示すように、オペレータソフトの中で最適と判断されるものは着信し、それ以外のオペレータソフトは切断する。
【０１０９】
具体的には、図２７−１において、各オペレータソフトは、自らが先頭着信ソフトであるか否かを判断し（ステップＳ２７０３）、先頭着信ソフトである場合（ステップＳ２７０３：Ｙｅｓ）は、何もせずに一連の処理を終了する、すなわち、着信したままとする。これに対して、先頭着信ソフトでない場合（ステップＳ２７０３：Ｎｏ）は、通信を切断し（ステップＳ２７０５）、一連の処理を終了する。このように、先頭着信ソフトを最適なオペレータソフトと判断してもよい。
【０１１０】
また、図２７−２において、各オペレータソフトは、他のオペレータソフトから通話要求、すなわち、上記着信に対して、他のオペレータソフトが自ら通話をしたい旨の要求があったか否かを判断し（ステップＳ２７０４）、上記通話要求があった場合（ステップＳ２７０４：Ｙｅｓ）は、通信を切断し（ステップＳ２７０５）、一連の処理を終了する。このように、通話要求を他のオペレータソフトに送信したオペレータソフトを最適なオペレータソフトと判断するようにしてもよい。最適なオペレータソフトの判断は、上記方法に限らず、別の方法であってもよい。なお、図２７−２は、図２７−１のステップＳ２７０３をステップＳ２７０４に変えただけであり、その他は同じなので、その他の説明は省略する。
【０１１１】
あらかじめ定められた端末装置群（オペレータＰＣ）の各端末装置が、ユーザＩＤとは別の、端末装置群を代表する代表ユーザＩＤで、ネットワークに対してそれぞれにログインし、発信元端末装置からの代表ユーザＩＤへの発信によって、発信元端末装置と、代表ユーザＩＤでログインされた各端末装置とが接続された後、各端末装置のうちのいずれか
一つの端末装置を残して、他の端末装置と前記発信元端末装置との接続を切断することによって、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなう場合に、複数の端末装置からなる端末装置群に対して、一つの代表ユーザＩＤを用いて確実かつ効率的に各端末装置へ着信を振り分けることができる。
【０１１２】
（４．転送方法（その１））
転送方法（その１）は、発信ユーザからかかってきた電話を一旦転送ソフトで着信し、発信ソフトからオペレータソフトへ再発信する方法である。図２９は、転送方法（その１）における転送ソフト（ウエア）の処理の手順を示すフローチャートであり、図３０−１〜図３０−５は、転送方法（その１）の処理フローの内容を示す説明図である。
【０１１３】
図３０−１〜図３０−５において、『転送』は転送ソフト（ウエア）を示している。転送方法（その１）において、転送ソフトはＰ２Ｐ電話（音声通信）ソフトウエアとしての機能として、ログイン・接続の機能を持っているが、通話する機能を備えている必要はない。
【０１１４】
図２９のフローチャートにおいて、まず、転送ソフトは、代表ユーザＩＤ：「ｕｓｅｒ１」を使用してログインをおこなう（ステップＳ２９０１）。このとき、図３０−１に示すように、全てのオペレータは、自らのユーザＩＤでログインをする。
【０１１５】
つぎに、転送ソフトは、発信ユーザからの着信があったか否かを判断する（ステップＳ２９０２）。すなわち、図３０−２に示すように、発信ユーザが代表ユーザＩＤ：「ｕｓｅｒ１」に対して電話を発信し、代表ユーザＩＤを持つ転送ソフトによってその電話が着信されたか否かを判断する。ここで、着信するのを待って、着信した場合（ステップＳ２９０２：Ｙｅｓ）は、最適なオペレータを決定する（ステップＳ２９０３）。
【０１１６】
図３０−３に示すように、転送ソフトは空いているオペレータの中から最適なオペレータを決定する。ここでは、ユーザＩＤ：「ｏｐｅｒａｔｏｒ３」（図中、一番下のオペレータＰＣ）を最適なオペレータとして決定する。転送ソフトは発信ソフトに決定されたオペレータのユーザＩＤ（「ｏｐｅｒａｔｏｒ３」）を渡して、発信ソフトからそのユーザＩＤに再発信するよう再発信要求を送信する（ステップＳ２９０４）。
【０１１７】
その後、発信ソフトは、転送ソフトとの通信を切断し（ステップＳ２９０５）、転送ソフトの一連の処理は終了する。図３０−４に示すように、発信ソフトは、転送ソフトから指示されたユーザＩＤのオペレータ（「ｏｐｅｒａｔｏｒ３」）へ再発信する。そして、図３０−５に示すように、目的のオペレータソフト（「ｏｐｅｒａｔｏｒ３」）に着信する。
【０１１８】
あらかじめ定められた端末装置群（オペレータＰＣ）のうちのいずれかの端末装置（転送ＰＣ）が、ユーザＩＤとは別の、端末装置群を代表する代表ユーザＩＤで、ネットワークに対してログインするとともに、端末装置群のうちの他の端末装置（オペレータＰＣ）が、各自の前記ユーザＩＤでログインし、発信元端末装置（発信ＰＣ）からの代表ユーザＩＤへの発信によって、発信元端末装置と、前記代表ユーザＩＤでログインされた端末装置（転送ＰＣ）とが接続された場合に、転送ＰＣが、発信元端末装置に対して、上記他の端末装置（オペレータＰＣ）のいずれかへ発信するように指示し、転送方法（その１）における転送ソフト（ウエア）の処理の手順を示すフローチャートであ発信元端末装置との接続を切断することによって、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなう場合に、複数の端末装置からなる端末装置群に対して、一つの代表ユーザＩＤを用いて確実かつ効率的に各端末装置へ着信を振り分けることができる。
【０１１９】
（５．転送方法（その２））
転送方法（その２）は、発信ユーザからかかってきた電話を一旦転送ソフトで着信し、オペレータソフトから再発信する方法である。図３１は、転送方法（その１）における転送ソフト（ウエア）の処理の手順を示すフローチャートであり、図３２−１〜図３２−５は、転送方法（その２）の処理フローを示す説明図である。なお、図３２−１〜図３２−５において、『転送』は転送ソフト（ウエア）を示している。
【０１２０】
転送方法（その２）において、転送ソフトはＰ２Ｐ電話（音声通信）ソフトウエアとしての機能として、ログイン・接続の機能を持っているが、通話する機能を備えている必要はない。また、各ソフトは架電する際に、発信することを一意に特定することができる発信ＩＤを発信先に通知する。また、発信ソフトは通話中でも同じ発信ＩＤで電話がかかってきた場合は着信できるものとする。
【０１２１】
図３１のフローチャートにおいて、まず、転送ソフトは、代表ユーザＩＤ：「ｕｓｅｒ１」を使用してログインをおこなう（ステップＳ３１０１）。このとき、図３２−１に示すように、全てのオペレータは、自らのユーザＩＤでログインをする。
【０１２２】
つぎに、転送ソフトは、発信ユーザからの着信があったか否かを判断する（ステップＳ３１０２）。すなわち、図３２−２に示すように、発信ユーザが代表ユーザＩＤ：「ｕｓｅｒ１」に対して電話を発信する。この時、発信することを一意に特定することができる発信ＩＤ（「９９８８７７」）を渡す。そして、代表ユーザＩＤを持つ転送ソフトによってその電話が着信されたか否かを判断する（ステップＳ３１０２）。ここで、着信するのを待って、着信した場合（ステップＳ３１０２：Ｙｅｓ）は、最適なオペレータを決定する（ステップＳ３１０３）。
【０１２３】
そして、決定されたオペレータソフトに対して、発信ユーザのユーザＩＤへの発信要求を送信する（ステップＳ３１０４）。具体的には、図３２−３に示すように、転送ソフトは空いているオペレータの中から最適なオペレータを決定する。ここでは、ユーザＩＤ：「ｏｐｅｒａｔｏｒ３」（図中、一番下のオペレータＰＣ）を最適なオペレータとして決定する。そのオペレータソフトに接続指示をする。その際、発信ユーザのユーザＩＤ（「ｕｓｅｒ０」）と発信ＩＤ（「９９８８７７」）を渡す。
【０１２４】
その後、発信ソフトから、転送依頼情報を受信するのを待つ（ステップＳ３１０５）。具体的には、図３２−４に示すように、オペレータソフト（ ユーザＩＤ：「ｏｐｅｒａ
ｔｏｒ３」）から発信ソフトへ発信ユーザのユーザＩＤで発信する。その際、転送ソフトから受け取った発信ＩＤを渡し、ユーザＩＤ：「ｕｓｅｒ１」からユーザＩＤ：「ｏｐｅｒａｔｏｒ３」へ転送してほしい旨を伝える。発信ソフトは、現在、転送ソフト（ユーザＩＤ：「ｕｓｅｒ１」）と通話中であるが、発信ＩＤが同じ（「９９８８７７」）であることからオペレータソフト（ユーザＩＤ：「ｏｐｅｒａｔｏｒ３」）からの架電を着信する。
【０１２５】
そして、図３２−５に示すように、発信ソフトは、転送ソフトに対して、「ｏｐｅｒａｔｏｒ３から転送依頼を受けた」旨を伝える。これが、上記転送依頼情報である。そして上記転送依頼情報を受信するのを待って、上記転送依頼情報を受信した場合（ステップＳ３１０５：Ｙｅｓ）は、発信ソフトとの回線を切断し（ステップＳ３１０６）、一連の処理を終了する。また、転送ソフトは身に覚えのないユーザＩＤ（たとえばｏｐｅｒａｔｏｒ１）からの転送依頼であった場合は、発信ソフトにエラーを返す。発信ソフトはそれを受けて、身に覚えのないユーザとの回線を切断する。
【０１２６】
このように、あらかじめ定められた端末装置群のうちのいずれかの端末装置（転送ＰＣ）が、ユーザＩＤとは別の、端末装置群を代表する代表ユーザＩＤで、ネットワークに対してログインするとともに、端末装置群のうちの他の端末装置が、各自の前記ユーザＩＤでログインし、発信元端末装置からの代表ユーザＩＤへの発信によって、発信元端末装置と、代表ユーザＩＤでログインされた端末装置（転送ＰＣ）とが接続された場合に、転送ＰＣが、他の端末装置（オペレータＰＣ）のいずれかに対して、発信元端末装置へ発信するように指示することによって、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなう場合に、複数の端末装置からなる端末装置群に対して、一つの代表ユーザＩＤを用いて確実かつ効率的に各端末装置へ着信を振り分けることができる。
【０１２７】
（６．複合方法）
複合方法は、上記の方法を組み合わせて実現する方法である。図３３に示すように、発信ユーザソフト１０３から転送ソフト１０８へ接続する時には上記「バーチャルＩＤ方法」「ＩＤ変更方法」「複数発信方法」のいずれかの方法を使って接続する。この場合、上記説明で「オペレータソフト」の役割にあたるものが「転送ソフト」となる。その後、転送ソフトはオペレータソフトへその電話を取り次ぐ時には上記「転送方法（その１）」「転送方法（その２）」のいずれかの方法を使って接続する。
【０１２８】
このように、上記の方法を組み合わせることで、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしでおこなう音声通信において、より適切かつ確実にＡＣＤを実現することができる。
【０１２９】
（７．事前協議方法）
事前協議方法は、受電すべきオペレータソフトを事前に協議し、受電すべきオペレータソフト以外は受電を受け付けない状態にしておく方法である。図３４は、事前協議方法の処理の手順を示すフローチャートであり、図３５−１〜図３５−３は、事前協議方法の処理フローの内容を示す説明図である。
【０１３０】
事前協議方法において、発信ユーザソフトとオペレータソフトはＰ２Ｐ電話（音声通信）ソフトウエアとしての機能を持っている。また、オペレータソフトは受電可能／受電不可の状態を持つことが可能であり、受電可能状態のオペレータソフトには発信ソフトからの発信が着信し、受電不可状態のオペレータソフトには着信しない。
【０１３１】
図３４のフローチャートにおいて、まず、全てのオペレータソフトは、それぞれ代表ユーザＩＤでログインをする（ステップＳ３４０１）。たとえば図３５−１に示すように、全てのオペレータソフトは、それぞれ自動的に、代表ユーザＩＤ：「ｕｓｅｒ１」を使用してログインをおこなう。それとともに、受電可否状態を「不可（受電不可）」に設定する（ステップＳ３４０２）。そして、先頭着信ソフトになったか否かを判断する（ステップＳ３４０３）。
【０１３２】
ステップＳ３４０３において、先頭着信ソフトでない場合（ステップＳ３４０３：Ｎｏ）は、つぎに、受電可否状態変更指示が他のオペレータソフトからあったか否かを判断する（ステップＳ３４０４）。ここで、変更指示がない場合（ステップＳ３４０４：Ｎｏ）は、ステップＳ３４０３へ戻る。そして、先頭着信ソフトになった場合（ステップＳ３４０３：Ｙｅｓ）、または、受電可否状態変更指示があった場合（ステップＳ３４０４：Ｙｅｓ）は、受電可否状態を「不可」から「可（受電可）」へ変更する（ステップＳ３４０５）。
【０１３３】
つぎに、受電可否状態が「可」のオペレータソフトは、発信ソフトからの着信を待って（ステップＳ３４０６）、着信した場合（ステップ３４０６：Ｙｅｓ）は、受電可否状態を「可」から「不可」へ変更し（ステップＳ３４０７）、次着信ソフトに対して受電可否状態を「可」とするように指示する（ステップＳ３４０８）。
【０１３４】
具体的には、たとえば図３５−２に示すように、発信ユーザはユーザＩＤ：「ｕｓｅｒ１」に対して電話を発信する。代表ユーザのユーザＩＤでログインかつ受電可状態のオペレータソフト（図３５−２の一番上のオペレータソフト）に着信する。そして、図３５−３に示すように、着信したオペレータソフトは受電可否状態を受電不可とし、上述した「着信ソフト決定ロジック」に従って次着信ソフトとなったオペレータソフトに対して、受電可否状態を受電可とするよう指示する。これによって、次の発信ユーザがユーザＩＤ：「ｕｓｅｒ１」へ発信した場合は、別のオペレータソフトに着信することになる。
【０１３５】
このように、あらかじめ定められた端末装置群（オペレータＰＣ）の各端末装置が、ユーザＩＤとは別の、端末装置群を代表する代表ユーザＩＤで、ネットワークに対してそれぞれにログインし、受電可能端末装置のみが受電可能状態とするとともに、受電可能端末装置以外の他の端末装置が受電不可状態とし、発信元端末装置からの代表ユーザＩＤへの発信によって、発信元端末装置と受電可能端末装置とが接続された場合に、受電可能端末装置が、自装置を受電不可状態にするとともに、受電可能端末装置以外の他の端末装置のいずれかに対して、受電可能状態とするように指示することによって、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなう場合に、複数の端末装置からなる端末装置群に対して、一つの代表ユーザＩＤを用いて確実かつ効率的に各端末装置へ着信を振り分けることができる。
【０１３６】
（８．パスアップ（ｐａｓｓ  ｕｐ）方法）
パスアップ方法は、取り合えずオペレータを問わず受電し、適切なオペレータに出会うまで転送し続ける方法である。図３６および図３７は、パスアップ方法の処理の手順を示すフローチャートであり、図３８−１〜図３８−３は、パスアップ方法の処理フローの内容を示す説明図である。パスアップ方法において、発信ユーザソフトとオペレータソフトはＰ２Ｐ電話（音声通信）ソフトウエアとしての機能を持っている。また、発信ソフトとオペレータソフトとの間で転送が可能となっている。
【０１３７】
図３６のフローチャートにおいて、まず、いずれか一つのオペレータソフトは、代表ユーザＩＤでログインをする（ステップＳ３６０１）。たとえば図３８−１に示すように、いずれか一つのオペレータソフト（後述する図３８−１の一番上のオペレータソフト）は、代表ユーザＩＤ：「ｕｓｅｒ１」を使用してログインをおこなう。
【０１３８】
つぎに、代表ユーザＩＤでログインしたオペレータソフトは、発信ソフトからの着信を待って（ステップＳ３６０２）、着信した場合（ステップ３６０２：Ｙｅｓ）は、当該オペレータソフトが通話中であるか否かを判断する（ステップＳ３６０３）。ここで、通話中の場合（ステップＳ３６０３：Ｙｅｓ）は、ステップＳ３６０５へ移行する。一方、ステップＳ３６０３において、通話中でない場合（ステップＳ３６０３：Ｎｏ）は、当該オペレータソフトが先頭着信ソフトであるか否かを判断する（ステップＳ３６０４）。
【０１３９】
ステップＳ３６０４において、先頭着信ソフトでない場合（ステップＳ３６０４：Ｎｏ）は、ステップＳ３６０５へ移行し、ステップＳ３６０５において、あらかじめ定められている次のオペレータソフトへ転送処理をおこなう。そして、当該次のオペレータソフトへの転送が完了したか否かを判断する（ステップＳ３６０６）。ここで、転送が完了しなかった場合（ステップＳ３６０６：Ｎｏ）は、あらかじめ定められている、当該次のオペレータソフトの次のオペレータソフトへ転送処理をおこない（ステップＳ３６０７）、ステップＳ３６０６へ戻る。
【０１４０】
このようにして、転送が完了するまで、ステップＳ３６０６とステップＳ３６０７を繰り返しおこなう。そして、ステップＳ３６０６において、転送が完了した場合（ステップＳ３６０６：Ｙｅｓ）は、ステップＳ３６０２へ戻って、再び着信待ち状態となる。
【０１４１】
ステップＳ３６０４において、代表ユーザＩＤでログインし、着信があったオペレータソフトが先頭着信ソフトである場合（ステップＳ３６０４：Ｙｅｓ）は、受電処理をおこない（ステップＳ３６０８）、一連の処理を終了する。
【０１４２】
図３７のフローチャートは、オペレータソフトが、自ユーザソフトでログインした場合の処理の手順を示しており、オペレータソフトは、自ユーザＩＤでログインし（ステップＳ３７０１）、その後、あらかじめ定められた前のオペレータソフトから転送があったか否かを判断する（ステップＳ３７０２）。以後は、図３６に示したステップＳ３６０３〜ステップＳ３６０８と同様の処理であるので、その説明は省略する。
【０１４３】
図３８−１において、一番上のオペレータソフトのみが、代表ユーザでログインをおこなう。つぎに、図３８−２において、発信ユーザはユーザＩＤ：ｕｓｅｒ１、すなわち一番上のオペレータソフトに対して電話を発信する。当該オペレータソフトはその発信について着信する。ここで、着信したオペレータソフトが、上述した着信ソフト決定ロジックに従って先頭着信ソフトとなったか否かを判断し、先頭着信ソフトである場合は、受電する。一方、当該オペレータソフトが先頭着信ソフトでない場合は、他のオペレータソフト（図３８−２では、ユーザＩＤ：ｏｐｅｒａｔｏｒ１へ当該着信を転送する。転送する先はリスト上の自オペレータソフトの次のオペレータソフトとし、転送が完了しない場合（たとえば不在の場合など）は、そのつぎのオペレータソフトへ転送する。
【０１４４】
図３８−３において、転送を受けたオペレータソフト（ユーザＩＤ：ｏｐｅｒａｔｏｒ１）は、同様に着信ソフト決定ロジックに従って先頭着信ソフトか否かを判断し、先頭着信ソフトである場合は、受電する。一方、当該オペレータソフトが先頭着信ソフトでない場合は、他のオペレータソフト（図３８−３では、ユーザＩＤ：ｏｐｅｒａｔｏｒ２へ当該着信を転送する。転送する先はリスト上の自オペレータソフトの次のオペレータソフトとし、転送が完了しない場合（たとえば不在の場合など）は、その次のオペレータソフトへ転送する。ここでは、ユーザＩＤ：ｏｐｅｒａｔｏｒ２（上から３番目のオペレータソフト）が、オペレータ不在のため、その次のオペレータソフト（ユーザＩＤ：ｏｐｅｒａｔｏｒ３へ転送する。
【０１４５】
ここで、発信者より、リストの指定を受けることができる。具体的には、ユーザＩＤ：ｏｐｅｒａｔｏｒ３と通話がしたいが、できないときは、ｏｐｅｒａｔｏｒ１かｏｐｅｒａｔｏｒ４でよいという場合に、ｏｐｅｒａｔｏｒ３→ｏｐｅｒａｔｏｒ１→ｏｐｅｒａｔｏｒ４というリストをあらかじめ作成し、発信時に電話呼に付加するようにするとよい。これによって、当該発信者に対しては、ｏｐｅｒａｔｏｒ３が主担当、ｏｐｅｒａｔｏｒ１およびｏｐｅｒａｔｏｒ４が副担当とする場合に特に有効である。
【０１４６】
このように、あらかじめ定められた端末装置群のうちのいずれかの端末装置（転送ＰＣ）が、ユーザＩＤとは別の、端末装置群を代表する代表ユーザＩＤで、ネットワークに対してログインするとともに、端末装置群のうちの他の端末装置が、各自の前記ユーザＩＤでログインし、発信元端末装置からの代表ユーザＩＤへの発信によって、着信端末装置が受電可能である場合は、発信元端末装置と接続するとともに、受電可能でない場合は、端末装置群のうちのあらかじめ定められた他の端末装置へ前記着信を転送し、他の端末装置が、着信の転送があった際に受電可能である場合は、発信元端末装置と接続するとともに、受電可能でない場合は、端末装置群のうちのあらかじめ定められた自装置以外の他の端末装置へ着信を転送することによって、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしで、音声通信をおこなう場合に、複数の端末装置からなる端末装置群に対して、一つの代表ユーザＩＤを用いて確実かつ効率的に各端末装置へ着信を振り分けることができる。
【０１４７】
なお、本実施の形態で説明した音声通信方法は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーション等のコンピュータで実行することにより実現することができる。このプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。またこのプログラムは、インターネット等のネットワークを介して配布することが可能な伝送媒体であってもよい。
【産業上の利用可能性】
【０１４８】
以上のように、ユーザごとに一意に定められたユーザＩＤを使用してネットワークに対してログインされた端末装置どうしでおこなう音声通信に用いるのに適している。
【図面の簡単な説明】
【０１４９】
【図１】本発明の実施の形態にかかる音声通信方法を実現するためのシステムの概要を示す説明図である。
【図２】各ノードが保有する情報（ノードテーブル）を示す説明図である。
【図３】各ユーザとユーザＩＤとの関係を示す説明図である。
【図４−１】着信ソフト決定手順の内容を示すフローチャートである。
【図４−２】着信ソフト決定手順の内容を示すフローチャートである。
【図５】着信ソフト決定手順の内容を示すフローチャートである。
【図６】着信ソフト決定手順の内容を示すフローチャートである。
【図７】着信ソフト決定手順の内容を示すフローチャートである。
【図８】着信ソフト決定手順の内容を示すフローチャートである。
【図９】着信ソフト決定手順の内容を示すフローチャートである。
【図１０】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１１−１】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１１−２】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１１−３】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１２−１】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１２−２】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１３−１】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１３−２】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１３−３】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１４−１】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１４−２】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１４−３】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１４−４】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１４−５】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１４−６】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１４−７】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１４−８】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１４−９】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１５−１】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１５−２】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１５−３】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１６】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１７−１】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１７−２】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１７−３】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１７−４】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１８−１】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１８−２】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１９−１】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１９−２】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１９−３】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図１９−４】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図２０−１】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図２０−２】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図２１−１】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図２１−２】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図２１−３】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図２２】各ノードの状態が変化した場合の処理フローの内容を示す説明図である。
【図２３】バーチャルＩＤ方法の処理の手順を示すフローチャートである。
【図２４−１】バーチャルＩＤ方法の処理フローの内容を示す説明図である。
【図２４−２】バーチャルＩＤ方法の処理フローの内容を示す説明図である。
【図２４−３】バーチャルＩＤ方法の処理フローの内容を示す説明図である。
【図２５】ＩＤ変更方法の処理の手順を示すフローチャートである。
【図２６−１】ＩＤ変更方法の処理フローの内容を示す説明図である。
【図２６−２】ＩＤ変更方法の処理フローの内容を示す説明図である。
【図２６−３】ＩＤ変更方法の処理フローの内容を示す説明図である。
【図２６−４】ＩＤ変更方法の処理フローの内容を示す説明図である。
【図２６−５】ＩＤ変更方法の処理フローの内容を示す説明図である。
【図２６−６】ＩＤ変更方法の処理フローの内容を示す説明図である。
【図２７−１】複数発信方法の処理の手順を示すフローチャートである。
【図２７−２】複数発信方法の処理の手順を示すフローチャートである。
【図２８−１】複数発信方法の処理フローの内容を示す説明図である。
【図２８−２】複数発信方法の処理フローの内容を示す説明図である。
【図２８−３】複数発信方法の処理フローの内容を示す説明図である。
【図２９】転送方法（その１）における転送ソフト（ウエア）の処理の手順を示すフローチャートである。
【図３０−１】転送方法（その１）の処理フローの内容を示す説明図である。
【図３０−２】転送方法（その１）の処理フローの内容を示す説明図である。
【図３０−３】転送方法（その１）の処理フローの内容を示す説明図である。
【図３０−４】転送方法（その１）の処理フローの内容を示す説明図である。
【図３０−５】転送方法（その１）の処理フローの内容を示す説明図である。
【図３１】転送方法（その２）における転送ソフト（ウエア）の処理の手順を示すフローチャートである。
【図３２−１】転送方法（その２）の処理フローの内容を示す説明図である。
【図３２−２】転送方法（その２）の処理フローの内容を示す説明図である。
【図３２−３】転送方法（その２）の処理フローの内容を示す説明図である。
【図３２−４】転送方法（その２）の処理フローの内容を示す説明図である。
【図３２−５】転送方法（その２）の処理フローの内容を示す説明図である。
【図３３】複合方法の処理フローの内容を示す説明図である。
【図３４】事前協議方法における転送ソフト（ウエア）の処理の手順を示すフローチャートである。
【図３５−１】事前協議方法の処理フローの内容を示す説明図である。
【図３５−２】事前協議方法の処理フローの内容を示す説明図である。
【図３５−３】事前協議方法の処理フローの内容を示す説明図である。
【図３６】パスアップ方法における、代表ユーザＩＤでログインした場合のＰ２Ｐ電話ソフト（ウエア）の処理の手順を示すフローチャートである。
【図３７】パスアップ方法における、代表ユーザＩＤ以外のＩＤでログインした場合のＰ２Ｐ電話ソフト（ウエア）の処理の手順を示すフローチャートである。
【図３８−１】パスアップ方法の処理フローの内容を示す説明図である。
【図３８−２】パスアップ方法の処理フローの内容を示す説明図である。
【図３８−３】パスアップ方法の処理フローの内容を示す説明図である。
【符号の説明】
【０１５０】
１００  ネットワーク
１０１  発信ユーザ
１０２  発信ＰＣ（パーソナルコンピュータ）
１０３  発信ユーザソフト（ウエア）
１０４（１０４ａ、１０４ｂ、１０４ｃ）  オペレータ
１０５（１０５ａ、１０５ｂ、１０５ｃ）  オペレータＰＣ（パーソナルコンピュータ）
１０６（１０６ａ、１０６ｂ、１０６ｃ）  オペレータソフト（ウエア）
１０７（１０７ａ、１０７ｂ、１０７ｃ）  転送ＰＣ（パーソナルコンピュータ）
１０８（１０８ａ、１０８ｂ、１０８ｃ）  転送ソフト（ウエア）
【図１】
2006325172.tif 000003
【図２】
2006325172.tif 000004
【図３】
2006325172.tif 000005
【図４−１】
2006325172.tif 000006
【図４−２】
2006325172.tif 000007
【図５】
2006325172.tif 000008
【図６】
2006325172.tif 000009
【図７】
2006325172.tif 000010
【図８】
2006325172.tif 000011
【図９】
2006325172.tif 000012
【図１０】
2006325172.tif 000013
【図１１−１】
2006325172.tif 000014
【図１１−２】
2006325172.tif 000015
【図１１−３】
2006325172.tif 000016
【図１２−１】
2006325172.tif 000017
【図１２−２】
2006325172.tif 000018
【図１３−１】
2006325172.tif 000019
【図１３−２】
2006325172.tif 000020
【図１３−３】
2006325172.tif 000021
【図１４−１】
2006325172.tif 000022
【図１４−２】
2006325172.tif 000023
【図１４−３】
2006325172.tif 000024
【図１４−４】
2006325172.tif 000025
【図１４−５】
2006325172.tif 000026
【図１４−６】
2006325172.tif 000027
【図１４−７】
2006325172.tif 000028
【図１４−８】
2006325172.tif 000029
【図１４−９】
2006325172.tif 000030
【図１５−１】
2006325172.tif 000031
【図１５−２】
2006325172.tif 000032
【図１５−３】
2006325172.tif 000033
【図１６】
2006325172.tif 000034
【図１７−１】
2006325172.tif 000035
【図１７−２】
2006325172.tif 000036
【図１７−３】
2006325172.tif 000037
【図１７−４】
2006325172.tif 000038
【図１８−１】
2006325172.tif 000039
【図１８−２】
2006325172.tif 000040
【図１９−１】
2006325172.tif 000041
【図１９−２】
2006325172.tif 000042
【図１９−３】
2006325172.tif 000043
【図１９−４】
2006325172.tif 000044
【図２０−１】
2006325172.tif 000045
【図２０−２】
2006325172.tif 000046
【図２１−１】
2006325172.tif 000047
【図２１−２】
2006325172.tif 000048
【図２１−３】
2006325172.tif 000049
【図２２】
2006325172.tif 000050
【図２３】
2006325172.tif 000051
【図２４−１】
2006325172.tif 000052
【図２４−２】
2006325172.tif 000053
【図２４−３】
2006325172.tif 000054
【図２５】
2006325172.tif 000055
【図２６−１】
2006325172.tif 000056
【図２６−２】
2006325172.tif 000057
【図２６−３】
2006325172.tif 000058
【図２６−４】
2006325172.tif 000059
【図２６−５】
2006325172.tif 000060
【図２６−６】
2006325172.tif 000061
【図２７−１】
2006325172.tif 000062
【図２７−２】
2006325172.tif 000063
【図２８−１】
2006325172.tif 000064
【図２８−２】
2006325172.tif 000065
【図２８−３】
2006325172.tif 000066
【図２９】
2006325172.tif 000067
【図３０−１】
2006325172.tif 000068
【図３０−２】
2006325172.tif 000069
【図３０−３】
2006325172.tif 000070
【図３０−４】
2006325172.tif 000071
【図３０−５】
2006325172.tif 000072
【図３１】
2006325172.tif 000073
【図３２−１】
2006325172.tif 000074
【図３２−２】
2006325172.tif 000075
【図３２−３】
2006325172.tif 000076
【図３２−４】
2006325172.tif 000077
【図３２−５】
2006325172.tif 000078
【図３３】
2006325172.tif 000079
【図３４】
2006325172.tif 000080
【図３５−１】
2006325172.tif 000081
【図３５−２】
2006325172.tif 000082
【図３５−３】
2006325172.tif 000083
【図３６】
2006325172.tif 000084
【図３７】
2006325172.tif 000085
【図３８−１】
2006325172.tif 000086
【図３８−２】
2006325172.tif 000087
【図３８−３】
2006325172.tif 000088