JP4561671B2 - データ通信方法およびシステム - Google Patents

Description

本発明は、データ通信方法およびシステムに関し、更に詳しくは、セッション管理サーバ装置を利用して、クライアント装置とサーバ装置との間での暗号化データ通信を可能にしたデータ通信方法およびシステムに関する。

ネットワークにおける暗号化通信方法では、クライアント装置（端末装置を指す。クライアントという）とサーバ装置（サーバという）は、互いに意図しない相手装置との通信を防止するため、相手装置について認証手順を実行し、相手装置の認証に成功した時、通信に使用する暗号化パラメータを交換するようにしている。ＩＥＴＦ（Internet Engineering Task Force）のＲＦＣ２４０１（非特許文献１）に記述されたＩＰｓｅｃ（Internet Protocol Security）では、通信相手の認証に公開鍵証明書が適用される。

公開鍵証明書を用いた認証では、通信相手が提示した公開鍵証明書が信頼できる認証局から発行されたものであることを何らかの方法で検証する必要がある。公開鍵証明書の検証方法の１つとしては、例えば、通信相手が提示する公開鍵証明書の発行元認証局を証明するための信頼性のある認証局ｒｏｏｔ証明書を何らかの方法で事前に入手しておき、通信相手の認証手順において、相手装置が提示した公開鍵証明書に付与された認証局の署名を、認証局のｒｏｏｔ証明書の公開鍵によって検証する方法がある。この検証方法によれば、サーバとクライアントは、通信対象となる全ての通信装置の公開鍵証明書に対応して、各公開鍵証明書の発行元認証局のｒｏｏｔ証明書を事前に用意しておく必要がある。

例えば、複数のクライアントＣＬ１、ＣＬ２、ＣＬ３が、それぞれ発行元認証局（ＣＡ１、ＣＡ２、ＣＡ３）の異なる秘密鍵ＳＫ１、ＳＫ２、ＳＫ３と公開鍵証明書ＰＫ１、ＰＫ２、ＰＫ３を所持し、サーバＳＶ１、ＳＶ２、ＳＶ３も、それぞれ発行元認証局（ＣＡ１、ＣＡ２、ＣＡ３）の異なる秘密鍵ＳＫ１１、ＳＫ１２、ＳＫ１３と公開鍵証明書ＰＫ１１、ＰＫ１２、ＰＫ１３を所持したシステムを想定する。ここで、各クライアントが、複数のサーバＳＶ１、ＳＶ２、ＳＶ３と随時に通信できるようにするためには、各サーバに、通信相手となる全てのクライアント装置ＣＬ１、ＣＬ２、ＣＬ３がもつ公開鍵証明書（ＰＫ１、ＰＫ２、ＰＫ３）の発行元認証局（ＣＡ１、ＣＡ２、ＣＡ３）と対応して、複数のｒｏｏｔ証明書ＲＴ１、ＲＴ２、ＲＴ３を事前に所持しておく必要がある。同様に、各クライアントにも、通信相手となるサーバＳＶ１、ＳＶ２、ＳＶ３がもつ公開鍵証明書（ＰＫ１１、ＰＫ１２、ＰＫ１３）の発行元認証局（ＣＡ１、ＣＡ２、ＣＡ３）と対応して、複数のｒｏｏｔ証明書ＲＴ１、ＲＴ２、ＲＴ３を事前に用意しておく必要がある。また、このシステム構成では、各クライアント装置とサーバは、通信相手を変えた時、その都度、認証処理を繰り返す必要がある。

上記ＲＦＣ２４０１に記述されたＩＰｓｅｃによる暗号化通信を行うためにクライアントが備えるソフトウェアは、ネットワークインタフェースカード（ＮＩＣ）部２０、ＴＣＰ／ＩＰレイヤの暗号化通信機能部３０、アプリケーション４０、ＲＦＣ２４０９（非特許文献２）に記述された鍵管理（ＩＫＥ：Internet Key Exchange）プロセス用のソフトウェア部である鍵管理プロセス５０から構成されている。暗号化通信機能部３０の暗号エンジン３１は、暗号化通信機能部３０のソフトウェアの一部として装備され、送信パケットに暗号化を適用するか否かの判定情報（ＳＰ情報）を記憶したＳＰＤＢ（Security Policy Data Base）３２と、暗号化通信に適用する暗号化方式や暗号鍵等の情報（ＳＡ（Security Association）情報）を記憶したＳＡＤＢ（Security Association Data Base）３３とを備えている。

上記クライアントの通信相手となるサーバも、上記と同様のソフトウェアを有し、クライアントとサーバのアプリケーションレイヤ同士、鍵管理プロセス同士が互いに通信するようになっている。

暗号エンジン３１は、アプリケーションレイヤ４０のプログラムが発行したＩＰパケットの送信要求を検出すると、該ＩＰパケットのヘッダ情報をＳＰＤＢ３２で検証し、このＩＰパケットにＩＰｓｅｃを適用すべきか否かを判定する。ＩＰパケットにＩＰｓｅｃを適用すると判断した暗号エンジン３１は、ＳＡＤＢ３３から、ＩＰパケットに適用すべきＳＡ情報を取得する。ここで、もし、ＳＡＤＢ３３に上記ＩＰパケットと対応するＳＡ情報が登録されていなかった場合、暗号エンジン３１は、ＩＫＥ（鍵管理）プロセス５０に対して、通信相手（接続先サーバ）との間での暗号鍵を含むＳＡ情報の交換を要求する。

鍵管理プロセス５０は、非特許文献２に従って、通信相手とＳＡ情報を交換する。非特許文献２では、通信相手との間に暗号化通信路を形成した後、相手装置が通信を許容された真正な装置か否かを確認するための認証手順を実行することが開示されている。鍵管理プロセス５０は、上記認証手順によって、相手装置が暗号化通信を許容された真正な装置であることを確認すると、上記暗号化通信路を介して、相手装置とＳＡ情報の交換を開始する。鍵管理プロセス５０は、通信相手とのＳＡ情報の交換が完了すると、暗号エンジン３１に、ＳＡ情報とこれに対応したＳＰ（Security Policy）情報を通知する。

暗号エンジン３１は、鍵管理プロセス５０から通知されたＳＰ情報とＳＡ情報をそれぞれＳＰＤＢ３２、ＳＡＤＢ３３に格納した後、ＩＰパケットを上記ＳＡ情報に従って暗号化して、通信相手に送信する。通信相手となるサーバ側では、上記暗号化されたＩＰパケットを受信すると、鍵管理プロセスによって合意したＳＡ情報に従って受信ＩＰパケットを復号化し、サーバ側アプリケーションレイヤにＩＰパケットの受信を通知する。

一方、ＲＦＣ３２６１（非特許文献３）には、ＴＬＳ（Transport Layer Security）によって、クライアント（ユーザエージェントクライアント）とＳＩＰ（Session Initiation Protocol）プロキシ装置（ＳＩＰプロキシという）との間、およびＳＩＰプロキシとサーバ（ユーザエージェント・サーバ）との間の相互認証を行って、クライアントとＳＩＰプロキシ、ＳＩＰプロキシとサーバが暗号化通信する方法が記載されている。ＲＦＣ３２６１のＳＩＰモデルによれば、クライアントとサーバは、それぞれがＳＩＰプロキシによって真正な通信相手として確認済みであり、且つ、クライアントとサーバとの間では、暗号化されたＳＩＰメッセージが送受信されるため、クライアント、サーバ、ＳＩＰプロキシ以外の他の装置が、上記クライアントとサーバとの間の通信内容を傍受することは困難となっている。

なお、ＳＩＰプロキシは、あるクライアントから別のクライアントに送信されるＳＩＰメッセージを中継したり、サービスを提供するためにユーザを認証したり、ユーザの権限を確認したり、といった処理を行うサーバである。また、ＳＩＰのフレームワークにおいては、ＳＩＰメッセージを中継するために、クライアントの現在のネットワーク上の位置を示すネットワークアドレス（ＩＰアドレス）を登録したり、更新したりする機能が規定されている。クライアントからのネットワーク識別子の登録要求や更新要求を処理するサーバは、レジストラ、と呼ばれる。

ＳＩＰは、テキストベースのプロトコルであり、ＳＩＰメッセージは、ヘッダ部と、セッション内容を示すメッセージボディ部とからなる。

IETF、RFC2401：Security Architecture for the Internet Protocol、[2005年11月29日検索] 、インターネット＜URL：http://www.ietf.org/rfc/rfc2401.txt＞ IETF、RFC2409：The Internet Key Exchange (IKE) 、[2005年11月29日検索] 、インターネット＜URL：http://www.ietf.org/rfc/rfc2409.txt＞http://www.ietf.org/rfc/rfc2408.txt＞ IETF、RFC3261：SIP: Session Initiation Protocol、[2005年11月29日検索] 、インターネット＜URL：http://www.ietf.org/rfc/rfc3261.txt＞

図１は、上述したＳＩＰプロキシを適用した認証システムの１例を示す。ここで、ＰＲは、複数のクライアントＣＬ１、ＣＬ２、ＣＬ３と、複数のサーバＳＶ１、ＳＶ２、ＳＶ３とに接続されたＳＩＰプロキシを示す。ＳＩＰプロキシＰＲは、認証局ＣＡ４が発行した秘密鍵ＳＫ３０と、公開鍵証明書ＰＫ３０を使用しており、サーバＳＶ１、ＳＶ２、ＳＶ３を認証するために、これらのサーバが使用する公開鍵証明書の発行元認証局（ＣＡ１、ＣＡ２、ＣＡ３）と対応した複数のｒｏｏｔ証明書ＲＴ１、ＲＴ２、ＲＴ３を予め所持している。

ＳＩＰプロキシを適用した認証システムでは、各サーバとクライアントは、図１に示すように、通信相手を認証するためのｒｏｏｔ証明書として、ＳＩＰプロキシＰＲが使用する公開鍵証明書ＰＫ３０の発行元認証局と対応したｒｏｏｔ証明書ＲＴ４を所持すればよい。また、各クライアントは、ＳＩＰプロキシＰＲを介して１つのサーバと通信した後、接続先を別のサーバに変更する場合、ＳＩＰプロキシとの間では既に構築済みの暗号通信路を使用して通信できるため、新たな通信相手との間で暗号化パラメータを交換するだけで、暗号化通信を開始することが可能となる。つまり、ＳＩＰプロキシを適用した認証システムでは、各クライアントにとって、接続先サーバの変更の都度、新たに認証処理を行う必要がないという利点がある。

然るに、ＳＩＰのフレームワークにおいては、ＳＩＰプロキシの機能を備えたセッション管理サーバ（ＳＩＰのフレームワークにおいては、ＳＩＰサーバとも称する）は、ＡＯＲ（Address-of-Record）と呼ばれる「ユーザ名＠ドメイン名」 形式をもつ接続先識別子（ＳＩＰ−ＵＲＩ）によって、受信ＳＩＰメッセージの転送先を決定している。従って、上述したＳＩＰプロキシのようなセッション管理サーバ経由のセッション設定を前提としたネットワークシステムでは、クライアント上で実行されるアプリケーションは、接続先サーバを指定するための識別子として、サーバの所属ドメインを特定可能なＳＩＰ−ＵＲＩ（Uniform Resource Identifier）を使用する必要がある。

更に詳述すると、ＳＩＰのフレームワークにおいては、クライアント側では、スタートラインに含まれるＲｅｑｕｅｓｔ−ＵＲＩとして、接続先サーバを指定するＡＯＲ形式のＳＩＰ−ＵＲＩを記述した接続要求ＳＩＰメッセージを生成し、該ＳＩＰメッセージをペイロードに含むＩＰパケットをクライアントの所属ドメインに位置するＳＩＰプロキシ宛に送信する。上記ＩＰパケットを受信したＳＩＰプロキシは、Ｒｅｑｕｅｓｔ−ＵＲＩとして記述されたＡＯＲが示すドメイン名に基づいて、例えば、ＤＮＳ（Domain Name System）のＮＡＰＴＲ Ｒｅｃｏｒｄ検索とＳＲＶ Ｒｅｃｏｒｄ検索を行うことにより、受信メッセージの転送先サーバが所属する他のドメインに位置したＳＩＰプロキシ（転送先ＳＩＰプロキシ）のＩＰアドレスあるいはＦＱＤＮ（Full Qualified Domain Name）を特定する。ＳＲＶ Ｒｅｃｏｒｄ検索の結果がＦＱＤＮを示した場合は、ＤＮＳのＡ Ｒｅｃｏｒｄ検索を実行することによって、転送先ＳＩＰプロキシのＩＰアドレスを取得できる。

ここで、接続先サーバの所属ドメインが、ＳＩＰメッセージを受信したＳＩＰプロキシの所属ドメインと同一であった場合、ＳＩＰプロキシは、受信メッセージのＲｅｑｕｅｓｔ−ＵＲＩに記述されたＳＩＰ−ＵＲＩを検索キーとして、ロケーションサービスＤＢ（データベース）から接続先サーバのＩＰアドレス（またはＦＱＤＮ）を取得し、このＩＰアドレスをＩＰパケットの宛先アドレスとして、ＳＩＰメッセージを接続先サーバに転送する。接続先サーバの所属ドメインがＳＩＰプロキシ（または送信元クライアント）の所属ドメインと異なった場合は、ＳＩＰメッセージは、接続先サーバの所属ドメインに位置した別のＳＩＰプロキシに転送され、転送先のＳＩＰプロキシが、ロケーションサービスＤＢから接続先サーバのＩＰアドレスまたはＦＱＤＮを取得して、ＳＩＰメッセージを接続先サーバに転送する。

上述したように、セッション管理サーバ（ＳＩＰプロキシ）経由のセッション設定を前提とするネットワークでは、セッション管理サーバが、受信したＳＩＰメッセージに含まれる接続先識別子（ＳＩＰ−ＵＲＩ）から、接続先サーバが所属するドメインを判定し、受信メッセージを接続先サーバあるいは接続先セッション管理サーバに転送するようになっている。

しかしながら、ＩＰ網に接続されるクライアント端末上で実行される一般のアプリケーションプログラムは、接続先サーバの指定に、上述したＡＯＲ形式のＳＩＰ−ＵＲＩのようにＳＩＰのフレームワークにおける識別子ではなく、ＩＰアドレスのように接続先サーバを示す識別子を使用したり、ＵＲＬなどのようにドメイン名を含んでいても、ＳＩＰ−ＵＲＩとは異なるフレームワークの識別子を使用したりしている。

アプリケーションプログラムまたは暗号化通信ソフトが、接続先サーバをＩＰアドレスやＵＲＬで指定してサーバとの接続要求を発行し、クライアントが、接続先サーバをＩＰアドレスやＵＲＬで指定した形で接続要求ＳＩＰメッセージを送信した場合、セッション管理サーバ（ＳＩＰプロキシ）は、受信した接続要求メッセージの転送先ドメインを特定することができない。この場合、クライアントが図１に示した認証システムの利点を享受できないという問題がある。

本発明は、セッション管理サーバが採用しているものとは異なる、接続先の装置をＩＰアドレスやＵＲＬのような、アプリケーションが相手を識別するために使用する識別子（以降、サービス識別子とも呼ぶ）で指定したセッション制御メッセージをセッション管理サーバ経由で接続先サーバに転送可能にしたデータ通信方法およびシステムを提供する。

本発明は、また、接続先サーバをサービス識別子で指定したクライアントからの接続要求をセッション管理サーバ経由で当該接続先サーバに転送可能にしたデータ通信方法およびシステムを提供する。

本発明は、また、クライアントとサーバとの間の暗号化データ通信を可能にし、且つ、暗号化データ通信に先立って必要となるクライアントとサーバとの間の認証手順を容易にしたデータ通信方法およびシステムを提供する。

具体的には、本発明は、複数の識別情報管理サーバがそれぞれ異なる接続先識別子に関するサービス識別子を管理している場合に、当該サービス識別子の接続先識別子を取得するために問い合わせるべき管理サーバを、サービス識別子の管理ドメインとして管理するドメイン管理テーブルを設ける。クライアントが接続先サーバをサービス識別子で指定した接続要求を発行した時、クライアントから要求を受信した第一の管理サーバが、ドメイン管理テーブルを検索して上記サービス識別子の管理ドメインを見つけ、当該管理ドメインの第二の管理サーバが上記サービス識別子を接続先識別子に変換することを特徴とする。

たとえば、本発明は、複数のドメインからなる通信ネットワークと、それぞれのドメインを管理する管理サーバと、互いに異なるドメインに接続されたクライアントとサービスサーバとからなる通信システムにおける、クライアントと接続先サーバとの間のデータ通信方法であって、クライアントが、サービス識別子を指定して、当該サービス識別子が割り当てられた上記接続先サーバの、所属ドメイン名を含む接続先識別子を、上記クライアントが所属するドメインを管理する第一の上記管理サーバに問い合わせる第１ステップと、上記クライアントから問合せを受けた第一の上記管理サーバが、サービス識別子とその所属ドメインとの対応関係を管理しているドメイン管理テーブルから、上記接続先サーバの所属ドメイン名を取得し、当該所属ドメインを管理する第二の上記管理サーバに、上記接続先サーバのサービス識別子を指定して、該接続先サーバに割り当てられた、当該接続先サーバの所属ドメイン名を含む接続先識別子を問い合わせる第２ステップと、上記第二の上記管理サーバが、上記サービス識別子と接続先識別子との対応関係を管理している識別情報管理テーブルから、上記接続先サーバのサービス識別子と対応する接続先識別子を取得し、上記クライアントに通知する第３ステップと、上記クライアントが、上記第一の管理サーバに、取得した上記接続先サーバの接続先識別子を含む接続要求メッセージを送信する第４ステップと、上記第一の管理サーバが、受信した上記接続要求メッセージに記述された上記接続先識別子に含まれるドメイン名に基づいて受信した上記接続要求メッセージの送信先を判定し、上記接続要求メッセージを上記接続先サーバ、または該接続先サーバの所属ドメインを管理する上記第二の管理サーバに転送する第５ステップと、からなることを特徴とする。

更に詳述すると、本発明のデータ通信方法は、上記接続先サーバが、上記接続要求メッセージの受信に応答して、上記管理サーバを介して、上記要求元クライアントに、暗号化通信に必要となるパラメータ情報を含む接続応答メッセージを返送する第６ステップと、上記クライアントと上記接続先サーバとの間で、上記接続応答メッセージで指定されたパラメータ情報に従って暗号化されたメッセージを通信する第７ステップと、を含むことを特徴とする。

上記管理サーバは、当該クライアントまたは接続先サーバが所属するドメインの通信セッションを管理するセッション管理サーバであってもよいし、当該クライアントまたは接続先サーバが所属するドメインの識別情報を管理する識別情報管理サーバであってもよい。

例えば、セッション管理サーバが上記管理サーバである場合、本発明によるクライアントとサーバとの間のデータ通信方法は、クライアントから第一のセッション管理サーバに、接続先のサービス識別子を指定して、該接続先サーバに割り当てられた所属ドメイン名を含む接続先識別子を問い合わせるAOR取得要求メッセージを送信する第１ステップと、上記第一のセッション管理サーバが、サービス識別子と、当該サービス識別子の管理ドメインをドメイン管理テーブルから上記サービス識別子の管理ドメインを取得し、当該管理ドメインに属する第二のセッション管理サーバに上記AOR取得要求メッセージを転送する第２ステップと、
上記第二のセッション管理サーバが、サービス識別子と接続先識別子との対応関係を管理しているロケーションテーブルから、上記接続先サーバのサービス識別子と対応する接続先識別子を取得し、上記クライアントに当該接続先識別子を含む、AOR取得応答メッセージを送信する第３ステップと、上記クライアントから上記セッション管理サーバに、要求リソースを上記接続先サーバの接続先識別子で指定した接続要求メッセージを送信する第４ステップと、上記第一のセッション管理サーバが、受信した接続要求メッセージに記述された上記接続先識別子に含まれるドメイン名に基づいて受信メッセージの転送先を判定し、受信メッセージを接続先サーバまたは該接続先サーバの所属ドメインを管理する別のセッション管理サーバに送信する第５ステップと、からなることを特徴とする。

更に詳述すると、上記のデータ通信方法は、接続要求メッセージの受信に応答して、上記第二のセッション管理サーバが接続先サーバに暗号化通信に必要となるパラメータ情報を送信する第６ステップと、上記第一のセッション管理サーバが上記クライアントに暗号化通信に必要となるパラメータ情報を送信する第７ステップと、上記クライアントと接続先サーバとの間で、上記接続応答メッセージで指定されたパラメータ情報に従って暗号化されたメッセージを含むパケットを通信する第８ステップと、を含むことを特徴とする。

また、識別情報管理サーバが上記管理サーバである場合、本発明によるクライアントとサーバとの間のデータ通信方法は、クライアントから第一の識別情報管理サーバに、接続先のサービス識別子を指定して、該接続先サーバに割り当てられた所属ドメイン名を含む接続先識別子を問い合わせる、第一のAOR取得要求メッセージを送信する第１ステップと、上記第一の識別情報管理サーバが、ドメイン管理テーブルから上記サービス識別子の管理ドメインを取得し、当該管理ドメインに属する第二の識別情報管理サーバに上記第一のAOR取得要求メッセージに含まれるサービス識別子の接続先識別子を問い合わせる、第二のAOR取得要求メッセージを作成して送信する第２ステップと、上記第二の識別情報管理サーバが、サービス識別子と接続先識別子との対応関係を管理しているロケーションテーブルから、上記接続先サーバのサービス識別子と対応する接続先識別子を取得し、当該接続先識別子を含む第一のAOR取得応答メッセージを上記第一の識別情報管理サーバに送信する第３ステップと、上記第一の識別情報管理サーバが上記第一のAOR取得応答メッセージの記述内容に基づいて作成した、上記接続先識別子を含む第二のAOR取得応答メッセージを上記クライアントに送信する第４ステップと、上記クライアントから上記第一の識別情報管理サーバに、上記接続先サーバの接続先識別子を含む第一の接続要求メッセージを送信する第５ステップと、上記第一のセッション管理サーバが、受信した第一の接続要求メッセージに記述された上記接続先識別子に含まれるドメイン名に基づいてメッセージの送信先を判定し、上記第一の接続要求メッセージの記載内容に基づいて作成した第二の接続要求メッセージを接続先サーバまたは該接続先サーバの所属ドメインに存在する第二の識別情報管理サーバに送信する第６ステップと、からなることを特徴とする。

更に詳述すると、上記のデータ通信方法は、接続要求メッセージの受信に応答して、上記第二のセッション管理サーバが接続先サーバに暗号化通信に必要となるパラメータ情報を送信する第７ステップと、上記第一のセッション管理サーバが上記クライアントに暗号化通信に必要となるパラメータ情報を送信する第８ステップと、上記クライアントと接続先サーバとの間で、上記接続応答メッセージで指定されたパラメータ情報に従って暗号化されたメッセージを含むパケットを通信する第９ステップと、を含むことを特徴とする。

