(57)【要約】  デジタルシネマパッケージにおける復号鍵情報を提供するための方法およびシステムが開示される。少なくとも復号鍵のソースに関連する情報がデジタルシネマパッケージに含まれる。
2015507403.tif 000002
【特許請求の範囲】
【請求項１】
デジタルシネマパッケージにおけるコンテンツを復号するための復号鍵の少なくとも１つのソースに関連する鍵ソース情報
を備える、デジタルシネマパッケージ。
【請求項２】
前記鍵ソース情報が、前記デジタルシネマパッケージにおける少なくとも１つのファイル内に提供される、請求項１に記載のデジタルシネマパッケージ。
【請求項３】
前記ファイルが、既存の規格に準拠した形式を有する、請求項１に記載のデジタルシネマパッケージ。
【請求項４】
前記鍵ソース情報が、アセットマップ、パッキングリスト、コンポジションプレイリスト、およびアセットトラックファイルの内の少なくとも１つから選択されたファイル内に提供される、請求項１に記載のデジタルシネマパッケージ。
【請求項５】
前記鍵ソース情報が、前記復号鍵の少なくとも１つの場所と、前記復号鍵を取得する方法と、を示す、請求項１に記載のデジタルシネマパッケージ。
【請求項６】
前記鍵ソース情報が、少なくとも１つのＵＲＬを含むテキストとして提供される、請求項１に記載のデジタルシネマパッケージ。
【請求項７】
前記少なくとも１つのＵＲＬが、電子メールアドレス、電話番号、ファイル転送プロトコルサーバ、および、ハイパーテキスト転送プロトコルサーバ、の内の少なくとも１つを識別する、請求項６に記載のデジタルシネマパッケージ。
【請求項８】
デジタルシネマパッケージにおけるコンテンツを復号するための復号鍵の少なくとも１つのソースに関連する鍵ソース情報を提供するステップであって、前記鍵ソース情報が前記デジタルシネマパッケージにおいて提供される、前記ステップ、
を含む、デジタルシネマコンテンツの復号鍵情報を提供する方法。
【請求項９】
前記鍵ソース情報を、前記デジタルシネマパッケージにおける少なくとも１つのファイル内に提供するステップ、
をさらに含む、請求項８に記載の方法。
【請求項１０】
前記ファイルを、既存の規格に準拠した形式で提供するステップ
をさらに含む、請求項９に記載の方法。
【請求項１１】
前記鍵ソース情報を、アセットマップ、パッキングリスト、コンポジションプレイリスト、およびアセットトラックファイルの内の少なくとも１つから選択されるファイル内に提供するステップ
をさらに含む、請求項９に記載の方法。
【請求項１２】
前記鍵ソース情報が、前記復号鍵の少なくとも１つの場所と、前記復号鍵を取得する方法と、を示す、請求項８に記載の方法。
【請求項１３】
前記鍵ソース情報を、少なくとも１つのＵＲＬを含むテキストとして提供するステップ
をさらに含むことを特徴とする請求項８に記載の方法。
【請求項１４】
前記少なくとも１つのＵＲＬが、電子メールアドレス、電話番号、ファイル転送プロトコルサーバ、および、ハイパーテキスト転送プロトコルサーバ、の内の少なくとも１つを識別する、請求項１３に記載の方法。
【請求項１５】
前記鍵ソース情報およびデジタルシネマパッケージが第１のサーバに提供され、
前記デジタルシネマパッケージのコンポジションプレイリストを選択するステップであって、前記コンポジションプレイリストが前記デジタルシネマパッケージにおける少なくとも１つのアセットトラックファイルを識別する、前記選択するステップと、
前記選択されたコンポジションプレイリストと、前記少なくとも１つのアセットトラックファイルと、を前記第１のサーバから第２のサーバに転送するステップと、
前記コンポジションプレイリストに対応するコンテンツを復号することに関して前記復号鍵を検索する際に使用するために前記鍵ソース情報を前記第１のサーバから前記第２のサーバに転送するステップと、
をさらに含む、請求項８に記載の方法。
【請求項１６】
前記コンポジションプレイリストが前記鍵ソース情報を含む、請求項１５に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
（他の出願の相互参照）
本出願は、２０１１年１２月１４日に出願された米国特許仮出願第６１／５７０，７８１号「デジタルシネマ復号鍵を自動的に取得するための方法および装置」の優先権を主張し、その全体が参照によりここに組み込まれる。
【０００２】
本発明は、デジタルシネマのコンテンツを復号するための復号鍵を取得するための方法及び装置に関する。
【背景技術】
【０００３】
ほとんどのスタジオは、上映前に映画館主により取得される復号鍵を必要とする、暗号化されたデジタルシネマ作品またはコンテンツを制作する。鍵とデジタルシネマ作品は、一緒に配給されることは無い。作品は、スタジオがサードパーティの配給業者に提供することが多く、該業者は、映画館主に鍵を提供する業者であってもそうでなくてもよい。配給業者（鍵提供業者であってよい）がスタジオから独立しているため、上映時刻が近付き、鍵がまだ取得されていない場合に、誰とコンタクトを取るのかについて混乱が生じ得る。
【０００４】
概して、デジタルシネマコンテンツの公開に必要な復号鍵は、事前に鍵配給者により適切な映画館主に送られる。この処理が失敗したときや、映画館主が時間間際に作品の上映に合意した場合、映画館職員は、１つまたは複数の鍵配給者にコンタクトを取り、どのエンティティが鍵の提供が可能であるかを判断する。しかし、鍵配給者の正体が映画館主に分からない場合、映画館職員は、他の配給者またはスタジオに尋ねることにより、正しい配給者を判断しなければならない。そのような処理には、相当な量の映画公開および配給者またはスタジオリソースを消費するという欠点があり、かつ、鍵の到着が映画公開の時間に間に合わず、スクリーンが暗いままになるという状況にしばしばなる。時間間際に鍵取得の作業がなされると、鍵が見つけられ（または作成され）、５〜１０分以内で送信されることが可能であるが、全体的に、現行の実務は信頼性が無く、係わる全ての人に多くのストレスがかかる。
【０００５】
鍵配給システムのうち、ある態様は、Ｗａｌｋｅｒらによる「Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｋｅｙ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  ｆｏｒ  Ｓｅｃｕｒｅ  Ｄｉｇｉｔａｌ  Ｃｉｎｅｍａ  ｐｒｅｓｅｎｔａｔｉｏｎｓ（安全なデジタルシネマ上演の鍵配給のための方法および装置）」と題する同一出願人の米国特許出願第２００９／０１９６４２６号に教示され、その全体が参照により本明細書に組み込まれる。Ｗａｌｋｅｒらによると、鍵配給のための所定のソースが、推測され、または映画館主に対して公表される。しかし、復号鍵のソースに関する情報を提供する代替のアプローチに対する必要性が、現在進行的に存在する。
【発明の概要】
【０００６】
本発明は、デジタルシネマパッケージ（Ｄｉｇｉｔａｌ  Ｃｉｎｅｍａ  Ｐａｃｋａｇｅ：ＤＣＰ、以下ＤＣＰ）における暗号化された作品のための復号鍵の少なくとも１つのソースに関する情報を提供する方法およびシステムに関し、復号鍵を受信していない場合に、映画館主が容易に鍵配給エンティティを識別できるようにする。ＤＣＰは、ぞれぞれの暗号化された作品または構成物（コンポジション）について、復号鍵のソースへの１つまたは複数のリファレンスを提供する。鍵ソースリファレンスまたは情報は、暗号化された作品に関連してデジタルシネマサーバまたは劇場管理システムにより維持され、鍵が作品上演のために取得される必要があるときに、鍵ソース情報および復号鍵が自動的に回収可能となるようにする。鍵ソース情報は、異なるフォーマットで、既存の規格と整合する種々のファイル内に、または、既存の業界規格に準拠しない新しい鍵ソースファイル内に、含まれてよい。
【０００７】
一実施形態により、デジタルシネマパッケージが提供され、該パッケージはデジタルシネマパッケージにおけるコンテンツを復号するための復号鍵の少なくとも１つのソースに関する鍵ソース情報を含む。
【０００８】
別の実施形態は、デジタルシネマコンテンツの復号鍵情報を提供する方法に関する。方法には、デジタルシネマパッケージにおけるコンテンツを復号するための復号鍵の少なくとも１つのソースに関する鍵ソース情報を提供するステップであって、鍵ソース情報がデジタルシネマパッケージ内に提供される、ステップを含む。
【図面の簡単な説明】
【０００９】
本発明の教示は、添付の図面と併せて以下の詳細な説明を考察することにより容易に理解することが可能である。
【図１】本発明の一実施形態に従う、デジタルシネマ復号鍵を提供するためのシステムを示すブロック図である。
【図２】鍵提供者システムの詳細を示すブロック図である。
【図３】従来技術のアセットマップファイルの一部分の例である。
【図４】本発明の一実施形態に従う、アセットマップファイルの一部分の例であり、ＣＰＬのａｎｎｏｔａｔｉｏｎ  ｔｅｘｔ（注釈テキスト）内の鍵のソースを識別している。
【図５】本発明の一実施形態に従う、アセットマップファイルの一部分の別の例であり、ＣＰＬのアセット要素に関連するコメントフィールド内の鍵のソースを識別している。
【図６】本発明の一実施形態に従う、アセットマップファイルの一部分のさらに別の例であり、ＣＰＬのアセット要素に関連する特定のＸＭＬタグ内のソースを識別している。
【図７】デジタルシネマパッケージにおける鍵ソース情報に基づく暗号化された作品のための復号鍵を取得する一実施形態を説明する図である。
【図８】暗号化された作品に関連する鍵ソースをトラッキングし、鍵ソースから復号鍵を取得して作品を再生する、一実施形態を説明する図である。
【図９】暗号化された作品および関連する鍵ソースを提供する別の実施形態を説明する図である。
【００１０】
理解を容易にするために、可能な場合には、同一の参照番号を使用して、図面に共通する同一の要素を示す。
【発明を実施するための形態】
【００１１】
ニューヨーク州ホワイトプレーンズの映画テレビ技術者協会（Ｔｈｅ  Ｓｏｃｉｅｔｙ  ｏｆ  Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  ａｎｄ  Ｔｅｌｅｖｉｓｉｏｎ  Ｅｎｇｉｎｅｅｒｓ：ＳＭＰＴＥ、以下ＳＭＰＴＥ）は、多数の規格を作成および確立して、デジタルシネマの成功を推進してきた。以下のＳＭＰＴＥ規格書には、デジタルシネマのパッケージングおよび公開に関する情報が含まれる。  
ＳＴ  ０４２９−３−２００７  Ｄ−シネマパッケージング−サウンドおよび映像のトラックファイル
ＳＴ  ０４２９−５−２００９  Ｄ−シネマパッケージング−タイムドテキストトラックファイル
ＳＴ  ０４２９−７−２００６  Ｄ−シネマパッケージング−コンポジションプレイリスト
ＳＴ  ０４２９−８−２００７  Ｄ−シネマパッケージング−パッキングリスト
ＳＴ  ０４２９−９−２００７  Ｄ−シネマパッケージング−アセットマッピングおよびファイルセグメンテーション
ＳＴ  ０４２９−２−２００９  Ｄ−シネマパッケージング−ＤＣＰ操作制約
ＳＴ  ０４２９−６−２００６  Ｄ−シネマパッケージング−ＭＸＦトラックファイルエッセンス暗号化
ＳＴ  ０４３０−１−２００６  Ｄ−シネマオペレーションズ−鍵配信メッセージ、および
ＳＴ  ０４３０−２−２００６  Ｄ−シネマオペレーションズ−デジタル証明書
【００１２】
本発明のより良い理解を支援するために、デジタルシネマパッケージングに関する背景を以下に示す。デジタルシネマパッケージ（ＤＣＰ）には、典型的には多くの構成要素が含まれ、アセットトラックファイル、音声トラックファイル、コンポジションプレイリスト（ｃｏｍｐｏｓｉｔｉｏｎ  ｐｌａｙｌｉｓｔ：ＣＰＬ、以下ＣＰＬ）、鍵配信メッセージ（ｋｅｙ  ｄｅｌｉｖｅｒｙ  ｍｅｓｓａｇｅ：ＫＤＭ、以下ＫＤＭ）、パッキングリスト（ｐａｃｋｉｎｇ  ｌｉｓｔ：ＰＫＬ、以下ＰＫＬ）、およびアセットマップファイルなどが含まれる。本明細書での検討は、上記でリストアップしたＳＭＰＴＥ規格の観点から提示されるが、ＭＰＥＧ  Ｉｎｔｅｒｏｐ  ｉｎｉｔｉａｔｉｖｅにより記載されるＭＰＥＧ  Ｉｎｔｅｒｏｐ  Ｐａｃｋａｇｉｎｇ  Ｓｐｅｃｉｆｉｃａｔｉｏｎなど、業界で使用される他の事実上の規格が、本発明における使用について同様に適合性のある同様の構成要素を有する。
【００１３】
アセットトラックファイルには、少なくとも１リールの作品のシングルタイプの映像、音声またはテキストのアセットが含まれる。（デジタルシネマでは、１リールは少なくとも１秒の表示であり、一般的には最大約２０分であるが、もっと長くてもよい。）アセットトラックファイルは、映像、音声、サブタイトル、または字幕のアセットの他に、他の構造的かつ記述的な情報を含む標準化されたＸＭＬファイルである。映像トラックファイルは、映画リールの少なくとも各フレームに対して１つの個別の画像を、または、映画が立体３Ｄの場合は各フレームに対して２つの画像を含む。音声トラックファイルは、少なくとも映画リールの期間中の音声の各チャンネルに対して、１秒当たり４８，０００個（および、９６，０００個の場合もある）の音声サンプルを含む。これは、代替の言語のトラックファイルについても同様である。字幕およびいくつかのサブタイトルは、トラックファイルのテキストとして提供され（他のサブタイトルファイルはテキストの映像を含む）、テキストの適切な色、および、いつ、どこで、どのくらいの期間、そのテキスト（または、テキストの映像）を表示させるのかを示すデータである。各トラックファイルは、グローバル一意識別番号（ＧＵＩＤ）を有し、一義的に参照されうる。
【００１４】
暗号化された作品または表示に関し、トラックファイル内の映像、音声、または、サブタイトルおよび字幕のアセットを表すデータは、暗号化され（しかし、データを記述するメタデータ、およびデータを含むＸＭＬ構造は暗号化されない）、従って、海賊行為の脅威を制限することができる。異なる鍵を使用して、アセットトラックファイルのそれぞれを暗号化し、これらの同じ鍵がプレイアウトのアセットを復号するのに必要である。
【００１５】
コンポジションプレイリスト、すなわちＣＰＬファイルは、種々のアセットトラックファイルと、一貫性のある上演を提供するために必要なトラックファイルの順番とを識別する標準化されたＸＭＬデータ構造である。１作品の１つまたは複数のリールのそれぞれについて、ＣＰＬは、映像、音声、および、任意の代替の言語、サブタイトル、または字幕のトラックファイルを、それらの対応するＧＵＩＤを使用して正確に識別し、かつ、それらのトラック内に入口点および出口点をさらに含み、異なるアセット間の精密な同期を提供する（例えば、音声が映像と同期し、登場人物が話す時にサブタイトルが現れるように）。
【００１６】
ＣＰＬは、暗号化されず（現行の規格では、ＣＰＬが参照する、映像、音声トラックなどのアセットトラックファイルのみが暗号化されうる）、通常は、作成権限者、典型的には、スタジオ、またはスタジオが承認するポストプロダクションパッケージング企業、が提供する安全なデジタル署名を有する。この署名は、映画館主およびスタジオに、ＣＰＬ内に示される構成物が、本物であり、意図される通りに厳密に上映されることを保証する。それぞれ個別のＣＰＬが、自身のグローバル一意識別番号（ＧＵＩＤ）を有する。
【００１７】
暗号化された作品の各アセットトラックファイルが異なる鍵で暗号化されて、特定のＣＰＬにより表される作品を再生するために必要な複数の復号鍵が、鍵配信メッセージ、すなわちＫＤＭに含まれる。上記の規格によると、ＫＤＭは別のＸＭＬファイルである。ＫＤＭは、実際にはデジタルシネマ業界において安全なラッパー内の複数の鍵の集合であるけれども、ＫＤＭは「鍵」（単数または複数）と呼ばれることがある。個々のアセットトラックファイルを暗号化および復号するための実際の暗号化鍵は、裸で（安全なラッパー無しで）送られ、あるいはそれ自身により送信されることはないことに留意すべきである。
【００１８】
本発明の文脈において、復号鍵すなわちＫＤＭに対する要求、又は復号鍵すなわちＫＤＭのソースなどの表現はまた、鍵配信を提供する一般的なメッセージ、または鍵配信メッセージのソースを求める要求を含むことも意味し、これらのメッセージが特定の業界規格に一致するか否かにかかわらない。
【００１９】
ＫＤＭが作成されて、１つのデジタルシネマサーバまたは任意の他の信頼できる装置、および１つのＣＰＬに厳密に関連付けられる。デジタルシネマサーバは、デジタルシネマサーバのみに関連付けられた暗号証明書の暗号的に安全なサムプリント（一般的には、ドメイン名修飾子「ＤＮ修飾子」と呼ばれる）により識別されるが、潜在的には、装置のデジタル証明書に一意的に関連付けられる別の識別情報により識別され、ＣＰＬは、そのＧＵＩＤにより識別される。ＫＤＭは、ＣＰＬが参照するトラックファイル内のアセットを復号するために必要な鍵の全てを含むが、各鍵はそれ自体が暗号化されており、単一の指定された装置（例えば、特定の対象のデジタルシネマサーバ）のみがそれらにアクセスできる。さらに、ＫＤＭには、デジタルシネマサーバに対して、指定された装置が参照される構成物を暗号化および公開することを許可されるときの区間すなわち日付範囲を示す開始および終了日付が含まれる。デジタルシネマサーバは、これらの制限それぞれに対して委ねられ、そのようなサーバの製造者は、これが、製造者のデジタル証明書に依存する製造者の安全なデジタル署名の形式の場合である、ということを保証する。最後に、ＫＤＭは、鍵制作エンティティ（通常、鍵配給者または別個の承認された鍵制作者）による安全な、デジタル署名を有し、誰もＫＤＭを改ざんしていないことを確実にする。
【００２０】
パッキングリストすなわちＰＫＬファイルは、パッケージ内のトラックファイルおよびＣＰＬのそれぞれを、それらの正確なサイズを含めてリストアップする。ＰＫＬファイルも、それ自身のグローバル一意識別番号（ＧＵＩＤ）によって識別され、かつ、通常、スタジオまたは作品の配給者により提供される安全なデジタル署名を有する。
【００２１】
最終的に、それぞれトラックファイル、ＣＰＬ、およびＰＫＬを対応するＧＵＩＤによりリストアップし、かつ、デジタルシネマパッケージの各要素がファイルとしてどこに配置されるかを記述する、アセットマップファイルが提供される。
【００２２】
図１は、本発明の一実施形態に従う、デジタルシネマコンテンツの復号鍵の配給を説明するシステム１００を示す。本例において、鍵の提供者またはソース情報が、従来のＤＣＰから修正された、拡張または向上したＤＣＰ１３０などのデジタルシネマパッケージにおいて提供される。システム１００は、コンテンツ配給システム１１０、鍵提供者システム１４０、および劇場または映画館主システム１６０を含む。
【００２３】
コンテンツ配給システム１１０は、コンテンツ配給サーバ１１２を含み、これは鍵の提供者またはソースの情報を組み込むことにより従来のデジタルシネマパッケージ（ＤＣＰ１１８）を修正して、拡張または向上したＤＣＰ１３０を生成する。鍵提供者情報に基づき、復号鍵を取得することができる。
【００２４】
鍵提供者システム１４０は、鍵提供サーバ１４２を含み、これは、アセット暗号化鍵および承認ブッキング情報に基づき、鍵配信メッセージ生成する。
【００２５】
劇場または映画館主システム１６０は、受信された拡張したＤＣＰにおける鍵提供者情報に基づき１つまたは複数の鍵提供者に復号鍵を要求する。
【００２６】
これらの構成要素のシステムについては以下でさらに検討する。
【００２７】
コンテンツ配給システム１１０は、完結したＤＣＰ１１８、または、完結したＤＣＰを作成するために必要とされる全ての情報およびアセットを表すデジタルシネマ配給マスタ（Ｄｉｇｉｔａｌ  Ｃｉｎｅｍａ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｍａｓｔｅｒ：ＤＣＤＭ、以下ＤＣＤＭ）を受信する。ＤＣＤＭをＤＣＰに変換することは周知の処理であり、例えば、カリフォルニア州バーバンクのＣｉｎｅＣｅｒｔ社によるＷａｉｌｕａ  Ｄ−Ｃｉｎｅｍａ  Ｍａｓｔｅｒｉｎｇ  Ｓｙｓｔｅｍとして市場に出ている一連のソフトウェアツールを使用して実行されるように、現行では人手の介入を必要とする。
【００２８】
従来の実務では、ＤＣＰ１１８は典型的には、配給ブッキング情報１１４に基づき映画公開劇場１６０に配給され、配給ブッキング情報１１４には、作品上演がブッキングまたは承認された映画公開劇場がリストアップされる。
【００２９】
本発明によると、代わりに、異なるＤＣＰ１３０が劇場１６０に配給される。ＤＣＰ１３０は、以下でさらに検討するように、従来のＤＣＰを、少なくとも復号鍵の提供者に関する情報を含んで修正することにより作成される。コンテンツ配給システム１１０はＤＣＰの配給を管理し、これは、ＤＣＰを衛星（図示せず）を介して送信すること、または、ＤＣＰをハードディスクドライブ（図示せず）に記録して種々の映画館主または劇場１６０に出荷すること、を含む異なる手段により行うことができる。
【００３０】
配給システム１１０は、アセットトラックファイルの何らかの暗号化を委ねられているのであれば、それらのアセットを復号するために必要な鍵を所有するであろう。各作品（それぞれＣＰＬ１３６により記述される）について、配給システム１１０は、アセット暗号化鍵１２０（アセットトラックファイルの復号にも使用される）を、鍵提供者情報１１６内にリストアップされる各承認された鍵提供システム１４０に、提供しなければならない。コンテンツ配給サーバ１１２に対して提供されるようなＤＣＰ１１８におけるアセットトラックファイルが、既に暗号化されている場合、アセット暗号化鍵１２０は、スタジオまたは別の関係者により鍵提供システム１４０に提供されてもよい。この構成によりセキュリティを高めることが可能となり、何故なら、コンテンツの配給を課されたエンティティが、そのコンテンツの鍵を配給することもできないからである。
【００３１】
鍵提供システムは概して、Ｗａｌｋｅｒらによる「Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｋｅｙ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  ｆｏｒ  Ｓｅｃｕｒｅ  Ｄｉｇｉｔａｌ  Ｃｉｎｅｍａ  ｐｒｅｓｅｎｔａｔｉｏｎｓ（安全なデジタルシネマ上演の鍵配給のための方法および装置）」と題する同一出願人の米国特許出願第２００９／０１９６４２６号、および、Ａｒｎａｕｄ  Ｒｏｂｅｒｔによる「ＫｅｙＭａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ  ｆｏｒ  Ｄｉｇｉｔａｌ  Ｃｉｎｅｍａ（デジタルシネマのための鍵管理システム）」と題する米国特許出願第２００８／０１３７８６９号、に教示されるように既知であり、その全体が参照により本明細書に組み込まれる。
【００３２】
本発明によると、鍵提供システム１４０は、向上したＤＣＰ１３０に追加される鍵ソースの情報またはデータにより参照され、またはそれにおいて識別され、かつ、映画館主または他の承認されたエンティティにより送られた、鍵を求める要求に応答する。いくつかの実施形態において、要求は、向上したＤＣＰにおける鍵ソース情報に従って策定され、一方、他の実施形態において、要求は、他で確立された従来の技法で策定すること可能である。
【００３３】
アセット暗号化鍵１２０は、鍵提供者情報１１６に従って鍵提供システム１４０に送られる。アセット暗号化鍵１２０が鍵提供システム１４０に提供されるのが早いほど、システム１４０は、デジタルシネマサーバ１６２に対するＫＤＭ１４８の生成の開始を早くすることができる。ＫＤＭ１４８は、鍵提供者または鍵提供サーバにより、承認ブッキング情報１４４および他のポリシー（図示せず）に従って、予め生成されてあってもよく、例えば、特定のコンテンツの所有者が、特定の期間を超えない有効期限を有するべく全ての鍵を制約する、というポリシーがある。映画館主の任意の要求に先だって生成されるＫＤＭは、後の要求時の検索のため、または、大量の配給のために、鍵ストア１４６に格納することができる。多くの実装において、これにより、結果として、ＫＤＭを必要に応じて生成してオンザフライで要求して返すよりも、ピークの計算需要を低くすることができる。
【００３４】
本発明において、コンテンツ配給システム１１０は、１つまたは複数の鍵提供者システム１４０に関する鍵提供者情報１１６を含むことにより、ＤＣＰ１１８を作成または修正し、従って、１つまたは複数の映画公開劇場１６０に配給するための拡張または修正されたＤＣＰ１３０を生成する。コンテンツ配給システム１１０は、少なくともコンテンツ配給サーバ１１２を含み、これは１つまたは複数の配給チャンネルまたは映画館主の施設の機構（図示せず）に動作可能に連結されるもので、例えば、衛星、ブロードバンド、ディスクレプリケータおよび宅配配信、ならびに、一連のソフトウェアツール、例えばＣｉｎｅＣｅｒｔ社によるＷａｉｌｕａツール、などに連結される。拡張または修正されたＤＣＰ１３０には、スタジオ（コンテンツ所有者）または他の権限者から取得される追加的な鍵提供者情報１１６が含まれる。
【００３５】
鍵提供者情報１１６は、暗号化されたコンテンツを有するＤＣＰ１３０内の個々のＣＰＬ１３６についてＫＤＭ１４８を生成および／または配給することを承認された少なくとも１つの鍵提供者システム１４０を識別する。
【００３６】
鍵提供者情報１１６はまた、各鍵提供者にコンタクトを取る１つまたは複数の方法を識別するアクセス情報を含む。鍵提供者システム１４０にコンタクトを取るための一例の方法は、通信チャンネルを介して鍵提供サーバ１４２にコンタクトを取ることであり、通信チャンネルには、例えば、ＴＭＳ１６６について示されるように、関連的にインターネットを含んでもよい広域ネットワーク（ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ：ＷＡＮ、以下ＷＡＮ）１５０、が含まれる。この通信チャンネルはまた、デジタルシネマサーバ１６２については、中間ＬＡＮ１６８を含んでもよい。そのような情報はＵＲＬとして表現されてよく、例えば、ハイパーテキスト転送プロトコル（すなわち、ｈｔｔｐ：／／）またはその他の使用を示す。デジタルシネマサーバ１６２でのプレイアウトのために、鍵提供サーバにコンタクトしてＣＰＬ１３６により記述される特定の作品の鍵を要求する際、デジタル証明書１６４または対応する判別名修飾子（ＤＮ（ｄｉｓｔｉｎｇｕｉｓｈｅｄ  ｎａｍｅ）修飾子）が、ＣＰＬ１３６の一意的な識別子、および、選択的に他の情報（例えば、開始日および期間）と共に提供される。ＣＰＬ１３６の一意的な識別子およびデジタルシネマサーバ１６２のＤＮ修飾子などの要求に対するパラメータは、周知のＲｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ（ＲＥＳＴｆｕｌ）アーキテクチャを使用するインターフェースにおいて一般的に行われるように、ＨＴＴＰ  Ｇｅｔ操作では習慣的に示される位置におけるＵＲＬに代用することができる。他の実施形態において、パラメータは、周知のＳｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）を使用するインターフェースにおいて一般的に見られるように、ＨＴＴＰ  Ｐｏｓｔ操作のように、文書内にサブミットすることができる。鍵提供者システム１４０にコンタクトして鍵を要求するための、本例および他の例の方法については、以下で図２と併せてさらに検討する。
【００３７】
劇場１６０において、鍵提供者システムに関する情報が、個々のデジタルシネマサーバ１６２（スクリーン管理サーバ、すなわちＳＭＳとしても既知である）、または、デジタルシネマサーバ（複数可）１６２の代わりに動作する劇場管理システム（ｔｈｅａｔｅｒ  ｍａｎａｇｅｍｅｎｔ  ｓｙｓｔｅｍ：ＴＭＳ、以下ＴＭＳ）１６６などの複数のシネマサーバを管理する管理システムにより、拡張したＤＣＰ１３０から取得される。１つまたは複数の要求を、ＫＤＭのソースに関する情報およびそれらを取得する様式に基づき、デジタルシネマサーバ１６２または劇場管理システム１６６によって送ることができる。例えば、要求を行って、特定のデジタルシネマサーバ１６２の１つのＣＰＬに関連付けられたＫＤＭを取得することができる。あるいは、ＫＤＭを求める多くの別個の要求を送る代わりに、単一の要求を、デジタルシネマサーバ１６２または劇場管理システム１６６により（１つまたは複数のデジタルシネマサーバ１６２の代わりに）行って、ＤＣＰ内の数個（または全て）のぞれぞれのＣＰＬのＫＤＭを取得することができる。ＤＣＰは、アセットマップのＵＵＩＤ、ＰＫＬのＵＵＩＤまたは他の当該情報により識別可能である。例えば、ＫＤＭ１４８に関する鍵提供者システム１４０と通信するために必要な情報は、拡張したＤＣＰ内のアセットマップ１３２内に提供可能である。ＫＤＭ１４８は、特定のデジタルシネマサーバ１６２およびＣＰＬ１３６に関連付けられており、承認ブッキング情報１４４により承認されたデジタルシネマサーバ１６２によりＣＰＬ１３６内に記述される作品を復号して上映するために必要である。
【００３８】
鍵提供者情報１１６は、ＤＣＰ１３０内の暗号化されたコンテンツに関するファイル、例えば、アセットマップ１３２、パッキングリスト（ＰＫＬ）１３４、コンポジションプレイリスト（ＣＰＬ）１３６、および／またはアセットトラックファイル１３８のいずれか、または、１つまたは複数の追加的なファイルに組み込むことができる。これらの追加的なファイルには、特定のファイル１３９を含むことができ、少なくとも１つの鍵提供者１４０をリストアップしており、例えば、この機能に専用であって通常は提示されないテキストファイル「ＫｅｙＰｒｏｖｉｄｅｒ．ｘｍｌ」、または、後で定義される他の標準のファイルもしくは現在定義されるもの（サブタイトルトラックファイルなどであり、これはアセットトラックファイル１３８の１つのタイプである）、があるが、ここでは特に言及はしない。
【００３９】
アセットトラックファイル、ＣＰＬおよびＰＫＬがデジタルで署名されて、改ざんに対して安全を保っているため、これらのファイルの内１つまたは複数が補正または修正されて、適切な鍵提供システム１４０が識別される場合、補正されたファイルは、ＤＣＰ１１８の元の作成者の代わりにコンテンツ配給システム１１０の権限者により再署名されなければならない。従って、ファイルを修正してコンテンツ配給システム１１０の権限者により再署名するという必要性を回避するためには、修正されたＤＣＰを異なる方法で提供することが望ましく、または、ポリシーもしくは標準の問題である。
【００４０】
さらに、アセットトラックファイル１３８がＤＣＰ１１８内の元のファイルから再パッケージ化される場合、その大きさおよびＧＵＩＤが変更され、それに従って全てのＣＰＬ１３６、ＰＫＬ１３４、およびアセットマップ１３２の更新が必要となる。同様に、ＣＰＬ１３６および／またはＰＫＬ１３４がＤＣＰ１１８内のそれぞれの元のファイルから再パッケージ化される場合、そのそれぞれの大きさおよびＧＵＩＤが変更される。再パッケージ化されたＰＫＬ１３４について、アセットマップ１３２を同様に修正する必要があり、一方、再パッケージ化されたＣＰＬについては、アセットマップ１３２およびＰＫＬ１３４の両方を修正する必要がある。
【００４１】
別の実施形態において、アセットマップ１３２は、ＰＫＬ１３４、関連するＣＰＬ１３６、および関連する暗号化されたアセットトラックファイル１３８のそれぞれを参照するものであり、補正または修正されて適切な鍵提供システム１４０が識別されるようにしてもよい。アセットトラックファイル、ＣＰＬ、またはＰＫＬとは異なり、アセットマップ１３２はデジタルで署名されない。その代わりに、特定のＧＵＩＤリファレンスに対応するファイルをシステムが配置するのを支援する情報ユーティリティである。すなわち、ＣＰＬファイル１３６はＧＵＩＤによりアセットトラックファイル１３８を参照し、アセットマップ１３２は、特定のＧＵＩＤが特定の名前付けされたファイル（ＤＣＰ１３０の実装に基づくファイルシステムにおいて）に対応することを識別するインデックスを提供する。従って、本実装の一利点は、コンテンツ配給システム１１０が、ファイルの内のいずれかに再署名することを要求されず、かつ、全てのセキュリティおよび証明書権限者が、ＤＣＰ１１８をパッケージ化する元のエンティティにとどまる、ということである。
【００４２】
別の実施形態において、新しいタイプのファイル、例えば、鍵ソースファイル１３９が、拡張または向上したＤＣＰ１３０に追加される。鍵ソースファイルは、適切な鍵提供システム１４０およびそれらが適用されるＣＰＬについての情報を含む。
【００４３】
さらに別の実施形態において、映画公開劇場１６０の劇場管理システム（ＴＭＳ）１６６およびデジタルシネマサーバ１６２のいずれかが、向上したＤＣＰからの鍵ソース情報に基づき遭遇した適切な鍵提供システム１４０の少なくとも識別情報を、長期メモリ（例えば、それぞれメモリ１６５および１６７）に記録および格納してよいが、複製は無視されてよい。例えば、鍵提供者のリストを、どのＤＣＰ配給にも含めることができ、コンテンツが暗号化されているか否かに係わらない。リストは、所定の有効期間、例えば、１ヵ月など、を伴ってメモリに格納される。従って、新しいＤＣＰが受信されると、リストが現在進行的または継続的に更新される。鍵提供システムの識別をこのように格納することにより、劇場１６０の劇場管理システム（ＴＭＳ）およびデジタルシネマサーバには、複数の鍵提供システムが素早く分かる。ＴＭＳおよびサーバは、従来技術のＤＣＰ１１８が劇場１６０にて受信された時でも、以前から分かっているシステム（すなわち、１つまたは複数の以前から既知の鍵提供者システム）から、たとえ受信したＤＣＰ１１８において該システムが識別されていない場合でも、鍵を取得する試みが可能であるように構成することができる。
【００４４】
例えば、鍵ソースを求める検索を、コンテンツを発行または制作したスタジオにより以前から使用されていた鍵提供サーバで開始することが可能である。検索は、少なくとも１つの確立された規則に基づき、例えば、中でも、最も近々に使用されたサーバ、または、最も共通して使用されたサーバに、最初にコンタクトすることにより、行うことができる。このアプローチは可及的に効率が良いわけではないが、人手の介入を必要とするよりはるかに好ましい。しかし、劇場が格納された情報から適切な鍵提供者を取得できない場合は、人手の介入が要求されてもよい。
【００４５】
図２は、本発明の一実施形態を説明するブロック図であり、鍵提供者システム１４０の詳細を示し、鍵配給者２２０、鍵生成装置２１０、および、他のハードウェアおよびソフトウェア構成要素（例えば、中でも、ウェブサーバ２３０、ファイル転送プロトコル（ｆｉｌｅ  ｔｒａｎｓｆｅｒ  ｐｒｏｔｏｃｏｌ：ＦＴＰ、以下ＦＴＰ）サーバ２４０）を有する鍵提供サーバ１４２が含まれる。鍵提供サーバ１４２は、異なる様式で構成することが可能であり、プロセッサ−メモリ−入力−出力のアーキテクチャが含まれて良く、これは、単一のサーバとして、または、通信回線により相互接続されるか、もしくはネットワーク上のサーバのクラスタとして、実装可能である。鍵提供サーバ１４２の各モジュールまたは構成要素は、特定のモジュールと関連付けられてよい、または、他のモジュールと共有されてよい、１つまたは複数のプロセッサ（図示せず）が実行するための、メモリに格納される１つまたは複数のプログラムを有する。
【００４６】
鍵生成装置２１０および鍵配給者２２０は、１つまたは複数のサーバのように構成することができる。鍵生成装置２１０の一例は、（上述の）ＣｉｎｅＣｅｒｔ社によるＷａｉｍｅａ  Ｄ−Ｃｉｎｅｍａ  Ｋｅｙ  Ｍａｎａｇｅｍｅｎｔ  Ｓｅｒｖｅｒである。一実施形態において、鍵生成装置および配給者はそれぞれ、独立して、またはお互いに相互作用して動作可能である少なくとも１つのサーバを含む。複数のサーバを、向上したスループットおよび冗長性のために使用可能である。ウェブサービス２３１、ウェブサイト２３２、および、それぞれ電子メール、ウェブ、およびＦＴＰ用のサーバ２２２、２３０、２４０、は、鍵配給者２２０上で稼働する個々のソフトウェアモジュールを有することができ、または、複数の物理サーバを介して分散され、例えば、負荷を分配しフォールトトレランスを提供することができる。
【００４７】
鍵生成装置２１０は、セキュリティ上の理由で、対応するデジタルシネマサーバ１６２のデジタル証明書１６４（例えば、公開鍵）を要求しなければならず、デジタル証明書は信頼できるソースから取得され、および／または、信頼できるソースにより署名されて、証明書ストア２１２にあらかじめロードしておく。鍵生成装置２１０は、承認ブッキング情報１４４（例えば、スタジオより提供される）をメモリから読み込み、デジタルシネマサーバ１６２上で稼働するべくブッキングされるＣＰＬ１３６に対応するアセット暗号化鍵１２０を使用して、ＫＤＭ１４８を生成する。ＫＤＭは、承認ブッキング情報１４４からの開始終了日付情報を含む。特定のデジタルシネマサーバ１６２のＫＤＭ１４８を生成するために、鍵生成装置は、デジタルシネマサーバ１６２のデジタル証明書１６４において提示される公開鍵を使用するが、これは、典型的にはアセット暗号化鍵１２０を暗号化するための証明書１６４の安全なサムプリント（ＤＮ修飾子）に関連付けられている。ＫＤＭ１４８は生成されると、後の呼び出しおよび配給に備えて鍵ストア１４６内に格納されてもよいし、または、直ぐに使用（配給）されてもよい。
【００４８】
鍵配給者２２０は、ＫＤＭを求める外部への要求のための種々のインターフェースを提示することができる。例えば、モデム２２１は、電話回線１５０’との接続を介して映画館主システムまたは劇場１６０と相互作用することができる。
【００４９】
電子メールサーバ２２２を使用して、人間の管理者および映写技師の電子メールアカウント、または、映画館主システム１６０上で稼働する自動メールボックス（図示せず）に１つまたは複数のＫＤＭを送信することができる。ＫＤＭ自体は、添付ファイルとして単独で、または、．ｚｉｐもしくは．ｔａｒのアーカイブとして、含まれてよい。
【００５０】
ウェブサーバ２３０は、そのアドレスが鍵提供者情報１１６内に提供され、かつＤＣＰ１３０に含まれるもので、劇場がＫＤＭを要求するためにアクセスすることができる。ウェブサービス２３１およびウェブサイト２３２のどちらかまたは両方を提示することによりＨＴＴＰ要求に応答することができる。ウェブサイト２３２は、有用なヒューマンインターフェースを提示すること、および／または、鍵を求める要求を行うためのパラメータ化されたＵＲＬを受け取ること、ができる。例えば、
ｈｔｔｐ：／／  ｗｗｗ．ｔｅｃｈｎｉｃｏｌｏｒ．ｃｏｍ／  
ｋｅｙＲｅｑｕｅｓｔ？ＣＰＬ＿ＩＤ＝＄ＣＰＬ＿ＧＵＤＤ＆ＳＭＳ＿ＩＤ＝＄ＤＮＱ  
の形式のＨＴＴＰクエリは、変数＄ＣＰＬ＿ＧＵＩＤおよび＄ＤＮＱを、関心対象のＣＰＬ１３６の一意的な識別子、およびその鍵が探索されるデジタルシネマサーバ１６２に対応するドメイン名修飾子（すなわち、デジタル証明書１６４のサムプリント）で置き換えて、使用することが可能である。
【００５１】
ウェブサービス２３１を使用して、他の自動化されたシステム（例えば、デジタルシネマサーバ１６２または劇場管理システム１６６）にサービスを提供することができる。代替実施形態において、自動化されたシステムへの同様のサービスの提供は、専用のアプリケーションおよびソケットまたはセキュアソケットレイヤインターフェースを介したプロトコルを使用して、行ってもよい。
【００５２】
いくつかの実施形態において、例えば、特定のデジタルシネマサーバ１６２または劇場管理システム１６６の管理下にある全てのデジタルシネマの全てのＫＤＭ１４８が、適切なサブディレクトリに階層的に配置されるように、鍵ストア１４６が組織化されている場合、ファイル転送プロトコル（ＦＴＰ）サーバ２４０へのログインにより、全ての適切な現在または次回のＫＤＭを含むディレクトリが、最上位のディレクトリとして、またはそのサブディレクトリ内に返される。
【００５３】
鍵提供サーバ１４２は、１つまたは複数のインターフェース２２１、２２２、２３０、および２４０をサポートしてよく、また、鍵配給者２２０は、鍵ストア１４６へのアクセスを要求してその機能を実行する。鍵提供サーバ１４２が鍵生成装置２１０を含むか否かは設計上の選択である。
【００５４】
概して、鍵生成装置２１０は、非同期的に、かつ、鍵配給者２２０が鍵の要求を受け取る前に動作する。例えば、新しい承認ブッキング情報が受け取られると、鍵生成装置２１０は、続けて、証明書ストア２１２に先にロードしておいた証明書１６４およびアセット暗号化鍵１２０を使用して鍵を生成することができ、生成したＫＤＭは鍵ストア１４６に格納される。作品公開開始日（ブッキング情報内に提供されＫＤＭにコピーされる）のどのくらい前に、ＫＤＭを、映画館主システムまたは劇場１６０に利用可能にするのか（既に生成されて鍵ストア１４６に置かれているかどうかに係わらず）は、鍵提供システム１４０のオペレータ、承認ブッキング情報１４４、またはコンテンツ所有者のポリシーにより決定されてよいポリシー上の問題である。
【００５５】
代替実施形態において、ＫＤＭ１４８は、丁度いいタイミングで、すわなち、鍵配給者との相互作用に基づき動的に、鍵配給者２２０が受け取る要求に応答して、生成されてもよい。しかしこの場合、鍵生成装置２１０は、予測されるピークの要求の変化量に遅れずについて行くことができなければならない。
【００５６】
図３は、ＸＭＬファイルの形式の従来技術のアセットマップ３００の例を示す。アセットマップ３００の＜ＡｓｓｅｔＬｉｓｔ＞要素（ｅｌｅｍｅｎｔ）は、１つまたは複数の＜Ａｓｓｅｔ＞要素を列挙し、ＤＣＰ１１８全てのアセットが表わされる。例示のアセット要素３１０は、ＤＣＰ１１８内の１つのＣＰＬに関する。アセット要素３１０には、アセットの１つをそのＧＵＩＤで識別する＜Ｉｄ＞要素３１２、および、特定のアセットについて記述する人間が読めるテキストを含む＜ＡｎｎｏｔａｔｉｏｎＴｅｘｔ＞要素３１４、が含まれる。また、アセット要素３１０には、アセットがどこで見つかるかの指示が含まれ、これらの例においては、適切なファイルへのパスとなっている（この後者の部分は、本発明では変更しない）。
【００５７】
図４は、従来技術のアセットマップのスキームに適合する、本発明のアセットマップ４００の例を示す。本実施形態において、３１０に対応する＜Ａｓｓｅｔ＞要素４１０には、＜Ａｓｓｅｔ＞３１０の＜Ｉｄ＞３１２と同様の＜Ｉｄ＞要素４１２が含まれる。しかし、＜ＡｎｎｏｔａｔｉｏｎＴｅｘｔ＞要素３１４に対応する＜ＡｎｎｏｔａｔｉｏｎＴｅｘｔ＞要素４１４が、元の人間が読めるアセットの記述だけでなく、鍵ソース識別子４２１（すなわち、「ＫｅｙＳｏｕｒｃｅ＝」の句）をも含んで、＜ＡｎｎｏｔａｔｉｏｎＴｅｘｔ＞４１４が、鍵をどこでどのように取得するのかついての鍵ソース表示４２２（本例においては、置き換え可能なパラメータ＄ＣＰＬおよび＄ＤＮＱを用いたＵＲＬ）を含む、ことを示す場合は、アセット４１０は拡張されている。要素４１４は、閉じタグ４２４により境界が定められる。
【００５８】
図５は、従来技術のアセットマップのスキームに適合する、本発明のアセットマップ５００の別の例を示す。本実施形態において、＜Ａｓｓｅｔ＞要素５１０には、＜Ｉｄ＞５１２および＜ＡｎｎｏｔａｔｉｏｎＴｅｘｔ＞５１４が含まれ、それぞれ３１０、３１２、および３１４に相当対応する。しかし、鍵ソース識別子５２１（４２１と同様）および鍵ソース表示５２２（４２２と同様）を含むコメント５２０が追加されている場合、アセット５１０は拡張されている。コメント要素は、閉じタグ５２４で境界が定められる。当業者は理解するであろうが、コメント要素は、アセットマップ５００内の多くの場所のいずれかに配置することができる。
【００５９】
図６は、本発明のアセットマップ６００の別の例を示す。しかし、アセットマップ４００および５００とは異なり、アセットマップ６００は、従来技術アセットマップのスキームには適合せず、何故なら、従来技術アセットマップのスキームでは許容されない新しい要素が追加されているからである。本実施形態において、＜Ａｓｓｅｔ＞要素６１０には、＜Ｉｄ＞６１２および＜ＡｎｎｏｔａｔｉｏｎＴｅｘｔ＞６１４が含まれ、それぞれ３１０、３１２、および３１４に相当する。しかし、＜ＫｅｙＳｏｕｒｃｅＬｉｓｔ＞要素６２０（閉じタグ６２４を伴う）が導入される場合、アセット６１０は拡張されており、要素６２０には１つまたは複数の＜ＫｅｙＳｏｕｒｃｅ＞要素６２１（閉じタグ６２３を有する）が含まれている。各＜ＫｅｙＳｏｕｒｃｅ＞要素６２１（アセットマップ６００には１つのみ示す）が、鍵ソース表示６２２（鍵ソース表示４２２および５２２と同様）を提供する。当業者には、６２１などの＜ＫｅｙＳｏｕｒｃｅ＞要素の配置に適切な、アセットマップ６００内の他の実施可能な場所を検討できるであろう。
【００６０】
アセットマップ４００および５００と比較すると、アセットマップ６００は、鍵ソース表示を導入するにはより明確で適切な方法である。しかし、アセットマップ６００は、既存の規格に対する更新を必要とし、現在の標準を順守するシステムと相互に動作することが可能ではない。このため、アセットマップ６００などが広くサポートされる時まで、本発明を実践するためにアセットマップ４００または５００に示されるような拡張性を使用してもよい。
【００６１】
上述のように、同様の変更を、任意の従来のＤＣＰ（例えば、ＤＣＰ１１８）の他の構成要素に加えて、拡張したＤＣＰ１３０を生成してもよい。例えば、鍵ソース表示情報（４２２、５２２、６２２の形式で）を、上述のような１つまたは複数の他のファイルにおける対応する変更と共に、ＰＫＬ１３４、ＣＰＬ１３６、または、アセットマップ１３２の代わりにアセットトラックファイル１３８にも、追加することができ、一貫性のある有効なＤＣＰ１３０が生成される。
【００６２】
代替実施形態において、図４から６に示すようなウェブサーバ２３０のＨＴＴＰのＵＲＬを含む鍵ソース表示４２２、５２２、６２２の代わりに、鍵ソース表示は、ＦＴＰサイト２４０へのＵＲＬ
ｆｔｐ：／／  ｗｗｗ．ｔｅｃｈｎｉｃｏｌｏｒ．ｃｏｍ／  ｋｅｙＲｅｑｕｅｓｔ／  ＄ＤＮＱ  
を含むことでき、ここでは、変数＄ＤＮＱは、劇場管理システム１６６またはデジタルシネマサーバ１６２によって、アクセスの前に、証明書１６４のサムプリント（または、映画館主システムの他の共有識別子）で置き換えることができる。または、
ｆｔｐ：／／  ＄ＤＮＱ＠ｗｗｗ．  ｔｅｃｈｎｉｃｏｌｏｒ．ｃｏｍ／  ｋｅｙＲｅｑｕｅｓｔ／  
を含むことができ、ここでは、劇場管理システム１６６またはデジタルシネマサーバ１６２により提供されるログイン認証情報により、映画公開システムに対応する鍵ストア１４６内のユーザディレクトリにおいて、ＦＴＰサーバ２４０上のＦＴＰセッションが開始される。
【００６３】
さらに別の実施形態において、鍵ソース表示が、ＵＲＬとしてであるが、電子メールサーバ
ｍａｉｌｔｏ：／／  ｋｅｙＲｅｑｕｅｓｔ＠ｔｅｃｈｎｉｃｏＩｏｒ．ｃｏｍ？  ｓｕｂｊｅｃｔ＝＄ＣＰＬ＆ｂｏｄｙ＝＄ＤＮＱ  
を識別することができ、ここで、映画館主システム１６０内の解釈要素が、電子メールサーバ２２２宛に、適切な返信電子メールアドレスを示す有効な電子メールメッセージを構成することができる。代替実施形態において、返信電子メールアドレスは、鍵配給者２２０により、特定のデジタルシネマサーバ１６２または劇場管理システム１６６を１つまたは複数の電子メールアドレスに関連付けているデータベース（図示せず）内で検索可能であり、これにより、電子メールを以前に承認された受信者のみに送信可能であるために、不正行為の機会が最小限にされる。
【００６４】
さらに別の代替実施形態において、オペレータが同様の鍵ソース表示を使用して、適切な件名と本文の値を使用して電子メールメッセージを手動で構成することにより、鍵を要求することができる。
【００６５】
モデム２２１を介した接続が適切である場合、１つまたは複数の電話番号をリストアップすることが可能であり、例えば、スイス、ジュネーブのＩｎｔｅｒｎｅｔ  Ｓｏｃｉｅｔｙが２００４年１２月に公開した「電話番号のためのｔｅｌ  ＵＲＩ（Ｔｈｅ  ｔｅｌ  ＵＲＩ  ｆｏｒ  ＴｅｌｅｐｈｏｎｅＮｕｍｂｅｒｓ）ＲＦＣ３９６６」に記載される。
【００６６】
ｔｅｌ：  １−８００−９９３−４５６７；  ｐｈｏｎｅ−ｃｏｎｔｅｘｔ＝＋ｌ
この後に、所定の接続プロトコル（例えば、ＰＰＰ、ＳＬＩＰ、など）を与えることができる。
【００６７】
図７には、本発明に従う、復号鍵を取得するための処理７００を示す。ステップ７１０にて、劇場管理システム１６６またはデジタルシネマサーバ１６２などの映画館主システムが、ＤＣＰ１３０を取り込む準備をする。
【００６８】
ステップ７１２にて、ＤＣＰ１３０が映画館主システム１６０により受け取られる。例えば、ＤＣＰ１３０を、衛星通信リンクを介して衛星受信機に送信して、映画館主の施設にあるメモリに記録することが可能である。あるいは、ＤＣＰ１３０を含有するハードディスクドライブを、映画館主の施設に出荷することが可能である。
【００６９】
ステップ７１４にて、ＤＣＰ１３０は、暗号化された関心対象のＣＰＬ１３６、すなわち、復号鍵が要求されたＣＰＬ検査される。暗号化された関心対象のＣＰＬ１３６毎に、その一意的な識別子が記され、これはアセットマップファイル１３２、パッキングリスト１３４、またはＣＰＬ１３６から取得することができる。ステップ７１６にて、ＤＣＰ１３０は、種々の代替実施形態として上記で提案したように、アセットマップ１３２またはＤＣＰ１３０内の他のファイル（例えば、パッキングリスト１３４、鍵ソースファイル１３９）において、図４から６と併せて説明したような１つまたは複数の鍵ソース識別情報を有するか検査される。関心対象のＣＰＬに関する鍵ソース識別情報が記され、どのＣＰＬが個々の鍵ソースによりサポートされるのかについての任意の制約（全く図示されていない）が含まれる。代替実施形態において、関心対象の全てのＣＰＬの一意的な識別子を記す代わりに、ＤＣＰ１３０に関連付けられた、例えば、パッキングリスト（ＰＫＬ）１３４またはアセットマップ１３２の単一の識別子を、単一の要求における全ての暗号化されたＣＰＬのＫＤＭを検索する際に使用するために記すことができる。
【００７０】
ステップ７１８にて、復号鍵またはＫＤＭを求める要求が、ステップ７１６にて識別された鍵ソースの１つに対して行われる。要求には、少なくとも１つの暗号化されたＣＰＬ１３６からの一意的な識別子、および、デジタルシネマサーバ１６２のデジタル証明書１６４のサムプリント（例えば、判別名修飾子）、または、ＣＰＬ復号鍵もしくはＫＤＭが探索される特定のデジタルシネマサーバ１６２を示す何らかの他の一意的な識別情報、が含まれる。あるいは、ＤＣＰ１３０に関連付けられる一意的な識別子は、ＤＣＰの全てのＣＰＬの復号鍵またはＫＤＭを要求する際に使用可能である。
【００７１】
ステップ７２０にて、鍵要求の状態に関して判定がなされる。鍵を求める要求が拒否されなかったと判定されると、ステップ７２８にて、ＣＰＬ１３６の再生がスケジューリング（または手動でトリガー）される時、劇場で受け取られるＫＤＭがデジタルシネマサーバ１６２による使用のためにローカルに格納される。鍵取得の処理７００はステップ７３０で終了する。
【００７２】
ステップ７２０にて劇場１６０により判定され、任意のＫＤＭを求める要求が拒否される場合、処理は続いてステップ７２２にて、所望の鍵の獲得を試みるためのさらなるソース（鍵提供者システム１４０）があるかどうかを判定する。ある場合、ステップ７２４にて、次の適切な鍵ソース１４０が選択され、処理はステップ７１８に戻って繰り返される。
【００７３】
しかし、ステップ７２２にて、鍵のためのさらなるソースが無いとシステムが判定する場合、ステップ７２６にて、システムは、鍵が取得できないことを警告する。
【００７４】
鍵の要求は、様々な理由で不成功となり得る。例えば、鍵提供者システム１４０は、以下の１つまたは複数の問題により、要求を拒否することができる。  
ａ）ＣＰＬが認識されない（システム１４０が対応するアセット暗号化鍵１２０を持たない）。  
ｂ）ＳＭＳが認識されない（システム１４０が対応する証明書１４８を持たない）。
ｃ）ＫＤＭがまだ利用できない（応答は、いつ鍵が取得可能かを示すことができる）。
ｄ）ＫＤＭがもう利用できない（すなわち、作品のリリースを取り下げられた）。
ｅ）対応するブッキングが見つからない（すなわち、契約の記録が示されていない）。
ｆ）鍵配給システムが利用できない（システム１４０の一部がオフライン）。
【００７５】
あるいは、不成功の鍵要求が発生するのは、映画館主システム１６０が応答を待っている間にタイムアウトしてしまうからであることがあり、これは、鍵提供者システム１４０が、過負荷、オフライン、廃業している場合、または、鍵ソース情報が正しくない場合、に起こり得る。
【００７６】
いずれかの鍵配給システム１４０が、鍵が取得できない理由をもって応答した場合、それらがまとめられて映画館主システム１６０のオペレータに提示されてもよい。推奨される動作の経路（例えば、上記の理由のリストに対応する）も、以下に提供することができる。
ａ）スタジオまたはコンテンツの配給者にコンタクトして鍵を要求し、再試行する。
ｂ）ＳＭＳをスタジオおよび鍵配給者（複数可）に登録して、再試行する。
ｃ）推奨される時間が経ってから、もう一度やってみる。
ｄ）スタジオにコンタクトしてブッキングを整え、再試行する。
ｅ）スタジオにコンタクトしてブッキングを整え、再試行する。
ｆ）後でもう一度やってみる。
そして、鍵取得の処理７００は、その後、ステップ７３０で終了する。
【００７７】
図８は、暗号化されたＣＰＬの鍵ソースをトラッキングするための処理８００を説明する図である。鍵ソーストラッキング処理８００は、映画公開システムまたは劇場が、ＤＣＰ、例えば、ＤＣＰ１３０を受け取る準備ができている状態で、ステップ８１０で開始される。ステップ８１２にて、システムは、ＤＣＰ１３０を取り込み、これにより、システムには、暗号化された作品のコンテンツだけでなく、対応するＣＰＬの鍵ソース表示（例えば、図４から６の表示４２２、５２２、６２２と同様）も提供される。
【００７８】
ステップ８１４にて、暗号化されたＣＰＬ１３６とそれぞれの対応する鍵ソース表示との間の関連性が、スクリーン管理サーバ１６２に関連するメモリ１６５または劇場管理システム１６６に関連するメモリ１６７に格納される。冗長部分および重複した情報は除去することができる（失効または期限切れした情報など）。
【００７９】
ステップ８１６にて、暗号化されたＣＰＬ１３６により表される作品の上映がスケジューリングされ、すなわち、作品が、あるデジタルシネマサーバ１６２上である時間に再生されるよう指示される。スケジューリングのタスクは、劇場管理システム１６６またはデジタルシネマサーバ１６２のどちらかを用いて実行されてよい。必要に応じて、少なくともアセットトラックファイル１３８およびＣＰＬ１３６が、予定の上映時間より前にデジタルシネマサーバ１６２に転送される。
【００８０】
ステップ８１８にて、選択されたデジタルシネマサーバ１６２上での指定された時間における再生がスケジューリングされた作品について、ＫＤＭが既に提示されているかどうか、判定される。ステップ８２０にて、ＫＤＭが実際にすでに利用可能であることを、システムが確認した場合、ステップ８３２にて、そのＫＤＭが使用されて、スケジューリング通りの上映のために作品が復号され、ステップ８３４にて処理は終了する。
【００８１】
しかし、ステップ８２０にて、システムが、スケジューリングされた作品のＫＤＭを検出できない場合、ステップ８２２にて、指定されたＣＰＬに関連する鍵ソースに対して（ステップ８１４にてメモリに格納された関連性に基づき）検査が行われる。スケジューリングされたＣＰＬに鍵ソースが関連付けられていない場合、ステップ８３０にて、鍵またはＫＤＭが無いことについて適切な警告がなされ、処理はステップ８３４で終了する。
【００８２】
しかし、ステップ８２２にて、ＣＰＬに関連する少なくとも１つの鍵ソースがあると判定されると、ステップ８２４にてループが開始され、ステップ７１８について上述したように、鍵またはＫＤＭが関連する鍵ソースから要求される。ステップ８２６にて、鍵を求める要求が成功した場合、ループを出て、分岐してステップ８１８に戻り、取得されたＫＤＭが検査される。反対に、鍵を求める要求が失敗した場合、ステップ８２８にて次のソースに対してループが繰り返されて、ステップ８２４にて次のソースを用いてＫＤＭの取得が試みられる。ステップ８２８にて、既知の鍵ソースがそれ以上無い場合、ループを出てステップ８３０へ進み、利用可能な鍵が無いという警告を発行する。処理はステップ８３４にて終了する。
【００８３】
図９には、ＣＰＬと鍵ソースとの間の関連性をトラッキングして、両者を別の装置に提供するための、処理９００を示す。この処理は、劇場管理システム１６６が実行してその管理下にあるデジタルシネマサーバ１６２にコンテンツを提供してもよいし、または、第１のデジタルシネマサーバ１６２が実行して第２のデジタルシネマサーバ１６２にコンテンツを提供してもよい。
【００８４】
処理９００は、ステップ９１０にて開始され、第１のサーバ（例えば、劇場管理システム１６６、またはデジタルシネマサーバ１６２）が、本発明のＤＣＰ（例えば、ＤＣＰ１３０）を取り込むべく準備される。ステップ９１２にて、第１のサーバがＤＣＰ１３０を取り込み、アセットマップ１３２、パッキングリスト（ＰＫＬ）１３４、コンポジションプレイリスト（複数可）（ＣＰＬ）１３６、アセットトラックファイル１３８、および、（ある場合は）鍵ソースファイル１３９を介してパースすることが可能となる。代替実施形態において、完全な取り込み（計算用チェックサムおよび非常に大きなファイルのダイジェストが含まれ、ファイルが漏洩しておらずエラーもないことが確実にされる）を行うのではなく、ステップ９１２にて、ＤＣＰ１３０が、単に第１のサーバに組み込まれて、少しのファイルのみ（例えば、鍵ソース表示を含むことが予測されるアセットマップ１３２）を読み込んで暗号化されたＣＰＬに関連する鍵ソース表示を探す、というものでもよい。
【００８５】
ステップ９１４にて、ＤＣＰ１３０において識別される暗号化されたＣＰＬと鍵ソースとの間の関連性毎に、記録が作成される。ステップ９１６にて、要求が第１のサーバにより受け取られ、ＣＰＬ１３６が第２のサーバ（例えば、第１のサーバとは異なるデジタルシネマサーバ１６２）に転送される。あるいは、第１のサーバは、第２のサーバからの要求を待たずに、ＣＰＬを第２のサーバに転送することを要求および／または開始することができる。
【００８６】
ステップ９１８にて、要求に応答して、ＣＰＬ１３６および関連するアセットトラックファイル１３８が第２のサーバに転送される。ステップ９２０にて、転送されたＣＰＬ１３６に関連付けられる鍵ソース表示が第２のサーバに供給され、第２のサーバは、ＣＰＬ１３６の上映に必要な鍵を、必要になる時より前に要求するのに十分な情報を有することができる。ステップ９１６にて、転送は、第１または第２のサーバのどちらが要求してもよく、その場合、要求の受領者（第２または第１のサーバ）が、ステップ９１８および９２０の転送を行うことができる。ステップ９１６にて、転送が第１のサーバにより、第２のサーバからの要求を待たずに開始される場合、第１のサーバは、ステップ９１８および９２０における転送を行うことができる。ステップ９２０にて転送が完了した後、処理９００は９２２にて終了する。
【００８７】
なお、ステップ９１４については、鍵ソース情報がＣＰＬ１３６内に埋め込まれている実施形態においては、ＣＰＬ１３６と少なくとも１つの鍵提供者システム１４０との間の関連性が、ＣＰＬ内に黙示的に提供される。同様に、９２０について、関連する鍵ソース表示の提供は、ステップ９１８において黙示的になされ、ＣＰＬ１３６は埋め込まれた鍵ソース情報と共に提供される。
【００８８】
従って、処理９００では、劇場管理システム１６６または第１のデジタルシネマサーバが、ＤＣＰ１３０を取り込んでしまっているが、後で、少なくとも１つの特定のＣＰＬ１３６および関連するアセットトラックファイル１３８を上映用の第２のサーバに、関連する鍵ソース表示と共に、転送することが可能とされる。このように、関心対象のＣＰＬのみ（および、その中で識別されるアセットトラックファイル１３８）が、第２のサーバに転送される必要があり、これは、ＤＣＰ１３０全体を転送することよりも、実質的にはより効率的であることが多いが、第２のサーバが、例えば、ステップ７１８で開始される処理７００の一部を使用して、適切なソースから鍵を取得することも可能とされる。
【００８９】
上記では、本発明の種々の実施形態が対象とされたが、本発明の他の実施形態が、その基本範囲から逸脱することなく考案されてよい。例えば、上記の例において記載された１つまたは複数の特徴は、修正、削除、および／または異なる組み合わせで使用されてよい。従って、本発明の適切な範囲は、以下の請求項に従って判断されるべきである。
【図１】
2015507403.tif 000003
【図２】
2015507403.tif 000004
【図３】
2015507403.tif 000005
【図４】
2015507403.tif 000006
【図５】
2015507403.tif 000007
【図６】
2015507403.tif 000008
【図７】
2015507403.tif 000009
【図８】
2015507403.tif 000010
【図９】
2015507403.tif 000011
【国際調査報告】
2015507403.tif 000012
2015507403.tif 000013