JP2018038041A - 通信システム及び通信方法 - Google Patents

Abstract

【課題】ＲＴＴやＴＴＬの制限を超えつつ、ＷＡＮなどの外部ネットワークを経由したリモート・アクセスを通じてコンテンツを安全に伝送する。
【解決手段】ＲＡ−ＡＫＥではＲＴＴ並びにＴＴＬの制限を外し、ＲＡ−ＳｏｕｒｃｅとＲＡ−Ｓｉｎｋ間でリモート・アクセス用の鍵共有を実現する。但し、ＲＡ−Ｓｉｎｋの事前登録、利用数制限、鍵供給数制限を課して、不特定多数のユーザーからのリモート・アクセスを制限する。また、ＲＡ−Ｓｏｕｒｃｅは、コンテンツが「リモート・アクセス出力可能」という情報を伴わない限り、リモート・アクセス出力を行なわないようする。
【選択図】 図１

Description

本発明は、コンテンツの伝送における不正利用を防止する通信システム、通信装置及び通信方法、並びにコンピューター・プログラムに係り、特に、暗号化コンテンツを伝送するとともに、暗号化コンテンツの復号鍵を所定の相互認証及び鍵交換（ＡＫＥ）アルゴリズムに従って交換する通信システム、通信装置及び通信方法、並びにコンピューター・プログラムに関する。

さらに詳しくは、本発明は、ＷＡＮなどの外部ネットワークを経由したリモート・アクセス（ＲＡ）を通じてコンテンツを安全に伝送する通信システム、往復遅延時間（ＲＴＴ）やＩＰルーターのホップ回数（ＴＴＬ）などの制限を超えつつ、リモート・アクセスを通じてコンテンツを安全に伝送する通信装置及び通信方法、並びにコンピューター・プログラムに係り、特に、通信システム、通信装置及び通信方法、並びにコンピューター・プログラムに関する。

従来、放送コンテンツやパッケージ・メディア中のコンテンツは、受信機器や再生機器が設置された場所、又は、これらの機器とホームネットワーク経由で接続された機器で利用すること（以下、「ローカル・アクセス（ＬＡ）」とも呼ぶ）が基本であった。例えば、屋外から携帯機器で上記の受信機器や再生機器と接続し、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）などの外部ネットワーク経由の伝送を伴ってコンテンツを利用すること（以下、「リモート・アクセス（ＲＡ）」とも呼ぶ）は、通信路やコーデックなどの技術的な観点から困難であった。しかし、将来的には、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）やＷｉＭＡＸ（Ｗｏｒｌｄ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ）といったデータ通信技術、並びに、Ｈ．２６４などの高圧縮コーデックの普及が見込まれ、これらを活用することでリモート・アクセスの実現可能性が見えてくる。例えば、ユーザーが出先から自宅のサーバーにリモート・アクセスして、コンテンツを再生するという使い方である。

他方、ディジタル化されたコンテンツはコピーや改竄などの不正な操作が比較的容易である。とりわけ、リモート・アクセスにおいては、個人的又は家庭的なコンテンツの使用を許容しながら、コンテンツ伝送に介在する不正利用の防止、すなわち著作権保護の仕組みが必要である。

ディジタル・コンテンツの伝送保護に関する業界標準的な技術として、ＤＴＬＡ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｌｉｃｅｎｓｉｎｇ Ａｄｍｉｎｉｓｔｒａｔｏｒ）が開発したＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）が挙げられる。ＤＴＣＰでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決められている。その規定は、要約すれば、ＤＴＣＰ準拠機器は取り扱いが容易な圧縮コンテンツを非暗号の状態で機器外に送出しないことと、暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ：ＡＫＥ）アルゴリズムに従って行なうこと、並びにＡＫＥコマンドにより鍵交換を行なう機器の範囲を制限することなどである。コンテンツ提供元であるサーバ（Ｓｏｕｒｃｅ）とコンテンツ提供先であるクライアント（Ｓｉｎｋ）は、ＡＫＥコマンドの送受信により、認証手続きを経て鍵を共有化し、その鍵を用いて伝送路を暗号化してコンテンツの伝送を行なう。したがって、不正なクライアントは、サーバーとの認証に成功しないと暗号鍵を取得できないから、コンテンツを享受することはできない。

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

ＤＴＣＰ−ＩＰは、ＤＴＣＰ技術をＩＰネットワークに移植した同様の技術であり、伝送路にＩＰネットワークを使用すること、暗号化されたコンテンツの伝送にＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＲＴＰ（Ｒｅａｌ−Ｔｉｍｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）といった、ＩＰネットワーク上で実装されたコンテンツ伝送用プロトコルを使用する。例えば、ＨＴＴＰの手続きに従ってコンテンツを伝送する場合、ＳｏｕｒｃｅがＨＴＴＰサーバーとなり、ＳｉｎｋがＨＴＴＰクライアントとなって、ＨＴＴＰのためのＴＣＰ／ＩＰコネクションが作成され、暗号化コンテンツのダウンロード伝送が行なわれる（但し、アップロード伝送を行なうときには、ＳｏｕｒｃｅがＨＴＴＰクライアントとなりＳｉｎｋがＨＴＴＰサーバーとなる）。

現在のＤＴＣＰ−ＩＰ（ＤＴＣＰ Ｖｏｌｕｍｅ １ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｓｕｐｐｌｅｍｅｎｔ Ｅ Ｒｅｖｉｓｉｏｎ １．２）は、主にコンテンツの家庭内のみの利用を確保することを意図したものである。このため、ＡＫＥコマンドに対し往復遅延時間（ＲＴＴ：Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）は最大７ミリ秒に制限され、また、ＩＰルーターのホップ回数（ＴＴＬ：Ｔｉｍｅ Ｔｏ Ｌｉｖｅ）の上限が３に設定されている。

例えば、ＳｏｕｒｃｅがＤＴＣＰ−ＩＰ認証を開始してから終了する直前までの間、受信した各ＡＫＥコマンドを監視し続け、ＴＴＬ値の最大値を更新し続け、認証手続きが終了する直前にＴＴＬ値の最大値をチェックし、この最大値が３以下であれば鍵交換して認証手続きを完了するが、３を超えると、最終段階の処理を行なわずに認証手続きを終わらせる情報通信システムについて提案がなされている（例えば、特許文献１を参照のこと）。

しかしながら、ＲＴＴやＴＴＬの制限を課すと、家庭外の遠隔地から家庭内のホームネットワークのサーバーにある著作権保護されたコンテンツにアクセスすることはできない。

ユーザーの利便性を考えると、コンテンツへのリモート・アクセスを許容したいが、著作権保護したいというコンテンツ・オーナーの利益とは相反する。

特開２００７−３６３５１号公報

本発明の目的は、暗号化コンテンツの復号鍵を所定の相互認証及び鍵交換（ＡＫＥ）アルゴリズムに従って交換して、コンテンツの伝送における不正利用を好適に防止することができる、優れた通信システム、通信装置及び通信方法、並びにコンピューター・プログラムを提供することにある。

本発明のさらなる目的は、往復遅延時間（ＲＴＴ）やＩＰルーターのホップ回数（ＴＴＬ）などの制限を超えつつ、ＷＡＮなどの外部ネットワークを経由したリモート・アクセスを通じてコンテンツを安全に伝送することができる、優れた通信システム、通信装置及び通信方法、並びにコンピューター・プログラムを提供することにある。

本願は、上記課題を参酌してなされたものであり、その第１の側面に係る発明は、コンテンツを提供するコンテンツ提供装置とコンテンツを利用する１以上のコンテンツ利用装置でコンテンツ伝送のための通信を行なう通信システムであって、
コマンドの往復遅延時間に関する制限を課した第１の相互認証手続きを経て、コンテンツを要求するコンテンツ利用装置を前記コンテンツ提供装置に登録する登録手段と、
コマンドの往復遅延時間に関する制限を課さない第２の相互認証手続きを経て、前記コンテンツ提供装置から前記登録手段により登録された前記コンテンツ利用装置へ、要求されたコンテンツを伝送する伝送手段と、
を具備する通信システムである。

但し、ここで言う「システム」とは、複数の装置（又は特定の機能を実現する機能モジュール）が論理的に集合した物のことを言い、各装置や機能モジュールが単一の筐体内にあるか否かは特に問わない。

本願の第２の側面に係る発明は、
コンテンツを要求するコンテンツ利用装置を、コマンドの往復遅延時間に関する制限を課した第１の相互認証手続きを経て登録する登録手段と、
コマンドの往復遅延時間に関する制限を課さない第２の相互認証手続きを経て、前記登録手段により登録された前記コンテンツ利用装置へ、要求されたコンテンツを伝送する伝送手段と、
を具備する通信装置である。

本願の第３の側面に係る発明によれば、第２の側面に係る通信装置の登録手段は、前記第１の相互認証手続きに際し、ＩＰルーターのホップ回数に関する制限をさらに課すが、他方の伝送手段は、前記第２の相互認証手続きに際し、ＩＰルーターのホップ回数に関する制限をも課さないように構成されている。

本願の第４の側面に係る発明によれば、第２の側面に係る通信装置の登録手段は、登録するコンテンツ利用装置の台数を制限するように構成されている。

本願の第５の側面に係る発明によれば、第２又は第４のいずれかの側面に係る通信装置の伝送手段は、前記登録手段に登録された正当なコンテンツ利用装置のうちコンテンツ伝送を許容する台数の上限を設定するように構成されている。

本願の第６の側面に係る発明によれば、第５の側面に係る通信装置の伝送手段は、第２の相互認証手続きを通じて前記コンテンツ利用装置の間で共有される交換鍵から生成される暗号鍵を用いてコンテンツを暗号化伝送し、その後、コンテンツ利用装置がアクセスを終了する際に発行する破棄要求に応じて、該当する交換鍵を破棄し、前記台数の上限のカウントを破棄した交換鍵の数に応じて減じるように構成されている。

本願の第７の側面に係る発明によれば、第２の側面に係る通信装置は、第２の相互認証手続きを経たコンテンツ伝送が可能であるコンテンツに所定の伝送可能情報が付加されているときには、伝送手段が、前記伝送可能情報が付加されていないコンテンツの伝送を禁止するが、前記伝送可能情報が付加されているコンテンツについては前記伝送可能情報を伴わずに伝送するように構成されている。

本願の第８の側面に係る発明によれば、第７の側面に係る通信装置は、コマンドの往復遅延時間に関する制限を課した第１の相互認証手続きを経て、伝送可能情報が付加されたままコンテンツを伝送する第２の伝送手段をさらに備えている。

本願の第９の側面に係る発明によれば、第８の側面に係る通信装置の第２の伝送手段は、第１の相互認証手続きを通じて１台のコンテンツ利用装置のみの間で共有される代行用の交換鍵から生成される暗号鍵を用いて前記伝送可能情報が付加されたままコンテンツを暗号化伝送し、このコンテンツ利用装置が代行終了時に発行する破棄要求に応じて代行用の交換鍵を破棄するように構成されており、同時に２以上の代行用の交換鍵を生成し２台以上のコンテンツ利用装置が代行することはない。

本願の第１０の側面に係る発明によれば、第１の側面に係る通信装置の伝送手段は、同じコンテンツを所定の台数以上のコンテンツ利用装置に同時に伝送しないように構成されている。

本願の第１１の側面に係る発明によれば、第１の側面に係る通信装置の伝送手段は、第２の相互認証手続きを通じて伝送するコンテンツを暗号化する暗号鍵の生成に用いる交換の鍵を、コンテンツの伝送先となるコンテンツ利用装置毎に変えるとともに、暗号化伝送するコンテンツをコンテンツ利用装置毎に管理して、同じコンテンツを所定の台数以上のコンテンツ利用装置に同時に伝送しないように構成されている。

本願の第１２の側面に係る発明によれば、第１の側面に係る通信装置は、提供するコンテンツを記録する記憶部を備え、伝送手段は、前記記憶部に記録してから所定時間が経過した後のコンテンツの伝送を許容するように構成されている。

本願の第１３の側面に係る発明は、
コンテンツを要求するコンテンツ利用装置を、コマンドの往復遅延時間に関する制限を課した第１の相互認証手続きを経て登録する登録ステップと、
コマンドの往復遅延時間に関する制限を課さない第２の相互認証手続きを経て、前記登録手段により登録された前記コンテンツ利用装置へ、要求されたコンテンツを伝送する伝送ステップと、
を有する通信方法である。

本願の第１４の側面に係る発明は、
コンテンツ要求先となるコンテンツ提供装置に対し、コマンドの往復遅延時間に関する制限を課した第１の相互認証手続きを経て登録手続きを行なう登録手続手段と、
コマンドの往復遅延時間に関する制限を課さない第２の相互認証手続きを経て、登録した後の前記コンテンツ提供装置に対し、コンテンツを要求するコンテンツ要求手段と、
を具備する通信装置である。

本願の第１５の側面に係る発明によれば、第１４の側面に係る通信装置において、登録手続手段による登録手続きでは、前記第１の相互認証手続きに際し、ＩＰルーターのホップ回数に関する制限がさらに課されるが、コンテンツ要求手段によるコンテンツ要求時では前記第２の相互認証手続きに際し、ＩＰルーターのホップ回数に関する制限をも課されない。

本願の第１６の側面に係る発明によれば、第１４の側面に係る通信装置のコンテンツ要求手段は、
前記第２の相互認証手続きを通じてコンテンツ提供装置との間で共有される交換鍵から生成される暗号鍵を用いて暗号化されたコンテンツを受信し、コンテンツ提供装置へのアクセス終了時に前記交換鍵の破棄要求を発行するように構成されている。

本願の第１７の側面に係る発明によれば、第２の相互認証手続きを経たコンテンツ伝送が可能であるコンテンツに所定の伝送可能情報が付加されており、第１４の側面に係る通信装置は、コマンドの往復遅延時間に関する制限を課した第１の相互認証手続きを経て、前記伝送可能情報が付加されたままのコンテンツを要求する第２のコンテンツ要求手段をさらに備えている。

本願の第１８の側面に係る発明によれば、第１７の側面に係る通信装置の第２のコンテンツ要求手段は、第１の相互認証手続きを通じてコンテンツ提供装置との間で共有される代行用の交換鍵から生成される暗号鍵を用いて暗号化された、前記伝送可能情報が付加されたコンテンツを受信して、コンテンツ提供装置を代行するとともに、コンテンツ提供装置の代行を終了するときに前記代行用の交換鍵の破棄要求を発行するように構成されている。

本願の第１９の側面に係る発明は、
コンテンツ要求先となるコンテンツ提供装置に対し、コマンドの往復遅延時間に関する制限を課した第１の相互認証手続きを経て登録手続きを行なう登録手続ステップと、
コマンドの往復遅延時間に関する制限を課さない第２の相互認証手続きを経て、登録した後の前記コンテンツ提供装置に対し、コンテンツを要求するコンテンツ要求ステップと、
を有する通信方法である。

本願の第２０の側面に係る発明は、ネットワーク経由でコンテンツを提供するための処理をコンピューター上で実行するようにコンピューター可読形式で記述されたコンピューター・プログラムであって、前記コンピューターを、
コンテンツを要求するコンテンツ利用装置を、コマンドの往復遅延時間に関する制限を課した第１の相互認証手続きを経て登録する登録手段、
コマンドの往復遅延時間に関する制限を課さない第２の相互認証手続きを経て、前記登録手段により登録された前記コンテンツ利用装置へ、要求されたコンテンツを伝送する伝送手段、
として機能させるためのコンピューター・プログラムである。

