JP2018011091A - 再生装置及び再生方法 - Google Patents

Abstract

【課題】ネットワークを介して暗号化コンテンツの再生に必要な鍵を取得する時間を短縮する。【解決手段】暗号化コンテンツ取得部１００１は、暗号化コンテンツを光ディスク３から取得し、鍵判断部１００２は、光ディスク３に記録されている第１の鍵情報を用いるか否かを判断し、第１の鍵情報を用いないと判断された場合、第２の鍵情報取得部１００４は、暗号化コンテンツを再生するために必要となる第２の鍵情報を、ネットワークを介して取得し、再生部１００５は、第２の鍵情報を用いて暗号化コンテンツを復号して再生し、再生部１００５によって最初に再生される暗号化コンテンツは、第１の鍵によって暗号化されており、第２の鍵情報取得部１００４は、最初に再生される暗号化コンテンツが再生されている間に、第２の鍵情報をネットワークを介して取得する。【選択図】図１２

Description

本開示は、媒体に記録されたコンテンツを再生する再生装置及び再生方法に関するものである。

近年、ネットワークを介して配信されるコンテンツを受信して端末で再生するコンテンツ配信が利用されている。例えば、特許文献１では、インタラクティブコンテンツをシーン単位で複数のコンテンツパーツに分割し、現在視聴しているコンテンツパーツの視聴中に、次に視聴される可能性のあるコンテンツパーツをダウンロードする端末が開示されている。

また、特許文献２では、放送ネットワークを介して配信されるコンテンツのすべての受信及び視聴ライセンス取得処理が完了するまでの間、そのコンテンツの一部分を再生し、視聴ライセンス取得処理後にコンテンツの残りの部分を再生するコンテンツ再生装置が開示されている。

特開２００６−２１７３１４号公報 特開２０１０−１８３２６０号公報

上記、従来の再生装置では、更なる改善が必要とされていた。

本開示の一局面に係る再生装置は、媒体に記録されたコンテンツを再生する再生装置であって、前記媒体は、暗号化された複数の暗号化コンテンツと、前記複数の暗号化コンテンツの内の一部の暗号化コンテンツを再生するために必要となる第１の鍵情報とを記録しており、前記暗号化コンテンツを前記媒体から取得する暗号化コンテンツ取得部と、前記暗号化コンテンツの復号に、前記第１の鍵情報を用いるか否かを判断する鍵判断部と、前記鍵判断部によって前記第１の鍵情報を用いると判断された場合、前記第１の鍵情報を前記媒体から取得する第１の鍵情報取得部と、前記鍵判断部によって前記第１の鍵情報を用いないと判断された場合、前記暗号化コンテンツを再生するために必要となる第２の鍵情報を、ネットワークを介して取得する第２の鍵情報取得部と、前記第１の鍵情報又は前記第２の鍵情報を用いて前記暗号化コンテンツを復号して再生する再生部とを備え、前記再生部によって最初に再生される暗号化コンテンツは、前記第１の鍵によって暗号化されており、前記第２の鍵情報取得部は、前記再生部によって最初に再生される暗号化コンテンツが再生されている間に、前記第２の鍵情報を前記ネットワークを介して取得する。

なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラム、または、記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。

本開示によれば、更なる改善が実現できる。

ＭＰＥＧ２−ＴＳ方式でコンテンツを光ディスクに格納する際のデータ構造を模式的に示す図である。 Ａｌｉｇｎｅｄ Ｕｎｉｔの復号方法を説明するための図である。 ＭＰ４方式でコンテンツをＨＤＤ又はフラッシュメモリに格納する際のデータ構造を模式的に示す図である。 Ｃｏｎｔｅｎｔ Ｆｉｌｅ内の各Ｆｒａｇｍｅｎｔの復号に必要となるＩｎｉｔｉａｌ Ｖｅｃｔｏｒを模式的に示す図である。 ＡＥＳ−ＣＴＲモードにおいて、Ｃｏｎｔｅｎｔ Ｆｉｌｅの暗号化について説明するための図である。 ＡＥＳ−ＣＴＲモードにおいて、Ｃｏｎｔｅｎｔ Ｆｉｌｅの復号化について説明するための図である。 図１で示したＳｔｒｅａｍ Ｆｉｌｅに加えて、各Ｓｔｒｅａｍ Ｆｉｌｅを復号するための鍵を記録するためのデータであるＫｅｙ Ｆｉｌｅのデータ構成を模式的に示す図である。 コンテンツ再生システムの構成を模式的に示す図である。 プレーヤが光ディスク上のＳｔｒｅａｍ Ｆｉｌｅをローカルストレージに格納する動作を模式的に示す図である。 プレーヤが光ディスク上のＳｔｒｅａｍ Ｆｉｌｅを全く別のＤＲＭ（Ｄｉｇｉｔａｌ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ）システムにエクスポートする動作について模式的に示す図である。 図１０でエクスポート先のメディアに格納されたＣｏｎｔｅｎｔ Ｆｉｌｅをメディアにバインドするために必要となる処理を模式的に示す図である。 本実施の形態におけるプレーヤの構成を示すブロック図である。 本実施の形態における再生処理を説明するためのフローチャートである。 光ディスクの１例であるＢＤ−ＲＯＭの構成を示す図である。 インテックステーブルの一例を示す図である。 本実施の形態においてプログラムファイルを実行する手順について説明するための図である。 本実施の形態における光ディスク挿入時のシーケンスの一例を示す図である。 プレーヤがネットワークに接続されていない場合に表示される画面の一例を示す図である。 鍵の取得先を示すＵＲＬをリージョンコード毎に格納するテーブルの一例を示す図である。 鍵の取得先を示すＵＲＬを国コード毎に格納するテーブルの一例を示す図である。 鍵の取得先を示すＵＲＬをタイトル毎に格納するテーブルの一例を示す図である。 プレイリストファイルについて説明するための模式図である。 プレイアイテムについて説明するための模式図である。

（本開示の基礎となった知見）
従来、光ディスクで利用されてきたファイルフォーマットは、ＩＳＯ／ＩＥＣ１３８１８１−１で規定されるＭＰＥＧ２−ＴＳ方式であり、映像ストリーム、音声ストリーム及び字幕ストリームが多重化されている。ＭＰＥＧ２−ＴＳ方式では、映像ストリーム、音声ストリーム及び字幕ストリームなどの各ストリームを各１８８ＢｙｔｅｓのＴＳパケットに分割した上で多重化して記録する。

これに対して、近年、ネットワークでのコンテンツ配信において利用されつつあるファイルフォーマットは、ＩＳＯ／ＩＥＣ１４４９６−１２で規定されるＭＰ４方式である。ＭＰ４方式は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）又はフラッシュメモリのようなランダムアクセス可能なメディアへの適用を前提に、極めて柔軟なデータ構造を採用している。一般的な利用形態では、映像ストリーム、音声ストリーム及び字幕ストリームを数秒程度のフラグメントという単位に分割した上で、これらを順次並べることによって一つのファイルとしている。

今後普及が見込まれる４Ｋなどの高品質なコンテンツを配布する配布メディアとしては、ビット単価の問題から光ディスクが活用されることが多いと考えられている。一方で、スマートフォン又はタブレット型コンピュータは、光ディスクドライブを持たないが、携帯性の高さ、大画面化及び高精細化を活かして、ネットワークを介して配信されるコンテンツを受信して再生する端末として利用されている。このため、スマートフォン又はタブレット型コンピュータではＭＰ４方式に対応することが多く、ＭＰＥＧ２−ＴＳ方式への対応は余り進んでいない。

光ディスクでのコンテンツの配布において、コンテンツの不正な漏洩を防止するため、光ディスク上には、暗号化されたコンテンツを記録する一方、暗号化されたコンテンツを復号するための鍵を記録せず、ネットワークを介して鍵を配信するケースが想定されている。

しかしながら、ネットワークを介して鍵を取得する際には、既にコンテンツが記録された光ディスクがあるにも関わらず、コンテンツを再生する前に鍵を取得する時間がかかるため、ユーザを待たせてしまう。また、鍵の配布経路は様々なケースが想定されるが、これら全ての経路を一つのプレーヤが対応することは困難である。

さらに、コンテンツをＭＰ４形式に変換する際にも、再生用の鍵とは異なる変換用の鍵をプレーヤが取得する必要がある。

ここで、光ディスクで配布されたＭＰＥＧ２−ＴＳ方式のコンテンツをスマートフォン又はタブレット型コンピュータにコピーする際には、ＭＰＥＧ２−ＴＳ方式で多重化されたコンテンツを一度、映像ストリーム、音声ストリーム及び字幕ストリームに戻した上で、改めてＭＰ４形式に変換する必要がある。一般的に、光ディスクで配布される商用コンテンツは暗号化されているが、形式を変換する際には、一旦復号してから形式を変換し、その後に再度暗号化する必要がある。このような復号及び暗号化処理は、変換機器での処理に時間がかかるとともに、一旦平文のコンテンツを作成することとなるためセキュリティの観点からも懸念がある。

また、特許文献１に記載の配信システムでは、コンテンツパーツはサーバによって配信され、媒体によって配布されるコンテンツのセキュリティを確保することについては開示されていない。同様に、特許文献２に記載のコンテンツ再生装置でも、コンテンツは放送ネットワークを介して配信され、媒体によって配布されるコンテンツのセキュリティを確保することについては開示されていない。

以上の考察に基づき、本発明者らは、本開示の各態様を想到するに至った。

本開示の一局面に係る再生装置は、媒体に記録されたコンテンツを再生する再生装置であって、前記媒体は、暗号化された複数の暗号化コンテンツと、前記複数の暗号化コンテンツの内の一部の暗号化コンテンツを再生するために必要となる第１の鍵情報とを記録しており、前記暗号化コンテンツを前記媒体から取得する暗号化コンテンツ取得部と、前記暗号化コンテンツを再生する前に、前記第１の鍵情報を用いて前記暗号化コンテンツを再生可能であるか否かを判断する鍵判断部と、前記鍵判断部によって前記暗号化コンテンツが再生可能であると判断された場合、前記第１の鍵情報を前記媒体から取得する第１の鍵情報取得部と、前記鍵判断部によって前記暗号化コンテンツが再生不可能であると判断された場合、前記暗号化コンテンツを再生するために必要となる第２の鍵情報を、ネットワークを介して取得する第２の鍵情報取得部と、前記第１の鍵情報又は前記第２の鍵情報を用いて前記暗号化コンテンツを復号して再生する再生部とを備え、前記再生部によって最初に再生される暗号化コンテンツは、前記第１の鍵によって暗号化されており、前記第２の鍵情報取得部は、前記再生部によって最初に再生される暗号化コンテンツが再生されている間に、前記第２の鍵情報を前記ネットワークを介して取得する。

