JP2009065576A - データ通信システム - Google Patents

Abstract

【課題】
セッション管理サーバが，セッションの確立に必要となる各機能（サービスの提供可否の判断や，セッション鍵の生成など）の処理に長い時間を要する場合にも，セッション確立までに要する時間を短縮する，セッション確立の高速化方法およびシステムを提供する。
【解決手段】
セッション管理サーバが，セッション確立に必要となる各機能（サービスの提供可否の判断や，セッション鍵の生成など）への処理要求と，セッションを確立しようとする通信装置または他のセッション管理サーバにより送信された通信メッセージの転送処理と，を並行して行う手段を設ける。
【選択図】図１

Description

本発明は，データ通信方法およびシステムに関し，特にセッション管理サーバ装置を利用して，通信装置間でのデータ通信を可能にしたデータ通信方法およびシステムに関する。

２つのエンティティ（例えば，装置，または装置上でソフトウェアが実行されることにより具現化されるプロセスを指す）間のデータ通信を行う場合に，当該データ通信を可能にしたり，切断したり，といったデータ通信の制御を行うため，データ通信とは独立した制御用通信プロトコルを用いることがある。例えば，ＩＰ電話では，制御用通信プロトコルとしてＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）というプロトコルが広く利用されている（ＳＩＰの詳細については非特許文献１を参照）。

以下，ＳＩＰにおいて，通信装置間で確立される通信セッションを管理するセッション管理サーバを利用して，第一の通信装置が第二の通信装置との間の通信セッション（以下，単にセッションともいう）を確立してデータ通信を可能にする場合の手順を簡単に説明する。

なお，本明細書においては，セッションとは，通信装置間で行われる一連のデータ通信シーケンスをさす。例えば，ＳＩＰにおける，ＩＮＶＩＴＥメッセージと，対応する２００ＯＫとＡＣＫメッセージのやり取りで始まり，ＢＹＥメッセージと対応する２００ＯＫメッセージのやり取りで終了するものである。

まず，第二の通信装置は通信セッション確立処理に先立って，当該通信装置のＩＰアドレスをセッション管理サーバに登録する。すなわち，当該通信装置は，セッション管理サーバにおいて当該通信装置または通信装置のユーザを識別するための識別子（ＳＩＰ−ＵＲＩとも呼ばれる）と，当該通信装置のＩＰアドレスと，を含む登録要求メッセージ（ＲＥＧＩＳＴＥＲメッセージとも呼ばれる）をセッション管理サーバに送信する。セッション管理サーバは，登録要求メッセージに記載された識別子とＩＰアドレスを対応付けて記録しておく。

なお，セッション管理サーバに記録されている，ある通信装置の識別子とＩＰアドレスとの対応付けは，対応付けが記録されたときに設定された有効期間が経過すると削除されるようになっている。また，当該通信装置が登録削除要求メッセージ（例えば，上記ＲＥＧＩＳＴＥＲメッセージにおいて，対応付けの有効期間を０と設定するように指示する）を送信することによっても削除することができる。

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

同様に，第一の通信装置もセッション確立処理に先立ち，セッション管理サーバへのログインを行う。

次に，第一の通信装置が第二の通信装置とのセッション確立処理を行う。

すなわち，第一の通信装置は，セッション管理サーバに第二の通信装置とのセッション確立を要求する接続要求メッセージ（以下，ＩＮＶＩＴＥメッセージとも呼ぶ）を送信する。当該ＩＮＶＩＴＥメッセージには，第一の通信装置の識別子と第二の通信装置の識別子とが記載されている。ＩＮＶＩＴＥメッセージを受信したセッション管理サーバは，当該ＩＮＶＩＴＥメッセージを第二の通信装置へ転送する。ＩＮＶＩＴＥメッセージを受信した第二の通信装置は，当該接続要求を受理する場合には，その旨を示す応答メッセージ（２００ ＯＫメッセージとも呼ぶ）をセッション管理サーバへ送信する。当該セッション管理サーバは，受信した２００ ＯＫメッセージを第一の通信装置へ転送する。第一の通信装置が当該応答メッセージを受信することにより，第二の通信装置との間で通信セッションが確立したこととなる。

以上が，ＳＩＰにおいて，セッション管理サーバを利用して第一の通信装置が第二の通信装置との間のセッションを確立し，データ通信を可能にするまでの手順となる。

ＳＩＰはその拡張性の高さから，ＩＰ電話に留まらず，インスタントメッセージサービスや，コンテンツ配信サービスなど，様々なマルチメディアサービスにおいて，ユーザとコンテンツプロバイダ間での制御用通信プロトコルとして利用されている。またＮＧＮすなわち次世代ネットワーク（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）が，そのネットワークの基盤として利用するＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）においても，ＳＩＰが利用されている。

ＩＭＳはＩＰネットワーク上でのコンテンツ配信やＩＰ電話などのマルチメディアサービスを実現するための通信アーキテクチャである。ＩＭＳを構成する要素の中で中心的な役割を果たすのは，呼セッション制御機能（ＣＳＣＦ： Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）と呼ばれるＳＩＰサーバ装置である。

ＣＳＣＦはＩＭＳに接続するユーザ側通信装置やサービス側通信装置と，またＩＭＳ内のノードに各種機能を提供するアプリケーションサーバ装置（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ，以下，ＡＳという）などと，ＳＩＰを用いてデータ通信を行う。ＣＳＣＦには，ユーザからのアクセスを処理するＰ−ＣＳＣＦ（Ｐｒｏｘｙ−ＣＳＣＦ）と，他ネットワークとのゲートウェイとなるＩ−ＣＳＣＦ（Ｉｎｔｅｒｒｏｇａｔｉｎｇ−ＣＳＣＦ）と，セッション制御を行うＳ−ＣＳＣＦ（Ｓｅｒｖｉｎｇ−ＣＳＣＦ）の３つの種類が存在する。

Ｉ−ＣＳＣＦおよびＳ−ＣＳＣＦは，ユーザ情報やフィルタクライテリアを格納するホーム加入者サーバ（Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ，以下，ＨＳＳという）装置と，Ｄｉａｍｅｔｅｒプロトコルを用いてデータ通信を行う。Ｄｉａｍｅｔｅｒは，ＡＡＡ（認証・認可・アカウンティング）に用いられるプロトコルである。フィルタクライテリアは，Ｓ−ＣＳＣＦが，受け取ったメッセージの内容と照らし合わせ，当該メッセージの処理にいずれかのＡＳを利用する必要があるか否かを判定するための条件を記述したデータである。（ＩＭＳの詳細については非特許文献２を参照）。

マルチメディアサービスを提供するコンテンツプロバイダは，提供サービスの種類によっては，サービスへのアクセス制御機能や，ユーザとサービス間の暗号化通信に用いられるセッション鍵の生成機能など，セッション確立中に必要となる機能を，サービスを提供する通信装置（サービス側通信装置）へ装備することが求められる。

しかしながら，セッション確立中に必要となる各機能を個々のサービス側通信装置に搭載する場合，各サービス側通信装置上のソフトウェア開発や実装，保守などの作業に多くのコストがかかる，といった問題が生じる。さらに，各サービス側通信装置はセッション確立中に必要となる各機能を実現するために多くの計算資源を必要とし，また管理すべきデータの量も増加する。

この問題を解決するため，セッション確立中に必要となる単一ないし複数の処理を，各サービス側通信装置に配置するのではなく，セッション管理サーバや，セッション管理サーバと連携するサーバへ配置することで，機能の一元化を図る方法が考えられている。

例えばＩＭＳにおいては，ＳＩＰサーバであるＡＳが，ＱｏＳ制御や鍵生成など付加的なサービスを行うことで，サービス側通信装置の負担を軽減することが可能となっている。

また，特許文献１においては，ＳＩＰサーバであるセッション管理サーバが，ユーザへのサービス提供の可否を判定するための機能と，当該サービス提供が可と判断された場合に，サービス側通信装置にセッション設定要求パケットを送信するための機能を備えている。

ここで，特許文献１においてユーザ側通信装置がＳＩＰサーバを介してサービス側通信装置との間でセッションを確立するまでのシーケンスについて説明する。ＳＩＰサーバは初めに，ユーザ側通信装置からサービス側通信装置へ向けたＩＮＶＩＴＥメッセージを受信する。非特許文献１で定められるＳＩＰの標準的な手順では，ＳＩＰサーバはただちに当該ＩＮＶＩＴＥメッセージをサービス側通信装置へ転送するが，特許文献１に記載された手順においては，当該ＩＮＶＩＴＥメッセージの転送前に，ユーザ側通信装置がサービス側通信装置のサービスを享受する権限を，ユーザが保有しているかどうかを，加入者管理サーバへ問い合わせる手順が追加されている。

権限判定の結果，ユーザが上記権限を保有していることがＳＩＰサーバへ伝えられた場合，ＳＩＰサーバはＩＮＶＩＴＥメッセージをサービス側通信装置へ転送する。以降は特許文献１と同様の手順を踏むことで，サービス側通信装置のサービスを享受する権限を有するユーザが利用する通信装置は，サービス側通信装置とのセッションを確立することができる。

以上に示したように，特許文献１においては，サービス提供の可否判定機能を個々のサービス側通信装置が備えることなく，加入者管理サーバへ一元的に装備させることで，サービス側通信装置において加入者管理処理を行うコストを削減する方法が開示されている。

特開２００５−２８４７５３号公報 ＩＥＴＦ，ＲＦＣ３２６１：ＳＩＰ：Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ，［２００７年４月２０日検索］，インターネット（ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３２６１．ｔｘｔ） ３ＧＰＰ，３ＧＰＰ ＴＳ ２３．２２８：ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ（ＩＭＳ）Ｓｔａｇｅ ２，［２００７年４月２０日検索］，インターネット（ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇ／ｆｔｐ／Ｓｐｅｃｓ／ｈｔｍｌ−ｉｎｆｏ／２３２２８．ｈｔｍ）

特許文献１に記載された方法においては，セッション管理サーバが，ＩＮＶＩＴＥメッセージをユーザ側通信装置から受信した際，当該ＩＮＶＩＴＥメッセージをサービス側通信装置へ転送する前に，加入者管理サーバによるサービス提供可否の判断処理が終了するまで待機する。このため，当該判断処理に要する時間がセッション確立に要する時間全体にそのまま反映され，当該処理に長い時間を要するような状況においては，セッション確立に対しても長い時間が必要とされる，という課題がある。

加えて，サービス側通信装置が，サーバ内部エラー等の原因でサービスの提供を行うことのできない状態にある場合にも，ユーザ側通信装置はサービス提供可否の判断処理が終わった後にそのエラーメッセージを受信するため，当該判断処理に長い時間を要するような状況においては，ユーザのアクセス権限に関係しないエラーメッセージに対しても，ユーザの待ち時間が消費される，という課題がある。

本発明は，セッション確立に必要な処理のうち，一つの処理結果が他の処理に影響するため，従来，他の処理結果を待って逐次処理していた複数の処理を，並行して行うことにより，処理時間を短縮可能なデータ通信システムを提供する。

本発明は，通信装置間で確立されるセッションを管理するセッション管理サーバが，通信装置間でやり取りされる当該セッション確立に必要な通信メッセージの転送処理と，他の機能提供装置へ依頼する，当該セッション確立に必要な処理，とを並行して行うデータ通信システムを提供する。

具体的には，本発明が提供するセッション管理サーバは，ユーザ側通信装置から受信した，セッション確立を要求するＩＮＶＩＴＥメッセージの転送処理を，当該ユーザが，確立するセッションを利用してサービスを享受するための権限を，有しているか否かの問い合わせまたは処理要求と並行して，例えば，これらの結果を受信する前に，行うことを主な特徴とする。問い合わせまたは処理を要求する相手は，機能提供サーバなどの，他の装置であってもよい。

具体的には，本発明は，セッション管理サーバが，ユーザの権限判定を行う権限判定サーバやセッション鍵を生成する鍵生成サーバなど，セッション確立に必要な処理を行う各々の機能提供サーバから，要求した結果を受信する前に，サービス側通信装置へＩＮＶＩＴＥメッセージを送信する。機能提供サーバへ問い合わせまたは処理要求のメッセージを送信するタイミングは，ＩＮＶＩＴＥメッセージ送信の前でも後でもかまわない。

セッション管理サーバが，サービス側通信装置から，転送したＩＮＶＩＴＥメッセージに対するサービス提供可能メッセージを受信した場合は，当該サービス提供可能メッセージに対する応答メッセージをサービス側通信装置へ送信し，当該応答メッセージの送信後に，まだ受信していない結果があれば，これらの機能提供サーバからの結果を待ち受ける。

また，セッション管理サーバが，機能提供サーバから，依頼した処理に対する結果として、サービス側通信装置によるサービス提供を許可するメッセージを受信した場合は，当該許可メッセージに対する応答メッセージを機能提供サーバへ送信し，当該応答メッセージの送信後に，まだ受信していない結果があれば，これらの，機能提供サーバへ依頼した処理，および／または，サービス側通信装置へ送信した要求メッセージに対する結果，を待ち受ける。

上で述べた特徴に従い，本発明では，ユーザ側通信装置がサービスを享受するための権限を保有するかどうかが確定しない段階で，セッション管理サーバがサービス側通信装置へＩＮＶＩＴＥメッセージを送信する。当該ＩＮＶＩＴＥメッセージを受信したサービス側通信装置は，非特許文献１で定められる標準的なＳＩＰの手順に従い，応答となる２００ ＯＫメッセージをセッション管理サーバへ送信し，ユーザ側通信装置との間でセッション確立が完了した状態に遷移する。

この処理はユーザ側通信装置がサービスを享受するための権限を保有するかどうかに依らず実行されるため，サービス側通信装置は権限を保有しないユーザ側通信装置へサービスを提供する状態へ遷移してしまう可能性がある。

これに対し本発明では，権限を保有しないユーザの通信装置へサービス側通信装置がサービスを提供する可能性を排除するため，ユーザがサービスを享受するための権限を保有しないことが確定した場合，セッション管理サーバがサービス側通信装置へ当該セッションを切断するための処理，例えば，取消メッセージの送信，を行う。

具体的には，セッション管理サーバは，ユーザがサービスを享受するための権限を保有しないことが確認できたら，当該セッション確立を取り消すためのＳＩＰメッセージを，サービス側通信装置に対して送信する。送信されるＳＩＰメッセージは，サービス側通信装置の状態に応じて，ＢＹＥメッセージもしくはＣＡＮＣＥＬメッセージを使用する。

また，セッション管理サーバが，サービス側通信装置から要求を受け入れる応答メッセージを受信した後に，機能提供サーバからサービス提供を受けるために必要な処理結果を受信した場合は，サービス側通信装置に対して，必要な情報を追加するためのメッセージを送信する。

また，サービス側通信装置から，転送した要求メッセージに対する，サービス提供拒否メッセージを受信した場合には，機能提供サーバへ依頼した処理の取消メッセージを，当該機能提供サーバへ送信してもよい。

セッション管理サーバは，サービス側通信装置および処理を依頼した全ての機能提供サーバから応答を受信し，サービス側通信装置へ必要な情報を送信し，サービス側通信装置がサービス提供可能な状態に遷移したことを確認した後に，要求メッセージに対する応答メッセージをユーザ側通信装置へ送信する。

上記態様によれば，セッション管理サーバが，通信装置間でやり取りされる接続要求メッセージ，および接続応答メッセージの転送処理と，他の機能へ依頼する，セッション確立に必要な処理，とを並行して行うため，セッションの確立に要する時間を短縮することが可能である。

さらに，上記態様によれば，セッション管理サーバが，通信装置から送信されるエラーメッセージの転送処理と，他の機能へ依頼する，セッション確立に必要な処理，とを並行して行うため，エラーメッセージがユーザに届くまでの時間を短縮することが可能である。

さらに，上記態様によれば，ユーザ側通信装置は，サービス側通信装置がサービス提供不能状態にある場合に，ユーザがセッション確立要求メッセージの送信後，エラーメッセージを受信するまでの待ち時間が短縮される。

本発明によれば，機能提供サーバと連携するセッション管理サーバを用いたサービス提供可否判定処理を高速に行うことができる。

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

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

さらに，以下の各実施例における各装置は，例えば，図２にその構成例を示すような，プロセッサ（ＣＰＵ）９１と，プロセッサ９１上で実行される各種ソフトウェア（プログラム）とデータを記憶するためのメモリ９２および／またはハードディスク９３と，ネットワーク０に接続するためのネットワークインタフェース９４と，マウス，キーボードなどの入力装置，表示装置，そして外部記憶媒体の読み書き装置を含む入出力装置９５とを含んで構成され，各構成要素がバスなどの内部通信線９６によって相互接続されている一般的な電子計算機上に実現されるものである。

