JP2015082681A - コンテンツ受信装置及びコンテンツ受信方法、並びにコンピューター・プログラム - Google Patents

Abstract

【課題】家庭内で蓄積したコンテンツを外部ネットワーク経由で伝送する際に、私的利用の範囲を超えた利用を抑制する。【解決手段】サーバーは、端末をリモート・アクセスのために登録を行なう際に再生可能時間を付与する。サーバーは、端末にコンテンツのストリーム伝送を行なう際、伝送した時間だけ再生可能時間を減らし、残りの再生可能時間がゼロになったらそれ以上の伝送ができないようにする。また、サーバーは、端末にコンテンツの移動を行なう際、そのコンテンツの長さを再生可能時間から差し引き、残りの再生可能時間がゼロになったらそれ以上伝送できないようにする。【選択図】 図１

Description

本明細書で開示する技術は、他の装置からコンテンツを受信するコンテンツ受信装置及びコンテンツ受信方法、並びにコンピューター・プログラムに係り、例えばＤＴＣＰなどの所定の相互認証及び鍵交換（ＡＫＥ）アルゴリズムに従って共有した鍵を用いて暗号化伝送されたコンテンツを受信するコンテンツ受信装置及びコンテンツ受信方法、並びにコンピューター・プログラムに関する。

ディジタル化されたコンテンツはコピーや改竄などの不正な操作が比較的容易である。とりわけ、リモート・アクセスにおいては、個人的又は家庭的なコンテンツの使用を許容しながら、コンテンツ伝送に介在する不正利用の防止、すなわち著作権保護の仕組みが必要である。ディジタル・コンテンツの伝送保護に関する業界標準的な技術として、ＤＴＬＡ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｌｉｃｅｎｓｉｎｇ Ａｄｍｉｎｉｓｔｒａｔｏｒ）が開発したＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）が挙げられる。

ＤＴＣＰでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決められている。その規定は、要約すれば、ＤＴＣＰ準拠機器は取り扱いが容易な圧縮コンテンツを非暗号の状態で機器外に送出しないことと、暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ：ＡＫＥ）アルゴリズムに従って行なうこと、並びにＡＫＥコマンドにより鍵交換を行なう機器の範囲を制限することなどである。

ＤＴＣＰは、原初的には、ＩＥＥＥ１３９４などを伝送路に用いたホーム・ネットワーク上におけるコンテンツ伝送について規定したものである。最近では、ＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）に代表されるように、家庭内に蓄積したディジタル・コンテンツをＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワーク経由で流通させようという動きが本格的になっている。そこで、ＤＴＣＰ技術をＩＰネットワークに移植した、ＤＴＣＰ−ＩＰ（ＤＴＣＰ ｍａｐｐｉｎｇ ｔｏ ＩＰ）の開発が進められている。

例えば、ホーム・サーバーに蓄積された放送コンテンツや映画などの商用コンテンツを、携帯電話や多機能端末などのモバイルＳｉｎｋ機器を使って遠隔地から視聴する場合、私的利用の範囲を超えて利用されないように制御することが望まれている。

現在のＤＴＣＰ−ＩＰ（ＤＴＣＰ−ＩＰ Ｖｏｌｕｍｅ １ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｒｅｖｉｓｉｏｎ １．４）では、第三者によるコンテンツの利用を制限することを意図して、家庭内のサーバーへのリモート・アクセスを、そのサーバーに登録した端末だけに限定している。また、端末を家庭内のサーバーに登録する際において、コマンドの往復遅延時間（ＲＴＴ：Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）を最大７ミリ秒に制限するとともに、ＩＰルーターのホップ回数の上限が課されている。

例えば、リモート・アクセス時におけるＡＫＥ手続きにおいて、上記のＲＴＴ並びにＴＴＬの制限を解除してリモート・アクセス用の鍵共有を可能にする一方、リモート・アクセスする端末のサーバーへの事前登録、コンテンツのリモート・アクセス利用数制限、鍵供給数制限を課して、不特定多数のユーザーからのリモート・アクセスを制限するようにしたコンテンツ伝送システムについて、提案がなされている（例えば、特許文献１を参照のこと）。

しかしながら、現在のＤＴＣＰ−ＩＰ規格によると、端末の家庭内のサーバーへの登録は一度だけ行なえば、以後は再び登録を行なわずに、リモート・アクセスによりホーム・サーバー内のコンテンツを永続的に利用することができる。このため、第三者の端末をサーバーに一度登録すれば、以後はその第三者がホーム・サーバー内のコンテンツを永続的に利用できてしまうという問題がある。

特開２０１１−８２９５２号公報

本明細書で開示する技術の目的は、ＤＴＣＰなどの所定の相互認証及び鍵交換アルゴリズムに従いつつ、適切な利用範囲内で、家庭内で蓄積したコンテンツを外部ネットワーク経由で受信することができる、優れたコンテンツ受信装置及びコンテンツ受信方法、並びにコンピューター・プログラムを提供することにある。

本願は、上記課題を参酌してなされたものであり、請求項１に記載の技術は、
サーバーが付与した再生可能時間の範囲内で前記サーバーからコンテンツを受信するコンテンツ取得部と、
コンテンツを再生するコンテンツ再生出力部と、
を具備するコンテンツ受信装置である。

本願の請求項２に記載の技術によれば、請求項１に記載のコンテンツ受信装置は、所定の相互認証及び鍵交換手続きに従って端末を認証するとともに交換鍵を共有する認証及び鍵共有部と、前記コンテンツ取得部が前記サーバーから取得した暗号化コンテンツを、前記交換鍵を用いて復号するコンテンツ復号部をさらに備えている。

本願の請求項３に記載の技術によれば、請求項２に記載のコンテンツ受信装置の前記認証及び鍵共有部は、ＤＴＣＰ−ＩＰが規定する認証及び鍵交換（ＡＫＥ）アルゴリズムに従ってサーバーと相互認証並びに交換鍵の共有を行なうとともに、ＤＴＣＰ−ＩＰが規定する手続きに従って前記サーバーに登録する際に再生可能時間が付与されるように構成されている。

本願の請求項４に記載の技術によれば、請求項１に記載のコンテンツ受信装置の前記認証及び鍵共有部は、ホーム・ネットワーク内でサーバーに登録し、前記コンテンツ取得部は、登録が済んだサーバーから、外部ネットワーク経由でコンテンツを取得するように構成されている。

本願の請求項５に記載の技術によれば、請求項４に記載のコンテンツ受信装置は、前記認証及び鍵共有部がサーバーに登録する際に、前記サーバーから再生可能時間の初期値が付与されるように構成されている。

本願の請求項６に記載の技術によれば、請求項５に記載のコンテンツ受信装置は、前記認証及び鍵共有部がサーバーに再登録することにより、再生可能時間が初期値にリセットされるように構成されている。

本願の請求項７に記載の技術によれば、請求項４に記載のコンテンツ受信装置の前記コンテンツ取得部は、再生可能時間がゼロになるまで、コンテンツの受信が許可されるように構成されている。

本願の請求項８に記載の技術によれば、請求項７に記載のコンテンツ受信装置は、前記コンテンツ取得部がコンテンツの受信を終了又は停止したときに、再生可能時間から受信したコンテンツの再生時間が引かれるように構成されている。

本願の請求項９に記載の技術によれば、請求項４に記載のコンテンツ受信装置の前記コンテンツ取得部は、再生可能時間より短いコンテンツを、再生可能時間からコンテンツの長さが引かれた後に、受信するように構成されている。

本願の請求項１０に記載の技術によれば、請求項９に記載のコンテンツ受信装置は、前記コンテンツ取得部がコンテンツの受信を終了又は停止したときに、コンテンツの長さから受信したコンテンツの再生時間を引いた値が再生可能時間に足されるように構成されている。

本願の請求項１１に記載の技術によれば、請求項４に記載のコンテンツ受信装置の前記コンテンツ取得部は、再生可能時間より短いコンテンツの移動を許可されるように構成されている。

本願の請求項１２に記載の技術によれば、請求項１１に記載のコンテンツ受信装置は、前記コンテンツ取得部が移動により受信したコンテンツの長さが再生可能時間から引かれるように構成されている。

本願の請求項１３に記載の技術によれば、請求項４に記載のコンテンツ受信装置は、再生可能時間がゼロになると、サーバーの登録が削除されるように構成されている。

本願の請求項１４に記載の技術によれば、請求項１に記載のコンテンツ受信装置は、表示部をさらに備えている。そして、コンテンツ取得部がサーバーからコンテンツを受信する際に、再生可能時間の情報を受け取り、前記表示部に表示するように構成されている。

本願の請求項１５に記載の技術によれば、請求項１に記載のコンテンツ受信装置は、サーバーから取得可能なコンテンツに関する情報を前記サーバーから取得するコンテンツ情報取得部をさらに備えている。そして、コンテンツ取得部は、閲覧しているコンテンツ情報を介して前記サーバーにコンテンツを要求するように構成されている。

本願の請求項１６に記載の技術によれば、請求項１５に記載のコンテンツ受信装置の前記コンテンツ情報取得部は、現在の再生可能時間に基づいてコンテンツ情報の取得が制限されるように構成されている。

本願の請求項１７に記載の技術によれば、請求項１５に記載のコンテンツ受信装置の前記コンテンツ情報取得部は、現在の再生可能時間よりも短いコンテンツのみコンテンツ情報を取得できるように構成されている。

本願の請求項１８に記載の技術によれば、請求項１５に記載のコンテンツ受信装置の前記コンテンツ情報取得部は、再生可能時間がゼロになると、コンテンツ情報を取得できなくなるように構成されている。

また、本願の請求項１９に記載の技術は、
サーバーに付与された再生可能時間の範囲内で前記サーバーからコンテンツを受信するコンテンツ取得ステップと、
取得したコンテンツを再生するコンテンツ再生出力ステップと、
を有するコンテンツ受信方法である。

また、本願の請求項２０に記載の技術は、
サーバーに付与された再生可能時間の範囲内で前記サーバーからコンテンツを受信するコンテンツ取得部、
取得したコンテンツを再生するコンテンツ再生出力部、
としてコンピューターを機能させるようにコンピューター可読形式で記述されたコンピューター・プログラムである。

本願の請求項２０に係るコンピューター・プログラムは、コンピューター上で所定の処理を実現するようにコンピューター可読形式で記述されたコンピューター・プログラムを定義したものである。換言すれば、本願の請求項２０に係るコンピューター・プログラムをコンピューターにインストールすることによって、コンピューター上では協働的作用が発揮され、本願の請求項１に係るコンテンツ受信装置と同様の作用効果を得ることができる。

本明細書で開示する技術によれば、ＤＴＣＰなどの所定の相互認証及び鍵交換アルゴリズムに従いつつ、適切な利用範囲内で、家庭内で蓄積したコンテンツを外部ネットワーク経由で受信することができる、優れたコンテンツ受信装置及びコンテンツ受信方法、並びにコンピューター・プログラムを提供することができる。

本明細書で開示する技術によれば、Ｓｏｕｒｃｅとして機能するコンテンツ送信装置は、リモート・アクセスするＳｉｎｋに所定の再生可能時間を付与し、リモート・アクセス時に提供するコンテンツを再生可能時間内に制限することにより、コンテンツが遠隔地でも永続的に視聴されるというコンテンツ提供業者のデメリットを解決することができる。

なお、本明細書に記載された効果は、あくまでも例示であり、本発明の効果はこれに限定されるものではない。また、本発明が、上記の効果以外に、さらに付加的な効果を奏する場合もある。

本明細書で開示する技術のさらに他の目的、特徴や利点は、後述する実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。

図１は、本明細書で開示する技術を適用したコンテンツ伝送システム１００の構成例を模式的に示した図である。 図２は、本明細書で開示する技術を適用したコンテンツ伝送システム２００の他の構成例を模式的に示した図である。 図３は、図１並びに図２において、サーバー１０１、２０１として動作するコンテンツ送信装置３００の機能的構成を模式的に示した図である。 図４は、図１並びに図２において、端末１０２、２０２として動作するコンテンツ受信装置４００の機能的構成を模式的に示した図である。 図５は、リモート・アクセスを行なうＳｉｎｋデバイスを、再生可能時間とともにＳｏｕｒｃｅデバイスに登録する手順を示した図である。 図６は、ＳｏｕｒｃｅデバイスがＳｉｎｋ−ＩＤと再生可能時間をペアにしたＳｉｎｋデバイスの登録を行なうための処理手順を示したフローチャートである。 図７は、Ｓｉｎｋ−ＩＤと再生可能時間をペアにして格納したｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙの登録内容を例示した図である 図８は、ＳｏｕｒｃｅデバイスとＳｉｎｋデバイス間でリモート・アクセスによるコンテンツ伝送を行なう手順を模式的に示した図である。 図９は、コンテンツ・リスト閲覧フェーズ（ＳＥＱ８０１）の中身を模式的に示した図である。 図１０は、ＲＡ−ＡＫＥ手続きフェーズ（ＳＥＱ８０２）の中身の詳細を示した図である。 図１１は、Ｓｉｎｋデバイスに対して生成したリモート・アクセス用交換鍵Ｋ_R及びその交換鍵ラベルＫ_R＿ｌａｂｅｌをＳｉｎｋ−ＩＤと対応付けてＲＡＣ ｒｅｃｏｒｄとして記憶する様子を示した図である。 図１２は、ｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙのメンテナンス処理の手順を示したフローチャートである。 図１３は、リモート・アクセス用交換鍵Ｋ_Rを用いて暗号化伝送するコンテンツ伝送フェーズ（ＳＥＱ８０３）の中身を模式的に示した図である。 図１４は、ストリーミング時においてＳＥＱ１３０２で実施するコンテンツ出力管理処理の手順を示したフローチャートである。 図１５は、ストリーミング時においてＳＥＱ１３０４で実施するコンテンツ出力制御及び再生可能時間管理処理の手順を示したフローチャートである。 図１６は、ストリーミング時においてＳＥＱ１３０２で実施するコンテンツ出力管理処理の手順の変形例を示したフローチャートである。 図１７は、図１６に対応したコンテンツ出力制御及び再生可能時間管理処理の手順を示したフローチャートである。 図１８は、コンテンツ移動（ＭＯＶＥ）においてＳＥＱ１３０２で実施するコンテンツ出力管理処理の手順を示したフローチャートである。 図１９は、コンテンツ移動（ＭＯＶＥ）においてＳＥＱ１３０４で実施するコンテンツ出力制御及び再生可能時間管理処理の手順を示したフローチャートである。 図２０は、Ｓｏｕｒｃｅデバイスがリモート・アクセスするＳｉｎｋデバイスの限界日時に基づいてＣＤＳ情報の提供を制限するための処理手順を示したフローチャートである。 図２１は、コンテンツ伝送フェーズでＳｏｕｒｃｅデバイスがＳｉｎｋデバイスに再生可能時間を通知する仕組みを示した図である。 図２２は、Ｓｉｎｋデバイスが、Ｓｏｕｒｃｅデバイスから通知された再生可能時間を表示するための処理手順を示したフローチャートである。 図２３は、サーバー２０１若しくはＤＴＣＰのＳｏｕｒｃｅデバイスとして動作することが可能なパーソナル・コンピューター２４００の構成例を示した図である。 図２４は、サーバー２０１若しくはＤＴＣＰのＳｏｕｒｃｅデバイスとして動作することが可能なレコーダー２５００の構成例を示した図である。 図２５は、サーバー２０１若しくはＤＴＣＰのＳｏｕｒｃｅデバイスとして動作することが可能なネットワーク・アクセス・サーバー（ＮＡＳ）２６００の構成例を示した図である。 図２６は、コンピューター・プログラム配信システム２７００の構成を示した図である。