本願の第２１の側面に係る発明は、ネットワーク経由でコンテンツを要求するための処理をコンピューター上で実行するようにコンピューター可読形式で記述されたコンピューター・プログラムであって、前記コンピューターを、
コンテンツ要求先となるコンテンツ提供装置に対し、コマンドの往復遅延時間に関する制限を課した第１の相互認証手続きを経て登録手続きを行なう登録手続手段と、
コマンドの往復遅延時間に関する制限を課さない第２の相互認証手続きを経て、登録した後の前記コンテンツ提供装置に対し、コンテンツを要求するコンテンツ要求手段と、
として機能させるためのコンピューター・プログラムである。

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

本願の第２２の側面に係る発明は、
コマンドの往復遅延時間に関する制限を課した第１の相互認証手続きを記述した第１のプログラム、及び、コマンドの往復遅延時間に関する制限を課さない第２の相互認証手続きを記述した第２のプログラムを記憶するプログラム記憶部と、
前記プログラム記憶部から読み出したプログラムを実行するプログラム実行部と、
前記プログラム実行部が前記第１のプログラムを実行したことを経て、コンテンツを要求するコンテンツ利用装置を示すコンテンツ利用装置識別情報を記憶するコンテンツ利用装置記憶部と、
前記プログラム実行部が前記第２のプログラムを実行したことを経て、前記コンテンツ利用装置記憶部にコンテンツ利用装置識別情報が記憶されたコンテンツ利用装置に、要求されたコンテンツを送信する送信部と、
を具備する通信装置である。

本願の第２３の側面に係る発明によれば、第２２の側面に係る通信装置は、動画像を圧縮又は復号する動画像処理用補助演算装置をさらに備えている。

本願の第２４の側面に係る発明によれば、第２３の側面に係る通信装置の同画像処理用補助演算装置が処理する動画像は、ＭＰＥＧ２、Ｈ２６４、又は、ＶＣ１アルゴリズムを備えている。

本願の第２５の側面に係る発明によれば、第２２の側面に係る通信装置において、第１のプログラムで記述される第１の相互認証手続きは、ＩＰルーターのホップ回数に関する制限をさらに課す一方、前記第２のプログラムで記述される第２の相互認証手続きは、ＩＰルーターのホップ回数に関する制限をも課さないようにしてもよい。

本願の第２６の側面に係る発明によれば、第２２の側面に係る通信装置のコンテンツ利用装置記憶部は、コンテンツ利用装置識別情報を記憶するコンテンツ利用装置の台数を制限するように構成されている。

本願の第２７の側面に係る発明によれば、第２２又は２６のいずれかの側面に係る通信装置の送信部は、前記コンテンツ利用装置記憶部がコンテンツ利用装置識別情報を記憶するコンテンツ利用装置のうちコンテンツ伝送を許容する台数の上限を設定するように構成されている。

本願の第２８の側面に係る発明によれば、第２７の側面に係る通信装置の送信部は、前記第２の相互認証手続きを通じて前記コンテンツ利用装置の間で共有される交換鍵から生成される暗号鍵を用いてコンテンツを暗号化伝送し、前記コンテンツ利用装置がアクセス終了時に発行する破棄要求に応じて、該当する交換鍵を破棄し、前記台数の上限のカウントを破棄した交換鍵の数に応じて減じるように構成されている。

本願の第２９の側面に係る発明によれば、第２２の側面に係る通信装置において、第２の相互認証手続きを経たコンテンツ伝送が可能であるコンテンツには所定の伝送可能情報が付加されており、送信部は、前記伝送可能情報が付加されていないコンテンツの伝送を禁止し、前記伝送可能情報が付加されているコンテンツについては前記伝送可能情報を伴わずに伝送するように構成されている。

本願の第３０の側面に係る発明によれば、第２２の側面に係る通信装置は、コマンドの往復遅延時間に関する制限を課した第１の相互認証手続きを経て、前記伝送可能情報が付加されたままコンテンツを伝送する第２の送信部をさらに備えている。

本願の第３１の側面に係る発明によれば、第３０の側面に係る通信装置の第２の送信部は、前記第１の相互認証手続きを通じて１台のコンテンツ利用装置のみの間で共有される代行用の交換鍵から生成される暗号鍵を用いて前記伝送可能情報が付加されたままコンテンツを暗号化伝送し、前記１台のコンテンツ利用装置が代行終了時に発行する破棄要求に応じて、前記代行用の交換鍵を破棄するように構成されている。

本願の第３２の側面に係る発明によれば、第２２の側面に係る通信装置の送信部は、同じコンテンツを所定の台数以上のコンテンツ利用装置に同時に伝送しないように構成されている。

本願の第３３の側面に係る発明によれば、第２２の側面に係る通信装置の送信部は、前記第２の相互認証手続きを通じて伝送するコンテンツを暗号化する暗号鍵の生成に用いる交換の鍵を、コンテンツの伝送先となるコンテンツ利用装置毎に変えるとともに、暗号化伝送するコンテンツをコンテンツ利用装置毎に管理して、同じコンテンツを所定の台数以上のコンテンツ利用装置に同時に伝送しないように構成されている。

本願の第３４の側面に係る発明によれば、第２２の側面に係る通信装置は、提供するコンテンツを記録するコンテンツ記憶部を備え、記送信部は、前記コンテンツ記憶部に記録してから所定時間が経過した後のコンテンツの伝送を許容するように構成されている。

本発明によれば、往復遅延時間（ＲＴＴ）やＩＰルーターのホップ回数（ＴＴＬ）などの制限を超えつつ、ＷＡＮなどの外部ネットワークを経由したリモート・アクセスを通じてコンテンツを安全に伝送することができる、優れた通信システム、通信装置及び通信方法、並びにコンピューター・プログラムを提供することができる。

現行のＤＴＣＰ−ＩＰなどでは、相互認証及び鍵交換手続きにおいて、ＲＴＴやＴＴＬが制限されているため、リモート・アクセスに適用することはできない。これに対し、本願の第１、２、３、１３、１４、１５、１９乃至２１、２２乃至２５の側面に係る発明によると、伝送手段はＲＴＴやＴＴＬの制限を課さないので、コンテンツ提供装置にリモート・アクセスするコンテンツ利用装置へ、コンテンツを伝送することができる。また、本願の第１、２、３、１３、１４、１５、１９乃至２１、２２乃至２５の側面に係る発明によれば、登録手段によりＲＴＴやＴＴＬが制限された相互認証及び鍵交換手続きに従ってコンテンツ利用装置を登録し、伝送手段は事前に登録されたコンテンツ利用装置にのみコンテンツを伝送するので、不特定多数のユーザーからのリモート・アクセスを制限して、コンテンツの著作権保護を確保することができる。

本願の第４乃至６、１６、２６乃至２８の側面に係る発明によれば、登録するコンテンツ利用装置の台数を制限し、あるいは、登録されたコンテンツ利用装置のうちリモート・アクセス用の交換鍵を渡す台数を制限することで、不正利用の規模を限定することができる。また、本願の第４乃至６、１６、２６乃至２８の側面に係る発明によれば、登録台数を制限する以外に、コンテンツ伝送を許容する台数を制限することによって、登録できるコンテンツ利用装置の台数を、実際にコンテンツを利用できる台数に比べて大きく設定することができ、その結果、新たなコンテンツ利用装置を登録する際に古い登録内容を消去する手間を省くことができる。

機器仕様によっては、Ｓｉｎｋとしてのコンテンツ利用装置がＳｏｕｒｃｅとしてのコンテンツ提供装置の機能を兼ね備える場合がある。このように２つの機能を備える機器同士の接続関係をデイジーチェーン形式に繰り返すと、コンテンツ利用装置の登録を順次行なうことで、コンテンツを伝送可能な範囲、すなわち不正使用の規模は無限に拡大しかねない。これに対し、本願の第７、２９の側面に係る発明によれば、要求元のコンテンツ利用装置が事前に登録された正当なものであっても、伝送可能情報が付加されていないコンテンツを、コマンドの往復遅延時間に関する制限を課さない第２の相互認証手続きのみによって伝送することを禁止して、コンテンツ提供元が意図しない範囲にまでコンテンツが提供されないようにすることができる。

本願の第７、２９の側面に係る発明によると、コンテンツ提供装置がコマンドの往復遅延時間に関する制限を課さない第２の相互認証手続きを経たコンテンツ伝送に対応していない場合には、伝送可能情報が付加されたコンテンツであっても、１度もコマンドの往復遅延時間に関する制限を課さない第２の相互認証手続きを経たコンテンツ伝送が行なわれないことになり、コンテンツを提供できる範囲が不当に制限されてしまうことになる。これに対し、本願の第８、９、１７、１８、３０、３１の側面に係る発明によれば、コマンドの往復遅延時間に関する制限を課した第１の相互認証手続きを経て前記伝送可能情報が付加されたままコンテンツを伝送することができるので、第１の相互認証手続きが可能な範囲内において、コンテンツ伝送先となるコンテンツ利用装置はコンテンツ提供元に代行して、第２の相互認証手続きを経たコンテンツ伝送を行なうことができ、コンテンツを提供できる適正な範囲を確保することができる。また、本願の第９の側面に係る発明によれば、コンテンツの伝送を代行するコンテンツ利用装置を１台のみに限定することができる。

本願の第１０、１１、３２、３３の側面に係る発明によれば、コンテンツを同時にリモート・アクセスを利用できる数を制限することで不正の脅威を小さくすることができる。

本願の第７、２９の側面に係る発明によれば、伝送可能情報が付加されたコンテンツのみ、伝送手段によりコンテンツ利用装置に提供することが許可される。しかしながら、記録可能なコンテンツであれば、伝送可能情報が付加されていなくても、記録媒体に書き込んで持ち出すことで、コンテンツ利用装置に提供することができる。そこで、本願の第１２、３４の側面に係る発明のように、記憶部に記録してから所定時間が経過した後のコンテンツについては、伝送可能情報の有無に拘わらず、コンテンツ利用装置に提供できるようにしてもよい。

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

図１は、本発明に係る通信システムの一構成例を模式的に示した図である。 図２は、本発明に係る通信システムの他の構成例を模式的に示した図である。 図３は、コンテンツ提供装置１０の機能的構成を模式的に示した図である。 図４は、コンテンツ利用装置２０の機能的構成を模式的に示した図である。 図５は、ＳｏｕｒｃｅとＳｉｎｋの間でＤＴＣＰ−ＩＰにより暗号化コンテンツ伝送を行なう仕組みを説明するための図である。 図６は、ＳｏｕｒｃｅとＳｉｎｋ間で現行のＤＴＣＰ−ＩＰに従って行なわれる、ＡＫＥコマンドを用いた相互認証及び鍵交換の動作シーケンスを示した図である。 図７は、ＲＡ−ＳｏｕｒｃｅにＲＡ−Ｓｉｎｋを登録する際の認証シーケンス例を示した図である。 図８は、ＲＡ−ＳｏｕｒｃｅがＲＡ−Ｓｉｎｋを登録するための「ＲＡ−Ｓｉｎｋ Ｒｅｇｉｓｔｒａｔｏｉｎ」処理の手順を示したフローチャートである。 図９は、ＲＡ−ＳｏｕｒｃｅがＲＡ−Ｓｉｎｋに対してリモート・アクセス用の交換鍵を供給する際の認証シーケンス例を示した図である。 図１０は、ＲＡ−ＳｏｕｒｃｅがＲＡ−Ｓｉｎｋの登録確認及びリモート・アクセス用の交換鍵の供給数確認を行なうための「ＲＡ−Ｓｉｎｋ ＩＤ ｃｏｎｆｉｒｍａｔｉｏｎ」処理の手順を示したフローチャートである。 図１１は、ＲＡ−Ｓｏｕｒｃｅ、ＲＡ−Ｓｉｎｋがさらに別の機器にデイジーチェーン接続され、受信したコンテンツをさらに出力する可能性があるシステム構成例を模式的に示した図である。 図１２は、ＲＡ−Ｓｏｕｒｃｅ、ＲＡ−Ｓｉｎｋがさらに別の機器にデイジーチェーン接続され、受信したコンテンツをさらに出力する可能性があるシステム構成例を模式的に示した図である。 図１３は、ＲＡ−Ｓｏｕｒｃｅ、ＲＡ−Ｓｉｎｋがさらに別の機器にデイジーチェーン接続され、受信したコンテンツをさらに出力する可能性があるシステム構成例を模式的に示した図である。 図１４は、ＤＥＰ−ＲＡ−ＡＫＥを行なってＳｏｕｒｃｅ＃０が鍵をＳｉｎｋ＃１とだけ共有する際の認証シーケンス例を示した図である。 図１５は、ＳｏｕｒｃｅがＳｉｎｋにコンテンツのリモート・アクセス出力の代行を認証する「ＤＥＰ＿ＲＡ−Ｓｉｎｋ Ｃｏｎｆｉｒｍａｔｉｏｎ」処理の手順を示したフローチャートである。 図１６は、同じコンテンツを同時に伝送するＲＡ−Ｓｉｎｋの台数が制限される場合の、ＲＡ−ＳｉｎｋがＲＡ−Ｓｏｕｒｃｅにコンテンツを要求する際の動作シーケンスを示した図である。 図１７は、Ａ−Ｓｏｕｒｃｅがコンテンツ・データのリクエストに応じて実行する、同一コンテンツの出力数を管理するための処理手順を示したフローチャートである。 図１８は、ＲＡ−Ｓｏｕｒｃｅとして動作する機器がコンテンツを記録又はＭＯＶＥ機能で取り込むための処理手順を示したフローチャートである。 図１９は、ＲＡ−ＳｉｎｋがＲＡ−Ｓｏｕｒｃｅにコンテンツを要求する際の動作シーケンスを示した図である。 図２０は、コンテンツのリモート・アクセス（ＲＡ）出力数管理１の処理手順を示したフローチャートである。 図２１は、ＳｉｎｋがＳｏｕｒｃｅに対してリモート・アクセスを代行するコンテンツを要求する際の動作シーケンスを示した図である。 図２２は、コンテンツのリモート・アクセス出力代行管理の処理手順を示したフローチャートである。 図２３は、ＲＡ−ｆｌａｇの改竄を防ぐ方法の一例を説明するための図であり、具体的には、ＲＡ−ｆｌａｇの値を暗号鍵の計算をする関数に入力にして、暗号鍵Ｋ_cの値に反映させたりする方法を示した図である。 図２４は、ＲＡ−ｆｌａｇの改竄を防ぐ方法の一例を説明するための図であり、具体的には、ＲＡ−ｆｌａｇを含む、平文で伝送する情報を、その情報と暗号鍵をハッシュ関数で処理して署名データを求める方法を示した図である。 図２５は、ＲＡ−ｆｌａｇの改竄を防ぐ方法の一例を説明するための図であり、具体的には、ＲＡ−ｆｌａｇをコンテンツ・データとともに暗号化する際の格納先を示した図である。 図２６は、ＲＡ−ｆｌａｇの改竄を防ぐ方法の一例を説明するための図であり、具体的には、ＲＡ−ｆｌａｇをコンテンツ・データとともに暗号化する際の格納先を示した図である。 図２７は、ＲＡ−Ｓｏｕｒｃｅが、コンテンツに設定されたＲＡ−ｆｌａｇ及びＴを更新するための処理手順を示したフローチャートである。 図２８は、リモート・アクセス用のＡＫＥ ｃｏｎｔｒｏｌ ｃｏｍｍａｎｄの構成例を示した図である。 図２９は、コンテンツ提供装置に適用されるパーソナル・コンピューターの構成例を示した図である。 図３０は、コンテンツ提供装置に適用されるレコーダーの構成例を示した図である。

