JP2006338249A - コンテンツ保護装置及びコンテンツ保護解除装置 - Google Patents

Abstract

【課題】ＤＲＭ（デジタル著作権管理）システムへの対応機能を持たない下位システムのファイルを、ＤＲＭシステムで保護する。
【解決手段】アプリケーション１２，２２はパスワード保護機能を有するが、ＤＲＭには対応していないとする。カプセル化ツール１４は、アプリケーション１２のファイルがカプセル化対象として与えられた場合、パスワードを自動生成し、そのパスワードをＤＲＭ権利発行サーバ３０から与えられた鍵で暗号化し、暗号化したパスワードとその暗号を復号する鍵を示す鍵ＩＤとをそのファイルの属性データに設定し、アプリケーション１２にそのファイルをそのパスワードで保護させる。
【選択図】図１

Description

本発明は、デジタルコンテンツの権利保護のための技術に関する。

近年、画像や映像、文書、音声、ゲームプログラムその他のソフトウエアなど、様々なコンテンツが様々なコンテンツ提供者からユーザに提供されている。そして、これらのコンテンツの提供に際しては、コンテンツ提供者の著作権等の権利を守るために、ＤＲＭ（デジタル著作権管理）の技術が利用されている。

ＤＲＭ技術の代表的なものに電子チケットを利用したシステムがある。このシステムでは、コンテンツは暗号化等により利用制限が掛けられた状態でユーザに配布される。このような利用制限は「カプセル化」とも呼ばれる。ユーザはカプセル化されたコンテンツ（以下単にカプセルと呼ぶ）を利用する場合には、利用制限解除のために必要な鍵等の情報を含んだ電子チケットを別途入手する。電子チケットは、ライセンスや利用権情報などと呼ばれることもある。ユーザは、カプセルを利用する場合、権利管理サーバにアクセスし、ユーザ認証やチケット購入処理などの処理により電子チケットを入手する。特許文献１には、このような電子チケットを用いたＤＲＭシステムの一例が示される。

電子チケットを用いたＤＲＭを実現する場合、一般には、カプセルを取り扱うアプリケーションが、そのコンテンツに施された暗号化の解除や利用制限に応じた操作制限など、利用制限を取り扱う機能（ＤＲＭ機構）を備えていなければならない。

ただし、プラグイン(plug-in)機構を備えたアプリケーション（例えば米国adobe社のAcrobat（商標））の場合は、アプリケーション本体に対しＤＲＭ機構をプラグインとして後で組み込むこともできる。特許文献１には、ＤＲＭ機構をアプリケーションに組み込むのに、プラグイン技術を用いる点が示されている。また、特許文献２にも、電子チケット方式のＤＲＭの一例が示される。

特開平１１−０３１１０５号公報 特開平１０−２４７９０５号公報

しかしながら、ＤＲＭ機構を備えず、かつプラグイン機構も備えないアプリケーションに対しては、電子チケット方式の保護の仕組みは適用できなかった。例えばマイクロソフト社のワードプロセッサアプリケーション「Ｗｏｒｄ」や表計算アプリケーション「Ｅｘｃｅｌ」などは、ＤＲＭ用のプラグイン機構を備えていないため、電子チケット方式のＤＲＭによるデータ保護が適用できなかった。

また、ＤＲＭシステムは既に数多く提案されており、稼働しているものも存在する。このような既存システムを別のＤＲＭシステム（前者に対して上位のＤＲＭである）で管理できると便利な点がある。

例えば、複数のアプリケーションが、互いに異なる既存ＤＲＭシステムにそれぞれ対応しているとする。この場合、各アプリケーションの作成・編集したコンテンツファイルは、それぞれ別々のＤＲＭシステムで管理される。電子チケットの発行条件も個々のＤＲＭシステムにそれぞれ登録しなければならない。それに対して、これら複数の既存システムを、アドオンした上位ＤＲＭシステムで一元管理すれば、そのような煩わしさを低減できる。このようにＤＲＭシステムを別の上位ＤＲＭシステムで管理するための仕組みは、従来知られていない。

本発明の一つの側面では、コンピュータシステムを、コンテンツ保護機能を備える下位システムによるコンテンツの保護を解除するための解除用情報を、電子チケット方式の上位著作権管理システムから取得した鍵を用いて暗号化することで、暗号化情報を生成する暗号化手段、前記コンテンツを前記下位システムに渡して前記コンテンツ保護機能による該コンテンツの保護を実行させ、その結果得られる保護済みコンテンツを前記下位システムから取得し、該保護済みコンテンツと前記暗号化情報とを対応付けて配布用データを作成し出力するコンテンツ加工手段、として機能させるためのプログラムを提供する。

本発明の別の側面では、コンピュータシステムを、下位システムのコンテンツ保護機能を用いて保護された保護済みコンテンツと、該保護済みコンテンツの保護を解除するための解除用情報を上位著作権管理システムが発行した鍵で暗号化することで得られた暗号化情報と、を含んだ配布用データを取得する手段、前記上位著作権管理システムとの間で、前記暗号化情報の復号のための電子チケットを取得するための認証処理を実行する手段、前記認証処理が成功して前記電子チケットが得られた場合に、前記配布用データに含まれる前記暗号化情報を前記電子チケット用いて復号することにより、前記解除用情報を求める復号手段、前記復号手段により求められた解除用情報を用いて、前記保護済みコンテンツに対する前記下位システムによる保護を解除する解除手段、前記解除手段により保護が解除されたコンテンツをユーザに提示する提示手段、として前記コンピュータシステムを機能させるためのプログラムを提供する。

以下、図面を参照して、本発明を実施するための最良の形態（以下「実施形態」と呼ぶ）について説明する。

まず、コンテンツ保護機能を備えたアプリケーション・ソフトウエア（以下単にアプリケーションという）に対し、電子チケット方式のＤＲＭ（著作権管理）システムによるコンテンツ保護方式を適用する実施形態について説明する。なお、本実施形態において、電子チケットとは、対応するコンテンツに施された保護を解除するのに必要な鍵、或いはその鍵を求めるのに必要な情報の少なくとも一部を含んだデータである。

図１に示すように、本実施形態のシステムは、コンテンツ提供者側装置１０，ユーザが操作するユーザＰＣ（パーソナルコンピュータ）２０，ＤＲＭ権利発行サーバ３０及びＤＲＭ権利管理サーバ４０を備える。これら各装置１０〜４０は、インターネットやローカル・エリア・ネットワークなどのネットワーク５０を介して相互に接続されていることが好適である。ただし、これは必須のことではなく、例えばＣＤ−ＲＯＭなどの媒体を介してそれら各装置１０〜４０の間で必要な情報の受け渡しが行われてもよい。

ＤＲＭ権利発行サーバ３０及びＤＲＭ権利管理サーバ４０は、電子チケット方式のＤＲＭシステムを構成する要素である。このうちＤＲＭ権利発行サーバ３０は、保護対象のコンテンツのカプセル化のための鍵の発行や、カプセルを利用可能とするための電子チケットの発行を行う。また、ＤＲＭ権利管理サーバ４０は、ユーザに対する電子チケットの発行管理を行うサーバである。ＤＲＭ権利管理サーバ４０は、電子チケットの発行を要求したユーザに対してユーザ認証を行い、この認証が成功した場合にＤＲＭ権利発行サーバ３０が発行した電子チケットをユーザに提供する。このようにＤＲＭシステムをＤＲＭ権利発行サーバ３０及びＤＲＭ権利管理サーバ４０とに分けているのは、電子チケットの発行と、ユーザ認証を含むチケット発行管理とを別々に管理するためであるが、このような別管理を行わない場合は、それら両サーバの機能を１つのサーバにまとめてもよい。これらＤＲＭ権利発行サーバ３０及びＤＲＭ権利管理サーバ４０、またはそれらをまとめた１つのＤＲＭシステムとしては、例えば上記特許文献１及び２に示したものや、マイクロソフト社のWindows Media(登録商標) Rights Managerなど、公知のものを用いることもできる。

なお、ＤＲＭシステムには、よく知られるようにオンライン型とオフライン型がある。オンライン型は、コンテンツに対するユーザの利用権の確認が必要となる都度（例えばユーザがコンテンツのファイルのオープンを指示したとき等）に、ユーザＰＣがＤＲＭシステムから電子チケット（ライセンスとも呼ばれる）を取得する方式である。これに対しオフライン型は、ＤＲＭシステムから発行された電子チケットをユーザＰＣ上に保存して繰り返し利用できるようにしたものである。オフライン型の例には本出願人が開発したアクセスチケット方式があり、前述の特許文献１及び２はこのアクセスチケット方式の一例である。図１の例におけるＤＲＭ権利発行サーバ３０及び権利管理サーバ４０は、オンライン型、オフライン型のいずれでもよい。以下、オフライン型の場合を主たる例として説明を進める。

