JP2016519471A - 安全なメディア再生のためのｄｌｎａ（登録商標）／ｄｔｃｐストリーム変換 - Google Patents

Abstract

ＤＴＣＰ−ＩＰトランスポート・ストリームをＨＬＳ形式に変換する処理方法であって、２次デバイスにおいて、暗号化されたＤＴＣＰ−ＩＰトランスポート・ストリームをソース・デバイスから受信する工程であって、暗号化されたＤＴＣＰ−ＩＰトランスポート・ストリームは、複数のＤＴＣＰフレームを備え、複数のＤＴＣＰフレームの各々は複数の暗号化された１６バイト部分を備える、工程と、ＤＴＣＰフレームの複数の暗号化された１６バイト部分を１つのチャンクにグループ化することによって、複数のＤＴＣＰフレームからチャンクを形成する工程と、暗号化されたチャンクを形成するように、各チャンクの最後にＨＬＳパディングバイトを追加して、ＨＬＳパディングバイトを暗号化する工程と、暗号化されたチャンクの各々とプレイリストとを、２次デバイスにおけるメディア・プロキシサーバにロードする工程と、ＤＴＣＰキーをセキュリティ・プロキシサーバ上にロードする工程と、プレイリスト、暗号化されたチャンクの各々、およびＤＴＣＰキーを、２次デバイス上に元々実装されているメディアプレーヤに提供する工程であって、元々実装されているメディアプレーヤは、プレイリストに従って、ＤＴＣＰキーを使用して、暗号化されたチャンクを解読して、チャンクを再生する、工程と、を備える。

Description

本開示は、デジタルビデオ記録およびストリーミングの分野に関し、特に、デジタルビデオレコーダから移動体デバイスへメディア・コンテンツを安全にストリーミングするためのシステムに関する。

インターネット上でメディア・コンテンツをストリーミングする、またはメディア・コンテンツをデバイスにダウンロードすることにより、消費者は、移動体電話またはタブレットコンピュータなどのテレビ以外のデバイス上でメディア・コンテンツにオンデマンドでアクセスして楽しめるようになった。さらに、消費者は、テレビ放送をリアルタイムで、または、放送を録画して後に視聴できるデジタルビデオレコーダ（ＤＶＲ）を通じて、楽しめるようにもなった。

しかし、デジタル著作権管理への配慮により、１つのデバイスから録画されたコンテンツを別のデバイスにストリーミングまたはダウンロードできるようにして、２つのメディア消費モデルを結合できるようになったのはつい最近のことである。たとえば、ケーブルボックスまたはＤＶＲなどの機器は、最近になってやっと、リアルタイム放送または録画コンテンツといったメディア・コンテンツをテレビ以外のデバイスにストリーミングまたはダウンロードできるようになった。多くの消費者が、外出中であるが、出先で特定の番組を移動体電話上で視聴したい場合などに、テレビ以外のデバイス上でライブ放送または録画放送を視聴できるという柔軟性を楽しめる一方で、多くのケーブルボックスおよびＤＶＲは、メディア・コンテンツの無許可のコピーまたは転送を防止するため、コンテンツを暗号化するか、または他のデジタル著作権管理方法を設けている。

メディア・コンテンツの無制限コピーを許可することなく、１つのデバイスからのコピー保護されたコンテンツに、許可を得て２次デバイス上でアクセスできるようにするいくつかのシステムが開発中である。たとえば、インターネットプロトコル経由でのデジタル送信コンテンツ保護（ＤＴＣＰ−ＩＰ）は、メディア・コンテンツがデータ接続上で１つのデバイスから別のデバイスへ移動する際に、メディア・コンテンツのコピー保護を提供する方法である。ＤＴＣＰ−ＩＰシステムでは、消費者は、ＤＶＲ上でテレビコンテンツを録画し、この録画したコンテンツを、コンテンツのコピー保護の維持と無許可コピーの防止を行いつつ、無線インターネット接続を通じてスマートフォンまたは他のデバイスにストリーミングすることができる。

ユーザ、他のアプリケーション、システムの他の部分に対して、解読されたクリア・メディア転送ストリームへのアクセスを可能にすることなく、クライアント・アプリケーションがメディア転送ストリームを十分安全に処理できる場合には、デバイスまたはオペレーティング・システムはＤＴＣＰ−ＩＰと互換性を有することができる。非限定的な例の方法では、ＤＴＣＰ−ＩＰは、ｉＯＳ（登録商標）オペレーティング・システムを実行するＡｐｐｌｅ（登録商標）デバイス、たとえばｉＰｈｏｎｅ（登録商標）およびｉＰａｄ（登録商標）上に実装される。これは、こうしたデバイスが、安全なブートチェーンを備えており、署名付きコードを許可し、信頼のルートが確立された安全なＨＴＴＰライブストリーミング（ＨＬＳ）プレーヤを元々実装しており（ネイティブであり）、難読化およびホワイトボックス保護を設けた安全なソフトウェア開発キット（ＳＤＫ）を、安全な信頼のルート、デバイス認証、さらに、安全なＲＳＡ証明書などのプライベートキーとリンクさせることが可能なためである。

したがって、必要なのは、リモート・デバイスの他のコンポーネントをメディア・ストリームにアクセスさせずに、ソース・デバイスからリモート・デバイスにて受信したＤＴＣＰ−ＩＰメディア・ストリームを、リモート・デバイス上に元々実装されている（ネイティブ）メディアプレーヤで可読な形式に変換する処理方法である。ＤＴＣＰ−ＩＰメディア・ストリームは、リモート・デバイスに元々実装されているメディアプレーヤで再生可能にするべく、解読、チャンク化、再暗号化したり、または、ＤＴＣＰ−ＩＰメディア・ストリームを、ＨＬＳパディングバイトを追加する、および／もしくは、ＤＴＣＰ−ＩＰパディングバイトをＨＬＳパディングバイトに置き換えることで、解読せずにチャンクに分割したりすることができる。

一実施形態においては、本開示は、ＤＴＣＰ−ＩＰトランスポート・ストリームをＨＬＳ形式に変換する処理を提供するものであり、この処理は、２次デバイスにおいて、暗号化されたＤＴＣＰ−ＩＰトランスポート・ストリームをソース・デバイスから受信する工程であって、暗号化されたＤＴＣＰ−ＩＰトランスポート・ストリームは、複数のＤＴＣＰフレームを備え、この複数のＤＴＣＰフレームの各々は複数の暗号化された１６バイト部分を備える、工程と、ＤＴＣＰフレームの複数の暗号化された１６バイト部分の１以上を１つのチャンクにグループ化することによって、複数のＤＴＣＰフレームの１つからチャンクを形成する工程と、チャンクの最後にＨＬＳパディングバイトを追加して、ＨＬＳパディングバイトを暗号化する工程であって、チャンクと暗号化されたＨＬＳパディングバイトとが暗号化されたＨＬＳチャンクを形成している、工程と、暗号化されたＨＬＳチャンクの各々と暗号化されたＨＬＳチャンクのプレイリストとを、２次デバイスにおけるメディア・プロキシサーバにロードする工程と、ＤＴＣＰキーを２次デバイスにおけるセキュリティ・プロキシサーバにロードする工程であって、ＤＴＣＰキーは、ソース・デバイスから入手されている、工程と、プレイリスト、暗号化されたＨＬＳチャンクの各々、およびＤＴＣＰキーを、２次デバイス上に元々実装されているメディアプレーヤに提供する工程であって、元々実装されているメディアプレーヤは、前記プレイリストに従って、ＤＴＣＰキーを使用して、暗号化されたＨＬＳチャンクを解読して、ＨＬＳチャンクを再生する工程と、を備える。