本発明は、ＷＡＮなどの外部ネットワークを経由したリモート・アクセス（ＲＡ）を通じてコンテンツを安全に伝送する通信システムに関するものである。同通信システムは、基本的に、リモート・アクセスによりコンテンツを提供するサーバ（ＲＡ−Ｓｏｕｒｃｅ）と、リモート・アクセスによりコンテンツを要求するクライアント（ＲＡ−Ｓｉｎｋ）からなる。本明細書では、リモート・アクセス時に行なうＡＫＥ手続きを、「ＲＡ−ＡＫＥ」と呼ぶことにする。以下、図面を参照しながら本発明の実施形態について詳細に説明する。

図１には、本発明に係る通信システムの一構成例を模式的に示している。図示の通信システムでは、ＲＡ−Ｓｏｕｒｃｅに相当するコンテンツ提供装置１０が家庭内に設置され、ＲＡ−Ｓｉｎｋに相当するコンテンツ利用装置２０が屋外にいる。そして、コンテンツ利用装置２０は、携帯電話のような通信機能によってコンテンツ提供装置１０に対してリモート・アクセスする。

コンテンツ提供装置１０は、一般にルーター３０とモデム４０経由でＷＡＮ５０などの外部ネットワークに接続される。ＷＡＮ５０は例えばインターネットである。ルーター３０には、ＷＡＮ５０側のＩＰアドレスが、ユーザーが加入するＩｎｔｅｎｅｔ Ａｃｃｓｅｓｓ Ｓｅｒｖｉｃｅ（ＩＡＳ）プロバイダー６０から割り当てられる。また、コンテンツ利用装置２０も、基本的にこのＩＰアドレスにアクセスする。ルーター３０は、コンテンツ提供装置１０にはプライベートＩＰアドレスを割り当て、ＷＡＮ５０からのアクセスについてはポート・フォワーディングによって通信を中継する。なお、ルーター３０に割り当てられるＩＰアドレスは、ＩＡＳプロバイダー６０によって更新される場合があるが、そのようなケースではＤＤＮＳサービス７０を用い、ルーター３０乃至コンテンツ提供装置１０のＤＤＮＳ（Ｄｙｎａｍｉｃ ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ））機能を使うことで対応できる。

また、図２には、本発明に係る通信システムの他の構成例を模式的に示している。図示の通信システムでは、ＲＡ−Ｓｉｎｋに相当するコンテンツ利用装置２０も家庭内に設置され、ルーター３１とモデム４１経由でＷＡＮ５０に接続されている。コンテンツ利用装置２０から発信されるＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）通信は、ルーター３１のＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）機能によってアドレス変換されるが、それ以外は図１の場合と同様である。

図３には、コンテンツ提供装置１０の機能的構成を模式的に示している。コンテンツ提供装置１０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１と、コンテンツ受信／再生部１２と、通信部１３と、記憶部１４と、タイマー１５を備えるが、ＲＡ−Ｓｏｕｒｃｅとして機能して、リモート・アクセスでコンテンツを送信する。

コンテンツ受信／再生部１２は、放送受信機能や、パッケージ・メディア再生機能をそなえている。ＣＰＵ１１は、コンテンツ受信／再生部１２で得られるコンテンツについて、リモート・アクセス可能なものを適切な保護を施した後に、通信部１３を通じて、ＲＡ−ＡＫＥにより相互認証及び鍵交換を行なったＲＡ−Ｓｉｎｋ（コンテンツ利用装置２０）に送信する。

記憶部１４には、後述の登録処理によって記憶することになったＲＡ−Ｓｉｎｋの識別情報や、ＲＡ−ＡＫＥを通じてＲＡ−Ｓｉｎｋと共有したリモート・アセス用の交換鍵とその交換鍵の識別情報などが記憶される。また、記憶部１４は、コンテンツ受信／再生部１２で得たコンテンツを蓄積する用途で用いることもできる。

タイマー１５は、リモート・アクセス可能なコンテンツを扱う際に、時間管理が必要となる場合（例えば、後述するように、基準点時刻からのリモート・アクセス不可期限を管理する場合）に使われる。

図４には、コンテンツ利用装置２０の機能的構成を模式的に示している。コンテンツ利用装置２０は、ＣＰＵ２１と、通信部２２と、コンテンツ出力部２３と、記憶部２４を備えるが、ＲＡ−Ｓｉｎｋとして機能して、リモート・アクセスでコンテンツを受信する。

ＲＡ−Ｓｉｎｋとしてのコンテンツ利用装置２０は、通信部２２を通じてＲＡ−Ｓｏｕｒｃｅ（コンテンツ提供装置１０）に対して後述の機器登録処理を行なう他、ＲＡ−ＡＫＥを行なってＲＡ−Ｓｏｕｒｃｅから交換鍵を取得して記憶部２４に保持するとともに、その鍵を基に算出する暗号鍵でＲＡ−Ｓｏｕｒｃｅから得た暗号化コンテンツを復号して、コンテンツ出力部２３からコンテンツを出力する。記憶部２４は、ＲＡ−Ｓｏｕｒｃｅから受け取った交換鍵やコンテンツを蓄積する用途で用いられる。

以下の説明では、交換鍵から暗号鍵を算出する方法はＤＴＣＰ−ＩＰに従うものとする（但し、本発明の要旨は必ずしもこの方法には限定されない）。

ここで、ＳｏｕｒｃｅとＳｉｎｋの間でＤＴＣＰ−ＩＰにより暗号化コンテンツ伝送を行なう仕組みについて、図５を参照しながら説明しておく。コンテンツ伝送の形態は、Ｓｏｕｒｃｅ上のコンテンツをＳｉｎｋにコピーする方法と、ＳｏｕｒｃｅからＳｉｎｋへコンテンツを移動してＳｏｕｒｃｅにコンテンツを残さない方法があるが（周知）、同図では前者のコピーによるコンテンツ伝送方法を前提にして説明する。

ＳｏｕｒｃｅとＳｉｎｋは、まず１つのＴＣＰ／ＩＰコネクションを確立して、機器同士の認証（ＡＫＥ手続き）を行なう。ＤＴＣＰ準拠機器には、ＤＴＬＡ（前述）により発行された機器証明書が埋め込まれている。ＡＫＥ手続きでは、互いが正規のＤＴＣＰ準拠機器であることを確かめた後、認証鍵Ｋ_authをＳｏｕｒｃｅとＳｉｎｋで共有することができる。

ＡＫＥ手続きが成功すると、Ｓｏｕｒｃｅはコンテンツ鍵Ｋ_cの種となる交換鍵Ｋ_xを生成し、認証鍵Ｋ_authで暗号化してＳｉｎｋに送る。Ｓｏｕｒｃｅ及びＳｉｎｋそれぞれにおいて、交換鍵Ｋ_xに対して所定の演算処理を適用することによって、コンテンツ伝送時にコンテンツを暗号化するために使用されるコンテンツ鍵Ｋ_cを生成することができる。

そして、ＤＴＣＰ準拠の機器間でＡＫＥによる認証及び鍵交換手続きが済んだ後、ＨＴＴＰやＲＴＰなどのプロトコルを利用してコンテンツ伝送が開始される。図示の例では、ＨＴＴＰの手続きに従ってコンテンツ伝送が行なわれる。その際、ＡＫＥ手続きのためのＴＣＰ／ＩＰコネクションとは別に、ＨＴＴＰのためのＴＣＰ／ＩＰコネクションが作成される（すなわち、ＳｏｕｒｃｅとＳｉｎｋはそれぞれ、ＡＫＥ手続き用とコンテンツ伝送用に個別のソケット情報（ＩＰアドレスとポート番号の組み合わせ）を持つ）。

ＨＴＴＰプロトコルに従ってコンテンツ伝送を行なうには、ＳｉｎｋがＳｏｕｒｃｅにコンテンツを要求するダウンロード形式と、Ｓｏｕｒｃｅ側からＳｉｎｋにコンテンツをプッシュするアップロード形式の２通りが挙げられる。前者の場合、ＨＴＴＰクライアントとしてのＳｉｎｋは、例えばＨＴＴＰ ＧＥＴメソッドを用いたＨＴＴＰリクエストにより、ＨＴＴＰサーバーとしてのＳｏｕｒｃｅにコンテンツを要求し、これに対し、Ｓｏｕｃｅからは要求通りのコンテンツがＨＴＴＰレスポンスとして伝送される。また後者の場合、ＨＴＴＰクライアントとしてのＳｏｕｒｃｅは、例えばＨＴＴＰ ＰＯＳＴメソッドを用いたＨＴＴＰリクエストにより、ＨＴＴＰサーバーとしてのＳｉｎｋとの伝送を開始する。

Ｓｏｕｒｃｅから伝送されるデータは、ＳｏｕｒｃｅがＡＫＥ認証をした後に共有した鍵を用いてコンテンツを暗号化したデータとなっている。具体的には、Ｓｏｕｒｃｅは、乱数を用いてノンスＮ_cを生成して、交換鍵Ｋ_xとノンスＮ_cと暗号モードに応じたコンテンツ鍵Ｋ_cを生成する。そして、Ｓｉｎｋから要求されているコンテンツを、コンテンツ鍵Ｋ_cを用いて暗号化し、暗号化コンテンツからなるペイロードとノンスＮ_cと暗号モードの情報を含んだヘッダからなるパケットをＴＣＰストリーム上に乗せて送信する。ＩＰプロトコルでは、ＴＣＰストリームを所定の単位となるパケットの大きさに分割し、さらにヘッダ部を付加したＩＰパケットにし、指定されたＩＰアドレス宛てに届ける。

Ｓｉｎｋ側では、Ｓｏｕｒｃｅからの各ＩＰパケットを受信すると、これをＴＣＰストリームに組み立てる。そして、このストリームからノンスＮ_cとＥ−ＥＭＩを取り出すと、これらと交換鍵Ｋ_xを用いてコンテンツ鍵Ｋ_cを算出し、暗号化コンテンツを復号することができる。そして、復号化した後の平文のコンテンツに対し再生処理を実施することができる。あるいは、Ｓｉｎｋは、暗号化コンテンツを復号することなく、コンテンツを記憶部２４に格納したり、他の機器にスルーしたりする。このようにしてＨＴＴＰプロトコルを利用したコンテンツ伝送が終了すると、例えばＳｉｎｋ側から、コンテンツ伝送に使用したＴＣＰコネクションを適宜切断する。（ＤＴＣＰ−ＩＰでは、パケットのヘッダ部に記述するＥ−ＥＭＩ（ＥｘｔｅｎｄｅｄＥｎｃｒｙｐｔｉｏｎ Ｍｏｄｅ Ｉｎｄｉｃａｔｏｒ）と、Ｅｍｂｅｄｄｅｄ ＣＣＩ（Ｃｏｐｙ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）という２つのメカニズムにより、コンテンツに付随したコピー制御情報の伝送を実現している。）

なお、ＤＴＣＰ−ＩＰでは、連続不使用時間が所定の期間（例えば２時間）を超える前に破棄することが規定されている。ＳｉｎｋはＳｏｕｒｃｅから最新の交換鍵Ｋ_xを入手できなければ、暗号化コンテンツを利用不能となる。また、交換鍵Ｋ_xの運用方法には、Ｓｉｎｋ毎に１つずつ鍵を用意する方法と、Ｓｉｎｋによらず１つの鍵を使う方法がある。

図６には、ＳｏｕｒｃｅとＳｉｎｋ間で現行のＤＴＣＰ−ＩＰに従って行なわれる、ＡＫＥコマンドを用いた相互認証及び鍵交換の動作シーケンス（ＲＴＴ−ＡＫＥ）を示している。

ＡＫＥ手続きのチャレンジ・レスポンス部分（Ｃｈａｌｌｅｎｇｅ−Ｒｅｓｐｏｎｓｅ ｐｏｒｔｉｏｎ ｏｆ ＡＫＥ）では、まず、コンテンツを要求するＳｉｎｋから、Ｒｘ乱数とＲｘ証明書を含んだＲｘチャレンジが送信される。これに対し、Ｓｏｕｒｃｅからは、Ｔｘ乱数及びＴｘ証明書を含んだＴｘチャレンジが返信される。以降、Ｓｏｕｒｃｅから、Ｒｘ乱数、Ｔｘメッセージ、Ｔｘ署名を含んだＲｘレスポンスが送信されるとともに、ＳｉｎｋからはＴｘ乱数、Ｒｘメッセージ、Ｒｘ署名を含んだＴｘレスポンスが送信され、通常のチャレンジ・レスポンス認証手続きが続く。チャレンジ・レスポンス部分で送信されるコマンドには、各チャレンジ・コマンドには、機器固有の識別情報であるＤｅｖｉｃｅ ＩＤが含まれている。

上記のチャレンジ・レスポンス応答手続きでは、ＴＴＬ（ＩＰルーターのホップ回数）の制限が課されている。すなわち、現在のＤＴＣＰ−ＩＰでは、送信機器はＡＫＥで用いるコマンドを送るＴＣＰ／ＩＰ通信においてＴＴＬが３以下に設定され、受信機器はＴＴＬが３より大きい場合は受け取ったデータを無効にしなければならない。

その後、ＲＴＴ保護プロトコル（Ｐｒｏｔｅｃｔｅｄ ＲＴＴ Ｐｒｏｔｏｃｏｌ）を経て、ＳｏｕｒｃｅからＳｉｎｋへ、ＥＸＣＨＡＮＧＥ＿ＫＥＹコマンドが送信され、これに対し、Ｓｉｎｋからレスポンス（図示しない）が返される。

図６に示した現行のＤＴＣＰ−ＩＰに従うＲＴＴ−ＡＫＥでは、ＡＫＥコマンドに対し往復遅延時間（ＲＴＴ）やＩＰルーターのホップ回数（ＴＴＬ）が制限されており、現状のままでは、リモート・アクセスに適用することはできない（前述）。しかしながら、ユーザーの利便性を考えると、ユーザーが出先から自宅のサーバーにリモート・アクセスして、コンテンツを再生するという使い方が望まれる。勿論、著作権保護したいというコンテンツ・オーナーの利益を確保する必要がある。したがって、リモート・アクセスは、コンテンツ・オーナーが許容するコンテンツの範囲内に制限すべきであり、且つ、リモート・アクセスされるコンテンツの保護も行なわなければならない。

これに対し、本発明として提案する、リモート・アクセス時のＡＫＥ手続きすなわちＲＡ−ＡＫＥでは、図６に示したＲＴＴ−ＡＫＥ手続きで行なっている「Ｐｒｏｔｅｃｔｅｄ ＲＴＴ Ｐｒｏｔｏｃｏｌ」を行なわない。すなわち、ＳｏｕｒｃｅとＳｉｎｋの間のＲＴＴが７ミリ秒を超えてもＡＫＥ手続きを中止しない。また、ＲＡ−ＡＫＥでは、上記のＴＴＬの上限を設けない。すなわち、ＲＡ−ＡＫＥでは、ＲＴＴ並びにＴＴＬの制限を設けないことで、リモート・アクセスに対応するＳｏｕｒｃｅ（コンテンツ提供装置１０）と、リモート・アクセスに対応するＳｉｎｋ（コンテンツ利用装置２０）が、応答遅延時間が７ミリ秒を超え、又は、ホップ数が３を超えるだけ離間していたとしても、両機器間でＡＫＥ手続きを成功裏に実施して、リモート・アクセス用の交換鍵を共有することができる。

但し、ＲＴＴ並びにＴＴＬの制限が外された状態の通信システムでは、任意の機器間でコンテンツの伝送が可能になるため、コンテンツの著作権保護の観点から不正な利用を防止する仕組みが必要になる。

ＲＡ−ＡＫＥ手続きにおいてＲＴＴ並びにＴＴＬの制限を設けないことに伴う不正な利用方法の１つとして、不特定多数（言い換えれば、著作権法で許容される私的使用の範囲を超えた）のユーザーが各自のＲＡ−Ｓｉｎｋを特定のユーザーのＲＡ−Ｓｏｕｒｃｅと接続し、そのコンテンツを遠隔利用することが考えられる。したがって、不特定多数のユーザーからの接続を制限する必要がある。