すなわち，以下の各実施例における各装置が備える処理部とその処理は，それぞれの装置においてハードディスク９３またはメモリ９２に格納された，上記各処理部を実現するプログラムを必要なタイミングでプロセッサ９１が実行することにより，具現化される。以下の実施形態の説明では，便宜上，各処理部を処理の実行主体として説明する。なお，プログラムをコード，または，モジュールということがある。

プロセッサ９１により実行されるプログラムは予め，各装置のハードディスク９３またはメモリ９２に格納されていても良いし，必要なときに，当該装置が利用可能な媒体を介して，他の装置から上記記憶部に導入されてもよい。媒体とは，たとえば，入出力装置９５にて利用可能な着脱可能な記憶媒体，またはネットワークインタフェース９４を介して利用可能な通信媒体（すなわちネットワークまたはネットワークを伝搬する搬送波やディジタル信号）を指す。また，上述の各々の処理部を集積回路などのハードウェアとして構成することも可能である。

また，以下の実施例において使用しているドメイン名，ＵＲＬ，ＵＲＩ，ＩＰアドレス等の識別子は，説明のために用いる架空のものであり，実在するものがあったとしても関係はない。

まず，図１から図１４を参照して，本発明によるデータ通信の第一の実施例について説明する。

図１は，本発明の第一の実施例におけるシステム構成を示した図である。ここに示したシステムは，セッション管理サーバであるＳＩＰサーバ１０と，権限判定サーバ２０と，課金サーバ３０と，鍵生成サーバ４０と，ユーザが使用してサービスとのデータ通信を実施するユーザ側通信装置４１と，サービスを提供するサービス側通信装置４２と，を含んで構成され，各サーバならびに通信装置はネットワーク０を介して接続されている。

ＳＩＰサーバ１０は，１９２．１６８．１０．１１というＩＰアドレスが割り当てられており，ＳＩＰサーバ１０にログインしている通信端末を管理するためのレジストラＤＢ６０と，ＳＩＰサーバ１０が管理している通信セッションの情報を管理するためのセッションログＤＢ７０とを備えている。

ＳＩＰサーバ１０は，例えば，ネットワーク０を介して他のサーバならびに通信装置と通信するためのネットワークインタフェースカード部（ＮＩＣ）１０１と，ＳＩＰメッセージを処理するＳＩＰメッセージ処理部１０２と，レジストラＤＢ７０への処理を制御するレジストラ処理部１０３と，セッションログＤＢ４１への処理を制御するセッション制御部１０４と，権限判定サーバや課金サーバとの通信を処理するアプリケーション処理部１０５と，を含む。図７に，セッションログＤＢ７０に保存されたセッションログ情報の一例を示す。

権限判定サーバ２０は，１９２．１６８．２０．１１というＩＰアドレスが割り当てられており，各ユーザがサービス側通信装置のサービスを享受可能か否かについての権限情報を管理する権限ＤＢ８０を備えている。

ここで，サービス側通信装置からユーザ側通信装置へ提供されるサービスは，当該通信装置間で確立されるセッション上で提供されるため，サービス側通信装置からサービスを享受するための権限を持つユーザは，サービス側通信装置とセッションを確立するための権限も保有していると言える。従って，権限ＤＢ８０の管理対象は，サービスを享受するための権限だけでなく，セッションを確立するための権限も含んでいる。

権限判定サーバ２０は，例えば，ネットワーク０を介して他のサーバならびに通信装置と通信するためのネットワークインタフェースカード部（ＮＩＣ）２０１と，権限判定要求メッセージを処理するメッセージ処理部２０２と，権限ＤＢ８０への処理を制御する権限判定処理部２０３と，を含む。図７に，権限ＤＢ８０に保存された権限情報の一例を示す。

課金サーバ３０は，１９２．１６８．３０．１１というＩＰアドレスが割り当てられている。課金サーバ３０は，例えば，ネットワーク０を介して他のサーバならびに通信装置と通信するためのネットワークインタフェースカード部（ＮＩＣ）３０１と，課金処理要求メッセージを処理するメッセージ処理部３０２と，処理要求に基づき，サービス側通信装置が提供するサービスに応じて発生する課金処理を行う課金処理部３０３と，を含む。

鍵生成サーバ４０は，１９２．１６８．４０．１１というＩＰアドレスが割り当てられている。鍵生成サーバ４０は，例えば，ネットワーク０を介して他のサーバならびに通信装置と通信するためのネットワークインタフェースカード部（ＮＩＣ）４０１と，鍵生成処理要求メッセージを処理するメッセージ処理部４０２と，処理要求に基づき，ユーザ側通信装置とサービス側通信装置との間の暗号化通信に用いられるセッション鍵の生成処理を行う鍵生成処理部４０３と，を含む。

なお，以下では，権限判定サーバ２０と，課金サーバ３０と，鍵生成サーバ４０を，機能提供サーバと総称することがある。

ユーザ側通信装置４１は，１９２．１６８．４１．１１というＩＰアドレスと，ｓｉｐ：ｃｌ１＠ｈｉｔａｃｈｉ．ｃｏｍというＳＩＰ−ＵＲＩとが割り当てられている。ユーザ側通信装置４１は，例えば，ネットワーク０を介して他のサーバならびに通信装置と通信するためのネットワークインタフェースカード部（ＮＩＣ）４１１と，ＳＩＰメッセージを処理するＳＩＰメッセージ処理部４１２と，サービス側通信装置４２が提供するサービスを享受するクライアント処理部４１３と，を含む。

サービス側通信装置４２は，１９２．１６８．４２．１１というＩＰアドレスと，ｓｉｐ：ｓｖ１＠ｈｉｔａｃｈｉ．ｃｏｍというＳＩＰ−ＵＲＩとが割り当てられており，サービス側通信装置４２が提供するサービスの情報を記録するためのアプリケーションログＤＢ５０を備える。ユーザ側通信装置４２は，例えば，ネットワーク０を介して他のサーバならびに通信装置と通信するためのネットワークインタフェースカード部（ＮＩＣ）４２１と，ＳＩＰメッセージを処理するＳＩＰメッセージ処理部４２２と，ユーザ側通信装置４１にサービスを提供し，またその提供状況をアプリケーションログＤＢ５０に記録するサーバ処理部４２３と，を含む。図７に，アプリケーションログＤＢ５０に保存されたアプリケーションログ情報の一例を示す。

以下，第一の実施例として，図１に示したユーザ側通信装置４１が，サービス側通信装置４２とデータ通信を行う場合の通信手順を説明する。

まず，ユーザ側通信装置４１およびサービス側通信装置４２は，図３のシーケンス図に示すように，ＳＩＰサーバへのログイン処理を行う。

まず，サービス側通信装置４２がＳＩＰサーバ１０へログイン処理を行う。すなわち，サービス側通信装置４２は，サーバ処理部４２３が，ＳＩＰサーバ１０との間でＴＬＳ通信のネゴシエーションを行い（Ｍ２０１），サービス側通信装置４２とＳＩＰサーバ１０の間でＴＬＳ通信を確立する。

次に，サービス側通信装置４２は，ＳＩＰメッセージ処理部４２２が，ＳＩＰメッセージであるＲＥＧＩＳＴＥＲメッセージＭ２０２を生成し，ＳＩＰサーバ１０へ送信することで，ロケーション登録を要求する。

ＲＥＧＩＳＴＥＲメッセージを受信したＳＩＰサーバ１０は，レジストラ処理部１０３がレジストラＤＢ６０に，受信したＲＥＧＩＳＴＥＲメッセージのＦｒｏｍヘッダが示す要求元(通信元)ＳＩＰ−ＵＲＩ（ｓｖ１＠ｈｉｔａｃｈｉ．ｃｏｍ）とＣｏｎｔａｃｔヘッダが示す要求元ＩＰアドレス（１９２．１６８．４２．１１）との関係を示すロケーションデータを登録すると，ＳＩＰメッセージ処理部１０２がロケーション登録の成功を伝えるために，ＳＩＰメッセージである２００ ＯＫメッセージＭ２０３をサービス側通信装置４２に送信する。

以上により，サービス側通信装置４２のＳＩＰサーバ１０へのログインが完了し，サービス側通信装置４２はユーザ側通信装置４１からのサービス提供要求を受け付けることが可能となる。

続いて，ユーザ側通信装置４１がＳＩＰサーバ１０へログイン処理を行う。すなわち，ユーザ側通信装置４１は，クライアント処理部４１３が，ＳＩＰサーバ１０とＴＬＳ通信のネゴシエーションを行い（Ｍ２０４），ユーザ側通信装置４１とＳＩＰサーバ１０の間でＴＬＳ通信が確立される。

次に，ユーザ側通信装置４１は，ＳＩＰメッセージ処理部４１２が，ＳＩＰメッセージであるＲＥＧＩＳＴＥＲメッセージＭ２０５を生成し，ＳＩＰサーバ１０へ送信することで，ロケーション登録を要求する。

ＲＥＧＩＳＴＥＲメッセージを受信したＳＩＰサーバ１０は，レジストラ処理部１０３がレジストラＤＢ６０に，受信したＲＥＧＩＳＴＥＲメッセージのＦｒｏｍヘッダが示す要求元ＳＩＰ−ＵＲＩ（ｃｌ１＠ｈｉｔａｃｈｉ．ｃｏｍ）とＣｏｎｔａｃｔヘッダが示す要求元ＩＰアドレス（１９２．１６８．４１．１１）との関係を示すロケーションデータを登録すると，ＳＩＰメッセージ処理部１０２がロケーション登録の成功を伝えるために，ＳＩＰメッセージである２００ ＯＫメッセージＭ２０６をユーザ側通信装置４１に送信する。

以上により，ユーザ側通信装置４１のＳＩＰサーバ１０へのログインが完了し，ユーザ側通信装置４１はサービス側通信装置４２へサービスの提供を要求することが可能となる。

ログイン処理が完了したユーザ側通信装置４１は，サービス側通信装置４２にサービスの提供を要求するため，ＳＩＰメッセージ処理部４１２が，ＳＩＰメッセージであるＩＮＶＩＴＥメッセージを生成し，ＳＩＰサーバ１０へ送信する。

以下，図４から図６を用いて，ＳＩＰサーバ１０が，ログイン処理を完了したユーザ側通信装置４１から，ＩＮＶＩＴＥメッセージＭ１０１を受信した後の，ＳＩＰサーバ１０の処理フローについて説明する。

ＩＮＶＩＴＥメッセージＭ１０１を受信したＳＩＰサーバ１０はまず，レジストラ処理部１０３がレジストラＤＢ６０にアクセスして，受信したＩＮＶＩＴＥメッセージのＴｏヘッダが示す通信先ＳＩＰ−ＵＲＩのＩＰアドレスを検索する（Ｓ３０１）。

レジストラＤＢ６０から該当するＩＰアドレスが発見できなかった場合には，ＳＩＰサーバ１０は，ＳＩＰメッセージ処理部１０２が，ＳＩＰメッセージである４０４ Ｎｏｔ Ｆｏｕｎｄメッセージを生成し，ユーザ側通信装置４１へ送信した後（Ｓ３０３），処理を終了する（Ｓ３０４）。

レジストラＤＢ６０から該当するＩＰアドレスを発見できた場合には，ステップＳ３０４に遷移し，ＳＩＰサーバ１０のセッション管理部１０４が，ＩＮＶＩＴＥメッセージＭ１０１のＦｒｏｍヘッダが示す通信元ＳＩＰ−ＵＲＩと，Ｔｏヘッダが示す通信先ＳＩＰ−ＵＲＩと，Ｃａｌｌ−ＩＤヘッダが示す通信セッションの識別情報と，当該通信セッションが「確立処理中（通信先からの応答待ち）」状態であることを，現在時刻とともにセッションログＤＢ７０に記録する（Ｓ３０５）。

ＳＩＰサーバ１０のアプリケーション処理部１０５は，機能提供サーバへ処理要求を送信する（Ｓ３０６）。本実施例においては，権限判定サーバ２０へ権限判定要求メッセージＭ１０３を送信し，鍵生成サーバ４０へ鍵生成要求メッセージＭ１０４を送信する。また，ＳＩＰサーバ１０のＳＩＰメッセージ処理部１０２は，サービス側通信装置４２へＩＮＶＩＴＥメッセージＭ１０５を送信する（Ｓ３０７）。

権限判定要求メッセージＭ１０３は，アプリケーション処理部１０５によって作成され，そのボディ部は，図８に例示するようなメッセージ構造を持つ。すなわち，Ｐｅｒｍｉｓｓｉｏｎ要素のｓｔａｔｕｓ属性の値であるｒｅｑｕｅｓｔは，当該メッセージが権限判定を要求するために送信されたものであることを示し，ｉｄ属性の値３５８ａ１ａ７７は当該メッセージを一意に識別するための値として用いられる。Ｆｒｏｍ要素の値であるＳＩＰ−ＵＲＩ“ｓｉｐ：ｃｌ１＠ｈｉｔａｃｈｉ．ｃｏｍ”およびＴｏ要素の値であるＳＩＰ−ＵＲＩ“ｓｉｐ：ｓｖ１＠ｈｉｔａｃｈｉ．ｃｏｍ”は，ｓｉｐ：ｃｌ１＠ｈｉｔａｃｈｉ．ｃｏｍをＳＩＰ−ＵＲＩとして持つユーザ側通信装置４１が，ｓｉｐ：ｓｖ１＠ｈｉｔａｃｈｉ．ｃｏｍをＳＩＰ−ＵＲＩとして持つサービス側通信装置４２へサービスの提供を依頼する際に，当該権限判定要求メッセージＭ１０３が送信されたことを示している。Ｄａｔｅ要素の値である２００７−０１−０３Ｔ１５：２０：３３＋０９：００は，ＳＩＰサーバ１０によって権限判定要求メッセージが送信された時刻が２００７年１月３日の１５時２０分３３秒であることを示している。

また，鍵生成要求メッセージＭ１０４は，アプリケーション処理部１０５によって作成され，そのボディ部は，図８に例示するようなメッセージ構造を持つ。すなわち，ＫｅｙＧｅｎ要素のｓｔａｔｕｓ属性の値であるｒｅｑｕｅｓｔは，当該メッセージが鍵生成処理を要求するために送信されたものであることを示す。Ｆｒｏｍ要素，Ｔｏ要素，ＣａｌｌＩＤ要素の値は，鍵生成を要求する呼を識別するために存在し，それぞれＩＮＶＩＴＥメッセージＭ１０１のＦｒｏｍヘッダ，Ｔｏヘッダ，Ｃａｌｌ−ＩＤヘッダの値と一致する。Ｄａｔｅ要素の値については権限判定要求メッセージＭ１０３と同様である。また，Ｋｅｙ要素のｓｃｈｅｍｅ属性の値であるＡＥＳ２５６は，当該メッセージが鍵長２５６ビットのＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）アルゴリズムに基づいた鍵の生成を要求することを示している。

また，ＩＮＶＩＴＥメッセージＭ１０５は，ＳＩＰメッセージ処理部１０２によって，ユーザ側通信装置４１から受信したＩＮＶＩＴＥメッセージＭ１０１のヘッダ部に新たなＶｉａヘッダを追加し，Ｍａｘ−Ｆｏｒｗａｒｄヘッダの値を１だけ減らすことで作成される。

図４で，ＳＩＰサーバは機能提供サーバへ処理要求メッセージを送信した後，サービス側通信装置へＩＮＶＩＴＥメッセージを送信する，という処理順序をとっているが，本発明はこの順序に限定されない。各機能提供サーバへ送信する処理要求メッセージ（本実施形態では，権限判定サーバ２０への権限判定要求メッセージＭ１０３または鍵生成サーバ４０への鍵生成要求メッセージＭ１０４），およびサービス側通信装置へ送信するＩＮＶＩＴＥメッセージについては，任意の順序で送信することが可能である。

ＳＩＰサーバ１０は権限判定要求メッセージ，鍵生成要求メッセージ，およびＩＮＶＩＴＥメッセージの送信後，これらに対する応答を待ち受ける状態に遷移する（Ｓ３０８，Ｓ３０９，Ｓ３１０，Ｓ３１１）。

サービス側通信装置４２から，上記要求メッセージに対する結果を示す応答メッセージ（暫定応答メッセージであり，本実施形態の処理に影響しない１ｘｘメッセージ以外の，ＳＩＰ最終応答メッセージ）を受信した場合，当該ＳＩＰ最終応答メッセージが，サービス提供を受け入れる２００ ＯＫメッセージであれば，ＳＩＰサーバ１０のＳＩＰメッセージ処理部１０２が，サービス側通信装置４２へ確認応答のためのＡＣＫメッセージを生成し，サービス側通信装置４２へ送信した後，機能提供サーバへ依頼した処理結果のメッセージの待ち受け状態に戻る（Ｓ３０８，Ｓ３１２，Ｓ３１３）。

