(57)【特許請求の範囲】
【請求項１】
システム内のそれぞれのユーザデバイスを介して識別ベース暗号化（ＩＢＥ）を用いてユーザにデータを配信する方法であって、該システムは、コンテンツプロバイダと、データパッケージサービスデバイスと、ポリシー強制サービスデバイスと、それぞれのユーザデバイスにおける複数のユーザと、通信ネットワークとを有し、
該方法は、
該通信ネットワークを介して、該コンテンツプロバイダから該データパッケージサービスデバイスにデータ構造を提供することであって、該データ構造は暗号化されるべきデータと該暗号化されるべきデータの複数のデータ属性とを含む、ことと、
該データパッケージサービスデバイスが、該コンテンツプロバイダからの該複数のデータ属性のうちの少なくともいくつかをポリシー情報として用いて、ユーザの群に対して一般的である識別ベース暗号化公開鍵を形成することであって、該データパッケージサービスデバイスは、該識別ベース暗号化公開鍵を形成する場合、データタイプ暗号化ポリシー情報を用いて該複数のデータ属性のうちのどれを用いるかを選択する、ことと、
該データパッケージサービスデバイスが、識別ベース暗号化エンジンを用いて該データを暗号化することであって、該識別ベース暗号化エンジンは、該データを暗号化する場合、少なくとも該識別ベース暗号化公開鍵を入力として用いる、ことと、
該複数のユーザのデバイスにおいて、該複数のユーザに対して該暗号化されたデータを利用可能にすることと、
該複数のユーザのうちの所与のユーザに対応するユーザデバイスが、該識別ベース暗号化公開鍵に対応する識別ベース暗号化秘密鍵に対する鍵要求を生成することであって、該鍵要求は、該ポリシー情報と該所与のユーザの少なくとも１つの特性に関する情報とを含む、ことと、
該ポリシー強制サービスデバイスが、該所与のユーザのデバイスから該鍵要求を受信することと、
該ポリシー強制サービスデバイスが、該鍵要求に応答して、該鍵要求からの該ポリシー情報を用いて、どのアクセスポリシーを該所与のユーザに適用するかを決定し、どの識別ベース暗号化秘密鍵を生成すべきかを決定することと、
該ポリシー強制サービスデバイスにおいて、該鍵要求からの該ポリシー情報と該所与のユーザの該少なくとも１つの特性に関する情報とを用いて、該所与のユーザが該要求された識別ベース暗号化秘密鍵の受信を許可されているかどうかを決定することと、
該所与のユーザが許可されている場合、該ポリシー強制サービスデバイスを用いて該識別ベース暗号化公開鍵に対応する該要求された識別ベース暗号化秘密鍵を該ユーザに送信することと
を含む、方法。
【請求項２】
前記所与のユーザのユーザデバイスにおいて、前記秘密鍵と復号化エンジンとを用いて、該所与のユーザが前記暗号化されたデータのコンテンツにアクセス可能であるように該暗号化されたデータを復号化することをさらに含む、請求項１に記載の方法。
【請求項３】
前記ポリシー情報は指定情報を含み、前記方法は、前記所与のユーザが前記要求された秘密鍵の受信を許可されているかどうかを決定する際に、該指定情報を用いることをさらに含む、請求項１に記載の方法。
【請求項４】
前記ポリシー情報は、Ｇ指定、ＰＧ指定、ＰＧ−１３指定、Ｒ指定、およびＸ指定からなるグループから選択される指定情報を含む、請求項１に記載の方法。
【請求項５】
メディアプレーヤが前記所与のユーザのユーザデバイスに実装され、前記方法は、該メディアプレーヤを用いて前記鍵要求を生成することをさらに含む、請求項１に記載の方法。
【請求項６】
前記識別ベース暗号化エンジンを用いて、ＸＭＬフォーマットのデータタイプ暗号化ポリシー情報に基づいて、前記データを暗号化することをさらに含む、請求項１に記載の方法。
【請求項７】
前記データはＸＭＬフォーマットであり、前記方法は、前記識別ベース暗号化エンジンを用いて、前記ＸＭＬフォーマットのデータタイプ暗号化ポリシー情報に基づいて、ＸＭＬフォーマットデータを暗号化することをさらに含む、請求項６に記載の方法。
【請求項８】
前記公開鍵はＸＭＬフォーマットの公開鍵を含む、請求項１に記載の方法。
【請求項９】
前記データが歌を含み、前記方法は、ピアツーピア構成を用いてユーザに該歌を配信することをさらに含み、該データが復号化される前に、あるユーザが別のユーザに該歌を電子的に送信する、請求項１に記載の方法。
【請求項１０】
前記暗号化されたデータを復号化する前に、ピアツーピア構成内のあるユーザから別のユーザに該暗号化されたデータを配信することをさらに含む、請求項１に記載の方法。
【請求項１１】
前記識別ベース暗号化エンジンを用いてデータを暗号化するステップは、対称鍵暗号化を用いて該データ内のコンテンツを暗号化することなく、識別情報ベースの暗号化アルゴリズムを直接用いて該データを暗号化することを含む、請求項１に記載の方法。
【請求項１２】
前記識別ベース暗号化エンジンを用いてデータを暗号化するステップは、２段階の処理を用いて該データを暗号化することを含み、
該２段階の処理において、該データ内のコンテンツは、対称鍵を用いて暗号化され、該対称鍵は、識別情報ベースの暗号化アルゴリズムを用いて暗号化される、請求項１に記載の方法。
【請求項１３】
前記通信ネットワークを介して、前記データパッケージサービスデバイスからユーザへ前記公開鍵を送信することをさらに含む、請求項１に記載の方法。
【請求項１４】
前記ポリシー強制サービスデバイスにおいて、前記所与のユーザが前記要求された秘密鍵の受信を許可されているかどうかを決定する際に、グローバルポリシー情報を用いることをさらに含む、請求項１に記載の方法。
【請求項１５】
前記所与のユーザの特性に関する情報は、該所与のユーザの年齢に関する情報を含み、前記方法は、前記ポリシー強制サービスデバイスにおいて、前記鍵要求からの前記ポリシー情報と該ユーザの年齢に関する情報とを用いて、該所与のユーザが前記公開鍵に対応する前記秘密鍵の受信を許可されているかどうかを決定することをさらに含む、請求項１に記載の方法。
【発明の詳細な説明】
【背景技術】
【０００１】
（発明の背景）
本発明は暗号化に関し、特に詳しくは、データを安全に配信するための識別情報に基づく暗号化手法に関する。
【０００２】
歌および映像等のコンテンツを、デジタル形式で保存することが一般的になっている。暗号技術を用いて、このようなコンテンツを不正使用から保護するように支援することもできる。
【０００３】
データを暗号化する際に、多数の暗号技術を利用することができる。例えば、対称鍵技術が幅広く用いられている。対称鍵の構成により、一方の者が、対称鍵を用いてもう一方の者のデータを暗号化する。もう一方の者は、同じ対称鍵を用いて暗号化データを復号化する。対称鍵システムは、当事者の間で安全なやり方で対称鍵を交換する必要がある。
【０００４】
ＲＳＡ暗号システム等の公開鍵暗号システムでは、２種類の鍵を用いる。公開鍵および秘密鍵である。任意の者へのデータを、その者に一意の公開鍵を用いて暗号化することができる。各当事者は、暗号化データの復号に用いる対応する秘密鍵を有している。
【０００５】
識別情報に基づく暗号化手法についても提案されている。このような識別情報に基づく暗号化手法では、公開パラメータを用いてデータを暗号化することもできる。これらの手法が”識別情報に基づく”ものと言われているのは、特定のユーザの電子メールアドレス等のユーザ固有の識別情報を、暗号化アルゴリズムの入力の１つとして用いているからである。各ユーザは、ユーザの識別に基づいた、暗号化データを復号化する一意の秘密鍵を有している。この種類の手法では、１つのセットの公開パラメータ（暗号化および復号化処理の間に用いる）を、多くのユーザの間で共有することもできる。
【発明の開示】
【課題を解決するための手段】
【０００６】
（発明の要旨）
本発明によれば、識別情報に基づく暗号化手法を用いてコンテンツを安全に配信するシステムを提供する。この手法を用いる識別情報に基づく暗号化アルゴリズムでは、公開鍵に基づくポリシー情報を、１人のユーザに固有の実際の識別情報というよりもむしろ、１つの入力として用いる。このシステムを用いて、コンテンツを配信することもできる。デジタル符号化した映画または他の映像、デジタル符号化した歌（例えば、ＭＰ３ファイル）、または他の適したオーディオファイル、テキスト（例えば、本または雑誌）、グラフィックス（例えば、デジタル画像）、株式売買または決済記録、ソフトウェア（例えば、ゲームおよび他のアプリケーション）、企業の在庫表またはサプライチェーンデータ、または任意のその他のコンテンツ等である。
【０００７】
コンテンツプロバイダ（例えば、メディア関連コンテンツの場合は、映画会社、レコード会社、またはテレビジョンネットワーク、金融レコードコンテンツの場合は、証券会社または銀行または他の金融機関、ゲームおよび他のアプリケーションの場合は、サプライチェーンデータ生成企業、ソフトウェア販売店またはデベロッパまたは任意の他の適切な機関または関係者）が、データ（コンテンツ）を生成して配信することもできる。データパッケージサービスを用いて、データを暗号化することもできる。
【０００８】
暗号化されるデータは、指定、日付、タイトル、所有者の名前、価格等の対応付けられた属性を有することもできる。属性は、属性名（例えば，”ｒａｔｉｎｇ”）および対応付けられた属性値（例えば、”Ｒ”）を有することもできる。データ属性を、データ（例えば、映画の指定）から分けることもできるし、データ自体の一部とすることもできる（例えば、データおよび属性の両方の役割を果たすＸＭＬフィールドからなるＸＭＬデータ構造の場合）。所望の場合には、データパッケージサービスが、暗号化されるデータを有するデータ構造に属性を含めることもできる。データ構造の種類（例えば、”ｍｏｖｉｅ”）を、データ構造に対応付けることもできる。
【０００９】
一旦暗号化されたならば、暗号化されるデータに対応付けられた属性のある部分または全部をポリシー情報として用いて、データに対するアクセスを調整することもできる。一般に、いずれの任意のデータに対応付けられた特定の属性は、関連するデータの種類に依存する。
【００１０】
データパッケージサービスは、識別情報に基づく暗号化エンジン（暗号化処理）を用いて、データを暗号化することもできる（例えば、データ構造のコンテンツを暗号化する）。識別情報に基づく暗号化エンジンは、暗号化されるデータを取得して、対応する暗号化データを生成する。データを暗号化する際に、エンジンは少なくとも２つの入力を用いる。第１の入力は公開パラメータ情報である。例えば、以下に述べるように、ボネー（Ｂｏｎｅｈ）およびフランクリン（Ｆｒａｎｋｌｉｎ）の研究に関する、識別情報に基づく暗号化公開パラメータＰおよびｓＰのセットの形式の公開パラメータ情報である。第２の入力は、提案する識別情報に基づく暗号化アルゴリズムで用いられる”識別”の代わりをするものである。この第２の入力を、ここでは”識別”ではなくむしろ”公開鍵”と呼ぶのは、ユーザの電子メールアドレス等の一意のユーザ固有の識別を用いる場合のように、１人のユーザではなくむしろ、複数のユーザに対応付けられたものであるからである。各ユーザの一意の識別に基づく識別情報に基づく暗号化手法と、本アプローチとの間のこの違いに関わらず、本アプローチを、ここではやはり”識別情報に基づく”暗号化手法と呼んで、ＲＳＡ公開鍵アプローチ等の従来の公開鍵暗号化アプローチとはっきりと区別する。識別情報に基づく暗号化エンジンは、システムデータベースまたは構成要素と通信することなく、公開パラメータおよび公開鍵を用いてデータを暗号化することもできる。
【００１１】
本識別ベースの暗号化手法の公開鍵は、特定のユーザに対応付けられたものではなく、むしろ、複数のユーザのアクセス権を調整する汎用ポリシー情報に基づくものである（例えば、数百、数千、または数百万ものユーザである）。公開鍵のポリシー情報は、例えば、データの属性を用いて生成することもできる。属性から公開鍵を構成する例示の方法の１つは、属性名および値の連結を必要とする。例えば、デジタル映像では、公開鍵を、”ｓｅｃｕｒｅ−ｖｉｄｅｏ：／／Ｎａｍｅ＝Ｍａｔｒｉｘ；Ｄｉｓｔｒｉｂｕｔｏｒ＝Ｐａｒａｍｏｕｎｔ；Ｄａｔｅ＝Ａｕｇ−２００２；Ｒａｔｉｎｇ”Ｒ”とすることもできる。所望の場合には、データをＸＭＬデータ構造にまとめることもできる。ＸＭＬベースのフォーマットを用いてデータおよび属性情報を処理することは、ＸＭＬベースの属性基準が業界で受け入れられている状況では利点がある。
【００１２】
暗号化されるデータを、異なる種類のデータ構造にまとめることもできる。例えば、あるデータ構造の種類が”ｍｏｖｉｅ”で、もう一つのものが”ｓｏｎｇ”という場合である。特定の暗号化されるデータの属性を用いて公開鍵を生成する方法（例えば、どの特定の属性を用いて、用いられる任意の連結処理でどの順序で用いるか）を、データタイプ暗号化ポリシー情報を用いて指定することもできる。属性をＸＭＬレコードで維持する場合には、データタイプ暗号化ポリシー情報を用いて、どのＸＭＬレコードエントリを用いて公開鍵を生成するか、これらのエントリをどのように用いるかを、指定することもできる（例えば、特定のエントリを連結するべき順序等）。所望の場合には、データタイプ暗号化ポリシー情報自体を、ＸＭＬフォーマットを用いて保存することもできる。また、公開鍵を、ＸＭＬを用いて生成することもできる（例えば、公開鍵をＸＭＬフォーマットにすることもできる）。
【００１３】
データをまず復号化してからでないと、暗号化データのコンテンツにアクセスすることはできない。これは、データの暗号化に用いる公開鍵に対応する、適した秘密鍵を用いなければ、達成することができない。任意の暗号化データを取得したユーザ（例えば、データパッケージサービスから直接、または対応付けられた配信サービスから、またはピアツーピアトランザクションの別のユーザから）に、ポリシー強制サービスを介して、暗号化データのコンテンツに対するアクセスを許可することもできる（例えば、適した秘密鍵を供給することによる）。
【００１４】
ポリシー強制サービスは、任意のユーザにアクセスを許可するかどうか判定する際に、各種の種類のポリシー情報を用いることもできる。例えば、グローバルポリシー情報は、Ｒ指定の映像を１７歳未満のユーザに公開してはならないと命令することもできる。また、ポリシー情報を用いて、商業的加入契約規則を実施することもできる（例えば、”ユーザが”スピルバーグスペシャルプラン”を申し込めば、スティーブン・スピルバーグ監督の映画すべてに対して秘密鍵を発行することもできる）。ポリシー強制サービスが用いるポリシー情報は通常、公開鍵を含むアクセス要求の形式で、ユーザがポリシー強制サービスに提供するものである（ポリシー情報も含む）が、グローバルポリシー情報（例えば、ポリシー強制サービスがすでに知っている情報）を再送信する必要はなく、アクセス要求に含まれたポリシー情報を補ったり、オーバーライドしたりするのに用いることもできる。データに対してユーザアクセスを調整する際に、ポリシー強制サーバが用いるグローバルポリシー情報は、あらかじめ決められた業界基準または政府の規定等に基づくこともできる。このようなポリシー情報をユーザがポリシー強制サービスに提供する必要がないのは、ポリシー強制サービスをすでに有しているからである。
【００１５】
ポリシー強制サービスを、管理者の加入契約サービスの管理に用いることもできる（例えば、クレジットカード等を用いた購買トランザクションの処理）。秘密鍵を取得して特定の暗号化データを復号化したいと思うユーザは、適した認証情報を提供することもできる（例えば、ユーザ識別情報、ユーザ年齢情報、ユーザアカウント情報、ユーザセキュリティ許容度、ユーザ会員ステータス、ユーザ性別、ユーザクレジットカードステータス、または他の適したユーザ依存の特性等のユーザ特性に関する情報）。ポリシー情報が述べるポリシー規定を実行してユーザが暗号化データのコンテンツへのアクセスを許可されているかどうか判定する際に、ポリシー強制サービスは、ユーザ特性に関するこの情報を用いることもできる。ユーザが許可されていれば、ユーザに必要な秘密鍵を提供することもできる（例えば、セキュアソケットレイヤ（ＳＳＬ）経路等の安全な通信経路を介する）。
【００１６】
一旦、ユーザが秘密鍵を取得したならば、ユーザは、識別情報に基づく復号化エンジンを用いて、暗号化データを復号化することにより、暗号化されていない形式のデータにアクセスして用いることもできる。識別情報に基づく復号化エンジンを、ユーザの装置で実行する独立型ソフトウェアとして備えることもできるし、他のユーザソフトウェアに組み込んだり、これと共に動作したりするように備えることもできる。例えば、映像およびオーディオファイルの再生に適したメディアプレーヤを、ユーザの装置上で実行することもできる。識別情報に基づく復号化エンジン機能をメディアプレーヤに組み込んだり、ユーザがあるコンテンツを再生したり、視聴したりしたい時にメディアプレーヤがこれを自動的に起動したりすることもできる。
【００１７】
本識別情報に基づく暗号化コンテンツ配信アプローチの利点は、各コンテンツ受信者に対して公開秘密鍵対を管理する必要がなく、コンテンツを安全な方法で配信することができる点である。本アプローチでは、１つの公開鍵を用いて、大多数のユーザを規制するポリシーを指定することもできる。秘密鍵を各公開鍵に対して生成するが、公開鍵は、異なるポリシーを実行する際に生成するだけである（例えば、異なる指定の映画または加入契約プランを配信する際）。個別のユーザに対してそれぞれ公開鍵を生成したり、一意の識別情報に基づく暗号化処理を実行したりする必要がない。
【００１８】
一般に、ユーザに公開された秘密鍵を用いて、多数の異なる暗号化データ項目を復号化することもできる（すなわち、１つの秘密鍵を用いて、同じ公開鍵ポリシー情報を用いて暗号化した暗号化データ項目すべてを復号化することもできる）。しかしながら、秘密鍵はポリシーが適切であるという根拠に基づいて公開されているので、ユーザは、ユーザの認証レベルに適した秘密鍵を与えられるだけである。これは、システムの完全性を維持するのに役立つものである。例えば、秘密鍵を取得してＧ指定を含む公開鍵で暗号化した映画のロックを解除するユーザは、Ｒ指定の映画のロックを解除するのにその秘密鍵を用いることはできない（秘密鍵が、このようなＲ指定の映画の暗号化に用いられるＲ指定ベースの公開鍵と一致しないからである）。（この例の）ユーザが復号化できる映画はすべて、Ｇ指定レベルである。別の例として、ユーザが、Ｒ指定の映画をユーザが復号できる秘密鍵を受信した場合は、秘密鍵を用いて別のＲ指定の映画を復号化することもできる。しかしながら、ユーザが第１のＲ指定コンテンツにアクセスできる適切な年齢（例えば、１７歳を越えている）をすでに越えていると確認されているので、ユーザに、ユーザのアクセス権のレベル以外の権利を供給することはない。同時に、システム管理が煩わしくなってしまうことになる、全く別のユーザ固有の公開鍵を用いて、各データを暗号化する必要はない。
【００１９】
本発明のさらなる特徴、その性質および各種の利点については、添付の図面および以下の好適な実施の形態についての詳細な説明から、いっそう明らかになるであろう。
【発明を実施するための最良の形態】
【００２０】
（好ましい実施形態の詳細な説明）
例示の、本発明によるコンテンツをユーザに配信するための識別情報に基づく暗号システム１０を、図１に示す。システム１０は、様々な場所にいるユーザが、識別情報に基づく暗号化およびデータ配信手法を用いて保護したデータを受信できるようにするものである。システムのユーザは、個人、組織、または任意の他の適したもの、またはエンティティとすることができる。ユーザは、対応付けられたユーザデバイスまたは装置２２を有するものである。装置２２は、例えば、パーソナルコンピュータ、ポータブルコンピュータ、メインフレームコンピュータ、ネットワーク接続コンピュータまたは端末、電気通信装置、ハンドヘルドコンピュータまたは携帯情報端末または携帯電話等の計算装置を含むものである。複数のユーザが、同じデバイスを用いることもできる。例えば、ユーザ群が、ローカルエリアネットワークのホストコンピュータに接続した１つのコンピュータ端末を共有して用いることもできる。これらは単に、システム１０のユーザが用いることもできる例示の種類のプラットフォームである。所望の場合には、ユーザ装置２２は、任意の適した電子装置に基づくこともできる。
【００２１】
ユーザ装置デバイスを、通信ネットワーク１２で相互接続することもできる。ネットワーク１２は、例えば、インターネット、ローカルエリアネットワーク、ワイドエリアネットワーク、公衆交換電話網、仮想私設網、ワイヤードネットワーク、ワイヤレスネットワーク、専用通信回線、ネットワークに基づく光ファイバまたはケーブル経路または他のワイヤードまたはワイヤレス経路、または任意の他の適したネットワーク技術を用いて構成したネットワークまたはこのようなネットワークも組み合わせとすることもできる。
【００２２】
各種の計算装置を、ネットワーク１２に接続して識別ベースの暗号化手法の機能をサポートすることもできる。例えば、１つ以上のコンテンツプロバイダ１４に配置された計算装置を用いて、コンテンツを保存して提供することもできる。システム１０を用いて配信するコンテンツは、メディア（例えば、デジタル映像またはオーディオ）、ビジネスレコードデータ（例えば、株式売買データ、電子決済または他の金融レコード、サプライチェーンデータ等）、ソフトウェア（例えば、ゲームまたは他のアプリケーション）、または任意の他の適したデータとすることもできる。コンテンツプロバイダ１４（データプロバイダとも呼ばれる）は、コンテンツに対応付けられた任意の適したエンティティまたは企業とすることもできる。例えば、配信するコンテンツが、映画または歌等のメディアコンテンツの場合は、コンテンツプロバイダ１４は、映画会社またはレコード会社とすることもできる。配信するコンテンツが株式売買トランザクションまたは電子決済アカウントレコードの場合は、コンテンツプロバイダ１４は、銀行または他の金融機関とすることもできる。配信するデータがソフトウェアを含む場合は、コンテンツプロバイダ１４は、ソフトウェア販売店またはデベロッパとすることもできる。
【００２３】
図１では個別にコンテンツプロバイダ１４を示しているが、コンテンツプロバイダ１４の機能（コンテンツの生成、保存、維持および提供）を、１つ以上の実際のエンティティ、または組織、および１つ以上の適したコンピュータ装置の設置施設に分散することもできる。理解しやすいように、図１に示すように、このような分散型エンティティおよび装置の動作について、１つ以上の個別のコンテンツプロバイダという文脈で、初めに説明する。
【００２４】
構成のあるものでは、図１に示すコンテンツプロバイダ１４および他のエンティティの計算装置を用いて、サーバの機能を、クライアントサーバアーキテクチャに備えることもできる。理解しやすいように、本発明では、しばしば、このようなサーバベースの構成という文脈で説明する。これは、しかしながら、単に説明のためだけである。所望の場合には、任意の適した計算装置の構成を用いて、システム１０の情報を配信することもできる。典型的なサーバベースの構成では、１つ以上のコンピュータを用いてサーバの機能を備えている。サーバを、１つのコンピュータまたは複数のコンピュータを用いて構成することもできる。所望の場合には、１つのサーバの機能を、多数の異なる物理位置に分散したコンピュータで備えることもできる。
【００２５】
図１のコンテンツプロバイダ１４および他のエンティティは、通信ネットワーク１２に接続したサーバベースのプラットフォーム等の、適した計算プラットフォームに基づくこともできる。
【００２６】
データ配信の開始を決定する等の、システム１０のアクティビティのあるもの、または暗号化データへのアクセス要求等のユーザアクティビティは、手動操作が関わる（または必要となる）ものもある。
【００２７】
システム１０の他のアクティビティ（ユーザアクティビティを含む）を、自動化または半自動化することもできる。これらのアクティビティは、手動操作がほとんどなく、あるいはまったくなく発生することもできる。単なる一例として、データまたはコンテンツプロバイダ１４を、音楽または映像配信サービスに対応付けることもできる。暗号化通信を用いて、通信ネットワーク１２を介して、暗号化映画または歌をユーザデバイス２２のアカウントを持つユーザに配信しようとするものである。一旦システムを適切に設定してしまえば、配信サービス装置でのオペレータの操作が全く必要ないように、配信処理を自動化することもできる。ユーザが暗号化コンテンツを受信することについても、自動化することもできる。
【００２８】
コンテンツプロバイダ１４からのデータを、データパッケージサービス１６等のデータパッケージサービスに（例えば、電子的に通信ネットワーク１２を介して）提供することもできる。データパッケージサービスは、データをユーザに提供する前に、データを暗号化することもできる。所望の場合には、データパッケージサービス１６が、暗号化されるコンテンツをデータ構造に組み込むこともできる（例えば、この機能がコンテンツプロバイダ１４で前もって行われていなかった場合には）。データ属性は、データに対応付けられたものである。例えば、指定属性は映画コンテンツに対応付けられており、供給者識別はサプライチェーンデータに対応付けられており、アーティストは歌データ等に対応付けられている。複数のデータ属性を、同じデータ項目に対応付けることもできる。例えば、歌データは、リリース日付、アーティスト、タイトル、レコード会社、ジャンル、指定等の、対応付けられた属性を有することもできる。
【００２９】
データパッケージサービスは、データを任意の適したデータ構造の種類のデータ構造に組み込むこともできる。例えば、コンテンツプロバイダ１４が提供した映画の映像コンテンツを、”ｍｏｖｉｅ”の種類のデータ構造に組み込むこともできる。映画データは、例えば、”ｒａｔｉｎｇ=Ｒ”、”Ｄｉｒｅｃｔｏｒ=Ｓｐｉｅｌｂｅｒｇ”、”Ｐｒｉｃｅ＝＄１０．００”等の対応付けられた属性を有する。
【００３０】
データパッケージサービス１６を、任意の適した計算装置を用いて実行することもできる（例えば、パーソナルコンピュータ、メインフレーム、分散型またはネットワーク型のコンピュータの集合、サーバ等）。データパッケージサービス１６のデータパッケージおよび／または暗号化および他の機能を、暗号化サービス１６、または任意の他の適したサービスプロバイダ、またはエンティティ１６により備えることもできる。これらのサービスは、独立型サービスとすることもできるし、他のサービスおよびエンティティに組み込むこともできる。理解しやすいように、このような暗号化サービスについて一般に、ここでは”データパッケージサービス”と呼ぶ。
【００３１】
サービス１６（例えば、データパッケージサービス１６、暗号化サービス１６、または他の適した独立型または一体型サービス）は、識別情報に基づく暗号化エンジンを実行するために用いる計算装置を有するものである。識別情報に基づく暗号化エンジンは、少なくとも２つの入力を有している。ポリシー強制サービス２０から受信した公開パラメータからなる第１の入力と、ポリシー情報からなる第２の入力（いわゆる公開鍵）とである。公開鍵入力は、通常、識別情報に基づく暗号化手法で用いられるユーザ識別情報で行われる。
【００３２】
識別情報に基づく暗号化手法を、多数の異なる暗号アルゴリズムを用いて実行することができる。このような手法の１つは、平方剰余に基づくものである（例えば、”平方剰余に基づく識別情報に基づく暗号化手法（Ａｎ  Ｉｄｅｎｔｉｔｙ  Ｂａｓｅｄ  Ｅｎｃｒｙｐｔｉｏｎ  Ｓｃｈｅｍｅ  Ｂａｓｅｄ  ｏｎ  Ｑｕａｄｒａｔｉｃ  Ｒｅｓｉｄｕｅｓ）”クリフォード・コックス（Ｃｌｉｆｆｏｒｄ  Ｃｏｃｋｓ）、第８回ＩＭＡ国際会議暗号技術およびコーディング（ＩＭＡ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ｃｒｙｐｔｏｇｒａｐｈｙ  ａｎｄ  Ｃｏｄｉｎｇ）、２００１年１２月、王立農業大学（Ｒｏｙａｌ  Ａｇｒｉｃｕｌｔｕｒａｌ  Ｃｏｌｌｅｇｅ）、サイレンスター、英国、を参照）。別の適した手法は、楕円曲線に基づくものである（例えば、”ワイルペアリングからの識別情報に基づく暗号化（Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ  Ｅｎｃｒｙｐｔｉｏｎ  ｆｒｏｍ  ｔｈｅ  Ｗｅｉｌ  Ｐａｉｒｉｎｇ）”ダン・ボネー（Ｄａｎ  Ｂｏｎｅｈ）およびマシュー・フランクリン（Ｍａｔｔｈｅｗ  Ｆｒａｎｋｌｉｎ）、改訂アブストラクト、Ａｄｖａｎｃｅｓ  ｉｎ  Ｃｒｙｐｔｏｌｏｇｙ−Ｃｒｙｐｔｏ２００１、コンピュータサイエンスレクチャーノート、２１３９巻、シュプリンガー出版、２３１−２２９頁、２００１年８月。ダン・ボネーおよびマシュー・フランクリンによる、ｈｔｔｐ：／／ｅｐｒｉｎｔ．ｉａｃｒ．ｏｒｇ／２００１／０９０についても参照のこと）。理解しやすいように、本発明の側面については、しばしば、ボネーおよびフランクリンの楕円曲線インプリメンテーション等の、識別情報に基づく暗号化手法の文脈で説明する。しかしながら、これは単に説明のためだけである。所望の場合には、識別情報に基づく暗号化の任意の適したアプローチをシステム１０とともに用いることもできる。
【００３３】
用いられる特定の種類の識別情報に基づく暗号化手法に関わらず、暗号化手法は一般に、暗号化されるデータの他に、少なくとも２つの入力を用いる。
【００３４】
第１の入力は公開パラメータ情報である（例えば、ボネーおよびフランクリンの研究における公開パラメータＰおよびｓＰである。ただし、ｓは、識別情報に基づく暗号化アルゴリズムで用いられる、いわゆる”マスタシークレット”である）。システム１０では、マスタシークレットを、ポリシー強制サービス２０により維持する。サービス２０は、マスタシークレットを用いて公開パラメータ情報（例えば、パラメータＰおよびｓＰ）を生成することもできる。公開パラメータ情報をデータパッケージサービス１６に提供して、データ構造を暗号化する際に用いることもできる（すなわち、データ暗号化エンジンへの第１の入力として用いる）。
【００３５】
データ暗号化エンジンが用いる第２の入力は、ポリシー情報を含む公開鍵である（例えば、公開鍵は、映画の指定に関する情報または映画の指定から抽出されるが異なる形式の対応する情報を含む。これは、何歳のユーザならこの映画を見ることができるかを命令するものである）。従来の識別情報に基づく暗号化手法を用いて、（例えば）メッセージ送信者とメッセージ受信者との間でのメッセージの暗号化をサポートする場合は、暗号化エンジンは、受信者の識別を識別情報に基づく暗号化エンジンへの入力として利用する。逆に、システム１０のコンテンツ配信手法では、ポリシー情報に基づく公開鍵（Ｑと呼ぶ）を第２の入力として用いる。この第２の入力は、１人のユーザに固有のものではない。
【００３６】
暗号化エンジンに対する第１および第２の入力を、データパッケージサービスが用いてデータを暗号化する（例えば、データ構造のコンテンツ）。次に、暗号化データをユーザデバイス２２のユーザに安全に通信する（例えば、インターネットを介して）。所望の場合には、データを暗号化するのに用いるポリシー情報（例えば、指定例での要件となるユーザ年齢）を、データとともにユーザに供給することもできる（または、適切な対応付けられたポリシー情報に関する情報を、例えばコードでユーザに通信することもできる）。ユーザはまた、特定のグローバルポリシーが実施されているのか暗黙で知る、または知るように期待されている（例えば、１８歳未満のユーザは特定の種類のコンテンツにアクセスできない等）。
【００３７】
暗号化されるデータは、複数のデータ属性を有することもできる。例えば、暗号化される映画が、対応付けられた指定データ属性（例えば、Ｒ）と、対応付けられた映画会社データ属性（例えば、ソニー）とを有することもできる。データを暗号化する際に公開鍵として用いられるポリシー情報は、１つ以上のこのようなデータ属性に基づくものである。ポリシー情報を複数のデータ属性に基づかせる利点は、このアプローチにより、１つのデータ属性しか用いない場合よりも、データパッケージ（暗号化）サービスがデータを保護して、ユーザの種類によってきめ細かく合わせて配信できるようになる（所望の場合には、１つのデータ属性をポリシー情報に基づいて用いることもできるが）。例えば、ポリシー情報を、ｒａｔｉｎｇ=Ｒおよびｓｔｕｄｉｏ=Ｓｏｎｙ等の、映画の複数のデータ属性を用いて生成することもできる。ユーザ認証の間に、ポリシー強制サービスは、この複数の属性ポリシー情報および暗号化データへのアクセス要求をしている任意のユーザの特性に関する情報（例えば、ａｇｅ=３０およびｓｔｕｄｉｏ  ｍｅｍｂｅｒｓｈｉｐ  ｓｔａｔｕｓ＝Ｓｏｎｙ）を用いて、要求ユーザに暗号化データを復号に必要な秘密鍵を抵抗するかどうか判定することもできる。
【００３８】
ユーザは、データパッケージサービスから受信したポリシー情報（または、適切な適応可能なポリシー情報を識別するデータパッケージサービスから受信した情報）を用いて、アクセス要求を生成することもできる。アクセス要求を用いて、ポリシー強制サービスから暗号化コンテンツへのアクセス許可を取得する。特定の暗号化データ項目へのアクセスのアクセス要求が許可されたら、ポリシー強制サービスは、ユーザに適切な秘密鍵を提供して暗号化データ項目を復号化させることもできる。
【００３９】
所望の場合には、ユーザは、アクセス要求に基づいて、データパッケージサービスから受信したポリシー情報を用いることもできる。例えば、ユーザは、受信したポリシー情報をポリシー強制サービスへ転送することもできる。別の例として、ユーザは、ポリシー情報自体全部は含まないアクセス要求を生成することもできる（または、ポリシー情報を全く含まないもの）。しかし、どの公開鍵（および対応するポリシー）およびどの秘密鍵がアクセス要求に対応しているのかポリシー強制サービスに通知するのに十分な情報を含んでいる。アクセス要求（またはユーザとポリシー強制サービスとの間のフォローアップ通信）は、ユーザ特性に関する情報を含むこともできる（例えば、ユーザ年齢、会員ステータス、セキュリティ許容度等）。
【００４０】
特定の形式およびアクセス要求の内容に関わらず、アクセス要求は好ましくは、要求された秘密鍵を識別するのに十分な情報を含んでいる。その結果、アクセス要求は、ポリシー強制サービスが、データの暗号化に用いられた公開鍵に対応する秘密鍵を供給するように命令する。ポリシー強制サービス２０は、アクセス要求を用いて、どのアクセスポリシーをユーザに適用して、ポリシー強制サービスに供給するユーザ特性に関する情報と組み合わせてこのポリシーを用いるか判定して（例えば、年齢情報、クレジットカードステータス、運転免許証番号、会員ステータス等）、ユーザが暗号化データへのアクセスを許可されているかどうか確認する。
【００４１】
ポリシー強制サービスが、ユーザ（例えば、ユーザ特性に関する情報）はポリシーが課すポリシー制約条件を満たしているので、ユーザの暗号化データのコンテンツへのアクセスを許可すると判定した場合には、ポリシー強制サービスは、データを暗号化するのに用いた公開鍵（Ｑ）に対応する秘密鍵（例えば、ボネーおよびフランクリンの研究に記載の種類のシステムで用いられるｓＱ）をユーザに提供することもできる。ユーザは、秘密鍵（例えば、ｓＱ）およびユーザの装置２２で実行する識別情報に基づく復号化エンジンを用いて、暗号化データを復号化することにより、所望のコンテンツにアクセスすることもできる。あるポリシー情報（例えば、法的に規定されるポリシーに基づくグローバルポリシー情報）は、業界でよく知られているので、ユーザまたは他のエンティティがこの情報をポリシー強制サービス２０に転送する必要はない。むしろ、このようなポリシー情報をポリシー強制サービス２０に前もって保存しておくこともできる。グローバルポリシー情報を用いて、公開鍵が表すポリシー情報を補足したりオーバーライドしたりすることもできる。
【００４２】
配信サーバ１８を用いて、データ配信処理を容易にすることもできる。例えば、様々な国々または国内のいろいろな場所での配信サービスは、ダウンロードサービスまたは中間の転送装置として作用する。暗号化コンテンツをユーザに供給する場合。暗号化データを、ユーザの要求により配信サービスからダウンロードすることもできるし、またはユーザにプッシュすることもできる（例えば、ブロードキャスト構成を用いる）。また、暗号化コンテンツを、ハードコピーアプローチを用いて配信することもできる（例えば、ＤＶＤまたはＣＤディスクまたは他の記憶媒体等で暗号化コンテンツを供給する）。所望の場合には、任意の適した技術を用いて、データパッケージサービスが暗号化した暗号化データをユーザに配信することもできる。また、ポリシー情報を、ユーザに暗号化データを用いて提供することができ、または別の通信で供給することもできる。グローバルポリシー情報（例えば、各種指定の映像に対する許可されたアクセス年齢等の情報）をいつでも提供することもでき、ユーザに再送信したり、ユーザがポリシー強制サービス２０に提供したりする必要はない。
【００４３】
システム１０では、識別情報に基づく暗号化エンジン（Ｑ）に対する第２の入力を識別ではなくむしろ公開鍵と呼ぶのは、この第２の入力が個別のユーザに固有のものではなく、多くのユーザに配信するデータを暗号化するのに用いるからである。
【００４４】
公開鍵Ｑを、データに対応付けられた属性から生成することもできる。例えば、データ属性の１つ（例えば、指定＝Ｒ）を公開鍵として用いることもできる。別の例として、複数のデータ属性をともに連結して、Ｑを生成することもできる。一例として、映画の公開鍵Ｑを、”ｓｅｃｕｒｅ−ｖｉｄｅｏ：／／Ｎａｍｅ＝Ｍａｔｒｉｘ；ｄｉｓｔｒｉｂｕｔｏｒ＝Ｐａｒａｍｏｕｎｔ；Ｄａｔｅ＝Ａｕｇ−２００２；Ｒａｔｉｎｇ＝”Ｒ”とすることもできる。
【００４５】
データおよびデータ属性を、データ構造とともにまとめることもできる。例えば、図６に示すように、ＭＰ３ファイルデータ構造は、データ（例えば、音楽データ）および対応付けられた属性（例えばタイトル情報、アーティスト情報、トラック情報等）の両方を含むこともできる。
【００４６】
所望の場合には、データを、コンテンツ（例えば、ビデオファイル）およびコンテンツの属性（例えば、指定、監督、日付、価格等）を含むＸＭＬデータ構造とすることもできる。ＸＭＬベースのフォーマットを用いて属性情報を処理することは、ＸＭＬベースの属性基準が業界で承認されているといった状況では有利である。
【００４７】
所望の場合には、特定のデータの属性を用いてそのデータの公開鍵Ｑを生成する方法を、データタイプ暗号化ポリシー情報を用いて指定することもできる。属性をＸＭＬレコードで維持する場合には、データタイプ暗号化ポリシー情報を用いて、どのＸＭＬレコードエントリを用いて公開鍵を生成して、これらのエントリをどのように用いるか指定することもできる（例えば、特定のエントリを連結する順序等である）。所望の場合には、データタイプ暗号化ポリシー情報自体を、ＸＭＬフォーマットを用いて保存することもできる。
【００４８】
この種類の構成の一例を、図７ａ、図７ｂ、および図７ｃに示す。図７ａに示すように、ＸＭＬフォーマットデータ構造は、部品番号データ、数量データ、地域データ供給者データ等のサプライチェーンデータを含むこともできる。サプライチェーンデータは単に説明のためだけである。所望の場合には、任意の適したデータの種類を、図７ａに示す種類のＸＭＬデータ構造に備えることもできる。
【００４９】
ＸＭＬフォーマットに備えられた例示のデータタイプ暗号化ポリシー情報を、図７ｂに示す。図７ｂの例では、データタイプ暗号化ポリシー情報は、図７ａのＸＭＬデータ構造のデータ構造フィールドをどのように用いてポリシー情報を生成するかを指定する、ＸＭＬフィールドを含んでいる。例えば、図７ｂの供給者フィールドは、ポリシー要件”ｍｕｓｔ−ｂｅ−ａ−ｃｕｓｔｏｍｅｒ−ｏｆ”をどのように図７ａのデータ構造、”ｃｏｍｐａｎｙ＝Ｄｅｌｃｏ”の供給者フィールドに適用するかを指定する。また、図７ｂの地域フィールドは、ポリシー要件”ｍｕｓｔ−ｂｅ−ｉｎ−ｒｅｇｉｏｎ”をどのように図７ａの地域フィールド”ｒｅｇｉｏｎ=ＵＳ”に適用するかを指定する。
【００５０】
ＸＭＬデータタイプ暗号化ポリシー情報を用いて、図７ａのＸＭＬデータ構造属性をどのように用いるかを指定した結果のポリシー情報を、図７ｃに示す。所望の場合には、公開鍵に用いるポリシー情報を、ＸＭＬを用いて提供することもできる（例えば、公開鍵をＸＭＬフォーマット公開鍵とすることもできる）。
【００５１】
システム１０に用いる識別情報に基づく暗号化処理は、２つのステップの処理が必要となる。２つのステップのうちの一方では、識別情報に基づく暗号化を用い、２つのステップのうちのもう一方では、対称鍵アプローチ等の非識別情報に基づくアプローチを用いる。例えば、データコンテンツ（例えば、データ構造のコンテンツ）を直接識別情報に基づく暗号化を用いて暗号化する必要はないが、むしろ、対称鍵を用いて暗号化することもできる。識別情報に基づく暗号化を用いて順に暗号化して、データを対応付けて保存する（例えば、暗号化データを含む暗号化データ構造の一部として）。暗号化対称鍵の受信者は、対称鍵を復号化して、これを用いてコンテンツを復号化することができる。
【００５２】
この場合は、識別情報に基づく暗号化を用いて直接暗号化するのではなく、大量のデータペイロード（例えば、データ構造ビデオまたは他のコンテンツ）を、それ自体が識別情報に基づく暗号化を用いて暗号化された対称鍵を用いて暗号化する。一般に、これにより、埋め込み対称鍵アプローチを用いることなく、識別情報に基づく暗号化を直接用いて全データを暗号化するという利点を備える。なぜなら、対称鍵暗号化／復号化は非常に効率的だからである。システム１０では、これらのアプローチのいずれか（直接または間接の識別情報に基づく暗号化）を基本的に同じやり方で用いるのは、理解しやすいように、データ暗号化アプローチ（１つのステップおよび２つのステップ）をともに、ここでは”識別情報に基づく暗号化”と呼ぶからである。
【００５３】
図１の構成では、暗号化データをユーザに配信する際の支援に用いることもできるデータ配信サービス１８（例えば、サーバに基づく）を、データパッケージサービス１６およびコンテンツプロバイダ１４と別々に示しているが、所望の場合には、コンテンツプロバイダ１４、データパッケージサービス１６、および１つ以上の配信サービス１８を同じ場所に配置したり、それらの機能を適した数の計算装置設置施設またはサービスを用いたりして備えることもできる。
【００５４】
所望の場合には配信サービスにより、ユーザは、コンテンツリストを閲覧して、所望のコンテンツ項目を選択してダウンロードすることができる。また、コンテンツを、スケジュールに従って、サーバ１８を用いて自動的に配信したり、任意の他の適したアプローチを用いて配信したりすることもできる。
【００５５】
識別情報に基づく暗号手法および図１の装置を用いてコンテンツをユーザデバイス２２に配信するステップを、図２、図３、図４、および図５に示す。配信されているコンテンツは、安全なやり方で送信される任意のデジタル情報（例えば、テキスト、グラフィックス、オーディオ、映像、コマンド、実行用コード、データ等）とすることもできる。
【００５６】
図２のステップは、システム１０でポリシー強制サービス２０を設定して用いることに関する。図２のステップ２４で、図１のポリシー強制サービス２０がマスタシークレットｓを取得する。例えば、ポリシー強制サービス２０は、タンパー防止エンクロージャ内に格納した処理装置がサービスでランダムに生成した数字から、マスタシークレットを生成することもできる。また、マスタシークレットをオフサイトで生成して、ポリシー強制サービス２０に送信することもできる。マスタシークレット（しばしば、秘密マスタキーまたはマスタキーとも呼ぶ）は秘密情報である。これをポリシー強制サービス２０が続いて用いて、システムのユーザ２２が暗号化データを復号化する際に用いる秘密鍵を生成して（例えば、ボネーおよびフランクリンの研究に記載の種類のシステムで用いられる秘密鍵Ｑである）、データパッケージサービス１６が配信の前にデータ（例えば、データ構造のデータ）を暗号化する際に用いる公開パラメータ情報（例えば、ＰおよびｓＰ）を生成する。
【００５７】
ステップ２４の間、ポリシー強制サービス２０は、公開パラメータ情報を生成することもできる。例えば、ポリシー強制サービス２０が公開パラメータＰを取得、または生成することもできる。用いられる識別情報に基づく暗号化の指定の種類によるが、他の公開パラメータ情報についても生成することもできる。例えば、ボネーおよびフランクリンの研究に記載の種類の識別情報に基づく暗号化手法の場合は、マスタシークレットｓおよび公開パラメータＰの値を、ポリシー強制サービス２０が用いて、さらに対応する公開パラメータｓＰを生成することもできる。従って、ボネーおよびフランクリンの手法に基づくシステムでは、公開パラメータ情報は、ＰおよびｓＰをともに含むことになる。
【００５８】
ボネーおよびフランクリンの研究に記載の種類のシステムにおけるパラメータＰおよびＳＰは、数字である。一般に、数字、文字、符号、および他の情報を表すこのような手法の間には等価性がある。ある情報（例えば、マスタシークレットまたは公開パラメータ）を、しばしば数字の形式として記述したり、特定の情報（例えば、ポリシー情報として用いることもできるデータ属性）を少なくとも部分的に文字の形式で記述したりすることもある（例えば、指定の形式等）。これらの異なる表現手法の間の固有の等価性のために、文字または符号を数字に変換する技術や、複数の数字またはストリングを１つの数字として表したりする技術や、または他のこのような動作については、ここでは詳細に説明しない。
【００５９】
ステップ２４では、ポリシー強制サービス２０は、公開パラメータ情報（例えば、パラメータＰおよびｓＰ）を、コンテンツを暗号化するデータパッケージサービス１６または任意の他のサービスまたはエンティティ等のデータパッケージサービスが利用できるようにすることもできる。例えば、公開パラメータ情報を、ポリシー強制サービス２０の計算装置を用いて（例えば、サーバ）、通信ネットワーク１２を介して利用できるようにすることもできる。公開パラメータ情報を、宅配業者を通じてデータパッケージサービスに供給することもできる（例えば、ディスケットまたは他の記憶媒体）、等である。公開パラメータ情報（例えば、パラメータＰおよびｓＰ）を、ダウンロード可能な、または前もってインストールしたソフトウェアモジュールまたはパッケージの一部として、データパッケージサービス１６等のサービスに提供することもできる。例えば、公開パラメータ情報（例えば、公開パラメータＰおよびｓＰ）を、データパッケージサービスが用いる識別情報に基づく暗号化エンジンソフトウェアパッケージに組み込んだり、これを用いて提供したりすることもできる。
【００６０】
パラメータＰおよびｓＰ等の公開パラメータを、いっしょに、あるいは別々にデータパッケージサービス１６が利用できるようにすることもできる。パラメータＰおよびＳＰ等のパラメータを別々に配信する場合は、各パラメータを、異なる配信機構を用いて配信することもできる。例えば、Ｐをデータパッケージサービスのソフトウェアに組み込んで、ｓＰをインターネットを介して配信することともできる。また、ＰおよびＳＰを組み合わせて、１つの数字またはパラメータの等価物として生成したり（理解しやすいようにするのと便宜上のため、ここではやはり複数の形式の”パラメータ”を用いて呼ぶ）、細分化したりすることもできる（例えば、３つ以上の公開パラメータのサブパートを生成する）。所望の場合には、公開パラメータＰおよびｓＰを、印刷した郵便物で、ポリシー強制サービス２０からデータパッケージサービス１６に提供することもできる。これらは単に説明のためだけである。所望の場合には、任意の適した技術を用いて、公開パラメータＰおよびＳＰ等の公開パラメータ情報をステップ２６でデータパッケージサービス１６が利用できるようにすることもできる。
【００６１】
一旦、公開パラメータ情報（例えば、パラメータＰおよびｓＰ）をデータパッケージサービス１６に提供したならば、データパッケージサービスは、データを暗号化することもできる（例えば、データパッケージサービスがコンテンツプロバイダ１４から取得したコンテンツを含むデータ構造）。暗号化データを、ユーザ２２に配信することもできる（例えば、データ配信サービス１８および通信ネットワーク１２を介して）。暗号化データのコンテンツへのアクセスするためのアクセス規定を管理するポリシー情報を用いて、データを暗号化する際の入力として用いられ、後からコンテンツにアクセスできるものを決定する際に用いることもできる公開鍵を生成することもできる（すなわち、暗号化されていないバージョンの暗号化データ）。システム１０で用いるポリシー情報のあるものを、世界的に周知のものとすることもできる（例えば、ユーザが１７歳以上でなければならないＲ指定の映画）。他のポリシー情報を、世界中で周知ものとしなくてもよい（例えば、この映画の価格が１０ドルであるとか、どの年齢の人でも見ることができるＧ指定の映画）。ポリシー情報（例えば、公開鍵内のポリシー情報や、世界的に周知でないもの）を、通信ネットワーク１２を介してユーザ２２およびポリシー強制サービス２０に送信することもできる。
【００６２】
特定の暗号化データ項目にアクセスしたいと思うユーザは、ポリシー強制サービスへアクセス要求を生成することもできる。アクセス要求は、ポリシー強制サービスに、そのデータ項目を暗号化するのに用いられた公開鍵に対応する秘密鍵をユーザに提供するように命令する（ユーザが認証されれば）。アクセス要求は、公開鍵およびその公開鍵が表すポリシー情報（または、当該公開鍵をポリシー強制サービスに対して識別する情報を含むこともできる）を含むこともでき、これを、通信ネットワーク１２を介してポリシー強制サービス２０に提供することもできる。
【００６３】
ステップ２８では、ポリシー強制サービスが、ユーザがデータパッケージサービス１６から受信した暗号化データの特定の項目のコンテンツへのアクセスを希望するユーザからのアクセス要求を受信することもできる。アクセス要求は、実際上は、ユーザがアクセス要求を介して提供または識別中で、且つ、データパッケージサービスの識別情報に基づく暗号化エンジンがデータ構造を暗号化するのに用いた公開鍵に対応する秘密鍵のコピーを要求する、ユーザからの要求である。
【００６４】
ステップ３０では、ポリシー強制サービス２０が、ポリシー強制サービスが知っているマスタシークレットｓおよび公開鍵（ポリシー情報）Ｑを用いて、そして、識別情報に基づく暗号化アルゴリズムを用いて、秘密鍵（ｓＱ）を生成することもできる。ステップ３０の間、ポリシー強制サービスは、公開鍵のポリシー情報を用いて、要求中のユーザが秘密鍵を受信する資格があるかどうか判定することもできる。例えば、公開鍵（ポリシー情報）が指定であれば（例えば、指定=Ｒ）、ポリシー強制サービス２０は、秘密鍵をユーザに提供する前に、ユーザがＲ指定コンテンツの視聴を許可されているかどうか確認しようとする。例えば、ポリシー強制サーバが、ユーザの年齢を確認して、ユーザの年齢をＲ指定コンテンツに対応付けられた年齢と比較することもできる（年齢情報を公開鍵内のポリシー情報の一部とすることもできるし、ポリシー強制サービスがすでにわかっている関連グローバルポリシー情報とすることもできる）。ポリシー強制サービスが維持するグローバルポリシー情報をポリシー強制サービスが用いて、公開鍵に記述したポリシー情報を補足したりオーバーライドしたりすることもできる（例えば、制約条件をさらに追加することもできる）。アクセス要求がはっきりと必要なポリシー情報すべてを含んでいない時には、十分な情報をポリシー強制サービスに提供して当該ポリシーを識別するというよりもむしろ、ルックアップテーブルまたは他の適したデータベース構成をポリシー強制サービスが用いて、ポリシー強制サービスが適切な公開鍵および対応するポリシーを識別できるようにすることもできる（従って、要求された適切な秘密鍵を識別する）。
【００６５】
ステップ３０の確認処理の間、ポリシー強制サービス２０は、ユーザについての特定の情報を確認する必要がある（例えば、年齢、加入契約プラン、場所等）。ユーザ情報を、任意の適したストリング、数字、符号等で表すこともできる。秘密鍵を、データパッケージサービス１６で暗号化する間に用いられる公開鍵を用いて、自動的に現在時間を連結することにより、システム１０で自動的に失効することもできる（例えば、今年の現在の日、年、現在の月、または任意の他の適した時間関連の日付スタンプ情報）。理解しやすいように、公開鍵について、一般に、ここでは値Ｑで説明する。適した数学的関数を用いて、公開鍵（ポリシー情報）のストリング表現から、または任意の他の適した表現から、ポリシー強制サービス２０で用いる識別情報に基づく暗号化秘密鍵生成アルゴリズムに対する入力として用いるのに適したＱの値を決定することもできる。
【００６６】
ユーザのアクセス許可をステップ３０で確認する際に、任意の適した手動または自動の認証技術をポリシー強制サービス２０が用いることもできる。例えば、ユーザ情報を含むレターを、ユーザの名入り便せんで秘密鍵生成器１６にファックスするか郵送するかユーザに尋ねることもできる。これを、スタッフまたは秘密鍵生成器の自動装置が信憑性を調べる。別の例として、生物測定認証技術（例えば、指紋分析、眼球スキャン、掌紋または声紋分析、顔面認識方法、または直接認証チェック）を用いることもできる。認証処理にユーザとポリシー強制サービス２０との間で電子通信が必要な場合は、ユーザとポリシー強制サービス２０との間の通信経路を保護する必要がある。信頼できないものが利用できないようになっていれば、通信経路は保護されていると考えることもできる。例えば、ポリシー強制サービス２０とユーザ２２との間のネットワークを、ポリシー強制サービス２０または別の信頼できる権威者により制御されている専用回線とすることもできる。別の例として、保護されたチャネルを、保護されたウェブブラウザリンクを用いてサポートすることもできる（例えば、セキュアソケットプロトコルを用いる）。ユーザについて適切な情報を収集して、ポリシー強制サービス２０が適切なポリシー規定を適用して、（暗号化データに対応付けられた公開鍵ポリシー情報から）ユーザの認証を確認して、ステップ３０で秘密鍵を受信した後、ステップ３２で秘密鍵をユーザに提供することもできる（例えば、ネットワーク１２を介して、セキュアソケットレイヤ（ＳＳＬ）リンク等の保護された経路を用いる）。これは単に、秘密鍵をユーザに提供する例示の技術である。所望の場合には、任意の適した技術を用いることもできる。
【００６７】
ポリシー強制サービス２０がステップ２６で秘密鍵を受信者に提供した後、ステップ２８で処理を継続することもできるので（ライン３４で示す）、ポリシー強制サービス２０は、他のユーザが提供する公開鍵に基づいて、他のユーザから秘密鍵の要求をさらに受信することもできる。
【００６８】
システム１０でデータパッケージサービス１６を用いる際に必要なステップについて、図３に示す。ステップ３６で、データパッケージサービス１６は、識別情報に基づく暗号化公開パラメータ情報を取得することもできる（例えば、公開パラメータＰおよびｓＰ）。この情報を、ポリシー強制サービス２０に供給することもできる。公開パラメータ情報を、任意の適した技術を用いて供給することもできる。例えば、サービス１６に、電子的にネットワーク１２を介して公開パラメータ情報を提供したりすることもできるし、または公開パラメータ情報を、識別情報に基づく暗号化エンジンソフトウェアの一部として提供したりすることもできる。
【００６９】
ステップ３８では、データパッケージサービス１６が暗号化されるデータを取得することもできる。メディア、ソフトウェア、テキスト、グラフィックス、金融レコードまたは他のデータ等の、任意の適したコンテンツを、システム１０を用いて配信することもできる。一例として、デジタル版の映画を、衛星アップリンク（ネットワーク１２の一部）を用いてデータパッケージサービス１６に提供したり、または映画ファイルを含むＣＤまたはＤＶＤをサービス１６に提供したりすることもできる。
【００７０】
ステップ４０では、所望の場合には、データパッケージサービス１６が特定の種類のデータ構造を生成することもできる（例えば、”ｍｏｖｉｅ”タイプ）。映画のコンテンツを、データ構造に組み込むこともできる。属性をデータに対応付けることもできる。例えば、このような属性が、ポリシー情報を定義することもできる。一例として、映画の属性は、映画のタイトル、監督、上映時間、公開年、指定（例えばＧ、ＰＧ、ＰＧ−１３、Ｒ、Ｘ等）、価格等を含む。データに対応付けられた属性を、（少なくとも初めは）データと別々に維持することもできるし（例えば、映画を含むＶＣＲテープの外側に指定ラベルを貼ってある場合など）、または暗号化されるコンテンツとともにデータ構造に組み込むこともできる（例えば、トラック、アーティスト、タイトル、および他の属性を、歌のデータとともにＭＰ３データ構造に組み込む場合）。
【００７１】
属性のいくつかまたはすべて、およびデータの使用を管理する他の適切な情報を、ポリシー情報として用いることもできる。このポリシー情報を、公開鍵Ｑを生成してデータ構造を暗号化する際に、データパッケージサービスが用いることもできる。映画に適した公開鍵の一例として、映画の指定とすることもできる。（例えば、ｒａｔｉｎｇ=Ｒ）。所望の場合には、ポリシー関連の属性をさらに用いて公開鍵を生成することもできる。一例として、多数のデジタル映像の属性をともに連結して、公開鍵Ｑを生成することもできる（例えば、”ｓｅｃｕｒｅ−ｖｉｄｅｏ：／／Ｎａｍｅ=Ｍａｔｒｉｘ；Ｄｉｓｔｒｉｂｕｔｏｒ=Ｐａｒａｍｏｕｎｔ；Ｄａｔｅ=Ａｕｇ−２００２／Ｒａｔｉｎｇ=”Ｒ”等の属性。所望の場合には、暗号化されるデータを、ＸＭＬデータ構造等のデータ構造に組み込むこともできる。データパッケージサービス１６が公開鍵Ｑとして用いるポリシーデータ（属性）を手動で選択したり、自動的に選択したりすることもできる。所望の場合には、データタイプ暗号化ポリシー情報を用いて、Ｑを生成する際に、どの属性とポリシー情報とを用いるか定義することもできる。１つのセットの属性を１つのタイプのデータを暗号化するのに用いることもできるが、（例えば、映画タイプのデータ構造内のデータを暗号化する場合）、別のセットの属性を用いて他のタイプのデータを暗号化することもできる（例えば、歌のタイプのデータ構造内のデータを暗号化する場合）。所望の場合には、データタイプ暗号化ポリシー情報を、ＸＭＬフォーマットで提供することもできる。
【００７２】
ステップ４０で、データパッケージサービス１６で識別情報に基づく暗号化エンジンを用いてデータを暗号化することもできる。識別情報に基づく暗号化エンジンは、識別情報に基づく暗号化アルゴリズムを実行して、暗号化されていない情報を、暗号化情報に基づく公開パラメータ情報および識別情報に変換する（図１のシステム１０という文脈で公開鍵と呼ぶ）。特に、識別情報に基づく暗号化エンジンは、識別情報に基づく暗号化公開鍵Ｑおよび識別情報に基づく暗号化公開パラメータ情報を、暗号化データの他に、識別情報に基づく暗号化エンジンに対する第１および第２の入力として用いることもできる。
【００７３】
ステップ４２で、得られる暗号化データ（所望の場合には、選択として公開鍵Ｑおよび他の適したポリシーデータ）を、ユーザが利用できるようにすることもできる。例えば、暗号化データ構造を、配信サービス１８を用いて通信ネットワーク１２を介して、ユーザ装置２２に配信することもできる。また、ＣＤおよびＤＶＤ等の記憶媒体を用いて、暗号化データ構造を配信することもできる。データが暗号化されているので、ピアツーピア配信処理を用いることもできる（例えば、１人のユーザ２２が、通信ネットワーク１２を介して、受信した暗号化データ構造またはデータ項目を別のユーザ２２に電子メールで送信したり、別の方法で送信したりすることもできる）。ユーザ２２は、暗号化データをダウンロードすることもできる（例えば、配信サービス１８上で提供するリポジトリから）。また、もともとユーザデバイス２２を受け取った場合、ユーザは、暗号化データを受信することもできる（例えば、暗号化データがユーザデバイス２２のハードウェアにすでに格納されていて、ユーザがユーザデバイスを受け取った場合）。一旦、ステップ４２で暗号化データをユーザが利用できるようにしたなら、ライン４４で示しているように、ステップ３８でさらにコンテンツを取得することもできる（すなわち、処理を継続することもできる）。
【００７４】
ユーザが（暗号化されていない版の）暗号化データのコンテンツに対するアクセスを取得できるようにさせる例示のステップを、図４に示す。ステップ４６で、システムを設定することもできる。例えば、ユーザの装置がアクセス機能および対応付けられたパラメータを実行するのに用いるソフトウェアを、ステップ４６で取得することもできる。必要なソフトウェアを、ユーザの装置に前もってインストールしたり、ダウンロードしたり、またはディスケット、ＣＤ、または他の記憶媒体を介して取得することもできる。ソフトウェアを、特定の機関（例えば、銀行）が提供するソフトウェアパッケージとすることもできるし、または販売店または汎用ソフトウェア製造業者（例えば、メディアプレーヤソフトウェアのプロバイダ）が提供するソフトウェアとすることもできる。暗号化データがデジタル映画ファイルの場合は、例えば、ソフトウェアは、デジタル加入映画サービスに対応付けられたものが提供する映像ソフトウェアまたはメディアプレーヤソフトウェアである。映像ソフトウェアを用いて、配信サーバ１８が提供するリストに列挙された各種のタイトルから所望の映画を選択する処理を行うこともできる。映像ソフトウェアを用いて、暗号化された版の映画をダウンロードすることもできる。次に、映像ソフトウェアをユーザが用いて、アクセス要求を生成して（適切な公開鍵を含む）、ポリシー強制サービスから適切な対応する秘密鍵を受信して、映画を復号化してユーザが視聴する処理を行うこともできる。
【００７５】
ステップ４６でシステムを設定した後、ユーザは、アクセスする暗号化データを取得することもできる。例えば、ユーザは、１つ以上の配信サービス１８または他の適した装置を介して、データパッキングサービス１６から暗号化データを取得することもできる。また、暗号化データについてもユーザのハードドライブに前もって格納することもできる。この場合は、暗号化データの取得処理には、ローカルディスクアクセス機能が必要となる。ポリシー情報（例えば、公開鍵Ｑにふくまれる等の情報）を、暗号化データとしてユーザに動じに（または別の時に）提供することもできるし、ユーザの装置に前もって格納することもできる（例えば、秘密鍵をポリシー強制サービスに提供する時間の場合は、ユーザがアクセスするテーブル内）。これにより、認証および鍵生成処理を簡単にすることができるのは、ユーザが単に、当該ポリシー情報をポリシー強制サービス２０に鍵要求の一部として転送することもできるからである。
【００７６】
ステップ５０では、ユーザは、手動または自動的に（映像再生ソフトウェア等の適切なユーザソフトウェアを用いて）鍵要求を生成することもできる（すなわち、ユーザは、ポリシー強制サービス２０に、暗号化データ構造を復号化する適切な秘密鍵を生成してユーザに提供するように照会することもできる）。前もって格納したグローバルポリシー情報を除いた、公開鍵／ポリシー情報をすべて含む鍵要求、（いわゆる、システム１０のユーザ全員に影響を与えるので）、または、でなければ、どのポリシーを適用して、どの秘密鍵を生成するか判断できるように、適切な情報を含んだかぎ要求を、ポリシー強制サービス２０（例えば、ネットワーク１２を介して）送信することもできる。鍵要求処理の間、ポリシー強制サービス２０は、データについて適切なポリシー情報を用いて（すなわち、ユーザが識別するか、または実際にポリシー強制サービスおよび／またはグローバルまたは前もって格納したポリシー情報等に転送した、データに対応付けられたポリシー情報）、ユーザにコンテンツへのアクセスを許可するかどうか判定する。一例として、ポリシー情報は、ユーザの許可年齢幅を指定する情報を含むこともできる。例えば、ポリシー情報を、ユーザの年齢１７歳以上のものだけが対応付けられた暗号化データのコンテンツにアクセスできると命令する映画指定Ｒとすることもできる。別の例として、特定の加入契約タイプの全ユーザ（例えば、”シルバープラン”）のアクセスを許可することもできる。これらは単に、用いられるポリシータイプを説明するためだけのものである。所望の場合には、異なる、さらに複雑なポリシーを用いることもできる。また、ステップ５０の要求処理には、ポリシー強制サービスがユーザ識別を認証することが必要とすることもできる（あるいは、少なくとも年齢等のユーザ特性）。所望の場合には、任意の適した検証技術を用いることもできる。また、ユーザがポリシー強制サービスと通信する間に、さらに情報を提供するかユーザに紹介することもできる。このような追加の情報は、例えば、ユーザのクレジットカード番号等の支払い情報を含むこともできる（必要の場合には、例えばポリシー情報から）。
【００７７】
ユーザが適切な情報をポリシー強制サービス２０に提供して、ポリシー強制サービスがポリシー情報およびユーザ情報に記載されたポリシーを用いてユーザが暗号化データにアクセスすることを認証されていると正常に確認した場合は、ポリシー強制サービス２０は、秘密鍵をユーザに発行して、ユーザはステップ５２でこの鍵を取得することもできる。秘密鍵（ｓＱ）は、データを暗号化するのに用いて、アクセス要求が識別した、あるいは提供した、公開鍵Ｑに対応する。従って、ステップ５２で、ユーザは、秘密鍵ｓＱを用いて暗号化データを復号化して、データのコンテンツにアクセスして用いることもできる。暗号化映画についての例示の場合では、例えば、ユーザは、ユーザの映像ソフトウェアを用いて映画を復号化して再生することもできる。鍵要求処理の詳細についてはユーザから隠すことができるので、ユーザは、ユーザのソフトウェアで要求したその鍵について知る必要はない。ライン５４で示すように、ユーザは、ステップ４８から開始する処理を繰り返すことにより、さらにコンテンツの取得を継続することもできる。
【００７８】
システム１０を用いて配信するデータは一般に、任意のフォーマットとすることもできる。例えば、デジタル映画をＭＰＥＧファイルとして保存することもでき、歌をＭＰ３ファイルとして保存することもできる、等である。所望の場合には、データを、ＸＭＬフォーマットを用いたデータ構造等のデータ構造に保存することもできる。（データコンテンツはやはり、ＭＰＥＧまたはＭＰ３ファイルフォーマットである。）
特定のフォーマット情報を用いて、続いてデータを暗号化するのに用いられる公開鍵Ｑを生成する際に、どのデータ属性（例えば、指定、またはある他の属性、または属性の特定の組み合わせ）を用いるか判定することもできる。このいわゆるデータタイプ暗号化ポリシー情報は、関連する特定のデータタイプに固有のものとすることもできる。例えば、データタイプ暗号化ポリシー情報を用いて、１つのセットのポリシー情報を用いて全映画を暗号化するように命令したり、別のセットのポリシー情報を用いて歌を暗号化するように命令したりすることもできる。所望の場合には、データタイプ暗号化ポリシー情報自体をＸＭＬフォーマットで提供することもできる。データおよびデータタイプ暗号化ポリシー情報をともにＸＭＬを用いて提供する例示のシナリオについて、図７ａ、７ｂおよび７ｃとともに上記で述べている。
【００７９】
ＸＭＬデータタイプ暗号化ポリシー情報を用いてどのようにデータを暗号化するか判定することについての例示のステップを、図５に示す。ステップ５６では、サービス１６の識別情報ベースの暗号化エンジンが、暗号化するデータ（例えば、データ構造内のデータ）を取得および／または生成することもできる。このデータは、コンテンツ（例えば、映画または歌）を含むこともできるし、データタイプ情報（例えば、”ｍｏｖｉｅ”または”ｓｏｎｇ”）を含むこともできるし、他の対応付けられた属性（例えば、Ｇ、ＰＧ、Ｒ、およびＸの取り得る値から選択したその対応する属性値”Ｒ”の”指定”を付けられた属性）を含むか、あるいは有することもできる。コンテンツは一般に、コンテンツプロバイダ１４が提供する。データの他の情報（例えば、データタイプおよび他の属性情報）を、データパッケジャー、コンテンツプロバイダ、または他の適したエンティティまたはこのようなエンティティの組み合わせが提供することもできる。
【００８０】
ステップ５８では、データパッケージサービス１６が、データタイプ暗号化ポリシー情報を取得することもできる。この情報を、コンテンツプロバイダから取得することもできるし、データパッケージサービス１６のスタッフが生成することもできるし、または任意の他の適したエンティティが生成することもできる。例えば、データ構造タイプ暗号化ポリシー情報は、データタイプ”映画”として、属性”ｒａｔｉｎｇ”は、公開鍵Ｑを生成する際に用いられるたった１つの属性であることを指定することもできる。別の例として、データタイプ暗号化ポリシー情報は、データタイプ”ｓｏｎｇ”として、２つの属性”ａｒｔｉｓｔ”および”ｐｒｉｃｅ”をともに連結してＱを生成することを指定することもできる。これらは単に、データタイプ暗号化ポリシー情報の説明のための例である。所望の場合には、任意の適したデータタイプ暗号化ポリシー情報を用いることもできる。
【００８１】
データタイプ暗号化ポリシー情報を、ＸＭＬフォーマットまたは任意の他の適した形式で提供して維持することもできる。
【００８２】
ステップ６０では、データパッケージサービス１６が、データタイプ暗号化ポリシー情報およびデータに対応付けられた属性情報を用いて公開鍵Ｑを生成することもできる。次にデータパッケージサービスは、識別情報に基づく暗号化エンジンを用いて、データおよびその対応付けられたコンテンツを暗号化することもできる。識別情報に基づく暗号化エンジンは、入力として、ポリシー強制サービス２０が提供した公開パラメータ情報（Ｐ、ｓＰ）およびポリシー情報（Ｑ）から生成した公開鍵を用いることもできる。
【００８３】
上記は、本発明の原理を単に説明するためだけのものであり、本発明の範囲および精神から逸脱することなく、当業者が各種の変更を行うことができる。
【図面の簡単な説明】
【００８４】
【図１】図１は、本発明による、コンテンツをユーザに配信するための識別情報に基づく暗号化システムを説明する図である。
【図２】図２は、図１に示す本発明によるシステムを利用した、ポリシー強制サービスを用いて暗号化コンテンツ配信をサポートする際のステップを説明するフローチャートである。
【図３】図３は、本発明によるパッケージサービスおよび配信サービスを用いてデータ構造を暗号化して配信する際のステップを説明するフローチャートである。
【図４】図４は、本発明による図１に示すシステムでユーザに暗号化データを復号化させる際のステップを説明するフローチャートである。
【図５】図５は、本発明によるデータ構造を暗号化する際のステップを説明する図である。
【図６】図６は、本発明による、音楽データコンテンツおよび対応するデータ属性をどのように１つのデータ構造にまとめるかを示す、説明のためのＭＰ３ファイルを示す図である。
【図７】図７ａは、本発明による説明のためのデータ構造（ＸＭＬフォーマット）を示す図である。図７ｂは、本発明によるデータ構造のデータを暗号化する際に用いる公開鍵を生成する時に、図７ａに示すデータのデータ属性をどのように用いるか決定するのに用いられるデータタイプ暗号化ポリシー情報（ＸＭＬフォーマット）を説明する図である。図７ｃは、本発明による図７ｂに示すデータタイプ暗号化ポリシー情報に基づく図７ａのデータ構造属性から生成される公開鍵（これはＸＭＬフォーマットで提供）を示す図である。
【図１】
0004619354.tif 000002
【図２】
0004619354.tif 000003
【図３】
0004619354.tif 000004
【図４】
0004619354.tif 000005
【図５】
0004619354.tif 000006
【図６】
0004619354.tif 000007
【図７】
0004619354.tif 000008