コンテンツ提供者側装置１０は、コンテンツ提供者がユーザに対して提供するカプセルを作成するのに用いるコンピュータシステムである。コンテンツ提供者側装置１０には、コンテンツを作成又は編集するためのアプリケーション１２がインストールされている。

アプリケーション１２は、例えばワードプロセッサ、表計算、図面作成などのためのソフトウエアである。アプリケーション１２は、コンテンツに対しパスワード保護を施して保存する機能を備えている。すなわちアプリケーション１２は、例えば作成又は編集されたコンテンツの保存の指示があった場合に、パスワード入力のためのユーザインタフェース（以下「ＵＩ」と略す）画面を提供し、この画面に対し入力されたパスワードによりそのコンテンツに対する保護を掛けた上で、そのコンテンツのファイルを保存する。このコンテンツを取り扱うアプリケーション１２（及び２２）は、コンテンツファイルのオープンが指示された場合、そのファイルにパスワード保護が施されていれば、パスワードの入力を促すＵＩ画面を提示し、この画面に対して正しいパスワードが入力された場合にのみその保護を解除してファイルをオープンする。また、アプリケーション１２は、このようなパスワード保護及び解除の機構を呼び出すためのＡＰＩ（アプリケーション・プログラム・インタフェース）を備えており、これらＡＰＩを介して他のプログラムからパスワード保護付の保存指示や、パスワード保護付ファイルのオープン指示を受け付け、その指示に応じた処理を実行する。この種のパスワード保護機構を備えたアプリケーション１２（及び２２）としては、マイクロソフト社の「Ｗｏｒｄ」や「Ｅｘｃｅｌ」などがよく知られている。

図では、アプリケーション１２を１つ示しただけだが、コンテンツ提供者側装置１０はパスワード保護機能を有するアプリケーション１２を複数有していてもよい。

カプセル化ツール１４は、コンテンツ提供者がユーザに提供するコンテンツをカプセル化を施い、カプセルを生成するためのソフトウエアである。このカプセル化は、ＤＲＭ権利発行サーバ３０及びＤＲＭ権利管理サーバ４０によるＤＲＭの枠組みの下でのコンテンツ保護のためのものである。カプセル化ツール１４は、このカプセル化において、アプリケーション１２が提供するＡＰＩを用いることで、アプリケーション１２のパスワード保護機構を利用する。すなわちカプセル化ツール１４は、アプリケーション１２のパスワード保護機構を利用することで、アプリケーション１２の作成・編集するコンテンツに対し、ＤＲＭシステムによる電子チケット方式のコンテンツ保護を適用できるようにしている。このカプセル化ツール１４の処理内容については後で詳細に説明する。なお、ここでいうコンテンツ提供者は、コンテンツホルダー（所有者）でも、コンテンツホルダーからの依頼を受けてコンテンツ配信を行う業者でもよい。

ユーザＰＣ２０は、コンテンツを利用するユーザが操作する端末装置である。ユーザＰＣ２０は、コンテンツ提供者側装置１０が提供するコンテンツを取り扱うアプリケーション２２を備える。このアプリケーション２２は、コンテンツ提供者側装置１０のアプリケーション１２と同等のものであり、パスワード保護の解除機能を備える。また、ユーザに提供されるコンテンツはカプセル化ツール１４によりカプセル化されたものであるため、ユーザＰＣ２０は、このカプセル化を解除する機能を備えたビューワ２４を備える。ビューワ２４は、アプリケーション２２のＡＰＩを用いてカプセル化の解除を行い、その結果得られたコンテンツをユーザに表示する。

次に、図２及び図３を参照して、コンテンツ提供者側装置１０のカプセル化ツール１４の処理手順を説明する。図２はこの処理の手順を示すフローチャートであり、図３はこの処理におけるカプセル化ツール１４とアプリケーション１２及びＤＲＭシステムとの指示のやりとりを示す図である。なお、図３では、煩雑さを避けるため、ＤＲＭ権利発行サーバ３０とＤＲＭ権利管理サーバ４０をＤＲＭシステムとまとめて表示している。

図２に示すように、この手順では、まずカプセル化ツール１４に対して操作者からカプセル化の対象となるコンテンツのファイルが指定される（Ｓ１０）。ここでは、ワードプロセッサアプリケーションのファイルである"target.doc"が指定されたとする（図３参照）。するとカプセル化ツール１４は、そのコンテンツを取り扱うアプリケーション１２のパスワード保護機構が許容する範囲（例えばパスワード文字数の下限と上限など）内のパスワードを自動生成する（Ｓ１２）。パスワードは、アプリケーション１２がコンテンツを保護する際の鍵であり、その保護を解除するための解除用の鍵である。このパスワードを乱数や擬似乱数などを用いて生成すれば、カプセルのセキュリティを高めることができる。例えば、アプリケーション１２が許容するパスワード文字数の上限に該当するバイト数の擬似乱数のバイナリデータを生成し、これをＢａｓｅ６４等の方式でアプリケーション１２がパスワードとして解釈可能なテキストデータに変換することで、ランダムなパスワードを生成することができる。このようにして生成されたパスワードを、図３では"pswd"と示している。

次にカプセル化ツール１４は、ＤＲＭシステムを構成するＤＲＭ権利発行サーバ３０に対しコンテンツ保護のための鍵の発行を要求し、該サーバ３０からその要求に応じた鍵（"Pk"とする）を取得する（Ｓ１４）。ステップＳ１２とＳ１４の実行順序は逆でもよい。ステップＳ１４で取得する鍵"Pk"は、公開鍵暗号方式を用いるＤＲＭシステムの場合は公開鍵であり、秘密鍵暗号方式を用いるＤＲＭシステムの場合は秘密鍵である。秘密鍵暗号方式の場合、ＤＲＭ権利発行サーバ３０から、鍵に対応づけて、その鍵を一意に指し示す鍵ＩＤ（識別情報）"keyID"も取得する。なお、ＤＲＭシステム（権利発行サーバ３０）は、鍵の発行を行うと、従来から行われているように、その鍵と鍵ＩＤ（秘密鍵暗号方式の場合）の対応関係、又はその鍵（公開鍵）と秘密鍵の対応関係をデータベースに登録して管理する。これは後で電子チケット発行する際に必要となるからである。

ＤＲＭシステムから鍵を取得すると、カプセル化ツール１４は、ステップＳ１２で生成したパスワード"pswd"をこの鍵"Pk"で暗号化することにより、認証情報"EncInfo"を生成する（Ｓ１６）。

次にカプセル化ツール１４は、アプリケーション１２の提供するＡＰＩを用いて、ステップＳ１０で指定されたファイルをアプリケーション１２にオープンさせる（Ｓ１８）。図３では、そのＡＰＩのメソッドを"wordApp.open"として示している。このＡＰＩメソッドには、対象ファイル"target.doc"が引数として指定される。このＡＰＩメソッドに応じ、アプリケーション１２は、対象ファイルをオープンし、そのオープンされた対象ファイルのオブジェクト識別子"docObj"をカプセル化ツール１４に返す。なお、この明細書で例示するメソッドやその引数等の形式はあくまで例示のためのものであり、具体的なアプリケーションに対してはそのアプリケーションが提供するＡＰＩに従った形式のメソッドを利用すればよい。

対象ファイルがオープンされると、カプセル化ツール１４は、ステップＳ１５で生成した認証情報（すなわち暗号化したパスワード）を、対象ファイルに対し属性情報として付加する（Ｓ２０）。アプリケーション１２は、マイクロソフト社の「Ｗｏｒｄ」等のように、ファイルに対して属性（プロパティ）情報を設定可能なものであるとする。図３の例では、この属性の設定は、アプリケーション１２が提供する属性設定用のＡＰＩメソッド"Addprop"を用いて行われている。すなわち、カプセル化ツール１４は、対象ファイルのオブジェクト"docObj"について、認証情報である旨を示す属性名"capsuleinfo"と、認証情報"EncInfo"と、この認証情報の暗号化に用いた鍵の鍵ＩＤ"keyID"と、を引数としてこのメソッド"Addprop"を呼び出す。アプリケーション１２は、このメソッドを実行することで、そのオブジェクト"docObj"に対し、認証情報と鍵ＩＤを"capsuleinfo"という属性名で設定する。ここで認証情報等に与える属性名である"capsuleinfo"は、本システム内であらかじめ取り決めてある名称であり、カプセルを利用する側のビューワ２４もこの属性名"capsuleinfo"を用いて認証情報等の属性情報を特定する。鍵ＩＤ"keyID"を認証情報"EncInfo"と共に属性に設定するのは、ビューワ２４が認証情報を復号化するのに必要な鍵をその鍵ＩＤ"keyID"が示しているためである。この鍵ＩＤとしては、本実施形態で使用するＤＲＭシステムが秘密鍵暗号方式の場合は、ＤＲＭシステムから鍵と共に取得した鍵ＩＤを用いる。また、公開鍵暗号方式を用いる場合、公開鍵が知られても復号に必要な秘密鍵をその公開鍵から求めることは非常に困難なので、属性に設定する鍵ＩＤとして、暗号化に用いた公開鍵そのものを用いることもできる。

