(57)【要約】【課題】マルチキャストアドレスを効率的に割り当てる中継装置を提供する。【解決手段】プレゼンス情報の購読を要求する要求メッセージをウォッチャーから受信するリクエスト受信部１１１と、要求メッセージを受信したウォッチャーを、予め定められた複数のネットワークの範囲のいずれに属するかによって複数のグループに分類する制御部１１５と、グループごとに予め定められた方法で、グループをマルチキャストグループとするマルチキャストアドレスを割り当てるアドレス割当部１１６と、要求メッセージによって購読が要求されたプレゼンス情報を通知する通知メッセージをプレゼンスサーバから受信するリクエスト受信部１２１と、グループごとに、割り当てられたマルチキャストアドレスを宛先アドレスとして通知メッセージを送信するマルチキャスト送信部１１７と、を備えた。【選択図】        図５
2009200796.tif 000002
【特許請求の範囲】
【請求項１】
複数の通信装置と、プレゼンス情報を管理する管理装置との間で送受信されるメッセージを中継する中継装置であって、
前記プレゼンス情報の購読を要求する要求メッセージを前記通信装置から受信する要求受信部と、
前記要求メッセージを受信した前記通信装置を、予め定められた複数のネットワークの範囲のいずれに属するかによって複数のグループに分類する分類部と、
前記グループごとに予め定められた方法で、前記グループをマルチキャストグループとするマルチキャストアドレスを割り当てる割当部と、
前記要求メッセージによって購読が要求された前記プレゼンス情報を通知する通知メッセージを前記管理装置から受信する通知受信部と、
前記グループごとに、割り当てられた前記マルチキャストアドレスを宛先アドレスとして前記通知メッセージを送信する通知送信部と、
を備えたことを特徴とする中継装置。
【請求項２】
前記分類部は、前記要求メッセージを受信した前記通信装置を、前記中継装置と同一リンクに属するか否かによって前記グループに分類すること、
を特徴とする請求項１に記載の中継装置。
【請求項３】
前記分類部は、前記要求メッセージを受信した前記通信装置を、前記中継装置と同一のネットワークの範囲として予め定められた同一ネットワークに属するか否かによって前記グループに分類すること、
を特徴とする請求項１に記載の中継装置。
【請求項４】
前記分類部は、前記要求メッセージに含まれる前記通信装置のアドレス情報が、前記ネットワークの範囲それぞれに対応するアドレス情報の範囲のいずれに含まれるかによって、前記要求メッセージを受信した前記通信装置を前記グループに分類すること、
を特徴とする請求項１に記載の中継装置。
【請求項５】
前記分類部は、前記要求メッセージを転送した複数の前記通信装置のアドレス情報が前記要求メッセージに含まれる場合に、最後に前記要求メッセージを転送した前記通信装置のアドレス情報を前記要求メッセージから取得し、取得したアドレス情報が、前記ネットワークの範囲それぞれに対応するアドレス情報の範囲のいずれに含まれるかによって、前記要求メッセージを受信した前記通信装置を前記グループに分類すること、
を特徴とする請求項４に記載の中継装置。
【請求項６】
前記通信装置は、他の前記通信装置と前記管理装置との間で送受信されるメッセージを中継する外部中継装置を含み、
前記分類部は、前記要求メッセージを中継した複数の前記外部中継装置の前記アドレス情報が前記要求メッセージに含まれる場合に、最後に前記要求メッセージを転送した前記外部中継装置の前記アドレス情報を前記要求メッセージから取得し、取得したアドレス情報が、前記ネットワークの範囲それぞれに対応するアドレス情報の範囲のいずれに含まれるかによって、前記要求メッセージを受信した前記外部中継装置を前記グループに分類すること、
を特徴とする請求項５に記載の中継装置。
【請求項７】
前記要求受信部は、前記プレゼンス情報の提供元を識別する識別情報と前記プレゼンス情報の種類とを含む前記要求メッセージを受信し、
前記分類部は、前記要求メッセージを受信した前記通信装置を、前記識別情報および前記種類ごとに、前記ネットワークの範囲のいずれに属するかによって前記グループに分類すること、
を特徴とする請求項１に記載の中継装置。
【請求項８】
複数の通信装置と、プレゼンス情報を管理する管理装置との間で送受信されるメッセージを中継する中継装置で実行される中継方法であって、
要求受信部が、前記プレゼンス情報の購読を要求する要求メッセージを前記通信装置から受信する要求受信ステップと、
分類部が、前記要求メッセージを受信した前記通信装置を、予め定められた複数のネットワークの範囲のいずれに属するかによって複数のグループに分類する分類ステップと、
割当部が、前記グループごとに予め定められた方法で、前記グループをマルチキャストグループとするマルチキャストアドレスを割り当てる割当ステップと、
通知受信部が、前記要求メッセージによって購読が要求された前記プレゼンス情報を通知する通知メッセージを前記管理装置から受信する通知受信ステップと、
通知送信部が、前記グループごとに、割り当てられた前記マルチキャストアドレスを宛先アドレスとして前記通知メッセージを送信する通知送信ステップと、
を備えたことを特徴とする中継方法。
【請求項９】
複数の通信装置と、プレゼンス情報を管理する管理装置との間で送受信されるメッセージを中継する中継装置で実行される中継プログラムであって、
前記プレゼンス情報の購読を要求する要求メッセージを前記通信装置から受信する要求受信手順と、
前記要求メッセージを受信した前記通信装置を、予め定められた複数のネットワークの範囲のいずれに属するかによって複数のグループに分類する分類手順と、
前記グループごとに予め定められた方法で、前記グループをマルチキャストグループとするマルチキャストアドレスを割り当てる割当手順と、
前記要求メッセージによって購読が要求された前記プレゼンス情報を通知する通知メッセージを前記管理装置から受信する通知受信手順と、
前記グループごとに、割り当てられた前記マルチキャストアドレスを宛先アドレスとして前記通知メッセージを送信する通知送信手順と、
を前記中継装置に実行させる中継プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、プレゼンスサービスを提供するサーバとプレゼンス情報を購読するウォッチャーとの間で送受信されるメッセージを中継する装置、方法およびプログラムに関する。
【背景技術】
【０００２】
近年、通信装置間に介在し通信を制御・中継するシグナリング手順としてＳＩＰ（Session Initiation Protocol）が広く知られている。また、ＳＩＰを利用したサービスの一例として、プレゼンスサービスと呼ばれるサービスに関する技術が提案されている（非特許文献１、非特許文献２）。プレゼンスサービスは、「ウォッチャー」と呼ばれるノードが、「プレゼンティティ」と呼ばれるノードの状態を表すプレゼンス情報を監視可能とするサービスである。
【０００３】
ウォッチャーがプレゼンティティの状態を監視することを特に「購読」と呼ぶ。ウォッチャーは、プレゼンティティに対して「購読要求」（ＳＵＢＳＣＲＩＢＥリクエスト）を送信することによりプレゼンティティの状態を購読できる。プレゼンティティは、自身の状態が変化した際に、自身の状態を「通知」（ＮＯＴＩＦＹリクエスト）としてウォッチャーに送る。これにより、ウォッチャーはプレゼンティティの状態を逐一知ることができる。
【０００４】
プレゼンティティの持つ状態の種類は１つではなく、複数種類の状態を持つことができる。状態の種類を区別するものとして「イベントパッケージ」が用いられる。ウォッチャーは、プレゼンティティを識別するＳＩＰ  ＵＲＩと、プレゼンティティの状態のうち購読を希望する状態を表すイベントパッケージとの組を指定して購読要求を送信する。あるイベントパッケージで表される状態の種類に関する実際のプレゼンティティの状態を、特に「イベントステート」と呼ぶ。
【０００５】
プレゼンスサービスでは、一般にプレゼンティティの代理となるサーバとしてプレゼンスサーバが利用される。プレゼンスサーバは、複数のプレゼンティティの状態を保持し、プレゼンティティごとにウォッチャーからの購読要求を受け付ける。
【０００６】
通常、ウォッチャーとプレゼンスサーバとの間には複数のＳＩＰプロキシが存在する。ＳＩＰプロキシは、ＳＩＰメッセージを受信し、受信したＳＩＰメッセージを転送する宛先を決定し、決定した宛先にＳＩＰメッセージを転送する。複数のウォッチャーが同じプレゼンティティの同じイベントパッケージについて購読している場合、末端のウォッチャーとプレゼンスサーバとの間にはそれぞれ個別に購読と通知の関係が構築される。
【０００７】
また、通常、ＳＩＰプロキシは、複数のウォッチャーが同じプレゼンスサーバから同じプレゼンティティの同じイベントパッケージを購読していることを認識しない。すなわち、ＳＩＰプロキシは、同じプレゼンティティの同じイベントパッケージの購読要求であっても、ウォッチャーごとにプレゼンスサーバに転送する。このため、プレゼンスサーバは、同じプレゼンティティの同じイベントパッケージに関する通知であっても、購読を要求したウォッチャーそれぞれに対してイベントステートを通知する。また、ＳＩＰプロキシも同様に、購読を要求したウォッチャーの数だけＳＩＰメッセージを中継する。
【０００８】
しかし、同じイベントパッケージのイベントステートをウォッチャーの数だけ中継するのは非効率である。これを解消するため、ウォッチャーから購読要求を受信したＳＩＰプロキシが、ウォッチャーの代理としてプレゼンスサーバからイベントステートを購読する方法が知られている。この方法では、ＳＩＰプロキシは、プレゼンスサーバから通知されたイベントステートを、購読を代理するウォッチャーそれぞれに対して通知する。
【０００９】
さらに、ＳＩＰプロキシからウォッチャーへのイベントステートの通知にマルチキャストを用いることにより、さらなる効率化を図ることも可能となる。すなわち、まず同一プレゼンティティの同一イベントパッケージを購読するウォッチャーを１つのマルチキャストグループとしてマルチキャストアドレスを割り当てる。そして、イベントステートがプレゼンスサーバからＳＩＰプロキシに通知されると、ＳＩＰプロキシは、通知されたイベントステートに対応するマルチキャストグループにマルチキャストでイベントステートを通知するＮＯＴＩＦＹリクエストを送信する。なお、ＳＩＰプロキシは、購読要求であるＳＵＢＳＣＲＩＢＥリクエストの応答に含める方法などにより、予めマルチキャストアドレスをウォッチャーに通知しておく。
【００１０】
ＳＩＰプロキシは、マルチキャストアドレスの値を自由に決めることはできない。すなわち、ＳＩＰプロキシは、同じネットワーク上の他のサービスで利用しているマルチキャストアドレスと重ならないアドレスを割り当てる必要がある。そこで、ＳＩＰプロキシは、ＭＡＤＣＡＰ（Multicast Address Dynamic Client Allocation Protocol）、ＺＭＡＡＰ（ZeroConf Multicast Address Allocation Protocol）などのプロトコルを利用してマルチキャストアドレスを取得する。
【００１１】
ＭＡＤＣＡＰは、ネットワーク内のマルチキャストアドレス割り当てサーバからアドレスの割り当てを受ける方法を規定している。また、ＺＭＡＡＰは、同一リンク内の各ノード間で調整することにより、使用するマルチキャストアドレスの衝突を避ける方法を規定している。
【００１２】
【非特許文献１】A. B. Roach et al.、 "RFC 3265、Session Initiation Protocol （SIP）-Specific Event Notification"、[online]、June 2002、retrieved from the Internet: <URL: http://www.ietf.org/rfc/rfc3265.txt>
【非特許文献２】A. Niemi, Ed. et al.、 "RFC 3903、Session Initiation Protocol （SIP） Extension for Event State Publication"、[online]、June 2004、retrieved from the Internet: <URL: http://www.ietf.org/rfc/rfc3903.txt>
【発明の開示】
【発明が解決しようとする課題】
【００１３】
しかしながら、従来のＳＩＰプロキシでは、効率的にマルチキャストアドレスを割り当てられない場合があった。例えば、ＭＡＤＣＡＰを利用する場合、同じプレゼンティティの同じイベントパッケージを購読するすべてのウォッチャーが、購読を代理するＳＩＰプロキシと同一リンク内に存在する場合であっても、当該ＳＩＰプロキシは、当該リンクより広い範囲で使用可能なグローバルスコープのマルチキャストアドレスをマルチキャストアドレス割り当てサーバから割り当てることになる。
【００１４】
本来、このような場合は、同一リンク内でのみ有効なリンクローカルスコープを持つマルチキャストアドレスを割り当てれば十分である。リンクローカルスコープを用いることができれば、マルチキャストアドレス割り当てサーバを介してアドレスを割り当てる必要がなくなり、処理負荷が軽減する。
【００１５】
また、リンクローカルスコープを用いることができれば、マルチキャストアドレスを使用することによるマルチキャストルーティングの設定も必要なくなる。マルチキャストルーティングの設定とは、マルチキャストグループに属するノードを収容するルータから、マルチキャストの送信元までの経路を設定する手順である。プレゼンスサービスでは、同じ情報を購読するウォッチャーが時間経過と共に変化する。このため、ウォッチャーが変化するたびにマルチキャストアドレスの割り当てとマルチキャストルーティングの設定が必要になる。すなわち、グローバルスコープのマルチキャストアドレスを割り当てる場合は、マルチキャストアドレス割り当て処理とマルチキャストルーティングの設定処理の負荷が増大するという問題があった。
【００１６】
本発明は、上記に鑑みてなされたものであって、プレゼンス情報を中継するためのマルチキャストアドレスを効率的に割り当てることができる装置、方法およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１７】
上述した課題を解決し、目的を達成するために、本発明は、複数の通信装置と、プレゼンス情報を管理する管理装置との間で送受信されるメッセージを中継する中継装置であって、前記プレゼンス情報の購読を要求する要求メッセージを前記通信装置から受信する要求受信部と、前記要求メッセージを受信した前記通信装置を、予め定められた複数のネットワークの範囲のいずれに属するかによって複数のグループに分類する分類部と、前記グループごとに予め定められた方法で、前記グループをマルチキャストグループとするマルチキャストアドレスを割り当てる割当部と、前記要求メッセージによって購読が要求された前記プレゼンス情報を通知する通知メッセージを前記管理装置から受信する通知受信部と、前記グループごとに、割り当てられた前記マルチキャストアドレスを宛先アドレスとして前記通知メッセージを送信する通知送信部と、を備えたことを特徴とする。
【００１８】
また、本発明は、上記装置を実行することができる方法およびプログラムである。
【発明の効果】
【００１９】
本発明によれば、プレゼンス情報を中継するためのマルチキャストアドレスを効率的に割り当てることができるという効果を奏する。
【発明を実施するための最良の形態】
【００２０】
以下に添付図面を参照して、この発明にかかる装置、方法およびプログラムの最良な実施の形態を詳細に説明する。
【００２１】
本実施の形態にかかる中継装置は、プレゼンス情報（イベントステート）の購読を代理する対象となる各通信装置（ウォッチャー）を、自装置とのネットワークの接続形態に応じてグループに分類し、接続形態に応じた適切な方法でグループごとにマルチキャストアドレスを割り当てる。
【００２２】
ここで、プレゼンスサーバの概要について説明する。図１は、プレゼンスサーバの機能の概要を示す図である。
【００２３】
同図に示すように、ウォッチャー２０ａ〜２０ｃは、プレゼンスサーバ１０上で管理されているプレゼンティティのイベントステート（プレゼンティティ１、２）を購読する。なお、ウォッチャー２０ａ〜２０ｃは、同様の機能を備えるため、以下では単にウォッチャー２０という場合がある。
【００２４】
ＥＰＡ（Event Publication Agent）３０ａ、３０ｂは、プレゼンスサーバ１０上で管理されているプレゼンティティのイベントステートを更新する専用のノードである。ＥＰＡ３０ａ、３０ｂが、プレゼンスサーバ１０上で管理されているプレゼンティティのイベントステートを更新すると、プレゼンスサーバ１０は更新されたイベントステートを購読するすべてのウォッチャー２０に対して更新されたイベントステートを通知する。
【００２５】
次に、ＳＩＰプロキシ（以下、単にプロキシという）がイベントステートの購読を代理する処理の概要について説明する。図２は、プロキシによるイベントステートの購読代理処理の概要を示す図である。
【００２６】
上述のように、同じイベントパッケージのイベントステートを購読する複数のウォッチャー２０が存在する場合であっても、プレゼンスサーバ１０から通知されたイベントステートをプロキシがウォッチャー２０ごとに中継するのは非効率である。そこで、図２に示すように、ウォッチャー２０ａ〜２０ｃから購読要求を受信したプロキシ１００ａが、ウォッチャー２０ａ〜２０ｃの代理としてイベントステートを購読する。そして、プロキシ１００ａは、購読要求の送信元であるウォッチャー２０ａ〜２０ｃに対して、プレゼンスサーバ１０と同様に振る舞い、応答を返す。
【００２７】
なお、プロキシ１００ｂは、プロキシ１００ａとプレゼンスサーバ１０との間に設置され、両者間で送受信されるメッセージを中継する。プロキシ１００ｂがプロキシ１００ａと同様に、購読を代理する機能を備えていてもよい。以下では、プロキシ１００ａおよび１００ｂは同様の機能を備えるものとして説明する。また、プロキシ１００ａおよび１００ｂを、単にプロキシ１００と呼ぶ場合がある。
【００２８】
このように、プロキシ１００は、ＳＩＰの端末であるユーザエージェント（ＵＡ）から送信されたＳＩＰメッセージを中継するＳＩＰのプロキシサーバとしての機能を備えている。なお、プロキシ１００に、リダイレクトサーバおよびレジストラなどの他のＳＩＰサーバの機能を備えるように構成してもよい。
【００２９】
プロキシ１００ａは、同じプレゼンティティの同じイベントパッケージに対して複数のウォッチャー２０ａ〜２０ｃから購読要求が送信された場合でも、プレゼンスサーバ１０に対する購読要求は１回のみ行う。そして、プレゼンスサーバ１０からイベントステートを通知された場合、プロキシ１００ａは、同一プレゼンティティの同一イベントステートに対する購読を要求したすべてのウォッチャー２０ａ〜２０ｃに対して、イベントステートを通知する。
【００３０】
これにより、最終的に末端のすべてのウォッチャー２０ａ〜２０ｃに対して、所望のイベントステートを通知することができる。また、このような構成により、プロキシ１００ａとプレゼンスサーバ１０との間、および、プロキシ１００ａとプロキシ１００ｂとの間で送受信されるメッセージの個数を削減することができる。
【００３１】
次に、本実施の形態によるメッセージの中継方法の概要について図３および図４を用いて説明する。図３は、プロキシ１００によるウォッチャー２０のグループ化の一例を示す図である。
【００３２】
図３に示すように、プロキシ１００は、ウォッチャー２０ａ〜２０ｅを、同一プレゼンティティの同一イベントステートを購読するウォッチャー２０ごとにグループに分類する。同図に示すように、例えば、ウォッチャー２０ａおよび２０ｂが、プレゼンティティＡのイベントステートを購読するウォッチャーのグループとして分類されている。同様に、ウォッチャー２０ｃおよび２０ｄが、プレゼンティティＢのイベントステートを購読するウォッチャーのグループとして分類されている。さらに、ウォッチャー２０ｅが、プレゼンティティＣのイベントステートを購読するウォッチャーのグループとして分類されている。
【００３３】
そして、プロキシ１００は、グループごとに、グループに属するウォッチャー２０を、プロキシ１００とのネットワークの接続形態によって３つのグループにさらに分類する。具体的には、プロキシ１００は、プロキシ１００と同じリンクに属するウォッチャー２０、プロキシ１００とリンクは異なるが同じネットワークに属するウォッチャー２０、プロキシ１００とは異なるネットワークに属するウォッチャー２０にグループ分けする。
【００３４】
次に、プロキシ１００は、分類したグループごとにマルチキャストアドレスを割り当てる。図４は、マルチキャストアドレスの割り当ての一例を説明するための図である。
【００３５】
同図は、プロキシ１００ａが、ネットワーク５１１内の同一リンクに属するウォッチャー２０ａ、２０ｂ、２０ｃを１つのグループに分類した例を示している。また、同図は、プロキシ１００ｂが、同一リンクではないが同一ネットワーク５１２に属するウォッチャー２０ｆ、２０ｇ、２０ｈを１つのグループに分類した例を示している。なお、ウォッチャー２０ｉは、プロキシ１００ａ、１００ｂのいずれとも異なるネットワーク５１３に属するため、異なるネットワークに属するウォッチャーのグループに分類される。
【００３６】
このようにウォッチャー２０をグループに分類した後、プロキシ１００は、ネットワーク接続形態に応じて最適な方法で、グループごとにマルチキャストアドレスを割り当てる。すなわち、プロキシ１００は、プロキシ１００と同じリンクに属するウォッチャー２０のグループについて、グループに２つ以上のウォッチャー２０が含まれる場合には、同一リンク内でのアドレス割り当て方法によってマルチキャストアドレスを割り当てる。同一リンク内でのアドレス割り当て方法としては、例えば、ＺＭＡＡＰを適用できる。
【００３７】
例えば図４では、プロキシ１００ａが、同一リンクに属するウォッチャー２０ａ、２０ｂ、２０ｃに対して、ＺＭＡＡＰによってマルチキャストアドレスを割り当てることができる。
【００３８】
この方法でマルチキャストアドレスが割り当てられないグループは、プロキシ１００とリンクは異なるが同一ネットワークに属するウォッチャー２０のグループと併合する。なお、グループに１つのウォッチャー２０しか含まれない場合には、プロキシ１００は、当該ウォッチャー２０に対してユニキャストでイベントステートを通知する。
【００３９】
次に、プロキシ１００は、リンクは異なるが同じネットワークに属するウォッチャー２０のグループについて、グループに２つ以上のウォッチャー２０が含まれる場合には、マルチキャストアドレス割り当てサーバを利用してマルチキャストアドレスを割り当てる。マルチキャストアドレス割り当てサーバとしては、例えば、ＭＡＤＣＡＰに準拠したサーバを利用できる。
【００４０】
例えば図４では、プロキシ１００ｂが、同一ネットワーク５１２に属するウォッチャー２０ｆ、２０ｇ、２０ｈに対して、ＭＡＤＣＡＰサーバ５２１を利用してマルチキャストアドレスを割り当てることができる。
【００４１】
この方法でマルチキャストアドレスが割り当てられない場合は、プロキシ１００は、このグループに属するすべてのウォッチャー２０に対してユニキャストでイベントステートを通知する。なお、グループに１つのウォッチャー２０しか含まれない場合にはユニキャストでイベントステートを通知する。
【００４２】
また、プロキシ１００は、プロキシ１００と異なるネットワークに属するウォッチャー２０のグループについて、グループに２つ以上のウォッチャー２０が含まれ、何らかのマルチキャストアドレスを割り当てる方法が存在する場合には、その方法によってアドレス割り当てを行う。割り当て方法が存在しない場合には、プロキシ１００は、このグループに属するウォッチャー２０に対してユニキャストでイベントステートを通知する。また、プロキシ１００は、グループに１つのウォッチャー２０しか含まれない場合にはユニキャストでイベントステートを通知する。
【００４３】
このように、プロキシ１００は、同じリンクに属するウォッチャー２０のグループ、リンクは異なるが同じネットワークに属するウォッチャー２０のグループ、異なるネットワークに属するウォッチャー２０のグループの順に、マルチキャストアドレスを割り当てる。
【００４４】
なお、ウォッチャー２０が購読を止めたことによってグループに属するウォッチャー２０が１つになり、かつ、グループにマルチキャストアドレスが割り当てられている場合は、プロキシ１００は、このグループに割り当てたマルチキャストアドレスを解放し、ユニキャストによるイベントステートの通知に切り替える。
【００４５】
次に、本実施の形態にかかるプロキシ１００の構成について図５を用いて説明する。図５は、本実施の形態にかかるプロキシ１００のブロック図である。同図に示すように、プロキシ１００は、購読要求処理部１１０と、イベントステート取得部１２０とを備えている。
【００４６】
購読要求処理部１１０は、ウォッチャー２０から受信した購読要求に関する処理を制御する。購読要求処理部１１０は、リクエスト受信部１１１と、レスポンス送信部１１２と、リクエスト送信部１１３と、レスポンス受信部１１４と、制御部１１５と、アドレス割当部１１６と、マルチキャスト送信部１１７と、購読情報記憶部１１８と、を備えている。
【００４７】
リクエスト受信部１１１は、ウォッチャー２０からの購読要求を受信し、受信した購読要求を制御部１１５に渡す。
【００４８】
レスポンス送信部１１２は、購読要求を受信したリクエスト受信部１１１からの要求に従い、購読要求を送信したウォッチャー２０に対して応答（ＳＩＰレスポンス）を送信する。
【００４９】
リクエスト送信部１１３は、制御部１１５からの要求を受けて、ウォッチャー２０にユニキャストでイベントステートを通知するＮＯＴＩＦＹリクエストを送信する。
【００５０】
レスポンス受信部１１４は、リクエスト送信部１１３によってウォッチャー２０に送信されたＮＯＴＩＦＹリクエストに対して返信されるレスポンスを受信する。なお、レスポンス受信部１１４が、レスポンスを受信した場合、リクエスト送信部１１３はＮＯＴＩＦＹリクエストの再送を停止する。
【００５１】
制御部１１５は、ウォッチャー２０が送信した購読要求に応じた各種処理、およびイベントステート取得部１２０が新しいイベントステートを受信した場合に実行する各種処理を制御する。例えば、制御部１１５は、購読要求を受信したウォッチャー２０を、ネットワーク接続形態に応じて分類する機能を備える。より具体的には、図３および図４で説明したように、制御部１１５は、同一リンクに属するウォッチャー２０のグループ、リンクは異なるが同一ネットワークに属するウォッチャー２０のグループ、および異なるネットワークに属するウォッチャー２０のグループの３つのグループに分類する。
【００５２】
アドレス割当部１１６は、制御部１１５が分類したグループごとに、各グループに属するウォッチャー２０とのネットワーク接続形態に応じて予め定められた方法により、グループそれぞれをマルチキャストグループとしてマルチキャストアドレスを割り当てる。例えば、アドレス割当部１１６は、同一リンクに属するウォッチャー２０のグループに対して、ＺＭＡＡＰによってマルチキャストアドレスを割り当てる。また、アドレス割当部１１６は、リンクは異なるが同一ネットワークに属するウォッチャー２０のグループに対して、ＭＡＤＣＡＰによってマルチキャストアドレスを割り当てる。さらに、アドレス割当部１１６は、異なるネットワークに属するウォッチャー２０のグループに対して、マルチキャストアドレスの割り当て方法が存在する場合は、その方法によってマルチキャストアドレスを割り当てる。
【００５３】
ここで、ＺＭＡＡＰによるマルチキャストアドレスの割り当て手順の概要について説明する。ＺＭＡＡＰは、ＺｅｒｏＣｏｎｆという同一リンク内で設定の自動化を行うための一連のプロトコル群に含まれるプロトコルの１つである。具体的には、ＺＭＡＡＰは、リンク内で衝突することなくマルチキャストアドレスを利用するための仕様を定めている。
【００５４】
（１）アドレス割当部１１６は、プロキシ１００上で動作する、図示しないｍｉｎｉ−ＭＡＳＳ（Multicast Address Allocation Server）にマルチキャストアドレスの割り当てを要求する。
（２）ｍｉｎｉ−ＭＡＳＳは、未使用と思われるマルチキャストアドレスを選択し、ＡＣＬＭ（AddressClaim）メッセージをリンク内にマルチキャストする。
（３）ｍｉｎｉ−ＭＡＳＳは、ＡＣＬＭメッセージに対して、リンク内の他の装置からＡＩＵ（Address In Use）メッセージが返信される場合には、別のアドレスを選択し、再度ＡＣＬＭメッセージをマルチキャストする。
（４）ｍｉｎｉ−ＭＡＳＳは、ＡＩＵメッセージが返信されなくなるまで上記（２）および（３）の動作を繰り返す。
（５）ｍｉｎｉ−ＭＡＳＳは、ＡＩＵメッセージが返信されないマルチキャストアドレスをアドレス割当部１１６に返す。
（６）すべてのＡＣＬＭメッセージに対してＡＩＵメッセージが返信される場合は、マルチキャストアドレスの割り当てに失敗する。
【００５５】
次に、ＭＡＤＣＡＰによるマルチキャストアドレスの割り当て手順の概要について説明する。ＭＡＤＣＡＰは、マルチキャストアドレスの利用を専用のマルチキャストアドレス割り当てサーバによって管理するための仕様である。
（１）アドレス割当部１１６は、ＭＡＤＣＡＰのアドレス要求メッセージをマルチキャストで送信する。予めマルチキャストアドレス割り当てサーバが設定されている場合には、設定されているマルチキャストアドレス割り当てサーバにアドレス要求メッセージを送信する。
（２）マルチキャストアドレス割り当てサーバから使用可能なマルチキャストアドレスが通知された場合は、アドレス割当部１１６は、マルチキャストアドレスを通知したマルチキャストアドレス割り当てサーバに対して、アドレス使用メッセージを送信する。
【００５６】
マルチキャスト送信部１１７は、制御部１１５からの要求を受けて、ウォッチャー２０に対してイベントステートを通知するＮＯＴＩＦＹリクエストをマルチキャストで送信する。
【００５７】
購読情報記憶部１１８は、同じプレゼンティティの同じイベントパッケージごとに、分類したグループに属するウォッチャー２０、およびグループに割り当てたマルチキャストアドレスを対応づけた購読情報を記憶する。図６は、購読情報記憶部１１８に記憶された購読情報のデータ構造の一例を示す図である。
【００５８】
図６に示すように、購読情報は、購読対象であるプレゼンティティを識別する識別情報（ＳＩＰ  ＵＲＩ）と、購読するイベントパッケージと、ウォッチャーリスト１と、マルチキャストアドレス１と、ウォッチャーリスト２と、マルチキャストアドレス２と、ウォッチャーリスト３と、マルチキャストアドレス３と、を含んでいる。
【００５９】
ウォッチャーリスト１は、同じプレゼンティティの同じイベントパッケージを購読するウォッチャー２０のうち、プロキシ１００と同じリンクに属するウォッチャー２０のＳＩＰ  ＵＲＩの一覧である。マルチキャストアドレス１は、ウォッチャーリスト１のウォッチャー２０を含むグループに対して割り当てられたマルチキャストアドレスである。
【００６０】
ウォッチャーリスト２は、同じプレゼンティティの同じイベントパッケージを購読するウォッチャー２０のうち、プロキシ１００とリンクは異なるが同じネットワークに属するウォッチャー２０のＳＩＰ  ＵＲＩの一覧である。マルチキャストアドレス２は、ウォッチャーリスト２のウォッチャー２０を含むグループに対して割り当てられたマルチキャストアドレスである。
【００６１】
ウォッチャーリスト３は、同じプレゼンティティの同じイベントパッケージを購読するウォッチャー２０のうち、プロキシ１００と異なるネットワークに属するウォッチャー２０のＳＩＰ  ＵＲＩの一覧である。マルチキャストアドレス３は、ウォッチャーリスト３のウォッチャー２０を含むグループに対して割り当てられたマルチキャストアドレスである。
【００６２】
なお、ウォッチャー２０を識別可能な情報であれば、ＳＩＰ  ＵＲＩ以外の情報をウォッチャーリストに記載するように構成してもよい。
【００６３】
図５に戻り、イベントステート取得部１２０は、プレゼンスサーバ１０から受信したイベントステートに関する処理を制御する。イベントステート取得部１２０は、リクエスト受信部１２１と、レスポンス送信部１２２と、リクエスト送信部１２３と、レスポンス受信部１２４と、イベントステート記憶部１２５と、を備えている。
【００６４】
リクエスト受信部１２１は、イベントステートを通知するＮＯＴＩＦＹリクエストをプレゼンスサーバ１０から受信する。
【００６５】
レスポンス送信部１２２は、プレゼンスサーバ１０から受信したＮＯＴＩＦＹリクエストに対する応答として、ＳＩＰレスポンスをプレゼンスサーバ１０に送信する。
【００６６】
リクエスト送信部１２３は、プレゼンティティのイベントステートの購読を要求するＳＵＢＳＣＲＩＢＥリクエストをプレゼンスサーバ１０に対して送信する。
【００６７】
レスポンス受信部１２４は、送信したＳＵＢＳＣＲＩＢＥリクエストに対してプレゼンスサーバ１０から送信されたＳＩＰレスポンスを受信する。
【００６８】
イベントステート記憶部１２５は、プレゼンスサーバ１０から取得したイベントステートを、プレゼンティティおよびイベントパッケージごとに記憶する。すなわち、イベントステート記憶部１２５は、プレゼンティティのＳＩＰ  ＵＲＩと、イベントパッケージと、イベントステートとを対応づけた情報を記憶する。
【００６９】
なお、リクエスト受信部１２１、レスポンス送信部１２２、リクエスト送信部１２３、およびレスポンス受信部１２４は、それぞれ購読要求処理部１１０のリクエスト受信部１１１と、レスポンス送信部１１２と、リクエスト送信部１１３と、レスポンス受信部１１４と統合するように構成してもよい。また、イベントステート記憶部１２５を備えず、購読要求処理部１１０からイベントステートを要求されるたびに、イベントステート取得部１２０が最新のイベントステートをプレゼンスサーバ１０に問い合わせるように構成してもよい。
【００７０】
また、購読情報記憶部１１８およびイベントステート記憶部１２５は、ＨＤＤ（Hard Disk Drive）、光ディスク、メモリカード、ＲＡＭ（Random Access Memory）などの一般的に利用されているあらゆる記憶媒体により構成することができる。
【００７１】
次に、このように構成された本実施の形態にかかるプロキシ１００によるメッセージ中継処理について説明する。なお、メッセージ中継処理には、購読処理と、イベントステート通知処理とが含まれる。購読処理とは、ウォッチャー２０から購読要求を受信したときに、ウォッチャー２０を代理して購読要求をプレゼンスサーバ１０に購読要求を送信するとともに、ウォッチャー２０をグループ化する処理をいう。また、イベントステート通知処理とは、購読を要求したイベントパッケージについてのイベントステートの通知をプレゼンスサーバ１０から受信したときに、要求元のウォッチャー２０に対して通知を転送する処理をいう。
【００７２】
まず、購読処理について図７を用いて説明する。図７は、本実施の形態における購読処理の全体の流れを示すフローチャートである。
【００７３】
まず、リクエスト受信部１１１が、ウォッチャー２０から購読要求であるＳＵＢＳＣＲＩＢＥリクエストを受信する（ステップＳ７０１）。ＳＵＢＳＣＲＩＢＥリクエストには、購読要求の対象となるプレゼンティティを識別するＳＩＰ  ＵＲＩと、購読するイベントパッケージを識別する情報とが含まれる。
【００７４】
次に、レスポンス送信部１１２が、購読要求に対するレスポンスを、ＳＵＢＳＣＲＩＢＥリクエストを受信したウォッチャー２０に送信する（ステップＳ７０２）。なお、レスポンスにイベントステートを通知するためのマルチキャストアドレスを含めて返す場合は、ステップＳ７１０のマルチキャストアドレス取得処理（後述）の後にレスポンスを送信する。
【００７５】
次に、制御部１１５は、購読が要求されたプレゼンティティおよびイベントパッケージに対応するエントリを、購読情報記憶部１１８から取得する（ステップＳ７０３）。そして、制御部１１５は、エントリが取得できたか否かを判断する（ステップＳ７０４）。
【００７６】
エントリを取得できなかった場合は（ステップＳ７０４：ＮＯ）、イベントステート取得部１２０が、新たに購読を代理するために、プレゼンスサーバ１０に購読要求を送信してイベントステートを取得する購読要求処理を実行する（ステップＳ７０５）。購読要求処理の詳細については後述する。
【００７７】
購読要求処理の後、制御部１１５は、新たに購読を要求した対象のエントリを購読情報記憶部１１８に追加する（ステップＳ７０６）。
【００７８】
エントリを追加した後、または、ステップＳ７０４でエントリが取得できた場合（ステップＳ７０４：ＹＥＳ）、制御部１１５は、購読要求を受信したウォッチャー２０とのネットワーク接続形態を判定して当該ウォッチャー２０を分類するグループを決定するネットワーク判定処理を実行する（ステップＳ７０７）。ネットワーク判定処理の詳細については後述する。
【００７９】
ネットワーク判定処理の後、制御部１１５は、追加したエントリまたは取得したエントリのウォッチャーリストのうち、決定したグループに対応するウォッチャーリストに、購読要求を受信したウォッチャー２０を追加する（ステップＳ７０８）。
【００８０】
次に、制御部１１５は、ウォッチャー２０を追加したウォッチャーリストに、２つ以上のウォッチャー２０が存在し、かつ、当該ウォッチャーリストに対応するマルチキャストアドレスが未設定であるか否かを判断する（ステップＳ７０９）。
【００８１】
ウォッチャーリストに２つ以上のウォッチャー２０が存在し、かつ、対応するマルチキャストアドレスが未設定の場合（ステップＳ７０９：ＹＥＳ）、制御部１１５は、アドレス割当部１１６にマルチキャストアドレスの割り当てを要求する。そして、アドレス割当部１１６が、該当するウォッチャーリストに含まれるウォッチャー２０に対するマルチキャストアドレスを割り当てるマルチキャストアドレス取得処理を実行する（ステップＳ７１０）。マルチキャストアドレス取得処理の詳細については後述する。
【００８２】
次に、制御部１１５は、マルチキャストアドレス取得処理によって取得されたマルチキャストアドレスを、ウォッチャー２０を追加したウォッチャーリストに対応するマルチキャストアドレスの欄に追加する（ステップＳ７１１）。
【００８３】
マルチキャストアドレスを追加後、または、ステップＳ７０９でウォッチャーリストに２つ以上のウォッチャー２０が存在し、かつ、対応するマルチキャストアドレスが未設定であると判断されなかった場合は（ステップＳ７０９：ＮＯ）、制御部１１５は、ステップＳ７０１で受信した購読要求の対象となるプレゼンティティの最新のイベントステートを、イベントステート取得部１２０を用いて取得するイベントステート取得処理を実行する（ステップＳ７１２）。イベントステート取得処理の詳細については後述する。
【００８４】
イベントステート取得処理の後、制御部１１５は、リクエスト送信部１１３を用いて、購読要求を受信したウォッチャー２０に対して、最初のイベントステートの通知をユニキャストで送信する（ステップＳ７１３）。このとき、制御部１１５は、最新のイベントステートとともに、ステップＳ７１０で取得したマルチキャストアドレスを通知する。
【００８５】
なお、ステップＳ７１０で、マルチキャストアドレスを取得していない場合、またはマルチキャストアドレスを取得できなかった場合は、イベントステートのみを通知する。また、マルチキャストアドレスを取得後に、購読要求に対するレスポンスにマルチキャストアドレスを含めて送信するように構成する場合は、ステップＳ７１３で送信する通知メッセージにマルチキャストアドレスを含める必要はない。
【００８６】
図７の購読処理は、原則として、あるウォッチャー２０が最初の購読要求を送信した場合の処理手順を表している。ウォッチャー２０が２回目以降の購読要求を送信した場合は、プロキシ１００は、以下のような処理手順でイベントステートを取得して通知する。
【００８７】
まず、制御部１１５は、ステップＳ７０４でエントリが取得されたと判断した後に、取得したエントリのウォッチャーリスト内に購読要求を受信したウォッチャー２０がすでに追加されているか否かを判断する。これにより、制御部１１５は、購読要求を受信したウォッチャー２０から２回目以降の購読要求を受信したか否かを判断できる。そして、ウォッチャーリスト内に購読要求を受信したウォッチャー２０がすでに追加されている場合は、ステップＳ７０７〜ステップＳ７１１は実行する必要はない。
【００８８】
この後、制御部１１５は、受信した購読要求の対象となるプレゼンティティの最新のイベントステートがイベントステート記憶部１２５に記憶されていれば、イベントステート記憶部１２５から取得した最新のイベントステートを含むＮＯＴＩＦＹリクエストを、購読要求を送信してきたウォッチャー２０に送信する。
【００８９】
なお、制御部１１５が、ウォッチャー２０から購読要求を受信するたびに、ステップＳ７１２と同様の処理により、イベントステート取得部１２０に最新のイベントステートを要求するように構成してもよい。また、この場合、取得した最新のイベントステートを、同じイベントパッケージを購読するすべてのウォッチャー２０に通知してもよいし、購読要求を送信してきたウォッチャー２０に対してのみ通知してもよい。
【００９０】
次に、ステップＳ７０５の購読要求処理の詳細について図８を用いて説明する。図８は、本実施の形態における購読要求処理の全体の流れを示すフローチャートである。
【００９１】
まず、制御部１１５からの要求に従い、イベントステート取得部１２０内のリクエスト送信部１２３が、プレゼンスサーバ１０に対して購読要求（ＳＵＢＳＣＲＩＢＥリクエスト）を送信する（ステップＳ８０１）。次に、レスポンス受信部１２４は、購読要求に対するＳＩＰレスポンスをプレゼンスサーバ１０から受信する（ステップＳ８０２）。
【００９２】
次に、リクエスト受信部１２１は、購読要求が送信された時点でのプレゼンティティのイベントステートを含むＮＯＴＩＦＹリクエストをプレゼンスサーバ１０から受信する（ステップＳ８０３）。イベントステート取得部１２０は、受信したＮＯＴＩＦＹリクエスト内のイベントステートを、該当するプレゼンティティのＳＩＰ  ＵＲＩとイベントパッケージとに対応するイベントステートとして、イベントステート記憶部１２５に記憶する（ステップＳ８０４）。
【００９３】
次に、レスポンス送信部１２２が、ＮＯＴＩＦＹリクエストに対するＳＩＰレスポンスをプレゼンスサーバ１０に対して送信する（ステップＳ８０５）。なお、イベントステート取得部１２０は、取得したイベントステートを購読要求処理部１１０に通知し、購読要求処理を終了する。
【００９４】
次に、ステップＳ７０７のネットワーク判定処理の詳細について図９を用いて説明する。図９は、本実施の形態におけるネットワーク判定処理の全体の流れを示すフローチャートである。
【００９５】
まず、制御部１１５は、ＳＵＢＳＣＲＩＢＥリクエストに含まれる最も下に記載されたＶｉａヘッダを取得する（ステップＳ９０１）。次に、制御部１１５は、取得したＶｉａヘッダにｒｅｃｅｉｖｅｄパラメータが存在するか否かを判断する（ステップＳ９０２）。存在する場合は（ステップＳ９０２：ＹＥＳ）、制御部１１５は、ｒｅｃｅｉｖｅｄパラメータ内に記載されたＩＰアドレスを、ウォッチャー２０のＩＰアドレスとして取得する（ステップＳ９０３）。
【００９６】
取得したＶｉａヘッダにｒｅｃｅｉｖｅｄパラメータが存在しない場合は（ステップＳ９０２：ＮＯ）、制御部１１５は、ＳＵＢＳＣＲＩＢＥリクエスト内のコンタクトヘッダ（Ｃｏｎｔａｃｔヘッダ）に記載されたＩＰアドレスをウォッチャー２０のＩＰアドレスとして取得する（ステップＳ９０４）。
【００９７】
次に、制御部１１５は、ネットワーク設定情報を参照して、取得したＩＰアドレスを、プロキシ１００と同一リンク内のＩＰアドレス、プロキシ１００と異なるリンクだが同一ネットワーク内のＩＰアドレス、およびプロキシ１００と異なるネットワーク内のＩＰアドレスのいずれかに分類する（ステップＳ９０５）。ネットワーク設定情報とは、ネットワークの範囲を予め定める情報であって、例えば、同一リンクに属するＩＰアドレスの範囲を特定する情報、および同一ネットワークに属するＩＰアドレスの範囲を特定する情報を含む。なお、ネットワーク設定情報はこれに限られず、取得したＩＰアドレスのウォッチャー２０が属するネットワークが判定できるものであればあらゆる情報を利用できる。
【００９８】
制御部１１５は、ＩＰアドレスの分類に従い、購読要求を受信したウォッチャー２０を、プロキシ１００と同じリンクに属するウォッチャー２０のグループ、プロキシ１００とリンクは異なるが同じネットワークに属するウォッチャー２０のグループ、プロキシ１００とは異なるネットワークに属するウォッチャー２０のグループのいずれかに分類する（ステップＳ９０６）。
【００９９】
次に、ステップＳ７１０のマルチキャストアドレス取得処理の詳細について図１０を用いて説明する。図１０は、本実施の形態におけるマルチキャストアドレス取得処理の全体の流れを示すフローチャートである。
【０１００】
まず、アドレス割当部１１６は、購読要求を受信したウォッチャー２０が、プロキシ１００と同一リンクに属するか否かを判断する（ステップＳ１００１）。例えば、アドレス割当部１１６は、該当するウォッチャー２０が、購読情報記憶部１１８のウォッチャーリスト１に含まれるか否かによって、プロキシ１００と同一リンクに属するか否かを判断する。
【０１０１】
プロキシ１００と同一リンクに属する場合は（ステップＳ１００１：ＹＥＳ）、アドレス割当部１１６は、ＺＭＡＡＰを用いてマルチキャストアドレスを割り当てる（ステップＳ１００２）。
【０１０２】
なお、同図では省略しているが、ＺＭＡＡＰによるマルチキャストアドレスの割り当てが失敗した場合、アドレス割当部１１６がＺＭＡＡＰ以外の方法により同一リンク内でのマルチキャストアドレスを割り当てるように構成してもよい。
【０１０３】
例えば、アドレス割当部１１６が、予め割り当てられていたマルチキャストアドレスの範囲の中から未使用のマルチキャストアドレスを選択するように構成してもよい。また、アドレス割当部１１６が、ウォッチャー２０が購読する対象となるプレゼンティティのＳＩＰ  ＵＲＩおよび購読するイベントパッケージからハッシュ値を算出し、算出したハッシュ値を、マルチキャストアドレスのプリフィックスに結合してマルチキャストアドレスを生成するように構成してもよい。また、アドレス割当部１１６が、マルチキャストアドレスの一部にプロキシ１００のＩＰアドレスの一部を埋め込んだマルチキャストアドレスを生成するように構成してもよい。
【０１０４】
なお、これらのいずれかの方法で割り当てたマルチキャストアドレスが他のサービスで用いられているマルチキャストアドレスと衝突しないことを保証できない場合がある。このため、プロキシ１００の運用者のポリシーに従い、ＺＭＡＡＰによるアドレスの割り当てが失敗した場合には他の方法によるマルチキャストアドレスを取得しないように構成してもよい。
【０１０５】
制御部１１５は、マルチキャストアドレスの取得に失敗した場合は、プロキシ１００とリンクは異なるが同じネットワークに属するウォッチャー２０向けに割り当てられたマルチキャストアドレスでイベントステートを通知する。
【０１０６】
ステップＳ１００１で、ウォッチャー２０がプロキシ１００と同一リンクに属さないと判断した場合は（ステップＳ１００１：ＮＯ）、アドレス割当部１１６は、ウォッチャー２０が、プロキシ１００と同一ネットワークに属するか否かを判断する（ステップＳ１００３）。例えば、アドレス割当部１１６は、該当するウォッチャー２０が、購読情報記憶部１１８のウォッチャーリスト２に含まれるか否かによって、プロキシ１００と同一ネットワークに属するか否かを判断する。
【０１０７】
プロキシ１００と同一ネットワークに属する場合は（ステップＳ１００３：ＹＥＳ）、アドレス割当部１１６は、ＭＡＤＣＡＰを用いてマルチキャストアドレスを割り当てる（ステップＳ１００４）。なお、マルチキャストアドレス割り当てサーバがネットワーク上に存在しない場合や、実際に使用可能なマルチキャストアドレスが不足している場合は、マルチキャストアドレスの取得は失敗する。
【０１０８】
ステップＳ１００３で、ウォッチャー２０がプロキシ１００と同一ネットワークに属さないと判断した場合は（ステップＳ１００３：ＮＯ）、アドレス割当部１１６は、異なるネットワーク間で利用可能なマルチキャストアドレスを割り当てる（ステップＳ１００５）。なお、本ステップは、ネットワーク間でマルチキャストアドレスの使用に関する何らかの設定がなされており、双方のネットワークに対してマルチキャストアドレスを割り当てられるマルチキャストアドレス割り当てサーバ等が存在している場合にのみ実行される。アドレス割当部１１６は、このようなマルチキャストアドレス割り当てサーバから割り当てられたマルチキャストアドレスを、ウォッチャー２０のマルチキャストアドレスとして取得する。
【０１０９】
例えば、ゲートウェイを介して接続された２つのネットワーク間で、双方のネットワークで共通して使用可能なマルチキャストアドレスが確保されており、かつ、確保されたマルチキャストアドレスからプロキシ１００の要求に応じてマルチキャストアドレスの割り当てを行う手順が実装されている場合には、それらの手順を用いてマルチキャストアドレスを割り当ててもよい。
【０１１０】
このような手順が実装されていない場合や、これらの手順で割り当て可能なマルチキャストアドレスが不足している場合は、マルチキャストアドレスの取得は失敗する。
【０１１１】
次に、ステップＳ７１２のイベントステート取得処理の詳細について図１１を用いて説明する。図１１は、本実施の形態におけるイベントステート取得処理の全体の流れを示すフローチャートである。
【０１１２】
まず、イベントステート取得部１２０は、購読要求処理部１１０から要求されたプレゼンティティのＳＩＰ  ＵＲＩおよびイベントパッケージに対応するイベントステートをイベントステート記憶部１２５から検索する（ステップＳ１１０１）。
【０１１３】
イベントステート取得部１２０は、イベントステートを取得できたか否かを判断し（ステップＳ１１０２）、取得できなかった場合は（ステップＳ１１０２：ＮＯ）、ステップＳ７０５と同様の購読要求処理を実行する（ステップＳ１１０３）。そして、イベントステート取得部１２０は、購読要求処理で取得したイベントステートを購読要求処理部１１０に送出し（ステップＳ１１０４）、イベントステート取得処理を終了する。
【０１１４】
ステップＳ１１０２で、イベントステート記憶部１２５からイベントステートを取得できた場合は（ステップＳ１１０２：ＹＥＳ）、イベントステート取得部１２０は、取得したイベントステートを購読要求処理部１１０に送出し（ステップＳ１１０５）、イベントステート取得処理を終了する。
【０１１５】
以上で、メッセージ中継処理の１つである購読処理と、購読処理に含まれる各処理の詳細について説明した。次に、メッセージ中継処理に含まれるもう１つの処理であるイベントステート通知処理について図１２を用いて説明する。図１２は、本実施の形態におけるイベントステート通知処理の全体の流れを示すフローチャートである。
【０１１６】
まず、イベントステート取得部１２０のリクエスト受信部１２１は、最新のプレゼンティティのイベントステートを含むＮＯＴＩＦＹリクエストをプレゼンスサーバ１０から受信する（ステップＳ１２０１）。
【０１１７】
次に、イベントステート取得部１２０は、受信したＮＯＴＩＦＹリクエスト内のイベントステートを、該当するプレゼンティティのＳＩＰ  ＵＲＩとイベントパッケージとに対応するイベントステートとして、イベントステート記憶部１２５に記憶する（ステップＳ１２０２）。
【０１１８】
次に、レスポンス送信部１２２が、ＮＯＴＩＦＹリクエストに対するＳＩＰレスポンスをプレゼンスサーバ１０に対して送信する（ステップＳ１２０３）。また、イベントステート取得部１２０は、取得したイベントステートを購読要求処理部１１０に通知する。
【０１１９】
通知を受けた購読要求処理部１１０の制御部１１５は、通知されたプレゼンティティおよびイベントパッケージのエントリを、購読情報記憶部１１８から取得する（ステップＳ１２０４）。そして、制御部１１５は、取得したエントリ内に、マルチキャストアドレスが設定されているか否かを判断する（ステップＳ１２０５）。具体的には、制御部１１５は、マルチキャストアドレス１、マルチキャストアドレス２、およびマルチキャストアドレス３がそれぞれについて、アドレスが設定されているかを判断する。
【０１２０】
マルチキャストアドレス１、マルチキャストアドレス２、およびマルチキャストアドレス３のうち値が設定されているアドレスについては（ステップＳ１２０５：ＹＥＳ）、マルチキャスト送信部１１７は、設定されているマルチキャストアドレスを宛先として、受信した最新のイベントステートをマルチキャストにより通知する（ステップＳ１２０６）。
【０１２１】
マルチキャストアドレスが設定されていない場合は（ステップＳ１２０５：ＮＯ）、制御部１１５は、リクエスト送信部１１３を用いて、対応するウォッチャーリストに含まれる各ウォッチャー２０に対して、最新のイベントステートの通知をユニキャストで送信する（ステップＳ１２０７）。
【０１２２】
このように、本実施の形態にかかる中継装置では、プレゼンス情報の購読を代理するウォッチャーを、ネットワークの接続形態に応じてグループに分類し、接続形態に応じた適切な方法でグループごとにマルチキャストアドレスを割り当てることができる。これにより、プレゼンス情報を中継するためのマルチキャストアドレスを効率的に割り当てることができる。
【０１２３】
また、例えば、同一プレゼンティティの同一イベントパッケージを購読するウォッチャー全体を１つのマルチキャストグループとして扱えない場合でも、部分的にマルチキャストを使うことができるため、中継装置から送信するメッセージを削減し、中継装置への負荷を軽減することができる。
【０１２４】
また、同一プレゼンティティの同一イベントパッケージを購読するウォッチャーがすべて中継装置と同じリンクに属している場合に、マルチキャストアドレス割り当てサーバを介することなく、リンク内でマルチキャストアドレスを割り当てられる。このため、マルチキャストアドレス割り当てサーバに問い合わせる手順と、ルータに対するマルチキャストルーティングの設定を省略できる。特にｓｐａｒｓｅモードのマルチキャストルーティングプロトコルが動作している環境では、ＲＰ（Rendezvous Point）までのディストリビューションツリーを構成する時間を省略できる。
【０１２５】
また、従来のＳＩＰプロキシでは、同一プレゼンティティの同一イベントパッケージを購読するすべてのウォッチャーを１つのマルチキャストグループとして扱えるマルチキャストアドレスが割り当てられなかった場合には、例え一部のウォッチャーでマルチキャストグループを構成可能な場面であってもマルチキャストを使わずにすべてのウォッチャーにユニキャストでイベントステートを通知していた。すなわち、このような場合はマルチキャストの恩恵を得ることができなかった。
【０１２６】
これに対し、本実施の形態の中継装置では、中継装置と同一リンクに属するウォッチャーについては、リンク内でマルチキャストアドレスの調整を行うため、マルチキャストアドレス割り当てサーバが存在しない環境であっても、マルチキャストによって効率的にメッセージを配信可能となる。
【０１２７】
さらに、中継装置と同一リンクに属するウォッチャーのためのマルチキャストアドレスの割り当てをリンク内で行えなかった場合でも、同一ネットワーク内のマルチキャストアドレス割り当てサーバによって割り当てられたマルチキャストアドレスを使用することができる。すなわち、１つの方法でマルチキャストアドレスが割り当てられない場合であっても、他の方法で割り当てることができる。このため、マルチキャストによるイベントステートの通知が可能となり、送信するメッセージが削減され、中継装置への負荷を軽減できる。
【０１２８】
（変形例１）
上述の実施の形態では、イベントステートを購読するウォッチャー２０に対してマルチキャストアドレスを割り当て、ウォッチャー２０に対して直接マルチキャストによって通知を送信していた。このような方法は、例えば図２のプロキシ１００ａのように、プロキシ１００が直接ウォッチャー２０を収容する場合に適している。
【０１２９】
一方、例えば図２のプロキシ１００ｂのように、プレゼンスサーバ１０とウォッチャー２０との間に設置され、ウォッチャー２０を直接収容しないプロキシ１００の場合は、隣接するプロキシ１００に対してマルチキャストアドレスを割り当てるように構成してもよい。すなわち、この場合は、隣接するプロキシ１００をウォッチャーとみなしてマルチキャストアドレスを割り当てるように構成する。なお、この場合、隣接するプロキシ１００が、ウォッチャー２０に対してマルチキャストまたはユニキャストによって通知を転送する。
【０１３０】
このように構成する変形例１では、隣接するプロキシ１００をウォッチャーとみなすため、ウォッチャーとのネットワーク接続形態を判定するネットワーク判定処理が変更される。図１３は、本実施の形態の変形例１におけるネットワーク判定処理の全体の流れを示すフローチャートである。
【０１３１】
まず、制御部１１５は、ＳＵＢＳＣＲＩＢＥリクエストに含まれる最も上に記載されたＶｉａヘッダを取得する（ステップＳ１３０１）。このように、本変形例１では、最も下のＶｉａヘッダではなく、最も上のＶｉａヘッダを取得する点が上述の実施の形態のネットワーク判定処理を表す図９のステップＳ９０１と異なる。これにより、購読要求を中継したプロキシ１００のうち、隣接するプロキシ１００のＩＰアドレスを取得することができる。
【０１３２】
以降のステップＳ１３０２〜ステップＳ１３０６は、図９のステップＳ９０２〜ステップＳ９０６と同様なのでその説明を省略する。
【０１３３】
（変形例２）
ＳＵＢＳＣＲＩＢＥリクエストにＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダが設定されている場合、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダに記載されたプロキシ１００に対してマルチキャストでイベントステートを通知し、それ以降の通知はＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダに書かれたプロキシ１００に処理させるように構成してもよい。図１４は、このように構成された本実施の形態の変形例２におけるネットワーク判定処理の全体の流れを示すフローチャートである。
【０１３４】
まず、制御部１１５は、ＳＵＢＳＣＲＩＢＥリクエストからＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを取得する（ステップＳ１４０１）。次に、制御部１１５は、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダを取得できたか否かを判断し（ステップＳ１４０２）、取得できた場合は（ステップＳ１４０２：ＹＥＳ）、ＳＵＢＳＣＲＩＢＥリクエストの最も上に記載されたＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダ内のＩＰアドレスをウォッチャーのＩＰアドレスとして取得する（ステップＳ１４０３）。
【０１３５】
Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダを取得できなかった場合は（ステップＳ１４０２：ＮＯ）、制御部１１５は、ＶｉａヘッダからＩＰアドレスを取得する（ステップＳ１４０４〜ステップＳ１４０９）。ステップＳ１４０４〜ステップＳ１４０９は、図９のステップＳ９０１〜ステップＳ９０６と同様なのでその説明を省略する。
【０１３６】
このように、変形例２は、ＶｉａヘッダよりＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを優先してＩＰアドレスを取得するように構成している。なお、変形例２のフローチャートである図１４は、図９の方法にＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダの値を優先的に扱う処理（ステップＳ１４０１〜ステップＳ１４０３）を追加した処理手順を表している。同様に、図１３の変形例１の方法に対して、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダの値を優先的に扱うステップＳ１４０１〜ステップＳ１４０３を追加するように構成してもよい。
【０１３７】
次に、本実施の形態にかかる中継装置のハードウェア構成について図１５を用いて説明する。図１５は、本実施の形態にかかる中継装置のハードウェア構成図である。
【０１３８】
本実施の形態にかかる中継装置は、ＣＰＵ（Central Processing Unit）５１などの制御装置と、ＲＯＭ（Read Only Memory）５２やＲＡＭ５３などの記憶装置と、ネットワークに接続して通信を行う通信Ｉ／Ｆ５４と、ＨＤＤ（Hard Disk Drive）、ＣＤ（Compact Disc）ドライブ装置などの外部記憶装置と、ディスプレイ装置などの表示装置と、キーボードやマウスなどの入力装置と、各部を接続するバス６１を備えており、通常のコンピュータを利用したハードウェア構成となっている。
【０１３９】
本実施の形態にかかる中継装置で実行される中継プログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Compact Disk Recordable）、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。
【０１４０】
また、本実施の形態にかかる中継装置で実行される中継プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、本実施の形態にかかる中継装置で実行される中継プログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。
【０１４１】
また、本実施の形態の中継プログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。
【０１４２】
本実施の形態にかかる中継装置で実行される中継プログラムは、上述した各部（購読要求処理部、イベントステート取得部）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ５１（プロセッサ）が上記記憶媒体から中継プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、上述した各部が主記憶装置上に生成されるようになっている。
【産業上の利用可能性】
【０１４３】
以上のように、本発明にかかる装置、方法およびプログラムは、ウォッチャーを代理してプレゼンスサーバからプレゼンス情報を購読し、プレゼンス情報をウォッチャーに通知するＳＩＰプロキシなどの中継装置に適している。
【図面の簡単な説明】
【０１４４】
【図１】プレゼンスサーバの機能の概要を示す図である。
【図２】プロキシによるイベントステートの購読代理処理の概要を示す図である。
【図３】プロキシによるウォッチャーのグループ化の一例を示す図である。
【図４】マルチキャストアドレスの割り当ての一例を説明するための図である。
【図５】本実施の形態にかかるプロキシのブロック図である。
【図６】購読情報のデータ構造の一例を示す図である。
【図７】本実施の形態における購読処理の全体の流れを示すフローチャートである。
【図８】本実施の形態における購読要求処理の全体の流れを示すフローチャートである。
【図９】本実施の形態におけるネットワーク判定処理の全体の流れを示すフローチャートである。
【図１０】本実施の形態におけるマルチキャストアドレス取得処理の全体の流れを示すフローチャートである。
【図１１】本実施の形態におけるイベントステート取得処理の全体の流れを示すフローチャートである。
【図１２】本実施の形態におけるイベントステート通知処理の全体の流れを示すフローチャートである。
【図１３】本実施の形態の変形例１におけるネットワーク判定処理の全体の流れを示すフローチャートである。
【図１４】本実施の形態の変形例２におけるネットワーク判定処理の全体の流れを示すフローチャートである。
【図１５】本実施の形態にかかる中継装置のハードウェア構成図である。
【符号の説明】
【０１４５】
１０  プレゼンスサーバ
２０ａ〜２０ｅ  ウォッチャー
３０ａ、３０ｂ  ＥＰＡ
５１    ＣＰＵ
５２    ＲＯＭ
５３    ＲＡＭ
５４    通信Ｉ／Ｆ
６１    バス
１００ａ、１００ｂ  プロキシ
１１０  購読要求処理部
１１１  リクエスト受信部
１１２  レスポンス送信部
１１３  リクエスト送信部
１１４  レスポンス受信部
１１５  制御部
１１６  アドレス割当部
１１７  マルチキャスト送信部
１１８  購読情報記憶部
１２０  イベントステート取得部
１２１  リクエスト受信部
１２２  レスポンス送信部
１２３  リクエスト送信部
１２４  レスポンス受信部
１２５  イベントステート記憶部
５１１〜５１３  ネットワーク
５２１  ＭＡＤＣＡＰサーバ
【図１】
2009200796.tif 000003
【図２】
2009200796.tif 000004
【図３】
2009200796.tif 000005
【図４】
2009200796.tif 000006
【図５】
2009200796.tif 000007
【図６】
2009200796.tif 000008
【図７】
2009200796.tif 000009
【図８】
2009200796.tif 000010
【図９】
2009200796.tif 000011
【図１０】
2009200796.tif 000012
【図１１】
2009200796.tif 000013
【図１２】
2009200796.tif 000014
【図１３】
2009200796.tif 000015
【図１４】
2009200796.tif 000016
【図１５】
2009200796.tif 000017