JP2004032220A

JP2004032220A - 電子チケットを用いたアクセス権管理装置

Info

Publication number: JP2004032220A
Application number: JP2002183739A
Authority: JP
Inventors: Yoshihiro Shin; 申　吉浩; Taro Terao; 寺尾　太郎; Masahiro Taguchi; 田口　正弘
Original assignee: ACCESSTICKET SYSTEMS Inc
Current assignee: ACCESSTICKET SYSTEMS Inc
Priority date: 2002-06-24
Filing date: 2002-06-24
Publication date: 2004-01-29
Anticipated expiration: 2022-06-24
Also published as: JP3896909B2

Abstract

【課題】アクセス資格の管理が集中しないようにし、さらにアクセス資格の無効化、譲渡、分割、変更などの操作を行えるようにする。
【解決手段】電子チケット生成装置１１０は、特定情報取得手段１１１を内部に保持する。特定情報取得手段１１１は、ユーザが所有するクライアント装置１２０を特定する特定情報２０２を取得する。電子チケット生成装置１１０は特定情報２０２を利用して電子チケット２０１を生成する。アプリケーション装置１３０は、クライアント装置１２０と通信を行い、電子チケット２０１を検査して、ユーザのアクセス資格を検証する。
【選択図】　図１

Description

【０００１】
【発明の属する技術分野】
この発明は、電子的データによって表現された各種サービス利用権の発行、検証、ならびに前記利用権データに対する無効化、譲渡、分割、変更などの操作を行うアクセス権管理技術に関する。
【０００２】
【背景の技術】
アクセス権管理システムにおいては、リソースやサービスに対するアクセスを欲する主体がアクセス要求を行い、一方、リソースを管理する主体がアクセスを欲するものを認証することによってそのアクセスを許可したり拒絶したりする。
【０００３】
情報システムとしては、このようなアクセス権認証は、アクセス要求主体とアクセス管理主体が、それぞれアクセス資格を証明する証明情報とアクセス資格を認証する検証情報に基づいて、データの交換と評価を行うことによって実現される。
【０００４】
アクセス資格保持者を他のアクセス資格を持たない第三者から区別する機能の原理は、畢竟アクセス資格証明情報の保持にかかっており、どのような暗号学的な技法が用いられるかに依存しない事実である。
【０００５】
情報システムにおいて、アクセス資格の保持はユーザのアクセス資格証明情報保持と直結しているが故に、アクセス管理主体から見ると、アクセス資格保持者がアクセス資格証明情報を第三者にそのまま引き渡すことが常に原理的脅威となる。
【０００６】
この脅威を取り除くことを目的に、従来技術によるアクセス権管理システムでは、アクセス要求主体たるユーザの保持する証明情報は当ユーザの利害に直接関与する情報とし、その情報の濫用、つまり、第三者への開示がアクセス要求主体にとって望ましくないような状況を演出する。例えば、アクセスアカウントをユーザの銀行口座番号やクレジットカード番号に関連付けてデータベースに記録したり、公開鍵インフラ（ＰＫＩ）で公開鍵証明書の発行に際して運転免許証のような身分証明を要求するのは、これが理由である。つまり、アクセス管理におけるアクセス要求主体たるユーザの証明情報は、ユーザのアイデンティティを指示する識別情報そのものであるか、もしくは、このような識別情報とシステム的に緊密に関連付けられた情報である。
【０００７】
従って、アクセス権管理システムは、ユーザの身許を認証するシステムレイヤと、認証の結果に基づいて該ユーザに許されているアクセス権を確認するシステムレイヤとから構成され、アクセス権の管理は次のステップに従って実行させる。
【０００８】
［ステップ１］：ユーザはリソースへのアクセスをアクセス管理主体に対して要求する。
［ステップ２］：アクセス管理主体は、予め定められた適切な手段を用いて、ユーザの身許を認証する。この目的に供される手段の例としては、アクセス管理主体が適正と認める認証局（Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ）が発行する公開鍵証明書と公開鍵暗号アルゴリズムによる認証プロトコルの実行や、予めデータベース中に記録されたユーザの身許証明データ（銀行預金口座番号、クレジットカード番号など）の暗証番号をキーとする照会などがある。
［ステップ３］：アクセス管理主体は、前記ユーザの身許認証に失敗した場合、該ユーザのアクセス要求を拒否する。
［ステップ４］：予めデータベース中に記録されたレコードを参照し、身許の確認された該ユーザに許可されているアクセス資格を確認する。レコードには行使条件（有効期限など）やアクセス種別（読み出し、書き込み、変更など）などアクセス資格の定義が記録される。データベース中に記録されるアクセス資格定義のレコードの集まりをアクセス制御リスト（ＡＣＬ，Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ　Ｌｉｓｔ）と呼ぶこともある。
［ステップ５］：アクセス管理主体は、ステップ４で確認されたアクセス資格の範囲内で、該ユーザによるリソースへのアクセスを許可する。
【０００９】
このように、従来技術によるアクセス権管理システムは、次の二つの特徴を有する。
１、ユーザの身許（アイデンティティ）を認証するステップを含む。
２、アクセス制御リストなどによりユーザのアクセス資格の集中管理を行う。
【００１０】
【発明が解決する課題】
前節で述べた従来技術に鑑み、本発明では、従来技術が有する以下の５項目の課題を解決することを目的とする。
【００１１】
１、アクセス資格の集中管理に起因する運用側のコストの増大と運用時の性能上の制約
２、アクセス資格の集中管理に起因する流通フローを実現する上での制約
３、ユーザが複数のクライアント装置を取得しなければならないことの不便
４、秘密情報が介在することに起因して発生する、サービス提供者、クライアント装置提供者、アプリケーション装置提供者の間の相互運用性の阻害
５、ユーザによるアクセス権の行使における匿名性の欠如
【００１２】
以下では、従来技術がとる構成上の特徴に関連付けて、上記の課題に関して説明する。
【００１３】
従来技術の構成上の第１の特徴はつぎのようなものである。従来技術においては、ユーザを特定してサービスの利用を制御するために、サービスの提供者がユーザを管理するための手段を保持する必要があった。典型的な例としては、サービスの提供者が管理するサーバ上にデータベースを構築し、ユーザの識別情報を含むユーザ固有の情報を格納するデータレコードを記憶しておく。ここでは、このユーザ固有のデータレコードをアカウントと呼ぶ。サービスの提供者は、特定のユーザによるサービスへのアクセスの可否を判断する際に、このアカウントを参照する。アカウントには、ユーザの身許の識別情報が記憶されており、この識別情報を用いて、たとえユーザがネットワークを挟んで存在した場合においても、その身許を認証して、然る後、ユーザによるサービスへのアクセスの可否を判断する。アカウントには、該ユーザによるサービスの利用に関わる種々の情報、例えば、アクセス種別、アクセス許諾期間、アクセス許諾回数などが記録され、サービスの提供者はこれらの情報をもとに、粒度の細かい制御を実施する。
【００１４】
本発明が解決しようとする従来技術の第一の課題は、従来技術による上記構成に起因する、アカウントの管理コストのオーバーヘッドと性能上の制約である。
【００１５】
サービスの提供者が管理するアカウントは、サービスへのアクセス制御を行う上で根幹となる情報が格納されている。従って、外部からの侵入や内部の不正行為により、これらの情報が改竄されたり消去されたりすると、ユーザによるサービスの利用を正しく制御することができなくなり、サービスの提供者は損害を蒙る危険がある。ために、当アカウントのセキュリティの管理は厳重に行わなければならず、ファイアウォールによる外部からの侵入の防止、内部からのアクセスの制御などの対策を、システム管理者による不断の注意のもとで継続的に実施する必要があった。
【００１６】
サービスを利用するユーザの数が増加し、また、ユーザによるサービスの利用頻度が高まることによってアカウントへのアクセス数が増大すると、アカウントを管理するための上記オーバーヘッドは飛躍的に増大し、サービス提供者の大きな負担となる。勿論、多数のユーザのアカウントを記録するための大きな記憶媒体の調達や、物理アクセスの制限、停電などの事故に備えたバックアップなどのオーバーヘッドも大きくなる。
【００１７】
サービス提供の性能の観点からは、アカウントを格納するサーバの処理能力やネットワークとの接続環境が限界要因となり、アクセスが集中した場合、単位時間あたりの処理数（スループット）や１処理あたりの処理時間（ターンアラウンドタイム）が低下する恐れがある。特に、ユーザによるサービスの利用のたびにアカウントにアクセスする、所謂、オンライン・オンデマンド型の制御方法では、この課題による弊害はより顕著になり、ユーザに堪えがたい不便を強いることとなる。
【００１８】
従来技術の課題の原因となる、従来技術の構成の第２の特徴は以下のとおりである。
【００１９】
前記、データベースによるユーザのアカウントの管理の例にみるように、従来技術の構成では、ユーザによるサービスの利用の制御は、単一のサーバや装置によって集中的に行われる。
【００２０】
この構成上の特徴に起因する、従来技術の第二の課題は、前記集中管理的な利用制御は市場で求められている流通フローを実現する上での阻害要因となる、少なくとも、重要なコスト要因となる点である。
【００２１】
例えば、商品の流通フローとしては、再販モデル（リテイルモデル）と呼ばれる形態が一般的である。再販モデルにおいては、最上流の商品の生産者と最下流の消費者との間で、複数の卸業者と小売業者が介在し、商品は上流から下流に流れていく。商品が一旦生産者の手をはなれ、卸業者の手に渡されると、該卸業者による次工程の卸業者或いは小売業者への商品の販売は、全く該卸業者の恣意にゆだねられ、上流に位置する生産者は取引に関与することはない。この事実は、更に下流の卸業者及び小売業者に関しても同様である。
【００２２】
一方、従来技術によるサービスの利用制御では、サービスの利用権の流通は全て中央のサーバないし装置で管理されるため、商品の生産者に当たるサービスの提供者の介在を省くことができない。この事実は、商品たるサービスの利用権の流通にあたり、トランザクションが煩雑になるのに加え、中央のサーバないし装置で流通経路を管理する必要が生じ、また、利用権の移動が発生する都度中央のサーバないし装置に対してアクセスが発生することから、システムが大規模にならざるを得ず、構築及び運用のコストも増大する。
【００２３】
別の例としては、近年、デジタルコンテンツの新しい流通形態として注目を浴びているピア・ツー・ピアの流通がある。ピア・ツー・ピアの流通では、消費者は、サービスの提供者が許諾する範囲で、自ら購入したサービスの利用権のコピーを作成し、他の消費者に譲渡することが認められる（私的利用に限定した複製の許諾）。従来技術の構成により、ピア・ツー・ピアの流通を実現しようとすると、個人消費者間での利用権の譲渡は、中央のサーバないし装置を経由して実行されるため、前述の再販モデルの場合と同様に、システムの構築及び運用コストの増大をもたらす。これは、また、プライバシー保護の観点からも問題となる。
【００２４】
従来技術の課題の原因となる、従来技術の構成上の第３の特徴は以下のとおりである。
【００２５】
ユーザによるサービスの利用制御を確実に実行するためには、サービスに対するアクセスが許諾されたユーザとそれ以外のユーザとを確実に区別するための手段が必須となる。このために、システム固有の秘密の識別情報が用いられることがある。例えば、アカウントにユーザを識別するためのパスワードを記録しておき、ユーザに対するサービス利用の可否を判断するたびに、ユーザにパスワードの入力を促し、記録されたパスワードと入力されたパスワードとの一致を検査する。この方式は、現在インターネット上で提供されている多くのサービスで採用されているものである。前記システム固有の識別情報の秘密性は、サービス提供者の利益の保全に緊密に関わっており、外部に漏洩することによりサービスの提供者の利益を著しく損なう危険がある。このため、異なるサービスの提供者のシステム間で、前記識別情報を共有することができない。
【００２６】
また、前記従来技術の構成上の特徴と関連して、従来技術の課題の原因となる、従来技術の構成上の第４の特徴は、サービスの利用制御の仕組みと、ユーザに対して実際にサービスを提供するアプリケーション装置とが一体化しており、複数のサービスの提供者による異なるシステム間での相互運用性がない点である。このような構成は、ユーザによるサービスの利用の制御にシステム固有の秘密情報（暗号の鍵など）を利用している点に起因している。異なるアプリケーション装置の提供者が提供するアプリケーション装置と、サービス提供者が運用する利用制御装置とを相互に連携させて運用する場合、利用制御装置に帰属する秘密情報がアプリケーション装置中に現れることとなる。アプリケーションの提供者に悪意があり、アプリケーション装置がサービスの提供者に帰属する前記秘密情報を外部に漏洩するように作成されていた場合（バックドア）、サービスの不正な濫用を許す結果になる。
【００２７】
従来技術の第三の課題は、従来技術の前記構成に起因する。
【００２８】
即ち、ユーザが複数のサービスの提供者が提供するサービスを利用する際、ユーザは自らのアクセス権を証明する手段（例えば、パスワード）をサービスの提供者の数だけ、或いは、サービスの数だけ保持しなければならないという、ユーザの利便性に関する課題である。
【００２９】
前記パスワードによる方法は、パスワードが横流しされる危険があり、ユーザのアクセス権を認証する手段としてはあまり安全ではない。より安全な利用制御を行おうとすると、識別のための秘密情報を内蔵するクライアント装置の存在を仮定する。
【００３０】
クライアント装置は、例えば、ＰＣ上で稼動するプログラムの形態をとったり、ＩＣカードなどのデバイスの形態をとったりするが、クライアント装置にはサービスの提供者の利害に影響する秘密情報が内蔵されていることから、複数のサービス提供者の間で共有ができないという事由と、アプリケーション装置と一体化している必要があるという自由により、ユーザは、サービスの提供者毎、或いは、サービスやコンテンツの種別毎にクライアント装置を調達しなければならない。これは、ユーザが、サービスの提供者やサービスごとに異なるプログラムを自分のＰＣにインストールしたり、ＩＣカードを取得して携行しなければならないということを意味し、ユーザにとっての大きな参入障壁となる。
【００３１】
前記課題を、サービスの提供者の観点から見てみると、サービスの提供者が自ら保有するサービスを、確実な利用制御を前提とした上で、広くユーザに提供しようとした場合に、ユーザが前記クライアント装置を取得する際の閾が問題となる。ユーザに対して、自分のサービスだけにのみ使用できるクライアント装置の取得を動機付けることは、ユーザの手間を考えると、易しいことではなく、サービスをユーザに提供する上での重大な阻害要因となる。
【００３２】
このように、本発明では、クライアント装置とアプリケーション装置との間の相互運用性を実現することで、前記第三の課題を解決することを目指すが、このことは、サービスの提供者、クライアント装置の提供者、アプリケーション装置の提供者が互いに異なることを前提とする。
【００３３】
従って、本発明が解決しようとする第四の課題は、サービス提供者が運用する管理システム、ユーザが保持するクライアント装置、アプリケーション提供者が供給しユーザにサービスを提供するアプリケーション装置が協調してサービスの利用制御を行う際に、互いに、それぞれの提供者の利益を損なうことがないにする点にある。
【００３４】
具体的な例では、クライアント装置とアプリケーション装置が協調することにより、クライアント装置の秘密情報がアプリケーション装置に露呈し、その結果アプリケーションの提供者が偽のクライアント装置を構成できる脅威がある。また、サービス提供者が運用する管理システムは、正当なユーザにのみサービスを提供するようにアプリケーション装置を制御するわけであるが、この時アクセス資格の偽造につながる秘密情報がアプリケーション装置に流れることがあってはならない。
【００３５】
このように、システム間の相互運用性を確保するためには、システム間で相互の秘密情報が流れることがない設計である必要がある。
【００３６】
本発明が解決しようとする第五の課題は、従来技術によるアクセス権権利システムがユーザの身許認証を含むことに起因する。
【００３７】
公共、商用を問わず、現在実際にユーザに提供されているサービスを観察すると、必ずしも、ユーザの身許の認証を必要としないものが多いことが分かる。例えば、多くの商用サービスでは、アクセスを要求しているユーザが対価を支払っているか否かが、サービスを提供するか否かを決定する要因であって、そのユーザの身許を認証する必要は些かも存しない。これは、従来技術のアクセス資格管理システムが、アクセス資格の横流しといった脅威に対して脆弱であるため、ユーザの身許情報とアクセス資格を緊密に結びつけることでこの脆弱性を補おうとする、いわば、必要悪である。
【００３８】
実際、ユーザの視点から見ると、サービスの利用に際して、必須ではないにもかかわらず自らの身許を明らかにしなければならないというのは、プライバシー保護の観点からは好ましくない。
【００３９】
【課題を解決するための手段】
この発明によれば、上述の目的を達成するために、特許請求の範囲に記載のとおりの構成を採用している。
【００４０】
本発明は、ユーザに対して、該ユーザが保有するアクセス資格を電子チケット（チケットデータ）の形態で発行し、サービスを提供するアプリケーション装置と、ユーザが保有し、該ユーザを他のユーザと区別するための手段であるクライアント装置とが、互いに協調して該電子チケットを処理することで、サービスのアクセス制御を実現するものである。
【００４１】
本発明の第１の側面によれば、上述の第一の課題を解決するために、クライアント装置を特定する目的に供する特定情報であって、かつ、第三者に開示しても安全性を損なうことのない情報を、公開の手順で取得する手段を設けることで、サービスの提供者がアカウント管理等の手段を用いて前記特定情報を集中管理することなく、チケットデータを生成することを可能とする。
【００４２】
クライアント装置の特定情報は、クライアント装置が必要に応じて生成したり、電子チケット生成装置が、ディレクトリサービスなどの第三者機関を介して、取得することが可能である。
【００４３】
更に、チケットデータの生成及び発行の過程で、クライアント装置内に電子チケット生成装置との間の共有鍵を保持せしめるとともに、アプリケーション装置が検査するチケットデータを該共有鍵に依存せしめ、ユーザがサービスにアクセスする際にクライアント装置内に保持される該共有鍵の存在を根拠にアクセス資格を証明することにより、サービスの提供者のシステムが関与することなくアクセス資格の認証を可能とし、結果としてアクセス資格の集中管理を排する。
【００４４】
また、本発明の他の側面によれば、上述の第二の課題を解決するために、チケットデータの無効化、譲渡、分割、条件の変更を、サービス提供者が運用するシステムを介することなく、アプリケーション装置とクライアント装置との間のトランザクションのみにより実行可能となる構成とすることで解決する。
【００４５】
チケットデータに関わる前記の操作がアプリケーション装置とクライアント装置との間で実行可能であることは、チケットデータの流通の過程で、流通に関わる当事者、例えば、販売者と購買者が、第三者の干渉やサポートを受けることなく取引を完結することができることを意味し、現在すでに存在するものも含めて、多様な流通フローを直接的に実現できることを意味する。
【００４６】
また、さきに述べたように上述の本発明の第１の側面によれば、クライアント装置の特定情報を開示可能で、かつ、電子チケット生成装置が公開された手続きにより取得できる手段を設けていいる。このに併せて、公開の手続きで取得された特定情報に基づいて、電子チケット生成装置とクライアント装置が、電子チケット毎の共有鍵を生成し、該共有鍵を用いてアクセス制御を実行する構成すれば、チケットデータの生成に当たってクライアント装置固有の秘密情報が電子チケット生成装置に送られることがなくなり、よって一つのクライアント装置で異なるサービス提供者が運用する複数の電子チケット生成装置から、チケットデータの供給を受けることが可能となる。これにより上述の第三の課題も解決できる。
【００４７】
また、本発明のさらに他の側面によれば、第四の課題を解決するために、第一に、アプリケーション装置とクライアント装置が、一方向性関数手段を用いて通信データを生成し、よって各々の秘密情報が相手方に伝わらない構成としている。更に、電子チケット生成装置がアプリケーション設定データ及びクライアント証明データを評価する手段を設けることで、サービスの提供者が、アプリケーション装置及びクライアント装置の提供者を認証することを可能とし、結果として、相互運用性の実現において問題となる提供者間（従って、装置間）の信頼の確立に手段を与える。
【００４８】
また、上述した本発明の第１の側面によれば、ユーザの識別情報ではなく、クライアント装置の特定情報に基づきチケットデータを生成するので、第五の課題を解決することができる。より厳密に考えるならば、アクセス制御が電子チケット生成装置とクライアント装置との間で共有される共有鍵に基づいて実施され、加えて、クライアント装置に内部データの改竄や窃取に対する保護手段が施されており、該共有鍵の横流しが困難であることから、クライアント装置の特定情報をユーザの識別情報にバインドして抑止効果を狙うことなく、安全を確保することが可能となる。
【００４９】
なお、この発明は装置またはシステムとして実現できるのみでなく、方法としても実現可能である。また、そのような発明の一部をソフトウェアとして構成することができることはもちろんである。またそのようなソフトウェアをコンピュータに実行させるために用いるソフトウェア製品（記録媒体）もこの発明の技術的な範囲に含まれることも当然である。
【００５０】
【発明の実施の形態】
以下、この発明の実施例について説明する。
【００５１】
［実施例１］
［全体の構成］
図１は本発明を適用した実施例の構成図である。本実施例は、コンピュータ・携帯端末・ＩＣカード、その他専用のデバイス・専用端末から構成され、これらが協調して動作することで電子チケットの発行・流通・検証を行う。
【００５２】
図１において、１１０は電子チケットを生成して発行する電子チケット生成装置である。
【００５３】
１２０は、ユーザに帰属するクライアント装置であり、パーソナルコンピュータやワークステーション、携帯電話やＰＤＡ等の携帯型端末、演算機能を内蔵したＩＣカード（スマートカード）などの上に実装されるプログラムである。
【００５４】
１３０はアプリケーション装置であり、電子チケット２０１を検査することによりユーザのアクセス権を検査し、検査が成功した場合に限ってコンテンツの復号などのサービスをユーザに提供する。アプリケーション装置１３０は、クライアント装置１２０と同一の機器上で実現されても、また、異なる機器上に実現されてもよい。
【００５５】
さて、電子チケット生成装置１１０は、クライアント装置１２０を特定して、電子チケット２０１を生成する。電子チケット２０１は特定のユーザによるサービスへのアクセス権を表現するデータであることから、電子チケット生成装置１１０は該ユーザを他のユーザから区別できる必要がある。本発明では、該ユーザが所有するクライアント装置１２０を特定する特定情報２０２を、電子チケット生成装置１１０が利用することでこの目的を果たす。
【００５６】
さて、本発明を構成する要件の第一は、電子チケット生成装置１１０が、クライアント装置１２０の特定情報２０２を管理するデータベースなどを独自に保持することはせず、公開された手続きを介して外部から必要に応じて取得する点にある。このために、電子チケット生成装置１１０は、特定情報取得手段１１１を内部に保持する。特定情報取得手段１１１は、例えば、インターネット上の電子メールシステムであったり、ディレクトリサーバに接続するためのネットワーク接続プログラム並びに通信デバイスであったりする。
【００５７】
一方、アプリケーション装置１３０が電子チケットを検査するに当たっては、クライアント装置１２０と通信を行う。アプリケーション装置１３０が電子チケット２０１を検査する目的は、特定のユーザが該アプリケーション装置１３０の提供するサービスに対するアクセス権を保有していることを検査する点にあり、言い換えるならば、該電子チケット２０１が該ユーザに帰属することを検査する点にあるが、この検査を該ユーザに帰属する固有のクライアント装置と通信を行い、該クライアント装置のみが生成できるデータを取得することで実行する。
【００５８】
従って、クライアント装置１２０とアプリケーション装置１３０とは、それぞれ相手と通信するための通信手段（２）１２１、通信手段（１）１３１を含む。通信手段（２）１２１、通信手段（１）１３１による具体的な通信方式は、クライアント装置１２０とアプリケーション装置１３０の実施例に依存して、適切なものを選択する。クライアント装置１２０とアプリケーション装置１３０が同一のパーソナルコンピュータやワークステーション上のプログラムとして実現される場合、例えば、クライアント装置１２０はダイナミックリンクライブラリ（ＤＬＬ）やコム（ＣＯＭ）として実装され、アプリケーション装置１３０は所定のアプリケーションプログラムインターフェース（ＡＰＩ）を介した関数呼び出しによりクライアント装置１２０と通信するように構成することができる。クライアント装置１２０とアプリケーション装置１３０とがネットワークを介して接続している場合、リモートプロシージャコール（ＲＰＣ）やＨＴＴＰなどを介して通信が行われる。クライアント装置１２０が特殊なデバイスである場合は、それぞれのデバイスの機能や仕様に応じた通信手段が選ばれる。ＩＣカードであればＩＳＯ７８１６準拠の通信プロトコル、携帯端末ではＩｒＤＡ（Ｉｎｆｒａ　Ｒｅｄ　Ｄａｔａ　Ａｃｃｅｓｓ）、Ｂｌｕｅｔｏｏｔｈ（商標）、ＩＥＥＥ８０２．１１ｂなどの赤外線や無線による通信プロトコルが利用される。
【００５９】
［クライアント装置の特定情報の取得の例］
アプリケーション装置１３０は、電子チケットを検査することで、特定のユーザが特定のリソース或いはサービスに対するアクセス権を有しているか検査する。仮に、電子チケットが正しいアクセス権を有するユーザ以外のユーザの手に渡った場合においても、アプリケーション装置１３０は電子チケットを検査することで、該ユーザが正当なユーザでないことを検知して、アクセスを拒否しなければならない。
【００６０】
アプリケーション装置１３０は、例えば、図６〜図８に示すように構成でき、通信手段（１）１３１の他に、秘密鍵保持手段１３２、電子チケット保持手段１３３、アクセス権認証手段１３４、コマンド発行手段１３６等を有している。
【００６１】
この機能を実現するために、本発明では、少なくともアプリケーション装置１３０が電子チケットを検査する時点において、正当なアクセス権を保有するユーザが保持するクライアント装置１２０に、該クライアント装置１２０に固有であり、かつ、外部に知られることのない秘密情報を保持せしめると同時に、電子チケットを該秘密情報に依存するように生成する。アプリケーション装置１３０は、該秘密情報、または、該秘密情報を用いて計算されるデータを、通信手段（１）１３１を介してクライアント装置１２０から取得し、該秘密情報、もしくは、該通信データに基づいて電子チケットを検査する。電子チケットは、該秘密情報に依存するように構成されるので、アプリケーション装置１３０が、該秘密情報、もしくは、該秘密情報から計算されるデータにアクセスできない限り、電子チケットの検査に成功することはない。本実施例では、該秘密情報を、認証情報と呼ぶことにする。
【００６２】
電子チケットを生成するに当たって、該クライアント装置１２０を特定して前記認証情報を保持せしめることを目的として、電子チケット生成装置１１０はクライアント装置１２０の特定情報２０２を使用する。
【００６３】
一方、特定情報２０２の正当性、即ち、特定情報２０２がどのユーザのクライアント装置を特定するかを知らしめる機能は、必ずしも、特定情報２０２に具備されない。この機能は、ＰＫＩなど、外部の仕組みで実現することが可能であるからであり、リソースやサービスの特性によって適切なものを選択することができる。
【００６４】
以下では、前述の全体構成に基づき、電子チケット生成装置１１０がクライアント装置１２０の特定情報２０２を取得する方法について、より具体的な実施例を示す。
【００６５】
電子チケット生成装置１１０による特定情報２０２の取得方式は、電子チケット生成装置１１０がクライアント装置１２０から特定情報２０２を取得する方式と、電子チケット生成装置１１０がクライアント装置１２０の特定情報２０２が登録されている第三者機関（ディレクトリサービスなど）から取得する方式とに大別される。
【００６６】
図２〜図５は、電子チケット生成装置１１０がクライアント装置１２０から特定情報を取得する方式の構成を示している。クライアント装置１２０は特定情報生成手段１２２を含み、該手段により特定情報２０２を生成して電子チケット生成装置１１０に提供する。
【００６７】
電子チケット生成装置１１０は、必ずしもネットワークなどの通信手段を使って特定情報２０２を取得する必要はなく、たとえば、フロッピーディスクに記録されたり、バーコードなどに準拠して印刷された形式を受け取って処理してもよいので、電子チケット生成装置１１０とクライアント装置１２０との間の通信手段は設けない。
【００６８】
該クライアント装置１２０の特定情報は、該クライアント装置１２０が保持する秘密情報に依存して生成されるが、該秘密情報は、該クライアント装置１２０に固有かつ固定のデータである場合と、動的に生成される使い捨てのデータである場合の両様がありえる。
【００６９】
前者の典型的な例は、前記秘密情報が、該クライアント装置１２０の製造業者が付与する識別番号や暗号の秘密鍵のような場合である。
【００７０】
一方、後者の典型的な例は、前記秘密情報が、該クライアント装置１２０固有の方式で生成されるシリアル番号や都度生成される乱数である場合である。
本発明の目的を達するための要件の一つとして、電子チケット生成装置１１０は特定情報を必ずしも安全ではないチャネルを介して、公開の手続きで取得できなければならない。そのため、秘密情報がクライアント装置１２０固有でかつ固定的である場合はいうに及ばず、シリアル番号や乱数のような都度使い捨てられる場合であっても、クライアント装置１２０が詐称される（成りすまされる）ことを防ぐために、特定情報から秘密情報が漏れることがあってはならない。
【００７１】
この要件を満足するような特定情報の構成例のひとつは、クライアント装置１２０の前記秘密情報を、例えば、電子チケット生成装置１１０に帰属する公開鍵暗号の公開鍵を用いて暗号化したデータを、特定情報２０２とする場合である。
【数１】
特定情報＝暗号化関数_{電子チケット生成装置の公開鍵}（クライアント装置の秘密情報）
【００７２】
この構成方法例では、クライアント装置１２０は、電子チケット生成装置１１０の公開鍵を取得する必要がある。該公開鍵はクライアント装置の中に予め格納しておいたり、公開鍵証明書のように認証機関によって裏書きされた形式で都度クライアント装置１２０に入力するなどの方法で供給する。
【００７３】
一方、公開鍵のような電子チケット生成装置１１０に依存する情報を利用しない方法もある。
【００７４】
例えば、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵交換アルゴリズムを用いる方法である。以下では、表記の都合から、楕円曲線を公開鍵暗号利用におけるベースの群とするが、本発明に関する説明において、楕円曲線暗号に基づく設定に限定する意図は全くない。例えば、体の乗法群をもちいるような場合は、加法と乗法を、スカラー倍と冪乗を読み替えれば、以下に述べる例はそのまま乗法群上の例と解釈することができる。
【００７５】
以下の実施例においては、楕円曲線Ｅ上で十分大きな位数をもつ点Ｇを基点として定めておき、クライアント装置１２０は、図１０に記載の手順で特定情報を生成する。
【００７６】
［ステップ１］：（５１１）Ｇの位数より小さい正の整数ｒをランダムに生成する。
［ステップ２］：（５１２，５１３）楕円曲線Ｅ上で、Ｒ＝ｒＧを計算し、Ｒを特定情報とし、電子チケット生成装置に送付する。
【００７７】
一方、電子チケット生成装置１１０は、次の手順で電子チケットを生成する。
［ステップ１］：（５１４）Ｇの位数より小さい正の整数ｒ’をランダムに生成する。
［ステップ２］：（５１５，５１６）楕円曲線Ｅ上で、Ｋ＝ｒ’Ｒを計算し、Ｋに依存するように電子チケットを生成する。
［ステップ３］：（５１７，５１８）Ｒ’＝ｒ’Ｇを計算し、Ｒ’を電子チケットに添付して発行する。
【００７８】
クライアント装置１２０はｒを保持しておき、Ｒ’（＝ｒ’Ｇ）が入力された段階で、Ｋ＝ｒＲ’（＝ｒｒ’Ｇ）を計算する。このＫが認証情報となる。
クライアント装置１２０は、アプリケーション装置１３０との通信に際して、Ｋを用いた計算により通信データを生成する。認証情報Ｋは、ｒを知っている該クライアント装置１２０のみが計算しえる値であるので、アプリケーション装置１３０は正しいクライアント装置１２０を他のクライアント装置から区別できるのである。
【００７９】
また、電子チケット生成装置１１０の公開鍵を用いない別の例として、一方向性ハッシュ関数を利用する方法も存在する。一方向性ハッシュ関数は、「出力から入力を求める計算量が極めて大きく、そのため、実用的には出力から入力を推測することは不可能である」という性質をもつ関数である。米国連邦政府調達規格（ＦＩＰＳ）で規定されているＳＨＡ−１（Ｓｅｃｕｒｅ　Ｈａｓｈ　Ａｌｇｏｒｉｔｈｍ）は、世界的に広く利用されている一方向性ハッシュ関数の実例である。
【００８０】
この場合、クライアント装置１２０は、電子チケット毎に使い捨ての秘密情報を生成し、それに一方向性ハッシュ関数を施した結果を特定情報とする。
【数２】
特定情報＝一方向性ハッシュ関数（クライアント装置の使い捨ての秘密情報）
【００８１】
一方向性ハッシュ関数の特性により、特定情報から秘密情報を得ることはできない。一方、クライアント装置１２０はアプリケーション装置１３０と通信を行う際に、該使い捨ての秘密情報を提示する。アプリケーション装置１３０は、受信した該秘密情報に同じ一方向性ハッシュ関数を施し、電子チケットが得られたハッシュ値に依存して生成されていることを検査する。この例では、クライアント装置１２０が生成した該秘密情報が認証情報となる。
【００８２】
ここまでで述べた特定情報の実施例では、電子チケット生成装置１１０が特定情報の正当性を確認する手段が提供されない。即ち、クライアント装置１２０が意図するユーザに帰属するクライアント装置の特定情報であることを保証する機能は提供されない。特定情報の正当性を検証するための手段は別途与えられることを前提とするが、この手段は、電子チケット生成装置１１０がクライアント装置１２０を所持するユーザを識別する際のポリシーに強く依存する。
【００８３】
例えば、電子チケット生成装置１１０が、対価を支払ったユーザに対しては無条件に電子チケットを発行するというポリシーをもっていた場合、特定情報は一旦決済機関に送付され、該決済機関において対価の支払いが確認された時点で、該決済機関が該特定情報に電子署名を施して、電子チケット生成装置１１０に送付するという構成がありえる。
【００８４】
別の例としては、電子チケット生成装置１１０がユーザの身許を確認した後に電子チケットを発行するポリシーを採用している場合、ユーザが特定情報に電子署名を施し、電子チケット生成装置１１０はユーザの公開鍵証明書により署名を検査して電子チケットの発行の可否を判断するという構成がありえる。
【００８５】
前記２例では、特定情報の正当性を確認する手段を電子チケット生成装置１１０及びクライアント装置１２０の外部に設けたが、内部に設ける方法も可能である。
【００８６】
特定情報の正当性を内部的に保証する方法のもっとも典型的な実施例は、クライアント装置１２０の公開鍵、より実際的には、該公開鍵を含む公開鍵証明書を特定情報として利用す方法である。この場合、クライアント装置１２０は、該公開鍵に対応する秘密鍵（個人鍵、私有鍵、プライベート鍵などともいう）を保持する秘密情報保持手段（秘密鍵保持手段）１２３を含む。
【００８７】
例えば、電子チケットに該公開鍵を含めておき、クライアント装置１２０が秘密情報保持手段１２３に保持されている秘密鍵を用いて生成したデータを、アプリケーション装置１３０が電子チケットに含まれる該公開鍵を用いて検査する方法である。この例では、クライアント装置１２０の秘密鍵が認証情報として用いられる。
【００８８】
また、電子チケット生成装置１１０が、認証情報となる共有鍵ｋを生成し、ｋをクライアント装置１２０の公開鍵で暗号化した暗号化データを生成し、該暗号化データを電子チケットとともに発行する方法も可能である。クライアント装置１２０は、該暗号化データの入力を受けて、秘密情報保持手段１２３に保持されている秘密鍵を用いてｋを復号し、アプリケーション装置１３０との通信においてｋを用いて通信データを生成する。
【００８９】
先述したように、クライアント装置１２０の公開鍵を特定情報とする方法の最大の利点は、公開鍵証明書（ＩＴＵ−Ｔ　Ｘ．５０９など）と公開鍵インフラ（ＰＫＩ）の仕組みを用いたインフラを、電子チケット生成装置１１０が特定情報２０２の正当性を確認する手段として利用できることから該機能を外部に求める必要がない。公開鍵インフラは、認証局が公開鍵に裏書きすることで公開鍵の正当性を保証する仕組みであることから、電子チケット生成装置１１０は偽のクライアント装置１２０によるなり済ましの危険を排除することが可能となる。
【００９０】
一方、上記の方法を組み合わせて、特定情報２０２を、クライアント装置１２０の公開鍵とクライアント装置１２０が部分特定情報生成手段１２４を利用して生成する動的な部分特定情報とから構成するようにもできる。
【００９１】
例えば、変形Ｍｅｎｅｚｅｓ−Ｑｕ−Ｖａｎｓｔｏｎｅ鍵交換アルゴリズムを用いて、図１１に記載の手順で特定情報を構成することができる。
【００９２】
クライアント装置１２０は、特定情報を生成する。
［ステップ１］：（５２１）基点Ｇの位数より小さい正の整数ｒをランダムに生成する。
［ステップ２］：（５２２、５２３）楕円曲線Ｅ上で、Ｒ＝ｒＧを計算し、Ｒを部分特定情報とする。
【００９３】
一方、電子チケット生成装置１１０は、図１１に記載の手順で電子チケットを生成する。
［ステップ１］：（５２４）クライアント装置１２０の公開鍵であるＥ上の点ＰとＲとを併せて特定情報とする。
［ステップ２］：（５２５）Ｇの位数より小さい正の整数ｒ’をランダムに生成する。
［ステップ３］：（５２６）楕円曲線Ｅ上で、Ｋ＝ｒ’（Ｒ＋π（Ｒ））Ｐを計算し、Ｋに依存するように電子チケットを生成する。但し、π（Ｒ）はＲのｘ座標から所定の方法で計算される正の整数である。
［ステップ４］：（５２７，５２８）Ｒ’＝ｒ’Ｇを計算し、Ｒ’を電子チケットに添付して発行する。
【００９４】
クライアント装置１２０はｒを保持しておき、Ｒ’（＝ｒ’Ｇ）の入力を受けた段階で、認証情報Ｋを、次式のように計算する。
【数３】
（ｒ＋π（Ｒ）ｐ）Ｒ’＝（ｒ＋π（Ｒ）ｐ）（ｒ’Ｇ）
＝（（ｒ＋π（Ｒ）ｐ）ｒ’）Ｇ＝ｒ’Ｒ＝Ｋ
【００９５】
クライアント装置１２０は、アプリケーション装置１３０との通信に際して、Ｋを用いた計算により通信データを生成する。
【００９６】
但し、ｐは公開鍵Ｐに対応する秘密鍵で、楕円曲線Ｅ上でＰ＝ｐＧを満足する。
【００９７】
認証鍵Ｋはｒとｐとを知っている該クライアント装置１２０のみが計算しえる値であるので、アプリケーション装置１３０は正しいクライアント装置１２０を不正なクライアント装置から区別できるのである。
【００９８】
［電子チケットの構成方法の例］
電子チケットは、ユーザによるサービスへのアクセスに関する種々の属性、例えば、有効アクセス期限（アクセス開始期日、アクセス終了期日）、有効アクセス回数、クライアントの特定情報、サービスの特定情報、その他、アプリケーション装置１３０が解釈し実行する種々のルールを指定する属性を含む。この属性の中には、アプリケーション装置１３０が実行するスクリプトのようなプログラムを含めることもできる。
【００９９】
さて、電子チケットに求められる安全性に関しては、以下の２点の要請が重要である。
【０１００】
（ア）アプリケーション装置１３０は、前記属性を含む電子チケットに対する改竄を検知できること。
（イ）アプリケーション装置１３０は、正当なクライアント装置１２０を認証できること。正当なクライアント装置１２０とは、電子チケット生成装置１１０が該電子チケットを生成する際に参照した特定情報２０２に対応するクライアント装置１２０を指す。
【０１０１】
特定情報の生成方法に関する前述の例のいくつかに基づいて、上記要件を満足する電子チケットの構成方法を例示する。
【０１０２】
特定情報が、クライアント装置１２０が保持する使い捨ての秘密情報と一方向性ハッシュ関数から生成される場合、電子チケットは、例えば、以下のように構成することができる。
【数４】
電子チケットデータ：：＝　　　｛サービスの識別子、アクセスの有効期限、アクセスの有効回数、その他のアクセスに関するルール、クライアント装置の特定情報、電子チケット生成装置による電子署名｝
【０１０３】
アプリケーション装置１３０は、電子チケット生成装置１１０による電子署名を検査することで、電子チケットが改竄されているかを検査することができる。この場合、アプリケーション装置１３０は、電子チケット生成装置１１０の署名検証用の公開鍵を何らかの手段で取得している必要がある。
【０１０４】
次いで、アプリケーション装置１３０は、現在サービスへのアクセスを要求しているユーザが、電子チケット生成装置１１０が意図している正しいユーザであることを確かめるために、該ユーザが保持するクライアント装置１２０と通信を行う。
図１２は、検証の手順である。
［ステップ１］：（６１１，６１２）クライアント装置１２０は、特定情報を生成する際に使用した使い捨ての秘密情報を、アプリケーション装置１３０に送付する。
［ステップ２］：（６１３）アプリケーション装置は、
【数５】
指定されている特定情報＝一方向性ハッシュ関数（受信した秘密情報）
が成立するかを検査する。
［ステップ３］：（６１４）検査が成功した場合には、該ユーザがアクセス権を有する正しいユーザであると認定し、サービスを提供する。検査が失敗した場合には、ユーザによるアクセスを拒否する。
【０１０５】
ここで、一方向性ハッシュ関数としては、ＳＨＡ−１のような公知の関数を用いるので、アプリケーション装置１３０は、電子チケット生成装置１１０、クライアント装置１２０のいずれとも秘密情報を共有することなく、上記アクセス権の検査を実行することが可能となる。
【０１０６】
一方向性ハッシュ関数を用いた特定情報に基づく電子チケットの別の実施例として、電子チケットの属性データを、電子チケット生成装置１１０が受け取った特定情報を鍵として暗号化する方法がある。
【数６】
電子チケットデータ＝暗号化関数_{クライアントの特定情報}（サービスの識別子、アクセスの有効期限、アクセスの有効回数、その他のアクセスに関するルール、クライアント装置の特定情報）
【０１０７】
アプリケーション装置による電子チケットの検査は図１３のように実行される。
［ステップ１］：（６２１，６２２）クライアント装置１２０は、特定情報を生成する際に使用した使い捨ての秘密情報を、アプリケーション装置１３０に送付する。
［ステップ２］：（６２３）アプリケーション装置１３０は、
【数７】
復号鍵＝一方向性ハッシュ関数（受信した秘密情報）
により復号鍵を計算する。
［ステップ３］：（６２４，６２５）前記復号鍵を用いて電子チケットを復号し、
【数８】
復号鍵＝電子チケットに指定されたクライアント装置の特定情報
を検査して、電子チケットが正しく復号されていることを確認する。
［ステップ４］：（６２６）検査が成功した場合には、該ユーザがアクセス権を有する正しいユーザであると認定し、サービスを提供する。検査が失敗した場合には、ユーザによるアクセスを拒否する。
【０１０８】
ここまでに述べた例の特定情報の実施例のうち、電子チケット生成装置１１０の公開鍵で暗号化した鍵ｋをクライアント装置１２０が送付する構成例、クライアント装置１２０の公開鍵で暗号化した鍵ｋを電子チケット生成装置１１０が送付する構成例、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵交換アルゴリズムを利用した構成例、及び、変形Ｍｅｎｅｚｅｓ−Ｑｕ−Ｖａｎｓｔｏｎｅ鍵交換アルゴリズムを用いた構成例では、クライアント装置１２０のみではなく、電子チケット生成装置１１０も認証情報を共有する。
例えば、特定情報が
【数９】
特定情報＝暗号化関数_{電子チケット生成装置の公開鍵}（クライアント装置の認証情報）
と定義される場合には、電子チケット生成装置１１０は自らの秘密鍵を用いて特定情報を復号することにより、クライアント装置１２０が生成した認証情報を共有することとなる。
【０１０９】
Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵交換アルゴリズム、及び、変形Ｍｅｎｅｚｅｓ−Ｑｕ−Ｖａｎｓｔｏｎｅ鍵交換アルゴリズムに基づく例では、認証情報Ｋは、クライアント装置１２０がＲ’を受け取った時点で、電子チケット生成装置１１０とクライアント装置１２０との間で共有されることとなる。
【０１１０】
電子チケット生成装置１１０とクライアント装置１２０との間で認証情報が共有されるとき、認証情報を特に共有鍵と呼ぶこととする。
電子チケット生成装置１１０とクライアント装置１２０との間で共有される共有鍵を、少なくとも鍵の一部として使って得られる暗号化データを電子チケットの定義とすることができる。
【０１１１】
最も、原始的な例としては、
【数１０】
電子チケットデータ：：＝暗号化関数_共有鍵Ｋ（サービスの識別子、アクセスの有効期限、アクセスの有効回数、その他のアクセスに関するルール、クライアント装置の特定情報）
と定義する方法である。
【０１１２】
図１４は、検証手順である。
［ステップ１］：（６３１）アプリケーション装置１３０は電子チケットをクライアント装置１２０に送付する。
［ステップ２］：（６３２）クライアント装置１２０は共有鍵Ｋを用いて電子チケットを復号し、アプリケーション装置１３０に送付する。
［ステップ３］：（６３４）アプリケーション装置１３０は、送付されたデータが、正しい平文であるかを検査する。
［ステップ４］：（６３５）検査が成功した場合には、該ユーザがアクセス権を有する正しいユーザであると認定し、サービスを提供する。検査が失敗した場合には、ユーザによるアクセスを拒否する。
【０１１３】
次に、共有鍵Ｋを用いた暗号化により電子チケットを生成する方法で、安全上ならびに機能上のより高度な要請に応える方法を述べる。
【０１１４】
前提として、サービスは該サービスに固有の公開鍵Ｓと緊密に対応付けられているものとする。例えば、サービスがデジタルコンテンツである場合、コンテンツデータを公開鍵Ｓによって暗号化しておく。このような処置を施すことにより、公開鍵Ｓに対応する秘密鍵ｓによる復号計算を何らかの形で実行しない限り、コンテンツデータにアクセスすることができないようにすることができる。以下の記述では、楕円曲線上の公開鍵暗号を仮定し、Ｓ＝ｓＧが成り立つものとするが、一般の公開鍵暗号でも同様の構成が可能である。
【０１１５】
さて、電子チケットは次のように定義される。
【数１１】
電子チケットデータ：：＝　　　｛サービスの識別子、アクセスの有効期限、アクセスの有効回数、その他のアクセスに関するルール、電子チケット鍵｝
【０１１６】
上記の定義中の電子チケット鍵は以下のように定義する。
【０１１７】
以下、表記の簡明のために、次の記号を用いる。
【数１２】
ｔ：電子チケット鍵
Ｓ：サービスに割り当てられた公開鍵
ｓ：Ｓに対応する秘密鍵、楕円曲線Ｅ上でＳ＝ｓＧを満たす
Ｋ：電子チケット生成装置１１０とクライアント装置１２０の間で共有する共有鍵
ＴｃｋｔＤｅｆ：サービスの識別子、アクセスの有効期限・有効回数、その他のアクセスに関するルールなど、電子チケットの属性から構成されるデータ
ＡｐｐｌＤｅｆ：アプリケーション装置１３０を認証するための方法、アプリケーション装置１３０の特権など、アプリケーション装置のの属性から構成されるデータ（後述）
Ｈ_｜ｓ｜（　）：秘密鍵ｓと同じサイズ（ビット長）の出力を返す一方向性・非衝突ハッシュ関数
ｔ＝ｓ−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）
ＡｐｐｌＤｅｆの役割に関しては後述する。
ｔは、秘密鍵ｓをＨ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）を鍵として暗号化したものであり、Ｋの値がわからないと鍵を計算することができない。
さて、コンテンツデータＣをＥｌＧａｍａｌ暗号によって暗号化したデータを（Ａ，Ｂ）とおく。即ち、
【数１３】