属性設定が完了すると、カプセル化ツール１４は、属性を設定したオブジェクト"docObj"をパスワード保護付きで保存するよう、アプリケーション１２に指示する（Ｓ２２）。図３の例では、オブジェクト"docObj"について、ファイル保存を示すメソッド"Saveas"を呼び出している。アプリケーション１２は、このメソッドを実行することで、オブジェクト"docObj"を、引数に示されたファイル名"target.cdc"で、かつ、引数に示されたパスワード"pswd"で保護した状態のファイルとして保存する。ステップＳ２２の時点でのオブジェクト"docObj"は、最初に指定されたファイル"target.doc"のデータ内容（本体及び属性の両方）に対し、更に認証情報"EncInfo"等が属性として追加されたものであり、これをパスワード保護されたファイルとしたものがファイル"target.cdc"である。

このように、指定された対象ファイル"target.doc"に対し、認証情報"EncInfo"等を属性として付加し、パスワード保護して保存するという処理が、本実施形態のカプセル化であり、そのように保存されたファイル"target.cdc"が本実施形態形態におけるカプセルである。

なお、このファイル名の拡張子".cdc"は、ビューワ２４に関連づけられたものである。すなわち、例えばマイクロソフト社のWindows（登録商標）オペレーティングシステムで制御されるユーザＰＣ２０にビューワ２４をインストールする際、拡張子".cdc"はビューワ２４に対応するものとして登録される。したがって、ＯＳが提供するファイルシステムのグラフィカル・ユーザ・インタフェース（ＧＵＩ）上でユーザがファイル"target.cdc"に対し、ダブルクリック操作などのオープン操作が行われた場合、アプリケーション２２ではなく、ビューワ２４が起動され、そのファイルを開くための処理を行うことになる。

以上のようにして生成され、保存されたカプセルが、従来と同様、ネットワーク５０経由或いはＣＤ−ＲＯＭ等の可搬型媒体の配布などの方法で、ユーザに対して提供される。

このカプセルの配布と並行して、コンテンツ提供者は、従来と同様、ＤＲＭシステムのＤＲＭ権利管理サーバ４０に対して、当該コンテンツに対する電子チケットの発行条件を登録する。発行条件は、当該コンテンツに対する電子チケットを発行するユーザを規定する条件である。同じコンテンツに対し、与える権利の内容（例えば「閲覧のみ可」、「改変可」、「複製作成可」など）が異なる複数レベルの電子チケットを発行する場合もあり、その場合には権利内容毎についての条件が発行条件として規定される。例えば、ユーザからの料金支払いを発行条件とする場合において、料金レベルごとに権利内容の異なる電子チケットを用意する場合などである。また、料金支払いを発行条件とする場合以外にも、ユーザ情報により発行条件を規定する場合もある。例えば、コンテンツごとに、そのコンテンツに対する電子チケットの発行対象とするユーザのユーザＩＤを個々に指定したり、或いは発行対象のユーザが属すべきグループを指定したり、発行対象のユーザが持つべきユーザ属性（年齢・性別・役職等）の条件を指定したりすることもできる。もちろんこのような条件設定は、権利内容のレベル毎に行うこともできる。このようにユーザ情報により発行条件が規定される場合、ＤＲＭ権利管理サーバ４０では、電子チケットの発行要求を受けた場合、ユーザ認証を行い、これにより認証されたユーザのユーザ情報に基づき、電子チケットの発行の可否や、発行するチケットの権利内容を判定する。

次に、図４及び図５を参照して、カプセルを利用しようとするユーザＰＣ２０での、ビューワ２４の処理手順を説明する。図４はこの処理の手順を示すフローチャートであり、図５はこの処理におけるビューワ２４とアプリケーション１２及びＤＲＭシステムとの指示のやりとりを示す図である。

この手順は、既に起動しているビューワ２４に対してカプセルのオープンが指示された時、或いはファイルシステム上でカプセルのオープンが指示され、これに応じてビューワ２４が起動された時に開始される（Ｓ３０）。図５の例では、ファイル"target.cdc"のオープンが指示されている。この指示に応じビューワ２４は、まずアプリケーション２２が提供するＡＰＩのうちファイル（図示例では"target.cdc"）の属性をオープンするＡＰＩ"wordApp.OpenProp"を用いることで、アプリケーション２２に対し、当該ファイルの属性読み出し用のＡＰＩ"Getprop"を受け付けるためのオブジェクト"docObj"を生成する（Ｓ３１）。

次にビューワ２４は、アプリケーション２２の属性読み出し用のＡＰＩを用いて、オブジェクト"docObj"（すなわちファイル"target.cdc"）の属性データのうちの認証情報"capsuleinfo"を読み出す（Ｓ３２）。図５の例では、ＡＰＩメソッド"Getprop"を用い、引数として読み出すべき属性の名称"capsuleinfo"を指定している。カプセルのファイルには、認証情報がその属性名で設定されているので、アプリケーション２２はその属性"capsuleinfo"のデータを読み出してビューワ２４に返す。

カプセル化ツール１４の説明のなかで示したように、属性"capsuleinfo"の中には、暗号化された認証情報"EncInfo"と、その暗号化を解除するのに必要な鍵の識別情報である"keyID"が含まれている。この属性情報を受け取ったビューワ２４は、その鍵ＩＤ"keyID"に対応する電子チケットを、ユーザＰＣ２０のローカル環境内で探索する（Ｓ３４）。これは、オフライン型のＤＲＭシステムの場合である。すなわち、オフライン側の場合、ＤＲＭシステムから取得した電子チケットを、ユーザＰＣ２０のローカル環境内のチケットデータベース（図示省略）に保存しているので、ステップＳ３４では、その取得済みの電子チケットの中に、今回の対象ファイル"target.cdc"に対応する電子チケットがあるかどうかを調べる。電子チケットにはそのチケット自身が対応可能な鍵の識別情報が含まれているので、ステップＳ３４では、対象ファイルの属性情報から得られた"keyID"と同じ値の鍵ＩＤを持つ電子チケットを探すのである。なお、コンテンツに対して一意に付与されたコンテンツＩＤをカプセルに属性情報の一つとして組み込み、更に電子チケットにも組み込むことも可能である。この場合、カプセルに対応する電子チケットは、鍵ＩＤの代わりにコンテンツＩＤで特定することができる。

ステップＳ３４の探索で、対応する電子チケットがローカル環境には存在しないことが判った場合、ビューワ２４は、ＤＲＭ権利管理サーバ４０にアクセスし、コンテンツ利用権確認処理を実行する（Ｓ３８）。コンテンツ利用権確認処理は、ビューワ２４を操作するユーザが当該コンテンツの利用のための電子チケットを取得するための権利を持っているかどうかを判定する処理である。この判定のため、ビューワ２４は、ステップＳ３２で取得したカプセルの鍵ＩＤ"keyID"（又は当該コンテンツのＩＤ）をＤＲＭ権利管理サーバ４０に送信する。これを受け取ったＤＲＭ権利管理サーバ４０は、その鍵ＩＤ（又はコンテンツＩＤ）に対応づけて登録された発行条件（前述）に基づき、チケット発行の可否を判定する。例えば、料金支払いに応じてチケットを発行する場合、ビューワ２４側から料金支払いの操作がなされると、電子チケットを発行可能と判定する。また、ユーザ情報に基づきチケット発行の可否を判定する場合は、ＤＲＭ権利管理サーバ４０は、ビューワ２４に対してユーザ認証情報（例えばユーザＩＤとパスワードの組）の入力を求め、それに応じて入力されたユーザ認証情報に基づきユーザ認証を行う。このユーザ認証により、正当なユーザからのアクセスであると判定された場合、そのユーザのユーザ情報が当該コンテンツの発行条件を満足しているかどうかを判定し、満足している場合には電子チケットが発行可能と判定する。なお、このようなコンテンツ利用権確認処理自体は特に特徴的なものではなく、公知の様々な手法を利用することができる。

コンテンツ利用権確認が失敗した場合（すなわち電子チケットが発行不可と判定された場合）（Ｓ４０）は、ビューワ２４は、ユーザが当該コンテンツの利用できない旨のメッセージを表示する等のエラー処理を行い（Ｓ４２）、当該コンテンツをオープンする処理を終了する。なお、エラー処理は必須ではない。

