JP4830503B2 - 個人情報を保護した通信セッション確立仲介システムおよび方法 - Google Patents

Description

本発明は，複数のエンティティ間で制御用通信プロトコルを使用して，複数のセッション管理サーバを介して通信セッションを確立するシステムにおけるアクセス制御に関すものである。

２つのエンティティ(例えば、装置、または装置上でソフトウェアが実行させることにより具現化されるプロセス)間のデータ通信を行う場合に，当該データ通信を可能にしたり，切断したり，といったデータ通信の制御を行うためにデータ通信とは独立した制御用通信プロトコルを用いることがある。例えば，IP電話では，制御用通信プロトコルとしてSIP (Session Initiation Protocol)というプロトコルが広く利用されている（SIPの詳細は非特許文献１参照）。

制御用通信プロトコルには，エンティティ（以下，クライアントとも呼ぶ）同士の通信セッション確立処理を一つまたは複数のセッション管理サーバが仲介する仕組みを想定しているものがある。例えば，上記のSIPでは，インターネット接続サービス事業者（以下，ISPとも呼ぶ）が当該ISPの顧客の間でIP電話サービスを提供するためにセッション管理サーバ（SIPサーバとも呼ばれる）が運用されている。

以下，SIPにおいて，セッション管理サーバを利用して第一のクライアントが第二のクライアントとの間の通信セッション（以下、単にセッションともいう）を確立してデータ通信を可能にする場合の動作を簡単に説明する。

まず，第一のクライアントは通信セッション確立処理に先立って，当該クライアントのIPアドレスをセッション管理サーバに登録する。すなわち，当該クライアントは， セッション管理サーバにおいて当該クライアントまたはクライアントのユーザを一意に識別するための識別子（SIP-URIとも呼ばれる）と，当該クライアントのIPアドレスと，を含む登録要求メッセージ（REGISTERメッセージとも呼ばれる）をセッション管理サーバに送信する。セッション管理サーバでは，登録要求メッセージに記載された前記識別子とIPアドレスとを対応付けて記録しておく。

なお，セッション管理サーバに記録されている，あるクライアントの識別子とIPアドレスとの対応付けは，対応付けが記録されたときに設定された有効期間が経過すると削除されるようになっている。また，当該クライアントから登録削除要求メッセージ（前記対応付けの有効期間を０と設定するように指示するREGISTERメッセージ）を送信することによっても削除することができる。

また，本明細書では，あるクライアント（エンティティ）の識別子とIPアドレスとがセッション管理サーバに対応付けて記録されている状態を，当該クライアントはセッション管理サーバにログインしている，とも呼び，記録されていない状態を，当該クライアントはセッション管理サーバからログアウトしている，とも呼ぶ。

ログインすることにより、セッション管理サーバが接続元クライアントから受信したINVITEメッセージ（後述する）を接続先クライアントに送信できるようになる。逆に、接続先クライアントがINVITEメッセージ等をセッション管理サーバに受け付けてもらえるようになる。

同様に，第二のクライアントもセッション確立処理に先立って，セッション管理サーバにログインしておく。

次に，第一のクライアントが第二のクライアントとのセッションを確立する処理を行う。

すなわち，第一のクライアントは，セッション管理サーバに第二のクライアントとのセッション確立を要求する接続要求メッセージ（以下、INVITEメッセージともいう）を送信する。当該INVITEメッセージには，第一のクライアントの識別子と第二のクライアントの識別子とが記載されている。INVITEメッセージを受信したセッション管理サーバは，当該INVITEメッセージを第二のクライアントに送信する。INVITEメッセージを受信した第二のクライアントは，接続要求を受理する場合には、その旨を示す応答メッセージ（２００OKメッセージとも呼ばれる）を前記セッション管理サーバに送信する。前記セッション管理サーバは，第一のクライアントに前記応答メッセージを返信する。第一のクライアントが応答メッセージを受信することにより，第二のクライアントとの間で通信セッションが確立したことになる。

以上が，SIPにおいて，セッション管理サーバを利用して第一のクライアントが第二のクライアントとの間のデータセッションを確立しデータ通信を可能にする場合の動作である。

また，複数のセッション管理サーバ同士が連携して，２つのクライアント間の通信セッションを制御する場合もある。すなわち，第一のクライアントは第一のセッション管理サーバにログインし，第二のクライアントは第二のセッション管理サーバにログインしているような状態で第一のクライアントが第二のクライアントとの間でセッションを確立する場合には，まず，第一のクライアントは，前記INVITEメッセージを第一のセッション管理装置に送信する。

当該INVITEメッセージを受信した第一のセッション管理サーバは，当該INVITEメッセージを第二のセッション管理サーバに転送する。第二のセッション管理サーバは当該INVITEメッセージを第二のクライアントに転送する。同様に，第二のクライアントは，前記応答メッセージを第二のセッション管理サーバに送信する。応答メッセージを受信した第二のセッション管理サーバは，当該応答メッセージを第一のセッション管理サーバに転送する。第一のセッション管理サーバは，当該応答メッセージを第一のクライアントに転送する，という具合である。

例えば，上記のIP電話では，ISPが自ISPの顧客にIP電話サービスを提供する場合に，それぞれのISPがSIPサーバを運用し，SIPサーバ同士が連携して，顧客の端末で動作しているIP電話クライアントソフトウェア間でのIP電話のためのセッションを確立する。

上記のように，複数のセッション管理サーバを介してINVITEメッセージが転送される場合に，第二のセッション管理サーバが第一のクライアントからINVITEメッセージを受信した場合に、該第一のクライアントに提供されるサービスを規定したサービス提供条件を取得し，第二のセッション管理サーバが、当該条件に基づいてサービスを提供するというサービス制御方法が存在する。（例えば，特許文献１参照）
特開２００４−１７２７８２号公報 IETF,RFC3261"SIP: Session Initiation Protocol"，IETF，2002年6月,[2004年12月20日検索]，インターネット＜URL：http://www.ietf.org/rfc/rfc3261.txt＞

特許文献１に記載のサービス制御方法は，ユーザの属性情報（例えば，年齢や住所等）に応じたサービスを提供することができる。

すなわち，第二のセッション管理サーバは，第一のクライアントから第一のセッション管理サーバを介してINVITEメッセージを受信した場合に，上記第一のクライアントを使用しているユーザの属性情報を取得し，当該属性情報に応じたサービスを提供するのである。

しかしながら，上記のサービス制御方法では，第一のセッション管理サーバにログインしている上記ユーザは，第二のセッション管理サーバにはログインしていないにも関わらず，第二のセッション管理サーバに属性情報を提供しなければならない。仮に，当該ユーザが，第三のセッション管理サーバにログインしている別のサービスも利用したい場合には，第三のセッション管理サーバにも属性情報を提供する必要がある。

すなわち，上記のサービス制御方法では，上記ユーザの属性情報の一部または全部の複製が頒布されてしまうという課題がある。

なお，例えば，下限年齢が設定されているサービスを、その年齢に達していないユーザに提供していまう等のように第二のセッション管理サーバがサービス提供条件の判断を間違った場合に，当該ユーザがログインしていた第一のセッション管理サーバの管理者も責任を問われる可能性がある。しかしながら，上記のサービス制御方法では，第一のセッション管理サーバはINVITEメッセージや応答メッセージを単純に転送する処理しか行わず，どのような判断に基づいてサービスが提供されようとしているのかが分からない，という課題がある。

本発明は，セッション管理サーバにおいて当該セッション管理サーバにログインしているクライアントを使用しているユーザの属性情報や前記クライアントで動作しているサービスの属性情報を管理するとともに，セッション確立処理に関与する複数のセッション管理サーバの間で，通信セッションを確立するための条件（以下，Session Establishment Policy ，SEPとも称する）をやり取りし，属性情報を管理しているセッション管理サーバが属性情報と提供されたSEPとを比較して通信セッションを確立するか否かを判定するアクセス判定を行うことにより，属性情報のコピーが頒布されることを防止することを主な特徴とする。

そのため，本発明では，個々の上記セッション管理サーバに，前記SEPが登録されたり更新されたり削除されたりした場合、あるいは他のセッション管理サーバから要求された場合にSEPを提供するSEP提供手段を設ける。

あるいは，本発明では，上記セッション管理サーバに，当該セッション管理サーバがINVITEメッセージを受信した場合に，当該INVITEメッセージの送信元あるいは送信先のクライアントがログインしているセッション管理サーバを検索するセッション管理サーバ検索手段と，当該セッション管理サーバ検索手段によって検索したセッション管理サーバからSEPを取得するSEP取得手段とを設ける。

また，本発明は，どのセッション管理サーバがどのようなSEPに対するアクセス可否判定を行ったのかという証拠を上記INVITEメッセージあるいは上記応答メッセージとともに送信し，上記アクセス可否判定を行っていないセッション管理サーバが前記証拠を確認することにより，通信セッション確立に関与する他のセッション管理サーバがどのような判断に基づいてサービスを提供しようとしているのかを事前に確認できるようにすることを主な特徴とする。

そのため，本発明では，上記セッション管理サーバに，上記アクセス判定を行った場合に上記証拠を上記INVITEメッセージあるいは上記応答メッセージに付加する証拠付加手段と，受信した上記INVITEメッセージあるいは上記応答メッセージに上記証拠が付加されていた場合に当該証拠を検証する証拠検証手段とを設ける。

本発明により，複数のセッション管理サーバが関与して通信セッションを確立するようなシステムにおいて，属性情報の一部または全部のコピーが頒布されることを防止することができるという効果がある。

さらには，本発明により，通信セッション確立に関与するセッション管理サーバが、どのような判断に基づいてサービスが提供されようとしているのかを確認できるという効果がある。

以下，図面を用いて本発明の実施の形態について説明する。なお，これらの実施形態によって本発明が限定されるものではない。

また，以下，SIPへの適用例を説明するが，SIP以外にも，通信セッションを確立する場合にセッション管理サーバを介してINVITEメッセージや応答メッセージを送受するようなシステムにも，本発明は適用できる。

本発明が適用されたSIP通信システムの一例について説明する。

図１は，本発明が適用されたSIP通信システムのシステム構成を示した図である。

本実施例のSIP通信システムでは，ｎ台のユーザ端末装置（以下、ユーザ端末という）１０とｍ台のサービスサーバ装置（以下、サーバ装置という）２０と２台のセッション管理装置３０とがネットワーク０を介して互いに接続され，さらに，セッション管理装置３０はローカルネットワークを介して接続された属性情報管理装置４０を備えている。
（なお，以降では，複数存在する端末や装置，人，機能等から１つを特定する必要がある場合には，たとえば，ユーザ端末１０_１，ユーザ端末１０_２のように添え字を用いて表記する）
ユーザ端末１０は，ユーザ１がSIP通信システムを利用するために使用する装置であり，ユーザ端末１０をユーザ側のエンティティとして機能させるユーザアプリケーションプログラムが実行される。当該アプリケーションプログラムの実行により実現されるプロセス（エンティティ）を以下、アプリケーション１００という。