不特定多数のユーザーからの接続を制限するために、ＲＡ−Ｓｏｕｒｃｅが事前に登録されたＲＡ−ＳｉｎｋとだけＲＡ−ＡＫＥ手続きを行なう方法と、ＲＡ−ＡＫＥ手続きで鍵を渡すＲＡ−Ｓｉｎｋの台数を制限する方法が考えられる。前者の事前登録に関しては、現在のＤＴＣＰ−ＩＰのＲＴＴ−ＡＫＥのように、ＲＴＴやＴＴＬ制限を伴うＡＫＥ手続きに成功した場合にだけ、ＲＡ−ＳｏｕｒｃｅがＲＡ−Ｓｉｎｋの機器固有ＩＤを記憶するようにすることで、不特定多数のユーザーがＲＡ−ＡＫＥ手続きを成功できないようにする。

また、ＲＡ−Ｓｏｕｒｃｅに登録するＲＡ−Ｓｉｎｋの台数を制限することで、不正利用の規模を限定することができる。以下では、ＲＡ−Ｓｏｕｒｃｅは、所定台数までのＲＡ−ＳｉｎｋのＩＤを登録するための「ＲＡレジストリー」（記憶部１４内に）を備えているものとする。ここで、仮にＲＡ−Ｓｉｎｋの機器固有ＩＤをＲＡ−Ｓｏｕｒｃｅに登録できた場合であっても、後述するように、コンテンツ伝送の際にリモート・アクセス用の交換鍵を供給するＲＡ−Ｓｉｎｋの台数を制限することで、不正利用の規模を限定することができる。

ＲＡ−Ｓｉｎｋの登録手続きは、例えば、ＲＴＴ並びにＴＴＬの制限に収まる家庭内で事前に行なわれる。その際、ＲＡ−Ｓｏｕｒｃｅは多めの１０台のＲＡ−Ｓｉｎｋを登録するようにしてもよい。そして、ＲＡ−Ｓｏｕｒｃｅに対し１０台のＲＡ−Ｓｉｎｋを事前登録したとしても、ＲＡ−Ｓｏｕｒｃｅはこのうちの５台までしかリモート・アクセス用の交換鍵を渡さないようにする。

図７には、ＲＡ−ＳｏｕｒｃｅにＲＡ−Ｓｉｎｋを登録する際の認証シーケンス例を示している。

この認証シーケンスは、ＲＡ−ＳｉｎｋがＲＡ−Ｓｏｕｒｃｅに対して登録要求コマンド「ＲＡ＿ＲＥＧＩ＿ＩＮＩＴ」を送信することによって開始する。ＲＡ−ＡＫＥ手続きのチャレンジ・レスポンス部分（Ｃｈａｌｌｅｎｇｅ−Ｒｅｓｐｏｎｓｅ ｐｏｒｔｉｏｎ ｏｆ ＡＫＥ）では、まず、ＲＡ−Ｓｉｎｋから、Ｒｘ乱数とＲｘ証明書を含んだＲｘチャレンジが送信される。これに対し、ＲＡ−Ｓｏｕｒｃｅからは、Ｔｘ乱数及びＴｘ証明書を含んだＴｘチャレンジが返信される。以降、ＲＡ−Ｓｏｕｒｃｅから、Ｒｘ乱数、Ｔｘメッセージ、Ｔｘ署名を含んだＲｘレスポンスが送信されるとともに、ＲＡ−ＳｉｎｋからはＴｘ乱数、Ｒｘメッセージ、Ｒｘ署名を含んだＴｘレスポンスが送信される。なお、「ＲＡ＿ＲＥＧＩ＿ＩＮＩＴ」を送信する代わりに、Ｒｘチャレンジとして送信する情報の中に、「ＲＡ＿ＲＥＧＩ＿ＩＮＩＴ」の送信に相当する情報、例えば「ＲＡ＿ＲＥＧＩ＿ＩＮＩＴ＿ｆｌａｇ」を含める方法も考えられる。

各チャレンジ・コマンドには、機器固有の識別情報であるＤｅｖｉｃｅ ＩＤが含まれている。但し、同チャレンジ・レスポンス部分の中では、ＳｉｎｋからＳｏｕｒｃｅへのレスポンスとして「ＲＥＳＰＯＮＳＥ２」が送られることがある。これは、機器がＣｏｍｍｏｎ Ｄｅｖｉｃｅ ＫｅｙとＣｏｍｍｏｎ Ｄｅｖｉｃｅ Ｃｅｒｔｉｆｉｃａｔｅを実装することで、Ｄｅｖｉｃｅ ＩＤが機器固有とならない場合である。ＲＥＳＰＯＮＳＥ２が送られる場合は、機器固有の識別情報として、Ｄｅｖｉｃｅ ＩＤではなく、ＲＥＳＰＯＮＳＥ２に含まれる機器固有情報であるＩＤｕを使うことになる。

登録手続きにおけるＲＡ−ＡＫＥ手続きのチャレンジ・レスポンス部分は、現行のＤＴＣＰ−ＩＰにおけるＲＴＴ−ＡＫＥ手続きと同様の処理となり、ＴＴＬの制限が課されている。その後、ＲＴＴ保護プロトコル（Ｐｒｏｔｅｃｔｅｄ ＲＴＴ Ｐｒｏｔｏｃｏｌ）がさらに続き、ＲＡ−ＳｏｕｒｃｅとＲＡ−Ｓｉｎｋの間のＲＴＴが７ミリ秒を超えるとＲＡ−ＡＫＥ手続きを中止する。

ＲＡ−Ｓｏｕｒｃｅは、ここまでの手順に成功したＲＡ−Ｓｉｎｋを登録するための「ＲＡ−Ｓｉｎｋ Ｒｅｇｉｓｔｒａｔｏｉｎ」処理を実行する。そして、ＲＡ−Ｓｏｕｒｃｅは、記憶部１４内のＲＡレジストリーにＲＡ−ＳｉｎｋのＩＤを登録できる余裕があれば追加登録し、その結果を、結果コードを送るコマンド「ＲＡ＿ＲＥＧＩ＿ＥＮＤ」でＲＡ−Ｓｉｎｋに通知する。

なお、図７中の「ＲＡ＿ＲＥＧＩ＿ＩＮＩＴ」と「ＲＡ＿ＲＥＧＩ＿ＥＮＤ」は、ＤＴＣＰ−ＩＰのＡＫＥ ｃｏｎｔｒｏｌ ｃｏｍｍａｎｄにリモート・アクセス用のコマンドとして追加するものとする。図２８には、リモート・アクセス用のＡＫＥ ｃｏｎｔｒｏｌ ｃｏｍｍａｎｄの構成例を示している。図示の例では、ｓｕｂｆｕｎｃｔｉｏｎフィールドに新たな値を割り当て、ＡＫＥ＿Ｉｎｆｏで情報を運ぶことができる。

図８には、ＲＡ−ＳｏｕｒｃｅがＲＡ−Ｓｉｎｋを登録するための「ＲＡ−Ｓｉｎｋ Ｒｅｇｉｓｔｒａｔｏｉｎ」処理の手順をフローチャートの形式で示している。

ＲＡ−Ｓｏｕｒｃｅは、まず、当該処理ルーチンを開始する以前の処理（Ｃｈａｌｌｅｎｇｅ−Ｒｅｓｐｏｎｓｅ ｐｏｒｔｉｏｎ ｏｆ ＡＫＥ、並びに、Ｐｒｏｔｅｃｔｅｄ ＲＴＴ Ｐｒｏｔｏｃｏｌ）を異常終了（ａｂｏｒｔ）したか否かをチェックする（ステップＳ１）。

ここで、以前の処理を異常終了していた場合には（ステップＳ１のＮｏ）、ＲＡ−Ｓｏｕｒｃｅは、要求元のＲＡ−Ｓｉｎｋに対し、登録処理に「失敗」した旨の結果コードを通知して（ステップＳ９）、本処理ルーチンを終了する。

また、以前の処理を正常に終了していた場合には（ステップＳ１のＹｅｓ）、ＲＡ−Ｓｏｕｒｃｅは、ＲＥＳＰＯＮＳＥ２（前述）を受信したか否かをチェックする（ステップＳ２）。そして、ＲＥＳＰＯＮＳＥ２を受信したときには（ステップＳ２のＹｅｓ）、ＲＡ−Ｓｏｕｒｃｅは、要求元のＲＡ−ＳｉｎｋのＩＤをＩＤｕとする（ステップＳ３）。また、ＲＥＳＰＯＮＳＥ２を受信していないときには（ステップＳ２のＮｏ）、ＲＡ−Ｓｏｕｒｃｅは、要求元のＲＡ−ＳｉｎｋのＤｅｖｉｃｅ ＩＤをＩＤとする（ステップＳ４）。

次いで、ＲＡ−Ｓｏｕｒｃｅは、要求元のＲＡ−ＳｉｎｋのＩＤをＲＡレジストリーに既に登録済みか否かをチェックする（ステップＳ５）。

ここで、要求元のＲＡ−ＳｉｎｋのＩＤをＲＡレジストリーに既に登録済みである場合には（ステップＳ５のＹｅｓ）、ＲＡ−Ｓｏｕｒｃｅは、要求元のＲＡ−Ｓｉｎｋに対し、登録処理に「成功」した旨の結果コードを通知して（ステップＳ８）、本処理ルーチンを終了する。

他方、要求元のＲＡ−ＳｉｎｋのＩＤをＲＡレジストリーにまだ登録していないときには（ステップＳ５のＮｏ）、ＲＡ−Ｓｏｕｒｃｅは、続いて、記憶部１４内のＲＡレジストリーに空きがあるか否かをチェックする（ステップＳ６）。

ここで、ＲＡレジストリーに空きがない場合には（ステップＳ６のＮｏ）、ＲＡ−Ｓｏｕｒｃｅは、要求元のＲＡ−Ｓｉｎｋに対し、登録処理に「失敗」した旨の結果コードを通知して（ステップＳ９）、本処理ルーチンを終了する。

また、ＲＡレジストリーに空きがある場合には（ステップＳ６のＹｅｓ）、ＲＡ−Ｓｏｕｒｃｅは、ＲＡレジストリーにＲＡ−ＳｉｎｋのＩＤを追加登録する（ステップＳ７）。そして、ＲＡ−Ｓｏｕｒｃｅは、要求元のＲＡ−Ｓｉｎｋに対し、登録処理に「成功」した旨の結果コードを通知して（ステップＳ８）、本処理ルーチンを終了する。

図７並びに図８を参照しながら説明したように、ＲＡ−Ｓｏｕｒｃｅは、ＲＴＴ−ＡＫＥと同様の認証手順に成功すると、ＲＡレジストリーにＲＡ−ＳｉｎｋのＩＤを登録できる余裕があれば追加登録する。ＲＡ−Ｓｉｎｋは、ＲＡ−Ｓｏｕｒｃｅにリモート・アクセスするには、上記認証手順を経て自分のＩＤをＲＡ−ＳｏｕｒｃｅのＲＡレジストリーに登録することが必要である。したがって、ＲＡ−Ｓｏｕｒｃｅは、ＲＡレジストリーの登録可能数によって、ＲＡ−Ｓｏｕｒｃｅを利用可能なＲＡ−Ｓｉｎｋの台数を制限して、コンテンツの不正利用の規模を限定することができる。

図９には、ＲＡ−ＳｏｕｒｃｅがＲＡ−Ｓｉｎｋに対してリモート・アクセス用の交換鍵を供給する際の認証シーケンス例を示している。図示のシーケンスは、リモート・アクセス用の交換鍵を供給するＲＡ−Ｓｉｎｋの台数を制限する仕組みを備えている。

この認証シーケンスは、ＲＡ−ＳｉｎｋがＲＡ−Ｓｏｕｒｃｅに対して鍵供給要求コマンド「ＲＡ＿ＡＫＥ＿ＩＮＩＴ」を送信することによって開始する。ＲＡ−ＡＫＥ手続きのチャレンジ・レスポンス部分（Ｃｈａｌｌｅｎｇｅ−Ｒｅｓｐｏｎｓｅ ｐｏｒｔｉｏｎ ｏｆ ＡＫＥ）では、まず、ＲＡ−Ｓｉｎｋから、Ｒｘ乱数とＲｘ証明書を含んだＲｘチャレンジが送信される。これに対しＲＡ−Ｓｏｕｒｃｅからは、Ｔｘ乱数及びＴｘ証明書を含んだＴｘチャレンジが返信される。以降、ＲＡ−Ｓｏｕｒｃｅから、Ｒｘ乱数、Ｔｘメッセージ、Ｔｘ署名を含んだＲｘレスポンスが送信されるとともに、ＲＡ−ＳｉｎｋからはＴｘ乱数、Ｒｘメッセージ、Ｒｘ署名を含んだＴｘレスポンスが送信される。なお、「ＲＡ＿ＡＫＥ＿ＩＮＩＴ」を送信する代わりに、Ｒｘチャレンジとして送信する情報の中に、「ＲＡ＿ＡＫＥ＿ＩＮＩＴ」の送信に相当する情報、例えば「ＲＡ＿ＡＫＥ＿ＩＮＩＴ＿ｆｌａｇ」を含める方法も考えられる。

各チャレンジ・コマンドには、機器固有の識別情報であるＤｅｖｉｃｅ ＩＤが含まれている。但し、同チャレンジ・レスポンス部分の中では、ＳｉｎｋからＳｏｕｒｃｅへのレスポンスとして「ＲＥＳＰＯＮＳＥ２」が送られることがあるが、その場合は、機器固有の識別情報として、Ｄｅｖｉｃｅ ＩＤではなく、ＲＥＳＰＯＮＳＥ２に含まれるＩＤｕを使うことになる（同上）。

ＴＴＬの制限は、ＲＡ−Ｓｏｕｒｃｅへ登録する際には必要であるが、リモート・アクセス用の交換鍵供給のためのＲＡ−ＡＫＥ手続きでは省略される。また、ＲＴＴ保護プロトコル（Ｐｒｏｔｅｃｔｅｄ ＲＴＴ Ｐｒｏｔｏｃｏｌ）も、鍵供給のためのＲＡ−ＡＫＥ手続きでは省略される。これによって、ＲＡ−Ｓｉｎｋは、リモート環境下でもリモート・アクセス用の交換鍵を要求することができ、すなわち、リモート・アクセスによるコンテンツの利用が可能になる。

そして、上記の認証手順に成功すると、ＲＡ−Ｓｏｕｒｃｅは、「ＲＡ−Ｓｉｎｋ ＩＤ ｃｏｎｆｉｒｍａｔｉｏｎ」処理を実行する。この処理では、ＲＡ−Ｓｏｕｒｃｅは、要求元のＲＡ−ＳｉｎｋのＩＤがＲＡレジストリーに登録済みであることを確認するとともに、リモート・アクセス用の交換鍵の供給数（ＫＣ）が上限を超えていないかを確認する。そして、ＲＡ−Ｓｏｕｒｃｅは、これらの確認ができた場合に、リモート・アクセス用の交換鍵（ＲＡ＿Ｋ_x）と、当該交換鍵のＩＤ（ＲＡ＿Ｋ_x＿ｌａｂｅｌ）と結果コードを、コマンド「ＲＡ＿ＥＸＣＨＡＮＧＥ＿ＫＥＹ」でＲＡ−Ｓｉｎｋに渡す。