が成り立つ。但し、ξ（ａＳ）は楕円曲線上の点ａＳのｘ座標であるとする。
（Ａ，Ｂ）はコンテンツデータに添付されて、アプリケーション装置１３０に与えられる。
アプリケーション装置１３０とクライアント装置１２０との間の通信は、図１５に従って、実行される。
【０１１８】
［ステップ１］：（６４１）アプリケーション装置１３０はＡをクライアント装置１２０に送付する。
［ステップ２］：（６４２，６４３）クライアント装置１２０は、Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）を計算し、
【数１４】
Ｒ＝Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）Ａ
をアプリケーション装置１３０に送付する。
［ステップ３］：（６４４）アプリケーション装置１３０は、
【数１５】
ａＳ＝ｔＡ＋Ｒ
を計算し、
【数１６】

によりＣを復号する。ａＳ＝ｔＡ＋Ｒが成り立つことは、
【数１７】
ｔＡ＋Ｒ＝（ｓ−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ））（ａＧ）＋Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）（ａＧ）
＝ｓａＧ＝ａＳ
から分かる。
【０１１９】
上記の方法が満足する安全上の特徴は以下である。
【０１２０】
１、サービス提供者の秘密である秘密鍵ｓが、アプリケーション装置１３０に対しても、クライアント装置１２０に対しても開示されない。
【０１２１】
２、ＡｐｐｌＤｅｆ或いはＴｃｋｔＤｅｆが改竄され、ＡｐｐｌＤｅｆ’及びＴｃｋｔＤｅｆ’が与えられると、
【数１８】
ｔＡ＋Ｒ＝（ｓ−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ））（ａＧ）＋Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ’｜ＴｃｋｔＤｅｆ’｜Ｋ）（ａＧ）
＝ａＳ＋（Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ’｜ＴｃｋｔＤｅｆ’｜Ｋ）
−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ））（ａＧ）となり、ａＳと一致しない。従って、コンテンツデータＣをアプリケーション装置１３０はコンテンツデータを復号することができない。
【０１２２】
３、クライアント装置１２０が共有鍵Ｋを知らず、異なる鍵Ｋ’を計算に使用すると、
【数１９】
ｔＡ＋Ｒ＝（ｓ−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ））（ａＧ）
＋Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ’）（ａＧ）
＝ａＳ＋（Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）（ａＧ）
となり、ａＳと一致しない。従って、コンテンツデータＣをアプリケーション装置１３０はコンテンツデータを復号することができず、ユーザはサービスを享受することができない。
【０１２３】
機能上の特徴を述べると、電子チケットのデータ中に、ＴｃｋｔＤｅｆにあたる情報が電子チケット中で平文で現れるため、電子チケットが共有鍵Ｋによる暗号文である例の場合とは異なり、クライアント装置１２０による復号を待たず属性の評価を実施することができる。
【０１２４】
なお、電子チケット生成装置１１０は、図５に示すように、特定情報取得手段１１１の他に、例えば、鍵共有手段（１）１１２、鍵共有データ生成手段１１３、秘密情報保持手段（２）１１４を有し、種々の態様で特定情報を取得して電子チケットを生成できる。
【０１２５】
［アプリケーション装置の認証］
前記のように、アプリケーション装置１３０はクライアント装置１２０と通信することで、該クライアント装置１２０を所有するユーザがサービスに対するアクセス権を有することを検証する。このとき、電子チケットに記載される様々なアクセスに関する属性が改竄されていないことも併せて検証される。
【０１２６】
一方、サービスの提供者には、予め認定したアプリケーション装置１３０以外による上記通信の実行を阻止したいという要請がある。コンテンツデータＣを復号する例を見れば明らかなように、上記通信を実行することにより、サービスの提供者の秘密情報であるコンテンツデータＣが現れるからである。
【０１２７】
この目的のために、アプリケーションの設定データＡｐｐｌＤｅｆが用いられる。
【０１２８】
一義的には、ＡｐｐｌＤｅｆには、アプリケーション装置１３０をクライアント装置１２０が認証するための方法が記述される。
【０１２９】
具体的な例としては、アプリケーション設定データ中にアプリケーション装置１３０の公開鍵を指定することができる。クライアント装置１２０は、アプリケーション設定データ中の公開鍵を利用することで、アプリケーションを認証することができる。
【０１３０】
一方、サービスの提供者は、電子チケット中の電子チケット鍵ｔを計算する時にアプリケーション設定データを計算に含めることにより、該電子チケットによる認証の結果サービスをユーザに提供するアプリケーション装置１３０を特定することができる。
【０１３１】
クライアント装置１２０へのアプリケーション設定データの供給方式は自由である。アプリケーション装置１３０がクライアント装置１２０と通信する際に、自らに関する設定データを入力してもよいし、クライアント装置１２０がアプリケーション装置１３０を介さずに事前に取得しておく方法でもよい。ただし、いずれの場合も、少なくともアプリケーション装置１３０と通信を行う間、該アプリケーション設定データを保持しておく設定データ保持手段１２５が必要である。これは、例えば、メモリ上の一時記憶領域でもよい。
【０１３２】
以下では、（１）と同じ電子チケット鍵に従うが、ＥｌＧａｍａｌ暗号とは別の公開鍵暗号アルゴリズムに基づいて、クライアント装置１２０によるアプリケーション装置１３０の効率的な認証の実施例について述べる。
【０１３３】
ここでベースとする公開鍵暗号アルゴリズムは、Ｓｃｈｎｏｒｒ零知識識別アルゴリズムと呼ばれるものである。ＥｌＧａｍａｌ暗号とは異なり、コンテンツデータなどを暗号化する機能は提供せず、認証に限定して利用されるが、計算量が極めて小さく、スマートカードなど演算能力に制約のある実装で威力を発揮する公開鍵暗号アルゴリズムである。
【０１３４】
アプリケーション設定データには、アプリケーション装置１３０の公開鍵Ａが記載されており、他方、アプリケーション装置１３０は秘密鍵保持手段１３２を含み、秘密鍵保持手段１３２に公開鍵Ａに対応する秘密鍵ａを保持する。楕円曲線Ｅ上で、
【数２０】
Ａ＝ａＧ
が成立する。
【０１３５】
クライアント装置１２０とアプリケーション装置１３０は、図１６に記載の手順で、通信を実行する。
【０１３６】
［ステップ１］：（７０１，７０２，７０３）クライアント装置１２０は、基点Ｇの位数より小さい乱数ｗを生成し、楕円曲線Ｅ上の点Ｗ＝ｗＧを計算して、アプリケーション装置１３０に送付する。
［ステップ２］：（７０４，７０５，７０６，７０７）アプリケーション装置１３０は、乱数ｃを生成するとともに、メッセージ認証鍵ｋをｋ＝ξ（ａＷ）により計算する。次いで、ｋを鍵として乱数ｃに対するメッセージ認証コード（ＭＡＣ、Ｍｅｓｓａｇｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｃｏｄｅｓ）ＭＡＣ（ｋ，ｃ）を計算し、ｃとＭＡＣ（ｋ，ｃ）の組をクライアント装置１２０に送付する。
［ステップ３］：（７０８，７０９）クライアント装置１２０は、アプリケーション設定データ中に指定されているアプリケーション装置１３０の公開鍵Ａを取り出し、ｋ’＝ξ（ｗＡ）によりメッセージ認証鍵ｋ’を計算する。次いで、
【数２１】
ＭＡＣ（ｋ，ｃ）＝ＭＡＣ（ｋ’，ｃ）
を検査し、検査が成功しなかった場合、以後の処理を行わない。
（７１０，７１１）メッセージ認証コードの検査が成功した場合、クライアント装置１２０は
【数２２】
ｒ＝Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）ｃ＋ｗ
を計算し、アプリケーション装置１３０に送付する。
（７１２）アプリケーション装置１３０は、楕円曲線Ｅの上で
【数２３】
（ｃｔ＋ｒ）Ｇ＝ｃＳ＋Ｗ
が成立することを検査する。
【０１３７】
アプリケーション装置１３０が、アプリケーション設定データに記載されている公開鍵Ａに対応する秘密鍵ａを保持している場合、ｋ＝ｋ’が成り立ち、上記ステップ３においてメッセージ認証コードの検査に成功する。これは、
【数２４】
ａＷ＝ａ（ｗＧ）＝（ａｗ）Ｇ＝ｗ（ａＧ）＝ｗＡ
が成り立つことによる。
【０１３８】
逆に、秘密鍵ａを知らずに、Ａ＝ａＧが得られて、楕円曲線Ｅ上の点Ｗに対してそのａ倍を計算することができるかという問題は、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ問題と呼ばれ、計算量的に解決不可能であるとされている。従って、秘密鍵ａを正しく保有するアプリケーション装置１３０以外がクライアント装置１２０と通信を行おうとした場合、確実に、ステップ３において拒否される。
【０１３９】
一方、アプリケーション設定データＡｐｐｌＤｅｆを改竄して、虚偽のアプリケーション装置１３０が保持している秘密鍵ａ’に対応する公開鍵Ａ’を書き込んだＡｐｐｌＤｅｆ’をクライアント装置１２０に入力した場合、クライアント装置１２０は正しいｒを計算することができない。
【０１４０】
アプリケーション設定データ中の公開鍵を書き換える攻撃手法は、虚偽のアプリケーション装置が、正しいアプリケーション装置１３０とクライアント装置１２０の間に割り込み、クライアント装置１２０と通信することで、正しいアプリケーション装置に対してなりすましを図る、Ｍａｎ−Ｉｎ−Ｔｈｅ−Ｍｉｄｄｌｅとよばれる攻撃に用いられる。
【０１４１】
［電子チケットに対する操作］
本実施例では、特権を有するアプリケーション装置１３０が、正当なクライアント装置１２０と協力して、存在する電子チケットの状態を多様に変更する機能を提供する。具体的には以下の機能を提供する。
【０１４２】
［無効化］　現在の電子チケットを無効化し、今後、該電子チケットを用いたアクセス権の検査が必ず失敗するようにする。該電子チケットで表現されているユーザのサービスに対するアクセス権を無効化する目的に用いる。
【０１４３】
［譲渡］　現在の電子チケットを無効化するとともに、現在のクライアント装置と異なる別のクライアント装置によるアクセス権の検査を成功させる、新しい電子チケットを生成する。現在の電子チケットで表現されているアクセス権を、異なるクライアント装置を所有する他のユーザに譲渡する目的に用いる。
【０１４４】
［分割］　電子チケットを無効化するとともに、新しい電子チケットを二つ以上生成する。即ち、現在の電子チケットで表現されているアクセス権を、二つ以上の独立のアクセス権に分割する目的に用いる。
【０１４５】
［変更］　現在の電子チケットを無効化するとともに、サービスへのアクセスに関する異なるルールに従う新しい電子チケットを生成する。例えば、有効利用回数を減じるなど、サービスへのアクセスに伴い、次回以降のサービスへのアクセスの条件が変更した時、その変更を電子チケットに反映させる目的に用いる。
【０１４６】
ここで、重要な性質は、上記機能は、サービスの提供者を煩わせることなく、特権を有するアプリケーション装置１３０とクライアント装置１２０との間で、完結して実行される点である。
【０１４７】
上記性質を満たすように上記機能を提供することにより、「発明が解決しようとする課題」の節で述べたような「アクセス権の多様な流通フローへの対応」を可能とする。
【０１４８】
電子チケットが、
【数２５】
ｔ＝ｓ−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）
と定義される場合を例にとって、前記機能の具体的な実現方法を述べる。
【０１４９】
［無効化の具体例］
共有鍵Ｋがクライアント装置１２０内に生成されるタイミングは、Ｋの生成方法によって異なる。電子チケットの生成時に、クライアント装置１２０がＫを生成し、電子チケット生成装置の公開鍵で暗号化して特定情報とする実施例では、クライアント装置１２０は電子チケットの生成時点で共有鍵Ｋを保持することとなる。一方、Ｒ＝ｒＧを計算して、特定情報或いは部分特定情報として用いる実施例では、電子チケット生成装置１１０が電子チケットとともに生成するＲ’＝ｒ’Ｇが入力された時点で、クライアント装置１２０はＫ＝ｒＲ’又はＫ＝（ｒ＋π（Ｒ）ｐ）Ｒ’によって共有鍵Ｋを計算する。
【０１５０】
しかしながら、どちらのケースでも、クライアント装置１２０はアプリケーション装置１３０との通信時には、共有鍵を共有鍵保持手段１２６に保持しており、通信時に共有鍵Ｋを用いて通信データを生成する。逆に、この共有鍵Ｋなしでは、クライアント装置１２０は、アプリケーション装置によるアクセス権認証を成功せしめる通信データを生成することができない。共有鍵保持手段１２６の共通鍵は共通鍵保護手段１２７によりセキャアに保護される。
【０１５１】
この性質を用いて、電子チケットの確実な無効化が可能となる。即ち、クライアント装置１２０は、共有鍵保持手段１２６に保持されている共有鍵Ｋを消去することにより、Ｋに依存して生成された電子チケットを完全に無効化することができるのである。
【０１５２】
前記、電子チケットの無効化は、無効化を実行する特権を有するアプリケーション装置１３０の指示によって実行される。
【０１５３】
具体的には、アプリケーション装置１３０は、コマンド発行手段１３６を含み、通信手段（１）１３１を介して、クライアント装置１２０に無効化のコマンドを送付し、一方、クライアント装置１２０は通信手段（２）１２１を介して無効化のコマンドを受け取り、更に、コマンド受理手段１３７においてコマンドを解釈する。
【０１５４】
前記のＳｃｈｎｏｒｒ零知識識別アルゴリズムに基づくクライアント装置１２０とアプリケーション装置１３０との通信手続きを例にとって、図１７の記載に従って、無効化のコマンドの発行・受理・実行の手順を説明する。
【０１５５】
［ステップ１］：（８０１，８０２，８０３）クライアント装置１２０は、基点Ｇの位数より小さい乱数ｗを生成し、楕円曲線Ｅ上の点Ｗ＝ｗＧを計算して、アプリケーション装置１３０に送付する。
［ステップ２］：（８０４，８０５，８０６，８０７）アプリケーション装置１３０は、乱数ｃを生成するとともに、メッセージ認証鍵ｋをｋ＝ξ（ａＷ）により計算する。
更に、電子チケットの無効化コマンド“ｒｅｖｏｋｅ”と乱数ｃを合わせてメッセージとし、ｋを鍵としてメッセージ認証コード（ＭＡＣ、Ｍｅｓｓａｇｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｃｏｄｅｓ）
【数２６】
ＭＡＣ（ｋ，“ｒｅｖｏｋｅ”｜ｃ）
を計算し、“ｒｅｖｏｋｅ”とｃとＭＡＣ（ｋ，“ｒｅｖｏｋｅ”｜ｃ）とをクライアント装置１２０に送付する。
［ステップ３］：（８０８，８０９，８１０）クライアント装置１２０は、アプリケーション設定データ中に指定されているアプリケーション装置１３０の公開鍵Ａを取り出し、ｋ’＝ξ（ｗＡ）によりメッセージ認証鍵ｋ’を計算する。次いで、
【数２７】
ＭＡＣ（ｋ，“ｒｅｖｏｋｅ”｜ｃ）＝ＭＡＣ（ｋ’，“ｒｅｖｏｋｅ”｜ｃ）
を検査し、検査が成功しなかった場合、以後の処理を行わない。
また、ＡｐｐｌＤｅｆを参照し、公開鍵Ａに対応付けられているアプリケーション装置に電子チケットを無効化する特権が付与されているか検査する。特権が付与されていない場合には、以後の処理を行わない。
［ステップ４］：（８１１，８１２，８１３）メッセージ認証コードの検査が成功した場合、クライアント装置１２０は
【数２８】
ｒ＝Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）ｃ＋ｗ
を計算し、アプリケーション装置１３０に送付する。同時に、共有鍵保持手段１２６に保持されている共有鍵Ｋを消去し、電子チケットを無効化する。
［ステップ５］：（８１４）アプリケーション装置１３０は、楕円曲線Ｅの上で
【数２９】
（ｃｔ＋ｒ）Ｇ＝ｃＳ＋Ｗ
が成立することを検査する。
【０１５６】
［譲渡の具体例］
Ｓｃｈｎｏｒｒ零知識識別アルゴリズムに基づく実施例を例にとり、譲渡のコマンドの発行・受理・実行の手順に関し、図１８の記載に従って述べる。
【０１５７】
クライアント装置１２０（Ａ）は、差分データ生成手段１２８及び外部特定情報保持手段１２９を含む。なお譲渡もとのクライアント装置１２０を（Ａ）で表し、譲渡先のクライアント装置１２０を（Ｂ）で表す。
【０１５８】
［ステップ１］：（９０１，９０２，９０３）クライアント装置１２０（Ａ）は、基点Ｇの位数より小さい乱数ｗを生成し、楕円曲線Ｅ上の点Ｗ＝ｗＧを計算して、アプリケーション装置１３０に送付する。
［ステップ２］：（９０４，９０５，９０６，９０７，９０８）アプリケーション装置１３０は、乱数ｃを生成するとともに、メッセージ認証鍵ｋをｋ＝ξ（ａＷ）により計算する。更に、電子チケットの譲渡コマンドはコマンド名“ｔｒａｎｓｆｅｒ”と譲渡先のクライアント装置１２０（Ｂ）の特定情報を与えるパラメータＣｌｉｅｎｔＩｄとから構成される。アプリケーション装置１３０は上とコマンドと乱数ｃを合わせてメッセージとし、ｋを鍵としてメッセージ認証コード（ＭＡＣ、Ｍｅｓｓａｇｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｃｏｄｅｓ）
【数３０】
ＭＡＣ（ｋ，“ｔｒａｎｓｆｅｒ”｜ＣｌｉｅｎｔＩｄ｜ｃ）
を計算し、“ｔｒａｎｓｆｅｒ”とＣｌｉｅｎｔＩＤとｃとＭＡＣ（ｋ，“ｔｒａｎｓｆｅｒ”｜ＣｌｉｅｎｔＩｄ｜ｃ）とをクライアント装置１２０に送付する。
［ステップ３］：（９０９，９１０，９１１）クライアント装置１２０（Ａ）は、アプリケーション設定データ中に指定されているアプリケーション装置１３０の公開鍵Ａを取り出し、
【数３１】
ｋ’＝ξ（ｗＡ）
によりメッセージ認証鍵ｋ’を計算する。次いで、
【数３２】
ＭＡＣ（ｋ，“ｔｒａｎｓｆｅｒ”｜ＣｌｉｅｎｔＩｄ｜ｃ）
＝ＭＡＣ（ｋ’，“ｔｒａｎｓｆｅｒ”｜ＣｌｉｅｎｔＩｄ｜ｃ）を検査し、検査が成功しなかった場合、以後の処理を行わない。
また、ＡｐｐｌＤｅｆを参照し、公開鍵Ａに対応付けられているアプリケーション装置に電子チケットを譲渡する特権が付与されているか検査する。特権が付与されていない場合には、以後の処理を行わない。
［ステップ４］：（９１２）クライアント装置１２０（Ａ）はＣｌｉｅｎｔＩｄを外部特定情報保持手段１２９に保持する。
［ステップ５］：（９１３，９１４）クライアント装置１２０（Ａ）は、差分データ生成手段１２８に外部特定情報保持手段１２９が保持している外部のクライアント装置１２０（Ｂ）の特定情報を入力する。差分データ生成手段１２８は、電子チケット生成装置とクライアント装置との間で行う鍵共有と同じ方法で、外部のクライアント装置１２０（Ｂ）との間の共有鍵Ｋ_１を生成し、次式により差分データΔを計算する。
【数３３】
Δ＝Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ_１）
−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）
［ステップ６］：（９１５，９１６，９１７）クライアント装置１２０（Ａ）は、
【数３４】
ｒ＝Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）ｃ＋ｗ
を計算し、アプリケーション装置１３０に送付する。同時に、共有鍵保持手段１２６に保持されている共有鍵Ｋを消去し、電子チケットを無効化する。
［ステップ７］：（９１８）アプリケーション装置１３０は、楕円曲線Ｅの上で
【数３５】
（ｃＴ＋ｒ）Ｇ＝ｃＳ＋Ｗ
が成立することを検査する。
【０１５９】
差分データΔは、オリジナルの電子チケット鍵ｔ
【数３６】
ｔ＝ｓ−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）
から、新たな電子チケットｔ_１を生成する目的で使用される。すなわち、
【数３７】
ｔ_１＝ｔ＋Δ
＝ｓ−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）＋Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ_１）
−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）
＝ｓ−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ_１）
は、クライアント装置１２０（Ｂ）が計算可能な共有鍵Ｋ_１による新たな電子チケットである。共有鍵Ｋ_１は、外部のクライアント装置１２０（Ｂ）の共有鍵保持手段によって保持されるため、アプリケーション装置１３０は、電子チケット鍵ｔ_１に基づいて、クライアント装置１２０（Ｂ）と通信することで、クライアント装置１２０（Ｂ）を所有するユーザが該サービスに対するアクセス権を保持していることを検査することができるようになる。
【０１６０】
前記の新たな電子チケット鍵の計算は、いかなる方法で実行してもよい。たとえば、以下のような構成が可能である。
【０１６１】
１、クライアント装置１２０が通信データｒとともにアプリケーション装置１３０に送付し、アプリケーション装置１３０が新たな電子チケット鍵ｔ_１を計算する。アプリケーション装置は、ユーザのアクセス権を認証するために電子チケット鍵ｔＴを保持しているので、新たな電子チケット鍵ｔ_１の計算を実行することができる。
【０１６２】
２、クライアント装置１２０がスマートカードのような可搬型デバイスである場合、電子チケットをクライアント装置に記録して携行する態様はきわめて自然である。このようなケースでは、クライアント装置１２０が新たな電子チケット鍵ｔ_１Ｔ_１を計算することが可能である。
【０１６３】
［分割の具体例］
Ｓｃｈｎｏｒｒ零知識識別アルゴリズムに基づく実施例を例にとり、分割のコマンドの発行・受理・実行の手順に関し、図１９の記載に従って述べる。
【０１６４】
クライアント装置１２０は、差分データ生成手段１２８を含む。
【０１６５】
［ステップ１］：（１００１，１００２，１００３）クライアント装置１２０は、基点Ｇの位数より小さい乱数ｗを生成し、楕円曲線Ｅ上の点Ｗ＝ｗＧを計算して、アプリケーション装置１３０に送付する。
【０１６６】
［ステップ２］：（１００４，１００５，１００６，１００７，１００８）アプリケーション装置１３０は、乱数ｃを生成するとともに、メッセージ認証鍵ｋをｋ＝ξ（ａＷ）により計算する。
更に、電子チケットの分割コマンドはコマンド名“ｄｉｖｉｄｅ”と分割後の電子チケットの定義データを与える二つのパラメータＴｃｋｔＤｅｆ１及びＴｃｋｔＤｅｆ２とから構成される。アプリケーション装置１３０は上とコマンドと乱数ｃを合わせてメッセージとし、ｋを鍵としてメッセージ認証コード（ＭＡＣ、Ｍｅｓｓａｇｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｃｏｄｅｓ）
【数３８】
ＭＡＣ（ｋ，“ｄｉｖｉｄｅ”｜ＴｃｋｔＤｅｆ１｜ＴｃｋｔＤｅｆ２｜ｃ）
を計算し、“ｄｉｖｉｄｅ”とＴｃｋｔＤｅｆ１とＴｃｋｔＤｅｆ２ｃとＭＡＣ（ｋ，“ｄｉｖｉｄｅ”｜ＴｃｋｔＤｅｆ１｜ＴｃｋｔＤｅｆ２｜ｃ）とをクライアント装置１２０に送付する。
【０１６７】
［ステップ３］：（１００９，１０１０，１０１１）クライアント装置１２０は、アプリケーション設定データ中に指定されているアプリケーション装置１３０の公開鍵Ａを取り出し、ｋ’＝ξ（ｗＡ）によりメッセージ認証鍵ｋ’を計算する。次いで、
【数３９】
ＭＡＣ（ｋ，“ｄｉｖｉｄｅ”｜ＴｃｋｔＤｅｆ１｜ＴｃｋｔＤｅｆ２｜ｃ）
＝ＭＡＣ（ｋ’，“ｄｉｖｉｄｅ”｜ＴｃｋｔＤｅｆ１｜ＴｃｋｔＤｅｆ２｜ｃ）
を検査し、検査が成功しなかった場合、以後の処理を行わない。
また、ＡｐｐｌＤｅｆを参照し、公開鍵Ａに対応付けられているアプリケーション装置に電子チケットを分割する特権が付与されているか検査する。特権が付与されていない場合には、以後の処理を行わない。
【０１６８】
［ステップ４］：（１０１２，１０１３）クライアント装置１２０は、差分データ生成手段１２８にコマンドのパラメータＴｃｋｔＤｅｆ１とＴｃｋｔＤｅｆ２とを入力する。差分データ生成手段１２８は、新たな共有鍵Ｋ_１とＫ_２とを生成し、次式により差分データΔ_１及びΔ_２を計算する。
【数４０】
Δ_１＝Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ１｜Ｋ_１）−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）
Δ_２＝Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ２｜Ｋ_２）−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）
【０１６９】
［ステップ５］：（１０１４，１０１５）クライアント装置１２０は、
【数４１】
ｒ＝Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）ｃ＋ｗ
を計算し、アプリケーション装置１３０に送付する。
【０１７０】
［ステップ６］：（１０１６，１０１７）共有鍵保持手段１２６に保持されている共有鍵Ｋを消去し、電子チケットを無効化するとともに、共有鍵Ｋ_１とＫ_２とを共有鍵保持手段１２６に記録する。
【０１７１】
［ステップ７］：（１０１８）アプリケーション装置１３０は、楕円曲線Ｅの上で
【数４２】
（ｃｔ＋ｒ）Ｇ＝ｃＳ＋Ｗ
が成立することを検査する。
差分データΔ_１及びΔ_２は、オリジナルの電子チケット鍵ｔ
【数４３】
ｔ＝ｓ−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）
から、新たな電子チケット鍵ｔ_１を生成する目的で使用される。すなわち、
【数４４】
ｔ_１＝　　　ｔ＋Δ_１
＝ｓ−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）＋Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ１｜Ｋ_１）
−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）
＝ｓ−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ１｜Ｋ_１）
ｔ_２＝　　　ｔ＋Δ_２
＝ｓ−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）＋Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ２｜Ｋ_２）
−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）
＝ｓ−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ２｜Ｋ_２）
は、クライアント装置１２０の共有鍵保持手段１２６に保持されている共有鍵Ｋ_１とＫ_２による新たな電子チケットである。
【０１７２】
［変更の具体例］
Ｓｃｈｎｏｒｒ零知識識別アルゴリズムに基づく実施例を例にとり、変更のコマンドの発行・受理・実行の手順に関し、図２０の記載に従って述べる。
【０１７３】
クライアント装置１２０は、差分データ生成手段１２８を含む。
【０１７４】
［ステップ１］：（１１０１，１１０２，１１０３）クライアント装置１２０は、基点Ｇの位数より小さい乱数ｗを生成し、楕円曲線Ｅ上の点Ｗ＝ｗＧを計算して、アプリケーション装置１３０に送付する。
【０１７５】
［ステップ２］：（１１０４，１１０５，１１０６，１１０７，１１０８）アプリケーション装置１３０は、乱数ｃを生成するとともに、メッセージ認証鍵ｋをｋ＝ξ（ａＷ）により計算する。
更に、電子チケットの変更コマンドはコマンド名“ｍｏｄｉｆｙ”と変更後の電子チケットの定義データを与えるパラメータＴｃｋｔＤｅｆ１とから構成される。アプリケーション装置１３０は上とコマンドと乱数ｃを合わせてメッセージとし、ｋを鍵としてメッセージ認証コード（ＭＡＣ、Ｍｅｓｓａｇｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｃｏｄｅｓ）
【数４５】
ＭＡＣ（ｋ，“ｍｏｄｉｆｙ”｜ＴｃｋｔＤｅｆ１｜ｃ）
を計算し、“ｍｏｄｉｆｙ”とＴｃｋｔＤｅｆ１とｃとＭＡＣ（ｋ，“ｍｏｄｉｆｙ”｜ＴｃｋｔＤｅｆ１｜ｃ）とをクライアント装置１２０に送付する。
【０１７６】
［ステップ３］：（１１０９，１１１０，１１１１）クライアント装置１２０は、アプリケーション設定データ中に指定されているアプリケーション装置１３０の公開鍵Ａを取り出し、ｋ’＝ξ（ｗＡ）によりメッセージ認証鍵ｋ’を計算する。次いで、
【数４６】
ＭＡＣ（ｋ，“ｍｏｄｉｆｙ”｜ＴｃｋｔＤｅｆ１｜ｃ）＝ＭＡＣ（ｋ’，ｍｏｄｉｆｙ”｜ＴｃｋｔＤｅｆ１｜ｃ）
を検査し、検査が成功しなかった場合、以後の処理を行わない。
また、ＡｐｐｌＤｅｆを参照し、公開鍵Ａに対応付けられているアプリケーション装置に電子チケットを分割する特権が付与されているか検査する。特権が付与されていない場合には、以後の処理を行わない。
【０１７７】
［ステップ４］：（１１１２，１１１３）クライアント装置１２０は、差分データ生成手段１２８にコマンドのパラメータＴｃｋｔＤｅｆ１を入力する。差分データ生成手段１２８は新たな共有鍵Ｋ_１を生成し、次式により差分データΔ_１を計算する。
【数４７】
Δ_１＝Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ１｜Ｋ_１）−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）
【０１７８】
［ステップ５］：（１１１４，１１１５）クライアント装置１２０は、
【数４８】
ｒ＝Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）ｃ＋ｗ
を計算し、アプリケーション装置１３０に送付する。
【０１７９】
［ステップ６］：（１１１６，１１１７）共有鍵保持手段１２６に保持されている共有鍵Ｋを消去し、電子チケットを無効化するとともに、共有鍵Ｋ_１とＫ_２とを共有鍵保持手段１２６に記録する。
【０１８０】
［ステップ７］：（１１１８）アプリケーション装置１３０は、楕円曲線Ｅの上で
【数４９】
（ｃｔ＋ｒ）Ｇ＝ｃＳ＋Ｗ
が成立することを検査する。
【０１８１】
差分データΔ_１は、オリジナルの電子チケット鍵ｔ
【数５０】
ｔ＝ｓ−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）
から、新たな電子チケット鍵ｔ_１を生成する目的で使用される。すなわち、
【数５１】
ｔ_１＝ｔ＋Δ_１
＝ｓ−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）＋Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ１｜Ｋ_１）
−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）
＝ｓ−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ１｜Ｋ_１）
は、クライアント装置１２０の共有鍵保持手段１２６に保持されている共有鍵Ｋ_１による新たな電子チケット鍵である。
【０１８２】
［操作に関連する属性とその変更ルール］
電子チケットに記述可能な属性として、該電子チケットによるリソース及びサービスへのアクセスに関する有効期限及び有効回数を指定できることは、先述の実施例において述べた。
【０１８３】
本実施例では、有効回数属性の管理方法を述べる。
【０１８４】
アプリケーション装置１３０が、有効回数属性に値が指定されている電子チケットを検査し、その結果として、ユーザにサービスを提供する場合には、図２１に記載の手順で処理を行う。
【０１８５】
［ステップ１］：（１２０１，１２０２）アプリケーション装置１３０は、クライアント装置１２０との通信の過程において、現在の電子チケットの有効回数属性に指定されている値から１減じた値を有効回数属性にもつ電子チケットの定義データＴｃｋｔＤｅｆ１を引数として、コマンド“ｍｏｄｉｆｙ”をクライアント装置１２０に発行する。
【０１８６】
［ステップ２］：（１２０３，１２０４，１２０５，１２０６）クライアント装置１２０は、例えば、先に述べた実施例での方法に従って、アプリケーション装置１３０を認証したあと、現在の電子チケットを無効化し（対応する共有鍵を消去し）、次いで、ＴｃｋｔＤｅｆ１をチケット定義として持つ新たな電子チケット鍵ｔ_１と現在の電子チケット鍵ｔとの差分データΔ_１を計算して、アプリケーション装置１３０への通信データの一部として送付する。
【数５２】
Δ_１＝Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ１｜Ｋ_１）−Ｈ_｜ｓ｜（ＡｐｐｌＤｅｆ｜ＴｃｋｔＤｅｆ｜Ｋ）
【０１８７】
［ステップ３］：（１２０７，１２０８）アプリケーション装置１３０は、クライアント装置１２０からの前記通信データに基づいて、電子チケット鍵ｔを検査し、検査が成功した場合に限り、新たな電子チケット鍵ｔ_１を
【数５３】
ｔ_１＝ｔ＋Δ_１
により生成する。電子チケット鍵ｔはクライアント装置１２０により無効化されており、かつ、電子チケット鍵ｔ_１は有効回数属性が１減じられているので、リソース或いはサービスへの有効アクセス回数が１度数費消されたことになる。
【０１８８】
同様の仕組で譲渡回数の上限を定める譲渡可能回数属性、分割可能回数属性等を、チケット定義に含めることができる。
【０１８９】
［操作の取り消し］
電子チケットに対する無効化、譲渡、分割、及び、変更の操作を行った後、アプリケーションからの指示によりこれらの操作を取り消す機能の実施例を、これまでに述べた無効化、譲渡、分割、及び、変更の実施例に基づいて述べる。
【０１９０】
無効化、譲渡、分割、及び、変更の実施例では、クライアント装置１２０は、認証情報として共有鍵保持手段１２６に保持されている共有鍵を消去することで、操作前の電子チケットを無効化していた。
【０１９１】
以下で図２２に記載の操作の取り消し実現する実施例では、クライアント装置１２０は、共有鍵退避手段１２６’を含む。
【０１９２】
［ステップ１］：（１３０１）クライアント装置１２０が、操作前の電子チケットを無効化する際には、共有鍵保持手段１２６に保持されている共有鍵を消去する前に、該共有鍵を共有鍵退避手段１２６’に記憶する。
【０１９３】
［ステップ２］：（１３０２，１３０３）アプリケーション装置１３０が、コマンド発行手段１３６により、操作の取り消しコマンド“ｒｅｓｕｍｅ”を発行すると、クライアント装置１２０はコマンド受理手段において同コマンドを解釈し、その後、共有鍵退避手段１２６’に記録されている操作前の共有鍵を取り出し、共有鍵保持手段１２６に記録する。
【０１９４】
［ステップ３］：（１３０４）加えて、電子チケットに対する前記操作によって、新たに生成された共有鍵が共有鍵保持手段１２６に保持されている場合には、共有鍵保持手段１２６中から該共有鍵を消去する。同共有鍵を、共有鍵退避手段１２６’に記録した後に、共有鍵保持手段１２６から消去する実装様態でもよい。
【０１９５】
以上の手順により、クライアント装置１２０は、操作前の電子チケットに付随する共有鍵を用いて通信を行うことが可能となり、アプリケーション装置１３０による該操作の効果を取り消し、操作前の電子チケットを再度有効にすることが可能となる。
【０１９６】
［実施例２：ビジネスモデルの実現］
以下では、本発明における電子チケットの無効化、譲渡、分割、変更の機能を用いて、アクセス権の表現である電子チケットの様々な流通フローを実現する実施例を示す。
【０１９７】
［再販モデル］
再販モデルとは、サービスの所有者であるサービスプロバイダがエンドユーザに対して電子チケットを販売するにあたり、サービスプロバイダとエンドユーザとの間に複数の流通業者が存在するモデルである。
【０１９８】
図２３は、再販モデルの流通フローを示す構成図であり、１４０１はサービスを所有するサービスプロバイダ、１４０２は卸業者、１４０３はエンドユーザに利用権を販売する小売業者、１４０４は最終的なエンドユーザである。
【０１９９】
卸業者１４０２は、サービスプロバイダ１４０１から電子チケットの形でサービスを購入し、小売業者１４０３に転売する。
【０２００】
また、サービスプロバイダ１４０１は卸業者１４０２から、卸業者１４０２は小売業者１４０３から、売れ残りの電子チケットの返品も受付けることができる。
【０２０１】
図２４は、具体的な例に基づいた、電子チケットの流通のフロー図である。
【０２０２】
［ステップ１］：（１５０１）サービスプロバイダ１４０１は卸業者１４０２に１つの電子チケットを出荷する。該電子チケットは、サービスプロバイダ１４０１が提供するサービスに対するアクセス権を表現しており、更に、該電子チケットに対する分割操作回数の上限が属性（分割可能回数属性）として記述される。例えば、前記分割可能回数属性に１００が指定されたときは、該電子チケットを１００回分割することができる、言い換えると、分割して最大１００人のエンドユーザに販売することができることを意味する。
【０２０３】
［ステップ２］：（１５０２）小売業者１４０３から注文を受けると、卸業者１４０２は前記電子チケットを２つに分割し（分割操作）、その一方を小売業者に譲渡する（譲渡操作）。例えば、小売業者１４０３からの注文が「３０人分の電子チケット」である場合、分割された一方の電子チケットの分割可能回数属性には１００−３０＝７０が指定され、他方の電子チケットの分割可能回数属性には３０が指定される。卸業者は後者の電子チケットを小売業者に販売（譲渡）し、７０が分割可能回数属性に指定された電子チケットを手許に残す。前述のように、電子チケットの分割操作と譲渡操作とは、卸業者１４０２が所持するクライアント装置とアプリケーション装置とにより、サービスプロバイダ１４０１を介在させることなく実行される。
【０２０４】
［ステップ３］：（１５０３）小売業者１４０３によるエンドユーザ１４０４への電子チケットの販売も、電子チケットに対する分割操作と譲渡操作により実行される。小売業者１４０３は、エンドユーザ１４０４の注文を受けて、所有する電子チケットを２分割する。小売業者１４０３はそのうち１つを保持し、もう一方を顧客であるエンドユーザ１４０４に譲渡する。小売業者１４０３が手許に残す電子チケットの分割可能回数属性には、分割前の電子チケットの分割可能回数属性に指定される値から１減じた値が指定される。一方、エンドユーザ１４０４に譲渡される電子チケットの分割可能回数属性には０が指定され、エンドユーザ１４０４にはそれ以上電子チケットを分割することは許されない。前記、電子チケットに対する分割操作と譲渡操作は、サービスプロバイダ１４０１及び卸業者１４０２を介在させることなく、小売業者１４０３が所持するクライアント装置とアプリケーション装置とによって実行される。
【０２０５】
［ステップ４］：（１５０４，１５０６）卸業者１４０２は、更に、別の小売業者１４０３に「５０人分の電子チケット」を販売し、総計で９０人分のアクセス権に相当する電子チケットを販売したところで、それ以上の販売を断念するものとする。卸業者１４０２の手許には分割可能回数属性に値１０が指定された有効な電子チケットが残されており、卸業者１４０２は該電子チケットをサービスプロバイダ１４０１に該電子チケットを「返品」して、払い戻しを受ける。この返品操作は、売れ残った該電子チケットをサービスプロバイダ１４０１に譲渡することで（譲渡操作）実行される。卸業者１４０２が小売業者１４０３に電子チケットを販売する過程で過渡時に所持する電子チケット、即ち、分割可能回数属性にそれぞれ１００及び７０が指定されている電子チケットは、販売による分割操作後、アプリケーション装置とクライアント装置により無効化されているため（無効化操作）、これらの電子チケットをサービスプロバイダ１４０１に対して返品することはできない。正確にはサービスプロバイダ１４０１は、返品された該電子チケットを検査することで、無効化された要ることを検知できる。アプリケーション装置は、譲渡操作において譲渡対象となる電子チケットの検査を実行するため、無効化された電子チケットに対して譲渡操作を実行すると、無効化されていることがアプリケーション装置によって検知されるからである。
【０２０６】
［ステップ５］：（１５０７，１５０８）サービスプロバイダ１４０１は、譲渡された電子チケットを、自らの所有するクライアント装置及びアプリケーション装置を用いて検査する。検査が成功しなかった場合には、該電子チケットの受理を拒否し、返品を受け付けない。検査に成功した場合には、該電子チケットの分割可能回数属性に指定された値を見て、該値に相当する電子チケットの返品を受理し、払い戻しを行う。例えば、該分割可能回数属性に１０が指定されている場合、サービスプロバイダ１４０１は１０個分の電子チケットの代金を卸業者１４０２に払い戻す。
【０２０７】
［ピア・ツー・ピアモデル］
インターネットによるデジタルコンテンツ流通の普及に伴い、ピア・ツー・ピアによる新しいコンテンツ配信モデルが注目されるようになってきた。ピア・ツー・ピアモデルは、「私的使用に限定したコピーの作成権」を根拠に、デジタルコンテンツの購買者がデジタルコンテンツのコピーを配信する流通モデルである。ただし、消費者間でのコンテンツのコピーが無制限に実行されると、コンテンツの著作者の権利を著しく侵害することから、ピア・ツー・ピアモデルを実現するにあたっては、消費者にコンテンツ著作者の意図した範囲でのみ、コンテンツのコピーと配布を許すシステム的な保証が必要となる。
【０２０８】
ここでは、本発明における電子チケットに対する、無効化、譲渡、分割、変更の機能を用いて、ピア・ツー・ピアモデルを実現する実施例を示す。
【０２０９】
図２５は、実施例の構成図、図２６は実施例のフロー図である。以下、図２６に従って説明する。
【０２１０】
前提として、コンテンツの著作者は、コンテンツを暗号化して配布する。コンテンツは暗号化されたままでは再生することができないので、暗号化コンテンツの配布に何らの制限を加える必要はない。例えば、暗号化コンテンツを、公開されたダウンロードサイトにアップロードして、任意のユーザに自由にダウンロードすることを許すこともできる。
【０２１１】
コンテンツの販売とアクセス制御は、正当な対価を支払った消費者ユーザに対して、電子チケットを発行することで実現する。
【０２１２】
この場合、アプリケーション装置は、暗号化コンテンツを復号して、再生する能力を有し、例えば、パーソナルコンピュータ上で動作するコンテンツプレイヤプログラムや専用の再生端末のような実現となる。いずれの実装においても、アプリケーション装置は、ユーザが保有するクライアント装置と通信して電子チケットを検査し、検査に合格した場合に限り、コンテンツを復号して、再生する。このとき、先述の実施例で示したように、電子チケットの検査の結果として、コンテンツそのものやコンテンツを復号するための鍵が得られるような構成とすれば、検査ルーチンをバイパスするような攻撃に対しても安全となる。
【０２１３】
［ステップ１］：（１７０１）ユーザは、暗号化されたコンテンツを復号し、再生するためのアクセス権として電子チケットを購入する。電子チケットは分割可能回数属性を含み、電子チケットの販売者が該電子チケットの販売時に値を指定する。この属性に指定される値は、該電子チケットの販売を受けたユーザがコンテンツの共有を許されるユーザ数の最大値である。例えば、コンテンツの共有が、電子チケットを購入したユーザを含めて６人まで許可されるのであれば、該電子チケットの分割可能回数属性には５が指定される。
【０２１４】
［ステップ２］：（１７０２，１７０３）ユーザは、電子チケットを分割し、譲渡することで、他のユーザとコンテンツを共有する。アプリケーション装置は、まず、電子チケットの分割可能回数属性に指定されている値を検査し、値が０であれば処理を中止する。次いで、クライアント装置と通信して、電子チケットの検査を行い、電子チケットに指定された属性、就中、該分割可能回数属性の値が改竄されていないことを確認する。改竄が検知された場合は、処理を中止する。
【０２１５】
［ステップ３］：（１７０４）アプリケーション装置は、クライアント装置に分割コマンドを発行し、電子チケットを二つに分割する。分割された電子チケットの一方は、分割可能回数属性に、分割前の前記電子チケットの分割可能回数属性に指定されていた値から１減じた値をもち、他方は、分割可能回数属性に値０を持つ。引き続いて、アプリケーション装置は、譲渡先のユーザが有するクライアント装置の特定情報を指定して、クライアント装置に譲渡コマンドを発行する。該コマンドによって譲渡される電子チケットは、その分割可能回数属性に値０が指定されている電子チケットである。例えば、分割前の電子チケットの分割可能回数属性に５が指定されている場合、分割後、該ユーザの手許に残され、利用が可能な電子チケットの分割可能回数属性には４が指定されており、譲渡される電子チケットの分割可能回数属性には０が指定される。
【０２１６】
［ステップ４］：（１７０５）譲渡先のユーザは、前記譲渡された電子チケットを、電子メールなど任意の手段で受け取る。該ユーザは、該電子チケットを使って、コンテンツを再生することができる。しかし、該電子コンテンツの分割可能回数属性には０が指定されているため、該電子チケットを分割して、他のユーザとコンテンツを共有することはできない。
【０２１７】
［モニタリング］
電子チケットの仕組みを用いて、デジタルコンテンツの無料プロモーションを行う例を説明する。
【０２１８】
図２７は、この実施例の説明図である。
【０２１９】
本実施例では、ある音楽レーベルが新人バンドのプロモーションとして、インターネット上で楽曲の電子データを公開し、ユーザによるダウンロード、さらにユーザ間の自律的な配布によって、低コストで認知拡大を図るキャンペーンを実施する場合を想定する。
【０２２０】
このキャンペーンへのリスナーの参加を促すため、曲を最も多く再配布したユーザに賞を与えることとし、この再配布数の正確な把握のために電子チケットを利用する。
【０２２１】
ここで、電子チケットには２種類ある。即ち、通常の再生権のみを持つ電子チケットと、自身が再配布権を持ち、他人に対して再生権を持つ電子チケットばかりでなく、再配布権も持つ電子チケットも発行可能な権利を持つ電子チケットである。
【０２２２】
前者は、単純なリスナーであり、指定された回数の再生のみが許されている。後者は、このキャンペーンにおいて、プロモータの役割を果たすユーザであり、彼らが発行した再生権チケット、換言するならば楽曲を聞かせたリスナーの数が賞の対象となる仕組みである。
【０２２３】
図２８は実施例のフロー図である。以下、図２８に従って説明する。
【０２２４】
［ステップ１］：（１９０１）音楽レーベルは、コンテンツを暗号化して配布する。これは正しいアプリケーションと正しい電子チケットの組合せによってのみ復号可能である。
【０２２５】
［ステップ２］：（１９０２）楽曲にアクセスしたユーザには、分割可能回数属性にＮの指定された電子チケットが発行される。また、この電子チケットには、新たに電子チケットを生成できる権利（分割）が属性設定される。
【０２２６】
［ステップ３］：（１９０３）ユーザが電子チケットを分割して、他のユーザに発行するたびに、手元に残される電子チケットの分割可能回数が１ずつ減算される。この時、再配布権つきの電子チケットに設定される分割可能回数は、分割元の分割可能回数の現在値によらず一定である。
【０２２７】
［ステップ４］：（１９０４）再配布権付電子チケットを持つユーザは、再配布権を持たない再生権のみの電子チケットを発行することも可能である。この時の再生権は一定回数以下あるいはキャンペーン期間のみといった期日指定とすることも可能である。
【０２２８】
［ステップ５］：（１９０５）こうして何回かのチケット分割を繰り返したのち、キャンペーン期間が終了する。この時、賞に応募するには、有効な最新の電子チケットを音楽レーベルに返送（譲渡）するだけでよい。
【０２２９】
［ステップ６］：（１９０６）返送された電子チケットには、元の分割可能回数Ｎから分割した回数だけ減算された回数が分割可能回数として設定されている。従って、音楽レーベルは所定の認証手続きに従って電子チケットを検査することで、ユーザによる電子チケットの再配布数を把握する。
【０２３０】
ここでより詳しい分割の状況として、再配布先や時刻をモニタしたい場合には、ユーザの手許でローカルに蓄積されたログを電子チケットと同時に音楽レーベルに送付するような設定も可能である。その場合には、ログデータを電子チケットの属性として指定し、電子チケットを認証すると同時にログが改竄されていないことを検証することができる。
【０２３１】
［チェックイン、チェックアウトモデル］
デジタルコンテンツなどの利用において、据付型の機器から、携帯型の機器に対して、利用権の一時的な移動が必要な場合がある。
【０２３２】
このような場合における電子チケットの実施例を説明する。
【０２３３】
図２９は、本実施例の構成図である。チケット発行元から発行された電子チケットは据付型の機器Ａに格納されている。
【０２３４】
図３０は、本実施例に基づく据付型機器へ利用権の移動・回収の動作フロー図である。以下、図３０に従って、説明する。
【０２３５】
［ステップ１］：（２１０１）コンテンツプロバイダは、対象となるユーザに帰属する据付型機器に対して、当該コンテンツの利用権を発行する。これには、オンデマンドでのライセンス発行でも良いし、予めコンテンツに一定条件の利用権を同梱しておいても良い。またこの電子チケットには、分割可能な権利を付与する。
ユーザは、入手した利用権を元に据付型機器上のビューワでコンテンツの再生などをすることができる。
【０２３６】
［ステップ２］：（２１０２）据付型機器上のクライアント装置は、利用権操作アプリケーションから電子チケットの転送要求を受ける。
【０２３７】
［ステップ３］：（２１０３）まず、要求のあった電子チケットが譲渡可能なものであるか検査し、譲渡不可能な場合は以降の処理を中止する。
【０２３８】
［ステップ４］：（２１０４）ついで、利用権操作アプリケーションを認証する。認証に失敗すると以降の処理を中止する。
【０２３９】
［ステップ５］：（２１０５，２１０６，２１０７）電子チケットの譲渡の手続きに従って、新たな電子チケットを生成し、携帯型機器に転送する。据付型機器の電子チケットは転送後、無効化される。なお、利用権は元々のコンテンツプロバイダから与えられた権利に基づいて、そのまま残しておくこともできる。
【０２４０】
［ステップ６］：（２１０８）ユーザは、携帯機器上のビューワを用いて、コンテンツの再生をできる。しかし、他の機器に利用権を譲渡したり、分割することは許可されない。
【０２４１】
［ステップ７］：（２１０９，２１１０，２１１１，２１１２，２１１３）ユーザは、携帯機器上でのコンテンツの利用が終了した時点で、再び電子チケットの譲渡の手続きに従って、元の据付型機器に利用権を戻す。これで、据付型機器での再生が再び可能となる。携帯型機器に転送する利用権に予め制限（利用回数制限、利用期間制限など）をつけることで、据付型機器への書き戻しをしない方式などもバリエーションとして考えられる。
【０２４２】
［複数アプリケーションから構成される「アプリケーション」の例（ＩＣカードによるチケッティング）］
ここでは、役割の異なる複数のアプリケーション装置が、協調して一貫したサービスを提供するとともに、クライアント装置が各々のアプリケーション装置に付与された特権（役割）を認証することで、不正なアプリケーション装置による電子チケットの不正操作を防止する実施例を示す。
【０２４３】
図３１は、構成図であり、ＩＣカードによって実現されるクライアント装置２２０１に格納された電子チケットに対して、電子チケットの確認を行うユーザ端末２２０２、譲渡・分割・変更などの操作を行う操作端末２２０３、および電子チケットの検証を行う検証器２２０４から構成されている。
【０２４４】
ユーザ端末２２０２は、例えば、ユーザのパーソナルコンピュータの上で動作するアプリケーションプログラムとして実現されたり、また、液晶画面を備えたキーホルダー型のＩＣカードリーダライタとして実現されたりする。ユーザ端末２２０２は、電子チケットを検査して、検査された電子チケットが有効であるか否かを表示するとともに、電子チケットに含まれる属性のうちから必要な項目を選択して表示する。ユーザは、ユーザ端末２２０２の画面上で、一義的には購入した電子チケットが正しく生成されていることを確認し、二義的には何のための電子チケットであるかを確認する。ユーザ端末には、電子チケットに対する無効化、譲渡、分割、変更の操作を行う特権が与えられない。
【０２４５】
一方、操作端末２２０３は、駅や店舗に設置される端末であり、ユーザはこの端末を用いて、電子チケットに対する無効化、譲渡、分割、変更の諸操作を伴う種々の操作を行う。
【０２４６】
例えば、ユーザが一度購入した電子チケットを別のユーザに譲渡したい時、また、ユーザが代表してまとめて買った電子チケットを分割して別のユーザに渡したい時などに、この操作端末２２０３を利用する。
【０２４７】
操作端末２２０３には、電子チケットに対する無効化、譲渡、分割、変更の操作を実行する（クライアント装置２２０１に対して指示する）特権が付与されている。そのため、操作端末２２０３の実装や運用には、ユーザ端末２２０２に比較してより厳重なセキュリティが必要とされ、ユーザのパーソナルコンピュータ上で動作するアプリケーションプログラムなどの形態ではなく、管理の行き届く専用端末として実現する。
【０２４８】
ＩＣカード２２０１に格納された電子チケットを、別のユーザに譲渡・分割する場合の操作を、図３２のフローチャートに従って説明する。
【０２４９】
［ステップ１］：（２３０１）譲渡・分割対象となる電子チケットの格納されているＩＣカードを操作端末に装着する。この時、ＩＣカード内の電子チケットの内容がディスプレイに表示される。
［ステップ２］：（２３０２）譲渡・分割する電子チケットを選択する。
［ステップ３］：（２３０３）譲渡・分割の詳細条件を入力する。例えば、操作が譲渡なのか分割なのかの指示、分割である場合何枚と何枚とに分割するかなどの指示を、このステップで行う。
［ステップ４］：（２３０４）譲渡・分割先のＩＣカードを操作端末に読ませる。ＩＣカードが非接触型インターフェースを備えている場合、複数のＩＣカードを同時に読ませることが可能となる。
［ステップ５］：（２３０５）譲渡分割条件と譲渡・分割先を確認の上、譲渡・分割操作を実行する。
［ステップ６］：（２３０６）他に譲渡・分割対象の電子チケットがあれば、ステップ２に戻る。
［ステップ７］：（２３０７）２枚のＩＣカードを操作端末から抜くことでアプリケーションは終了する。
【０２５０】
検証器２２０４は、駅の改札やイベント会場の入り口に設置される機器であり、電子チケットを検査して、ユーザに対してサービスを提供することの可否を判断し、例えば、電子チケットが１回限りの使いきりのチケットである場合には検査後無効化し、回数券のように有効利用回数が指定されている場合には、チケット定義を変更して有効利用回数属性の値を１減じる操作を行う。
【０２５１】
このように、電子チケットを用いたデジタルチケッティングにおいて、それぞれの役割を持つ複数のアプリケーション装置が協調して、全体のサービスを構成する。セキュリティの観点からいえば、不正なアプリケーション装置が不正な処理を行わないようアプリケーションの認証を行うとともに、それぞれのアプリケーション装置に許される特権を認証する必要がある。
【０２５２】
本実施例では、アプリケーション装置に関わる種々の設定を定義するアプリケーション設定データと、該アプリケーション設定データに依存して生成される電子チケットと、アプリケーション装置の認証を実行するクライアント装置によって、上記機能を実現する。
【０２５３】
具体的には、アプリケーション設定データは、次のように定義される。
【数５４】