この構成によれば、媒体は、暗号化された複数の暗号化コンテンツと、複数の暗号化コンテンツの内の一部の暗号化コンテンツを再生するために必要となる第１の鍵情報とを記録している。暗号化コンテンツが媒体から取得される。暗号化コンテンツが再生される前に、第１の鍵情報を用いて暗号化コンテンツを再生可能であるか否かが判断される。暗号化コンテンツが再生可能であると判断された場合、第１の鍵情報が媒体から取得される。一方、暗号化コンテンツが再生不可能であると判断された場合、暗号化コンテンツを再生するために必要となる第２の鍵情報が、ネットワークを介して取得される。そして、第１の鍵情報又は第２の鍵情報を用いて暗号化コンテンツが復号されて再生される。最初に再生される暗号化コンテンツは、第１の鍵によって暗号化されている。最初に再生される暗号化コンテンツが再生されている間に、第２の鍵情報がネットワークを介して取得される。

これにより、媒体に記録されている鍵を用いて最初に再生される暗号化コンテンツが再生され、最初に再生される暗号化コンテンツが再生されている間に、ネットワークを介して暗号化コンテンツを再生するのに必要な鍵が取得されるので、ネットワークを介して暗号化コンテンツの再生に必要な鍵を取得する時間を短縮することができ、媒体に記録されたコンテンツのセキュリティを強化することができる。

以下添付図面を参照しながら、本開示の実施の形態について説明する。なお、以下の実施の形態は、本開示を具体化した一例であって、本開示の技術的範囲を限定するものではない。

図１は、ＭＰＥＧ２−ＴＳ方式でコンテンツを光ディスクに格納する際のデータ構造を模式的に示す図である。光ディスク３は、コンテンツとしてＳｔｒｅａｍ Ｆｉｌｅを格納している。図１では、１つのＳｔｒｅａｍ Ｆｉｌｅのみを記載しているが、複数のＳｔｒｅａｍ Ｆｉｌｅが格納されてもよい。また、ここでは、Ｓｔｒｅａｍ Ｆｉｌｅは、「ＸＸＸＸＸ．Ｍ２ＴＳ」というファイル名で記録されている。「ＸＸＸＸＸ」には番号が記載され、複数のコンテンツが格納される場合に、個別に管理することが可能である。

各Ｓｔｒｅａｍ Ｆｉｌｅは、Ａｌｉｇｎｅｄ Ｕｎｉｔと呼ばれる単位で区分され、各Ａｌｉｇｎｅｄ Ｕｎｉｔの容量は６１４４Ｂｙｔｅｓである。Ａｌｉｇｎｅｄ Ｕｎｉｔが暗号化の単位となる。なお、Ｓｔｒｅａｍ Ｆｉｌｅに格納されるコンテンツは必ずしも６１４４Ｂｙｔｅｓの倍数にならない可能性もある。この場合には、末尾にＮＵＬＬ Ｄａｔａを格納する等の方法で、Ｓｔｒｅａｍ Ｆｉｌｅは６１４４Ｂｙｔｅｓの倍数にすることが望ましい。

図２は、Ａｌｉｇｎｅｄ Ｕｎｉｔの復号方法を説明するための図である。光ディスク３上のコンテンツは、ユニット鍵（図２ではＫｕと記載）と呼ばれるデータを用いて暗号化されている。ここで、各６１４４Ｂｙｔｅｓのデータは、先頭の１６Ｂｙｔｅｓのデータと残る６１２８Ｂｙｔｅｓのデータとに分離される。先頭の１６Ｂｙｔｅｓのデータは、先述したユニット鍵を用いてＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）暗号方式の復号処理が行われる（ＡＥＳ＿Ｅ）。こうして得られたデータと先頭の１６Ｂｙｔｅｓのデータとの排他的論理和（ＸＯＲ）が演算された上で、演算結果を鍵として、残る６１２８ＢｙｔｅｓのデータがＡＥＳ−ＣＢＣモードで復号される（ＡＥＳ＿ＤＣＢＣ）。こうして平文の６１２８Ｂｙｔｅｓのデータが得られるため、このデータに先頭１６Ｂｙｔｅｓのデータが付加されることで、６１４４Ｂｙｔｅｓの平文のデータが得られる。

図３は、ＭＰ４方式でコンテンツをＨＤＤ又はフラッシュメモリに格納する際のデータ構造を模式的に示す図である。ＨＤＤ又はフラッシュメモリ上には、コンテンツとしてＣｏｎｔｅｎｔ Ｆｉｌｅが格納される。Ｃｏｎｔｅｎｔ Ｆｉｌｅは、通常のデータファイルとして格納される。図３では、１つのＣｏｎｔｅｎｔ Ｆｉｌｅのみを記載しているが、複数のＣｏｎｔｅｎｔ Ｆｉｌｅが格納されてもよい。また、ここでは、Ｃｏｎｔｅｎｔ Ｆｉｌｅは、「ＸＸＸＸＸ．ＭＰ４」というファイル名で記録されている。「ＸＸＸＸＸ」には番号が記載され、複数のコンテンツが格納される場合に、個別に管理することが可能である。

各Ｃｏｎｔｅｎｔ Ｆｉｌｅの先頭部分には、可変長のバイト数のＭｅｔａ Ｄａｔａが記録される。Ｍｅｔａ Ｄａｔａの後には、Ｖｉｄｅｏ又はＡｕｄｉｏのＦｒａｇｍｅｎｔと呼ばれるデータが格納される。Ｆｒａｇｍｅｎｔは、通常数秒程度のエレメンタリストリームであり、Ｖｉｄｅｏの場合には単体でデコードが可能な単位となっている。各Ｆｒａｇｍｅｎｔは可変長のバイト数となっており、再生時間も各々異なっている。

Ｍｅｔａ Ｄａｔａには、各Ｆｒａｇｍｅｎｔのバイト数と再生時間長とが記載されている。プレーヤは、Ｍｅｔａ Ｄａｔａを参照することによって、先頭から特定時間の位置に相当するＦｒａｇｍｅｎｔを検索することが可能である。各Ｆｒａｇｍｅｎｔの再生時間長を累積することによって、指定時間に相当するＦｒａｇｍｅｎｔの番号を取得することができ、各Ｆｒａｇｍｅｎｔのバイト数を累積することによって、Ｃｏｎｔｅｎｔ Ｆｉｌｅ内でのバイト位置を計算することが可能である。

図４は、Ｃｏｎｔｅｎｔ Ｆｉｌｅ内の各Ｆｒａｇｍｅｎｔの復号に必要となるＩｎｉｔｉａｌ Ｖｅｃｔｏｒを模式的に示す図である。先述したＭｅｔａ Ｄａｔａの内部には、各Ｆｒａｇｍｅｎｔに対応するＩｎｉｔｉａｌ Ｖｅｃｔｏｒ（ＩＶ）が格納されている。Ｆｒａｇｍｅｎｔの順序通りにＩｎｉｔｉａｌ Ｖｅｃｔｏｒが格納されることによって、各Ｆｒａｇｍｅｎｔに対応するＩｎｉｔｉａｌ Ｖｅｃｔｏｒを特定することが可能である。

図５は、ＡＥＳ−ＣＴＲモードにおいて、Ｃｏｎｔｅｎｔ Ｆｉｌｅの暗号化について説明するための図である。図６は、ＡＥＳ−ＣＴＲモードにおいて、Ｃｏｎｔｅｎｔ Ｆｉｌｅの復号化について説明するための図である。暗号化の際には、鍵（Ｋｅｙ）と初期値であるＩＶ（Ｉｎｉｔｉａｌ Ｖｅｃｔｏｒ）とが用いられる。鍵を用いてＩＶを暗号化した値と、メッセージ（Ｃｏｎｔｅｎｔ Ｆｉｌｅ）の先頭の１６Ｂｙｔｅｓのデータとの排他的論理和（ＸＯＲ）が演算され、演算結果が最初の１６Ｂｙｔｅｓのデータに対応する暗号文となる。次の１６Ｂｙｔｅｓのデータに対しては、ＩＶをインクリメントした上で、同様の処理が行われる。このような処理が連続して行われることで、１６Ｂｙｔｅｓ以上の長いメッセージに対しても暗号文を作成することが可能である。なお、メッセージの長さが１６Ｂｙｔｅｓの倍数になっていない場合には、末尾のブロックにおいてＸＯＲ演算がビット単位で行われることによって、暗号文が得られる。

図６の復号化の処理は、図５に示す暗号化の処理と全く同じになっている。特に、復号化であるにも関わらず暗号化処理（ＥＮＣ）が行われることに注意が必要である。

ここで、図５及び図６でＫｅｙと示したデータがＭＰ４形式のＣｏｎｔｅｎｔ Ｆｉｌｅを暗号化及び復号化する際の鍵となる。

図７は、図１で示したＳｔｒｅａｍ Ｆｉｌｅに加えて、各Ｓｔｒｅａｍ Ｆｉｌｅを復号するための鍵を記録するためのデータであるＫｅｙ Ｆｉｌｅのデータ構成を模式的に示す図である。光ディスク３は、Ｓｔｒｅａｍ Ｆｉｌｅとは別にＫｅｙ Ｆｉｌｅを格納している。図７の例では、「Ｓｔｒｅａｍ Ｆｉｌｅ＃１」、「Ｓｔｒｅａｍ Ｆｉｌｅ＃２」及び「Ｓｔｒｅａｍ Ｆｉｌｅ＃３」の３つのファイルが光ディスク３上に記録されている。Ｋｅｙ Ｆｉｌｅは、各Ｓｔｒｅａｍ Ｆｉｌｅに対応したＫｅｙを含む。図７の例では、Ｋｅｙ Ｆｉｌｅは、「Ｓｔｒｅａｍ Ｆｉｌｅ＃１」、「Ｓｔｒｅａｍ Ｆｉｌｅ＃２」及び「Ｓｔｒｅａｍ Ｆｉｌｅ＃３」のそれぞれに対応する「Ｋｅｙ＃１」、「Ｋｅｙ＃２」及び「Ｋｅｙ＃３」を含む。

ここで、例えば、Ｋｅｙ＃１には、その値として「Ｙ！４．ｄ」という値が格納されている。プレーヤがＳｔｒｅａｍ Ｆｉｌｅを復号する場合には、先述した鍵としてこの値を利用する。なお、ここでは、光ディスク３は鍵を直接格納するとしたが、実際には鍵を平文で格納することはなく、別途各プレーヤが保持するデバイス鍵で暗号化した状態で記録される。

次に、図７の例では、「Ｓｔｒｅａｍ Ｆｉｌｅ＃２」及び「Ｓｔｒｅａｍ Ｆｉｌｅ＃３」に対応する「Ｋｅｙ＃２」及び「Ｋｅｙ＃３」の値は「ｎｕｌｌ」となっている。すなわち、「ｎｕｌｌ」は、鍵が記録されていないことを意味している。これは、このままでは「Ｓｔｒｅａｍ Ｆｉｌｅ＃２」及び「Ｓｔｒｅａｍ Ｆｉｌｅ＃３」を再生できないことを意味している。

