データ通信方法およびシステム
【課題】 接続先をアプリケーション固有の識別情報で指定したセッション制御メッセージをセッション管理サーバ経由で接続先に転送可能にした暗号化通信方法とシステムの提供。
【解決手段】 クライアントのアプリケーションプログラムまたは暗号化通信ソフトが、接続先サーバをアプリケーション固有の識別情報で指定した形で接続要求を発行した時、クライアントまたはセッション管理サーバで、上記識別情報をドメイン識別可能な所望のリソース識別子に自動的に変換し、受信メッセージの転送先ドメインを判定する。
【解決手段】 クライアントのアプリケーションプログラムまたは暗号化通信ソフトが、接続先サーバをアプリケーション固有の識別情報で指定した形で接続要求を発行した時、クライアントまたはセッション管理サーバで、上記識別情報をドメイン識別可能な所望のリソース識別子に自動的に変換し、受信メッセージの転送先ドメインを判定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ通信方法およびシステムに関し、更に詳しくは、セッション管理サーバを利用して、クライアントとサーバとの間での暗号化データ通信を可能にしたデータ通信方法およびシステムを提供することにある。
【背景技術】
【０００２】
ネットワークにおける暗号化通信方法では、クライアントとサーバは、互いに意図しない相手装置との通信を防止するため、相手装置について認証手順を実行し、相手装置の認証に成功した時、通信に使用する暗号化パラメータを交換するようにしている。ＩＥＴＦ（Internet Engineering Task Force）のＲＦＣ２４０１（非特許文献１）に記述されたＩＰｓｅｃ（Internet Protocol Security）や、ＲＦＣ２２４６（非特許文献２）に記述されたＴＬＳ（Transport Layer Security）では、通信相手の認証に公開鍵証明書が適用される。
【０００３】
公開鍵証明書を用いた認証では、通信相手が提示した公開鍵証明書が信頼できる認証局から発行されたものであることを何らかの方法で検証する必要がある。公開鍵証明書の検証方法の１つとしては、例えば、通信相手が提示する公開鍵証明書の発行元認証局を証明するための信頼性のある認証局ｒｏｏｔ証明書を何らかの方法で事前に入手しておき、通信相手の認証手順において、相手装置が提示した公開鍵証明書に付与された認証局の署名を、認証局のｒｏｏｔ証明書の公開鍵によって検証する方法がある。この検証方法によれば、サーバとクライアントは、通信対象となる全ての通信装置の公開鍵証明書に対応して、各公開鍵証明書の発行元認証局のｒｏｏｔ証明書を事前に用意しておく必要がある。
【０００４】
例えば、図１に示すように、複数のクライアント（端末装置）ＣＬ１、ＣＬ２、ＣＬ３が、それぞれ発行元（ＣＡ１、ＣＡ２、ＣＡ３）の異なる秘密鍵ＳＫ１、ＳＫ２、ＳＫ３と公開鍵証明書ＰＫ１、ＰＫ２、ＰＫ３を所持し、サーバＳＶ１、ＳＶ２、ＳＶ３も、それぞれ発行元（ＣＡ１、ＣＡ２、ＣＡ３）の異なる秘密鍵ＳＫ１１、ＳＫ１２、ＳＫ１３と公開鍵証明書ＰＫ１１、ＰＫ１２、ＰＫ１３を所持したシステムを想定する。ここで、各クライアントが、複数のサーバＳＶ１、ＳＶ２、ＳＶ３と随時に通信できるようにするためには、図示したように、各サーバに、通信相手となる全てのクライアント装置ＣＬ１、ＣＬ２、ＣＬ３がもつ公開鍵証明書（ＰＫ１、ＰＫ２、ＰＫ３）の発行元認証局（ＣＡ１、ＣＡ２、ＣＡ３）と対応して、複数のｒｏｏｔ証明書ＲＴ１、ＲＴ２、ＲＴ３を事前に所持しておく必要がある。同様に、各クライアントにも、通信相手となるサーバＳＶ１、ＳＶ２、ＳＶ３がもつ公開鍵証明書（ＰＫ１１、ＰＫ１２、ＰＫ１３）の発行元認証局（ＣＡ１、ＣＡ２、ＣＡ３）と対応して、複数のｒｏｏｔ証明書ＲＴ１、ＲＴ２、ＲＴ３を事前に用意しておく必要がある。また、このシステム構成では、各クライアント装置とサーバは、通信相手を変えた時、その都度、認証処理を繰り返す必要がある。
【０００５】
図２は、上記ＲＦＣ２４０１に記述されたＩＰｓｅｃによる暗号化通信を行うためにクライアントが備えるソフトウェアの基本的なブロック構成を示す。
ここで、２０は、ネットワークインタフェースカード（ＮＩＣ）部、３０は、ＴＣＰ／ＩＰレイヤ、４０は、アプリケーションレイヤのソフトウェア部を示し、５０は、ＲＦＣ２４０９（非特許文献３）に記述された鍵管理（ＩＫＥ：Internet Key Exchange）プロセス用のソフトウェア部を示している。暗号エンジン３１は、ＴＣＰ／ＩＰレイヤのソフトウェアの一部として装備され、送信パケットに暗号化を適用するか否かの判定情報（ＳＰ情報）を記憶したＳＰＤＢ（Security Policy Data Base）３２と、暗号化通信に適用する暗号化方式や暗号鍵等の情報（ＳＡ情報）を記憶したＳＡＤＢ（Security Association Data Base）３３とを備えている。
【０００６】
上記クライアントの通信相手となるサーバも、図２と同様のソフトウェアを有し、クライアントとサーバのアプリケーションレイヤ同士、鍵管理プロセス同士が互いに通信するようになっている。
【０００７】
暗号エンジン３１は、アプリケーションレイヤ４０のプログラムが発行したＩＰパケットの送信要求を検出すると、該ＩＰパケットのヘッダ情報をＳＰＤＢ３２で検証し、このＩＰパケットにＩＰｓｅｃを適用すべきか否かを判定する。ＩＰパケットにＩＰｓｅｃを適用すると判断した暗号エンジン３１は、ＳＡＤＢ３３から、ＩＰパケットに適用すべきＳＡ（Security Association）情報を取得する。ここで、もし、ＳＡＤＢ３３に上記ＩＰパケットと対応するＳＡ情報が登録されていなかった場合、暗号エンジン３１は、ＩＫＥ（鍵管理）プロセス５０に対して、通信相手（接続先サーバ）との間での暗号鍵を含むＳＡ情報の交換を要求する。
【０００８】
ＩＫＥプロセス５０は、ＲＦＣ２４０８（非特許文献４）に記載されたＩＳＡＫＭＰ（Internet Security Association and Key Management Protocol）に従って、通信相手とＳＡ情報を交換する。ＩＳＡＫＭＰでは、通信相手との間に暗号化通信路を形成した後、相手装置が通信を許容された真正な装置か否かを確認するための認証手順を実行する。ＩＫＥプロセス５０は、上記認証手順によって、相手装置が暗号化通信を許容された真正な装置であることを確認すると、ＩＳＡＫＭＰによって設定された通信路を介して、相手装置とＳＡ情報の交換を開始する。ＩＫＥプロセス５０は、通信相手とのＳＡ情報の交換が完了すると、暗号エンジン３１に、ＳＡ情報とこれに対応したＳＰ（Security Policy）情報を通知する。
【０００９】
暗号エンジン３１は、ＩＫＥプロセス５０から通知されたＳＰ情報とＳＡ情報をそれぞれＳＰＤＢ３２、ＳＡＤＢ３３に格納した後、ＩＰパケットを上記ＳＡ情報に従って暗号化して、通信相手に送信する。通信相手となるサーバ側では、上記暗号化されたＩＰパケットを受信すると、ＩＫＥプロセスによって合意したＳＡ情報に従って受信ＩＰパケットを復号化し、サーバ側アプリケーションレイヤにＩＰパケットの受信を通知する。
【００１０】
一方、ＲＦＣ３２６１（非特許文献５）には、ＴＬＳ（Transport Layer Security）によって、クライアント（ユーザエージェントクライアント）とセッション管理サーバであるＳＩＰ（Session Initiation Protocol）プロキシとの間、およびＳＩＰプロキシとサーバ（ユーザエージェント・サーバ）との間の相互認証を行って、クライアントとＳＩＰプロキシ、ＳＩＰプロキシとサーバが暗号化通信する方法が記載されている。ＲＦＣ３２６１のＳＩＰモデルによれば、クライアントとサーバは、それぞれがＳＩＰプロキシによって真正な通信相手として確認済みであり、且つ、クライアントとサーバとの間では、暗号化されたＳＩＰメッセージが送受信されるため、クライアント、サーバ、ＳＩＰプロキシ以外の他の装置が、上記クライアントとサーバとの間の通信内容を傍受することは困難となっている。
【００１１】
ＳＩＰは、テキストベースのプロトコルであり、ＳＩＰメッセージは、ヘッダ部と、セッション内容を示すメッセージボディ部とからなる。ＳＩＰに関しては、ＲＦＣ３２６３（非特許文献６）に記述されている。また、ＲＦＣ２３２７（非特許文献７）には、セッション記述に適用されるＳＤＰ（Session Description Protocol）と、クライアントとサーバとの間で交換される暗号化パラメータの記述方法について開示されている。ＳＩＰモデルのクライアントとサーバは、それぞれがＳＩＰプロキシとの間に形成した暗号通信路を介して、ＳＩＰメッセージによってセッション記述と暗号化パラメータを交換した後、上記暗号化パラメータを適用して、暗号化パケットを通信することができる。
【００１２】
【非特許文献１】ＩＥＴＦ、ＲＦＣ２４０１：Ｓｅｃｕｒｉｔｙ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ、［２００５年１１月２９日検索］ 、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２４０１．ｔｘｔ＞
【非特許文献２】ＩＥＴＦ、ＲＦＣ２２４６：Ｔｈｅ ＴＬＳ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ １．０、［２００５年１１月２９日検索］ 、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２２４６．ｔｘｔ＞
【非特許文献３】ＩＥＴＦ、ＲＦＣ２４０９：Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ （ＩＫＥ） 、［２００５年１１月２９日検索］ 、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２４０９．ｔｘｔ＞
【非特許文献４】ＩＥＴＦ、ＲＦＣ２４０８：Ｉｎｔｅｒｎｅｔ Ｓｅｃｕｒｉｔｙ Ａｓｓｏｃｉａｔｉｏｎ ａｎｄ Ｋｅｙ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ （ＩＳＡＫＭＰ） 、［２００５年１１月２９日検索］ 、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２４０８．ｔｘｔ＞
【非特許文献５】ＩＥＴＦ、ＲＦＣ３２６１：ＳＩＰ： Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ、［２００５年１１月２９日検索］ 、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３２６１．ｔｘｔ＞
【非特許文献６】ＩＥＴＦ、ＲＦＣ３２６３：Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ （ＳＩＰ）： Ｌｏｃａｔｉｎｇ ＳＩＰ Ｓｅｒｖｅｒｓ、［２００５年１１月２９日検索］ 、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３２６３．ｔｘｔ＞
【非特許文献７】ＩＥＴＦ、ＲＦＣ２３２７：ＳＤＰ： Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ、［２００５年１１月２９日検索］ 、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２３２７．ｔｘｔ＞
【発明の開示】
【発明が解決しようとする課題】
【００１３】
図３は、上述したＳＩＰプロキシを適用した認証システムの１例を示す。ここで、ＰＲは、複数のクライアントＣＬ１、ＣＬ２、ＣＬ３と、複数のサーバＳＶ１、ＳＶ２、ＳＶ３とに接続されたＳＩＰプロキシを示す。ＳＩＰプロキシＰＲは、認証局ＣＡ４が発行した秘密鍵ＳＫ３０と、公開鍵証明書ＰＫ３０を使用しており、サーバＳＶ１、ＳＶ２、ＳＶ３を認証するために、これらのサーバが使用する公開鍵証明書の発行元認証局（ＣＡ１、ＣＡ２、ＣＡ３）と対応した複数のｒｏｏｔ証明書ＲＴ１、ＲＴ２、ＲＴ３を予め所持している。
【００１４】
ＳＩＰプロキシを適用した認証システムでは、各サーバとクライアントは、図３に示すように、通信相手を認証するためのｒｏｏｔ証明書として、ＳＩＰプロキシＰＲが使用する公開鍵証明書ＰＫ３０の発行元認証局と対応したｒｏｏｔ証明書ＲＴ４のみを所持すればよい。また、各クライアントは、ＳＩＰプロキシＰＲを介して１つのサーバと通信した後、接続先を別のサーバに変更する場合、ＳＩＰプロキシとの間では既に構築済みの暗号通信路を使用して通信できるため、新たな通信相手との間で暗号化パラメータを交換するだけで、暗号化通信を開始することが可能となる。つまり、ＳＩＰプロキシを適用した認証システムでは、各クライアントにとって、接続先サーバの変更の都度、新たに認証処理を行う必要がないという利点がある。
【００１５】
然るに、ＳＩＰのフレームワークにおいては、セッション管理サーバ（ＳＩＰプロキシ）は、ＡＯＲ（Address-of-Record）と呼ばれる「ユーザ名＠ドメイン名」 形式をもつ識別子（ＳＩＰ−ＵＲＩ）によって、受信ＳＩＰメッセージの転送先を決定している。従って、上述したＳＩＰプロキシのようなセッション管理サーバ経由のセッション設定を前提としたネットワークシステムでは、クライアント上で実行されるアプリケーションは、接続先サーバを指定するための識別子として、サーバの所属ドメインを特定可能なＳＩＰ−ＵＲＩ（Uniform Resource Identifier）を使用する必要がある。
【００１６】
更に詳述すると、ＳＩＰのフレームワークにおいては、クライアント側では、スタートラインに含まれるＲｅｑｕｅｓｔ−ＵＲＩとして、接続先サーバを指定するＡＯＲ形式のＳＩＰ−ＵＲＩを記述した接続要求ＳＩＰメッセージを生成し、該ＳＩＰメッセージをペイロードに含むＩＰパケットをクライアントの所属ドメインに位置するＳＩＰプロキシ宛に送信する。上記ＩＰパケットを受信したＳＩＰプロキシは、Ｒｅｑｕｅｓｔ−ＵＲＩとして記述されたＡＯＲが示すドメイン名に基づいて、例えば、ＤＮＳ（Domain Name System）のＮＡＰＴＲ Ｒｅｃｏｒｄ検索とＳＲＶ Ｒｅｃｏｒｄ検索を行うことにより、受信メッセージの転送先サーバが所属する他のドメインに位置したＳＩＰプロキシ（転送先ＳＩＰプロキシ）のＩＰアドレスあるいはＦＱＤＮ（Full Qualified Domain Name）を特定する。ＳＲＶ Ｒｅｃｏｒｄ検索の結果がＦＱＤＮを示した場合は、ＤＮＳのＡ Ｒｅｃｏｒｄ検索を実行することによって、転送先ＳＩＰプロキシのＩＰアドレスを取得できる。尚、ドメイン名から転送先ＳＩＰプロキシのＩＰアドレスを取得する手順については、ＲＦＣ３２６３（非特許文献６）に記述されている。
【００１７】
ここで、接続先サーバの所属ドメインが、ＳＩＰメッセージを受信したＳＩＰプロキシの所属ドメインと同一であった場合、ＳＩＰプロキシは、受信メッセージのＲｅｑｕｅｓｔ−ＵＲＩに記述されたＳＩＰ−ＵＲＩを検索キーとして、ロケーションサービスＤＢ（データベース）から接続先サーバのＩＰアドレス（またはＦＱＤＮ）を取得し、このＩＰアドレスをＩＰパケットの宛先アドレスとして、ＳＩＰメッセージを接続先サーバに転送する。接続先サーバの所属ドメインがＳＩＰプロキシ（または送信元クライアント）の所属ドメインと異なった場合は、ＳＩＰメッセージは、接続先サーバの所属ドメインに位置した別のＳＩＰプロキシに転送され、転送先のＳＩＰプロキシが、ロケーションサービスＤＢから接続先サーバのＩＰアドレスまたはＦＱＤＮを取得して、ＳＩＰメッセージを接続先サーバに転送する。
【００１８】
上述したように、セッション管理サーバ（ＳＩＰプロキシ）経由のセッション設定を前提とするネットワークでは、セッション管理サーバが、受信したＳＩＰメッセージに含まれる要求リソース識別子（ＳＩＰ−ＵＲＩ）から、接続先サーバが所属するドメインを判定し、受信メッセージを接続先サーバあるいは接続先セッション管理サーバに転送するようになっている。しかしながら、ＩＰ網に接続されるクライアント端末上で実行される一般のアプリケーションプログラムは、接続先サーバの指定に、上述したＡＯＲ形式のＳＩＰ−ＵＲＩのようにＳＩＰのフレームワークにおける識別子ではなく、ＩＰアドレスのように接続先サーバのみを示す識別子を使用したり、ＵＲＬなどのようにドメイン名を含んでいても、ＳＩＰ−ＵＲＩとは異なるフレームワークの識別子を使用したりしている。
【００１９】
アプリケーションプログラムまたは暗号化通信ソフトが、接続先サーバをＩＰアドレスやＵＲＬで指定してサーバとの接続要求を発行し、クライアントが、接続先サーバをＩＰアドレスやＵＲＬで指定した形で接続要求ＳＩＰメッセージを送信した場合、セッション管理サーバ（ＳＩＰプロキシ）は、受信した接続要求メッセージの転送先ドメインを特定することができない。この場合、クライアントが図３に示した認証システムの利点を享受できないという問題がある。
【００２０】
本発明の目的は、接続先の装置をＩＰアドレスやＵＲＬのような、セッション管理サーバが採用しているものとは異なる、アプリケーションの仕様に応じた識別子（以降、接続先識別子とも呼ぶ）で指定したセッション制御メッセージをセッション管理サーバ経由で接続先サーバに転送可能にしたデータ通信方法およびシステムを提供することにある。
本発明の他の目的は、接続先サーバを接続先識別子で指定したクライアントからの接続要求をセッション管理サーバ経由で当該接続先サーバに転送可能にしたデータ通信方法およびシステムを提供することにある。
本発明の更に他の目的は、クライアントとサーバとの間の暗号化データ通信を可能にし、且つ、暗号化データ通信に先立って必要となるクライアントとサーバとの間の認証手順を容易にしたデータ通信方法およびシステムを提供することにある。
【課題を解決するための手段】
【００２１】
上記目的を達成するため、本発明では、クライアントのアプリケーションプログラムまたは暗号化通信ソフトが、接続先サーバを接続先識別子で指定した形で接続要求を発行した時、クライアントまたはセッション管理サーバまたは識別情報管理サーバで、上記接続先識別子をセッション管理サーバがドメイン識別可能な所望のリソース識別子に自動的に変換することを特徴とする。
【００２２】
本発明によるクライアントとサーバとの間のデータ通信方法は、クライアントからセッション管理サーバあるいは識別情報管理サーバに、接続先の接続先識別子を指定して、該接続先サーバに割り当てられた所属ドメイン名を含むリソース識別子を問い合わせる第１ステップと、上記セッション管理サーバあるいは識別情報管理サーバが、接続先識別子とリソース識別子との対応関係を管理しているロケーションテーブルから、上記接続先サーバの接続先識別子と対応するリソース識別子を取得し、上記クライアントに通知する第２ステップと、上記クライアントから上記セッション管理サーバに、要求リソースを上記接続先サーバのリソース識別子で指定した接続要求メッセージを送信する第３ステップと、上記セッション管理サーバが、受信した接続要求メッセージに記述された上記リソース識別子に含まれるドメイン名に基づいて受信メッセージの転送先を判定し、受信メッセージを接続先サーバまたは該接続先サーバの所属ドメインを管理する別のセッション管理サーバに転送する第４ステップとからなることを特徴とする。
【００２３】
更に詳述すると、本発明のデータ通信方法は、接続要求メッセージの受信に応答して、接続先サーバからセッション管理サーバを介して要求元クライアントに、暗号化通信に必要となるパラメータ情報を含む接続応答メッセージを返送する第５ステップと、上記クライアントと接続先サーバとの間で、上記接続応答メッセージで指定されたパラメータ情報に従って暗号化されたメッセージを含むパケットを通信する第６ステップを含む。
【００２４】
上記セッション管理サーバは、例えば、ＳＩＰ（Session Initiation Protocol）サーバからなる。この場合、クライアントとセッション管理サーバとの間の通信メッセージは、例えば、ＲＦＣ３２６１に規定されたＴＬＳ（Transport Layer Security）によって暗号化され、クライアントと接続先サーバとの間の通信データは、例えば、ＲＦＣ２４０１に規定されたＩＰｓｅｃ（Internet Protocol Security）によって暗号化される。
【００２５】
本発明によって提供されるセッション管理サーバは、クライアントから、要求リソースを接続先サーバの接続先識別子で指定した接続要求メッセージを受信した時、接続先識別子とリソース識別子との対応関係を管理しているロケーションテーブルから、上記接続先サーバの接続先識別子と対応するリソース識別子を取得し、受信メッセージに記述された要求リソースを接続先識別子から上記リソース識別子に書き換えるための手段と、上記リソース識別子に含まれるドメイン名に基づいて受信メッセージの転送先を判定し、受信メッセージを接続先サーバまたは該接続先サーバの所属ドメインを管理する別のセッション管理サーバに転送するための手段とを備えたことを特徴とする。
【００２６】
上記セッション管理サーバは、具体的には、通信ネットワークに接続されたネットワークインタフェース部と、セッション制御メッセージを処理するメッセージ処理部と、上記ネットワークインタフェース部から受信した暗号化メッセージを復号化して上記メッセージ処理部に渡すと共に、上記メッセージ処理部から出力されたセッション制御メッセージを暗号化して上記ネットワークインタフェース部に出力するためのセキュリティ部とを有し、上記メッセージ処理部が、上述した要求リソースの書き換え手段と受信メッセージの転送手段を備える。
【００２７】
本発明によって提供されるクライアント端末は、通信ネットワークに接続されたネットワークインタフェース部と、セッション制御メッセージを処理するメッセージ処理部と、アプリケーションプログラムが発生する接続先サーバ宛の送信メッセージを暗号化して上記ネットワークインタフェース部に出力すると共に、上記ネットワークインタフェース部から受信した暗号化メッセージを復号化して上記アプリケーションプログラムに渡すための第１セキュリティ部と、上記セキュリティ部から、接続先サーバとの暗号化パラメータの交換要求が発生した時、接続先サーバを接続先識別子で指定した接続要求メッセージを上記メッセージ処理部に出力し、上記メッセージ処理部から接続応答メッセージを受信した時、該受信メッセージから抽出した暗号化パラメータを上記第１セキュリティ部に渡すセキュリティ情報制御部とからなり、
上記メッセージ処理部が、上記セキュリティ情報制御部から接続要求メッセージを受信した時、上記接続先識別子に基づいて上記セッション管理サーバまたは接続先サーバから接続先サーバのリソース識別子を取得し、該リソース識別子で要求リソースを指定した形で、上記接続要求メッセージを上記セッション管理サーバに送信することを特徴とする。
【００２８】
実際の応用では、本発明のクライアント端末は、上記ネットワークインタフェース部から受信した暗号化されたセッション制御メッセージを復号化して上記メッセージ処理部に渡すと共に、上記メッセージ処理部から出力されたセッション制御メッセージを暗号化して上記ネットワークインタフェース部に出力するための第２セキュリティ部を有し、
接続先サーバとの通信データが上記第１セキュリティ部によって暗号化され、セッション管理サーバと通信メッセージが上記第２セキュリティ部によって暗号化される。
【発明の効果】
【００２９】
本発明によれば、クライアントのアプリケーションプログラムまたは暗号化通信ソフトから、要求リソース（接続先サーバ）を接続先識別子で指定した形で接続要求が発行された場合でも、接続要求メッセージの要求リソースを接続先識別子からドメイン識別可能なリソース識別子に自動的に変換できる。従って、接続要求メッセージを転送制御するセッション管理サーバにおいて、受信メッセージのリソース識別子から転送先ドメインを判定し、受信メッセージを接続先サーバ、または接続先サーバの所属ドメインに位置した別のセッション管理サーバに転送することが可能となる。
本発明によれば、一般のアプリケーションプログラムを実行するクライアントでも、セッション管理サーバによる認証機能を利用することによって、接続先サーバとの間で容易に暗号化通信を実現できる。
【発明を実施するための最良の形態】
【００３０】
以下、本発明の実施例について図面を参照して説明する。
図４は、本発明が適用されるネットワーク構成の１例を示す。
ここに示したネットワークは、ＳＩＰサーバＳＩＰａが管理する第１ドメインを形成する第１のネットワークＮＷ１と、ＳＩＰサーバＳＩＰｂが管理する第２ドメインを形成する第２のネットワークＮＷ２と、ロケーションサーバＬＳＶと、ＤＮＳ（Domain Name System）とからなる。
【００３１】
第１のネットワークＮＷ１には、クライアントＣＬ１ａ、ＣＬ２ａと、サーバＳＶ１ａ、ＳＶ２ａが接続され、第２のネットワークＮＷ２には、クライアントＣＬ１ｂ、ＣＬ２ｂと、サーバＳＶ１ｂ、ＳＶ２ｂが接続されている。また、ＳＩＰサーバＳＩＰａは、ＳＩＰプロキシＰＲａとレジストラＰＧａとからなり、ＳＩＰサーバＳＩＰｂは、ＳＩＰプロキシＰＲｂとレジストラＰＧｂとからなっている。
【００３２】
ここで、各クライアントおよびサーバに付随して括弧内に示した文字列は、ＳＩＰメッセージの転送先識別子（リソース識別子）となるＡＯＲ（Address-of-Record）形式のＳＩＰ−ＵＲＩの値を示している。第１ネットワークＮＷ１に接続されたクライアントとサーバには、ＳＩＰサーバＳＩＰａのドメイン識別子「aaa.com」を含むＡＯＲが割り当てられ、第２ネットワークＮＷ２に接続されたクライアントとサーバには、ＳＩＰサーバＳＩＰｂのドメイン識別子「bbb.com」を含むＡＯＲが割り当てられている。
【００３３】
本発明のＳＩＰサーバＳＩＰａ、ＳＩＰｂは、それぞれの管轄下にあるクライアントから、接続先サーバをＵＲＬで指定したＳＩＰメッセージを受信した時、ロケーションサーバＬＳＶに、上記接続先ＵＲＬと対応するＡＯＲ（リソース識別子）の検索（ロケーションデータ検索）を要求する。また、ＳＩＰサーバＳＩＰａ、ＳＩＰｂは、それぞれ他のＳＩＰサーバから、接続先サーバをＡＯＲで指定したＳＩＰメッセージを受信した時、ロケーションサーバＬＳＶに、上記接続先ＡＯＲと対応するＩＰアドレスの検索を要求する。
【００３４】
ロケーションサーバＬＳＶは、ロケーションサービス・データベース（ＤＢ）に、例えば、図５に示すように、ＳＩＰサーバＳＩＰａ、ＳＩＰｂの管轄下にあるクライアントおよびサーバと対応した複数のエントリＥＮ−１、ＥＮ−２，・・・からなり、各エントリが、クライアントまたはサーバのＡＯＲ６１とＩＰアドレス６２との対応関係を示すロケーションサービステーブル６０を格納する。また、ロケーションサーバＬＳＶは、ＳＩＰサーバＳＩＰａ、ＳＩＰｂの管轄下にあるクライアントおよびサーバと対応した複数のエントリＲＥＮ−１、ＲＥＮ−２，・・・からなり、各エントリが、クライアントまたはサーバのアプリケーションプログラムや暗号化通信ソフトが通信相手の装置を識別するために用いる情報である識別情報６３と、ＡＯＲ６１との対応関係を示す識別情報管理テーブル６４と、を備えている。ロケーションサーバＬＳＶは、ＳＩＰサーバからの検索キーとしてＡＯＲを指定されたロケーションデータ検索要求を受信した場合、上記ロケーションサービステーブル６０から、当該ＡＯＲと対応するＩＰアドレスを検索し、検索結果を要求元ＳＩＰサーバに返送する。同様に、ロケーションサーバＬＳＶは、ＳＩＰサーバからの検索キーとしてＵＲＬ等の識別情報６３を指定されたロケーションデータ検索要求を受信した場合、上記識別情報管理テーブル６４から、当該識別情報６３と対応するＡＯＲを検索し、検索結果を要求元ＳＩＰサーバに返送する。なお、本実施例では、識別情報６３にはＵＲＬやＵＲＩやＩＰアドレスなどが使用可能である。識別情報６３はこれらＵＲＬ等に限られず、それぞれの装置に独自に割り当てられ互いに識別が可能な情報であればよい。なお、ＩＰアドレスを使用する場合には、ＵＲＬやＵＲＩとの区別を容易にするため、ＩＰアドレスの先頭に「ipv4:」や「ipv6:」などのプレフィックスをつけることが望ましい。
【００３５】
図６は、ＳＩＰプロキシＰＲａのハードウェア構成を示す。ＳＩＰプロキシＰＲａは例えば、プロセッサ（ＣＰＵ）１１と、プロセッサが実行する各種ソフトウェアとデータを記憶するためのメモリ１２およびハードディスク１３と、ネットワークＮＷ１（ＮＷ２）に接続するためのネットワークインタフェース１４と、入出力装置１５とからなり、これらの要素は内部バス１６によって相互接続されている。ＳＩＰプロキシＰＲｂ、レジストラＲＧａ、ＲＧｂ、クライアントＣＬ１ａ〜ＣＬ２ｂ、サーバＳＶ１ａ〜ＳＶ２ｂも、基本的には、図６に示したＳＩＰプロキシＰＲａと同様の構成要素からなる。
【００３６】
以下、図４に示した第１ドメインに所属するクライアントＣＬ１ａが、第２ドメインに所属するサーバＳＶ１ｂと暗号化データ通信する場合の通信手順を例にして、本発明の第１の実施例について説明する。
【００３７】
図７は、クライアントＣＬ１ａの基本的なソフトウェア構造の一例を示す。他のクライアントＣＬ１ｂ〜ＣＬ２ｂも、これと同様のソフトウェア構造をとりうる。クライアントＣＬ１ａのソフトウェアは、ネットワークインタフェースカード部（ＮＩＣ）２０Ｃと、暗号化／復号化機能を備えた暗号エンジン３１Ｃを含む暗号化通信機能部３０Ｃと、アプリケーションプログラム４０Ｃと、鍵管理プロセス部５０Ｃとからなる。第１実施例では、鍵管理プロセス部５０Ｃが、暗号化通信制御部５１Ｃと、ＴＬＳ（Transport Layer Security）部５２Ｃと、ＳＩＰメッセージ処理部５３Ｃとを備えたことを特徴としている。
【００３８】
図８は、サーバＳＶ１ｂの基本的なソフトウェア構造の一例を示す。他のサーバＳＶ１ａ、ＳＶ２ａ、ＳＶ２ｂも、これと同様のソフトウェア構造をとりうる。サーバＳＶ１ｂのソフトウェアは、ネットワークインタフェースカード部（ＮＩＣ）２０Ｓと、ＩＰｓｅｃ暗号化／復号化機能を備えた暗号エンジン３１Ｓを含む暗号化通信機能部３０Ｓと、アプリケーションプログラム４０Ｓと、鍵管理プロセス部５０Ｓとからなり、鍵管理プロセス部５０Ｓが、暗号化通信制御部５１Ｓと、ＴＬＳ部５２Ｓと、ＳＩＰメッセージ処理部５３Ｓとを備えている。
【００３９】
本実施例では、クライアントＣＬ１ａのアプリケーションプログラム４０ＣとサーバＳＶ１ｂのアプリケーションプログラム４０Ｓは、それぞれが備える暗号エンジン３１Ｃ、３１ＳのＩＰｓｅｃ暗号化／復号化機能を利用して、ＩＰｓｅｃによる暗号化データを通信する。一方、クライアントＣＬ１ａのＳＩＰメッセージ処理部５３Ｃは、後述するＳＩＰサーバＳＩＰａ（ＳＩＰプロキシＰＲａ、レジストラＲＧａ）のＳＩＰメッセージ処理部との間で、それぞれが備えるＴＬＳ部のメッセージ暗号化／復号化機能を利用して、暗号化されたＳＩＰメッセージを通信する。同様に、サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓも、ＳＩＰサーバＳＩＰａ（ＳＩＰプロキシＰＲａ、レジストラＲＧａ）のＳＩＰメッセージ処理部との間で、それぞれが備えるＴＬＳ部のメッセージ暗号化／復号化機能を利用して、暗号化されたＳＩＰメッセージを通信する。
【００４０】
図９は、ＳＩＰプロキシＰＲａの基本的なソフトウェア構造の一例を示す。ＳＩＰプロキシＰＲｂも、これと同様のソフトウェア構造をとりうる。ＳＩＰプロキシＰＲａのソフトウェアは、ネットワークインタフェースカード部（ＮＩＣ）２０Ｐと、暗号化通信機能部３０Ｐと、鍵管理プロセス部５０Ｐとからなる。鍵管理プロセス部５０Ｐが、ＴＬＳ部５２Ｐと、ＳＩＰメッセージ処理部５３Ｐとを備えている。ＳＩＰメッセージ処理部５３Ｐは、後述するＳＩＰ−ＵＲI（ＡＯＲ）検索機能５４を備えている。ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐは、ＴＬＳ部５２Ｐのメッセージ暗号化／復号化機能を利用して、管理下にあるドメインに所属したクライアント、サーバ、および他のドメインを管理する他のＳＩＰプロキシ、例えばＰＲｂと暗号化メッセージを通信する。
【００４１】
図１０は、レジストラＲＧａの基本的なソフトウェア構造の一例を示す。レジストラＲＧｂも、これと同様のソフトウェア構造をとりうる。レジストラＲＧａのソフトウェアは、ネットワークインタフェースカード部（ＮＩＣ）２０Ｒと、暗号化通信機能部３０Ｒと、メッセージの暗号化／復号化機能を備えたＴＬＳ部５２Ｒと、ＳＩＰメッセージ処理部５３Ｒと、レジストラ処理部６０Ｒとからなっている。ＳＩＰメッセージ処理部５３Ｒは、クライアントが発行したＡＯＲ取得要求、またはＳＩＰプロキシＰＲａが発行したＡＯＲ取得要求を受信すると、レジストラ処理部６０Ｒにロケーションデータの検索を要求する。レジストラ処理部６０Ｒは、ＳＩＰメッセージ処理部５３Ｒからの要求に応答して、ロケーションサーバＬＳＶが備えるロケーションサービスＤＢをアクセスする。尚、レジストラＲＧａとＳＩＰプロキシＰＲａとの間の通信には、暗号化を適用しなくてもよい。
【００４２】
図１１と図１２は、本発明による暗号化データ通信の第１の実施例を示すシーケンス図である。第１の実施例では、クライアントＣＬ１ａがＡＯＲ取得要求を発行する。本実施例において、クライアントＣＬ１ａからの接続要求先となる第２ネットワークに接続されたサーバＳＶ１ｂは、クライアントＣＬ１ａからの接続要求に先立って、ＳＩＰサーバＳＩＰｂのレジストラＲＧｂとの間で、サーバＳＶ１ｂの認証と暗号化通信用のパラメータ設定のためのＴＬＳネゴシェーション（Ｓ１）を実行した後、レジストラＲＧｂにロケーション登録要求メッセージ（ＳＩＰメッセージ：REGISTER）Ｍ１を送信する。
【００４３】
ロケーション登録要求メッセージＭ１は、例えば、図１３に示すように、ＩＰヘッダＨ１と、ＵＤＰ／ＴＣＰヘッダＨ２とを付したＩＰパケット形式で送信される。ＩＰヘッダＨ１は、宛先アドレスとしてレジストラＲＧｂ（ＳＩＰサーバＳＩＰｂ）のＩＰアドレス、送信元アドレスとしてサーバＳＶ１ｂのＩＰアドレスを含む。
【００４４】
ＳＩＰメッセージは、ＳＩＰメッセージの種類（Request-Method）を示すスタートラインと、要求または応答内容を記述したヘッダ部と、必要に応じてセッション内容を記述したメッセージボディ部とからなる。メッセージの種類によっては、上記スタートラインに、該メッセージの宛先を示すリソース識別子（Request-URI）が記述される。また、メッセージボディ部におけるセッション内容の記述には、ＲＦＣ３２６６で仕様化されたＳＤＰ（Session Description Protocol）が適用される。
【００４５】
サーバＳＶ２ｂが発行するロケーション登録要求メッセージＭ１の場合、スタートラインには、ＳＩＰメッセージの種類として「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）情報を検索する。ここで、ＳＡＤＢ３３Ｃに当該通信に適用すべきＳＡ情報が未登録の場合、暗号化通信制御部５１Ｃは、通信相手との暗号化パラメータの交換（鍵交換）を実施する。
【００７３】
暗号化通信制御部５１Ｃは、ＤＮＳ等を参照して取得した、上記ＵＲＬが示すＴＣＰ／ＩＰ通信パラメータと、暗号化通信制御部５１Ｃが管理している利用可能なＳＡ情報とに基づいて、図１８に例示した接続要求メッセージのボディ部Ｍ５−２を作成し（ステップ１０３）、該接続要求メッセージボディ部Ｍ５−２と上記ＳＩＰ−ＵＲＬとをＳＩＰメッセージ処理部５３Ｃに渡し（１０４）、ＳＩＰメッセージ処理部５３Ｃからの接続応答メッセージボディ部の受信を待つ（１０５）。
【００７４】
暗号化通信制御部５１Ｃは、ＳＩＰメッセージ処理部５３Ｃから、図２４に例示した接続応答メッセージボディ部Ｍ１０−２を受信すると、受信した接続応答メッセージボディ部を解析し、今回の暗号化通信に使用すべきＳＡ情報を決定し（、ＳＡＤＢ３３Ｃに設定する（１０６）と、暗号エンジン３１Ｃに暗号化通信の適用要否判定結果を通知する（１０７）。
【００７５】
図３９Ａは、暗号化通信制御部５１ＣからＳＩＰ−ＵＲＩ取得を要求された場合、ＳＩＰメッセージ処理部５３Ｃが実行する制御動作のフローチャート１１０を示す。
ＳＩＰメッセージ処理部５３Ｃは、暗号化通信制御部５１ＣからＵＲＬを受信すると、図１５に例示したＡＯＲ取得要求メッセージＭ３を作成し（ステップ１１１）、該メッセージをＴＳＬ部５２Ｃ、ＴＣＰ／ＩＰ部３０Ｃ、ＮＩＣ部２０Ｃを介して、クライアントＣＬ１ａと同一ドメインに位置するＳＩＰサーバＳＩＰａ（レジストラＲＧａ）宛に送信する（１１２）。このとき、ＴＬＳ部５２Ｃは、レジストラＲＧａとの間でＴＬＳネゴシェーション（図１１のＳ５）を実行した後、ＴＬＳ暗号化されたＡＯＲ取得要求メッセージＭ３をＴＣＰ／ＩＰ部３０Ｃ、ＮＩＣ部２０Ｃを介してレジストラＲＧａに送信する。上記ＡＯＲ取得要求メッセージＭ３は、ＴＣＰ／ＩＰ部３０Ｃによって、ＳＩＰサーバＳＶ１宛の宛先ＩＰアドレスを含むＩＰヘッダＨ１とＵＤＰ／ＴＣＰヘッダＨ２とが付加され、ＩＰパケット形式でネットワークＮＷ１に送出される。
【００７６】
ＳＩＰメッセージ処理部５３Ｃは、レジストラＲＧａからのＡＯＲ取得応答メッセージを待っており（１１３）、ＡＯＲ取得応答メッセージを受信すると、受信メッセージを解析し（１１４）、ＡＯＲヘッダから接続先サーバに割り当てられたＡＯＲ形式のＳＩＰ−ＵＲＩを抽出する（１１５）。
【００７７】
図３９Ｂは、暗号化通信制御部５１Ｃから接続要求メッセージのボディ部を受信した時、ＳＩＰメッセージ処理部５３Ｃが実行する制御動作のフローチャート１２０を示す。
【００７８】
ＳＩＰメッセージ処理部５３Ｃは、暗号化通信制御部５１Ｃから接続要求メッセージのボディ部とＳＩＰ−ＵＲIとを受信すると、上記ＳＩＰ−ＵＲＩをスタートラインとＴｏヘッダに適用して、ヘッダ部Ｍ５−１と暗号化通信制御部５１Ｃから受信したボディ部Ｍ５−２とからなる図１７に例示した接続要求メッセージＭ５を作成する（１２１）。
【００７９】
ＳＩＰメッセージ処理部５３Ｃは、上記接続要求メッセージをＴＳＬ部５２Ｃ、ＴＣＰ／ＩＰ部３０Ｃ、ＮＩＣ部２０Ｃを介して、ＳＩＰサーバＳＩＰａのＳＩＰプロキシＰＲａ宛に送信し（１２２）、ＳＩＰプロキシＰＲａからの応答を待つ（１２３）。ＳＩＰプロキシＰＲａから接続中メッセージＭ６を受信した場合は、接続中メッセージ処理（１２４）を実行した後、ＳＩＰプロキシＰＲａからの次の応答を待つ。
【００８０】
ＳＩＰメッセージ処理部５３Ｃは、ＳＩＰプロキシＰＲａから接続応答メッセージＭ１２を受信すると、受信メッセージを解析し（１２５）、受信メッセージから抽出した図２４に例示した接続応答メッセージボディ部Ｍ１２−２を暗号化通信制御部５１Ｃに渡す（１２６）。この後、ＳＩＰメッセージ処理部５３Ｃは、図２７に例示した接続確認メッセージＭ１３を作成し、これをＴＳＬ部５２Ｃ、ＴＣＰ／ＩＰ部３０Ｃ、ＮＩＣ部２０Ｃを介して、ＳＩＰプロキシＰＲａ宛に送信し（１２７）、このルーチンを終了する。
【００８１】
図４０は、ＡＯＲ取得要求メッセージＭ３を受信した時、レジストラＲＧａのＳＩＰメッセージ処理部５３Ｒが実行する制御動作のフローチャート２００を示す。レジストラＲＧａのＳＩＰメッセージ処理部５３Ｒは、受信したＡＯＲ取得要求メッセージＭ３を解析し（ステップ２０１）、Ｔｏヘッダが示す接続先サーバＳＶ１ｂのＵＲＬを検索キーとして、ロケーションデータ検索クエリを作成し（２０２）、レジストラ処理部６０Ｒを介して、上記検索クエリをロケーションサーバＬＳＶに送信し（２０３）、ロケーションサーバからの応答を待つ（２０４）。
【００８２】
ＳＩＰメッセージ処理部５３Ｒは、レジストラ処理部６０Ｒを介して、ロケーションサーバＬＳＶからロケーションデータを受信すると、受信データが示すＳＩＰ−ＵＲＩをＡＯＲヘッダとして含む図１６に例示したＡＯＲ取得応答メッセージＭ４を作成し（２０５）、該メッセージＭ４をＴＣＰ／ＩＰ部３０Ｒ、ＮＩＣ部２０Ｒを介してＡＯＲ取得要求メッセージＭ３の送信元（この例では、クライアントＣＬ１ａ）に送信し（２０６）、このルーチンを終了する。
【００８３】
図４１（図４１Ａ〜図４１Ｄ）は、クライアントＣＬ１ａから接続要求メッセージＭ５を受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作のフローチャート３００を示す。ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐは、クライアントＣＬ１ａからの接続要求メッセージＭ５を受信すると、受信メッセージを解析し（ステップ３０１）、受信メッセージのスタートラインに記述されたＲｅｑｕｅｓｔ−ＵＲＩをチェックして（３０２）、上記Ｒｅｑｕｅｓｔ−ＵＲＩが示すドメイン名から、受信メッセージの転送先を判定する（３０３）。
【００８４】
受信メッセージの転送先が他のドメインに所属していると判定された場合、ＳＩＰメッセージ処理部５３Ｐは、ＤＮＳ検索（ＮＡＰＴＲ検索＋ＳＲＶ検索＋Ａ検索）等によって、受信メッセージの転送先ドメインのＳＩＰサーバ（ＳＩＰプロキシ）を決定する（３０４）。図１１で示した例では、ＤＮＳ検索によって、接続要求メッセージＭ５の転送先が、ＳＩＰプロキシＰＲｂであることが判明する。この場合、ＳＩＰメッセージ処理部５３Ｐは、図１９で例示した接続中メッセージＭ６をＴＬＳ部５２Ｐ、ＴＣＰ／ＩＰ部３０Ｐ、ＮＩＣ部２０Ｐを介して、接続要求メッセージＭ５の送信元であるクライアントＣＬ１ａに送信（３０５）した後、接続要求メッセージＭ５に新たなＶｉａヘッダを付加した形の接続要求メッセージＭ７をＳＩＰプロキシＰＲｂに転送して（３０６）、ＳＩＰプロキシＰＲｂからの応答を待つ（３０７）。
【００８５】
ＳＩＰメッセージ処理部５３Ｐは、ＳＩＰプロキシＰＲｂから接続中メッセージＭ８を受信すると、接続中メッセージ処理（３０８）を実行した後、ＳＩＰプロキシＰＲｂからの次の応答を待つ。ＳＩＰメッセージ処理部５３Ｐは、ＳＩＰプロキシＰＲｂから接続応答メッセージＭ１１を受信すると、受信メッセージを解析し（３０９）、受信メッセージから自ＳＩＰ−ＵＲＩを含むＶｉａヘッダを除去し、接続応答メッセージＭ１２として、接続要求元（クライアントＣＬ１ａ）に転送する（３１０）。この後、ＳＩＰメッセージ処理部５３Ｐは、接続要求元（クライアントＣＬ１ａ）からの応答を待つ（３１１）。ＳＩＰメッセージ処理部５３Ｐは、接続確認メッセージＭ１３を受信すると、受信メッセージを解析し（３１２）、受信メッセージに自分のＳＩＰ−ＵＲＩを含む新たなＶｉａヘッダを付加し、接続確認メッセージＭ１３として、ＳＩＰプロキシＰＲｂに転送して（３１３）、このルーチンを終了する。
【００８６】
判定ステップ３０３で、クライアント端末ＣＬ１ａから受信した接続要求メッセージの転送先が、例えば、サーバＳＶ１ａ（またはＳＶ２ａ）のように、ＳＩＰプロキシＰＲａと同一ドメインに所属していると判定された場合、ＳＩＰメッセージ処理部５３Ｐは、受信メッセージのＲｅｑｕｅｓｔ−ＵＲＩが示すＳＩＰ−ＵＲＩを検索キーとするロケーションデータ（ＩＰアドレス）検索クエリを作成し（３１５）、該ロケーションデータ検索クエリをロケーションサーバＬＳＶに送信して（３１６）、ロケーションサービス応答を待つ（３１７）。
【００８７】
ＳＩＰメッセージ処理部５３Ｐは、ロケーションサーバＬＳＶからロケーションデータを受信すると、上記ロケーションデータが示す接続先サーバのＩＰアドレスを宛先ＩＰアドレスに適用して、接続要求メッセージをＩＰパケット形式でネットワークＮＷ１に送信し（３１８）、接続先サーバからの応答を待つ（３１９）。上記接続要求メッセージには、ＳＩＰプロキシＰＲａのＳＩＰ−ＵＲＩを含む新たなＶｉａヘッダが付加されている。
【００８８】
接続先サーバから接続応答メッセージを受信すると、ＳＩＰメッセージ処理部５３Ｐは、受信メッセージを解析し（３２０）、自分と対応するＶｉａヘッダを除去した形の接続応答メッセージを接続要求元に転送して（３２１）、接続要求元（クライアントＣＬ１ａ）からの応答を待つ（３２２）。ＳＩＰメッセージ処理部５３Ｐは、接続要求元から接続確認メッセージを受信すると、受信メッセージを解析し（３２３）、新たなＶｉａヘッダを付加した形の接続確認メッセージを接続先サーバに転送して（３２４）、このルーチンを終了する。
【００８９】
図４２（図４２Ａ、図４２Ｂ）は、接続先サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓが、ＳＩＰプロキシＰＲｂから接続要求メッセージＭ９を受信した時に実行する制御動作のフローチャート４００を示す。ＳＩＰプロキシＰＲｂから接続先サーバＳＶ１ｂに送信された接続要求メッセージＭ９は、ＴＬＳ部５２Ｓで復号した後、ＳＩＰメッセージ処理部５３Ｓに入力される。ＳＩＰメッセージ処理部５３Ｓは、接続要求メッセージＭ９を受信すると、受信メッセージを解析し（ステップ４０１）、受信メッセージから抽出した接続要求メッセージボディ部Ｍ５−２を暗号化通信制御部５１Ｓに渡し（４０２）、暗号化通信制御部５１Ｓからの応答を待つ（４０３）。
【００９０】
ＳＩＰメッセージ処理部５３Ｓは、暗号化通信制御部５１Ｓから接続応答メッセージボディ部Ｍ１０−２を受信すると、図２５に例示した接続応答メッセージＭ１１を作成する（４０４）。ＳＩＰメッセージ処理部５３Ｓは、ＴＬＳ部、ＴＣＰ／ＩＰ部、ＮＩＣ部を介して、上記接続応答メッセージＭ１１をＳＩＰプロキシＰＲｂに転送し（４０５）、ＳＩＰプロキシＰＲｂからの応答を待つ（４０６）。ＳＩＰメッセージ処理部５３Ｓは、ＳＩＰプロキシＰＲｂから、接続確認メッセージＭ１５を受信すると、受信メッセージを解析し（４０７）、接続確認メッセージＭ１５を受信したことを暗号化通信制御部５１Ｓに通知して（４０８）、このルーチンを終了する。
【００９１】
図４３は、ＳＩＰメッセージ処理部５３Ｓから接続要求メッセージボディ部Ｍ５−２を受信した時、サーバＳＶ１ｂの暗号化通信制御部５１Ｓが実行する制御動作の示すフローチャート４２０を示す。
暗号化通信制御部５１Ｓは、ＳＩＰメッセージ処理部５３Ｓから受信した接続要求メッセージボディ部Ｍ５−２を解析し（ステップ４２１）、接続要求メッセージボディ部Ｍ５−２に記述されたＳＡ情報（図１８の例では、トランスフォームペイロード９２−１、９２−２）から、クライアントとの暗号化通信に適用すべきＳＡを選択して、図２４に例示した接続応答メッセージのボディ部Ｍ１０−２を作成する（４２２）。暗号化通信制御部５１Ｓは、上記接続応答メッセージボディ部Ｍ１０−２をＳＩＰメッセージ処理部５３Ｓに渡し（４２３）、ＳＩＰメッセージ処理部５３Ｓからの応答を待つ（４２４）。暗号化通信制御部５１Ｓは、ＳＩＰメッセージ処理部５３Ｓから接続確認メッセージの受信通知を受けると、ＳＡＤＢ３３ＳにＳＡ情報を設定して（４２５）、このルーチンを終了する。
【００９２】
図４４は、クライアントＣＬ１ａにおいて、暗号エンジン３１Ｃが発行する通信終了要求に応答して暗号化通信制御部５１Ｃが実行する制御動作のフローチャート１３０を示す。クライアントＣＬ１ａのユーザが、サーバＳＶ１ｂと交信していたアプリケーションを終了すると、暗号エンジン３１Ｃから暗号化通信制御部５１Ｃに、通信終了要求が発行される。ＳＡ／ＳＰ制御部５１Ｃは、暗号エンジン３１Ｃから通信終了要求を受信すると、ＳＩＰメッセージ処理部５３Ｃに、切断要求メッセージの発行を要求し（１３１）、ＳＩＰメッセージ処理部５３Ｃからの応答を待つ（１３２）。ＳＡ／ＳＰ制御部５１Ｃは、ＳＩＰメッセージ処理部５３Ｃから切断応答メッセージの受信通知を受けると、上記暗号鍵消去要求と対応するＳＡＤＢ３３Ｓの設定値を消去し（１３３）、このルーチンを終了する。
【００９３】
図４５は、ＳＡ／ＳＰ制御部５１Ｃから切断要求メッセージの発行要求を受信した時にＳＩＰメッセージ処理部５３Ｃが実行する制御動作のフローチャート１４０を示す。ＳＩＰメッセージ処理部５３Ｃは、ＳＡ／ＳＰ制御部５１Ｃから切断要求メッセージの発行要求を受信すると、図３０に例示した切断要求メッセージＭ２０を作成し（ステップ１４１）、ＴＬＳ部５２Ｃ、ＴＣＰ／ＩＰ部３０Ｃの暗号エンジン３１Ｃ、ＮＩＣ部２０Ｃを介して、上記切断要求メッセージＭ２０のＩＰパケットをＳＩＰサーバＳＩＰａ（ＳＩＰプロキシＰＲａ）に送信する（１４２）。
【００９４】
ＳＩＰメッセージ処理部５３Ｃは、ＳＩＰプロキシＰＲａからの応答を待ち（１４３）、切断中メッセージＭ２１を受信した場合は、切断中メッセージ処理（１４４）を実行した後、ＳＩＰプロキシＰＲａからの次の応答を待つ。ＳＩＰメッセージ処理部５３Ｃは、ＳＩＰプロキシＰＲａから図３７に例示した切断応答メッセージＭ２７を受信すると、受信メッセージを解析し（１４５）、暗号化通信制御部５１Ｃに切断応答メッセージの受信を通知し（１４６）、このルーチンを終了する。
【００９５】
図４６（図４６Ａ、図４６Ｂ）は、クライアントから切断要求メッセージＭ２０を受信した時にＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作のフローチャート３４０を示す。ＳＩＰメッセージ処理部５３Ｐは、受信した切断要求メッセージＭ２０を解析し（ステップ３４１）、受信メッセージのＲｅｑｕｅｓｔ−ＵＲＩをチェックする（３４２）。ＳＩＰメッセージ処理部５３Ｐは、Ｒｅｑｕｅｓｔ−ＵＲＩに記述されたドメイン名から、受信メッセージの転送先を判定し（３４３）、転送先が他のドメインに所属していると判定された場合、ＤＮＳ検索（ＮＡＰＴＲ検索＋ＳＲＶ検索＋Ａ検索）等によって、受信メッセージの転送先ドメインのＳＩＰサーバ（ＳＩＰプロキシ）を決定する（３４４）。
【００９６】
図１２で示した例では、上記ＤＮＳ検索によって、切断要求メッセージＭ２０の転送先が、ＳＩＰプロキシＰＲｂであることが判明する。この場合、ＳＩＰメッセージ処理部５３Ｐは、ＴＬＳ部５２Ｐ、ＴＣＰ／ＩＰ部３０Ｐ、ＮＩＣ部２０Ｐを介して、切断要求メッセージＭ２０の送信元であるクライアントＣＬ１ａに、図３１に例示した切断中メッセージＭ２１を送信（３４５）した後、切断要求メッセージＭ２０に新たなＶｉａヘッダを付加し、ＳＩＰプロキシＰＲａに対応するＲｏｕｔｅヘッダを除去した切断要求メッセージＭ２２をＳＩＰプロキシＰＲｂに転送し（３４６）、ＳＩＰプロキシＰＲｂからの応答を待つ（３４７）。
【００９７】
ＳＩＰメッセージ処理部５３Ｐは、ＳＩＰプロキシＰＲｂから切断中メッセージＭ２３を受信すると、切断中メッセージ処理（３４８）を実行した後、ＳＩＰプロキシＰＲｂからの次の応答を待つ。ＳＩＰメッセージ処理部５３Ｐは、ＳＩＰプロキシＰＲｂから切断応答メッセージＭ２６を受信すると、受信メッセージを解析し（３４９）、受信メッセージから自ＳＩＰ−ＵＲＩを含むＶｉａヘッダを除去し、切断応答メッセージＭ２７として、切断要求元（クライアントＣＬ１ａ）に転送し（３５０）、このルーチンを終了する。
【００９８】
尚、判定ステップ３４３で、もし、クライアント端末ＣＬ１ａから受信した切断要求メッセージＭ２０の転送先が、ＳＩＰプロキシＰＲａと同一ドメインに所属していると判定された場合、ＳＩＰメッセージ処理部５３Ｐは、受信メッセージのＲｅｑｕｅｓｔ−ＵＲＩが示すＳＩＰ−ＵＲＩを検索キーとするロケーションデータ（ＩＰアドレス）検索クエリを作成し（３５１）、該検索クエリをロケーションサーバＬＳＶに送信して（３５２）、ロケーションサービス応答を待つ（３５３）。
【００９９】
ＳＩＰメッセージ処理部５３Ｐは、ロケーションサーバＬＳＶからロケーションデータを受信すると、上記ロケーションデータが示すサーバＩＰアドレスを宛先ＩＰアドレスに適用して、切断要求メッセージのＩＰパケットをネットワークＮＷ１に送信し（３５４）、サーバからの応答を待つ（３５５）。尚、上記切断要求メッセージには、ＳＩＰプロキシＰＲａのＳＩＰ−ＵＲＩを含む新たなＶｉａヘッダが付加されている。切断要求メッセージの宛先サーバから切断応答メッセージを受信すると、ＳＩＰメッセージ処理部５３Ｐは、受信メッセージを解析し（３５６）、自分のＶｉａヘッダを除去した形の切断応答メッセージを切断要求元に転送し（３５７）、このルーチンを終了する。
【０１００】
図４７は、ＳＩＰプロキシから切断要求メッセージＭ２４を受信した時、サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓが実行する制御動作のフローチャート４３０を示す。ＳＩＰメッセージ処理部５３Ｓは、ＴＬＳ部５２Ｓを介して切断要求メッセージＭ２４を受信すると、受信メッセージを解析し（ステップ４３１）、暗号化通信制御部５１Ｓに対して、切断すべき通信の識別情報（例えば、Ｃａｌｌ−ＩＤ）を指定して、切断要求の受信を通知し（４３２）、暗号化通信制御部５１Ｓからの応答を待つ（４３３）。ＳＩＰメッセージ処理部５３Ｓは、暗号化通信制御部５１Ｓから切断応答を受信すると、図３５に例示した切断応答メッセージＭ２５を作成し（４３４）、ＴＬＳ部、ＴＣＰ／ＩＰ部、ＮＩＣ部を介してＳＩＰプロキシＰＲｂに転送し（４３５）、このルーチンを終了する。
【０１０１】
図４８は、ＳＩＰメッセージ処理部５３Ｓから切断要求の発生を通知された時、暗号化通信制御部５１Ｓが実行する制御動作のフローチャート４４０を示す。暗号化通信制御部５１Ｓは、通知された通信識別情報にもとづいて、ＳＡＤＢ３３Ｓから消去すべきＳＡ情報を特定し（ステップ４４１）、当該ＳＡ情報を消去し（４４２）、このルーチンを終了する。
【０１０２】
なお、本実施例では、登録要求メッセージのボディ部に識別情報６３を含め、登録要求メッセージを解析することによって、識別情報管理テーブル６４を更新するようにしている。しかしながら、本発明はこれに限定されず、識別情報管理テーブル６４、あるいはその一部のエントリは、ロケーションサーバＬＳＶの管理者によって予め値が設定されていてもよい。
【０１０３】
次に、図４９から図５４を参照して、本発明による暗号化データ通信の第２の実施例について説明する。上述した第１の実施例では、ＳＩＰプロキシPRとレジストラRGとは同一のＳＩＰサーバ上で動作していた。また、識別情報管理テーブル６４で識別情報とＳＩＰ−ＵＲＩとの関連を検索する場合に検索用のＳＩＰメッセージを使用し、ＳＩＰプロキシＰＲが当該ＳＩＰメッセージのヘッダに基づいて、識別情報管理テーブル６４を検索していた。また、クライアントやサーバと、ＳＩＰサーバとの間の通信はＴＬＳで保護していた。
【０１０４】
本発明の第２の実施例では、識別情報管理テーブル６４へのロケーション情報の登録や削除、および識別情報管理テーブル６４の検索を行う、識別情報管理サービス６５が動作する識別情報管理サーバＩＳＶを、別途設けたことを特徴とする。さらには、クライアントやサーバと、識別情報管理テーブル６４との間で交換するＳＩＰメッセージのボディ部分をメッセージ暗号（Ｓ／ＭＩＭＥ）で保護することを特徴とする。
【０１０５】
本発明の第２の実施例におけるネットワーク構成は、図４９に示すように、ＳＩＰサーバＳＩＰａが管理するネットワークＮＷ１と、ロケーションサーバＬＳＶと、ＤＮＳ（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」のように、着目フィールドでＩＰｖ４（またはＩＰｖ６）というスキームを検出した場合は、その後にＩＰアドレスが記述されているものと約束してもよい。
【０１２２】
さらには、実施例では、クライアントのアプリケーションプログラムが接続先サーバのＩＰアドレス宛にパケットを送信する操作を行った場合に、接続先サーバのＩＰアドレスに対応するＳＩＰ−ＵＲＩを取得するためのＡＯＲ取得要求メッセージをＳＩＰサーバに送信するようにしているが、本発明はこれに限定されず、当該アプリケーションプログラムが使用している任意の体系の接続先識別子から、当該接続先識別子に対応するリソース識別子（接続先サーバを識別するためにセッション管理サーバが採用している識別子）を取得するために適用することができる。例えば、クライアントのアプリケーションプログラムが接続先サーバを指定する情報を含むＵＲＬへの接続を要求する操作を行った場合に、当該ＵＲＬに対応するＳＩＰ−ＵＲＩを取得するためのＡＯＲ取得要求メッセージをＳＩＰサーバに送信するようにしてもよい。このとき、前記ＵＲＬは事前にＳＩＰサーバに登録するようにしてもよいし、接続先サーバがロケーション登録を行う際のロケーション登録要求メッセージに当該接続先サーバがアクセス可能なＵＲＬのリストを含めるようにしてもよい。
【０１２３】
さらには、実施例では、クライアントやサーバとＳＩＰサーバとの間の通信はＴＬＳによって保護しているが、本発明はこれに限定されず、Ｓ／ＭＩＭＥによって保護してもよい。また、第２の実施例では、クライアントやサーバと識別情報管理サーバＩＳＶとの間でＳ／ＭＩＭＥで保護されたＳＩＰメッセージを送受するようにしても良い。
【図面の簡単な説明】
【０１２４】
【図１】公開鍵暗号化通信における従来の認証システムを説明するため図。
【図２】ＩＰｓｅｃによる暗号化通信を行うために従来のクライアントが備えるソフトウェアの基本的なブロック構成を示す図。
【図３】本発明と関係するＳＩＰプロキシを適用した認証システムを説明するための図。
【図４】本発明のセッション管理サーバ（ＳＩＰサーバ）を含むネットワーク構成の１例を示す図。
【図５】図４に示したロケーションサーバＬＳＶが備えるロケーションサービステーブルの１例を示す図。
【図６】図４に示したＳＩＰプロキシＰＲａのハードウェア構成を示すブロック図。
【図７】図４に示したクライアントＣＬ１ａの基本的なソフトウェア構造を示す図。
【図８】図４に示したサーバＳＶ１ｂの基本的なソフトウェア構造を示す図。
【図９】図４に示したＳＩＰプロキシＰＲａの基本的なソフトウェア構造を示す図。
【図１０】図４に示したレジストラＲＧａの基本的なソフトウェア構造を示す図。
【図１１】本発明による暗号化通信の第１の実施例を説明するためのシーケンス図の一部。
【図１２】本発明による暗号化通信の第１の実施例を説明するためのシーケンス図の残部。
【図１３】図１１におけるロケーション登録要求メッセージＭ１のフォーマットの１例を示す図。
【図１４】図１１におけるロケーション登録応答メッセージＭ２のフォーマットの１例を示す図。
【図１５】図１１におけるロケーションＡＯＲ取得要求メッセージＭ３のフォーマットの１例を示す図。
【図１６】図１１におけるロケーションＡＯＲ取得応答メッセージＭ４のフォーマットの１例を示す図。
【図１７】図１１における接続要求メッセージＭ５のフォーマットの１例を示す図。
【図１８】接続要求メッセージＭ５のボディ部Ｍ５−２のフォーマットの１例を示す図。
【図１９】図１１における接続中メッセージＭ６のフォーマットの１例を示す図。
【図２０】図１１における接続要求メッセージＭ７のフォーマットの１例を示す図。
【図２１】図１２における接続中メッセージＭ８のフォーマットの１例を示す図。
【図２２】図１２における接続要求メッセージＭ９のフォーマットの１例を示す図。
【図２３】図１２における接続応答メッセージＭ１０のフォーマットの１例を示す図。
【図２４】接続応答メッセージＭ１０のボディ部Ｍ１０−２のフォーマットの１例を示す図。
【図２５】図１２における接続応答メッセージＭ１１のフォーマットの１例を示す図。
【図２６】図１２における接続応答メッセージＭ１２のフォーマットの１例を示す図。
【図２７】図１２における接続確認メッセージＭ１３のフォーマットの１例を示す図。
【図２８】図１２における接続確認メッセージＭ１４のフォーマットの１例を示す図。
【図２９】図１２における接続確認メッセージＭ１５のフォーマットの１例を示す図。
【図３０】図１２における切断要求メッセージＭ２０のフォーマットの１例を示す図。
【図３１】図１２における切断中メッセージＭ２１のフォーマットの１例を示す図。
【図３２】図１２における切断要求メッセージＭ２２のフォーマットの１例を示す図。
【図３３】図１２における切断中メッセージＭ２３のフォーマットの１例を示す図。
【図３４】図１２における切断要求メッセージＭ２４のフォーマットの１例を示す図。
【図３５】図１２における切断応答メッセージＭ２５のフォーマットの１例を示す図。
【図３６】図１２における切断応答メッセージＭ２６のフォーマットの１例を示す図。
【図３７】図１２における切断応答メッセージＭ２７のフォーマットの１例を示す図。
【図３８】鍵交換要求を受信した時、クライアントＣＬ１ａの暗号化通信制御部５１Ｃが実行する制御動作を示すフローチャート。
【図３９Ａ】接続要求メッセージのボディ部を受信した時、クライアントＣＬ１ａのＳＩＰメッセージ処理部５３Ｃが実行する制御動作を示すフローチャートの一部。
【図３９Ｂ】接続要求メッセージのボディ部を受信した時、クライアントＣＬ１ａのＳＩＰメッセージ処理部５３Ｃが実行する制御動作を示すフローチャートの残部。
【図４０】ＡＯＲ取得要求メッセージを受信した時、レジストラＲＧａのＳＩＰメッセージ処理部５３Ｒが実行する制御動作を示すフローチャート。
【図４１Ａ】接続要求メッセージを受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作を示すフローチャートの第１部分。
【図４１Ｂ】接続要求メッセージを受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作を示すフローチャートの第２部分。
【図４１Ｃ】接続要求メッセージを受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作を示すフローチャートの第３部分。
【図４１Ｄ】接続要求メッセージを受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作を示すフローチャートの第４部分。
【図４２】接続要求メッセージを受信した時、サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓが実行する制御動作を示すフローチャート。
【図４３】接続要求メッセージのボディ部を受信した時、サーバＳＶ１ｂの暗号化通信制御部５１Ｓが実行する制御動作を示すフローチャート。
【図４４】鍵消去要求を受信した時、クライアントＣＬ１ａの暗号化通信制御部５１Ｃが実行する制御動作を示すフローチャート。
【図４５】切断要求メッセージの発行要求を受信した時、クライアントＣＬ１ａのＳＩＰメッセージ処理部５３Ｃが実行する制御動作を示すフローチャート。
【図４６Ａ】切断要求メッセージを受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作を示すフローチャートの一部。
【図４６Ｂ】切断要求メッセージを受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作を示すフローチャートの残部。
【図４７】切断要求メッセージを受信した時、サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓが実行する制御動作を示すフローチャート。
【図４８】切断要求の発生通知を受信した時、サーバＳＶ１ｂの暗号化通信制御部５１Ｓが実行する制御動作を示すフローチャート。
【図４９】本発明による暗号化通信の第２の実施例のネットワーク構成の１例を示す図。
【図５０】本発明による暗号化通信の第２の実施例を説明するためのシーケンス図の一部。
【図５１】図５０における識別情報登録要求メッセージＭ１０１のフォーマットの１例を示す図。
【図５２】図５０における識別情報登録応答メッセージＭ１０３のフォーマットの１例を示す図。
【図５３】図５０におけるＡＯＲ取得要求メッセージＭ１０５のフォーマットの１例を示す図。
【図５４】図５０におけるＡＯＲ取得応答メッセージＭ１０７のフォーマットの１例を示す図。
【符号の説明】
【０１２５】
ＣＬ１ａ〜ＣＬ２ｂ：クライアント、ＳＶ１ａ〜ＳＶ２ｂ：サーバ、
ＳＩＰａ、ＳＩＰｂ：ＳＩＰサーバ、ＰＲａ、ＰＲｂ：ＳＩＰプロキシ、
ＲＧａ、ＲＧｂ：レジストラ、ＬＳＶ：ロケーションサーバ、ＩＳＶ：識別情報管理サーバ、
２０：ネットワークインタフェースカード部、３０：暗号化通信機能部、
３１：暗号エンジン、４０：アプリケーションソフト、５０：鍵管理プロセス、
５１：暗号化通信制御部、５２：ＴＬＳ部、５３：ＳＩＰメッセージ処理部、
６０：レジストラ処理部。
【技術分野】
【０００１】
本発明は、データ通信方法およびシステムに関し、更に詳しくは、セッション管理サーバを利用して、クライアントとサーバとの間での暗号化データ通信を可能にしたデータ通信方法およびシステムを提供することにある。
【背景技術】
【０００２】
ネットワークにおける暗号化通信方法では、クライアントとサーバは、互いに意図しない相手装置との通信を防止するため、相手装置について認証手順を実行し、相手装置の認証に成功した時、通信に使用する暗号化パラメータを交換するようにしている。ＩＥＴＦ（Internet Engineering Task Force）のＲＦＣ２４０１（非特許文献１）に記述されたＩＰｓｅｃ（Internet Protocol Security）や、ＲＦＣ２２４６（非特許文献２）に記述されたＴＬＳ（Transport Layer Security）では、通信相手の認証に公開鍵証明書が適用される。
【０００３】
公開鍵証明書を用いた認証では、通信相手が提示した公開鍵証明書が信頼できる認証局から発行されたものであることを何らかの方法で検証する必要がある。公開鍵証明書の検証方法の１つとしては、例えば、通信相手が提示する公開鍵証明書の発行元認証局を証明するための信頼性のある認証局ｒｏｏｔ証明書を何らかの方法で事前に入手しておき、通信相手の認証手順において、相手装置が提示した公開鍵証明書に付与された認証局の署名を、認証局のｒｏｏｔ証明書の公開鍵によって検証する方法がある。この検証方法によれば、サーバとクライアントは、通信対象となる全ての通信装置の公開鍵証明書に対応して、各公開鍵証明書の発行元認証局のｒｏｏｔ証明書を事前に用意しておく必要がある。
【０００４】
例えば、図１に示すように、複数のクライアント（端末装置）ＣＬ１、ＣＬ２、ＣＬ３が、それぞれ発行元（ＣＡ１、ＣＡ２、ＣＡ３）の異なる秘密鍵ＳＫ１、ＳＫ２、ＳＫ３と公開鍵証明書ＰＫ１、ＰＫ２、ＰＫ３を所持し、サーバＳＶ１、ＳＶ２、ＳＶ３も、それぞれ発行元（ＣＡ１、ＣＡ２、ＣＡ３）の異なる秘密鍵ＳＫ１１、ＳＫ１２、ＳＫ１３と公開鍵証明書ＰＫ１１、ＰＫ１２、ＰＫ１３を所持したシステムを想定する。ここで、各クライアントが、複数のサーバＳＶ１、ＳＶ２、ＳＶ３と随時に通信できるようにするためには、図示したように、各サーバに、通信相手となる全てのクライアント装置ＣＬ１、ＣＬ２、ＣＬ３がもつ公開鍵証明書（ＰＫ１、ＰＫ２、ＰＫ３）の発行元認証局（ＣＡ１、ＣＡ２、ＣＡ３）と対応して、複数のｒｏｏｔ証明書ＲＴ１、ＲＴ２、ＲＴ３を事前に所持しておく必要がある。同様に、各クライアントにも、通信相手となるサーバＳＶ１、ＳＶ２、ＳＶ３がもつ公開鍵証明書（ＰＫ１１、ＰＫ１２、ＰＫ１３）の発行元認証局（ＣＡ１、ＣＡ２、ＣＡ３）と対応して、複数のｒｏｏｔ証明書ＲＴ１、ＲＴ２、ＲＴ３を事前に用意しておく必要がある。また、このシステム構成では、各クライアント装置とサーバは、通信相手を変えた時、その都度、認証処理を繰り返す必要がある。
【０００５】
図２は、上記ＲＦＣ２４０１に記述されたＩＰｓｅｃによる暗号化通信を行うためにクライアントが備えるソフトウェアの基本的なブロック構成を示す。
ここで、２０は、ネットワークインタフェースカード（ＮＩＣ）部、３０は、ＴＣＰ／ＩＰレイヤ、４０は、アプリケーションレイヤのソフトウェア部を示し、５０は、ＲＦＣ２４０９（非特許文献３）に記述された鍵管理（ＩＫＥ：Internet Key Exchange）プロセス用のソフトウェア部を示している。暗号エンジン３１は、ＴＣＰ／ＩＰレイヤのソフトウェアの一部として装備され、送信パケットに暗号化を適用するか否かの判定情報（ＳＰ情報）を記憶したＳＰＤＢ（Security Policy Data Base）３２と、暗号化通信に適用する暗号化方式や暗号鍵等の情報（ＳＡ情報）を記憶したＳＡＤＢ（Security Association Data Base）３３とを備えている。
【０００６】
上記クライアントの通信相手となるサーバも、図２と同様のソフトウェアを有し、クライアントとサーバのアプリケーションレイヤ同士、鍵管理プロセス同士が互いに通信するようになっている。
【０００７】
暗号エンジン３１は、アプリケーションレイヤ４０のプログラムが発行したＩＰパケットの送信要求を検出すると、該ＩＰパケットのヘッダ情報をＳＰＤＢ３２で検証し、このＩＰパケットにＩＰｓｅｃを適用すべきか否かを判定する。ＩＰパケットにＩＰｓｅｃを適用すると判断した暗号エンジン３１は、ＳＡＤＢ３３から、ＩＰパケットに適用すべきＳＡ（Security Association）情報を取得する。ここで、もし、ＳＡＤＢ３３に上記ＩＰパケットと対応するＳＡ情報が登録されていなかった場合、暗号エンジン３１は、ＩＫＥ（鍵管理）プロセス５０に対して、通信相手（接続先サーバ）との間での暗号鍵を含むＳＡ情報の交換を要求する。
【０００８】
ＩＫＥプロセス５０は、ＲＦＣ２４０８（非特許文献４）に記載されたＩＳＡＫＭＰ（Internet Security Association and Key Management Protocol）に従って、通信相手とＳＡ情報を交換する。ＩＳＡＫＭＰでは、通信相手との間に暗号化通信路を形成した後、相手装置が通信を許容された真正な装置か否かを確認するための認証手順を実行する。ＩＫＥプロセス５０は、上記認証手順によって、相手装置が暗号化通信を許容された真正な装置であることを確認すると、ＩＳＡＫＭＰによって設定された通信路を介して、相手装置とＳＡ情報の交換を開始する。ＩＫＥプロセス５０は、通信相手とのＳＡ情報の交換が完了すると、暗号エンジン３１に、ＳＡ情報とこれに対応したＳＰ（Security Policy）情報を通知する。
【０００９】
暗号エンジン３１は、ＩＫＥプロセス５０から通知されたＳＰ情報とＳＡ情報をそれぞれＳＰＤＢ３２、ＳＡＤＢ３３に格納した後、ＩＰパケットを上記ＳＡ情報に従って暗号化して、通信相手に送信する。通信相手となるサーバ側では、上記暗号化されたＩＰパケットを受信すると、ＩＫＥプロセスによって合意したＳＡ情報に従って受信ＩＰパケットを復号化し、サーバ側アプリケーションレイヤにＩＰパケットの受信を通知する。
【００１０】
一方、ＲＦＣ３２６１（非特許文献５）には、ＴＬＳ（Transport Layer Security）によって、クライアント（ユーザエージェントクライアント）とセッション管理サーバであるＳＩＰ（Session Initiation Protocol）プロキシとの間、およびＳＩＰプロキシとサーバ（ユーザエージェント・サーバ）との間の相互認証を行って、クライアントとＳＩＰプロキシ、ＳＩＰプロキシとサーバが暗号化通信する方法が記載されている。ＲＦＣ３２６１のＳＩＰモデルによれば、クライアントとサーバは、それぞれがＳＩＰプロキシによって真正な通信相手として確認済みであり、且つ、クライアントとサーバとの間では、暗号化されたＳＩＰメッセージが送受信されるため、クライアント、サーバ、ＳＩＰプロキシ以外の他の装置が、上記クライアントとサーバとの間の通信内容を傍受することは困難となっている。
【００１１】
ＳＩＰは、テキストベースのプロトコルであり、ＳＩＰメッセージは、ヘッダ部と、セッション内容を示すメッセージボディ部とからなる。ＳＩＰに関しては、ＲＦＣ３２６３（非特許文献６）に記述されている。また、ＲＦＣ２３２７（非特許文献７）には、セッション記述に適用されるＳＤＰ（Session Description Protocol）と、クライアントとサーバとの間で交換される暗号化パラメータの記述方法について開示されている。ＳＩＰモデルのクライアントとサーバは、それぞれがＳＩＰプロキシとの間に形成した暗号通信路を介して、ＳＩＰメッセージによってセッション記述と暗号化パラメータを交換した後、上記暗号化パラメータを適用して、暗号化パケットを通信することができる。
【００１２】
【非特許文献１】ＩＥＴＦ、ＲＦＣ２４０１：Ｓｅｃｕｒｉｔｙ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ、［２００５年１１月２９日検索］ 、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２４０１．ｔｘｔ＞
【非特許文献２】ＩＥＴＦ、ＲＦＣ２２４６：Ｔｈｅ ＴＬＳ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ １．０、［２００５年１１月２９日検索］ 、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２２４６．ｔｘｔ＞
【非特許文献３】ＩＥＴＦ、ＲＦＣ２４０９：Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ （ＩＫＥ） 、［２００５年１１月２９日検索］ 、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２４０９．ｔｘｔ＞
【非特許文献４】ＩＥＴＦ、ＲＦＣ２４０８：Ｉｎｔｅｒｎｅｔ Ｓｅｃｕｒｉｔｙ Ａｓｓｏｃｉａｔｉｏｎ ａｎｄ Ｋｅｙ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ （ＩＳＡＫＭＰ） 、［２００５年１１月２９日検索］ 、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２４０８．ｔｘｔ＞
【非特許文献５】ＩＥＴＦ、ＲＦＣ３２６１：ＳＩＰ： Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ、［２００５年１１月２９日検索］ 、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３２６１．ｔｘｔ＞
【非特許文献６】ＩＥＴＦ、ＲＦＣ３２６３：Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ （ＳＩＰ）： Ｌｏｃａｔｉｎｇ ＳＩＰ Ｓｅｒｖｅｒｓ、［２００５年１１月２９日検索］ 、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３２６３．ｔｘｔ＞
【非特許文献７】ＩＥＴＦ、ＲＦＣ２３２７：ＳＤＰ： Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ、［２００５年１１月２９日検索］ 、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２３２７．ｔｘｔ＞
【発明の開示】
【発明が解決しようとする課題】
【００１３】
図３は、上述したＳＩＰプロキシを適用した認証システムの１例を示す。ここで、ＰＲは、複数のクライアントＣＬ１、ＣＬ２、ＣＬ３と、複数のサーバＳＶ１、ＳＶ２、ＳＶ３とに接続されたＳＩＰプロキシを示す。ＳＩＰプロキシＰＲは、認証局ＣＡ４が発行した秘密鍵ＳＫ３０と、公開鍵証明書ＰＫ３０を使用しており、サーバＳＶ１、ＳＶ２、ＳＶ３を認証するために、これらのサーバが使用する公開鍵証明書の発行元認証局（ＣＡ１、ＣＡ２、ＣＡ３）と対応した複数のｒｏｏｔ証明書ＲＴ１、ＲＴ２、ＲＴ３を予め所持している。
【００１４】
ＳＩＰプロキシを適用した認証システムでは、各サーバとクライアントは、図３に示すように、通信相手を認証するためのｒｏｏｔ証明書として、ＳＩＰプロキシＰＲが使用する公開鍵証明書ＰＫ３０の発行元認証局と対応したｒｏｏｔ証明書ＲＴ４のみを所持すればよい。また、各クライアントは、ＳＩＰプロキシＰＲを介して１つのサーバと通信した後、接続先を別のサーバに変更する場合、ＳＩＰプロキシとの間では既に構築済みの暗号通信路を使用して通信できるため、新たな通信相手との間で暗号化パラメータを交換するだけで、暗号化通信を開始することが可能となる。つまり、ＳＩＰプロキシを適用した認証システムでは、各クライアントにとって、接続先サーバの変更の都度、新たに認証処理を行う必要がないという利点がある。
【００１５】
然るに、ＳＩＰのフレームワークにおいては、セッション管理サーバ（ＳＩＰプロキシ）は、ＡＯＲ（Address-of-Record）と呼ばれる「ユーザ名＠ドメイン名」 形式をもつ識別子（ＳＩＰ−ＵＲＩ）によって、受信ＳＩＰメッセージの転送先を決定している。従って、上述したＳＩＰプロキシのようなセッション管理サーバ経由のセッション設定を前提としたネットワークシステムでは、クライアント上で実行されるアプリケーションは、接続先サーバを指定するための識別子として、サーバの所属ドメインを特定可能なＳＩＰ−ＵＲＩ（Uniform Resource Identifier）を使用する必要がある。
【００１６】
更に詳述すると、ＳＩＰのフレームワークにおいては、クライアント側では、スタートラインに含まれるＲｅｑｕｅｓｔ−ＵＲＩとして、接続先サーバを指定するＡＯＲ形式のＳＩＰ−ＵＲＩを記述した接続要求ＳＩＰメッセージを生成し、該ＳＩＰメッセージをペイロードに含むＩＰパケットをクライアントの所属ドメインに位置するＳＩＰプロキシ宛に送信する。上記ＩＰパケットを受信したＳＩＰプロキシは、Ｒｅｑｕｅｓｔ−ＵＲＩとして記述されたＡＯＲが示すドメイン名に基づいて、例えば、ＤＮＳ（Domain Name System）のＮＡＰＴＲ Ｒｅｃｏｒｄ検索とＳＲＶ Ｒｅｃｏｒｄ検索を行うことにより、受信メッセージの転送先サーバが所属する他のドメインに位置したＳＩＰプロキシ（転送先ＳＩＰプロキシ）のＩＰアドレスあるいはＦＱＤＮ（Full Qualified Domain Name）を特定する。ＳＲＶ Ｒｅｃｏｒｄ検索の結果がＦＱＤＮを示した場合は、ＤＮＳのＡ Ｒｅｃｏｒｄ検索を実行することによって、転送先ＳＩＰプロキシのＩＰアドレスを取得できる。尚、ドメイン名から転送先ＳＩＰプロキシのＩＰアドレスを取得する手順については、ＲＦＣ３２６３（非特許文献６）に記述されている。
【００１７】
ここで、接続先サーバの所属ドメインが、ＳＩＰメッセージを受信したＳＩＰプロキシの所属ドメインと同一であった場合、ＳＩＰプロキシは、受信メッセージのＲｅｑｕｅｓｔ−ＵＲＩに記述されたＳＩＰ−ＵＲＩを検索キーとして、ロケーションサービスＤＢ（データベース）から接続先サーバのＩＰアドレス（またはＦＱＤＮ）を取得し、このＩＰアドレスをＩＰパケットの宛先アドレスとして、ＳＩＰメッセージを接続先サーバに転送する。接続先サーバの所属ドメインがＳＩＰプロキシ（または送信元クライアント）の所属ドメインと異なった場合は、ＳＩＰメッセージは、接続先サーバの所属ドメインに位置した別のＳＩＰプロキシに転送され、転送先のＳＩＰプロキシが、ロケーションサービスＤＢから接続先サーバのＩＰアドレスまたはＦＱＤＮを取得して、ＳＩＰメッセージを接続先サーバに転送する。
【００１８】
上述したように、セッション管理サーバ（ＳＩＰプロキシ）経由のセッション設定を前提とするネットワークでは、セッション管理サーバが、受信したＳＩＰメッセージに含まれる要求リソース識別子（ＳＩＰ−ＵＲＩ）から、接続先サーバが所属するドメインを判定し、受信メッセージを接続先サーバあるいは接続先セッション管理サーバに転送するようになっている。しかしながら、ＩＰ網に接続されるクライアント端末上で実行される一般のアプリケーションプログラムは、接続先サーバの指定に、上述したＡＯＲ形式のＳＩＰ−ＵＲＩのようにＳＩＰのフレームワークにおける識別子ではなく、ＩＰアドレスのように接続先サーバのみを示す識別子を使用したり、ＵＲＬなどのようにドメイン名を含んでいても、ＳＩＰ−ＵＲＩとは異なるフレームワークの識別子を使用したりしている。
【００１９】
アプリケーションプログラムまたは暗号化通信ソフトが、接続先サーバをＩＰアドレスやＵＲＬで指定してサーバとの接続要求を発行し、クライアントが、接続先サーバをＩＰアドレスやＵＲＬで指定した形で接続要求ＳＩＰメッセージを送信した場合、セッション管理サーバ（ＳＩＰプロキシ）は、受信した接続要求メッセージの転送先ドメインを特定することができない。この場合、クライアントが図３に示した認証システムの利点を享受できないという問題がある。
【００２０】
本発明の目的は、接続先の装置をＩＰアドレスやＵＲＬのような、セッション管理サーバが採用しているものとは異なる、アプリケーションの仕様に応じた識別子（以降、接続先識別子とも呼ぶ）で指定したセッション制御メッセージをセッション管理サーバ経由で接続先サーバに転送可能にしたデータ通信方法およびシステムを提供することにある。
本発明の他の目的は、接続先サーバを接続先識別子で指定したクライアントからの接続要求をセッション管理サーバ経由で当該接続先サーバに転送可能にしたデータ通信方法およびシステムを提供することにある。
本発明の更に他の目的は、クライアントとサーバとの間の暗号化データ通信を可能にし、且つ、暗号化データ通信に先立って必要となるクライアントとサーバとの間の認証手順を容易にしたデータ通信方法およびシステムを提供することにある。
【課題を解決するための手段】
【００２１】
上記目的を達成するため、本発明では、クライアントのアプリケーションプログラムまたは暗号化通信ソフトが、接続先サーバを接続先識別子で指定した形で接続要求を発行した時、クライアントまたはセッション管理サーバまたは識別情報管理サーバで、上記接続先識別子をセッション管理サーバがドメイン識別可能な所望のリソース識別子に自動的に変換することを特徴とする。
【００２２】
本発明によるクライアントとサーバとの間のデータ通信方法は、クライアントからセッション管理サーバあるいは識別情報管理サーバに、接続先の接続先識別子を指定して、該接続先サーバに割り当てられた所属ドメイン名を含むリソース識別子を問い合わせる第１ステップと、上記セッション管理サーバあるいは識別情報管理サーバが、接続先識別子とリソース識別子との対応関係を管理しているロケーションテーブルから、上記接続先サーバの接続先識別子と対応するリソース識別子を取得し、上記クライアントに通知する第２ステップと、上記クライアントから上記セッション管理サーバに、要求リソースを上記接続先サーバのリソース識別子で指定した接続要求メッセージを送信する第３ステップと、上記セッション管理サーバが、受信した接続要求メッセージに記述された上記リソース識別子に含まれるドメイン名に基づいて受信メッセージの転送先を判定し、受信メッセージを接続先サーバまたは該接続先サーバの所属ドメインを管理する別のセッション管理サーバに転送する第４ステップとからなることを特徴とする。
【００２３】
更に詳述すると、本発明のデータ通信方法は、接続要求メッセージの受信に応答して、接続先サーバからセッション管理サーバを介して要求元クライアントに、暗号化通信に必要となるパラメータ情報を含む接続応答メッセージを返送する第５ステップと、上記クライアントと接続先サーバとの間で、上記接続応答メッセージで指定されたパラメータ情報に従って暗号化されたメッセージを含むパケットを通信する第６ステップを含む。
【００２４】
上記セッション管理サーバは、例えば、ＳＩＰ（Session Initiation Protocol）サーバからなる。この場合、クライアントとセッション管理サーバとの間の通信メッセージは、例えば、ＲＦＣ３２６１に規定されたＴＬＳ（Transport Layer Security）によって暗号化され、クライアントと接続先サーバとの間の通信データは、例えば、ＲＦＣ２４０１に規定されたＩＰｓｅｃ（Internet Protocol Security）によって暗号化される。
【００２５】
本発明によって提供されるセッション管理サーバは、クライアントから、要求リソースを接続先サーバの接続先識別子で指定した接続要求メッセージを受信した時、接続先識別子とリソース識別子との対応関係を管理しているロケーションテーブルから、上記接続先サーバの接続先識別子と対応するリソース識別子を取得し、受信メッセージに記述された要求リソースを接続先識別子から上記リソース識別子に書き換えるための手段と、上記リソース識別子に含まれるドメイン名に基づいて受信メッセージの転送先を判定し、受信メッセージを接続先サーバまたは該接続先サーバの所属ドメインを管理する別のセッション管理サーバに転送するための手段とを備えたことを特徴とする。
【００２６】
上記セッション管理サーバは、具体的には、通信ネットワークに接続されたネットワークインタフェース部と、セッション制御メッセージを処理するメッセージ処理部と、上記ネットワークインタフェース部から受信した暗号化メッセージを復号化して上記メッセージ処理部に渡すと共に、上記メッセージ処理部から出力されたセッション制御メッセージを暗号化して上記ネットワークインタフェース部に出力するためのセキュリティ部とを有し、上記メッセージ処理部が、上述した要求リソースの書き換え手段と受信メッセージの転送手段を備える。
【００２７】
本発明によって提供されるクライアント端末は、通信ネットワークに接続されたネットワークインタフェース部と、セッション制御メッセージを処理するメッセージ処理部と、アプリケーションプログラムが発生する接続先サーバ宛の送信メッセージを暗号化して上記ネットワークインタフェース部に出力すると共に、上記ネットワークインタフェース部から受信した暗号化メッセージを復号化して上記アプリケーションプログラムに渡すための第１セキュリティ部と、上記セキュリティ部から、接続先サーバとの暗号化パラメータの交換要求が発生した時、接続先サーバを接続先識別子で指定した接続要求メッセージを上記メッセージ処理部に出力し、上記メッセージ処理部から接続応答メッセージを受信した時、該受信メッセージから抽出した暗号化パラメータを上記第１セキュリティ部に渡すセキュリティ情報制御部とからなり、
上記メッセージ処理部が、上記セキュリティ情報制御部から接続要求メッセージを受信した時、上記接続先識別子に基づいて上記セッション管理サーバまたは接続先サーバから接続先サーバのリソース識別子を取得し、該リソース識別子で要求リソースを指定した形で、上記接続要求メッセージを上記セッション管理サーバに送信することを特徴とする。
【００２８】
実際の応用では、本発明のクライアント端末は、上記ネットワークインタフェース部から受信した暗号化されたセッション制御メッセージを復号化して上記メッセージ処理部に渡すと共に、上記メッセージ処理部から出力されたセッション制御メッセージを暗号化して上記ネットワークインタフェース部に出力するための第２セキュリティ部を有し、
接続先サーバとの通信データが上記第１セキュリティ部によって暗号化され、セッション管理サーバと通信メッセージが上記第２セキュリティ部によって暗号化される。
【発明の効果】
【００２９】
本発明によれば、クライアントのアプリケーションプログラムまたは暗号化通信ソフトから、要求リソース（接続先サーバ）を接続先識別子で指定した形で接続要求が発行された場合でも、接続要求メッセージの要求リソースを接続先識別子からドメイン識別可能なリソース識別子に自動的に変換できる。従って、接続要求メッセージを転送制御するセッション管理サーバにおいて、受信メッセージのリソース識別子から転送先ドメインを判定し、受信メッセージを接続先サーバ、または接続先サーバの所属ドメインに位置した別のセッション管理サーバに転送することが可能となる。
本発明によれば、一般のアプリケーションプログラムを実行するクライアントでも、セッション管理サーバによる認証機能を利用することによって、接続先サーバとの間で容易に暗号化通信を実現できる。
【発明を実施するための最良の形態】
【００３０】
以下、本発明の実施例について図面を参照して説明する。
図４は、本発明が適用されるネットワーク構成の１例を示す。
ここに示したネットワークは、ＳＩＰサーバＳＩＰａが管理する第１ドメインを形成する第１のネットワークＮＷ１と、ＳＩＰサーバＳＩＰｂが管理する第２ドメインを形成する第２のネットワークＮＷ２と、ロケーションサーバＬＳＶと、ＤＮＳ（Domain Name System）とからなる。
【００３１】
第１のネットワークＮＷ１には、クライアントＣＬ１ａ、ＣＬ２ａと、サーバＳＶ１ａ、ＳＶ２ａが接続され、第２のネットワークＮＷ２には、クライアントＣＬ１ｂ、ＣＬ２ｂと、サーバＳＶ１ｂ、ＳＶ２ｂが接続されている。また、ＳＩＰサーバＳＩＰａは、ＳＩＰプロキシＰＲａとレジストラＰＧａとからなり、ＳＩＰサーバＳＩＰｂは、ＳＩＰプロキシＰＲｂとレジストラＰＧｂとからなっている。
【００３２】
ここで、各クライアントおよびサーバに付随して括弧内に示した文字列は、ＳＩＰメッセージの転送先識別子（リソース識別子）となるＡＯＲ（Address-of-Record）形式のＳＩＰ−ＵＲＩの値を示している。第１ネットワークＮＷ１に接続されたクライアントとサーバには、ＳＩＰサーバＳＩＰａのドメイン識別子「aaa.com」を含むＡＯＲが割り当てられ、第２ネットワークＮＷ２に接続されたクライアントとサーバには、ＳＩＰサーバＳＩＰｂのドメイン識別子「bbb.com」を含むＡＯＲが割り当てられている。
【００３３】
本発明のＳＩＰサーバＳＩＰａ、ＳＩＰｂは、それぞれの管轄下にあるクライアントから、接続先サーバをＵＲＬで指定したＳＩＰメッセージを受信した時、ロケーションサーバＬＳＶに、上記接続先ＵＲＬと対応するＡＯＲ（リソース識別子）の検索（ロケーションデータ検索）を要求する。また、ＳＩＰサーバＳＩＰａ、ＳＩＰｂは、それぞれ他のＳＩＰサーバから、接続先サーバをＡＯＲで指定したＳＩＰメッセージを受信した時、ロケーションサーバＬＳＶに、上記接続先ＡＯＲと対応するＩＰアドレスの検索を要求する。
【００３４】
ロケーションサーバＬＳＶは、ロケーションサービス・データベース（ＤＢ）に、例えば、図５に示すように、ＳＩＰサーバＳＩＰａ、ＳＩＰｂの管轄下にあるクライアントおよびサーバと対応した複数のエントリＥＮ−１、ＥＮ−２，・・・からなり、各エントリが、クライアントまたはサーバのＡＯＲ６１とＩＰアドレス６２との対応関係を示すロケーションサービステーブル６０を格納する。また、ロケーションサーバＬＳＶは、ＳＩＰサーバＳＩＰａ、ＳＩＰｂの管轄下にあるクライアントおよびサーバと対応した複数のエントリＲＥＮ−１、ＲＥＮ−２，・・・からなり、各エントリが、クライアントまたはサーバのアプリケーションプログラムや暗号化通信ソフトが通信相手の装置を識別するために用いる情報である識別情報６３と、ＡＯＲ６１との対応関係を示す識別情報管理テーブル６４と、を備えている。ロケーションサーバＬＳＶは、ＳＩＰサーバからの検索キーとしてＡＯＲを指定されたロケーションデータ検索要求を受信した場合、上記ロケーションサービステーブル６０から、当該ＡＯＲと対応するＩＰアドレスを検索し、検索結果を要求元ＳＩＰサーバに返送する。同様に、ロケーションサーバＬＳＶは、ＳＩＰサーバからの検索キーとしてＵＲＬ等の識別情報６３を指定されたロケーションデータ検索要求を受信した場合、上記識別情報管理テーブル６４から、当該識別情報６３と対応するＡＯＲを検索し、検索結果を要求元ＳＩＰサーバに返送する。なお、本実施例では、識別情報６３にはＵＲＬやＵＲＩやＩＰアドレスなどが使用可能である。識別情報６３はこれらＵＲＬ等に限られず、それぞれの装置に独自に割り当てられ互いに識別が可能な情報であればよい。なお、ＩＰアドレスを使用する場合には、ＵＲＬやＵＲＩとの区別を容易にするため、ＩＰアドレスの先頭に「ipv4:」や「ipv6:」などのプレフィックスをつけることが望ましい。
【００３５】
図６は、ＳＩＰプロキシＰＲａのハードウェア構成を示す。ＳＩＰプロキシＰＲａは例えば、プロセッサ（ＣＰＵ）１１と、プロセッサが実行する各種ソフトウェアとデータを記憶するためのメモリ１２およびハードディスク１３と、ネットワークＮＷ１（ＮＷ２）に接続するためのネットワークインタフェース１４と、入出力装置１５とからなり、これらの要素は内部バス１６によって相互接続されている。ＳＩＰプロキシＰＲｂ、レジストラＲＧａ、ＲＧｂ、クライアントＣＬ１ａ〜ＣＬ２ｂ、サーバＳＶ１ａ〜ＳＶ２ｂも、基本的には、図６に示したＳＩＰプロキシＰＲａと同様の構成要素からなる。
【００３６】
以下、図４に示した第１ドメインに所属するクライアントＣＬ１ａが、第２ドメインに所属するサーバＳＶ１ｂと暗号化データ通信する場合の通信手順を例にして、本発明の第１の実施例について説明する。
【００３７】
図７は、クライアントＣＬ１ａの基本的なソフトウェア構造の一例を示す。他のクライアントＣＬ１ｂ〜ＣＬ２ｂも、これと同様のソフトウェア構造をとりうる。クライアントＣＬ１ａのソフトウェアは、ネットワークインタフェースカード部（ＮＩＣ）２０Ｃと、暗号化／復号化機能を備えた暗号エンジン３１Ｃを含む暗号化通信機能部３０Ｃと、アプリケーションプログラム４０Ｃと、鍵管理プロセス部５０Ｃとからなる。第１実施例では、鍵管理プロセス部５０Ｃが、暗号化通信制御部５１Ｃと、ＴＬＳ（Transport Layer Security）部５２Ｃと、ＳＩＰメッセージ処理部５３Ｃとを備えたことを特徴としている。
【００３８】
図８は、サーバＳＶ１ｂの基本的なソフトウェア構造の一例を示す。他のサーバＳＶ１ａ、ＳＶ２ａ、ＳＶ２ｂも、これと同様のソフトウェア構造をとりうる。サーバＳＶ１ｂのソフトウェアは、ネットワークインタフェースカード部（ＮＩＣ）２０Ｓと、ＩＰｓｅｃ暗号化／復号化機能を備えた暗号エンジン３１Ｓを含む暗号化通信機能部３０Ｓと、アプリケーションプログラム４０Ｓと、鍵管理プロセス部５０Ｓとからなり、鍵管理プロセス部５０Ｓが、暗号化通信制御部５１Ｓと、ＴＬＳ部５２Ｓと、ＳＩＰメッセージ処理部５３Ｓとを備えている。
【００３９】
本実施例では、クライアントＣＬ１ａのアプリケーションプログラム４０ＣとサーバＳＶ１ｂのアプリケーションプログラム４０Ｓは、それぞれが備える暗号エンジン３１Ｃ、３１ＳのＩＰｓｅｃ暗号化／復号化機能を利用して、ＩＰｓｅｃによる暗号化データを通信する。一方、クライアントＣＬ１ａのＳＩＰメッセージ処理部５３Ｃは、後述するＳＩＰサーバＳＩＰａ（ＳＩＰプロキシＰＲａ、レジストラＲＧａ）のＳＩＰメッセージ処理部との間で、それぞれが備えるＴＬＳ部のメッセージ暗号化／復号化機能を利用して、暗号化されたＳＩＰメッセージを通信する。同様に、サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓも、ＳＩＰサーバＳＩＰａ（ＳＩＰプロキシＰＲａ、レジストラＲＧａ）のＳＩＰメッセージ処理部との間で、それぞれが備えるＴＬＳ部のメッセージ暗号化／復号化機能を利用して、暗号化されたＳＩＰメッセージを通信する。
【００４０】
図９は、ＳＩＰプロキシＰＲａの基本的なソフトウェア構造の一例を示す。ＳＩＰプロキシＰＲｂも、これと同様のソフトウェア構造をとりうる。ＳＩＰプロキシＰＲａのソフトウェアは、ネットワークインタフェースカード部（ＮＩＣ）２０Ｐと、暗号化通信機能部３０Ｐと、鍵管理プロセス部５０Ｐとからなる。鍵管理プロセス部５０Ｐが、ＴＬＳ部５２Ｐと、ＳＩＰメッセージ処理部５３Ｐとを備えている。ＳＩＰメッセージ処理部５３Ｐは、後述するＳＩＰ−ＵＲI（ＡＯＲ）検索機能５４を備えている。ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐは、ＴＬＳ部５２Ｐのメッセージ暗号化／復号化機能を利用して、管理下にあるドメインに所属したクライアント、サーバ、および他のドメインを管理する他のＳＩＰプロキシ、例えばＰＲｂと暗号化メッセージを通信する。
【００４１】
図１０は、レジストラＲＧａの基本的なソフトウェア構造の一例を示す。レジストラＲＧｂも、これと同様のソフトウェア構造をとりうる。レジストラＲＧａのソフトウェアは、ネットワークインタフェースカード部（ＮＩＣ）２０Ｒと、暗号化通信機能部３０Ｒと、メッセージの暗号化／復号化機能を備えたＴＬＳ部５２Ｒと、ＳＩＰメッセージ処理部５３Ｒと、レジストラ処理部６０Ｒとからなっている。ＳＩＰメッセージ処理部５３Ｒは、クライアントが発行したＡＯＲ取得要求、またはＳＩＰプロキシＰＲａが発行したＡＯＲ取得要求を受信すると、レジストラ処理部６０Ｒにロケーションデータの検索を要求する。レジストラ処理部６０Ｒは、ＳＩＰメッセージ処理部５３Ｒからの要求に応答して、ロケーションサーバＬＳＶが備えるロケーションサービスＤＢをアクセスする。尚、レジストラＲＧａとＳＩＰプロキシＰＲａとの間の通信には、暗号化を適用しなくてもよい。
【００４２】
図１１と図１２は、本発明による暗号化データ通信の第１の実施例を示すシーケンス図である。第１の実施例では、クライアントＣＬ１ａがＡＯＲ取得要求を発行する。本実施例において、クライアントＣＬ１ａからの接続要求先となる第２ネットワークに接続されたサーバＳＶ１ｂは、クライアントＣＬ１ａからの接続要求に先立って、ＳＩＰサーバＳＩＰｂのレジストラＲＧｂとの間で、サーバＳＶ１ｂの認証と暗号化通信用のパラメータ設定のためのＴＬＳネゴシェーション（Ｓ１）を実行した後、レジストラＲＧｂにロケーション登録要求メッセージ（ＳＩＰメッセージ：REGISTER）Ｍ１を送信する。
【００４３】
ロケーション登録要求メッセージＭ１は、例えば、図１３に示すように、ＩＰヘッダＨ１と、ＵＤＰ／ＴＣＰヘッダＨ２とを付したＩＰパケット形式で送信される。ＩＰヘッダＨ１は、宛先アドレスとしてレジストラＲＧｂ（ＳＩＰサーバＳＩＰｂ）のＩＰアドレス、送信元アドレスとしてサーバＳＶ１ｂのＩＰアドレスを含む。
【００４４】
ＳＩＰメッセージは、ＳＩＰメッセージの種類（Request-Method）を示すスタートラインと、要求または応答内容を記述したヘッダ部と、必要に応じてセッション内容を記述したメッセージボディ部とからなる。メッセージの種類によっては、上記スタートラインに、該メッセージの宛先を示すリソース識別子（Request-URI）が記述される。また、メッセージボディ部におけるセッション内容の記述には、ＲＦＣ３２６６で仕様化されたＳＤＰ（Session Description Protocol）が適用される。
【００４５】
サーバＳＶ２ｂが発行するロケーション登録要求メッセージＭ１の場合、スタートラインには、ＳＩＰメッセージの種類として「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）情報を検索する。ここで、ＳＡＤＢ３３Ｃに当該通信に適用すべきＳＡ情報が未登録の場合、暗号化通信制御部５１Ｃは、通信相手との暗号化パラメータの交換（鍵交換）を実施する。
【００７３】
暗号化通信制御部５１Ｃは、ＤＮＳ等を参照して取得した、上記ＵＲＬが示すＴＣＰ／ＩＰ通信パラメータと、暗号化通信制御部５１Ｃが管理している利用可能なＳＡ情報とに基づいて、図１８に例示した接続要求メッセージのボディ部Ｍ５−２を作成し（ステップ１０３）、該接続要求メッセージボディ部Ｍ５−２と上記ＳＩＰ−ＵＲＬとをＳＩＰメッセージ処理部５３Ｃに渡し（１０４）、ＳＩＰメッセージ処理部５３Ｃからの接続応答メッセージボディ部の受信を待つ（１０５）。
【００７４】
暗号化通信制御部５１Ｃは、ＳＩＰメッセージ処理部５３Ｃから、図２４に例示した接続応答メッセージボディ部Ｍ１０−２を受信すると、受信した接続応答メッセージボディ部を解析し、今回の暗号化通信に使用すべきＳＡ情報を決定し（、ＳＡＤＢ３３Ｃに設定する（１０６）と、暗号エンジン３１Ｃに暗号化通信の適用要否判定結果を通知する（１０７）。
【００７５】
図３９Ａは、暗号化通信制御部５１ＣからＳＩＰ−ＵＲＩ取得を要求された場合、ＳＩＰメッセージ処理部５３Ｃが実行する制御動作のフローチャート１１０を示す。
ＳＩＰメッセージ処理部５３Ｃは、暗号化通信制御部５１ＣからＵＲＬを受信すると、図１５に例示したＡＯＲ取得要求メッセージＭ３を作成し（ステップ１１１）、該メッセージをＴＳＬ部５２Ｃ、ＴＣＰ／ＩＰ部３０Ｃ、ＮＩＣ部２０Ｃを介して、クライアントＣＬ１ａと同一ドメインに位置するＳＩＰサーバＳＩＰａ（レジストラＲＧａ）宛に送信する（１１２）。このとき、ＴＬＳ部５２Ｃは、レジストラＲＧａとの間でＴＬＳネゴシェーション（図１１のＳ５）を実行した後、ＴＬＳ暗号化されたＡＯＲ取得要求メッセージＭ３をＴＣＰ／ＩＰ部３０Ｃ、ＮＩＣ部２０Ｃを介してレジストラＲＧａに送信する。上記ＡＯＲ取得要求メッセージＭ３は、ＴＣＰ／ＩＰ部３０Ｃによって、ＳＩＰサーバＳＶ１宛の宛先ＩＰアドレスを含むＩＰヘッダＨ１とＵＤＰ／ＴＣＰヘッダＨ２とが付加され、ＩＰパケット形式でネットワークＮＷ１に送出される。
【００７６】
ＳＩＰメッセージ処理部５３Ｃは、レジストラＲＧａからのＡＯＲ取得応答メッセージを待っており（１１３）、ＡＯＲ取得応答メッセージを受信すると、受信メッセージを解析し（１１４）、ＡＯＲヘッダから接続先サーバに割り当てられたＡＯＲ形式のＳＩＰ−ＵＲＩを抽出する（１１５）。
【００７７】
図３９Ｂは、暗号化通信制御部５１Ｃから接続要求メッセージのボディ部を受信した時、ＳＩＰメッセージ処理部５３Ｃが実行する制御動作のフローチャート１２０を示す。
【００７８】
ＳＩＰメッセージ処理部５３Ｃは、暗号化通信制御部５１Ｃから接続要求メッセージのボディ部とＳＩＰ−ＵＲIとを受信すると、上記ＳＩＰ−ＵＲＩをスタートラインとＴｏヘッダに適用して、ヘッダ部Ｍ５−１と暗号化通信制御部５１Ｃから受信したボディ部Ｍ５−２とからなる図１７に例示した接続要求メッセージＭ５を作成する（１２１）。
【００７９】
ＳＩＰメッセージ処理部５３Ｃは、上記接続要求メッセージをＴＳＬ部５２Ｃ、ＴＣＰ／ＩＰ部３０Ｃ、ＮＩＣ部２０Ｃを介して、ＳＩＰサーバＳＩＰａのＳＩＰプロキシＰＲａ宛に送信し（１２２）、ＳＩＰプロキシＰＲａからの応答を待つ（１２３）。ＳＩＰプロキシＰＲａから接続中メッセージＭ６を受信した場合は、接続中メッセージ処理（１２４）を実行した後、ＳＩＰプロキシＰＲａからの次の応答を待つ。
【００８０】
ＳＩＰメッセージ処理部５３Ｃは、ＳＩＰプロキシＰＲａから接続応答メッセージＭ１２を受信すると、受信メッセージを解析し（１２５）、受信メッセージから抽出した図２４に例示した接続応答メッセージボディ部Ｍ１２−２を暗号化通信制御部５１Ｃに渡す（１２６）。この後、ＳＩＰメッセージ処理部５３Ｃは、図２７に例示した接続確認メッセージＭ１３を作成し、これをＴＳＬ部５２Ｃ、ＴＣＰ／ＩＰ部３０Ｃ、ＮＩＣ部２０Ｃを介して、ＳＩＰプロキシＰＲａ宛に送信し（１２７）、このルーチンを終了する。
【００８１】
図４０は、ＡＯＲ取得要求メッセージＭ３を受信した時、レジストラＲＧａのＳＩＰメッセージ処理部５３Ｒが実行する制御動作のフローチャート２００を示す。レジストラＲＧａのＳＩＰメッセージ処理部５３Ｒは、受信したＡＯＲ取得要求メッセージＭ３を解析し（ステップ２０１）、Ｔｏヘッダが示す接続先サーバＳＶ１ｂのＵＲＬを検索キーとして、ロケーションデータ検索クエリを作成し（２０２）、レジストラ処理部６０Ｒを介して、上記検索クエリをロケーションサーバＬＳＶに送信し（２０３）、ロケーションサーバからの応答を待つ（２０４）。
【００８２】
ＳＩＰメッセージ処理部５３Ｒは、レジストラ処理部６０Ｒを介して、ロケーションサーバＬＳＶからロケーションデータを受信すると、受信データが示すＳＩＰ−ＵＲＩをＡＯＲヘッダとして含む図１６に例示したＡＯＲ取得応答メッセージＭ４を作成し（２０５）、該メッセージＭ４をＴＣＰ／ＩＰ部３０Ｒ、ＮＩＣ部２０Ｒを介してＡＯＲ取得要求メッセージＭ３の送信元（この例では、クライアントＣＬ１ａ）に送信し（２０６）、このルーチンを終了する。
【００８３】
図４１（図４１Ａ〜図４１Ｄ）は、クライアントＣＬ１ａから接続要求メッセージＭ５を受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作のフローチャート３００を示す。ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐは、クライアントＣＬ１ａからの接続要求メッセージＭ５を受信すると、受信メッセージを解析し（ステップ３０１）、受信メッセージのスタートラインに記述されたＲｅｑｕｅｓｔ−ＵＲＩをチェックして（３０２）、上記Ｒｅｑｕｅｓｔ−ＵＲＩが示すドメイン名から、受信メッセージの転送先を判定する（３０３）。
【００８４】
受信メッセージの転送先が他のドメインに所属していると判定された場合、ＳＩＰメッセージ処理部５３Ｐは、ＤＮＳ検索（ＮＡＰＴＲ検索＋ＳＲＶ検索＋Ａ検索）等によって、受信メッセージの転送先ドメインのＳＩＰサーバ（ＳＩＰプロキシ）を決定する（３０４）。図１１で示した例では、ＤＮＳ検索によって、接続要求メッセージＭ５の転送先が、ＳＩＰプロキシＰＲｂであることが判明する。この場合、ＳＩＰメッセージ処理部５３Ｐは、図１９で例示した接続中メッセージＭ６をＴＬＳ部５２Ｐ、ＴＣＰ／ＩＰ部３０Ｐ、ＮＩＣ部２０Ｐを介して、接続要求メッセージＭ５の送信元であるクライアントＣＬ１ａに送信（３０５）した後、接続要求メッセージＭ５に新たなＶｉａヘッダを付加した形の接続要求メッセージＭ７をＳＩＰプロキシＰＲｂに転送して（３０６）、ＳＩＰプロキシＰＲｂからの応答を待つ（３０７）。
【００８５】
ＳＩＰメッセージ処理部５３Ｐは、ＳＩＰプロキシＰＲｂから接続中メッセージＭ８を受信すると、接続中メッセージ処理（３０８）を実行した後、ＳＩＰプロキシＰＲｂからの次の応答を待つ。ＳＩＰメッセージ処理部５３Ｐは、ＳＩＰプロキシＰＲｂから接続応答メッセージＭ１１を受信すると、受信メッセージを解析し（３０９）、受信メッセージから自ＳＩＰ−ＵＲＩを含むＶｉａヘッダを除去し、接続応答メッセージＭ１２として、接続要求元（クライアントＣＬ１ａ）に転送する（３１０）。この後、ＳＩＰメッセージ処理部５３Ｐは、接続要求元（クライアントＣＬ１ａ）からの応答を待つ（３１１）。ＳＩＰメッセージ処理部５３Ｐは、接続確認メッセージＭ１３を受信すると、受信メッセージを解析し（３１２）、受信メッセージに自分のＳＩＰ−ＵＲＩを含む新たなＶｉａヘッダを付加し、接続確認メッセージＭ１３として、ＳＩＰプロキシＰＲｂに転送して（３１３）、このルーチンを終了する。
【００８６】
判定ステップ３０３で、クライアント端末ＣＬ１ａから受信した接続要求メッセージの転送先が、例えば、サーバＳＶ１ａ（またはＳＶ２ａ）のように、ＳＩＰプロキシＰＲａと同一ドメインに所属していると判定された場合、ＳＩＰメッセージ処理部５３Ｐは、受信メッセージのＲｅｑｕｅｓｔ−ＵＲＩが示すＳＩＰ−ＵＲＩを検索キーとするロケーションデータ（ＩＰアドレス）検索クエリを作成し（３１５）、該ロケーションデータ検索クエリをロケーションサーバＬＳＶに送信して（３１６）、ロケーションサービス応答を待つ（３１７）。
【００８７】
ＳＩＰメッセージ処理部５３Ｐは、ロケーションサーバＬＳＶからロケーションデータを受信すると、上記ロケーションデータが示す接続先サーバのＩＰアドレスを宛先ＩＰアドレスに適用して、接続要求メッセージをＩＰパケット形式でネットワークＮＷ１に送信し（３１８）、接続先サーバからの応答を待つ（３１９）。上記接続要求メッセージには、ＳＩＰプロキシＰＲａのＳＩＰ−ＵＲＩを含む新たなＶｉａヘッダが付加されている。
【００８８】
接続先サーバから接続応答メッセージを受信すると、ＳＩＰメッセージ処理部５３Ｐは、受信メッセージを解析し（３２０）、自分と対応するＶｉａヘッダを除去した形の接続応答メッセージを接続要求元に転送して（３２１）、接続要求元（クライアントＣＬ１ａ）からの応答を待つ（３２２）。ＳＩＰメッセージ処理部５３Ｐは、接続要求元から接続確認メッセージを受信すると、受信メッセージを解析し（３２３）、新たなＶｉａヘッダを付加した形の接続確認メッセージを接続先サーバに転送して（３２４）、このルーチンを終了する。
【００８９】
図４２（図４２Ａ、図４２Ｂ）は、接続先サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓが、ＳＩＰプロキシＰＲｂから接続要求メッセージＭ９を受信した時に実行する制御動作のフローチャート４００を示す。ＳＩＰプロキシＰＲｂから接続先サーバＳＶ１ｂに送信された接続要求メッセージＭ９は、ＴＬＳ部５２Ｓで復号した後、ＳＩＰメッセージ処理部５３Ｓに入力される。ＳＩＰメッセージ処理部５３Ｓは、接続要求メッセージＭ９を受信すると、受信メッセージを解析し（ステップ４０１）、受信メッセージから抽出した接続要求メッセージボディ部Ｍ５−２を暗号化通信制御部５１Ｓに渡し（４０２）、暗号化通信制御部５１Ｓからの応答を待つ（４０３）。
【００９０】
ＳＩＰメッセージ処理部５３Ｓは、暗号化通信制御部５１Ｓから接続応答メッセージボディ部Ｍ１０−２を受信すると、図２５に例示した接続応答メッセージＭ１１を作成する（４０４）。ＳＩＰメッセージ処理部５３Ｓは、ＴＬＳ部、ＴＣＰ／ＩＰ部、ＮＩＣ部を介して、上記接続応答メッセージＭ１１をＳＩＰプロキシＰＲｂに転送し（４０５）、ＳＩＰプロキシＰＲｂからの応答を待つ（４０６）。ＳＩＰメッセージ処理部５３Ｓは、ＳＩＰプロキシＰＲｂから、接続確認メッセージＭ１５を受信すると、受信メッセージを解析し（４０７）、接続確認メッセージＭ１５を受信したことを暗号化通信制御部５１Ｓに通知して（４０８）、このルーチンを終了する。
【００９１】
図４３は、ＳＩＰメッセージ処理部５３Ｓから接続要求メッセージボディ部Ｍ５−２を受信した時、サーバＳＶ１ｂの暗号化通信制御部５１Ｓが実行する制御動作の示すフローチャート４２０を示す。
暗号化通信制御部５１Ｓは、ＳＩＰメッセージ処理部５３Ｓから受信した接続要求メッセージボディ部Ｍ５−２を解析し（ステップ４２１）、接続要求メッセージボディ部Ｍ５−２に記述されたＳＡ情報（図１８の例では、トランスフォームペイロード９２−１、９２−２）から、クライアントとの暗号化通信に適用すべきＳＡを選択して、図２４に例示した接続応答メッセージのボディ部Ｍ１０−２を作成する（４２２）。暗号化通信制御部５１Ｓは、上記接続応答メッセージボディ部Ｍ１０−２をＳＩＰメッセージ処理部５３Ｓに渡し（４２３）、ＳＩＰメッセージ処理部５３Ｓからの応答を待つ（４２４）。暗号化通信制御部５１Ｓは、ＳＩＰメッセージ処理部５３Ｓから接続確認メッセージの受信通知を受けると、ＳＡＤＢ３３ＳにＳＡ情報を設定して（４２５）、このルーチンを終了する。
【００９２】
図４４は、クライアントＣＬ１ａにおいて、暗号エンジン３１Ｃが発行する通信終了要求に応答して暗号化通信制御部５１Ｃが実行する制御動作のフローチャート１３０を示す。クライアントＣＬ１ａのユーザが、サーバＳＶ１ｂと交信していたアプリケーションを終了すると、暗号エンジン３１Ｃから暗号化通信制御部５１Ｃに、通信終了要求が発行される。ＳＡ／ＳＰ制御部５１Ｃは、暗号エンジン３１Ｃから通信終了要求を受信すると、ＳＩＰメッセージ処理部５３Ｃに、切断要求メッセージの発行を要求し（１３１）、ＳＩＰメッセージ処理部５３Ｃからの応答を待つ（１３２）。ＳＡ／ＳＰ制御部５１Ｃは、ＳＩＰメッセージ処理部５３Ｃから切断応答メッセージの受信通知を受けると、上記暗号鍵消去要求と対応するＳＡＤＢ３３Ｓの設定値を消去し（１３３）、このルーチンを終了する。
【００９３】
図４５は、ＳＡ／ＳＰ制御部５１Ｃから切断要求メッセージの発行要求を受信した時にＳＩＰメッセージ処理部５３Ｃが実行する制御動作のフローチャート１４０を示す。ＳＩＰメッセージ処理部５３Ｃは、ＳＡ／ＳＰ制御部５１Ｃから切断要求メッセージの発行要求を受信すると、図３０に例示した切断要求メッセージＭ２０を作成し（ステップ１４１）、ＴＬＳ部５２Ｃ、ＴＣＰ／ＩＰ部３０Ｃの暗号エンジン３１Ｃ、ＮＩＣ部２０Ｃを介して、上記切断要求メッセージＭ２０のＩＰパケットをＳＩＰサーバＳＩＰａ（ＳＩＰプロキシＰＲａ）に送信する（１４２）。
【００９４】
ＳＩＰメッセージ処理部５３Ｃは、ＳＩＰプロキシＰＲａからの応答を待ち（１４３）、切断中メッセージＭ２１を受信した場合は、切断中メッセージ処理（１４４）を実行した後、ＳＩＰプロキシＰＲａからの次の応答を待つ。ＳＩＰメッセージ処理部５３Ｃは、ＳＩＰプロキシＰＲａから図３７に例示した切断応答メッセージＭ２７を受信すると、受信メッセージを解析し（１４５）、暗号化通信制御部５１Ｃに切断応答メッセージの受信を通知し（１４６）、このルーチンを終了する。
【００９５】
図４６（図４６Ａ、図４６Ｂ）は、クライアントから切断要求メッセージＭ２０を受信した時にＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作のフローチャート３４０を示す。ＳＩＰメッセージ処理部５３Ｐは、受信した切断要求メッセージＭ２０を解析し（ステップ３４１）、受信メッセージのＲｅｑｕｅｓｔ−ＵＲＩをチェックする（３４２）。ＳＩＰメッセージ処理部５３Ｐは、Ｒｅｑｕｅｓｔ−ＵＲＩに記述されたドメイン名から、受信メッセージの転送先を判定し（３４３）、転送先が他のドメインに所属していると判定された場合、ＤＮＳ検索（ＮＡＰＴＲ検索＋ＳＲＶ検索＋Ａ検索）等によって、受信メッセージの転送先ドメインのＳＩＰサーバ（ＳＩＰプロキシ）を決定する（３４４）。
【００９６】
図１２で示した例では、上記ＤＮＳ検索によって、切断要求メッセージＭ２０の転送先が、ＳＩＰプロキシＰＲｂであることが判明する。この場合、ＳＩＰメッセージ処理部５３Ｐは、ＴＬＳ部５２Ｐ、ＴＣＰ／ＩＰ部３０Ｐ、ＮＩＣ部２０Ｐを介して、切断要求メッセージＭ２０の送信元であるクライアントＣＬ１ａに、図３１に例示した切断中メッセージＭ２１を送信（３４５）した後、切断要求メッセージＭ２０に新たなＶｉａヘッダを付加し、ＳＩＰプロキシＰＲａに対応するＲｏｕｔｅヘッダを除去した切断要求メッセージＭ２２をＳＩＰプロキシＰＲｂに転送し（３４６）、ＳＩＰプロキシＰＲｂからの応答を待つ（３４７）。
【００９７】
ＳＩＰメッセージ処理部５３Ｐは、ＳＩＰプロキシＰＲｂから切断中メッセージＭ２３を受信すると、切断中メッセージ処理（３４８）を実行した後、ＳＩＰプロキシＰＲｂからの次の応答を待つ。ＳＩＰメッセージ処理部５３Ｐは、ＳＩＰプロキシＰＲｂから切断応答メッセージＭ２６を受信すると、受信メッセージを解析し（３４９）、受信メッセージから自ＳＩＰ−ＵＲＩを含むＶｉａヘッダを除去し、切断応答メッセージＭ２７として、切断要求元（クライアントＣＬ１ａ）に転送し（３５０）、このルーチンを終了する。
【００９８】
尚、判定ステップ３４３で、もし、クライアント端末ＣＬ１ａから受信した切断要求メッセージＭ２０の転送先が、ＳＩＰプロキシＰＲａと同一ドメインに所属していると判定された場合、ＳＩＰメッセージ処理部５３Ｐは、受信メッセージのＲｅｑｕｅｓｔ−ＵＲＩが示すＳＩＰ−ＵＲＩを検索キーとするロケーションデータ（ＩＰアドレス）検索クエリを作成し（３５１）、該検索クエリをロケーションサーバＬＳＶに送信して（３５２）、ロケーションサービス応答を待つ（３５３）。
【００９９】
ＳＩＰメッセージ処理部５３Ｐは、ロケーションサーバＬＳＶからロケーションデータを受信すると、上記ロケーションデータが示すサーバＩＰアドレスを宛先ＩＰアドレスに適用して、切断要求メッセージのＩＰパケットをネットワークＮＷ１に送信し（３５４）、サーバからの応答を待つ（３５５）。尚、上記切断要求メッセージには、ＳＩＰプロキシＰＲａのＳＩＰ−ＵＲＩを含む新たなＶｉａヘッダが付加されている。切断要求メッセージの宛先サーバから切断応答メッセージを受信すると、ＳＩＰメッセージ処理部５３Ｐは、受信メッセージを解析し（３５６）、自分のＶｉａヘッダを除去した形の切断応答メッセージを切断要求元に転送し（３５７）、このルーチンを終了する。
【０１００】
図４７は、ＳＩＰプロキシから切断要求メッセージＭ２４を受信した時、サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓが実行する制御動作のフローチャート４３０を示す。ＳＩＰメッセージ処理部５３Ｓは、ＴＬＳ部５２Ｓを介して切断要求メッセージＭ２４を受信すると、受信メッセージを解析し（ステップ４３１）、暗号化通信制御部５１Ｓに対して、切断すべき通信の識別情報（例えば、Ｃａｌｌ−ＩＤ）を指定して、切断要求の受信を通知し（４３２）、暗号化通信制御部５１Ｓからの応答を待つ（４３３）。ＳＩＰメッセージ処理部５３Ｓは、暗号化通信制御部５１Ｓから切断応答を受信すると、図３５に例示した切断応答メッセージＭ２５を作成し（４３４）、ＴＬＳ部、ＴＣＰ／ＩＰ部、ＮＩＣ部を介してＳＩＰプロキシＰＲｂに転送し（４３５）、このルーチンを終了する。
【０１０１】
図４８は、ＳＩＰメッセージ処理部５３Ｓから切断要求の発生を通知された時、暗号化通信制御部５１Ｓが実行する制御動作のフローチャート４４０を示す。暗号化通信制御部５１Ｓは、通知された通信識別情報にもとづいて、ＳＡＤＢ３３Ｓから消去すべきＳＡ情報を特定し（ステップ４４１）、当該ＳＡ情報を消去し（４４２）、このルーチンを終了する。
【０１０２】
なお、本実施例では、登録要求メッセージのボディ部に識別情報６３を含め、登録要求メッセージを解析することによって、識別情報管理テーブル６４を更新するようにしている。しかしながら、本発明はこれに限定されず、識別情報管理テーブル６４、あるいはその一部のエントリは、ロケーションサーバＬＳＶの管理者によって予め値が設定されていてもよい。
【０１０３】
次に、図４９から図５４を参照して、本発明による暗号化データ通信の第２の実施例について説明する。上述した第１の実施例では、ＳＩＰプロキシPRとレジストラRGとは同一のＳＩＰサーバ上で動作していた。また、識別情報管理テーブル６４で識別情報とＳＩＰ−ＵＲＩとの関連を検索する場合に検索用のＳＩＰメッセージを使用し、ＳＩＰプロキシＰＲが当該ＳＩＰメッセージのヘッダに基づいて、識別情報管理テーブル６４を検索していた。また、クライアントやサーバと、ＳＩＰサーバとの間の通信はＴＬＳで保護していた。
【０１０４】
本発明の第２の実施例では、識別情報管理テーブル６４へのロケーション情報の登録や削除、および識別情報管理テーブル６４の検索を行う、識別情報管理サービス６５が動作する識別情報管理サーバＩＳＶを、別途設けたことを特徴とする。さらには、クライアントやサーバと、識別情報管理テーブル６４との間で交換するＳＩＰメッセージのボディ部分をメッセージ暗号（Ｓ／ＭＩＭＥ）で保護することを特徴とする。
【０１０５】
本発明の第２の実施例におけるネットワーク構成は、図４９に示すように、ＳＩＰサーバＳＩＰａが管理するネットワークＮＷ１と、ロケーションサーバＬＳＶと、ＤＮＳ（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」のように、着目フィールドでＩＰｖ４（またはＩＰｖ６）というスキームを検出した場合は、その後にＩＰアドレスが記述されているものと約束してもよい。
【０１２２】
さらには、実施例では、クライアントのアプリケーションプログラムが接続先サーバのＩＰアドレス宛にパケットを送信する操作を行った場合に、接続先サーバのＩＰアドレスに対応するＳＩＰ−ＵＲＩを取得するためのＡＯＲ取得要求メッセージをＳＩＰサーバに送信するようにしているが、本発明はこれに限定されず、当該アプリケーションプログラムが使用している任意の体系の接続先識別子から、当該接続先識別子に対応するリソース識別子（接続先サーバを識別するためにセッション管理サーバが採用している識別子）を取得するために適用することができる。例えば、クライアントのアプリケーションプログラムが接続先サーバを指定する情報を含むＵＲＬへの接続を要求する操作を行った場合に、当該ＵＲＬに対応するＳＩＰ−ＵＲＩを取得するためのＡＯＲ取得要求メッセージをＳＩＰサーバに送信するようにしてもよい。このとき、前記ＵＲＬは事前にＳＩＰサーバに登録するようにしてもよいし、接続先サーバがロケーション登録を行う際のロケーション登録要求メッセージに当該接続先サーバがアクセス可能なＵＲＬのリストを含めるようにしてもよい。
【０１２３】
さらには、実施例では、クライアントやサーバとＳＩＰサーバとの間の通信はＴＬＳによって保護しているが、本発明はこれに限定されず、Ｓ／ＭＩＭＥによって保護してもよい。また、第２の実施例では、クライアントやサーバと識別情報管理サーバＩＳＶとの間でＳ／ＭＩＭＥで保護されたＳＩＰメッセージを送受するようにしても良い。
【図面の簡単な説明】
【０１２４】
【図１】公開鍵暗号化通信における従来の認証システムを説明するため図。
【図２】ＩＰｓｅｃによる暗号化通信を行うために従来のクライアントが備えるソフトウェアの基本的なブロック構成を示す図。
【図３】本発明と関係するＳＩＰプロキシを適用した認証システムを説明するための図。
【図４】本発明のセッション管理サーバ（ＳＩＰサーバ）を含むネットワーク構成の１例を示す図。
【図５】図４に示したロケーションサーバＬＳＶが備えるロケーションサービステーブルの１例を示す図。
【図６】図４に示したＳＩＰプロキシＰＲａのハードウェア構成を示すブロック図。
【図７】図４に示したクライアントＣＬ１ａの基本的なソフトウェア構造を示す図。
【図８】図４に示したサーバＳＶ１ｂの基本的なソフトウェア構造を示す図。
【図９】図４に示したＳＩＰプロキシＰＲａの基本的なソフトウェア構造を示す図。
【図１０】図４に示したレジストラＲＧａの基本的なソフトウェア構造を示す図。
【図１１】本発明による暗号化通信の第１の実施例を説明するためのシーケンス図の一部。
【図１２】本発明による暗号化通信の第１の実施例を説明するためのシーケンス図の残部。
【図１３】図１１におけるロケーション登録要求メッセージＭ１のフォーマットの１例を示す図。
【図１４】図１１におけるロケーション登録応答メッセージＭ２のフォーマットの１例を示す図。
【図１５】図１１におけるロケーションＡＯＲ取得要求メッセージＭ３のフォーマットの１例を示す図。
【図１６】図１１におけるロケーションＡＯＲ取得応答メッセージＭ４のフォーマットの１例を示す図。
【図１７】図１１における接続要求メッセージＭ５のフォーマットの１例を示す図。
【図１８】接続要求メッセージＭ５のボディ部Ｍ５−２のフォーマットの１例を示す図。
【図１９】図１１における接続中メッセージＭ６のフォーマットの１例を示す図。
【図２０】図１１における接続要求メッセージＭ７のフォーマットの１例を示す図。
【図２１】図１２における接続中メッセージＭ８のフォーマットの１例を示す図。
【図２２】図１２における接続要求メッセージＭ９のフォーマットの１例を示す図。
【図２３】図１２における接続応答メッセージＭ１０のフォーマットの１例を示す図。
【図２４】接続応答メッセージＭ１０のボディ部Ｍ１０−２のフォーマットの１例を示す図。
【図２５】図１２における接続応答メッセージＭ１１のフォーマットの１例を示す図。
【図２６】図１２における接続応答メッセージＭ１２のフォーマットの１例を示す図。
【図２７】図１２における接続確認メッセージＭ１３のフォーマットの１例を示す図。
【図２８】図１２における接続確認メッセージＭ１４のフォーマットの１例を示す図。
【図２９】図１２における接続確認メッセージＭ１５のフォーマットの１例を示す図。
【図３０】図１２における切断要求メッセージＭ２０のフォーマットの１例を示す図。
【図３１】図１２における切断中メッセージＭ２１のフォーマットの１例を示す図。
【図３２】図１２における切断要求メッセージＭ２２のフォーマットの１例を示す図。
【図３３】図１２における切断中メッセージＭ２３のフォーマットの１例を示す図。
【図３４】図１２における切断要求メッセージＭ２４のフォーマットの１例を示す図。
【図３５】図１２における切断応答メッセージＭ２５のフォーマットの１例を示す図。
【図３６】図１２における切断応答メッセージＭ２６のフォーマットの１例を示す図。
【図３７】図１２における切断応答メッセージＭ２７のフォーマットの１例を示す図。
【図３８】鍵交換要求を受信した時、クライアントＣＬ１ａの暗号化通信制御部５１Ｃが実行する制御動作を示すフローチャート。
【図３９Ａ】接続要求メッセージのボディ部を受信した時、クライアントＣＬ１ａのＳＩＰメッセージ処理部５３Ｃが実行する制御動作を示すフローチャートの一部。
【図３９Ｂ】接続要求メッセージのボディ部を受信した時、クライアントＣＬ１ａのＳＩＰメッセージ処理部５３Ｃが実行する制御動作を示すフローチャートの残部。
【図４０】ＡＯＲ取得要求メッセージを受信した時、レジストラＲＧａのＳＩＰメッセージ処理部５３Ｒが実行する制御動作を示すフローチャート。
【図４１Ａ】接続要求メッセージを受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作を示すフローチャートの第１部分。
【図４１Ｂ】接続要求メッセージを受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作を示すフローチャートの第２部分。
【図４１Ｃ】接続要求メッセージを受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作を示すフローチャートの第３部分。
【図４１Ｄ】接続要求メッセージを受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作を示すフローチャートの第４部分。
【図４２】接続要求メッセージを受信した時、サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓが実行する制御動作を示すフローチャート。
【図４３】接続要求メッセージのボディ部を受信した時、サーバＳＶ１ｂの暗号化通信制御部５１Ｓが実行する制御動作を示すフローチャート。
【図４４】鍵消去要求を受信した時、クライアントＣＬ１ａの暗号化通信制御部５１Ｃが実行する制御動作を示すフローチャート。
【図４５】切断要求メッセージの発行要求を受信した時、クライアントＣＬ１ａのＳＩＰメッセージ処理部５３Ｃが実行する制御動作を示すフローチャート。
【図４６Ａ】切断要求メッセージを受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作を示すフローチャートの一部。
【図４６Ｂ】切断要求メッセージを受信した時、ＳＩＰプロキシＰＲａのＳＩＰメッセージ処理部５３Ｐが実行する制御動作を示すフローチャートの残部。
【図４７】切断要求メッセージを受信した時、サーバＳＶ１ｂのＳＩＰメッセージ処理部５３Ｓが実行する制御動作を示すフローチャート。
【図４８】切断要求の発生通知を受信した時、サーバＳＶ１ｂの暗号化通信制御部５１Ｓが実行する制御動作を示すフローチャート。
【図４９】本発明による暗号化通信の第２の実施例のネットワーク構成の１例を示す図。
【図５０】本発明による暗号化通信の第２の実施例を説明するためのシーケンス図の一部。
【図５１】図５０における識別情報登録要求メッセージＭ１０１のフォーマットの１例を示す図。
【図５２】図５０における識別情報登録応答メッセージＭ１０３のフォーマットの１例を示す図。
【図５３】図５０におけるＡＯＲ取得要求メッセージＭ１０５のフォーマットの１例を示す図。
【図５４】図５０におけるＡＯＲ取得応答メッセージＭ１０７のフォーマットの１例を示す図。
【符号の説明】
【０１２５】
ＣＬ１ａ〜ＣＬ２ｂ：クライアント、ＳＶ１ａ〜ＳＶ２ｂ：サーバ、
ＳＩＰａ、ＳＩＰｂ：ＳＩＰサーバ、ＰＲａ、ＰＲｂ：ＳＩＰプロキシ、
ＲＧａ、ＲＧｂ：レジストラ、ＬＳＶ：ロケーションサーバ、ＩＳＶ：識別情報管理サーバ、
２０：ネットワークインタフェースカード部、３０：暗号化通信機能部、
３１：暗号エンジン、４０：アプリケーションソフト、５０：鍵管理プロセス、
５１：暗号化通信制御部、５２：ＴＬＳ部、５３：ＳＩＰメッセージ処理部、
６０：レジストラ処理部。
【特許請求の範囲】
【請求項１】
セッション管理サーバが接続された通信ネットワークを介して行われるクライアントとサーバとの間のデータ通信方法であって、
上記クライアントから上記セッション管理サーバに、接続先サーバの接続先識別子を指定して、該接続先サーバに割り当てられた所属ドメイン名を含むリソース識別子を問い合わせる第１ステップと、
上記セッション管理サーバが、接続先識別子とリソース識別子との対応関係を管理している識別情報管理テーブルから、上記接続先サーバの接続先識別子と対応するリソース識別子を取得し、上記クライアントに通知する第２ステップと、
上記クライアントから上記セッション管理サーバに、要求リソースを上記接続先サーバのリソース識別子で指定した接続要求メッセージを送信する第３ステップと、
上記セッション管理サーバが、受信した接続要求メッセージに記述された上記リソース識別子に含まれるドメイン名に基づいて受信メッセージの転送先を判定し、受信メッセージを接続先サーバまたは該接続先サーバの所属ドメインを管理する別のセッション管理サーバに転送する第４ステップとからなることを特徴とするデータ通信方法。
【請求項２】
セッション管理サーバが接続された通信ネットワークを介して行われるクライアントとサーバとの間のデータ通信方法であって、
上記クライアントから上記セッション管理サーバに、要求リソースを接続先サーバの接続先識別子で指定した接続要求メッセージを送信する第１ステップと、
上記接続要求メッセージを受信したセッション管理サーバが、接続先識別子とリソース識別子との対応関係を管理している識別情報管理テーブルから、上記接続先サーバの接続先識別子と対応するリソース識別子を取得する第２ステップと、
上記セッション管理サーバが、受信メッセージに要求リソースとして記述された接続先識別子を上記識別情報管理テーブルから取得したリソース識別子に書き換える第３ステップと、
上記セッション管理サーバが、上記リソース識別子に含まれるドメイン名に基づいて受信メッセージの転送先を判定し、受信メッセージを接続先サーバまたは該接続先サーバの所属ドメインを管理する別のセッション管理サーバに転送する第４ステップとからなることを特徴とするデータ通信方法。
【請求項３】
セッション管理サーバが接続された通信ネットワークを介して行われるクライアントとサーバとの間のデータ通信方法であって、
上記クライアントから接続先となるサーバに、該サーバに割り当てられた所属ドメイン名を含むリソース識別子を問い合わせる第１ステップと、
上記サーバから上記クライアントに、問い合わせリソース識別子を通知する第２ステップと、
上記クライアントから上記セッション管理サーバに、要求リソースを上記接続先サーバのリソース識別子で指定した接続要求メッセージを送信する第３ステップと、
上記セッション管理サーバが、受信した接続要求メッセージに記述された上記リソース識別子に含まれるドメイン名に基づいて受信メッセージの転送先を判定し、受信メッセージを接続先サーバまたは該接続先サーバの所属ドメインを管理する別のセッション管理サーバに転送する第４ステップとからなることを特徴とするデータ通信方法。
【請求項４】
前記接続要求メッセージの受信に応答して、前記接続先サーバから前記セッション管理サーバを介して前記要求元クライアントに、暗号化通信に必要となるパラメータ情報を含む接続応答メッセージを返送する第５ステップと、
上記クライアントと接続先サーバとの間で、上記接続応答メッセージで指定されたパラメータ情報に従って暗号化されたメッセージを含むパケットを通信する第６ステップを含むことを特徴とする請求項１〜請求項３の何れかに記載のデータ通信方法。
【請求項５】
前記セッション管理サーバが、ＳＩＰ（Session Initiation Protocol）サーバからなり、前記クライアントと前記セッション管理サーバとの間の通信メッセージがＲＦＣ３２６１に規定されたＴＬＳ（Transport Layer Security）によって暗号化され、上記接続先識別子は接続先サーバのＩＰアドレスであることを特徴とする請求項１〜請求項４の何れかに記載のデータ通信方法。
【請求項６】
前記クライアントと接続先サーバとの間の通信データが、ＲＦＣ２４０１に規定されたＩＰｓｅｃ（Internet Protocol Security）によって暗号化されることを特徴とする請求項４または請求項５に記載のデータ通信方法。
【請求項７】
通信ネットワークを介してクライアントおよびサーバと通信するセッション管理サーバであって、
上記クライアントから、要求リソースを接続先サーバの接続先識別子で指定した接続要求メッセージを受信した時、接続先識別子とリソース識別子との対応関係を管理している識別情報管理テーブルから、上記接続先サーバの接続先識別子と対応するリソース識別子を取得し、受信メッセージに記述された要求リソースを接続先識別子から上記リソース識別子に書き換えるための手段と、
上記リソース識別子に含まれるドメイン名に基づいて受信メッセージの転送先を判定し、受信メッセージを接続先サーバまたは該接続先サーバの所属ドメインを管理する別のセッション管理サーバに転送するための手段とを有することを特徴とするセッション管理サーバ。
【請求項８】
前記通信ネットワークに接続されたネットワークインタフェース部と、
セッション制御メッセージを処理するメッセージ処理部と、
上記ネットワークインタフェース部から受信した暗号化メッセージを復号化して上記メッセージ処理部に渡すと共に、上記メッセージ処理部から出力されたセッション制御メッセージを暗号化して上記ネットワークインタフェース部に出力するためのセキュリティ部とを有し、
上記メッセージ処理部が、前記要求リソースの書き換え手段と、前記受信メッセージの転送手段を備えることを特徴とする請求項７に記載のセッション管理サーバ。
【請求項９】
通信ネットワークを介してセッション管理サーバおよびサーバと通信するクライアント端末であって、
上記通信ネットワークに接続されたネットワークインタフェース部と、
セッション制御メッセージを処理するメッセージ処理部と、
アプリケーションプログラムが発生する接続先サーバ宛の送信メッセージを暗号化して上記ネットワークインタフェース部に出力すると共に、上記ネットワークインタフェース部から受信した暗号化メッセージを復号化して上記アプリケーションプログラムに渡すための第１セキュリティ部と、
上記セキュリティ部から、接続先サーバとの暗号化パラメータの交換要求が発生した時、接続先サーバを接続先識別子で指定した接続要求メッセージを上記メッセージ処理部に出力し、上記メッセージ処理部から接続応答メッセージを受信した時、該受信メッセージから抽出した暗号化パラメータを上記第１セキュリティ部に渡すセキュリティ情報制御部とからなり、
上記メッセージ処理部が、上記セキュリティ情報制御部から接続要求メッセージを受信した時、上記接続先識別子に基づいて上記セッション管理サーバまたは接続先サーバから接続先サーバのリソース識別子を取得し、該リソース識別子で要求リソースを指定した形で、上記接続要求メッセージを上記セッション管理サーバに送信することを特徴とするクライアント端末。
【請求項１０】
前記ネットワークインタフェース部から受信した暗号化されたセッション制御メッセージを復号化して上記メッセージ処理部に渡すと共に、上記メッセージ処理部から出力されたセッション制御メッセージを暗号化して上記ネットワークインタフェース部に出力するための第２セキュリティ部を有し、
前記接続先サーバとの通信データが前記第１セキュリティ部によって暗号化され、前記セッション管理サーバと通信メッセージが上記第２セキュリティ部によって暗号化されることを特徴とする請求項９に記載のクライアント端末。
【請求項１】
セッション管理サーバが接続された通信ネットワークを介して行われるクライアントとサーバとの間のデータ通信方法であって、
上記クライアントから上記セッション管理サーバに、接続先サーバの接続先識別子を指定して、該接続先サーバに割り当てられた所属ドメイン名を含むリソース識別子を問い合わせる第１ステップと、
上記セッション管理サーバが、接続先識別子とリソース識別子との対応関係を管理している識別情報管理テーブルから、上記接続先サーバの接続先識別子と対応するリソース識別子を取得し、上記クライアントに通知する第２ステップと、
上記クライアントから上記セッション管理サーバに、要求リソースを上記接続先サーバのリソース識別子で指定した接続要求メッセージを送信する第３ステップと、
上記セッション管理サーバが、受信した接続要求メッセージに記述された上記リソース識別子に含まれるドメイン名に基づいて受信メッセージの転送先を判定し、受信メッセージを接続先サーバまたは該接続先サーバの所属ドメインを管理する別のセッション管理サーバに転送する第４ステップとからなることを特徴とするデータ通信方法。
【請求項２】
セッション管理サーバが接続された通信ネットワークを介して行われるクライアントとサーバとの間のデータ通信方法であって、
上記クライアントから上記セッション管理サーバに、要求リソースを接続先サーバの接続先識別子で指定した接続要求メッセージを送信する第１ステップと、
上記接続要求メッセージを受信したセッション管理サーバが、接続先識別子とリソース識別子との対応関係を管理している識別情報管理テーブルから、上記接続先サーバの接続先識別子と対応するリソース識別子を取得する第２ステップと、
上記セッション管理サーバが、受信メッセージに要求リソースとして記述された接続先識別子を上記識別情報管理テーブルから取得したリソース識別子に書き換える第３ステップと、
上記セッション管理サーバが、上記リソース識別子に含まれるドメイン名に基づいて受信メッセージの転送先を判定し、受信メッセージを接続先サーバまたは該接続先サーバの所属ドメインを管理する別のセッション管理サーバに転送する第４ステップとからなることを特徴とするデータ通信方法。
【請求項３】
セッション管理サーバが接続された通信ネットワークを介して行われるクライアントとサーバとの間のデータ通信方法であって、
上記クライアントから接続先となるサーバに、該サーバに割り当てられた所属ドメイン名を含むリソース識別子を問い合わせる第１ステップと、
上記サーバから上記クライアントに、問い合わせリソース識別子を通知する第２ステップと、
上記クライアントから上記セッション管理サーバに、要求リソースを上記接続先サーバのリソース識別子で指定した接続要求メッセージを送信する第３ステップと、
上記セッション管理サーバが、受信した接続要求メッセージに記述された上記リソース識別子に含まれるドメイン名に基づいて受信メッセージの転送先を判定し、受信メッセージを接続先サーバまたは該接続先サーバの所属ドメインを管理する別のセッション管理サーバに転送する第４ステップとからなることを特徴とするデータ通信方法。
【請求項４】
前記接続要求メッセージの受信に応答して、前記接続先サーバから前記セッション管理サーバを介して前記要求元クライアントに、暗号化通信に必要となるパラメータ情報を含む接続応答メッセージを返送する第５ステップと、
上記クライアントと接続先サーバとの間で、上記接続応答メッセージで指定されたパラメータ情報に従って暗号化されたメッセージを含むパケットを通信する第６ステップを含むことを特徴とする請求項１〜請求項３の何れかに記載のデータ通信方法。
【請求項５】
前記セッション管理サーバが、ＳＩＰ（Session Initiation Protocol）サーバからなり、前記クライアントと前記セッション管理サーバとの間の通信メッセージがＲＦＣ３２６１に規定されたＴＬＳ（Transport Layer Security）によって暗号化され、上記接続先識別子は接続先サーバのＩＰアドレスであることを特徴とする請求項１〜請求項４の何れかに記載のデータ通信方法。
【請求項６】
前記クライアントと接続先サーバとの間の通信データが、ＲＦＣ２４０１に規定されたＩＰｓｅｃ（Internet Protocol Security）によって暗号化されることを特徴とする請求項４または請求項５に記載のデータ通信方法。
【請求項７】
通信ネットワークを介してクライアントおよびサーバと通信するセッション管理サーバであって、
上記クライアントから、要求リソースを接続先サーバの接続先識別子で指定した接続要求メッセージを受信した時、接続先識別子とリソース識別子との対応関係を管理している識別情報管理テーブルから、上記接続先サーバの接続先識別子と対応するリソース識別子を取得し、受信メッセージに記述された要求リソースを接続先識別子から上記リソース識別子に書き換えるための手段と、
上記リソース識別子に含まれるドメイン名に基づいて受信メッセージの転送先を判定し、受信メッセージを接続先サーバまたは該接続先サーバの所属ドメインを管理する別のセッション管理サーバに転送するための手段とを有することを特徴とするセッション管理サーバ。
【請求項８】
前記通信ネットワークに接続されたネットワークインタフェース部と、
セッション制御メッセージを処理するメッセージ処理部と、
上記ネットワークインタフェース部から受信した暗号化メッセージを復号化して上記メッセージ処理部に渡すと共に、上記メッセージ処理部から出力されたセッション制御メッセージを暗号化して上記ネットワークインタフェース部に出力するためのセキュリティ部とを有し、
上記メッセージ処理部が、前記要求リソースの書き換え手段と、前記受信メッセージの転送手段を備えることを特徴とする請求項７に記載のセッション管理サーバ。
【請求項９】
通信ネットワークを介してセッション管理サーバおよびサーバと通信するクライアント端末であって、
上記通信ネットワークに接続されたネットワークインタフェース部と、
セッション制御メッセージを処理するメッセージ処理部と、
アプリケーションプログラムが発生する接続先サーバ宛の送信メッセージを暗号化して上記ネットワークインタフェース部に出力すると共に、上記ネットワークインタフェース部から受信した暗号化メッセージを復号化して上記アプリケーションプログラムに渡すための第１セキュリティ部と、
上記セキュリティ部から、接続先サーバとの暗号化パラメータの交換要求が発生した時、接続先サーバを接続先識別子で指定した接続要求メッセージを上記メッセージ処理部に出力し、上記メッセージ処理部から接続応答メッセージを受信した時、該受信メッセージから抽出した暗号化パラメータを上記第１セキュリティ部に渡すセキュリティ情報制御部とからなり、
上記メッセージ処理部が、上記セキュリティ情報制御部から接続要求メッセージを受信した時、上記接続先識別子に基づいて上記セッション管理サーバまたは接続先サーバから接続先サーバのリソース識別子を取得し、該リソース識別子で要求リソースを指定した形で、上記接続要求メッセージを上記セッション管理サーバに送信することを特徴とするクライアント端末。
【請求項１０】
前記ネットワークインタフェース部から受信した暗号化されたセッション制御メッセージを復号化して上記メッセージ処理部に渡すと共に、上記メッセージ処理部から出力されたセッション制御メッセージを暗号化して上記ネットワークインタフェース部に出力するための第２セキュリティ部を有し、
前記接続先サーバとの通信データが前記第１セキュリティ部によって暗号化され、前記セッション管理サーバと通信メッセージが上記第２セキュリティ部によって暗号化されることを特徴とする請求項９に記載のクライアント端末。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９Ａ】
【図３９Ｂ】
【図４０】
【図４１Ａ】
【図４１Ｂ】
【図４１Ｃ】
【図４１Ｄ】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６Ａ】
【図４６Ｂ】
【図４７】
【図４８】
【図４９】
【図５０】
【図５１】
【図５２】
【図５３】
【図５４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９Ａ】
【図３９Ｂ】
【図４０】
【図４１Ａ】
【図４１Ｂ】
【図４１Ｃ】
【図４１Ｄ】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６Ａ】
【図４６Ｂ】
【図４７】
【図４８】
【図４９】
【図５０】
【図５１】
【図５２】
【図５３】
【図５４】
【公開番号】特開２００７−１６４３８７（Ｐ２００７−１６４３８７Ａ）
【公開日】平成１９年６月２８日（２００７．６．２８）
【国際特許分類】
【出願番号】特願２００５−３５８３９８（Ｐ２００５−３５８３９８）
【出願日】平成１７年１２月１３日（２００５．１２．１３）
【国等の委託研究の成果に係る記載事項】（出願人による申告）国等の委託研究の成果に係る特許出願（平成１７年度総務省「認証機能を具備するサービスプラットフォーム技術」委託研究、産業活力再生特別措置法第３０条の適用を受けるもの）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成１９年６月２８日（２００７．６．２８）
【国際特許分類】
【出願日】平成１７年１２月１３日（２００５．１２．１３）
【国等の委託研究の成果に係る記載事項】（出願人による申告）国等の委託研究の成果に係る特許出願（平成１７年度総務省「認証機能を具備するサービスプラットフォーム技術」委託研究、産業活力再生特別措置法第３０条の適用を受けるもの）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]