サーバ装置２０は，ユーザ１またはユーザ端末１０にサービスを提供するためのサーバ装置であり，サーバ装置上で当該サービスを提供する側のエンティティ（以下、サービス２という）を具現化するサービスプログラムが実行される。

セッション管理装置３０は，ユーザ端末１０とサーバ装置２０との間の通信セッションを制御するための管理装置であり，セッション管理サーバ３００を具現化するプログラムが動作している。

セッション管理サーバ３００は，アプリケーション１００とサービス２との間の通信セッションを制御するために，アプリケーション１００（あるいはサービス２）がログインしたりログアウトしたりするための処理を行うログイン管理機能３０１と，アプリケーション１００とサービス２との間の通信セッションの制御を行うセッション制御機能３０２と，セッション制御機能３０２が前記通信セッションの確立処理時に当該通信セッションを確立してよいかどうかの判定を属性情報管理装置４０に依頼する判定依頼機能３０３と，SEP６を管理するためのSEP管理機能３０４と，他のセッション管理装置３０からSEPを取得するためのSEP取得機能３０５と，他のセッション管理装置３０にSEP６を送信するためのSEP送信機能３０６と，上記属性情報管理装置４０に依頼した判定の結果から，どのようなSEPに対するアクセス判定を行ったのかという証拠を作成する証拠作成機能３０７と，他のセッション管理装置３０が作成した証拠の妥当性を検証する証拠検証機能３０８と，を具現化し、ログイン管理機能３０１がSIP識別子とIPアドレスとの対応付けを記録しておくレジストラDB３０９と，SEP管理機能３０４がSEP６を記録しておくSEPDB３１０と，を管理する。

なお，本実施例では，アプリケーション１００がログイン時にセッション管理サーバ３００に登録するSIP-URIとしてユーザ１に対して発行されたSIP-URIを使用するものとする。そこで，以降では，アプリケーション１００がログインすることを，ユーザ１がログインする，とも称する。

また，セッション管理サーバ３００_１にはサービス２はログインせず，セッション管理サーバ３００_２にはアプリケーション１００はログインしないものとする。

しかしながら，本発明はこれに限定されるものではない。例えば，セッション管理装置３０_１に，アプリケーション１００_１からアプリケーション１００_５まで，および，サービス２_１からサービス２_５までがログインするようにし，セッション管理装置３０_ｓに，アプリケーション１００_６からアプリケーション１００_ｎまで，および，サービス２_６からサービス２_ｍまでがログインするようにしても構わない。さらには，３台以上のセッション管理装置３０を配置し，それぞれに対して異なるアプリケーション１００やサービス２がログインするようにしても構わない。

図５は，レジストラDB３０９の構成を例示した図である。

図５のレジストラDB３０９は，アプリケーション１００のSIP-URIとして用いるユーザ１のSIP-URIや、サービス２のSIP-URIを記録するSIP-URIフィールド３０９１と，当該ユーザ１が使用するユーザ端末１０やサービス２が動作するサーバ装置２０に割り当てられたIPアドレスを記録するIPアドレスフィールド３０９２と，当該関連付けの有効期限を記録する有効期限フィールド３０９３と，から構成されている。

本実施例では，SIP-URIは，ユーザ１やサービス２の名前と，当該ユーザ１やサービス２がログインしているセッション管理サーバ３００の名前（以降，ドメイン名とも称する）と，を「＠」で連結し，さらに、先頭にSIP-URIであることを示す「sip:」を付加した文字列として表現する。例えば，本実施例では，ユーザ１_１は「user11」という名前であり，ユーザ１が使用するアプリケーション１００_１がログインするセッション管理装置３０_１は「sip1.hitachi.jp」という名前であるため，ユーザ１とアプリケーション１００_１のSIP-URIは「sip:user11@sip1.hitachi.jp」となる。また，同様に、ユーザ１とアプリケーション１００_２は「sip:user12@sip1.hitachi.jp」というSIP-URIであり，ユーザ１とアプリケーション１００_ｎは「sip:user1n@sip1.hitachi.jp」というSIP-URIである。同様に，サービス２_１は「service21」という名前であり，サービス２_１がログインするセッション管理装置３０_２は「sip2.hitachi.jp」という名前であるため，サービス２_１のSIP-URIは「sip:service21@sip2.hitachi.jp」となる。また，サービス２₂のSIP-URIは「sip:service22@sip2.hitachi.jp」であり，サービス２_mのSIP-URIは「sip:service2m@sip2.hitachi.jp」である。

図３は，SEPDB３１０の構成を例示した図である。

図３のSEPDB３１０は，SEP６が設定されているユーザ１やサービス２のSIP-URIを記録するSIP-URIフィールド３１０１と， SEP６を記録するSEPフィールド３１０２とから構成されている。

図３では，例えば，「sip:user11@sip1.hitachi.jp」というSIP-URIを持つユーザ１_１には「推奨年齢>=18」というSEP６（SEP６_１１）が設定されている。したがって，ユーザ１_１には，推奨年齢が１８歳以上という属性を持つサービス２には接続を許可してよい，と設定されている。同様に，「sip:service21@sip2.hitachi.jp」というSIP-URIを持つサービス２_１には「住所=（東京都｜神奈川県｜埼玉県｜千葉県） & 年齢>=20 & 年齢<30 ＆ 性別＝男」というSEP６（SEP６_２１）が設定されている。したがって，サービス２_１は，住所が東京都か神奈川県か埼玉県か千葉県のいずれかであり，年齢が２０歳以上３０歳未満の男性，という属性を持つユーザ１からの接続要求を受け入れてよい，と設定されている。（なお，SEP６の１つを特定する必要がある場合には，例えば，ユーザ１_１を対象とするSEP６はSEP６_１１，ユーザ１_２を対象とするSEP６はSEP６_１２のように表記し，サービス２_１を対象とするSEP６はSEP６_２１，サービス２_２を対象とするSEP６はSEP６_２２のように表記する）
本実施例においては、接続または接続要求の受け入れが許可される、ということは、サービスの享受と提供が許可されるということを意味するものとする。

属性情報管理装置４０は，ユーザ１やサービス２に関する属性情報を管理するための装置であり，属性情報の登録や削除，更新などの処理を行う属性情報管理サービス４０１と，セッション管理装置３０から依頼された判定を行う適合性判定サービス４０２を具現化するプログラムと，属性情報管理サービス４０１がユーザ１やサービス２の属性情報を記録しておく属性情報DB４１０と，を備えている。

図４は，属性情報DB４１０の構成を例示した図である。

本実施例では，属性情報DB４１０は，ユーザ１の属性情報を記録したユーザ属性情報テーブル４１１と，サービス２の属性情報を記録したサービス属性情報テーブル４１２と，から構成されている。

ユーザ属性情報テーブル４１１は，ユーザ１のSIP-URIを記録したSIP-URIフィールド４１１０と，当該ユーザ１の名前を記録した名前フィールド４１１１と，当該ユーザ１の住所を記録した住所フィールド４１１２と，当該ユーザ１の年齢を記録した年齢フィールド４１１３と，当該ユーザ１の性別を記録した性別フィールド４１１４と，当該ユーザ１の職業を記録した職業フィールド４１１５と，を一組の情報として管理している。

サービス属性情報テーブル４１２は，サービス２のSIP-URIを記録したSIP-URIフィールド４１２０と，当該サービス２の名前を記録した名前フィールド４１２１と，当該サービス２の利用を許可するユーザ１の推奨年齢を記録した推奨年齢フィールド４１２２と，当該サービス２に暴力的な表現が含まれるか否かという属性情報を記録した暴力性フィールド４１２３と，当該サービス２に性的な表現が含まれるか否かという属性情報を記録した性的情報フィールド４１２４と，を一組の情報として管理している。

なお，本実施例では，属性情報DB４１０₂のサービス属性情報テーブル４１２にはセッション管理装置３０_１にログインするユーザ端末１を使用しているユーザ１の属性情報は記録されず，属性情報DB４１０_１のユーザ属性情報テーブル４１１にはセッション管理装置３０_２にログインするサーバ装置２０のサービス２の属性情報は記録されないものとする。

以上が，本実施例のSIP通信システムのシステム構成である。

なお，図１に示すユーザ端末１０，サーバ装置２０，セッション管理装置３０，属性情報管理装置４０の各機能や各サービスは，例えば，図２に示すような，CPU９１と，メモリ９２と，ハードディスク等の外部記憶装置９３と，CD-ROM等の可搬性を有する記憶媒体９９から情報を読み取る読取装置９４と，ネットワークやＬＡＮを介して他装置と通信を行うための通信装置９５と，キーボードやマウス等の入力装置９６と，モニタやプリンタ等の出力装置９７と，これらの各装置間のデータ送受を行うインタフェース９８と，各種の周辺機器を接続するためのローカルネットワークと，を備えた電子計算機においてCPU９１が、メモリ９２上にロードされたオペレーティングシステム（OSという）を実行し、さらにその管理下で所定のプログラムを実行することにより実現できる。

すなわち，サービス２，アプリケーション１００，セッション管理サーバ３００，属性情報管理サービス４０１，適合性判定サービス４０２はCPU９１が所定のプログラムを実行することによるプロセスとして実現できる。

また，レジストラDB３０９，SEPDB３１０，属性情報DB４０３は，CPU９１がメモリ９２や外部記憶装置９３を利用することにより実現できる。

このような電子計算機上に，上記各装置を実現するための所定のプログラムは，上記電子計算機が利用可能な記憶媒体９９から読取装置９４を介して導入されてもよいし，あるいは，通信装置９５を介してネットワーク０またはネットワーク０を伝搬する搬送波やデジタル信号といった，上記電子計算機が利用可能な通信媒体を介して他のサーバから導入されてもよい。

プログラムの導入に際しては，一旦，外部記憶装置９３に格納された後，そこからメモリ９２上にロードされてCPU９１に実行されてもよいし，あるいは，外部記憶装置９３に格納されることなく，直接メモリ９２上にロードされて，CPU９１に実行されてもよい。

