コンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラム
【課題】伝送中に伝送路に障害が発生しても、コンテンツが分断されたり欠落が発生したりするのを防いで、Ｍｏｖｅを確実に行なう。
【解決手段】ＳｉｎｋはＭｏｖｅ中のコンテンツを順次記録媒体に記録するが、この記録コンテンツはＭｏｖｅの終了処理が成功するまでは利用できない状態におき、終了処理が確認されると、Ｓｉｎｋ側の記録コンテンツを有効化して利用できる状態にすると同時に、Ｓｏｕｒｃｅ側で元のコンテンツを消去若しくは利用不能にする処理を行なう。伝送路で障害が発生しても、ＤＴＣＰで規定されている条件を満たしながら、コンテンツのＭｏｖｅ処理を行なうことができる。
【解決手段】ＳｉｎｋはＭｏｖｅ中のコンテンツを順次記録媒体に記録するが、この記録コンテンツはＭｏｖｅの終了処理が成功するまでは利用できない状態におき、終了処理が確認されると、Ｓｉｎｋ側の記録コンテンツを有効化して利用できる状態にすると同時に、Ｓｏｕｒｃｅ側で元のコンテンツを消去若しくは利用不能にする処理を行なう。伝送路で障害が発生しても、ＤＴＣＰで規定されている条件を満たしながら、コンテンツのＭｏｖｅ処理を行なうことができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デジタル化されたＡＶデータなどのコンテンツを機器間で伝送するコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムに係り、特に、著作権保護やその他の目的でコピーが制限されたコンテンツを機器間で暗号化伝送するコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムに関する。
【０００２】
さらに詳しくは、本発明は、ＤＴＣＰに準拠した情報機器同士で暗号化コンテンツの伝送手続きを実行するコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムに係り、特に、ＤＴＣＰ ＭＯＶＥ機能を用いてＳｏｕｒｃｅからＳｉｎｋへコンテンツを移動するコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムに関する。
【背景技術】
【０００３】
情報技術の普及に伴い、ＡＶコンテンツのほとんどがデジタル化されており、ＣＤやＤＶＤなどのデジタル・コンテンツを記録再生するメディアが広く利用されている。また、最近では、ＨＤＤレコーダやＨＤＤ搭載ＤＶＤレコーダなど、コンテンツをデジタル記録する機器が家庭内にも浸透してきている。さらには、ネットワークを経由した映像や音楽などのコンテンツの流通・配信サービスが盛んとなり、ＣＤやＤＶＤなどのメディアの移動なしに、ネットワークを経由して遠隔端末間でコンテンツ配信が行なわれている。
【０００４】
しかしながら、デジタル化されたコンテンツはコピーや改竄などの不正な操作が比較的容易であることから、個人的又は家庭的なコンテンツの使用を許容しながら不正使用に対する防御が必要である。とりわけ、国内では２０１１年の地上アナログ放送停波に向けてアナログ放送受信機からデジタル放送受信機への置き換えが急速に進んでおり、家庭内のＡＶコンテンツのデジタル化に対してコンテンツの保護を技術的に実現することが必須と考えられている。
【０００５】
日本国内では、ＡＲＩＢ（Ａｓｓｏｃｉａｔｉｏｎ ｏｆ Ｒａｄｉｏ Ｉｎｄｕｓｔｒｉｅｓ ａｎｄ Ｂｕｓｉｎｅｓｓｅｓ：電波産業会）が中心となってデジタル放送に関する標準化が進められ、デジタル衛星放送、デジタル地上波放送、並びにデジタルＣＡＴＶにおいてＭＰＥＧ２システム（例えば、非特許文献１を参照のこと）を採用するとともに、「１世代のみコピー可」（コピーワンス）といったコピー制御機能の導入を義務付け、厳しいコンテンツ保護規定を設けている（例えば、非特許文献２、非特許文献３を参照のこと）。
【０００６】
また、デジタル伝送コンテンツの保護に関する業界標準的な技術として、ＤＴＬＡ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｌｉｃｅｎｓｉｎｇ Ａｄｍｉｎｉｓｔｒａｔｏｒ）が開発したＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）が挙げられ、コピー制御を始め著作権が保護された形でコンテンツを伝送させるための仕組みについて規定されている（例えば、非特許文献４を参照のこと）。
【０００７】
ＤＴＣＰでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決められている。その規定は、要約すれば、ＤＴＣＰ準拠機器はＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）など取り扱いが容易な圧縮コンテンツを非暗号の状態で機器外に送出しないことと、暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ：ＡＫＥ）アルゴリズムに従って行なうこと、並びにＡＫＥコマンドにより鍵交換を行なう機器の範囲を制限することなどを取り決めている。
【０００８】
コンテンツ提供元であるサーバ（Ｓｏｕｒｃｅ）とコンテンツ提供先であるクライアント（Ｓｉｎｋ）は、ＡＫＥコマンドの送受信により、認証手続きを経て鍵を共有化し、その鍵を用いて伝送路を暗号化してコンテンツの伝送を行なう。したがって、不正なクライアントは、サーバとの認証に成功しないと暗号鍵を取得できないから、コンテンツを享受することはできない。
【０００９】
ＤＴＣＰは、原初的には、ＩＥＥＥ１３９４などを伝送路に用いたホーム・ネットワーク上におけるデジタル・コンテンツの伝送について規定している。最近では、ＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）に代表されるように、家庭内においても、デジタル化されたＡＶコンテンツをＩＰネットワーク経由で流通させようという動きが本格的になっていることから、ＩＰネットワークに対応したＤＴＣＰ技術、すなわちＤＴＣＰ−ＩＰ（ＤＴＣＰ ｍａｐｐｉｎｇ ｔｏ ＩＰ）の開発が進められている。
【００１０】
ＤＴＣＰ−ＩＰは、ＤＴＣＰ技術をＩＰネットワークに移植した同様の技術であるが、伝送路にＩＰネットワークを使用すること、暗号化されたコンテンツの伝送にＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＲＴＰ（Ｒｅａｌ−Ｔｉｍｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）といった、ＩＰネットワーク上で実装されたコンテンツ伝送用プロトコルを使用するという点で、ＩＥＥＥ１３９４ベースで規定された本来のＤＴＣＰとは相違する。例えば、ＨＴＴＰの手続きに従ってコンテンツを伝送する場合、ＳｏｕｒｃｅがＨＴＴＰサーバとなり、ＳｉｎｋがＨＴＴＰクライアントとなって、ＨＴＴＰのためのＴＣＰ／ＩＰコネクションが作成され、暗号化コンテンツのダウンロード伝送が行なわれる（アップロード伝送を行なうときには、ＳｏｕｒｃｅがＨＴＴＰクライアントとなりＳｉｎｋがＨＴＴＰサーバとなる）。
【００１１】
ホーム・ネットワークがルータ経由でインターネットなどの外部のＩＰネットワークに接続されると、データの盗聴、改竄、コンテンツの不正コピーなどの危惧がある。また、ＳｏｕｒｃｅとＳｉｎｋ間の伝送路上にパーソナル・コンピュータなどで構成される不正なプロキシを設置することで、コンテンツの不正利用が容易に行なわれてしまう。このため、ＤＴＣＰ−ＩＰでは、ＡＫＥコマンドのＴＴＬ（Ｔｉｍｅ Ｔｏ Ｌｉｖｅ）すなわちＩＰルータのホップ回数に上限を設けることで、コンテンツの利用範囲を個人的又は家庭の範囲内に制限するなど、コンテンツを保護しながらネットワーク伝送するためのさらなる方法を規定している（例えば、非特許文献５を参照のこと）。
【００１２】
著作権保護に対応したコンテンツ伝送を行なう際、コンテンツ保護に関するコンテンツ属性を指定する必要がある。ＤＴＣＰ−ＩＰでは、コンテンツ伝送用のパケット（ＰＣＰ）のヘッダ部に記述するＥ−ＥＭＩ（Ｅｘｔｅｎｄｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｍｏｄｅ Ｉｎｄｉｃａｔｏｒ）と、Ｅｍｂｅｄｄｅｄ ＣＣＩ（Ｃｏｐｙ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）という２つのメカニズムにより、コンテンツに付随したコピー制御情報の伝送を実現している。
【００１３】
Ｅｍｂｅｄｄｅｄ ＣＣＩは、暗号化するコンテンツ・ストリームの一部として（すなわちパケットのペイロードに埋め込んで）伝送されるコピー制御情報である。コンテンツ・ストリームをタンパリングすると誤った暗号解読を行なうことになるので、Ｅｍｂｅｄｄｅｄ ＣＣＩの完全性を保証することができる。一方のＥ−ＥＭＩは、平文状態のヘッダ部に記載され、パケットのヘッダでコンテンツ・ストリームに関するコピー制御情報を示すことにより、容易にアクセスできると同時にセキュリティを実現する。Ｅ−ＥＭＩは、暗号モードを記述する４ビットのフィールドで構成され、その値はコピー制御情報の７種類に対応する。ビット値定義を下表に示しておく。但し、同表では未使用となっている９つのＥ−ＥＭＩ値は将来の拡張用に予備となっている。
【００１４】
【表１】
【００１５】
Ｓｏｕｒｃｅとして動作する機器は、コンテンツ・ストリームの特性に従って正しい暗号モードを選択し、これに基づいてＥ−ＥＭＩを設定する。これに対し、Ｓｉｎｋとして動作する機器は、コンテンツを伝送するパケットのヘッダ中のＥ−ＥＭＩで指定される正しい暗号解読モードを選択する。また、Ｓｉｎｋとして動作する機器は、Ｅ−ＥＭＩやＥｍｂｅｄｄｅｄ ＣＣＩで指定されている通りに、受信コンテンツを符号化して一旦蓄積し、続いてＳｏｕｒｃｅとして動作するときにはコピー制御情報に従って２次的なコンテンツ伝送動作を制御する。コピー制御の種類として、以下が挙げられる。
【００１６】
Ｃｏｐｙ Ｆｒｅｅ：著作権自体は留保するが、ＤＴＣＰを用いたコピー制御は行なわない。
Ｃｏｐｙ Ｎｅｖｅｒ：決してコンテンツを複製してはならない。
Ｃｏｐｙ Ｏｎｅ Ｇｅｎｅｒａｔｉｏｎ：１回だけ（Ｏｎｅ Ｇｅｎｅｒａｔｉｏｎ）だけコピーが許容される。
Ｎｏ Ｍｏｒｅ Ｃｏｐｉｅｓ：もはやコピーが許されない。
【００１７】
上記のうちＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓは、元はＣｏｐｙ Ｏｎｅ Ｇｅｎｅｒａｔｉｏｎに設定されたコンテンツを１回（ｆｉｒｓｔ ｇｅｎｅｒａｔｉｏｎ）だけコピーしたことによりコピーが許可されなくなった状態である。ＤＴＣＰ−ＩＰでは、Ｎｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして符号化されたコンテンツを伝送する手段として、ＭＯＶＥ機能が用意されている（例えば、非特許文献５、非特許文献６を参照のこと）。ネットワーク通信におけるＭＯＶＥは、機器間でデータを移動させることに相当し、基本的に移動元にデータを残さない。ＤＴＣＰ−ＩＰで言うＭＯＶＥ機能は、Ｓｉｎｋは受信したコンテンツをＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして符号化して扱うこと、及び、Ｓｏｕｒｃｅ側では伝送した後のコンテンツを消去又は利用不能にするという条件の下で、暗号化コンテンツをＳｏｕｒｃｅからＳｉｎｋへ伝送することを意味する。例えば、Ｃｏｐｙ Ｏｎｅ Ｇｅｎｅｒａｔｉｏｎのコンテンツが個人のビデオ録画機器（ＰＶＲ）などのＳｏｕｒｃｅにＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして符号化・記録されている場合、ＭＯＶＥ機能を用いることで、上記の条件を満たしながら、Ｃｏｐｙ Ｏｎｅ Ｇｅｎｅｒａｔｉｏｎの状態で符号化して単一のＳｉｎｋに伝送することができる。また、単一のＳｏｕｒｃｅと単一のＳｉｎｋ間でのみ、ＭＯＶＥが許容される。
【００１８】
現状の規定によれば、Ｅ−ＥＭＩでＣ１モード、又はＢ１モードのいずれかを使用してＭＯＶＥ伝送を行なうことができる。Ｓｉｎｋ側では、これらのモードで受け取ったコンテンツを、ＡＫＥ手続きで取得した鍵を用いて復号し、記録することができる。また、Ｓｏｕｒｃｅ側では、送信した瞬間にデータを無効化する必要がある。
【００１９】
ＭＯＶＥ機能によれば、有体物をある場所から別の場所へ移動するのと同様に、ＭＯＶＥしたコンテンツのエンティティ数が増えることはない。逆に言えば、伝送対象となるコンテンツが、ＳｏｕｒｃｅとＳｉｎｋに同時に存在しない（若しくは利用可能とならない）ことを保証する必要がある。したがって、ＳｏｕｒｃｅからＳｉｎｋへのコンテンツが複数のメッセージ転送手続きで構成される場合、上述したような、Ｓｏｕｒｃｅ側でコンテンツを消去又は利用不能にするという条件をすべてのメッセージ転送手続にわたって一貫して遵守しなければならない。このため、コンテンツ伝送方法としては、Ｓｏｕｒｃｅ側で送信後のデータを逐次的に利用不能にするとともに、Ｓｉｎｋ側で受信データを逐次的に利用可能にしていくという“ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ”を行なう必要がある。
【００２０】
例えば、コンテンツを複数の領域に分割してそれぞれを別のタイトル鍵で暗号化し、コンテンツ復号化の際に使用される時変鍵を抽出し、タイトル鍵領域の元のタイトル鍵を、抽出した当該時変鍵で順次上書きして前のコンテンツの復号化を不可能にすることによって、ＭＯＶＥ処理した元のコンテンツを安全且つ効率的に削除するコンテンツ管理装置について提案がなされている（例えば、特許文献１を参照のこと）。
【００２１】
ここで、ＳｏｕｒｃｅとＳｉｎｋ間で行なわれているＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥシーケンスがコンテンツ伝送中に障害の発生などにより中断したときに、Ｓｏｕｒｃｅ及びＳｉｎｋのそれぞれにコンテンツが分断されるという問題がある。コンテンツ全体の伝送が成功裏に終わればＳｏｕｒｃｅとＳｉｎｋ間でコンテンツの権利を無事に委譲することができるが、伝送処理の途中で障害が発生すると、伝送が済んだデータ部分はＳｉｎｋ側に存在するが、伝送する前のデータ部分はＳｏｕｒｃｅに残ってしまうため、コンテンツが分断される。ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥを処理中に生じ得る障害として、例えば、コネクション・エラーが発生する、一方の機器の電源が遮断される、コンテンツ格納用のメディアが抜き取られる（あるいはストレージが故障する）、Ｓｉｎｋ側でコンテンツを格納するストレージが満杯になるといった原因が挙げられ、コンテンツが分断される事態は決して希ではない。
【００２２】
１つのコンテンツの移動が複数のメッセージ転送手続きで行なわれる場合、Ｓｏｕｒｃｅがメッセージ転送を行なう毎にＳｉｎｋ側へ移動が終わったデータ部分を逐次的に消去すると、コンテンツ伝送が中断したときに、ＳｏｕｒｃｅとＳｉｎｋのいずれでもコンテンツを回復することができなくなってしまう。ＳｏｕｒｃｅからＳｉｎｋへのコンテンツ伝送が完了した後にＳｏｕｒｃｅ側のコンテンツを一括して消去又は利用不能にするようにすれば、ユーザはコンテンツを消失する心配はない。しかしながら、ＤＴＣＰ−ＩＰで規定されている、ＭＯＶＥ実行時の前提条件（前述）を一貫して遵守したことにならず、コンテンツの著作権保護を危険に晒しかねない。
【００２３】
例えば、汎用バス経由でコンテンツ伝送を行なうＳｏｕｒｃｅとＳｉｎｋの間にコンテンツ移動コントローラを設け、ＭＯＶＥ伝送に際してＳｏｕｒｃｅとＳｉｎｋの両方に重複して存在する再生可能なコンテンツの量が通常の再生時間にして１分を超えてはならないというＤＴＣＰ規格に基づいて、コンテンツ移動コントローラがＳｏｕｒｃｅ及びＳｉｎｋいずれかで不具合を検出すると１分以内にＭＯＶＥを中断し、Ｓｏｕｒｃｅに再生可能な状態で残っている部分で移動動作を再開することによってコンテンツの消失を避けるコンテンツ移動システムについて提案がなされている（例えば、特許文献を参照２のこと）。但し、この場合は、コンテンツ移動コントローラが介在しなければならないことから、装置コストが増大する。また、無線ＬＡＮ上で任意のＤＴＣＰ−ＩＰ機器がＳｏｕｒｃｅ並びにＳｉｎｋとしてそれぞれ動作し、これらＳｏｕｒｃｅ及びＳｉｎｋ間でコンテンツのＭＯＶＥ処理をアドホックに起動する場合には、コンテンツ移動コントローラの配置が困難となり、あるいはコンテンツ移動コントローラの介在が伝送シーケンスのボトルネックとなる。
【００２４】
また、コンテンツを受信完了したＳｉｎｋから返信されるコンテンツの記録状態情報を基にＳｏｕｒｃｅが送信済みのコンテンツを消去することで、Ｓｉｎｋがコンテンツを正常記録できない際のＳｏｕｒｃｅ側でのコンテンツの紛失を防ぐコンテンツ記録システムについて提案がなされている（例えば、特許文献３を参照のこと）。しかしながら、同システムでは、コンテンツ伝送が途切れたことによりコンテンツがＳｏｕｒｃｅとＳｉｎｋで分断してしまった事態については何ら考慮されていない。
【００２５】
また、著作権保護されたデータを他の記録装置に移動する際に、独自の複写暗号鍵で複写データを暗号化して保持しておき、万一移動時の障害などにより移動後のデータが不良の場合は、移動後のデータを無効とし同装置では、複写データから元のデータを復元することにより、著作権保護を行ないながら元のデータの消失を防止する、コンテンツ・データを取り扱う装置について提案がなされている（例えば、特許文献４を参照のこと）。しかしながら、同装置では、移動先にデータが記録されてから元のデータを消去するか、又は移動先でのデータの記録と並行して元のデータを消去するので、コンテンツ伝送が途切れたことによりコンテンツがＳｏｕｒｃｅとＳｉｎｋで分断してしまった事態について十分には考慮されていない。
【先行技術文献】
【特許文献】
【００２６】
【特許文献１】特開２００３−１０１５２９号公報
【特許文献２】特開２００５−１５８０５６号公報
【特許文献３】特開２００５−２９３７３１号公報
【特許文献４】特開２００５−２５０５６７号公報
【非特許文献】
【００２７】
【非特許文献１】ＩＳＯ／ＩＥＣ １３８１８−１ＧＥＮＥＲＩＣ ＣＯＤＩＮＧ ＯＦ ＭＯＶＩＮＧ ＰＩＣＴＵＲＥＳＡＮＤ ＡＳＳＯＣＩＡＴＥＤ ＡＵＤＩＯ：ＳＹＳＴＥＭＳ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｈ．２２２．０
【非特許文献２】ＡＲＩＢ ＴＲ−Ｂ１４ 地上デジタルテレビジョン放送運用規定
【非特許文献３】ＡＲＩＢ ＴＲ−Ｂ１５ ＢＳ／広帯域ＣＳデジタル放送運用規定
【非特許文献４】ＤＴＣＰ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｏｌｕｍｅ １ （Ｉｎｆｏｒｍａｔｉｏｎａｌ Ｖｅｒｓｉｏｎ） Ｒｅｖｉｓｉｏｎ １．４ （ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／）
【非特許文献５】ＤＴＣＰ Ｖｏｌｕｍｅ １ Ｓｕｐｐｌｅｍｅｎｔ Ｅ（Ｖ１ＳＥ） Ｍａｐｐｉｎｇ ＤＴＣＰ ｔｏ ＩＰ （Ｉｎｆｏｒｍａｔｉｏｎａｌ Ｖｅｒｓｉｏｎ） Ｒｅｖｉｓｉｏｎ １．１ （ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／）
【非特許文献６】ＤＩＧＩＴＡＬ ＴＲＡＮＳＭＩＳＳＩＯＮ ＰＲＯＴＥＣＴＩＯＮ ＬＩＣＥＮＳＥ ＡＧＲＥＥＭＥＮＴ， Ａｄｏｐｔｅｒ Ａｇｒｅｅｍｅｎｔ ――Ｍａｙ ２００５
【発明の概要】
【発明が解決しようとする課題】
【００２８】
本発明の目的は、ＤＴＣＰに準拠した情報機器同士で暗号化コンテンツの伝送手続きを好適に実行することができる、優れたコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することにある。
【００２９】
本発明のさらなる目的は、ＭＯＶＥ機能を用いてＳｏｕｒｃｅからＳｉｎｋへコンテンツを好適に移動することができる、優れたコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することにある。
【００３０】
本発明のさらなる目的は、コンテンツ伝送中に伝送路に障害が発生したりしても、コンテンツが分断されたり欠落が発生するのを防いで、コンテンツのＭＯＶＥ処理を確実に行なうことができる、優れたコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することにある。
【課題を解決するための手段】
【００３１】
本発明は、上記課題を参酌してなされたものであり、その第１の側面は、コンテンツを送信するＳｏｕｒｃｅとコンテンツを受信するＳｉｎｋ間でコンテンツを伝送するコンテンツ伝送システムであって、
ＳｏｕｒｃｅとＳｉｎｋ間で伝送対象となるコンテンツを指定するコンテンツ指定手段と、
ＳｏｕｒｃｅとＳｉｎｋ間で相互認証及び鍵交換を行なう認証手段と、
前記認証手段により交換した鍵を用いてＳｏｕｒｃｅからＳｉｎｋへ、前記コンテンツ指定手段により指定されたコンテンツを暗号化伝送するコンテンツ伝送手段と、
前記コンテンツ伝送手段により伝送処理が終了したことに応じて、Ｓｉｎｋ側のコンテンツを有効化するとともに、Ｓｏｕｒｃｅ側の元のコンテンツを無効化するコンテンツ伝送終了処理手段を備え、
ＳｏｕｒｃｅからＳｉｎｋへコンテンツを移動することを特徴とするコンテンツ伝送システムである。
【００３２】
但し、ここで言う「システム」とは、複数の装置（又は特定の機能を実現する機能モジュール）が論理的に集合した物のことを言い、各装置や機能モジュールが単一の筐体内にあるか否かは特に問わない（以下、同様）。
【００３３】
本発明は、ＩＰネットワーク上で著作権保護が必要となる情報コンテンツを伝送するコンテンツ伝送システムに関するものであり、具体的には、ＤＴＣＰ−ＩＰに準拠した情報通信機器の間で、相互認証及び鍵交換を経て共有した鍵を用いて暗号化コンテンツ伝送を安全に行なうコンテンツ伝送システムに関する。
【００３４】
ＤＴＣＰでは、コピー制御を始め著作権が保護された形でコンテンツを伝送する仕組みが規定されている。コンテンツ伝送の形態は、Ｓｏｕｒｃｅ上のコンテンツをＳｉｎｋにコピーする方法と、ＳｏｕｒｃｅからＳｉｎｋへコンテンツを移動してＳｏｕｒｃｅにコンテンツを残さない方法すなわちＭＯＶＥがある。ＤＴＣＰにおいては、Ｓｉｎｋは受信したコンテンツをＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして符号化して扱うこと、及び、Ｓｏｕｒｃｅ側では伝送した後のコンテンツを消去又は利用不能にすることを条件にして、Ｎｏ Ｍｏｒｅ Ｃｏｐｙとして符号化されたコンテンツを伝送するＭＯＶＥ機能が用意されている。
【００３５】
ＭＯＶＥ機能によれば、ユーザはコピーできないコンテンツを他の機器に移動して楽しむことができる。また、有体物をある場所から別の場所へ移動するのと同様に、ＭＯＶＥしたコンテンツのエンティティ数が増えることはないので、コンテンツ保護上の問題はない。
【００３６】
ＭＯＶＥ伝送シーケンス上ではＳｏｕｒｃｅ側でコンテンツを消去又は利用不能にするという条件を一貫して遵守しなければならない。このため、Ｓｏｕｒｃｅ側で送信後のデータを逐次的に利用不能にするとともに、Ｓｉｎｋ側で受信データを逐次的に利用可能にしていくという“ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ”を行なう必要がある。ところが、伝送路での障害が発生したことやその他の原因によりＭＯＶＥシーケンスが中断すると、コンテンツがＳｏｕｒｃｅとＳｉｎｋ間で分断されたり欠落が発生したりして、ユーザは本来適正に取得したコンテンツを消失してしまうことになる。
【００３７】
これに対し、本発明に係るコンテンツ伝送システムでは、ＳｉｎｋはＭＯＶＥ伝送中のコンテンツを順次記録媒体に記録するが、この記録コンテンツはＭＯＶＥ伝送の終了処理が成功するまでは利用できない状態にしておく。その後、コンテンツ伝送の終了処理の確認すなわちＣｏｍｍｉｔｍｅｎｔが行なわれると、Ｓｉｎｋ側の記録コンテンツを有効化して利用できる状態にすると同時に、Ｓｏｕｒｃｅ側で元のコンテンツを消去若しくは利用不能にする処理を行なう。これによって、ＭＯＶＥ伝送中にＳｏｕｒｃｅとＳｉｎｋでＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓコンテンツが二重に存在することはなく、且つ、伝送路で障害が発生するなどによりＭＯＶＥ伝送が途切れても、コンテンツが分断することはなく、Ｓｏｕｒｃｅから改めてコンテンツ伝送を再開することができる。
【００３８】
このようなコンテンツ伝送方法によるＭＯＶＥ伝送は、コンテンツ全体を一括してＳｏｕｒｃｅとＳｉｎｋ間で移動することと等価である。Ｓｏｕｒｃｅ側で送信後のデータを逐次的に利用不能にするとともにＳｉｎｋ側で受信データを逐次的に利用可能にしていくＩＮＣＲＥＭＥＮＴＥＬ ＭＯＶＥとは異なり、“ＢＬＯＣＫ ＭＯＶＥ”と呼ぶこともできる。ＢＬＯＣＫ ＭＯＶＥも、その伝送シーケンス上でＳｏｕｒｃｅとＳｉｎｋで同じコンテンツが二重に存在することはないから、ＤＴＣＰで規定されている条件を満たしたコンテンツのＭＯＶＥ処理であると言える。
【００３９】
また、Ｓｉｎｋは、ＭＯＶＥの終了処理が成功するまでは、記録したコンテンツを再生することはできないが、受信コンテンツを無効化した状態で記録する動作と並行して、受信コンテンツを再生出力（レンダリング）するように構成することも可能である。何故ならば、ＢＬＯＣＫ ＭＯＶＥがＤＴＣＰで既定する条件を満足するＭＯＶＥ処理であるとするならば、ＢＬＯＣＫ ＭＯＶＥに並行してコンテンツを復号して出力することは、コンテンツのストリーミングと等価でだからある。すなわち、復号コンテンツの出力とともにデータが失われるのでコンテンツのコピーには相当せず、ＳｏｕｒｃｅとＳｉｎｋの両方に重複して存在する再生可能なコンテンツがあってはならないというＤＴＣＰ規格に抵触しない。
【００４０】
この場合、Ｓｉｎｋ側では、受信したコンテンツを一旦復号化すると、Ｎｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして規定の符号化処理を施して、ハード・ディスク又はその他の記録媒体に保存するのに並行して、この復号コンテンツをそのままビデオ及びオーディオ信号に変換（レンダリング）して、ディスプレイなどのＡＶ出力部から映像並びに音響出力する。ユーザは、ＭＯＶＥ伝送中にそのコンテンツの内容を確認するとともに、リアルタイムでコンテンツ視聴を享受することができる。
【００４１】
また、ＭＯＶＥ処理手続の期間中、Ｓｏｕｒｃｅは、ＭＯＶＥ対象となるコンテンツを他のＳｉｎｋからＭＯＶＥ要求できないようにロックするようにする。何故ならば、複数のＳｉｎｋに対して同じコンテンツを多重してＭＯＶＥすると、コンテンツのエンティティ数が増える、すなわち事実上コピーすることになり、Ｎｏ Ｍｏｒｅ Ｃｏｐｉｅｓというコピー制御情報を破ることになるからである。
【００４２】
ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥはＤＴＣＰ−ＩＰで取り決められたＭＯＶＥ伝送により実装することが可能である。これに対し、ＢＬＯＣＫ ＭＯＶＥは本願の基礎出願である特願２００６−４１２９の出願当時（平成１８年１月１１日）のＤＴＣＰ仕様に含まれている訳ではない。そこで、ＢＬＯＣＫ ＭＯＶＥを行なう際には、前記認証手段は、ＳｏｕｒｃｅとＳｉｎｋ間で認証処理を行なう際に併せて、互いの機器がＢＬＯＣＫ ＭＯＶＥに対応しているかどうか、若しくはＭＯＶＥ伝送の詐称を防止することが好ましい。また、いずれか一方の機器がＢＬＯＣＫ ＭＯＶＥに対応していない場合には、従来のＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥにモードを切り替えてコンテンツのＭＯＶＥ処理を行なうようにしてもよい。
【００４３】
本発明に係るコンテンツ伝送システムでは、移動したいコンテンツを指定するために、ＵＰｎＰ（登録商標）で規定されているＣＤＳ（Ｃｏｎｔｅｎｔ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ）を利用して行なうことができる。また、それ以降に行なうＳｏｕｒｃｅとＳｉｎｋ間の認証手続き、コンテンツ伝送手続き、及びコンテンツ伝送終了処理手続きは、ＤＴＣＰ−ＩＰに則って各処理を行なうことができる。
【００４４】
例えば、ユーザがＳｉｎｋを操作して、コンテンツを提供するサーバとして動作するＳｏｕｒｃｅからコンテンツをダウンロードする形式でコンテンツの移動を行なうことができる。
【００４５】
この場合、Ｓｉｎｋにおいて、ＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｑｕｅｓｔに対するＳｏｕｒｃｅからのＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｓｐｏｎｓｅに含まれる情報に基づいて、移動したいコンテンツの認証及び鍵交換用のソケット情報を取得するとともに当該コンテンツがＳｏｕｒｃｅから移動可能か否かを確認することができる。
【００４６】
そして、Ｓｉｎｋは、ヘッダ内にコンテンツの移動であることを示すヘッダ情報を含めて、ＨＴＴＰ ＧＥＴメソッドを用いてＳｏｕｒｃｅから暗号化コンテンツを取得することができる。
【００４７】
あるいは、ユーザがＳｏｕｒｃｅを操作して、コンテンツを提供するサーバとして動作するＳｉｎｋに対してコンテンツをアップロードする形式でコンテンツの移動を行なうこともできる。
【００４８】
この場合、Ｓｏｕｒｃｅは、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｑｕｅｓｔを用いてＳｉｎｋに対して、当該コンテンツの移動場所の作成を要求することができる。
【００４９】
このとき、認証処理がＳｉｎｋから開始される都合上、Ｓｉｎｋ側から認証及び鍵交換用のＴＣＰコネクションを確立させるために、ＳｏｕｒｃｅはＳｉｎｋに対してソケット情報を通知する必要がある。例えば、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｑｕｅｓｔにソケット情報を伴うプロパティを含めることで、Ｓｉｎｋに対し認証及び鍵交換用のソケット情報を通知するようにしてもよい。あるいは、Ｓｏｕｒｃｅは、（コンテンツを含まない）ＨＴＴＰ ＰＯＳＴメソッドに含まれるヘッダ情報を用いてＳｉｎｋに対し認証及び鍵交換用のソケット情報を通知するようにしてもよい。
【００５０】
そして、Ｓｏｕｒｃｅは、ヘッダ内にコンテンツの移動であることを示すヘッダ情報を含めて、ＨＴＴＰ ＰＯＳＴメソッドを用いてＳｉｎｋへ暗号化コンテンツをアップロード伝送することができる。
【００５１】
また、ＳｏｕｒｃｅとＳｉｎｋ間では、移動するコンテンツ毎にＡＫＥ手続きによりコンテンツ移動専用の鍵の交換を行なうものとする。Ｓｏｕｒｃｅは、移動対象コンテンツを複数回伝送することになるようなＧＥＴリクエストをＳｉｎｋから受けたときには、これを拒否し、ＭＯＶＥ伝送処理を完結にすると同時にＭＯＶＥ伝送し終えたコンテンツを速やかに無効化することで、同じコンテンツを複数回移動する（すなわち、実質的にコピーする）ことのないようにする。
【００５２】
また、Ｓｏｕｒｃｅは、あるＳｉｎｋに対してコンテンツを移動中、他のＳｉｎｋからの当該コンテンツの移動要求を拒否することにより、複数のＳｉｎｋに同じコンテンツを移動する（すなわち、実質的にコピーする）ことのないようにする。
【００５３】
また、コンテンツのＭＯＶＥ伝送が終了し、さらにコンテンツ伝送終了処理が完了したことに応答して、Ｓｏｕｒｃｅ及びＳｉｎｋにおけるコンテンツ移動専用の交換鍵を消滅させる。逆に言えば、コンテンツの伝送終了処理が終了するまでは、ＡＫＥ手続きのために確立したＴＣＰコネクションを維持するようにする。
【００５４】
このような場合、コンテンツ伝送処理が終了するまでの間、ＡＫＥ手続きのために確立したＴＣＰコネクションを用いてコンテンツ伝送処理を取り消すことができる。コンテンツ伝送の取り消し処理は、Ｓｉｎｋ又はＳｏｕｒｃｅの少なくとも一方からの要求により起動する。コンテンツ伝送処理を取り消す際には、Ｓｉｎｋに伝送されたコンテンツを無効化するようにする。
【００５５】
また、コンテンツ伝送処理が終了するまでの間、ＳｉｎｋとＳｏｕｒｃｅ間の通信が途切れたときに、Ｓｉｎｋ又はＳｏｕｒｃｅの少なくとも一方からの要求によりコンテンツ伝送処理を中止することができる。中止する際のＳｏｕｒｃｅ並びにＳｉｎｋの振る舞いは、コンテンツ伝送を取り消す場合と同様である。
【００５６】
本発明に係るコンテンツ伝送システムでは、ＳｉｎｋとＳｏｕｒｃｅ間でコンテンツ伝送が無事に終了したことを確認すなわちＣｏｍｍｉｔｍｅｎｔをとるためのコンテンツ伝送終了処理を実施して、Ｓｉｎｋ側のコンテンツを有効化するとともに、Ｓｏｕｒｃｅ側の元のコンテンツを無効化することにより、コンテンツの移動が完了する。このコンテンツ伝送の終了処理では、まず、Ｓｉｎｋからコンテンツ受信終了を示す第１のコマンドが送信され、Ｓｏｕｒｃｅはこのコマンドに応答して、Ｓｏｕｒｃｅ側の元のコンテンツを中間的な無効状態にする。続いて、Ｓｏｕｒｃｅから第１のコマンドに対する第１のレスポンスが返信されると、Ｓｉｎｋはこのレスポンスに応答してＳｉｎｋ側に伝送されたコンテンツを有効化するとともに、Ｓｉｎｋ側で保持するコンテンツ移動専用の鍵を消滅させる。そして、Ｓｉｎｋからコンテンツ有効化を示す第２のコマンドが送信されると、Ｓｏｕｒｃｅはこのコマンドに応答して、Ｓｏｕｒｃｅ側の元のコンテンツを無効状態にするとともに、Ｓｏｕｒｃｅ側で保持するコンテンツ移動専用の鍵を消滅させる。
【００５７】
また、コンテンツ伝送手段によるＳｏｕｒｃｅからＳｉｎｋへのコンテンツ伝送が成功裏に終了したにも拘らず、一方の機器の電源遮断などによりコンテンツ伝送終了処理手段による処理が途切れてしまった場合のために、コンテンツ伝送システムは、途切れたコンテンツ伝送終了処理を再開するためのコンテンツ伝送終了処理再開手段をさらに備えていてもよい。この再開手段によって、コンテンツ伝送手続きが無駄にならずに済むとともに、ＳｉｎｋとＳｏｕｒｃｅの双方でコンテンツが無効になることを避けることができる。
【００５８】
このコンテンツ伝送終了処理再開手段は、ＳｏｕｒｃｅがＳｉｎｋからコンテンツ受信終了を示す第１のコマンドを受信したときに、Ｓｏｕｒｃｅがコンテンツ移動専用の交換鍵乃至第１のレスポンスで送る情報をまだ保持している場合には、Ｓｏｕｒｃｅ側の元のコンテンツを中間的な無効状態にし、ＳｏｕｒｃｅからＳｉｎｋに第１のコマンドに対する第１のレスポンスを返信させることで、コンテンツ伝送終了手続きを再開させることができる。
【００５９】
あるいは、コンテンツ伝送終了処理再開手段は、ＳｏｕｒｃｅがＳｉｎｋからコンテンツ受信終了を示す第２のコマンドを受信したときに、Ｓｏｕｒｃｅがコンテンツ移動専用の交換鍵乃至第１のレスポンスで送る情報をまだ保持している場合には、Ｓｏｕｒｃｅ側の元のコンテンツを無効状態にし、Ｓｏｕｒｃｅ側で保持するコンテンツ移動専用の鍵乃至第１のレスポンスで送る情報を消滅させるとともに、ＳｏｕｒｃｅからＳｉｎｋに第２のコマンドに対する第２のレスポンスを返信させることで、コンテンツ伝送終了手続きを再開させることができる。
【００６０】
あるいは、コンテンツ伝送終了処理再開手段は、Ｓｉｎｋがコンテンツ移動専用の交換鍵乃至第１のコマンドで送る情報をまだ保持している場合には、コンテンツ移動元となるＳｏｕｒｃｅとの接続を確立し、該当するコンテンツがＳｉｎｋ側で無効状態であればＳｏｕｒｃｅに対して第１のコマンドを送信させ、該当するコンテンツがＳｉｎｋ側で既に有効化されていれば第２のコマンドを送信させることで、コンテンツ伝送終了処理を再開させることができる。
【００６１】
このとき、Ｓｉｎｋ側から認証及び鍵交換用のＴＣＰコネクションを確立させるために、ＳｏｕｒｃｅはＳｉｎｋに対してソケット情報を通知する必要がある。コンテンツ伝送がダウンロード形式で行なわれた場合には、Ｓｉｎｋは、Ｓｏｕｒｃｅに対してＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｑｕｅｓｔを送信し、ＳｏｕｒｃｅからのＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｓｐｏｎｓｅに含まれる情報に基づいてソケット情報を取得して、コンテンツ伝送終了処理を再開させるためのＴＣＰコネクションを確立することができる。また、コンテンツ伝送がアップロード形式で行なわれた場合には、Ｓｏｕｒｃｅにおいて、（コンテンツを含まない）ＨＴＴＰ ＰＯＳＴメソッドのヘッダ情報を用いてＳｉｎｋにソケット情報を通知し、Ｓｉｎｋはこのソケット情報に基づいてコンテンツ伝送終了処理を再開させるためのＴＣＰコネクションを確立することができる。
【００６２】
また、ＤＴＣＰ−ＩＰでは、ＳｏｕｒｃｅとＳｉｎｋ間の伝送路上にパーソナル・コンピュータなどで構成される不正なプロキシを設置することで、通信内容の改ざんが容易に行なわれてしまう。とりわけ、認証手段によるＳｏｕｒｃｅとＳｉｎｋ間でＭＯＶＥ方法に関するケイパビリティの確認を行なってからＢＬＯＣＫ ＭＯＶＥを開始するようなシステムにおいては、ＳｏｕｒｃｅがＢＬＯＣＫ ＭＯＶＥに対応しているにも拘らず、プロキシはＳｏｕｒｃｅがＢＬＯＣＫ ＭＯＶＥに非対応であるとＳｉｎｋに偽り、ＳｉｎｋにＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥを行なわせることができる。この場合、Ｓｉｎｋ側では、Ｓｏｕｒｃｅからデータを受け取る度に逐次的に有効化していくとともに、コンテンツ伝送処理が終了した時点でプロキシがＳｏｕｒｃｅに対してコンテンツ伝送処理の取り消しを行なうことで、ＳｏｕｒｃｅとＳｉｎｋの双方で有効なコンテンツが存在するというＤＴＣＰ−ＩＰの規定に抵触する事態が生じる。
【００６３】
そこで、本発明に係るコンテンツ伝送システムは、ＳｏｕｒｃｅとＳｉｎｋ間で確認されたケイパビリティが詐称される、あるいはその他の手段によってＳｉｎｋ側のＭＯＶＥモードが偽装されることを防止する詐称防止手段をさらに備えておくことが好ましい。
【００６４】
この詐称防止手段は、例えば、前記認証手段で交換した鍵からコンテンツ暗号鍵を生成する方法をコンテンツ伝送方法毎に、すなわちＩＮＣＲＥＭＥＮＡＬ ＭＯＶＥとＢＬＯＣＫ ＭＯＶＥとで変えるようにする。このような場合、詐称によりＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥを行なうＳｉｎｋは、ＢＬＯＣＫ ＭＯＶＥを行なうＳｏｕｒｃｅとコンテンツ暗号鍵を共有できず、コンテンツが有効化されない。したがって、ＳｏｕｒｃｅとＳｉｎｋでコンテンツが二重に存在することはなくなる。
【００６５】
あるいは、詐称防止手段は、前記認証手段で交換した鍵をスクランブルする方法をコンテンツ伝送方法毎に、すなわちＩＮＣＲＥＭＥＮｔａｌ ＭＯＶＥとＢＬＯＣＫ ＭＯＶＥとで変えるようにしてもよい。このような場合、詐称によりＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥを行なうＳｉｎｋは、認証手段で交換した鍵をデスクランブルすることができず、正しいコンテンツ暗号鍵を得ることができない。したがって、ＳｏｕｒｃｅとＳｉｎｋでコンテンツが二重に存在することはなくなる。
【００６６】
あるいは、詐称防止手段は、相互認証及び鍵交換のためのチャレンジ・レスポンス手続きにおいて、ＳｉｎｋからＳｏｕｒｃｅへの電子署名で保護される通信メッセージの中にコンテンツ伝送方法に関する情報を含めるようにしてもよい。詐称によりＳｉｎｋがＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥを行なうようになった場合、Ｓｏｕｒｃｅ側ではケイパビリティの確認に従ってＢＬＯＣＫ ＭＯＶＥを行なおうとしても、チャレンジ・レスポンスの手続きで詐称されていることを検出することができる。Ｓｏｕｒｃｅは、ＭＯＶＥ伝送そのものを停止する、あるいはＳｉｎｋ側に合わせてＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥに切り替えるといった対策を採ることかできる。
【００６７】
また、本発明の第２の側面は、ＤＴＣＰ Ｓｏｕｒｃｅとしてコンテンツを送信するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
Ｓｉｎｋとの間で伝送対象となるコンテンツを指定するコンテンツ指定手順と、
ＡＫＥ手続きによりＳｉｎｋとの間で相互認証及び鍵交換を行なう認証手順と、
前記認証手順において交換した鍵を用いて、前記コンテンツ指定手順において指定されたコンテンツを、Ｓｉｎｋへ暗号化伝送するコンテンツ伝送手順と、
前記コンテンツ伝送手順においてコンテンツ伝送処理が終了したことに応じて、元のコンテンツを無効化するコンテンツ伝送終了処理手順を実行させ、
Ｓｉｎｋへコンテンツを移動することを特徴とするコンピュータ・プログラムである。
【００６８】
また、本発明の第３の側面は、ＤＴＣＰ Ｓｉｎｋとしてコンテンツを受信するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
Ｓｏｕｒｃｅとの間で伝送対象となるコンテンツを指定するコンテンツ指定手順と、
ＡＫＥ手続きによりＳｏｕｒｃｅとの間で相互認証及び鍵交換を行なう認証手順と、
前記認証手順において交換した鍵を用いて、前記コンテンツ指定手順において指定されたコンテンツを、Ｓｏｕｒｃｅから暗号化伝送するコンテンツ伝送手順と、
前記コンテンツ伝送手順においてコンテンツ伝送処理が終了したことに応じて、受信したコンテンツを有効化するコンテンツ伝送終了処理ステップを実行させ、
Ｓｏｕｒｃｅからコンテンツを移動することを特徴とするコンピュータ・プログラムである。
【００６９】
本発明の第２乃至第３の各側面に係るコンピュータ・プログラムは、コンピュータ・システム上で所定の処理を実現するようにコンピュータ可読形式で記述されたコンピュータ・プログラムを定義したものである。換言すれば、本発明の第２乃至第３の各側面に係るコンピュータ・プログラムをコンピュータ・システムにインストールすることによってコンピュータ・システム上では協働的作用が発揮され、それぞれ本発明の第１の側面に係るコンテンツ伝送システムにおけるＳｏｕｒｃｅ及びＳｉｎｋとして動作する。このようなコンテンツ伝送装置を起動してＤＴＣＰに基づくネットワークを構築することによって、本発明の第１の側面に係るコンテンツ伝送システムと同様の作用効果を得ることができる。
【発明の効果】
【００７０】
本発明によれば、ＤＴＣＰに準拠した情報機器同士で暗号化コンテンツの伝送手続きを好適に実行することができる、優れたコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することができる。
【００７１】
また、本発明によれば、ＭＯＶＥ機能を用いてＳｏｕｒｃｅからＳｉｎｋへコンテンツを好適に移動することができる、優れたコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することができる。
【００７２】
また、本発明によれば、コンテンツ伝送中に伝送路に障害が発生したりしても、コンテンツが分断されたり欠落が発生するのを防いで、コンテンツのＭＯＶＥ処理を確実に行なうことができる、優れたコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することができる。
【００７３】
本発明に係るコンテンツ伝送システムは、ＤＴＣＰで規定されている条件に則って、コンテンツ全体を一括してＳｏｕｒｃｅとＳｉｎｋ間で移動することと等価となるＢＬＯＣＫ ＭＯＶＥが可能である。
【００７４】
ＢＬＯＣＫ ＭＯＶＥは、コンテンツ伝送処理が終了したことに応じて、Ｓｉｎｋ側のコンテンツを有効化するとともに、Ｓｏｕｒｃｅ側の元のコンテンツを無効化するコンテンツ伝送終了処理によって実現する。いずれか一方の機器の電源が遮断するなどの原因で、コンテンツ伝送終了処理が中断する危険があるが、本発明に係るコンテンツ伝送システムによれば、コンテンツ伝送終了処理を再開して、ＭＯＶＥ処理を正しく終了させることができる。
【００７５】
また、ＢＬＯＣＫ ＭＯＶＥを行なう場合には、ＳｏｕｒｃｅとＳｉｎｋ間で不正なプロキシが介在して、例えばＳｉｎｋ側のケイパビリティを詐称することやその他の方法によりＭＯＶＥ伝送を偽装してコピー伝送が行なわれ、コンテンツが二重に存在する危険がある。これに対し、本発明に係るコンテンツ伝送システムによれば、詐称防止手段が、ＳｏｕｒｃｅとＳｉｎｋ間で確認されたケイパビリティを詐称してＳｉｎｋ側のＭＯＶＥモードが偽装されることを防止することができる。
【００７６】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
【図面の簡単な説明】
【００７７】
【図１】図１は、本発明の一実施形態に係る情報通信システムの構成例を模式的に示した図である。
【図２】図２は、図１に示した情報通信システムにおいて、クライアント（すなわち、Ｓｉｎｋ）として動作する情報通信装置の機能構成を示した図である。
【図３】図３は、図１に示した情報通信システムにおいて、サーバ（すなわち、Ｓｏｕｒｃｅ）として動作する情報通信装置の機能構成を示した図である。
【図４】図４は、ＳｏｕｒｃｅとＳｉｎｋの間でＡＫＥに基づく鍵交換手続き、及び鍵交換により共有した鍵を利用した暗号化コンテンツ伝送を行なう仕組みを説明するための図である
【図５】図５は、ＰＣＰのデータ構造を模式的に示した図である。
【図６】図６は、ＰＣＰペイロードにパディングする様子を示した図である。
【図７】図７は、コンテンツのＭＯＶＥ処理と受信コンテンツの再生処理を並行して行なうためのＳｉｎｋの構成例を示した図である。
【図８】図８は、ダウンロード形式でＳｏｕｒｃｅとＳｉｎｋ間のＭＯＶＥ伝送を行なう場合の動作シーケンスを示した図である。
【図９】図９は、ダウンロード形式でＳｏｕｒｃｅとＳｉｎｋ間のＭＯＶＥ伝送を行なう場合に、ＵＰｎＰ（登録商標）ベースでＣＤＳを用いてＳｉｎｋとＳｏｕｒｃｅ間でＭＯＶＥ対象となるコンテンツを選択するための動作シーケンスを示した図である。
【図１０】図１０は、ＭＯＶＥ用ＡＫＥ手続きの動作シーケンスを示した図である。
【図１１】図１１は、Ｓｏｕｒｃｅ及びＳｉｎｋ間でＭＯＶＥ終了処理手続きを実行する動作シーケンスを示した図である。
【図１２】図１２は、アップロード形式でＳｏｕｒｃｅとＳｉｎｋ間のＭＯＶＥ伝送を行なう場合の動作シーケンスを示した図である。
【図１３】図１３は、アップロード形式でＳｏｕｒｃｅとＳｉｎｋ間のＭＯＶＥ伝送を行なう場合に、ＵＰｎＰ（登録商標）ベースでＣＤＳを用いてＳｏｕｒｃｅからＳｉｎｋに対してコンテンツのアップロードを通知するための動作シーケンスを示した図である。
【図１４Ａ】図１４Ａは、ダウンロード形式でＳｏｕｒｃｅからＳｉｎｋへコンテンツをＭＯＶＥする場合のＳｏｕｒｃｅ及びＳｉｎｋがそれぞれ実行する処理動作を示したフローチャートである。
【図１４Ｂ】図１４Ｂは、ＨＴＴＰサーバとしてのＳｏｕｒｃｅからＨＴＴＰクライアントとしてのＳｉｎｋへコンテンツをダウンロードＭＯＶＥ伝送する場合のＳｏｕｒｃｅ及びＳｉｎｋがそれぞれ実行する処理動作を示したフローチャートである。
【図１５Ａ】図１５Ａは、アップロード形式でＳｏｕｒｃｅからＳｉｎｋへコンテンツをＭＯＶＥする場合のＳｏｕｒｃｅ及びＳｉｎｋがそれぞれ実行する処理動作を示したフローチャートである。
【図１５Ｂ】図１５Ｂは、アップロード形式でＳｏｕｒｃｅからＳｉｎｋへコンテンツをＭＯＶＥする場合のＳｏｕｒｃｅ及びＳｉｎｋがそれぞれ実行する処理動作を示したフローチャートである。
【図１６】図１６は、ケイパビリティの確認シーケンスを含んだＭＯＶＥ用ＡＫＥ手続きの動作シーケンス例を示した図である。
【図１７】図１７は、図１６中のケイパビリティ交換手続きの部分を詳細に示した図である。
【図１８】図１８は、図１１に示したダウンロードＭＯＶＥ伝送終了シーケンス上でＳｉｎｋ及びＳｏｕｒｃｅがそれぞれ実施する処理内容を具体的に示した図である。
【図１９】図１９は、ＨＴＴＰサーバとして動作するＳｏｕｒｃｅにおいて、中断したダウンロードＭＯＶＥ伝送終了処理を再開するための処理手順を示したフローチャートである。
【図２０】図２０は、ＨＴＴＰサーバとして動作するＳｏｕｒｃｅにおいて、中断したダウンロードＭＯＶＥ伝送終了処理を再開するための処理手順を示したフローチャートである。
【図２１】図２１は、ＨＴＴＰクライアントとして動作するＳｉｎｋにおいて、中断したダウンロードＭＯＶＥ伝送処理を再開するための処理手順を示したフローチャートである。
【図２２】図２２は、Ｓｉｎｋに対しＭＯＶＥモード詐称攻撃が掛けられた動作シーケンス例を示した図である。
【図２３】図２３は、ＭＯＶＥモード詐称攻撃に対策を採った動作シーケンス例を示した図である。
【図２４】図２４は、ＭＯＶＥモード詐称攻撃に対策を採った動作シーケンス例を示した図である。
【図２５】図２５は、ＭＯＶＥモード詐称攻撃に対策を採った動作シーケンス例を示した図である。
【図２６】図２６は、ＭＯＶＥモード詐称攻撃に対策を採った動作シーケンス例を示した図である。
【図２７】図２７は、ＭＯＶＥ用ＡＫＥ手続の他の動作シーケンス例を示した図である。
【図２８】図２８は、ＳｉｎｋがＨＴＴＰ ＧＥＴリクエストを用いてコンテンツを要求し、ＳｏｕｒｃｅがＨＴＴＰ ＧＥＴレスポンスを用いてコンテンツ伝送を行なう動作シーケンス例を示した図である。
【図２９】図２９は、ダウンロード形式のＭＯＶＥシーケンスにおいて、中断したＭＯＶＥ伝送終了処理を再開する際に、Ｓｉｎｋ及びＳｏｕｒｃｅ間でＴＣＰコネクションを確立するための処理手順を示したフローチャートである。
【図３０】図３０は、ＳｏｕｒｃｅとＳｉｎｋ間でアップロードＭＯＶＥ伝送を行なうための動作シーケンスを示した図（但し、ＳｏｕｒｃｅがＰＯＳＴリクエストを用いてソケット情報を通知する方法を用いる場合）である。
【図３１】図３１は、ＳｏｕｒｃｅとＳｉｎｋ間でアップロードＭＯＶＥ伝送を行なうための動作シーケンスを示した図（但し、Ｓｏｕｒｃｅから送信されたソケット情報を伴うＰＯＳＴリクエストに対し、ＡＫＥ手続が終了した後にＳｉｎｋがＰＯＳＴレスポンスを返し、その後にコンテンツをＰＯＳＴリクエストに対するメッセージ・ボディとして伝送する場合）である。
【図３２Ａ】図３２Ａは、ＳｏｕｒｃｅからＳｉｎｋへコンテンツをアップロードＭＯＶＥ伝送する場合のＳｏｕｒｃｅ及びＳｉｎｋがそれぞれ実行する処理動作を示したフローチャートである。
【図３２Ｂ】図３２Ｂは、ＳｏｕｒｃｅからＳｉｎｋへコンテンツをアップロードＭＯＶＥ伝送する場合のＳｏｕｒｃｅ及びＳｉｎｋがそれぞれ実行する処理動作を示したフローチャートである。
【図３３】図３３は、アップロード形式のＭＯＶＥシーケンスにおいて、中断したＭＯＶＥ伝送終了処理を再開する際に、Ｓｉｎｋ及びＳｏｕｒｃｅ間でＴＣＰコネクションを確立するための処理手順を示したフローチャートである。
【発明を実施するための最良の形態】
【００７８】
本発明は、著作権やその他の目的で保護が必要となる情報コンテンツを所定のコピー制御情報に従って暗号化伝送するコンテンツ伝送システムに関するものである。かかるシステムの具体例は、ＤＴＣＰ−ＩＰ機器の間で行なわれるＨＴＴＰプロトコルを利用したコンテンツ伝送である。以下、図面を参照しながら本発明の実施形態について詳解する。
【００７９】
Ａ．システム構成
ＤＴＣＰ−ＩＰに従ったコンテンツ伝送は、コンテンツを送信するＳｏｕｒｃｅと、コンテンツを受信して再生若しくは記録するＳｉｎｋで構成される。コンテンツの伝送方法としては、サーバとして動作するＳｏｕｒｃｅがクライアントとして動作するＳｉｎｋからの要求に応じてコンテンツを送信するダウンロード転送と、クライアントとして動作するＳｉｎｋからの要求によりサーバとして動作するＳｉｎｋへコンテンツを送信するアップロード転送が考えられる。
【００８０】
図１には、本発明の一実施形態に係る情報通信システムの構成例を模式的に示している。図示の例では、ＳｏｕｒｃｅとＳｉｎｋの各装置により、ＤＴＣＰ−ＩＰ ＡＫＥシステムが構築されている。ＤＴＣＰ−ＩＰに準拠した認証サーバであるＳｏｕｒｃｅとＤＴＣＰ−ＩＰに準拠した認証クライアントであるＳｉｎｋはネットワークを経由して接続されている。ここで言うネットワークには、Ｅｔｈｅｒｎｅｔ（登録商標）や、インターネット、その他のＩＰネットワークが含まれる。
【００８１】
図２及び図３には、図１に示したコンテンツ伝送システムにおいて、Ｓｉｎｋ及びＳｏｕｒｃｅとして動作するコンテンツ伝送装置の、特に認証及びコンテンツ伝送に着目した機能構成をそれぞれ模式的に示している。但し、図２及び図３では、サーバとして動作するＳｏｕｒｃｅがクライアントとして動作するＳｉｎｋからの要求に応じてコンテンツをダウンロード転送する場合の機能構成を示したものであり、アップロード転送時の機能構成については説明を省略する。ＳｉｎｋとＳｏｕｒｃｅは、インターネットなどのＴＣＰ／ＩＰネットワーク上でコネクションを確立することができ、このコネクションを利用して、認証手続きやコンテンツ伝送手続きを実行することができる。
【００８２】
図２に示すＳｉｎｋは、ＤＴＣＰ−ＩＰ認証ブロック１０と、ＤＴＣＰ−ＩＰコンテンツ受信ブロック２０と、コンテンツ再生／記録ブロック３０を備え、ＨＴＴＰクライアントとして動作し、ＨＴＴＰサーバとして動作するＳｏｕｒｃｅからダウンロード転送されるコンテンツを受信するようになっている。
【００８３】
ＤＴＣＰ−ＩＰ認証ブロック１０は、ＡＫＥブロック１１と、メッセージ・ダイジェスト生成ブロック１２と、コンテンツ復号ブロック１３で構成される。ＤＴＣＰ−ＩＰ認証ブロック１０は、より好ましくは耐タンパ性を備えている。
【００８４】
ＡＫＥブロック１１は、ＤＴＣＰ−ＩＰにおけるＡＫＥ機構（Ｓｉｎｋ側）を実現するブロックである。このＡＫＥブロック１１は後述のメッセージ・ダイジェスト生成ブロックから要求されたパラメータを渡す機能も備えている。ＡＫＥブロック１１は、コピーなど通常のコンテンツ伝送手続を行なう際のＡＫＥとは別に、ＭＯＶＥ専用のＡＫＥ手続を規定し、スクランブル方法などを異ならせることによってＭＯＶＥモードの詐称を防止するようにしてもよい。
【００８５】
メッセージ・ダイジェスト生成ブロック１２は、指定されたアルゴリズムに従い、パラメータのメッセージ・ダイジェストを生成するブロックである。メッセージ・ダイジェストを生成するアルゴリズムはあらかじめ用意されたアルゴリズムを指定することができる。あらかじめ用意されたアルゴリズムとして、例えばＭＤ５やＳＨＡ−１といった一方向性ハッシュ関数に関するアルゴリズムが挙げることができる（ＳＨＡ−１は、ＭＤ５と同様、ＭＤ４を改良したものに相当するが、１６０ビットのハッシュ値を生成するので、強度はＭＤシリーズを上回る）。
【００８６】
メッセージ・ダイジェスト生成ブロック１２は、ＤＴＣＰ−ＩＰ認証ブロック１０の外に公開してはならないＡＫＥブロック１１が保持するパラメータのメッセージ・ダイジェストを生成できるようにＡＫＥブロック１１と密に配置され、ＡＫＥブロック１１へパラメータを要求して取得することが可能であり、そのパラメータ若しくは外部から与えられたパラメータのメッセージ・ダイジェストを作成することができる。
【００８７】
コンテンツ復号ブロック１３は、ＡＫＥで交換した鍵Ｋxを用いてコンテンツの復号鍵Ｋcを算出し、Ｓｏｕｒｃｅから受信した暗号コンテンツをこの復号鍵Ｋcで復号するブロックである。ここで復号されたコンテンツは、コンテンツ再生／記録ブロックへ渡される。ＭＯＶＥ専用のＡＫＥ手続を規定した場合も同様である。
【００８８】
コンテンツ再生／記録ブロック３０は、コンテンツ復号ブロック１３から渡されたコンテンツを、再生モードの場合は再生を行ない、記録モードの場合はハード・ディスク又はその他の記録媒体（図示しない）に保存する。但し、コンテンツの記録動作は、コンテンツ伝送用のパケットＰＣＰ内に挿入されているコピー制御情報の規定に従う。
【００８９】
ＤＴＣＰ−ＩＰコンテンツ受信ブロック２０は、ＡＫＥを実施した後にＳｏｕｒｃｅとのコンテンツ伝送手続きを実行する処理モジュールである。図示の例では、ＤＴＣＰ−ＩＰコンテンツ受信ブロック２０はＨＴＴＰクライアント・ブロック２１を持ち、ＨＴＴＰクライアントとしてＨＴＴＰサーバ（すなわちＳｏｕｒｃｅ）へコンテンツを要求し、応答されたコンテンツをＨＴＴＰサーバから受信する。
【００９０】
ＨＴＴＰクライアント・ブロック２１は、ＨＴＴＰリクエスト管理ブロック２２とＨＴＴＰレスポンス管理ブロック２３に分かれる。さらに、ＨＴＴＰリクエスト管理ブロックは、ＨＴＴＰリクエスト送信ブロック２２ＡとＨＴＴＰリクエスト生成ブロック２２Ｂに分かれる。
【００９１】
ＨＴＴＰリクエスト生成ブロック２２Ｂは、送信するコンテンツ伝送要求（ＨＴＴＰリクエスト)を生成する。ここで生成されたＨＴＴＰリクエスト（例えば、ＨＴＴＰ ＧＥＴリクエスト）は、ＨＴＴＰリクエスト送信ブロック２２ＡによりＨＴＴＰサーバ（すなわちＳｏｕｒｃｅ）へ送信される。
【００９２】
ＨＴＴＰレスポンス管理ブロック２３は、ＨＴＴＰレスポンス受信ブロック２３ＡとＨＴＴＰレスポンス解釈ブロック２３Ｂに分かれる。サーバから返信されるＨＴＴＰレスポンスと暗号化されたコンテンツは、ＨＴＴＰレスポンス受信ブロック２３Ａで受信される。ここで受信したＨＴＴＰレスポンスは、ＨＴＴＰレスポンス解釈ブロック２３Ｂでチェックされる。ここでのチェックがＯＫの場合は受信した暗号化コンテンツをＤＴＣＰ−ＩＰ認証ブロック１０内のコンテンツ復号ブロック１３へ送る。また、このチェックがＮＧの場合は、エラー・レスポンスとしての処理を行なう。ＳｏｕｒｃｅからのＨＴＴＰレスポンスは１つ以上のＰＣＰからなる。
【００９３】
ＤＴＣＰ−ＩＰ認証ブロック１０とＤＴＣＰ−ＩＰコンテンツ受信ブロック２０は、サーバ機器との間で個別のＴＣＰ／ＩＰコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。
【００９４】
また、図３に示すＳｏｕｒｃｅは、ＤＴＣＰ−ＩＰ認証ブロック４０と、ＤＴＣＰ−ＩＰコンテンツ送信ブロック５０と、コンテンツ管理ブロック６０を備え、ＨＴＴＰサーバとして動作し、ＨＴＴＰクライアントとして動作するＳｉｎｋに対してコンテンツをダウンロード転送するようになっている。
【００９５】
ＤＴＣＰ−ＩＰ認証ブロック４０は、ＡＫＥブロック４１と、メッセージ・ダイジェスト生成ブロック４２と、コンテンツ暗号化ブロック４３で構成される。ＤＴＣＰ−ＩＰ認証ブロック４０は、より好ましくは耐タンパ性を備えている。
【００９６】
ＡＫＥブロック４１は、ＤＴＣＰ−ＩＰにおけるＡＫＥ機構（Ｓｏｕｒｃｅ側）を実現するブロックである。このブロックは、メッセージ・ダイジェスト生成ブロック４２から要求されたパラメータ（後述）を渡す機能も備えている。ＡＫＥブロック４１は認証したＳｉｎｋに関する情報をＡＫＥ認証した機器の数だけ保持し、それをクライアントからコンテンツが要求された際に認証済みのクライアントかどうかを判別するのに使用する。ＡＫＥブロック４１は、コピーなど通常のコンテンツ伝送手続を行なう際のＡＫＥとは別に、ＭＯＶＥ専用のＡＫＥ手続を規定し、スクランブル方法などを異ならせることによってＭＯＶＥモードの詐称を防止するようにしてもよい。
【００９７】
メッセージ・ダイジェスト生成ブロック４２は指定されたアルゴリズムに従い、パラメータのメッセージ・ダイジェストを生成するブロックである。メッセージ・ダイジェストを生成するアルゴリズムはあらかじめ用意されたアルゴリズムを指定できる。あらかじめ用意されたアルゴリズムとは、例えばＭＤ５やＳＨＡ−１といった一方向性ハッシュ関数に関するアルゴリズムが挙げられる（同上）。
【００９８】
メッセージ・ダイジェスト生成ブロック４２は、ＤＴＣＰ−ＩＰ認証ブロック４０の外に公開してはならないＡＫＥブロック４１が保持するパラメータのメッセージ・ダイジェストを生成できるようにＡＫＥブロック４１と密に配置され、ＡＫＥブロック４１へパラメータを要求して取得することが可能で、そのパラメータ若しくは外部から与えられたパラメータのメッセージ・ダイジェストを作成することができる。
【００９９】
コンテンツ暗号化ブロック４３は、ＤＴＣＰ−ＩＰコンテンツ送信ブロック５０の要求に応じてコンテンツ管理ブロック６０より読み出したコンテンツ・データを、ＡＫＥで交換した鍵Ｋxから生成したコンテンツ鍵Ｋcを用いて暗号化するブロックである。ここで暗号化されたコンテンツは、クライアントへ送信するために、ＤＴＣＰ−ＩＰコンテンツ送信ブロック５０へ渡される。
【０１００】
コンテンツ管理ブロック６０は、ＤＴＣＰ−ＩＰの機構を用いて保護されるべきコンテンツを管理するブロックである。コンテンツ暗号化ブロックの読み出しに応じて、コンテンツのデータを渡す。
【０１０１】
ＤＴＣＰ−ＩＰコンテンツ送信ブロック５０は、ＨＴＴＰサーバ・ブロック５１を持ち、ＨＴＴＰサーバとしてクライアント（すなわちＳｉｎｋ）からのリクエスト（例えば、ＨＴＴＰ ＧＥＴリクエスト）を受理し、要求に応じた処理を実行する。
【０１０２】
ＨＴＴＰサーバ・ブロック５１は、ＨＴＴＰリクエスト管理ブロック５２とＨＴＴＰレスポンス管理ブロック５３に分かれる。
【０１０３】
ＨＴＴＰリクエスト管理ブロック５２は、さらに、ＨＴＴＰリクエスト受信ブロック５２Ａと、ＨＴＴＰリクエスト解釈ブロック５２Ｂに分かれる。ＨＴＴＰリクエスト受信ブロック５２Ａは、クライアントからのＨＴＴＰリクエストを受信する。受信したＨＴＴＰリクエストはＨＴＴＰリクエスト解釈ブロック５２Ｂに送られ、チェックされる。ＨＴＴＰリクエスト解釈ブロック５２ＢにおけるチェックがＯＫの場合、ＨＴＴＰリクエストの情報をＤＴＣＰ−ＩＰ認証ブロック４０へ通知する。
【０１０４】
ＨＴＴＰレスポンス管理ブロック５３は、さらに、ＨＴＴＰレスポンス生成ブロック５３ＢとＨＴＴＰレスポンス送信ブロック５３Ａに分かれる。
【０１０５】
ＨＴＴＰレスポンス生成ブロック５３Ｂは、ＨＴＴＰリクエスト解釈ブロック５２ＢでのチェックがＯＫの場合、暗号化されたコンテンツを返すためのＨＴＴＰレスポンスを作成する。ＨＴＴＰレスポンスは１つ以上のＰＣＰからなる。一方、ＨＴＴＰリクエスト解釈ブロック５２ＢでのチェックがＮＧの場合、エラーを返すためのＨＴＴＰレスポンスを作成する。
【０１０６】
ＨＴＴＰレスポンス送信ブロック５３Ａは、作成されたＨＴＴＰレスポンスを、要求元のクライアントへ送信する。また、ＨＴＴＰリクエスト解釈ブロック５２ＢでのチェックがＯＫの場合には、ＨＴＴＰレスポンス・ヘッダに続けて、ＤＴＣＰ−ＩＰ認証ブロック４０内のコンテンツ暗号化ブロック４３で暗号化したコンテンツを送信する。
【０１０７】
ＤＴＣＰ−ＩＰ認証ブロック４０とＤＴＣＰ−ＩＰコンテンツ送信ブロック５０は、Ｓｉｎｋとの間で個別のＴＣＰ／ＩＰコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。
【０１０８】
なお、ＤＴＣＰ−Ｓｉｎｋ及びＤＴＣＰ−ＳｏｕｒｃｅのいずれもがＤＴＣＰ−ＩＰ認証ブロック内に持つメッセージ・ダイジェスト生成ブロックは、ＤＴＣＰ−ＩＰ自体で規定される機能モジュールではなく、また本発明の要旨には直接関連しない。
【０１０９】
Ｂ．ＨＴＴＰを利用したコンテンツ伝送
続いて、ＤＴＣＰ−ＩＰに従ったコンテンツの伝送手順について説明する。図４には、ＳｏｕｒｃｅとＳｉｎｋの間でＡＫＥに基づく鍵交換手続き、及び鍵交換により共有した鍵を利用した暗号化コンテンツ伝送を行なう仕組みを図解している。コンテンツ伝送の形態は、Ｓｏｕｒｃｅ上のコンテンツをＳｉｎｋにコピーする方法と、ＳｏｕｒｃｅからＳｉｎｋへコンテンツを移動してＳｏｕｒｃｅにコンテンツを残さない方法がある。この項では、前者のコピーによるコンテンツ伝送方法を前提にして説明する。後者のコンテンツ伝送方法はＭＯＶＥ機能によって実現されるが、ＭＯＶＥ伝送を行なう際のＡＫＥ手続の詳細については後述に譲る。
【０１１０】
ＳｏｕｒｃｅとＳｉｎｋは、まず１つのＴＣＰ／ＩＰコネクションを確立し、機器同士の認証を行なう。この認証を、ＤＴＣＰ認証若しくはＡＫＥ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ)と言う。ＤＴＣＰ準拠機器には、ＤＴＬＡ（前述）により発行された機器証明書が埋め込まれている。ＤＴＣＰ認証手続きでは、互いが正規のＤＴＣＰ準拠機器であることを確かめた後、認証鍵ＫauthをＳｏｕｒｃｅとＳｉｎｋで共有することができる。
【０１１１】
ＡＫＥ手続きが成功すると、Ｓｏｕｒｃｅはコンテンツ鍵Ｋcの種となる交換鍵Ｋxを生成し、認証鍵Ｋauthで暗号化してＳｉｎｋに送る。Ｓｏｕｒｃｅ及びＳｉｎｋそれぞれにおいて、交換鍵Ｋxに対して所定の演算処理を適用することによって、コンテンツ伝送時にコンテンツを暗号化するために使用されるコンテンツ鍵Ｋcが生成される。コンテンツ伝送方法に応じて交換鍵Ｋxからコンテンツ鍵Ｋcを生成するための計算式を変えるようにしてもよいが（例えば、コンテンツのコピー伝送とＭＯＶＥ伝送で計算式を切り替えるようにしてもよい）、この点の詳細については後述に譲る。
【０１１２】
そして、ＤＴＣＰ準拠の機器間でＡＫＥによる認証及び鍵交換手続きが済んだ後、ＳｉｎｋはＳｏｕｒｃｅ上のコンテンツを要求する。Ｓｏｕｒｃｅは、ＵＰｎＰ（登録商標）で規定されているＣＤＳ（Ｃｏｎｔｅｎｔ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ）などを通じてＳｉｎｋにＳｏｕｒｃｅ上のコンテンツへのアクセス先を示すコンテンツ場所をあらかじめ伝えることができる。Ｓｉｎｋがコンテンツを要求するとき、ＨＴＴＰやＲＴＰなどのプロトコルを利用することができる。
【０１１３】
図４に示す例では、ＨＴＴＰの手続きに従ってＨＴＴＰクライアントとしてのＳｉｎｋがＨＴＴＰサーバとしてのＳｏｕｒｃｅに対してコンテンツを要求するダウンロード形式となるコンテンツ伝送の場合、例えばＨＴＴＰ ＧＥＴメソッドを用いてコンテンツの伝送を開始する。また、図示しないが、ＨＴＴＰの手続きに従ってＨＴＴＰクライアントとしてのＳｏｕｒｃｅがＨＴＴＰサーバとしてのＳｉｎｋに対してコンテンツをプッシュするアップロード形式となるコンテンツ伝送の場合、例えばＨＴＴＰ ＰＯＳＴメソッドを用いてコンテンツの伝送を開始する。あるいは、ＲＴＰによる伝送を要求するとき、ＳｏｕｒｃｅがＲＴＰ Ｓｅｎｄｅｒとなり、ＳｉｎｋがＲＴＰ Ｒｅｃｅｉｖｅｒとなってコンテンツの伝送を開始する。
【０１１４】
ＨＴＴＰでコンテンツ伝送を行なう際、ＡＫＥ手続すなわちＤＴＣＰ認証のためのＴＣＰ／ＩＰコネクションとは別に、ＨＴＴＰのためのＴＣＰ／ＩＰコネクションがＨＴＴＰクライアントより作成される（すなわち、ＳｏｕｒｃｅとＳｉｎｋはそれぞれ、ＡＫＥ手続き用とコンテンツ伝送用に個別のソケット情報（ＩＰアドレスとポート番号の組み合わせ）を持つ）。そして、ＨＴＴＰクライアントとしてのＳｉｎｋは、通常のＨＴＴＰと全く同様の動作手順により、ＧＥＴメソッドを用いたＨＴＴＰリクエストによりＨＴＴＰサーバ上のコンテンツを要求する。これに対し、ＨＴＴＰサーバは、要求通りのコンテンツをＨＴＴＰレスポンスとして返す。
【０１１５】
ＨＴＴＰレスポンスとして伝送されるデータは、ＨＴＴＰサーバすなわちＳｏｕｒｃｅがＡＫＥ認証をした後に共有した鍵を用いてコンテンツを暗号化したデータとなっている。具体的には、Ｓｏｕｒｃｅは、乱数を用いてノンスＮcを生成して、交換鍵ＫxとノンスＮcと暗号モードを表すＥ−ＥＭＩを基にコンテンツ鍵Ｋcを生成する。そして、Ｓｉｎｋから要求されているコンテンツを、コンテンツ鍵Ｋcを用いて暗号化し、暗号化コンテンツからなるペイロードとノンスＮcとＥ−ＥＭＩを含んだヘッダからなるパケットであるＰＣＰ（Ｐｒｏｔｅｃｔｅｄ Ｃｏｎｔｅｎｔ Ｐａｃｋｅｔ）をＴＣＰストリーム上に乗せて送信する。そして、ＩＰプロトコルは、ＴＣＰストリームを所定の単位となるパケットの大きさに分割し、さらにヘッダ部を付加したＩＰパケットにし、指定されたＩＰアドレス宛てに届ける。
【０１１６】
Ｓｉｎｋ側では、Ｓｏｕｒｃｅからの各ＩＰパケットを受信すると、これをＴＣＰストリームに組み立てて、送信されたＰＣＰを取り出す。そして、ストリームからノンスＮcとＥ−ＥＭＩを取り出すと、これらと交換鍵Ｋxを用いてコンテンツ鍵Ｋcを算出し、暗号化コンテンツを復号することができる。そして、復号化した後の平文のコンテンツに対し再生若しくは記録などの処理を実施することができる。このようにしてＨＴＴＰプロトコルを利用したコンテンツ伝送が終了すると、例えばＳｉｎｋ側から、コンテンツ伝送に使用したＴＣＰコネクションを適宜切断する。
【０１１７】
図５には、ＤＴＣＰ−ＩＰにおいてコンテンツ伝送に用いられるパケットＰＣＰのデータ構造を模式的に示している。図示のように、ＰＣＰは、ノンスＮcを含んだヘッダと、暗号化コンテンツからなるペイロードで構成されるパケットである。ちなみに、ＨＴＴＰレスポンスは１つ以上のＰＣＰからなり、ＲＴＰペイロードは１つのＰＣＰからなる。
【０１１８】
ＰＣＰヘッダは平文であり、ノンスＮcが含まれている。また、ＰＣＰペイロードはノンスＮcで決まるコンテンツ鍵Ｋcで暗号化されたコンテンツ（但し、コピー制御情報として“ｃｏｐｙ−ｆｒｅｅ”が指定されているコンテンツは暗号化不要）で構成される。
【０１１９】
ＰＣＰペイロードは、データ長すなわちｐｒｏｔｅｃｔｅｄ＿ｃｏｎｔｅｎｔ＿ｌｅｎｇｔｈの値が常に１６バイトの倍数になるように規定されている。ｐｒｏｔｅｃｔｅｄ＿ｃｏｎｔｅｎｔ＿ｌｅｎｇｔｈの値が１６の整数倍でないときは、必要に応じて暗号化前にパディング（ｐａｄｄｉｎｇ）が行なわれ、コンテンツに１〜１５バイトのパディングが付く。図６には、ＰＣＰをパディングする様子を示している。
【０１２０】
ここで、長大なＴＣＰストリーム全体に亘り同じ暗号鍵を使用し続けると、鍵が解読される危険は高くなる。このため、ＤＴＣＰ−ＩＰでは、Ｓｏｕｒｃｅは１２８ＭＢ毎にノンスＮcすなわちコンテンツ鍵Ｋcを更新する（１ずつインクリメントする）よう取り決められ、コンテンツの安全化が図られている。定期的にノンスＮcを更新する時点でも、ＰＣＰはパディングされる（コンテンツ鍵Ｋcを更新しなくても複数のＰＣＰにｐａｄｄｉｎｇすることは可能）。
【０１２１】
また、ＤＴＣＰ−ＩＰでは、ノンスＮcの更新に伴い、コンテンツ鍵確認手続を起動するようになっている。コンテンツ鍵確認手続では、Ｓｉｎｋは、コンテンツ伝送用のＴＣＰコネクションとは別に、コンテンツ鍵の確認用のＴＣＰコネクションをさらに確立し、Ｓｏｕｒｃｅに対しコンテンツ鍵確認のための手続きを行なう。Ｓｉｎｋは、コンテンツ鍵の確認が必要になると、適宜このＴＣＰコネクションを確立する。例えば、ＤＴＣＰ−ＩＰ Ｖｏｌｕｍｅ １ Ｓｕｐｐｌｅｍｅｎｔ Ｅ．８．６には、コンテンツ鍵の確認手続きとして“Ｃｏｎｔｅｎｔ Ｋｅｙ Ｃｏｎｆｉｒｍａｔｉｏｎ”を規定している。これによれば、Ｓｉｎｋは、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦ ｓｕｂｆｕｎｃｔｉｏｎを用いて、現在のノンスＮcに関連付けられたコンテンツ鍵の確認を行なう。
【０１２２】
Ｃ．コンテンツのＭＯＶＥ伝送
ＤＴＣＰ−ＩＰでは、Ｓｏｕｒｃｅ側でＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして符号化されているコンテンツをＳｉｎｋで利用できるようにする手段として、ＭＯＶＥ機能が用意されている。
【０１２３】
ネットワーク通信におけるＭＯＶＥは、機器間でデータを移動させることに相当し、移動先の機器にデータが移動した後は基本的に移動元の機器にはデータを残さない。ＤＴＣＰ−ＩＰで言うＭＯＶＥ機能は、Ｓｉｎｋは受信したコンテンツをＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして符号化して扱うこと、及び、Ｓｏｕｒｃｅ側では伝送した後のコンテンツを消去又は利用不能にするという条件の下で、暗号化コンテンツをＳｏｕｒｃｅからＳｉｎｋへ伝送することを意味し、単一のＳｏｕｒｃｅと単一のＳｉｎｋ間でのみＭＯＶＥが許容される。
【０１２４】
以下では、ＤＴＣＰ−ＩＰに準拠する機器同士の相互運用を実現するためのＭＯＶＥシーケンスについて説明する。最低限の相互運用を確保するには、単一のＨＴＴＰ ＧＥＴメソッド又はＰＯＳＴメソッドを用いたＭＯＶＥ伝送が推奨されるが、勿論、他のシーケンスを用いた実装が禁止されている訳ではない。
【０１２５】
ＤＴＣＰ−ＩＰにおけるＭＯＶＥシーケンスでは、Ｓｏｕｒｃｅ側でコンテンツを消去又は利用不能にするという条件を一貫して遵守することが課されている。このため、Ｓｏｕｒｃｅ側で送信後のデータを逐次的に利用不能にするとともに、Ｓｉｎｋ側で受信データを逐次的に利用可能にしていくという“ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ”を行なう必要がある。ところが、伝送路での障害が発生したことやその他の原因によりＭＯＶＥシーケンスが中断すると、コンテンツがＳｏｕｒｃｅとＳｉｎｋ間で分断されたり欠落が発生したりしてしまう。そして、ＭＯＶＥシーケンスが途切れた結果として、ユーザは、そもそも適正に取得したコンテンツを消失してしまうことになる。
【０１２６】
そこで、本実施形態に係るコンテンツ伝送システムでは、Ｓｉｎｋは、ＭＯＶＥ伝送中のコンテンツを順次記録媒体に記録するが、ＭＯＶＥの終了処理が成功するまでは順次記録したコンテンツを利用できない状態に保つようにした。そして、ＭＯＶＥ伝送の終了処理の確認すなわちＣｏｍｍｉｔｍｅｎｔが行なわれると、Ｓｉｎｋ側の記録コンテンツを有効化して利用できる状態にすると同時に、Ｓｏｕｒｃｅ側で元のコンテンツを消去若しくは利用不能にする処理を行なう。このような伝送手順によれば、ＭＯＶＥ伝送中にＳｏｕｒｃｅとＳｉｎｋでＮｏ Ｍｏｒｅ Ｃｏｐｙコンテンツが二重に存在することはない。且つ、伝送路で障害が発生するなどによりＭＯＶＥ伝送処理が途切れても、コンテンツが分断することはなく、Ｓｉｎｋ側から改めてコンテンツ伝送を再開（ｒｅｓｕｍｅ）することができる。
【０１２７】
このようなコンテンツのＭＯＶＥ伝送は、コンテンツ全体を一括してＳｏｕｒｃｅとＳｉｎｋ間で移動することと等価である。Ｓｏｕｒｃｅ側で送信後のデータを逐次的に利用不能にするとともにＳｉｎｋ側で受信データを逐次的に利用可能にしていくＩＮＣＲＥＭＥＮＴＥＬ ＭＯＶＥとは異なり、“ＢＬＯＣＫ ＭＯＶＥ”と呼ぶこともできる。ＢＬＯＣＫ ＭＯＶＥも、ＳｏｕｒｃｅとＳｉｎｋで同じコンテンツが二重に存在することはないから、ＤＴＣＰで規定されている条件を満たしたコンテンツのＭＯＶＥ処理であると言える。
【０１２８】
なお、Ｓｉｎｋは、ＭＯＶＥ伝送の終了処理が成功するまでは、記録したコンテンツを再生することはできないが、受信コンテンツを無効化した状態で記録する動作と並行して、受信コンテンツを再生出力（レンダリング）するように構成することも可能である。何故ならば、ＢＬＯＣＫ ＭＯＶＥがＤＴＣＰで既定する条件を満足するＭＯＶＥ処理であるとするならば、これに並行したレンダリング処理は、ＭＯＶＥ伝送用のＴＣＰコネクションと並行してコンテンツ・ストリーミング伝送用のＴＣＰコネクションを確立して、ストリーミング・データを再生出力することと等価であるからである。ＢＬＯＣＫ ＭＯＶＥに並行してレンダリング処理を行なう場合、ＴＣＰコネクションは１本で済むから通信路を節約することができる。また、ＳｏｕｒｃｅやＳｉｎｋの機器にとってはＭＯＶＥ伝送とレンダリングの双方の処理を単一のコンテンツ伝送処理で済ますことができるから負荷を軽減することになる。
【０１２９】
コンテンツのＭＯＶＥ処理と受信コンテンツの再生処理を並行して行なうためには、図２に示したＳｉｎｋ内のコンテンツ再生／記録ブロック３０を、コンテンツ再生ブロック３１とコンテンツ記録ブロック３２という２つの独立したモジュールとして構成すればよい。図７には、この場合の機能ブロック図を示している。
【０１３０】
コンテンツ復号ブロック１３では、ＡＫＥで交換した交換鍵Ｋxから算出されるコンテンツの復号鍵Ｋcを用いて、Ｓｏｕｒｃｅから受信した暗号化コンテンツを復号すると、これをコンテンツ再生ブロック３１とコンテンツ記録ブロック３２の各々に供給する。
【０１３１】
コンテンツ記録ブロック３２では、コンテンツをＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして規定の符号化処理を施して、まず無効化された状態でハード・ディスク又はその他の記録媒体（図示しない）に保存する。コンテンツ記録ブロック３２により保存された符号化コンテンツは、ＭＯＶＥ伝送全体が完了するまでは有効化されないので、記録媒体から読み出して復号して利用（例えばコンテンツ再生ブロックで再生）することはできない。また、コンテンツ記録ブロック３２を、コンテンツ復号ブロック１３と同様に、耐タンパ性のあるＤＴＣＰ−ＩＰ認証ブロック１０内に配置することで、コンテンツ復号ブロック１３とコンテンツ記録ブロック３２間での復号コンテンツの漏洩の問題はなくなる。
【０１３２】
一方、コンテンツ再生ブロック３１では、コンテンツ復号ブロック１３から供給されるコンテンツを、そのままビデオ及びオーディオ信号に変換（レンダリング）して、ディスプレイなどのＡＶ出力部から映像並びに音響出力する。このような復号コンテンツの出力は、出力とともにデータが失われるのでコンテンツのコピーには相当せず、ＳｏｕｒｃｅとＳｉｎｋの両方に重複して存在する再生可能なコンテンツがあってはならないというＤＴＣＰ規格に抵触しない。
【０１３３】
このようにＭＯＶＥ処理と並行して受信コンテンツの再生処理を実行することにより、ユーザは、ＭＯＶＥ伝送中にそのコンテンツの内容を確認するとともに、リアルタイムでコンテンツ視聴を享受することができる。
【０１３４】
ここで、ＳｏｕｒｃｅとＳｉｎｋ間のコンテンツ伝送が、コンテンツ再生ブロックにおける再生の実時間より高速に行なわれる場合には、コンテンツ再生ブロック３１はＡＶ出力用バッファ３３をローカルに備えていてもよい。上述したような並列処理を行なう際、コンテンツ復号ブロック１３から直接供給されるコンテンツをこのＡＶ出力用バッファ３３に蓄積し、ＦＩＦＯ形式で再生出力するようにすれば、コンテンツ再生ブロック３１を通じたコンテンツの実時間再生を行なうことができる。ＡＶ出力用バッファ３３の実装方法としては、コンテンツ再生ブロック３１専用のバッファ・メモリを設ける以外に、コンテンツ記録ブロック３２が持つハード・ディスクなどの記録媒体（図示しない）とＡＶ出力用バッファ３３とを統合し、ＡＶ出力用のコンテンツと記録用のコンテンツを一元化することも考えられる。
【０１３５】
本発明者らは、ＳｏｕｒｃｅとＳｉｎｋ間のＭＯＶＥ伝送を、ダウンロードとアップロードに大別して扱うことにしている。ここで言うダウンロードとは、Ｓｉｎｋを操作するユーザがＳｏｕｒｃｅからコンテンツをプル配信することを意味し、例えばＳｏｕｒｃｅがＨＴＴＰサーバとして動作するとともにＳｉｎｋがＨＴＴＰクライアントとして動作し、ＨＴＴＰ ＧＥＴメソッドを用いてＭＯＶＥシーケンスを実装することができる。また、アップロードとは、Ｓｏｕｒｃｅを操作するユーザがＳｉｎｋに対してコンテンツをプッシュ配信することを意味し、例えばＳｏｕｒｃｅがＨＴＴＰクライアントとして動作するとともにＳｉｎｋがＨＴＴＰサーバとして動作し、ＨＴＴＰ ＰＯＳＴメソッドを用いてＭＯＶＥシーケンスを実装することができる。最低限の相互運用を確保するには、単一のＨＴＴＰ ＧＥＴメソッド又はＰＯＳＴメソッドを用いたＭＯＶＥ伝送が推奨されるが、勿論、他のシーケンスを用いた実装が禁止されている訳ではない。
【０１３６】
従来のＤＴＣＰ−ＩＰではＳｉｎｋからコンテンツ伝送のトリガが発生するダウンロード形式でコピー伝送が行なわれるのが一般的であるが（例えば、図４を参照のこと）、以下ではダウンロード伝送とアップロード伝送それぞれの場合についてのＢＬＯＣＫ ＭＯＶＥ伝送シーケンスについて説明する。
【０１３７】
Ｃ−１．ダウンロード形式のＢＬＯＣＫ ＭＯＶＥ
図８には、ダウンロード形式でＳｏｕｒｃｅとＳｉｎｋ間のＢＬＯＣＫ ＭＯＶＥ伝送を行なう場合の動作シーケンスを示している。図示の通り、この場合のＭＯＶＥ伝送は、Ｓｏｕｒｃｅ及びコンテンツ選択、ＭＯＶＥ用ＡＫＥ手続き、コンテンツ移動（ＭＯＶＥ）手続き、ＭＯＶＥ終了処理手続きという４段階のフェーズで構成される。このうち、ＭＯＶＥ用ＡＫＥ手続き、コンテンツ移動（ＭＯＶＥ）手続き、ＭＯＶＥ終了処理手続きは、ＤＴＣＰ上で規定される手順に従って実行される。
【０１３８】
Ｓｏｕｒｃｅ及びコンテンツ選択のフェーズは、例えばＵＰｎＰ（登録商標）ベースで行なうことができ、この場合、ＳｉｎｋはＣＤＳ（ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ)を利用してコンテンツ情報を取得することができる。ＣＤＳは、ＵＰｎＰ（登録商標）メディア・サーバの主要なサービスの１つである。通常、ＳｉｎｋはＣＤＳを用いてコンテンツの閲覧や検索、コンテンツのメタデータの編集などを行なう。図９には、この場合のＳｏｕｒｃｅとＳｉｎｋ間の動作シーケンスを示している。
【０１３９】
まず、Ｓｉｎｋは、ＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｑｕｅｓｔを発行し、ＳｏｕｒｃｅからのＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｓｐｏｎｓｅによってコンテンツ一覧情報（ｃｏｎｔｅｎｔ ｌｉｓｔ ｉｎｆｏｒｍａｔｉｏｎ）を引き取ることができる。同図に示すように、このレスポンス内では、コンテンツはｉｔｅｍ ＩＤとｐａｒｅｎｔＩＤで識別され、コンテンツ毎に、コンテンツのタイトル、コンテンツのＵＰｎＰ（登録商標）クラス、ＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｑｕｅｓｔに対するレスポンス情報が記載されている。そして、レスポンス属性情報（ｒｅｓ ｐｒｏｔｏｃｏｌＩｎｆｏ ｐｒｏｐｅｒｔｙ）の第３フィールドにコンテンツ毎のソケット情報（ＤＴＣＰ Ｓｏｃｋｅｔ Ｉｎｆｏ）が記載されるとともに、別のレスポンス属性情報（ｒｅｓ＠ａｌｌｗｅｄＵｓｅ）でコンテンツがＭＯＶＥ伝送可能かどうかを示すＭｏｖａｂｌｅ情報が記載され、これらに続いてコンテンツの保管場所を示すＵＲＬが含まれている。なお、Ｍｏｖａｂｌｅ情報の記載手段はこれに限定されることはなく、例えばＤＴＣＰでレスポンス属性情報を定義してこれを用いることも考えられる。可能なＭＯＶＥ方法としてＢＬＯＣＫ ＭＯＶＥとＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥを個別に表現することも考えられる。
【０１４０】
図９に示す例では、Ｓｏｕｒｃｅは、ｒｅｓのｐｒｏｔｏｃｏｌＩｎｆｏアトリビュートの３番目のフィールドにソケット情報としての文字列“ＤＴＣＰ１ＨＯＳＴ＝（ｈｏｓｔ）；ＤＴＣＰ１ＰＯＲＴ＝（ｐｏｒｔ）”を記載するとともに、ａｌｌｏｗｅｄＵｓｅアトリビュートには当該コンテンツがＤＴＣＰ−ＩＰによりＭＯＶＥ可能であることを示す文字列“ＭＯＶＥ：１”を記載している。したがって、Ｓｉｎｋは、図示のレスポンス中から、ユーザが選択したコンテンツに関するｒｅｓタグ内のｐｒｏｔｏｃｏｌＩｎｆｏ並びにａｌｌｏｗｅｄＵｓｅの各アトリビュートの値を読み出すことで、コンテンツ毎のソケット情報と、コンテンツがＭＯＶＥ伝送可能かどうかを取得することができる。
【０１４１】
なお、ｒｅｓ＠ａｌｌｏｗｅｄＵｓｅはＤＴＣＰ規格で規定されているものではなく、“ＭＯＶＥ：１”の運用方法も詳細に定義されていないため、将来の定義内容にとっては不適切なものになるおそれがある。そこで、ｒｅｓ＠ａｌｌｏｗｅｄＵｓｅに代えて、「ＤＴＣＰ．ＣＯＭ＿ＦＬＡＧＳ ｐａｒａｍ」というパラメータをｒｅｓ＠ｐｒｏｔｏｃｏｌＩｎｆｏの第４フィールドに設けて、コンテンツのＭＯＶＥ伝送の可否を示すことが考えられる。ＤＴＣＰ．ＣＯＭ＿ＦＬＡＧＳ ｐａｒａｍは３２ビット長のフィールドであり、ビット定義は以下の通りとする。ビット３０に１が記載されているときには、ビット３１にも１が記載される。Ｓｉｎｋは予備のビット・フィールドを無視する。
【０１４２】
ビット３１：ＤＴＣＰに基づくＭＯＶＥ伝送可。
ビット３０：ＤＴＣＰ仕様書で規定されている条件を満足するＢＬＯＣＫ ＭＯＶＥプロトコルをサポートしている。
ビット２９〜０：予備
【０１４３】
ＤＴＣＰ．ＣＯＭ＿ＦＬＡＧＳ ｐａｒａｍはｒｅｓ＠ｐｒｏｔｏｃｏｌＩｎｆｏの第４フィールドに設けられ、３２ビット値が１６進数表記される。また、ＤＴＣＰ．ＣＯＭ＿ＦＬＡＧＳ ｐａｒａｍを用いた場合のｒｅｓ＠ｐｒｏｔｏｃｏｌＩｎｆｏアトリビュートの記述例は以下の通りとなる。
【０１４４】
【数１】
【０１４５】
Ｓｉｎｋは、１以上のＳｏｕｒｃｅからＣＤＳ：：Ｂｒｏｗｓｅレスポンスを引き取ると、Ｓｏｕｒｃｅの選択（Ｓｅｌｅｃｔ Ｓｏｕｒｃｅ）、選択したＳｏｕｒｃｅからＭＯＶＥすべきコンテンツの選択（Ｓｅｌｅｃｔ Ｃｏｎｔｅｎｔ）、並びに移動先の選択（Ｓｅｌｅｃｔ Ｄｅｓｔｉｎａｔｉｏｎ）を行なう。そして、Ｓｉｎｋ側でのコンテンツの選択に引き続いて、選択したコンテンツのＭＯＶＥ伝送処理が開始される。
【０１４６】
ＭＯＶＥ伝送に先駆けて、まずＳｏｕｒｃｅとＳｉｎｋ間の相互認証及びＭＯＶＥ用の鍵共有を行なうために、ＭＯＶＥ用ＡＫＥ手続きを実施する。ここでは、ＳｉｎｋからＳｏｕｒｃｅへＡＫＥトリガ情報が渡されるより前に、ＳｏｕｒｃｅはＳｉｎｋからのＡＫＥを受け付けられる状態になっているものとする。本実施形態では、通常のＤＴＣＰ−ＩＰにおけるＡＫＥ手続（前述並びに図４を参照のこと）と同様の手順に従ってＳｏｕｒｃｅとＳｉｎｋ間の相互認証と、コンテンツ復号鍵の元となる種鍵を共有するための処理を実行する。但し、ＭＯＶＥ実行時には、通常のコンテンツ伝送時とは異なる交換鍵ＫxMを生成し、且つ、１回のＭＯＶＥ伝送毎に交換鍵を消滅させるようにしている。これによって、ＭＯＶＥ伝送をコピー伝送と偽装してコンテンツのコピー動作を行なうことをより困難にすることができる。
【０１４７】
図１０には、ＭＯＶＥ用ＡＫＥ手続きの動作シーケンスを示している。図示のように、チャレンジ・レスポンス認証手続を用いて手続きが行なわれる。Ｓｏｕｒｃｅは、ＳｉｎｋからＭＯＶＥ用のチャレンジ要求（ＭＶ−ＣＨＡＬＬＥＮＧＥ）に応答して、１回のＭＯＶＥ用ＡＫＥ手続毎に、ＭＯＶＥ用の交換鍵ＫXMを生成し、後続のレスポンスを経て、ＳｏｕｒｃｅとＳｉｎｋ間で鍵ＫXM及びＫXM_labelの共有が実現する。但し、ＥＸＣＨＡＮＧＥ ＫＥＹコマンドでは、通常のＡＫＥ手続の場合とは異なるスクランブル方法が適用され、ＭＯＶＥ伝送をコピー伝送と偽られるのを防止する。
【０１４８】
鍵ＫXM及びＫXM_labelの生成方法は、通常のコンテンツ伝送時（前述並びに図４を参照のこと）と同様なので、ここでは詳細な説明を省略する。また、鍵ＫXM及びＫXM_labelを消滅させる規則も鍵ＫX及びＫX_labelの場合と同様なので、説明を省略する。
【０１４９】
ＳｏｕｒｃｅとＳｉｎｋはともに、１回のＭＯＶＥ手続が終了する度に、当該ＭＯＶＥ手続き用の鍵ＫXM及びＫXM_labelを消滅させる。
【０１５０】
図２７には、ＭＯＶＥ用ＡＫＥ手続きの他の動作シーケンス例を示している。図示の例では、Ｓｉｎｋは、ＭＶ−ＩＮＩＴＩＡＴＥコマンドを送信するというＭＯＶＥプロトコルを用いて、ＭＯＶＥ伝送を初期化して、ＭＯＶＥ ＲＴＴ−ＡＫＥプロセスを起動する。ＲＴＴ−ＡＫＥプロセスでは、通常のＡＫＥと同じ手順を追って、チャレンジ−レスポンス手続きによる相互認証が行なわれる。ＲＴＴによればＳｉｎｋ及びＳｏｕｒｃｅのＬｏｃａｌｉｚａｔｉｏｎチェックが行なわれるが、本発明の要旨には直接関連しない。そして、ＭＶ＿ＥＸＣＨＡＮＧＥ＿ＫＥＹコマンドによって交換鍵の共有が行なわれる。
【０１５１】
既に述べたように、本実施形態に係るコンテンツ伝送システムでは、コンテンツのＭＯＶＥモードとして、ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥとＢＬＯＣＫ ＭＯＶＥの２種類を備えている。ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥはＤＴＣＰ−ＩＰで取り決められたＭＯＶＥ伝送により実装することが可能である。これに対し、ＢＬＯＣＫ ＭＯＶＥは現在の仕様に含まれている訳ではない。そこで、例えばＭＯＶＥ用ＡＫＥ手続きを行なう際に、互いの機器がＢＬＯＣＫ ＭＯＶＥに対応しているかどうか、すなわちケイパビリティを確認することが好ましい。
【０１５２】
図１６には、ケイパビリティの確認シーケンスを含んだＭＯＶＥ用ＡＫＥ手続きの動作シーケンス例を示している。図示の例では、ＭＯＶＥ用のチャレンジ・レスポンス認証手続きを行なう前に、ＳｉｎｋとＳｏｕｒｃｅ間で互いのケイパビリティを交換する手続き（ＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥ）が実行される。
【０１５３】
図１７には、図１６中のケイパビリティ交換手続きの部分をさらに詳細に示している。このコマンド／レスポンスに使用されるメッセージは、それぞれの機器が持つケイパビリティを記述したＣＡＰＡＢＩＬＩＴＹフィールドと、ＣＡＰＡＢＩＬＩＴＹフィールドに対する電子署名で構成される。
【０１５４】
メッセージの先頭１ビットはＳｉｎｋ又はＳｏｕｒｃｅを識別するために使用される。機器がＳｉｎｋとしてのケイパビリティを送る場合には１を記載し、Ｓｏｕｒｃｅとしてのケイパビリティを送る場合には０を記載する。これによって、ＳｏｕｒｃｅとしてのケイパビリティのようにＳｉｎｋとしてのケイパビリティを送り（あるいはその逆の振る舞いをし）、ケイパビリティの詐称をすることを防止する。ＣＡＰＡＢＩＬＩＴＹフィールドの末尾のフィールドを使って、機器がＭＯＶＥ（若しくはＢＬＯＣＫ ＭＯＶＥ）に対応しているかどうかを記載する。
【０１５５】
電子署名は、メッセージ先頭のＳｉｎｋ／ＳｏｕｒｃビットとＣＡＰＡＢＩＬＩＴＹフィールドに対して各機器の秘密鍵で求めた電子署名で構成される。ＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥコマンドを受け取ったＳｏｕｒｃｅは、Ｓｉｎｋの公開鍵を使って署名を検証し、ＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥレスポンスを受け取ったＳｉｎｋはＳｏｕｒｃｅの公開鍵を使って署名を検証することができる。
【０１５６】
例えば、ＳｉｎｋがＢＬＯＣＫ ＭＯＶＥモードでのコンテンツのＭＯＶＥを要求するときに、まず、Ｓｉｎｋ側からＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥコマンドが発行され、これに対し、ＳｏｕｒｃｅからはＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥレスポンスが返される。いずれか一方の機器がＢＬＯＣＫ ＭＯＶＥに対応していない場合には、従来のＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥにモードを切り替えてコンテンツのＭＯＶＥ処理を行なうようにしてもよい。
【０１５７】
ＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥシーケンスは、ＭＯＶＥ伝送モード詐称攻撃に対する対策として十分である。但し、この種の詐称攻撃に対する他の対策がとられている場合には、ＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥシーケンスを通じたセキュアな情報交換手続は不要となる。
【０１５８】
ＭＯＶＥ伝送用のＡＫＥ手続きが無事に完了すると、続いてコンテンツ移動（ＭＯＶＥ伝送）手続きが開始される。Ｓｉｎｋ側のユーザ操作によりＳｏｕｒｃｅからコンテンツをＭＯＶＥ伝送する場合、ＳｏｕｒｃｅがＨＴＴＰサーバとして動作するとともにＳｉｎｋがＨＴＴＰクライアントとして動作し、ＨＴＴＰプロトコルを用いてダウンロードＭＯＶＥ伝送を行なうようにすれば良い。コンテンツのデータ・エンティティの伝送自体には、ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥもＢＬＯＣＫ ＭＯＶＥも同様に行なうことができるが、いずれの場合もＨＴＴＰプロトコルを使用することができる。すなわち、ＨＴＴＰクライアントとしてのＳｉｎｋはＨＴＴＰ ＧＥＴリクエストを用いてコンテンツを要求し、これに対し、ＨＴＴＰサーバとしてのＳｏｕｒｃｅはＨＴＴＰ ＧＥＴレスポンスを用い、コンテンツ選択フェーズで選択されたコンテンツのＭＯＶＥ伝送を行なうことができる。ＧＥＴは、特定のＵＲＩから情報を取得する際に、リクエストとして送信するＨＴＴＰメソッドである（周知）。
【０１５９】
図２８には、ＨＴＴＰプロトコルを用いてコンテンツをダウンロードＭＯＶＥ伝送する場合の動作シーケンスを例示している。例えば図２７に示したＭＯＶＥ ＲＴＴ−ＡＫＥ手続が無事に完了すると、ＨＴＴＰクライアントとして動作するＳｉｎｋは、ＨＴＴＰ ＧＥＴリクエストを送信することによって、ＭＯＶＥ伝送プロセスを初期化する。
【０１６０】
ＨＴＴＰプロトコルを用いてコンテンツをダウンロードＭＯＶＥ伝送するとき、Ｓｏｕｒｃｅは、Ｅ−ＥＭＩのモードをＣ１（すなわちＭＯＶＥモード（表１を参照のこと））に設定する。Ｓｉｎｋは、Ｃ１以外のＥ−ＥＭＩモードを受け取ったときには、受信したコンテンツをＭＯＶＥ対象として扱わない。
【０１６１】
Ｓｉｎｋは、ＨＴＴＰのＧＥＴリクエストのヘッダに“ＭＯＶＥ．ｄｔｃｐ．ｃｏｍ：＜ＫｘＭ＿ｌａｂｅｌ＞”（若しくは、“ＭＯＶＥ．ｄｔｃｐ．ｃｏｍ”ではなく“ＢＬＫＭＯＶＥ．ｄｔｃｐ．ｃｏｍ”）というヘッダ情報を設定したＨＴＴＰ ＧＥＴリクエストを送信して、ダウンロードＭＯＶＥ伝送を開始する。Ｓｏｕｒｃｅは、このヘッダ情報を検知したら、リクエストされたコンテンツを鍵ＩＤであるＫxM_labelに対応するＭＯＶＥ用の鍵ＫXMから得た暗号鍵Ｋcで暗号化し、Ｅ−ＥＭＩをＣ１に設定してＧＥＴレスポンスとして伝送する。
【０１６２】
図１４Ａ及び図１４Ｂには、ＨＴＴＰサーバとしてのＳｏｕｒｃｅからＨＴＴＰクライアントとしてのＳｉｎｋへコンテンツをダウンロードＭＯＶＥ伝送する場合のＳｏｕｒｃｅ及びＳｉｎｋがそれぞれ実行する処理動作をフローチャートの形式でまとめている。
【０１６３】
Ｓｉｎｋは、ＨＴＴＰサーバとして動作するＳｏｕｒｃｅを発見して、そこからコンテンツをＭＯＶＥすることを選択すると（ステップＳ２１）、当該Ｓｏｕｒｃｅ宛てにＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｑｕｅｓｔを送信し(ステップＳ２２)、Ｓｏｕｒｃｅからのレスポンスを待機する（ステップＳ２３）。
【０１６４】
Ｓｏｕｒｃｅ側では、ＳｉｎｋからのＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｑｕｅｓｔ又はその他のリクエストの受信を待機しており（ステップＳ１）、当該リクエストを受信すると、Ｓｉｎｋに対してＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｓｐｏｎｓｅを返信し（ステップＳ２）、ＭＯＶＥ用のＡＫＥ要求を受信するまで待機する（ステップＳ３）。
【０１６５】
Ｓｉｎｋは、ＳｏｕｒｃｅからのＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｓｐｏｎｓｅによってコンテンツ一覧を引き取ると、ＭＯＶＥしようとするコンテンツを決定するとともに（ステップＳ２４）、Ｓｏｕｒｃｅに対してＭＯＶＥ用のＡＫＥ処理を要求する（ステップＳ２５）。
【０１６６】
そして、ＳｉｎｋとＳｏｕｒｃｅ間では、ＭＯＶＥ用のＡＫＥ手続きが開始され、互いにＭＯＶＥ用のＡＫＥ処理を実行する（ステップＳ４、Ｓ２６）。ＭＯＶＥ用のＡＫＥの認証に成功すると（ステップＳ５、Ｓ２７）、ＳｏｕｒｃｅはＭＯＶＥ用の鍵と鍵ＩＤを生成してＳｉｎｋに送信し（ステップＳ６）、ＳｉｎｋはＳｏｕｒｃｅからＭＯＶＥ用の鍵と鍵ＩＤを受信する（ステップＳ２８）。但し、ＳｏｕｒｃｅとＳｉｎｋ間でＭＯＶＥ用のＡＫＥの認証に失敗すると、ＳｏｕｒｃｅとＳｉｎｋはともに、後続の処理をすべてスキップして、本処理ルーチン全体を終了する。
【０１６７】
Ｓｉｎｋは、ＭＯＶＥ用ＡＫＥ手続きを成功裏に終えると、 “ＭＯＶＥ．ｄｔｃｐ．ｃｏｍ：＜ＫｘＭ＿ｌａｂｅｌ＞”（若しくは、“ＭＯＶＥ．ｄｔｃｐ．ｃｏｍ”ではなく“ＢＬＫＭＯＶＥ．ｄｔｃｐ．ｃｏｍ”）というヘッダ情報を伴った、ＨＴＴＰ ＧＥＴリクエストを送信する（ステップＳ２９）。
【０１６８】
Ｓｏｕｒｃｅは、ＳｉｎｋからＭＯＶＥ用ヘッダを伴うＨＴＴＰ ＧＥＴリクエストを受信すると（ステップＳ７）、当該リクエストで要求されているコンテンツが他のＳｉｎｋに対してＭＯＶＥしている最中かどうかをチェックする（ステップＳ８）。そして、ＭＯＶＥ伝送中であれば、エラー応答をＳｉｎｋに返す（ステップＳ１５）。
【０１６９】
Ｓｉｎｋ側では、ＳｏｕｒｃｅからのＨＴＴＰ ＧＥＴレスポンスの受信を待機する（ステップＳ３０）。この受信待機中に、要求したコンテンツをＭＯＶＥできない旨のエラー応答をＳｏｕｒｃｅから受信すると（ステップＳ３１）、ここで本処理ルーチン全体を終了する。
【０１７０】
また、Ｓｏｕｒｃｅは、ＳｉｎｋからＭＯＶＥ要求されているコンテンツが他のＳｉｎｋに対してＭＯＶＥ伝送中ではなく、当該Ｓｉｎｋに対してＭＯＶＥ伝送することができるときには、当該コンテンツに対して「ＭＯＶＥ伝送中」フラグをセットしてから（ステップＳ９）、当該コンテンツをＭＯＶＥ用の鍵を用いて暗号化して、要求元Ｓｉｎｋ宛てに送信する（ステップＳ１０）。「ＭＯＶＥ伝送中」フラグをセットすると、当該コンテンツはロック状態となる。そして、暗号化コンテンツの伝送処理を終了すると、ＳｉｎｋからのＭＯＶＥ終了処理の要求の受信を待機する（ステップＳ１１）。
【０１７１】
Ｓｉｎｋは、Ｓｏｕｒｃｅから暗号化コンテンツを成功裏にダウンロードすることができたならば（ステップＳ３２）、Ｓｏｕｒｃｅに対してＭＯＶＥ終了処理の要求を送信する（ステップＳ３３）。そして、ＳｏｕｒｃｅとＳｉｎｋは、それぞれＭＯＶＥ終了処理手続きを実行して（ステップＳ１２、Ｓ３４）、Ｓｉｎｋ側でコンテンツを有効化するとともに、Ｓｏｕｒｃｅ側の元のコンテンツを削除する。Ｓｏｕｒｃｅ及びＳｉｎｋ間におけるＭＯＶＥ伝送終了処理手続きの動作シーケンスの詳細については後述に譲る。
【０１７２】
そして、ＳｏｕｒｃｅとＳｉｎｋは、ＭＯＶＥ終了処理手続きを完了すると（ステップＳ１３、Ｓ３５）、いずれもＭＯＶＥ用の鍵と鍵ＩＤを破棄して（ステップＳ１４、Ｓ３６）、本処理ルーチン全体を終了する。
【０１７３】
図１４Ａ及び図１４Ｂに示したダウンロードＭＯＶＥ処理手続きの期間中、ＭＯＶＥ対象となるコンテンツを他のＳｉｎｋからＭＯＶＥ要求できないようにロックして、多重ＭＯＶＥの発生を防止する。ダウンロードによりＭＯＶＥを行なう場合、Ｓｏｕｒｃｅはサーバに相当するが、保持する個々のコンテンツについてＭＯＶＥ伝送中であるかどうかを、例えば下記の表２に示すようなテーブルを使って管理する。同表では、コンテンツを特定するＵＲＩと、それがＭＯＶＥ伝送中かどうかを示すフラグを関係付けて、コンテンツの状態を確認することができるようになっている。また、Ｓｏｕｒｃｅは、ダウンロードによりコンテンツのＭＯＶＥを要求する他のＳｉｎｋに対して、ＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｓｐｏｎｓｅでＭＯＶＥ伝送中のコンテンツについては存在を示さないことで、混乱を防止することができる（視聴途中でのＭＯＶＥ完了による伝送中断など）。
【０１７４】
【表２】
【０１７５】
また、Ｓｉｎｋは、ＢＬＯＣＫ ＭＯＶＥモードでダウンロードＭＯＶＥ伝送処理が行なわれている期間中は、コンテンツはまだ有効化されていないので、リアルタイムでレンダリングする以外の目的で受信したコンテンツを利用することはできない。リアルタイム・レンダリングの仕組みについては、図７を参照しながら既に説明したので、ここでは説明を省略する。
【０１７６】
なお、ＭＯＶＥ用ＡＫＥ手続き並びにコンテンツ移動（ＭＯＶＥ）手続きの期間中には、ＭＯＶＥ伝送を途中で取り止めるＣａｎｃｅｌやＡｂｏｒｔといった中断処理が起動することがあるが、この点の詳細については後述に譲る。
【０１７７】
ＳｉｎｋがＨＴＴＰプロトコルのＧＥＴリクエストにより、選択したＳｏｕｒｃｅから所望のコンテンツを成功裏にダウンロードすることができたならば、ＳｉｎｋとＳｏｕｒｃｅ間でコンテンツ伝送が無事に終了したことの確認すなわちＣｏｍｍｉｔｍｅｎｔを行なうためのＭＯＶＥ終了処理手続きを実施する。この終了処理では、Ｓｉｎｋ側ではこのダウンロードしたコンテンツを有効化すると同時に、Ｓｏｕｒｃｅ側では元のコンテンツの削除を行なう。また、ＳｉｎｋとＳｏｕｒｃｅはそれぞれ、コンテンツ伝送に使用した交換鍵の削除を行なう。ＢＬＯＣＫ ＭＯＶＥモードでは、このようなＣｏｍｍｉｔｍｅｎｔを実施することで、コンテンツ全体を一括してＳｏｕｒｃｅとＳｉｎｋ間で移動することと等価なＭＯＶＥ処理を実現することができる。ＢＬＯＣＫ ＭＯＶＥも、ＳｏｕｒｃｅとＳｉｎｋで同じコンテンツが二重に存在することはないから、ＤＴＣＰで規定されている条件を満たしたコンテンツのＭＯＶＥ処理であると言える。
【０１７８】
図１１には、Ｓｏｕｒｃｅ及びＳｉｎｋ間でＭＯＶＥ終了処理手続きを実行する動作シーケンスを示している。図示の動作シーケンスは、図１４Ｂに示したフローチャートのステップＳ１２並びにＳ３４において実施される。
【０１７９】
Ｓｉｎｋは、ＭＯＶＥ対象となるコンテンツを無事に受信し終えると、Ｓｏｕｒｃｅからレスポンスを受け取るまで、ＭＯＶＥ終了処理用コマンドＣＭＤ１（若しくはＭＶ＿ＦＩＮＡＬＩＺＥコマンド）を送信し続ける。
【０１８０】
一方、Ｓｏｕｒｃｅは、ＭＯＶＥ終了処理用コマンドＣＭＤ１を受信すると、ＭＯＶＥ終了処理用レスポンスＲＳＰ１を返信する。また、Ｓｏｕｒｃｅは、有効状態（Ｖａｌｉｄ）であった元のコンテンツを、中間的（ｉｎｔｅｒｉｍ）な無効状態（Ｉｎｖａｌｉｄ）に遷移させる。
【０１８１】
Ｓｉｎｋは、受信したＲＳＰ１において、Ｓｏｕｒｃｅが既にＭＯＶＥ処理手続を終了していると記載されていれば、同様にＭＯＶＥ処理手続を終了する。これに伴って、ＳｏｕｒｃｅからＭＯＶＥしたコンテンツを無効状態から有効状態に遷移させる。
【０１８２】
続いて、Ｓｉｎｋは、Ｓｏｕｒｃｅからレスポンスを受け取るまで、次のＭＯＶＥ終了処理用コマンドＣＭＤ２（若しくは、ＭＶ＿ＣＯＭＰＬＥＴＥコマンド）を送信し続ける。これに対し、Ｓｏｕｒｃｅは、元のコンテンツを中間的な無効状態から完全な無効状態に遷移させてから、ＭＯＶＥ終了処理用レスポンスＲＳＰ２を返信する。
【０１８３】
図１８には、図１１に示したダウンロードＭＯＶＥ伝送終了シーケンス上でＳｉｎｋ及びＳｏｕｒｃｅがそれぞれ実施する処理内容をフローチャートの形式で具体的に示している。
【０１８４】
Ｓｉｎｋ側では、まず乱数Ｒを生成し（ステップＳ８１）、この乱数Ｒに対し所定の演算処理を適用して、メッセージ・ダイジェストＭＡＣ５Ａ及びＭＡＣ６Ａを計算する。ＭＡＣ５ＡはＳｏｕｒｃｅに渡す値、ＭＡＣ６ＡはＳｏｕｒｃｅから返されることが期待される値である。ＭＡＣ５Ａ及びＭＡＣ６Ａの計算式は、例えば以下の通りである。この計算には、ＫxM_labelに対応するＫxMが使用される。
【０１８５】
【数２】
【０１８６】
続いて、Ｓｉｎｋは、鍵ＩＤであるＫxM_labelと乱数Ｒ、ＭＡＣ５Ａ、ＭＡＣ６Ａ、ＭＯＶＥしたコンテンツのＩＤ、ＳｏｕｒｃｅのＩＤを不揮発的に格納する（ステップＳ８２）。これらのデータを不揮発的に格納しておくことにより、電源遮断などによりコンテンツ伝送終了処理が途切れても、再開処理が可能となり、ＳｉｎｋとＳｏｕｒｃｅの双方でコンテンツが無効になることを避けることができる。
【０１８７】
そして、Ｓｉｎｋは、ＫxM_labelと乱数Ｒ、ＭＡＣ５Ａを含んだＭＯＶＥ終了用コマンドＣＭＤ１（若しくは、ＭＶ＿ＦＩＮＡＬＩＺＥコマンド）をＳｏｕｒｃｅに送信する。Ｓｉｎｋは、Ｓｏｕｒｃｅからレスポンスを受け取るまでは、受信タイムアウトが発生する度にＣＭＤ１を送信し続ける（ステップＳ８３）。
【０１８８】
一方、Ｓｏｕｒｃｅは、ＭＯＶＥ用コマンドＣＭＤ１を受け取ると、これに含まれる乱数Ｒに対し所定の演算処理（同上）を適用して、メッセージ・ダイジェストＭＡＣ５Ｂ及びＭＡＣ６Ｂを計算する。ＭＡＣ６ＢはＳｉｎｋに渡す値、ＭＡＣ５ＢはＳｉｎｋから得られることが期待される値である。そして、Ｓｏｕｒｃｅは、ＣＭＤ１に含まれるＭＡＣ５Ａと、自ら求めたＭＡＣ５Ｂを照合して、コマンドの真正性をチェックする（ステップＳ９１）。このチェックに失敗したときには、コンテンツ伝送終了処理を中止（Ａｂｏｒｔ）する。但し、Ｓｏｕｒｃｅは自身のソケット情報が途中で変化したことが原因でＳｉｎｋがＣＭＤ１の送信先を誤った可能性がある場合は、処理を中止せずにＣＭＤ１を待ち続けても良い。
【０１８９】
また、Ｓｏｕｒｃｅは、真正性のチェックに成功したときには、鍵ＩＤであるＫxM_labelとＭＡＣ６Ｂ、ＭＯＶＥしたコンテンツのＩＤを不揮発的に格納する（ステップＳ９２）。これらのデータを不揮発的に格納しておくことにより、電源遮断などによりコンテンツ伝送終了処理が途切れても、再開処理が可能となり、ＳｉｎｋとＳｏｕｒｃｅの双方でコンテンツが無効になることを避けることができる（同上）。
【０１９０】
そして、Ｓｏｕｒｃｅは、有効状態であった元のコンテンツを、中間的な無効状態に遷移させてから（ステップＳ９３）、ＣＭＤ１を受理したこと（Ａｃｃｅｐｔｅｄ）を示すＭＯＶＥ終了処理用レスポンスＲＳＰ１を返信する。
【０１９１】
Ｓｉｎｋは、ＳｏｕｒｃｅからＭＯＶＥ終了処理用レスポンスＲＳＰ１を受信すると、ＣＭＤ１が拒絶（Ｒｅｊｅｃｔｅｄ）されていないかどうかをチェックする（ステップＳ８４）。ＲＳＰ１がＡｃｃｅｐｔｅｄを示している場合には、さらにＲＳＰ１に含まれるＭＡＣ６Ｂが自ら保持しているＭＡＣ６Ａと一致するかどうかをチェックする（ステップＳ８５）。そして、これらのチェックに成功すると、ＳｏｕｒｃｅからＭＯＶＥしたコンテンツを無効状態から有効状態に遷移させる（ステップＳ８６）。
【０１９２】
続いて、Ｓｉｎｋは、鍵ＩＤであるＫxM_labelを含んだＭＯＶＥ終了用コマンドＣＭＤ２（若しくは、ＭＶ＿ＣＯＭＰＬＥＴＥコマンド）をＳｏｕｒｃｅに送信する。Ｓｉｎｋは、Ｓｏｕｒｃｅからレスポンスを受け取るまでは、受信タイムアウトが発生する度にＣＭＤ２を送信し続ける（ステップＳ８７）。
【０１９３】
Ｓｏｕｒｃｅは、ＭＯＶＥ終了処理用コマンドＣＭＤ２を受信すると、これに含まれるＫxM_labelに対応するデータを削除する（ステップＳ９４）。ここで言うデータとは、ステップＳ９２で不揮発的に格納しておいたＫxM_labelとＭＡＣ６Ｂ、ＭＯＶＥしたコンテンツのＩＤのことである。そして、Ｓｏｕｒｃｅは、ＭＯＶＥ終了処理用レスポンスＲＳＰ２を返信する。
【０１９４】
Ｓｉｎｋは、ＭＯＶＥ終了処理用レスポンスＲＳＰ２を受信すると、これに含まれるＫxM_labelに対応するデータを削除する（ステップＳ８８）。ここで言うデータとは、ステップＳ８２で不揮発的に格納しておいたＫxM_labelと乱数Ｒ、ＭＡＣ５Ａ、ＭＡＣ６Ａ、コンテンツのＩＤ、ＳｏｕｒｃｅのＩＤのことである。
【０１９５】
ダウンロードＭＯＶＥ伝送が終了した後にＳｉｎｋ側でコンテンツを有効化する方法は特に限定されない。有効化すると、Ｓｉｎｋ内のコンテンツ記録ブロックでＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして符号化して記録されたコンテンツの利用が可能となる（例えば、記録時に適用した暗号の解除が可能となる）。この結果、コンテンツ再生ブロック３１に符号化コンテンツを供給して、ビデオ及びオーディオ信号に変換（ｒｅｎｄｅｒｉｎｇ）して、ディスプレイなどのＡＶ出力部から映像並びに音響出力することができる。また、Ｓｉｎｋは、今度はＳｏｕｒｃｅとしてさらに別のＳｉｎｋに対して、Ｎｏ ｍｏｒｅ Ｃｏｐｉｅｓコンテンツを上述と同様にダウンロード形式でＭＯＶＥしたり、あるいは後述するアップロード形式でＭＯＶＥしたりすることもできる。
【０１９６】
また、ダウンロードＭＯＶＥ伝送が終了した後にＳｏｕｒｃｅ側で元のコンテンツを削除する方法も特に限定されない。コンテンツを格納したハード・ディスクなどの記録媒体からコンテンツ・データのエンティティ自体を削除する以外に、符号化（暗号化）して記録されているコンテンツのエンティティは残すが復号鍵を再び使用できないようにするのであってもよい。
【０１９７】
ここで、ＳｏｕｒｃｅからＳｉｎｋへコンテンツのエンティティが成功裏にダウンロードＭＯＶＥ伝送されたにも拘らず、一方の機器の電源遮断などにより図１１に示したダウンロードＭＯＶＥ伝送の終了処理シーケンスが途切れてしまう可能性がある。このような場合、ダウンロードＭＯＶＥ伝送の終了処理の中断（ｉｎｔｅｒｒｕｐｔｅｄ）によって、Ｓｏｕｒｃｅ及びＳｉｎｋの双方において移動したコンテンツを利用できなくなるおそれがある。そこで、本実施形態に係るコンテンツ伝送システムでは、このような事態に備えて、コンテンツ伝送終了処理を再開するための処理手続きを設けて、Ｃｏｍｍｉｎｍｅｎｔを無事に終了させるようにしている。この再開手続きによって、コンテンツ伝送手続きが無駄にならずに済むとともに、ＳｉｎｋとＳｏｕｒｃｅの双方でコンテンツが無効になることを避けることができる。
【０１９８】
ダウンロードＭＯＶＥ伝送の終了処理の再開を可能にするために、Ｓｉｎｋ及びＳｏｕｒｃｅの各々では、ダウンロードＭＯＶＥ伝送の終了処理を開始する際に、ＮＶＲＡＭなどの不揮発性メモリを用いて、再開処理に必要となるデータを保存するようにしている。Ｓｉｎｋ側では、ＣＭＤ１すなわちＭＶ＿ＦＩＮＡＬＩＺＥコマンドを発行する際に、そのコマンドで送信するＫXM_lable、乱数Ｒ、ＭＡＣ５Ａ、さらにＭＡＣ６Ａ、ダウンロードＭＯＶＥしたコンテンツのＩＤ（ＣＤＳのオブジェクトＩＤに相当）、ＳｏｕｒｃｅのＩＤ（ＵＰｎＰ（登録商標）のＵＵＩＤに相当）を不揮発的に格納する（図１８中のステップＳ８２を参照）。一方、Ｓｏｕｒｃｅ側では、鍵ＩＤであるＫxM_labelとＭＡＣ５Ｂ、ＭＡＣ６Ｂを不揮発的に格納する（図１８中のステップＳ９２を参照）。再開処理は、基本的にはＳｉｎｋ側が起動する。
【０１９９】
Ｓｉｎｋは、ＵＰｎＰ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅで規定されているＵＵＩＤを記憶しておくことにより、ＣＤＳ処理のクエスト先であるＳｏｕｒｃｅを発見することが可能であり、また、ＵＰｎＰ ＡＶ ＣＤＳ２で規定されているＯｂｊｅｃｔ ＩＤを記憶しておくことにより、ＭＯＶＥ対象コンテンツを指定することが可能である。そして、中断したＭＯＶＥ処理を再開する際、Ｓｉｎｋは、最初にコンテンツを選択するときと同様にＵＰｎＰ（登録商標）のＣＤＳの処理をすることで、ＭＯＶＥ対象となるコンテンツに対するソケット情報を得ることができる。例えばＳｏｕｒｃｅが電源遮断して、再開時にそのＩＰアドレスが変更してしまっても問題はない。
【０２００】
Ｓｉｎｋは、ＭＯＶＥ対象コンテンツのソケット情報を得ると、続いて、該当するＳｏｕｒｃｅとのＴＣＰコネクションを確立する。図２９には、ＭＯＶＥ伝送終了処理を再開する際に、Ｓｉｎｋ及びＳｏｕｒｃｅ間でＴＣＰコネクションを確立するための処理手順をフローチャートの形式で示している。
【０２０１】
Ｓｉｎｋは、不揮発に記憶しているＳｏｕｒｃｅＩＤ（ＵＵＩＤ）を１つ選択すると（ステップＳ１３１）、ＵＰｎＰのデバイス発見のプロトコル（ＳＳＤＰ）により、同じＵＵＩＤを持つ機器が存在するかどうかをチェックする（ステップＳ１３２）。ここで、同じＵＵＩＤを持つ機器が存在しなければ、後続の処理をすべてスキップして、本処理ルーチン全体を終了する。
【０２０２】
一方、同じＵＵＩＤを持つ機器が存在する場合には（ステップＳ１３２のＹｅｓ）、その機器に対してＣＤＳ：：ＢｒｏｗｓｅリクエストをＯｂｊｅｃｔ ＩＤ指定付きで送信する（ステップＳ１３３）。
【０２０３】
Ｓｏｕｒｃｅは、ＳｉｎｋからＣＤＳ：：Ｂｒｏｗｓｅリクエストを受信すると（ステップＳ１４１）、該当するコンテンツについてコンテンツ伝送終了処理が完了していない旨の情報を含んだＣＤＳ：：Ｂｒｏｗｓｅレスポンスを返信する（ステップＳ１４２）。
【０２０４】
なお、コンテンツ伝送終了処理が完了していないということは、例えばコンテンツがＭｏｖａｂｌｅであることを示す属性情報を含めない、あるいはＨＴＴＰ ＧＥＴリクエストを送るべきＵＲＬを含めない、ＭＯＶＥ処理を実行中という属性情報を含める、といった方法で示すことができる。
【０２０５】
そして、Ｓｉｎｋは、ＣＤＳ：：Ｂｒｏｗｓｅレスポンスを受信すると（ステップＳ１３４）、当該メッセージに含まれるソケット情報を参照して、ＣＭＤ１、ＣＭＤ２などのＡＫＥコマンド用のＴＣＰコネクションを確立する（ステップＳ１３５）。
【０２０６】
Ｓｉｎｋは、このようにしてＡＫＥコマンド用のＴＣＰコネクションを確立すると、不揮発的に格納しておいた鍵ＩＤであるＫxM_labelと乱数Ｒ、ＭＡＣ５Ａを参照して、ＣＭＤ１（ＭＶ＿ＦＩＮＡＬＩＺＥコマンド）又はＣＭＤ２（ＭＶ＿ＣＯＭＰＬＥＴＥコマンド）をＳｏｕｒｃｅに送信する。これに対し、Ｓｏｕｒｃｅは、同様に不揮発的に格納しておいたＫxM_labelとＭＡＣ６Ｂを用いてＣＭＤ１に対するレスポンスＲＳＰ１又はＣＭＤ２に対するレスポンスＲＳＰ２を返す。これによって、ＳｉｎｋとＳｏｕｒｃｅ間のダウンロードＭＯＶＥ伝送の終了処理を完結することができる。
【０２０７】
図１９には、図１１並びに図１８に示したダウンロードＭＯＶＥ伝送の終了処理シーケンスが何らかの原因により中断（ｉｎｔｅｒｒｕｐｔｅｄ）した後、ＳｏｕｒｃｅがＳｉｎｋからＭＯＶＥ終了処理用コマンドＣＭＤ１を受け取ったときの処理手順をフローチャートの形式で示している。
【０２０８】
Ｓｏｕｒｃｅは、ＭＯＶＥ終了処理用コマンドＣＭＤ１に含まれるＫxM_labelを自分が不揮発的に格納しているかどうかをチェックする（ステップＳ１０１）。
【０２０９】
ここで、ＫxM_labelを保持していないときには、Ｓｏｕｒｃｅは既に該当するコンテンツ伝送終了処理を完了しているか、又はＣＭＤ１が自分とは無関係であることが想定されるので、当該コマンドを拒絶すること（Ｒｅｊｅｃｔｅｄ）を示すＭＯＶＥ終了処理用レスポンスＲＳＰ１を返す（ステップＳ１０４）。
【０２１０】
一方、ＫxM_labelを保持しているときには、該当するコンテンツ伝送終了処理が中断していたことになるので、Ｓｏｕｒｃｅは、ＣＭＤ１内のコンテンツＩＤで示される元のコンテンツを中間的な無効状態に遷移させてから（ステップＳ１０２）、ＣＭＤ１を受理したこと（Ａｃｃｅｐｔｅｄ）を示すＭＯＶＥ終了処理用レスポンスＲＳＰ１を返信する（ステップＳ１０３）。このようにして、中断したＭＯＶＥ終了処理をＨＴＴＰサーバとして動作するＳｏｕｒｃｅにおいて再開することができる。
【０２１１】
また、図２０には、図１１並びに図１８に示したダウンロードＭＯＶＥ伝送の終了処理シーケンスが何らかの原因により中断（ｉｎｔｅｒｒｕｐｔｅｄ）した後、ＳｏｕｒｃｅがＳｉｎｋからＭＯＶＥ終了処理用コマンドＣＭＤ２を受け取ったときの処理手順をフローチャートの形式で示している。
【０２１２】
Ｓｏｕｒｃｅは、ＭＯＶＥ終了処理用コマンドＣＭＤ２に含まれる鍵ＩＤであるＫxM_labelを自分が不揮発的に格納しているかどうかをチェックする（ステップＳ１１１）。
【０２１３】
ここで、ＫxM_labelを保持しているときには、該当するコンテンツ伝送終了処理が中断していたことになるので、Ｓｏｕｒｃｅは、ＫxM_labelに対応付けて格納されているデータ（すなわち、ＭＡＣ６Ｂ、ＭＯＶＥしたコンテンツのＩＤ）を削除し（ステップＳ１１２）、ＣＭＤ２を受理したこと（Ａｃｃｅｐｔｅｄ）を示すＭＯＶＥ終了処理用レスポンスＲＳＰ２を返信する（ステップＳ１１３）。
【０２１４】
一方、ＫxM_labelを保持していないときには、Ｓｏｕｒｃｅは既に該当するコンテンツ伝送終了処理を完了しているか、又はＣＭＤ２が自分とは無関係であることが想定されるので、ステップＳ１１２をスキップし、ＣＭＤ２を受理したこと（Ａｃｃｅｐｔｅｄ）を示すＭＯＶＥ終了処理用レスポンスＲＳＰ２を返信する（ステップＳ１１３）。このようにして、中断したＭＯＶＥ終了処理をＨＴＴＰサーバとして動作するＳｏｕｒｃｅにおいて再開することができる。
【０２１５】
また、図２１には、図１１並びに図１８に示したダウンロードＭＯＶＥ伝送の終了処理シーケンスが何らかの原因により中断（ｉｎｔｅｒｒｕｐｔｅｄ）した後、ＳｉｎｋがＭＯＶＥ終了処理を再開させるための処理手順をフローチャートの形式で示している。
【０２１６】
Ｓｉｎｋは、ステップＳ８２において不揮発的に格納したデータ、すなわち鍵ＩＤであるＫxM_labelと乱数Ｒ、ＭＡＣ５Ａ、ＭＡＣ６Ａ、コンテンツＩＤ、ＳｏｕｒｃｅＩＤが存在していることを検出すると（ステップＳ１２１）、これはコンテンツ伝送終了処理が中断して、ＳｏｕｒｃｅとのＣｏｍｍｉｔｍｅｎｔが完了せずに、これらのデータが消去されずに残っていることが分かる。
【０２１７】
この場合、コンテンツ伝送終了処理を再開するために、該当するＳｏｕｒｃｅとのＴＣＰコネクションを確立する（ステップＳ１２２）。
【０２１８】
そして、コンテンツＩＤで示されるコンテンツが無効状態かどうかをチェックする（ステップＳ１２３）。
【０２１９】
コンテンツが無効状態のままであれば（ステップＳ１２３のＹｅｓ）、ＳｏｕｒｃｅからＭＯＶＥ終了処理用レスポンスＲＳＰ１を受け取る前にコンテンツ伝送終了処理が中断したことになるので、図１８に示したフローチャートの＃１にジャンプして（ステップＳ１２４）、ＳｏｕｒｃｅとのＣｏｍｍｉｔｍｅｎｔを開始する。
【０２２０】
コンテンツが既に有効状態となっていれば（ステップＳ１２３のＮｏ）、ＳｏｕｒｃｅからＣｏｍｍｉｔｍｅｎｔを得た後でＭＯＶＥ終了処理用レスポンスＲＳＰ２を受け取る前にコンテンツ伝送終了処理が中断したことになるので、図１８に示したフローチャートの＃２にジャンプして（ステップＳ１２５）、Ｓｏｕｒｃｅに対するＭＯＶＥ終了処理用コマンドＣＭＤ２の送信を行なう。このようにして、中断したＭＯＶＥ終了処理をＨＴＴＰクライアントとして動作するＳｉｎｋにおいて再開することができる。
【０２２１】
図１９〜図２１に示したようなＭＯＶＥ伝送シーケンスの再開処理によって、コンテンツ伝送手続きが無駄にならずに済むとともに、ＳｉｎｋとＳｏｕｒｃｅの双方でコンテンツが無効になることを避けることができる。
【０２２２】
Ｓｏｕｒｃｅは、ＭＯＶＥ終了処理用レスポンスＲＳＰ２を返信するか、又は無効化すべきというユーザの指示入力に応答して、元のコンテンツを中間的な無効状態から完全な無効状態に遷移させる。
【０２２３】
Ｃ−２．アップロード形式のＢＬＯＣＫ ＭＯＶＥ
図１２には、アップロード形式でＳｏｕｒｃｅとＳｉｎｋ間のＢＬＯＣＫ ＭＯＶＥ伝送を行なう場合の動作シーケンスを示している。この場合のＭＯＶＥ伝送もダウンロードと同様に、Ｓｉｎｋ及びコンテンツ選択、ＭＯＶＥ用ＡＫＥ手続き、コンテンツ移動（ＭＯＶＥ）手続き、ＭＯＶＥ終了処理手続きという４段階のフェーズで構成される。このうち、ＭＯＶＥ用ＡＫＥ手続き、コンテンツ移動（ＭＯＶＥ）手続き、ＭＯＶＥ終了処理手続きは、ＤＴＣＰ上で規定される手順に従って実行される。
【０２２４】
Ｓｉｎｋ及びコンテンツ選択のフェーズでは、ユーザは、Ｓｏｕｒｃｅ側で、ＭＯＶＥしたいコンテンツの選択（Ｓｅｌｅｃｔ Ｃｏｎｔｅｎｔ）と、コンテンツの伝送先となるＳｉｎｋの選択（Ｓｅｌｅｃｔ Ｓｉｎｋ ＆ Ｄｅｓｔｉｎａｔｉｏｎ）を行なってから、該当するＳｉｎｋに対して、ＤＴＣＰ ＭＯＶＥとして伝送するコンテンツに関する認証及び鍵交換用のソケット情報を通知する。そして、これに引き続いて、選択したコンテンツのＭＯＶＥ処理が開始する。
【０２２５】
ＳｏｕｒｃｅからＳｉｎｋに対する通知は、ＵＰｎＰ（登録商標）ベースでＣＤＳを用いて行なうことができる。図１３には、この場合のＳｏｕｒｃｅとＳｉｎｋ間の動作シーケンスを示している。
【０２２６】
まず、Ｓｏｕｒｃｅは、Ｓｉｎｋに対してアップロードＭＯＶＥ伝送を要求するときには、伝送しようとするコンテンツの保管場所を作成するよう、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔリクエストを発行する。Ｓｏｕｒｃｅは、このＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔリクエスト内で、ＭＯＶＥしようとするコンテンツ毎に、コンテンツのタイトル、コンテンツのＵＰｎＰ（登録商標）クラス、認証及び鍵交換用のソケット情報並びにＤＴＣＰ−ＩＰのＭＯＶＥ手続きによってコンテンツ伝送を行なうことを記載する。なお、コンテンツ特定用のｉｔｅｍ ＩＤ、ｐａｒｅｎｔＩＤ、コンテンツのＵＲＩはリクエストで不定となり、ＨＴＴＰサーバであるＳｉｎｋが決定し、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔレスポンスによってＨＴＴＰクライアントであるＳｏｕｒｃｅに通知する。図１３に示す例では、Ｓｏｕｒｃｅは、ｒｅｓのｐｒｏｔｏｃｏｌＩｎｆｏアトリビュートの第３フィールドにソケット情報としての文字列“ＤＴＣＰ１ＨＯＳＴ＝（ｈｏｓｔ）；ＤＴＣＰ１ＰＯＲＴ＝（ｐｏｒｔ）”を記載するとともに、当該コンテンツをＤＴＣＰ−ＩＰのＭＯＶＥ伝送シーケンスによって伝送することを示す文字列“ＤＴＣＰＯＰ＝ＭＯＶＥ”を記載している。
【０２２７】
なお、ｒｅｓ＠ｐｒｏｔｏｃｏｌＩｎｆｏの中にＤＴＣＰＯＰなど、アップロード時に一時的に使用する属性情報を含めると、Ｓｉｎｋは自身がＨＴＴＰサーバとしてＣＤＳ：：Ｂｒｏｗｓｅリクエストへの応答でｒｅｓ＠ｐｒｏｔｏｃｏｌＩｎｆｏを送る際にはその属性情報を取り除く必要があり、処理が煩雑になる。そこで、属性情報をｐｒｏｔｏｃｏｌＩｎｆｏとは独立して新たなアトリビュートで送る方法も考えられる。具体的には、ｒｅｓ＠ｄｔｃｐ：ｕｐｌｏａｄＩｎｆｏアトリビュートというものを設けて、コンテンツのＭＯＶＥ伝送の可否を示すことが考えられる。ｒｅｓ＠ｄｔｃｐ：ｕｐｌｏａｄＩｎｆｏアトリビュートは３２ビット長のフィールドであり、ビット定義は以下の通りとなっている。ビット３０に１が記載されているときには、ビット３１にも１が記載される。Ｓｉｎｋは予備のビット・フィールドを無視する。
【０２２８】
ビット３１：ＤＴＣＰに基づき、ＭＯＶＥとして伝送する。
ビット３０：ＤＴＣＰ仕様書に規定されている条件を満足するＢＬＯＣＫ ＭＯＶＥプロトコルを使用する。
ビット２９〜０：予備
【０２２９】
ｒｅｓ＠ｄｔｃｐ：ｕｐｌｏａｄＩｎｆｏアトリビュートの３２ビットは１６進数表記される。ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔリクエスト中のｒｅｓ＠ｄｔｃｐ：ｕｐｌｏａｄＩｎｆｏアトリビュートの記述例は以下の通りとなる。
【０２３０】
【数３】
【０２３１】
Ｓｉｎｋは、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔリクエストを受け取ると、コンテンツの伝送元となるＳｏｕｒｃｅ側の認証及び鍵交換用のソケット情報と、コンテンツがＭＯＶＥとして伝送されるのかどうかを識別することができる。そして、Ｓｉｎｋは、ＳｏｕｒｃｅからのアップロードＭＯＶＥ伝送要求を受け容れるときには、コンテンツの保管場所（すなわちインポート先）をローカルの記憶領域に作成するとともに、この保管場所の情報を含んだＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔレスポンスを要求元のＳｏｕｒｃｅに返す。図１３に示す例では、Ｓｉｎｋはｒｅｓ＠ｐｒｏｔｏｃｏｌＩｎｆｏアトリビュート内のｉｍｐｏｒｔＵｒｉアトリビュートにＭＯＶＥ対象となるコンテンツのインポート先を示す文字列“ｈｔｔｐ：／／１．２．３．４：５００００／ｉｍｐｏｒｔ？ｉｄ＝６”を記載している。あるいは、ｒｅｓ＠ｄｔｃｐ：ｕｐｌｏａｄＩｎｆｏアトリビュートを用いてＭＯＶＥ伝送の可否を示す場合には、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔレスポンスの記述例は以下の通りとなる。
【０２３２】
【数４】
【０２３３】
このようにして、Ｓｏｕｒｃｅは、ＳｉｎｋからエラーでないＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔレスポンスを受け取って、Ｓｉｎｋ宛てにコンテンツのＭＯＶＥが可能であると確認し、コンテンツの保管場所を確保すると、これに引き続いて、選択したコンテンツのアップロードＭＯＶＥ伝送処理が開始される。
【０２３４】
ＭＯＶＥ伝送に先駆けて、まずＳｏｕｒｃｅとＳｉｎｋ間の相互認証及びＭＯＶＥ用の鍵共有を行なうために、ＭＯＶＥ用ＡＫＥ手続きを実施する。ＭＯＶＥ用ＡＫＥ手続きの動作シーケンスは、図１０、並びに図１６〜１７を参照しながら既に説明した通りなので、ここでは説明を省略する。但し、ＭＶ−ＣＨＡＬＬＥＮＧＥコマンドでは、通常のＡＫＥ手続の場合とは異なるスクランブル方法が適用され、ＭＯＶＥ伝送をコピー伝送と偽られるのを防止する（同上）。
【０２３５】
あるいは、ＭＯＶＥ用ＡＫＥ手続きには、図２７に示したような動作シーケンスを使用することができる。この場合、Ｓｉｎｋは、ＭＶ−ＩＮＩＴＩＡＴＥコマンドを送信するというＭＯＶＥプロトコルを用いて、ダウンロードＭＯＶＥ伝送を初期化して、ＭＯＶＥ ＲＴＴ−ＡＫＥプロセスを起動する。ＲＴＴ−ＡＫＥプロセスでは、通常のＡＫＥと同じ手順を追って、チャレンジ−レスポンス手続きによる相互認証が行なわれる。そして、ＭＶ＿ＥＸＣＨＡＮＧＥ＿ＫＥＹコマンドによって共有鍵の交換が行なわれる（同上）。
【０２３６】
そして、ＭＯＶＥ伝送用のＡＫＥ手続きが無事に完了すると、続いてコンテンツ移動（ＭＯＶＥ）手続きが開始される。Ｓｏｕｒｃｅ側のユーザ操作によりＳｉｎｋへコンテンツをＭＯＶＥ伝送する場合、ＳｏｕｒｃｅがＨＴＴＰクライアントとして動作するとともにＳｉｎｋがＨＴＴＰサーバとして動作し、ＨＴＴＰプロトコルを用いてアップロードＭＯＶＥ伝送を行なうようにすれば良い。すなわち、ＨＴＴＰクライアントとしてのＳｏｕｒｃｅはＨＴＴＰ ＰＯＳＴリクエストを送信し、これに対し、ＨＴＴＰサーバとしてのＳｉｎｋはＨＴＴＰ ＰＯＳＴレスポンスを返信することにより、コンテンツ選択フェーズで選択されたコンテンツをＳｏｕｒｃｅからＳｉｎｋへアップロードＭＯＶＥ伝送する。ＰＯＳＴは、特定のＵＲＩに対して情報を送信するための、リクエストとして送信するＨＴＴＰメソッドである（周知）。
【０２３７】
ＨＴＴＰプロトコルを用いてコンテンツをアップロードＭＯＶＥ伝送するとき、Ｓｏｕｒｃｅは、Ｅ−ＥＭＩのモードをＣ１（すなわちＭＯＶＥモード（表１を参照のこと））に設定する。Ｓｉｎｋは、Ｃ１以外のＥ−ＥＭＩモードを受け取ったときには、受信したコンテンツをＭＯＶＥ対象として扱わない（同上）。
【０２３８】
Ｓｏｕｒｃｅは、ＨＴＴＰのＰＯＳＴリクエストのヘッダに“ＭＯＶＥ．ｄｔｃｐ．ｃｏｍ：＜ＫｘＭ＿ｌａｂｅｌ＞”（若しくは、“ＭＯＶＥ．ｄｔｃｐ．ｃｏｍ”ではなく“ＢＬＫＭＯＶＥ．ｄｔｃｐ．ｃｏｍ”）というヘッダ情報を設定したＨＴＴＰ ＰＯＳＴリクエストを送信して、アップロードＭＯＶＥ伝送を開始する。そして、Ｓｏｕｒｃｅは、リクエストしたコンテンツをＫxM_labelに対応するＭＯＶＥ用の鍵ＫXMから得た暗号鍵Ｋcで暗号化し、Ｅ−ＥＭＩをＣ１に設定して後続のＰＯＳＴリクエストとして伝送する。
【０２３９】
図１５Ａ及び図１５Ｂには、ＨＴＴＰクライアントとしてのＳｏｕｒｃｅからＨＴＴＰサーバとしてのＳｉｎｋへコンテンツをアップロードＭＯＶＥ伝送する場合のＳｏｕｒｃｅ及びＳｉｎｋがそれぞれ実行する処理動作をフローチャートの形式でまとめている。
【０２４０】
Ｓｏｕｒｃｅは、コンテンツのアップロード先のサーバとして動作するＳｉｎｋを発見すると（ステップＳ４１）、Ｓｉｎｋに対してコンテンツの保管場所の作成を要求するべく、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｑｕｅｓｔを送信して（ステップＳ４２）、そのレスポンスの受信を待機する（ステップＳ４３）。
【０２４１】
Ｓｉｎｋは、ＳｏｕｒｃｅからＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｑｕｅｓｔを受信すると（ステップＳ６１）、これに対するレスポンスを返信する（ステップＳ６２）。
【０２４２】
Ｓｏｕｒｃｅは、ＳｉｎｋからＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｓｐｏｎｓｅを受信すると、続いてＭＯＶＥするコンテンツを決定し（ステップＳ４４）、ＭＯＶＥ用のＡＫＥ要求を受信するまで待機する（ステップＳ４５）。
【０２４３】
Ｓｉｎｋは、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｓｐｏｎｓｅを送信した後、Ｓｏｕｒｃｅに対してＭＯＶＥ用のＡＫＥ処理を要求する（ステップＳ６３）。
【０２４４】
そして、ＳｉｎｋとＳｏｕｒｃｅ間では、ＭＯＶＥ用のＡＫＥ手続きが開始され、互いにＭＯＶＥ用のＡＫＥ処理を実行する（ステップＳ４６、Ｓ６４）。ＭＯＶＥ用のＡＫＥの認証に成功すると（ステップＳ４７、Ｓ６５）、ＳｏｕｒｃｅはＭＯＶＥ用の鍵と鍵ＩＤを生成してＳｉｎｋに送信し（ステップＳ４８）、ＳｉｎｋはＳｏｕｒｃｅからＭＯＶＥ用の鍵と鍵ＩＤを受信する（ステップＳ６６）。但し、ＳｏｕｒｃｅとＳｉｎｋ間でＭＯＶＥ用のＡＫＥの認証に失敗すると、ＳｏｕｒｃｅとＳｉｎｋはともに、後続の処理をすべてスキップして、本処理ルーチン全体を終了する。
【０２４５】
続いて、Ｓｏｕｒｃｅは、Ｓｉｎｋに対してＭＯＶＥによりアップロードしようとするコンテンツに対して「ＭＯＶＥ伝送中」フラグをセットしてから（ステップＳ４９）、当該コンテンツをＭＯＶＥ用の鍵を用いて暗号化し、“ＭＯＶＥ．ｄｔｃｐ．ｃｏｍ：＜ＫｘＭ＿ｌａｂｅｌ＞”というヘッダ情報を伴ったＨＴＴＰ ＰＯＳＴリクエストにより、暗号化コンテンツを送信する（ステップＳ５０）。「ＭＯＶＥ伝送中」フラグをセットすると、当該コンテンツはロック状態となる。そして、ＳｉｎｋからのＨＴＴＰ ＰＯＳＴレスポンスの受信を待機する（ステップＳ５１）。
【０２４６】
Ｓｉｎｋ側では、ＭＯＶＥ用のＡＫＥ手続きを終えると、ＳｏｕｒｃｅからのＨＴＴＰ ＰＯＳＴリクエストを受信待機している（ステップＳ６７）。そして、当該リクエストを受信して、暗号化コンテンツをすべて受け取ると、ＨＴＴＰ ＰＯＳＴレスポンスを返信する（ステップＳ６８）。
【０２４７】
このようにして、ＳｏｕｒｃｅからＳｉｎｋへ暗号化コンテンツを成功裏にアップロードすることができたならば、ＳｏｕｒｃｅはＭＯＶＥ終了処理の受信を待機する（ステップＳ５２）。また、Ｓｉｎｋは、Ｓｏｕｒｃｅに対してＭＯＶＥ終了処理の要求を送信する（ステップＳ６９）。そして、ＳｏｕｒｃｅとＳｉｎｋは、それぞれＭＯＶＥ終了処理手続きを実行して（ステップＳ５３、Ｓ７０）、Ｓｉｎｋ側でコンテンツを有効化するとともに、Ｓｏｕｒｃｅ側の元のコンテンツを削除する。Ｓｏｕｒｃｅ及びＳｉｎｋ間におけるＭＯＶＥ終了処理手続きの動作シーケンスは図１１並びに図１８を参照して既に説明した通りなので、ここでは説明を省略する。
【０２４８】
そして、ＳｏｕｒｃｅとＳｉｎｋは、ＭＯＶＥ終了処理手続きを完了すると（ステップＳ５４、Ｓ７１）、いずれもＭＯＶＥ用の鍵と鍵ＩＤを破棄して（ステップＳ５５、Ｓ７２）、本処理ルーチン全体を終了する。
【０２４９】
図１５Ａ及び図１５Ｂに示したアップロードＭＯＶＥ処理手続の期間中、ＭＯＶＥ対象となるコンテンツを他のＳｉｎｋからＭＯＶＥ要求できないようにロックして、多重ＭＯＶＥの発生を防止する。アップロード形式でコンテンツのＭＯＶＥを行なう場合、Ｓｉｎｋは、サーバに相当するが、保持する個々のコンテンツについてＭＯＶＥ伝送中であるかどうかを、例えば表２（前述）に示したようなテーブルを使って管理することができる（同上）。
【０２５０】
また、Ｓｉｎｋは、ＢＬＯＣＫ ＭＯＶＥモードでアップロードＭＯＶＥ伝送処理が行なわれている期間中は、コンテンツはまだ有効化されていないので、リアルタイムでレンダリングする以外の目的で受信したコンテンツを利用することはできない。リアルタイム・レンダリングの仕組みについては、図７を参照しながら既に説明したので、ここでは説明を省略する。
【０２５１】
なお、ＭＯＶＥ用ＡＫＥ手続き並びにコンテンツ移動（ＭＯＶＥ）手続きの期間中には、ＭＯＶＥ伝送をユーザ操作で取り止める取り消し（Ｃａｎｃｅｌ）や中止（Ａｂｏｒｔ）といった中断処理が起動することがあるが、この点の詳細については後述に譲る。
【０２５２】
そして、ＳｏｕｒｃｅがＨＴＴＰプロトコルのＰＯＳＴリクエストにより、ＨＴＴＰサーバとして動作する所定のＳｉｎｋに対して所望のコンテンツを成功裏にアップロードすることができたならば、アップロードＭＯＶＥ伝送の終了処理手続きを実施して、Ｓｉｎｋ側ではこのアップロードしたコンテンツを有効化すると同時に、Ｓｏｕｒｃｅ側では元のコンテンツの削除を行なう。ＭＯＶＥ終了処理手続きは、図１１並びに図１８に示したものと同様の動作シーケンスに従って実行される（同上）。
【０２５３】
アップロードＭＯＶＥ伝送が終了した後にＳｉｎｋ側でコンテンツを有効化する方法は特に限定されない。有効化すると、Ｓｉｎｋ内のコンテンツ記録ブロックでＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして符号化して記録されたコンテンツの利用が可能となる（例えば、記録時に適用した暗号の解除が可能となり）。この結果、コンテンツ再生ブロックに符号化コンテンツを供給して、ビデオ及びオーディオ信号に変換（ｒｅｎｄｅｒｉｎｇ）して、ディスプレイなどのＡＶ出力部から映像並びに音響出力することができる。あるいは、今度はＳｏｕｒｃｅとして、さらに別のＳｉｎｋに対して、上述と同様にダウンロード又はアップロード形式でＭＯＶＥすることもできる。
【０２５４】
また、アップロードＭＯＶＥ伝送が終了した後にＳｏｕｒｃｅ側で元のコンテンツを削除する方法も特に限定されない。コンテンツを格納したハード・ディスクなどの記録媒体からコンテンツ・データのエンティティ自体を削除する以外に、符号化（暗号化）して記録されているコンテンツのエンティティは残すが復号鍵を再び使用できないようにするのであってもよい。
【０２５５】
なお、Ｓｉｎｋは、コンテンツをＳｏｕｒｃｅからアップロードＭＯＶＥ伝送した後に、今度は自らＳｏｕｒｃｅとしてコンテンツを提供しようとする場合は、ｒｅｓタグ内のＤＴＣＰＯＰ＝ＭＯＶＥを削除する（若しくはｒｅｓ＠ｄｔｃｐ：ｕｐｌｏａｄＩｎｆｏアトリビュートを削除する）とともに、ソケット情報のホスト名とポートを自らのものに変更する必要がある。また、他のＳｉｎｋにコンテンツを持ち出す（ＭＯＶＥ ｏｕｔ）ことを許容する場合には、ｒｅｓタグ内にＭＯＶＥ可能であることを示す文字列“ＭＯＶＥ：１”を記載したａｌｌｏｗｅｄＵｓｅアトリビュートを追加する（若しくは、上記のＤＴＣＰ．ＣＯＭ＿ＦＬＡＧＳ ｐａｒａｍをｒｅｓ＠ｐｒｏｔｏｃｏｌＩｎｆｏアトリビュートの第４フィールドに追加する）。
【０２５６】
図１３に示した動作シーケンスでは、Ｓｉｎｋ側でＭＯＶＥ用ＡＫＥ手続きのためのＴＣＰコネクションを確立するために必要となるソケット情報（ＤＴＣＰ ｓｏｃｋｅｔ Ｉｎｆｏ）を、ＳｏｕｒｃｅはＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔリクエストによって通知している。ところが、この通知方法では、中断したＭＯＶＥ伝送終了手続きを再開する際には、ソケット情報の通知のために、同じコンテンツのアップロードＭＯＶＥ伝送を要求するＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔリクエストを再び発行しなければならず、１回のみＭＯＶＥ伝送を許可するというＤＴＣＰ規格に抵触するおそれがある。
【０２５７】
そこで、本発明者らは、図１３に示した動作シーケンスによる通知方法以外に、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔの処理後に、ＭＯＶＥ用ＡＫＥ手続きを行なうのに先立ち、ＨＴＴＰ ＰＯＳＴリクエストのヘッダにソケット情報（ＤＴＣＰ ｓｏｃｋｅｔ Ｉｎｆｏ）を記載して、ＳｏｕｒｃｅからＳｉｎｋへソケット情報を通知する方法について提案する。例えば、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダを使って、以下のように記載する。
【０２５８】
【数５】
【０２５９】
ＳｉｎｋはＡＫＥ手続きが完了するまでコンテンツの暗号を解けないので、ＳｏｕｒｃｅはこのＰＯＳＴリクエストではまだコンテンツを伝送せず、ＡＫＥ手続きの完了後に伝送するという手順が考えられる。すなわち、ソケット情報を通知するＨＴＴＰ ＰＯＳＴリクエストは、コンテンツを伴わなくても良く、また、図１３とは相違し、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔではソケット情報を送る必要はない。
【０２６０】
図３０には、ＳｏｕｒｃｅがＰＯＳＴリクエストを用いてソケット情報を通知する方法を用いる場合において、ＳｏｕｒｃｅとＳｉｎｋ間でアップロードＭＯＶＥ伝送を行なうための動作シーケンスを示している。
【０２６１】
まず、Ｓｏｕｒｃｅは、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔリクエストを用いて、Ｓｉｎｋに対して、コンテンツの移動先となるオブジェクトの作成を要求する。このとき、Ｓｏｕｒｃｅは、ｒｅｓ＠ｕｐｌｏａｄＩｎｆｏアトリビュートにおいてＭＯＶＥ伝送をベースにしたトランザクションを要求する。これに対し、Ｓｉｎｋは、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔレスポンスのｒｅｓ＠ｉｍｐｏｒｔＵｒｉアトリビュートにおいて、ＨＴＴＰ ＰＯＳＴ用のＵＲＩを返す。
【０２６２】
続いて、Ｓｏｕｒｃｅは、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔレスポンスの記載内容から取得したＵＲＩに対するＨＴＴＰ ＰＯＳＴリクエストを送信して、Ｓｉｎｋに対して認証及び鍵交換用のソケット情報を通知する。ソケット情報は、上述したように、ＣｏｎｔｅｎｔＴｙｐｅとして送られてくる。但し、ソケット情報の通知に使用されるＨＴＴＰ ＰＯＳＴリクエストは、コンテンツを含まない。
【０２６３】
Ｓｉｎｋは、ソケット情報を取得すると、認証及び鍵交換用のＴＣＰコネクションを確立する。そして、Ｓｉｎｋは、ＭＶ−ＩＮＩＴＩＡＴＥコマンドを送信してＭＯＶＥ ＲＴＴ−ＡＫＥプロセスを起動することによって、アップロードＭＯＶＥ伝送を初期化する。
【０２６４】
ＭＯＶＥ ＲＴＴ−ＡＫＥプロセスが終了すると、ＢＬＫＭＯＶＥ．ｄｔｃｐ．ｃｏｍヘッダ情報を含んだＨＴＴＰ ＰＯＳＴリクエストを送信することで、Ｓｏｕｒｃｅは、暗号化コンテンツの伝送を行なう。
【０２６５】
Ｓｉｎｋは、ＭＯＶＥ対象コンテンツをすべて受け取った後、ＭＶ＿ＦＩＮＡＬＩＺＥコマンドを送信することによって、ＭＯＶＥ伝送終了処理を起動する。ＭＯＶＥ終了処理手続きは、図１１に示した動作シーケンスに従って実施される。
【０２６６】
なお、図３１に示すように、Ｓｏｕｒｃｅから、コンテンツを伴わないＰＯＳＴリクエストのヘッダでソケット情報を送り、Ｓｉｎｋが認証および鍵交換用のＴＣＰコネクションを確立して、ＡＫＥ手続を終了した後に、ＰＯＳＴレスポンスを返すようにしても良い。このような動作シーケンスの場合、ＡＫＥ手続きで共有したＫXM_labelをＭＯＶＥ．ｄｔｃｐ．ｃｏｍ（若しくは、ＢＬＫＭＯＶＥ．ｄｔｃｐ．ｃｏｍ）ヘッダを使い、“ＭＯＶＥ．ｄｔｃｐ．ｃｏｍ：＜ＫXM_label＞”のようにしてＳｉｎｋからのＰＯＳＴレスポンスで送ることで、Ｓｏｕｒｃｅは同時に複数のＭＯＶＥ伝送処理を行なう場合でも、コンテンツの暗号化に適用すべき交換鍵ＫXMを確実に把握することができる。
【０２６７】
また、図３１に示した動作シーケンスと同じ効果を得る別の方法として、複数のＭＯＶＥ処理を行なう場合にＳｉｎｋに通知するソケット情報をユニークにすることで、ＳｉｎｋとＫXMの関係付けを確実に行なうことができる。この場合、ＳｉｎｋはＡＫＥ手続きの完了前にＭＯＶＥ．ｄｔｃｐ．ｃｏｍ（若しくは、ＢＬＫＭＯＶＥ．ｃｏｍ）ヘッダを伴わないＰＯＳＴレスポンスを送ることもできる。なお、この後のコンテンツ伝送は新たなＰＯＳＴリクエストとしてではなく、ＡＫＥ手続き前のＰＯＳＴリクエストの手続きとして送る方法も考えられる。
【０２６８】
また、ここで説明したソケット情報の通知方法は、アップロードＭＯＶＥ伝送だけでなく、アップロード形式のＣＯＰＹ伝送においても同様に適用することができる。
【０２６９】
図３２Ａ及び図３２Ｂには、図３１に示した動作シーケンスによってＨＴＴＰクライアントとしてのＳｏｕｒｃｅからＨＴＴＰサーバとしてのＳｉｎｋへコンテンツをアップロードＭＯＶＥ伝送する場合のＳｏｕｒｃｅ及びＳｉｎｋがそれぞれ実行する処理動作をフローチャートの形式でまとめている。
【０２７０】
Ｓｏｕｒｃｅは、コンテンツのアップロード先のサーバとして動作するＳｉｎｋを発見すると（ステップＳ１５１）、Ｓｉｎｋに対してコンテンツの保管場所の作成を要求するべく、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｑｕｅｓｔを送信して（ステップＳ１５２）、そのレスポンスの受信を待機する（ステップＳ１５３）。
【０２７１】
Ｓｉｎｋは、ＳｏｕｒｃｅからＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｑｕｅｓｔを受信すると（ステップＳ１７１）、これに対するレスポンスを返信する（ステップＳ１７２）。
【０２７２】
Ｓｏｕｒｃｅは、ＳｉｎｋからＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｓｐｏｎｓｅを受信すると、続いてＭＯＶＥ対象となるコンテンツを決定する（ステップＳ１５４）。そして、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダを伴うＨＴＴＰ ＰＯＳＴリクエストでＳｉｎｋにソケット情報を送信した後（ステップＳ１５５）、ＭＯＶＥ用のＡＫＥ要求を受信するまで待機する（ステップＳ１５６）。
【０２７３】
Ｓｉｎｋは、ソケット情報を伴うＨＴＴＰ ＰＯＳＴリクエストをＳｏｕｒｃｅから受信すると（ステップＳ１７３）、当該リクエストから得たソケットに対するＴＣＰコネクションを確立して（ステップＡ１７４）、Ｓｏｕｒｃｅに対してＭＯＶＥ用のＡＫＥ処理を要求する（ステップＳ１７５）。
【０２７４】
そして、ＳｉｎｋとＳｏｕｒｃｅ間では、ＭＯＶＥ用のＡＫＥ手続きが開始され、互いにＭＯＶＥ用のＡＫＥ処理を実行する（ステップＳ１５７、Ｓ１７６）。ここで、ＭＯＶＥ用のＡＫＥの認証に成功すると（ステップＳ１５８、Ｓ１７７）、Ｓｏｕｒｃｅは、ＭＯＶＥ用の鍵と鍵ＩＤを生成してＳｉｎｋに送信する（ステップＳ１５９）。但し、ＳｏｕｒｃｅとＳｉｎｋ間でＭＯＶＥ用のＡＫＥの認証に失敗すると、ＳｏｕｒｃｅとＳｉｎｋはともに、後続の処理をすべてスキップして、本処理ルーチン全体を終了する。
【０２７５】
Ｓｉｎｋは、ＳｏｕｒｃｅからＭＯＶＥ用の鍵と鍵ＩＤを受信すると（ステップＳ１７８のＹｅｓ）、ＢＬＫＭＯＶＥ．ｄｔｃｐ．ｃｏｍヘッダを伴うＨＴＴＰ ＰＯＳＴレスポンスで鍵ＩＤを送信する（ステップＳ１７９）。
【０２７６】
そして、Ｓｏｕｒｃｅは、Ｓｉｎｋから鍵ＩＤを伴うＨＴＴＰ ＰＯＳＴレスポンスを受信すると（ステップＳ１６０のＹｅｓ）、この鍵ＩＤに対応するＭＯＶＥ伝送用の鍵を以後の処理用に選択する（ステップＳ１６１）。
【０２７７】
続いて、Ｓｏｕｒｃｅは、Ｓｉｎｋに対してアップロードＭＯＶＥ伝送しようとするコンテンツに対して「ＭＯＶＥ伝送中」フラグをセットしてから（ステップＳ１６２）、当該コンテンツをＭＯＶＥ伝送用の鍵を用いて暗号化し、ソケット情報を伴うＨＴＴＰ ＰＯＳＴリクエストのメッセージ・ボディとして送信する（ステップＳ１６３）。「ＭＯＶＥ伝送中」フラグをセットすると、当該コンテンツはロック状態となる。そして、ＳｉｎｋからのＨＴＴＰ ＰＯＳＴレスポンスの受信を待機する（ステップＳ１６４）。
【０２７８】
Ｓｉｎｋ側では、ＭＯＶＥ用のＡＫＥ手続きを終えると、ＳｏｕｒｃｅからのＨＴＴＰ ＰＯＳＴリクエストのメッセージ・ボディとしての暗号化コンテンツを受信待機している（ステップＳ１８１）。そして、当該リクエストを受信して、暗号化コンテンツを受け取ると、ＨＴＴＰ ＰＯＳＴレスポンスを返信する（ステップＳ１８２）。
【０２７９】
このようにして、ＳｏｕｒｃｅからＳｉｎｋへ暗号化コンテンツを成功裏にアップロードすることができたならば、ＳｏｕｒｃｅはＭＯＶＥ終了処理の受信を待機する（ステップＳ１６５）。また、Ｓｉｎｋは、Ｓｏｕｒｃｅに対してＭＯＶＥ終了処理の要求を送信する（ステップＳ１８３）。そして、ＳｏｕｒｃｅとＳｉｎｋは、それぞれＭＯＶＥ終了処理手続きを実行して（ステップＳ１６６、Ｓ１８４）、Ｓｉｎｋ側でコンテンツを有効化するとともに、Ｓｏｕｒｃｅ側の元のコンテンツを削除又は無効化する。Ｓｏｕｒｃｅ及びＳｉｎｋ間におけるＭＯＶＥ終了処理手続きの動作シーケンスは図１１並びに図１８を参照して既に説明した通りなので、ここでは説明を省略する。
【０２８０】
そして、ＳｏｕｒｃｅとＳｉｎｋは、ＭＯＶＥ終了処理手続きを完了すると（ステップＳ１６７、Ｓ１８５）、いずれもＭＯＶＥ伝送用の鍵と鍵ＩＤを破棄して（ステップＳ１６８、Ｓ１８６）、本処理ルーチン全体を終了する。
【０２８１】
ここで、ＳｏｕｒｃｅからＳｉｎｋへコンテンツのエンティティが成功裏にアップロードＭＯＶＥ伝送されたにも拘らず、一方の機器の電源遮断などによりＭＯＶＥ伝送の終了処理シーケンスが途切れてしまう可能性がある。ＭＯＶＥ伝送の終了処理の中断（ｉｎｔｅｒｒｕｐｔｅｄ）によって、Ｓｏｕｒｃｅ及びＳｉｎｋの双方において移動したコンテンツを利用できなくなるおそれがある。このようにＭＯＶＥ終了処理手続きが中断したときには、図１９〜２１に示した処理手順に従って再開して、ＳｉｎｋとＳｏｕｒｃｅの双方でコンテンツが無効になることを避けることができる。
【０２８２】
アップロードＭＯＶＥ伝送の終了処理の再開を可能にするために、Ｓｉｎｋ及びＳｏｕｒｃｅの各々では、アップロードＭＯＶＥ伝送の終了処理を開始する際に、ＮＶＲＡＭなどの不揮発性メモリを用いて、再開処理に必要となるデータを保存するようにしている。Ｓｉｎｋ側では、ＣＭＤ１すなわちＭＶ＿ＦＩＮＡＬＩＺＥコマンドで用いるパラメータ（ＫxM_label）と、ＭＡＣ６Ａを不揮発的に格納する。
【０２８３】
また、Ｓｏｕｒｃｅは中断したＣｏｍｍｉｔｍｅｎｔ情報を持つ場合、対応するＳｉｎｋに対してソケット情報を通知し、処理の再開を促す必要がある。このためには、Ｓｏｕｒｃｅは、Ｃｏｍｍｉｔｍｅｎｔ処理の過程において、Ｓｉｎｋ発見に必要となるＵＵＩＤ、及びＰＯＳＴの宛て先ＵＲＩを発見するのに必要となるＯｂｊｅｃｔ ＩＤ、さらには鍵ＩＤであるＫxM_labelとＭＡＣ５Ｂ、ＭＡＣ６Ｂを不揮発的に格納する。再開処理は、基本的にはＳｉｎｋ側が起動する。
【０２８４】
ＨＴＴＰ ＰＯＳＴリクエストのヘッダにソケット情報（ＤＴＣＰ ｓｏｃｋｅｔ Ｉｎｆｏ）を記載して、ＳｏｕｒｃｅからＳｉｎｋへソケット情報を通知するという上記の方法によれば、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔを使ってソケット情報を通知する方法とは異なり、中断したＭＯＶＥ処理を再開する際であっても、Ｓｉｎｋは問題なくＭＯＶＥ対象となるコンテンツに関するソケット情報を得ることができる。
【０２８５】
図３３には、ＭＯＶＥ伝送終了処理を再開する際に、Ｓｉｎｋ及びＳｏｕｒｃｅ間でＴＣＰコネクションを確立するための処理手順をフローチャートの形式で示している。
【０２８６】
Ｓｏｕｒｃｅは、不揮発的に記憶しておいたＵＵＩＤを１つ選択し（ステップＳ１９１）、ＵＰｎＰのデバイス発見のプロトコルにより、不揮発的に記憶しておいたＵＵＩＤと一致する機器（Ｓｉｎｋ）が発見されたかどうかをチェックする（ステップＳ１９２）。そして、Ｓｏｕｒｃｅは、不揮発的に記憶しておいたものと同じＵＵＩＤを持つＳｉｎｋを発見すると、その機器に対してＣＤＳ：：ＢｒｏｗｓｅリクエストをＯｂｊｅｃｔＩＤ指定付きで送信する（ステップＳ１９３）。
【０２８７】
一方、Ｓｉｎｋは、ＳｏｕｒｃｅからＣＤＳ：：Ｂｒｏｗｓｅリクエストを受信すると（ステップＳ２０１）、ＣＤＳ：：Ｂｒｏｗｓｅレスポンスを返信する（ステップＳ２０２）。
【０２８８】
Ｓｏｕｒｃｅは、ＳｉｎｋからＣＤＳ：：Ｂｒｏｗｓｅレスポンスを受け取ると（ステップＳ１９４のＹｅｓ）、当該レスポンスの記述内容からソケット情報の送信先となるｒｅｓ＠ｉｍｐｏｒｔＵｒｉを取得する（ステップＳ１９５）。そして、ソケット情報をＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダに含むＨＴＴＰ ＰＯＳＴリクエストをＳｉｎｋに送信する（ステップＳ１９６）。
【０２８９】
Ｓｉｎｋは、Ｓｏｕｒｃｅからソケット情報を伴うＨＴＴＰ ＰＯＳＴリクエストを受信すると（ステップＳ２０３）、当該リクエストに含まれるソケット情報を参照して、Ｓｏｕｒｃｅとの間でＡＫＥコマンドの通信用のＴＣＰコネクションを確立する（ステップＳ２０４）。そして、このＴＣＰコネクションを利用して、図１９〜２１に示した処理手順に従って、中断されたＭＯＶＥ伝送終了処理を再開することができる。
【０２９０】
Ｃ−３．ＢＬＯＣＫ ＭＯＶＥのＣＡＮＣＥＬ並びにＡｂｏｒｔ
上述したようなダウンロード及びアップロードのうちいずれの形式でコンテンツをＭＯＶＥする場合であっても、Ｓｉｎｋは、Ｓｏｕｒｃｅに対しＭＯＶＥ終了処理用コマンドＣＭＤ１を送信する前であれば、ＭＯＶＥ処理を取り消し（ｃａｎｃｅｌ）又は中止（ａｂｏｒｔ）することができる。
【０２９１】
Ｓｏｕｒｃｅ並びにＳｉｎｋはともに、相手に対してＭＶ−ＣＡＮＣＥＬサブファンクションを送信することによって、ＭＯＶＥ処理手続を取り消す（ＣＡＮＣＥＬする）ことができる。
【０２９２】
本実施形態では、ＭＯＶＥ処理手続きのＣＡＮＣＥＬは、ＡＫＥ手続きの一部として実装する。ＡＫＥ手続きのためのＴＣＰコネクションは、通常、Ｓｉｎｋからのトリガによって確立される。コンテンツのストリーミングやコピーを行なう通常のコンテンツ伝送手続きでは、ＡＫＥにより鍵を共有するとＡＫＥ用のＴＣＰコネクションを切断する。しかしながら、ここでは、ＭＯＶＥ処理手続き中にＳｏｕｒｃｅ側からもＭＶ−ＣＡＮＣＥＬサブファンクションを送信できるようにするために、ＡＫＥ用のＴＣＰコネクションを保持しておく必要がある。
【０２９３】
Ｓｏｕｒｃｅは、ＭＯＶＥ終了処理手続きを開始する前にＭＶ−ＣＡＮＣＥＬサブファンクションを送信し又は受信すると、ＭＯＶＥ処理手続きを終了させるとともに、ＭＯＶＥ対象となっていたコンテンツのロック状態を解除し（具体的には、表２中で該当コンテンツの状態をＭＯＶＥ可能に戻す）、当該コンテンツに対する他のＭＯＶＥ要求のために解放する。また、ＭＯＶＥ処理手続の終了に併せて、Ｓｏｕｒｃｅは交換鍵ＫXMを消滅させる。これ以降は、Ｓｉｎｋからの当該終了したＭＯＶＥ処理手続きに関するリクエストを拒絶するようになる。
【０２９４】
また、Ｓｉｎｋは、ＭＯＶＥ終了処理手続きを開始する前にＭＶ−ＣＡＮＣＥＬサブファンクションを送信し又は受信すると、ＭＯＶＥ処理手続きを終了させるとともに、自分にＭＯＶＥされたコンテンツを削除する。このＭＯＶＥ処理手続の終了に併せて、Ｓｉｎｋは交換鍵ＫXMを消滅させる。
【０２９５】
また、ＳｏｕｒｃｅとＳｉｎｋはともに、ＭＯＶＥ終了処理が開始する前にＳｏｕｒｃｅとＳｉｎｋ間の通信が途切れると、ＭＯＶＥ処理手続きを中止（ａｂｏｒｔ）することができる。この場合のＳｏｕｒｃｅとＳｉｎｋは、ＭＶ−ＣＡＮＣＥＬを送信又は受信したときと同様の振る舞いを行なう。
【０２９６】
Ｄ．ＭＯＶＥモード詐称攻撃の対策
ＤＴＣＰ−ＩＰでは、ＳｏｕｒｃｅとＳｉｎｋ間の伝送路上にパーソナル・コンピュータなどで構成される不正なプロキシを設置することで、通信内容の改ざんが容易に行なわれてしまう。とりわけ、ＳｏｕｒｃｅとＳｉｎｋ間でケイパビリティの確認手続き（図１６〜１７を参照のこと）を経てＢＬＯＣＫ ＭＯＶＥを開始するようなシステムにおいては、その確認手続きの実装が必須でない場合、ＳｏｕｒｃｅがＢＬＯＣＫ ＭＯＶＥに対応しているにも拘らず、プロキシはＳｏｕｒｃｅがＢＬＯＣＫ ＭＯＶＥに非対応であるとＳｉｎｋに偽り、ＳｉｎｋにＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥを行なわせることができる。図２２に示す動作シーケンス例では、プロキシは、ＳｉｎｋからのＢＬＯＣＫ ＭＯＶＥ対応であることを記載したＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥメッセージをＳｏｕｒｃｅにそのまま伝達するが、ＳｏｕｒｃｅからのＢＬＯＣＫ ＭＯＶＥ対応であることを記載したＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥメッセージを改竄して、ＢＬＯＣＫ ＭＯＶＥの要求を拒否し（Ｒｅｊｅｃｔｅｄ）、ＳｏｕｒｃｅがＢＬＯＣＫ ＭＯＶＥ非対応であると偽る。この場合、Ｓｏｕｒｃｅ側はＳｉｎｋからの要求に従ってＢＬＯＣＫ ＭＯＶＥモードでコンテンツ送信処理を行なうが、ＳｉｎｋはＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥモードに切り替わってコンテンツ受信処理を行なうことになる。
【０２９７】
このようなＭＯＶＥモード詐称攻撃が仕掛けられると、Ｓｉｎｋ側では、Ｓｏｕｒｃｅからデータを受け取る度に逐次的に有効化していくとともに、コンテンツ伝送処理が終了した時点でプロキシがＳｏｕｒｃｅに対してコンテンツ伝送処理の取り消しを行なうことで、ＳｏｕｒｃｅとＳｉｎｋの双方で有効なコンテンツが存在するというＤＴＣＰ−ＩＰの規定に抵触する事態が生じる。
【０２９８】
そこで、本実施形態に係るコンテンツ伝送システムは、ＳｏｕｒｃｅとＳｉｎｋ間で確認されたケイパビリティを詐称してＳｉｎｋ側のＭＯＶＥモードが偽装されることや、何らかの手段によりＭＯＶＥ伝送であることを装ってコンテンツのコピー伝送を行なうことを防止するための幾つかの方法を適用するようにしている。
【０２９９】
例えば、プロキシがＳｏｕｒｃｅ機器からのＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥメッセージを改ざんしてＢＬＯＣＫ ＭＯＶＥの要求を拒否し（Ｒｅｊｅｃｔｅｄ）、ＳｏｕｒｃｅがＢＬＯＣＫ ＭＯＶＥ非対応であると偽った場合であっても、その後ＡＫＥ手続きにおいて、ＳｉｎｋがＳｏｕｒｃｅに対して設定したＭＯＶＥモードを通知し、Ｓｏｕｒｃｅはケイパビリティの確認手続きを経て決定した自分のＭＯＶＥモードと照合することによって、詐称が行なわれているかどうかをチェックすることができる。あるいは図８中のＳｏｕｒｃｅ及びコンテンツの選択手続きや図１２中のＳｉｎｋ及びコンテンツの選択手続きにおいて、ｓｉｎｋに対してＭＯＶＥによるコンテンツ伝送を行なうことを正しく理解させ、過ってＣＯＰＹ伝送を行なわせないようにする。
【０３００】
図２３に示す動作シーケンス例では、Ｓｉｎｋは、ＡＫＥ認証手続き内で行なわれるチャレンジ・レスポンスを利用して、Ｓｏｕｒｃｅに送るレスポンスの中に自分の動作モードに関する情報を含める。この際、署名で保護される情報にＭＯＶＥモードの情報を含めることが望ましい。このレスポンスを受信したＳｏｕｒｃｅは、自分が設定しているＢＬＯＣＫ ＭＯＶＥモードとは相違することから、ＭＯＶＥモードの詐称が行なわれ、ＳｏｕｒｃｅとＳｉｎｋ間の伝送路が危険に晒されていることを気づくことができる。そして、Ｓｏｕｒｃｅは、交換鍵ＫxをＳｉｎｋに送らず、このような危険な伝送路でコンテンツ伝送を開始することなく、ＭＯＶＥ処理を終了する。
【０３０１】
また、図２４には、図２３に示した動作シーケンスの変形例を示している。図示のシーケンス例では、Ｓｉｎｋは、ＡＫＥ認証手続き内でＳｏｕｒｃｅに送るレスポンス中で、署名で保護される情報にＭＯＶＥモードの情報を含める。このレスポンスを受信したＳｏｕｒｃｅは、自分が設定しているＢＬＯＣＫ ＭＯＶＥモードとは相違することから、ＭＯＶＥモードの詐称が行なわれていることを気づくと、ＢＬＯＣＫ ＭＯＶＥモードからＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥモードに切り替わり、交換鍵ＫxをＳｉｎｋに送る。そして、ＳｏｕｒｃｅとＳｉｎｋはそれぞれ、交換鍵Ｋxに所定の演算を施してコンテンツ暗号鍵Ｋcを作成し、ＭＯＶＥ対象となるコンテンツの暗号化伝送を開始する。
【０３０２】
ＭＯＶＥモードの詐称を防止する他の方法として、交換鍵Ｋxをスクランブルする方法をＭＯＶＥモード毎に切り替える方法が挙げられる。図２５には、この場合の動作シーケンス例を示している。Ｓｏｕｒｃｅ側では、ＢＬＯＣＫ ＭＯＶＥを行なう際には、交換鍵Ｋxでスクランブルに使うワンタイム鍵をハッシュ関数で処理して使う。すると、ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥモード下にあるＳｉｎｋは、交換鍵Ｋx用のデスクランブル方法ではＢＬＯＣＫ ＭＯＶＥ用の交換鍵ＫxMを共用することができなくなる。すなわち、Ｓｉｎｋは、ＢＬＯＣＫ ＭＯＶＥモード以外では交換鍵Ｋx用のデスクランブルが禁止され、正しいコンテンツ暗号鍵Ｋcを作成できないので、ＭＯＶＥされたコンテンツを復号できない。
【０３０３】
また、ＭＯＶＥモードの詐称を防止するさらに他の方法として、交換鍵Ｋxからコンテンツ暗号鍵Ｋcを生成する計算式をＭＯＶＥモード毎に切り替える方法が挙げられる。図２６には、この場合の動作シーケンス例を示している。Ｓｏｕｒｃｅ側では、ＢＬＯＣＫ ＭＯＶＥを行なう際には、交換鍵ＫxMからコンテンツ暗号鍵Ｋcを生成するための計算式に含まれる定数を特別な値に変更する。すると、ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥモード下にあるＳｉｎｋ側では、通常の計算式に従って交換鍵Ｋxから計算しても、正しいコンテンツ暗号鍵Ｋcを作成できないので（言い換えれば、交換鍵ＫxMからコンテンツ暗号鍵Ｋcを計算することが禁止されているので）、ＭＯＶＥされたコンテンツを復号できない。
【０３０４】
よって、上述したいずれかの対策を講じることで、不正なプロキシが伝送路に介在する場合であっても、ＳｏｕｒｃｅとＳｉｎｋの双方で有効なコンテンツが存在するというＤＴＣＰ−ＩＰの規定に抵触する事態を回避することができる。
【０３０５】
図１６には、ＭＯＶＥ伝送モード詐称攻撃の対策としてＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥシーケンスについて説明したが、図２３〜図２６に示したような対策によってＭＯＶＥ伝送モード詐称攻撃を十分に防ぐことができ、これらの場合はＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥシーケンスを通じたセキュアな情報交換手続は不要となる。
【産業上の利用可能性】
【０３０６】
以上、特定の実施形態を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
【０３０７】
本発明の適用例として、ＳｏｕｒｃｅとＳｉｎｋ間で行なわれるＨＴＴＰプロトコルを利用したコンテンツ伝送を挙げることができるが、本発明の要旨はこれに限定されない。著作権やその他の目的で保護が必要となる情報コンテンツを所定のコピー制御情報に従って暗号化伝送する他のあらゆるコンテンツ伝送システム、あるいはコピー制御やコンテンツの暗号化を行なわないシステムであっても、移動元にデータを残さずに機器間でデータを移動させる際に、同様に本発明を適用することができる。
【０３０８】
要するに、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、特許請求の範囲を参酌すべきである。
【符号の説明】
【０３０９】
１０…ＤＴＣＰ−ＩＰ認証ブロック
１１…ＡＫＥブロック
１２…メッセージ・ダイジェスト生成ブロック
１３…コンテンツ復号ブロック
２０…ＤＴＣＰ−ＩＰコンテンツ受信ブロック
２１…ＨＴＴＰクライアント・ブロック
２２…ＨＴＴＰリクエスト管理ブロック
２３…ＨＴＴＰレスポンス管理ブロック
３０…コンテンツ再生／記録ブロック
４０…ＤＴＣＰ−ＩＰ認証ブロック
４１…ＡＫＥブロック
４２…メッセージ・ダイジェスト生成ブロック
４３…コンテンツ暗号化部ロック
５０…ＤＴＣＰ−ＩＰコンテンツ送信ブロック
５１…ＨＴＴＰサーバ・ブロック
５２…ＨＴＴＰリクエスト管理ブロック
５３…ＨＴＴＰレスポンス管理ブロック
６０…コンテンツ管理ブロック
【技術分野】
【０００１】
本発明は、デジタル化されたＡＶデータなどのコンテンツを機器間で伝送するコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムに係り、特に、著作権保護やその他の目的でコピーが制限されたコンテンツを機器間で暗号化伝送するコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムに関する。
【０００２】
さらに詳しくは、本発明は、ＤＴＣＰに準拠した情報機器同士で暗号化コンテンツの伝送手続きを実行するコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムに係り、特に、ＤＴＣＰ ＭＯＶＥ機能を用いてＳｏｕｒｃｅからＳｉｎｋへコンテンツを移動するコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムに関する。
【背景技術】
【０００３】
情報技術の普及に伴い、ＡＶコンテンツのほとんどがデジタル化されており、ＣＤやＤＶＤなどのデジタル・コンテンツを記録再生するメディアが広く利用されている。また、最近では、ＨＤＤレコーダやＨＤＤ搭載ＤＶＤレコーダなど、コンテンツをデジタル記録する機器が家庭内にも浸透してきている。さらには、ネットワークを経由した映像や音楽などのコンテンツの流通・配信サービスが盛んとなり、ＣＤやＤＶＤなどのメディアの移動なしに、ネットワークを経由して遠隔端末間でコンテンツ配信が行なわれている。
【０００４】
しかしながら、デジタル化されたコンテンツはコピーや改竄などの不正な操作が比較的容易であることから、個人的又は家庭的なコンテンツの使用を許容しながら不正使用に対する防御が必要である。とりわけ、国内では２０１１年の地上アナログ放送停波に向けてアナログ放送受信機からデジタル放送受信機への置き換えが急速に進んでおり、家庭内のＡＶコンテンツのデジタル化に対してコンテンツの保護を技術的に実現することが必須と考えられている。
【０００５】
日本国内では、ＡＲＩＢ（Ａｓｓｏｃｉａｔｉｏｎ ｏｆ Ｒａｄｉｏ Ｉｎｄｕｓｔｒｉｅｓ ａｎｄ Ｂｕｓｉｎｅｓｓｅｓ：電波産業会）が中心となってデジタル放送に関する標準化が進められ、デジタル衛星放送、デジタル地上波放送、並びにデジタルＣＡＴＶにおいてＭＰＥＧ２システム（例えば、非特許文献１を参照のこと）を採用するとともに、「１世代のみコピー可」（コピーワンス）といったコピー制御機能の導入を義務付け、厳しいコンテンツ保護規定を設けている（例えば、非特許文献２、非特許文献３を参照のこと）。
【０００６】
また、デジタル伝送コンテンツの保護に関する業界標準的な技術として、ＤＴＬＡ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｌｉｃｅｎｓｉｎｇ Ａｄｍｉｎｉｓｔｒａｔｏｒ）が開発したＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）が挙げられ、コピー制御を始め著作権が保護された形でコンテンツを伝送させるための仕組みについて規定されている（例えば、非特許文献４を参照のこと）。
【０００７】
ＤＴＣＰでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決められている。その規定は、要約すれば、ＤＴＣＰ準拠機器はＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）など取り扱いが容易な圧縮コンテンツを非暗号の状態で機器外に送出しないことと、暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ：ＡＫＥ）アルゴリズムに従って行なうこと、並びにＡＫＥコマンドにより鍵交換を行なう機器の範囲を制限することなどを取り決めている。
【０００８】
コンテンツ提供元であるサーバ（Ｓｏｕｒｃｅ）とコンテンツ提供先であるクライアント（Ｓｉｎｋ）は、ＡＫＥコマンドの送受信により、認証手続きを経て鍵を共有化し、その鍵を用いて伝送路を暗号化してコンテンツの伝送を行なう。したがって、不正なクライアントは、サーバとの認証に成功しないと暗号鍵を取得できないから、コンテンツを享受することはできない。
【０００９】
ＤＴＣＰは、原初的には、ＩＥＥＥ１３９４などを伝送路に用いたホーム・ネットワーク上におけるデジタル・コンテンツの伝送について規定している。最近では、ＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）に代表されるように、家庭内においても、デジタル化されたＡＶコンテンツをＩＰネットワーク経由で流通させようという動きが本格的になっていることから、ＩＰネットワークに対応したＤＴＣＰ技術、すなわちＤＴＣＰ−ＩＰ（ＤＴＣＰ ｍａｐｐｉｎｇ ｔｏ ＩＰ）の開発が進められている。
【００１０】
ＤＴＣＰ−ＩＰは、ＤＴＣＰ技術をＩＰネットワークに移植した同様の技術であるが、伝送路にＩＰネットワークを使用すること、暗号化されたコンテンツの伝送にＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＲＴＰ（Ｒｅａｌ−Ｔｉｍｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）といった、ＩＰネットワーク上で実装されたコンテンツ伝送用プロトコルを使用するという点で、ＩＥＥＥ１３９４ベースで規定された本来のＤＴＣＰとは相違する。例えば、ＨＴＴＰの手続きに従ってコンテンツを伝送する場合、ＳｏｕｒｃｅがＨＴＴＰサーバとなり、ＳｉｎｋがＨＴＴＰクライアントとなって、ＨＴＴＰのためのＴＣＰ／ＩＰコネクションが作成され、暗号化コンテンツのダウンロード伝送が行なわれる（アップロード伝送を行なうときには、ＳｏｕｒｃｅがＨＴＴＰクライアントとなりＳｉｎｋがＨＴＴＰサーバとなる）。
【００１１】
ホーム・ネットワークがルータ経由でインターネットなどの外部のＩＰネットワークに接続されると、データの盗聴、改竄、コンテンツの不正コピーなどの危惧がある。また、ＳｏｕｒｃｅとＳｉｎｋ間の伝送路上にパーソナル・コンピュータなどで構成される不正なプロキシを設置することで、コンテンツの不正利用が容易に行なわれてしまう。このため、ＤＴＣＰ−ＩＰでは、ＡＫＥコマンドのＴＴＬ（Ｔｉｍｅ Ｔｏ Ｌｉｖｅ）すなわちＩＰルータのホップ回数に上限を設けることで、コンテンツの利用範囲を個人的又は家庭の範囲内に制限するなど、コンテンツを保護しながらネットワーク伝送するためのさらなる方法を規定している（例えば、非特許文献５を参照のこと）。
【００１２】
著作権保護に対応したコンテンツ伝送を行なう際、コンテンツ保護に関するコンテンツ属性を指定する必要がある。ＤＴＣＰ−ＩＰでは、コンテンツ伝送用のパケット（ＰＣＰ）のヘッダ部に記述するＥ−ＥＭＩ（Ｅｘｔｅｎｄｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｍｏｄｅ Ｉｎｄｉｃａｔｏｒ）と、Ｅｍｂｅｄｄｅｄ ＣＣＩ（Ｃｏｐｙ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）という２つのメカニズムにより、コンテンツに付随したコピー制御情報の伝送を実現している。
【００１３】
Ｅｍｂｅｄｄｅｄ ＣＣＩは、暗号化するコンテンツ・ストリームの一部として（すなわちパケットのペイロードに埋め込んで）伝送されるコピー制御情報である。コンテンツ・ストリームをタンパリングすると誤った暗号解読を行なうことになるので、Ｅｍｂｅｄｄｅｄ ＣＣＩの完全性を保証することができる。一方のＥ−ＥＭＩは、平文状態のヘッダ部に記載され、パケットのヘッダでコンテンツ・ストリームに関するコピー制御情報を示すことにより、容易にアクセスできると同時にセキュリティを実現する。Ｅ−ＥＭＩは、暗号モードを記述する４ビットのフィールドで構成され、その値はコピー制御情報の７種類に対応する。ビット値定義を下表に示しておく。但し、同表では未使用となっている９つのＥ−ＥＭＩ値は将来の拡張用に予備となっている。
【００１４】
【表１】
【００１５】
Ｓｏｕｒｃｅとして動作する機器は、コンテンツ・ストリームの特性に従って正しい暗号モードを選択し、これに基づいてＥ−ＥＭＩを設定する。これに対し、Ｓｉｎｋとして動作する機器は、コンテンツを伝送するパケットのヘッダ中のＥ−ＥＭＩで指定される正しい暗号解読モードを選択する。また、Ｓｉｎｋとして動作する機器は、Ｅ−ＥＭＩやＥｍｂｅｄｄｅｄ ＣＣＩで指定されている通りに、受信コンテンツを符号化して一旦蓄積し、続いてＳｏｕｒｃｅとして動作するときにはコピー制御情報に従って２次的なコンテンツ伝送動作を制御する。コピー制御の種類として、以下が挙げられる。
【００１６】
Ｃｏｐｙ Ｆｒｅｅ：著作権自体は留保するが、ＤＴＣＰを用いたコピー制御は行なわない。
Ｃｏｐｙ Ｎｅｖｅｒ：決してコンテンツを複製してはならない。
Ｃｏｐｙ Ｏｎｅ Ｇｅｎｅｒａｔｉｏｎ：１回だけ（Ｏｎｅ Ｇｅｎｅｒａｔｉｏｎ）だけコピーが許容される。
Ｎｏ Ｍｏｒｅ Ｃｏｐｉｅｓ：もはやコピーが許されない。
【００１７】
上記のうちＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓは、元はＣｏｐｙ Ｏｎｅ Ｇｅｎｅｒａｔｉｏｎに設定されたコンテンツを１回（ｆｉｒｓｔ ｇｅｎｅｒａｔｉｏｎ）だけコピーしたことによりコピーが許可されなくなった状態である。ＤＴＣＰ−ＩＰでは、Ｎｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして符号化されたコンテンツを伝送する手段として、ＭＯＶＥ機能が用意されている（例えば、非特許文献５、非特許文献６を参照のこと）。ネットワーク通信におけるＭＯＶＥは、機器間でデータを移動させることに相当し、基本的に移動元にデータを残さない。ＤＴＣＰ−ＩＰで言うＭＯＶＥ機能は、Ｓｉｎｋは受信したコンテンツをＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして符号化して扱うこと、及び、Ｓｏｕｒｃｅ側では伝送した後のコンテンツを消去又は利用不能にするという条件の下で、暗号化コンテンツをＳｏｕｒｃｅからＳｉｎｋへ伝送することを意味する。例えば、Ｃｏｐｙ Ｏｎｅ Ｇｅｎｅｒａｔｉｏｎのコンテンツが個人のビデオ録画機器（ＰＶＲ）などのＳｏｕｒｃｅにＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして符号化・記録されている場合、ＭＯＶＥ機能を用いることで、上記の条件を満たしながら、Ｃｏｐｙ Ｏｎｅ Ｇｅｎｅｒａｔｉｏｎの状態で符号化して単一のＳｉｎｋに伝送することができる。また、単一のＳｏｕｒｃｅと単一のＳｉｎｋ間でのみ、ＭＯＶＥが許容される。
【００１８】
現状の規定によれば、Ｅ−ＥＭＩでＣ１モード、又はＢ１モードのいずれかを使用してＭＯＶＥ伝送を行なうことができる。Ｓｉｎｋ側では、これらのモードで受け取ったコンテンツを、ＡＫＥ手続きで取得した鍵を用いて復号し、記録することができる。また、Ｓｏｕｒｃｅ側では、送信した瞬間にデータを無効化する必要がある。
【００１９】
ＭＯＶＥ機能によれば、有体物をある場所から別の場所へ移動するのと同様に、ＭＯＶＥしたコンテンツのエンティティ数が増えることはない。逆に言えば、伝送対象となるコンテンツが、ＳｏｕｒｃｅとＳｉｎｋに同時に存在しない（若しくは利用可能とならない）ことを保証する必要がある。したがって、ＳｏｕｒｃｅからＳｉｎｋへのコンテンツが複数のメッセージ転送手続きで構成される場合、上述したような、Ｓｏｕｒｃｅ側でコンテンツを消去又は利用不能にするという条件をすべてのメッセージ転送手続にわたって一貫して遵守しなければならない。このため、コンテンツ伝送方法としては、Ｓｏｕｒｃｅ側で送信後のデータを逐次的に利用不能にするとともに、Ｓｉｎｋ側で受信データを逐次的に利用可能にしていくという“ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ”を行なう必要がある。
【００２０】
例えば、コンテンツを複数の領域に分割してそれぞれを別のタイトル鍵で暗号化し、コンテンツ復号化の際に使用される時変鍵を抽出し、タイトル鍵領域の元のタイトル鍵を、抽出した当該時変鍵で順次上書きして前のコンテンツの復号化を不可能にすることによって、ＭＯＶＥ処理した元のコンテンツを安全且つ効率的に削除するコンテンツ管理装置について提案がなされている（例えば、特許文献１を参照のこと）。
【００２１】
ここで、ＳｏｕｒｃｅとＳｉｎｋ間で行なわれているＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥシーケンスがコンテンツ伝送中に障害の発生などにより中断したときに、Ｓｏｕｒｃｅ及びＳｉｎｋのそれぞれにコンテンツが分断されるという問題がある。コンテンツ全体の伝送が成功裏に終わればＳｏｕｒｃｅとＳｉｎｋ間でコンテンツの権利を無事に委譲することができるが、伝送処理の途中で障害が発生すると、伝送が済んだデータ部分はＳｉｎｋ側に存在するが、伝送する前のデータ部分はＳｏｕｒｃｅに残ってしまうため、コンテンツが分断される。ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥを処理中に生じ得る障害として、例えば、コネクション・エラーが発生する、一方の機器の電源が遮断される、コンテンツ格納用のメディアが抜き取られる（あるいはストレージが故障する）、Ｓｉｎｋ側でコンテンツを格納するストレージが満杯になるといった原因が挙げられ、コンテンツが分断される事態は決して希ではない。
【００２２】
１つのコンテンツの移動が複数のメッセージ転送手続きで行なわれる場合、Ｓｏｕｒｃｅがメッセージ転送を行なう毎にＳｉｎｋ側へ移動が終わったデータ部分を逐次的に消去すると、コンテンツ伝送が中断したときに、ＳｏｕｒｃｅとＳｉｎｋのいずれでもコンテンツを回復することができなくなってしまう。ＳｏｕｒｃｅからＳｉｎｋへのコンテンツ伝送が完了した後にＳｏｕｒｃｅ側のコンテンツを一括して消去又は利用不能にするようにすれば、ユーザはコンテンツを消失する心配はない。しかしながら、ＤＴＣＰ−ＩＰで規定されている、ＭＯＶＥ実行時の前提条件（前述）を一貫して遵守したことにならず、コンテンツの著作権保護を危険に晒しかねない。
【００２３】
例えば、汎用バス経由でコンテンツ伝送を行なうＳｏｕｒｃｅとＳｉｎｋの間にコンテンツ移動コントローラを設け、ＭＯＶＥ伝送に際してＳｏｕｒｃｅとＳｉｎｋの両方に重複して存在する再生可能なコンテンツの量が通常の再生時間にして１分を超えてはならないというＤＴＣＰ規格に基づいて、コンテンツ移動コントローラがＳｏｕｒｃｅ及びＳｉｎｋいずれかで不具合を検出すると１分以内にＭＯＶＥを中断し、Ｓｏｕｒｃｅに再生可能な状態で残っている部分で移動動作を再開することによってコンテンツの消失を避けるコンテンツ移動システムについて提案がなされている（例えば、特許文献を参照２のこと）。但し、この場合は、コンテンツ移動コントローラが介在しなければならないことから、装置コストが増大する。また、無線ＬＡＮ上で任意のＤＴＣＰ−ＩＰ機器がＳｏｕｒｃｅ並びにＳｉｎｋとしてそれぞれ動作し、これらＳｏｕｒｃｅ及びＳｉｎｋ間でコンテンツのＭＯＶＥ処理をアドホックに起動する場合には、コンテンツ移動コントローラの配置が困難となり、あるいはコンテンツ移動コントローラの介在が伝送シーケンスのボトルネックとなる。
【００２４】
また、コンテンツを受信完了したＳｉｎｋから返信されるコンテンツの記録状態情報を基にＳｏｕｒｃｅが送信済みのコンテンツを消去することで、Ｓｉｎｋがコンテンツを正常記録できない際のＳｏｕｒｃｅ側でのコンテンツの紛失を防ぐコンテンツ記録システムについて提案がなされている（例えば、特許文献３を参照のこと）。しかしながら、同システムでは、コンテンツ伝送が途切れたことによりコンテンツがＳｏｕｒｃｅとＳｉｎｋで分断してしまった事態については何ら考慮されていない。
【００２５】
また、著作権保護されたデータを他の記録装置に移動する際に、独自の複写暗号鍵で複写データを暗号化して保持しておき、万一移動時の障害などにより移動後のデータが不良の場合は、移動後のデータを無効とし同装置では、複写データから元のデータを復元することにより、著作権保護を行ないながら元のデータの消失を防止する、コンテンツ・データを取り扱う装置について提案がなされている（例えば、特許文献４を参照のこと）。しかしながら、同装置では、移動先にデータが記録されてから元のデータを消去するか、又は移動先でのデータの記録と並行して元のデータを消去するので、コンテンツ伝送が途切れたことによりコンテンツがＳｏｕｒｃｅとＳｉｎｋで分断してしまった事態について十分には考慮されていない。
【先行技術文献】
【特許文献】
【００２６】
【特許文献１】特開２００３−１０１５２９号公報
【特許文献２】特開２００５−１５８０５６号公報
【特許文献３】特開２００５−２９３７３１号公報
【特許文献４】特開２００５−２５０５６７号公報
【非特許文献】
【００２７】
【非特許文献１】ＩＳＯ／ＩＥＣ １３８１８−１ＧＥＮＥＲＩＣ ＣＯＤＩＮＧ ＯＦ ＭＯＶＩＮＧ ＰＩＣＴＵＲＥＳＡＮＤ ＡＳＳＯＣＩＡＴＥＤ ＡＵＤＩＯ：ＳＹＳＴＥＭＳ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｈ．２２２．０
【非特許文献２】ＡＲＩＢ ＴＲ−Ｂ１４ 地上デジタルテレビジョン放送運用規定
【非特許文献３】ＡＲＩＢ ＴＲ−Ｂ１５ ＢＳ／広帯域ＣＳデジタル放送運用規定
【非特許文献４】ＤＴＣＰ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｏｌｕｍｅ １ （Ｉｎｆｏｒｍａｔｉｏｎａｌ Ｖｅｒｓｉｏｎ） Ｒｅｖｉｓｉｏｎ １．４ （ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／）
【非特許文献５】ＤＴＣＰ Ｖｏｌｕｍｅ １ Ｓｕｐｐｌｅｍｅｎｔ Ｅ（Ｖ１ＳＥ） Ｍａｐｐｉｎｇ ＤＴＣＰ ｔｏ ＩＰ （Ｉｎｆｏｒｍａｔｉｏｎａｌ Ｖｅｒｓｉｏｎ） Ｒｅｖｉｓｉｏｎ １．１ （ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／）
【非特許文献６】ＤＩＧＩＴＡＬ ＴＲＡＮＳＭＩＳＳＩＯＮ ＰＲＯＴＥＣＴＩＯＮ ＬＩＣＥＮＳＥ ＡＧＲＥＥＭＥＮＴ， Ａｄｏｐｔｅｒ Ａｇｒｅｅｍｅｎｔ ――Ｍａｙ ２００５
【発明の概要】
【発明が解決しようとする課題】
【００２８】
本発明の目的は、ＤＴＣＰに準拠した情報機器同士で暗号化コンテンツの伝送手続きを好適に実行することができる、優れたコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することにある。
【００２９】
本発明のさらなる目的は、ＭＯＶＥ機能を用いてＳｏｕｒｃｅからＳｉｎｋへコンテンツを好適に移動することができる、優れたコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することにある。
【００３０】
本発明のさらなる目的は、コンテンツ伝送中に伝送路に障害が発生したりしても、コンテンツが分断されたり欠落が発生するのを防いで、コンテンツのＭＯＶＥ処理を確実に行なうことができる、優れたコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することにある。
【課題を解決するための手段】
【００３１】
本発明は、上記課題を参酌してなされたものであり、その第１の側面は、コンテンツを送信するＳｏｕｒｃｅとコンテンツを受信するＳｉｎｋ間でコンテンツを伝送するコンテンツ伝送システムであって、
ＳｏｕｒｃｅとＳｉｎｋ間で伝送対象となるコンテンツを指定するコンテンツ指定手段と、
ＳｏｕｒｃｅとＳｉｎｋ間で相互認証及び鍵交換を行なう認証手段と、
前記認証手段により交換した鍵を用いてＳｏｕｒｃｅからＳｉｎｋへ、前記コンテンツ指定手段により指定されたコンテンツを暗号化伝送するコンテンツ伝送手段と、
前記コンテンツ伝送手段により伝送処理が終了したことに応じて、Ｓｉｎｋ側のコンテンツを有効化するとともに、Ｓｏｕｒｃｅ側の元のコンテンツを無効化するコンテンツ伝送終了処理手段を備え、
ＳｏｕｒｃｅからＳｉｎｋへコンテンツを移動することを特徴とするコンテンツ伝送システムである。
【００３２】
但し、ここで言う「システム」とは、複数の装置（又は特定の機能を実現する機能モジュール）が論理的に集合した物のことを言い、各装置や機能モジュールが単一の筐体内にあるか否かは特に問わない（以下、同様）。
【００３３】
本発明は、ＩＰネットワーク上で著作権保護が必要となる情報コンテンツを伝送するコンテンツ伝送システムに関するものであり、具体的には、ＤＴＣＰ−ＩＰに準拠した情報通信機器の間で、相互認証及び鍵交換を経て共有した鍵を用いて暗号化コンテンツ伝送を安全に行なうコンテンツ伝送システムに関する。
【００３４】
ＤＴＣＰでは、コピー制御を始め著作権が保護された形でコンテンツを伝送する仕組みが規定されている。コンテンツ伝送の形態は、Ｓｏｕｒｃｅ上のコンテンツをＳｉｎｋにコピーする方法と、ＳｏｕｒｃｅからＳｉｎｋへコンテンツを移動してＳｏｕｒｃｅにコンテンツを残さない方法すなわちＭＯＶＥがある。ＤＴＣＰにおいては、Ｓｉｎｋは受信したコンテンツをＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして符号化して扱うこと、及び、Ｓｏｕｒｃｅ側では伝送した後のコンテンツを消去又は利用不能にすることを条件にして、Ｎｏ Ｍｏｒｅ Ｃｏｐｙとして符号化されたコンテンツを伝送するＭＯＶＥ機能が用意されている。
【００３５】
ＭＯＶＥ機能によれば、ユーザはコピーできないコンテンツを他の機器に移動して楽しむことができる。また、有体物をある場所から別の場所へ移動するのと同様に、ＭＯＶＥしたコンテンツのエンティティ数が増えることはないので、コンテンツ保護上の問題はない。
【００３６】
ＭＯＶＥ伝送シーケンス上ではＳｏｕｒｃｅ側でコンテンツを消去又は利用不能にするという条件を一貫して遵守しなければならない。このため、Ｓｏｕｒｃｅ側で送信後のデータを逐次的に利用不能にするとともに、Ｓｉｎｋ側で受信データを逐次的に利用可能にしていくという“ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ”を行なう必要がある。ところが、伝送路での障害が発生したことやその他の原因によりＭＯＶＥシーケンスが中断すると、コンテンツがＳｏｕｒｃｅとＳｉｎｋ間で分断されたり欠落が発生したりして、ユーザは本来適正に取得したコンテンツを消失してしまうことになる。
【００３７】
これに対し、本発明に係るコンテンツ伝送システムでは、ＳｉｎｋはＭＯＶＥ伝送中のコンテンツを順次記録媒体に記録するが、この記録コンテンツはＭＯＶＥ伝送の終了処理が成功するまでは利用できない状態にしておく。その後、コンテンツ伝送の終了処理の確認すなわちＣｏｍｍｉｔｍｅｎｔが行なわれると、Ｓｉｎｋ側の記録コンテンツを有効化して利用できる状態にすると同時に、Ｓｏｕｒｃｅ側で元のコンテンツを消去若しくは利用不能にする処理を行なう。これによって、ＭＯＶＥ伝送中にＳｏｕｒｃｅとＳｉｎｋでＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓコンテンツが二重に存在することはなく、且つ、伝送路で障害が発生するなどによりＭＯＶＥ伝送が途切れても、コンテンツが分断することはなく、Ｓｏｕｒｃｅから改めてコンテンツ伝送を再開することができる。
【００３８】
このようなコンテンツ伝送方法によるＭＯＶＥ伝送は、コンテンツ全体を一括してＳｏｕｒｃｅとＳｉｎｋ間で移動することと等価である。Ｓｏｕｒｃｅ側で送信後のデータを逐次的に利用不能にするとともにＳｉｎｋ側で受信データを逐次的に利用可能にしていくＩＮＣＲＥＭＥＮＴＥＬ ＭＯＶＥとは異なり、“ＢＬＯＣＫ ＭＯＶＥ”と呼ぶこともできる。ＢＬＯＣＫ ＭＯＶＥも、その伝送シーケンス上でＳｏｕｒｃｅとＳｉｎｋで同じコンテンツが二重に存在することはないから、ＤＴＣＰで規定されている条件を満たしたコンテンツのＭＯＶＥ処理であると言える。
【００３９】
また、Ｓｉｎｋは、ＭＯＶＥの終了処理が成功するまでは、記録したコンテンツを再生することはできないが、受信コンテンツを無効化した状態で記録する動作と並行して、受信コンテンツを再生出力（レンダリング）するように構成することも可能である。何故ならば、ＢＬＯＣＫ ＭＯＶＥがＤＴＣＰで既定する条件を満足するＭＯＶＥ処理であるとするならば、ＢＬＯＣＫ ＭＯＶＥに並行してコンテンツを復号して出力することは、コンテンツのストリーミングと等価でだからある。すなわち、復号コンテンツの出力とともにデータが失われるのでコンテンツのコピーには相当せず、ＳｏｕｒｃｅとＳｉｎｋの両方に重複して存在する再生可能なコンテンツがあってはならないというＤＴＣＰ規格に抵触しない。
【００４０】
この場合、Ｓｉｎｋ側では、受信したコンテンツを一旦復号化すると、Ｎｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして規定の符号化処理を施して、ハード・ディスク又はその他の記録媒体に保存するのに並行して、この復号コンテンツをそのままビデオ及びオーディオ信号に変換（レンダリング）して、ディスプレイなどのＡＶ出力部から映像並びに音響出力する。ユーザは、ＭＯＶＥ伝送中にそのコンテンツの内容を確認するとともに、リアルタイムでコンテンツ視聴を享受することができる。
【００４１】
また、ＭＯＶＥ処理手続の期間中、Ｓｏｕｒｃｅは、ＭＯＶＥ対象となるコンテンツを他のＳｉｎｋからＭＯＶＥ要求できないようにロックするようにする。何故ならば、複数のＳｉｎｋに対して同じコンテンツを多重してＭＯＶＥすると、コンテンツのエンティティ数が増える、すなわち事実上コピーすることになり、Ｎｏ Ｍｏｒｅ Ｃｏｐｉｅｓというコピー制御情報を破ることになるからである。
【００４２】
ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥはＤＴＣＰ−ＩＰで取り決められたＭＯＶＥ伝送により実装することが可能である。これに対し、ＢＬＯＣＫ ＭＯＶＥは本願の基礎出願である特願２００６−４１２９の出願当時（平成１８年１月１１日）のＤＴＣＰ仕様に含まれている訳ではない。そこで、ＢＬＯＣＫ ＭＯＶＥを行なう際には、前記認証手段は、ＳｏｕｒｃｅとＳｉｎｋ間で認証処理を行なう際に併せて、互いの機器がＢＬＯＣＫ ＭＯＶＥに対応しているかどうか、若しくはＭＯＶＥ伝送の詐称を防止することが好ましい。また、いずれか一方の機器がＢＬＯＣＫ ＭＯＶＥに対応していない場合には、従来のＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥにモードを切り替えてコンテンツのＭＯＶＥ処理を行なうようにしてもよい。
【００４３】
本発明に係るコンテンツ伝送システムでは、移動したいコンテンツを指定するために、ＵＰｎＰ（登録商標）で規定されているＣＤＳ（Ｃｏｎｔｅｎｔ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ）を利用して行なうことができる。また、それ以降に行なうＳｏｕｒｃｅとＳｉｎｋ間の認証手続き、コンテンツ伝送手続き、及びコンテンツ伝送終了処理手続きは、ＤＴＣＰ−ＩＰに則って各処理を行なうことができる。
【００４４】
例えば、ユーザがＳｉｎｋを操作して、コンテンツを提供するサーバとして動作するＳｏｕｒｃｅからコンテンツをダウンロードする形式でコンテンツの移動を行なうことができる。
【００４５】
この場合、Ｓｉｎｋにおいて、ＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｑｕｅｓｔに対するＳｏｕｒｃｅからのＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｓｐｏｎｓｅに含まれる情報に基づいて、移動したいコンテンツの認証及び鍵交換用のソケット情報を取得するとともに当該コンテンツがＳｏｕｒｃｅから移動可能か否かを確認することができる。
【００４６】
そして、Ｓｉｎｋは、ヘッダ内にコンテンツの移動であることを示すヘッダ情報を含めて、ＨＴＴＰ ＧＥＴメソッドを用いてＳｏｕｒｃｅから暗号化コンテンツを取得することができる。
【００４７】
あるいは、ユーザがＳｏｕｒｃｅを操作して、コンテンツを提供するサーバとして動作するＳｉｎｋに対してコンテンツをアップロードする形式でコンテンツの移動を行なうこともできる。
【００４８】
この場合、Ｓｏｕｒｃｅは、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｑｕｅｓｔを用いてＳｉｎｋに対して、当該コンテンツの移動場所の作成を要求することができる。
【００４９】
このとき、認証処理がＳｉｎｋから開始される都合上、Ｓｉｎｋ側から認証及び鍵交換用のＴＣＰコネクションを確立させるために、ＳｏｕｒｃｅはＳｉｎｋに対してソケット情報を通知する必要がある。例えば、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｑｕｅｓｔにソケット情報を伴うプロパティを含めることで、Ｓｉｎｋに対し認証及び鍵交換用のソケット情報を通知するようにしてもよい。あるいは、Ｓｏｕｒｃｅは、（コンテンツを含まない）ＨＴＴＰ ＰＯＳＴメソッドに含まれるヘッダ情報を用いてＳｉｎｋに対し認証及び鍵交換用のソケット情報を通知するようにしてもよい。
【００５０】
そして、Ｓｏｕｒｃｅは、ヘッダ内にコンテンツの移動であることを示すヘッダ情報を含めて、ＨＴＴＰ ＰＯＳＴメソッドを用いてＳｉｎｋへ暗号化コンテンツをアップロード伝送することができる。
【００５１】
また、ＳｏｕｒｃｅとＳｉｎｋ間では、移動するコンテンツ毎にＡＫＥ手続きによりコンテンツ移動専用の鍵の交換を行なうものとする。Ｓｏｕｒｃｅは、移動対象コンテンツを複数回伝送することになるようなＧＥＴリクエストをＳｉｎｋから受けたときには、これを拒否し、ＭＯＶＥ伝送処理を完結にすると同時にＭＯＶＥ伝送し終えたコンテンツを速やかに無効化することで、同じコンテンツを複数回移動する（すなわち、実質的にコピーする）ことのないようにする。
【００５２】
また、Ｓｏｕｒｃｅは、あるＳｉｎｋに対してコンテンツを移動中、他のＳｉｎｋからの当該コンテンツの移動要求を拒否することにより、複数のＳｉｎｋに同じコンテンツを移動する（すなわち、実質的にコピーする）ことのないようにする。
【００５３】
また、コンテンツのＭＯＶＥ伝送が終了し、さらにコンテンツ伝送終了処理が完了したことに応答して、Ｓｏｕｒｃｅ及びＳｉｎｋにおけるコンテンツ移動専用の交換鍵を消滅させる。逆に言えば、コンテンツの伝送終了処理が終了するまでは、ＡＫＥ手続きのために確立したＴＣＰコネクションを維持するようにする。
【００５４】
このような場合、コンテンツ伝送処理が終了するまでの間、ＡＫＥ手続きのために確立したＴＣＰコネクションを用いてコンテンツ伝送処理を取り消すことができる。コンテンツ伝送の取り消し処理は、Ｓｉｎｋ又はＳｏｕｒｃｅの少なくとも一方からの要求により起動する。コンテンツ伝送処理を取り消す際には、Ｓｉｎｋに伝送されたコンテンツを無効化するようにする。
【００５５】
また、コンテンツ伝送処理が終了するまでの間、ＳｉｎｋとＳｏｕｒｃｅ間の通信が途切れたときに、Ｓｉｎｋ又はＳｏｕｒｃｅの少なくとも一方からの要求によりコンテンツ伝送処理を中止することができる。中止する際のＳｏｕｒｃｅ並びにＳｉｎｋの振る舞いは、コンテンツ伝送を取り消す場合と同様である。
【００５６】
本発明に係るコンテンツ伝送システムでは、ＳｉｎｋとＳｏｕｒｃｅ間でコンテンツ伝送が無事に終了したことを確認すなわちＣｏｍｍｉｔｍｅｎｔをとるためのコンテンツ伝送終了処理を実施して、Ｓｉｎｋ側のコンテンツを有効化するとともに、Ｓｏｕｒｃｅ側の元のコンテンツを無効化することにより、コンテンツの移動が完了する。このコンテンツ伝送の終了処理では、まず、Ｓｉｎｋからコンテンツ受信終了を示す第１のコマンドが送信され、Ｓｏｕｒｃｅはこのコマンドに応答して、Ｓｏｕｒｃｅ側の元のコンテンツを中間的な無効状態にする。続いて、Ｓｏｕｒｃｅから第１のコマンドに対する第１のレスポンスが返信されると、Ｓｉｎｋはこのレスポンスに応答してＳｉｎｋ側に伝送されたコンテンツを有効化するとともに、Ｓｉｎｋ側で保持するコンテンツ移動専用の鍵を消滅させる。そして、Ｓｉｎｋからコンテンツ有効化を示す第２のコマンドが送信されると、Ｓｏｕｒｃｅはこのコマンドに応答して、Ｓｏｕｒｃｅ側の元のコンテンツを無効状態にするとともに、Ｓｏｕｒｃｅ側で保持するコンテンツ移動専用の鍵を消滅させる。
【００５７】
また、コンテンツ伝送手段によるＳｏｕｒｃｅからＳｉｎｋへのコンテンツ伝送が成功裏に終了したにも拘らず、一方の機器の電源遮断などによりコンテンツ伝送終了処理手段による処理が途切れてしまった場合のために、コンテンツ伝送システムは、途切れたコンテンツ伝送終了処理を再開するためのコンテンツ伝送終了処理再開手段をさらに備えていてもよい。この再開手段によって、コンテンツ伝送手続きが無駄にならずに済むとともに、ＳｉｎｋとＳｏｕｒｃｅの双方でコンテンツが無効になることを避けることができる。
【００５８】
このコンテンツ伝送終了処理再開手段は、ＳｏｕｒｃｅがＳｉｎｋからコンテンツ受信終了を示す第１のコマンドを受信したときに、Ｓｏｕｒｃｅがコンテンツ移動専用の交換鍵乃至第１のレスポンスで送る情報をまだ保持している場合には、Ｓｏｕｒｃｅ側の元のコンテンツを中間的な無効状態にし、ＳｏｕｒｃｅからＳｉｎｋに第１のコマンドに対する第１のレスポンスを返信させることで、コンテンツ伝送終了手続きを再開させることができる。
【００５９】
あるいは、コンテンツ伝送終了処理再開手段は、ＳｏｕｒｃｅがＳｉｎｋからコンテンツ受信終了を示す第２のコマンドを受信したときに、Ｓｏｕｒｃｅがコンテンツ移動専用の交換鍵乃至第１のレスポンスで送る情報をまだ保持している場合には、Ｓｏｕｒｃｅ側の元のコンテンツを無効状態にし、Ｓｏｕｒｃｅ側で保持するコンテンツ移動専用の鍵乃至第１のレスポンスで送る情報を消滅させるとともに、ＳｏｕｒｃｅからＳｉｎｋに第２のコマンドに対する第２のレスポンスを返信させることで、コンテンツ伝送終了手続きを再開させることができる。
【００６０】
あるいは、コンテンツ伝送終了処理再開手段は、Ｓｉｎｋがコンテンツ移動専用の交換鍵乃至第１のコマンドで送る情報をまだ保持している場合には、コンテンツ移動元となるＳｏｕｒｃｅとの接続を確立し、該当するコンテンツがＳｉｎｋ側で無効状態であればＳｏｕｒｃｅに対して第１のコマンドを送信させ、該当するコンテンツがＳｉｎｋ側で既に有効化されていれば第２のコマンドを送信させることで、コンテンツ伝送終了処理を再開させることができる。
【００６１】
このとき、Ｓｉｎｋ側から認証及び鍵交換用のＴＣＰコネクションを確立させるために、ＳｏｕｒｃｅはＳｉｎｋに対してソケット情報を通知する必要がある。コンテンツ伝送がダウンロード形式で行なわれた場合には、Ｓｉｎｋは、Ｓｏｕｒｃｅに対してＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｑｕｅｓｔを送信し、ＳｏｕｒｃｅからのＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｓｐｏｎｓｅに含まれる情報に基づいてソケット情報を取得して、コンテンツ伝送終了処理を再開させるためのＴＣＰコネクションを確立することができる。また、コンテンツ伝送がアップロード形式で行なわれた場合には、Ｓｏｕｒｃｅにおいて、（コンテンツを含まない）ＨＴＴＰ ＰＯＳＴメソッドのヘッダ情報を用いてＳｉｎｋにソケット情報を通知し、Ｓｉｎｋはこのソケット情報に基づいてコンテンツ伝送終了処理を再開させるためのＴＣＰコネクションを確立することができる。
【００６２】
また、ＤＴＣＰ−ＩＰでは、ＳｏｕｒｃｅとＳｉｎｋ間の伝送路上にパーソナル・コンピュータなどで構成される不正なプロキシを設置することで、通信内容の改ざんが容易に行なわれてしまう。とりわけ、認証手段によるＳｏｕｒｃｅとＳｉｎｋ間でＭＯＶＥ方法に関するケイパビリティの確認を行なってからＢＬＯＣＫ ＭＯＶＥを開始するようなシステムにおいては、ＳｏｕｒｃｅがＢＬＯＣＫ ＭＯＶＥに対応しているにも拘らず、プロキシはＳｏｕｒｃｅがＢＬＯＣＫ ＭＯＶＥに非対応であるとＳｉｎｋに偽り、ＳｉｎｋにＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥを行なわせることができる。この場合、Ｓｉｎｋ側では、Ｓｏｕｒｃｅからデータを受け取る度に逐次的に有効化していくとともに、コンテンツ伝送処理が終了した時点でプロキシがＳｏｕｒｃｅに対してコンテンツ伝送処理の取り消しを行なうことで、ＳｏｕｒｃｅとＳｉｎｋの双方で有効なコンテンツが存在するというＤＴＣＰ−ＩＰの規定に抵触する事態が生じる。
【００６３】
そこで、本発明に係るコンテンツ伝送システムは、ＳｏｕｒｃｅとＳｉｎｋ間で確認されたケイパビリティが詐称される、あるいはその他の手段によってＳｉｎｋ側のＭＯＶＥモードが偽装されることを防止する詐称防止手段をさらに備えておくことが好ましい。
【００６４】
この詐称防止手段は、例えば、前記認証手段で交換した鍵からコンテンツ暗号鍵を生成する方法をコンテンツ伝送方法毎に、すなわちＩＮＣＲＥＭＥＮＡＬ ＭＯＶＥとＢＬＯＣＫ ＭＯＶＥとで変えるようにする。このような場合、詐称によりＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥを行なうＳｉｎｋは、ＢＬＯＣＫ ＭＯＶＥを行なうＳｏｕｒｃｅとコンテンツ暗号鍵を共有できず、コンテンツが有効化されない。したがって、ＳｏｕｒｃｅとＳｉｎｋでコンテンツが二重に存在することはなくなる。
【００６５】
あるいは、詐称防止手段は、前記認証手段で交換した鍵をスクランブルする方法をコンテンツ伝送方法毎に、すなわちＩＮＣＲＥＭＥＮｔａｌ ＭＯＶＥとＢＬＯＣＫ ＭＯＶＥとで変えるようにしてもよい。このような場合、詐称によりＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥを行なうＳｉｎｋは、認証手段で交換した鍵をデスクランブルすることができず、正しいコンテンツ暗号鍵を得ることができない。したがって、ＳｏｕｒｃｅとＳｉｎｋでコンテンツが二重に存在することはなくなる。
【００６６】
あるいは、詐称防止手段は、相互認証及び鍵交換のためのチャレンジ・レスポンス手続きにおいて、ＳｉｎｋからＳｏｕｒｃｅへの電子署名で保護される通信メッセージの中にコンテンツ伝送方法に関する情報を含めるようにしてもよい。詐称によりＳｉｎｋがＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥを行なうようになった場合、Ｓｏｕｒｃｅ側ではケイパビリティの確認に従ってＢＬＯＣＫ ＭＯＶＥを行なおうとしても、チャレンジ・レスポンスの手続きで詐称されていることを検出することができる。Ｓｏｕｒｃｅは、ＭＯＶＥ伝送そのものを停止する、あるいはＳｉｎｋ側に合わせてＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥに切り替えるといった対策を採ることかできる。
【００６７】
また、本発明の第２の側面は、ＤＴＣＰ Ｓｏｕｒｃｅとしてコンテンツを送信するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
Ｓｉｎｋとの間で伝送対象となるコンテンツを指定するコンテンツ指定手順と、
ＡＫＥ手続きによりＳｉｎｋとの間で相互認証及び鍵交換を行なう認証手順と、
前記認証手順において交換した鍵を用いて、前記コンテンツ指定手順において指定されたコンテンツを、Ｓｉｎｋへ暗号化伝送するコンテンツ伝送手順と、
前記コンテンツ伝送手順においてコンテンツ伝送処理が終了したことに応じて、元のコンテンツを無効化するコンテンツ伝送終了処理手順を実行させ、
Ｓｉｎｋへコンテンツを移動することを特徴とするコンピュータ・プログラムである。
【００６８】
また、本発明の第３の側面は、ＤＴＣＰ Ｓｉｎｋとしてコンテンツを受信するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
Ｓｏｕｒｃｅとの間で伝送対象となるコンテンツを指定するコンテンツ指定手順と、
ＡＫＥ手続きによりＳｏｕｒｃｅとの間で相互認証及び鍵交換を行なう認証手順と、
前記認証手順において交換した鍵を用いて、前記コンテンツ指定手順において指定されたコンテンツを、Ｓｏｕｒｃｅから暗号化伝送するコンテンツ伝送手順と、
前記コンテンツ伝送手順においてコンテンツ伝送処理が終了したことに応じて、受信したコンテンツを有効化するコンテンツ伝送終了処理ステップを実行させ、
Ｓｏｕｒｃｅからコンテンツを移動することを特徴とするコンピュータ・プログラムである。
【００６９】
本発明の第２乃至第３の各側面に係るコンピュータ・プログラムは、コンピュータ・システム上で所定の処理を実現するようにコンピュータ可読形式で記述されたコンピュータ・プログラムを定義したものである。換言すれば、本発明の第２乃至第３の各側面に係るコンピュータ・プログラムをコンピュータ・システムにインストールすることによってコンピュータ・システム上では協働的作用が発揮され、それぞれ本発明の第１の側面に係るコンテンツ伝送システムにおけるＳｏｕｒｃｅ及びＳｉｎｋとして動作する。このようなコンテンツ伝送装置を起動してＤＴＣＰに基づくネットワークを構築することによって、本発明の第１の側面に係るコンテンツ伝送システムと同様の作用効果を得ることができる。
【発明の効果】
【００７０】
本発明によれば、ＤＴＣＰに準拠した情報機器同士で暗号化コンテンツの伝送手続きを好適に実行することができる、優れたコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することができる。
【００７１】
また、本発明によれば、ＭＯＶＥ機能を用いてＳｏｕｒｃｅからＳｉｎｋへコンテンツを好適に移動することができる、優れたコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することができる。
【００７２】
また、本発明によれば、コンテンツ伝送中に伝送路に障害が発生したりしても、コンテンツが分断されたり欠落が発生するのを防いで、コンテンツのＭＯＶＥ処理を確実に行なうことができる、優れたコンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラムを提供することができる。
【００７３】
本発明に係るコンテンツ伝送システムは、ＤＴＣＰで規定されている条件に則って、コンテンツ全体を一括してＳｏｕｒｃｅとＳｉｎｋ間で移動することと等価となるＢＬＯＣＫ ＭＯＶＥが可能である。
【００７４】
ＢＬＯＣＫ ＭＯＶＥは、コンテンツ伝送処理が終了したことに応じて、Ｓｉｎｋ側のコンテンツを有効化するとともに、Ｓｏｕｒｃｅ側の元のコンテンツを無効化するコンテンツ伝送終了処理によって実現する。いずれか一方の機器の電源が遮断するなどの原因で、コンテンツ伝送終了処理が中断する危険があるが、本発明に係るコンテンツ伝送システムによれば、コンテンツ伝送終了処理を再開して、ＭＯＶＥ処理を正しく終了させることができる。
【００７５】
また、ＢＬＯＣＫ ＭＯＶＥを行なう場合には、ＳｏｕｒｃｅとＳｉｎｋ間で不正なプロキシが介在して、例えばＳｉｎｋ側のケイパビリティを詐称することやその他の方法によりＭＯＶＥ伝送を偽装してコピー伝送が行なわれ、コンテンツが二重に存在する危険がある。これに対し、本発明に係るコンテンツ伝送システムによれば、詐称防止手段が、ＳｏｕｒｃｅとＳｉｎｋ間で確認されたケイパビリティを詐称してＳｉｎｋ側のＭＯＶＥモードが偽装されることを防止することができる。
【００７６】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
【図面の簡単な説明】
【００７７】
【図１】図１は、本発明の一実施形態に係る情報通信システムの構成例を模式的に示した図である。
【図２】図２は、図１に示した情報通信システムにおいて、クライアント（すなわち、Ｓｉｎｋ）として動作する情報通信装置の機能構成を示した図である。
【図３】図３は、図１に示した情報通信システムにおいて、サーバ（すなわち、Ｓｏｕｒｃｅ）として動作する情報通信装置の機能構成を示した図である。
【図４】図４は、ＳｏｕｒｃｅとＳｉｎｋの間でＡＫＥに基づく鍵交換手続き、及び鍵交換により共有した鍵を利用した暗号化コンテンツ伝送を行なう仕組みを説明するための図である
【図５】図５は、ＰＣＰのデータ構造を模式的に示した図である。
【図６】図６は、ＰＣＰペイロードにパディングする様子を示した図である。
【図７】図７は、コンテンツのＭＯＶＥ処理と受信コンテンツの再生処理を並行して行なうためのＳｉｎｋの構成例を示した図である。
【図８】図８は、ダウンロード形式でＳｏｕｒｃｅとＳｉｎｋ間のＭＯＶＥ伝送を行なう場合の動作シーケンスを示した図である。
【図９】図９は、ダウンロード形式でＳｏｕｒｃｅとＳｉｎｋ間のＭＯＶＥ伝送を行なう場合に、ＵＰｎＰ（登録商標）ベースでＣＤＳを用いてＳｉｎｋとＳｏｕｒｃｅ間でＭＯＶＥ対象となるコンテンツを選択するための動作シーケンスを示した図である。
【図１０】図１０は、ＭＯＶＥ用ＡＫＥ手続きの動作シーケンスを示した図である。
【図１１】図１１は、Ｓｏｕｒｃｅ及びＳｉｎｋ間でＭＯＶＥ終了処理手続きを実行する動作シーケンスを示した図である。
【図１２】図１２は、アップロード形式でＳｏｕｒｃｅとＳｉｎｋ間のＭＯＶＥ伝送を行なう場合の動作シーケンスを示した図である。
【図１３】図１３は、アップロード形式でＳｏｕｒｃｅとＳｉｎｋ間のＭＯＶＥ伝送を行なう場合に、ＵＰｎＰ（登録商標）ベースでＣＤＳを用いてＳｏｕｒｃｅからＳｉｎｋに対してコンテンツのアップロードを通知するための動作シーケンスを示した図である。
【図１４Ａ】図１４Ａは、ダウンロード形式でＳｏｕｒｃｅからＳｉｎｋへコンテンツをＭＯＶＥする場合のＳｏｕｒｃｅ及びＳｉｎｋがそれぞれ実行する処理動作を示したフローチャートである。
【図１４Ｂ】図１４Ｂは、ＨＴＴＰサーバとしてのＳｏｕｒｃｅからＨＴＴＰクライアントとしてのＳｉｎｋへコンテンツをダウンロードＭＯＶＥ伝送する場合のＳｏｕｒｃｅ及びＳｉｎｋがそれぞれ実行する処理動作を示したフローチャートである。
【図１５Ａ】図１５Ａは、アップロード形式でＳｏｕｒｃｅからＳｉｎｋへコンテンツをＭＯＶＥする場合のＳｏｕｒｃｅ及びＳｉｎｋがそれぞれ実行する処理動作を示したフローチャートである。
【図１５Ｂ】図１５Ｂは、アップロード形式でＳｏｕｒｃｅからＳｉｎｋへコンテンツをＭＯＶＥする場合のＳｏｕｒｃｅ及びＳｉｎｋがそれぞれ実行する処理動作を示したフローチャートである。
【図１６】図１６は、ケイパビリティの確認シーケンスを含んだＭＯＶＥ用ＡＫＥ手続きの動作シーケンス例を示した図である。
【図１７】図１７は、図１６中のケイパビリティ交換手続きの部分を詳細に示した図である。
【図１８】図１８は、図１１に示したダウンロードＭＯＶＥ伝送終了シーケンス上でＳｉｎｋ及びＳｏｕｒｃｅがそれぞれ実施する処理内容を具体的に示した図である。
【図１９】図１９は、ＨＴＴＰサーバとして動作するＳｏｕｒｃｅにおいて、中断したダウンロードＭＯＶＥ伝送終了処理を再開するための処理手順を示したフローチャートである。
【図２０】図２０は、ＨＴＴＰサーバとして動作するＳｏｕｒｃｅにおいて、中断したダウンロードＭＯＶＥ伝送終了処理を再開するための処理手順を示したフローチャートである。
【図２１】図２１は、ＨＴＴＰクライアントとして動作するＳｉｎｋにおいて、中断したダウンロードＭＯＶＥ伝送処理を再開するための処理手順を示したフローチャートである。
【図２２】図２２は、Ｓｉｎｋに対しＭＯＶＥモード詐称攻撃が掛けられた動作シーケンス例を示した図である。
【図２３】図２３は、ＭＯＶＥモード詐称攻撃に対策を採った動作シーケンス例を示した図である。
【図２４】図２４は、ＭＯＶＥモード詐称攻撃に対策を採った動作シーケンス例を示した図である。
【図２５】図２５は、ＭＯＶＥモード詐称攻撃に対策を採った動作シーケンス例を示した図である。
【図２６】図２６は、ＭＯＶＥモード詐称攻撃に対策を採った動作シーケンス例を示した図である。
【図２７】図２７は、ＭＯＶＥ用ＡＫＥ手続の他の動作シーケンス例を示した図である。
【図２８】図２８は、ＳｉｎｋがＨＴＴＰ ＧＥＴリクエストを用いてコンテンツを要求し、ＳｏｕｒｃｅがＨＴＴＰ ＧＥＴレスポンスを用いてコンテンツ伝送を行なう動作シーケンス例を示した図である。
【図２９】図２９は、ダウンロード形式のＭＯＶＥシーケンスにおいて、中断したＭＯＶＥ伝送終了処理を再開する際に、Ｓｉｎｋ及びＳｏｕｒｃｅ間でＴＣＰコネクションを確立するための処理手順を示したフローチャートである。
【図３０】図３０は、ＳｏｕｒｃｅとＳｉｎｋ間でアップロードＭＯＶＥ伝送を行なうための動作シーケンスを示した図（但し、ＳｏｕｒｃｅがＰＯＳＴリクエストを用いてソケット情報を通知する方法を用いる場合）である。
【図３１】図３１は、ＳｏｕｒｃｅとＳｉｎｋ間でアップロードＭＯＶＥ伝送を行なうための動作シーケンスを示した図（但し、Ｓｏｕｒｃｅから送信されたソケット情報を伴うＰＯＳＴリクエストに対し、ＡＫＥ手続が終了した後にＳｉｎｋがＰＯＳＴレスポンスを返し、その後にコンテンツをＰＯＳＴリクエストに対するメッセージ・ボディとして伝送する場合）である。
【図３２Ａ】図３２Ａは、ＳｏｕｒｃｅからＳｉｎｋへコンテンツをアップロードＭＯＶＥ伝送する場合のＳｏｕｒｃｅ及びＳｉｎｋがそれぞれ実行する処理動作を示したフローチャートである。
【図３２Ｂ】図３２Ｂは、ＳｏｕｒｃｅからＳｉｎｋへコンテンツをアップロードＭＯＶＥ伝送する場合のＳｏｕｒｃｅ及びＳｉｎｋがそれぞれ実行する処理動作を示したフローチャートである。
【図３３】図３３は、アップロード形式のＭＯＶＥシーケンスにおいて、中断したＭＯＶＥ伝送終了処理を再開する際に、Ｓｉｎｋ及びＳｏｕｒｃｅ間でＴＣＰコネクションを確立するための処理手順を示したフローチャートである。
【発明を実施するための最良の形態】
【００７８】
本発明は、著作権やその他の目的で保護が必要となる情報コンテンツを所定のコピー制御情報に従って暗号化伝送するコンテンツ伝送システムに関するものである。かかるシステムの具体例は、ＤＴＣＰ−ＩＰ機器の間で行なわれるＨＴＴＰプロトコルを利用したコンテンツ伝送である。以下、図面を参照しながら本発明の実施形態について詳解する。
【００７９】
Ａ．システム構成
ＤＴＣＰ−ＩＰに従ったコンテンツ伝送は、コンテンツを送信するＳｏｕｒｃｅと、コンテンツを受信して再生若しくは記録するＳｉｎｋで構成される。コンテンツの伝送方法としては、サーバとして動作するＳｏｕｒｃｅがクライアントとして動作するＳｉｎｋからの要求に応じてコンテンツを送信するダウンロード転送と、クライアントとして動作するＳｉｎｋからの要求によりサーバとして動作するＳｉｎｋへコンテンツを送信するアップロード転送が考えられる。
【００８０】
図１には、本発明の一実施形態に係る情報通信システムの構成例を模式的に示している。図示の例では、ＳｏｕｒｃｅとＳｉｎｋの各装置により、ＤＴＣＰ−ＩＰ ＡＫＥシステムが構築されている。ＤＴＣＰ−ＩＰに準拠した認証サーバであるＳｏｕｒｃｅとＤＴＣＰ−ＩＰに準拠した認証クライアントであるＳｉｎｋはネットワークを経由して接続されている。ここで言うネットワークには、Ｅｔｈｅｒｎｅｔ（登録商標）や、インターネット、その他のＩＰネットワークが含まれる。
【００８１】
図２及び図３には、図１に示したコンテンツ伝送システムにおいて、Ｓｉｎｋ及びＳｏｕｒｃｅとして動作するコンテンツ伝送装置の、特に認証及びコンテンツ伝送に着目した機能構成をそれぞれ模式的に示している。但し、図２及び図３では、サーバとして動作するＳｏｕｒｃｅがクライアントとして動作するＳｉｎｋからの要求に応じてコンテンツをダウンロード転送する場合の機能構成を示したものであり、アップロード転送時の機能構成については説明を省略する。ＳｉｎｋとＳｏｕｒｃｅは、インターネットなどのＴＣＰ／ＩＰネットワーク上でコネクションを確立することができ、このコネクションを利用して、認証手続きやコンテンツ伝送手続きを実行することができる。
【００８２】
図２に示すＳｉｎｋは、ＤＴＣＰ−ＩＰ認証ブロック１０と、ＤＴＣＰ−ＩＰコンテンツ受信ブロック２０と、コンテンツ再生／記録ブロック３０を備え、ＨＴＴＰクライアントとして動作し、ＨＴＴＰサーバとして動作するＳｏｕｒｃｅからダウンロード転送されるコンテンツを受信するようになっている。
【００８３】
ＤＴＣＰ−ＩＰ認証ブロック１０は、ＡＫＥブロック１１と、メッセージ・ダイジェスト生成ブロック１２と、コンテンツ復号ブロック１３で構成される。ＤＴＣＰ−ＩＰ認証ブロック１０は、より好ましくは耐タンパ性を備えている。
【００８４】
ＡＫＥブロック１１は、ＤＴＣＰ−ＩＰにおけるＡＫＥ機構（Ｓｉｎｋ側）を実現するブロックである。このＡＫＥブロック１１は後述のメッセージ・ダイジェスト生成ブロックから要求されたパラメータを渡す機能も備えている。ＡＫＥブロック１１は、コピーなど通常のコンテンツ伝送手続を行なう際のＡＫＥとは別に、ＭＯＶＥ専用のＡＫＥ手続を規定し、スクランブル方法などを異ならせることによってＭＯＶＥモードの詐称を防止するようにしてもよい。
【００８５】
メッセージ・ダイジェスト生成ブロック１２は、指定されたアルゴリズムに従い、パラメータのメッセージ・ダイジェストを生成するブロックである。メッセージ・ダイジェストを生成するアルゴリズムはあらかじめ用意されたアルゴリズムを指定することができる。あらかじめ用意されたアルゴリズムとして、例えばＭＤ５やＳＨＡ−１といった一方向性ハッシュ関数に関するアルゴリズムが挙げることができる（ＳＨＡ−１は、ＭＤ５と同様、ＭＤ４を改良したものに相当するが、１６０ビットのハッシュ値を生成するので、強度はＭＤシリーズを上回る）。
【００８６】
メッセージ・ダイジェスト生成ブロック１２は、ＤＴＣＰ−ＩＰ認証ブロック１０の外に公開してはならないＡＫＥブロック１１が保持するパラメータのメッセージ・ダイジェストを生成できるようにＡＫＥブロック１１と密に配置され、ＡＫＥブロック１１へパラメータを要求して取得することが可能であり、そのパラメータ若しくは外部から与えられたパラメータのメッセージ・ダイジェストを作成することができる。
【００８７】
コンテンツ復号ブロック１３は、ＡＫＥで交換した鍵Ｋxを用いてコンテンツの復号鍵Ｋcを算出し、Ｓｏｕｒｃｅから受信した暗号コンテンツをこの復号鍵Ｋcで復号するブロックである。ここで復号されたコンテンツは、コンテンツ再生／記録ブロックへ渡される。ＭＯＶＥ専用のＡＫＥ手続を規定した場合も同様である。
【００８８】
コンテンツ再生／記録ブロック３０は、コンテンツ復号ブロック１３から渡されたコンテンツを、再生モードの場合は再生を行ない、記録モードの場合はハード・ディスク又はその他の記録媒体（図示しない）に保存する。但し、コンテンツの記録動作は、コンテンツ伝送用のパケットＰＣＰ内に挿入されているコピー制御情報の規定に従う。
【００８９】
ＤＴＣＰ−ＩＰコンテンツ受信ブロック２０は、ＡＫＥを実施した後にＳｏｕｒｃｅとのコンテンツ伝送手続きを実行する処理モジュールである。図示の例では、ＤＴＣＰ−ＩＰコンテンツ受信ブロック２０はＨＴＴＰクライアント・ブロック２１を持ち、ＨＴＴＰクライアントとしてＨＴＴＰサーバ（すなわちＳｏｕｒｃｅ）へコンテンツを要求し、応答されたコンテンツをＨＴＴＰサーバから受信する。
【００９０】
ＨＴＴＰクライアント・ブロック２１は、ＨＴＴＰリクエスト管理ブロック２２とＨＴＴＰレスポンス管理ブロック２３に分かれる。さらに、ＨＴＴＰリクエスト管理ブロックは、ＨＴＴＰリクエスト送信ブロック２２ＡとＨＴＴＰリクエスト生成ブロック２２Ｂに分かれる。
【００９１】
ＨＴＴＰリクエスト生成ブロック２２Ｂは、送信するコンテンツ伝送要求（ＨＴＴＰリクエスト)を生成する。ここで生成されたＨＴＴＰリクエスト（例えば、ＨＴＴＰ ＧＥＴリクエスト）は、ＨＴＴＰリクエスト送信ブロック２２ＡによりＨＴＴＰサーバ（すなわちＳｏｕｒｃｅ）へ送信される。
【００９２】
ＨＴＴＰレスポンス管理ブロック２３は、ＨＴＴＰレスポンス受信ブロック２３ＡとＨＴＴＰレスポンス解釈ブロック２３Ｂに分かれる。サーバから返信されるＨＴＴＰレスポンスと暗号化されたコンテンツは、ＨＴＴＰレスポンス受信ブロック２３Ａで受信される。ここで受信したＨＴＴＰレスポンスは、ＨＴＴＰレスポンス解釈ブロック２３Ｂでチェックされる。ここでのチェックがＯＫの場合は受信した暗号化コンテンツをＤＴＣＰ−ＩＰ認証ブロック１０内のコンテンツ復号ブロック１３へ送る。また、このチェックがＮＧの場合は、エラー・レスポンスとしての処理を行なう。ＳｏｕｒｃｅからのＨＴＴＰレスポンスは１つ以上のＰＣＰからなる。
【００９３】
ＤＴＣＰ−ＩＰ認証ブロック１０とＤＴＣＰ−ＩＰコンテンツ受信ブロック２０は、サーバ機器との間で個別のＴＣＰ／ＩＰコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。
【００９４】
また、図３に示すＳｏｕｒｃｅは、ＤＴＣＰ−ＩＰ認証ブロック４０と、ＤＴＣＰ−ＩＰコンテンツ送信ブロック５０と、コンテンツ管理ブロック６０を備え、ＨＴＴＰサーバとして動作し、ＨＴＴＰクライアントとして動作するＳｉｎｋに対してコンテンツをダウンロード転送するようになっている。
【００９５】
ＤＴＣＰ−ＩＰ認証ブロック４０は、ＡＫＥブロック４１と、メッセージ・ダイジェスト生成ブロック４２と、コンテンツ暗号化ブロック４３で構成される。ＤＴＣＰ−ＩＰ認証ブロック４０は、より好ましくは耐タンパ性を備えている。
【００９６】
ＡＫＥブロック４１は、ＤＴＣＰ−ＩＰにおけるＡＫＥ機構（Ｓｏｕｒｃｅ側）を実現するブロックである。このブロックは、メッセージ・ダイジェスト生成ブロック４２から要求されたパラメータ（後述）を渡す機能も備えている。ＡＫＥブロック４１は認証したＳｉｎｋに関する情報をＡＫＥ認証した機器の数だけ保持し、それをクライアントからコンテンツが要求された際に認証済みのクライアントかどうかを判別するのに使用する。ＡＫＥブロック４１は、コピーなど通常のコンテンツ伝送手続を行なう際のＡＫＥとは別に、ＭＯＶＥ専用のＡＫＥ手続を規定し、スクランブル方法などを異ならせることによってＭＯＶＥモードの詐称を防止するようにしてもよい。
【００９７】
メッセージ・ダイジェスト生成ブロック４２は指定されたアルゴリズムに従い、パラメータのメッセージ・ダイジェストを生成するブロックである。メッセージ・ダイジェストを生成するアルゴリズムはあらかじめ用意されたアルゴリズムを指定できる。あらかじめ用意されたアルゴリズムとは、例えばＭＤ５やＳＨＡ−１といった一方向性ハッシュ関数に関するアルゴリズムが挙げられる（同上）。
【００９８】
メッセージ・ダイジェスト生成ブロック４２は、ＤＴＣＰ−ＩＰ認証ブロック４０の外に公開してはならないＡＫＥブロック４１が保持するパラメータのメッセージ・ダイジェストを生成できるようにＡＫＥブロック４１と密に配置され、ＡＫＥブロック４１へパラメータを要求して取得することが可能で、そのパラメータ若しくは外部から与えられたパラメータのメッセージ・ダイジェストを作成することができる。
【００９９】
コンテンツ暗号化ブロック４３は、ＤＴＣＰ−ＩＰコンテンツ送信ブロック５０の要求に応じてコンテンツ管理ブロック６０より読み出したコンテンツ・データを、ＡＫＥで交換した鍵Ｋxから生成したコンテンツ鍵Ｋcを用いて暗号化するブロックである。ここで暗号化されたコンテンツは、クライアントへ送信するために、ＤＴＣＰ−ＩＰコンテンツ送信ブロック５０へ渡される。
【０１００】
コンテンツ管理ブロック６０は、ＤＴＣＰ−ＩＰの機構を用いて保護されるべきコンテンツを管理するブロックである。コンテンツ暗号化ブロックの読み出しに応じて、コンテンツのデータを渡す。
【０１０１】
ＤＴＣＰ−ＩＰコンテンツ送信ブロック５０は、ＨＴＴＰサーバ・ブロック５１を持ち、ＨＴＴＰサーバとしてクライアント（すなわちＳｉｎｋ）からのリクエスト（例えば、ＨＴＴＰ ＧＥＴリクエスト）を受理し、要求に応じた処理を実行する。
【０１０２】
ＨＴＴＰサーバ・ブロック５１は、ＨＴＴＰリクエスト管理ブロック５２とＨＴＴＰレスポンス管理ブロック５３に分かれる。
【０１０３】
ＨＴＴＰリクエスト管理ブロック５２は、さらに、ＨＴＴＰリクエスト受信ブロック５２Ａと、ＨＴＴＰリクエスト解釈ブロック５２Ｂに分かれる。ＨＴＴＰリクエスト受信ブロック５２Ａは、クライアントからのＨＴＴＰリクエストを受信する。受信したＨＴＴＰリクエストはＨＴＴＰリクエスト解釈ブロック５２Ｂに送られ、チェックされる。ＨＴＴＰリクエスト解釈ブロック５２ＢにおけるチェックがＯＫの場合、ＨＴＴＰリクエストの情報をＤＴＣＰ−ＩＰ認証ブロック４０へ通知する。
【０１０４】
ＨＴＴＰレスポンス管理ブロック５３は、さらに、ＨＴＴＰレスポンス生成ブロック５３ＢとＨＴＴＰレスポンス送信ブロック５３Ａに分かれる。
【０１０５】
ＨＴＴＰレスポンス生成ブロック５３Ｂは、ＨＴＴＰリクエスト解釈ブロック５２ＢでのチェックがＯＫの場合、暗号化されたコンテンツを返すためのＨＴＴＰレスポンスを作成する。ＨＴＴＰレスポンスは１つ以上のＰＣＰからなる。一方、ＨＴＴＰリクエスト解釈ブロック５２ＢでのチェックがＮＧの場合、エラーを返すためのＨＴＴＰレスポンスを作成する。
【０１０６】
ＨＴＴＰレスポンス送信ブロック５３Ａは、作成されたＨＴＴＰレスポンスを、要求元のクライアントへ送信する。また、ＨＴＴＰリクエスト解釈ブロック５２ＢでのチェックがＯＫの場合には、ＨＴＴＰレスポンス・ヘッダに続けて、ＤＴＣＰ−ＩＰ認証ブロック４０内のコンテンツ暗号化ブロック４３で暗号化したコンテンツを送信する。
【０１０７】
ＤＴＣＰ−ＩＰ認証ブロック４０とＤＴＣＰ−ＩＰコンテンツ送信ブロック５０は、Ｓｉｎｋとの間で個別のＴＣＰ／ＩＰコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。
【０１０８】
なお、ＤＴＣＰ−Ｓｉｎｋ及びＤＴＣＰ−ＳｏｕｒｃｅのいずれもがＤＴＣＰ−ＩＰ認証ブロック内に持つメッセージ・ダイジェスト生成ブロックは、ＤＴＣＰ−ＩＰ自体で規定される機能モジュールではなく、また本発明の要旨には直接関連しない。
【０１０９】
Ｂ．ＨＴＴＰを利用したコンテンツ伝送
続いて、ＤＴＣＰ−ＩＰに従ったコンテンツの伝送手順について説明する。図４には、ＳｏｕｒｃｅとＳｉｎｋの間でＡＫＥに基づく鍵交換手続き、及び鍵交換により共有した鍵を利用した暗号化コンテンツ伝送を行なう仕組みを図解している。コンテンツ伝送の形態は、Ｓｏｕｒｃｅ上のコンテンツをＳｉｎｋにコピーする方法と、ＳｏｕｒｃｅからＳｉｎｋへコンテンツを移動してＳｏｕｒｃｅにコンテンツを残さない方法がある。この項では、前者のコピーによるコンテンツ伝送方法を前提にして説明する。後者のコンテンツ伝送方法はＭＯＶＥ機能によって実現されるが、ＭＯＶＥ伝送を行なう際のＡＫＥ手続の詳細については後述に譲る。
【０１１０】
ＳｏｕｒｃｅとＳｉｎｋは、まず１つのＴＣＰ／ＩＰコネクションを確立し、機器同士の認証を行なう。この認証を、ＤＴＣＰ認証若しくはＡＫＥ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ)と言う。ＤＴＣＰ準拠機器には、ＤＴＬＡ（前述）により発行された機器証明書が埋め込まれている。ＤＴＣＰ認証手続きでは、互いが正規のＤＴＣＰ準拠機器であることを確かめた後、認証鍵ＫauthをＳｏｕｒｃｅとＳｉｎｋで共有することができる。
【０１１１】
ＡＫＥ手続きが成功すると、Ｓｏｕｒｃｅはコンテンツ鍵Ｋcの種となる交換鍵Ｋxを生成し、認証鍵Ｋauthで暗号化してＳｉｎｋに送る。Ｓｏｕｒｃｅ及びＳｉｎｋそれぞれにおいて、交換鍵Ｋxに対して所定の演算処理を適用することによって、コンテンツ伝送時にコンテンツを暗号化するために使用されるコンテンツ鍵Ｋcが生成される。コンテンツ伝送方法に応じて交換鍵Ｋxからコンテンツ鍵Ｋcを生成するための計算式を変えるようにしてもよいが（例えば、コンテンツのコピー伝送とＭＯＶＥ伝送で計算式を切り替えるようにしてもよい）、この点の詳細については後述に譲る。
【０１１２】
そして、ＤＴＣＰ準拠の機器間でＡＫＥによる認証及び鍵交換手続きが済んだ後、ＳｉｎｋはＳｏｕｒｃｅ上のコンテンツを要求する。Ｓｏｕｒｃｅは、ＵＰｎＰ（登録商標）で規定されているＣＤＳ（Ｃｏｎｔｅｎｔ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ）などを通じてＳｉｎｋにＳｏｕｒｃｅ上のコンテンツへのアクセス先を示すコンテンツ場所をあらかじめ伝えることができる。Ｓｉｎｋがコンテンツを要求するとき、ＨＴＴＰやＲＴＰなどのプロトコルを利用することができる。
【０１１３】
図４に示す例では、ＨＴＴＰの手続きに従ってＨＴＴＰクライアントとしてのＳｉｎｋがＨＴＴＰサーバとしてのＳｏｕｒｃｅに対してコンテンツを要求するダウンロード形式となるコンテンツ伝送の場合、例えばＨＴＴＰ ＧＥＴメソッドを用いてコンテンツの伝送を開始する。また、図示しないが、ＨＴＴＰの手続きに従ってＨＴＴＰクライアントとしてのＳｏｕｒｃｅがＨＴＴＰサーバとしてのＳｉｎｋに対してコンテンツをプッシュするアップロード形式となるコンテンツ伝送の場合、例えばＨＴＴＰ ＰＯＳＴメソッドを用いてコンテンツの伝送を開始する。あるいは、ＲＴＰによる伝送を要求するとき、ＳｏｕｒｃｅがＲＴＰ Ｓｅｎｄｅｒとなり、ＳｉｎｋがＲＴＰ Ｒｅｃｅｉｖｅｒとなってコンテンツの伝送を開始する。
【０１１４】
ＨＴＴＰでコンテンツ伝送を行なう際、ＡＫＥ手続すなわちＤＴＣＰ認証のためのＴＣＰ／ＩＰコネクションとは別に、ＨＴＴＰのためのＴＣＰ／ＩＰコネクションがＨＴＴＰクライアントより作成される（すなわち、ＳｏｕｒｃｅとＳｉｎｋはそれぞれ、ＡＫＥ手続き用とコンテンツ伝送用に個別のソケット情報（ＩＰアドレスとポート番号の組み合わせ）を持つ）。そして、ＨＴＴＰクライアントとしてのＳｉｎｋは、通常のＨＴＴＰと全く同様の動作手順により、ＧＥＴメソッドを用いたＨＴＴＰリクエストによりＨＴＴＰサーバ上のコンテンツを要求する。これに対し、ＨＴＴＰサーバは、要求通りのコンテンツをＨＴＴＰレスポンスとして返す。
【０１１５】
ＨＴＴＰレスポンスとして伝送されるデータは、ＨＴＴＰサーバすなわちＳｏｕｒｃｅがＡＫＥ認証をした後に共有した鍵を用いてコンテンツを暗号化したデータとなっている。具体的には、Ｓｏｕｒｃｅは、乱数を用いてノンスＮcを生成して、交換鍵ＫxとノンスＮcと暗号モードを表すＥ−ＥＭＩを基にコンテンツ鍵Ｋcを生成する。そして、Ｓｉｎｋから要求されているコンテンツを、コンテンツ鍵Ｋcを用いて暗号化し、暗号化コンテンツからなるペイロードとノンスＮcとＥ−ＥＭＩを含んだヘッダからなるパケットであるＰＣＰ（Ｐｒｏｔｅｃｔｅｄ Ｃｏｎｔｅｎｔ Ｐａｃｋｅｔ）をＴＣＰストリーム上に乗せて送信する。そして、ＩＰプロトコルは、ＴＣＰストリームを所定の単位となるパケットの大きさに分割し、さらにヘッダ部を付加したＩＰパケットにし、指定されたＩＰアドレス宛てに届ける。
【０１１６】
Ｓｉｎｋ側では、Ｓｏｕｒｃｅからの各ＩＰパケットを受信すると、これをＴＣＰストリームに組み立てて、送信されたＰＣＰを取り出す。そして、ストリームからノンスＮcとＥ−ＥＭＩを取り出すと、これらと交換鍵Ｋxを用いてコンテンツ鍵Ｋcを算出し、暗号化コンテンツを復号することができる。そして、復号化した後の平文のコンテンツに対し再生若しくは記録などの処理を実施することができる。このようにしてＨＴＴＰプロトコルを利用したコンテンツ伝送が終了すると、例えばＳｉｎｋ側から、コンテンツ伝送に使用したＴＣＰコネクションを適宜切断する。
【０１１７】
図５には、ＤＴＣＰ−ＩＰにおいてコンテンツ伝送に用いられるパケットＰＣＰのデータ構造を模式的に示している。図示のように、ＰＣＰは、ノンスＮcを含んだヘッダと、暗号化コンテンツからなるペイロードで構成されるパケットである。ちなみに、ＨＴＴＰレスポンスは１つ以上のＰＣＰからなり、ＲＴＰペイロードは１つのＰＣＰからなる。
【０１１８】
ＰＣＰヘッダは平文であり、ノンスＮcが含まれている。また、ＰＣＰペイロードはノンスＮcで決まるコンテンツ鍵Ｋcで暗号化されたコンテンツ（但し、コピー制御情報として“ｃｏｐｙ−ｆｒｅｅ”が指定されているコンテンツは暗号化不要）で構成される。
【０１１９】
ＰＣＰペイロードは、データ長すなわちｐｒｏｔｅｃｔｅｄ＿ｃｏｎｔｅｎｔ＿ｌｅｎｇｔｈの値が常に１６バイトの倍数になるように規定されている。ｐｒｏｔｅｃｔｅｄ＿ｃｏｎｔｅｎｔ＿ｌｅｎｇｔｈの値が１６の整数倍でないときは、必要に応じて暗号化前にパディング（ｐａｄｄｉｎｇ）が行なわれ、コンテンツに１〜１５バイトのパディングが付く。図６には、ＰＣＰをパディングする様子を示している。
【０１２０】
ここで、長大なＴＣＰストリーム全体に亘り同じ暗号鍵を使用し続けると、鍵が解読される危険は高くなる。このため、ＤＴＣＰ−ＩＰでは、Ｓｏｕｒｃｅは１２８ＭＢ毎にノンスＮcすなわちコンテンツ鍵Ｋcを更新する（１ずつインクリメントする）よう取り決められ、コンテンツの安全化が図られている。定期的にノンスＮcを更新する時点でも、ＰＣＰはパディングされる（コンテンツ鍵Ｋcを更新しなくても複数のＰＣＰにｐａｄｄｉｎｇすることは可能）。
【０１２１】
また、ＤＴＣＰ−ＩＰでは、ノンスＮcの更新に伴い、コンテンツ鍵確認手続を起動するようになっている。コンテンツ鍵確認手続では、Ｓｉｎｋは、コンテンツ伝送用のＴＣＰコネクションとは別に、コンテンツ鍵の確認用のＴＣＰコネクションをさらに確立し、Ｓｏｕｒｃｅに対しコンテンツ鍵確認のための手続きを行なう。Ｓｉｎｋは、コンテンツ鍵の確認が必要になると、適宜このＴＣＰコネクションを確立する。例えば、ＤＴＣＰ−ＩＰ Ｖｏｌｕｍｅ １ Ｓｕｐｐｌｅｍｅｎｔ Ｅ．８．６には、コンテンツ鍵の確認手続きとして“Ｃｏｎｔｅｎｔ Ｋｅｙ Ｃｏｎｆｉｒｍａｔｉｏｎ”を規定している。これによれば、Ｓｉｎｋは、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦ ｓｕｂｆｕｎｃｔｉｏｎを用いて、現在のノンスＮcに関連付けられたコンテンツ鍵の確認を行なう。
【０１２２】
Ｃ．コンテンツのＭＯＶＥ伝送
ＤＴＣＰ−ＩＰでは、Ｓｏｕｒｃｅ側でＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして符号化されているコンテンツをＳｉｎｋで利用できるようにする手段として、ＭＯＶＥ機能が用意されている。
【０１２３】
ネットワーク通信におけるＭＯＶＥは、機器間でデータを移動させることに相当し、移動先の機器にデータが移動した後は基本的に移動元の機器にはデータを残さない。ＤＴＣＰ−ＩＰで言うＭＯＶＥ機能は、Ｓｉｎｋは受信したコンテンツをＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして符号化して扱うこと、及び、Ｓｏｕｒｃｅ側では伝送した後のコンテンツを消去又は利用不能にするという条件の下で、暗号化コンテンツをＳｏｕｒｃｅからＳｉｎｋへ伝送することを意味し、単一のＳｏｕｒｃｅと単一のＳｉｎｋ間でのみＭＯＶＥが許容される。
【０１２４】
以下では、ＤＴＣＰ−ＩＰに準拠する機器同士の相互運用を実現するためのＭＯＶＥシーケンスについて説明する。最低限の相互運用を確保するには、単一のＨＴＴＰ ＧＥＴメソッド又はＰＯＳＴメソッドを用いたＭＯＶＥ伝送が推奨されるが、勿論、他のシーケンスを用いた実装が禁止されている訳ではない。
【０１２５】
ＤＴＣＰ−ＩＰにおけるＭＯＶＥシーケンスでは、Ｓｏｕｒｃｅ側でコンテンツを消去又は利用不能にするという条件を一貫して遵守することが課されている。このため、Ｓｏｕｒｃｅ側で送信後のデータを逐次的に利用不能にするとともに、Ｓｉｎｋ側で受信データを逐次的に利用可能にしていくという“ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥ”を行なう必要がある。ところが、伝送路での障害が発生したことやその他の原因によりＭＯＶＥシーケンスが中断すると、コンテンツがＳｏｕｒｃｅとＳｉｎｋ間で分断されたり欠落が発生したりしてしまう。そして、ＭＯＶＥシーケンスが途切れた結果として、ユーザは、そもそも適正に取得したコンテンツを消失してしまうことになる。
【０１２６】
そこで、本実施形態に係るコンテンツ伝送システムでは、Ｓｉｎｋは、ＭＯＶＥ伝送中のコンテンツを順次記録媒体に記録するが、ＭＯＶＥの終了処理が成功するまでは順次記録したコンテンツを利用できない状態に保つようにした。そして、ＭＯＶＥ伝送の終了処理の確認すなわちＣｏｍｍｉｔｍｅｎｔが行なわれると、Ｓｉｎｋ側の記録コンテンツを有効化して利用できる状態にすると同時に、Ｓｏｕｒｃｅ側で元のコンテンツを消去若しくは利用不能にする処理を行なう。このような伝送手順によれば、ＭＯＶＥ伝送中にＳｏｕｒｃｅとＳｉｎｋでＮｏ Ｍｏｒｅ Ｃｏｐｙコンテンツが二重に存在することはない。且つ、伝送路で障害が発生するなどによりＭＯＶＥ伝送処理が途切れても、コンテンツが分断することはなく、Ｓｉｎｋ側から改めてコンテンツ伝送を再開（ｒｅｓｕｍｅ）することができる。
【０１２７】
このようなコンテンツのＭＯＶＥ伝送は、コンテンツ全体を一括してＳｏｕｒｃｅとＳｉｎｋ間で移動することと等価である。Ｓｏｕｒｃｅ側で送信後のデータを逐次的に利用不能にするとともにＳｉｎｋ側で受信データを逐次的に利用可能にしていくＩＮＣＲＥＭＥＮＴＥＬ ＭＯＶＥとは異なり、“ＢＬＯＣＫ ＭＯＶＥ”と呼ぶこともできる。ＢＬＯＣＫ ＭＯＶＥも、ＳｏｕｒｃｅとＳｉｎｋで同じコンテンツが二重に存在することはないから、ＤＴＣＰで規定されている条件を満たしたコンテンツのＭＯＶＥ処理であると言える。
【０１２８】
なお、Ｓｉｎｋは、ＭＯＶＥ伝送の終了処理が成功するまでは、記録したコンテンツを再生することはできないが、受信コンテンツを無効化した状態で記録する動作と並行して、受信コンテンツを再生出力（レンダリング）するように構成することも可能である。何故ならば、ＢＬＯＣＫ ＭＯＶＥがＤＴＣＰで既定する条件を満足するＭＯＶＥ処理であるとするならば、これに並行したレンダリング処理は、ＭＯＶＥ伝送用のＴＣＰコネクションと並行してコンテンツ・ストリーミング伝送用のＴＣＰコネクションを確立して、ストリーミング・データを再生出力することと等価であるからである。ＢＬＯＣＫ ＭＯＶＥに並行してレンダリング処理を行なう場合、ＴＣＰコネクションは１本で済むから通信路を節約することができる。また、ＳｏｕｒｃｅやＳｉｎｋの機器にとってはＭＯＶＥ伝送とレンダリングの双方の処理を単一のコンテンツ伝送処理で済ますことができるから負荷を軽減することになる。
【０１２９】
コンテンツのＭＯＶＥ処理と受信コンテンツの再生処理を並行して行なうためには、図２に示したＳｉｎｋ内のコンテンツ再生／記録ブロック３０を、コンテンツ再生ブロック３１とコンテンツ記録ブロック３２という２つの独立したモジュールとして構成すればよい。図７には、この場合の機能ブロック図を示している。
【０１３０】
コンテンツ復号ブロック１３では、ＡＫＥで交換した交換鍵Ｋxから算出されるコンテンツの復号鍵Ｋcを用いて、Ｓｏｕｒｃｅから受信した暗号化コンテンツを復号すると、これをコンテンツ再生ブロック３１とコンテンツ記録ブロック３２の各々に供給する。
【０１３１】
コンテンツ記録ブロック３２では、コンテンツをＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして規定の符号化処理を施して、まず無効化された状態でハード・ディスク又はその他の記録媒体（図示しない）に保存する。コンテンツ記録ブロック３２により保存された符号化コンテンツは、ＭＯＶＥ伝送全体が完了するまでは有効化されないので、記録媒体から読み出して復号して利用（例えばコンテンツ再生ブロックで再生）することはできない。また、コンテンツ記録ブロック３２を、コンテンツ復号ブロック１３と同様に、耐タンパ性のあるＤＴＣＰ−ＩＰ認証ブロック１０内に配置することで、コンテンツ復号ブロック１３とコンテンツ記録ブロック３２間での復号コンテンツの漏洩の問題はなくなる。
【０１３２】
一方、コンテンツ再生ブロック３１では、コンテンツ復号ブロック１３から供給されるコンテンツを、そのままビデオ及びオーディオ信号に変換（レンダリング）して、ディスプレイなどのＡＶ出力部から映像並びに音響出力する。このような復号コンテンツの出力は、出力とともにデータが失われるのでコンテンツのコピーには相当せず、ＳｏｕｒｃｅとＳｉｎｋの両方に重複して存在する再生可能なコンテンツがあってはならないというＤＴＣＰ規格に抵触しない。
【０１３３】
このようにＭＯＶＥ処理と並行して受信コンテンツの再生処理を実行することにより、ユーザは、ＭＯＶＥ伝送中にそのコンテンツの内容を確認するとともに、リアルタイムでコンテンツ視聴を享受することができる。
【０１３４】
ここで、ＳｏｕｒｃｅとＳｉｎｋ間のコンテンツ伝送が、コンテンツ再生ブロックにおける再生の実時間より高速に行なわれる場合には、コンテンツ再生ブロック３１はＡＶ出力用バッファ３３をローカルに備えていてもよい。上述したような並列処理を行なう際、コンテンツ復号ブロック１３から直接供給されるコンテンツをこのＡＶ出力用バッファ３３に蓄積し、ＦＩＦＯ形式で再生出力するようにすれば、コンテンツ再生ブロック３１を通じたコンテンツの実時間再生を行なうことができる。ＡＶ出力用バッファ３３の実装方法としては、コンテンツ再生ブロック３１専用のバッファ・メモリを設ける以外に、コンテンツ記録ブロック３２が持つハード・ディスクなどの記録媒体（図示しない）とＡＶ出力用バッファ３３とを統合し、ＡＶ出力用のコンテンツと記録用のコンテンツを一元化することも考えられる。
【０１３５】
本発明者らは、ＳｏｕｒｃｅとＳｉｎｋ間のＭＯＶＥ伝送を、ダウンロードとアップロードに大別して扱うことにしている。ここで言うダウンロードとは、Ｓｉｎｋを操作するユーザがＳｏｕｒｃｅからコンテンツをプル配信することを意味し、例えばＳｏｕｒｃｅがＨＴＴＰサーバとして動作するとともにＳｉｎｋがＨＴＴＰクライアントとして動作し、ＨＴＴＰ ＧＥＴメソッドを用いてＭＯＶＥシーケンスを実装することができる。また、アップロードとは、Ｓｏｕｒｃｅを操作するユーザがＳｉｎｋに対してコンテンツをプッシュ配信することを意味し、例えばＳｏｕｒｃｅがＨＴＴＰクライアントとして動作するとともにＳｉｎｋがＨＴＴＰサーバとして動作し、ＨＴＴＰ ＰＯＳＴメソッドを用いてＭＯＶＥシーケンスを実装することができる。最低限の相互運用を確保するには、単一のＨＴＴＰ ＧＥＴメソッド又はＰＯＳＴメソッドを用いたＭＯＶＥ伝送が推奨されるが、勿論、他のシーケンスを用いた実装が禁止されている訳ではない。
【０１３６】
従来のＤＴＣＰ−ＩＰではＳｉｎｋからコンテンツ伝送のトリガが発生するダウンロード形式でコピー伝送が行なわれるのが一般的であるが（例えば、図４を参照のこと）、以下ではダウンロード伝送とアップロード伝送それぞれの場合についてのＢＬＯＣＫ ＭＯＶＥ伝送シーケンスについて説明する。
【０１３７】
Ｃ−１．ダウンロード形式のＢＬＯＣＫ ＭＯＶＥ
図８には、ダウンロード形式でＳｏｕｒｃｅとＳｉｎｋ間のＢＬＯＣＫ ＭＯＶＥ伝送を行なう場合の動作シーケンスを示している。図示の通り、この場合のＭＯＶＥ伝送は、Ｓｏｕｒｃｅ及びコンテンツ選択、ＭＯＶＥ用ＡＫＥ手続き、コンテンツ移動（ＭＯＶＥ）手続き、ＭＯＶＥ終了処理手続きという４段階のフェーズで構成される。このうち、ＭＯＶＥ用ＡＫＥ手続き、コンテンツ移動（ＭＯＶＥ）手続き、ＭＯＶＥ終了処理手続きは、ＤＴＣＰ上で規定される手順に従って実行される。
【０１３８】
Ｓｏｕｒｃｅ及びコンテンツ選択のフェーズは、例えばＵＰｎＰ（登録商標）ベースで行なうことができ、この場合、ＳｉｎｋはＣＤＳ（ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ)を利用してコンテンツ情報を取得することができる。ＣＤＳは、ＵＰｎＰ（登録商標）メディア・サーバの主要なサービスの１つである。通常、ＳｉｎｋはＣＤＳを用いてコンテンツの閲覧や検索、コンテンツのメタデータの編集などを行なう。図９には、この場合のＳｏｕｒｃｅとＳｉｎｋ間の動作シーケンスを示している。
【０１３９】
まず、Ｓｉｎｋは、ＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｑｕｅｓｔを発行し、ＳｏｕｒｃｅからのＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｓｐｏｎｓｅによってコンテンツ一覧情報（ｃｏｎｔｅｎｔ ｌｉｓｔ ｉｎｆｏｒｍａｔｉｏｎ）を引き取ることができる。同図に示すように、このレスポンス内では、コンテンツはｉｔｅｍ ＩＤとｐａｒｅｎｔＩＤで識別され、コンテンツ毎に、コンテンツのタイトル、コンテンツのＵＰｎＰ（登録商標）クラス、ＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｑｕｅｓｔに対するレスポンス情報が記載されている。そして、レスポンス属性情報（ｒｅｓ ｐｒｏｔｏｃｏｌＩｎｆｏ ｐｒｏｐｅｒｔｙ）の第３フィールドにコンテンツ毎のソケット情報（ＤＴＣＰ Ｓｏｃｋｅｔ Ｉｎｆｏ）が記載されるとともに、別のレスポンス属性情報（ｒｅｓ＠ａｌｌｗｅｄＵｓｅ）でコンテンツがＭＯＶＥ伝送可能かどうかを示すＭｏｖａｂｌｅ情報が記載され、これらに続いてコンテンツの保管場所を示すＵＲＬが含まれている。なお、Ｍｏｖａｂｌｅ情報の記載手段はこれに限定されることはなく、例えばＤＴＣＰでレスポンス属性情報を定義してこれを用いることも考えられる。可能なＭＯＶＥ方法としてＢＬＯＣＫ ＭＯＶＥとＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥを個別に表現することも考えられる。
【０１４０】
図９に示す例では、Ｓｏｕｒｃｅは、ｒｅｓのｐｒｏｔｏｃｏｌＩｎｆｏアトリビュートの３番目のフィールドにソケット情報としての文字列“ＤＴＣＰ１ＨＯＳＴ＝（ｈｏｓｔ）；ＤＴＣＰ１ＰＯＲＴ＝（ｐｏｒｔ）”を記載するとともに、ａｌｌｏｗｅｄＵｓｅアトリビュートには当該コンテンツがＤＴＣＰ−ＩＰによりＭＯＶＥ可能であることを示す文字列“ＭＯＶＥ：１”を記載している。したがって、Ｓｉｎｋは、図示のレスポンス中から、ユーザが選択したコンテンツに関するｒｅｓタグ内のｐｒｏｔｏｃｏｌＩｎｆｏ並びにａｌｌｏｗｅｄＵｓｅの各アトリビュートの値を読み出すことで、コンテンツ毎のソケット情報と、コンテンツがＭＯＶＥ伝送可能かどうかを取得することができる。
【０１４１】
なお、ｒｅｓ＠ａｌｌｏｗｅｄＵｓｅはＤＴＣＰ規格で規定されているものではなく、“ＭＯＶＥ：１”の運用方法も詳細に定義されていないため、将来の定義内容にとっては不適切なものになるおそれがある。そこで、ｒｅｓ＠ａｌｌｏｗｅｄＵｓｅに代えて、「ＤＴＣＰ．ＣＯＭ＿ＦＬＡＧＳ ｐａｒａｍ」というパラメータをｒｅｓ＠ｐｒｏｔｏｃｏｌＩｎｆｏの第４フィールドに設けて、コンテンツのＭＯＶＥ伝送の可否を示すことが考えられる。ＤＴＣＰ．ＣＯＭ＿ＦＬＡＧＳ ｐａｒａｍは３２ビット長のフィールドであり、ビット定義は以下の通りとする。ビット３０に１が記載されているときには、ビット３１にも１が記載される。Ｓｉｎｋは予備のビット・フィールドを無視する。
【０１４２】
ビット３１：ＤＴＣＰに基づくＭＯＶＥ伝送可。
ビット３０：ＤＴＣＰ仕様書で規定されている条件を満足するＢＬＯＣＫ ＭＯＶＥプロトコルをサポートしている。
ビット２９〜０：予備
【０１４３】
ＤＴＣＰ．ＣＯＭ＿ＦＬＡＧＳ ｐａｒａｍはｒｅｓ＠ｐｒｏｔｏｃｏｌＩｎｆｏの第４フィールドに設けられ、３２ビット値が１６進数表記される。また、ＤＴＣＰ．ＣＯＭ＿ＦＬＡＧＳ ｐａｒａｍを用いた場合のｒｅｓ＠ｐｒｏｔｏｃｏｌＩｎｆｏアトリビュートの記述例は以下の通りとなる。
【０１４４】
【数１】
【０１４５】
Ｓｉｎｋは、１以上のＳｏｕｒｃｅからＣＤＳ：：Ｂｒｏｗｓｅレスポンスを引き取ると、Ｓｏｕｒｃｅの選択（Ｓｅｌｅｃｔ Ｓｏｕｒｃｅ）、選択したＳｏｕｒｃｅからＭＯＶＥすべきコンテンツの選択（Ｓｅｌｅｃｔ Ｃｏｎｔｅｎｔ）、並びに移動先の選択（Ｓｅｌｅｃｔ Ｄｅｓｔｉｎａｔｉｏｎ）を行なう。そして、Ｓｉｎｋ側でのコンテンツの選択に引き続いて、選択したコンテンツのＭＯＶＥ伝送処理が開始される。
【０１４６】
ＭＯＶＥ伝送に先駆けて、まずＳｏｕｒｃｅとＳｉｎｋ間の相互認証及びＭＯＶＥ用の鍵共有を行なうために、ＭＯＶＥ用ＡＫＥ手続きを実施する。ここでは、ＳｉｎｋからＳｏｕｒｃｅへＡＫＥトリガ情報が渡されるより前に、ＳｏｕｒｃｅはＳｉｎｋからのＡＫＥを受け付けられる状態になっているものとする。本実施形態では、通常のＤＴＣＰ−ＩＰにおけるＡＫＥ手続（前述並びに図４を参照のこと）と同様の手順に従ってＳｏｕｒｃｅとＳｉｎｋ間の相互認証と、コンテンツ復号鍵の元となる種鍵を共有するための処理を実行する。但し、ＭＯＶＥ実行時には、通常のコンテンツ伝送時とは異なる交換鍵ＫxMを生成し、且つ、１回のＭＯＶＥ伝送毎に交換鍵を消滅させるようにしている。これによって、ＭＯＶＥ伝送をコピー伝送と偽装してコンテンツのコピー動作を行なうことをより困難にすることができる。
【０１４７】
図１０には、ＭＯＶＥ用ＡＫＥ手続きの動作シーケンスを示している。図示のように、チャレンジ・レスポンス認証手続を用いて手続きが行なわれる。Ｓｏｕｒｃｅは、ＳｉｎｋからＭＯＶＥ用のチャレンジ要求（ＭＶ−ＣＨＡＬＬＥＮＧＥ）に応答して、１回のＭＯＶＥ用ＡＫＥ手続毎に、ＭＯＶＥ用の交換鍵ＫXMを生成し、後続のレスポンスを経て、ＳｏｕｒｃｅとＳｉｎｋ間で鍵ＫXM及びＫXM_labelの共有が実現する。但し、ＥＸＣＨＡＮＧＥ ＫＥＹコマンドでは、通常のＡＫＥ手続の場合とは異なるスクランブル方法が適用され、ＭＯＶＥ伝送をコピー伝送と偽られるのを防止する。
【０１４８】
鍵ＫXM及びＫXM_labelの生成方法は、通常のコンテンツ伝送時（前述並びに図４を参照のこと）と同様なので、ここでは詳細な説明を省略する。また、鍵ＫXM及びＫXM_labelを消滅させる規則も鍵ＫX及びＫX_labelの場合と同様なので、説明を省略する。
【０１４９】
ＳｏｕｒｃｅとＳｉｎｋはともに、１回のＭＯＶＥ手続が終了する度に、当該ＭＯＶＥ手続き用の鍵ＫXM及びＫXM_labelを消滅させる。
【０１５０】
図２７には、ＭＯＶＥ用ＡＫＥ手続きの他の動作シーケンス例を示している。図示の例では、Ｓｉｎｋは、ＭＶ−ＩＮＩＴＩＡＴＥコマンドを送信するというＭＯＶＥプロトコルを用いて、ＭＯＶＥ伝送を初期化して、ＭＯＶＥ ＲＴＴ−ＡＫＥプロセスを起動する。ＲＴＴ−ＡＫＥプロセスでは、通常のＡＫＥと同じ手順を追って、チャレンジ−レスポンス手続きによる相互認証が行なわれる。ＲＴＴによればＳｉｎｋ及びＳｏｕｒｃｅのＬｏｃａｌｉｚａｔｉｏｎチェックが行なわれるが、本発明の要旨には直接関連しない。そして、ＭＶ＿ＥＸＣＨＡＮＧＥ＿ＫＥＹコマンドによって交換鍵の共有が行なわれる。
【０１５１】
既に述べたように、本実施形態に係るコンテンツ伝送システムでは、コンテンツのＭＯＶＥモードとして、ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥとＢＬＯＣＫ ＭＯＶＥの２種類を備えている。ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥはＤＴＣＰ−ＩＰで取り決められたＭＯＶＥ伝送により実装することが可能である。これに対し、ＢＬＯＣＫ ＭＯＶＥは現在の仕様に含まれている訳ではない。そこで、例えばＭＯＶＥ用ＡＫＥ手続きを行なう際に、互いの機器がＢＬＯＣＫ ＭＯＶＥに対応しているかどうか、すなわちケイパビリティを確認することが好ましい。
【０１５２】
図１６には、ケイパビリティの確認シーケンスを含んだＭＯＶＥ用ＡＫＥ手続きの動作シーケンス例を示している。図示の例では、ＭＯＶＥ用のチャレンジ・レスポンス認証手続きを行なう前に、ＳｉｎｋとＳｏｕｒｃｅ間で互いのケイパビリティを交換する手続き（ＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥ）が実行される。
【０１５３】
図１７には、図１６中のケイパビリティ交換手続きの部分をさらに詳細に示している。このコマンド／レスポンスに使用されるメッセージは、それぞれの機器が持つケイパビリティを記述したＣＡＰＡＢＩＬＩＴＹフィールドと、ＣＡＰＡＢＩＬＩＴＹフィールドに対する電子署名で構成される。
【０１５４】
メッセージの先頭１ビットはＳｉｎｋ又はＳｏｕｒｃｅを識別するために使用される。機器がＳｉｎｋとしてのケイパビリティを送る場合には１を記載し、Ｓｏｕｒｃｅとしてのケイパビリティを送る場合には０を記載する。これによって、ＳｏｕｒｃｅとしてのケイパビリティのようにＳｉｎｋとしてのケイパビリティを送り（あるいはその逆の振る舞いをし）、ケイパビリティの詐称をすることを防止する。ＣＡＰＡＢＩＬＩＴＹフィールドの末尾のフィールドを使って、機器がＭＯＶＥ（若しくはＢＬＯＣＫ ＭＯＶＥ）に対応しているかどうかを記載する。
【０１５５】
電子署名は、メッセージ先頭のＳｉｎｋ／ＳｏｕｒｃビットとＣＡＰＡＢＩＬＩＴＹフィールドに対して各機器の秘密鍵で求めた電子署名で構成される。ＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥコマンドを受け取ったＳｏｕｒｃｅは、Ｓｉｎｋの公開鍵を使って署名を検証し、ＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥレスポンスを受け取ったＳｉｎｋはＳｏｕｒｃｅの公開鍵を使って署名を検証することができる。
【０１５６】
例えば、ＳｉｎｋがＢＬＯＣＫ ＭＯＶＥモードでのコンテンツのＭＯＶＥを要求するときに、まず、Ｓｉｎｋ側からＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥコマンドが発行され、これに対し、ＳｏｕｒｃｅからはＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥレスポンスが返される。いずれか一方の機器がＢＬＯＣＫ ＭＯＶＥに対応していない場合には、従来のＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥにモードを切り替えてコンテンツのＭＯＶＥ処理を行なうようにしてもよい。
【０１５７】
ＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥシーケンスは、ＭＯＶＥ伝送モード詐称攻撃に対する対策として十分である。但し、この種の詐称攻撃に対する他の対策がとられている場合には、ＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥシーケンスを通じたセキュアな情報交換手続は不要となる。
【０１５８】
ＭＯＶＥ伝送用のＡＫＥ手続きが無事に完了すると、続いてコンテンツ移動（ＭＯＶＥ伝送）手続きが開始される。Ｓｉｎｋ側のユーザ操作によりＳｏｕｒｃｅからコンテンツをＭＯＶＥ伝送する場合、ＳｏｕｒｃｅがＨＴＴＰサーバとして動作するとともにＳｉｎｋがＨＴＴＰクライアントとして動作し、ＨＴＴＰプロトコルを用いてダウンロードＭＯＶＥ伝送を行なうようにすれば良い。コンテンツのデータ・エンティティの伝送自体には、ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥもＢＬＯＣＫ ＭＯＶＥも同様に行なうことができるが、いずれの場合もＨＴＴＰプロトコルを使用することができる。すなわち、ＨＴＴＰクライアントとしてのＳｉｎｋはＨＴＴＰ ＧＥＴリクエストを用いてコンテンツを要求し、これに対し、ＨＴＴＰサーバとしてのＳｏｕｒｃｅはＨＴＴＰ ＧＥＴレスポンスを用い、コンテンツ選択フェーズで選択されたコンテンツのＭＯＶＥ伝送を行なうことができる。ＧＥＴは、特定のＵＲＩから情報を取得する際に、リクエストとして送信するＨＴＴＰメソッドである（周知）。
【０１５９】
図２８には、ＨＴＴＰプロトコルを用いてコンテンツをダウンロードＭＯＶＥ伝送する場合の動作シーケンスを例示している。例えば図２７に示したＭＯＶＥ ＲＴＴ−ＡＫＥ手続が無事に完了すると、ＨＴＴＰクライアントとして動作するＳｉｎｋは、ＨＴＴＰ ＧＥＴリクエストを送信することによって、ＭＯＶＥ伝送プロセスを初期化する。
【０１６０】
ＨＴＴＰプロトコルを用いてコンテンツをダウンロードＭＯＶＥ伝送するとき、Ｓｏｕｒｃｅは、Ｅ−ＥＭＩのモードをＣ１（すなわちＭＯＶＥモード（表１を参照のこと））に設定する。Ｓｉｎｋは、Ｃ１以外のＥ−ＥＭＩモードを受け取ったときには、受信したコンテンツをＭＯＶＥ対象として扱わない。
【０１６１】
Ｓｉｎｋは、ＨＴＴＰのＧＥＴリクエストのヘッダに“ＭＯＶＥ．ｄｔｃｐ．ｃｏｍ：＜ＫｘＭ＿ｌａｂｅｌ＞”（若しくは、“ＭＯＶＥ．ｄｔｃｐ．ｃｏｍ”ではなく“ＢＬＫＭＯＶＥ．ｄｔｃｐ．ｃｏｍ”）というヘッダ情報を設定したＨＴＴＰ ＧＥＴリクエストを送信して、ダウンロードＭＯＶＥ伝送を開始する。Ｓｏｕｒｃｅは、このヘッダ情報を検知したら、リクエストされたコンテンツを鍵ＩＤであるＫxM_labelに対応するＭＯＶＥ用の鍵ＫXMから得た暗号鍵Ｋcで暗号化し、Ｅ−ＥＭＩをＣ１に設定してＧＥＴレスポンスとして伝送する。
【０１６２】
図１４Ａ及び図１４Ｂには、ＨＴＴＰサーバとしてのＳｏｕｒｃｅからＨＴＴＰクライアントとしてのＳｉｎｋへコンテンツをダウンロードＭＯＶＥ伝送する場合のＳｏｕｒｃｅ及びＳｉｎｋがそれぞれ実行する処理動作をフローチャートの形式でまとめている。
【０１６３】
Ｓｉｎｋは、ＨＴＴＰサーバとして動作するＳｏｕｒｃｅを発見して、そこからコンテンツをＭＯＶＥすることを選択すると（ステップＳ２１）、当該Ｓｏｕｒｃｅ宛てにＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｑｕｅｓｔを送信し(ステップＳ２２)、Ｓｏｕｒｃｅからのレスポンスを待機する（ステップＳ２３）。
【０１６４】
Ｓｏｕｒｃｅ側では、ＳｉｎｋからのＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｑｕｅｓｔ又はその他のリクエストの受信を待機しており（ステップＳ１）、当該リクエストを受信すると、Ｓｉｎｋに対してＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｓｐｏｎｓｅを返信し（ステップＳ２）、ＭＯＶＥ用のＡＫＥ要求を受信するまで待機する（ステップＳ３）。
【０１６５】
Ｓｉｎｋは、ＳｏｕｒｃｅからのＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｓｐｏｎｓｅによってコンテンツ一覧を引き取ると、ＭＯＶＥしようとするコンテンツを決定するとともに（ステップＳ２４）、Ｓｏｕｒｃｅに対してＭＯＶＥ用のＡＫＥ処理を要求する（ステップＳ２５）。
【０１６６】
そして、ＳｉｎｋとＳｏｕｒｃｅ間では、ＭＯＶＥ用のＡＫＥ手続きが開始され、互いにＭＯＶＥ用のＡＫＥ処理を実行する（ステップＳ４、Ｓ２６）。ＭＯＶＥ用のＡＫＥの認証に成功すると（ステップＳ５、Ｓ２７）、ＳｏｕｒｃｅはＭＯＶＥ用の鍵と鍵ＩＤを生成してＳｉｎｋに送信し（ステップＳ６）、ＳｉｎｋはＳｏｕｒｃｅからＭＯＶＥ用の鍵と鍵ＩＤを受信する（ステップＳ２８）。但し、ＳｏｕｒｃｅとＳｉｎｋ間でＭＯＶＥ用のＡＫＥの認証に失敗すると、ＳｏｕｒｃｅとＳｉｎｋはともに、後続の処理をすべてスキップして、本処理ルーチン全体を終了する。
【０１６７】
Ｓｉｎｋは、ＭＯＶＥ用ＡＫＥ手続きを成功裏に終えると、 “ＭＯＶＥ．ｄｔｃｐ．ｃｏｍ：＜ＫｘＭ＿ｌａｂｅｌ＞”（若しくは、“ＭＯＶＥ．ｄｔｃｐ．ｃｏｍ”ではなく“ＢＬＫＭＯＶＥ．ｄｔｃｐ．ｃｏｍ”）というヘッダ情報を伴った、ＨＴＴＰ ＧＥＴリクエストを送信する（ステップＳ２９）。
【０１６８】
Ｓｏｕｒｃｅは、ＳｉｎｋからＭＯＶＥ用ヘッダを伴うＨＴＴＰ ＧＥＴリクエストを受信すると（ステップＳ７）、当該リクエストで要求されているコンテンツが他のＳｉｎｋに対してＭＯＶＥしている最中かどうかをチェックする（ステップＳ８）。そして、ＭＯＶＥ伝送中であれば、エラー応答をＳｉｎｋに返す（ステップＳ１５）。
【０１６９】
Ｓｉｎｋ側では、ＳｏｕｒｃｅからのＨＴＴＰ ＧＥＴレスポンスの受信を待機する（ステップＳ３０）。この受信待機中に、要求したコンテンツをＭＯＶＥできない旨のエラー応答をＳｏｕｒｃｅから受信すると（ステップＳ３１）、ここで本処理ルーチン全体を終了する。
【０１７０】
また、Ｓｏｕｒｃｅは、ＳｉｎｋからＭＯＶＥ要求されているコンテンツが他のＳｉｎｋに対してＭＯＶＥ伝送中ではなく、当該Ｓｉｎｋに対してＭＯＶＥ伝送することができるときには、当該コンテンツに対して「ＭＯＶＥ伝送中」フラグをセットしてから（ステップＳ９）、当該コンテンツをＭＯＶＥ用の鍵を用いて暗号化して、要求元Ｓｉｎｋ宛てに送信する（ステップＳ１０）。「ＭＯＶＥ伝送中」フラグをセットすると、当該コンテンツはロック状態となる。そして、暗号化コンテンツの伝送処理を終了すると、ＳｉｎｋからのＭＯＶＥ終了処理の要求の受信を待機する（ステップＳ１１）。
【０１７１】
Ｓｉｎｋは、Ｓｏｕｒｃｅから暗号化コンテンツを成功裏にダウンロードすることができたならば（ステップＳ３２）、Ｓｏｕｒｃｅに対してＭＯＶＥ終了処理の要求を送信する（ステップＳ３３）。そして、ＳｏｕｒｃｅとＳｉｎｋは、それぞれＭＯＶＥ終了処理手続きを実行して（ステップＳ１２、Ｓ３４）、Ｓｉｎｋ側でコンテンツを有効化するとともに、Ｓｏｕｒｃｅ側の元のコンテンツを削除する。Ｓｏｕｒｃｅ及びＳｉｎｋ間におけるＭＯＶＥ伝送終了処理手続きの動作シーケンスの詳細については後述に譲る。
【０１７２】
そして、ＳｏｕｒｃｅとＳｉｎｋは、ＭＯＶＥ終了処理手続きを完了すると（ステップＳ１３、Ｓ３５）、いずれもＭＯＶＥ用の鍵と鍵ＩＤを破棄して（ステップＳ１４、Ｓ３６）、本処理ルーチン全体を終了する。
【０１７３】
図１４Ａ及び図１４Ｂに示したダウンロードＭＯＶＥ処理手続きの期間中、ＭＯＶＥ対象となるコンテンツを他のＳｉｎｋからＭＯＶＥ要求できないようにロックして、多重ＭＯＶＥの発生を防止する。ダウンロードによりＭＯＶＥを行なう場合、Ｓｏｕｒｃｅはサーバに相当するが、保持する個々のコンテンツについてＭＯＶＥ伝送中であるかどうかを、例えば下記の表２に示すようなテーブルを使って管理する。同表では、コンテンツを特定するＵＲＩと、それがＭＯＶＥ伝送中かどうかを示すフラグを関係付けて、コンテンツの状態を確認することができるようになっている。また、Ｓｏｕｒｃｅは、ダウンロードによりコンテンツのＭＯＶＥを要求する他のＳｉｎｋに対して、ＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｓｐｏｎｓｅでＭＯＶＥ伝送中のコンテンツについては存在を示さないことで、混乱を防止することができる（視聴途中でのＭＯＶＥ完了による伝送中断など）。
【０１７４】
【表２】
【０１７５】
また、Ｓｉｎｋは、ＢＬＯＣＫ ＭＯＶＥモードでダウンロードＭＯＶＥ伝送処理が行なわれている期間中は、コンテンツはまだ有効化されていないので、リアルタイムでレンダリングする以外の目的で受信したコンテンツを利用することはできない。リアルタイム・レンダリングの仕組みについては、図７を参照しながら既に説明したので、ここでは説明を省略する。
【０１７６】
なお、ＭＯＶＥ用ＡＫＥ手続き並びにコンテンツ移動（ＭＯＶＥ）手続きの期間中には、ＭＯＶＥ伝送を途中で取り止めるＣａｎｃｅｌやＡｂｏｒｔといった中断処理が起動することがあるが、この点の詳細については後述に譲る。
【０１７７】
ＳｉｎｋがＨＴＴＰプロトコルのＧＥＴリクエストにより、選択したＳｏｕｒｃｅから所望のコンテンツを成功裏にダウンロードすることができたならば、ＳｉｎｋとＳｏｕｒｃｅ間でコンテンツ伝送が無事に終了したことの確認すなわちＣｏｍｍｉｔｍｅｎｔを行なうためのＭＯＶＥ終了処理手続きを実施する。この終了処理では、Ｓｉｎｋ側ではこのダウンロードしたコンテンツを有効化すると同時に、Ｓｏｕｒｃｅ側では元のコンテンツの削除を行なう。また、ＳｉｎｋとＳｏｕｒｃｅはそれぞれ、コンテンツ伝送に使用した交換鍵の削除を行なう。ＢＬＯＣＫ ＭＯＶＥモードでは、このようなＣｏｍｍｉｔｍｅｎｔを実施することで、コンテンツ全体を一括してＳｏｕｒｃｅとＳｉｎｋ間で移動することと等価なＭＯＶＥ処理を実現することができる。ＢＬＯＣＫ ＭＯＶＥも、ＳｏｕｒｃｅとＳｉｎｋで同じコンテンツが二重に存在することはないから、ＤＴＣＰで規定されている条件を満たしたコンテンツのＭＯＶＥ処理であると言える。
【０１７８】
図１１には、Ｓｏｕｒｃｅ及びＳｉｎｋ間でＭＯＶＥ終了処理手続きを実行する動作シーケンスを示している。図示の動作シーケンスは、図１４Ｂに示したフローチャートのステップＳ１２並びにＳ３４において実施される。
【０１７９】
Ｓｉｎｋは、ＭＯＶＥ対象となるコンテンツを無事に受信し終えると、Ｓｏｕｒｃｅからレスポンスを受け取るまで、ＭＯＶＥ終了処理用コマンドＣＭＤ１（若しくはＭＶ＿ＦＩＮＡＬＩＺＥコマンド）を送信し続ける。
【０１８０】
一方、Ｓｏｕｒｃｅは、ＭＯＶＥ終了処理用コマンドＣＭＤ１を受信すると、ＭＯＶＥ終了処理用レスポンスＲＳＰ１を返信する。また、Ｓｏｕｒｃｅは、有効状態（Ｖａｌｉｄ）であった元のコンテンツを、中間的（ｉｎｔｅｒｉｍ）な無効状態（Ｉｎｖａｌｉｄ）に遷移させる。
【０１８１】
Ｓｉｎｋは、受信したＲＳＰ１において、Ｓｏｕｒｃｅが既にＭＯＶＥ処理手続を終了していると記載されていれば、同様にＭＯＶＥ処理手続を終了する。これに伴って、ＳｏｕｒｃｅからＭＯＶＥしたコンテンツを無効状態から有効状態に遷移させる。
【０１８２】
続いて、Ｓｉｎｋは、Ｓｏｕｒｃｅからレスポンスを受け取るまで、次のＭＯＶＥ終了処理用コマンドＣＭＤ２（若しくは、ＭＶ＿ＣＯＭＰＬＥＴＥコマンド）を送信し続ける。これに対し、Ｓｏｕｒｃｅは、元のコンテンツを中間的な無効状態から完全な無効状態に遷移させてから、ＭＯＶＥ終了処理用レスポンスＲＳＰ２を返信する。
【０１８３】
図１８には、図１１に示したダウンロードＭＯＶＥ伝送終了シーケンス上でＳｉｎｋ及びＳｏｕｒｃｅがそれぞれ実施する処理内容をフローチャートの形式で具体的に示している。
【０１８４】
Ｓｉｎｋ側では、まず乱数Ｒを生成し（ステップＳ８１）、この乱数Ｒに対し所定の演算処理を適用して、メッセージ・ダイジェストＭＡＣ５Ａ及びＭＡＣ６Ａを計算する。ＭＡＣ５ＡはＳｏｕｒｃｅに渡す値、ＭＡＣ６ＡはＳｏｕｒｃｅから返されることが期待される値である。ＭＡＣ５Ａ及びＭＡＣ６Ａの計算式は、例えば以下の通りである。この計算には、ＫxM_labelに対応するＫxMが使用される。
【０１８５】
【数２】
【０１８６】
続いて、Ｓｉｎｋは、鍵ＩＤであるＫxM_labelと乱数Ｒ、ＭＡＣ５Ａ、ＭＡＣ６Ａ、ＭＯＶＥしたコンテンツのＩＤ、ＳｏｕｒｃｅのＩＤを不揮発的に格納する（ステップＳ８２）。これらのデータを不揮発的に格納しておくことにより、電源遮断などによりコンテンツ伝送終了処理が途切れても、再開処理が可能となり、ＳｉｎｋとＳｏｕｒｃｅの双方でコンテンツが無効になることを避けることができる。
【０１８７】
そして、Ｓｉｎｋは、ＫxM_labelと乱数Ｒ、ＭＡＣ５Ａを含んだＭＯＶＥ終了用コマンドＣＭＤ１（若しくは、ＭＶ＿ＦＩＮＡＬＩＺＥコマンド）をＳｏｕｒｃｅに送信する。Ｓｉｎｋは、Ｓｏｕｒｃｅからレスポンスを受け取るまでは、受信タイムアウトが発生する度にＣＭＤ１を送信し続ける（ステップＳ８３）。
【０１８８】
一方、Ｓｏｕｒｃｅは、ＭＯＶＥ用コマンドＣＭＤ１を受け取ると、これに含まれる乱数Ｒに対し所定の演算処理（同上）を適用して、メッセージ・ダイジェストＭＡＣ５Ｂ及びＭＡＣ６Ｂを計算する。ＭＡＣ６ＢはＳｉｎｋに渡す値、ＭＡＣ５ＢはＳｉｎｋから得られることが期待される値である。そして、Ｓｏｕｒｃｅは、ＣＭＤ１に含まれるＭＡＣ５Ａと、自ら求めたＭＡＣ５Ｂを照合して、コマンドの真正性をチェックする（ステップＳ９１）。このチェックに失敗したときには、コンテンツ伝送終了処理を中止（Ａｂｏｒｔ）する。但し、Ｓｏｕｒｃｅは自身のソケット情報が途中で変化したことが原因でＳｉｎｋがＣＭＤ１の送信先を誤った可能性がある場合は、処理を中止せずにＣＭＤ１を待ち続けても良い。
【０１８９】
また、Ｓｏｕｒｃｅは、真正性のチェックに成功したときには、鍵ＩＤであるＫxM_labelとＭＡＣ６Ｂ、ＭＯＶＥしたコンテンツのＩＤを不揮発的に格納する（ステップＳ９２）。これらのデータを不揮発的に格納しておくことにより、電源遮断などによりコンテンツ伝送終了処理が途切れても、再開処理が可能となり、ＳｉｎｋとＳｏｕｒｃｅの双方でコンテンツが無効になることを避けることができる（同上）。
【０１９０】
そして、Ｓｏｕｒｃｅは、有効状態であった元のコンテンツを、中間的な無効状態に遷移させてから（ステップＳ９３）、ＣＭＤ１を受理したこと（Ａｃｃｅｐｔｅｄ）を示すＭＯＶＥ終了処理用レスポンスＲＳＰ１を返信する。
【０１９１】
Ｓｉｎｋは、ＳｏｕｒｃｅからＭＯＶＥ終了処理用レスポンスＲＳＰ１を受信すると、ＣＭＤ１が拒絶（Ｒｅｊｅｃｔｅｄ）されていないかどうかをチェックする（ステップＳ８４）。ＲＳＰ１がＡｃｃｅｐｔｅｄを示している場合には、さらにＲＳＰ１に含まれるＭＡＣ６Ｂが自ら保持しているＭＡＣ６Ａと一致するかどうかをチェックする（ステップＳ８５）。そして、これらのチェックに成功すると、ＳｏｕｒｃｅからＭＯＶＥしたコンテンツを無効状態から有効状態に遷移させる（ステップＳ８６）。
【０１９２】
続いて、Ｓｉｎｋは、鍵ＩＤであるＫxM_labelを含んだＭＯＶＥ終了用コマンドＣＭＤ２（若しくは、ＭＶ＿ＣＯＭＰＬＥＴＥコマンド）をＳｏｕｒｃｅに送信する。Ｓｉｎｋは、Ｓｏｕｒｃｅからレスポンスを受け取るまでは、受信タイムアウトが発生する度にＣＭＤ２を送信し続ける（ステップＳ８７）。
【０１９３】
Ｓｏｕｒｃｅは、ＭＯＶＥ終了処理用コマンドＣＭＤ２を受信すると、これに含まれるＫxM_labelに対応するデータを削除する（ステップＳ９４）。ここで言うデータとは、ステップＳ９２で不揮発的に格納しておいたＫxM_labelとＭＡＣ６Ｂ、ＭＯＶＥしたコンテンツのＩＤのことである。そして、Ｓｏｕｒｃｅは、ＭＯＶＥ終了処理用レスポンスＲＳＰ２を返信する。
【０１９４】
Ｓｉｎｋは、ＭＯＶＥ終了処理用レスポンスＲＳＰ２を受信すると、これに含まれるＫxM_labelに対応するデータを削除する（ステップＳ８８）。ここで言うデータとは、ステップＳ８２で不揮発的に格納しておいたＫxM_labelと乱数Ｒ、ＭＡＣ５Ａ、ＭＡＣ６Ａ、コンテンツのＩＤ、ＳｏｕｒｃｅのＩＤのことである。
【０１９５】
ダウンロードＭＯＶＥ伝送が終了した後にＳｉｎｋ側でコンテンツを有効化する方法は特に限定されない。有効化すると、Ｓｉｎｋ内のコンテンツ記録ブロックでＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして符号化して記録されたコンテンツの利用が可能となる（例えば、記録時に適用した暗号の解除が可能となる）。この結果、コンテンツ再生ブロック３１に符号化コンテンツを供給して、ビデオ及びオーディオ信号に変換（ｒｅｎｄｅｒｉｎｇ）して、ディスプレイなどのＡＶ出力部から映像並びに音響出力することができる。また、Ｓｉｎｋは、今度はＳｏｕｒｃｅとしてさらに別のＳｉｎｋに対して、Ｎｏ ｍｏｒｅ Ｃｏｐｉｅｓコンテンツを上述と同様にダウンロード形式でＭＯＶＥしたり、あるいは後述するアップロード形式でＭＯＶＥしたりすることもできる。
【０１９６】
また、ダウンロードＭＯＶＥ伝送が終了した後にＳｏｕｒｃｅ側で元のコンテンツを削除する方法も特に限定されない。コンテンツを格納したハード・ディスクなどの記録媒体からコンテンツ・データのエンティティ自体を削除する以外に、符号化（暗号化）して記録されているコンテンツのエンティティは残すが復号鍵を再び使用できないようにするのであってもよい。
【０１９７】
ここで、ＳｏｕｒｃｅからＳｉｎｋへコンテンツのエンティティが成功裏にダウンロードＭＯＶＥ伝送されたにも拘らず、一方の機器の電源遮断などにより図１１に示したダウンロードＭＯＶＥ伝送の終了処理シーケンスが途切れてしまう可能性がある。このような場合、ダウンロードＭＯＶＥ伝送の終了処理の中断（ｉｎｔｅｒｒｕｐｔｅｄ）によって、Ｓｏｕｒｃｅ及びＳｉｎｋの双方において移動したコンテンツを利用できなくなるおそれがある。そこで、本実施形態に係るコンテンツ伝送システムでは、このような事態に備えて、コンテンツ伝送終了処理を再開するための処理手続きを設けて、Ｃｏｍｍｉｎｍｅｎｔを無事に終了させるようにしている。この再開手続きによって、コンテンツ伝送手続きが無駄にならずに済むとともに、ＳｉｎｋとＳｏｕｒｃｅの双方でコンテンツが無効になることを避けることができる。
【０１９８】
ダウンロードＭＯＶＥ伝送の終了処理の再開を可能にするために、Ｓｉｎｋ及びＳｏｕｒｃｅの各々では、ダウンロードＭＯＶＥ伝送の終了処理を開始する際に、ＮＶＲＡＭなどの不揮発性メモリを用いて、再開処理に必要となるデータを保存するようにしている。Ｓｉｎｋ側では、ＣＭＤ１すなわちＭＶ＿ＦＩＮＡＬＩＺＥコマンドを発行する際に、そのコマンドで送信するＫXM_lable、乱数Ｒ、ＭＡＣ５Ａ、さらにＭＡＣ６Ａ、ダウンロードＭＯＶＥしたコンテンツのＩＤ（ＣＤＳのオブジェクトＩＤに相当）、ＳｏｕｒｃｅのＩＤ（ＵＰｎＰ（登録商標）のＵＵＩＤに相当）を不揮発的に格納する（図１８中のステップＳ８２を参照）。一方、Ｓｏｕｒｃｅ側では、鍵ＩＤであるＫxM_labelとＭＡＣ５Ｂ、ＭＡＣ６Ｂを不揮発的に格納する（図１８中のステップＳ９２を参照）。再開処理は、基本的にはＳｉｎｋ側が起動する。
【０１９９】
Ｓｉｎｋは、ＵＰｎＰ Ｄｅｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅで規定されているＵＵＩＤを記憶しておくことにより、ＣＤＳ処理のクエスト先であるＳｏｕｒｃｅを発見することが可能であり、また、ＵＰｎＰ ＡＶ ＣＤＳ２で規定されているＯｂｊｅｃｔ ＩＤを記憶しておくことにより、ＭＯＶＥ対象コンテンツを指定することが可能である。そして、中断したＭＯＶＥ処理を再開する際、Ｓｉｎｋは、最初にコンテンツを選択するときと同様にＵＰｎＰ（登録商標）のＣＤＳの処理をすることで、ＭＯＶＥ対象となるコンテンツに対するソケット情報を得ることができる。例えばＳｏｕｒｃｅが電源遮断して、再開時にそのＩＰアドレスが変更してしまっても問題はない。
【０２００】
Ｓｉｎｋは、ＭＯＶＥ対象コンテンツのソケット情報を得ると、続いて、該当するＳｏｕｒｃｅとのＴＣＰコネクションを確立する。図２９には、ＭＯＶＥ伝送終了処理を再開する際に、Ｓｉｎｋ及びＳｏｕｒｃｅ間でＴＣＰコネクションを確立するための処理手順をフローチャートの形式で示している。
【０２０１】
Ｓｉｎｋは、不揮発に記憶しているＳｏｕｒｃｅＩＤ（ＵＵＩＤ）を１つ選択すると（ステップＳ１３１）、ＵＰｎＰのデバイス発見のプロトコル（ＳＳＤＰ）により、同じＵＵＩＤを持つ機器が存在するかどうかをチェックする（ステップＳ１３２）。ここで、同じＵＵＩＤを持つ機器が存在しなければ、後続の処理をすべてスキップして、本処理ルーチン全体を終了する。
【０２０２】
一方、同じＵＵＩＤを持つ機器が存在する場合には（ステップＳ１３２のＹｅｓ）、その機器に対してＣＤＳ：：ＢｒｏｗｓｅリクエストをＯｂｊｅｃｔ ＩＤ指定付きで送信する（ステップＳ１３３）。
【０２０３】
Ｓｏｕｒｃｅは、ＳｉｎｋからＣＤＳ：：Ｂｒｏｗｓｅリクエストを受信すると（ステップＳ１４１）、該当するコンテンツについてコンテンツ伝送終了処理が完了していない旨の情報を含んだＣＤＳ：：Ｂｒｏｗｓｅレスポンスを返信する（ステップＳ１４２）。
【０２０４】
なお、コンテンツ伝送終了処理が完了していないということは、例えばコンテンツがＭｏｖａｂｌｅであることを示す属性情報を含めない、あるいはＨＴＴＰ ＧＥＴリクエストを送るべきＵＲＬを含めない、ＭＯＶＥ処理を実行中という属性情報を含める、といった方法で示すことができる。
【０２０５】
そして、Ｓｉｎｋは、ＣＤＳ：：Ｂｒｏｗｓｅレスポンスを受信すると（ステップＳ１３４）、当該メッセージに含まれるソケット情報を参照して、ＣＭＤ１、ＣＭＤ２などのＡＫＥコマンド用のＴＣＰコネクションを確立する（ステップＳ１３５）。
【０２０６】
Ｓｉｎｋは、このようにしてＡＫＥコマンド用のＴＣＰコネクションを確立すると、不揮発的に格納しておいた鍵ＩＤであるＫxM_labelと乱数Ｒ、ＭＡＣ５Ａを参照して、ＣＭＤ１（ＭＶ＿ＦＩＮＡＬＩＺＥコマンド）又はＣＭＤ２（ＭＶ＿ＣＯＭＰＬＥＴＥコマンド）をＳｏｕｒｃｅに送信する。これに対し、Ｓｏｕｒｃｅは、同様に不揮発的に格納しておいたＫxM_labelとＭＡＣ６Ｂを用いてＣＭＤ１に対するレスポンスＲＳＰ１又はＣＭＤ２に対するレスポンスＲＳＰ２を返す。これによって、ＳｉｎｋとＳｏｕｒｃｅ間のダウンロードＭＯＶＥ伝送の終了処理を完結することができる。
【０２０７】
図１９には、図１１並びに図１８に示したダウンロードＭＯＶＥ伝送の終了処理シーケンスが何らかの原因により中断（ｉｎｔｅｒｒｕｐｔｅｄ）した後、ＳｏｕｒｃｅがＳｉｎｋからＭＯＶＥ終了処理用コマンドＣＭＤ１を受け取ったときの処理手順をフローチャートの形式で示している。
【０２０８】
Ｓｏｕｒｃｅは、ＭＯＶＥ終了処理用コマンドＣＭＤ１に含まれるＫxM_labelを自分が不揮発的に格納しているかどうかをチェックする（ステップＳ１０１）。
【０２０９】
ここで、ＫxM_labelを保持していないときには、Ｓｏｕｒｃｅは既に該当するコンテンツ伝送終了処理を完了しているか、又はＣＭＤ１が自分とは無関係であることが想定されるので、当該コマンドを拒絶すること（Ｒｅｊｅｃｔｅｄ）を示すＭＯＶＥ終了処理用レスポンスＲＳＰ１を返す（ステップＳ１０４）。
【０２１０】
一方、ＫxM_labelを保持しているときには、該当するコンテンツ伝送終了処理が中断していたことになるので、Ｓｏｕｒｃｅは、ＣＭＤ１内のコンテンツＩＤで示される元のコンテンツを中間的な無効状態に遷移させてから（ステップＳ１０２）、ＣＭＤ１を受理したこと（Ａｃｃｅｐｔｅｄ）を示すＭＯＶＥ終了処理用レスポンスＲＳＰ１を返信する（ステップＳ１０３）。このようにして、中断したＭＯＶＥ終了処理をＨＴＴＰサーバとして動作するＳｏｕｒｃｅにおいて再開することができる。
【０２１１】
また、図２０には、図１１並びに図１８に示したダウンロードＭＯＶＥ伝送の終了処理シーケンスが何らかの原因により中断（ｉｎｔｅｒｒｕｐｔｅｄ）した後、ＳｏｕｒｃｅがＳｉｎｋからＭＯＶＥ終了処理用コマンドＣＭＤ２を受け取ったときの処理手順をフローチャートの形式で示している。
【０２１２】
Ｓｏｕｒｃｅは、ＭＯＶＥ終了処理用コマンドＣＭＤ２に含まれる鍵ＩＤであるＫxM_labelを自分が不揮発的に格納しているかどうかをチェックする（ステップＳ１１１）。
【０２１３】
ここで、ＫxM_labelを保持しているときには、該当するコンテンツ伝送終了処理が中断していたことになるので、Ｓｏｕｒｃｅは、ＫxM_labelに対応付けて格納されているデータ（すなわち、ＭＡＣ６Ｂ、ＭＯＶＥしたコンテンツのＩＤ）を削除し（ステップＳ１１２）、ＣＭＤ２を受理したこと（Ａｃｃｅｐｔｅｄ）を示すＭＯＶＥ終了処理用レスポンスＲＳＰ２を返信する（ステップＳ１１３）。
【０２１４】
一方、ＫxM_labelを保持していないときには、Ｓｏｕｒｃｅは既に該当するコンテンツ伝送終了処理を完了しているか、又はＣＭＤ２が自分とは無関係であることが想定されるので、ステップＳ１１２をスキップし、ＣＭＤ２を受理したこと（Ａｃｃｅｐｔｅｄ）を示すＭＯＶＥ終了処理用レスポンスＲＳＰ２を返信する（ステップＳ１１３）。このようにして、中断したＭＯＶＥ終了処理をＨＴＴＰサーバとして動作するＳｏｕｒｃｅにおいて再開することができる。
【０２１５】
また、図２１には、図１１並びに図１８に示したダウンロードＭＯＶＥ伝送の終了処理シーケンスが何らかの原因により中断（ｉｎｔｅｒｒｕｐｔｅｄ）した後、ＳｉｎｋがＭＯＶＥ終了処理を再開させるための処理手順をフローチャートの形式で示している。
【０２１６】
Ｓｉｎｋは、ステップＳ８２において不揮発的に格納したデータ、すなわち鍵ＩＤであるＫxM_labelと乱数Ｒ、ＭＡＣ５Ａ、ＭＡＣ６Ａ、コンテンツＩＤ、ＳｏｕｒｃｅＩＤが存在していることを検出すると（ステップＳ１２１）、これはコンテンツ伝送終了処理が中断して、ＳｏｕｒｃｅとのＣｏｍｍｉｔｍｅｎｔが完了せずに、これらのデータが消去されずに残っていることが分かる。
【０２１７】
この場合、コンテンツ伝送終了処理を再開するために、該当するＳｏｕｒｃｅとのＴＣＰコネクションを確立する（ステップＳ１２２）。
【０２１８】
そして、コンテンツＩＤで示されるコンテンツが無効状態かどうかをチェックする（ステップＳ１２３）。
【０２１９】
コンテンツが無効状態のままであれば（ステップＳ１２３のＹｅｓ）、ＳｏｕｒｃｅからＭＯＶＥ終了処理用レスポンスＲＳＰ１を受け取る前にコンテンツ伝送終了処理が中断したことになるので、図１８に示したフローチャートの＃１にジャンプして（ステップＳ１２４）、ＳｏｕｒｃｅとのＣｏｍｍｉｔｍｅｎｔを開始する。
【０２２０】
コンテンツが既に有効状態となっていれば（ステップＳ１２３のＮｏ）、ＳｏｕｒｃｅからＣｏｍｍｉｔｍｅｎｔを得た後でＭＯＶＥ終了処理用レスポンスＲＳＰ２を受け取る前にコンテンツ伝送終了処理が中断したことになるので、図１８に示したフローチャートの＃２にジャンプして（ステップＳ１２５）、Ｓｏｕｒｃｅに対するＭＯＶＥ終了処理用コマンドＣＭＤ２の送信を行なう。このようにして、中断したＭＯＶＥ終了処理をＨＴＴＰクライアントとして動作するＳｉｎｋにおいて再開することができる。
【０２２１】
図１９〜図２１に示したようなＭＯＶＥ伝送シーケンスの再開処理によって、コンテンツ伝送手続きが無駄にならずに済むとともに、ＳｉｎｋとＳｏｕｒｃｅの双方でコンテンツが無効になることを避けることができる。
【０２２２】
Ｓｏｕｒｃｅは、ＭＯＶＥ終了処理用レスポンスＲＳＰ２を返信するか、又は無効化すべきというユーザの指示入力に応答して、元のコンテンツを中間的な無効状態から完全な無効状態に遷移させる。
【０２２３】
Ｃ−２．アップロード形式のＢＬＯＣＫ ＭＯＶＥ
図１２には、アップロード形式でＳｏｕｒｃｅとＳｉｎｋ間のＢＬＯＣＫ ＭＯＶＥ伝送を行なう場合の動作シーケンスを示している。この場合のＭＯＶＥ伝送もダウンロードと同様に、Ｓｉｎｋ及びコンテンツ選択、ＭＯＶＥ用ＡＫＥ手続き、コンテンツ移動（ＭＯＶＥ）手続き、ＭＯＶＥ終了処理手続きという４段階のフェーズで構成される。このうち、ＭＯＶＥ用ＡＫＥ手続き、コンテンツ移動（ＭＯＶＥ）手続き、ＭＯＶＥ終了処理手続きは、ＤＴＣＰ上で規定される手順に従って実行される。
【０２２４】
Ｓｉｎｋ及びコンテンツ選択のフェーズでは、ユーザは、Ｓｏｕｒｃｅ側で、ＭＯＶＥしたいコンテンツの選択（Ｓｅｌｅｃｔ Ｃｏｎｔｅｎｔ）と、コンテンツの伝送先となるＳｉｎｋの選択（Ｓｅｌｅｃｔ Ｓｉｎｋ ＆ Ｄｅｓｔｉｎａｔｉｏｎ）を行なってから、該当するＳｉｎｋに対して、ＤＴＣＰ ＭＯＶＥとして伝送するコンテンツに関する認証及び鍵交換用のソケット情報を通知する。そして、これに引き続いて、選択したコンテンツのＭＯＶＥ処理が開始する。
【０２２５】
ＳｏｕｒｃｅからＳｉｎｋに対する通知は、ＵＰｎＰ（登録商標）ベースでＣＤＳを用いて行なうことができる。図１３には、この場合のＳｏｕｒｃｅとＳｉｎｋ間の動作シーケンスを示している。
【０２２６】
まず、Ｓｏｕｒｃｅは、Ｓｉｎｋに対してアップロードＭＯＶＥ伝送を要求するときには、伝送しようとするコンテンツの保管場所を作成するよう、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔリクエストを発行する。Ｓｏｕｒｃｅは、このＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔリクエスト内で、ＭＯＶＥしようとするコンテンツ毎に、コンテンツのタイトル、コンテンツのＵＰｎＰ（登録商標）クラス、認証及び鍵交換用のソケット情報並びにＤＴＣＰ−ＩＰのＭＯＶＥ手続きによってコンテンツ伝送を行なうことを記載する。なお、コンテンツ特定用のｉｔｅｍ ＩＤ、ｐａｒｅｎｔＩＤ、コンテンツのＵＲＩはリクエストで不定となり、ＨＴＴＰサーバであるＳｉｎｋが決定し、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔレスポンスによってＨＴＴＰクライアントであるＳｏｕｒｃｅに通知する。図１３に示す例では、Ｓｏｕｒｃｅは、ｒｅｓのｐｒｏｔｏｃｏｌＩｎｆｏアトリビュートの第３フィールドにソケット情報としての文字列“ＤＴＣＰ１ＨＯＳＴ＝（ｈｏｓｔ）；ＤＴＣＰ１ＰＯＲＴ＝（ｐｏｒｔ）”を記載するとともに、当該コンテンツをＤＴＣＰ−ＩＰのＭＯＶＥ伝送シーケンスによって伝送することを示す文字列“ＤＴＣＰＯＰ＝ＭＯＶＥ”を記載している。
【０２２７】
なお、ｒｅｓ＠ｐｒｏｔｏｃｏｌＩｎｆｏの中にＤＴＣＰＯＰなど、アップロード時に一時的に使用する属性情報を含めると、Ｓｉｎｋは自身がＨＴＴＰサーバとしてＣＤＳ：：Ｂｒｏｗｓｅリクエストへの応答でｒｅｓ＠ｐｒｏｔｏｃｏｌＩｎｆｏを送る際にはその属性情報を取り除く必要があり、処理が煩雑になる。そこで、属性情報をｐｒｏｔｏｃｏｌＩｎｆｏとは独立して新たなアトリビュートで送る方法も考えられる。具体的には、ｒｅｓ＠ｄｔｃｐ：ｕｐｌｏａｄＩｎｆｏアトリビュートというものを設けて、コンテンツのＭＯＶＥ伝送の可否を示すことが考えられる。ｒｅｓ＠ｄｔｃｐ：ｕｐｌｏａｄＩｎｆｏアトリビュートは３２ビット長のフィールドであり、ビット定義は以下の通りとなっている。ビット３０に１が記載されているときには、ビット３１にも１が記載される。Ｓｉｎｋは予備のビット・フィールドを無視する。
【０２２８】
ビット３１：ＤＴＣＰに基づき、ＭＯＶＥとして伝送する。
ビット３０：ＤＴＣＰ仕様書に規定されている条件を満足するＢＬＯＣＫ ＭＯＶＥプロトコルを使用する。
ビット２９〜０：予備
【０２２９】
ｒｅｓ＠ｄｔｃｐ：ｕｐｌｏａｄＩｎｆｏアトリビュートの３２ビットは１６進数表記される。ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔリクエスト中のｒｅｓ＠ｄｔｃｐ：ｕｐｌｏａｄＩｎｆｏアトリビュートの記述例は以下の通りとなる。
【０２３０】
【数３】
【０２３１】
Ｓｉｎｋは、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔリクエストを受け取ると、コンテンツの伝送元となるＳｏｕｒｃｅ側の認証及び鍵交換用のソケット情報と、コンテンツがＭＯＶＥとして伝送されるのかどうかを識別することができる。そして、Ｓｉｎｋは、ＳｏｕｒｃｅからのアップロードＭＯＶＥ伝送要求を受け容れるときには、コンテンツの保管場所（すなわちインポート先）をローカルの記憶領域に作成するとともに、この保管場所の情報を含んだＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔレスポンスを要求元のＳｏｕｒｃｅに返す。図１３に示す例では、Ｓｉｎｋはｒｅｓ＠ｐｒｏｔｏｃｏｌＩｎｆｏアトリビュート内のｉｍｐｏｒｔＵｒｉアトリビュートにＭＯＶＥ対象となるコンテンツのインポート先を示す文字列“ｈｔｔｐ：／／１．２．３．４：５００００／ｉｍｐｏｒｔ？ｉｄ＝６”を記載している。あるいは、ｒｅｓ＠ｄｔｃｐ：ｕｐｌｏａｄＩｎｆｏアトリビュートを用いてＭＯＶＥ伝送の可否を示す場合には、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔレスポンスの記述例は以下の通りとなる。
【０２３２】
【数４】
【０２３３】
このようにして、Ｓｏｕｒｃｅは、ＳｉｎｋからエラーでないＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔレスポンスを受け取って、Ｓｉｎｋ宛てにコンテンツのＭＯＶＥが可能であると確認し、コンテンツの保管場所を確保すると、これに引き続いて、選択したコンテンツのアップロードＭＯＶＥ伝送処理が開始される。
【０２３４】
ＭＯＶＥ伝送に先駆けて、まずＳｏｕｒｃｅとＳｉｎｋ間の相互認証及びＭＯＶＥ用の鍵共有を行なうために、ＭＯＶＥ用ＡＫＥ手続きを実施する。ＭＯＶＥ用ＡＫＥ手続きの動作シーケンスは、図１０、並びに図１６〜１７を参照しながら既に説明した通りなので、ここでは説明を省略する。但し、ＭＶ−ＣＨＡＬＬＥＮＧＥコマンドでは、通常のＡＫＥ手続の場合とは異なるスクランブル方法が適用され、ＭＯＶＥ伝送をコピー伝送と偽られるのを防止する（同上）。
【０２３５】
あるいは、ＭＯＶＥ用ＡＫＥ手続きには、図２７に示したような動作シーケンスを使用することができる。この場合、Ｓｉｎｋは、ＭＶ−ＩＮＩＴＩＡＴＥコマンドを送信するというＭＯＶＥプロトコルを用いて、ダウンロードＭＯＶＥ伝送を初期化して、ＭＯＶＥ ＲＴＴ−ＡＫＥプロセスを起動する。ＲＴＴ−ＡＫＥプロセスでは、通常のＡＫＥと同じ手順を追って、チャレンジ−レスポンス手続きによる相互認証が行なわれる。そして、ＭＶ＿ＥＸＣＨＡＮＧＥ＿ＫＥＹコマンドによって共有鍵の交換が行なわれる（同上）。
【０２３６】
そして、ＭＯＶＥ伝送用のＡＫＥ手続きが無事に完了すると、続いてコンテンツ移動（ＭＯＶＥ）手続きが開始される。Ｓｏｕｒｃｅ側のユーザ操作によりＳｉｎｋへコンテンツをＭＯＶＥ伝送する場合、ＳｏｕｒｃｅがＨＴＴＰクライアントとして動作するとともにＳｉｎｋがＨＴＴＰサーバとして動作し、ＨＴＴＰプロトコルを用いてアップロードＭＯＶＥ伝送を行なうようにすれば良い。すなわち、ＨＴＴＰクライアントとしてのＳｏｕｒｃｅはＨＴＴＰ ＰＯＳＴリクエストを送信し、これに対し、ＨＴＴＰサーバとしてのＳｉｎｋはＨＴＴＰ ＰＯＳＴレスポンスを返信することにより、コンテンツ選択フェーズで選択されたコンテンツをＳｏｕｒｃｅからＳｉｎｋへアップロードＭＯＶＥ伝送する。ＰＯＳＴは、特定のＵＲＩに対して情報を送信するための、リクエストとして送信するＨＴＴＰメソッドである（周知）。
【０２３７】
ＨＴＴＰプロトコルを用いてコンテンツをアップロードＭＯＶＥ伝送するとき、Ｓｏｕｒｃｅは、Ｅ−ＥＭＩのモードをＣ１（すなわちＭＯＶＥモード（表１を参照のこと））に設定する。Ｓｉｎｋは、Ｃ１以外のＥ−ＥＭＩモードを受け取ったときには、受信したコンテンツをＭＯＶＥ対象として扱わない（同上）。
【０２３８】
Ｓｏｕｒｃｅは、ＨＴＴＰのＰＯＳＴリクエストのヘッダに“ＭＯＶＥ．ｄｔｃｐ．ｃｏｍ：＜ＫｘＭ＿ｌａｂｅｌ＞”（若しくは、“ＭＯＶＥ．ｄｔｃｐ．ｃｏｍ”ではなく“ＢＬＫＭＯＶＥ．ｄｔｃｐ．ｃｏｍ”）というヘッダ情報を設定したＨＴＴＰ ＰＯＳＴリクエストを送信して、アップロードＭＯＶＥ伝送を開始する。そして、Ｓｏｕｒｃｅは、リクエストしたコンテンツをＫxM_labelに対応するＭＯＶＥ用の鍵ＫXMから得た暗号鍵Ｋcで暗号化し、Ｅ−ＥＭＩをＣ１に設定して後続のＰＯＳＴリクエストとして伝送する。
【０２３９】
図１５Ａ及び図１５Ｂには、ＨＴＴＰクライアントとしてのＳｏｕｒｃｅからＨＴＴＰサーバとしてのＳｉｎｋへコンテンツをアップロードＭＯＶＥ伝送する場合のＳｏｕｒｃｅ及びＳｉｎｋがそれぞれ実行する処理動作をフローチャートの形式でまとめている。
【０２４０】
Ｓｏｕｒｃｅは、コンテンツのアップロード先のサーバとして動作するＳｉｎｋを発見すると（ステップＳ４１）、Ｓｉｎｋに対してコンテンツの保管場所の作成を要求するべく、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｑｕｅｓｔを送信して（ステップＳ４２）、そのレスポンスの受信を待機する（ステップＳ４３）。
【０２４１】
Ｓｉｎｋは、ＳｏｕｒｃｅからＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｑｕｅｓｔを受信すると（ステップＳ６１）、これに対するレスポンスを返信する（ステップＳ６２）。
【０２４２】
Ｓｏｕｒｃｅは、ＳｉｎｋからＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｓｐｏｎｓｅを受信すると、続いてＭＯＶＥするコンテンツを決定し（ステップＳ４４）、ＭＯＶＥ用のＡＫＥ要求を受信するまで待機する（ステップＳ４５）。
【０２４３】
Ｓｉｎｋは、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｓｐｏｎｓｅを送信した後、Ｓｏｕｒｃｅに対してＭＯＶＥ用のＡＫＥ処理を要求する（ステップＳ６３）。
【０２４４】
そして、ＳｉｎｋとＳｏｕｒｃｅ間では、ＭＯＶＥ用のＡＫＥ手続きが開始され、互いにＭＯＶＥ用のＡＫＥ処理を実行する（ステップＳ４６、Ｓ６４）。ＭＯＶＥ用のＡＫＥの認証に成功すると（ステップＳ４７、Ｓ６５）、ＳｏｕｒｃｅはＭＯＶＥ用の鍵と鍵ＩＤを生成してＳｉｎｋに送信し（ステップＳ４８）、ＳｉｎｋはＳｏｕｒｃｅからＭＯＶＥ用の鍵と鍵ＩＤを受信する（ステップＳ６６）。但し、ＳｏｕｒｃｅとＳｉｎｋ間でＭＯＶＥ用のＡＫＥの認証に失敗すると、ＳｏｕｒｃｅとＳｉｎｋはともに、後続の処理をすべてスキップして、本処理ルーチン全体を終了する。
【０２４５】
続いて、Ｓｏｕｒｃｅは、Ｓｉｎｋに対してＭＯＶＥによりアップロードしようとするコンテンツに対して「ＭＯＶＥ伝送中」フラグをセットしてから（ステップＳ４９）、当該コンテンツをＭＯＶＥ用の鍵を用いて暗号化し、“ＭＯＶＥ．ｄｔｃｐ．ｃｏｍ：＜ＫｘＭ＿ｌａｂｅｌ＞”というヘッダ情報を伴ったＨＴＴＰ ＰＯＳＴリクエストにより、暗号化コンテンツを送信する（ステップＳ５０）。「ＭＯＶＥ伝送中」フラグをセットすると、当該コンテンツはロック状態となる。そして、ＳｉｎｋからのＨＴＴＰ ＰＯＳＴレスポンスの受信を待機する（ステップＳ５１）。
【０２４６】
Ｓｉｎｋ側では、ＭＯＶＥ用のＡＫＥ手続きを終えると、ＳｏｕｒｃｅからのＨＴＴＰ ＰＯＳＴリクエストを受信待機している（ステップＳ６７）。そして、当該リクエストを受信して、暗号化コンテンツをすべて受け取ると、ＨＴＴＰ ＰＯＳＴレスポンスを返信する（ステップＳ６８）。
【０２４７】
このようにして、ＳｏｕｒｃｅからＳｉｎｋへ暗号化コンテンツを成功裏にアップロードすることができたならば、ＳｏｕｒｃｅはＭＯＶＥ終了処理の受信を待機する（ステップＳ５２）。また、Ｓｉｎｋは、Ｓｏｕｒｃｅに対してＭＯＶＥ終了処理の要求を送信する（ステップＳ６９）。そして、ＳｏｕｒｃｅとＳｉｎｋは、それぞれＭＯＶＥ終了処理手続きを実行して（ステップＳ５３、Ｓ７０）、Ｓｉｎｋ側でコンテンツを有効化するとともに、Ｓｏｕｒｃｅ側の元のコンテンツを削除する。Ｓｏｕｒｃｅ及びＳｉｎｋ間におけるＭＯＶＥ終了処理手続きの動作シーケンスは図１１並びに図１８を参照して既に説明した通りなので、ここでは説明を省略する。
【０２４８】
そして、ＳｏｕｒｃｅとＳｉｎｋは、ＭＯＶＥ終了処理手続きを完了すると（ステップＳ５４、Ｓ７１）、いずれもＭＯＶＥ用の鍵と鍵ＩＤを破棄して（ステップＳ５５、Ｓ７２）、本処理ルーチン全体を終了する。
【０２４９】
図１５Ａ及び図１５Ｂに示したアップロードＭＯＶＥ処理手続の期間中、ＭＯＶＥ対象となるコンテンツを他のＳｉｎｋからＭＯＶＥ要求できないようにロックして、多重ＭＯＶＥの発生を防止する。アップロード形式でコンテンツのＭＯＶＥを行なう場合、Ｓｉｎｋは、サーバに相当するが、保持する個々のコンテンツについてＭＯＶＥ伝送中であるかどうかを、例えば表２（前述）に示したようなテーブルを使って管理することができる（同上）。
【０２５０】
また、Ｓｉｎｋは、ＢＬＯＣＫ ＭＯＶＥモードでアップロードＭＯＶＥ伝送処理が行なわれている期間中は、コンテンツはまだ有効化されていないので、リアルタイムでレンダリングする以外の目的で受信したコンテンツを利用することはできない。リアルタイム・レンダリングの仕組みについては、図７を参照しながら既に説明したので、ここでは説明を省略する。
【０２５１】
なお、ＭＯＶＥ用ＡＫＥ手続き並びにコンテンツ移動（ＭＯＶＥ）手続きの期間中には、ＭＯＶＥ伝送をユーザ操作で取り止める取り消し（Ｃａｎｃｅｌ）や中止（Ａｂｏｒｔ）といった中断処理が起動することがあるが、この点の詳細については後述に譲る。
【０２５２】
そして、ＳｏｕｒｃｅがＨＴＴＰプロトコルのＰＯＳＴリクエストにより、ＨＴＴＰサーバとして動作する所定のＳｉｎｋに対して所望のコンテンツを成功裏にアップロードすることができたならば、アップロードＭＯＶＥ伝送の終了処理手続きを実施して、Ｓｉｎｋ側ではこのアップロードしたコンテンツを有効化すると同時に、Ｓｏｕｒｃｅ側では元のコンテンツの削除を行なう。ＭＯＶＥ終了処理手続きは、図１１並びに図１８に示したものと同様の動作シーケンスに従って実行される（同上）。
【０２５３】
アップロードＭＯＶＥ伝送が終了した後にＳｉｎｋ側でコンテンツを有効化する方法は特に限定されない。有効化すると、Ｓｉｎｋ内のコンテンツ記録ブロックでＮｏ Ｍｏｒｅ Ｃｏｐｉｅｓとして符号化して記録されたコンテンツの利用が可能となる（例えば、記録時に適用した暗号の解除が可能となり）。この結果、コンテンツ再生ブロックに符号化コンテンツを供給して、ビデオ及びオーディオ信号に変換（ｒｅｎｄｅｒｉｎｇ）して、ディスプレイなどのＡＶ出力部から映像並びに音響出力することができる。あるいは、今度はＳｏｕｒｃｅとして、さらに別のＳｉｎｋに対して、上述と同様にダウンロード又はアップロード形式でＭＯＶＥすることもできる。
【０２５４】
また、アップロードＭＯＶＥ伝送が終了した後にＳｏｕｒｃｅ側で元のコンテンツを削除する方法も特に限定されない。コンテンツを格納したハード・ディスクなどの記録媒体からコンテンツ・データのエンティティ自体を削除する以外に、符号化（暗号化）して記録されているコンテンツのエンティティは残すが復号鍵を再び使用できないようにするのであってもよい。
【０２５５】
なお、Ｓｉｎｋは、コンテンツをＳｏｕｒｃｅからアップロードＭＯＶＥ伝送した後に、今度は自らＳｏｕｒｃｅとしてコンテンツを提供しようとする場合は、ｒｅｓタグ内のＤＴＣＰＯＰ＝ＭＯＶＥを削除する（若しくはｒｅｓ＠ｄｔｃｐ：ｕｐｌｏａｄＩｎｆｏアトリビュートを削除する）とともに、ソケット情報のホスト名とポートを自らのものに変更する必要がある。また、他のＳｉｎｋにコンテンツを持ち出す（ＭＯＶＥ ｏｕｔ）ことを許容する場合には、ｒｅｓタグ内にＭＯＶＥ可能であることを示す文字列“ＭＯＶＥ：１”を記載したａｌｌｏｗｅｄＵｓｅアトリビュートを追加する（若しくは、上記のＤＴＣＰ．ＣＯＭ＿ＦＬＡＧＳ ｐａｒａｍをｒｅｓ＠ｐｒｏｔｏｃｏｌＩｎｆｏアトリビュートの第４フィールドに追加する）。
【０２５６】
図１３に示した動作シーケンスでは、Ｓｉｎｋ側でＭＯＶＥ用ＡＫＥ手続きのためのＴＣＰコネクションを確立するために必要となるソケット情報（ＤＴＣＰ ｓｏｃｋｅｔ Ｉｎｆｏ）を、ＳｏｕｒｃｅはＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔリクエストによって通知している。ところが、この通知方法では、中断したＭＯＶＥ伝送終了手続きを再開する際には、ソケット情報の通知のために、同じコンテンツのアップロードＭＯＶＥ伝送を要求するＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔリクエストを再び発行しなければならず、１回のみＭＯＶＥ伝送を許可するというＤＴＣＰ規格に抵触するおそれがある。
【０２５７】
そこで、本発明者らは、図１３に示した動作シーケンスによる通知方法以外に、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔの処理後に、ＭＯＶＥ用ＡＫＥ手続きを行なうのに先立ち、ＨＴＴＰ ＰＯＳＴリクエストのヘッダにソケット情報（ＤＴＣＰ ｓｏｃｋｅｔ Ｉｎｆｏ）を記載して、ＳｏｕｒｃｅからＳｉｎｋへソケット情報を通知する方法について提案する。例えば、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダを使って、以下のように記載する。
【０２５８】
【数５】
【０２５９】
ＳｉｎｋはＡＫＥ手続きが完了するまでコンテンツの暗号を解けないので、ＳｏｕｒｃｅはこのＰＯＳＴリクエストではまだコンテンツを伝送せず、ＡＫＥ手続きの完了後に伝送するという手順が考えられる。すなわち、ソケット情報を通知するＨＴＴＰ ＰＯＳＴリクエストは、コンテンツを伴わなくても良く、また、図１３とは相違し、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔではソケット情報を送る必要はない。
【０２６０】
図３０には、ＳｏｕｒｃｅがＰＯＳＴリクエストを用いてソケット情報を通知する方法を用いる場合において、ＳｏｕｒｃｅとＳｉｎｋ間でアップロードＭＯＶＥ伝送を行なうための動作シーケンスを示している。
【０２６１】
まず、Ｓｏｕｒｃｅは、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔリクエストを用いて、Ｓｉｎｋに対して、コンテンツの移動先となるオブジェクトの作成を要求する。このとき、Ｓｏｕｒｃｅは、ｒｅｓ＠ｕｐｌｏａｄＩｎｆｏアトリビュートにおいてＭＯＶＥ伝送をベースにしたトランザクションを要求する。これに対し、Ｓｉｎｋは、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔレスポンスのｒｅｓ＠ｉｍｐｏｒｔＵｒｉアトリビュートにおいて、ＨＴＴＰ ＰＯＳＴ用のＵＲＩを返す。
【０２６２】
続いて、Ｓｏｕｒｃｅは、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔレスポンスの記載内容から取得したＵＲＩに対するＨＴＴＰ ＰＯＳＴリクエストを送信して、Ｓｉｎｋに対して認証及び鍵交換用のソケット情報を通知する。ソケット情報は、上述したように、ＣｏｎｔｅｎｔＴｙｐｅとして送られてくる。但し、ソケット情報の通知に使用されるＨＴＴＰ ＰＯＳＴリクエストは、コンテンツを含まない。
【０２６３】
Ｓｉｎｋは、ソケット情報を取得すると、認証及び鍵交換用のＴＣＰコネクションを確立する。そして、Ｓｉｎｋは、ＭＶ−ＩＮＩＴＩＡＴＥコマンドを送信してＭＯＶＥ ＲＴＴ−ＡＫＥプロセスを起動することによって、アップロードＭＯＶＥ伝送を初期化する。
【０２６４】
ＭＯＶＥ ＲＴＴ−ＡＫＥプロセスが終了すると、ＢＬＫＭＯＶＥ．ｄｔｃｐ．ｃｏｍヘッダ情報を含んだＨＴＴＰ ＰＯＳＴリクエストを送信することで、Ｓｏｕｒｃｅは、暗号化コンテンツの伝送を行なう。
【０２６５】
Ｓｉｎｋは、ＭＯＶＥ対象コンテンツをすべて受け取った後、ＭＶ＿ＦＩＮＡＬＩＺＥコマンドを送信することによって、ＭＯＶＥ伝送終了処理を起動する。ＭＯＶＥ終了処理手続きは、図１１に示した動作シーケンスに従って実施される。
【０２６６】
なお、図３１に示すように、Ｓｏｕｒｃｅから、コンテンツを伴わないＰＯＳＴリクエストのヘッダでソケット情報を送り、Ｓｉｎｋが認証および鍵交換用のＴＣＰコネクションを確立して、ＡＫＥ手続を終了した後に、ＰＯＳＴレスポンスを返すようにしても良い。このような動作シーケンスの場合、ＡＫＥ手続きで共有したＫXM_labelをＭＯＶＥ．ｄｔｃｐ．ｃｏｍ（若しくは、ＢＬＫＭＯＶＥ．ｄｔｃｐ．ｃｏｍ）ヘッダを使い、“ＭＯＶＥ．ｄｔｃｐ．ｃｏｍ：＜ＫXM_label＞”のようにしてＳｉｎｋからのＰＯＳＴレスポンスで送ることで、Ｓｏｕｒｃｅは同時に複数のＭＯＶＥ伝送処理を行なう場合でも、コンテンツの暗号化に適用すべき交換鍵ＫXMを確実に把握することができる。
【０２６７】
また、図３１に示した動作シーケンスと同じ効果を得る別の方法として、複数のＭＯＶＥ処理を行なう場合にＳｉｎｋに通知するソケット情報をユニークにすることで、ＳｉｎｋとＫXMの関係付けを確実に行なうことができる。この場合、ＳｉｎｋはＡＫＥ手続きの完了前にＭＯＶＥ．ｄｔｃｐ．ｃｏｍ（若しくは、ＢＬＫＭＯＶＥ．ｃｏｍ）ヘッダを伴わないＰＯＳＴレスポンスを送ることもできる。なお、この後のコンテンツ伝送は新たなＰＯＳＴリクエストとしてではなく、ＡＫＥ手続き前のＰＯＳＴリクエストの手続きとして送る方法も考えられる。
【０２６８】
また、ここで説明したソケット情報の通知方法は、アップロードＭＯＶＥ伝送だけでなく、アップロード形式のＣＯＰＹ伝送においても同様に適用することができる。
【０２６９】
図３２Ａ及び図３２Ｂには、図３１に示した動作シーケンスによってＨＴＴＰクライアントとしてのＳｏｕｒｃｅからＨＴＴＰサーバとしてのＳｉｎｋへコンテンツをアップロードＭＯＶＥ伝送する場合のＳｏｕｒｃｅ及びＳｉｎｋがそれぞれ実行する処理動作をフローチャートの形式でまとめている。
【０２７０】
Ｓｏｕｒｃｅは、コンテンツのアップロード先のサーバとして動作するＳｉｎｋを発見すると（ステップＳ１５１）、Ｓｉｎｋに対してコンテンツの保管場所の作成を要求するべく、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｑｕｅｓｔを送信して（ステップＳ１５２）、そのレスポンスの受信を待機する（ステップＳ１５３）。
【０２７１】
Ｓｉｎｋは、ＳｏｕｒｃｅからＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｑｕｅｓｔを受信すると（ステップＳ１７１）、これに対するレスポンスを返信する（ステップＳ１７２）。
【０２７２】
Ｓｏｕｒｃｅは、ＳｉｎｋからＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｓｐｏｎｓｅを受信すると、続いてＭＯＶＥ対象となるコンテンツを決定する（ステップＳ１５４）。そして、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダを伴うＨＴＴＰ ＰＯＳＴリクエストでＳｉｎｋにソケット情報を送信した後（ステップＳ１５５）、ＭＯＶＥ用のＡＫＥ要求を受信するまで待機する（ステップＳ１５６）。
【０２７３】
Ｓｉｎｋは、ソケット情報を伴うＨＴＴＰ ＰＯＳＴリクエストをＳｏｕｒｃｅから受信すると（ステップＳ１７３）、当該リクエストから得たソケットに対するＴＣＰコネクションを確立して（ステップＡ１７４）、Ｓｏｕｒｃｅに対してＭＯＶＥ用のＡＫＥ処理を要求する（ステップＳ１７５）。
【０２７４】
そして、ＳｉｎｋとＳｏｕｒｃｅ間では、ＭＯＶＥ用のＡＫＥ手続きが開始され、互いにＭＯＶＥ用のＡＫＥ処理を実行する（ステップＳ１５７、Ｓ１７６）。ここで、ＭＯＶＥ用のＡＫＥの認証に成功すると（ステップＳ１５８、Ｓ１７７）、Ｓｏｕｒｃｅは、ＭＯＶＥ用の鍵と鍵ＩＤを生成してＳｉｎｋに送信する（ステップＳ１５９）。但し、ＳｏｕｒｃｅとＳｉｎｋ間でＭＯＶＥ用のＡＫＥの認証に失敗すると、ＳｏｕｒｃｅとＳｉｎｋはともに、後続の処理をすべてスキップして、本処理ルーチン全体を終了する。
【０２７５】
Ｓｉｎｋは、ＳｏｕｒｃｅからＭＯＶＥ用の鍵と鍵ＩＤを受信すると（ステップＳ１７８のＹｅｓ）、ＢＬＫＭＯＶＥ．ｄｔｃｐ．ｃｏｍヘッダを伴うＨＴＴＰ ＰＯＳＴレスポンスで鍵ＩＤを送信する（ステップＳ１７９）。
【０２７６】
そして、Ｓｏｕｒｃｅは、Ｓｉｎｋから鍵ＩＤを伴うＨＴＴＰ ＰＯＳＴレスポンスを受信すると（ステップＳ１６０のＹｅｓ）、この鍵ＩＤに対応するＭＯＶＥ伝送用の鍵を以後の処理用に選択する（ステップＳ１６１）。
【０２７７】
続いて、Ｓｏｕｒｃｅは、Ｓｉｎｋに対してアップロードＭＯＶＥ伝送しようとするコンテンツに対して「ＭＯＶＥ伝送中」フラグをセットしてから（ステップＳ１６２）、当該コンテンツをＭＯＶＥ伝送用の鍵を用いて暗号化し、ソケット情報を伴うＨＴＴＰ ＰＯＳＴリクエストのメッセージ・ボディとして送信する（ステップＳ１６３）。「ＭＯＶＥ伝送中」フラグをセットすると、当該コンテンツはロック状態となる。そして、ＳｉｎｋからのＨＴＴＰ ＰＯＳＴレスポンスの受信を待機する（ステップＳ１６４）。
【０２７８】
Ｓｉｎｋ側では、ＭＯＶＥ用のＡＫＥ手続きを終えると、ＳｏｕｒｃｅからのＨＴＴＰ ＰＯＳＴリクエストのメッセージ・ボディとしての暗号化コンテンツを受信待機している（ステップＳ１８１）。そして、当該リクエストを受信して、暗号化コンテンツを受け取ると、ＨＴＴＰ ＰＯＳＴレスポンスを返信する（ステップＳ１８２）。
【０２７９】
このようにして、ＳｏｕｒｃｅからＳｉｎｋへ暗号化コンテンツを成功裏にアップロードすることができたならば、ＳｏｕｒｃｅはＭＯＶＥ終了処理の受信を待機する（ステップＳ１６５）。また、Ｓｉｎｋは、Ｓｏｕｒｃｅに対してＭＯＶＥ終了処理の要求を送信する（ステップＳ１８３）。そして、ＳｏｕｒｃｅとＳｉｎｋは、それぞれＭＯＶＥ終了処理手続きを実行して（ステップＳ１６６、Ｓ１８４）、Ｓｉｎｋ側でコンテンツを有効化するとともに、Ｓｏｕｒｃｅ側の元のコンテンツを削除又は無効化する。Ｓｏｕｒｃｅ及びＳｉｎｋ間におけるＭＯＶＥ終了処理手続きの動作シーケンスは図１１並びに図１８を参照して既に説明した通りなので、ここでは説明を省略する。
【０２８０】
そして、ＳｏｕｒｃｅとＳｉｎｋは、ＭＯＶＥ終了処理手続きを完了すると（ステップＳ１６７、Ｓ１８５）、いずれもＭＯＶＥ伝送用の鍵と鍵ＩＤを破棄して（ステップＳ１６８、Ｓ１８６）、本処理ルーチン全体を終了する。
【０２８１】
ここで、ＳｏｕｒｃｅからＳｉｎｋへコンテンツのエンティティが成功裏にアップロードＭＯＶＥ伝送されたにも拘らず、一方の機器の電源遮断などによりＭＯＶＥ伝送の終了処理シーケンスが途切れてしまう可能性がある。ＭＯＶＥ伝送の終了処理の中断（ｉｎｔｅｒｒｕｐｔｅｄ）によって、Ｓｏｕｒｃｅ及びＳｉｎｋの双方において移動したコンテンツを利用できなくなるおそれがある。このようにＭＯＶＥ終了処理手続きが中断したときには、図１９〜２１に示した処理手順に従って再開して、ＳｉｎｋとＳｏｕｒｃｅの双方でコンテンツが無効になることを避けることができる。
【０２８２】
アップロードＭＯＶＥ伝送の終了処理の再開を可能にするために、Ｓｉｎｋ及びＳｏｕｒｃｅの各々では、アップロードＭＯＶＥ伝送の終了処理を開始する際に、ＮＶＲＡＭなどの不揮発性メモリを用いて、再開処理に必要となるデータを保存するようにしている。Ｓｉｎｋ側では、ＣＭＤ１すなわちＭＶ＿ＦＩＮＡＬＩＺＥコマンドで用いるパラメータ（ＫxM_label）と、ＭＡＣ６Ａを不揮発的に格納する。
【０２８３】
また、Ｓｏｕｒｃｅは中断したＣｏｍｍｉｔｍｅｎｔ情報を持つ場合、対応するＳｉｎｋに対してソケット情報を通知し、処理の再開を促す必要がある。このためには、Ｓｏｕｒｃｅは、Ｃｏｍｍｉｔｍｅｎｔ処理の過程において、Ｓｉｎｋ発見に必要となるＵＵＩＤ、及びＰＯＳＴの宛て先ＵＲＩを発見するのに必要となるＯｂｊｅｃｔ ＩＤ、さらには鍵ＩＤであるＫxM_labelとＭＡＣ５Ｂ、ＭＡＣ６Ｂを不揮発的に格納する。再開処理は、基本的にはＳｉｎｋ側が起動する。
【０２８４】
ＨＴＴＰ ＰＯＳＴリクエストのヘッダにソケット情報（ＤＴＣＰ ｓｏｃｋｅｔ Ｉｎｆｏ）を記載して、ＳｏｕｒｃｅからＳｉｎｋへソケット情報を通知するという上記の方法によれば、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔを使ってソケット情報を通知する方法とは異なり、中断したＭＯＶＥ処理を再開する際であっても、Ｓｉｎｋは問題なくＭＯＶＥ対象となるコンテンツに関するソケット情報を得ることができる。
【０２８５】
図３３には、ＭＯＶＥ伝送終了処理を再開する際に、Ｓｉｎｋ及びＳｏｕｒｃｅ間でＴＣＰコネクションを確立するための処理手順をフローチャートの形式で示している。
【０２８６】
Ｓｏｕｒｃｅは、不揮発的に記憶しておいたＵＵＩＤを１つ選択し（ステップＳ１９１）、ＵＰｎＰのデバイス発見のプロトコルにより、不揮発的に記憶しておいたＵＵＩＤと一致する機器（Ｓｉｎｋ）が発見されたかどうかをチェックする（ステップＳ１９２）。そして、Ｓｏｕｒｃｅは、不揮発的に記憶しておいたものと同じＵＵＩＤを持つＳｉｎｋを発見すると、その機器に対してＣＤＳ：：ＢｒｏｗｓｅリクエストをＯｂｊｅｃｔＩＤ指定付きで送信する（ステップＳ１９３）。
【０２８７】
一方、Ｓｉｎｋは、ＳｏｕｒｃｅからＣＤＳ：：Ｂｒｏｗｓｅリクエストを受信すると（ステップＳ２０１）、ＣＤＳ：：Ｂｒｏｗｓｅレスポンスを返信する（ステップＳ２０２）。
【０２８８】
Ｓｏｕｒｃｅは、ＳｉｎｋからＣＤＳ：：Ｂｒｏｗｓｅレスポンスを受け取ると（ステップＳ１９４のＹｅｓ）、当該レスポンスの記述内容からソケット情報の送信先となるｒｅｓ＠ｉｍｐｏｒｔＵｒｉを取得する（ステップＳ１９５）。そして、ソケット情報をＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダに含むＨＴＴＰ ＰＯＳＴリクエストをＳｉｎｋに送信する（ステップＳ１９６）。
【０２８９】
Ｓｉｎｋは、Ｓｏｕｒｃｅからソケット情報を伴うＨＴＴＰ ＰＯＳＴリクエストを受信すると（ステップＳ２０３）、当該リクエストに含まれるソケット情報を参照して、Ｓｏｕｒｃｅとの間でＡＫＥコマンドの通信用のＴＣＰコネクションを確立する（ステップＳ２０４）。そして、このＴＣＰコネクションを利用して、図１９〜２１に示した処理手順に従って、中断されたＭＯＶＥ伝送終了処理を再開することができる。
【０２９０】
Ｃ−３．ＢＬＯＣＫ ＭＯＶＥのＣＡＮＣＥＬ並びにＡｂｏｒｔ
上述したようなダウンロード及びアップロードのうちいずれの形式でコンテンツをＭＯＶＥする場合であっても、Ｓｉｎｋは、Ｓｏｕｒｃｅに対しＭＯＶＥ終了処理用コマンドＣＭＤ１を送信する前であれば、ＭＯＶＥ処理を取り消し（ｃａｎｃｅｌ）又は中止（ａｂｏｒｔ）することができる。
【０２９１】
Ｓｏｕｒｃｅ並びにＳｉｎｋはともに、相手に対してＭＶ−ＣＡＮＣＥＬサブファンクションを送信することによって、ＭＯＶＥ処理手続を取り消す（ＣＡＮＣＥＬする）ことができる。
【０２９２】
本実施形態では、ＭＯＶＥ処理手続きのＣＡＮＣＥＬは、ＡＫＥ手続きの一部として実装する。ＡＫＥ手続きのためのＴＣＰコネクションは、通常、Ｓｉｎｋからのトリガによって確立される。コンテンツのストリーミングやコピーを行なう通常のコンテンツ伝送手続きでは、ＡＫＥにより鍵を共有するとＡＫＥ用のＴＣＰコネクションを切断する。しかしながら、ここでは、ＭＯＶＥ処理手続き中にＳｏｕｒｃｅ側からもＭＶ−ＣＡＮＣＥＬサブファンクションを送信できるようにするために、ＡＫＥ用のＴＣＰコネクションを保持しておく必要がある。
【０２９３】
Ｓｏｕｒｃｅは、ＭＯＶＥ終了処理手続きを開始する前にＭＶ−ＣＡＮＣＥＬサブファンクションを送信し又は受信すると、ＭＯＶＥ処理手続きを終了させるとともに、ＭＯＶＥ対象となっていたコンテンツのロック状態を解除し（具体的には、表２中で該当コンテンツの状態をＭＯＶＥ可能に戻す）、当該コンテンツに対する他のＭＯＶＥ要求のために解放する。また、ＭＯＶＥ処理手続の終了に併せて、Ｓｏｕｒｃｅは交換鍵ＫXMを消滅させる。これ以降は、Ｓｉｎｋからの当該終了したＭＯＶＥ処理手続きに関するリクエストを拒絶するようになる。
【０２９４】
また、Ｓｉｎｋは、ＭＯＶＥ終了処理手続きを開始する前にＭＶ−ＣＡＮＣＥＬサブファンクションを送信し又は受信すると、ＭＯＶＥ処理手続きを終了させるとともに、自分にＭＯＶＥされたコンテンツを削除する。このＭＯＶＥ処理手続の終了に併せて、Ｓｉｎｋは交換鍵ＫXMを消滅させる。
【０２９５】
また、ＳｏｕｒｃｅとＳｉｎｋはともに、ＭＯＶＥ終了処理が開始する前にＳｏｕｒｃｅとＳｉｎｋ間の通信が途切れると、ＭＯＶＥ処理手続きを中止（ａｂｏｒｔ）することができる。この場合のＳｏｕｒｃｅとＳｉｎｋは、ＭＶ−ＣＡＮＣＥＬを送信又は受信したときと同様の振る舞いを行なう。
【０２９６】
Ｄ．ＭＯＶＥモード詐称攻撃の対策
ＤＴＣＰ−ＩＰでは、ＳｏｕｒｃｅとＳｉｎｋ間の伝送路上にパーソナル・コンピュータなどで構成される不正なプロキシを設置することで、通信内容の改ざんが容易に行なわれてしまう。とりわけ、ＳｏｕｒｃｅとＳｉｎｋ間でケイパビリティの確認手続き（図１６〜１７を参照のこと）を経てＢＬＯＣＫ ＭＯＶＥを開始するようなシステムにおいては、その確認手続きの実装が必須でない場合、ＳｏｕｒｃｅがＢＬＯＣＫ ＭＯＶＥに対応しているにも拘らず、プロキシはＳｏｕｒｃｅがＢＬＯＣＫ ＭＯＶＥに非対応であるとＳｉｎｋに偽り、ＳｉｎｋにＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥを行なわせることができる。図２２に示す動作シーケンス例では、プロキシは、ＳｉｎｋからのＢＬＯＣＫ ＭＯＶＥ対応であることを記載したＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥメッセージをＳｏｕｒｃｅにそのまま伝達するが、ＳｏｕｒｃｅからのＢＬＯＣＫ ＭＯＶＥ対応であることを記載したＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥメッセージを改竄して、ＢＬＯＣＫ ＭＯＶＥの要求を拒否し（Ｒｅｊｅｃｔｅｄ）、ＳｏｕｒｃｅがＢＬＯＣＫ ＭＯＶＥ非対応であると偽る。この場合、Ｓｏｕｒｃｅ側はＳｉｎｋからの要求に従ってＢＬＯＣＫ ＭＯＶＥモードでコンテンツ送信処理を行なうが、ＳｉｎｋはＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥモードに切り替わってコンテンツ受信処理を行なうことになる。
【０２９７】
このようなＭＯＶＥモード詐称攻撃が仕掛けられると、Ｓｉｎｋ側では、Ｓｏｕｒｃｅからデータを受け取る度に逐次的に有効化していくとともに、コンテンツ伝送処理が終了した時点でプロキシがＳｏｕｒｃｅに対してコンテンツ伝送処理の取り消しを行なうことで、ＳｏｕｒｃｅとＳｉｎｋの双方で有効なコンテンツが存在するというＤＴＣＰ−ＩＰの規定に抵触する事態が生じる。
【０２９８】
そこで、本実施形態に係るコンテンツ伝送システムは、ＳｏｕｒｃｅとＳｉｎｋ間で確認されたケイパビリティを詐称してＳｉｎｋ側のＭＯＶＥモードが偽装されることや、何らかの手段によりＭＯＶＥ伝送であることを装ってコンテンツのコピー伝送を行なうことを防止するための幾つかの方法を適用するようにしている。
【０２９９】
例えば、プロキシがＳｏｕｒｃｅ機器からのＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥメッセージを改ざんしてＢＬＯＣＫ ＭＯＶＥの要求を拒否し（Ｒｅｊｅｃｔｅｄ）、ＳｏｕｒｃｅがＢＬＯＣＫ ＭＯＶＥ非対応であると偽った場合であっても、その後ＡＫＥ手続きにおいて、ＳｉｎｋがＳｏｕｒｃｅに対して設定したＭＯＶＥモードを通知し、Ｓｏｕｒｃｅはケイパビリティの確認手続きを経て決定した自分のＭＯＶＥモードと照合することによって、詐称が行なわれているかどうかをチェックすることができる。あるいは図８中のＳｏｕｒｃｅ及びコンテンツの選択手続きや図１２中のＳｉｎｋ及びコンテンツの選択手続きにおいて、ｓｉｎｋに対してＭＯＶＥによるコンテンツ伝送を行なうことを正しく理解させ、過ってＣＯＰＹ伝送を行なわせないようにする。
【０３００】
図２３に示す動作シーケンス例では、Ｓｉｎｋは、ＡＫＥ認証手続き内で行なわれるチャレンジ・レスポンスを利用して、Ｓｏｕｒｃｅに送るレスポンスの中に自分の動作モードに関する情報を含める。この際、署名で保護される情報にＭＯＶＥモードの情報を含めることが望ましい。このレスポンスを受信したＳｏｕｒｃｅは、自分が設定しているＢＬＯＣＫ ＭＯＶＥモードとは相違することから、ＭＯＶＥモードの詐称が行なわれ、ＳｏｕｒｃｅとＳｉｎｋ間の伝送路が危険に晒されていることを気づくことができる。そして、Ｓｏｕｒｃｅは、交換鍵ＫxをＳｉｎｋに送らず、このような危険な伝送路でコンテンツ伝送を開始することなく、ＭＯＶＥ処理を終了する。
【０３０１】
また、図２４には、図２３に示した動作シーケンスの変形例を示している。図示のシーケンス例では、Ｓｉｎｋは、ＡＫＥ認証手続き内でＳｏｕｒｃｅに送るレスポンス中で、署名で保護される情報にＭＯＶＥモードの情報を含める。このレスポンスを受信したＳｏｕｒｃｅは、自分が設定しているＢＬＯＣＫ ＭＯＶＥモードとは相違することから、ＭＯＶＥモードの詐称が行なわれていることを気づくと、ＢＬＯＣＫ ＭＯＶＥモードからＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥモードに切り替わり、交換鍵ＫxをＳｉｎｋに送る。そして、ＳｏｕｒｃｅとＳｉｎｋはそれぞれ、交換鍵Ｋxに所定の演算を施してコンテンツ暗号鍵Ｋcを作成し、ＭＯＶＥ対象となるコンテンツの暗号化伝送を開始する。
【０３０２】
ＭＯＶＥモードの詐称を防止する他の方法として、交換鍵Ｋxをスクランブルする方法をＭＯＶＥモード毎に切り替える方法が挙げられる。図２５には、この場合の動作シーケンス例を示している。Ｓｏｕｒｃｅ側では、ＢＬＯＣＫ ＭＯＶＥを行なう際には、交換鍵Ｋxでスクランブルに使うワンタイム鍵をハッシュ関数で処理して使う。すると、ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥモード下にあるＳｉｎｋは、交換鍵Ｋx用のデスクランブル方法ではＢＬＯＣＫ ＭＯＶＥ用の交換鍵ＫxMを共用することができなくなる。すなわち、Ｓｉｎｋは、ＢＬＯＣＫ ＭＯＶＥモード以外では交換鍵Ｋx用のデスクランブルが禁止され、正しいコンテンツ暗号鍵Ｋcを作成できないので、ＭＯＶＥされたコンテンツを復号できない。
【０３０３】
また、ＭＯＶＥモードの詐称を防止するさらに他の方法として、交換鍵Ｋxからコンテンツ暗号鍵Ｋcを生成する計算式をＭＯＶＥモード毎に切り替える方法が挙げられる。図２６には、この場合の動作シーケンス例を示している。Ｓｏｕｒｃｅ側では、ＢＬＯＣＫ ＭＯＶＥを行なう際には、交換鍵ＫxMからコンテンツ暗号鍵Ｋcを生成するための計算式に含まれる定数を特別な値に変更する。すると、ＩＮＣＲＥＭＥＮＴＡＬ ＭＯＶＥモード下にあるＳｉｎｋ側では、通常の計算式に従って交換鍵Ｋxから計算しても、正しいコンテンツ暗号鍵Ｋcを作成できないので（言い換えれば、交換鍵ＫxMからコンテンツ暗号鍵Ｋcを計算することが禁止されているので）、ＭＯＶＥされたコンテンツを復号できない。
【０３０４】
よって、上述したいずれかの対策を講じることで、不正なプロキシが伝送路に介在する場合であっても、ＳｏｕｒｃｅとＳｉｎｋの双方で有効なコンテンツが存在するというＤＴＣＰ−ＩＰの規定に抵触する事態を回避することができる。
【０３０５】
図１６には、ＭＯＶＥ伝送モード詐称攻撃の対策としてＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥシーケンスについて説明したが、図２３〜図２６に示したような対策によってＭＯＶＥ伝送モード詐称攻撃を十分に防ぐことができ、これらの場合はＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥシーケンスを通じたセキュアな情報交換手続は不要となる。
【産業上の利用可能性】
【０３０６】
以上、特定の実施形態を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
【０３０７】
本発明の適用例として、ＳｏｕｒｃｅとＳｉｎｋ間で行なわれるＨＴＴＰプロトコルを利用したコンテンツ伝送を挙げることができるが、本発明の要旨はこれに限定されない。著作権やその他の目的で保護が必要となる情報コンテンツを所定のコピー制御情報に従って暗号化伝送する他のあらゆるコンテンツ伝送システム、あるいはコピー制御やコンテンツの暗号化を行なわないシステムであっても、移動元にデータを残さずに機器間でデータを移動させる際に、同様に本発明を適用することができる。
【０３０８】
要するに、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、特許請求の範囲を参酌すべきである。
【符号の説明】
【０３０９】
１０…ＤＴＣＰ−ＩＰ認証ブロック
１１…ＡＫＥブロック
１２…メッセージ・ダイジェスト生成ブロック
１３…コンテンツ復号ブロック
２０…ＤＴＣＰ−ＩＰコンテンツ受信ブロック
２１…ＨＴＴＰクライアント・ブロック
２２…ＨＴＴＰリクエスト管理ブロック
２３…ＨＴＴＰレスポンス管理ブロック
３０…コンテンツ再生／記録ブロック
４０…ＤＴＣＰ−ＩＰ認証ブロック
４１…ＡＫＥブロック
４２…メッセージ・ダイジェスト生成ブロック
４３…コンテンツ暗号化部ロック
５０…ＤＴＣＰ−ＩＰコンテンツ送信ブロック
５１…ＨＴＴＰサーバ・ブロック
５２…ＨＴＴＰリクエスト管理ブロック
５３…ＨＴＴＰレスポンス管理ブロック
６０…コンテンツ管理ブロック
【特許請求の範囲】
【請求項１】
コンテンツを送信するＳｏｕｒｃｅとコンテンツを受信するＳｉｎｋ間でコンテンツを伝送するコンテンツ伝送システムであって、
ＳｏｕｒｃｅとＳｉｎｋ間で伝送対象となるコンテンツを指定するコンテンツ指定手段と、
ＳｏｕｒｃｅとＳｉｎｋ間で相互認証及び鍵交換を行なう認証手段と、
前記認証手段により交換した鍵を用いてＳｏｕｒｃｅからＳｉｎｋへ、前記コンテンツ指定手段により指定されたコンテンツを暗号化伝送するコンテンツ伝送手段と、
コンテンツ伝送処理が終了するまではＳｉｎｋ側のコンテンツを無効化した状態に保ち、前記コンテンツ伝送手段によりコンテンツ伝送処理が終了したことに応じて、Ｓｉｎｋ側のコンテンツを有効化するとともに、Ｓｏｕｒｃｅ側の元のコンテンツを無効化するコンテンツ伝送終了処理手段と、
前記コンテンツ伝送手段によるコンテンツ伝送処理が終了するまでの間、Ｓｉｎｋ又はＳｏｕｒｃｅの少なくとも一方からの要求により、コンテンツ伝送処理を取り消すコンテンツ伝送処理取り消し手段と、
を備え、
前記認証手段は、コンテンツ伝送終了処理手段によるコンテンツ伝送終了処理が終了するまでの間、認証及び鍵交換用のＴＣＰコネクションを保持し、
前記コンテンツ伝送処理取り消し手段は、前記認証及び鍵交換用のＴＣＰコネクションを用いてコンテンツ伝送処理を取り消す、
コンテンツ伝送システム。
【請求項２】
前記コンテンツ伝送処理取り消し手段は、コンテンツ伝送処理を取り消す際に、Ｓｉｎｋに伝送されたコンテンツを削除する、
請求項１に記載のコンテンツ伝送システム。
【請求項３】
前記認証手段は、相互認証及び鍵交換に併せて、ＳｏｕｒｃｅとＳｉｎｋがともにコンテンツ伝送終了処理手段による処理に対応しているかどうかケイパビリティを確認する、
請求項１に記載のコンテンツ伝送システム。
【請求項４】
前記コンテンツ指定手段は、ＵＰｎＰで規定されているＣＤＳ（Ｃｏｎｔｅｎｔ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ）を利用して行ない、
前記認証手段、前記コンテンツ伝送手段、及びコンテンツ伝送終了処理手段は、ＤＴＣＰ−ＩＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ − Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）上で各処理を行なう、
請求項１に記載のコンテンツ伝送システム。
【請求項５】
ユーザが操作するＳｉｎｋが、コンテンツを提供するサーバとして動作するＳｏｕｒｃｅからコンテンツをダウンロードする形式でコンテンツの移動を行なう、
請求項４に記載のコンテンツ伝送システム。
【請求項６】
前記コンテンツ指定手段は、Ｓｉｎｋにおいて、ＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｑｕｅｓｔに対するＳｏｕｒｃｅからのＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｓｐｏｎｓｅに含まれる情報に基づいて、移動したいコンテンツの認証及び鍵交換用のソケット情報を取得するとともに当該コンテンツがＳｏｕｒｃｅから移動可能か否かを確認する、
請求項５に記載のコンテンツ伝送システム。
【請求項７】
前記コンテンツ伝送手段は、Ｓｉｎｋにおいて、ヘッダ内にコンテンツの移動であることを示すヘッダ情報を含めて、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ） ＧＥＴメソッドを用いてＳｏｕｒｃｅから暗号化コンテンツを取得する、
請求項５に記載のコンテンツ伝送システム。
【請求項８】
ユーザが操作するＳｏｕｒｃｅが、コンテンツを提供するサーバとして動作するＳｉｎｋに対してコンテンツをアップロードする形式でコンテンツの移動を行なう、
請求項１に記載のコンテンツ伝送システム。
【請求項９】
前記コンテンツ指定手段は、Ｓｏｕｒｃｅにおいて、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｑｕｅｓｔを用いて当該コンテンツの移動場所の作成を要求するとともに、該要求に対するＳｉｎｋからの応答によりコンテンツの移動場所のＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｄｅｎｔｉｆｉｅｒ）を受け取り、
前記コンテンツ伝送手段は、該受け取ったコンテンツの移動場所のＵＲＩに対してＨＴＴＰ ＰＯＳＴメソッドを用いてＳｏｕｒｃｅから暗号化コンテンツを伝送する、
請求項８に記載のコンテンツ伝送システム。
【請求項１０】
前記コンテンツ指定手段は、Ｓｏｕｒｃｅにおいて、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｑｕｅｓｔを用いてＳｉｎｋに対し認証及び鍵交換用のソケット情報を通知し、
前記認証手段は、該ソケット情報に基づいて認証及び鍵交換用のＴＣＰコネクションをＳｉｎｋ側から確立する、
請求項９に記載のコンテンツ伝送システム。
【請求項１１】
前記コンテンツ指定手段は、Ｓｏｕｒｃｅにおいて、ＣＤＳ：：Ｃｒｅａｔｅ Ｏｂｊｅｃｔ ｒｅｑｕｅｓｔの応答で受け取ったコンテンツ移動先のＵＲＩに対して（コンテンツを含まない）ＨＴＴＰ ＰＯＳＴメソッドのヘッダ情報を用いてＳｉｎｋに対し認証及び鍵交換用のソケット情報を通知し、
前記認証手段は、該ソケット情報に基づいて認証及び鍵交換用のＴＣＰコネクションをＳｉｎｋ側から確立する、
請求項９に記載のコンテンツ伝送システム。
【請求項１２】
前記コンテンツ伝送手段は、Ｓｏｕｒｃｅにおいて、ヘッダ内にコンテンツの移動であることを示すヘッダ情報を含めて、ＨＴＴＰ ＰＯＳＴメソッドを用いてＳｉｎｋへ暗号化コンテンツを送信する、
請求項８に記載のコンテンツ伝送システム。
【請求項１３】
前記認証手段は、移動するコンテンツ毎にＡＫＥ手続きによりコンテンツ移動専用の鍵の交換を行なう、
請求項３に記載のコンテンツ伝送システム。
【請求項１４】
前記認証手段は、前記コンテンツ伝送終了処理手段によるコンテンツ伝送終了処理が終了したことに応答して、Ｓｏｕｒｃｅ及びＳｉｎｋにおけるコンテンツ移動専用の交換鍵を消滅させる、
請求項１３に記載のコンテンツ伝送システム。
【請求項１５】
Ｓｏｕｒｃｅは、Ｓｉｎｋに対してコンテンツを移動中、他のＳｉｎｋからの当該コンテンツの移動要求を拒否する、
請求項１に記載のコンテンツ伝送システム。
【請求項１６】
Ｓｉｎｋは、Ｓｏｕｒｃｅから移動中でまだ有効化されていないコンテンツを再生する手段を備える、
請求項１に記載のコンテンツ伝送システム。
【請求項１７】
前記コンテンツ伝送手段によるコンテンツ伝送処理が終了するまでの間、ＳｉｎｋとＳｏｕｒｃｅ間の通信が途切れたときに、Ｓｉｎｋ又はＳｏｕｒｃｅの少なくとも一方からの要求によりコンテンツ伝送処理を中止するコンテンツ伝送処理中止手段をさらに備える、
請求項１に記載のコンテンツ伝送システム。
【請求項１８】
前記コンテンツ伝送終了処理手段は、
ＳｉｎｋからＳｏｕｒｃｅに対してコンテンツ受信終了を示す第１のコマンドが送信されたことに応答して、Ｓｏｕｒｃｅ側の元のコンテンツを中間的な無効状態にし、
ＳｏｕｒｃｅからＳｉｎｋに第１のコマンドに対する第１のレスポンスが返信されたことに応答してＳｉｎｋ側に伝送されたコンテンツを有効化するとともに、Ｓｉｎｋ側で保持するコンテンツ移動専用の鍵乃至第１のコマンドで送る情報を消滅させ、
ＳｉｎｋからＳｏｕｒｃｅに対してコンテンツ有効化を示す第２のコマンドが送信されたことに応答して、Ｓｏｕｒｃｅ側の元のコンテンツを無効状態にするとともに、Ｓｏｕｒｃｅ側で保持するコンテンツ移動専用の鍵乃至第１のレスポンスで送る情報を消滅させる、
請求項１に記載のコンテンツ伝送システム。
【請求項１９】
前記コンテンツ伝送手段によるＳｏｕｒｃｅからＳｉｎｋへのコンテンツ伝送が成功裏に終了したにも拘らず、前記コンテンツ伝送終了処理手段による処理が途切れてしまった場合に、コンテンツ伝送終了処理を再開するためのコンテンツ伝送終了処理再開手段をさらに備える、
請求項１８に記載のコンテンツ伝送システム。
【請求項２０】
前記コンテンツ伝送終了処理再開手段は、ＳｏｕｒｃｅがＳｉｎｋからコンテンツ受信終了を示す第１のコマンドを受信したときに、Ｓｏｕｒｃｅがコンテンツ移動専用の交換鍵乃至第１のレスポンスで送る情報をまだ保持している場合には、Ｓｏｕｒｃｅ側の元のコンテンツを中間的な無効状態にし、ＳｏｕｒｃｅからＳｉｎｋに第１のコマンドに対する第１のレスポンスを返信させる、
請求項１９に記載のコンテンツ伝送システム。
【請求項２１】
前記コンテンツ伝送終了処理再開手段は、ＳｏｕｒｃｅがＳｉｎｋからコンテンツ受信終了を示す第２のコマンドを受信したときに、Ｓｏｕｒｃｅがコンテンツ移動専用の交換鍵乃至第１のレスポンスで送る情報をまだ保持している場合には、Ｓｏｕｒｃｅ側の元のコンテンツを無効状態にし、Ｓｏｕｒｃｅ側で保持するコンテンツ移動専用の鍵乃至第１のレスポンスで送る情報を消滅させるとともに、ＳｏｕｒｃｅからＳｉｎｋに第２のコマンドに対する第２のレスポンスを返信させる、
請求項１９に記載のコンテンツ伝送システム。
【請求項２２】
前記コンテンツ伝送終了処理再開手段は、Ｓｉｎｋがコンテンツ移動専用の交換鍵乃至第１のコマンドで送る情報をまだ保持している場合には、コンテンツ移動元となるＳｏｕｒｃｅとの接続を確立し、該当するコンテンツがＳｉｎｋ側で無効状態であればＳｏｕｒｃｅに第１のコマンドを送信させ、該当するコンテンツがＳｉｎｋ側で既に有効化されていれば第２のコマンドを送信させる、
請求項１９に記載のコンテンツ伝送システム。
【請求項２３】
前記コンテンツ伝送終了処理再開手段は、再開処理を行なうためのＳｉｎｋ及びＳｏｕｒｃｅ間のコネクションを確立する手段を備える、
請求項１９に記載のコンテンツ伝送システム。
【請求項２４】
前記コンテンツ伝送終了処理再開手段は、ダウンロード形式で行なわれたコンテンツ伝送の終了処理を再開する際に、Ｓｉｎｋにおいて、ＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｑｕｅｓｔに対するＳｏｕｒｃｅからのＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｓｐｏｎｓｅに含まれる情報に基づいて認証及び鍵交換用のソケット情報を取得して、Ｓｏｕｒｃｅとのコネクションを確立する、
請求項２３に記載のコンテンツ伝送システム。
【請求項２５】
前記コンテンツ伝送終了処理再開手段は、アップロード形式で行なわれたコンテンツ伝送の終了処理を再開する際に、Ｓｏｕｒｃｅにおいて、（コンテンツを含まない）ＨＴＴＰ ＰＯＳＴメソッドを用いてＳｉｎｋに認証及び鍵交換用のソケット情報を通知し、Ｓｉｎｋが該ソケット情報に基づいてＳｏｕｒｃｅとのコネクションを確立する、
請求項２３に記載のコンテンツ伝送システム。
【請求項２６】
前記認証手段によりＳｏｕｒｃｅとＳｉｎｋ間で確認されたＭＯＶＥ伝送の詐称を防止する詐称防止手段をさらに備える、
請求項１に記載のコンテンツ伝送システム。
【請求項２７】
前記詐称防止手段は、コンテンツ伝送方法毎に前記認証手段で交換した鍵からコンテンツ暗号鍵を生成する方法を変える、
請求項２６に記載のコンテンツ伝送システム。
【請求項２８】
前記詐称防止手段は、コンテンツ伝送方法毎に前記認証手段で交換した鍵をスクランブルする方法を変える、
請求項２６に記載のコンテンツ伝送システム。
【請求項２９】
前記詐称防止手段は、相互認証及び鍵交換のためのチャレンジ・レスポンス手続きにおいて、ＳｉｎｋからＳｏｕｒｃｅへの通信メッセージの中にコンテンツ伝送方法に関する情報を含める、
請求項２６に記載のコンテンツ伝送システム。
【請求項３０】
ＤＴＣＰに従ってコンテンツを送信するＳｏｕｒｃｅとして動作するコンテンツ伝送装置であって、
Ｓｉｎｋとの間で伝送対象となるコンテンツを指定するコンテンツ指定手段と、
ＡＫＥ手続きによりＳｉｎｋとの間で相互認証及び鍵交換を行なう認証手段と、
前記認証手段により交換した鍵を用いて、前記コンテンツ指定手段により指定されたコンテンツを、Ｓｉｎｋへ暗号化伝送するコンテンツ伝送手段と、
コンテンツ伝送処理が終了するまではＳｉｎｋ側のコンテンツを無効化した状態に保ち、前記コンテンツ伝送手段によりコンテンツ伝送処理が終了したことに応じて、元のコンテンツを無効化するコンテンツ伝送終了処理手段と、
前記コンテンツ伝送手段によるコンテンツ伝送処理が終了するまでの間、コンテンツ伝送処理を取り消すコンテンツ伝送処理取り消し手段と、
を備え、
前記認証手段は、コンテンツ伝送終了処理手段によるコンテンツ伝送終了処理が終了するまでの間、認証及び鍵交換用のＴＣＰコネクションを保持し、
前記コンテンツ伝送処理取り消し手段は、前記認証及び鍵交換用のＴＣＰコネクションを用いてコンテンツ伝送処理を取り消す、
コンテンツ伝送装置。
【請求項３１】
前記コンテンツ伝送処理取り消し手段は、コンテンツ伝送処理を取り消す際に、Ｓｉｎｋに伝送されたコンテンツを削除する、
請求項３０に記載のコンテンツ伝送装置。
【請求項３２】
前記認証手段は、相互認証及び鍵交換に併せて、Ｓｉｎｋがコンテンツ伝送終了処理手段に対応しているかどうかケイパビリティを確認する、
請求項３０に記載のコンテンツ伝送装置。
【請求項３３】
コンテンツを提供するサーバとして動作し、Ｓｉｎｋ側からのユーザ操作に応じてコンテンツをＳｉｎｋへダウンロードする際に、
前記コンテンツ指定手段は、ＳｉｎｋからのＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｑｕｅｓｔに応答して、各コンテンツの認証及び鍵交換用のソケット情報と当該コンテンツがＳｏｕｒｃｅから移動可能か否かを記載したＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｓｐｏｎｓｅを返信し、
前記コンテンツ伝送手段は、Ｓｉｎｋからの、ヘッダ内にコンテンツの移動であることを示すヘッダ情報を含んだＨＴＴＰ ＧＥＴメソッドに応じて暗号化コンテンツを伝送する、
請求項３０に記載のコンテンツ伝送装置。
【請求項３４】
コンテンツを提供するサーバとして動作するＳｉｎｋに対して、ユーザの操作に応じてコンテンツをアップロードする際に、
前記コンテンツ指定手段は、Ｓｉｎｋに対して、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｑｕｅｓｔを用いて当該コンテンツの移動場所の作成を要求するとともに、該要求に対するＳｉｎｋからの応答によりコンテンツの移動場所のＵＲＩを受け取り、
前記コンテンツ伝送手段は、ヘッダ内にコンテンツの移動であることを示すヘッダ情報を含めて、該受け取ったコンテンツの移動場所のＵＲＩに対してＨＴＴＰ ＰＯＳＴメソッドを用いてＳｉｎｋへ暗号化コンテンツを送信する、
請求項３０に記載のコンテンツ伝送装置。
【請求項３５】
前記コンテンツ指定手段は、Ｓｉｎｋに対し、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｑｕｅｓｔを用いて認証及び鍵交換用のソケット情報を通知し、
前記認証手段は、該ソケット情報に基づいてＳｉｎｋ側から認証及び鍵交換用のＴＣＰコネクションを確立する、
請求項３４に記載のコンテンツ伝送装置。
【請求項３６】
前記コンテンツ指定手段は、Ｓｉｎｋに対し、ＣＤＳ：：Ｃｒｅａｔｅ Ｏｂｊｅｃｔ ｒｅｑｕｅｓｔの応答で受け取ったコンテンツ移動先のＵＲＩに対して（コンテンツを含まない）ＨＴＴＰ ＰＯＳＴメソッドのヘッダ情報を用いて認証及び鍵交換用のソケット情報を通知し、
前記認証手段は、該ソケット情報に基づいてＳｉｎｋ側から認証及び鍵交換用のＴＣＰコネクションをＳｉｎｋ側から確立させる、
請求項３４に記載のコンテンツ伝送装置。
【請求項３７】
前記認証手段は、Ｓｉｎｋへ移動するコンテンツ毎にＡＫＥ手続きによりコンテンツ移動専用の鍵の交換を行なう、
請求項３０に記載のコンテンツ伝送装置。
【請求項３８】
前記認証手段は、前記コンテンツ伝送手段によるコンテンツの伝送が終了したことに応答して、コンテンツ移動専用の鍵を消滅させる、
請求項３０に記載のコンテンツ伝送装置。
【請求項３９】
前記コンテンツ伝送手段は、Ｓｉｎｋに対してコンテンツを移動中、他のＳｉｎｋからの当該コンテンツの移動要求を拒否する、
請求項３０に記載のコンテンツ伝送装置。
【請求項４０】
前記認証手段は、コンテンツ伝送手段によるコンテンツ伝送処理が終了するまでの間、認証及び鍵交換用のＴＣＰコネクションを保持し、
前記コンテンツ伝送手段によるコンテンツ伝送処理が終了するまでの間、認証及び鍵交換用のＴＣＰコネクションを用いてコンテンツ伝送処理を取り消すコンテンツ伝送処理取り消し手段をさらに備える、
請求項３０に記載のコンテンツ伝送装置。
【請求項４１】
前記コンテンツ伝送手段によるコンテンツ伝送処理が終了するまでの間、Ｓｉｎｋとの通信が途切れたときに、コンテンツ伝送処理を中止するコンテンツ伝送処理中止手段をさらに備える、
請求項３０に記載のコンテンツ伝送装置。
【請求項４２】
前記コンテンツ伝送終了処理手段は、
Ｓｉｎｋからコンテンツ受信終了を示す第１のコマンドが受信したことに応答して元のコンテンツを中間的な無効状態にするとともに第１のコマンドに対する第１のレスポンスを返信し、
Ｓｉｎｋからコンテンツ有効化を示す第２のコマンドが受信したことに応答して、Ｓｏｕｒｃｅ側の元のコンテンツを無効状態にする、
請求項３０に記載のコンテンツ伝送装置。
【請求項４３】
前記コンテンツ伝送手段によるＳｉｎｋへのコンテンツ伝送が成功裏に終了したにも拘らず、前記コンテンツ伝送終了処理手段による処理が途切れてしまった場合に、コンテンツ伝送終了処理を再開するためのコンテンツ伝送終了処理再開手段をさらに備える、
請求項４２に記載のコンテンツ伝送装置。
【請求項４４】
前記コンテンツ伝送終了処理再開手段は、Ｓｉｎｋからコンテンツ受信終了を示す第１のコマンドを受信したときに、前記認証手段がコンテンツ移動専用の交換鍵乃至第１のレスポンスで送る情報をまだ保持している場合には、元のコンテンツを中間的な無効状態にするとともに、Ｓｉｎｋに第１のコマンドに対する第１のレスポンスが返信する、
請求項４３に記載のコンテンツ伝送装置。
【請求項４５】
前記コンテンツ伝送終了処理再開手段は、Ｓｉｎｋからコンテンツ受信終了を示す第２のコマンドを受信したときに、前記認証手段がコンテンツ移動専用の交換鍵乃至第１のレスポンスで送る情報をまだ保持している場合には、元のコンテンツを無効状態にし、前記認証手段が保持するコンテンツ移動専用の鍵を消滅させるとともに、Ｓｉｎｋに第２のコマンドに対する第２のレスポンスが返信する、
請求項４３に記載のコンテンツ伝送装置。
【請求項４６】
前記コンテンツ伝送終了処理再開手段は、再開処理を行なうためのＳｉｎｋとのコネクションを確立する手段を備える、
請求項４３に記載のコンテンツ伝送装置。
【請求項４７】
前記コンテンツ伝送終了処理再開手段は、ダウンロード形式で行なわれたコンテンツ伝送の終了処理を再開する際に、ＳｉｎｋからのＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｑｕｅｓｔに対して認証及び鍵交換用のソケット情報を含んだＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｓｐｏｎｓｅを返信して、Ｓｉｎｋとのコネクションを確立する、
請求項４６に記載のコンテンツ伝送装置。
【請求項４８】
前記コンテンツ伝送終了処理再開手段は、アップロード形式で行なわれたコンテンツ伝送の終了処理を再開する際に、ＨＴＴＰ ＰＯＳＴメソッドを用いてＳｉｎｋに認証及び鍵交換用のソケット情報を通知して、Ｓｉｎｋとのコネクションを確立する、
請求項４６に記載のコンテンツ伝送装置。
【請求項４９】
前記認証手段によりＳｉｎｋとの間で確認されたＭＯＶＥ伝送の詐称を防止する詐称防止手段をさらに備える、
請求項３０に記載のコンテンツ伝送装置。
【請求項５０】
前記詐称防止手段は、ケイパビリティに対応したコンテンツ伝送方法毎に前記認証手段で交換した鍵からコンテンツ暗号鍵を生成する方法を変える、
請求項４９に記載のコンテンツ伝送装置。
【請求項５１】
前記詐称防止手段は、コンテンツ伝送方法毎に前記認証手段で交換した鍵をスクランブルする方法を変える、
請求項４９に記載のコンテンツ伝送装置。
【請求項５２】
ＤＴＣＰに従ってコンテンツを受信するＳｉｎｋとして動作するコンテンツ伝送装置であって、
Ｓｏｕｒｃｅとの間で伝送対象となるコンテンツを指定するコンテンツ指定手段と、
ＡＫＥ手続きによりＳｏｕｒｃｅとの間で相互認証及び鍵交換を行なう認証手段と、
前記認証手段により交換した鍵を用いて、前記コンテンツ指定手段により指定されたコンテンツを、Ｓｏｕｒｃｅから暗号化伝送するコンテンツ伝送手段と、
コンテンツ伝送処理が終了するまではコンテンツを無効化した状態に保ち、前記コンテンツ伝送手段によりコンテンツ伝送処理が終了したことに応じて、受信したコンテンツを有効化するコンテンツ伝送終了処理手段と、
前記コンテンツ伝送手段によるコンテンツ伝送処理が終了するまでの間、認コンテンツ伝送処理を取り消すコンテンツ伝送処理取り消し手段と、
を備え、
前記認証手段は、コンテンツ伝送終了処理手段によるコンテンツ伝送終了処理が終了するまでの間、認証及び鍵交換用のＴＣＰコネクションを保持し、
前記コンテンツ伝送処理取り消し手段は、前記認証及び鍵交換用のＴＣＰコネクションを用いてコンテンツ伝送処理を取り消す、
コンテンツ伝送装置。
【請求項５３】
前記認証手段は、相互認証及び鍵交換に併せて、Ｓｉｎｋがコンテンツ伝送終了処理手段に対応しているかどうかケイパビリティを確認する、
請求項５２に記載のコンテンツ伝送装置。
【請求項５４】
コンテンツを提供するサーバとして動作するＳｏｕｒｃｅから、ユーザ操作に応じてコンテンツをダウンロードする際に、
前記コンテンツ指定手段は、ＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｑｕｅｓｔを送信し、ＳｏｕｒｃｅからのＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｓｐｏｎｓｅに含まれる情報に基づいて、移動したいコンテンツの認証及び鍵交換用のソケット情報を取得するとともに当該コンテンツがＳｏｕｒｃｅから移動可能か否かを確認し、
前記コンテンツ伝送手段は、ヘッダ内にコンテンツの移動であることを示すヘッダ情報を含めて、ＨＴＴＰ ＧＥＴメソッドを用いてＳｏｕｒｃｅから暗号化コンテンツを取得する、
請求項５２に記載のコンテンツ伝送装置。
【請求項５５】
コンテンツを提供するサーバとして動作し、Ｓｏｕｒｃｅ側からのユーザの操作に応じてコンテンツをアップロードする際に、
前記コンテンツ指定手段は、Ｓｏｕｒｃｅから受信したＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｑｕｅｓｔに基づいて当該コンテンツの移動場所を作成し、
前記コンテンツ伝送手段は、Ｓｏｕｒｃｅからの、ヘッダ内にコンテンツの移動であることを示すヘッダ情報を含んだＨＴＴＰ ＰＯＳＴメソッドにより暗号化コンテンツを受信する、
請求項５２に記載のコンテンツ伝送装置。
【請求項５６】
前記認証手段は、前記コンテンツ伝送手段によるコンテンツの伝送が終了したことに応答して、コンテンツ移動専用の鍵の交換を消滅させる、
請求項５２に記載のコンテンツ伝送装置。
【請求項５７】
Ｓｏｕｒｃｅから移動中でまだ有効化されていないコンテンツを再生する手段をさらに備える、
請求項５２に記載のコンテンツ伝送装置。
【請求項５８】
前記コンテンツ伝送手段によるコンテンツ伝送処理が終了するまでの間、認証及び鍵交換用のＴＣＰコネクションを用いてコンテンツ伝送処理を取り消すコンテンツ伝送処理取り消し手段をさらに備える、
請求項５２に記載のコンテンツ伝送装置。
【請求項５９】
前記コンテンツ伝送処理取り消し手段は、コンテンツ伝送処理を取り消す際に、Ｓｏｕｒｃｅから伝送されたコンテンツを無効化する、
請求項５８に記載のコンテンツ伝送装置。
【請求項６０】
前記コンテンツ伝送手段によるコンテンツ伝送処理が終了するまでの間、Ｓｏｕｒｃｅとの通信が途切れたときに、コンテンツ伝送処理を中止するコンテンツ伝送処理中止手段をさらに備える、
請求項５２に記載のコンテンツ伝送装置。
【請求項６１】
前記コンテンツ伝送終了処理手段は、Ｓｏｕｒｃｅに対してコンテンツ受信終了を示す第１のコマンドを送信し、ＳｏｕｒｃｅからＳｉｎｋに第１のコマンドに対する第１のレスポンスが返信されたことに応答して伝送されたコンテンツを有効化するとともに、前記認証手段が保持するコンテンツ移動専用の鍵乃至第１のコマンドで送る情報を消滅させる、
請求項５２に記載のコンテンツ伝送装置。
【請求項６２】
前記コンテンツ伝送手段によるＳｏｕｒｃｅとのコンテンツ伝送が成功裏に終了したにも拘らず、前記コンテンツ伝送終了処理手段による処理が途切れてしまった場合に、コンテンツ伝送終了処理を再開するためのコンテンツ伝送終了処理再開手段をさらに備える、
請求項６１に記載のコンテンツ伝送装置。
【請求項６３】
前記コンテンツ伝送終了処理再開手段は、前記認証手段がコンテンツ移動専用の交換鍵乃至第１のコマンドで送る情報をまだ保持している場合には、Ｓｏｕｒｃｅとの接続を確立し、該当するコンテンツが無効状態であればＳｏｕｒｃｅに第１のコマンドを送信し、該当するコンテンツがＳｉｎｋ側で既に有効化されていれば第２のコマンドを送信する、
請求項６２に記載のコンテンツ伝送装置。
【請求項６４】
前記コンテンツ伝送終了処理再開手段は、再開処理を行なうためのＳｏｕｒｃｅとのコネクションを確立する手段を備える、
請求項６２に記載のコンテンツ伝送装置。
【請求項６５】
前記コンテンツ伝送終了処理再開手段は、ダウンロード形式で行なわれたコンテンツ伝送の終了処理を再開する際に、ＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｑｕｅｓｔに対するＳｏｕｒｃｅからのＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｓｐｏｎｓｅに含まれる情報に基づいて認証及び鍵交換用のソケット情報を取得して、Ｓｏｕｒｃｅとのコネクションを確立する、
請求項６４に記載のコンテンツ伝送装置。
【請求項６６】
前記コンテンツ伝送終了処理再開手段は、アップロード形式で行なわれたコンテンツ伝送の終了処理を再開する際に、Ｓｏｕｒｃｅからの（コンテンツを含まない）ＨＴＴＰ ＰＯＳＴメソッドを用いて通知された認証及び鍵交換用のソケット情報に基づいてＳｏｕｒｃｅとのコネクションを確立する、
請求項６４に記載のコンテンツ伝送装置。
【請求項６７】
前記認証手段によりＳｏｕｒｃｅとの間で確認されたＭＯＶＥ伝送の詐称を防止する詐称防止手段をさらに備える、
請求項５２に記載のコンテンツ伝送装置。
【請求項６８】
前記詐称防止手段は、相互認証及び鍵交換のためのチャレンジ・レスポンス手続きにおいて、Ｓｏｕｒｃｅへの通信メッセージの中にコンテンツ伝送方法に関する情報を含める、
請求項６７に記載のコンテンツ伝送装置。
【請求項６９】
ＤＴＣＰ Ｓｏｕｒｃｅとしてコンテンツを送信するコンテンツ伝送方法であって、
Ｓｉｎｋとの間で伝送対象となるコンテンツを指定するコンテンツ指定ステップと、
ＡＫＥ手続きによりＳｉｎｋとの間で相互認証及び鍵交換を行なう認証ステップと、
前記認証ステップにおいて交換した鍵を用いて、前記コンテンツ指定ステップにおいて指定されたコンテンツを、Ｓｉｎｋへ暗号化伝送するコンテンツ伝送ステップと、
コンテンツ伝送処理が終了するまではＳｉｎｋ側のコンテンツを無効化した状態に保ち、前記コンテンツ伝送ステップにおいてコンテンツ伝送処理が終了したことに応じて、元のコンテンツを無効化するコンテンツ伝送終了処理ステップと、
前記コンテンツ伝送ステップにおけるコンテンツ伝送処理が終了するまでの間、コンテンツ伝送処理を取り消すコンテンツ伝送処理取り消しステップと、
を有し、
前記認証ステップでは、コンテンツ伝送終了処理ステップにおけるコンテンツ伝送終了処理が終了するまでの間、認証及び鍵交換用のＴＣＰコネクションを保持し、
前記コンテンツ伝送処理取り消しステップでは、前記認証及び鍵交換用のＴＣＰコネクションを用いてコンテンツ伝送処理を取り消す、
コンテンツ伝送方法。
【請求項７０】
ＤＴＣＰ Ｓｉｎｋとしてコンテンツを受信するコンテンツ伝送方法であって、
Ｓｏｕｒｃｅとの間で伝送対象となるコンテンツを指定するコンテンツ指定ステップと、
ＡＫＥ手続きによりＳｏｕｒｃｅとの間で相互認証及び鍵交換を行なう認証ステップと、
前記認証ステップにおいて交換した鍵を用いて、前記コンテンツ指定ステップにおいて指定されたコンテンツを、Ｓｏｕｒｃｅから暗号化伝送するコンテンツ伝送ステップと、
コンテンツ伝送処理が終了するまではコンテンツを無効化した状態に保ち、前記コンテンツ伝送ステップにおいてコンテンツ伝送処理が終了したことに応じて、受信したコンテンツを有効化するコンテンツ伝送終了処理ステップと、
前記コンテンツ伝送ステップにおけるコンテンツ伝送処理が終了するまでの間、コンテンツ伝送処理を取り消すコンテンツ伝送処理取り消しステップと、
を有し、
前記認証ステップでは、コンテンツ伝送終了処理ステップにおけるコンテンツ伝送終了処理が終了するまでの間、認証及び鍵交換用のＴＣＰコネクションを保持し、
前記コンテンツ伝送処理取り消しステップでは、前記認証及び鍵交換用のＴＣＰコネクションを用いてコンテンツ伝送処理を取り消す、
コンテンツ伝送方法。
【請求項７１】
ＤＴＣＰ Ｓｏｕｒｃｅとしてコンテンツを送信するための処理をコンピュータ上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータを、
Ｓｉｎｋとの間で伝送対象となるコンテンツを指定するコンテンツ指定手段、
ＡＫＥ手続きによりＳｉｎｋとの間で相互認証及び鍵交換を行なう認証手段、
前記認証手段により交換した鍵を用いて、前記コンテンツ指定手段により指定されたコンテンツを、Ｓｉｎｋへ暗号化伝送するコンテンツ伝送手段、
コンテンツ伝送処理が終了するまでははＳｉｎｋ側のコンテンツを無効化した状態に保ち、前記コンテンツ伝送手段によりコンテンツ伝送処理が終了したことに応じて、元のコンテンツを無効化するコンテンツ伝送終了処理手段、
前記コンテンツ伝送手段によるコンテンツ伝送処理が終了するまでの間、コンテンツ伝送処理を取り消すコンテンツ伝送処理取り消し手段、
として機能させ、
前記認証手段は、コンテンツ伝送終了処理手段によるコンテンツ伝送終了処理が終了するまでの間、認証及び鍵交換用のＴＣＰコネクションを保持し、
前記コンテンツ伝送処理取り消し手段は、前記認証及び鍵交換用のＴＣＰコネクションを用いてコンテンツ伝送処理を取り消す、
コンピュータ・プログラム。
【請求項７２】
ＤＴＣＰ Ｓｉｎｋとしてコンテンツを受信するための処理をコンピュータ上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータを、
Ｓｏｕｒｃｅとの間で伝送対象となるコンテンツを指定するコンテンツ指定手段、
ＡＫＥ手続きによりＳｏｕｒｃｅとの間で相互認証及び鍵交換を行なう認証手段、
前記認証手段により交換した鍵を用いて、前記コンテンツ指定手段により指定されたコンテンツを、Ｓｏｕｒｃｅから暗号化伝送するコンテンツ伝送手段、
コンテンツ伝送処理が終了するまではコンテンツを無効化した状態に保ち、前記コンテンツ伝送手段によりコンテンツ伝送処理が終了したことに応じて、受信したコンテンツを有効化するコンテンツ伝送終了処理手段、
前記コンテンツ伝送手段によるコンテンツ伝送処理が終了するまでの間、てコンテンツ伝送処理を取り消すコンテンツ伝送処理取り消し手段、
として機能させ、
前記認証手段は、コンテンツ伝送終了処理手段によるコンテンツ伝送終了処理が終了するまでの間、認証及び鍵交換用のＴＣＰコネクションを保持し、
前記コンテンツ伝送処理取り消し手段は、前記認証及び鍵交換用のＴＣＰコネクションを用いてコンテンツ伝送処理を取り消す、
コンピュータ・プログラム。
【請求項１】
コンテンツを送信するＳｏｕｒｃｅとコンテンツを受信するＳｉｎｋ間でコンテンツを伝送するコンテンツ伝送システムであって、
ＳｏｕｒｃｅとＳｉｎｋ間で伝送対象となるコンテンツを指定するコンテンツ指定手段と、
ＳｏｕｒｃｅとＳｉｎｋ間で相互認証及び鍵交換を行なう認証手段と、
前記認証手段により交換した鍵を用いてＳｏｕｒｃｅからＳｉｎｋへ、前記コンテンツ指定手段により指定されたコンテンツを暗号化伝送するコンテンツ伝送手段と、
コンテンツ伝送処理が終了するまではＳｉｎｋ側のコンテンツを無効化した状態に保ち、前記コンテンツ伝送手段によりコンテンツ伝送処理が終了したことに応じて、Ｓｉｎｋ側のコンテンツを有効化するとともに、Ｓｏｕｒｃｅ側の元のコンテンツを無効化するコンテンツ伝送終了処理手段と、
前記コンテンツ伝送手段によるコンテンツ伝送処理が終了するまでの間、Ｓｉｎｋ又はＳｏｕｒｃｅの少なくとも一方からの要求により、コンテンツ伝送処理を取り消すコンテンツ伝送処理取り消し手段と、
を備え、
前記認証手段は、コンテンツ伝送終了処理手段によるコンテンツ伝送終了処理が終了するまでの間、認証及び鍵交換用のＴＣＰコネクションを保持し、
前記コンテンツ伝送処理取り消し手段は、前記認証及び鍵交換用のＴＣＰコネクションを用いてコンテンツ伝送処理を取り消す、
コンテンツ伝送システム。
【請求項２】
前記コンテンツ伝送処理取り消し手段は、コンテンツ伝送処理を取り消す際に、Ｓｉｎｋに伝送されたコンテンツを削除する、
請求項１に記載のコンテンツ伝送システム。
【請求項３】
前記認証手段は、相互認証及び鍵交換に併せて、ＳｏｕｒｃｅとＳｉｎｋがともにコンテンツ伝送終了処理手段による処理に対応しているかどうかケイパビリティを確認する、
請求項１に記載のコンテンツ伝送システム。
【請求項４】
前記コンテンツ指定手段は、ＵＰｎＰで規定されているＣＤＳ（Ｃｏｎｔｅｎｔ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ）を利用して行ない、
前記認証手段、前記コンテンツ伝送手段、及びコンテンツ伝送終了処理手段は、ＤＴＣＰ−ＩＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ − Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）上で各処理を行なう、
請求項１に記載のコンテンツ伝送システム。
【請求項５】
ユーザが操作するＳｉｎｋが、コンテンツを提供するサーバとして動作するＳｏｕｒｃｅからコンテンツをダウンロードする形式でコンテンツの移動を行なう、
請求項４に記載のコンテンツ伝送システム。
【請求項６】
前記コンテンツ指定手段は、Ｓｉｎｋにおいて、ＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｑｕｅｓｔに対するＳｏｕｒｃｅからのＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｓｐｏｎｓｅに含まれる情報に基づいて、移動したいコンテンツの認証及び鍵交換用のソケット情報を取得するとともに当該コンテンツがＳｏｕｒｃｅから移動可能か否かを確認する、
請求項５に記載のコンテンツ伝送システム。
【請求項７】
前記コンテンツ伝送手段は、Ｓｉｎｋにおいて、ヘッダ内にコンテンツの移動であることを示すヘッダ情報を含めて、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ） ＧＥＴメソッドを用いてＳｏｕｒｃｅから暗号化コンテンツを取得する、
請求項５に記載のコンテンツ伝送システム。
【請求項８】
ユーザが操作するＳｏｕｒｃｅが、コンテンツを提供するサーバとして動作するＳｉｎｋに対してコンテンツをアップロードする形式でコンテンツの移動を行なう、
請求項１に記載のコンテンツ伝送システム。
【請求項９】
前記コンテンツ指定手段は、Ｓｏｕｒｃｅにおいて、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｑｕｅｓｔを用いて当該コンテンツの移動場所の作成を要求するとともに、該要求に対するＳｉｎｋからの応答によりコンテンツの移動場所のＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｄｅｎｔｉｆｉｅｒ）を受け取り、
前記コンテンツ伝送手段は、該受け取ったコンテンツの移動場所のＵＲＩに対してＨＴＴＰ ＰＯＳＴメソッドを用いてＳｏｕｒｃｅから暗号化コンテンツを伝送する、
請求項８に記載のコンテンツ伝送システム。
【請求項１０】
前記コンテンツ指定手段は、Ｓｏｕｒｃｅにおいて、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｑｕｅｓｔを用いてＳｉｎｋに対し認証及び鍵交換用のソケット情報を通知し、
前記認証手段は、該ソケット情報に基づいて認証及び鍵交換用のＴＣＰコネクションをＳｉｎｋ側から確立する、
請求項９に記載のコンテンツ伝送システム。
【請求項１１】
前記コンテンツ指定手段は、Ｓｏｕｒｃｅにおいて、ＣＤＳ：：Ｃｒｅａｔｅ Ｏｂｊｅｃｔ ｒｅｑｕｅｓｔの応答で受け取ったコンテンツ移動先のＵＲＩに対して（コンテンツを含まない）ＨＴＴＰ ＰＯＳＴメソッドのヘッダ情報を用いてＳｉｎｋに対し認証及び鍵交換用のソケット情報を通知し、
前記認証手段は、該ソケット情報に基づいて認証及び鍵交換用のＴＣＰコネクションをＳｉｎｋ側から確立する、
請求項９に記載のコンテンツ伝送システム。
【請求項１２】
前記コンテンツ伝送手段は、Ｓｏｕｒｃｅにおいて、ヘッダ内にコンテンツの移動であることを示すヘッダ情報を含めて、ＨＴＴＰ ＰＯＳＴメソッドを用いてＳｉｎｋへ暗号化コンテンツを送信する、
請求項８に記載のコンテンツ伝送システム。
【請求項１３】
前記認証手段は、移動するコンテンツ毎にＡＫＥ手続きによりコンテンツ移動専用の鍵の交換を行なう、
請求項３に記載のコンテンツ伝送システム。
【請求項１４】
前記認証手段は、前記コンテンツ伝送終了処理手段によるコンテンツ伝送終了処理が終了したことに応答して、Ｓｏｕｒｃｅ及びＳｉｎｋにおけるコンテンツ移動専用の交換鍵を消滅させる、
請求項１３に記載のコンテンツ伝送システム。
【請求項１５】
Ｓｏｕｒｃｅは、Ｓｉｎｋに対してコンテンツを移動中、他のＳｉｎｋからの当該コンテンツの移動要求を拒否する、
請求項１に記載のコンテンツ伝送システム。
【請求項１６】
Ｓｉｎｋは、Ｓｏｕｒｃｅから移動中でまだ有効化されていないコンテンツを再生する手段を備える、
請求項１に記載のコンテンツ伝送システム。
【請求項１７】
前記コンテンツ伝送手段によるコンテンツ伝送処理が終了するまでの間、ＳｉｎｋとＳｏｕｒｃｅ間の通信が途切れたときに、Ｓｉｎｋ又はＳｏｕｒｃｅの少なくとも一方からの要求によりコンテンツ伝送処理を中止するコンテンツ伝送処理中止手段をさらに備える、
請求項１に記載のコンテンツ伝送システム。
【請求項１８】
前記コンテンツ伝送終了処理手段は、
ＳｉｎｋからＳｏｕｒｃｅに対してコンテンツ受信終了を示す第１のコマンドが送信されたことに応答して、Ｓｏｕｒｃｅ側の元のコンテンツを中間的な無効状態にし、
ＳｏｕｒｃｅからＳｉｎｋに第１のコマンドに対する第１のレスポンスが返信されたことに応答してＳｉｎｋ側に伝送されたコンテンツを有効化するとともに、Ｓｉｎｋ側で保持するコンテンツ移動専用の鍵乃至第１のコマンドで送る情報を消滅させ、
ＳｉｎｋからＳｏｕｒｃｅに対してコンテンツ有効化を示す第２のコマンドが送信されたことに応答して、Ｓｏｕｒｃｅ側の元のコンテンツを無効状態にするとともに、Ｓｏｕｒｃｅ側で保持するコンテンツ移動専用の鍵乃至第１のレスポンスで送る情報を消滅させる、
請求項１に記載のコンテンツ伝送システム。
【請求項１９】
前記コンテンツ伝送手段によるＳｏｕｒｃｅからＳｉｎｋへのコンテンツ伝送が成功裏に終了したにも拘らず、前記コンテンツ伝送終了処理手段による処理が途切れてしまった場合に、コンテンツ伝送終了処理を再開するためのコンテンツ伝送終了処理再開手段をさらに備える、
請求項１８に記載のコンテンツ伝送システム。
【請求項２０】
前記コンテンツ伝送終了処理再開手段は、ＳｏｕｒｃｅがＳｉｎｋからコンテンツ受信終了を示す第１のコマンドを受信したときに、Ｓｏｕｒｃｅがコンテンツ移動専用の交換鍵乃至第１のレスポンスで送る情報をまだ保持している場合には、Ｓｏｕｒｃｅ側の元のコンテンツを中間的な無効状態にし、ＳｏｕｒｃｅからＳｉｎｋに第１のコマンドに対する第１のレスポンスを返信させる、
請求項１９に記載のコンテンツ伝送システム。
【請求項２１】
前記コンテンツ伝送終了処理再開手段は、ＳｏｕｒｃｅがＳｉｎｋからコンテンツ受信終了を示す第２のコマンドを受信したときに、Ｓｏｕｒｃｅがコンテンツ移動専用の交換鍵乃至第１のレスポンスで送る情報をまだ保持している場合には、Ｓｏｕｒｃｅ側の元のコンテンツを無効状態にし、Ｓｏｕｒｃｅ側で保持するコンテンツ移動専用の鍵乃至第１のレスポンスで送る情報を消滅させるとともに、ＳｏｕｒｃｅからＳｉｎｋに第２のコマンドに対する第２のレスポンスを返信させる、
請求項１９に記載のコンテンツ伝送システム。
【請求項２２】
前記コンテンツ伝送終了処理再開手段は、Ｓｉｎｋがコンテンツ移動専用の交換鍵乃至第１のコマンドで送る情報をまだ保持している場合には、コンテンツ移動元となるＳｏｕｒｃｅとの接続を確立し、該当するコンテンツがＳｉｎｋ側で無効状態であればＳｏｕｒｃｅに第１のコマンドを送信させ、該当するコンテンツがＳｉｎｋ側で既に有効化されていれば第２のコマンドを送信させる、
請求項１９に記載のコンテンツ伝送システム。
【請求項２３】
前記コンテンツ伝送終了処理再開手段は、再開処理を行なうためのＳｉｎｋ及びＳｏｕｒｃｅ間のコネクションを確立する手段を備える、
請求項１９に記載のコンテンツ伝送システム。
【請求項２４】
前記コンテンツ伝送終了処理再開手段は、ダウンロード形式で行なわれたコンテンツ伝送の終了処理を再開する際に、Ｓｉｎｋにおいて、ＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｑｕｅｓｔに対するＳｏｕｒｃｅからのＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｓｐｏｎｓｅに含まれる情報に基づいて認証及び鍵交換用のソケット情報を取得して、Ｓｏｕｒｃｅとのコネクションを確立する、
請求項２３に記載のコンテンツ伝送システム。
【請求項２５】
前記コンテンツ伝送終了処理再開手段は、アップロード形式で行なわれたコンテンツ伝送の終了処理を再開する際に、Ｓｏｕｒｃｅにおいて、（コンテンツを含まない）ＨＴＴＰ ＰＯＳＴメソッドを用いてＳｉｎｋに認証及び鍵交換用のソケット情報を通知し、Ｓｉｎｋが該ソケット情報に基づいてＳｏｕｒｃｅとのコネクションを確立する、
請求項２３に記載のコンテンツ伝送システム。
【請求項２６】
前記認証手段によりＳｏｕｒｃｅとＳｉｎｋ間で確認されたＭＯＶＥ伝送の詐称を防止する詐称防止手段をさらに備える、
請求項１に記載のコンテンツ伝送システム。
【請求項２７】
前記詐称防止手段は、コンテンツ伝送方法毎に前記認証手段で交換した鍵からコンテンツ暗号鍵を生成する方法を変える、
請求項２６に記載のコンテンツ伝送システム。
【請求項２８】
前記詐称防止手段は、コンテンツ伝送方法毎に前記認証手段で交換した鍵をスクランブルする方法を変える、
請求項２６に記載のコンテンツ伝送システム。
【請求項２９】
前記詐称防止手段は、相互認証及び鍵交換のためのチャレンジ・レスポンス手続きにおいて、ＳｉｎｋからＳｏｕｒｃｅへの通信メッセージの中にコンテンツ伝送方法に関する情報を含める、
請求項２６に記載のコンテンツ伝送システム。
【請求項３０】
ＤＴＣＰに従ってコンテンツを送信するＳｏｕｒｃｅとして動作するコンテンツ伝送装置であって、
Ｓｉｎｋとの間で伝送対象となるコンテンツを指定するコンテンツ指定手段と、
ＡＫＥ手続きによりＳｉｎｋとの間で相互認証及び鍵交換を行なう認証手段と、
前記認証手段により交換した鍵を用いて、前記コンテンツ指定手段により指定されたコンテンツを、Ｓｉｎｋへ暗号化伝送するコンテンツ伝送手段と、
コンテンツ伝送処理が終了するまではＳｉｎｋ側のコンテンツを無効化した状態に保ち、前記コンテンツ伝送手段によりコンテンツ伝送処理が終了したことに応じて、元のコンテンツを無効化するコンテンツ伝送終了処理手段と、
前記コンテンツ伝送手段によるコンテンツ伝送処理が終了するまでの間、コンテンツ伝送処理を取り消すコンテンツ伝送処理取り消し手段と、
を備え、
前記認証手段は、コンテンツ伝送終了処理手段によるコンテンツ伝送終了処理が終了するまでの間、認証及び鍵交換用のＴＣＰコネクションを保持し、
前記コンテンツ伝送処理取り消し手段は、前記認証及び鍵交換用のＴＣＰコネクションを用いてコンテンツ伝送処理を取り消す、
コンテンツ伝送装置。
【請求項３１】
前記コンテンツ伝送処理取り消し手段は、コンテンツ伝送処理を取り消す際に、Ｓｉｎｋに伝送されたコンテンツを削除する、
請求項３０に記載のコンテンツ伝送装置。
【請求項３２】
前記認証手段は、相互認証及び鍵交換に併せて、Ｓｉｎｋがコンテンツ伝送終了処理手段に対応しているかどうかケイパビリティを確認する、
請求項３０に記載のコンテンツ伝送装置。
【請求項３３】
コンテンツを提供するサーバとして動作し、Ｓｉｎｋ側からのユーザ操作に応じてコンテンツをＳｉｎｋへダウンロードする際に、
前記コンテンツ指定手段は、ＳｉｎｋからのＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｑｕｅｓｔに応答して、各コンテンツの認証及び鍵交換用のソケット情報と当該コンテンツがＳｏｕｒｃｅから移動可能か否かを記載したＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｓｐｏｎｓｅを返信し、
前記コンテンツ伝送手段は、Ｓｉｎｋからの、ヘッダ内にコンテンツの移動であることを示すヘッダ情報を含んだＨＴＴＰ ＧＥＴメソッドに応じて暗号化コンテンツを伝送する、
請求項３０に記載のコンテンツ伝送装置。
【請求項３４】
コンテンツを提供するサーバとして動作するＳｉｎｋに対して、ユーザの操作に応じてコンテンツをアップロードする際に、
前記コンテンツ指定手段は、Ｓｉｎｋに対して、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｑｕｅｓｔを用いて当該コンテンツの移動場所の作成を要求するとともに、該要求に対するＳｉｎｋからの応答によりコンテンツの移動場所のＵＲＩを受け取り、
前記コンテンツ伝送手段は、ヘッダ内にコンテンツの移動であることを示すヘッダ情報を含めて、該受け取ったコンテンツの移動場所のＵＲＩに対してＨＴＴＰ ＰＯＳＴメソッドを用いてＳｉｎｋへ暗号化コンテンツを送信する、
請求項３０に記載のコンテンツ伝送装置。
【請求項３５】
前記コンテンツ指定手段は、Ｓｉｎｋに対し、ＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｑｕｅｓｔを用いて認証及び鍵交換用のソケット情報を通知し、
前記認証手段は、該ソケット情報に基づいてＳｉｎｋ側から認証及び鍵交換用のＴＣＰコネクションを確立する、
請求項３４に記載のコンテンツ伝送装置。
【請求項３６】
前記コンテンツ指定手段は、Ｓｉｎｋに対し、ＣＤＳ：：Ｃｒｅａｔｅ Ｏｂｊｅｃｔ ｒｅｑｕｅｓｔの応答で受け取ったコンテンツ移動先のＵＲＩに対して（コンテンツを含まない）ＨＴＴＰ ＰＯＳＴメソッドのヘッダ情報を用いて認証及び鍵交換用のソケット情報を通知し、
前記認証手段は、該ソケット情報に基づいてＳｉｎｋ側から認証及び鍵交換用のＴＣＰコネクションをＳｉｎｋ側から確立させる、
請求項３４に記載のコンテンツ伝送装置。
【請求項３７】
前記認証手段は、Ｓｉｎｋへ移動するコンテンツ毎にＡＫＥ手続きによりコンテンツ移動専用の鍵の交換を行なう、
請求項３０に記載のコンテンツ伝送装置。
【請求項３８】
前記認証手段は、前記コンテンツ伝送手段によるコンテンツの伝送が終了したことに応答して、コンテンツ移動専用の鍵を消滅させる、
請求項３０に記載のコンテンツ伝送装置。
【請求項３９】
前記コンテンツ伝送手段は、Ｓｉｎｋに対してコンテンツを移動中、他のＳｉｎｋからの当該コンテンツの移動要求を拒否する、
請求項３０に記載のコンテンツ伝送装置。
【請求項４０】
前記認証手段は、コンテンツ伝送手段によるコンテンツ伝送処理が終了するまでの間、認証及び鍵交換用のＴＣＰコネクションを保持し、
前記コンテンツ伝送手段によるコンテンツ伝送処理が終了するまでの間、認証及び鍵交換用のＴＣＰコネクションを用いてコンテンツ伝送処理を取り消すコンテンツ伝送処理取り消し手段をさらに備える、
請求項３０に記載のコンテンツ伝送装置。
【請求項４１】
前記コンテンツ伝送手段によるコンテンツ伝送処理が終了するまでの間、Ｓｉｎｋとの通信が途切れたときに、コンテンツ伝送処理を中止するコンテンツ伝送処理中止手段をさらに備える、
請求項３０に記載のコンテンツ伝送装置。
【請求項４２】
前記コンテンツ伝送終了処理手段は、
Ｓｉｎｋからコンテンツ受信終了を示す第１のコマンドが受信したことに応答して元のコンテンツを中間的な無効状態にするとともに第１のコマンドに対する第１のレスポンスを返信し、
Ｓｉｎｋからコンテンツ有効化を示す第２のコマンドが受信したことに応答して、Ｓｏｕｒｃｅ側の元のコンテンツを無効状態にする、
請求項３０に記載のコンテンツ伝送装置。
【請求項４３】
前記コンテンツ伝送手段によるＳｉｎｋへのコンテンツ伝送が成功裏に終了したにも拘らず、前記コンテンツ伝送終了処理手段による処理が途切れてしまった場合に、コンテンツ伝送終了処理を再開するためのコンテンツ伝送終了処理再開手段をさらに備える、
請求項４２に記載のコンテンツ伝送装置。
【請求項４４】
前記コンテンツ伝送終了処理再開手段は、Ｓｉｎｋからコンテンツ受信終了を示す第１のコマンドを受信したときに、前記認証手段がコンテンツ移動専用の交換鍵乃至第１のレスポンスで送る情報をまだ保持している場合には、元のコンテンツを中間的な無効状態にするとともに、Ｓｉｎｋに第１のコマンドに対する第１のレスポンスが返信する、
請求項４３に記載のコンテンツ伝送装置。
【請求項４５】
前記コンテンツ伝送終了処理再開手段は、Ｓｉｎｋからコンテンツ受信終了を示す第２のコマンドを受信したときに、前記認証手段がコンテンツ移動専用の交換鍵乃至第１のレスポンスで送る情報をまだ保持している場合には、元のコンテンツを無効状態にし、前記認証手段が保持するコンテンツ移動専用の鍵を消滅させるとともに、Ｓｉｎｋに第２のコマンドに対する第２のレスポンスが返信する、
請求項４３に記載のコンテンツ伝送装置。
【請求項４６】
前記コンテンツ伝送終了処理再開手段は、再開処理を行なうためのＳｉｎｋとのコネクションを確立する手段を備える、
請求項４３に記載のコンテンツ伝送装置。
【請求項４７】
前記コンテンツ伝送終了処理再開手段は、ダウンロード形式で行なわれたコンテンツ伝送の終了処理を再開する際に、ＳｉｎｋからのＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｑｕｅｓｔに対して認証及び鍵交換用のソケット情報を含んだＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｓｐｏｎｓｅを返信して、Ｓｉｎｋとのコネクションを確立する、
請求項４６に記載のコンテンツ伝送装置。
【請求項４８】
前記コンテンツ伝送終了処理再開手段は、アップロード形式で行なわれたコンテンツ伝送の終了処理を再開する際に、ＨＴＴＰ ＰＯＳＴメソッドを用いてＳｉｎｋに認証及び鍵交換用のソケット情報を通知して、Ｓｉｎｋとのコネクションを確立する、
請求項４６に記載のコンテンツ伝送装置。
【請求項４９】
前記認証手段によりＳｉｎｋとの間で確認されたＭＯＶＥ伝送の詐称を防止する詐称防止手段をさらに備える、
請求項３０に記載のコンテンツ伝送装置。
【請求項５０】
前記詐称防止手段は、ケイパビリティに対応したコンテンツ伝送方法毎に前記認証手段で交換した鍵からコンテンツ暗号鍵を生成する方法を変える、
請求項４９に記載のコンテンツ伝送装置。
【請求項５１】
前記詐称防止手段は、コンテンツ伝送方法毎に前記認証手段で交換した鍵をスクランブルする方法を変える、
請求項４９に記載のコンテンツ伝送装置。
【請求項５２】
ＤＴＣＰに従ってコンテンツを受信するＳｉｎｋとして動作するコンテンツ伝送装置であって、
Ｓｏｕｒｃｅとの間で伝送対象となるコンテンツを指定するコンテンツ指定手段と、
ＡＫＥ手続きによりＳｏｕｒｃｅとの間で相互認証及び鍵交換を行なう認証手段と、
前記認証手段により交換した鍵を用いて、前記コンテンツ指定手段により指定されたコンテンツを、Ｓｏｕｒｃｅから暗号化伝送するコンテンツ伝送手段と、
コンテンツ伝送処理が終了するまではコンテンツを無効化した状態に保ち、前記コンテンツ伝送手段によりコンテンツ伝送処理が終了したことに応じて、受信したコンテンツを有効化するコンテンツ伝送終了処理手段と、
前記コンテンツ伝送手段によるコンテンツ伝送処理が終了するまでの間、認コンテンツ伝送処理を取り消すコンテンツ伝送処理取り消し手段と、
を備え、
前記認証手段は、コンテンツ伝送終了処理手段によるコンテンツ伝送終了処理が終了するまでの間、認証及び鍵交換用のＴＣＰコネクションを保持し、
前記コンテンツ伝送処理取り消し手段は、前記認証及び鍵交換用のＴＣＰコネクションを用いてコンテンツ伝送処理を取り消す、
コンテンツ伝送装置。
【請求項５３】
前記認証手段は、相互認証及び鍵交換に併せて、Ｓｉｎｋがコンテンツ伝送終了処理手段に対応しているかどうかケイパビリティを確認する、
請求項５２に記載のコンテンツ伝送装置。
【請求項５４】
コンテンツを提供するサーバとして動作するＳｏｕｒｃｅから、ユーザ操作に応じてコンテンツをダウンロードする際に、
前記コンテンツ指定手段は、ＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｑｕｅｓｔを送信し、ＳｏｕｒｃｅからのＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｓｐｏｎｓｅに含まれる情報に基づいて、移動したいコンテンツの認証及び鍵交換用のソケット情報を取得するとともに当該コンテンツがＳｏｕｒｃｅから移動可能か否かを確認し、
前記コンテンツ伝送手段は、ヘッダ内にコンテンツの移動であることを示すヘッダ情報を含めて、ＨＴＴＰ ＧＥＴメソッドを用いてＳｏｕｒｃｅから暗号化コンテンツを取得する、
請求項５２に記載のコンテンツ伝送装置。
【請求項５５】
コンテンツを提供するサーバとして動作し、Ｓｏｕｒｃｅ側からのユーザの操作に応じてコンテンツをアップロードする際に、
前記コンテンツ指定手段は、Ｓｏｕｒｃｅから受信したＣＤＳ：：ＣｒｅａｔｅＯｂｊｅｃｔ ｒｅｑｕｅｓｔに基づいて当該コンテンツの移動場所を作成し、
前記コンテンツ伝送手段は、Ｓｏｕｒｃｅからの、ヘッダ内にコンテンツの移動であることを示すヘッダ情報を含んだＨＴＴＰ ＰＯＳＴメソッドにより暗号化コンテンツを受信する、
請求項５２に記載のコンテンツ伝送装置。
【請求項５６】
前記認証手段は、前記コンテンツ伝送手段によるコンテンツの伝送が終了したことに応答して、コンテンツ移動専用の鍵の交換を消滅させる、
請求項５２に記載のコンテンツ伝送装置。
【請求項５７】
Ｓｏｕｒｃｅから移動中でまだ有効化されていないコンテンツを再生する手段をさらに備える、
請求項５２に記載のコンテンツ伝送装置。
【請求項５８】
前記コンテンツ伝送手段によるコンテンツ伝送処理が終了するまでの間、認証及び鍵交換用のＴＣＰコネクションを用いてコンテンツ伝送処理を取り消すコンテンツ伝送処理取り消し手段をさらに備える、
請求項５２に記載のコンテンツ伝送装置。
【請求項５９】
前記コンテンツ伝送処理取り消し手段は、コンテンツ伝送処理を取り消す際に、Ｓｏｕｒｃｅから伝送されたコンテンツを無効化する、
請求項５８に記載のコンテンツ伝送装置。
【請求項６０】
前記コンテンツ伝送手段によるコンテンツ伝送処理が終了するまでの間、Ｓｏｕｒｃｅとの通信が途切れたときに、コンテンツ伝送処理を中止するコンテンツ伝送処理中止手段をさらに備える、
請求項５２に記載のコンテンツ伝送装置。
【請求項６１】
前記コンテンツ伝送終了処理手段は、Ｓｏｕｒｃｅに対してコンテンツ受信終了を示す第１のコマンドを送信し、ＳｏｕｒｃｅからＳｉｎｋに第１のコマンドに対する第１のレスポンスが返信されたことに応答して伝送されたコンテンツを有効化するとともに、前記認証手段が保持するコンテンツ移動専用の鍵乃至第１のコマンドで送る情報を消滅させる、
請求項５２に記載のコンテンツ伝送装置。
【請求項６２】
前記コンテンツ伝送手段によるＳｏｕｒｃｅとのコンテンツ伝送が成功裏に終了したにも拘らず、前記コンテンツ伝送終了処理手段による処理が途切れてしまった場合に、コンテンツ伝送終了処理を再開するためのコンテンツ伝送終了処理再開手段をさらに備える、
請求項６１に記載のコンテンツ伝送装置。
【請求項６３】
前記コンテンツ伝送終了処理再開手段は、前記認証手段がコンテンツ移動専用の交換鍵乃至第１のコマンドで送る情報をまだ保持している場合には、Ｓｏｕｒｃｅとの接続を確立し、該当するコンテンツが無効状態であればＳｏｕｒｃｅに第１のコマンドを送信し、該当するコンテンツがＳｉｎｋ側で既に有効化されていれば第２のコマンドを送信する、
請求項６２に記載のコンテンツ伝送装置。
【請求項６４】
前記コンテンツ伝送終了処理再開手段は、再開処理を行なうためのＳｏｕｒｃｅとのコネクションを確立する手段を備える、
請求項６２に記載のコンテンツ伝送装置。
【請求項６５】
前記コンテンツ伝送終了処理再開手段は、ダウンロード形式で行なわれたコンテンツ伝送の終了処理を再開する際に、ＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｑｕｅｓｔに対するＳｏｕｒｃｅからのＣＤＳ：：Ｂｒｏｗｓｅ ｒｅｓｐｏｎｓｅに含まれる情報に基づいて認証及び鍵交換用のソケット情報を取得して、Ｓｏｕｒｃｅとのコネクションを確立する、
請求項６４に記載のコンテンツ伝送装置。
【請求項６６】
前記コンテンツ伝送終了処理再開手段は、アップロード形式で行なわれたコンテンツ伝送の終了処理を再開する際に、Ｓｏｕｒｃｅからの（コンテンツを含まない）ＨＴＴＰ ＰＯＳＴメソッドを用いて通知された認証及び鍵交換用のソケット情報に基づいてＳｏｕｒｃｅとのコネクションを確立する、
請求項６４に記載のコンテンツ伝送装置。
【請求項６７】
前記認証手段によりＳｏｕｒｃｅとの間で確認されたＭＯＶＥ伝送の詐称を防止する詐称防止手段をさらに備える、
請求項５２に記載のコンテンツ伝送装置。
【請求項６８】
前記詐称防止手段は、相互認証及び鍵交換のためのチャレンジ・レスポンス手続きにおいて、Ｓｏｕｒｃｅへの通信メッセージの中にコンテンツ伝送方法に関する情報を含める、
請求項６７に記載のコンテンツ伝送装置。
【請求項６９】
ＤＴＣＰ Ｓｏｕｒｃｅとしてコンテンツを送信するコンテンツ伝送方法であって、
Ｓｉｎｋとの間で伝送対象となるコンテンツを指定するコンテンツ指定ステップと、
ＡＫＥ手続きによりＳｉｎｋとの間で相互認証及び鍵交換を行なう認証ステップと、
前記認証ステップにおいて交換した鍵を用いて、前記コンテンツ指定ステップにおいて指定されたコンテンツを、Ｓｉｎｋへ暗号化伝送するコンテンツ伝送ステップと、
コンテンツ伝送処理が終了するまではＳｉｎｋ側のコンテンツを無効化した状態に保ち、前記コンテンツ伝送ステップにおいてコンテンツ伝送処理が終了したことに応じて、元のコンテンツを無効化するコンテンツ伝送終了処理ステップと、
前記コンテンツ伝送ステップにおけるコンテンツ伝送処理が終了するまでの間、コンテンツ伝送処理を取り消すコンテンツ伝送処理取り消しステップと、
を有し、
前記認証ステップでは、コンテンツ伝送終了処理ステップにおけるコンテンツ伝送終了処理が終了するまでの間、認証及び鍵交換用のＴＣＰコネクションを保持し、
前記コンテンツ伝送処理取り消しステップでは、前記認証及び鍵交換用のＴＣＰコネクションを用いてコンテンツ伝送処理を取り消す、
コンテンツ伝送方法。
【請求項７０】
ＤＴＣＰ Ｓｉｎｋとしてコンテンツを受信するコンテンツ伝送方法であって、
Ｓｏｕｒｃｅとの間で伝送対象となるコンテンツを指定するコンテンツ指定ステップと、
ＡＫＥ手続きによりＳｏｕｒｃｅとの間で相互認証及び鍵交換を行なう認証ステップと、
前記認証ステップにおいて交換した鍵を用いて、前記コンテンツ指定ステップにおいて指定されたコンテンツを、Ｓｏｕｒｃｅから暗号化伝送するコンテンツ伝送ステップと、
コンテンツ伝送処理が終了するまではコンテンツを無効化した状態に保ち、前記コンテンツ伝送ステップにおいてコンテンツ伝送処理が終了したことに応じて、受信したコンテンツを有効化するコンテンツ伝送終了処理ステップと、
前記コンテンツ伝送ステップにおけるコンテンツ伝送処理が終了するまでの間、コンテンツ伝送処理を取り消すコンテンツ伝送処理取り消しステップと、
を有し、
前記認証ステップでは、コンテンツ伝送終了処理ステップにおけるコンテンツ伝送終了処理が終了するまでの間、認証及び鍵交換用のＴＣＰコネクションを保持し、
前記コンテンツ伝送処理取り消しステップでは、前記認証及び鍵交換用のＴＣＰコネクションを用いてコンテンツ伝送処理を取り消す、
コンテンツ伝送方法。
【請求項７１】
ＤＴＣＰ Ｓｏｕｒｃｅとしてコンテンツを送信するための処理をコンピュータ上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータを、
Ｓｉｎｋとの間で伝送対象となるコンテンツを指定するコンテンツ指定手段、
ＡＫＥ手続きによりＳｉｎｋとの間で相互認証及び鍵交換を行なう認証手段、
前記認証手段により交換した鍵を用いて、前記コンテンツ指定手段により指定されたコンテンツを、Ｓｉｎｋへ暗号化伝送するコンテンツ伝送手段、
コンテンツ伝送処理が終了するまでははＳｉｎｋ側のコンテンツを無効化した状態に保ち、前記コンテンツ伝送手段によりコンテンツ伝送処理が終了したことに応じて、元のコンテンツを無効化するコンテンツ伝送終了処理手段、
前記コンテンツ伝送手段によるコンテンツ伝送処理が終了するまでの間、コンテンツ伝送処理を取り消すコンテンツ伝送処理取り消し手段、
として機能させ、
前記認証手段は、コンテンツ伝送終了処理手段によるコンテンツ伝送終了処理が終了するまでの間、認証及び鍵交換用のＴＣＰコネクションを保持し、
前記コンテンツ伝送処理取り消し手段は、前記認証及び鍵交換用のＴＣＰコネクションを用いてコンテンツ伝送処理を取り消す、
コンピュータ・プログラム。
【請求項７２】
ＤＴＣＰ Ｓｉｎｋとしてコンテンツを受信するための処理をコンピュータ上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータを、
Ｓｏｕｒｃｅとの間で伝送対象となるコンテンツを指定するコンテンツ指定手段、
ＡＫＥ手続きによりＳｏｕｒｃｅとの間で相互認証及び鍵交換を行なう認証手段、
前記認証手段により交換した鍵を用いて、前記コンテンツ指定手段により指定されたコンテンツを、Ｓｏｕｒｃｅから暗号化伝送するコンテンツ伝送手段、
コンテンツ伝送処理が終了するまではコンテンツを無効化した状態に保ち、前記コンテンツ伝送手段によりコンテンツ伝送処理が終了したことに応じて、受信したコンテンツを有効化するコンテンツ伝送終了処理手段、
前記コンテンツ伝送手段によるコンテンツ伝送処理が終了するまでの間、てコンテンツ伝送処理を取り消すコンテンツ伝送処理取り消し手段、
として機能させ、
前記認証手段は、コンテンツ伝送終了処理手段によるコンテンツ伝送終了処理が終了するまでの間、認証及び鍵交換用のＴＣＰコネクションを保持し、
前記コンテンツ伝送処理取り消し手段は、前記認証及び鍵交換用のＴＣＰコネクションを用いてコンテンツ伝送処理を取り消す、
コンピュータ・プログラム。
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４Ａ】
【図１４Ｂ】
【図１５Ａ】
【図１５Ｂ】
【図１６】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２Ａ】
【図３２Ｂ】
【図３３】
【図１】
【図１７】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４Ａ】
【図１４Ｂ】
【図１５Ａ】
【図１５Ｂ】
【図１６】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２Ａ】
【図３２Ｂ】
【図３３】
【図１】
【図１７】
【公開番号】特開２０１０−２３１７８７（Ｐ２０１０−２３１７８７Ａ）
【公開日】平成２２年１０月１４日（２０１０．１０．１４）
【国際特許分類】
【出願番号】特願２０１０−７６２８０（Ｐ２０１０−７６２８０）
【出願日】平成２２年３月２９日（２０１０．３．２９）
【分割の表示】特願２００６−２７１２４０（Ｐ２００６−２７１２４０）の分割
【原出願日】平成１８年１０月２日（２００６．１０．２）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
【公開日】平成２２年１０月１４日（２０１０．１０．１４）
【国際特許分類】
【出願日】平成２２年３月２９日（２０１０．３．２９）
【分割の表示】特願２００６−２７１２４０（Ｐ２００６−２７１２４０）の分割
【原出願日】平成１８年１０月２日（２００６．１０．２）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
[ Back to top ]