また、上記のデータ通信方法は、クライアントがデータ通信を終了する場合に、クライアントが切断処理を開始することを通知する、第一の切断開始要求メッセージを上記第一の識別情報管理サーバに送信する第１０ステップと、上記第一の切断開始要求メッセージの記載内容に基づいて作成した、第二の切断開始要求メッセージを接続先サーバまたは該接続先サーバの所属ドメインに存在する上記第二の識別情報管理サーバに送信する第１１ステップと、を含むことを特徴とする。

また、上記セッション管理サーバは、例えば、ＳＩＰ（Session Initiation Protocol）サーバからなる。この場合、クライアントとセッション管理サーバとの間の通信メッセージは、例えば、ＲＦＣ３２６１に規定されたＴＬＳ（Transport Layer Security）によって暗号化され、クライアントと接続先サーバとの間の通信データは、例えば、ＲＦＣ２４０１に規定されたＩＰｓｅｃ（Internet Protocol Security）によって暗号化される。それぞれの暗号化プロトコルが上記に限定されないのは勿論である。

本発明によって提供される管理サーバは、それぞれのドメインを管理する管理サーバであって、複数のドメインからなる通信ネットワークにおいて、クライアントおよびサーバと通信し、サービス識別子とその所属ドメインとの対応関係を管理しているドメイン管理テーブルを備え、上記クライアントから、サービス識別子を指定して、当該サービス識別子が割り当てられた上記接続先サーバの所属ドメイン名を含む、接続先識別子の問い合わせを受信した場合に、上記ドメイン管理テーブルから、上記接続先サーバの所属ドメイン名を取得し、当該所属ドメインを管理する他の管理サーバに、上記接続先サーバのサービス識別子を指定して、該接続先サーバに割り当てられた、当該接続先サーバの所属ドメイン名を含む接続先識別子を問い合わせ、上記他の管理サーバから、上記問い合わせた接続先サーバの接続先識別子を取得し、取得した上記接続先識別子を上記クライアントに通知し、上記クライアントから、通知した上記接続先サーバの接続先識別子を含む接続要求メッセージを受信した場合に、受信した上記接続要求メッセージに記述された上記接続先識別子に含まれるドメイン名に基づいて、受信した上記接続要求メッセージの送信先を判定し、上記接続要求メッセージを、上記接続先サーバまたは該接続先サーバの所属ドメインを管理する上記他の管理サーバに転送することを特徴とする。

上記態様によれば、クライアントのアプリケーションプログラムまたは暗号化通信ソフトから、要求リソース（接続先サーバ）をサービス識別子で指定した形で接続要求が発行された場合でも、接続要求メッセージの要求リソースをサービス識別子からドメイン識別可能な接続先識別子に自動的に変換できる。従って、接続要求メッセージを転送制御するセッション管理サーバにおいて、受信メッセージの接続先識別子から転送先ドメインを判定し、受信メッセージを接続先サーバ、または接続先サーバの所属ドメインに位置した別のセッション管理サーバに転送することが可能となる。

また、上記態様によれば、一般のアプリケーションプログラムを実行するクライアントでも、セッション管理サーバによる認証機能を利用することによって、接続先サーバとの間で容易に暗号化通信を実現できる。

また、上記態様によれば、上記サービス識別子の管理ドメイン毎に異なる識別情報管理サーバで管理することができる。また、サービス識別子から管理ドメインを検索できる。従って、クライアントの数が多くなった場合にも管理ドメインを分けることによって性能劣化を防ぐことができる。

本発明によれば、接続先をアプリケーション固有の識別情報で指定したセッション制御メッセージをセッション管理サーバ経由で接続先に転送することが可能となり、各クライアントが、接続先サーバの変更の都度、新たに認証処理を行う必要がなくなる。

以下、本発明の実施例について図面を参照して説明する。

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

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

また、以下の実施例に於いて使用しているドメイン名、URL、URI、IPアドレス等の識別子は、説明のために用いる架空のものであり、実在するものがあったとしても関係はない。

図２は、本発明が適用されるシステム構成の一例を示す。

ここに示したネットワークは、ＳＩＰサーバ装置（以下、ＳＩＰサーバという）ＳＩＰａが管理する第１ドメインを形成する第１のネットワークＮＷ１と、ＳＩＰサーバＳＩＰｂが管理する第２ドメインを形成する第２のネットワークＮＷ２と、ロケーションサーバ装置（以下、ロケーションサーバという）ＬＳＶと、ＤＮＳ（Domain Name System）装置（以下、ＤＮＳという）とからなる。

第１のネットワークＮＷ１には、クライアントＣＬ１ａ、ＣＬ２ａと、サーバＳＶ１ａ、ＳＶ２ａが接続され、第２のネットワークＮＷ２には、クライアントＣＬ１ｂ、ＣＬ２ｂと、サーバＳＶ１ｂ、ＳＶ２ｂが接続されている。また、ＳＩＰサーバＳＩＰａは、ＳＩＰプロキシＰＲａとレジストラＰＧａとからなり、ＳＩＰサーバＳＩＰｂは、ＳＩＰプロキシＰＲｂとレジストラＰＧｂとからなっている。ＳＩＰプロキシＰＲａ，ＰＲｂとレジストラＰＧａ，ＰＧｂは、それぞれが独立した装置であってもよいし、ＳＩＰサーバＳＩＰａ，ＳＩＰｂに含まれる処理部であってもよい。

ここで、各クライアントおよびサーバに付随して括弧内に示した文字列は、ＳＩＰメッセージの転送先識別子（接続先識別子）となるＡＯＲ（Address-of-Record）形式のＳＩＰ−ＵＲＩの値を示している。第１ネットワークＮＷ１に接続されたクライアントとサーバには、ＳＩＰサーバＳＩＰａのドメイン識別子「aaa.com」を含むＡＯＲが割り当てられ、第２ネットワークＮＷ２に接続されたクライアントとサーバには、ＳＩＰサーバＳＩＰｂのドメイン識別子「bbb.com」を含むＡＯＲが割り当てられている。

本発明のＳＩＰサーバＳＩＰａ、ＳＩＰｂは、それぞれの管轄下にあるクライアントから、接続先サーバをＵＲＬで指定したＳＩＰメッセージを受信した時、ロケーションサーバＬＳＶに、上記接続先ＵＲＬと対応するＡＯＲ（接続先識別子）の検索（ロケーションデータ検索）を要求する。また、ＳＩＰサーバＳＩＰａ、ＳＩＰｂは、それぞれ他のＳＩＰサーバから、接続先サーバをＡＯＲで指定したＳＩＰメッセージを受信した時、ロケーションサーバＬＳＶに、上記接続先ＡＯＲと対応するＩＰアドレスの検索を要求する。

ロケーションサーバＬＳＶは、ロケーションサービス・データベース（ＤＢ）に、例えば、図３に示すように、ＳＩＰサーバＳＩＰａ、ＳＩＰｂの管轄下にあるクライアントおよびサーバと対応した複数のエントリＥＮ−１、ＥＮ−２，・・・からなり、各エントリが、クライアントまたはサーバという、通信相手の装置を識別するサービス識別子としてのＡＯＲ６２とＩＰアドレスなどのネットワークアドレス（以下、ＩＰアドレスという）６３との対応関係を示すロケーションサービステーブル６１を格納する。

また、ロケーションサーバＬＳＶは、ＳＩＰサーバＳＩＰａ、ＳＩＰｂの管轄下にあるクライアントおよびサーバと対応した複数のエントリＲＥＮ−１、ＲＥＮ−２，・・・からなり、各エントリが、クライアントまたはサーバのアプリケーションプログラムや暗号化通信ソフトが通信相手の装置が提供するサービスを識別するために用いる識別子であるサービス識別情報６５と、ＡＯＲ６２との対応関係を示す識別情報管理テーブル６４と、を備えている。

ロケーションサーバＬＳＶは、ＳＩＰサーバからの検索キーとしてＡＯＲを指定されたロケーションデータ検索要求を受信した場合、上記ロケーションサービステーブル６１から、当該ＡＯＲと対応するＩＰアドレスを検索し、検索結果を要求元ＳＩＰサーバに返送する。

同様に、ロケーションサーバＬＳＶは、ＳＩＰサーバからの検索キーとしてＵＲＬ等のサービス識別子を含むサービス識別情報６５を指定されたロケーションデータ検索要求を受信した場合、上記識別情報管理テーブル６４から、当該サービス識別情報６５と対応するＡＯＲを検索し、検索結果を要求元ＳＩＰサーバに返送する。

なお、本実施例では、サービス識別情報６５にはＵＲＬやＵＲＩやＩＰアドレスなどが使用可能である。サービス識別情報６５はこれらＵＲＬ等に限られず、それぞれの装置に独自に割り当てられ互いに識別が可能な情報であればよい。なお、ＩＰアドレスを使用する場合には、ＵＲＬやＵＲＩとの区別を容易にするため、ＩＰアドレスの先頭に「ipv4:」や「ipv6:」などのプレフィックスをつけることが望ましい。

以下、図２に示した第１ドメインに所属するクライアントＣＬ１ａが、第２ドメインに所属するサーバＳＶ１ｂと暗号化データ通信する場合の通信手順を例にして、本発明の第１の実施例について説明する。

図５は、クライアントＣＬ１ａの基本的なソフトウェア構造の一例を示す。他のクライアントＣＬ１ｂ〜ＣＬ２ｂも、これと同様のソフトウェア構造をとりうる。クライアントＣＬ１ａのソフトウェアは、ネットワークインタフェースカード部（ＮＩＣ）２０Ｃと、暗号化／復号化機能を備えた暗号エンジン３１Ｃを含む暗号化通信機能部３０Ｃと、アプリケーションプログラム４０Ｃと、鍵管理プロセス部５０Ｃとからなる。第１実施例では、鍵管理プロセス部５０Ｃが、暗号化通信制御部５１Ｃと、ＴＬＳ（Transport Layer Security）部５２Ｃと、ＳＩＰメッセージ処理部５３Ｃとを備えたことを特徴としている。

図６は、サーバＳＶ１ｂの基本的なソフトウェア構造の一例を示す。他のサーバＳＶ１ａ、ＳＶ２ａ、ＳＶ２ｂも、これと同様のソフトウェア構造をとりうる。サーバＳＶ１ｂのソフトウェアは、ネットワークインタフェースカード部（ＮＩＣ）２０Ｓと、ＩＰｓｅｃ暗号化／復号化機能を備えた暗号エンジン３１Ｓを含む暗号化通信機能部３０Ｓと、アプリケーションプログラム４０Ｓと、鍵管理プロセス部５０Ｓとからなり、鍵管理プロセス部５０Ｓが、暗号化通信制御部５１Ｓと、ＴＬＳ部５２Ｓと、ＳＩＰメッセージ処理部５３Ｓとを備えている。

本実施例では、クライアントＣＬ１ａのアプリケーションプログラム４０ＣとサーバＳＶ１ｂのアプリケーションプログラム４０Ｓは、それぞれが備える暗号エンジン３１Ｃ、３１ＳのＩＰｓｅｃ暗号化／復号化機能を利用して、ＩＰｓｅｃによる暗号化データを通信する。一方、クライアントＣＬ１ａのＳＩＰメッセージ処理部５３Ｃは、後述するＳＩＰサーバＳＩＰａ（ＳＩＰプロキシＰＲａ、レジストラＲＧａ）のＳＩＰメッセージ処理部との間で、それぞれが備えるＴＬＳ部のメッセージ暗号化／復号化機能を利用して、暗号化されたＳＩＰメッセージを通信する。同様に、サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓも、ＳＩＰサーバＳＩＰａ（ＳＩＰプロキシＰＲａ、レジストラＲＧａ）のＳＩＰメッセージ処理部との間で、それぞれが備えるＴＬＳ部のメッセージ暗号化／復号化機能を利用して、暗号化されたＳＩＰメッセージを通信する。

図７は、ＳＩＰプロキシＰＲａの基本的なソフトウェア構造の一例を示す。ＳＩＰプロキシＰＲｂも、これと同様のソフトウェア構造をとりうる。ＳＩＰプロキシＰＲａのソフトウェアは、ネットワークインタフェースカード部（ＮＩＣ）２０Ｐと、暗号化通信機能部３０Ｐと、鍵管理プロセス部５０Ｐとからなる。鍵管理プロセス部５０Ｐが、ＴＬＳ部５２Ｐと、ＳＩＰメッセージ処理部５３Ｐとを備えている。ＳＩＰメッセージ処理部５３Ｐは、後述するＳＩＰ−ＵＲI（ＡＯＲ）検索機能５４を備えている。ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐは、ＴＬＳ部５２Ｐのメッセージ暗号化／復号化機能を利用して、管理下にあるドメインに所属したクライアント、サーバ、および他のドメインを管理する他のＳＩＰプロキシ、例えばＰＲｂと暗号化メッセージを通信する。

図８は、レジストラＲＧａの基本的なソフトウェア構造の一例を示す。レジストラＲＧｂも、これと同様のソフトウェア構造をとりうる。レジストラＲＧａのソフトウェアは、ネットワークインタフェースカード部（ＮＩＣ）２０Ｒと、暗号化通信機能部３０Ｒと、メッセージの暗号化／復号化機能を備えたＴＬＳ部５２Ｒと、ＳＩＰメッセージ処理部５３Ｒと、レジストラ処理部６０Ｒとからなっている。ＳＩＰメッセージ処理部５３Ｒは、クライアントが発行したＡＯＲ取得要求、またはＳＩＰプロキシＰＲａが発行したＡＯＲ取得要求を受信すると、レジストラ処理部６０Ｒにロケーションデータの検索を要求する。レジストラ処理部６０Ｒは、ＳＩＰメッセージ処理部５３Ｒからの要求に応答して、ロケーションサーバＬＳＶが備えるロケーションサービスＤＢをアクセスする。尚、レジストラＲＧａとＳＩＰプロキシＰＲａとの間の通信には、暗号化を適用しなくてもよい。

図９と図１０は、本発明による暗号化データ通信の第１の実施例を示すシーケンス図である。第１の実施例では、クライアントＣＬ１ａがＡＯＲ取得要求を発行する。本実施例において、クライアントＣＬ１ａからの接続要求先となる第２ネットワークに接続されたサーバＳＶ１ｂは、クライアントＣＬ１ａからの接続要求に先立って、ＳＩＰサーバＳＩＰｂのレジストラＲＧｂとの間で、サーバＳＶ１ｂの認証と暗号化通信用のパラメータ設定のためのＴＬＳネゴシェーション（Ｓ１）を実行した後、レジストラＲＧｂにロケーション登録要求メッセージ（ＳＩＰメッセージ：REGISTER）Ｍ１を送信する。

ロケーション登録要求メッセージＭ１は、例えば、図１１に示すように、ＩＰヘッダＨ１と、ＵＤＰ／ＴＣＰヘッダＨ２とを付したＩＰパケット形式で送信される。ＩＰヘッダＨ１は、宛先アドレスとしてレジストラＲＧｂ（ＳＩＰサーバＳＩＰｂ）のＩＰアドレス、送信元アドレスとしてサーバＳＶ１ｂのＩＰアドレスを含む。

ＳＩＰメッセージは、ＳＩＰメッセージの種類（Request-Method）を示すスタートラインと、要求または応答内容を記述したメッセージヘッダ部と、必要に応じてセッション内容を記述したメッセージボディ部とからなる。メッセージの種類によっては、上記スタートラインに、該メッセージの宛先を示す接続先識別子（Request-URI）が記述される。（なお、以下では、スタートラインとメッセージヘッダ部をまとめて、ヘッダ部、と称する。また、メッセージボディ部を単に、ボディ部、とも称する。）
サーバＳＶ２ｂが発行するロケーション登録要求メッセージＭ１の場合、スタートラインには、ＳＩＰメッセージの種類として「REGISTER」、メッセージ宛先を示す接続先識別子として、レジストラＲＧｂのＳＩＰ−ＵＲＩである「registrar.bbb.com」が含まれる。また、スタートラインに続くメッセージヘッダ部には、ＳＩＰメッセージの経路を示すＶｉａヘッダ、メッセージの宛先を示すＴｏヘッダ、メッセージの送信元を示すＦｒｏｍヘッダ、送信元で指定したセッション識別子を示すＣａｌｌ−ＩＤヘッダ、要求メソッドを示すＣＳｅｃヘッダ、ロケーションサービステーブルに登録すべきサーバＳＶ１ｂのＩＰアドレス「sv1＠192.0.2.4」を含むＣｏｎｔａｃｔヘッダ、メッセージの有効時間を示すＥｘｐｉｒｅｓヘッダ、後続するメッセージボディ部の長さを示すＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダ、その他のヘッダ情報が含まれる。

本実施例のロケーション登録要求メッセージＭ１の場合、メッセージボディ部にはサーバＳＶ１ｂのサービス識別情報６５のリストが含まれる。Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダにはメッセージボディ部の長さとして値「４６」が設定され、ＴｏヘッダとＦｒｏｍヘッダには、要求元サーバＳＶ１ｂのＳＩＰ−ＵＲＩの値「sv1＠bbb.com」が設定されている。

レジストラＲＧｂは、上記ロケーション登録要求メッセージＭ１を受信すると、ロケーションサービスＤＢのロケーションサービステーブル６１に、受信メッセージのＦｒｏｍヘッダが示す要求元ＳＩＰ−ＵＲＩ「sv1＠bbb.com」とＣｏｎｔａｃｔヘッダが示す要求元ＩＰアドレス「sv1＠192.0.2.4」との関係を示すロケーションデータを登録するとともに、識別情報管理テーブル６４に、受信メッセージのメッセージボディ部に含まれている各々のサービス識別情報６５と受信メッセージのＦｒｏｍヘッダが示す要求元ＳＩＰ−ＵＲＩ「sv1＠bbb.com」との関係を示す識別情報データを登録する（Ｓ２）。

データの登録が完了すると（Ｓ３）、要求元サーバＳＶ２ｂに、図１１に示すロケーション登録応答メッセージＭ２を送信する。ロケーション登録応答メッセージＭ２のスタートラインは、ＳＩＰメッセージの種類として、応答メッセージであることを示す「200 OK」を含み、メッセージヘッダ部には、ロケーション登録要求メッセージＭ１と同一内容のヘッダ情報が設定される。

この状態で、クライアントＣＬ１ａのユーザが、アプリケーションプログラムを立ち上げ、サーバＳＶ１ｂのＵＲＬ「http://www.bbb.com/」宛に通信を要求する操作を行った場合について説明する。本発明の第１の実施例では、クライアントＣＬ１ａが、ＳＩＰサーバＳＩＰａ（レジストラＲＧａ）との間で、クライアントの認証と暗号化通信用のパラメータ設定のためのＴＬＳネゴシェーション（Ｓ４）を実行した後、ＳＩＰサーバＳＩＰａ（レジストラＲＧａ）にＡＯＲ（Address-of-Record）取得要求メッセージ（ＳＩＰメッセージ：GET AOR）Ｍ３を送信する。

上記ＡＯＲ取得要求メッセージＭ３は、本実施例で新たにＳＩＰを拡張して作成したメッセージであり、例えば、図１２に示すように、スタートラインに、ＳＩＰメッセージ種類を示す「GET AOR」と、レジストラＲＧａのＳＩＰ−ＵＲＩである「registrar.aaa.com」を含み、Ｖｉａヘッダは、クライアントＣＬ１ａの暗号化通信制御部５１Ｃの識別子となるＵＲＩの値を示している。また、Ｔｏヘッダには、クライアントＣＬ１ａの接続相手となるサーバＳＶ１ｂのＵＲＬ「http://www.bbb.com/」が設定され、Ｆｒｏｍヘッダには、クライアントＣＬ１ａのＵＲＩ「cl1＠aaa.com」が設定されている。

レジストラＲＧａは、ＡＯＲ取得要求メッセージＭ３を受信すると、ロケーションサービスＤＢの識別情報管理テーブル６４から、受信メッセージのＴｏヘッダが示すＵＲＬ「http://www.bbb.com/」と対応するＡＯＲ（サーバＳＶ１ｂのＵＲＩ）の値を検索し（Ｓ５）、ロケーションデータＡＯＲの検索が完了すると（Ｓ６）、要求元クライアントＣＬ１ａにＡＯＲ取得応答メッセージＭ４を送信する。

ＡＯＲ取得応答メッセージＭ４は、図１２に示すように、スタートラインに、メッセージ種類が応答メッセージであることを示す「200 OK」を含み、メッセージヘッダ部には、ＡＯＲ取得要求メッセージＭ３と略同一内容のヘッダ情報と、識別情報管理テーブル６４から検索されたサーバＳＶ１ｂのＳＩＰ−ＵＲＩの値「sv1＠bbb.com」を示すＡＯＲヘッダが記述されている。

上記ＡＯＲ取得応答メッセージＭ４の受信によって接続先サーバＳＶ１ｂのＳＩＰ−ＵＲＩを取得したクライアントＣＬ１ａは、ＳＩＰサーバＳＩＰａのＳＩＰプロキシＰＲａとの間で、クライアントの認証と暗号化通信用のパラメータ設定のためのＴＬＳネゴシェーション（Ｓ７）を実行した後、ＳＩＰプロキシＰＲａに対して、サーバＳＶ１ｂへの接続要求メッセージＭ５を送信する。

接続要求メッセージＭ５は、接続要求メッセージのヘッダ部Ｍ５−１とボディ部Ｍ５−２とからなり、接続要求メッセージのヘッダ部Ｍ５−１は、スタートラインに、メッセージ種類「INVITE」と、Ｒｅｑｕｅｓｔ−ＵＲＩとして、メッセージ宛先となるサーバＳＶ１ｂのＳＩＰ−ＵＲＩ「sv1＠bbb.com」を含む。

また、メッセージヘッダ部に、クライアントＣＬ１ａにおけるＳＩＰメッセージ処理部５３ＣのＳＩＰ−ＵＲＩを示すＶｉａヘッダ、サーバＳＶ１ｂのＳＩＰ−ＵＲＩ「sv1＠bbb.com」を含むＴｏヘッダ、クライアントＣＬ１ａのＳＩＰ−ＵＲＩ「cl1＠aaa.com」を含むＦｒｏｍヘッダと、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダ、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダ、その他の情報を含む。Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダは、ボディ部Ｍ５−２が関係するアプリケーションプログラムを示し、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダは、ボディ部Ｍ５−２の長さを示している。