さて、図７で述べたように、「Ｓｔｒｅａｍ Ｆｉｌｅ＃２」及び「Ｓｔｒｅａｍ Ｆｉｌｅ＃３」に対応する鍵は光ディスク３上には記録されていないため、このままでは再生することができない。よって、プレーヤは、これらのＳｔｒｅａｍ Ｆｉｌｅを再生するための鍵を図８で示す方法を用いて取得する。

図８は、コンテンツ再生システムの構成を模式的に示す図である。コンテンツ再生システムは、プレーヤ１と、鍵管理サーバ２とを備える。鍵管理サーバ２は、鍵管理サーバ２のサブモジュールとしてデータベース２１を備える。データベース２１は、鍵情報と、鍵送信不可リストとを格納している。

プレーヤ１は、Ｓｔｒｅａｍ Ｆｉｌｅを再生するための鍵が存在しない場合に、鍵管理サーバ２に対して鍵の発行を要求する。この際に、プレーヤ１と鍵管理サーバ２との間で認証処理が行われる。認証処理には、例えば、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）方式などを利用することが可能である。認証によって、相互に相手の機器をセキュアに確認することが可能となる。

鍵管理サーバ２は、認証により確認された相手側のプレーヤ１が鍵送信不可対象であるか否かを、鍵送信不可リストを用いて確認する。鍵送信不可リストは、鍵を送信することが許可されていないプレーヤを識別するための情報を格納している。プレーヤ１は、鍵の発行を要求する際に、自身の識別子を送信する。鍵管理サーバ２は、プレーヤ１の識別子を受信し、鍵送信不可リストに格納された情報を用いて鍵送信不可対象であるか否かを判断する。鍵送信不可対象であると判断した場合には、相手のプレーヤ１が信用できないプレーヤであるとして、鍵管理サーバ２は鍵を発行しない。勿論、認証そのものが失敗した場合にも、鍵管理サーバ２は鍵を発行しない。

プレーヤ１は、ローカルストレージ１１を備える。鍵がプレーヤ１に対して発行された場合には、鍵管理サーバ２は、発行された鍵をプレーヤ１に送信する。プレーヤ１は、鍵管理サーバ２によって送信された鍵を受信し、受信した鍵をローカルストレージ１１に格納する。これによって、これ以降に同じ光ディスク３を再生する場合には、プレーヤ１は、鍵管理サーバ２から鍵を取得することなく、ローカルストレージ１１から鍵を取得することにより、光ディスク３を再生することが可能となる。なお、ローカルストレージ１１は、プレーヤ１が保持するデバイス鍵を用いて取得した鍵を暗号化した状態で格納することが好ましい。これにより、取得した鍵を安全に保護することができる。

なお、ローカルストレージ１１に格納された鍵が誤って削除されたり、ローカルストレージ１１の不調などによって鍵が消去されたりした場合には、プレーヤ１は、改めて鍵管理サーバ２に鍵の発行を要請することによって、再度鍵を取得することも可能である。

図９は、プレーヤ１が光ディスク３上のＳｔｒｅａｍ Ｆｉｌｅをローカルストレージ１１に格納する動作を模式的に示す図である。ここでは、Ｓｔｒｅａｍ Ｆｉｌｅ＃２及びＳｔｒｅａｍ Ｆｉｌｅ＃３のみをローカルストレージ１１に格納するケースを記載している。これは、例えば、Ｓｔｒｅａｍ Ｆｉｌｅ＃１がメニューなどを表すコンテンツであり、Ｓｔｒｅａｍ Ｆｉｌｅ＃２が本編映像を表すコンテンツであり、Ｓｔｒｅａｍ Ｆｉｌｅ＃３がボーナス映像を表すコンテンツである場合に、繰り返し見る可能性があるコンテンツ（Ｓｔｒｅａｍ Ｆｉｌｅ＃２及びＳｔｒｅａｍ Ｆｉｌｅ＃３）のみをコピーすることに相当する。

既に、図８で述べたように、Ｓｔｒｅａｍ Ｆｉｌｅを復号するための鍵はローカルストレージ１１に保護して格納することが可能である。Ｓｔｒｅａｍ Ｆｉｌｅをローカルストレージ１１に記録する方法と、鍵をローカルストレージ１１に記録する方法とを組み合わせることによって、光ディスク３が存在しない場合でも、Ｓｔｒｅａｍ Ｆｉｌｅを再生することが可能となる。

図１０は、プレーヤ１が光ディスク上のＳｔｒｅａｍ Ｆｉｌｅを全く別のＤＲＭ（Ｄｉｇｉｔａｌ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ）システムにエクスポートする動作について模式的に示す図である。ここでは、エクスポートするために、ＭＰＥＧ２−ＴＳ形式のＳｔｒｅａｍ ＦｉｌｅがＭＰ４形式のＣｏｎｔｅｎｔ Ｆｉｌｅに変換される。変換に際しては、単にＡＥＳの暗号モードを、例えばＣＢＣ（Ｃｉｐｈｅｒ Ｂｌｏｃｋ Ｃａｉｎｉｎｇ）モードからＣＴＲ（Ｃｏｕｎｔｅｒ）モードに変更するだけではなく、鍵を変更してもよい。

図１０において、プレーヤ１の復号部１０１は、Ｓｔｒｅａｍ Ｆｉｌｅをローカルストレージ１１ａから取得し、さらに鍵をローカルストレージ１１ｂから取得する。ここで、復号部１０１は、図２で示した復号方法によって、Ｓｔｒｅａｍ Ｆｉｌｅを復号する。なお、ローカルストレージ１１ａとローカルストレージ１１ｂとは、同一のストレージであっても、異なるストレージであってもよい。

復号部１０１が復号することで平文となったＳｔｒｅａｍ ＦｉｌｅはＭＰＥＧ２−ＴＳ形式のデータである。復号部１０１は、ＭＰＥＧ２−ＴＳ形式のデータの多重化をほどくことによって、Ｖｉｄｅｏ又はＡｕｄｉｏのエレメンタリストリームを取得することができる。そして、復号部１０１は、取得したエレメンタリストリームを改めてＦｒａｇｍｅｎｔ単位で多重化することによって、平文のＭＰ４形式のＣｏｎｔｅｎｔ Ｆｉｌｅを得ることが可能である。

次に、プレーヤ１の暗号化部１０２は、暗号化の際に用いる鍵を鍵管理サーバ２から取得する。ここで、鍵管理サーバ２は、再生するための鍵を取得した鍵管理サーバと同じでもよいし、異なってもよい。再生のための鍵管理サーバ２では、光ディスクに対応した鍵を必ず発行しなければ、プレーヤ１での再生が保障されない。これに対して、エクスポートのための鍵管理サーバ２では必ずしも再生時と同じ鍵を発行する必要はなく、ランダムな値を鍵として発行することも可能である。ただし、この場合でも、鍵がプレーヤ１から漏洩した際に、漏洩元を特定するなどの目的で、鍵管理サーバ２は、発行した鍵の値を記録しておくことが望ましい。

プレーヤ１の暗号化部１０２は、鍵管理サーバ２から取得した鍵を用いて、平文のＭＰ４形式のＣｏｎｔｅｎｔ Ｆｉｌｅを暗号化し、暗号化したＣｏｎｔｅｎｔ Ｆｉｌｅをエクスポート先のＨＤＤ１１ｃに書き込む。

図１１は、図１０でエクスポート先のメディアに格納されたＣｏｎｔｅｎｔ Ｆｉｌｅをメディアにバインドするために必要となる処理を模式的に示す図である。プレーヤ１は、バインド用の鍵管理サーバ２に問い合わせて、バインドするために必要となるデータを要求する。この際に、プレーヤ１は、メディアを識別するためのメディアＩＤなどの情報を送付する。これに対して、鍵管理サーバ２は、メディアＩＤを鍵で処理してバインド用の鍵データを作成する。鍵管理サーバ２が、作成したバインド用の鍵データをプレーヤ１に通知し、プレーヤ１がメディアに格納することによって、Ｃｏｎｔｅｎｔ Ｆｉｌｅがメディアにバインドされる。

図１２は、本実施の形態におけるプレーヤの構成を示すブロック図である。

図１２に示すプレーヤ１は、暗号化コンテンツ取得部１００１、鍵判断部１００２、第１の鍵情報取得部１００３、第２の鍵情報取得部１００４、再生部１００５、鍵情報記憶部１００６及びアドレス情報記憶部１００７を備える。

暗号化コンテンツ取得部１００１は、暗号化コンテンツを光ディスク３から取得する。光ディスク３は、暗号化された複数の暗号化コンテンツと、複数の暗号化コンテンツの内の一部の暗号化コンテンツを再生するために必要となる第１の鍵情報とを記録している。なお、図７に示す「Ｋｅｙ」が、第１の鍵情報に相当する。

鍵判断部１００２は、暗号化コンテンツの復号に、光ディスク３に記録されている第１の鍵情報を用いるか否かを判断する。第１の鍵情報を用いないと判断された場合、ネットワークを介して取得する第２の鍵情報を用いることを意味する。光ディスク３は、複数の暗号化コンテンツ毎に、光ディスク上の第１の鍵情報を用いるか、ネットワークを介して取得する第２の鍵情報を用いるかを判断するために用いるコンテンツ暗号化情報を含む。鍵判断部１００２は、光ディスク３上のコンテンツ暗号化情報を参照して判断する。コンテンツ暗号化情報は、例えば、後述するＳｔｒｅａｍ Ｆｉｌｅ暗号化情報である。Ｓｔｒｅａｍ Ｆｉｌｅ暗号化情報は、Ｓｔｒｅａｍ Ｆｉｌｅを復号するためにネットワーク接続が必要であるか否かを示す。つまり、鍵判断部１００２は、Ｓｔｒｅａｍ Ｆｉｌｅ暗号化情報がネットワーク接続必要を示す場合、第２の鍵情報を用いると判断する。鍵判断部１００２は、Ｓｔｒｅａｍ Ｆｉｌｅ暗号化情報がネットワーク接続不要を示す場合、第１の鍵情報を用いると判断する。また、コンテンツ暗号化情報は、例えば、Ｓｔｒｅａｍ Ｆｉｌｅ毎に、第１鍵情報の格納有無を示す情報である。つまり、鍵判断部１００２は、コンテンツ暗号化情報が第１鍵情報の格納ありを示す場合、第１の鍵情報を用いると判断する。鍵判断部１００２は、コンテンツ暗号化情報が第１鍵情報の格納なしを示す場合、第２の鍵情報を用いると判断する。また、図７の「Ｋｅｙ」の値が「ｎｕｌｌ」の場合、鍵が記録されていないことを意味している。つまり、鍵判断部１００２は、「Ｋｅｙ」の値が「ｎｕｌｌ」の場合、第２の鍵情報を用いると判断する。鍵判断部１００２は、「Ｋｅｙ」の値が「ｎｕｌｌ」でない場合、第１の鍵情報を用いると判断する。

第１の鍵情報取得部１００３は、第１の鍵情報を光ディスク３から取得する。