以下、図面を参照しながら本明細書で開示する技術の実施形態について詳細に説明する。

Ａ．システム構成
図１には、本明細書で開示する技術を適用したコンテンツ伝送システム１００の構成例を模式的に示している。図示のコンテンツ伝送システム１００は、家庭内に敷設されたホーム・ネットワーク１１０内に設置されたサーバー１０１と端末１０２で構成される。同図では、簡素化のため、サーバーと端末をそれぞれ１台ずつしか描いていないが、２台以上のサーバー並びに端末がホーム・ネットワーク上に設置されることも想定される。例えば、サーバーと端末はＤＬＮＡに規定されているプロトコルに従って動作することでコンテンツの伝送を行なうことが可能である。

サーバー１０１は、端末１０２にコンテンツを提供する装置である。サーバー１０１は、例えば、セットトップボックスやレコーダー、テレビジョン受信機、パーソナル・コンピューター、ネットワーク・アクセス・サーバー（ＮＡＳ）などである。サーバー１０１は、地上ディジタル放送で受信又は録画した放送コンテンツや、ブルーレイ・ディスクなどの記録媒体（図示しない）から読み込んだ映画などの商用コンテンツ、さらにはインターネット上のコンテンツ・サーバー（図示しない）から取得したコンテンツを端末１０２に提供する。コンテンツを提供する形態として、ストリーミングやコンテンツの移動（ＭＯＶＥ）が挙げられる。

端末１０２は、ホーム・ネットワーク１１０越しに、サーバー１０１にコンテンツを要求する装置であり、携帯電話やスマートフォン、タブレットなどの多機能携帯端末などに相当する。

本実施形態では、ホーム・ネットワーク１１０を介したサーバー１０１と端末１０２間のコンテンツ伝送には、ＤＴＣＰ技術が適用されている。したがって、端末１０２は、所定の相互認証及び鍵交換（ＡＫＥ）アルゴリズムに従って、サーバー１０１と相互認証するとともに鍵を共有した後に、サーバー１０１内に蓄積されたコンテンツを要求することができる。サーバー１０１は、要求されたコンテンツを、共有した鍵を用いて暗号化伝送する。コンテンツを提供するサーバー１０１はＤＴＣＰのＳｏｕｒｃｅデバイスに相当し、コンテンツを利用する端末１０２はＤＴＣＰのＳｉｎｋデバイスに相当する。

なお、端末１０２で外出先などホーム・ネットワーク１１０の外からサーバー１０１にアクセスしたいときには、ホーム・ネットワーク１１０内で端末１０２をサーバー１０１に事前に登録しておく必要がある。また、本実施形態では、サーバー１０１は、登録する端末１０２に対して、リモート・アクセス時に許容されるコンテンツの再生可能時間を付与するようになっているが、この点の詳細については後述に譲る。

また、図２には、本明細書で開示する技術を適用したコンテンツ伝送システム２００の他の構成例を模式的に示している。図示のコンテンツ伝送システム２００は、家庭内に敷設されたホーム・ネットワーク２１０内に設置されたサーバー２０１と、インターネットなどの外部ネットワーク２２０上に接続された端末２０２で構成される。ホーム・ネットワーク２１０と外部ネットワーク２２０は、ＩＰプロトコルに従い、ルーター２３０経由で相互接続されている。同図では、簡素化のため、サーバーと端末をそれぞれ１台ずつしか描いていないが、ホーム・ネットワーク２１０内に２台以上のサーバーが設置されることや、ホーム・ネットワーク２１０内にも端末が接続され、さらに外部ネットワーク２２０上に２台以上の端末が接続されることも想定される。

サーバー２０１は、セットトップボックスやレコーダー、テレビジョン受信機、パーソナル・コンピューター、ネットワーク・アクセス・サーバー（ＮＡＳ）などである。サーバー２０１、放送コンテンツや商用コンテンツなどを、外部ネットワーク２２０からリモート・アクセスする端末２０２に提供する）。コンテンツを提供する形態として、ストリーミングやコンテンツの移動（ＭＯＶＥ）が挙げられる。

端末２０２は、携帯電話やスマートフォン、タブレットなどの多機能携帯端末などであり、ホーム・ネットワーク２１０及び外部ネットワーク２２０からなるＩＰネットワーク越しに、サーバー２０１にコンテンツを要求する。

本実施形態では、ホーム・ネットワーク２１０及び外部ネットワーク２２０を介したサーバー２０１と端末２０２間のコンテンツ伝送には、ＤＴＣＰ−ＩＰ技術が適用されている。したがって、端末２０２は、ホーム・ネットワーク２１０内でサーバー２０１に事前に登録しておく必要がある（前述）。端末２０２は、ホーム・ネットワーク２１０及び外部ネットワーク２２０からなるＩＰネットワーク越しに、サーバー２０１と相互認証するとともに交換鍵を共有した後に、サーバー２０１内に蓄積されたコンテンツを要求することができる。サーバー２０１は、登録されている端末２０２から要求されたコンテンツを、共有した交換鍵を用いて暗号化伝送する。コンテンツを提供するサーバー２０１はＤＴＣＰのＳｏｕｒｃｅデバイスに相当し、コンテンツを利用する端末２０２はＤＴＣＰのＳｉｎｋデバイスに相当する。

本実施形態では、サーバー２０２は、事前に登録する端末２０２に対して、リモート・アクセス時に許容されるコンテンツの再生可能時間を付与するようになっている。また、サーバー２０１は、端末２０２がリモート・アクセスした際には、残りの再生可能時間に応じてコンテンツの提供を制限するが、この点の詳細については後述に譲る。

図３には、図１並びに図２において、サーバー１０１、２０１（すなわち、Ｓｏｕｒｃｅデバイス）として動作するコンテンツ送信装置３００の機能的構成を模式的に示している。サーバー１０１、２０１の具体例は、セットトップボックスやレコーダー、テレビジョン受信機、パーソナル・コンピューター、ネットワーク・アクセス・サーバー（ＮＡＳ）などである。

通信・制御部３０１は、ホーム・ネットワーク並びに外部ネットワークを介した通信動作を制御するとともに、当該コンテンツ送信装置３００全体の動作を統括的に制御する。また、通信・制御部３０１は、ＨＤＭＩ（登録商標）（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ）やＭＨＬ（登録商標）（Ｍｏｂｉｌｅ Ｈｉｇｈ‐Ｄｅｆｉｎｉｔｉｏｎ Ｌｉｎｋ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）などの外部機器接続用（若しくは、コンテンツのディジタル出力用）のインターフェースを備えており、ハード・ディスク装置やブルーレイ・ディスク装置などの録画再生機器を接続することができる。

コンテンツ記録部３０２は、ホーム・ネットワーク並びに外部ネットワーク越しで端末１０１、２０１に提供するコンテンツを記録する。コンテンツ記録部３０２に記録された各コンテンツは、一般的なファイル・システムの管理下で、記録日時やアクセス日時、長さ（ｄｕｒａｔｉｏｎ）が保持される。また、コンテンツ記録部３０２は、各コンテンツ、又はコンテンツ・グループのメタデータも記録する。

コンテンツ取得部３０３は、端末１０１、２０１に提供するコンテンツを取得し、必要に応じてコンテンツ記録部３０２に記録する。また、コンテンツ取得部３０３は、端末に提供するコンテンツをコンテンツ記録部３０２から取得することもある。

コンテンツ取得部３０３は、例えば地上ディジタル放送用チューナーなどからなり、放送コンテンツを取得する。この場合のコンテンツ取得部３０３は、例えばＡＲＩＢ（Ａｓｓｏｃｉａｔｉｏｎ ｏｆ Ｒａｄｉｏ Ｉｎｄｕｓｔｒｉｅｓ ａｎｄＢｕｓｉｎｅｓｓｅｓ：電波産業会）で規定される仕様に基づく。コンテンツ取得部３０３は、例えば、放送チャンネルの全セグメント又は一部のセグメントの受信機能、ＥＰＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅ）の機能（番組検索、番組情報の表示、番組予約）、ＨＤＣＰ（Ｈｉｇｈ−ｂａｎｄｗｉｄｔｈ Ｄｉｇｉｔａｌ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）仕様などに基づくコピー制御機能、放送コンテンツを限定受信したり受信した放送コンテンツを外部出力する際に暗号化したりするコンテンツ保護機能、などを備えている。

また、サーバー１０１、２０１がネットワーク・アクセス・サーバーの場合には、コンテンツ取得部３０３は、放送波を受信せず、レコーダーで録画したコンテンツや、メディア再生装置で再生するコンテンツを、ネットワーク経由で取得し、必要に応じてコンテンツ記録部３０２に記録する。

また、コンテンツ取得部３０３は、ブルーレイ・ディスクなどのメディア再生装置からなり、映画などの商用コンテンツをメディアから読み取る。また、コンテンツ取得部３０３は、ブラウザーなどからなり、インターネット上のコンテンツ・サーバー（図示しない）から有償又は無償のコンテンツをダウンロードする。

コンテンツ提供部３０４は、端末からの要求に応答して、コンテンツ取得部３０３が取得したコンテンツを端末に提供する。端末が外部ネットワーク上からのリモート・アクセスによりコンテンツを要求する場合、その端末は端末管理部３０７に事前に登録されたものでなければならない。コンテンツ提供部３０４は、例えばＨＴＴＰ（Ｈｙｐｅｔ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）プロトコルを利用して、端末へコンテンツを伝送する。コンテンツを提供する方法として、コンテンツのストリーミングやコンテンツの移動（ＭＯＶＥ）を挙げることができる。また、コンテンツ提供部３０４は、伝送するコンテンツを、認証・鍵共有部３０６により端末と共有した交換鍵を用いて暗号化する。

コンテンツ・リスト提供部３０５は、例えば端末からの要求に応答して、端末に提供可能なコンテンツのリストと詳細情報を、端末に提供する。上述からも分かるように、サーバー１０１、２０１が端末に提供可能なコンテンツは、コンテンツ取得部３０３が受信する放送コンテンツやメディアから読み出す商用コンテンツ、コンテンツ記録部３０２に既に記録されているコンテンツが挙げられる。コンテンツ・リストの提供には、例えば、ＤＬＮＡのベースとなるＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄＰｌａｙ）で策定されている、コンテンツのリストとコンテンツの詳細情報を階層化して配信するＣＤＳ（Ｃｏｎｔｅｎｔ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ）機能が適用される。

認証・鍵共有部３０６は、コンテンツの要求元となる端末との間で、ＤＴＣＰ−ＩＰが規定する認証及び鍵交換（ＡＫＥ）アルゴリズムに従って、相互認証並びにコンテンツ暗号化のための交換鍵の共有を行なう。認証・鍵共有部３０６は、外部ネットワークからリモート・アクセスによりコンテンツを要求してくる端末に対しては、リモート・アクセス用交換鍵Ｋ_Rを共有する（後述）。

端末管理部３０７は、コンテンツを要求する端末の情報を管理する。端末管理部３０７は、外部ネットワークからリモート・アクセスによりコンテンツを利用する端末に対して事前に登録の処理を行なうとともに、その端末の情報を「ｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙ」や「ＲＡＣ（Ｒｅｍｏｔｅ Ａｃｃｅｓｓ Ｃｏｎｎｅｃｔｉｏｎ） ｒｅｇｉｓｔｒｙ」として管理する。

本実施形態では、端末管理部３０７は、端末の登録を行なう際に、リモート・アクセス時に許容されるコンテンツの再生可能時間をその端末に付与し、端末の識別情報とペアにして管理する点に１つの特徴がある。そして、コンテンツ提供部３０４は、登録を済ませた端末がリモート・アクセスした際には、その端末の再生可能時間のアップデート（コンテンツの再生時間に応じた再生可能時間の減算）を行なうとともに、残りの再生可能時間に応じてコンテンツの提供を制限する。但し、この点の詳細については後述に譲る。

なお、上記の機能ブロック３０３〜３０７は、通信・制御部３０１において、オペレーティング・システムやＴＣＰ／ＩＰプロトコルの上位で実行するアプリケーション・プログラムとして実現することもできる。また、この種のアプリケーション・プログラムは、インターネットなどの広域ネットワーク上で所定のダウンロード・サイトで配信することができ、ディジタル放送チューナーやＴＶ受像機などのＣＥ（Ｃｏｎｓｕｍｅｒ Ｅｌｅｃｔｒｏｎｉｃｓ）機器、スマートフォンなどの多機能端末にダウンロードして利用に供される。

このようなダウンロード・サイトは、例えば、コンピューター・プログラムを記憶する記憶装置２７１１と、コンピューター・プログラムのダウンロード要求を受信したことに応じてそのダウンロードを認める通信装置２７１２とを備えたサーバー２７１０からなり（図２６を参照のこと）、ダウンロードしたコンピューター・プログラムをインストールするクライアント装置（ＤＴＣＰ＿Ｓｏｕｒｃｅ又はＤＴＣＰ＿Ｓｉｎｋ）と併せてコンピューター・プログラム配信システム２７００を構成する。この種のサーバーは、クライアントからのコンピューター・プログラムのダウンロード要求に対して、コンピューター・プログラムの名称を示す情報を通知する情報通知装置２７１３をさらに備えている。情報通知装置２７１３は、コンピューター・プログラムの名称とともに、例えば、家庭内に記録した商用コンテンツを遠隔地の端末に提供するアプリケーションであることを示す情報を通知する。

図４には、図１並びに図２において、端末１０２、２０２（すなわち、Ｓｉｎｋ）として動作するコンテンツ受信装置４００の機能的構成を模式的に示している。端末１０２、２０２の具体例は、携帯電話やスマートフォン、タブレットなどの多機能携帯端末などである。

通信・制御部４０１は、ホーム・ネットワーク並びに外部ネットワークを介した通信動作を制御するとともに、当該コンテンツ受信装置４００全体の動作を統括的に制御する。

コンテンツ・リスト閲覧部４０２は、Ｓｏｕｒｃｅとなるサーバー１０１、２０１に対して、コンテンツ・リストの取得要求を行ない、取得したコンテンツ・リストの閲覧画面を表示する。例えば、サーバー１０１、２０１が提供可能なコンテンツのリストをＣＤＳ情報（前述）として取得したときには、コンテンツ一覧画面が表示される。ユーザーはこの一覧画面を通して、再生出力したいコンテンツを選択することができる。