接続要求メッセージＭ５のボディ部Ｍ５−２は、例えば、図１３に示すように、クライアントＣＬ１ａとサーバＳＶ１ｂとの間での暗号化通信に適用するＳＡ情報として、ＩＫＥにおける通常のＩＰｓｅｃ用ＳＡ設定時と同様、暗号化プロトコルの識別情報を示すプロポーザルペイロード９１と、トランスフォーム識別情報を示すトランスフォームペイロード９２、鍵交換ペイロード９３、要求元の識別情報を示す第１ＩＤペイロード９４と、接続先の識別情報を示す第２ＩＤペイロード９５を含んでいる。

図１３では、クライアントＣＬ１ａが、２つのトランスフォームペイロード９２−１、９２−２で、トランスフォームＩＤとして「ESP-AES」と「ESP-3DES」を提案しており、そのうちの１つを接続先サーバＳＶ１ｂが選択して、接続応答メッセージでクライアントに通知することになる。尚、第１ＩＤペイロード９４のＩＤデータは、要求元クライアントＣＬ１ａのＩＰアドレスを示し、第２ＩＤペイロード９５のＩＤデータは、接続先サーバＳＶ１ｂのＩＰアドレスを示す。なお、本実施例のクライアントＣＬ１ａは、接続先サーバＳＶ１ｂのＩＰアドレスとして、サーバＳＶ１ｂのＵＲＬ「http://www.bbb.com/」に対応するＩＰアドレスをＤＮＳから取得する。

ＳＩＰプロキシＰＲａは、上記接続要求メッセージＭ５を受信すると、要求元クライアントＣＬ１ａにサーバＳＶ１ｂと接続中であることを通知するために、接続中メッセージＭ６を送信した後、接続先サーバＳＶ１ｂが所属するドメインのＳＩＰプロキシＰＲｂとの間で、相互の認証と暗号化通信用のパラメータ設定のためのＴＬＳネゴシェーション（Ｓ８）を実行する。

接続中メッセージＭ６は、スタートラインに、メッセージ種類として、要求を実行中であることを示す「100 Trying」を含み、メッセージヘッダ部に、接続要求メッセージＭ５から抽出されたＶｉａ、Ｔｏ、Ｆｒｏｍ、Ｃａｌｌ−ＩＤ、ＣＳｅｃ等の数項目のヘッダ情報を含み、メッセージボディ部は省略されている。

ＳＩＰプロキシＰＲａは、ＳＩＰプロキシＰＲｂとの間のＴＬＳネゴシェーションが終わると、クライアントから受信した接続要求メッセージＭ５に、自分のＳＩＰ−ＵＲＩ「proxy.aaa.com」を含む新たなＶｉａヘッダと、接続要求がＵＲＩ「proxy.aaa.com」を経由したことを示すＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを追加し、接続要求メッセージＭ７として、ＳＩＰプロキシＰＲｂに送信する。

ＳＩＰプロキシＰＲｂは、上記接続要求メッセージＭ７を受信すると、受信メッセージのスタートラインから宛先ＵＲＩ「SV1＠bbb.com」を抽出し、図１０に示すように、ロケーションサーバＬＳＶに対して、ロケーションサービスＤＢからの上記宛先ＵＲＩと対応したＩＰアドレスの検索（ロケーションデータ検索）を要求する（Ｓ９）。ＳＩＰプロキシＰＲｂは、ロケーションサービスＤＢの検索結果を示すロケーションデータ（ＩＰアドレス「sv1＠192.0.2.4」）を受信すると（Ｓ１０）と、上記接続要求メッセージＭ７の要求元ＳＩＰプロキシＰＲａに対して、接続中メッセージＭ８を送信した後、ＩＰアドレス「sv1＠192.0.2.4」で特定される接続先サーバＳＶ１ｂとの間で、相互の認証と暗号化通信用のパラメータ設定のためのＴＬＳネゴシェーション（Ｓ１１）を実行する。

ＳＩＰプロキシＰＲｂは、接続先サーバＳＶ１ｂとの間のＴＬＳネゴシェーションが終了すると、接続要求メッセージＭ７のＲｅｑｕｅｓｔ−ＵＲＩをＩＰアドレス「sv1＠192.0.2.4」に書き換え、自分のＳＩＰ−ＵＲＩ「proxy.bbb.com」を含む新たなＶｉａヘッダと、接続要求がＵＲＩ「proxy.bbb.com」を経由したことを示すＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを追加し、接続要求メッセージＭ９として接続先サーバＳＶ１ｂに送信する。

接続先サーバＳＶ１ｂは、上記接続要求メッセージＭ９に応答して、接続応答メッセージＭ１０を返信する。接続応答メッセージＭ１０は、ヘッダ部Ｍ１０−１とボディ部Ｍ１０−２とからなり、ヘッダ部Ｍ１０−１のスタートラインには、メッセージ種類として、応答メッセージであることを示す「200 OK」を含み、メッセージヘッダ部には接続要求メッセージＭ９と同様の複数項目のヘッダ情報を含む。

また、ボディ部Ｍ１０−２は、例えば、図１４に示すように、接続要求メッセージＭ１０のボディ部Ｍ５−２で提案された２つのトランスフォームペイロード９２−１、９２−２のうち、サーバＳＶ１ｂが選択した１つのトランスフォームペイロード（この例では、EPS-AES）を残している。

ＳＩＰプロキシＰＲｂは、接続応答メッセージＭ１０を受信すると、受信メッセージのヘッダ部から自ＵＲＩを含むＶｉａヘッダを除去し、接続応答メッセージＭ１１に変換して、ＳＩＰプロキシＰＲａに送信する。ＳＩＰプロキシＰＲａは、接続応答メッセージＭ１１を受信すると、受信メッセージのヘッダ部から自ＵＲＩを含むＶｉａヘッダを除去し、接続応答メッセージＭ１２に変換して、要求元クライアントＣＬ１ａに送信する。

要求元クライアントＣＬ１ａは、接続応答メッセージＭ１２を受信すると、受信メッセージのボディ部Ｍ１０−２を解析して、接続先サーバＳＶ１ｂとのＩＰｓｅｃ通信に適用すべきＳＡ情報を決定し、これをＳＡＤＢ３３Ｃに登録した後、接続確認メッセージＭ１３をＳＩＰプロキシＰＲａに送信する。接続確認メッセージＭ１３は、スタートラインに、メッセージ種類「ACK」と、Ｒｅｑｕｅｓｔ−ＵＲＩとしてサーバＳＶ１ｂのＳＩＰ−ＵＲＩを含み、メッセージヘッダ部に、Ｖｉａ、Ｔｏ、Ｆｒｏｍ、Ｃａｌｌ−ＩＤ、ＣＳｅｃ、Ｒｏｕｔｅヘッダを含み、メッセージボディ部は省略されている。Ｒｏｕｔｅヘッダには、接続応答メッセージＭ１２のＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダから抽出されたＵＲＩの値が設定される。

上記接続確認メッセージＭ１３は、ＳＩＰプロキシＰＲａで新たなＶｉａヘッダを追加し、ＳＩＰプロキシＰＲａと対応するＲｏｕｔｅヘッダを除去して、接続確認メッセージＭ１４としてＳＩＰプロキシＰＲｂに転送される。ＳＩＰプロキシＰＲｂは、接続確認メッセージＭ１４に新たなＶｉａヘッダを追加し、ＳＩＰプロキシＰＲｂと対応するＲｏｕｔｅヘッダを除去し、接続確認メッセージＭ１５に変換して接続先サーバＳＶ１ｂに転送する。

サーバＳＶ１ｂが上記接続確認メッセージＭ１５を受信することによって、クライアントＣＬ１ａとサーバＳＶ１ｂは、ＩＰｓｅｃ暗号化を適用したアプリケーション間のデータ通信（Ｓ２０）が可能となる。すなわち、クライアントＣＬ１ａは、サーバＳＶ１ｂへの送信データをＳＡＤＢ３３Ｃに登録されているＳＡ情報に従って暗号化し、これをＩＰパケット形式で送信する。サーバＳＶ１ｂは、クライアントＣＬ１ａからの受信データをＳＡＤＢ３３Ｖに登録されているＳＡ情報に従って復号化し、クライアントＣＬ１ａへの送信データを上記ＳＡ情報に従って暗号化して、ＩＰパケット形式で送信できる。

クライアントＣＬ１ａは、サーバＳＶ１ｂとの間でのデータ通信が終了すると、ＳＩＰプロキシＰＲａに対して、切断要求メッセージＭ２０を送信する。切断要求メッセージＭ２０は、スタートラインに、メッセージ種類「BYE」とサーバＳＶ１ｂのＳＩＰ−ＵＲＩを含み、メッセージヘッダ部に接続確認メッセージＭ１３と同様、Ｖｉａ、Ｔｏ、Ｆｒｏｍ、Ｃａｌｌ−ＩＤ、ＣＳｅｃ、Ｒｏｕｔｅヘッダを含み、メッセージボディ部は省略される。

ＳＩＰプロキシＰＲａは、上記切断要求メッセージＭ２０を受信すると、要求元のクライアントＶＬ１ａに対して、切断中メッセージＭ２１を送信した後、切断要求メッセージＭ２０に新たなＶｉａヘッダを追加し、ＳＩＰプロキシＰＲａと対応するＲｏｕｔｅヘッダを除去し、切断要求メッセージＭ２２として、ＳＩＰプロキシＰＲｂに送信する。切断中メッセージＭ２１は、スタートラインに、メッセージ種類として、要求を実行中であることを示す「110 Trying」を含み、メッセージヘッダ部に、切断要求メッセージＭ２０から抽出されたＶｉａ、Ｔｏ、Ｆｒｏｍ、Ｃａｌｌ−ＩＤ、ＣＳｅｃ等の数項目のヘッダ情報を含み、メッセージボディ部は省略されている。

ＳＩＰプロキシＰＲｂは、上記切断要求メッセージＭ２２を受信すると、ＳＩＰプロキシＰＲａに対して、切断中メッセージＭ２３を送信した後、切断要求メッセージＭ２２に新たなＶｉａヘッダを追加し、ＳＩＰプロキシＰＲｂと対応するＲｏｕｔｅヘッダを除去し、切断要求メッセージＭ２４として、サーバＳＶ１ｂに送信する。

サーバＳＶ１ｂは、切断要求メッセージＭ２４を受信すると、切断応答メッセージＭ２５をＳＩＰプロキシＰＲｂに送信する。切断応答メッセージＭ２５は、スタートラインに、メッセージ種類として、応答を示す「200 OK」を含み、メッセージヘッダ部に、切断要求メッセージＭ２４から抽出されたＶｉａ、Ｔｏ、Ｆｒｏｍ、Ｃａｌｌ−ＩＤ、ＣＳｅｃ等の数項目のヘッダ情報を含み、メッセージボディ部は省略されている。

ＳＩＰプロキシＰＲｂは、切断応答メッセージＭ２５を受信すると、受信メッセージのヘッダ部から自ＵＲＩを含むＶｉａヘッダを除去し、切断応答メッセージＭ２６に変換して、ＳＩＰプロキシＰＲａに送信する。ＳＩＰプロキシＰＲａは、切断応答メッセージＭ２６を受信すると、受信メッセージのヘッダ部から自ＵＲＩを含むＶｉａヘッダを除去し、切断応答メッセージＭ２７に変換して、要求元クライアントＣＬ１ａに送信する。要求元クライアントＣＬ１ａは、上記切断応答メッセージＭ２７を受信すると、ＩＰｓｅｃ暗号化／復号化を終了し、同一または別のアプリケーションによる新たなパケット送信要求を待つ。

次に、図１５〜図２５を参照して、上述した本発明の第１実施例の暗号化データ通信を可能にするクライアントＣＬ１ａ、ＳＩＰサーバＳＩＰａ（ＳＩＰプロキシＰＲａ、レジストラＲＧａ）、サーバＳＶ２ｂの制御動作について説明する。

クライアントＣＬ１ａの暗号エンジン３１Ｃは、アプリケーション４０ＣからサーバＳＶ１ｂのＵＲＬ宛への通信要求を検出すると、上記ＵＲＬとの通信に暗号化処理を適用するか否かの判定を、鍵管理プロセス５０Ｃに要求する。ここで、鍵管理プロセス５０Ｃが暗号化通信適用要と判定した場合、暗号エンジン３１Ｃは、ＤＮＳにより上記ＳＩＰ−ＵＲＩに対応するＩＰアドレスを取得する。そして暗号エンジン３１Ｃは、ＳＡＤＢ（Security Association Data Base）３３Ｃから、上記ＩＰアドレスとの通信に適用すべき暗号鍵などのＳＡ（Security Association）情報を検索し、当該ＳＡ情報を用いてアプリケーション４０ＣからサーバＳＶ１ｂに宛てられた通信データを暗号化したり、サーバＳＶ１ｂからアプリケーション４０Ｃに宛てられた通信データを復号したりする。一方、ＳＡＤＢ３３Ｃに上記ＩＰアドレスとの通信に適用すべきＳＡ情報が未登録の場合、暗号化通信制御部５１Ｃは、アプリケーション４０ＣからサーバＳＶ１ｂに宛てられた通信データや、サーバＳＶ１ｂからアプリケーション４０Ｃに宛てられた通信データを廃棄するよう決定する。

図１５は、クライアントＣＬ１ａにおいて、暗号エンジン３１が発行する暗号化通信適用可否判定の要求に応答して暗号化通信制御部５１Ｃが実行する制御動作のフローチャート１００を示す。

本実施例では、暗号エンジン３１Ｃからの暗号化通信適用要否判定の要求を暗号化通信制御部５１Ｃで処理する。暗号化通信制御部５１は、暗号化通信適用可否判定要求を受信すると、暗号化通信適用可否判定要求が示すＵＲＬに対応する、ＡＯＲ形式のＳＩＰ−ＵＲＩ取得をＳＩＰメッセージ処理部５３Ｃに要求し（ステップ１０１）、ＳＩＰメッセージ処理部５３Ｃからの応答を待つ（１０２）。次に、暗号化通信制御部５１は、ＳＰＤＢ（Security Policy Data Base）３２Ｃを参照して、ＳＩＰメッセージ処理部５３Ｃからの応答に含まれる、上記ＵＲＬに対応するＳＩＰ−ＵＲＩに対する暗号化通信の適用の要否判定する。ここで、暗号化通信を適用すべきと判断した場合、鍵管理プロセス５０Ｃは、ＳＡＤＢ（Security Association Data Base）３３Ｃから、上記ＳＩＰ−ＵＲＩに適用すべき暗号鍵などのＳＡ（Security Association）情報を検索する。ここで、ＳＡＤＢ３３Ｃに当該通信に適用すべきＳＡ情報が未登録の場合、暗号化通信制御部５１Ｃは、通信相手との暗号化パラメータの交換（鍵交換）を実施する。

暗号化通信制御部５１Ｃは、ＤＮＳ等を参照して取得した、上記ＵＲＬが示すＴＣＰ／ＩＰ通信パラメータと、暗号化通信制御部５１Ｃが管理している利用可能なＳＡ情報とに基づいて、図１３に例示した接続要求メッセージのボディ部Ｍ５−２を作成し（ステップ１０３）、該接続要求メッセージボディ部Ｍ５−２と上記ＳＩＰ−ＵＲＩとをＳＩＰメッセージ処理部５３Ｃに渡し（１０４）、ＳＩＰメッセージ処理部５３Ｃからの接続応答メッセージボディ部の受信を待つ（１０５）。

暗号化通信制御部５１Ｃは、ＳＩＰメッセージ処理部５３Ｃから、図１４に例示した接続応答メッセージボディ部Ｍ１０−２を受信すると、受信した接続応答メッセージボディ部を解析し、今回の暗号化通信に使用すべきＳＡ情報を決定し（、ＳＡＤＢ３３Ｃに設定する（１０６）と、暗号エンジン３１Ｃに暗号化通信の適用要否判定結果を通知する（１０７）。

図１６は、暗号化通信制御部５１ＣからＳＩＰ−ＵＲＩ取得を要求された場合、ＳＩＰメッセージ処理部５３Ｃが実行する制御動作のフローチャート１１０を示す。

ＳＩＰメッセージ処理部５３Ｃは、暗号化通信制御部５１ＣからＵＲＬを受信すると、図１２に例示したＡＯＲ取得要求メッセージＭ３を作成し（ステップ１１１）、該メッセージをＴＬS部５２Ｃ、暗号化通信機能部部３０Ｃ、ＮＩＣ部２０Ｃを介して、クライアントＣＬ１ａと同一ドメインに位置するＳＩＰサーバＳＩＰａ（レジストラＲＧａ）宛に送信する（１１２）。このとき、ＴＬＳ部５２Ｃは、レジストラＲＧａとの間でＴＬＳネゴシェーション（図９のＳ５）を実行した後、ＴＬＳ暗号化されたＡＯＲ取得要求メッセージＭ３を暗号化通信機能部３０Ｃ、ＮＩＣ部２０Ｃを介してレジストラＲＧａに送信する。上記ＡＯＲ取得要求メッセージＭ３は、暗号化通信機能部３０Ｃによって、ＳＩＰサーバＳＶ１宛の宛先ＩＰアドレスを含むＩＰヘッダＨ１とＵＤＰ／ＴＣＰヘッダＨ２とが付加され、ＩＰパケット形式でネットワークＮＷ１に送出される。

ＳＩＰメッセージ処理部５３Ｃは、レジストラＲＧａからのＡＯＲ取得応答メッセージを待っており（１１３）、ＡＯＲ取得応答メッセージを受信すると、受信メッセージを解析し（１１４）、ＡＯＲヘッダから接続先サーバに割り当てられたＡＯＲ形式のＳＩＰ−ＵＲＩを抽出する（１１５）。

ＳＩＰメッセージ処理部５３Ｃは、暗号化通信制御部５１Ｃから接続要求メッセージのボディ部とＳＩＰ−ＵＲIとを受信すると、上記ＳＩＰ−ＵＲＩをスタートラインとＴｏヘッダに適用して、ヘッダ部Ｍ５−１と暗号化通信制御部５１Ｃから受信したボディ部Ｍ５−２とからなる接続要求メッセージＭ５を作成する（１１６）。

ＳＩＰメッセージ処理部５３Ｃは、上記接続要求メッセージをＴＳＬ部５２Ｃ、暗号化通信機能部３０Ｃ、ＮＩＣ部２０Ｃを介して、ＳＩＰサーバＳＩＰａのＳＩＰプロキシＰＲａ宛に送信し（１１７）、ＳＩＰプロキシＰＲａからの応答を待つ（１１８）。ＳＩＰプロキシＰＲａから接続中メッセージＭ６を受信した場合は、接続中メッセージ処理（１１９）を実行した後、ＳＩＰプロキシＰＲａからの次の応答を待つ。

ＳＩＰメッセージ処理部５３Ｃは、ＳＩＰプロキシＰＲａから接続応答メッセージＭ１２を受信すると、受信メッセージを解析し（１２０）、受信メッセージから抽出した図１４に例示した接続応答メッセージボディ部Ｍ１２−２を暗号化通信制御部５１Ｃに渡す（１２１）。この後、ＳＩＰメッセージ処理部５３Ｃは、図２７に例示した接続確認メッセージＭ１３を作成し、これをＴＳＬ部５２Ｃ、暗号化通信機能部３０Ｃ、ＮＩＣ部２０Ｃを介して、ＳＩＰプロキシＰＲａ宛に送信し（１２２）、このルーチンを終了する。

図１７は、ＡＯＲ取得要求メッセージＭ３を受信した時、レジストラＲＧａのＳＩＰメッセージ処理部５３Ｒが実行する制御動作のフローチャート２００を示す。レジストラＲＧａのＳＩＰメッセージ処理部５３Ｒは、受信したＡＯＲ取得要求メッセージＭ３を解析し（ステップ２０１）、Ｔｏヘッダが示す接続先サーバＳＶ１ｂのＵＲＬを検索キーとして、ロケーションデータ検索クエリを作成し（２０２）、レジストラ処理部６０Ｒを介して、上記検索クエリをロケーションサーバＬＳＶに送信し（２０３）、ロケーションサーバからの応答を待つ（２０４）。

ＳＩＰメッセージ処理部５３Ｒは、レジストラ処理部６０Ｒを介して、ロケーションサーバＬＳＶからロケーションデータを受信すると、受信データが示すＳＩＰ−ＵＲＩをＡＯＲヘッダとして含む図１２に例示したＡＯＲ取得応答メッセージＭ４を作成し（２０５）、該メッセージＭ４を暗号化通信機能部３０Ｒ、ＮＩＣ部２０Ｒを介してＡＯＲ取得要求メッセージＭ３の送信元（この例では、クライアントＣＬ１ａ）に送信し（２０６）、このルーチンを終了する。

図１８は、クライアントＣＬ１ａから接続要求メッセージＭ５を受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作のフローチャート３００を示す。ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐは、クライアントＣＬ１ａからの接続要求メッセージＭ５を受信すると、受信メッセージを解析し（ステップ３０１）、受信メッセージのスタートラインに記述されたＲｅｑｕｅｓｔ−ＵＲＩをチェックして（３０２）、上記Ｒｅｑｕｅｓｔ−ＵＲＩが示すドメイン名から、受信メッセージの転送先を判定する（３０３）。

受信メッセージの転送先が他のドメインに所属していると判定された場合、ＳＩＰメッセージ処理部５３Ｐは、ＤＮＳ検索（ＮＡＰＴＲ検索＋ＳＲＶ検索＋Ａ検索）等によって、受信メッセージの転送先ドメインのＳＩＰサーバ（ＳＩＰプロキシ）を決定する（３０４）。図９で示した例では、ＤＮＳ検索によって、接続要求メッセージＭ５の転送先が、ＳＩＰプロキシＰＲｂであることが判明する。この場合、ＳＩＰメッセージ処理部５３Ｐは、図１９で例示した接続中メッセージＭ６をＴＬＳ部５２Ｐ、暗号化通信機能部３０Ｐ、ＮＩＣ部２０Ｐを介して、接続要求メッセージＭ５の送信元であるクライアントＣＬ１ａに送信（３０５）した後、接続要求メッセージＭ５に新たなＶｉａヘッダを付加した形の接続要求メッセージＭ７をＳＩＰプロキシＰＲｂに転送して（３０６）、ＳＩＰプロキシＰＲｂからの応答を待つ（３０７）。

ＳＩＰメッセージ処理部５３Ｐは、ＳＩＰプロキシＰＲｂから接続中メッセージＭ８を受信すると、接続中メッセージ処理（３０８）を実行した後、ＳＩＰプロキシＰＲｂからの次の応答を待つ。ＳＩＰメッセージ処理部５３Ｐは、ＳＩＰプロキシＰＲｂから接続応答メッセージＭ１１を受信すると、受信メッセージを解析し（３０９）、受信メッセージから自ＳＩＰ−ＵＲＩを含むＶｉａヘッダを除去し、接続応答メッセージＭ１２として、接続要求元（クライアントＣＬ１ａ）に転送する（３１０）。この後、ＳＩＰメッセージ処理部５３Ｐは、接続要求元（クライアントＣＬ１ａ）からの応答を待つ（３１１）。ＳＩＰメッセージ処理部５３Ｐは、接続確認メッセージＭ１３を受信すると、受信メッセージを解析し（３１２）、受信メッセージに自分のＳＩＰ−ＵＲＩを含む新たなＶｉａヘッダを付加し、接続確認メッセージＭ１３として、ＳＩＰプロキシＰＲｂに転送して（３１３）、このルーチンを終了する。