一方，サービス側通信装置４２から受信したＳＩＰ最終応答メッセージが，２００ ＯＫ以外の，サービス提供を拒否するメッセージであった場合（Ｓ３０８，Ｓ３１２，Ｓ３１４）には，ＳＩＰサーバ１０はサービス側通信装置がユーザ側通信装置へサービスを提供できない状態にあると判断し，ＳＩＰメッセージ処理部１０２が，受信したＳＩＰ最終応答メッセージに対するＡＣＫメッセージを生成し，サービス側通信装置４２へ送信する（図５，Ｓ４０１）。

次に，ＳＩＰサーバ１０のＳＩＰメッセージ処理部１０２が，サービス側通信装置４２から送信されたＳＩＰエラー応答メッセージ（１ｘｘ，２ｘｘ以外のＳＩＰ応答メッセージ）をユーザ側通信装置４１へ転送する（Ｓ４０２）。次に，ＳＩＰメッセージ処理部１０２は，権限判定を要求した権限判定サーバ２０と，鍵生成を要求した鍵生成サーバ４０へ，それぞれ処理要求を取り消すためのメッセージを送信し（Ｓ４０３），処理を終了する（Ｓ４０４）。

なお，上記３つの処理（Ｓ４０１，Ｓ４０２，Ｓ４０３）の実行順序は一例であって，この順序に限定されない。上記３つの処理は任意の順序で実行することが可能である。

ここで，ステップＳ４０３において，ＳＩＰサーバ１０のアプリケーション処理部１０５が権限判定サーバ２０へ送信する権限判定取消メッセージＭ１４５は，図８に例示するようなボディ部を持つ。すなわち，Ｐｅｒｍｉｓｓｉｏｎ要素のｓｔａｔｕｓ属性の値であるｃａｎｃｅｌは，当該メッセージが権限判定の要求を取り消すために送信されたものであることを示し，ｉｄ属性の値３５８ａ１ａ７７は当該メッセージが対応する権限判定要求メッセージに含まれるｉｄ属性の値と一致する。Ｆｒｏｍ要素の値であるＳＩＰ−ＵＲＩ“ｓｉｐ：ｃｌ１＠ｈｉｔａｃｈｉ．ｃｏｍ”およびＴｏ要素の値であるＳＩＰ−ＵＲＩ“ｓｉｐ：ｓｖ１＠ｈｉｔａｃｈｉ．ｃｏｍ”は，ｓｉｐ：ｃｌ１＠ｈｉｔａｃｈｉ．ｃｏｍをＳＩＰ−ＵＲＩとして持つユーザ側通信装置４１がｓｉｐ：ｓｖ１＠ｈｉｔａｃｈｉ．ｃｏｍをＳＩＰ−ＵＲＩとして持つサービス側通信装置４２へサービス提供を要求した際に，ＳＩＰサーバ１０が権限判定サーバ２０へ送信したサービス享受権限の判定処理を取り消すために，当該権限判定取消メッセージＭ１４５が送信されたことを示している。Ｄａｔｅ要素の値である２００７−０１−０３Ｔ１５：２０：３４＋０９：００は，ＳＩＰサーバ１０によって権限判定取消メッセージＭ１４５が送信された時刻が２００７年１月３日の１５時２０分３４秒であることを示している。

また，ステップＳ４０３において，ＳＩＰサーバ１０のアプリケーション処理部１０５が鍵生成サーバ４０へ送信する鍵生成取消メッセージＭ１２４は，図８に例示するようなボディ部を持つ。すなわち，ＫｅｙＧｅｎ要素のｓｔａｔｕｓ属性の値であるｃａｎｃｅｌは，当該メッセージが鍵生成の要求を取り消すために送信されたものであることを示す。Ｆｒｏｍ要素の値，Ｔｏ要素の値，ＣａｌｌＩＤ要素の値は，対応する鍵生成要求メッセージに含まれる各要素の値と一致する。Ｄａｔｅ要素の値については，権限判定取消メッセージＭ１４５と同様である。

以上が，ＳＩＰサーバ１０がサービス側通信装置４２からＳＩＰ最終応答メッセージを受信した際の，ＳＩＰサーバ１０の処理フローである。

一方，待ち受け中のＳＩＰサーバ１０が権限判定サーバ２０から権限判定結果メッセージを受信した場合，当該権限判定結果メッセージが権限判定結果［許可］メッセージＭ１１２であれば，ＳＩＰサーバ１０は他のメッセージの待ち受け状態に戻る（Ｓ３０９，Ｓ３１５）。ここで，権限判定結果［許可］メッセージＭ１１２は権限判定サーバ２０の権限判定処理部２０３によって作成され，図８に例示するようなボディ部を持つ。すなわち，Ｐｅｒｍｉｓｓｉｏｎ要素のｓｔａｔｕｓ属性の値であるａｃｃｅｐｔは，権限判定の結果，ユーザ側通信装置４１がサービス側通信装置４２のサービスを享受するための権限を保有することを示し，ｉｄ属性の値３５８ａ１ａ７７は当該メッセージが対応する権限判定要求メッセージに含まれるｉｄ属性の値と一致する。

権限判定サーバ２０から受信した権限判定結果メッセージが，権限判定結果［拒否］メッセージＭ１２１であった場合，すなわちユーザ側通信装置４１がサービス側通信装置４２のサービスを享受するための権限を持たなかった場合，ＳＩＰサーバ１０は直ちに，セッションの確立を中断する処理に移行する（Ｓ３０９，Ｓ３１５，Ｓ３１６）。ここで，権限判定結果［拒否］メッセージＭ１２１は権限判定サーバ２０の権限判定処理部２０３によって作成され，図８に例示するようなボディ部を持つ。すなわち，Ｐｅｒｍｉｓｓｉｏｎ要素のｓｔａｔｕｓ属性の値であるｒｅｊｅｃｔは，権限判定の結果として，ユーザ側通信装置４１がサービス側通信装置４２のサービスを享受するための権限を持たないことを示し，ｉｄ属性の値３５８ａ１ａ７７は当該メッセージが対応する権限判定要求メッセージに含まれるｉｄ属性の値と一致する。

ここで，ＳＩＰサーバ１０がセッション確立を中断するための処理フローについて説明する。

ＳＩＰサーバ１０のＳＩＰメッセージ処理部１０２は，ユーザ側通信装置４１がサービス側通信装置４２のサービスを享受するための権限を持たなかったことを示すため，ＳＩＰメッセージである４０３Ｆｏｒｂｉｄｄｅｎメッセージを生成し，ユーザ側通信装置４１へ送信する（Ｓ５０１）。

ＳＩＰサーバ１０のアプリケーション処理部１０５は，要求処理中の機能提供サーバ，すなわちここでは鍵生成サーバ４０へ，鍵生成取消メッセージＭ１２２を送信する（Ｓ５０２）。

次に，ＳＩＰサーバ１０のＳＩＰメッセージ処理部１０２は，サービス側通信装置４２への接続要求を取り消すための処理を行う。当該処理については，ＳＩＰサーバ１０が，ＩＮＶＩＴＥに対する２００ ＯＫメッセージをサービス側通信装置４２から既に受信している場合と，そうでない場合によって，手順が異なる。以下，一つずつ順に説明する。

まず，ＳＩＰサーバ１０が，ＩＮＶＩＴＥに対する２００ ＯＫメッセージをサービス側通信装置４２から既に受信している，場合，ＳＩＰサーバ１０のＳＩＰメッセージ処理部１０２は，ＳＩＰメッセージであるＢＹＥメッセージをサービス側通信装置４２へ送信することで，サービス側通信装置４２との間で確立していたＳＩＰダイアログを解消し（Ｓ５０４），処理を終了する（Ｓ５０５）。ここで，ＢＹＥメッセージＭ１２４はＳＩＰメッセージ処理部１０２によって作成され，図８に例示するようなボディ部を持つ。すなわち，ＳｅｓｓｉｏｎＩｎｆｏ要素のｓｔａｔｕｓ属性の値であるｃａｎｃｅｌは，当該ＢＹＥメッセージが，既に確立したセッションの終了を通知するために送信されたわけではなく，まだ確立していないセッションの確立処理を中断するために送信されたものであることを明示するために付加している。Ｆｒｏｍ要素の値であるＳＩＰ−ＵＲＩ“ｓｉｐ：ｃｌ１＠ｈｉｔａｃｈｉ．ｃｏｍ”およびＴｏ要素の値であるＳＩＰ−ＵＲＩ“ｓｉｐ：ｓｖ１＠ｈｉｔａｃｈｉ．ｃｏｍ”は，ｓｉｐ：ｃｌ１＠ｈｉｔａｃｈｉ．ｃｏｍをＳＩＰ−ＵＲＩとして持つユーザ側通信装置４１からｓｉｐ：ｓｖ１＠ｈｉｔａｃｈｉ．ｃｏｍをＳＩＰ−ＵＲＩとして持つサービス側通信装置４２へのセッション確立を中断するために，当該ＢＹＥメッセージＭ１２４が送信されたことを示している。Ｄａｔｅ要素の値については，権限判定取消メッセージＭ１４５と同様である。

次に，ＳＩＰサーバ１０が，ＩＮＶＩＴＥに対する２００ ＯＫメッセージをサービス側通信装置４２から受信していない，場合，ＳＩＰメッセージ処理部１０２がＣＡＮＣＥＬメッセージをサービス側通信装置４２へ送信することで，サービス側通信装置４２との間で試みていたセッション確立を中断する（Ｓ５０６）。

ステップＳ５０６においては，ネットワーク０上の通信障害などの理由で，ＳＩＰサーバ１０が送信したＣＡＮＣＥＬメッセージがサービス側通信装置４２へ届かない可能性が存在する。届かない場合，サービス側通信装置４２はプロセス起動処理等，セッション確立のための処理を続け，ＳＩＰサーバ１０へＩＮＶＩＴＥに対する最終応答である２００ ＯＫメッセージを送信するので，サービス側通信装置４２からは，ユーザ側通信装置４１との間のセッションが確立したように見えており，セッション確立の中断は達成できていない状態になる。

そのため，ＳＩＰサーバ１０のＳＩＰメッセージ処理部１０２は，ＣＡＮＣＥＬメッセージを送信したにも係わらず，先に送信したＩＮＶＩＴＥメッセージやＣＡＮＣＥＬメッセージと同じＣａｌｌ−ＩＤヘッダを持ち，かつＣＳｅｑヘッダに文字列”ＩＮＶＩＴＥ”を含む２００ ＯＫメッセージをサービス側通信装置４２から受信した場合には，サービス側通信装置４２に対してＢＹＥメッセージを送信することで，サービス側通信装置４２との間で確立していたセッションを切断する（Ｓ５０７，Ｓ５０４）。ここで送信されるＢＹＥメッセージは，図８で示したものと同一である。ＢＹＥメッセージを送信した後，ＳＩＰサーバ１０は処理を終了する（Ｓ５０５）。

サービス側通信装置４２へＣＡＮＣＥＬメッセージを送信して一定時間が経過した場合，ＳＩＰサーバ１０はサービス側通信装置４２が当該ＣＡＮＣＥＬメッセージを受信したとみなし，処理を終了する（Ｓ５０８，Ｓ５０５）。

以上が，ＳＩＰサーバ１０が権限判定サーバ２０から権限判定結果メッセージを受信した際の，ＳＩＰサーバ１０の処理フローである。

一方，待ち受け中のＳＩＰサーバ１０が鍵生成サーバ４０から鍵生成結果メッセージＭ１１３を受信した場合，ＳＩＰサーバ１０は，アプリケーション処理部１０５が，当該鍵生成結果メッセージに含まれる鍵情報をセッションログＤＢ７０に保存する（Ｓ３１０，Ｓ３１７）。すなわちＳＩＰサーバ１０は，セッションログＤＢ７０において，鍵生成結果メッセージボディ部Ｍ１１３−１に含まれるＦｒｏｍ要素の値，Ｔｏ要素の値，ＣａｌｌＩＤ要素の値に対応するテーブルエントリに，セッション鍵情報として当該鍵生成結果メッセージボディ部に含まれるＫｅｙ要素の値を記録する。ここで，鍵生成結果メッセージＭ１１３は鍵生成サーバ４０の鍵生成処理部４０３によって作成され，図８に示すようなボディ部を持つ。すなわち，ＫｅｙＧｅｎ要素のｓｔａｔｕｓ属性の値であるｒｅｓｐｏｎｓｅは，当該メッセージが鍵生成の結果得られた鍵を転送するために送信されたものであることを示す。Ｆｒｏｍ要素の値，Ｔｏ要素の値，ＣａｌｌＩＤ要素の値は，対応する鍵生成要求メッセージに含まれる各要素の値と一致する。Ｄａｔｅ要素の値については，権限判定取消メッセージＭ１４５と同様である。また，Ｋｅｙ要素のｓｃｈｅｍｅ属性の値であるＡＥＳ２５６は，Ｋｅｙ要素に含まれる情報が鍵長２５６ビットのＡＥＳアルゴリズムで用いられる鍵であることを示し，Ｋｅｙ要素内のＯｃｔｅｔＳｔｒｉｎｇ要素の値は，セッション鍵情報を示す。

以上が，ＳＩＰサーバ１０が鍵生成サーバ４０から鍵生成結果メッセージを受信した際の，ＳＩＰサーバ１０の処理フローである。

待ち受け状態のＳＩＰサーバ１０は，サービス側通信装置４２と，権限判定サーバ２０と，鍵生成サーバ４０と，の全てからメッセージを受信すると，セッション確立の最終処理に移行する（Ｓ３１１，Ｓ３１８）。

セッション確立の最終処理では，ＳＩＰサーバ１０は初めに，アプリケーション処理部１０５が，機能提供サーバから取得してセッションログＤＢ７０へ記録した情報のうち，ユーザ側通信装置およびサービス側通信装置へ伝えるべき情報が存在するかどうかを確認する（Ｓ６０１）。ここでユーザ側通信装置およびサービス側通信装置へ伝えるべき情報とは，具体的には，鍵生成サーバ４０によって生成されたセッション鍵情報などを指す。

ユーザ側通信装置およびサービス側通信装置へ伝えるべき情報が存在する場合は，ＳＩＰサーバ１０は，情報をユーザ側通信装置４１およびサービス側通信装置４２へ伝えるために必要な処理（Ｓ６０２，Ｓ６０３）を行う。

すなわち，ＳＩＰサーバ１０は初めに，サービス側通信装置４２へＵＰＤＡＴＥメッセージを送信する（Ｓ６０２）。ＵＰＤＡＴＥメッセージＭ１１４はＳＩＰメッセージ処理部１０２によって作成され，セッションログＤＢ７０に記録された鍵情報をボディ部に含む。

続けて，ユーザ側通信装置およびサービス側通信装置へ伝えるべき情報が存在する場合，ＳＩＰサーバ１０は，ＳＩＰメッセージ処理部１０２が，セッションログＤＢ７０に記録された鍵情報をコピーし，２００ ＯＫメッセージＭ１１６のボディ部を生成する（Ｓ６０３）。

以上が，ユーザ側通信装置およびサービス側通信装置へ伝えるべき情報が存在する場合に，ＳＩＰサーバ１０が情報を各通信装置へ伝えるために行う処理フローである。

セッション確立の最終処理では，ＳＩＰサーバ１０は，ＳＩＰメッセージ処理部１０２が，サービス側通信装置４２から受信していた２００ ＯＫメッセージＭ１０９のヘッダ部から，自ＵＲＩを含むＶｉａヘッダを除去することで２００ ＯＫメッセージＭ１１６のヘッダ部を作成し，ユーザ側通信装置４１へ送信する（Ｓ６０４）。メッセージのボディ部については，ユーザ側通信装置およびサービス側通信装置へ伝えるべき情報が存在する場合には，ステップＳ６０３で生成したボディ部を用いる。ユーザ側通信装置およびサービス側通信装置へ伝えるべき情報が存在しない場合には，ボディ部には情報を含めずに送信する。

最後にＳＩＰサーバ１０は，後に課金サーバ３０が課金処理を行う際に用いるセッションログの収集を開始する（Ｓ６０５）。すなわち，ＳＩＰサーバ１０のセッション管理部１０４が，ＩＮＶＩＴＥメッセージＭ１０１のＦｒｏｍヘッダが示す通信元ＳＩＰ−ＵＲＩと，Ｔｏヘッダが示す通信先ＳＩＰ−ＵＲＩと，Ｃａｌｌ−ＩＤヘッダが示す通信セッションの識別情報と，に対応するエントリに対し，当該通信セッションの開始時刻として現在時刻をセッションログＤＢ７０に記録する。図７に，セッションログＤＢ７０に保存されたセッションログ情報の一例を示す。