コンテンツ取得部４０３は、コンテンツの取得要求をサーバー１０１、２０１に送信して、サーバー内のコンテンツを取得する。コンテンツ取得部４０３は、例えば、コンテンツ・リスト閲覧部４０２が表示するコンテンツ一覧画面の中でユーザーが選択したコンテンツの取得を要求する。サーバー１０１、２０１に対するコンテンツの取得要求並びにコンテンツの取得には、例えばＨＴＴＰプロトコルが利用される（後述）。コンテンツを取得する方法として、コンテンツのストリーミングやコンテンツの移動（ＭＯＶＥ）を挙げることができる。本実施形態では、サーバー２０１にリモート・アクセスする場合、登録時に付与された再生可能時間の残りに応じてコンテンツの提供が制限される点に１つの特徴があるが、その詳細については後述に譲る。

サーバー１０１、２０１から取得したコンテンツは、認証・鍵共有部４０６によりサーバー１０１、２０１との間で共有した交換鍵を用いて暗号化されている。コンテンツ復号部４０４は、サーバー１０１、２０１から取得した暗号化コンテンツをこの暗号鍵を用いて復号化する。そして、コンテンツ再生出力部４０５は、復号したコンテンツを再生出力する。コンテンツ再生出力部４０５は、動画像などのコンテンツを表示する表示部を備えている。

認証・鍵共有部４０６は、コンテンツの要求先となるサーバー１０１、２０１との間で、ＤＴＣＰ−ＩＰが規定する認証及び鍵交換（ＡＫＥ）アルゴリズムに従って、相互認証と、コンテンツ暗号化のための暗号鍵の共有を行なう。認証・鍵共有部４０６は、外部ネットワークからリモート・アクセスによりコンテンツを要求するサーバー２０１との間では、リモート・アクセス用交換鍵Ｋ_Rを共有する。また、認証・鍵共有部４０６は、ホーム・ネットワーク２１０に接続している間に、サーバー２０１に対してリモート・アクセスのための登録を事前に行なう。本実施形態では、端末２０２がサーバー２０１に登録を行なう際に、リモート・アクセス時に許容されるコンテンツの再生可能時間が付与される点に特徴があるが、この点の詳細については後述に譲る。

上記の機能ブロック４０２〜４０６は、通信・制御部４０１において、オペレーティング・システムやＴＣＰ／ＩＰプロトコルの上位で実行するアプリケーション・プログラムとして実現することもできる。この種のアプリケーション・プログラムは、インターネットなどの広域ネットワーク上で所定のダウンロード・サイトで配信することができ、スマートフォンなど、ホーム・サーバー内のコンテンツを再生する多機能端末にダウンロードして利用に供される。

このようなダウンロード・サイトは、例えば、コンピューター・プログラムを記憶する記憶装置２７１１と、コンピューター・プログラムのダウンロード要求を受信したことに応じてそのダウンロードを認める通信装置２７１２とを備えたサーバー２７１０からなり（図２６を参照のこと）、ダウンロードしたコンピューター・プログラムをインストールするクライアント装置（ＤＴＣＰ＿Ｓｏｕｒｃｅ又はＤＴＣＰ＿Ｓｉｎｋ）と併せてコンピューター・プログラム配信システム２７００を構成する。この種のサーバーは、クライアントからのコンピューター・プログラムのダウンロード要求に対して、コンピューター・プログラムの名称を示す情報を通知する情報通知装置２７１３をさらに備えている。情報通知装置２７１３は、コンピューター・プログラムの名称とともに、例えば、家庭内に記録した商用コンテンツを遠隔地で閲覧することが認められるアプリケーションであることを示す情報を通知する。

図２に示したコンテンツ伝送システム２００の利用形態として、携帯電話や多機能携帯端末のような端末２０２が、遠隔地から外部ネットワーク２２０及びルーター２３０経由で自宅内のサーバー２０１に接続して、サーバー２０１のコンテンツ記録部３０２に記録されたコンテンツ（例えば、録画した放送コンテンツ）を視聴することが考えられる。このような利用形態は、ユーザーにとってはどこでもコンテンツを視聴できるというメリットがある反面、コンテンツ提供業者にとっては、コンテンツが遠隔地でも永続的に視聴されるというデメリットがある。

例えば、放送事業者にとっては、放送対象地域外の居住者によって放送コンテンツが永続的に視聴されることになる。これによって、地方局の放送ビジネスに悪影響を及ぼすことや、コンテンツ調達契約でカバーされない場所でコンテンツが視聴されることが懸念される。

そこで、本明細書で開示する技術では、リモート・アクセス時に許容されるコンテンツの再生可能時間を端末２０２に付与し、サーバー２０１は再生可能時間の範囲内でのみ端末２０２にコンテンツを提供することにより、遠隔地からのコンテンツの利用が永続できないようにしている。

サーバー２０１は、例えば、端末２０２をリモート・アクセスのために登録を行なう際に再生可能時間の付与を併せて行なう。勿論、サーバー２０１は、別の方法で、又は別の時期に、端末２０２への再生可能時間の付与を行なうようにしてもよい。

そして、サーバー２０１は、端末２０２にコンテンツのストリーム伝送を行なう際、伝送したコンテンツの再生時間だけ再生可能時間を減らし、残りの再生可能時間がゼロになったらそれ以上の伝送ができないようにする。また、サーバー２０１は、端末２０２にコンテンツの移動（ＭＯＶＥ）を行なう際、そのコンテンツの長さ（ｄｕｒａｔｉｏｎ）を再生可能時間から差し引き、残りの再生可能時間がゼロになったらそれ以上伝送できないようにする。伝送できないようにする方法として、残りの再生可能時間がゼロであることを確認する方法の他に、端末２０２の登録を抹消する方法も挙げられる。

このように、サーバー２０１が再生可能時間に応じて端末２０２へのコンテンツの提供を制限することによって、リモート・アクセスする端末２０２でコンテンツを永続的に視聴することを防止することができる。放送対象地域に居住するユーザーは、旅行や出張の間、与えられた再生可能時間だけはコンテンツを視聴することができる。これと同時に、放送対象外地域に居住するユーザーが永続的にコンテンツを視聴することを防止できる。

サーバー２０１への端末２０２の登録は、ホーム・ネットワーク２１０内でのみ可能とし、遠隔地からは行なえないようにする。例えば、ＤＴＣＰ規格のＲｅｍｏｔｅ Ｓｉｎｋ Ｒｅｇｉｓｔｒａｔｉｏｎ処理を行なう。

また、端末２０２は、再生可能時間がゼロになる前にサーバー２０１に再登録を行なうことにより、再生可能時間を初期値に戻すことができるものとする。

なお、サーバー２０１は、再生可能時間の残りを端末２０２に通知するようにしてもよい。例えば、コンテンツ伝送を行なう際のＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）メッセージのヘッダー・フィールドなどに再生可能時間の情報を格納するようにしてもよい（後述）。

Ｂ．登録手続き
図５には、リモート・アクセスを行なうＳｉｎｋデバイスを、再生可能時間とともに、Ｓｏｕｒｃｅデバイスに登録する手順（Ｒｅｍｏｔｅ Ｓｉｎｋ Ｒｅｇｉｓｔｒａｔｉｏｎ処理）を図解している。同図中、Ｓｉｎｋデバイスは端末２０２に相当し、Ｓｏｕｒｃｅデバイスはサーバー２０１に相当するものと理解されたい。登録手続きは、ホーム・ネットワーク２１０内でのみとし、遠隔地からは行なえないものとする。

まず、ＳｏｕｒｃｅデバイスとＳｉｎｋデバイス間で、ＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）の制限下で、ＡＫＥ手続きが実施される（ＳＥＱ５０１）。例えば、ＳｏｕｒｃｅデバイスとＳｉｎｋデバイスがホーム・ネットワーク２１０内にあれば、ＲＴＴの制限をクリアして、ＡＫＥ手続きが成功裏に終了する。ＲＴＴ−ＡＫＥ手続き自体は、本明細書で開示する技術の要旨に直接関連しないので、ここでは詳細な説明を省略する。

そして、ＲＴＴ−ＡＫＥ手続きに成功裏に終了すると、Ｓｉｎｋデバイスは、コマンドＲＡ＿ＲＥＧＩＳＴＥＲ．ＣＭＤを用いて、自分のＳｉｎｋ−ＩＤをＳｏｕｒｃｅデバイスに送信する（ＳＥＱ５０２）。

ここで、Ｓｉｎｋデバイスは、Ｓｉｎｋ−ＩＤとして、自分に固有のＤｅｖｉｃｅ ＩＤ、又は、ＩＤｕを送信する（ＳｉｎｋデバイスがＣｏｍｍｏｎ Ｄｅｖｉｃｅ ＫｅｙとＣｏｍｍｏｎ Ｄｅｖｉｃｅ Ｃｅｒｔｉｆｉｃａｔｅを実装することで、Ｄｅｖｉｃｅ ＩＤがＳｉｎｋの特定情報とならない場合には、ＩＤｕがＳｉｎｋ−ＩＤとして用いられる）。

これに対し、Ｓｏｕｒｃｅデバイスは、ＲＡ＿ＲＥＧＩＳＴＥＲ．ＣＭＤで受け取ったＳｉｎｋ−ＩＤが、直前に完了したＲＴＴ-ＡＫＥ手続で受信したＤｅｖｉｃｅ ＩＤ又はＩＤｕと一致し、ｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙにまだ記憶しておらず、且つ、ｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙが満杯でないかどうかをチェックする。そして、これらの条件をクリアし、Ｓｉｎｋ−ＩＤをｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙに追加記憶するときには、Ｓｏｕｒｃｅデバイスは、ＲＡ＿ＲＥＧＩＳＴＥＲ．ＲＳＰをＳｉｎｋデバイスに返す（ＳＥＱ５０３）。

上記の手続きＳＥＱ５０１〜５０３は、基本的には、ＤＴＣＰの仕様書、例えばＤＴＣＰ Ｖｏｌｕｍｅ １ Ｓｕｐｐｌｅｍｅｎｔ Ｅ Ｍａｐｐｉｎｇ ＤＴＣＰ ｔｏ ＩＰ，Ｒｅｖｉｓｉｏｎ １．４ｅｄ１（Ｉｎｆｏｒｍａｔｉｏｎａｌ Ｖｅｒｓｉｏｎ）のＶ１ＳＥ．１０．７．１節の記載に従って実施される。

そして、Ｓｏｕｒｃｅデバイスは、再生可能時間をペアにしたＳｉｎｋデバイスの登録を実行する（ＳＥＱ５０４）。

図６には、手続きＳＥＱ５０４において、ＳｏｕｒｃｅデバイスがＳｉｎｋ−ＩＤと再生可能時間をペアにしたＳｉｎｋデバイスの登録を行なうための処理手順をフローチャートの形式で示している。

Ｓｏｕｒｃｅデバイスは、ＲＡ＿ＲＥＧＩＳＴＥＲ．ＣＭＤで登録を要求してきたＳｉｎｋデバイスのＳｉｎｋ−ＩＤが、（端末管理部３０７で管理している）ｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙに既に記憶されたかどうかをチェックする（ステップＳ６０１）。

Ｓｉｎｋデバイスから受け取ったＳｉｎｋ−ＩＤが記憶されている場合は（ステップＳ６０１のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、そのＳｉｎｋデバイスの再生可能時間を初期値にセットして（ステップＳ６０２）、本処理ルーチンを終了する。なお、Ｓｉｎｋ−ＩＤが今回の登録処理以前に登録されていた場合には、本処理で再生可能時間が初期値にリセットされる。

一方、登録を要求するＳｉｎｋデバイスのＳｉｎｋ−ＩＤがｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙに記憶されていないときには（ステップＳ６０１のＮｏ）、Ｓｏｕｒｃｅデバイスは、何もせずに本処理を終了する。

図７には、Ｓｉｎｋ−ＩＤと再生可能時間をペアにして格納したｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙの登録内容を例示している。図示の例では、参照番号７０１で示すように、Ｓｉｎｋ−ＩＤが０ｘ８０００００ｅ９２４のＳｉｎｋデバイスの再生可能時間４３２００分と、参照番号７０２で示すように、Ｓｉｎｋ−ＩＤが０ｘ８００００１００ａｆのＳｉｎｋデバイスの再生可能時間１５００分を登録している。

但し、図７に示したような端末毎の再生可能時間の情報の管理を、ホーム・ネットワーク２１０内のサーバー２０１で個別に行なうのではなく、クラウド上などに置かれた管理用サーバーで一元的に行なうようにしてもよい。

Ｃ．再生可能時間に基づくリモート・アクセスの制限
上述したように、サーバー２０１は、端末２０２を登録する際に、リモート・アクセス時に許容されるコンテンツの再生可能時間を付与し、Ｓｉｎｋ−ＩＤとペアにして管理する。そして、サーバー２０１は、端末２０２にコンテンツのストリーム伝送を行なう際、伝送したコンテンツの再生時間だけ再生可能時間を減らし、残りの再生可能時間がゼロになったらそれ以上の伝送ができないようにする。また、サーバー２０１は、端末２０２にコンテンツの移動（ＭＯＶＥ）を行なう際、そのコンテンツの長さ（ｄｕｒａｔｉｏｎ）を再生可能時間から差し引き、残りの再生可能時間がゼロになったらそれ以上伝送できないようにする。また、伝送できないようにする方法として、端末２０２の登録を抹消（ｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙから削除）することも挙げられる。

このように、サーバー２０１が再生可能時間により端末２０２へのコンテンツの提供を制限することによって、リモート・アクセスする端末２０２でコンテンツを永続的に視聴するのを防止することができる。放送対象地域に居住するユーザーは、旅行や出張の間、与えられた再生可能時間だけはコンテンツを視聴することができる。これと同時に、放送対象外地域に居住するユーザーが永続的にその放送コンテンツを視聴することを防止できる。

図８には、上記の登録を行なった後のＳｏｕｒｃｅデバイスとＳｉｎｋデバイス間でリモート・アクセスによるコンテンツ伝送を行なう手順を模式的に示している。同図中、Ｓｉｎｋデバイスは端末２０２に相当し、Ｓｏｕｒｃｅデバイスはサーバー２０１に相当するものと理解されたい。

図示のコンテンツ伝送は、Ｓｉｎｋデバイスが伝送を要求するコンテンツを指定するコンテンツ・リスト閲覧フェーズ（ＳＥＱ８０１）と、ＳｏｕｒｃｅデバイスとＳｉｎｋデバイス間で相互認証及び鍵交換手順を実施してリモート・アクセス用交換鍵Ｋ_Rを共有するＲＡ−ＡＫＥ手続きフェーズ（ＳＥＱ８０２）と、コンテンツ・リスト閲覧フェーズで指定されたコンテンツを、リモート・アクセス用交換鍵Ｋ_Rを用いて暗号化伝送するコンテンツ伝送フェーズ（ＳＥＱ８０３）からなる。

図９には、コンテンツ・リスト閲覧フェーズ（ＳＥＱ８０１）の中身を模式的に示している。同図中、Ｓｉｎｋデバイスは端末２０２に相当し、Ｓｏｕｒｃｅデバイスはサーバー２０１に相当するものと理解されたい。

Ｓｉｎｋデバイスからは、コンテンツ・リスト閲覧部４０２から、コンテンツ・リストの閲覧要求が発行される（ＳＥＱ９０１）。