【０２５４】
上記の例では、ユーザ端末は、ＵｓｅｒＴｅｒｍで名前が与えられる＜Ａｐｐｌｉｃａｔｉｏｎ＞要素で定義が与えられ、＜Ｐｒｉｖｉｌｅｇｅ＞要素が空であることで特権が付与されていないことが規定される。＜ＰｕｂＫｅｙ＞要素ではユーザ端末を認証する際に用いる公開鍵がＢａｓｅ６４に従って指定される。
【０２５５】
クライアント装置は、前記実施例に示したように、公開鍵を用いてアプリケーション装置を認証し、また、該アプリケーション装置から操作コマンドが発行された場合、＜Ｐｒｉｖｉｌｅｇｅ＞要素を参照して、指示された操作を行う特権を該アプリケーション装置が有しているかを確かめる。
【０２５６】
［複数アプリケーションから構成される「アプリケーション」の例（家電製品の制御）］
本実施例では、家庭内ネットワーク上に接続された家電製品などの制御に電子チケットを用いる例を説明する。
【０２５７】
図３３は、その構成例である。この図において、２４１０は、ホームサーバーであり、電子チケットを発行するともに、公衆回線と家庭内のネットワークのハブとして、各個別家電製品とクライアントの認証を仲介する。
【０２５８】
２４２０は、外部から家庭内の家電製品を制御するクライアント装置となる携帯電話である。無論、携帯電話以外にもＰＤＡ，ＮｏｔｅＰＣなどであっても構わない。クライアント装置は、例えば公開鍵証明書などを送付することによって、ユーザへの帰属を明らかにし、他の権限をもたないユーザと区別される。
【０２５９】
２４３０，２４４０，２４５０，２４６０は、各個別家電製品であり、おのおの特定のサービスを提供するアプリケーションとして機能する。各家電製品はここではホームサーバーに特権などを記述したアプリケーション設定表を設置時に登録するものとする。
【０２６０】
１、ユーザは自宅のホームサーバに対して、電話あるいはメイルなどでアクセスし、電子チケットの発行要求を出す。
【０２６１】
２、ホームサーバはクライアントを認証し、正当なクライアントには所望の電子チケットを発行する。
ここで、ホームサーバーは管理下のクライアントおよび機器の権限についての情報を事前に蓄積しているので、正しい条件の電子チケットのみを発行できる。例えば、ビデオデッキの予約は家庭内の全員に可能だが、炊飯器の設定は特定の人間しかできないといったユーザごとアプリケーションごとの権利設定が可能となる。
【０２６２】
３、ユーザは、電子チケットの条件の許す範囲において、入手した電子チケットを使って、家庭内の家電製品を制御することができる。
具体的には、ユーザは入手した電子チケットをホームサーバーをゲートウェーとして、制御対象となる機器に送付する。例えば、ビデオデッキの予約設定、空調の調整、風呂への給湯、炊飯器の炊きあがり時間設定などである。
【０２６３】
［実施例３：完結したスキームの実施例］
［概要］
本発明に基づいたシステムにおける管理的ロールはクライアント配布者・アプリケーション管理者・電子チケット発行者の三者である。これらはそれぞれ独立なロールであり，さらに各ロールはそれぞれ複数の独立な主体が務めることができる。また逆に一つの主体が複数のロールを兼ねることもできる。
【０２６４】
システムにおける装置はクライアント装置・アプリケーション装置・電子チケット生成装置の三種類がある。
【０２６５】
クライアント装置は、クライアント配布者によって作成されユーザに配布される。典型的な実現としては、ＣＰＵの特殊機能、ＩＣカード、ＰＣカード、ＵＳＢ機器、携帯電話やＰＤＡ中の特殊モジュール等のハードウェア、或いは、ＯＳの特殊コンポーネント、ＰＣ上にインストールされるアプリケーションプログラム等のソフトウェアの形態をとる。ハードウェア、ソフトウェア、いずれの実装の場合であっても、ユーザが携帯するのに便利なもの、また、ユーザの身近にあるものが望ましい。
【０２６６】
本実施例では、クライアント装置は機能的には、電子チケット生成装置と通信を行い、電子チケット生成装置からユーザのアクセス資格を表現するデータとして電子チケットを取得する。また、アプリケーション装置と通信を行い、その電子チケットを用いてユーザのアクセス資格をアプリケーション装置に対して証明する。さらに、アプリケーション装置を介して他のクライアント装置と通信を行い、その電子チケットが許可する範囲で譲渡・分割を行うことによって、他のクライアント装置へチケットを発行したり、他のクライアント装置が保持する電子チケットの譲渡・分割によって生成された電子チケットを取得する。
【０２６７】
クライアント装置に仮定される性質はクライアント装置毎に異なるクライアント公開鍵が割り当てられていて、外部から観測不能な記憶領域（クライアント秘密鍵及びチケット共有値が格納される）及び計算環境を備えることである。
【０２６８】
アプリケーション装置はアプリケーション管理者によって作成されサービス提供におけるプラットフォーム乃至ゲートウェイとなる。典型的な実現としては、ハードウェアとして、改札などの条件的ゲート施設、カードリーダー、ＰＯＳ端末、各種コンテンツフォーマットに対応したセキュアコンテンツデバイス、また、ソフトウェアとして、ＰＣ上にインストールされた電子チケット管理ツール、各種コンテンツフォーマットに対応したセキュアコンテンツビューア、暗号の復号や署名生成を行うＰＫＩにおけるユーザの個人鍵処理モジュール等がある。いずれにせよ何らかの意味でユーザに条件的にサービスを提供するものならば何であっても構わない。つまり、任意の家電製品（有資格者には機能する）や任意のアプリケーションプログラム（有資格者は起動できる）でも良い。
【０２６９】
アプリケーション装置は機能的にはクライアント装置と通信を行い、電子チケットを用いてユーザのアクセス資格を認証してサービスを提供する。また、さらに他のクライアント装置と通信を行い、その電子チケットが許可する範囲で譲渡・分割を行うことによって他のクライアント装置へ電子チケットを発行する。
【０２７０】
アプリケーション装置に仮定される性質はアプリケーション公開鍵が割り当てられていて、外部から観測不能な記憶領域（アプリケーション秘密鍵が格納される）及び計算環境を備え、ユーザのサービスに対するアクセス資格を検証するために、提供するサービスに対応するサービス公開鍵を少なくともサービス提供時に持つことである。
【０２７１】
電子チケット生成装置は電子チケット発行者によって使用され、ユーザの所持するクライアント装置向けに電子チケットを発行する。
【０２７２】
典型的な実現としては、家電製品の組み込みモジュールであっても良いし、ＰＣ上のアプリケーションプログラムでも良いし、また、多数のサービスを扱い多数のクライアントに対して大量にアクセス資格を発行する電子商取引サイトの機能であるならばデータベースを備えた大規模システムからなるものであっても良い。
【０２７３】
電子チケット生成装置は機能的にはクライアント装置と通信を行い、ユーザのアクセス資格を電子チケットとして発行する。
【０２７４】
電子チケット生成装置に仮定される性質はサービス公開鍵に対応するサービス秘密鍵を外部から観測不能な記憶領域に保持し、計算環境を備え、サービス公開鍵ペアが割り当てられている。
【０２７５】
［因数分解型の公開鍵暗号アルゴリズム］
多くの公開鍵暗号アルゴリズムにおける秘密鍵の属する空間は安全性を留保したまま公開可能なアーベル群であり、その群構造とアルゴリズムは親和性を持つ。例えば、素因数分解が困難な合成数ｎに対して、ＲＳＡにおける秘密鍵ｄは加法群Ｚの元と見なせ、Ｇｕｉｌｌｏｕ−Ｑｕｉｓｑｕａｔｅｒ認証における秘密鍵ｓは乗法群Ｇｍ（Ｚ／ｎＺ）の元と見なせる。また、素数位数ｐの基底Ｇが定められた離散対数問題が困難な群ＥにおけるＳｃｈｎｏｒｒ認証やＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵共有の秘密鍵ｘは加法群Ｇａ（Ｆｐ）の元である。
【０２７６】
［実施例３−１：ＲＳＡ公開鍵暗号に基づく実施例］
ここでは因数分解型の公開鍵暗号アルゴリズムに基づく本発明の実施例の一例として、ＲＳＡ公開鍵暗号に基づく構成を示す。
【０２７７】
クライアント配布者がクライアント鍵ペア（Ｔ，τ）を生成し、あるクライアント装置にＲＳＡ公開鍵（Ｔ，２^１６＋１）を割り当て、保護された記憶領域には対応する秘密鍵τを格納するものとする。つまりＴは素因数分解が困難な合成数で任意のｃ∈Ｇｍ（Ｚ／ＴＺ）に対して
【数５５】