また，本実施例の構成は上記に限定されない。例えば，セッション管理装置３０と属性情報管理装置４０とはネットワーク０を介して接続するように構成してもよい。その場合には，属性情報管理装置４０は，ネットワーク０を介して当該属性情報管理装置４０にアクセスしてきた装置を識別し，特定のセッション管理装置３０からの接続のみを許可したり，あるいはユーザ属性情報テーブル４１１やサービス属性情報テーブル４１２の特定の領域へのアクセスを許可したりするようなアクセス制限機能を備えてもよい。こうすることにより，複数のセッション管理装置３０が一つの属性情報管理装置４０を利用することができるという効果がある。ただし，ネットワーク０が、第三者が通信を盗聴できるものである場合には，セッション管理装置３０と属性情報管理装置４０との間の通信は暗号化することが望ましい。

また，セッション管理装置３０と属性情報管理装置４０とを同一の装置としてもよい。

なお，本実施例では，ユーザ属性情報テーブル４１１に記載される情報を登録したり，更新したり，削除したりする場合には，ユーザ１が書面または対面で申請し，属性情報管理装置４０の管理者がユーザ属性情報テーブル４１１を変更するものとする。同様に，サービス属性情報４１２に記載される情報を登録したり，更新したり，削除したりする場合には，サービス２の提供者が書面または対面で申請し，サービス属性情報テーブル４１２を変更するものとする。ここで，属性情報管理装置４０の管理者がユーザ属性情報テーブル４１１やサービス属性情報テーブル４１２を変更する場合には，上記入力装置９６から上記管理者からの命令を受け取った属性情報管理サービス４０１が上記テーブルを変更し，上記出力装置９７に結果を表示する，という手順で対話的に変更するものとする。

しかしながら，本発明は上記手順には限定されない。例えば，上記入力装置９６から命令を受け取ったり，上記出力装置９７に結果を出力したりする代わりに，ローカルネットワークや通信装置９５を介して命令や結果を送受するようにしてもよい。こうすることにより，上記属性情報管理装置４０の管理者は遠隔地からネットワーク０を介して，属性情報を更新できるという効果がある。さらには，上記入力装置９６や出力装置９７を備える必要がなくなるという効果がある。

次に，本実施例のSIP通信システムの動作について説明する。

本実施例のSIP通信システムにおいて，ユーザ１またはアプリケーション１００がセッション管理サーバ３００にログインする（上述の通り、以下では、アプリケーション１００がログインするという）場合の動作と，サービス２がセッション管理サーバ３００にログインする場合の動作は，通常のSIPを用いたシステムの動作と同じであるため，説明を省略する。 ユーザ１がセッション管理サーバ３００にログインすると，SEPの登録や更新や削除をしたり，セッション管理サーバ３００にログイン済みのサービス２との間でデータ通信したりできるようになる。

ユーザ１がSEP６を登録したり，削除したりする場合に本実施例のSIP通信システムの動作について図面を用いて説明する。

図６は，ユーザ１_１がセッション管理サーバ３００_１で管理されているSEP６_１１を削除した上で，新しいSEP６_１１を登録する場合の動作シーケンスを示した図である。

まず，ユーザ１_１はアプリケーション１００_１を起動してログインし，所定の操作により，SEP処理の起動を指示する。（S６０１）
SEP処理の起動を指示されたアプリケーション１００_１は，セッション管理サーバ３００_１に現在登録されているSEP６_１１を問い合わせると（S６０２），セッション管理サーバ３００_１はSEP管理機能３０４_１が当該SEP６_１１の送付元のIPアドレスを検索キーとしてレジストラDB３０９_１を検索し，ユーザ１_１のSIP-URIを取得する（S６０３）。次に，SEP管理機能３０４_１は，当該SIP-URIを検索キーとしてSEPDB３１０_１を検索し（S６０４），アプリケーション１００_１にSEP６_１１を送信する（S６０５）。

セッション管理サーバ３００_１からSEP６_１１を受信したアプリケーション１００_１は，ユーザ端末のOSを介して、SEP処理画面をユーザに表示する（S６０６）。 図７は，SEP処理画面の一例である。

図７のSEP処理画面は，現在セッション管理装置３０に登録されているSEP６を表示したSEP表示フィールド７０１と，新しいSEP６を入力するSEP入力フィールド７０２と， SEP入力フィールドに入力されたSEP６をセッション管理装置３０に登録するSEP登録ボタン７０３と，セッション管理装置３０に登録されているSEP６を削除するSEP削除ボタン７０４と，SEP処理画面を閉じるクローズボタン７０５と，から構成されている。

ユーザ１_１がSEP６_１１を削除するためにSEP削除ボタン７０４をクリックする（S６０７）と，アプリケーション１００_１はSEP削除要求をセッション管理サーバ３００_１に送信する（S６０８）。

SEP削除要求を受信したセッション管理サーバ３００_１は，SEP管理機能３０４_１が当該SEP削除要求の送信元のIPアドレスを検索キーとしてレジストラDB３０９_１を検索し，ユーザ１_１のSIP-URIを取得する（S６０９）。次に，SEP管理機能３０４は，当該SIP-URIを検索キーとしてSEPDB３１０_１を検索し（S６１０），当該SIP-URIと対応付けられているSEPフィールド３１０２の値を削除する（S６１１）と，削除完了メッセージをアプリケーション１００_１に返信する（S６１２）。

削除完了メッセージを受信したアプリケーション１００_１は，SEP表示フィールド７０１を空にしたSEP処理画面をユーザ１_１に対して表示する（S６１３）。

次に，ユーザ１_１は，新しいSEP６_１１を登録するために，SEP入力フィールド７０２にデータを入力し（S６１４），SEP登録ボタン７０３をクリックする（S６１５）。

SEP登録ボタン７０３がクリックされたことを検知したアプリケーション１００_１は，SEP入力フィールドに入力されたデータをSEP６_１１としてセッション管理サーバ３００_１に送信する（S６１６）。

SEP６_１１を受信したセッション管理サーバ３００_１は，SEP管理機能３０４_１が当該SEP６_１１の送付元のIPアドレスを検索キーとしてレジストラDB３０９_１を検索し，ユーザ１すなわちアプリケーション１００_１のSIP-URIを取得する（S６１７）。次に，SEP管理機能３０４_１は，当該SIP-URIを検索キーとしてSEPDB３１０_１を検索し（S６１８），当該SIP-URIと対応付けられているSEPフィールド３１０２を前記SEP６_１１で上書きする（S６１９）と，登録完了メッセージをアプリケーション１００_１に返信する（S６２０）。

登録完了メッセージを受信したアプリケーション１００_１は，SEP表示フィールド７０１を上記SEP６_１１に更新したSEP処理画面をユーザ１_１に表示する（S６２１）。

次に，ユーザ１_１がクローズボタン７０５をクリックすると，アプリケーション１００_１はSEP処理を終了する（S６２２）。

以上が，ユーザ１がSEP６を登録したり，削除したりする場合における本実施例のSIP通信システムの動作である。

なお，本実施例では，ユーザ１のSEP６の登録や削除はユーザ１自身がネットワーク０を介して行うようにしているが，本発明はそれに限定されない。例えば，ユーザ１がSEP６の登録や削除の権限を委任している第三者（以下，権限委任者と呼ぶ）によって登録や削除が行われてもよい。こうすることにより，ユーザ１の保護者がユーザ１のSEP６を設定でき，保護者による情報のフィルタリング（Parental Control）を実現できるという効果がある。

あるいは，ユーザ１あるいは上記権限委任者が上記セッション管理装置３０の管理者に書面や電話で申請し，当該管理者がユーザ１のSEP６を登録したり，削除したりするようにしてもよい。こうすることにより，ユーザ１あるいは上記権限委任者はSEP６の正確な記述方法を知らない場合でも自然言語で上記管理者にSEP６の内容を伝えるだけでSEP６が設定できるという効果がある。

なお， サービス２の提供者がサービス２のSEP６を登録したり，削除したりする場合も，本実施例のシステムの動作は，ユーザ１がSEP６を登録したり，削除したりする場合の動作と同じであり，説明を省略する。

次に，アプリケーション１００がサービス２との間で通信セッションを確立しようとした場合に本実施例のSIP通信システムの動作について図面を用いて説明する。

まず，図１１を参照して、アプリケーション１００の動作について説明する。

まず，アプリケーション１００が起動すると，アプリケーション１００は，ステップ１００１で，セッション確立の指示やネットワーク０からのデータを待ち受ける。

ここで，例えば，アプリケーション１００からサービス２_１とのセッション確立を指示された場合には，ステップ１０１１で，サービス２_１へのINVITEメッセージ５０を作成すると，INVITEメッセージ５０を当該アプリケーション１００がログインしているセッション管理サーバ３００に送信し（ステップ１０１２），当該セッション管理サーバ３００からの応答メッセージ５１を待ち受ける（ステップ１０１３）。

上記セッション管理サーバ３００からの応答メッセージ５１を受信すると，当該応答メッセージ５１の内容を解析し，通信が許可されたかどうかを確認する（ステップ１０１４）。

通信が許可されなかった場合には，ステップ１００１に戻る。通信が許可された場合には，上記セッション管理サーバ３００に確認メッセージ５２を送信する（ステップ１０１５）と，サービス２_１と通信セッションを確立して（ステップ１０１６），ステップ１００１に戻る。

ステップ１００１で，ネットワーク０からINVITEメッセージ５０を受信した場合には，当該INVITEメッセージ５０の送信元と通信を行うために通信装置を設定するなどのINVITE処理を行った（ステップ１０２１）後，応答メッセージ５１を作成し（ステップ１０２２），上記セッション管理サーバ３００に応答メッセージ５１を送信する（ステップ１０２３）。

次に，ステップ１０２４でネットワーク０からのデータを待ち受ける。

上記セッション管理サーバ３００から確認メッセージ５２を受信した場合には，そのまま，ステップ１０２４に戻る。前記INVITEメッセージ５０の送信元から通信を受信した場合には，ステップ１０１６以降の処理を実施する。

以上が，アプリケーション１００の動作である。なお，サービス２もアプリケーション１００と同様の動作を行う。

また，INVITEメッセージ５０，応答メッセージ５１，確認メッセージ５２のフォーマットは，通常のSIP通信システムと同じで良いため，説明を省略する。

次に，図９および図１０を参照して、アプリケーション１００がサービス２との間で通信セッションを確立する場合のセッション管理サーバ３００の動作について説明する。

セッション管理サーバ３００は，セッション制御機能３０２が，他のセッション管理サーバ３００やアプリケーション１００やサービス２からのメッセージを待ち受ける（ステップ３００１）。

他のセッション管理サーバ３００やアプリケーション１００からINVITEメッセージ５０を受信した場合には，セッション制御機能３０２が，当該INVITEメッセージ５０の送信先SIP-URI（送信先フィールド（Toヘッダフィールドとも称する）に記載されているSIP-URIを指す）のドメイン名が当該セッション管理サーバ３００のドメイン名と一致するかを確認する（ステップ３０１０）。