以下の添付の図面の補助により、本発明のさらなる詳細を説明する。
ネットワーク上で、ソース・デバイスから１以上の２次デバイスへメディア・コンテンツを提供するシステムを示す図。 ソース・デバイスの例示的な実施形態を示す図。 ２次デバイスの例示的な実施形態を示す図。 ２次デバイス上のメディアプレーヤで再生するために、トランスポート・ストリームを受信および変換する第１処理を示す図。 図４の工程中の、受信したトランスポート・ストリームをメディアプレーヤ上で再生可能な形式に変換する過程で使用される要素を示す図。 ソース・デバイスのＤＴＣＰ−ＩＰモジュールによって暗号化されたメディア・コンテンツの例示的な部分を示す図。 トランスポート・ストリームをカプセル化する過程で作成されたＤＴＣＰフレームの例示的な実施形態を示す図。 ２次デバイス上のメディアプレーヤで再生するために、トランスポート・ストリームを受信および変換するための第２処理を示す図。 ＤＴＣＰフレームを、ＨＬＳパディングバイトを組み込んだ暗号化されたチャンクに変換することを示す図。 暗号化されたチャンクを形成するために、ＤＴＣＰペイロードの最終部分から作成されたチャンクにおいて、ＤＴＣＰパディングバイトをＨＬＳパディングバイトに置き換えることを示す図。

図１は、ネットワーク１０４上で、ソース・デバイス１００から１以上の２次デバイス１０２へメディア・コンテンツを提供するシステムを示す。ソース・デバイス１００は、ＤＶＲ、ケーブルボックス、ホームメディアサーバ、または、メディア・コンテンツを受信および記憶、あるいは受信もしくは記憶する任意の他のソースであってもよい。ソース・デバイス１００は、無線または有線データ接続、インターネット接続、および／もしくはローカル・ネットワークといったネットワーク１０４上で、メディア・コンテンツを受信し、ならびに／または、１以上の２次デバイス１０２上で視聴できるよう調整することができる。２次デバイス１０２は、スマートフォン、タブレットコンピュータ、コンピュータ、または、任意の他のデバイスといった、移動体デバイスであってもよい。一実施形態では、ソース・デバイス１００は、ソース・デバイスとテレビ１０６との間の直接接続１０８（同軸ケーブルまたはＨＤＭＩ（登録商標）（Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ）ケーブルなど）によって、メディア・コンテンツを１以上のテレビ１０６またはモニタ上で視聴するべく、追加的および代替的、あるいは追加的もしくは代替的に提供する。

図２は、ソース・デバイス１００の例示的な実施形態を示す。一実施形態においては、ソース・デバイス１００は１以上のチューナ２０２、トランスコーダ２０４、ストレージ・デバイス２０６、ＤＴＣＰ−ＩＰモジュール２０８、および／もしくはメディアサーバ２１０を備える。

チューナ２０２は、ケーブルまたは衛星接続を通じて受信したテレビ放送などのメディア・コンテンツを受信するように構成できる。チューナ２０２で受信したメディア・コンテンツを、トランスコーダ２０４によって、ストレージ・デバイス２０６に録画として記憶可能なデジタル形式にトランスコードすることができる。ストレージ・デバイス２０６は、ハードドライブ、フラッシュメモリ、ランダムアクセスメモリといったメモリ、または任意の他のタイプのメモリであってもよい。いくつかの状況および実施形態、あるいは状況または実施形態においては、録画されたメディア・コンテンツは録画されれば、その視聴が可能になるため、視聴者はそれを、録画されたメディア・コンテンツを一時停止したり巻き戻したりすることができる実質的なライブ放送であると認識することができる。別の状況および実施形態、あるいは状況または実施形態においては、録画されたメディア・コンテンツを、後に、ライブ視聴、一時停止、巻き戻し、および／または早送りのオプション付きで視聴することができる。録画されたメディア・コンテンツは、ソース・デバイス１００と通信した状態のテレビ１０６上で、または、以下で説明するように、ネットワーク１０４を通じてソース・デバイス１００に接続したテレビ以外の２次デバイス１０２上で視聴することが可能である。しかしながら、一実施形態においては、チューナ２０２で受信したビデオコンテンツをＤＴＣＰ−ＩＰモジュール２０８へ直接送ることができるので、ストレージ・デバイス２０６はオプションまたは一時的なバッファであってもよい。

２次デバイス１０２上で視聴する場合には、録画したメディア・コンテンツをストレージ・デバイス２０６から取り出し、ＤＴＣＰ−ＩＰモジュール２０８へ送ることができる。ＤＴＣＰ−ＩＰモジュール２０８は「インターネットプロトコル経由でのデジタル送信コンテンツ保護」（ＤＴＣＰ−ＩＰ）方法を使用して、メディア・コンテンツを暗号化することができる。ＤＴＣＰ−ＩＰ方法は、録画された放送などのメディア・コンテンツがデータ接続経由で１つのデバイスから別のデバイスへ転送される際に、このメディア・コンテンツにコピー保護を提供することが可能である。ＤＴＣＰ−ＩＰモジュール２０８は
、ＤＴＣＰキーを用いてメディア・コンテンツを暗号化できる。以下で説明するように、ＤＴＣＰ−ＩＰモジュール２０８は、ＤＴＣＰキー２１２に関する情報を１以上の２次デバイス１０２に提供し、２次デバイスはこの情報からＤＴＣＰキー２１２を導出することができる。さらに、ＤＴＣＰ−ＩＰモジュール２０８は、暗号化されたＤＴＣＰ−ＩＰ放送を、コンテナ・フォーマットを使用してトランスポート・ストリーム２１４内にカプセル化することが可能である。非限定的な例では、ＤＴＣＰ−ＩＰ放送をＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）トランスポート・ストリーム内にカプセル化することができる。ＤＴＣＰ−ＩＰモジュール２０８によるメディア・コンテンツのトランスポート・ストリーム２１４への暗号化およびカプセル化について、以下で図６を参照してさらに説明する。

ＤＴＣＰ−ＩＰモジュール２０８によって暗号化およびカプセル化されたトランスポート・ストリームは、メディアサーバ２１０へ渡される。メディアサーバ２１０は、２次デバイス１０２からの要求を受信すると、インターネット、ローカル有線または無線データネットワークなどのネットワーク１０４、または任意の他のネットワークを通じて、要求側の２次デバイス１０２にトランスポート・ストリーム２１４を配布することができる。非限定的な例では、メディアサーバ２１０は、デジタル・リビング・ネットワーク・アライアンス（ＤＬＮＡサーバ）により証明されたサーバであってもよい。

図３は、２次デバイス１０２の例示的な実施形態を示す。２次デバイス１０２は、処理ブロック３０２、ＤＴＣＰ−ＩＰセキュリティブロック３０４、補助セキュリティブロック３０６、メディア・プロキシサーバ３０８、セキュリティ・プロキシサーバ３１０、および／またはメディアプレーヤ３１２を備えることができる。一実施形態においては、処理ブロック３０２、ＤＴＣＰ−ＩＰセキュリティブロック３０４、補助セキュリティブロック３０６、メディア・プロキシサーバ３０８、セキュリティ・プロキシサーバ３１０は、２次デバイス１０２上で実行中のクライアント・アプリケーション３１４に提供されて、動作することができ、あるいは提供されるか動作することができ、一方、メディアプレーヤ３１２は、図２に示すように、２次デバイスのオペレーティング・システムに元々実装された安全なメディアプレーヤであってもよい。非限定的な例では、数種のＡｐｐｌｅ（登録商標）デバイスで使用されているｉＯＳ（登録商標）オペレーティング・システムには、以下で説明するように、メディアプレーヤ３１２として使用できる、安全なＨＴＴＰライブストリーミング（ＨＬＳ）プレーヤが元々実装されていてもよい。一実施形態においては、クライアント・アプリケーション３１４は安全な方法で実行できるので、データにアクセスすることが可能な２次デバイス１０２の、メディアプレーヤ３１２を除くその他のハードウェアまたはソフトウェアコンポーネントを提供しなくても、ほとんどのデータをクライアント・アプリケーション３１４内で処理および保持することができる。非限定的な例では、数種のＡｐｐｌｅ（登録商標）デバイスで使用されているｉＯＳ（登録商標）オペレーティング・システムは、安全なブートチェーン、署名付きコード、安全なＲＳＡ証明書、デバイス認証といった、クライアント・アプリケーション３１４の安全な実行を支援する要素を含んでいる。