なお、リモート・アクセス用の交換鍵の供給数ＫＣの上限は、記憶部１４内のＲＡレジストリーに登録できるＩＤの数と同じか、それより少なく設定される。つまり、事前登録する台数の制限によってコンテンツの不正利用の規模を限定する以外に、ＫＣの上限によってＲＡ−Ｓｉｎｋの利用可能な数を制限して不正利用の規模をさらに限定することが可能である。また、ＲＡレジストリーへの登録台数の制限の他に、ＫＣの上限を設けることによって、ＲＡ−Ｓｏｕｒｃｅへ登録できるＲＡ−Ｓｉｎｋの台数を、コンテンツを利用できるＲＡ−Ｓｉｎｋの台数に比べて大きく設定することができ、その結果、新たなＲＡ−Ｓｉｎｋを登録する際に古い登録内容を消去する手間を省くことができる。

リモート・アクセス用の交換鍵の供給数ＫＣは、ＲＡ−ＳｏｕｒｃｅがＲＡ−Ｓｉｎｋに渡した交換鍵のうち、有効なものの数である。したがって、どのＲＡ−Ｓｉｎｋにも交換鍵を渡していない初期状態ではＫＣはゼロであり、渡した交換鍵をＲＡ−Ｓｏｕｒｃｅが破棄したときはその分を減らすことができる。

ここで、ＫＣの上限が２以上の場合、リモート・アクセス用の交換鍵の運用方法には、ＲＡ−Ｓｉｎｋ毎に１つずつ鍵を用意する方法と、ＲＡ−Ｓｉｎｋによらず１つの鍵を使う方法がある。前者の場合は１つの交換鍵を破棄するとＫＣを１つ減らすことになり、後者の場合は交換鍵を破棄するとＫＣをゼロにリセットすることになる。

リモート・アクセス用の交換鍵の（ＲＡ＿Ｋ_x）の破棄については、ＤＴＣＰ−ＩＰと同様に連続不使用期間が所定の期間を超える前に破棄するというルールで運用することが考えられる。また、ＲＡ−Ｓｉｎｋがリモート・アクセスの終了時に当該交換鍵の破棄を求めるコマンド（ＲＡ＿ＦＩＮＩＳＨ）を交換鍵のＩＤ（ＲＡ＿Ｋ_x＿ｌａｂｅｌ）とともに送るという運用形態も考えられる。この破棄要求コマンドＲＡ＿ＦＩＮＩＳＨは、図９中の「ＲＡ−ＡＫＥ＿ＩＮＩＴ」、「ＲＡ＿ＥＸＣＨＡＮＧＥ＿ＫＥＹ」とともに、ＤＴＣＰ−ＩＰのＡＫＥ ｃｏｎｔｒｏｌ ｃｏｍｍａｎｄに、リモート・アクセス用のコマンドとして追加するものとする。

図１０には、ＲＡ−ＳｏｕｒｃｅがＲＡ−Ｓｉｎｋの登録確認及びリモート・アクセス用の交換鍵の供給数確認を行なうための「ＲＡ−Ｓｉｎｋ ＩＤ ｃｏｎｆｉｒｍａｔｉｏｎ」処理の手順をフローチャートの形式で示している。

ＲＡ−Ｓｏｕｒｃｅは、まず、当該処理ルーチンを開始する以前の処理（Ｃｈａｌｌｅｎｇｅ−Ｒｅｓｐｏｎｓｅ ｐｏｒｔｉｏｎ ｏｆ ＡＫＥ、Ｐｒｏｔｅｃｔｅｄ ＲＴＴ Ｐｒｏｔｏｃｏｌ）を異常終了（ａｂｏｒｔ）したか否かをチェックする（ステップＳ１１）。

ここで、以前の処理を異常終了していた場合には（ステップＳ１１のＮｏ）、ＲＡ−Ｓｏｕｒｃｅは、要求元のＲＡ−Ｓｉｎｋに対し、ＲＡ−ＡＫＥ手続きを中断して（ステップＳ２０）、本処理ルーチンを終了する。

また、以前の処理を正常に終了していた場合には（ステップＳ１１のＹｅｓ）、ＲＡ−Ｓｏｕｒｃｅは、ＲＥＳＰＯＮＳＥ２を受信したか否かをチェックする（ステップＳ１２）。そして、ＲＥＳＰＯＮＳＥ２を受信したときには（ステップＳ１２のＹｅｓ）、ＲＡ−Ｓｏｕｒｃｅは、要求元のＲＡ−ＳｉｎｋのＩＤをＩＤｕとする（ステップＳ１３）。また、ＲＥＳＰＯＮＳＥ２を受信していないときには（ステップＳ１２のＮｏ）、ＲＡ−Ｓｏｕｒｃｅは、要求元のＲＡ−ＳｉｎｋのＤｅｖｉｃｅ ＩＤをＩＤとする（ステップＳ１４）。

次いで、ＲＡ−Ｓｏｕｒｃｅは、要求元のＲＡ−ＳｉｎｋのＩＤを記憶部１４内のＲＡレジストリーに既に登録済みか否かをチェックする（ステップＳ１５）。

ここで、要求元のＲＡ−ＳｉｎｋのＩＤをＲＡレジストリーに登録してあることを確認できないときには（ステップＳ１５のＮｏ）、ＲＡ−Ｓｏｕｒｃｅは、要求元のＲＡ−Ｓｉｎｋに対し、ＲＡ−ＡＫＥ手続きを中断して（ステップＳ２０）、本処理ルーチンを終了する。

他方、要求元のＲＡ−ＳｉｎｋのＩＤをＲＡレジストリーに登録済みであることを確認できたときには（ステップＳ１５のＹｅｓ）、ＲＡ−Ｓｏｕｒｃｅは、続いて、リモート・アクセス用の交換鍵の供給数ＫＣが上限値未満であるかどうかをチェックする（ステップＳ１６）。

そして、リモート・アクセス用の交換鍵の供給数ＫＣが上限値未満であることを確認できたときには（ステップＳ１６のＹｅｓ）、ＲＡ−Ｓｏｕｒｃｅは、ＫＣを１だけインクリメントして（ステップＳ１７）、確認処理に「成功」した旨の結果コードを、リモート・アクセス用の交換鍵（ＲＡ＿Ｋ_x）とそのＩＤ（ＲＡ＿Ｋ_x＿ｌａｂｅｌ）とともに、要求元のＲＡ−Ｓｉｎｋに通知して（ステップＳ１９）、本処理ルーチンを終了する。

また、鍵の供給数ＫＣが上限値に到達しているときには（ステップＳ１６のＮｏ）、ＲＡ−Ｓｏｕｒｃｅは、「ｂｕｓｙ」である旨の結果コードを要求元のＲＡ−Ｓｉｎｋに通知して（ステップＳ１８）、本処理ルーチンを終了する。

ＲＡ−ＳｏｕｒｃｅとＲＡ−Ｓｉｎｋの間でリモート・アクセス用の交換鍵が共有されると、リモート・アクセスによるコンテンツ伝送が可能な状態となる。図１９には、ＲＡ−ＳｉｎｋがＲＡ−Ｓｏｕｒｃｅに対してコンテンツを要求する際の動作シーケンスを示している。但し、同図では、ＲＡ−ＳｉｎｋからＲＡ−Ｓｏｕｒｃｅに対してＨＴＴＰプロトコルに従ってコンテンツが要求され、ダウンロード形式でコンテンツが伝送されるものとする。

ＲＡ−Ｓｉｎｋは、図９に示したＲＡ−ＡＫＥ手続きによってリモート・アクセス用の交換鍵（ＲＡ＿Ｋ_x）とそのＩＤ（ＲＡ＿Ｋ_x＿ｌａｂｅｌ）を取得した後、ＨＴＴＰ ＧＥＴメソッドを用いたＨＴＴＰリクエスト（ＨＴＴＰ ＧＥＴ ｒｅｑｕｅｓｔ）により、ＲＡ−Ｓｏｕｒｃｅにコンテンツ・データをリクエストする。このリクエストの際には、コンテンツのＵＲＬとともに、リモート・アクセス出力用の交換鍵のＩＤ（ＲＡ＿Ｋ_x＿ｌａｂｅｌ）を送る。ここで、ＲＡ−ＳｉｎｋからＲＡ−Ｓｏｕｒｃｅに交換鍵のＩＤ（ＲＡ＿Ｋ_x＿ｌａｂｅｌ）を送るためのヘッダーフィールドを定義する。

ＲＡ−Ｓｏｕｒｃｅは、コンテンツ・データのリクエストを受けると、要求されたコンテンツがリモート・アクセス出力数をチェックするための「コンテンツのリモート・アクセス（ＲＡ）出力管理１」の処理を実行する。そして、リクエストで指定されたＵＲＬのコンテンツがリモート・アクセス出力可能であることが確認できたなら、ＲＡ−Ｓｏｕｒｃｅは、交換鍵ＩＤで指定されたリモート・アクセス用の交換鍵を用いて暗号鍵を算出し、この暗号鍵を用いて暗号化したコンテンツをＨＴＴＰレスポンス（ＨＴＴＰ ＧＥＴ ｒｅｓｐｏｎｓｅ）として返送する。

図２０には、ＲＡ−Ｓｏｕｒｃｅが実施する、コンテンツのリモート・アクセス（ＲＡ）出力管理１の処理手順をフローチャートの形式で示している。

まず、ＲＡ−Ｓｏｕｒｃｅは、ＨＴＴＰリクエストに含まれる交換鍵ＩＤで示される交換鍵がＤＴＣＰ−ＩＰ用か否かをチェックする（ステップＳ５１）。

ここで、ＨＴＴＰリクエストに含まれる交換鍵ＩＤで示される交換鍵がＤＴＣＰ−ＩＰ用でない場合には（ステップＳ５１のＮｏ）、ＲＡ−Ｓｏｕｒｃｅは、続いて、当該交換鍵がリモート・アクセス用か否かをチェックする（ステップＳ５２）。

当該交換鍵がリモート・アクセス用である場合には（ステップＳ５２のＹｅｓ）、ＲＡ−Ｓｏｕｒｃｅは、ＨＴＴＰリクエストに含まれるＵＲＬで指定されたコンテンツがリモート・アクセス可能か否かをチェックする（ステップＳ５３）。コンテンツがリモート・アクセス可能か否かは、例えば、ＲＡ−ｆｌａｇを用いて管理することができる（後述）。

そして、ＨＴＴＰリクエストに含まれる交換鍵ＩＤで示される交換鍵がＤＴＣＰ−ＩＰ用である場合（ステップＳ５１のＹｅｓ）、又は、ＨＴＴＰリクエストで指定されたコンテンツがリモート・アクセス可能であることが分かった場合には（ステップＳ５３のＹｅｓ）、ＲＡ−Ｓｏｕｒｃｅは、ＲＡ−ＳｉｎｋからのＨＴＴＰリクエスト（ＨＴＴＰ ＧＥＴ ｒｅｑｕｅｓｔ）への応答をＯＫとして（ステップＳ５４）、本処理ルーチンを終了する。

他方、ＨＴＴＰリクエストに含まれる交換鍵ＩＤで示される交換鍵がリモート・アクセス用でない場合（ステップＳ５２のＮｏ）、又は、ＨＴＴＰリクエストで指定されたコンテンツがリモート・アクセス不能の場合には（ステップＳ５３のＮｏ）、ＲＡ−Ｓｏｕｒｃｅは、ＲＡ−ＳｉｎｋからのＨＴＴＰリクエスト（ＨＴＴＰ ＧＥＴ ｒｅｑｕｅｓｔ）への応答をエラーとして（ステップＳ５５）、本処理ルーチンを終了する。

ここまでの説明では、通信システムが一対のＲＡ−ＳｏｕｒｃｅとＲＡ−Ｓｉｎｋだけで構成されることを想定していた。しかしながら、ＲＡ−ＳｏｕｒｃｅやＲＡ−Ｓｉｎｋは、それぞれさらに別の機器とデイジーチェーン形式で接続され、コンテンツを伝送する可能性がある。著作権保護されたコンテンツの伝送範囲は、本来、家庭内に留めるべきであり、コンテンツの受信と再送信が何段にもわたり繰り返し行なわれることは好ましくない。このため、コンテンツの受信と再送信を技術的に阻止することが必要である。本実施形態では、登録時におけるＲＴＴ及びＴＴＬの制限と、鍵の供給数制限をより厳密なものにするために、さらに幾つかのルールを設けている。

図１１に示すシステム構成例では、ＲＡ−Ｓｏｕｒｃｅ＃０と接続するＲＡ−Ｓｉｎｋ＃１が、さらにＲＡ−Ｓｏｕｒｃｅ＃１としての機能も備え、別の機器ＲＡ−Ｓｉｎｋ＃２と接続している。このような場合、ＲＡ−Ｓｉｎｋ＃１としてリモート・アクセスして受信したコンテンツを、ＲＡ−Ｓｏｕｒｃｅ＃１としてＲＡ−Ｓｉｎｋ＃２に再度リモート・アクセス出力することを禁止することによって、コンテンツ提供元であるＲＡ−Ｓｏｕｒｃｅ＃０の管理が及ばない所でリモート・アクセスされるのを防止するように運用する。

また、図１２に示すシステム構成例では、ＲＡ−Ｓｉｎｋ＃１が、リモート・アクセスによりＲＡ−Ｓｏｕｒｃｅ＃０に接続するとともに、Ｓｏｕｒｃｅ＃１としての機能も備えＤＴＣＰ−ＩＰにより別の機器Ｓｉｎｋ＃２に接続され、さらに、Ｓｉｎｋ＃２がＲＡ−Ｓｏｕｒｃｅ＃２としての機能も備えて別の機器ＲＡ−Ｓｉｎｋ＃３と接続している。ＲＡ−Ｓｉｎｋ＃１は、リモート・アクセスにより受信したコンテンツを、ＤＴＣＰ−ＩＰを通じて別の機器Ｓｉｎｋ＃２にローカル伝送することができる。ＤＴＣＰ−ＩＰによるローカル伝送は、著作権保護の仕組みに則ったものであり、問題はない。また、Ｓｉｎｋ＃２が受信したコンテンツを、ＲＡ−Ｓｏｕｒｃｅ＃２としてＲＡ−Ｓｉｎｋ＃３に再度リモート・アクセス出力することを禁止することによって、コンテンツ提供元であるＲＡ−Ｓｏｕｒｃｅ＃０の管理が及ばない所でリモート・アクセスされるのを防止するように運用する。

図１１、図１２を参照しながら説明したシステム運用は、要するに、機器はリモート・アクセス又はＤＴＣＰ−ＩＰでのローカル伝送によって受信したコンテンツのリモート・アクセス出力を禁止して、コンテンツ提供元の意図しないリモート・アクセスを防止することである。このような運用を実現する１つの方法として、コンテンツのリモート・アクセス出力並びにローカル伝送時に以下の（１）、（２）の規定を設けることが挙げられる。

（１）ＲＡ−Ｓｏｕｒｃｅは、コンテンツが「リモート・アクセス出力可能」という情報を伴わない限り、リモート・アクセス出力を行なわないようする。
（２）ＲＡ−Ｓｏｕｒｃｅ、Ｓｏｕｒｃｅは、リモート・アクセス又はＤＴＣＰ−ＩＰによるローカル伝送時に、リモート・アクセス出力の可否を表す情報を送らない。

図１３に示すシステム構成例では、Ｓｏｕｒｃｅ＃０とＤＴＣＰ−ＩＰにより接続するＳｉｎｋ＃１が、さらにＲＡ−Ｓｏｕｒｃｅ＃１としての機能も備え、別の機器ＲＡ−Ｓｉｎｋ＃２と接続している。Ｓｏｕｒｃｅ＃０は、ＤＴＣＰ−ＩＰを通じてのみ、Ｓｉｎｋ＃１にコンテンツをローカル伝送することができる。ＤＴＣＰ−ＩＰによるローカル伝送は、著作権保護の仕組みに則ったものであり、問題はない。ここで、上記（１）、（２）の制限規定が課されると、Ｓｉｎｋ＃１は、受信したコンテンツをＲＡ−Ｓｏｕｒｃｅ＃１としてＲＡ−Ｓｉｎｋ＃３に再度リモート・アクセス出力することができなくなる。