となっている。
【０２７８】
また、サービスのオーナが同様にサービス鍵ペア（Ｓ，σ）を生成し、所有するあるサービスにＲＳＡ公開鍵（Ｓ，２^１６＋１）を割り当てるものとする。ここでＳ＜Ｔとする。
【０２７９】
σを知るサービスオーナが
１、ランダムにκ（チケット共有値）を生成する。チケット共有値とは、先術の実施例において、認証情報、或いは、共有鍵と呼ぶデータと一致する。
ただし０＜κ＜Ｓとする。
２、
【数５６】

（チケット共有値のクライアント公開鍵による暗号化）を計算する。
３、ｔ＝σ−κ（サービス秘密鍵とチケット共有値お差分）を計算する。
として、クライアント装置Ｔに（Ｉ，ｔ）を発行する。クライアント装置はＩを入力されると
１、
【数５７】

としてＩを復号する。
２、κを保護された記憶領域に格納する。
という電子チケットの登録作業を行うものとする。また、クライアント装置はｃ（ただし０＜ｃ＜Ｓ）を入力されると
１、ｒ＝ｃ^κｍｏｄ　Ｓを計算する。
２、ｒを出力する。
というレスポンス生成の機能も持つものとする。ｔ＋κ＝σであるからｃ^ｔｒｍｏｄ　Ｓ＝ｃ^σ　ｍｏｄ　Ｓであり、クライアント装置を保持しているユーザは電子チケットｔを用いることによってサービス秘密鍵σを知ることなくサービス秘密鍵σによる関数ｃ^σ　ｍｏｄ　Ｓを計算することができる。
【０２８０】
さらに電子チケット登録においてサービス鍵Ｓの識別子ｓ＝ｈ（Ｓ）を併せて入力することによって保護された記憶領域に（ｓ，κ）を格納するようにし、レスポンス生成においてサービス鍵Ｓを併せて入力し、対応するκを検索して利用するようにすれば、多数のサービス鍵に応じたレスポンス生成が行える。さらに、電子チケットに対して有効期限などを記述するチケット定義Ｄ（オクテット列として符号化されて表現されているものとする）という量を導入し、ｔ＝σ−ｈ_Ｓ（Ｄ｜ｋ）とすることによって電子チケットに対して有効期限などを設定することが可能である。ただし、ここで｜はオクテット列の連接を表しており、本実施例において、例えばここにおけるκのような数学的量には常に適当なオクテット列へのエンコードメソッドが用意されているものとしている。また、ｈ_Ｓ（Ｄ｜ｋ）は、サービス公開鍵Ｓに依存する一方向性及び非衝突性を満足するハッシュ関数であるとする。
【０２８１】
また電子チケット生成に先立って、クライアント装置がランダムなチケット要求鍵Ｒを生成するものとし、チケット共有値κがＲに依存するようにすることができる。一例として、サービスオーナがランダムにチケット共有値シードιを生成し、
【数５８】

