通信システム、通信装置及び通信方法、並びにコンピューター・プログラム
【課題】RTTやTTLの制限を超えつつ、WANなどの外部ネットワークを経由したリモート・アクセスを通じてコンテンツを安全に伝送する。
【解決手段】コンテンツのリモート・アクセスを制御するためのフラグの取り扱い方を明示的に定義するとともに、コンテンツ利用装置がリモート・アクセスしたときに認証方法を明示的に定義することによって、リモート・アクセスにおいても、従来の家庭内でのアクセスと同様に、DTCP−IPに基づくコンテンツの著作権保護環境を構築する。
【解決手段】コンテンツのリモート・アクセスを制御するためのフラグの取り扱い方を明示的に定義するとともに、コンテンツ利用装置がリモート・アクセスしたときに認証方法を明示的に定義することによって、リモート・アクセスにおいても、従来の家庭内でのアクセスと同様に、DTCP−IPに基づくコンテンツの著作権保護環境を構築する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、コンテンツの伝送における不正利用を防止する通信システム、通信装置及び通信方法、並びにコンピューター・プログラムに係り、特に、暗号化コンテンツを伝送するとともに、暗号化コンテンツの復号鍵を所定の相互認証及び鍵交換(AKE)アルゴリズムに従って交換する通信システム、通信装置及び通信方法、並びにコンピューター・プログラムに関する。
【0002】
さらに詳しくは、本発明は、WANなどの外部ネットワークを経由したリモート・アクセス(RA)を通じてコンテンツを安全に伝送する通信システム、往復遅延時間(RTT)やIPルーターのホップ回数(TTL)などの制限を超えつつ、リモート・アクセスを通じてコンテンツを安全に伝送する通信装置及び通信方法、並びにコンピューター・プログラムに係り、特に、通信システム、通信装置及び通信方法、並びにコンピューター・プログラムに関する。
【背景技術】
【0003】
従来、放送コンテンツやパッケージ・メディア中のコンテンツは、受信機器や再生機器が設置された場所、又は、これらの機器とホームネットワーク経由で接続された機器で利用すること(以下、「ローカル・アクセス(LA)」とも呼ぶ)が基本であった。例えば、屋外から携帯機器で上記の受信機器や再生機器と接続し、WAN(Wide Area Network)などの外部ネットワーク経由の伝送を伴ってコンテンツを利用すること(以下、「リモート・アクセス(RA)」とも呼ぶ)は、通信路やコーデックなどの技術的な観点から困難であった。しかし、将来的には、LTE(Long Term Evolution)やWiMAX(World Interoperability for Microwave Access)といったデータ通信技術、並びに、H.264などの高圧縮コーデックの普及が見込まれ、これらを活用することでリモート・アクセスの実現可能性が見えてくる。例えば、ユーザーが出先から自宅のサーバーにリモート・アクセスして、コンテンツを再生するという使い方である。
【0004】
他方、ディジタル化されたコンテンツはコピーや改竄などの不正な操作が比較的容易である。とりわけ、リモート・アクセスにおいては、個人的又は家庭的なコンテンツの使用を許容しながら、コンテンツ伝送に介在する不正利用の防止、すなわち著作権保護の仕組みが必要である。
【0005】
ディジタル・コンテンツの伝送保護に関する業界標準的な技術として、DTLA(Digital Transmission Licensing Administrator)が開発したDTCP(Digital Transmission Content Protection)が挙げられる。DTCPでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決められている。その規定は、要約すれば、DTCP準拠機器は取り扱いが容易な圧縮コンテンツを非暗号の状態で機器外に送出しないことと、暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換(Authentication and Key Exchange:AKE)アルゴリズムに従って行なうこと、並びにAKEコマンドにより鍵交換を行なう機器の範囲を制限することなどである。コンテンツ提供元であるサーバ(Source)とコンテンツ提供先であるクライアント(Sink)は、AKEコマンドの送受信により、認証手続きを経て鍵を共有化し、その鍵を用いて伝送路を暗号化してコンテンツの伝送を行なう。したがって、不正なクライアントは、サーバーとの認証に成功しないと暗号鍵を取得できないから、コンテンツを享受することはできない。
【0006】
DTCPは、原初的には、IEEE1394などを伝送路に用いたホームネットワーク上におけるコンテンツ伝送について規定したものである。最近では、DLNA(DigitalLiving Network Alliance)に代表されるように、家庭内においても、ディジタル化されたAVコンテンツをIPネットワーク経由で流通させようという動きが本格的になっている。そこで、家庭内においてもディジタル・コンテンツをIPネットワーク経由で流通させることを意図して、IPネットワークに対応したDTCP技術、すなわちDTCP−IP(DTCP mapping to IP)の開発が進められている。
【0007】
DTCP−IPは、DTCP技術をIPネットワークに移植した同様の技術であるが、伝送路にIPネットワークを使用すること、暗号化されたコンテンツの伝送にHTTP(Hyper Text Transfer Protocol)やRTP(Real−Time Transfer Protocol)といった、IPネットワーク上で実装されたコンテンツ伝送用プロトコルを使用する。例えば、HTTPの手続きに従ってコンテンツを伝送する場合、SourceがHTTPサーバーとなり、SinkがHTTPクライアントとなって、HTTPのためのTCP/IPコネクションが作成され、暗号化コンテンツのダウンロード伝送が行なわれる(但し、アップロード伝送を行なうときには、SourceがHTTPクライアントとなりSinkがHTTPサーバーとなる)。
【0008】
現在のDTCP−IP(DTCP Volume 1 Specification Supplement E Revision 1.2)は、主にコンテンツの家庭内のみの利用を確保することを意図したものである。このため、AKEコマンドに対し往復遅延時間(RTT:Round Trip Time)は最大7ミリ秒に制限され、また、IPルーターのホップ回数(TTL:Time To Live)の上限が3に設定されている。
【0009】
例えば、SourceがDTCP−IP認証を開始してから終了する直前までの間、受信した各AKEコマンドを監視し続け、TTL値の最大値を更新し続け、認証手続きが終了する直前にTTL値の最大値をチェックし、この最大値が3以下であれば鍵交換して認証手続きを完了するが、3を超えると、最終段階の処理を行なわずに認証手続きを終わらせる情報通信システムについて提案がなされている(例えば、特許文献1を参照のこと)。
【0010】
しかしながら、RTTやTTLの制限を課すと、家庭外の遠隔地から家庭内のホームネットワークのサーバーにある著作権保護されたコンテンツにアクセスすることはできない。
【0011】
ユーザーの利便性を考えると、コンテンツへのリモート・アクセスを許容したいが、著作権保護したいというコンテンツ・オーナーの利益とは相反する。
【先行技術文献】
【特許文献】
【0012】
【特許文献1】特開2007−36351号公報
【発明の開示】
【発明が解決しようとする課題】
【0013】
本発明の目的は、暗号化コンテンツの復号鍵を所定の相互認証及び鍵交換(AKE)アルゴリズムに従って交換して、コンテンツの伝送における不正利用を好適に防止することができる、優れた通信システム、通信装置及び通信方法、並びにコンピューター・プログラムを提供することにある。
【0014】
本発明のさらなる目的は、往復遅延時間(RTT)やIPルーターのホップ回数(TTL)などの制限を超えつつ、WANなどの外部ネットワークを経由したリモート・アクセスを通じてコンテンツを安全に伝送することができる、優れた通信システム、通信装置及び通信方法、並びにコンピューター・プログラムを提供することにある。
【課題を解決するための手段】
【0015】
本願は、上記課題を参酌してなされたものであり、請求項1に記載の発明は、コンテンツを提供するコンテンツ提供装置とコンテンツを利用する1以上のコンテンツ利用装置でコンテンツ伝送のための通信を行なう通信システムであって、
リモート・アクセスするコンテンツ利用装置を、コマンドの往復遅延時間に関する制限を課さないリモート・アクセス用の相互認証手続きに従って認証する認証手段と、
前記コンテンツ利用装置からリモート・アクセスにより要求されたコンテンツがリモート・アクセスを許容されているか否かを識別する識別手段と、
前記識別手段による識別結果及び前記認証手段による認証結果に応じて、前記コンテンツ提供装置から認証された前記コンテンツ利用装置へ、前記要求されたコンテンツを伝送する伝送手段と、
を具備することを特徴とする通信システムである。
【0016】
但し、ここで言う「システム」とは、複数の装置(又は特定の機能を実現する機能モジュール)が論理的に集合した物のことを言い、各装置や機能モジュールが単一の筐体内にあるか否かは特に問わない。
【0017】
本願の請求項2に記載の発明は、
リモート・アクセスするコンテンツ利用装置を、コマンドの往復遅延時間に関する制限を課さないリモート・アクセス用の相互認証手続きに従って認証する認証手段と、
コンテンツ利用装置からリモート・アクセスにより要求されたコンテンツがリモート・アクセスを許容されているか否かを識別する識別手段と、
コンテンツ利用装置へ要求されたコンテンツを提供する提供手段と、
を具備し、
前記提供手段は、リモート・アクセスによりコンテンツを要求するコンテンツ利用装置に対し、前記識別手段による識別結果及び前記認証手段による認証結果に応じて、コンテンツを提供する、
ことを特徴とする通信装置である。
【0018】
本願の請求項3に記載の発明によれば、請求項2に係る通信装置の認証手段は、リモート・アクセス用の相互認証手続きに際し、IPルーターのホップ回数に関する制限をも課さないように構成されている。
【0019】
本願の請求項4に記載の発明によれば、請求項2に係る通信装置の識別手段は、要求されたコンテンツの所定の制御記述子に重畳されている、リモート・アクセスの可否を示す情報に基づいて、リモート・アクセスを許容されているか否かを識別するように構成されている。
【0020】
本願の請求項5に記載の発明によれば、請求項2に係る通信装置の識別手段は、要求されたコンテンツの所定の制御記述子の記載内容に基づいて、リモート・アクセスを許容されているか否かを識別するように構成されている。
【0021】
本願の請求項6に記載の発明によれば、請求項2に係る通信装置の識別手段は、要求されたコンテンツの所定の制御記述子に含まれるコピー制御情報の記載内容に基づいて、リモート・アクセスを許容されているか否かを識別するように構成されている。
【0022】
本願の請求項7に記載の発明によれば、請求項2に係る通信装置は、コンテンツを蓄積することができる記憶部をさらに備え、識別手段は、記憶部にコピーされているコンテンツはリモート・アクセスを許可されていると識別するように構成されている。
【0023】
本願の請求項8に記載の発明によれば、請求項2に係る通信装置は、放送コンテンツを受信する受信部をさらに備え、識別手段は、放送中のリアルタイム・コンテンツについては、放送終了後からの経過時間に基づいてリモート・アクセスを許容されているか否かを識別するように構成されている。
【0024】
本願の請求項9に記載の発明によれば、請求項2に係る通信装置は、放送コンテンツを受信する受信部と、コンテンツを蓄積することができる記憶部をさらに備え、識別手段は、受信した放送コンテンツを、前記記憶部に一旦蓄積した後にリモート・アクセスを許可されていると識別するように構成されている。
【0025】
本願の請求項10に記載の発明によれば、請求項2に係る通信装置は、リモート・アクセス可能コンテンツを記憶する第1の領域とリモート・アクセス不可コンテンツを記憶する第2の領域を有する記憶部をさらに備え、各コンテンツを識別手段による識別結果に基づいて前記第1又は第2の領域に仕分けして記憶部に蓄積するように構成されている。
【0026】
本願の請求項11に記載の発明によれば、請求項2に係る通信装置は、コマンドの往復遅延時間に関する制限を課した登録用の相互認証手続きを経てコンテンツ利用装置を事前に登録する登録手段をさらに備え、認証手段は、リモート・アクセスするコンテンツ利用装置が前記登録手段により登録されているときのみ認証手続きを行なうように構成されている。
【0027】
本願の請求項12に記載の発明によれば、請求項11に係る通信装置の登録手段は、登録用の相互認証手続きに際し、IPルーターのホップ回数に関する制限をさらに課すように構成されている。
【0028】
本願の請求項13に記載の発明によれば、請求項11に係る通信装置の登録手段は、コンテンツ利用装置の事前登録時に、ユーザーID、パスフレーズ若しくはキー、ユーザーの生体情報、又はその他のリモート・アクセス用の認証情報を併せて登録し、認証手段は、リモート・アクセスするコンテンツ利用装置を認証する際に、前記の事前登録した認証情報を用いた認証処理を併せて行なうように構成されている。
【0029】
本願の請求項14に記載の発明によれば、請求項13に係る通信装置の認証手段は、リモート・アクセス用の認証情報を書き込んだポータブル・メディアを通じて事前登録した認証情報を用いた認証処理を行なうように構成されている。
【0030】
本願の請求項15に記載の発明によれば、請求項11に係る通信装置の認証手段は、当該装置に紐付けされたドングルを通じてリモート・アクセスするコンテンツ利用装置を認証するように構成されている。
【0031】
本願の請求項16に記載の発明によれば、請求項11に係る通信装置の登録手段はコンテンツ利用装置を事前登録する際に、当該コンテンツ利用装置がリモート・アクセス時に利用する1以上のコンテンツを併せて登録し、提供手段は、リモート・アクセスするコンテンツ利用装置に対し、前記のリモート・アクセス時に利用するとして事前登録されたコンテンツのみを提供するように構成されている。
【0032】
本願の請求項17に記載の発明によれば、請求項2に係る通信装置の認証手段は、前記リモート・アクセス用の相互認証手続きに代えて、所定の認証サーバーに対するログイン処理を通じて前記リモート・アクセスするコンテンツ利用装置の認証手続きを行なうように構成されている。
【0033】
本願の請求項18に記載の発明によれば、請求項2に係る通信装置の認証手段は、コンテンツ利用装置からの相互認証制御コマンドに設けられている、リモート・アクセスの可否を示す情報ビットに基づいて、リモート・アクセスするコンテンツ利用装置を認証するように構成されている。
【0034】
本願の請求項19に記載の発明によれば、請求項2に係る通信装置の認証手段は、リモート・アクセス専用の相互認証手続きに従って、リモート・アクセスするコンテンツ利用装置を認証するように構成されている。
【0035】
本願の請求項20に記載の発明によれば、請求項18又は19のいずれかに係る通信装置の提供手段は、リモート・アクセス専用の暗号化モードを用いて、コンテンツ利用装置からリモート・アクセスにより要求されたコンテンツを暗号化伝送するように構成されている。
【0036】
本願の請求項21に記載の発明によれば、請求項18又は19のいずれかに係る通信装置の提供手段は、コンテンツのリモート・アクセスによる再出力を禁止するように構成されている。
【0037】
本願の請求項22に記載の発明によれば、請求項18又は19のいずれかに係る通信装置はコンテンツを蓄積することができる記憶部をさらに備え、提供手段は、記憶部に蓄積されているコンテンツにリモート・アクセスが可能であることを示す情報が付加されているときには、リモート・アクセスによる再出力を禁止するように構成されている。
【0038】
本願の請求項23に記載の発明によれば、請求項18又は19のいずれかに係る通信装置はコンテンツを蓄積することができる記憶部をさらに備え、識別手段は、リモート・アクセスが可能であることを示す情報が付加されたコンテンツを記憶部に蓄積する際に、当該情報をリモート・アクセス不可に書き換えるように構成されている。
【0039】
本願の請求項24に記載の発明によれば、請求項18又は19のいずれかに係る通信装置の識別手段は、著作権保護が施された所定のプロトコルに従って受け取ったコンテンツにリモート・アクセスの可否を示す情報が付加されていないときには、当該コンテンツをリモート・アクセス不可として扱うように構成されている。
【0040】
本願の請求項25に記載の発明によれば、請求項18又は19のいずれかに係る通信装置の識別手段は、著作権保護が施された所定のプロトコルに従って受け取ったコンテンツにリモート・アクセスの可否を示す情報が付加されていないときには、当該コンテンツに設定されているコピー制御情報に基づいて、当該コンテンツがリモート・アクセスを許容されているか否かを識別するように構成されている。
【0041】
本願の請求項26に記載の発明によれば、請求項25に係る通信装置はコンテンツを蓄積することができる記憶部をさらに備え、識別手段は、リモート・アクセスを不可としないコンテンツについては、前記記憶部に一旦蓄積した後にリモート・アクセス可として扱い、前記記憶部に蓄積する前の状態ではリモート・アクセス不可として扱うように構成されている。
【0042】
また、本願の請求項27に記載の発明は、
リモート・アクセスするコンテンツ利用装置を、コマンドの往復遅延時間に関する制限を課さないリモート・アクセス用の相互認証手続きに従って認証する認証ステップと、
コンテンツ利用装置からリモート・アクセスにより要求されたコンテンツがリモート・アクセスを許容されているか否かを識別する識別ステップと、
コンテンツ利用装置へ要求されたコンテンツを提供する提供ステップと、
を有し、
前記提供ステップでは、リモート・アクセスによりコンテンツを要求するコンテンツ利用装置に対し、前記識別ステップにおける識別結果及び前記認証ステップにおける認証結果に応じて、コンテンツを提供する、
ことを特徴とする通信方法である。
【0043】
また、本願の請求項28に記載の発明は、ネットワーク経由でコンテンツを提供するための処理をコンピューター上で実行するようにコンピューター可読形式で記述されたコンピューター・プログラムであって、前記コンピューターを、
リモート・アクセスするコンテンツ利用装置を、コマンドの往復遅延時間に関する制限を課さないリモート・アクセス用の相互認証手続きに従って認証する認証手段、
コンテンツ利用装置からリモート・アクセスにより要求されたコンテンツがリモート・アクセスを許容されているか否かを識別する識別手段、
コンテンツ利用装置へ要求されたコンテンツを提供する提供手段、
として機能させ、
前記提供手段は、リモート・アクセスによりコンテンツを要求するコンテンツ利用装置に対し、前記識別手段による識別結果及び前記認証手段による認証結果に応じて、コンテンツを提供する、
ことを特徴とするコンピューター・プログラムである。
【0044】
本願の請求項28に係るコンピューター・プログラムは、コンピューター上で所定の処理を実現するようにコンピューター可読形式で記述されたコンピューター・プログラムを定義したものである。換言すれば、本願の請求項28に係るコンピューター・プログラムをコンピューターにインストールすることによって、コンピューター上では協働的作用が発揮され、本願の請求項2に係る通信装置と同様の作用効果を得ることができる。
【発明の効果】
【0045】
本発明によれば、往復遅延時間(RTT)やIPルーターのホップ回数(TTL)などの制限を超えつつ、WANなどの外部ネットワークを経由したリモート・アクセスを通じてコンテンツを安全に伝送することができる、優れた通信システム、通信装置及び通信方法、並びにコンピューター・プログラムを提供することができる。
【0046】
本発明によれば、コンテンツ・オーナーが許容するコンテンツの範囲内に限り、コンテンツを保護しながらユーザーのリモート・アクセスを実施することかできる、優れた通信システム、通信装置及び通信方法、並びにコンピューター・プログラムを提供することができる。
【0047】
本願の請求項1、2、3に記載の発明によれば、リモート・アクセスするコンテンツ利用装置に対してはRTT及びTTLの制限を外した相互認証手続きを適用するので、リモート・アクセスが可能である。また、リモート・アクセスするコンテンツ利用装置に対しリモート・アクセスが許容されたコンテンツのみを提供するので、DTCP−IPで著作権保護されたDLNAコンテンツに、家庭外の遠隔地からリモート・アクセスして、コンテンツを安全に利用することができる。
【0048】
また、本願の請求項4乃至10に記載の発明によれば、コンテンツのリモート・アクセスを制御するためのフラグの取り扱い方を明示的に定義しているので、リモート・アクセスにおいても、従来の家庭内でのアクセスと同様に、DTCP−IPに基づくコンテンツの著作権保護環境を構築することができる。
【0049】
また、本願の請求項1、2、3、11乃至17に記載の発明によれば、コンテンツ利用装置がリモート・アクセスしたときに認証方法(AKE手続き)を明示的に定義しているので、リモート・アクセスにおいても、従来の家庭内でのアクセスと同様に、DTCP−IPに基づくコンテンツの著作権保護環境を構築することができる。
【0050】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
【図面の簡単な説明】
【0051】
【図1】図1は、本発明に係る通信システムの一構成例を模式的に示した図である。
【図2】図2は、本発明に係る通信システムの他の構成例を模式的に示した図である。
【図3】図3は、コンテンツ提供装置10の機能的構成を模式的に示した図である。
【図4】図4は、コンテンツ利用装置20の機能的構成を模式的に示した図である。
【図5】図5は、SourceとSinkの間でDTCP−IPにより暗号化コンテンツ伝送を行なう仕組みを説明するための図である。
【図6】図6は、SourceとSink間で現行のDTCP−IPに従って行なわれる、AKEコマンドを用いた相互認証及び鍵交換の動作シーケンスを示した図である。
【図7】図7は、RA−SourceにRA−Sinkを事前登録する際の認証シーケンス例を示した図である。
【図8】図8は、AKE control commandの構成を示した図である。
【図9】図9は、RA−SourceがRA−Sinkを事前登録するための「RA−Sink Registratoin」処理の手順を示したフローチャートである。
【図10】図10は、RA−SinkがRA−AKE手続きによりRA−Sourceからリモート・アクセス用の交換鍵を取得するとともに、RA−Sourceにコンテンツを要求するコンテンツ取得シーケンス例を示した図である。
【図11】図11は、RA−SourceがRA−Sinkの登録確認及び認証処理を行なうための「RA−Sink ID confirmation」処理の手順を示したフローチャートである。
【図12】図12は、コンテンツ提供装置10がコンテンツに付加されたリモート・アクセス可否情報に基づいてリモート・アクセスを制御するための仕組みを説明するための図である。
【図13】図13は、TSパケットの構造を模式的に示した図である。
【図14】図14は、ディジタル・コピー制御記述子のデータ構造を示した図である。
【図15】図15は、PMTの詳細な構造を示した図である。
【図16】図16は、MPEG TSストリーム中に所定間隔でPMTを含んだTSパケットが挿入されている様子を示した図である。
【図17】図17は、Blu−rayディスク上のコンテンツのリモート・アクセスを制御する仕組みを示した図である。
【図18】図18は、RA−Source、RA−Sinkがさらに別の機器にデイジーチェーン接続され、受信したコンテンツをさらに出力する可能性があるシステム構成例を模式的に示した図である。
【図19】図19は、RA−Source、RA−Sinkがさらに別の機器にデイジーチェーン接続され、受信したコンテンツをさらに出力する可能性があるシステム構成例を模式的に示した図である。
【発明を実施するための形態】
【0052】
以下、図面を参照しながら本発明の実施形態について詳細に説明する。
【0053】
A.システム構成
本発明は、WANなどの外部ネットワークを経由したリモート・アクセス(RA)を通じてコンテンツを安全に伝送する通信システムに関するものであり、同通信システムは、基本的に、リモート・アクセスによりコンテンツを提供するサーバ(RA−Source)と、リモート・アクセスによりコンテンツを要求するクライアント(RA−Sink)からなる。本明細書では、リモート・アクセス時に行なうAKE手続きを、「RA−AKE」と呼ぶことにする以下、図面を参照しながら本発明の実施形態について詳細に説明する。
【0054】
図1には、本発明に係る通信システムの一構成例を模式的に示している。図示の通信システムでは、RA−Sourceに相当するコンテンツ提供装置10が家庭内に設置され、RA−Sinkに相当するコンテンツ利用装置20が屋外にいる。そして、コンテンツ利用装置20は、携帯電話のような通信機能によってコンテンツ提供装置10に対してリモート・アクセスする。
【0055】
コンテンツ提供装置10は、一般にルーター30とモデム40経由でWAN50などの外部ネットワークに接続される。WAN50は例えばインターネットである。ルーター30には、WAN50側のIPアドレスが、ユーザーが加入するIntenet Accsess Service(IAS)プロバイダー60から割り当てられる。また、コンテンツ利用装置20も、基本的にこのIPアドレスにアクセスする。ルーター30は、コンテンツ提供装置10にはプライベートIPアドレスを割り当て、WAN50からのアクセスについてはポート・フォワーディングによって通信を中継する。なお、ルーター30に割り当てられるIPアドレスは、IASプロバイダー60によって更新される場合があるが、そのようなケースではDDNSサービス70を用い、ルーター30乃至コンテンツ提供装置10のDDNS(Dynamic DNS(Domain Name System))機能を使うことで対応できる。
【0056】
また、図2には、本発明に係る通信システムの他の構成例を模式的に示している。図示の通信システムでは、RA−Sinkに相当するコンテンツ利用装置20も家庭内に設置され、ルーター31とモデム41経由でWAN50に接続されている。コンテンツ利用装置20から発信されるTCP/IP(Transmission Control Protocol/Internet Protocol)通信は、ルーター31のNAT(Network Address Translation)機能によってアドレス変換されるが、それ以外は図1の場合と同様である。
【0057】
図3には、コンテンツ提供装置10の機能的構成を模式的に示している。コンテンツ提供装置10は、CPU(Central Processing Unit)11と、コンテンツ受信/再生部12と、通信部13と、記憶部14と、タイマー15を備えるが、ホームネットワーク・サーバー並びにRA−Sourceとして機能して、リモート・アクセスでコンテンツを送信する。
【0058】
コンテンツ受信/再生部12は、放送受信機能や、パッケージ・メディア再生機能をそなえている。CPU11は、コンテンツ受信/再生部12で得られるコンテンツについて、リモート・アクセス可能なものを適切な保護を施した後に、通信部13を通じて、RA−AKEにより相互認証及び鍵交換を行なったRA−Sink(コンテンツ利用装置20)に送信する。
【0059】
記憶部14には、後述の登録処理によって記憶することになったRA−Sinkの識別情報(Device ID)や認証情報(リモート・アクセス用のユーザーID、パスフレーズあるいはキー、ユーザーの生体情報など)、RA−AKEを通じてRA−Sinkと共有した交換鍵とその識別情報などが記憶される。また、記憶部14は、コンテンツ受信/再生部12で得たコンテンツを蓄積する用途で用いることもできる。
【0060】
タイマー15は、リモート・アクセス可能なコンテンツを扱う際に時間管理が必要となる場合に使われる。
【0061】
図4には、コンテンツ利用装置20の機能的構成を模式的に示している。コンテンツ利用装置20は、CPU21と、通信部22と、コンテンツ出力部23と、記憶部24と、認証情報入力部25を備えるが、RA−Sinkとして機能して、リモート・アクセスでコンテンツを受信する。
【0062】
RA−Sinkとしてのコンテンツ利用装置20は、通信部22を通じてRA−Source(コンテンツ提供装置10)に対して後述の機器登録処理を行なう他、RA−AKEを行なってRA−Sourceから交換鍵を取得して記憶部24に保持するとともに、その鍵を基に算出する暗号鍵でRA−Sourceから得た暗号化コンテンツを復号して、コンテンツ出力部23からコンテンツを出力する。記憶部24は、RA−Sourceから受け取った交換鍵やコンテンツを蓄積する用途で用いられる。
【0063】
認証情報入力部25は、ユーザーがパスフレーズあるいはキーを入力するための入力操作部、ユーザーの生体情報を取得するための生体情報読取部、パスフレーズあるいはキーを記録したポータブル・メディアを装着するメディア装着部、ドングルなどのホームネットワーク・サーバーに紐付けされたハードウェア・キーを装着するドングル装着部などからなる。
【0064】
以下の説明では、交換鍵から暗号鍵を算出する方法はDTCP−IPに従うものとする(但し、本発明の要旨は必ずしもこの方法には限定されない)。
【0065】
ここで、SourceとSinkの間でDTCP−IPにより暗号化コンテンツ伝送を行なう仕組みについて、図5を参照しながら説明しておく。コンテンツ伝送の形態は、Source上のコンテンツをSinkにコピーする方法と、SourceからSinkへコンテンツを移動してSourceにコンテンツを残さない方法があるが(周知)、同図では前者のコピーによるコンテンツ伝送方法を前提にして説明する。
【0066】
SourceとSinkは、まず1つのTCP/IPコネクションを確立して、機器同士の認証(AKE手続き)を行なう。DTCP準拠機器には、DTLA(前述)により発行された機器証明書が埋め込まれている。AKE手続きでは、互いが正規のDTCP準拠機器であることを確かめた後、認証鍵KauthをSourceとSinkで共有することができる。
【0067】
AKE手続きが成功すると、Sourceはコンテンツ鍵Kcの種となる交換鍵Kxを生成し、認証鍵Kauthで暗号化してSinkに送る。Source及びSinkそれぞれにおいて、交換鍵Kxに対して所定の演算処理を適用することによって、コンテンツ伝送時にコンテンツを暗号化するために使用されるコンテンツ鍵Kcを生成することができる。
【0068】
そして、DTCP準拠の機器間でAKEによる認証及び鍵交換手続きが済んだ後、HTTPやRTPなどのプロトコルを利用してコンテンツ伝送が開始される。図示の例では、HTTPの手続きに従ってコンテンツ伝送が行なわれる。その際、AKE手続きのためのTCP/IPコネクションとは別に、HTTPのためのTCP/IPコネクションが作成される(すなわち、SourceとSinkはそれぞれ、AKE手続き用とコンテンツ伝送用に個別のソケット情報(IPアドレスとポート番号の組み合わせ)を持つ)。
【0069】
HTTPプロトコルに従ってコンテンツ伝送を行なうには、SinkがSourceにコンテンツを要求するダウンロード形式と、Source側からSinkにコンテンツをプッシュするアップロード形式の2通りが挙げられる。前者の場合、HTTPクライアントとしてのSinkは、例えばHTTP GETメソッドを用いたHTTPリクエストにより、HTTPサーバーとしてのSourceにコンテンツを要求し、これに対しSouceからは要求通りのコンテンツがHTTPレスポンスとして伝送される。また後者の場合、HTTPクライアントとしてのSourceは、例えばHTTP POSTメソッドを用いたHTTPリクエストにより、HTTPサーバーとしてのSinkとの伝送を開始する。
【0070】
Sourceから伝送されるデータは、SourceがAKE認証をした後に共有した鍵を用いてコンテンツを暗号化したデータとなっている。具体的には、Sourceは、乱数を用いてノンスNcを生成して、交換鍵KxとノンスNcと暗号モードに応じたコンテンツ鍵Kcを生成する。そして、Sinkから要求されているコンテンツを、コンテンツ鍵Kcを用いて暗号化し、暗号化コンテンツからなるペイロードとノンスNcと暗号モードの情報を含んだヘッダからなるパケットをTCPストリーム上に乗せて送信する。IPプロトコルでは、TCPストリームを所定の単位となるパケットの大きさに分割し、さらにヘッダ部を付加したIPパケットにし、指定されたIPアドレス宛てに届ける。
【0071】
Sink側では、Sourceからの各IPパケットを受信すると、これをTCPストリームに組み立てる。そして、このストリームからノンスNcとE−EMIを取り出すと、これらと交換鍵Kxを用いてコンテンツ鍵Kcを算出し、暗号化コンテンツを復号することができる。そして、復号化した後の平文のコンテンツに対し再生処理を実施することができる。あるいは、Sinkは、暗号化コンテンツを復号することなく、コンテンツを記憶部24に格納したり、他の機器にスルーしたりする。このようにしてHTTPプロトコルを利用したコンテンツ伝送が終了すると、例えばSink側から、コンテンツ伝送に使用したTCPコネクションを適宜切断する。(DTCP−IPでは、パケットのヘッダ部に記述するE−EMI(ExtendedEncryption Mode Indicator)と、Embedded CCI(Copy Control Information)という2つのメカニズムにより、コンテンツに付随したコピー制御情報の伝送を実現している。)
【0072】
なお、DTCP−IPでは、交換鍵Kxを定期的(例えば2時間毎)に更新することが規定されている。SinkはSourceから最新の交換鍵Kxを入手できなければ、暗号化コンテンツを利用不能となる。また、Sourceが単一の交換鍵Kxを生成して複数台の(正当な)Sinkに配る方法と、Sink毎に異なる交換鍵Kxを生成する方法が考えられるが、以下の説明では前者の方法を採用するものとする。
【0073】
図6には、SourceとSink間で現行のDTCP−IPに従って行なわれる、AKEコマンドを用いた相互認証及び鍵交換の動作シーケンス(RTT−AKE)を示している。
【0074】
AKE手続きのチャレンジ・レスポンス部分(Challenge−Response portion of AKE)では、まず、コンテンツを要求するSinkから、Rx乱数とRx証明書を含んだRxチャレンジが送信される。これに対し、Sourceからは、Tx乱数及びTx証明書を含んだTxチャレンジが返信される。以降、Sourceから、Rx乱数、Txメッセージ、Tx署名を含んだRxレスポンスが送信されるとともに、SinkからはTx乱数、Rxメッセージ、Rx署名を含んだTxレスポンスが送信され、通常のチャレンジ・レスポンス認証手続きが続く。チャレンジ・レスポンス部分で送信されるコマンドには、各チャレンジ・コマンドには、機器固有の識別情報であるDevice IDが含まれている。
【0075】
上記のチャレンジ・レスポンス応答手続きでは、TTL(IPルーターのホップ回数)の制限が課されている。すなわち、現在のDTCP−IPでは、送信機器はAKEで用いるコマンドを送るTCP/IP通信においてTTLが3以下に設定され、受信機器はTTLが3より大きい場合は受け取ったデータを無効にしなければならない。
【0076】
その後、RTT保護プロトコル(Protected RTT Protocol)を経て、SourceからSinkへ、EXCHANGE_KEYコマンドが送信され、これに対し、Sinkからレスポンス(図示しない)が返される。
【0077】
図6に示した現行のDTCP−IPに従うRTT−AKEでは、AKEコマンドに対し往復遅延時間(RTT)やIPルーターのホップ回数(TTL)が制限されている。現状のままでは、家庭外の遠隔地から家庭内のホームネットワークのサーバーにある著作権保護されたコンテンツにアクセスすることはできない(前述)。しかしながら、ユーザーの利便性を考えると、ユーザーが出先から自宅のサーバーにリモート・アクセスして、コンテンツを再生するという使い方が望まれる。勿論、著作権保護したいというコンテンツ・オーナーの利益を確保する必要がある。したがって、リモート・アクセスは、コンテンツ・オーナーが許容するコンテンツの範囲内に制限すべきであり、且つ、リモート・アクセスされるコンテンツの保護も行なわなければならない。
【0078】
これに対し、本発明として提案する、リモート・アクセス時のAKE手続きすなわちRA−AKEでは、図6に示したRTT−AKE手続きで行なっている「Protected RTT Protocol」を行なわない。すなわち、SourceとSinkの間のRTTが7ミリ秒を超えてもAKE手続きを中止しない。また、RA−AKEでは、上記のTTLの上限を設けない。すなわち、RA−AKEでは、RTT並びにTTLの制限を設けないことで、リモート・アクセスに対応するSource(コンテンツ提供装置10)と、リモート・アクセスに対応するSink(コンテンツ利用装置20)が、応答遅延時間が7ミリ秒を超え、又は、ホップ数が3を超えるだけ離間していたとしても、両機器間でAKE手続きを成功裏に実施して、リモート・アクセス用の交換鍵を共有することができる。
【0079】
但し、RTT並びにTTLの制限が外された状態の通信システムでは、任意の機器間でコンテンツの伝送が可能になるため、コンテンツの著作権保護の観点から不正な利用を防止する仕組みが必要になる。
【0080】
本発明者らは、RTT並びにTTLの制限を外して、コンテンツ・オーナーが許容する範囲内でユーザーのリモート・アクセスを実現するには、リモート・アクセスが許容されるコンテンツを識別することと、リモート・アクセスする機器(すなわち、コンテンツ利用装置20)がホームネットワークの一員であることを確認することが必要であると思料する。以下では、リモート・アクセス可能なコンテンツの識別方法と、リモート・アクセス用端末の認証方法の各々について詳細に説明する。
【0081】
B.リモート・アクセス用端末の認証
まず、リモート・アクセスする機器がームネットワークの一員であることを確認するための方法について説明する。
【0082】
不正なユーザーからの接続を制限するために、RA−Sourceが事前に登録されたRA−SinkとだけRA−AKE手続きを行なうようにする。具体的には、現在のDTCP−IPのRTT−AKEと同様に、RTTやTTL制限を伴うAKE手続きに成功した場合にだけ、RA−SourceがRA−Sinkの機器固有IDを記憶して登録する。RA−Sinkの登録手続きは、例えば、RTT並びにTTLの制限に収まる家庭内で事前に行なわれる。したがって、不正なユーザーは、リモート環境から事前登録できないので、RA−AKE手続きを成功できなくなる。
【0083】
図7には、RA−SourceにRA−Sinkを事前登録する際の認証シーケンス例を示している。
【0084】
この認証シーケンスは、RA−SinkがRA−Sourceに対して登録要求コマンド「RA_REGI_INIT」を送信することによって開始する。RA−AKE手続きのチャレンジ・レスポンス部分(Challenge−Response portion of AKE)では、まず、RA−Sinkから、Rx乱数とRx証明書を含んだRxチャレンジが送信される。これに対し、RA−Sourceからは、Tx乱数及びTx証明書を含んだTxチャレンジが返信される。以降、RA−Sourceから、Rx乱数、Txメッセージ、Tx署名を含んだRxレスポンスが送信されるとともに、RA−SinkからはTx乱数、Rxメッセージ、Rx署名を含んだTxレスポンスが送信される。
【0085】
各チャレンジ・コマンドには、機器固有の識別情報であるDevice IDが含まれている。但し、同チャレンジ・レスポンス部分の中では、SinkからSourceへのレスポンスとして「RESPONSE2」が送られることがある。これは、機器がCommon Device KeyとCommon Device Certificateを実装することで、Device IDが機器固有とならない場合である。RESPONSE2が送られる場合は、機器固有の識別情報として、Device IDではなく、RESPONSE2に含まれる機器固有情報であるIDuを使うことになる。なお、Device IDやIDuではなく、WiFi用のMAC(Media Access Control)アドレスを機器固有情報に用いることもできる。
【0086】
登録手続きにおけるRA−AKE手続きのチャレンジ・レスポンス部分は、現行のDTCP−IPにおけるRTT−AKE手続きと同様の処理となり、TTLの制限が課されている。その後、RTT保護プロトコル(Protected RTT Protocol)がさらに続き、RA−SourceとRA−Sinkの間のRTTが7ミリ秒を超えるとRA−AKE手続きを中止する。
【0087】
RA−Sourceは、ここまでの手順に成功したRA−Sinkを登録するための「RA−Sink Registratoin」処理を実行する。そして、RA−Sourceは、記憶部14内のRAレジストリーにRA−SinkのIDを登録できる余裕があれば追加登録し、その結果を、結果コードとして、コマンド「RA_REGI_END」でRA−Sinkに通知する。
【0088】
なお、図7中の「RA_REGI_INIT」と「RA_REGI_END」は、DTCP−IPのAKE control commandにリモート・アクセス用のコマンドとして追加するものとする。図8には、リモート・アクセス用のAKE control commandの構成例を示している。図示の例では、subfunctionフィールドに新たな値を割り当て、AKE_Infoで情報を運ぶことができる。
【0089】
図9には、RA−SourceがRA−Sinkを登録するための「RA−Sink Registratoin」処理の手順をフローチャートの形式で示している。
【0090】
RA−Sourceは、まず、当該処理ルーチンを開始する以前の処理(Challenge−Response portion of AKE、並びに、Protected RTT Protocol)を異常終了(abort)したか否かをチェックする(ステップS1)。
【0091】
ここで、以前の処理を異常終了していた場合には(ステップS1のNo)、RA−Sourceは、要求元のRA−Sinkに対し、登録処理に「失敗」した旨の結果コードを通知して(ステップS9)、本処理ルーチンを終了する。
【0092】
また、以前の処理を正常に終了していた場合には(ステップS1のYes)、RA−Sourceは、RESPONSE2(前述)を受信したか否かをチェックする(ステップS2)。そして、RESPONSE2を受信したときには(ステップS2のYes)、RA−Sourceは、要求元のRA−SinkのIDをIDuとする(ステップS3)。また、RESPONSE2を受信していないときには(ステップS2のNo)、RA−Sourceは、要求元のRA−SinkのDevice IDをIDとする(ステップS4)。
【0093】
次いで、RA−Sourceは、要求元のRA−SinkのIDを既に登録済みか否かをチェックする(ステップS5)。
【0094】
ここで、要求元のRA−SinkのIDを既に登録済みである場合には(ステップS5のYes)、RA−Sourceは、要求元のRA−Sinkに対し、登録処理に「成功」した旨の結果コードを通知して(ステップS8)、本処理ルーチンを終了する。
【0095】
他方、要求元のRA−SinkのIDをまだ登録していないときには(ステップS5のNo)、RA−Sourceは、記憶部14内に当該RA−SinkのIDを追加登録する(ステップS6)。また、オプションとして、パスフレーズあるいはキー、ユーザーの生体情報などのユーザーの認証情報をRA−Sinkから取得して、RA−SinkのIDに紐付けして登録する(ステップS7)。そして、RA−Sourceは、要求元のRA−Sinkに対し、登録処理に「成功」した旨の結果コードを通知して(ステップS8)、本処理ルーチンを終了する。
【0096】
なお、ステップS6又はステップS7においてRA−Sinkに関する情報を登録する際に、RA−Sourceを通じてリモート・アクセス可能なコンテンツのうち、RA−Sink上でリモート・アクセスの対象となるコンテンツを併せて登録するようにしてもよい。このような場合、RA−Sinkは、リモート・アクセス時には、登録しておいたコンテンツのみを利用することができる。リモート・アクセスするコンテンツの登録は、ホームネットワーク内でのコンテンツの共有設定に類似する。このような設定モードを設けることにより、コンテンツが必要以上にリモート・アクセスされることを防止できる。また、RA−Sourceから厖大数のコンテンツが提供されている場合、ユーザーは自分が興味のあるコンテンツのみリモート・アクセス用に登録しておけばよい。
【0097】
図10には、RA−SinkがRA−AKE手続きによりRA−Sourceからリモート・アクセス用の交換鍵を取得するとともに、RA−Sourceにコンテンツを要求するコンテンツ取得シーケンス例を示している。
【0098】
このコンテンツ取得シーケンスは、RA−SinkがRA−Sourceに対して鍵供給要求コマンド「RA_AKE_INIT」を送信することによって開始する。RA−AKE手続きのチャレンジ・レスポンス部分(Challenge−Response portion of AKE)では、まず、RA−Sinkから、Rx乱数とRx証明書を含んだRxチャレンジが送信される。これに対しRA−Sourceからは、Tx乱数及びTx証明書を含んだTxチャレンジが返信される。以降、RA−Sourceから、Rx乱数、Txメッセージ、Tx署名を含んだRxレスポンスが送信されるとともに、RA−SinkからはTx乱数、Rxメッセージ、Rx署名を含んだTxレスポンスが送信される。
【0099】
各チャレンジ・コマンドには、機器固有の識別情報であるDevice IDが含まれている。但し、同チャレンジ・レスポンス部分の中では、SinkからSourceへのレスポンスとして「RESPONSE2」が送られることがあるが、その場合は、機器固有の識別情報として、Device IDではなく、RESPONSE2に含まれるIDuを使うことになる(同上)。
【0100】
TTLの制限は、RA−Sourceへ登録する際には必要であるが、リモート・アクセス用の交換鍵供給のためのRA−AKE手続きでは省略される。また、RTT保護プロトコル(Protected RTT Protocol)も、鍵供給のためのRA−AKE手続きでは省略される。これによって、RA−Sinkは、リモート環境下でもリモート・アクセス用の交換鍵を要求することができ、すなわち、リモート・アクセスによるコンテンツの利用が可能になる。
【0101】
そして、上記の認証手順に成功すると、RA−Sourceは、「RA−Sink ID confirmation」処理を実行する。この処理では、RA−Sourceは、要求元のRA−SinkのIDが既に登録済みであることを確認するとともに認証処理を行なう。そして、RA−Sourceは、これらの確認ができた場合に、リモート・アクセス用の交換鍵(RA_Kx)と、当該交換鍵のID(RA_Kx_label)と結果コードを、コマンド「RA_EXCHANGE_KEY」でRA−Sinkに渡す。
【0102】
RA−Sinkは、上述のRA−AKE手続きによってリモート・アクセス用の交換鍵(RA_Kx)とそのID(RA_Kx_label)を取得すると、続いてHTTP GETメソッドを用いたHTTPリクエスト(HTTP GET request)により、RA−Sourceにコンテンツ・データをリクエストする。このリクエストの際には、コンテンツのURLとともに、リモート・アクセス出力用の交換鍵のID(RA_Kx_label)を送る。ここで、RA−SinkからRA−Sourceに交換鍵のID(RA_Kx_label)を送るためのヘッダーフィールドを定義する。
【0103】
RA−Sourceは、コンテンツ・データのリクエストを受けると、交換鍵IDで指定されたリモート・アクセス用の交換鍵を用いて暗号鍵を算出し、指定されたURLのコンテンツをこの暗号鍵を用いて暗号化して、HTTPレスポンス(HTTP GET response)として返送する。
【0104】
なお、RA−SinkをRA−Sourceに事前登録する際に、RA−Sourceを通じてリモート・アクセス可能なコンテンツのうち、RA−Sink上でリモート・アクセスの対象となるコンテンツを併せて登録しておいた場合には(前述)、RA−Sinkは、当該処理シーケンスを通じて、事前登録しておいたコンテンツのみを利用することができる。
【0105】
また、リモート・アクセス用の交換鍵の(RA_Kx)の破棄については、DTCP−IPと同様に連続不使用期間が所定の期間を超える前に破棄するというルールで運用することが考えられる。また、RA−Sinkがリモート・アクセスの終了時に当該交換鍵の破棄を求めるコマンド(RA_FINISH)を交換鍵のID(RA_Kx_label)とともに送るという運用形態も考えられる。この破棄要求コマンドRA_FINISHは、図10中の「RA−AKE_INIT」、「RA_EXCHANGE_KEY」とともに、DTCP−IPのAKE control commandに、リモート・アクセス用のコマンドとして追加するものとする。
【0106】
図11には、RA−SourceがRA−Sinkの登録確認及び認証処理を行なうための「RA−Sink ID confirmation」処理の手順をフローチャートの形式で示している。
【0107】
RA−Sourceは、まず、当該処理ルーチンを開始する以前の処理(Challenge−Response portion of AKE、Protected RTT Protocol)を異常終了(abort)したか否かをチェックする(ステップS11)。
【0108】
ここで、以前の処理を異常終了していた場合には(ステップS11のNo)、RA−Sourceは、要求元のRA−Sinkに対し、RA−AKE手続きを中断して(ステップS20)、本処理ルーチンを終了する。
【0109】
また、以前の処理を正常に終了していた場合には(ステップS11のYes)、RA−Sourceは、RESPONSE2を受信したか否かをチェックする(ステップS12)。そして、RESPONSE2を受信したときには(ステップS12のYes)、RA−Sourceは、要求元のRA−SinkのIDをIDuとする(ステップS13)。また、RESPONSE2を受信していないときには(ステップS12のNo)、RA−Sourceは、要求元のRA−SinkのDevice IDをIDとする(ステップS14)。
【0110】
次いで、RA−Sourceは、要求元のRA−SinkのIDを記憶部14内に既に登録済みか否かをチェックする(ステップS15)。
【0111】
ここで、要求元のRA−SinkのIDを登録してあることを確認できないときには(ステップS15のNo)、RA−Sourceは、要求元のRA−Sinkに対し、RA−AKE手続きを中断して(ステップS19)、本処理ルーチンを終了する。
【0112】
他方、要求元のRA−SinkのIDを登録済みであることを確認できたときには(ステップS15のYes)、RA−Sourceは、続いて、RA−Sinkのユーザーの認証処理を行なう(ステップS16)。
【0113】
そして、RA−Sinkのユーザーの認証処理に成功したときには(ステップS17のYes)、RA−Sourceは、確認処理に「成功」した旨の結果コードを、リモート・アクセス用の交換鍵(RA_Kx)とそのID(RA_Kx_label)とともに、要求元のRA−Sinkに通知して(ステップS18)、本処理ルーチンを終了する。
【0114】
また、RA−Sinkのユーザーの認証処理に失敗したときには(ステップS17のNo)、RA−Sourceは、要求元のRA−Sinkに対し、RA−AKE手続きを中断して(ステップS19)、本処理ルーチンを終了する。
【0115】
ステップS16で行なわれるユーザー認証処理では、例えば、リモート・アクセス用のユーザーID、パスフレーズ又はキー、あるいはユーザーの生体情報などを、RA−Sinkの認証情報入力部25からユーザーが入力し、RA−Sourceに登録されているものとの照合が行なわれる生体情報を認証に用いる場合、例えば、指の静脈パターンを検出する生体認証システム「mofiria(モフィリア)」を使用することが可能である。あるいは、ユーザーの入力操作する代わりに、リモート・アクセス用のユーザーID、パスフレーズ又はキーを書き込んだポータブル・メディアをRA−Sinkに装着する、ドングルなどのホームネットワーク・サーバーに紐付けされたハードウェア・キーをRA−Sinkに装着するといった方法を通じて、ユーザー認証を行なうこともできる。
【0116】
ドングルをホームネットワーク・サーバーに紐付けする方法として、SDメモリーカードのCPRM(Content Protection for Recordable MEDIA)やメモリースティックのMagicGateの認証方法を用いることができる。あるいは、リモート・アクセス専用の認証方法を用いて、ユーザーのコンテンツ・アクセス権をホームネットワーク・サーバーに紐付けすることができる。
【0117】
また、図7、図10に示した処理シーケンス例では、ユーザーは遠隔地へ出かける前に家庭内で事前登録という機器設定が必要であった。事前登録の手続きを行なうことなくコンテンツのリモート・アクセスを可能にする方法の一例として、ホームネットワークに接続されたパソコンなどの情報端末をホームネットワーク上の認証サーバーとして利用し、そのログインIDとパスワードを用いたログイン作業を、RA−AKE手続きに代用する方法を挙げることができる。
【0118】
C.リモート・アクセス可能なコンテンツの識別方法
続いて、リモート・アクセスが許容されるコンテンツを識別するための方法について説明する。
【0119】
ここでは、RA−Sourceが提供する各コンテンツには、リモート・アクセスが可能か否かを示す情報が付加されていることを前提とする。
【0120】
RA−Sourceとしてのコンテンツ提供装置10はコンテンツ受信/再生部12で受信した放送コンテンツや記録メディアから再生するコンテンツ、あるいは通信部13を通じて取得したコンテンツを、リモート・アクセス可否情報に基づいて振り分ける。そして、リモート・アクセス可能と振り分けられたコンテンツに対してのみ、リモート環境にいるRA−Sinkとしてのコンテンツ利用装置20からリモート・アクセスすることができる。
【0121】
コンテンツにリモート・アクセス可否情報を付加する方法として、コンテンツの制御記述子に情報ビットを重畳する方法を挙げることができる。あるいは、情報ビットを重畳するのではなく、コピー制御情報(Copy Control Information:CCI)などの制御記述子に含まれる既存の情報でリモート・アクセス可否情報を代用する方法も考えられる。
【0122】
以下では、ディジタル・コンテンツの伝送並びに蓄積に広く採用されているMPEG2システムを例にとって、リモート・アクセス可否情報を付加する方法について説明する。
【0123】
MPEG2システムは、符号化されたビデオやオーディオ、付加データなど個別のストリームを多重化し、それぞれの同期をとりながら再生するための方式を規定したもので、MPEG2−PS(ProgramStream)と、MPEG2−TS(Transport Stream)の2種類の方式がある。このうち、MPEG2−TSは、放送や通信ネットワークなどデータの伝送誤りが発生する環境に適用されることを想定しており、1本のストリームの中に複数のプログラムを構成することができることから、ディジタル放送などに使用されている。また、MPEG2−PSは、DVDなどに使用されている。
【0124】
MPEG2−TSでは、188バイトの固定長のTS(Transport Stream)パケットが複数個集まって、トランスポート・ストリームが構成される。この188バイトのTSパケットの長さは、ATM(AsynchronousTransfer Mode)セル長との整合性を考慮して決定されている。
【0125】
図13には、TSパケットの構造を模式的に示している。1つのTSパケットは、4バイトの固定長のパケット・ヘッダと、可変長のアダプテーション・フィールド、ペイロードで構成される。パケット・ヘッダには、PID(パケット識別子)や各種のフラグが定義されている。PIDにより、TSパケットのペイロード部分の種類が識別される。ビデオやオーディオなどの個別ストリームが収められたPES(PacketizedElementary Stream)パケットは、同じPID番号を持つ複数のTSパケットに分割されて伝送される。
【0126】
トランスポート・ストリームには、PSI(Program Specific Information)やSI(ServiceInformation)のセクション形式のテーブルで記述された情報をペイロードに乗せたパケットが含まれている。
【0127】
PSIは、所望の放送のチャンネルを選択して受信するシステムで必要な情報(選局のための制御情報)であり、これには、PAT(ProgramAssociation Table)、PMT(Program Map Table)、NIT(Network Information Table)、CAT(ConditionAccess Table)などのデータ構造を持つセクションがある。PATには、プログラム番号に対応するPMTのPIDなどが記述されている。PMTには、対応するプログラムに含まれる映像、音声、付加データ及びPCRのPIDが記述される。NITには、放送システム全体に関する詳細情報が記述され、例えばネットワークに含まれるすべてのプログラムの情報や、目的のプログラムがどの搬送波周波数で送られているかが記述されている。CATには、限定受信方式の識別と契約情報などの個別情報に関する情報が記述される。
【0128】
一方、SIは、放送事業者のサービスに用いるセクションである。SIとしては、EIT(Event InformationTable)やSDT(Service Description Table)などのセクションがある。EITは、番組の詳細情報及び放送時間などが記述されている。
【0129】
MPEG2システムでは、各セクションに詳細な情報を入れるために、ディスクリプタ(descriptor:記述子)を定義し、これをセクションに挿入することにより、きめの細かい情報を伝送することを可能にしている。ARIB STD−B10で定義された、地上ディジタルテレビジョン放送で使用する記述子を以下の表にまとめておく。
【0130】
【表1】
【0131】
ARIB STD−B10では、コンテンツの著作権保護に関わるコピー制御情報を伝送するために、digital_copy_control_descriptor(ディジタル・コピー制御記述子)及びcontent_availability_descriptor(コンテンツ利用記述子)を定義し、これをPMTに挿入してコンテンツのコピー制御情報を定義している。ディジタル・コピー制御記述子のデータ構造を図14に示しておく。
【0132】
ディジタル・コピー制御記述子におけるdigital_recording_control_data(ディジタル記録制御データ)の2ビットは、コピー制御(コピーの世代管理)のためのものである。この2ビットが「00」ならコピー・フリー、「11」ならコピー禁止、「10」なら一世代のみコピーが許可される。すなわち、この2ビットはCGMS(Copy Generation Management System)のコピー制御を行なうものである。
【0133】
【表2】
【0134】
要するに、コンテンツのコピー制御情報は、コンテンツを伝送するストリームを構成するTSパケットのペイロードとして含まれるデータの1種類であり、PMTと呼ばれるデータ構造を持っている。PMTの詳細な構造を図15に示しておく。
【0135】
MPEG TSストリームは、上述したような固定長のTSパケットの繰り返しで構成されるが、すべてのTSパケットにコピー制御情報が含まれる訳ではなく、特定のTSパケットにのみ含まれる。例えば、ARIBでは、MPEG TSストリーム中で100ミリ秒の間隔で、コピー制御情報を記載したPMTを伝送するパケットが含まれるように決められている。図16には、MPEG TSストリーム中に所定間隔でPMTを含んだTSパケットが挿入されている様子を示している。図示の構成によれば、コンテンツの供給装置側ではコンテンツ保護に関するコピー制御情報などのコンテンツ属性を伝送ストリームの中で指定することができる。そして、コンテンツを受信するコンテンツ処理装置側では、コピー制御情報に従ってコンテンツの暗号モードの設定やコピーや記録の制限を行なうことができる。
【0136】
コンテンツのリモート・アクセスを許可するか否かは、コンテンツの著作権保護と深く関わっている。そこで、本発明者らは、リモート・アクセスが許容されるコンテンツを識別するためにディジタル制御記述子を利用する方法を提案する。
【0137】
1つの方法として、図14に示したディジタル制御記述子内の予約領域(reserved_future_use)をリモート・アクセスの可否を示すフラグ(以下では、「RA−flag」と呼ぶ)に定義して、RA=1のときにリモート・アクセス許可とし、RA=0のときにリモート・アクセス禁止とする。
【0138】
また、他の方法として、図14に示したディジタル・コピー制御記述子に含まれるコピー制御情報(CCI)を、リモート・アクセスの制御記述子としても併用する。例えば、コピー禁止(Never Copy)コンテンツはリモート・アクセス禁止とし、制御条件なしコピー可(Copy Free)コンテンツ並びに1世代のみコピー可(Copy One Generation)コンテンツはリモート・アクセス許可とする、などである。
【0139】
【表3】
【0140】
上述した識別方法は主に放送コンテンツに適用することができる。勿論、Blu−rayやDVD(Digital Versatile Disc)、フラッシュメモリーなどの記録メディアや、インターネット経由で配布されるコンテンツに関しても、記録メディアの著作権保護技術である、AACS(Advanced Access Content System)、CSS(Content Scramble System)、CPRMなどで定義されるディジタル・コピー制御記述子を用いて、同様の識別方法を実現することができる。
【0141】
Blu−rayディスクのリモート・アクセスの場合、その著作権保護技術であるAACSによって制御され、コンテンツ提供装置10内の記憶部14(HDDなど)にコピーされた後、DTCP−IPに受け渡され、リモート・アクセスに供される。
【0142】
コンテンツのリモート・アクセスを制御する「リモート・アクセス制御ファイル」は、XML(extensible Markup Language)言語で記述される。リモート・アクセス制御ファイルは、Blu−rayディスクの本編を対象とする「Managed Copy and Remote Access Manifest File」と、ポータブル・ファイルを対象とする「Remote Access Manifest File」からなる。これらのファイルは、JAVA(登録商標)ヴァーチャルマシンMCRAM(Managed Copy and Remote Access Machine)、又は、RAM(Remote Access Machine)に読み込まれて実行される。
【0143】
リモート・アクセス用のポータブル・ファイルが、Blu−rayディスク上のディレクトリー「PARTIALDB」に格納されていると仮定し、dest(destination)で指定されたHDD上のディレクトリーにコピーされてリモート・アクセスに供されると仮定した場合の一例を以下に示しておく。
【0144】
【数1】
【0145】
図17には、Blu−rayディスク上のコンテンツのリモート・アクセスを制御する仕組みを図解している。RA−Sourceとしてのコンテンツ提供装置10は、コンテンツ受信/再生部12によりBlu−rayディスクからJAVA(登録商標)アプリケーションを読み出して、CPU11のシステム・メモリにロードし、JAVA(登録商標)ヴァーチャルマシンを実行して、Blu−rayディスクから読み出したリモート・アクセス用コンテンツへのリモート・アクセスの制御を行なう。
【0146】
ここまでは、コンテンツに付随する著作権保護などの情報に基づいて、そのリモート・アクセスの可否を識別する方法について説明してきた。それ以外にも、コンテンツの状態に基づいてリモート・アクセスの可否を識別する方法も考えられる。
【0147】
例えば、ホームネットワーク・サーバーとして動作しているコンテンツ提供装置10の記憶部14(HDDなど)に、コピー制御に関する制約を外して蓄積されたコンテンツはすべて複製物、言い換えれば、コピーが許可されたコンテンツであるから、上記の表3に従い、リモート・アクセスが許可されているものとして扱うことができる。
【0148】
但し、放送コンテンツをコンテンツ受信/再生部12で受信し記憶部14に録画するような場合には、放送地域制限などの放送のビジネス・モデルを考慮して、放送中のリアルタイム・コンテンツについては、リモート・アクセスに制限を課すことが好ましい。具体的には、放送コンテンツを記憶部14に一旦蓄積し、一定時間が経過した後に、リモート・アクセスを許可するようにする。例えば、放送から30分遅れでコンテンツのリモート・アクセスを許可したり、放送終了後であればリモート・アクセスを許可したりする。あるいは、放送が終了してから、6時間後、12時間後、…、翌日以降、1週間後以降などの時間的制約を設定することが可能である。
【0149】
また、コンテンツに付随する著作権保護などの情報に基づいてリモート・アクセスの可否を識別する方法、コンテンツの状態に基づいてリモート・アクセスの可否を識別する方法のうちいずれか一方を単独で用いるのではなく、コンテンツ提供装置10に蓄積されたコンテンツについて、これら2つの方法を組み合わせてリモート・アクセスの可否を識別する方法も考えられる。記憶部14に蓄積されたコンテンツに付加されているコピー制御情報の他に、リモート・アクセスの可否を示すRA−flagを追加定義して、RA=1のときにリモート・アクセス許可とし、RA=0のときにリモート・アクセス禁止とする。コンテンツ利用装置20からコンテンツへのリモート・アクセスが要求されたときには、コンテンツ提供装置10は、要求されたコンテンツのRA−flagを参照して、リモート・アクセスを制御する。
【0150】
また、コンテンツ提供装置10は、RA−flagを追加定義するのではなく、記憶部14内にリモート・アクセスが許可されたコンテンツ、並びに、リモート・アクセスが禁止されたコンテンツをそれぞれ蓄積するための専用のファイル・フォルダー(あるいはパーティション)を設けて、例えばコンテンツ取得時にそのリモート・アクセスの可否を判断し、各ファイル・フォルダーに仕分けするようにしてもよい。このような場合、コンテンツ利用装置20は、リモート・アクセス許可コンテンツ用のファイル・フォルダーに蓄積されているコンテンツを自由にリモート・アクセスすることができるのに対し、リモート・アクセス禁止コンテンツ用のファイル・フォルダーに蓄積されているコンテンツにはリモート・アクセスすることはできない。
【0151】
D.リモート・アクセスの識別方法
ホームネットワーク・サーバーなどRA−Sourceとして動作するコンテンツ提供装置10は、これまで説明してきた方法によって、リモート・アクセスするコンテンツ利用装置20はリモート・アクセスが許可されたRA−Sinkであるか否か、並びに、コンテンツ利用装置20がリモート・アクセスを要求するコンテンツがリモート・アクセスを許可されているか否かを識別することができる。
【0152】
しかしながら、コンテンツ提供装置10は、そもそも、コンテンツ利用装置20からのアクセスが、リモート・アクセスか否かを正確に識別する必要がある。何故ならば、DTCP−IPの通常のホームネットワーク内にいるコンテンツ利用装置20によるコンテンツの利用は、著作権保護の観点からも正当な使用であり、アクセスが拒否されるとユーザーの利益を不当に害するものとなるからである。
【0153】
以下では、コンテンツ利用装置20から要求されるAKE手続きが、DTCP−IPの通常のホームネットワーク内の認証手続き(RTT−AKE)、又は、遠隔地からのリモート・アクセスによる認証手続き(RA−AKE)のいずれであるかを識別する方法について説明する。
【0154】
AKE control commandの構成は図8に示した通りである。DTCP−IPの通常のAKE control commandでは、Control(0)の上位4ビットは、reserved(ZERO)である。例えば、この4ビット長のフィールドをオール1にしてリモート・アクセス用の認証モード(Authentication Mode)と定義すれば、通常のDTCP−IPの通常のホームネットワーク内のAKE手続きと区別することが可能である。以下のAKE手続きは、DTCP−IPの通常のホームネットワーク内のAKE手続き(RTT−AKE)とは異なるリモート・アクセス用のAKE手続き(RA−AKE)となる。 また、Control(2)のsubfunctionとして、現在定義されていない値を用いてリモート・アクセス用のAKE control commandを定義することでも区別が可能である。
【0155】
あるいは、上述したようにAKE control command内にリモート・アクセスか否かの制御ビットを設けるのではなく、リモート・アクセス専用の認証手続きを新たに定義するようにしてもよい。DTCP−IPの通常のAKE control commandのControl(3)に割り当てられているAKE_procedureは、現行では、下位から4ビット目(Bit3)は、通常のAKE手続きはFull Authenticationで行なうのに対し、Extended Fulle Authenticationで行なうか否かを識別するフラグに定義されている。また、上位の4ビットは招来の拡張のための予約領域となっている。したがって、この上位4ビットの予約領域に、新たにリモート・アクセス用のFull Authenticationを定義して行なうことも考えられる。
【0156】
【表4】
【0157】
上述のようにして、リモート・アクセス用のAKE手続き(RA−AKE)が成立したならば、RA−Sourceとしてのコンテンツ提供装置10と、RA−Sinkとしてのコンテンツ利用装置20の間でリモート・アクセス用の交換鍵が共有される。そして、リモート・アクセス用に新たに設けた暗号化モードを用いて、コンテンツ伝送を行なうようにしてもよい。
【0158】
DTCP−IPでは、パケットのヘッダ部に記述するE−EMI(Extended Encryption Mode Indicator)と、EmbeddedCCI(Copy Control Information)という2つのメカニズムにより、コンテンツに付随したコピー制御情報の伝送を実現している。以下の表5には、現行のDTCP−IPの暗号モード(EMI)の一覧を示している。
【0159】
【表5】
【0160】
リモート・アクセスは、外部のネットワークを経由して接続されることから、そのコンテンツ保護レベルも、通常の家庭内のネットワークで使用されるものとは異なるレベルの暗号化モードが要求される。例えば、家庭内のネットワークにおけるコピー禁止(CN)、一世代のみコピー許可(COG)とは別に、リモート・アクセスにおけるコピー禁止(RA−CN)、一世代のみコピー許可(RA−COG)といった暗号化モードが必要である。そして、上記の表5の予約値を使用して、これらの新たなリモート・アクセス用暗号化モードを定義する。
【0161】
ここまでの説明では、通信システムが一対のRA−SourceとRA−Sinkだけで構成されることを想定していた。しかしながら、RA−SourceやRA−Sinkは、それぞれさらに別の機器とデイジーチェーン形式で接続され、コンテンツを伝送する可能性がある。著作権保護されたコンテンツの伝送範囲は、本来、家庭内に留めるべきであり、コンテンツの受信と再送信が何段にもわたり繰り返し行なわれることは好ましくない。このため、コンテンツの受信と再送信を技術的に阻止することが必要である。
【0162】
本実施形態では、コンテンツのリモート・アクセスの可否を示すRA−flagが各コンテンツに付加されており(前述)、このフラグを用いてコンテンツの再送信を制限する。
【0163】
例えば、ある機器が、RA−Sourceとしてのコンテンツ提供装置10に蓄積されているコンテンツにRA−flagが「リモート・アクセス可」を示す場合には、既に転送された(すなわち、RA−Sinkとして受信した)コンテンツであり、再送信を止めるべきであることが分かる。
【0164】
あるいは、コンテンツ提供装置10が、RA−Sinkとして受信したコンテンツを一時的にキャッシュし、記憶部14に蓄積し、あるいは一切記録せずに再送信しようとする際に、この受信コンテンツに付加されたRA−flagを「リモート・アクセス不可」に書き換えて、リモート・アクセスによる再送信を防止する。
【0165】
図18に示すシステム構成例では、RA−Source#0と接続するRA−Sink#1が、さらにRA−Source#1としての機能も備え、別の機器RA−Sink#2と接続している。このような場合、RA−Sink#1としてリモート・アクセスして受信したコンテンツを、RA−Source#1としてRA−Sink#2に再度リモート・アクセス出力することを禁止することによって、コンテンツ提供元であるRA−Source#0の管理が及ばない所でリモート・アクセスされるのを防止するように運用する。
【0166】
また、図19に示すシステム構成例では、RA−Sink#1が、リモート・アクセスによりRA−Source#0に接続するとともに、Source#1としての機能も備えDTCP−IPにより別の機器Sink#2に接続され、さらに、Sink#2がRA−Source#2としての機能も備えて別の機器RA−Sink#3と接続している。RA−Sink#1は、リモート・アクセスにより受信したコンテンツを、DTCP−IPを通じて別の機器Sink#2にローカル伝送することができる。DTCP−IPによるローカル伝送は、著作権保護の仕組みに則ったものであり、問題はない。また、Sink#2が受信したコンテンツを、RA−Source#2としてRA−Sink#3に再度リモート・アクセス出力することを禁止することによって、コンテンツ提供元であるRA−Source#0の管理が及ばない所でリモート・アクセスされるのを防止するように運用する。
【0167】
RA−flagは、RA=1のときにリモート・アクセス許可とし、RA=0のときにリモート・アクセス禁止とするように定義することは既に述べた通りである。ここで、現行のDTCP−IPではRA−flagは定義されていないことから、RA−flagを用いてリモート・アクセスの可否を制御する場合には、旧来のDTCP−IP機器との互換性が問題となる。
【0168】
例えば、リモート・アクセスの可否を示す制御ビットや、リモート・アクセス用のAKE手続きをDTCP−IPで新たに設けるのではなく、各機器がDTCP−IP経由で受け取ったコンテンツはすべてリモート・アクセス不可として扱うようにする。これによって、従来のDTCP−IP機器との互換性を保ちながら、従来のDTCP−IP機器を経由して受け取った(リモート・アクセスの可否が不明な)コンテンツをリモート・アクセス禁止にする。
【0169】
【表6】
【0170】
あるいは、上述のようにDTCP−IP経由で受け取ったコンテンツをすべてリモート・アクセス不可とする代わりに、コピー制御情報(CCI)を、リモート・アクセスの制御記述子としても併用することによって、旧来のDTCP−IP機器との互換性を保つことができる。
【0171】
具体的には、以下の表7の第2及び第3行に示すように、No more copy又はNever copyがエンコードされたコンテンツのみをリモート・アクセス不可として扱うことで、旧来のDTCP−IP機器との互換性を保ちながら、旧来のDTCP−IPを経由して受け取った(リモート・アクセスの可否が不明な)コンテンツをリモート・アクセス禁止にする。
【0172】
また、リモート・アクセス不可としないコンテンツについては、以下の表7の第4及び第5行に示すように、一旦記憶部14に蓄積した後にリモート・アクセスかとして扱い、蓄積する前の状態では、リモート・アクセス不可として取り扱う。
【0173】
【表7】
【0174】
本実施形態に係る通信システムによれば、DTCP−IPで著作権保護されたDLNAコンテンツに、家庭外の遠隔地からリモート・アクセスして、コンテンツを安全に利用することができる。
【0175】
また、本実施形態に係る通信システムでは、コンテンツのリモート・アクセスを制御するためのフラグの取り扱い方やリモート・アクセス時の認証方法(AKE手続き)を明示的に定義しているので、リモート・アクセスにおいても、従来の家庭内でのアクセスと同様に、DTCP−IPに基づくコンテンツの著作権保護環境を構築することができる。
【産業上の利用可能性】
【0176】
以上、特定の実施形態を参照しながら、本発明について詳細に説明してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
【0177】
本発明の適用例として、DTCP−IPが適用されるホームネットワーク上のサーバーに、家庭外のクライアントからリモート・アクセスしてコンテンツを利用する通信システムを挙げることができるが、本発明の要旨はこれに限定されない。著作権やその他の目的で保護が必要となるコンテンツを、往復遅延時間(RTT)やIPルーターのホップ回数(TTL)などの制限を超えつつ、WANなどの外部ネットワークを経由したリモート・アクセスを通じてコンテンツを伝送する他のあらゆるコンテンツ伝送システムに、同様に本発明を適用することができる。
【0178】
要するに、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、特許請求の範囲を参酌すべきである。
【符号の説明】
【0179】
10…コンテンツ提供装置(RA−source)
11…CPU
12…コンテンツ受信/再生部
13…通信部
14…記憶部
15…タイマー
20…コンテンツ利用装置(RA−sink)
21…CPU
22…通信部
23…コンテンツ出力部
24…記憶部
25…認証情報入力部
30、31…ルーター
40、41…モデム
50…WAN
60…IASサービス
70…DDNSサービス
【技術分野】
【0001】
本発明は、コンテンツの伝送における不正利用を防止する通信システム、通信装置及び通信方法、並びにコンピューター・プログラムに係り、特に、暗号化コンテンツを伝送するとともに、暗号化コンテンツの復号鍵を所定の相互認証及び鍵交換(AKE)アルゴリズムに従って交換する通信システム、通信装置及び通信方法、並びにコンピューター・プログラムに関する。
【0002】
さらに詳しくは、本発明は、WANなどの外部ネットワークを経由したリモート・アクセス(RA)を通じてコンテンツを安全に伝送する通信システム、往復遅延時間(RTT)やIPルーターのホップ回数(TTL)などの制限を超えつつ、リモート・アクセスを通じてコンテンツを安全に伝送する通信装置及び通信方法、並びにコンピューター・プログラムに係り、特に、通信システム、通信装置及び通信方法、並びにコンピューター・プログラムに関する。
【背景技術】
【0003】
従来、放送コンテンツやパッケージ・メディア中のコンテンツは、受信機器や再生機器が設置された場所、又は、これらの機器とホームネットワーク経由で接続された機器で利用すること(以下、「ローカル・アクセス(LA)」とも呼ぶ)が基本であった。例えば、屋外から携帯機器で上記の受信機器や再生機器と接続し、WAN(Wide Area Network)などの外部ネットワーク経由の伝送を伴ってコンテンツを利用すること(以下、「リモート・アクセス(RA)」とも呼ぶ)は、通信路やコーデックなどの技術的な観点から困難であった。しかし、将来的には、LTE(Long Term Evolution)やWiMAX(World Interoperability for Microwave Access)といったデータ通信技術、並びに、H.264などの高圧縮コーデックの普及が見込まれ、これらを活用することでリモート・アクセスの実現可能性が見えてくる。例えば、ユーザーが出先から自宅のサーバーにリモート・アクセスして、コンテンツを再生するという使い方である。
【0004】
他方、ディジタル化されたコンテンツはコピーや改竄などの不正な操作が比較的容易である。とりわけ、リモート・アクセスにおいては、個人的又は家庭的なコンテンツの使用を許容しながら、コンテンツ伝送に介在する不正利用の防止、すなわち著作権保護の仕組みが必要である。
【0005】
ディジタル・コンテンツの伝送保護に関する業界標準的な技術として、DTLA(Digital Transmission Licensing Administrator)が開発したDTCP(Digital Transmission Content Protection)が挙げられる。DTCPでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決められている。その規定は、要約すれば、DTCP準拠機器は取り扱いが容易な圧縮コンテンツを非暗号の状態で機器外に送出しないことと、暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換(Authentication and Key Exchange:AKE)アルゴリズムに従って行なうこと、並びにAKEコマンドにより鍵交換を行なう機器の範囲を制限することなどである。コンテンツ提供元であるサーバ(Source)とコンテンツ提供先であるクライアント(Sink)は、AKEコマンドの送受信により、認証手続きを経て鍵を共有化し、その鍵を用いて伝送路を暗号化してコンテンツの伝送を行なう。したがって、不正なクライアントは、サーバーとの認証に成功しないと暗号鍵を取得できないから、コンテンツを享受することはできない。
【0006】
DTCPは、原初的には、IEEE1394などを伝送路に用いたホームネットワーク上におけるコンテンツ伝送について規定したものである。最近では、DLNA(DigitalLiving Network Alliance)に代表されるように、家庭内においても、ディジタル化されたAVコンテンツをIPネットワーク経由で流通させようという動きが本格的になっている。そこで、家庭内においてもディジタル・コンテンツをIPネットワーク経由で流通させることを意図して、IPネットワークに対応したDTCP技術、すなわちDTCP−IP(DTCP mapping to IP)の開発が進められている。
【0007】
DTCP−IPは、DTCP技術をIPネットワークに移植した同様の技術であるが、伝送路にIPネットワークを使用すること、暗号化されたコンテンツの伝送にHTTP(Hyper Text Transfer Protocol)やRTP(Real−Time Transfer Protocol)といった、IPネットワーク上で実装されたコンテンツ伝送用プロトコルを使用する。例えば、HTTPの手続きに従ってコンテンツを伝送する場合、SourceがHTTPサーバーとなり、SinkがHTTPクライアントとなって、HTTPのためのTCP/IPコネクションが作成され、暗号化コンテンツのダウンロード伝送が行なわれる(但し、アップロード伝送を行なうときには、SourceがHTTPクライアントとなりSinkがHTTPサーバーとなる)。
【0008】
現在のDTCP−IP(DTCP Volume 1 Specification Supplement E Revision 1.2)は、主にコンテンツの家庭内のみの利用を確保することを意図したものである。このため、AKEコマンドに対し往復遅延時間(RTT:Round Trip Time)は最大7ミリ秒に制限され、また、IPルーターのホップ回数(TTL:Time To Live)の上限が3に設定されている。
【0009】
例えば、SourceがDTCP−IP認証を開始してから終了する直前までの間、受信した各AKEコマンドを監視し続け、TTL値の最大値を更新し続け、認証手続きが終了する直前にTTL値の最大値をチェックし、この最大値が3以下であれば鍵交換して認証手続きを完了するが、3を超えると、最終段階の処理を行なわずに認証手続きを終わらせる情報通信システムについて提案がなされている(例えば、特許文献1を参照のこと)。
【0010】
しかしながら、RTTやTTLの制限を課すと、家庭外の遠隔地から家庭内のホームネットワークのサーバーにある著作権保護されたコンテンツにアクセスすることはできない。
【0011】
ユーザーの利便性を考えると、コンテンツへのリモート・アクセスを許容したいが、著作権保護したいというコンテンツ・オーナーの利益とは相反する。
【先行技術文献】
【特許文献】
【0012】
【特許文献1】特開2007−36351号公報
【発明の開示】
【発明が解決しようとする課題】
【0013】
本発明の目的は、暗号化コンテンツの復号鍵を所定の相互認証及び鍵交換(AKE)アルゴリズムに従って交換して、コンテンツの伝送における不正利用を好適に防止することができる、優れた通信システム、通信装置及び通信方法、並びにコンピューター・プログラムを提供することにある。
【0014】
本発明のさらなる目的は、往復遅延時間(RTT)やIPルーターのホップ回数(TTL)などの制限を超えつつ、WANなどの外部ネットワークを経由したリモート・アクセスを通じてコンテンツを安全に伝送することができる、優れた通信システム、通信装置及び通信方法、並びにコンピューター・プログラムを提供することにある。
【課題を解決するための手段】
【0015】
本願は、上記課題を参酌してなされたものであり、請求項1に記載の発明は、コンテンツを提供するコンテンツ提供装置とコンテンツを利用する1以上のコンテンツ利用装置でコンテンツ伝送のための通信を行なう通信システムであって、
リモート・アクセスするコンテンツ利用装置を、コマンドの往復遅延時間に関する制限を課さないリモート・アクセス用の相互認証手続きに従って認証する認証手段と、
前記コンテンツ利用装置からリモート・アクセスにより要求されたコンテンツがリモート・アクセスを許容されているか否かを識別する識別手段と、
前記識別手段による識別結果及び前記認証手段による認証結果に応じて、前記コンテンツ提供装置から認証された前記コンテンツ利用装置へ、前記要求されたコンテンツを伝送する伝送手段と、
を具備することを特徴とする通信システムである。
【0016】
但し、ここで言う「システム」とは、複数の装置(又は特定の機能を実現する機能モジュール)が論理的に集合した物のことを言い、各装置や機能モジュールが単一の筐体内にあるか否かは特に問わない。
【0017】
本願の請求項2に記載の発明は、
リモート・アクセスするコンテンツ利用装置を、コマンドの往復遅延時間に関する制限を課さないリモート・アクセス用の相互認証手続きに従って認証する認証手段と、
コンテンツ利用装置からリモート・アクセスにより要求されたコンテンツがリモート・アクセスを許容されているか否かを識別する識別手段と、
コンテンツ利用装置へ要求されたコンテンツを提供する提供手段と、
を具備し、
前記提供手段は、リモート・アクセスによりコンテンツを要求するコンテンツ利用装置に対し、前記識別手段による識別結果及び前記認証手段による認証結果に応じて、コンテンツを提供する、
ことを特徴とする通信装置である。
【0018】
本願の請求項3に記載の発明によれば、請求項2に係る通信装置の認証手段は、リモート・アクセス用の相互認証手続きに際し、IPルーターのホップ回数に関する制限をも課さないように構成されている。
【0019】
本願の請求項4に記載の発明によれば、請求項2に係る通信装置の識別手段は、要求されたコンテンツの所定の制御記述子に重畳されている、リモート・アクセスの可否を示す情報に基づいて、リモート・アクセスを許容されているか否かを識別するように構成されている。
【0020】
本願の請求項5に記載の発明によれば、請求項2に係る通信装置の識別手段は、要求されたコンテンツの所定の制御記述子の記載内容に基づいて、リモート・アクセスを許容されているか否かを識別するように構成されている。
【0021】
本願の請求項6に記載の発明によれば、請求項2に係る通信装置の識別手段は、要求されたコンテンツの所定の制御記述子に含まれるコピー制御情報の記載内容に基づいて、リモート・アクセスを許容されているか否かを識別するように構成されている。
【0022】
本願の請求項7に記載の発明によれば、請求項2に係る通信装置は、コンテンツを蓄積することができる記憶部をさらに備え、識別手段は、記憶部にコピーされているコンテンツはリモート・アクセスを許可されていると識別するように構成されている。
【0023】
本願の請求項8に記載の発明によれば、請求項2に係る通信装置は、放送コンテンツを受信する受信部をさらに備え、識別手段は、放送中のリアルタイム・コンテンツについては、放送終了後からの経過時間に基づいてリモート・アクセスを許容されているか否かを識別するように構成されている。
【0024】
本願の請求項9に記載の発明によれば、請求項2に係る通信装置は、放送コンテンツを受信する受信部と、コンテンツを蓄積することができる記憶部をさらに備え、識別手段は、受信した放送コンテンツを、前記記憶部に一旦蓄積した後にリモート・アクセスを許可されていると識別するように構成されている。
【0025】
本願の請求項10に記載の発明によれば、請求項2に係る通信装置は、リモート・アクセス可能コンテンツを記憶する第1の領域とリモート・アクセス不可コンテンツを記憶する第2の領域を有する記憶部をさらに備え、各コンテンツを識別手段による識別結果に基づいて前記第1又は第2の領域に仕分けして記憶部に蓄積するように構成されている。
【0026】
本願の請求項11に記載の発明によれば、請求項2に係る通信装置は、コマンドの往復遅延時間に関する制限を課した登録用の相互認証手続きを経てコンテンツ利用装置を事前に登録する登録手段をさらに備え、認証手段は、リモート・アクセスするコンテンツ利用装置が前記登録手段により登録されているときのみ認証手続きを行なうように構成されている。
【0027】
本願の請求項12に記載の発明によれば、請求項11に係る通信装置の登録手段は、登録用の相互認証手続きに際し、IPルーターのホップ回数に関する制限をさらに課すように構成されている。
【0028】
本願の請求項13に記載の発明によれば、請求項11に係る通信装置の登録手段は、コンテンツ利用装置の事前登録時に、ユーザーID、パスフレーズ若しくはキー、ユーザーの生体情報、又はその他のリモート・アクセス用の認証情報を併せて登録し、認証手段は、リモート・アクセスするコンテンツ利用装置を認証する際に、前記の事前登録した認証情報を用いた認証処理を併せて行なうように構成されている。
【0029】
本願の請求項14に記載の発明によれば、請求項13に係る通信装置の認証手段は、リモート・アクセス用の認証情報を書き込んだポータブル・メディアを通じて事前登録した認証情報を用いた認証処理を行なうように構成されている。
【0030】
本願の請求項15に記載の発明によれば、請求項11に係る通信装置の認証手段は、当該装置に紐付けされたドングルを通じてリモート・アクセスするコンテンツ利用装置を認証するように構成されている。
【0031】
本願の請求項16に記載の発明によれば、請求項11に係る通信装置の登録手段はコンテンツ利用装置を事前登録する際に、当該コンテンツ利用装置がリモート・アクセス時に利用する1以上のコンテンツを併せて登録し、提供手段は、リモート・アクセスするコンテンツ利用装置に対し、前記のリモート・アクセス時に利用するとして事前登録されたコンテンツのみを提供するように構成されている。
【0032】
本願の請求項17に記載の発明によれば、請求項2に係る通信装置の認証手段は、前記リモート・アクセス用の相互認証手続きに代えて、所定の認証サーバーに対するログイン処理を通じて前記リモート・アクセスするコンテンツ利用装置の認証手続きを行なうように構成されている。
【0033】
本願の請求項18に記載の発明によれば、請求項2に係る通信装置の認証手段は、コンテンツ利用装置からの相互認証制御コマンドに設けられている、リモート・アクセスの可否を示す情報ビットに基づいて、リモート・アクセスするコンテンツ利用装置を認証するように構成されている。
【0034】
本願の請求項19に記載の発明によれば、請求項2に係る通信装置の認証手段は、リモート・アクセス専用の相互認証手続きに従って、リモート・アクセスするコンテンツ利用装置を認証するように構成されている。
【0035】
本願の請求項20に記載の発明によれば、請求項18又は19のいずれかに係る通信装置の提供手段は、リモート・アクセス専用の暗号化モードを用いて、コンテンツ利用装置からリモート・アクセスにより要求されたコンテンツを暗号化伝送するように構成されている。
【0036】
本願の請求項21に記載の発明によれば、請求項18又は19のいずれかに係る通信装置の提供手段は、コンテンツのリモート・アクセスによる再出力を禁止するように構成されている。
【0037】
本願の請求項22に記載の発明によれば、請求項18又は19のいずれかに係る通信装置はコンテンツを蓄積することができる記憶部をさらに備え、提供手段は、記憶部に蓄積されているコンテンツにリモート・アクセスが可能であることを示す情報が付加されているときには、リモート・アクセスによる再出力を禁止するように構成されている。
【0038】
本願の請求項23に記載の発明によれば、請求項18又は19のいずれかに係る通信装置はコンテンツを蓄積することができる記憶部をさらに備え、識別手段は、リモート・アクセスが可能であることを示す情報が付加されたコンテンツを記憶部に蓄積する際に、当該情報をリモート・アクセス不可に書き換えるように構成されている。
【0039】
本願の請求項24に記載の発明によれば、請求項18又は19のいずれかに係る通信装置の識別手段は、著作権保護が施された所定のプロトコルに従って受け取ったコンテンツにリモート・アクセスの可否を示す情報が付加されていないときには、当該コンテンツをリモート・アクセス不可として扱うように構成されている。
【0040】
本願の請求項25に記載の発明によれば、請求項18又は19のいずれかに係る通信装置の識別手段は、著作権保護が施された所定のプロトコルに従って受け取ったコンテンツにリモート・アクセスの可否を示す情報が付加されていないときには、当該コンテンツに設定されているコピー制御情報に基づいて、当該コンテンツがリモート・アクセスを許容されているか否かを識別するように構成されている。
【0041】
本願の請求項26に記載の発明によれば、請求項25に係る通信装置はコンテンツを蓄積することができる記憶部をさらに備え、識別手段は、リモート・アクセスを不可としないコンテンツについては、前記記憶部に一旦蓄積した後にリモート・アクセス可として扱い、前記記憶部に蓄積する前の状態ではリモート・アクセス不可として扱うように構成されている。
【0042】
また、本願の請求項27に記載の発明は、
リモート・アクセスするコンテンツ利用装置を、コマンドの往復遅延時間に関する制限を課さないリモート・アクセス用の相互認証手続きに従って認証する認証ステップと、
コンテンツ利用装置からリモート・アクセスにより要求されたコンテンツがリモート・アクセスを許容されているか否かを識別する識別ステップと、
コンテンツ利用装置へ要求されたコンテンツを提供する提供ステップと、
を有し、
前記提供ステップでは、リモート・アクセスによりコンテンツを要求するコンテンツ利用装置に対し、前記識別ステップにおける識別結果及び前記認証ステップにおける認証結果に応じて、コンテンツを提供する、
ことを特徴とする通信方法である。
【0043】
また、本願の請求項28に記載の発明は、ネットワーク経由でコンテンツを提供するための処理をコンピューター上で実行するようにコンピューター可読形式で記述されたコンピューター・プログラムであって、前記コンピューターを、
リモート・アクセスするコンテンツ利用装置を、コマンドの往復遅延時間に関する制限を課さないリモート・アクセス用の相互認証手続きに従って認証する認証手段、
コンテンツ利用装置からリモート・アクセスにより要求されたコンテンツがリモート・アクセスを許容されているか否かを識別する識別手段、
コンテンツ利用装置へ要求されたコンテンツを提供する提供手段、
として機能させ、
前記提供手段は、リモート・アクセスによりコンテンツを要求するコンテンツ利用装置に対し、前記識別手段による識別結果及び前記認証手段による認証結果に応じて、コンテンツを提供する、
ことを特徴とするコンピューター・プログラムである。
【0044】
本願の請求項28に係るコンピューター・プログラムは、コンピューター上で所定の処理を実現するようにコンピューター可読形式で記述されたコンピューター・プログラムを定義したものである。換言すれば、本願の請求項28に係るコンピューター・プログラムをコンピューターにインストールすることによって、コンピューター上では協働的作用が発揮され、本願の請求項2に係る通信装置と同様の作用効果を得ることができる。
【発明の効果】
【0045】
本発明によれば、往復遅延時間(RTT)やIPルーターのホップ回数(TTL)などの制限を超えつつ、WANなどの外部ネットワークを経由したリモート・アクセスを通じてコンテンツを安全に伝送することができる、優れた通信システム、通信装置及び通信方法、並びにコンピューター・プログラムを提供することができる。
【0046】
本発明によれば、コンテンツ・オーナーが許容するコンテンツの範囲内に限り、コンテンツを保護しながらユーザーのリモート・アクセスを実施することかできる、優れた通信システム、通信装置及び通信方法、並びにコンピューター・プログラムを提供することができる。
【0047】
本願の請求項1、2、3に記載の発明によれば、リモート・アクセスするコンテンツ利用装置に対してはRTT及びTTLの制限を外した相互認証手続きを適用するので、リモート・アクセスが可能である。また、リモート・アクセスするコンテンツ利用装置に対しリモート・アクセスが許容されたコンテンツのみを提供するので、DTCP−IPで著作権保護されたDLNAコンテンツに、家庭外の遠隔地からリモート・アクセスして、コンテンツを安全に利用することができる。
【0048】
また、本願の請求項4乃至10に記載の発明によれば、コンテンツのリモート・アクセスを制御するためのフラグの取り扱い方を明示的に定義しているので、リモート・アクセスにおいても、従来の家庭内でのアクセスと同様に、DTCP−IPに基づくコンテンツの著作権保護環境を構築することができる。
【0049】
また、本願の請求項1、2、3、11乃至17に記載の発明によれば、コンテンツ利用装置がリモート・アクセスしたときに認証方法(AKE手続き)を明示的に定義しているので、リモート・アクセスにおいても、従来の家庭内でのアクセスと同様に、DTCP−IPに基づくコンテンツの著作権保護環境を構築することができる。
【0050】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
【図面の簡単な説明】
【0051】
【図1】図1は、本発明に係る通信システムの一構成例を模式的に示した図である。
【図2】図2は、本発明に係る通信システムの他の構成例を模式的に示した図である。
【図3】図3は、コンテンツ提供装置10の機能的構成を模式的に示した図である。
【図4】図4は、コンテンツ利用装置20の機能的構成を模式的に示した図である。
【図5】図5は、SourceとSinkの間でDTCP−IPにより暗号化コンテンツ伝送を行なう仕組みを説明するための図である。
【図6】図6は、SourceとSink間で現行のDTCP−IPに従って行なわれる、AKEコマンドを用いた相互認証及び鍵交換の動作シーケンスを示した図である。
【図7】図7は、RA−SourceにRA−Sinkを事前登録する際の認証シーケンス例を示した図である。
【図8】図8は、AKE control commandの構成を示した図である。
【図9】図9は、RA−SourceがRA−Sinkを事前登録するための「RA−Sink Registratoin」処理の手順を示したフローチャートである。
【図10】図10は、RA−SinkがRA−AKE手続きによりRA−Sourceからリモート・アクセス用の交換鍵を取得するとともに、RA−Sourceにコンテンツを要求するコンテンツ取得シーケンス例を示した図である。
【図11】図11は、RA−SourceがRA−Sinkの登録確認及び認証処理を行なうための「RA−Sink ID confirmation」処理の手順を示したフローチャートである。
【図12】図12は、コンテンツ提供装置10がコンテンツに付加されたリモート・アクセス可否情報に基づいてリモート・アクセスを制御するための仕組みを説明するための図である。
【図13】図13は、TSパケットの構造を模式的に示した図である。
【図14】図14は、ディジタル・コピー制御記述子のデータ構造を示した図である。
【図15】図15は、PMTの詳細な構造を示した図である。
【図16】図16は、MPEG TSストリーム中に所定間隔でPMTを含んだTSパケットが挿入されている様子を示した図である。
【図17】図17は、Blu−rayディスク上のコンテンツのリモート・アクセスを制御する仕組みを示した図である。
【図18】図18は、RA−Source、RA−Sinkがさらに別の機器にデイジーチェーン接続され、受信したコンテンツをさらに出力する可能性があるシステム構成例を模式的に示した図である。
【図19】図19は、RA−Source、RA−Sinkがさらに別の機器にデイジーチェーン接続され、受信したコンテンツをさらに出力する可能性があるシステム構成例を模式的に示した図である。
【発明を実施するための形態】
【0052】
以下、図面を参照しながら本発明の実施形態について詳細に説明する。
【0053】
A.システム構成
本発明は、WANなどの外部ネットワークを経由したリモート・アクセス(RA)を通じてコンテンツを安全に伝送する通信システムに関するものであり、同通信システムは、基本的に、リモート・アクセスによりコンテンツを提供するサーバ(RA−Source)と、リモート・アクセスによりコンテンツを要求するクライアント(RA−Sink)からなる。本明細書では、リモート・アクセス時に行なうAKE手続きを、「RA−AKE」と呼ぶことにする以下、図面を参照しながら本発明の実施形態について詳細に説明する。
【0054】
図1には、本発明に係る通信システムの一構成例を模式的に示している。図示の通信システムでは、RA−Sourceに相当するコンテンツ提供装置10が家庭内に設置され、RA−Sinkに相当するコンテンツ利用装置20が屋外にいる。そして、コンテンツ利用装置20は、携帯電話のような通信機能によってコンテンツ提供装置10に対してリモート・アクセスする。
【0055】
コンテンツ提供装置10は、一般にルーター30とモデム40経由でWAN50などの外部ネットワークに接続される。WAN50は例えばインターネットである。ルーター30には、WAN50側のIPアドレスが、ユーザーが加入するIntenet Accsess Service(IAS)プロバイダー60から割り当てられる。また、コンテンツ利用装置20も、基本的にこのIPアドレスにアクセスする。ルーター30は、コンテンツ提供装置10にはプライベートIPアドレスを割り当て、WAN50からのアクセスについてはポート・フォワーディングによって通信を中継する。なお、ルーター30に割り当てられるIPアドレスは、IASプロバイダー60によって更新される場合があるが、そのようなケースではDDNSサービス70を用い、ルーター30乃至コンテンツ提供装置10のDDNS(Dynamic DNS(Domain Name System))機能を使うことで対応できる。
【0056】
また、図2には、本発明に係る通信システムの他の構成例を模式的に示している。図示の通信システムでは、RA−Sinkに相当するコンテンツ利用装置20も家庭内に設置され、ルーター31とモデム41経由でWAN50に接続されている。コンテンツ利用装置20から発信されるTCP/IP(Transmission Control Protocol/Internet Protocol)通信は、ルーター31のNAT(Network Address Translation)機能によってアドレス変換されるが、それ以外は図1の場合と同様である。
【0057】
図3には、コンテンツ提供装置10の機能的構成を模式的に示している。コンテンツ提供装置10は、CPU(Central Processing Unit)11と、コンテンツ受信/再生部12と、通信部13と、記憶部14と、タイマー15を備えるが、ホームネットワーク・サーバー並びにRA−Sourceとして機能して、リモート・アクセスでコンテンツを送信する。
【0058】
コンテンツ受信/再生部12は、放送受信機能や、パッケージ・メディア再生機能をそなえている。CPU11は、コンテンツ受信/再生部12で得られるコンテンツについて、リモート・アクセス可能なものを適切な保護を施した後に、通信部13を通じて、RA−AKEにより相互認証及び鍵交換を行なったRA−Sink(コンテンツ利用装置20)に送信する。
【0059】
記憶部14には、後述の登録処理によって記憶することになったRA−Sinkの識別情報(Device ID)や認証情報(リモート・アクセス用のユーザーID、パスフレーズあるいはキー、ユーザーの生体情報など)、RA−AKEを通じてRA−Sinkと共有した交換鍵とその識別情報などが記憶される。また、記憶部14は、コンテンツ受信/再生部12で得たコンテンツを蓄積する用途で用いることもできる。
【0060】
タイマー15は、リモート・アクセス可能なコンテンツを扱う際に時間管理が必要となる場合に使われる。
【0061】
図4には、コンテンツ利用装置20の機能的構成を模式的に示している。コンテンツ利用装置20は、CPU21と、通信部22と、コンテンツ出力部23と、記憶部24と、認証情報入力部25を備えるが、RA−Sinkとして機能して、リモート・アクセスでコンテンツを受信する。
【0062】
RA−Sinkとしてのコンテンツ利用装置20は、通信部22を通じてRA−Source(コンテンツ提供装置10)に対して後述の機器登録処理を行なう他、RA−AKEを行なってRA−Sourceから交換鍵を取得して記憶部24に保持するとともに、その鍵を基に算出する暗号鍵でRA−Sourceから得た暗号化コンテンツを復号して、コンテンツ出力部23からコンテンツを出力する。記憶部24は、RA−Sourceから受け取った交換鍵やコンテンツを蓄積する用途で用いられる。
【0063】
認証情報入力部25は、ユーザーがパスフレーズあるいはキーを入力するための入力操作部、ユーザーの生体情報を取得するための生体情報読取部、パスフレーズあるいはキーを記録したポータブル・メディアを装着するメディア装着部、ドングルなどのホームネットワーク・サーバーに紐付けされたハードウェア・キーを装着するドングル装着部などからなる。
【0064】
以下の説明では、交換鍵から暗号鍵を算出する方法はDTCP−IPに従うものとする(但し、本発明の要旨は必ずしもこの方法には限定されない)。
【0065】
ここで、SourceとSinkの間でDTCP−IPにより暗号化コンテンツ伝送を行なう仕組みについて、図5を参照しながら説明しておく。コンテンツ伝送の形態は、Source上のコンテンツをSinkにコピーする方法と、SourceからSinkへコンテンツを移動してSourceにコンテンツを残さない方法があるが(周知)、同図では前者のコピーによるコンテンツ伝送方法を前提にして説明する。
【0066】
SourceとSinkは、まず1つのTCP/IPコネクションを確立して、機器同士の認証(AKE手続き)を行なう。DTCP準拠機器には、DTLA(前述)により発行された機器証明書が埋め込まれている。AKE手続きでは、互いが正規のDTCP準拠機器であることを確かめた後、認証鍵KauthをSourceとSinkで共有することができる。
【0067】
AKE手続きが成功すると、Sourceはコンテンツ鍵Kcの種となる交換鍵Kxを生成し、認証鍵Kauthで暗号化してSinkに送る。Source及びSinkそれぞれにおいて、交換鍵Kxに対して所定の演算処理を適用することによって、コンテンツ伝送時にコンテンツを暗号化するために使用されるコンテンツ鍵Kcを生成することができる。
【0068】
そして、DTCP準拠の機器間でAKEによる認証及び鍵交換手続きが済んだ後、HTTPやRTPなどのプロトコルを利用してコンテンツ伝送が開始される。図示の例では、HTTPの手続きに従ってコンテンツ伝送が行なわれる。その際、AKE手続きのためのTCP/IPコネクションとは別に、HTTPのためのTCP/IPコネクションが作成される(すなわち、SourceとSinkはそれぞれ、AKE手続き用とコンテンツ伝送用に個別のソケット情報(IPアドレスとポート番号の組み合わせ)を持つ)。
【0069】
HTTPプロトコルに従ってコンテンツ伝送を行なうには、SinkがSourceにコンテンツを要求するダウンロード形式と、Source側からSinkにコンテンツをプッシュするアップロード形式の2通りが挙げられる。前者の場合、HTTPクライアントとしてのSinkは、例えばHTTP GETメソッドを用いたHTTPリクエストにより、HTTPサーバーとしてのSourceにコンテンツを要求し、これに対しSouceからは要求通りのコンテンツがHTTPレスポンスとして伝送される。また後者の場合、HTTPクライアントとしてのSourceは、例えばHTTP POSTメソッドを用いたHTTPリクエストにより、HTTPサーバーとしてのSinkとの伝送を開始する。
【0070】
Sourceから伝送されるデータは、SourceがAKE認証をした後に共有した鍵を用いてコンテンツを暗号化したデータとなっている。具体的には、Sourceは、乱数を用いてノンスNcを生成して、交換鍵KxとノンスNcと暗号モードに応じたコンテンツ鍵Kcを生成する。そして、Sinkから要求されているコンテンツを、コンテンツ鍵Kcを用いて暗号化し、暗号化コンテンツからなるペイロードとノンスNcと暗号モードの情報を含んだヘッダからなるパケットをTCPストリーム上に乗せて送信する。IPプロトコルでは、TCPストリームを所定の単位となるパケットの大きさに分割し、さらにヘッダ部を付加したIPパケットにし、指定されたIPアドレス宛てに届ける。
【0071】
Sink側では、Sourceからの各IPパケットを受信すると、これをTCPストリームに組み立てる。そして、このストリームからノンスNcとE−EMIを取り出すと、これらと交換鍵Kxを用いてコンテンツ鍵Kcを算出し、暗号化コンテンツを復号することができる。そして、復号化した後の平文のコンテンツに対し再生処理を実施することができる。あるいは、Sinkは、暗号化コンテンツを復号することなく、コンテンツを記憶部24に格納したり、他の機器にスルーしたりする。このようにしてHTTPプロトコルを利用したコンテンツ伝送が終了すると、例えばSink側から、コンテンツ伝送に使用したTCPコネクションを適宜切断する。(DTCP−IPでは、パケットのヘッダ部に記述するE−EMI(ExtendedEncryption Mode Indicator)と、Embedded CCI(Copy Control Information)という2つのメカニズムにより、コンテンツに付随したコピー制御情報の伝送を実現している。)
【0072】
なお、DTCP−IPでは、交換鍵Kxを定期的(例えば2時間毎)に更新することが規定されている。SinkはSourceから最新の交換鍵Kxを入手できなければ、暗号化コンテンツを利用不能となる。また、Sourceが単一の交換鍵Kxを生成して複数台の(正当な)Sinkに配る方法と、Sink毎に異なる交換鍵Kxを生成する方法が考えられるが、以下の説明では前者の方法を採用するものとする。
【0073】
図6には、SourceとSink間で現行のDTCP−IPに従って行なわれる、AKEコマンドを用いた相互認証及び鍵交換の動作シーケンス(RTT−AKE)を示している。
【0074】
AKE手続きのチャレンジ・レスポンス部分(Challenge−Response portion of AKE)では、まず、コンテンツを要求するSinkから、Rx乱数とRx証明書を含んだRxチャレンジが送信される。これに対し、Sourceからは、Tx乱数及びTx証明書を含んだTxチャレンジが返信される。以降、Sourceから、Rx乱数、Txメッセージ、Tx署名を含んだRxレスポンスが送信されるとともに、SinkからはTx乱数、Rxメッセージ、Rx署名を含んだTxレスポンスが送信され、通常のチャレンジ・レスポンス認証手続きが続く。チャレンジ・レスポンス部分で送信されるコマンドには、各チャレンジ・コマンドには、機器固有の識別情報であるDevice IDが含まれている。
【0075】
上記のチャレンジ・レスポンス応答手続きでは、TTL(IPルーターのホップ回数)の制限が課されている。すなわち、現在のDTCP−IPでは、送信機器はAKEで用いるコマンドを送るTCP/IP通信においてTTLが3以下に設定され、受信機器はTTLが3より大きい場合は受け取ったデータを無効にしなければならない。
【0076】
その後、RTT保護プロトコル(Protected RTT Protocol)を経て、SourceからSinkへ、EXCHANGE_KEYコマンドが送信され、これに対し、Sinkからレスポンス(図示しない)が返される。
【0077】
図6に示した現行のDTCP−IPに従うRTT−AKEでは、AKEコマンドに対し往復遅延時間(RTT)やIPルーターのホップ回数(TTL)が制限されている。現状のままでは、家庭外の遠隔地から家庭内のホームネットワークのサーバーにある著作権保護されたコンテンツにアクセスすることはできない(前述)。しかしながら、ユーザーの利便性を考えると、ユーザーが出先から自宅のサーバーにリモート・アクセスして、コンテンツを再生するという使い方が望まれる。勿論、著作権保護したいというコンテンツ・オーナーの利益を確保する必要がある。したがって、リモート・アクセスは、コンテンツ・オーナーが許容するコンテンツの範囲内に制限すべきであり、且つ、リモート・アクセスされるコンテンツの保護も行なわなければならない。
【0078】
これに対し、本発明として提案する、リモート・アクセス時のAKE手続きすなわちRA−AKEでは、図6に示したRTT−AKE手続きで行なっている「Protected RTT Protocol」を行なわない。すなわち、SourceとSinkの間のRTTが7ミリ秒を超えてもAKE手続きを中止しない。また、RA−AKEでは、上記のTTLの上限を設けない。すなわち、RA−AKEでは、RTT並びにTTLの制限を設けないことで、リモート・アクセスに対応するSource(コンテンツ提供装置10)と、リモート・アクセスに対応するSink(コンテンツ利用装置20)が、応答遅延時間が7ミリ秒を超え、又は、ホップ数が3を超えるだけ離間していたとしても、両機器間でAKE手続きを成功裏に実施して、リモート・アクセス用の交換鍵を共有することができる。
【0079】
但し、RTT並びにTTLの制限が外された状態の通信システムでは、任意の機器間でコンテンツの伝送が可能になるため、コンテンツの著作権保護の観点から不正な利用を防止する仕組みが必要になる。
【0080】
本発明者らは、RTT並びにTTLの制限を外して、コンテンツ・オーナーが許容する範囲内でユーザーのリモート・アクセスを実現するには、リモート・アクセスが許容されるコンテンツを識別することと、リモート・アクセスする機器(すなわち、コンテンツ利用装置20)がホームネットワークの一員であることを確認することが必要であると思料する。以下では、リモート・アクセス可能なコンテンツの識別方法と、リモート・アクセス用端末の認証方法の各々について詳細に説明する。
【0081】
B.リモート・アクセス用端末の認証
まず、リモート・アクセスする機器がームネットワークの一員であることを確認するための方法について説明する。
【0082】
不正なユーザーからの接続を制限するために、RA−Sourceが事前に登録されたRA−SinkとだけRA−AKE手続きを行なうようにする。具体的には、現在のDTCP−IPのRTT−AKEと同様に、RTTやTTL制限を伴うAKE手続きに成功した場合にだけ、RA−SourceがRA−Sinkの機器固有IDを記憶して登録する。RA−Sinkの登録手続きは、例えば、RTT並びにTTLの制限に収まる家庭内で事前に行なわれる。したがって、不正なユーザーは、リモート環境から事前登録できないので、RA−AKE手続きを成功できなくなる。
【0083】
図7には、RA−SourceにRA−Sinkを事前登録する際の認証シーケンス例を示している。
【0084】
この認証シーケンスは、RA−SinkがRA−Sourceに対して登録要求コマンド「RA_REGI_INIT」を送信することによって開始する。RA−AKE手続きのチャレンジ・レスポンス部分(Challenge−Response portion of AKE)では、まず、RA−Sinkから、Rx乱数とRx証明書を含んだRxチャレンジが送信される。これに対し、RA−Sourceからは、Tx乱数及びTx証明書を含んだTxチャレンジが返信される。以降、RA−Sourceから、Rx乱数、Txメッセージ、Tx署名を含んだRxレスポンスが送信されるとともに、RA−SinkからはTx乱数、Rxメッセージ、Rx署名を含んだTxレスポンスが送信される。
【0085】
各チャレンジ・コマンドには、機器固有の識別情報であるDevice IDが含まれている。但し、同チャレンジ・レスポンス部分の中では、SinkからSourceへのレスポンスとして「RESPONSE2」が送られることがある。これは、機器がCommon Device KeyとCommon Device Certificateを実装することで、Device IDが機器固有とならない場合である。RESPONSE2が送られる場合は、機器固有の識別情報として、Device IDではなく、RESPONSE2に含まれる機器固有情報であるIDuを使うことになる。なお、Device IDやIDuではなく、WiFi用のMAC(Media Access Control)アドレスを機器固有情報に用いることもできる。
【0086】
登録手続きにおけるRA−AKE手続きのチャレンジ・レスポンス部分は、現行のDTCP−IPにおけるRTT−AKE手続きと同様の処理となり、TTLの制限が課されている。その後、RTT保護プロトコル(Protected RTT Protocol)がさらに続き、RA−SourceとRA−Sinkの間のRTTが7ミリ秒を超えるとRA−AKE手続きを中止する。
【0087】
RA−Sourceは、ここまでの手順に成功したRA−Sinkを登録するための「RA−Sink Registratoin」処理を実行する。そして、RA−Sourceは、記憶部14内のRAレジストリーにRA−SinkのIDを登録できる余裕があれば追加登録し、その結果を、結果コードとして、コマンド「RA_REGI_END」でRA−Sinkに通知する。
【0088】
なお、図7中の「RA_REGI_INIT」と「RA_REGI_END」は、DTCP−IPのAKE control commandにリモート・アクセス用のコマンドとして追加するものとする。図8には、リモート・アクセス用のAKE control commandの構成例を示している。図示の例では、subfunctionフィールドに新たな値を割り当て、AKE_Infoで情報を運ぶことができる。
【0089】
図9には、RA−SourceがRA−Sinkを登録するための「RA−Sink Registratoin」処理の手順をフローチャートの形式で示している。
【0090】
RA−Sourceは、まず、当該処理ルーチンを開始する以前の処理(Challenge−Response portion of AKE、並びに、Protected RTT Protocol)を異常終了(abort)したか否かをチェックする(ステップS1)。
【0091】
ここで、以前の処理を異常終了していた場合には(ステップS1のNo)、RA−Sourceは、要求元のRA−Sinkに対し、登録処理に「失敗」した旨の結果コードを通知して(ステップS9)、本処理ルーチンを終了する。
【0092】
また、以前の処理を正常に終了していた場合には(ステップS1のYes)、RA−Sourceは、RESPONSE2(前述)を受信したか否かをチェックする(ステップS2)。そして、RESPONSE2を受信したときには(ステップS2のYes)、RA−Sourceは、要求元のRA−SinkのIDをIDuとする(ステップS3)。また、RESPONSE2を受信していないときには(ステップS2のNo)、RA−Sourceは、要求元のRA−SinkのDevice IDをIDとする(ステップS4)。
【0093】
次いで、RA−Sourceは、要求元のRA−SinkのIDを既に登録済みか否かをチェックする(ステップS5)。
【0094】
ここで、要求元のRA−SinkのIDを既に登録済みである場合には(ステップS5のYes)、RA−Sourceは、要求元のRA−Sinkに対し、登録処理に「成功」した旨の結果コードを通知して(ステップS8)、本処理ルーチンを終了する。
【0095】
他方、要求元のRA−SinkのIDをまだ登録していないときには(ステップS5のNo)、RA−Sourceは、記憶部14内に当該RA−SinkのIDを追加登録する(ステップS6)。また、オプションとして、パスフレーズあるいはキー、ユーザーの生体情報などのユーザーの認証情報をRA−Sinkから取得して、RA−SinkのIDに紐付けして登録する(ステップS7)。そして、RA−Sourceは、要求元のRA−Sinkに対し、登録処理に「成功」した旨の結果コードを通知して(ステップS8)、本処理ルーチンを終了する。
【0096】
なお、ステップS6又はステップS7においてRA−Sinkに関する情報を登録する際に、RA−Sourceを通じてリモート・アクセス可能なコンテンツのうち、RA−Sink上でリモート・アクセスの対象となるコンテンツを併せて登録するようにしてもよい。このような場合、RA−Sinkは、リモート・アクセス時には、登録しておいたコンテンツのみを利用することができる。リモート・アクセスするコンテンツの登録は、ホームネットワーク内でのコンテンツの共有設定に類似する。このような設定モードを設けることにより、コンテンツが必要以上にリモート・アクセスされることを防止できる。また、RA−Sourceから厖大数のコンテンツが提供されている場合、ユーザーは自分が興味のあるコンテンツのみリモート・アクセス用に登録しておけばよい。
【0097】
図10には、RA−SinkがRA−AKE手続きによりRA−Sourceからリモート・アクセス用の交換鍵を取得するとともに、RA−Sourceにコンテンツを要求するコンテンツ取得シーケンス例を示している。
【0098】
このコンテンツ取得シーケンスは、RA−SinkがRA−Sourceに対して鍵供給要求コマンド「RA_AKE_INIT」を送信することによって開始する。RA−AKE手続きのチャレンジ・レスポンス部分(Challenge−Response portion of AKE)では、まず、RA−Sinkから、Rx乱数とRx証明書を含んだRxチャレンジが送信される。これに対しRA−Sourceからは、Tx乱数及びTx証明書を含んだTxチャレンジが返信される。以降、RA−Sourceから、Rx乱数、Txメッセージ、Tx署名を含んだRxレスポンスが送信されるとともに、RA−SinkからはTx乱数、Rxメッセージ、Rx署名を含んだTxレスポンスが送信される。
【0099】
各チャレンジ・コマンドには、機器固有の識別情報であるDevice IDが含まれている。但し、同チャレンジ・レスポンス部分の中では、SinkからSourceへのレスポンスとして「RESPONSE2」が送られることがあるが、その場合は、機器固有の識別情報として、Device IDではなく、RESPONSE2に含まれるIDuを使うことになる(同上)。
【0100】
TTLの制限は、RA−Sourceへ登録する際には必要であるが、リモート・アクセス用の交換鍵供給のためのRA−AKE手続きでは省略される。また、RTT保護プロトコル(Protected RTT Protocol)も、鍵供給のためのRA−AKE手続きでは省略される。これによって、RA−Sinkは、リモート環境下でもリモート・アクセス用の交換鍵を要求することができ、すなわち、リモート・アクセスによるコンテンツの利用が可能になる。
【0101】
そして、上記の認証手順に成功すると、RA−Sourceは、「RA−Sink ID confirmation」処理を実行する。この処理では、RA−Sourceは、要求元のRA−SinkのIDが既に登録済みであることを確認するとともに認証処理を行なう。そして、RA−Sourceは、これらの確認ができた場合に、リモート・アクセス用の交換鍵(RA_Kx)と、当該交換鍵のID(RA_Kx_label)と結果コードを、コマンド「RA_EXCHANGE_KEY」でRA−Sinkに渡す。
【0102】
RA−Sinkは、上述のRA−AKE手続きによってリモート・アクセス用の交換鍵(RA_Kx)とそのID(RA_Kx_label)を取得すると、続いてHTTP GETメソッドを用いたHTTPリクエスト(HTTP GET request)により、RA−Sourceにコンテンツ・データをリクエストする。このリクエストの際には、コンテンツのURLとともに、リモート・アクセス出力用の交換鍵のID(RA_Kx_label)を送る。ここで、RA−SinkからRA−Sourceに交換鍵のID(RA_Kx_label)を送るためのヘッダーフィールドを定義する。
【0103】
RA−Sourceは、コンテンツ・データのリクエストを受けると、交換鍵IDで指定されたリモート・アクセス用の交換鍵を用いて暗号鍵を算出し、指定されたURLのコンテンツをこの暗号鍵を用いて暗号化して、HTTPレスポンス(HTTP GET response)として返送する。
【0104】
なお、RA−SinkをRA−Sourceに事前登録する際に、RA−Sourceを通じてリモート・アクセス可能なコンテンツのうち、RA−Sink上でリモート・アクセスの対象となるコンテンツを併せて登録しておいた場合には(前述)、RA−Sinkは、当該処理シーケンスを通じて、事前登録しておいたコンテンツのみを利用することができる。
【0105】
また、リモート・アクセス用の交換鍵の(RA_Kx)の破棄については、DTCP−IPと同様に連続不使用期間が所定の期間を超える前に破棄するというルールで運用することが考えられる。また、RA−Sinkがリモート・アクセスの終了時に当該交換鍵の破棄を求めるコマンド(RA_FINISH)を交換鍵のID(RA_Kx_label)とともに送るという運用形態も考えられる。この破棄要求コマンドRA_FINISHは、図10中の「RA−AKE_INIT」、「RA_EXCHANGE_KEY」とともに、DTCP−IPのAKE control commandに、リモート・アクセス用のコマンドとして追加するものとする。
【0106】
図11には、RA−SourceがRA−Sinkの登録確認及び認証処理を行なうための「RA−Sink ID confirmation」処理の手順をフローチャートの形式で示している。
【0107】
RA−Sourceは、まず、当該処理ルーチンを開始する以前の処理(Challenge−Response portion of AKE、Protected RTT Protocol)を異常終了(abort)したか否かをチェックする(ステップS11)。
【0108】
ここで、以前の処理を異常終了していた場合には(ステップS11のNo)、RA−Sourceは、要求元のRA−Sinkに対し、RA−AKE手続きを中断して(ステップS20)、本処理ルーチンを終了する。
【0109】
また、以前の処理を正常に終了していた場合には(ステップS11のYes)、RA−Sourceは、RESPONSE2を受信したか否かをチェックする(ステップS12)。そして、RESPONSE2を受信したときには(ステップS12のYes)、RA−Sourceは、要求元のRA−SinkのIDをIDuとする(ステップS13)。また、RESPONSE2を受信していないときには(ステップS12のNo)、RA−Sourceは、要求元のRA−SinkのDevice IDをIDとする(ステップS14)。
【0110】
次いで、RA−Sourceは、要求元のRA−SinkのIDを記憶部14内に既に登録済みか否かをチェックする(ステップS15)。
【0111】
ここで、要求元のRA−SinkのIDを登録してあることを確認できないときには(ステップS15のNo)、RA−Sourceは、要求元のRA−Sinkに対し、RA−AKE手続きを中断して(ステップS19)、本処理ルーチンを終了する。
【0112】
他方、要求元のRA−SinkのIDを登録済みであることを確認できたときには(ステップS15のYes)、RA−Sourceは、続いて、RA−Sinkのユーザーの認証処理を行なう(ステップS16)。
【0113】
そして、RA−Sinkのユーザーの認証処理に成功したときには(ステップS17のYes)、RA−Sourceは、確認処理に「成功」した旨の結果コードを、リモート・アクセス用の交換鍵(RA_Kx)とそのID(RA_Kx_label)とともに、要求元のRA−Sinkに通知して(ステップS18)、本処理ルーチンを終了する。
【0114】
また、RA−Sinkのユーザーの認証処理に失敗したときには(ステップS17のNo)、RA−Sourceは、要求元のRA−Sinkに対し、RA−AKE手続きを中断して(ステップS19)、本処理ルーチンを終了する。
【0115】
ステップS16で行なわれるユーザー認証処理では、例えば、リモート・アクセス用のユーザーID、パスフレーズ又はキー、あるいはユーザーの生体情報などを、RA−Sinkの認証情報入力部25からユーザーが入力し、RA−Sourceに登録されているものとの照合が行なわれる生体情報を認証に用いる場合、例えば、指の静脈パターンを検出する生体認証システム「mofiria(モフィリア)」を使用することが可能である。あるいは、ユーザーの入力操作する代わりに、リモート・アクセス用のユーザーID、パスフレーズ又はキーを書き込んだポータブル・メディアをRA−Sinkに装着する、ドングルなどのホームネットワーク・サーバーに紐付けされたハードウェア・キーをRA−Sinkに装着するといった方法を通じて、ユーザー認証を行なうこともできる。
【0116】
ドングルをホームネットワーク・サーバーに紐付けする方法として、SDメモリーカードのCPRM(Content Protection for Recordable MEDIA)やメモリースティックのMagicGateの認証方法を用いることができる。あるいは、リモート・アクセス専用の認証方法を用いて、ユーザーのコンテンツ・アクセス権をホームネットワーク・サーバーに紐付けすることができる。
【0117】
また、図7、図10に示した処理シーケンス例では、ユーザーは遠隔地へ出かける前に家庭内で事前登録という機器設定が必要であった。事前登録の手続きを行なうことなくコンテンツのリモート・アクセスを可能にする方法の一例として、ホームネットワークに接続されたパソコンなどの情報端末をホームネットワーク上の認証サーバーとして利用し、そのログインIDとパスワードを用いたログイン作業を、RA−AKE手続きに代用する方法を挙げることができる。
【0118】
C.リモート・アクセス可能なコンテンツの識別方法
続いて、リモート・アクセスが許容されるコンテンツを識別するための方法について説明する。
【0119】
ここでは、RA−Sourceが提供する各コンテンツには、リモート・アクセスが可能か否かを示す情報が付加されていることを前提とする。
【0120】
RA−Sourceとしてのコンテンツ提供装置10はコンテンツ受信/再生部12で受信した放送コンテンツや記録メディアから再生するコンテンツ、あるいは通信部13を通じて取得したコンテンツを、リモート・アクセス可否情報に基づいて振り分ける。そして、リモート・アクセス可能と振り分けられたコンテンツに対してのみ、リモート環境にいるRA−Sinkとしてのコンテンツ利用装置20からリモート・アクセスすることができる。
【0121】
コンテンツにリモート・アクセス可否情報を付加する方法として、コンテンツの制御記述子に情報ビットを重畳する方法を挙げることができる。あるいは、情報ビットを重畳するのではなく、コピー制御情報(Copy Control Information:CCI)などの制御記述子に含まれる既存の情報でリモート・アクセス可否情報を代用する方法も考えられる。
【0122】
以下では、ディジタル・コンテンツの伝送並びに蓄積に広く採用されているMPEG2システムを例にとって、リモート・アクセス可否情報を付加する方法について説明する。
【0123】
MPEG2システムは、符号化されたビデオやオーディオ、付加データなど個別のストリームを多重化し、それぞれの同期をとりながら再生するための方式を規定したもので、MPEG2−PS(ProgramStream)と、MPEG2−TS(Transport Stream)の2種類の方式がある。このうち、MPEG2−TSは、放送や通信ネットワークなどデータの伝送誤りが発生する環境に適用されることを想定しており、1本のストリームの中に複数のプログラムを構成することができることから、ディジタル放送などに使用されている。また、MPEG2−PSは、DVDなどに使用されている。
【0124】
MPEG2−TSでは、188バイトの固定長のTS(Transport Stream)パケットが複数個集まって、トランスポート・ストリームが構成される。この188バイトのTSパケットの長さは、ATM(AsynchronousTransfer Mode)セル長との整合性を考慮して決定されている。
【0125】
図13には、TSパケットの構造を模式的に示している。1つのTSパケットは、4バイトの固定長のパケット・ヘッダと、可変長のアダプテーション・フィールド、ペイロードで構成される。パケット・ヘッダには、PID(パケット識別子)や各種のフラグが定義されている。PIDにより、TSパケットのペイロード部分の種類が識別される。ビデオやオーディオなどの個別ストリームが収められたPES(PacketizedElementary Stream)パケットは、同じPID番号を持つ複数のTSパケットに分割されて伝送される。
【0126】
トランスポート・ストリームには、PSI(Program Specific Information)やSI(ServiceInformation)のセクション形式のテーブルで記述された情報をペイロードに乗せたパケットが含まれている。
【0127】
PSIは、所望の放送のチャンネルを選択して受信するシステムで必要な情報(選局のための制御情報)であり、これには、PAT(ProgramAssociation Table)、PMT(Program Map Table)、NIT(Network Information Table)、CAT(ConditionAccess Table)などのデータ構造を持つセクションがある。PATには、プログラム番号に対応するPMTのPIDなどが記述されている。PMTには、対応するプログラムに含まれる映像、音声、付加データ及びPCRのPIDが記述される。NITには、放送システム全体に関する詳細情報が記述され、例えばネットワークに含まれるすべてのプログラムの情報や、目的のプログラムがどの搬送波周波数で送られているかが記述されている。CATには、限定受信方式の識別と契約情報などの個別情報に関する情報が記述される。
【0128】
一方、SIは、放送事業者のサービスに用いるセクションである。SIとしては、EIT(Event InformationTable)やSDT(Service Description Table)などのセクションがある。EITは、番組の詳細情報及び放送時間などが記述されている。
【0129】
MPEG2システムでは、各セクションに詳細な情報を入れるために、ディスクリプタ(descriptor:記述子)を定義し、これをセクションに挿入することにより、きめの細かい情報を伝送することを可能にしている。ARIB STD−B10で定義された、地上ディジタルテレビジョン放送で使用する記述子を以下の表にまとめておく。
【0130】
【表1】
【0131】
ARIB STD−B10では、コンテンツの著作権保護に関わるコピー制御情報を伝送するために、digital_copy_control_descriptor(ディジタル・コピー制御記述子)及びcontent_availability_descriptor(コンテンツ利用記述子)を定義し、これをPMTに挿入してコンテンツのコピー制御情報を定義している。ディジタル・コピー制御記述子のデータ構造を図14に示しておく。
【0132】
ディジタル・コピー制御記述子におけるdigital_recording_control_data(ディジタル記録制御データ)の2ビットは、コピー制御(コピーの世代管理)のためのものである。この2ビットが「00」ならコピー・フリー、「11」ならコピー禁止、「10」なら一世代のみコピーが許可される。すなわち、この2ビットはCGMS(Copy Generation Management System)のコピー制御を行なうものである。
【0133】
【表2】
【0134】
要するに、コンテンツのコピー制御情報は、コンテンツを伝送するストリームを構成するTSパケットのペイロードとして含まれるデータの1種類であり、PMTと呼ばれるデータ構造を持っている。PMTの詳細な構造を図15に示しておく。
【0135】
MPEG TSストリームは、上述したような固定長のTSパケットの繰り返しで構成されるが、すべてのTSパケットにコピー制御情報が含まれる訳ではなく、特定のTSパケットにのみ含まれる。例えば、ARIBでは、MPEG TSストリーム中で100ミリ秒の間隔で、コピー制御情報を記載したPMTを伝送するパケットが含まれるように決められている。図16には、MPEG TSストリーム中に所定間隔でPMTを含んだTSパケットが挿入されている様子を示している。図示の構成によれば、コンテンツの供給装置側ではコンテンツ保護に関するコピー制御情報などのコンテンツ属性を伝送ストリームの中で指定することができる。そして、コンテンツを受信するコンテンツ処理装置側では、コピー制御情報に従ってコンテンツの暗号モードの設定やコピーや記録の制限を行なうことができる。
【0136】
コンテンツのリモート・アクセスを許可するか否かは、コンテンツの著作権保護と深く関わっている。そこで、本発明者らは、リモート・アクセスが許容されるコンテンツを識別するためにディジタル制御記述子を利用する方法を提案する。
【0137】
1つの方法として、図14に示したディジタル制御記述子内の予約領域(reserved_future_use)をリモート・アクセスの可否を示すフラグ(以下では、「RA−flag」と呼ぶ)に定義して、RA=1のときにリモート・アクセス許可とし、RA=0のときにリモート・アクセス禁止とする。
【0138】
また、他の方法として、図14に示したディジタル・コピー制御記述子に含まれるコピー制御情報(CCI)を、リモート・アクセスの制御記述子としても併用する。例えば、コピー禁止(Never Copy)コンテンツはリモート・アクセス禁止とし、制御条件なしコピー可(Copy Free)コンテンツ並びに1世代のみコピー可(Copy One Generation)コンテンツはリモート・アクセス許可とする、などである。
【0139】
【表3】
【0140】
上述した識別方法は主に放送コンテンツに適用することができる。勿論、Blu−rayやDVD(Digital Versatile Disc)、フラッシュメモリーなどの記録メディアや、インターネット経由で配布されるコンテンツに関しても、記録メディアの著作権保護技術である、AACS(Advanced Access Content System)、CSS(Content Scramble System)、CPRMなどで定義されるディジタル・コピー制御記述子を用いて、同様の識別方法を実現することができる。
【0141】
Blu−rayディスクのリモート・アクセスの場合、その著作権保護技術であるAACSによって制御され、コンテンツ提供装置10内の記憶部14(HDDなど)にコピーされた後、DTCP−IPに受け渡され、リモート・アクセスに供される。
【0142】
コンテンツのリモート・アクセスを制御する「リモート・アクセス制御ファイル」は、XML(extensible Markup Language)言語で記述される。リモート・アクセス制御ファイルは、Blu−rayディスクの本編を対象とする「Managed Copy and Remote Access Manifest File」と、ポータブル・ファイルを対象とする「Remote Access Manifest File」からなる。これらのファイルは、JAVA(登録商標)ヴァーチャルマシンMCRAM(Managed Copy and Remote Access Machine)、又は、RAM(Remote Access Machine)に読み込まれて実行される。
【0143】
リモート・アクセス用のポータブル・ファイルが、Blu−rayディスク上のディレクトリー「PARTIALDB」に格納されていると仮定し、dest(destination)で指定されたHDD上のディレクトリーにコピーされてリモート・アクセスに供されると仮定した場合の一例を以下に示しておく。
【0144】
【数1】
【0145】
図17には、Blu−rayディスク上のコンテンツのリモート・アクセスを制御する仕組みを図解している。RA−Sourceとしてのコンテンツ提供装置10は、コンテンツ受信/再生部12によりBlu−rayディスクからJAVA(登録商標)アプリケーションを読み出して、CPU11のシステム・メモリにロードし、JAVA(登録商標)ヴァーチャルマシンを実行して、Blu−rayディスクから読み出したリモート・アクセス用コンテンツへのリモート・アクセスの制御を行なう。
【0146】
ここまでは、コンテンツに付随する著作権保護などの情報に基づいて、そのリモート・アクセスの可否を識別する方法について説明してきた。それ以外にも、コンテンツの状態に基づいてリモート・アクセスの可否を識別する方法も考えられる。
【0147】
例えば、ホームネットワーク・サーバーとして動作しているコンテンツ提供装置10の記憶部14(HDDなど)に、コピー制御に関する制約を外して蓄積されたコンテンツはすべて複製物、言い換えれば、コピーが許可されたコンテンツであるから、上記の表3に従い、リモート・アクセスが許可されているものとして扱うことができる。
【0148】
但し、放送コンテンツをコンテンツ受信/再生部12で受信し記憶部14に録画するような場合には、放送地域制限などの放送のビジネス・モデルを考慮して、放送中のリアルタイム・コンテンツについては、リモート・アクセスに制限を課すことが好ましい。具体的には、放送コンテンツを記憶部14に一旦蓄積し、一定時間が経過した後に、リモート・アクセスを許可するようにする。例えば、放送から30分遅れでコンテンツのリモート・アクセスを許可したり、放送終了後であればリモート・アクセスを許可したりする。あるいは、放送が終了してから、6時間後、12時間後、…、翌日以降、1週間後以降などの時間的制約を設定することが可能である。
【0149】
また、コンテンツに付随する著作権保護などの情報に基づいてリモート・アクセスの可否を識別する方法、コンテンツの状態に基づいてリモート・アクセスの可否を識別する方法のうちいずれか一方を単独で用いるのではなく、コンテンツ提供装置10に蓄積されたコンテンツについて、これら2つの方法を組み合わせてリモート・アクセスの可否を識別する方法も考えられる。記憶部14に蓄積されたコンテンツに付加されているコピー制御情報の他に、リモート・アクセスの可否を示すRA−flagを追加定義して、RA=1のときにリモート・アクセス許可とし、RA=0のときにリモート・アクセス禁止とする。コンテンツ利用装置20からコンテンツへのリモート・アクセスが要求されたときには、コンテンツ提供装置10は、要求されたコンテンツのRA−flagを参照して、リモート・アクセスを制御する。
【0150】
また、コンテンツ提供装置10は、RA−flagを追加定義するのではなく、記憶部14内にリモート・アクセスが許可されたコンテンツ、並びに、リモート・アクセスが禁止されたコンテンツをそれぞれ蓄積するための専用のファイル・フォルダー(あるいはパーティション)を設けて、例えばコンテンツ取得時にそのリモート・アクセスの可否を判断し、各ファイル・フォルダーに仕分けするようにしてもよい。このような場合、コンテンツ利用装置20は、リモート・アクセス許可コンテンツ用のファイル・フォルダーに蓄積されているコンテンツを自由にリモート・アクセスすることができるのに対し、リモート・アクセス禁止コンテンツ用のファイル・フォルダーに蓄積されているコンテンツにはリモート・アクセスすることはできない。
【0151】
D.リモート・アクセスの識別方法
ホームネットワーク・サーバーなどRA−Sourceとして動作するコンテンツ提供装置10は、これまで説明してきた方法によって、リモート・アクセスするコンテンツ利用装置20はリモート・アクセスが許可されたRA−Sinkであるか否か、並びに、コンテンツ利用装置20がリモート・アクセスを要求するコンテンツがリモート・アクセスを許可されているか否かを識別することができる。
【0152】
しかしながら、コンテンツ提供装置10は、そもそも、コンテンツ利用装置20からのアクセスが、リモート・アクセスか否かを正確に識別する必要がある。何故ならば、DTCP−IPの通常のホームネットワーク内にいるコンテンツ利用装置20によるコンテンツの利用は、著作権保護の観点からも正当な使用であり、アクセスが拒否されるとユーザーの利益を不当に害するものとなるからである。
【0153】
以下では、コンテンツ利用装置20から要求されるAKE手続きが、DTCP−IPの通常のホームネットワーク内の認証手続き(RTT−AKE)、又は、遠隔地からのリモート・アクセスによる認証手続き(RA−AKE)のいずれであるかを識別する方法について説明する。
【0154】
AKE control commandの構成は図8に示した通りである。DTCP−IPの通常のAKE control commandでは、Control(0)の上位4ビットは、reserved(ZERO)である。例えば、この4ビット長のフィールドをオール1にしてリモート・アクセス用の認証モード(Authentication Mode)と定義すれば、通常のDTCP−IPの通常のホームネットワーク内のAKE手続きと区別することが可能である。以下のAKE手続きは、DTCP−IPの通常のホームネットワーク内のAKE手続き(RTT−AKE)とは異なるリモート・アクセス用のAKE手続き(RA−AKE)となる。 また、Control(2)のsubfunctionとして、現在定義されていない値を用いてリモート・アクセス用のAKE control commandを定義することでも区別が可能である。
【0155】
あるいは、上述したようにAKE control command内にリモート・アクセスか否かの制御ビットを設けるのではなく、リモート・アクセス専用の認証手続きを新たに定義するようにしてもよい。DTCP−IPの通常のAKE control commandのControl(3)に割り当てられているAKE_procedureは、現行では、下位から4ビット目(Bit3)は、通常のAKE手続きはFull Authenticationで行なうのに対し、Extended Fulle Authenticationで行なうか否かを識別するフラグに定義されている。また、上位の4ビットは招来の拡張のための予約領域となっている。したがって、この上位4ビットの予約領域に、新たにリモート・アクセス用のFull Authenticationを定義して行なうことも考えられる。
【0156】
【表4】
【0157】
上述のようにして、リモート・アクセス用のAKE手続き(RA−AKE)が成立したならば、RA−Sourceとしてのコンテンツ提供装置10と、RA−Sinkとしてのコンテンツ利用装置20の間でリモート・アクセス用の交換鍵が共有される。そして、リモート・アクセス用に新たに設けた暗号化モードを用いて、コンテンツ伝送を行なうようにしてもよい。
【0158】
DTCP−IPでは、パケットのヘッダ部に記述するE−EMI(Extended Encryption Mode Indicator)と、EmbeddedCCI(Copy Control Information)という2つのメカニズムにより、コンテンツに付随したコピー制御情報の伝送を実現している。以下の表5には、現行のDTCP−IPの暗号モード(EMI)の一覧を示している。
【0159】
【表5】
【0160】
リモート・アクセスは、外部のネットワークを経由して接続されることから、そのコンテンツ保護レベルも、通常の家庭内のネットワークで使用されるものとは異なるレベルの暗号化モードが要求される。例えば、家庭内のネットワークにおけるコピー禁止(CN)、一世代のみコピー許可(COG)とは別に、リモート・アクセスにおけるコピー禁止(RA−CN)、一世代のみコピー許可(RA−COG)といった暗号化モードが必要である。そして、上記の表5の予約値を使用して、これらの新たなリモート・アクセス用暗号化モードを定義する。
【0161】
ここまでの説明では、通信システムが一対のRA−SourceとRA−Sinkだけで構成されることを想定していた。しかしながら、RA−SourceやRA−Sinkは、それぞれさらに別の機器とデイジーチェーン形式で接続され、コンテンツを伝送する可能性がある。著作権保護されたコンテンツの伝送範囲は、本来、家庭内に留めるべきであり、コンテンツの受信と再送信が何段にもわたり繰り返し行なわれることは好ましくない。このため、コンテンツの受信と再送信を技術的に阻止することが必要である。
【0162】
本実施形態では、コンテンツのリモート・アクセスの可否を示すRA−flagが各コンテンツに付加されており(前述)、このフラグを用いてコンテンツの再送信を制限する。
【0163】
例えば、ある機器が、RA−Sourceとしてのコンテンツ提供装置10に蓄積されているコンテンツにRA−flagが「リモート・アクセス可」を示す場合には、既に転送された(すなわち、RA−Sinkとして受信した)コンテンツであり、再送信を止めるべきであることが分かる。
【0164】
あるいは、コンテンツ提供装置10が、RA−Sinkとして受信したコンテンツを一時的にキャッシュし、記憶部14に蓄積し、あるいは一切記録せずに再送信しようとする際に、この受信コンテンツに付加されたRA−flagを「リモート・アクセス不可」に書き換えて、リモート・アクセスによる再送信を防止する。
【0165】
図18に示すシステム構成例では、RA−Source#0と接続するRA−Sink#1が、さらにRA−Source#1としての機能も備え、別の機器RA−Sink#2と接続している。このような場合、RA−Sink#1としてリモート・アクセスして受信したコンテンツを、RA−Source#1としてRA−Sink#2に再度リモート・アクセス出力することを禁止することによって、コンテンツ提供元であるRA−Source#0の管理が及ばない所でリモート・アクセスされるのを防止するように運用する。
【0166】
また、図19に示すシステム構成例では、RA−Sink#1が、リモート・アクセスによりRA−Source#0に接続するとともに、Source#1としての機能も備えDTCP−IPにより別の機器Sink#2に接続され、さらに、Sink#2がRA−Source#2としての機能も備えて別の機器RA−Sink#3と接続している。RA−Sink#1は、リモート・アクセスにより受信したコンテンツを、DTCP−IPを通じて別の機器Sink#2にローカル伝送することができる。DTCP−IPによるローカル伝送は、著作権保護の仕組みに則ったものであり、問題はない。また、Sink#2が受信したコンテンツを、RA−Source#2としてRA−Sink#3に再度リモート・アクセス出力することを禁止することによって、コンテンツ提供元であるRA−Source#0の管理が及ばない所でリモート・アクセスされるのを防止するように運用する。
【0167】
RA−flagは、RA=1のときにリモート・アクセス許可とし、RA=0のときにリモート・アクセス禁止とするように定義することは既に述べた通りである。ここで、現行のDTCP−IPではRA−flagは定義されていないことから、RA−flagを用いてリモート・アクセスの可否を制御する場合には、旧来のDTCP−IP機器との互換性が問題となる。
【0168】
例えば、リモート・アクセスの可否を示す制御ビットや、リモート・アクセス用のAKE手続きをDTCP−IPで新たに設けるのではなく、各機器がDTCP−IP経由で受け取ったコンテンツはすべてリモート・アクセス不可として扱うようにする。これによって、従来のDTCP−IP機器との互換性を保ちながら、従来のDTCP−IP機器を経由して受け取った(リモート・アクセスの可否が不明な)コンテンツをリモート・アクセス禁止にする。
【0169】
【表6】
【0170】
あるいは、上述のようにDTCP−IP経由で受け取ったコンテンツをすべてリモート・アクセス不可とする代わりに、コピー制御情報(CCI)を、リモート・アクセスの制御記述子としても併用することによって、旧来のDTCP−IP機器との互換性を保つことができる。
【0171】
具体的には、以下の表7の第2及び第3行に示すように、No more copy又はNever copyがエンコードされたコンテンツのみをリモート・アクセス不可として扱うことで、旧来のDTCP−IP機器との互換性を保ちながら、旧来のDTCP−IPを経由して受け取った(リモート・アクセスの可否が不明な)コンテンツをリモート・アクセス禁止にする。
【0172】
また、リモート・アクセス不可としないコンテンツについては、以下の表7の第4及び第5行に示すように、一旦記憶部14に蓄積した後にリモート・アクセスかとして扱い、蓄積する前の状態では、リモート・アクセス不可として取り扱う。
【0173】
【表7】
【0174】
本実施形態に係る通信システムによれば、DTCP−IPで著作権保護されたDLNAコンテンツに、家庭外の遠隔地からリモート・アクセスして、コンテンツを安全に利用することができる。
【0175】
また、本実施形態に係る通信システムでは、コンテンツのリモート・アクセスを制御するためのフラグの取り扱い方やリモート・アクセス時の認証方法(AKE手続き)を明示的に定義しているので、リモート・アクセスにおいても、従来の家庭内でのアクセスと同様に、DTCP−IPに基づくコンテンツの著作権保護環境を構築することができる。
【産業上の利用可能性】
【0176】
以上、特定の実施形態を参照しながら、本発明について詳細に説明してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
【0177】
本発明の適用例として、DTCP−IPが適用されるホームネットワーク上のサーバーに、家庭外のクライアントからリモート・アクセスしてコンテンツを利用する通信システムを挙げることができるが、本発明の要旨はこれに限定されない。著作権やその他の目的で保護が必要となるコンテンツを、往復遅延時間(RTT)やIPルーターのホップ回数(TTL)などの制限を超えつつ、WANなどの外部ネットワークを経由したリモート・アクセスを通じてコンテンツを伝送する他のあらゆるコンテンツ伝送システムに、同様に本発明を適用することができる。
【0178】
要するに、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、特許請求の範囲を参酌すべきである。
【符号の説明】
【0179】
10…コンテンツ提供装置(RA−source)
11…CPU
12…コンテンツ受信/再生部
13…通信部
14…記憶部
15…タイマー
20…コンテンツ利用装置(RA−sink)
21…CPU
22…通信部
23…コンテンツ出力部
24…記憶部
25…認証情報入力部
30、31…ルーター
40、41…モデム
50…WAN
60…IASサービス
70…DDNSサービス
【特許請求の範囲】
【請求項1】
コンテンツを提供するコンテンツ提供装置とコンテンツを利用する1以上のコンテンツ利用装置でコンテンツ伝送のための通信を行なう通信システムであって、
リモート・アクセスするコンテンツ利用装置を、コマンドの往復遅延時間に関する制限を課さないリモート・アクセス用の相互認証手続きに従って認証する認証手段と、
前記コンテンツ利用装置からリモート・アクセスにより要求されたコンテンツがリモート・アクセスを許容されているか否かを識別する識別手段と、
前記識別手段による識別結果及び前記認証手段による認証結果に応じて、前記コンテンツ提供装置から認証された前記コンテンツ利用装置へ、前記要求されたコンテンツを伝送する伝送手段と、
を具備することを特徴とする通信システム。
【請求項2】
リモート・アクセスするコンテンツ利用装置を、コマンドの往復遅延時間に関する制限を課さないリモート・アクセス用の相互認証手続きに従って認証する認証手段と、
コンテンツ利用装置からリモート・アクセスにより要求されたコンテンツがリモート・アクセスを許容されているか否かを識別する識別手段と、
コンテンツ利用装置へ要求されたコンテンツを提供する提供手段と、
を具備し、
前記提供手段は、リモート・アクセスによりコンテンツを要求するコンテンツ利用装置に対し、前記識別手段による識別結果及び前記認証手段による認証結果に応じて、コンテンツを提供する、
ことを特徴とする通信装置。
【請求項3】
前記認証手段は、前記リモート・アクセス用の相互認証手続きに際し、IP(Internet Protocol)ルーターのホップ回数に関する制限をも課さない、
ことを特徴とする請求項2に記載の通信装置。
【請求項4】
前記識別手段は、前記要求されたコンテンツの所定の制御記述子に重畳されている、リモート・アクセスの可否を示す情報に基づいて、リモート・アクセスを許容されているか否かを識別する、
ことを特徴とする請求項2に記載の通信装置。
【請求項5】
前記識別手段は、前記要求されたコンテンツの所定の制御記述子の記載内容に基づいて、リモート・アクセスを許容されているか否かを識別する、
ことを特徴とする請求項2に記載の通信装置。
【請求項6】
前記識別手段は、前記要求されたコンテンツの所定の制御記述子に含まれるコピー制御情報の記載内容に基づいて、リモート・アクセスを許容されているか否かを識別する、
ことを特徴とする請求項2に記載の通信装置。
【請求項7】
コンテンツを蓄積することができる記憶部をさらに備え、
前記識別手段は、前記記憶部にコピーされているコンテンツはリモート・アクセスを許可されていると識別する、
ことを特徴とする請求項2に記載の通信装置。
【請求項8】
放送コンテンツを受信する受信部をさらに備え、
前記識別手段は、放送中のリアルタイム・コンテンツについては、放送終了後からの経過時間に基づいてリモート・アクセスを許容されているか否かを識別する、
ことを特徴とする請求項2に記載の通信装置。
【請求項9】
放送コンテンツを受信する受信部と、コンテンツを蓄積することができる記憶部をさらに備え、
前記識別手段は、受信した放送コンテンツを、前記記憶部に一旦蓄積した後にリモート・アクセスを許可されていると識別する、
ことを特徴とする請求項2に記載の通信装置。
【請求項10】
リモート・アクセス可能コンテンツを記憶する第1の領域とリモート・アクセス不可コンテンツを記憶する第2の領域を有する記憶部をさらに備え、
各コンテンツを前記識別手段による識別結果に基づいて前記第1又は第2の領域に仕分けして前記記憶部に蓄積する、
ことを特徴とする請求項2に記載の通信装置。
【請求項11】
コマンドの往復遅延時間に関する制限を課した登録用の相互認証手続きを経てコンテンツ利用装置を事前に登録する登録手段をさらに備え、
前記認証手段は、前記リモート・アクセスするコンテンツ利用装置が前記登録手段により登録されているときのみ認証手続きを行なう、
ことを特徴とする請求項2に記載の通信装置。
【請求項12】
前記登録手段は、前記登録用の相互認証手続きに際し、IPルーターのホップ回数に関する制限をさらに課す、
ことを特徴とする請求項11に記載の通信装置。
【請求項13】
前記登録手段は、コンテンツ利用装置の事前登録時に、ユーザーID、パスフレーズ若しくはキー、ユーザーの生体情報、又はその他のリモート・アクセス用の認証情報を併せて登録し、
前記認証手段は、リモート・アクセスするコンテンツ利用装置を認証する際に、前記の事前登録した認証情報を用いた認証処理を併せて行なう、
ことを特徴とする請求項11に記載の通信装置。
【請求項14】
前記認証手段は、前記リモート・アクセス用の認証情報を書き込んだポータブル・メディアを通じて前記の事前登録した認証情報を用いた認証処理を行なう、
ことを特徴とする請求項13に記載の通信装置。
【請求項15】
前記認証手段は、当該装置に紐付けされたドングルを通じてリモート・アクセスするコンテンツ利用装置を認証する、
ことを特徴とする請求項11に記載の通信装置。
【請求項16】
前記登録手段はコンテンツ利用装置を事前登録する際に、当該コンテンツ利用装置がリモート・アクセス時に利用する1以上のコンテンツを併せて登録し、
前記提供手段は、リモート・アクセスするコンテンツ利用装置に対し、前記のリモート・アクセス時に利用するとして事前登録されたコンテンツのみを提供する、
ことを特徴とする請求項11に記載の通信装置。
【請求項17】
前記認証手段は、前記リモート・アクセス用の相互認証手続きに代えて、所定の認証サーバーに対するログイン処理を通じて前記リモート・アクセスするコンテンツ利用装置の認証手続きを行なう、
ことを特徴とする請求項2に記載の通信装置。
【請求項18】
前記認証手段は、コンテンツ利用装置からの相互認証制御コマンドに設けられている、リモート・アクセスの可否を示す情報ビットに基づいて、リモート・アクセスするコンテンツ利用装置を認証する、
ことを特徴とする請求項2に記載の通信装置。
【請求項19】
前記認証手段は、リモート・アクセス専用の相互認証手続きに従って、リモート・アクセスするコンテンツ利用装置を認証する、
ことを特徴とする請求項2に記載の通信装置。
【請求項20】
前記提供手段は、リモート・アクセス専用の暗号化モードを用いて、コンテンツ利用装置からリモート・アクセスにより要求されたコンテンツを暗号化伝送する、
ことを特徴とする請求項18又は19のいずれかに記載の通信装置。
【請求項21】
前記提供手段は、コンテンツのリモート・アクセスによる再出力を禁止する、
ことを特徴とする請求項18又は19のいずれかに記載の通信装置。
【請求項22】
コンテンツを蓄積することができる記憶部をさらに備え、
前記提供手段は、前記記憶部に蓄積されているコンテンツにリモート・アクセスが可能であることを示す情報が付加されているときには、リモート・アクセスによる再出力を禁止する、
ことを特徴とする請求項18又は19のいずれかに記載の通信装置。
【請求項23】
コンテンツを蓄積することができる記憶部をさらに備え、
前記識別手段は、リモート・アクセスが可能であることを示す情報が付加されたコンテンツを前記記憶部に蓄積する際に、当該情報をリモート・アクセス不可に書き換える、
ことを特徴とする請求項18又は19のいずれかに記載の通信装置。
【請求項24】
前記識別手段は、著作権保護が施された所定のプロトコルに従って受け取ったコンテンツにリモート・アクセスの可否を示す情報が付加されていないときには、当該コンテンツをリモート・アクセス不可として扱う、
ことを特徴とする請求項18又は19のいずれかに記載の通信装置。
【請求項25】
前記識別手段は、著作権保護が施された所定のプロトコルに従って受け取ったコンテンツにリモート・アクセスの可否を示す情報が付加されていないときには、当該コンテンツに設定されているコピー制御情報に基づいて、当該コンテンツがリモート・アクセスを許容されているか否かを識別する、
ことを特徴とする請求項18又は19のいずれかに記載の通信装置。
【請求項26】
コンテンツを蓄積することができる記憶部をさらに備え、
前記識別手段は、リモート・アクセスを不可としないコンテンツについては、前記記憶部に一旦蓄積した後にリモート・アクセス可として扱い、前記記憶部に蓄積する前の状態ではリモート・アクセス不可として扱う、
ことを特徴とする請求項25に記載の通信装置。
【請求項27】
リモート・アクセスするコンテンツ利用装置を、コマンドの往復遅延時間に関する制限を課さないリモート・アクセス用の相互認証手続きに従って認証する認証ステップと、
コンテンツ利用装置からリモート・アクセスにより要求されたコンテンツがリモート・アクセスを許容されているか否かを識別する識別ステップと、
コンテンツ利用装置へ要求されたコンテンツを提供する提供ステップと、
を有し、
前記提供ステップでは、リモート・アクセスによりコンテンツを要求するコンテンツ利用装置に対し、前記識別ステップにおける識別結果及び前記認証ステップにおける認証結果に応じて、コンテンツを提供する、
ことを特徴とする通信方法。
【請求項28】
ネットワーク経由でコンテンツを提供するための処理をコンピューター上で実行するようにコンピューター可読形式で記述されたコンピューター・プログラムであって、前記コンピューターを、
リモート・アクセスするコンテンツ利用装置を、コマンドの往復遅延時間に関する制限を課さないリモート・アクセス用の相互認証手続きに従って認証する認証手段、
コンテンツ利用装置からリモート・アクセスにより要求されたコンテンツがリモート・アクセスを許容されているか否かを識別する識別手段、
コンテンツ利用装置へ要求されたコンテンツを提供する提供手段、
として機能させ、
前記提供手段は、リモート・アクセスによりコンテンツを要求するコンテンツ利用装置に対し、前記識別手段による識別結果及び前記認証手段による認証結果に応じて、コンテンツを提供する、
ことを特徴とするコンピューター・プログラム。
【請求項1】
コンテンツを提供するコンテンツ提供装置とコンテンツを利用する1以上のコンテンツ利用装置でコンテンツ伝送のための通信を行なう通信システムであって、
リモート・アクセスするコンテンツ利用装置を、コマンドの往復遅延時間に関する制限を課さないリモート・アクセス用の相互認証手続きに従って認証する認証手段と、
前記コンテンツ利用装置からリモート・アクセスにより要求されたコンテンツがリモート・アクセスを許容されているか否かを識別する識別手段と、
前記識別手段による識別結果及び前記認証手段による認証結果に応じて、前記コンテンツ提供装置から認証された前記コンテンツ利用装置へ、前記要求されたコンテンツを伝送する伝送手段と、
を具備することを特徴とする通信システム。
【請求項2】
リモート・アクセスするコンテンツ利用装置を、コマンドの往復遅延時間に関する制限を課さないリモート・アクセス用の相互認証手続きに従って認証する認証手段と、
コンテンツ利用装置からリモート・アクセスにより要求されたコンテンツがリモート・アクセスを許容されているか否かを識別する識別手段と、
コンテンツ利用装置へ要求されたコンテンツを提供する提供手段と、
を具備し、
前記提供手段は、リモート・アクセスによりコンテンツを要求するコンテンツ利用装置に対し、前記識別手段による識別結果及び前記認証手段による認証結果に応じて、コンテンツを提供する、
ことを特徴とする通信装置。
【請求項3】
前記認証手段は、前記リモート・アクセス用の相互認証手続きに際し、IP(Internet Protocol)ルーターのホップ回数に関する制限をも課さない、
ことを特徴とする請求項2に記載の通信装置。
【請求項4】
前記識別手段は、前記要求されたコンテンツの所定の制御記述子に重畳されている、リモート・アクセスの可否を示す情報に基づいて、リモート・アクセスを許容されているか否かを識別する、
ことを特徴とする請求項2に記載の通信装置。
【請求項5】
前記識別手段は、前記要求されたコンテンツの所定の制御記述子の記載内容に基づいて、リモート・アクセスを許容されているか否かを識別する、
ことを特徴とする請求項2に記載の通信装置。
【請求項6】
前記識別手段は、前記要求されたコンテンツの所定の制御記述子に含まれるコピー制御情報の記載内容に基づいて、リモート・アクセスを許容されているか否かを識別する、
ことを特徴とする請求項2に記載の通信装置。
【請求項7】
コンテンツを蓄積することができる記憶部をさらに備え、
前記識別手段は、前記記憶部にコピーされているコンテンツはリモート・アクセスを許可されていると識別する、
ことを特徴とする請求項2に記載の通信装置。
【請求項8】
放送コンテンツを受信する受信部をさらに備え、
前記識別手段は、放送中のリアルタイム・コンテンツについては、放送終了後からの経過時間に基づいてリモート・アクセスを許容されているか否かを識別する、
ことを特徴とする請求項2に記載の通信装置。
【請求項9】
放送コンテンツを受信する受信部と、コンテンツを蓄積することができる記憶部をさらに備え、
前記識別手段は、受信した放送コンテンツを、前記記憶部に一旦蓄積した後にリモート・アクセスを許可されていると識別する、
ことを特徴とする請求項2に記載の通信装置。
【請求項10】
リモート・アクセス可能コンテンツを記憶する第1の領域とリモート・アクセス不可コンテンツを記憶する第2の領域を有する記憶部をさらに備え、
各コンテンツを前記識別手段による識別結果に基づいて前記第1又は第2の領域に仕分けして前記記憶部に蓄積する、
ことを特徴とする請求項2に記載の通信装置。
【請求項11】
コマンドの往復遅延時間に関する制限を課した登録用の相互認証手続きを経てコンテンツ利用装置を事前に登録する登録手段をさらに備え、
前記認証手段は、前記リモート・アクセスするコンテンツ利用装置が前記登録手段により登録されているときのみ認証手続きを行なう、
ことを特徴とする請求項2に記載の通信装置。
【請求項12】
前記登録手段は、前記登録用の相互認証手続きに際し、IPルーターのホップ回数に関する制限をさらに課す、
ことを特徴とする請求項11に記載の通信装置。
【請求項13】
前記登録手段は、コンテンツ利用装置の事前登録時に、ユーザーID、パスフレーズ若しくはキー、ユーザーの生体情報、又はその他のリモート・アクセス用の認証情報を併せて登録し、
前記認証手段は、リモート・アクセスするコンテンツ利用装置を認証する際に、前記の事前登録した認証情報を用いた認証処理を併せて行なう、
ことを特徴とする請求項11に記載の通信装置。
【請求項14】
前記認証手段は、前記リモート・アクセス用の認証情報を書き込んだポータブル・メディアを通じて前記の事前登録した認証情報を用いた認証処理を行なう、
ことを特徴とする請求項13に記載の通信装置。
【請求項15】
前記認証手段は、当該装置に紐付けされたドングルを通じてリモート・アクセスするコンテンツ利用装置を認証する、
ことを特徴とする請求項11に記載の通信装置。
【請求項16】
前記登録手段はコンテンツ利用装置を事前登録する際に、当該コンテンツ利用装置がリモート・アクセス時に利用する1以上のコンテンツを併せて登録し、
前記提供手段は、リモート・アクセスするコンテンツ利用装置に対し、前記のリモート・アクセス時に利用するとして事前登録されたコンテンツのみを提供する、
ことを特徴とする請求項11に記載の通信装置。
【請求項17】
前記認証手段は、前記リモート・アクセス用の相互認証手続きに代えて、所定の認証サーバーに対するログイン処理を通じて前記リモート・アクセスするコンテンツ利用装置の認証手続きを行なう、
ことを特徴とする請求項2に記載の通信装置。
【請求項18】
前記認証手段は、コンテンツ利用装置からの相互認証制御コマンドに設けられている、リモート・アクセスの可否を示す情報ビットに基づいて、リモート・アクセスするコンテンツ利用装置を認証する、
ことを特徴とする請求項2に記載の通信装置。
【請求項19】
前記認証手段は、リモート・アクセス専用の相互認証手続きに従って、リモート・アクセスするコンテンツ利用装置を認証する、
ことを特徴とする請求項2に記載の通信装置。
【請求項20】
前記提供手段は、リモート・アクセス専用の暗号化モードを用いて、コンテンツ利用装置からリモート・アクセスにより要求されたコンテンツを暗号化伝送する、
ことを特徴とする請求項18又は19のいずれかに記載の通信装置。
【請求項21】
前記提供手段は、コンテンツのリモート・アクセスによる再出力を禁止する、
ことを特徴とする請求項18又は19のいずれかに記載の通信装置。
【請求項22】
コンテンツを蓄積することができる記憶部をさらに備え、
前記提供手段は、前記記憶部に蓄積されているコンテンツにリモート・アクセスが可能であることを示す情報が付加されているときには、リモート・アクセスによる再出力を禁止する、
ことを特徴とする請求項18又は19のいずれかに記載の通信装置。
【請求項23】
コンテンツを蓄積することができる記憶部をさらに備え、
前記識別手段は、リモート・アクセスが可能であることを示す情報が付加されたコンテンツを前記記憶部に蓄積する際に、当該情報をリモート・アクセス不可に書き換える、
ことを特徴とする請求項18又は19のいずれかに記載の通信装置。
【請求項24】
前記識別手段は、著作権保護が施された所定のプロトコルに従って受け取ったコンテンツにリモート・アクセスの可否を示す情報が付加されていないときには、当該コンテンツをリモート・アクセス不可として扱う、
ことを特徴とする請求項18又は19のいずれかに記載の通信装置。
【請求項25】
前記識別手段は、著作権保護が施された所定のプロトコルに従って受け取ったコンテンツにリモート・アクセスの可否を示す情報が付加されていないときには、当該コンテンツに設定されているコピー制御情報に基づいて、当該コンテンツがリモート・アクセスを許容されているか否かを識別する、
ことを特徴とする請求項18又は19のいずれかに記載の通信装置。
【請求項26】
コンテンツを蓄積することができる記憶部をさらに備え、
前記識別手段は、リモート・アクセスを不可としないコンテンツについては、前記記憶部に一旦蓄積した後にリモート・アクセス可として扱い、前記記憶部に蓄積する前の状態ではリモート・アクセス不可として扱う、
ことを特徴とする請求項25に記載の通信装置。
【請求項27】
リモート・アクセスするコンテンツ利用装置を、コマンドの往復遅延時間に関する制限を課さないリモート・アクセス用の相互認証手続きに従って認証する認証ステップと、
コンテンツ利用装置からリモート・アクセスにより要求されたコンテンツがリモート・アクセスを許容されているか否かを識別する識別ステップと、
コンテンツ利用装置へ要求されたコンテンツを提供する提供ステップと、
を有し、
前記提供ステップでは、リモート・アクセスによりコンテンツを要求するコンテンツ利用装置に対し、前記識別ステップにおける識別結果及び前記認証ステップにおける認証結果に応じて、コンテンツを提供する、
ことを特徴とする通信方法。
【請求項28】
ネットワーク経由でコンテンツを提供するための処理をコンピューター上で実行するようにコンピューター可読形式で記述されたコンピューター・プログラムであって、前記コンピューターを、
リモート・アクセスするコンテンツ利用装置を、コマンドの往復遅延時間に関する制限を課さないリモート・アクセス用の相互認証手続きに従って認証する認証手段、
コンテンツ利用装置からリモート・アクセスにより要求されたコンテンツがリモート・アクセスを許容されているか否かを識別する識別手段、
コンテンツ利用装置へ要求されたコンテンツを提供する提供手段、
として機能させ、
前記提供手段は、リモート・アクセスによりコンテンツを要求するコンテンツ利用装置に対し、前記識別手段による識別結果及び前記認証手段による認証結果に応じて、コンテンツを提供する、
ことを特徴とするコンピューター・プログラム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図15】
【図16】
【図17】
【図18】
【図19】
【図14】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図15】
【図16】
【図17】
【図18】
【図19】
【図14】
【公開番号】特開2011−61478(P2011−61478A)
【公開日】平成23年3月24日(2011.3.24)
【国際特許分類】
【出願番号】特願2009−208688(P2009−208688)
【出願日】平成21年9月9日(2009.9.9)
【出願人】(000002185)ソニー株式会社 (34,172)
【Fターム(参考)】
【公開日】平成23年3月24日(2011.3.24)
【国際特許分類】
【出願日】平成21年9月9日(2009.9.9)
【出願人】(000002185)ソニー株式会社 (34,172)
【Fターム(参考)】
[ Back to top ]