このケースでは、コンテンツ提供元の管理が及ばない所でのリモート・アクセス出力を防止することができるが、「リモート・アクセス出力可能」の情報を伴ったコンテンツであっても、一度もリモート・アクセス出力されないことになる。これに対し、本発明者らは、ＲＡ−Ｓｏｕｒｃｅ＃１が、Ｓｉｎｋ＃１としてＤＴＣＰ−ＩＰを通じてローカル伝送によりＳｏｕｒｃｅ＃０から受信したコンテンツを、Ｓｏｕｒｃｅ＃０に代わってさらに別の機器ＲＡ−Ｓｉｎｋ＃２にリモート・アクセス出力する（すなわち、リモート・アクセス出力を代行する）という運用は禁止する必要はない、と思料する。リモート・アクセス出力を代行するという運用は、ＤＥＰ−ＲＡ−ＡＫＥを行なって、Ｓｏｕｒｃｅ＃０が鍵をＳｉｎｋ＃１とだけ共有し、Ｓｉｎｋ＃１がその鍵を使ってコンテンツを暗号化伝送し、ＲＡ−Ｓｏｕｒｃｅ１からリモート・アクセス出力することで実現できる。

図１４には、ＤＥＰ−ＲＡ−ＡＫＥを行なってＳｏｕｒｃｅ＃０が鍵をＳｉｎｋ＃１とだけ共有する際の認証シーケンス例を示している。

この認証シーケンスは、Ｓｉｎｋ＃１がＳｏｕｒｃｅ＃０に対して鍵供給要求コマンド「ＤＥＰ＿ＲＡ＿ＩＮＩＴ」を送信することによって開始する。ＡＫＥ手続きのチャレンジ・レスポンス部分（Ｃｈａｌｌｅｎｇｅ−Ｒｅｓｐｏｎｓｅ ｐｏｒｔｉｏｎ ｏｆ ＡＫＥ）では、まず、Ｓｉｎｋ＃１から、Ｒｘ乱数とＲｘ証明書を含んだＲｘチャレンジが送信される。これに対しＳｏｕｒｃｅ＃０からは、Ｔｘ乱数及びＴｘ証明書を含んだＴｘチャレンジが返信される。以降、Ｓｏｕｒｃｅ＃０から、Ｒｘ乱数、Ｔｘメッセージ、Ｔｘ署名を含んだＲｘレスポンスが送信されるとともに、Ｓｉｎｋ＃１からはＴｘ乱数、Ｒｘメッセージ、Ｒｘ署名を含んだＴｘレスポンスが送信される。なお、「ＤＥＰ＿ＲＡ＿ＡＫＥ」を送信する代わりに、Ｒｘチャレンジとして送信する情報の中に、「ＤＥＰ＿ＲＡ＿ＡＫＥ」の送信に相当する情報、例えば「ＤＥＰ＿ＲＡ＿ＡＫＥ＿ｆｌａｇ」を含める方法も考えられる。

各チャレンジ・コマンドには、機器固有の識別情報であるＤｅｖｉｃｅ ＩＤが含まれている。但し、同チャレンジ・レスポンス部分の中では、ＳｉｎｋからＳｏｕｒｃｅへのレスポンスとして「ＲＥＳＰＯＮＳＥ２」が送られることがあるが、その場合は、機器固有の識別情報として、Ｄｅｖｉｃｅ ＩＤではなく、ＲＥＳＰＯＮＳＥ２に含まれるＩＤｕを使うことになる（同上）。

ＡＫＥ手続きはＤＴＣＰ−ＩＰを通じて実施されることから、ＴＴＬの制限が課される。また、また、ＲＴＴ保護プロトコル（Ｐｒｏｔｅｃｔｅｄ ＲＴＴ Ｐｒｏｔｏｃｏｌ）がさらに続く。リモート・アクセス出力代行の手続きＤＥＰ−ＲＡ−ＡＫＥは、ローカル環境内だけで行なわれるべきであり、現行のＤＴＣＰ−ＩＰにおけるＲＴＴ−ＡＫＥと同様に、ＲＴＴ及びＴＴＬが課される。

そして、上記の認証手順に成功すると、Ｓｏｕｒｃｅ＃０は、「ＤＥＰ＿ＲＡ−Ｓｉｎｋ Ｃｏｎｆｉｒｍａｔｉｏｎ」処理を実行する。この処理では、Ｓｏｕｒｃｅ＃０は、鍵をＳｉｎｋ＃１とだけ共有するとともに、他の機器とこのＤＥＰ−ＲＡ−ＡＫＥは実施できないようにする。そして、Ｓｏｕｒｃｅ＃０は、鍵をＳｉｎｋ＃１とだけ共有できることを確認できた場合に、リモート・アクセス出力代行用の交換鍵（Ｄ−ＲＡ＿Ｋ_x）とそのＩＤ（Ｄ−ＲＡ＿Ｋ_x＿ｌａｂｅｌ）と結果コードを、コマンド「ＤＥＰ−ＲＡ＿ＥＸＣＨＡＮＧＥ＿ＫＥＹ」でＳｉｎｋ＃１に渡す。

Ｓｏｕｒｃｅ＃０は、その後はＡＫＥによって共有した鍵を破棄するまで、他の機器とこのＤＥＰ−ＲＡ−ＡＫＥは実施できないようにする。また、Ｓｉｎｋ＃１側では、当該処理手順を通じて共有できたリモート・アクセス出力代行用の交換鍵を使って、「リモート・アクセス出力可能」の情報を伴ったままコンテンツを暗号化伝送する。そして、Ｓｉｎｋ＃１は、ＲＡ−Ｓｏｕｒｃｅ＃１として、ＲＡ−Ｓｉｎｋ＃２へ当該コンテンツをリモート・アクセス出力することができる。

図１５には、ＳｏｕｒｃｅがＳｉｎｋにコンテンツのリモート・アクセス出力の代行を認証する「ＤＥＰ＿ＲＡ−Ｓｉｎｋ Ｃｏｎｆｉｒｍａｔｉｏｎ」処理の手順をフローチャートの形式で示している。

Ｓｏｕｒｃｅは、まず、当該処理ルーチンを開始する以前の処理（Ｃｈａｌｌｅｎｇｅ−Ｒｅｓｐｏｎｓｅ ｐｏｒｔｉｏｎ ｏｆ ＡＫＥ、Ｐｒｏｔｅｃｔｅｄ ＲＴＴ Ｐｒｏｔｏｃｏｌ）を異常終了（ａｂｏｒｔ）したか否かをチェックする（ステップＳ２１）。

ここで、以前の処理を異常終了していた場合には（ステップＳ２１のＮｏ）、Ｓｏｕｒｃｅは、要求元のＳｉｎｋに対し、ＤＥＰ＿ＲＡ−Ｓｉｎｋ手続きを中断して（ステップＳ３０）、本処理ルーチンを終了する。

また、以前の処理を正常に終了していた場合には（ステップＳ２１のＹｅｓ）、Ｓｏｕｒｃｅは、ＲＥＳＰＯＮＳＥ２を受信したか否かをチェックする（ステップＳ２２）。そして、ＲＥＳＰＯＮＳＥ２を受信したときには（ステップＳ２２のＹｅｓ）、Ｓｏｕｒｃｅは、要求元のＳｉｎｋのＩＤをＩＤｕとする（ステップＳ２３）。また、ＲＥＳＰＯＮＳＥ２を受信していないときには（ステップＳ２２のＮｏ）、Ｓｏｕｒｃｅは、要求元のＳｉｎｋのＤｅｖｉｃｅ ＩＤをＩＤとする（ステップＳ２４）。

次いで、Ｓｏｕｒｃｅは、自分のＤＥＰ＿ＲＡレジストリーが空か否かをチェックする（ステップＳ２５）。ＤＥＰ＿ＲＡレジストリーは、コンテンツのリモート・アクセス出力を許可する唯一の機器のＩＤを保持するために記憶部１４内に用意されたレジストリーである。

ここで、ＤＥＰ＿ＲＡレジストリーが空であることを確認できたときには（ステップＳ２５のＹｅｓ）、Ｓｏｕｒｃｅは、ＤＥＰ＿ＲＡレジストリーに要求元のＳｉｎｋのＩＤを代入する（ステップＳ２６）。そして、Ｓｏｕｒｃｅは、リモート・アクセス出力代行用の交換鍵（Ｄ−ＲＡ＿Ｋ_x）とそのＩＤ（Ｄ−ＲＡ＿Ｋ_x＿ｌａｂｅｌ）と結果コードを、コマンド「ＤＥＰ−ＲＡ＿ＥＸＣＨＡＮＧＥ＿ＫＥＹ」でＳｉｎｋ＃１に渡して（ステップＳ２９）、本処理ルーチンを終了する。

また、ＤＥＰ＿ＲＡレジストリーが空でないときには（ステップＳ２５のＮｏ）、Ｓｏｕｒｃｅは、ＤＥＰ＿ＲＡレジストリーに保持されているＩＤが要求元のＳｉｎｋのＩＤと一致するかどうかをさらにチェックする（ステップＳ２７）。

ＤＥＰ＿ＲＡレジストリーに保持されているＩＤが要求元のＳｉｎｋのＩＤと一致する場合、すなわち、要求元のＳｉｎｋをコンテンツのリモート・アクセス出力を代行する機器として既に登録しているときには（ステップＳ２７のＹｅｓ）、Ｓｏｕｒｃｅは、リモート・アクセス出力代行用の交換鍵（Ｄ−ＲＡ＿Ｋ_x）とそのＩＤ（Ｄ−ＲＡ＿Ｋ_x＿ｌａｂｅｌ）と結果コードを、コマンド「ＤＥＰ−ＲＡ＿ＥＸＣＨＡＮＧＥ＿ＫＥＹ」でＳｉｎｋ＃１に渡して（ステップＳ２９）、本処理ルーチンを終了する。

他方、ＤＥＰ＿ＲＡレジストリーに保持されているＩＤが要求元のＳｉｎｋのＩＤと一致しないときには（ステップＳ２７のＮｏ）、Ｓｏｕｒｃｅは、「ｂｕｓｙ」である旨の結果コードを要求元のＳｉｎｋに通知して（ステップＳ２８）、本処理ルーチンを終了する。

Ｓｏｕｒｃｅは、図１５に示した処理手順を実行した後は、他の機器とこのＤＥＰ−ＲＡ−ＡＫＥを重複して実施することができない。また、Ｓｏｕｒｃｅは、ＤＥＰ−ＲＡ−ＡＫＥで共有したリモート・アクセス代行用の交換鍵（Ｄ−ＲＡ＿Ｋ_x）を破棄したときに、ＤＥＰ＿ＲＡレジストリーを空にすることで、他の機器とこのＤＥＰ−ＲＡ−ＡＫＥを実施できるようになる。

リモート・アクセス代行用の交換鍵の（Ｄ＿ＲＡ＿Ｋ_x）の破棄については、例えば、Ｓｉｎｋがリモート・アクセス代行を終了する時に、当該交換鍵の破棄を求めるコマンド（ＤＥＰ＿ＲＡ＿ＦＩＮＩＳＨ）を交換鍵のＩＤ（Ｄ＿ＲＡ＿Ｋ_x＿ｌａｂｅｌ）とともに送るという運用形態が考えられる。この破棄要求コマンドＤＥＰ＿ＲＡ＿ＦＩＮＩＳＨは、図１４中の「ＤＥＰ＿ＲＡ＿ＩＮＩＴ」、「ＤＥＰ＿ＲＡ＿ＥＸＣＨＡＮＧＥ＿ＫＥＹ」とともに、ＤＴＣＰ−ＩＰのＡＫＥ ｃｏｎｔｒｏｌ ｃｏｍｍａｎｄに、リモート・アクセス用のコマンドとして追加するものとする。

図２１には、（ＲＡ−Ｓｏｕｒｃｅの機能を備えた）ＳｉｎｋがＳｏｕｒｃｅに対してリモート・アクセスを代行するコンテンツを要求する際の動作シーケンスを示している。但し、同図では、ＳｉｎｋからＳｏｕｒｃｅに対してＨＴＴＰプロトコルに従ってコンテンツが要求され、ダウンロード形式でコンテンツが伝送されるものとする。

Ｓｉｎｋは、図１４に示したＤＥＰ＿ＲＡ−ＡＫＥ手続きによってリモート・アクセス用の交換鍵（Ｄ＿ＲＡ＿Ｋ_x）とそのＩＤ（Ｄ＿ＲＡ＿Ｋ_x＿ｌａｂｅｌ）を取得した後、ＨＴＴＰ ＧＥＴメソッドを用いたＨＴＴＰリクエスト（ＨＴＴＰ ＧＥＴ ｒｅｑｕｅｓｔ）により、Ｓｏｕｒｃｅに対してコンテンツ・データをリクエストする。このリクエストの際には、コンテンツのＵＲＬとともに、リモート・アクセス代行用の交換鍵のＩＤ（Ｄ＿ＲＡ＿Ｋ_x＿ｌａｂｅｌ）を送る。ここで、ＳｉｎｋからＳｏｕｒｃｅに交換鍵のＩＤ（Ｄ＿ＲＡ＿Ｋ_x＿ｌａｂｅｌ）を送るためのヘッダーフィールドを定義する。

Ｓｏｕｒｃｅは、コンテンツのリモート・アクセス出力代行のリクエストを受けると、要求されたコンテンツがリモート・アクセス出力代行可能か否かをチェックするための「コンテンツのリモート・アクセス代行（ＤＥＰ−ＲＡ）出力管理１」の処理を実行する。そして、リクエストで指定されたＵＲＬのコンテンツがリモート・アクセス出力代行可能であることが確認できたなら、Ｓｏｕｒｃｅは、交換鍵ＩＤで指定されたリモート・アクセス代行用の交換鍵を用いて暗号鍵を算出し、この暗号鍵を用いて暗号化したコンテンツを、「リモート・アクセス出力可能」の情報を伴ったまま、ＨＴＴＰレスポンス（ＨＴＴＰ ＧＥＴ ｒｅｓｐｏｎｓｅ）として返送する。

図２２には、リモート・アクセス出力代行を要求されたＳｏｕｒｃｅが実施する、コンテンツのリモート・アクセス出力代行管理の処理手順をフローチャートの形式で示している。

まず、Ｓｏｕｒｃｅは、ＨＴＴＰリクエストに含まれる交換鍵ＩＤで示される交換鍵がＤＴＣＰ−ＩＰ用か否かをチェックする（ステップＳ６１）。

ここで、ＨＴＴＰリクエストに含まれる交換鍵ＩＤで示される交換鍵がＤＴＣＰ−ＩＰ用でない場合には（ステップＳ６１のＮｏ）、ＲＡ−Ｓｏｕｒｃｅは、続いて、当該交換鍵がリモート・アクセス代行用か否かをチェックする（ステップＳ６２）。

当該交換鍵がリモート・アクセス代行用である場合には（ステップＳ６２のＹｅｓ）、Ｓｏｕｒｃｅは、ＨＴＴＰリクエストに含まれるＵＲＬで指定されたコンテンツがリモート・アクセス可能か否かをチェックする（ステップＳ６３）。コンテンツがリモート・アクセス可能か否かは、例えば、ＲＡ−ｆｌａｇを用いて管理することができる（後述）。

