(57)【要約】【課題】ＩＰマルチキャスト通信を行う際の処理負担を軽減するサーバ装置を提供する。【解決手段】プレゼンス情報を記憶するプレゼンス情報テーブル１４２と、複数の端末装置のそれぞれを識別するための端末識別子を、それぞれの端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵と対応付けて記憶する記憶部１４０と、複数の端末装置のうちの第１の端末装置から、その第１の端末装置の端末識別子を含み、記憶部１４０に記憶されたプレゼンス情報の購読を要求する購読要求メッセージを受信する受信部１２２と、受信した購読要求メッセージに含まれる第１の端末装置の端末識別子を用いて、第１の端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵を記憶部１４０から取得する取得部１１３と、取得した暗号鍵を第１の端末装置に送信する送信部１２１とを備えた。【選択図】        図３
2008034960.tif 000002
【特許請求の範囲】
【請求項１】
複数の端末装置の間のマルチキャスト通信で用いる暗号鍵を管理するサーバ装置であって、
プレゼンス情報を記憶する第１の記憶手段と、
前記複数の端末装置のそれぞれを識別するための端末識別子を、それぞれの端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵と対応付けて記憶する第２の記憶手段と、
前記複数の端末装置のうちの第１の端末装置から、その第１の端末装置の端末識別子を含み、前記第１の記憶手段に記憶されたプレゼンス情報の購読を要求する購読要求メッセージを受信する受信手段と、
受信した前記購読要求メッセージに含まれる前記第１の端末装置の端末識別子を用いて、前記第１の端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵を前記第２の記憶手段から取得する取得手段と、
取得した暗号鍵を前記第１の端末装置に送信する送信手段と
を備えることを特徴とするサーバ装置。
【請求項２】
前記第２の記憶手段は、前記暗号鍵とともに、前記マルチキャストグループ内のマルチキャスト通信に用いるマルチキャストアドレスも前記端末識別子と対応づけて記憶し、
前記取得手段は、前記暗号鍵とともに、前記マルチキャストアドレスも前記第２の記憶手段から取得し、
前記送信手段は、前記暗号鍵とともに、前記取得したマルチキャストアドレスも、前記第１の端末装置に送信する
ことを特徴とする請求項１に記載のサーバ装置。
【請求項３】
前記送信手段は、取得した暗号鍵を、購読要求のあったプレゼンス情報とともに前記第１の端末装置に送信する
ことを特徴とする請求項１に記載のサーバ装置。
【請求項４】
前記マルチキャストグループを識別するグループ識別子と、プレゼンス情報に関する予め定められた条件とを対応づけたグループ定義情報を記憶する第３の記憶手段をさらに備え、
前記受信手段は、さらに、前記端末装置のプレゼンス情報を含む情報通知メッセージを前記端末装置から受信し、
前記取得手段は、さらに、受信した前記情報通知メッセージに含まれるプレゼンス情報が満たす前記条件に対応する前記グループ識別子を取得し、取得した前記グループ識別子に対応する前記鍵情報を前記第２の記憶手段から取得し、
前記送信手段は、取得した前記鍵情報を、前記情報通知メッセージを送信した前記端末装置に送信すること、もしくは、前記グループ識別子で識別されるマルチキャストグループに含まれる前記端末装置に送信すること、
を特徴とする請求項１に記載のサーバ装置。
【請求項５】
前記マルチキャストグループの前記暗号鍵を生成する生成手段と、
生成した前記暗号鍵を含む前記鍵情報を前記第２の記憶手段に登録する登録手段と、をさらに備え、
前記送信手段は、さらに前記登録手段が前記鍵情報を登録した場合に、前記鍵情報を登録した前記マルチキャストグループに含まれる前記端末装置に、登録した前記鍵情報を送信すること、
を特徴とする請求項１に記載のサーバ装置。
【請求項６】
前記マルチキャストグループを識別するグループ識別子と、プレゼンス情報に関する予め定められた条件とを対応づけたグループ定義情報を記憶する第３の記憶手段をさらに備え、
前記グループ定義情報の入力を受付ける受付手段と、
受付けた前記グループ定義情報を前記第３の記憶手段に登録する登録手段と、
前記取得手段は、さらに、前記登録手段が前記グループ定義情報を登録した場合に、登録した前記グループ定義情報の前記条件に対応する前記グループ識別子を取得し、取得した前記グループ識別子に対応する前記鍵情報を前記第２の記憶手段から取得し、
前記送信手段は、取得した前記鍵情報を、登録した前記グループ定義情報の前記条件を満たすプレゼンス情報を有する前記端末装置に対して送信すること、
を特徴とする請求項１に記載のサーバ装置。
【請求項７】
前記受信手段は、さらに、前記グループ定義情報を含み、前記グループ定義情報の登録を要求する登録要求メッセージを受信し、
前記登録手段は、受信した前記登録要求メッセージに含まれる前記グループ定義情報を前記第３の記憶手段に登録すること、
を特徴とする請求項６に記載のサーバ装置。
【請求項８】
前記登録要求メッセージを送信した前記端末装置の認証を行う認証手段をさらに備え、
前記登録手段は、前記端末装置が認証された場合に、受信した前記登録要求メッセージに含まれる前記グループ定義情報を前記第３の記憶手段に登録すること、
を特徴とする請求項７に記載のサーバ装置。
【請求項９】
前記受信手段は、さらに、前記暗号鍵を前記端末装置から受信し、
受信した前記暗号鍵を含む前記鍵情報を前記第２の記憶手段に登録する登録手段をさらに備えたこと、
を特徴とする請求項１に記載のサーバ装置。
【請求項１０】
前記暗号鍵を送信した前記端末装置の認証を行う認証手段をさらに備え、
前記登録手段は、前記端末装置が認証された場合に、受信した前記暗号鍵を含む前記鍵情報を前記第２の記憶手段に登録すること、
を特徴とする請求項９に記載のサーバ装置。
【請求項１１】
前記受信手段は、さらに、マルチキャスト通信の開始を通知する開始メッセージを前記端末装置から受信し、
前記送信手段は、さらに、前記開始メッセージを受信した場合に、マルチキャスト通信の対象となる前記マルチキャストグループに含まれる前記端末装置に、マルチキャスト通信の開始を要求する開始要求メッセージを送信すること、
を特徴とする請求項１に記載のサーバ装置。
【請求項１２】
前記受信手段は、さらに、マルチキャスト通信の終了を通知する終了メッセージを前記端末装置から受信し、
前記送信手段は、さらに、前記終了メッセージを受信した場合に、マルチキャスト通信の対象となる前記マルチキャストグループに含まれる前記端末装置に、マルチキャスト通信の終了を要求する終了要求メッセージを送信すること、
を特徴とする請求項１１に記載のサーバ装置。
【請求項１３】
前記送信手段は、さらに、前記開始メッセージを送信した前記端末装置と異なる前記端末装置がマルチキャスト通信を行っていない場合に、前記開始メッセージを送信した前記端末装置に対してマルチキャスト通信を許可する許可メッセージを送信すること、
を特徴とする請求項１０に記載のサーバ装置。
【請求項１４】
前記端末装置の認証を行う認証手段をさらに備え、
前記受信手段は、さらに、前記マルチキャストグループに含まれない前記端末装置から、前記グループ識別子を含み、前記マルチキャストグループへのマルチキャスト通信を要求する通信要求メッセージを受信し、
前記認証手段は、前記通信要求メッセージを送信した前記端末装置を認証し、
前記取得手段は、前記端末装置が認証された場合に、前記通信要求メッセージに含まれる前記グループ識別子に対応する前記鍵情報を前記第２の記憶手段から取得し、
前記送信手段は、取得した前記鍵情報を、前記通信要求メッセージを送信した前記端末装置に送信すること、
を特徴とする請求項１に記載のサーバ装置。
【請求項１５】
前記送信手段は、さらに、前記通信要求メッセージを送信した前記端末装置と異なる前記端末装置がマルチキャスト通信を行っていない場合に、前記通信要求メッセージを送信した前記端末装置に対してマルチキャスト通信を許可する許可メッセージを送信すること、
を特徴とする請求項１３に記載のサーバ装置。
【請求項１６】
プレゼンス情報を管理するサーバ装置とネットワークを介して接続された端末装置であって、
プレゼンス情報を提供するプレゼンティティであるマルチキャストグループのプレゼンス情報の購読を要求する購読要求メッセージを前記サーバ装置に送信する送信手段と、
前記マルチキャストグループがマルチキャスト通信に用いる暗号鍵に関する鍵情報を前記サーバ装置から受信する受信手段と、
を備えたことを特徴とする端末装置。
【請求項１７】
複数の端末装置の間のマルチキャスト通信で用いる暗号鍵を管理するサーバ装置における通信方法であって、
前記複数の端末装置のうちの第１の端末装置から、その第１の端末装置の端末識別子を含み、プレゼンス情報を記憶する第１の記憶手段に記憶されたプレゼンス情報の購読を要求する購読要求メッセージを受信する受信ステップと、
取得手段によって、受信した前記購読要求メッセージに含まれる前記第１の端末装置の端末識別子を用いて、前記複数の端末装置のそれぞれを識別するための端末識別子をそれぞれの端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵と対応付けて記憶する第２の記憶手段から、前記第１の端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵を取得する取得ステップと、
取得した暗号鍵を前記第１の端末装置に送信する送信ステップと
を備えたことを特徴とする通信方法。
【請求項１８】
複数の端末装置の間のマルチキャスト通信で用いる暗号鍵を管理するサーバ装置における通信プログラムであって、
前記複数の端末装置のうちの第１の端末装置から、その第１の端末装置の端末識別子を含み、プレゼンス情報を記憶する第１の記憶手段に記憶されたプレゼンス情報の購読を要求する購読要求メッセージを受信する受信手順と、
受信した前記購読要求メッセージに含まれる前記第１の端末装置の端末識別子を用いて、前記複数の端末装置のそれぞれを識別するための端末識別子をそれぞれの端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵と対応付けて記憶する第２の記憶手段から、前記第１の端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵を取得する取得手順と、
取得した暗号鍵を前記第１の端末装置に送信する送信手順と
をコンピュータに実行させる通信プログラム。
【請求項１９】
複数の端末装置の間のマルチキャスト通信で用いる暗号鍵を管理するサーバ装置と、前記複数の端末装置と、をネットワークで接続した通信システムであって、
前記サーバ装置は、
プレゼンス情報を記憶する第１の記憶手段と、
前記複数の端末装置のそれぞれを識別するための端末識別子を、それぞれの端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵と対応付けて記憶する第２の記憶手段と、
前記複数の端末装置のうちの第１の端末装置から、その第１の端末装置の端末識別子を含み、前記第１の記憶手段に記憶されたプレゼンス情報の購読を要求する購読要求メッセージを受信する受信手段と、
受信した前記購読要求メッセージに含まれる前記第１の端末装置の端末識別子を用いて、前記第１の端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵を前記第２の記憶手段から取得する取得手段と、
取得した暗号鍵を前記第１の端末装置に送信する送信手段と、を備え、
前記端末装置は、
前記購読要求メッセージを前記サーバ装置に送信する第２送信手段と、
前記鍵情報を前記サーバ装置から受信する第２受信手段と、を備えたこと、
を特徴とする通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ＳＩＰ（Session Initiation Protocol）などのセッション制御プロトコルベースのシステムでＩＰ（Internet Protocol）マルチキャスト通信を行うサーバ装置、端末装置、通信方法、通信プログラムおよび通信システムに関するものである。
【背景技術】
【０００２】
近年、ＩＰネットワーク上でのマルチメディアセッションの制御を行うプロトコルであるＳＩＰを用いて、例えば、インターネット電話システムなどの通信システムが開発されている。
【０００３】
ＳＩＰベースの通信システムでＩＰマルチキャスト通信を行う場合、セキュリティ強化等のため、通信する端末相互間で事前に暗号化鍵を交換し、暗号化鍵でメッセージを暗号化して通信を行うことが望ましい。
【０００４】
非特許文献１では、ＳＩＰなどに適用しうる暗号化鍵の交換プロトコルとして標準化されたＭＩＫＥＹ（Multimedia Internet KEYing）と呼ばれる技術が開示されている。非特許文献１の方法をＳＩＰに適用する場合、原則として暗号化通信を行う端末同士がオファーアンサーモデルに従って暗号化鍵の交換を行うことになる。
【０００５】
【非特許文献１】J. Arkko et al.、 "RFC 3830、 MIKEY: Multimedia Internet KEYing"、 [online]、 August 2004、 retrieved from the Internet: <URL: http://www.ietf.org/rfc/rfc3830.txt>
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、非特許文献１の方法では、端末同士が１対１で暗号化鍵の交換を行うため、ＩＰマルチキャスト通信時の鍵交換のための処理負担が増大する場合があるという問題があった。
【０００７】
例えば、多数の端末がメンバとして登録されているＩＰマルチキャストグループとＩＰマルチキャスト通信を行う場合、すべてのメンバとの間で鍵交換を行い、鍵交換処理が完了してからＩＰマルチキャスト通信を開始する必要があるため、通信開始までの時間的コストが過大となる問題があった。
【０００８】
本発明は、上記に鑑みてなされたものであって、セキュアなＩＰマルチキャスト通信を行う際の処理負担を軽減することができるサーバ装置、端末装置、通信方法、通信プログラムおよび通信システムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
上述した課題を解決し、目的を達成するために、本発明は、複数の端末装置の間のマルチキャスト通信で用いる暗号鍵を管理するサーバ装置であって、プレゼンス情報を記憶する第１の記憶手段と、前記複数の端末装置のそれぞれを識別するための端末識別子を、それぞれの端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵と対応付けて記憶する第２の記憶手段と、前記複数の端末装置のうちの第１の端末装置から、その第１の端末装置の端末識別子を含み、前記第１の記憶手段に記憶されたプレゼンス情報の購読を要求する購読要求メッセージを受信する受信手段と、受信した前記購読要求メッセージに含まれる前記第１の端末装置の端末識別子を用いて、前記第１の端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵を前記第２の記憶手段から取得する取得手段と、取得した暗号鍵を前記第１の端末装置に送信する送信手段とを備えることを特徴とする。
【００１０】
また、本発明は、上記装置を実行することができる通信方法および通信プログラムである。
【００１１】
また、本発明は、複数の端末装置の間のマルチキャスト通信で用いる暗号鍵を管理するサーバ装置と、前記複数の端末装置と、をネットワークで接続した通信システムであって、前記サーバ装置は、プレゼンス情報を記憶する第１の記憶手段と、前記複数の端末装置のそれぞれを識別するための端末識別子を、それぞれの端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵と対応付けて記憶する第２の記憶手段と、前記複数の端末装置のうちの第１の端末装置から、その第１の端末装置の端末識別子を含み、前記第１の記憶手段に記憶されたプレゼンス情報の購読を要求する購読要求メッセージを受信する受信手段と、受信した前記購読要求メッセージに含まれる前記第１の端末装置の端末識別子を用いて、前記第１の端末装置が属するマルチキャストグループ内のマルチキャスト通信に用いる暗号鍵を前記第２の記憶手段から取得する取得手段と、取得した暗号鍵を前記第１の端末装置に送信する送信手段と、を備え、前記端末装置は、前記購読要求メッセージを前記サーバ装置に送信する第２送信手段と、前記鍵情報を前記サーバ装置から受信する第２受信手段と、を備えたこと、を特徴とする。
【発明の効果】
【００１２】
本発明によれば、プレゼンスサーバ機能を用いてマルチキャスト通信で用いる鍵の交換を行うため、セキュアなＩＰマルチキャスト通信を行う際の処理負担を軽減することができるという効果を奏する。
【発明を実施するための最良の形態】
【００１３】
以下に添付図面を参照して、この発明にかかるサーバ装置、端末装置、通信方法、通信プログラムおよび通信システムの最良な実施の形態を詳細に説明する。
【００１４】
（第１の実施の形態）
第１の実施の形態にかかるサーバ装置は、ＩＰマルチキャスト通信とは無関係な存在であったプレゼンスサーバ機能を利用して、事前にＩＰマルチキャストのための鍵交換をＩＰマルチキャストグループのメンバ間で行うものである。これにより、ＳＩＰベースのシステムでセキュアなＩＰマルチキャスト通信を開始するまでにかかる時間的なコスト（オーバヘッド）を削減することができる。
【００１５】
また、本実施の形態にかかるサーバ装置は、鍵交換プロトコルのためのメッセージ送信とプレゼンス情報のためのメッセージ送信を統合することにより、システム構成を単純化し、ネットワークトラフィックを削減することができる。
【００１６】
なお、プレゼンス情報とは、端末が通信可能か否か（オフラインかオンラインか）や、ユーザの在席位置情報、あるいはアプリケーションの利用可能性などのような、端末やユーザ、ユーザが属するグループ、アプリケーションなどに関する状態を表す情報をいう。
【００１７】
図１は、第１の実施の形態にかかるサーバ装置であるプレゼンスサーバ１００を含む通信システムの構成を示す概念図である。本通信システムはＳＩＰベースのシステムであり、例えば、ＩＰベースの企業向け内線電話システム、テレビ会議システム、チャットシステムなどが該当する。同図に示すように、本通信システムは、プレゼンスサーバ１００と、複数の端末２００ａ〜２００ｈと、Ｐｒｏｘｙ３００とを含んでいる。
【００１８】
端末２００ａ〜２００ｈは、ＳＩＰのクライアント機能（ＳＩＰ  ＵＡ（ユーザエージェント））を有する装置である。なお、端末２００ａ〜２００ｈは同様の構成を備えているため、以下では単に端末２００という場合がある。
【００１９】
Ｐｒｏｘｙ３００は、ＳＩＰメッセージの転送機能を持つ通常のＳＩＰ  Ｐｒｏｘｙサーバであり、プレゼンスサーバ１００や端末２００間のＳＩＰメッセージを転送するものである。
【００２０】
プレゼンスサーバ１００は、本通信システムの各プレゼンティティのプレゼンス情報を管理するものである。なお、プレゼンティティとは、プレゼンス情報を提供するものをいう。一方、プレゼンティティのプレゼンス情報の通知を受けるものをウォッチャーという。なお、プレゼンティティやウォッチャーは、端末２００に限られず、プレゼンス情報の提供や通知を受けるものであればあらゆるものが該当する。
【００２１】
図２は、第１の実施の形態にかかる端末２００の構成を示すブロック図である。同図に示すように、端末２００は、音声入出力部２１１と、データ入出力部２１２と、発行メッセージ処理部２０１と、購読メッセージ処理部２０２と、通知メッセージ処理部２０３と、送信部２２１と、受信部２２２とを備えている。
【００２２】
音声入出力部２１１は、ユーザの発話等の音声を入力するとともに、他の端末２００等から送信された音声をユーザに対して出力するものである。音声入出力部２１１は、一般的に利用されているマイクとスピーカ、または電話機の受話器などにより構成することができる。
【００２３】
データ入出力部２１２は、音声以外の各種データの入出力を行うものであり、例えば、電話番号を入力するための操作ボタン、データを表示する液晶ディスプレイなどにより構成することができる。
【００２４】
なお、音声入出力部２１１と、データ入出力部２１２とにより、通常の電話端末のようなユーザインターフェース機能が実現される。
【００２５】
発行メッセージ処理部２０１は、プレゼンスサーバ１００に対するプレゼンス情報の発行を行うメッセージである発行メッセージに関する処理を行うものである。具体的には、発行メッセージ処理部２０１は、ＳＩＰ  ＰＵＢＬＩＳＨメッセージを発行メッセージとしてプレゼンスサーバ１００に対してプレゼンス情報を発行する。メッセージの形式はこれに限られるものではなく、プレゼンス情報を発行できるものであればあらゆる形式のメッセージを用いることができる。
【００２６】
なお、この発行メッセージ処理部２０１の機能により、端末２００は、プレゼンスサーバ１００に対して、プレゼンス情報を提供するプレゼンティティとなることができる。
【００２７】
購読メッセージ処理部２０２は、プレゼンスサーバ１００に対して他のプレゼンティティの情報の購読を要求するメッセージである購読要求メッセージに関する処理を行うものである。具体的には、購読メッセージ処理部２０２は、ＳＩＰ  ＳＵＢＳＣＲＩＢＥメッセージを購読要求メッセージとしてプレゼンスサーバ１００に対して購読要求を行う。メッセージの形式はこれに限られるものではなく、購読要求を送信できるものであればあらゆる形式のメッセージを用いることができる。
【００２８】
なお、この購読メッセージ処理部２０２の機能により、端末２００は、プレゼンスサーバ１００から、他のプレゼンティティの情報に関する通知を受けるウォッチャーとなることができる。
【００２９】
通知メッセージ処理部２０３は、プレゼンスサーバ１００から受信した他のプレゼンティティのプレゼンス情報などを通知するメッセージである情報通知メッセージに関する処理を行うものである。具体的には、通知メッセージ処理部２０３は、ＳＩＰ  ＮＯＴＩＦＹメッセージを情報通知メッセージとして通知されたプレゼンス情報を受信し、その内容を取得する処理を行う。メッセージの形式はこれに限られるものではなく、他のプレゼンティティのプレゼンス情報などの通知を受けることができるものであればあらゆる形式のメッセージを用いることができる。
【００３０】
送信部２２１は、プレゼンスサーバ１００または他の端末２００に対して、各種メッセージや、音声・映像等のメディアデータを送信するものである。
【００３１】
受信部２２２は、プレゼンスサーバ１００または他の端末２００から、各種メッセージや、音声・映像等のメディアデータを受信するものである。
【００３２】
送信部２２１および受信部２２２は、ＳＲＴＰ（Secure Real-time Transport Protocol）によりセキュアなＩＰマルチキャスト通信によりメディアデータを送信する。このため、送信部２２１および受信部２２２は、暗号化および復号に使用する鍵情報を記憶部に複数保持する。
【００３３】
これにより、送信部２２１は、送信の際にそのうちの１つの暗号鍵を選択してメディアデータを暗号化して送信することができる。また、受信部２２２は、受信の際に、そのメディアデータの暗号化に使用されている暗号鍵を特定し、保持している複数の暗号鍵の中から対応する暗号鍵を選択し、メディアデータを復号して受信することができる。
【００３４】
図３は、第１の実施の形態にかかるプレゼンスサーバ１００の構成を示すブロック図である。同図に示すように、プレゼンスサーバ１００は、記憶部１４０と、受付部１１１と、認証部１１２と、取得部１１３と、生成部１１４と、登録部１１５と、発行メッセージ処理部１０１と、購読メッセージ処理部１０２と、通知メッセージ処理部１０３と、送信部１２１と、受信部１２２とを備えている。
【００３５】
記憶部１４０は、プレゼンスサーバ１００による通信処理で利用する各種データを記憶するものであり、ＨＤＤ（Hard Disk Drive）、光ディスク、メモリカード、ＲＡＭ（Random Access Memory）などの一般的に利用されているあらゆる記憶媒体により構成することができる。
【００３６】
また、記憶部１４０は、各種データを記憶するテーブルとして、プレゼンティティ情報テーブル１４１と、プレゼンス情報テーブル１４２と、対応テーブル１４３と、定義情報テーブル１４４と、アドレステーブル１４５と、鍵情報テーブル１４６とを含んでいる。
【００３７】
プレゼンティティ情報テーブル１４１は、プレゼンティティに関する情報を格納するものである。図４は、プレゼンティティ情報テーブル１４１のデータ構造の一例を示す説明図である。
【００３８】
同図に示すように、プレゼンティティ情報テーブル１４１は、プレゼンティティ名と、Ｇｒｏｕｐフラグと、プレゼンティティを識別する識別子としてＵＲＩ（Uniform Resource Identifier）とを対応づけて格納している。
【００３９】
Ｇｒｏｕｐフラグとは、プレゼンティティがマルチキャストグループであるか否かを表す情報をいい、マルチキャストグループであるときは、「○」が設定される。このように、本実施の形態にかかるプレゼンスサーバ１００では、プレゼンティティとしてマルチキャストグループを指定することができる。
【００４０】
プレゼンス情報テーブル１４２は、各プレゼンティティの現在の状況を表すプレゼンス情報を格納するものである。図５は、プレゼンス情報テーブル１４２のデータ構造の一例を示す説明図である。
【００４１】
同図に示すように、プレゼンス情報テーブル１４２は、プレゼンティティ名と、プレゼンス情報とを対応づけて格納している。プレゼンス情報としては、メッセージの受入れ可否（「Ｏｐｅｎ」または「Ｃｌｏｓｅ」）を表すＢａｓｉｃ要素と、位置に関する情報であるＬｏｃａｔｉｏｎ要素とを格納している。なお、プレゼンス情報はこれに限られるものではなく、従来から用いられているプレゼンスに関するあらゆる情報を指定することができる。
【００４２】
対応テーブル１４３は、プレゼンティティごとに、当該プレゼンティティに対するウォッチャーを格納するものである。図６は、対応テーブル１４３のデータ構造の一例を示す説明図である。
【００４３】
同図に示すように、対応テーブル１４３は、プレゼンティティのＵＲＩと、ウォッチャーリストとを対応づけて格納している。プレゼンティティがマルチキャストグループの場合は、プレゼンティティのＵＲＩにはマルチキャストグループのＵＲＩが設定され、ウォッチャーリストに含まれるＵＲＩが、対応するマルチキャストグループを構成するメンバである端末２００のリストを表す。
【００４４】
定義情報テーブル１４４は、マルチキャストグループを構成するメンバを定義する情報を格納するものである。図７は、定義情報テーブル１４４のデータ構造の一例を示す説明図である。
【００４５】
同図に示すように、定義情報テーブル１４４は、マルチキャストグループのＵＲＩと、グループメンバのＵＲＩのリストとを対応づけたグループ定義情報を格納している。また、定義情報テーブル１４４には、プレゼンス情報が満たす条件によって構成メンバを定義するグループ定義情報を格納することもできる。
【００４６】
例えば、同図の２レコード目のグループ定義情報では、グループメンバを「プレゼンス状態が着席中であり、且つ、その接続元情報がオフィスＡとなっている端末」のように、プレゼンス情報の条件によって定義している。
【００４７】
すなわち、同図では、プレゼンス情報のＢａｓｉｃ要素が「Ｏｐｅｎ」であり、Ｌｏｃａｔｉｏｎ要素が「ｌｏｃａｔｉｏｎ−Ａ」である端末２００をグループメンバとするグループ定義情報が指定されている。
【００４８】
なお、同図の１レコード目のグループ定義情報のように、端末２００のＵＲＩのリストによって定義されたマルチキャストグループのグループメンバは、対応テーブル１４３における当該マルチキャストグループをプレゼンティティとするウォッチャーリストと同一となる。
【００４９】
一方、プレゼンス情報により定義されたマルチキャストグループに対しては、プレゼンティティ情報テーブル１４１およびプレゼンス情報テーブル１４２を参照し、条件を満たすプレゼンス情報を有する端末２００を選択することにより、任意のタイミングで当該マルチキャストグループのメンバとなる端末２００のＵＲＩのリストを得ることができる。
【００５０】
このようにして得られた端末２００のＵＲＩのリストは、対応テーブル１４３のウォッチャーリストに登録される。このようにして、現在のプレゼンス情報を反映したマルチキャストグループのメンバ構成を対応テーブル１４３に保持することができる。
【００５１】
アドレステーブル１４５は、マルチキャストグループのマルチキャストアドレスを格納するものである。図８は、アドレステーブル１４５のデータ構造の一例を示す説明図である。
【００５２】
同図に示すように、アドレステーブル１４５は、マルチキャストグループの識別子（ＵＲＩ）であるグループＵＲＩと、マルチキャストアドレスとを対応づけて格納している。
【００５３】
鍵情報テーブル１４６は、マルチキャストグループにおけるＩＰマルチキャスト通信で用いる暗号鍵の情報を格納するものである。図９は、鍵情報テーブル１４６のデータ構造の一例を示す説明図である。同図に示すように、鍵情報テーブル１４６は、グループＵＲＩと、鍵情報とを対応づけて格納している。
【００５４】
鍵情報には、暗号化通信に用いる鍵の情報を記憶する。本実施の形態では、鍵情報として、秘密鍵方式の暗号鍵などの従来から用いられているあらゆる暗号鍵を用いることができる。なお、鍵情報は、そのＩＤとともに複数保持することができる。
【００５５】
受付部１１１は、定義情報テーブル１４４に設定するグループ定義情報などの、ユーザにより入力される各種情報の入力を受付けるものである。受付部１１１は、キーボードなどのユーザインターフェースや、外部装置からネットワーク経由でグループ定義情報を受付ける方法などの従来から用いられているあらゆるデータ入力方法により実現される。
【００５６】
認証部１１２は、端末２００などの外部装置の認証処理を行うものであり、ＩＤ／パスワードを用いた認証方法などの従来から用いられているあらゆる認証方法を適用できる。また、認証部１１２は、ネットワークを介して接続された外部の認証サーバ（図示せず）を利用して認証処理を行うように構成してもよい。
【００５７】
取得部１１３は、購読要求メッセージ等が送信されたマルチキャストグループの鍵情報を、鍵情報テーブル１４６から取得するものである。具体的には、取得部１１３は、購読要求メッセージ等に含まれる端末２００のＵＲＩに対応するマルチキャストグループのＵＲＩを対応テーブル１４３から取得し、取得したＵＲＩに対応する鍵情報を鍵情報テーブル１４６から取得する。
【００５８】
また、取得部１１３は、購読要求メッセージ等が送信されたマルチキャストグループのマルチキャストアドレスを、アドレステーブル１４５から取得する。具体的には、取得部１１３は、対応テーブル１４３から取得したＵＲＩに対応するマルチキャストアドレスをアドレステーブル１４５から取得する。
【００５９】
生成部１１４は、マルチキャストグループの鍵情報の生成を行うものである。生成部１１４は、例えば、受付部１１１により新規グループの作成が受付けられたときに、乱数の発生などによって鍵情報を生成する。生成部１１４による鍵の生成では、用いる暗号鍵の種類に応じた従来から用いられているあらゆる鍵の生成方法を適用できる。
【００６０】
なお、マルチキャストグループを構成する端末２００により生成された鍵情報を、例えばＳＩＰ  ＰＵＢＬＩＳＨ  ＲＥＱＵＥＳＴメッセージなどにより受信して利用するように構成してもよい。また、生成部１１４は、鍵情報を任意のタイミング、または周期的に更新するように構成してもよい。
【００６１】
登録部１１５は、上記各テーブルに対する情報の登録処理を行うものである。例えば、登録部１１５は、生成部１１４が生成した鍵情報を、鍵情報テーブル１４６に登録する。また、登録部１１５は、受付部１１１が受付けたグループ定義情報を、定義情報テーブル１４４に登録する。
【００６２】
発行メッセージ処理部１０１は、プレゼンティティである端末２００などから受信した発行メッセージに関する処理を行うものである。例えば、発行メッセージ処理部１０１は、ＳＩＰ  ＰＵＢＬＩＳＨ  ＲＥＱＵＥＳＴメッセージによってプレゼンス情報が変化したことを端末２００から通知されたとき、ＳＩＰ  ＰＵＢＬＩＳＨ  ＲＥＳＰＯＮＳＥメッセージを返信する処理を行う。
【００６３】
また、発行メッセージ処理部１０１は、受信したプレゼンス情報をプレゼンス情報テーブル１４２に保存する。新規プレゼンティティのプレゼンス情報を受信したときは、発行メッセージ処理部１０１は、プレゼンティティ情報テーブル１４１に新たにプレゼンティティの情報を追加する。
【００６４】
購読メッセージ処理部１０２は、ウォッチャーである端末２００などから受信した購読要求メッセージに関する処理を行うものである。例えば、購読メッセージ処理部１０２は、ＳＩＰ  ＳＵＢＳＣＲＩＢＥメッセージを受信したとき、対応するレスポンスとしてＳＩＰ  ＳＵＢＳＣＲＩＢＥ  ＲＥＳＰＯＮＳＥメッセージを返信する処理を行う。
【００６５】
また、購読メッセージ処理部１０２は、購読要求メッセージを受信した端末２００を対応テーブル１４３のウォッチャーリストに追加する処理などを行う。
【００６６】
通知メッセージ処理部１０３は、端末２００に送信するプレゼンス情報の変更などを通知する情報通知メッセージに関する処理を行うものである。例えば、通知メッセージ処理部１０３は、任意のプレゼンティティのプレゼンス情報が更新された場合に、当該プレゼンティティのウォッチャーである端末２００に対して通知するＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを生成し、端末２００に送信する処理を行う。なお、通知メッセージ処理部１０３は、対応するＳＩＰ  ＮＯＴＩＦＹ  ＲＥＳＰＯＮＳＥの処理も行う。
【００６７】
ウォッチャーリストを更新した場合、通知メッセージ処理部１０３は、プレゼンス情報をウォッチャーリストに含まれる各端末２００に対して、ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージによって通知する。
【００６８】
送信部１２１は、端末２００に対して各種メッセージを送信するものである。受信部１２２は、端末２００から各種メッセージを受信するものである。
【００６９】
次に、このように構成された第１の実施の形態にかかるプレゼンスサーバ１００による鍵交換処理について説明する。図１０は、第１の実施の形態における鍵交換処理の全体の流れを示すシーケンス図である。同図は、端末２００が起動したときの鍵交換処理のシーケンスを表している。
【００７０】
まず、端末２００の送信部２２１は、マルチキャストグループを含む任意のプレゼンティティに対するウォッチャーとして登録を依頼する購読要求メッセージ（ＳＩＰ  ＳＵＢＳＣＲＩＢＥ  ＲＥＱＵＥＳＴメッセージ）をプレゼンスサーバ１００に対して送信する（ステップＳ１００１）。
【００７１】
なお、端末２００は、事前にプレゼンスサーバ１００のアドレスを取得しているものとする。また、ＳＩＰ  ＳＵＢＳＣＲＩＢＥ  ＲＥＱＵＥＳＴメッセージは、端末２００の購読メッセージ処理部２０２によって作成される。ＳＩＰ  ＳＵＢＳＣＲＩＢＥ  ＲＥＱＵＥＳＴメッセージには、購読対象となるプレゼンティティを識別するためのＵＲＩが含まれる。なお、マルチキャストグループに含まれる端末２００の情報はプレゼンスサーバ１００の対応テーブル１４３で管理しているため、自装置が属するマルチキャストグループの購読要求を行うときはＵＲＩを含めなくてもよい。
【００７２】
次に、プレゼンスサーバ１００の受信部１２２は、ＳＩＰ  ＳＵＢＳＣＲＩＢＥ  ＲＥＱＵＥＳＴメッセージを受信する（ステップＳ１００２）。続いて、認証部１１２が、ＳＩＰ  ＳＵＢＳＣＲＩＢＥ  ＲＥＱＵＥＳＴメッセージに含まれる認証情報を用いて端末２００の認証処理を行う（ステップＳ１００３）。
【００７３】
端末２００が認証された場合は、購読メッセージ処理部１０２は、購読が要求されたプレゼンティティに対するウォッチャーとして端末２００を追加するように対応テーブル１４３を更新する（ステップＳ１００４）。また、例えば、システム全体のマルチキャストグループに対応するプレゼンティティが存在する場合、当該プレゼンティティに対するウォッチャーとして端末２００を追加するように構成してもよい。
【００７４】
次に、購読メッセージ処理部１０２は、ＳＩＰ  ＳＵＢＳＣＲＩＢＥ  ＲＥＳＰＯＮＳＥメッセージを生成する（ステップＳ１００５）。生成したメッセージは、送信部１２１が端末２００に送信する（ステップＳ１００６）。
【００７５】
端末２００の受信部２２２は、送信されたＳＩＰ  ＳＵＢＳＣＲＩＢＥ  ＲＥＳＰＯＮＳＥメッセージを受信する（ステップＳ１００７）。
【００７６】
次に、プレゼンスサーバ１００の通知メッセージ処理部１０３は、端末２００の購読対象はマルチキャストグループか否かを判断する（ステップＳ１００８）。
【００７７】
具体的には、通知メッセージ処理部１０３は、まず、対応テーブル１４３を参照して端末２００に通知すべきプレゼンティティを特定する。すなわち、通知メッセージ処理部１０３は、端末２００がウォッチャーとして含まれるプレゼンティティ名を対応テーブル１４３から取得する。
【００７８】
ここで特定されるプレゼンティティとしては、端末２００が明示的にウォッチャーとなることを要求して対応テーブル１４３に登録されているプレゼンティティと、端末２００が含まれるマルチキャストグループとが該当しうる。
【００７９】
次に、通知メッセージ処理部１０３は、取得したプレゼンティティ名に対応するＧｒｏｕｐフラグをプレゼンティティ情報テーブル１４１から取得し、取得したＧｒｏｕｐフラグが「○」であるか否かにより、購読対象がマルチキャストグループか否かを判断する。
【００８０】
購読対象がマルチキャストグループである場合は（ステップＳ１００８：ＹＥＳ）、取得部１１３は、受信したＳＩＰ  ＳＵＢＳＣＲＩＢＥ  ＲＥＱＵＥＳＴメッセージに含まれるＵＲＩに対応する鍵情報を、鍵情報テーブル１４６から取得する（ステップＳ１００９）。また、取得部１１３は、当該ＵＲＩに対応するマルチキャストアドレスをアドレステーブル１４５から取得する。
【００８１】
次に、通知メッセージ処理部１０３は、取得した鍵情報を含むＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを生成する（ステップＳ１０１０）。なお、当該ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージには、端末２００に通知すべきプレゼンス情報と、マルチキャストグループ情報とが含まれる。マルチキャストグループ情報とは、マルチキャストアドレス情報と、鍵情報とを含む情報をいう。
【００８２】
このとき、通知メッセージ処理部１０３は、鍵情報を含むマルチキャストグループ情報を暗号化するように構成してもよい。例えば、通知メッセージ処理部１０３は、既存の鍵交換プロトコルであるＭＩＫＥＹにしたがって暗号化した鍵情報を含むメッセージを生成するように構成することができる。
【００８３】
通知メッセージ処理部１０３は、対応テーブル１４３から取得したプレゼンティティ名に対応するプレゼンス情報をプレゼンス情報テーブル１４２から取得し、通知すべきプレゼンス情報とする。
【００８４】
次に、送信部１２１は、生成したＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを、ＳＩＰ  ＳＵＢＳＣＲＩＢＥメッセージに対応する最初のＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージとして端末２００に対して送信する（ステップＳ１０１１）。
【００８５】
なお、ステップＳ１００８で、購読対象がマルチキャストグループでないと判断された場合は（ステップＳ１００８：ＮＯ）、鍵交換を行う必要がないため、送信部１２１は、鍵情報を含まない通常のＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを端末２００に対して送信する。
【００８６】
図１１は、鍵情報を含むＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージの形式の一例を示す説明図である。同図は、プレゼンス情報を表現する仕様であるＰＩＤＦ（Presence Information Data Format）を拡張したメッセージ形式の一例を示している。
【００８７】
同図のメッセージ形式では、プレゼンティティである「alice@example.com」のプレゼンス情報とともに、ＭＩＫＥＹ鍵交換プロトコルにより暗号鍵を交換するための情報を含む、プレゼンティティであるマルチキャストグループ「group-X@example.com」のプレゼンス情報が含まれている。
【００８８】
図１０に戻り、端末２００の受信部２２２は、ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを受信する（ステップＳ１０１２）。次に、端末２００の通知メッセージ処理部２０３は、受信したＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージに含まれる鍵情報を設定する（ステップＳ１０１３）。鍵情報を設定するとは、メッセージから鍵情報を抽出し、セキュアなＩＰマルチキャスト通信が可能となるように抽出した鍵情報を装置内に組み込むことをいう。なお、通知メッセージ処理部２０３は、メッセージに含まれるマルチキャストアドレスの設定等も同時に行う。
【００８９】
次に、通知メッセージ処理部２０３は、ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージに対する応答である、ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＳＰＯＮＳＥメッセージを生成する（ステップＳ１０１４）。
【００９０】
なお、通知メッセージ処理部２０３は、ＭＩＫＥＹなどの鍵交換に使用しているプロトコルに規定されるデータを含むメッセージを生成するように構成してもよい。例えば、端末２００とプレゼンスサーバ１００の間で相互認証を行うための、端末２００のＩＤ情報などが含まれるかもしれない。
【００９１】
図１２は、ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＳＰＯＮＳＥメッセージの形式の一例を示す説明図である。同図は、ＰＩＤＦを拡張したメッセージ形式の一例を示している。同図の例では、マルチキャストグループ「group-X@example.com」のためのＭＩＫＥＹ鍵交換プロトコルによる相互認証メッセージを含むメッセージ形式が示されている。
【００９２】
図１０に戻り、送信部２２１は、生成したＳＩＰ  ＮＯＴＩＦＹ  ＲＥＳＰＯＮＳＥメッセージをプレゼンスサーバ１００に送信する（ステップＳ１０１５）。プレゼンスサーバ１００の受信部１２２は、ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＳＰＯＮＳＥメッセージを受信し（ステップＳ１０１６）、鍵交換処理を終了する。
【００９３】
以上の処理により、他の端末２００すべてと相互に鍵交換を行うことなく、事前にプレゼンスサーバ１００に保存された鍵情報の配布を受けることにより、効率的に鍵交換を行い、ＩＰマルチキャスト通信時の処理負担を軽減することができる。
【００９４】
次に、端末２００のプレゼンス情報の更新が行われた場合の鍵交換処理のシーケンスについて説明する。図１３は、この場合の鍵交換処理の全体の流れを示すシーケンス図である。
【００９５】
まず、端末２００の送信部２２１は、自装置のプレゼンス情報の発行メッセージ（ＳＩＰ  ＰＵＢＬＩＳＨ  ＲＥＱＵＥＳＴメッセージ）をプレゼンスサーバ１００に対して送信する（ステップＳ１３０１）。
【００９６】
なお、ＳＩＰ  ＰＵＢＬＩＳＨ  ＲＥＱＵＥＳＴメッセージは、端末２００の発行メッセージ処理部２０１によって作成される。
【００９７】
次に、プレゼンスサーバ１００の受信部１２２は、ＳＩＰ  ＰＵＢＬＩＳＨ  ＲＥＱＵＥＳＴメッセージを受信する（ステップＳ１３０２）。続いて、認証部１１２が、ＳＩＰ  ＰＵＢＬＩＳＨ  ＲＥＱＵＥＳＴメッセージに含まれる認証情報を用いて端末２００の認証処理を行う（ステップＳ１３０３）。
【００９８】
端末２００が認証された場合は、発行メッセージ処理部１０１は、プレゼンティティ情報テーブル１４１を参照し、同テーブルに保存済みのプレゼンティティでない場合、すなわち、当該端末２００から最初にＳＩＰ  ＰＵＢＬＩＳＨ  ＲＥＱＵＥＳＴメッセージを受信した場合には、当該メッセージに含まれる端末２００のＵＲＩをプレゼンティティ情報テーブル１４１に追加する（ステップＳ１３０４）。
【００９９】
また、発行メッセージ処理部１０１は、受信したメッセージに含まれるプレゼンス情報をプレゼンス情報テーブル１４２に登録する。既にプレゼンティティとして登録済みの端末２００の場合は、受信したメッセージに含まれるプレゼンス情報で対応するプレゼンティティのプレゼンス情報を更新する。
【０１００】
次に、発行メッセージ処理部１０１は、ＳＩＰ  ＰＵＢＬＩＳＨ  ＲＥＳＰＯＮＳＥメッセージを生成する（ステップＳ１３０５）。生成したメッセージは、送信部１２１が端末２００に送信する（ステップＳ１３０６）。
【０１０１】
端末２００の受信部２２２は、送信されたＳＩＰ  ＰＵＢＬＩＳＨ  ＲＥＳＰＯＮＳＥメッセージを受信する（ステップＳ１３０７）。
【０１０２】
次に、発行メッセージ処理部１０１は、定義情報テーブル１４４でプレゼンス情報の条件で定義されたマルチキャストグループのメンバ（ウォッチャーリスト）を再構成する（ステップＳ１３０８）。プレゼンス情報を更新した場合、プレゼンス情報の条件で定義されたマルチキャストグループのメンバが変更される場合があるためである。
【０１０３】
次に、発行メッセージ処理部１０１は、マルチキャストグループが更新されたか否かを判断する（ステップＳ１３０９）。更新されていない場合は（ステップＳ１３０９：ＮＯ）、鍵交換を行う必要がないため、鍵交換処理を終了する。
【０１０４】
更新されている場合は（ステップＳ１３０９：ＹＥＳ）、取得部１１３は、更新したマルチキャストグループの鍵情報を、鍵情報テーブル１４６から取得する（ステップＳ１３１０）。また、取得部１１３は、更新したマルチキャストグループのマルチキャストアドレスをアドレステーブル１４５から取得する。
【０１０５】
次に、通知メッセージ処理部１０３は、取得した鍵情報を含むＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを生成する（ステップＳ１３１１）。
【０１０６】
次に、送信部１２１は、生成したＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを、更新したマルチキャストグループのウォッチャーである端末２００に送信する（ステップＳ１３１２）。なお、送信する端末２００は、対応テーブル１４３を参照して取得する。
【０１０７】
ただし、マルチキャストグループのウォッチャーが単に新規に追加されただけであり、また、後述するような、現在該当のマルチキャストグループで使用している鍵を更新しない場合、新しく該当のマルチキャストグループに加わった端末（これは通常、上述のＰＵＢＬＩＳＨ  ＲＥＱＵＥＳＴを送信した端末である）に対してのみ、ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴを送信し、該当のマルチキャストグループを構成するその他の端末には送信しないことも可能である。
【０１０８】
ステップＳ１３１３からステップＳ１３１７までの、ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージ送受信処理、ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＳＰＯＮＳＥメッセージ送受信処理は、図１０のステップＳ１０１２からステップＳ１０１６までと同様の処理なのでその説明を省略する。
【０１０９】
また、ステップＳ１３１８からステップＳ１３２１は、プレゼンス情報を通知する必要がある他の端末２００上での処理を表し、ステップＳ１３１３からステップＳ１３１６と同様の処理なのでその説明を省略する。
【０１１０】
なお、このＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージ送信処理は、ＳＩＰ  ＰＵＢＬＩＳＨ  ＲＥＳＰＯＮＳＥメッセージの処理の直後に行う必要はない。例えば、その他のプレゼンティティの情報、マルチキャストグループ情報、またはグループ定義情報等が更新され、それに応じてＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを送信するときに同時に行うように構成してもよい。また、複数のＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを合わせて１つのＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージとして送信するように構成してもよい。
【０１１１】
これにより、鍵交換のためのメッセージ送信とプレゼンス情報通知のためのメッセージ送信を統合することができるため、システム構成を単純化し、ネットワークトラフィックを削減することができる。
【０１１２】
さらに、ウォッチャーリストに含まれる各端末２００に対し、同時のタイミングでメッセージ送信を行う必要はない。また、ＳＩＰ  ＮＯＴＩＦＹメッセージ交換は、マルチキャストグループ情報を新規に通知する必要のある端末２００との間のみで行うように構成してもよい。
【０１１３】
以上の処理により、プレゼンス情報の更新が行われた場合にも、必要な端末２００に鍵情報を事前に配布することが可能となる。
【０１１４】
次に、プレゼンスサーバ１００で鍵情報の更新が行われた場合の鍵交換処理のシーケンスについて説明する。図１４は、この場合の鍵交換処理の全体の流れを示すシーケンス図である。
【０１１５】
まず、プレゼンスサーバ１００の生成部１１４は、任意のタイミング、例えば、周期的に、または、マルチキャストグループのメンバが変更された場合に、暗号鍵を新たに生成する（ステップＳ１４０１）。なお、上述のように、プレゼンスサーバ１００自身が乱数を発生させて鍵を新たに生成してもよいし、端末２００が生成し、任意のメッセージでプレゼンスサーバ１００に通知するように構成してもよい。
【０１１６】
次に、登録部１１５は、生成した暗号鍵を対応するマルチキャストグループの鍵情報として鍵情報テーブル１４６に登録する（ステップＳ１４０２）。
【０１１７】
次に、通知メッセージ処理部１０３は、登録した鍵情報とマルチキャストアドレスを含むＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを生成する（ステップＳ１４０３）。
【０１１８】
次に、送信部１２１は、生成したＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを、鍵情報を更新したマルチキャストグループのウォッチャーである端末２００に送信する（ステップＳ１４０４）。なお、送信する端末２００は、対応テーブル１４３を参照して取得する。
【０１１９】
ステップＳ１４０５からステップＳ１４１３までの、ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージ送受信処理、ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＳＰＯＮＳＥメッセージ送受信処理は、図１３のステップＳ１３１３からステップＳ１３２１までと同様の処理なのでその説明を省略する。
【０１２０】
以上の処理により、プレゼンスサーバ１００で鍵情報の更新が行われた場合にも、必要な端末２００に鍵情報を適切に配布することが可能となる。
【０１２１】
次に、プレゼンスサーバ１００でマルチキャストグループの新規グループ定義、または、マルチキャストグループ定義の更新が行われた場合の鍵交換処理のシーケンスについて説明する。図１５は、この場合の鍵交換処理の全体の流れを示すシーケンス図である。
【０１２２】
まず、プレゼンスサーバ１００の受付部１１１が、ユーザによるグループ定義情報の入力を受付ける（ステップＳ１５０１）。登録部１１５は、受付けたグループ定義情報を定義情報テーブル１４４に登録する（ステップＳ１５０２）。これにより、ユーザは、マルチキャストグループの定義の新規作成や更新を行うことができる。
【０１２３】
プレゼンス情報の条件により定義されたグループ定義情報の場合は、通知メッセージ処理部１０３は、プレゼンス情報テーブル１４２を参照して条件を満たすプレゼンス情報を有する端末２００の情報を取得することにより、対応テーブル１４３の対応するマルチキャストグループを再構成する（ステップＳ１５０３）。
【０１２４】
なお、端末２００のＵＲＩのリストによって定義されたグループ定義情報の場合は、当該リストがそのまま対応テーブル１４３のウォッチャーリストに反映される。また、対応テーブル１４３を更新した際、鍵情報を生成部１１４により生成し、生成した鍵情報により鍵情報テーブル１４６を更新するように構成してもよい。
【０１２５】
次に、取得部１１３は、グループ定義情報を追加または更新したマルチキャストグループに対応する鍵情報を鍵情報テーブル１４６から取得する（ステップＳ１５０４）。また、取得部１１３は、グループ定義情報を追加または更新したマルチキャストグループのマルチキャストアドレスをアドレステーブル１４５から取得する。
【０１２６】
次に、通知メッセージ処理部１０３は、取得した鍵情報を含むＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを生成する（ステップＳ１５０５）。
【０１２７】
次に、送信部１２１は、生成したＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを、グループ定義情報を追加または更新したマルチキャストグループのウォッチャーである端末２００に送信する（ステップＳ１５０６）。なお、送信する端末２００は、対応テーブル１４３を参照して取得する。
【０１２８】
ステップＳ１５０７からステップＳ１５１５までの、ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージ送受信処理、ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＳＰＯＮＳＥメッセージ送受信処理は、図１３のステップＳ１３１３からステップＳ１３２１までと同様の処理なのでその説明を省略する。
【０１２９】
以上の処理により、プレゼンスサーバ１００で新規グループの追加またはグループ定義の更新が行われた場合にも、必要な端末２００に鍵情報を適切に配布することが可能となる。
【０１３０】
なお、以上で説明したすべての鍵交換シーケンスは、あるマルチキャストグループに対して、常に１種類の鍵の鍵交換しか行わない。よって、あるマルチキャストグループに対して、異なる鍵の鍵交換を同時に実行することはない。
【０１３１】
次に、実際にセキュアなＩＰマルチキャスト通信が行われる際のデータ通信処理について説明する。まず、データ通信処理時の暗号化鍵の選択方法について説明する。
【０１３２】
上述のシーケンスにより、任意のマルチキャストグループに含まれる端末２００は、対応するアドレス情報および鍵情報を、例えばＭＩＫＥＹなどのＳＩＰメッセージ上で実行された鍵交換プロトコルにより取得する。
【０１３３】
端末２００は、マルチキャストグループごとに、少なくとも２つのアドレス情報および鍵情報を保持することができる。ここではその２つのアドレス情報および鍵情報を、それぞれ最新有効鍵情報と、有効鍵情報と呼ぶ。
【０１３４】
最新有効鍵情報とは、上述の鍵交換シーケンスで取得したアドレス情報および鍵情報をいう。すなわち、端末２００は、取得したアドレス情報および鍵情報を、対応するマルチキャストグループの最新有効鍵情報として保持する。
【０１３５】
有効鍵情報とは、最新有効鍵情報の前に取得した鍵情報をいう。したがって、端末２００は、鍵交換プロトコルなどにより新たに対応するマルチキャストグループのアドレス情報および鍵情報を取得した場合、現在保持している最新有効鍵情報を有効鍵情報にコピーし、新たに取得した鍵情報を最新有効鍵情報に保持する。
【０１３６】
なお、有効鍵情報を保持していない場合、すなわち、最初にアドレス情報および鍵情報を鍵交換シーケンスで取得した場合は、最新有効鍵情報を有効鍵情報にコピーする。以後、端末２００は、対応するマルチキャストグループに対し、常に、少なくとも最新有効鍵情報と有効鍵情報の２つを保持し、マルチキャスト通信用に設定する。
【０１３７】
ＩＰマルチキャストのためのネットワーク設定は、各端末２００がＩＧＭＰ（Internet Group Management Protocol）などのプロトコルを利用した従来と同様の方法によって行う。
【０１３８】
このように、マルチキャストグループに含まれる端末２００は、最新有効鍵情報と、有効鍵情報の少なくとも２つの暗号化鍵とそのＩＤを保持している。
【０１３９】
暗号化されたマルチキャストデータを受信した場合、端末２００は、受信部２２２で暗号化されたデータを含むパケットから、暗号化に使用されている鍵のＩＤを識別し、そのＩＤに対応する鍵が、最新有効鍵情報に含まれる暗号鍵であるか有効鍵情報に含まれる鍵であるかを判断し、該当する鍵を使ってデータを復号する。このような機能は、例えば、ＳＲＴＰなどで実現可能である。
【０１４０】
一方、マルチキャストデータを暗号化して送信する端末２００は、暗号化に使用する鍵を選択する際、常に、対応するマルチキャストグループの有効鍵情報の暗号鍵を選択する。本実施の形態におけるプレゼンスサーバ１００を含んだ通信システムは、対応するマルチキャストグループに関して、ある鍵に関する鍵交換が終了する前に、別の鍵に関する鍵交換を開始することはないことに注意が必要である。よって、常に有効鍵情報の暗号鍵を選択してこれによりマルチキャストデータを暗号化して送信すれば、マルチキャストグループを構成する端末２００のすべてが、既に最新有効鍵情報または有効鍵情報として保持している鍵によって、マルチキャストデータを受信し復号化することができる。
【０１４１】
この他、使用する鍵情報の決定方法としては、現在使用可能な暗号鍵のＩＤの情報をＳＩＰ  ＮＯＴＩＦＹメッセージなどを用いてプレゼンスサーバ１００から通知を受け、通知された情報によりデータ送信に使用する方法も適用可能である。
【０１４２】
次に、マルチキャストデータ通信の開始・終了に関する処理について説明する。通常のマルチキャストデータ通信のように、送信端末が、暗号化したメディアデータをマルチキャストアドレスに宛てて単純に送信するだけの構成も可能である。一方、端末２００を、常にメディアデータ受信可能な状態に設定しておくことが難しく、マルチキャストデータ通信が開始される際にメディア受信状態を開始し、マルチキャストデータ通信が終了する際に、メディア受信状態を解除することが必要となる場合がある。
【０１４３】
以下では、このような場合に、セキュアなマルチキャストデータ通信を開始するシーケンスについて説明する。図１６は、第１の実施の形態におけるデータ通信開始処理の全体の流れを示すシーケンス図である。
【０１４４】
まず、メディアデータ送信を開始する端末２００（以下、送信端末２００という。）の送信部２２１は、送信を開始するマルチキャストグループの情報を含んだＳＩＰ  ＰＵＢＬＩＳＨ  ＲＥＱＵＥＳＴメッセージを送信することにより、プレゼンスサーバ１００に対してメディアデータ送信を開始することを通知する（ステップＳ１６０１）。なお、このメッセージは、発行メッセージ処理部２０１により生成する。
【０１４５】
次に、プレゼンスサーバ１００の受信部１２２は、ＳＩＰ  ＰＵＢＬＩＳＨ  ＲＥＱＵＥＳＴメッセージを受信する（ステップＳ１６０２）。次に、認証部１１２が、当該メッセージに含まれる認証情報を用いて送信端末２００の認証を行う（ステップＳ１６０３）。ここでは、送信端末２００が送信対象となるマルチキャストグループに対して通信可能か否かの認証を行う。なお、認証処理を行わないように構成してもよい。また、外部の認証サーバ等を利用するように構成してもよい。
【０１４６】
送信端末２００が認証された場合は、通知メッセージ処理部１０３は、メディアデータ送信が開始されることを通知するため、対応するマルチキャストアドレス情報を含むＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを生成する（ステップＳ１６０４）。
【０１４７】
この際、通知メッセージ処理部１０３は、当該マルチキャストグループのマルチキャストアドレスをアドレステーブル１４５から取得する。また、通知メッセージ処理部１０３は、受信したメッセージに含まれるマルチキャストグループの情報を参照し、当該マルチキャストグループを構成する端末２００（以下、受信端末２００という。）を対応テーブル１４３から取得する。
【０１４８】
次に、通知メッセージ処理部１０３は、生成したＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを受信端末２００に送信する（ステップＳ１６０５）。
【０１４９】
受信端末２００の受信部２２２は、ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを受信し（ステップＳ１６０６）、受信したメッセージから、送信が開始されるメディアのマルチキャストグループ情報を取得する。
【０１５０】
次に、通知メッセージ処理部２０３が、メディアデータ受信状態を開始する（ステップＳ１６０７）。具体的には、通知メッセージ処理部２０３は、取得したマルチキャストグループ情報より、送信が開始されるメディアのマルチキャストグループを特定し、該当のマルチキャストグループ宛のデータの受信準備を行うよう、受信部２２２に通知する。この際、取得したマルチキャストグループ情報に含まれるマルチキャストアドレスからのメディアデータを、取得したマルチキャストグループ情報に含まれるマルチキャストアドレスや鍵のＩＤなどの鍵情報を用いて受信可能な状態に設定することも可能である。
【０１５１】
次に、通知メッセージ処理部２０３は、ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＳＰＯＮＳＥメッセージを生成する（ステップＳ１６０８）。生成したメッセージは、送信部２２１がプレゼンスサーバ１００に対して送信する（ステップＳ１６０９）。
【０１５２】
次に、プレゼンスサーバ１００の受信部１２２は、ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＳＰＯＮＳＥメッセージを受信する（ステップＳ１６１０）。
【０１５３】
続いて、プレゼンスサーバ１００の通知メッセージ処理部１０３が、ＳＩＰ  ＰＵＢＬＩＳＨ  ＲＥＳＰＯＮＳＥメッセージを生成し（ステップＳ１６１１）、送信部１２１が、生成したメッセージを送信端末２００に送信する（ステップＳ１６１２）。
【０１５４】
ＳＩＰ  ＰＵＢＬＩＳＨ  ＲＥＳＰＯＮＳＥメッセージの送信は、マルチキャストグループのすべての受信端末２００からのＳＩＰ  ＮＯＴＩＦＹ  ＲＥＳＰＯＮＳＥメッセージの受信を行った後に行う。なお、送信端末２００からＳＩＰ  ＰＵＢＬＩＳＨ  ＲＥＱＵＥＳＴメッセージを受信した直後に行ってもよい。
【０１５５】
また、この際、プレゼンスサーバ１００は、複数の送信端末２００によって同一のマルチキャストグループに対してデータ送信が行われないようにするため、現在メディアデータを送信している送信端末２００の情報を、プレゼンティティ情報テーブル１４１などにて保持するように構成してもよい。
【０１５６】
すなわち、ある送信端末２００に対してマルチキャストグループへのデータ送信を認可している場合は、その他の送信端末２００に対して、当該マルチキャストグループへのデータ送信を認可しないように構成してもよい。これにより、プレゼンスサーバ１００は、送信端末２００に対して、マルチキャストグループへのデータ送信を排他的に許可することが可能となる。
【０１５７】
次に、送信端末２００の受信部２２２は、ＳＩＰ  ＰＵＢＬＩＳＨ  ＲＥＳＰＯＮＳＥメッセージを受信する（ステップＳ１６１３）。このメッセージを受信した後、送信端末２００は、実際のメディアデータの送信を行うことができる。
【０１５８】
すなわち、送信端末２００の送信部２２１が、メディアデータの送信を行い（ステップＳ１６１４）、受信端末２００の受信部２２２が、当該メディアデータの受信を行う（ステップＳ１６１５）。
【０１５９】
以上のような処理により、常にメディアデータ受信可能な状態に設定することなく、適切にメディアデータの送信処理を開始することが可能となる。
【０１６０】
次に、このようにして開始したセキュアなマルチキャストデータ通信を終了するシーケンスについて説明する。図１７は、第１の実施の形態におけるデータ通信終了処理の全体の流れを示すシーケンス図である。
【０１６１】
送信端末２００は、メディアデータ送信が終了すると、メディアデータ送信が終了したことを通知するためのＳＩＰ  ＰＵＢＬＩＳＨ  ＲＥＱＵＥＳＴメッセージを、プレゼンスサーバ１００に対して送信する（ステップＳ１７０１）。
【０１６２】
次に、プレゼンスサーバ１００の受信部１２２は、ＳＩＰ  ＰＵＢＬＩＳＨ  ＲＥＱＵＥＳＴメッセージを受信する（ステップＳ１７０２）。なお、排他制御のためプレゼンティティ情報テーブル１４１などに現在メディアデータを送信している送信端末２００の情報を保存している場合は、当該情報を削除するように構成してもよい。
【０１６３】
次に、通知メッセージ処理部１０３は、メディアデータ送信が終了されることを通知するため、対応するマルチキャストアドレス情報を含むＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを生成する（ステップＳ１７０３）。
【０１６４】
この際、通知メッセージ処理部１０３は、当該マルチキャストグループのマルチキャストアドレスをアドレステーブル１４５から取得する。また、通知メッセージ処理部１０３は、受信したメッセージに含まれるマルチキャストグループの情報を参照し、当該マルチキャストグループを構成する受信端末２００を対応テーブル１４３から取得する。
【０１６５】
次に、通知メッセージ処理部１０３は、生成したＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを受信端末２００に送信する（ステップＳ１７０４）。
【０１６６】
受信端末２００の受信部２２２は、ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを受信し（ステップＳ１７０５）、受信したメッセージから、送信が終了するメディアのマルチキャストグループ情報を取得する。
【０１６７】
次に、通知メッセージ処理部２０３が、メディアデータ受信状態を解除する（ステップＳ１７０６）。具体的には、通知メッセージ処理部２０３は、取得したマルチキャストグループ情報に含まれるマルチキャストアドレスからのメディアデータを受信できない状態に設定する。
【０１６８】
ステップＳ１７０７からステップＳ１７１２までの、ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＳＰＯＮＳＥメッセージ送受信処理、ＳＩＰ  ＰＵＢＬＩＳＨ  ＲＥＳＰＯＮＳＥメッセージ送受信処理は、図１６のステップＳ１６０８からステップＳ１６１３までと同様の処理なのでその説明を省略する。
【０１６９】
以上のような処理により、適切にメディアデータの送信処理の終了を通知することができるため、常にメディアデータ受信可能な状態に設定する必要がなくなる。
【０１７０】
次に、従来技術と比較した本実施の形態の鍵配布処理シーケンスの相違について説明する。図１８は、従来技術におけるプレゼンスサーバを含む通信システムの構成を示す概念図である。
【０１７１】
同図に示すように、従来の通信システムは、本実施の形態と同様にＰｒｏｘｙ１８０１、端末１８０２、およびプレゼンスサーバ１８０３を含むが、従来の通信システムでは、Ｐｒｏｘｙ１８０１を介して各端末相互で鍵交換を行う必要がある。
【０１７２】
図１９は、従来の通信システムによる鍵交換処理のシーケンスの概要を示した説明図である。
【０１７３】
まず、セキュアなＩＰマルチキャスト通信を所望する端末１８０２は、Ｐｒｏｘｙ１８０１に対してＩＮＶＩＴＥ−Ｒｅｑｕｅｓｔを送信する（ステップＳ１９０１）。ＩＰマルチキャストグループのメンバシップ情報は、端末１８０２が指定してもよいし、Ｐｒｏｘｙ１８０１で保持してもよい。
【０１７４】
ＩＮＶＩＴＥ−Ｒｅｑｕｅｓｔを受信したＰｒｏｘｙ１８０１は、メッセージをフォークさせ、ＩＰマルチキャストグループを構成する全メンバとなる端末に対してＩＮＶＩＴＥ−Ｒｅｑｕｅｓｔをコピーして転送する（ステップＳ１９０２）。
【０１７５】
その後、ＩＰマルチキャスト通信を所望する端末１８０２と、ＩＰマルチキャストグループを構成するメンバ端末は、オファーアンサーモデルに従い、ＩＮＶＩＴＥ−Ｒｅｓｐｏｎｓｅ（２００ＯＫ）（ステップＳ１９０３、ステップＳ１９０４）、ＡＣＫのメッセージ（ステップＳ１９０５）を交換する。
【０１７６】
これにより、ＩＰマルチキャスト通信を所望する端末１８０２は、全グループメンバ端末との間でマルチキャストメッセージを暗号化するための暗号化鍵を交換する。これらの鍵交換がすべて終わった後、セキュアなＩＰマルチキャスト通信が実行される（ステップＳ１９０６）。
【０１７７】
このように、従来の方法では、すべてのメンバ間での鍵交換が完了してからＩＰマルチキャスト通信を開始するため、通信開始までの時間的コストが過大となる場合があった。
【０１７８】
なお、従来技術におけるプレゼンスサーバ１８０３は、端末に対して各種プレゼンス情報の通知を行うのみであり、ＳＩＰベースシステムにおけるＩＰマルチキャスト通信のための鍵交換とは無関係である。
【０１７９】
図２０は、本実施の形態における通信システムによる鍵交換処理のシーケンスの概要を示した説明図である。
【０１８０】
詳細は上述したとおりであるので省略するが、同図に示すように、本実施の形態では、Ｐｒｏｘｙではなく、プレゼンスサーバ１００により鍵交換処理を行うことができる。また、端末２００が起動したときに、ＳＩＰ  ＳＵＢＳＣＲＩＢＥ  ＲＥＱＵＥＳＴメッセージ、ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージ等を用いて、事前に登録されている鍵情報をプレゼンスサーバ１００から取得できるため、他の端末２００と相互に鍵情報を交換する必要がない。
【０１８１】
このように、第１の実施の形態にかかるサーバ装置は、プレゼンスサーバ機能を利用して、事前にＩＰマルチキャストのための鍵交換を行うことができる。さらに、鍵交換プロトコルのためのメッセージ送信とプレゼンス情報送信のためのメッセージ送信を統合することができるため、ＳＩＰベースのシステムでセキュアなＩＰマルチキャスト通信を開始するまでにかかる時間的コストを削減することができる。
【０１８２】
（第２の実施の形態）
従来、セキュアなＩＰマルチキャスト通信を行うグループに対して、グループメンバでない端末がデータ送信を行うことは許されておらず、そのためには、一時的に対象となるＩＰマルチキャスト通信を行うグループに参加することが必要であった。
【０１８３】
第２の実施の形態にかかるサーバ装置は、セキュアなＩＰマルチキャストグループに対するデータ送信を所望する端末に対して、一時的に利用可能な暗号化鍵を送信するものである。これにより、端末がマルチキャストグループへ参加する処理などの特別な処理を必要とすることなく、セキュアなＩＰマルチキャスト通信を実現できる。
【０１８４】
図２１は、第２の実施の形態にかかるサーバ装置であるプレゼンスサーバ２３００を含む通信システムの構成を示す概念図である。本通信システムでは、マルチキャストグループに属さないが当該グループに対してメディアデータの送信を所望する端末である送信端末２１００ｚを含む点が、第１の実施の形態にかかる通信システムを表す図１と異なっている。
【０１８５】
なお、受信端末２１００ａ〜２１００ｈと送信端末２１００ｚは、同一のマルチキャストグループに属するか否かが異なる。なお、以下では、単に受信端末２１００、送信端末２１００という。
【０１８６】
図２２は、第２の実施の形態にかかる受信端末２１００および送信端末２１００の構成を示すブロック図である。同図に示すように、受信端末２１００および送信端末２１００は、音声入出力部２１１と、データ入出力部２１２と、発行メッセージ処理部２０１と、購読メッセージ処理部２０２と、通知メッセージ処理部２０３と、セッション制御メッセージ処理部２２０４と、送信部２２１と、受信部２２２とを備えている。
【０１８７】
第２の実施の形態では、セッション制御メッセージ処理部２２０４を追加したことが第１の実施の形態と異なっている。その他の構成および機能は、第１の実施の形態にかかる端末２００の構成を表すブロック図である図２と同様であるので、同一符号を付し、ここでの説明は省略する。
【０１８８】
セッション制御メッセージ処理部２２０４は、プレゼンスサーバ２３００から受信したセッション制御要求メッセージ（後述）に関する処理を行うものである。具体的には、セッション制御メッセージ処理部２２０４は、セッション制御要求メッセージに含まれる鍵情報を取得して設定する処理や、セッション制御要求メッセージに対する応答であるＡＣＫメッセージの生成を行う。
【０１８９】
図２３は、第２の実施の形態にかかるサーバ装置であるプレゼンスサーバ２３００の構成を示すブロック図である。同図に示すように、プレゼンスサーバ２３００は、記憶部１４０と、受付部１１１と、認証部１１２と、取得部１１３と、生成部１１４と、登録部１１５と、発行メッセージ処理部１０１と、購読メッセージ処理部１０２と、通知メッセージ処理部１０３と、セッション制御メッセージ処理部２３０４と、送信部１２１と、受信部１２２とを備えている。
【０１９０】
第２の実施の形態では、セッション制御メッセージ処理部２３０４を追加したことが第１の実施の形態と異なっている。その他の構成および機能は、第１の実施の形態にかかるプレゼンスサーバ１００の構成を表すブロック図である図３と同様であるので、同一符号を付し、ここでの説明は省略する。
【０１９１】
セッション制御メッセージ処理部２３０４は、プレゼンスサーバ２３００が管理するマルチキャストグループに対してマルチキャスト通信の開始を要求するセッション制御要求メッセージを処理するものである。セッション制御メッセージ処理部２３０４は、セッション制御要求メッセージとして、例えば、ＳＩＰ  ＩＮＶＩＴＥメッセージを用いることができる。なお、セッション制御要求メッセージのメッセージ形式はこれに限られるものではなく、マルチキャスト通信の開始を要求できるものであればあらゆる形式のメッセージを用いることができる。
【０１９２】
次に、このように構成された第２の実施の形態にかかるサーバ装置２３００による鍵交換処理について説明する。図２４は、第２の実施の形態における鍵交換処理の全体の流れを示すフローチャートである。
【０１９３】
まず、送信端末２１００の送信部２２１は、通信を行うマルチキャストグループを識別するＵＲＩを含むＳＩＰ  ＩＮＶＩＴＥ  ＲＥＱＵＥＳＴメッセージをプレゼンスサーバ２３００に対して送信する（ステップＳ２４０１）。なお、ＳＩＰ  ＩＮＶＩＴＥ  ＲＥＱＵＥＳＴメッセージは、セッション制御メッセージ処理部２２０４が生成する。
【０１９４】
次に、プレゼンスサーバ２３００の受信部１２２は、ＳＩＰ  ＩＮＶＩＴＥ  ＲＥＱＵＥＳＴメッセージを受信する（ステップＳ２４０２）。
【０１９５】
次に、認証部１１２が、送信端末２１００によるマルチキャストグループに対するデータ送信の認可を確認する（ステップＳ２４０３）。この際、プレゼンスサーバ２３００は、外部の認証サーバなどを利用するように構成してもよい。
【０１９６】
認可された場合、取得部１１３は、ＳＩＰ  ＩＮＶＩＴＥ  ＲＥＱＵＥＳＴメッセージに含まれるマルチキャストグループのＵＲＩを用いて、当該マルチキャストグループに対応する鍵情報を鍵情報テーブル１４６から取得する（ステップＳ２４０４）。また、取得部１１３は、当該ＵＲＩに対応するマルチキャストアドレスをアドレステーブル１４５から取得する。
【０１９７】
次に、セッション制御メッセージ処理部２３０４は、取得した鍵情報を含むＳＩＰ  ＩＮＶＩＴＥ  ＲＥＳＰＯＮＳＥメッセージを生成する（ステップＳ２４０５）。具体的には、セッション制御メッセージ処理部２３０４は、マルチキャストアドレス情報と、鍵情報とを含むマルチキャストグループ情報を含むＳＩＰ  ＩＮＶＩＴＥ  ＲＥＳＰＯＮＳＥメッセージを生成する。マルチキャストアドレス情報はアドレステーブル１４５から取得する。
【０１９８】
このとき、セッション制御メッセージ処理部２３０４は、鍵情報を含むマルチキャストグループ情報を暗号化するように構成してもよい。例えば、セッション制御メッセージ処理部２３０４は、ＭＩＫＥＹにしたがって暗号化した鍵情報を含むメッセージを生成するように構成することができる。
【０１９９】
次に、送信部１２１は、生成したＳＩＰ  ＩＮＶＩＴＥ  ＲＥＳＰＯＮＳＥメッセージを送信端末２１００に送信する（ステップＳ２４０６）。
【０２００】
なお、この際、プレゼンスサーバ２３００は、複数の送信端末２００によって同一のマルチキャストグループに対してデータ送信が行われないようにするため、現在鍵情報を保持している送信端末２１００の情報を、プレゼンティティ情報テーブル１４１などにて保持するように構成してもよい。
【０２０１】
すなわち、ある送信端末２１００に対してマルチキャストグループへのデータ送信を認可している場合は、その他の送信端末２１００に対して、当該マルチキャストグループへのデータ送信を認可しないように構成してもよい。これにより、プレゼンスサーバ２３００は、送信端末２１００に対して、マルチキャストグループへのデータ送信を排他的に許可することが可能となる。
【０２０２】
次に、送信端末２１００の受信部２２２は、ＳＩＰ  ＩＮＶＩＴＥ  ＲＥＳＰＯＮＳＥメッセージを受信する（ステップＳ２４０７）。次に、送信端末２１００のセッション制御メッセージ処理部２２０４は、受信したＳＩＰ  ＩＮＶＩＴＥ  ＲＥＳＰＯＮＳＥメッセージに含まれる鍵情報を設定する（ステップＳ２４０８）。
【０２０３】
次に、セッション制御メッセージ処理部２２０４は、ＡＣＫメッセージを生成し（ステップＳ２４０９）、送信部２２１が、生成したＡＣＫメッセージをプレゼンスサーバ２３００に送信する（ステップＳ２４１０）。次に、プレゼンスサーバ２３００の受信部１２２は、ＡＣＫメッセージを受信する（ステップＳ２４１１）。
【０２０４】
なお、セッション制御メッセージ処理部２２０４は、ＭＩＫＥＹなどの鍵交換に使用しているプロトコルに規定されるデータを含むＡＣＫメッセージを生成するように構成してもよい。例えば、送信端末２１００とプレゼンスサーバ２３００の間で相互認証を行うための、送信端末２１００のＩＤ情報などが含まれるかもしれない。
【０２０５】
また、この際、プレゼンスサーバ２３００は、通知メッセージ処理部１０３によって、ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを受信端末２１００に送信し、マルチキャストデータ送信が開始されること、またはマルチキャストデータ送信に関する送信端末２１００の情報およびタイミングに関する情報などを通知してもよい（ステップＳ２４１２、ステップＳ２４１３）。
【０２０６】
これに対応し、受信端末２１００は、通知メッセージ処理部２０３により、受信したメッセージに含まれる情報から開始されるマルチキャストのデータ通信のタイミングなどの情報を取得し、メディア受信状態を開始するように構成してもよい（ステップＳ２４１４、ステップＳ２４１５）。
【０２０７】
なお、これらの処理を表すステップＳ２４１２からステップＳ２４１８は、第１の実施の形態のおける図１６のステップＳ１６０４からステップＳ１６１０までと同様の処理であるため、詳細な説明は省略する。
【０２０８】
この後、送信端末２１００はメディアデータの送信が可能となる。すなわち、送信部２２１が、メディアデータを送信し（ステップＳ２４１９）、受信端末２１００の受信部２２２が、送信されたメディアデータを受信する（ステップＳ２４２０）。受信端末２１００では、対応する暗号鍵を用いてメディアデータを復号して後続する処理を実行する。
【０２０９】
次に、図１６の処理で鍵を交換後に開始したセキュアなマルチキャストデータ通信を終了するシーケンスについて説明する。図２５は、第２の実施の形態におけるデータ通信終了処理の全体の流れを示すシーケンス図である。
【０２１０】
まず、送信端末２１００は、メディアデータ送信が終了すると、メディアデータ送信が終了したことを通知するためのＢＹＥ  ＲＥＱＵＥＳＴメッセージを、プレゼンスサーバ２３００に対して送信する（ステップＳ２５０１）。なお、ＢＹＥ  ＲＥＱＵＥＳＴメッセージは、セッション制御メッセージ処理部２２０４によって生成される。
【０２１１】
次に、プレゼンスサーバ２３００の受信部１２２は、ＢＹＥ  ＲＥＱＵＥＳＴメッセージを受信する（ステップＳ２５０２）。なお、排他制御のためプレゼンティティ情報テーブル１４１などに現在鍵情報を保持している送信端末２１００の情報を保存している場合は、当該情報を削除するように構成してもよい。
【０２１２】
次に、セッション制御メッセージ処理部２３０４は、ＳＩＰ  ＢＹ  ＲＥＳＰＯＮＳＥメッセージを生成し（ステップＳ２５０３）、送信部１２１が、生成したメッセージを送信端末２１００に送信する（ステップＳ２５０４）。また、送信端末２１００の受信部２２２は、ＳＩＰ  ＢＹ  ＲＥＳＰＯＮＳＥメッセージを受信する（ステップＳ２５０５）。
【０２１３】
プレゼンスサーバ２３００は、対応するマルチキャストグループの鍵を新規作成あるいは更新し、以後任意のタイミングにて、対応するマルチキャストグループのリストに含まれる受信端末２１００に対して鍵交換を行う。
【０２１４】
すなわち、プレゼンスサーバ２３００の通知メッセージ処理部１０３は、受信端末２１００に対してプレゼンス情報などを通知するためのＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを生成する（ステップＳ２５０６）。
【０２１５】
この際、通知メッセージ処理部１０３は、鍵情報を含むマルチキャストグループ情報を含むＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを生成する。なお、通知メッセージ処理部１０３は、マルチキャストグループ情報を暗号化してもよいし、マルチキャストデータ通信が終了したことを示す情報をメッセージに含めてもよい。
【０２１６】
次に、送信部１２１は、生成されたＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを受信端末２１００に送信する（ステップＳ２５０７）。
【０２１７】
なお、このＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージ送信処理は、ＢＹＥ  ＲＥＳＰＯＮＳＥメッセージの処理の直後に行う必要はない。例えば、その他のプレゼンティティの情報、マルチキャストグループ情報、またはグループ定義情報等が更新され、それに応じてＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを送信するときに同時に行うように構成してもよい。また、複数のＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを合わせて１つのＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージとして送信するように構成してもよい。
【０２１８】
受信端末２１００の受信部２２２は、ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージを受信する（ステップＳ２５０８）。次に、通知メッセージ処理部２０３は、受信したＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージに含まれる鍵情報およびマルチキャストアドレス情報を設定する（ステップＳ２５０９）。
【０２１９】
なお、受信したメッセージにマルチキャストデータ通信が終了したことを示す情報が含まれている場合は、メディア受信状態を解除するように構成してもよい。
【０２２０】
次に、通知メッセージ処理部２０３は、ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージに対する応答である、ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＳＰＯＮＳＥメッセージを生成する（ステップＳ２５１０）。
【０２２１】
続いて、送信部２２１は、生成したＳＩＰ  ＮＯＴＩＦＹ  ＲＥＳＰＯＮＳＥメッセージをプレゼンスサーバ２３００に送信する（ステップＳ２５１１）。プレゼンスサーバ２３００の受信部１２２は、ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＳＰＯＮＳＥメッセージを受信し（ステップＳ２５１２）、データ通信終了処理が完了する。
【０２２２】
なお、ステップＳ２５０７からステップＳ２５１２までの処理は、通信を終了するマルチキャストグループに含まれるすべての受信端末２１００との間で実行される。前述の通り、この処理は、すべての受信端末２１００で同時のタイミングで行われる必要はない。
【０２２３】
このように、第２の実施の形態にかかるサーバ装置では、マルチキャストグループに属さない端末からＩＰマルチキャスト通信の要求を受信した場合に、当該グループのＩＰマルチキャスト通信で用いる鍵情報を当該端末に対して返信することができる。これにより、端末がマルチキャストグループへ参加する処理などの特別な処理を必要とすることなく、セキュアなＩＰマルチキャスト通信を実現することができる。
【０２２４】
なお、本発明は、上述した第１実施形態および第２実施形態に限定されるものではなく、以下に例示するような種々の変形が可能である。
【０２２５】
（変形例）
上述した第１の実施の形態および第２の実施の形態では、プレゼンスサーバが鍵交換に必要な機能をすべて備えるように構成していたが、一部の機能を端末側で実行するように構成してもよい。
【０２２６】
例えば、記憶部１４０に格納されているプレゼンティティ情報テーブル１４１、プレゼンス情報テーブル１４２、対応テーブル１４３、定義情報テーブル１４４、アドレステーブル１４５、および鍵情報テーブル１４６の一部またはすべてを保持する端末と、当該端末で保持するテーブルを保持しないプレゼンスサーバとを備えたシステム構成をとりうる。
【０２２７】
この場合、端末が保持する情報に変化が起きた場合、端末がプレゼンスサーバに対して、例えばＳＩＰ  ＰＵＢＬＩＳＨメッセージなどにより情報を送受信することで変化を通知するように構成する。このように、所定のメッセージで必要な情報を送受信することにより、上述の実施の形態と同様の機能を実現することができる。
【０２２８】
図２５は、第１または第２の実施の形態にかかるサーバ装置のハードウェア構成を示す説明図である。
【０２２９】
第１または第２の実施の形態にかかるサーバ装置は、ＣＰＵ（Central Processing Unit）５１などの制御装置と、ＲＯＭ（Read Only Memory）５２やＲＡＭ５３などの記憶装置と、ネットワークに接続して通信を行う通信Ｉ／Ｆ５４と、ＨＤＤ（Hard Disk Drive）、ＣＤ（Compact Disc）ドライブ装置などの外部記憶装置と、ディスプレイ装置などの表示装置と、キーボードやマウスなどの入力装置と、各部を接続するバス６１を備えており、通常のコンピュータを利用したハードウェア構成となっている。
【０２３０】
第１または第２の実施の形態にかかるサーバ装置で実行される通信プログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Compact Disk Recordable）、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。
【０２３１】
また、第１または第２の実施の形態にかかるサーバ装置で実行される通信プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、第１または第２の実施の形態にかかるサーバ装置で実行される通信プログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。
【０２３２】
また、第１または第２の実施の形態の通信プログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。
【０２３３】
第１または第２の実施の形態にかかるサーバ装置で実行される通信プログラムは、上述した各部（受付部、認証部、取得部、生成部、登録部、発行メッセージ処理部、購読メッセージ処理部、通知メッセージ処理部、送信部、受信部）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ５１（プロセッサ）が上記記憶媒体から通信プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、上述した各部が主記憶装置上に生成されるようになっている。
【産業上の利用可能性】
【０２３４】
以上のように、本発明にかかるサーバ装置、端末装置、通信方法、通信プログラムおよび通信システムは、ＳＩＰベースのシステムでセキュアなＩＰマルチキャスト通信を行うサーバ装置、端末装置、通信方法、通信プログラムおよび通信システムに適している。
【図面の簡単な説明】
【０２３５】
【図１】第１の実施の形態にかかる通信システムの構成を示す概念図である。
【図２】第１の実施の形態にかかる端末装置の構成を示すブロック図である。
【図３】第１の実施の形態にかかるサーバ装置の構成を示すブロック図である。
【図４】プレゼンティティ情報テーブルのデータ構造の一例を示す説明図である。
【図５】プレゼンス情報テーブルのデータ構造の一例を示す説明図である。
【図６】対応テーブルのデータ構造の一例を示す説明図である。
【図７】定義情報テーブルのデータ構造の一例を示す説明図である。
【図８】アドレステーブルのデータ構造の一例を示す説明図である。
【図９】鍵情報テーブルのデータ構造の一例を示す説明図である。
【図１０】第１の実施の形態における鍵交換処理の全体の流れを示すシーケンス図である。
【図１１】ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＱＵＥＳＴメッセージの形式の一例を示す説明図である。
【図１２】ＳＩＰ  ＮＯＴＩＦＹ  ＲＥＳＰＯＮＳＥメッセージの形式の一例を示す説明図である。
【図１３】鍵交換処理の全体の流れを示すシーケンス図である。
【図１４】鍵交換処理の全体の流れを示すシーケンス図である。
【図１５】鍵交換処理の全体の流れを示すシーケンス図である。
【図１６】第１の実施の形態におけるデータ通信開始処理の全体の流れを示すシーケンス図である。
【図１７】第１の実施の形態におけるデータ通信終了処理の全体の流れを示すシーケンス図である。
【図１８】従来技術におけるプレゼンスサーバを含む通信システムの構成を示す概念図である。
【図１９】従来の通信システムによる鍵交換処理のシーケンスの概要を示した説明図である。
【図２０】本実施の形態における通信システムによる鍵交換処理のシーケンスの概要を示した説明図である。
【図２１】第２の実施の形態にかかる通信システムの構成を示す概念図である。
【図２２】第２の実施の形態にかかる端末の構成を示すブロック図である。
【図２３】第２の実施の形態にかかるサーバ装置の構成を示すブロック図である。
【図２４】第２の実施の形態における鍵交換処理の全体の流れを示すフローチャートである。
【図２５】第２の実施の形態におけるデータ通信終了処理の全体の流れを示すシーケンス図である。
【図２６】サーバ装置のハードウェア構成を示す説明図である。
【符号の説明】
【０２３６】
５１  ＣＰＵ
５２  ＲＯＭ
５３  ＲＡＭ
５４  通信Ｉ／Ｆ
６１  バス
１００  プレゼンスサーバ
１０１  発行メッセージ処理部
１０２  購読メッセージ処理部
１０３  通知メッセージ処理部
１１１  受付部
１１２  認証部
１１３  取得部
１１４  生成部
１１５  登録部
１２１  送信部
１２２  受信部
１４０  記憶部
１４１  プレゼンティティ情報テーブル
１４２  プレゼンス情報テーブル
１４３  対応テーブル
１４４  定義情報テーブル
１４５  アドレステーブル
１４６  鍵情報テーブル
２００  端末
２０１  発行メッセージ処理部
２０２  購読メッセージ処理部
２０３  通知メッセージ処理部
２１１  音声入出力部
２１２  データ入出力部
２２１  送信部
２２２  受信部
３００  Ｐｒｏｘｙ
１８０１  Ｐｒｏｘｙ
１８０２  端末
１８０３  プレゼンスサーバ
２１００  受信端末
２１００  送信端末
２３００  セッション制御メッセージ処理部
２３００  ２３００  プレゼンスサーバ
２３０４  セッション制御メッセージ処理部
【図１】
2008034960.tif 000003
【図２】
2008034960.tif 000004
【図３】
2008034960.tif 000005
【図４】
2008034960.tif 000006
【図５】
2008034960.tif 000007
【図６】
2008034960.tif 000008
【図７】
2008034960.tif 000009
【図８】
2008034960.tif 000010
【図９】
2008034960.tif 000011
【図１０】
2008034960.tif 000012
【図１１】
2008034960.tif 000013
【図１２】
2008034960.tif 000014
【図１３】
2008034960.tif 000015
【図１４】
2008034960.tif 000016
【図１５】
2008034960.tif 000017
【図１６】
2008034960.tif 000018
【図１７】
2008034960.tif 000019
【図１８】
2008034960.tif 000020
【図１９】
2008034960.tif 000021
【図２０】
2008034960.tif 000022
【図２１】
2008034960.tif 000023
【図２２】
2008034960.tif 000024
【図２３】
2008034960.tif 000025
【図２４】
2008034960.tif 000026
【図２５】
2008034960.tif 000027
【図２６】
2008034960.tif 000028