第２の鍵情報取得部１００４は、暗号化コンテンツを再生するために必要となる第２の鍵情報を、鍵管理サーバ２からネットワークを介して取得する。なお、図８に示す鍵が、第２の鍵情報に相当する。

再生部１００５は、第１の鍵情報又は第２の鍵情報を用いて暗号化コンテンツを復号して再生する。

光ディスク挿入後に、再生部１００５によって最初に再生される暗号化コンテンツは、第１の鍵によって暗号化されている。第２の鍵情報取得部１００４は、再生部１００５によって最初に再生される暗号化コンテンツが再生されている間に、光ディスクに記録されている他の暗号化コンテンツを復号するための第２の鍵情報を鍵管理サーバ２からネットワークを介して取得する。

鍵情報記憶部１００６は、第２の鍵情報取得部１００４によって取得された第２の鍵情報を記憶する。第２の鍵情報取得部１００４は、取得した第２の鍵情報を前記鍵情報記憶部１００６に記憶する。第２の鍵情報取得部１００４は、鍵判断部１００２によってネットワークを介して取得する第２の鍵情報を用いると判断された場合、既に、鍵情報記憶部１００６に第２の鍵情報が記憶されているか否かを判断する。鍵情報記憶部１００６に第２の鍵情報が記憶されていると判断された場合、第２の鍵情報取得部１００４は、鍵情報記憶部１００６から第２の鍵情報を取得し、鍵情報記憶部１００６に第２の鍵情報が記憶されていないと判断された場合、ネットワークを介して第２の鍵情報を取得する。

アドレス情報記憶部１００７は、第２の鍵情報を発行する鍵管理サーバ２のネットワーク上のアドレスを示すアドレス情報を記憶する。なお、アドレス情報については後述するが、例えばＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｖｅ Ｌｏｃａｔｏｒ）で表される。第２の鍵情報取得部１００４は、鍵判断部１００２によってネットワークを介して取得する第２の鍵情報を用いると判断された場合、アドレス情報記憶部１００７に記憶されているアドレス情報に対応する鍵管理サーバ２から第２の鍵情報を取得する。

なお、光ディスク３は、光ディスク３を識別するための媒体識別情報を記憶してもよい。アドレス情報記憶部１００７は、アドレス通知サーバのネットワーク上のアドレスを示す第２のアドレス情報を記憶してもよい。アドレス通知サーバは、媒体識別情報に対応付けられている第２の鍵情報を発行する鍵管理サーバ２のネットワーク上のアドレスを示す第１のアドレス情報を通知する機能を有する。第２の鍵情報取得部１００４は、鍵判断部１００２によってネットワークを介して取得する第２の鍵情報を用いると判断された場合、アドレス情報記憶部１００７に記憶されている第２のアドレス情報に対応するアドレス通知サーバへ媒体識別情報を送信し、アドレス通知サーバから第１のアドレス情報を取得し、取得した第１のアドレス情報に対応する鍵管理サーバ２から第２の鍵情報を取得する。

また、光ディスク３は、第２の鍵情報を発行する鍵管理サーバ２のネットワーク上のアドレスを示すアドレス情報を記録してもよい。第２の鍵情報取得部１００４は、鍵判断部１００２によってネットワークを介して取得する第２の鍵情報を用いると判断された場合、光ディスク３に記録されているアドレス情報に対応する鍵管理サーバ２から第２の鍵情報を取得する。この場合、アドレス情報記憶部１００７はなくてもよい。

図１３は、本実施の形態における再生処理を説明するためのフローチャートである。

まず、光ディスク３がプレーヤに挿入され、処理を開始する。

ステップＳ１において、暗号化コンテンツ取得部１００１は、暗号化コンテンツを光ディスク３から取得する。このとき、光ディスク３がプレーヤに挿入されてから最初に再生される暗号化コンテンツは予め決められている。

次に、ステップＳ２において、鍵判断部１００２は、コンテンツ暗号化情報を参照し、光ディスク３内の第１の鍵情報を用いるか否かを判断する。光ディスク挿入後に最初に再生される暗号化コンテンツは、予め決められており、光ディスク３内の第１の鍵情報を用いて再生される。

光ディスク３内の第１の鍵情報を用いると判断された場合（ステップＳ２でＹＥＳ）、第１の鍵情報取得部１００３は、第１の鍵情報を光ディスク３から取得する。

一方、光ディスク３内の第１の鍵情報を用いないと判断された場合（ステップＳ２でＮＯ）、ステップＳ４において、第２の鍵情報取得部１００４は、暗号化コンテンツを再生するために必要となる第２の鍵情報を、鍵管理サーバ２からネットワークを介して取得する。第２の鍵情報取得部１００４は、取得した第２の鍵情報をローカルストレージ１１に格納する。

次に、ステップＳ５において、再生部１００５は、第１の鍵情報又は第２の鍵情報を用いて暗号化コンテンツを復号して再生を開始する。

次に、ステップ６において、最初に再生される暗号化コンテンツが再生されている間に、鍵判断部１００２は、光ディスク３内に他の暗号化コンテンツがあるか否かを判断する。

光ディスク３内に他の暗号化コンテンツがあると判断された場合（ステップ６でＹＥＳ）、他の暗号化コンテンツ毎に、次の処理を繰り返す。ステップＳ７において、鍵判断部１００２は、コンテンツ暗号化情報を参照し、光ディスク３内の第１の鍵情報を用いるか、ネットワークを介して取得する第２の鍵情報を用いるかを判断する。ネットワークを介して取得する第２の鍵情報を用いると判断された場合（ステップＳ７でＮＯ）、ステップ８において、第２の鍵情報取得部１００４は、他の暗号化コンテンツを再生するために必要となる第２の鍵情報を、鍵管理サーバ２からネットワークを介して取得する。第２の鍵情報取得部１００４は、取得した第２の鍵情報をローカルストレージ１１に格納する。

一方、光ディスク３内の第１の鍵情報を用いると判断された場合（ステップＳ７でＹＥＳ）、ステップＳ６の処理に戻る。

以上により、プレーヤ１は、最初に再生される暗号化コンテンツが再生されている間に、暗号化コンテンツを再生するために必要となる第２の鍵情報を、鍵管理サーバ２からネットワークを介して取得する。

なお、図１３では、ステップ２において、鍵判断部１００２は、コンテンツ暗号化情報を参照し、光ディスク３内の第１の鍵情報を用いるか否かを判断している。しかしながら、光ディスク３がプレーヤ１に挿入されてから最初に再生される暗号化コンテンツは、通常、光ディスク３内の第１の鍵情報を用いて再生される。このため、ステップ２の判断を行わず、ステップ３の処理を行ってもよい。また、常にステップ２の判断を行う実装でもよい。

続いて、光ディスクの１つであるＢＤ（Ｂｌｕ−ｒａｙ（登録商標） Ｄｉｓｃ）−ＲＯＭの構成について説明する。

図１４は、光ディスクの１例であるＢＤ−ＲＯＭの構成を示す図である。

図１４において、ＢＤ−ＲＯＭ２０１は、トラック２０２を有している。トラック２０２は、ＢＤ−ＲＯＭ２０１の内周側から外周側にかけて螺旋状に形成されており、図１４に示すトラック２０２は、横方向に引き伸ばして描画されている。ＢＤ−ＲＯＭ２０１は、例えばＤＶＤ又はＣＤなどの他の光ディスクと同様に、内周側から外周側に向けてらせん状に記録領域を有している。ＢＤ−ＲＯＭ２０１は、内周側に設けられたリードイン領域と、外周側に設けられたリードアウト領域と、リードイン領域とリードアウト領域との間に設けられた論理データを記録できるボリューム領域とを有している。

ボリューム領域は、先頭からＢＤ−ＲＯＭ２０１をアクセスする単位で通し番号が振られており、この番号は、論理アドレスと呼ばれる。ＢＤ−ＲＯＭ２０１からのデータの読み出しは論理アドレスを指定することで行われる。論理アドレスは、ＢＤ−ＲＯＭ２０１上の物理的な配置においても、連続していると定義する。すなわち、論理アドレスが連続しているデータはシークを行わずに読み出すことが可能である。また、リードイン領域の内側にはＢＣＡ（Ｂｕｒｓｔ Ｃｕｔｔｉｎｇ Ａｒｅａ）と呼ばれるドライブでしか読み出せない特別な領域がある。ＢＣＡはアプリケーションから読み出せないため、例えば著作権保護技術などに利用される。

ボリューム領域には、先頭からファイルシステムのボリューム情報が記録され、続いて映像データなどのアプリケーションデータが記録されている。ファイルシステムとは、ディスク上のデータをディレクトリ又はファイルと呼ばれる単位で表現する仕組みである。ＢＤ−ＲＯＭ２０１の場合、ＵＤＦ（Ｕｎｉｖｅｒｓａｌ Ｄｉｓｃ Ｆｏｒｍａｔ）によってデータが記録される。ＰＣ（パーソナルコンピュータ）でも、ＦＡＴ（Ｆｉｌｅ Ａｌｌｏｃａｔｉｏｎ Ｔａｂｌｅ）又はＮＴＦＳ（ＮＴ Ｆｉｌｅ Ｓｙｓｔｅｍ）と呼ばれるファイルシステムが用いられることにより、ディレクトリ又はファイルという構造でハードディスクに記録されたデータがコンピュータ上で表現され、ユーザビリティを高めている。このファイルシステムにより、通常のＰＣと同じように記録されている論理データをディレクトリ又はファイル構造を使って読み出すことが可能になっている。

ＢＤ−ＲＯＭ２０１上のディレクトリ又はファイル構造では、ルートディレクトリ（ＲＯＯＴ）の直下にＢＤＭＶディレクトリが置かれている。ＢＤＭＶディレクトリは、ＢＤ−ＲＯＭ２０１で扱うＡＶコンテンツ又は管理情報などのデータが記録されているディレクトリである。ＢＤＭＶディレクトリの下には、タイトルを構成するインデックステーブルが定義されたインデックスファイル（ｉｎｄｅｘ．ｂｄｍｖ）、ＰＬＡＹＬＩＳＴディレクトリ、ＣＬＩＰＩＮＦＯディレクトリ、ＳＴＲＥＡＭディレクトリ、ＰＲＯＧＲＡＭディレクトリ、ＢＤＪＯディレクトリ及びＪＡＲディレクトリが存在する。

映像及び音声といったＡＶコンテンツが多重化され格納されたＡＶクリップ（ＸＸＸ．Ｍ２ＴＳ）は、ＳＴＲＥＡＭディレクトリの下に配置される。ＡＶクリップの管理情報を格納したクリップ情報ファイル（ＸＸＸ．ＣＬＰＩ）は、ＣＬＩＰＩＮＦＯディレクトリの下に配置される。ＡＶクリップの論理的な再生経路を定義したプレイリストファイル（ＹＹＹ．ＭＰＬＳ）は、ＰＬＡＹＬＩＳＴディレクトリの下に配置される。動的なシナリオを定義するためのプログラムが格納されたＢＤプログラムファイル（ＡＡＡ．ＰＲＧ）は、ＰＲＯＧＲＡＭディレクトリの下に配置される。

