JP2015103890A - コンテンツ受信装置及びコンテンツ受信方法、並びにコンテンツ送信装置及びコンテンツ送信方法 - Google Patents

コンテンツ受信装置及びコンテンツ受信方法、並びにコンテンツ送信装置及びコンテンツ送信方法 Download PDF

Info

Publication number
JP2015103890A
JP2015103890A JP2013241552A JP2013241552A JP2015103890A JP 2015103890 A JP2015103890 A JP 2015103890A JP 2013241552 A JP2013241552 A JP 2013241552A JP 2013241552 A JP2013241552 A JP 2013241552A JP 2015103890 A JP2015103890 A JP 2015103890A
Authority
JP
Japan
Prior art keywords
content
authentication
unit
receiving device
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2013241552A
Other languages
English (en)
Inventor
中野　雄彦
Katsuhiko Nakano
雄彦 中野
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP2013241552A priority Critical patent/JP2015103890A/ja
Priority to US14/538,442 priority patent/US20150149778A1/en
Publication of JP2015103890A publication Critical patent/JP2015103890A/ja
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/082—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying multi-factor authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

【課題】端末は受信したコンテンツを所定の制限下で好適に利用し、サーバーは送信したコンテンツの利用に所定の制限を課す。
【解決手段】端末２０２は、再生しようとするコンテンツのダウンロード元であるサーバー２０１とリモート認証を実行し、リモート認証で得られた交換鍵を付けてコンテンツのストリーミング要求を疑似的に行なう。端末２０２は、サーバー２０１とのリモート認証に成功しなければダウンロードしたコンテンツを再生しないので、ダウンロードしたコンテンツが無制限に利用されないようにすることができる。
【選択図】 図１

Description

