JP2007199890A - コンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラム - Google Patents

コンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラム Download PDF

Info

Publication number
JP2007199890A
JP2007199890A JP2006015886A JP2006015886A JP2007199890A JP 2007199890 A JP2007199890 A JP 2007199890A JP 2006015886 A JP2006015886 A JP 2006015886A JP 2006015886 A JP2006015886 A JP 2006015886A JP 2007199890 A JP2007199890 A JP 2007199890A
Authority
JP
Japan
Prior art keywords
data
content
sink
source
procedure
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
JP2006015886A
Other languages
English (en)
Inventor
Katsuhiko Nakano
雄彦 中野
Hisato Shima
久登 嶋
Kazuhiko Takabayashi
和彦 高林
Takuya Igarashi
卓也 五十嵐
Morihiko Hayashi
守彦 林
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 JP2006015886A priority Critical patent/JP2007199890A/ja
Priority to EP07000881A priority patent/EP1840781A1/en
Priority to US11/656,386 priority patent/US20070180224A1/en
Priority to KR1020070006838A priority patent/KR20070078065A/ko
Priority to CNA2007100027273A priority patent/CN101009808A/zh
Publication of JP2007199890A publication Critical patent/JP2007199890A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • 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/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution
    • 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/062—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying encryption of the keys

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Tourism & Hospitality (AREA)
  • Bioethics (AREA)
  • Strategic Management (AREA)
  • Primary Health Care (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Human Resources & Organizations (AREA)
  • Economics (AREA)
  • Storage Device Security (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Computer And Data Communications (AREA)
  • Television Signal Processing For Recording (AREA)

Abstract

【課題】障害によりＭＯＶＥ動作が途切れた場合であっても、既にＳｉｎｋ側で受け取ったデータに関する権利を公平となるように取り扱う。
【解決手段】Ｓｉｎｋはコンテンツを構成する各データを受信した時点で、コンテンツ全体の伝送処理の完了を待たずに、その受信データに関する権利がＳｏｕｒｃｅから委譲され、Ｓｉｎｋ側で受信データが逐次的に利用可能になるとともに、Ｓｏｕｒｃｅ側ではコンテンツの当該データ部分が無効化される。ＭＯＶＥしたデータをＳｉｎｋ側で受信した直後に利用可能にする。あるいは、受信データに関してＳｏｕｒｃｅとの間で確約を経た後にＳｉｎｋ側で利用可能にする。
【選択図】 図７

Description

本発明は、デジタル化されたＡＶデータなどのコンテンツを機器間で伝送するコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムに係り、特に、著作権保護やその他の目的でコピーが制限されたコンテンツを機器間で暗号化伝送するコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムに関する。
デジタル化されたコンテンツはコピーや改竄などの不正な操作が比較的容易であることから、個人的又は家庭的なコンテンツの使用を許容しながら不正使用に対する防御が必要である。とりわけ、国内では２０１１年の地上アナログ放送停波に向けてアナログ放送受信機からデジタル放送受信機への置き換えが急速に進んでおり、家庭内のＡＶコンテンツのデジタル化に対してコンテンツの保護を技術的に実現することが必須と考えられている。
日本国内では、ＡＲＩＢ（Ａｓｓｏｃｉａｔｉｏｎｏｆ Ｒａｄｉｏ Ｉｎｄｕｓｔｒｉｅｓ ａｎｄ Ｂｕｓｉｎｅｓｓｅｓ：電波産業会）が中心となってデジタル放送に関する標準化が進められ、デジタル衛星放送、デジタル地上波放送、並びにデジタルＣＡＴＶにおいてＭＰＥＧ２システム（例えば、非特許文献１を参照のこと）を採用するとともに、「１世代のみコピー可」（コピーワンス）といったコピー制御機能の導入を義務付け、厳しいコンテンツ保護規定を設けている（例えば、非特許文献２を参照のこと）。
また、デジタル伝送コンテンツの保護に関する業界標準的な技術として、ＤＴＬＡ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｌｉｃｅｎｓｉｎｇ Ａｄｍｉｎｉｓｔｒａｔｏｒ）が開発したＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）が挙げられ、コピー制御を始め著作権が保護された形でコンテンツを伝送させるための仕組みについて規定されている（例えば、非特許文献３を参照のこと）。
ＤＴＣＰでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決められている。その規定によれば、コンテンツ提供元であるＳｏｕｒｃｅとコンテンツ提供先であるＳｉｎｋは、ＡＫＥコマンドの送受信により、認証手続きを経て鍵を共有化し、その鍵を用いて伝送路を暗号化してコンテンツの伝送を行なう。不正なＳｉｎｋは、Ｓｏｕｒｃｅとの認証に成功しないと暗号鍵を取得できないから、コンテンツを取得することはできない。
ＤＴＣＰは、原初的には、ＩＥＥＥ１３９４を伝送路に用いたホーム・ネットワーク上におけるデジタル・コンテンツの伝送について規定している。最近では、ＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）に代表されるように、デジタル化されたＡＶコンテンツをＩＰネットワーク経由で流通させようという動きが本格的になっていることから、ＩＰネットワークに対応したＤＴＣＰ技術、すなわちＤＴＣＰ−ＩＰ（ＤＴＣＰ ｍａｐｐｉｎｇ ｔｏ ＩＰ）の開発が進められている。
ＤＴＣＰ−ＩＰによれば、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）といったコンテンツ伝送用プロトコルを使用することができる。例えば、ＨＴＴＰの手続きに従ってコンテンツを伝送する場合、ＳｏｕｒｃｅがＨＴＴＰサーバとなり、ＳｉｎｋがＨＴＴＰクライアントとなって、ＨＴＴＰのためのＴＣＰ／ＩＰコネクションが作成され、暗号化コンテンツの伝送が行なわれる。また、ホーム・ネットワークがルータ経由で外部のＩＰネットワークに接続されると、盗聴や改竄、コンテンツの不正コピーといった危惧があるため、ＤＴＣＰ−ＩＰでは、コンテンツを保護しながらネットワーク伝送するためのさらなる方法を規定している（例えば、非特許文献４を参照のこと）。
著作権保護に対応したコンテンツ伝送を行なう際、コピー制御や暗号化方式などコンテンツ保護に関するコンテンツ属性を指定する必要がある。ＤＴＣＰ−ＩＰでは、コンテンツ伝送用のパケット（ＰＣＰ）のヘッダ部に記述するＥ−ＥＭＩ（Ｅｘｔｅｎｄｅｄ − Ｅｎｃｒｙｐｔｉｏｎ Ｍｏｄｅ Ｉｎｄｉｃａｔｏｒ）と、Ｅｍｂｅｄｅｄ ＣＣＩ（Ｃｏｐｙ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）という２つのメカニズムにより、コンテンツに付随したコピー制御情報の伝送を実現している。
Ｅｍｂｅｄｄｅｄ ＣＣＩは、パケットのペイロード部に埋め込んで伝送される。コンテンツ・ストリームをタンパリングすると誤った暗号解読を行なうことになるので、Ｅｍｂｅｄｄｅｄ ＣＣＩの完全性を保証することができる。一方のＥ−ＥＭＩは、平文状態のヘッダ部に記載される、暗号モードを記述する４ビットのフィールドであり、その値はコピー制御情報の種類に対応する。ビット値定義を下表に示しておく。但し、同表で未使用となっている９つのＥ−ＥＭＩ値は将来の拡張用に予備となっている。
Figure 2007199890
Ｓｏｕｒｃｅ側では、コンテンツ・ストリームの特性に従って正しい暗号モードを選択し、これに基づいてＥ−ＥＭＩを設定する。また、Ｓｉｎｋは、コンテンツを伝送するパケットのヘッダ中のＥ−ＥＭＩで指定される正しい暗号解読モードを選択する。また、Ｓｉｎｋでは、Ｅ−ＥＭＩやＥｍｂｅｄｄｅｄ ＣＣＩで指定されている通りに、受信コンテンツを符号化して蓄積し、自らＳｏｕｒｃｅとなるときにはコピー制御情報に従って２次的なコンテンツ伝送動作を制御する。コピー制御の種類として、以下が挙げられる。
Ｃｏｐｙ Ｆｒｅｅ：著作権自体は留保するが、ＤＴＣＰを用いたコピー制御は行なわない。
Ｃｏｐｙ Ｎｅｖｅｒ：決してコンテンツを複製してはならない。
Ｃｏｐｙ Ｏｎｅ Ｇｅｎｅｒａｔｉｏｎ：１回だけ（Ｏｎｅ Ｇｅｎｅｒａｔｉｏｎ）だけコピーが許容される。
Ｎｏ Ｍｏｒｅ Ｃｏｐｉｅｓ：もはやコピーが許されない。
上記のうちＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓは、元はＣｏｐｙ Ｏｎｅ Ｇｅｎｅｒａｔｉｏｎに設定されたコンテンツを１回（ｆｉｒｓｔ ｇｅｎｅｒａｔｉｏｎ）だけコピーしたことによりコピーが許可されなくなった状態である。ＤＴＣＰ−ＩＰでは、Ｎｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして符号化されたコンテンツを伝送する手段として、Ｍｏｖｅ機能が用意されており、Ｓｉｎｋは受信したコンテンツをＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして符号化して扱うこと、及び、Ｓｏｕｒｃｅ側では伝送した後のコンテンツを消去又は利用不能にするという条件の下で、ＳｏｕｒｃｅからＳｉｎｋへコンテンツをＭＯＶＥすることが許容される（例えば、非特許文献４、非特許文献５を参照のこと）。具体的には、元はＣｏｐｙ Ｏｎｅ Ｇｅｎｅｒａｔｉｏｎであったコンテンツが個人のビデオ録画機器（ＰＶＲ）などのＳｏｕｒｃｅにＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして符号化・記録されている場合、上記の条件を満たすことで、Ｃｏｐｙ Ｏｎｅ Ｇｅｎｅｒａｔｉｏｎの状態で符号化し、単一のＳｉｎｋにのみＭＯＶＥすることが許容される。
現状の規定によれば、Ｅ−ＥＭＩでＣ０モード、又はＢ１モードのいずれかを使用してＭＯＶＥ動作を行なうことができる。Ｓｉｎｋ側では、これらのモードで受け取ったコンテンツを、ＡＫＥ手続きで取得した鍵を用いて復号し、記録することができる。また、Ｓｏｕｒｃｅ側では、送信した瞬間にデータを無効化する必要がある。
ＳｏｕｒｃｅからＳｉｎｋへのコンテンツのＭＯＶＥ処理が複数のデータ伝送シーケンスで構成される場合、上述したような、Ｓｏｕｒｃｅ側でコンテンツを消去又は利用不能にするという条件を一貫して遵守しなければならない。例えば、コンテンツを複数の領域に分割してそれぞれを別のタイトル鍵で暗号化し、コンテンツ復号化の際に使用される時変鍵を抽出し、タイトル鍵領域の元のタイトル鍵を、抽出した当該時変鍵で順次上書きして前のコンテンツの復号化を不可能にすることによって、Ｍｏｖｅ処理した元のコンテンツを安全且つ効率的に削除するコンテンツ管理装置について提案がなされている（例えば、特許文献１を参照のこと）。
ここで、ＳｏｕｒｃｅとＳｉｎｋ間で行なわれているＭＯＶＥシーケンスが障害などにより中断したときに、Ｓｏｕｒｃｅ及びＳｉｎｋのそれぞれにコンテンツが分断されるという問題がある。コンテンツ全体の伝送が成功裏に終わればＳｏｕｒｃｅとＳｉｎｋ間でコンテンツの権利を無事に委譲することができるが、伝送の途中で障害が発生すると、伝送後のデータ部分はＳｉｎｋ側に、伝送前のデータ部分はＳｏｕｒｃｅに残り、コンテンツが分断される。ＭＯＶＥ動作中に生じる障害として、コネクション・エラーが発生する、一方の機器の電源が遮断される、コンテンツ格納用のメディアが抜き取られる（あるいはストレージが故障する）、Ｓｉｎｋ側でコンテンツを格納するストレージが満杯になるといった原因が挙げられる。
例えば、汎用バス経由でコンテンツ伝送を行なうＳｏｕｒｃｅとＳｉｎｋの間にコンテンツ移動コントローラを設け、Ｍｏｖｅ動作に際してＳｏｕｒｃｅとＳｉｎｋの両方に重複して存在する再生可能なコンテンツの量が通常の再生時間にして１分を超えてはならないというＤＴＣＰ規格に基づいて、コンテンツ移動コントローラがＳｏｕｒｃｅ及びＳｉｎｋいずれかで不具合を検出すると１分以内にＭＯＶＥを中断し、Ｓｏｕｒｃｅに再生可能な状態で残っている部分で移動動作を再開することによってコンテンツの消失を避けるコンテンツ移動システムについて提案がなされている（例えば、特許文献を参照２のこと）。但し、この場合は、コンテンツ移動コントローラが介在しなければならないことから、装置コストが増大する。また、無線ＬＡＮ上で任意のＳｏｕｒｃｅとＳｉｎｋ間でＭＯＶＥ動作がアドホックに起動する場合には、コンテンツ移動コントローラの配置が困難となり、あるいはコンテンツ移動コントローラの介在が伝送シーケンスのボトルネックとなる。
また、コンテンツを受信完了したＳｉｎｋから返信されるコンテンツの記録状態情報を基にＳｏｕｒｃｅが送信済みのコンテンツを消去することで、Ｓｉｎｋがコンテンツを正常記録できない際のＳｏｕｒｃｅ側でのコンテンツの紛失を防ぐコンテンツ記録システムについて提案がなされている（例えば、特許文献３を参照のこと）。しかしながら、同システムでは、コンテンツ伝送が途切れたことによりコンテンツがＳｏｕｒｃｅとＳｉｎｋで分断してしまった事態の解消方法については何ら考慮されていない。
また、著作権保護されたデータを他の記録装置に移動する際に、独自の複写暗号鍵で複写データを暗号化して保持しておき、万一移動時の障害などにより移動後のデータが不良の場合は、移動後のデータを無効とし、複写データから元のデータを復元することにより、著作権保護を行ないながら元のデータの消失を防止する、コンテンツ・データを取り扱う装置について提案がなされている（例えば、特許文献４を参照のこと）。しかしながら、同装置では、移動先にデータが記録されてから元のデータを消去するか、又は移動先でのデータの記録と並行して元のデータを消去するので、コンテンツ伝送が途切れたことによりコンテンツがＳｏｕｒｃｅとＳｉｎｋで分断してしまった事態の解消方法について十分には考慮されていない。
コンテンツ伝送が途切れたことによりコンテンツがＳｏｕｒｃｅとＳｉｎｋで分断してしまった場合、まだコンテンツがＭＯＶＥしていないと扱うと、Ｓｉｎｋ側では一部でも使用が可能であるから、コンテンツの権利者は不利益を被る。また、コンテンツがＭＯＶＥされたと扱うと、Ｓｉｎｋ側ではコンテンツ全体を利用できる訳ではないから、ユーザにとって不利である。
ＭＯＶＥ動作が完全に終了しなかった場合、Ｕｎｄｏ（すなわちＭＯＶＥしなかった状態に戻す）や、Ｒｅｓｕｍｅ（すなわち残りのＭＯＶＥ動作を再開する）といった解決方法も考えられる。
しかしながら、Ｓｉｎｋが利用可能な状態でしかデータを受け取ることができない（すなわち、Ｕｎｕｓａｂｌｅという状態で記録することができない）機器である場合には、受け取ったデータをＵｎｕｓａｂｌｅな状態にできない限り、Ｕｎｄｏを行なうことができない。また、Ｓｉｎｋ側で受け取ったデータを１回限りの逐次書き込み専用のストレージに記録しているような場合には、ストレージにデータを書き込まなかった状態に戻すことはできない。また、ＭＯＶＥ動作か途切れた原因が機器の故障などの場合は、Ｒｅｓｕｍｅすることはできない。
特開２００３−１０１５２９号公報 特開２００５−１５８０５６号公報 特開２００５−２９３７３１号公報 特開２００５−２５０５６７号公報 ＩＳＯ／ＩＥＣ １３８１８−１ＧＥＮＥＲＩＣＣＯＤＩＮＧ ＯＦ ＭＯＶＩＮＧ ＰＩＣＴＵＲＥＳ ＡＮＤ ＡＳＳＯＣＩＡＴＥＤ ＡＵＤＩＯ：ＳＹＳＴＥＭＳ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｈ．２２２．０ ＡＲＩＢ ＴＲ−Ｂ１４ ＡＲＩＢ ＴＲ−Ｂ１５ ＤＴＣＰ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｏｌｕｍｅ １ Ｖｅｒｓｉｏｎ １．４ （Ｉｎｆｏｒｍａｔｉｏｎａｌ Ｖｅｒｓｉｏｎ）ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ ＤＴＣＰ Ｖｏｌｕｍｅ １ Ｓｕｐｐｌｅｍｅｎｔ Ｅ Ｍａｐｐｉｎｇ ＤＴＣＰ ｔｏ ＩＰ， Ｖｅｒｓｉｏｎ １．１ （Ｉｎｆｏｒｍａｔｉｏｎａｌ Ｖｅｒｓｉｏｎ）ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ ＤＩＧＩＴＡＬ ＴＲＡＮＳＭＩＳＳＩＯＮ ＰＲＯＴＥＣＴＩＯＮ ＬＩＣＥＮＳＥ ＡＧＲＥＥＭＥＮＴ， Ａｄｏｐｔｅｒ Ａｇｒｅｅｍｅｎｔ Ｍａｙ ２００５
本発明の目的は、ＤＴＣＰに準拠した情報機器同士で暗号化コンテンツの伝送手続きを好適に実行することができる、優れたコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することにある。
本発明のさらなる目的は、ＭＯＶＥ機能を用いてＳｏｕｒｃｅからＳｉｎｋへコンテンツを好適に移動することができる、優れたコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することにある。
本発明のさらなる目的は、何らかの障害によりＭＯＶＥ動作が途切れた場合であっても、既にＳｉｎｋ側で受け取ったデータに関してコンテンツ権利者及びユーザにとって公平となるように取り扱うことができる、優れたコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することにある。
本発明は、上記課題を参酌してなされたものであり、その第１の側面は、コンテンツを送信するＳｏｕｒｃｅとコンテンツを受信するＳｉｎｋ間でコンテンツを伝送するコンテンツ伝送システムであって、前記Ｓｉｎｋは、前記Ｓｏｕｒｃｅから受信した部分のデータを逐次有効化し、前記Ｓｏｕｒｃｅは、前記Ｓｉｎｋに送信した部分のデータを逐次無効化しながら、コンテンツの移動を行なうことを特徴とするコンテンツ伝送システムである。
但し、ここで言う「システム」とは、複数の装置（又は特定の機能を実現する機能モジュール）が論理的に集合した物のことを言い、各装置や機能モジュールが単一の筐体内にあるか否かは特に問わない（以下、同様）。
本発明は、著作権保護が必要となる情報コンテンツを例えばＩＰネットワーク上で伝送するコンテンツ伝送システムに関するものであり、特に、具体的には、ＤＴＣＰ−ＩＰに準拠した情報通信機器の間で、相互認証及び鍵交換を経て共有した鍵を用いて暗号化コンテンツ伝送を安全に行なうコンテンツ伝送システムに関する。ＤＴＣＰでは、コピー制御を始め著作権が保護された形でコンテンツを伝送する仕組みが規定されている。
コンテンツ伝送の形態は、Ｓｏｕｒｃｅ上のコンテンツをＳｉｎｋにコピーする方法と、ＳｏｕｒｃｅからＳｉｎｋへコンテンツを移動してＳｏｕｒｃｅにコンテンツを残さない方法がある。ＤＴＣＰにおいては、Ｓｉｎｋは受信したコンテンツをＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして符号化して扱うこと、及び、Ｓｏｕｒｃｅ側では伝送した後のコンテンツを消去又は利用不能にすることを条件にして、Ｎｏ Ｍｏｒｅ Ｃｏｐｙとして符号化されたコンテンツを伝送するＭＯＶＥ機能が用意されている。
しかしながら、ＳｏｕｒｃｅとＳｉｎｋ間でＭＯＶＥ機能によるコンテンツ伝送処理が障害などに起因して中断したときに、Ｓｏｕｒｃｅ及びＳｉｎｋのそれぞれにコンテンツが分断されるという問題がある。ＭＯＶＥ動作が完全に終了しなかった場合、Ｕｎｄｏ（すなわちＭＯＶＥしなかった状態に戻す）や、Ｒｅｓｕｍｅ（すなわち残りのＭＯＶＥ動作を再開する）といった解決方法も考えられるが、これらの処理を行なえないケースもある。
そこで、本発明に係るコンテンツ伝送システムでは、Ｓｉｎｋは、Ｓｏｕｒｃｅから受信した部分のデータを逐次有効化するとともに、Ｓｏｕｒｃｅは、Ｓｉｎｋに送信した部分のデータを逐次無効化することを可能にし、Ｓｉｎｋ側ではコンテンツを構成する各データを受信する度にそのデータに関する権利をＳｉｎｋに委譲するという仕組みを導入した。
このようにコンテンツを構成するデータを部分的若しくは段階的に移動するという仕組みを導入することによって、何らかの障害によりコンテンツのＭＯＶＥ動作が途切れた場合であっても、既にＳｉｎｋ側で受け取ったデータに関してコンテンツ権利者及びユーザにとって公平となるように取り扱うことができる。
ここで、Ｓｉｎｋは、Ｓｏｕｒｃｅから受信して有効化したコンテンツ・データの少なくとも一部を無効化することができる場合には、受信データを無効化してから移動の取り消しをＳｏｕｒｃｅに要求することができる。Ｓｏｕｒｃｅは、該取り消し要求に応じて、一旦無効化した当該送信データを有効化することで、コンテンツ移動前の状態を復元することができる。
また、Ｓｏｕｒｃｅは、データをＳｉｎｋ宛てに送信した直後に無効化すると、データ伝送トランザクション中のコネクション・エラーや電源遮断に起因して、Ｓｉｎｋ側ではデータの欠落が生じる可能性がある。そこで、Ｓｏｕｒｃｅは、Ｓｉｎｋからデータを受信したことの確約手続きに応じて送信データの無効化処理を行なうようにしてもよい。
具体的には、ＳｉｎｋはＳｏｕｒｃｅから受信して有効化したデータの範囲を指定した受領確認コマンドを送信し、これに対し、Ｓｏｕｒｃｅは、該受領確認コマンドを受信したことに応じて、指定された範囲のデータを無効化するようにする。
このように、段階的なコンテンツの移動を確約手続き付きで行なうことにより、確約を経てからでないとＳｏｕｒｃｅはデータの無効化を行なわないから、コネクション・エラーのためにデータの欠落が生じることはない。また、伝送トランザクション中に機器の電源がオフされた場合であっても、確約前のデータを不揮発記憶領域に格納しておくことで、データの欠落を回避することができる。
また、本発明の第２の側面は、ＤＴＣＰ Ｓｏｕｒｃｅとしてコンテンツを送信するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
ＡＫＥ手続きによりＳｉｎｋとの間で相互認証及び鍵交換を行なう認証手順と、
送信対象となるコンテンツのデータを、前記認証手順において交換した鍵を用いて前記Ｓｉｎｋへ暗号化伝送するデータ伝送手順と、
前記データ伝送手順において送信された部分のデータを順次無効化するデータ無効化手順を実行させ、
Ｓｉｎｋへコンテンツを移動することを特徴とするコンピュータ・プログラムである。
また、本発明の第３の側面は、ＤＴＣＰ Ｓｉｎｋとしてコンテンツを受信するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
ＡＫＥ手続きによりＳｏｕｒｃｅとの間で相互認証及び鍵交換を行なう認証手順と、
前記Ｓｏｕｒｃｅから送信されるコンテンツ・データを、前記認証手順において交換した鍵を用いて受信処理するデータ受信手順と、
前記データ受信手順において受信された部分のデータを順次有効化するデータ有効化手順を実行させ、
Ｓｏｕｒｃｅからコンテンツを移動することを特徴とするコンピュータ・プログラムである。
本発明の第２乃至第３の各側面に係るコンピュータ・プログラムは、コンピュータ・システム上で所定の処理を実現するようにコンピュータ可読形式で記述されたコンピュータ・プログラムを定義したものである。換言すれば、本発明の第２乃至第３の各側面に係るコンピュータ・プログラムをコンピュータ・システムにインストールすることによってコンピュータ・システム上では協働的作用が発揮され、本発明の第１の側面に係るシステムにおいてＳｏｕｒｃｅ並びにＳｉｎｋとしてそれぞれ動作し、本発明の第１の側面に係るコンテンツ伝送システムと同様の作用効果を得ることができる。
本発明によれば、ＤＴＣＰに準拠した情報機器同士で暗号化コンテンツの伝送手続きを好適に実行することができる、優れたコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することができる。
また、本発明によれば、Ｍｏｖｅ機能を用いてＳｏｕｒｃｅからＳｉｎｋへコンテンツを好適に移動することができる、優れたコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することができる。
本発明に係るコンテンツ伝送システムによれば、コンテンツのＭＯＶＥを行なう際に、Ｓｉｎｋ側では受信したデータを逐次的に利用可能にする（すなわち、コンテンツを構成する各データを受信する度にそのデータに関する権利をＳｉｎｋに委譲する）という仕組みを導入することにより、何らかの障害によりＭＯＶＥ動作が途切れた場合であっても、既にＳｉｎｋ側で受け取ったデータに関してコンテンツ権利者及びユーザにとって公平となるように取り扱うことができる。
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
本発明は、著作権やその他の目的で保護が必要となる情報コンテンツを所定のコピー制御情報に従って暗号化伝送するコンテンツ伝送システムに関するものである。かかるシステムの具体例は、ＤＴＣＰ機器の間で行なわれるコンテンツ伝送である。以下、図面を参照しながら本発明の実施形態について詳解する。
Ａ．システム構成
ＤＴＣＰ−ＩＰに従ったコンテンツ伝送は、コンテンツの要求を受理してコンテンツを送信するサーバとしてのＳｏｕｒｃｅと、コンテンツを要求し、コンテンツを受信し、再生若しくは記録するクライアントとしてのＳｉｎｋで構成される。図１には、本発明の一実施形態に係る情報通信システムの構成例を模式的に示している。
図示の例では、ＤＴＣＰ−ＩＰ に準拠した認証サーバであるＳｏｕｒｃｅとＤＴＣＰ−ＩＰに準拠した認証クライアントであるＳｉｎｋはネットワークを経由して接続されて、ＡＫＥシステムが構築されている。ここで言うネットワークには、Ｅｔｈｅｒｎｅｔ（登録商標）や、インターネット、その他のＩＰネットワークが含まれる。ＳｉｎｋとＳｏｕｒｃｅは、ＴＣＰ／ＩＰネットワーク上でコネクションを確立することができ、このコネクションを利用して、認証手続きやコンテンツ伝送手続きを実行することができる。
図２及び図３には、図１に示したコンテンツ伝送システムにおいて、Ｓｉｎｋ及びＳｏｕｒｃｅとして動作するコンテンツ伝送装置の、特に認証及びコンテンツ伝送に着目した機能構成をそれぞれ模式的に示している。
図２に示すＳｉｎｋは、ＤＴＣＰ−ＩＰ認証ブロックと、ＤＴＣＰ−ＩＰコンテンツ受信ブロックと、コンテンツ再生／記録ブロックを備えている。
ＤＴＣＰ−ＩＰ認証ブロックは、ＡＫＥブロックと、メッセージ・ダイジェスト生成ブロックと、コンテンツ復号ブロックで構成される。ＤＴＣＰ−ＩＰ認証ブロックは、より好ましくは耐タンパ性を備えている。
ＡＫＥブロックは、ＤＴＣＰ−ＩＰにおけるＡＫＥ機構（Ｓｉｎｋ側）を実現するブロックでる。このＡＫＥブロックは後述のメッセージ・ダイジェスト生成ブロックから要求されたパラメータを渡す機能も備えている。
メッセージ・ダイジェスト生成ブロックは、例えばＭＤ５やＳＨＡ−１といった指定されたアルゴリズムに従い、パラメータのメッセージ・ダイジェストを生成するブロックであり、ＤＴＣＰ−ＩＰ認証ブロックの外に公開してはならないＡＫＥブロックが保持するパラメータのメッセージ・ダイジェストを生成できるようにＡＫＥブロックと密に配置される。
コンテンツ復号ブロックは、ＡＫＥで交換した鍵Ｋxを用いてコンテンツの復号鍵Ｋcを算出し、ＤＴＣＰ−ＩＰコンテンツ受信ブロックがＳｏｕｒｃｅから受信した暗号化コンテンツをこの復号鍵Ｋcで復号する。ここで復号されたコンテンツは、コンテンツ再生／記録ブロックへ渡される。
コンテンツ再生／記録ブロックは、コンテンツ復号ブロックから渡されたコンテンツを、再生モードの場合は再生を行ない、記録モードの場合はハード・ディスク又はその他の記録媒体（図示しない）に保存する。但し、コンテンツの記録動作は、コンテンツ伝送用のパケットＰＣＰ内に挿入されているコピー制御情報の規定に従う。
ＤＴＣＰ−ＩＰコンテンツ受信ブロックは、ＡＫＥを実施した後にＳｏｕｒｃｅとのコンテンツ伝送手続きを実行する処理モジュールである。図示の例では、ＤＴＣＰ−ＩＰコンテンツ受信ブロックはＨＴＴＰクライアント・ブロックを持ち、ＨＴＴＰサーバ（すなわちＳｏｕｒｃｅ）へコンテンツを要求し、応答されたコンテンツをＨＴＴＰサーバから受信する。ＨＴＴＰクライアント・ブロックは、ＨＴＴＰリクエスト管理ブロックとＨＴＴＰレスポンス管理ブロックに分かれる。
ＨＴＴＰリクエスト管理ブロックは、ＨＴＴＰリクエスト送信ブロックとＨＴＴＰリクエスト生成ブロックに分かれる。ＨＴＴＰリクエスト生成ブロックは、送信するコンテンツ伝送要求（ＨＴＴＰリクエスト）を生成する。ここで生成されたＨＴＴＰリクエストは、ＨＴＴＰリクエスト送信ブロックによりＨＴＴＰサーバとしてのＳｏｕｒｃｅへ送信される。
ＨＴＴＰレスポンス管理ブロックは、ＨＴＴＰレスポンス受信ブロックとＨＴＴＰレスポンス解釈ブロックに分かれる。サーバから返信されるＨＴＴＰレスポンスと暗号化されたコンテンツは、ＨＴＴＰ受信ブロックで受信される。ここで受信したＨＴＴＰレスポンスは、ＨＴＴＰレスポンス解釈ブロックでチェックされる。ここでのチェック結果が肯定的であれば受信した暗号化コンテンツをＤＴＣＰ認証ブロック内のコンテンツ復号ブロックへ送る。また、このチェック結果が否定的となる場合は、エラー・レスポンスとしての処理を行なう。ＳｏｕｒｃｅからのＨＴＴＰレスポンスは１つ以上のＰＣＰからなる。
ＤＴＣＰ−ＩＰ認証ブロックとＤＴＣＰ−ＩＰコンテンツ受信ブロックは、サーバ機器との間で個別のＴＣＰ／ＩＰコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。
また、図３に示すＳｏｕｒｃｅは、ＤＴＣＰ−ＩＰ認証ブロックと、ＤＴＣＰ−ＩＰコンテンツ送信ブロックと、コンテンツ管理ブロックを備えている。
ＤＴＣＰ−ＩＰ認証ブロックは、ＡＫＥブロックと、メッセージ・ダイジェスト生成ブロックと、コンテンツ暗号化ブロックで構成される。ＤＴＣＰ−ＩＰ認証ブロックは、より好ましくは耐タンパ性を備えている。
ＡＫＥブロックは、ＤＴＣＰ−ＩＰにおけるＡＫＥ機構（Ｓｏｕｒｃｅ側）を実現するブロックである。このブロックは、後述のメッセージ・ダイジェスト生成ブロックから要求されたパラメータを渡す機能も備えている。ＡＫＥブロックは認証したＳｉｎｋに関する情報を認証した機器の数だけ保持し、それをＳｉｎｋからコンテンツが要求された際に認証済みのＳｉｎｋかどうかを判別するのに使用する。
メッセージ・ダイジェスト生成ブロックは、ＭＤ５やＳＨＡ−１といった指定されたアルゴリズムに従い、パラメータのメッセージ・ダイジェストを生成するブロックであり、ＤＴＣＰ−ＩＰ認証ブロックの外に公開してはならないＡＫＥブロックが保持するパラメータのメッセージ・ダイジェストを生成できるようにＡＫＥブロックと密に配置される。
コンテンツ暗号化ブロックは、ＤＴＣＰ−ＩＰコンテンツ送信ブロックの要求に応じてコンテンツ管理ブロックより読み出したコンテンツ・データを、ＡＫＥで交換した鍵Ｋxから生成したコンテンツ鍵Ｋcを用いて暗号化する。ここで暗号化されたコンテンツは、Ｓｉｎｋへ送信するために、ＤＴＣＰ−ＩＰコンテンツ送信ブロックへ渡される。
コンテンツ管理ブロックは、ＤＴＣＰ−ＩＰの機構を用いて保護されるべきコンテンツを管理するブロックである。コンテンツ暗号化ブロックの読み出しに応じて、コンテンツのデータを渡す。
ＤＴＣＰ−ＩＰコンテンツ送信ブロックは、ＨＴＴＰサーバ・ブロックを持ち、Ｓｉｎｋからのリクエストに応じた処理を実行する。ＨＴＴＰサーバ・ブロックは、ＨＴＴＰリクエスト管理ブロックとＨＴＴＰレスポンス管理ブロックに分かれる。
ＨＴＴＰリクエスト管理ブロックは、ＨＴＴＰリクエスト受信ブロックと、ＨＴＴＰリクエスト解釈ブロックに分かれる。ＨＴＴＰリクエスト受信ブロックは、クライアントとしてのＳｉｎｋからのＨＴＴＰリクエストを受信する。受信したＨＴＴＰリクエストはＨＴＴＰリクエスト解釈ブロックに送られ、チェックされる。ＨＴＴＰリクエスト解釈ブロックにおけるチェック結果が肯定的であれば、ＨＴＴＰリクエストの情報をＤＴＣＰ−ＩＰ認証ブロックへ通知する。
ＨＴＴＰレスポンス管理ブロックは、ＨＴＴＰレスポンス生成ブロックとＨＴＴＰレスポンス送信ブロックに分かれる。ＨＴＴＰレスポンス生成ブロックは、ＨＴＴＰリクエスト解釈ブロックでのチェック結果が肯定的であれば、暗号化されたコンテンツを返すためのＨＴＴＰレスポンスを作成する。ＨＴＴＰレスポンスは１つ以上のＰＣＰからなる。一方、ＨＴＴＰリクエスト解釈ブロックでのチェック結果が否定的となる場合、エラーを返すためのＨＴＴＰレスポンスを作成する。ＨＴＴＰレスポンス送信ブロックは、作成されたＨＴＴＰレスポンスを、要求元のクライアントへ送信する。また、ＨＴＴＰリクエスト解釈ブロックでのチェック結果が肯定的となる場合には、ＨＴＴＰレスポンス・ヘッダに続けて、ＤＴＣＰ−ＩＰ認証ブロック内のコンテンツ暗号化ブロックで暗号化したコンテンツを送信する。
ＤＴＣＰ−ＩＰ認証ブロックとＤＴＣＰ−ＩＰコンテンツ送信ブロックは、ＨＴＴＰクライアントとしてのＳｉｎｋとの間で個別のＴＣＰ／ＩＰコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。
なお、Ｓｉｎｋ及びＳｏｕｒｃｅのいずれもがＤＴＣＰ−ＩＰ認証ブロック内に持つメッセージ・ダイジェスト生成ブロックは、ＤＴＣＰ−ＩＰ自体で規定される機能モジュールではなく、また本発明の要旨には直接関連しない。
Ｂ．ＨＴＴＰを利用したコンテンツ伝送
続いて、ＤＴＣＰ−ＩＰに従ったコンテンツの伝送手順について説明する。図４には、ＳｏｕｒｃｅとＳｉｎｋの間でＡＫＥに基づく鍵交換手続き、及び鍵交換により共有した鍵を利用した暗号化コンテンツ伝送を行なう仕組みを図解している。ＤＴＣＰ−ＩＰではＨＴＴＰやＲＴＰなどのコンテンツ伝送用プロトコルを利用することができるが、図示の例ではＨＴＴＰの手続きに従うものとする。また、コンテンツ伝送の形態は、コンテンツの複製とコンテンツの移動があるが、ここでは前者を前提にして説明する。後者のコンテンツ伝送方法は、ＤＴＣＰで規定されるＭＯＶＥ機能によって実現されるが、その詳細については後述に譲る。
ＳｏｕｒｃｅとＳｉｎｋは、まず１つのＴＣＰ／ＩＰコネクションを確立し、機器同士の認証及び鍵交換のためのＡＫＥ手続きを行なう。ＤＴＣＰ準拠機器には、ＤＴＬＡ（前述）により発行された機器証明書が埋め込まれている。ＤＴＣＰ認証手続きでは、互いが正規のＤＴＣＰ準拠機器であることを確かめた後、認証鍵ＫauthをＳｏｕｒｃｅとＳｉｎｋで共有する。ＡＫＥ手続きが成功すると、Ｓｏｕｒｃｅはコンテンツ暗号鍵Ｋcの種となる種鍵Ｋxを生成し、認証鍵Ｋauthで暗号化してＳｉｎｋに送る。
そして、ＡＫＥによる認証及び鍵交換手続きが済んだ後、ＳｉｎｋはＳｏｕｒｃｅ上のコンテンツを要求することができる。また、Ｓｏｕｒｃｅは、ＵＰｎＰで規定されているＣＤＳ（ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ）などを通じてＳｉｎｋにＳｏｕｒｃｅ上のコンテンツへのアクセス先を示すコンテンツ場所をあらかじめ伝えることができる。
図２及び図３に示した構成例では、ＳｏｕｒｃｅがＨＴＴＰサーバとなり、ＳｉｎｋがＨＴＴＰクライアントとなって、コンテンツの伝送を開始する（ＲＴＰを使用するときは、ＳｏｕｒｃｅがＲＴＰＳｅｎｄｅｒとなり、ＳｉｎｋがＲＴＰ Ｒｅｃｅｉｖｅｒとなる）。ＨＴＴＰのためのＴＣＰ／ＩＰコネクションが、ＡＫＥのためのＴＣＰ／ＩＰコネクションとは別に、ＨＴＴＰクライアントより作成される（すなわち、ＡＫＥ手続き用とコンテンツ伝送用に個別のソケット情報（ＩＰアドレスとポート番号の組み合わせ）を持つ）。そして、ＨＴＴＰクライアントとして動作するＳｉｎｋは、通常のＨＴＴＰと全く同様の動作手順によりＨＴＴＰサーバとして動作するＳｏｕｒｃｅ上のコンテンツを要求する。これに対し、ＨＴＴＰサーバは、要求通りのコンテンツをＨＴＴＰレスポンスとして返す。
Ｓｏｕｒｃｅは、乱数を用いてノンスＮcを生成して、種鍵ＫxとノンスＮcと暗号モードを表すＥ−ＥＭＩを基にコンテンツ鍵Ｋcを生成する。そして、Ｓｉｎｋから要求されているコンテンツを、コンテンツ鍵Ｋcを用いて暗号化し、暗号化コンテンツからなるペイロードとノンスＮcとＥ−ＥＭＩを含んだヘッダからなるパケットであるＰＣＰ（Ｐｒｏｔｅｃｔｅｄ Ｃｏｎｔｅｎｔ Ｐａｃｋｅｔ）をＴＣＰストリーム上に乗せて送信する。そして、ＩＰプロトコルは、ＴＣＰストリームを所定の単位となるパケットの大きさに分割し、さらにヘッダ部を付加したＩＰパケットにし、指定されたＩＰアドレス宛てに届ける。
Ｓｉｎｋ側では、Ｓｏｕｒｃｅからの各ＩＰパケットを受信すると、これをＴＣＰストリームに組み立てて、送信されたＰＣＰを取り出す。そして、ストリームからノンスＮcとＥ−ＥＭＩを取り出すと、これらと種鍵Ｋxを用いて同様にコンテンツ鍵Ｋcを算出し、暗号化コンテンツを復号して、再生若しくは記録などの処理を実施する。ＨＴＴＰプロトコルを利用したコンテンツ伝送が終了すると、例えばＳｉｎｋ側から、使用したＴＣＰコネクションを適宜切断する。
また、長大なＴＣＰストリーム全体に渡り同じ暗号鍵を使用し続けると、鍵が解読される危険は高くなる。このため、ＤＴＣＰ−ＩＰでは、Ｓｏｕｒｃｅは１２８ＭＢ毎にノンスＮcすなわちコンテンツ鍵Ｋcを更新する（１ずつインクリメントする）よう取り決められている。Ｓｉｎｋは、コンテンツ鍵の確認が必要になると、コンテンツ伝送用のＴＣＰコネクションとは別に、コンテンツ鍵の確認用のＴＣＰコネクションをさらに確立し、Ｓｏｕｒｃｅに対しコンテンツ鍵確認のための手続きを行なう。例えば、ＤＴＣＰ−ＩＰ Ｖｏｌｕｍｅ １ Ｓｕｐｐｌｅｍｅｎｔ Ｅ．８．６には、コンテンツ鍵の確認手続きとして“Ｃｏｎｔｅｎｔ Ｋｅｙ Ｃｏｎｆｉｒｍａｔｉｏｎ”を規定している。
ＤＴＣＰ−ＩＰでは、ノンスＮcを含んだヘッダと、暗号化コンテンツからなるペイロードで構成される、ＰＣＰというパケット形式でコンテンツ伝送が行なわれる。図５には、ＰＣＰのデータ構造を模式的に示している。ＰＣＰヘッダは平文であり、ノンスＮcが含まれている。また、ＰＣＰペイロードはノンスＮcで決まるコンテンツ鍵Ｋcで暗号化されたコンテンツ（但し、コピー制御情報として“ｃｏｐｙ−ｆｒｅｅ”が指定されているコンテンツは暗号化不要）で構成される。ＰＣＰペイロードは、常に１６バイトの倍数になるように、必要に応じて暗号化前にｐａｄｄｉｎｇが行なわれる。また、コンテンツの安全のために定期的にノンスＮcすなわちコンテンツ鍵Ｋcを更新するが（前述）、その時点でもＰＣＰはｐａｄｄｉｎｇされる（コンテンツ鍵Ｋcを更新しなくても複数のＰＣＰにｐａｄｄｉｎｇすることは可能）。また、ｐｒｏｔｅｃｔｅｄ＿ｃｏｎｔｅｎｔ＿ｌｅｎｇｔｈの値が１６の整数倍でないときは、コンテンツに１〜１５バイトのｐａｄｄｉｎｇが付く。ノンスＮcの更新に伴い、コンテンツ鍵確認手続を起動するのは上述した通りである。ちなみに、ＨＴＴＰレスポンスは１つ以上のＰＣＰからなり、ＲＴＰペイロードは１つのＰＣＰからなる。図６には、ＰＣＰをｐａｄｄｉｎｇする様子を示している。
Ｃ．コンテンツのＭＯＶＥ動作
ＤＴＣＰ−ＩＰでは、Ｓｏｕｒｃｅ側でＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして符号化されているコンテンツをＳｉｎｋで利用できるようにする手段として、ＭＯＶＥ機能が用意されている。すなわち、Ｓｉｎｋは受信したコンテンツをＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして符号化して扱うこと、及び、Ｓｏｕｒｃｅ側では伝送した後のコンテンツを消去又は利用不能にするという条件の下で、ＳｏｕｒｃｅからＳｉｎｋへコンテンツをＭＯＶＥすることが許容される。ＭＯＶＥ機能によれば、ＳｏｕｒｃｅとＳｉｎｋ間で伝送したコンテンツのエンティティ数が増えることはないので、コンテンツ保護上の問題はない。
しかしながら、ＳｏｕｒｃｅとＳｉｎｋ間でＭＯＶＥ機能によるコンテンツ伝送処理が障害などに起因して中断したときに、Ｓｏｕｒｃｅ及びＳｉｎｋのそれぞれにコンテンツが分断されるという問題がある。ＭＯＶＥ動作が完全に終了しなかった場合、Ｕｎｄｏ（すなわちＭＯＶＥしなかった状態に戻す）や、Ｒｅｓｕｍｅ（すなわち残りのＭＯＶＥ動作を再開する）といった解決方法も考えられるが、これらの処理を行なえないケースもある。
そこで、本実施形態では、ＳｏｕｒｃｅからＳｉｎｋへコンテンツのＭＯＶＥを行なう際に、Ｓｉｎｋ側では受信したデータを逐次的に利用可能にするという仕組みを導入することにした。この場合、Ｓｉｎｋはコンテンツを構成する各データを受信した時点で、コンテンツ全体の伝送処理の完了を待たずに、その受信データに関する権利がＳｏｕｒｃｅから委譲され、Ｓｉｎｋ側で受信データが利用可能になるとともに、Ｓｏｕｒｃｅ側ではコンテンツの当該データ部分が無効化される。すなわち、データ伝送する度にＭＯＶＥしたコンテンツが増分すると言う、段階的なコンテンツの移動が行なわれる。
コンテンツをＭＯＶＥする際に、Ｓｉｎｋ側で受信データを逐次的に利用可能にしていくというこのような仕組みを、本明細書では“ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ”と呼ぶことにする。ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥによれば、何らかの障害によりＭＯＶＥ動作が途切れた場合であっても、既にＳｉｎｋ側で受け取られたデータの増分に関してコンテンツ権利者及びユーザにとって公平となるように取り扱うことができる、と本発明者らは思料する。
ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥでは、ＭＯＶＥしたデータをＳｉｎｋ側で受信した直後に利用可能にするようにしてもよい。Ｓｏｕｒｃｅ側では、データが受信されるのと引き換えに、当該データ部分を利用不能（すなわち無効化）にする。但し、データ受信直後に権利を委譲すると、Ｓｏｕｒｃｅ側では、自分から伝送したデータがＳｉｎｋで正しく受信及び格納されたかどうかを知ることはできない。そこで、受信データに関してＳｏｕｒｃｅとの間で確約（ｃｏｍｍｉｔｍｅｎｔ）を経た後に、Ｓｉｎｋ側で利用可能（すなわち有効化）にするようにしてもよい。この場合、Ｓｏｕｒｃｅは、確約手続きの一環としてＳｉｎｋ側から受信を通知されたデータ部分を利用不能にする。以下では、それぞれの方法に分けて、ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥの実施形態について説明する。
Ｃ−１．即時的なＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ
図７〜図１０には、ＭＯＶＥしたデータをＳｉｎｋ側で受信した直後に利用可能にする場合のコンテンツ伝送シーケンスを模式的に示している。
図７に示すように、コンテンツ全体の伝送が成功裏に終われば、ＳｏｕｒｃｅとＳｉｎｋ間でコンテンツの権利を無事に委譲することができる。これに対し、図８に示すように伝送の途中で障害が発生すると、伝送後のデータ部分はＳｉｎｋ側に、伝送前のデータ部分はＳｏｕｒｃｅに残り、コンテンツが分断される。ＭＯＶＥが中断し、且つ、以降でＭＯＶＥ処理を再開（Ｒｅｓｕｍｅ）することができないときに、このような状態に陥る。Ｓｉｎｋは、無事に受信したデータ増分に関しては権利が委譲され、その利用可能になる。また、Ｓｏｕｒｃｅは、既に送信したデータの部分を無効化するが、未送信となった残りのデータに関しては権利を留保し、その利用が可能である。
また、Ｓｉｎｋが既に受信したデータのうち任意の時点から利用不能にすることができる場合には、その時点以降のＭＯＶＥを取り消すことができる。データのＭＯＶＥを取り消すために、本実施形態では“ＣＡＮＣＥＬ”というコマンドを定義している。
図９には、受信データのある時点ｘ以降のＭＯＶＥを取り消すためのコンテンツ伝送シーケンスを模式的に示している。ｘ以前の受信データは、例えば、Ｓｉｎｋ側で既に利用可能な状態でデータを記録してしまい、なお且つ無効化できない（すなわちＵｎｄｏすることができない）データ部分、あるいはＳｉｎｋ側で利用するのに都合のよいデータ単位（例えば、受信バッファのサイズ）などである。Ｓｉｎｋは、Ｓｏｕｒｃｅに対し、ＭＯＶＥを取り消したい時点ｘを引数に含んだＣＡＮＣＥＬコマンドを送信する。
また、Ｓｉｎｋが受信データをすべて利用不可能な状態にすることが可能で、且つＳｉｎｋがＭＯＶＥ自体を取り消したい場合には、図１０に示すように、取り消したい時点を初期値０に設定したＣＡＮＣＥＬコマンドをＳｏｕｒｃｅに送信することで、今回のＭＯＶＥ動作全体をＵｎｄｏすることができる。
ＣＡＮＣＥＬコマンドの伝送は、安全なトランザクションで行なう必要がある。例えば、コマンド伝送用あるいはＡＫＥ用のＴＣＰコネクションを利用して、ＣＡＮＣＥＬコマンド並びにそれに関連するトランザクションを行なうことができる。ＣＡＮＣＥＬコマンドのフレーム・フォーマットについては後に説明する。
ＳｏｕｒｃｅからＳｉｎｋへコンテンツをＭＯＶＥするのは、クライアントとして動作するＳｉｎｋがコンテンツ・サーバとして動作するＳｏｕｒｃｅからコンテンツをダウンロードするケースと、クライアントとして動作するＳｕｒｃｅがコンテンツ・サーバとして動作するＳｉｎｋへコンテンツをアップロードするケースが想定される。以下では、それぞれのケースについて、Ｓｏｕｒｃｅ並びにＳｉｎｋが即時的なＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥを行なうための動作手順について説明する。
図１１には、即時的なＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ動作によりＳｉｎｋがＳｏｕｒｃｅからコンテンツをＭＯＶＥによりダウンロードする場合に、Ｓｏｕｒｃｅが実行する動作手順をフローチャートの形式で示している。
まず、コンテンツ送信先機器となるＳｉｎｋとの間で認証及び鍵交換（ＡＫＥ）手続き用のＴＣＰコネクションを確立して、ＡＫＥ処理を行なう（ステップＳ１）。Ｓｏｕｒｃｅが最初に鍵を渡す相手は１台のＳｉｎｋに限定する。
ＡＫＥに成功すると、Ｓｉｎｋとの間でコンテンツ伝送用のＴＣＰコネクションを確立する。そして、Ｓｉｎｋからコンテンツの送信要求を受信すると（ステップＳ２のＹｅｓ）、指定された部分のデータを送信する（ステップＳ３）。そして、送信した部分のデータを無効済みでなければ（ステップＳ４のＮｏ）、当該部分のコンテンツを無効化する（ステップＳ５）。
ここで言う「無効化」とは、実際にデータを消したり変えたりすることではなく、再送以外の目的での利用を抑制する処理である。ＳｉｎｋによりＭＯＶＥがＣＡＮＣＥＬされたときには無効化したデータを利用可能な状態に戻す。ＣＡＮＣＥＬコマンドは、例えば、無効化すべきコンテンツの範囲を指定するポインタ情報を持ち、Ｓｏｕｒｃｅ側では、ポインタの位置以前の範囲のデータの利用を制限するなどの管理を行なう。
Ｓｏｕｒｃｅは、ＳｉｎｋからＣＡＮＣＥＬコマンドを受信すると（ステップＳ６のＹｅｓ）、ＣＡＮＣＥＬコマンドで指定された位置（例えば、図９中の時点ｘ）以降で無効化されている部分を有効化して（ステップＳ７）、本処理ルーチンを終了する。
一方、ＳｉｎｋからＣＡＮＣＥＬコマンドを受信しないときには（ステップＳ６のＮｏ）、ＭＯＶＥ動作を中断する必要があるかどうかをチェックする（ステップＳ７）。ＭＯＶＥ動作の中断が必要となるのは、ユーザや他のアプリケーションから中断の要求がある場合、タイムアウトした場合などである。
ＭＯＶＥ動作を中断する必要があるときには（ステップＳ７のＹｅｓ）、本処理ルーチンを終了する。また、ＭＯＶＥ動作を中断する必要がないときには（ステップＳ７のＮｏ）、ＳｉｎｋからＯＫコマンドを受信したことにより（ステップＳ８のＹｅｓ）、本処理ルーチンを終了する。
また、ＯＫコマンドを受信しないときには（ステップＳ９のＮｏ）、ステップＳ２に戻って、Ｓｉｎｋから次のコンテンツの送信要求を待機する。
なお、Ｓｏｕｒｃｅが無効化したデータ部分の再送を行なうときは、Ｓｉｎｋが当該再送部分を別に複製に用いないことが前提である。Ｓｏｕｒｃｅは、認証時にＳｉｎｋがこの前提を遵守できるかどうかを確認し、確認できないときには再送を拒否するようにしてもよい。
図１２には、即時的なＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ動作によりＳｉｎｋがＳｏｕｒｃｅからコンテンツをダウンロードする場合に、Ｓｉｎｋが実行する動作手順をフローチャートの形式で示している。
まず、コンテンツ送信元機器となるＳｏｕｒｃｅとの間で認証及び鍵交換（ＡＫＥ）手続き用のＴＣＰコネクションを確立して、ＡＫＥ処理を行なう（ステップＳ１１）。
ＡＫＥに成功すると、Ｓｏｕｒｃｅとの間でコンテンツ伝送用のＴＣＰコネクションを確立する。そして、Ｓｉｎｋは、コンテンツの未送信部分のデータの送信要求を送信する（ステップＳ１２）。
ここで、送信要求した部分のデータを正常に受信することができなかったときには（ステップＳ１３のＮｏ）、データの再送を行なう必要があるかどうかをチェックする（ステップＳ１４）。データの再送が必要となるのは、タイムアウトが発生した場合や、受信データに異常がある場合、受信データが不完全な場合などである。
データ再送が必要でなければ（ステップＳ１４のＮｏ）、ステップＳ１３に戻って、正常なデータを受信するまで待機する。データ再送が必要なときは（ステップＳ１４のＹｅｓ）、既に送信されたデータの再送要求をＳｏｕｒｃｅに送信した後（ステップＳ１５）、ステップＳ１３に戻って、正常なデータを受信するまで待機する。なお、Ｓｏｕｒｃｅから無効化したデータ部分の再送を行なうときは、Ｓｉｎｋが当該再送部分を別に複製に用いないことが前提である。
また、送信要求した部分のデータを正常に受信することができたときには（ステップＳ１３のＹｅｓ）、コンテンツのすべてのデータを受信したかどうかをチェックする（ステップＳ１６）。未送信のデータが残っているときには、コンテンツのＭＯＶＥ動作を中断する必要があるかどうかをチェックする（ステップＳ１７）。ＭＯＶＥ動作の中断が必要となるのは、ユーザや他のアプリケーションから中断の要求が発生した場合、タイムアウトした場合などである。
ＭＯＶＥ動作を継続する場合には（ステップＳ１７のＮｏ）、ステップＳ１２に戻り、未送信のデータの受信処理を繰り返し行なう。
一方、ＭＯＶＥ動作を中断すべき場合には（ステップＳ１７のＹｅｓ）、中断後に有効にならない範囲の先頭位置ｘを決定し、ＣＡＮＣＥＬコマンドでｘをＳｏｕｒｃｅに通知するとともに（ステップＳ１８）、Ｓｉｎｋ側では受信したコンテンツのｘ以降の部分のデータを無効化して（ステップＳ１９）、本処理ルーチンを終了する。ここで言う無効化の処理は上述と同様である。
また、コンテンツを構成するすべてのデータを受信したときには（ステップＳ１６のＹｅｓ）、Ｓｉｎｋは、Ｓｏｕｒｃｅに対してＯＫコマンドを送信し（ステップＳ２０）、本処理ルーチン全体を終了する。
図１３には、即時的なＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ動作によりＳｏｕｒｃｅがＳｉｎｋへコンテンツをアップロードする場合に、Ｓｏｕｒｃｅが実行する動作手順をフローチャートの形式で示している。
まず、コンテンツ送信先機器となるＳｉｎｋとの間で認証及び鍵交換（ＡＫＥ）手続き用のＴＣＰコネクションを確立して、ＡＫＥ処理を行なう（ステップＳ２１）。Ｓｏｕｒｃｅが最初に鍵を渡す相手は１台のＳｉｎｋに限定する。ＡＫＥに成功すると、Ｓｉｎｋとの間でコンテンツ伝送用のＴＣＰコネクションを確立する。
そして、アップロードすべきすべてのコンテンツを送信したかどうかをチェックする（ステップＳ２２）。
未送信のコンテンツ・データがあるときには（ステップＳ２２のＮｏ）、そのデータの送信を行なう（ステップＳ２３）。そして、送信した部分のデータを無効化する（ステップＳ２４）。
送信したデータのコンテンツを無効化した後、並びに送信すべきすべてのコンテンツを送信した後（ステップＳ２２のＹｅｓ）、無効化したデータの再送要求をＳｉｎｋから受信したかどうかをチェックする（ステップＳ２５）。
データの再送要求を受信したときには（ステップＳ２５のＹｅｓ）、指定された部分のデータを送信する（ステップＳ２６）。但し、データ再送を行なうときは、Ｓｉｎｋが当該再送部分を別に複製に用いないことが前提である。Ｓｏｕｒｃｅは、認証時にＳｉｎｋがこの前提を遵守できるかどうかを確認し、確認できないときには再送を拒否するようにしてもよい。
データの再送要求を受信しなかったとき（ステップＳ２５のＮｏ）、並びに、再送要求に応じてデータ再送を行なった後、Ｓｏｕｒｃｅは、ＳｉｎｋからＣＡＮＣＥＬコマンドを受信したかどうかをチェックする（ステップＳ２７）。
ＣＡＮＣＥＬコマンドを受信したときには（ステップＳ２７のＹｅｓ）、ＣＡＮＣＥＬコマンドで指定された位置（例えば、図９中の時点ｘ）以降で無効化されている部分を有効化して（ステップＳ２８）、本処理ルーチンを終了する。
一方、ＳｉｎｋからＣＡＮＣＥＬコマンドを受信しないときには（ステップＳ２７のＮｏ）、ＭＯＶＥ動作を中断する必要があるかどうかをチェックする（ステップＳ２９）。本処理ルーチンを終了する。ＭＯＶＥ動作の中断が必要となるのは、ユーザや他のアプリケーションから中断の要求がある場合、タイムアウトした場合などである。ＭＯＶＥ動作を中断する必要があるときには、本処理ルーチンを終了する。また、ＭＯＶＥ動作を中断する必要がないときには、ＳｉｎｋからＯＫコマンドを受信して（ステップＳ３０のＹｅｓ）、確約を経た後に本処理ルーチンを終了する。
また、ＯＫコマンドを受信しないときには（ステップＳ３０のＮｏ）、ステップＳ２に戻って、Ｓｉｎｋから次のコンテンツの送信要求を待機する。
図１４には、即時的なＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ動作によりＳｏｕｒｃｅがＳｉｎｋへコンテンツをアップロードする場合に、Ｓｉｎｋが実行する動作手順をフローチャートの形式で示している。
まず、コンテンツ送信元機器となるＳｏｕｒｃｅとの間で認証及び鍵交換（ＡＫＥ）手続き用のＴＣＰコネクションを確立して、ＡＫＥ処理を行なう（ステップＳ３１）。ＡＫＥに成功すると、Ｓｏｕｒｃｅとの間でコンテンツ伝送用のＴＣＰコネクションを確立する。
そして、Ｓｉｎｋは、Ｓｏｕｒｃｅからデータを正常に受信できたかどうかをチェックする（ステップＳ３２）。
ここで、データを正常に受信することができなかったときには（ステップＳ３２のＮｏ）、データの再送を行なう必要があるかどうかをチェックする（ステップＳ３３）。データの再送が必要となるのは、タイムアウトが発生した場合や、受信データに異常がある場合、受信データが不完全な場合などである。
データ再送が必要でなければ（ステップＳ３３のＮｏ）、ステップＳ３２に戻って、正常なデータを受信するまで待機する。データ再送が必要なときは（ステップＳ３３のＹｅｓ）、既に送信されたデータの送信要求をＳｏｕｒｃｅに送信した後（ステップＳ３４）、ステップＳ３２に戻って、正常なデータを受信するまで待機する。なお、Ｓｏｕｒｃｅから無効化したデータ部分の再送を行なうときは、Ｓｉｎｋは正常に受信できなかった部分の補完以外の目的には使用しない。
また、ＳｉｎｋがＳｏｕｒｃｅからデータを正常に受信することができたときには（ステップＳ３２のＹｅｓ）、コンテンツのすべてのデータを受信したかどうかをチェックする（ステップＳ３５）。未送信のデータが残っているときには、コンテンツのＭＯＶＥ動作を中断する必要があるかどうかをチェックする（ステップＳ３６）。ＭＯＶＥ動作の中断が必要となるのは、ユーザや他のアプリケーションから中断の要求が発生した場合、タイムアウトした場合などである。
ＭＯＶＥ動作を継続する場合には（ステップＳ３６のＮｏ）、ステップＳ３２に戻り、未送信のデータの受信処理を繰り返し行なう。
一方、ＭＯＶＥ動作を中断すべき場合には（ステップＳ３６のＹｅｓ）、中断後に有効にならない範囲の先頭位置ｘを決定し、ＣＡＮＣＥＬコマンドでｘをＳｏｕｒｃｅに通知するとともに（ステップＳ３７）、Ｓｉｎｋ側では受信したコンテンツのｘ以降の部分のデータを無効化して（ステップＳ３８）、本処理ルーチンを終了する。ここで言う無効化の処理は上述と同様である。
また、コンテンツを構成するすべてのデータを受信したときには（ステップＳ３５のＹｅｓ）、Ｓｉｎｋは、Ｓｏｕｒｃｅに対してＯＫコマンドを送信し（ステップＳ３９）、本処理ルーチン全体を終了する。
Ｃ−２．確約付きのＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ
図１５〜１７には、受信データに関してＳｏｕｒｃｅとの間で確約（ｃｏｍｍｉｔｍｅｎｔ）を経た後にＳｉｎｋ側で利用可能にするようにする場合のコンテンツ伝送シーケンスを模式的に示している。
ＳｉｎｋにＭＯＶＥされたデータは、当該データに関してＳｏｕｒｃｅとの間で確約手続きを行なうまでは利用不可能な状態を保つ。Ｓｏｕｒｃｅは、確約手続きでＳｉｎｋから指定されたデータ部分を利用不可能にする。本実施形態では、確約手続きを行なうために、“ＯＫ”というコマンドを定義している。Ｓｉｎｋは、受信データのうち利用可能にしたい（すなわち確約の対象となる）データ部分をＯＫコマンドに記して、Ｓｏｕｒｃｅに送信する。
図１５には、コンテンツ全体の伝送が成功裏に終了する場合のシーケンス例を示している。Ｓｉｎｋは、ｐまでデータを受信した時点でそのデータを利用可能にしたい場合には、時点ｐを引数に含んだＯＫコマンドをＳｏｕｒｃｅに送信して、確約手続きを行なう。そして、Ｓｏｕｒｃｅ側で時点ｐまでのデータを利用不可能にする（すなわち無効化する）ことと引き換えに、Ｓｉｎｋ側では当該時点までのデータの利用を可能にする（すなわち有効化する）ことができる。
さらに、Ｓｉｎｋは、ｑまでデータを受信した時点、並びに、ｒまでデータを受信した時点においても、ＯＫコマンドをＳｏｕｒｃｅに送信して、確約手続きを行ない、各々の時点でそれぞれデータを利用可能な状態にしている。
Ｓｉｎｋが確約手続きを行なう時点は、例えば、Ｓｉｎｋ側で利用するのに都合のよいデータ単位（受信バッファサイズなど）である。図１５に示した例では、このような数回の確約手続きを経て、コンテンツ全体のＭＯＶＥが完了する。
コンテンツ伝送の途中で新たにＭＯＶＥしたデータ増分について確約手続きを行なうことで、各時点での受信データを逐次的に利用可能にすることができる。このように追加分のデータに関する確約手続きを逐次的に行なうＭＯＶＥ動作のことを中間的な確約手続き（ＩＮＴＥＲＭＥＤＩＡＴＥ ＣＯＭＭＩＴＭＥＮＴ）と呼ぶこともできる。勿論、中間的な確約手続きを行なわず、コンテンツ全体の伝送が完了した時点でＳｉｎｋがコンテンツ全体に関するＯＫコマンドを送信し、一括して確約手続きを行なうようにしてもよいが、これは“ＢＬＯＣＫ ＭＯＶＥ”に相当する。ＢＬＯＣＫ ＭＯＶＥに関しては、例えば本出願人に既に譲渡されている特願２００６−４１２９号明細書を参照されたい。
図１６には、中間的な確約手続きを行なうコンテンツ伝送の途中で障害が発生した場合の伝送シーケンス例を示している。Ｓｉｎｋは、ｐまでデータを受信した時点でそのデータを利用可能にしたい場合には、時点ｐを引数に含んだＯＫコマンドをＳｏｕｒｃｅに送信して、確約手続きを行なう。そして、Ｓｏｕｒｃｅ側で時点ｐまでのデータを利用不可能にすることと引き換えに、Ｓｉｎｋ側では当該時点までのデータの利用を可能にする。同様に、ｑまでデータを受信した時点で確約手続きを行なうことで、Ｓｉｎｋ側では当該時点までのデータの利用を可能にする。
ここで、コンテンツ伝送に障害が発生し、且つ、以降でＭＯＶＥ処理を再開（Ｒｅｓｕｍｅ）することができないときには、伝送後のデータ部分はＳｉｎｋ側に、伝送前のデータ部分はＳｏｕｒｃｅに残り、コンテンツが分断される。即時的なＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥでは、ＭＯＶＥが中断してＲｅｓｕｍｅすることができない場合は必ずコンテンツが分断されるが（図８〜図９を参照のこと）、確約付きのＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥでは、中間的な確約手続きを行なった後にＭＯＶＥが中断し、且つＭＯＶＥ処理をＲｅｓｕｍｅできないときのみコンテンツの分断が生じる。
図１５に示した例では、複数回の中間的な確約手続きを行なっているが、Ｓｉｎｋ側で一旦利用可能にした受信データを利用不可能にすることができる場合には、確約を行なった後であってもＭＯＶＥを取り消すことができる。図１７に示す例では、Ｓｉｎｋは、ｐ、ｑ、並びにｒの各時点で中間的な確約手続きを行なった後、すべての受信データを利用不可能にすることを記したＣＡＮＣＥＬコマンドをＳｏｕｒｃｅに送信している。この場合、Ｓｏｕｒｃｅ側では送信したコンテンツが再び利用可能な状態となり、ＭＯＶＥをＵｎｄｏすることができる。
ＯＫコマンドの伝送は、安全なトランザクションで行なう必要がある。例えば、コマンド伝送用あるいはＡＫＥ用のＴＣＰコネクションを利用して、ＯＫコマンド並びにそれに関連するトランザクションを行なうことができる。ＯＫコマンドのフレーム・フォーマットについては後に説明する。
即時的なＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥでは、データ伝送トランザクションの途中で、コネクション・エラーに起因するデータの欠落が生じ得る。また、伝送トランザクション中に機器の電源がオフされたことに伴い、バッファリングされたデータの欠落が生じ得る。これに対し、確約付きのＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥによれば、確約手続きを経てからでないとＳｏｕｒｃｅはデータの無効化を行なわないから、コネクション・エラーのためにデータの欠落が生じることはない。また、伝送トランザクション中に機器の電源がオフされた場合であっても、確約前のデータを不揮発記憶領域に格納しておくことで、データの欠落を回避することができる。
また、即時的なＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥでは、ＭＯＶＥをＵｎｄｏする手続きを安全なトランザクションで行なう必要があるのに対し、確約付きのＩＮＣＲＥＮＥＭＴＡＮ ＭＯＶＥでＵｎｄｏを行なうには、中間的な確約手続きを経た場合のみ安全なトランザクションが必要となる。
ＳｏｕｒｃｅからＳｉｎｋへコンテンツをＭＯＶＥするのは、クライアントとして動作するＳｉｎｋがコンテンツ・サーバとして動作するＳｏｕｒｃｅからコンテンツをダウンロードするケースと、クライアントとして動作するＳｕｒｃｅがコンテンツ・サーバとして動作するＳｉｎｋへコンテンツをアップロードするケースが想定される。以下では、それぞれのケースについて、Ｓｏｕｒｃｅ並びにＳｉｎｋが確約付きＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥを行なうための動作手順について説明する。
図１８には、確約付きのＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ動作によりＳｉｎｋがＳｏｕｒｃｅからコンテンツをダウンロードする場合に、Ｓｏｕｒｃｅが実行する動作手順をフローチャートの形式で示している。
まず、コンテンツ送信先機器となるＳｉｎｋとの間で認証及び鍵交換（ＡＫＥ）手続き用のＴＣＰコネクションを確立して、ＡＫＥ処理を行なう（ステップＳ５１）。Ｓｏｕｒｃｅが最初に鍵を渡す相手は１台のＳｉｎｋに限定する。
ＡＫＥに成功すると、Ｓｉｎｋとの間でコンテンツ伝送用のＴＣＰコネクションを確立する。そして、Ｓｉｎｋからコンテンツの送信要求を受信すると（ステップＳ５２のＹｅｓ）、指定された部分のデータを送信する（ステップＳ５３）。なお、データ送信処理と並行して、Ｓｏｕｒｃｅでは送信したデータの無効化処理を行なうが、その無効化処理動作の詳細については後述に譲る。
また、Ｓｏｕｒｃｅは、ＳｉｎｋからＣＡＮＣＥＬコマンドを受信すると（ステップＳ５４のＹｅｓ）、ＣＡＮＣＥＬコマンドで指定された位置以降で無効化されているデータ部分を有効化して（ステップＳ５５）、本処理ルーチンを終了する。
一方、ＳｉｎｋからＣＡＮＣＥＬコマンドを受信しないときには（ステップＳ５４のＮｏ）、ＭＯＶＥ動作を中断する必要があるかどうかをチェックする（ステップＳ５６）。ＭＯＶＥ動作の中断が必要となるのは、ユーザや他のアプリケーションから中断の要求がある場合、タイムアウトした場合などである。
ＭＯＶＥ動作を中断する必要があるときには（ステップＳ５６のＹｅｓ）、本処理ルーチンを終了する。また、ＭＯＶＥ動作を中断する必要がないときには（ステップＳ５６のＮｏ）、既にＳｉｎｋに送信したデータが図１９に示す処理手順（後述）に従って最後まで無効化されているかどうかをチェックする（ステップＳ５７）。最後まで無効化されているときには、本処理ルーチンを終了する。また、最後まで無効化されていないときには、ステップＳ５２に戻り、Ｓｉｎｋからの次の送信要求を待機する。
Ｓｏｕｒｃｅは、図１８に示した処理手順に従ってＳｉｎｋにコンテンツをダウンロードする際、これの処理とは並行して、Ｓｉｎｋからの通知（すなわちＯＫコマンドを用いた確約手続き）に基づいて、送信済みデータの無効化処理を行なう。ここで言う「無効化」とは、実際にデータを消したり変えたりすることではなく、再送以外の目的での利用を抑制する処理である（同上）。Ｓｏｕｒｃｅが無効化したデータ部分の再送を行なうときは、Ｓｉｎｋが当該再送部分を別に複製に用いないことが前提である。Ｓｏｕｒｃｅは、認証時にＳｉｎｋがこの前提を遵守できるかどうかを確認し、確認できないときには再送を拒否するようにしてもよい。
図１９には、確約付きのＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥを行なう際にＳｏｕｒｃｅが並行して行なうデータ無効化処理の手順をフローチャートの形式で示している。
Ｓｏｕｒｃｅは、Ｓｉｎｋに対してコンテンツの送信を開始してから（ステップＳ６１のＹｅｓ）、中断するまでの間に（ステップＳ６２のＮｏ）、ＯＫコマンドを受信すると（ステップＳ６３のＹｅｓ）、送信したデータの有効範囲の先頭からＯＫコマンドで指定された位置ｘまで無効化を行なう（ステップＳ６４）。
送信したコンテンツの最後のデータまで無効化したら（ステップＳ６５のＹｅｓ）、本処理ルーチンを終了する。また、送信したコンテンツの最後のデータまで無効化しないときには（ステップＳ６５のＮｏ）、ステップＳ６２に戻って、中断の発生又は次のＯＫコマンドの受信を待機する。
また、ＭＯＶＥ動作が中断したときには（ステップＳ６２のＹｅｓ）、本処理ルーチンを終了する。
図２０には、確約付きのＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ動作によりＳｉｎｋがＳｏｕｒｃｅからコンテンツをダウンロードする場合に、Ｓｉｎｋが実行する動作手順をフローチャートの形式で示している。
まず、コンテンツ送信元機器となるＳｏｕｒｃｅとの間で認証及び鍵交換（ＡＫＥ）手続き用のＴＣＰコネクションを確立して、ＡＫＥ処理を行なう（ステップＳ７１）。
ＡＫＥに成功すると、Ｓｏｕｒｃｅとの間でコンテンツ伝送用のＴＣＰコネクションを確立する。そして、Ｓｉｎｋは、コンテンツの未送信部分のデータの送信要求を送信し（ステップＳ７２）、要求したデータ部分をＳｏｕｒｃｅから正しく受信できたかどうかをチェックする（ステップＳ７３）。なお、Ｓｏｕｒｃｅからのデータ受信処理と並行して、Ｓｉｎｋでは受信したデータの有効化処理を行なうが、その有効化処理動作の詳細については後述に譲る。
ここで、送信要求した部分のデータを正常に受信することができなかったときには（ステップＳ７３のＮｏ）、データの再送を行なう必要があるかどうかをチェックする（ステップＳ７４）。データの再送が必要となるのは、タイムアウトが発生した場合や、受信データに異常がある場合、受信データが不完全な場合などである。
データ再送が必要でなければ（ステップＳ７４のＮｏ）、ステップＳ７３に戻って、正常なデータを受信するまで待機する。データ再送が必要なときは（ステップＳ７４のＹｅｓ）、既に送信されたデータの再送要求をＳｏｕｒｃｅに送信した後（ステップＳ７５）、ステップＳ７３に戻って、正常なデータを受信するまで待機する。なお、Ｓｏｕｒｃｅから無効化したデータ部分の再送を行なうときは、Ｓｉｎｋが当該再送部分を別に複製に用いないことが前提である。
また、送信要求した部分のデータを正常に受信することができたときには（ステップＳ７３のＹｅｓ）、受信したデータを図２１に示す処理手順（後述）に従って最後まで有効化したかどうかをチェックする（ステップＳ７６）。最後まで有効化したならば、本処理ルーチンを終了する。
有効化していない受信データが残っているときには（ステップＳ７６のＮｏ）、コンテンツのＭＯＶＥ動作を中断する必要があるかどうかをチェックする（ステップＳ７７）。ＭＯＶＥ動作の中断が必要となるのは、ユーザや他のアプリケーションから中断の要求が発生した場合、タイムアウトした場合などである。
ＭＯＶＥ動作を継続する場合には（ステップＳ７７のＮｏ）、ステップＳ７２にて送信を要求したコンテンツを最後まで受信したかどうかをチェックする（ステップＳ８０）。そして、最後まで受信していなければ、ステップＳ１２に戻り、未送信のデータの受信処理を繰り返し行なう。また、最後まで受信していれば、ステップＳ７６に戻り、受信データを最後まで有効化したかどうかをチェックする。
一方、ＭＯＶＥ動作を中断すべき場合には（ステップＳ７７のＹｅｓ）、中断後に有効にならない範囲の先頭位置ｘを決定し、ＣＡＮＣＥＬコマンドでｘをＳｏｕｒｃｅに通知するとともに（ステップＳ７８）、Ｓｉｎｋ側では受信したコンテンツのｘ以降の部分のデータを無効化して（ステップＳ７９）、本処理ルーチンを終了する。
Ｓｉｎｋは、図２０に示した処理手順に従ってＳｏｕｒｃｅからコンテンツをダウンロードする際、これの処理とは並行して、Ｓｏｕｒｃｅへの通知（すなわちＯＫコマンドを用いた確約手続き）に基づいて、受信データの有効化処理を行なう。ここで言う「有効化」は、利用不能状態のデータを再生利用が可能な状態にする処理である。
図２１には、確約付きのＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥを行なう際にＳｉｉｎｋが並行して行なうデータ有効化処理の手順をフローチャートの形式で示している。
まず、有効化する前のコンテンツ・データが所定の有効化単位だけ受信したか（すなわち受信データ・バッファに蓄積されたか）どうかをチェックする（ステップＳ８１）。有効化前のコンテンツ・データを未だ所定の有効化単位だけ受信していないときには（ステップＳ８１のＮｏ）、有効化前のコンテンツを最後まで受信するまで（ステップＳ８２）、Ｓｏｕｒｃｅからのデータ受信を待機する。
そして、有効化する前のコンテンツ・データを所定の有効化単位だけ受信すると（ステップＳ８１のＹｅｓ）、ＭＯＶＥ動作が中断したかどうかをチェックする（ステップＳ８３）。ＭＯＶＥ動作が中断したときには、本処理ルーチンを終了する。
一方、ＭＯＶＥ動作が中断していないときには（ステップＳ８３のＮｏ）、有効化する部分の末尾位置ｘをＯＫコマンドでＳｏｕｒｃｅに通知し（ステップＳ８４）、さらに無効範囲の先頭から末尾位置ｘを有効化する（ステップＳ８５）。
そして、コンテンツを最後まで有効化したときには（ステップＳ８６のＹｅｓ）、本処理ルーチンを終了し、最後まで有効化していないときには（ステップＳ８６のＮｏ）、ステップＳ８１に戻る。
図２２には、確約付きのＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ動作によりＳｏｕｒｃｅがＳｉｎｋへコンテンツをアップロードする場合に、Ｓｏｕｒｃｅが実行する動作手順をフローチャートの形式で示している。
まず、コンテンツ送信先機器となるＳｉｎｋとの間で認証及び鍵交換（ＡＫＥ）手続き用のＴＣＰコネクションを確立して、ＡＫＥ処理を行なう（ステップＳ９１）。Ｓｏｕｒｃｅが最初に鍵を渡す相手は１台のＳｉｎｋに限定する。ＡＫＥに成功すると、Ｓｉｎｋとの間でコンテンツ伝送用のＴＣＰコネクションを確立する。
そして、アップロードすべきすべてのコンテンツを送信したかどうかをチェックし（ステップＳ９２）、未送信のコンテンツ・データがあるときにはそのデータの送信を行なう（ステップＳ９３）。なお、データ送信処理と並行して、Ｓｏｕｒｃｅでは、ＳｉｎｋからのＯＫコマンドの受信に基づいて送信したデータの無効化処理を行なうが、その動作手順は図１９に示したフローチャートに従う。
次いで、無効化したデータの再送要求をＳｉｎｋから受信したかどうかをチェックする（ステップＳ９４）。データの再送要求を受信したときには、指定された部分のデータを送信する（ステップＳ９５）。但し、データ再送を行なうときは、Ｓｉｎｋが当該再送部分を別に複製に用いないことが前提である。Ｓｏｕｒｃｅは、認証時にＳｉｎｋがこの前提を遵守できるかどうかを確認し、確認できないときには再送を拒否するようにしてもよい。
データの再送要求を受信しなかったとき（ステップＳ９４のＮｏ）、並びに、再送要求に応じてデータ再送を行なった後、Ｓｏｕｒｃｅは、ＳｉｎｋからＣＡＮＣＥＬコマンドを受信したかどうかをチェックする（ステップＳ９６）。
ＣＡＮＣＥＬコマンドを受信したときには（ステップＳ９６のＹｅｓ）、ＣＡＮＣＥＬコマンドで指定された位置以降で無効化されているデータ部分を有効化して（ステップＳ９７）、本処理ルーチンを終了する。
一方、ＳｉｎｋからＣＡＮＣＥＬコマンドを受信しないときには（ステップＳ９６のＮｏ）、ＭＯＶＥ動作を中断する必要があるかどうかをチェックする（ステップＳ９８）。本処理ルーチンを終了する。ＭＯＶＥ動作の中断が必要となるのは、ユーザや他のアプリケーションから中断の要求がある場合、タイムアウトした場合などである。ＭＯＶＥ動作を中断する必要があるときには、本処理ルーチンを終了する。
また、ＭＯＶＥ動作を中断する必要がないときには（ステップＳ９８のＮｏ）、Ｓｉｎｋに既に送信したデータが図１９に示した処理手順に従って最後まで無効化されたかどうかをチェックする（ステップＳ９９）、最後まで無効化されているときには本処理ルーチンを終了する。最後まで無効化されていないときには、ステップＳ９２に戻る。
図２３には、確約付きのＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ動作によりＳｏｕｒｃｅがＳｉｎｋへコンテンツをアップロードする場合に、Ｓｉｎｋが実行する動作手順をフローチャートの形式で示している。
まず、コンテンツ送信元機器となるＳｏｕｒｃｅとの間で認証及び鍵交換（ＡＫＥ）手続き用のＴＣＰコネクションを確立して、ＡＫＥ処理を行なう（ステップＳ１０１）。ＡＫＥに成功すると、Ｓｏｕｒｃｅとの間でコンテンツ伝送用のＴＣＰコネクションを確立する。
そして、Ｓｉｎｋは、Ｓｏｕｒｃｅからデータを正常に受信できたかどうかをチェックする（ステップＳ１０２）。なお、Ｓｏｕｒｃｅからのデータ受信処理と並行して、Ｓｉｎｋでは受信したデータの有効化処理を行なうが、図２１に示した動作手順に従ってその処理が行なわれる。
ここで、送信要求した部分のデータを正常に受信することができなかったときには（ステップＳ１０２のＮｏ）、データの再送を行なう必要があるかどうかをチェックする（ステップＳ１０３）。データの再送が必要となるのは、タイムアウトが発生した場合や、受信データに異常がある場合、受信データが不完全な場合などである。
データ再送が必要でなければ（ステップＳ１０３のＮｏ）、ステップＳ１０２に戻って、正常なデータを受信するまで待機する。データ再送が必要なときは（ステップＳ１０３のＹｅｓ）、既に送信されたデータの送信要求をＳｏｕｒｃｅに送信した後（ステップＳ１０４）、ステップＳ１０２に戻って、正常なデータを受信するまで待機する。なお、Ｓｏｕｒｃｅから無効化したデータ部分の再送を行なうときは、Ｓｉｎｋは正常に受信できなかった部分の補完以外の目的には使用しない。
また、送信要求した部分のデータを正常に受信することができたときには（ステップＳ１０２のＹｅｓ）、受信したデータが図２１に示した処理手順に従って最後まで有効化されたかどうかをチェックする（ステップＳ１０５）。最後まで有効化されていたならば、本処理ルーチンを終了する。
有効化されていない受信データが残っているときには（ステップＳ１０５のＮｏ）、コンテンツのＭＯＶＥ動作を中断する必要があるかどうかをチェックする（ステップＳ１０６）。ＭＯＶＥ動作の中断が必要となるのは、ユーザや他のアプリケーションから中断の要求が発生した場合、タイムアウトした場合などである。
ＭＯＶＥ動作を継続する場合には（ステップＳ１０６のＮｏ）、ステップＳ７２にて送信を要求したコンテンツを最後まで受信したかどうかをチェックする（ステップＳ１０９）。そして、最後まで受信していなければ、ステップＳ１０２に戻り、未送信のデータの受信処理を繰り返し行なう。また、最後まで受信していれば、ステップＳ１０５に戻り、受信データを最後まで有効化したかどうかをチェックする。
一方、ＭＯＶＥ動作を中断すべき場合には（ステップＳ１０６のＹｅｓ）、中断後に有効にならない範囲の先頭位置ｘを決定し、ＣＡＮＣＥＬコマンドでｘをＳｏｕｒｃｅに通知するとともに（ステップＳ１０７）、Ｓｉｎｋ側では受信したコンテンツのｘ以降の部分のデータを無効化して（ステップＳ１０８）、本処理ルーチンを終了する。
Ｃ−３．ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥを実現するＳｉｎｋの構成
本実施形態に係るコンテンツ伝送システムでは、ＣＡＮＣＥＬコマンドを利用することで、ＳｏｕｒｃｅからＳｉｎｋへ一旦ＭＯＶＥしたコンテンツを任意の範囲で取り消すことができる。
ＣＡＮＣＥＬを実現するには、Ｓｉｎｋが既に受信したデータのうち、特定の時点又は任意の時点から利用不能にすることができる仕組みを持つことが前提となる。
Ｓｉｎｋの概略的な機能構成は、図２を参照しながら既に説明した通りである。すなわち、ＤＴＣＰ−ＩＰ認証ブロック内では、ＡＫＥブロックによりＳｏｕｒｃｅとの間で鍵Ｋxが交換される。そして、コンテンツ復号ブロックは、鍵Ｋxからコンテンツ復号鍵Ｋcを算出し、ＤＴＣＰ−ＩＰコンテンツ受信ブロックでＳｏｕｒｃｅから受信した暗号化コンテンツをこの復号鍵Ｋcで復号する。
図２４には、一旦有効化したコンテンツ・データを無効化すなわち利用不能にするためのＤＴＣＰ−ＩＰ認証ブロックの機能構成例を示している。図示のＤＴＣＰ−ＩＰ認証ブロックは、コンテンツ復号ブロックにて復号したコンテンツ・データを一時的に格納するコンテンツ・バッファ・ブロックと、バッファリングされたコンテンツ・データを記録するコンテンツ記録ブロックを備えている。コンテンツ管理ブロックでは、ＣＡＮＣＥＬやＯＫなどＳｏｕｒｃｅへ発行するコマンドに基づいて、コンテンツ・バッファ・ブロック並びにコンテンツ記録ブロックに格納されているコンテンツ・データの管理を行なう。
コンテンツの保存方法として、ハード・ディスクなどの書き換え可能な記録媒体に記録されている場合と、１回のみ書き込み可能な記録媒体に記録されて書き換え不可能な場合がある。コンテンツ記録ブロックに保存されたコンテンツが書き換え可能な場合は、有効化前のコンテンツを保存して、後から有効化することもできる。一方、コンテンツ記録ブロックに保存されたコンテンツが書き換え不可の場合は、コンテンツ・データは有効化後の状態で保存する必要がある。また、コンテンツ記録ブロックを、コンテンツ復号ブロックと同様に、耐タンパ性のあるＤＴＣＰ−ＩＰ認証ブロック内に配置することで、コンテンツ復号ブロックとコンテンツ記録ブロック間での復号コンテンツの漏洩の問題はなくなる。
なお、コンテンツ再生ブロックでは、伝送内容のリアルタイム・モニタリングとしての使い方であれば、有効化前のデータをコンテンツ記録ブロックから読み出して、そのままビデオ及びオーディオ信号に変換（ｒｅｎｄｅｒｉｎｇ）して、ディスプレイなどのＡＶ出力部から映像並びに音響出力することはできる。このような復号コンテンツの再生方法は、出力とともにデータが失われるのでコンテンツのコピーには相当せず、ＳｏｕｒｃｅとＳｉｎｋの両方に再生可能なコンテンツが重複して存在してはならないというＤＴＣＰ規格に抵触しないからである。
ここで、ＩＮＣＲＥＭＡＮＴＡＬ ＭＯＶＥされたコンテンツ・データをＳｉｎｋ側ですべてＣＡＮＣＥＬするには、コンテンツ・バッファ・ブロック内のデータに加え、コンテンツ記録ブロック内に書き込まれたデータもすべて無効化することができることが前提となる。また、コンテンツ記録ブロック内に書き込んだデータを無効化することができない場合であっても、コンテンツ・バッファ・ブロック内のデータを破棄することができるならば、その部分だけはＣＡＮＣＥＬすることが許容される。
データ再送が必要となるケースを挙げて具体的に説明する。コンテンツ復号ブロックにより復号されたコンテンツが複数のデータ・ブロックからなり、それぞれがシーケンス・カウンタを持つとする。コンテンツ・バッファ・ブロックでは、受信したデータ・ブロックのシーケンス・カウンタが不連続であれば、その箇所のデータが欠落していることを確認することができる。この場合、最後に正常と確認されたデータ・ブロック以降をコンテンツ記録ブロックに転送する前に、再送処理を起動して欠落したデータ・ブロックをＳｏｕｒｃｅに再送要求して取得し直すことで、不連続なデータをコンテンツ記録ブロックに渡すことを防止できる。
また、Ｓｉｎｋが、図２０並びに図２３に示したように、確約付きのＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥを実装する場合には、コンテンツ復号ブロックで復号したデータを、Ｓｏｕｒｃｅとの間で確約を交わすまでは無効状態でバッファリングする必要がある。
図２５には、このような仕組みを備えたコンテンツ・バッファ・ブロックの構成例を示している。図示のコンテンツ・バッファ・ブロックは、あるデータ単位を無効状態で保持することができるバッファ・メモリを１以上備えている。ＯＫコマンドを使用した処理に要する時間も、Ｓｏｕｒｃｅからのコンテンツ受信や記録動作を継続する場合は、複数のバッファ・メモリを順次切り替えて使用する。
コンテンツ復号ブロックから復号後のデータが入力されると、まず、ＳＷ１により当該単位毎に各バッファ・メモリに振り分けられ、無効状態のままバッファされる。そして、ＯＫコマンドをＳｏｕｒｃｅに送信して受信通知処理を完了したデータ単位は、ＳＷ２を経由してコンテンツ記録ブロックに供給され、有効状態として格納される。
ＭＯＶＥ動作を完全にＣＡＮＣＥＬできるのは、コンテンツ・バッファ・ブロック内のすべてのデータに加え、コンテンツ記録ブロック内に書き込まれたデータもすべて無効化できる場合に限られる。また、コンテンツ記録ブロック内に書き込んだデータを無効化することができない場合であっても、コンテンツ・バッファ・ブロック内のデータを破棄することができるならば、その部分だけはＣＡＮＣＥＬすることが許容される。
再送が必要となる場合の処理は図２４の場合と同様なので、ここでは説明を省略する。
Ｃ−４．ＯＫコマンド、ＣＡＮＣＥＬコマンド
本実施形態に係るコンテンツ伝送システムでは、ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥを好適に実現するために、ＯＫ並びにＣＡＮＣＥＬというコマンドを定義した。これらのコマンドのフレーム・フォーマットの一例を図２６に示す。
命令コードでコマンドの種別を示し、メッセージで各コマンドのパラメータを送る。また、改竄防止用に、最後のシグニチャで命令コードとメッセージに対する電子署名を送る。但し、即時的なＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥにおいてＳｉｎｋから送るＯＫコマンドは、攻撃に利がないので、シグニチャを使用しないという運用形態も考えられる。
具体的なメッセージとして、確約付きのＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ処理においてＳｉｎｋから送信するＯＫコマンドについては、受信し終えたデータの末尾位置を先頭からのバイト数で示すことが考えられる。一方、即時的並びに確約付きのＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ処理においてＳｉｎｋから送信するＣＡＮＣＥＬコマンドについては、コンテンツの先頭からのバイト数で位置を示し、それ以降をＣＡＮＣＥＬする範囲とすることが考えられる。
また、シグニチャには、例えば鍵付きハッシュ値を用いることが考えられる最初に行なう認証及び鍵交換（ＡＫＥ）を通してＳｏｕｒｃｅとＳｉｎｋだけが共有する秘密鍵に所定の演算を施し、それを鍵として上記のメッセージ及び所定の情報に対する鍵付きハッシュ値を求める。なお、所定の情報はすべてのＳｏｕｒｃｅとＳｉｎｋがあらかじめ知っている特定の値を初期値として使うものとする。
ＯＫコマンドやＣＡＮＣＥＬコマンドは、Ｓｏｕｒｃｅに届いたことをＳｉｎｋ側で確実に確認することができないと、コンテンツの重複や欠落が生じてしまう。このため、実際には２相コミットメントなどの手続きを用いて、複数のやり取りを経て１つのコマンド処理を行なうことが考えられる。この場合、複数のやり取りを行なう際には上記のハッシュ対象の１つである所定の情報をＳｏｕｒｃｅとＳｉｎｋが同期して値を増やすなどの方法で順次切り替えることで、第３者に予測不能で且つＳｏｕｒｃｅとＳｉｎｋが互いに相手の正当性を確認するハッシュ値を生成することができ、トランザクションはより安全なものとなる。
以上、特定の実施形態を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
本発明の適用例として、ＳｏｕｒｃｅとＳｉｎｋ間で行なわれるＨＴＴＰプロトコルを利用したコンテンツ伝送を挙げることができるが、本発明の要旨はこれに限定されない。著作権やその他の目的で保護が必要となる情報コンテンツを所定のコピー制御情報に従って暗号化伝送する他のあらゆるコンテンツ伝送システム、あるいはコピー制御やコンテンツの暗号化を行なわないシステムであっても、移動元にデータを残さずに機器間でデータを移動させる際に、同様に本発明を適用することができる。
要するに、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、特許請求の範囲を参酌すべきである。
図１は、本発明の一実施形態に係る情報通信システムの構成例を模式的に示した図である。 図２は、図１に示した情報通信システムにおいて、Ｓｉｎｋとして動作する情報通信装置の機能構成を示した図である。 図３は、図１に示した情報通信システムにおいて、Ｓｏｕｒｃｅとして動作する情報通信装置の機能構成を示した図である。 図４は、ＳｏｕｒｃｅとＳｉｎｋの間でＡＫＥに基づく鍵交換手続き、及び鍵交換により共有した鍵を利用した暗号化コンテンツ伝送を行なう仕組みを説明するための図である 図５は、ＰＣＰのデータ構造を模式的に示した図である。 図６は、ＰＣＰペイロードにパディングする様子を示した図である。 図７は、ＭＯＶＥしたデータをＳｉｎｋ側で受信した直後に利用可能にする場合のコンテンツ伝送シーケンスを模式的に示した図である。 図８は、ＭＯＶＥしたデータをＳｉｎｋ側で受信した直後に利用可能にする場合のコンテンツ伝送シーケンス（途中で障害が生じた場合）を模式的に示した図である。 図９は、受信データのある時点ｘ以降のＭＯＶＥを取り消すためのコンテンツ伝送シーケンスを模式的に示した図である。 図１０は、ＭＯＶＥしたデータをＳｉｎｋ側で受信した直後に利用可能にする場合のコンテンツ伝送シーケンスを模式的に示した図である。 図１１は、即時的なＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ動作によりＳｉｎｋがＳｏｕｒｃｅからコンテンツをＭＯＶＥによりダウンロードする場合に、Ｓｏｕｒｃｅが実行する動作手順を示したフローチャートである。 図１２は、即時的なＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ動作によりＳｉｎｋがＳｏｕｒｃｅからコンテンツをダウンロードする場合に、Ｓｉｎｋが実行する動作手順を示したフローチャートである。 即時的なＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ動作によりＳｏｕｒｃｅがＳｉｎｋへコンテンツをアップロードする場合に、Ｓｏｕｒｃｅが実行する図１３は、動作手順を示したフローチャートである。 図１４は、即時的なＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ動作によりＳｏｕｒｃｅがＳｉｎｋへコンテンツをアップロードする場合に、Ｓｉｎｋが実行する動作手順を示したフローチャートである。 図１５は、受信データに関してＳｏｕｒｃｅとの間で確約を経た後に、Ｓｉｎｋ側で利用可能にするようにする場合のコンテンツ伝送シーケンスを模式的に示した図である。 図１６は、受信データに関してＳｏｕｒｃｅとの間で確約を経た後に、Ｓｉｎｋ側で利用可能にするようにする場合のコンテンツ伝送シーケンス（途中で障害が発生した場合）を模式的に示した図である。 図１７は、受信データに関してＳｏｕｒｃｅとの間で確約を経た後に、Ｓｉｎｋ側で利用可能にするようにする場合のコンテンツ伝送シーケンス（ＭＯＶＥをＵｎｄｏする場合）を模式的に示した図である。 図１８は、確約付きのＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ動作によりＳｉｎｋがＳｏｕｒｃｅからコンテンツをダウンロードする場合に、Ｓｏｕｒｃｅが実行する動作手順を示したフローチャートである。 図１９は、確約付きのＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥを行なう際にＳｏｕｒｃｅが並行して行なうデータ無効化処理の手順を示したフローチャートである。 図２０は、確約付きのＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ動作によりＳｉｎｋがＳｏｕｒｃｅからコンテンツをダウンロードする場合に、Ｓｉｎｋが実行する動作手順を示したフローチャートである。 図２１は、確約付きのＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥを行なう際にＳｉｉｎｋが並行して行なうデータ無効化処理の手順を示したフローチャートである。 図２２は、確約付きのＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ動作によりＳｏｕｒｃｅがＳｉｎｋへコンテンツをアップロードする場合に、Ｓｏｕｒｃｅが実行する動作手順を示したフローチャートである。 図２３は、確約付きのＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ動作によりＳｏｕｒｃｅがＳｉｎｋへコンテンツをアップロードする場合に、Ｓｉｎｋが実行する動作手順を示したフローチャートである。 図２４は、一旦有効化したコンテンツ・データを無効化すなわち利用不能にするためのＤＴＣＰ−ＩＰ認証ブロックの構成例を示した図である。 図２５は、コンテンツ・バッファ・ブロックの構成例を示した図である。 図２６は、ＯＫ並びにＣＡＮＣＥＬコマンドのフレーム・フォーマットの一例を示した図である。

Claims (19)

  1. コンテンツを送信するＳｏｕｒｃｅとコンテンツを受信するＳｉｎｋ間でコンテンツを伝送するコンテンツ伝送システムであって、
    前記Ｓｉｎｋは、前記Ｓｏｕｒｃｅから受信した部分のデータを逐次有効化するとともに、前記Ｓｏｕｒｃｅは、前記Ｓｉｎｋに送信した部分のデータを逐次無効化して、コンテンツを前記Ｓｏｕｒｃｅから前記Ｓｉｎｋへ移動する、
    ことを特徴とするコンテンツ伝送システム。
  2. 前記Ｓｉｎｋは、前記Ｓｏｕｒｃｅから受信して有効化したコンテンツ・データの少なくとも一部を無効化して、当該データの移動の取り消しを要求し、
    前記Ｓｏｕｒｃｅは、該取り消し要求に応じて、一旦無効化した当該送信データを有効化する、
    ことを特徴とする請求項１に記載のコンテンツ伝送システム。
  3. 前記Ｓｏｕｒｃｅは、前記Ｓｉｎｋからのデータを受信したことを示す所定の確約手続きに応じて送信データの無効化処理を行なう、
    ことを特徴とする請求項１に記載のコンテンツ伝送システム。
  4. 前記Ｓｉｎｋは、前記Ｓｏｕｒｃｅから受信して有効化したデータの範囲を指定した受領確認コマンドを送信し、
    前記Ｓｏｕｒｃｅは、該受領確認コマンドを受信したことに応じて、指定された範囲のデータを無効化する、
    ことを特徴とする請求項３に記載のコンテンツ伝送システム。
  5. 前記Ｓｉｎｋは、前記Ｓｏｕｒｃｅに対して確約手続きを行なって有効化した受信データの少なくとも一部を無効化して、当該データの移動の取り消しを要求し、
    前記Ｓｏｕｒｃｅは、該取り消し要求に応じて、確約手続きを経て一旦無効化した当該送信データを有効化する、
    ことを特徴とする請求項３に記載のコンテンツ伝送システム。
  6. ＤＴＣＰに従ってコンテンツを送信するＳｏｕｒｃｅとして動作するコンテンツ伝送装置であって、
    ＡＫＥ手続きによりＳｉｎｋとの間で相互認証及び鍵交換を行なう認証手段と、
    送信対象となるコンテンツのデータを、前記認証手段により交換した鍵を用いて前記Ｓｉｎｋへ暗号化伝送するデータ伝送手段と、
    前記データ伝送手段により送信された部分のデータを順次無効化するデータ無効化手段を備え、
    Ｓｉｎｋへコンテンツを移動することを特徴とするコンテンツ伝送装置。
  7. 前記Ｓｉｎｋからの移動取り消し要求に応じて、一旦無効化したデータを有効化するデータ有効化手段をさらに備える、
    ことを特徴とする請求項６に記載のコンテンツ伝送装置。
  8. 前記データ無効化手段は、前記Ｓｉｎｋがデータを受信したことを示す所定の確約手続きに応じて、前記データ伝送手段により送信したデータの無効化処理を行なう、
    ことを特徴とする請求項６に記載のコンテンツ伝送装置。
  9. 前記データ無効化手段は、有効化したデータの範囲を指定した受領確認コマンドを前記Ｓｉｎｋからデータを受信したことに応じて、前記データ伝送手段により送信したデータの無効化処理を行なう、
    ことを特徴とする請求項８に記載のコンテンツ伝送装置。
  10. 前記Ｓｉｎｋからの移動取り消し要求に応じて、確約手続きを経て一旦無効化したデータを有効化するデータ有効化手段をさらに備える、
    ことを特徴とする請求項８に記載のコンテンツ伝送装置。
  11. ＤＴＣＰに従ってコンテンツを受信するＳｉｎｋとして動作するコンテンツ伝送装置であって、
    ＡＫＥ手続きによりＳｏｕｒｃｅとの間で相互認証及び鍵交換を行なう認証手段と、
    前記Ｓｏｕｒｃｅから送信されるコンテンツ・データを、前記認証手段により交換した鍵を用いて受信処理するデータ受信手段と、
    前記データ受信手段により受信された部分のデータを順次有効化するデータ有効化手段を備え、
    Ｓｏｕｒｃｅからコンテンツを移動することを特徴とするコンテンツ伝送装置。
  12. 前記データ有効化手段により有効化されたデータの少なくとも一部を無効化するデータ無効化手段と、
    前記データ無効化手段により無効化したデータの移動の取り消しを前記Ｓｏｕｒｃｅに要求する移動取り消し要求手段と、
    をさらに備えることを特徴とする請求項１１に記載のコンテンツ伝送装置。
  13. データを受信したことを前記Ｓｏｕｒｃｅに示す所定の確約手続きを行なう確約手続き手段をさらに備え、
    前記データ有効化手段は、前記確約手続き手段による確約手続きを経て、該当するデータを有効化する、
    ことを特徴とする請求項１１に記載のコンテンツ伝送装置。
  14. 前記確約手続き手段は、有効化したデータの範囲を指定した受領確認コマンドを前記Ｓｏｕｒｃｅに送信する、
    ことを特徴とする請求項１３に記載のコンテンツ伝送装置。
  15. 前記確約手続き手段による確約手続きを行なって有効化した受信データの少なくとも一部を無効化するデータ無効化手段と、
    前記データ無効化手段により無効化したデータの移動の取り消しを前記Ｓｏｕｒｃｅに要求する移動取り消し要求手段と、
    をさらに備えることを特徴とする請求項１３に記載のコンテンツ伝送装置。
  16. ＤＴＣＰ Ｓｏｕｒｃｅとしてコンテンツを送信するコンテンツ伝送方法であって、
    ＡＫＥ手続きによりＳｉｎｋとの間で相互認証及び鍵交換を行なう認証ステップと、
    送信対象となるコンテンツのデータを、前記認証ステップにおいて交換した鍵を用いて前記Ｓｉｎｋへ暗号化伝送するデータ伝送ステップと、
    前記データ伝送ステップにおいて送信された部分のデータを順次無効化するデータ無効化ステップを備え、
    Ｓｉｎｋへコンテンツを移動することを特徴とするコンテンツ伝送方法。
  17. ＤＴＣＰ Ｓｉｎｋとしてコンテンツを受信するコンテンツ伝送装置であって、
    ＡＫＥ手続きによりＳｏｕｒｃｅとの間で相互認証及び鍵交換を行なう認証ステップと、
    前記Ｓｏｕｒｃｅから送信されるコンテンツ・データを、前記認証ステップにおいて交換した鍵を用いて受信処理するデータ受信ステップと、
    前記データ受信ステップにおいて受信された部分のデータを順次有効化するデータ有効化ステップを備え、
    Ｓｏｕｒｃｅからコンテンツを移動することを特徴とするコンテンツ伝送装置。
  18. ＤＴＣＰ Ｓｏｕｒｃｅとしてコンテンツを送信するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
    ＡＫＥ手続きによりＳｉｎｋとの間で相互認証及び鍵交換を行なう認証手順と、
    送信対象となるコンテンツのデータを、前記認証手順において交換した鍵を用いて前記Ｓｉｎｋへ暗号化伝送するデータ伝送手順と、
    前記データ伝送手順において送信された部分のデータを順次無効化するデータ無効化手順を実行させ、
    Ｓｉｎｋへコンテンツを移動することを特徴とするコンピュータ・プログラム。
  19. ＤＴＣＰ Ｓｉｎｋとしてコンテンツを受信するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
    ＡＫＥ手続きによりＳｏｕｒｃｅとの間で相互認証及び鍵交換を行なう認証手順と、
    前記Ｓｏｕｒｃｅから送信されるコンテンツ・データを、前記認証手順において交換した鍵を用いて受信処理するデータ受信手順と、
    前記データ受信手順において受信された部分のデータを順次有効化するデータ有効化手順を実行させ、
    Ｓｏｕｒｃｅからコンテンツを移動することを特徴とするコンピュータ・プログラム。
JP2006015886A 2006-01-25 2006-01-25 コンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラム Pending JP2007199890A (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
JP2006015886A JP2007199890A (ja) 2006-01-25 2006-01-25 コンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラム
EP07000881A EP1840781A1 (en) 2006-01-25 2007-01-17 System, device, method and computer program for transferring content
US11/656,386 US20070180224A1 (en) 2006-01-25 2007-01-23 System, device, method and computer program for transferring content
KR1020070006838A KR20070078065A (ko) 2006-01-25 2007-01-23 컨텐츠 전송 시스템, 컨텐츠 전송 장치 및 컨텐츠 전송방법, 및 컴퓨터 프로그램
CNA2007100027273A CN101009808A (zh) 2006-01-25 2007-01-25 内容传输系统、装置和方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006015886A JP2007199890A (ja) 2006-01-25 2006-01-25 コンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラム

Publications (1)

Publication Number Publication Date
JP2007199890A true JP2007199890A (ja) 2007-08-09

Family

ID=38323513

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006015886A Pending JP2007199890A (ja) 2006-01-25 2006-01-25 コンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラム

Country Status (5)

Country Link
US (1) US20070180224A1 (ja)
EP (1) EP1840781A1 (ja)
JP (1) JP2007199890A (ja)
KR (1) KR20070078065A (ja)
CN (1) CN101009808A (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008028497A (ja) * 2006-07-19 2008-02-07 Hitachi Ltd コンテンツ記録再生装置
JP2009265702A (ja) * 2008-04-21 2009-11-12 Sony Corp 記録システム、伝送装置、記録装置、及び記録制御方法、並びにプログラム
JP2013098753A (ja) * 2011-10-31 2013-05-20 Toshiba Corp コンテンツ送信装置及びコンテンツ受信装置

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4468425B2 (ja) * 2007-08-31 2010-05-26 株式会社東芝 送信装置、受信装置、コンテンツ送受信システム、コンテンツ送信方法、コンテンツ受信方法及びプログラム
JP2009194860A (ja) * 2008-02-18 2009-08-27 Toshiba Corp 送信装置、受信装置、コンテンツ送受信システム、コンテンツ送信方法、コンテンツ受信方法及びプログラム
US9253165B2 (en) 2010-07-20 2016-02-02 Verimatrix, Inc. Digital rights domain management for secure content distribution in a local network
JP5652036B2 (ja) 2010-07-29 2015-01-14 ソニー株式会社 通信システム、通信装置及び通信方法、並びにコンピューター・プログラム
US8565420B2 (en) * 2011-02-24 2013-10-22 Vixs Systems, Inc Source centric sanction server and methods for use therewith
CN105828174B (zh) * 2015-01-05 2019-11-05 中兴通讯股份有限公司 一种分享媒体内容的方法和装置
US10402251B2 (en) * 2015-07-24 2019-09-03 Nxp Usa, Inc. DMA controller for a data processing system, a data processing system and a method of operating a DMA controller
EP3883209B1 (en) * 2017-03-08 2023-06-28 Hitachi Energy Switzerland AG Method and devices for preserving relative timing and ordering of data packets in a network

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11506240A (ja) * 1996-03-11 1999-06-02 コニンクリジケ ピーティーティー ネーダーランド エヌ ブィー スマートカードのデータを安全に変更する方法
JP2003228522A (ja) * 2002-02-04 2003-08-15 Matsushita Electric Ind Co Ltd デジタルコンテンツ管理装置およびデジタルコンテンツ管理プログラム
JP2005202935A (ja) * 2003-12-15 2005-07-28 Ricoh Co Ltd 情報処理装置、画像形成装置、電子データの移動の取り消し方法
JP2005235337A (ja) * 2004-02-20 2005-09-02 Sony Corp 情報処理装置および方法、並びにプログラム
JP2005293731A (ja) * 2004-03-31 2005-10-20 Toshiba Corp コンテンツ記録方法、コンテンツ記録システム、及び記録再生装置

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002261748A (ja) * 2000-12-28 2002-09-13 Sony Corp データ送信装置及び方法並びにデータ記録装置及び方法
US6372974B1 (en) * 2001-01-16 2002-04-16 Intel Corporation Method and apparatus for sharing music content between devices
JP2004056776A (ja) * 2002-05-29 2004-02-19 Matsushita Electric Ind Co Ltd データ送信装置、データ受信装置、データ伝送システム及びデータ伝送方法
US20050204110A1 (en) * 2003-11-04 2005-09-15 Matsushita Electric Industrial Co., Ltd. Content move system
JP4264650B2 (ja) * 2004-04-07 2009-05-20 ソニー株式会社 コンテンツ伝送システム及びコンテンツ伝送方法、コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、並びにコンピュータ・プログラム
JP3814620B2 (ja) * 2004-10-15 2006-08-30 株式会社東芝 情報処理装置および情報処理方法
JP4518058B2 (ja) * 2006-01-11 2010-08-04 ソニー株式会社 コンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11506240A (ja) * 1996-03-11 1999-06-02 コニンクリジケ ピーティーティー ネーダーランド エヌ ブィー スマートカードのデータを安全に変更する方法
JP2003228522A (ja) * 2002-02-04 2003-08-15 Matsushita Electric Ind Co Ltd デジタルコンテンツ管理装置およびデジタルコンテンツ管理プログラム
JP2005202935A (ja) * 2003-12-15 2005-07-28 Ricoh Co Ltd 情報処理装置、画像形成装置、電子データの移動の取り消し方法
JP2005235337A (ja) * 2004-02-20 2005-09-02 Sony Corp 情報処理装置および方法、並びにプログラム
JP2005293731A (ja) * 2004-03-31 2005-10-20 Toshiba Corp コンテンツ記録方法、コンテンツ記録システム、及び記録再生装置

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008028497A (ja) * 2006-07-19 2008-02-07 Hitachi Ltd コンテンツ記録再生装置
JP4548393B2 (ja) * 2006-07-19 2010-09-22 株式会社日立製作所 コンテンツ記録再生装置
JP2009265702A (ja) * 2008-04-21 2009-11-12 Sony Corp 記録システム、伝送装置、記録装置、及び記録制御方法、並びにプログラム
JP4720847B2 (ja) * 2008-04-21 2011-07-13 ソニー株式会社 記録システム、伝送装置、記録装置、及び記録制御方法、並びにプログラム
US8625972B2 (en) 2008-04-21 2014-01-07 Sony Corporation Recording system, transmission apparatus, recording apparatus, recording control method, and recording medium
JP2013098753A (ja) * 2011-10-31 2013-05-20 Toshiba Corp コンテンツ送信装置及びコンテンツ受信装置

Also Published As

Publication number Publication date
KR20070078065A (ko) 2007-07-30
US20070180224A1 (en) 2007-08-02
CN101009808A (zh) 2007-08-01
EP1840781A1 (en) 2007-10-03

Similar Documents

Publication Publication Date Title
JP4518058B2 (ja) コンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラム
JP2007199890A (ja) コンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラム
JP4350714B2 (ja) 送信装置、受信装置及び送信方法
US20060165456A1 (en) Print system, print device and print instruction method
JP2007018121A (ja) 記憶装置及び情報処理端末
WO2011030520A1 (en) Communication system, communication apparatus, communication method, and computer program
JP4468425B2 (ja) 送信装置、受信装置、コンテンツ送受信システム、コンテンツ送信方法、コンテンツ受信方法及びプログラム
JP4910324B2 (ja) 情報処理装置及び情報処理方法、並びにコンピュータ・プログラム
US7688860B2 (en) Data transmission apparatus, data reception apparatus, data transmission method, and data reception method
JP4883199B2 (ja) コンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラム
JP4684775B2 (ja) 記憶装置
JP4439558B2 (ja) コンテンツ鍵生成装置、コンテンツ受信装置およびコンテンツ伝送方法
JP2009157848A (ja) データ送信装置、データ受信装置及びデータ送受信システム
JP6443516B2 (ja) 通信システム及び通信方法
JP4736603B2 (ja) 情報通信装置及び情報通信方法、並びにコンピュータ・プログラム
JP2007036952A (ja) 情報通信装置及び情報通信方法、並びにコンピュータ・プログラム

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100119

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100309

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20100406