以上が，ＳＩＰサーバ１０が，ログイン処理を完了したユーザ側通信装置４１から，ＩＮＶＩＴＥメッセージＭ１０１を受信した後の，ＳＩＰサーバ１０の処理フローとなる。

次に，図１０から図１４を用いて，ログイン処理が完了したユーザ側通信装置４１がサービス側通信装置４２にサービスの提供を要求する際のシーケンスを示す。

はじめに図１０を用いて，ユーザ側通信装置４１がサービス側通信装置４２のサービスを享受するための権限を有する場合のシーケンスについて説明する。

まず，ユーザ側通信装置４１がサービス側通信装置４２にサービスの提供を要求する場合，ユーザ側通信装置４１はＳＩＰサーバ１０へＳＩＰメッセージであるＩＮＶＩＴＥメッセージＭ１０１を送信する。

ＳＩＰサーバ１０は，ユーザ側通信装置４１からＩＮＶＩＴＥメッセージＭ１０１を受信すると，処理フローＳ３０２に従い，レジストラ処理部１０３がレジストラＤＢ６０にアクセスして，受信したＩＮＶＩＴＥメッセージのＴｏヘッダが示す受信者ＳＩＰ−ＵＲＩのＩＰアドレスを検索する。登録されているユーザ側通信装置４１のＩＰアドレスを発見すると，ＳＩＰサーバ１０は処理フローＳ３０５に従い，セッション管理部１０４が，通信元ＳＩＰ−ＵＲＩと，通信先ＳＩＰ−ＵＲＩと，通信セッションの識別情報と，当該通信セッションが「確立処理中（通信先からの応答待ち）」状態であることを，現在時刻とともにセッションログＤＢ７０に記録する（Ｍ１０２）。

次に，ＳＩＰサーバ１０は，処理フローＳ３０６に従い，権限判定サーバ２０へ権限判定要求メッセージＭ１０３を送信し，鍵生成サーバ４０へ鍵生成要求メッセージＭ１０４を送信する。また，ＳＩＰサーバ１０は，処理フローＳ３０７に従い，サービス側通信装置４１へＩＮＶＩＴＥメッセージＭ１０５を送信する。

権限判定要求メッセージＭ１０３はアプリケーション処理部１０５によって作成され，図８に示すようなボディ部を持つ。

また，鍵生成要求メッセージＭ１０４は，アプリケーション処理部１０５によって作成され，図８に示すようなボディ部を持つ。

また，ＩＮＶＩＴＥメッセージＭ１０５は，ＳＩＰメッセージ処理部１０２によって，ユーザ側通信装置４１から受信したＩＮＶＩＴＥメッセージＭ１０１のヘッダ部に新たなＶｉａヘッダを追加し，Ｍａｘ−Ｆｏｒｗａｒｄヘッダの値を１だけ減らすことで作成される。

図１０から図１４で，ＳＩＰサーバ１０は権限判定要求メッセージＭ１０３，鍵生成要求メッセージＭ１０４，ＩＮＶＩＴＥメッセージＭ１０５の順でメッセージを送信しているが，本発明はこの順序に限定されない。これら３つのメッセージは任意の順序で送信することが可能である。

権限判定要求メッセージＭ１０３を受信した権限判定サーバ２０は，権限判定処理部２０３が権限ＤＢ８０に権限情報の問い合わせを行う（Ｍ１０６）。

また，鍵生成要求Ｍ１０４を受信した鍵生成サーバ４０は，鍵生成処理部４０３が鍵生成処理を開始する（Ｍ１０７）。

また，ＩＮＶＩＴＥメッセージＭ１０５を受信したサービス側通信装置４２は，サーバ処理部４２３が，サービスの提供に当たって必要となる初期化処理（プロセスの起動等）を開始する（Ｍ１０８）。

サービス側通信装置４２は，当該初期化処理が完了すると，ＳＩＰメッセージ処理部４２３が，ＳＩＰメッセージである２００ ＯＫメッセージＭ１０９を生成し，ＳＩＰサーバ１０へ送信する。

ＳＩＰサーバ１０は，サービス側通信装置４２から２００ ＯＫメッセージＭ１０９を受信すると，処理フローＳ３１３に従い，ＳＩＰメッセージ処理部１０２が，当該２００ ＯＫメッセージに対するＡＣＫメッセージＭ１１０を生成し，サービス側通信装置４２へ送信する。

サービス側通信装置４２は，ＳＩＰサーバ１０からＡＣＫメッセージＭ１１０を受信すると，サーバ処理部４２３が，ユーザ側通信装置４１に対するサービスの提供記録（アプリケーションログ）の収集を開始する（Ｍ１１１）。アプリケーションログはアプリケーションログＤＢ５０内に記録される。図７に，アプリケーションログＤＢ５０に保存されたアプリケーションログ情報の一例を示す。

権限判定サーバ２０は，権限判定処理の結果，ユーザ側通信装置４１がサービス側通信装置４２のサービスを享受するための権限を持つことを確認すると，ＳＩＰサーバ１０へ権限判定結果［許可］メッセージＭ１１２を送信する。権限判定結果［許可］メッセージＭ１１２は権限判定処理部２０３によって作成され，図８に示すようなボディ部を持つ。

鍵生成サーバ４０は，鍵生成処理を完了すると，ＳＩＰサーバ１０へ鍵生成結果メッセージＭ１１３を送信する。鍵生成結果メッセージＭ１１３は鍵生成処理部４０３によって作成され，図８に示すようなボディ部を持つ。

ＳＩＰサーバ１０は，鍵生成サーバ４０から鍵生成結果メッセージＭ１１３を受信すると，処理フローＳ３１７に従い，アプリケーション処理部１０５が，当該鍵生成結果メッセージに含まれる鍵情報をセッションログＤＢ７０に保存する。

ＳＩＰサーバ１０は，サービス側通信装置４２，鍵生成サーバ４０，権限判定サーバ２０の３者からメッセージを受信すると，処理フローＳ３１１に従い，セッション確立の最終処理に移行する。

本実施例では，ユーザ側通信装置およびサービス側通信装置へ伝えるべき情報として，鍵生成サーバによって生成されたセッション鍵情報が存在するため，ＳＩＰサーバ１０は処理フローＳ６０２に従い，ＳＩＰメッセージ処理部１０２がＵＰＤＡＴＥメッセージＭ１１４を生成し，サービス側通信装置４２へ送信する。

サービス側通信装置４２は，ＳＩＰサーバ１０からＵＰＤＡＴＥメッセージＭ１１４を受信すると，ＳＩＰメッセージ処理部４２２が，当該ＵＰＤＡＴＥメッセージのボディ部に含まれるセッション鍵情報を取得した後，当該ＵＰＤＡＴＥメッセージに対する２００ ＯＫメッセージＭ１１５をＳＩＰサーバ１０へ送信し，ユーザ側通信装置４１へのサービス提供が可能な状態へ遷移する。

また，ＳＩＰサーバ１０は，処理フローＳ６０３に従い，ＳＩＰメッセージ処理部１０２が，２００ ＯＫメッセージＭ１１６のボディ部を生成し，サービス側通信装置４２から受信していた２００ ＯＫメッセージＭ１０９のヘッダ部から，自ＵＲＩを含むＶｉａヘッダを除去することで生成したヘッダ部と結合し，２００ ＯＫメッセージＭ１１６としてユーザ側通信装置４１へ送信する。

ユーザ側通信装置４１は，２００ ＯＫメッセージＭ１１６を受信すると，ＳＩＰメッセージ処理部４１２がＡＣＫメッセージＭ１１７を生成し，ＳＩＰサーバ１０へ送信する。

ＳＩＰサーバ１０は，ユーザ側通信装置４１からＡＣＫメッセージＭ１１７を受信すると，処理フローＳ６０５に従い，セッション管理部１０４が，ユーザ側通信装置４１とサービス側通信装置４２間のセッション記録（セッションログ）をセッションログＤＢ７０へ収集し始める（Ｍ１１８）。

以上の手順によって，ユーザ側通信装置４１とサービス側通信装置４２との間に通信セッションが確立され（Ｍ１１９），ユーザ側通信装置４１からサービス側通信装置４２へのアクセスと，サービス側通信装置４２からユーザ側通信装置４１への情報サービスが可能となる。ユーザ側通信装置４１とサービス側通信装置４２との間の通信は，セッション確立中に得られたセッション鍵情報を用いて暗号化される。また，セッションが解放されるまでの間，ＳＩＰサーバ１０によるセッションログの収集と，サービス側通信装置４２によるアプリケーションログの収集が継続される。

以上が，ユーザ側通信装置４１がサービス側通信装置４２のサービスを享受するための権限を有する場合のシーケンスとなる。

本シーケンスにおいては，権限判定サーバ２０による権限判定処理Ｍ１０６と，鍵生成サーバによる鍵生成処理Ｍ１０７と，サービス側通信装置４２によるプロセス起動処理等Ｍ１０８と，が並行して行われる。このため，それぞれの処理を一つ一つ順に行う従来の手順と比較して，通信開始までに要する時間が短縮される，という効果がある。

次に図１１を用いて，ユーザ側通信装置４１がサービス側通信装置４２へセッションの切断を要求する場合のシーケンスについて説明する。

ユーザ側通信装置４１がサービス側通信装置４２にセッションの切断を要求する場合，ユーザ側通信装置４１はまず，ＳＩＰメッセージ処理部４１２が，ＳＩＰサーバ１０へＳＩＰメッセージであるＢＹＥメッセージＭ３０１を送信する。

ＳＩＰサーバ１０は，ユーザ側通信装置４１からＢＹＥメッセージＭ３０１を受信すると，セッション管理部１０４が，セッションログＤＢ７０において，鍵生成結果メッセージボディ部Ｍ１１３−１に含まれるＦｒｏｍ要素の値，Ｔｏ要素の値，ＣａｌｌＩＤ要素の値に対応するテーブルエントリに，当該通信セッションが「切断処理中（通信先からの応答待ち）」状態であることを記録する。

続いてＳＩＰサーバ１０は，ＳＩＰメッセージ処理部１０２が，ＢＹＥメッセージＭ３０１のヘッダ部に新たなＶｉａヘッダを追加し，Ｍａｘ−Ｆｏｒｗａｒｄヘッダの値を１だけ減らすことでＢＹＥメッセージＭ３０２を作成し，サービス側通信装置４２へ送信する。

サービス側通信装置４２は，ＳＩＰサーバ１０からＢＹＥメッセージＭ３０２を受信すると，ＳＩＰメッセージ処理部４２２が，当該ＢＹＥメッセージに対する応答となる２００ ＯＫメッセージＭ３０３をＳＩＰサーバ１０へ送信した後，サーバ処理部４２３が，ユーザ側通信装置４１へのサービス提供を終了するとともに，アプリケーションログの収集を停止する。また，ＳＩＰメッセージ処理部４２２が，受信したＢＹＥメッセージＭ３０２のボディ部に，ｓｔａｔｕｓ属性がｃａｎｃｅｌであるＳｅｓｓｉｏｎＩｎｆｏ要素が含まれるか否かをチェックする。本シーケンスにおいては，当該要素がＢＹＥメッセージのボディ部に含まれないため，サービス側通信装置４２は，アプリケーションログ情報メッセージＭ３０５を生成し，課金サーバ３０へ送信する。ここでアプリケーションログ情報メッセージＭ３０５はサーバ処理部４２３によって作成され，図９に示すようなボディ部を持つ。

ＳＩＰサーバ１０は，サービス側通信装置４２から２００ ＯＫメッセージＭ３０３を受信すると，ＳＩＰメッセージ処理部１０２が，当該２００ ＯＫメッセージのヘッダ部から自ＵＲＩを含むＶｉａヘッダを除去することで２００ ＯＫメッセージＭ３０４を作成し，ユーザ側通信装置４１へ送信する。次に，セッション管理部１０４が，２００ ＯＫメッセージＭ３０３のＦｒｏｍヘッダが示す通信元ＳＩＰ−ＵＲＩと，Ｔｏヘッダが示す通信先ＳＩＰ−ＵＲＩと，Ｃａｌｌ−ＩＤヘッダが示す通信セッションの識別情報に対応するセッションログＤＢ７０中のテーブルエントリへ，セッション終了時刻として現在時刻を記録し，セッションログの収集を停止する。

この後，ＳＩＰサーバ１０は，セッションログ情報をボディ部に含むセッションログ情報メッセージＭ３０６を生成し，課金サーバ３０へ送信する。ここでセッションログ情報メッセージＭ３０６はセッション管理部１０４によって作成され，図９に示すようなボディ部を持つ。

以上が，ユーザ側通信装置４１がサービス側通信装置４２へセッションの切断を要求する場合のシーケンスとなる。

次に図１２を用いて，ユーザ側通信装置４１がサービス側通信装置４２のサービスを享受するための権限を持たない場合で，かつサービス側通信装置４２からの２００ ＯＫメッセージが権限判定の結果よりも先に通知された場合のシーケンスについて説明する。

ユーザ側通信装置４１がＳＩＰサーバ１０へＩＮＶＩＴＥメッセージＭ１０１を送信してから，サービス側通信装置４２がアプリケーションログの収集を開始（Ｍ１１１）するまでのシーケンスについては，図１０で示したシーケンスと同様であるため，説明を省略する。

この後，権限判定サーバ２０は，権限判定処理の結果，ユーザ側通信装置４１がサービス側通信装置４２のサービスを享受するための権限を持たないことを確認すると，ＳＩＰサーバ１０へ権限判定結果［拒否］メッセージＭ１２１を送信する。権限判定結果［拒否］メッセージＭ１２１は権限判定処理部２０３によって作成され，図８に示すようなボディ部を持つ。

ＳＩＰサーバ１０は，権限判定サーバ２０から権限判定結果［拒否］メッセージＭ１２１を受信すると，処理フローＳ５０１に従い，ＳＩＰメッセージ処理部１０２が，ＳＩＰメッセージである４０３ＦｏｒｂｉｄｄｅｎメッセージＭ１２２を生成し，ユーザ側通信装置４１へ送信する。

ユーザ側通信装置４１は，ＳＩＰサーバ１０から４０３ＦｏｒｂｉｄｄｅｎメッセージＭ１２２を受信すると，ＳＩＰメッセージ処理部４１２が，ＡＣＫメッセージＭ１２３を生成し，ＳＩＰサーバ１０へ送信する。

ＳＩＰサーバ１０は，ユーザ側通信装置４１へ４０３ＦｏｒｂｉｄｄｅｎメッセージＭ１２２を送信した後，処理フローＳ５０２に従い，鍵生成サーバ４０へ鍵生成取消メッセージＭ１２４を送信する。鍵生成取消メッセージＭ１２４はアプリケーション処理部１０５によって作成され，図８に示すようなボディ部を持つ。

鍵生成サーバ４０は，ＳＩＰサーバ１０から鍵生成取消メッセージＭ１２４を受信すると，鍵生成処理部４０３が，処理中であった鍵生成処理を終了する。続いて，メッセージ処理部４０２が，鍵生成取消応答メッセージＭ１２５を生成し，ＳＩＰサーバ１０へ送信する。ここで鍵生成取消応答メッセージＭ１２５は，図８に示すようなボディ部を持つ。

ここで図８を用いて鍵生成取消応答メッセージボディ部Ｍ１２５−１の一例について説明する。ＫｅｙＧｅｎ要素のｓｔａｔｕｓ属性の値であるｃａｎｃｅｌｅｄは，当該メッセージが鍵生成の取消要求に対する応答として送信されたものであることを示す。ＫｅｙＧｅｎ要素の内容は，対応する鍵生成取消メッセージボディ部Ｍ１２４−１のＫｅｙＧｅｎ要素の内容と同一である。

次にＳＩＰサーバ１０は，処理フローＳ５０３に従い，サービス側通信装置４２から２００ ＯＫメッセージを受信しているかどうかを判定する。本シーケンスにおいては，この時点でサービス側通信装置４２から２００ ＯＫメッセージを受信している場合を扱うため，処理フローＳ５０４に従い，サービス側通信装置４２へＢＹＥメッセージＭ１２６を送信する。ＢＹＥメッセージＭ１２６はＳＩＰメッセージ処理部１０２によって生成され，図８に示すようなボディ部を持つ。

