(57)【特許請求の範囲】
【請求項１】
ＳＩＰ(Session Initiation Protocol)／ＳＩＭＰＬＥ(SIP for Instant Messaging and Presence Leveraging Extensions)を用いたプレゼンスシステムに備えられたサーバであって、
プレゼンス情報を登録するためのPUBLISHメッセージを送信する第１の通信装置と、
前記プレゼンス情報を購読するためのSUBSCRIBEメッセージを送信する第２の通信装置と、
受信した前記PUBLISHメッセージに含まれる前記プレゼンス情報を登録し、受信した前記SUBSCRIBEメッセージの送信元装置へ前記プレゼンス情報を含むNOTIFYメッセージを送信する複数のプレゼンスサーバと
の間で通信可能な負荷分散サーバにおいて、
前記プレゼンス情報毎のエントリに、当該プレゼンス情報を登録したプレゼンスサーバの識別子のリストを記録したパブリッシュ用データベースと、
前記プレゼンスサーバ毎に、購読(SUBSCRIBE)メッセージ受信率を記録したサブスクライブ用データベースと、
前記SUBSCRIBEメッセージ又は前記PUBLISHメッセージを受信した際に、当該プレゼンス情報に基づくエントリに含まれた前記リストの中のプレゼンスサーバについて、前記購読メッセージ受信率が最も低いプレゼンスサーバを選択するエントリ検索手段と、
選択された前記プレゼンスサーバに基づく前記購読メッセージ受信率が所定閾値Ｔｓよりも高い場合、前記購読メッセージ受信率が所定閾値Ｔｓ以下となるいずれか１つの追加プレゼンスサーバを選択するプレゼンスサーバ選択手段と、
選択された前記プレゼンスサーバへ、前記PUBLISHメッセージを送信するメッセージ送受信制御手段と
を有することを特徴とする負荷分散サーバ。
【請求項２】
前記プレゼンスサーバ選択手段は、
前記プレゼンス情報の一部を引数とするハッシュ関数によって、前記複数のプレゼンスサーバの中からいずれか１つのプレゼンスサーバを選択し、
選択された当該プレゼンスサーバに対する購読メッセージ受信率が所定閾値Ｔｓ以下か否かを判定し、
その判定を真とする前記プレゼンスサーバが検出されるまで、プレゼンスサーバの選択を繰り返す
ことを特徴とする請求項１に記載の負荷分散サーバ。
【請求項３】
前記メッセージ送受信制御手段は、第２の通信装置から受信した前記SUBSCRIBEメッセージを前記プレゼンスサーバへ送信するために、
前記プレゼンスサーバのアドレスを含むリダイレクト要求を、第２の通信装置へ返信するか、ＤＳＲ(Direct Server Return)方式によって前記プレゼンスサーバへ前記SUBSCRIBEメッセージを送信するか、又は、ＮＡＴ(Network Address Translation)方式によって前記プレゼンスサーバへ前記SUBSCRIBEメッセージを送信する
ことを特徴とする請求項１又は２に記載の負荷分散サーバ。
【請求項４】
前記SUBSCRIBEメッセージを受信した際に、前記追加プレゼンスサーバへ前記PUBLISHメッセージを送信する場合、
前記メッセージ送受信制御手段は、当該プレゼンス情報に基づくエントリに含まれる前記リストの中のいずれか１つのプレゼンスサーバへ前記PUBLISHメッセージを送信し、該プレゼンスサーバから前記NOTIFYメッセージによってプレゼンス情報を受信し、該プレゼンス情報を含むPUBLISHメッセージを、前記追加プレゼンスサーバへ送信する
ことを特徴とする請求項１から３のいずれか１項に記載の負荷分散サーバ。
【請求項５】
前記PUBLISHメッセージを受信した際に、前記追加プレゼンスサーバへ前記PUBLISHメッセージを送信する場合、
前記メッセージ送受信制御手段は、当該プレゼンス情報に基づくエントリに含まれる前記リストの中の全てのプレゼンスサーバへ前記PUBLISHメッセージを送信すると共に、前記追加プレゼンスサーバへ前記PUBLISHメッセージを送信する
ことを特徴とする請求項１から４のいずれか１項に記載の負荷分散サーバ。
【請求項６】
前記サブスクライブ用データベースは、前記プレゼンス情報毎に、更に有効期間を含んでおり、
前記エントリ検索手段は、前記サブスクライブ用データベースに記憶されたSUBSCRIBEメッセージの有効期間が、現在時刻を過ぎたプレゼンスサーバについて、エントリリストから削除することを特徴とする請求項１から５のいずれか１項に記載の負荷分散サーバ。
【請求項７】
ＳＩＰ／ＳＩＭＰＬＥを用いたプレゼンスシステムに備えられたサーバであって、
プレゼンス情報を登録するためのPUBLISHメッセージを送信する第１の通信装置と、
前記プレゼンス情報を購読するためのSUBSCRIBEメッセージを送信する第２の通信装置と、
受信した前記公開メッセージに含まれる前記プレゼンス情報を登録し、受信した前記購読メッセージの送信元装置へ前記プレゼンス情報を含むNOTIFYメッセージを送信する複数のプレゼンスサーバと
の間で通信可能なサーバに搭載されたコンピュータを機能させる負荷分散プログラムであって、
前記プレゼンス情報毎のエントリに、当該プレゼンス情報を登録したプレゼンスサーバの識別子のリストを記録したパブリッシュ用データベースと、
前記プレゼンスサーバ毎に、購読(SUBSCRIBE)メッセージ受信率を記録したサブスクライブ用データベースと、
前記SUBSCRIBEメッセージ又は前記PUBLISHメッセージを受信した際に、当該プレゼンス情報に基づくエントリに含まれた前記リストの中のプレゼンスサーバについて、前記購読メッセージ受信率が最も低いプレゼンスサーバを選択するエントリ検索手段と、
選択された前記プレゼンスサーバに基づく前記SUBSCRIBEメッセージ受信率が所定閾値Ｔｓよりも高い場合、前記購読メッセージ受信率が所定閾値Ｔｓ以下となるいずれか１つの追加プレゼンスサーバを選択するプレゼンスサーバ選択手段と、
選択された前記プレゼンスサーバへ、前記公開メッセージを送信するメッセージ送受信制御手段と
してコンピュータを機能させることを特徴とする負荷分散プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＳＩＰ(Session Initiation Protocol)／ＳＩＭＰＬＥ(SIP for Instant Messaging and Presence Leveraging Extensions)を用いたプレゼンスシステムに関する。特に、プレゼンス情報の負荷を分散管理する負荷分散サーバ及びプログラムに関する。
【背景技術】
【０００２】
ＳＩＭＰＬＥは、インスタントメッセージ及びプレゼンスサービスを実現するために、ＳＩＰを拡張した技術である（例えば非特許文献１、２及び３参照）。プレゼンスサービスとは、ユーザ（端末）の状態（「オンライン」「オフライン」「ビジー」「不在」等）を、他のユーザ（端末）へ向けて、プッシュ的に通知するものである。現在では、ユーザの状態だけでなく、端末の能力や位置など様々な情報（プレゼンス情報）を扱うことができる。尚、３ＧＰＰ(3rd Generation Partnership Project)では、ＳＩＰ／ＳＩＭＰＬＥを用いたＩＭＳ(IP Multimedia Domain)におけるプレゼンスシステムを標準化している（例えば非特許文献４参照）。
【０００３】
図１は、従来技術におけるプレゼンスシステムの構成図である。
【０００４】
図１によれば、複数のユーザ端末は、１台のプレゼンスサーバ２と通信をすることができる。ここで、複数のユーザ端末は、プレゼンティティ(Presentity)機能及び／又はウォッチャ(Watcher)機能を有する。プレゼンティティとは、Presence＋Entityの造語であって、プレゼンス情報の所有者を表す。ウォッチャとは、SUBSCRIBER（購読者）を意味し、プレゼンティティに対応する用語である。
【０００５】
（Ｓ１０１）プレゼンス情報を生成するプレゼンティティ３は、プレゼンスサーバ２へ、プレゼンス情報を登録するためのPUBLISHメッセージを送信する。これに対し、プレゼンスサーバ２は、プレゼンティティ３へ200OKメッセージを返信する。プレゼンス情報の登録はソフトステートで管理される。従って、プレゼンスサーバ２は、有効期間内に、再登録(REFRESH)のPUBLISHメッセージが受信されない限り、そのプレゼンス情報の登録を破棄する。
【０００６】
（Ｓ１０２）ウォッチャ４を操作するユーザは、他のユーザの所持するプレゼンティティ３のプレゼンス情報を購読したいとする。そのとき、ウォッチャ４は、プレゼンスサーバ２へ、そのプレゼンティティ３のプレゼンス情報の購読を要求するSUBSCRIBEメッセージを送信する。これに対し、プレゼンスサーバ２は、ウォッチャ４へ200OKメッセージを返信する。
【０００７】
プレゼンス情報は、PRS-URI(PReSence - Uniform Resource Identifier、プレゼンティティのプレゼンス情報に対する識別子)及びEvent（イベント名、イベントパッケージ）の組み合わせによって識別される。プレゼンス情報の購読も、ソフトステートで管理される。従って、プレゼンスサーバ２は、有効期間内に、再購読(SUBSCRIBE)メッセージが受信されない限り、そのプレゼンス情報の購読を破棄する。再購読の場合、初回の購読と同じダイアログを含むSUBSCRIBEメッセージを送信する必要がある。即ち、To tag、From tag、Call-ID及びEventヘッダフィールドのidパラメータが、一致する必要がある。
【０００８】
（Ｓ１０３）SUBSCRIBEメッセージを受信したプレゼンスサーバ２は、そのプレゼンス情報を含むNOTIFYメッセージを、ウォッチャ４へ返信する。これに対し、ウォッチャ４は、プレゼンスサーバ２へ200OKメッセージを返信する。
【０００９】
また、プレゼンティティ３が、プレゼンス情報の内容変更(MODIFY)のPUBLISHメッセージをプレゼンスサーバ２へ送信した場合、そのプレゼンス情報を購読している全てのウォッチャ４へ、更新されたプレゼンス情報を含むNOTIFYメッセージが送信される。
【００１０】
【非特許文献１】“SessionInitiation Protocol (SIP)-Specific Event Notification”, RFC3265
【非特許文献２】“SessionInitiation Protocol (SIP) Extension for Event State Publication”, RFC3903
【非特許文献３】“A PresenceEvent Package for the Session Initiation Protocol (SIP)”, RFC3856
【非特許文献４】“Presenceservice using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3(Release 7)”, 3GPP TS 24.141 V7.3.0 (2006-12)
【発明の開示】
【発明が解決しようとする課題】
【００１１】
前述したプレゼンスシステムによれば、プレゼンス情報が増加することによって、プレゼンスサーバ及びネットワークの負荷も増加する。具体的には、プレゼンス情報を含むPUBLISHメッセージの送信回数が多いほど、NOTIFYメッセージの送信回数も増加する。特に、１つのプレゼンス情報に対するSUBSCRIBEメッセージの送信回数が多いほど、１つのPUBLISHメッセージに対してNOTIFYメッセージの送信回数も増加する。
NOTIFYメッセージ数＝SUBSCRIBEメッセージ数×PUBLISHメッセージ数
【００１２】
将来的にユーザ端末数が増加した場合、このような問題は、プレゼンスシステムにおける拡張性の制約となる。
【００１３】
従来、ＳＩＰメッセージの内容を参照する経路制御によって、負荷分散を実現するレイヤ７スイッチがある。これをプレゼンスシステムに適用する場合、例えばPRS-URI及びEvent毎に、そのプレゼンス情報を含むPUBLISHメッセージを経路制御し、プレゼンスサーバへ送信することも考えられる。
【００１４】
しかしながら、ウォッチャは、SUBSCRIBEメッセージを、PUBLISHメッセージによってプレゼンス情報が登録されたプレゼンスサーバへ送信する必要がある。なぜなら、それ以外のプレゼンスサーバは、そのプレゼンス情報を保持していないからである。従って、ある特定のプレゼンス情報を保持したプレゼンスサーバに、多数のSUBSCRIBEメッセージが集中して送信され、負荷が集中するという問題がある。
【００１５】
従って、本発明は、複数のプレゼンスサーバを備えた場合に、プレゼンス情報の負荷を分散管理することができる負荷分散サーバ及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１６】
本発明によれば、ＳＩＰ(Session Initiation Protocol)／ＳＩＭＰＬＥ(SIP for Instant Messaging and Presence Leveraging Extensions)を用いたプレゼンスシステムに備えられたサーバであって、
プレゼンス情報を登録するためのPUBLISHメッセージを送信する第１の通信装置と、
プレゼンス情報を購読するためのSUBSCRIBEメッセージを送信する第２の通信装置と、
受信したPUBLISHメッセージに含まれるプレゼンス情報を登録し、受信したSUBSCRIBEメッセージの送信元装置へプレゼンス情報を含むNOTIFYメッセージを送信する複数のプレゼンスサーバと
の間で通信可能な負荷分散サーバにおいて、
プレゼンス情報毎のエントリに、当該プレゼンス情報を登録したプレゼンスサーバの識別子のリストを記録したパブリッシュ用データベースと、
プレゼンスサーバ毎に、購読(SUBSCRIBE)メッセージ受信率を記録したサブスクライブ用データベースと、
SUBSCRIBEメッセージ又はPUBLISHメッセージを受信した際に、当該プレゼンス情報に基づくエントリに含まれたリストの中のプレゼンスサーバについて、購読メッセージ受信率が最も低いプレゼンスサーバを選択するエントリ検索手段と、
選択されたプレゼンスサーバに基づく購読メッセージ受信率が所定閾値Ｔｓよりも高い場合、購読メッセージ受信率が所定閾値Ｔｓ以下となるいずれか１つの追加プレゼンスサーバを選択するプレゼンスサーバ選択手段と、
選択されたプレゼンスサーバへ、PUBLISHメッセージを送信するメッセージ送受信制御手段と
を有することを特徴とする。
【００１８】
本発明の負荷分散サーバにおける他の実施形態によれば、プレゼンスサーバ選択手段は、
プレゼンス情報の一部を引数とするハッシュ関数によって、複数のプレゼンスサーバの中からいずれか１つのプレゼンスサーバを選択し、
選択された当該プレゼンスサーバに対する購読メッセージ受信率が所定閾値Ｔｓ以下か否かを判定し、
その判定を真とするプレゼンスサーバが検出されるまで、プレゼンスサーバの選択を繰り返す
ことも好ましい。
【００１９】
本発明の負荷分散サーバにおける他の実施形態によれば、
メッセージ送受信制御手段は、第２の通信装置から受信したSUBSCRIBEメッセージをプレゼンスサーバへ送信するために、
プレゼンスサーバのアドレスを含むリダイレクト要求を、第２の通信装置へ返信するか、ＤＳＲ(Direct Server Return)方式によってプレゼンスサーバへSUBSCRIBEメッセージを送信するか、又は、ＮＡＴ(Network Address Translation)方式によってプレゼンスサーバへSUBSCRIBEメッセージを送信する
ことも好ましい。
【００２０】
本発明の負荷分散サーバにおける他の実施形態によれば、
SUBSCRIBEメッセージを受信した際に、追加プレゼンスサーバへPUBLISHメッセージを送信する場合、
メッセージ送受信制御手段は、当該プレゼンス情報に基づくエントリに含まれるリストの中のいずれか１つのプレゼンスサーバへPUBLISHメッセージを送信し、該プレゼンスサーバからNOTIFYメッセージによってプレゼンス情報を受信し、該プレゼンス情報を含むPUBLISHメッセージを、追加プレゼンスサーバへ送信する
ことも好ましい。
【００２１】
本発明の負荷分散サーバにおける他の実施形態によれば、
PUBLISHメッセージを受信した際に、追加プレゼンスサーバへPUBLISHメッセージを送信する場合、
メッセージ送受信制御手段は、当該プレゼンス情報に基づくエントリに含まれるリストの中の全てのプレゼンスサーバへPUBLISHメッセージを送信すると共に、追加プレゼンスサーバへPUBLISHメッセージを送信する
ことも好ましい。
【００２２】
本発明の負荷分散サーバにおける他の実施形態によれば、
サブスクライブ用データベースは、プレゼンス情報毎に、更に有効期間を含んでおり、
エントリ検索手段は、サブスクライブ用データベースに記憶されたSUBSCRIBEメッセージの有効期間が、現在時刻を過ぎたプレゼンスサーバについて、エントリリストから削除することも好ましい。
【００２３】
本発明によれば、ＳＩＰ／ＳＩＭＰＬＥを用いたプレゼンスシステムに備えられたサーバであって、
プレゼンス情報を登録するためのPUBLISHメッセージを送信する第１の通信装置と、
プレゼンス情報を購読するためのSUBSCRIBEメッセージを送信する第２の通信装置と、
受信したPUBLISHメッセージに含まれるプレゼンス情報を登録し、受信したSUBSCRIBEメッセージの送信元装置へプレゼンス情報を含むNOTIFYメッセージを送信する複数のプレゼンスサーバと
の間で通信可能なサーバに搭載されたコンピュータを機能させる負荷分散プログラムであって、
プレゼンス情報毎のエントリに、当該プレゼンス情報を登録したプレゼンスサーバの識別子のリストを記録したパブリッシュ用データベースと、
プレゼンスサーバ毎に、購読(SUBSCRIBE)メッセージ受信率を記録したサブスクライブ用データベースと、
SUBSCRIBEメッセージ又はPUBLISHメッセージを受信した際に、当該プレゼンス情報に基づくエントリに含まれたリストの中のプレゼンスサーバについて、購読メッセージ受信率が最も低いプレゼンスサーバを選択するエントリ検索手段と、
選択されたプレゼンスサーバに基づくSUBSCRIBEメッセージ受信率が所定閾値Ｔｓよりも高い場合、購読メッセージ受信率が所定閾値Ｔｓ以下となるいずれか１つの追加プレゼンスサーバを選択するプレゼンスサーバ選択手段と、
選択されたプレゼンスサーバへ、PUBLISHメッセージを送信するメッセージ送受信制御手段と
してコンピュータを機能させることを特徴とする負荷分散プログラム。
【発明の効果】
【００２５】
従って、本発明の負荷分散サーバ及びプログラムによれば、ある特定のプレゼンス情報に対して多くのSUBSCRIBEメッセージが集中して送信される場合であっても、そのプレゼンス情報を登録するプレゼンスサーバの数を増加させることにより、プレゼンス情報の負荷を分散管理することができる。
【発明を実施するための最良の形態】
【００２６】
以下では、図面を用いて、本発明を実施するための最良の形態について詳細に説明する。
【００２７】
図２は、本発明におけるシステム構成図である。
【００２８】
本発明の重要な構成要素は、ＳＩＰ／ＳＩＭＰＬＥを用いたプレゼンスシステムに搭載された負荷分散サーバ１である。図２によれば、プレゼンティティ又はウォッチャとして機能する複数のユーザ端末は、負荷分散サーバ１と通信する。負荷分散サーバ１は、ネットワークを介して複数のプレゼンスサーバ２と接続されている。負荷分散サーバ１は、プレゼンス情報を複数のプレゼンスサーバに登録することにより、プレゼンスシステムにおけるSUBSCRIBEメッセージの分散処理を可能とする。
【００２９】
本発明における負荷分散サーバ１は、プレゼンティティ３から、プレゼンス情報を含むPUBLISHメッセージを受信した際に、プレゼンスサーバに対するメッセージの集中の程度から負荷分散の必要性を判定する。負荷分散が必要と判定した際に、負荷分散サーバ１は、複数のプレゼンスサーバ２へPUBLISHメッセージを送信する。これにより、そのプレゼンス情報が、複数のプレゼンスサーバ２によって登録される。
【００３０】
また、負荷分散サーバ１は、ウォッチャ４からSUBSCRIBEメッセージを受信した際に、特定のプレゼンスサーバ２に負荷が集中しないように、負荷の軽いプレゼンスサーバへ、そのSUBSCRIBEメッセージを経路制御する。
【００３１】
プレゼンスサーバ２は、受信したSUBSCRIBEメッセージを経路制御してプレゼンスサーバ２へ送信する。例えば、プレゼンスサーバのアドレスを含むリダイレクト要求をウォッチャ４へ返信するか、ＤＳＲ方式又はＮＡＴ方式によってプレゼンスサーバへSUBSCRIBEメッセージを送信する。これによって、プレゼンスサーバ２は、そのプレゼンス情報を含むNOTIFYメッセージを、ウォッチャ４へ転送することができる。ウォッチャ４は、負荷分散サーバ１を介しているにもかかわらず、既存のプレゼンスサーバ２と直接的にSUBSCRIBEメッセージを送受信している場合と、何ら違いがない。
【００３２】
負荷分散サーバ１は、全てのプレゼンスサーバ２の識別子（プレゼンスサーバＵＲＩであって、例えばSIP-URI）のリストを保持する。本発明によれば、特定のプレゼンス情報に対してSUBSCRIBEメッセージが多数発生した場合、そのプレゼンス情報を登録するプレゼンスサーバ２を増加させていくことによって、特定のプレゼンスサーバ２に集中する負荷を分散させることができる。
【００３３】
図３は、本発明における負荷分散サーバの機能構成図である。
【００３４】
負荷分散サーバ１は、データ蓄積のために、プレゼンスサーバリスト蓄積部１０１と、パブリッシュ用データベース１０２と、サブスクライブ用データベース１０３とを有する。
【００３５】
プレゼンスサーバリスト蓄積部１０１は、利用可能な全てのプレゼンスサーバにおけるプレゼンスサーバＵＲＩ(SIP-URI)と、それに対応するハッシュ値とを蓄積する。ハッシュ値は、SIP-URIを引数としてハッシュ関数から得た値である。
【００３６】
パブリッシュ用データベース１０２は、プレゼンス情報毎のエントリに、当該プレゼンス情報を登録したプレゼンスサーバのSIP-URIのリスト（エントリリスト）を記録する。パブリッシュ用データベース１０２は、プレゼンティティにおけるプレゼンス情報の識別子(PRS-URI)及びイベント名(Event)毎に、以下のようなデータを蓄積する。
【００３７】
【表１】
0004753316.tif 000002
【００３８】
表１によれば、PRS-URI及びEvent（例えばpresence）毎に、「有効期間」と、「代表エンティティタグ」と、「プレゼンスサーバＵＲＩ及びエンティティタグのリスト」とを有する。
【００３９】
「有効期間」は、そのプレゼンス情報の登録がプレゼンスサーバによって保持される時間を表す。「代表エンティティタグ」は、プレゼンティティへ返信した200OKメッセージにおけるExpiresヘッダフィールドの値である。「エントリリスト」は、そのプレゼンス情報を登録しているプレゼンスサーバのSIP-URI及びエンティティタグのリストである。
【００４０】
サブスクライブ用データベース１０３は、プレゼンスサーバ毎に、SUBSCRIBE受信率を記録する。サブスクライブ用データベース１０３は、302 Moved Temporarily方式と、ＤＳＲ／ＮＡＴ方式とで、蓄積するデータ構造が異なる。
【００４１】
302 Moved Temporarily方式とは、Ｗｅｂサーバからの応答であるＨＴＴＰリダイレクト(Hyper Text Transfer Protocol redirect)用のコードを、ＳＩＰの応答メッセージに適用したものであり、本来は、ページが一時的に別の場所に用意されていることを意味する。ＨＴＴＰでは、ユーザ端末のＷｅｂブラウザは、自動的にこのコードを認識し、リダイレクト先のＵＲＬを読みに行く。これをSIPに適用した場合、ウォッチャ４−プレゼンスサーバ２間のSUBSCRIBEメッセージ及びNOTIFYメッセージは直接的に送受信され、負荷分散サーバ１を全く経由しない。また、ＤＳＲ方式は、直接サーバ返答方式であり、ＮＡＴ方式とは、アドレス書き換え方式である。
【００４２】
サブスクライブ用データベース１０３は、302 Moved Temporarily方式の場合、以下のようなデータを蓄積する。
【表２】
0004753316.tif 000003
【００４３】
データ構造１によれば、PRS-URI及びEvent毎に、「プレゼンスサーバＵＲＩ、有効期間」のリストを有する。ここで、有効期間とは、各プレゼンスサーバにおいて、そのプレゼンス情報に対するSUBSCRIBEメッセージの有効期間の中で、最長の有効期間のもの示す。
【００４４】
また、データ構造２によれば、プレゼンスサーバＵＲＩ毎に、SUBSCRIBE受信率を蓄積する。SUBSCRIBE受信率とは、単位時間当たりのSUBSCRIBE数を意味し、これによって、発生したSUBSCRIBEの数が多いか少ないかを判定することができる。
【００４５】
更に、サブスクライブ用データベース１０３は、ＤＳＲ／ＮＡＴ方式の場合、以下のようなデータを蓄積する。
【表３】
0004753316.tif 000004
【００４６】
データ構造１によれば、プレゼンスサーバへ送信したSUBSCRIBEメッセージにおけるプレゼンス情報のEvent、ダイアログ（Toタグ、Fromタグ、Call-ID）、有効期間、プレゼンスサーバの識別子の組み合わせを記録する。
【００４７】
また、データ構造２によれば、プレゼンスサーバ毎に、総サブスクライブ数を記録する。ＤＳＲ／ＮＡＴ方式では、SUBSCRIBE受信率の代わりに、有効なダイアログの数をカウントした総サブスクライブ数を用いる。
【００４８】
負荷分散サーバ１は、更に、プレゼンスサーバ選択部１０４と、エントリ検索部１０５と、SUBSCRIBE受信率判定部１０６と、メッセージ送受信制御部１０７と、エントリ更新部１０８と、通信インタフェース部１０９とを有する。これら機能構成部は、サーバに搭載されたコンピュータを機能させるプログラムを実行することによって実現される。
【００４９】
プレゼンスサーバ選択部１０４は、プレゼンスサーバに基づくSUBSCRIBE受信率が所定閾値Ｔｓよりも高い場合、SUBSCRIBE受信率が所定閾値Ｔｓ以下となるいずれか１つの追加プレゼンスサーバを選択する。
【００５０】
エントリ検索部１０５は、当該プレゼンス情報に基づくエントリに含まれたリストの中のプレゼンスサーバについて、SUBSCRIBE受信率が最も低いプレゼンスサーバを選択する。
【００５１】
SUBSCRIBE受信率判定部１０６は、プレゼンスサーバにおけるSUBSCRIBE受信率が所定閾値Ｔｓ以下か否かを判定する。
【００５２】
メッセージ送受信制御部１０７は、プレゼンスサーバ２と、プレゼンティティ３と、ウォッチャ４との間でメッセージを交換する。
【００５３】
尚、各機能構成部の詳細な動作は、後述する図８及び図９に記載されたフローチャートに、番号を付して明確にしている。
【００５４】
図４は、本発明における第１のシーケンス図である。
【００５５】
（Ｓ４０１）最初に、プレゼンティティ３は、プレゼンス情報を登録するためにPUBLISH(INITIAL)メッセージを負荷分散サーバ１へ送信する。PUBLISH(INITIAL)メッセージを受信した負荷分散サーバ１は、そのプレゼンス情報を登録すべきプレゼンスサーバＰを選択する。このとき、SUBCRIBE受信率が所定閾値Ｔｓ以下となるプレゼンスサーバＰが選択される。そして、そのPUBLISH(INITIAL)メッセージは、そのプレゼンスサーバ２へ送信される。これにより、プレゼンスサーバ２は、プレゼンティティ３のプレゼンス情報を登録する。
【００５６】
以下は、この場合のPUBLISHメッセージのフォーマット例である。
PUBLISH sip:presentity@example.com SIP/2.0    ［PRS-URI］
Via SIP/2.0/UDP
Event:                                        ［イベント名］
To:<sip:presentity@example.com>               ［PRS-URI］
From:<sip:presentity@example.com>             ［PRS-URI］
Expires:                                      ［登録の有効期間］
Call-ID:
CSeq: 1 PUBLISH
【００５７】
（Ｓ４０２）これに対し、プレゼンスサーバ２は、200OKメッセージを負荷分散サーバ１へ返信する。200OKメッセージを受信した負荷分散サーバ１は、その200OKメッセージを、プレゼンティティ３へ返信する。これにより、プレゼンティティ３は、プレゼンスサーバ２へのプレゼンス情報の登録を完了する。
【００５８】
（Ｓ４０３）次に、ウォッチャ４が、プレゼンティティ３のプレゼンス情報を購読したいとする。このとき、ウォッチャ４は、SUBSCRIBE(INITIAL)メッセージを負荷分散サーバ１へ送信する。
【００５９】
以下は、この場合のSUBSCRIBEメッセージのフォーマット例である。
SUBSCRIBE sip:presentity@example.com SIP/2.0  ［PRS-URI］
Via SIP/2.0/UDP
Event:                                        ［イベント名］
To:<sip:presentity@example.com>               ［PRS-URI］
From:<sip:watcher@example.com>                ［ウォッチャのSIP URI］
Expires:                                      ［購読の有効期間］
Call-ID:
CSeq: 1 SUBSCRIBE
【００６０】
（Ｓ４０４）これに対し、負荷分散サーバ１は、ＳＩＰのリダイレクトの応答である302 Moved Temporarilyをウォッチャ４へ返信する。302 Moved Temporarilyは、そのプレゼンス情報を登録しているプレゼンスサーバ２のSIP-URIを含む。
【００６１】
（Ｓ４０５）ウォッチャ４は、リダイレクトによって、302 Moved Temporarilyに含まれるプレゼンスサーバ２のSIP-URIへ向けて、SUBSCRIBE(INITIAL)メッセージを送信する。
【００６２】
（Ｓ４０６）プレゼンスサーバ２は、ウォッチャ４からSUBSCRIBEメッセージを受信すると、既存のプレゼンスサーバと同様に、200OKメッセージをウォッチャ４へ返信する。プレゼンスサーバ２は、既に、負荷分散サーバ１からPUBLISH(INITIAL)メッセージを受信しており、そのプレゼンス情報を登録している。
【００６３】
（Ｓ４０７）次に、プレゼンスサーバ２は、NOTIFYメッセージを、ウォッチャ４へ送信する。NOTIFYメッセージは、プレゼンティティ３のプレゼンス情報を含む。
【００６４】
以下は、この場合のNOTIFYメッセージのフォーマット例である。
NOTIFY sip:watcher@example.com SIP/2.0        ［ウォッチャのSIP URI］
Via SIP/2.0/UDP
Event:                                        ［イベント名］
To:<sip:watcher@example.com>                  ［ウォッチャのSIP URI］
From:<sip:presentity@example.com>             ［PRS-URI］
Call-ID:
CSeq: 1 NOTIFY
Subscription-Status: active; expires=         ［購読の状態、有効期間］
<中略>
<プレゼンス情報>
【００６５】
（Ｓ４０８）NOTIFYメッセージを受信したウォッチャ４は、そのプレゼンス情報を取得する。そして、200OKメッセージを、プレゼンスサーバ２へ返信する。
【００６６】
（Ｓ４０９）その後、そのプレゼンス情報の購読を要求するSUBSCRIBEメッセージが、複数のウォッチャ４から多数送信されたとする。プレゼンスサーバ２に対するSUBSCRIBE受信率は、負荷分散サーバ１によって監視されている。このとき、プレゼンスサーバ２に対する負荷が集中しているために、以下では、そのプレゼンス情報を、他のプレゼンスサーバ２へ登録するように動作する。
【００６７】
（Ｓ４１０）ウォッチャ４が、プレゼンティティ３のプレゼンス情報に対するSUBSCRIBEメッセージを、負荷分散サーバ１へ送信したとする。負荷分散サーバ１は、新たにプレゼンティティ３のプレゼンス情報を持つプレゼンスサーバを追加する。まず、プレゼンティティ３のプレゼンス情報を取得するため、負荷分散サーバ１は、Expires（有効期間）ヘッダを０に設定したプレゼンティティ３のプレゼンス情報に対するSUBSCRIBEメッセージを、プレゼンスサーバ２へ送信する。これは、有効期間の更新を意味しない。
以下は、この場合のSUBSCRIBEメッセージのフォーマット例である。
SUBSCRIBE sip:presentity@example.com SIP/2.0  ［PRS-URI］
Via SIP/2.0/UDP
Event:                                        ［イベント名］
To:<sip:presentity@example.com>               ［PRS-URI］
From:<sip:load-balance@example.com>           ［負荷分散サーバのSIP URI］
Expires: 0                                    ［購読の有効期間＝０］
Call-ID:
CSeq: 1 SUBSCRIBE
【００６８】
（Ｓ４１１）これに対し、プレゼンスサーバ２は、200OKメッセージを負荷分散サーバ１へ返信する。
【００６９】
（Ｓ４１２）次に、プレゼンスサーバ２は、NOTIFYメッセージを、負荷分散サーバ１へ送信する。NOTIFYメッセージは、プレゼンティティ３のプレゼンス情報を含む。
以下は、この場合のNOTIFYメッセージのフォーマット例である。
NOTIFY sip:load-balance@example.com SIP/2.0   ［負荷分散サーバのSIP URI］
Via SIP/2.0/UDP
Event:                                        ［イベント名］
To:<sip:load-balance@example.com>             ［負荷分散サーバのSIP URI］
From:<sip:presentity@example.com>             ［PRS-URI］
Call-ID:
CSeq: 1 NOTIFY
Subscription-Status: terminated; expires=timeout［購読の状態、有効期間］
<中略>
<プレゼンス情報>
【００７０】
（Ｓ４１３）NOTIFYメッセージを受信した負荷分散サーバ１は、そのプレゼンス情報を取得することができる。そして、200OKメッセージを、プレゼンスサーバ２へ返信する。
【００７１】
（Ｓ４１４）ここで、負荷分散サーバ１は、そのプレゼンス情報を登録すべき別のプレゼンスサーバＰを選択する。このプレゼンスサーバＰは、そのSUBSCRIBE受信率が所定閾値Ｔｓ以下であることを要する。そして、負荷分散サーバ１は、そのプレゼンス情報を含むPUBLISH(INITIAL)メッセージを、選択されたプレゼンスサーバＰへ送信する。これにより、処理負荷の小さいプレゼンスサーバＰに対して、そのプレゼンス情報を登録することができる。尚、登録の有効期間は、パブリッシュ用データベースから、該当するプレゼンス情報を持つ他のプレゼンスサーバと同じ有効期間を設定する。
以下は、この場合のPUBLISHメッセージのフォーマット例である。
PUBLISH sip:presentity@example.com SIP/2.0    ［PRS-URI］
Via SIP/2.0/UDP
Event:                                        ［イベント名］
To:<sip:presentity@example.com>               ［PRS-URI］
From:<sip:presentity@example.com>             ［PRS-URI］
Expires:                                      ［登録の有効期間］
Call-ID:
CSeq: 1 PUBLISH
【００７２】
（Ｓ４１５）これに対し、プレゼンスサーバＰは、200OKメッセージを負荷分散サーバ１へ返信する。
【００７３】
（Ｓ４１６）次に、負荷分散サーバ１は、プレゼンスサーバＰから200OKメッセージを受信すると、ＳＩＰの302 Moved Temporarilyをウォッチャ４へ返信する。302 Moved
Temporarilyは、新たにプレゼンス情報を登録したプレゼンスサーバＰのSIP-URIを含む。
【００７４】
（Ｓ４１７）302 Moved Temporarilyを受信したウォッチャ４は、リダイレクトによって、302 Moved Temporarilyに含まれるプレゼンスサーバＰのSIP-URIへ向けて、SUBSCRIBEメッセージを送信する。即ち、SUBSCRIBEメッセージは、負荷分散サーバ１を介することなく、直接的にプレゼンスサーバへ送信される。
【００７５】
（Ｓ４１８）プレゼンスサーバＰは、ウォッチャ４からSUBSCRIBEメッセージを受信すると、既存のプレゼンスサーバと同様に、200OKメッセージをウォッチャ４へ返信する。プレゼンスサーバＰは、既に、負荷分散サーバ１からPUBLISH(INITIAL)メッセージを受信しており、そのプレゼンス情報を登録している。
【００７６】
（Ｓ４１９）次に、プレゼンスサーバＰは、NOTIFYメッセージを、ウォッチャ４へ送信する。NOTIFYメッセージは、プレゼンティティ３のプレゼンス情報を含む。
【００７７】
（Ｓ４２０）NOTIFYメッセージを受信したウォッチャ４は、そのプレゼンス情報を取得する。そして、200OKメッセージを、プレゼンスサーバ２へ返信する。
【００７８】
図４によれば、ある特定のプレゼンス情報に対して多くのSUBSCRIBEメッセージが集中して送信される場合であっても、そのプレゼンス情報を登録するプレゼンスサーバの数を増加させることにより、プレゼンス情報の負荷を分散管理することができる。
【００７９】
図５は、本発明における第２のシーケンス図である。
【００８０】
PUBLISHメッセージは、新規登録のためのINITIALと、プレゼンス情報の登録における有効期限の更新のためのREFRESHと、プレゼンス情報の内容変更のためのMODIFYとに分類される。PUBLISH(REFRESH／MODIFY)メッセージには、SIP-If-Matchヘッダが付加されており、PUBLISH(INITIAL)メッセージには、SIP-If-Matchヘッダが付加されていない。PUBLISH(REFRESH／MODIFY)メッセージは、そのSIP-If-Matchヘッダに、INITIAL（初回）登録時に対する200OKメッセージのSIP-ETagヘッダフィールドのエンティティタグを格納する。これによって、プレゼンスサーバ２及び負荷分散サーバ１は、登録済みのプレゼンス情報に対するPUBLISHメッセージであると認識することができる。
【００８１】
「SIP-If-Match」ヘッダは、以前に発行したイベントステートに関するPUBLISHレスポンス(200OK)で指定されたSIP-ETagヘッダ値を指定する。これは、以前に発行されたイベントステートを更新する場合に、PUBLISHメッセージによって更新、修正又は削除させる特定のイベントステートを識別するものである。
【００８２】
「SIP-ETag」ヘッダは、PUBLISHメッセージを受信した場合に、ＥＳＣ(Event State Compositor)が生成したエンティティタグ（リクエスト識別子）である。
【００８３】
図５によれば、PUBLISH(REFRESH/MODIFY)メッセージを受信した場合のシーケンスについて表している。
【００８４】
（Ｓ５０１）プレゼンティティ３は、既に登録したプレゼンス情報の再登録及び内容変更について、PUBLISH(REFRESH/MODIFY)メッセージを負荷分散サーバ１へ送信する。負荷分散サーバ１は、そのプレゼンス情報を既に登録しているプレゼンスサーバＰを検索し、そのプレゼンスサーバＰへそのPUBLISH(REFRESH/MODIFY)メッセージを送信する。
【００８５】
（Ｓ５０２）これに対し、プレゼンスサーバＰは、プレゼンティティ３のプレゼンス情報の再登録及び内容変更をする。そして、プレゼンスサーバＰは、200OKメッセージを負荷分散サーバ１へ返信する。
【００８６】
（Ｓ５０３）このとき、負荷分散サーバ１は、そのプレゼンス情報を既に登録しているプレゼンスサーバＰにおけるSUBSCRIBE受信率を検索する。SUBSCRIBE受信率が、所定閾値Ｔｓ以下でない場合、即ち、そのプレゼンスサーバＰの処理負荷が高い場合には、他のプレゼンスサーバ２へ、そのプレゼンス情報を登録する。
【００８７】
ここで、プレゼンスサーバＰのSUBSCRIBE受信率が、所定閾値Ｔｓ以下でないとする。このとき、負荷分散サーバ１は、そのプレゼンス情報を登録すべき別のプレゼンスサーバＰnewを選択する。このプレゼンスサーバＰnewは、そのSUBSCRIBE受信率が所定閾値Ｔｓ以下であることを要する。そして、負荷分散サーバ１は、そのプレゼンス情報を含むPUBLISH(INITIAL)メッセージを、選択されたプレゼンスサーバＰnewへ送信する。この際、SIP-If-Matchヘッダは含めないことに注意されたい。これにより、処理負荷の小さいプレゼンスサーバＰnewに対して、そのプレゼンス情報を登録することができる。
【００８８】
（Ｓ５０４）プレゼンスサーバＰnewは、200OKメッセージを負荷分散サーバ１へ返信する。また、負荷分散サーバ１は、その200OKメッセージのSIP-ETagヘッダフィールドのエンティティタグを、サブスクライブ用データベースに格納する。そして、200OKメッセージは、プレゼンティティ３へ返信される。このプレゼンティティ３は、代表エンティティタグをSIP-If-Matchヘッダに付与したPUBLISH(REFRESH/MODIFY)メッセージの送信元である。代表エンティティタグは、あるプレゼンス情報に対して最初にPUBLISHメッセージを受信したプレゼンスサーバからの200OKメッセージに含まれるSIP-ETagヘッダフィールドのエンティティタグを用いてもよい。例えば、この場合は、プレゼンスサーバＰの200OKメッセージが該当する。また、負荷分散サーバ１が独自に生成してもよい。
【００８９】
（Ｓ５０５）その後、プレゼンスサーバ２に対して、そのプレゼンス情報の購読を要求するSUBSCRIBEメッセージの数が減少してきたとする。そのプレゼンスサーバ２に対する購読の有効時間の最大値は、負荷分散サーバ１によって監視されている。
【００９０】
SUBSCRIBEメッセージの数が減少することによって、サブスクライブ用データベース１０３に記憶されたSUBSCRIBEの有効期間が、現在時刻を過ぎる場合がある。これは、プレゼンスサーバ２においてそのプレゼンス情報に対する有効な購読がないことを意味する。このとき、負荷分散サーバ１は、SUBSCRIBEの有効期間が現在時刻を過ぎたプレゼンスサーバ２について、エントリリストから削除する。これにより、負荷分散サーバ１は、その後、プレゼンティティ３からのPUBLISH(REFRESH/MODIFY)メッセージ及びウォッチャ４からのSUBSCRIBEメッセージを受信しても、エントリリストから削除されたプレゼンスサーバ２へ、メッセージを送信することはない。但し、負荷分散サーバ１は、各プレゼンス情報について、最低１つはそれを登録するプレゼンスサーバを残すものとする。
【００９１】
（Ｓ５０６）プレゼンティティ３は、既に登録したプレゼンス情報の再登録及び内容変更について、PUBLISH(REFRESH/MODIFY)メッセージを負荷分散サーバ１へ送信する。負荷分散サーバ１は、そのプレゼンス情報を既に登録しているプレゼンスサーバＰを検索し、そのプレゼンスサーバＰへそのPUBLISH(REFRESH/MODIFY)メッセージを送信する。
【００９２】
（Ｓ５０７）これに対し、プレゼンスサーバＰは、そのプレゼンス情報を登録する。そして、プレゼンスサーバＰは、200OKメッセージを負荷分散サーバ１へ返信する。また、負荷分散サーバ１は、その200OKメッセージを、PUBLISH(REFRESH/MODIFY)メッセージを送信したプレゼンティティ３へ返信する。
【００９３】
ここで、PUBLISHメッセージ及び200OKメッセージの送受信方法について説明する。ここで、ＭＡＣ(Media Access Control)アドレス変換によるＤＳＲを用いる場合と、ＩＰアドレス変換ＮＡＴを用いる場合とがある。
【００９４】
［ＭＡＣアドレス変換によるＤＳＲを用いる場合］
負荷分散サーバ１及びプレゼンスサーバ２は、同一リンク上に接続される。
（１）負荷分散サーバ１が、プレゼンスサーバ２へ送信するPUBLISHメッセージ
PUBLISHメッセージの送信先ＭＡＣアドレス：プレゼンスサーバ２のＭＡＣアドレス
送信先ＩＰアドレス：負荷分散サーバ１のＩＰアドレス
プレゼンスサーバ２のループバックインタフェースには、負荷分散サーバ１と同じＩＰアドレスが付与されている。従って、プレゼンスサーバ２は、このPUBLISHメッセージを受信することができる。
（２）プレゼンスサーバ２が、プレゼンティティ３へ送信する200OKメッセージ
200OKメッセージの送信元ＭＡＣアドレス：プレゼンスサーバＰのＭＡＣアドレス
送信元ＩＰアドレス：負荷分散サーバ１のＩＰアドレス
送信先ＩＰアドレスは、プレゼンティティ（又はそのプロキシサーバ）とするために、200OKメッセージは、プレゼンティティ３へ直接到達する。
【００９５】
［ＩＰアドレス変換によるＮＡＴを用いる場合］
（１）負荷分散サーバ１が、プレゼンスサーバ２へ送信するPUBLISHメッセージ
ウォッチャから送信されるSUBSCRIBEメッセージの送信先ＩＰアドレス：
プレゼンスサーバ２のＩＰアドレス
（２）プレゼンスサーバ２が、プレゼンティティ３へ送信する200OKメッセージ
負荷分散サーバ１は、プレゼンスサーバ２のデフォルト経路、又はプレゼンスサーバ２におけるPUBLISHメッセージに対する200OKメッセージのSIPプロキシとして動作する。
負荷分散サーバ１は、プレゼンスサーバから受信した200OKメッセージを、プレゼンティティへ送信する場合、200OKメッセージの送信元ＩＰアドレスを、負荷分散サーバのＩＰアドレスに変換する。
【００９６】
次に、SUBSCRIBEメッセージ及びNOTIFYメッセージの送受信方法について説明する。
【００９７】
［ＭＡＣアドレス変換によるＤＳＲを用いる場合］
（１）SUBSCRIBEのダイアログが生成されていない場合、302 Moved Temporarilyの場合と同様の方法で、SUBSCRIBEメッセージを送信するプレゼンスサーバ２を決定する。
（２）SUBSCRIBEのダイアログが生成されている場合、ダイアログに対応するプレゼンスサーバ２をサブスクライブ用データベース１０３（表４参照）から検索する。
（３）負荷分散サーバ１が、プレゼンスサーバ２へ送信するSUBSCRIBEメッセージ
SUBSCRIBEメッセージの送信先ＭＡＣアドレス：プレゼンスサーバＰのＭＡＣアドレス
送信先ＩＰアドレス：負荷分散サーバ１のＩＰアドレス
プレゼンスサーバ２のループバックインタフェースには、負荷分散サーバと同じＩＰアドレスが付与される。そのために、負荷分散サーバは、SUBSCRIBEメッセージを受信することができる。
（４）負荷分散サーバ１は、プレゼンスサーバ２へSUBSCRIBEメッセージを送信した後、ダイアログの情報をサブスクライブ用データベース１０３に記録する。
（５）プレゼンスサーバＰが、ウォッチャへ送信する200OKメッセージ
200OKメッセージの送信元ＭＡＣアドレス：プレゼンスサーバ２のＭＡＣアドレス
送信元ＩＰアドレス：負荷分散サーバ１のＩＰアドレス
送信先ＩＰアドレスは、ウォッチャ（又はそのプロキシサーバ）とするため、200OKメッセージは、ウォッチャへ直接到達する。
【００９８】
［ＩＰアドレス変換ＮＡＴを用いる場合］
（１）SUBSCRIBEのダイアログが生成されていない場合、302 Moved Temporarilyの場合と同様の方法で、SUBSCRIBEメッセージを送信するプレゼンスサーバ２を決定する。
（２）SUBSCRIBEのダイアログが生成されている場合、ダイアログに対応するプレゼンスサーバ２をサブスクライブ用データベース１０３（表４参照）から検索する。
（３）負荷分散サーバ１が、プレゼンスサーバＰへ送信するSUBSCRIBEメッセージ
SUBSCRIBEメッセージの送信先ＩＰアドレス：
ダイアログに対応したプレゼンスサーバＰのＩＰアドレス
（４）プレゼンスサーバＰが、ウォッチャへ送信する200OKメッセージ
負荷分散サーバ１は、プレゼンスサーバＰのデフォルト経路として動作し、200OKメッセージを受信した際に、送信元IPアドレスを負荷分散サーバ１のものに変換してウォッチャへ送信する。
【００９９】
図６は、本発明におけるプレゼンスサーバ選択部のフローチャートである。
【０１００】
プレゼンスサーバ選択部には、PRS-URI及びEventを入力する。
（Ｓ６０１）最初に、Numフラグを０に設定する。
【０１０１】
（Ｓ６０２）ハッシュ値Hash(PRS)を導出する。ハッシュ関数への引数は、例えば以下のようなものである。
Hash(PRS)＝Hash（PRS-URI／Event／Num）
”／”は区切り文字
【０１０２】
ここで、プレゼンスサーバリスト蓄積部１０１を検索する。プレゼンスサーバＵＲＩ(SIP-URI)に対応付けて、そのSIP-URIを引数とするハッシュ値Hash(SIP-URI)が記録されている。
【０１０３】
（Ｓ６０３）次に、Hash(PRS)に最も近いHash(SIP-URI)を有するプレゼンスサーバを検索する。検索されたプレゼンスサーバを、プレゼンスサーバＰと設定する。
【０１０４】
（Ｓ６０４）次に、負荷分散サーバ１は、サブスクライブ用データベース１０３に記録されたプレゼンスサーバＰにおける、SUBSCRIBE受信率（単位時間当たりの総SUBSCRIBE数）が所定閾値Ｔｓ以下か否かを判定する。ここで、所定閾値Ｔｓよりも高い場合は、そのプレゼンスサーバＰに対してSUBSCRIBEメッセージが集中しているために、他のプレゼンスサーバを選択する必要があると考える。
【０１０５】
（Ｓ６０５）SUBSCRIBE受信率が所定閾値Ｔｓより高い場合、Numを１増分する。これによって、次に算出されるハッシュ値Hash(PRS)が異なる値となり、他のプレゼンスサーバＰが選択されることとなる。このように、SUBSCRIBE受信率が所定閾値Ｔｓ以下であるプレゼンスサーバＰが検出されるまで、Numを１増分しつつ繰り返す。
【０１０６】
最終的に、SUBSCRIBE受信率が所定閾値Ｔｓ以下となるプレゼンスサーバＰが選択さることとなる。
【０１０７】
図７は、本発明におけるエントリ検索部のフローチャートである。
【０１０８】
エントリ検索部には、PRS-URI、Event及びSIP-If-Matchヘッダフィールドのエンティティタグを入力する。
【０１０９】
（Ｓ７０１）最初に、パブリッシュ用データベース１０２から、PRS-URI、Event及びエンティティタグに一致するエントリを検索する。このとき、現在時刻が、そのエントリに含まれる有効期間内であることも要する。尚、SIP-If-Matchヘッダフィールドのエンティティタグは、エントリの代表エンティティタグと一致していることを要する。
【０１１０】
（Ｓ７０２）パブリッシュ用データベース１０２から、対象となるエントリが検索されなかった場合、402 Conditional Request Failedをプレゼンティティ３へ返信する。
【０１１１】
（Ｓ７０３）パブリッシュ用データベース１０２によって、対象となるエントリが検索された場合、そのエントリのエントリリストに含まれるプレゼンスサーバの中で、最もSUBSCRIBE受信率が少ないプレゼンスサーバＰを、サブスクライブ用データベース１０３を用いて検索する。
【０１１２】
図８は、PUBLISHメッセージを受信した場合における負荷分散サーバのフローチャートである。
【０１１３】
（Ｓ８０１）受信したPUBLISHメッセージが、INITIALであるか、又はREFRESH／MODIFYであるかを判定する。SIP-If-Matchヘッダが無いPUBLISHメッセージは、INITIALと判定される。
【０１１４】
（Ｓ８０２）PUBLISH(INITIAL)メッセージである場合、そのプレゼンス情報は未登録であるので、プレゼンスサーバ選択処理（図６参照）によって、プレゼンスサーバＰを選択する。プレゼンスサーバＰによれば、SUBSCRIBE受信率は所定閾値Ｔｓ以下である。
【０１１５】
（Ｓ８０３）そのプレゼンスサーバＰへ、PUBLISH(INITIAL)メッセージを送信する。
【０１１６】
（Ｓ８０４）そして、負荷分散サーバ１は、プレゼンスサーバＰからの200OKメッセージの受信を待つ。
【０１１７】
（Ｓ８０５）プレゼンスサーバＰから200OKメッセージを受信すると、負荷分散サーバ１は、プレゼンティティ３へ200OKメッセージを返信する。
【０１１８】
（Ｓ８０６）これによって、負荷分散サーバ１は、プレゼンスサーバＰに、プレゼンティティのプレゼンス情報が登録されたと認識する。このとき、負荷分散サーバ１のパブリッシュ用データベース１０２において、そのPRS-URI及びEventのエントリを検索する。そして、そのエントリのエントリリストの中に、そのプレゼンスサーバＰのSIP-URIと、200OKメッセージのSIP-ETagヘッダフィールドに含まれるエンティティタグとを記録する。
【０１１９】
また、現在時刻に、200OKメッセージのExpiresヘッダフィールドの値を加えた値が、有効期間（＝初期値０）よりも大きい場合、その値を有効期間に入力する。また、代表エンティティタグには、プレゼンティティへ送信した200OKメッセージのExpiresヘッダフィールドの値を入力する。
【０１２０】
（Ｓ８１２）PUBLISH(REFRESH／MODIFY)メッセージである場合、エントリ検索処理（図７参照）によって、プレゼンスサーバＰを選択する。
【０１２１】
（Ｓ８１３）次に、サブスクライブ用データベース１０３に記録されたプレゼンスサーバＰにおける、SUBSCRIBE受信率が所定閾値Ｔｓ以下か否かを判定する。
【０１２２】
（Ｓ８１４）プレゼンスサーバＰのSUBSCRIBE受信率が所定閾値Ｔｓ以下でない場合、即ち、プレゼンスサーバＰにSUBSCRIBEメッセージが集中して受信されている場合、プレゼンスサーバ選択処理（図６参照）をする。これによって、追加プレゼンスサーバＰnewが選択される。
【０１２３】
（Ｓ８１５）パブリッシュ用データベース１０２及びサブスクライブ用データベース１０３について、当該プレゼンス情報に基づくエントリのエントリリストに、追加プレゼンスサーバＰnewの識別子(SIP-URI)を追加する。このとき、エンティティタグは空である。
【０１２４】
（Ｓ８１６）追加プレゼンスサーバＰnewへ、PUBLISH(INITIAL)メッセージを送信する。そのPUBLISHメッセージのSIP-If-Matchヘッダは、削除する。
【０１２５】
（Ｓ８１７）Ｓ８１３によってプレゼンスサーバＰにおけるSUBSCRIBE受信率が所定閾値Ｔｓ以下である場合、又は、追加プレゼンスサーバＰnewが選択された場合、パブリッシュ用データベース１０２を用いて、当該プレゼンス情報に基づくエントリのエントリリスト内に記録された全てのSIP-URIへ、即ち、全てのプレゼンスサーバへ、PUBLISHメッセージを送信する。但し、パブリッシュ用データベース１０２から、プレゼンスサーバ毎に対応したエンティティタグを検索し、そのエンティティタグを、そのPUBLISHメッセージのSIP-If-Matchヘッダフィールドに格納する。
【０１２６】
（Ｓ８１８）いずれか１つのプレゼンスサーバからの200OKメッセージの受信を待つ。
【０１２７】
（Ｓ８１９）いずれか１つのプレゼンスサーバから、200OKメッセージを受信した場合、その200OKメッセージを、プレゼンティティ３へ返信する。このとき、200OKメッセージのSIP-ETagヘッダフィールドには、代表エンティティタグを格納する。
【０１２８】
（Ｓ８２０）最後に、パブリッシュ用データベース１０２及びサブスクライブ用データベース１０３に対して、PRS-URI及びEventに基づいて、プレゼンスサーバURIに該当する有効期間を更新する。これは、現在時刻に、200OKメッセージのExpiresヘッダフィールドの値を加えたものである。また、追加プレゼンスサーバＰnewのエンティティタグには、追加プレゼンスサーバＰnewから受信した200OKメッセージに含まれるSIP-ETagヘッダフィールドのエンティティタグを格納する。
【０１２９】
図９は、SUBSCRIBEメッセージを受信した場合における負荷分散サーバのフローチャートである。
【０１３０】
負荷分散サーバ１は、ウォッチャ４から、プレゼンス情報を購読するためのSUBSCRIBEメッセージを受信する。
【０１３１】
（Ｓ９０１）SUBSCRIBEメッセージに含まれるPRS-URI及びEventに基づいて、エントリ検索処理（図７参照）によって、プレゼンスサーバＰを検索する。
【０１３２】
（Ｓ９０２）検索されたプレゼンスサーバＰについて、SUBSCRIBE受信率が所定閾値Ｔｓ以下であるか否かを判定する。
【０１３３】
（Ｓ９０３）検索されたプレゼンスサーバＰについて、SUBSCRIBE受信率が所定閾値Ｔｓよりも高い場合、そのプレゼンス情報を保持するプレゼンスサーバを追加し、そのプレゼンス情報に対する負荷を分散させるように動作する。即ち、プレゼンスサーバＰに対してSUBSCRIBEメッセージが集中して受信されている場合、追加プレゼンスサーバを選択する。ここでは、プレゼンスサーバ選択処理（図６参照）がなされる。これによって、追加プレゼンスサーバＰnewが選択される。
【０１３４】
（Ｓ９０４）追加プレゼンスサーバＰnewへ、当該プレゼンス情報を含むPUBLISH(INITIAL)メッセージを送信する。このとき、図４のＳ４１０〜Ｓ４１４のように、プレゼンスＰへSUBSCRIBEメッセージ(Expires＝０)を送信することも好ましい。これによって、ウォッチャ４からのPUBLISH(REFRESH／MODIFY)を受信すること待たずに、受信されるNOTIFYメッセージのボディ部に含まれるプレゼンス情報を取得することができる。
【０１３５】
また、負荷分散サーバ１が、各代表エンティティタグに対応するプレゼンス情報について、ウォッチャ４から最後に受信したPUBLISHメッセージを保持しておくものであってもよい。このとき、そのPUBLISHメッセージから、SIP-If-Matchヘッダを削除し、INITIALとする。また、Expiresヘッダフィールドの値には、パブリッシュ用データベース１０２における有効期間から、現在の時間を差し引いた値を格納する。
【０１３６】
（Ｓ９０５）追加プレゼンスサーバＰnewからの200OKメッセージの受信を待つ。
【０１３７】
（Ｓ９０６）追加プレゼンスサーバＰnewから200OKメッセージを受信すると、パブリッシュ用データベース１１２及びサブスクライブ用データベース１０３に対して、PRS-URI及びEventに基づくエントリのエントリリストに、追加プレゼンスサーバＰnewのSIP-URIを追加する。また、200OKメッセージのSIP-ETagヘッダフィールドのエンティティタグも追加する。
【０１３８】
（Ｓ９０７）検索されたプレゼンスサーバＰについて、SUBSCRIBE受信率が所定閾値Ｔｓ以下である場合、又は、追加プレゼンスサーバＰnewを追加した場合、ウォッチャ４へ、プレゼンスサーバＰ又はＰnewに対する302 Moved Temporarilyを送信する。これによって、ウォッチャ４に対して、プレゼンスサーバＰ又はＰnewへのリダイレクトを促す。
【０１３９】
（Ｓ９０８）サブスクライブ用データベース１０３に対して、SUBSCRIBE受信率を更新する。また、プレゼンスサーバＰ又はＰnewにおける有効期間も更新する。現在時刻に、SUBSCRIBEメッセージのExpiresヘッダフィールドの値を加えた時刻が、有効期間（＝初期値０）よりも大きい場合、その時刻を有効期間として入力する。
【０１４０】
以上、詳細に説明したように、本発明の負荷分散サーバ及びプログラムによれば、ある特定のプレゼンス情報に対して多くのSUBSCRIBEメッセージが集中して送信される場合であっても、そのプレゼンス情報を登録するプレゼンスサーバの数を増加させることにより、プレゼンス情報の負荷を分散管理することができる。
【０１４１】
前述した本発明の種々の実施形態において、本発明の技術思想及び見地の範囲の種々の変更、修正及び省略は、当業者によれば容易に行うことができる。前述の説明はあくまで例であって、何ら制約しようとするものではない。本発明は、特許請求の範囲及びその均等物として限定するものにのみ制約される。
【図面の簡単な説明】
【０１４２】
【図１】従来技術におけるプレゼンスシステムの構成図である。
【図２】本発明におけるシステム構成図である。
【図３】本発明における負荷分散サーバの機能構成図である。
【図４】本発明における第１のシーケンス図である。
【図５】本発明における第２のシーケンス図である。
【図６】本発明におけるプレゼンスサーバ選択部のフローチャートである。
【図７】本発明におけるエントリ検索部のフローチャートである。
【図８】PUBLISHメッセージを受信した場合における負荷分散サーバのフローチャートである。
【図９】SUBSCRIBEメッセージを受信した場合における負荷分散サーバのフローチャートである。
【符号の説明】
【０１４３】
１  負荷分散サーバ
１０１  プレゼンスサーバリスト蓄積部
１０２  パブリッシュ用データベース
１０３  サブスクライブ用データベース
１０４  プレゼンスサーバ選択部
１０５  エントリ検索部
１０６  SUBSCRIBE受信率判定部
１０７  メッセージ送受信制御部
１０８  エントリ更新部
１０９  通信インタフェース部
２  プレゼンスサーバ
３  プレゼンティティ
４  ウォッチャ
【図１】
0004753316.tif 000005
【図２】
0004753316.tif 000006
【図３】
0004753316.tif 000007
【図４】
0004753316.tif 000008
【図５】
0004753316.tif 000009
【図６】
0004753316.tif 000010
【図７】
0004753316.tif 000011
【図８】
0004753316.tif 000012
【図９】
0004753316.tif 000013