図４は、２次デバイス１０２上のメディアプレーヤ３１２で再生するためにトランスポート・ストリーム２１４を受信および変換する第１処理を示す。図５は、図４の工程中の、受信したトランスポート・ストリーム２１４をメディアプレーヤ３１２上で再生可能な形式に変換する過程で使用される要素を示す。

工程４０２では、２次デバイス１０２上で実行中のクライアント・アプリケーション３１４が、ネットワーク１０４上で、ソース・デバイス１００のメディアサーバ２１０からのトランスポート・ストリーム２１４を要求する。上述したように、トランスポート・ストリーム２１４は、ＤＴＣＰキー２１２を使用するＤＴＣＰ−ＩＰコピー保護方法を用い
て、ＤＴＣＰ−ＩＰモジュール２０８によって暗号化されていてもよい。さらに、トランスポート・ストリーム２１４は、ＤＴＣＰ−ＩＰモジュール２０８によって、ＭＰＥＧトランスポート・ストリーム用のＤＴＣＰコンテナなどのコンテナ・フォーマットにカプセル化されていてもよい。

工程４０４では、クライアント・アプリケーション３１４内の処理ブロック３０２は、要求したトランスポート・ストリーム２１４を、メディアサーバ２１０からネットワーク１０４経由で受信する。一実施形態においては、クライアント・アプリケーション３１４は、トランスポート・ストリーム２１４の受信時に、処理を開始するのに十分なデータが受信されるまでこれをバッファすることができる。一実施形態においては、処理ブロック３０２はトランスポート・ストリーム２１４を脱カプセル化することもできる。

工程４０６では、処理ブロック３０２は、ソース・デバイスのＤＴＣＰ−ＩＰモジュール２０８が暗号化に使用したものと同じＤＴＣＰキー２１２を使用して、トランスポート・ストリーム２１４を解読することができるため、トランスポート・ストリーム２１４は解読されて、図５に示すように暗号化されていないクリア・トランスポート・ストリーム５００となる。処理ブロック３０２は、２次デバイス１０２内のＤＴＣＰ−ＩＰセキュリティブロック３０４からＤＴＣＰキー２１２を入手できる。ＤＴＣＰ−ＩＰセキュリティブロック３０４は、ＤＴＣＰキー２１２をクライアント・アプリケーション３１４内で導出または再構成するのに十分なだけの、ＤＴＣＰキー２１２に関する情報を、ソース・デバイス１００から事前に入手しておくことができる。

一実施形態においては、特定のソース・デバイス１００内でＤＴＣＰ−ＩＰモジュール２０８がメディア・ストリームを暗号化するために使用したＤＴＣＰキー２１２に関する情報を、特定のソース・デバイス１００からストリームにアクセスすることを許可された各２次デバイス１０２内のＤＴＣＰ−ＩＰセキュリティブロック３０４に配布することができる。これにより、ＤＴＣＰ−ＩＰセキュリティブロック３０４、またはクライアント・アプリケーション３１４のその他の部分が、ＤＴＣＰキー２１２を導出または再構成できるようになる。一実施形態では、２次デバイス１０２およびクライアント・アプリケーション３１４、あるいは２次デバイス１０２またはクライアント・アプリケーション３１４は、２次デバイス１０２またはクライアント・アプリケーション３１４を許可識別子（加入者アカウント、ユーザ識別子、メンバー識別子、または任意の他の識別子など）と関連付けることにより、特定のソース・デバイス１００からストリームにアクセスすることを許可される。非限定的な例では、ケーブルテレビサービスの加入者は、ソース・デバイス１００を、テレビ１０６に接続したケーブルボックスおよびＤＶＲ、あるいはケーブルボックスまたはＤＶＲとして自宅に設置し、ソース・デバイス１００内のＤＴＣＰ−ＩＰモジュール２０８を加入者アカウントにリンクさせることができる。さらに、ソース・デバイス１００と２次デバイス１０２は両方とも加入者アカウントにリンクしているため、ケーブル加入者は、スマートフォンなどの２次デバイス１０２上のクライアント・アプリケーション３１４を通じて自分のアカウントにサインインして、２次デバイス１０２が加入者アカウントにリンクされたソース・デバイス１００からストリームを受信するための許可を受けることができる。この例では、加入者のソース・デバイス１００内のＤＴＣＰ−ＩＰモジュール２０８によって使用されるＤＴＣＰキー２１２に関する情報を、加入者に関連付けられた各２次デバイス１０２内のＤＴＣＰ−ＩＰセキュリティブロック３０４に配布することができ、これにより、加入者に関連付けられた任意の２次デバイス１０２がＤＴＣＰキー２１２を導出し、加入者に関連付けられたソース・デバイス１００により暗号化されたコンテンツを解読できるようになる。

工程４０８では、クリア・トランスポート・ストリーム５００を処理し、チャンク５０２に分割できる。一実施形態においては、チャンク５０２は、クリア・トランスポート・
ストリーム５００の実質的に均等な時間のセグメントであってもよい。非限定的な例では、一実施形態において、各チャンク５０２は、クリア・トランスポート・ストリーム５００の実質的に長さ５秒間の部分であってもよい。別の実施形態においては、各チャンク５０２は、実質的に長さ１秒間、１０秒間であるか、あるいは、任意の他の所望の長さのクリア・トランスポート・ストリーム５００の一部であってもよい。

一実施形態においては、チャンク５０２に分割する前のクリア・トランスポート・ストリーム５００を、その内部にプログラム時刻基準（ＰＣＲ：Ｐｒｏｇｒａｍ Ｃｌｏｃｋ
Ｒｅｆｅｒｅｎｃｅ）を見出すべく処理することができる。クライアント・アプリケーション３１４は、プログラム関連付けテーブル（ＰＡＴ）およびプログラム・マップ・テーブル（ＰＭＴ）、プログラム時刻基準（ＰＣＲ）のパケット識別子（ＰＩＤ：Ｐａｃｋｅｔ Ｉｄｅｎｔｉｆｉｅｒ）に関して、クリア・トランスポート・ストリーム５００を調べることができる。プログラム関連付けテーブル（ＰＡＴ）は、クリア・トランスポート・ストリーム５００内で利用できる全てのプログラムを列挙することができる。各々のプログラム・マップ・テーブル（ＰＭＴ）は、プログラム関連付けテーブル（ＰＡＴ）に挙げられた１つのプログラムに関する情報を記述できる。クリア・トランスポート・ストリーム５００の異なるコンポーネント同士を同期できるようにするために、プログラム時刻基準（ＰＣＲ）をクリア・トランスポート・ストリーム５００の全体にわたって含めることができる。非限定的な例では、ＰＣＲをクリア・トランスポート・ストリーム５００内の少なくとも１００ミリ秒毎に含めることにより、クリア・トランスポート・ストリーム５００内のオーディオトラックとビデオトラックをＰＣＲに従って同期できるようにしている。一実施形態においては、ＰＣＲがクリア・トランスポート・ストリーム５００の全体にわたり規則的な間隔で出現する度に、クリア・トランスポート・ストリーム５００のＰＣＲの少なくとも一部を、クリア・トランスポート・ストリーム５００を実質的に等しい時間のチャンク５０２に分割するために使用できる。非限定的な例では、ＰＣＲを、クリア・トランスポート・ストリームのビットレートを推定するために使用でき、各チャンク５０２内に何ビット含めるべきかを決定するためにも使用できる。