上記INVITEメッセージ５０の送信先フィールドに記載されているSIP-URIのドメイン名が当該セッション管理サーバ３００のドメイン名と一致した場合には，セッション制御機能３０２がログイン管理機能３０１に，当該送信先SIP-URIを持つアプリケーション１００（あるいはサービス２）がログインしているか否かの確認を依頼する（ステップ３０３０）。

当該送信先SIP-URIを持つアプリケーション１００（あるいはサービス２）がログインしている場合には，セッション制御機能３０２はSEP管理機能３０４に，SEPDB３１０から当該送信先SIP-URIのSEP６の検索を依頼する（ステップ３０３１）。

次に，SEP当該送信先SIP-URIのSEP６が存在していなかった場合（ステップ３０３２でNo）には，ステップ３０４８以降の動作を実行する。

当該送信先SIP-URIのSEP６が存在していた場合（ステップ３０３２でYes）には，ステップ３０３３に進む。ステップ３０３３で，上記INVITEメッセージ５０の送信元フィールド（Fromヘッダフィールドとも称する）に記載されているSIP-URI（以下，送信元SIP-URIとも称する）のドメイン名が当該セッション管理サーバ３００のドメイン名と一致した場合には，セッション制御機能３０２は判定依頼機能３０３に，当該通信セッションを確立してよいかどうかの、適合性判定サービス４０２への問い合わせを依頼する。判定依頼機能３０３は，上記SEP６と，上記送信元SIP-URIとを含む評価要求メッセージ７０を適合性判定サービス４０２に送信し，適合性判定サービス４０２から評価結果７１を取得し（ステップ３０３４）、ステップ３０３５に進む。

図１６に，本実施例における，評価要求メッセージ７０と評価結果７１のフォーマットを示す。評価要求メッセージ７０は，４バイトのSIP-URI長フィールド７０１１と，可変長のSIP-URIフィールド７０１２と，４バイトのSEP長フィールド７０２１と，可変長のSEPフィールド７０２２と，がバイト列として連結されたフォーマットとなっている。SIP-URI長フィールド７０１１にはSIP-URIフィールド７０１２の長さが格納され，SIP-URIフィールド７０には評価を依頼するSIP-URIが格納される。また，SEP長フィールド７０２１にはSEPフィールド７０２２の長さが格納され，SEPフィールド７０２２には評価を依頼するSEP６が格納される。

評価結果７１は，１バイトの結果コード７１０１と，４バイトの評価要求メッセージ長フィールド７１１１と，可変長の評価要求メッセージフィールド７１１２と，がバイト列として連結されたフォーマットとなっている。評価要求メッセージ長フィールド７１１１には，評価要求メッセージフィールド７１１２の長さが格納され，評価要求メッセージフィールド７１１２には，当該評価結果７１に対応する評価要求メッセージ７０が格納される。また，結果コード７１０１には，上記評価要求メッセージ７０を評価した結果，上記評価要求メッセージ７０に含まれるSEP６を上記評価要求メッセージ７０に含まれるSIP-URIの属性情報が満足すると判定した場合には０が，満足しないと判定した場合には１が，判定の過程でエラーが発生した場合には-1が，それぞれ格納される（以下では，結果コードが０の場合，適合性判定サービス４０２はセッションを確立してよいと判定したと考え，結果コードが０以外の場合には，適合性判定サービス４０２はセッションを確立してはならないと判定したと考える）。

セッション制御機能３０２は，ステップ３０３５で，適合性判定サービス４０２から受信した結果が，セッションを確立してよい，というものであった場合には，ステップ３０４８以降の動作を実行する。

ステップ３０３５で，適合性判定サービス４０２から受信した結果が，セッションを確立してはならない，というものであった場合には，接続要求を拒否する旨の応答メッセージを作成（ステップ３０３６）し，ステップ３０５７以降の動作を実行する。

一方，ステップ３０３３で，上記送信元SIP-URIのドメイン名が当該セッション管理サーバ３００のドメイン名と一致しなかった場合，セッション制御機能３０２は，当該INVITEメッセージ５０に対して正しいアクセス判定が行われていないと判断し，ステップ３０３６以降の動作を実行する。

また，ステップ３０３０で，当該送信先SIP-URIを持つアプリケーション１００（あるいはサービス２）がログインしていなかった場合には，ステップ３０３６以降の処理を実行する。

一方，ステップ３０１０で，上記送信先SIP-URIのドメイン名が当該セッション管理サーバ３００のドメイン名と一致しなかった場合には，セッション制御機能３０２は，上記INVITEメッセージ５０の送信元SIP-URIのドメイン名が当該セッション管理サーバ３００のドメイン名と一致するかどうかを確認し（ステップ３０１１）、ドメイン名が一致しなかった場合には，ステップ３０４８以降の動作を実行する。ドメイン名が一致した場合には，ステップ３０１２で，当該送信元SIP-URIを持つアプリケーション１００（あるいはサービス２）がログインしているかどうかを確認する。

ログイン済みであった場合には，セッション制御機能３０２は，SEP取得機能３０５に上記送信先SIP-URIのSEP6を要求するSEP送信要求メッセージ６０の作成を依頼する。SEP取得機能３０５がSEP送信要求メッセージ６０を作成すると，セッション制御機能３０２は上記送信先SIP-URIのドメイン名を持つセッション管理サーバ３００に送信する（ステップ３０１３）。

次に，セッション制御機能３０２がSEP送信応答メッセージ６１を受信すると，SEP取得機能３０５に当該メッセージからSEP6の取得を依頼する。SEP取得機能３０５は，上記SEP送信応答メッセージ６１からSEP6を取得する（ステップ３０１４）。

なお，本実施例におけるSEP送信要求メッセージ６０と，SEP送信応答メッセージ６１とはSIPメッセージに準じたフォーマットとなっている。

図１５（ａ）（ｂ）は，本実施例のSEP送信要求メッセージ６０とSEP送信応答メッセージ６１の構成を例示した図であり，セッション管理サーバ３００_１がセッション管理サーバ３００_２に対して，サービス２_１のSEP６_２１の取得を要求したSEP送信要求メッセージ６０と，当該SEP送信要求メッセージ６０に対するSEP送信応答メッセージ６１と，を示している。

図１５（ａ）のSEP送信要求メッセージ６０には，一行目に当該メッセージがSEP送信要求メッセージ６０であることを示す「GETSEP」という文字列が記述されており，「From：」という文字列から始まる送信元フィールドには当該メッセージの送信元を示す情報，例えば，セッション管理サーバ３００_１のドメイン名が記載され，「To：」という文字列から始まる送信先フィールドにはSEP６を要求する相手の識別情報，例えば，サービス２_１のSIP-URIが記載されている。さらには，当該SEP送信要求メッセージ６０を一意に識別するための情報が「Call-ID」および「CSeq」で始まる２つの行に記載されている。

図１５（ｂ）のSEP送信応答メッセージ６１には，一行目に当該メッセージが何かに対する応答メッセージであることを示す「２００ OK」という文字列が記述され，かつ「Call-ID」および「CSeq」で始まる２つの行に上記SEP送信要求メッセージ６０と同じ情報が記載されていることから，当該メッセージが上記SEP送信要求メッセージ６０に対する応答であることを示している。「From：」という文字列から始まる送信元フィールドには当該メッセージが誰のSEP６を記載したものであるのかを示す情報，すなわちサービス２_１のSIP-URIが記載されており，「To：」という文字列から始まる送信先フィールドには送信相手としてセッション管理サーバ３００_１のドメイン名が記載されている。さらには，「<SEP>」と「</SEP>」という二つの文字列で挟まれた領域にSEP６_２１が記載されている。

次に，セッション制御機能３０２は判定依頼機能３０３に，当該通信セッションを確立してよいかどうかの適合性判定サービス４０２への問い合わせを依頼する。このとき，判定依頼機能３０３は，上記SEP６と，上記送信元SIP-URIとを含む評価要求メッセージ７０を適合性判定サービス４０２に送信し，適合性判定サービス４０２から判定結果７１を取得する。（ステップ３０１５）
ステップ３０１６で，適合性判定サービス４０２から受信した結果が，セッションを確立してはならない，というものであった場合には，ステップ３０３６以降の動作を実行する。ステップ３０１６で，適合性判定サービス４０２から受信した結果が，セッションを確立してよい，というものであった場合には，どのような判定を行ったのかを示す，証拠データ８０を判定依頼機能３０３が作成する（ステップ３０１７）。

なお，本実施例では，証拠データ８０は，判定依頼機能３０３が作成するようにしているが，本発明はそれに限定されない。セッション制御機能３０２が作成するようにしても良いし，適合性判定サービス４０２が作成して，判定依頼機能３０３に返すようにしてもよい。

次に，セッション制御機能３０２は，SEP管理機能３０４に上記送信元SIP-URIのSEP６の検索を依頼する。SEP管理機能３０４は，SEPDB３１０から当該SEP6を検索し，セッション制御機能３０２に応答する（ステップ３０１８）。セッション制御機能３０２は，ステップ３０１９で，上記INVITEメッセージ５０に，SEP管理機能３０４から取得した上記送信元SIP-URIのSEP６と，上記証拠データ８０とを付加して，証拠付INVITEメッセージ５４を作成する。

図１３は，証拠付INVITEメッセージ５４の構成を例示する図であり，アプリケーション１００_１からサービス２_１へのINVITEメッセージ５０のボディ部分に，アプリケーション１００_１のSEP６_１１と，サービス２_１のSEP６_２１をアプリケーション１００_１が満足するかどうかを判定した証拠データ８０と，が付加されている。アプリケーション１００_１のSEP６_１１は，「<SEP>」と「</SEP>」という二つの文字列で挟まれた領域に記述する。同様に，証拠データ８０は，「<PROOF>」と「</PROOF>」という二つの文字列に挟まれた領域に記述する。

なお，図１３の証拠データ８０において，「<STATEMENT>」と「</STATEMENT>」という二つの文字列で挟まれた領域に，アプリケーション１００_１がSEP６_２１を満足する，という旨の文字列が記載されており，「<VerifiedBy>」と「</VerifiedBy>」という二つの文字列で挟まれた領域に，上記の確認を行ったセッション管理サーバ３００，すなわち，セッション管理サーバ３００_１の名前が記載され，さらには，「<SIGNATURE>」と「</SIGNATURE>」という二つの文字列で挟まれた領域に，「<STATEMENT>」から「</VerifiedBy>」までの領域に対してセッション管理サーバ３００_１が電子署名を行った電子署名データが記載されている。