判定ステップ３０３で、クライアント端末ＣＬ１ａから受信した接続要求メッセージの転送先が、例えば、サーバＳＶ１ａ（またはＳＶ２ａ）のように、ＳＩＰプロキシＰＲａと同一ドメインに所属していると判定された場合、ＳＩＰメッセージ処理部５３Ｐは、受信メッセージのＲｅｑｕｅｓｔ−ＵＲＩが示すＳＩＰ−ＵＲＩを検索キーとするロケーションデータ（ＩＰアドレス）検索クエリを作成し（３１５）、該ロケーションデータ検索クエリをロケーションサーバＬＳＶに送信して（３１６）、ロケーションサービス応答を待つ（３１７）。

ＳＩＰメッセージ処理部５３Ｐは、ロケーションサーバＬＳＶからロケーションデータを受信すると、上記ロケーションデータが示す接続先サーバのＩＰアドレスを宛先ＩＰアドレスに適用して、接続要求メッセージをＩＰパケット形式でネットワークＮＷ１に送信し（３１８）、接続先サーバからの応答を待つ（３１９）。上記接続要求メッセージには、ＳＩＰプロキシＰＲａのＳＩＰ−ＵＲＩを含む新たなＶｉａヘッダが付加されている。

接続先サーバから接続応答メッセージを受信すると、ＳＩＰメッセージ処理部５３Ｐは、受信メッセージを解析し（３２０）、自分と対応するＶｉａヘッダを除去した形の接続応答メッセージを接続要求元に転送して（３２１）、接続要求元（クライアントＣＬ１ａ）からの応答を待つ（３２２）。ＳＩＰメッセージ処理部５３Ｐは、接続要求元から接続確認メッセージを受信すると、受信メッセージを解析し（３２３）、新たなＶｉａヘッダを付加した形の接続確認メッセージを接続先サーバに転送して（３２４）、このルーチンを終了する。

図１９は、接続先サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓが、ＳＩＰプロキシＰＲｂから接続要求メッセージＭ９を受信した時に実行する制御動作のフローチャート４００を示す。ＳＩＰプロキシＰＲｂから接続先サーバＳＶ１ｂに送信された接続要求メッセージＭ９は、ＴＬＳ部５２Ｓで復号した後、ＳＩＰメッセージ処理部５３Ｓに入力される。ＳＩＰメッセージ処理部５３Ｓは、接続要求メッセージＭ９を受信すると、受信メッセージを解析し（ステップ４０１）、受信メッセージから抽出した接続要求メッセージボディ部Ｍ５−２を暗号化通信制御部５１Ｓに渡し（４０２）、暗号化通信制御部５１Ｓからの応答を待つ（４０３）。

ＳＩＰメッセージ処理部５３Ｓは、暗号化通信制御部５１Ｓから接続応答メッセージボディ部Ｍ１０−２を受信すると、図２５に例示した接続応答メッセージＭ１１を作成する（４０４）。ＳＩＰメッセージ処理部５３Ｓは、ＴＬＳ部、暗号化通信機能部部、ＮＩＣ部を介して、上記接続応答メッセージＭ１１をＳＩＰプロキシＰＲｂに転送し（４０５）、ＳＩＰプロキシＰＲｂからの応答を待つ（４０６）。ＳＩＰメッセージ処理部５３Ｓは、ＳＩＰプロキシＰＲｂから、接続確認メッセージＭ１５を受信すると、受信メッセージを解析し（４０７）、接続確認メッセージＭ１５を受信したことを暗号化通信制御部５１Ｓに通知して（４０８）、このルーチンを終了する。

図２０は、ＳＩＰメッセージ処理部５３Ｓから接続要求メッセージボディ部Ｍ５−２を受信した時、サーバＳＶ１ｂの暗号化通信制御部５１Ｓが実行する制御動作の示すフローチャート４２０を示す。

暗号化通信制御部５１Ｓは、ＳＩＰメッセージ処理部５３Ｓから受信した接続要求メッセージボディ部Ｍ５−２を解析し（ステップ４２１）、接続要求メッセージボディ部Ｍ５−２に記述されたＳＡ情報（図１３の例では、トランスフォームペイロード９２−１、９２−２）から、クライアントとの暗号化通信に適用すべきＳＡを選択して、図１４に例示した接続応答メッセージのボディ部Ｍ１０−２を作成する（４２２）。暗号化通信制御部５１Ｓは、上記接続応答メッセージボディ部Ｍ１０−２をＳＩＰメッセージ処理部５３Ｓに渡し（４２３）、ＳＩＰメッセージ処理部５３Ｓからの応答を待つ（４２４）。暗号化通信制御部５１Ｓは、ＳＩＰメッセージ処理部５３Ｓから接続確認メッセージの受信通知を受けると、ＳＡＤＢ３３ＳにＳＡ情報を設定して（４２５）、このルーチンを終了する。

図２１は、クライアントＣＬ１ａにおいて、暗号エンジン３１Ｃが発行する通信終了要求に応答して暗号化通信制御部５１Ｃが実行する制御動作のフローチャート１３０を示す。クライアントＣＬ１ａのユーザが、サーバＳＶ１ｂと交信していたアプリケーションを終了すると、暗号エンジン３１Ｃから暗号化通信制御部５１Ｃに、通信終了要求が発行される。ＳＡ／ＳＰ制御部５１Ｃは、暗号エンジン３１Ｃから通信終了要求を受信すると、ＳＩＰメッセージ処理部５３Ｃに、切断要求メッセージの発行を要求し（１３１）、ＳＩＰメッセージ処理部５３Ｃからの応答を待つ（１３２）。ＳＡ／ＳＰ制御部５１Ｃは、ＳＩＰメッセージ処理部５３Ｃから切断応答メッセージの受信通知を受けると、上記暗号鍵消去要求と対応するＳＡＤＢ３３Ｓの設定値を消去し（１３３）、このルーチンを終了する。

図２２は、ＳＡ／ＳＰ制御部５１Ｃから切断要求メッセージの発行要求を受信した時にＳＩＰメッセージ処理部５３Ｃが実行する制御動作のフローチャート１４０を示す。ＳＩＰメッセージ処理部５３Ｃは、ＳＡ／ＳＰ制御部５１Ｃから切断要求メッセージの発行要求を受信すると、切断要求メッセージＭ２０を作成し（ステップ１４１）、ＴＬＳ部５２Ｃ、暗号化通信機能部３０Ｃの暗号エンジン３１Ｃ、ＮＩＣ部２０Ｃを介して、上記切断要求メッセージＭ２０のＩＰパケットをＳＩＰサーバＳＩＰａ（ＳＩＰプロキシＰＲａ）に送信する（１４２）。

ＳＩＰメッセージ処理部５３Ｃは、ＳＩＰプロキシＰＲａからの応答を待ち（１４３）、切断中メッセージＭ２１を受信した場合は、切断中メッセージ処理（１４４）を実行した後、ＳＩＰプロキシＰＲａからの次の応答を待つ。ＳＩＰメッセージ処理部５３Ｃは、ＳＩＰプロキシＰＲａから切断応答メッセージＭ２７を受信すると、受信メッセージを解析し（１４５）、暗号化通信制御部５１Ｃに切断応答メッセージの受信を通知し（１４６）、このルーチンを終了する。

図２３は、クライアントから切断要求メッセージＭ２０を受信した時にＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作のフローチャート３４０を示す。ＳＩＰメッセージ処理部５３Ｐは、受信した切断要求メッセージＭ２０を解析し（ステップ３４１）、受信メッセージのＲｅｑｕｅｓｔ−ＵＲＩをチェックする（３４２）。ＳＩＰメッセージ処理部５３Ｐは、Ｒｅｑｕｅｓｔ−ＵＲＩに記述されたドメイン名から、受信メッセージの転送先を判定し（３４３）、転送先が他のドメインに所属していると判定された場合、ＤＮＳ検索（ＮＡＰＴＲ検索＋ＳＲＶ検索＋Ａ検索）等によって、受信メッセージの転送先ドメインのＳＩＰサーバ（ＳＩＰプロキシ）を決定する（３４４）。

図１０で示した例では、上記ＤＮＳ検索によって、切断要求メッセージＭ２０の転送先が、ＳＩＰプロキシＰＲｂであることが判明する。この場合、ＳＩＰメッセージ処理部５３Ｐは、ＴＬＳ部５２Ｐ、暗号化通信機能部３０Ｐ、ＮＩＣ部２０Ｐを介して、切断要求メッセージＭ２０の送信元であるクライアントＣＬ１ａに、切断中メッセージＭ２１を送信（３４５）した後、切断要求メッセージＭ２０に新たなＶｉａヘッダを付加し、ＳＩＰプロキシＰＲａに対応するＲｏｕｔｅヘッダを除去した切断要求メッセージＭ２２をＳＩＰプロキシＰＲｂに転送し（３４６）、ＳＩＰプロキシＰＲｂからの応答を待つ（３４７）。

ＳＩＰメッセージ処理部５３Ｐは、ＳＩＰプロキシＰＲｂから切断中メッセージＭ２３を受信すると、切断中メッセージ処理（３４８）を実行した後、ＳＩＰプロキシＰＲｂからの次の応答を待つ。ＳＩＰメッセージ処理部５３Ｐは、ＳＩＰプロキシＰＲｂから切断応答メッセージＭ２６を受信すると、受信メッセージを解析し（３４９）、受信メッセージから自ＳＩＰ−ＵＲＩを含むＶｉａヘッダを除去し、切断応答メッセージＭ２７として、切断要求元（クライアントＣＬ１ａ）に転送し（３５０）、このルーチンを終了する。

尚、判定ステップ３４３で、もし、クライアント端末ＣＬ１ａから受信した切断要求メッセージＭ２０の転送先が、ＳＩＰプロキシＰＲａと同一ドメインに所属していると判定された場合、ＳＩＰメッセージ処理部５３Ｐは、受信メッセージのＲｅｑｕｅｓｔ−ＵＲＩが示すＳＩＰ−ＵＲＩを検索キーとするロケーションデータ（ＩＰアドレス）検索クエリを作成し（３５１）、該検索クエリをロケーションサーバＬＳＶに送信して（３５２）、ロケーションサービス応答を待つ（３５３）。

ＳＩＰメッセージ処理部５３Ｐは、ロケーションサーバＬＳＶからロケーションデータを受信すると、上記ロケーションデータが示すサーバＩＰアドレスを宛先ＩＰアドレスに適用して、切断要求メッセージのＩＰパケットをネットワークＮＷ１に送信し（３５４）、サーバからの応答を待つ（３５５）。尚、上記切断要求メッセージには、ＳＩＰプロキシＰＲａのＳＩＰ−ＵＲＩを含む新たなＶｉａヘッダが付加されている。切断要求メッセージの宛先サーバから切断応答メッセージを受信すると、ＳＩＰメッセージ処理部５３Ｐは、受信メッセージを解析し（３５６）、自分のＶｉａヘッダを除去した切断応答メッセージを切断要求元に転送し（３５７）、このルーチンを終了する。

図２４は、ＳＩＰプロキシから切断要求メッセージＭ２４を受信した時、サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓが実行する制御動作のフローチャート４３０を示す。ＳＩＰメッセージ処理部５３Ｓは、ＴＬＳ部５２Ｓを介して切断要求メッセージＭ２４を受信すると、受信メッセージを解析し（ステップ４３１）、暗号化通信制御部５１Ｓに対して、切断すべき通信の識別情報（例えば、Ｃａｌｌ−ＩＤ）を指定して、切断要求の受信を通知し（４３２）、暗号化通信制御部５１Ｓからの応答を待つ（４３３）。ＳＩＰメッセージ処理部５３Ｓは、暗号化通信制御部５１Ｓから切断応答を受信すると、切断応答メッセージＭ２５を作成し（４３４）、ＴＬＳ部、暗号化通信機能部、ＮＩＣ部を介してＳＩＰプロキシＰＲｂに転送し（４３５）、このルーチンを終了する。

図２５は、ＳＩＰメッセージ処理部５３Ｓから切断要求の発生を通知された時、暗号化通信制御部５１Ｓが実行する制御動作のフローチャート４４０を示す。暗号化通信制御部５１Ｓは、通知された通信識別情報にもとづいて、ＳＡＤＢ３３Ｓから消去すべきＳＡ情報を特定し（ステップ４４１）、当該ＳＡ情報を消去し（４４２）、このルーチンを終了する。

なお、本実施例では、登録要求メッセージのボディ部にサービス識別情報６５を含め、登録要求メッセージを解析することによって、識別情報管理テーブル６４を更新するようにしている。しかしながら、本発明はこれに限定されず、識別情報管理テーブル６４、あるいはその一部のエントリは、ロケーションサーバＬＳＶの管理者によって予め値が設定されていてもよい。

次に、図２６から図３０を参照して、本発明による暗号化データ通信の第２の実施例について説明する。上述した第１の実施例では、識別情報管理テーブル６４で識別情報とＳＩＰ−ＵＲＩとの関連を検索する場合に検索用のＳＩＰメッセージを使用し、ＳＩＰプロキシＰＲが当該ＳＩＰメッセージのヘッダに基づいて、識別情報管理テーブル６４を検索していた。また、クライアントやサーバと、ＳＩＰサーバとの間の通信はＴＬＳで保護していた。

本発明の第２の実施例では、識別情報管理テーブル６４へのロケーション情報の登録や削除、および識別情報管理テーブル６４の検索を行う、識別情報管理サービス提供部（以下、識別情報管理サービスという）６６が動作する識別情報管理サーバ装置（以下、識別情報管理サーバという）ＩＳＶを、設けたことを特徴とする。 図２９は、識別情報管理サーバＩＳＶの機能構成例を示す。識別情報管理サーバＩＳＶａは、ネットワークインタフェースカード部（ＮＩＣ）２０Iと、暗号化通信機能部３０Iと、鍵管理プロセス部５０Iと、識別情報管理サービス６６からなり、鍵管理プロセス部５０Iが、ＴＬＳ部５２Iと、ＳＩＰメッセージ処理部５３Iとを備え、識別情報管理サービス６６が識別情報管理テーブル６４を備えている。

本発明の第２の実施例におけるネットワーク構成は、図２６に示すように、ＳＩＰサーバＳＩＰａが管理するネットワークＮＷ１と、ロケーションサーバＬＳＶと、ＤＮＳ（Domain Name System）と、識別情報管理サーバＩＳＶと、からなる。

ネットワークＮＷ１には、クライアントＣＬ１ａ、ＣＬ２ａと、サーバＳＶ１ａ、ＳＶ２ａが接続されている。また、ＳＩＰサーバＳＩＰａは、ＳＩＰプロキシＰＲａとレジストラＰＧａとからなっている。

なお、本実施例の識別情報管理サーバＩＳＶには、「agent@aaa.com」というＳＩＰ−ＵＲＩが割り当てられている。本実施例のクライアントＣＬやサーバＳＶは当該ＳＩＰ−ＵＲＩにロケーション登録や登録解除を要求するＳＩＰメッセージを送信することによって、識別情報管理テーブル６４の内容を更新する。また、本実施例のクライアントＣＬやサーバＳＶは上記ＳＩＰ−ＵＲＩにＡＯＲ取得を要求するＳＩＰメッセージを送信することによって、識別情報管理テーブル６４の内容を検索する。

図２７は、本発明の第２の実施例における暗号化通信シーケンス図を示す。図９、図１０と同一符号で示された第１実施例で説明済みのステップとメッセージについては説明を省略する。本発明の第２の実施例では、まず、サーバＳＶ１ａが、クライアントＣＬ１ａからの接続要求に先立って、ＳＩＰサーバＳＩＰａのレジストラＲＧａとの間で、サーバＳＶ１ａの認証と暗号化通信用のパラメータ設定のためのＴＬＳネゴシェーション（Ｓ１）を実行した後、レジストラＲＧｂにロケーション登録要求メッセージＭ１を送信する。

レジストラＲＧａは、上記ロケーション登録要求メッセージＭ１を受信すると、ロケーションサービスＤＢのロケーションサービステーブル６１に、受信メッセージのＦｒｏｍヘッダが示す要求元ＳＩＰ−ＵＲＩ「sv1＠aaa.com」とＣｏｎｔａｃｔヘッダが示す要求元ＩＰアドレス「sv1＠192.0.2.4」との関係を示すロケーションデータを登録し（Ｓ１０１）、データの登録が完了すると（Ｓ１０２）、要求元サーバＳＶ２ａに、ロケーション登録応答メッセージＭ１０２を送信する。

ロケーション登録応答メッセージＭ２を受信したサーバＳＶ１ａは、次に、識別情報管理サーバＩＳＶ宛の識別情報登録メッセージＭ１０１（ＳＩＰメッセージ：ＭＥＳＳＡＧＥ）をＳＩＰサーバＳＩＰａに送信する。

上記識別情報登録メッセージＭ１０１は、例えば、図２８に示すように、スタートラインに、ＳＩＰメッセージの種類を示す「ＭＥＳＳＡＧＥ」と、識別情報管理サーバＩＳＶのＳＩＰ−ＵＲＩである「agent@aaa.com」を含み、Ｖｉａヘッダは、サーバＳＶ１ａのＦＱＤＮの値を示している。また、Ｔｏヘッダには、識別情報管理サーバＩＳＶのＳＩＰ−ＵＲＩである「agent@aaa.com」が設定され、Ｆｒｏｍヘッダには、サーバＳＶ１ａのＳＩＰ−ＵＲＩ「sips:sv1＠aaa.com」が設定されている。さらに、メッセージの有効時間を示すＥｘｐｉｒｅｓヘッダ、後続するメッセージボディ部の長さを示すＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダ、その他のヘッダ情報が含まれる。識別情報登録要求メッセージＭ１０１のメッセージボディ部にはサーバＳＶ１ａのサービス識別情報６５のリストが含まれる。

識別情報登録要求メッセージＭ１０１を受信したＳＩＰサーバＳＩＰａは、上記識別情報登録要求メッセージＭ１０１の宛先である「agent@aaa.com」をキーとしてロケーションデータベースを検索し（Ｓ１０３）、識別情報管理サーバＩＳＶのＩＰアドレス「192.168.0.3」を取得する（Ｓ１０４）と、当該ＩＰアドレスに識別情報登録要求メッセージＭ１０２を送信する（Ｍ１０２）。

識別情報登録要求メッセージＭ１０２を受信した識別情報管理サーバＩＳＶは、当該識別情報登録要求メッセージＭ１０２のボディ部の各サービス識別情報６５を上記識別情報登録要求メッセージＭ１０１の送信元のＳＩＰ−ＵＲＩ「sips:sv1@aaa.com」と関連付けて、識別情報管理テーブル６４に格納すると、図２８に示す、サーバＳＶ１ａ宛の識別情報登録応答メッセージＭ１０３（ＳＩＰメッセージ：２００ ＯＫ）をＳＩＰサーバＳＩＰａに送信する。識別情報登録応答メッセージＭ１０３のスタートラインは、ＳＩＰメッセージの種類として、応答メッセージであることを示す「200 OK」を含み、メッセージヘッダ部には、ロケーション登録要求メッセージＭ１と同一内容のヘッダ情報が設定される。

識別情報登録応答メッセージＭ１０３を受信したＳＩＰサーバＳＩＰａは、上記識別情報登録要求メッセージＭ１０３の送信元である「sips:sv1@aaa.com」に識別情報登録応答メッセージＭ１０４を送信する（Ｍ１０４）。

この状態で、クライアントＣＬ１ａのユーザが、アプリケーションプログラムを立ち上げ、サーバＳＶ１ａのＵＲＬ「http://www.aaa.com/」宛に通信を要求する操作を行った場合、第２の実施例では、クライアントＣＬ１ａが、ＳＩＰサーバＳＩＰａ（レジストラＲＧａ）との間で、クライアントの認証と暗号化通信用のパラメータ設定のためのＴＬＳネゴシェーション（Ｓ４）を実行した後、ＳＩＰサーバＳＩＰａに識別情報管理サーバＩＳＶ宛のＡＯＲ（Address-of-Record）取得要求メッセージ（ＳＩＰメッセージ：ＩＮＦＯ）Ｍ１０５を送信する。

上記ＡＯＲ取得要求メッセージＭ１０５は、例えば、図３０に示すように、スタートラインに、ＳＩＰメッセージ種類を示す「ＩＮＦＯ」と、識別情報管理サーバＩＳＶのＳＩＰ−ＵＲＩである「sips:agent@aaa.com」を含み、Ｖｉａヘッダは、クライアントＣＬ１ａのＦＱＤＮの値を示している。また、Ｔｏヘッダには、クライアントＣＬ１ａの接続相手となるサーバＳＶ１ａのＵＲＬ「http://www.aaa.com/」が設定され、Ｆｒｏｍヘッダには、クライアントＣＬ１ａのＵＲＩ「sips:cl1＠aaa.com」が設定されている。

ＡＯＲ取得要求メッセージＭ１０５を受信したＳＩＰサーバＳＩＰａは、上記識別情報登録メッセージＭ１０５の宛先である「agent@aaa.com」をキーとしてロケーションデータベースを検索し（Ｓ１０５）、識別情報管理サーバＩＳＶのＩＰアドレスを取得する（Ｓ１０６）と、当該ＩＰアドレスに識別情報登録要求メッセージＭ１０５を送信する（Ｍ１０６）。

ＡＯＲ取得要求メッセージＭ１０５を受信した識別情報管理サーバＩＳＶは、ドメイン管理ＤＢのドメイン管理テーブル６４から、受信メッセージのＴｏヘッダが示すＵＲＬ「http://www.bbb.com/」と対応するＡＯＲ（サーバＳＶ１ａのＵＲＩ）の値を検索し、ロケーションデータＡＯＲの検索が完了すると、ＳＩＰサーバＳＩＰａを介して要求元クライアントＣＬ１ａにＡＯＲ取得応答メッセージＭ１０７を送信する。

ＡＯＲ取得応答メッセージＭ１０７は、図３０に示すように、スタートラインに、メッセージ種類が応答メッセージであることを示す「200 OK」を含み、メッセージヘッダ部にはＡＯＲ取得要求メッセージＭ１０５と同一内容のヘッダ情報が記載され、ボディ部には識別情報管理テーブル６４から検索されたサーバＳＶ１ａのＳＩＰ−ＵＲＩの値「sv1＠aaa.com」を示す値が記述されている。