代替実施形態においては、クリア・トランスポート・ストリーム５００の処理およびチャンク化は、ＰＣＲについてクリア・トランスポート・ストリーム５００を調べることなく実行できる。非限定的な例では、一実施形態において、クライアント・アプリケーション３１４がクリア・トランスポート・ストリーム５００のビットレートを決定する、または知らされることができる。クライアント・アプリケーション３１４が、クリア・トランスポート・ストリーム５００が均等なビットレートを有することを決定する、または知らされる状況では、ビットをカウントし、等しいデータサイズのチャンク５０２を作成することで、クライアント・アプリケーション３１４が、クリア・トランスポート・ストリーム５００を実質的に等しい時間のチャンク５０２に分割できるようになる。ビットレートが可変であるが、クリア・トランスポート・ストリーム５００のいくつかまたは全てから平均ビットレートを決定できる別の状況においては、実質的に等しい時間を平均ビットレートに従って推定することで、実質的に等しい時間のチャンク５０２を作成することができる。非限定的な例では、クリア・トランスポート・ストリームの開始区間、たとえば最初の１０秒間を、平均ビットレートを見出すために調べることができ、さらに、この平均ビットレートを、クリア・トランスポート・ストリーム５００の残り部分について推定される平均ビットレートとして使用することができる。別の非限定的な例では、クリア・トランスポート・ストリーム５００の総データサイズを合計持続時間で割ることで、平均ビットレートを推定できる。平均ビットレートを使用するこれらの状況のいくつかにおいては、いくつかのケースではより長いチャンク５０２が平均合計ビットレートにより近づくことがあるため、チャンク５０２の時間を、別の実施形態における時間よりも長くなるように選択できる。さらに別の、特にタイミングがサーバによって大まかに実行される実施形態においては、リアルタイムで事前に選択された時間間隔を時計を使用して測ることが
でき、チャンク５０２がそれぞれの時間間隔でクリア・トランスポート・ストリーム５００から発生する。

工程４１０では、工程４０８でのチャンク作成時に、チャンク５０２のＩＤおよびシーケンスを記述したプレイリスト５０４を生成でき、このプレイリスト５０４を２次デバイス１０２内のメディア・プロキシサーバ３０８上に記憶させることができる。メディア・プロキシサーバ３０８は、２次デバイス１０２内のローカルＨＴＴＰプロキシサーバであってもよい。一実施形態においては、プレイリスト５０４はローリング．ｍ３ｕ、．ｍ３ｕ８、またはその他のタイプの、チャンク５０２を記述した情報を含むプレイリストであってもよい。一実施形態においては、プレイリスト５０４はさらに、チャンク５０２の持続時間を記述したＥＸＴ−ＩＮＦタグをさらに備えてもよい。非限定的な例では、各チャンク５０２の長さを１０秒間に設定した場合、プレイリスト５０４のＥＸＴ−ＩＮＦを１０秒間に設定することができる。上述したように、ＥＸＴ−ＩＮＦタグに記述するチャンク５０２の持続時間は、ＰＣＲを使用すること、固定のビットレートのクリア・トランスポート・ストリーム５００内のビットをカウントすること、クリア・トランスポート・ストリーム５００の平均ビットレートを調べた後にビットをカウントすること、および／または、クリア・トランスポート・ストリーム５００内でチャンク５０２を所定の時間間隔で分割するためにリアルタイム・クロックを使用すること、によって決定することができる。

工程４１２では、処理ブロック３０２は、チャンクキー５０６を用いて各チャンク５０２を暗号化して暗号化されたチャンク５０８にし、次に各々の暗号化されたチャンク５０８をメディア・プロキシサーバ３０８上に記憶することができる。一実施形態においては、各々のチャンク５０２を同一のチャンクキー５０６を用いて暗号化でき、別の実施形態においては、異なるチャンクキー５０６のシーケンスを用いて、各々のチャンク５０２を暗号化できる。一実施形態においては、チャンク５０２を暗号化するために使用した１以上のチャンクキー５０６は、ＤＴＣＰキー２１２とは異なるキーであってもよく、たとえば、補助セキュリティブロック３０６またはＤＴＣＰ−ＩＰセキュリティブロック３０４によって処理ブロック３０２に提供された、および／または、処理ブロック３０２によって生成されたチャンクキー５０６であってもよい。非限定的な例では、補助セキュリティブロック３０６は、チャンクキー５０６として使用するための、１以上の新規のキーを生成し、処理ブロック３０２に提供することができる。代替実施形態では、チャンクキー５０６はＤＴＣＰキー２１２と同じであってもよい。非限定的な例では、処理ブロック３０２が、工程４０６でチャンクキー５０６として入手したＤＴＣＰキー２１２のコピーを再使用することができるか、あるいは、ＤＴＣＰ−ＩＰセキュリティブロック３０４が、ソース・デバイス１００から入手したＤＴＣＰキー２１２を補助セキュリティブロック３０６に提供することにより、工程４１２で、ＤＴＣＰキー２１２を、チャンク５０２を暗号化して暗号化されたチャンク５０８にするためのチャンクキー５０６として使用するために、補助セキュリティブロック３０６から処理ブロック３０２に提供できるようになる。一実施形態においては、処理ブロック３０２はコピー制御情報（ＣＣＩ：Ｃｏｐｙ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）、権利情報、および出力制御、あるいは権利情報、または出力制御、たとえばＤＴＣＰ−ＩＰセキュリティブロック３０４から受信したＣＣＩを追加的に処理することができる。

工程４１４では、工程４１２でのチャンク５０２の暗号化に使用された１以上のチャンクキー５０６は、２次デバイス１０２内のセキュリティ・プロキシサーバ３１０上でホストされてもよい。セキュリティ・プロキシサーバ３１０は、メディア・プロキシサーバ３０８と類似した、２次デバイス１０２内のローカルＨＴＴＰプロキシサーバであってもよい。補助セキュリティブロック３０６は、処理ブロック３０２に工程４１２で使用するためのチャンクキー５０６を提供することに加え、１以上のチャンクキー５０６をセキュリ
ティ・プロキシサーバ３１０に提供することができる。代替実施形態においては、処理ブロック３０２が、チャンク５０２の暗号化に使用したチャンクキー５０６をセキュリティ・プロキシサーバ３１０に提供することができる。

工程４１６では、メディアプレーヤ３１２が、ソース・デバイス１００から受信したメディア・コンテンツを再生することができる。メディアプレーヤ３１２は、メディア・プロキシサーバ３０８およびセキュリティ・プロキシサーバ３１０の両方と通信した状態にあってもよい。メディアプレーヤ３１２は、メディア・プロキシサーバ３０８に記憶されたプレイリスト５０４を使用して、どのチャンク５０２を、および／またはどのような順序で再生するかを決定できる。メディアプレーヤ３１２は、プレイリスト５０４によって記述されたチャンク５０２に対応したメディア・プロキシサーバ３０８から、暗号化されたチャンク５０８を入手できる。次に、メディアプレーヤ３１２は、暗号化されたチャンク５０８の各々について適切なチャンクキー５０６を入手し、このチャンクキー５０６を、暗号化されたチャンク５０８を解読して暗号化されていないチャンク５０２にするために使用できる。次に、この暗号化されていないチャンク５０２を再生し、映像として２次デバイス上に表示することができる。メディアプレーヤ３１２は、プレイリスト５０４内の後続のチャンク５０２についてもこの処理を繰り返すことで、要求されたメディア・コンテンツの或る部分または全体を再生できる。

一実施形態においては、各チャンクキー５０６をメディアプレーヤ３１２に安全に送達するために、メディアプレーヤ３１２とセキュリティ・プロキシサーバ３１０との間に双方向ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）接続を確立することが可能である。一実施形態においては、メディアプレーヤ３１２とセキュリティ・プロキシサーバ３１０との間の双方向ＳＳＬ接続により、セキュリティ・プロキシサーバ３１０が、２次デバイス１０２が管理するデバイス認証をチェックできるようになり、また、メディアプレーヤ３１２について、セキュリティ・プロキシサーバ３１０が管理する認証をチェックできるようになる。

一実施形態においては、プレイリスト５０４は、チャンク５０２が作成されれば、および／または、チャンク５０２を暗号化して暗号化されたチャンク５０８にする工程が開始されれば、プレイリスト５０４が各チャンク５０２に関するデータを含むことができるので、メディアプレーヤ３１２は、チャンク５０２に気付き、可能な限り早くチャンク５０２の再生を始めることができる。同様に、一実施形態においては、暗号化されたチャンク５０８を小片にてメディア・プロキシサーバ３０８およびメディアプレーヤ３１２、あるいはメディア・プロキシサーバ３０８またはメディアプレーヤ３１２へ転送することができるので、メディアプレーヤ３１２が最初の小片を受信すれば、暗号化されたチャンク５０８の解読および再生を始められるようにしている。メディア・コンテンツが事前に録画され、そのメディア・コンテンツのソース・デバイス１００におけるトランスコードがリアルタイムよりも高速で行われるいくつかの状況では、可能な限り早く再生を開始するべく、チャンク５０２を可能な限り早く作成、暗号化、転送、解読するために、２次デバイス１０２が、トランスポート・ストリーム２１４の開始部分をリアルタイム速度よりも高速でロードしようとする。