次に，セッション制御機能３０２は，ステップ３０２０で 当該証拠付INVITEメッセージ５４を上記送信先SIP-URIのドメイン名を持つセッション管理サーバ３００に送信すると，ステップ３０５０以降の処理を実行する。

一方，ステップ３００１で，他のセッション管理サーバ３００やアプリケーション１００から証拠付INVITEメッセージ５４を受信した場合には，セッション制御機能３０２は，ステップ３０４１に遷移し，当該メッセージの送信先SIP-URIのドメイン名が，当該セッション管理サーバ３００のドメイン名と一致するかどうかを確認する。

ドメイン名が一致しなかった場合には，ステップ３０４８以降の処理を実行し，ドメイン名が一致した場合には，ステップ３０４２で証拠付INVITEメッセージ５４の送信先SIP-URIを持つアプリケーション１００（あるいはサービス２）がログイン済みかどうかを確認する。

ここで，ログイン済みでなかった場合には，ステップ３０３６以降の処理を実行し，ログイン済みであった場合には，セッション制御機能３０２は判定依頼機能３０３に，当該通信セッションを確立してよいかどうかの、適合性判定サービス４０２への問い合わせを依頼する。このとき，判定依頼機能３０３は，証拠付INVITEメッセージ５４に付加されていたSEP６と，上記送信先SIP-URIとを含む評価要求メッセージ７０を適合性判定サービス４０２に送信し，適合性判定サービス４０２から判定結果７１を取得し（ステップ３０４３），ステップ３０４４に進む。

セッション制御機能３０２は，ステップ３０４４で，適合性判定サービス４０２から受信した結果が，セッションを確立してはならない，というものであった場合には，ステップ３０３６以降の動作を実行し，セッションを確立してよい，という結果であった場合には，ステップ３０４５で，証拠付INVITEメッセージ５４に付加されていた証拠データ８０を検証する。すなわち，証拠データ８０の作成者が信頼できるか，および証拠データ８０が改ざんされていないかを電子署名を検証して確認する。

電子署名の検証に失敗した場合には，ステップ３０３６以降の処理を実行し，電子署名の検証に成功した場合には，上記証拠付INVITEメッセージ５４から付加されているSEP６および証拠データ８０を取り除き，INVITEメッセージ５０を作成する（ステップ３０４７）。

次に，レジストラDB３０９から上記送信先SIP-URIに関連付けられているIPアドレスを検索（ステップ３０４８）し，当該IPアドレスを持つ装置にINVITEメッセージ５０を送信する（ステップ３０４９）と，応答メッセージを待ち受ける（ステップ３０５０）。

ステップ３０５１で応答メッセージを受信すると，ステップ３０５２で当該応答メッセージが証拠付応答メッセージ５４であるかどうかを確認する。

本実施例の証拠付応答メッセージ５４は，応答メッセージ５１のボディ部に，「<PROOF>」と「</PROOF>」という二つの文字列で挟まれた領域に証拠データ８０を付加したメッセージであり，証拠付応答メッセージ５４であるか否かは，当該応答メッセージのボディ部を確認することにより，判断できる。

図１４は，本実施例の証拠付応答メッセージ５４の構成を例示した図である。

ステップ３０５２で，応答メッセージ５１であった場合には，ステップ３０５７以降の動作を実行し，証拠付応答メッセージ５４であった場合には，当該メッセージに付加されている証拠データ８０を検証し，正当なアクセス判定が行われたかどうかを確認する。すなわち，証拠データ８０の作成者が信頼できるか，および証拠データ８０が改ざんされていないかを電子署名を検証して確認する（ステップ３０５３）。

次に，ステップ３０５４で上記確認に失敗した場合には，ステップ３０３６以降の動作を実行し，上記確認に成功した場合には，ステップ３０５５で応答メッセージ５１に付加すべき証拠データ８０が存在するか否かを確認する。

ステップ３０５５で，付加すべき証拠データ８０が存在していた場合には，上記応答メッセージに当該証拠データ８０を付加した証拠付応答メッセージ５４を作成する（ステップ３０５６）。

ステップ３０５７で，応答メッセージの送信先SIP-URIのドメイン名が，当該セッション管理サーバ３００のドメイン名と一致するかどうかを確認し，ドメイン名が一致した場合には，ステップ３０５８に遷移し，上記応答メッセージが証拠付応答メッセージ５４であった場合には，当該証拠付応答メッセージ５４から証拠データ８０を削除し，応答メッセージ５１を作成する。

次に，レジストラDB３０９から上記送信先SIP-URIに関連付けられているIPアドレスを検索（ステップ３０５９）し，当該IPアドレスを持つ装置に当該応答メッセージ５１を送信する（ステップ３０６０）と，ステップ３００１に戻る。

ステップ３０５７でドメイン名が一致しなかった場合には，ステップ３０６０で上記送信先SIP-URIのドメイン名を持つセッション管理サーバ３００に応答メッセージを送信し，ステップ３００１に戻る。

一方，ステップ３００１で，他のセッション管理サーバ３００やアプリケーション１００から確認メッセージ５２を受信した場合には，当該確認メッセージ５２を応答メッセージ５１とみなして，ステップ３０５７に進み，セッション制御機能３０２が以降の処理を実行する。

一方，ステップ３００１で，他のセッション管理サーバ３００やアプリケーション１００からSEP送信要求メッセージ６０を受信した場合には，ステップ３０２１に進み，SEP送信機能３０６が，SEP送信要求メッセージ６０に記載されている送信先SIP-URIのSEP６をSEPDB３１０から検索する。

次に，ステップ３０２２で，SEP送信機能３０６が，上記SEP６を含むSEP送信応答メッセージ６１を作成すると，上記SEP送信要求メッセージ６０の送信元に返信し，ステップ３００１に戻る。

なお，ステップ３０２１でSEPDB３１０に送信先SIP-URIのSEP６が存在しなかった場合には，本実施例ではSEP６は空の文字列であるとして扱う。このとき，ステップ３０２２では，SEP送信応答メッセージ６１の「<SEP>」と「</SEP>」の二つの文字列でSEP６を挟む代わりに，「<SEP />」と記載する。

以上が，アプリケーション１００がサービス２との間で通信セッションを確立する場合のセッション管理サーバ３００の動作である。

次に，図１２を参照して，セッション管理サーバ３００から判定を依頼された場合の適合性判定サービス４０２の動作について説明する。

適合性判定サービス４０２は，プロセスが起動すると，セッション管理サーバ３００や管理者からの操作を待ち受ける（ステップ４０１０）。ここで，管理者がシャットダウン操作を行うと，ステップ４０２１で，属性情報DB４１０を非活性化し，処理を終了し，ステップ４０１０で，セッション管理サーバ３００から評価要求メッセージ７０を受信した場合には，適合性判定サービス４０２は，評価要求メッセージ７０に含まれているSIP-URIと，SEP６とを取り出し，当該SIP-URIの属性情報を属性情報DB４１０から検索する。

上記SIP-URIの属性情報が存在しなかった場合（ステップ４０１２でNo）には，セッション管理サーバ３００に判定結果７１としてエラーが発生した旨を返却する（ステップ４０１５）と，ステップ４０１０に戻る。

上記SIP-URIの属性情報が存在していた場合（ステップ４０１２でYes）には，適合性判定サービス４０２は，当該属性情報が上記SEP６を満足するか否かを判定する（ステップ４０１３）。なお，SEP６が空の文字列であった場合には，常に満足する，と判定する。

次に，適合性判定サービス４０２は，ステップ４０１３の結果を判定結果７１としてセッション管理サーバ３００に返却する（ステップ４０１４）と，ステップ４０１０に戻る。

以上が，セッション管理サーバ３００から判定を依頼された場合の適合性判定サービス４０２の動作である。

アプリケーション１００とサービス２との間で通信セッションを確立する場合，アプリケーション１００，サービス２，セッション管理サーバ３００，セッション管理サーバ３００，適合性判定サービス４０２，適合性判定サービス４０２が、上述の動作を行い各種メッセージを送受することにより，通信セッションが確立される。

図８を用いて，通信セッションの確立が許可されるアプリケーションとサービス（アプリケーション１００_１とサービス２_１）との間で通信セッションを確立する場合の上記メッセージの送受を説明する。

まず，ユーザ１_１がアプリケーション１００_１にサービス２_１との接続を指示すると，アプリケーション１００_１は，ステップ１０１２でINVITEメッセージ５０をセッション管理サーバ３００_１に送信する（S８０１）。

INVITEメッセージ５０を受信したセッション管理サーバ３００_１は，ステップ３０１４でサービス２_１がログインしているセッション管理サーバ３００_２にSEP６_２１を要求するSEP送信要求メッセージ６０を送付する（S８０２）。

セッション管理サーバ３００_２は， SEP６_２１を含むSEP送信応答メッセージ６１をセッション管理サーバ３００_１に返信する（図９のステップ３０２２，S８０３）。

セッション管理サーバ３００_２からSEP６_２１を含むSEP送信応答メッセージ６１を受信したセッション管理サーバ３００_１は，ステップ３０１５で適合性判定サービス４００_１にアプリケーション１００_１のSIP-URIとSEP６_２１とを含んだ評価要求メッセージ７０を送付する（図９のステップ３０１５，S８０４）。

評価要求メッセージ７０を受信した適合性判定サービス４００_１は，アプリケーション１００_１の属性情報がSEP６_２１（すなわち，「住所が東京都か神奈川県か埼玉県か千葉県のいずれかであり，年齢が２０歳以上３０歳未満の男性」という属性を持つ）を満足するかどうかの評価を行い，ステップ４０１４で「アプリケーション１００_１の属性情報はSEP６_２１を満足する」という判定結果７１をセッション管理サーバ３００_１に返信する（ステップ３０１１〜ステップ３０１３，S８０５）。

セッション管理サーバ３００_１は，ステップ３０１７からステップ３０１９で判定結果７１から作成した証拠データ８０と，アプリケーション１００_１のSEP６_１１と，を含む証拠付INVITEメッセージ５３を作成し，ステップ３０２０でセッション管理サーバ３００_２に送信する（S８０６）。

証拠付きINVITEメッセージ５３を受け取ったセッション管理サーバ３００_２は，ステップ３０４３で，サービス２A_１のSIP-URIと，SEP６_１１と，を含んだ評価要求メッセージ７０を適合性判定サービス４００_２に送付する（S８０７）。

評価要求メッセージ７０を受信した適合性判定サービス４００_２は，ステップ４０１１からステップ４０１３でサービス２_１の属性情報がSEP６_１１を満足するかどうかの評価を行い，ステップ４０１４で判定結果７１をセッション管理サーバ３００_１に返信する（S８０８）。

