(57)【要約】アプリケーション・サーバ（１０６）からコンテンツおよび／またはサービスの要求があった場合に、第三者認証を行うための方法およびシステム（１００）。この方法は、チケットのコンセプトを使用する鍵管理プロトコルに適用することができる。この方法およびシステムは、第三者アプリケーション・サーバ（１０７）に結合しているクライアント（１０２）を含む。この場合、クライアントは第三者アプリケーション・サーバからコンテンツに対する要求を提出し、第三者アプリケーション・サーバは、要求された情報および対応する認証を返送する。クライアントは、さらに、第１のアプリケーション・サーバ（１０６）に結合している。この場合、クライアントは、第三者サーバ情報および対応する認証を含む鍵要求（ＫＥＹ＿ＲＥＱ）を第１のアプリケーション・サーバに提出する。第１のアプリケーション・サーバは、第三者サーバ情報の認証を行い、第三者情報に基づいてクライアントの許可を確認する。第１のアプリケーション・サーバは、第三者情報に基づいて、第三者サーバ情報の認証を行い、クライアントの許可を確認する。第１のアプリケーション・サーバは、第三者サーバ情報の認証が行われ、クライアントの許可が確認されると、鍵応答（ＫＥＹ＿ＲＥＰ）を返送する。【特許請求の範囲】
【請求項１】
通信許可方法であって、
アクセス情報に対する要求を受信してコンテンツにアクセスするステップと、
前記アクセス情報を生成して第１のアプリケーション・サーバから前記所望のコンテンツにアクセスするステップと、
第１のサービス・チケットにより前記アクセス情報の認証を生成するステップと、
クライアントに前記アクセス情報および認証を送信するステップとを備える方法。
【請求項２】
前記認証を生成するステップが、前記第１のサービス・チケットにより第三者サーバの署名を生成するステップを備え、前記第１のサービス・チケットは前記第１のアプリケーション・サーバへの第三者サーバ・サービス・チケットである、請求項１に記載の方法。
【請求項３】
前記アクセス情報を生成するステップがセッション権を生成するステップと、前記第１のアプリケーション・サーバに対する第三者サーバ・サービス鍵により前記セッション権の少なくとも一部を暗号化するステップとを備える、請求項１に記載の方法。
【請求項４】
前記第１のサービス・チケットにより前記認証の少なくとも一部を暗号化するステップをさらに備える、請求項１に記載の方法。
【請求項５】
チケット許可チケット（ＴＧＴチケット）を要求するステップと、
ＴＧＴチケットを受信するステップと、
前記第１のアプリケーション・サーバに対する前記第三者サーバ・サービス・チケットを要求するステップと、
前記第１のアプリケーション・サーバに対する前記第三者サーバ・サービス・チケットを受信するステップとをさらに備える、請求項４に記載の方法。
【請求項６】
前記アクセス情報および認証を含む鍵要求を受信するステップと、
前記アクセス情報および認証を抽出するステップと、
前記第１のサービス・チケットおよびクライアントの許可により前記アクセス情報の認証を確認するステップと、
前記アクセス情報およびクライアントの許可の認証が確認された場合、鍵応答を発行するステップとをさらに備える、請求項１に記載の方法。
【請求項７】
クライアントが、前記アクセス情報および前記認証を含む鍵要求を生成するステップと、
前記第１のアプリケーション・サーバに前記鍵要求を送信するステップと、
前記第１のアプリケーション・サーバにより、前記アクセス情報およびクライアントの許可の認証が確認された場合に、前記鍵応答（ＫＥＹ＿ＲＥＰ）を受信するステップとをさらに備える、請求項６に記載の方法。
【請求項８】
クライアントに対する許可を確認してコンテンツおよび／またはサービスにアクセスするための方法であって、
鍵要求を受信するステップと、
前記鍵要求から第三者サーバ・アクセス情報および第三者サーバ認証を抽出するステップと、
第三者アクセス情報およびクライアントの許可の認証を確認するステップと、
前記第三者アクセス情報および前記クライアントの許可の認証が確認された場合に、鍵応答を発行するステップとを備える方法。
【請求項９】
前記第三者サーバ認証により前記第三者サーバ・アクセス情報の認証を行うステップをさらに備える、請求項８に記載の方法。
【請求項１０】
認証を行う前記ステップが、前記認証から第１のサービス・チケットを抽出し、前記第１のサービス・チケットにより前記第三者サーバ・アクセス情報の認証を行うステップを備える、請求項９に記載の方法。
【請求項１１】
前記第三者サーバ認証を抽出する前記ステップが、前記鍵要求からセッション鍵を抽出するステップと、
前記セッション鍵により、第三者サーバの署名を確認するステップを含む前記アクセス情報の認証を行うステップとをさらに備える、請求項８に記載の方法。
【請求項１２】
前記セッション鍵を抽出する前記ステップが、アプリケーション・サーバ・サービス鍵により前記鍵要求の少なくとも一部を解読し、前記セッション鍵を抽出するステップを備える、請求項１１に記載の方法。
【請求項１３】
前記アクセス情報に対する要求を受信してコンテンツにアクセスするステップと、
前記第三者サーバ・アクセス情報を生成して前記第１のアプリケーション・サーバから前記所望のコンテンツにアクセスするステップと、
前記アクセス情報の前記第三者サーバ認証を生成するステップとをさらに備える、請求項８に記載の方法。
【請求項１４】
前記第三者サーバ認証を生成する前記ステップが、前記第１のアプリケーション・サーバに対する第三者サーバ・サービス・チケットを組み込むステップを備える、請求項１３に記載の方法。
【請求項１５】
前記認証を生成する前記ステップが、前記第三者サーバ・サービス・チケットのセッション鍵により署名を生成するステップを備える、請求項１４に記載の方法。
【請求項１６】
前記アクセス情報の認証を確認する前記ステップが、前記第三者サーバ・サービス・チケットを抽出し、前記第三者サーバ・サービス・チケットを確認するステップを備える、請求項１４に記載の方法。
【請求項１７】
サービスを配布する場合に、機密保護通信を提供するための方法であって、
サービスに対する選択を受信するステップと、
前記サービスに対してアクセス情報を発行するステップと、
前記アクセス情報の認証を発行するステップと、
鍵要求を受信するステップと、
第１のサービス・チケットの少なくとも一部により前記アクセス情報およびクライアントの許可の認証を確認するステップと、
前記アクセス情報および前記クライアントの許可の認証が確認された場合に、クライアントに鍵応答を発行するステップとを備える方法。
【請求項１８】
第三者サーバから第１のサーバに対する第１のサービス・チケット要求を受信するステップと、
前記第１のサーバに対して前記第三者サーバへの前記第１のサービス・チケットを発行するステップとをさらに含み、
アクセス情報および認証を発行する前記ステップが、前記第１のサービス・チケットにより前記アクセス情報および認証を生成するステップを備える、請求項１７に記載の方法。
【請求項１９】
前記第１のサーバに対する第２のサービス・チケット要求を受信するステップと、
前記第１のサーバに対して第２のサービス・チケットを発行するステップと、
鍵要求を受信するステップとをさらに含み、前記鍵要求が前記第２のサービス・チケットを備える、請求項１７に記載の方法。
【請求項２０】
前記アクセス情報の認証を確認する前記ステップが、
前記第１のサービス・チケットを抽出するステップと、
前記第１のサービス・チケットを解読するステップと、
前記第１のサービス・チケットからセッション鍵を抽出するステップと、
前記セッション鍵により署名を生成するステップと、
前記認証により前記署名を確認するステップとを備える、請求項１７に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はネットワーク・セキュリティ一般に関する。より詳細には、アプリケーション・サーバからのコンテンツおよび／またはサービスにアクセスするための許可の認証を提供するための方法およびシステムに関する。
【背景技術】
【０００２】
インターネットは機密保護が行われていないネットワークである。インターネット上で使用されているプロトコルの多くはセキュリティを全く提供しない。暗号化または任意の他のタイプのセキュリティ方法を使用しないでインターネット上で送信されるデータは「平文で」送信されていると言える。平文でインターネットを通して送信されるパスワード、クレジット・カード番号、クライアント識別および名前等のようなデータをハッカーが「嗅ぎつける」ことができるツールは容易に入手可能である。それ故、インターネットを通して暗号化していないデータを送信するアプリケーションは非常に無防備なものである。
【０００３】
ケルベロス（Kerberos）は、秘密鍵暗号化を使用することにより、クライアント／サーバ・アプリケーションに対して認証を行うように設計されている周知のネットワーク認証プロトコルの一例である。マサチューセッツ工科大学から入手可能なケルベロスプロトコルは、クライアントが機密保護が行われていないネットワーク接続を通してサーバに（また逆にクライアントに）意図的にその識別を証明することができるように暗号化を使用している。クライアントおよびサーバが、自分の識別を証明するためにケルベロスを使用した後で、クライアントおよびサーバは、また、自分のビジネスを行う場合、意図的に確実にプライバシーおよびデータ保全性を保護するために、自分の通信のすべてを暗号化する。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
本発明は、ネットワーク・セキュリティの分野に関連するこれらおよび他の背景情報要素に対するものである。
【課題を解決するための手段】
【０００５】
本発明は、アプリケーション・サーバからコンテンツおよび／またはサービスを要求する場合に、第三者認証を提供する方法および装置を提供する。
上記方法は、クライアントを許可するために使用することができる第三者サーバから、認証が行われたアクセス情報を要求するステップと、第三者サーバからアクセス情報を受信するステップと、第三者サーバから認証を受信するステップと、第三者サーバから受信したアクセス情報を含む鍵要求を生成し、チケットを使用して認証を添付するステップと、アプリケーション・サーバに鍵要求（ＫＥＹ＿ＲＥＱ）を転送するステップと、チケットにより第三者サーバ情報の認証が行われ、クライアントの許可がアプリケーション・サーバにより確認された場合に、鍵応答（ＫＥＹ＿ＲＥＰ）を受信するステップとを備える。
【０００６】
他の実施形態の場合には、本発明は、第三者アプリケーション・サーバの認証を行うための方法を提供する。この方法は、クライアントが第三者サーバに要求を提出するステップと、第三者サーバが要求された情報を生成するステップと、第三者サーバが認証を生成するステップと、第三者サーバがクライアントに要求された情報および認証を転送するステップと、クライアントがアプリケーション・サーバに、要求された情報および認証を含
む鍵要求を提出するステップと、第１のアプリケーション・サーバがチケットにより第三者サーバ情報の認証を確認し、クライアントの許可を確認するステップと、第三者サーバ情報がチケットにより認証され、クライアントの許可が確認された場合に、アプリケーション・サーバがクライアントに鍵応答を返送するステップとを備える。
【０００７】
さらなる実施形態では、本発明は、クライアントにコンテンツへのアクセスを許可する際に、アプリケーション・サーバが使用した情報に対するクライアントからの要求を受信するステップと、クライアントが使用する情報を生成して第１のアプリケーション・サーバからの所望のコンテンツにアクセスするステップと、クライアントに対して要求した情報の認証を生成して第１のアプリケーション・サーバからのコンテンツにアクセスするステップと、クライアントに要求した情報および認証を転送するステップとを備えた方法を提供する。
【０００８】
さらなる実施形態では、本発明は、クライアントから鍵要求を受信するステップと、第三者サーバ情報を抽出するステップと、第三者サーバ認証を抽出するステップと、第三者情報を確認するステップと、第三者認証を確認するステップと、チケットにより第三者サーバ情報の認証が行われ、クライアントの許可が確認された場合に、鍵応答を発行するステップとを備える方法を提供する。
【０００９】
さらなる実施形態では、本発明は、クライアントからのコンテンツに対する要求を受信するステップと、クライアントに対して要求された情報を生成してコンテンツにアクセスするステップと、クライアントに対する情報の認証を生成してコンテンツにアクセスするステップと、クライアントに要求した情報および認証を送信するステップと、クライアントから要求した情報および認証を含むコンテンツに対する鍵要求を受信するステップと、チケットにより要求された情報の認証を確認し、クライアントの許可を確認するステップと、クライアントに鍵応答を送信するステップとを備える方法を提供する。
【００１０】
さらなる実施形態では、本発明は、サービスに対する選択を受信するステップと、サービスに対するアクセス情報を発行するステップと、アクセス情報の認証を発行するステップと、鍵要求を受信するステップと、アクセス情報の認証を確認するステップと、クライアントの許可を確認するステップと、アクセス情報およびクライアントの許可が確認された場合に、鍵応答を発行するステップとを備える方法を提供する。
【００１１】
さらなる実施形態では、本発明は、第１のアプリケーション・サーバからのコンテンツおよび／またはサービスにアクセスするために、許可の第三者サーバの認証を提供するコンピュータ・プログラム製品として特徴付けることができる。コンピュータ・プログラム製品は、コンピュータへの入力に対してコンピュータ・プログラムを実施するための媒体と、コンピュータに下記の機能、すなわち、クライアントから第三者サーバへの要求の提出と、第三者サーバのアクセス情報の生成と、第三者サーバの認証の生成と、第三者サーバのクライアントへのアクセス情報および認証の転送と、クライアントのアプリケーション・サーバへのアクセス情報および認証を含む鍵要求の提出と、第１のアプリケーション・サーバによる、アクセス情報の認証およびクライアントの許可の確認と、アクセス情報およびクライアントの許可が確認された場合の、アプリケーション・サーバによるクライアントへの鍵応答の返送とを実行させるために媒体内で実施したコンピュータ・プログラムとを備える。
【００１２】
さらなる実施形態では、本発明は、アクセス情報の第三者サーバの認証を提供するシステムとして特徴付けることができる。このシステムは、第三者アプリケーション・サーバに結合しているクライアントを含む。この場合、上記クライアントは、第三者アプリケーション・サーバからコンテンツに対して要求を提出し、上記第三者アプリケーション・サ
ーバは、クライアントにアクセス情報および認証を返送する。上記クライアントは、さらに、第１のアプリケーション・サーバに結合している。この場合、クライアントは、第１のアプリケーション・サーバにアクセス情報および認証を含む鍵要求を提出し、第１のアプリケーション・サーバは、アクセス情報およびクライアントを確認し、第１のアプリケーション・サーバは、アクセス情報およびクライアントが確認された場合、鍵応答を返送する。
【００１３】
さらなる実施形態では、メッセージ交換に関連しない第三者サーバからのメッセージ交換の認証を提供するための装置として特徴付けることができる。このシステムは、第１のサーバに結合しているクライアントを含む。この場合、クライアントは、第１のサーバとメッセージ交換を行うように構成されている。上記クライアントは、メッセージ交換のためにクライアントにアクセス情報を発行し、アクセス情報の認証を提供するように構成されている第三者サーバに結合している。またクライアントは、さらに、メッセージ交換中に、第１のサーバにアクセス情報および認証を提出するように構成されている。
【００１４】
本発明の以下の詳細な説明を読み、また本発明の原理を使用している例示としての実施形態を示す添付の図面を見れば、本発明の特徴および利点をよりよく理解することができるだろう。
【００１５】
下記の図面を含む本発明の下記のより詳細な説明を読めば、本発明の上記および他の態様、特徴および利点をよりよく理解することができるだろう。
【発明を実施するための最良の形態】
【００１６】
ケルベロスを含む従来の認証プロトコルは、分散型ネットワークを通して提供される第三者情報、データ、媒体、アプリケーション、プロセス、サービス、プログラムおよび他のこのようなコンテンツおよび／またはサービスへの閲覧、受信、ダウンロード、実施および他のこのようなアクセスを含むアクセスおよび使用のための許可権を確保するための機構を提供しない。例えば、クライアントまたは閲覧者が、例えば、デジタル的に記憶している映画のような第三者のコンテンツにアクセスしたい場合には、クライアントは、購入オプションを選択し、第三者から対応する認証符号およびおそらく追加コンテンツ規則を入手する。次に、クライアントは、キャッシング・サーバから配信されるコンテンツ（すなわち、デジタル的に記憶している映画）を要求する。
【００１７】
本発明は、クライアントに、キャッシング・サーバのような他のネットワーク・エンティティが配布する第三者のコンテンツまたはサービスへのアクセスを許可する前に、第三者アクセス情報の認証を使用する方法、プロセス、システム、装置、コンピュータ・プログラム、およびコンピュータ・プログラム製品を提供する。
【００１８】
本発明は、チケットのコンセプトを使用する鍵管理プロトコルによく適している。チケットは、鍵配布センター（ＫＤＣ）がクライアントに与える確認トークンである。通常、チケットは、少なくともクライアントの名前、特定のサーバの名称、およびセッション鍵（対称暗号鍵）を含む。セッション鍵および一実施形態の場合にはクライアント名は、秘密にされ、サービス鍵と呼ばれるもう１つの鍵で暗号化される。サービス鍵は、ＫＤＣおよびチケットに記載されている特定のサーバだけが知っている秘密鍵である。クライアントもこのサービス鍵を持っていないので、クライアントはチケットを解読したり、その内容を変更することはできない。通常、クライアントもセッション鍵を知る必要があり、クライアントはチケットからセッション鍵を入手することができないので、ＫＤＣはこのクライアントに同じセッション鍵のコピーを送る。
【００１９】
チケット（例えば、以下にさらに詳細に説明する鍵要求メッセージ）によりメッセージ
を確認するために、クライアントは、このメッセージ内にチケットとセッション鍵で鍵がかけられるチェックサムの両方を含む。チケットに記載されているサーバが、クライアントからこのメッセージを受信した場合には、サーバは、そのサービス鍵でチケットを解読し、クライアント名を確認し、セッション鍵を入手することができる。次に、鍵をかけられたチェックサムを確認し、それ故全メッセージを確認するためにセッション鍵が使用される。
【００２０】
今説明した確認に類似しているチケットをベースとする確認は、ケルベロスＩＥＴＦ規格（ＲＦＣ１５１０）が定義しているケルベロスを含む従来のプロトコルで使用される。一実施形態の場合には、本発明は、さらに、このチケットをベースとする確認を使用する、モトローラ社が開発したＥＳＢｒｏｋｅｒプロトコルで実施される。チケットは、有効期間（開始時間および終了時間）、種々のフラグ、クライアントの許可データ等を含む他の情報も有することができる。しかし、ケルベロスのような従来のプロトコルは、コンテンツおよび／またはサービスにアクセスするために、クライアントの許可を確認する際に使用する第三者サーバ・アクセス情報の認証を行うための機構を提供しない。
【００２１】
本発明のある実施形態によれば、コンテンツ・プロバイダなどの第三者アプリケーション・サーバは、例えば、１つ以上のキャッシング・サーバなどの１つ以上の別のアプリケーション・サーバを通して、クライアントおよびネットワークの他のエンティティにサービスを提供する。それ故、クライアントは、別のアプリケーション・サーバの中の１つにアクセスすることにより、第三者アプリケーション・サーバが提供するサービスおよび／またはコンテンツにアクセスする。それ故、第三者サーバは、実際には、別のアプリケーション・サーバを通して、サービスまたはコンテンツにアクセスするクライアント間の相互作用に対する第三者である。別のサーバを通してコンテンツおよび／またはサービスにアクセスするために、第三者サーバは、クライアントに、選択した購入オプション、支払い情報および第三者が提供するコンテンツおよび／またはサービスに関連する追加情報のようなアクセス情報を提供する。
【００２２】
第三者サーバは、さらに、クライアントに認証を供給する。別のアプリケーション・サーバは、クライアントが別のアプリケーション・サーバを通してコンテンツおよび／またはサービスを入手しようとすると、第三者サーバからのアクセス情報を確認するために認証を使用する。そのため、第三者と別のサーバとの間に追加インタフェースを使用する必要はない。さらに、クライアントがコンテンツおよび／またはサービスにアクセスしようとした場合に、クライアントを通して別のアプリケーション・サーバに第三者からの追加情報を供給すれば、別のサーバは、追加情報をコンパイルし、それをクライアントの要求と突き合わせる必要がない。
【００２３】
本発明は、標準ケルベロスなど従来のプロトコルの場合には使用できなかった新しい機能を追加する。この場合、標準ケルベロスは、クライアントから別のアプリケーション・サーバなどの別のネットワーク構成要素へ第三者サーバ情報および関連する認証を送るための機構を提供しない。さらに、本発明は、ネットワーク通信のトラヒックを低減し、追加情報をクライアントを通して別のサーバに転送できるようにすることによりインタフェースとしても機能する。
【００２４】
一実施形態の場合には、本発明は、さらに、これら第三者サーバへのサービス・チケットを入手しなくても、クライアントが１つ以上の第三者サーバにアクセスできるようにする。クライアントと第三者サーバとの間で独占的または秘密の情報の伝達が行われず、第三者サーバが自分自身クライアントがコンテンツを受信するのを許可しないので、クライアントはサービス・チケットを必要としない。クライアントは、別のネットワーク構成要素にアクセスするために、別のアプリケーション・サーバに対するサービス・チケットを
使用する。一実施形態の場合には、実際のクライアントの許可は、クライアントを通して受信する認証を行った第三者サーバ情報に基づいて、別のネットワーク構成要素が行う。
【００２５】
図１は、本発明のある実施形態により実施したシステム１００の概略ブロック図である。このシステム１００は、インターネット、イントラネットおよび他のタイプのネットワークなどのネットワーク上でセキュリティおよびプライバシー保護を提供し、例えば、数百万のユーザに対して規模を拡大することができる認証鍵管理プロトコルを使用する。一般的に、システム１００は、公開鍵アルゴリズムおよび対称鍵アルゴリズムの両方を使用する１つ以上の集中鍵配布センター（ＫＤＣ）１０４により、ならびに第１および第２のアプリケーション・サーバ１０６および１０７のような個々のアプリケーション・サーバにより相互に作用する１つ以上のクライアント１０２を有する。このプロトコルは一般的なプロトコルで、分散型環境で認証を使用するいくつかのアプリケーションに容易に適合させることができる。さらに、システム１００は、１つ以上の集中管理ユーザ・データベースに対してインタフェースとして機能することができる。図面を簡単にするために、図１の実施形態は、１つのクライアント１０２と２つのアプリケーション・サーバ１０６、１０７しか含んでいない。しかし、当業者であれば、ネットワーク１００は、本発明の新規性から逸脱することなく、多数のクライアント、アプリケーション・サーバ、および他のネットワーク構成要素を有していてもよいことを理解することができるだろう。
【００２６】
クライアント１０２は、ユーザの代わりにネットワーク・サービスを使用するプロセスまたはデバイスを備えることができる。一例を挙げて説明すると、クライアント１０２は、任意のタイプのサーバ、コンピュータ、マイクロプロセッサ、プロセスおよびプログラムを備えることができる。一実施形態の場合には、クライアント１０２は、無線電話、ポケットベル（ｐａｇｅｒ）、携帯情報端末（ＰＤＡ）、ローエンド・マイクロプロセッサまたは限定された処理機能を有する他のデバイスを有する家庭用品のような「小型軽量クライアント（ｔｈｉｎ  ｃｌｉｅｎｔ）」を備えることができる。場合によっては、サーバ自身が、ある他のサーバのクライアントになることができる（例えば、印刷サーバは、ファイル・サーバのクライアントになることができる）ことに留意されたい。アプリケーション・サーバ１０６、１０７は、ネットワーク・クライアントにリソースを提供する。一実施形態の場合には、第２のアプリケーション・サーバ１０７は、第１のアプリケーション・サーバ１０６を通して、クライアント１０２にサービスおよび／またはコンテンツを提供する。第２のアプリケーション・サーバ１０７は、クライアントが、サービスおよび／またはコンテンツにアクセスするのを許可するために使用したアクセス情報を提供する。クライアント１０２は、許可を入手し、第１のアプリケーション・サーバ１０６にサービスおよび／またはコンテンツの配信をスタートさせるために、この第三者サーバ情報を使用する。それ故、第２のアプリケーション・サーバ１０７は、サービスおよび／またはコンテンツにアクセスするために、第１のアプリケーション・サーバ１０６とのクライアントの相互作用に対して第三者である。
【００２７】
一実施形態の場合には、ＫＤＣ１０４は、クライアント１０２および第三者サーバ１０７にアプリケーション・サーバ・サービス・チケット（ＳＴチケット）を供給する。ＳＴチケットは、クライアント１０２および／または第三者アプリケーション・サーバがサービスを要求した場合に、クライアント１０２および第三者アプリケーション・サーバ１０７が、第１のアプリケーション・サーバ１０６に呈示するエンド・サービス・チケットである。第１のアプリケーション・サーバ１０６は、クライアント１０２が、ＳＴチケットおよび第２のアプリケーション・サーバ１０７がクライアントに供給した第三者認証（ＴＰＡｕｔｈ）により自分自身の認証を行う場合に、第三者アプリケーション・サーバ１０７からクライアント１０２への関連するアクセス情報により許可した種々のサービスおよび／またはコンテンツを提供する。
【００２８】
ＴＰＡｕｔｈおよびサービスおよび／またはコンテンツをクライアント１０２に提供するためのシステム１００の一実施形態が使用する基本メッセージ・タイプのいくつかの例を以下に示す。
【００２９】
（Ａ）認証サーバ要求メッセージ（ＡＳ＿ＲＥＱ）：ＫＤＣ１０４からチケット許可チケット（ＴＧＴ）チケットを要求するためのクライアント１０２（または第三者アプリケーション・サーバ１０７）からのメッセージ。
【００３０】
（Ｂ）認証サーバ応答メッセージ（ＡＳ＿ＲＥＰ）：ＴＧＴチケットによるＫＤＣ１０４からクライアント１０２（または第三者アプリケーション・サーバ１０７）への応答メッセージ。
【００３１】
（Ｃ）チケット許可サーバ要求メッセージ（ＴＧＳ＿ＲＥＱ）：ＫＤＣ１０４からＳＴチケットを要求するためのクライアント１０２（または第三者アプリケーション・サーバ１０７）からのメッセージ。
【００３２】
（Ｄ）チケット許可サーバ応答メッセージ（ＴＧＳ＿ＲＥＰ）：ＳＴチケットによるＫＤＣ１０４からクライアント１０２（または第三者アプリケーション・サーバ１０７）への応答メッセージ。
【００３３】
（Ｅ）コンテンツ選択（ＣＯＮ＿ＳＥＬ）：サービスおよび／またはコンテンツを選択するために、クライアントから第三者アプリケーション・サーバ１０７に送信したメッセージ。サービスおよび／またはコンテンツは、第１のアプリケーション・サーバ１０６を通してクライアント１０２に供給される。一実施形態の場合には、ＣＯＮ＿ＳＥＬは、選択したこれらサービスまたはコンテンツに対する支払い形式を指定するために、クライアントが使用する支払いオプションを含む。ＣＯＮ＿ＳＥＬメッセージは、通常、認証を必要としないし、特定のプロトコル（例えば、ＥＳＢｒｏｋｅｒまたはケルベロス）鍵管理メッセージではない。本発明は、このメッセージの特定のフォーマットに依存しない。例えば、ＣＯＮ＿ＳＥＬメッセージは、標準ＨＴＴＰにより実施することができる。
【００３４】
（Ｆ）セッション権および第三者許可（ＴＰＡｕｔｈ）：クライアント１０２が第１のアプリケーション・サーバ１０６を通して提供されたサービスおよび／またはコンテンツにアクセスすることができるように、許可および許可の認証を提供する第三者サーバ１０７からクライアント１０２へ送信したメッセージ。
ＴＰＡｕｔｈメッセージは、特定のプロトコル（例えば、ＥＳＢｒｏｋｅｒまたはケルベロス）鍵管理メッセージではない。本発明は、このメッセージの特定のフォーマットに依存しない。しかし、このメッセージは、通常、要求した第三者情報および関連するチケットをベースとする認証符号を含む。例えば、このメッセージは、標準ＨＴＴＰにより実施することができる。
【００３５】
（Ｇ）鍵要求メッセージ（ＫＥＹ＿ＲＥＱ）：セキュリティ（鍵管理）パラメータを要求するために、クライアント１０２から第１のアプリケーション・サーバ１０６に送信したメッセージ。
【００３６】
（Ｈ）鍵応答メッセージ（ＫＥＹ＿ＲＥＰ）：副鍵およびアプリケーション特定データを含む、第１のアプリケーション・サーバ１０６からクライアント１０２への応答メッセージ。
【００３７】
一実施形態の場合には、各メッセージは、通常、ヘッダとその後に続くメッセージ本体を含む。一例を挙げて説明すると、ヘッダは、メッセージ・タイプ・フィールド、プロト
コル・バージョン番号フィールド、およびチェックサムを含むことができる。メッセージ・タイプ・フィールドは、ＡＳ＿ＲＥＱ、ＡＳ＿ＲＥＰ等のようなメッセージのタイプを示す。メッセージ・ヘッダの後には属性のリストを有するメッセージの本体が位置する。一実施形態の場合には、属性はタイプ−長さ−値（ＴＬＶ）フォーマット内に含まれている。
【００３８】
ある例の場合には、クライアント１０２および第三者サーバ１０７は、自分たちがＴＧＴチケットを入手したい場合には、クライアント１０２とＫＤＣ１０４との間で、また第三者アプリケーション・サーバ１０７とＫＤＣ１０４との間で、認証サービス交換をスタートするためにＡＳ＿ＲＥＱメッセージを生成する。ＴＧＴチケットは、第１のアプリケーション・サーバ１０６（または、図示していない他のサーバ）に対して、ＫＤＣ１０４からＳＴチケットの生成をスタートするためのチケットである。すなわち、ＡＳ＿ＲＥＱメッセージは、第１のアプリケーション・サーバ１０６のような特定のアプリケーション・サーバに対するＳＴチケットを要求するために、クライアントおよび第三者アプリケーション・サーバが使用するＴＧＴチケットを入手する目的で、クライアント１０２および第三者アプリケーション・サーバ１０７によりＫＤＣ１０４に送信される。
【００３９】
一例を挙げて説明すると、ＡＳ＿ＲＥＱメッセージは、クライアントの識別（例えば、名前）（または第三者サーバの識別）、ＫＤＣの識別、および要求を応答に結びつける臨時の値を含むことができる。ＡＳ＿ＲＥＱは、また、クライアント１０２がサポートする対称暗号化アルゴリズムのリストを含むことができる。再生をチェックするために、このメッセージは、また、タイムスタンプおよびメッセージの保全性のための署名を含むことができる。署名は、鍵をかけたチェックサムまたはデジタル署名であってもよい。
【００４０】
署名を確認するための公開鍵は、好適には、ユーザのデータベース内に保管することが好ましい。デジタル証明書は、そうしたい場合には、ＡＳ＿ＲＥＱメッセージに内蔵させることができ、デジタル署名を確認するために、記憶している公開鍵の代わりに使用することができる。鍵をかけたチェックサムを確認するためのクライアント１０２の永久対称鍵は、好適には、同じユーザ・データベース内に保管することが好ましい。ＡＳ＿ＲＥＱメッセージは、また、鍵同意（例えば、楕円曲線ディフィ−ヘルマンパラメータ）のために使用される公開鍵情報を含むことができる。一例を挙げて説明すると、楕円曲線は、その処理速度が速いので、公開鍵の暗号化のために使用することができる。楕円曲線暗号化としては、ＲＳＡのような他の暗号化技術よりも１桁または２桁速いものを使用することができる。ラインダール(Rijndael)暗号化規格は、１２８ビット鍵長と一緒に使用することができる。
【００４１】
ＫＤＣ１０４は、それを確認するためにＡＳ＿ＲＥＱメッセージを処理する。ＡＳ＿ＲＥＱ処理がエラーを起こさない場合には、ＫＤＣ１０４は、ＡＳ＿ＲＥＱメッセージに応じてＡＳ＿ＲＥＰメッセージを生成する。より詳細に説明すると、ＫＤＣ１０４は、データベース内のＫＤＣの鍵およびクライアント１０２の鍵を参照して、ＫＤＣ１０４による以降の認証のために、ランダム・セッション鍵を生成する。ＫＤＣ１０４は、平文の部分および暗号化された部分を含むことができるＴＧＴチケットを生成する。例えば、ＫＤＣ１０４の識別およびチケットの有効期間は、発行したＴＧＴチケット内に平文で表示することができる。チケットの暗号化された部分は、クライアント１０２（または第三者サーバ１０７）の名前、セッション鍵、およびプライベートにしておくべき任意の他のデータを含む。チケットは、また好適には、ＫＤＣ１０４がサポートする暗号化タイプおよびチェックサム・タイプのリストを提供することが好ましい。チケットの暗号化された部分は、ＫＤＣ１０４の秘密鍵により暗号化することができる。
【００４２】
ＡＳ＿ＲＥＰメッセージは、好適には、ＡＳ＿ＲＥＱメッセージに対する署名を生成す
るために、クライアント１０２（または第三者サーバ１０７）が使用するのと同じアルゴリズムによりＫＤＣ１０４が署名することが好ましい。この署名は、クライアント１０２の秘密鍵を使用するデジタル署名であってもよいし、鍵をかけたチェックサムであってもよい。公開鍵情報は、ＫＤＣ１０４の鍵同意パラメータの公開部分であり、クライアント１０２が選択したものと同じ鍵同意アルゴリズムを指すものでなければならない。最後に、ＡＳ＿ＲＥＰメッセージは、好適には、再生を防止するために、ＡＳ＿ＲＥＱメッセージからコピーした臨時の値を含むことが好ましい。
【００４３】
ＡＳ＿ＲＥＰメッセージの暗号化された部分は、通常、ＴＧＴチケット内のものと同じ情報を含んでいるため、クライアント１０２（または第三者サーバ１０７）は、（ＴＧＴに含まれている場合には）それ自身の許可データに読出し専用アクセスをするが、これは本発明の要件ではない。このオプションとしての機能は、ユーザにとって便利なものである。何故なら、クライアント１０２が自分自身の許可データを知っている場合には、いずれにせよアプリケーション・サーバが後で拒否するであろう行動をしようとしないからである。何故なら、アプリケーション・サーバは、チケット内部で暗号化されるクライアント情報のコピーだけを信用するからである。また、ユーザをそれ自身の許可データのハッカー行為および変更から防止するハードウェア・セキュリティを有しているクライアントの場合には、このオプションとしての機能はセキュリティの利点を有することができる。何故なら、読み出すことができる許可データは、また、例えば、ローカル・ディスク上で映画をセーブし、再生する権利のようなある種のローカル的行動をクライアントに許可することができるからである。一実施形態の場合には、ＡＳ＿ＲＥＰメッセージの暗号化部分は、好適にはまた、この応答がこの特定のクライアント１０２に対してＫＤＣ１０４が元来構成したものであることを確認するために、クライアント１０２の識別を含んでいることが好ましい。このデータは、好適には、鍵同意アルゴリズムから入手した対称鍵で暗号化することが好ましい。
【００４４】
クライアント１０２（または第三者サーバ１０７）は、それが本物であることを確認し、ＴＧＴチケットを入手する目的でメッセージ内のプライベートなチケット部分を解読するために、ＡＳ＿ＲＥＰメッセージを処理する。ＡＳ＿ＲＥＰメッセージが本物であることを確認できない場合には、クライアント１０２は、好適には、エラー・メッセージをＫＤＣ１０４に返送しないことが好ましい。場合によっては、クライアントは他のＡＳ＿ＲＥＱメッセージで再試行することができる。
【００４５】
本発明は適切な場合には、クライアント１０２（または第三者サーバ１０７）およびＫＤＣ１０４が、デジタル証明書で相互に認証を行うことができるようにするために、ＡＳ＿ＲＥＱおよびＡＳ＿ＲＥＰメッセージの両方のデジタル証明書を通過させることができる。証明書がない場合には、クライアント１０２がＫＤＣ公開鍵をすでに入手していて、ＫＤＣ１０４がすでにそのデータベース内のクライアント１０２（または第三者サーバ）の公開鍵を入手している場合が考えられる。ＡＳ＿ＲＥＱ上のデジタル署名は、そのデータベース内で探しだすクライアントの公開鍵により、ＫＤＣ１０４が確認する。クライアント１０２は、予め供給されたＫＤＣ公開鍵で、ＡＳ＿ＲＥＰ上のデジタル署名を確認する。
【００４６】
クライアント１０２（または第三者サーバ１０７）が、ＫＤＣ１０４交換によりＴＧＴチケットを入手した後で、クライアント１０２（または第三者サーバ１０７）が、第１のアプリケーション・サーバ１０６のような所与のまたは特定のアプリケーション・サーバに対する認証信用状を入手したい場合には、クライアント１０２は、クライアント１０２とＫＤＣ１０４との間でＴＧＳ＿ＲＥＱメッセージの交換をスタートする。ＴＧＳ＿ＲＥＱメッセージは、ＫＥＹ＿ＲＥＱメッセージで使用することができるアプリケーション・サーバ・サービス・チケット（ＳＴチケット）を入手するために、クライアント１０２に
より生成され、ＫＤＣ１０４に送信される。クライアント１０２は、ＴＧＳ＿ＲＥＱメッセージの一部として、ＡＳ＿ＲＥＰメッセージから入手したＴＧＴチケットを呈示する。ＴＧＳ＿ＲＥＱメッセージは、第１のアプリケーション・サーバ１０６の識別およびクライアント１０２の識別（ＴＧＴチケットに含まれている）を指定する。一実施形態の場合には、クライアント１０２の識別は保護される。何故なら、この識別はＴＧＴチケットの暗号化された部分にあり、メッセージの平文の部分には含まれていないからである。ＴＧＴチケットからのセッション鍵は、ＴＧＳ＿ＲＥＱ交換中に暗号化および解読のために使用することができる。それ故、スヌーパ（ｓｎｏｏｐｅｒ）は、クライアント（すなわち、ユーザ）がどのサービスを要求しているのかを検出することはできない。
【００４７】
クライアント１０２がＴＧＳ＿ＲＥＱメッセージを送信した後で、クライアント１０２は、好適には、後でＫＤＣ１０４からの一致するＴＧＳ＿ＲＥＰメッセージを確認するために、ＴＧＳ＿ＲＥＱ内に含まれている臨時の値をセーブすることが好ましい。クライアント１０２は、好適には、構成可能な時間切れの値が時間切れになるまで、臨時の値を維持することが好ましい。時間切れになった後で、クライアント１０２は、もはや対応するＴＧＳ＿ＲＥＰを処理することができないので、再試行しなければならない。
【００４８】
ＫＤＣ１０４は、ＴＧＳ＿ＲＥＱメッセージを確認し、ＴＧＴチケットを処理する。次に、ＫＤＣ１０４は、ＴＧＳ＿ＲＥＱメッセージへの応答でＴＧＳ＿ＲＥＰメッセージを生成する。ＴＧＳ＿ＲＥＰメッセージは、サービスおよび／またはコンテンツを要求したい場合に、クライアント１０２（または第三者サーバ１０７）が、アプリケーション・サーバ１０６に呈示する、ＫＤＣ１０４が発行したＳＴチケット（エンド・サービス・チケットである）を含む。アプリケーション・サーバ１０６の識別、チケットの有効期間は、発行したＳＴチケットの内部に平文で表示することができる。ＳＴチケットの暗号化された部分は、アプリケーション・サーバ１０６およびＫＤＣ１０４が共有する鍵により暗号化されたクライアント１０２の名前およびセッション鍵を含むことができる。プライベートな状態で維持しなければならない任意の追加のクライアント・データは、ＳＴチケットの暗号化された部分の一部として含むことができる。ＳＴチケット内のクライアント・データは、ＴＧＴの場合のようにクライアントの許可データを含むことができる。ＴＧＳ＿ＲＥＰメッセージの暗号化された部分は、好適には、クライアント１０２（または第三者サーバ１０７）が、それ自身の許可データに読出し専用アクセスをするように、ＳＴチケット内のものと同じ情報を含んでいることが好ましいが、これは本発明の要件ではない。クライアントによるＳＴチケット内のそれ自身の許可データへの読出し専用アクセスは、クライアントによるＴＧＴ内のそれ自身の許可データへのアクセスと同じ利点を有する。ＴＧＳ＿ＲＥＰメッセージは、ＴＧＴチケット・セッション鍵を使用して、鍵をかけたチェックサムによりＫＤＣ１０４が署名する。最後に、ＴＧＳ＿ＲＥＰメッセージは、再生を防止するために、ＴＧＳ＿ＲＥＱメッセージからコピーした臨時の値を含む。
【００４９】
一例を挙げて説明すると、ＫＤＣ１０４は、下記手順によりＴＧＳ＿ＲＥＰメッセージを生成することができる。最初に、ＴＧＳ＿ＲＥＱメッセージからの臨時の値が、それを要求に結びつけるＴＧＳ＿ＲＥＰメッセージに内蔵される。次に、ＫＤＣ１０４が、ランダム（サービス・チケット）セッション鍵のタイプを割り当てる。２つ以上の暗号化アルゴリズムを使用することができる場合には、ＫＤＣ１０４は、好適には、最も強力なものを選択することが好ましい。次に、ＫＤＣ１０４はＳＴチケットを生成する。アプリケーション・サーバ１０６の秘密鍵は、暗号化されたチケット部分を暗号化するため、また全ＳＴチケット上で鍵をかけたチェックサムを生成するために使用される。ＳＴチケットの期限切れ時間は、好適には、ＫＤＣ１０４が決定することが好ましい。クライアント１０２は、そうしたい場合には、もっと短い有効期間を指定することができる。ＳＴチケットの暗号化された部分は、クライアント１０２の識別、セッション鍵および他のプライベート・データを含む。ＴＧＴチケットのセッション鍵は、ＴＧＳ＿ＲＥＰメッセージの暗号
化されたデータ部分を生成するために使用され、鍵をかけたチェックサム（ＴＧＴセッション鍵を使用する）は、ＴＧＳ＿ＲＥＰメッセージ上に追加される。この場合も、これはＴＧＳ＿ＲＥＰメッセージを生成するためにＫＤＣ１０４が使用することができる手順の一例に過ぎない。
【００５０】
例えば、クライアント１０２が第１のアプリケーション・サーバ１０６に対するＳＴチケットをまだ受信していない場合のように、クライアントがサーバに対するＳＴチケットをまだ受信していない場合、ＴＧＳ＿ＲＥＱおよびＴＧＳ＿ＲＥＰメッセージは、クライアント１０２（または第三者サーバ１０７）により送信され、受信される。さらに、クライアントが期限切れのＳＴチケットを有している場合には、クライアント１０２はＴＧＳ＿ＲＥＱを発行することができる。そうでない場合には、ＳＴチケットを入手するためのステップは必要ない。
【００５１】
クライアント１０２が第三者アプリケーション・サーバ１０７が生成し、第１のアプリケーション・サーバ１０６が配布した関連情報を含むサービスおよび／またはコンテンツにアクセスしたい場合には、クライアント１０２は所望のサービスおよび／またはコンテンツを決定する。例えば、第三者サーバ１０７が、ペイ・パー・ビュー映画を供給するコンテンツ・プロバイダである場合には、クライアント１０２は、第三者サーバ１０７が供給する潜在的な映画の閲覧をスタートする。所望のサービスおよび／またはコンテンツが決定された場合には、クライアントは、第１のアプリケーション・サーバ１０６がクライアントの許可の認証のために後で使用する所望のサービスおよび／またはコンテンツに対応するアクセス情報を入手するために、クライアント１０２と第三者サーバ１０７との間のＣＯＮ＿ＳＥＬメッセージ交換を生成する。ＣＯＮ＿ＳＥＬメッセージはクライアント１０２により生成され、ＫＥＹ＿ＲＥＱメッセージ内で使用されるアクセス情報、セッション権およびＴＰＡｕｔｈを入手するために、第三者サーバ１０７に送られる。
【００５２】
一実施形態の場合には、クライアント１０２は、またそうしたい場合には、第三者サーバとの、または許可プロセスの際に後で使用する情報そのものの代わりに、サービスおよび／またはコンテンツのための完全なクライアントの許可を入手する目的で、プライベート暗号化セッションを確立するために、第三者アプリケーション・サーバ１０６へのＳＴチケットも入手する。
【００５３】
クライアント１０２は、所望のサービスおよび／またはコンテンツに対する要求をＣＯＮ＿ＳＥＬメッセージの一部として呈示する。ＣＯＮ＿ＳＥＬメッセージは、第三者アプリケーション・サーバ１０７の識別およびクライアント１０２の識別を指定する。一実施形態の場合には、クライアント１０２の識別が保護される。何故なら、この識別は、ＣＯＮ＿ＳＥＬメッセージの暗号化された部分に含まれていて、メッセージの平文部分に含まれていないからである。ＣＯＮ＿ＳＥＬは、さらに、返送されたセッション権の確認のためのクライアント・セッション識別（セッションＩＤ）を含む。通常、セッションＩＤは、クライアント１０２が生成する乱数である。一実施形態の場合には、ＣＯＮ＿ＳＥＬは、本発明のＫＥＹ＿ＲＥＱ／ＫＥＹ＿ＲＥＰ交換（以下にさらに詳細に説明する）により、クライアントと第三者サーバとの間で以前に確立されたリンク鍵により暗号化され、認証される。
【００５４】
クライアント１０２がＣＯＮ＿ＳＥＬメッセージを送信した後で、クライアント１０２は、好適には、第三者サーバ１０７からの一致するセッション権およびＴＰＡｕｔｈメッセージを後で確認するために、セッションＩＤ値をセーブすることが好ましい。クライアント１０２は、好適には、構成することができる時間切れの値が時間切れになるまで、セッションＩＤを保持することが好ましい。時間切れになると、クライアント１０２は、もはや対応するセッション権およびＴＰＡｕｔｈを処理することはできないので、再試行を
行う必要がある。
【００５５】
受信した場合、第三者サーバ１０７は、ＣＯＮ＿ＳＥＬメッセージを確認する。ＣＯＮ＿ＳＥＬメッセージが暗号化および／または認証されている場合には、第三者サーバは、前に確立したリンク鍵によりＣＯＮ＿ＳＥＬメッセージを解読する。ＣＯＮ＿ＳＥＬメッセージが確認されると、第三者サーバ１０７は、ＣＯＮ＿ＳＥＬメッセージに応じて、セッション権およびＴＰＡｕｔｈメッセージを生成する。一実施形態の場合には、第三者サーバ１０７は、第三者サーバ１０７により認証が行われる解釈領域（ＤＯＩ）オブジェクトを生成する。ＤＯＩオブジェクトは、クライアント１０２が所望のサービスおよび／またはコンテンツを受信するために、第１のアプリケーション・サーバ１０６から機密保護セッションを要求した場合に、クライアントが、通常、ＫＥＹ＿ＲＥＱメッセージと一緒に送信するセッション権を含む。
【００５６】
本発明は、そうしたい場合に、ＣＯＮ＿ＳＥＬメッセージの認証を行いおよび／または解読を行うために使用する特定の方法に依存しない。一例を挙げて説明すると、このメッセージは、ＫＥＹ＿ＲＥＱ／ＫＥＹ＿ＲＥＰ交換により、クライアントと第三者サーバとの間で前に確立された共有リンク鍵により認証を行い解読することができる。
【００５７】
一実施形態の場合には、ＤＯＩオブジェクトは、ＤＯＩオブジェクトをセッション権を供給するものとして識別するＤＯＩ＿タイプを指定する。第三者サーバ・アクセス情報には、クライアント１０２がセッション権を確認することができるように、セッションＩＤが含まれている。この同じセッションＩＤは、鍵管理が終了し、セキュリティ・パラメータが確立された場合、機密保護ストリーミング・セッションを識別するために使用することができる。このセッションＩＤを含む同じセキュリティ・パラメータは、同じストリーミング・セッションに関連するＲＴＰ、ＲＴＣＰおよびＲＴＳＰプロトコルに適用することができる。終了時間は、それ以降はセッション権がもはや有効でなくなる時間を指定するために、セッション権に内蔵されている。さらに、第三者サーバ１０７およびクライアントの識別がセッション権に内蔵されている。所望のコンテンツおよび／またはサービスを指定するために、コンテンツＩＤが内蔵されている。一実施形態の場合には、コンテンツＩＤはＲＴＳＰ  ＵＲＬのようなＵＲＬである。第１のアプリケーション・サーバ１０６は、このＵＲＬをセーブし、それをセッションＩＤに関連付ける。コンテンツＩＤは、ＲＴＳＰプロトコルにより要求したＵＲＬを確認するために使用される。セッション権は、また、そうしたい場合には、所望のサービスおよび／またはコンテンツの支払いおよび支払いのタイプを指定する購入オプションを含むことができる。
【００５８】
セッション権がオプションとして含む追加パラメータとしては、特定の１つのまたは複数の国への所望のコンテンツの配布を制限する国に対する配布禁止、特定の１つのまたは複数の地理的エリアへの配布を制限する地理的配布制限、加入のために所望のコンテンツが提供されるサービスＩＤを提供する加入ＩＤのような配布の制限等がある。
【００５９】
セッション権には、第三者サーバ１０７がセッション権およびＴＰＡｕｔｈを生成したこと、およびセッション権およびＴＰＡｕｔｈが、そのクライアント、別のクライアントまたは別のサーバのようなネットワーク１００の他のエンティティが生成したものではないことを証明するために、ＴＰＡｕｔｈが添付されている。一実施形態の場合には、ＴＰＡｕｔｈは、第三者サーバ１０７が第１のアプリケーション・サーバ１０６のために前に受信した第三者サーバのＳＴチケット、第三者サーバの署名、経過時間を含む。第１のアプリケーション・サーバへの第三者サーバのＳＴチケット内のセッション鍵は、アクセス情報の署名を生成するために使用される。一実施形態の場合には、ＴＰＡｕｔｈの生成は、アクセス情報、許可およびセッション権の生成から独立している。一実施形態の場合には、署名は対称鍵により生成され、対称鍵により生成された署名は、通常ＭＡＣ（メッセ
ージ認証コード）と呼ばれる。ＭＡＣアルゴリズムの例としては、ＨＭＡＣ（ハッシュド・メッセージ認証コード）がある。ＭＡＣはまた、鍵をかけたチェックサムとも呼ばれる。
【００６０】
一実施形態の場合には、セッション権および認証は、第三者サーバおよびクライアントの両方が知っているセッション鍵により暗号化することができる。この場合、クライアントは第三者サーバに対するサービス・チケットをすでに入手している。セッション権および認証は、第三者サーバ１０７からクライアント１０２に転送される。クライアントは、セッション権内に含まれている少なくともセッションＩＤ（セッションを識別するための）によりＣＯＮ＿ＳＥＬメッセージへのセッション権および認証を確認する。
【００６１】
ＫＥＹ＿ＲＥＱおよびＫＥＹ＿ＲＥＰメッセージは、クライアント１０２（または第三者サーバ１０７）と第１のアプリケーション・サーバ１０６との間の鍵管理および認証のために使用される。ＫＥＹ＿ＲＥＱメッセージは、新しい一組のセキュリティ・パラメータを確立するために、クライアント１０２によりアプリケーション・サーバ１０６に送られる。ＫＥＹ＿ＲＥＱメッセージは、また第１のアプリケーション・サーバ１０６との新しい鍵を周期的に確立するために、クライアント１０２が使用することができる。クライアント１０２は、ＫＤＣ１０４から前に入手した有効なＳＴチケットによりスタートする。第１のアプリケーション・サーバ１０６は、自分がチケットを解読し、確認するために使用することができるそのサービス鍵によりスタートする。ＫＥＹ＿ＲＥＱメッセージは、第１のアプリケーション・サーバのためのＳＴチケット、およびクライアント１０２の認証を行うために必要なＫＥＹ＿ＲＥＱのコンテンツ上のセッション鍵で鍵をかけられているチェックサムを含む署名を含む。ＫＥＹ＿ＲＥＱメッセージは、好適にはまた、臨時の値（それを応答ＫＥＹ＿ＲＥＰメッセージに結びつけるための）およびクライアント・タイムスタンプ（再生攻撃を防止するための）を含むことが好ましい。一実施形態の場合には、クライアントの臨時の値はクライアント１０２が生成した疑似乱数である。この場合、クライアントは、臨時の値が未決着のＫＥＹ＿ＲＥＱメッセージに対応しないことを確認する。
【００６２】
ＫＥＹ＿ＲＥＱは、さらに、暗号化されたＤＯＩを含み、それ故クライアントの許可のために使用することができる第三者情報を含む。暗号化されたＤＯＩのコンテンツは、アプリケーションに依存する。上記コンテンツは、アプリケーションにより定義される。一般的に、上記コンテンツは、この特定のターゲット・プロトコル・セッションを、クライアント１０２と第１のアプリケーション・サーバ１０６との間に位置する他のセッションから区別する１つまたはそれ以上のターゲット・プロトコル向け識別子を含む。他の情報も暗号化されたＤＯＩに内蔵させることができる。ＤＯＩは、クライアントにより暗号化することができ、ある場合には、ヌル暗号化アルゴリズムにより暗号化される（クライアントのプライバシーを保護する必要がない場合）。ＳＴチケット内のセッション鍵は、データを暗号化するために発行される。
【００６３】
ＫＥＹ＿ＲＥＱは、さらに、ＴＰＡｕｔｈを含む。一実施形態の場合には、ＴＰＡｕｔｈは、第１のアプリケーション・サーバ１０６に対する第三者サーバ１０７のＳＴチケット、第三者サーバの署名および時間制限を含む。第１のアプリケーション・サーバ１０６は、セッション鍵により第三者サーバのＳＴチケット、第三者サーバの署名を確認し、時間制限が時間切れになっていないことを確認する。
【００６４】
一実施形態の場合には、クライアント１０２がＫＥＹ＿ＲＥＱメッセージを生成した場合、クライアント１０２の識別は、アプリケーション・サーバ１０６のためのクライアント１０２のＳＴチケットの暗号化された部分内に含まれていて、メッセージの平文内には含まれていない。クライアント１０２がＫＥＹ＿ＲＥＱメッセージを送信した後で、クラ
イアント１０２は、アプリケーション・サーバ１０６からの一致するＫＥＹ＿ＲＥＰメッセージを後で確認するために、クライアントの臨時の値をセーブする。クライアント１０２は、構成することができる時間切れの値が時間切れになるまでクライアントの臨時の値を保持する。時間切れになると、クライアント１０２は、もはや対応するＫＥＹ＿ＲＥＰメッセージを処理することができない。クライアント１０２は、このような時間切れになった後で再試行を行うことができる。
【００６５】
以下にＫＥＹ＿ＲＥＱの処理の一例を説明する。最初に、第１のアプリケーション・サーバ１０６が、メッセージのヘッダを構文解析する。このヘッダ構文解析に失敗した場合には、アプリケーション・サーバ１０６は、メッセージを放棄し、エラーを返送しない。次に、第１のアプリケーション・サーバ１０６は、ヘッダ内のプロトコル・バージョン番号を確認する。プロトコル・バージョンがサポートされていない場合には、アプリケーション・サーバ１０６は、メッセージを放棄し、エラーを返送しない。次に、アプリケーション・サーバ１０６は、第１のアプリケーション・サーバ１０６からのサービスおよび／またはコンテンツにアクセスするために、クライアント１０２に対するＳＴチケットを確認する。
【００６６】
クライアントのＳＴチケットを確認する際に、一実施形態の場合には、第１のアプリケーション・サーバ１０６は、ＳＴチケットを構文解析する。ＳＴチケットのフォーマットが仕様と一致しない場合には、確認は失敗する。第１のアプリケーション・サーバ１０６が、チケット・バージョン番号をサポートしない場合には、確認は失敗する。ＳＴチケット内のサーバ名および領域名が、第１のアプリケーション・サーバ１０６のそれと一致しない場合には、確認は失敗する。ＳＴチケットを暗号化するために使用したサービス鍵のバージョンが、第１のアプリケーション・サーバ１０６が使用する現在のバージョンでない場合で、もし第１のサーバ１０６がＳＴチケット内に指定されているサービス鍵・バージョン番号を依然として有している場合には、第１のアプリケーション・サーバ１０６は、ＳＴチケットを解読する。そうでない場合には、確認は失敗する。第１のアプリケーション・サーバ１０６は、第１のアプリケーション・サーバ・サービス鍵で、ＳＴチケットのプライベート部分を解読し、次に解読したデータを構文解析する。解読または構文解析に失敗した場合には、確認は失敗する。第１のアプリケーション・サーバ１０６は、ＳＴチケットのプライベート部分を解読するためにも使用する、同じサービス鍵により、ＳＴチケット上で鍵がかかっているチェックサムを確認する。チェックサムの確認に失敗した場合、または第１のアプリケーション・サーバ１０６が、そのチェックサム・タイプをサポートしていない場合、確認は失敗する。第１のアプリケーション・サーバ１０６は、さらに、有効期間（チケットの開始および終了時間）を確認し、チケットの有効期間が時間切れになっているか、または現在も無効である場合には、確認は失敗する。エラーがない場合には、第１のアプリケーション・サーバ１０６は、ＳＴチケットを確認する。
【００６７】
回復不能エラー・コードのためにＳＴチケットの確認に失敗した場合には、アプリケーション・サーバ１０６は、エラーを報告し、ＫＥＹ＿ＲＥＱのそれ以上の処理を打ち切る。次に、署名の属性が確認される。確認に失敗した場合には、ＫＥＹ＿ＲＥＱは放棄され、エラーは返送されない。上記ＳＴチケット確認が回復可能エラー・コードになった場合には、アプリケーション・サーバ１０６は、署名を確認する目的で、ＳＴチケットからのセッション鍵を抽出するために、古いサービス鍵を使用しようとする。
【００６８】
第１のアプリケーション・サーバ１０６は、次に、ＫＥＹ＿ＲＥＱがまだ時間切れになっていないことを確認するためにクライアント時間をチェックする。第１のアプリケーション・サーバ１０６は、また、ＤＯＩオブジェクトを入手するために、ＳＴチケットからのセッション鍵により暗号化されたＤＯＩを解読する。次に、アプリケーション・サーバ１０６は、ＴＰＡｕｔｈを確認する。ＴＰＡｕｔｈが認識されないか、ＴＰＡｕｔｈが不
正に変更されていると判断した場合には、第１のアプリケーション・サーバ１０６は、クライアント１０２にエラーを返送する。そうでない場合には、アプリケーション・サーバ１０６は、アプリケーション向けのＤＯＩオブジェクトをさらに処理する。エラーがある場合には、エラーが返送される。ＤＯＩオブジェクトの処理中にエラーがない場合には、クライアントの許可が確認され、第１のアプリケーション・サーバ１０６は、ＤＯＩオブジェクトのコンテンツに基づいて、適当なＫＥＹ＿ＲＥＰを生成する。
【００６９】
ＴＰＡｕｔｈの処理中、第１のアプリケーション・サーバ１０６は、ＴＰＡｕｔｈから第三者サーバ１０７のＳＴチケットを抽出する。次に、第１のアプリケーション・サーバ１０６はＳＴチケットを確認する。第三者サーバ１０７のＳＴチケットの確認中にエラーを発見した場合には、エラーがクライアント１０２に返送され、認証は失敗する。第１のアプリケーション・サーバ１０６は、さらに、サービス鍵により第三者サーバ１０７のＳＴチケットのプライベートなチケット部分を解読し、セッション鍵を抽出する。第三者サーバ１０７の署名が構文解析される。第１のアプリケーション・サーバ１０６は、さらに解読した第三者サーバ１０７のＳＴチケットから入手したセッション鍵により、ＤＯＩオブジェクトの署名を生成する。生成したＤＯＩオブジェクト署名は、アクセス情報の認証を解読するために、ＴＰＡｕｔｈの署名で確認される。確認に失敗した場合には、第１のアプリケーション・サーバ１０６は、クライアント１０２にエラーを返送する。一実施形態の場合には、ＤＯＩオブジェクトの処理中に、第１のアプリケーション・サーバ１０６は、クライアントの許可を確認するステップに進む。このことは、ＤＯＩオブジェクトにより返送された情報を、チケット内に含まれているかもしれないクライアントの許可と突き合わせ、またアプリケーション・サーバ１０６の一部上に記憶しているかもしれない許可に影響を与える追加情報と突き合わせることにより行うことができる。例えば、アプリケーション・サーバは、特定のＩＳＰによりインターネットに接続しているすべてのクライアントに対する制限を追加することができる。
【００７０】
ＫＥＹ＿ＲＥＰメッセージは、ＫＥＹ＿ＲＥＱメッセージに応じて、第１のアプリケーション・サーバ１０６により送信される。第１のアプリケーション・サーバ１０６は、ＫＥＹ＿ＲＥＱを処理し、条件が満たされ、第三者アプリケーション・サーバ１０７のアクセス情報および認証が確認された場合には、ＫＥＹ＿ＲＥＱを返送する。一例を挙げて説明すると、ＫＥＹ＿ＲＥＰメッセージは、クライアント１０２とアプリケーション・サーバ１０６との間で共有するセッション鍵で暗号化されているランダムに生成した副鍵を含むことができる。ＫＥＹ＿ＲＥＱと同様に、プロトコルが対称である場合には、クライアントが第三者サーバにより認証されるある種の追加情報を入手したい場合、ＫＥＹ＿ＲＥＰも、ＤＯＩオブジェクトおよび対応する認証符号（ＴＰＡｕｔｈ）を含むことができる。ＫＥＹ＿ＲＥＰ内のＴＰＡｕｔｈは、ＳＴチケット、署名および時間切れ時間を含む。この場合、ＳＴチケットは、クライアント１０２にではなく、第三者アプリケーション・サーバ１０７に属する。第三者サーバ１０７のＳＴチケット内のセッション鍵は、暗号化されたＤＯＩ応答に含まれる署名を生成するために使用される。ＫＥＹ＿ＲＥＰメッセージは、セキュリティ・パラメータを確立するのに必要な追加情報も含むことができる。
【００７１】
図２は、第１のアプリケーション・サーバ１０６を通して、第三者アプリケーション・サーバ１０７が供給するアプリケーション、プロセス、サービス、および／またはコンテンツへアクセスするためのクライアント１０２の要求に第三者アプリケーション・サーバ１０７の情報および認証を提供するためのプロセス２２０の一実施形態の１つの実施の簡単な流れ図である。ステップ２２２において、第三者アプリケーション・サーバ１０７は、第１のアプリケーション・サーバ１０６へのＳＴチケットを入手する。ステップ２２４において、クライアント１０２は、第１のアプリケーション・サーバ１０６へのＳＴチケットを入手する。ステップ２２６において、クライアント１０２は、アプリケーション、プログラムおよび／またはコンテンツにアクセスするために、第三者アプリケーション・
サーバ１０７への要求を提出する。ステップ２３０において、第三者アプリケーション・サーバ１０７は、クライアント１０２にセッション権およびＴＰＡｕｔｈを発行する。ステップ２３２において、クライアント１０２は、第１のアプリケーション・サーバ１０６にＫＥＹ＿ＲＥＱを提出する。この場合、ＫＥＹ＿ＲＥＱはセッション権およびＴＰＡｕｔｈを含む。ステップ２３６において、第１のアプリケーション・サーバ１０６は、セッション権およびクライアントの許可およびＴＰＡｕｔｈに関連する場合がある任意の他の局所的に記憶している情報に基づいて、クライアントの許可を確認する。ステップ２４０において、第１のアプリケーション・サーバ１０６は、クライアントの許可およびＴＰＡｕｔｈが確認された場合、クライアント１０２に副鍵を含む鍵応答を返送する。
【００７２】
図３は、第１のアプリケーション・サーバ１０６を通して、第三者アプリケーション・サーバ１０７が供給するサービスおよび／またはコンテンツへアクセスするためのクライアント１０２の要求に、第三者アプリケーション・サーバ１０７の情報および認証を提供するためのプロセス３２０の一実施形態の１つの実施の簡単な流れ図である。ステップ３２２において、第三者アプリケーション・サーバ１０７は、ＫＤＣ１０４に、チケット許可チケット（ＴＧＴ）に対するＡＳ＿ＲＥＱを提出する。ステップ３２４において、ＫＤＣ１０４は、第三者アプリケーション・サーバ１０７に、ＴＧＴを証明するＡＳ＿ＲＥＰを発行する。ステップ３２６において、第三者アプリケーション・サーバ１０７は、第１のアプリケーション・サーバ１０６に、ＳＴチケットを要求するＫＤＣにＴＧＳ＿ＲＥＱを提出する。ステップ３２８において、ＫＤＣ１０４は、第１のアプリケーション・サーバ１０６に対するＳＴチケットと一緒に、ＴＧＳ＿ＲＥＰを返送する。ステップ３３０において、クライアント１０２は、ＫＤＣ１０４にチケット許可チケット（ＴＧＴ）に対するＡＳ＿ＲＥＱを提出する。ステップ３３２において、ＫＤＣ１０４は、クライアント１０２にＴＧＴを証明するＡＳ＿ＲＥＰを発行する。ステップ３３４において、クライアント１０２は、第１のアプリケーション・サーバ１０６に、ＳＴチケットを要求するＫＤＣ１０４にＴＧＳ＿ＲＥＱを提出する。ステップ３３６において、ＫＤＣ１０４は、第１のアプリケーション・サーバ１０６に対して、ＳＴチケットと一緒にクライアント１０２にＴＧＳ＿ＲＥＰを返送する。
【００７３】
ステップ３３５において、クライアント１０２は、第三者アプリケーション・サーバ１０７に対してＳＴチケットを要求しているＫＤＣ１０４に、ＴＧＳ＿ＲＥＱを提出する。ステップ３３７において、ＫＤＣ１０４は、第三者アプリケーション・サーバ１０７に対するＳＴチケットと一緒に、クライアント１０２にＴＧＳ＿ＲＥＰを返送する。ステップ３４０において、クライアント１０２は、アプリケーション、プログラムおよび／またはコンテンツにアクセスし、それらを選択するために、第三者アプリケーション・サーバ１０７に要求を提出する。一実施形態の場合には、クライアント１０２は、第三者アプリケーション・サーバ１０７に対するクライアント１０６のＳＴチケット内のセッション鍵により、要求の少なくとも一部を暗号化する。ステップ３４４において、第三者アプリケーション・サーバ１０７は、クライアント１０２にＴＰＡｕｔｈを含むセッション権を返送する。
【００７４】
ステップ３５０において、クライアント１０２は、第１のアプリケーション・サーバ１０６にＫＥＹ＿ＲＥＱを提出する。この場合、ＫＥＹ＿ＲＥＱは、セッション権およびＴＰＡｕｔｈを含む。ステップ３５４において、第１のアプリケーション・サーバ１０６は、セッション権およびクライアントの許可およびＴＰＡｕｔｈに関連している場合がある任意の他の局所的に記憶している情報に基づいてクライアントの許可を確認する。ステップ３５８において、第１のアプリケーション・サーバ１０６は、クライアント１０２に副鍵を返送する。しかし、当業者であれば、本発明の新規性から逸脱することなしに、上記のステップの中のいくつかの順序を変更することができることを理解することができるだろう。例えば、別の方法としては、ステップ３３０〜３３６は、ステップ３４４と３５０
との間で実行することができる。この場合、クライアントはステップ３４４でキャッシング・サーバの識別を入手し、次に、クライアントはキャッシング・サーバのサービス・チケットを入手する（オンデマンド）。
【００７５】
すでに説明したように、第１のアプリケーション・サーバ１０６は、サービスまたはコンテンツを受信するために、クライアントが第三者（例えば、第２のアプリケーション・サーバ１０７）からクライアントの許可のために必要な情報を入手した後で、クライアント１０２にサービスおよび／またはコンテンツを供給することができる。一例を挙げて説明すると、第三者サーバ１０７は、１人またはそれ以上の許可を得たクライアントに映画のコンテンツを実際に配布するために、１つまたはそれ以上のキャッシング・サーバ（例えば、第１のアプリケーション・サーバ１０６）を使用するペイ・パー・ビュー映画供給業者であってもよい。そのため、ネットワークのトラヒックを低減し、経路選択をもっと簡単にし、また他のネットワークの考慮事項を最適化するために、コンテンツをクライアントにもっと近い位置に、ネットワーク１００を横切って配布することができる。例えば、映画のようなコンテンツにアクセスするためには、クライアント１０２は、最初、第三者サーバ１０７または他のリスト（複数のコンテンツ・プロバイダが共有するコンテンツ・ディレクトリを通して供給されるリストなど）にアクセスし、１つまたはそれ以上の所望の映画を選択する。次に、第三者サーバ１０７は、キャッシング・サーバ１０６からの映画にアクセスするために、クライアント１０２に対してキャッシング・サーバ１０６がクライアントの許可の際に後で使用するアクセス情報を返送する。一実施形態の場合には、第三者アクセス情報は、セッション権として供給される。第三者サーバ１０７は、さらにセッション権の一部と一緒にまたはセッション権の一部として認証を発行する。
【００７６】
クライアント１０２は、この例の場合には所望の映画である必要なコンテンツにアクセスしようとする場合には、キャッシング・サーバ（すなわち、第１のアプリケーション・サーバ１０６）に、これらのセッション権および認証を転送する。この認証は、第三者情報が、第三者情報を生成するクライアントまたは他のエンティティのような別のネットワーク・エンティティとは反対の第三者サーバ１０７（すなわちペイ・パー・ビュー供給業者）が実際に生成したものかどうかを確認するために、キャッシング・サーバ１０６が使用する。
【００７７】
それ故、本発明の方法およびシステムは、第三者サービス・プロバイダおよび／またはコンテンツ・プロバイダに、第三者サービス・プロバイダおよび／またはコンテンツ・プロバイダから依然として情報を入手しながら、またこの情報をチケットをベースとする鍵管理プロトコル内に機密保護状態で含みながら、別のアプリケーション・サーバからサービスおよび／またはコンテンツをクライアントが入手することができるようにする効率的な方法を提供する。チケットに基づく第三者認証を含むこの方法は、デジタル署名およびデジタル証明書を使用する他の従来の方法およびシステムと比較すると、（もっと低い処理能力しか必要としない）かなりより効率的なものである。クライアントは、クライアントの許可に関連している場合があり、チケットにより情報が効率的に認証される第三者サーバからいくつかの情報を入手する。この第三者情報は、また他の従来技術のシステムの場合には、通常、第三者サーバから他のアプリケーション・サーバに直接送信され、そのため都合の悪いことに追加のネットワーク・インタフェースを必要とするコンテンツ規則も含むことができる。本発明は、従来のチケットをベースとするケルベロスのような鍵管理システムが持っていないクライアント−サーバ・鍵管理およびクライアントの許可を提供する。
【００７８】
例えば、第三者サーバ・アクセス情報は、名前、場所、および／またはクライアントが要求したコンテンツおよび／またはサービスへのアクセスに対して課金するために使用される、課金システムに対するネットワーク・アドレスを含むことができる。第１のアプリ
ケーション・サーバ１０６は、課金システムを指定するためにクライアントを信用することができないので、第１のアプリケーション・サーバは、課金システム情報の認証を行う。
【００７９】
本発明を使用すれば、第三者情報（例えば、解釈領域（ＤＯＩ）オブジェクト）を含む鍵要求を、鍵要求がクライアントのような第１の構成要素または当事者が生成した場合には、メッセージ交換プロセスに関連する第三者により認証を行うことができる。この認証符号は、第三者情報の生成者が鍵要求の送信者ではなく、他のある第三者である場合に役に立つ。
【００８０】
本発明は、鍵交換を使用する実質的にすべての分散型権利管理システムに対して実行することもできるし、適用することもできる。さらに、本発明は、その上、実質的にすべてのチケットをベースとする鍵管理プロトコルで実施することができる。一実施形態の場合には、本発明は、機密保護マルチメディア・コンテンツ交換システム、ビデオ・オンデマンド・システム、マルチキャスト・コンテンツ配布システム、およびコンテンツおよび／またはサービスが、クライアントおよびサーバのようなネットワークの構成要素間で交換される他のこのようなシステムのクライアント・エンドおよびサーバ・エンドを通して実施することができる。
【００８１】
マルチメディア・コンテンツの交換は、オーディオまたはビデオだけに限定されないし、ストリーミングされたコンテンツに限定されない。この交換は、機密保護文書、電子書籍、ソフトウェア配布、プログラム、アプリケーション、アップグレード、音楽ファイルおよび他のこのような交換のダウンロードのような他の交換にも適用される。
【００８２】
本発明は、チケットおよび信頼されているチケット配布装置（すなわち、１つまたはそれ以上のＫＤＣ）をベースとするケルベロスのような他の鍵管理プロトコルに対して実施し、適用することができる。さらに、認証は、データの分離および認証が使用される実質的にすべてのこのような鍵管理プロトコルに対して実施し、適用することができる。一実施形態の場合には、本発明は、第三者情報の第三者認証を鍵管理プロトコルの一部とし、第三者情報のアプリケーション向けコンテンツとは独立して、鍵管理デーモンにより処理される。一実施形態の場合には、本発明は、モトローラ社が開発した電子セキュリティ・ブローカ（ＥＳＢｒｏｋｅｒ）内で、また、モトローラ社が開発したＩＰ権利管理システムの一部として実施される。
【００８３】
認証から第三者情報の処理を分離すると、本発明をもっと一般的なものにして、複数の鍵管理システムおよび複数のプロトコルに適用することができる。本発明は、送信側が第三者情報のフォーマットを知らなくても、第三者情報に認証を添付するために、鍵要求のようなメッセージ交換の送信側が使用するためのものである。本発明は、２つの当事者のうちの一方が生成したのではなく、代わりに第三者が生成した２つの当事者間で交換した情報を第三者が生成したものとして認証することができる実質的にすべてのチケットをベースとする鍵管理システムで実施することができる。さらに、本発明は、鍵交換のための実質的にすべての分散型権利管理システムのチケットをベースとするプロトコルで実施することができる。本発明は、第三者サーバ・データおよびその対応する認証を分離し、そのうちのいくつかがデジタル権利管理を含むことができる複数のおそらく関連のないアプリケーションに対する鍵を確立するために、同じ鍵管理デーモンを再使用できる追加の柔軟性を与える。
【００８４】
今まで特定の実施形態およびその用途により本発明を説明してきたが、当業者であれば、特許請求の範囲に記載する本発明の範囲から逸脱することなしに、多数の修正および変更を行うことができる。
【図面の簡単な説明】
【００８５】
【図１】本発明のある実施形態により構成したシステムのブロック図。
【図２】本発明のある実施形態による、クライアントが第１のアプリケーション・サーバからコンテンツを要求した場合の第三者情報の認証を提供するための方法を示す流れ図。
【図３】本発明のある実施形態による、クライアントが第１のアプリケーション・サーバからコンテンツを要求した場合の第三者情報の認証を提供するための方法を示す流れ図。
【図１】
2005525622.tif 000002
【図２】
2005525622.tif 000003
【図３】
2005525622.tif 000004