以下に、ＢＤＭＶディレクトリ配下に置かれる各ファイルのデータ構造について説明する。

まず、インデックスファイル（Ｉｎｄｅｘ．ｂｄｍｖ）について説明する。図１５は、インテックステーブルの一例を示す図である。インデックスファイルは、図１５に示すインデックステーブルを有する。インデックステーブルは、ＢＤ−ＲＯＭに格納されるすべてのタイトル、トップメニュー及びＦｉｒｓｔＰｌａｙといったタイトル構成を定義する最上位層のテーブルである。インデックステーブルには、全てのタイトル、トップメニュー及びＦｉｒｓｔＰｌａｙから最初に実行されるプログラムファイルが指定されている。

ＢＤ−ＲＯＭのプレーヤは、タイトル又はメニューが呼び出されるたびにインデックステーブルを参照して、所定のＢＤプログラムファイルを実行する。ここで、ＦｉｒｓｔＰｌａｙは、コンテンツプロバイダによって設定されるＢＤプログラムファイルであり、ディスク投入時に最初に自動的に実行される。また、トップメニューは、リモコンでのユーザ操作により、「メニューに戻る」というようなコマンドが実行されるときに、呼び出されるムービーオブジェクト又はＢＤＪオブジェクトが指定されている。

ＢＤプログラムファイル（ＡＡＡ．ＰＲＧ）は、タイトルから指定及び実行されるプログラムを格納している。複数のプログラムのファイルがあり、プリフィックス（ＡＡＡ）がプログラムを識別するのに使用される。ブルーレイディスクでは、コマンドナビゲーションと呼ばれる独自仕様のインタープリタ方式のプログラムが使われるが、言語方式は本開示の本質ではないため、プログラミング言語は、Ｊａｖａ（登録商標）又はＪａｖａＳｃｒｉｐ（登録商標）のような汎用のプログラミング言語であっても構わない。このプログラムによって再生されるプレイリストが指定される。

次に、図１６を用いて、ネットワーク経由で鍵を取得する際に、取得に時間がかかってしまい、手元に既に光ディスクがあってすぐに再生が可能であるにも関わらずユーザを待たせてしまうという問題を解決する手法について説明する。

図１６は、本実施の形態においてプログラムファイルを実行する手順について説明するための図である。

ここで、光ディスクが挿入されたときにＦｉｒｓｔＰｌａｙから再生されるＳｔｒｅａｍ Ｆｉｌｅ＃１を復号するための鍵は、ネットワークから取得されない。これは、プレーヤが最初に再生するＦｉｒｓｔ Ｐｌａｙを再生するために、Ｓｔｒｅａｍ Ｆｉｌｅ＃１を復号する鍵をネットワークから取得すると、再生開始までに時間を要してしまうことを回避するためである。また、通常、Ｆｉｒｓｔ Ｐｌａｙから再生されるコンテンツは、映画本編ではなく、映画のトレーラー又は映画スタジオの紹介であり、タイトルから再生されるコンテンツに比べて重要性が低い。そのため、ネットワーク経由で鍵を取得することによってセキュリティを高めるよりも、ディスク挿入時に素早く再生が開始される利点を得ることの方が重要である。

ＦｉｒｓｔＰｌａｙから再生されるＳｔｒｅａｍ Ｆｉｌｅ＃１を復号するための鍵は、光ディスク上の情報及びプレーヤの情報のうちのいずれか又は両方を用いて取得される。Ｓｔｒｅａｍ Ｆｉｌｅ＃１を復号するための鍵が、ネットワークから配信されることはない。

次に、トップメニューから再生されるＳｔｒｅａｍ Ｆｉｌｅ＃２を復号する鍵も、ネットワークから取得されないことが望ましい。トップメニューから再生されるコンテンツは、ユーザがディスク視聴中に言語設定などを変えるため使用されることが多く、例えば映画再生中でも言語設定を変えたい場合などにアクセスされる対象である。そのため、ネットワークから鍵を取得することによって、トップメニューの表示が遅れることはユーザを待たせることになり、好ましくない。

そのため、トップメニューから再生されるＳｔｒｅａｍ Ｆｉｌｅ＃２を復号するための鍵は、光ディスク上の情報及びプレーヤの情報のうちのいずれか又は両方を用いて取得される。Ｓｔｒｅａｍ Ｆｉｌｅ＃２を復号するための鍵が、ネットワークから配信されることはない。

これに対して、タイトル１から再生されるＳｔｒｅａｍ Ｆｉｌｅ＃３を復号する鍵は、ネットワークから取得されてもよい。例えば、ＦｉｒｓｔＰｌａｙを再生中に、バックグラウンドの処理としてＳｔｒｅａｍ Ｆｉｌｅ＃３の復号に必要な鍵をネットワークから取得する。これにより、ネットワーク経由で鍵を取得するのに必要な処理時間を、短縮することが可能となる。

図１７は、図１６に示す光ディスク挿入時のコンテンツ再生システムのシーケンスの一例を示す図である。

プレーヤ１は、光ディスク３が挿入されると、Ｆｉｒｓｔ Ｐｌａｙを最初に再生するため、再生対象の暗号化コンテンツであるＳｔｒｅａｍ Ｆｉｌｅ＃１を光ディスク３から取得する。プレーヤ１は、Ｓｔｒｅａｍ Ｆｉｌｅ＃１を復号するための鍵（第１の鍵情報）を光ディスク３から取得し、取得した鍵を用いて暗号化コンテンツを復号し、ＦｉｒｓｔＰｌａｙの再生を開始する。

プレーヤ１は、ＦｉｒｓｔＰｌａｙを再生中に、バックグラウンドの処理として、光ディスク３上に鍵が記憶されていないタイトル１、タイトル２、タイトルｎから再生されるＳｔｒｅａｍ Ｆｉｌｅの復号に必要な鍵（第２の鍵情報）をネットワークから取得し、ローカルストレージ１１に格納する。

プレーヤ１は、Ｆｉｒｓｔ Ｐｌａｙの次にトップメニューを再生するため、再生対象の暗号化コンテンツであるＳｔｒｅａｍ Ｆｉｌｅ＃２を光ディスク３から取得する。プレーヤ１は、Ｓｔｒｅａｍ Ｆｉｌｅ＃２を復号するための鍵（第１の鍵情報）を光ディスク３から取得し、取得した鍵を用いて暗号化コンテンツを復号し、トップメニューの再生を開始する。

プレーヤ１は、トップメニュー再生中にタイトル１の再生が選択されると、再生対象の暗号化コンテンツであるＳｔｒｅａｍ Ｆｉｌｅ＃３を光ディスク３から取得する。プレーヤ１は、Ｓｔｒｅａｍ Ｆｉｌｅ＃３を復号するための鍵（第２の鍵情報）をローカルストレージ１１から取得し、取得した鍵を用いて暗号化コンテンツを復号し、タイトル１の再生を開始する。

図１８は、プレーヤがネットワークに接続されていない場合に表示される画面の一例を示す図である。従来のＢＤ−ＲＯＭディスクを再生する際には、ネットワークへの接続は必須ではなかった。しかしながら、図１６に示すタイトル１のように再生する対象のＳｔｒｅａｍ Ｆｉｌｅ＃３を復号するための鍵をネットワーク経由で取得する必要がある場合、ユーザに対して明確にネットワークへの接続が必要であることを通知する必要がある。このため、図１６に示すＢＤプログラムファイル「００１．ＰＲＧ」は、プレーヤがネットワークに接続されているか否かを判断する処理と、プレーヤがネットワークに接続されていないと判断された場合、ユーザに対して図１８に示す画面を提示する処理とを含むことが望ましい。

次に、Ｓｔｒｅａｍ Ｆｉｌｅの復号に必要な鍵をネットワークから取得する際に、アクセスすべきネットワーク上のサーバを特定する方法について説明する。ネットワーク上のアクセス先は、ＵＲＬ又はＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスなどで表される。以下に、ＵＲＬを記録する位置及び鍵を取得する方法について説明する。

（１）第１の方法としては、光ディスク（例えば、Ｂｌｕ−ｒａｙディスク）の規格として鍵を発行するサーバのＵＲＬを予め決めておき、プレーヤ製造時にＵＲＬをプレーヤが備える不揮発性のメモリに記憶する。この場合、鍵を発行するネットワークサーバ（鍵管理サーバ）に対して複数のプレーヤから鍵発行の依頼が来ると、ネットワークサーバの負荷が増大する可能性がある。

これを解決するには、光ディスクの規格として鍵を発行する複数のネットワークサーバ（鍵管理サーバ）を用意し、機器毎又は後述するリージョンコード毎に異なるネットワークサーバのＵＲＬを設定すればよい。

（２）第２の方法としては、光ディスク（例えば、Ｂｌｕ−ｒａｙディスク）の規格として鍵を取得するために最初にアクセスする第１のサーバの第１のＵＲＬを予め決めておき、プレーヤは、第１のＵＲＬに対応する第１のサーバにアクセスし、光ディスクのＳｔｒｅａｍ Ｆｉｌｅを復号するための鍵を発行する第２のサーバの第２のＵＲＬを第１のサーバから取得する。

プレーヤは、最初にアクセスすべき第１のＵＲＬを予め記憶する不揮発性のメモリを備える。プレーヤは、実際に鍵を取得する際には、第１のＵＲＬとは異なる第２のＵＲＬに対応する第２のサーバに接続する。これにより、鍵を管理するネットワークサーバ（鍵管理サーバ）の負荷を分散できる。

ディスク毎にアクセス先を変えるには、ディスクを特定するための情報をサーバに通知する必要がある。プレーヤは、ディスクに記録されている情報（例えば、ディスク製作者を示すＩＤ又はディスクに一意に与えられるＩＤ）をネットワークサーバ（鍵管理サーバ）に通知する。

（３）第３の方法としては、光ディスクが、鍵を発行するサーバのＵＲＬを予め記録する。この場合、ディスク挿入時に最初に読み込まれるインデックステーブルに鍵の取得先となるＵＲＬを記録しておくことが望ましい。このように、プレーヤは、鍵を発行するサーバのＵＲＬをインデックステーブルに記録しておくことによって、前述したようにＦｉｒｓｔＰｌａｙの再生中のバックグランド処理としてＵＲＬに対応するサーバにアクセスし、鍵を取得することが可能となる。

また、光ディスクが、ネットワークから鍵を取得する必要があるＳｔｒｅａｍ Ｆｉｌｅと、ネットワークから鍵を取得する必要がないＳｔｒｅａｍ Ｆｉｌｅとを記録している場合に、図１６に示すようにタイトル毎にネットワークから鍵を取得するか否かを示す情報があってもよい。このように、タイトル毎にネットワークから鍵を取得するか否かを示すことにより、リモコンなどによって直接タイトルが指定された際でも、指定されたタイトルから再生されるＳｔｒｅａｍ Ｆｉｌｅを復号するための鍵をネットワーク経由で取得する必要があるか否かが容易に判定できる。