判定結果７１が，「サービス２_１の属性情報はSEP６_１１を満足する」というものであれば，セッション管理サーバ３００_２は，ステップ３０４５からステップ３０４６で上記証拠付INVITEメッセージ５３に付加されていた証拠データ８０を検証する。

ステップ３０４７で上記証拠付INVITEメッセージ５３からINVITEメッセージ５０を作成し，ステップ３０４９でサービス２_１に送信する。（S８０９）
INVITEメッセージ５０を受信したサービス２_１がステップ１０２３で応答メッセージ５１をセッション管理サーバ３００_２に送信する（S８１０）と，セッション管理サーバ３００_２はステップ３０５１からステップ３０５６で証拠付き応答メッセージ５４を作成し，ステップ３０６１でセッション管理サーバ３００_１に送信する（S８１１）。

セッション管理サーバ３００_１は，ステップ３０５０からステップ３０５４で証拠付き応答メッセージ５４に付加されていた証拠データ８０を検証すると，ステップ３０５８で上記証拠付き応答メッセージ５４から当該証拠データ８０を削除し，ステップ３０６０で応答メッセージ５１をアプリケーション１００_１に送信する（S８１２）。

アプリケーション１００_１はステップ１０１３で応答メッセージ５１を受信すると，ステップ１０１５で確認メッセージ５２をセッション管理サーバ３００_１に送信する（S８１３）
確認メッセージ５２受信したセッション管理サーバ３００_１は，ステップ３０６１で確認メッセージ５２をセッション管理サーバ３００_２に送信する（S８１４）と，セッション管理サーバ３００_２もステップ３０６０で当該確認メッセージ５２をサービス２_１に送信する（S８１５）。

次に，アプリケーション１００_１とサービス２_１とが通信セッションを確立する。具体的には、アプリケーション１００_１とサービス２_１との間でTCPコネクションが確立され，アプリケーション１００_１とサービス２_１との間でアプリケーションデータの送受が開始される（S８１６）。

以上が，アプリケーション１００_１がサービス２_１との間で通信セッションを確立する場合に，本実施例のSIP通信システムで送受されるメッセージのシーケンスである。

なお，サービス２がアプリケーション１００との間で通信セッションを確立する場合にも，上記と同様の動作で通信セッションを確立することができる。

本実施例のシステムでは，セッション管理サーバ３００は，送信元SIP-URIのドメイン名が当該セッション管理サーバ３００のドメイン名と一致し，送信先SIP-URIのドメイン名が当該セッション管理サーバ３００のドメイン名と一致しないINVITEメッセージ５０を受信した場合には，上記送信先SIP-URIのドメイン名を持つセッション管理サーバ３００から上記送信先SIP-URIに対応するアプリケーション１００（あるいはサービス２）のSEP６を取得するようにしている。また，上記INVITEメッセージ５０の代わりに，当該INVITEメッセージ５０に上記送信元SIP-URIに対応するアプリケーション１００（あるいはサービス２）のSEP６と付加した，証拠付INVITEメッセージ５３を上記送信先SIP-URIのドメイン名を持つセッション管理サーバ３００に送信するようにしている。さらには，属性情報は属性情報管理装置４０で管理し，アクセス判定は当該属性情報管理装置４０で行うようにしている。このため，本実施例のシステムによれば，属性情報が頒布されることなく，アクセス判定が行えるという効果がある。

また，本実施例のシステムでは，セッション管理サーバ３００は，アクセス判定の証拠を示した証拠データ８０を，証拠付INVITEメッセージ５３や証拠付応答メッセージ５４として，INVITEメッセージ５０や応答メッセージ５１とともに送信する。このため，アクセス判定を行っていないセッション管理サーバ３００でもどのようなアクセス判定が行われたのかが検証できるという効果と，証拠データ８０を別々に送信するよりも送受するメッセージ数が少なくて済むという効果がある。

さらには，証拠付INVITEメッセージ５３や証拠付応答メッセージ５４では，SEP６や証拠データ８０を，INVITEメッセージ５０や応答メッセージ５１のボディ部に格納している。このため，本実施例を適用していないSIPサーバが当該メッセージを中継したとしてもエラーにならない，という効果がある。

しかしながら，本発明は上記に限定されない。例えば，セッション管理サーバ３００はSEP６や証拠データ８０とINVITEメッセージ５０や応答メッセージ５１とをバイト列として連結したような新しいメッセージを使用してもよいし，あるいは，SEP６や証拠データ８０にINVITEメッセージ５０や応答メッセージ５１を格納する領域を設け，当該領域にINVITEメッセージ５０や応答メッセージ５１を格納したSEP６や証拠データ８０を送信するようにしてもよい。

また，本実施例のシステムでは，セッション管理サーバ３００は，当該セッション管理サーバ３００が管理していないSEP６は，アクセス判定を行う際に取得するようにしている。このため，セッション管理サーバ３００は当該セッション管理サーバ３００にログインするアプリケーション１００やサービス２のSEP６のみを管理すればよく，SEPDB３１０が小さくて済むという効果がある。

また，本実施例のシステムでは，アプリケーション１００やサービス２の属性情報は属性情報管理装置４０で表示や更新が行えるようにし，ローカルネットワークを介してアクセスした場合には，ある条件を満足するか否か，という適合性判定の結果が得られるようにしている。このため，アプリケーション１００やサービス２の属性情報がネットワークを介して流出することがない，という効果がある。

また，本実施例のシステムでは， セッション管理サーバ３００でSEP６を管理し，かつSEP６をどのセッション管理サーバ３００から取得すればよいかの判定には，セッション管理サーバ３００がSIPメッセージの送信先を決定するのと同じ判定方法（アルゴリズム）を使用している。このため，SEP６の管理者を検索するための機能が不要であるという効果がある。

なお，本実施例では，ネットワーク０を介して送受されるメッセージは平文のままで送付するようにしているが，これに限定されない。メッセージを暗号化したり，電子署名を施したり，あるいは，暗号化通信プロトコルを利用してメッセージを送受信したりしてもよい。こうすることにより，メッセージの機密性や完全性がより確実になるという効果がある。

また，本実施例では，レジストラDB３０９やSEPDB３１０や属性情報DB４１０に情報を平文のままで格納しているようにしているが，これに限定されない。格納する際に情報を暗号化したり，電子署名を施したりといった処理を行った後に格納しても良い。こうすることにより，DBに格納されている情報の機密性や完全性がより確実になるという効果がある。

さらに，本実施例では，ネットワーク０を介して送受されるメッセージには，アプリケーション１００とサービス２との間の通信セッションに関する情報は含まれていないが，これに限定されない。例えば，上記メッセージには，上記通信セッションで使用するプロトコルの名称や，暗号化アルゴリズムやダイジェストアルゴリズムの名称や，暗号処理やハッシュ処理に使用する鍵，あるいは当該鍵を計算するための乱数などが含まれていても良い。こうすることにより，アクセスが許可されたアプリケーション１００とサービス２との間での通信セッションの通信パラメータのネゴシエーションが行えるという効果がある。

さらに，本実施例では，ユーザ１がサービス２と通信セッションを確立する場合に，ユーザ１の属性情報がサービス２のSEP6を満足するかと，サービス２の属性情報がユーザ１のSEP6を満足するかの2種類の判定を行っている（S805およびS808）が，本発明は上記に限定されない。

例えば，ユーザ１の属性情報がサービス２のSEP6を満足するかの判定結果によって通信セッションを確立するか否かを決定しても良い。こうすることにより，サービス２がログインしているセッション管理サーバ３００では証拠の検証だけを行えばよいため，高速に処理が行える，という効果がある。

さらに，本実施例では，セッション管理サーバ３００がSEP管理機能３０４やSEP送信機能３０６，SEPDB３１０を持っているが，本発明は上記に限定されない。

例えば，セッション管理サーバ３００と異なるSEP管理プロセスがSEP管理機能３０４やSEP送信機能３０６，SEPDB３１０を持ち，セッション管理サーバ３００はSEP取得機能305によってSEP管理プロセスからSEP６を取得しても良い。さらには，セッション管理サーバ３００と，SEP管理プロセスとを異なる装置で動作させるようにしても良い。こうすることにより，セッション管理サーバ３００は， SEP６を取得したいSIP-URIが自身のドメイン名と一致するかによってSEP6の取得手順を変更する必要がなく，取得要求を送信する相手を変更するだけでよい，という効果がある。

さらに，本実施例では，SEP送信要求メッセージ６０やSEP送信応答メッセージ６１は，SIPメッセージに準じたフォーマットのメッセージを使用しているが，本発明は上記に限定されない。

例えば，独自のフォーマットのメッセージを使用しても良い。あるいは，INFOメッセージやMESSAGEメッセージ等のSIPメッセージを使用し，当該SIPメッセージのボディ部にSEPの送信や登録・削除の要求・応答を示すコマンドを記載しても良い。こうすることにより，より高速にSEPを取得することができたり，あるいはSIPに準拠したセッション管理機能３０２が使用できたり，という効果がある。

次に，本発明を適用した第二の実施例について説明する。

実施例２のシステムでは，アプリケーション１００がアプリケーション１００のSEP６を保持しており，サービス２が当該サービス２のSEP６を保持している点が、実施例１と異なる。

まず，実施例２のシステムにおいて，アプリケーション１００がログインおよびログアウトする場合の動作について図面を用いて説明する。

図１７は，アプリケーション１００_１がログインおよびログアウトする場合の動作シーケンスを示した図である。