サービス側通信装置４２は，ＳＩＰサーバ１０からＢＹＥメッセージＭ１２６を受信すると，ＳＩＰメッセージ処理部４２２が，当該ＢＹＥメッセージに対する応答となる２００ ＯＫメッセージＭ１２７を生成し，ＳＩＰサーバ１０へ送信する。次に，サービス側通信装置４２は，サーバ処理部４２３が，ユーザ側通信装置４１へのサービス提供可能状態を終了するとともに，アプリケーションログの収集を停止する。また，ＳＩＰメッセージ処理部４２２が，受信したＢＹＥメッセージＭ１２６のボディ部に，ｓｔａｔｕｓ属性がｃａｎｃｅｌであるＳｅｓｓｉｏｎＩｎｆｏ要素が含まれるか否かをチェックする。本シーケンスにおいては，当該要素がＢＹＥメッセージのボディ部に含まれるため，サービス側通信装置４２は，アプリケーションログ情報メッセージを課金サーバ３０へ送信しない。

最後に，ＳＩＰサーバ１０は，サービス側通信装置４２からＢＹＥメッセージに対する２００ ＯＫメッセージＭ１２７を受信し，処理を終了する。

以上が，ユーザ側通信装置４１がサービス側通信装置４２のサービスを享受するための権限を持たない場合で，かつサービス側通信装置４２からの２００ ＯＫメッセージが権限判定の結果よりも先に通知された場合のシーケンスとなる。

本シーケンスにおいては，一旦ＳＩＰサーバ１０とサービス側通信装置４２の間で確立したＳＩＰダイアログを解消するために利用したＢＹＥメッセージのボディ部に，ユーザ側通信装置４１がセッションを確立することができなかったことを示す情報（図８のＢＹＥメッセージボディＭ１２６−１に示す，ＳｅｓｓｉｏｎＩｎｆｏ要素のｓｔａｔｕｓ属性の値であるｃａｎｃｅｌ）を含めていることを特徴とする。当該情報を含めることにより，サービス側通信装置４２は，受信したＢＹＥメッセージがセッションを終了させるために送信されたものか，あるいはセッション確立処理が途中で中断されたことを示すために送信されたものであるか，を判別することができる。これにより，課金サーバ３０へ不要なアプリケーションログが送信されることを防ぎ，結果として，不正な課金処理が発生することを防ぐ，という効果がある。

次に図１３を用いて，ユーザ側通信装置４１がサービス側通信装置４２のサービスを享受するための権限を持たない場合で，かつサービス側通信装置４２からの２００ ＯＫメッセージよりも先に権限判定の結果が通知された場合のシーケンスについて説明する。

ユーザ側通信装置４１がＳＩＰサーバ１０へＩＮＶＩＴＥメッセージＭ１０１を送信してから，サービス側通信装置４２がプロセス起動処理等を開始する（Ｍ１０８）までのシーケンスについては，図１０で示したシーケンスと同様であるため，説明を省略する。

この後，権限判定サーバ２０は，権限判定処理部２０３が，サービス側通信装置４２が２００ ＯＫメッセージを送信するよりも先に権限判定処理を済ませ，ユーザ側通信装置４１がサービス側通信装置４２のサービスを享受するための権限を持たないことを確認すると，ＳＩＰサーバ１０へ権限判定結果［拒否］メッセージＭ１２１を送信する。権限判定結果［拒否］メッセージＭ１２１はメッセージ処理部２０２によって作成され，図８に示すようなボディ部を持つ。

ＳＩＰサーバ１０は，権限判定サーバ２０から権限判定結果［拒否］メッセージＭ１２１を受信すると，処理フローＳ５０１に従い，ＳＩＰメッセージ処理部１０２が，４０３ＦｏｒｂｉｄｄｅｎメッセージＭ１２２を送信する。

ユーザ側通信装置４１は，ＳＩＰサーバ１０から４０３ＦｏｒｂｉｄｄｅｎメッセージＭ１２２を受信すると，ＳＩＰメッセージ処理部４１２が，ＡＣＫメッセージＭ１２３を生成し，ＳＩＰサーバ１０へ送信する。

ＳＩＰサーバ１０は，ユーザ側通信装置４１へ４０３ＦｏｒｂｉｄｄｅｎメッセージＭ１２２を送信した後，処理フローＳ５０２に従い，鍵生成サーバ４０へ鍵生成取消メッセージＭ１２４を送信する。鍵生成取消メッセージＭ１２４はアプリケーション処理部１０５によって作成され，図８に示すようなボディ部を持つ。

鍵生成サーバ４０は，ＳＩＰサーバ１０から鍵生成取消メッセージＭ１２４を受信すると，鍵生成処理部４０３が，処理中であった鍵生成処理を終了する。続いて，メッセージ処理部４０２が，鍵生成取消応答メッセージＭ１２５を生成し，ＳＩＰサーバ１０へ送信する。ここで鍵生成取消応答メッセージＭ１２５は，図８に示すようなボディ部を持つ。

次にＳＩＰサーバ１０は，処理フローＳ５０３に従い，サービス側通信装置４２から２００ ＯＫメッセージを受信しているかどうかを判定する。本シーケンスにおいては，この時点でまだサービス側通信装置４２から２００ ＯＫメッセージを受信していない場合を扱うため，処理フローＳ５０６に従い，ＳＩＰメッセージ処理部４２２が，サービス側通信装置４２へＳＩＰメッセージであるＣＡＮＣＥＬメッセージＭ１３１を送信する。

サービス側通信装置４２は，ＳＩＰサーバ１０からＣＡＮＣＥＬメッセージＭ１３１を受信すると，ＳＩＰメッセージ処理部４２２が，当該ＣＡＮＣＥＬメッセージに対する応答となる２００ ＯＫメッセージＭ１３２を生成し，ＳＩＰサーバ１０へ送信する。

続いて，サービス側通信装置４２は，ＳＩＰメッセージ処理部４２２が，ＳＩＰサーバ１０へＳＩＰ最終応答メッセージである４８７ Ｒｅｑｕｅｓｔ Ｔｅｒｍｉｎａｔｅｄメッセージを送信する。

ＳＩＰサーバ１０は，サービス側通信装置４２からＣＡＮＣＥＬメッセージＭ１３１に対する２００ ＯＫメッセージＭ１３２を受信すると，処理フローＳ５０８，Ｓ５０５に従い，処理を終了する。

次に図１４を用いて，サービス側通信装置４２がサービスを提供できない状態であった場合のシーケンスについて説明する。

ユーザ側通信装置４１がＳＩＰサーバ１０へＩＮＶＩＴＥメッセージＭ１０１を送信してから，ＳＩＰサーバ１０がサービス側通信装置４２へＩＮＶＩＴＥメッセージＭ１０５を送信するまでのシーケンスについては，図１０で示したシーケンスと同様であるため，説明を省略する。

続いてサービス側通信装置４２が，何らかの理由でサービスを提供できない状態であることを伝えるために，ＳＩＰメッセージ処理部４２２が，ＳＩＰサーバ１０へＳＩＰエラー応答メッセージＭ１４１を送信する。例えば，サービス側通信装置４２はＳＩＰメッセージである４８６Ｂｕｓｙ Ｈｅｒｅメッセージを送信することで，サービス側通信装置４２が既に他のユーザ側通信装置と多数のセッションを確立しており，これ以上新しいセッションを確立することができない状況にあることを通知することができる。

ＳＩＰサーバ１０は，ＳＩＰエラー応答メッセージＭ１４１を受信すると，処理フローＳ４０１に従い，ＳＩＰメッセージ処理部１０２が，サービス側通信装置４２へＡＣＫメッセージＭ１４２を送信する。

次に，ＳＩＰサーバ１０は，処理フローＳ４０２に従い，ＳＩＰメッセージ処理部１０２が，サービス側通信装置４２から受信していたＳＩＰエラー応答メッセージＭ１４１のヘッダ部から自ＵＲＩを含むＶｉａヘッダを除去することでＳＩＰエラー応答メッセージＭ１４３を生成し，ユーザ側通信装置４１へ送信する。

ユーザ側通信装置４１は，ＳＩＰサーバ１０からＳＩＰエラー応答メッセージＭ１４３を受信すると，ＳＩＰメッセージ処理部４１２が，ＳＩＰサーバ１０へＡＣＫメッセージＭ１４４を送信する。

次に，ＳＩＰサーバ１０は，処理フローＳ４０３に従い，機能提供サーバへ処理要求を取り消すためのメッセージを送信する。本シーケンスにおいては，要求処理中の機能提供サーバとして権限判定サーバ２０および鍵生成サーバ４０が存在する。

まず，ＳＩＰサーバ１０は，アプリケーション処理部１０５が，権限判定取消メッセージＭ１４５を生成し，権限判定サーバ２０へ送信する。権限判定取消メッセージＭ１４５は，図８に示すようなボディ部を持つ。

権限判定サーバ２０は，ＳＩＰサーバ１０から権限判定取消メッセージＭ１４２を受信すると，権限判定処理部２０３が，処理中であった権限判定処理を終了する。続いて，メッセージ処理部２０２が，権限判定取消応答メッセージＭ１４６を生成し，ＳＩＰサーバ１０へ送信する。権限判定取消応答メッセージＭ１４６は，図８に示すようなボディ部を持つ。

ここで図８を用いて権限判定取消応答メッセージボディ部Ｍ１４６−１の一例について説明する。Ｐｅｒｍｉｓｓｉｏｎ要素のｓｔａｔｕｓ属性の値であるｃａｎｃｅｌｅｄは，当該メッセージが権限判定の中断要求に対する応答として送信されたものであることを示し，ｉｄ属性の値３５８ａ１ａ７７は当該メッセージが対応する権限判定中断メッセージに含まれるｉｄ属性の値と一致する。Ｐｅｒｍｉｓｓｉｏｎ要素の内容は，対応する権限判定中断メッセージボディ部Ｍ１４２−１のＰｅｒｍｉｓｓｉｏｎ要素の内容と同一である。

また，ＳＩＰサーバ１０は，アプリケーション処理部１０５が，鍵生成取消メッセージＭ１２４を生成し，鍵生成サーバ４０へ送信する。鍵生成取消メッセージＭ１２４は，図８に示すようなボディ部を持つ。

鍵生成サーバ４０は，ＳＩＰサーバ１０から鍵生成取消メッセージＭ１２４を受信すると，鍵生成処理部４０３が，処理中であった鍵生成処理を終了する。続いて，メッセージ処理部４０２が，鍵生成取消応答メッセージＭ１２５を生成し，ＳＩＰサーバ１０へ送信する。ここで鍵生成取消応答メッセージＭ１２５は鍵生成処理部４０３によって生成され，図８に示すようなボディ部を持つ。

ＳＩＰサーバ１０は，権限判定サーバ２０から権限判定取消応答メッセージＭ１４６を受信し，また鍵生成サーバ４０から鍵生成取消応答メッセージＭ１２３を受信し，処理を終了する。

本シーケンスにおいては，権限判定処理や鍵生成処理が実行されている間にも，ＳＩＰサーバ１０はサービス側通信装置４２からのＳＩＰエラー応答メッセージを受信することができ，さらに当該ＳＩＰエラー応答メッセージをユーザ側通信装置４１へ転送することが可能である。このため，ユーザ側通信装置４１は，サービス側通信装置４２がサービスを提供できない状態にあることを，従来の手順よりも早く知ることができる，という効果がある。

以上が，サービス側通信装置４２がサービスを提供できない状態であった場合のシーケンスとなる。

本実施例においては，従来の手順と比較すると，ＩＮＶＩＴＥメッセージを受信したサービス側通信装置４２が，プロセス起動処理等，サービスの提供に必要な初期処理を，権限判定サーバ２０による権限判定処理や鍵生成サーバ４０による鍵生成処理と並行して実行できる。このため，セッション確立までに要する時間が短縮される，という効果がある。

さらに，本実施例において，セッション確立中に機能提供サーバから与えられる情報の中に，ユーザ側通信装置およびサービス側通信装置へ伝えるべき情報が存在しない場合，ＳＩＰサーバ１０はＵＰＤＡＴＥメッセージＭ１１４を送信する必要がなく，また，サービス側通信装置はＵＰＤＡＴＥメッセージに対する２００ ＯＫメッセージＭ１１５を送信する必要がない。具体的には，鍵生成処理を各通信装置内もしくはＳＩＰサーバ上で行うシステムの場合，本実施例で用いる鍵生成サーバは必要とされず，ユーザ側通信装置およびサービス側通信装置へ伝えるべき情報が存在しない。そのため，ＵＰＤＡＴＥメッセージおよび２００ ＯＫメッセージの送受信処理を省略することが可能となり，より高速なセッション確立を実現することが可能となる。

なお，本実施形態において，それぞれ異なる独立した装置として説明した，機能提供サーバの各々とセッション管理サーバは，任意の二つ以上が一つの装置として実現されていても構わない。機能提供サーバが，セッション管理サーバ装置に含まれる場合は，そのＩＰアドレスは不要となり，複数の機能提供サーバが一つに纏まる場合は，共通のＩＰアドレスと異なるポート番号を備えることになる。

また，本実施例において，権限判定サーバ２０は，ユーザがサービス側通信装置により提供されるサービスを享受するための権限について判定を行っているが，この例の変形として，権限判定サーバ２０ではユーザ側通信装置がサービス側通信装置とセッションを確立するための権限について判定し，当該セッション上で提供されるサービスをユーザが享受するための権限判定については，各サービス側通信装置で行う，といった構成も可能である。

次に，図１５から図２３を参照して，本発明によるデータ通信の第二の実施例について説明する。

第二の実施例では，ユーザの権限判定やセッション鍵の生成を行う機能提供サーバを，Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ（ＡＳ）としてＩＭＳアーキテクチャ上へ配置したシステムにおいて，Ｓ−ＣＳＣＦが，ＩＮＶＩＴＥメッセージの転送と，ＡＳに対する処理要求メッセージの送信を並行して行うことで，セッション確立までに要する時間を短縮する過程を示す。

図１５および図１６に構成を示した，第二の実施例におけるシステムは，ネットワーク０とネットワーク１の二つのネットワーク上で構成される。ネットワーク０とネットワーク１は，ルータ等により接続され，両ネットワーク上に存在する装置は，相互に通信することが可能となっている。ネットワーク０上には，Ｐ−ＣＳＣＦ１１と，Ｉ−ＣＳＣＦ１２と，Ｓ−ＣＳＣＦ１３と，ＨＳＳ２１と，鍵生成を行うアプリケーションサーバである鍵生成ＡＳ３１と，ユーザ側通信装置４１と，が存在する。また，ネットワーク１上には，Ｐ−ＣＳＣＦ１４と，Ｉ−ＣＳＣＦ１５と，Ｓ−ＣＳＣＦ１６と，ユーザ情報の管理を行うＨＳＳ２２と，権限判定を行うアプリケーションサーバである権限判定ＡＳ３２と，サービス側通信装置４２と，が存在する。

Ｐ−ＣＳＣＦ１１は，１９２．１６８．１１．１１というＩＰアドレスが割り当てられている。Ｐ−ＣＳＣＦ１１は，その機能として，例えば，ネットワーク０を介して他のＣＳＣＦならびに通信装置と通信するためのネットワークインタフェースカード部（ＮＩＣ）１１１と，ＳＩＰメッセージを処理するＳＩＰメッセージ処理部１１２と，Ｄｉａｍｅｔｅｒメッセージを処理するＤｉａｍｅｔｅｒメッセージ処理部１１３と，各通信装置からの要求に基づき，ＳＩＰメッセージの転送などを処理するＰ−ＣＳＣＦ処理部１１４と，を含む。

Ｐ−ＣＳＣＦ１４は，１９２．１６８．１４．１１というＩＰアドレスが割り当てられている。Ｐ−ＣＳＣＦ１４の機能構成はＰ−ＣＳＣＦ１１と同様であるため，説明を省略する。

Ｉ−ＣＳＣＦ１２は，１９２．１６８．１２．１１というＩＰアドレスが割り当てられている。Ｉ−ＣＳＣＦ１２は，その機能として，例えば，ネットワーク０を介して他のＣＳＣＦならびに通信装置と通信するためのネットワークインタフェースカード部（ＮＩＣ）１２１と，ＳＩＰメッセージを処理するＳＩＰメッセージ処理部１２２と，Ｄｉａｍｅｔｅｒメッセージを処理するＤｉａｍｅｔｅｒメッセージ処理部１２３と，ネットワーク内のＳ−ＣＳＣＦの検索などを行うＩ−ＣＳＣＦ処理部１２４と，を含む。

Ｉ−ＣＳＣＦ１５は，１９２．１６８．１５．１１というＩＰアドレスが割り当てられている。Ｉ−ＣＳＣＦ１５の機能構成はＩ−ＣＳＣＦ１２と同様であるため，説明を省略する。