そして、ＨＴＴＰリクエストに含まれる交換鍵ＩＤで示される交換鍵がＤＴＣＰ−ＩＰ用である場合（ステップＳ６１のＹｅｓ）、又は、ＨＴＴＰリクエストで指定されたコンテンツがリモート・アクセス可能であることが分かった場合には（ステップＳ６３のＹｅｓ）、Ｓｏｕｒｃｅは、ＳｉｎｋからのＨＴＴＰリクエスト（ＨＴＴＰ ＧＥＴ ｒｅｑｕｅｓｔ）への応答をＯＫとする（ステップＳ６４）。

他方、ＨＴＴＰリクエストに含まれる交換鍵ＩＤで示される交換鍵がリモート・アクセス代行用でない場合（ステップＳ６２のＮｏ）、又は、ＨＴＴＰリクエストで指定されたコンテンツがリモート・アクセス不能の場合には（ステップＳ６３のＮｏ）、Ｓｏｕｒｃｅは、ＳｉｎｋからのＨＴＴＰリクエスト（ＨＴＴＰ ＧＥＴ ｒｅｑｕｅｓｔ）への応答をエラーとする（ステップＳ５５）。

なお、図１３に示したシステム構成において、リモート・アクセス不可のコンテンツをＳｏｕｒｃｅ＃０からＳｉｎｋ＃１に伝送したい場合には、現行のＤＴＣＰ−ＩＰに従って行なうことが考えられるが、以下のようにすることで、リモート・アクセス代行用の交換鍵（Ｄ＿ＲＡ＿Ｋ_ｘ）を用いた伝送でリモート・アクセス可能及び不可の双方のコンテンツを扱えるようにすることもできる。

Ｓｏｕｒｃｅ＃０は、ＤＥＰ−ＲＡ−ＡＫＥで共有した交換鍵を使うコンテンツ伝送の際には、リモート・アクセスの可否情報（ＲＡ−ｆｌａｇ）を伴うことで、ＲＡ−Ｓｏｕｒｃｅ＃１は、受信したコンテンツをリモート・アクセス出力できるかどうかを判別できるようにする。

なお、ＲＡ−ｆｌａｇは、コンテンツ・データとともに暗号化したり、ＲＡ−ｆｌａｇの値を暗号鍵の計算をする関数に入力にして、暗号鍵Ｋ_cの値に反映させたりする方法や（図２３を参照のこと）、ＲＡ−ｆｌａｇを含む、平文で伝送する情報を、その情報と暗号鍵をハッシュ関数で処理して求めた署名データ（ｓｉｇｎａｔｕｒｅ）とともに送ることで（図２４を参照のこと）、改竄を防ぐことができる。

また、ＲＡ−ｆｌａｇをコンテンツ・データとともに暗号化する場合、その格納先としては、ＤＴＣＰ−ＩＰで運用されているＤＴＣＰ＿ｄｅｓｃｒｉｐｔｏｒやＰＣＰ−ＵＲのｒｅｓｅｒｖｅｄとなっているビットや（図２５、図２６を参照のこと）、あるいは新たなコンテンツ関連情報のコンテナを設けてそこに配置することなどが考えられる。

なお、上記の説明では、図１３に示したシステム構成において、Ｓｉｎｋ＃１は、Ｓｏｕｒｃｅ＃０からのコンテンツを記録せずに、ＲＡ−Ｓｏｕｒｃｅ＃１経由でリモート・アクセス出力することを想定している。変形例として、コンテンツをＳｏｕｒｃｅ＃０からＳｉｎｋ＃１にＭＯＶＥする場合も、ＤＰ−ＲＡ−ＡＫＥで共有した鍵を使ったコンテンツの伝送時にリモート・アクセスの可否情報（ＲＡ−ｆｌａｇ）を伴うことで、ＲＡ−Ｓｏｕｒｃｅ＃１は、受信したコンテンツをリモート・アクセス出力できるかどうかを判別することができる。ここで、ＤＴＣＰ−ＩＰで言うＭＯＶＥ機能は、Ｓｉｎｋは受信したコンテンツをＮｏＭｏｒｅ Ｃｏｐｉｅｓとして符号化して記録すること、及び、Ｓｏｕｒｃｅ側では伝送した後のコンテンツを消去又は利用不能にするという条件の下で、暗号化コンテンツをＳｏｕｒｃｅからＳｉｎｋへ伝送することを意味する。

ここまでは、ＲＡ−Ｓｏｕｒｃｅを利用できるＲＡ−Ｓｉｎｋの台数を制限する方法について説明してきた。これに対し、コンテンツ・オーナーの中には、自分が提供するコンテンツを同時にリモート・アクセスを利用できる数を制限することで不正の脅威を小さくしたいと要望することも考えられる。例えば、記録禁止の有料番組を受信機が直ちにリモート・アクセス出力する場合などである。

コンテンツのリモート・アクセス利用数を制限する方法として、ＲＡ−ＡＫＥで共有する鍵をＲＡ−Ｓｉｎｋ毎に変えるとともに、各ＲＡ−Ｓｉｎｋにどのコンテンツをリモート・アクセスしているかを管理する方法が挙げられる。そして、ＲＡ−Ｓｏｕｒｃｅは、所定の数以上のＲＡ−Ｓｉｎｋに同じコンテンツを同時に伝送しないようにすればよい。

ＲＡ−Ｓｏｕｒｃｅは、コンテンツを同時にリモート・アクセスを利用できる数を制限するために、例えば以下に示すような管理テーブルを用いる。

上記の管理テーブルでは、ＲＡ−Ｓｉｎｋに伝送中のコンテンツのＵＲＬとＲＡ−Ｓｉｎｋと１対１に対応する交換鍵ＩＤ（ＲＡ＿Ｋ_x＿ｌａｂｅｌ）の組み合わせが各エントリーで管理されている。この管理テーブル中で、ＵＲＬのみが一致し、交換鍵ＩＤが相違するエントリーは、１つのコンテンツを異なるＲＡ−Ｓｉｎｋが利用していることを表す。

ＲＡ−Ｓｏｕｒｃｅは、新たにコンテンツ伝送を開始する前に、この管理テーブルを参照して、同じコンテンツが所定の数を超えるＲＡ−Ｓｉｎｋに送られないように制御する。コンテンツの伝送開始が許容されるときには、ＲＡ−Ｓｏｕｒｃｅは、ＵＲＬと交換鍵ＩＤの組み合わせからなるエントリーを管理テーブルに追加する。

図１６には、同じコンテンツを同時に伝送するＲＡ−Ｓｉｎｋの台数が制限される場合の、ＲＡ−ＳｉｎｋがＲＡ−Ｓｏｕｒｃｅにコンテンツを要求する際の動作シーケンスを示している。

ＲＡ−Ｓｉｎｋは、図９に示したＲＡ−ＡＫＥ手続きによってリモート・アクセス用の交換鍵（ＲＡ＿Ｋ_x）とそのＩＤ（ＲＡ＿Ｋ_x＿ｌａｂｅｌ）を取得した後、ＨＴＴＰ ＧＥＴメソッドを用いたＨＴＴＰリクエスト（ＨＴＴＰ ＧＥＴ ｒｅｑｕｅｓｔ）により、ＲＡ−Ｓｏｕｒｃｅにコンテンツ・データをリクエストする。このリクエストの際には、コンテンツのＵＲＬとともに、リモート・アクセス出力用の交換鍵のＩＤ（ＲＡ＿Ｋ_x＿ｌａｂｅｌ）を送る。ここで、ＲＡ−ＳｉｎｋからＲＡ−Ｓｏｕｒｃｅに交換鍵のＩＤ（ＲＡ＿Ｋ_x＿ｌａｂｅｌ）を送るためのヘッダーフィールドを定義する。

ＲＡ−Ｓｏｕｒｃｅは、コンテンツ・データのリクエストを受けると、要求されたコンテンツを同時にリモート・アクセス出力するＲＡ−Ｓｉｎｋの台数をチェックするための「同一コンテンツのリモート・アクセス（ＲＡ）出力管理２」の処理を実行する。そして、指定されたＵＲＬのコンテンツを同時に伝送するＲＡ−Ｓｉｎｋの台数がまだ制限数に達していない場合は、ＲＡ−Ｓｏｕｒｃｅは、交換鍵ＩＤで指定されたリモート・アクセス用の交換鍵を用いて暗号鍵を算出し、この暗号鍵を用いて暗号化したコンテンツをＨＴＴＰレスポンス（ＨＴＴＰ ＧＥＴ ｒｅｓｐｏｎｓｅ）として返送する。また、ＲＡ−Ｓｏｕｒｃｅは、上記の管理テーブルにエントリーを追加する。

なお、ＲＡ−Ｓｏｕｒｃｅがリモート・アクセス用の鍵を破棄したときに、破棄した鍵に対応するエントリーを上記のテーブルから消去する。なお、ＲＡ−Ｓｉｎｋがリモート・アクセスを終了した時で、上記の管理テーブルからエントリーの削除を求めるコマンド（ＲＡ＿ＦＩＮＩＳＨ）を、リモート・アクセス用の交換鍵のＩＤ（ＲＡ＿Ｋ_x＿ｌａｂｅｌ）とともに送るようにしてもよい（同上）。

図１７には、図１６に示した動作シーケンスにおいて、ＲＡ−Ｓｏｕｒｃｅがコンテンツ・データのリクエストに応じて実行する、同一コンテンツの出力数を管理するための処理手順をフローチャートの形式で示している。

まず、ＲＡ−Ｓｏｕｒｃｅは、ＨＴＴＰリクエストに含まれる交換鍵ＩＤで示される交換鍵がＤＴＣＰ−ＩＰ用か否かをチェックする（ステップＳ３１）。

ここで、ＨＴＴＰリクエストに含まれる交換鍵ＩＤで示される交換鍵がＤＴＣＰ−ＩＰ用である場合には（ステップＳ３１のＹｅｓ）、ＲＡ−Ｓｏｕｒｃｅは、ＲＡ−ＳｉｎｋからのＨＴＴＰリクエスト（ＨＴＴＰ ＧＥＴ ｒｅｑｕｅｓｔ）への応答をＯＫとして（ステップＳ３８）、本処理ルーチンを終了する。

また、ＨＴＴＰリクエストに含まれる交換鍵ＩＤで示される交換鍵がＤＴＣＰ−ＩＰ用でない場合には（ステップＳ３１のＮｏ）、ＲＡ−Ｓｏｕｒｃｅは、続いて、当該交換鍵がリモート・アクセス用か否かをチェックする（ステップＳ３２）。

当該交換鍵がリモート・アクセス用である場合には（ステップＳ３２のＹｅｓ）、ＲＡ−Ｓｏｕｒｃｅは、ＨＴＴＰリクエストに含まれるＵＲＬで指定されたコンテンツがリモート・アクセス可能か否かをチェックする（ステップＳ３３）。コンテンツがリモート・アクセス可能か否かは、例えば、ＲＡ−ｆｌａｇを用いて管理することができる（後述）。

ＨＴＴＰリクエストに含まれる交換鍵ＩＤで示される交換鍵がリモート・アクセス用でない場合（ステップＳ３２のＮｏ）、又は、ＨＴＴＰリクエストで指定されたコンテンツがリモート・アクセス不能の場合には（ステップＳ３３のＮｏ）、ＲＡ−Ｓｏｕｒｃｅは、ＲＡ−ＳｉｎｋからのＨＴＴＰリクエスト（ＨＴＴＰ ＧＥＴ ｒｅｑｕｅｓｔ）への応答をエラーとして（ステップＳ３９）、本処理ルーチンを終了する。

また、ＨＴＴＰリクエストで指定されたコンテンツがリモート・アクセス可能であることが分かった場合には（ステップＳ３３のＹｅｓ）、ＲＡ−Ｓｏｕｒｃｅは、コンテンツ・データのリクエスト中に含まれるＵＲＬと交換鍵ＩＤ（ＲＡ＿Ｋ_x＿ｌａｂｅｌ）の組み合わせと同じエントリーが管理テーブル中にあるかどうかをチェックする（ステップＳ３４）。

ここで、コンテンツ・データのリクエスト中に含まれるＵＲＬと交換鍵ＩＤ（ＲＡ＿Ｋ_x＿ｌａｂｅｌ）の組み合わせと同じエントリーが管理テーブル中にあるときには（ステップＳ３４のＹｅｓ）、当該コンテンツが要求元のＲＡ−Ｓｉｎｋに利用されても利用数の制限を超えることはない。そこで、ＲＡ−Ｓｏｕｒｃｅは、要求元のＲＡ−ＳｉｎｋからのＧＥＴ ｒｅｑｕｅｓｔに対する応答を「ＯＫ」として（ステップＳ３８）、本処理ルーチンを終了する。

他方、コンテンツ・データのリクエスト中に含まれるＵＲＬと交換鍵ＩＤ（ＲＡ＿Ｋ_x＿ｌａｂｅｌ）の組み合わせと同じエントリーが管理テーブル中にないときには、ＲＡ−Ｓｏｕｒｃｅは、続いて、ＵＲＬが同じエントリーが管理テーブル中にあるかどうかをチェックする（ステップＳ３５）。

コンテンツ・データのリクエスト中に含まれるＵＲＬが同じであるエントリーが管理テーブル中にないときには（ステップＳ３５のＮｏ）、当該コンテンツが要求元のＲＡ−Ｓｉｎｋに利用されても利用数の制限を超えることはない。そこで、ＲＡ−Ｓｏｕｒｃｅは、コンテンツ・データのリクエストで指定されたＵＲＬと交換鍵ＩＤ（ＲＡ＿Ｋ_x＿ｌａｂｅｌ）の組み合わせからなるエントリーを管理テーブルに追加する（ステップＳ３７）。そして、ＲＡ−Ｓｏｕｒｃｅは、要求元のＲＡ−ＳｉｎｋからのＧＥＴ ｒｅｑｕｅｓｔに対する応答を「ＯＫ」として（ステップＳ３８）、本処理ルーチンを終了する。

また、コンテンツ・データのリクエスト中に含まれるＵＲＬと同じであるエントリーが管理テーブル中にあるときには（ステップＳ３５のＹｅｓ）、リクエストに応答して要求元のＲＡ−Ｓｉｎｋにコンテンツを提供すると、利用数の制限を超えるおそれがある。そこで、ＲＡ−Ｓｏｕｒｃｅは、管理テーブル中で、コンテンツ・データのリクエスト中に含まれるＵＲＬと同じであるエントリーの数が上限値未満か否かをさらにチェックする（ステップＳ３６）。

管理テーブル中で、コンテンツ・データのリクエスト中に含まれるＵＲＬと同じであるエントリーの数が上限値未満であれば（ステップＳ３６のＹｅｓ）、当該コンテンツが要求元のＲＡ−Ｓｉｎｋに利用されても利用数の制限を超えることはない。そこで、ＲＡ−Ｓｏｕｒｃｅは、コンテンツ・データのリクエストで指定されたＵＲＬと交換鍵ＩＤ（ＲＡ＿Ｋ_x＿ｌａｂｅｌ）の組み合わせからなるエントリーを管理テーブルに追加し（ステップＳ３７）、要求元のＲＡ−ＳｉｎｋからのＧＥＴ ｒｅｑｕｅｓｔに対する応答を「ＯＫ」として（ステップＳ３８）、本処理ルーチンを終了する。

管理テーブル中で、コンテンツ・データのリクエスト中に含まれるＵＲＬと同じであるエントリーの数が上限値に達していると（ステップＳ３６のＮｏ）、当該コンテンツが要求元のＲＡ−Ｓｉｎｋに利用されても利用数の制限を超えてしまう。このため、ＲＡ−Ｓｏｕｒｃｅは、要求元のＲＡ−ＳｉｎｋからのＧＥＴ ｒｅｑｕｅｓｔに対する応答を「ＥＲＲＯＲ」として（ステップＳ３９）、本処理ルーチンを終了する。