また、ネットワークから鍵を取得する必要があるタイトルは、鍵を取得する時間が必要であるため、再生開始までに時間がかかる。ここで、ＢＤ規格ではユーザが指定したタイトルを直接再生するタイトルサーチという機能が具備されている。そのため、ＦｉｒｓｔＰｌａｙが再生されることなく、特定のタイトルの再生が開始されることがある。このような場合、プレーヤは、ユーザによって指定されたタイトル（正確には、タイトルからＸＸＸ．ＭＰＬＳをたどって参照されるＳｔｒｅａｍ Ｆｉｌｅ）を再生するために、ネットワークから鍵を取得する必要があり、鍵の取得処理に要する時間を短縮することができない。これを防ぐために、ネットワークから鍵を取得するタイトルに対してのタイトルサーチは禁止することが望ましい。

また、光ディスクは、インデックステーブルを記載したファイルとは別に、復号のためにネットワークから鍵を取得する必要があるＳｔｒｅａｍ Ｆｉｌｅの一覧を示すファイルと、各Ｓｔｒｅａｍ Ｆｉｌｅを復号するための鍵のＵＲＬを記載したファイルとを備えてもよい。

また、各Ｓｔｒｅａｍ Ｆｉｌｅ中に復号に必要な鍵を取得可能なＵＲＬが記載されていてもよい。

また、Ｓｔｒｅａｍ Ｆｉｌｅを管理するファイル（ＡＶクリップ情報）に復号に必要な鍵を取得可能なＵＲＬが記載されていてもよい。

なお、鍵の取得先を示すＵＲＬを保持する場所は上記に限定されない。例えば、鍵の取得先を示すＵＲＬは、ＢＤ−ＲＯＭディスクに同梱される紙に記載されてもよく、再生時において、プレーヤは、ユーザによるＵＲＬの入力を受け付けてもよい。また、鍵の取得先を示すＵＲＬは、再生するコンテンツを記録したＢＤ−ＲＯＭディスクとは異なる媒体に記録してもよく、再生前に、プレーヤは、ＵＲＬを媒体から読み出してもよい。

次に、ネットワーク上の鍵の取得先（ＵＲＬ）を表すテーブルについて説明する。

図１９は、鍵の取得先を示すＵＲＬをリージョンコード毎に格納するテーブルの一例を示す図である。ここで、リージョンコードとは、当該光ディスクを再生できる地域を制限することを目的として地域毎に指定されているコードである。例えばＢｌｕ−ｒａｙディスクにおいては、リージョンコードＡには、南北アメリカ及び日本などが含まれ、リージョンコードＢには、ヨーロッパが含まれる。リージョンコードＡとして指定されたディスクは、リージョンコードＡ対応のプレーヤでしか再生できず、リージョンコードＢ対応プレーヤでは再生できない。

このように、プレーヤと、再生対象となる光ディスクとは、それぞれリージョンコードを有し、互いのリージョンコードが一致しないプレーヤでは再生できない。そのため、鍵の取得先は、リージョンコード毎に指定できることが望ましい。したがって、プレーヤは、図１９に示すテーブルを参照して、リージョンコード毎に異なるＵＲＬにアクセスして鍵を取得できる。このようにすることで、例えば、リージョンコードＡのプレーヤは、リージョンコードＡに対応付けられているＵＲＬ（ｗｗｗ．１２３４５．ｃｏｍ／ｋｅｙ＿ｒｅｇｉｏｎＡ）にアクセスして鍵を取得することで再生できる。一方、リージョンコードＡのプレーヤは、リージョンコードＢに対応付けられているＵＲＬ（ｗｗｗ．５４３２１．ｊｐ／ｋｅｙ＿ｒｅｇｉｏｎＢ）の鍵を無効にする。これにより、リージョンコードＢで指定される地域において再生を抑制することが可能となる。

図２０は、鍵の取得先を示すＵＲＬを国コード毎に格納するテーブルの一例を示す図である。ここでは記載していないが、Ｂｌｕ−ｒａｙディスクプレーヤには、ユーザの嗜好として、字幕又は音声に使用すべき言語が設定されている領域がある。また、プレーヤは、使用される国が設定される場合もある。図２０に示すテーブルは、国を示す国コードと、鍵を発行するＵＲＬとを対応付けて記憶している。

したがって、例えばプレーヤ又はＢＤプログラムは、ユーザの言語設定又は使用国設定と、図２０で示したテーブルとに基づいて、鍵の取得先のＵＲＬを切り替えることによって、リージョンコード毎ではなく、使用する言語又はプレーヤを使用する国毎により細かくコンテンツを再生するか否かを制御することが可能となる。つまり、字幕又は音声の言語設定として日本語が設定されているプレーヤは、日本で使用されているプレーヤであると判断され、「ＪＰ」の国コードで示されるＵＲＬ（ｗｗｗ．５４３２１．ｊｐ／ｋｅｙ＿ＪＰ）を取得し、当該ＵＲＬにアクセスして、復号に必要な鍵を取得する。

あるいは、鍵管理サーバ２は、前述のプレーヤ１の言語設定ではなく、プレーヤ１が保持しているＩＰアドレスからどこの国からアクセスしているか判断し、取得すべき国コードを判定して、判定した国コードに該当する鍵取得用ＵＲＬをプレーヤ１に送信してもよい。

つまり、鍵管理サーバ２は、プレーヤのＩＰアドレスが英国で使用されているアドレスであると判定された場合、「ＵＫ」の国コードに対応したＵＲＬ（ｗｗｗ．６７８９０．ｕｋ／ｋｅｙ＿ＵＫ）を送信してもよい。プレーヤは、受信したＵＲＬにアクセスして鍵を取得してもよい。

このように、国コード毎に鍵を取得すべきＵＲＬを変えることで、例えばある国の映画館でまだ上映中の映画が光ディスクに記録されている場合には、鍵管理サーバは、その国のプレーヤからの鍵取得要求を拒否する。これにより、映画の興行収入を担保するとともに、映画の上映期間終了後にネットワーク上で鍵を有効にすることによって、光ディスクからの再生を許可することも可能となる。

また、特定の国が判定できない場合、又は国毎の指定の必要がない場合にアクセスすべきＵＲＬとして図２０に示すようにＤｅｆａｕｌｔのＵＲＬが設定されていることが望ましい。

図２１は、鍵の取得先を示すＵＲＬをタイトル毎に格納するテーブルの一例を示す図である。図２０に示すテーブルは、光ディスク内に記録されているタイトルと、鍵を発行するＵＲＬとを対応付けて記憶している。このように、タイトル（コンテンツ）毎に鍵の取得先を変えることができるようにすることで、タイトル毎に鍵の付与を制御することも可能となる。

次に、プレイリストファイル（ＹＹＹ．ＭＰＬＳ）について説明する。図２２は、プレイリストファイルについて説明するための模式図である。

プレイリストは、ＡＶクリップの再生経路を示す。図２２に示すように、プレイリストは、１つ以上のプレイアイテム（ＰＩ）１２０１から構成される。各プレイアイテム１２０１は、ＡＶクリップに対する再生区間を示す。各プレイアイテム１２０１は、それぞれプレイアイテムＩＤで識別され、プレイリスト内で再生されるべき順序で記述されている。また、プレイリストは、再生開始点を示すエントリマーク１２０２を含む。エントリマーク１２０２は、プレイアイテムで定義される再生区間に対して付与される。エントリマーク１２０２は、図２２に示すように、プレイアイテムに対して再生開始点となりうる位置に付与され、頭出し再生に利用される。例えば、映画タイトルにおいて、エントリマーク１２０２をチャプタの先頭となる位置に付与することで、チャプタ再生することが可能である。なお、ここでは、一連のプレイアイテム１２０１の再生経路がメインパス１２０５と定義される。

プレイアイテムの内容について図２３を用いて説明する。図２３は、プレイアイテムについて説明するための模式図である。プレイアイテムは、再生するクリップ情報１３０１、再生開始時刻１３０２、再生終了時刻１３０３、コネクションコンディション１３１０、及びストリーム選択テーブル１３０５を含む。再生開始時刻１３０２及び再生終了時刻１３０３は時間情報であるため、プレーヤは、クリップ情報ファイルのエントリマップを参照し、指定された再生開始時刻及び再生終了時刻に対応するＳＰＮ（ソースパケット番号）を取得し、読み出し開始位置を特定し、再生処理を行う。

コネクションコンディション１３１０は、前方プレイアイテムと接続タイプとを示している。プレイアイテムのコネクションコンディション１３１０が「１」である場合は、プレイアイテムが指し示すＡＶクリップは、そのプレイアイテムの前のプレイアイテムが指し示すＡＶクリップとシームレスに接続されることが保証されない。プレイアイテムのコネクションコンディション１３１０が「５」又は「６」である場合は、プレイアイテムが指し示すＡＶクリップは、そのプレイアイテムの前のプレイアイテムが指し示すＡＶクリップとシームレスに接続されることが保証される。コネクションコンディション１３１０が「５」である場合は、プレイアイテム間でＳＴＣ（Ｓｙｓｔｅｍ Ｔｉｍｅ Ｃｌｏｃｋ）の連続性が途切れていてもよい。つまり、接続前プレイアイテムのＡＶクリップ終端のビデオ表示時刻と、接続後プレイアイテムのＡＶクリップ先頭のビデオ表示時刻とは、不連続でよい。

ストリーム選択テーブル１３０５は、複数のストリームエントリ１３０９で構成される。ストリームエントリ１３０９は、ストリーム選択番号１３０６、ストリームパス情報１３０７、及びストリーム識別情報１３０８を含む。

ストリーム選択番号１３０６は、ストリーム選択テーブルに含まれるストリームエントリ１３０９の先頭から順にインクリメントされる番号であり、プレーヤにおいてストリームを識別するために利用される。

ストリームパス情報１３０７は、ストリーム識別情報１３０８によって示されるストリームが、どのＡＶクリップに多重化されているかを示す情報である。例えば、ストリームパス情報１３０７が“メインパス”であれば、該当するプレイアイテムのＡＶクリップを示し、ストリームパス情報１３０７が“サブパスＩＤ＝１”であれば、そのサブパスＩＤが示すサブパスにおいて、該当するプレイアイテムの再生区間に対応するサブプレイアイテムのＡＶクリップを示す。

ストリーム識別情報１３０８は、ＰＩＤ（Ｐａｃｋｅｔ Ｉｄｅｎｔｉｆｉｅｒ）などの情報であり、参照するＡＶクリップに多重化されているストリームを示す。また、ストリームエントリ１３０９には、各ストリームの属性情報も同時に記録されている。ここで属性情報は、各ストリームの性質を示す情報であり、ストリームが例えばオーディオ、プレゼンテーショングラフィックス又はインタラクティブグラフィックスである場合には、言語属性などを含む。