図６Ａは、ソース・デバイス１００のＤＴＣＰ−ＩＰモジュール２０８によって暗号化されたメディア・コンテンツの例示的な部分６００を示す。図６Ｂは、トランスポート・ストリーム２１４のカプセル化の過程において作成されたＤＴＣＰフレーム６０４の例示的な実施形態を示す。

一実施形態においては、ソース・デバイス１００におけるメディア・コンテンツのトランスポート・ストリーム２１４への最初の暗号化は、図６Ａに示すように、ＤＴＣＰ−Ｉ
Ｐモジュール２０８によって、事前に決定されたサイズのメディア・コンテンツの部分６００を連続的に暗号化することで実行できる。非限定的な例では、ＤＴＣＰ−ＩＰモジュール２０８は、メディア・コンテンツをＡＥＳ−ＣＢＣ（高度暗号化規格（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）／暗号・ブロック連鎖（Ｃｉｐｈｅｒ−Ｂｌｏｃｋ Ｃｈａｉｎｉｎｇ））に従って暗号化できる。この場合、部分６００の事前決定されたサイズは１６バイトである。代替実施形態においては、任意の他の事前決定されたサイズを部分６００に使用できるが、本開示では簡略化のために、部分６００をＡＥＳ−ＣＢＣで使用される１６バイトを持つものとして言及する。

各々の部分６００を、ＤＴＣＰキー２１２に加え初期化ベクトル（ＩＶ：Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｖｅｃｔｏｒ））６０２を使用して暗号化することができる。第１部分６００は導出されたＩＶ６０２を使用して暗号化できるが、第１部分６００が暗号化された後は、先に暗号化された部分６００を、次の部分６００を暗号化するためのＩＶ６０２として使用できるようになる。非限定的な例では、ＡＥＳ−ＣＢＣ方法において、メディア・コンテンツの１６バイト部分６００が暗号化されると、この暗号化された１６バイト部分６００を、メディア・コンテンツの次の１６バイトを暗号化するためのＩＶ６０２として使用できるようになる。

ＤＴＣＰ−ＩＰモジュール２０８は、暗号化されたメディア・コンテンツをトランスポート・ストリーム２１４内にカプセル化する際に、暗号化されたメディア・コンテンツを複数のＤＴＣＰフレーム６０４にセグメント化することができる。図６Ｂは、例示的なＤＴＣＰフレーム６０４を示す。各ＤＴＣＰフレーム６０４は、ヘッダ６０６、ペイロード６０８、テール６１０を備える保護されたコンテンツパケット（ＰＣＰ：Ｐｒｏｔｅｃｔｅｄ Ｃｏｎｔｅｎｔ Ｐａｃｋｅｔ）であってもよい。ヘッダ６０６とテール６１０はＤＴＣＰフレーム６０４に関する情報データを備え、一方、ペイロード６０８はメディア・コンテンツの１以上の暗号化された部分６００を備えることができる。上述したように、ＤＴＣＰフレームのペイロードデータ６０８内の、最初の部分６００を除いた暗号化された各部分６００は、先に暗号化された部分６００をＩＶ６０２として使用して暗号化されることができる。そのため、ペイロード６０８内の暗号化された各部分６００のＩＶ６０２は、直前に暗号化された部分６００を探すことで、見出すことができる。ペイロード６００内の最初の部分６００を暗号化するために使用したデフォルトのＩＶ６０２は、ＤＴＣＰフレームのヘッダ６０６内に記憶される。

いくつかの状況においては、図８Ａの上部に示すように、ペイロード６０８の最終部分６００は、１以上のＤＴＣＰパディングバイト８０２を備えることができる。これらの状況においては、ＤＴＣＰフレーム６０４の最終部分６００に、メディア・コンテンツ自体からの所定のバイト数よりも少ないバイト数を含ませ、暗号化中に残りの所定のバイト数をＤＴＣＰパディングバイト８０２によって補完することができる。非限定的な例では、所定サイズの部分６００を１６バイトに設定した場合、ペイロード６０８の最終部分６００はメディア・コンテンツからの１〜１５バイトを含み、残りをＤＴＣＰパディングバイト８０２を使用して合計１６バイトになるよう補完することができる。

図７は、２次デバイス上のメディアプレーヤ３１２で再生するためにトランスポート・ストリーム２１４を受信および変換するための第２処理を示す。図７の処理は、ＤＴＣＰフレーム６０４をメディアプレーヤ３１２が希望する暗号化されたチャンク８０６に変換するために、クライアント・アプリケーション３１４によって使用され得る。一実施形態においては、以下で説明するように、ＤＴＣＰフレーム６０４をより小さいチャンク８００に分割して、不足部分をパディングバイト８０４でパディングを行い、次に、各チャンク８００が自己暗号化を行うことで、暗号化されたチャンク８０６として使用できるようになる。暗号化されたチャンク８０６は、図４の処理で生成される暗号化されたチャンク
５０８と類似してもよい。

一実施形態においては、２次デバイスのメディアプレーヤ３１２によって解読および再生できる暗号化されたチャンク８０６内のパディングバイト８０４の形式は、ＤＴＣＰフレーム６０４の部分６００を補完するために使用されるＤＣＴＰパディングバイト８０２の形式とは異なる。非限定的な例では、Ａｐｐｌｅ（登録商標）のｉＯＳ（登録商標）デバイスに元々実装されているメディアプレーヤはＨＬＳプレーヤである。ＨＬＳは、ＡＥＳ−ＣＢＣ暗号化により暗号化されたチャンク５０８または８０６を、ＤＴＣＰ−ＩＰがＡＥＳ−ＣＢＣ暗号化により暗号化されたＤＴＣＰフレーム６０４を使用するのと全く同様に使用する。しかしながら、ＨＬＳ暗号化されたチャンク５０８または８０６、およびＤＴＣＰフレーム６０４では、使用するパディングバイトは異なる。ＤＴＣＰフレーム６０４内のＤＴＣＰパディングバイト８０２を、図８Ａに示すように代替ＨＬＳパティングバイト８０４に置き換えるか、または、図８Ｂに示すようにＤＴＣＰフレーム６０４のチャンク８００にＨＬＳパディングバイト８０４を付加することで、ＤＴＣＰフレーム６０４を、トランスポート・ストリーム２１４の完全な解読と、クリア・トランスポート・ストリーム５００のチャンク化と、個々のチャンク５０２の暗号化済みチャンク５０８への完全な再暗号化とを伴った図４の処理を経ずに、ＨＬＳプレーヤで読み出せる、ＨＬＳ形式の暗号化されたチャンク８０６に変換できるようになる。

工程７０２では、クライアント・アプリケーション３１４は、ＤＴＣＰフレーム６０４を受信すると、個々の部分６００を解読せずに、ＤＴＣＰフレーム６０４をチャンク８００に分割することができる。各チャンク８００は、ＤＴＣＰフレームのペイロード６０８からの、典型的にはＮ秒間のチャンクを作成できるだけの数の、多数の暗号化された部分６００を備えることができる。非限定的な例では、ＤＴＣＰフレーム６０４は複数の１６バイト部分６００を備えることができ、この際、数個の部分６００が各チャンク８００を形成することで、各チャンク８００が１６バイトの倍数のデータサイズを有するようになる。