ここまでの説明では、「リモート・アクセス出力可能」という情報を伴わないコンテンツはリモート・アクセスできないことが前提であった。しかしながら、現実には、記録可能なコンテンツであれば、ＤＶＤやメモリカードなどの可搬型の記録媒体（ｒｅｍｏｖａｂｌｅ ｍｅｄｉａ）に書き込むことで、コンテンツを家庭の外に持ち出して、別の機器で利用することができる。よって、記録可能なコンテンツについては、「リモート・アクセス出力可能」という情報を伴わなくても、記録した後はリモート・アクセス可能とする運用も考えられる。

但し、ＲＡ−Ｓｉｎｋで受信したコンテンツの書き込み先が可搬型記録媒体の場合は、コンテンツを最後まで書き込んだ後に持ち出せるということで、リモート・アクセスについてもコンテンツの記録中や、記録開始時点から所定の時間が経過するまでリモート・アクセスの抑制が求められるかもしれない。

図１８には、ＲＡ−Ｓｏｕｒｃｅとして動作する機器がコンテンツを記録又はＭＯＶＥ機能で取り込むための処理手順をフローチャートの形式で示している。

ＲＡ−Ｓｏｕｒｃｅは、まず、取り込んだコンテンツが「リモート・アクセス出力可否」に関する情報を伴っているかどうかをチェックする（ステップＳ４１）。

ここで、取り込むコンテンツが取り込んだコンテンツが「リモート・アクセス出力可否」に関する情報を伴っているときには（ステップＳ４１のＹｅｓ）、さらに、当該情報の指定内容が「リモート・アクセス出力可」となっているか否かをチェックする（ステップＳ４２）。

ここで、「リモート・アクセス出力可否」に関する情報の指定内容が「リモート・アクセス出力可」となっていないときには（ステップＳ４２のＮｏ）、ＲＡ−Ｓｏｕｒｃｅは、その情報に従って、リモート・アクセス不可期限を「無限」に設定する（ステップＳ４３）。

次いで、ＲＡ−Ｓｏｕｒｃｅは、取り込んだコンテンツのリモート・アクセス出力の可否を示すＲＡ−ｆｌａｇを設定して（ステップＳ４４）、本処理ルーチンを終了する。

一方、コンテンツが「リモート・アクセス出力可能」という情報を伴っていないときには（ステップＳ４５のＮｏ）、ＲＡ−Ｓｏｕｒｃｅは、基準となる時点の時刻に所定の期間を加えた結果の値Ｔを求め（ステップＳ４６）、Ｔをそのコンテンツのリモート・アクセス不可期限とするとともに（ステップＳ４７）、その期限まで当該コンテンツのリモート・アクセス出力を禁止する設定でＲＡ−ｆｌａｇを「不可」に初期化して（ステップＳ４８）、本処理ルーチンを終了する。

ここで、基準点時刻とは、例えば放送コンテンツであれば番組の先頭が放送されたタイミングの時刻で、それに加える所定の時間としては、番組情報としてコンテンツとともに送られる番組の時間長などが考えられる。記録メディア中のコンテンツなど、いつ記録されたものか不明なものについては、コンテンツをＭＯＶＥ機能により取り込もうとした時点の時刻にコンテンツの再生長を加えた値をＴとすることが考えられる。

なお、図１８では省略しているが、コンテンツが「リモート・アクセス出力不可」という情報を伴うときには（ステップＳ４２で分かったときには）、ＲＡ−Ｓｏｕｒｃｅは、ＲＡ−ｆｌａｇを不可とするとともに、Ｔを「無限」に設定する。

図１８に示した処理手順を経て、ＲＡ−ｆｌａｇが「不可」と設定されたコンテンツで、Ｔが「無限」に設定でないものは、指定されたタイミング以降は、リモート・アクセス可能なものとして扱うことができる。

図２７には、ＲＡ−Ｓｏｕｒｃｅが、コンテンツに設定されたＲＡ−ｆｌａｇ及びＴを更新するための処理手順をフローチャートの形式で示している。

ＲＡ−Ｓｏｕｒｃｅは、まず、コンテンツのＲＡ−ｆｌａｇが「可」に設定されているか否かをチェックする（ステップＳ７１）。ここで、コンテンツのＲＡ−ｆｌａｇが既に「可」に設定されているときには（ステップＳ７１のＹｅｓ）、後続の処理をすべてスキップして、本処理ルーチンを終了する。

コンテンツのＲＡ−ｆｌａｇが「可」に設定されていないときには（ステップＳ７１のＮｏ）、ＲＡ−Ｓｏｕｒｃｅは、次いで、コンテンツのリモート・アクセス不可期限が「無限」に設定されているか否かをチェックする（ステップＳ７２）。ここで、コンテンツのリモート・アクセス不可期限が「無限」に設定されているときには（ステップＳ７２のＹｅｓ）、後続の処理をすべてスキップして、本処理ルーチンを終了する。

コンテンツのリモート・アクセス不可期限が「無限」に設定されていないときには（ステップＳ７２のＮｏ）、ＲＡ−Ｓｏｕｒｃｅは、次いで、コンテンツのリモート・アクセス不可期限が現時点より未来か否かをチェックする（ステップＳ７３）。

コンテンツのリモート・アクセス不可期限が現時点より未来であれば（ステップＳ７３のＹｅｓ）、そのまま本処理ルーチンを終了する。また、コンテンツのリモート・アクセス不可期限が現時点より未来でない、すなわちリモート・アクセス不可期限に既に到達しているときには（ステップＳ７３のＮｏ）、ＲＡ−Ｓｏｕｒｃｅは、コンテンツのＲＡ−ｆｌａｇを「可」に更新して（ステップＳ７４）、本処理ルーチンを終了する。

ＲＡ−Ｓｏｕｒｃｅが図２７に示した処理手順を定期的に実行することで、コンテンツのＲＡ−ｆｌａｇを「可」に更新することができる。当該処理手順の具体的な実施タイミングとして、例えばコンテンツ・リスト（図示しない）を外部に提示するときなどが挙げられる。

ＤＴＣＰ−ＩＰではコンテンツは家庭内ネットワークでの利用だけが可能であった。これに対し、本実施形態に係る通信システムでは、不正利用の可能性を絞り込むことで、家庭の外から、すなわちリモート・アクセスによるコンテンツの利用が可能となる。

また、本実施形態に係る通信システムでは、ＲＴＴ、ＴＴＬ、コンテンツを利用するＲＡ−Ｓｉｎｋの台数、交換鍵の供給数など、リモート・アクセスを制限する複数の制限値を調整することで、システムを柔軟に構築することができる。

また、本実施形態に係る通信システムによれば、ＤＴＣＰ−ＩＰの通信プロトコルをベースにして構築しつつ、ＲＴＴやＴＴＬの制限を外して、リモート・アクセスによるコンテンツの利用を実現することができる。

本発明に係る通信システムに置いて、ＲＡ−Ｓｏｕｒｃｅに相当するコンテンツ提供装置の機能的構成については、図３を参照しながら既に説明した。例えば、パーソナル・コンピューターや、レコーダー、その他のさまざまな情報機器がコンテンツ提供装置として機能することができる。

図２９には、コンテンツ提供装置に適用されるパーソナル・コンピューター８０の構成例を示している。図示のパーソナル・コンピューター８０は、ＣＰＵ８１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）８２、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）８３、ディスプレイ８４、スピーカー８５、例えばＨＤＤ（Ｈａｒｄ Ｄｉｓｃ Ｄｒｉｖｅ）やＳＤＤ（Ｓｕｐｅｒ Ｄｅｎｓｉｔｙ Ｄｉｓｃ）などの大容量情報記憶装置８６、Ｉ／Ｏインターフェース８７などの回路コンポーネントを備え、これらの回路コンポーネントがバス８８を介して相互接続されている。

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

ＲＡＭ８２には、コンテンツの暗号及び復号に関する機能がロードされる。例えば、ＤＴＣＰ−ＩＰ機能を実行するためのプログラム、及び、ＲＡ−ＡＫＥ処理を実行するためのプログラムがＲＡＭ８２にロードされる。また、ＲＡ−ＳｏｕｒｃｅにＲＡ−Ｓｉｎｋを登録する際の認証シーケンス（図７を参照のこと）を実行するためのプログラムは、ＲＡ−ＡＫＥ処理を実行するためのプログラムの一部として、このＲＡＭ８２にロードされ、ＣＰＵ８１が実行する。

ＥＥＰＲＯＭ８３は、書き換えが可能な不揮発性記憶装置であり、設定情報などが記憶される。パーソナル・コンピューター８０がＲＡ−Ｓｏｕｒｃｅすなわちコンテンツ提供装置として動作する場合、ＲＡ−ｓｉｎｋとなる端末ＩＤがＥＥＰＲＯＭ８３に記憶される。

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

この手続きに成功すると、ＣＰＵ８１は、ＲＡＭ８２に記憶されたプログラムに従って、ＲＡ−ｓｉｎｋの端末ＩＤを、ＥＥＰＲＯＭ８３に記憶する。

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

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

また、図３０には、コンテンツ提供装置に適用されるレコーダー９０の構成例を示している。図示のレコーダー９０は、システム・チップ９１、大容量記憶装置９２、ＲＡＭ９３、ＥＥＰＲＯＭ９４、無線ＬＡＮチップ９５を備えている。

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

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

コプロセッサー９１ｂは、補助演算装置であり、主に動画像の圧縮又は復号処理を実行する。例えば、Ｈ２６４、ＶＣ１、ＭＰＥＧ２、ＪＰＥＧなどのアルゴリズムを実行する。

大容量記憶装置９２は、例えばＨＤＤやＳＤＤなどであるが、コンテンツ利用装置に提供するコンテンツを記憶する。

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

ＥＥＰＲＯＭ９４は、書き換えが可能な不揮発性記憶装置であり、設定情報などが記憶される。レコーダー９０がＲＡ−Ｓｏｕｒｃｅすなわちコンテンツ提供装置として動作する場合、ＲＡ−ｓｉｎｋとなる端末ＩＤがＥＥＰＲＯＭ９４に記憶される。

レコーダー９０上では、ＲＡ−ｓｉｎｋ（例えば、モバイル端末）から、このＲＡ−ｓｉｎｋをＲＡ−ＡＫＥ手続きが可能な端末として登録するよう要求を受けると、ＣＰＵ９１ａが、ＲＡＭ９３からＤＴＣＰ−ＩＰのＡＫＥ処理が記述されたプログラムを読み出し、ＲＡ−ｓｉｎｋとの間でＡＫＥ手続きを実行する。

この手続きに成功すると、ＣＰＵ９１ａは、ＲＡＭ９３に記憶されたプログラムに従って、ＲＡ−ｓｉｎｋの端末ＩＤを、ＥＥＰＲＯＭ９４に記憶する。

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

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

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

本発明の適用例として、ＤＴＣＰ−ＩＰが適用されるホームネットワーク上のサーバーに、家庭外のクライアントからリモート・アクセスしてコンテンツを利用する通信システムを挙げることができるが、本発明の要旨はこれに限定されない。著作権やその他の目的で保護が必要となるコンテンツを、往復遅延時間（ＲＴＴ）やＩＰルーターのホップ回数（ＴＴＬ）などの制限を超えつつ、ＷＡＮなどの外部ネットワークを経由したリモート・アクセスを通じてコンテンツを伝送する他のあらゆるコンテンツ伝送システムに、同様に本発明を適用することができる。

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

１０…コンテンツ提供装置（ＲＡ−ｓｏｕｒｃｅ）
１１…ＣＰＵ
１２…コンテンツ受信／再生部
１３…通信部
１４…記憶部
１５…タイマー
２０…コンテンツ利用装置（ＲＡ−ｓｉｎｋ）
２１…ＣＰＵ
２２…通信部
２３…コンテンツ出力部
２４…記憶部
３０、３１…ルーター
４０、４１…モデム
５０…ＷＡＮ
６０…ＩＡＳサービス
７０…ＤＤＮＳサービス
８０…パーソナル・コンピューター
８１…ＣＰＵ
８２…ＲＡＭ
８３…ＥＥＰＲＯＭ
８４…ディスプレイ
８５…スピーカー
８６…大容量情報記憶装置
８７…Ｉ／Ｏインターフェース
８８…バス
９０…レコーダー
９１…システム・チップ
９１ａ…ＣＰＵ、９１ｂ…コプロセッサー
９１ｃ…インターフェース機能部、９１ｄ…バス
９２…大容量記憶装置
９２…ＲＡＭ
９４…ＥＥＰＲＯＭ
９５…無線ＬＡＮチップ

Claims (2)

1. リモート・アクセスによるコンテンツの提供を可能にする通信システムであって、前記通信システムは、コンテンツ利用装置とコンテンツ提供装置を含み、
   前記コンテンツ提供装置は、
   コンテンツを要求するコンテンツ利用装置を、コマンドの往復遅延時間に関する制限を課した第１の相互認証手続きを経て、登録できるコンテンツ利用装置の台数を第１の所定台数までに制限して登録する登録手段と、
   コンテンツ利用装置からコンテンツ利用要求があるとき、コマンドの往復遅延時間に関する制限を課さない第２の相互認証手続きを経て、前記登録手段に登録されたコンテンツ利用装置に対し、交換鍵と前記交換鍵から生成される暗号鍵を用いて暗号化された前記要求されたコンテンツを伝送する伝送手段と、
   前記登録手段に登録されたコンテンツ利用装置のうち、コマンドの往復遅延時間に関する制限を課さない前記第２の相互認証手続きを通じて交換鍵を配信できる前記コンテンツ利用装置の台数を第２の所定台数までに制限する管理手段と、
   を具備し、
   前記コンテンツ利用装置は、
   前記コンテンツ提供装置の前記第１の相互認証手続きを経て、前記コンテンツ提供装置にコンテンツ利用装置登録をする登録手続手段と、
   前記コンテンツ提供装置に対してコンテンツを要求し、前記コンテンツ提供装置の前記第２の相互認証手続きを経て、前記コンテンツを受信するコンテンツ受信手段と、
   を具備し、
   前記コンテンツ提供装置の前記登録手段により制限される前記第１の所定台数は、２台以上であり、前記管理手段により制限される前記第２の所定台数よりも多い、
   通信システム。
2. コンテンツ提供装置とコンテンツ利用装置の間でリモート・アクセスによるコンテンツの利用を可能にする通信方法において、
   前記コンテンツ提供装置は、
   コンテンツを要求するコンテンツ利用装置を、コマンドの往復遅延時間に関する制限を課した第１の相互認証手続きを経て、登録できるコンテンツ利用装置の台数を第１の所定台数までに制限して登録手段に登録する登録ステップと、
   コンテンツ利用装置からコンテンツ利用要求があるとき、コマンドの往復遅延時間に関する制限を課さない第２の相互認証手続きを経て、前記登録手段に登録されたコンテンツ利用装置に対し、交換鍵と前記交換鍵から生成される暗号鍵を用いて暗号化された前記要求されたコンテンツを伝送する伝送ステップと、
   前記登録手段に登録された正当なコンテンツ利用装置のうち、前記伝送ステップにおいて前記第２の相互認証手続きを通じて交換鍵を配信できる前記コンテンツ利用装置の台数を第２の所定台数までに制限する管理ステップと、
   を有し、
   前記コンテンツ利用装置は、
   前記コンテンツ提供装置の前記第１の相互認証手続きを経て、前記コンテンツ提供装置にコンテンツ利用装置登録をする登録手続ステップと、
   前記コンテンツ提供装置に対してコンテンツを要求し、前記コンテンツ提供装置の前記第２の相互認証手続きを経て、前記コンテンツを受信するコンテンツ受信ステップと、
   を有し、
   前記登録ステップにより制限される前記第１の所定台数は、２台以上であり、前記管理手段により制限される前記第２の所定台数よりも多い、
   通信方法。

Images