上記ＡＯＲ取得応答メッセージＭ１０７の受信によって接続先サーバＳＶ１ａのＳＩＰ−ＵＲＩを取得したクライアントＣＬ１ａは、ＳＩＰプロキシＰＲａに対して、サーバＳＶ１ａへの接続要求メッセージＭ５を送信する。

以降の動作は、第一の実施例の動作と同じであるので、説明を省略する
尚、実施例では、ＳＩＰメッセージのＲｅｑｕｅｓｔ−ＵＲＩやＴｏヘッダにＩＰアドレスを適用する時、例えば、図１２や図２８の「sips：192.0.2.4」のように記述した。この場合、ＳＩＰメッセージを受信したＳＩＰプロキシ、レジストラまたはサーバ側では、着目フィールドにおける「sips：」に続く文字列が、３桁以下の数字をドットで区切ったＩＰアドレス表記となっているか否かによって、ＳＩＰ−ＵＲＩ記述かＩＰアドレス記述かを判定できる。ＳＩＰ−ＵＲＩ記述かＩＰアドレス記述かを判定を確実にするためは、例えば、「sips：192.0.2.4；id=ipv4」のように、ＵＲＩパラメータを使用して、ＡＯＲ解決を必要とするＳＩＰ−ＵＲＩであることを明示するようにしてもよい。また、例えば、「ipv4：192.0.2.4」のように、着目フィールドでＩＰｖ４（またはＩＰｖ６）というスキームを検出した場合は、その後にＩＰアドレスが記述されているものと約束してもよい。

さらには、実施例では、クライアントのアプリケーションプログラムが接続先サーバのＩＰアドレス宛にパケットを送信する操作を行った場合に、接続先サーバのＩＰアドレスに対応するＳＩＰ−ＵＲＩを取得するためのＡＯＲ取得要求メッセージをＳＩＰサーバに送信するようにしているが、本発明はこれに限定されず、当該アプリケーションプログラムが使用している任意の体系のサービス識別子から、当該サービス識別子に対応する接続先識別子（接続先サーバを識別するためにセッション管理サーバが採用している識別子）を取得するために適用することができる。例えば、クライアントのアプリケーションプログラムが接続先サーバを指定する情報を含むＵＲＬへの接続を要求する操作を行った場合に、当該ＵＲＬに対応するＳＩＰ−ＵＲＩを取得するためのＡＯＲ取得要求メッセージをＳＩＰサーバに送信するようにしてもよい。このとき、前記ＵＲＬは事前にＳＩＰサーバに登録するようにしてもよいし、接続先サーバがロケーション登録を行う際のロケーション登録要求メッセージに当該接続先サーバがアクセス可能なＵＲＬのリストを含めるようにしてもよい。

さらには、実施例では、クライアントやサーバとＳＩＰサーバとの間の通信はＴＬＳによって保護しているが、本発明はこれに限定されず、Ｓ／ＭＩＭＥによって保護してもよい。また、第２の実施例では、クライアントやサーバと識別情報管理サーバＩＳＶとの間でＳ／ＭＩＭＥで保護されたＳＩＰメッセージを送受するようにしても良い。

次に、本発明による暗号化データ通信の第３の実施例について説明する。第３の実施例では、ロケーションサーバや識別情報管理サーバは複数存在し、個々のロケーションサーバや識別情報管理サーバはそれぞれ異なるＳＩＰ−ＵＲＩに関するロケーション情報や識別情報を管理している。

そのため、本第３の実施例では、ロケーション情報や識別情報からＳＩＰ−ＵＲＩを取得するために問い合わせるべきロケーションサーバや識別情報管理サーバを管理ドメインとして記録したドメイン管理テーブル６８を備えたドメイン管理サーバ装置（以下、ドメイン管理サーバという）ＤＳＶを設けたことを特徴とする。

図３５は、ドメイン管理サーバDＳＶの機能構成例を示す。ドメイン管理サーバDＳＶは、ネットワークインタフェースカード部（ＮＩＣ）２０Dと、暗号化通信機能部３０Dと、鍵管理プロセス部５０Dと、ドメイン管理サービス提供部（以下、ドメイン管理サービスという）６７からなり、鍵管理プロセス部５０Dが、ＴＬＳ部５２Dを備え、ドメイン管理サービス６７がドメイン管理テーブル６８を備えている。

図３１は、本実施例が適用されるシステム構成の１例を示す。

ここに示したシステムは、ＳＩＰサーバＳＩＰａが管理する第１ドメインを形成する第１のネットワークＮＷ１と、ＳＩＰサーバＳＩＰｂが管理する第２ドメインを形成する第２のネットワークＮＷ２と、ＳＩＰサーバＳＩＰａがロケーション情報を記録するロケーションサーバＬＳＶａと、ＳＩＰサーバＳＩＰｂがロケーション情報を記録するロケーションサーバＬＳＶｂと、ＳＩＰサーバＳＩＰａが識別情報を記録する識別情報管理サーバＩＳＶａと、ＳＩＰサーバＳＩＰｂが識別情報を記録する識別情報管理サーバＩＳＶｂと、ＳＩＰサーバＳＩＰａに管理ドメインの情報（ドメイン情報）を提供するドメイン管理サーバＤＳＶａと、ＳＩＰサーバＳＩＰｂにドメイン情報を提供するドメイン管理サーバＤＳＶｂと、からなる。

第１のネットワークＮＷ１には、クライアントＣＬ１ａ、ＣＬ２ａと、サーバＳＶ１ａ、ＳＶ２ａが接続され、第２のネットワークＮＷ２には、クライアントＣＬ１ｂ、ＣＬ２ｂと、サーバＳＶ１ｂ、ＳＶ２ｂが接続されている。また、ＳＩＰサーバＳＩＰａは、ＳＩＰプロキシＰＲａとレジストラＰＧａとからなり、ＳＩＰサーバＳＩＰｂは、ＳＩＰプロキシＰＲｂとレジストラＰＧｂとからなっている。

なお、本実施例の識別情報管理サーバＩＳＶａには「agent@aaa.com」というＳＩＰ−ＵＲＩが、識別情報管理サーバＩＳＶｂには「agent@bbb.com」というＳＩＰ−ＵＲＩが、それぞれ割り当てられている。

図３２は、本第３の実施例における暗号化通信シーケンスを示した図である。図９、図１０、図２７と同一符号で示された第１および第２の実施例で説明済みのステップとメッセージについては説明を省略する。

なお、本第３の実施例で暗号化通信を確立、または、切断するためにクライアントＣＬ、ＳＩＰサーバＳＩＰ、識別情報管理サーバＩＳＶ、サーバＳＶの間で送受されるメッセージは、非特許文献３で定義されたＳＩＰメッセージに準拠したメッセージであり、ＳＩＰメッセージのボディに暗号化通信設定など暗号化通信を確立、または、切断するための情報を格納している。

本第３の実施例では、まず、サーバＳＶ１ｂに電源が投入され、プロセッサ１１が鍵管理プロセス５０Ｓの処理を開始すると、サーバＳＶ１ｂのＴＬＳ部５２ＳがレジストラＲＧｂとの間でＴＬＳネゴシェーション（Ｓ１）を実行し、ＴＬＳセッションが確立すると、ＳＩＰメッセージ処理部５３ＳがレジストラＲＧｂにロケーション登録要求メッセージ（ＳＩＰメッセージ：ＲＥＧＩＳＴＥＲ）Ｍ１を送信して、ロケーションサーバのロケーションサービステーブル６１にロケーションデータを登録する（Ｓ１０１）。さらに、ＳＩＰメッセージ処理部５３Ｓは識別情報管理サーバＩＳＶ宛の識別情報登録メッセージ（ＳＩＰメッセージ：ＭＥＳＳＡＧＥ）Ｍ１０１をＳＩＰサーバＳＩＰｂに送信し、識別情報管理テーブル６４にサービス識別情報６５を格納する。

図３３は、本実施例のロケーションサーバＬＳＶｂ、識別情報管理サーバＩＳＶｂ、ドメイン管理サーバDＳＶａが管理している、ロケーションサービステーブル６１、識別情報管理テーブル６４、ドメイン管理テーブル６８の一例を示す図である。ロケーションサービステーブル６１のエントリ（ＥＮ−３）には、サーバＳＶ１ｂのIPアドレス（192.168.2.4）がサーバＳＶ１ｂのＳＩＰ−ＵＲＩ（sv1@bbb.com）と関連付けて登録されている。また、図３３の識別情報管理テーブル６４のREN-1、REN-2には、サーバＳＶ１ｂの識別情報として、「http://www.bbb.com」や「ftp://ftp.bbb.com/」がサーバＳＶ１ｂのＳＩＰ−ＵＲＩ（sv1@bbb.com）と関連付けて登録されている。

同様に、クライアントＣＬ１ａもレジストラＲＧａとの間でＴＬＳネゴシェーションを実行し、ロケーションサーバＬＳＶａ、識別情報管理サーバＩＳＶａにロケーション情報、識別情報を登録する。

上述のように、本実施例では、サーバＳＶやクライアントＣＬの電源が投入されると自動的にロケーションサービステーブル６１や識別情報管理テーブル６４が最新の状態に更新されるようにしている。

なお、本実施例では、サーバＳＶやクライアントＣＬは、ロケーション登録要求メッセージや識別情報登録メッセージの応答メッセージに記載されている有効期間が過ぎる前に、ロケーション登録要求メッセージおよび識別情報登録メッセージを送信して、再度ロケーションサービステーブル６１や識別情報管理テーブル６４を更新する。このようにすることで、ロケーションサービステーブル６１や識別情報管理テーブル６４が更新されなくなればＳＩＰサーバＳＩＰや識別情報管理サーバＩＳＶはサーバＳＶやクライアントＣＬが動作していないことを知ることができる。

なお、ＳＩＰサーバＳＩＰにロケーション登録要求メッセージを送信してロケーションサービステーブル６１にロケーション情報を登録することを、ＳＩＰサーバＳＩＰにログインする、とも称する。また、ロケーションサービステーブル６１にクライアントＣＬの有効期限が切れていないロケーション情報が登録されている場合、当該クライアントＣＬはログイン中である、とも称する。

また、上述の処理は、サーバＳＶａやクライアントＣＬ１ａの利用者が鍵管理プロセス５０Ｓおよび鍵管理プロセス５０Cにコマンドを与えることにより実行するようにしてもよい。あるいは、利用者がオペレーティングシステム（ＯＳ）にログインした後に、上記処理の実行を利用者に促す画面を表示するようにしても良い。

この状態で、クライアントＣＬ１ａのユーザが、アプリケーションプログラムを立ち上げ、サーバＳＶ１ｂのＵＲＬ「http://www.bbb.com/」宛に通信を要求する操作を行った場合、本第３の実施例では、クライアントＣＬ１ａの暗号化機能部３０Ｃが、当該要求を検出し、暗号化通信制御部５１Ｃに当該通信のためのＳＡ情報の作成を依頼する。暗号化通信制御部５１Ｃは、ＳＩＰメッセージ処理部５３Ｃに指示して、ＳＩＰサーバＳＩＰａに識別情報管理サーバＩＳＶ宛のＡＯＲ取得要求メッセージ（ＳＩＰメッセージ：ＩＮＦＯ）Ｍ１０５を送信する。

ＡＯＲ取得要求メッセージＭ１０５を受信したＳＩＰサーバＳＩＰａは、ＳＩＰメッセージ処理部５３PがＡＯＲ取得要求メッセージＭ１０５の送信先となる識別情報管理サーバＩＳＶを調べるため、ＡＯＲ取得要求メッセージＭ１０５のＴｏヘッダに記載されている内容、すなわち、「http://www.bbb.com/」を検索キーとして、ドメイン管理サーバＤＳＶａにドメイン検索クエリを送信する（S３０１）。

ドメイン検索を要求されたドメイン管理サーバＤＳＶａは、ドメイン情報管理サービス６７がドメイン管理テーブル６８を検索する。

図３３のドメイン管理テーブル６８は、ドメイン管理サーバＤＳＶａが管理しているドメイン管理テーブル６８の一例である。図３３のドメイン管理テーブル６８は、サービス識別情報６５として、「＊」として「任意の文字列」を意味するなど、特殊な役割を持っている文字や文字列を含んだ正規表現の使用が可能であることを特徴とする。たとえば、「http://」で始まり、任意の文字列の後に「.aaa.com/」が含まれるようなサービス識別情報６５は「aaa.com」という管理ドメインで管理されている（DEN-1）。同様に、「１９２．１６８．１０．０のサブネットに属するIPv4アドレス」は「aaa.com」という管理ドメインで管理されている（DEN-２）。また、図３３のドメイン管理テーブル６８は、検索の優先順位が高い順にエントリを上から下に書いていることも特徴とする。例えば、「http://www.bbb.com/cgi-bin/CGI/」というサービス識別情報６５はDEN-4およびDEN-5の両方にマッチするが、優先順位の高いDEN-4にマッチすると判定する。

なお、本実施例では、ドメイン管理サーバＤＳＶの管理者は、サービス識別情報とドメインの対応付けや、検索の優先順位を予め決定して、ドメイン管理テーブル６８を作成し、ドメイン管理サーバＤＳＶに登録するようにしている。しかしながら、本発明はこれに限定されるものではなく、ドメイン管理サーバＤＳＶ同士が連携してドメイン管理テーブル６８を更新するようにしても良い。このようにすることで、ドメイン管理テーブル６８の整合性を保つために、ドメイン管理サーバＤＳＶの管理者が他の管理者にドメイン管理テーブル６８の更新を通知する必要がなくなる。

ドメイン管理サーバＤＳＶａのドメイン情報管理サービス６７は、与えられた検索キーが含まれるサービス識別情報６５が存在するか否かをドメイン管理テーブル６８のエントリを上から下に向かって検索する。「http://www.bbb.com/」の場合には、DEN-5にマッチするため、「bbb.com」という管理ドメインで管理されていると判定する。

ドメイン情報管理サービス６７はドメイン検索結果をＳＩＰサーバＳＩＰａに返す（Ｓ３０２）。

ＳＩＰサーバＳＩＰａのＳＩＰメッセージ処理部５３Ｐは、ドメイン管理サーバＤＳＶａから受信したドメイン検索結果が自分の管理ドメインと異なる管理ドメインを示していた場合には、当該管理ドメインの識別情報管理サーバＩＳＶ宛のＡＯＲ取得要求メッセージＭ３０１を作成し、当該管理ドメインのＳＩＰサーバにＡＯＲ取得要求メッセージＭ３０１を送信する。具体的には、ＡＯＲ取得要求メッセージＭ３０１は、ＡＯＲ取得要求メッセージＭ１０５のスタートラインに記載されている、識別情報管理サーバＩＳＶのＳＩＰ−ＵＲＩを、上記ドメイン検索結果に含まれている管理ドメイン「bbb.com」を管理する識別情報管理サーバＩＳＶのＳＩＰ−ＵＲＩ「sips:agent@bbb.com」に置き換えたものであり、ＳＩＰサーバＳＩＰａはＡＯＲ取得要求メッセージＭ３０１をＳＩＰサーバＳＩＰｂに送信する。

ＡＯＲ取得要求メッセージＭ３０１を受信したＳＩＰサーバＳＩＰｂは、ＳＩＰメッセージ処理部５３Ｐで、ＡＯＲ取得要求メッセージＭ３０１の送信先となる識別情報管理サーバＩＳＶを調べるため、ＡＯＲ取得要求メッセージＭ３０１のＴｏヘッダに記載されている内容、すなわち、「http://www.bbb.com/」を検索キーとして、ドメイン管理サーバＤＳＶｂにドメイン検索クエリを送信する（S３０３）。

ドメイン検索を要求されたドメイン管理サーバＤＳＶｂは、ドメイン情報管理サービス６７がドメイン管理テーブル６８を検索し、ドメイン検索結果をＳＩＰサーバＳＩＰｂに返す（Ｓ３０４）。なお、検索キーが「http://www.bbb.com/」の場合にはDEN-5に従い「bbb.com」が返される。

ＳＩＰサーバＳＩＰｂは、ＳＩＰメッセージ処理部５３Ｐがドメイン管理サーバＤＳＶｂから受信したドメイン検索結果が自分の管理ドメインと同じ管理ドメインであるため、ＡＯＲ取得要求メッセージＭ３０１を識別情報管理サーバＩＳＶｂに送信する。

ＡＯＲ取得要求メッセージＭ３０１を受信した識別情報管理サーバＩＳＶｂは、識別情報管理サーバ６６が識別情報管理ＤＢの識別情報管理テーブル６４から、受信メッセージのＴｏヘッダが示すＵＲＬ「http://www.bbb.com/」と対応するＡＯＲ（サーバＳＶ１ｂのＳＩＰ−ＵＲＩ）の値を検索し、検索結果である「sv1@bbb.com」を取得すると、ＳＩＰサーバＳＩＰｂとＳＩＰサーバＳＩＰａとを介して要求元クライアントＣＬ１ａにＡＯＲ取得応答メッセージＭ１０７を送信する。

上記ＡＯＲ取得応答メッセージＭ１０７の受信によって接続先サーバＳＶ１ａのＳＩＰ−ＵＲＩ「sv1@bbb.com」を取得したクライアントＣＬ１ａは、ＳＩＰメッセージ処理部５３CがＳＩＰプロキシＰＲａに対して、サーバＳＶ１ａへの接続要求メッセージＭ５を送信する。

以降の動作は、第１の実施例の動作に倣うので、説明を省略する。

以下、図３２におけるＳＩＰサーバおよび識別情報管理サーバがＡＯＲ取得要求メッセージを受信した場合の制御動作について説明する。

図３６は、図３２においてＳＩＰサーバＳＩＰａがＡＯＲ取得要求メッセージＭ１０５を受け取った場合の動作を示したフロー図である。なお、ＳＩＰサーバＳＩＰｂがＡＯＲ取得要求メッセージＭ３０１を受信した場合も同じ動作を行う。

ＡＯＲ取得要求メッセージＭ１０５を受信したＳＩＰサーバＳＩＰａは、ＳＩＰメッセージ処理部５３ＰがＡＯＲ取得要求メッセージＭ１０５を解析し（５０１）、ＡＯＲ取得要求メッセージＭ１０５のＴｏヘッダに記載された内容に基づいてＳＱＬなどによりドメイン検索クエリを作成する（５０２）。次に、ＳＩＰメッセージ処理部５３Pは、作成したドメイン検索クエリをドメイン管理サーバＤＳＶａに送信する（５０３、Ｓ３０１（ＳＩＰサーバＳＩＰｂの場合はＳ３０３））と、ドメイン管理サーバＤＳＶａからの応答を待ち受ける（５０４）。

ＳＩＰメッセージ処理部５３Pがドメイン検索結果を受け取る（Ｓ３０２（ＳＩＰサーバＳＩＰｂの場合はＳ３０４））と、ドメイン検索結果を解析し、ＡＯＲ取得要求メッセージＭ１０５の転送先を決定する（５０５）。

転送先が他の管理ドメインである場合には、ＡＯＲ取得要求メッセージＭ１０５の転送先ドメインのＳＩＰサーバを決定し（５０７）、ＡＯＲ取得要求メッセージＭ１０５からＡＯＲ取得要求メッセージＭ３０１を作成すると、転送先ドメインのＳＩＰサーバにＡＯＲ取得要求メッセージＭ３０１を送信し（５０８）、応答を待ち受ける（５０９）。

ＡＯＲ取得応答メッセージＭ１０７を受信したＳＩＰサーバＳＩＰａは、ＳＩＰメッセージ処理部５３ＰがＡＯＲ取得応答メッセージＭ１０７を解析し（５１０）、ＡＯＲ取得要求メッセージＭ１０５の送信元にＡＯＲ取得要求メッセージＭ１０７を送信して（５１１）、処理を終了する。

一方、ステップ５０５で、転送先が自管理ドメインであった場合には、識別情報管理サーバＩＳＶａにＡＯＲ取得要求メッセージＭ１０５を送信し（５１２）、識別情報管理サーバＩＳＶａからの応答を待ち受ける（５１３）。

ＳＩＰサーバＳＩＰａは識別情報管理サーバＩＳＶａからＡＯＲ取得応答メッセージＭ１０７を受信すると、ＡＯＲ取得要求メッセージＭ１０５の送信元にＳＩＰメッセージ処理部５３ＰがＡＯＲ取得応答メッセージＭ１０７を送信して（５１４）、処理を終了する。

図３７は、図３２において識別情報管理サーバＩＳＶｂがＡＯＲ取得要求メッセージＭ３０１を受信した場合の動作を示したフロー図である。

識別情報管理サーバＩＳＶｂがＡＯＲ取得要求メッセージＭ３０１を受信する（６００）と、識別情報管理サーバＩＳＶｂのＳＩＰメッセージ処理部５３ＩがＡＯＲ取得要求メッセージＭ３０１を解析し、ＡＯＲ取得要求メッセージＭ３０１のＴｏヘッダに記載されている内容を識別情報管理サービス６６に渡す（６０１）。識別情報管理サービス６６は受け取ったＴｏヘッダの記載内容から識別情報検索クエリを作成し（６０２）、識別情報管理ＤＢの識別情報管理テーブル６４を検索する（６０３）。

識別情報管理サービス６６は、識別情報管理ＤＢから検索結果を受信すると、検索結果を解析し、ＡＯＲ６２をＳＩＰメッセージ処理部５３Ｉに渡す（６０５）。

ＡＯＲ６２を受信したＳＩＰメッセージ処理部５３Ｉは、ＡＯＲ取得応答メッセージＭ１０７を作成し（６０５）、ＡＯＲ取得要求メッセージM３０１の送信元にＡＯＲ取得応答メッセージＭ１０７を送信する（６０６）。

以上が本第３の実施例におけるＳＩＰサーバおよび識別情報管理サーバがＡＯＲ取得要求メッセージを受信した場合の制御動作である。

本第３の実施例では、ＡＯＲ取得要求メッセージを受信したＳＩＰサーバはドメイン管理サーバＤＳＶを検索してＡＯＲ取得要求メッセージを送信すべき識別情報管理サーバＩＳＶを決定するように構成している。そのため、クライアントＣＬやサーバＳＶのサービス識別子を複数の識別情報管理サーバＩＳＶで管理することができるので、負荷を分散することが可能となる。

また、本第３の実施例のドメイン管理テーブル６８は、サービス識別情報６５を正規表現で記載できるため、すべてのサービス識別情報６５の管理ドメインを登録する必要がなく、ドメイン管理テーブル６８のサイズが肥大するのを抑えることができる。

なお、本発明は、第３の実施例の構成には限定されず、以下のように構成しても良い。

例えば、ドメイン管理テーブル６８には、すべての種類のサービス識別情報６５を記載した一つのテーブルを使用している。しかし、サービス識別情報６５の種類ごとにドメイン管理テーブル６８を分けてもよい。こうにすることで、高速にサービス識別情報６５の管理ドメインを検索することができる。