Ｓ−ＣＳＣＦ１３は，１９２．１６８．１３．１１というＩＰアドレスが割り当てられている。Ｓ−ＣＳＣＦ１３は，その機能として，例えば，ネットワーク０を介して他のＣＳＣＦならびに通信装置と通信するためのネットワークインタフェースカード部（ＮＩＣ）１３１と，ＳＩＰメッセージを処理するＳＩＰメッセージ処理部１３２と，Ｄｉａｍｅｔｅｒメッセージを処理するＤｉａｍｅｔｅｒメッセージ処理部１３３と，ＡＳなどと連携してセッションの制御を行うＳ−ＣＳＣＦ処理部１３４と，を含む。

Ｓ−ＣＳＣＦ１６は，１９２．１６８．１６．１１というＩＰアドレスが割り当てられている。Ｓ−ＣＳＣＦ１６の機能構成はＳ−ＣＳＣＦ１３と同様であるため，説明を省略する。

ＨＳＳ２１は，１９２．１６８．２１．１１というＩＰアドレスが割り当てられている。ＨＳＳ２１は，その機能として，例えば，ネットワーク０を介して他のサーバならびに通信装置と通信するためのネットワークインタフェースカード部（ＮＩＣ）２１１と，Ｄｉａｍｅｔｅｒメッセージを処理するＤｉａｍｅｔｅｒメッセージ処理部２１２と，ユーザ情報の管理を行うＨＳＳ処理部２１３と，を含む。

ＨＳＳ２２は，１９２．１６８．２２．１１というＩＰアドレスが割り当てられている。ＨＳＳ２２の機能構成はＨＳＳ２１と同様であるため，説明を省略する。

ＨＳＳ２１，ＨＳＳ２２はそれぞれＤｉａｍｅｔｅｒサーバとして働き，各々のＤｉａｍｅｔｅｒメッセージ処理部が，ＤｉａｍｅｔｅｒメッセージＬＩＲ（Ｌｏｃａｔｉｏｎ−Ｉｎｆｏ−Ｒｅｑｕｅｓｔ）を受信し，ＤｉａｍｅｔｅｒメッセージＬＩＡ（Ｌｏｃａｔｉｏｎ−Ｉｎｆｏ−Ａｎｓｗｅｒ）を送信することができる。

鍵生成ＡＳ３１は，１９２．１６８．３１．１１というＩＰアドレスが割り当てられている。鍵生成ＡＳ３１は，例えば，ネットワーク０を介して他のサーバならびに通信装置と通信するためのネットワークインタフェースカード部（ＮＩＣ）３１１と，ＳＩＰメッセージを処理するＳＩＰメッセージ処理部３１２と，処理要求に基づき，ユーザ側通信装置とサービス側通信装置との間の暗号化通信に用いられるセッション鍵の生成処理を行う鍵生成処理部３１３と，を含む。

権限判定ＡＳ３２は，１９２．１６８．３２．１１というＩＰアドレスが割り当てられており，各ユーザがサービス側通信装置が提供するサービスを享受可能か否かについての権限情報を管理する権限ＤＢ８０を備えている。実施例１と同様に，権限ＤＢ８０の管理対象は，サービスを享受するための権限だけでなく，セッションを確立するための権限も含んでいる。権限判定ＡＳ３２は，例えば，ネットワーク０を介して他のサーバならびに通信装置と通信するためのネットワークインタフェースカード部（ＮＩＣ）３２１と，権限判定要求メッセージを処理するメッセージ処理部３２２と，権限ＤＢ８０への処理を制御する権限判定処理部３２３と，を含む。

ユーザ側通信装置４１には，１９２．１６８．４１．１１というＩＰアドレスが割り当てられている。ユーザ側通信装置４１の機能構成は第一の実施例と同様であるため，説明を省略する。

サービス側通信装置４２には，１９２．１６８．４２．１１というＩＰアドレスが割り当てられている。サービス側通信装置４２の機能構成は第一の実施例と同様であるため，説明を省略する。

Ｐ−ＣＳＣＦ１１，１４，Ｉ−ＣＳＣＦ１２，１５，Ｓ−ＣＳＣＦ１３，１６はそれぞれＳＩＰサーバとして働き，各々のＳＩＰメッセージ処理部が，ＳＩＰメッセージであるＩＮＶＩＴＥメッセージ，ＢＹＥメッセージ，ＣＡＮＣＥＬメッセージ，ＵＰＤＡＴＥメッセージや，それに対する応答メッセージ等を送受信する。

また，Ｐ−ＣＳＣＦ１１，１４，Ｉ−ＣＳＣＦ１２，１５，Ｓ−ＣＳＣＦ１３，１６はそれぞれＤｉａｍｅｔｅｒクライアントとして働き，各々のＤｉａｍｅｔｅｒメッセージ処理部が，ＤｉａｍｅｔｅｒプロトコルのＬＩＲメッセージ等を送信することができる。

以下，図１５に示したユーザ側通信装置４１が，図１６に示したサービス側通信装置４２と，ＩＭＳを介したデータ通信を行う場合の通信手順を説明する。

まず，ユーザ側通信装置４１およびサービス側通信装置４２はそれぞれネットワーク０およびネットワーク１上のＰ−ＣＳＣＦに対し，ログインを開始する。当該ログイン処理に関しては，非特許文献２で示されるＩＭＳの仕様で定められた手順に従うため，説明を省略する。

以下，図１７から図２３を用いて，ＩＭＳへのログイン処理が完了したユーザ側通信装置４１が，サービス側通信装置４２とのセッションを確立するまでのシーケンスについて説明する。

ネットワーク０上のＳ−ＣＳＣＦ１３ならびにネットワーク１上のＳ−ＣＳＣＦ１６の処理フローは，第一の実施例におけるＳＩＰサーバ１０の処理フローとほぼ同等である。

初めに，図１７および図１８を用いて，ログイン処理が完了したユーザ側通信装置４１がサービス側通信装置４２にサービスの提供を要求する際のシーケンスを示す。

まず，ユーザ側通信装置４１は，ネットワーク０上のＰ−ＣＳＣＦ１１へＩＮＶＩＴＥメッセージＭ４０１を送信する。

Ｐ−ＣＳＣＦ１１は，ユーザ側通信装置４１からＩＮＶＩＴＥメッセージＭ４０１を受信すると，ＳＩＰメッセージ処理部１１２が，当該ＩＮＶＩＴＥメッセージを元にＩＮＶＩＴＥメッセージＭ４０２を生成し，Ｓ−ＣＳＣＦ１３へ送信する。

Ｓ−ＣＳＣＦ１３は，Ｐ−ＣＳＣＦ１１からＩＮＶＩＴＥメッセージＭ４０２を受信すると，ユーザ側通信装置４１のログイン時にＨＳＳ２１から取得したフィルタクライテリアと，当該ＩＮＶＩＴＥメッセージに含まれるユーザ情報を照らし合わせる（Ｍ４０３）。この結果，本実施例においては，セッション確立に際し鍵生成ＡＳ３１の提供する機能が必要であると判断し，鍵生成ＡＳ３１に対して鍵生成要求メッセージＭ４０４を送信する。鍵生成要求メッセージＭ４０４としては，ＳＩＰメッセージであるＭＥＳＳＡＧＥメッセージを用いる。当該ＭＥＳＳＡＧＥメッセージはＳＩＰメッセージ処理部１３２とＳ−ＣＳＣＦ処理部１３４によって生成される。また当該ＭＥＳＳＡＧＥメッセージのボディ部は，図８に示した鍵生成要求メッセージボディ部Ｍ１０４−１と同様の構造を持つ。

続いてＳ−ＣＳＣＦ１３は，鍵生成ＡＳ３１からの応答を待たずに，ネットワーク１上のＩ−ＣＳＣＦ１５へＩＮＶＩＴＥメッセージＭ４０５を送信する。

なお，Ｓ−ＣＳＣＦ１３は鍵生成要求メッセージＭ４０４，ＩＮＶＩＴＥメッセージＭ４０５の順でメッセージを送信しているが，これら二つのメッセージはこの順序には限定されず，任意の順序で送信することが可能である。

鍵生成ＡＳ３１は，Ｓ−ＣＳＣＦ１３から鍵生成要求メッセージＭ４０４を受信すると，鍵生成処理部３１３が鍵生成処理を開始する（Ｍ４０６）。

これに並行し，ネットワーク１上のＩ−ＣＳＣＦ１５は，Ｓ−ＣＳＣＦ１３からＩＮＶＩＴＥメッセージＭ４０５を受信すると，当該ＩＮＶＩＴＥメッセージの宛先であるサービス側通信装置４２を担当するＳ−ＣＳＣＦのＩＰアドレスを取得するため，Ｄｉａｍｅｔｅｒメッセージ処理部１５３がＤｉａｍｅｔｅｒプロトコルのＬＩＲメッセージＭ４０７を生成し，同じネットワーク１上のＨＳＳ２２へ送信する。

ＨＳＳ２２は，Ｉ−ＣＳＣＦ１５からＬＩＲメッセージＭ４０７を受信すると，当該ＬＩＲメッセージから抽出したサービス側通信装置４２のＩＰアドレスをキーとして内部ＤＢを検索し，サービス側通信装置４２を担当するＳ−ＣＳＣＦ１６のＩＰアドレスを得る。次にＨＳＳ２２は，Ｄｉａｍｅｔｅｒ処理部２２２が，得られたＳ−ＣＳＣＦ１６のＩＰアドレスを含むＬＩＡメッセージＭ４０８を生成し，Ｉ−ＣＳＣＦ１５へ送信する。

Ｉ−ＣＳＣＦ１５は，Ｄｉａｍｅｔｅｒメッセージ処理部１５３が，ＨＳＳ２２から受信したＬＩＡメッセージＭ４０８からＳ−ＣＳＣＦ１６のＩＰアドレスを抽出すると，ＳＩＰメッセージ処理部１５２が，ＩＮＶＩＴＥメッセージＭ４０５を元にＩＮＶＩＴＥメッセージＭ４０９を生成し，Ｓ−ＣＳＣＦ１６のＩＰアドレスへ向けて送信する。

Ｓ−ＣＳＣＦ１６は，Ｉ−ＣＳＣＦ１５からＩＮＶＩＴＥメッセージＭ４０９を受信すると，サービス側通信装置４２のログイン時にＨＳＳ２２から取得したフィルタクライテリアと，当該ＩＮＶＩＴＥメッセージに含まれるサービス情報を照らし合わせる（Ｍ４１０）。この結果，本実施例においては，セッション確立に際し権限判定ＡＳ３２の機能が必要であると判断し，権限判定ＡＳ３２に対して権限判定要求メッセージＭ４１１を送信する。権限判定要求メッセージＭ４１１としては，鍵生成要求メッセージと同様に，ＳＩＰメッセージであるＭＥＳＳＡＧＥメッセージを用いる。当該ＭＥＳＳＡＧＥメッセージはＳＩＰメッセージ処理部１６２とＳ−ＣＳＣＦ処理部１６４によって生成される。また当該ＭＥＳＳＡＧＥメッセージのボディ部は，図８に示した権限判定要求メッセージボディ部Ｍ１０３−１と同様の構造を持つ。

続いてＳ−ＣＳＣＦ１６は，権限判定ＡＳ３２からの返答を待たずに，ネットワーク１上のＰ−ＣＳＣＦ１４へＩＮＶＩＴＥメッセージＭ４１２を送信する。

なお，Ｓ−ＣＳＣＦ１６は権限判定要求メッセージＭ４１１，ＩＮＶＩＴＥメッセージＭ４１２の順でメッセージを送信しているが，これら二つのメッセージはこの順序には限定されず，任意の順序で送信することが可能である。

権限判定ＡＳ３２は，Ｓ−ＣＳＣＦ１６から権限判定要求メッセージＭ４１１を受信すると，権限判定処理部３２３が権限ＤＢ８０に権限情報の問い合わせを行う（Ｍ４１３）。

これに並行し，ネットワーク１上のＰ−ＣＳＣＦ１４は，Ｓ−ＣＳＣＦ１６からＩＮＶＩＴＥメッセージＭ４１２を受け取ると，ＳＩＰメッセージ処理部１４２が，当該ＩＮＶＩＴＥメッセージを元にＩＮＶＩＴＥメッセージＭ４１４を生成し，同じネットワーク１上のサービス側通信装置４２へ送信する。

ＩＮＶＩＴＥメッセージＭ４１４を受信したサービス側通信装置４２は，サーバ処理部４２３が，サービスの提供に当たって必要となる初期化処理（プロセスの起動等）を開始する（Ｍ４１５）。初期化処理が完了すると，サービス側通信装置４２は，Ｐ−ＣＳＣＦ１４へ２００ ＯＫメッセージＭ４１６を送信する。

サービス側通信装置４２から２００ ＯＫメッセージＭ４１６を受信したＰ−ＣＳＣＦ１４は，ＳＩＰメッセージ処理部１４２が，当該２００ ＯＫメッセージを元に２００ ＯＫメッセージＭ４１７を生成し，Ｓ−ＣＳＣＦ１６へ送信する。

Ｓ−ＣＳＣＦ１６は，Ｐ−ＣＳＣＦ１４から２００ ＯＫメッセージＭ４１７を受信すると，ＳＩＰメッセージ処理部１６２が，当該２００ ＯＫメッセージに対するＡＣＫメッセージＭ４１８を生成し，Ｐ−ＣＳＣＦ１４へ送信する。

Ｐ−ＣＳＣＦ１４は，Ｓ−ＣＳＣＦ１６からＡＣＫメッセージＭ４１８を受信すると，ＳＩＰメッセージ処理部１４２が，当該ＡＣＫメッセージを元にＡＣＫメッセージＭ４１９を生成し，サービス側通信装置４２へ送信する。

権限判定処理Ｍ４１３を行っていた権限判定ＡＳ３２は，当該権限判定処理を終え，ユーザ側通信装置４１がサービス側通信装置４２のサービスを享受するための権限を持つことを確認すると，Ｓ−ＣＳＣＦ１６へ権限判定結果［許可］メッセージＭ４２０を送信する。権限判定結果［許可］メッセージＭ４２０としては，ＳＩＰメッセージである２００ ＯＫメッセージを用いる。当該２００ ＯＫメッセージはＳＩＰメッセージ処理部３２２と権限判定処理部３２３によって生成される。また当該２００ ＯＫメッセージのボディ部は，図８に示した権限判定結果［許可］メッセージボディ部Ｍ１１２−１と同様の構造を持つ。

Ｓ−ＣＳＣＦ１６は，サービス側通信装置４２，権限判定ＡＳ３２の両者からメッセージを受信すると，ＳＩＰメッセージ処理部１６２が，ＩＮＶＩＴＥメッセージＭ４０９に対する２００ ＯＫメッセージＭ４１７のヘッダ部から自ＵＲＩを含むＶｉａヘッダを除去することで，ＩＮＶＩＴＥメッセージＭ４０９に対する２００ ＯＫメッセージＭ４２１を生成し，Ｉ−ＣＳＣＦ１５へ送信する。

Ｉ−ＣＳＣＦ１５は，Ｓ−ＣＳＣＦ１６から２００ ＯＫメッセージＭ４２１を受信すると，当該２００ ＯＫメッセージを元に２００ ＯＫメッセージＭ４２２を生成し，ネットワーク０上のＳ−ＣＳＣＦ１３へ送信する。

Ｓ−ＣＳＣＦ１３は，Ｉ−ＣＳＣＦ１５から２００ ＯＫメッセージＭ４２２を受信すると，ＳＩＰメッセージ処理部１３２が，当該２００ ＯＫメッセージに対するＡＣＫメッセージＭ４２３を生成し，Ｓ−ＣＳＣＦ１６へ送信する。

鍵生成処理Ｍ４０６を行っていた鍵生成ＡＳ３１は，当該鍵生成処理を完了すると，Ｓ−ＣＳＣＦ１３へ鍵生成結果メッセージＭ４２４を送信する。鍵生成結果メッセージＭ４２４としては，ＳＩＰメッセージである２００ ＯＫメッセージを用いる。当該２００ ＯＫメッセージはＳＩＰメッセージ処理部３１２と鍵生成処理部３１３によって生成される。また当該２００ ＯＫメッセージのボディ部は，図８に示した鍵生成結果メッセージボディ部Ｍ１１３−１と同様の構造を持つ。