本明細書で開示する技術は、受信したコンテンツを所定の制限下で利用するコンテンツ受信装置及びコンテンツ受信方法、並びに、送信したコンテンツの利用に所定の制限を課すに関する。
ディジタル化されたコンテンツは、コピーや改竄などの不正な操作が比較的容易である。したがって、個人的又は家庭的なコンテンツの使用を許容しながら、コンテンツ伝送に介在する不正利用の防止、すなわち著作権保護の仕組みが必要である。ディジタル・コンテンツの伝送保護に関する業界標準的な技術として、ＤＴＬＡ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｌｉｃｅｎｓｉｎｇ Ａｄｍｉｎｉｓｔｒａｔｏｒ）が開発したＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）が挙げられる。
ＤＴＣＰでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決められている。その規定は、要約すれば、ＤＴＣＰ準拠機器は取り扱いが容易な圧縮コンテンツを非暗号の状態で機器外に送出しないことと、暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ：ＡＫＥ）アルゴリズムに従って行なうこと、並びにＡＫＥコマンドにより鍵交換を行なう機器の範囲を制限することなどである。
ＤＴＣＰは、原初的には、ＩＥＥＥ１３９４などを伝送路に用いたホーム・ネットワーク上におけるコンテンツ伝送について規定したものである。例えば、家庭内の異種の情報機器の相互接続を規定するＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）では、圧縮したコンテンツの暗号化伝送にＤＴＣＰが利用される。最近では、家庭内に蓄積したディジタル・コンテンツをＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワーク経由で遠隔地からも利用（すなわち、リモート・アクセス）できるようにする動きが本格的になっている。そこで、ＤＴＣＰ技術をＩＰネットワークに移植した、ＤＴＣＰ−ＩＰ（ＤＴＣＰ ｍａｐｐｉｎｇ ｔｏ ＩＰ）によるリモート・アクセス機能を盛り込んだＤＴＣＰ＋（以下、ＤＴＣＰ＋とする）の開発が進められている。
例えば、ホーム・サーバーに蓄積された放送コンテンツや映画などの商用コンテンツを、携帯電話や多機能端末などのモバイル機器を使って遠隔地から視聴する場合、私的利用の範囲を超え、無制限に利用されないように制御することが望まれている。
ＤＴＣＰ＋では、第三者によるコンテンツの利用を制限することを意図して、家庭内のサーバーへのリモート・アクセスを、そのサーバーに登録した端末だけに限定している。また、端末を家庭内のサーバーに登録する際において、コマンドの往復遅延時間（ＲＴＴ：Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）を最大７ミリ秒に制限するとともに、ＩＰルーターのホップ回数で表されるパケットの伝送制限（ＴＴＬ： Ｔｉｍｅ Ｔｏ Ｌｉｖｅ）が課されている。
例えば、認証の際に、認証要求若しくは認証応答の送信に対する受信確認の到達までの時間が一定の上限値を超えない場合に限り、共有化した鍵データによって暗号化されたコンテンツの伝送を行なうとともに、アドレス情報と装置固有の機器情報を登録して、再度コンテンツを伝送するときには時間の上限値の制限を課さないで暗号化されたコンテンツを伝送するコンテンツ送信装置について提案がなされている（例えば、特許文献１を参照のこと）。
また、リモート・アクセス時における認証手続きにおいて、上記のＲＴＴ並びにＴＴＬの制限を解除してリモート・アクセス用の鍵共有を可能にする一方、リモート・アクセスする端末のサーバーへの事前登録、コンテンツのリモート・アクセス利用数制限、鍵供給数制限を課して、不特定多数のユーザーからのリモート・アクセスを制限するようにしたコンテンツ伝送システムについて提案がなされている（例えば、特許文献２を参照のこと）。
しかしながら、現在のＤＴＣＰ＋規格によると、端末の家庭内のサーバーへの登録は一度だけ行なえば、以後は再び登録を行なわずに、リモート・アクセスによりホーム・サーバー内のコンテンツを永続的に利用することができる。このため、第三者の端末をサーバーに一度登録すれば、以後はその第三者がホーム・サーバー内のコンテンツを永続的に利用できてしまうという問題がある。
特開２００５−２０４０９４号公報 特開２０１１−８２９５２号公報
本明細書で開示する技術の目的は、受信したコンテンツを所定の制限下で好適に利用することができる、優れたコンテンツ受信装置及びコンテンツ受信方法を提供することにある。
本明細書で開示する技術のさらなる目的は、送信したコンテンツの利用に所定の制限を課すことができる、優れたコンテンツ送信装置及びコンテンツ送信方法を提供することにある。
本願は、上記課題を参酌してなされたものであり、請求項１に記載の技術は、
コンテンツ送信装置と通信する通信部と、
前記コンテンツ送信装置と相互認証する認証部と、
コンテンツを記録するコンテンツ記録部と、
コンテンツを再生するコンテンツ再生出力部と、
を具備し、
前記認証部が前記コンテンツ送信装置と第１の認証を行なった後に前記コンテンツ送信装置からコンテンツを受信して前記コンテンツ記録部に記録するとともに、前記認証部が前記コンテンツ送信装置と第２の認証を含む処理を実行した後に前記コンテンツ記録部に記録した前記コンテンツを再生する、
コンテンツ受信装置である。
本願の請求項２に記載の技術によれば、請求項１に記載のコンテンツ受信装置は、前記コンテンツ記録部に記録する前記コンテンツを、前記第２の認証を含む処理を実行して得た交換鍵を保持する期間以外に再生できないように管理するように構成されている。
本願の請求項３に記載の技術によれば、請求項２に記載のコンテンツ受信装置は、前記コンテンツを前記コンテンツ受信装置に固有の秘密鍵で暗号化して前記コンテンツ記録部に記録するように構成されている。
本願の請求項４に記載の技術によれば、請求項１に記載のコンテンツ受信装置は、前記認証部が第１の認証を行なって前記コンテンツ送信装置から前記コンテンツを受信したときに、第２の認証を含む処理を実行した後に再生処理に用いられる情報を記憶しておくように構成されている。
本願の請求項５に記載の技術によれば、請求項４に記載のコンテンツ受信装置は、前記の再生処理に用いられる情報として、前記コンテンツ送信装置の第１の識別情報を記憶し、前記認証部は、記憶した前記第１の識別情報を持つ前記コンテンツ送信装置に対して前記第２の認証を含む処理を実行するように構成されている。
本願の請求項６に記載の技術によれば、請求項４に記載のコンテンツ受信装置は、前記の再生処理に用いられる情報として、前記第１の認証において前記コンテンツ送信装置から受信した機器証明書に含まれる第２の識別情報を記憶し、前記認証部は、前記第２の認証において前記コンテンツ送信装置から受信した機器証明書に含まれる識別情報が前記の記憶した識別情報と一致するかどうかをチェックするように構成されている。
本願の請求項７に記載の技術によれば、請求項５に記載のコンテンツ受信装置は、コンテンツのＵＲＬ及びコンテンツの選択に有用なＵＩ情報を含むコンテンツ情報を取得するコンテンツ情報取得部をさらに備えている。そして、前記の再生処理に用いられる情報として、前記コンテンツのＵＲＬ及びＵＩ情報を記憶するように構成されている。
本願の請求項８に記載の技術によれば、請求項７に記載のコンテンツ受信装置の前記認証部は、記憶したＵＩ情報に対応する第１の識別情報を持つ前記コンテンツ送信装置に対して前記第２の認証を含む処理を実行するように構成されている。
本願の請求項９に記載の技術によれば、請求項７に記載のコンテンツ受信装置の前記認証部は、記憶したＵＲＬを、前記第２の認証で得た交換鍵のラベルを付けて前記コンテンツ送信装置に送信するように構成されている。
本願の請求項１０に記載の技術によれば、請求項９に記載のコンテンツ受信装置は、前記コンテンツ送信装置から所定時間以内に前記ＵＲＬの送信に対する応答を受信したことにより、前記コンテンツ記録部に記録した前記コンテンツの再生を開始するように構成されている。
本願の請求項１１に記載の技術によれば、請求項１に記載のコンテンツ受信装置の前記認証部は、前記コンテンツ記録部に記録したコンテンツの再生を終了したときに、前記コンテンツ送信装置と第３の認証を行なうように構成されている。
本願の請求項１２に記載の技術によれば、前記の再生処理に用いられる情報として、前記コンテンツ記録部に記録したコンテンツへのポインターを含んでいる。そして、請求項４に記載のコンテンツ受信装置は、前記第２の認証を含む処理を実行した後に、前記ポインターのコンテンツを再生するように構成されている。
本願の請求項１３に記載の技術によれば、請求項１に記載のコンテンツ受信装置は、前記第１の認証を行なった後に、コピー不可の前記コンテンツを移動プロトコルに従って前記コンテンツ送信装置から受信するように構成されている。
また、本願の請求項１４に記載の技術は、
コンテンツ送信装置と第１の認証を行なうステップと、
前記コンテンツ送信装置からコンテンツを受信するステップと、
受信したコンテンツを記録するステップと、
前記コンテンツ送信装置と第２の認証を含む処理を実行するステップと、
前記の記録したコンテンツを再生するステップと、
を有するコンテンツ受信方法である。
また、本願の請求項１５に記載の技術は、
コンテンツ受信装置と通信する通信部と、
前記コンテンツ受信装置と相互認証して交換鍵を共有する認証部と、
前記交換鍵を用いて暗号化したコンテンツを前記通信部から前記コンテンツ受信装置に送信するコンテンツ提供部と、
交換鍵及びそのラベルを前記コンテンツ受信装置の識別情報と対応付けて記録するとともに、この記録の破棄の有無を示すＬｏｃｋフラグを含むコネクション・レコードを記録する管理部と、
を具備するコンテンツ送信装置である。
本願の請求項１６に記載の技術によれば、請求項１５に記載のコンテンツ送信装置は、前記認証部が前記コンテンツ受信装置と第１の認証を行なった後に前記コンテンツ提供部が前記コンテンツ受信装置にコンテンツを送信し、前記認証部が前記コンテンツ受信装置と第２の認証を行なったときに共有した交換鍵のラベルを前記コンテンツのＵＲＬとともに受信したときに、該当するコネクション・レコードのＬｏｃｋフラグをセットするように構成されている。
本願の請求項１７に記載の技術によれば、請求項１６に記載のコンテンツ送信装置は、受信した前記ＵＲＬに対応するコンテンツのｄｕｒａｔｉｏｎを前記コネクション・レコード用のタイマーに設定してダウンカウントし、前記管理部が、前記タイマーの値がゼロになったコネクション・レコードのＬｏｃｋフラグをリセットするように構成されている。
本願の請求項１８に記載の技術によれば、請求項１６に記載のコンテンツ送信装置の前記管理部は、前記認証部が前記コンテンツ受信装置と第３の認証を行なったときに、該当するコネクション・レコードのＬｏｃｋフラグをリセットするように構成されている。
本願の請求項１９に記載の技術によれば、請求項１５に記載のコンテンツ送信装置の前記管理部は、前記認証部が前記コンテンツ受信装置と第２の認証を行なったときに共有した交換鍵のラベルを含むコンテンツの送信リクエストを受信したときに、該当するコネクション・レコードのＬｏｃｋフラグをリセットするように構成されている。
また、本願の請求項２０に記載の技術は、
コンテンツ受信装置と第１の認証を行なうステップと、
前記コンテンツ受信装置にコンテンツを送信し、
前記コンテンツ受信装置と第２の認証を行なうステップと、
前記コンテンツ受信装置から前記第２の認証で共有した交換鍵のラベルを受信したときに、該当するコネクション・レコードのＬｏｃｋフラグをセットするステップと、
を有するコンテンツ送信方法である。
本明細書で開示する技術によれば、受信したコンテンツを所定の制限下で好適に利用することができる、優れたコンテンツ受信装置及びコンテンツ受信方法を提供することができる。
本明細書で開示する技術を適用したコンテンツ受信装置は、あらかじめダウンロードしたコンテンツの再生を仮想的なストリーミングとして行なうことで、コンテンツの利用に所定の制限を課すことができる。コンテンツ受信装置は、例えばコンテンツ送信元とリモート認証に成功しなければダウンロードしたコンテンツを再生できないので、コンテンツの無制限に利用されないようにすることができる。
また、本明細書で開示する技術によれば、送信したコンテンツの利用に所定の制限を課すことができる、優れたコンテンツ送信装置及びコンテンツ送信方法を提供することができる。
本明細書で開示する技術を適用したコンテンツ送信装置は、コンテンツ送信先にダウンロードしたコンテンツを再生している間は同時複数ストリーミングを制限することができる。
なお、本明細書に記載された効果は、あくまでも例示であり、本発明の効果はこれに限定されるものではない。また、本発明が、上記の効果以外に、さらに付加的な効果を奏する場合もある。
本明細書で開示する技術のさらに他の目的、特徴や利点は、後述する実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
図１は、本明細書で開示する技術を適用したコンテンツ伝送システム１００の構成例を模式的に示した図である。 図２は、本明細書で開示する技術を適用したコンテンツ伝送システム２００の他の構成例を模式的に示した図である。 図３は、図１並びに図２において、サーバー１０１、２０１として動作するコンテンツ送信装置３００の機能的構成を模式的に示した図である。 図４は、図１並びに図２において、端末１０２、２０２として動作するコンテンツ受信装置４００の機能的構成を模式的に示した図である。 図５は、リモート・アクセスを行なうＳｉｎｋデバイスをＳｏｕｒｃｅデバイスに登録する手順を示した図である。 図６は、ＳｏｕｒｃｅデバイスとＳｉｎｋデバイス間でリモート・アクセスによるコンテンツ伝送を行なう手順を模式的に示した図である。 図７は、コンテンツ・リスト閲覧フェーズ（ＳＥＱ６０１）の中身を模式的に示した図である 図８は、ＲＡ−ＡＫＥ手続きフェーズ（ＳＥＱ６０２）の中身の詳細を示した図である。 図９は、Ｓｉｎｋデバイスに対して生成したリモート・アクセス用交換鍵ＫR及びその交換鍵ラベルＫR＿ｌａｂｅｌをＳｉｎｋ−ＩＤと対応付けてＲＡＣ ｒｅｃｏｒｄとして記憶する様子を示した図である。 図１０は、リモート・アクセス用交換鍵Ｋ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＿ｌａｂｅｌを含むＲＡＣ ｒｅｃｏｒｄを認証・鍵共有部３０６で管理しているかどうかをチェックする（ステップＳ１７０２）。
そして、指定されたラベルＫ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. コンテンツ受信装置と第１の認証を行なうステップと、
    前記コンテンツ受信装置にコンテンツを送信し、
    前記コンテンツ受信装置と第２の認証を行なうステップと、
    前記コンテンツ受信装置から前記第２の認証で共有した交換鍵のラベルを受信したときに、該当するコネクション・レコードのＬｏｃｋフラグをセットするステップと、
    を有するコンテンツ送信方法。