まず，アプリケーション１００_１は，ログイン処理を行うため，アプリケーション１００_１に対して，ログイン処理の起動を要求する。（S１６０１）
アプリケーション１００_１は，保持しているSEP６を、REGISTERメッセージに付加したSEP付REGISTERメッセージ５５を作成し，セッション管理サーバ３００_１に送信する。（S１６０２）
SEP付REGISTERメッセージ５５を受信したセッション管理サーバ３００_１では，ログイン管理機能３０１_１がレジストラDB３０９_１に、当該メッセージの送信元SIP-URIとIPアドレスの組を登録するとともに，当該メッセージに付加されているSEP６_１１をSEPDB３１０_１に登録する。（S１６０３）
次に，セッション管理サーバ３００_１は，SEP送信機能３０６_１が、SEP６_１１を含んだSEP登録要求メッセージ６２をセッション管理サーバ３００_２に送信する。（S１６０４）
SEP登録要求メッセージ６２を受信したセッション管理サーバ３００_２は，当該メッセージからSEP６_１１を取り出し，SEPDB３１０_２に登録する。（S１６０５）
セッション管理サーバ３００_１は，SEP登録要求メッセージ６２をセッション管理サーバ３００_２に送信すると，ログイン処理が完了したことを通知するため，応答メッセージ５１をアプリケーション１００_１に送信する。（S１６０６）
応答メッセージ５１を受信したアプリケーション１００_１は，ユーザ１_１にログイン処理が完了したことを、表示などの方法により通知する。（S１６０７）
次に，アプリケーション１００_１がログアウトのために，アプリケーション１００_１に対して，ログアウト処理の起動を要求する（S１６１１）と，アプリケーション１００_１は，有効期間を０に設定したREGISTERメッセージ５６を作成し，セッション管理サーバ３００_１に送信する。（S１６１２）
REGISTERメッセージ５６を受信したセッション管理サーバ３００_１は，有効期間が０であるため、ログイン管理機能３０１_１がレジストラDB３０９_１から当該メッセージの送信元SIP-URIとIPアドレスの組を削除するとともに，当該送信元SIP-URIに関連付けられた SEP６をSEPDB３１０_１から削除する。（S１６１３）
セッション管理サーバ３００_１は，SEP送信機能３０６_１が上記送信元SIP-URIを含んだSEP削除要求メッセージ６３をセッション管理サーバ３００_２に送信する。（S１６１４）
SEP削除要求メッセージ６３を受信したセッション管理サーバ３００_２は，当該メッセージから上記送信元SIP-URIを取り出し，当該SIP-URIに関連付けられているSEP６をSEPDB３１０_２から登録する。（S１６１５）
セッション管理サーバ３００_１は，SEP削除要求メッセージ６３をセッション管理サーバ３００_２に送信すると，ログアウト処理が完了したことを通知するため，応答メッセージ５１をアプリケーション１００_１に送信する。（S１６１６）
応答メッセージ５１を受信したアプリケーション１００_１は，ユーザ１_１にログアウト処理が完了したことを、表示などの方法により通知する。（S１６１７）
なお，実施例２におけるSEP登録要求メッセージ６２と，SEP削除要求メッセージ６３とはSIPメッセージに準じたフォーマットを使うことができる。

図１５の（ｃ）および（ｄ）は，SEP登録要求メッセージ６２と，SEP削除要求メッセージ６３の構成を例示した図であり，セッション管理サーバ３００_１がセッション管理サーバ３００_２に対して，アプリケーション１００_１のSEP６_１１の登録を要求したSEP登録要求メッセージ６２と，ッション管理サーバ３００_１がセッション管理サーバ３００_２に対して，アプリケーション１００_１のSEP６_１１の削除を要求したSEP削除要求メッセージ６３と，を示している。

図１５の（ｃ）のSEP登録要求メッセージ６２には，一行目に当該メッセージがSEP登録要求メッセージ６２であることを示す「ADDSEP」という文字列が記述されており，「To：」という文字列から始まる送信先フィールドには当該メッセージの送信先を示す情報，すなわちセッション管理サーバ３００_２のドメイン名が記載され，「From：」という文字列から始まる送信元フィールドには登録するSEP６の対象者の識別情報，すなわちアプリケーション１００_１のSIP-URIが記載されている。さらには，当該SEP登録要求メッセージ６２を一意に識別するための情報が「Call-ID」および「CSeq」で始まる２つの行に記載されている。更には，「<SEP>」と「</SEP>」という二つの文字列で挟まれた領域に，SEP６が記載されている。

また，図１５の（ｄ）のSEP削除要求メッセージ６３には，一行目に当該メッセージがSEP削除要求メッセージ６３であることを示す「DELSEP」という文字列が記述されており， 「To：」という文字列から始まる送信先フィールドには当該メッセージの送信先を示す情報，すなわちセッション管理サーバ３００_２のドメイン名が記載され，「From：」という文字列から始まる送信元フィールドには削除するSEP６の対象者の識別情報，すなわちアプリケーション１００_１のSIP-URIが記載されている。さらには，当該SEP削除要求メッセージ６３を一意に識別するための情報が「Call-ID」および「CSeq」で始まる２つの行に記載されている。

以上が，実施例２のシステムにおいて，アプリケーション１００がログインおよびログアウトする場合の動作である。

なお，サービス２がログインしたり，ログアウトしたりする場合も，アプリケーション１００がログインしたり，ログアウトしたりする場合と同様の動作である。

また，実施例２では，ユーザ１がSEP６を修正する場合には，アプリケーション１００が保持しているSEP６を修正した後，再度ログイン処理を起動するものとする。サービス２のSEP６を修正する場合も同様である。

次に，実施例２のシステムにおいて，アプリケーション１００がサービス２と通信セッションを確立する場合の動作について説明する。

ここで，アプリケーション１００，サービス２，適合性判定サービス４０２の動作は，実施例１の動作と同様であるので，説明を省略する。

また，セッション管理サーバ３００の動作は，実施例１のセッション管理サーバ３００と似ている。ただし，実施例２のセッション管理サーバ３００は，アクセス判定を依頼する場合に，SEP６をセッション管理サーバ３００から取得したり，証拠付INVITEメッセージ５３に付加されたSEP６を使用したりする代わりに，SEPDB３１０からSEP６を取得するようにしている。

図１８は，実施例２のセッション管理サーバ３００の動作で，実施例１と異なる部分を示した図である。

まず，実施例２のセッション管理サーバ３００は，SEP送信要求メッセージ６０を受信することはないため，ステップ３０２１およびステップ３０２２の動作は存在しない。

また，実施例２のセッション管理サーバ３００は，送信先SIP-URIのドメイン名が他のセッション管理サーバ３００のドメイン名と一致し，かつ送信元SIP-URIのドメイン名が自身のドメイン名と一致するようなINVITEメッセージ５０を受信した場合に，実施例１のセッション管理サーバ３００と同様にステップ３０１２まで遷移する。

ステップ３０１２で，送信元SIP-URIのアプリケーション１００（あるいはサービス２）がログイン済みでなかった場合には，実施例１のセッション管理サーバ３００と同様にステップ３０３６以降の処理を行う。

一方，ログイン済みであった場合には，ステップ３０１３を実行する代わりに，ステップ３１００に遷移し，SEPDB３１０から送信先SIP-URIに対応付けられたSEP６を検索する。

ここで，SEPDB３１０にSEP６が存在しなかった場合には，ステップ３０３６以降の処理を実行する。

一方，SEPDB３１０にSEP６が存在した場合には，ステップ３０１５以降の処理を実行する。

さらには，実施例２のセッション管理サーバ３００は，送信元SIP-URIのドメイン名が他のセッション管理サーバ３００のドメイン名と一致し，かつ送信先SIP-URIのドメイン名が自身のドメイン名と一致するような証拠付INVITEメッセージ５３を受信した場合に，実施例１のセッション管理サーバ３００と同様にステップ３０４２まで遷移する。

ステップ３０４２で，送信先SIP-URIのアプリケーション１００（あるいはサービス２）がログイン済みでなかった場合には，実施例１のセッション管理サーバ３００と同様にステップ３０３６以降の処理を行う。

一方，ログイン済みであった場合には，ステップ３０４３を実行する代わりに，ステップ３２００に遷移し，SEPDB３１０から送信元SIP-URIに対応付けられたSEP６を検索する。

ここで，SEPDB３１０にSEP６が存在しなかった場合には，ステップ３０３６以降の処理を実行する。

一方，SEPDB３１０にSEP６が存在した場合には，ステップ３０４３以降の処理を実行する。

実施例２のセッション管理サーバ３００の動作は，上記以外の部分では実施例１のセッション管理サーバ３００の動作と同じであるので，説明を省略する。

以上が，実施例２のシステムにおいて，アプリケーション１００がサービス２と通信セッションを確立する場合の動作である。

実施例２のシステムでは，アプリケーション１００やサービス２がログインした際に，セッション管理サーバ３００の間でSEP６を送受し，共有するようにしている。こうすることにより，INVITEメッセージ５０を処理する場合にSEP６を送受する必要がなくなり，通信セッションが高速に確立できる，という効果がある。

なお，実施例２では，アプリケーション１００やサービス２がログインした場合に，セッション管理サーバ３００の間でSEP６が送受されるようにしているが，本発明はこれに限定されない。セッション管理サーバ３００が保持しているSEP６を，繰り返し（たとえば、予め定めた時間間隔で）他のセッション管理サーバ３００に送信するようにしてもよい。こうすることにより，例えば，セッション管理サーバ３００_２が一時的にサービスを中断していても，サービスを再開した場合に，セッション管理サーバ３００_１からすべてのSEP６を受信できるようになるという効果がある。

また，セッション管理サーバ３００がSEP登録要求メッセージ６３を受信した場合に，応答メッセージを返却してもよい。こうすることにより，応答メッセージが戻ってこないセッション管理サーバ３００にはSEP登録要求メッセージ６３を再送できるようになるという効果がある。

さらに，実施例２では，SEP登録要求メッセージ６２，SEP削除要求メッセージ６３は，SIPメッセージに準じたフォーマットのメッセージを使用しているが，本発明は上記に限定されない。

例えば，独自のフォーマットのメッセージを使用しても良い。あるいは，INFOメッセージやMESSAGEメッセージ等のSIPメッセージを使用し，当該SIPメッセージのボディ部にSEPの送信や登録・削除の要求・応答を示すコマンドを記載しても良い。こうすることにより，より高速にSEPを取得することができたり，あるいはSIPに準拠したセッション管理機能３０２が使用できたり，という効果がある。

なお、上記実施例１と実施例２とを適宜組み合わせて実施してもよい。

本発明が適用されたSIP通信システムのシステム構成を示した図である。 ユーザ端末１０，サーバ装置２０，セッション管理装置３０，属性情報管理装置４０，の各々のハードウェア構成例を例示する図である。 SEPDB３１０の構成を例示した図である。 属性情報DB４１０の構成を例示した図である。 レジストラDB３０９の構成を例示した図である。 SEP６の削除と登録の動作シーケンスを示した図である。 SEP処理画面の一例である。 アプリケーション１００がサービス２との間で通信セッションを確立する場合の各装置間で送受されるメッセージのシーケンスを示した図である。 アプリケーション１００がサービス２との間で通信セッションを確立する場合のセッション管理サーバ３００の動作を示した図である。 アプリケーション１００がサービス２との間で通信セッションを確立する場合のセッション管理サーバ３００の動作を示した図である。 アプリケーション１００の動作を示した図である。 適合性判定サービス４０２の動作を示した図である。 証拠付INVITEメッセージ５４の構成を例示する図である。 証拠付応答メッセージ５４の構成を例示した図である。 SEP送信要求メッセージ６０，SEP送信応答メッセージ６１，SEP登録要求メッセージ６２，SEP削除要求メッセージ６３の構成を例示した図である。 評価要求メッセージ７０および判定結果７１のフォーマットを示した図である。 アプリケーション１００がログインおよびログアウトする場合の動作シーケンスを示した図である。 実施例２のセッション管理サーバ３００の動作で，実施例１と異なる部分を示した図である。