とするなどの方法がある。チケット共有値κの生成にクライアント装置が内部で生成する乱数Ｒが関与するものとすると、クライアント装置のテーブルから一度消去されたチケット共有値κを再現することが不可能になる。この事実を利用して電子チケットの効果的な消去を実行できる。また、電子チケットの初期状態が再現できないというこの技法と秘密鍵の空間がアーベル群をなすことを組み合わせて、遷移型の電子チケットを定義することができる。電子チケット（Ｄ，ｔ）に対して異なるチケット定義を持つ電子チケットを生成するのに、以下のステップを実行する
【数５９】

【０２８２】
また、電子チケット（Ｄ，ｔ）を異なるクライアント装置用のものに変換する電子チケットの譲渡も以下のように実現できる。
１、譲渡先のクライアント装置からチケット要求鍵Ｒ’を取得する。
２、ランダムに新しいチケット共有値シードｔ’を生成する。
３、譲渡先のクライアント装置の公開鍵Ｔ’で共有値シードｔ’を暗号化し、それをＩ’とする。
【数６０】

４、譲渡先のクライアント装置におけるチケット共有値ｋ’を計算する。
【数６１】
ｋ’＝ｈ_Ｓ（ｉ’｜Ｒ’）。
５、チケット鍵の差分Δ’＝ｈ_Ｓ（Ｄ｜ｋ）−ｈ_Ｓ（Ｄ’｜ｋ’）を計算する。
６、クライアント装置のテーブルに格納するチケット共有値κを削除する。
７、譲渡先のクライアント装置用の新しいチケット鍵ｔ’＝ｔ＋Δ’を計算する。
８、（Ｉ’，Ｄ’，ｔ’）を電子チケットとして譲渡先のクライアント装置へ送付する。
譲渡先のクライアント装置が電子チケットの登録を行う方法はサービスオーナが生成した電子チケットを登録する方法と同一である。さらに、更新と譲渡を組み合わせることで電子チケットの分割も実現できる。
【０２８３】
電子チケットの更新が行えることから利用回数制限のような指定をチケット定義Ｄに含めることができる。これらの電子チケットに副作用を与えるような処理は任意の第三者が行えてはいけない。そこで、チケット定義中にこれらの指示を出すことができるアプリケーションの公開鍵を指定して、その公開鍵で検証できるような動作つまりアプリケーション秘密鍵の保持をテストするような動作を要求することによってクライアント装置がアプリケーションを認証し、これら特権を持ったアプリケーションのみがチケットへの副作用を及ぼす処理の指示が可能であるようにするべきである。電子チケットの更新・譲渡・分割は電子チケット認証と同期して行うこともできる。
【０２８４】
［実施例３−２：Ｇｕｉｌｌｏｕ−Ｑｕｉｓｑｕａｔｅｒ零知識認証に基づく実施例］
ここでは、因数分解型公開鍵暗号アルゴリズムに基づく実施例の第二として、Ｇｕｉｌｌｏｕ−Ｑｕｉｓｑｕａｔｅｒ零知識認証に基づいた実施例を述べる。
【０２８５】
以下でｐは共通の素数であり、公開されているものとする。
【０２８６】
クライアント配布者は、該クライアント配布者が配布するクライアント装置で共通に用いられる法数ｎを固定的に定める。Ｎは素因数分解の困難な合成数である。
【０２８７】
更に、クライアント配布者は、クライアント装置毎にＧｕｉｌｌｏｕ−Ｑｕｉｓｑｕａｔｅｒクライアント鍵ペア（Ｔ，τ）を生成し、Ｔを該クライアント装置の公開鍵として公開し、秘密鍵τをクライアント装置内の保護された記憶領域に格納する。即ち、
【数６２】
τ^ｐ＝Ｔ　ｍｏｄ　Ｎ
が成立する。
【０２８８】
一方、サービスオーナは公開の法数ｎと，任意のｃ∈Ｇｍ（Ｚ／ｎＺ）に対して
【数６３】
ｃ^ｐｃ−１＝ｃ　ｍｏｄ　ｎ
を満足するマスター鍵ｄを秘密裡に保持する。即ち、（ｐ，ｄ）は法数ｎに対応するＲＳＡ公開鍵暗号の公開鍵ペアとなる。
【０２８９】
更に、Ｇｕｉｌｌｏｕ−Ｑｕｉｓｑｕａｔｅｒサービス鍵ペア（Ｓ，σ）を
【数６４】
σ^ｐ＝Ｓ　ｍｏｄ　ｎ
を満足するように定める。
【０２９０】
本実施例では、クライアント装置が特定情報と認証情報を都度生成し、電子チケット生成装置に送付する。以下は、特定情報の計算手順である。
【０２９１】
［ステップ１］：サービス法数ｎ、及び、サービス公開鍵Ｓの入力を受け、サービス公開鍵識別子ｓ＝ｈ（ｎ，Ｓ）を計算する。
［ステップ２］：認証情報（共有鍵）κをランダムに生成し、（ｓ，κ）をクライアント装置内の保護された記憶領域に格納する。
［ステップ３］：乱数ε∈Ｇｍ（Ｚ／ｎＺ）を生成し、Ｇｕｉｌｌｏｕ−Ｑｕｉｓｑｕａｔｅｒ電子署名（ρ_０，ρ_１）を以下のように生成する。
【数６５】
ρ_０＝ε^ｐ　ｍｏｄ　ｎ
ρ_１＝ετ^{ｈ（ρ０κ}　ｍｏｄ　ｎ
【０２９２】
［ステップ４］：κをＲＳＡ公開鍵暗号の公開鍵（ｐ，ｎ）で暗号化し、（κ^ｐ
ｍｏｄ　ｎ，ρ_０，ρ_１）を特定情報として出力する。
【０２９３】
電子チケット生成装置は、特定情報（κ^ｐ　ｍｏｄ　ｎ，ρ_０，ρ_１）、クライアント公開鍵Ｔ、及び、チケット定義ＴｃｋｔＤｅｆを入力として、以下の手順で電子チケットを生成する。
【０２９４】
［ステップ１］：マスター鍵ｄにより、κを復号する。
［ステップ２］：Ｇｕｉｌｌｏｕ−Ｑｕｉｓｑｕａｔｅｒ電子署名（ρ_０，ρ_１）が、κに対する電子署名であることを、クライアント公開鍵Ｔを用いて検査する。検査に失敗したときには、以降の処理を中止する。
［ステップ３］：下式により、電子チケット鍵ｔを計算する。
【数６６】
ｔ＝σｈ（κ｜ＴｃｋｔＤｅｆ）^−１　ｍｏｄ　ｎ
【０２９５】
以下、本実施例では、もっとも基本的な電子チケットの認証手順を述べる。クライアント装置によるアプリケーション装置の認証や、アプリケーションによる、電子チケットの無効化、譲渡、分割、変更は、これまでに述べた実施例と同一の構成によって実現できるので、本実施例では説明を割愛する。
【０２９６】
［ステップ１］：クライアント装置は、入力（ｎ，Ｓ）からｓ＝ｈ（ｎ，Ｓ）を計算し、ｓを検索の鍵として、クライアント装置内の保護された記憶領域から（ｓ，κ）を取得する。
［ステップ２］：コミットメントχ∈Ｇｍ（Ｚ／ｎＺ）をランダムに生成し、ウィットネスωを以下の式で計算し、アプリケーション装置に送付する。
【数６７】
ω＝χ^ｐ　ｍｏｄ　ｎ
【０２９７】
［ステップ３］：アプリケーション装置は、チャレンジｃをランダムに生成し、クライアント装置に送付する。
［ステップ４］：クライアント装置は、レスポンスｒを以下の式で計算し、アプリケーション装置に送付する。
【数６８】
ｒ＝χｈ（κ｜ＴｃｋｔＤｅｆ）^ｃ　ｍｏｄ　ｎ
【０２９８】
［ステップ５］：アプリケーション装置は、ｔ^ｐｃｒ^ｐ＝ωＳ^ｃ　ｍｏｄ　ｎを検査し、検査が成功した場合に限り、ユーザが正しくアクセス権を有しているものと認定し、サービスを提供する。
【０２９９】
［実施例４：ロール間の信頼関係］
クライアント配布者は、各クライアント装置にユニークな公開鍵・個人鍵対を生成し、公開鍵を証明する証明書を併せて発行する。通常の証明書は現実に存在し責任能力のあるエンティティと公開鍵情報のバインドを保証するためのものだが、本発明のケースでは、対応する個人鍵がクライアント装置内に耐タンパー性をもって格納され、個人鍵の漏洩が起きないことをクライアント配布者がチケット発行者に対して保証する意味付けがなされている。述べ方を替えるならば、公開鍵に対応する個人鍵を保持するものはクライアント装置プログラムのみに限ることをクライアント装置配布者が保証するという意味になる。本発明の電子チケットは、電子チケット生成装置と発行先のクライアント装置において共有される値に基づいてサービスに対応する個人鍵を変形したものであり、第三者が電子チケット発行者との間で共有値を得ることができれば、直ちにサービスに対応する個人鍵を得られてしまう。電子チケット発行者は、発行先のクライアント装置の発行者を信頼することによって、電子チケット発行を行うことができる。
【０３００】
アプリケーションは電子チケットに対して副作用を及ぼすことができる。電子チケットに対して副作用を及ぼすことができるのは、電子チケットに指定されたアプリケーションに限られる。アプリケーションは、認証の対象となるサービスに対応したサービス公開鍵を用いてユーザのアクセス資格を認証し、また、アプリケーションの特権を表す公開鍵・個人鍵対の個人鍵を用いてクライアント装置へ電子チケットへの副作用を指示することができる。アプリケーション管理者は、アプリケーションの特権を特徴付ける公開鍵・個人鍵対を生成し、公開鍵を証明する証明書を併せて発行する。本発明の電子チケットは、電子チケットによって指定されたアプリケーションの個人鍵を用いることによって指定された範囲で副作用を及ぼすことができるので、第三者がアプリケーションの個人鍵を得ることができれば、自由にチケットに副作用を及ぼすことができてしまう。チケット発行者は、発行する電子チケットを用いた認証を行うアプリケーションプログラムの管理者たるアプリケーション管理者を信頼することによって、チケット発行を行うことができる。
【０３０１】
以上説明したように本発明の実施例によれば、アクセス資格を集中管理しないので、アクセス資格の運用コストを増大させることがなく、また、通通フローに適用が容易となる。また、クライアントは秘密情報を管理するための装置を複数保持する必要がなくなる。また秘密情報の漏洩等のおそれがなくサービス提供者、クライアント装置提供者、アプリケーション装置提供者の間の相互運用を容易にする。さらに、アクセス権行使に際し、匿名性を確保できる。さらに、各種サービス利用権の発行、検証、ならびに前記利用権データに対する無効化、譲渡、分割、変更などの操作を行うことができる。
【０３０２】
なお、この発明は上述の実施例に限定されるものではなくその趣旨を逸脱しない範囲で種々変更が可能である。
【０３０３】
【発明の効果】
以上説明したように、この発明によれば、アクセス資格の集中管理等に起因していた従来のアクセス権管理上の種々の問題を解消することができる。
【図面の簡単な説明】
【図１】本発明の実施例１の全体構成を説明する図である。
【図２】上述実施例１のクライアント装置の構成例を説明する図である。
【図３】上述実施例１のクライアント装置の他の構成例を説明する図である。
【図４】上述実施例１のクライアント装置の他の構成例を説明する図である。
【図５】上述実施例１のクライアント装置のさらに他の構成例を説明する図である。
【図６】上述実施例１のアプリケーション装置の構成例を説明する図である。
【図７】上述実施例１のアプリケーション装置の他の構成例を説明する図である。
【図８】上述実施例１のアプリケーション装置のさらに他の構成例を説明する図である。
【図９】上述実施例において信頼できるクライアント装置やアプリケーション装置を選択する構成を説明する図である。
【図１０】上述実施例における電子チケット発行フローを説明するフローチャートである。
【図１１】上述実施例における他の電子チケット発行フローを説明するフローチャートである。
【図１２】上述実施例における電子チケット検証フローを説明するフローチャートである。
【図１３】上述実施例における他の電子チケット検証フローを説明するフローチャートである。
【図１４】上述実施例における他の電子チケット検証フローを説明するフローチャートである。
【図１５】上述実施例におけるさらに他の電子チケット検証フローを説明するフローチャートである。
【図１６】上述実施例におけるアプリケーション装置によるクライアント装置の認証のフローを説明するフローチャートである。
【図１７】上述実施例における電子チケットを無効化するフローを説明するフローチャートである。
【図１８】上述実施例における電子チケットを譲渡するフローを説明するフローチャートである。
【図１９】上述実施例における電子チケットを分割するフローを説明するフローチャートである。
【図２０】上述実施例における電子チケットを変更するフローを説明するフローチャートである。
【図２１】上述実施例における有効回数の管理フローを説明するフローチャートである。
【図２２】上述実施例における副作用の取消フローを説明するフローチャートである。
【図２３】本発明の実施例２の再販モデルの構成を説明する図である。
【図２４】上述再販モデルの電子チケットの発行・検証のフローを説明するフローチャートである。
【図２５】上述実施例２のピア・ツー・ピアモデルの構成を説明する図である。
【図２６】上述ピア・ツー・ピアモデルの利用権配布フローを説明するフローチャートである。
【図２７】上述実施例２のモニタリングの構成を説明する図である。
【図２８】上述モニタリングのフローを説明するフローチャートである。
【図２９】上述実施例２のチェックイン・チェックアウトの構成を説明する図である。
【図３０】上述チェックイン・チェックアウトのフローを説明するフローチャートである。
【図３１】上述実施例２の複合アプリケーションの構成を説明する図である。
【図３２】上述実施例２のチケットの譲渡・分割の操作手順を説明するフローチャートである。
【図３３】上述実施例２の家電製品の制御を説明する図である。
【符号の説明】
１１０　　　電子チケット生成装置
１１１　　　特定情報取得手段
１２０　　　クライアント装置
１２１　　　通信手段（２）
１２２　　　特定情報生成手段
１２３　　　秘密情報保持手段
１２４　　　部分特定情報生成手段
１２５　　　設定データ保持手段
１２６　　　共有鍵保持手段
１２６　　　共有鍵退避手段
１２６　　　共有鍵保持手段
１２７　　　共有鍵保護手段
１２８　　　差分データ生成手段
１２９　　　外部特定情報保持手段
１３０　　　アプリケーション装置
１３１　　　通信手段（１）
１３２　　　秘密鍵保持手段
１３３　　　電子チケット保持手段
１３４　　　アクセス権認証装置
１３６　　　コマンド発行手段
１３７　　　コマンド受理手段
２０１　　　電子チケット
２０２　　　特定情報
１４０１　　　サービスプロバイダ
１４０２　　　卸業者
１４０３　　　小売業者
１４０４　　　エンドユーザ
２２０１　　　カード
２２０１　　　クライアント装置
２２０２　　　ユーザ端末
２２０３　　　操作端末
２２０４　　　検証器