Ｓ−ＣＳＣＦ１３は，サービス側通信装置４２，鍵生成ＡＳ３１の両者からメッセージを受信すると，ネットワーク１上のＳ−ＣＳＣＦ１６へＳＩＰメッセージであるＵＰＤＡＴＥメッセージＭ４２５を送信する。ＵＰＤＡＴＥメッセージＭ４２５はＳＩＰメッセージ処理部１３２およびＳ−ＣＳＣＦ処理部１３４によって生成される。当該ＵＰＤＡＴＥメッセージのボディ部には，鍵生成結果メッセージＭ４２４によって運ばれたセッション鍵情報が含まれる。

Ｓ−ＣＳＣＦ１６は，Ｓ−ＣＳＣＦ１３からＵＰＤＡＴＥメッセージＭ４２５を受信すると，ＳＩＰメッセージ処理部１６２が，当該ＵＰＤＡＴＥメッセージを元にＵＰＤＡＴＥメッセージＭ４２６を生成し，Ｐ−ＣＳＣＦ１４へ転送する。

Ｐ−ＣＳＣＦ１４は，Ｓ−ＣＳＣＦ１６からＵＰＤＡＴＥメッセージＭ４２６を受信すると，ＳＩＰメッセージ処理部１４２が，当該ＵＰＤＡＴＥメッセージを元にＵＰＤＡＴＥメッセージＭ４２７を生成し，サービス側通信装置４２へ転送する。

サービス側通信装置４２は，Ｐ−ＣＳＣＦ１４からＵＰＤＡＴＥメッセージＭ４２７を受信すると，ＳＩＰメッセージ処理部４２２が，当該ＵＰＤＡＴＥメッセージのボディ部に含まれるセッション鍵情報を取得した後，当該ＵＰＤＡＴＥメッセージに対する２００ ＯＫメッセージＭ４２８を生成する。次に当該２００ ＯＫメッセージをＰ−ＣＳＣＦ１４へ送信し，ユーザ側通信装置４１へサービスの提供が可能な状態へ遷移する。

Ｐ−ＣＳＣＦ１４は，サービス側通信装置４２から２００ ＯＫメッセージＭ４２８を受信すると，ＳＩＰメッセージ処理部１４２が，当該２００ ＯＫメッセージを元に２００ ＯＫメッセージＭ４２９を生成し，Ｓ−ＣＳＣＦ１６へ送信する。

Ｓ−ＣＳＣＦ１６は，Ｐ−ＣＳＣＦ１４から２００ ＯＫメッセージＭ４２９を受信すると，ＳＩＰメッセージ処理部１６２が，当該２００ ＯＫメッセージを元に２００ ＯＫメッセージＭ４３０を生成し，ネットワーク０上のＳ−ＣＳＣＦ１３へ送信する。

Ｓ−ＣＳＣＦ１３は，Ｓ−ＣＳＣＦ１６から２００ ＯＫメッセージＭ４３０を受信すると，ＳＩＰメッセージ処理部１３２が，Ｐ−ＣＳＣＦ１１から受信していたＩＮＶＩＴＥメッセージＭ４０２のヘッダ部から，自ＵＲＩを含むＶｉａヘッダを除去することで２００ ＯＫメッセージＭ４３１のヘッダ部を生成する。また，鍵生成ＡＳ３１から受信した鍵情報結果メッセージのボディ部に含まれるセッション鍵情報から，２００ ＯＫメッセージＭ４３１のボディ部を生成し，ヘッダ部と結合することで２００ ＯＫメッセージＭ４３１を生成し，Ｐ−ＣＳＣＦ１１へ送信する。

Ｐ−ＣＳＣＦ１１は，Ｓ−ＣＳＣＦ１３から２００ ＯＫメッセージＭ４３１を受信すると，ＳＩＰメッセージ処理部１１２が，当該２００ ＯＫメッセージを元に２００ ＯＫメッセージＭ４３２を生成し，ユーザ側通信装置４１へ送信する。

ユーザ側通信装置４１は，Ｐ−ＣＳＣＦ１１から２００ ＯＫメッセージＭ４３２を受信すると，ＳＩＰメッセージ処理部４１２が，当該２００ ＯＫメッセージのボディ部に含まれるセッション鍵情報を取得した後，当該２００ ＯＫメッセージへの応答として，Ｐ−ＣＳＣＦ１１へＡＣＫメッセージＭ４３３を送信する。

Ｐ−ＣＳＣＦ１１は，ユーザ側通信装置４１からＡＣＫメッセージＭ４３３を受信すると，ＳＩＰメッセージ処理部１１２が，当該ＡＣＫメッセージを元にＡＣＫメッセージＭ４３４を生成し，Ｓ−ＣＳＣＦ１３へ送信する。

Ｓ−ＣＳＣＦ１３は，Ｐ−ＣＳＣＦ１１からＡＣＫメッセージＭ４３４を受信し，処理を終了する。

以上の手順によって，ユーザ側通信装置４１とサービス側通信装置４２との間に通信セッションが確立され，ユーザ側通信装置４１からサービス側通信装置４２へのアクセスと，サービス側通信装置４２からユーザ側通信装置４１への情報サービスが可能となる（Ｍ４３５）。ユーザ側通信装置４１とサービス側通信装置４２との間の通信は，セッション確立中に得られたセッション鍵情報を用いて暗号化される。

本実施例においては，鍵生成ＡＳ３１による鍵生成処理Ｍ４０６，権限判定ＡＳ３２による権限判定処理Ｍ４１３，サービス側通信装置４２によるプロセス起動処理等Ｍ４１５が並行して行われる。このため，それぞれの処理を一つ一つ順に行う手順と比較して，通信開始までに要する時間が短縮される，という効果がある。

ユーザ側通信装置４１がサービス側通信装置４２へセッションの切断を要求する場合のシーケンスについては，ＩＭＳの仕様で定められた手順に従うため，説明を省略する。

次に図１９および図２０を用いて，ユーザ側通信装置４１がサービス側通信装置４２のサービスを享受するための権限を持たない場合で，かつサービス側通信装置４２からの２００ＯＫメッセージが権限判定の結果よりも先に通知された場合のシーケンスについて説明する。

ユーザ側通信装置４１がＰ−ＣＳＣＦ１１へＩＮＶＩＴＥメッセージＭ４０１を送信してから，Ｐ−ＣＳＣＦ１４がサービス側通信装置４２へＡＣＫメッセージＭ４１９を送信するまでのシーケンスについては，図１７および図１８で示したシーケンスと同様である。

この後，権限判定ＡＳ３２は，権限判定処理の結果，ユーザ側通信装置４１がサービス側通信装置４２のサービスを享受するための権限を持たないことを確認すると，Ｓ−ＣＳＣＦ１６へ権限判定結果［拒否］メッセージＭ４４１を送信する。権限判定［拒否］メッセージＭ４４１としてはＳＩＰメッセージである４０３ Ｆｏｒｂｉｄｄｅｎメッセージを用いる。当該４０３ ＦｏｒｂｉｄｄｅｎメッセージはＳＩＰメッセージ処理部３２２および権限判定処理部３２３によって生成される。また当該４０３ Ｆｏｒｂｉｄｄｅｎメッセージのボディ部は，図６に示した権限判定［拒否］メッセージボディ部Ｍ１２１−１と同様の構造を持つ。

Ｓ−ＣＳＣＦ１６は，権限判定結果［拒否］メッセージＭ４４１を受信すると，ＳＩＰメッセージ処理部１６２が，ＩＮＶＩＴＥメッセージＭ４０９に対する４０３ ＦｏｒｂｉｄｄｅｎメッセージＭ４４２を生成し，Ｉ−ＣＳＣＦ１５へ送信する。

また，Ｓ−ＣＳＣＦ１６は，ＳＩＰメッセージ処理部１６２が，ＢＹＥメッセージＭ４４３を生成し，Ｐ−ＣＳＣＦ１４へ送信する。

Ｐ−ＣＳＣＦ１４は，Ｓ−ＣＳＣＦ１６からＢＹＥメッセージＭ４４３を受信すると，ＳＩＰメッセージ処理部１４２が，当該ＢＹＥメッセージを元にＢＹＥメッセージＭ４４４を生成し，サービス側通信装置４２へ送信する。

サービス側通信装置４２は，Ｐ−ＣＳＣＦ１４からＢＹＥメッセージＭ４４４を受信すると，ＳＩＰメッセージ処理部４２２が，当該ＢＹＥメッセージに対する応答として２００ ＯＫメッセージＭ４４５を生成し，Ｐ−ＣＳＣＦ１４へ送信する。

Ｐ−ＣＳＣＦ１４は，サービス側通信装置４２から２００ ＯＫメッセージＭ４４５を受信すると，ＳＩＰメッセージ処理部１４２が，当該２００ ＯＫメッセージを元に２００ ＯＫメッセージＭ４４６を生成し，Ｓ−ＣＳＣＦ１６へ送信する。

図２０において，Ｉ−ＣＳＣＦ１５は，Ｓ−ＣＳＣＦ１６から４０３ ＦｏｒｂｉｄｄｅｎメッセージＭ４４２を受信すると，ＳＩＰメッセージ処理部１５２が，当該４０３ Ｆｏｒｂｉｄｄｅｎメッセージを元に４０３ ＦｏｒｂｉｄｄｅｎメッセージＭ４４７を生成し，ネットワーク０上のＳ−ＣＳＣＦ１３へ送信する。

Ｓ−ＣＳＣＦ１３は，Ｉ−ＣＳＣＦ１５から４０３ ＦｏｒｂｉｄｄｅｎメッセージＭ４４７を受信すると，ＳＩＰメッセージ処理部１３２が，当該４０３ Ｆｏｒｂｉｄｄｅｎメッセージに対する応答となるＡＣＫメッセージＭ４４８を生成し，ネットワーク１上のＳ−ＣＳＣＦ１６へ送信する。

また，Ｓ−ＣＳＣＦ１３は，Ｉ−ＣＳＣＦ１５から受信した４０３ ＦｏｒｂｉｄｄｅｎメッセージＭ４４７を元に，ＳＩＰメッセージ処理部１３２が，４０３ ＦｏｒｂｉｄｄｅｎメッセージＭ４４９を生成し，Ｐ−ＣＳＣＦ１１へ送信する。

Ｐ−ＣＳＣＦ１１は，Ｓ−ＣＳＣＦ１３から４０３ ＦｏｒｂｉｄｄｅｎメッセージＭ４４９を受信すると，ＳＩＰメッセージ処理部１１２が，当該４０３ Ｆｏｒｂｉｄｄｅｎメッセージを元に４０３ ＦｏｒｂｉｄｄｅｎメッセージＭ４５０を生成し，ユーザ側通信装置４１へ送信する。

ユーザ側通信装置４１は，Ｐ−ＣＳＣＦ１１から４０３ ＦｏｒｂｉｄｄｅｎメッセージＭ４５０を受信すると，ＳＩＰメッセージ処理部４１２が，当該４０３ Ｆｏｒｂｉｄｄｅｎメッセージに対する応答となるＡＣＫメッセージＭ４５１を生成し，Ｐ−ＣＳＣＦ１１へ送信する。

Ｐ−ＣＳＣＦ１１は，ユーザ側通信装置４１からＡＣＫメッセージＭ４５１を受信すると，ＳＩＰメッセージ処理部１１２が，当該ＡＣＫメッセージを元にＡＣＫメッセージＭ４５２を生成し，Ｓ−ＣＳＣＦ１３へ送信する。

また，Ｓ−ＣＳＣＦ１３は，鍵生成ＡＳ３１へ鍵生成取消メッセージＭ４５３を送信する。鍵生成取消メッセージＭ４５３としては，ＳＩＰメッセージであるＭＥＳＳＡＧＥメッセージを用いる。当該ＭＥＳＳＡＧＥメッセージはＳＩＰメッセージ処理部１３２によって生成される。また当該ＭＥＳＳＡＧＥメッセージのボディ部は，図８に示した鍵生成取消メッセージボディ部Ｍ１２４−１と同様の構造を持つ。

鍵生成ＡＳ３１は，Ｓ−ＣＳＣＦ１３から鍵生成取消メッセージＭ４５３を受信すると，鍵生成処理部３１３が，処理中であった鍵生成処理を終了する。続いて，ＳＩＰメッセージ処理部１３２が，鍵生成取消応答メッセージＭ４５４を生成し，Ｓ−ＣＳＣＦ１３へ送信する。鍵生成取消応答メッセージＭ４５４としてはＳＩＰメッセージである２００ ＯＫメッセージを用いる。また当該２００ ＯＫメッセージのボディ部は，図８に示した鍵生成取消応答メッセージボディ部Ｍ１２５−１と同様の構造を持つ。

次に図２１を用いて，ユーザ側通信装置４１がサービス側通信装置４２のサービスを享受するための権限を持たない場合で，かつサービス側通信装置４２からの２００ ＯＫメッセージよりも先に権限判定の結果が通知された場合のシーケンスについて説明する。

ユーザ側通信装置４１がＰ−ＣＳＣＦ１１へＩＮＶＩＴＥメッセージＭ４０１を送信してから，サービス側通信装置４２がプロセス起動処理等Ｍ４１５の実行を開始するまでのシーケンスについては，図１７および図１８で示したシーケンスと同様である。

この後，権限判定ＡＳ３２は，権限判定処理の結果，ユーザ側通信装置４１がサービス側通信装置４２のサービスを享受するための権限を持たないことを確認すると，Ｓ−ＣＳＣＦ１６へ権限判定結果［拒否］メッセージＭ４４１を，サービス側通信装置４２が２００ ＯＫメッセージを送信するよりも先に，送信する。権限判定結果［拒否］メッセージＭ４４１は，図１９で示したシーケンス中の権限判定結果［拒否］メッセージＭ４４１と同一のメッセージである。

Ｓ−ＣＳＣＦ１６は，権限判定ＡＳ３２から権限判定結果［拒否］メッセージＭ４４１を受信すると，ＳＩＰメッセージ処理部１６２が，ＩＮＶＩＴＥメッセージＭ４０９に対する４０３ ＦｏｒｂｉｄｄｅｎメッセージＭ４４２を生成し，Ｉ−ＣＳＣＦ１５へ送信する。

また，Ｓ−ＣＳＣＦ１６は，ＳＩＰメッセージ処理部１６２が，ＣＡＮＣＥＬメッセージＭ４６１を生成し，Ｐ−ＣＳＣＦ１４へ送信する。

この後，４０３ ＦｏｒｂｉｄｄｅｎメッセージＭ４４２を受信したＩ−ＣＳＣＦ１５と，ネットワーク０内の各装置と，で行われるシーケンスについては，図２０で示したシーケンスと同一であるため，説明を省略する。

Ｐ−ＣＳＣＦ１４は，Ｓ−ＣＳＣＦ１６からＣＡＮＣＥＬメッセージＭ４６１を受信すると，ＳＩＰメッセージ処理部１４２が，当該ＣＡＮＣＥＬメッセージを元に，ＣＡＮＣＥＬメッセージＭ４６２を生成し，サービス側通信装置４２へ送信する。

また，Ｐ−ＣＳＣＦ１４は，ＳＩＰメッセージ処理部１４２が，ＣＡＮＣＥＬメッセージＭ４６１に対する応答メッセージである２００ ＯＫメッセージＭ４６３を生成し，Ｓ−ＣＳＣＦ１６へ送信する。

サービス側通信装置４２は，Ｐ−ＣＳＣＦ１４からＣＡＮＣＥＬメッセージＭ４６２を受信すると，ＳＩＰメッセージ処理部４２２が，当該ＣＡＮＣＥＬメッセージに対する応答として２００ ＯＫメッセージＭ４６４を生成し，Ｐ−ＣＳＣＦ１４へ送信する。

続いて，サービス側通信装置４２は，ＳＩＰメッセージ処理部４２２が，ＳＩＰ最終応答メッセージである４８７ Ｒｅｑｕｅｓｔ Ｔｅｒｍｉｎａｔｅｄメッセージを生成し，Ｐ−ＣＳＣＦ１４へ送信する。

Ｐ−ＣＳＣＦ１４は，サービス側通信装置４２から４８７ Ｒｅｑｕｅｓｔ Ｔｅｒｍｉｎａｔｅｄメッセージを受信すると，ＳＩＰメッセージ処理部１４２が，当該４８７ Ｒｅｑｕｅｓｔ Ｔｅｒｍｉｎａｔｅｄメッセージを元に，４８７ Ｒｅｑｕｅｓｔ ＴｅｒｍｉｎａｔｅｄメッセージＭ４６６を生成し，Ｓ−ＣＳＣＦ１６へ送信する。

Ｓ−ＣＳＣＦ１６は，Ｐ−ＣＳＣＦ１４から４８７ Ｒｅｑｕｅｓｔ ＴｅｒｍｉｎａｔｅｄメッセージＭ４６６を受信すると，ＳＩＰメッセージ処理部１６２が，当該４８７ Ｒｅｑｕｅｓｔ Ｔｅｒｍｉｎａｔｅｄメッセージに対する応答となるＡＣＫメッセージＭ４６７を生成し，Ｐ−ＣＳＣＦ１４へ送信する。