ここで、プレイリストファイルが保持する１つ以上のプレイアイテムが参照する複数のＳｔｒｅａｍ Ｆｉｌｅを復号するための鍵は、全てネットワーク上から取得するか、全てネットワークから取得せずに光ディスクから取得するかのいずれかで統一することが望ましい。これは、あるプレイアイテムが参照するＳｔｒｅａｍ Ｆｉｌｅの復号にネットワークから取得する鍵を必要とし、別のプレイアイテムが参照するＳｔｒｅａｍ Ｆｉｌｅの復号にネットワークから取得する鍵を必要としない場合、鍵の入手経路がそれぞれ異なることによってプレーヤの処理が煩雑になることを避けるためである。

このように、プレイリストファイルから参照されるＳｔｒｅａｍ Ｆｉｌｅを復号するためにネットワークから鍵を取得するか否かを示すために、下記のようなＳｔｒｅａｍ Ｆｉｌｅ暗号化情報が光ディスク上、又はプレイリストファイルの一部に含まれてもよい。

Ｓｔｒｅａｍ Ｆｉｌｅ暗号化情報
０１ｂ：参照されるＳｔｒｅａｍ ｆｉｌｅの復号にネットワーク接続不要
１０ｂ：参照されるＳｔｒｅａｍ ｆｉｌｅの復号にネットワーク接続必要
１１ｂ：参照されるＳｔｒｅａｍ ｆｉｌｅの復号に、ネットワーク接続必要なＳｔｒｅａｍ ｆｉｌｅとネットワーク接続不要なＳｔｒｅａｍ ｆｉｌｅとが混在している。

なお、前述のような煩雑な鍵処理を回避するために、Ｓｔｒｅａｍ Ｆｉｌｅ暗号化情報の設定値「１１ｂ」は禁止しておくことが望ましい。

あるいは、設定値「１１ｂ」を許可する場合においても、第１のプレイアイテムと、第１のプレイアイテムに続く第２のプレイアイテムとがシームレスに接続される場合には、これら２つのプレイアイテムから参照される鍵の取得方法は同じであること、すなわち、ネットワークから取得するか、ネットワークから取得しないかのいずれかであることが望ましい。

また、１つのＳｔｒｅａｍ Ｆｉｌｅを復号する際に、光ディスク上の鍵と、ネットワーク上の鍵との両方を使う方法も考えられる。この場合、図２２で示したエントリマーク（一般にチャプタの先頭を示すことに使われる）の先頭部分の鍵が光ディスク上に保持されることによって、チャプタへ移動した際にネットワークからの鍵の取得を待たずに即座に再生することが可能となる。

なお、上述した具体的実施形態には以下の構成を有する発明が主に含まれている。

本開示の一局面に係る再生装置は、媒体に記録されたコンテンツを再生する再生装置であって、前記媒体は、暗号化された複数の暗号化コンテンツと、前記複数の暗号化コンテンツの内の一部の暗号化コンテンツを再生するために必要となる第１の鍵情報とを記録しており、前記暗号化コンテンツを前記媒体から取得する暗号化コンテンツ取得部と、前記暗号化コンテンツの復号に、前記第１の鍵情報を用いるか否かを判断する鍵判断部と、前記鍵判断部によって前記第１の鍵情報を用いると判断された場合、前記第１の鍵情報を前記媒体から取得する第１の鍵情報取得部と、前記鍵判断部によって前記第１の鍵情報を用いないと判断された場合、前記暗号化コンテンツを再生するために必要となる第２の鍵情報を、ネットワークを介して取得する第２の鍵情報取得部と、前記第１の鍵情報又は前記第２の鍵情報を用いて前記暗号化コンテンツを復号して再生する再生部とを備え、前記再生部によって最初に再生される暗号化コンテンツは、前記第１の鍵によって暗号化されており、前記第２の鍵情報取得部は、前記再生部によって最初に再生される暗号化コンテンツが再生されている間に、前記第２の鍵情報を前記ネットワークを介して取得する。

この構成によれば、媒体は、暗号化された複数の暗号化コンテンツと、複数の暗号化コンテンツの内の一部の暗号化コンテンツを再生するために必要となる第１の鍵情報とを記録している。暗号化コンテンツが媒体から取得される。暗号化コンテンツの復号に、第１の鍵情報を用いるか否かが判断される。第１の鍵情報を用いると判断された場合、第１の鍵情報が媒体から取得される。一方、第１の鍵情報を用いないと判断された場合、暗号化コンテンツを再生するために必要となる第２の鍵情報が、ネットワークを介して取得される。そして、第１の鍵情報又は第２の鍵情報を用いて暗号化コンテンツが復号されて再生される。最初に再生される暗号化コンテンツは、第１の鍵によって暗号化されている。最初に再生される暗号化コンテンツが再生されている間に、第２の鍵情報がネットワークを介して取得される。

したがって、媒体に記録されている鍵を用いて最初に再生される暗号化コンテンツが再生され、最初に再生される暗号化コンテンツが再生されている間に、ネットワークを介して暗号化コンテンツを再生するのに必要な鍵が取得されるので、ネットワークを介して暗号化コンテンツの再生に必要な鍵を取得する時間を短縮することができ、媒体に記録されたコンテンツのセキュリティを強化することができる。

また、上記の再生装置において、前記第２の鍵情報取得部によって取得された前記第２の鍵情報を記憶する鍵情報記憶部をさらに備え、前記第２の鍵情報取得部は、取得した前記第２の鍵情報を前記鍵情報記憶部に記憶し、前記第２の鍵情報取得部は、前記鍵判断部によって前記第１の鍵情報を用いないと判断された場合、前記鍵情報記憶部に前記第２の鍵情報が記憶されているか否かを判断し、前記鍵情報記憶部に前記第２の鍵情報が記憶されていると判断された場合、前記鍵情報記憶部から前記第２の鍵情報を取得することが好ましい。

この構成によれば、取得された第２の鍵情報が鍵情報記憶部に記憶される。そして、前記第１の鍵情報を用いないと判断された場合、鍵情報記憶部に第２の鍵情報が記憶されているか否かが判断され、鍵情報記憶部に第２の鍵情報が記憶されていると判断された場合、鍵情報記憶部から第２の鍵情報が取得される。

したがって、取得された第２の鍵情報が鍵情報記憶部に記憶されるので、２回目以降に暗号化コンテンツを再生する際に、既に取得した第２の鍵情報を用いて再生することができ、ネットワークを介して暗号化コンテンツの再生に必要な鍵を取得する時間を省略することができる。

また、上記の再生装置において、前記第２の鍵情報取得部によって取得された前記第２の鍵情報を記憶する鍵情報記憶部をさらに備え、前記鍵判断部は、前記再生部によって最初に再生される暗号化コンテンツが再生されている間に、前記媒体に記録されている前記複数の暗号化コンテンツの内、前記最初に再生される暗号化コンテンツ以外の他の暗号化コンテンツに対し、前記他の暗号化コンテンツの復号に、前記第１の鍵情報を用いるか否かを判断し、前記第２の鍵情報取得部は、前記鍵判断部によって前記第１の鍵情報を用いないと判断された場合、前記他の暗号化コンテンツを再生するために必要となる前記第２の鍵情報を前記ネットワークを介して取得し、取得した前記第２の鍵情報を、前記鍵情報記憶部に格納することが好ましい。

この構成によれば、取得された第２の鍵情報が鍵情報記憶部に記憶される。最初に再生される暗号化コンテンツが再生されている間に、媒体に記録されている複数の暗号化コンテンツの内、最初に再生される暗号化コンテンツ以外の他の暗号化コンテンツに対し、他の暗号化コンテンツの復号に、第１の鍵情報を用いるか否かが判断される。そして、第１の鍵情報を用いないと判断された場合、他の暗号化コンテンツを再生するために必要となる第２の鍵情報がネットワークを介して取得され、取得された第２の鍵情報が、鍵情報記憶部に格納される。

したがって、最初に再生される暗号化コンテンツが再生されている間に、他の暗号化コンテンツを再生するために必要となる第２の鍵情報をネットワークを介して取得することができる。

また、上記の再生装置において、前記第２の鍵情報を発行するサーバの前記ネットワーク上のアドレスを示すアドレス情報を記憶するアドレス情報記憶部をさらに備え、前記第２の鍵情報取得部は、前記鍵判断部によって前記第１の鍵情報を用いないと判断された場合、前記アドレス情報記憶部に記憶されている前記アドレス情報に対応する前記サーバから前記第２の鍵情報を取得することが好ましい。

この構成によれば、第２の鍵情報を発行するサーバのネットワーク上のアドレスを示すアドレス情報がアドレス情報記憶部に記憶されている。そして、第１の鍵情報を用いないと判断された場合、アドレス情報記憶部に記憶されているアドレス情報に対応するサーバから第２の鍵情報が取得される。

したがって、再生装置内に記憶されているアドレス情報に対応するサーバから第２の鍵情報が取得されるので、媒体内にアドレス情報を記録する必要がなく、媒体に記録するデータの量を削減することができる。

また、上記の再生装置において、前記媒体は、前記媒体を識別するための媒体識別情報を記憶しており、前記媒体識別情報に対応付けられている前記第２の鍵情報を発行する第１のサーバの前記ネットワーク上のアドレスを示す第１のアドレス情報を通知する第２のサーバの前記ネットワーク上のアドレスを示す第２のアドレス情報を記憶するアドレス情報記憶部をさらに備え、前記第２の鍵情報取得部は、前記鍵判断部によって前記第１の鍵情報を用いないと判断された場合、前記アドレス情報記憶部に記憶されている前記第２のアドレス情報に対応する前記第２のサーバへ前記媒体識別情報を送信し、前記第２のサーバから前記第１のアドレス情報を取得し、取得した前記第１のアドレス情報に対応する前記第１のサーバから前記第２の鍵情報を取得することが好ましい。

この構成によれば、媒体は、媒体を識別するための媒体識別情報を記憶している。また、媒体識別情報に対応付けられている第２の鍵情報を発行する第１のサーバのネットワーク上のアドレスを示す第１のアドレス情報を通知する第２のサーバのネットワーク上のアドレスを示す第２のアドレス情報がアドレス情報記憶部に記憶されている。そして、第１の鍵情報を用いないと判断された場合、アドレス情報記憶部に記憶されている第２のアドレス情報に対応する第２のサーバへ媒体識別情報が送信され、第２のサーバから第１のアドレス情報が取得され、取得された第１のアドレス情報に対応する第１のサーバから第２の鍵情報が取得される。

したがって、第２の鍵情報を発行する第１のサーバから直接第２の鍵情報を取得するのではなく、第１のサーバのネットワーク上のアドレスを示す第１のアドレス情報を通知する第２のサーバに一度アクセスしてから、第１のサーバにアクセスするので、第１のサーバのネットワーク負荷を軽減することができる。

