JP2002139998A - 属性確認処理を含むデータ通信システムおよび属性確認処理を含むデータ通信方法 - Google Patents

属性確認処理を含むデータ通信システムおよび属性確認処理を含むデータ通信方法

Info

Publication number
JP2002139998A
JP2002139998A JP2000334186A JP2000334186A JP2002139998A JP 2002139998 A JP2002139998 A JP 2002139998A JP 2000334186 A JP2000334186 A JP 2000334186A JP 2000334186 A JP2000334186 A JP 2000334186A JP 2002139998 A JP2002139998 A JP 2002139998A
Authority
JP
Japan
Prior art keywords
attribute
data
user device
public key
certificate
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2000334186A
Other languages
English (en)
Inventor
Yoshito Ishibashi
義人 石橋
Kenji Yoshino
賢治 吉野
Toru Akishita
徹 秋下
Taizo Shirai
太三 白井
Makoto Oka
誠 岡
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP2000334186A priority Critical patent/JP2002139998A/ja
Publication of JP2002139998A publication Critical patent/JP2002139998A/ja
Pending legal-status Critical Current

Links

Landscapes

  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

(57)【要約】 【課題】 データ通信を安全に行なうことを可能とした
属性確認処理を含むデータ通信システムを提供する。 【解決手段】 データ通信を実行するエンティテイ間に
おいて、通信相手のエンティテイに設定された属性情報
を通信相手のエンティテイの公開鍵証明書または属性証
明書から取得し、取得した属性情報に基づく属性確認が
なされたことを処理実行条件とする。例えば、コンテン
ツの購入を実行するユーザ機器、コンテンツの購入要求
を受け付けるショップサーバ、コンテンツ配信管理を行
うシステムホルダ等の機能毎に異なる属性コードを付与
して、属性コードに基づいて属性確認を実行する。本構
成によれば、通信相手が他のエンティテイになりすまし
て処理を実行することが防止され、安全なコンテンツ取
り引き等のデータ通信が可能となる。

Description