工程７０４では、パディングバイト８０４を各チャンク８００の最後に追加でき、図８Ａに示すようにこの追加した部分を暗号化し、チャンク８００を暗号化されたチャンク８０６にすることができる。メディアプレーヤ３１２がＤＴＣＰフレームのペイロード６０８を読み出し、再生できるようにするために、パディングバイト８０４はメディアプレーヤ３１２が希望する形式にすることができる。非限定的な例では、Ａｐｐｌｅ（登録商標）のｉＯＳ（登録商標）で使用されるメディアプレーヤ３１２は、暗号化された各チャンク５０８の最後のＨＬＳパディングバイト８０４を見出すことが期待されるＨＬＳプレーヤであってもよく、したがって、代替パディングバイト８０４はＨＬＳパディングバイトであってもよい。一実施形態においては、個々の部分６００のサイズと等しい多数のパディングバイト８０４をチャンク８００の最後に追加できる。非限定的な例では、チャンク８００が、ＤＴＣＰフレーム６０４からのいくつかの１６バイト部分６００をグループ化して形成されている場合、１６のパディングバイト８０４をチャンク８００の最後に追加することができる。ＤＴＣＰフレーム６０４から発生した既に暗号化済みのチャンク８００と、新たに追加され暗号化されたパディングバイト８０４とが、完全に暗号化されたチャンク８０６を形成できるようにするために、追加されたパディングバイト８０４はＤＴＣＰキー２１２により暗号化することができる。

しかしながら、図８Ｂに示すようにいくつかの状況では、特定のＤＴＣＰフレームのペイロード６０８の暗号化された最終部分６００は、メディア・コンテンツからの総バイト数に満たないバイトを含み、残りをＤＴＣＰパディングバイト８０２で補完されたものであってもよい。この暗号化された最終部分６００をチャンク８００の一部として使用する場合には、暗号化された最終部分６００を解読し、そのＤＴＣＰパディングバイト８０２
を除去して、ＨＬＳパディングバイト８０４に置き換えることができる。非限定的な例では、ＡＥＳ−ＣＢＣ暗号化方法において、ペイロード６０８の最終部分６００はペイロード６０８の最後の１６バイトであってもよい。クライアント・アプリケーション３１４は、ペイロード６０８内の最終部分６００の直前に存在する部分６００を見出すことによって、最終部分６００にＩＶ６０２を見出すこともできる。非限定的な例では、ＡＥＳ−ＣＢＣ暗号化方法において、最後の１６バイトについてのＩＶ６０２は、図６Ｂに示すように、最後の１６バイトの前に存在する１６バイトを調べることで見出すことができる。最終部分６００のＩＶ６０２は、最終部分６００を解読するために、ＤＴＣＰキー２１２と併用することができる。工程４０６と同様に、ＤＴＣＰ−ＩＰセキュリティブロック３０４がＤＴＣＰキー２１２を処理ブロックに提供することが可能である。最終部分６００の解読が終わったら、ＤＴＣＰパディングバイト８０２をＨＬＳパディングバイト８０４に置き換えることができる。置き換えたＨＬＳパディングバイト８０４を含んだ最終部分６００を再度暗号化できることで、最終部分６００が組み込まれたチャンク８００全体にＨＬＳパディングバイト８０４が含まれ、暗号化されたチャンク８０６として使用できるようになる。

別の状況および実施形態、あるいは状況または実施形態においては、ペイロード６０８の最終部分６００が１以上のパディングバイトを含んでおらず、代わりに、メディア・コンテンツからのバイトを排他的に備えている場合には、処理ブロック３０２が、メディアプレーヤ３１２が希望する形式のパディングバイトを排他的に備えた追加部分６００をペイロード６０８の最後に付加することができる。非限定的な例では、処理ブロック３０２は、最終部分６００の解読後に、ＤＴＣＰフレームのペイロード６０８のこの最終部分６００がパディングバイトを全く含んでいないことを発見した場合には、メディアプレーヤ３１２が希望する形式の１６パディングバイトを含んだエキストラ部分６００を最終部分６００の後に付加することができ、最終部分６００を含むチャンク８００が、排他的なパディングバイトである新たな最終部分６００を有するようにすることができる。

工程７０６では、ＨＬＳパディングバイト８０４を含んでいる暗号化されたチャンク８０６は、メディア・プロキシサーバ３０８に記憶される。
工程７０８では、暗号化されたチャンク８０６を記述するプレイリスト５０４を処理ブロック３０２が生成し、これをメディア・プロキシサーバ３０８に記憶することができる。プレイリスト５０４は、暗号化された各チャンク８０６の第１部分６００についてのＩＶ６０２を含んだキータグ定義を含むことができ、これにより、暗号化されたチャンク８０６の最初の部分６００の一部を後にそのＩＶ６０２で解読できるようになる。導出された、ＤＴＣＰフレーム６０４からの最初に暗号化されたチャンク８０６の第１部分６００についてのＩＶ６０２は、ＤＴＣＰフレームのヘッダ６０６、およびＤＴＣＰキー２１２から入手でき、一方、別の暗号化されたチャンク８０６の第１部分６００についてのＩＶ６０２は、ＤＴＣＰフレーム６０４から発生する前のＤＴＣＰフレーム６０４内の部分６００の手前に存在する部分６００を調べることで入手できる。工程４１０で説明したように、プレイリスト５０４はローリング．ｍ３ｕ８プレイリスト、または任意の他のタイプのプレイリストであってもよい。

同様に、上述したように、プレイリスト５０４は、暗号化されたチャンク８０６の経過時間を記述するＥＸＴ−ＩＮＦ値も含むことができる。いくつかの状況および実施形態、あるいは状況または実施形態においては、暗号化されたトランスポート・ストリーム２１４が固定のビットレートを有することが、処理以前に予めわかっている場合には、ＥＸＴ−ＩＮＦ値を選ぶことができ、また、ＤＴＣＰフレーム６０４からのデータのビット数をカウントすることにより、チャンク境界を決定することができる。

処理前にトランスポート・ストリームのビットレートが不明である、またはビットレー
トが可変である代替の状況および実施形態、あるいは状況もしくは実施形態においては、トランスポート・ストリーム２１４の最初において選択された部分６００または完全なＤＴＣＰフレーム６０４を解読することができ、解読された部分の平均ビットレートを決定することができる。この平均ビットレート、および選ばれた秒単位のチャンクサイズ（プレイリスト５０４のＥＸＴ−ＩＮＦ値）を使用して、ＤＴＣＰフレームをチャンクに分割することができる。非限定的な例では、暗号化されたトランスポート・ストリーム２１４の最初の１０秒間を解読し、この最初の１０秒間の平均ビットレートを求め、この平均ビットレートを使用して、トランスポート・ストリーム２１４により作成した暗号化された各チャンク８０６に使用するバイト数を推定できる。

適応型ストリーミング状況などの、さらに別の状況および実施形態、あるいは状況または実施形態においては、トランスポート・ストリーム２１４のビットレートを高度に可変的にすることができ、それにより、ストリームのビットレートが予め不明であっても、および／または、トランスポート・ストリーム２１４の最初についての平均ビットレートの推定が、トランスポート・ストリームの残り部分について同様でなくてもよくなる。これらの状況においては、ソース・デバイス１００からのトランスポート・ストリーム２１４のトランスコーディングおよびストリーミングが、実質的にプッシュモデルにて動作でき、この場合、ソース・デバイス１００が、メディア・コンテンツがソース・デバイス１００に受信されると実質的にリアルタイムでトランスポート・ストリーム２１４をトランスコードし、２次デバイス１０２へ送信する。これらの状況では、ＤＴＣＰフレーム６０４内の、コンテンツで構成された各チャンクに使用するバイト数をその受信時に推定するために、チャンク境界を、リアルタイム・クロックと、選ばれた秒単位でのチャンクサイズ（プレイリスト５０４におけるＥＸＴ−ＩＮＦ値）とを使用して決定できる。

工程７１０では、メディアプレーヤ３１２はメディア・コンテンツを再生することができる。図４の再生工程と同様に、暗号化されたチャンク８０６とプレイリスト５０４とをメディア・プロキシサーバ３０８から取り出し、ＤＴＣＰキー２１２をセキュリティ・プロキシサーバ３１０から取り出すことができる。メディアプレーヤ３１２は、暗号化されたチャンク８０６の各部分６００を解読するため、および、解読されたメディア・コンテンツを再生するために、ＤＴＣＰキー２１２およびＩＶ６０２を使用できる。