また、上記の再生装置において、前記媒体は、前記第２の鍵情報を発行するサーバの前記ネットワーク上のアドレスを示すアドレス情報を記録しており、前記第２の鍵情報取得部は、前記鍵判断部によって前記第１の鍵情報を用いないと判断された場合、前記媒体に記録されている前記アドレス情報に対応する前記サーバから前記第２の鍵情報を取得することが好ましい。

この構成によれば、媒体は、第２の鍵情報を発行するサーバのネットワーク上のアドレスを示すアドレス情報を記録している。そして、第１の鍵情報を用いないと判断された場合、媒体に記録されているアドレス情報に対応するサーバから第２の鍵情報が取得される。

したがって、媒体内に記録されているアドレス情報に対応するサーバから第２の鍵情報が取得されるので、再生装置内にアドレス情報を記録する必要がなく、再生装置に記憶するデータの量を削減することができる。

また、上記の再生装置において、前記媒体は、前記複数の暗号化コンテンツ毎に前記第１の鍵情報を用いて再生可能であるか否かを示すコンテンツ暗号化情報を含み、前記鍵判断部は、前記コンテンツ暗号化情報を参照し、前記暗号化コンテンツの復号に、前記第１の鍵情報を用いるか否かを判断することが好ましい。

この構成によれば、媒体は、複数の暗号化コンテンツ毎に第１の鍵情報を用いて再生可能であるか否かを示すコンテンツ暗号化情報を含む。そして、コンテンツ暗号化情報が参照され、暗号化コンテンツの復号に、第１の鍵情報を用いるか否かが判断される。

したがって、第１の鍵情報を用いるか否かを容易に判断することができる。

本開示の他の局面に係る再生方法は、媒体に記録されたコンテンツを再生する再生方法であって、前記媒体は、暗号化された複数の暗号化コンテンツと、前記複数の暗号化コンテンツの内の一部の暗号化コンテンツを再生するために必要となる第１の鍵情報とを記録しており、前記暗号化コンテンツを前記媒体から取得する暗号化コンテンツ取得ステップと、前記暗号化コンテンツの復号に、前記第１の鍵情報を用いるか否かを判断する鍵判断ステップと、前記鍵判断ステップにおいて前記第１の鍵情報を用いると判断された場合、前記第１の鍵情報を前記媒体から取得する第１の鍵情報取得ステップと、前記鍵判断ステップにおいて前記第１の鍵情報を用いないと判断された場合、前記暗号化コンテンツを再生するために必要となる第２の鍵情報を、ネットワークを介して取得する第２の鍵情報取得ステップと、前記第１の鍵情報又は前記第２の鍵情報を用いて前記暗号化コンテンツを復号して再生する再生ステップとを含み、前記再生ステップにおいて最初に再生される暗号化コンテンツは、前記第１の鍵によって暗号化されており、前記第２の鍵情報取得ステップは、前記再生ステップにおいて最初に再生される暗号化コンテンツが再生されている間に、前記第２の鍵情報を取得する。

この構成によれば、媒体は、暗号化された複数の暗号化コンテンツと、複数の暗号化コンテンツの内の一部の暗号化コンテンツを再生するために必要となる第１の鍵情報とを記録している。暗号化コンテンツが媒体から取得される。暗号化コンテンツの復号に、第１の鍵情報を用いるか否かが判断される。第１の鍵情報を用いると判断された場合、第１の鍵情報が媒体から取得される。一方、第１の鍵情報を用いないと判断された場合、暗号化コンテンツを再生するために必要となる第２の鍵情報が、ネットワークを介して取得される。そして、第１の鍵情報又は第２の鍵情報を用いて暗号化コンテンツが復号されて再生される。最初に再生される暗号化コンテンツは、第１の鍵によって暗号化されている。最初に再生される暗号化コンテンツが再生されている間に、第２の鍵情報がネットワークを介して取得される。

したがって、媒体に記録されている鍵を用いて最初に再生される暗号化コンテンツが再生され、最初に再生される暗号化コンテンツが再生されている間に、ネットワークを介して暗号化コンテンツを再生するのに必要な鍵が取得されるので、ネットワークを介して暗号化コンテンツの再生に必要な鍵を取得する時間を短縮することができ、媒体に記録されたコンテンツのセキュリティを強化することができる。

本開示に係る再生装置及び再生方法は、ネットワークを介して暗号化コンテンツの再生に必要な鍵を取得する時間を短縮することができ、媒体に記録されたコンテンツのセキュリティを強化することができ、媒体に記録されたコンテンツを再生する再生装置及び再生方法として有用である。

１ プレーヤ
２ 鍵管理サーバ
３ 光ディスク
１１ ローカルストレージ
２１ データベース
１０１ 復号部
１０２ 暗号化部
１００１ 暗号化コンテンツ取得部
１００２ 鍵判断部
１００３ 鍵情報取得部
１００４ 鍵情報取得部
１００５ 再生部
１００６ 鍵情報記憶部
１００７ アドレス情報記憶部

Claims (8)

1. 媒体に記録されたコンテンツを再生する再生装置であって、
   前記媒体は、暗号化された複数の暗号化コンテンツと、前記複数の暗号化コンテンツの内の一部の暗号化コンテンツを再生するために必要となる第１の鍵情報とを記録しており、
   前記暗号化コンテンツを前記媒体から取得する暗号化コンテンツ取得部と、
   前記暗号化コンテンツの復号に、前記第１の鍵情報を用いるか否かを判断する鍵判断部と、
   前記鍵判断部によって前記第１の鍵情報を用いると判断された場合、前記第１の鍵情報を前記媒体から取得する第１の鍵情報取得部と、
   前記鍵判断部によって前記第１の鍵情報を用いないと判断された場合、前記暗号化コンテンツを再生するために必要となる第２の鍵情報を、ネットワークを介して取得する第２の鍵情報取得部と、
   前記第１の鍵情報又は前記第２の鍵情報を用いて前記暗号化コンテンツを復号して再生する再生部とを備え、
   前記再生部によって最初に再生される暗号化コンテンツは、前記第１の鍵によって暗号化されており、
   前記第２の鍵情報取得部は、前記再生部によって最初に再生される暗号化コンテンツが再生されている間に、前記第２の鍵情報を前記ネットワークを介して取得する、
   再生装置。
2. 前記第２の鍵情報取得部によって取得された前記第２の鍵情報を記憶する鍵情報記憶部をさらに備え、
   前記第２の鍵情報取得部は、取得した前記第２の鍵情報を前記鍵情報記憶部に記憶し、
   前記第２の鍵情報取得部は、前記鍵判断部によって前記第１の鍵情報を用いないと判断された場合、前記鍵情報記憶部に前記第２の鍵情報が記憶されているか否かを判断し、前記鍵情報記憶部に前記第２の鍵情報が記憶されていると判断された場合、前記鍵情報記憶部から前記第２の鍵情報を取得する、
   請求項１記載の再生装置。
3. 前記第２の鍵情報取得部によって取得された前記第２の鍵情報を記憶する鍵情報記憶部をさらに備え、
   前記鍵判断部は、前記再生部によって最初に再生される暗号化コンテンツが再生されている間に、前記媒体に記録されている前記複数の暗号化コンテンツの内、前記最初に再生される暗号化コンテンツ以外の他の暗号化コンテンツに対し、前記他の暗号化コンテンツの復号に、前記第１の鍵情報を用いるか否かを判断し、
   前記第２の鍵情報取得部は、前記鍵判断部によって前記第１の鍵情報を用いないと判断された場合、前記他の暗号化コンテンツを再生するために必要となる前記第２の鍵情報を前記ネットワークを介して取得し、取得した前記第２の鍵情報を、前記鍵情報記憶部に格納する、
   請求項１記載の再生装置。
4. 前記第２の鍵情報を発行するサーバの前記ネットワーク上のアドレスを示すアドレス情報を記憶するアドレス情報記憶部をさらに備え、
   前記第２の鍵情報取得部は、前記鍵判断部によって前記第１の鍵情報を用いないと判断された場合、前記アドレス情報記憶部に記憶されている前記アドレス情報に対応する前記サーバから前記第２の鍵情報を取得する、
   請求項１又は２記載の再生装置。
5. 前記媒体は、前記媒体を識別するための媒体識別情報を記憶しており、
   前記媒体識別情報に対応付けられている前記第２の鍵情報を発行する第１のサーバの前記ネットワーク上のアドレスを示す第１のアドレス情報を通知する第２のサーバの前記ネットワーク上のアドレスを示す第２のアドレス情報を記憶するアドレス情報記憶部をさらに備え、
   前記第２の鍵情報取得部は、前記鍵判断部によって前記第１の鍵情報を用いないと判断された場合、前記アドレス情報記憶部に記憶されている前記第２のアドレス情報に対応する前記第２のサーバへ前記媒体識別情報を送信し、前記第２のサーバから前記第１のアドレス情報を取得し、取得した前記第１のアドレス情報に対応する前記第１のサーバから前記第２の鍵情報を取得する、
   請求項１又は２記載の再生装置。
6. 前記媒体は、前記第２の鍵情報を発行するサーバの前記ネットワーク上のアドレスを示すアドレス情報を記録しており、
   前記第２の鍵情報取得部は、前記鍵判断部によって前記第１の鍵情報を用いないと判断された場合、前記媒体に記録されている前記アドレス情報に対応する前記サーバから前記第２の鍵情報を取得する、
   請求項１又は２記載の再生装置。
7. 前記媒体は、前記複数の暗号化コンテンツ毎に前記第１の鍵情報を用いるか否かを示すコンテンツ暗号化情報を含み、
   前記鍵判断部は、前記コンテンツ暗号化情報を参照し、前記暗号化コンテンツの復号に、前記第１の鍵情報を用いるか否かを判断する、
   請求項１〜６のいずれかに記載の再生装置。
8. 媒体に記録されたコンテンツを再生する再生方法であって、
   前記媒体は、暗号化された複数の暗号化コンテンツと、前記複数の暗号化コンテンツの内の一部の暗号化コンテンツを再生するために必要となる第１の鍵情報とを記録しており、
   前記暗号化コンテンツを前記媒体から取得する暗号化コンテンツ取得ステップと、
   前記暗号化コンテンツの復号に、前記第１の鍵情報を用いるか否かを判断する鍵判断ステップと、
   前記鍵判断ステップにおいて前記第１の鍵情報を用いると判断された場合、前記第１の鍵情報を前記媒体から取得する第１の鍵情報取得ステップと、
   前記鍵判断ステップにおいて前記第１の鍵情報を用いないと判断された場合、前記暗号化コンテンツを再生するために必要となる第２の鍵情報を、ネットワークを介して取得する第２の鍵情報取得ステップと、
   前記第１の鍵情報又は前記第２の鍵情報を用いて前記暗号化コンテンツを復号して再生する再生ステップとを含み、
   前記再生ステップにおいて最初に再生される暗号化コンテンツは、前記第１の鍵によって暗号化されており、
   前記第２の鍵情報取得ステップは、前記再生ステップにおいて最初に再生される暗号化コンテンツが再生されている間に、前記第２の鍵情報を取得する、
   再生方法。

Images