【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は属性確認処理を含む
データ通信システムおよび属性確認処理を含むデータ通
信方法に関する。さらに、詳細には、データ通信を実行
するエンティテイ間において通信相手の属性確認を実行
することにより、セキュリティの高い正当なコンテンツ
流通処理等のデータ通信処理を実行することを可能とし
た属性確認処理を含むデータ通信システムおよび属性確
認処理を含むデータ通信方法に関する。
【０００２】
【従来の技術】昨今、ゲームプログラム、音声データ、
画像データ、文書作成プログラム等、様々なソフトウエ
アデータ（以下、これらをコンテンツ（Content）と呼
ぶ）の、インターネット等、ネットワークを介した流通
が盛んになってきている。また、オンラインショッピン
グ、銀行決済、チケット販売等のネットワークを介した
商品売買、決済処理等も盛んになってきている。
【０００３】このようなネットワークを介したデータ通
信においては、データ送信側とデータ受信側とが互いに
正規なデータ送受信対象であることを確認した上で、必
要な情報を転送する、すなわちセキュリティを考慮した
データ転送構成をとるのが一般的となっている。データ
転送の際のセキュリティ構成を実現する手法には、転送
データの暗号化処理、データに対する署名処理等があ
る。
【０００４】暗号化データは、所定の手続きによる復号
化処理によって利用可能な復号データ（平文）に戻すこ
とができる。このような情報の暗号化処理に暗号化鍵を
用い、復号化処理に復号化鍵を用いるデータ暗号化、復
号化方法は従来からよく知られている。
【０００５】暗号化鍵と復号化鍵を用いるデータ暗号化
・復号化方法の態様には様々な種類があるが、その１つ
の例としていわゆる公開鍵暗号方式と呼ばれる方式があ
る。公開鍵暗号方式は、発信者と受信者の鍵を異なるも
のとして、一方の鍵を不特定のユーザが使用可能な公開
鍵として、他方を秘密に保つ秘密鍵とするものである。
例えば、データ暗号化鍵を公開鍵とし、復号鍵を秘密鍵
とする。あるいは、認証子生成鍵を秘密鍵とし、認証子
検証鍵を公開鍵とする等の態様において使用される。
【０００６】暗号化、復号化に共通の鍵を用いるいわゆ
る共通鍵暗号化方式と異なり、公開鍵暗号方式では秘密
に保つ必要のある秘密鍵は、特定の１人が持てばよいた
め鍵の管理において有利である。ただし、公開鍵暗号方
式は共通鍵暗号化方式に比較してデータ処理速度が遅
く、秘密鍵の配送、ディジタル署名等のデータ量の少な
い対象に多く用いられている。公開鍵暗号方式の代表的
なものにはＲＳＡ（Rivest-Shamir-Adleman）暗号があ
る。これは非常に大きな２つの素数（例えば１５０桁）
の積を用いるものであり、大きな２つの素数（例えば１
５０桁）の積の素因数分解する処理の困難さを利用して
いる。
【０００７】公開鍵暗号方式では、不特定多数に公開鍵
を使用可能とする構成であり、配布する公開鍵が正当な
ものであるか否かを証明する証明書、いわゆる公開鍵証
明書を使用する方法が多く用いられている。例えば、利
用者Ａが公開鍵、秘密鍵のペアを生成して、生成した公
開鍵を認証局に対して送付して公開鍵証明書を認証局か
ら入手する。利用者Ａは公開鍵証明書を一般に公開す
る。不特定のユーザは公開鍵証明書から所定の手続きを
経て公開鍵を入手して文書等を暗号化して利用者Ａに送
付する。利用者Ａは秘密鍵を用いて暗号化文書等を復号
する等のシステムである。また、利用者Ａは、秘密鍵を
用いて文書等に署名を付け、不特定のユーザが公開鍵証
明書から所定の手続きを経て公開鍵を入手して、その署
名の検証を行なうシステムである。
【０００８】公開鍵証明書は、公開鍵暗号方式における
認証局あるいは発行局（ＣＡ：Certificate Authority
またはＩＡ：Issuer Authority）が発行する証明書であ
り、ユーザが自己のＩＤ、公開鍵等を認証局に提出する
ことにより、認証局側が認証局のＩＤや有効期限等の情
報を付加し、さらに認証局による署名を付加して作成さ
れる証明書である。
【０００９】公開鍵証明書は、証明書のバージョン番
号、発行局が証明書利用者に対し割り付ける証明書の通
し番号、電子署名に用いたアルゴリズムおよびパラメー
タ、認証局の名前、証明書の有効期限、証明書利用者の
名前（ユーザＩＤ）、証明書利用者の公開鍵並びに電子
署名を含む。
【００１０】電子署名は、証明書のバージョン番号、認
証局が証明書利用者に対し割り付ける証明書の通し番
号、電子署名に用いたアルゴリズムおよびパラメータ、
認証局の名前、証明書の有効期限、証明書利用者の名前
並びに証明書利用者の公開鍵全体に対しハッシュ関数を
適用してハッシュ値を生成し、そのハッシュ値に対して
認証局の秘密鍵を用いて生成したデータである。
【００１１】一方、この公開鍵証明書を利用する際に
は、利用者は自己が保持する認証局の公開鍵を用い、当
該公開鍵証明書の電子署名を検証し、電子署名の検証に
成功した後に公開鍵証明書から公開鍵を取り出し、当該
公開鍵を利用する。従って、公開鍵証明書を利用する全
ての利用者は、共通の認証局の公開鍵を保持している必
要がある。
【００１２】
【発明が解決しようとする課題】上述のような認証局発
行の公開鍵証明書を用いた公開鍵暗号方式によるデータ
送信システムにおいては、例えばコンテンツを配信する
コンテンツ配信ショップは、ユーザの公開鍵に基づいて
配信対象のコンテンツを暗号化してユーザに送信する。
コンテンツ配信ショップからの暗号化データを受信した
ユーザ機器は、自己の公開鍵に対応する自己の秘密鍵で
暗号化コンテンツの復号を実行する。
【００１３】しかし、コンテンツ取り引きにおいてデー
タ通信を実行する場合、通信相手がショップであるの
か、ユーザ機器であるのか、あるいはその他システムホ
ルダ等の管理サーバであるのかを確認することは困難で
ある。通信相手から送信されるデータに基づいて判定す
るしかないのが現状である。
【００１４】従って、不正なユーザ機器、不正なショッ
プ等が存在し、不正なユーザ機器がショップになりすま
してコンテンツの架空取引を実行したりする可能性があ
る。また、正当な取り引きを実行しようとするユーザ機
器がショップサーバであると信じて通信を開始し、ショ
ップサーバ相手のコンテンツ購入要求を実行して、例え
ばクレジット口座番号の送信処理を実行するような場
合、相手がショップサーバになりすました不正なサーバ
であるような場合は、ユーザ機器からクレジット口座番
号を不正に取得する等の処理が実行されるおそれがあ
る。
【００１５】また、不正、あるいは架空のコンテンツ取
り引きが実行されると、コンテンツの取り引き実体の把
握が困難となる。一般的には、コンテンツ配信ショップ
の自己申告により、コンテンツの販売量を確認し、自己
申告に基づくライセンス料が、ショップからライセンス
ホルダ、あるいはコンテンツ製作者等に提供されるのが
一般的な取り引き形態であるが、不正、あるいは架空の
コンテンツ取り引きが実行されると、ショップにおいて
も、また、コンテンツの頒布権を持つライセンスホル
ダ、あるいはコンテンツの著作権を持つコンテンツ製作
者も正当なコンテンツ取り引きに伴うライセンス料の取
得が保証されない。
【００１６】本発明は、上述のような、コンテンツ取り
引きにおける問題点に鑑みてなされたものであり、デー
タ通信を実行するエンティテイ間において、通信相手の
エンティテイの属性を確認して処理を実行することによ
り、不正な相手との処理、例えばコンテンツ購入に伴う
様々な処理が不正に実行されることを防止可能とした属
性確認処理を含むデータ通信システムおよび属性確認処
理を含むデータ通信方法を実現することを目的とする。
【００１７】より具体的には、例えばコンテンツを購入
する機能を持つユーザ機器、コンテンツの購入依頼を受
領する機能を持つショップサーバ、コンテンツ配信を管
理する機能を持つサービス運営体サーバ、コンテンツを
配信する配信サーバ等の異なるエンティテイの各々に、
異なる属性情報としての属性コードを付与し、各エンテ
ィテイの公開鍵証明書または属性証明書に格納された属
性情報によって通信相手の確認を可能として暗然なコン
テンツ取り引き形態を実現する属性確認処理を含むデー
タ通信システムおよび属性確認処理を含むデータ通信方
法を提供することを目的とする。
【００１８】
【課題を解決するための手段】本発明の第１の側面は、
データ通信を実行するエンティテイ間において、通信相
手のエンティテイに設定された属性情報を該通信相手の
エンティテイの公開鍵証明書または属性証明書から取得
し、取得した属性情報に基づく属性確認がなされたこと
を処理実行条件とした構成を有することを特徴とする属
性確認処理を含むデータ通信システムにある。
【００１９】さらに、本発明のデータ通信システムの一
実施態様において、前記属性情報は、エンティテイの機
能に基づいて設定される属性情報であることを特徴とす
る。
【００２０】さらに、本発明のデータ通信システムの一
実施態様において、データ通信を実行するエンティテイ
は、コンテンツ配信システムを構成するエンティテイで
あって、コンテンツを購入する機能を持つユーザ機器、
コンテンツの購入依頼を受領する機能を持つショップサ
ーバ、コンテンツ配信を管理する機能を持つサービス運
営体サーバ、コンテンツを配信する配信サーバ中の２以
上のエンティテイを含み、該異なるエンティテイの各々
には、異なる属性情報としての属性コードが付与され、
各エンティテイの公開鍵証明書または属性証明書に格納
された構成であることを特徴とする。
【００２１】さらに、本発明のデータ通信システムの一
実施態様において、前記エンティテイの属性情報は、当
該エンティテイの公開鍵証明書に格納され、属性情報を
格納した公開鍵証明書には、公開鍵証明書発行局の署名
が生成されて格納された構成を有することを特徴とす
る。
【００２２】さらに、本発明のデータ通信システムの一
実施態様において、前記エンティテイの属性情報は、当
該エンティテイの属性証明書に格納され、属性情報を格
納した属性証明書には、属性証明書発行局の署名が生成
されて格納された構成を有することを特徴とする。
【００２３】さらに、本発明のデータ通信システムの一
実施態様において、データ通信を実行するエンティテイ
間において、通信相手のエンティテイに設定された属性
情報を取得する処理は、エンティテイ間の相互認証処理
において取得する通信相手の公開鍵証明書から取得する
処理として実行することを特徴とする。
【００２４】さらに、本発明のデータ通信システムの一
実施態様において、データ通信を実行するエンティテイ
間において、通信相手のエンティテイに設定された属性
情報を取得する処理は、通信相手の属性証明書を取得
し、属性証明書中の属性証明書発行局の署名検証を実行
し、署名検証成功を条件として属性証明書から取得する
処理として実行することを特徴とする。
【００２５】さらに、本発明のデータ通信システムの一
実施態様において、データ通信を実行するエンティテイ
間において、通信相手のエンティテイに設定された属性
情報を取得する処理は、受信データの署名検証処理に適
用する通信相手エンティテイの公開鍵証明書から取得す
る処理として実行することを特徴とする。
【００２６】さらに、本発明のデータ通信システムの一
実施態様において、データ通信を実行するエンティテイ
間において、通信相手のエンティテイに設定された属性
情報を取得する処理は、通信相手の公開鍵証明書とリン
クする属性証明書を、公開鍵証明書および属性証明書に
共通に格納された公開鍵証明書通し番号に基づいて確認
し、公開鍵証明書と同一の公開鍵証明書通し番号を格納
した属性証明書から取得する処理として実行することを
特徴とする。
【００２７】さらに、本発明のデータ通信システムの一
実施態様において、前記属性確認処理は、通信相手のエ
ンティテイの公開鍵証明書、または属性証明書から取得
した属性コードと、通信相手として想定したエンティテ
イに設定された属性コードとの比較処理として実行する
構成であることを特徴とする。
【００２８】さらに、本発明のデータ通信システムの一
実施態様において、前記属性確認処理は、特定の通信相
手に固有の通信処理実行シーケンスに含まれる属性コー
ド比較処理であり、前記特定の通信相手に設定された属
性コードと、通信相手のエンティテイの公開鍵証明書、
または属性証明書から取得した属性コードとの比較処理
として実行する構成であることを特徴とする。
【００２９】さらに、本発明の第２の側面は、データ通
信を実行するエンティテイ間において、通信相手のエン
ティテイに設定された属性情報を該通信相手のエンティ
テイの公開鍵証明書または属性証明書から取得する属性
情報取得ステップと、前記属性情報取得ステップにおい
て取得した属性情報に基づく属性確認を実行する属性確
認処理ステップとを有し、前記属性確認ステップにおい
て属性の正当性が確認されたことを次処理実行条件とし
たことを特徴とする属性確認処理を含むデータ通信方法
にある。
【００３０】さらに、本発明のデータ通信方法の一実施
態様において、前記属性情報は、エンティテイの機能に
基づいて設定される属性情報であることを特徴とする。
【００３１】さらに、本発明のデータ通信方法の一実施
態様において、データ通信を実行するエンティテイは、
コンテンツ配信システムを構成するエンティテイであっ
て、コンテンツを購入する機能を持つユーザ機器、コン
テンツの購入依頼を受領する機能を持つショップサー
バ、コンテンツ配信を管理する機能を持つサービス運営
体サーバ、コンテンツを配信する配信サーバ中の２以上
のエンティテイを含み、該異なるエンティテイの各々に
は、異なる属性情報としての属性コードが付与され、各
エンティテイの公開鍵証明書または属性証明書に格納さ
れ、前記公開鍵証明書または属性証明書に基づく属性確
認を実行することを特徴とする。
【００３２】さらに、本発明のデータ通信方法の一実施
態様において、前記エンティテイの公開鍵証明書は、エ
ンティテイに設定された属性情報を含み、公開鍵証明書
発行局の署名が格納され、属性確認を実行するエンティ
テイは、前記公開鍵証明書発行局の署名検証の後、前記
属性情報を取得する処理を実行することを特徴とする。
【００３３】さらに、本発明のデータ通信方法の一実施
態様において、前記エンティテイの属性証明書は、エン
ティテイに設定された属性情報を含み、属性証明書発行
局の署名が格納され、属性確認を実行するエンティテイ
は、前記属性証明書発行局の署名検証の後、前記属性情
報を取得する処理を実行することを特徴とする。
【００３４】さらに、本発明のデータ通信方法の一実施
態様において、データ通信を実行するエンティテイ間に
おいて、通信相手のエンティテイに設定された属性情報
を取得する処理は、エンティテイ間の相互認証処理にお
いて取得する通信相手の公開鍵証明書から取得する処理
として実行することを特徴とする。
【００３５】さらに、本発明のデータ通信方法の一実施
態様において、データ通信を実行するエンティテイ間に
おいて、通信相手のエンティテイに設定された属性情報
を取得する処理は、受信データの署名検証処理に適用す
る通信相手エンティテイの公開鍵証明書から取得する処
理として実行することを特徴とする。
【００３６】さらに、本発明のデータ通信方法の一実施
態様において、データ通信を実行するエンティテイ間に
おいて、通信相手のエンティテイに設定された属性情報
を取得する処理は、通信相手の公開鍵証明書とリンクす
る属性証明書を、公開鍵証明書および属性証明書に共通
に格納された公開鍵証明書通し番号に基づいて確認し、
公開鍵証明書と同一の公開鍵証明書通し番号を格納した
属性証明書から取得する処理として実行することを特徴
とする。
【００３７】さらに、本発明のデータ通信方法の一実施
態様において、前記属性確認処理ステップは、通信相手
のエンティテイの公開鍵証明書、または属性証明書から
取得した属性コードと、通信相手として想定したエンテ
ィテイに設定された属性コードとの比較処理として実行
することを特徴とする。
【００３８】さらに、本発明のデータ通信方法の一実施
態様において、前記属性確認処理ステップは、特定の通
信相手に固有の通信処理実行プログラムに含まれる属性
コード比較処理であり、前記特定の通信相手に設定され
た属性コードと、通信相手のエンティテイの公開鍵証明
書、または属性証明書から取得した属性コードとの比較
処理として実行することを特徴とする。
【００３９】さらに、本発明の第３の側面は、データ通
信を実行するエンティテイの機能に基づく属性情報を構
成データとして有するとともに、公開鍵証明所発行局の
署名データを含む公開鍵証明書を格納したことを特徴と
する記録媒体にある。
【００４０】さらに、本発明の第４の側面は、データ通
信を実行するエンティテイの機能に基づく属性情報を構
成データとして有するとともに、属性証明書発行局の署
名データを含む属性証明書を格納したことを特徴とする
記録媒体にある。
【００４１】さらに、本発明の第５の側面は、データ通
信処理をコンピュータ・システム上で実行せしめるコン
ピュータ・プログラムを提供するプログラム提供媒体で
あって、前記コンピュータ・プログラムは、データ通信
を実行するエンティテイ間において、通信相手のエンテ
ィテイに設定された属性情報を通信相手のエンティテイ
の公開鍵証明書または属性証明書から取得する属性情報
取得ステップと、前記属性情報取得ステップにおいて取
得した属性情報に基づく属性確認を実行する属性確認処
理ステップと、を有することを特徴とするプログラム提
供媒体にある。
【００４２】なお、本発明の第５の側面に係るプログラ
ム提供媒体は、例えば、様々なプログラム・コードを実
行可能な汎用コンピュータ・システムに対して、コンピ
ュータ・プログラムをコンピュータ可読な形式で提供す
る媒体である。媒体は、ＣＤやＦＤ、ＭＯなどの記録媒
体、あるいは、ネットワークなどの伝送媒体など、その
形態は特に限定されない。
【００４３】このようなプログラム提供媒体は、コンピ
ュータ・システム上で所定のコンピュータ・プログラム
の機能を実現するための、コンピュータ・プログラムと
提供媒体との構造上又は機能上の協働的関係を定義した
ものである。換言すれば、該提供媒体を介してコンピュ
ータ・プログラムをコンピュータ・システムにインスト
ールすることによって、コンピュータ・システム上では
協働的作用が発揮され、本発明の他の側面と同様の作用
効果を得ることができるのである。
【００４４】本発明のさらに他の目的、特徴や利点は、
後述する本発明の実施例や添付する図面に基づくより詳
細な説明によって明らかになるであろう。
【００４５】
【発明の実施の形態】以下、図面を参照しながら、本発
明の実施の形態について詳細に説明する。なお、説明
は、以下の項目に従って行なう。 １．暗号化コンテンツ鍵の鍵かけかえ処理によるコンテ
ンツ配信管理 １．１．システム構成：基本コンテンツ配信モデル１ １．２．基本コンテンツ配信モデル１の変形例 １．３．基本コンテンツ配信モデル２ ２．電子チケットを利用したコンテンツ配信モデル ３．ログ収集サーバによるコンテンツ配信管理 ４．属性データを記録した公開鍵証明書または属性証明
書利用構成
【００４６】
【実施例】［１．暗号化コンテンツ鍵の鍵かけかえ処理
によるコンテンツ配信管理］ ［１．１．システム構成：基本コンテンツ配信モデル
１］図１に本発明のコンテンツ配信システムおよびコン
テンツ配信方法の一実施例の概要を説明する図を示す。
なお、システムとは、複数の装置の論理的集合構成であ
り、各構成の装置が同一筐体内にあるものには限らな
い。
【００４７】図１のコンテンツ配信システムは、ユーザ
機器に対するコンテンツの配信サービスを行なうショッ
プサーバ（ＳＨＯＰ）１００、ショップサーバ１００か
らのコンテンツ配信を受信するユーザ機器（ＤＥＶＩＣ
Ｅ）２００、さらに、正当なコンテンツ取り引き管理を
行なう管理サーバとして機能するユーザ機器認証サーバ
（ＤＡＳ：Device Authentication Server）３００を主
構成要素とする。なお、図１の構成では、ショップサー
バ１００、ユーザ機器２００、ユーザ機器認証サーバ３
００を１つづつ示しているが、実際のコンテンツ取り引
き構成においては、図１に示す各構成要素が複数存在
し、各コンテンツ取り引き毎に、様々なルートで情報が
送受信される。図１は、１つのコンテンツ取り引きにお
けるデータの流れを示しているものである。
【００４８】（ショップサーバ）図１のコンテンツ配信
システムのショップサーバ１００の構成を図２に示す。
ショップサーバ１００は、取り引き対象となるコンテン
ツをコンテンツキーで暗号化した暗号化コンテンツデー
タであるＫｃ（Ｃｏｎｔｅｎｔ）と、コンテンツキーＫ
ｃをユーザ機器認証サーバ（ＤＡＳ：Device Authentic
ation Server）の公開鍵：ＫｐＤＡＳで暗号化した暗号
化コンテンツキーＫｐＤＡＳ（Ｋｃ）を格納したコンテ
ンツデータベース１１０を有する。なお、暗号化コンテ
ンツデータであるＫｃ（Ｃｏｎｔｅｎｔ）は、図にも示
すように、それぞれコンテンツ識別子であるコンテンツ
ＩＤが付加され、コンテンツＩＤに基づいて識別可能な
構成を持つ。
【００４９】ショップサーバ１００は、さらにコンテン
ツ取り引き管理データ、例えばコンテンツ販売先のユー
ザ機器の識別子とコンテンツ識別子等を対応づけて管理
する購買管理データベース１２０を有する。さらに、コ
ンテンツデータベース１１０からの配信コンテンツの抽
出処理、取り引きに伴う購買管理データベース１２０に
対して登録する取り引きデータの生成処理、ユーザ機器
２００、ユーザ機器認証サーバ３００との通信処理、さ
らに、各通信処理に際してのデータ暗号処理等を実行す
る制御手段１３０を有する。
【００５０】購買管理データベース１２０のデータ構成
を図３に示す。購買管理データベース１２０は、ショッ
プサーバがコンテンツ取り引きに応じて処理を実行する
際に内部生成する識別番号としてのショップ処理Ｎ
ｏ．、コンテンツ購入依頼を発行したユーザ機器の識別
子である機器ＩＤ、ユーザ機器とショップ間でのコンテ
ンツ取り引きを実行する際に、ユーザ機器で生成発行す
るコンテンツ取り引き識別子としてのトランザクション
ＩＤ、取り引き対象コンテンツの識別子であるコンテン
ツＩＤ、ショップサーバにおけるコンテンツ取り引き処
理のステータスを示すステータスの各情報を持つ。ステ
ータスは、後段で詳細に説明するがコンテンツの取り引
きに伴う複数の処理の進行に応じて更新される。
【００５１】制御手段１３０は、図２に示すように暗号
処理手段、通信処理手段としての機能も有し、制御手段
１３０は、例えば暗号処理プログラム、通信処理プログ
ラムを格納したコンピュータによって構成される。制御
手段１３０の暗号処理手段において実行される暗号処理
において使用される鍵データ等は、制御手段内部の記憶
手段にセキュアに格納されている。ショップサーバ１０
０が格納する暗号鍵等の暗号処理用データとしては、シ
ョップサーバの秘密鍵：ＫｓＳＨＯＰ、ショップサーバ
の公開鍵証明書Ｃｅｒｔ＿ＳＨＯＰ、公開鍵証明書の発
行機関である公開鍵証明書発行局としての認証局（Ｃ
Ａ：Certificate Authority）の公開鍵ＫｐＣＡがあ
る。
【００５２】図４に制御手段１３０の構成例を示す。制
御手段１３０の構成について説明する。制御部１３１は
各種処理プログラムを実行する中央演算処理装置（ＣＰ
Ｕ:Central Processing Unit）によって構成され、図４
の制御手段の各構成部位の処理を制御する。ＲＯＭ（Re
ad only Memory）１３２は、ＩＰＬ（Initial Program
Loading）等のプログラムを記憶したメモリである。Ｒ
ＡＭ（Random Access Memory）１３３は、制御部１３１
が実行するプログラム、例えばデータベース管理プログ
ラム、暗号処理プログラム、通信プログラム等、実行プ
ログラムの格納領域、またこれら各プログラム処理にお
けるワークエリアとして使用される。
【００５３】表示部１３４は、液晶表示装置、ＣＲＴな
どの表示手段を有し、制御部１３１の制御の下、様々な
プログラム実行時のデータ、例えばコンテンツ配信先の
ユーザデータ等を表示する。入力部１３５は、キーボー
ドや、例えばマウス等のポインティングデバイスを有
し、これら各入力デバイスからのコマンド、データ入力
を制御部１３１に出力する。ＨＤＤ（Hard Disk Driv
e）１３６は、データベース管理プログラム、暗号処理
プログラム、通信プログラム等のプログラム、さらに各
種データが格納される。
【００５４】ドライブ１３７は、例えばＨＤ（Hard Dis
k）や、ＦＤ（Floppy Disk）等の磁気ディスク、ＣＤ−
ＲＯＭ（Compact Disk ROM）などの光ディスク、ミニデ
ィスク等の光磁気ディスク、ＲＯＭやフラッシュメモリ
などの半導体メモリ等の各種記録媒体に対するアクセス
を制御する機能を持つ。磁気ディスク等の各種記録媒体
はプログラム、データ等を記憶する。ネットワークイン
タフェース１３８は、インターネット、電話回線等の有
線、無線を介した通信のインタフェースとして機能す
る。
【００５５】ショップサーバ１００は、例えば上述した
構成を持つ制御手段１３０において、コンテンツの取り
引き対象であるユーザ機器２００、あるいはユーザ機器
認証サーバ３００との間でのコンテンツ取り引きに伴う
様々な暗号処理、認証処理等を実行する。
【００５６】（ユーザ機器認証サーバ）図５にユーザ機
器認証サーバ（ＤＡＳ）３００の構成を示す。ユーザ機
器認証サーバは、ライセンス管理データベース３２０を
有する。ライセンス管理データベース３２０のデータ構
成を図６に示す。ライセンス管理データベースは、コン
テンツ取り引き時にユーザ機器認証サーバ（ＤＡＳ）の
実行する処理に応じて内部生成する処理識別子としての
ユーザ機器認証サーバ処理Ｎｏ．、コンテンツ購入依頼
を発行したユーザ機器の識別子である機器ＩＤ、コンテ
ンツ取り引きを実行する際に、ユーザ機器で生成発行す
るコンテンツ取り引き識別子としてのトランザクション
ＩＤ、取り引き対象コンテンツの識別子であるコンテン
ツＩＤ、コンテンツ取り引きを実行するショップサーバ
の識別子であるショップＩＤ、ショップの発行するショ
ップでの処理識別子であるショップ処理Ｎｏ．、ユーザ
機器認証サーバ（ＤＡＳ）におけるコンテンツ取り引き
処理のステータスを示すステータスの各情報を持つ。ス
テータスは、後段で詳細に説明するがコンテンツの取り
引きに伴う複数の処理の進行に応じて更新される
【００５７】ユーザ機器認証サーバ（ＤＡＳ）３００
は、ユーザ機器２００、ショップサーバ１００との通信
処理、さらに、各通信処理に際してのデータ暗号処理等
を実行する制御手段３３０を有する。制御手段３３０
は、先に説明したショップサーバの制御手段と同様、暗
号処理手段、通信処理手段としての機能も有する。その
構成は、図４を用いて説明した構成と同様である。制御
手段３３０の暗号処理手段において実行される暗号処理
において使用される鍵データ等は、制御手段内部の記憶
手段にセキュアに格納されている。ユーザ機器認証サー
バ（ＤＡＳ）３００が格納する暗号鍵等の暗号処理用デ
ータとしては、ユーザ機器認証サーバ（ＤＡＳ）の秘密
鍵：ＫｓＤＡＳ、ユーザ機器認証サーバ（ＤＡＳ）の公
開鍵証明書Ｃｅｒｔ＿ＤＡＳ、公開鍵証明書の発行機関
である公開鍵証明書発行局としての認証局（ＣＡ：Cert
ificate Authority）の公開鍵ＫｐＣＡがある。
【００５８】（ユーザ機器）図７にユーザ機器２００の
構成を示す。ユーザ機器は、コンテンツの購入を実行
し、購入したコンテンツの利用、すなわちコンテンツ再
生、実行を行なう例えばコンテンツ再生機器であり、購
入管理データベース２２０を有する。購入管理データベ
ース２２０のデータ構成を図８に示す。購入管理データ
ベースは、コンテンツ取り引きを実行する際に、ユーザ
機器で生成発行するコンテンツ取り引き識別子としての
トランザクションＩＤ、取り引き対象コンテンツの識別
子であるコンテンツＩＤ、コンテンツ取り引きを実行す
るショップサーバの識別子であるショップＩＤ、ユーザ
機器におけるコンテンツ取り引き処理のステータスを示
すステータスの各情報、さらに、ユーザ機器の機器識別
子である機器ＩＤを持つ。ステータスは、後段で詳細に
説明するがコンテンツの取り引きに伴う複数の処理の進
行に応じて更新される。
【００５９】ユーザ機器２００は、ショップサーバ１０
０、ユーザ機器認証サーバ３００との通信処理、さら
に、各通信処理に際してのデータ暗号処理等を実行する
制御手段２３０を有する。制御手段２３０は、先に説明
したショップサーバの制御手段と同様、暗号処理手段、
通信処理手段としての機能も有する。その構成は、図４
を用いて説明した構成と同様である。制御手段２３０の
暗号処理手段において実行される暗号処理において使用
される鍵データ等は、制御手段内部の記憶手段にセキュ
アに格納されている。ユーザ機器２００が格納する暗号
鍵等の暗号処理用データとしては、ユーザ機器の秘密
鍵：ＫｓＤＥＶ、ユーザ機器の公開鍵証明書Ｃｅｒｔ＿
ＤＥＶ、公開鍵証明書の発行機関である公開鍵証明書発
行局としての認証局（ＣＡ：Certificate Authority）
の公開鍵ＫｐＣＡ、コンテンツをユーザ機器の例えばハ
ードディスク等の記憶手段に格納する際の暗号化鍵とし
て適用する保存鍵Ｋｓｔｏがある。
【００６０】［公開鍵証明書］上記ショップサーバ（Ｓ
ＨＯＰ）１００、ユーザ機器（ＤＥＶＩＣＥ）２００、
ユーザ機器認証サーバ（ＤＡＳ：Device Authenticatio
n Server）３００の保有する公開鍵証明書について図９
を用いて説明する。
【００６１】公開鍵証明書は、公開鍵を用いた暗号デー
タの送受信、あるいはデータ送受信を行なう２者間での
相互認証等の処理において、使用する公開鍵が正当な利
用者の有する公開鍵であることを第三者、すなわち発行
局（ＣＡ：Certificate Authority）が証明したもので
ある。公開鍵証明書のフォーマットの概略を図９（ａ）
に示す。
【００６２】バージョン（version）は、証明書フォー
マットのバージョンを示す。証明書の通し番号は、シリ
アルナンバ（Serial Number）であり、公開鍵証明書発
行局（ＣＡ）によって設定される公開鍵証明書のシリア
ルナンバである。署名アルゴリズム識別子、アルゴリズ
ムパラメータ（Signature algorithm Identifier algor
ithm parameter）は、公開鍵証明書の署名アルゴリズム
とそのパラメータを記録するフィールドである。なお、
署名アルゴリズムとしては、楕円曲線暗号およびＲＳＡ
があり、楕円曲線暗号が適用されている場合はパラメー
タおよび鍵長が記録され、ＲＳＡが適用されている場合
には鍵長が記録される。発行局の名前は、公開鍵証明書
の発行者、すなわち公開鍵証明書発行局（ＣＡ）の名称
が識別可能な形式（Distinguished Name）で記録される
フィールドである。証明書の有効期限(validity)は、証
明書の有効期限である開始日時、終了日時が記録され
る。公開鍵証明書の利用者名（ＩＤ）は、ユーザである
認証対象者の名前が記録される。具体的には例えばユー
ザ機器のＩＤや、サービス提供主体のＩＤ等である。利
用者公開鍵（subject Public Key Info algorithm subj
ect Public key）は、ユーザの公開鍵情報としての鍵ア
ルゴリズム、鍵情報そのものを格納するフィールドであ
る。発行局が付ける署名は、公開鍵証明書発行局（Ｃ
Ａ）の秘密鍵を用いて公開鍵証明書のデータに対して実
行される電子署名であり、公開鍵証明書の利用者は、公
開鍵証明書発行局（ＣＡ）の公開鍵を用いて検証を行な
い、公開鍵証明書の改竄有無がチェック可能となってい
る。
【００６３】公開鍵暗号方式を用いた電子署名の生成方
法について、図１０を用いて説明する。図１０に示す処
理は、ＥＣ−ＤＳＡ（（Elliptic Curve Digital Signa
tureAlgorithm）、IEEE P1363/D3）を用いた電子署名デ
ータの生成処理フローである。なお、ここでは公開鍵暗
号として楕円曲線暗号（Elliptic Curve Cryptography
（以下、ＥＣＣと呼ぶ））を用いた例を説明する。な
お、本発明のデータ処理装置においては、楕円曲線暗号
以外にも、同様の公開鍵暗号方式における、例えばＲＳ
Ａ暗号（（Rivest、Shamir、Adleman）など（ANSI X9.3
1））を用いることも可能である。
【００６４】図１０の各ステップについて説明する。ス
テップＳ１において、ｐを標数、a、bを楕円曲線の係数
（楕円曲線：４ａ3＋２７ｂ2≠０（ｍｏｄ ｐ）、Ｇを
楕円曲線上のベースポイント、rをＧの位数、Ｋｓを秘
密鍵（０＜Ｋｓ＜ｒ）とする。ステップＳ２おいて、メ
ッセージＭのハッシュ値を計算し、f=Hash(M)とする。
【００６５】ここで、ハッシュ関数を用いてハッシュ値
を求める方法を説明する。ハッシュ関数とは、メッセー
ジを入力とし、これを所定のビット長のデータに圧縮
し、ハッシュ値として出力する関数である。ハッシュ関
数は、ハッシュ値（出力）から入力を予測することが難
しく、ハッシュ関数に入力されたデータの1ビットが変
化したとき、ハッシュ値の多くのビットが変化し、ま
た、同一のハッシュ値を持つ異なる入力データを探し出
すことが困難である特徴を有する。ハッシュ関数として
は、ＭＤ４、ＭＤ５、ＳＨＡ−１などが用いられる場合
もあるし、ＤＥＳ−ＣＢＣが用いられる場合もある。こ
の場合は、最終出力値となるＭＡＣ（チェック値：ＩＣ
Ｖに相当する）がハッシュ値となる。
【００６６】続けて、ステップＳ３で、乱数ｕ（０＜ｕ
＜ｒ）を生成し、ステップＳ４でベースポイントをｕ倍
した座標Ｖ（Ｘｖ，Ｙｖ）を計算する。なお、楕円曲線
上の加算、２倍算は次のように定義されている。
【００６７】
【数１】P=(Ｘａ，Ｙａ),Q=(Ｘｂ，Ｙｂ),R=(Ｘｃ,Ｙ
ｃ)=P+Qとすると、 P≠Qの時（加算）、 Xｃ=λ2−Ｘａ−Ｘｂ Ｙｃ=λ×(Ｘａ−Ｘｃ)−Ｙａ λ=(Ｙｂ−Ｙａ)／(Ｘｂ−Ｘａ) P=Qの時（2倍算）、 Ｘｃ=λ2−２Ｘａ Ｙｃ=λ×(Ｘａ−Ｘｃ)−Ｙａ λ=(３(Ｘａ)2＋ａ)／(２Ｙａ)
【００６８】これらを用いて点Ｇのｕ倍を計算する（速
度は遅いが、最もわかりやすい演算方法として次のよう
に行う。Ｇ、２×Ｇ、４×Ｇ・・を計算し、uを2進数展
開して1が立っているところに対応する２i×Ｇ（Ｇをｉ
回２倍算した値（ｉはｕのＬＳＢから数えた時のビット
位置））を加算する。
【００６９】ステップＳ５で、ｃ＝Ｘｖｍｏｄ ｒを計
算し、ステップＳ６でこの値が０になるかどうか判定
し、０でなければステップＳ７でｄ＝［（ｆ＋ｃＫｓ）
／ｕ］ｍｏｄ ｒを計算し、ステップＳ８でｄが０であ
るかどうか判定し、ｄが０でなければ、ステップＳ９で
ｃおよびｄを電子署名データとして出力する。仮に、ｒ
を１６０ビット長の長さであると仮定すると、電子署名
データは３２０ビット長となる。
【００７０】ステップＳ６において、ｃが０であった場
合、ステップＳ３に戻って新たな乱数を生成し直す。同
様に、ステップＳ８でｄが０であった場合も、ステップ
Ｓ３に戻って乱数を生成し直す。
【００７１】次に、公開鍵暗号方式を用いた電子署名の
検証方法を、図１１を用いて説明する。ステップＳ１１
で、Ｍをメッセージ、pを標数、a、bを楕円曲線の係数
（楕円曲線：ｙ2=ｘ3＋ａｘ＋ｂ）、Ｇを楕円曲線上の
ベースポイント、rをＧの位数、ＧおよびＫｓ×Gを公開
鍵（０＜Ｋｓ＜ｒ）とする。ステップＳ１２で電子署名
データｃおよびｄが０＜ｃ＜ｒ、０＜ｄ＜ｒを満たすか
検証する。これを満たしていた場合、ステップＳ１３
で、メッセージＭのハッシュ値を計算し、ｆ＝Ｈａｓｈ
（Ｍ）とする。次に、ステップＳ１４でh=1/d mod rを
計算し、ステップＳ１５でｈ１＝ｆｈ ｍｏｄ ｒ、ｈ
２=ｃｈ ｍｏｄ ｒを計算する。
【００７２】ステップＳ１６において、既に計算したｈ
１およびｈ２を用い、点Ｐ＝（Ｘｐ，Ｙｐ）＝ｈ１×Ｇ
＋ｈ２・Ｋｓ×Ｇを計算する。電子署名検証者は、公開
鍵ＧおよびＫｓ×Ｇを知っているので、図１０のステッ
プＳ４と同様に楕円曲線上の点のスカラー倍の計算がで
きる。そして、ステップＳ１７で点Ｐが無限遠点かどう
か判定し、無限遠点でなければステップＳ１８に進む
（実際には、無限遠点の判定はステップＳ１６でできて
しまう。つまり、Ｐ＝（Ｘ，Ｙ）、Ｑ＝（Ｘ，−Ｙ）の
加算を行うと、λが計算できず、Ｐ＋Ｑが無限遠点であ
ることが判明している）。ステップＳ１８でＸｐ ｍｏ
ｄ ｒを計算し、電子署名データｃと比較する。最後
に、この値が一致していた場合、ステップＳ１９に進
み、電子署名が正しいと判定する。
【００７３】電子署名が正しいと判定された場合、デー
タは改竄されておらず、公開鍵に対応した秘密鍵を保持
する者が電子署名を生成したことがわかる。
【００７４】ステップＳ１２において、電子署名データ
ｃまたはｄが、０＜ｃ＜ｒ、０＜ｄ＜ｒを満たさなかっ
た場合、ステップＳ２０に進む。また、ステップＳ１７
において、点Ｐが無限遠点であった場合もステップＳ２
０に進む。さらにまた、ステップＳ１８において、Ｘｐ
ｍｏｄ ｒの値が、電子署名データｃと一致していなか
った場合にもステップＳ２０に進む。
【００７５】ステップＳ２０において、電子署名が正し
くないと判定された場合、データは改竄されているか、
公開鍵に対応した秘密鍵を保持する者が電子署名を生成
したのではないことがわかる。
【００７６】公開鍵証明書には、発行局の署名がなさ
れ、公開鍵利用者による署名検証により、証明書の改竄
がチェック可能な構成となっている。図９に戻り説明を
つづける。図９（ｂ）がユーザ機器に格納されるユーザ
機器の公開鍵証明書：Ｃｅｒｔ＿ＤＥＶであり、ユーザ
機器ＩＤと、ユーザ機器の公開鍵ＫｐＤＥＶを格納して
いる。図９（ｃ）はショップサーバに格納されるショッ
プサーバの公開鍵証明書：Ｃｅｒｔ＿ＳＨＯＰであり、
ショップＩＤと、ショップサーバの公開鍵ＫｐＳＨＯＰ
を格納している。図９（ｄ）はユーザ機器認証サーバに
格納されるユーザ機器認証サーバの公開鍵証明書：Ｃｅ
ｒｔ＿ＤＡＳであり、ユーザ機器認証サーバＩＤと、ユ
ーザ機器認証サーバの公開鍵ＫｐＤＡＳを格納してい
る。このように、ユーザ機器、ショップサーバ、ユーザ
機器認証サーバがそれぞれ公開鍵証明書を保有する。
【００７７】［コンテンツ購入処理］次に、図１に戻
り、ユーザ機器が、ショップサーバからコンテンツを購
入して利用する処理について説明する。図１の番号
（１）から（２０）の順に処理が進行する。各番号順に
処理の詳細を説明する。なお、本実施例ではエンティテ
イ間の通信において相互認証処理（（１）、（７）、
（１１））を行なったものを述べているが、必要に応じ
て省略しても構わない。
【００７８】（１）相互認証 コンテンツをショップサーバ１００から購入しようとす
るユーザ機器２００は、ショップサーバとの間で相互認
証処理を行なう。データ送受信を実行する２つの手段間
では、相互に相手が正しいデータ通信者であるか否かを
確認して、その後に必要なデータ転送を行なうことが行
われる。相手が正しいデータ通信者であるか否かの確認
処理が相互認証処理である。相互認証処理時にセッショ
ン鍵の生成を実行して、生成したセッション鍵を共有鍵
として暗号化処理を実行してデータ送信を行なう構成が
１つの好ましいデータ転送方式である。
【００７９】共通鍵暗号方式を用いた相互認証方法を、
図１２を用いて説明する。図１２において、共通鍵暗号
方式としてＤＥＳを用いているが、同様な共通鍵暗号方
式であればいずれでもよい。
【００８０】まず、Ｂが６４ビットの乱数Ｒｂを生成
し、Ｒｂおよび自己のＩＤであるＩＤ（ｂ）をＡに送信
する。これを受信したＡは、新たに６４ビットの乱数Ｒ
ａを生成し、Ｒａ、Ｒｂ、ＩＤ（ｂ）の順に、ＤＥＳの
ＣＢＣモードで鍵Ｋａｂを用いてデータを暗号化し、Ｂ
に返送する。
【００８１】これを受信したＢは、受信データを鍵Ｋａ
ｂで復号化する。受信データの復号化方法は、まず、暗
号文Ｅ１を鍵Ｋａｂで復号化し、乱数Ｒａを得る。次
に、暗号文Ｅ２を鍵Ｋａｂで復号化し、その結果とＥ１
を排他的論理和し、Ｒｂを得る。最後に、暗号文Ｅ３を
鍵Ｋａｂで復号化し、その結果とＥ２を排他的論理和
し、ＩＤ(ｂ)を得る。こうして得られたＲａ、Ｒｂ、Ｉ
Ｄ(ｂ)の内、ＲｂおよびＩＤ(ｂ)が、Ｂが送信したもの
と一致するか検証する。この検証に通った場合、ＢはＡ
を正当なものとして認証する。
【００８２】次にＢは、認証後に使用するセッション鍵
（Session Key（以下、Ｋｓｅｓとする））を生成する
（生成方法は、乱数を用いる）。そして、Ｒｂ、Ｒａ、
Ｋｓｅｓの順に、ＤＥＳのＣＢＣモードで鍵Ｋａｂを用
いて暗号化し、Ａに返送する。
【００８３】これを受信したＡは、受信データを鍵Ｋａ
ｂで復号化する。受信データの復号化方法は、Ｂの復号
化処理と同様であるので、ここでは詳細を省略する。こ
うして得られたＲｂ、Ｒａ、Ｋｓｅｓの内、Ｒｂおよび
Ｒａが、Ａが送信したものと一致するか検証する。この
検証に通った場合、ＡはＢを正当なものとして認証す
る。互いに相手を認証した後には、セッション鍵Ｋｓｅ
ｓは、認証後の秘密通信のための共通鍵として利用され
る。
【００８４】なお、受信データの検証の際に、不正、不
一致が見つかった場合には、相互認証が失敗したものと
して処理を中断する。
【００８５】次に、公開鍵暗号方式である１６０ビット
長の楕円曲線暗号を用いた相互認証方法を、図１３を用
いて説明する。図１３において、公開鍵暗号方式として
ＥＣＣを用いているが、前述のように同様な公開鍵暗号
方式であればいずれでもよい。また、鍵サイズも１６０
ビットでなくてもよい。図１３において、まずＢが、６
４ビットの乱数Ｒｂを生成し、Aに送信する。これを受
信したＡは、新たに６４ビットの乱数Ｒａおよび標数ｐ
より小さい乱数Ａｋを生成する。そして、ベースポイン
トＧをＡｋ倍した点Ａｖ＝Ａｋ×Ｇを求め、Ｒａ、Ｒ
ｂ、Ａｖ（X座標とY座標）に対する電子署名Ａ．Ｓｉｇ
を生成し、Ａの公開鍵証明書とともにＢに返送する。こ
こで、ＲａおよびＲｂはそれぞれ６４ビット、ＡｖのＸ
座標とＹ座標がそれぞれ１６０ビットであるので、合計
４４８ビットに対する電子署名を生成する。
【００８６】公開鍵証明書を利用する際には、利用者は
自己が保持する公開鍵証明書発行局（ＣＡ）４１０の公
開鍵を用い、当該公開鍵証明書の電子署名を検証し、電
子署名の検証に成功した後に公開鍵証明書から公開鍵を
取り出し、当該公開鍵を利用する。従って、公開鍵証明
書を利用する全ての利用者は、共通の公開鍵証明書発行
局（ＣＡ）の公開鍵を保持している必要がある。なお、
電子署名の検証方法については、図１１で説明したので
その詳細は省略する。
【００８７】Ａの公開鍵証明書、Ｒａ、Ｒｂ、Ａｖ、電
子署名Ａ．Ｓｉｇを受信したＢは、Ａが送信してきたＲ
ｂが、Ｂが生成したものと一致するか検証する。その結
果、一致していた場合には、Ａの公開鍵証明書内の電子
署名を認証局の公開鍵で検証し、Ａの公開鍵を取り出
す。そして、取り出したＡの公開鍵を用い電子署名Ａ．
Ｓｉｇを検証する。電子署名の検証に成功した後、Ｂは
Ａを正当なものとして認証する。
【００８８】次に、Ｂは、標数ｐより小さい乱数Ｂｋを
生成する。そして、ベースポイントＧをＢｋ倍した点Ｂ
ｖ＝Ｂｋ×Ｇを求め、Ｒｂ、Ｒａ、Ｂｖ（Ｘ座標とＹ座
標）に対する電子署名Ｂ．Ｓｉｇを生成し、Ｂの公開鍵
証明書とともにＡに返送する。
【００８９】Ｂの公開鍵証明書、Ｒｂ、Ｒａ、Ｂｖ、電
子署名Ｂ．Ｓｉｇを受信したＡは、Ｂが送信してきたＲ
ａが、Ａが生成したものと一致するか検証する。その結
果、一致していた場合には、Ｂの公開鍵証明書内の電子
署名を認証局の公開鍵で検証し、Ｂの公開鍵を取り出
す。そして、取り出したＢの公開鍵を用い電子署名Ｂ．
Ｓｉｇを検証する。電子署名の検証に成功した後、Ａは
Ｂを正当なものとして認証する。
【００９０】両者が認証に成功した場合には、ＢはＢｋ
×Ａｖ（Ｂｋは乱数だが、Ａｖは楕円曲線上の点である
ため、楕円曲線上の点のスカラー倍計算が必要）を計算
し、ＡはＡｋ×Ｂｖを計算し、これら点のＸ座標の下位
６４ビットをセッション鍵として以降の通信に使用する
（共通鍵暗号を６４ビット鍵長の共通鍵暗号とした場
合）。もちろん、Ｙ座標からセッション鍵を生成しても
よいし、下位６４ビットでなくてもよい。なお、相互認
証後の秘密通信においては、送信データはセッション鍵
で暗号化されるだけでなく、電子署名も付されることが
ある。
【００９１】電子署名の検証や受信データの検証の際
に、不正、不一致が見つかった場合には、相互認証が失
敗したものとして処理を中断する。
【００９２】このような相互認証処理において、生成し
たセッション鍵を用いて、送信データを暗号化して、相
互にデータ通信を実行する。
【００９３】（２）トランザクションＩＤ、購入要求デ
ータ生成、および （３）購入要求データ送信 上述のショップサーバ１００とユーザ機器２００間の相
互認証が成功すると、ユーザ機器２００は、コンテンツ
の購入要求データを生成する。購入要求データの構成を
図１４（ａ）に示す。購入要求データは、コンテンツ購
入の要求先であるショップサーバ１００の識別子である
ショップＩＤ、コンテンツ取り引きの識別子として、ユ
ーザ機器２００の暗号処理手段が例えば乱数に基づいて
生成するトランザクションＩＤ、さらに、ユーザ機器が
購入を希望するコンテンツの識別子としてのコンテンツ
ＩＤの各データを有し、これらのデータに対するユーザ
機器の電子署名が付加されている。さらに、購入要求デ
ータには、ユーザ機器の公開鍵証明書が添付され、ショ
ップサーバ１００に送付される。なお、公開鍵証明書が
既に前述の相互認証処理、あるいはその以前の処理にお
いて、ショップ側に送付済みの場合は、必ずしも改めて
送付する必要はない。
【００９４】（４）受信データ検証 図１４（ａ）に示す購入要求データをユーザ機器２００
から受信したショップサーバ１００は、受信データの検
証処理を実行する。検証処理の詳細について図１５を用
いて説明する。まず、ショップサーバ１００は、受信デ
ータ中のユーザ機器の公開鍵証明書Ｃｅｒｔ＿ＤＥＶの
検証（Ｓ５１）を行なう。これは前述したように、公開
鍵証明書に含まれる発行局（ＣＡ）の署名を検証する処
理（図１１参照）として実行され、発行局の公開鍵：Ｋ
ｐＣＡを適用して実行される。
【００９５】検証がＯＫ、すなわち公開鍵証明書の改竄
がないと判定（Ｓ５２でＹｅｓ）されると、Ｓ５３に進
む。検証が非成立の場合（Ｓ５２でＮｏ）は、Ｓ５７で
公開鍵証明書に改竄ありと判定され、その公開鍵証明書
を利用した処理が中止される。Ｓ５３では、公開鍵証明
書からユーザ機器の公開鍵：ＫｐＤＥＶが取り出され、
ステップＳ５４で公開鍵：ＫｐＤＥＶを用いた購入要求
データのユーザ機器署名の検証処理（図１１参照）が実
行される。検証がＯＫ、すなわち購入要求データの改竄
がないと判定（Ｓ５５でＹｅｓ）されると、Ｓ５６に進
み受信データが正当なコンテンツ購入要求データである
と判定される。検証が非成立の場合（Ｓ５５でＮｏ）
は、Ｓ５７で購入要求データが改竄ありと判定され、そ
の購入要求データに対する処理が中止される。
【００９６】（５）暗号化コンテンツおよび暗号化コン
テンツ鍵データ１（ショップ）送信 ショップサーバ１００において、購入要求データの検証
が完了し、データ改竄のない正当なコンテンツ購入要求
であると判定すると、ショップサーバ１００は、暗号化
コンテンツおよび暗号化コンテンツ鍵データ１（ショッ
プ）をユーザ機器に送信する。これらは、いずれもコン
テンツデータベース１１０に格納されたデータであり、
コンテンツをコンテンツキーで暗号化した暗号化コンテ
ンツ：Ｋｃ（content）と、コンテンツキー：Ｋｃをユ
ーザ機器認証サーバ（ＤＡＳ）３００の公開鍵で暗号化
した暗号化コンテンツ鍵データ：ＫｐＤＡＳ（Ｋｃ）で
ある。
【００９７】暗号化コンテンツ鍵データ１（ショップ）
の構成を図１４（ｂ）に示す。暗号化コンテンツ鍵デー
タ１（ショップ）は、コンテンツ購入の要求元であるユ
ーザ機器２００の識別子であるユーザ機器ＩＤ、購入要
求データ（図１４（ａ）のユーザ機器公開鍵証明書を除
いたデータ）、コンテンツ取り引きに伴いショップサー
バ１００が生成したショップ処理Ｎｏ．、暗号化コンテ
ンツ鍵データ：ＫｐＤＡＳ（Ｋｃ）を有し、これらのデ
ータに対するショップサーバ１００の電子署名が付加さ
れている。さらに、暗号化コンテンツ鍵データ１（ショ
ップ）には、ショップサーバ１００の公開鍵証明書が添
付され、ユーザ機器２００に送付される。なお、ショッ
プサーバ公開鍵証明書が既に前述の相互認証処理、ある
いはその以前の処理において、ユーザ機器側に送付済み
の場合は、必ずしも改めて送付する必要はない。
【００９８】（６）受信データ検証 ショップサーバ１００から暗号化コンテンツ：Ｋｃ（co
ntent）と、図１４（ｂ）に示す暗号化コンテンツ鍵デ
ータ１（ショップ）を受信したユーザ機器２００は、暗
号化コンテンツ鍵データ１（ショップ）の検証処理を実
行する。この検証処理は、先に説明した図１５の処理フ
ローと同様の処理であり、ユーザ機器２００は、まずシ
ョップサーバ１００から受領したショップサーバの公開
鍵証明書の検証を発行局（ＣＡ）の公開鍵ＫｐＣＡを用
いて実行し、次に公開鍵証明書から取り出したショップ
サーバの公開鍵ＫｐＳＨＯＰを用いて図１４（ｂ）に示
す暗号化コンテンツ鍵データ１（ショップ）のショップ
署名の検証を実行する。
【００９９】（７）相互認証 ユーザ機器２００が、ショップサーバ１００から暗号化
コンテンツ：Ｋｃ（content）と暗号化コンテンツ鍵デ
ータ１（ショップ）を受信し、暗号化コンテンツ鍵デー
タ１（ショップ）の検証を終えると、ユーザ機器２００
は、ユーザ機器認証サーバ３００にアクセスし、ユーザ
機器２００と、ユーザ機器認証サーバ３００間において
相互認証処理を実行する。この処理は、前述のショップ
サーバ１００とユーザ機器２００間の相互認証処理と同
様の手続きで実行される。
【０１００】（８）暗号化コンテンツ鍵データ（ユーザ
機器）および暗号化コンテンツ鍵かけかえ要求送信 ユーザ機器２００とユーザ機器認証サーバ３００との間
の相互認証が成立すると、ユーザ機器２００は、ユーザ
機器認証サーバ３００に対して、先にショップサーバ１
００から受信した暗号化コンテンツ鍵ＫｐＤＡＳ（Ｋ
ｃ）を含む暗号化コンテンツ鍵データ（ユーザ機器）
と、暗号化コンテンツ鍵かけかえ要求を送信する。
【０１０１】暗号化コンテンツ鍵データ（ユーザ機器）
の構成を図１４（ｃ）に示す。暗号化コンテンツ鍵デー
タ（ユーザ機器）は、暗号化コンテンツ鍵かけかえ要求
の要求先であるユーザ機器認証サーバ３００の識別子で
あるユーザ機器認証サーバＩＤ、ショップサーバ１００
から受領した暗号化コンテンツ鍵データ（図１４（ｂ）
のショップ公開鍵証明書を除いたデータ）、を有し、こ
れらのデータに対するユーザ機器２００の電子署名が付
加されている。さらに、暗号化コンテンツ鍵データ（ユ
ーザ機器）には、ショップサーバ１００の公開鍵証明書
と、ユーザ機器２００の公開鍵証明書が添付され、ユー
ザ機器認証サーバ３００に送付される。なお、ユーザ機
器認証サーバ３００がユーザ機器公開鍵証明書、ショッ
プサーバ公開鍵証明書をすでに保有している場合は、必
ずしも改めて送付する必要はない。
【０１０２】（９）受信データ検証 ユーザ機器２００から暗号化コンテンツ鍵データ（ユー
ザ機器）および暗号化コンテンツ鍵かけかえ要求（図１
４（ｃ））を受信したユーザ機器認証サーバ３００は、
暗号化コンテンツ鍵かけかえ要求の検証処理を実行す
る。この検証処理は、先に説明した図１５の処理フロー
と同様の処理であり、ユーザ機器認証サーバ３００は、
まずユーザ機器２００から受領したユーザ機器の公開鍵
証明書の検証を発行局（ＣＡ）の公開鍵ＫｐＣＡを用い
て実行し、次に公開鍵証明書から取り出したユーザ機器
の公開鍵ＫｐＤＥＶを用いて、図１４（ａ）に示す購入
要求データおよび図１４（ｃ）に示す暗号化コンテンツ
鍵データ（ユーザ機器）の電子署名の検証を実行する。
さらに、ショップサーバの公開鍵証明書の検証を発行局
（ＣＡ）の公開鍵ＫｐＣＡを用いて実行し、次に公開鍵
証明書から取り出したショップサーバの公開鍵ＫｐＳＨ
ＯＰを用いて図１４（ｃ）に示す暗号化コンテンツ鍵デ
ータ（ユーザ機器）に含まれる（５）暗号化コンテンツ
鍵データ１のショップ署名の検証を実行する。
【０１０３】（１０）暗号化コンテンツ鍵かけかえ処
理、 ユーザ機器認証サーバ３００において、ユーザ機器２０
０から受信した暗号化コンテンツ鍵データ（ユーザ機
器）および暗号化コンテンツ鍵かけかえ要求の検証が終
了し、正当な鍵かけかえ要求であると判定すると、ユー
ザ機器認証サーバ３００は、暗号化コンテンツ鍵データ
（ユーザ機器）に含まれる暗号化コンテンツ鍵、すなわ
ち、コンテンツ鍵：Ｋｃをユーザ機器認証サーバ（ＤＡ
Ｓ）３００の公開鍵ＫｐＤＡＳで暗号化したデータ：Ｋ
ｐＤＡＳ（Ｋｃ）をユーザ機器認証サーバ３００の秘密
鍵ＫｓＤＡＳで復号してコンテンツ鍵Ｋｃを取得し、さ
らにコンテンツ鍵Ｋｃをユーザ機器の公開鍵：ＫｐＤＥ
Ｖで暗号化した暗号化コンテンツ鍵：ＫｐＤＥＶ（Ｋ
ｃ）を生成する。すなわち、ＫｐＤＡＳ（Ｋｃ）→Ｋｃ
→ＫｐＤＥＶ（Ｋｃ）の鍵かけかえ処理を実行する。
【０１０４】図１６にユーザ機器認証サーバ３００にお
いて実行される暗号化コンテンツ鍵かけかえ処理のフロ
ーを示す。まず、ユーザ機器認証サーバ３００は、ユー
ザ機器２００から受信した暗号化コンテンツ鍵データ
（ユーザ機器）から、ユーザ機器認証サーバ（ＤＡＳ）
３００の公開鍵ＫｐＤＡＳで暗号化したコンテンツ鍵デ
ータ：ＫｐＤＡＳ（Ｋｃ）を取り出す（Ｓ６１）。次
に、ユーザ機器認証サーバ３００の秘密鍵ＫｓＤＡＳで
復号してコンテンツ鍵Ｋｃを取得（Ｓ６２）する。次
に、復号により取得したコンテンツ鍵Ｋｃをユーザ機器
の公開鍵：ＫｐＤＥＶで再暗号化して暗号化コンテンツ
鍵：ＫｐＤＥＶ（Ｋｃ）を生成する（Ｓ６３）。これら
の処理が終了すると、ライセンス管理データベース（図
６参照）のステータスを「鍵かけかえ完了」に設定す
る。
【０１０５】（１１）相互認証 ユーザ機器認証サーバ３００において、上述の暗号化コ
ンテンツ鍵の鍵かけかえ処理が完了すると、ユーザ機器
認証サーバ３００は、ショップサーバ１００にアクセス
し、ユーザ機器認証サーバ３００とショップサーバ１０
０間において相互認証処理を実行する。この処理は、前
述のショップサーバ１００とユーザ機器２００間の相互
認証処理と同様の手続きで実行される。
【０１０６】（１２）暗号化コンテンツデータ送信 ユーザ機器認証サーバ３００とショップサーバ１００間
の相互認証が成立すると、ユーザ機器認証サーバ３００
は、暗号化コンテンツ鍵データ（ＤＡＳ）をショップサ
ーバ１００に送信する。
【０１０７】暗号化コンテンツ鍵データ（ＤＡＳ）の構
成を図１７（ｄ）に示す。暗号化コンテンツ鍵データ
（ＤＡＳ）は、コンテンツ購入の要求先であるショップ
サーバ１００の識別子であるショップＩＤ、暗号化コン
テンツ鍵データ（ユーザ機器）（図１４（ｃ）のショッ
プおよびユーザ機器公開鍵証明書を除いたデータ）、さ
らに、前述の鍵かけかえ処理により、ユーザ機器認証サ
ーバ３００が生成した暗号化コンテンツ鍵データ：Ｋｐ
ＤＥＶ（Ｋｃ）を有し、これらのデータに対するユーザ
機器認証サーバ３００の電子署名が付加されている。さ
らに、暗号化コンテンツ鍵データ（ＤＡＳ）には、ユー
ザ機器認証サーバ３００と、ユーザ機器２００の公開鍵
証明書が添付され、ショップサーバ１００に送付され
る。なお、ショップサーバが、これらの公開鍵証明書を
既に保有済みである場合は、必ずしも改めて送付する必
要はない。
【０１０８】また、ユーザ機器認証サーバ３００が信頼
できる第三者機関であると認められる存在である場合
は、暗号化コンテンツ鍵データ（ＤＡＳ）は、図１７
（ｄ）に示すようにユーザ機器の生成した（８）暗号化
コンテンツ鍵データ（ユーザ機器）をそのまま含むデー
タ構成とすることなく、図１８（ｄ’）に示すように、
ユーザ機器ＩＤ、トランザクションＩＤ、コンテンツＩ
Ｄ、ショップ処理ＮＯ、ユーザデバイスの公開鍵で暗号
化したコンテンツ鍵ＫｐＤＥＶ（Ｋｃ）の各データを、
ユーザ機器認証サーバ３００が抽出して、これらに署名
を付加して暗号化コンテンツ鍵データ（ＤＡＳ）として
もよい。この場合は、（８）暗号化コンテンツ鍵データ
（ユーザ機器）の検証が不要となるので、添付する公開
鍵証明書は、ユーザ機器認証サーバ３００の公開鍵証明
書のみでよい。
【０１０９】（１３）受信データ検証 ユーザ機器認証サーバ３００から暗号化コンテンツ鍵デ
ータ（ＤＡＳ）（図１７（ｄ））を受信したショップサ
ーバ１００は、暗号化コンテンツ鍵データ（ＤＡＳ）の
検証処理を実行する。この検証処理は、先に説明した図
１５の処理フローと同様の処理であり、ショップサーバ
１００は、まずユーザ機器認証サーバ３００から受領し
たユーザ機器認証サーバの公開鍵証明書の検証を発行局
（ＣＡ）の公開鍵ＫｐＣＡを用いて実行し、次に公開鍵
証明書から取り出したユーザ機器認証サーバ３００の公
開鍵ＫｐＤＡＳを用いて図１７（ｄ）に示す暗号化コン
テンツ鍵データ（ＤＡＳ）の電子署名の検証を実行す
る。さらに、ユーザ機器の公開鍵証明書の検証を発行局
（ＣＡ）の公開鍵ＫｐＣＡを用いて実行し、次に公開鍵
証明書から取り出したユーザ機器の公開鍵ＫｐＤＥＶを
用いて図１７（ｄ）に示す暗号化コンテンツ鍵データ
（ＤＡＳ）に含まれる（８）暗号化コンテンツ鍵データ
（ユーザ機器）のユーザ機器署名の検証を実行する。さ
らに、また、自己の公開鍵ＫｐＳＨＯＰを用いて、暗号
化コンテンツデータ（ユーザ機器）を検証するようにし
てもよい。
【０１１０】なお、先に説明した図１８（ｄ’）の簡略
化した暗号化コンテンツ鍵データ（ＤＡＳ）をショップ
サーバ１００が受領した場合は、ショップサーバ１００
は、ユーザ機器認証サーバの公開鍵証明書の検証を発行
局（ＣＡ）の公開鍵ＫｐＣＡを用いて実行し、次に公開
鍵証明書から取り出したユーザ機器認証サーバ３００の
公開鍵ＫｐＤＡＳを用いて図１８（ｄ’）に示す暗号化
コンテンツ鍵データ（ＤＡＳ）の電子署名の検証を実行
するのみの処理となる。
【０１１１】（１４）相互認証、および （１５）暗号化コンテンツ鍵要求データ送信 次に、ユーザ機器２００は、暗号化コンテンツ鍵要求デ
ータをショップサーバ１００に対して送信する。なお、
この際、前の要求と異なるセッションで要求を実行する
場合は、再度相互認証を実行して、相互認証が成立した
ことを条件として暗号化コンテンツ鍵要求データがユー
ザ機器２００からショップサーバ１００に送信される。
【０１１２】暗号化コンテンツ鍵要求データの構成を図
１７（ｅ）に示す。暗号化コンテンツ鍵要求データは、
コンテンツ購入の要求先であるショップサーバ１００の
識別子であるショップＩＤ、先にユーザ機器２００が生
成したコンテンツ取り引きの識別子であるトランザクシ
ョンＩＤ、さらに、ユーザ機器が購入を希望するコンテ
ンツの識別子としてのコンテンツＩＤ、さらに、先にシ
ョップが生成し暗号化コンテンツ鍵データ１（ショッ
プ）としてユーザ機器２００に送信してきたデータ（図
１４（ｂ）参照）中に含まれるショップ処理Ｎｏ．を有
し、これらのデータに対するユーザ機器の電子署名が付
加されている。さらに、暗号化コンテンツ鍵要求データ
には、ユーザ機器の公開鍵証明書が添付され、ショップ
サーバ１００に送付される。なお、公開鍵証明書が既に
ショップ側に保管済みの場合は、必ずしも改めて送付す
る必要はない。
【０１１３】（１６）検証処理、および （１７）課金処理 暗号化コンテンツ鍵要求データをユーザ機器から受信し
たショップサーバ１００は、暗号化コンテンツ鍵要求デ
ータの検証処理を実行する。これは、図１５を用いて説
明したと同様の処理である。データ検証が済むと、ショ
ップサーバ１００は、コンテンツの取り引きに関する課
金処理を実行する。課金処理は、ユーザの取り引き口座
からコンテンツ料金を受領する処理である。受領したコ
ンテンツ料金は、コンテンツの著作権者、ショップ、ユ
ーザ機器認証サーバ管理者など、様々な関係者に配分さ
れる。
【０１１４】この課金処理に至るまでには、ユーザ機器
認証サーバ３００による暗号化コンテンツ鍵の鍵かけか
え処理プロセスが必須となっているので、ショップサー
バ１００は、ユーザ機器間とのみの処理では課金処理が
実行できない。また、ユーザ機器２００においても暗号
化コンテンツ鍵の復号ができないので、コンテンツの利
用ができない。ユーザ機器認証サーバは、図６を用いて
説明したユーザ機器認証サーバ・ライセンス管理データ
ベースに、すべての鍵かけかえ処理を実行したコンテン
ツ取り引き内容を記録しており、すべての課金対象とな
るコンテンツ取り引きが把握可能となる。従って、ショ
ップ側単独でのコンテンツ取り引きは不可能となり、不
正なコンテンツ販売が防止される。
【０１１５】（１８）暗号化コンテンツ鍵データ２（シ
ョップ）送信 ショップサーバ１００における課金処理が終了すると、
ショップサーバ１００は、暗号化コンテンツ鍵データ２
（ショップ）をユーザ機器２００に送信する。
【０１１６】暗号化コンテンツ鍵データ２（ショップ）
の構成を図１７（ｆ）に示す。暗号化コンテンツ鍵デー
タ２（ショップ）は、暗号化コンテンツ鍵要求の要求元
であるユーザ機器２００の識別子であるユーザ機器Ｉ
Ｄ、ユーザ機器認証サーバ３００から受領した暗号化コ
ンテンツ鍵データ（ＤＡＳ）（図１７（ｄ）のユーザ機
器、ユーザ機器認証サーバ公開鍵証明書を除いたデー
タ）、を有し、これらのデータに対するショップサーバ
１００の電子署名が付加されている。さらに、暗号化コ
ンテンツ鍵データ２（ショップ）には、ショップサーバ
１００の公開鍵証明書と、ユーザ機器認証サーバ３００
の公開鍵証明書が添付され、ユーザ機器２００に送付さ
れる。なお、ユーザ機器２００がユーザ機器認証サーバ
公開鍵証明書、ショップサーバ公開鍵証明書をすでに保
有している場合は、必ずしも改めて送付する必要はな
い。
【０１１７】なお、ユーザ機器認証サーバ３００が信頼
できる第三者機関であると認められる存在であり、ショ
ップサーバ１００がユーザ機器認証サーバ３００から受
信する暗号化コンテンツ鍵データ（ＤＡＳ）が先に説明
した図１８（ｄ’）の簡略化した暗号化コンテンツ鍵デ
ータ（ＤＡＳ）である場合は、ショップサーバ１００
は、図１８（ｆ’）に示す暗号化コンテンツ鍵データ２
（ショップ）をユーザ機器に送付する。すなわち、図１
８（ｄ’）に示す簡略化した暗号化コンテンツ鍵データ
（ＤＡＳ）にショップサーバの署名を付加したデータ
に、ショップサーバ１００の公開鍵証明書と、ユーザ機
器認証サーバ３００の公開鍵証明書を添付してユーザ機
器２００に送付する。
【０１１８】（１９）受信データ検証 ショップサーバ１００から、暗号化コンテンツ鍵データ
２（ショップ）を受領したユーザ機器２００は、暗号化
コンテンツ鍵データ２（ショップ）の検証処理を実行す
る。この検証処理は、先に説明した図１５の処理フロー
と同様の処理であり、ユーザ機器２００は、まずショッ
プサーバ１００から受領したショップサーバの公開鍵証
明書の検証を発行局（ＣＡ）の公開鍵ＫｐＣＡを用いて
実行し、次に公開鍵証明書から取り出したショップサー
バ１００の公開鍵ＫｐＳＨＯＰを用いて図１７（ｆ）に
示す暗号化コンテンツ鍵データ２（ショップ）の電子署
名の検証を実行する。さらに、ユーザ機器認証サーバ３
００の公開鍵証明書の検証を発行局（ＣＡ）の公開鍵Ｋ
ｐＣＡを用いて実行し、次に公開鍵証明書から取り出し
たユーザ機器認証サーバ３００の公開鍵ＫｐＤＡＳを用
いて図１７（ｆ）に示す暗号化コンテンツ鍵データ２
（ショップ）に含まれる（１２）暗号化コンテンツ鍵デ
ータ（ＤＡＳ）の署名検証を実行する。さらにまた、自
己の公開鍵ＫｐＤＥＶを用いて、暗号化コンテンツデー
タ（ユーザ機器）を検証するようにしてもよい。
【０１１９】（２０）保存処理 ショップサーバ１００から受信した暗号化コンテンツ鍵
データ２（ショップ）を検証したユーザ機器２００は、
暗号化コンテンツ鍵データ２（ショップ）に含まれる自
己の公開鍵ＫｐＤＥＶで暗号化された暗号化コンテンツ
鍵：ＫｐＤＥＶ（Ｋｃ）を自己の秘密鍵ＫｓＤＥＶを用
いて復号し、さらに、ユーザ機器の保存鍵Ｋｓｔｏを用
いて暗号化して暗号化コンテンツ鍵：Ｋｓｔｏ（Ｋｃ）
を生成して、これをユーザ機器２００の記憶手段に格納
する。コンテンツの利用時には、暗号化コンテンツ鍵：
Ｋｓｔｏ（Ｋｃ）を保存鍵Ｋｓｔｏを用いて復号してコ
ンテンツ鍵Ｋｃを取り出して、取り出したコンテンツ鍵
Ｋｃを用いて、暗号化コンテンツＫｃ（Content）の復
号処理を実行し、コンテンツ（Content）を再生、実行
する。
【０１２０】ユーザ機器２００におけるコンテンツ鍵Ｋ
ｃの取得と保存処理フローを図１９に示す。ユーザ機器
２００は、まず、ショップサーバ１００から受信した暗
号化コンテンツ鍵データ２（ショップ）から自己の公開
鍵ＫｐＤＥＶで暗号化された暗号化コンテンツ鍵：Ｋｐ
ＤＥＶ（Ｋｃ）を取り出し（Ｓ７１）、取り出した暗号
化コンテンツ鍵：ＫｐＤＥＶ（Ｋｃ）を自己の秘密鍵Ｋ
ｓＤＥＶを用いて復号してコンテンツ鍵Ｋｃを取り出す
（Ｓ７２）。さらに、ユーザ機器の保存鍵Ｋｓｔｏを用
いてコンテンツ鍵Ｋｃの暗号化処理を実行して暗号化コ
ンテンツ鍵：Ｋｓｔｏ（Ｋｃ）を生成して、これをユー
ザ機器２００の記憶手段（内部メモリ）に格納（Ｓ７
３）する。
【０１２１】以上の処理により、ユーザ機器は、暗号化
コンテンツＫｃ（Content）と、該暗号化コンテンツの
コンテンツ鍵Ｋｃを取得することができ、コンテンツを
利用することができる。上述の説明から明らかなよう
に、ユーザ機器２００においてコンテンツ利用可能な状
態に至るまでには、ユーザ機器認証サーバ３００におけ
る暗号化コンテンツ鍵の鍵かけかえ処理プロセスが必須
である。従って、ショップサーバ１００は、ユーザ機器
２００に対して、ユーザ機器認証サーバ３００に秘密に
コンテンツを販売し、コンテンツをユーザ機器において
利用可能な状態とすることができない。ユーザ機器認証
サーバは、図６を用いて説明したユーザ機器認証サーバ
・ライセンス管理データベースに、すべての鍵かけかえ
処理を実行したコンテンツ取り引き内容を記録してお
り、すべてのショップの取り引きの管理がなされ、課金
されたコンテンツ取り引きを把握し、ショップの課金処
理において受領されたコンテンツ料金を、コンテンツの
著作権者、ショップ、ユーザ機器認証サーバ管理者な
ど、様々な関係者に正確に配分することが可能となる。
【０１２２】（各機器におけるステータス遷移）図１に
示すショップサーバ１００、ユーザ機器２００、ユーザ
認証サーバ（ＤＡＳ）３００は、それぞれコンテンツ取
り引きに係る一連の処理において、処理状態を示すステ
ータスに応じて、次の処理を決定する。ステータスは、
例えば図３に示すショップサーバの購買管理データベー
ス、図６のユーザ機器認証サーバのライセンス管理デー
タベース、図８のユーザ機器の購入管理データベースに
おいて、各コンテンツ取り引き毎に管理される。
【０１２３】まず、ショップサーバ１００のステータス
遷移について、図２０を用いて説明する。ショップサー
バは、ユーザ機器２００からのコンテンツ購入要求デー
タを受信（図１の処理（３）に対応）することで処理が
開始される。ショップサーバ１００は、ユーザ機器２０
０からの受信データを検証し、検証に成功した場合は、
ステータスを「購入受付完了」に設定し、データ検証に
より正当な購入要求であるとの判定がなされなかった場
合等には、処理を中止するか、あるいは同様の処理、こ
こでは、購入受付処理を所定回数繰り返した後処理を中
止し、ステータスを「購入受付失敗」とする。ステータ
スが「購入受付完了」である場合にのみ次ステップに進
む。
【０１２４】ステータスが「購入受付完了」に遷移する
と、次に、ショップサーバ１００は、ユーザ機器２００
に対して暗号化コンテンツ鍵データ１（ショップ）を送
信（図１の処理（５）に対応）し、ユーザ機器からの受
信応答（レスポンス）を受領することにより、ステータ
スを「鍵１配信完了」とする。鍵データ１の送信が成功
しなかった場合は、処理を中止するか、あるいは同様の
処理、ここでは、鍵データ１の送信処理を所定回数繰り
返した後、処理を中止し、ステータスを「鍵１配信失
敗」とする。ステータスが「鍵１配信完了」である場合
にのみ次ステップに進む。
【０１２５】ステータスが「鍵１配信完了」に遷移した
場合、次に、ショップサーバ１００は、ユーザ機器認証
サーバ３００から暗号化コンテンツ鍵データ（ＤＡＳ）
を受信（図１の処理（１２）に対応）し、データ検証を
実行する。検証に成功した場合は、ステータスを「鍵受
信完了」に設定し、データ検証により正当な暗号化コン
テンツ鍵データ（ＤＡＳ）であるとの判定がなされなか
った場合等には、処理を中止するか、あるいは同様の処
理、ここでは、鍵受信処理を所定回数繰り返した後、処
理を中止し、ステータスを「鍵受信失敗」とする。ステ
ータスが「鍵受信完了」である場合にのみ次ステップに
進む。
【０１２６】ステータスが「鍵受信完了」に遷移した場
合、次に、ショップサーバ１００は、ユーザ機器２００
から暗号化コンテンツ鍵送信要求データを受信（図１の
処理（１５）に対応）し、データ検証を実行する。検証
に成功した場合は、ステータスを「暗号化コンテンツ鍵
送信要求受付完了」に設定し、データ検証により正当な
鍵送信要求データであるとの判定がなされなかった場合
等には、処理を中止するか、あるいは同様の処理、ここ
では、暗号化コンテンツ鍵送信要求データの受信処理を
所定回数繰り返した後、処理を中止し、ステータスを
「暗号化コンテンツ鍵送信要求受付失敗」とする。ステ
ータスが「暗号化コンテンツ鍵送信要求受付完了」であ
る場合にのみ次ステップに進む。
【０１２７】ステータスが「暗号化コンテンツ鍵送信要
求受付完了」に遷移した場合、次に、ショップサーバ１
００は、課金処理（図１の処理（１７）に対応）を実行
する。課金処理が完了すると、ステータスを「課金完
了」に設定し、課金処理が終了しなかった場合、例えば
ユーザ機器の指定口座からのコンテンツ料金引き落とし
ができなかった場合などには、以降の処理は実行せず、
処理を中止するか、あるいは同様の処理、ここでは、課
金処理を所定回数繰り返した後、処理を中止し、ステー
タスを「課金失敗」とする。ステータスが「課金完了」
である場合にのみ次ステップに進む。
【０１２８】ステータスが「課金完了」に遷移した場
合、次に、ショップサーバ１００は、ユーザ機器へ暗号
化コンテンツ鍵データ２（ショップ）送信処理（図１の
処理（１８）に対応）を実行する。暗号化コンテンツ鍵
データ２（ショップ）送信処理が完了し、ユーザ機器か
らの受信レスポンスを受信すると、ステータスを「鍵２
配信完了」に設定し、鍵データ２（ショップ）送信処理
が終了しなかった場合には、ステータスを「鍵２配信失
敗」とする。ステータスが「鍵２配信完了」である場合
にのみ次ステップ、ここでは処理終了となり、ステータ
スが「鍵２配信失敗」である場合は、以降の処理は実行
せず、処理を中止するか、あるいは同様の処理、ここで
は、鍵データ２（ショップ）送信処理を所定回数繰り返
す。ショップサーバ１００は、このような状態遷移を各
コンテンツ取り引き毎に実行する。
【０１２９】次に、ユーザ機器２００のステータス遷移
について、図２１を用いて説明する。ユーザ機器２００
は、まず、ショップサーバ１００に対してコンテンツ購
入要求データを送信（図１の処理（３）に対応）するこ
とで処理が開始される。ユーザ機器２００は、ショップ
サーバ１００に対するコンテンツ購入要求データの受信
完了のレスポンスを受信すると、ステータスを「購入要
求送信完了」に設定し、ショップサーバ１００からの受
信完了のレスポンスを受信できない場合は、処理を中止
するか、あるいは同様の処理、ここでは、購入要求送信
処理を所定回数繰り返した後、処理を中止し、ステータ
スを「購入要求送信失敗」とする。ステータスが「購入
要求送信完了」である場合にのみ次ステップに進む。
【０１３０】ステータスが「購入要求送信完了」に遷移
すると、次に、ユーザ機器２００は、ショップサーバ１
００から、暗号化コンテンツ鍵データ１（シヨップ）を
受信（図１の処理（５）に対応）し、受信データを検証
する。ショップサーバ１００からの暗号化コンテンツ鍵
データの検証に成功した場合は、ステータスを「鍵１受
信完了」に設定し、データ検証により正当な暗号化コン
テンツ鍵データであるとの判定がなされなかった場合等
には、処理を中止するか、あるいは同様の処理、ここで
は、鍵１受信処理を所定回数繰り返した後、処理を中止
し、ステータスを「鍵１受信失敗」とする。ステータス
が「鍵１受信完了」である場合にのみ次ステップに進
む。
【０１３１】ステータスが「鍵１受信完了」に遷移した
場合、次に、ユーザ機器２００は、ユーザ機器認証サー
バ３００に対して、暗号化コンテンツ鍵データ（ユーザ
機器）を送信（図１の処理（８）に対応）し、データ受
信レスポンスを受信する。データ受信レスポンスを受信
した場合は、ステータスを「鍵送信完了」に設定し、デ
ータ受信レスポンスを受信しない場合は、処理を中止す
るか、あるいは同様の処理、ここでは、鍵送信処理を所
定回数繰り返した後、処理を中止し、ステータスを「鍵
送信失敗」とする。ステータスが「鍵送信完了」である
場合にのみ次ステップに進む。
【０１３２】ステータスが「鍵送信完了」に遷移した場
合、次に、ユーザ機器２００は、ショップサーバ１００
に対して、暗号化コンテンツ鍵送信要求を送信（図１の
処理（１５）に対応）し、データ受信レスポンスを受信
する。データ受信レスポンスを受信した場合は、ステー
タスを「暗号化コンテンツ鍵送信要求送信完了」に設定
し、データ受信レスポンスを受信しない場合は、処理を
中止するか、あるいは同様の処理、ここでは、暗号化コ
ンテンツ鍵送信要求送信処理を所定回数繰り返した後、
処理を中止し、ステータスを「暗号化コンテンツ鍵送信
要求送信失敗」とする。ステータスが「暗号化コンテン
ツ鍵送信要求送信完了」である場合にのみ次ステップに
進む。
【０１３３】ステータスが「暗号化コンテンツ鍵送信要
求送信完了」に遷移した場合、次に、ユーザ機器２００
は、ショップサーバ１００から、暗号化コンテンツ鍵デ
ータ２（ショップ）を受信（図１の処理（１８）に対
応）し、データ検証を行なう。データ検証に成功した場
合は、ステータスを「鍵２受信完了」に設定し、データ
検証に成功しなかった場合等には、処理を中止するか、
あるいは同様の処理、ここでは、鍵データ２（ショッ
プ）受信処理を所定回数繰り返した後、処理を中止し、
ステータスを「鍵２受信失敗」とする。ステータスが
「鍵２受信完了」である場合には処理終了となる。ユー
ザ機器２００は、このような状態遷移を各コンテンツ取
り引き毎に実行する。
【０１３４】次にユーザ機器認証サーバ３００のステー
タス遷移について、図２２を用いて説明する。ユーザ機
器認証サーバ３００は、ユーザ機器２００からの暗号化
コンテンツ鍵データ（ユーザ機器）を受信（図１の処理
（８）に対応）することで処理が開始される。ユーザ機
器認証サーバ３００は、ユーザ機器２００からの受信デ
ータを検証し、検証に成功した場合は、ステータスを
「鍵受信完了」に設定し、データ検証により正当なデー
タであるとの判定がなされなかった場合等には、処理を
中止するか、あるいは同様の処理、ここでは、暗号化コ
ンテンツ鍵データ（ユーザ機器）の受信処理を所定回数
繰り返した後、処理を中止し、ステータスを「鍵受信失
敗」とする。ステータスが「鍵受信完了」である場合に
のみ次ステップに進む。
【０１３５】ステータスが「鍵受信完了」に遷移する
と、次に、ユーザ機器認証サーバ３００は、コンテンツ
鍵かけかえ処理（図１の処理（１０）に対応）を実行
し、鍵かけかえ処理が完了した場合には、ステータスを
「鍵かけかえ完了」とする。鍵かけかえに失敗すること
は想定していないので、ここでは「鍵かけかえ完了」の
みのステータス遷移が存在する。
【０１３６】ステータスが「鍵かけかえ完了」に遷移し
た場合、次に、ユーザ機器認証サーバ３００は、ショッ
プサーバ１００に対して暗号化コンテンツ鍵データ（Ｄ
ＡＳ）を送信（図１の処理（１２）に対応）し、ショッ
プサーバ１００からのデータ受信応答を受信する。デー
タ受信応答を受信した場合は、ステータスを「鍵送信完
了」に設定し、データ受信応答の受信がなされなかった
場合等には、処理を中止するか、あるいは同様の処理、
ここでは、暗号化コンテンツ鍵データ（ＤＡＳ）の送信
処理を所定回数繰り返した後、処理を中止し、ステータ
スを「鍵送信失敗」とする。ステータスが「鍵送信完
了」である場合には、処理終了となる。ユーザ機器認証
サーバ３００は、このような状態遷移を各コンテンツ取
り引き毎に実行する。
【０１３７】（コンテンツ購入処理フロー）次に、ユー
ザ機器からショップサーバに対するコンテンツ購入要求
に伴ってショップサーバ１００、ユーザ機器２００、ユ
ーザ機器認証サーバ３００間で実行されるデータ送受信
処理をフローに従って説明する。処理フローは、以下の
Ａ，Ｂ，Ｃ，Ｄに分割して説明する。
【０１３８】Ａ．ショップサーバとユーザ機器間におけ
る処理（図１に示す（１）〜（６）の処理） ユーザ機器２００とショップサーバ１００の相互認証〜
ユーザ機器２００からショップサーバ１００に対するコ
ンテンツ購入要求〜ショップサーバ１００からユーザ機
器２００に対する鍵１（ショップ）の送信。 Ｂ．ユーザ機器認証サーバとユーザ機器間における処理
（図１に示す（７）〜（９）の処理） ユーザ機器２００とユーザ機器認証サーバ３００の相互
認証〜暗号化コンテンツ鍵データ送信〜ユーザ機器認証
サーバ３００における受信データ検証。Ｃ．ユーザ機器
認証サーバとショップサーバ間における処理（図１に示
す（１１）〜（１３）の処理） ユーザ機器認証サーバ３００とショップサーバ１００間
の相互認証〜暗号化コンテンツ鍵データ（ＤＡＳ）送信
〜ショップサーバにおける受信データ検証。Ｄ．ショッ
プサーバとユーザ機器間における処理（図１に示す（１
４）〜（１９）の処理） ユーザ機器２００とショップサーバ１００の相互認証〜
ユーザ機器２００からショップサーバ１００に対する暗
号化コンテンツ鍵要求データ送信〜ショップサーバ１０
０からユーザ機器２００に対する鍵２（ショップ）の送
信〜ユーザ機器２００における受信データ検証。
【０１３９】まず、Ａ．ショップサーバとユーザ機器間
における処理（図１に示す（１）〜（６）の処理）につ
いて、図２３、図２４を用いて説明する。
【０１４０】図２３、図２４において、左側がショップ
サーバの処理、右側がユーザ機器の処理を示す。なお、
すべてのフローにおいて、ショップサーバの処理ステッ
プＮｏをＳ１０ｘｘ、ユーザ機器の処理ステップＮｏを
Ｓ２０ｘｘ、ユーザ機器認証サーバの処理ステップＮｏ
をＳ３０ｘｘとして示す。
【０１４１】まず、図２３に示すように、処理開始時
に、ショップサーバとユーザ機器間において相互認証が
実行される（Ｓ１００１，Ｓ２００１）。相互認証処理
は、図１２または図１３を用いて説明した処理として実
行される。相互認証処理において生成したセッション鍵
を用いて、必要に応じて送信データを暗号化してデータ
通信を実行する。相互認証が成立すると、ショップサー
バは、購買管理データベース（図３参照）に新規ショッ
プ処理ＮＯを新たな処理エントリとして追加（Ｓ１００
３）する。
【０１４２】一方、ユーザ機器は、相互認証が成立する
と、今回のコンテンツ取り引きにおいて適用するトラン
ザクションＩＤを例えば乱数に基づいて生成し、購入デ
ータベース（図８参照）に新規トランザクションＩＤを
新たなエントリとして追加（Ｓ２００３）する。さら
に、ユーザ機器は、ショップサーバに対するコンテンツ
購入要求データの送信（Ｓ２００４）、すなわち、図１
４（ａ）に示す（３）購入要求データの送信を実行す
る。
【０１４３】ショップサーバは、ユーザ機器からのコン
テンツ購入要求データを受信（Ｓ１００４）し、受信デ
ータ（Ｓ１００５）の検証を実行する。データ検証は、
先に説明した図１１の処理フローに従った処理である。
受信データの検証により、データが改竄のない正当なデ
ータであると認められると、ユーザ機器に対して受信Ｏ
Ｋのレスポンスを送信（Ｓ１００８）し、購買管理デー
タベースのステータスを「購入受付完了」に設定（Ｓ１
０１０）する。受信データの検証により、データが改竄
のある不当なデータであると認められると、ユーザ機器
に対して受信ＮＧのレスポンスを送信（Ｓ１００７）
し、購買管理データベースのステータスを「購入受付失
敗」に設定（Ｓ１００９）する。
【０１４４】ユーザ機器は、ショップサーバからの受信
ＯＫのレスポンスを受信（Ｓ２００５，Ｓ２００６でＹ
ｅｓ）すると、購入管理データベースのステータスを
「購入要求送信完了」に設定し、ショップサーバからの
受信ＮＧレスポンスを受信（Ｓ２００５，Ｓ２００６で
Ｎｏ）すると、購入管理データベースのステータスを
「購入要求送信失敗」に設定する。
【０１４５】ショップサーバでは、購買管理データベー
スのステータスを「購入受付完了」に設定（Ｓ１０１
０）後、暗号化コンテンツ鍵データ１（ショップ）（図
１４（ｂ）参照）を生成（Ｓ１０１１）し、ユーザ機器
に対して、コンテンツ鍵：Ｋｃで暗号化した暗号化コン
テンツ：Ｋｃ（Content）を送信（Ｓ１０１２）し、さ
らに、図１４（ｂ）に示す暗号化コンテンツ鍵データ１
（ショップ）を送信（Ｓ１０１３）する。
【０１４６】ユーザ機器は、購入管理データベースのス
テータスを「購入要求送信完了」に設定（Ｓ２００７）
後、ショップサーバから、コンテンツ鍵：Ｋｃで暗号化
した暗号化コンテンツ：Ｋｃ（Content）を受信（Ｓ２
００９）し、さらに、ショップサーバから暗号化コンテ
ンツ鍵データ１（ショップ）（図１４（ｂ））を受信
（Ｓ２０１０）する。
【０１４７】ユーザ機器は、ステップＳ２００９，Ｓ２
０１０で受信したデータの検証処理（図１１参照）を実
行（Ｓ２０２１）し、受信データの検証により、データ
が改竄のない正当なデータであると認められると、ショ
ップサーバに対して受信ＯＫのレスポンスを送信（Ｓ２
０２３）し、購入管理データベースのステータスを「鍵
１受信完了」に設定（Ｓ２０２５）する。受信データの
検証により、データが改竄のある不当なデータであると
認められると、ショップサーバに対して受信ＮＧのレス
ポンスを送信（Ｓ２０２４）し、購入管理データベース
のステータスを「鍵１受信失敗」に設定（Ｓ２０２６）
した後、ショップサーバとの接続を切る（Ｓ２０２
７）。
【０１４８】ショップサーバは、ユーザ機器からのレス
ポンスを受信（Ｓ１０２１）し、レスポンスがＯＫであ
る場合は、購買管理データベースのステータスを「鍵１
配信成功」に設定（Ｓ１０２４）する。レスポンスがＮ
Ｇである場合は、購買管理データベースのステータスを
「鍵１配信失敗」に設定（Ｓ１０２３）した後、ユーザ
機器との接続を切る（Ｓ１０２５）。
【０１４９】なお、ステップＳ１００２，Ｓ２００２の
相互認証失敗の場合、Ｓ１００９のステータスの「購入
受付失敗」の設定、および、Ｓ２００８のステータスの
「購入要求送信失敗」の設定の場合は、いずれも処理を
中止して、接続を切る処理を行なって処理終了とする。
【０１５０】次に、Ｂ．ユーザ機器認証サーバとユーザ
機器間における処理（図１に示す（７）〜（９）の処
理）について、図２５のフローに従って説明する。
【０１５１】まず、ユーザ機器認証サーバとユーザ機器
間において相互認証が実行される（Ｓ３００１，Ｓ２０
３１）。相互認証処理は、図１２または図１３を用いて
説明した処理として実行される。相互認証処理において
生成したセッション鍵を用いて、必要に応じて送信デー
タを暗号化してデータ通信を実行する。相互認証が成立
すると、ユーザ機器認証サーバは、ライセンス管理デー
タベース（図６参照）に新規ユーザ機器認証サーバ処理
ＮＯ、を新たな処理エントリとして追加（Ｓ３００３）
する。
【０１５２】一方、ユーザ機器は、相互認証が成立する
と、暗号化コンテンツ鍵データ（ユーザ機器）（図１４
（ｃ）参照）を生成（Ｓ２０３３）し、ユーザ機器認証
サーバへ送信（Ｓ２０３４）する。
【０１５３】ユーザ機器認証サーバは、ユーザ機器から
の暗号化コンテンツ鍵データ（ユーザ機器）を受信（Ｓ
３００４）し、受信データの検証（Ｓ３００５）を実行
する。データ検証は、先に説明した図１１の処理フロー
に従った処理である。受信データの検証により、データ
が改竄のない正当なデータであると認められると、ユー
ザ機器に対して受信ＯＫのレスポンスを送信（Ｓ３００
８）し、ライセンス管理データベースのステータスを
「鍵受信完了」に設定（Ｓ３０１０）する。受信データ
の検証により、データが改竄のある不当なデータである
と認められると、ユーザ機器に対して受信ＮＧのレスポ
ンスを送信（Ｓ３００７）し、ライセンス管理データベ
ースのステータスを「鍵受信失敗」に設定（Ｓ３００
９）後、ユーザ機器との接続を切る（Ｓ３０１１）。
【０１５４】ユーザ機器は、ユーザ機器認証サーバから
の受信ＯＫのレスポンスを受信（Ｓ２０３５，Ｓ２０３
６でＹｅｓ）すると、購入管理データベースのステータ
スを「鍵送信完了」に設定（Ｓ２０３７）し、ユーザ機
器認証サーバからの受信ＮＧレスポンスを受信（Ｓ２０
３５，Ｓ２０３６でＮｏ）すると、購入管理データベー
スのステータスを「鍵送信失敗」に設定（Ｓ２０３８）
した後、ユーザ機器認証サーバとの接続を切る（Ｓ２０
３９）。
【０１５５】なお、ステップＳ３００２，Ｓ２０３２の
相互認証失敗の場合は、処理を中止して、接続を切る処
理を行なって処理終了とする。
【０１５６】次に、Ｃ．ユーザ機器認証サーバとショッ
プサーバ間における処理（図１に示す（１１）〜（１
３）の処理）について、図２６のフローに従って説明す
る。
【０１５７】まず、ユーザ機器認証サーバとショップサ
ーバ間において相互認証が実行される（Ｓ３０２１，Ｓ
１０３１）。相互認証処理は、図１２または図１３を用
いて説明した処理として実行される。相互認証処理にお
いて生成したセッション鍵を用いて、必要に応じて送信
データを暗号化してデータ通信を実行する。相互認証が
成立すると、ユーザ機器認証サーバは、暗号化コンテン
ツ鍵データ（ＤＡＳ）（図１７（ｄ）参照）を生成（Ｓ
３０２３）し、ショップサーバに送信（Ｓ３０２４）す
る。
【０１５８】一方、ショップサーバは、相互認証の成立
後、ユーザ機器認証サーバから暗号化コンテンツ鍵デー
タ（ＤＡＳ）（図１７（ｄ）参照）を受信（Ｓ１０３
３）し、受信データの検証（Ｓ１０３４）を実行する。
データ検証は、先に説明した図１１の処理フローに従っ
た処理である。受信データの検証により、データが改竄
のない正当なデータであると認められると、ユーザ機器
認証サーバに対して受信ＯＫのレスポンスを送信（Ｓ１
０３６）し、購買管理データベースのステータスを「鍵
受信完了」に設定（Ｓ１０３８）する。受信データの検
証により、データが改竄のある不当なデータであると認
められると、ユーザ機器認証サーバに対して受信ＮＧの
レスポンスを送信（Ｓ１０３７）し、購買管理データベ
ースのステータスを「鍵受信失敗」に設定（Ｓ１０３
９）後、ユーザ機器認証サーバとの接続を切る（Ｓ１０
４０）。
【０１５９】ユーザ機器認証サーバは、ショップサーバ
からの受信ＯＫのレスポンスを受信（Ｓ３０２５，Ｓ３
０２６でＹｅｓ）すると、ライセンス管理データベース
のステータスを「鍵送信完了」に設定（Ｓ３０２８）
し、ショップサーバからの受信ＮＧレスポンスを受信
（Ｓ３０２５，Ｓ３０２６でＮｏ）すると、ライセンス
管理データベースのステータスを「鍵送信失敗」に設定
（Ｓ３０２７）した後、ユーザ機器認証サーバとの接続
を切る（Ｓ３０２９）。
【０１６０】なお、ステップＳ３０２２，Ｓ１０３２の
相互認証失敗の場合は、処理を中止して、接続を切る処
理を行なって処理終了とする。
【０１６１】次に、Ｄ．ショップサーバとユーザ機器間
における処理（図１に示す（１４）〜（１９）の処理）
について、図２７、図２８を用いて説明する。
【０１６２】まず、処理開始時に、ショップサーバとユ
ーザ機器間において相互認証が実行される（Ｓ１０５
１，Ｓ２０５１）。相互認証処理は、図１２または図１
３を用いて説明した処理として実行される。相互認証処
理において生成したセッション鍵を用いて、必要に応じ
て送信データを暗号化してデータ通信を実行する。相互
認証が成立すると、ユーザ機器は、暗号化コンテンツ鍵
送信要求データ（図１７（ｅ）参照）を生成（Ｓ２０５
３）し、ショップサーバへ送信（Ｓ２０５４）する。
【０１６３】ショップサーバは、ユーザ機器からの暗号
化コンテンツ鍵送信要求データを受信（Ｓ１０５４）
し、受信データの検証を実行（Ｓ１０５５）する。デー
タ検証は、先に説明した図１１の処理フローに従った処
理である。受信データの検証により、データが改竄のな
い正当なデータであると認められると、ユーザ機器に対
して受信ＯＫのレスポンスを送信（Ｓ１０５８）し、購
買管理データベースのステータスを「暗号化コンテンツ
鍵送信要求受付完了」に設定（Ｓ１０６０）する。受信
データの検証により、データが改竄のある不当なデータ
であると認められると、ユーザ機器に対して受信ＮＧの
レスポンスを送信（Ｓ１０５７）し、購買管理データベ
ースのステータスを「暗号化コンテンツ鍵送信要求受付
失敗」に設定（Ｓ１０５９）する。
【０１６４】ユーザ機器は、ショップサーバからの受信
ＯＫのレスポンスを受信（Ｓ２０５５，Ｓ２０５６でＹ
ｅｓ）すると、購入管理データベースのステータスを
「暗号化コンテンツ鍵送信要求送信完了」に設定（Ｓ２
０５７）し、ショップサーバからの受信ＮＧレスポンス
を受信（Ｓ２０５５，Ｓ２０５６でＮｏ）すると、購入
管理データベースのステータスを「暗号化コンテンツ鍵
送信要求送信失敗」に設定（Ｓ２０５８）する。
【０１６５】ショップサーバでは、購買管理データベー
スのステータスを「暗号化コンテンツ鍵送信要求受付完
了」に設定（Ｓ１０６０）後、暗号化コンテンツ鍵デー
タ２（ショップ）（図１７（ｆ）参照）を生成（Ｓ１０
６１）し、ユーザ機器に対して、図１７（ｆ）に示す暗
号化コンテンツ鍵データ２（ショップ）を送信（Ｓ１０
６２）する。
【０１６６】ユーザ機器は、購入管理データベースのス
テータスを「暗号化コンテンツ鍵送信要求送信完了」に
設定（Ｓ２０５７）後、ショップサーバから、暗号化コ
ンテンツ鍵データ２（ショップ）（図１７（ｆ））を受
信（Ｓ２０５９）する。
【０１６７】ユーザ機器は、ステップＳ２０５９で受信
したデータの検証処理（図１１参照）を実行（Ｓ２０７
１）し、受信データの検証により、データが改竄のない
正当なデータであると認められると、ショップサーバに
対して受信ＯＫのレスポンスを送信（Ｓ２０７３）し、
購入管理データベースのステータスを「鍵２受信完了」
に設定（Ｓ２０７５）する。受信データの検証により、
データが改竄のある不当なデータであると認められる
と、ショップサーバに対して受信ＮＧのレスポンスを送
信（Ｓ２０７４）し、購入管理データベースのステータ
スを「鍵２受信失敗」に設定（Ｓ２０７６）した後、シ
ョップサーバとの接続を切る（Ｓ２０７７）。
【０１６８】ショップサーバは、ユーザ機器からのレス
ポンスを受信（Ｓ１０７１）し、レスポンスがＯＫであ
る場合は、購買管理データベースのステータスを「鍵２
配信成功」に設定（Ｓ１０７４）する。レスポンスがＮ
Ｇである場合は、購買管理データベースのステータスを
「鍵２配信失敗」に設定（Ｓ１０７３）した後、ユーザ
機器との接続を切る（Ｓ１０７５）。
【０１６９】なお、ステップＳ１０５２，Ｓ２０５２の
相互認証失敗の場合は、処理を中止して、接続を切る処
理を行なって処理終了とする。
【０１７０】［基本コンテンツ配信モデル１の変形例］
ここまで、図１に示した基本コンテンツ配信モデル１の
構成に基づいてコンテンツ購入処理の構成、処理手順に
ついて説明してきたが、基本的にユーザ機器認証サーバ
においてコンテンツ鍵のかけかえ処理を実行する構成と
するポリシーを持つ構成であれば、図１に示す構成に限
らず、様々な態様が実現可能である。以下、様々な変形
例について説明する。
【０１７１】図２９に示す構成は、ショップサーバの機
能を分離し、ショップサーバと配信サーバを設けた構成
である。ショップサーバ１００は、ユーザ機器２００か
らのコンテンツ購入要求を受領するが、ユーザ機器２０
０に対するコンテンツ配信は配信サーバ４００が実行す
る。本例では、各エンティテイ間で相互認証処理を省略
しているが、基本コンテンツ配信モデル１同様、相互認
証処理を行なっても構わない。
【０１７２】ショップサーバ１００は、ユーザ機器２０
０からの購入要求データを受信し、データの検証（図２
９の処理（３））を行なって、要求データの正当性を確
認した後、配信サーバ４００に対して、コンテンツ配信
要求の送信を実行（図２９の処理（４））する。配信サ
ーバ４００は、ショップサーバ１００からのコンテンツ
配信要求データを検証し、データの正当性が確認された
場合、コンテンツデータベース４１０から取り出した暗
号化コンテンツおよび暗号化コンテンツ鍵データ（配信
サーバ）を送信（図２９の処理（６））する。暗号化コ
ンテンツ鍵データ（配信サーバ）は、前述の実施例の暗
号化コンテンツ鍵データ１（ショップ）に対応し、ユー
ザ機器認証サーバの公開鍵ＫｐＤＡＳで暗号化したコン
テンツ鍵Ｋｃ、すなわちＫｐＤＡＳ（Ｋｃ）を含むデー
タである。
【０１７３】ユーザ機器２００が配信サーバ４００から
暗号化コンテンツおよび暗号化コンテンツ鍵データ（配
信サーバ）を受信した以後の処理は、先の図１に示した
構成に基づく実施例と同様となる。
【０１７４】本構成においては、ショップサーバ１００
は、ユーザ機器からのコンテンツ要求を受け付けて、そ
の正当性を検証する機能、ユーザ機器認証サーバから
の、かけかえ済みの暗号化コンテンツ鍵を受信し、ユー
ザ機器に対する配信を主として実行し、コンテンツ自体
の管理、配信を行なわない。従って、例えば音楽データ
を管理する音楽コンテンツ配信サーバ、ゲームコンテン
ツを管理するゲームコンテンツ配信サーバ等、様々なコ
ンテンツ管理主体となる複数の配信サーバに対して１つ
のショップサーバがユーザ機器からのコンテンツ要求に
応答し、ショップサーバが要求に応じて要求コンテンツ
を管理する配信サーバにコンテンツ配信要求を送信する
構成に適した態様である。また、この構成にしたことに
より、例えば、ユーザ機器とショップサーバは双方向通
信であるため、インターネットを使うが、配信サーバか
らユーザ機器へは片方向通信であるため、高速な衛星通
信が利用できるメリットがある。
【０１７５】図３０は、図２９と同様ショップサーバの
機能を分離し、ショップサーバと配信サーバを設けた構
成であり、ショップサーバ１００は、ユーザ機器２００
からのコンテンツ購入要求を受領するが、ユーザ機器２
００に対するコンテンツ配信は配信サーバ４００が実行
する。図２９の構成と異なる点は、ショップサーバ１０
０から配信サーバ４００に対してコンテンツ配信要求を
送信せず、ユーザ機器認証サーバ３００が、配信サーバ
４００に対してコンテンツ配信要求を送信する構成とし
た点である。
【０１７６】ショップサーバ１００は、ユーザ機器２０
０からの購入要求データを受信し、データの検証（図３
０の処理（３））を行なって、要求データの正当性を確
認した後、ユーザ機器認証サーバ３００に対して、コン
テンツ配信要求の送信を実行（図３０の処理（４））す
る。その後、ユーザ機器認証サーバ３００は、データの
検証（図３０の処理（５））を行なって、要求データの
正当性を確認した後、配信サーバ４００に対して、コン
テンツ配信要求の送信を実行（図３０の処理（６））す
る。配信サーバ４００は、ユーザ機器認証サーバ３００
からのコンテンツ配信要求データを検証し、正当性が確
認された場合、ユーザ機器２００に対して、コンテンツ
データベース４１０から取り出した暗号化コンテンツお
よび暗号化コンテンツ鍵データ（配信サーバ）を送信
（図３０の処理（８））する。暗号化コンテンツ鍵デー
タ（配信サーバ）は、前述の実施例の暗号化コンテンツ
鍵データ１（ショップ）に対応し、ユーザ機器認証サー
バの公開鍵ＫｐＤＡＳで暗号化したコンテンツ鍵Ｋｃ、
すなわちＫｐＤＡＳ（Ｋｃ）を含むデータである。
【０１７７】ユーザ機器２００が配信サーバ４００から
暗号化コンテンツおよび暗号化コンテンツ鍵データ（配
信サーバ）を受信した以後の処理は、先の図１に示した
構成に基づく実施例と同様となる。
【０１７８】本構成においては、ユーザ機器認証サーバ
３００は、ユーザ機器２００からの鍵のかけかえ要求以
前、ショップサーバ１００に対してコンテンツ購入要求
があった時点で、コンテンツ購入要求主体であるユーザ
機器情報を取得し、管理することが可能となる。従っ
て、ユーザ機器２００からの鍵のかけかえ要求受領時
に、すでに登録済みのコンテンツ購入要求ユーザ機器で
あるか否かの照合処理が可能となる。
【０１７９】［１．３．基本コンテンツ配信モデル２］
次に、図３１を用いて基本コンテンツ配信モデル１と異
なる基本コンテンツ配信モデル２について説明する。基
本コンテンツ配信モデル２では、ユーザ機器２００とユ
ーザ機器認証サーバ３００との間ではデータ送受信が行
われない。図３１に示す各処理（１）〜（１９）につい
て、基本コンテンツ配信モデル１との相違点を中心に説
明する。なお、本実施例では、エンティテイ間の通信に
おいて相互認証処理（（１）、（７）、（１３））を行
なったものを述べているが、必要に応じて省略しても構
わない。
【０１８０】（１）相互認証 コンテンツをショップサーバ１００から購入しようとす
るユーザ機器２００は、ショップサーバ１００との間で
相互認証処理を行なう。相互認証処理は、図１２または
図１３を用いて説明した処理である。相互認証処理にお
いて、生成したセッション鍵を用いて、必要に応じて送
信データを暗号化してデータ通信を実行する。
【０１８１】（２）トランザクションＩＤ、購入要求デ
ータ生成、および （３）購入要求データ送信 ショップサーバ１００とユーザ機器２００間の相互認証
が成功すると、ユーザ機器２００は、コンテンツの購入
要求データを生成する。購入要求データの構成を図３２
（ｇ）に示す。購入要求データは、コンテンツ購入の要
求先であるショップサーバ１００の識別子であるショッ
プＩＤ、コンテンツ取り引きの識別子として、ユーザ機
器２００の暗号処理手段が乱数に基づいて生成するトラ
ンザクションＩＤ、さらに、ユーザ機器が購入を希望す
るコンテンツの識別子としてのコンテンツＩＤの各デー
タを有し、これらのデータに対するユーザ機器の電子署
名が付加されている。さらに、購入要求データには、ユ
ーザ機器の公開鍵証明書が添付され、ショップサーバ１
００に送付される。なお、公開鍵証明書が既に前述の相
互認証処理、あるいはその以前の処理において、ショッ
プ側に送付済みの場合は、必ずしも改めて送付する必要
はない。
【０１８２】（４）受信データ検証 図３２（ｇ）に示す購入要求データをユーザ機器２００
から受信したショップサーバ１００は、受信データの検
証処理を実行する。検証処理の詳細は、先に図１５を用
いて説明した通りである。
【０１８３】（５）暗号化コンテンツおよび購入受付デ
ータ送信 ショップサーバ１００において、購入要求データの検証
が完了し、データ改竄のない正当なコンテンツ購入要求
であると判定すると、ショップサーバ１００は、暗号化
コンテンツおよび購入受付データをユーザ機器に送信す
る。これらは、コンテンツをコンテンツキーで暗号化し
た暗号化コンテンツ：Ｋｃ（content）と、購入要求を
受け付けたことを示すのみのデータであり、先のコンテ
ンツキー：Ｋｃをユーザ機器認証サーバ（ＤＡＳ）３０
０の公開鍵で暗号化した暗号化コンテンツ鍵データ：Ｋ
ｐＤＡＳ（Ｋｃ）を含まないデータである。
【０１８４】購入受付データの構成を図３２（ｈ）に示
す。購入受付データは、コンテンツ購入の要求元である
ユーザ機器２００の識別子であるユーザ機器ＩＤ、購入
要求データ（図３２（ｇ）のユーザ機器公開鍵証明書を
除いたデータ）、コンテンツ取り引きに伴いショップサ
ーバ１００が生成したショップ処理Ｎｏ．を有し、これ
らのデータに対するショップサーバ１００の電子署名が
付加されている。さらに、購入受付データには、ショッ
プサーバ１００の公開鍵証明書が添付され、ユーザ機器
２００に送付される。なお、ショップサーバ公開鍵証明
書が既に前述の相互認証処理、あるいはその以前の処理
において、ユーザ機器側に送付済みの場合は、必ずしも
改めて送付する必要はない。
【０１８５】（６）受信データ検証 ショップサーバ１００から暗号化コンテンツ：Ｋｃ（co
ntent）と、図３２（ｈ）に示す購入受付データを受信
したユーザ機器２００は、購入受付データの検証処理を
実行する。この検証処理は、先に説明した図１５の処理
フローと同様の処理であり、ユーザ機器２００は、まず
ショップサーバ１００から受領したショップサーバの公
開鍵証明書の検証を発行局（ＣＡ）の公開鍵ＫｐＣＡを
用いて実行し、次に公開鍵証明書から取り出したショッ
プサーバの公開鍵ＫｐＳＨＯＰを用いて図３２（ｈ）に
示す購入受付データのショップ署名の検証を実行する。
【０１８６】（７）相互認証 （８）暗号化コンテンツ鍵データ１（ショップ）送信 次にショップサーバ１００は、ユーザ機器認証サーバ３
００にアクセスし、ショップサーバ１００と、ユーザ機
器認証サーバ３００間において相互認証処理を実行す
る。相互認証が成立すると、ショップサーバ１００は、
ユーザ機器認証サーバ３００に対して、暗号化コンテン
ツ鍵データ１（ショップ）を送信する。
【０１８７】暗号化コンテンツ鍵データ１（ショップ）
の構成を図３２（ｉ）に示す。暗号化コンテンツ鍵デー
タ１（ショップ）は、暗号化コンテンツ鍵かけかえ要求
の要求先であるユーザ機器認証サーバ３００の識別子で
あるユーザ機器認証サーバＩＤ、ユーザ機器２００から
受領した購入要求データ（図３２（ｇ）のユーザ機器公
開鍵証明書を除いたデータ）、ショップ処理Ｎｏ．を有
し、これらのデータに対するショップサーバ１００の電
子署名が付加されている。さらに、暗号化コンテンツ鍵
データ１（ショップ）には、ショップサーバ１００の公
開鍵証明書と、ユーザ機器２００の公開鍵証明書が添付
され、ユーザ機器認証サーバ３００に送付される。な
お、ユーザ機器認証サーバ３００がユーザ機器公開鍵証
明書、ショップサーバ公開鍵証明書をすでに保有してい
る場合は、必ずしも改めて送付する必要はない。
【０１８８】（９）受信データ検証 ショップサーバ１００から暗号化コンテンツ鍵データ１
（ショップ）（図３２（ｉ））を受信したユーザ機器認
証サーバ３００は、受信データの検証処理を実行する。
この検証処理は、先に説明した図１５の処理フローと同
様の処理であり、ユーザ機器認証サーバ３００は、まず
ショップサーバ１００から受領したショップサーバの公
開鍵証明書の検証を発行局（ＣＡ）の公開鍵ＫｐＣＡを
用いて実行し、次に公開鍵証明書から取り出したショッ
プサーバの公開鍵ＫｐＳＨＯＰを用いて図３２（ｉ）に
示す暗号化コンテンツ鍵データ１（ショップ）の電子署
名の検証を実行する。さらに、ユーザ機器の公開鍵証明
書の検証を発行局（ＣＡ）の公開鍵ＫｐＣＡを用いて実
行し、次に公開鍵証明書から取り出したユーザ機器の公
開鍵ＫｐＤＥＶを用いて図３２（ｉ）に示す暗号化コン
テンツ鍵データ１（ショップ）に含まれる（３）購入要
求データのユーザ機器署名の検証を実行する。
【０１８９】（１０）暗号化コンテンツ鍵かけかえ処理 ユーザ機器認証サーバ３００において、ショップサーバ
１００から受信した暗号化コンテンツ鍵データ１（ショ
ップ）の検証が終了し、正当なデータであると判定する
と、ユーザ機器認証サーバ３００は、暗号化コンテンツ
鍵データ１（ショップ）に含まれる暗号化コンテンツ
鍵、すなわち、コンテンツ鍵：Ｋｃをユーザ機器認証サ
ーバ（ＤＡＳ）３００の公開鍵ＫｐＤＡＳで暗号化した
データ：ＫｐＤＡＳ（Ｋｃ）をユーザ機器認証サーバ３
００の秘密鍵ＫｓＤＡＳで復号してコンテンツ鍵Ｋｃを
取得し、さらにコンテンツ鍵Ｋｃをユーザ機器の公開
鍵：ＫｐＤＥＶで暗号化した暗号化コンテンツ鍵：Ｋｐ
ＤＥＶ（Ｋｃ）を生成する。すなわち、ＫｐＤＡＳ（Ｋ
ｃ）→Ｋｃ→ＫｐＤＥＶ（Ｋｃ）の鍵かけかえ処理を実
行する。この処理は、先に説明した図１６に示すフロー
に従った処理である。
【０１９０】（１１）暗号化コンテンツデータ送信 次に、ユーザ機器認証サーバ３００は、暗号化コンテン
ツ鍵データ（ＤＡＳ）をショップサーバ１００に送信す
る。
【０１９１】暗号化コンテンツ鍵データ（ＤＡＳ）の構
成を図３３（ｊ）に示す。暗号化コンテンツ鍵データ
（ＤＡＳ）は、コンテンツ購入の要求先であるショップ
サーバ１００の識別子であるショップＩＤ、暗号化コン
テンツ鍵データ１（ショップ）（図３２（ｉ）のショッ
プおよびユーザ機器公開鍵証明書を除いたデータ）、さ
らに、前述の鍵かけかえ処理により、ユーザ機器認証サ
ーバ３００が生成した暗号化コンテンツ鍵データ：Ｋｐ
ＤＥＶ（Ｋｃ）を有し、これらのデータに対するユーザ
機器認証サーバ３００の電子署名が付加されている。さ
らに、暗号化コンテンツ鍵データ（ＤＡＳ）には、ユー
ザ機器認証サーバ３００と、ユーザ機器２００の公開鍵
証明書が添付され、ショップサーバ１００に送付され
る。なお、ショップサーバが、これらの公開鍵証明書を
既に保有済みである場合は、必ずしも改めて送付する必
要はない。
【０１９２】また、ユーザ機器認証サーバ３００が信頼
できる第三者機関であると認められる存在である場合
は、暗号化コンテンツ鍵データ（ＤＡＳ）は、図３３
（ｊ）に示すような（８）暗号化コンテンツ鍵データ１
（ショップ）をそのまま含むデータ構成とすることな
く、図３４（ｊ’）に示すように、ショップＩＤ、ユー
ザ機器ＩＤ、トランザクションＩＤ、コンテンツＩＤ、
ショップ処理ＮＯ、ユーザデバイスの公開鍵で暗号化し
たコンテンツ鍵ＫｐＤＥＶ（Ｋｃ）の各データを、ユー
ザ機器認証サーバ３００が抽出して、これらに署名を付
加して暗号化コンテンツ鍵データ（ＤＡＳ）としてもよ
い。添付する公開鍵証明書は、ユーザ機器認証サーバ３
００の公開鍵証明書である。
【０１９３】（１２）受信データ検証 ユーザ機器認証サーバ３００から暗号化コンテンツ鍵デ
ータ（ＤＡＳ）（図３３（ｊ））を受信したショップサ
ーバ１００は、暗号化コンテンツ鍵データ（ＤＡＳ）の
検証処理を実行する。この検証処理は、先に説明した図
１５の処理フローと同様の処理であり、ショップサーバ
１００は、まずユーザ機器認証サーバ３００から受領し
たユーザ機器認証サーバの公開鍵証明書の検証を発行局
（ＣＡ）の公開鍵ＫｐＣＡを用いて実行し、次に公開鍵
証明書から取り出したユーザ機器認証サーバ３００の公
開鍵ＫｐＤＡＳを用いて図３３（ｊ）に示す暗号化コン
テンツ鍵データ（ＤＡＳ）の電子署名の検証を実行す
る。なお、先に説明した図３４（ｊ’）の簡略化した暗
号化コンテンツ鍵データ（ＤＡＳ）をショップサーバ１
００が受領した場合も同様の検証を実行する。さらに、
必要に応じて図３３（ｊ）の暗号化コンテンツデータ
（ＤＡＳ）内の暗号化コンテンツ鍵１（ショップ１）を
検証するようにしてもよい。
【０１９４】（１３）相互認証、および （１４）暗号化コンテンツ鍵要求データ送信 次に、ユーザ機器２００は、暗号化コンテンツ鍵要求デ
ータをショップサーバに対して送信する。なお、この
際、前の要求と異なるセッションで要求を実行する場合
は、再度相互認証を実行して、相互認証が成立したこと
を条件として暗号化コンテンツ鍵要求データがユーザ機
器２００からショップサーバ１００に送信される。
【０１９５】（１５）検証処理、および （１６）課金処理 暗号化コンテンツ鍵要求データをユーザ機器から受信し
たショップサーバ１００は、暗号化コンテンツ鍵要求デ
ータの検証処理を実行する。これは、図１５を用いて説
明したと同様の処理である。データ検証が済むと、ショ
ップサーバ１００は、コンテンツの取り引きに関する課
金処理を実行する。課金処理は、ユーザの取り引き口座
からコンテンツ料金を受領する処理である。受領したコ
ンテンツ料金は、コンテンツの著作権者、ショップ、ユ
ーザ機器認証サーバ管理者など、様々な関係者に配分さ
れる。
【０１９６】前述した基本モデル１と同様、この課金処
理に至るまでには、ユーザ機器認証サーバ３００による
暗号化コンテンツ鍵の鍵かけかえ処理プロセスが必須と
なっているので、ショップサーバ１００は、ユーザ機器
間とのみの処理では課金処理が実行できない。また、ユ
ーザ機器２００においても暗号化コンテンツ鍵の復号が
できないので、コンテンツの利用ができない。ユーザ機
器認証サーバは、図６を用いて説明したユーザ機器認証
サーバ・ライセンス管理データベースに、すべての鍵か
けかえ処理を実行したコンテンツ取り引き内容を記録し
ており、すべての課金対象となるコンテンツ取り引きが
把握可能となる。従って、ショップ側単独でのコンテン
ツ取り引きは不可能となり、不正なコンテンツ販売が防
止される。
【０１９７】（１７）暗号化コンテンツ鍵データ２（シ
ョップ）送信 ショップサーバ１００における課金処理が終了すると、
ショップサーバ１００は、暗号化コンテンツ鍵データ２
（ショップ）をユーザ機器２００に送信する。
【０１９８】暗号化コンテンツ鍵データ２（ショップ）
の構成を図３３（ｋ）に示す。暗号化コンテンツ鍵デー
タ２（ショップ）は、暗号化コンテンツ鍵要求の要求元
であるユーザ機器２００の識別子であるユーザ機器Ｉ
Ｄ、ユーザ機器認証サーバ３００から受領した暗号化コ
ンテンツ鍵データ（ＤＡＳ）（図３３（ｊ）のユーザ機
器認証サーバ公開鍵証明書を除いたデータ）、を有し、
これらのデータに対するショップサーバ１００の電子署
名が付加されている。さらに、暗号化コンテンツ鍵デー
タ２（ショップ）には、ショップサーバ１００の公開鍵
証明書と、ユーザ機器認証サーバ３００の公開鍵証明書
が添付され、ユーザ機器２００に送付される。なお、ユ
ーザ機器２００がユーザ機器認証サーバ公開鍵証明書、
ショップサーバ公開鍵証明書をすでに保有している場合
は、必ずしも改めて送付する必要はない。
【０１９９】なお、ユーザ機器認証サーバ３００が信頼
できる第三者機関であると認められる存在であり、ショ
ップサーバ１００がユーザ機器認証サーバ３００から受
信する暗号化コンテンツ鍵データ（ＤＡＳ）が先に説明
した図３４（ｊ’）の簡略化した暗号化コンテンツ鍵デ
ータ（ＤＡＳ）である場合は、ショップサーバ１００
は、図３４（ｋ’）に示す暗号化コンテンツ鍵データ２
（ショップ）をユーザ機器に送付する。すなわち、図３
４（ｊ’）に示す簡略化した暗号化コンテンツ鍵データ
（ＤＡＳ）にショップサーバの署名を付加したデータ
に、ショップサーバ１００の公開鍵証明書と、ユーザ機
器認証サーバ３００の公開鍵証明書を添付してユーザ機
器２００に送付する。
【０２００】（１８）受信データ検証 ショップサーバ１００から、暗号化コンテンツ鍵データ
２（ショップ）を受領したユーザ機器２００は、暗号化
コンテンツ鍵データ２（ショップ）の検証処理を実行す
る。この検証処理は、先に説明した図１５の処理フロー
と同様の処理であり、ユーザ機器２００は、まずショッ
プサーバ１００から受領したショップサーバの公開鍵証
明書の検証を発行局（ＣＡ）の公開鍵ＫｐＣＡを用いて
実行し、次に公開鍵証明書から取り出したショップサー
バ１００の公開鍵ＫｐＳＨＯＰを用いて図３３（ｋ）に
示す暗号化コンテンツ鍵データ２（ショップ）の電子署
名の検証を実行する。さらに、ユーザ機器認証サーバ３
００の公開鍵証明書の検証を発行局（ＣＡ）の公開鍵Ｋ
ｐＣＡを用いて実行し、次に公開鍵証明書から取り出し
たユーザ機器認証サーバ３００の公開鍵ＫｐＤＡＳを用
いて図３３（ｊ）に示す暗号化コンテンツ鍵データ２
（ショップ）に含まれる（１１）暗号化コンテンツ鍵デ
ータ（ＤＡＳ）の署名検証を実行する。さらに、必要に
応じて図３３（ｊ）の暗号化コンテンツデータ（ＤＡ
Ｓ）内の暗号化コンテンツ鍵１（ショップ１）を検証す
るようにしてもよい。
【０２０１】（１９）保存処理 ショップサーバ１００から受信した暗号化コンテンツ鍵
データ２（ショップ）を検証したユーザ機器２００は、
暗号化コンテンツ鍵データ２（ショップ）に含まれる自
己の公開鍵ＫｐＤＥＶで暗号化された暗号化コンテンツ
鍵：ＫｐＤＥＶ（Ｋｃ）を自己の秘密鍵ＫｓＤＥＶを用
いて復号し、さらに、ユーザ機器の保存鍵Ｋｓｔｏを用
いて暗号化して暗号化コンテンツ鍵：Ｋｓｔｏ（Ｋｃ）
を生成して、これをユーザ機器２００の記憶手段に格納
する。コンテンツの利用時には、暗号化コンテンツ鍵：
Ｋｓｔｏ（Ｋｃ）を保存鍵Ｋｓｔｏを用いて復号してコ
ンテンツ鍵Ｋｃを取り出して、取り出したコンテンツ鍵
Ｋｃを用いて、暗号化コンテンツＫｃ（Content）の復
号処理を実行し、コンテンツ（Content）を再生、実行
する。
【０２０２】このように、基本配信モデル２において
は、ユーザ機器２００と、ユーザ機器認証サーバ３００
との間ではデータの送受信が実行されず、ユーザ機器２
００は、ショップサーバ１００との間でデータ送受信を
行なうのみでよく、ユーザ機器の処理負担が軽減され
る。
【０２０３】［１．２．基本コンテンツ配信モデル２の
変形例］次に、図３１に示した基本コンテンツ配信モデ
ル２の構成の変形例について説明する。図３５に示す構
成は、ショップサーバの機能を分離し、ショップサーバ
と配信サーバを設けた構成である。ショップサーバ１０
０は、ユーザ機器２００からのコンテンツ購入要求を受
領するが、ユーザ機器２００に対するコンテンツ配信は
配信サーバ４００が実行する。本構成では、データ送受
信を実行するエンティテイ間での相互認証を行なわず、
各エンティテイは、受信データの署名検証のみを行な
う。しかし、基本コンテンツ配信モデル２同様、エンテ
ィテイ間で相互認証処理を行なう構成をとっても構わな
い。
【０２０４】ショップサーバ１００は、ユーザ機器２０
０からの購入要求データを受信し、データの検証（図３
５の処理（３））を行なって、要求データの正当性を確
認した後、配信サーバ４００に対して、コンテンツ配信
要求の送信を実行（図３５の処理（４））する。配信サ
ーバ４００は、ショップサーバ１００からのコンテンツ
配信要求データを検証し、データの正当性が確認された
場合、コンテンツデータベース４１０から取り出した暗
号化コンテンツを送信（図３５の処理（６））する。
【０２０５】ユーザ機器２００は、配信サーバ４００か
ら、暗号化コンテンツを受信し、データ検証の後、暗号
化コンテンツ受領データを配信サーバ４００に送信（図
３５の処理（８））する。配信サーバ４００は、受信デ
ータ検証の後、ユーザ機器認証サーバ３００に対して暗
号化コンテンツ鍵データ（配信サーバ）および暗号化コ
ンテンツ鍵かけかえ要求を送信（図３５の処理（１
０））する。
【０２０６】ユーザ機器認証サーバ３００が配信サーバ
４００から暗号化コンテンツ鍵データ（配信サーバ）お
よび暗号化コンテンツ鍵かけかえ要求を受信した以後の
処理は、相互認証処理を省略した以外は、先の図３１に
示した構成に基づく実施例と同様となる。
【０２０７】本構成においては、ユーザ機器は、相互認
証を行なわずに、ショップサーバに対してコンテンツ購
入要求を送信し、配信サーバから暗号化コンテンツを受
領する。ショップサーバ１００は、ユーザ機器からのコ
ンテンツ要求を受け付けて、その正当性を署名検証のみ
に基づいて検証する。さらに、ユーザ機器認証サーバか
らの、かけかえ済みの暗号化コンテンツ鍵を受信し、そ
の正当性を署名検証により実行する。配信サーバ４００
は、ショップサーバからの受信データについての署名検
証を実行してデータ正当性の確認を行ないコンテンツ配
信を行なう。
【０２０８】ショップサーバ１００は、コンテンツ自体
の管理、配信を行なわない。従って、例えば音楽データ
を管理する音楽コンテンツ配信サーバ、ゲームコンテン
ツを管理するゲームコンテンツ配信サーバ等、様々なコ
ンテンツ管理主体となる複数の配信サーバに対して１つ
のショップサーバがユーザ機器からのコンテンツ要求に
応答し、ショップサーバが要求に応じて要求コンテンツ
を管理する配信サーバにコンテンツ配信要求を送信する
構成に適した態様である。また、この構成にしたことに
より、例えば、ユーザ機器とショップサーバは双方向通
信であるため、インターネットを使うが、配信サーバか
らユーザ機器へは片方向通信であるため、高速な衛星通
信が利用できるメリットがある。
【０２０９】本実施例では、相互認証が省略され、署名
検証のみにより、データの正当性を確認する処理とした
ので、処理の効率化が実現される。
【０２１０】図３６は、図３５と同様ショップサーバの
機能を分離し、ショップサーバと配信サーバを設け、相
互認証を省略した構成であり、ショップサーバ１００
は、ユーザ機器２００からのコンテンツ購入要求を受領
し、署名検証を行なう。ユーザ機器２００に対するコン
テンツ配信は配信サーバ４００が実行する。図３５の構
成と異なる点は、ショップサーバ１００から配信サーバ
４００に対してコンテンツ配信要求を送信せず、ユーザ
機器認証サーバ３００が、配信サーバ４００に対してコ
ンテンツ配信要求を送信する構成とした点である。
【０２１１】ショップサーバ１００は、ユーザ機器２０
０からの購入要求データを受信し、データの検証（図３
６の処理（３））を行なって、要求データの正当性を確
認した後、ユーザ機器認証サーバ３００に対して、暗号
化コンテンツ鍵データ１（ショップ）の送信を実行（図
３６の処理（４））する。その後、ユーザ機器認証サー
バ３００は、データの検証（図３６の処理（５））を行
なって、要求データの正当性を確認した後、配信サーバ
４００に対して、コンテンツ配信要求の送信を実行（図
３６の処理（６））する。配信サーバ４００は、ユーザ
機器認証サーバ３００からのコンテンツ配信要求データ
を検証し、正当性が確認された場合、ユーザ機器２００
に対して、コンテンツデータベース４１０から取り出し
た暗号化コンテンツを送信（図３６の処理（８））す
る。以後の処理は、先の図３５に示した構成に基づく処
理と同様となる。
【０２１２】本構成においては、ユーザ機器認証サーバ
３００は、配信サーバ４００からの鍵のかけかえ要求以
前、ショップサーバ１００に対してコンテンツ購入要求
があった時点で、コンテンツ購入要求主体であるユーザ
機器情報を取得し、管理することが可能となる。従っ
て、配信サーバ４００からの鍵のかけかえ要求受領時
に、すでに登録済みのコンテンツ購入要求ユーザ機器で
あるか否かの照合処理が可能となる。また、ＤＡＳが信
頼できる機関であるとみなせば、配信サーバはショップ
サーバの送信データを検証しなくてもよくなり、処理の
効率化が図れる。
【０２１３】以上、説明したように、本発明のコンテン
ツ配信構成によれば、ユーザ機器は、暗号化コンテンツ
Ｋｃ（Content）取得後、コンテンツ利用可能な状態に
至るまでには、ユーザ機器認証サーバにおける暗号化コ
ンテンツ鍵の鍵かけかえ処理プロセスが必須となる。従
って、ショップサーバが、ユーザ機器に対して、ユーザ
機器認証サーバに通知せずコンテンツを販売し、コンテ
ンツをユーザ機器において利用可能な状態とすることが
できない。ユーザ機器認証サーバは、ユーザ機器認証サ
ーバ・ライセンス管理データベース（図６参照）に、す
べての鍵かけかえ処理を実行したコンテンツ取り引き内
容を記録しており、すべてのショップの取り引きの管理
が可能であり、課金されたコンテンツ取り引きを把握
し、ショップの課金処理において受領されたコンテンツ
料金を、コンテンツの著作権者、ショップ、ユーザ機器
認証サーバ管理者など、様々な関係者に正確に配分する
ことが可能となり、不正なコンテンツ利用を排除する構
成が実現される。
【０２１４】［２．電子チケットを利用したコンテンツ
配信モデル］次に、ユーザによるコンテンツの利用（購
入）に基づいて、コンテンツの著作権者、製作者、ライ
センスホルダー、ショップ等、様々な関係者に対する利
益配分情報を記述した電子チケットを発行して、発行し
た電子チケットに基づく利益配分処理を実行する構成に
ついて説明する。
【０２１５】図３７に電子チケットに基づく利益配分を
実行するシステム構成を示す。図３７のコンテンツ配信
システムは、ユーザ機器が購入するコンテンツの購入要
求を受け付け、コンテンツ購入に伴う利用料金の利益配
分情報を記述した電子チケットを発行するチケット発行
サーバ（ＴＩＳ：Ticket Issuer Server）６１０、コン
テンツ購入主体となるユーザ機器（ＤＥＶ）６２０、正
当なコンテンツ取り引き管理のための鍵かけかえ処理を
行なう管理サーバとして機能するユーザ機器認証サーバ
（ＤＡＳ：Device Authentication Server）６３０、コ
ンテンツの配信を行なうコンテンツプロバイダ（ＣＰ）
等の配信サーバ（ＣＰ：Content Provider）６４０、さ
らに、電子チケットに基づいて利用料金の振替等の換金
処理を行なうチケット換金サーバ（ＴＥＳ：Ticket Exc
hange Server）６５０を主構成要素とする。
【０２１６】（チケット発行サーバ）図３７のコンテン
ツ配信システムのチケット発行サーバ（ＴＩＳ）６１０
の構成を図３８に示す。チケット発行サーバ６１０は、
ユーザ機器６２０からの購入要求を受け付け、購入要求
のあった取り引き対象となるコンテンツに対応してその
利益配分情報を記述した電子チケットを発行する。
【０２１７】チケット発行サーバ（ＴＩＳ）６１０は、
コンテンツ取り引きに伴う発行チケットの管理データ、
例えばコンテンツ販売先のユーザ機器の識別子とコンテ
ンツ識別子、コンテンツ料金等を対応づけて管理するチ
ケット発行管理データベース６１２を有する。さらに、
ユーザ機器６２０からのコンテンツ購入要求検証、チケ
ット発行管理データベースの制御、チケットに基づくユ
ーザ機器に対する課金処理、ユーザ機器等との通信処
理、さらに、各通信処理に際してのデータ暗号処理等を
実行する制御手段６１３を有する。
【０２１８】チケット発行管理データベース６１２のデ
ータ構成を図３９に示す。チケット発行管理データベー
ス６１２は、チケット発行サーバがコンテンツ取り引き
に応じてチケット発行処理を実行する際に内部生成する
識別番号としてのチケット発行処理Ｎｏ．、コンテンツ
購入依頼を発行したユーザ機器の識別子である機器Ｉ
Ｄ、ユーザ機器とチケット発行サーバ間での取り引きを
実行する際に、コンテンツ取り引き識別子としてユーザ
機器で生成発行するトランザクションＩＤ、取り引き対
象コンテンツの識別子であるコンテンツＩＤ、チケット
発行サーバ６１０の発行する電子チケットに基づいて対
価を得るエンティテイ、例えば著作権者、ライセンスホ
ルダ、管理者、コンテンツ販売関係者等の識別子として
のチケット利用先ＩＤ、各チケット利用先ＩＤに対応す
るコンテンツ利用料金配分金額としての金額、チケット
に基づく換金処理の有効期限、チケット発行サーバ６１
０におけるチケット発行、管理処理のステータスを示す
ステータスの各情報を持つ。ステータスは、後段で詳細
に説明するがコンテンツの取り引きに伴う複数の処理の
進行に応じて更新される。
【０２１９】チケット発行サーバ６１０の制御手段６１
３は、図３８に示すように暗号処理手段、通信処理手段
としての機能も有し、制御手段６１３は、例えば暗号処
理プログラム、通信処理プログラムを格納したコンピュ
ータによって構成される。制御手段６１３の暗号処理手
段において実行される暗号処理において使用される鍵デ
ータ等は、制御手段内部の記憶手段にセキュアに格納さ
れている。チケット発行サーバ６１０が格納する暗号鍵
等の暗号処理用データとしては、チケット発行サーバ６
１０の秘密鍵：ＫｓＴＩＳ、チケット発行サーバ６１０
の公開鍵証明書Ｃｅｒｔ＿ＴＩＳ、公開鍵証明書の発行
機関である公開鍵証明書発行局としての認証局（ＣＡ：
Certificate Authority）の公開鍵ＫｐＣＡがある。
【０２２０】制御手段６１３の構成は、先に図４を用い
て説明した制御手段構成と同様の構成、すなわち、中央
演算処理装置（ＣＰＵ:Central Processing Unit）、Ｒ
ＯＭ（Read only Memory）、ＲＡＭ（Random Access Me
mory）、表示部、入力部、記憶手段、通信インタフェー
ス等を持つ構成である。
【０２２１】（ユーザ機器）ユーザ機器（ＤＥＶ）６２
０は、図１の構成におけるユーザ機器、すなわち、図７
の構成と同様の構成を持つ。ユーザ機器６２０が格納す
る暗号鍵等の暗号処理用データとしては、ユーザ機器の
秘密鍵：ＫｓＤＥＶ、ユーザ機器の公開鍵証明書Ｃｅｒ
ｔ＿ＤＥＶ、公開鍵証明書の発行機関である公開鍵証明
書発行局としての認証局（ＣＡ：Certificate Authorit
y）の公開鍵ＫｐＣＡ、コンテンツをユーザ機器の例え
ばハードディスク等の記憶手段に格納する際の暗号化鍵
として適用する保存鍵Ｋｓｔｏがある。
【０２２２】図３７のチケット管理構成を実行するシス
テムにおけるユーザ機器６２０の有する購入管理データ
ベースは、チケット管理機能を持つデータ構成となる。
購入管理データベースのデータ構成を図４０に示す。購
入管理データベースは、コンテンツ取り引きを実行する
際に、ユーザ機器で生成発行するトランザクションＩ
Ｄ、取り引き対象コンテンツの識別子であるコンテンツ
ＩＤ、コンテンツ取り引きに伴いチケットを発行するチ
ケット発行体の識別子であるチケット発行体ＩＤ、チケ
ット発行サーバ６１０が設定するチケット発行処理Ｎ
ｏ．、チケットを送信した先の送信先エンティテイの識
別子としてのチケット送信先ＩＤ、さらに、ユーザ機器
におけるコンテンツ取り引き処理のステータスを示すス
テータスの各情報を持つ。ステータスは、後段で詳細に
説明するがコンテンツの取り引きに伴う複数の処理の進
行に応じて更新される。
【０２２３】（ユーザ機器認証サーバ）ユーザ機器認証
サーバ（ＤＡＳ）６３０は、図１の構成におけるユーザ
機器認証サーバ、すなわち、図５の構成と同様の構成を
持つ。ユーザ機器認証サーバ６３０が格納する暗号鍵等
の暗号処理用データとしては、ユーザ機器認証サーバ
（ＤＡＳ）の秘密鍵：ＫｓＤＡＳ、ユーザ機器認証サー
バ（ＤＡＳ）の公開鍵証明書Ｃｅｒｔ＿ＤＡＳ、公開鍵
証明書の発行機関である公開鍵証明書発行局としての認
証局（ＣＡ：Certificate Authority）の公開鍵ＫｐＣ
Ａがある。
【０２２４】図３７のチケット管理構成を実行するシス
テムにおけるユーザ機器認証サーバ６３０の有するライ
センス管理データベースは、チケット管理機能を持つデ
ータ構成となる。ライセンス管理データベースのデータ
構成を図４１に示す。ライセンス管理データベースは、
コンテンツ取り引き時にユーザ機器認証サーバ（ＤＡ
Ｓ）６３０の実行する処理に応じて内部生成する処理識
別子としてのユーザ機器認証サーバ処理Ｎｏ．、コンテ
ンツ購入依頼を発行したユーザ機器の識別子である機器
ＩＤ、コンテンツ取り引きを実行する際に、ユーザ機器
で生成発行するトランザクションＩＤ、取り引き対象コ
ンテンツの識別子であるコンテンツＩＤ、コンテンツ取
り引きに伴いチケットを発行するチケット発行体の識別
子であるチケット発行体ＩＤ、チケット発行サーバ６１
０が設定するチケット発行処理Ｎｏ．、さらに、ユーザ
機器認証サーバ（ＤＡＳ）におけるコンテンツ取り引き
処理のステータスを示すステータスの各情報を持つ。ス
テータスは、後段で詳細に説明するがコンテンツの取り
引きに伴う複数の処理の進行に応じて更新される。
【０２２５】（配信サーバ）図３７のコンテンツ配信シ
ステムの配信サーバ６４０の構成を図４２に示す。配信
サーバ６４０は、例えばコンテンツプロバイダ（ＣＰ）
であり、取り引き対象となるコンテンツをコンテンツキ
ーで暗号化した暗号化コンテンツデータであるＫｃ（Ｃ
ｏｎｔｅｎｔ）と、コンテンツキーＫｃをユーザ機器認
証サーバ（ＤＡＳ：Device Authentication Server）の
公開鍵：ＫｐＤＡＳで暗号化した暗号化コンテンツキー
ＫｐＤＡＳ（Ｋｃ）を格納したコンテンツデータベース
６４４を有する。なお、暗号化コンテンツデータである
Ｋｃ（Ｃｏｎｔｅｎｔ）は、図にも示すように、それぞ
れコンテンツ識別子であるコンテンツＩＤが付加され、
コンテンツＩＤに基づいて識別可能な構成を持つ。
【０２２６】配信サーバ６４０は、さらにコンテンツの
配信管理データを管理する配信管理データベース６４２
を有する。配信管理データベース６４２は、チケット管
理機能を持つデータ構成となる。購入管理データベース
のデータ構成を図４３に示す。配信管理データベース６
４２は、コンテンツ配信処理を実行する際に、配信サー
バ６４０が設定する配信サーバ処理Ｎｏ．、取り引き対
象コンテンツの識別子であるコンテンツＩＤ、コンテン
ツの配信対象識別子としてのユーザ機器ＩＤ、コンテン
ツ取り引きに伴いチケットを発行するチケット発行体の
識別子であるチケット発行体ＩＤ、チケット発行体が設
定するチケット発行処理Ｎｏ．、さらに、配信サーバに
おけるコンテンツ取り引き処理のステータスを示すステ
ータスの各情報を持つ。ステータスは、後段で詳細に説
明するがコンテンツの取り引きに伴う複数の処理の進行
に応じて更新される
【０２２７】さらに、配信サーバ６４０は、コンテンツ
データベース６４４からの配信コンテンツの抽出処理、
取り引きに伴う配信管理データベース６４２に対して登
録する取り引きデータの生成処理、ユーザ機器６２０他
との通信処理、さらに、各通信処理に際してのデータ暗
号処理等を実行する制御手段６４３を有する。制御手段
６４３は、図４２に示すように暗号処理手段、通信処理
手段としての機能も有し、制御手段６４３は、例えば暗
号処理プログラム、通信処理プログラムを格納したコン
ピュータによって構成される。制御手段６４３の暗号処
理手段において実行される暗号処理において使用される
鍵データ等は、制御手段内部の記憶手段にセキュアに格
納されている。配信サーバ６４０が格納する暗号鍵等の
暗号処理用データとしては、配信サーバ６４０の秘密
鍵：ＫｓＣＰ、配信サーバ６４０の公開鍵証明書Ｃｅｒ
ｔ＿ＣＰ、公開鍵証明書の発行機関である公開鍵証明書
発行局としての認証局（ＣＡ：Certificate Authorit
y）の公開鍵ＫｐＣＡがある。
【０２２８】制御手段６４３の構成は、先に図４を用い
て説明した制御手段構成と同様の構成、すなわち、中央
演算処理装置（ＣＰＵ:Central Processing Unit）、Ｒ
ＯＭ（Read only Memory）、ＲＡＭ（Random Access Me
mory）、表示部、入力部、記憶手段、通信インタフェー
ス等を持つ構成である。
【０２２９】（チケット換金サーバ）図３７のコンテン
ツ配信システムのチケット換金サーバ（ＴＥＳ）６５０
の構成を図４４に示す。チケット換金サーバ６５０は、
様々なエンティテイから電子チケットを受信し、受信デ
ータの検証の後、チケットに基づく換金処理、例えば口
座振替処理、あるいは電子マネーの残高変更処理等を行
なう、具体的な一例としては、チケット換金サーバ６５
０は各エンティティの銀行口座を管理する銀行内のサー
バとする設定が可能である。
【０２３０】チケット換金サーバ６５０は、コンテンツ
取り引きに伴う発行チケットに基づく換金処理の管理デ
ータを管理するチケット換金管理データベース６５２を
有する。さらに、各エンティテイからの受信チケット検
証、チケット換金管理データベースの制御、各エンティ
テイとの通信処理、さらに、各通信処理に際してのデー
タ暗号処理等を実行する制御手段６５３を有する。
【０２３１】チケット換金管理データベース６５２のデ
ータ構成を図４５に示す。チケット換金管理データベー
ス６５２は、チケット換金サーバが受領チケットに応じ
てチケット換金処理を実行する際に内部生成する識別番
号としてのチケット換金サーバ処理Ｎｏ．、チケットに
基づく換金の要求を行なってきた要求主体識別子として
の換金依頼元ＩＤ、コンテンツ取り引きに伴いチケット
を発行するチケット発行体の識別子であるチケット発行
体ＩＤ、チケット発行サーバ６１０が設定するチケット
発行処理Ｎｏ．、チケットに基づく換金金額、コンテン
ツの購入主体であるユーザ機器の識別子としてのユーザ
機器ＩＤ、コンテンツ取り引きを実行する際に、ユーザ
機器で生成発行するトランザクションＩＤ、さらに、チ
ケット換金サーバにおける換金処理のステータスを示す
ステータスの各情報を持つ。ステータスは、後段で詳細
に説明するがコンテンツの取り引きに伴う複数の処理の
進行に応じて更新される。
【０２３２】さらに、チケット換金サーバ６５０は、チ
ケット換金管理データベース６５２のデータ生成、更新
処理、受領チケットの検証処理、各種エンティテイとの
通信処理、さらに、各通信処理に際してのデータ暗号処
理等を実行する制御手段６５３を有する。制御手段６５
３は、図４４に示すように暗号処理手段、通信処理手段
としての機能も有し、制御手段６５３は、例えば暗号処
理プログラム、通信処理プログラムを格納したコンピュ
ータによって構成される。制御手段６５３の暗号処理手
段において実行される暗号処理において使用される鍵デ
ータ等は、制御手段内部の記憶手段にセキュアに格納さ
れている。チケット換金サーバ６５０が格納する暗号鍵
等の暗号処理用データとしては、チケット換金サーバ６
５０の秘密鍵：ＫｓＴＥＳ、チケット換金サーバ６５０
の公開鍵証明書Ｃｅｒｔ＿ＴＥＳ、公開鍵証明書の発行
機関である公開鍵証明書発行局としての認証局（ＣＡ：
Certificate Authority）の公開鍵ＫｐＣＡがある。
【０２３３】制御手段６５３の構成は、先に図４を用い
て説明した制御手段構成と同様の構成、すなわち、中央
演算処理装置（ＣＰＵ:Central Processing Unit）、Ｒ
ＯＭ（Read only Memory）、ＲＡＭ（Random Access Me
mory）、表示部、入力部、記憶手段、通信インタフェー
ス等を持つ構成である。
【０２３４】［コンテンツ購入処理］次に、図３７に戻
り、ユーザ機器が、チケット発行サーバにコンテンツ購
入要求を発行してコンテンツを利用可能な状態としてユ
ーザ機器に保存し、チケットに基づいてコンテンツ料金
が配分（換金）されるまでの処理について説明する。図
３７の番号（１）から（３２）の順に処理が進行する。
各番号順に処理の詳細を説明する。
【０２３５】（１）相互認証 コンテンツを購入しようとするユーザ機器６２０は、チ
ケット発行サーバ６１０との間で相互認証処理を行な
う。相互認証処理は、図１２または図１３を用いて説明
した処理である。相互認証処理において、生成したセッ
ション鍵を用いて、必要に応じて送信データを暗号化し
てデータ通信を実行する。
【０２３６】（２）トランザクションＩＤ、購入要求デ
ータ生成、および （３）購入要求データ送信 チケット発行サーバ６１０とユーザ機器６２０間の相互
認証が成功すると、ユーザ機器６２０は、コンテンツの
購入要求データを生成する。購入要求データの構成を図
４６（ｍ）に示す。購入要求データは、コンテンツ購入
の要求元であるユーザ機器６２０の識別子である機器Ｉ
Ｄ、取り引きの識別子として、ユーザ機器６２０の暗号
処理手段が例えば乱数に基づいて生成するトランザクシ
ョンＩＤ、さらに、ユーザ機器が購入を希望するコンテ
ンツの識別子としてのコンテンツＩＤの各データを有
し、これらのデータに対するユーザ機器の電子署名が付
加されている。さらに、購入要求データには、署名検証
用に必要に応じてユーザ機器の公開鍵証明書を添付す
る。
【０２３７】（４）受信データ検証 図４６（ｍ）に示す購入要求データをユーザ機器６２０
から受信したチケット発行サーバ６１０は、受信データ
の検証処理を実行する。検証処理の詳細は、先に図１５
を用いて説明した通りである。
【０２３８】（５）課金処理 （６）電子チケット発行 （７）電子チケット送信 チケット発行サーバ６１０は、次に、コンテンツの取り
引きに関する課金処理、電子チケット発行処理を実行す
る。これらの処理は、例えば予め登録されているユーザ
口座、あるいは電子マネー口座等に基づいて設定される
ユーザの取り引き金額限度内の電子チケットを発行する
処理として実行される。発行された電子チケットは、ユ
ーザ機器６２０に送信される。
【０２３９】電子チケットの構成例を図４７に示す。図
４７（Ａ）は、電子チケットに基づく料金配分先（料金
受領エンティテイ）が単一である場合のデータ構成であ
り、チケット発行体ＩＤ、チケット発行処理Ｎｏ．、電
子チケットに基づく料金配分先（エンティテイ）を示す
チケット利用先ＩＤ、電子チケットに基づいて配分され
る料金を示す金額、電子チケットの有効期限、すなわち
料金受領エンティテイがチケットに基づく換金（料金精
算）処理を実行可能な期限、さらに、ユーザ機器からチ
ケット発行サーバに対して送信された購入要求データ
（図４６（ｍ）参照）を含む。なお、さらに、チケット
発行日等のデータを付加してもよい。これらのデータに
チケット発行サーバ６１０の電子署名が付加される。さ
らに、電子チケットには、署名検証用に必要に応じてチ
ケット発行サーバの公開鍵証明書を添付する。
【０２４０】図４７（Ｂ）は、電子チケットに基づく料
金配分先（エンティテイ）が複数である場合のデータ構
成であり、チケット利用先ＩＤが複数（１〜ｎ）格納さ
れ、それぞれのチケット利用先ＩＤ毎に、電子チケット
に基づいて配分される料金を示す金額が１〜ｎまで格納
されている。チケットに基づいて料金を受領するエンテ
ィテイは、自己のＩＤに対応する金額を受領する。
【０２４１】図３７の処理例では、チケット発行サーバ
６１０は、配信サーバを管理するコンテンツプロバイダ
（ＣＰ）用の電子チケットと、ユーザ機器認証サーバ
（ＤＡＳ）用の電子チケットを発行する。これらのチケ
ット発行先は、コンテンツ毎に異なり、コンテンツの著
作者等が含まれる場合もある。チケット発行サーバは、
コンテンツＩＤに基づいてチケット発行先と、配分金額
を定めたテーブルを有し、ユーザ機器からのコンテンツ
購入要求に含まれるコンテンツＩＤに基づいてテーブル
からチケット発行先と、配分金額データを取得してチケ
ットを生成して発行する。
【０２４２】（８）受信データ検証 チケット発行サーバ６１０からチケットを受信したユー
ザ機器６２０は、チケットの検証処理を実行する。この
検証処理は、先に説明した図１５の処理フローと同様の
処理であり、ユーザ機器６２０は、まずチケット発行サ
ーバの公開鍵証明書の検証を発行局（ＣＡ）の公開鍵Ｋ
ｐＣＡを用いて実行し、次に公開鍵証明書から取り出し
たチケット発行サーバの公開鍵ＫｐＴＩＳを用いてチケ
ットの署名検証を実行する。
【０２４３】（９）相互認証 （１０）電子チケット（ＣＰ用）送信 次にユーザ機器６２０は、配信サーバ６４０にアクセス
し、相互認証処理を実行する。相互認証が成立すると、
ユーザ機器６２０は、配信サーバ６４０に対して、配信
サーバ用の電子チケット（ＣＰ用）を送信する。
【０２４４】（１１）受信データ検証 （１２）暗号化コンテンツおよび暗号化コンテンツ鍵送
信 配信サーバ６４０において、電子チケット（ＣＰ用）の
検証が完了し、データ改竄のない正当な電子チケットで
あると判定すると、配信サーバ６４０は、暗号化コンテ
ンツおよび暗号化コンテンツ鍵をユーザ機器に送信す
る。これらは、コンテンツをコンテンツキーで暗号化し
た暗号化コンテンツ：Ｋｃ（content）と、コンテンツ
キー：Ｋｃをユーザ機器認証サーバ（ＤＡＳ）６３０の
公開鍵で暗号化した暗号化コンテンツ鍵データ：ＫｐＤ
ＡＳ（Ｋｃ）を含むデータである。
【０２４５】（１３）受信データ検証 （１４）相互認証 （１５）電子チケット（ＤＡＳ用）および鍵かけかえ要
求送信 配信サーバ６４０から暗号化コンテンツおよび暗号化コ
ンテンツ鍵を受信したユーザ機器６２０は、データの検
証処理を実行する。データ検証後、ユーザ機器６２０
は、ユーザ機器認証サーバ６３０にアクセスし、相互認
証処理を実行する。相互認証が成立すると、ユーザ機器
６２０は、ユーザ機器認証サーバ６３０に対して、ユー
ザ機器認証サーバ用の電子チケット（ＤＡＳ）および鍵
かけかえ要求を送信する。鍵かけかえ要求は、先に配信
サーバ６４０から受信したユーザ機器認証サーバの公開
鍵で暗号化されたコンテンツ鍵Ｋｃである。暗号化コン
テンツ鍵ＫｐＤＡＳ（Ｋｃ）をユーザ機器の公開鍵Ｋｐ
ＤＥＶで暗号化したコンテンツ鍵、すなわちＫｐＤＥＶ
（Ｋｃ）とする処理を要求するものであり、図１を用い
て説明したかけかえ処理と同様である。
【０２４６】（１６）受信データ検証 （１７）暗号化コンテンツ鍵かけかえ処理、 ユーザ機器６２０から電子チケット（ＤＡＳ用）および
暗号化コンテンツ鍵ＫｐＤＡＳ（Ｋｃ）かけかえ要求を
受信したユーザ機器認証サーバ６３０は、電子チケット
（ＤＡＳ用）、暗号化コンテンツ鍵かけかえ要求の検証
処理を実行する。検証が終了し、データの改竄のない正
当な電子チケットであり、正当な鍵かけかえ要求である
と判定すると、ユーザ機器認証サーバ６３０は、コンテ
ンツ鍵：Ｋｃをユーザ機器認証サーバ（ＤＡＳ）６３０
の公開鍵ＫｐＤＡＳで暗号化したデータ：ＫｐＤＡＳ
（Ｋｃ）をユーザ機器認証サーバ６３０の秘密鍵ＫｓＤ
ＡＳで復号してコンテンツ鍵Ｋｃを取得し、さらにコン
テンツ鍵Ｋｃをユーザ機器の公開鍵：ＫｐＤＥＶで暗号
化した暗号化コンテンツ鍵：ＫｐＤＥＶ（Ｋｃ）を生成
する。すなわち、ＫｐＤＡＳ（Ｋｃ）→Ｋｃ→ＫｐＤＥ
Ｖ（Ｋｃ）の鍵かけかえ処理を実行する。この処理は、
前述の図１６を用いて説明した処理と同様である。
【０２４７】（１８）暗号化コンテンツ鍵送信 （１９）受信データ検証 （２０）保存処理 ユーザ機器認証サーバ６３０は、鍵かけかえにより生成
した暗号化コンテンツ鍵ＫｐＤＥＶ（Ｋｃ）をユーザ機
器６２０に送信する。ユーザ機器認証サーバ６３０か
ら、暗号化コンテンツ鍵ＫｐＤＥＶ（Ｋｃ）を受領した
ユーザ機器６２０は、受信データ検証処理を実行し、検
証後、ユーザ機器６２０は、暗号化コンテンツ鍵ＫｐＤ
ＥＶ（Ｋｃ）を自己の秘密鍵ＫｓＤＥＶを用いて復号
し、さらに、ユーザ機器の保存鍵Ｋｓｔｏを用いて暗号
化して暗号化コンテンツ鍵：Ｋｓｔｏ（Ｋｃ）を生成し
て、これをユーザ機器６２０の記憶手段に格納する。コ
ンテンツの利用時には、暗号化コンテンツ鍵：Ｋｓｔｏ
（Ｋｃ）を保存鍵Ｋｓｔｏを用いて復号してコンテンツ
鍵Ｋｃを取り出して、取り出したコンテンツ鍵Ｋｃを用
いて、暗号化コンテンツＫｃ（Content）の復号処理を
実行し、コンテンツ（Content）を再生、実行する。
【０２４８】（２１）相互認証 （２２）電子チケット（ＣＰ用）送信 配信サーバ６４０は、ユーザ機器６２０に対する暗号化
コンテンツ配信の後、チケット換金サーバ６５０にアク
セスし、相互認証処理を実行する。相互認証が成立する
と、配信サーバ６４０は、チケット換金サーバ６５０に
対して、配信サーバ用の電子チケット（ＣＰ用）を送信
する。
【０２４９】（２３）受信データ検証、換金処理 チケット換金サーバ６５０において、電子チケット（Ｃ
Ｐ用）の検証が完了し、データ改竄のない正当な電子チ
ケットであると判定すると、チケット換金サーバ６５０
は、受領した電子チケット（ＣＰ用）に基づいて換金処
理を実行する。換金処理は、例えば予め登録されている
配信サーバを管理するコンテンツプロバイダ（ＣＰ）の
管理口座、あるいは電子マネー口座等に、電子チケット
（ＣＰ用）に設定された金額をユーザ機器の管理ユーザ
の口座から振り替える処理として行われる。あるいは既
にチケット発行サーバがユーザからの前払い預り金とし
て受領しているチケット発行サーバ管理口座からコンテ
ンツプロバイダ（ＣＰ）の管理口座にチケットに設定さ
れた金額を振り替える処理として行なってもよい。な
お、チケット換金サーバ６５０は、チケットに格納され
た有効期限を検証し、有効期限内であることが確認され
たことを条件として該チケットに基づく料金精算処理を
実行する。
【０２５０】（２４）換金処理レポート報告 チケット換金サーバ６５０において、電子チケット（Ｃ
Ｐ用）に基づく換金が終了すると、チケット換金サーバ
６５０は、配信サーバ６４０に対して換金処理が済んだ
ことを示すレポートを送信する。
【０２５１】換金処理レポートの構成例を図４６（ｎ）
に示す。換金処理レポートは、チケット換金処理個々の
識別子であるチケット換金処理ＩＤ、チケットに基づく
換金の要求を行なってきた要求主体識別子としての換金
依頼元ＩＤ、チケットに基づく換金金額、コンテンツ取
り引きに伴いチケットを発行したチケット発行体の識別
子であるチケット発行体ＩＤ、チケット発行サーバ６１
０が設定するチケット発行処理Ｎｏ．、チケット換金サ
ーバ６５０において換金処理が実行されたチケット換金
処理完了日等のデータを有し、これらにチケット換金サ
ーバ６５０の電子署名が付加される。さらに、換金処理
レポートには、署名検証用に必要に応じてチケット換金
サーバの公開鍵証明書を添付する。
【０２５２】（２５）受信データ検証 チケット換金サーバ６５０から換金処理レポートを受信
した配信サーバ６４０は、換金処理レポートの検証処理
を実行する。データ検証により、レポートが正当である
と認められれば、配信サーバの管理主体であるコンテン
ツプロバイダに対するコンテンツ取り引きに伴う料金配
分が完了したことが確認される。
【０２５３】（２６）相互認証 （２７）電子チケット（ＤＡＳ用）送信 （２８）受信データ検証、換金処理 （２９）換金処理レポート報告 （３０）受信データ検証 ユーザ機器認証サーバ６３０とチケット換金サーバ６５
０との間においても、上述の配信サーバ６４０とチケッ
ト換金サーバ６５０間の処理（２１）〜（２５）と同様
の処理が電子チケット（ＤＡＳ用）に基づいて実行され
る。
【０２５４】（３１）相互認証 （３２）換金処理レポート報告 （３３）受信データ検証 また、チケット換金サーバ６５０は、各エンティテイか
ら受領したチケットに基づいて換金処理を実行した場
合、チケット発行サーバ６１０との相互認証後、各エン
ティテイに送付したと同様の換金処理レポート（図４６
（ｎ）参照）をチケット発行サーバ６１０に送信する。
チケット発行サーバ６１０は、チケット換金サーバ６５
０から受信した換金処理レポートの検証を実行し、発行
したチケットに関する換金処理が完了したことを確認す
る。
【０２５５】（各機器におけるステータス遷移）図３７
に示すチケット発行サーバ６１０等の各エンティテイ
は、それぞれコンテンツ取り引きに係る一連の処理にお
いて、処理状態を示すステータスに応じて、次の処理を
決定する。ステータスは、例えば図３９に示すチケット
発行管理データベース、図４０のユーザ機器の購入管理
データベース等において、各コンテンツ取り引き毎に管
理される。
【０２５６】まず、チケット発行サーバ６１０のステー
タス遷移について、図４８を用いて説明する。チケット
発行サーバ６１０は、ユーザ機器６２０からのコンテン
ツ購入要求データを受信（図３７の処理（３）に対応）
することで処理が開始される。チケット発行サーバ６１
０は、ユーザ機器６２０からの受信データを検証し、検
証に成功した場合は、ステータスを「購入受付完了」に
設定し、データ検証により正当な購入要求であるとの判
定がなされなかった場合等には、処理を中止するか、あ
るいは同様の処理、ここでは、購入受付処理を所定回数
繰り返した後処理を中止し、ステータスを「購入受付失
敗」とする。ステータスが「購入受付完了」である場合
にのみ次ステップに進む。
【０２５７】ステータスが「購入受付完了」に遷移する
と、次に、チケット発行サーバ６１０は、ユーザ機器６
２０に対して電子チケットを送信（図３７の処理（７）
に対応）し、ユーザ機器からの受信応答（レスポンス）
を受領することにより、ステータスを「チケット配信完
了」とする。受信応答（レスポンス）を受領しなかった
場合は、処理を中止するか、あるいは同様の処理、ここ
では、電子チケットの送信処理を所定回数繰り返した
後、処理を中止し、ステータスを「チケット配信失敗」
とする。ステータスが「チケット配信完了」である場合
にのみ次ステップに進む。
【０２５８】ステータスが「チケット配信完了」に遷移
した場合、次に、チケット発行サーバ６１０は、チケッ
ト換金サーバから換金処理レポートを受信し、レポート
の検証（図３７の処理（３２）、（３３）に対応）を実
行する。検証に成功した場合は、ステータスを「換金処
理レポート受信完了」に設定し、処理終了とする。レポ
ート検証により正当なレポートであるとの判定がなされ
なかった場合等には、処理を中止するか、あるいは同様
の処理、ここでは、レポート受信、検証処理を所定回数
繰り返した後、処理を中止し、ステータスを「換金レポ
ート受信失敗」とする。チケット発行サーバ６１０は、
このような状態遷移を各コンテンツ取り引き毎に実行す
る。
【０２５９】次にユーザ機器認証サーバ６３０のステー
タス遷移について、図４９を用いて説明する。ユーザ機
器認証サーバ６３０は、ユーザ機器６２０からの暗号化
コンテンツ鍵ＫｐＤＡＳ（Ｋｃ）を受信（図３７の処理
（１５）に対応）することで処理が開始される。ユーザ
機器認証サーバ６３０は、ユーザ機器６２０からの電子
チケット（ＤＡＳ）を含む受信データを検証し、検証に
成功した場合は、ステータスを「鍵受信完了」に設定
し、データ検証により正当なデータであるとの判定がな
されなかった場合等には、処理を中止するか、あるいは
同様の処理、ここでは、暗号化コンテンツ鍵データ（ユ
ーザ機器）の受信処理を所定回数繰り返した後、処理を
中止し、ステータスを「鍵受信失敗」とする。ステータ
スが「鍵受信完了」である場合にのみ次ステップに進
む。
【０２６０】ステータスが「鍵受信完了」に遷移する
と、次に、ユーザ機器認証サーバ６３０は、コンテンツ
鍵かけかえ処理（図３７の処理（１７）に対応）を実行
し、鍵かけかえ処理が成功した場合には、ステータスを
「鍵かけかえ完了」とする。鍵かけかえに失敗すること
は想定していないので、ここでは「鍵かけかえ完了」の
みのステータス遷移が存在する。
【０２６１】ステータスが「鍵かけかえ完了」に遷移し
た場合、次に、ユーザ機器認証サーバ６３０は、ユーザ
機器６２０に対して暗号化コンテンツ鍵データ（ＤＡ
Ｓ）を送信（図３７の処理（１８）に対応）し、ユーザ
機器６２０からのデータ受信応答を受信する。データ受
信応答を受信した場合は、ステータスを「鍵送信完了」
に設定し、データ受信応答の受信がなされなかった場合
等には、処理を中止するか、あるいは同様の処理、ここ
では、暗号化コンテンツ鍵データ（ＤＡＳ）の送信処理
を所定回数繰り返した後、処理を中止し、ステータスを
「鍵送信失敗」とする。
【０２６２】ステータスが「鍵送信完了」に遷移する
と、次に、ユーザ機器認証サーバ６３０は、チケット換
金サーバ６５０に対して、電子チケット（ＤＡＳ用）を
送信（図３７の処理（２７）に対応）し、チケット換金
サーバ６５０からのデータ受信応答を受信する。データ
受信応答を受信した場合は、ステータスを「チケット換
金要求送信完了」に設定し、データ受信応答の受信がな
されなかった場合等には、処理を中止するか、あるいは
同様の処理、ここでは、チケット換金要求の送信処理を
所定回数繰り返した後、処理を中止し、ステータスを
「チケット換金要求失敗」とする。
【０２６３】ステータスが「チケット換金要求送信完
了」に遷移すると、次に、ユーザ機器認証サーバ６３０
は、チケット換金サーバ６５０からの換金処理レポート
を受信し、レポートの検証処理（図３７の処理（２
９）、（３０）に対応）を実行する。検証に成功した場
合は、ステータスを「換金処理レポート受信完了」に設
定し、処理終了とする。レポート検証により正当なレポ
ートであるとの判定がなされなかった場合等には、処理
を中止するか、あるいは同様の処理、ここでは、レポー
ト受信、検証処理を所定回数繰り返した後、処理を中止
し、ステータスを「換金レポート受信失敗」とする。ユ
ーザ機器認証サーバ６３０は、このような状態遷移を各
コンテンツ取り引き毎に実行する。
【０２６４】次に配信サーバ６４０のステータス遷移に
ついて、図５０を用いて説明する。配信サーバ６４０
は、ユーザ機器６２０からの電子チケット（ＣＰ用）を
受信（図３７の処理（１０）に対応）することで処理が
開始される。配信サーバ６４０は、ユーザ機器６２０か
らの受信データを検証し、検証に成功した場合は、ステ
ータスを「電子チケット受信完了」に設定し、データ検
証により正当なデータであるとの判定がなされなかった
場合等には、処理を中止するか、あるいは同様の処理、
ここでは、チケットの受信処理を所定回数繰り返した
後、処理を中止し、ステータスを「電子チケット受信失
敗」とする。ステータスが「電子チケット受信完了」で
ある場合にのみ次ステップに進む。
【０２６５】ステータスが「電子チケット受信完了」に
遷移すると、次に、配信サーバ６４０は、ユーザ機器６
２０に対して暗号化コンテンツおよび暗号化コンテンツ
鍵データＫｐＤＡＳ（Ｋｃ）を送信（図３７の処理（１
２）に対応）し、ユーザ機器６２０からのデータ受信応
答を受信する。データ受信応答を受信した場合は、ステ
ータスを「配信完了」に設定し、データ受信応答の受信
がなされなかった場合等には、処理を中止するか、ある
いは同様の処理、ここでは、暗号化コンテンツおよび暗
号化コンテンツ鍵データＫｐＤＡＳ（Ｋｃ）の送信処理
を所定回数繰り返した後、処理を中止し、ステータスを
「配信失敗」とする。
【０２６６】ステータスが「配信完了」に遷移すると、
次に、配信サーバ６４０は、チケット換金サーバ６５０
に対して、電子チケット（ＣＰ用）を送信（図３７の処
理（２２）に対応）し、チケット換金サーバ６５０から
のデータ受信応答を受信する。データ受信応答を受信し
た場合は、ステータスを「チケット換金要求送信完了」
に設定し、データ受信応答の受信がなされなかった場合
等には、処理を中止するか、あるいは同様の処理、ここ
では、チケット換金要求の送信処理を所定回数繰り返し
た後、処理を中止し、ステータスを「チケット換金要求
失敗」とする。
【０２６７】ステータスが「チケット換金要求送信完
了」に遷移すると、次に、配信サーバ６４０は、チケッ
ト換金サーバ６５０からの換金処理レポートを受信し、
レポートの検証処理（図３７の処理（２４）、（２５）
に対応）を実行する。検証に成功した場合は、ステータ
スを「換金処理レポート受信完了」に設定し、処理終了
とする。レポート検証により正当なレポートであるとの
判定がなされなかった場合等には、処理を中止するか、
あるいは同様の処理、ここでは、レポート受信、検証処
理を所定回数繰り返した後、処理を中止し、ステータス
を「換金レポート受信失敗」とする。配信サーバ６４０
は、このような状態遷移を各コンテンツ取り引き毎に実
行する。
【０２６８】次に、ユーザ機器６２０のステータス遷移
について、図５１を用いて説明する。ユーザ機器６２０
は、まず、チケット発行サーバ６１０に対して購入要求
データを送信（図３７の処理（３）に対応）することで
処理が開始される。ユーザ機器６２０は、チケット発行
サーバ６１０に対する購入要求データの受信完了のレス
ポンスを受信すると、ステータスを「購入要求送信完
了」に設定し、チケット発行サーバ６１０からの受信完
了のレスポンスを受信できない場合は、処理を中止する
か、あるいは同様の処理、ここでは、購入要求送信処理
を所定回数繰り返した後、処理を中止し、ステータスを
「購入要求送信失敗」とする。ステータスが「購入要求
送信完了」である場合にのみ次ステップに進む。
【０２６９】ステータスが「購入要求送信完了」に遷移
すると、次に、ユーザ機器６２０は、チケット発行サー
バ６１０から、電子チケットを受信（図３７の処理
（７）、（８）に対応）し、受信データを検証する。チ
ケット発行サーバ６１０からのチケットの検証に成功し
た場合は、ステータスを「電子チケット受信完了」に設
定し、データ検証により正当なチケットであるとの判定
がなされなかった場合等には、処理を中止するか、ある
いは同様の処理、ここでは、チケット受信処理を所定回
数繰り返した後、処理を中止し、ステータスを「電子チ
ケット受信失敗」とする。ステータスが「電子チケット
受信完了」である場合にのみ次ステップに進む。
【０２７０】ステータスが「電子チケット受信完了」に
遷移した場合、次に、ユーザ機器６２０は、配信サーバ
６４０に対して、電子チケットを送信（図３７の処理
（１０）に対応）し、データ受信レスポンスを受信す
る。データ受信レスポンスを受信した場合は、ステータ
スを「電子チケット送信完了」に設定し、データ受信レ
スポンスを受信しない場合は、処理を中止するか、ある
いは同様の処理、ここでは、チケット送信処理を所定回
数繰り返した後、処理を中止し、ステータスを「電子チ
ケット送信失敗」とする。ステータスが「電子チケット
送信完了」である場合にのみ次ステップに進む。
【０２７１】ステータスが「電子チケット送信完了」に
遷移すると、次に、ユーザ機器６２０は、配信サーバ６
４０から、暗号化コンテンツと、暗号化コンテンツ鍵Ｋ
ｐＤＡＳ（Ｋｃ）を受信し、データ検証（図３７の処理
（１２）、（１３）に対応）を実行する。データ検証に
成功した場合は、ステータスを「鍵１受信完了」に設定
し、データ検証に成功しなかった場合等には、処理を中
止するか、あるいは同様の処理、ここでは、鍵データの
受信処理を所定回数繰り返した後、処理を中止し、ステ
ータスを「鍵１受信失敗」とする。
【０２７２】ステータスが「鍵１受信完了」に遷移する
と、次に、ユーザ機器６２０は、ユーザ機器認証サーバ
６３０に対して電子チケット（ＤＡＳ用）と暗号化コン
テンツ鍵ＫｐＤＡＳ（Ｋｃ）を送信（図３７の処理（１
５）に対応）し、データ受信レスポンスを受信する。デ
ータ受信レスポンスを受信した場合は、ステータスを
「鍵かけかえ要求送信完了」に設定し、データ受信レス
ポンスを受信しない場合は、処理を中止するか、あるい
は同様の処理、ここでは、電子チケット（ＤＡＳ用）と
暗号化コンテンツ鍵ＫｐＤＡＳ（Ｋｃ）の送信処理を所
定回数繰り返した後、処理を中止し、ステータスを「鍵
かけかえ要求送信失敗」とする。ステータスが「鍵かけ
かえ要求送信完了」である場合にのみ次ステップに進
む。
【０２７３】ステータスが「鍵かけかえ要求送信完了」
に遷移すると、次に、ユーザ機器６２０は、ユーザ機器
認証サーバ６３０から、暗号化コンテンツ鍵ＫｐＤＥＶ
（Ｋｃ）を受信し、データ検証（図３７の処理（１
８）、（１９）に対応）を実行する。データ検証に成功
した場合は、ステータスを「鍵２受信完了」に設定し、
処理を終了する。データ検証に成功しなかった場合等に
は、処理を中止するか、あるいは同様の処理、ここで
は、鍵データの受信処理を所定回数繰り返した後、処理
を中止し、ステータスを「鍵２受信失敗」とする。
【０２７４】次にチケット換金サーバ６５０のステータ
ス遷移について、図５２を用いて説明する。チケット換
金サーバ６５０は、電子チケットによる配分権を持つエ
ンティテイからの電子チケットを受信（図３７の処理
（２２）、（２７）に対応）することで処理が開始され
る。チケット換金サーバ６５０は、受信チケットを検証
し、検証に成功した場合は、ステータスを「電子チケッ
ト受信完了」に設定し、データ検証により正当なデータ
であるとの判定がなされなかった場合等には、処理を中
止するか、あるいは同様の処理、ここでは、チケットの
受信処理を所定回数繰り返した後、処理を中止し、ステ
ータスを「電子チケット受信失敗」とする。ステータス
が「電子チケット受信完了」である場合にのみ次ステッ
プに進む。
【０２７５】ステータスが「電子チケット受信完了」に
遷移すると、次に、チケット換金サーバ６５０は、電子
チケットに基づく換金処理を実行する。換金処理は、予
め登録されている利益配分エンティテイ、例えば配信サ
ーバを管理するコンテンツプロバイダ（ＣＰ）の管理口
座、あるいは電子マネー口座等に、電子チケット（ＣＰ
用）に設定された金額をユーザ機器の管理ユーザの口座
から振り替える処理、あるいは既にチケット発行サーバ
がユーザからの前払い預り金として受領しているチケッ
ト発行サーバ管理口座からコンテンツプロバイダ（Ｃ
Ｐ）の管理口座にチケットに設定された金額を振り替え
る処理として行なわれる。換金処理が完了するとステー
タスを「換金処理完了」に設定し、換金処理が実行でき
なかった場合には、処理を中止し、ステータスを「換金
処理失敗」とする。
【０２７６】ステータスが「換金処理完了」に遷移する
と、次に、チケット換金サーバ６５０は、チケットを送
信してきたエンティテイに対して、換金処理レポートを
送信（図３７の処理（２４）、（２９）に対応）し、各
エンティテイからのデータ受信応答を受信する。データ
受信応答を受信した場合は、ステータスを「換金レポー
ト送信完了」に設定し、処理を終了する。データ受信応
答の受信がなされなかった場合等には、処理を中止する
か、あるいは同様の処理、ここでは、換金レポートの送
信処理を所定回数繰り返した後、処理を中止し、ステー
タスを「換金レポート送信失敗」とする。チケット換金
サーバ６５０は、このような状態遷移を各コンテンツ取
り引き毎に実行する。
【０２７７】図５３にチケット発行体によって発行され
るチケットを流通させることによりコンテンツ料金の精
算処理を行なう具体的構成例を示す。ユーザ機器８０２
からチケット発行体８０１に対してコンテンツ購入要求
があると、チケット発行体は、コンテンツの取り引きに
関する課金処理、電子チケット発行処理を実行する。こ
れらの処理は、例えば予め登録されているユーザ口座、
あるいは電子マネー口座等に基づいて設定されるユーザ
の取り引き金額限度内の電子チケットを発行する処理と
して実行される。図５３に示す例では、コンテンツ購入
代金として１，０００円分の電子チケットをチケット発
行体がユーザ機器に対して発行する。
【０２７８】図５３の例では、コンテンツ料金１０００
円の配分は、図上部に示すように、チケット発行体とし
てのショップが販売手数料としてのショップ利益として
３００円、コンテンツ配信のシステム運営者であるライ
センスホルダ（ユーザ機器認証サーバ）８０３がライセ
ンス料として１００円、コンテンツ製作者（配信サー
バ）がコンテンツ料として６００円を、それぞれ受領す
る設定であるとする。
【０２７９】ユーザ機器からの購入要求を受領したチケ
ット発行体８０１は、コンテンツＩＤからコンテンツ料
金の配分比率の設定情報を求め、複数の料金配分先があ
る場合は、それぞれの電子チケットを発行する。図５３
の例では、ライセンスホルダ８０３に対するセイセンス
料、１００円の配分料金を設定した電子チケットと、コ
ンテンツ製作者に対するコンテンツ料、６００円のチケ
ットをユーザ機器８０２に配信する。配信する電子チケ
ットには、チケット発行体の署名が生成される。
【０２８０】ユーザ機器８０２は、ライセンスホルダ８
０３、コンテンツ製作者８０４それぞれに各電子チケッ
トを送信する。ライセンスホルダ８０３、コンテンツ製
作者８０４は、受領した電子チケットを検証して、正当
なチケットであることを確認した後、銀行（チケット換
金サーバ）８０５にチケットを送信し、換金サーバにお
いても署名検証を実行し、正当なチケットであることを
確認してそれぞれの配分料金の換金（ｅｘ．振替処理）
を行なう。なお、銀行（チケット換金サーバ）において
実行するチケットの署名検証は、電子チケットに対して
生成されたチケット発行体の署名の検証である。また、
チケットに含まれる購入要求データのユーザ機器署名の
検証も実行する。
【０２８１】さらに、チケットの送信主体であるコンテ
ンツ製作者、ライセンスホルダが電子チケットを含む送
信データに対して署名を生成し、これらの署名について
も銀行（チケット換金サーバ）が署名検証を実行する構
成としてもよい。
【０２８２】図５３の構成では、チケット発行体（ショ
ップ）８０１自身もコンテンツ料金の一部３００円分の
自己の電子チケットを銀行（チケット換金サーバ）８０
５に送付して換金を行なう構成である。
【０２８３】これらの各電子チケットの換金処理によ
り、確実にコンテンツ料金の配分が実行される。コンテ
ンツ製作者８０４は、電子チケットをユーザ機器８０２
から受領して検証した後、コンテンツ鍵Ｋｃで暗号化し
た暗号化コンテンツと、コンテンツ鍵Ｋｃをライセンス
ホルダ（ユーザ機器認証サーバ）の公開鍵ＫｐＤＡＳで
暗号化した暗号化コンテンツ鍵：ＫｐＤＡＳ（Ｋｃ）を
ユーザ機器８０２に送信する。
【０２８４】ユーザ機器８０２は、コンテンツ制作者８
０４から受領した暗号化コンテンツ鍵ＫｐＤＡＳ（Ｋ
ｃ）を電子チケット（ＤＡＳ）とともに、ライセンスホ
ルダ８０３に送信する。ライセンスホルダは、電子チケ
ットの検証の後、暗号化コンテンツ鍵ＫｐＤＡＳ（Ｋ
ｃ）の鍵かけかえ処理を実行し、ユーザ機器の公開鍵Ｋ
ｐＤＥＶでコンテンツ鍵を暗号化して、ＫｐＤＥＶ（Ｋ
ｃ）を生成してユーザ機器８０２に送信する。ユーザ機
器８０２は、ＫｐＤＥＶ（Ｋｃ）を自己の秘密鍵ＫｓＤ
ＥＶで復号してコンテンツ鍵Ｋｃを得ることができる。
またコンテンツ鍵をデバイスに格納する場合は、自己の
保存鍵Ｋｓｔｏで暗号化して保存する。
【０２８５】上述したように、チケット発行体によって
発行するチケットを受信し、正当なチケットであること
を条件として配信サーバ（ｅｘ．コンテンツ製作者）が
暗号化コンテンツと暗号化コンテンツ鍵をユーザ機器に
送信し、一方、ライセンスホルダ（ユーザ認証機器）
が、同様に電子チケットを受領し、正当なチケットであ
ることを条件として暗号化コンテンツ鍵のかけかえを行
なってユーザ機器に配信する構成としたことにより、電
子チケットに基づく確実なコンテンツ料金の配分が実行
され、ユーザ機器においてコンテンツの利用が可能とな
る。
【０２８６】［３．ログ収集サーバによるコンテンツ配
信管理］次に、ユーザ機器がコンテンツの購入を行なっ
た事実をユーザ機器にログとして蓄積し、ログの回収を
システム運営者が行なうことにより、コンテンツの流通
実体を正確に把握可能としたコンテンツ配信システムに
ついて説明する。
【０２８７】図５４にログ回収システムを持つコンテン
ツ配信形態のシステム構成を示す。図５４のコンテンツ
配信システムは、ユーザ機器に対するコンテンツの配信
サービスを行なうショップサーバ（ＳＨＯＰ）９０１、
ショップサーバ９０１からのコンテンツ配信を受信する
ユーザ機器（ＤＥＶＩＣＥ）９０２、さらに、正当なコ
ンテンツ取り引き管理のためのログ管理サーバとして機
能するログ収集サーバ９０３を主構成要素とし、コンテ
ンツの提供者としてのコンテンツプロバイダ９０５と、
コンテンツプロバイダ９０５から提供されるコンテンツ
に対してコンテンツの利用制限情報等の各種情報をヘッ
ダとして生成し、ショップサーバに提供するオーサリン
グサーバ９０４、さらに、各エンティテイに対して公開
鍵証明書（Ｃｅｒｔ＿ｘｘｘ）を発行する認証局（Ｃ
Ａ：Certificate Authority）を有する。
【０２８８】図５４の構成において、コンテンツプロバ
イダ９０５とオーサリングサーバ９０４は、ショップサ
ーバ９０１に対して、流通対象となるコンテンツを提供
するエンティテイ構成の一例であり、図５４の形態に限
らず、他の様々な態様でショップサーバに対する流通コ
ンテンツの提供がなされる。例えばコンテンツプロバイ
ダから直接ショップサーバにコンテンツが提供されても
よいし、コンテンツの保持者である著作者から複数のサ
ービスプロバイダを介してショップサーバにコンテンツ
が提供される場合もある。
【０２８９】図５４の構成例は、本発明の説明の理解を
容易にするために、コンテンツ売り上げの一部を取得す
る権利を持つエンティテイの1つの代表例としてコンテ
ンツプロバイダ９０５を示したものである。図５４の構
成例では、コンテンツプロバイダ９０５は、ログ収集サ
ーバ９０３によって収集されるログに基づいて管理され
るコンテンツ売り上げデータの確認により、自己の配分
利益を確実に取得することができる。他の利益配分権を
有するエンティテイがある場合は、そのエンティテイが
図５４の構成に加わり、ログ収集サーバ９０３によって
収集されるログに基づいて自己の配分利益を確認可能で
ある。
【０２９０】図５４の構成において、ショップサーバ９
０１は、図１他の構成において説明したと同様の構成で
あり、暗号処理、通信処理可能な制御部を有し、コンテ
ンツ取り引き処理に伴うステータス管理を実行して、各
機器における取り引き処理シーケンスを実行する。ま
た、コンテンツプロバイダ９０５とオーサリングサーバ
９０４も暗号処理、通信処理可能な制御部を有し、コン
テンツ取り引き処理に伴うステータス管理を実行して、
各機器における取り引き処理シーケンスを実行する。
【０２９１】（ユーザ機器）ユーザ機器９０２は、先に
図７を用いて説明した構成と同様であり、暗号処理、通
信処理可能な制御手段２３０（図７参照）を有する。た
だし、本実施例では、制御手段２３０は、コンテンツ購
入処理毎にログデータを生成し、購入管理データベース
２２０中に生成したログデータを格納する。
【０２９２】ユーザ機器９０２において生成され格納さ
れるログデータの構成例を図５５に示す。図５５には、
ログデータの例を２つ示している。（Ａ）構成例１は、
ユーザ機器９０２がショップサーバ９０１との取り引き
により取得したコンテンツの識別子であるコンテンツＩ
Ｄ、ユーザ機器の識別子であるユーザ機器ＩＤ（ＩＤ＿
ＤＥＶ）、取り引きを行なったショップの識別子である
ショップＩＤ（ＩＤ＿ＳＨＯＰ）、取り引きの日時を示
す日付情報が含まれ、これらのデータに対するユーザ機
器の署名（Ｓｉｇ．ＤＥＶ）が生成されている。ログ収
集サーバはユーザ機器から受信する購入ログの電子署名
の検証処理を実行する。（Ｂ）構成例２は、販売確認デ
ータとコンテンツの受領日時データに対してユーザ機器
の署名（Ｓｉｇ．ＤＥＶ）が生成された構成である。販
売確認データは、ショップサーバ９０１がユーザ機器９
０２からのコンテンツ購入要求に基づいて生成するコン
テンツの販売を実行したことを示すデータである。販売
確認データについては、後段でさらに説明する。
【０２９３】ユーザ機器９０２は、コンテンツ購入処理
に際して、例えば図５５に示すログデータを生成しユー
ザ機器内に格納する。格納されたログデータは、ログ収
集サーバ９０３に送信される。ユーザ機器は自己の公開
鍵証明書の更新処理実行時に、その間に蓄積したログデ
ータをログ収集サーバ９０３に送信する。これらの処理
シーケンスについては、フローを用いて後段で詳細に説
明する。
【０２９４】（ログ収集サーバ）ログ収集サーバ９０３
は、図５６に示す構成を有する。ログ収集サーバは、収
集ログ管理データベース９０３１を有する。収集ログ管
理データベース９０３１は、様々なユーザ機器から受領
するログデータ（図５５参照）を格納するデータベース
である。
【０２９５】ログ収集サーバ９０３は、ユーザ機器９０
２、ショップサーバ９０１等との通信処理、さらに、各
通信処理に際してのデータ暗号処理等を実行する制御手
段９０３２を有する。制御手段９０３２は、先に説明し
たショップサーバ等の制御手段と同様、暗号処理手段、
通信処理手段としての機能も有する。その構成は、図４
を用いて説明した構成と同様である。制御手段９０３２
の暗号処理手段において実行される暗号処理において使
用される鍵データ等は、制御手段内部の記憶手段にセキ
ュアに格納されている。ログ収集サーバ９０３が格納す
る暗号鍵等の暗号処理用データとしては、ログ収集サー
バ９０３の秘密鍵：ＫｓＬＯＧ、ログ収集サーバ９０３
の公開鍵証明書Ｃｅｒｔ＿ＬＯＧ、公開鍵証明書の発行
機関である公開鍵証明書発行局としての認証局（ＣＡ：
Certificate Authority）の公開鍵ＫｐＣＡがある。
【０２９６】ログ収集サーバ９０３は、ユーザ機器９０
２からのログデータ受領と引き換えに、公開鍵証明書の
発行手続き処理を実行する。具体的には、ユーザ機器９
０２から更新用の公開鍵を受領して、受領した公開鍵を
認証局９０６に転送して、ユーザ機器の公開鍵証明書の
発行要求を行ない、認証局９０６の発行した公開鍵証明
書を受領してユーザ機器９０２に送信する。この一連の
処理については、フローを用いて後段で詳細に説明す
る。
【０２９７】（コンテンツ購入処理）本実施例における
処理は、図５４の上段に示すように、 Ａ．コンテンツ購入処理 Ｂ．ログ送信、公開鍵証明書更新処理 Ｃ．コンテンツ販売準備処理 Ｄ．売り上げ確認処理 の４つの処理に分類される。以下、これらの各処理につ
いてフローを用いて説明する。
【０２９８】（Ａ．コンテンツ購入処理）コンテンツ購
入処理について、図５７、図５８のフローを用いて説明
する。図５７、図５８においては、左側にユーザ機器、
右側にショップサーバの処理を示している。まず、図５
７に示すように、処理開始時に、ユーザ機器とショップ
サーバ間において相互認証が実行される（Ｓ１５０１，
Ｓ１６０１）。
【０２９９】相互認証処理は、図１３を用いて説明した
公開鍵方式に基づく処理として実行される。この相互認
証においては、認証局（ＣＡ）９０６の発行する有効期
限の設定された公開鍵証明書を用いて行われ、ユーザ機
器は、有効期限内の公開鍵証明書を持つことが相互認証
を成立させるための条件として求められる。後段で説明
するが、公開鍵証明書の更新処理は、ログ収集サーバ９
０３に対するログの送信を条件として実行される。
【０３００】相互認証処理において生成したセッション
鍵（Ｋｓｅｓ）は、必要に応じて送信データを暗号化し
てデータ通信を実行したり、あるいはＫｓｅｓを用いた
改竄チェック値（ＩＣＶ：Integrity Check Value）の
生成処理に使用される。ＩＣＶの生成については後述す
る。
【０３０１】相互認証が成立すると、ユーザ機器は、コ
ンテンツ取り引きにおいて適用するトランザクションＩ
Ｄを例えば乱数に基づいて生成し、購入要求データを生
成（Ｓ１５０２）する。購入要求データのフォーマット
例を図５９（Ａ）に示す。
【０３０２】購入要求データには前述のトランザクショ
ンＩＤ（ＴＩＤ＿ＤＥＶ）、コンテンツ識別子であるコ
ンテンツＩＤ、ユーザ機器の識別子であるユーザ機器Ｉ
Ｄ（ＩＤ＿ＤＥＶ）、コンテンツ価格である表示価格、
さらに購入依頼日時を含み、これらのデータに対するユ
ーザ機器の署名（Ｓｉｇ．Ｄｅｖ）を生成した構成であ
る。
【０３０３】さらに、ユーザ機器は、購入要求データの
改竄チェック値（ＩＣＶ１）を生成して、ショップサー
バに送信（Ｓ１５０３）する。改竄チェック値（ＩＣ
Ｖ）は、改竄チェック対象データに対するハッシュ関数
を用いて計算され、ＩＣＶ＝ｈａｓｈ（Ｋｉｃｖ，Ｃ
１，Ｃ２，…）によって計算される。ＫｉｃｖはＩＣＶ
生成キーである。Ｃ１，Ｃ２は改竄チェック対象データ
の情報であり、改竄チェック対象データの重要情報のメ
ッセージ認証符号（ＭＡＣ：Message authentication C
ode）が使用される。
【０３０４】ＤＥＳ暗号処理構成を用いたＭＡＣ値生成
例を図６０に示す。図６０の構成に示すように対象とな
るメッセージを８バイト単位に分割し、（以下、分割さ
れたメッセージをＭ１、Ｍ２、・・・、ＭＮとする）、
まず、初期値（Initial Value（以下、ＩＶとする））
とＭ１を排他的論理和する（その結果をＩ１とする）。
次に、Ｉ１をＤＥＳ暗号化部に入れ、鍵（以下、Ｋ１と
する）を用いて暗号化する（出力をＥ１とする）。続け
て、Ｅ１およびＭ２を排他的論理和し、その出力Ｉ２を
ＤＥＳ暗号化部へ入れ、鍵Ｋ１を用いて暗号化する（出
力Ｅ２）。以下、これを繰り返し、全てのメッセージに
対して暗号化処理を施す。最後に出てきたＥＮがメッセ
ージ認証符号（ＭＡＣ（Message Authentication Cod
e））となる。なお、メッセージとしては、検証対象と
なるデータを構成する部分データが使用可能である。
【０３０５】このようなチェック対象データの改竄チェ
ック値（ＩＣＶ）は、ＩＣＶ生成キーＫｉｃｖを用いて
生成されたＭＡＣ値として構成される。改竄のないこと
が保証された例えばデータ送信側がデータ生成時に生成
したＩＣＶと、データ受信側が受信データに基づいて生
成したＩＣＶとを比較して同一のＩＣＶが得られればデ
ータに改竄のないことが保証され、ＩＣＶが異なれば、
改竄があったと判定される。
【０３０６】ここでは、ＩＣＶ生成キーとして相互認証
時に生成したセッション鍵：Ｋｓｅｓを使用する。ユー
ザ機器は、セッション鍵：Ｋｓｅｓを適用して購入要求
データ（図５９（Ａ）参照）の改竄チェック値（ＩＣＶ
１）を生成して、購入要求データ＋ＩＣＶ１をショップ
サーバに送信する。
【０３０７】ショップサーバは、ＩＣＶ１の検証、すな
わち、受信データに基づいてセッション鍵：Ｋｓｅｓを
適用して改竄チェック値ＩＣＶ１’を生成して、受信し
たＩＣＶ１＝ＩＣＶ１’が成立するか否かを判定する。
成立した場合は、改竄なしと判定する。さらに、ショッ
プサーバは、購入要求データの署名検証（Ｓ１６０３）
を行なう。署名検証は、ユーザ機器の公開鍵を用いて行
なう。公開鍵はユーザ機器の公開鍵証明書Ｃｅｒｔ＿Ｄ
ＥＶから取り出されるものであり、有効期限内の公開鍵
証明書であることが条件となる。有効期限の切れた公開
鍵証明書は、ショップサーバにおいて署名検証に使用さ
れず、購入依頼ＮＧとなる。ＩＣＶのチェック、署名検
証いずれもＯＫであれば、ショップサーバは、販売確認
データを生成（Ｓ１６０４）する。
【０３０８】販売確認データは、例えば図５９の（Ｂ）
に示すデータ構成を持つ。ショップサーバの生成したト
ランザクションＩＤ（ＴＩＤ＿ＳＨＯＰ）、ショップの
識別子であるショップＩＤ（ＩＤ＿ＳＨＯＰ）、販売日
時、コンテンツ販売に対する運営者手数料情報、ここで
運営者とは、例えば、コンテンツ販売システムの管理エ
ンティテイ（ＳＨ：システムホルダ）であり、図５４で
は、ログ収集サーバ９０３を管理するエンティテイであ
る。
【０３０９】さらに、ＣＰ（コンテンツプロバイダ）売
り上げ分配情報、これは、コンテンツの売り上げに対す
るコンテンツプロバイダの配分を示す情報である。さら
に、購入要求データ（図５９（Ａ）参照）を含み、これ
らのデータにショップの署名（Ｓｉｇ．ＳＨＯＰ）が生
成された構成である。
【０３１０】図５９（Ｂ）の販売確認データフォーマッ
トは、コンテンツの売り上げに対して運営者（ＳＨ：シ
ステムホルダ）と、コンテンツプロバイダ（ＣＰ）との
２つのエンティテイの配分情報のみを記録しているが、
この他にも、コンテンツ売り上げの配分先エンティテイ
が存在する場合は、それらの各エンティテイの配分情報
も格納する。
【０３１１】ＩＣＶのチェック、署名検証いずれもＯＫ
であり、販売確認データを生成（Ｓ１６０４）すると、
ショップサーバは購入を承諾するメッセージを含む購入
ＯＫデータにセッション鍵Ｋｓｅｓを用いて改竄チェッ
ク値（ＩＣＶ２）を生成付加してユーザ機器に送信（Ｓ
１６０５）する。ＩＣＶのチェック、署名検証いずれか
がＮＧであると、ショップサーバは購入を拒否するメッ
セージを含む購入ＮＧデータにセッション鍵Ｋｓｅｓを
用いて改竄チェック値（ＩＣＶ２）を生成付加してユー
ザ機器に送信（Ｓ１６０６）する。
【０３１２】さらに、ショップサーバは、購入ＯＫデー
タをユーザ機器に送信した場合は、販売確認データ（図
５９（Ｂ）参照）と、ヘッダ（コンテンツの利用情報等
を含む各種コンテンツ関連情報）に対してセッション鍵
Ｋｓｅｓを用いて改竄チェック値（ＩＣＶ３）を生成し
たデータとコンテンツとをユーザ機器に送信（Ｓ１６０
７）する。
【０３１３】ユーザ機器は、コンテンツおよび、購入要
求応答データ（ＯＫまたはＮＧ）＋ＩＣＶ２を受信（Ｓ
１５０４）し、ＩＣＶ２の検証を行ない、購入要求応答
を確認（Ｓ１５０５）する。ＩＣＶ２によりデータ改竄
なしと判定され、購入が受け入れられた（ＯＫ）である
ときは、販売確認データ（図５９（Ｂ）参照）と、ヘッ
ダ（コンテンツの利用情報等を含む各種コンテンツ関連
情報）＋ＩＣＶ３を受信（Ｓ１５０６）し、ＩＣＶ３の
検証、販売確認データの署名検証を行ないいずれもＯＫ
である場合は、コンテンツ受信ＯＫのレスポンスにＩＣ
Ｖ４を生成してショップサーバに送信する。
【０３１４】ステップＳ１５０７の判定がＮｏである場
合は、ステップＳ１５０９において、コンテンツ受信Ｎ
ＧのレスポンスにＩＣＶ４を生成してショップサーバに
送信する。
【０３１５】ショップサーバは、コンテンツ受信ＯＫま
たはＮＧ＋ＩＣＶ４を受信（（Ｓ１６０８）し、ＩＣＶ
４の検証を行ない（Ｓ１６１１）、さらにユーザ機器か
らの応答がコンテンツ受信ＯＫである場合は、ユーザに
対するコンテンツの課金処理を実行（Ｓ１６１３）す
る。この課金処理は、前実施例と同様、例えば、ユーザ
の取り引き口座、あるいはクレジットカード指定口座か
らコンテンツ料金を受領する処理である。課金処理が終
了すると、課金終了メッセージにＩＣＶ５を生成してユ
ーザ機器に送信（Ｓ１６１４）する。ステップＳ１６１
１、またはＳ１６１２の判定のいずれかがＮｏである場
合は、ステップＳ１６１５において課金未了メッセージ
にＩＣＶ５を生成してユーザ機器に送信する。
【０３１６】課金終了（または未了）メッセージ＋ＩＣ
Ｖ５を受信したユーザ機器は、ＩＣＶ５の検証を実行
し、さらに課金が無事終了したかを判定し、課金が済ん
だことを確認すると、購入ログ（図５５参照）を生成し
て自デバイスのメモリに保存の後、コンテンツの利用を
行なう。ステップＳ１５１２、またはＳ１５１３の判定
のいずれかがＮｏである場合は、ステップＳ１５１４に
おいてショップサーバから受領したヘッダ、コンテンツ
を削除する処理を行なう。
【０３１７】次に、図６１、図６２を用いてユーザ機器
と、ログ収集サーバ間で行われる鍵更新処理と、ログ送
信処理とについて説明する。図６１、図６２の左側にユ
ーザ機器の処理、右側にログ収集サーバの処理を示す。
この処理は、コンテンツをショップサーバから購入する
ユーザ機器がユーザ機器に格納されたユーザ機器の公開
鍵証明書を更新する際に実行される。ユーザ機器の公開
鍵証明書には有効期限が設定されており、一定期間毎に
更新処理を実行することが必要となる。図６１の処理か
ら説明する。
【０３１８】まず、ユーザ機器とログ収集サーバは、相
互認証を実行（Ｓ１５２１，Ｓ１７２１）しセッション
鍵の生成を行なう。ユーザ機器は認証成立を条件とし
て、ユーザ機器デバイス内のメモリに格納された購入ロ
グを取り出して、購入ログに対してセッション鍵Ｋｓｅ
ｓで改竄チェック値（ＩＣＶ１）を生成して購入ログ＋
ＩＣＶ１をログ収集サーバに送信（Ｓ１５２２）する。
【０３１９】ログ収集サーバは、購入ログ＋ＩＣＶ１を
受信（Ｓ１７２２）し、ＩＣＶ１の検証を実行（Ｓ１７
２３）し、検証ＯＫの場合は、ログをデータベース内に
保存（Ｓ１７２４）する。なお、ログ収集サーバは、さ
らに、購入ログ中のユーザ機器の電子署名の検証処理を
行なって、データ改竄の有無を更にチェックする構成と
してもよい。ログ収集サーバは、さらに、ログ受信ＯＫ
データにセッション鍵Ｋｓｅｓで改竄チェック値（ＩＣ
Ｖ２）を生成し、ログ受信ＯＫデータ＋ＩＣＶ２をユー
ザ機器に送信（Ｓ１７２５）する。ステップＳ１７２３
のＩＣＶ１の検証ＮＧであったときは、ログ受信ＮＧデ
ータにセッション鍵Ｋｓｅｓで改竄チェック値（ＩＣＶ
２）を生成し、ログ受信ＮＧデータ＋ＩＣＶ２をユーザ
機器に送信（Ｓ１７２６）する。
【０３２０】ユーザ機器は、ログ受信データ＋ＩＣＶ２
を受信（Ｓ１５２３）し、ＩＣＶ２の検証ＯＫ、ログ受
信ＯＫ（Ｓ１５２４）である場合は、更新用の公開鍵
（ＫｐＤＥＶ）と秘密鍵（ＫｓＤＥＶ）のペアを生成
（Ｓ１５２５）し、生成した公開鍵（ＫｐＤＥＶ）に改
竄チェック値（ＩＣＶ３）を生成付加してログ収集サー
バに送信（Ｓ１５２６）する。
【０３２１】ログ収集サーバは、公開鍵（ＫｐＤＥＶ）
＋ＩＣＶ３をユーザ機器から受信する（Ｓ１７２７）
と、ＩＣＶ３の検証を実行（Ｓ１７３１）し、検証ＯＫ
である場合は公開鍵受信ＯＫメッセージに対するＩＣＶ
４を生成付加してユーザ機器に送信（Ｓ１７３２）す
る。ＩＣＶ３の検証がＮＧである場合は公開鍵受信ＮＧ
メッセージにＩＣＶ４を生成付加してユーザ機器に送信
（Ｓ１７３３）する。
【０３２２】さらに、ログ収集サーバは、公開鍵受信Ｏ
Ｋメッセージに対するＩＣＶ４を生成付加してユーザ機
器に送信（Ｓ１７３２）した場合、発行局（ＣＡ）に対
して受領公開鍵とともに、公開鍵証明書の発行を要求し
て、ユーザ機器の更新された公開鍵証明書（Ｃｅｒｔ＿
ＤＥＶ）を取得（Ｓ１７３４）し、さらに、更新された
公開鍵証明書（Ｃｅｒｔ＿ＤＥＶ）に対する改竄チェッ
ク値ＩＣＶ５を生成付加してユーザ機器に送信（Ｓ１７
３５）する。
【０３２３】ユーザ機器は、公開鍵受信結果（ＯＫまた
はＮＧ）＋ＩＣＶ４を受信した後、ＩＣＶ４の検証を行
ない、ＩＣＶ４検証ＯＫであり、公開鍵受信ＯＫ（Ｓ１
５３２）である場合には、更新された公開鍵証明書＋Ｉ
ＣＶ５の受信（Ｓ１５３３）を実行し、ＩＣＶ５の検
証、受信した公開鍵証明書の検証（Ｓ１５３４）を実行
する。いずれの検証もＯＫである場合は、公開鍵証明書
内の公開鍵を取り出して、自己の送信した公開鍵との比
較（Ｓ１５３５）を行ない、一致した場合は更新用に生
成した秘密鍵、および受領した公開鍵証明書をユーザ機
器内のメモリに保存（Ｓ１５３６）し、ログ（ログ収集
サーバに送付済みのログ）の消去処理（Ｓ１５３７）を
実行する。
【０３２４】ステップＳ１５３２、Ｓ１５３４、Ｓ１５
３５のいずれかの判定がＮｏである場合は、有効な公開
鍵証明書の更新処理は実行されず、処理は終了する。
【０３２５】次に、コンテンツプロバイダとログ収集サ
ーバ間で実行されるコンテンツ売り上げ確認処理につい
て図６３のフローに基づいて説明する。ログ収集サーバ
は、ユーザ機器から受領する購入ログに基づいてコンテ
ンツ料金の１または複数の料金受領エンティテイに対す
る料金配分情報を管理し、料金受領エンティテイからの
売り上げ確認要求に応じて料金配分情報に基づく応答処
理を実行する。ログ収集サーバは、購入ログに含まれる
コンテンツＩＤと予めログ収集サーバが保有するコンテ
ンツ料金配分情報から、コンテンツの売り上げに基づく
料金受領エンティテイの売り上げを算出することができ
る。なお、図５５（Ｂ）に示す販売確認データを格納し
たログを受領する構成である場合は、販売確認データに
含まれる分配情報に基づいて料金受領エンティテイの売
り上げを算出することができる。
【０３２６】まず、コンテンツプロバイダとログ収集サ
ーバ間において、相互認証（Ｓ１５２１，Ｓ１７２１）
が実行され、セッション鍵Ｋｓｅｓが生成される。ログ
収集サーバは、相互認証の成立を条件として、コンテン
ツプロバイダ（ＣＰ）の公開鍵証明書Ｃｅｒｔ＿ＣＰか
らコンテンツプロバイダの識別子ＩＤ＿ＣＰを取り出し
（Ｓ１７２２）、ＩＤ＿ＣＰに対応する売り上げデータ
をデータベースに格納したログ情報に基づいて生成（Ｓ
１７２３）する。収集したログデータには、前述したよ
うにコンテンツプロバイダの配分情報が格納されてお
り、ログデータに基づいて各コンテンツプロバイダの配
分料金が求められる。さらに、ログ収集サーバは、売り
上げデータに対する改竄チェック値ＩＣＶ１を生成付加
してコンテンツプロバイダ（ＣＰ）に送信（Ｓ１７２
４）する。
【０３２７】コンテンツプロバイタ（ＣＰ）は、ログ収
集サーバから売り上げデータ＋ＩＣＶ１を受信（Ｓ１５
２２）し、ＩＣＶ１の検証を行なってデータ改竄のない
ことを確認して（Ｓ１５２３）売り上げデータをメモリ
に保存（Ｓ１５２４）する。ＩＣＶ１の検証を行なって
データ改竄ありの場合は、メモリに対するデータ保存を
実行せず、処理を終了する。この場合は、再度、ログ収
集サーバに対する売り上げデータ要求を行なう。
【０３２８】次に、ショップサーバとログ収集サーバ、
コンテンツプロバイダ間で実行される売り上げ報告処理
について図６４、図６５の処理フローに基づいて説明す
る。ショップサーバは、コンテンツの売り上げデータを
管理し、ログ収集サーバに対して、所定期間内の全売り
上げてデータまたは、料金受領エンティテイ毎の売り上
げデータを送信する処理を実行する。図６４は、ショッ
プサーバが実行したコンテンツ販売処理全体の売り上げ
を一括してログ収集サーバに送信する処理であり、図６
５の処理は、ショップサーバが実行したコンテンツ販売
処理中、特定のコンテンツプロバイダの提供したコンテ
ンツに関する売り上げを選択してコンテンツプロバイダ
に送信する処理である。
【０３２９】図６４の売り上げ一括報告処理から説明す
る。まず、ショップサーバとログ収集サーバ間におい
て、相互認証（Ｓ１６３１，Ｓ１７３１）が実行され、
セッション鍵Ｋｓｅｓが生成される。ショップサーバ
は、相互認証の成立を条件として、所定期間の全売り上
げデータをデータベースから取り出し、全売り上げデー
タに対する改竄チェック値ＩＣＶ１を生成付加してログ
収集サーバに送信（Ｓ１６３２）する。
【０３３０】ログ収集サーバは、ショツプサーバから全
売り上げデータ＋ＩＣＶ１を受信（Ｓ１７３２）し、Ｉ
ＣＶ１の検証を行なってデータ改竄のないことを確認し
て（Ｓ１７３３）、売り上げデータをメモリに保存（Ｓ
１７３４）する。ＩＣＶ１の検証を行なってデータ改竄
ありの場合は、メモリに対するデータ保存を実行せず、
処理を終了する。この場合は、再度、ショップサーバに
対する売り上げデータ要求を行なう。
【０３３１】図６５の特定コンテンツプロバイダ売り上
げ報告処理について説明する。まず、ショップサーバと
コンテンツプロバイダ間において、相互認証（Ｓ１６４
１，Ｓ１７４１）が実行され、セッション鍵Ｋｓｅｓが
生成される。ショップサーバは、相互認証の成立を条件
として、相互認証で得られたコンテンツプロバイダの公
開鍵証明書Ｃｅｒｔ＿ＣＰからコンテンツプロバイダの
識別子であるＩＤ＿ＣＰを取り出し（Ｓ１６４２）、取
り出したＩＤ＿ＣＰに基づいて、売り上げデータの検索
を行ない、その特定コンテンツプロバイダの提供コンテ
ンツの売り上げデータを取得（Ｓ１６４３）する。さら
に売り上げデータに対する改竄チェック値ＩＣＶ１を生
成付加してログ収集サーバに送信（Ｓ１６４４）する。
【０３３２】ログ収集サーバは、ショツプサーバから全
売り上げデータ＋ＩＣＶ１を受信（Ｓ１７４２）し、Ｉ
ＣＶ１の検証を行なってデータ改竄のないことを確認し
て（Ｓ１７４３）、売り上げデータをメモリに保存（Ｓ
１７４４）する。ＩＣＶ１の検証を行なってデータ改竄
ありの場合は、メモリに対するデータ保存を実行せず、
処理を終了する。この場合は、再度、ショップサーバに
対する売り上げデータ要求を行なう。
【０３３３】本実施例の構成によれば、ユーザ機器の公
開鍵証明書の更新処理に応じてコンテンツ購入ログデー
タを収集することが可能となり、ログ収集サーバを管理
するシステム運営者（ＳＨ：System Holder）は、コン
テンツ売り上げ状況を確実に把握することが可能とな
る。ユーザ機器の公開鍵証明書は、ショップサーバとの
相互認証処理において必要であり、有効な期限の設定さ
れた公開鍵証明書を有することがコンテンツ購入を実行
するための条件となる。また、ユーザ機器からの購入要
求データ等に付加される署名の検証もユーザ機器の公開
鍵証明書から取り出される公開鍵によって実行されるこ
とになり、有効な期限の設定された公開鍵証明書を有す
ることが署名検証においても必要となる。従って、ユー
ザ機器は、コンテンツ購入を行なうためには、ログデー
タをログ収集サーバに送信し、公開鍵証明書の更新を行
ない有効な期限を持つ公開鍵証明書を有することが必要
となる。公開鍵証明書の有効期限を例えば１ヶ月、また
は３ヶ月等に設定することにより、ログ収集サーバを管
理するシステム運営者（ＳＨ：System Holder）は、各
設定機関毎の蓄積ログを確実に収集することができる。
【０３３４】上述したように、システム運営者の管理す
るログ収集サーバにより確実にユーザ機器からのログデ
ータが収集され、コンテンツ売り上げ状況を管理するこ
とが可能となる。さらに、ログデータ中の売り上げ配分
情報に基づいて、コンテンツ売り上げをコンテンツプロ
バイダ等の売り上げ利益取得権利者に対して正確な配分
が可能となる。
【０３３５】また、本実施例では、各エンティテイ間に
おいて通信されるデータに相互認証時に生成したセッシ
ョン鍵Ｋｓｅｓを改竄チェック値（ＩＣＶ）の生成鍵と
して用い、送信データにＩＣＶを付加して通信する構成
としたので、通信データの安全性がさらに高まることに
なる。
【０３３６】なお、上述した実施例では、ユーザ機器と
ショップサーバ間の相互認証処理、署名生成、署名検証
処理のいずれも実行する構成として説明したが、いずれ
かのみの処理、すなわち、相互認証のみ、あるいは署名
生成、署名検証処理のみを実行する構成として、いずれ
かにおいて有効期限内の公開鍵証明書の利用を必須とす
る構成としてもよい。
【０３３７】［４．属性データを記録した公開鍵証明書
または属性証明書利用構成］次に、属性データを記録し
た公開鍵証明書または属性証明書の利用構成について説
明する。例えば上述したコンテンツ配信構成において、
悪意のショップ運営者がユーザ機器になりすましてコン
テンツの架空取り引きを実行したり、あるいはコンテン
ツプロバイダとショップ間における架空コンテンツ取り
引きを行なう可能性がある。また、正当な取り引きを実
行しようとするユーザ機器がショップサーバであると信
じて通信を開始し、ショップサーバ相手のコンテンツ購
入要求を実行して、例えばクレジット口座番号の送信処
理を実行するような場合、相手がショップサーバになり
すました不正なサーバであるような場合は、ユーザ機器
からクレジット口座番号を不正に取得する等の処理が実
行されるおそれがある。さらに、ユーザ機器がショップ
になりすまして、他のユーザ機器に対してコンテンツの
架空販売を行なうなどの処理を行なう可能性も否定でき
ない。このような事態が発生すると、システム運営者は
正確なコンテンツ配信実体を把握することが困難とな
る。
【０３３８】このような正規なコンテンツ配信ルート以
外の架空取引等を防止する構成として、以下、属性デー
タを記録した公開鍵証明書または属性証明書利用構成を
説明する。
【０３３９】属性データとは、ユーザ機器（ＤＥＶＩＣ
Ｅ）、ショップ（ＳＨＯＰ）、コンテンツプロバイダ
（ＣＰ）、サービス運営者（ＳＨ）、公開鍵証明書、属
性証明書の発行審査を行なう登録局等、コンテンツ配信
システムを構成するエンティテイの種別を識別するデー
タである。
【０３４０】属性データの構成例として、属性データの
内容を示すテーブルを図６６に示す。図６６に示すよう
に、異なるコードが各エンティテイに割り当てられる。
例えば、ユーザ機器あるいはショップ等から公開鍵証明
書、属性証明書の発行要求を受けつけ、審査を行なう登
録局には「００００」、コンテンツ配信システム上で流
通するコンテンツに対するライセンスを徴収するシステ
ムホルダとしてのサービス運営者には「０００１」が属
性コードとして割り振られる。上述した例では、サービ
ス運営者は鍵かけかえ処理を実行するユーザ機器認証サ
ーバを管理するエンティテイであったり、また、ログ情
報を収集するログ情報収集サーバを管理するエンティテ
イである。
【０３４１】さらに、ユーザ機器に対してコンテンツを
販売するショップとしてのコンテンツ販売者には、「０
００２」、ショップ（コンテンツ販売者）からの要求に
応じてコンテンツをユーザに配信する配信サーバの運営
エンティテイであるコンテンツ配信者には、「０００
３」、コンテンツを購入し利用するユーザ機器には「０
００４」のコードが割り当てられる。この他にもコンテ
ンツ配信に係わるエンティテイに対して、その種類に応
じて異なるコードが割り当てられる。なお、ショップに
必ずしも１つのコードを割り当てる構成に限らず、役
割、機能の異なるショップがある場合には、異なるコー
ドを割り当てて、それぞれを区別可能にしてもよいし、
またユーザ機器にも、何らかのカテゴリに応じて異なる
属性コードを割り当てる構成としてもよい。
【０３４２】上述した属性情報は、公開鍵証明書に含め
る構成と、公開鍵証明書とは異なる属性証明書を発行
し、属性証明書によって属性を識別する構成とがある。
属性情報を持つ公開鍵証明書の構成例を図６７に示す。
【０３４３】図６７に示す公開鍵証明書は、証明書のバ
ージョン番号、公開鍵証明書発行局（ＣＡ）が証明書利
用者に対し割り付ける証明書の通し番号、電子署名に用
いたアルゴリズムおよびパラメータ、発行局の名前、証
明書の有効期限、証明書利用者の名前（ｅｘ．ユーザ機
器ＩＤ）、証明書利用者の公開鍵、さらに、上述した
［００００］，［０００１］…［ｎｎｎｎ］等の属性情
報、さらに電子署名を含む。証明書の通し番号は、例え
ば発行年（４バイト）、月（２バイト）、日（２バイ
ト）、シリアル番号（８バイト）の合計１６バイトとす
る。利用者名は、登録局の定める識別可能な名前、ある
いは乱数、通し番号を用いてもよい。あるいは上位バイ
トをカテゴリとし、下位バイトを通し番号とする構成と
してもよい。
【０３４４】電子署名は、証明書のバージョン番号、公
開鍵証明書発行局（ＣＡ）が証明書利用者に対し割り付
ける証明書の通し番号、電子署名に用いたアルゴリズム
およびパラメータ、発行局の名前、証明書の有効期限、
証明書利用者の名前、証明書利用者の公開鍵、並びに属
性データ全体に対しハッシュ関数を適用してハッシュ値
を生成し、そのハッシュ値に対して発行局の秘密鍵を用
いて生成したデータである。
【０３４５】公開鍵証明書発行局（ＣＡ）は、図６７に
示す公開鍵証明書を発行するとともに、有効期限が切れ
た公開鍵証明書を更新し、不正を行った利用者の排斥を
行うための不正者リストの作成、管理、配布（これをリ
ボケーション：Revocationと呼ぶ）を行う。
【０３４６】一方、この公開鍵証明書を利用する際に
は、利用者は自己が保持する発行局の公開鍵ＫｐＣＡを
用い、当該公開鍵証明書の電子署名を検証し、電子署名
の検証に成功した後に公開鍵証明書から公開鍵を取り出
し、当該公開鍵を利用する。従って、公開鍵証明書を利
用する全ての利用者は、共通の公開鍵証明書発行局の公
開鍵を保持している必要がある。
【０３４７】次に図６８に属性情報を持たない公開鍵証
明書と、属性証明書のデータ構成を示す。（Ａ）は属性
情報を持たない公開鍵証明書であり、図６７に示す公開
鍵証明書から属性情報を取り除いたデータ構成であり、
公開鍵証明書発行局が発行する。（Ｂ）は属性証明書で
ある。属性証明書は、属性証明書発行局（ＡＡ：Attrib
ute Authority）が発行する。
【０３４８】図６８に示す属性証明書は、証明書のバー
ジョン番号、属性証明書発行局（ＡＡ）が発行する属性
証明書に対応する公開鍵証明書の通し番号、これは対応
公開鍵証明書の証明書の通し番号と同一であり、両証明
書を関連づけるリンクデータとしての機能を持つ。属性
証明書によって通信相手の属性を確認しようとするエン
ティテイは、公開鍵証明書とリンクする属性証明書を、
公開鍵証明書および属性証明書に共通に格納された公開
鍵証明書通し番号に基づいて確認し、公開鍵証明書と同
一の公開鍵証明書通し番号を格納した属性証明書から属
性情報を取得することができる。通し番号は、例えば発
行年（４バイト）、月（２バイト）、日（２バイト）、
シリアル番号（８バイト）の合計１６バイトとする。さ
らに、電子署名に用いたアルゴリズムおよびパラメー
タ、属性証明書発行局の名前、証明書の有効期限、証明
書利用者の名前（ｅｘ．ユーザ機器ＩＤ）、これは、対
応する公開鍵証明書の利用者名と同一であり、登録局の
定める識別可能な名前、あるいは乱数、通し番号、ある
いは上位バイトをカテゴリとし、下位バイトを通し番号
としたデータ構成である。さらに、上述した［０００
０］，［０００１］…［ｎｎｎｎ］等の属性情報、属性
証明書発行局（ＡＡ）の電子署名を含む。
【０３４９】電子署名は、証明書のバージョン番号、公
開鍵証明書の通し番号、電子署名に用いたアルゴリズム
およびパラメータ、発行局の名前、証明書の有効期限、
証明書利用者の名前、並びに属性データ全体に対しハッ
シュ関数を適用してハッシュ値を生成し、そのハッシュ
値に対して属性証明書発行局の秘密鍵を用いて生成した
データである。
【０３５０】属性証明書発行局（ＡＡ）は、図６８
（Ｂ）に示す属性証明書を発行するとともに、有効期限
が切れた属性証明書を更新し、不正を行った利用者の排
斥を行うための不正者リストの作成、管理、配布（これ
をリボケーション：Revocationと呼ぶ）を行う。
【０３５１】図６９にコンテンツ取り引きに参加するユ
ーザ機器、ショップサーバがそれぞれ使用する公開鍵証
明書を新規に発行する手続きを説明する図を示す。な
お、ここでショップサーバ１０１０、ユーザ機器１０２
０は、前述の図１他で説明したと同様の構成を持つ。サ
ービス運営体１０３０は、コンテンツ配信全体を管理す
るシステムホルダ（ＳＨ）であり、前述したコンテンツ
鍵のかけかえ処理、あるいはユーザ機器のコンテンツ購
入により生成されるログを収集する等の手法により、コ
ンテンツの流通状況を把握する。ここでは、さらに、シ
ョップサーバ１０１０、ユーザ機器１０２０他の公開鍵
証明書および属性証明書の発行要求の受付、審査を実行
する登録局（ＲＡ：Registration Authority）としての
機能も兼ね備える。なお、本例ではサービス運営体１０
３０がシステムホルダ（ＳＨ）としての機能と、登録局
（ＲＡ）としての機能を持つ構成であるが、これらは別
々の独立したエンティテイとして構成してもよい。
【０３５２】図６９では、ユーザ機器１０２０における
公開鍵証明書の新規発行手続きをＡ１〜Ａ８で示し、シ
ョップサーバ１０１０の公開鍵証明書の新規発行手続き
をＢ１〜Ｂ７で示している。まず、ユーザ機器１０２０
における公開鍵証明書の新規発行手続きについて説明す
る。
【０３５３】（Ａ１）相互認証 まず、ユーザ機器１０２０は、サービス運営体１０３０
との間で相互認証を実行する。ただし、この時点でユー
ザ機器１０２０は、公開鍵証明書を保有していないの
で、公開鍵証明書を用いた相互認証を実行することはで
きず、先に図１２を用いて説明した対称鍵暗号方式、す
なわち、共有秘密鍵、識別子（ＩＤ）を用いた相互認証
処理を実行（詳細は図１２に関する説明を参照）する。
【０３５４】（Ａ２）公開鍵、秘密鍵ペア生成 （Ａ３）公開鍵証明書発行要求 （Ａ４）審査＆公開鍵証明書発行要求 （Ａ５）公開鍵証明書発行要求 相互認証が成立すると、ユーザ機器１０２０は、自己の
デバイス内の暗号処理部において、新規に登録する公開
鍵と秘密鍵のペアを生成し、生成した公開鍵をサービス
運営体１０３０に対して、証明書発行要求とともに送信
する。公開鍵証明書発行要求を受信したサービス運営体
１０３０は、発行要求を審査し、公開鍵証明書を発行す
るエンティテイとしての要件を満足している場合に、証
明書発行要求を公開鍵証明書発行局（ＣＡ）１０４０に
対して送信する。なお、ここで発行する公開鍵証明書が
図６８（Ａ）に示す属性情報を持つ公開鍵証明書である
場合は、サービス運営体１０３０は、証明書発行要求を
送信してきたエンティテイの属性をＩＤに基づいて判定
する。
【０３５５】コンテンツ配信に参加するユーザ機器に
は、予めユーザ機器識別子（ＩＤ）および秘密情報とし
ての秘密鍵が格納され、これらユーザ機器ＩＤ、秘密鍵
はサービス運営体１０３０によって管理された構成であ
り、サービス運営体１０３０は、ユーザ機器から送信さ
れるＩＤに基づき秘密情報格納データベースを検索し、
予め登録済みのユーザ機器ＩＤであることを確認した
後、秘密鍵を取り出し、この鍵を用いてユーザ機器と図
１２に基づく相互認証を行ない、相互認証に成功した場
合にのみコンテンツ配信に参加可能なユーザ機器である
ことを確認する。
【０３５６】（Ａ６）公開鍵証明書発行 （Ａ７）公開鍵証明書送信 （Ａ８）公開鍵証明書送信 サービス運営体１０３０からの公開鍵証明書発行要求を
受信した公開鍵証明書発行局１０４０は、ユーザ機器の
公開鍵を格納し、公開鍵証明書発行局１０４０の電子署
名を持つ公開鍵証明書（図６７または図６８（Ａ））を
発行し、サービス運営体１０３０に送信する。サービス
運営体１０３０は、公開鍵証明書発行局１０４０から受
信した公開鍵証明書をユーザ機器１０２０に対して送信
する。ユーザ機器は、受信した公開鍵証明書と先ほど
（Ａ２）で生成しておいた秘密鍵を自デバイス内に格納
し、コンテンツ取り引きの際の相互認証、データ暗号
化、復号処理等に使用可能となる。
【０３５７】一方、ショップサーバ１０１０の公開鍵証
明書の発行手続きは、基本的にユーザ機器における証明
書発行手続きと同様であるが、ショップサーバは、コン
テンツの販売を手がけるエンティテイとしてサービス運
営体１０３０に認可してもらう手続きが必要となる。従
って、ショップサーバ１０１０は、自己の公開鍵ととも
に、ライセンス申請（図６９、Ｂ２の手続き）を実行す
ることが必要となる。これは、例えばサービス運営体１
０３０が定めるポリシーに従ったコンテンツ販売を実行
することをショップサーバ１０１０が受諾する処理とし
て実行されるものである。サービス運営体１０３０は、
ショップサーバ１０１０がサービス運営体１０３０が定
めるポリシーに従ったコンテンツ販売を実行可能であ
り、ショップサーバ１０１０がポリシーを遵守すること
を受諾した場合には、ショップに対する公開鍵証明書の
発行手続きを進める。公開鍵証明書の発行手続き処理
は、上述したユーザ機器の場合と同様である。
【０３５８】次に、公開鍵証明書の更新処理について図
７０を用いて説明する。公開鍵証明書は図６７，図６８
（Ａ）に示すように有効期限が定められており、公開鍵
証明書を使用するエンティテイは有効期限のすぎた証明
書は使用できないので、有効期限内に更新処理を実行
し、新たな有効期限の設定された公開鍵証明書の発行手
続きを行なうことが必要となる。
【０３５９】図７０において、ユーザ機器１０２０にお
ける公開鍵証明書の更新手続きをＡ１〜Ａ８で示し、シ
ョップサーバ１０１０の公開鍵証明書の更新手続きをＢ
１〜Ｂ７で示している。まず、ユーザ機器１０２０にお
ける公開鍵証明書の更新手続きについて説明する。
【０３６０】（Ａ１）相互認証 まず、ユーザ機器１０２０は、サービス運営体１０３０
との間で相互認証を実行する。この時点でユーザ機器１
０２０は、現在有効な公開鍵証明書を保有しているの
で、公開鍵証明書を用いた相互認証を実行する。これは
先に図１３を用いて説明した相互認証処理である。な
お、すでに手持ちの公開鍵証明書の有効期限がすぎてい
る場合は、新規発行手続きと同様先に図１２を用いて説
明した共有秘密鍵、識別子（ＩＤ）を用いた相互認証処
理を実行するようにしてもよい。
【０３６１】（Ａ２）新規公開鍵、秘密鍵ペア生成 （Ａ３）公開鍵証明書更新要求 （Ａ４）審査＆公開鍵証明書更新要求 （Ａ５）公開鍵証明書更新要求 相互認証が成立すると、ユーザ機器１０２０は、自己の
デバイス内の暗号処理部において、更新用の新規公開鍵
と秘密鍵のペアを生成し、生成した公開鍵をサービス運
営体１０３０に対して、証明書更新要求とともに送信す
る。公開鍵証明書更新要求を受信したサービス運営体１
０３０は、更新要求を審査し、更新要件を満足している
場合に、証明書更新要求を公開鍵証明書発行局（ＣＡ）
１０４０に対して送信する。なお、ここで発行する公開
鍵証明書が図６８（Ａ）に示す属性情報を持つ公開鍵証
明書である場合は、サービス運営体１０３０は、証明書
発行要求を送信してきたエンティテイの属性をＩＤに基
づいて判定する。
【０３６２】（Ａ６）公開鍵証明書更新 （Ａ７）公開鍵証明書送信 （Ａ８）公開鍵証明書送信 サービス運営体１０３０からの公開鍵証明書更新要求を
受信した公開鍵証明書発行局１０４０は、ユーザ機器の
新規公開鍵を格納し、公開鍵証明書発行局１０４０の電
子署名を持つ公開鍵証明書（図６７または図６８
（Ａ））を発行し、サービス運営体１０３０に送信す
る。サービス運営体１０３０は、公開鍵証明書発行局１
０４０から受信した公開鍵証明書をユーザ機器１０２０
に対して送信する。ユーザ機器は、受信した公開鍵証明
書と先ほど（Ａ２）で生成しておいた秘密鍵を自デバイ
ス内に格納し、コンテンツ取り引きの際の相互認証、デ
ータ暗号化、復号処理等に使用可能となる。
【０３６３】一方、ショップサーバ１０１０の公開鍵証
明書の更新手続きは、基本的にユーザ機器における証明
書更新手続きと同様であるが、前述のライセンス申請の
更新（図７０、Ｂ２の手続き）を実行することが必要と
なる。サービス運営体１０３０が、ショップサーバ１０
１０のライセンス更新を認めた場合には、ショップに対
する公開鍵証明書の更新手続きを進める。公開鍵証明書
の更新手続き処理は、上述したユーザ機器の場合と同様
である。
【０３６４】次に、図７１を用いて属性証明書の新規発
行手続きについて説明する。属性証明書は、図６８
（Ｂ）に示す証明書であり、図６８（Ａ）に示す公開鍵
証明書の発行の後、属性証明書が発行される。図７１で
は、ユーザ機器１０２０における属性証明書の新規発行
手続きをＡ１〜Ａ７で示し、ショップサーバ１０１０の
公開鍵証明書の新規発行手続きをＢ１〜Ｂ７で示してい
る。まず、ユーザ機器１０２０における公開鍵証明書の
新規発行手続きについて説明する。
【０３６５】（Ａ１）相互認証 まず、ユーザ機器１０２０は、サービス運営体１０３０
との間で相互認証を実行する。この時点でユーザ機器１
０２０は、すでに公開鍵証明書発行局公開鍵証明書を保
有しているので、公開鍵証明書を用いた相互認証を実行
する。
【０３６６】（Ａ２）属性証明書発行要求 （Ａ３）審査＆属性証明書発行要求 （Ａ４）属性証明書発行要求 相互認証が成立すると、ユーザ機器１０２０は、サービ
ス運営体１０３０に対して、属性証明書発行要求を送信
する。属性証明書発行要求を受信したサービス運営体１
０３０は、発行要求を審査し、属性証明書を発行するエ
ンティテイとしての要件を満足している場合に、証明書
発行要求を属性証明書発行局（ＡＡ）１０５０に対して
送信する。なお、ここでサービス運営体１０３０は、証
明書発行要求を送信してきたエンティテイの属性をＩＤ
に基づいて判定する。前述したように、コンテンツ配信
に参画するユーザ機器には、予めユーザ機器識別子（Ｉ
Ｄ）が格納され、これらユーザ機器ＩＤはサービス運営
体１０３０によって管理された構成であり、サービス運
営体１０３０は、ユーザ機器から送信されるＩＤと、予
め登録済みのユーザ機器ＩＤと比較参照することによ
り、コンテンツ配信に参画可能なユーザ機器であること
を確認する。
【０３６７】（Ａ５）属性証明書発行 （Ａ６）属性証明書送信 （Ａ７）属性証明書送信 サービス運営体１０３０からの属性証明書発行要求を受
信した属性証明書発行局１０５０は、ユーザ機器の属性
情報を格納し、属性証明書発行局１０５０の電子署名を
持つ属性証明書（図６８（Ｂ））を発行し、サービス運
営体１０３０に送信する。サービス運営体１０３０は、
属性証明書発行局１０５０から受信した属性証明書をユ
ーザ機器１０２０に対して送信する。ユーザ機器は、受
信した属性証明書を自デバイス内に格納し、コンテンツ
取り引きの際の属性確認処理に使用する。
【０３６８】一方、ショップサーバ１０１０の属性証明
書の発行手続き（Ｂ１〜Ｂ７）は、基本的にユーザ機器
における証明書発行手続きと同様である。また、属性証
明書の更新手続きも新規発行手続きと同様の手続きとな
る。
【０３６９】次に、属性証明書による属性確認処理、ま
たは公開鍵証明書に格納された属性情報による属性確認
処理を伴うコンテンツ取り引きについて説明する。
【０３７０】図７２に相互認証時に併せて属性確認処理
を実行する処理構成を示す。図７２の構成は、先に説明
した図１のシステム構成と同様である。すなわち、コン
テンツの販売を実行するショップサーバ１０１０、コン
テンツ購入を実行するユーザ機器１０２０、ユーザ機器
認証サーバ１０３０を構成要素とする。ここで、ユーザ
機器認証サーバ１０３０は、前述したサービス運営体の
管理下にある。図７２の番号（１）から（２０）の順に
処理が進行する。各番号順に処理の詳細を説明する。
【０３７１】（１）相互認証および属性確認処理 コンテンツをショップサーバ１０１０から購入しようと
するユーザ機器１０２０は、ショップサーバとの間で相
互認証処理を行なう。データ送受信を実行する２つの手
段間では、相互に相手が正しいデータ通信者であるか否
かを確認して、その後に必要なデータ転送を行なうこと
が行われる。相手が正しいデータ通信者であるか否かの
確認処理が相互認証処理である。相互認証処理時にセッ
ション鍵の生成を実行して、生成したセッション鍵を共
有鍵として暗号化処理を実行してデータ送信を行なう構
成が１つの好ましいデータ転送方式である。公開鍵方式
の相互認証処理は、公開鍵証明書の発行局の署名検証の
後、相手型の公開鍵を取り出して実行される。詳細は前
述の図１３に関する説明を参照されたい。
【０３７２】さらに、本実施例においては、属性確認処
理を実行する。ショップサーバ１０１０は、通信相手の
公開鍵証明書に属性データが格納されている場合は、そ
の属性がユーザ機器であることを示すデータであること
を確認する。公開鍵証明書に属性データが格納されてい
ない場合は、属性証明書を用いて属性の確認を行なう。
属性証明書には、属性証明書発行局の秘密鍵を用いて署
名がなされているので、属性証明書発行局の公開鍵：Ｋ
ｐＡＡを用いて署名検証を実行し、正当な証明書である
ことを確認し、属性証明書の「通し番号」および／また
は「利用者（ＩＤ）」が、公開鍵証明書内の「通し番
号」および／または「利用者（ＩＤ）」と一致している
か確認した後、証明書内の属性情報を確認する。
【０３７３】一方、ユーザ機器１０２０は、通信相手の
公開鍵証明書に属性データが格納されている場合は、そ
の属性がショップであることを示すデータであることを
確認する。公開鍵証明書に属性データが格納されていな
い場合は、属性証明書について、属性証明書発行局の公
開鍵：ＫｐＡＡを用いて署名検証を実行し、正当な証明
書であることを確認し、属性証明書の「通し番号」およ
び／または「利用者（ＩＤ）」が、公開鍵証明書内の
「通し番号」および／または「利用者（ＩＤ）」と一致
しているか確認した後、証明書内の属性情報を確認す
る。
【０３７４】ショップサーバ１０１０は、コンテンツ購
入要求主体の公開鍵証明書または属性証明書の属性がユ
ーザ機器であることを確認し、ユーザ機器１０２０は、
コンテンツ購入要求先の公開鍵証明書または属性証明書
の属性がショップであることを確認して、その後の処理
に移行する。
【０３７５】属性確認処理のフローを図７３に示す。図
７３（Ａ）は、公開鍵証明書に属性データが格納されて
いる場合の公開鍵証明書を用いた属性確認処理であり、
（Ｂ）は、属性証明書を用いた属性確認処理である。
【０３７６】図７３（Ａ）のフローから説明する。ま
ず、ステップＳ２１０１において、公開鍵証明書を用い
た相互認証処理を実行（図１３参照）し、認証が成立し
たことを条件として（Ｓ２１０２の判定Ｙｅｓ）、相手
の公開鍵証明書から属性情報を取り出す。属性情報が正
当である場合に（Ｓ２１０４の判定Ｙｅｓ）、相互認
証、属性確認が成功したものと判定（Ｓ２１０５）し、
その後の処理に移行する。なお、属性が正当であると
は、例えばユーザ機器がショップサーバにアクセスしコ
ンテンツ購入要求を実行しようとしている場合は、属性
がショップであれば正当であると判定し、ショップ以外
の例えば他のユーザ機器を示す属性コードであれば正当
でないと判定する。この判定処理は、例えばショップサ
ーバに対してコンテンツ購入要求を実行する場合は、コ
ンテンツ購入要求処理シーケンス（ｅｘ．実行プログラ
ム）中に属性コード比較処理を実行するステップを含ま
せ、予めショップに対して付与されたコード［０００
２］と、通信相手（エンティテイ）の公開鍵証明書、ま
たは属性証明書から取得した属性コードとを比較し、一
致すれば正当と判定し、不一致であれば正当でないと判
定する。あるいは、通信相手（エンティテイ）の公開鍵
証明書、または属性証明書から取得した属性コードをデ
ィスプレイに表示するなどして、通信相手として想定し
たエンティテイに設定された属性コードとを比較してユ
ーザ自身が判定する構成としてもよい。ステップＳ２１
０２，Ｓ２１０４で判定がＮｏの場合は、相互認証、属
性確認が失敗であると判定（Ｓ２１０６）し、その後の
処理を中止する。
【０３７７】属性正当性の判定は、上述のように、ショ
ップに対する処理実行プログラムでは、予めショップに
対して付与されたコード［０００２］と、通信相手（エ
ンティテイ）の公開鍵証明書、または属性証明書から取
得した属性コードとを比較する処理としてステップが実
行され、また、ユーザ機器がユーザ機器認証サーバに対
して実行する例えば鍵かけかえ要求処理実行シーケンス
（ｅｘ．プログラム）では、予めユーザ機器認証サーバ
に対して付与されたコード［０００１］と、通信相手
（エンティテイ）の公開鍵証明書、または属性証明書か
ら取得した属性コードとを比較する処理としてステップ
が実行される。その他、ショップとユーザ機器認証サー
バ間における通信処理においても、それぞれのエンティ
テイで通信相手を特定して実行する処理シーケンス（ｅ
ｘ．プログラム）において、予め正当な通信相手として
設定された属性コードと、通信相手（エンティテイ）の
公開鍵証明書、または属性証明書から取得した属性コー
ドとを比較する処理としてステップが実行される。
【０３７８】次に、図７３（Ｂ）の属性証明書を適用し
たフローについて説明する。まず、ステップＳ２２０１
において、公開鍵証明書を用いた相互認証処理を実行
（図１３参照）し、認証が成立したことを条件として
（Ｓ２２０２の判定Ｙｅｓ）、相手の属性証明書の検証
を属性証明書発行局の公開鍵を用いて実行（Ｓ２２０
３）し、検証が成功し、公開鍵証明書とリンクする属性
証明書を、公開鍵証明書および属性証明書に共通に格納
された公開鍵証明書通し番号に基づいて確認した（Ｓ２
２０４の判定Ｙｅｓ）ことを条件として、公開鍵証明書
と同一の公開鍵証明書通し番号を格納した属性証明書か
ら属性情報を取り出す（Ｓ２２０５）。属性情報が正当
である場合に（Ｓ２２０６の判定Ｙｅｓ）、相互認証、
属性確認が成功したものと判定（Ｓ２２０７）し、その
後の処理に移行する。ステップＳ２２０２，Ｓ２２０
４，Ｓ２２０６で判定がＮｏの場合は、相互認証、属性
確認が失敗であると判定（Ｓ２２０８）され、その後の
処理は中止される。
【０３７９】（２）トランザクションＩＤ、購入要求デ
ータ生成、および （３）購入要求データ送信 上述のショップサーバ１０１０とユーザ機器１０２０間
の相互認証および属性確認が成功すると、ユーザ機器１
０２０は、コンテンツの購入要求データを生成する。購
入要求データの構成は、先に説明した図１４（ａ）に示
す構成であり、コンテンツ購入の要求先であるショップ
サーバ１０１０の識別子であるショップＩＤ、取り引き
の識別子として、ユーザ機器１０２０の暗号処理手段が
乱数に基づいて生成するトランザクションＩＤ、さら
に、ユーザ機器が購入を希望するコンテンツの識別子と
してのコンテンツＩＤの各データを有し、これらのデー
タに対するユーザ機器の電子署名が付加されている。
【０３８０】（４）受信データ検証 図１４（ａ）に示す購入要求データをユーザ機器１０２
０から受信したショップサーバは、受信データの検証処
理を実行する。検証処理は、先に、図１５を用いて説明
したように、ユーザ機器の公開鍵証明書Ｃｅｒｔ＿ＤＥ
Ｖの検証の後、公開鍵証明書からユーザ機器の公開鍵：
ＫｐＤＥＶを取り出して、ユーザ機器の公開鍵：Ｋｐ＿
ＤＥＶを用いて購入要求データのユーザ機器署名の検証
を行なうものである。
【０３８１】検証がＯＫ、すなわち購入要求データの改
竄がないと判定されると、受信データが正当なコンテン
ツ購入要求データであると判定される。検証が不成立の
場合は、購入要求データが改竄ありと判定され、その購
入要求データに対する処理が中止される。
【０３８２】（５）暗号化コンテンツおよび暗号化コン
テンツ鍵データ１（ショップ）送信 ショップサーバ１０１０において、購入要求データの検
証が完了し、データ改竄のない正当なコンテンツ購入要
求であると判定すると、ショップサーバ１０１０は、暗
号化コンテンツおよび暗号化コンテンツ鍵データ１（シ
ョップ）をユーザ機器に送信する。これらは、いずれも
コンテンツデータベースに格納されたデータであり、コ
ンテンツをコンテンツキーで暗号化した暗号化コンテン
ツ：Ｋｃ（content）と、コンテンツキー：Ｋｃをユー
ザ機器認証サーバ（ＤＡＳ）１０３０の公開鍵で暗号化
した暗号化コンテンツ鍵データ：ＫｐＤＡＳ（Ｋｃ）で
ある。
【０３８３】暗号化コンテンツ鍵データ１（ショップ）
は、先に説明した図１４（ｂ）に示す構成である。すな
わち、コンテンツ購入の要求元であるユーザ機器１０２
０の識別子であるユーザ機器ＩＤ、購入要求データ（図
１４（ａ）のユーザ機器公開鍵証明書を除いたデー
タ）、コンテンツ取り引きに伴いショップサーバ１０１
０が生成したショップ処理Ｎｏ．、暗号化コンテンツ鍵
データ：ＫｐＤＡＳ（Ｋｃ）を有し、これらのデータに
対するショップサーバ１０１０の電子署名が付加されて
いる。さらに、暗号化コンテンツ鍵データ１（ショッ
プ）には、ショップサーバ１０１０の公開鍵証明書が添
付され、ユーザ機器１０２０に送付される。なお、ショ
ップサーバ公開鍵証明書が既に前述の相互認証処理、あ
るいはその以前の処理において、ユーザ機器側に送付済
みの場合は、必ずしも改めて送付する必要はない。
【０３８４】（６）受信データ検証 ショップサーバ１０１０から暗号化コンテンツ：Ｋｃ
（content）と、図１４（ｂ）に示す暗号化コンテンツ
鍵データ１（ショップ）を受信したユーザ機器１０２０
は、暗号化コンテンツ鍵データ１（ショップ）の検証処
理を実行する。この検証処理は、先に説明した図１５の
処理フローと同様の処理であり、ユーザ機器１０２０
は、まずショップサーバ１０１０から受領したショップ
サーバの公開鍵証明書の検証を発行局（ＣＡ）の公開鍵
ＫｐＣＡを用いて実行し、次に公開鍵証明書から取り出
したショップサーバの公開鍵ＫｐＳＨＯＰを用いて図１
４（ｂ）に示す暗号化コンテンツ鍵データ１のショップ
署名の検証を実行する。
【０３８５】（７）相互認証および属性確認処理 ユーザ機器１０２０が、ショップサーバ１０１０から暗
号化コンテンツ：Ｋｃ（content）と暗号化コンテンツ
鍵データ１（ショップ）を受信し、暗号化コンテンツ鍵
データ１（ショップ）の検証を終えると、ユーザ機器１
０２０は、ユーザ機器認証サーバ１０３０にアクセス
し、ユーザ機器１０２０と、ユーザ機器認証サーバ１０
３０間において相互認証処理および属性確認処理を実行
する。この処理は、前述のショップサーバ１０１０とユ
ーザ機器１０２０間の相互認証処理および属性確認処理
と同様の手続きで実行される。
【０３８６】（８）暗号化コンテンツ鍵データ（ユーザ
機器）および暗号化コンテンツ鍵かけかえ要求送信 ユーザ機器１０２０とユーザ機器認証サーバ１０３０と
の間の相互認証および属性確認が成立すると、ユーザ機
器１０２０は、ユーザ機器認証サーバ１０３０に対し
て、先にショップサーバ１０１０から受信した暗号化コ
ンテンツ鍵ＫｐＤＡＳ（Ｋｃ）と、暗号化コンテンツ鍵
かけかえ要求を送信する。暗号化コンテンツ鍵データ
（ユーザ機器）の構成は、先に説明した図１４（ｃ）に
示す構成である。すなわち、暗号化コンテンツ鍵かけか
え要求の要求先であるユーザ機器認証サーバ１０３０の
識別子であるユーザ機器認証サーバＩＤ、ショップサー
バ１０１０から受領した暗号化コンテンツ鍵データ（図
１４（ｂ）のショップ公開鍵証明書を除いたデータ）、
を有し、これらのデータに対するユーザ機器１０２０の
電子署名が付加されている。さらに、暗号化コンテンツ
鍵データ（ユーザ機器）には、ショップサーバ１０１０
の公開鍵証明書と、ユーザ機器１０２０の公開鍵証明書
が添付され、ユーザ機器認証サーバ１０３０に送付され
る。なお、ユーザ機器認証サーバ１０３０がユーザ機器
公開鍵証明書、ショップサーバ公開鍵証明書をすでに保
有している場合は、必ずしも改めて送付する必要はな
い。
【０３８７】（９）受信データ検証 ユーザ機器１０２０から暗号化コンテンツ鍵データ（ユ
ーザ機器）および暗号化コンテンツ鍵かけかえ要求（図
１４（ｃ））を受信したユーザ機器認証サーバ１０３０
は、暗号化コンテンツ鍵かけかえ要求の検証処理を実行
する。この検証処理は、先に説明した図１５の処理フロ
ーと同様の処理であり、ユーザ機器認証サーバ１０３０
は、まずユーザ機器１０２０から受領したユーザ機器の
公開鍵証明書の検証を発行局（ＣＡ）の公開鍵ＫｐＣＡ
を用いて実行し、次に公開鍵証明書から取り出したユー
ザ機器の公開鍵ＫｐＤＥＶを用いて図１４（ｃ）に示す
暗号化コンテンツ鍵データ（ユーザ機器）の電子署名の
検証を実行する。さらに、ショップサーバの公開鍵証明
書の検証を発行局（ＣＡ）の公開鍵ＫｐＣＡを用いて実
行し、次に公開鍵証明書から取り出したショップサーバ
の公開鍵ＫｐＳＨＯＰを用いて図１４（ｃ）に示す暗号
化コンテンツ鍵データ（ユーザ機器）に含まれる（５）
暗号化コンテンツ鍵データ１のショップ署名の検証を実
行する。また、ユーザ機器の送信した電文が図１４
（ｃ）に示すフォーマット中に入っている場合は、その
電文の検証を必要に応じて実行する。
【０３８８】（１０）暗号化コンテンツ鍵かけかえ処理 ユーザ機器認証サーバ１０３０において、ユーザ機器１
０２０から受信した暗号化コンテンツ鍵データ（ユーザ
機器）および暗号化コンテンツ鍵かけかえ要求の検証が
終了し、正当な鍵かけかえ要求であると判定すると、ユ
ーザ機器認証サーバ１０３０は、暗号化コンテンツ鍵デ
ータ（ユーザ機器）に含まれる暗号化コンテンツ鍵、す
なわち、コンテンツ鍵：Ｋｃをユーザ機器認証サーバ
（ＤＡＳ）１０３０の公開鍵ＫｐＤＡＳで暗号化したデ
ータ：ＫｐＤＡＳ（Ｋｃ）をユーザ機器認証サーバ１０
３０の秘密鍵ＫｓＤＡＳで復号してコンテンツ鍵Ｋｃを
取得し、さらにコンテンツ鍵Ｋｃをユーザ機器の公開
鍵：ＫｐＤＥＶで暗号化した暗号化コンテンツ鍵：Ｋｐ
ＤＥＶ（Ｋｃ）を生成する。すなわち、ＫｐＤＡＳ（Ｋ
ｃ）→Ｋｃ→ＫｐＤＥＶ（Ｋｃ）の鍵かけかえ処理を実
行する。
【０３８９】この処理は先に図１６を用いて説明したよ
うに、暗号化コンテンツ鍵データ（ユーザ機器）から、
ユーザ機器認証サーバ（ＤＡＳ）１０３０の公開鍵Ｋｐ
ＤＡＳで暗号化したコンテンツ鍵データ：ＫｐＤＡＳ
（Ｋｃ）を取り出し、次に、ユーザ機器認証サーバ１０
３０の秘密鍵ＫｓＤＡＳで復号してコンテンツ鍵Ｋｃを
取得し、次に、復号により取得したコンテンツ鍵Ｋｃを
ユーザ機器の公開鍵：ＫｐＤＥＶで再暗号化して暗号化
コンテンツ鍵：ＫｐＤＥＶ（Ｋｃ）を生成する処理であ
る。
【０３９０】（１１）相互認証および属性確認処理 ユーザ機器認証サーバ１０３０において、上述の暗号化
コンテンツ鍵の鍵かけかえ処理が完了すると、ユーザ機
器認証サーバ１０３０は、ショップサーバ１０１０にア
クセスし、ユーザ機器認証サーバ１０３０とショップサ
ーバ１０１０間において相互認証処理および属性確認処
理を実行する。この処理は、前述のショップサーバ１０
１０とユーザ機器１０２０間の相互認証処理および属性
確認処理と同様の手続きで実行される。
【０３９１】（１２）暗号化コンテンツデータ送信 ユーザ機器認証サーバ１０３０とショップサーバ１０１
０間の相互認証および属性確認処理が成立すると、ユー
ザ機器認証サーバ１０３０は、暗号化コンテンツ鍵デー
タ（ＤＡＳ）をショップサーバ１０１０に送信する。暗
号化コンテンツ鍵データ（ＤＡＳ）の構成は、先に説明
した図１７（ｄ）に示す構成である。コンテンツ購入の
要求先であるショップサーバ１０１０の識別子であるシ
ョップＩＤ、暗号化コンテンツ鍵データ（ユーザ機器）
（図１４（ｃ）のショップおよびユーザ機器公開鍵証明
書を除いたデータ）、さらに、前述の鍵かけかえ処理に
より、ユーザ機器認証サーバ１０３０が生成した暗号化
コンテンツ鍵データ：ＫｐＤＥＶ（Ｋｃ）を有し、これ
らのデータに対するユーザ機器認証サーバ１０３０の電
子署名が付加されている。さらに、暗号化コンテンツ鍵
データ（ＤＡＳ）には、ユーザ機器認証サーバ１０３０
と、ユーザ機器１０２０の公開鍵証明書が添付され、シ
ョップサーバ１０１０に送付される。なお、ショップサ
ーバが、これらの公開鍵証明書を既に保有済みである場
合は、必ずしも改めて送付する必要はない。
【０３９２】また、ユーザ機器認証サーバ１０３０が信
頼できる第三者機関であると認められる存在である場合
は、暗号化コンテンツ鍵データ（ＤＡＳ）は、図１７
（ｄ）に示すようにユーザ機器の生成した（８）暗号化
コンテンツ鍵データ（ユーザ機器）をそのまま含むデー
タ構成とすることなく、図１８（ｄ’）に示すように、
ユーザ機器ＩＤ、トランザクションＩＤ、コンテンツＩ
Ｄ、ショップ処理ＮＯ、ユーザデバイスの公開鍵で暗号
化したコンテンツ鍵ＫｐＤＥＶ（Ｋｃ）の各データを、
ユーザ機器認証サーバ１０３０が抽出して、これらに署
名を付加して暗号化コンテンツ鍵データ（ＤＡＳ）とし
てもよい。この場合は、（８）暗号化コンテンツ鍵デー
タ（ユーザ機器）の検証が不要となるので、添付する公
開鍵証明書は、ユーザ機器認証サーバ１０３０の公開鍵
証明書のみでよい。
【０３９３】（１３）受信データ検証 ユーザ機器認証サーバ１０３０から暗号化コンテンツ鍵
データ（ＤＡＳ）（図１７（ｄ））を受信したショップ
サーバ１０１０は、暗号化コンテンツ鍵データ（ＤＡ
Ｓ）の検証処理を実行する。この検証処理は、先に説明
した図１５の処理フローと同様の処理であり、ショップ
サーバ１０１０は、まずユーザ機器認証サーバ１０３０
から受領したユーザ機器認証サーバの公開鍵証明書の検
証を発行局（ＣＡ）の公開鍵ＫｐＣＡを用いて実行し、
次に公開鍵証明書から取り出したユーザ機器認証サーバ
１０３０の公開鍵ＫｐＤＡＳを用いて図１７（ｄ）に示
す暗号化コンテンツ鍵データ（ＤＡＳ）の電子署名の検
証を実行する。さらに、ユーザ機器の公開鍵証明書の検
証を発行局（ＣＡ）の公開鍵ＫｐＣＡを用いて実行し、
次に公開鍵証明書から取り出したユーザ機器の公開鍵Ｋ
ｐＤＥＶを用いて図１７（ｄ）に示す暗号化コンテンツ
鍵データ（ＤＡＳ）に含まれる（８）暗号化コンテンツ
鍵データ（ユーザ機器）のユーザ機器署名の検証を実行
する。また、ユーザ機器の送信した電文が図１４（ｃ）
に示すフォーマット中に入っている場合は、その電文の
検証を必要に応じて実行する。
【０３９４】なお、先に説明した図１８（ｄ’）の簡略
化した暗号化コンテンツ鍵データ（ＤＡＳ）をショップ
サーバ１０１０が受領した場合は、ショップサーバ１０
１０は、ユーザ機器認証サーバの公開鍵証明書の検証を
発行局（ＣＡ）の公開鍵ＫｐＣＡを用いて実行し、次に
公開鍵証明書から取り出したユーザ機器認証サーバ１０
３０の公開鍵ＫｐＤＡＳを用いて図１８（ｄ’）に示す
暗号化コンテンツ鍵データ（ＤＡＳ）の電子署名の検証
を実行するのみの処理となる。
【０３９５】（１４）相互認証および属性確認 （１５）暗号化コンテンツ鍵要求データ送信 次に、ユーザ機器１０２０は、暗号化コンテンツ鍵要求
データをショップサーバに対して送信する。なお、この
際、前の要求と異なるセッションで要求を実行する場合
は、再度相互認証および属性確認を実行して、相互認証
および属性確認が成立したことを条件として暗号化コン
テンツ鍵要求データがユーザ機器１０２０からショップ
サーバ１０１０に送信される。また、ユーザ機器の送信
した電文が図１４（ｃ）に示すフォーマット中に入って
いる場合は、その電文の検証を必要に応じて実行する。
【０３９６】暗号化コンテンツ鍵要求データの構成は図
１７（ｅ）に示す通りである。暗号化コンテンツ鍵要求
データは、コンテンツ購入の要求先であるショップサー
バ１０１０の識別子であるショップＩＤ、取り引きの識
別子として、ユーザ機器１０２０の暗号処理手段が乱数
に基づいて生成するトランザクションＩＤ、さらに、ユ
ーザ機器が購入を希望するコンテンツの識別子としての
コンテンツＩＤ、さらに、先にショップが生成し暗号化
コンテンツ鍵データ１（ショップ）としてユーザ機器１
０２０に送信してきたデータ（図１４（ｂ）参照）中に
含まれるショップ処理Ｎｏ．を有し、これらのデータに
対するユーザ機器の電子署名が付加されている。さら
に、暗号化コンテンツ鍵要求データには、ユーザ機器の
公開鍵証明書が添付され、ショップサーバ１０１０に送
付される。なお、公開鍵証明書が既にショップ側に保管
済みの場合は、必ずしも改めて送付する必要はない。
【０３９７】（１６）検証処理、および （１７）課金処理 暗号化コンテンツ鍵要求データをユーザ機器から受信し
たショップサーバ１０１０は、暗号化コンテンツ鍵要求
データの検証処理を実行する。これは、図１５を用いて
説明したと同様の処理である。データ検証が済むと、シ
ョップサーバ１０１０は、コンテンツの取り引きに関す
る課金処理を実行する。課金処理は、ユーザの取り引き
口座からコンテンツ料金を受領する処理である。受領し
たコンテンツ料金は、コンテンツの著作権者、ショッ
プ、ユーザ機器認証サーバ管理者など、様々な関係者に
配分される。
【０３９８】この課金処理に至るまでには、ユーザ機器
認証サーバ１０３０による暗号化コンテンツ鍵の鍵かけ
かえ処理プロセスが必須となっているので、ショップサ
ーバ１０１０は、ユーザ機器間とのみの処理では課金処
理が実行できない。また、ユーザ機器１０２０において
も暗号化コンテンツ鍵の復号ができないので、コンテン
ツの利用ができない。ユーザ機器認証サーバは、図６を
用いて説明したユーザ機器認証サーバ・ライセンス管理
データベースに、すべての鍵かけかえ処理を実行したコ
ンテンツ取り引き内容を記録しており、すべての課金対
象となるコンテンツ取り引きが把握可能となる。従っ
て、ショップ側単独でのコンテンツ取り引きは不可能と
なり、不正なコンテンツ販売が防止される。
【０３９９】（１８）暗号化コンテンツ鍵データ２（シ
ョップ）送信 ショップサーバ１０１０における課金処理が終了する
と、ショップサーバ１０１０は、暗号化コンテンツ鍵デ
ータ２（ショップ）をユーザ機器１０２０に送信する。
【０４００】暗号化コンテンツ鍵データ２（ショップ）
の構成は、先に説明した図１７（ｆ）に示す通りであ
る。暗号化コンテンツ鍵要求の要求元であるユーザ機器
１０２０の識別子であるユーザ機器ＩＤ、ユーザ機器認
証サーバ１０３０から受領した暗号化コンテンツ鍵デー
タ（ＤＡＳ）（図１７（ｄ）のユーザ機器、ユーザ機器
認証サーバ公開鍵証明書を除いたデータ）、を有し、こ
れらのデータに対するショップサーバ１０１０の電子署
名が付加されている。さらに、暗号化コンテンツ鍵デー
タ２（ショップ）には、ショップサーバ１０１０の公開
鍵証明書と、ユーザ機器認証サーバ１０３０の公開鍵証
明書が添付され、ユーザ機器１０２０に送付される。な
お、ユーザ機器１０２０がユーザ機器認証サーバ公開鍵
証明書、ショップサーバ公開鍵証明書をすでに保有して
いる場合は、必ずしも改めて送付する必要はない。
【０４０１】なお、ユーザ機器認証サーバ１０３０が信
頼できる第三者機関であると認められる存在であり、シ
ョップサーバ１０１０がユーザ機器認証サーバ１０３０
から受信する暗号化コンテンツ鍵データ（ＤＡＳ）が先
に説明した図１８（ｄ’）の簡略化した暗号化コンテン
ツ鍵データ（ＤＡＳ）である場合は、ショップサーバ１
０１０は、図１８（ｆ’）に示す暗号化コンテンツ鍵デ
ータ２（ショップ）をユーザ機器に送付する。すなわ
ち、図１８（ｄ’）に示す簡略化した暗号化コンテンツ
鍵データ（ＤＡＳ）にショップサーバの署名を付加した
データに、ショップサーバ１０１０の公開鍵証明書と、
ユーザ機器認証サーバ１０３０の公開鍵証明書が添付し
てユーザ機器１０２０に送付する。
【０４０２】（１９）受信データ検証 ショップサーバ１０１０から、暗号化コンテンツ鍵デー
タ２（ショップ）を受領したユーザ機器１０２０は、暗
号化コンテンツ鍵データ２（ショップ）の検証処理を実
行する。この検証処理は、先に説明した図１５の処理フ
ローと同様の処理であり、ユーザ機器１０２０は、まず
ショップサーバ１０１０から受領したショップサーバの
公開鍵証明書の検証を発行局（ＣＡ）の公開鍵ＫｐＣＡ
を用いて実行し、次に公開鍵証明書から取り出したショ
ップサーバ１０１０の公開鍵ＫｐＳＨＯＰを用いて図１
７（ｆ）に示す暗号化コンテンツ鍵データ２（ショッ
プ）の電子署名の検証を実行する。さらに、ユーザ機器
認証サーバ１０３０の公開鍵証明書の検証を発行局（Ｃ
Ａ）の公開鍵ＫｐＣＡを用いて実行し、次に公開鍵証明
書から取り出したユーザ機器認証サーバ１０３０の公開
鍵ＫｐＤＡＳを用いて図１７（ｆ）に示す暗号化コンテ
ンツ鍵データ２（ショップ）に含まれる（１２）暗号化
コンテンツ鍵データ（ＤＡＳ）の署名検証を実行する。
また、何らかの送信電文が図１７（ｆ）に示すフォーマ
ット中に入っている場合は、その電文の検証を必要に応
じて実行する。
【０４０３】（２０）保存処理 ショップサーバ１０１０から受信した暗号化コンテンツ
鍵データ２（ショップ）を検証したユーザ機器１０２０
は、暗号化コンテンツ鍵データ２（ショップ）に含まれ
る自己の公開鍵ＫｐＤＥＶで暗号化された暗号化コンテ
ンツ鍵：ＫｐＤＥＶ（Ｋｃ）を自己の秘密鍵ＫｓＤＥＶ
を用いて復号し、さらに、ユーザ機器の保存鍵Ｋｓｔｏ
を用いて暗号化して暗号化コンテンツ鍵：Ｋｓｔｏ（Ｋ
ｃ）を生成して、これをユーザ機器１０２０の記憶手段
に格納する。コンテンツの利用時には、暗号化コンテン
ツ鍵：Ｋｓｔｏ（Ｋｃ）を保存鍵Ｋｓｔｏを用いて復号
してコンテンツ鍵Ｋｃを取り出して、取り出したコンテ
ンツ鍵Ｋｃを用いて、暗号化コンテンツＫｃ（Conten
t）の復号処理を実行し、コンテンツ（Content）を再
生、実行する。
【０４０４】以上、述べたように、コンテンツ配信に伴
う各処理において、通信を実行する各エンティテイは、
属性確認により、相手の属性、例えばユーザ機器である
ことを確認した後、処理を実行する構成としたので、不
当なコンテンツ取り引き、例えばショップがユーザ機器
になりすましてコンテンツを取り引きするなどの処理、
あるいは、ショップサーバになりすまして、ユーザ機器
からクレジット口座番号を不正に取得する等の処理が防
止される。
【０４０５】例えばユーザ機器は、属性確認により、ユ
ーザ機器の通信相手がショップであると確認されれば、
ショップに対する処理としてのコンテンツ購入に伴う処
理を安心して実行可能であり、また属性確認において、
通信相手がユーザ機器認証サーバであると確認されれ
ば、ユーザ機器認証サーバに対する処理、例えば鍵のか
けかえ要求の送信を実行することができる。本構成によ
れば、属性確認を行なうことにより通信相手の属性が確
認可能となるので、それぞれの通信相手に応じた正当な
処理が実行される。さらに、不正な通信相手に秘密デー
タを誤って送信することもなくなるので、データ漏洩の
防止も可能である。
【０４０６】次に、相互認証処理による相手確認を実行
せず、受信データの署名検証のみを実行して、データ改
竄の有無と、属性確認を実行してコンテンツ取り引き処
理を実行する形態について図７４を用いて説明する。
【０４０７】図７４に示す処理は、図７２に示す処理か
ら相互認証処理を省いた処理として実行されるものであ
る。図７４の番号（１）から（１６）の順に処理が進行
する。各番号順に処理の詳細を説明する。
【０４０８】（１）トランザクションＩＤ、購入要求デ
ータ生成、および （２）購入要求データ送信 まず、ユーザ機器１０２０は、コンテンツの購入要求デ
ータを生成し、ショップサーバ１０１０に送信する。購
入要求データの構成は、先に説明した図１４（ａ）に示
す構成である。
【０４０９】（３）受信データ検証 図１４（ａ）に示す購入要求データをユーザ機器１０２
０から受信したショップサーバは、受信データの検証処
理を実行する。本実施例における検証処理は、購入要求
データの改竄有無のチェックとともに、属性情報のチェ
ックも併せて実行するものである。
【０４１０】図７５に公開鍵証明書に属性情報が格納さ
れている場合の受信データ検証処理フローを示す。ま
ず、メッセージと署名（購入要求データ）と、ユーザ機
器の公開鍵証明書を受信（Ｓ２３０１）したショップサ
ーバ１０１０は、ユーザ機器の公開鍵証明書を公開鍵証
明書発行局の公開鍵ＫｐＣＡを用いて検証（Ｓ２３０
２）する。検証が成立（Ｓ２３０３でＹｅｓ）すると、
公開鍵証明書からユーザ機器の公開鍵：ＫｐＤＥＶを取
り出し（Ｓ２３０４）て、ユーザ機器の公開鍵：ＫｐＤ
ＥＶを用いて購入要求データのユーザ機器署名の検証
（Ｓ２３０５）を行なう。さらに、検証が成功（Ｓ２３
０６でＹｅｓ）すると、公開鍵証明書から属性情報を取
り出し（Ｓ２３０７）て、正当な属性（ここではユーザ
機器を示す属性）であるか否かを判定（Ｓ２３０８）
し、正当である場合は、検証処理成功（Ｓ２３０９）と
して、次の処理に移行する。ステップＳ２３０３，Ｓ２
３０６，Ｓ２３０８で判定がＮｏの場合は、検証処理失
敗（Ｓ２３１０）として処理を中止する。
【０４１１】次に、公開鍵証明書と属性証明書を用いた
受信データ検証処理について図７６のフローを用いて説
明する。まず、メッセージと署名（購入要求データ）
と、ユーザ機器の公開鍵証明書、属性証明書を受信（Ｓ
２４０１）したショップサーバ１０１０は、ユーザ機器
の公開鍵証明書を公開鍵証明書発行局の公開鍵ＫｐＣＡ
を用いて検証（Ｓ２４０２）する。検証が成立（Ｓ２４
０３でＹｅｓ）すると、公開鍵証明書からユーザ機器の
公開鍵：ＫｐＤＥＶを取り出し（Ｓ２４０４）て、ユー
ザ機器の公開鍵：ＫｐＤＥＶを用いて購入要求データの
ユーザ機器署名の検証（Ｓ２４０５）を行なう。さら
に、検証が成功（Ｓ２４０６でＹｅｓ）すると、属性証
明書を属性証明書発行局の公開鍵ＫｐＡＡを用いて検証
（Ｓ２４０７）する。検証が成功（Ｓ２４０８でＹｅ
ｓ）したことを条件として、属性証明書から属性情報を
取り出し（Ｓ２４０９）て、正当な属性（ここではユー
ザ機器を示す属性）であるか否かを判定（Ｓ２４１０）
し、正当である場合は、検証処理成功（Ｓ２４１１）と
して、次の処理に移行する。ステップＳ２４０３，Ｓ２
４０６，Ｓ２４０８，Ｓ２４１０で判定がＮｏの場合
は、検証処理失敗（Ｓ２４１２）として処理を中止す
る。
【０４１２】（４）暗号化コンテンツおよび暗号化コン
テンツ鍵データ１（ショップ）送信 ショップサーバ１０１０において、購入要求データの検
証が完了し、データ改竄のない正当なコンテンツ購入要
求であると判定され属性が確認されると、ショップサー
バ１０１０は、暗号化コンテンツおよび暗号化コンテン
ツ鍵データ１（ショップ）（図１４（ｂ）参照）をユー
ザ機器に送信する。
【０４１３】（５）受信データ検証 ショップサーバ１０１０から暗号化コンテンツ：Ｋｃ
（content）と、図１４（ｂ）に示す暗号化コンテンツ
鍵データ１（ショップ）を受信したユーザ機器１０２０
は、暗号化コンテンツ鍵データ１（ショップ）の検証処
理および属性確認処理を実行する。この検証処理は、先
に説明した図７５または図７６の処理フローと同様の処
理である。この場合、公開鍵証明書または属性証明書の
属性がショップを示していない場合は、処理が中止され
ることになる。
【０４１４】（６）暗号化コンテンツ鍵データ（ユーザ
機器）および暗号化コンテンツ鍵かけかえ要求送信 次に、ユーザ機器１０２０は、ユーザ機器認証サーバ１
０３０に対して、先にショップサーバ１０１０から受信
した暗号化コンテンツ鍵ＫｐＤＡＳ（Ｋｃ）と、暗号化
コンテンツ鍵かけかえ要求（図１４（ｃ）参照）を送信
する。
【０４１５】（７）受信データ検証 ユーザ機器１０２０から暗号化コンテンツ鍵データ（ユ
ーザ機器）および暗号化コンテンツ鍵かけかえ要求（図
１４（ｃ））を受信したユーザ機器認証サーバ１０３０
は、暗号化コンテンツ鍵かけかえ要求の検証処理を実行
する。この検証処理は、先に説明した図７５、図７６の
処理フローと同様の処理であり、属性確認も併せて実行
する処理である。この場合は公開鍵証明書または属性証
明書の属性がユーザ機器でない場合は、処理が中止され
る。
【０４１６】（８）暗号化コンテンツ鍵かけかえ処理、 次に、ユーザ機器認証サーバ１０３０において、ＫｐＤ
ＡＳ（Ｋｃ）→Ｋｃ→ＫｐＤＥＶ（Ｋｃ）の鍵かけかえ
処理を実行する。
【０４１７】（９）暗号化コンテンツデータ送信 次に、ユーザ機器認証サーバ１０３０は、暗号化コンテ
ンツ鍵データ（ＤＡＳ）をショップサーバ１０１０に送
信する。暗号化コンテンツ鍵データ（ＤＡＳ）の構成
は、先に説明した図１７（ｄ）に示す構成である。
【０４１８】（１０）受信データ検証 ユーザ機器認証サーバ１０３０から暗号化コンテンツ鍵
データ（ＤＡＳ）（図１７（ｄ））を受信したショップ
サーバ１０１０は、暗号化コンテンツ鍵データ（ＤＡ
Ｓ）の検証処理を実行する。この検証処理は、先に説明
した図７５、図７６の処理フローと同様の処理であり、
属性確認が併せて実行される。この場合は公開鍵証明書
または属性証明書の属性がユーザ機器認証サーバ（サー
ビス運営体）でない場合は、処理が中止される。
【０４１９】（１１）暗号化コンテンツ鍵要求データ送
信 次に、ユーザ機器１０２０は、暗号化コンテンツ鍵要求
データをショップサーバに対して送信する。暗号化コン
テンツ鍵要求データの構成は図１７（ｅ）に示す通りで
ある。
【０４２０】（１２）検証処理、および （１３）課金処理 暗号化コンテンツ鍵要求データをユーザ機器から受信し
たショップサーバ１０１０は、暗号化コンテンツ鍵要求
データの検証処理を実行する。これは、先に説明した図
７５、図７６の処理フローと同様の処理であり、属性確
認も併せて実行する処理である。この場合は公開鍵証明
書または属性証明書の属性がユーザ機器でない場合は、
処理が中止される。データ検証が済むと、ショップサー
バ１０１０は、コンテンツの取り引きに関する課金処理
を実行する。
【０４２１】（１４）暗号化コンテンツ鍵データ２（シ
ョップ）送信 ショップサーバ１０１０における課金処理が終了する
と、ショップサーバ１０１０は、暗号化コンテンツ鍵デ
ータ２（ショップ）をユーザ機器１０２０に送信する。
暗号化コンテンツ鍵データ２（ショップ）の構成は、先
に説明した図１７（ｆ）に示す通りである。
【０４２２】（１５）受信データ検証 （１６）保存処理 ショップサーバ１０１０から、暗号化コンテンツ鍵デー
タ２（ショップ）を受領したユーザ機器１０２０は、暗
号化コンテンツ鍵データ２（ショップ）の検証処理を実
行する。この検証処理は、先に説明した図７５、図７６
の処理フローと同様の処理であり、属性確認も併せて実
行する処理である。この場合は公開鍵証明書または属性
証明書の属性がショップでない場合は、処理が中止され
る。データ検証が済むと、ユーザ機器１０２０は、コン
テンツの保存処理、すなわち自己の公開鍵ＫｐＤＥＶで
暗号化された暗号化コンテンツ鍵：ＫｐＤＥＶ（Ｋｃ）
を自己の秘密鍵ＫｓＤＥＶを用いて復号し、さらに、ユ
ーザ機器の保存鍵Ｋｓｔｏを用いて暗号化して暗号化コ
ンテンツ鍵：Ｋｓｔｏ（Ｋｃ）を生成して、これをユー
ザ機器１０２０の記憶手段に格納する処理を実行する。
【０４２３】このように、図７４に示す処理において
は、相互認証時に属性確認を行なうのではなく、受信し
たデータの署名検証において、属性を確認する処理を実
行する構成としたので、処理が簡略化され、コンテンツ
取り引きに伴う処理の効率化が達成される。
【０４２４】なお、上述した属性データによる属性確認
を適用した実施例では、サービス運営体において、鍵か
けかえ処理を実行する構成について説明したが、例えば
前述のログ収集サーバを適用した構成においても属性確
認処理を適用することが可能である。その他一般的なデ
ータ送受信を実行するエンティテイ間において、それぞ
れのエンティテイに特徴づけられた機能に基づいて属性
を設定し、設定された属性を公開鍵証明書または属性証
明書に格納し、これらの証明書を用いて通信相手の属性
確認処理を実行することにより、さらにデータ通信の安
全性、セキュリテイを高めることが可能となる。また、
属性確認処理は、従来の相互認証処理、署名検証処理と
併せて実行することが可能であるので、通常のデータ通
信は、署名検証のみ、あるいは相互認証のみを行ない、
必要に応じて属性確認処理を行なうなど、セキュリティ
度合いに応じて選択的に署名検証処理、相互認証処理、
属性確認処理のいずれか、あるいは組み合わせて実行す
ることが可能である。
【０４２５】以上、特定の実施例を参照しながら、本発
明について詳解してきた。しかしながら、本発明の要旨
を逸脱しない範囲で当業者が該実施例の修正や代用を成
し得ることは自明である。すなわち、例示という形態で
本発明を開示してきたのであり、限定的に解釈されるべ
きではない。本発明の要旨を判断するためには、冒頭に
記載した特許請求の範囲の欄を参酌すべきである。
【０４２６】
【発明の効果】上述したように、本発明の属性確認処理
を含むデータ通信システムおよび属性確認処理を含むデ
ータ通信方法によれば、データ通信を実行するエンティ
テイ間において、通信相手のエンティテイに設定された
属性情報を通信相手のエンティテイの公開鍵証明書また
は属性証明書から取得し、取得した属性情報に基づく属
性確認がなされたことを処理実行条件としたので、通信
相手が他のエンティテイになりすまして処理を実行する
ことが防止され、安全なデータ通信、例えばコンテンツ
取り引きに伴う処理が可能となる。
【０４２７】さらに、本発明の属性確認処理を含むデー
タ通信システムおよび属性確認処理を含むデータ通信方
法によれば、例えば、コンテンツの購入を実行するユー
ザ機器、コンテンツの購入要求を受け付けるショップサ
ーバ、コンテンツ配信管理を行うシステムホルダ等の機
能毎に異なる属性コードを付与して、属性コードに基づ
いて属性確認を実行する構成としたので、ユーザ機器は
例えば通信相手がショップサーバであることを確認した
後、様々なコンテンツ購入処理に伴うデータ送信が可能
となり、秘密データの漏洩等が防止される。
【０４２８】さらに、本発明の属性確認処理を含むデー
タ通信システムおよび属性確認処理を含むデータ通信方
法によれば、属性情報は、公開鍵証明書または属性証明
書に格納され、それぞれの証明書には、公開鍵証明書発
行局または属性証明書発行局の署名が生成されて格納さ
れた構成であるので、不正な属性情報を用いた不正な処
理が防止可能となる。
【図面の簡単な説明】
【図１】本発明のコンテンツ配信システムのシステム概
要およびコンテンツ配信処理を説明する図である。
【図２】本発明のコンテンツ配信システムにおけるショ
ップサーバの構成を示す図である。
【図３】本発明のコンテンツ配信システムにおけるショ
ップサーバの購買管理データベースの構成を示す図であ
る。
【図４】本発明のコンテンツ配信システムにおけるショ
ップサーバの制御手段構成を示す図である。
【図５】本発明のコンテンツ配信システムにおけるユー
ザ機器認証サーバの構成を示す図である。
【図６】本発明のコンテンツ配信システムにおけるユー
ザ機器認証サーバのライセンス管理データベースの構成
を示す図である。
【図７】本発明のコンテンツ配信システムにおけるユー
ザ機器の構成を示す図である。
【図８】本発明のコンテンツ配信システムにおけるユー
ザ機器の購入管理データベース構成を示す図である。
【図９】本発明のコンテンツ配信システムにおける公開
鍵証明書配布構成を示す図である。
【図１０】本発明のコンテンツ配信システムにおいて適
用可能な署名生成処理を説明する図である。
【図１１】本発明のコンテンツ配信システムにおいて適
用可能な署名検証処理を説明する図である。
【図１２】本発明のコンテンツ配信システムにおいて適
用可能な相互認証（対称鍵方式）処理を説明する図であ
る。
【図１３】本発明のコンテンツ配信システムにおいて適
用可能な相互認証（非対称鍵方式）処理を説明する図で
ある。
【図１４】本発明のコンテンツ配信システムにおいて各
エンティテイ間で通信されるデータ構成を説明する図で
ある。
【図１５】本発明のコンテンツ配信システムにおいて適
用可能なデータ検証処理を説明する図である。
【図１６】本発明のコンテンツ配信システムにおいて実
行される鍵かけかえ処理を説明する図である。
【図１７】本発明のコンテンツ配信システムにおいて各
エンティテイ間で通信されるデータ構成を説明する図で
ある。
【図１８】本発明のコンテンツ配信システムにおいて各
エンティテイ間で通信されるデータ構成を説明する図で
ある。
【図１９】本発明のコンテンツ配信システムにおいて実
行されるコンテンツ鍵保存処理を説明する図である。
【図２０】本発明のコンテンツ配信システムにおけるシ
ョップサーバのステータス変遷を説明する図である。
【図２１】本発明のコンテンツ配信システムにおけるユ
ーザ機器のステータス変遷を説明する図である。
【図２２】本発明のコンテンツ配信システムにおけるユ
ーザ機器認証サーバのステータス変遷を説明する図であ
る。
【図２３】本発明のコンテンツ配信システムにおけるシ
ョップサーバとユーザ機器間の処理フロー（その１）を
示す図である。
【図２４】本発明のコンテンツ配信システムにおけるシ
ョップサーバとユーザ機器間の処理フロー（その２）を
示す図である。
【図２５】本発明のコンテンツ配信システムにおけるユ
ーザ機器認証サーバとユーザ機器間の処理フローを示す
図である。
【図２６】本発明のコンテンツ配信システムにおけるユ
ーザ機器認証サーバとショップサーバ間の処理フローを
示す図である。
【図２７】本発明のコンテンツ配信システムにおけるシ
ョップサーバとユーザ機器間の処理フロー（その１）を
示す図である。
【図２８】本発明のコンテンツ配信システムにおけるシ
ョップサーバとユーザ機器間の処理フロー（その２）を
示す図である。
【図２９】本発明のコンテンツ配信システムの変形例と
して配信サーバを用いたコンテンツ配信処理を説明する
図である。
【図３０】本発明のコンテンツ配信システムの変形例と
して配信サーバを用いたコンテンツ配信処理を説明する
図である。
【図３１】本発明のコンテンツ配信システムの変形例の
コンテンツ配信処理を説明する図である。
【図３２】本発明のコンテンツ配信システムにおいて各
エンティテイ間で通信されるデータ構成を説明する図で
ある。
【図３３】本発明のコンテンツ配信システムにおいて各
エンティテイ間で通信されるデータ構成を説明する図で
ある。
【図３４】本発明のコンテンツ配信システムにおいて各
エンティテイ間で通信されるデータ構成を説明する図で
ある。
【図３５】本発明のコンテンツ配信システムの相互認証
を伴わないコンテンツ配信処理を説明する図である。
【図３６】本発明のコンテンツ配信システムの相互認証
を伴わないコンテンツ配信処理の変形例を説明する図で
ある。
【図３７】本発明のコンテンツ配信システムにおいて電
子チケットを適用したコンテンツ配信処理を説明する図
である。
【図３８】本発明のコンテンツ配信システムのチケット
発行サーバの構成を説明する図である。
【図３９】本発明のコンテンツ配信システムのチケット
発行サーバのチケット発行管理データベース構成を説明
する図である。
【図４０】本発明のコンテンツ配信システムのユーザ機
器の購入管理データベース構成を説明する図である。
【図４１】本発明のコンテンツ配信システムのユーザ機
器認証サーバのライセンス管理データベース構成を説明
する図である。
【図４２】本発明のコンテンツ配信システムの配信サー
バの構成を説明する図である。
【図４３】本発明のコンテンツ配信システムの配信サー
バの配信管理データベース構成を説明する図である。
【図４４】本発明のコンテンツ配信システムのチケット
換金サーバの構成を説明する図である。
【図４５】本発明のコンテンツ配信システムのチケット
換金サーバのチケット換金管理データベース構成を説明
する図である。
【図４６】本発明のコンテンツ配信システムにおいて各
エンティテイ間で通信されるデータ構成を説明する図で
ある。
【図４７】本発明のコンテンツ配信システムにおいて各
エンティテイ間で通信されるデータ構成を説明する図で
ある。
【図４８】本発明のコンテンツ配信システムにおけるチ
ケット発行サーバのステータス変遷を説明する図であ
る。
【図４９】本発明のコンテンツ配信システムにおけるユ
ーザ機器認証サーバのステータス変遷を説明する図であ
る。
【図５０】本発明のコンテンツ配信システムにおける配
信サーバのステータス変遷を説明する図である。
【図５１】本発明のコンテンツ配信システムにおけるユ
ーザ機器のステータス変遷を説明する図である。
【図５２】本発明のコンテンツ配信システムにおけるチ
ケット換金サーバのステータス変遷を説明する図であ
る。
【図５３】本発明のコンテンツ配信システムにおいて電
子チケットを適用したコンテンツ配信処理の具体例を説
明する図である。
【図５４】本発明のコンテンツ配信システムにおいてロ
グ収集サーバを適用したコンテンツ配信処理を説明する
図である。
【図５５】本発明のコンテンツ配信システムにおける購
入ログの構成例を説明する図である。
【図５６】本発明のコンテンツ配信システムにおけるロ
グ収集サーバの構成を示す図である。
【図５７】本発明のコンテンツ配信システムにおけるユ
ーザ機器と、ショップサーバ間の処理を示すフロー図
（その１）である。
【図５８】本発明のコンテンツ配信システムにおけるユ
ーザ機器と、ショップサーバ間の処理を示すフロー図
（その２）である。
【図５９】本発明のコンテンツ配信システムにおける購
入要求データと販売確認データのフォーマット例を示す
図である。
【図６０】本発明のコンテンツ配信システムにおいてて
着ようか能な改竄チェック値（ＩＣＶ）生成処理構成を
示す図である。
【図６１】本発明のコンテンツ配信システムにおけるユ
ーザ機器と、ログ収集サーバ間の処理を示すフロー図
（その１）である。
【図６２】本発明のコンテンツ配信システムにおけるユ
ーザ機器と、ログ収集サーバ間の処理を示すフロー図
（その２）である。
【図６３】本発明のコンテンツ配信システムにおけるコ
ンテンツプロバイダと、ログ収集サーバ間の処理を示す
フロー図である。
【図６４】本発明のコンテンツ配信システムにおけるシ
ョップサーバと、ログ収集サーバ間の処理を示すフロー
図である。
【図６５】本発明のコンテンツ配信システムにおけるシ
ョップサーバと、ログ収集サーバ間の処理を示すフロー
図である。
【図６６】本発明のコンテンツ配信システムにおいて適
用される属性情報について説明する図である。
【図６７】本発明のコンテンツ配信システムにおいて適
用可能な属性情報を持つ公開鍵証明書構成を示す図であ
る。
【図６８】本発明のコンテンツ配信システムにおいて適
用可能な公開鍵証明書および属性証明書構成を示す図で
ある。
【図６９】本発明のコンテンツ配信システムにおける公
開鍵証明書の新規発行処理を説明する図である。
【図７０】本発明のコンテンツ配信システムにおける公
開鍵証明書の更新処理を説明する図である。
【図７１】本発明のコンテンツ配信システムにおける属
性証明書の新規発行処理を説明する図である。
【図７２】本発明のコンテンツ配信システムにおける属
性チェックを伴うコンテンツ配信処理を説明する図であ
る。
【図７３】本発明のコンテンツ配信システムにおける属
性チェックを伴う相互認証処理を説明するフロー図であ
る。
【図７４】本発明のコンテンツ配信システムにおける属
性チェックを伴うコンテンツ配信処理を説明する図であ
る。
【図７５】本発明のコンテンツ配信システムにおける属
性チェックを伴うデータ検証処理を説明するフロー図で
ある。
【図７６】本発明のコンテンツ配信システムにおける属
性チェックを伴うデータ検証処理を説明するフロー図で
ある。
【符号の説明】
１００ ショップサーバ １１０ コンテンツデータベース １２０ 購買管理データベース １３０ 制御手段 １３１ 制御部 １３２ ＲＯＭ １３３ ＲＡＭ １３４ 表示部 １３５ 入力部 １３６ ＨＤＤ １３７ ドライブ １３８ ネットワークインタフェース ２００ ユーザ機器 ２２０ 購入管理データベース ２３０ 制御手段 ３００ ユーザ機器認証サーバ ３２０ ライセンス管理データベース ３３０ 制御手段 ４００ 配信サーバ ４１０ コンテンツデータベース ６１０ チケット発行サーバ ６１２ 購買管理データベース ６１３ 制御手段 ６２０ ユーザ機器 ６３０ ユーザ機器認証サーバ ６４０ 配信サーバ ６４２ 配信管理データベース ６４３ 制御手段 ６４４ コンテンツデータベース ６５０ チケット換金サーバ ６５２ チケット換金管理データベース ６５３ 制御手段 ８０１ チケット発行体 ８０２ ユーザ機器 ８０３ ライセンスホルダ ８０４ コンテンツ制作者 ８０５ 銀行 ９０１ ショップサーバ ９０２ ユーザ機器 ９０３ ログ収集サーバ ９０４ オーサリングサーバ ９０５ コンテンツプロバイダ ９０３１ ログ管理データベース ９０３２ 制御手段 １０１０ ショップサーバ １０２０ ユーザ機器 １０３０ サービス運営体 １０４０ 公開鍵証明書発行局 １０５０ 属性証明書発行局
───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.7 識別記号 ＦＩ テーマコート゛(参考） Ｇ０６Ｆ 17/60 ３１０ Ｇ０６Ｆ 17/60 ３１０Ｅ ５１２ ５１２ Ｈ０４Ｌ 9/08 Ｈ０４Ｎ 7/173 ６１０Ｚ 9/32 Ｈ０４Ｌ 9/00 ６０１Ｃ Ｈ０４Ｎ 7/167 ６７５Ｂ 7/173 ６１０ Ｈ０４Ｎ 7/167 Ｚ (72)発明者 秋下 徹 東京都品川区北品川６丁目７番35号 ソニ ー株式会社内 (72)発明者 白井 太三 東京都品川区北品川６丁目７番35号 ソニ ー株式会社内 (72)発明者 岡 誠 東京都品川区北品川６丁目７番35号 ソニ ー株式会社内 Ｆターム(参考） 5B049 AA05 BB00 CC05 DD01 EE01 EE07 FF03 FF04 GG04 GG07 GG10 5C064 BA01 BA07 BB05 BB07 BC07 BC16 BC18 BC20 BC23 BC25 BD02 BD07 BD08 CA14 CB01 CC04 5J104 AA07 AA09 AA12 AA16 EA05 EA06 EA18 EA19 KA02 KA05 LA03 LA06 NA12 NA16 PA11

Claims (24)

    【特許請求の範囲】
  1. 【請求項１】データ通信を実行するエンティテイ間にお
    いて、通信相手のエンティテイに設定された属性情報を
    該通信相手のエンティテイの公開鍵証明書または属性証
    明書から取得し、取得した属性情報に基づく属性確認が
    なされたことを処理実行条件とした構成を有することを
    特徴とする属性確認処理を含むデータ通信システム。
  2. 【請求項２】前記属性情報は、エンティテイの機能に基
    づいて設定される属性情報であることを特徴とする請求
    項１に記載の属性確認処理を含むデータ通信システム。
  3. 【請求項３】データ通信を実行するエンティテイは、コ
    ンテンツ配信システムを構成するエンティテイであっ
    て、 コンテンツを購入する機能を持つユーザ機器、コンテン
    ツの購入依頼を受領する機能を持つショップサーバ、コ
    ンテンツ配信を管理する機能を持つサービス運営体サー
    バ、コンテンツを配信する配信サーバ中の２以上のエン
    ティテイを含み、該異なるエンティテイの各々には、異
    なる属性情報としての属性コードが付与され、各エンテ
    ィテイの公開鍵証明書または属性証明書に格納された構
    成であることを特徴とする請求項１に記載の属性確認処
    理を含むデータ通信システム。
  4. 【請求項４】前記エンティテイの属性情報は、当該エン
    ティテイの公開鍵証明書に格納され、属性情報を格納し
    た公開鍵証明書には、公開鍵証明書発行局の署名が生成
    されて格納された構成を有することを特徴とする請求項
    １に記載の属性確認処理を含むデータ通信システム。
  5. 【請求項５】前記エンティテイの属性情報は、当該エン
    ティテイの属性証明書に格納され、属性情報を格納した
    属性証明書には、属性証明書発行局の署名が生成されて
    格納された構成を有することを特徴とする請求項１に記
    載の属性確認処理を含むデータ通信システム。
  6. 【請求項６】データ通信を実行するエンティテイ間にお
    いて、通信相手のエンティテイに設定された属性情報を
    取得する処理は、 エンティテイ間の相互認証処理において取得する通信相
    手の公開鍵証明書から取得する処理として実行すること
    を特徴とする請求項１に記載の属性確認処理を含むデー
    タ通信システム。
  7. 【請求項７】データ通信を実行するエンティテイ間にお
    いて、通信相手のエンティテイに設定された属性情報を
    取得する処理は、 通信相手の属性証明書を取得し、属性証明書中の属性証
    明書発行局の署名検証を実行し、署名検証成功を条件と
    して属性証明書から取得する処理として実行することを
    特徴とする請求項１に記載の属性確認処理を含むデータ
    通信システム。
  8. 【請求項８】データ通信を実行するエンティテイ間にお
    いて、通信相手のエンティテイに設定された属性情報を
    取得する処理は、 受信データの署名検証処理に適用する通信相手エンティ
    テイの公開鍵証明書から取得する処理として実行するこ
    とを特徴とする請求項１に記載の属性確認処理を含むデ
    ータ通信システム。
  9. 【請求項９】データ通信を実行するエンティテイ間にお
    いて、通信相手のエンティテイに設定された属性情報を
    取得する処理は、 通信相手の公開鍵証明書とリンクする属性証明書を、公
    開鍵証明書および属性証明書に共通に格納された公開鍵
    証明書通し番号に基づいて確認し、公開鍵証明書と同一
    の公開鍵証明書通し番号を格納した属性証明書から取得
    する処理として実行することを特徴とする請求項１に記
    載の属性確認処理を含むデータ通信システム。
  10. 【請求項１０】前記属性確認処理は、 通信相手のエンティテイの公開鍵証明書、または属性証
    明書から取得した属性コードと、通信相手として想定し
    たエンティテイに設定された属性コードとの比較処理と
    して実行する構成であることを特徴とする請求項１に記
    載の属性確認処理を含むデータ通信システム。
  11. 【請求項１１】前記属性確認処理は、 特定の通信相手に固有の通信処理実行シーケンスに含ま
    れる属性コード比較処理であり、 前記特定の通信相手に設定された属性コードと、通信相
    手のエンティテイの公開鍵証明書、または属性証明書か
    ら取得した属性コードとの比較処理として実行する構成
    であることを特徴とする請求項１に記載の属性確認処理
    を含むデータ通信システム。
  12. 【請求項１２】データ通信を実行するエンティテイ間に
    おいて、通信相手のエンティテイに設定された属性情報
    を該通信相手のエンティテイの公開鍵証明書または属性
    証明書から取得する属性情報取得ステップと、 前記属性情報取得ステップにおいて取得した属性情報に
    基づく属性確認を実行する属性確認処理ステップとを有
    し、 前記属性確認ステップにおいて属性の正当性が確認され
    たことを次処理実行条件としたことを特徴とする属性確
    認処理を含むデータ通信方法。
  13. 【請求項１３】前記属性情報は、エンティテイの機能に
    基づいて設定される属性情報であることを特徴とする請
    求項１２に記載の属性確認処理を含むデータ通信方法。
  14. 【請求項１４】データ通信を実行するエンティテイは、
    コンテンツ配信システムを構成するエンティテイであっ
    て、 コンテンツを購入する機能を持つユーザ機器、コンテン
    ツの購入依頼を受領する機能を持つショップサーバ、コ
    ンテンツ配信を管理する機能を持つサービス運営体サー
    バ、コンテンツを配信する配信サーバ中の２以上のエン
    ティテイを含み、該異なるエンティテイの各々には、異
    なる属性情報としての属性コードが付与され、各エンテ
    ィテイの公開鍵証明書または属性証明書に格納され、 前記公開鍵証明書または属性証明書に基づく属性確認を
    実行することを特徴とする請求項１２に記載の属性確認
    処理を含むデータ通信方法。
  15. 【請求項１５】前記エンティテイの公開鍵証明書は、エ
    ンティテイに設定された属性情報を含み、公開鍵証明書
    発行局の署名が格納され、 属性確認を実行するエンティテイは、前記公開鍵証明書
    発行局の署名検証の後、前記属性情報を取得する処理を
    実行することを特徴とする請求項１２に記載の属性確認
    処理を含むデータ通信方法。
  16. 【請求項１６】前記エンティテイの属性証明書は、エン
    ティテイに設定された属性情報を含み、属性証明書発行
    局の署名が格納され、 属性確認を実行するエンティテイは、前記属性証明書発
    行局の署名検証の後、前記属性情報を取得する処理を実
    行することを特徴とする請求項１２に記載の属性確認処
    理を含むデータ通信方法。
  17. 【請求項１７】データ通信を実行するエンティテイ間に
    おいて、通信相手のエンティテイに設定された属性情報
    を取得する処理は、 エンティテイ間の相互認証処理において取得する通信相
    手の公開鍵証明書から取得する処理として実行すること
    を特徴とする請求項１２に記載の属性確認処理を含むデ
    ータ通信方法。
  18. 【請求項１８】データ通信を実行するエンティテイ間に
    おいて、通信相手のエンティテイに設定された属性情報
    を取得する処理は、 受信データの署名検証処理に適用する通信相手エンティ
    テイの公開鍵証明書から取得する処理として実行するこ
    とを特徴とする請求項１２に記載の属性確認処理を含む
    データ通信方法。
  19. 【請求項１９】データ通信を実行するエンティテイ間に
    おいて、通信相手のエンティテイに設定された属性情報
    を取得する処理は、 通信相手の公開鍵証明書とリンクする属性証明書を、公
    開鍵証明書および属性証明書に共通に格納された公開鍵
    証明書通し番号に基づいて確認し、公開鍵証明書と同一
    の公開鍵証明書通し番号を格納した属性証明書から取得
    する処理として実行することを特徴とする請求項１２に
    記載の属性確認処理を含むデータ通信方法。
  20. 【請求項２０】前記属性確認処理ステップは、 通信相手のエンティテイの公開鍵証明書、または属性証
    明書から取得した属性コードと、通信相手として想定し
    たエンティテイに設定された属性コードとの比較処理と
    して実行することを特徴とする請求項１２に記載の属性
    確認処理を含むデータ通信方法。
  21. 【請求項２１】前記属性確認処理ステップは、 特定の通信相手に固有の通信処理実行プログラムに含ま
    れる属性コード比較処理であり、 前記特定の通信相手に設定された属性コードと、通信相
    手のエンティテイの公開鍵証明書、または属性証明書か
    ら取得した属性コードとの比較処理として実行すること
    を特徴とする請求項１２に記載の属性確認処理を含むデ
    ータ通信方法。
  22. 【請求項２２】データ通信を実行するエンティテイの機
    能に基づく属性情報を構成データとして有するととも
    に、公開鍵証明所発行局の署名データを含む公開鍵証明
    書を格納したことを特徴とする記録媒体。
  23. 【請求項２３】データ通信を実行するエンティテイの機
    能に基づく属性情報を構成データとして有するととも
    に、属性証明書発行局の署名データを含む属性証明書を
    格納したことを特徴とする記録媒体。
  24. 【請求項２４】データ通信処理をコンピュータ・システ
    ム上で実行せしめるコンピュータ・プログラムを提供す
    るプログラム提供媒体であって、前記コンピュータ・プ
    ログラムは、 データ通信を実行するエンティテイ間において、通信相
    手のエンティテイに設定された属性情報を通信相手のエ
    ンティテイの公開鍵証明書または属性証明書から取得す
    る属性情報取得ステップと、 前記属性情報取得ステップにおいて取得した属性情報に
    基づく属性確認を実行する属性確認処理ステップと、 を有することを特徴とするプログラム提供媒体。
JP2000334186A 2000-11-01 2000-11-01 属性確認処理を含むデータ通信システムおよび属性確認処理を含むデータ通信方法 Pending JP2002139998A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2000334186A JP2002139998A (ja) 2000-11-01 2000-11-01 属性確認処理を含むデータ通信システムおよび属性確認処理を含むデータ通信方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2000334186A JP2002139998A (ja) 2000-11-01 2000-11-01 属性確認処理を含むデータ通信システムおよび属性確認処理を含むデータ通信方法

Publications (1)

Publication Number Publication Date
JP2002139998A true JP2002139998A (ja) 2002-05-17

Family

ID=18810149

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000334186A Pending JP2002139998A (ja) 2000-11-01 2000-11-01 属性確認処理を含むデータ通信システムおよび属性確認処理を含むデータ通信方法

Country Status (1)

Country Link
JP (1) JP2002139998A (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003101042A1 (fr) * 2002-05-24 2003-12-04 Sony Corporation Procede, systeme et dispositif de traitement d'informations, support d'enregistrement et programme
WO2003105400A1 (ja) * 2002-06-07 2003-12-18 ソニー株式会社 データ処理システム、データ処理装置、および方法、並びにコンピュータ・プログラム
JP2014139838A (ja) * 2007-02-06 2014-07-31 Nec Corp 個人情報の改ざん防止と個人情報流通否認防止のための個人情報管理装置、サービス提供装置、プログラム、個人情報管理方法、照合方法、および個人情報照合システム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003101042A1 (fr) * 2002-05-24 2003-12-04 Sony Corporation Procede, systeme et dispositif de traitement d'informations, support d'enregistrement et programme
WO2003105400A1 (ja) * 2002-06-07 2003-12-18 ソニー株式会社 データ処理システム、データ処理装置、および方法、並びにコンピュータ・プログラム
JP2014139838A (ja) * 2007-02-06 2014-07-31 Nec Corp 個人情報の改ざん防止と個人情報流通否認防止のための個人情報管理装置、サービス提供装置、プログラム、個人情報管理方法、照合方法、および個人情報照合システム

Similar Documents

Publication Publication Date Title
JP2002140630A (ja) チケットに基づくコンテンツ料金精算システムおよびチケットに基づくコンテンツ料金精算方法
JP2002141895A (ja) コンテンツ配信システムおよびコンテンツ配信方法
US7184986B2 (en) Content transaction system and method, and program providing medium therefor
US8117128B2 (en) Content usage management system method, and program providing medium therefor
JP4660900B2 (ja) 個人認証適用データ処理システム、個人認証適用データ処理方法、および情報処理装置、並びにプログラム提供媒体
US6574611B1 (en) Information processing apparatus and method, information management apparatus and method, and information providing medium
JP4581200B2 (ja) 個人認証システム、個人認証方法、および情報処理装置、並びにプログラム提供媒体
JP4655345B2 (ja) 情報処理装置および情報処理方法、並びにプログラム提供媒体
JP4120125B2 (ja) 利用許可証発行装置および方法
JP4552294B2 (ja) コンテンツ配信システム、コンテンツ配信方法、および情報処理装置、並びにプログラム提供媒体
JP4586250B2 (ja) 個人識別証明書リンクシステム、情報処理装置、および情報処理方法、並びにプログラム提供媒体
JP4654497B2 (ja) 個人認証システム、個人認証方法、および情報処理装置、並びにプログラム提供媒体
US20030105720A1 (en) Content secondary distribution management system and method, and program providing medium therefor
US20020010861A1 (en) Access control system, access control method, device, access control server, access-control-server registration server, data processing apparatus, and program storage medium
JP2001230768A (ja) 情報取り引きシステムおよび情報取り引き方法、並びにプログラム提供媒体
JP2001320356A (ja) 公開鍵系暗号を使用したデータ通信システムおよびデータ通信システム構築方法
JP2002140534A (ja) ログ管理構成を持つコンテンツ配信システムおよびコンテンツ配信方法
JP3641909B2 (ja) 証明データ生成装置
JP2001256413A (ja) コンテンツ二次配信制限システムおよびコンテンツ二次配信制限方法、並びにプログラム提供媒体
JP2002139998A (ja) 属性確認処理を含むデータ通信システムおよび属性確認処理を含むデータ通信方法
JP2001256196A (ja) コンテンツ世代間配信制限システムおよびコンテンツ世代間配信制限方法、並びにプログラム提供媒体
JP2001256355A (ja) コンテンツ利用管理システムおよびコンテンツ利用管理方法、並びにプログラム提供媒体
JP2001256403A (ja) コンテンツ利用料金管理システムおよびコンテンツ利用料金管理方法、並びにプログラム提供媒体
JP2001256359A (ja) コンテンツ二次配布におけるユーザ管理システムおよびユーザ管理方法、並びにプログラム提供媒体
JPH1051572A (ja) 課金システムおよびその方法