コンテンツ利用権確認が成功した場合（Ｓ４０）、ＤＲＭ権利管理サーバ４０は、ＤＲＭ権利発行サーバ３０に対して当該コンテンツを特定する情報（例えば前述の鍵ＩＤ又はコンテンツＩＤ）を渡し、電子チケットの発行を要求する。コンテンツ利用権確認において、発行条件からチケットの権利内容が求められる場合は、その権利内容の情報も併せて権利発行サーバ３０に送る。ＤＲＭ権利発行サーバ３０は、受け取った情報に応じた電子チケットを発行する。ＤＲＭ権利管理サーバ４０は、発行された電子チケットを受け取り、これをビューワ２４に送信する。処理はステップＳ４４に進み、ビューワ２４はその電子チケットを取得する。

ステップＳ３６で、対応する電子チケットがローカルのチケットデータベースに存在することが判った場合は、ビューワ２４はチケットデータベースからその電子チケットを取得する（Ｓ４４）。

なお、ＤＲＭ権利発行サーバ３０及びＤＲＭ権利管理サーバ４０がオンライン型のＤＲＭシステムである場合は、電子チケット（ライセンス）がユーザＰＣ２０上に保存されることはないので、ステップＳ３６は不要である。この場合、ビューワ２４は、必ずステップＳ３８のコンテンツ利用権確認処理を実行する。

対象のコンテンツ・ファイルに対応した電子チケットを取得すると（Ｓ４４）、ビューワ２４は、その電子チケットを用いて認証情報"EncInfo"を復号する（Ｓ４６）。例えば、特許文献２に示されるアクセスチケット方式の場合、電子チケットに含まれる情報と、ユーザＰＣ２０が内蔵するハードウエア又はユーザＰＣ２０に接続されたハードウエア（例えばＩＣカードやＵＳＢ(Universal Serial Bus)機器など）が保持する固有情報（この固有情報は、アクセスチケットのシステムがハードウエア毎に割り当てたもの）と、を組み合わせた情報から、暗号化された認証情報"EncInfo"を復号するための鍵が求められる。なお、アクセスチケット方式やその類似方式の場合、電子チケットの発行を受けるために、ビューワ２４からＤＲＭシステム側に、コンテンツを特定する鍵ＩＤ又はコンテンツＩＤの他に、ユーザＰＣ２０又はそれに接続されたハードウエアの識別情報を送る場合もある。Windows Media(登録商標) Rights Managerを用いたＤＲＭシステムの場合、電子チケット（ライセンス）のデータの中に、復号用の鍵が含まれているので、それを利用する。このようにして取得した鍵を用いて認証情報"EncInfo"を復号することにより、カプセル"target.cdc"のパスワード保護を解除するためのパスワード"pswd"が求められる。

ビューワ２４は、次に、そのパスワード"pswd"をアプリケーション２２に渡し、カプセル"target.cdc"をオープンする（Ｓ４８）。ここでは、ビューワ２４は、アプリケーション２２のＡＰＩのうち、ファイルオープンを指示するためのＡＰＩメソッド"wordApp.open"を用い、引数としてオープン対象のファイルを特定する情報"target.cdc"とパスワード"pswd"とを指定する。この指示を受けたアプリケーション２２は、パスワード"pswd"によりそのファイルのパスワード保護を解除して、そのファイルをオープンする。ビューワ２４は、そのオープンされたファイルのオブジェクト"docObj1"を受け取り、これを用いてそのファイルの内容を画面表示する（Ｓ５０）。

なお、電子チケットには、ユーザに対して与える権利内容の情報が含まれる場合がある。そのような電子チケットを用いた場合は、ビューワ２４は、オープンしたファイルを表示する際、ファイル表示画面の操作メニューに表示する操作項目を、その権利内容において認められる操作項目のみに限定したり、あるいはその権利内容で認められない操作項目を選択不可の状態として表示するなどの制御を行う。また、電子チケットの権利内容に権利の有効期間や利用可能上限回数の情報が含まれる場合、ビューワ２４は、従来と同様、現在時刻が有効期間内か、又はその時点までのチケットの利用回数が上限回数を超えているかどうかの判定を行い、有効期間内でなかったり、利用回数が上限回数を超えている場合は、ファイルの表示を取りやめる。

また、このような権利内容の情報を、カプセル自身に埋め込むこともできる。この場合のカプセル化ツール１４及びビューワ２４の処理手順を図６及び図７に示す。図６及び図７において、図２及び図４の示した手順のステップと同様の処理を行うステップには、同一符号を付して説明を省略する。

まず図６のカプセル化ツール１４の手順は、図２の手順と比較した場合、操作者から、ユーザに与える権利内容（許可する操作又は許可しない操作、有効期間、利用可能上限回数など）の設定を受けるステップＳ１３が増えている。このステップＳ１３は、ステップＳ１０からステップＳ１６ａまでの間ならどのタイミングで実行してもよい。そして、ステップＳ１６ａでは、パスワード"pswd"とステップＳ１３で設定された権利内容の情報を結合し、この結合した情報を、ＤＲＭシステムから取得した鍵により暗号化することにより認証情報"EncInfo"を生成する。その他の処理は、図２の手順と同じでよい。

図７のビューワ２４の手順のステップＳ４６ａでは、図４のステップＳ４６と異なり、認証情報"EncInfo"を復号することで、パスワード及び権利内容の情報を取得する。そして、ステップＳ５２では、ユーザの権利が失効しているか否かを、ステップＳ４６ａで取得した権利内容の示す有効期間と現在時刻を比較することで判定する（Ｓ５２）。権利内容に利用上限回数が示されている場合、ステップＳ５２で利用回数のチェックを行うようにしてもよい。ステップＳ５２の判定において、権利が失効していれば（或いは利用回数が上限回数を超えていれば）、エラー処理を行い（Ｓ５４）、ファイルをオープンしないまま処理を終了する。権利が失効していない場合、ステップＳ４８で対象のファイルをオープンした後、ステップＳ４６ａで取得した権利内容に応じて、ファイル表示画面の操作メニューの中で選択可能とする操作項目を選択し、その選択結果に応じた表示画面を生成し（Ｓ５６）、その表示画面内にオープンしたファイルの内容を表示する（Ｓ５０）。

以上の例では、暗号化された認証情報"EncInfo"を、パスワード保護する対象ファイルの属性データとして設定していたが、認証情報"EncInfo"を対象ファイルに含めない形で管理する方式も可能である。例えば、認証情報"EncInfo"を対象ファイルとは別のファイルとして保存する方式である。この場合認証情報"EncInfo"のファイル、又は対象ファイルの少なくとも一方に、それら両者の対応関係を示すデータを持たせる。例えば、両ファイルのファイル名を互いに対応したものとしてもよいし、両方又はいずれか一方のファイル内に例えば属性情報として対応づけのための情報を持たせるようにしてもよい。また、認証情報"EncInfo"はファイルする代わりに、データベースに登録する方式も考えられる。このように認証情報を対象ファイル内に含めず、認証情報と対象ファイルとを互いに関連づけられた別々の情報として作成する場合も、本明細書では「カプセル化」の範疇に含める。なお、カプセル化ツール１４は、カプセルを配布等のために外部に出力する場合、カプセルの本体であるパスワード保護されたファイルと、これに関連づけられた認証情報"EncInfo"のデータとをセットにして出力する。カプセルを受け取る側の装置（例えばコンテンツを配布するサーバや、ビューワ２４）も、受け取ったファイルと認証情報のセットを互いに関連づけて管理する機能を備える。すなわち、ファイルと認証情報とはペアとなって、本実施形態のシステムの各要素間を流通する。

図１〜図７を参照して説明した実施形態では、カプセル化ツール１４が、アプリケーション１２，２２のパスワード保護に用いるパスワードをＤＲＭシステムから取得した鍵で暗号化し、この暗号化された情報がパスワード保護したコンテンツ・ファイルと関連づけて流通し、ユーザに提供される。ユーザは、ＤＲＭシステムにコンテンツ利用権確認（チケット発行可否判定）に合格して電子チケットを受け取ることで、その暗号化された情報を復号でき、復号の結果得られたパスワードにより、そのコンテンツ・ファイルのパスワード保護を解除することができる。カプセルは、ＤＲＭシステムの管理下で保護され、原理的には、ＤＲＭシステムから電子チケットを取得したユーザのみがそのコンテンツを利用することができる。

この仕組みは、アプリケーション１２，２４自身はパスワード保護機能とそれを外部のプログラム（カプセル化ツール１４、ビューワ２４）から利用するためのインタフェースを備えていれば成立する。すなわち、アプリケーション１２，２４がＤＲＭシステムに直接対応していなくても、またＤＲＭ機能のためのプラグインを受け入れることできなくても、本実施形態の方式によりそのアプリケーションのファイルに電子チケット方式の保護を施すことができる。

取り扱うファイルに対してパスワード保護以外の方式の保護を施すアプリケーションも考えられるが、そのようなアプリケーションに対しても、上述の方式を適用することが可能であることは容易に了解されるであろう。パスワード保護以外の保護を施す場合も、その保護を解除するのに必要な解除用情報をＤＲＭシステムの鍵で暗号化し、その暗号結果のデータを対象ファイルと関連づけてユーザ側に提供するようにすればよい。