コンテンツ・リストの閲覧には、ＤＬＮＡのベースとなるＵＰｎＰで策定されているＣＤＳ（Ｃｏｎｔｅｎｔ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ）機能を適用することができる。この場合、ＳＥＱ９０１では、ＳｉｎｋデバイスからＣＤＳ：Ｂｒｏｗｓｅアクションが発行される。そして、Ｓｏｕｒｃｅデバイスは、コンテンツのリストとコンテンツの詳細情報を階層化して配信する。

コンテンツ・リストの閲覧要求には、Ｓｉｎｋデバイスを特定するＳｉｎｋ−ＩＤが含められる。ＣＤＳ：ＢｒｏｗｓｅリクエストでＳｉｎｋ−ＩＤを送る手段としては、新たにヘッダー・フィールド（例えば、ＳｉｎｋＩＤ．ｄｔｃｐ．ｃｏｍ）を設け、そのパラメーターとしてＨＴＴＰのヘッダー部分で送ることが考えられる。Ｓｏｕｒｃｅデバイス側では、リクエストに含まれているＳｉｎｋ−ＩＤに基づいて、そのＳｉｎｋデバイスの再生可能時間をチェックすることができる。

Ｓｏｕｒｃｅデバイス側では、ＣＤＳ：Ｂｒｏｗｓｅアクションが発行されたことに応答して、コンテンツ・リスト提供部３０５は、コンテンツ提供部３０４で提供可能なコンテンツに関する取得可能なすべてのコンテンツ情報を取得して（ＳＥＱ９０２）、十分な情報量のＣＤＳ情報を生成する（ＳＥＱ９０３）。コンテンツ提供部３０４で提供可能なコンテンツは、例えば、コンテンツ取得部３０３で取得可能な放送コンテンツや商用コンテンツ、あるいは、自身のストレージであるコンテンツ記録部３０２に既に記録されているコンテンツなどである。そして、Ｓｏｕｒｃｅデバイスは、Ｓｉｎｋデバイスに対してＣＤＳ Ｒｅｓｕｌｔとして返す（ＳＥＱ９０４）。

なお、Ｓｏｕｒｃｅデバイスは、要求元のＳｉｎｋデバイスの現在の再生可能時間では足りない長さ（ｄｕｒａｔｉｏｎ）のコンテンツをコンテンツのリストから外すようにしてもよい。また、Ｓｏｕｒｃｅデバイスは、コンテンツのリストを提供する際に、要求元のＳｉｎｋデバイスの現在の再生可能時間の情報、又は、コンテンツを取得後の再生可能時間の情報を通知するようにしてもよい。

Ｓｉｎｋデバイス側では、コンテンツ・リスト閲覧部４０２が、受信したＣＤＳ Ｒｅｓｕｌｔを解析して、コンテンツのタイトル並びにより詳細情報を含むコンテンツ情報を表示する（ＳＥＱ９０５）。

Ｓｉｎｋデバイスのユーザーは、表示されているコンテンツ・リストの中から、再生したいコンテンツを選択することができる。そして、コンテンツが選択されると、ＳｏｕｒｃｅデバイスからＳｉｎｋデバイスへのコンテンツの伝送が開始されるが、コンテンツ伝送に先駆けて、ＳｉｎｋデバイスとＳｏｕｒｃｅデバイス間で、リモート・アクセス用の相互認証及び鍵交換すなわちＲＡ−ＡＫＥ処理が実施される。

図１０には、ＲＡ−ＡＫＥ手続きフェーズ（ＳＥＱ８０２）の中身の詳細を示している。同図中、Ｓｉｎｋデバイスは端末２０２に相当し、Ｓｏｕｒｃｅデバイスはサーバー２０１に相当するものと理解されたい。図示の手順は、基本的には、ＤＴＣＰの仕様書（前述）のＶ１ＳＥ．１０．７．２節に記載事項に従うものとする。

Ｓｉｎｋデバイスは、リモート・アクセス用交換Ｋ_R（Ｒｅｍｏｔｅ Ｅｘｃｈａｎｇｅ Ｋｅｙ）用のビットが設定された交換鍵フィールドを含んだＣＨＡＬＬＥＮＧＥコマンドを送信して、Ｓｏｕｒｃｅデバイスに対してＡＫＥ処理を要求する（ＳＥＱ１００１）。そして、ＳｏｕｒｃｅデバイスとＳｉｎｋデバイス間で、認証手続きのうちチャレンジ・レスポンス部分が実行される（ＳＥＱ１００２〜１００４）。

但し、ＣＨＡＬＬＥＮＧＥコマンドのＫ_R用のビットが設定されていないときには、ＳｏｕｒｃｅデバイスはＲＡ−ＡＫＥ手続きを中止し、ＲＡ−ＡＫＥ以外のＡＫＥ手続きを引き続き行なうことができる。

Ｓｏｕｒｃｅデバイスは、チャレンジ・レスポンス手続きでＳｉｎｋデバイスから、Ｄｅｖｉｃｅ ＩＤ又はＩＤｕをＳｉｎｋ−ＩＤとして受け取ることができる（ＳＥＱ１００５）。

ここで、Ｓｏｕｒｃｅデバイスは、ｒｅｍｏｔｅ ｓｉｎｋ ｒｅｓｉｓｔｒｙのメンテナンス、すなわち、再生可能時間がゼロになったＳｉｎｋ−ＩＤをｒｅｍｏｔｅ ｓｉｎｋ ｒｅｓｉｓｔｒｙから抹消する処理を実施する（ＳＥＱ１００６）。再生可能時間がゼロになったＳｉｎｋ−ＩＤをｒｅｍｏｔｅ ｓｉｎｋ ｒｅｓｉｓｔｒｙから抹消することで、放送対象地域外の居住者によって放送コンテンツが永続的に視聴されることを防止する。ｒｅｍｏｔｅ ｓｉｎｋ ｒｅｓｉｓｔｒｙのメンテナンス処理が実施された後は、再生可能時間が残っているエントリーのみが残っているものとする。ｒｅｍｏｔｅ ｓｉｎｋ ｒｅｓｉｓｔｒｙのメンテナンス処理の詳細については、後述に譲る。

なお、このメンテナンス処理は、新たなＳｉｎｋをｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙに登録できる領域を生む効果がある。但し、後述の処理に示す通り、この処理を行なわなくても再生可能時間がゼロのＳｉｎｋデバイスに対するコンテンツ送信は防げるため、敢えて登録を維持したい場合などにこの処理を行なわないことも考えられる。そして、メンテナンス処理を行なわない場合は、図示を省略するが、ＲＡ−ＡＫＥ手続きを行なっているＳｉｎｋデバイスの再生可能時間をチェックし、ゼロの場合はＡＫＥ＿ＣＡＮＣＥＬコマンドを送信して、ＲＡ−ＡＫＥ手続きを中止する。一方、ゼロでない場合は下記の処理を行なう。

次いで、Ｓｏｕｒｃｅデバイスは、受け取ったＳｉｎｋ−ＩＤが自身の端末管理部３０７内で管理しているｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙに登録されているかどうかをチェックする（ＳＥＱ１００７）。

Ｓｉｎｋ−ＩＤがｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙにリストされていない場合には（ＳＥＱ１００７のＮｏ）、Ｓｏｕｒｃｅデバイスは、ＳｉｎｋデバイスにＡＫＥ＿ＣＡＮＣＥＬコマンドを送信して（ＳＥＱ１０１５）、ＲＡ−ＡＫＥ手続きを中止する（ＳＥＱ１０１６）。

一方、Ｓｉｎｋ−ＩＤがｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙに既に登録されている場合には（ＳＥＱ１００７のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、このＳｉｎｋ−ＩＤに該当するＲＡＣ ｒｅｃｏｒｄ（後述）が既に存在するかどうかを判別するために、ＲＡＣ ｒｅｇｉｓｔｒｙ内をチェックする（ＳＥＱ１００８）。

Ｓｉｎｋ−ＩＤに該当するＲＡＣ ｒｅｃｏｒｄが存在する場合には（ＳＥＱ１００８のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、そのＲＡＣ ｒｅｃｏｒｄに格納されているリモート・アクセス用交換鍵Ｋ_R及びその交換鍵ラベルＫ_R＿ｌａｂｅｌを使うことに決定する。あるいは、Ｓｏｕｒｃｅデバイスは、リモート・アクセス用交換鍵Ｋ_Rを用いてコンテンツの伝送を行なっていないのであれば、ＲＡＣ ｒｅｃｏｒｄ内を参照し、格納されているＫ_R及びＫ_R＿ｌａｂｅｌの値を更新するようにしてもよい（ＳＥＱ１０１４）。

Ｓｉｎｋ−ＩＤはｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙに登録済みであるが、該当するＲＡＣ ｒｅｃｏｒｄが存在しない場合には（ＳＥＱ１００８のＮｏ）、Ｓｏｕｒｃｅデバイスは、ＲＡＣ ｒｅｃｏｒｄをカウントするカウント値ＲＡＣＣがＲＡＣＣ_max未満であるかどうかをチェックする（ＳＥＱ１００９）。ここで、ＲＡＣＣ_maxは、リモート・アクセス・コネクションをカウントするカウンターであり、リモート・アクセス・コネクションが存在しないときにゼロに初期化される。

ＲＡＣＣがそのＲＡＣＣ_max未満でないときには（ＳＥＱ１００９のＮｏ）、Ｓｏｕｒｃｅデバイスは、ＳｉｎｋデバイスにＡＫＥ＿ＣＡＮＣＥＬコマンドを送信して（ＳＥＱ１０１５）、ＲＡ−ＡＫＥ手続きを中止する（ＳＥＱ１０１６）。

ＲＡＣＣがＲＡＣＣ_max未満であれば（ＳＥＱ１００９のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、ＲＡＣＣの値を１だけインクリメントした後（ＳＥＱ１０１０）、所定の演算規則に従って、リモート・アクセス用交換鍵Ｋ_R及びその交換鍵ラベルＫ_R＿ｌａｂｅｌを生成して（ＳＥＱ１０１１）、これらをＳｉｎｋデバイスのＳｉｎｋ−ＩＤと対応付けて、ＲＡＣ ｒｅｇｉｓｔｒｙ内のＲＡＣ ｒｅｃｏｒｄに格納する（ＳＥＱ１０１２）。サーバー２０１は、例えば端末管理部３０７内でＲＡＣ ｒｅｃｏｒｄを管理する。

図１１には、Ｓｉｎｋデバイスに対して生成したリモート・アクセス用交換鍵Ｋ_R及びその交換鍵ラベルＫ_R＿ｌａｂｅｌをＳｉｎｋ−ＩＤと対応付けてＲＡＣ ｒｅｃｏｒｄとして記憶する様子を示している。図示の例では、Ｓｉｎｋ−ＩＤが０ｘ８０００００ｅ９２４のＳｉｎｋデバイスに対して、リモート・アクセス用交換鍵０ｘ７ｆ４１３０ｄｅ０ａ６１００ｅ２５７ｃｆ６８ｄｂ及びその交換鍵ラベル０ｘｅ９が割り当てられている。

Ｓｏｕｒｃｅデバイスは、既存のＲＡＣ ｒｅｃｏｒｄから取り出したリモート・アクセス用交換鍵Ｋ_R及びその交換鍵ラベルＫ_R＿ｌａｂｅｌ（更新した場合を含む）、又は、新たに生成したリモート・アクセス用交換鍵Ｋ_R及びその交換鍵ラベルＫ_R＿ｌａｂｅｌを、Ｓｉｎｋデバイスに送信する（ＳＥＱ１０１７）。

ＳｏｕｒｃｅデバイスがＲＡ＿ＭＡＮＡＧＥＭＥＮＴ機能をサポートしている場合には、リモート・アクセス用交換Ｋ_Rを維持するためのＫ_R用生存タイマーを開始させ、少なくとも１分間Ｋ_Rを保持する（ＳＥＱ１０１３）。

図１２には、ｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙのメンテナンス処理の手順をフローチャートの形式で示している。以下では、便宜上、Ｓｏｕｒｃｅデバイスとしてのサーバー２０１内でメンテナンス処理を行なうものとして説明する。このメンテナンス処理は、例えばサーバー２０１内の認証・鍵共有部３０６が、ＲＡ−ＡＫＥ手続きフェーズの中で実施する。

Ｓｏｕｒｃｅデバイスは、端末管理部３０７内で管理しているｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙ中で、再生可能時間を未確認のＳｉｎｋデバイスに関して（ステップＳ１２０１のＮｏ）、そのＳｉｎｋ−ＩＤとペアにして記憶されている再生可能時間を参照し（ステップＳ１２０２）、再生可能時間がゼロになっているかどうかをチェックする（ステップＳ１２０３）。そして、Ｓｏｕｒｃｅデバイスは、再生可能時間がゼロになっているＳｉｎｋ−ＩＤのエントリーを（ステップＳ１２０３のＹｅｓ）、ｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙから削除する（ステップＳ１２０４）。

次いで、Ｓｏｕｒｃｅデバイスは、ｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙ内に登録されているすべてのＳｉｎｋのエントリーについてステップＳ１２０２〜Ｓ１２０４の処理を終了するまで（ステップＳ１２０１のＹｅｓ）、繰り返し実行する。

図１２に示したｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙのメンテナンス処理は、各サーバー２０１が個別に実施する（言い換えれば、サーバー２０１が設置されたホーム・ネットワーク２１０単位で実施する）のではなく、クラウド上の管理サーバーなどで各家庭のサーバー２０１のｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙを一元的に集中管理するようにしてもよい。

また、図１２に示したようなｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙのメンテナンス処理を、ＲＡ−ＡＫＥ手続き時に逐次行なうのではなく、サーバー２０１又はクラウド上の管理サーバーなどが、（ＲＡ−ＡＫＥ手続きを実施するか否かに拘わらず）定期的に行なうようにしてもよい。

また、図１２では、１回のメンテナンス処理でｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙ内のすべてのエントリーについて再生可能時間の確認処理を実行するようになっているが、ＲＡ−ＡＫＥ手続きの対象となっているＳｉｎｋ−ＩＤに対応するエントリーについてのみ再生可能時間の確認処理を行なうだけでもよい。

図１３には、リモート・アクセス用交換鍵Ｋ_Rを用いて暗号化伝送するコンテンツ伝送フェーズ（ＳＥＱ８０３）の中身を模式的に示している。同図中、Ｓｉｎｋデバイスは端末２０２に相当し、Ｓｏｕｒｃｅデバイスはサーバー２０１に相当するものと理解されたい。図示のシーケンスには、再生可能時間に基づくコンテンツ出力管理の処理と、コンテンツ出力制御及び再生可能時間の管理の処理が含まれている。

Ｓｉｎｋデバイスは、ＲＡ−ＡＫＥ手続により取得したリモート・アクセス用交換鍵Ｋ_R及びその交換鍵ラベルＫ_R＿ｌａｂｅｌを取得した後に、例えば、ＨＴＴＰ ＧＥＴメソッドを用いたＨＴＴＰリクエスト（ＨＴＴＰ ＧＥＴ ｒｅｑｕｅｓｔ）により、Ｓｏｕｒｃｅデバイスに対して、コンテンツの伝送を要求する（ＳＥＱ１３０１）。この要求の際には、コンテンツのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）とともに、リモート・アクセス用交換鍵Ｋ_RのＩＤであるラベルＫ_R＿ｌａｂｅｌを送る。ここで、ＳｉｎｋデバイスからＳｏｕｒｃｅデバイスに交換鍵のＩＤ（Ｋ_R＿ｌａｂｅｌ）を送るためのヘッダー・フィールドを定義する。