Ｐ−ＣＳＣＦ１４は，Ｓ−ＣＳＣＦ１６からＡＣＫメッセージＭ４６７を受信すると，ＳＩＰメッセージ処理部１４２が，当該ＡＣＫメッセージを元に，ＡＣＫメッセージ４６８を生成し，サービス側通信装置４２へ送信する。

次に図２２および図２３を用いて，サービス側通信装置４２がサービスを提供できない状態であった場合のシーケンスについて説明する。

ユーザ側通信装置４１がＰ−ＣＳＣＦ１１へＩＮＶＩＴＥメッセージＭ４０１を送信してから，Ｐ−ＣＳＣＦ１４がサービス側通信装置４２へＩＮＶＩＴＥメッセージＭ４１４を送信するまでのシーケンスについては，図１７および図１８で示したシーケンスと同様である。

続いてサービス側通信装置４２が，何らかの理由でサービスを提供できない状態であることを伝えるために，Ｐ−ＣＳＣＦ１４へＳＩＰエラー応答メッセージＭ４７１を送信する。例えば，サービス側通信装置４２はＳＩＰメッセージである４８６Ｂｕｓｙ Ｈｅｒｅメッセージを送信することで，サービス側通信装置４２が既に他のユーザ側通信装置と多数のセッションを確立しており，これ以上新しいセッションを確立することができない状況にあることを通知することができる。

Ｐ−ＣＳＣＦ１４は，サービス側通信装置４２からＳＩＰエラー応答メッセージＭ４７１を受信すると，ＳＩＰメッセージ処理部１４２が，当該ＳＩＰエラー応答メッセージを元にＳＩＰエラー応答メッセージＭ４７２を生成し，Ｓ−ＣＳＣＦ１６へ送信する。

Ｓ−ＣＳＣＦ１６は，Ｐ−ＣＳＣＦ１４からＳＩＰエラー応答メッセージＭ４７２を受信すると，ＳＩＰメッセージ処理部１６２が，当該ＳＩＰエラー応答メッセージに対する応答となるＡＣＫメッセージＭ４７３を生成し，Ｐ−ＣＳＣＦ１４へ送信する。

Ｐ−ＣＳＣＦ１４は，Ｓ−ＣＳＣＦ１６からＡＣＫメッセージＭ４７３を受信すると，ＳＩＰメッセージ処理部１４２が，当該ＡＣＫメッセージを元にＡＣＫメッセージＭ４７４を生成し，サービス側通信装置４２へ送信する。

次に，Ｓ−ＣＳＣＦ１６は，ＳＩＰメッセージ処理部１６２が，受信したＳＩＰエラー応答メッセージＭ４７２を元にＳＩＰエラー応答メッセージＭ４７５を生成し，Ｉ−ＣＳＣＦ１５へ送信する。

次に，Ｓ−ＣＳＣＦ１６は，権限判定ＡＳ３２へ権限判定取消メッセージＭ４７６を送信する。権限判定取消メッセージＭ４７６としては，ＳＩＰメッセージであるＭＥＳＳＡＧＥメッセージを用いる。当該ＭＥＳＳＡＧＥメッセージはＳＩＰメッセージ処理部１６２によって生成される。また当該ＭＥＳＳＡＧＥメッセージのボディ部は，図８に示した権限判定取消メッセージボディ部Ｍ１４５−１と同様の構造を持つ。

権限判定ＡＳ３２は，Ｓ−ＣＳＣＦ１６から権限判定取消メッセージＭ４７６を受信すると，権限判定処理部３２３が，処理中であった権限判定処理を終了する。続いて，ＳＩＰメッセージ処理部３２２が，権限判定取消応答メッセージＭ４７７を生成し，Ｓ−ＣＳＣＦ１６へ送信する。権限判定取消応答メッセージＭ４７７としてはＳＩＰメッセージである２００ ＯＫメッセージを用いる。また当該２００ ＯＫメッセージのボディ部は，図８に示した権限判定取消応答メッセージボディ部Ｍ１４６−１と同様の構造を持つ。

一方，Ｉ−ＣＳＣＦ１５は，Ｓ−ＣＳＣＦ１６から受信したＳＩＰエラー応答メッセージＭ４７５を元にＳＩＰエラー応答メッセージＭ４７８を生成し，ネットワーク０上のＳ−ＣＳＣＦ１３へ送信する。

Ｓ−ＣＳＣＦ１３は，ネットワーク１上のＩ−ＣＳＣＦ１５からＳＩＰエラー応答メッセージＭ４７８を受信すると，ＳＩＰメッセージ処理部１３２が，当該ＳＩＰエラー応答メッセージに対する応答となるＡＣＫメッセージＭ４７９を生成し，ネットワーク１上のＳ−ＣＳＣＦ１６へ送信する。

次に，Ｓ−ＣＳＣＦ１３は，ＳＩＰメッセージ処理部１３２が，ＳＩＰエラー応答メッセージＭ４７８を元にＳＩＰエラー応答メッセージＭ４８０を生成し，Ｐ−ＣＳＣＦ１１へ送信する。

次に，Ｓ−ＣＳＣＦ１３は，鍵生成ＡＳ３１へ鍵生成取消メッセージＭ４８１を送信する。鍵生成取消メッセージＭ４８１としては，ＳＩＰメッセージであるＭＥＳＳＡＧＥメッセージを用いる。当該ＭＥＳＳＡＧＥメッセージはＳＩＰメッセージ処理部１３２によって生成される。また当該ＭＥＳＳＡＧＥメッセージのボディ部は，図８に示した鍵生成取消メッセージボディ部Ｍ１２４−１と同様の構造を持つ。

鍵生成ＡＳ３１は，Ｓ−ＣＳＣＦ１３から鍵生成取消メッセージＭ４８１を受信すると，鍵生成処理部３１３が，処理中であった鍵生成処理を終了する。続いて，ＳＩＰメッセージ処理部３１２が，鍵生成取消応答メッセージＭ４８２を生成し，Ｓ−ＣＳＣＦ１３へ送信する。鍵生成取消応答メッセージＭ４８２としては，ＳＩＰメッセージである２００ ＯＫメッセージを用いる。また当該２００ ＯＫメッセージのボディ部は，図８に示した鍵生成取消応答メッセージボディ部Ｍ１２５−１と同様の構造を持つ。

一方，Ｐ−ＣＳＣＦ１１は，Ｓ−ＣＳＣＦ１３からＳＩＰエラー応答メッセージＭ４８０を受信すると，ＳＩＰメッセージ処理部１１２が，当該ＳＩＰエラー応答メッセージを元にＳＩＰエラー応答メッセージＭ４８３を生成し，ユーザ側通信装置４１へ送信する。

ユーザ側通信装置４１は，Ｐ−ＣＳＣＦ１１からＳＩＰエラー応答メッセージＭ４８３を受信すると，ＳＩＰメッセージ処理部４１２が，当該ＳＩＰエラー応答メッセージに対する応答となるＡＣＫメッセージＭ４８４を生成し，Ｐ−ＣＳＣＦ１１へ送信する。

Ｐ−ＣＳＣＦ１１は，ユーザ側通信装置４１からＡＣＫメッセージＭ４８４を受信すると，ＳＩＰメッセージ処理部１１２が，当該ＡＣＫメッセージを元にＡＣＫメッセージＭ４８５を生成し，Ｓ−ＣＳＣＦ１３へ送信する。

本実施例では，権限判定処理や鍵生成処理が実行されている間にも，Ｓ−ＣＳＣＦ１６およびＳ−ＣＳＣＦ１３は，Ｐ−ＣＳＣＦやＩ−ＣＳＣＦによって転送されたサービス側通信装置４２からのＳＩＰエラー応答メッセージを受信することができる。当該ＳＩＰエラー応答メッセージはＰ−ＣＳＣＦ１１を経由し，ユーザ側通信装置４１の元へ届けられる。このため，ユーザ側通信装置４１は，サービス側通信装置４２がサービスを提供できない状態にあることを，従来の手順よりも早く知ることができる，という効果がある。

また，本実施例において，権限判定ＡＳ３２は，ユーザがサービス側通信装置により提供されるサービスを享受するための権限について判定を行っているが，この例の変形として，権限判定ＡＳ３２ではユーザ側通信装置がサービス側通信装置とセッションを確立するための権限について判定し，当該セッション上で提供されるサービスをユーザが享受するための権限判定については，各サービス側通信装置で行う，といった構成も可能である。

第一の実施例におけるシステム構成を示した図 第一，第二の実施例で用いる各装置のハードウェア構成を例示するブロック図 第一の実施例においてユーザ側通信装置４１およびサービス側通信装置４２がＳＩＰサーバ１０へのログイン処理を行う際のシーケンスを例示する図 第一の実施例においてユーザ側通信装置４１およびサービス側通信装置４２がログインした後の，ＳＩＰサーバ１０の処理フローを例示する図 第一の実施例においてユーザ側通信装置４１およびサービス側通信装置４２がログインした後の，ＳＩＰサーバ１０の処理フローを例示する図 第一の実施例においてユーザ側通信装置４１およびサービス側通信装置４２がログインした後の，ＳＩＰサーバ１０の処理フローを例示する図 第一の実施例におけるセッションログＤＢ７０，権限ＤＢ８０，アプリケーションログＤＢ５０に保存される情報を例示する図 第一の実施例においてＳＩＰサーバ１０が，権限判定サーバ２０，鍵生成サーバ４０，サービス側通信装置４２との間で送受信するメッセージを例示する図 第一の実施例において課金サーバ３０が受信するメッセージを例示する図 第一の実施例においてユーザ側通信装置４１がサービス側通信装置４２からサービスの提供を受ける場合のシーケンスを例示する図 第一の実施例においてユーザ側通信装置４１がサービス側通信装置４２とのセッションを切断する場合のシーケンスを例示する図 第一の実施例においてサービス側通信装置４２がユーザ側通信装置４１へのサービス提供を拒否する場合のシーケンスを例示する図 第一の実施例においてサービス側通信装置４２がユーザ側通信装置４１へサービスを提供できない場合のシーケンスを例示する図 第一の実施例においてサービス側通信装置４２がユーザ側通信装置４１へサービスを提供できない場合のシーケンスを例示する図 第二の実施例におけるシステム構成を示した図 第二の実施例におけるシステム構成を示した図 第二の実施例においてサービス側通信装置４２がユーザ側通信装置４１へサービスを提供する場合のシーケンスを例示する図 第二の実施例においてサービス側通信装置４２がユーザ側通信装置４１へサービスを提供する場合のシーケンスを例示する図 第二の実施例においてサービス側通信装置４２がユーザ側通信装置４１へのサービス提供を拒否する場合のシーケンスを例示する図 第二の実施例においてサービス側通信装置４２がユーザ側通信装置４１へのサービス提供を拒否する場合のシーケンスを例示する図 第二の実施例においてサービス側通信装置４２がユーザ側通信装置４１へのサービス提供を拒否する場合のシーケンスを例示する図 第二の実施例においてサービス側通信装置４２がユーザ側通信装置４１へサービスを提供できない場合のシーケンスを例示する図 第二の実施例においてサービス側通信装置４２がユーザ側通信装置４１へサービスを提供できない場合のシーケンスを例示する図

符号の説明

０，１：ネットワーク，１０：ＳＩＰサーバ，１１，１４：Ｐ−ＣＳＣＦ，１２，１５：Ｉ−ＣＳＣＦ，１３，１６：Ｓ−ＣＳＣＦ，２０：権限判定サーバ，２１，２２：ＨＳＳ，３０：課金サーバ，３１：鍵生成ＡＳ，３２：権限判定ＡＳ，４０：鍵生成サーバ，４１：ユーザ側通信装置，４２：サービス側通信装置，５０：アプリケーションログＤＢ，６０：レジストラＤＢ，７０：セッションログＤＢ，８０：権限ＤＢ，９１：ＣＰＵ，９２：メモリ，９３：ハードディスク，９４：ネットワークインタフェース，９５：入出力装置

Claims (11)

1. 通信装置１と，通信装置２と，前記複数の通信装置がデータ通信を行うためのセッションを管理するセッション管理サーバと，前記セッション確立に必要な機能を提供する機能提供サーバと，を含むデータ通信システムであって，
   前記セッション管理サーバは，
   前記通信装置１を通信元とする，前記通信装置２とのセッション確立を要求する要求メッセージを受信した場合に，前記要求メッセージを転送して応答を待つ処理と，前記セッション確立に必要な処理を機能提供サーバへ依頼して応答を待つ処理と，を並行して行う
   ことを特徴とするデータ通信システム。
2. 請求項１に記載のデータ通信システムであって，
   前記機能提供サーバへ依頼する処理は，前記通信装置１が，確立する前記セッションを利用して，前記通信装置２が提供するサービスを享受するために必要な権限を有するか否かを判定する処理を含む
   ことを特徴とするデータ通信システム。
3. 請求項１に記載のデータ通信システムであって，
   前記機能提供サーバへ依頼する処理は，前記通信装置１と前記通信装置２との前記セッションを利用して行われる通信の暗号化に必要な暗号鍵の生成処理を含む
   ことを特徴とするデータ通信システム。
4. 請求項１に記載のデータ通信システムであって，
   前記セッション管理サーバは，
   前記通信装置２から，送信した前記要求メッセージに対する応答メッセージを受信する前に，前記機能提供サーバから，前記通信装置２から前記通信装置１へのサービスの提供を拒否するメッセージを受信した場合には，
   前記通信装置２へ送信した前記セッション確立要求のキャンセルメッセージ，および／または，まだ結果を受信していない前記機能提供サーバへ依頼した処理の取消メッセージを，送信する
   ことを特徴とするデータ通信システム。
5. 請求項１に記載のデータ通信システムであって，
   前記セッション管理サーバは，
   前記通信装置２から，転送した前記要求メッセージに対する，サービス提供可能メッセージを受信した場合は，前記サービス提供可能メッセージに対する応答メッセージを前記通信装置２へ送信し，当該応答メッセージの送信後に，まだ結果を受信していない前記機能提供サーバへ依頼した処理に対する結果を待ち受ける
   ことを特徴とするデータ通信システム。
6. 請求項１に記載のデータ通信システムであって，
   前記セッション管理サーバは，
   前記機能提供サーバから，前記依頼した処理に対する前記結果として，前記通信装置２から前記通信装置１へのサービス提供を許可するメッセージを受信した場合は，前記サービス提供を許可するメッセージに対する応答メッセージを前記機能提供サーバへ送信し，当該応答メッセージの送信後に，前記機能提供サーバへ依頼した処理，および／または，前記通信装置２へ送信した前記要求メッセージに対する結果，を待ち受ける
   ことを特徴とするデータ通信システム。
7. 請求項６に記載のデータ通信システムであって，
   前記セッション管理サーバは，
   前記通信装置２および処理を依頼した全ての前記機能提供サーバから応答を受信した場合に，前記機能提供サーバから受信したメッセージに含まれていた情報を，前記通信装置２および前記通信装置１を宛先として送信する
   ことを特徴とするデータ通信システム。
8. 請求項５に記載のデータ通信システムであって，
   前記セッション管理サーバは，
   前記機能提供サーバから，前記依頼した処理に対する前記結果として，前記通信装置２から前記通信装置１へのサービス提供を拒否するメッセージを受信した場合に，前記通信装置２へ転送した前記要求メッセージによるセッション確立要求，および／または，他の前記機能提供サーバへ依頼した処理，の取消メッセージを，送信する
   ことを特徴とするデータ通信システム。
9. 請求項６に記載のデータ通信システムであって，
   前記セッション管理サーバは，
   前記通信装置２および処理を依頼した全ての前記機能提供サーバから応答を受信した場合に，セッション確立を要求する前記要求メッセージに対する応答メッセージを前記通信装置１へ送信する
   ことを特徴とするデータ通信システム。
10. 請求項１に記載のデータ通信システムであって，
    前記セッション管理サーバは，
    前記通信装置２から，転送した前記要求メッセージに対する，サービス提供拒否メッセージを受信した場合に，前記機能提供サーバへ依頼した処理の取消メッセージを，当該機能提供サーバへ送信する
    ことを特徴とするデータ通信システム。
11. 請求項８に記載のデータ通信システムであって，
    前記セッション管理サーバが前記通信装置２へ送信したセッション確立要求の取消メッセージとは，セッション確立処理が処理の途中で中断されたことを明示するための情報を含む
    ことを特徴とするデータ通信システム。

Images