上述したように、多くの状況において、ＤＴＣＰフレーム６０４は、暗号化されたチャンク８０６に役立つ長さよりも長くすることができ、１つのＤＴＣＰフレーム６０４はチャンク８００に分割でき、さらに、チャンク８００の最後にＨＬＳパディングバイト８０４を追加する、またはこれに置き換えることにより、メディアプレーヤ３１２で再生可能な暗号化されたチャンク８０６を形成することができる。他の状況においては、特定のＤＴＣＰフレーム６０４は、所望サイズの暗号化されたチャンク８０６よりも小さくてもよい。非限定的な例では、１５００バイトのＤＴＣＰフレーム６０４は、所望サイズの暗号化されたチャンク８０６よりも小さくてもよい。これらの状況では、小さいＤＴＣＰフレーム６０４を次のＤＴＣＰフレーム６０４の最初と組合せることができる。個々のＤＴＣＰフレーム６０４のそれぞれがその最終部分６００内にＤＴＣＰパディングバイト８０２を設けることができるため、一実施形態においては、ＤＴＣＰフレーム６０４を組合せて１つの暗号化されたチャンク８０６にする前に、各ＤＴＣＰフレーム６０４を解読し、ＤＴＣＰパディングバイト８０２を（第１フレームから）除去する、あるいは代替（第２フレームの）パディングバイト８０４に置き換えることが可能である。

いくつかの代替実施形態においては、図４の処理の要素を図７からの処理で補足することで、チャンク５０２が暗号化されたチャンク５０８に再暗号化されないよう防止し、代わりに、ＤＴＣＰフレーム６０４を暗号化されたチャンク８０６に分割することができ、これにより、いくつかの状況においては２次デバイス１０２の処理ロードを減少させるこ
とができる。一実施形態においては、入力されるトランスポート・ストリーム２１４を、工程４０６で説明したとおりに解読して、クリア・トランスポート・ストリーム５００を形成することが可能である。このクリア・トランスポート・ストリーム５００を、そのＰＣＲまたはその他のフィールドについて調べることにより、たとえば、クリア・トランスポート・ストリーム５００内の各ＰＣＲ同士間の時間の長さに従った、各チャンク５０２の適切な持続時間を決定できる。この時間の長さを、プレイリスト５０４内のＥＸＴ−ＩＮＦ値として使用できる。しかしながら、これらの実施形態では、クリア・トランスポート・ストリーム５００のチャンク化および再暗号化を回避し、代わりに、図７に示した処理により、受信したＤＴＣＰフレーム６０４を暗号化されたチャンク８０６に直接変換することができる。非限定的な例では、ＰＣＲを見出すために、また、各チャンクの適切な持続時間（ＥＸＴ−ＩＮＦ値）を決定するために、トランスポート・ストリーム２１４を解読してクリア・トランスポート・ストリーム５００にすることができるが、これらの実施形態では、チャンク５０２を作成および暗号化せず、代わりに、図７の処理を使用して、ＤＴＣＰフレーム６０４をチャンク８００に分割し、パディングバイトを追加するかまたはこれに置き換えることにより、暗号化されたチャンク８０６を作成する。この暗号化されたチャンク８０６は、メディアプレーヤ３１２で再生できる。

いくつかの状況においては、２次デバイス１０２のユーザは、一時停止、巻き戻し、早送り、メディア・コンテンツ内の特定の時点の検索、異なる速度での再生要求、または別のオペレーションの任意の要求、を行う命令をソース・デバイス１００に出すことができる。非限定的な例では、メディアプレーヤ３１２はグラフィカル・ユーザ・インターフェースをユーザに提示でき、ユーザはこのＧＵＩを使用して、メディア・コンテンツの再生に関するコマンドを入力できる。メディアプレーヤ３１２がこれらの命令をクライアント・アプリケーション３１４へ送ると、クライアント・アプリケーション３１４が、要求されたオペレーションをソース・デバイス１００に、たとえばＤＮＬＡヘッダまたはアクションを通じて通知することができる。これらのケースでは、ソース・デバイス１００は、トランスポート・ストリーム２１４内の特定の点を見出すことができるように、指定された不連続点を設けたトランスポート・ストリーム２１４を生成することができる。一実施形態においては、トランスポート・ストリーム２１４内のＤＮＬＡシグナリング層は、ソース・デバイス１００が送信を一時停止した、トランスポート・ストリーム２１４の送信をバッファリング中である、または、トランスポート・ストリーム２１４が、続行中の録画の完全な一部ではなく完全な録画を送信中であることを示すことができる。ソース・デバイス１００は、トランスポート・ストリーム２１４の生成を継続し、これを、メディア・コンテンツ内の要求された位置、再生速度、または任意の他の属性にて、２次デバイス１０２へ転送することにより、２次デバイス１０２はトランスポート・ストリーム２１４の受信および処理を継続する。

非限定的な例では、ユーザが、メディア・コンテンツを３０秒間巻き戻すコマンドをメディアプレーヤ３１２に入力すると、このコマンドがソース・デバイス１００へ送られる。次に、ソース・デバイス１００が、トランスポート・ストリーム２１４内の３０秒前の不連続点に戻し、この不連続点からのトランスポート・ストリーム２１４を２次デバイスへ送ることができる。２次デバイス１０２は、受信したトランスポート・ストリーム２１４を上述したとおりに処理することにより、暗号化されたチャンク５０８とプレイリスト５０４が、メディア・コンテンツ内の新たな位置から、あたかもライブストリームであるかのようにメディアプレーヤ３１２へ送達される。

一実施形態においては、トランスポート・ストリーム２１４全体を、ソース・デバイス１００から、２次デバイス１０２の記憶メモリに送達またはロードすることができる。非限定的な例では、ソース・デバイス１００に録画中のメディアを、２次デバイス１０２内のハードドライブまたはメモリカードにダウンロードできる。これらの実施形態において
は、トランスポート・ストリーム２１４をソース・デバイス１００からデータネットワーク上でリアルタイムでストリーミングする代わりに、ダウンロードしたトランスポート・ストリーム２１４をローカルで２次デバイス１０２上において再生することが可能である。

これらのケースでは、２次デバイス１０２内のローカルストレージ上にロードされたトランスポート・ストリーム２１４は、上述した工程によってローカル・メディアプレーヤ３１２が希望する形式に変換された場合を除き、ローカル・メディアプレーヤ３１２と互換していなくてもよい。非限定的な例では、ＤＴＣＰ−ＩＰストリームはＨＬＳストリームと互換性がなくてもよいが、ＤＴＣＰ−ＩＰストリームを上述した処理（たとえば、図４および図７、あるいは図４または図７の処理）で処理し、ＨＬＳメディアプレーヤ３１２と互換させることが可能である。

しかしながら、トランスポート・ストリーム２１４を、たとえばＤＮＬＡ ｈｔｔｐ ＧＥＴコマンドによって、メディア・コンテンツのリアルタイム再生よりも高速で２次デバイス１０２上にロードすることができる。これらの実施形態においては、暗号化されたトランスポート・ストリーム２１４を、２次デバイスのローカルストレージに予め記憶しておき、再生中に、上述した処理を実行することができる。あるいは、ＣＰＵサイクルが利用可能な場合に背景において、ローカルに記憶された暗号化済みのトランスポート・ストリーム２１４を、メディアプレーヤ３１２で再生可能な形式に変換することができる。これらの実施形態においては、２次デバイス１０２は、一連の暗号化されたチャンク５０８を生成するために、記憶されたトランスポート・ストリーム２１４を処理することができる。一実施形態においては、一連の暗号化されたチャンク５０８を、メディア・プロキシサーバ３０８上の１つの．ｔｓトランスポートファイル、またはローカル・ストレージ・デバイスに記憶でき、全ての暗号化されたチャンク５０８を含んでいる．ｔｓトランスポートファイル内における暗号化された各チャンク５０８のロケーションを記述した１つのプレイリスト５０４を、メディア・プロキシサーバ３０８上に生成することができる。非限定的な例では、プレイリスト５０４は、再生終了を示すＥＮＤ＿ＴＡＧを含んだメディア・コンテンツの総持続時間を表すことができ、また、プレイリスト５０４は、１つの．ｔｓトランスポートファイル内における暗号化された各チャンク５０８のロケーションを示したＢＹＴＥ＿ＯＦＦＳＥＴパラメータを含むことができる。