Ｓｏｕｒｃｅデバイスは、Ｓｉｎｋデバイスからコンテンツの伝送要求を受けると、再生可能時間に基づくコンテンツ出力管理の処理を実行する（ＳＥＱ１３０２）。

Ｓｏｕｒｃｅデバイスは、ＲＡ−ＡＫＥ手続きにおいて、リモート・アクセス用交換鍵Ｋ_R及びその交換鍵ラベルＫ_R＿ｌａｂｅｌをＳｉｎｋデバイスに送る際に、これらをＳｉｎｋ−ＩＤと対応付けてＲＡＣ ｒｅｃｏｒｄとして記憶している（前述並びに図１１を参照のこと）。したがって、Ｓｏｕｒｃｅデバイスは、コンテンツ要求に含まれる交換鍵ラベルＫ_R＿ｌａｂｅｌに該当するＲＡＣ Ｒｅｃｏｒｄから、要求元ＳｉｎｋデバイスのＳｉｎｋ−ＩＤを調べることができる。

また、Ｓｏｕｒｃｅデバイスは、Ｓｉｎｋデバイスの登録時、すなわち、Ｓｉｎｋ−ＩＤをｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙに登録する際に、再生可能時間（初期値）をＳｉｎｋ−ＩＤとペアにして記憶している（前述並びに図７を参照のこと）。そして、Ｓｏｕｒｃｅデバイスは、Ｓｉｎｋデバイスがコンテンツを利用する度に、ｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙ内の再生可能時間を更新している（後述）。したがって、ＲＡＣ Ｒｅｃｏｒｄから得たＳｉｎｋ−ＩＤに基づいて、そのＳｉｎｋデバイスの現在の再生可能時間を調べることができる。

そして、Ｓｏｕｒｃｅデバイスは、要求元Ｓｉｎｋデバイスの再生可能時間が残っていれば、Ｓｉｎｋデバイスからのコンテンツ要求を許可するが、再生可能時間がゼロになっていれば、Ｓｉｎｋデバイスからのコンテンツ要求を許可しない。

Ｓｏｕｒｃｅデバイスは、Ｓｉｎｋデバイスからのコンテンツ要求を許可する場合には、交換鍵ラベルＫ_R＿ｌａｂｅｌで指定されたリモート・アクセス用交換鍵Ｋ_RをＲＡＣ ｒｅｃｏｒｄから取り出すと、これ用いてコンテンツを暗号化して、ＨＴＴＰレスポンス（ＨＴＴＰ ＧＥＴ ｒｅｓｐｏｎｓｅ）としてＳｉｎｋデバイスに伝送する（ＳＥＱ１３０３）。

また、Ｓｏｕｒｃｅデバイスは、Ｓｉｎｋデバイスへのコンテンツの暗号化伝送を開始すると、続いて、再生可能時間に基づくコンテンツ出力制御と、そのＳｉｎｋデバイスの再生可能時間の管理の処理を実行する（ＳＥＱ１３０４）。

ＳｏｕｏｒｃｅデバイスがＳｉｎｋデバイスにコンテンツを提供する形態として、ストリーミング伝送とコンテンツの移動（ＭＯＶＥ）を挙げることができる。ストリーミング伝送とコンテンツの移動（ＭＯＶＥ）のいずれを行なうかになって、ＳＥＱ１３０２で実行するコンテンツ出力管理と、ＳＥＱ１３０４で実行するコンテンツ出力制御及び再生可能時間管理の処理手順は相違する。

図１４には、ストリーミング時においてＳＥＱ１３０２で実施するコンテンツ出力管理処理の手順をフローチャートの形式で示している。以下では、便宜上、Ｓｏｕｒｃｅデバイスとしてのサーバー２０１が、例えばコンテンツ提供部３０４がコンテンツ出力管理処理を行なうものとして説明する。

Ｓｏｕｒｃｅデバイスは、コンテンツ要求（ＨＴＴＰ ＧＥＴ ｒｅｑｕｅｓｔ）に含まれる交換鍵ラベルＫ_R＿ｌａｂｅｌを参照し（ステップＳ１４０１）、同じ交換鍵ラベルＫ_R＿ｌａｂｅｌのＲＡＣ ｒｅｃｏｒｄが端末管理部３０７内に存在するかどうかをチェックする（ステップＳ１４０２）。

ここで、同じ交換鍵ラベルＫ_R＿ｌａｂｅｌのＲＡＣ ｒｅｃｏｒｄが存在しない場合には（ステップＳ１４０２のＮｏ）、要求元のＳｉｎｋデバイスがＲＡ−ＡＫＥ手続きを行なっていないなどの原因により、不正なコンテンツ要求である。そこで、Ｓｏｕｒｃｅデバイスは、後続の処理をすべてスキップして、本処理ルーチンを終了する。

一方、同じ交換鍵ラベルＫ_R＿ｌａｂｅｌのＲＡＣ ｒｅｃｏｒｄが存在する場合には（ステップＳ１４０２のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、そのＲＡ ｒｅｃｏｒｄから、交換鍵ラベルＫ_R＿ｌａｂｅｌに対応するＳｉｎｋ−ＩＤを取得する（ステップＳ１４０３）。

次いで、Ｓｏｕｒｃｅデバイスは、端末管理部３０７内のｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙから、Ｓｉｎｋ−ＩＤとペアにして記憶されている再生可能時間を取得する（ステップＳ１４０４）。但し、各Ｓｉｎｋ−ＩＤの再生可能時間を例えばクラウド上の管理サーバーに委ねている場合には、Ｓｏｕｒｃｅデバイスは、通信・制御部３０１を介して管理サーバーにアクセスして、該当する再生可能時間の情報を取得する。

また、Ｓｏｕｒｃｅデバイスは、タイマーをゼロに設定する（ステップＳ１４０５）。

そして、Ｓｏｕｒｃｅデバイスは、コンテンツ要求元のＳｉｎｋデバイスの再生可能時間がゼロより大きいかどうかをチェックする（ステップＳ１４０６）。

再生可能時間がゼロでないときには（ステップＳ１４０６のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、Ｓｉｎｋデバイスからのコンテンツ要求を許可する。すなわち、Ｓｏｕｒｃｅデバイスは、タイマーの計時を開始し（ステップＳ１４０７）、要求されたコンテンツの送信を例えばＨＴＴＰ ＧＥＴ ｒｅｓｐｏｎｓｅで行なう（ステップＳ１４０８）。

一方、再生可能時間がゼロのときには（ステップＳ１４０６のＮｏ）、Ｓｏｕｒｃｅデバイスは、Ｓｉｎｋデバイスからのコンテンツ要求を許可せず、後続の処理をスキップして、本処理ルーチンを終了する。

また、図１５には、ストリーミング時においてＳＥＱ１３０４で実施するコンテンツ出力制御及び再生可能時間管理処理の手順をフローチャートの形式で示している。以下では、便宜上、Ｓｏｕｒｃｅデバイスとしてのサーバー２０１内で、例えばコンテンツ提供部３０４がコンテンツ出力制御及び再生可能時間管理処理を行なうものとして説明する。

Ｓｏｕｒｃｅデバイスは、計時しているタイマーの値がコンテンツ伝送先のＳｉｎｋデバイスの再生可能時間未満であるかどうかをチェックする（ステップＳ１５０１）。

ここで、タイマーの値が再生可能時間未満であれば（ステップＳ１５０１のＹｅｓ）、コンテンツの伝送を終了又は停止するまでの間（ステップＳ１５０２のＮｏ）、ステップＳ１５０１に戻り、Ｓｏｕｒｃｅデバイスは、タイマーの値のチェックを継続する。

そして、コンテンツの伝送を終了又は停止すると（ステップＳ１５０２のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、タイマーの計時を停止し（ステップＳ１５０３）、コンテンツ伝送先のＳｉｎｋデバイスの再生可能時間からタイマーの値を引いて（ステップＳ１５０４）、本処理ルーチンを終了する。

また、タイマーの値が再生可能時間以上となったときには（ステップＳ１５０１のＮｏ）、Ｓｏｕｒｃｅデバイスは、コンテンツ伝送先のＳｉｎｋデバイスへのコンテンツの伝送を停止する（ステップＳ１５０５）。そして、サーバー２０１は、ｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙで管理している、そのＳｉｎｋデバイスの再生可能時間をゼロにして（ステップＳ１５０６）、本処理ルーチンを終了する。

図１６には、ストリーミング時においてＳＥＱ１３０２で実施するコンテンツ出力管理処理の変形例を示している。また、図１７には、図１６に対応した、ストリーミング時においてＳＥＱ１３０４で実施するコンテンツ出力制御及び再生可能時間管理処理の手順を示している。図１６並びに図１７は、Ｓｏｕｒｃｅデバイス側での処理負荷を軽減することを意図した処理手順である。

まず、図１６を参照しながら、ストリーミング時においてＳＥＱ１３０２で実施するコンテンツ出力管理処理について説明する。

Ｓｏｕｒｃｅデバイスは、コンテンツ要求（ＨＴＴＰ ＧＥＴ ｒｅｑｕｅｓｔ）に含まれる交換鍵ラベルＫ_R＿ｌａｂｅｌを参照し（ステップＳ１６０１）、同じ交換鍵ラベルＫ_R＿ｌａｂｅｌのＲＡＣ ｒｅｃｏｒｄが端末管理部３０７内に存在するかどうかをチェックする（ステップＳ１６０２）。

ここで、同じ交換鍵ラベルＫ_R＿ｌａｂｅｌのＲＡＣ ｒｅｃｏｒｄが存在しない場合には（ステップＳ１６０２のＮｏ）、要求元のＳｉｎｋデバイスがＲＡ−ＡＫＥ手続きを行なっていないなどの原因により、不正なコンテンツ要求である。そこで、Ｓｏｕｒｃｅデバイスは、後続の処理をすべてスキップして、本処理ルーチンを終了する。

一方、同じ交換鍵ラベルＫ_R＿ｌａｂｅｌのＲＡＣ ｒｅｃｏｒｄが存在する場合には（ステップＳ１６０２のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、そのＲＡ ｒｅｃｏｒｄから、交換鍵ラベルＫ_R＿ｌａｂｅｌに対応するＳｉｎｋ−ＩＤを取得する（ステップＳ１６０３）。

次いで、Ｓｏｕｒｃｅデバイスは、端末管理部３０７内のｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙから、Ｓｉｎｋ−ＩＤとペアにして記憶されている再生可能時間を取得する（ステップＳ１６０４）。但し、各Ｓｉｎｋ−ＩＤの再生可能時間を例えばクラウド上の管理サーバーに委ねている場合には、Ｓｏｕｒｃｅデバイスは、通信・制御部３０１を介して管理サーバーにアクセスして、該当する再生可能時間の情報を取得する。

また、Ｓｏｕｒｃｅデバイスは、タイマーをゼロに設定する（ステップＳ１６０５）。

そして、Ｓｏｕｒｃｅデバイスは、コンテンツ移動先のＳｉｎｋデバイスの再生可能時間が、移動を要求しているコンテンツの長さ（ｄｕｒａｔｉｏｎ）以上かどうかをチェックする（ステップＳ１６０６）。

コンテンツ移動先のＳｉｎｋデバイスの再生可能時間がコンテンツの長さ（ｄｕｒａｔｉｏｎ）以上である場合には（ステップＳ１６０６のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、Ｓｉｎｋデバイスからのコンテンツ要求を許可する。この場合、Ｓｏｕｒｃｅデバイスは、コンテンツ移動先のＳｉｎｋデバイスの再生可能時間からコンテンツの長さ（ｄｕｒａｔｉｏｎ）を引いた後（ステップＳ１６０７）、タイマーの計時を開始し（ステップＳ１６０８）、要求されたコンテンツの送信を例えばＨＴＴＰ ＧＥＴ ｒｅｓｐｏｎｓｅで行なう（ステップＳ１６０９）。なお、後述（図２２を参照のこと）のように、再生可能時間をＳｉｎｋデバイスに通知する場合は、上記のコンテンツの長さを引く前の再生可能時間を渡すものとする。

一方、再生可能時間がコンテンツの長さ（ｄｕｒａｔｉｏｎ）より小さい場合には（ステップＳ１６０６のＮｏ）、Ｓｏｕｒｃｅデバイスは、Ｓｉｎｋデバイスからのコンテンツ要求を許可せず、後続の処理をスキップして、本処理ルーチンを終了する。

続いて、図１７を参照しながら、Ｓｏｏｕｒｃｅデバイスの処理負荷を軽減した、ストリーミング時においてＳＥＱ１３０４で実施するコンテンツ出力制御及び再生可能時間管理処理について説明する。

Ｓｏｕｒｃｅデバイスは、コンテンツの伝送を終了又は停止するとき（ステップＳ１７０１のＹｅｓ）、タイマーの計時を停止する（ステップＳ１７０２）。

そして、Ｓｏｕｒｃｅデバイスは、タイマーの値がコンテンツの長さ（ｄｕｒａｔｉｏｎ）より小さいかどうかをチェックする（ステップＳ１７０３）。

ここで、タイマーの値がコンテンツの長さ（ｄｕｒａｔｉｏｎ）よりも小さければ（ステップＳ１７０３のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、コンテンツ移動先のＳｉｎｋデバイスの再生可能時間に（ｄｕｒａｔｉｏｎ−タイマー値）を足して（ステップＳ１７０４）、本処理ルーチンを終了する。

また、タイマーの値がコンテンツの長さ（ｄｕｒａｔｉｏｎ）以上の場合には（ステップＳ１７０３のＮｏ）、Ｓｏｕｒｃｅデバイスは、コンテンツ移動先のＳｉｎｋデバイスの再生可能時間を更新することなく、本処理ルーチンを終了する。

図１６並びに図１７に示した処理手順に従えば、コンテンツ伝送中に再生残り時間のチェックが不要になる。したがって、Ｓｏｕｒｃｅデバイスは、現在の処理を変更しなければならない箇所が減り、伝送中の定期的な処理乃至割り込み処理が不要になることから、処理負荷が軽減される。

図１８には、コンテンツ移動（ＭＯＶＥ）時においてＳＥＱ１３０２で実施するコンテンツ出力管理処理の手順をフローチャートの形式で示している。以下では、便宜上、Ｓｏｕｒｃｅデバイスとしてのサーバー２０１内で、例えばコンテンツ提供部３０４がコンテンツ出力管理処理を行なうものとして説明する。

Ｓｏｕｒｃｅデバイスは、コンテンツ要求（ＨＴＴＰ ＧＥＴ ｒｅｑｕｅｓｔ）に含まれる交換鍵ラベルＫ_R＿ｌａｂｅｌを参照し（ステップＳ１８０１）、同じ交換鍵ラベルＫ_R＿ｌａｂｅｌのＲＡＣ ｒｅｃｏｒｄが端末管理部３０７内に存在するかどうかをチェックする（ステップＳ１８０２）。