以上、アプリケーションのコンテンツ保護機能を利用して、アプリケーションの作成・編集したファイルに電子チケット方式の保護を施す場合の実施形態を示した。次に、下位のＤＲＭシステムで保護されるコンテンツに対する利用権を、上位のＤＲＭシステムで管理する実施形態を説明する。この実施形態は、コンテンツを作成・編集する複数のアプリケーションがそれぞれ別々の（下位）ＤＲＭシステムに対応している場合において、それら複数のアプリケーションのコンテンツの利用を一元管理したい場合などに有用なものである。

ただし、以下では煩雑さを避けるため、下位ＤＲＭシステムが１つである場合の例を説明する。１つの上位ＤＲＭシステムに対して下位ＤＲＭシステムが複数ある場合は、上位ＤＲＭシステムは個々の下位ＤＲＭシステム対し、これから説明する処理をそれぞれ実行すればよい。

上位ＤＲＭシステムは、図１〜図７の実施形態と同様オンライン型でもオフライン型でもよく、タイプの違いによる処理の相違については既に上記実施形態で説明済みである。以下では煩雑さを避けるため、上位ＤＲＭシステムがオフライン型であるとして説明する。

まず図８〜図１０を用いて１つの実施形態を説明する。説明の便宜上、下位ＤＲＭシステムがオンライン型であるとして説明する。図８のシステム構成において、下位ＤＲＭシステムは下位ＤＲＭ権利発行サーバ６０と下位ＤＲＭ権利管理サーバ７０を含む。下位カプセル化装置１０Ｂは、下位ＤＲＭシステムに対応したアプリケーションを備えており、このアプリケーションの作成・編集したコンテンツ・ファイルに対して、下位ＤＲＭシステムによる保護のためのカプセル化を施す。下位ＤＲＭシステムと下位カプセル化装置１０Ｂとの組が、図１の実施形態のアプリケーション１２，２４に相当する位置づけである。これら下位ＤＲＭシステム及び下位カプセル化装置１０Ｂは、従来から存在するシステムと同様のものでよい。

一方、上位ＤＲＭ権利発行サーバ３０Ａと上位ＤＲＭ権利管理サーバ４０Ａは、上記実施形態におけるサーバ３０，４０にそれぞれ対応し、それら２つで上位ＤＲＭシステムを構成する。上位ＤＲＭカプセル化装置１０Ａは、図１のカプセル化ツール１４に対応するものであり、下位ＤＲＭを上位ＤＲＭで管理するに当たっての特別な処理を行う。この上位ＤＲＭカプセル化装置１０Ａの処理内容は、図９のフローチャートに示す。

ユーザＰＣ２０は、図１の実施形態におけるユーザＰＣ２０と同様、コンテンツ・ファイルを取り扱うアプリケーションと、ビューワ（図示省略）とを備えている。ビューワは、図１のビューワ２４に対応するものであり、下位ＤＲＭを上位ＤＲＭで管理するシステムならではの処理を実行する。この処理の流れを、図１０に示す。

以下、図８〜図１０を参照して、本実施形態の処理の流れを説明する。図８において、実線矢印はカプセル化処理におけるデータの流れを示し、破線矢印はカプセルをオープンする際のデータの流れを示す。

まず配布するコンテンツ・ファイルのカプセル化処理の流れを、図８及び図９を参照して説明する。

上位ＤＲＭカプセル化装置１０Ａに対し操作者がカプセル化対象のファイルを指定してカプセル化処理の実行を指示すると（Ｓ６０）、この上位ＤＲＭカプセル化装置１０Ａは、下位ＤＲＭカプセル化装置１０Ｂにその対象ファイルを送付し、カプセル化を依頼する（Ｃ１，Ｓ６２）。ここで、上位ＤＲＭカプセル化装置と下位ＤＲＭカプセル化装置は同一のハードウエア装置に実行される別のサーバプログラムとして実現しても良く、この場合ステップＳ６２では両プログラム間でファイルが受け渡されるだけである。

