(57)【要約】【課題】移動可能な世代を所定の数に制限することでコンテンツの流通範囲を制限しながら、他の装置へコンテンツを移動する。【解決手段】ＳｏｕｒｃｅデバイスとＳｉｎｋデバイスの間で、コンテンツ移動の制御情報として、移動回数の情報Ｍｏｖｅ−ｃｏｕｎｔを伝え、ＳｉｎｋデバイスはＭｏｖｅ−ｃｏｕｎｔを１だけデクリメントして受信したコンテンツを管理するようにする。Ｍｏｖｅ−ｃｏｕｎｔがまだ１以上であれば、Ｓｉｎｋデバイスは、それを次の制御情報としてコンテンツのさらなる移動が可能である。一方、Ｍｏｖｅ−ｃｏｕｎｔが０になると、さらなる移動はできない。【選択図】  図１
2015014979.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツ記録部に記録されたコンテンツを移動に関する制御情報付きで送信するとともに、送信済みのコンテンツを前記コンテンツ記録部から削除して、コンテンツの移動を実施するコンテンツ送信装置と、
前記コンテンツ送信装置から送信されたコンテンツを受信するコンテンツ受信装置と、
を具備するコンテンツ伝送システム。
【請求項２】
前記移動に関する制御情報は、コンテンツの移動の世代制限に関する情報を含む、
請求項１に記載のコンテンツ伝送システム。
【請求項３】
前記移動に関する制御情報は、コンテンツの世代制限付き移動の可否に関する情報を含む、
請求項１に記載のコンテンツ伝送システム。
【請求項４】
前記移動に関する制御情報は、移動可能な世代数に関する情報をさらに含む、
請求項３に記載のコンテンツ伝送システム。
【請求項５】
前記コンテンツ送信装置及び前記コンテンツ受信装置は、所定の伝送規格に従って相互認証及び共有鍵の交換を行ない、前記共有鍵から計算される暗号鍵を用いて暗号化したコンテンツの移動を実施する、
請求項１に記載のコンテンツ伝送システム。
【請求項６】
前記所定の伝送規格は、ＤＴＣＰ（Ｄｉｇｉｔａｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ）若しくはＤＴＣＰ−ＩＰ（ＤＴＣＰ  ｍａｐｐｉｎｇ  ｔｏ  ＩＰ）である、
請求項５に記載のコンテンツ伝送システム。
【請求項７】
前記コンテンツ送信装置は、ＤＴＣＰ−ＩＰ規格に従ってＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）メッセージにより前記コンテンツ受信装置へコンテンツを伝送する際に、Ｅ−ＥＭＩ（Ｅｘｔｅｎｄｅｄ  Ｅｎｃｒｉｐｔｉｏｎ  Ｍｏｄｅ  Ｉｎｄｉｃａｔｏｒ）に「世代制限付き移動可」を意味する値を付加して、当該コンテンツの世代制限付き移動の可否に関する情報を通知し、
前記コンテンツ受信装置は、前記コンテンツ送信装置からコンテンツを受信する際に、Ｅ−ＥＭＩの値に基づいて当該コンテンツが世代制限付き移動可か否かをチェックする、
請求項３に記載のコンテンツ伝送システム。
【請求項８】
前記コンテンツ送信装置は、ＤＴＣＰ＿ｄｅｓｃｒｉｐｔｏｒのＭｏｖｅ＿ｃｏｕｎｔフィールドに移動可能な世代数を記載して、移動可能な世代数に関する情報をさらに通知する、
請求項７に記載のコンテンツ伝送システム。
【請求項９】
前記コンテンツ送信装置は、ＰＣＰ−ＵＲ（Ｐｒｏｔｅｃｔｅｄ  Ｃｏｎｔｅｎｔ  Ｐａｃｋｅｔ−Ｕｓａｇｅ  Ｒｕｌｅ）のＭｏｖｅ＿ｃｏｕｎｔフィールドに移動可能な世代数を記載して、移動可能な世代数に関する情報をさらに通知する、
請求項７に記載のコンテンツ伝送システム。
【請求項１０】
前記コンテンツ送信装置は、ＣＭＩ  ｄｅｓｃｒｉｐｔｏｒのＭｏｖｅ＿ｃｏｕｎｔフィールドに移動可能な世代数を記載して、移動可能な世代数に関する情報をさらに通知する、
請求項７に記載のコンテンツ伝送システム。
【請求項１１】
前記コンテンツ受信装置は、前記コンテンツ送信装置から世代制限付き移動により取得したコンテンツの移動可能な世代数を１だけ減算する、
請求項４、８乃至１０のいずれかに記載のコンテンツ伝送システム。
【請求項１２】
前記コンテンツ受信装置は、前記コンテンツ送信装置から世代制限付き移動により取得したコンテンツについての移動可能な世代数に関する情報を検出できないときは、当該コンテンツの更なる移動を不可にする、
請求項４、８乃至１０のいずれかに記載のコンテンツ伝送システム。
【請求項１３】
前記コンテンツ受信装置は、更なる移動が不可のコンテンツを次にＤＴＣＰ−ＩＰで送信する際には、そのＥ−ＥＭＩに記録の禁止を意味する値を用いる、
請求項７に記載のコンテンツ伝送システム。
【請求項１４】
前記コンテンツ受信装置は、記録禁止で且つ１以上の移動可能な世代数が付与されたコンテンツについては、移動可能な世代数に拘らず、記録を不可にする、
請求項４に記載のコンテンツ伝送システム。
【請求項１５】
前記コンテンツ送信装置は、コンテンツの移動を要求した前記コンテンツ受信装置が世代制限付きのコンテンツ移動に対応しているか否かを確認した後に、コンテンツの世代制限付き移動を行なう、
請求項１に記載のコンテンツ伝送システム。
【請求項１６】
前記コンテンツ受信装置は、ＤＴＣＰ−ＩＰ規格に従ってＨＴＴＰリクエストによりコンテンツの移動を要求する際に、ＢＬＫＭｏｖｅ２．ｄｔｃｐ．ｃｏｍヘッダー・フィールドを用いて、世代制限付きのコンテンツ移動に対応していることを前記コンテンツ送信装置に伝える、
請求項１５に記載のコンテンツ伝送システム。
【請求項１７】
前記コンテンツ受信装置は、ＤＴＣＰ−ＩＰ規格に従ってＭＯＶＥ−ＡＫＥ手続きを開始するコマンドＭＶ＿ＩＮＩＴＩＡＴＥを世代制限付きで移動できることを示すＭＶ＿ＩＮＩＴＩＡＴＥ２に代えることにより、世代制限付きのコンテンツ移動に対応していることを前記コンテンツ送信装置に伝える、
請求項１５に記載のコンテンツ伝送システム。
【請求項１８】
前記コンテンツ受信装置は、移動可能な世代数を１だけ減算した結果世代数が０になったコンテンツのリモート・アクセスによる送信を不可にする、
請求項１１に記載のコンテンツ伝送システム。
【請求項１９】
前記コンテンツ受信装置は、移動可能な世代数を検出できない場合にコンテンツのリモート・アクセスによる送信を不可にする、
請求項１１に記載のコンテンツ伝送システム。
【請求項２０】
前記コンテンツ受信装置は、移動可能な世代数を１だけ減算する際にそのコンテンツが移動済みであることを対応付けて記憶し、移動済みのコンテンツのリモート・アクセスによる送信を不可にする、
請求項１１に記載のコンテンツ伝送システム。
【請求項２１】
前記コンテンツ送信装置及び前記コンテンツ受信装置は、リモート・アクセスによりコンテンツの移動を行なうときには、移動用の共有鍵から計算した暗号鍵に代えて、リモート・アクセスによるコンテンツ移動の処理専用の計算方法で得た暗号鍵を用いて暗号化伝送する、
請求項６に記載のコンテンツ伝送システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書で開示する技術は、装置間でコンテンツを伝送するコンテンツ伝送システムに係り、例えばＤＴＣＰなどの所定の相互認証及び鍵交換（ＡＫＥ）アルゴリズムに従って共有した鍵を用いて、著作権などの権利を保護すべきコンテンツを暗号化伝送するコンテンツ伝送システムに関する。
【背景技術】
【０００２】
ディジタル化されたコンテンツはコピーや改竄などの不正な操作が比較的容易である。ディジタル・コンテンツの伝送保護に関する業界標準的な技術として、ＤＴＬＡ（Ｄｉｇｉｔａｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｌｉｃｅｎｓｉｎｇ  Ａｄｍｉｎｉｓｔｒａｔｏｒ）が開発したＤＴＣＰ（Ｄｉｇｉｔａｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ）が挙げられる。
【０００３】
ＤＴＣＰでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決められている。その規定は、要約すれば、ＤＴＣＰ準拠機器は取り扱いが容易な圧縮コンテンツを非暗号の状態で機器外に送出しないことと、暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ａｎｄ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ：ＡＫＥ）アルゴリズムに従って行なうこと、並びにＡＫＥコマンドにより鍵交換を行なう機器の範囲を制限することなどである。
【０００４】
ＤＴＣＰは、原初的には、ＩＥＥＥ１３９４などを伝送路に用いたホーム・ネットワーク上におけるコンテンツ伝送について規定したものである。最近では、ＤＬＮＡ（Ｄｉｇｉｔａｌ  Ｌｉｖｉｎｇ  Ｎｅｔｗｏｒｋ  Ａｌｌｉａｎｃｅ）に代表されるように、家庭内でもディジタル・コンテンツをＩＰネットワーク経由で流通させようという動きが本格的になっている。そこで、ＤＴＣＰ技術をＩＰネットワークに移植した、ＤＴＣＰ−ＩＰ（ＤＴＣＰ  ｍａｐｐｉｎｇ  ｔｏ  ＩＰ）の開発が進められている。
【０００５】
例えば、ホーム・サーバーに蓄積された放送コンテンツや映画などの商用コンテンツを、家庭内で利用する場合はもちろんのこと、外出先から遠隔利用（リモート・アクセス）する場合でも、私的利用の範囲を超えて利用されることを、ＤＴＣＰ若しくはＤＴＣＰ−ＩＰの適切に制御によって防止することが望まれている。
【０００６】
リモート・アクセスによりコンテンツを再生する方法（例えば、ホーム・サーバーに蓄積されている動画像などのコンテンツを、家庭内の再生装置や外出先に携行している多機能端末（スマートフォン）で再生する場合）として、ストリーミングとダウンロード再生の２通りが挙げられる。ストリーミングは、再生した後はＳｉｎｋデバイスのコンテンツ本体が残らないので、コンテンツが無制限に流通する可能性は極めて低い。これに対し、ダウンロード再生の場合、ダウンロードした後のコンテンツの流通を制御する必要が生じる。例えば、リモート・アクセスによるダウンロード再生をすべて禁止にするという対策も考えられる。しかしながら、通信ができない環境（飛行機の中など）でコンテンツを利用する場合や、通信帯域が十分確保できない（回線が不安定な）環境（電車で移動中など）で高品質なコンテンツを再生するためには、ダウンロード再生が必要である。
【０００７】
ここで、ＤＴＣＰ仕様においてコンテンツをダウンロード再生する方法には、「コピー」と「移動」の２通りがある。
【０００８】
コピーを繰り返すと利用可能なコンテンツの数が増えてしまう。このため、ＤＴＣＰでは、コピーできる世代数を制限するなどのコピー制御を規定している。Ｓｏｕｒｃｅデバイスは、コピー禁止と設定されたコンテンツのコピーを実行せず、また、コピーが許容されたコンテンツを伝送時には、そのコピー属性（１世代コピー可能、再コピー不可、コピー自由など）を示したコピー制御情報を、伝送パケットのヘッダーやペイロード内に埋め込む。また、Ｓｉｎｋデバイス側では、ダウンロードしたコンテンツを、指定されたコピー属性に従ってコピー制御を行なう。
【０００９】
一方、「移動（Ｍｏｖｅ）」は、ＳｏｕｒｃｅデバイスからＳｉｎｋデバイスへコンテンツを送信すると、Ｓｏｕｒｃｅデバイス側では送信済みのコンテンツを消去する仕組みとなっている（例えば、特許文献１を参照のこと）。すなわち、移動は、移動元と移動先でのコンテンツの同時存在を禁止し、デバイス間でコンテンツの移動を繰り返しても利用可能なコンテンツの数は増えない。
【００１０】
しかしながら、デバイスの利用者を限定しない以上、コンテンツがさまざまな所有者のデバイスを次々と移動する可能性がある。また、リモート・アクセスでの移動により、コンテンツの流通範囲は無限となる。コンテンツの移動機能に対応したデバイスの普及が進むと、その可能性は高まる。したがって、上記のようにコンテンツの移動に制限が課されない状況下では、不正なコンテンツ利用の機会が増えることが懸念される。このような理由により、コンテンツ提供業者が、今後、コンテンツの移動に制限を課していない方式へのコンテンツの提供を躊躇し抑制してくることも考えられる。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
本明細書で開示する技術の目的は、コンテンツの流通範囲を制限しながら、他の装置からコンテンツを好適に伝送することができる、優れたコンテンツ伝送システムを提供することにある。
【００１２】
本明細書で開示する技術のさらなる目的は、ＤＴＣＰ規格に従って共有した鍵を用いて、著作権などの権利を保護すべきコンテンツを、その流通範囲を制限しながら好適に伝送することができる、優れたコンテンツ伝送システムを提供することにある。
【課題を解決するための手段】
【００１３】
本願は、上記課題を参酌してなされたものであり、請求項１に記載の技術は、
コンテンツ記録部に記録されたコンテンツを移動に関する制御情報付きで送信するとともに、送信済みのコンテンツを前記コンテンツ記録部から削除して、コンテンツの移動を実施するコンテンツ送信装置と、
前記コンテンツ送信装置から送信されたコンテンツを受信するコンテンツ受信装置と、
を具備するコンテンツ伝送システムである。
【００１４】
但し、ここで言う「システム」とは、複数の装置（又は特定の機能を実現する機能モジュール）が論理的に集合した物のことを言い、各装置や機能モジュールが単一の筐体内にあるか否かは特に問わない。
【００１５】
本願の請求項２に記載の技術によれば、請求項１に記載のコンテンツ伝送システムにおいて、前記移動に関する制御情報は、コンテンツの移動の世代制限に関する情報を含んでいる。
【００１６】
本願の請求項３に記載の技術によれば、請求項１に記載のコンテンツ伝送システムにおいて、前記移動に関する制御情報は、コンテンツの世代制限付き移動の可否に関する情報を含んでいる。
【００１７】
本願の請求項４に記載の技術によれば、請求項３に記載のコンテンツ伝送システムにおいて、前記移動に関する制御情報は、移動可能な世代数に関する情報をさらに含んでいる。
【００１８】
本願の請求項５に記載の技術によれば、請求項１に記載のコンテンツ伝送システムにおいて、前記コンテンツ送信装置及び前記コンテンツ受信装置は、所定の伝送規格に従って相互認証及び共有鍵の交換を行ない、前記共有鍵から計算される暗号鍵を用いて暗号化したコンテンツの移動を実施するように構成されている。
【００１９】
本願の請求項６に記載の技術によれば、請求項５に記載のコンテンツ伝送システムにおいて、前記所定の伝送規格は、ＤＴＣＰ（Ｄｉｇｉｔａｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ）若しくはＤＴＣＰ−ＩＰ（ＤＴＣＰ  ｍａｐｐｉｎｇ  ｔｏ  ＩＰ）である。
【００２０】
本願の請求項７に記載の技術によれば、請求項３に記載のコンテンツ伝送システムにおいて、前記コンテンツ送信装置は、ＤＴＣＰ−ＩＰ規格に従ってＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）メッセージにより前記コンテンツ受信装置へコンテンツを伝送する際に、Ｅ−ＥＭＩ（Ｅｘｔｅｎｄｅｄ  Ｅｎｃｒｉｐｔｉｏｎ  Ｍｏｄｅ  Ｉｎｄｉｃａｔｏｒ）に「世代制限付き移動可」を意味する値を付加して、当該コンテンツの世代制限付き移動の可否に関する情報を通知し、前記コンテンツ受信装置は、前記コンテンツ送信装置からコンテンツを受信する際に、Ｅ−ＥＭＩの値に基づいて当該コンテンツが世代制限付き移動可か否かをチェックするように構成されている。
【００２１】
本願の請求項８に記載の技術によれば、請求項７に記載のコンテンツ伝送システムにおいて、前記コンテンツ送信装置は、ＤＴＣＰ＿ｄｅｓｃｒｉｐｔｏｒのＭｏｖｅ＿ｃｏｕｎｔフィールドに移動可能な世代数を記載して、移動可能な世代数に関する情報をさらに通知するように構成されている。
【００２２】
本願の請求項９に記載の技術によれば、請求項７に記載のコンテンツ伝送システムにおいて、前記コンテンツ送信装置は、ＰＣＰ−ＵＲ（Ｐｒｏｔｅｃｔｅｄ  Ｃｏｎｔｅｎｔ  Ｐａｃｋｅｔ−Ｕｓａｇｅ  Ｒｕｌｅ）のＭｏｖｅ＿ｃｏｕｎｔフィールドに移動可能な世代数を記載して、移動可能な世代数に関する情報をさらに通知するように構成されている。
【００２３】
本願の請求項１０に記載の技術によれば、請求項７に記載のコンテンツ伝送システムにおいて、前記コンテンツ送信装置は、ＣＭＩ  ｄｅｓｃｒｉｐｔｏｒのＭｏｖｅ＿ｃｏｕｎｔフィールドに移動可能な世代数を記載して、移動可能な世代数に関する情報をさらに通知するように構成されている。
【００２４】
本願の請求項１１に記載の技術によれば、請求項４、８乃至１０のいずれかに記載のコンテンツ伝送システムにおいて、前記コンテンツ受信装置は、前記コンテンツ送信装置から世代制限付き移動により取得したコンテンツの移動可能な世代数を１だけ減算するように構成されている。
【００２５】
本願の請求項１２に記載の技術によれば、請求項４、８乃至１０のいずれかに記載のコンテンツ伝送システムにおいて、前記コンテンツ受信装置は、前記コンテンツ送信装置から世代制限付き移動により取得したコンテンツについての移動可能な世代数に関する情報を検出できないときは、当該コンテンツの更なる移動を不可にするように構成されている。
【００２６】
本願の請求項１３に記載の技術によれば、請求項７に記載のコンテンツ伝送システムにおいて、前記コンテンツ受信装置は、更なる移動が不可のコンテンツを次にＤＴＣＰ−ＩＰで送信する際には、そのＥ−ＥＭＩに記録の禁止を意味する値を用いるように構成されている。
【００２７】
本願の請求項１４に記載の技術によれば、請求項４に記載のコンテンツ伝送システムにおいて、前記コンテンツ受信装置は、記録禁止で且つ１以上の移動可能な世代数が付与されたコンテンツについては、移動可能な世代数に拘らず、記録を不可にするように構成されている。
【００２８】
本願の請求項１５に記載の技術によれば、請求項１に記載のコンテンツ伝送システムにおいて、前記コンテンツ送信装置は、コンテンツの移動を要求した前記コンテンツ受信装置が世代制限付きのコンテンツ移動に対応しているか否かを確認した後に、コンテンツの世代制限付き移動を行なうように構成されている。
【００２９】
本願の請求項１６に記載の技術によれば、請求項１５に記載のコンテンツ伝送システムにおいて、前記コンテンツ受信装置は、ＤＴＣＰ−ＩＰ規格に従ってＨＴＴＰリクエストによりコンテンツの移動を要求する際に、ＢＬＫＭｏｖｅ２．ｄｔｃｐ．ｃｏｍヘッダー・フィールドを用いて、世代制限付きのコンテンツ移動に対応していることを前記コンテンツ送信装置に伝えるように構成されている。
【００３０】
本願の請求項１７に記載の技術によれば、請求項１５に記載のコンテンツ伝送システムにおいて、前記コンテンツ受信装置は、ＤＴＣＰ−ＩＰ規格に従ってＭＯＶＥ−ＡＫＥ手続きを開始するコマンドＭＶ＿ＩＮＩＴＩＡＴＥを世代制限付きで移動できることを示すＭＶ＿ＩＮＩＴＩＡＴＥ２に代えることにより、世代制限付きのコンテンツ移動に対応していることを前記コンテンツ送信装置に伝えるように構成されている。
【００３１】
本願の請求項１８に記載の技術によれば、請求項１１に記載のコンテンツ伝送システムにおいて、前記コンテンツ受信装置は、移動可能な世代数を１だけ減算した結果世代数が０になったコンテンツのリモート・アクセスによる送信を不可にするように構成されている。また、本願の請求項１９に記載の技術によれば、前記コンテンツ受信装置は、移動可能な世代数を検出できない場合にコンテンツのリモート・アクセスによる送信を不可にするように構成されている。
【００３２】
本願の請求項２０に記載の技術によれば、請求項１１に記載のコンテンツ伝送システムにおいて、前記コンテンツ受信装置は、移動可能な世代数を１だけ減算する際にそのコンテンツが移動済みであることを対応付けて記憶し、移動済みのコンテンツのリモート・アクセスによる送信を不可にするように構成されている。
【００３３】
本願の請求項２１に記載の技術によれば、請求項６に記載のコンテンツ伝送システムにおいて、前記コンテンツ送信装置及び前記コンテンツ受信装置は、リモート・アクセスによりコンテンツの移動を行なうときには、移動用の共有鍵から計算した暗号鍵に代えて、リモート・アクセスによるコンテンツ移動の処理専用の計算方法で得た暗号鍵を用いて暗号化伝送するように構成されている。
【発明の効果】
【００３４】
本明細書で開示する技術によれば、移動可能な世代を所定の数に制限することでコンテンツの流通範囲を制限しながら、他の装置へコンテンツを好適に移動することができる、優れたコンテンツ伝送システムを提供することができる。
【００３５】
また、本明細書で開示する技術によれば、移動可能な世代を所定の数に制限することでコンテンツの流通範囲を制限しながら、ＤＴＣＰ規格に従って、著作権などの権利を保護すべきコンテンツを、他の装置へコンテンツを好適に移動することができる、優れたコンテンツ伝送システムを提供することにある。
【００３６】
本明細書で開示する技術を適用したコンテンツ伝送システムでは、装置間で移動するコンテンツに対して移動可能な世代数を制限することができる。したがって、コンテンツ提供業者は、コンテンツの移動を行なう機器に対しても、躊躇することなくコンテンツを提供することが期待される。コンテンツの移動が許容される結果として、通信ができない環境でもコンテンツを利用できる機会が増え、また、通信の帯域が十分確保できない環境でも高品質なコンテンツ再生を行なうことができる。
【００３７】
なお、本明細書に記載された効果は、あくまでも例示であり、本発明の効果はこれに限定されるものではない。また、本発明が、上記の効果以外に、さらに付加的な効果を奏する場合もある。
【００３８】
本明細書で開示する技術のさらに他の目的、特徴や利点は、後述する実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
【図面の簡単な説明】
【００３９】
【図１】図１は、本明細書で開示する技術を適用したコンテンツ伝送システム１００の構成例を示した図である。
【図２】図２は、本明細書で開示する技術を適用したコンテンツ伝送システム２００の他の構成例を模式的に示した図である。
【図３】図３は、Ｓｏｕｒｃｅデバイスとして動作するコンテンツ送信装置３００の機能的構成を模式的に示した図である。
【図４】図４は、Ｓｉｎｋデバイスとして動作するコンテンツ受信装置４００の機能的構成を模式的に示した図である。
【図５】図５は、コンテンツの移動制御情報をコンテンツ本体と対応付けて管理する仕組みを模式的に示した図である。
【図６】図６は、コンテンツの移動制御情報をコンテンツ本体の一部として管理する仕組みを模式的に示した図である。
【図７】図７は、ＳｏｕｒｃｅデバイスとＳｉｎｋデバイス間でリモート・アクセスによるコンテンツの移動を行なう際の全体的な手順を模式的に示した図である。
【図８】図８は、コンテンツ・リスト閲覧フェーズ（ＳＥＱ７０１）の中身を模式的に示した図である。
【図９】図９は、ＲＡ−ＡＫＥ手続きフェーズ（ＳＥＱ７０２）の中身の詳細を示した図である。
【図１０】図１０は、ＭＯＶＥ−ＡＫＥ手続きフェーズ（ＳＥＱ７０３）の中身を示した図である。
【図１１】図１１は、コンテンツ伝送フェーズ（ＳＥＱ７０４）の中身を模式的に示した図である。
【図１２】図１２は、ＤＴＣＰ−ＩＰにおいてコンテンツ伝送に用いられるパケットＰＣＰのデータ構造を模式的に示した図である。
【図１３】図１３は、ＤＴＣＰ−ＩＰ規格通りのＥ−ＥＭＩを示した図である。
【図１４】図１４は、「０１１１2」を「世代制限付き移動可」と追加定義したＥ−ＥＭＩを示した図である。
【図１５】図１５は、ＤＴＣＰ＿ｄｅｓｃｒｉｐｔｏｒの未使用領域をＭｏｖｅ＿ｃｏｕｎｔフィールドとして定義して、移動可能な世代数を記載した例を示した図である。
【図１６】図１６は、ＰＣＰヘッダー中のノンスＮcのフィールドの構造を示した図である。
【図１７】図１７は、ＰＣＰ−ＵＲの未使用領域１７０１をＭｏｖｅ＿ｃｏｕｎｔフィールドとして定義した例を示した図である。
【図１８】図１８は、ＣＭＩのパケット・フォーマットを示した図である。
【図１９】図１９は、ＣＭＩ  ｄｅｓｃｒｉｐｔｏｒ１フォーマットの未使用領域をＭｏｖｅ＿ｃｏｕｎｔフィールドとして定義した例を示した図である。
【図２０】図２０は、ＣＭＩ  ｄｅｓｃｒｉｐｔｏｒ２フォーマットの未使用領域をＭｏｖｅ＿ｃｏｕｎｔフィールドとして定義した例を示した図である。
【図２１】図２１は、Ｓｉｎｋデバイスにおいて受信したコンテンツの移動世代数を制御するための処理手順を示したフローチャートである。
【図２２】図２２は、Ｓｏｕｒｃｅデバイスが世代制限付きで移動可能なコンテンツを移動するための処理手順を示したフローチャートである。
【図２３】図２３は、Ｓｏｕｒｃｅデバイスが世代制限付き移動可能なコンテンツを移動するための処理手順を示したフローチャートである。
【図２４】図２４は、コンピューター・プログラム配信システム２４００の構成を示した図である。
【発明を実施するための形態】
【００４０】
コンテンツの移動が無制限に行なわれると、その流通範囲は無制限となり、私的利用の範囲を超えてコンテンツが利用されるおそれがある。２０１３年６月時点では、ＤＴＣＰ（ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ）は、コンテンツの移動に関しては、移動可能な世代数などを制限していない。そこで、本明細書で開示する技術では、コンテンツ移動可能な世代数の制限を設けることにより、コンテンツの流通範囲の拡大を抑制するようにしている。以下、図面を参照しながら本明細書で開示する技術の実施形態について詳細に説明する。
【００４１】
図１には、本明細書で開示する技術を適用したコンテンツ伝送システム１００の構成例を模式的に示している。図示のコンテンツ伝送システム１００は、家庭内に敷設されたホーム・ネットワーク１１０上に接続されたサーバー１０１と、端末１０２、端末１０３で構成される。同図では、簡素化のため、１台のサーバーと２台の端末しか描いていないが、２台以上のサーバー、並びに３台以上の端末がホーム・ネットワーク上に設置されることも想定される。
【００４２】
サーバー１０１は、端末１０２に提供するコンテンツを蓄積している。サーバー１０１は、例えば、地上ディジタル放送で受信した放送コンテンツや、ブルーレイ・ディスクなどの記録媒体（図示しない）から読み込んだ映画などの商用コンテンツ、さらにはインターネット上のコンテンツ・サーバー（図示しない）からダウンロードしたコンテンツを蓄積している。また、端末１０２は、サーバー１０１から移動（若しくはコピー）によりダウンロードしたコンテンツを蓄積し、さらに端末１０３に提供することもある。
【００４３】
ホーム・ネットワーク１１０を介したサーバー１０１と端末１０２間、並びに、端末１０２と端末１０３間のコンテンツ伝送には、ＤＴＣＰ技術が適用されている。例えば、コンテンツを利用したい端末１０２は、所定の相互認証及び鍵交換（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ａｎｄ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ：ＡＫＥ）アルゴリズムに従って、サーバー１０１と相互認証するとともに鍵を共有した後に、サーバー１０１内に蓄積されたコンテンツのダウンロードを要求することができる。サーバー１０１は、要求されたコンテンツを、共有した鍵を用いて暗号化伝送する。コンテンツを提供するサーバー１０１はＳｏｕｒｃｅデバイスに相当し、コンテンツを利用する端末１０２はＳｉｎｋデバイスに相当する。端末１０２から端末１０３へコンテンツをダウンロードする場合も同様に、ＡＫＥアルゴリズムに従って相互認証及び鍵の共有を行なった後、コンテンツを暗号化伝送する。この場合は、端末１０２がＳｏｕｒｃｅデバイス、端末１０３がＳｉｎｋデバイスとなる。
【００４４】
また、図２には、本明細書で開示する技術を適用したコンテンツ伝送システム２００の他の構成例を模式的に示している。図示のコンテンツ伝送システム２００は、家庭内に敷設されたホーム・ネットワーク２１０上に接続されたサーバー２０１並びに端末２０２と、インターネットなどの外部ネットワーク２２０上に接続された端末２０３で構成される。ホーム・ネットワーク２１０と外部ネットワーク２２０は、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）プロトコルに従い、ルーター２３０経由で相互接続されている。同図では、簡素化のため、ホーム・ネットワーク２１０上にサーバーと端末をそれぞれ１台ずつしか描いていないが、２台以上のサーバーが設置されることや、ホーム・ネットワーク２１０上にも端末が接続され、さらに外部ネットワーク２２０上に２台以上の端末が接続されることも想定される。
【００４５】
サーバー２０１は、放送コンテンツや商用コンテンツなど、端末２０２に提供するコンテンツを蓄積している。ホーム・ネットワーク２１０を介したサーバー２０１と端末２０２間のコンテンツ伝送には、ＤＴＣＰ技術が適用される（同上）。
【００４６】
また、ホーム・ネットワーク２１０及び外部ネットワーク２２０を介したサーバー２０１と端末２０３間、並びに、端末２０２と端末２０３のコンテンツ伝送には、ＤＴＣＰ−ＩＰ技術が適用されている。したがって、端末２０３は、ホーム・ネットワーク２１０及び外部ネットワーク２２０からなるＩＰネットワーク越しに、サーバー２０１又は端末２０２と相互認証するとともに共有鍵を共有した後に、サーバー２０１又は端末２０２内に蓄積されたコンテンツを要求することができる。サーバー２０１又は端末２０２は、要求されたコンテンツを、共有した共有鍵を用いて暗号化伝送する。コンテンツを提供するサーバー２０１又は端末２０２はＳｏｕｒｃｅデバイスに相当し、コンテンツを利用する端末２０３はＳｉｎｋデバイスに相当する。
【００４７】
図３には、Ｓｏｕｒｃｅデバイスとして動作するコンテンツ送信装置３００の機能的構成を模式的に示している。例えば、図１に示したコンテンツ伝送システム１００において、端末１０２にコンテンツをダウンロードするサーバー１０１や、端末１０３にコンテンツをダウンロードする端末１０２や、図２に示したコンテンツ伝送システムにおいて、端末１０２、１０３にコンテンツをダウンロードするサーバー２０１や、端末１０３にコンテンツをダウンロードする端末１０２などが図示のＳｏｕｒｃｅデバイスに相当する。
【００４８】
通信・制御部３０１は、ホーム・ネットワーク並びに外部ネットワークを介した通信動作を制御するとともに、当該コンテンツ送信装置３００全体の動作を統括的に制御する。また、通信・制御部３０１は、ＨＤＭＩ（登録商標）（Ｈｉｇｈ  Ｄｅｆｉｎｉｔｉｏｎ  Ｍｕｌｔｉｍｅｄｉａ  Ｉｎｔｅｒｆａｃｅ）やＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）などの外部機器接続用（若しくは、コンテンツのディジタル出力用）のインターフェースを備えており、ハード・ディスク装置やブルーレイ・ディスク装置などの録画再生機器を接続することができる。
【００４９】
コンテンツ記録部３０２は、ホーム・ネットワーク並びに外部ネットワーク越しで端末に提供するコンテンツを記録する。コンテンツ記録部３０２は、例えばハード・ディスクやブルーレイ・ディスク、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｃ）のような、コンテンツを記録する記録媒体を備え、例えばＦＡＴ（Ｆｉｌｅ  Ａｌｌｏｃａｔｉｏｎ  Ｔａｂｌｅ）のような一般的なファイル・システムの管理下で記録した各コンテンツを管理している。
【００５０】
コンテンツ取得部３０３は、端末に提供するコンテンツを取得する。コンテンツ取得部３０３は、例えば地上ディジタル放送用チューナーなどからなり、放送コンテンツを取得する。この場合のコンテンツ取得部３０３は、例えばＡＲＩＢ（Ａｓｓｏｃｉａｔｉｏｎ  ｏｆ  Ｒａｄｉｏ  Ｉｎｄｕｓｔｒｉｅｓ  ａｎｄＢｕｓｉｎｅｓｓｅｓ：電波産業会）で規定される仕様に基づく。コンテンツ取得部３０３は、例えば、放送チャンネルの全セグメント又は一部のセグメントの受信機能、ＥＰＧ（Ｅｌｅｃｔｒｏｎｉｃ  Ｐｒｏｇｒａｍ  Ｇｕｉｄｅ）の機能（番組検索、番組情報の表示、番組予約）、ＨＤＣＰ（Ｈｉｇｈ−ｂａｎｄｗｉｄｔｈ  Ｄｉｇｉｔａｌ  Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ）仕様などに基づくコピー制御機能、放送コンテンツを限定受信したり受信した放送コンテンツを外部出力する際に暗号化したりするコンテンツ保護機能などを備えている。
【００５１】
また、コンテンツ取得部３０３は、ブルーレイ・ディスクなどのメディア再生装置からなり、映画などの商用コンテンツをメディアから読み取る。また、コンテンツ取得部３０３は、ブラウザーなどからなり、インターネット上のコンテンツ・サーバー（図示しない）から有償又は無償のコンテンツをダウンロードする。コンテンツ取得部３０３は、取得したコンテンツは、必要に応じて上記のコンテンツ記録部３０２内に記録してもよい。また、コンテンツ取得部３０３は、Ｓｉｎｋデバイスに提供するコンテンツをコンテンツ記録部３０２から取得することもある。
【００５２】
コンテンツ取得部３０３が取得したコンテンツ（放送コンテンツや商用コンテンツ）の中には、移動可能な世代数が制限されたものもある。コンテンツのコピー制限や移動制限は、一般には、コンテンツ提供元の業者が設定するものであり、コンテンツ取得部３０３が放送コンテンツの受信時、メディア再生装置からの再生時などにコピー制限や移動制限に関する制御情報を受け取ることができる。取得したコンテンツをコンテンツ記録部３０２内に記録する際には、コンテンツ記録部３０２又はコンテンツ取得部３０３（あるいは、その他の機能モジュールでもよい）は、コンテンツに対応付けてコピー制限や移動制限に関する制御情報が管理されるものとする。
【００５３】
本実施形態では、コンテンツ記録部３０２は、コンテンツの移動可能な世代数の情報（以下、「Ｍｏｖｅ＿ｃｏｕｎｔ」とする）や世代制限付き移動可否などの移動制御情報を、図５に示すようにコンテンツ本体と対応付けて管理し、又は、図６に示すようにコンテンツ本体のデータの一部として管理できるものとする。但し、移動は常に１世代のみ可の場合には、移動可能な世代数Ｍｏｖｅ＿ｃｏｕｎｔの管理は不要である。
【００５４】
コンテンツ提供部３０４は、Ｓｉｎｋデバイスとして動作するコンテンツ受信装置（後述）からの要求に応答して、コンテンツ取得部３０３が取得したコンテンツを提供する。コンテンツ提供部３０４は、例えばＨＴＴＰ（Ｈｙｐｅｔ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）プロトコルが利用して、Ｓｉｎｋデバイスへコンテンツを伝送する。また、コンテンツ提供部３０４は、伝送するコンテンツを、認証・鍵共有部３０６によりＳｉｎｋデバイスと共有した共有鍵（コンテンツの移動の場合にはＫXM）などから計算した暗号鍵ＫCを用いて暗号化する。但し、Ｓｉｎｋデバイスが外部ネットワーク上からのリモート・アクセスによりコンテンツを要求する場合、そのＳｉｎｋデバイスは端末管理部３０７に事前登録されたものでなければならない（後述）。
【００５５】
コンテンツ提供部３０４がＳｉｎｋデバイスへコンテンツを提供する方法としてストリーミングとダウンロードが挙げられ、また、ダウンロードはコンテンツのコピーと移動の２通りがある。コンテンツ提供部３０４は、コンテンツ記録部３０２内のコンテンツの移動を行なう場合、Ｓｉｎｋデバイスにコンテンツを送信した後、送信済みのコンテンツをコンテンツ記録部３０２から消去して、同時存在を禁止する。コピーの場合、このようなコンテンツの消去操作は不要である。以下では、移動の形式でコンテンツを提供する場合について主に説明し、ストリーミングとコピーについては説明を省略する。
【００５６】
また、コンテンツ提供部３０４は、移動可能な世代数が制限されたコンテンツをＳｉｎｋデバイスに移動しようとする際には、相手となるＳｉｎｋデバイスが世代制限付きのコンテンツ移動に対応しているかを事前にチェックし、また、移動するコンテンツに移動可能な世代数の情報Ｍｏｖｅ＿ｃｏｕｎｔを設定するが、その詳細については後述に譲る。
【００５７】
コンテンツ・リスト提供部３０５は、例えば端末からの要求に応答して、端末に提供可能なコンテンツのリストと詳細情報を、端末に提供する。上述からも分かるように、サーバー１０１、２０１が端末に提供可能なコンテンツは、コンテンツ取得部３０３が受信する放送コンテンツやメディアから読み出す商用コンテンツ、コンテンツ記録部３０２に既に記録されているコンテンツが挙げられる。コンテンツ・リストの提供には、例えば、ＤＬＮＡのベースとなるＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ  ａｎｄＰｌａｙ）で策定されている、コンテンツのリストとコンテンツの詳細情報を階層化して配信するＣＤＳ（Ｃｏｎｔｅｎｔ  Ｄｉｒｅｃｔｏｒｙ  Ｓｅｒｖｉｃｅ）機能が適用される。
【００５８】
認証・鍵共有部３０６は、コンテンツの要求元となるＳｉｎｋデバイスとの間で、ＤＴＣＰ−ＩＰが規定する認証及び鍵交換（ＡＫＥ）アルゴリズムに従って、相互認証並びにコンテンツ暗号化のための共有鍵の共有を行なう。認証・鍵共有部３０６は、外部ネットワークからリモート・アクセスによりコンテンツを要求してくるＳｉｎｋデバイスに対しては、リモート・アクセス用共有鍵ＫRを共有する。また、コンテンツの移動を要求してくるＳｉｎｋデバイスに対しては、さらに移動（Ｍｏｖｅ）用の共有鍵ＫXMを共有する。
【００５９】
端末管理部３０７は、コンテンツを要求するＳｉｎｋデバイスの情報を管理する。現在のＤＴＣＰ−ＩＰ（ＤＴＣＰ−ＩＰ  Ｖｏｌｕｍｅ  １  Ｓｕｐｐｌｅｍｅｎｔ  Ｅ  Ｒｅｖｉｓｉｏｎ  １．４）では、第三者によるコンテンツの利用を制限することを意図して、家庭内のサーバーへのリモート・アクセスを、そのサーバーに登録したＳｉｎｋデバイスだけに限定している。本実施形態では、端末管理部３０７に事前登録されたＳｉｎｋデバイスのみコンテンツの要求が許可されるものとする。端末管理部３０７は、外部ネットワークからリモート・アクセスによりコンテンツを利用するＳｉｎｋデバイスに対して事前登録の処理を行なうとともに、そのＳｉｎｋデバイスの情報を「ｒｅｍｏｔｅ  ｓｉｎｋ  ｒｅｇｉｓｔｒｙ」や「ＲＡＣ（Ｒｅｍｏｔｅ  Ａｃｃｅｓｓ  Ｃｏｎｎｅｃｔｉｏｎ）  ｒｅｇｉｓｔｒｙ」として管理する。事前登録は、現在のＤＴＣＰ−ＩＰ（ＤＴＣＰ−ＩＰ  Ｖｏｌｕｍｅ  １  Ｓｕｐｐｌｅｍｅｎｔ  Ｅ  Ｒｅｖｉｓｉｏｎ  １．４）にも規定されているが、本明細書で開示する技術とは直接関連しないので、詳細な説明は省略する。
【００６０】
コンテンツ再生出力部３０８は、コンテンツ記録部３０２に記録されているコンテンツを復号して、再生出力する。
【００６１】
なお、上記の機能ブロック３０３〜３０７は、通信・制御部３０１において、オペレーティング・システムやＴＣＰ／ＩＰプロトコルの上位で実行するアプリケーション・プログラムとして実現することもできる。また、この種のアプリケーション・プログラムは、インターネットなどの広域ネットワーク上で所定のダウンロード・サイトで配信することができ、ディジタル放送チューナーやＴＶ受像機などのＣＥ（Ｃｏｎｓｕｍｅｒ  Ｅｌｅｃｔｒｏｎｉｃｓ）機器、スマートフォンなどの多機能端末にダウンロードして利用に供される。
【００６２】
このようなダウンロード・サイトは、例えば、コンピューター・プログラムを記憶する記憶装置２４１１と、コンピューター・プログラムのダウンロード要求を受信したことに応じてそのダウンロードを認める通信装置２４１２とを備えたサーバー２４１０からなり（図２４を参照のこと）、ダウンロードしたコンピューター・プログラムをインストールするクライアント装置（ＤＴＣＰ＿Ｓｏｕｒｃｅ又はＤＴＣＰ＿Ｓｉｎｋ）と併せてコンピューター・プログラム配信システム２４００を構成する。この種のサーバーは、クライアントからのコンピューター・プログラムのダウンロード要求に対して、コンピューター・プログラムの名称を示す情報を通知する情報通知装置２４１３をさらに備えている。情報通知装置２４１３は、コンピューター・プログラムの名称とともに、例えば、家庭内に記録した商用コンテンツを遠隔地の端末に提供するアプリケーションであることを示す情報を通知する。
【００６３】
図４には、Ｓｉｎｋデバイスとして動作するコンテンツ受信装置４００の機能的構成を模式的に示している。例えば、図１に示したコンテンツ伝送システム１００において、サーバー１０１にコンテンツを要求する端末１０２や、サーバー１０１若しくは端末１０２にコンテンツを要求する端末１０３、並びに、図２に示したコンテンツ伝送システム２００において、サーバー２０１にコンテンツを要求する端末２０２や、サーバー２０１若しくは端末２０２にコンテンツを要求する端末２０３などが図示のＳｉｎｋデバイスに相当する。
【００６４】
通信・制御部４０１は、ホーム・ネットワーク並びに外部ネットワークを介した通信動作を制御するとともに、当該コンテンツ受信装置４００全体の動作を統括的に制御する。
【００６５】
コンテンツ・リスト閲覧部４０２は、Ｓｏｕｒｃｅデバイスとして動作するコンテンツ送信装置３００（前述）に対して、コンテンツ・リストの取得要求を行ない、取得したコンテンツ・リストの閲覧画面を表示する。例えば、Ｓｏｕｒｃｅデバイスが提供可能なコンテンツのリストをＣＤＳ情報（前述）として取得したときには、コンテンツ一覧画面が表示される。ユーザーはこの一覧画面を通して、再生出力したいコンテンツを選択することができる。
【００６６】
コンテンツ取得部４０３は、コンテンツの取得要求をＳｏｕｒｃｅデバイスに送信して、Ｓｏｕｒｃｅデバイス内のコンテンツを取得する。コンテンツ取得部４０３は、例えば、コンテンツ・リスト閲覧部４０２が表示するコンテンツ一覧画面の中でユーザーが入力部４０７などを介して選択したコンテンツの取得を要求する。入力部４０７は、パーソナル・コンピューターにおけるキーボード並びにマウス、スマートフォンなどの多機能端末におけるタッチパネル、リモコンにおける十字キー並び決定ボタンなどに相当する。
【００６７】
コンテンツ取得部４０３がＳｏｕｒｃｅデバイスからコンテンツを取得する方法としてストリーミングとダウンロードが挙げられ、また、ダウンロードはコンテンツのコピーと移動の２通りがある。以下では、移動の形式でコンテンツを取得する場合について主に説明し、ストリーミングとコピーについては説明を省略する。なお、Ｓｏｕｒｃｅデバイスに対するコンテンツの取得要求並びにコンテンツの取得には、例えばＨＴＴＰプロトコルが利用される（後述）。
【００６８】
コンテンツ取得部４０３がＳｏｕｒｃｅデバイスから取得したコンテンツは、後述する認証・鍵共有部４０６によりＳｏｕｒｃｅデバイスとの間で共有した共有鍵（コンテンツの移動の場合にはＫXM）などから計算した暗号鍵ＫCを用いて暗号化されている。コンテンツ復号部４０４は、Ｓｏｕｒｃｅデバイスから取得した暗号化コンテンツを、この暗号鍵ＫCを用いて復号化することができる。そして、コンテンツ再生出力部４０５は、復号したコンテンツを再生出力する。
【００６９】
コンテンツ記録部４０８は、コンテンツ取得部４０３がダウンロード（すなわち、移動又はコピー）の形式で取得したコンテンツを記録する。記録するコンテンツには記録用の暗号化処理が別途施されることもある。コンテンツ記録部３０２は、例えばハード・ディスクやブルーレイ、ＤＶＤのような、コンテンツを記録する記録媒体を備え、例えばＦＡＴのような一般的なファイル・システムの管理下で記録した各コンテンツを管理している。
【００７０】
Ｓｏｕｒｃｅデバイスからの移動により取得したコンテンツの中には、移動可能な世代数が制限されたものもある。本実施形態では、コンテンツ記録部４０８は、コンテンツの移動可能な世代数の情報（以下、「Ｍｏｖｅ＿ｃｏｕｎｔ」とする）や世代制限付き移動可否などの移動制御情報を、図５に示すようにコンテンツ本体と対応付けて管理し、又は、図６に示すようにコンテンツ本体のデータの一部として管理できるものとする。コンテンツ取得部４０３が移動可能な世代数が制限されたコンテンツを取得し、コンテンツ記録部４０８に記録する際には、Ｍｏｖｅ＿ｃｏｕｎｔをデクリメントするなどの移動制御情報の更新処理を行なうが、その処理手順の詳細については後述に譲る。
【００７１】
認証・鍵共有部４０６は、コンテンツの要求先となるＳｏｕｒｃｅデバイスとの間で、ＤＴＣＰ−ＩＰが規定する認証及び鍵交換（ＡＫＥ）アルゴリズムに従って、相互認証並びにコンテンツ暗号化のための暗号鍵の共有を行なう。認証・鍵共有部４０６は、外部ネットワークからリモート・アクセスによりコンテンツを要求するＳｏｕｒｃｅデバイスとの間では、リモート・アクセス用共有鍵ＫRを共有する。また、コンテンツの移動を要求する際には、認証・鍵共有部４０６は、Ｓｏｕｒｃｅデバイスとの間でさらに移動（Ｍｏｖｅ）用の共有鍵ＫXMを共有する。また、認証・鍵共有部４０６は、ホーム・ネットワーク２１０接続時において、Ｓｏｕｒｃｅデバイスに対してリモート・アクセスのための事前登録を行なうものとする（前述）。
【００７２】
なお、図１に示したコンテンツ伝送システム１００の変形例として、コンテンツ受信装置４００（若しくはＳｉｎｋデバイス）としての端末１０２のコンテンツ記録部４０８が、コンテンツ送信装置３００（若しくはＳｏｕｒｃｅデバイス）に内蔵（例えば、内部バスで接続）され、単一の装置３００内でコンテンツ記録部３０２からコンテンツ記録部４０８へコンテンツ伝送（例えば移動）を行なうという構成も考えられる。例えば、パーソナル・コンピューターなどの情報機器内に内蔵されるハード・ディスク・ドライブ並びにメモリーカードが、コンテンツ記録部３０２、コンテンツ記録部４０８にそれぞれ相当する。
【００７３】
上記の機能ブロック４０２〜４０６は、通信・制御部４０１において、オペレーティング・システムやＴＣＰ／ＩＰプロトコルの上位で実行するアプリケーション・プログラムとして実現することもできる。この種のアプリケーション・プログラムは、インターネットなどの広域ネットワーク上で所定のダウンロード・サイトで配信することができ、スマートフォンなど、ホーム・サーバー内のコンテンツを再生する多機能端末にダウンロードして利用に供される。
【００７４】
このようなダウンロード・サイトは、例えば、コンピューター・プログラムを記憶する記憶装置２４１１と、コンピューター・プログラムのダウンロード要求を受信したことに応じてそのダウンロードを認める通信装置２４１２とを備えたサーバー２４１０からなり（図２４を参照のこと）、ダウンロードしたコンピューター・プログラムをインストールするクライアント装置（ＤＴＣＰ＿Ｓｏｕｒｃｅ又はＤＴＣＰ＿Ｓｉｎｋ）と併せてコンピューター・プログラム配信システム２４００を構成する。この種のサーバーは、クライアントからのコンピューター・プログラムのダウンロード要求に対して、コンピューター・プログラムの名称を示す情報を通知する情報通知装置２４１３をさらに備えている。情報通知装置２４１３は、コンピューター・プログラムの名称とともに、例えば、家庭内に記録した商用コンテンツを遠隔地で閲覧することが認められるアプリケーションであることを示す情報を通知する。
【００７５】
続いて、ＳｏｕｒｃｅデバイスからＳｉｎｋデバイスへコンテンツを移動するための処理動作について説明する。
【００７６】
ここで言うＳｏｕｒｃｅデバイスは、図１に示したコンテンツ伝送システム１００において、端末１０２、１０３にコンテンツをダウンロードするサーバー１０１や、端末１０３にコンテンツをダウンロードする端末１０２、図２に示したコンテンツ伝送システムにおいて、端末２０２、２０３にコンテンツをダウンロードするサーバー２０１や、端末２０３にコンテンツをダウンロードする端末２０２である。また、Ｓｉｎｋデバイスは、図１に示したコンテンツ伝送システム１００において、サーバー１０１にコンテンツを要求する端末１０２や、サーバー１０１若しくは端末１０２にコンテンツを要求する端末１０３、並びに、図２に示したコンテンツ伝送システム２００において、サーバー２０１にコンテンツを要求する端末２０２や、サーバー２０１若しくは端末２０２にコンテンツを要求する端末２０３である。
【００７７】
本明細書で開示する技術は、ＳｏｕｒｃｅデバイスからＳｉｎｋデバイスへコンテンツを移動する際に、世代制限付きでコンテンツの移動を制御する点に主な特徴がある。移動可能な世代数を制限すると、移動によるコンテンツの流通範囲を制限することにより、不正なコンテンツ利用の機会を抑制できるという効果がある。移動可能な世代数の制限は、ＤＴＣＰ−ＩＰ規格に従ってＩＰネットワーク経由でリモート・アクセスによりコンテンツの移動を行なう際にとりわけ効果があるが、もちろん、旧来のＤＴＣＰ規格に従ってホーム・ネットワーク上でコンテンツの移動を行なう際にも適用することができる。
【００７８】
図７には、ＳｏｕｒｃｅデバイスとＳｉｎｋデバイス間でリモート・アクセスによるコンテンツの移動を行なう際の全体的な手順を模式的に示している。なお、ＳｏｕｒｃｅデバイスとＳｉｎｋデバイス間では事前登録（前述）が済んでいることを前提とする。
【００７９】
図示のコンテンツ移動手順は、Ｓｉｎｋデバイスが移動を要求するコンテンツを指定するコンテンツ・リスト閲覧フェーズ（ＳＥＱ７０１）と、ＳｏｕｒｃｅデバイスとＳｉｎｋデバイス間で相互認証及び鍵交換手順を実施してリモート・アクセス用共有鍵ＫRを共有するＲＡ−ＡＫＥ手続きフェーズ（ＳＥＱ７０２）と、ＳｏｕｒｃｅデバイスとＳｉｎｋデバイス間で移動用共有鍵ＫXMを共有するＲＡ−ＡＫＥ手続きフェーズ（ＳＥＱ７０３）と、コンテンツ・リスト閲覧フェーズで指定されたコンテンツを、移動用共有鍵ＫXMを用いて暗号化伝送するコンテンツ伝送フェーズ（ＳＥＱ７０４）からなる。
【００８０】
図８には、コンテンツ・リスト閲覧フェーズ（ＳＥＱ７０１）の中身を模式的に示している。この処理手順は、主にＳｏｕｒｃｅデバイス側のコンテンツ・リスト提供部３０５とＳｉｎｋデバイス側のコンテンツ・リスト閲覧部４０２の間で実施される。
【００８１】
Ｓｉｎｋデバイスからは、コンテンツ・リスト閲覧部４０２から、コンテンツ・リストの閲覧要求が発行される（ＳＥＱ８０１）。コンテンツ・リストの閲覧には、ＤＬＮＡのベースとなるＵＰｎＰで策定されている、コンテンツのリストとコンテンツの詳細情報を階層化して配信するＣＤＳ機能が適用される（前述）。したがって、ＳＥＱ８０１では、ＳｉｎｋデバイスからＣＤＳ：Ｂｒｏｗｓｅアクションが発行される。
【００８２】
Ｓｏｕｒｃｅデバイス側では、コンテンツ提供部３０４で提供可能なコンテンツ（例えば、コンテンツ取得部３０３で取得可能な放送コンテンツや商用コンテンツ、あるいは、自身のストレージであるコンテンツ記録部３０２に既に記録されているコンテンツなど）に対してＣＤＳ：Ｂｒｏｗｓｅアクションが発行されたので、コンテンツ・リスト提供部３０５は、該当するコンテンツに関する取得可能なすべてのコンテンツ情報を取得して（ＳＥＱ８０２）、十分な情報量のＣＤＳ情報を生成する（ＳＥＱ８０３）。そして、Ｓｏｕｒｃｅデバイスは、Ｓｉｎｋデバイスに対してＣＤＳ  Ｒｅｓｕｌｔとして返す（ＳＥＱ８０４）。
【００８３】
Ｓｉｎｋデバイス側では、コンテンツ・リスト閲覧部４０２が、受信したＣＤＳ  Ｒｅｓｕｌｔを解析して、コンテンツのタイトル並びにより詳細情報を含むコンテンツ情報を表示する（ＳＥＱ８０５）。
【００８４】
Ｓｉｎｋデバイスのユーザーは、表示されているコンテンツ・リストの中から、再生したいコンテンツを選択することができる。そして、コンテンツが選択されると、ＳｏｕｒｃｅデバイスからＳｉｎｋデバイスへのコンテンツの伝送が開始されるが、コンテンツ伝送に先駆けて、ＳｉｎｋデバイスとＳｏｕｒｃｅデバイス間で、リモート・アクセス用の相互認証及び鍵交換すなわちＲＡ−ＡＫＥ処理（ＳＥＱ７０２）と、移動（Ｍｏｖｅ）用のＡＫＥ処理（ＳＥＱ７０３）が実施される。
【００８５】
図９には、ＲＡ−ＡＫＥ手続きフェーズ（ＳＥＱ７０２）の中身の詳細を示している。この処理手順は、主にＳｏｕｒｃｅデバイス側の認証・鍵共有部３０６とＳｉｎｋデバイス側の認証・鍵共有部４０６の間で実施される。なお、ＲＡ−ＡＫＥ手続きフェーズについては、ＤＴＣＰの仕様書（前述）のＶ１ＳＥ．１０．７．２節にも記載されている。
【００８６】
Ｓｉｎｋデバイスは、リモート・アクセス用交換ＫR（Ｒｅｍｏｔｅ  Ｅｘｃｈａｎｇｅ  Ｋｅｙ）用のビットが設定された共有鍵フィールドを含んだＣＨＡＬＬＥＮＧＥコマンドを送信して、Ｓｏｕｒｃｅデバイスに対してＡＫＥ処理を要求する（ＳＥＱ９０１）。そして、ＳｏｕｒｃｅデバイスとＳｉｎｋデバイス間で、認証手続きのうちチャレンジ・レスポンス部分が実行される（ＳＥＱ９０２〜９０４）。
【００８７】
但し、ＣＨＡＬＬＥＮＧＥコマンドのＫR用のビットが設定されていないときには、ＳｏｕｒｃｅデバイスはＲＡ−ＡＫＥ手続きを中止し、ＲＡ−ＡＫＥ以外のＡＫＥ手続きを引き続き行なうことができる。
【００８８】
Ｓｏｕｒｃｅデバイスは、チャレンジ・レスポンス手続きでＳｉｎｋデバイスから、Ｄｅｖｉｃｅ  ＩＤ又はＩＤｕをＳｉｎｋ−ＩＤとして受け取ると（ＳＥＱ９０５）、そのＳｉｎｋ−ＩＤが自身の端末管理部３０７内で管理しているｒｅｍｏｔｅ  ｓｉｎｋ  ｒｅｇｉｓｔｒｙ（前述）に登録されているかどうかをチェックする（ＳＥＱ９０６）。
【００８９】
Ｓｉｎｋ−ＩＤがｒｅｍｏｔｅ  ｓｉｎｋ  ｒｅｇｉｓｔｒｙにリストされていない場合には（ＳＥＱ９０６のＮｏ）、Ｓｏｕｒｃｅデバイスは、ＳｉｎｋデバイスにＡＫＥ＿ＣＡＮＣＥＬコマンドを送信して（ＳＥＱ９１４）、ＲＡ−ＡＫＥ手続きを中止する（ＳＥＱ９１５）。
【００９０】
一方、Ｓｉｎｋ−ＩＤがｒｅｍｏｔｅ  ｓｉｎｋ  ｒｅｇｉｓｔｒｙに既に登録されている場合には（ＳＥＱ９０６のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、このＳｉｎｋ−ＩＤに該当するＲＡＣ  ｒｅｃｏｒｄが既に存在するかどうかを判別するために、ＲＡＣ  ｒｅｇｉｓｔｒｙ（後述）内をチェックする（ＳＥＱ９０７）。
【００９１】
Ｓｉｎｋ−ＩＤに該当するＲＡＣ  ｒｅｃｏｒｄが存在する場合には（ＳＥＱ９０７のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、そのＲＡＣ  ｒｅｃｏｒｄに格納されているリモート・アクセス用共有鍵ＫR及びその共有鍵ラベルＫR＿ｌａｂｅｌを使うことに決定する。あるいは、Ｓｏｕｒｃｅデバイスは、リモート・アクセス用共有鍵ＫRを用いてコンテンツの伝送を行なっていないのであれば、ＲＡＣ  ｒｅｃｏｒｄ内を参照し、格納されているＫR及びＫR＿ｌａｂｅｌの値を更新するようにしてもよい（ＳＥＱ９１３）。
【００９２】
Ｓｉｎｋ−ＩＤはｒｅｍｏｔｅ  ｓｉｎｋ  ｒｅｇｉｓｔｒｙに登録済みであるが、該当するＲＡＣ  ｒｅｃｏｒｄが存在しない場合には（ＳＥＱ９０７のＮｏ）、Ｓｏｕｒｃｅデバイスは、ＲＡＣ  ｒｅｃｏｒｄをカウントするカウント値ＲＡＣＣがＲＡＣＣmax未満であるかどうかをチェックする（ＳＥＱ９０８）。ここで、ＲＡＣＣmaxは、リモート・アクセス・コネクションをカウントするカウンターであり、リモート・アクセス・コネクションが存在しないときにゼロに初期化される。
【００９３】
ＲＡＣＣがそのＲＡＣＣmax未満でないときには（ＳＥＱ９０８のＮｏ）、Ｓｏｕｒｃｅデバイスは、ＳｉｎｋデバイスにＡＫＥ＿ＣＡＮＣＥＬコマンドを送信して（ＳＥＱ９１４）、ＲＡ−ＡＫＥ手続きを中止する（ＳＥＱ９１５）。
【００９４】
ＲＡＣＣがＲＡＣＣmax未満であれば（ＳＥＱ９０８のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、ＲＡＣＣの値を１だけインクリメントした後（ＳＥＱ９０９）、所定の演算規則に従って、リモート・アクセス用共有鍵ＫR及びその共有鍵ラベルＫR＿ｌａｂｅｌを生成して（ＳＥＱ９１０）、これらをＳｉｎｋデバイスのＳｉｎｋ−ＩＤと対応付けて、ＲＡＣ  ｒｅｇｉｓｔｒｙ内のＲＡＣ  ｒｅｃｏｒｄに格納する（ＳＥＱ９１１）。サーバー２０１は、例えば端末管理部３０７内でＲＡＣ  ｒｅｃｏｒｄを管理する。
【００９５】
そして、Ｓｏｕｒｃｅデバイスは、既存のＲＡＣ  ｒｅｃｏｒｄから取り出したリモート・アクセス用共有鍵ＫR及びその共有鍵ラベルＫR＿ｌａｂｅｌ（更新した場合を含む）、又は、新たに生成したリモート・アクセス用共有鍵ＫR及びその共有鍵ラベルＫR＿ｌａｂｅｌを、Ｓｉｎｋデバイスに送信する（ＳＥＱ９１６）。
【００９６】
ＳｏｕｒｃｅデバイスがＲＡ＿ＭＡＮＡＧＥＭＥＮＴ機能をサポートしている場合には、リモート・アクセス用交換ＫRを維持するためのＫR用生存タイマーを開始させ、少なくとも１分間ＫRを保持する（ＳＥＱ９１２）。
【００９７】
図１０には、ＭＯＶＥ−ＡＫＥ手続きフェーズ（ＳＥＱ７０３）の中身を示している。この処理手順は、主にＳｏｕｒｃｅデバイス側の認証・鍵共有部３０６とＳｉｎｋデバイス側の認証・鍵共有部４０６の間で実施される。なお、ＭＯＶＥ−ＡＫＥ手続きについては、ＤＴＣＰの仕様書（前述）のＶ１ＳＥ．１０．４．１節にも記載されている。
【００９８】
Ｓｉｎｋデバイスは、ＳｏｕｒｃｅデバイスにＭＶ＿ＩＮＩＴＩＡＴＥコマンドを送信することによって、移動用のＲＴＴ−ＡＫＥプロトコルを開始する（ＳＥＱ１００１）。
【００９９】
これに対し、Ｓｏｕｒｃｅデバイスは、ＤＴＣＰ−ＩＰのＭｏｖｅプロトコルを実行できるときには、その受領確認として、ＭＶ＿ＩＮＩＴＩＡＴＥレスポンスを返信する（ＳＥＱ１００２）。
【０１００】
上述したように、ＳｏｕｒｃｅデバイスがＳｉｎｋデバイスに移動するコンテンツの中には移動可能な世代数が制限されているものがある。Ｓｉｎｋデバイスは、移動用のＲＴＴ−ＡＫＥプロトコルの開始に際し、自分が世代制限付きのコンテンツ移動に対応していることをＳｏｕｒｃｅデバイスに通知するようにしてもよい。例えば、当該プロトコルの開始コマンドであるＭＶ＿ＩＮＩＴＩＡＴＥに代えて、世代制限付きで移動できることを示すＭＶ＿ＩＮＩＴＩＡＴＥ２を用意する方法が考えられる。ＳｉｎｋデバイスがＭＶ＿ＩＮＩＴＩＡＴＥ２コマンドを用いて当該プロトコルを開始するとき、ＳｏｕｒｃｅデバイスはＳｉｎｋデバイスが世代制限付きのコンテンツ移動に対応していることを認識することができる。この点の詳細については後述に譲る。
【０１０１】
また、Ｓｉｎｋデバイスは、能力情報の交換が必要な場合には、この時点で、ＳｏｕｒｃｅデバイスにＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥコマンドを送信する（ＳＥＱ１００３）。これに対し、Ｓｏｕｒｃｅデバイスは、ＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥレスポンスを返信する（ＳＥＱ１００４）。
【０１０２】
続いて、ＳｉｎｋデバイスとＳｏｕｒｃｅデバイスは、Ｃｈａｌｌｅｎｇｅ−Ｒｅｓｐｏｎｓｅ  ｐｏｒｔｉｏｎ  ｏｆ  ＡＫＥ手続と（ＳＥＱ１００５）、Ｐｒｏｔｅｃｔｅｄ  ＲＴＴ  Ｐｒｏｔｏｃｏｌ手続を実施し（ＳＥＱ１００６）、ＫAUTHを使って計算された移動用の認証鍵（ＨＫAUTH）を共有する。
【０１０３】
そして、Ｓｏｕｒｃｅデバイスは、移動用の共有鍵ＫXMを生成して、これをＭＶ＿ＥＸＣＨＡＮＧＥ＿ＫＥＹコマンドでＳｉｎｋデバイスに送信する（ＳＥＱ１００７）。これに対し、Ｓｉｎｋデバイスは、ＭＶ＿ＥＸＣＨＡＮＧＥ＿ＫＥＹレスポンスを返信する（ＳＥＱ１００８）。
【０１０４】
移動用の共有鍵ＫXMの設定方法について、以下に補足しておく。
【０１０５】
まず、Ｓｏｕｒｃｅデバイスは、乱数を移動用の共有鍵ＫXMに割り当てるとともに、この共有鍵ＫXMに共有鍵ラベルＫXM＿ｌａｂｅｌを割り当てる。
【０１０６】
次いで、Ｓｏｕｒｃｅデバイスは、ＨＫAUTHを使ってＫXMにスクランブルをかけると、ライセンスの下でＤＴＬＡ（Ｄｉｇｉｔａｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｌｉｃｅｎｓｉｎｇ  Ａｄｍｉｎｉｓｔｒａｔｏｒ）から利用できるＤＴＣＰ仕様に記載されている関数に従ってＫSXMを求める。そして、Ｓｏｕｒｃｅデバイスは、鍵ＫSXMを共有鍵ラベルＫXM＿ｌａｂｅｌとともに、Ｓｉｎｋデバイスに送信する。
【０１０７】
Ｓｉｎｋデバイスは、ＫAUTH´から計算されるＨＫAUTH´を使ってＫSXMをデスクランブルすると、ライセンスの下でＤＴＬＡから利用できるＤＴＣＰ仕様に記載されている関数に従って、Ｓｏｕｒｃｅデバイスと共有する移動用の共有鍵ＫXMを決定する。
【０１０８】
図１１には、コンテンツ伝送フェーズ（ＳＥＱ７０４）の中身を模式的に示している。この処理手順は、主にＳｏｕｒｃｅデバイス側のコンテンツ提供部３０４とＳｉｎｋデバイス側のコンテンツ取得部４０３の間で実施される。ここでは、上記のＭＯＶＥ−ＡＫＥ手続きフェーズ（ＳＥＱ７０３）を経てＳｏｕｒｃｅデバイスとＳｉｎｋデバイス間で共有される移動用の共有鍵ＫXMを用いて、コンテンツ・リスト閲覧フェーズ（ＳＥＱ７０１）で指定されたコンテンツの移動が行なわれるものとする。
【０１０９】
Ｓｉｎｋデバイスは、ＨＴＴＰ  ＧＥＴメソッドを用いたＨＴＴＰリクエスト（ＨＴＴＰ  ＧＥＴ  ｒｅｑｕｅｓｔ）により、Ｓｏｕｒｃｅデバイスに対して、コンテンツの移動を要求する（ＳＥＱ１１０１）。このＨＴＴＰ  ＧＥＴリクエストには、コンテンツのＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）とともに、ＭＯＶＥ−ＡＫＥ手続きフェーズ（ＳＥＱ７０３）により取得した移動用の共有鍵ラベルＫXM＿ｌａｂｅｌを含める。ＨＴＴＰ  ＧＥＴリクエストは、ＢＬＫＭｏｖｅ．ｄｔｃｐ．ｃｏｍ＜ＫXM＿ｌａｂｅｌ＞というヘッダー情報を含んでいる。
【０１１０】
Ｓｉｎｋデバイスは、このコンテンツの移動要求（ＳＥＱ１１０１）の際に、自分が世代制限付きのコンテンツ移動に対応していることをＳｏｕｒｃｅデバイスに通知するようにしてもよい。例えば、コンテンツ移動用プロトコルのために用意されているＢＬＫＭｏｖｅ．ｄｔｃｐ．ｃｏｍヘッダー・フィールドの拡張版として、ＢＬＫＭｏｖｅ２．ｄｔｃｐ．ｃｏｍヘッダー・フィールドを用意して、このヘッダー内でＳｉｎｋデバイスが世代制限付きのコンテンツ移動に対応していることをＳｏｕｒｃｅデバイスに伝えることが考えられる。この点の詳細については後述に譲る。上記のように、ＢＬＫＭｏｖｅ．ｄｔｃｐ．ｃｏｍヘッダー・フィールドは、共有鍵ＫXMを特定するためのパラメーターである共有鍵ラベルＫXM＿ｌａｂｅｌをパラメーターに含む。
【０１１１】
あるいは、既に述べたように、Ｓｉｎｋデバイスは、移動用のＲＴＴ−ＡＫＥプロトコルの開始に際し、自分が世代制限付きのコンテンツ移動に対応していることをＳｏｕｒｃｅデバイスに通知することもある。
【０１１２】
いずれの方法でＳｉｎｋデバイスが移動可能な世代数の制限対応について通知するにせよ、Ｓｏｕｒｃｅデバイスは、コンテンツ移動の開始に先駆けて、Ｓｉｎｋデバイスがコンテンツの移動可能な世代数の制限機能に対応しているかどうかを確認する（ＳＥＱ１１０２）。ここでは、Ｓｉｎｋデバイスが世代制限付きのコンテンツ移動に対応しているものとして説明を続ける。
【０１１３】
Ｓｏｕｒｃｅデバイスは、Ｓｉｎｋデバイスからのコンテンツ要求を許可する場合には、共有鍵ラベルＫXM＿ｌａｂｅｌで指定された移動用共有鍵ＫXMを用いてコンテンツを暗号化して、Ｓｏｕｒｃｅデバイスは、ＨＴＴＰレスポンス（ＨＴＴＰ  ＧＥＴ  ｒｅｓｐｏｎｓｅ）としてＳｉｎｋデバイスに伝送する（ＳＥＱ１１０３）。
【０１１４】
ＨＴＴＰレスポンスは、１つ以上のＰＣＰからなる。具体的には、Ｓｏｕｒｃｅデバイスは、乱数を用いてノンスＮcを生成すると、共有鍵ＫXMとノンスＮcと暗号モードを表すＥ−ＥＭＩに基づいてコンテンツ鍵Ｋcを計算し、このコンテンツ鍵Ｋcを用いて暗号化する。そして、暗号化コンテンツを含んだＰＣＰ（Ｐｒｏｔｅｃｔｅｄ  Ｃｏｎｔｅｎｔ  Ｐａｃｋｅｔ）パケットをＴＣＰストリーム上に乗せる。ＩＰプロトコルは、暗号化コンテンツを含んだＴＣＰストリームを所定の単位となるパケットの大きさに分割し、さらにヘッダー部を付加したＩＰパケットにし、指定されたＩＰアドレス宛てに届ける。
【０１１５】
図１２に示すように、ＰＣＰパケット１２００は、暗号化コンテンツからなるペイロード１２０２とノンスＮcとＥ−ＥＭＩを含んだヘッダー１２０１からなる。Ｅ−ＥＭＩ（Ｅｘｔｅｎｄｅｄ  Ｅｎｃｒｉｐｔｉｏｎ  Ｍｏｄｅ  Ｉｎｄｉｃａｔｏｒ）は、暗号モードを記述する４ビット長のフィールドで構成され、その値はコピー制御情報の７種類に対応する。
【０１１６】
Ｓｏｕｒｃｅデバイスは、伝送するコンテンツは世代制限付きで移動可能であることと、移動可能な世代数の情報Ｍｏｖｅ＿ｃｏｕｎｔを、Ｓｉｎｋデバイス側に通知する必要がある。例えば、ＰＣＰヘッダー内のＥ−ＥＭＩに世代制限付きで移動可能であることを意味する値を追加定義するとともに、ＰＣＰペイロード内など（例えば、ＤＴＣＰ＿ｄｅｓｃｒｉｐｔｏｒ、ＰＣＰ−ＵＲ、ＣＭＩなど）に新たなフィールドを設けて移動可能な世代数の情報Ｍｏｖｅ＿ｃｏｕｎｔを運ぶようにしてもよい。この点の詳細については後述に譲る。
【０１１７】
Ｓｉｎｋデバイス側では、Ｓｏｕｒｃｅデバイスからの各ＩＰパケットを受信すると、これをＴＣＰストリームに組み立てて、送信された元のＰＣＰパケットを再現する。そして、ストリームからノンスＮcとＥ−ＥＭＩを取り出すと、これらと共有鍵ＫXMを用いてコンテンツ鍵Ｋcを算出し、暗号化コンテンツを復号することができる。そして、復号化した後の平文のコンテンツに対しコンテンツ再生出力部４０５からの再生若しくはコンテンツ記録部４０８への記録などの処理を実施することができる。
【０１１８】
このようにしてＨＴＴＰプロトコルを利用したコンテンツ伝送が終了すると、例えばＳｉｎｋデバイス側から、コンテンツ伝送に使用したＴＣＰコネクションを適宜切断する。
【０１１９】
世代制限付きのコンテンツ移動機能に対応しているＳｉｎｋデバイスは、受信したコンテンツに関する移動制御情報の更新処理を行なう（ＳＥＱ１１０４）。具体的には、コンテンツ記録部４０８への記録する際などに、受信したコンテンツが制限された世代数内で移動可能であるかどうかをチェックするとともに、移動可能な世代数の情報Ｍｏｖｅ＿ｃｏｕｎｔを更新する。この点の詳細については後述に譲る。
【０１２０】
続いて、図１、図２に示したようなコンテンツ伝送システム１００、２００において、私的利用の範囲を超えるコンテンツの利用を防止する仕組みについて、さらに詳細に説明する。本明細書で開示する技術は、ＳｏｕｒｃｅデバイスからＳｉｎｋデバイスへコンテンツを移動する際に、移動可能な世代数に制限を課すことによって、コンテンツの流通範囲を制限する方法を採用する。
【０１２１】
世代制限付きのコンテンツの移動の仕組みを、本実施形態のようなＤＴＣＰ若しくはＤＴＣＰ−ＩＰが適用されたコンテンツ伝送システム１００、２００で実現する場合、コンテンツの流通範囲を制限して、私的利用の範囲を超えるコンテンツの利用を防止することになる。
【０１２２】
コンテンツの移動元であるＳｏｕｒｃｅデバイスと、その移動先であるＳｉｎｋデバイスの間で、コンテンツ移動の制御情報として、移動可能な世代数の情報Ｍｏｖｅ＿ｃｏｕｎｔを伝え、ＳｉｎｋデバイスはＭｏｖｅ＿ｃｏｕｎｔを１だけデクリメントして受信したコンテンツを管理するようにする。Ｍｏｖｅ＿ｃｏｕｎｔがまだ１以上であれば、Ｓｉｎｋデバイスは、（今度はＳｏｕｒｃｅデバイスとして）それを次の制御情報としてコンテンツのさらなる移動が可能である。一方、Ｍｏｖｅ＿ｃｏｕｎｔが０になってしまうと、そのコンテンツのさらなる移動はできないものとする。なお、Ｍｏｖｅ＿ｃｏｕｎｔ＝１すなわち移動は１世代のみ可として運用するのであれば、移動可能な世代数の情報を伝える必要はなく、移動の可否を示す制御情報だけを用いることもできる。
【０１２３】
まず、世代制限付きの移動の可否を示す制御情報を通知する方法について説明する。
【０１２４】
ＤＴＣＰをＩＰ伝送にマッピングしたＤＴＣＰ−ＩＰでは、コンテンツ伝送に用いられるＨＴＴＰレスポンスは、１以上のＰＣＰと呼ばれるパケットからなる。図１２に示したように、そのＰＣＰヘッダー１２０１は、Ｅ−ＥＭＩを含んでいる。このＥ−ＥＭＩは、暗号モード（Ｅ−ＥＭＩ  Ｍｏｄｅ）を記述する４ビット長のフィールドで構成され、その値はコピー制御情報の７種類に対応する。
【０１２５】
本実施形態では、Ｅ−ＥＭＩフィールドの未定義の値に「世代制限付き移動可」を意味する値を追加定義する。具体的には、未定義の値「０１１１2」をＭｏｄｅ  Ｃ２として「世代制限付き移動可」と定義する。図１３には、ＤＴＣＰ−ＩＰ規格通りのＥ−ＥＭＩを示し、図１４には、「０１１１2」を「世代制限付き移動可」と追加定義したＥ−ＥＭＩを示している。
【０１２６】
Ｓｏｕｒｃｅデバイスは、世代制限付きで移動が許可されたコンテンツを移動する際には、その伝送に用いられるＰＣＰパケットのヘッダー内のＥ−ＥＭＩフィールドに「０１１１2」を書き込む。Ｓｉｎｋデバイス側では、ＨＴＴＰレスポンスの例えば先頭のＰＣＰパケットのヘッダー内のＥ−ＥＭＩの値をチェックすることで、コンテンツが「世代制限付き移動可」であるかどうかを判別することができる（勿論、従来通り、コピー制御情報並びに対応する暗号モードを識別することもできる）。
【０１２７】
次いで、移動可能な世代数を通知する方法について説明する。
【０１２８】
ＤＴＣＰで運用する制御情報の中に、移動可能な世代数に関する情報を運ぶための新たなフィールドを設ける方法が挙げられる。ここで言う制御情報として、ＤＴＣＰ＿ｄｅｓｃｒｉｐｔｏｒ、ＰＣＰ−ＵＲ、ＣＭＩなどを挙げることができる。
【０１２９】
ＤＴＣＰ＿ｄｅｓｃｒｉｐｔｏｒは、ＭＰＥＧ−ＴＳ形式でコンテンツを伝送する際の、ＤＴＣＰ制御情報を送る手段として用意されたもので、ＭＰＥＧ−ＴＳパケットの中（ＰＣＰペイロード内）に埋め込まれ、コンテンツとともに暗号化伝送される。図１５には、ＤＴＣＰ＿ｄｅｓｃｒｉｐｔｏｒの未使用領域をＭｏｖｅ＿ｃｏｕｎｔフィールドとして定義して、移動可能な世代数を記載した例を示している。同図では、参照番号１５０１で示すように、移動可能な世代数として１（回）が記入されている。
【０１３０】
ＰＣＰ−ＵＲ（Ｐｒｏｔｅｃｔｅｄ  Ｃｏｎｔｅｎｔ  Ｐａｃｋｅｔ−Ｕｓａｇｅ  Ｒｕｌｅ）は、ＭＰＥＧ−ＴＳ以外の形式でコンテンツを伝送する際の、ＤＴＣＰ制御情報を送る手段として用意されたもので、図１６に示すように、ＰＣＰヘッダー中のノンスＮcのフィールドの中に格納される。また、図１７には、ノンスＮcのフィールドのうちＰＣＰ−ＵＲ部分のフォーマットをより詳細に示している。図示の例では、ＰＣＰ−ＵＲの未使用領域１７０１をＭｏｖｅ＿ｃｏｕｎｔフィールドとして定義した例を示している。
【０１３１】
例えば、コンテンツ伝送フェーズＳＥＱ７０４で、ＭＰＥＧ−ＴＳ形式でコンテンツを伝送する場合には、図１５に示したようにＤＴＣＰ＿ｄｅｓｃｒｉｐｔｏｒ内で移動可能な世代数の情報を運び、ＭＰＥＧ−ＴＳ以外の形式でコンテンツを伝送する場合は、図１７に示したようにＰＣＰ−ＵＲ内で移動可能な世代数の情報を運ぶように、上記の方法を使い分けることも考えられる。
【０１３２】
ＣＭＩ（Ｃｏｎｔｅｎｔ  Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ）は、コンテンツの伝送形式によらず共通の方法でＤＴＣＰ制御情報を送る手段として用意されたものである。ＤＴＣＰ−ＩＰの場合、コンテンツ伝送フェーズＳＥＱ７０４では、コンテンツはＰＣＰ２パケット、制御情報はＣＭＩパケットにそれぞれ格納され、ＰＣＰ２とＣＭＩのパケットが混在したデータとして送られる。図１８には、ＣＭＩのパケット・フォーマットを示している。ＣＭＩパケットのペイロード部分であるＣＭＩフィールドには、１又はそれ以上のＣＭＩ  Ｄｅｓｃｒｉｐｔｏｒが格納される。ＣＭＩ  ｄｅｓｃｒｉｐｔｏｒの未使用領域をＭｏｖｅ＿ｃｏｕｎｔフィールドとして定義して、移動可能な世代数を記載する方法が考えられる。この方法によれば、コンテンツの伝送形式によらず共通に移動可能な世代数を伝えることができる。図１９には、ＣＭＩ  ｄｅｓｃｒｉｐｔｏｒ１フォーマットの未使用領域１９０１をＭｏｖｅ＿ｃｏｕｎｔフィールドとして定義した例を示している。また、図２０には、ＣＭＩ  ｄｅｓｃｒｉｐｔｏｒ２フォーマットの未使用領域２００１をＭｏｖｅ＿ｃｏｕｎｔフィールドとして定義した例を示している。
【０１３３】
上記では、ＤＴＣＰ−ＩＰ仕様において、コンテンツの移動に関する制御情報の伝送に、Ｅ−ＥＭＩ、ＤＴＣＰ＿ｄｅｓｃｒｉｐｔｏｒ、ＰＣＰ−ＵＲ、ＣＭＩを利用可能であることを例示した。ここで、ＤＴＣＰ−ＩＰ仕様上、Ｅ−ＥＭＩの送信は必須であるのに対し、ＰＣＰ−ＵＲ、ＣＭＩを送信することは必須ではない。言い換えれば、移動の可否を示す制御情報は必ず伝えることができるが、移動可能な世代数がＳｉｎｋデバイスに伝わらないこともあり得る。
【０１３４】
Ｓｉｎｋデバイスは、受信したＰＣＰパケットのヘッダー内のＥ−ＥＭＩの値を参照して、世代制限付き移動可であることが分かると、少なくともその移動可能な世代数が１以上であると言える。そこで、ＰＣＰ−ＵＲ、ＣＭＩが届かないなどの理由により、コンテンツの移動可能な世代数が不明な場合には、Ｓｉｎｋデバイスは、移動可能な世代数が１で受信したものとして処理するようにする。２以上の余分な世代数を与えないことにより、以降のコンテンツの流通範囲を制限する。
【０１３５】
図２１には、Ｓｉｎｋデバイスが、コンテンツ伝送フェーズＳＥＱ７０４において、受信したコンテンツの移動世代数を制御するための処理手順をフローチャートの形式で示している。この処理手順では、移動可能な世代数Ｍｏｖｅ＿ｃｏｕｎｔが０になったことを以って、更なる移動が禁止されたコンテンツと判断するものとする。
【０１３６】
通信・制御部４０１でＨＴＴＰレスポンスの例えば先頭のＰＣＰパケットを受信すると、コンテンツ取得部４０３は、そのＰＣＰヘッダー内のＥ−ＥＭＩの値を参照して、コンテンツが「世代制限付き移動可」であるかどうかをチェックする（ステップＳ２１０１）。
【０１３７】
次いで、コンテンツ取得部４０３は、ＤＴＣＰ＿ｄｅｓｃｒｉｐｔｏｒ、ＰＣＰ−ＵＲ、ＣＭＩなどに定義されているＭｏｖｅ＿ｃｏｕｎｔフィールドの検出を試みる（ステップＳ２１０２）。
【０１３８】
ここで、ＰＣＰ−ＵＲ、ＣＭＩが届かないなどの理由により、Ｍｏｖｅ＿ｃｏｕｎｔフィールドを検出できないときには（ステップＳ２１０２のＮｏ）、コンテンツ取得部４０３は、Ｍｏｖｅ＿ｃｏｕｎｔ＝１、すなわち受信したコンテンツは１世代のみ移動可能とみなして、このコンテンツを「更なる移動不可」と設定して（ステップＳ２１０５）、本処理ルーチンを終了する。
【０１３９】
一方、Ｍｏｖｅ＿ｃｏｕｎｔフィールドを検出できたときには（ステップＳ２１０２のＹｅｓ）、コンテンツ取得部４０３は、Ｍｏｖｅ＿ｃｏｕｎｔフィールドの値、すなわち移動可能な世代数を１だけデクリメントする（ステップＳ２１０３）。
【０１４０】
次いで、コンテンツ取得部４０３は、Ｍｏｖｅ＿ｃｏｕｎｔフィールドの値が０より大きいか、すなわちまだ移動可能であるかどうかをチェックする（ステップＳ２１０４）。
【０１４１】
ここで、Ｍｏｖｅ＿ｃｏｕｎｔフィールドの値が０以下、すなわち移動可能な世代数が消滅したときには（ステップＳ２１０４のＮｏ）、コンテンツ取得部４０３は、このコンテンツを「更なる移動不可」と設定して（ステップＳ２１０５）、本処理ルーチンを終了する。
【０１４２】
また、Ｍｏｖｅ＿ｃｏｕｎｔフィールドの値が０より大きいときには（ステップＳ２１０４のＹｅｓ）、コンテンツ取得部４０３は、デクリメントしたＭｏｖｅ＿ｃｏｕｎｔフィールドの値で、このコンテンツを世代制限付きで移動可能としたまま、本処理ルーチンを終了する。
【０１４３】
そして、コンテンツ取得部４０３は、上記の処理ルーチンを終了した後、移動可能な世代数の情報や世代制限付き移動可否の情報と対応付けて（図５又は図６を参照のこと）、受信したコンテンツをコンテンツ記録部４０８に記録する。
【０１４４】
上述したように、Ｓｉｎｋデバイスは、Ｅ−ＥＭＩが「世代制限付き移動可」で、移動可能な世代数Ｍｏｖｅ＿ｃｏｕｎｔ＝１又はＭｏｖｅ＿ｃｏｕｎｔが不明として受信したコンテンツの更なる移動を防止する。具体的には、Ｓｉｎｋデバイスは、（Ｓｏｕｒｃｅデバイスとして）次にＤＴＣＰ−ＩＰで送信する場合、このようなコンテンツのＥ−ＥＭＩには、記録の禁止を意味する値（例えば、０１００2や１１００2）を用いる。そして、このように記録禁止を意味するＥ−ＥＭＩが使われているコンテンツを受信した次のＳｉｎｋデバイスは、ＤＴＣＰ＿ｄｅｓｃｒｉｐｔｏｒ、ＰＣＰ−ＵＲ、ＣＭＩなどから判明した移動可能な世代数Ｍｏｖｅ＿ｃｏｕｎｔの値によらず、コンテンツを移動できないものとして扱う（Ｅ−ＥＭＩの内容を優先する）。
【０１４５】
２０１３年６月時点では、ＤＴＣＰ（ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ）は、コンテンツの移動に関しては、移動可能な世代数などを制限していない（前述）。ＤＴＣＰ仕様では、Ｅ−ＥＭＩの値は、コピー制御情報に対応した、コンテンツの暗号鍵（Ｋc）を計算するためのＪ−ＡＥＳ関数の１つのパラメーターである。本実施形態のように未定義のＥ−ＥＭＩの値を世代制御に使用した場合（図１４を参照のこと）、世代制限付きのコンテンツ移動に対応していない旧来のＳｉｎｋデバイスは、Ｅ−ＥＭＩの値として「世代制限付き移動可」を意味する「０１１１2」を受け取っても、正しい暗号鍵を計算できず、したがって、受信したコンテンツを復号できない。よって、世代制限付きのコンテンツ移動に対応しているＳｉｎｋデバイスだけに世代制限付きのコンテンツを渡すことができることになる。
【０１４６】
続いて、世代制限付きでコンテンツを移動する際に消失を防止する方法について説明する。
【０１４７】
既に述べたように、コンテンツの移動は、ＳｏｕｒｃｅデバイスはＳｉｎｋに送信済みのコンテンツを消去する伝送方法である。移動処理が不意の中断した場合などにコンテンツが消失するおそれがある。コンテンツの移動時に消失を防止する技術について、既に幾つか提案がなされている（例えば、特許文献１を参照のこと）。
【０１４８】
世代制限付きのコンテンツ移動も、コンテンツの消失が起きないように、この機能に対応した装置間でのみ行なわれるべきである。このため、Ｓｏｕｒｃｅデバイスは、コンテンツ伝送フェーズ（ＳＥＱ７０４）でコンテンツの移動を開始する際に、Ｓｉｎｋデバイスが世代制限付きのコンテンツ移動に対応しているかどうかを確認する必要がある。
【０１４９】
Ｓｉｎｋデバイスが世代制限付きのコンテンツ移動対応を確認する第１の方法として、Ｓｉｎｋデバイスがコンテンツの移動要求（図１１中のＳＥＱ１１０１）の際に、自分が世代制限付きのコンテンツ移動に対応していることをＳｏｕｒｃｅデバイスに通知する方法が挙げられる。
【０１５０】
具体的には、Ｓｉｎｋデバイスは、コンテンツ移動用プロトコルのために用意されているＢＬＫＭｏｖｅ．ｄｔｃｐ．ｃｏｍヘッダー・フィールドの拡張版として、ＢＬＫＭｏｖｅ２．ｄｔｃｐ．ｃｏｍヘッダー・フィールドを用意して、このヘッダー内で世代制限付きのコンテンツ移動に対応していることをＳｏｕｒｃｅデバイスに伝えることが考えられる。
【０１５１】
これに対し、Ｓｏｕｒｃｅデバイスは、ＨＴＴＰ  ＧＥＴリクエストでＢＬＫＭｏｖｅ２．ｄｔｃｐ．ｃｏｍヘッダー・フィールドが使われていれば世代制限付きのコンテンツ移動を行なうが、ＢＬＫＭｏｖｅ２．ｄｔｃｐ．ｃｏｍヘッダー・フィールドが使われていなければ世代制限付きのコンテンツ移動を行なわない。
【０１５２】
図２２には、Ｓｏｕｒｃｅデバイスが上記の第１の方法を用いて世代制限付きで移動可能なコンテンツを移動するための処理手順をフローチャートの形式で示している。
【０１５３】
コンテンツ伝送フェーズ（ＳＥＱ７０４）で、ＳｉｎｋデバイスからのＨＴＴＰ  ＧＥＴリクエストのヘッダーを通信・制御部３０１で受信すると（ステップＳ２２０１のＹｅｓ）、コンテンツ提供部３０４は、そのヘッダーにＢＬＫＭｏｖｅ２．ｄｔｃｐ．ｃｏｍヘッダー・フィールドが含まれているかどうかをチェックする（ステップＳ２２０２）。
【０１５４】
ＨＴＴＰ  ＧＥＴリクエストのヘッダーにＢＬＫＭｏｖｅ２．ｄｔｃｐ．ｃｏｍヘッダー・フィールドが含まれない場合には（ステップＳＳ２２０２のＮｏ）、世代制限付きのコンテンツ移動以外のＨＴＴＰリクエストを受けたと判断されるので、コンテンツ提供部３０４は、その他のＨＴＴＰ処理を実行する（ステップＳ２２０６）。
【０１５５】
一方、ＨＴＴＰ  ＧＥＴリクエストのヘッダーにＢＬＫＭｏｖｅ２．ｄｔｃｐ．ｃｏｍヘッダー・フィールドが含まれている場合には（ステップＳＳ２２０２のＹｅｓ）、コンテンツ提供部３０４は、このＢＬＫＭｏｖｅ２．ｄｔｃｐ．ｃｏｍヘッダー・フィールドで指定されている移動用の共有鍵ラベルＫXM＿ｌａｂｅｌを持つ移動用共有鍵ＫXMが認証・鍵共有部３０６内に存在するかどうかをさらにチェックする（ステップＳ２２０３）。
【０１５６】
共有鍵ラベルＫXM＿ｌａｂｅｌを持つ共有鍵ＫXMが存在しないときには（ステップＳ２２０３のＮｏ）、世代制限付きのコンテンツを移動のために暗号化できないので、コンテンツ提供部３０４は、このＨＴＴＰセッションをエラー終了する（ステップＳ２２０７）。
【０１５７】
一方、共有鍵ラベルＫXM＿ｌａｂｅｌを持つ共有鍵ＫXMが存在するときには（ステップＳ２２０３のＹｅｓ）、コンテンツ提供部３０４は、ＨＴＴＰ伝送の対象すなわち移動要求されているコンテンツが世代制限付きで移動可能かどうかをさらにチェックする（ステップＳ２２０４）。
【０１５８】
コンテンツ提供部３０４は、例えば、コンテンツ記録部３０２内の要求されているコンテンツに対応付けられている世代制限付き移動の可否の情報や移動可能な世代数の情報を参照して、ステップＳ２２０４のチェックを行なう。コンテンツに対し、世代制限付き移動が不可で、移動可能な世代数が１以上といった情報の食い違いが生じた場合には、世代制限付き移動不可という情報を優先し、不用意なコンテンツの流通を抑制する。
【０１５９】
移動要求されているコンテンツが世代制限付きで移動可能な場合には（ステップＳ２２０４のＹｅｓ）、コンテンツ提供部３０４は、「世代制限付き移動可能」を意味するＥ−ＥＭＩの値（０１１１2）（図１４を参照のこと）を設定するとともに、ＤＴＣＰ＿ｄｅｓｃｒｉｐｔｏｒ、ＰＣＰ−ＵＲ、ＣＭＩなどに設けられたＭｏｖｅ＿ｃｏｕｎｔフィールドに移動可能な世代数を設定して、このコンテンツの移動を行なう（ステップＳ２２０５）。
【０１６０】
また、移動要求されているコンテンツが世代制限付きで移動できるものでない場合には（ステップＳ２２０４のＮｏ）、コンテンツ提供部３０４は、コンテンツを通常の移動は可能かどうかをさらにチェックする（ステップＳ２２０８）。
【０１６１】
通常の移動が可能な場合には（ステップＳ２２０８のＹｅｓ）、コンテンツ提供部３０４は、「Ｍｏｖｅ」に相当するＥ−ＥＭＩの値（図１４を参照のこと）を設定して、このコンテンツの移動を行なう（ステップＳ２２０９）。また、通常の移動もできないときには（ステップＳ２２０８のＮｏ）、コンテンツ提供部３０４は、このＨＴＴＰセッションをエラー終了する（ステップＳ２２０７）。
【０１６２】
また、Ｓｉｎｋデバイスが世代制限付きのコンテンツ移動対応を確認する第２の方法として、ＳｉｎｋデバイスがＭＯＶＥ−ＡＫＥ手続きの際に、自分が世代制限付きのコンテンツ移動に対応していることをＳｏｕｒｃｅデバイスに通知する方法が挙げられる。
【０１６３】
具体的には、Ｓｉｎｋデバイスは、ＭＯＶＥ−ＡＫＥ手続きの開始コマンドであるＭＶ＿ＩＮＩＴＩＡＴＥに代えて、世代制限付きで移動できることを示すＭＶ＿ＩＮＩＴＩＡＴＥ２を用意する方法が考えられる。
【０１６４】
ＳｉｎｋデバイスがＭＶ＿ＩＮＩＴＩＡＴＥ２コマンドを用いて当該プロトコルを開始するとき、ＳｏｕｒｃｅデバイスはＳｉｎｋデバイスが世代制限付きのコンテンツ移動に対応していることを認識することができ、後続のコンテンツ伝送フェーズ（ＳＥＱ７０４）では世代制限付きのコンテンツの移動を行なう。一方、ＳｉｎｋデバイスがＭＶ＿ＩＮＩＴＩＡＴＥコマンドを用いて当該プロトコルを開始するとき、Ｓｏｕｒｃｅデバイスは世代制限付きのコンテンツの移動を行なわない。そのため、Ｓｏｕｒｃｅデバイスは当該プロトコルで共有鍵ラベルＫXM＿ｌａｂｅｌを生成し、記憶する際に、当該プロトコルがＭＶ＿ＩＮＩＴＩＡＴＥ２とＭＶ＿ＩＮＩＴＩＡＴＥのどちらで開始したかを合わせて記憶するか、どちらで開始したかを共有鍵ラベルＫXM＿ｌａｂｅｌの値で判別できるようにする。例えば、ＭＶ＿ＩＮＩＴＩＡＴＥ２で開始した場合は値を偶数とし、その他の場合は奇数にするなどの方法が考えられる。
【０１６５】
図２３には、Ｓｏｕｒｃｅデバイスが上記の第２の方法を用いて世代制限付きで移動可能なコンテンツを移動するための処理手順をフローチャートの形式で示している。
【０１６６】
コンテンツ伝送フェーズ（ＳＥＱ７０４）で、ＳｉｎｋデバイスからのＨＴＴＰ  ＧＥＴリクエストのヘッダーを通信・制御部３０１で受信すると（ステップＳ２３０１のＹｅｓ）、コンテンツ提供部３０４は、そのヘッダーにＢＬＫＭｏｖｅ．ｄｔｃｐ．ｃｏｍヘッダー・フィールドが含まれているかどうかをチェックする（ステップＳ２３０２）。
【０１６７】
ＨＴＴＰ  ＧＥＴリクエストのヘッダーにＢＬＫＭｏｖｅ．ｄｔｃｐ．ｃｏｍヘッダー・フィールドが含まれない場合には（ステップＳＳ２３０２のＮｏ）、コンテンツ移動以外のＨＴＴＰリクエストを受けたと判断されるので、コンテンツ提供部３０４は、その他のＨＴＴＰ処理を実行する（ステップＳ２３０７）。
【０１６８】
一方、ＨＴＴＰ  ＧＥＴリクエストのヘッダーにＢＬＫＭｏｖｅ．ｄｔｃｐ．ｃｏｍヘッダー・フィールドが含まれている場合には（ステップＳＳ２３０２のＹｅｓ）、コンテンツ提供部３０４は、このＢＬＫＭｏｖｅ．ｄｔｃｐ．ｃｏｍヘッダー・フィールドで指定されている移動用の共有鍵ラベルＫXM＿ｌａｂｅｌを持つ移動用共有鍵ＫXMが認証・鍵共有部３０６内に存在するかどうかをさらにチェックする（ステップＳ２３０３）。
【０１６９】
共有鍵ラベルＫXM＿ｌａｂｅｌを持つ共有鍵ＫXMが存在しないときには（ステップＳ２３０３のＮｏ）、世代制限付きのコンテンツを移動のために暗号化できないので、コンテンツ提供部３０４は、このＨＴＴＰセッションをエラー終了する（ステップＳ２３０８）。
【０１７０】
一方、共有鍵ラベルＫXM＿ｌａｂｅｌを持つ共有鍵ＫXMが存在するときには（ステップＳ２３０３のＹｅｓ）、コンテンツ提供部３０４は、この共有鍵ラベルＫXM＿ｌａｂｅｌがＭＶ＿ＩＮＩＴＩＡＴＥ２による処理で得られたものかどうかをさらにチェックする（ステップＳ２３０４）。そして、共有鍵ラベルＫXM＿ｌａｂｅｌがＭＶ＿ＩＮＩＴＩＡＴＥ２による処理のものであれば（ステップＳ２３０４のＹｅｓ）、コンテンツ提供部３０４は、ＨＴＴＰ伝送の対象すなわち移動要求されているコンテンツが世代制限付きで移動可能かどうかをチェックする（ステップＳ２３０５）。
【０１７１】
移動要求されているコンテンツが世代制限付きで移動可能な場合には（ステップＳ２３０５のＹｅｓ）、コンテンツ提供部３０４は、「世代制限付き移動可能」を意味するＥ−ＥＭＩの値（０１１１2）（図１４を参照のこと）を設定するとともに、ＤＴＣＰ＿ｄｅｓｃｒｉｐｔｏｒ、ＰＣＰ−ＵＲ、ＣＭＩなどに設けられたＭｏｖｅ＿ｃｏｕｎｔフィールドに移動可能な世代数を設定して、このコンテンツの移動を行なう（ステップＳ２３０６）。
【０１７２】
また、共有鍵ラベルＫXM＿ｌａｂｅｌがＭＶ＿ＩＮＩＴＩＡＴＥ２による処理のものでない場合（ステップＳ２３０４のＮｏ）、又は、移動要求されているコンテンツが世代制限付きで移動できるものでない場合には（ステップＳ２３０５のＮｏ）、コンテンツ提供部３０４は、コンテンツを通常の移動は可能かどうかをさらにチェックする（ステップＳ２３０９）。
【０１７３】
通常の移動が可能な場合には（ステップＳ２３０９のＹｅｓ）、コンテンツ提供部３０４は、「Ｍｏｖｅ」に相当するＥ−ＥＭＩの値（図１４を参照のこと）を設定して、このコンテンツの移動を行なう（ステップＳ２３１０）。また、通常の移動もできないときには（ステップＳ２２０８のＮｏ）、コンテンツ提供部３０４は、このＨＴＴＰセッションをエラー終了する（ステップＳ２３０８）。
【０１７４】
移動可能な世代数が制限されたコンテンツの場合、私的利用の範囲を超えた利用を防ぐ効果を高めるために、移動した後のコンテンツの伝送可能範囲を制限する運用も考えられる。
【０１７５】
例えば、ＤＴＣＰ−ＩＰ仕様には、Ｒｅｍｏｔｅ  Ａｃｃｅｓｓという、屋外の装置（Ｓｉｎｋデバイス）から家庭内の装置（Ｓｏｕｒｃｅデバイス）にあるコンテンツを利用する機能が規定されている。移動可能な世代数が制限されたコンテンツについては、移動した後のコンテンツへのＲｅｍｏｔｅ  Ａｃｃｅｓｓを禁止するといった運用が、伝送可能範囲を制限する１つの具体例として挙げられる。
【０１７６】
ここで、Ｒｅｍｏｔｅ  Ａｃｃｅｓｓでの送信禁止ということを実現する方法としては、例えば以下の２つが考えられる。
【０１７７】
（１）Ｓｉｎｋデバイスが世代制限付きで受信したコンテンツの移動可能な世代数Ｍｏｖｅ＿ｃｏｕｎｔを１だけデクリメントした結果、その値がゼロになったらＲｅｍｏｔｅ  Ａｃｃｅｓｓでの送信を不可にする。なお、ＳｉｎｋデバイスがＭｏｖｅ＿ｃｏｕｎｔを検出できない場合もＲｅｍｏｔｅ  Ａｃｃｅｓｓでの送信を不可にする。
（２）Ｓｉｎｋデバイスがコンテンツの移動可能な世代数Ｍｏｖｅ＿ｃｏｕｎｔを１だけデクリメントする際に、そのコンテンツが移動済みであることをコンテンツと対応付けて記憶しておく。そして、以後の送信において、移動済みコンテンツはＲｅｍｏｔｅ  Ａｃｃｅｓｓでの送信を不可にする。
【０１７８】
また、Ｒｅｍｏｔｅ  Ａｃｃｅｓｓにおけるコンテンツの移動は常に１世代のみ可として、コンテンツ移動による伝送可能範囲を制限することによっても、私的利用範囲を超えた利用を防ぐ効果を高めることができる。このような移動可能な世代数の制限は、よりシンプルに実現することができる。例えば、Ｒｅｍｏｔｅ  Ａｃｃｅｓｓによるコンテンツ移動時には、Ｓｏｕｒｃｅデバイスは、移動用の共有鍵ＫXMから計算した暗号鍵ではなく、Ｒｅｍｏｔｅ  Ａｃｃｅｓｓによるコンテンツ移動の処理専用の計算方法で得た暗号鍵を用いて暗号化伝送し、Ｓｉｎｋデバイス側でも同様にこの処理専用の計算方法で得た暗号鍵を用いて受信コンテンツを復号する。そして、Ｓｉｎｋデバイスは、Ｒｅｍｏｔｅ  Ａｃｃｅｓｓで受け取ったコンテンツのさらなる移動は自主的に禁止とする。
【０１７９】
Ｒｅｍｏｔｅ  Ａｃｃｅｓｓによるコンテンツ移動時に専用の暗号鍵の計算方法として、ＭＯＶＥ−ＡＫＥ手続きで得た移動用の共有鍵ＫXMの代わりに、Ｒｅｍｏｔｅ  Ａｃｃｅｓｓ用のＲＴＴ−ＡＫＥ手続きで得た共有鍵ＫRを暗号鍵ＫCの計算に用いる方法が挙げられる。さらには、移動用の共有鍵ＫXMをハッシュ関数で処理して暗号鍵の計算に用いる方法や、移動用の共有鍵ＫXMとＲｅｍｏｔｅ  Ａｃｃｅｓｓ用の共有鍵ＫRのＸＯＲ（排他的論理和）などの権利演算結果を暗号鍵の計算に用いる方法なども考えられる。
【０１８０】
上記の方法は、Ｅ−ＥＭＩフィールドの未定義の値に「世代制限付き移動可」を意味する値を追加定義したり、ＤＴＣＰ＿ｄｅｓｃｒｉｐｔｏｒ、ＰＣＰ−ＵＲ、ＣＭＩなどを使って移動可能な世代数を伝えたりする必要はなく、シンプルである。Ｅ−ＥＭＩには、現状のＭｏｄｅ  Ｃ１（図１３を参照のこと）をそのまま使用すればよい。
【先行技術文献】
【特許文献】
【０１８１】
【特許文献１】特開２０１０−２３１７８７号公報
【産業上の利用可能性】
【０１８２】
以上、特定の実施形態を参照しながら、本明細書で開示する技術について詳細に説明してきた。しかしながら、本明細書で開示する技術の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
【０１８３】
本明細書では、本明細書で開示する技術をＤＴＣＰ並びにＤＴＣＰ−ＩＰ仕様のネットワークに適用した実施形態を中心に説明してきたが、本明細書で開示する技術の要旨はこれに限定されるものではない。ＤＴＣＰ若しくはＤＴＣＰ−ＩＰ以外の技術仕様に基づくネットワーク上の機器間でコンテンツの移動を行なうコンテンツ伝送システムにも、同様に本明細書で開示する技術で開示する技術を適用して、移動可能な世代数制御によってコンテンツの流通範囲を制限することができる。
【０１８４】
また、本明細書では、それぞれ独立した装置として構成されるＳｏｕｒｃｅデバイスとＳｉｎｋデバイス間でＤＴＣＰ若しくはＤＴＣＰ−ＩＰ規格に従ってコンテンツを移動する実施形態を中心に説明してきたが、その変形例として、１つの装置内で２つの記録部（例えば、パーソナル・コンピューターなどの情報機器内に内蔵されるハード・ディスク・ドライブ並びにメモリーカード）の間でコンテンツの移動を行なう場合にも、同様に本明細書で開示する技術を適用することができる。
【０１８５】
要するに、例示という形態により本明細書で開示する技術について説明してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本明細書で開示する技術の要旨を判断するためには、特許請求の範囲を参酌すべきである。
【０１８６】
なお、本明細書の開示の技術は、以下のような構成をとることも可能である。
（１）コンテンツ記録部に記録されたコンテンツを移動に関する制御情報付きで送信するとともに、送信済みのコンテンツを前記コンテンツ記録部から削除して、コンテンツの移動を実施するコンテンツ送信装置と、
前記コンテンツ送信装置から送信されたコンテンツを受信するコンテンツ受信装置と、
を具備するコンテンツ伝送システム。
（２）前記移動に関する制御情報は、コンテンツの移動の世代制限に関する情報を含む、
上記（１）に記載のコンテンツ伝送システム。
（３）前記移動に関する制御情報は、コンテンツの世代制限付き移動の可否に関する情報を含む、
上記（１）に記載のコンテンツ伝送システム。
（４）前記移動に関する制御情報は、移動可能な世代数に関する情報をさらに含む、
上記（３）に記載のコンテンツ伝送システム。
（５）前記コンテンツ送信装置及び前記コンテンツ受信装置は、所定の伝送規格に従って相互認証及び共有鍵の交換を行ない、前記共有鍵から計算される暗号鍵を用いて暗号化したコンテンツの移動を実施する、
上記（１）に記載のコンテンツ伝送システム。
（６）前記所定の伝送規格は、ＤＴＣＰ（Ｄｉｇｉｔａｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ）若しくはＤＴＣＰ−ＩＰ（ＤＴＣＰ  ｍａｐｐｉｎｇ  ｔｏ  ＩＰ）である、
上記（５）に記載のコンテンツ伝送システム。
（７）前記コンテンツ送信装置は、ＤＴＣＰ−ＩＰ規格に従ってＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）メッセージにより前記コンテンツ受信装置へコンテンツを伝送する際に、Ｅ−ＥＭＩ（Ｅｘｔｅｎｄｅｄ  Ｅｎｃｒｉｐｔｉｏｎ  Ｍｏｄｅ  Ｉｎｄｉｃａｔｏｒ）に「世代制限付き移動可」を意味する値を付加して、当該コンテンツの世代制限付き移動の可否に関する情報を通知し、
前記コンテンツ受信装置は、前記コンテンツ送信装置からコンテンツを受信する際に、Ｅ−ＥＭＩの値に基づいて当該コンテンツが世代制限付き移動可か否かをチェックする、
上記（３）に記載のコンテンツ伝送システム。
（８）前記コンテンツ送信装置は、ＤＴＣＰ＿ｄｅｓｃｒｉｐｔｏｒのＭｏｖｅ＿ｃｏｕｎｔフィールドに移動可能な世代数を記載して、移動可能な世代数に関する情報をさらに通知する、
上記（７）に記載のコンテンツ伝送システム。
（９）前記コンテンツ送信装置は、ＰＣＰ−ＵＲ（Ｐｒｏｔｅｃｔｅｄ  Ｃｏｎｔｅｎｔ  Ｐａｃｋｅｔ−Ｕｓａｇｅ  Ｒｕｌｅ）のＭｏｖｅ＿ｃｏｕｎｔフィールドに移動可能な世代数を記載して、移動可能な世代数に関する情報をさらに通知する、
上記（７）に記載のコンテンツ伝送システム。
（１０）前記コンテンツ送信装置は、前記コンテンツ送信装置は、ＣＭＩ  ｄｅｓｃｒｉｐｔｏｒのＭｏｖｅ＿ｃｏｕｎｔフィールドに移動可能な世代数を記載して、移動可能な世代数に関する情報をさらに通知する、
上記（７）に記載のコンテンツ伝送システム。
（１１）前記コンテンツ受信装置は、前記コンテンツ送信装置から世代制限付き移動により取得したコンテンツの移動可能な世代数を１だけ減算する、
上記（４）、（８）乃至（１０）のいずれかに記載のコンテンツ伝送システム。
（１２）前記コンテンツ受信装置は、前記コンテンツ送信装置から世代制限付き移動により取得したコンテンツについての移動可能な世代数に関する情報を検出できないときは、当該コンテンツの更なる移動を不可にする、
上記（４）、（８）乃至（１０）のいずれかに記載のコンテンツ伝送システム。
（１３）前記コンテンツ受信装置は、更なる移動が不可のコンテンツを次にＤＴＣＰ−ＩＰで送信する際には、そのＥ−ＥＭＩに記録の禁止を意味する値を用いる、
上記（７）に記載のコンテンツ伝送システム。
（１４）前記コンテンツ受信装置は、記録禁止で且つ１以上の移動可能な世代数が付与されたコンテンツについては、移動可能な世代数に拘らず、記録を不可にする、
上記（４）に記載のコンテンツ伝送システム。
（１５）前記コンテンツ送信装置は、コンテンツの移動を要求した前記コンテンツ受信装置が世代制限付きのコンテンツ移動に対応しているか否かを確認した後に、コンテンツの世代制限付き移動を行なう、
上記（１）に記載のコンテンツ伝送システム。
（１６）前記コンテンツ受信装置は、ＤＴＣＰ−ＩＰ規格に従ってＨＴＴＰリクエストによりコンテンツの移動を要求する際に、ＢＬＫＭｏｖｅ２．ｄｔｃｐ．ｃｏｍヘッダー・フィールドを用いて、世代制限付きのコンテンツ移動に対応していることを前記コンテンツ送信装置に伝える、
上記（１５）に記載のコンテンツ伝送システム。
（１７）前記コンテンツ受信装置は、ＤＴＣＰ−ＩＰ規格に従ってＭＯＶＥ−ＡＫＥ手続きを開始するコマンドＭＶ＿ＩＮＩＴＩＡＴＥを世代制限付きで移動できることを示すＭＶ＿ＩＮＩＴＩＡＴＥ２に代えることにより、世代制限付きのコンテンツ移動に対応していることを前記コンテンツ送信装置に伝える、
上記（１５）に記載のコンテンツ伝送システム。
（１８）前記コンテンツ受信装置は、移動可能な世代数を１だけ減算した結果世代数が０になったコンテンツのリモート・アクセスによる送信を不可にする、
上記（１１）に記載のコンテンツ伝送システム。
（１９）前記コンテンツ受信装置は、移動可能な世代数を検出できない場合にコンテンツのリモート・アクセスによる送信を不可にする、
上記（１１）に記載のコンテンツ伝送システム。
（２０）前記コンテンツ受信装置は、移動可能な世代数を１だけ減算する際にそのコンテンツが移動済みであることを対応付けて記憶し、移動済みのコンテンツのリモート・アクセスによる送信を不可にする、
上記（１１）に記載のコンテンツ伝送システム。
（２１）前記コンテンツ送信装置及び前記コンテンツ受信装置は、リモート・アクセスによりコンテンツの移動を行なうときには、移動用の共有鍵から計算した暗号鍵に代えて、リモート・アクセスによるコンテンツ移動の処理専用の計算方法で得た暗号鍵を用いて暗号化伝送する、
上記（６）に記載のコンテンツ伝送システム。
【符号の説明】
【０１８７】
１００…コンテンツ伝送システム
１０１…サーバー、１０２、１０３…端末、１１０…ホーム・ネットワーク
２００…コンテンツ伝送システム
２０１…サーバー、２０２、２０３…端末
２１０…ホーム・ネットワーク、２２０…外部ネットワーク
２３０…ルーター
３００…コンテンツ送信装置（Ｓｏｕｒｃｅデバイス）
３０１…通信・制御部、３０２…コンテンツ記録部
３０３…コンテンツ取得部、３０４…コンテンツ提供部
３０５…コンテンツ・リスト提供部、３０６…認証・鍵共有部
３０７…端末管理部、３０８…コンテンツ再生出力部
４００…コンテンツ受信装置
４０１…通信・制御部
４０２…コンテンツ・リスト閲覧部、４０３…コンテンツ取得部
４０４…コンテンツ復号部、４０５…コンテンツ再生出力部
４０６…認証・鍵共有部、４０７…入力部、４０８…コンテンツ記録部
２４００…コンピューター・プログラム配信システム
２４１０…サーバー、２４１１…記憶装置
２４１２…通信装置、２４１３…情報通知装置
【図１】
2015014979.tif 000003
【図２】
2015014979.tif 000004
【図３】
2015014979.tif 000005
【図４】
2015014979.tif 000006
【図７】
2015014979.tif 000007
【図８】
2015014979.tif 000008
【図９】
2015014979.tif 000009
【図１０】
2015014979.tif 000010
【図１１】
2015014979.tif 000011
【図１２】
2015014979.tif 000012
【図１３】
2015014979.tif 000013
【図１６】
2015014979.tif 000014
【図１７】
2015014979.tif 000015
【図１８】
2015014979.tif 000016
【図１９】
2015014979.tif 000017
【図２０】
2015014979.tif 000018
【図２１】
2015014979.tif 000019
【図２２】
2015014979.tif 000020
【図２３】
2015014979.tif 000021
【図２４】
2015014979.tif 000022
【図５】
2015014979.tif 000023
【図６】
2015014979.tif 000024
【図１４】
2015014979.tif 000025
【図１５】
2015014979.tif 000026