ここで、同じ交換鍵ラベルＫ_R＿ｌａｂｅｌのＲＡＣ ｒｅｃｏｒｄが存在しない場合には（ステップＳ１８０２のＮｏ）、要求元のＳｉｎｋデバイスがＲＡ−ＡＫＥ手続きを行なっていないなどの原因により、不正なコンテンツ要求である。そこで、Ｓｏｕｒｃｅデバイスは、後続の処理をすべてスキップして、本処理ルーチンを終了する。このとき、Ｓｏｕｒｃｅデバイスは、コンテンツ要求元のＳｉｎｋデバイスに、例えばＨＴＴＰ Ｓｔａｔｕｓ Ｃｏｄｅ ４０６などのエラー応答を返送するようにしてもよい（ステップＳ１８０８）。

一方、同じ交換鍵ラベルＫ_R＿ｌａｂｅｌのＲＡＣ ｒｅｃｏｒｄが存在する場合には（ステップＳ１８０２のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、そのＲＡ ｒｅｃｏｒｄから、交換鍵ラベルＫ_R＿ｌａｂｅｌに対応するＳｉｎｋ−ＩＤを取得する（ステップＳ１８０３）。

次いで、Ｓｏｕｒｃｅデバイスは、端末管理部３０７内のｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙから、Ｓｉｎｋ−ＩＤとペアにして記憶されている再生可能時間を取得する（ステップＳ１８０４）。但し、各Ｓｉｎｋ−ＩＤの再生可能時間を例えばクラウド上の管理サーバーに委ねている場合には、Ｓｏｕｒｃｅデバイスは、通信・制御部３０１を介して管理サーバーにアクセスして、該当する再生可能時間の情報を取得する。

また、Ｓｏｕｒｃｅデバイスは、Ｓｉｎｋデバイスから要求されたコンテンツの長さ（ｄｕｒａｔｉｏｎ）を取得する（ステップＳ１８０５）。例えば、ＣＤＳ中のｒｅｓ＠ｄｕｒａｔｉｏｎなどを参照して、コンテンツの長さ（ｄｕｒａｔｉｏｎ）を取得することができる。

そして、Ｓｏｕｒｃｅデバイスは、コンテンツを要求するＳｉｎｋデバイスの再生可能時間が、要求されたコンテンツの長さ（ｄｕｒａｔｉｏｎ）以上かどうかをチェックする（ステップＳ１８０６）。

再生可能時間がコンテンツの長さ（ｄｕｒａｔｉｏｎ）以上のときには（ステップＳ１８０６のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、Ｓｉｎｋデバイスからのコンテンツ要求を許可し、そのコンテンツの伝送を開始する（ステップＳ１８０７）。要求されたコンテンツの送信を例えばＨＴＴＰ ＧＥＴ ｒｅｓｐｏｎｓｅで行なう。

また、再生可能時間がコンテンツの長さ（ｄｕｒａｔｉｏｎ）を下回るときには（ステップＳ１８０６のＮｏ）、Ｓｏｕｒｃｅデバイスは、Ｓｉｎｋデバイスからのコンテンツ要求を許可せず、後続の処理をスキップして、本処理ルーチンを終了する。このとき、Ｓｏｕｒｃｅデバイスは、コンテンツ要求元のＳｉｎｋデバイスに、例えばＨＴＴＰ Ｓｔａｔｕｓ Ｃｏｄｅ ４０６などのエラー応答を返送するようにしてもよい（ステップＳ１８０８）。

また、図１９には、コンテンツ移動（ＭＯＶＥ）時においてＳＥＱ１３０４で実施するコンテンツ出力制御及び再生可能時間管理処理の手順をフローチャートの形式で示している。以下では、便宜上、Ｓｏｕｒｃｅデバイスとしてのサーバー２０１内で、例えばコンテンツ提供部３０４がコンテンツ出力制御及び再生可能時間管理処理を行なうものとして説明する。

Ｓｏｕｒｃｅデバイスは、コンテンツの移動が中止されず（ステップＳ１９０１のＮｏ）、且つ、コンテンツの移動が成功裏に終了すると（ステップＳ１９０２）、コンテンツ伝送先のＳｉｎｋデバイスの再生可能時間から、移動したコンテンツの長さ（ｄｕｒａｔｉｏｎ）を引いて（ステップＳ１９０３）、本処理ルーチンを終了する。

また、コンテンツの移動が成功しなかったときには（ステップ１７０２のＮｏ）、ステップＳ１９０１に戻り、Ｓｏｕｒｃｅデバイスは、コンテンツの移動を中止するかどうかを再度チェックする。

また、コンテンツの移動を中止するときには（ステップＳ１９０１のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、コンテンツ伝送先のＳｉｎｋデバイスの再生可能時間からコンテンツの長さ（ｄｕｒａｔｉｏｎ）を引くことなく、本処理ルーチンを終了する。

図１４〜図１９に示した処理手順は、コンテンツ伝送フェーズにおいてＳｏｕｒｃｅデバイスがＳｉｎｋデバイスの残りの再生可能時間に基づいてコンテンツの提供を制限して、遠隔地からのコンテンツの利用が永続できないようにしている。

これに対し、コンテンツ伝送フェーズに先行するコンテンツ・リスト閲覧フェーズ（図８を参照のこと）において、Ｓｏｕｒｃｅデバイスが、Ｓｉｎｋデバイスの残りの再生可能時間に基づいて、閲覧を許可するコンテンツ情報を制限するという変形例も考えられる。

例えば、Ｓｉｎｋデバイスは、ＣＤＳを要求する際に、自分のＳｉｎｋ−ＩＤをＨＴＴＰ ｒｅｑｕｅｓｔ中のヘッダー・フィールド（例えば、ＤＴＣＰＩＤ．ＡＲＩＢ．ＯＲ．ＪＰ）で含める。Ｓｏｕｒｃｅデバイスは、Ｓｉｎｋ−ＩＤに基づいて、要求元のＳｉｎｋデバイスの再生可能時間を取得すると、再生可能時間がゼロのＳｉｎｋデバイスにはＣＤＳを渡さない、あるいは再生可能時間よりも長いｄｕｒａｔｉｏｎのコンテンツを提供可能なものとして通知しない、といった制限をする。Ｓｉｎｋデバイス側では、（Ｓｏｕｒｃｅデバイスは提供可能であるが）自分には提供されないコンテンツの情報への閲覧が制限されることにより、そのコンテンツの要求が抑制される。

図２０には、コンテンツ・リスト閲覧フェーズ（ＳＥＱ８０１）において、Ｓｏｕｒｃｅデバイスが、リモート・アクセスするＳｉｎｋデバイスに対して、Ｓｉｎｋデバイスの再生可能時間に基づいてＣＤＳ情報の提供を制限するための処理手順をフローチャートの形式で示している。

まず、Ｓｏｕｒｃｅデバイスは、提供可能なコンテンツ情報をクリアする（ステップＳ２００１）。次いで、Ｓｏｕｒｃｅデバイスは、要求元のＳｉｎｋデバイスのＳｉｎｋ−ＩＤに対応する再生可能時間を、ｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙから取得する（ステップＳ２００２）。

ここで、Ｓｏｕｒｃｅデバイスは、要求元のＳｉｎｋデバイスの再生可能時間がゼロより大きいかどうかをチェックする（ステップＳ２００３）。再生可能時間がゼロのときには（ステップＳ２００３のＮｏ）、Ｓｏｕｒｃｅデバイスは、Ｓｉｎｋデバイスからのコンテンツ情報の要求を許可せず、後続の処理ステップＳ２００４〜Ｓ２００８をスキップして、本処理ルーチンを終了する。

一方、要求元のＳｉｎｋデバイスの再生可能時間がゼロより大きいときには（ステップＳ２００３のＹｅｓ）、すべてのコンテンツ情報を処理するまで（ステップＳ２００４のＮｏ）、コンテンツ情報の作成を行なう。すなわち、Ｓｏｕｒｃｅデバイスは、未処理のコンテンツのコンテンツ情報を参照すると（ステップＳ２００５）、そのコンテンツの長さ（ｄｕｒａｔｉｏｎ）をＣＤＳ中のｒｅｓ＠ｄｕｒａｔｉｏｎなどから取得する（ステップＳ２００６）。

そして、Ｓｏｕｒｃｅデバイスは、そのコンテンツの長さ（ｄｕｒａｔｉｏｎ）と、要求元のＳｉｎｋデバイスの再生可能時間と大小比較する（ステップＳ２００７）。

そのコンテンツの長さ（ｄｕｒａｔｉｏｎ）がＳｉｎｋデバイスの再生可能時間以下のときには（ステップＳ２００７のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、このコンテンツ情報を提供可能なコンテンツ情報に追加する（ステップＳ２００８）。そして、ステップＳ２００４に戻り、すべてのコンテンツ情報を処理したかどうかをチェックする。

一方、そのコンテンツの長さ（ｄｕｒａｔｉｏｎ）がＳｉｎｋデバイスの再生可能時間を超えているときには（ステップＳ２００７のＮｏ）、ステップＳ２００４に戻り、Ｓｏｕｒｃｅデバイスはすべてのコンテンツ情報を処理したかどうかをチェックする。但し、ストリーミング時に、図１３のコンテンツ出力制御及び再生可能時間管理の処理を図１５の処理で行なう場合は、コンテンツの長さ（ｄｕｒａｔｉｏｎ）がＳｉｎｋデバイスの再生可能時間を超えているときにコンテンツ移動を不可にして、このコンテンツ情報を提供可能なコンテンツ情報に追加することも考えられる。例えば、ＤＬＮＡ Ｇｕｉｄｅｌｉｎｅｓ Ｐａｒｔ４では、ｒｅｓ＠ｐｒｏｔｏｃｏｌＩｎｆｏ中のＤＴＣＰ．ＣＯＭ＿ＦＬＡＧＳ ｐａｒａｍのｂｉｔ３１のｓｅｔ／ｒｅｓｅｔがコンテンツの移動可能／不可を表すようになっている。

そして、すべてのコンテンツ情報の処理が終了したときには（ステップＳ２００４のＹｅｓ）、Ｓｏｕｒｃｅデバイスは、完成したコンテンツ情報を、要求元のＳｉｎｋデバイスに送信する（ステップＳ２００９）。

このように、長さ（ｄｕｒａｔｉｏｎ）が再生可能時間以下となるコンテンツだけに制限して、Ｓｉｎｋデバイスにコンテンツ情報を提供することによっても、遠隔地からのコンテンツの利用が永続できないようにすることができる。

Ｄ．再生可能時間の通知
本実施形態では、サーバー２０１は、再登録してきた端末２０２の再生可能時間を初期値にリセットして、旅行や出張の間にコンテンツを視聴したいユーザーの便宜を図るようにしている。

また、コンテンツ伝送中に、サーバー２０１は、再生可能時間の残りを端末２０２に通知するようにしてもよい。端末２０２側では、受信したコンテンツの再生中に再生可能時間を表示することで、ユーザーが気付かないうちにコンテンツを再生できなくなるということを防止するとともに、サーバー２０１への再登録を促すことができる。

例えば、サーバー２０１は、図２１に示すように、コンテンツ伝送を行なう際のＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）メッセージのヘッダー・フィールドなどに再生可能時間の情報を格納することができる。同図中、Ｓｉｎｋデバイスは端末２０２に相当し、Ｓｏｕｒｃｅデバイスはサーバー２０１に相当するものと理解されたい。

Ｓｉｎｋデバイスは、ＨＴＴＰ ＧＥＴメソッドを用いたＨＴＴＰリクエスト（ＨＴＴＰ ＧＥＴ ｒｅｑｕｅｓｔ）により、Ｓｏｕｒｃｅデバイスに対して、コンテンツの伝送を要求する（ＳＥＱ２２０１）。この要求の際には、コンテンツのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）とともに、リモート・アクセス用交換鍵Ｋ_RのＩＤであるラベルＫ_R＿ｌａｂｅｌを送る。ここで、ＳｉｎｋデバイスからＳｏｕｒｃｅデバイスに交換鍵のＩＤ（Ｋ_R＿ｌａｂｅｌ）を送るためのヘッダー・フィールドを定義する。

これに対し、Ｓｏｕｒｃｅデバイスは、このコンテンツ要求に含まれる交換鍵ラベルＫ_R＿ｌａｂｅｌに該当するＲＡＣ Ｒｅｃｏｒｄから、要求元ＳｉｎｋデバイスのＳｉｎｋ−ＩＤを特定する。そして、Ｓｉｎｋ−ＩＤとペアにしてｒｅｍｏｔｅ ｓｉｎｋ ｒｅｇｉｓｔｒｙに登録されている再生可能時間の現在値を取得すると、これをＨＴＴＰレスポンス（ＨＴＴＰ ＧＥＴ ｒｅｓｐｏｎｓｅ）のヘッダー・フィールドＲＳＲＲＥｍａｉｎＴｉｍｅ．ＡＲＩＢ．ＯＲ．ＪＰに含めてＳｉｎｋデバイスに伝送する（ＳＥＱ２２０２）。図示の例では、再生可能時間１２３４分が記載されている。

図２２には、Ｓｉｎｋデバイスが、Ｓｏｕｒｃｅデバイスから通知された再生可能時間を表示するための処理手順をフローチャートの形式で示している。

まず、Ｓｉｎｋデバイスは、再生対象コンテンツの長さ（ｄｕｒａｔｉｏｎ）を変数Ｄに格納する（ステップＳ２３０１）。コンテンツの長さ（ｄｕｒａｔｉｏｎ）は、例えばＣＤＳ中のｒｅｓ＠ｄｕｒａｔｉｏｎを参照することによって取得することができる。

次いで、Ｓｉｎｋデバイスは、ＨＴＴＰ ＧＥＴ ｒｅｓｐｏｎｓｅのヘッダー・フィールドに記載されている再生可能時間を変数Ｒに格納する（ステップＳ２３０２）。

そして、Ｓｉｎｋデバイスは、Ｄの値とＲの値を大小比較する（ステップＳ２３０３）。ここで、Ｄの方がＲよりも大きいときには（ステップＳ２３０３のＹｅｓ）、Ｓｉｎｋデバイスの残りの再生可能時間よりもコンテンツの長さ（ｄｕｒａｔｉｏｎ）の方が長く、コンテンツを最後まで再生できないことになる。そこで、Ｓｉｎｋデバイスは、再生対象のコンテンツを最後まで再生できないという警告を、例えばコンテンツ再生出力部４０５の表示部（前述）に表示する（ステップＳ２３０４）。

次いで、Ｓｉｎｋデバイスは、タイマー２をゼロから計時開始すると（ステップＳ２３０５）、コンテンツの受信している間に（ステップＳ２３０７のＮｏ）、Ｒからタイマー２の値を引いた値を現時点の再生可能時間として、例えばコンテンツ再生出力部４０５の表示部（前述）に表示し続ける（ステップＳ２３０６）。なお、図１３のコンテンツ出力制御及び再生可能時間管理を図１６及び図１７の処理で行なう場合は、タイマー２の値がＲより大きくなる場合があり得るが、その場合、再生可能時間はゼロと表示するものとする。