また、ドメイン管理テーブル６８には、サービス識別情報６５の管理ドメインを検索するごとに、エントリ毎にサービス識別情報６５が正規表現に一致するかを計算している。しかし、ドメイン管理サーバＤＳＶの起動時にドメイン管理テーブル６８の各エントリを計算して、すべてのサービス識別情報６５のエントリに展開し、テーブルやツリーとしてメモリ上に保持してもよい。こうにすることで、高速にサービス識別情報６５の管理ドメインを検索することができる。

さらには、ドメイン管理テーブル６８では、各エントリの管理ドメイン情報は、当該エントリのサービス識別情報６５を管理している管理ドメインを記載するようにしている。しかし、ドメイン管理サーバＤＳＶを階層型に構築し、ドメイン管理テーブル６８のエントリが自ドメイン以外の管理ドメインの場合に、当該管理ドメインが下位のドメイン管理サーバＤＳＶで管理されている場合には、下位のドメイン管理サーバＤＳＶの管理ドメインを、それ以外の場合には上位のドメイン管理サーバＤＳＶの管理ドメインを、記載してもよい。こうにすることで、ドメイン管理テーブル６８の管理が容易になる。

また、ＳＩＰサーバＳＩＰとドメイン管理サーバＤＳＶは、ドメイン検索クエリおよびその応答をＴＬＳによって直接送受している。しかし、ドメイン検索クエリおよびその応答をＳＩＰメッセージのボディ部に格納して送受してもよい。

次に、本発明による暗号化データ通信の第４の実施例について説明する。第４の実施例では、識別情報管理サーバＩＳＶがドメイン管理サーバＤＳＶを検索する。

本第４の実施例のネットワーク構成は、上述した第３の実施例と同じであるので説明を省略する。

次に、本第４の実施例の動作について説明する。第４の実施例でクライアントＣＬ、ＳＩＰサーバＳＩＰ、識別情報管理サーバＩＳＶ、サーバＳＶの間で送受されるメッセージは、非特許文献３で定義されたＳＩＰメッセージに準拠したメッセージであり、ＳＩＰメッセージのボディに暗号化通信設定など暗号化通信を確立、または切断するための情報を格納している。

まず、サーバＳＶ１ｂやクライアントＣＬ１ａのＴＬＳ部５２がレジストラＲＧとの間でＴＬＳネゴシェーションを実行し、ＴＬＳセッションを確立すると、ＳＩＰメッセージ処理部５３がロケーションサーバＬＳＶ、識別情報管理サーバＩＳＶにロケーション情報、識別情報を登録する。当該処理の詳細は、上述した第３の実施例に倣うので説明を省略する。

次に、クライアントＣＬ１ａのユーザが、アプリケーションプログラムを立ち上げ、サーバＳＶ１ｂのＵＲＬ「http://www.bbb.com/」宛に通信を要求する操作を行った場合の動作について説明する。

図３４は、本発明の第４の実施例において、クライアントＣＬ１ａのユーザが、アプリケーションプログラムを立ち上げ、サーバＳＶ１ｂのＵＲＬ「http://www.bbb.com/」宛に通信を要求する操作を行った場合に暗号化通信を確立するためのシーケンス図である。

クライアントＣＬ１ａのユーザが、アプリケーションプログラムを立ち上げ、サーバＳＶ１ｂのＵＲＬ「http://www.bbb.com/」宛に通信を要求する操作を行った場合、クライアントＣＬ１ａの暗号化機能部３０Ｃが、当該要求を検出し、暗号化通信制御部５１Ｃに当該通信のためのＳＡ情報の作成を依頼する。暗号化通信制御部５１Ｃは、ＳＩＰメッセージ処理部５３Ｃに指示して、ＡＯＲ取得要求メッセージ（ＳＩＰメッセージ：ＩＮＦＯ）Ｍ４０１を、ＳＩＰサーバＳＩＰａを介して識別情報管理サーバＩＳＶａに送信し、識別情報管理サーバＩＳＶａからの応答を待ち受ける。

上記ＡＯＲ取得要求メッセージＭ４０１は、例えば、図３８に示すように、スタートラインに、ＳＩＰメッセージ種類を示す「ＩＮＦＯ」と、識別情報管理サーバＩＳＶａのＳＩＰ−ＵＲＩである「sips:agent@aaa.com」を含み、Ｖｉａヘッダは、クライアントＣＬ１ａのＦＱＤＮの値を示している。また、Ｔｏヘッダには、識別情報管理サーバＩＳＶａのＳＩＰ−ＵＲＩ「sips:agent@aaa.com」が設定され、Ｆｒｏｍヘッダには、クライアントＣＬ１ａのＵＲＩ「sips:cl1＠aaa.com」が設定されている。さらに、ＳＩＰメッセージのボディ部にはＡＯＲの取得対象の識別情報「http://www.bbb.com/」が設定されている。

ＡＯＲ取得要求メッセージＭ４０１を受信した識別情報管理サーバＩＳＶａは、識別情報管理サービス６６がＡＯＲ取得要求メッセージＭ４０１のボディ部に記載されている識別情報、すなわち、「http://www.bbb.com/」が識別情報管理テーブル６４に記載されているかを確認する（Ｓ４０１）。

ここで、識別情報が識別情報管理テーブル６４に記載されていた場合には、ＡＯＲ取得応答Ｍ４０４を作成し、ＳＩＰサーバＳＩＰａを介してクライアントＣＬ１ａにＡＯＲ取得応答Ｍ４０４を送信する。ＡＯＲ取得応答メッセージＭ４０４は、図３８に示すように、スタートラインに、メッセージ種類が応答メッセージであることを示す「200 OK」を含み、メッセージヘッダ部にはＡＯＲ取得要求メッセージＭ４０１と同一内容のヘッダ情報が記載され、ボディ部には識別情報管理テーブル６４から検索されたサーバＳＶ１ｂのＳＩＰ−ＵＲＩの値「sv1＠bbb.com」を示す値が記述されている。

一方、Ｓ４０１で識別情報が識別情報管理テーブル６４に記載されていない場合、識別情報管理サービス６６は、上記識別情報を検索キーとして、ドメイン管理サーバＤＳＶａにドメイン検索クエリを送信する（Ｓ４０２）。ドメイン管理サーバＤＳＶａはドメイン情報管理サービス６７がドメイン管理テーブル６８を検索して、検索結果を返す（Ｓ４０３）。

検索結果を受信した識別情報管理サーバＩＳＶａの識別情報管理サービス６６は、ＡＯＲ取得要求メッセージＭ４０２を作成し、ドメイン検索結果に含まれる管理ドメインの識別情報管理サーバＩＳＶ、すなわち識別情報管理サーバＩＳＶｂ（ＳＩＰ−ＵＲＩ：agent@bbb.com）にＳＩＰサーバＳＩＰａおよびＳＩＰサーバＳＩＰｂを介してＡＯＲ取得要求メッセージＭ４０２を送信すると、識別情報管理サーバＩＳＶｂの応答を待ち受ける。

なお、ＡＯＲ取得要求メッセージＭ４０２は、ＡＯＲ取得要求メッセージＭ４０１のスタートラインおよびＴｏヘッダの識別情報管理サーバＩＳＶａのＳＩＰ−ＵＲＩを識別情報管理サーバＩＳＶｂのＳＩＰ−ＵＲＩ「sips:agent@bbb.com」に変更し、ＦｒｏｍヘッダのクライアントＣＬ１ａのＳＩＰ−ＵＲＩを識別情報管理サーバＩＳＶａのＳＩＰ−ＵＲＩ「sips:agent@aaa.com」に変更したものである。

ＡＯＲ取得要求メッセージＭ４０２を受信した識別情報管理サーバＩＳＶｂは、識別情報管理サービス６６がＡＯＲ取得要求メッセージＭ４０１のボディ部に記載されている識別情報が識別情報管理テーブル６４に記載されているかを確認する（Ｓ４０４）。

ここで、識別情報が識別情報管理テーブル６４に記載されていた場合には、識別情報管理サーバＩＳＶｂは、ＡＯＲ取得応答Ｍ４０３を作成し、ＳＩＰサーバＳＩＰｂおよびＳＩＰサーバＳＩＰａを介して識別情報管理サーバＩＳＶａにＡＯＲ取得応答Ｍ４０３を送信する。

ＡＯＲ取得応答メッセージＭ４０３は、スタートラインに、メッセージ種類が応答メッセージであることを示す「200 OK」を含み、メッセージヘッダ部にはＡＯＲ取得要求メッセージＭ４０２と同一内容のヘッダ情報が記載され、ボディ部には識別情報管理テーブル６４から検索されたサーバＳＶ１ｂのＳＩＰ−ＵＲＩの値「sv1＠bbb.com」を示す値が記述されている。

なお、Ｓ４０１で識別情報が識別情報管理テーブル６４に記載されていない場合には、識別情報管理サーバＩＳＶｂは、上記識別情報を検索キーとして、ドメイン管理サーバＤＳＶｂにドメイン検索を要求し、ドメイン検索結果に含まれる管理ドメインの識別情報管理サーバＩＳＶにＡＯＲ取得要求メッセージを送信し、当該識別情報管理サーバＩＳＶの応答を待ち受ける。

ＡＯＲ取得応答Ｍ４０３を受信した識別情報管理サーバＩＳＶａの識別情報管理サービス６６は、ＡＯＲ取得応答Ｍ４０３からＡＯＲ取得応答Ｍ４０４を作成し、ＳＩＰサーバＳＩＰａを介してクライアントＣＬ１ａにＡＯＲ取得応答Ｍ４０４を送信する。

上記ＡＯＲ取得応答メッセージＭ４０４の受信によって接続先サーバＳＶ１ｂのＳＩＰ−ＵＲＩを取得したクライアントＣＬ１ａは、ＳＩＰメッセージ処理部５３がＳＩＰプロキシＰＲａを介して、識別情報管理サーバＩＳＶａにサーバＳＶ１ｂへの接続要求メッセージＭ４０５を送信する。

接続要求メッセージＭ４０５は、図３９に示すように、接続要求メッセージのヘッダ部Ｍ４０５−１とボディ部Ｍ４０５−２とからなり、接続要求メッセージのヘッダ部Ｍ４０５−１は、スタートラインに、メッセージ種類「INVITE」と、Ｒｅｑｕｅｓｔ−ＵＲＩとして、メッセージ宛先となる識別情報管理サーバＩＳＶａのＳＩＰ−ＵＲＩ「agent＠aaa.com」を含む。また、メッセージヘッダ部には、クライアントＣＬ１ａにおけるＳＩＰメッセージ処理部５３ＣのＳＩＰ−ＵＲＩを示すＶｉａヘッダ、識別情報管理サーバＩＳＶａのＳＩＰ−ＵＲＩ「agent＠aaa.com」を含むＴｏヘッダ、クライアントＣＬ１ａのＳＩＰ−ＵＲＩ「cl1＠aaa.com」を含むＦｒｏｍヘッダと、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダ、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダ、その他の情報を含む。Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダは、ボディ部Ｍ５−２が関係するアプリケーションプログラムを示し、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダは、ボディ部Ｍ４０５−２の長さを示している。

接続要求メッセージＭ５のボディ部Ｍ４０５−２は、ＭＩＭＥで定義されたマルチパートの形式で記述されている。例えば、「--BOUNDARY」で囲まれた最初のパートはサーバＳＶ１ｂのＳＩＰ−ＵＲＩを含み、次のパートはクライアントＣＬ１ａとサーバＳＶ１ｂとの間での暗号化通信設定を含む。クライアントＣＬ１ａとサーバＳＶ１ｂとの間での暗号化通信設定は、例えば、図１３に示すような、ＩＫＥにおける通常のＩＰｓｅｃ用ＳＡ設定時と同様、暗号化プロトコルの識別情報を示すプロポーザルペイロード９１と、トランスフォーム識別情報を示すトランスフォームペイロード９２、鍵交換ペイロード９３、要求元の識別情報を示す第１ＩＤペイロード９４と、接続先の識別情報を示す第２ＩＤペイロード９５を含んでいる。

接続要求メッセージＭ４０５を受信した識別情報管理サーバＩＳＶａは、接続要求メッセージＭ４０５から接続要求メッセージＭ４０６を作成し、ＳＩＰサーバＳＩＰａおよびＳＩＰサーバＳＩＰｂを介して識別情報管理サーバＩＳＶｂに接続要求メッセージＭ４０６を送信すると、識別情報管理サーバＩＳＶｂからの応答を待ち受ける。

なお、接続要求メッセージＭ４０６は、接続要求メッセージＭ４０５のＲｅｑｕｅｓｔ−ＵＲＩおよびＴｏヘッダを識別情報管理サーバＩＳＶａのＳＩＰ−ＵＲＩから識別情報管理サーバＩＳＶｂのＳＩＰ−ＵＲＩ「sips:agent@bbb.com」に変更し、ＶｉａヘッダおよびＦｒｏｍヘッダをクライアントＣＬ１ａのＳＩＰ−ＵＲＩから識別情報管理サーバＩＳＶａのＳＩＰ−ＵＲＩ「sips:agent@aaa.com」に変更したものである。

接続要求メッセージＭ４０６を受信した識別情報管理サーバＩＳＶｂは、SIPメッセージ処理部５３Ｉが接続要求メッセージＭ４０６から接続要求メッセージＭ４０７を作成し、ＳＩＰサーバＳＩＰｂを介して接続先サーバＳＶ１ｂに接続要求メッセージＭ４０７を送信すると、接続先サーバＳＶ１ｂからの応答を待ち受ける。

なお、接続要求メッセージＭ４０７は、接続要求メッセージＭ４０６のＲｅｑｕｅｓｔ−ＵＲＩおよびＴｏヘッダを識別情報管理サーバＩＳＶｂのＳＩＰ−ＵＲＩから接続先サーバＳＶ１ｂ「sips:sv1@bbb.com」に変更し、ＶｉａヘッダおよびＦｒｏｍヘッダを識別情報管理サーバＩＳＶａのＳＩＰ−ＵＲＩから識別情報管理サーバＩＳＶｂのＳＩＰ−ＵＲＩ「sips:agent@bbb.com」に変更したものである。

ＳＩＰメッセージ処理部５３Ｓで接続要求メッセージＭ４０７を受信したサーバＳＶ１ｂは、暗号化通信制御部５１Ｓで接続要求メッセージＭ４０７に記載されている暗号通信設定から１つを選択し、暗号化通信機能部３１Sに選択した暗号通信設定を適用すると、ＳＩＰメッセージ処理部５３Ｓが接続応答メッセージＭ４０８をＳＩＰサーバＳＩＰｂを介して識別情報管理サーバＩＳＶｂに返信する。

接続応答メッセージＭ４０８は、図３９に示すように、ヘッダ部Ｍ４０８−１とボディ部Ｍ４０８−２とからなり、ヘッダ部Ｍ４０８−１のスタートラインには、メッセージ種類として、応答メッセージであることを示す「200 OK」を含み、メッセージヘッダ部には接続要求メッセージＭ４０７と同様の複数項目のヘッダ情報を含む。

また、ボディ部Ｍ４０８−２の最初のパートはサーバＳＶ１ｂのＳＩＰ−ＵＲＩが「＜ＡＯＲ＞」と「＜／ＡＯＲ＞」にはさまれて記載されており、さらに、当該接続応答メッセージＭ４０８によって確立される暗号化通信セッションを一意に識別するためのセッション識別情報が「＜ＳＥＳＳＩＯＮ＞」と「＜／ＳＥＳＳＩＯＮ＞」とにはさまれて記載されている。また、ボディ部Ｍ４０８−２の次のパートは、接続要求メッセージＭ４０７のボディ部Ｍ４０７−２で提案された暗号通信設定のうち、サーバＳＶ１ｂが選択した暗号通信設定を含む。

接続応答メッセージＭ４０８を受信した識別情報管理サーバＩＳＶｂは、ＳＩＰメッセージ処理部５３Ｉが接続応答メッセージＭ４０８から接続応答メッセージＭ４０９を作成し、ＳＩＰサーバＳＩＰｂおよびＳＩＰサーバＳＩＰａを介して、識別情報管理サーバＩＳＶａに接続応答メッセージＭ４０９を送信する。

なお、接続応答メッセージＭ４０９は、接続要求メッセージＭ４０６に対する応答メッセージであり、接続応答メッセージＭ４０８からヘッダ部Ｍ４０８−１のスタートラインに続くメッセージヘッダ部を接続要求メッセージＭ４０６と同様のヘッダ情報に置き換えたものである。

接続応答メッセージＭ４０９を受信した識別情報管理サーバＩＳＶａは、ＳＩＰメッセージ処理部５３Ｉが接続応答メッセージＭ４０９から接続応答メッセージＭ４１０を作成し、ＳＩＰサーバＳＩＰａを介して、クライアントＣＬ１ａに接続応答メッセージＭ４１０を送信する。

なお、接続応答メッセージＭ４１０は、接続要求メッセージＭ４０５に対する応答メッセージであり、接続応答メッセージＭ４０９からヘッダ部Ｍ４０９−１のスタートラインに続くメッセージヘッダ部を接続要求メッセージＭ４０５と同様のヘッダ情報に置き換えたものである。

接続応答メッセージＭ４１０を受信したクライアントＣＬ１ａは、暗号化通信制御部５１Cを介して暗号エンジン３１Cに、接続応答メッセージＭ４１０に記載されている暗号通信設定を適用すると、接続先サーバＳＬ１ｂとアプリケーションデータ通信を開始する。

クライアントＣＬ１ａの暗号化通信制御部５１ＳがサーバＳＶ１ｂとの間でのデータ通信が終了したことを検出すると、ＳＩＰメッセージ処理部５３CがＳＩＰサーバＳＩＰａを介して識別情報管理サーバＩＳＶａに対して、図４０に示す切断開始要求メッセージＭ４１１を送信し、通信切断処理を開始する。

なお、切断要求メッセージＭ４１１は、スタートラインに、メッセージ種類「ＵＰＤＡＴＥ」と識別情報管理サーバＩＳＶａのＳＩＰ−ＵＲＩを含み、メッセージヘッダ部には、接続要求メッセージＭ４０５と同様、Ｖｉａ、Ｔｏ、Ｆｒｏｍ、Ｃａｌｌ−ＩＤ、ＣＳｅｃ、Ｒｏｕｔｅヘッダを含み、メッセージボディ部には接続先サーバＳＶ１ｂのＳＩＰ−ＵＲＩと、切断する暗号化通信セッションを一意に識別するためのセッション識別情報と、を含む。

なお、サーバＳＶ１ｂの暗号化通信制御部５１ＳがクライアントＣＬ１ａとの間でのデータ通信が終了したことを検出した場合には、サーバＳＶ１ｂからクライアントＣＬ１ａに切断開始要求メッセージＭ４１１を送信し、切断処理を行う。

図４１は、クライアントＣＬ１ａは、サーバＳＶ１ｂとの間でのデータ通信が終了した場合の通信切断の処理フローを示した図である。

切断開始要求メッセージＭ４１１を受信した識別情報管理サーバＩＳＶａは、ＳＩＰメッセージ処理部５３Ｉが切断開始要求メッセージＭ４１１から切断開始要求メッセージＭ４１２を作成し、ＳＩＰサーバＳＩＰａおよびＳＩＰサーバＳＩＰｂを介して識別情報管理サーバＩＳＶｂに切断開始要求メッセージＭ４１２を送信すると、識別情報管理サーバＩＳＶｂからの応答を待ち受ける。

なお、切断開始要求メッセージＭ４１２は、切断開始要求メッセージＭ４１１のＲｅｑｕｅｓｔ−ＵＲＩおよびＴｏヘッダを識別情報管理サーバＩＳＶａのＳＩＰ−ＵＲＩから識別情報管理サーバＩＳＶｂのＳＩＰ−ＵＲＩ「sips:agent@bbb.com」に変更し、ＶｉａヘッダおよびＦｒｏｍヘッダをクライアントＣＬ１ａのＳＩＰ−ＵＲＩから識別情報管理サーバＩＳＶａのＳＩＰ−ＵＲＩ「sips:agent@aaa.com」に変更したものである。

切断開始要求メッセージＭ４１２を受信した識別情報管理サーバＩＳＶｂは、ＳＩＰメッセージ処理部５３Ｉが切断開始要求メッセージＭ４１２から切断開始要求メッセージＭ４１３を作成し、ＳＩＰサーバＳＩＰｂを介して接続先サーバＳＶ１ｂに切断開始要求メッセージＭ４１３を送信すると、接続先サーバＳＶ１ｂからの応答を待ち受ける。

なお、切断開始要求メッセージＭ４１３は、切断開始要求メッセージＭ４１２のＲｅｑｕｅｓｔ−ＵＲＩおよびＴｏヘッダを識別情報管理サーバＩＳＶｂのＳＩＰ−ＵＲＩから接続先サーバＳＶ１ｂ「sips:sv1@bbb.com」に変更し、ＶｉａヘッダおよびＦｒｏｍヘッダを識別情報管理サーバＩＳＶａのＳＩＰ−ＵＲＩから識別情報管理サーバＩＳＶｂのＳＩＰ−ＵＲＩ「sips:agent@bbb.com」に変更したものである。

切断開始要求メッセージＭ４１３を受信したサーバＳＶ１ｂは、暗号化通信制御部５１SでクライアントＣＬ１ａとの通信の切断処理を開始したことを記録すると、ＳＩＰメッセージ処理部５３Ｓが切断開始応答メッセージＭ４１４を、ＳＩＰサーバＳＩＰｂを介して識別情報管理サーバＩＳＶｂに返信する。

切断開始応答メッセージＭ４１４は、図４０に示すように、ヘッダ部Ｍ４１４−１とボディ部Ｍ４１４−２とからなり、ヘッダ部Ｍ４１４−１のスタートラインには、メッセージ種類として、応答メッセージであることを示す「200 OK」を含み、メッセージヘッダ部には切断開始要求メッセージＭ４１３と同様の複数項目のヘッダ情報を含む。また、ボディ部Ｍ４０８−２には切断開始要求メッセージＭ４０７のボディ部Ｍ４０７−２と同じ内容を含む。

切断開始応答メッセージＭ４１４を受信した識別情報管理サーバＩＳＶｂは、ＳＩＰメッセージ処理部５３Ｉが切断開始応答メッセージＭ４１４から切断開始応答メッセージＭ４１５を作成し、ＳＩＰサーバＳＩＰｂおよびＳＩＰサーバＳＩＰａを介して、識別情報管理サーバＩＳＶａに切断開始応答メッセージＭ４１５を送信する。

なお、切断開始応答メッセージＭ４１５は、切断開始要求メッセージＭ４１２に対する応答メッセージであり、切断開始応答メッセージＭ４１４からヘッダ部Ｍ４１４−１のスタートラインに続くメッセージヘッダ部を切断開始要求メッセージＭ４１２と同様のヘッダ情報に置き換えたものである。

