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