このように、本実施形態に係るコンテンツ伝送システムによれば、コンテンツ送信装置すなわちＳｏｕｒｃｅデバイスは、コンテンツ受信装置すなわちＳｉｎｋデバイスがリモート・アクセスによりコンテンツを受信する際の再生可能時間を制限することで、遠隔地からのコンテンツの利用が永続できないようにすることができる。また、コンテンツ受信装置において、残りの再生可能時間を通知することによって、ユーザーが知らないうちにコンテンツを再生できなくなるということを防ぐことができる。

Ｅ．コンテンツ送信装置の具体例
サーバー２０１若しくはＤＴＣＰのＳｏｕｒｃｅデバイスとして動作するコンテンツ送信装置の具体例は、セットトップボックスやレコーダー、テレビジョン受信機、パーソナル・コンピューター、ネットワーク・アクセス・サーバー（ＮＡＳ）などである。

図２３には、サーバー２０１若しくはＤＴＣＰのＳｏｕｒｃｅデバイスとして動作することが可能なパーソナル・コンピューター２４００の構成例を示している。パーソナル・コンピューター２４００はリモート・アクセス機能（前述）にも対応しているものとする。図示のパーソナル・コンピューター２４００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２４０１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２４０２、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）２４０３、ディスプレイ２４０４、スピーカー２４０５、例えばＨＤＤ（Ｈａｒｄ Ｄｉｓｃ Ｄｒｉｖｅ）やＳＤＤ（Ｓｕｐｅｒ Ｄｅｎｓｉｔｙ Ｄｉｓｃ）などの大容量情報記憶装置２４０６、Ｉ／Ｏインターフェース２４０７などの回路コンポーネントを備え、これらの回路コンポーネントがバス２４０８を介して相互接続されている。

ＣＰＵ２４０１は、メイン・メモリーとしてのＲＡＭ２４０２にロードされたプログラムを読み出して実行する。

ＲＡＭ２４０２には、コンテンツの暗号及び復号に関する機能がロードされる。例えば、ＤＴＣＰ−ＩＰ機能を実行するためのプログラム、及び、ＲＡ−ＡＫＥ処理を実行するためのプログラムがＲＡＭ２４０２にロードされる。また、ＳｉｎｋデバイスのＳｉｎｋ−ＩＤを再生可能時間とペアにして登録する際の認証シーケンス（図６を参照のこと）を実行するためのプログラムは、ＲＡ−ＡＫＥ処理を実行するためのプログラムの一部として、このＲＡＭ２４０２にロードされ、ＣＰＵ２４０１が実行する。

ＥＥＰＲＯＭ２４０３は、書き換えが可能な不揮発性記憶装置であり、設定情報などが記憶される。パーソナル・コンピューター２４００がＳｏｕｒｃｅデバイスすなわちコンテンツ送信装置として動作する場合、ＳｉｎｋデバイスのＳｉｎｋ−ＩＤが再生可能時間とペアにしてＥＥＰＲＯＭ２４０３に記憶される。

パーソナル・コンピューター２４００上では、Ｓｉｎｋデバイスから、リモート・アクセスが可能な端末として登録するよう要求を受けると、ＣＰＵ２４０１が、ＲＡＭ２４０２からＤＴＣＰ−ＩＰのＡＫＥ処理が記述されたプログラムを読み出し、Ｓｉｎｋデバイスとの間でＡＫＥ手続きを実行する。

この手続きに成功すると、ＣＰＵ２４０１は、ＲＡＭ２４０２に記憶されたプログラムに従って、Ｓｉｎｋデバイスに再生可能時間（初期値）を付与し、Ｓｉｎｋ−ＩＤとペアにしてＥＥＰＲＯＭ２４０３に記憶する。

その後、パーソナル・コンピューター２４００上では、ＣＰＵ２４０１が、ＲＡ−ＡＫＥ処理の要求を受けた場合に、この要求を行なっているＳｉｎｋデバイスのＳｉｎｋ−ＩＤと、ＥＥＰＲＯＭ８３に記憶されたＳｉｎｋ−ＩＤと比較し、ＲＡ−ＡＫＥ処理を完了させるか否かを決定する処理を実行する。

そして、ＲＡ−ＡＫＥ処理が完了すると、パーソナル・コンピューター２４００と、ＲＡ−ＡＫＥ処理の要求を行なったＳｉｎｋデバイスとの間で共通するコンテンツ鍵が生成される。パーソナル・コンピューター２４００側では、生成されたコンテンツ鍵を一時的に記憶し、大容量情報記憶装置２４０６からコンテンツを読み出したときに、このコンテンツを一時的に記憶されたコンテンツ鍵で暗号化する。暗号化されたコンテンツは、Ｉ／Ｏインターフェース２４０８を経て、外部に出力される。Ｉ／Ｏインターフェース２４０８が無線ＬＡＮ機能を有している場合、無線ＬＡＮを介して、ＲＡ−ＡＫＥ処理の要求を行なったＳｉｎｋデバイスに対し、暗号化コンテンツが送信される。

図２４には、サーバー２０１若しくはＤＴＣＰのＳｏｕｒｃｅデバイスとして動作することが可能なレコーダー２５００の構成例を示している。レコーダー２５００はリモート・アクセス機能（前述）にも対応しているものとする。図示のレコーダー２５００は、システム・チップ２５０１、大容量記憶装置２５０２、ＲＡＭ２５０３、ＥＥＰＲＯＭ２５０４、無線ＬＡＮチップ２５０５又はＬＡＮポート２５０９のうち少なくとも一方、チューナー２５０６、ディスプレイ２５０７、スピーカー２５０８を備えている。

システム・チップ２５０１は、ＣＰＵ２５０１ａ、コプロセッサー２５０１ｂ、インターフェース機能部２５０１ｃなどの回路モジュールを備え、これらの回路モジュールは、当該チップ内のバス２５０１ｄで相互接続されている。

ＣＰＵ２５０１ａは、インターフェース機能部２５０１ｃを介して接続された記憶装置に記憶されたプログラムを実行することが可能である。

コプロセッサー２５０１ｂは、補助演算装置であり、主に動画像の圧縮又は復号処理を実行する。例えば、Ｈ２６４、ＶＣ１、ＭＰＥＧ２、ＪＰＥＧなどのアルゴリズムを実行する。また、コプロセッサー２５０１ｂは、（大容量記憶装置２５０２に記憶された）動画像コンテンツをＳｉｎｋデバイスなどのコンテンツ受信装置に伝送する際には、通信速度などの通信環境に応じて画像のサイズを変換して、通信環境に最適なサイズで送信できるようにする処理、すなわちコーデックのトランスコーディングを行なう。コーデックのトランスコードにより、Ｓｉｎｋデバイスなどのコンテンツ伝送先での再生の遅れを軽減することができる。但し、コーデックのトランスコーディングは、コプロセッサー２５０１ｂのような専用ハードウェアではなく、ＣＰＵ２５０１ａで行なうようにすることもできる。また、コンテンツのトランスコーディングを行なう圧縮率は、ユーザーがコンテンツ毎に指定することも可能である。

大容量記憶装置２５０２は、例えばＨＤＤやＳＤＤなどであるが、Ｓｉｎｋデバイス若しくはコンテンツ受信装置に提供するコンテンツを記憶する。

チューナー２５０６は、地上ディジタル放送などの放送信号を選局受信する。本実施形態では、例えばＥＰＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅ）などの機能に従って、番組を録画又は録画予約して、放送コンテンツを大容量記憶装置２５０２に記憶する。

チューナー２５０６で受信する放送番組や、大容量記憶装置２５０２に記憶したコンテンツは、ディスプレイ２５０７並びに２５０８を使って視聴することも可能である。

無線ＬＡＮチップ２５０５は、例えばＷｉ−Ｆｉ（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ）若しくはＩＥＥＥ８０２．１１などの無線ＬＡＮ規格における物理層並びにＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）層の処理を行ない、所定のアクセスポイント経由で、あるいはＳｉｎｋデバイスとしてのコンテンツ受信装置と直接無線接続する。また、ＬＡＮポート２５０９は、差し込まれたＬＡＮケーブル２５０９Ａを介してＥｔｈｅｒｎｅｔ（登録商標）などの有線ＬＡＮ（図示しない）に接続されるとともに、例えばＩＥＥＥ８０２．３などの有線ＬＡＮ規格における物理層並びにＭＡＣ層の処理を行ない、Ｓｉｎｋデバイスとしてのコンテンツ受信装置と通信する。

メイン・メモリーとしてのＲＡＭ２５０３には、ＣＰＵ２５０１ａで実行されるプログラムがロードされる。ＲＡＭ２５０３にロードされる主なプログラムは、コンテンツの暗号及び復号に関する機能を実現するプログラムであり、例えば、ＤＴＣＰ−ＩＰ機能を実行するためのプログラム、及び、ＲＡ−ＡＫＥ処理を実行するためのプログラムがＲＡＭ２５０３にロードされる。

ＥＥＰＲＯＭ２５０４は、書き換えが可能な不揮発性記憶装置であり、設定情報などが記憶される。レコーダー２５００がＳｏｕｒｃｅデバイスすなわちコンテンツ送信装置として動作する場合、ＳｉｎｋデバイスのＳｉｎｋ−ＩＤが再生可能時間とペアにしてＥＥＰＲＯＭ２５０４に記憶される。

レコーダー２５００上では、Ｓｉｎｋデバイスから、リモート・アクセスが可能な端末として登録するよう要求を受けると、ＣＰＵ２５０１ａが、ＲＡＭ２５０３からＤＴＣＰ−ＩＰのＡＫＥ処理が記述されたプログラムを読み出し、Ｓｉｎｋデバイスとの間でＡＫＥ手続きを実行する。

この手続きに成功すると、ＣＰＵ２５０１ａは、ＲＡＭ２５０３に記憶されたプログラムに従ってＳｉｎｋデバイスに再生可能時間（初期値）を付与し、Ｓｉｎｋ−ＩＤとペアにしてＥＥＰＲＯＭ２５０４に記憶する。

その後、レコーダー２５００上では、ＣＰＵ２５０１ａが、ＲＡ−ＡＫＥ処理の要求を受けた場合に、この要求を行なっているＳｉｎｋデバイスのＳｉｎｋ−ＩＤと、ＥＥＰＲＯＭ２５０４に記憶されたＳｉｎｋデバイスのＳｉｎｋＩＤを比較し、ＲＡ−ＡＫＥ処理を完了させるか否かを決定する処理を実行する。

そして、ＲＡ−ＡＫＥ処理が完了すると、レコーダー２５００と、ＲＡ−ＡＫＥ処理の要求を行なったＳｉｎｋデバイスとの間で共通するコンテンツ鍵が生成される。レコーダー２５００側では、生成されたコンテンツ鍵を一時的に記憶し、大容量情報記憶装置２５０２からコンテンツを読み出したときに、このコンテンツを一時的に記憶されたコンテンツ鍵で暗号化する。暗号化されたコンテンツは、インターフェース機能部２５０１ｃ及び無線ＬＡＮチップ２５０５を経て、ＲＡ−ＡＫＥ処理の要求を行なった端末に対し、暗号化コンテンツが送信される。

図２５には、サーバー２０１若しくはＤＴＣＰのＳｏｕｒｃｅデバイスとして動作することが可能なネットワーク・アクセス・サーバー（ＮＡＳ）２６００の構成例を示している。

ネットワーク・アクセス・サーバー２６００は、大容量記憶装置を備え、ホーム・ネットワーク１１０、２１０内に設置されて、大容量記憶装置内の情報をＩＰプロトコルに従って伝送する。例えば、レコーダー２５００で録画した放送コンテンツをネットワーク・アクセス・サーバー２６００にダビングしたり、ネットワーク・アクセス・サーバー２６００内に記憶したコンテンツをパーソナル・コンピューター２４００やスマートフォンなどのＳｉｎｋデバイスに伝送して視聴したりすることができる。また、ネットワーク・アクセス・サーバー２６００は、ネットワーク・アクセス・サーバー２６００はリモート・アクセス機能（前述）にも対応しているものとする。

図示のネットワーク・アクセス・サーバー２６００は、システム・チップ２６０１、大容量記憶装置２６０２、ＲＡＭ２６０３、ＥＥＰＲＯＭ２６０４、無線ＬＡＮチップ２６０５又はＬＡＮポート２６０６のうち少なくとも一方を備えている。

システム・チップ２６０１は、ＣＰＵ２６０１ａ、コプロセッサー２６０１ｂ、インターフェース機能部２６０１ｃなどの回路モジュールを備え、これらの回路モジュールは、当該チップ内のバス２６０１ｄで相互接続されている。

ＣＰＵ２６０１ａは、インターフェース機能部２６０１ｃを介して接続された記憶装置に記憶されたプログラムを実行することが可能である。

コプロセッサー２６０１ｂは、補助演算装置であり、主に動画像の圧縮又は復号処理を実行する。例えば、Ｈ２６４、ＶＣ１、ＭＰＥＧ２、ＪＰＥＧなどのアルゴリズムを実行する。また、コプロセッサー２６０１ｂは、（大容量記憶装置２６０２に記憶された）動画像コンテンツをＳｉｎｋデバイスなどのコンテンツ受信装置に伝送する際には、通信速度などの通信環境に応じて画像のサイズを変換して、通信環境に最適なサイズで送信できるようにする処理、すなわちコーデックのトランスコーディングを行なう。コーデックのトランスコードにより、Ｓｉｎｋデバイスなどのコンテンツ伝送先での再生の遅れを軽減することができる。但し、コーデックのトランスコーディングは、コプロセッサー２６０１ｂのような専用ハードウェアではなく、ＣＰＵ２６０１ａで行なうようにすることもできる。また、コンテンツのトランスコーディングを行なう圧縮率は、ユーザーがコンテンツ毎に指定することも可能である。

大容量記憶装置２６０２は、例えばＨＤＤやＳＤＤなどであるが、Ｓｉｎｋデバイス若しくはコンテンツ受信装置に提供するコンテンツを記憶する。例えば、レコーダー２５００で録画した放送コンテンツを、（無線ＬＡＮチップ２６０５経由で受信して）大容量記憶装置２６０２にダビングすることもできる。

無線ＬＡＮチップ２６０５は、例えばＷｉ−Ｆｉ（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ）若しくはＩＥＥＥ８０２．１１などの無線ＬＡＮ規格における物理層並びにＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）層の処理を行ない、所定のアクセスポイント経由で、あるいはＳｉｎｋデバイスとしてのコンテンツ受信装置と直接無線接続する。また、ＬＡＮポート２６０６は、差し込まれたＬＡＮケーブル２６０６Ａを介してＥｔｈｅｒｎｅｔ（登録商標）などの有線ＬＡＮ（図示しない）に接続されるとともに、例えばＩＥＥＥ８０２．３などの有線ＬＡＮ規格における物理層並びにＭＡＣ層の処理を行ない、Ｓｉｎｋデバイスとしてのコンテンツ受信装置と通信する。

メイン・メモリーとしてのＲＡＭ２６０３には、ＣＰＵ２６０１ａで実行されるプログラムがロードされる。ＲＡＭ２６０３にロードされる主なプログラムは、コンテンツの暗号及び復号に関する機能を実現するプログラムであり、例えば、ＤＴＣＰ−ＩＰ機能を実行するためのプログラム、及び、ＲＡ−ＡＫＥ処理を実行するためのプログラムがＲＡＭ２６０３にロードされる。