符号の説明

１：ユーザ、２：サービス、６：SEP、１０：ユーザ端末、２０：サーバ装置、３０：セッション管理装置、４０：属性情報管理装置、５０：INVITEメッセージ、５１：応答メッセージ、５２：確認メッセージ、５３：証拠付INVITEメッセージ、５４：証拠付応答メッセージ、５５：SEP付登録要求メッセージ、５６：登録要求メッセージ、６０：SEP送信要求メッセージ、６１：SEP送信応答メッセージ、６２：SEP登録要求メッセージ、６３：SEP削除要求メッセージ、７０：評価要求メッセージ、７１：判定結果、８０：証拠データ、９１：CPU、９２：メモリ、９３：外部記憶装置、９４：読取装置、９５：通信装置、９６：入力装置、９７：出力装置、９８：インタフェース、９９：記録媒体、１００：アプリケーション、３００：セッション管理サーバ、３０１：ログイン管理機能、３０２：セッション制御機能、３０３：判定依頼機能、３０４：SEP管理機能、３０５：SEP取得機能、３０６：SEP送信機能、３０７：証拠作成機能、３０８：証拠検証機能、３０９：レジストラDB、３１０：SEPDB、４０１：属性情報管理サービス、４０２：適合性判定サービス、４１０：属性情報DB、４１１：ユーザ属性情報テーブル、４１２：サービス属性情報テーブル。

Claims (7)

1. 第一のクライアントがログインする第一のセッション管理装置と第二のクライアントがログインする第二のセッション管理装置とが連携して，前記第一のクライアントと前記第二のクライアントとの通信セッションを確立する，通信セッション確立システムであって，
   前記第一のセッション管理装置は，
   前記第一のクライアントの属性情報を管理する属性情報管理機能と，
   前記第二のセッション管理装置にログインする前記第二のクライアントの利用者が，他のクライアントとの通信セッションの確立を許可する条件である前記第二のクライアントのSEP（Session Establishment Policy）を，前記第二のセッション管理装置に要求し，取得するSEP取得機能と，
   前記SEP取得機能が取得する前記第二のクライアントのSEPと，前記属性情報管理機能が管理する前記第一のクライアントの前記属性情報と，に基づき，前記第一のクライアントの属性情報が前記第二のクライアントのSEPを満足しているかという適合性判定を行う適合性判定機能と，
   前記適合性判定機能による前記適合性判定に係る証拠データを作成する証拠作成機能と，
   第一のセッション制御機能と，を備え，
   前記第二のセッション管理装置は，
   前記第二のクライアントのSEPを管理する第二のSEP管理機能と，
   前記第一のセッション管理装置から要求された，前記第二のSEP管理機能が管理する，前記第二のクライアントのSEPを，前記第一のセッション管理装置へ送信するSEP送信機能と，を備え，
   前記第一のセッション管理装置の前記第一のセッション制御機能は，
   前記第一のクライアントから，前記第二のクライアントとの通信セッションの確立を要求する接続要求メッセージを受信した場合に，前記第一のクライアントが前記通信セッションの確立を要求する相手である前記第二のクライアントのSEPの取得を前記SEP取得機能に依頼し，
   前記SEP取得機能が前記第二のセッション管理装置から取得した前記第二のクライアントのSEPと，当該第一のセッション管理装置の前記属性情報管理機能が管理する前記第一のクライアントの属性情報と，に基づく前記適合性判定を，前記適合性判定機能に依頼し，
   前記適合性判定の対象となる前記第一のクライアントと，前記適合性判定に用いられた前記第二のクライアントのSEPと，を示す前記証拠データの作成を，前記証拠作成機能に依頼し，
   前記適合性判定機能による適合性判定の結果，前記第一のクライアントの属性情報が前記第二のクライアントのSEPを満足している場合に，前記第二のクライアントとの通信セッションの確立を要求する前記接続要求メッセージに，前記第一のクライアントの属性情報を付加せず，作成された前記証拠データを付加して，前記第二のセッション管理装置へ送信する
   ことを特徴とする通信セッション確立システム。
2. 請求項１に記載の通信セッション確立システムであって，
   前記第二のセッション管理装置は，
   前記接続要求メッセージに付加された前記証拠データを検証して，前記適合性判定の妥当性を検証する第二の証拠検証機能と，
   前記第一のセッション管理装置から，前記証拠データが付加された前記接続要求メッセージを受信した場合に，前記第二の証拠検証機能に前記証拠データの検証を依頼し，
   前記第二の証拠検証機能が，前記第一のセッション管理装置における前記適合性判定が妥当なものであると判断した場合に，前記証拠データを取り除いた前記接続要求メッセージを前記第二のクライアントに送信する第二のセッション制御機能と，を備える
   ことを特徴とする通信セッション確立システム。
3. 請求項２に記載の通信セッション確立システムであって，
   前記第一のセッション管理装置において，
   当該第一のセッション管理装置にログインする前記第一のクライアントの利用者が，他のクライアントとの通信セッションの確立を許可する条件である前記第一のクライアントのSEPを管理する第一のSEP管理機能を備え，
   前記第一のセッション制御機能は，前記第一のクライアントのSEPを，前記第二のセッション管理装置へ送信する前記接続要求メッセージに付加して送信し，
   前記第二のセッション管理装置は，
   前記第二のクライアントの属性情報を管理する属性情報管理機能と，
   前記接続要求メッセージに付加された前記第一のクライアントのSEPと，前記属性情報管理機能が管理する前記第二のクライアントの属性情報と，に基づき，前記第二のクライアントの属性情報が前記第一のクライアントのSEPを満足しているかという適合性判定を行う適合性判定機能と，
   前記適合性判定機能による前記判定に係る証拠データを作成する証拠作成機能と，を備え，
   前記第二のセッション管理装置の前記第二のセッション制御機能は，
   前記第一のセッション管理装置から，前記第一のクライアントのSEPと前記証拠データとが付加された前記接続要求メッセージを受信した場合に，受信した前記接続要求メッセージに添付された第一のクライアントのSEPと，当該第二のセッション管理装置の前記属性情報管理機能が管理する前記第二のクライアントの属性情報と，に基づく前記適合性判定を，前記適合性判定機能に依頼し，
   前記適合性判定機能による適合性判定の結果，前記第二のクライアントの属性情報が前記第一のクライアントのSEPを満足している場合に，前記第二の証拠検証機能に前記証拠データの検証を依頼する
   ことを特徴とする通信セッション確立システム。
4. 請求項３記載の通信セッション確立システムであって，
   前記第二のセッション管理装置において，
   前記適合性判定機能による前記適合性判定に係る証拠データを作成する証拠作成機能を備え，
   前記第二のセッション制御機能は，
   前記第二のクライアントから，前記接続要求メッセージに対する応答メッセージを受信した場合に，
   前記適合性判定に係る前記証拠データの作成を，前記証拠作成機能に依頼し，
   前記応答メッセージに，作成した前記証拠データを付加した証拠付き応答メッセージを作成し，
   前記第一のセッション管理装置へ送信する
   ことを特徴とする通信セッション確立システム。
5. 請求項４記載の通信セッション確立システムであって，
   前記第一のセッション管理装置において，
   前記証拠付き応答メッセージに付加された前記証拠データを検証して，前記適合性判定の妥当性を検証する第一の証拠検証機能を備え，
   前記第一のセッション制御機能は，
   前記証拠付き応答メッセージを受信した場合に，前記第一の証拠検証機能に前記証拠データの検証を依頼し，
   前記第一の証拠検証機能が，前記適合性判定が妥当なものであると判断した場合に，前記証拠データを取り除いた前記応答メッセージを前記第一のクライアントに送信する
   ことを特徴とする通信セッション確立システム。
6. 第一のクライアントのログインを受け付け，前記第一のクライアントと第二のクライアントとの通信セッションの確立を仲介するセッション管理装置であって，
   前記第一のクライアントの属性情報を管理する属性情報管理機能と，
   他のセッション管理装置にログインする前記第二のクライアントの利用者が，他のクライアントとの通信セッションの確立を許可する条件である第二のクライアントのSEP（Session Establishment Policy）を，前記他のセッション管理装置から取得するSEP取得機能と，
   前記SEP取得機能が取得する前記第二のクライアントのSEPと，前記属性情報管理機能が管理する前記第一のクライアントの属性情報とに基づき，前記第一のクライアントの属性情報が前記他のクライアントのSEPを満足しているかという適合性判定を行う適合性判定機能と，
   前記適合性判定機能による前記適合性判定に係る証拠データを作成する証拠作成機能と，
   セッション制御機能と，を備え，
   前記セッション制御機能は，
   前記第一のクライアントから，前記第二のクライアントとの通信セッションの確立を要求する接続要求メッセージを受信した場合に，前記第一のクライアントが前記通信セッションの確立を要求する相手である前記第二のクライアントのSEPの取得を前記SEP取得機能に依頼し，
   前記SEP取得機能が前記第二のセッション管理装置から取得した前記第二のクライアントのSEPと，当該第一のセッション管理装置の前記属性情報管理機能が管理する前記第一のクライアントの属性情報と，に基づく前記適合性判定を，前記適合性判定機能に依頼し，
   前記適合性判定の対象となる前記第一のクライアントと，前記適合性判定に用いられた前記第二のクライアントのSEPと，を示す前記証拠データの作成を，前記証拠作成機能に依頼し，
   前記適合性判定機能による適合性判定の結果，前記第一のクライアントの属性情報が前記第二のクライアントのSEPを満足している場合に，前記第二のクライアントとの通信セッションの確立を要求する前記接続要求メッセージに，作成された前記証拠データを付加して，前記他のセッション管理装置へ送信する
   ことを特徴とするセッション管理装置。
7. 請求項６に記載のセッション管理装置であって，
   前記証拠データを検証して，前記適合性判定の妥当性を検証する証拠検証機能を備え，
   前記セッション制御機能は，
   他のセッション管理装置から，前記証拠データが付加された接続要求メッセージを受信した場合に，前記証拠検証機能に前記証拠データの検証を依頼し，
   前記証拠検証機能が，前記他のセッション管理装置における前記適合性判定が妥当なものであると判断した場合に，前記証拠データを取り除いた前記接続要求メッセージを前記第一のクライアントに送信する
   ことを特徴とするセッション管理装置。

Images