JP2013241552A 2013-11-22 2013-11-22 コンテンツ受信装置及びコンテンツ受信方法、並びにコンテンツ送信装置及びコンテンツ送信方法 Pending JP2015103890A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2013241552A JP2015103890A (ja) 2013-11-22 2013-11-22 コンテンツ受信装置及びコンテンツ受信方法、並びにコンテンツ送信装置及びコンテンツ送信方法
US14/538,442 US20150149778A1 (en) 2013-11-22 2014-11-11 Content reception apparatus and method, and content transmission apparatus and method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2013241552A JP2015103890A (ja) 2013-11-22 2013-11-22 コンテンツ受信装置及びコンテンツ受信方法、並びにコンテンツ送信装置及びコンテンツ送信方法

Publications (1)

Publication Number Publication Date
JP2015103890A true JP2015103890A (ja) 2015-06-04

Family

ID=53183713

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013241552A Pending JP2015103890A (ja) 2013-11-22 2013-11-22 コンテンツ受信装置及びコンテンツ受信方法、並びにコンテンツ送信装置及びコンテンツ送信方法

Country Status (2)

Country Link
US (1) US20150149778A1 (ja)
JP (1) JP2015103890A (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2553295B (en) * 2016-08-25 2020-12-16 Samsung Electronics Co Ltd Managing communications between a broadcast receiver and a security module
IL248306B (en) * 2016-10-10 2019-12-31 Verint Systems Ltd System and method for creating data sets for learning to recognize user actions
WO2019107314A1 (ja) * 2017-11-30 2019-06-06 株式会社アドテクニカ 情報処理装置、情報処理方法、情報処理システム及びプログラム
EP3942740A1 (en) 2019-03-20 2022-01-26 Verint Systems Ltd. System and method for de-anonymizing actions and messages on networks
US11658969B2 (en) * 2020-11-20 2023-05-23 At&T Intellectual Property I, L.P. Apparatuses and methods for facilitating port discernment driven mutual authentication and service access authorization
CN112787865B (zh) * 2021-01-21 2022-11-11 中科创达软件股份有限公司 Hdcp设备兼容方法、装置、电子设备和介质

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4011792B2 (ja) * 1999-06-16 2007-11-21 株式会社東芝 記録方法、再生方法、記録装置、再生装置及び記録媒体
JP2001175606A (ja) * 1999-12-20 2001-06-29 Sony Corp データ処理装置、データ処理機器およびその方法
EP1267515A3 (en) * 2000-01-21 2004-04-07 Sony Computer Entertainment Inc. Method and apparatus for symmetric encryption/decryption of recorded data
JP2001209583A (ja) * 2000-01-26 2001-08-03 Sony Corp データ記録再生器およびセーブデータ処理方法、並びにプログラム提供媒体
AU2003259563A1 (en) * 2002-08-28 2004-03-29 Matsushita Electric Industrial Co., Ltd. Content-duplication management system, apparatus and method, playback apparatus and method, and computer program
CN1774687A (zh) * 2003-04-14 2006-05-17 松下电器产业株式会社 使用挑战响应原理的客户端服务器鉴别
KR100985784B1 (ko) * 2003-05-02 2010-10-06 엘지전자 주식회사 대화형 광디스크의 인증 방법
JP2005191755A (ja) * 2003-12-25 2005-07-14 Toshiba Corp コンテンツ受信蓄積装置およびコンテンツ配信システム
US7418257B2 (en) * 2004-08-31 2008-08-26 Pantech & Curitel Communications, Inc. Mobile communication terminal, wireless data service authentication server, system for automatically blocking voice call connection, and method of processing various messages in mobile communication terminal
JP4581955B2 (ja) * 2005-10-04 2010-11-17 ソニー株式会社 コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラム
JP4518058B2 (ja) * 2006-01-11 2010-08-04 ソニー株式会社 コンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラム
WO2008050560A1 (fr) * 2006-10-25 2008-05-02 Sharp Kabushiki Kaisha Serveur de distribution de contenu, serveur de fourniture de contenu, système de distribution de contenu, procédé de distribution de contenu, procédé de fourniture de contenu, dispositif de terminal, programme de commande et support d'enregistrement lisible par ordinateur
EP2178019A4 (en) * 2007-08-07 2015-01-28 Panasonic Corp SYSTEM FOR REPRODUCING AUDIOVISUAL CONTENTS IN A NETWORK, SERVER, PROGRAM, AND RECORDING MEDIUM
JP4292222B2 (ja) * 2007-11-30 2009-07-08 株式会社東芝 著作権保護処理装置および著作権保護処理方法
JP6010023B2 (ja) * 2011-04-25 2016-10-19 パナソニック株式会社 記録媒体装置及びコントローラ
US20120290834A1 (en) * 2011-05-11 2012-11-15 Takahiro Yamaguchi Key distribution device, terminal device, and content distribution system
US20130018495A1 (en) * 2011-07-13 2013-01-17 Nokia Corporation Method and apparatus for providing content to an earpiece in accordance with a privacy filter and content selection rule
WO2013140774A1 (ja) * 2012-03-20 2013-09-26 パナソニック株式会社 サーバ装置、再生装置及びコンテンツ配信システム
KR20130140948A (ko) * 2012-05-17 2013-12-26 삼성전자주식회사 저장 장치의 식별자에 기반한 컨텐츠의 암복호화 장치 및 방법

Also Published As

Publication number Publication date
US20150149778A1 (en) 2015-05-28

Similar Documents

Publication Publication Date Title
JP6458974B2 (ja) コンテンツ配信方法、コンテンツ配信システム、及びソース機器
US10542307B2 (en) Content transmission device and content transmission method
US8984646B2 (en) Content transmission device and content reception device
JP6545835B2 (ja) コンテンツ送信装置、および、そのコンテンツ送信方法
US20130191626A1 (en) Recording device, terminal device, and content transmission system
JP2015103890A (ja) コンテンツ受信装置及びコンテンツ受信方法、並びにコンテンツ送信装置及びコンテンツ送信方法
US9165122B2 (en) Content reproducing device, content reproducing method, and content reproducing system
JP2009134617A (ja) 著作権保護処理装置および著作権保護処理方法
JP6390618B2 (ja) コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、コンピューター・プログラム、並びにコンテンツ伝送システム
JP6221428B2 (ja) コンテンツ受信装置及びコンテンツ受信方法、並びにコンピューター・プログラム
JP6332280B2 (ja) コンテンツ送信装置及びコンテンツ送信方法、並びにコンピューター・プログラム
JP7042373B2 (ja) コンテンツ送信装置
JP6187139B2 (ja) コンテンツ伝送システム
US20130347119A1 (en) Data processor, communication device, data transmission method
JP2015082681A (ja) コンテンツ受信装置及びコンテンツ受信方法、並びにコンピューター・プログラム
WO2015004978A1 (ja) コンテンツ送信装置及びコンテンツ送信方法、並びにコンピューター・プログラム
JP5168366B2 (ja) サーバ装置、クライアント装置、及び、サーバ装置とクライアント装置を含むコンテンツ伝送システム
JP2012080503A (ja) 移動体セットトップボックスを用いたコンテンツ閲覧システムおよび移動体セットトップボックス
JP2011087156A (ja) データ送信装置、データ受信装置及びデータ送受信システム