ＥＥＰＲＯＭ２６０４は、書き換えが可能な不揮発性記憶装置であり、設定情報などが記憶される。ネットワーク・アクセス・サーバー２６００がＳｏｕｒｃｅデバイスすなわちコンテンツ送信装置として動作する場合、ＳｉｎｋデバイスのＳｉｎｋ−ＩＤが再生可能時間とペアにしてＥＥＰＲＯＭ２６０４に記憶される。

ネットワーク・アクセス・サーバー２６００上では、Ｓｉｎｋデバイスから、リモート・アクセスが可能な端末として登録するよう要求を受けると、ＣＰＵ２６０１ａが、ＲＡＭ２６０３からＤＴＣＰ−ＩＰのＡＫＥ処理が記述されたプログラムを読み出し、Ｓｉｎｋデバイスとの間でＡＫＥ手続きを実行する。

この手続きに成功すると、ＣＰＵ２６０１ａは、ＲＡＭ２６０３に記憶されたプログラムに従ってＳｉｎｋデバイスに再生可能時間（初期値）を付与し、Ｓｉｎｋ−ＩＤとペアにしてＥＥＰＲＯＭ２６０４に記憶する。

その後、ネットワーク・アクセス・サーバー２６００上では、ＣＰＵ２５０１ａが、ＲＡ−ＡＫＥ処理の要求を受けた場合に、この要求を行なっているＳｉｎｋデバイスのＳｉｎｋ−ＩＤと、ＥＥＰＲＯＭ２６０４に記憶されたＳｉｎｋデバイスのＳｉｎｋＩＤを比較し、ＲＡ−ＡＫＥ処理を完了させるか否かを決定する処理を実行する。

そして、ＲＡ−ＡＫＥ処理が終了すると、ネットワーク・アクセス・サーバー２６００と、ＲＡ−ＡＫＥ処理の要求を行なったＳｉｎｋデバイスとの間で共通するコンテンツ鍵が生成される。ネットワーク・アクセス・サーバー２６００側では、生成されたコンテンツ鍵を一時的に記憶し、大容量情報記憶装置２６０２からコンテンツを読み出したときに、このコンテンツを一時的に記憶されたコンテンツ鍵で暗号化する。暗号化されたコンテンツは、インターフェース機能部２６０１ｃ及び無線ＬＡＮチップ２６０５を経て、ＲＡ−ＡＫＥ処理の要求を行なった端末に対し、暗号化コンテンツが送信される。

以上、特定の実施形態を参照しながら、本明細書で開示する技術について詳細に説明してきた。しかしながら、本明細書で開示する技術の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。

本明細書では、本明細書で開示する技術をＤＴＣＰ並びにＤＴＣＰ−ＩＰ仕様のネットワークに適用した実施形態を中心に説明してきたが、本明細書で開示する技術の要旨はこれに限定されるものではない。ＤＴＣＰ−ＩＰ以外の、ホーム・ネットワーク内のコンテンツへのリモート・アクセスに制限が課されるさまざまな通信システムにも、同様に本明細書で開示する技術で開示する技術を適用することができる。

また、本明細書で開示する技術の適用範囲は、ホーム・ネットワークへのリモート・アクセスに限定されない。ホーム・ネットワーク内でのローカル・アクセス時においても、端末毎の再生可能時間に基づいてコンテンツの利用を制限したい場合に、同様に本明細書で開示する技術を適用することができる。

要するに、例示という形態により本明細書で開示する技術について説明してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本明細書で開示する技術の要旨を判断するためには、特許請求の範囲を参酌すべきである。

なお、本明細書の開示の技術は、以下のような構成をとることも可能である。
（１）サーバーが付与した再生可能時間の範囲内で前記サーバーからコンテンツを受信するコンテンツ取得部と、
コンテンツを再生するコンテンツ再生出力部と、
を具備するコンテンツ受信装置。
（２）所定の相互認証及び鍵交換手続きに従って端末を認証するとともに交換鍵を共有する認証及び鍵共有部と、
前記コンテンツ取得部が前記サーバーから取得した暗号化コンテンツを、前記交換鍵を用いて復号するコンテンツ復号部と、
をさらに備える上記（１）に記載のコンテンツ受信装置。
（３）前記認証及び鍵共有部は、ＤＴＣＰ−ＩＰが規定する認証及び鍵交換（ＡＫＥ）アルゴリズムに従ってサーバーと相互認証並びに交換鍵の共有を行なうとともに、ＤＴＣＰ−ＩＰが規定する手続きに従って前記サーバーに登録する際に再生可能時間が付与される、
上記（２）に記載のコンテンツ受信装置。
（４）前記認証及び鍵共有部は、ホーム・ネットワーク内でサーバーに登録し、
前記コンテンツ取得部は、登録が済んだサーバーから、外部ネットワーク経由でコンテンツを取得する、
上記（１）に記載のコンテンツ受信装置。
（５）前記認証及び鍵共有部がサーバーに登録する際に、前記サーバーから再生可能時間の初期値が付与される、
上記（４）に記載のコンテンツ受信装置。
（６）前記認証及び鍵共有部がサーバーに再登録することにより、再生可能時間が初期値にリセットされる、
上記（５）に記載のコンテンツ受信装置。
（７）前記コンテンツ取得部は、再生可能時間がゼロになるまで、コンテンツの受信が許可される、
上記（４）に記載のコンテンツ受信装置。
（８）前記コンテンツ取得部がコンテンツの受信を終了又は停止したときに、再生可能時間から受信したコンテンツの再生時間が引かれる、
上記（７）に記載のコンテンツ受信装置。
（９）前記コンテンツ取得部は、再生可能時間より短いコンテンツを、再生可能時間からコンテンツの長さが引かれた後に、受信する、
上記（４）に記載のコンテンツ受信装置。
（１０）前記コンテンツ取得部がコンテンツの受信を終了又は停止したときに、コンテンツの長さから受信したコンテンツの再生時間を引いた値が再生可能時間に足される、
上記（９）に記載のコンテンツ受信装置。
（１１）前記コンテンツ取得部は、再生可能時間より短いコンテンツの移動を許可される、
上記（４）に記載のコンテンツ受信装置。
（１２）前記コンテンツ取得部が移動により受信したコンテンツの長さが再生可能時間から引かれる、
上記（１１）に記載のコンテンツ受信装置。
（１３）再生可能時間がゼロになると、サーバーの登録が削除される、
上記（４）に記載のコンテンツ受信装置。
（１４）表示部をさらに備え、
コンテンツ取得部がサーバーからコンテンツを受信する際に、再生可能時間の情報を受け取り、前記表示部に表示する、
上記（１）に記載のコンテンツ受信装置。
（１４−１）再生可能時間より長いコンテンツを前記コンテンツ再生出力部で再生するときに、コンテンツを最後まで再生できないことを通知する警告を前記表示部で表示する、
上記（１４）に記載のコンテンツ受信装置。
（１４−２）受け取った再生可能時間からコンテンツを再生した時間を引いた値を現時点での再生可能時間として前記表示部で表示する、
上記（１４）に記載のコンテンツ受信装置。
（１５）サーバーから取得可能なコンテンツに関する情報を前記サーバーから取得するコンテンツ情報取得部をさらに備え、
コンテンツ取得部は、閲覧しているコンテンツ情報を介して前記サーバーにコンテンツを要求する、
上記（１）に記載のコンテンツ受信装置。
（１６）前記コンテンツ情報取得部は、現在の再生可能時間に基づいてコンテンツ情報の取得が制限される、
上記（１５）に記載のコンテンツ受信装置。
（１７）前記コンテンツ情報取得部は、現在の再生可能時間よりも短いコンテンツのみコンテンツ情報を取得できる、
上記（１５）に記載のコンテンツ受信装置。
（１８）前記コンテンツ情報取得部は、再生可能時間がゼロになると、コンテンツ情報を取得できなくなる、
上記（１５）に記載のコンテンツ受信装置。
（１９）サーバーに付与された再生可能時間の範囲内で前記サーバーからコンテンツを受信するコンテンツ取得ステップと、
取得したコンテンツを再生するコンテンツ再生出力ステップと、
を有するコンテンツ受信方法。
（２０）サーバーに付与された再生可能時間の範囲内で前記サーバーからコンテンツを受信するコンテンツ取得部、
取得したコンテンツを再生するコンテンツ再生出力部、
としてコンピューターを機能させるようにコンピューター可読形式で記述されたコンピューター・プログラム。

１００…コンテンツ伝送システム
１０１…サーバー、１０２…端末、１１０…ホーム・ネットワーク
２０１…サーバー、２０２…端末
２００…コンテンツ伝送システム
２０１…サーバー、２０２…端末
２１０…ホーム・ネットワーク、２２０…外部ネットワーク
２３０…ルーター
３００…コンテンツ送信装置（Ｓｏｕｒｃｅデバイス）
３０１…通信・制御部、３０２…コンテンツ記録部
３０３…コンテンツ取得部、３０４…コンテンツ提供部
３０５…コンテンツ・リスト提供部、３０６…認証・鍵共有部
３０７…端末管理部
４００…コンテンツ受信装置
４０１…通信・制御部
４０２…コンテンツ・リスト閲覧部、４０３…コンテンツ取得部
４０４…コンテンツ復号部、４０５…コンテンツ再生出力部
４０６…認証・鍵共有部、４０７…入力部
２４００…パーソナル・コンピューター、２４０１…ＣＰＵ
２４０２…ＲＡＭ、２４０３…ＥＥＰＲＯＭ、２４０４…ディスプレイ
２４０５…スピーカー、２４０６…大容量記憶装置
２４０７…Ｉ／Ｏインターフェース、２４０８…バス
２５００…レコーダー、２５０１…システム・チップ、２５０１ａ…ＣＰＵ、
２５０１ｂ…コプロセッサー、２５０１ｃ…インターフェース機能部
２５０１ｄ…バス、２５０２…大容量記憶装置、２５０３…ＲＡＭ
２５０４…ＥＥＰＲＯＭ、２５０５…無線ＬＡＮチップ
２５０６…チューナー、２５０７…ディスプレイ、２５０８…スピーカー
２５０９…ＬＡＮポート、２５０９Ａ…ＬＡＮケーブル
２６００…ネットワーク・アクセス・サーバー
２６０１…システム・チップ、２６０１ａ…ＣＰＵ、
２６０１ｂ…コプロセッサー、２６０１ｃ…インターフェース機能部
２６０１ｄ…バス、２６０２…大容量記憶装置、２６０３…ＲＡＭ
２６０４…ＥＥＰＲＯＭ、２６０５…無線ＬＡＮチップ
２６０６…ＬＡＮポート、２６０６Ａ…ＬＡＮケーブル
２７００…コンピューター・プログラム配信システム、２７１０…サーバー
２７１１…記憶装置、２７１２…通信装置、２７１３…情報通知装置

Claims (20)

1. サーバーが付与した再生可能時間の範囲内で前記サーバーからコンテンツを受信するコンテンツ取得部と、
   コンテンツを再生するコンテンツ再生出力部と、
   を具備するコンテンツ受信装置。
2. 所定の相互認証及び鍵交換手続きに従って端末を認証するとともに交換鍵を共有する認証及び鍵共有部と、
   前記コンテンツ取得部が前記サーバーから取得した暗号化コンテンツを、前記交換鍵を用いて復号するコンテンツ復号部と、
   をさらに備える請求項１に記載のコンテンツ受信装置。
3. 前記認証及び鍵共有部は、ＤＴＣＰ−ＩＰが規定する認証及び鍵交換（ＡＫＥ）アルゴリズムに従ってサーバーと相互認証並びに交換鍵の共有を行なうとともに、ＤＴＣＰ−ＩＰが規定する手続きに従って前記サーバーに登録する際に再生可能時間が付与される、
   請求項２に記載のコンテンツ受信装置。
4. 前記認証及び鍵共有部は、ホーム・ネットワーク内でサーバーに登録し、
   前記コンテンツ取得部は、登録が済んだサーバーから、外部ネットワーク経由でコンテンツを取得する、
   請求項１に記載のコンテンツ受信装置。
5. 前記認証及び鍵共有部がサーバーに登録する際に、前記サーバーから再生可能時間の初期値が付与される、
   請求項４に記載のコンテンツ受信装置。
6. 前記認証及び鍵共有部がサーバーに再登録することにより、再生可能時間が初期値にリセットされる、
   請求項５に記載のコンテンツ受信装置。
7. 前記コンテンツ取得部は、再生可能時間がゼロになるまで、コンテンツの受信が許可される、
   請求項４に記載のコンテンツ受信装置。
8. 前記コンテンツ取得部がコンテンツの受信を終了又は停止したときに、再生可能時間から受信したコンテンツの再生時間が引かれる、
   請求項７に記載のコンテンツ受信装置。
9. 前記コンテンツ取得部は、再生可能時間より短いコンテンツを、再生可能時間からコンテンツの長さが引かれた後に、受信する、
   請求項４に記載のコンテンツ受信装置。
10. 前記コンテンツ取得部がコンテンツの受信を終了又は停止したときに、コンテンツの長さから受信したコンテンツの再生時間を引いた値が再生可能時間に足される、
    請求項９に記載のコンテンツ受信装置。
11. 前記コンテンツ取得部は、再生可能時間より短いコンテンツの移動を許可される、
    請求項４に記載のコンテンツ受信装置。
12. 前記コンテンツ取得部が移動により受信したコンテンツの長さが再生可能時間から引かれる、
    請求項１１に記載のコンテンツ受信装置。
13. 再生可能時間がゼロになると、サーバーの登録が削除される、
    請求項４に記載のコンテンツ受信装置。
14. 表示部をさらに備え、
    コンテンツ取得部がサーバーからコンテンツを受信する際に、再生可能時間の情報を受け取り、前記表示部に表示する、
    請求項１に記載のコンテンツ受信装置。
15. サーバーから取得可能なコンテンツに関する情報を前記サーバーから取得するコンテンツ情報取得部をさらに備え、
    コンテンツ取得部は、閲覧しているコンテンツ情報を介して前記サーバーにコンテンツを要求する、
    請求項１に記載のコンテンツ受信装置。
16. 前記コンテンツ情報取得部は、現在の再生可能時間に基づいてコンテンツ情報の取得が制限される、
    請求項１５に記載のコンテンツ受信装置。
17. 前記コンテンツ情報取得部は、現在の再生可能時間よりも短いコンテンツのみコンテンツ情報を取得できる、
    請求項１５に記載のコンテンツ受信装置。
18. 前記コンテンツ情報取得部は、再生可能時間がゼロになると、コンテンツ情報を取得できなくなる、
    請求項１５に記載のコンテンツ受信装置。
19. サーバーに付与された再生可能時間の範囲内で前記サーバーからコンテンツを受信するコンテンツ取得ステップと、
    取得したコンテンツを再生するコンテンツ再生出力ステップと、
    を有するコンテンツ受信方法。
20. サーバーに付与された再生可能時間の範囲内で前記サーバーからコンテンツを受信するコンテンツ取得部、
    取得したコンテンツを再生するコンテンツ再生出力部、
    としてコンピューターを機能させるようにコンピューター可読形式で記述されたコンピューター・プログラム。