切断開始応答メッセージＭ４１５を受信した識別情報管理サーバＩＳＶａは、ＳＩＰメッセージ処理部５３Ｉが切断開始応答メッセージＭ４１５から切断開始応答メッセージＭ４１６を作成し、ＳＩＰサーバＳＩＰａを介して、クライアントＣＬ１ａに切断開始応答メッセージＭ４１６を送信する。

なお、切断開始応答メッセージＭ４１６は、切断開始要求メッセージＭ４１１に対する応答メッセージであり、切断開始応答メッセージＭ４１５からヘッダ部Ｍ４１５−１のスタートラインに続くヘッダ情報を切断開始要求メッセージＭ４１１と同様のヘッダ情報に置き換えたものである。

切断開始応答メッセージＭ４１６を受信したクライアントＣＬ１ａは、ＳＩＰメッセージ処理部５３Cが切断要求メッセージＭ４１７を、ＳＩＰサーバＳＩＰａを介して識別情報管理サーバＩＳＶａに送信すると、識別情報管理サーバＩＳＶａからの応答を待ち受ける。

切断要求メッセージＭ４１７は、切断要求メッセージＭ２０に似ており、スタートラインに、メッセージ種類「BYE」と識別情報管理サーバＩＳＶａのＳＩＰ−ＵＲＩを含み、メッセージヘッダ部には、切断開始要求メッセージＭ４１１と同様、Ｖｉａ、Ｔｏ、Ｆｒｏｍ、Ｃａｌｌ−ＩＤ、ＣＳｅｃ、Ｒｏｕｔｅヘッダを含み、メッセージボディ部は省略される。

切断要求メッセージＭ４１７を受信した識別情報管理サーバＩＳＶａは、ＳＩＰメッセージ処理部５３Ｉが切断応答メッセージＭ４１８を作成し、ＳＩＰサーバＳＩＰａを介してクライアントＣＬ１ａに送信する。

切断応答メッセージＭ４１８は、切断応答メッセージＭ２５に似ており、スタートラインに、メッセージ種類として、応答を示す「200 OK」を含み、ヘッダ部に、切断要求メッセージＭ４１７から抽出されたＶｉａ、Ｔｏ、Ｆｒｏｍ、Ｃａｌｌ−ＩＤ、ＣＳｅｃ等の数項目のヘッダ情報を含み、メッセージボディ部は省略されている。

切断応答メッセージＭ４１８を受信したクライアントＣＬ１ａは、暗号化通信制御部５１Cが暗号エンジン３１Cに指示して、ＳＡＤＢ３３CからサーバＳＶ１ｂとの暗号通信設定を削除する。暗号エンジン３１ＣはＩＰｓｅｃ暗号化／復号化を終了し、同一または別のアプリケーションによる新たなパケット送信要求を待つ。

一方、切断応答メッセージＭ４１８を送信した識別情報管理サーバＩＳＶａは、ＳＩＰメッセージ処理部５３Ｉが切断要求メッセージＭ４１７から切断要求メッセージＭ４１９を作成し、ＳＩＰサーバＳＩＰａおよびＳＩＰサーバＳＩＰｂを介して識別情報管理サーバＩＳＶｂに切断要求メッセージＭ４１９を送信すると、識別情報管理サーバＩＳＶｂからの応答を待ち受ける。

なお、切断要求メッセージＭ４１９は、切断要求メッセージＭ４１７のスタートラインおよびＴｏヘッダの、識別情報管理サーバＩＳＶａのＳＩＰ−ＵＲＩを識別情報管理サーバＩＳＶｂのＳＩＰ−ＵＲＩ「sips:agent@bbb.com」に変更し、ＶｉａヘッダおよびＦｒｏｍヘッダの、クライアントＣＬ１ａのＳＩＰ−ＵＲＩを識別情報管理サーバＩＳＶａのＳＩＰ−ＵＲＩ「sips:agent@aaa.com」に変更したものである。

切断要求メッセージＭ４１９を受信した識別情報管理サーバＩＳＶｂは、ＳＩＰメッセージ処理部５３Ｉが切断応答メッセージＭ４２０を作成し、ＳＩＰサーバＳＩＰｂおよびＳＩＰサーバＳＩＰａを介して識別情報管理サーバＩＳＶａに送信する。

切断応答メッセージＭ４２０は、切断応答メッセージＭ２５に似ており、スタートラインに、メッセージ種類として、応答を示す「200 OK」を含み、メッセージヘッダ部に、切断要求メッセージＭ４１９から抽出されたＶｉａ、Ｔｏ、Ｆｒｏｍ、Ｃａｌｌ−ＩＤ、ＣＳｅｃ等の数項目のヘッダ情報を含み、メッセージボディ部は省略されている。

次に、識別情報管理サーバＩＳＶｂは切断応答メッセージＭ４２０を送信すると、ＳＩＰメッセージ処理部５３Ｉが切断要求メッセージＭ４１９から切断要求メッセージＭ４２１を作成し、ＳＩＰサーバＳＩＰｂを介して接続先サーバＳＶ１ｂに切断要求メッセージＭ４２１を送信すると接続先サーバＳＶ１ｂからの応答を待ち受ける。

なお、切断要求メッセージＭ４２１は、切断要求メッセージＭ４１９のスタートラインおよびＴｏヘッダの、識別情報管理サーバＩＳＶｂのＳＩＰ−ＵＲＩを接続先サーバＳＶ１ｂのＳＩＰ−ＵＲＩ「sips:sv1@bbb.com」に変更し、ＶｉａヘッダおよびＦｒｏｍヘッダの、識別情報管理サーバＩＳＶａのＳＩＰ−ＵＲＩを識別情報管理サーバＩＳＶｂのＳＩＰ−ＵＲＩ「sips:agent@bbb.com」に変更したものである。

切断要求メッセージＭ４２１を受信した接続先サーバＳＶ１ｂは、暗号化通信制御部５１Sが暗号エンジン３１Sに指示して、ＳＡＤＢ３３SからクライアントＣＬ１ａとの暗号通信設定を削除する。次に、ＳＩＰメッセージ処理部５３Ｓが切断応答メッセージＭ４２２を作成し、ＳＩＰサーバＳＩＰｂを介して識別情報管理サーバＩＳＶｂに送信する。

切断応答メッセージＭ４２２は、切断応答メッセージＭ２５に似ており、スタートラインに、メッセージ種類として、応答を示す「200 OK」を含み、メッセージヘッダ部に、切断要求メッセージＭ４２１から抽出されたＶｉａ、Ｔｏ、Ｆｒｏｍ、Ｃａｌｌ−ＩＤ、ＣＳｅｃ等の数項目のヘッダ情報を含み、メッセージボディ部は省略されている。

次に、図３４における、識別情報管理サーバＩＳＶ、ドメイン管理サーバＤＳＶ、および図４１における、識別情報管理サーバＩＳＶ、クライアントＣＬの制御動作について説明する。

なお、図３４および図４１におけるＳＩＰサーバＳＩＰの動作は、非特許文献３で開示されているＳＩＰプロキシおよびレジストラの動作に倣うので説明を省略する。また、図３４および図４１におけるサーバＳＶの動作は、図１９および図２４のサーバＳＶの動作フローに倣うので説明を省略する。

さらに、図３４におけるクライアントＣＬの動作は、ステップ１１６においてRequest-URIとToヘッダに接続先サーバのＳＩＰ−ＵＲＩの代わりに所属ドメインの識別情報管理サーバＩＳＶのＳＩＰ−ＵＲＩを設定し、かつ、ＳＩＰメッセージのボディ部に接続先サーバのＳＩＰ−ＵＲＩを記載した接続要求メッセージを作成する以外は、図１５および図１６におけるクライアントＣＬの動作フローに倣うので説明を省略する。

図４２は、図３４において、識別情報管理サーバＳＩＰａがＡＯＲ取得要求メッセージＭ４０１を受信した場合の動作フローを示した図である。なお、識別情報管理サーバＳＩＰｂがＡＯＲ取得要求メッセージＭ４０２を受信した場合も同様の動作を行う。

識別情報管理サーバＳＩＰａは、ＡＯＲ取得要求メッセージＭ４０１を受信すると、ＳＩＰメッセージ処理部５３ＩがＡＯＲ取得要求メッセージＭ４０１を解析し、ＡＯＲ取得要求メッセージＭ４０１のＴｏヘッダに記載された内容を識別情報管理サービス６６に渡す（７０１）。

識別情報管理サービス６６は、Ｔｏヘッダの記載内容から識別情報検索クエリを作成し（７０２）、識別情報管理ＤＢに識別情報管理テーブル６４の検索を指示する（７０３、図３４のＳ４０１）。

次に、識別情報管理サービス６６は識別情報管理ＤＢから検索結果を受信すると（７０４）、検索結果を解析し、ＡＯＲ６２が取得できたかどうかを確認する（７０５）。

ここで、ＡＯＲ６２が取得できていた場合（７０６でＹＥＳ）には、識別情報管理サービス６６は、ＡＯＲ６２をＳＩＰメッセージ処理部５３Ｉに渡す。ＡＯＲ６２を受け取ったＳＩＰメッセージ処理部５３Ｉは、ＡＯＲ６２を含むＡＯＲ取得応答メッセージＭ４０４を作成し（７１７）、ＡＯＲ取得要求メッセージＭ４０１の送信元に送信し（７１８）、処理を終了する。

一方、ステップ７０６でＡＯＲ６２が取得できていなかった場合（７０６でＮＯ）には、識別情報管理サービス６６は、Ｔｏヘッダの記載内容からドメイン検索クエリを作成して（７０７）、ドメイン管理サーバＤＳＶａに送信する（７０８、図３４のＳ４０２）と、ドメイン管理サーバＤＳＶａからの応答を待ち受ける（７０９でＮＯ）。

識別情報管理サービス６６がドメイン管理サーバＤＳＶａからドメイン検索結果を受信する（７０９でＹＥＳ、図３４のＳ４０３）と、ドメイン検索結果を解析してメッセージの転送先となる識別情報管理サーバＩＳＶを決定する（７１０）。

ここで、転送先の識別情報管理サーバＩＳＶが自分自身であった場合（７１１でＹＥＳ）には、識別情報管理サービス６６は、ＳＩＰメッセージ処理部５３Ｉに検索失敗を通知する。検索失敗を通知されたＳＩＰメッセージ処理部５３Ｉは、エラー発生を示すＡＯＲ取得応答メッセージＭ４０４をステップ７１７で作成し、ＡＯＲ取得要求メッセージＭ４０１の送信元に送信して（７１８）、処理を終了する。

なお、エラー発生を示すＡＯＲ取得応答メッセージＭ４０４は、ヘッダ部Ｍ４０４−１のスタートラインには、メッセージ種類として、エラー応答メッセージであることを示す「404 Not Found」を含み、スタートラインに続いて、ＡＯＲ取得要求メッセージＭ４０１と同様の複数項目のヘッダ情報を含む。また、ボディ部M４０４−２は空である。

一方、転送先の識別情報管理サーバＩＳＶが他のドメインの識別情報管理サーバＩＳＶであった場合（７１１でNO）には、識別情報管理サービス６６は、ＳＩＰメッセージ処理部５３ＩにＴｏヘッダの記載内容と、転送先の識別情報管理サーバＩＳＶのＳＩＰ−ＵＲＩを指定して、Ｔｏヘッダの記載内容のＡＯＲ取得を要求する。

ＳＩＰメッセージ処理部５３Ｉは、Ｔｏヘッダの記載内容と、転送先の識別情報管理サーバＩＳＶのＳＩＰ−ＵＲＩからＡＯＲ取得要求メッセージＭ４０２を作成し（７１２）、ＡＯＲ取得要求メッセージＭ４０２をＳＩＰサーバＳＩＰａに送信する（７１３）と、ＳＩＰサーバＳＩＰａからの応答を待ち受ける（７１４でNO）。

ＳＩＰメッセージ処理部５３Ｉは、ＳＩＰサーバＳＩＰａからＡＯＲ取得応答メッセージＭ４０３を受信する（７１４でＹＥＳ）と、ＡＯＲ取得応答メッセージＭ４０３を解析して、識別情報管理サービス６６にＡＯＲ６２を渡す。

なお、ＡＯＲ取得応答メッセージＭ４０３がエラーを示すメッセージであった場合には、ＡＯＲ６２として空文字列を渡す（７１５）。

識別情報管理サービス６６は、ＡＯＲ６２をＳＩＰメッセージ処理部５３Ｉに渡し、ＡＯＲ取得応答メッセージＭ４０４の作成を指示する（７１６）。ＳＩＰメッセージ処理部５３Ｉは、ＡＯＲ６２を含むＡＯＲ取得応答メッセージＭ４０４を作成し、ＡＯＲ取得要求メッセージＭ４０１の送信元に送信し（７１７）、処理を終了する。

図４３は、図３４において、識別情報管理サーバＩＳＶａが接続要求メッセージＭ４０５を受信した場合の動作フローを示した図である。

なお、識別情報管理サーバＩＳＶｂが接続要求メッセージＭ４０６を受信した場合にも同じフローに従った動作を行う。

識別情報管理サーバＩＳＶａは接続要求メッセージＭ４０５を受信すると、ＳＩＰメッセージ処理部５３Ｉが接続要求メッセージＭ４０５を解析し、識別情報管理サービス６６に接続要求メッセージＭ４０５のボディ部を渡す（８０１）。

接続要求メッセージＭ４０５のボディ部を受け取った識別情報管理サービス６６は、当該ボディ部に含まれる接続先サーバＳＶ１ｂのＳＩＰ−ＵＲＩのドメインを確認する（８０２）。

ここで、接続先サーバＳＶ１ｂのＳＩＰ−ＵＲＩのドメインが他ドメインであった場合には、識別情報管理サービス６６は、接続先サーバＳＶ１ｂの属するドメインの識別情報管理サーバＩＳＶを決定し、当該識別情報管理サーバＩＳＶ（ＩＳＶｂ）のＳＩＰ−ＵＲＩと、接続要求メッセージＭ４０５のボディ部と、を指定して、ＳＩＰメッセージ処理部５３Ｉに当該識別情報管理サーバＩＳＶ（ＩＳＶｂ）に接続要求メッセージを送信するように指示する（８０４）。

ＳＩＰメッセージ処理部５３Ｉは、当該識別情報管理サーバＩＳＶ（ＩＳＶｂ）のＳＩＰ−ＵＲＩと、接続要求メッセージＭ４０５のボディ部とから接続要求メッセージM４０６を作成する（８０５）と、接続要求メッセージM４０６をＳＩＰサーバＳＩＰａに送信し（８０６）、ＳＩＰサーバＳＩＰａからの応答を待ち受ける（８０７）。

ここで、ＳＩＰサーバＳＩＰａから接続中メッセージを受信した場合には、接続中メッセージを処理して（８０８）、ステップ８０７に戻る。

一方、ＳＩＰサーバＳＩＰａから接続応答メッセージＭ４０９を受信した場合には、ＳＩＰメッセージ処理部５３Ｉは接続応答メッセージＭ４０９を解析し、メッセージ種類と、接続応答メッセージＭ４０９のボディ部とを識別情報管理サービス６６に渡す（８０９）。

また、ＳＩＰメッセージ処理部５３Ｉは接続応答メッセージＭ４０９のメッセージ種類を確認して、通信要求が受け入れられた場合には接続確認メッセージを作成し、接続応答メッセージＭ４０９の送信元に送信する（８１０）
識別情報管理サービス６６は、上記メッセージ種類を確認して、通信要求が受け入れられたのかどうかをチェックすると、上記メッセージ種類と、上記ボディ部とをＳＩＰメッセージ処理部５３Ｉに渡し、接続要求メッセージＭ４０１の送信元に接続応答メッセージＭ４０９を送信するように指示する。

ＳＩＰメッセージ処理部５３Ｉは、識別情報管理サービス６６から受け取った上記メッセージ種類と、上記ボディ部とから、接続応答メッセージＭ４１０を作成すると、ＳＩＰサーバＳＩＰａに送信し（８１１）、ＳＩＰサーバＳＩＰａからの応答を待ち受ける（８１２）。

ＳＩＰサーバＳＩＰａから接続確認メッセージを受信したＳＩＰメッセージ処理部５３Ｉは、接続確認メッセージを解析し、メッセージ種類を識別情報管理サービス６６に渡す。識別情報管理サービス６６は、接続確認メッセージを確認して、通信が確立したかどうかをチェックすると、処理を終了する。

図４６は、図３４において、識別情報管理サーバＩＳＶからドメイン検索クエリを受信した場合の、ドメイン管理サーバＤＳＶの動作フローを示した図である。

識別情報管理サーバＩＳＶからドメイン検索クエリを受信したドメイン管理サーバＤＳＶは、ドメイン情報管理サービス６７がドメイン検索クエリを解析し、管理ドメインを検索するサービス識別情報６５を取り出して、検索キーに設定する（７３１）。

次に、ドメイン情報管理サービス６７は、ドメイン管理テーブル６８の最初のエントリを検索対象エントリとして設定し（７３２）、当該エントリのサービス識別情報６５に検索キーが含まれるかどうかを計算し、評価する（７３３）。

ここで、検索キーが含まれると判定する（７３４でＹＥＳ）と、検索対象エントリの管理ドメイン６９を含むドメイン検索応答を作成して、要求元に送信する（７３５）と、処理を終了する。

一方、検索キーが含まれないと判定した場合（７３４でNO)には、ドメイン管理テーブル６８に未検索のエントリが存在するかどうかを確認（７３６）して、未検索のエントリが残っている場合には、次のエントリを検索対象エントリとして設定し（７３７）、ステップ７３３以降の処理を繰り返す。

一方、未検索のエントリが存在していない場合には、該当する管理ドメインは存在しない旨のエラーメッセージを含むドメイン検索応答を作成して、要求元に送信する（７３８）と、処理を終了する。

ただし、図３３のドメイン管理テーブル６８では、最後のエントリ（ＤＥＮ−９）に任意のサービス識別情報６５を意味する「＊」という正規表現が記載されているため、どのようなサービス識別情報６５を検索キーとして設定しても必ず対応する管理ドメインが応答されるようになっている。

図４５は、図４１において、クライアントＣＬ１ａのＳＩＰメッセージ処理部５３Ｃが暗号化通信制御部５１Ｃから切断処理要求を受信した場合の動作フローを示した図である。

クライアントＣＬ１ａのＳＩＰメッセージ処理部５３Ｃが暗号化通信制御部５１Ｃから切断処理要求を受信すると、所属ドメインの識別情報管理サーバＩＳＶ（識別情報管理サーバＩＳＶａ）のＳＩＰ−ＵＲＩをRequest-URIに適用し、かつ、接続時に取得した接続先のＳＩＰ−ＵＲＩをボディ部に適用して、切断開始要求メッセージＭ４１１を作成する（９４１）。

切断開始要求メッセージＭ４１１を自ドメインのＳＩＰサーバ（ＳＩＰサーバＳＩＰａ）に送信する（９４２）と、ＳＩＰサーバからの応答を待ち受ける（９４３）。

ＳＩＰサーバから接続開始応答メッセージＭ４１６を受信すると、切断開始応答メッセージを解析し（９４４）、所属ドメインの識別情報管理サーバＩＳＶ（識別情報管理サーバＩＳＶａ）のＳＩＰ−ＵＲＩをRequest-URIに適用し、かつ、接続時に取得した接続先のＳＩＰ−ＵＲＩをボディ部に適用して、切断要求メッセージＭ４１７を作成する（９４５）。

切断要求メッセージＭ４１７を作成すると、図２２のステップ１４２以降の処理を実行する。

図４４は、図４１において、識別情報管理サーバＩＳＶａが切断開始要求メッセージＭ４１１を受信した場合の動作フローを示した図である。なお、識別情報管理サーバＩＳＶｂが接続要求メッセージＭ４１２を受信した場合にも同じフローに従った動作を行う。

識別情報管理サーバＩＳＶａが切断開始要求メッセージＭ４１１を受信すると、ＳＩＰメッセージ処理部５３Ｉが切断開始要求メッセージＭ４１１を解析し、切断開始要求メッセージＭ４１１のボディ部を識別情報管理サービス６６に渡す（９０１）。

切断開始要求メッセージＭ４１１のボディ部を受け取った識別情報管理サービス６６は、当該ボディ部に含まれている切断先サーバのＳＩＰ−ＵＲＩやセッション識別情報を確認して、切断開始要求メッセージの送信先ドメインをチェックする（９０２）。

ここで、送信先ドメインが他ドメインであった場合には、上記ボディ部を指定して、ＳＩＰメッセージ処理部５３Ｉに、送信先ドメインの識別情報管理サーバＩＳＶ宛の切断開始開始要求メッセージを送信するように指示する（９０４）。

ＳＩＰメッセージ処理部５３Ｉは、識別情報管理サービス６６から受け取った上記ボディ部を含む切断開始要求メッセージＭ４１２を作成する（９０５）と、ＳＩＰサーバＳＩＰａに切断開始要求メッセージＭ４１２を送信し（９０６）、応答を待ち受ける（９０７）。

ＳＩＰサーバＳＩＰａから切断開始応答メッセージＭ４１５を受信すると、ＳＩＰメッセージ処理部５３Ｉは切断開始応答メッセージＭ４１５を解析して、メッセージ種類と、ボディ部を識別情報管理サービス６６に渡す（９０８）。

識別情報管理サービス６６は、メッセージ種類を確認して、切断開始要求が受け入れられたかどうかを確認すると、上記メッセージ種類とボディ部とをＳＩＰメッセージ処理部５３Ｉに渡して、切断開始応答メッセージＭ４１６の作成と送信を指示する（９０９）。

ＳＩＰメッセージ処理部５３Ｉは、切断開始応答メッセージＭ４１６をＳＩＰサーバＳＩＰａに送信して、応答を待ち受ける（９１０）。

ＳＩＰメッセージ処理部５３Ｉは、ＳＩＰサーバＳＩＰａから切断要求メッセージＭ４１７を受信すると、切断要求メッセージＭ４１７の送信元に切断応答メッセージＭ４１８を送信し（９１１）、識別情報管理サービス６６に切断要求メッセージＭ４１７を受信した旨を通知する。識別情報管理サービス６６は、ＳＩＰメッセージ処理部５３Ｉに切断要求メッセージＭ４１８を作成と送信を指示する（９１２）。

ＳＩＰメッセージ処理部５３Ｉは、切断要求メッセージＭ４１９をＳＩＰサーバＳＩＰａに送信して、応答を待ち受ける（９１３）。

ここで、切断中メッセージを受信すると、当該メッセージを処理してステップ９１３に戻る。