Claims

ユーザによるサービスへのアクセスの制御を目的とするアクセス権管理装置であって、
サービスの提供者に帰属し、ユーザのアクセス権の電子的な表現であるチケットデータを生成する電子チケット生成装置と、
ユーザに帰属するクライアント装置とを有し、
前記電子チケット生成装置が前記クライアント装置を特定する特定情報を取得するための特定情報取得手段を含み、前記電子チケット生成装置はチケットデータを生成するにあたり、公開された手順に従って前記特定情報取得手段から前記クライアント装置の特定情報を取得し、該特定情報に依存するようにチケットデータを生成することを特徴とするアクセス権管理装置。
請求項１に記載のアクセス権管理装置において、前記クライアント装置が該クライアント装置を特定する特定情報を生成する特定情報生成手段を含み、前記電子チケット生成装置は前記特定情報取得手段を介して、該クライアント装置が前記特定情報生成手段を用いて生成した特定情報を取得して、チケットデータを生成することを特徴とするアクセス権管理装置。
請求項２に記載のアクセス権管理装置において、前記クライアント装置が該クライアント装置の秘密情報を保持する秘密情報保持手段を含み、前記クライアント装置の特定情報を前記秘密情報保持手段に保持される秘密情報から前記特定情報生成手段を用いて生成することを特徴とするアクセス権管理装置。
請求項２に記載のアクセス権管理装置において、前記クライアント装置が秘密情報生成手段を含み、前記クライアント装置の特定情報を前記秘密情報生成手段が生成する秘密情報から前記特定情報生成手段を用いて生成することを特徴とするアクセス権管理装置。
請求項３乃至４に記載のアクセス権管理装置において、前記クライアント装置が前記電子チケット生成装置からの特定情報発行要求を受け付ける要求受付手段を含み、前記特定情報生成手段を用いた特定情報の計算を、前記電子チケット生成装置から前記要求受付手段に要求が発行される都度、実行することを特徴とするアクセス権管理装置。
請求４に記載のアクセス権管理装置において、前記秘密情報生成手段が生成する秘密情報が乱数であることを特徴とするアクセス権管理装置。
請求項３に記載のアクセス権管理装置において、前記秘密情報保持手段に保持される秘密情報が、前記クライアント装置に帰属する暗号の秘密鍵であることを特徴とするアクセス権管理装置。
請求項２に記載のアクセス権管理装置において、前記クライアント装置が秘密情報生成手段と秘密情報保持手段とを含み、前記特定情報生成手段は、前記秘密情報生成手段が生成する第１の秘密情報と前記秘密情報保持手段が保持する第２の秘密情報とから、前記特定情報を生成することを特徴とするアクセス権管理装置。
請求項１に記載のアクセス権管理装置において、前記クライアント装置は秘密鍵保持手段を含み、前記秘密鍵保持手段は、前記クライアント装置に帰属する公開鍵暗号の秘密鍵（個人鍵、私有鍵、プライベート鍵ともいう）を保持し、前記クライアント装置を特定する情報が前記秘密鍵に対応する公開鍵暗号の公開鍵であることを特徴とするアクセス権管理装置。
請求項１に記載のアクセス権管理装置において、クライアント装置を特定する特定情報を第三者の機関に登録し、前記電子チケット生成装置は、前記特定情報取得手段を介して前記第三者の機関から前記クライアント装置の特定情報を取得することを特徴とするアクセス権管理装置。
請求項１に記載のアクセス権管理装置において、前記クライアント装置が該クライアント装置を一部特定するための部分特定情報生成手段と、該クライアント装置に帰属する公開鍵暗号の秘密鍵を保持するための秘密鍵保持手段とを含み、前記部分特定情報生成手段が生成する部分特定情報と、前記秘密鍵保持手段に保持される秘密鍵に対応する公開鍵とを合わせて、前記クライアント装置の特定情報とすることを特徴とするアクセス権管理装置。
請求項１に記載のアクセス権管理装置において、前記電子チケット生成装置は第１の鍵共有手段を含み、前記クライアント装置の特定情報から前記クライアント装置と共有するべき共有鍵を計算し、該共有鍵に依存するようにチケットデータを生成し、また、前記クライアント装置は第２の鍵共有手段と共有鍵保護手段を含み、前記第１の鍵共有手段が生成する共有鍵と一致する共有鍵を生成することを特徴とするアクセス権管理装置。
請求項１２に記載のアクセス権管理装置において、前記クライアント装置の前記第２の鍵共有手段は、前記電子チケット生成装置に帰属する公開鍵暗号の公開鍵を用いて前記共有鍵を生成することを特徴とするアクセス権管理装置。
請求項１２に記載のアクセス権管理装置において、前記電子チケット生成装置が鍵共有のために前記クライアント装置に送付する鍵共有データのための鍵共有データ生成手段を含み、また、前記クライアント装置の前記第２の鍵共有手段は、前記電子チケット生成装置が生成した鍵共有データを用いて共有鍵を生成することを特徴とするアクセス権管理装置。
請求項１４に記載のアクセス権管理装置において、前記電子チケット生成装置が秘密情報を保持する電子チケット生成装置用秘密情報保持手段を含み、前記第１の鍵共有手段は、クライアント装置の前記特定情報と併せて、前記電子チケット生成装置用秘密情報保持手段に保持される秘密情報を用いて共有鍵を生成し、前記鍵共有データ生成手段は該秘密情報を用いて鍵共有データを生成することを特徴とするアクセス権管理装置。
請求項１５に記載のアクセス権管理装置において、前記電子チケット生成装置用秘密情報保持手段に保持される秘密情報が、該電子チケット装置に帰属する暗号の秘密鍵であることを特徴とするアクセス権管理装置。
請求項１４に記載のアクセス権管理装置において、前記電子チケット生成装置が電子チケット生成装置用秘密情報生成手段を含み、前記第１の鍵共有手段は、クライアント装置の前記特定情報と併せて、前記電子チケット生成装置用秘密情報生成手段により生成される秘密情報を用いて共有鍵を生成し、前記鍵共有データ生成手段は該秘密情報を用いて鍵共有データを生成することを特徴とするアクセス権管理装置。
請求項１７に記載のアクセス権管理装置において、前記電子チケット生成装置用秘密情報生成手段が生成する秘密情報が乱数であることを特徴とするアクセス権管理装置。
請求項１６に記載のアクセス権管理装置において、前記電子チケット生成装置用秘密情報保持手段に保持される秘密鍵が公開鍵暗号の秘密鍵（個人鍵、私有鍵、プライベート鍵ともいう）であり、前記クライアント装置の第２の鍵共有手段は、前記電子チケット生成装置が生成する前記鍵共有データに併せて、前記秘密鍵に対応する公開鍵暗号の公開鍵を用いて共有鍵を生成することを特徴とするアクセス権管理装置。
請求項１２に記載のアクセス権管理装置において、前記電子チケット生成装置が秘密情報生成手段と秘密情報保持手段とを含み、前記第１の鍵共有手段は、前記秘密情報生成手段が生成する第１の秘密情報と前記秘密情報保持手段に保持される第２の秘密情報とを用いて共有鍵を生成し、前記鍵共有データ生成手段は、前記秘密情報生成手段が生成する第１の秘密情報と前記秘密情報保持手段に保持される第２の秘密情報とを用いて鍵共有データを生成することを特徴とするアクセス権管理装置。
ユーザによるサービスへのアクセスを制御することを目的とするアクセス権管理装置であって、
サービスを実際に提供するアプリケーション装置と、
ユーザに帰属するクライアント装置とを含み、
更に、前記アプリケーション装置は、
ユーザの前記サービスに対するアクセス権を電子的に表現したチケットデータを保持する電子チケット保持手段と、
クライアント装置と通信を行うための第１の通信手段と、
前記電子チケット保持手段に保持されるチケットデータと前記第１の通信手段を介して前記クライアント装置から得られる通信データとに基づいて認証を実行するアクセス権認証手段とを含み、
また、前記クライアント装置は、
前記アプリケーション装置と通信を行うための第２の通信手段と、
前記第２の通信手段を介して前記アプリケーション装置から得られる通信データに基づいて認証を実行するアプリケーション認証手段とを含み、
前記アプリケーション装置は、前記アクセス権認証手段による認証が成功した時に限り、ユーザが該サービスに対するアクセス権を有しているものと判断してサービスを提供し、他方、前記クライアント装置は、前記アプリケーション認証手段による認証が成功した時に限り、前記アプリケーション装置が該サービスを提供する特権を有していることを認証し、認証が成功した場合に限り前記アプリケーション装置の要求に応えて通信データを送付することを特徴とするアクセス権管理装置。
請求項２１に記載のアクセス権管理装置において、前記クライアント装置が共有鍵保持手段と共有鍵保護手段を含み、前記共有鍵保持手段は前記サービスの提供者に帰属する電子チケット生成装置との間で共有する共有鍵を保持し、前記アプリケーション認証手段は前記共有鍵を用いて、前記アプリケーション装置に送付する通信データを生成し、さらに、前記共有鍵保護手段はクライアント装置内に現れる共有鍵が改竄されたり摂取されたりすることを防止することを特徴とするアクセス権管理装置。
請求項２１または２２に記載のアクセス権管理装置において、前記クライアント装置は、特権を有するアプリケーション装置の認証方法を記載した設定データを保持するクライアント装置用設定データ保持手段を含み、前記アプリケーション認証手段は前記クライアント装置用設定データ保持手段に保持される設定データを参照することにより、前記アプリケーション装置が特権を有することを認証することを特徴とするアクセス権管理装置。
請求２３に記載のアクセス権管理装置において、前記クライアント装置は、前記アプリケーション装置と通信を行うに当たって、前記クライアント装置用設定データ保持手段に保持されている設定データに依存して前記アプリケーション装置に送付する通信データを生成することで、前記クライアント装置用設定データ保持手段に保持されている設定データが不正であった場合、前記アプリケーション装置が正しいデータを前記クライアント装置から受け取ることを防止することを特徴とするアクセス権管理装置。
請求項２１乃至２４に記載のアクセス権管理装置において、前記アプリケーション装置は、前記クライアント装置に対してコマンドを発行するためのコマンド発行手段を含み、前記クライアント装置は前記コマンドを受理するためのコマンド受理手段を含み、前記コマンド発行手段によって発行されたコマンドは、前記第１の通信手段及び第２の通信手段を介して、前記コマンド受理手段に伝達されることを特徴とするアクセス権管理装置。
請求項２５に記載のアクセス権管理装置において、前記クライアント装置の認証を目的とした通信において、前記アプリケーション装置は、前記コマンド発行手段を用いて、前記クライアント装置に対して前記チケットデータの無効化を指示するコマンドを発行し、前記クライアント装置は、前記コマンド受理手段により受理したコマンドを解釈し、アプリケーション装置が該コマンドを発行する特権を有していることを請求項２３乃至２４に記載の方法で認証し、認証が成功した場合に限り、前記チケットデータが今後利用できないように、前記クライアント装置の内部状態を変更することを特徴とするアクセス権管理装置。
請求項２５に記載のアクセス権管理装置において、前記クライアント装置は差分データ生成手段と、外部のクライアント装置の特定情報を保持する外部特定情報保持手段とを含み、前記クライアント装置及びアプリケーション装置の認証を目的とした通信時に、前記アプリケーション装置は前記チケットデータを他のユーザのアクセス権を表現する別のチケットデータに変更するためのコマンドを、前記コマンド発行手段を用いて前記クライアント装置に対して発行し、前記クライアント装置は、前記コマンド受理手段により該コマンドを受理し、前記アプリケーション装置が該コマンドを発行する特権を有していることを請求項２３乃至２４に記載の方法で認証し、認証が成功した場合に限り、前記チケットデータが今後利用できないように前記クライアント装置の内部状態を変更するとともに、差分データ生成手段と外部特定情報保持手段とを用いて前記チケットデータを前記新しいチケットデータに変更するために必須の差分データを生成することを特徴とするアクセス権管理装置。
請求項２５に記載のアクセス権管理装置において、前記クライアント装置は差分データ生成手段を含み、前記クライアント装置及び前記アプリケーション装置の認証を目的とした通信時に、前記アプリケーション装置は、前記チケットデータを同一のサービスに関する二つの異なるチケットデータに変更するするためのコマンドを、前記コマンド発行手段を用いて前記クライアント装置に対して発行し、前記クライアント装置はアプリケーション装置が該コマンドを発行する特権を有していることを請求項２３乃至２４に記載の方法で認証し、認証が成功した場合に限り、前記チケットデータが今後利用できないように前記クライアント装置の内部状態を変化するとともに、前記差分データ生成手段を用いて前記チケットデータを前記新しい二つのチケットデータに変更するために必須の差分データを生成することを特徴とするアクセス権管理装置。
請求項２５に記載のアクセス権管理装置において、前記クライアント装置は差分データ生成手段を含み、前記クライアント装置及び前記アプリケーション装置の認証を目的とした通信時に、前記アプリケーション装置は前記チケットデータに付与されている属性を変更して新しいチケットデータを生成するためのコマンドを、前記コマンド発行手段を用いて前記クライアント装置に対して発行し、前記クライアント装置は、前記コマンド受理手段により該コマンドを受理し、アプリケーション装置が該コマンドを発行する特権を有していることを請求項２３乃至２４に記載の方法で認証し、認証が成功した場合に限り、前記チケットデータが今後利用できないように前記クライアント装置の内部状態を変更するとともに、前記差分データ生成手段を利用して前記チケットデータを前記新しいチケットデータに変更するために必須の差分データを生成することを特徴とするアクセス権管理装置。
請求項２９に記載のアクセス権管理装置において、チケットデータに付与される属性が、チケットデータの利用開始日時、利用終了日時、利用可能回数、譲渡の可否、譲渡可能回数、分割の可否、分割可能回数、及び、アプリケーション装置が解釈できるプログラムコードのうちの一つ、或いは、複数の組み合わせであることを特徴とするアクセス権管理装置。
請求項２６乃至３０に記載のアクセス権管理装置において、アプリケーション装置が前記共有鍵保持手段を含む時、該チケットデータに対応する共有鍵を消去することで、該チケットデータを今後利用できないようにすることを特徴とするアクセス権管理装置。
請求項５乃至１２に記載のアクセス権管理装置において、前記クライアント装置及びアプリケーション装置が各々一方向性関数手段を保持し、互いの認証を目的とする通信時に、前記一方向性関数手段の出力を相手に送付することにより、互いに自らの秘密情報を開示しないことを特徴とするアクセス権管理装置。
ユーザによるサービスへのアクセスの制御を目的とするアクセス権管理装置であって、サービスの提供者に帰属し、ユーザのアクセス権の電子的な表現であるチケットデータを生成する電子チケット生成装置が、アプリケーション装置の供給者が提供するアプリケーション装置の設定データを評価するアプリケーション設定データ評価手段を含み、前記電子チケット生成装置は、前記設定データと前記アプリケーション設定データ評価手段からの出力のいずれか一方、もしくは、両方を用いてチケットデータを生成することで、設定データに記載された正当なアプリケーション装置のみに該チケットデータに基づいてサービスを提供する特権を付与することを特徴とするアクセス権管理装置。
請求項３３に記載のアクセス権管理装置であって、前記設定データには一つないし複数のアプリケーション装置に帰属する公開鍵暗号の公開鍵を含み、一方、個別のアプリケーション装置は、前記公開鍵に対応する秘密鍵（個人鍵、私有鍵、プライベート鍵ともいう）を保持する秘密鍵保持手段を含み、クライアント装置によるアプリケーション装置の特権の認証時に、該秘密鍵を用いて生成する通信データを送付することを特徴とするアクセス権管理装置。
ユーザによるサービスへのアクセスの制御を目的とするアクセス権管理装置であって、サービスの提供者に帰属し、ユーザのアクセス権の電子的な表現であるチケットデータを生成する電子チケット生成装置が、クライアント装置の供給者が提供するクライアント装置の証明データを評価するクライアント証明データ評価手段を含み、前記電子チケット生成装置は、前記証明データと前記クライアント証明データ評価手段からの出力のいずれか一方、もしくは、両方を用いてチケットデータを生成することで、前記証明データに記載された正当なクライアント装置のみに該チケットデータに基づいてサービスにアクセスするアクセス権を付与することを特徴とするアクセス権管理装置。
ユーザのアクセス権の電子的な表現であるチケットデータを用いてユーザによるサービスへのアクセスの制御を行うアクセス権管理装置において上記チケットデータを生成する電子チケット生成装置であって、
ユーザに帰属するクライアント装置を特定する特定情報を取得するための特定情報取得手段を含み、前記チケットデータを生成するにあたり、公開された手順に従って前記特定情報取得手段から前記クライアント装置の特定情報を取得し、該特定情報に依存するようにチケットデータを生成することを特徴とする電子チケット生成装置。