依頼を受けた下位ＤＲＭカプセル化装置１０Ｂは、下位ＤＲＭ権利発行サーバ６０に鍵の発行を依頼する（Ｃ２）。これを受けた下位ＤＲＭ権利発行サーバ６０は、鍵と、鍵(コンテンツ）ＩＤを生成して下位ＤＲＭカプセル化装置１０Ｂに送り返す（Ｃ３）。下位ＤＲＭカプセル化装置１０Ｂは、受け取った鍵で対象ファイルを暗号化し、この結果できる暗号化データに対し鍵(コンテンツ)ＩＤを付加することで、カプセルを生成する。そして、生成したカプセルを上位ＤＲＭカプセル化装置１０Ａに送り返す（Ｃ４）。

下位ＤＲＭカプセル化装置１０Ｂが作成したカプセル（「下位カプセル」と呼ぶ）を受け取った上位ＤＲＭカプセル化装置１０Ａ（Ｓ６４）は、ユーザＩＤとユーザ認証用パスワードとをランダムな文字列として生成する（Ｓ６６）。そして、そのユーザＩＤ及びパスワードと、下位カプセルから取り出した鍵ＩＤとを下位ＤＲＭ権利管理サーバ７０に送付し、そのユーザＩＤに対するその鍵ＩＤの利用権の設定を依頼する（Ｃ５，Ｓ６８）。これに応じ、下位ＤＲＭ権利管理サーバ７０が利用権設定を行い、設定ＯＫのステータスを上位ＤＲＭカプセル化装置１０Ａに返す（Ｃ６）。

次に上位ＤＲＭカプセル化装置１０Ａが、上位ＤＲＭ権利発行サーバ３０Ａに上位ＤＲＭでの保護のための鍵の発行を依頼すると（Ｃ７）、上位ＤＲＭ権利発行サーバ３０Ａから鍵（公開鍵暗号方式の場合は公開鍵、秘密鍵暗号方式の場合は秘密鍵とこの秘密鍵の鍵ＩＤとのペア）が返される（Ｃ８）。鍵を取得した上位ＤＲＭカプセル化装置１０Ａは（Ｓ７０）、その上位ＤＲＭの鍵で、前述のユーザＩＤ及びユーザ認証用とパスワードを暗号化し、この暗号化情報と、上位ＤＲＭの保護を解除する鍵を特定するための鍵ＩＤ（公開鍵暗号方式の場合は公開鍵自身）とを組み合わせることで上位ＤＲＭ認証情報を生成する（Ｓ７２）。そして、この上位ＤＲＭ認証情報を下位カプセルに付加することで、配布用のカプセルを生成する（Ｓ７４）。生成された配布用カプセルは、従来公知の手段でユーザに配布される（Ｃ９）。また、コンテンツ提供者は、配布したカプセルについての電子チケットの発行条件を、公知の手段により上位ＤＲＭ権利管理サーバ７０に登録する。

次に、図８及び図１０を参照して、配布されたカプセルをユーザＰＣ２０のビューワで開く際の処理を説明する。

ユーザがビューワを起動し、利用したいカプセルを開く指示を行うと（Ｓ８０）、ビューワは、カプセルに埋め込まれている上位ＤＲＭ認証情報を取り出す（Ｓ８２）。上位ＤＲＭ認証情報には、暗号化されたユーザＩＤ及びユーザ認証用パスワードと、上位ＤＲＭ用の鍵ＩＤが含まれている。ビューワは、その鍵ＩＤに対応する電子チケットがユーザＰＣ２０のローカル環境に存在するかどうかを確認する（Ｓ８４，Ｓ８６）。存在すれば（Ｓ９４に進む。存在しなければ、ビューワは上位ＤＲＭ権利管理サーバ４０Ａにアクセスし、図４のステップＳ３８と同様のコンテンツ利用権確認処理を行う（Ｓ８８，Ｓ９０，Ｕ１）。

コンテンツ利用権確認処理では、上位ＤＲＭ権利管理サーバ４０Ａは、依頼されたユーザが利用権を持っているかどうかを、あらかじめ登録された発行条件から判定する。当該ユーザが利用権を持っていないと判定された場合は、エラー処理を行い（Ｓ９２）、一連の処理を終了する。利用権を持っていると判定された場合は、上位ＤＲＭ権利発行サーバ３０Ａに、上位ＤＲＭ用の鍵ＩＤに対応する電子チケットの発行を依頼する（Ｕ２）。このとき、利用者の有する権利に制限がある場合は、チケット発行依頼にその利用条件とともに発行を依頼する。この依頼に対し、上位ＤＲＭ権利発行サーバ３０Ａは、指定された鍵ＩＤに対応する指定された条件（権利内容）の電子チケットを発行して送り返す（Ｕ３）。これを受け取った権利管理サーバ４０Ａは、ビューワに対してその電子チケットを送り返す（Ｕ４）。

これを受け取ったビューワ（Ｓ９４）は、その電子チケットの用いて復号用の鍵を求め、この鍵を用いて、上位ＤＲＭ認証情報中の暗号化されたユーザＩＤ及びユーザ認証用パスワードを復号する（Ｓ９６）。そしてビューワは、下位ＤＲＭ権利管理サーバ７０に対し、復号されたユーザＩＤ、ユーザ認証用パスワード、配布用カプセルから取得した下位ＤＲＭ鍵ＩＤ、及び電子チケットに指定された権利内容の情報を送付し（Ｕ５）、下位ＤＲＭの保護を解除するための電子チケットを取得する（Ｓ９８，Ｕ８）。

このステップＳ９８の処理において、ユーザＩＤ及びユーザ認証用パスワードは、下位ＤＲＭ権利管理サーバ７０でのユーザ認証に用いられる。このユーザＩＤ及びパスワードのペアは、ステップＳ６８で上位ＤＲＭカプセル化装置１０Ａから下位ＤＲＭ権利管理サーバ７０に対して既に登録されているので、このユーザ認証は成功する。また、その権利管理サーバ７０には同じくステップＳ６８でそのユーザＩＤに対してその鍵ＩＤへの利用権が設定されているはずなので、下位ＤＲＭ権利管理サーバ７０は電子チケット発行可と判定し、下位ＤＲＭ権利発行サーバ６０に鍵ＩＤと権利内容の情報を送付し（Ｕ６）、電子チケットの発行を依頼する。これに応じ下位ＤＲＭ権利発行サーバ６０は、下位カプセルの復号鍵（又はその元になる情報）と利用条件（権利内容）を含む電子チケットが送り返される（Ｕ７）。下位ＤＲＭ権利管理サーバ７０は、この電子チケット（下位用）をビューワに送り返す（Ｕ８）。

この電子チケットを受け取ったビューワは（Ｓ９８）、電子チケットを処理して復号鍵を求め、配布用カプセル中の下位カプセルをこの復号鍵で開く（Ｓ１００）。そして、開いたカプセルを、電子チケット中の利用条件の制限の下でユーザに利用させる（Ｓ１０２）。

このように図８〜図１０のシステムでは、下位ＤＲＭシステムには対応しているが上位ＤＲＭシステムには対応していないアプリケーションのファイルをカプセル化する必要があるので、実質的なカプセル化処理は下位ＤＲＭカプセル化装置１０Ｂが下位ＤＲＭシステムを利用して行っている。一方、カプセルに対するユーザの利用権管理は、上位ＤＲＭで統一的に行う必要がある。そこで、この例では、上位ＤＲＭカプセル化装置１０Ａが下位ＤＲＭシステムのユーザ権利管理のためのユーザＩＤ及びパスワードを自動生成することで仮想的なユーザを生成し、この仮想的なユーザに対するカプセルの利用権を下位ＤＲＭシステムに登録する。この仮想的なユーザの情報（ユーザＩＤ及びパスワード）が正当権利者以外に漏れなければそのカプセルの安全性は保たれるが、その一方正当な権利を持つユーザにその仮想的なユーザの情報が伝わらなければ、正当ユーザは仮想ＤＲＭで保護されたそのカプセルを利用できないことになる。そこで、この例では、この仮想的なユーザの情報（ユーザＩＤ及びパスワード）を上位ＤＲＭシステムの提供する鍵で暗号化してカプセルに付加した上でユーザに配布する。ユーザはこのカプセルを利用する際、上位ＤＲＭシステムによる利用権チェックを受ける。このチェックに合格した正当なユーザは、カプセル中から仮想的なユーザの認証情報を得ることができるので、この認証情報を用いて下位ＤＲＭシステムから利用権を得てそのカプセルが利用できるようになる。

なお、図８〜図１０の例では、下位ＤＲＭシステムがオンライン型であるとして説明をしたが、下位ＤＲＭシステムがオフライン型の場合も同様の方式を実現することができる。下位ＤＲＭシステムがオフライン型となることで変わってくる点は、下位ＤＲＭカプセル化装置１０Ｂにより生成された下位カプセルに対応する電子チケットが、ユーザＰＣ２０に既に保持されている可能性がある点である（オンライン型の場合は、コンテンツの利用の都度チケットを取得し、利用が終了するとチケットが消滅するので、そのような状況は生じない）。そこで、下位ＤＲＭシステムがオフライン型の場合、ユーザＰＣ２０のビューワは、図１０の処理手順において、配布用カプセルのオープンを指示された場合（Ｓ８０）、まずその配布用カプセルの中にある下位カプセルの中から下位ＤＲＭの鍵ＩＤ（公開鍵）を取得し、その鍵ＩＤに対応する電子チケットをローカル環境中から探し、見つかれば、その電子チケットを用いて下位カプセルを開く（Ｓ１００）。この場合、図１０のステップＳ８２〜Ｓ９８までの処理はスキップされる。下位ＤＲＭの鍵ＩＤに対応するチケットがローカル環境から見つからなかった場合は、ステップＳ８２以降の処理を実行する。

次に、下位ＤＲＭシステムを上位ＤＲＭシステムで管理するシステム構成の第１の変形例を、図１１〜図１３を参照して説明する。

この第１変形例は、図８〜図１０のシステムと比べた場合、上位ＤＲＭシステムで暗号化する情報が異なる。すなわち、図８のシステムの例では、上位ＤＲＭカプセル化装置１０Ａで生成した仮想的なユーザのＩＤ及びパスワードを暗号化したのに対し、この変形例では、下位ＤＲＭカプセル化装置１０Ｂが作成した下位カプセルの鍵（コンテンツ）ＩＤを保護（暗号化）する。ユーザは上位ＤＲＭシステムのコンテンツ利用権確認に合格すれば、それに応じて得られる電子チケットにより下位カプセルの鍵ＩＤを復号し、この鍵ＩＤを用いて下位カプセルに対応する電子チケットを下位ＤＲＭシステムから取得できる。

この変形例では、図８に示した下位ＤＲＭ権利管理サーバ７０は不要である（図１１参照）。

第１変形例におけるコンテンツ・ファイルのカプセル化処理の流れを、図１１及び図１２を参照して説明する。なお、図１１及び図１２においては、図８及び図９に示したステップやデータの流れに対応するものには同一符号を付して説明を省略する。

この処理において、図８及び図９の流れと異なっているのは、ステップＳ７６とＳ７２ａである。すなわち、図９のステップＳ６６ではユーザＩＤ及びパスワードを生成していたのに対し、この変形例では、上位ＤＲＭカプセル化装置１０Ａは、ステップＳ６４で取得した下位カプセルから鍵ＩＤを取り出す（Ｓ７６）。これにより下位カプセルからは鍵ＩＤが削除される。そして、ステップＳ７２ａでは、この鍵ＩＤ（下位ＤＲＭのもの）を上位ＤＲＭシステムから取得した鍵で暗号化し、この暗号化結果と、この暗号化を解除するための鍵を示す鍵ＩＤ（上位ＤＲＭのもの）とをまとめて認証情報を生成する。そして、ステップＳ７４では、この認証情報を下位カプセルに付加することで配布用カプセルを生成する。この処理手順では、下位ＤＲＭ権利管理サーバ７０に対する仮想的なユーザの利用権登録（図８のＣ５，Ｃ６及び図９のＳ６６，Ｓ６８）は行われない。

次に、図１１及び図１３を参照して、配布されたカプセルをユーザＰＣ２０のビューワで開く際の処理を説明する。図１３の処理手順は、ステップＳ８０〜Ｓ９４（Ｕ１〜Ｕ４）までは、図１０の手順と同じである。ステップＳ９４で電子チケットを取得すると、ビューワは、Ｓ８２で取得した認証情報中の暗号化された鍵ＩＤ（下位ＤＲＭのもの）をその電子チケットを用いて復号する（Ｓ９６ａ）。そして、この鍵ＩＤを下位ＤＲＭ権利発行サーバ６０に送り（図１１のＵ９）、この鍵ＩＤに対応する電子チケットを下位ＤＲＭ権利発行サーバ６０から取得する（Ｕ１０，Ｓ９８ａ）。そして、ビューワは、取得した電子チケットにより、配布されたカプセル中の下位カプセルを開いて（Ｓ１００）、ユーザに呈示する（Ｓ１０２）。

このように、第１変形例は、図８〜図１０の例に比べてシステム構成が簡単である。下位ＤＲＭシステムの鍵ＩＤが乱数などのように推測困難なものであれば、鍵ＩＤを推測するという攻撃は困難なので、この変形例でも十分にカプセルを守ることができる。

第１変形例は、下位ＤＲＭシステムがオンライン型である場合の例であったが、下位ＤＲＭシステムがオフライン型でも同様の方式が可能である。この変形例では、下位カプセルの鍵ＩＤを暗号化するので、オフライン型であらかじめその鍵ＩＤに対応する電子チケットがユーザＰＣ２０上に存在したとしても、鍵ＩＤを復号するまではそのことが判らない。したがって、ビューワの処理では、まず上位ＤＲＭの電子チケットでその鍵ＩＤを復号した後、その鍵ＩＤに対応する電子チケットをローカルで探索し、なければ下位ＤＲＭ権利発行サーバ６０から取得すると言う流れになる。それ以外は、オンライン型と同様でよい。

以上の第１変形例を更に一歩進めたのが、図１４〜図１６に示す第２の変形例である。図１４〜図１６において、図１１〜図１３の手順における各ステップと同内容のステップには、同一符号を付して説明を省略する。

上述の第１変形例では、下位カプセルの鍵ＩＤを上位ＤＲＭで保護して配布用カプセルに組み込んだが、この第２の変形例では、カプセル化の段階でその鍵ＩＤに対応する電子チケットを下位ＤＲＭ権利発行サーバ６０から取得してしまい、この電子チケットを上位ＤＲＭで保護して配布用カプセルに組み込む。

上位ＤＲＭカプセル化装置１０Ａの処理手順は、図１５に示される。第１変形例（図１２）との相違は、ステップＳ７８（図１４ではＣ５ａ，Ｃ６ａ）とＳ７２ｂである。すなわち、この第２変形例では、上位ＤＲＭカプセル化装置１０Ａは、下位ＤＲＭカプセル化装置１０Ｂから下位カプセルを受け取った（Ｓ６４）あと、この下位カプセル中の鍵ＩＤを下位ＤＲＭ権利発行サーバ６０に送り（Ｃ５ａ）、この鍵ＩＤに対応する電子チケットを発行してもらう（Ｓ７８，Ｃ６ａ）。そして、この電子チケットを上位ＤＲＭ権利発行サーバ３０Ａから取得した鍵で暗号化し（Ｓ７２ｂ）、暗号化された電子チケットをその暗号化の際に用いた鍵に対応する鍵ＩＤと併せて認証情報とし、これを下位カプセルに付加して配布用カプセルを作成する（Ｓ７４）。

一方、ユーザＰＣ２０のビューワは、ステップＳ９４で上位ＤＲＭシステムの電子チケットを取得すると、配布用カプセルから取り出した認証情報中の暗号化情報をその電子チケットで復号し、下位カプセル用の電子チケットを得る（Ｓ９６ｂ）。そして、その下位カプセル用の電子チケットを用いて下位カプセルの保護を解除することで、カプセル内のコンテンツ・ファイルを利用可能とする（Ｓ１００）。そしてビューワは、その電子チケット（下位用）の利用が終了（例えば開いたコンテンツ・ファイルを閉じた場合など）すると、その電子チケットをローカル環境の記憶装置から削除する。

このように、第２変形例では下位カプセル用の電子チケットが配布用カプセルに含まれているので、ユーザＰＣ２０のビューワは下位ＤＲＭシステムから下位カプセル用のチケットを取得する必要はない。第２変形例ではユーザ側はカプセルの利用時にはカプセル中のチケットを利用し、下位ＤＲＭに対する認証は受けないので、第２変形例は基本的に下位ＤＲＭがオフライン型の場合のものといえる。

以上の第２変形例では、利用が終了した下位カプセルの電子チケットをビューワが削除していたが、これは下位ＤＲＭ権利発行サーバ６０が上位ＤＲＭカプセル化装置１０Ａに対して電子チケットを発行する際、当該チケットの権利内容を指定していなかったためである。すなわち、この例では下位ＤＲＭはオフライン型なので、権利内容の設定のない（逆に言えば権利制限のない）下位ＤＲＭのチケットが一旦復号されユーザＰＣ２０上のチケットデータベースに登録されてしまうと、ユーザＰＣ２０ではその後、上位ＤＲＭから電子チケットを取得しなくても、その下位ＤＲＭのチケットを用いてカプセルを利用できる場合が出てくるという問題がある。そこで、上記の第２変形例では、一旦チケットデータベースに登録された当該電子チケットをコンテンツ利用終了後に削除することで、カプセル利用時にはユーザが必ず上位ＤＲＭで認証を受ける必要がでてくるようにした。

これに対し、下位カプセルに組み込む下位ＤＲＭの電子チケットに、権利内容を設定しておくこともできる。この場合の処理は、例えば上位ＤＲＭカプセル化装置１０Ａ上でコンテンツ提供者側の操作者が当該コンテンツについてユーザに与える権利内容を入力し、これを上位ＤＲＭカプセル化装置１０Ａから下位ＤＲＭ権利発行サーバ６０に送ってその権利内容の電子チケットを発行してもらい、下位カプセルに組み込む等の処理となる。この場合、上位ＤＲＭがユーザに対して発行する電子チケットの権利内容が、下位カプセルに組み込んだ下位ＤＲＭの電子チケットの権利内容と合致（一致又は下位チケットの権利を包含）するように管理すれば、上位ＤＲＭシステムの処理負荷を低減することができる。すなわち、ユーザＰＣ２０が一度上位ＤＲＭのコンテンツ利用権確認にパスすると、その下位ＤＲＭの電子チケットが有効となってローカルのチケットデータベースに登録されるので、その後ユーザが当該カプセルを利用する際には、ローカルにある下位ＤＲＭの電子チケットを用いてそのカプセルを開くことができるので、ユーザＰＣ２０は上位ＤＲＭのコンテンツ利用権確認を受けなくて済む。

なお、下位ＤＲＭのコンテンツを上位ＤＲＭで管理するための上述の実施形態及び変形例では、上位ＤＲＭカプセル化装置１０Ａは自ら生成したユーザＩＤ及びパスワードや下位カプセルの鍵ＩＤ、或いは下位カプセルのライセンスを上位ＤＲＭの鍵で暗号化したが、更に下位カプセル自体を上位ＤＲＭの鍵で暗号化してもよい。この場合、ビューワの処理には、暗号化された下位カプセルを上位ＤＲＭから取得した電子チケットで復号するステップが加わる。なお、図１２の例ではステップＳ７６で下位カプセルから鍵ＩＤを取り出し、ステップＳ７８でこれを上位ＤＲＭの鍵で暗号化していたが、これら両ステップに代えて下位カプセル全体を上位ＤＲＭの鍵で暗号化するステップを採用しても、下位カプセル中の鍵ＩＤ（下位用）を保護することができる。

本発明の実施形態のシステム構成を示す図である。 カプセル化処理の手順を示すフローチャートである。 カプセル化ツールとアプリケーション及びＤＲＭシステムとの指示のやりとりを示す図である。 ビューワの処理手順を示す図である。 ビューワとアプリケーション及びＤＲＭシステムとの指示のやりとりを示す図である。 権利内容の情報をカプセルに組み込む場合のカプセル化手順を示すフローチャートである。 権利内容の情報が組み込まれたカプセルを取り扱うビューワの処理手順を示す図である。 本発明の別の実施形態のシステムを説明するための図である。 カプセル化処理の手順を示すフローチャートである。 ビューワの処理手順を示す図である。 第１変形例のシステムを説明するための図である。 カプセル化処理の手順を示すフローチャートである。 ビューワの処理手順を示す図である。 第２変形例のシステムを説明するための図である。 カプセル化処理の手順を示すフローチャートである。 ビューワの処理手順を示す図である。

符号の説明

１０ コンテンツ提供者側装置、１２，２２ アプリケーションソフトウエア、１４ カプセル化ツール、２０ ユーザＰＣ、２４ ビューワ、３０ ＤＲＭ権利発行サーバ、４０ ＤＲＭ権利管理サーバ。

Claims (23)

1. コンピュータシステムを、
   コンテンツ保護機能を備える下位システムによるコンテンツの保護を解除するための解除用情報を、電子チケット方式の上位著作権管理システムから取得した鍵を用いて暗号化することで、暗号化情報を生成する暗号化手段、
   前記コンテンツを前記下位システムに渡して前記コンテンツ保護機能による該コンテンツの保護を実行させ、その結果得られる保護済みコンテンツを前記下位システムから取得し、該保護済みコンテンツと前記暗号化情報とを対応付けて配布用データを作成し出力するコンテンツ加工手段、
   として機能させるためのプログラム。
2. 前記下位システムは、コンテンツ保護機能を備えたアプリケーション・ソフトウエアである、ことを特徴とする請求１記載のプログラム。
3. 前記アプリケーション・ソフトウエアが備えるコンテンツ保護機能は、パスワードによる保護であり、
   前記プログラムは、前記コンピュータシステムを、前記アプリケーション・ソフトウエアによるコンテンツ保護のためのパスワードを生成する手段、として更に機能させるとともに、
   前記暗号化手段は、前記パスワードを前記解除用情報として暗号化し、
   前記コンテンツ加工手段は、前記アプリケーション・ソフトウエアに対し前記パスワードによるコンテンツ保護を実行させる、
   ことを特徴とする請求項２記載のプログラム。
4. 前記コンテンツ加工手段は、前記暗号化情報を、前記アプリケーション・ソフトウエアが取り扱うコンテンツに対し属性情報として付加する、
   ことを特徴とする請求項３記載のプログラム。
5. 前記下位システムは、前記上位著作権管理システムとは別の下位著作権管理システムであることを特徴とする請求項１記載のプログラム。
6. 前記プログラムは、前記コンピュータシステムを更に、
   前記下位著作権管理システムに対するユーザ認証情報を自動生成する手段、
   前記下位著作権管理システムに対し、前記ユーザ認証情報を用いて前記保護済みコンテンツに対する利用権を登録する手段、
   として機能させると共に、
   前記暗号化手段は、前記ユーザ認証情報を前記解除用情報として暗号化する、
   ことを特徴とする請求項５記載のプログラム。
7. 前記暗号化手段は、前記保護済みコンテンツの保護を解除する鍵を特定するための識別情報を、前記解除用情報として暗号化し、
   前記コンテンツ加工手段は、前記保護済みコンテンツの保護を解除する鍵を特定するための識別情報を前記保護済みコンテンツから削除し、前記識別情報が削除された前記保護済みコンテンツと前記暗号化情報とを対応づけて前記配布用データを作成する、
   ことを特徴とする請求項５記載のプログラム。
8. 前記プログラムは、前記コンピュータシステムを更に、
   前記保護済みコンテンツに対する電子チケットを前記下位著作権管理システムから取得するチケット取得手段、
   として機能させると共に、
   前記暗号化手段は、前記チケット取得手段が取得した前記保護済みコンテンツに対する電子チケットを、前記解除要情報として暗号化する、
   ことを特徴とする請求項５記載のプログラム。
9. 前記プログラムは、前記コンピュータシステムを更に、
   ユーザに対して付与する前記コンテンツの利用条件の入力を受け付ける手段、として更に機能させると共に、
   前記暗号化手段は、入力された利用条件を前記解除用情報と共に暗号化する、
   ことを特徴とする請求項１記載のプログラム。
10. 前記配布用データは、前記保護済みコンテンツと前記解除用情報とを１つのファイルにまとめたものであることを特徴とする、請求項１記載のプログラム。
11. コンピュータシステムを、
    下位システムのコンテンツ保護機能を用いて保護された保護済みコンテンツと、該保護済みコンテンツの保護を解除するための解除用情報を上位著作権管理システムが発行した鍵で暗号化することで得られた暗号化情報と、を含んだ配布用データを取得する手段、
    前記上位著作権管理システムとの間で、前記暗号化情報の復号のための電子チケットを取得するための認証処理を実行する手段、
    前記認証処理が成功して前記電子チケットが得られた場合に、前記配布用データに含まれる前記暗号化情報を前記電子チケットを用いて復号することにより、前記解除用情報を求める復号手段、
    前記復号手段により求められた解除用情報を用いて、前記保護済みコンテンツに対する前記下位システムによる保護を解除する解除手段、
    前記解除手段により保護が解除されたコンテンツをユーザに提示する提示手段、
    として前記コンピュータシステムを機能させるためのプログラム。
12. 前記下位システムは、コンテンツ保護機能を備えたアプリケーション・ソフトウエアである、ことを特徴とする請求１１記載のプログラム。
13. 前記アプリケーション・ソフトウエアが備えるコンテンツ保護機能は、パスワードによる保護であり、
    前記解除用情報は、前記アプリケーション・ソフトウエアが前記保護済みコンテンツの保護に用いたパスワードであり、
    前記解除手段は、前記解除用情報としてのパスワードを前記アプリケーション・ソフトウエアに対して渡し、前記保護済みコンテンツの保護の解除を指示する、
    ことを特徴とする請求項１２記載のプログラム。
14. 前記配布用データは、前記暗号化情報を前記保護済みコンテンツ中に属性情報として組み込んだものであり、
    前記復号手段は、前記保護済みコンテンツ中の属性情報から前記暗号化情報を取り出して、該暗号化情報を前記電子チケットを用いて復号する、
    ことを特徴とする請求項１３記載のプログラム。
15. 前記下位システムは、前記上位著作権管理システムとは別の下位著作権管理システムであることを特徴とする請求項１１記載のプログラム。
16. 前記解除用情報は、前記下位著作権管理システムに対するユーザ認証情報であり、
    前記解除手段は、前記復号手段により求められた解除用情報としての前記ユーザ認証情報を前記下位著作権管理システムに送信してユーザ認証を受けることにより、前記保護済みコンテンツの保護を解除するための電子チケットを取得し、該電子チケットを用いて前記保護済みコンテンツに対する保護を解除する、
    ことを特徴とする請求項１５記載のプログラム。
17. 前記解除用情報は、前記保護済みコンテンツの保護を解除する鍵を特定するための識別情報であり、
    前記解除手段は、前記復号手段により求められた解除用情報としての前記識別情報を前記下位著作権管理システムに送信することにより、該識別情報に対応する前記保護済みコンテンツの保護を解除するための電子チケットを取得し、該電子チケットを用いて前記保護済みコンテンツに対する保護を解除する、
    ことを特徴とする請求項１５記載のプログラム。
18. 前記解除用情報は、前記保護済みコンテンツの保護を解除するための電子チケットであり、
    前記解除手段は、前記復号手段により求められた解除用情報としての前記電子チケット用いて前記保護済みコンテンツに対する保護を解除する、
    ことを特徴とする請求項１５記載のプログラム。
19. 前記暗号化情報は、前記解除用情報と、前記保護済みコンテンツに対して付与されるユーザの利用条件とを前記上位著作権管理システムが発行した鍵で暗号化したものであり、
    前記復号手段は、前記暗号化情報を復号することで前記解除用情報と前記権利情報とを求め、
    前記提示手段は、前記復号手段により求められた前記権利情報に基づき、ユーザに対する前記保護が解除されたコンテンツの提示を制御する、
    ことを特徴とする請求項１１記載のプログラム。
20. コンテンツ保護機能を備える下位システムによるコンテンツの保護を解除するための解除用情報を、電子チケット方式の上位著作権管理システムから取得した鍵を用いて暗号化することで、暗号化情報を生成する暗号化手段と、
    前記コンテンツを前記下位システムに渡して前記コンテンツ保護機能による該コンテンツの保護を実行させ、その結果得られる保護済みコンテンツを前記下位システムから取得し、該保護済みコンテンツと前記暗号化情報とを対応付けて配布用データを作成し出力するコンテンツ加工手段と、
    を備えるコンテンツ保護装置。
21. 下位システムのコンテンツ保護機能を用いて保護された保護済みコンテンツと、該保護済みコンテンツの保護を解除するための解除用情報を上位著作権管理システムが発行した鍵で暗号化することで得られた暗号化情報と、を含んだ配布用データを取得する手段と、
    前記上位著作権管理システムとの間で、前記暗号化情報の復号のための電子チケットを取得するための認証処理を実行する手段と、
    前記認証処理が成功して前記電子チケットが得られた場合に、前記配布用データに含まれる前記暗号化情報を前記電子チケット用いて復号することにより、前記解除用情報を求める復号手段と、
    前記復号手段により求められた解除用情報を用いて、前記保護済みコンテンツに対する前記下位システムによる保護を解除する解除手段と、
    前記解除手段により保護が解除されたコンテンツをユーザに提示する提示手段と、
    を含むコンテンツ保護解除装置。
22. コンピュータにより実行されるコンテンツ保護方法であって、
    コンテンツ保護機能を備える下位システムによるコンテンツの保護を解除するための解除用情報を、電子チケット方式の上位著作権管理システムから取得した鍵を用いて暗号化することで、暗号化情報を生成し、
    前記コンテンツを前記下位システムに渡して前記コンテンツ保護機能による該コンテンツの保護を実行させ、その結果得られる保護済みコンテンツを前記下位システムから取得し、該保護済みコンテンツと前記暗号化情報とを対応付けて配布用データを作成し出力する、
    コンテンツ保護方法。
23. コンピュータにより実行されるコンテンツ保護解除方法であって、
    下位システムのコンテンツ保護機能を用いて保護された保護済みコンテンツと、該保護済みコンテンツの保護を解除するための解除用情報を上位著作権管理システムが発行した鍵で暗号化することで得られた暗号化情報と、を含んだ配布用データを取得し、
    前記上位著作権管理システムとの間で、前記暗号化情報の復号のための電子チケットを取得するための認証処理を実行し、
    前記認証処理が成功して前記電子チケットが得られた場合に、前記配布用データに含まれる前記暗号化情報を前記電子チケット用いて復号することにより、前記解除用情報を求め、
    求められた解除用情報を用いて、前記保護済みコンテンツに対する前記下位システムによる保護を解除し、
    保護が解除されたコンテンツをユーザに提示する、
    コンテンツ保護解除方法。

Images