一方、切断応答メッセージＭ４２０を受信した場合には、ＳＩＰメッセージ処理部５３Ｉは切断応答メッセージＭ４２０を解析してメッセージ種類を識別情報管理サービス６６に通知する。識別情報管理サービス６６は、上記メッセージ種類を確認して、切断処理が正しく完了したかどうかを確認する（９１４）と、処理を終了する。

なお、ステップ９０３で切断開始要求メッセージＭ４１１の送信先が自ドメインであると判定された場合には、識別情報管理サービス６６は、切断開始要求メッセージＭ４１１のボディ部を指定して、ＳＩＰメッセージ処理部５３Ｉに切断先サーバのＳＩＰ−ＵＲＩ宛に切断開始要求メッセージを作成・送信するように指示する（９１７）。

ＳＩＰメッセージ処理部５３Ｉは、作成した切断開始要求メッセージをＳＩＰサーバＳＩＰａに送信し、ステップ９０６以降の処理を実行する。

以上が、図３４における、識別情報管理サーバＩＳＶ、ドメイン管理サーバＤＳＶ、および図４１における、識別情報管理サーバＩＳＶ、クライアントＣＬの制御動作である。

本第４の実施例では、クライアントＣＬは、ＡＯＲ取得要求メッセージをクライアントＣＬと同じドメインに属する識別情報管理サーバＩＳＶ宛に送信するようにしている。かつ、ＡＯＲ取得要求メッセージを受信した識別情報管理サーバＩＳＶは、識別情報管理テーブル６４を検索して、対応するエントリが存在しなかった場合に、ドメイン管理サーバＤＳＶを検索してＡＯＲ取得要求メッセージを送信すべき識別情報管理サーバＩＳＶを決定するようにしている。

このため、クライアントＣＬやサーバＳＶのサービス識別子を複数の識別情報管理サーバＩＳＶで分散して管理することができる。また、ＳＩＰサーバは、受信したＳＩＰメッセージのヘッダ情報に従って、当該ＳＩＰメッセージを送信する先を決定するメッセージ転送機能を持てばよいため、一般的なＳＩＰサーバを使用することができる。

さらに、識別情報管理サーバＩＳＶはＳＩＰ−ＵＲＩが割り当てられているため、ある識別情報管理サーバＩＳＶにクライアントＣＬやサーバＳＶや他の識別情報管理サーバＩＳＶがＳＩＰメッセージを送信する場合には、ＳＩＰサーバＳＩＰのメッセージ転送機能を利用することができる。

また、本第４の実施例では、識別情報管理サーバＩＳＶが受信した接続要求メッセージのボディ部の内容に基づいて、送信する接続要求メッセージを作成するため、接続先サーバＳＶが受信する接続要求メッセージにはクライアントＣＬのＳＩＰ−ＵＲＩが記載されていない。従って、クライアントＣＬがＳＩＰサーバに認証されていることは保証しながら、クライアントＣＬのＳＩＰ−ＵＲＩを接続先サーバＳＶに公開することなく、暗号通信を実施することができる。

なお、本発明は、第４の実施例の構成には限定されず、以下のように構成しても良い。

例えば、識別情報管理サーバＩＳＶは、切断要求メッセージの受信を契機として他の識別情報管理サーバＩＳＶや接続先サーバＳＶに切断要求メッセージを送信している。しかし、切断応答メッセージの受信を契機として切断要求メッセージを送信してもよい。

また、識別情報管理サーバＩＳＶは、識別情報管理テーブル６４を検索して、検索に失敗した場合にドメイン管理サーバＤＳＶに問合せを行っている。しかし、ドメイン管理サーバＤＳＶに問合せを行い、自ドメインであると判定された場合に識別情報管理テーブル６４を検索してもよいし、それぞれを並行して行ってもよい。

また、識別情報管理サーバＩＳＶは受信した接続要求メッセージのボディのドメイン名を確認して送信先を決定している。しかし、接続要求メッセージを送信してよいかどうかの判定を行い、送信してよいと判断した場合に、上記送信先に新たに作成した接続要求メッセージを送信してもよい。

さらには、ＡＯＲ取得要求メッセージまたは接続要求メッセージに接続元の権限に関する情報や接続ポリシーに関する情報を記載し、識別情報管理サーバＩＳＶにおいてアクセス判定を行ってもよい。

また、識別情報管理サーバＩＳＶにおいて識別情報管理テーブル６４を保持している。しかし、識別情報管理テーブル６４を保持するデータベース装置を設置し、識別情報管理サーバＩＳＶはネットワークを介して上記テーブルにアクセスしてもよい。

また、本発明は、暗号化通信の開始および終了のための、接続要求メッセージから切断応答メッセージまでのＳＩＰメッセージを識別情報管理サーバＩＳＶが送受している。しかし、上記のＳＩＰメッセージを送受するための新たなサーバを設置してもよい。

さらに、本第４の実施例では、１つの管理ドメインを、１つのＳＩＰサーバＳＩＰと、１つの識別情報管理サーバＩＳＶと、で構成しているが、本発明はこれに限定されない。

例えば、クライアントＣＬやサーバＳＶとの間でＳＩＰメッセージを送受するＳＩＰサーバＳＩＰと、他の管理ドメインのＳＩＰサーバとの間でＳＩＰメッセージを送受するＳＩＰサーバＳＩＰとを分け、識別情報管理サーバＩＳＶがＳＩＰメッセージの送信先によってＳＩＰメッセージを送信先となるＳＩＰサーバを変更するようにしてもよい。

このようにすることで、ＳＩＰサーバＳＩＰへの負荷集中を防止することができる。さらには、１つの管理ドメインを、複数のＳＩＰサーバＳＩＰと、複数の識別情報管理サーバＩＳＶと、で構成し、ＳＩＰサーバＳＩＰや、識別情報管理サーバＩＳＶの負荷に応じて、ＳＩＰメッセージの送信先を変更するようにしてもよい。

さらに、本第４の実施例では、暗号化通信機能部がクライアントCLのアプリケーションとサーバＳＶのアプリケーションとの間の通信をＩＰｓｅｃで暗号化しているが、本発明はこれに限定されず、様々な暗号化通信プロトコルを適用することができる。

例えば、ＩＰｓｅｃの代わりにＴＬＳを用いて暗号化するようにしてもよい。ＴＬＳを用いて暗号化する場合には、暗号通信設定として、ＴＬＳ Ｈａｎｄｓｈａｋｅプロトコルで確立される接続情報を含む。すなわち、当該接続情報を識別するために使用するセッション識別子、通信相手のＩＰアドレスとポート番号、通信相手との通信に使用するＩＰアドレスとポート番号、アプリケーションデータを暗号化するための暗号アルゴリズム、アプリケーションデータのメッセージ認証を行うためのメッセージ認証アルゴリズム、暗号化やメッセージ認証に使用する鍵を計算するためのマスターシークレット、などが含まれる。

クライアントＣＬ１は、暗号エンジン３１Cに上記暗号通信設定を適用すると、接続先サーバＳＬ１とＴＬＳセッションを確立し、アプリケーションデータ通信を開始する。このとき、クライアントＣＬとサーバＳＶの間でＴＬＳセッションを確立する場合には、ＲＦＣ２２４６で規定されたセッション再開（Ｓｅｓｓｉｏｎ Ｒｅｓｕｍｅ）機能を使用することができる。すなわち、クライアントＣＬは、暗号化通信機能部３０Ｃが上記暗号通信設定のセッション識別子を含むＣｌｉｅｎｔ Ｈｅｌｌｏメッセージを接続先サーバＳＶに送信して、接続先サーバＳＶの暗号化通信機能部３０Ｓにアプリケーションデータ通信に使用する暗号通信設定を通知する。

Ｃｌｉｅｎｔ Ｈｅｌｌｏメッセージを受信した接続先サーバＳＶの暗号化通信機能部３０Ｓは、ＳＡＤＢを検索して、セッション識別子に対応する暗号通信設定が存在することを確認すると、セッション識別子を含むＳｅｒｖｅｒ ＨｅｌｌｏメッセージをクライアントＣＬに送信する。Ｓｅｒｖｅｒ Ｈｅｌｌｏメッセージを受信したクライアントＣＬの暗号化通信機能部３０ＣはＣｌｉｅｎｔ Ｈｅｌｌｏメッセージに含めたセッション識別子がＳｅｒｖｅｒ Ｈｅｌｌｏメッセージに含まれていることを確認すると、ＴＬＳセッションが確立したと判断し、アプリケーションデータ通信を開始する。

また、上記各実施例を適宜組み合わせて実施することも可能である。

ＳＩＰプロキシを適用した認証システムを説明するための図。 実施形態におけるセッション管理サーバ（ＳＩＰサーバ）を含むネットワーク構成を例示する図。 図２に示したロケーションサーバＬＳＶが備えるロケーションサービステーブルを例示する図。 図２に示したＳＩＰプロキシＰＲａのハードウェア構成を例示するブロック図。 図２に示したクライアントＣＬ１ａの基本的なソフトウェア構造を例示する図。 図２に示したサーバＳＶ１ｂの基本的なソフトウェア構造を例示する図。 図２に示したＳＩＰプロキシＰＲａの基本的なソフトウェア構造を例示する図。 図２に示したレジストラＲＧａの基本的なソフトウェア構造を例示する図。 第１の実施例における暗号化通信のシーケンスを例示する図（その１）。 第１の実施例における暗号化通信のシーケンスを例示する図（その２）。 図９におけるロケーション登録要求メッセージＭ１およびロケーション登録応答メッセージＭ２のフォーマットを例示する図。 図９におけるロケーションＡＯＲ取得要求メッセージＭ３およびロケーションＡＯＲ取得応答メッセージＭ４のフォーマットを例示する図。 接続要求メッセージＭ５のボディ部Ｍ５−２のフォーマットを例示する図。 接続応答メッセージＭ１０のボディ部Ｍ１０−２のフォーマットを例示する図。 鍵交換要求を受信した時、クライアントＣＬ１ａの暗号化通信制御部５１Ｃが実行する制御動作を例示するフローチャート。 接続要求メッセージのボディ部を受信した時、クライアントＣＬ１ａのＳＩＰメッセージ処理部５３Ｃが実行する制御動作を例示するフローチャート。 ＡＯＲ取得要求メッセージを受信した時、レジストラＲＧａのＳＩＰメッセージ処理部５３Ｒが実行する制御動作を例示するフローチャート。 接続要求メッセージを受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作を例示するフローチャート。 接続要求メッセージを受信した時、サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓが実行する制御動作を例示するフローチャート。 接続要求メッセージのボディ部を受信した時、サーバＳＶ１ｂの暗号化通信制御部５１Ｓが実行する制御動作を例示するフローチャート。 鍵消去要求を受信した時、クライアントＣＬ１ａの暗号化通信制御部５１Ｃが実行する制御動作を例示するフローチャート。 切断処理要求を受信した時、クライアントＣＬ１ａのＳＩＰメッセージ処理部５３Ｃが実行する制御動作を例示するフローチャート。 切断要求メッセージを受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作を例示するフローチャート。 切断要求メッセージを受信した時、サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓが実行する制御動作を例示するフローチャート。 切断要求の発生通知を受信した時、サーバＳＶ１ｂの暗号化通信制御部５１Ｓが実行する制御動作を例示するフローチャート。 第２の実施例のネットワーク構成を例示する図。 第２の実施例を説明するためのシーケンスを例示する図。 図２７における識別情報登録要求メッセージＭ１０１および識別情報登録応答メッセージＭ１０３のフォーマットを例示する図。 を例示する識別情報管理サーバＩＳＶの基本的なソフトウェア構造を例示する図。 図２７におけるＡＯＲ取得要求メッセージＭ１０５およびＡＯＲ取得応答メッセージＭ１０７のフォーマットを例示する図。 第３、第４の実施例のネットワーク構成を例示する図。 第３の実施例における暗号化通信のシーケンスを例示する図。 第３の実施例のロケーション管理テーブル６０、識別情報管理テーブル６４、ドメイン管理テーブル６８の構成を例示する図。 第４の実施例における通信の開始処理シーケンスを例示する図。 ドメイン管理サーバＤＳＶの基本的なソフトウェア構造を例示する図。 第３の実施例のＳＩＰサーバＳＩＰがＡＯＲ取得要求メッセージを受信した場合の動作を例示するフローチャート。 第３の実施例の識別情報管理サーバＩＳＶがＡＯＲ取得要求メッセージを受信した場合の動作を例示するフローチャート。 第４の実施例におけるＡＯＲ取得要求メッセージＭ４０１およびＡＯＲ取得応答メッセージＭ４０４のフォーマットを例示する図。 第４の実施例における接続要求メッセージＭ４０５および接続応答メッセージＭ４０８のフォーマットを例示する図。 第４の実施例における切断開始要求メッセージＭ４１１および切断開始応答メッセージＭ４１４のフォーマットを例示する図。 第４の実施例における通信の切断処理を説明するためのシーケンスを例示する図。 第４の実施例の識別情報管理サーバＩＳＶがＡＯＲ取得要求メッセージを受信した場合の動作を例示するフローチャート。 第４の実施例の識別情報管理サーバＩＳＶが接続要求メッセージを受信した場合の動作を例示するフローチャート。 第４の実施例の識別情報管理サーバＩＳＶが切断開始要求メッセージを受信した場合の動作を例示するフローチャート。 切断処理要求を受信した時、クライアントＣＬ１ａのＳＩＰメッセージ処理部５３Ｃが実行する制御動作を例示するフローチャート。 ドメイン検索要求を受信した時、ドメイン管理サーバＤＳＶが実行する制御動作を例示するフローチャート。

符号の説明

ＣＬ１ａ〜ＣＬ２ｂ：クライアント、ＳＶ１ａ〜ＳＶ２ｂ：サーバ、ＳＩＰａ、ＳＩＰｂ：ＳＩＰサーバ、ＰＲａ、ＰＲｂ：ＳＩＰプロキシ、ＲＧａ、ＲＧｂ：レジストラ、ＬＳＶ、ＬＳＶａ、ＬＳＶｂ：ロケーションサーバ、ＩＳＶ、ＩＳＶａ、ＩＳＶｂ：識別情報管理サーバ、ＤＳＶａ、ＤＳＶｂ：ドメイン管理サーバ、２０：ネットワークインタフェースカード部、３０：暗号化通信機能部、３１：暗号エンジン、４０：アプリケーションソフト、５０：鍵管理プロセス、５１：暗号化通信制御部、５２：ＴＬＳ部、５３：ＳＩＰメッセージ処理部、６０：レジストラ処理部、６１：ロケーションサービステーブル、６２：ＡＯＲ、６３：ＩＰアドレス、６４：識別情報管理テーブル、６５：識別情報、６６：識別情報管理サービス、６７：ドメイン管理サービス、６８：ドメイン管理テーブル、６９：ドメイン。

Claims (9)

1. 複数のドメインを含む通信ネットワークと、それぞれのドメインを管理する管理サーバと、互いに異なるドメインに接続されたクライアントとサービスサーバとを含む通信システムにおける、前記クライアントと前記サービスサーバ間のデータ通信方法であって、
   前記サービスサーバが、当該サービスサーバの所属ドメインを管理する第一の管理サーバに、当該管理サーバが前記サービスサーバを識別するために使用する接続先識別子と、前記サービスサーバの現在のネットワーク上の位置を示すネットワークアドレスと、を含むロケーション登録要求メッセージに、前記サービスサーバが提供しているサービスを識別するサービス識別情報をさらに含めて送信する第１ステップと、
   前記サービスサーバから前記ロケーション登録要求メッセージを受信した前記第一の管理サーバが、当該ロケーション登録要求メッセージに含まれる前記接続先識別子と前記ネットワークアドレスとの関連付けをロケーションサービステーブルに保存するとともに、当該ロケーション登録要求メッセージに含まれる前記接続先識別子と前記サービス識別情報との関連付けを識別情報管理テーブルに保存する第２ステップと、
   前記クライアントが、サービス提供を希望するサービスのサービス識別情報を指定して、当該サービス識別情報で識別されるサービスを提供している前記サービスサーバの接続先識別子を問い合わせるロケーション検索要求メッセージを、前記クライアントが所属するドメインを管理する第二の管理サーバに送信する第３ステップと、
   前記クライアントから問合せを受けた前記第二の管理サーバが、サービス識別子とその所属ドメインとの対応関係を管理しているドメイン管理テーブルから、前記前記サービスサーバの所属ドメイン名を取得し、当該所属ドメインを管理する前記第一の管理サーバに、前記ロケーション検索要求メッセージを転送する前記第４ステップと、
   前記第一の管理サーバが、前記識別情報管理テーブルから、前記サービス識別情報に対応する前記接続先識別子を取得し、前記クライアントに通知する第５ステップと、
   前記クライアントが、前記第一の管理サーバに、取得した前記サービスサーバの接続先識別子を含む接続要求メッセージを送信する第６ステップと、
   前記第一の管理サーバが、前記接続要求メッセージに記述された前記接続先識別子に含まれるドメイン名に基づいて、前記接続要求メッセージの送信先を判定し、前記接続要求メッセージを前記サービスサーバ、または該サービスサーバの所属ドメインを管理する前記第一の管理サーバに転送する第７ステップと、を備える
   ことを特徴とするデータ通信方法。
2. 請求項１記載のデータ通信方法であって、
   前記第二の管理サーバは、当該クライアントが所属するドメインの通信セッションを管理するセッション管理サーバであり、
   前記第二の管理サーバから問合せを受ける前記第一の管理サーバは、前記サービスサーバが所属するドメインの通信セッションを管理するセッション管理サーバである
   ことを特徴とするデータ通信方法。
3. 請求項１または２に記載のデータ通信方法であって、
   前記第二の管理サーバは、当該クライアントの所属するドメインの識別情報を管理する識別情報管理サーバであり、
   前記第二の管理サーバから問合せを受ける前記第一の管理サーバは、前記サービスサーバの所属するドメインの識別情報を管理する識別情報管理サーバである
   ことを特徴とするデータ通信方法。
4. 請求項１から３のいずれか一に記載のデータ通信方法であって、
   前記サービスサーバが、前記接続要求メッセージの受信に応答して、前記第二の管理サーバを介して、前記要求元クライアントに、暗号化通信に必要となるパラメータ情報を含む接続応答メッセージを返送する第８ステップと、
   前記クライアントと前記サービスサーバとの間で、前記接続応答メッセージで指定されたパラメータ情報に従って暗号化されたメッセージを通信する第９ステップと、を備える
   ことを特徴とするデータ通信方法。
5. 請求項２記載のデータ通信方法であって、
   前記セッション管理サーバが、ＳＩＰ（Session Initiation Protocol）サーバからなり、前記クライアントと前記セッション管理サーバとの間の通信メッセージが暗号化され、前記サービス識別情報はサービスサーバが提供するサービスのＵＲＬ、または、ＵＲＩである
   ことを特徴とするデータ通信方法。
6. 請求項５記載のデータ通信方法であって、
   前記クライアントとサービスサーバとの間の通信データが暗号化される
   ことを特徴とするデータ通信方法。
7. 請求項５または６に記載のデータ通信方法であって、
   前記接続先識別子は前記サービスサーバのＳＩＰ−ＵＲＩである
   ことを特徴とするデータ通信方法。
8. 複数のドメインを含む通信ネットワークにおいて、クライアントおよびサービスサーバと通信し、それぞれのドメインを管理する管理サーバであって、
   前記サービスサーバを識別するために使用する接続先識別子と、前記サービスサーバの現在のネットワーク上の位置を示すネットワークアドレスとの関連付けを管理するロケーションサービステーブルと、前記接続先識別子とサービスサーバが提供しているサービスのサービス識別情報との関連付けを管理する識別情報管理テーブルと、
   サービス識別情報とその所属ドメインとの対応関係を管理しているドメイン管理テーブルを備え、
   前記クライアントから、サービス識別情報を指定して、当該サービス識別情報が割り当てられた前記サービスサーバの接続先識別子の問い合わせを受信した場合に、前記ドメイン管理テーブルから、前記サービスサーバの所属ドメイン名を取得し、
   当該所属ドメインを当該管理サーバが管理している場合に、前記識別情報管理テーブルから、前記サービスサーバの接続先識別子を取得し、
   当該所属ドメインを当該管理サーバが管理していない場合に、前記所属ドメインを管理する他の管理サーバに、前記サービスサーバのサービス識別情報を指定して、該サービスサーバに割り当てられた、当該サービスサーバの所属ドメイン名を含む接続先識別子を問い合わせ、
   前記他の管理サーバから、前記問い合わせたサービスサーバの接続先識別子を取得し、
   取得した前記接続先識別子を前記クライアントに通知し、
   前記クライアントから、通知した前記サービスサーバの接続先識別子を含む接続要求メッセージを受信した場合に、受信した前記接続要求メッセージに記述された前記接続先識別子に含まれるドメイン名に基づいて、受信した前記接続要求メッセージの送信先を判定し、
   前記接続要求メッセージを、前記サービスサーバまたは該サービスサーバの所属ドメインを管理する前記他の管理サーバに転送する
   ことを特徴とする管理サーバ。
9. 通信ネットワークと、管理サーバと、通信ネットワークに接続されたクライアントとサービスサーバとを含む通信システムにおける、前記クライアントと前記サービスサーバ間のデータ通信方法であって、
   前記サービスサーバが、前記管理サーバが当該サービスサーバを識別するために使用する接続先識別子とＩＰアドレスを含むロケーション登録要求メッセージに、当該サービスサーバが提供しているサービスのサービス識別情報をさらに含めて管理サーバに送信する第１ステップと、
   前記サービスサーバから前記ロケーション登録要求メッセージを受信した前記管理サーバが、当該ロケーション登録要求メッセージに含まれる前記接続先識別子と前記ＩＰアドレスとの関連付けをロケーションサービステーブルに保存するとともに、当該ロケーション登録要求メッセージに含まれる前記接続先識別子と前記サービス識別情報との関連付けを識別情報管理テーブルに保存する第２ステップと、
   前記クライアントが、サービスの提供を希望するサービスのサービス識別情報を指定して、当該サービス識別情報が割り当てられた前記サービスサーバの接続先識別子を、前記クライアントが所属するドメインを管理する前記管理サーバに問い合わせる第３ステップと、
   前記クライアントから問合せを受けた前記管理サーバが、前記識別情報管理テーブルから、前記サービス識別情報に対応する前記接続先識別子を取得し、前記クライアントに通知する第４ステップと、
   前記クライアントが、前記管理サーバに、取得した前記サービスサーバの接続先識別子を含む接続要求メッセージを送信する第５ステップと、
   前記管理サーバが、前記ロケーションサービステーブルから、前記接続要求メッセージに含まれる前記接続先識別子に対応するＩＰアドレスを取得し、前記接続要求メッセージを当該ＩＰアドレスを持つ前記サービスサーバに送信する第６ステップと、を備える
   ことを特徴とするデータ通信方法。

Images