これらの実施形態のいくつかにおいては、１以上のチャンクキー５０６またはＤＴＣＰキー２１２、および／または関連付けされた認証、出力制御ビット、権利情報、または任意の他の情報を、暗号化されたチャンク５０８を含んだ．ｔｓトランスポートファイルと同じローカル・ストレージ・デバイスまたはメモリカードに記憶できる。

本発明を特定の実施形態と併せて説明したが、当業者には多くの代替、修正、応用が明白となることが明らかである。したがって、説明され、以下に請求される本発明は、添付の請求項の趣旨または広義な範囲に入るこうした代替、修正、応用を全て包括するものである。

Claims (13)

1. ＤＴＣＰ−ＩＰトランスポート・ストリームをＨＬＳ形式に変換する処理方法であって、
   ２次デバイスにおいて、暗号化されたＤＴＣＰ−ＩＰトランスポート・ストリームをソース・デバイスから受信する工程であって、暗号化された前記ＤＴＣＰ−ＩＰトランスポート・ストリームは、複数のＤＴＣＰフレームを備え、前記複数のＤＴＣＰフレームの各々は複数の暗号化された１６バイト部分を備える、工程と、
   ＤＴＣＰフレームの複数の暗号化された１６バイト部分の１以上を１つのチャンクにグループ化することによって、前記複数のＤＴＣＰフレームの１つからチャンクを形成する工程と、
   前記チャンクの最後にＨＬＳパディングバイトを追加して、前記ＨＬＳパディングバイトを暗号化する工程であって、前記チャンクと暗号化された前記ＨＬＳパディングバイトとが暗号化されたチャンクを形成している、工程と、
   暗号化された前記チャンクの各々と暗号化された前記チャンクのプレイリストとを、前記２次デバイスにおけるメディア・プロキシサーバにロードする工程と、
   ＤＴＣＰキーを前記２次デバイスにおけるセキュリティ・プロキシサーバ上にロードする工程であって、前記ＤＴＣＰキーは、前記ソース・デバイスから入手されている、工程と、
   前記プレイリスト、暗号化された前記チャンクの各々、および前記ＤＴＣＰキーを、前記２次デバイス上に元々実装されているメディアプレーヤに提供する工程であって、元々実装されている前記メディアプレーヤは、前記プレイリストに従って、前記ＤＴＣＰキーを使用して、暗号化された前記チャンクを解読して、前記チャンクを再生する、工程と、を備える、処理方法。
2. 前記チャンクの１つは、前記複数のＤＴＣＰフレームの１つからの１６バイトの最終部分を含み、前記処理方法はさらに、
   前記１６バイトの最終部分を解読する工程と、
   前記１６バイトの最終部分内のＤＴＣＰパディングバイトをＨＬＳパディングバイトに置き換える工程と、
   前記１６バイトの最終部分を再暗号化して、暗号化された前記チャンクの１つを形成する工程と、を備える、請求項１に記載の処理方法。
3. 前記プレイリストは、暗号化された各チャンクの時間の長さを記述する値を含む、請求項１に記載の処理方法。
4. 前記時間の長さは、
   クリア・トランスポート・ストリームを形成するように、暗号化された前記ＤＴＣＰ−ＩＰトランスポート・ストリームのいくつかまたは全てを解読する工程と、
   前記クリア・トランスポート・ストリーム内にＰＣＲを見出す工程と、
   少なくとも部分的に前記クリア・トランスポート・ストリーム内のＰＣＲ同士間の時間の長さによって、前記時間の長さを決定する工程と、によって決定される、請求項３に記載の処理方法。
5. 前記クリア・トランスポートは固定のビットレートを有し、前記時間の長さは、各チャンクのビット数によって決定され、前記ビット数は、前記固定のビットレートからのビットをカウントすることによって見出される、請求項４に記載の処理方法。
6. 前記クリア・トランスポート・ストリームは可変のビットレートを有し、前記時間の長さは、各チャンクのビット数によって決定され、前記ビット数は、平均ビットレートから
   のビットをカウントすることによって、前記クリア・トランスポート・ストリームの前記平均ビットレートから見出される、請求項４に記載の処理方法。
7. 前記時間の長さは、暗号化された前記ＤＴＣＰ−ＩＰトランスポート・ストリームを、事前に選択された時間間隔における前記チャンクに分割するように、クロックを使用して決定される、請求項４に記載の処理方法。
8. 暗号化された前記ＤＴＣＰ−ＩＰトランスポート・ストリームは、前記２次デバイスから前記ソース・デバイスに提出されたユーザメディア制御命令に応答して、前記ソース・デバイスから、或る速度で、または暗号化された前記ＤＴＣＰ−ＩＰトランスポート・ストリーム内の時点において、前記２次デバイスにおいて受信される、請求項１に記載の処理方法。
9. 異なる１６バイト部分を見出すことによって、前記チャンクの初期化ベクトルを見出す工程であって、前記異なる１６バイト部分は、前記ＤＴＣＰフレーム内の前記チャンク内の第１部分として使用されている前記１６バイト部分の直前に存在する、工程と、
   前記異なる１６バイト部分を前記チャンクの前記初期化ベクトルとして使用する工程と、をさらに備える、請求項１に記載の処理方法。
10. 前記プレイリスト内に前記チャンクの前記初期化ベクトルを含める工程をさらに備える、請求項９に記載の処理方法。
11. 暗号化された前記ＤＴＣＰ−ＩＰトランスポート・ストリームは、前記２次デバイスから前記ソース・デバイスに提出されたユーザメディア制御命令に応答して、前記ソース・デバイスから、或る速度で、または暗号化された前記ＤＴＣＰ−ＩＰトランスポート・ストリーム内の時点において、前記２次デバイスにおいて受信される、請求項１に記載の処理方法。
12. 暗号化された前記ＤＴＣＰ−ＩＰトランスポート・ストリーム自体の全体を、前記２次デバイス内のローカルストレージにおいて受信および記憶する工程と、後の或る時間において再生する要求があった場合にのみ、前記チャンクを形成する工程と、をさらに備える、請求項１に記載の処理方法。
13. ＤＴＣＰ−ＩＰトランスポート・ストリームをＨＬＳ形式に変換する処理方法であって、
    暗号化されたＤＴＣＰ−ＩＰトランスポート・ストリームを、２次デバイスにおいてソース・デバイスから受信する工程と、
    前記２次デバイスにおいて、暗号化された前記ＤＴＣＰ−ＩＰトランスポート・ストリームを、ＤＴＣＰキーを使用してクリア・トランスポート・ストリームに解読する工程と、
    前記２次デバイスにおいて、前記クリア・トランスポート・ストリームを複数のチャンクに分割する工程と、
    前記２次デバイスにおいて、前記複数のチャンクのプレイリストを生成する工程と、
    前記２次デバイスにおいて、チャンクキーを使用して、前記複数のチャンクの各々を暗号化されたチャンクに暗号化する工程と、
    前記プレイリストと暗号化された前記チャンクの各々とを、前記２次デバイスにおけるメディア・プロキシサーバ上に記憶する工程と、
    前記チャンクキーを、前記２次デバイスにおけるセキュリティ・プロキシサーバ上に記憶する工程と、
    前記プレイリスト、暗号化された前記チャンクの各々、および前記チャンクキーを、前
    記２次デバイス上に元々実装されているメディアプレーヤに提供する工程であって、元々実装されている前記メディアプレーヤは、前記プレイリストに従って、前記チャンクキーを使用して暗号化された前記チャンクを前記チャンクへと解読して、前記チャンクを再生する、工程と、を備える、処理方法。