以下、図面を参照しながら本明細書で開示する技術の実施形態について詳細に説明する。
A.システム構成
図1には、本明細書で開示する技術を適用した通信システム100の構成例を模式的に示している。図示の通信システム100は、家庭内に敷設されたホーム・ネットワーク110上に接続されたサーバー101と端末102で構成される。同図では、簡素化のため、サーバーと端末をそれぞれ1台ずつしか描いていないが、2台以上のサーバー並びに端末がホーム・ネットワーク上に設置されることも想定される。
サーバー101は、端末102に提供するコンテンツを蓄積している。サーバー101は、例えば、地上ディジタル放送で受信した放送コンテンツや、ブルーレイ・ディスクなどの記録媒体(図示しない)から読み込んだ映画などの商用コンテンツ、さらにはインターネット上のコンテンツ・サーバー(図示しない)からダウンロードしたコンテンツを蓄積している。
ホーム・ネットワーク110を介したサーバー101と端末102間のコンテンツ伝送には、DTCP技術が適用されている。したがって、コンテンツを利用したい端末102は、所定の相互認証及び鍵交換(Authentication and Key Exchange:AKE)アルゴリズムに従って、サーバー101と相互認証するとともに鍵を共有した後に、サーバー101内に蓄積されたコンテンツを要求することができる。サーバー101は、要求されたコンテンツを、共有した鍵を用いて暗号化伝送する。コンテンツを提供するサーバー101はSourceデバイスに相当し、コンテンツを利用する端末102はSinkデバイスに相当する。
なお、端末102で外出先などホーム・ネットワーク110の外からサーバー101にアクセスしたいときには、ホーム・ネットワーク110上で端末102をサーバー101に事前登録しておく必要がある。
また、図2には、本明細書で開示する技術を適用した通信システム200の他の構成例を模式的に示している。図示の通信システム200は、家庭内に敷設されたホーム・ネットワーク210上に接続されたサーバー201と、インターネットなどの外部ネットワーク220上に接続された端末202で構成される。ホーム・ネットワーク210と外部ネットワーク220は、IP(Internet Protocol)プロトコルに従い、ルーター230経由で相互接続されている。同図では、簡素化のため、サーバーと端末をそれぞれ1台ずつしか描いていないが、ホーム・ネットワーク210上に2台以上のサーバーが設置されることや、ホーム・ネットワーク210上にも端末が接続され、さらに外部ネットワーク220上に2台以上の端末が接続されることも想定される。
サーバー201は、放送コンテンツや商用コンテンツなど、端末202に提供するコンテンツを蓄積している。また、ホーム・ネットワーク210及び外部ネットワーク220を介したサーバー201と端末202間のコンテンツ伝送には、DTCP−IP技術が適用されている。したがって、コンテンツを利用したい端末202は、ホーム・ネットワーク210上でサーバー201に事前に登録しておく必要がある(前述)。そして、端末202は、ホーム・ネットワーク210及び外部ネットワーク220からなるIPネットワーク越しに、サーバー201と相互認証するとともに交換鍵を共有した後に、サーバー201内に蓄積されたコンテンツを要求することができる。サーバー201は、要求されたコンテンツを、共有した交換鍵を用いて暗号化伝送する。コンテンツを提供するサーバー201はSourceデバイスに相当し、コンテンツを利用する端末202はSinkデバイスに相当する。
図3には、図1並びに図2において、サーバー101、201(すなわち、Sourceデバイス)として動作する通信装置300の機能的構成を模式的に示している。
通信・制御部301は、ホーム・ネットワーク並びに外部ネットワークを介した通信動作を制御するとともに、当該通信装置300全体の動作を統括的に制御する。また、通信・制御部301は、HDMI(High Definition Multimedia Interface)やUSB(Universal Serial Bus)などの外部機器接続用(若しくは、コンテンツのディジタル出力用)のインターフェースを備えており、ハード・ディスク装置やブルーレイ・ディスク装置などの録画再生機器を接続することができる。
コンテンツ記録部302は、ホーム・ネットワーク並びに外部ネットワーク越しで端末に提供するコンテンツを記録する。コンテンツ記録部302に記録された各コンテンツは、一般的なファイル・システムの管理下で、記録日時やアクセス日時が保持される。
本実施形態では、コンテンツ記録部302に記録されたコンテンツ毎にリモート・アクセスの制限を設定したり、複数のコンテンツをグループ化してコンテンツのグループ毎にリモート・アクセスの制限を設定したりすることができるが、その詳細については後述に譲る。また、コンテンツ記録部302は、各コンテンツ、又はコンテンツ・グループのメタデータも記録する。
コンテンツ取得部303は、端末に提供するコンテンツを取得する。コンテンツ取得部303は、例えば地上ディジタル放送用チューナーなどからなり、放送コンテンツを取得する。この場合のコンテンツ取得部303は、例えばARIB(Association of Radio Industries and Businesses:電波産業会)で規定される仕様に基づく。コンテンツ取得部303は、例えば、放送チャンネルの全セグメント又は一部のセグメントの受信機能、EPG(Electronic Program Guide)の機能(番組検索、番組情報の表示、番組予約)、HDCP(High−bandwidth Digital Content Protection)仕様などに基づくコピー制御機能、放送コンテンツを限定受信したり受信した放送コンテンツを外部出力する際に暗号化したりするコンテンツ保護機能、などを備えている。
また、コンテンツ取得部303は、ブルーレイ・ディスクなどのメディア再生装置からなり、映画などの商用コンテンツをメディアから読み取る。また、コンテンツ取得部303は、ブラウザーなどからなり、インターネット上のコンテンツ・サーバー(図示しない)から有償又は無償のコンテンツをダウンロードする。コンテンツ取得部303は、取得したコンテンツは、必要に応じて上記のコンテンツ記録部302内に記録してもよい。また、コンテンツ取得部303は、端末に提供するコンテンツをコンテンツ記録部302から取得することもある。
放送コンテンツや商用コンテンツなどの取得日時は、コンテンツ取得部303が放送コンテンツを受信し又は商用コンテンツを読み出す現在日時である。また、コンテンツ記録部302内のコンテンツの取得日時は、コンテンツを記録した記録日時であり、ファイル・システムなどが管理している。本実施形態では、リモート・アクセスする端末に対してコンテンツの取得日時又は記録日時に基づいてコンテンツの提供を制限する点に1つの特徴があるが、その詳細については後述に譲る。
コンテンツ提供部304は、端末からの要求に応答して、コンテンツ取得部303が取得したコンテンツを端末に提供する。コンテンツ提供部304は、例えばHTTP(Hypet Text Transfer Protocol)プロトコルが利用して、端末へコンテンツを伝送する。また、コンテンツ提供部304は、伝送するコンテンツを、認証・鍵共有部306により端末と共有した交換鍵を用いて暗号化する。端末が外部ネットワーク上からのリモート・アクセスによりコンテンツを要求する場合、その端末は端末管理部307に事前に登録されたものでなければならない。本実施形態では、コンテンツ提供部304は、リモート・アクセスする端末に対して登録日時やコンテンツの取得日時に基づいてコンテンツの提供を制限する点に1つの特徴があるが、その詳細については後述に譲る。
コンテンツ・リスト提供部305は、例えば端末からの要求に応答して、端末に提供可能なコンテンツのリストと詳細情報を、端末に提供する。上述からも分かるように、サーバー101、201が端末に提供可能なコンテンツは、コンテンツ取得部303が受信する放送コンテンツやメディアから読み出す商用コンテンツ、コンテンツ記録部302に既に記録されているコンテンツが挙げられる。コンテンツ・リストの提供には、例えば、DLNAのベースとなるUPnP(Universal Plug andPlay)で策定されている、コンテンツのリストとコンテンツの詳細情報を階層化して配信するCDS(Content Directory Service)機能が適用される。本実施形態では、リモート・アクセスする端末に対して登録日時やコンテンツの取得日時に基づいてコンテンツの提供を制限する点に1つの特徴があるが、その詳細については後述に譲る。
認証・鍵共有部306は、コンテンツの要求元となる端末との間で、DTCP−IPが規定する認証及び鍵交換(AKE)アルゴリズムに従って、相互認証並びにコンテンツ暗号化のための交換鍵の共有を行なう。認証・鍵共有部306は、外部ネットワークからリモート・アクセスによりコンテンツを要求してくる端末に対しては、リモート・アクセス用交換鍵KRを共有する(後述)。
端末管理部307は、コンテンツを要求する端末の情報を管理する。端末管理部307は、外部ネットワークからリモート・アクセスによりコンテンツを利用する端末に対して事前登録の処理を行なうとともに、その端末の情報を「remote sink registry」や「RAC(Remote Access Connection) registry」として管理するが、その詳細については後述に譲る。コンテンツの利用は私的利用の範囲内に制限すべきである。本実施形態では、リモート・アクセスする端末に対して登録日時やコンテンツの取得日時に基づいてコンテンツの提供を制限することにより、コンテンツの利用を私的利用の範囲に制限するようにする点に1つの特徴があるが、その点の詳細については後述に譲る。
なお、上記の機能ブロック303〜307は、通信・制御部301において、オペレーティング・システムやTCP/IPプロトコルの上位で実行するアプリケーション・プログラムとして実現することもできる。また、この種のアプリケーション・プログラムは、インターネットなどの広域ネットワーク上で所定のダウンロード・サイトで配信することができ、ディジタル放送チューナーやTV受像機などのCE(Consumer Electronics)機器、スマートフォンなどの多機能端末にダウンロードして利用に供される。
このようなダウンロード・サイトは、例えば、コンピューター・プログラムを記憶する記憶装置2611と、コンピューター・プログラムのダウンロード要求を受信したことに応じてそのダウンロードを認める通信装置2612とを備えたサーバー2610からなり(図26を参照のこと)、ダウンロードしたコンピューター・プログラムをインストールするクライアント装置(DTCP_Source又はDTCP_Sink)と併せてコンピューター・プログラム配信システム2600を構成する。この種のサーバーは、クライアントからのコンピューター・プログラムのダウンロード要求に対して、コンピューター・プログラムの名称を示す情報を通知する情報通知装置2613をさらに備えている。情報通知装置2613は、コンピューター・プログラムの名称とともに、例えば、家庭内に記録した商用コンテンツを遠隔地の端末に提供するアプリケーションであることを示す情報を通知する。
図4には、図1並びに図2において、端末102、202(すなわち、Sink)として動作する通信装置400の機能的構成を模式的に示している。
通信・制御部401は、ホーム・ネットワーク並びに外部ネットワークを介した通信動作を制御するとともに、当該通信装置400全体の動作を統括的に制御する。
コンテンツ・リスト閲覧部402は、Sourceとなるサーバー101、201に対して、コンテンツ・リストの取得要求を行ない、取得したコンテンツ・リストの閲覧画面を表示する。例えば、サーバー101、201が提供可能なコンテンツのリストをCDS情報(前述)として取得したときには、コンテンツ一覧画面が表示される。ユーザーはこの一覧画面を通して、再生出力したいコンテンツを選択することができる。本実施形態では、サーバー201にリモート・アクセスする端末202の場合、提供可能なコンテンツのリストは、サーバー201への登録日時やコンテンツの取得日時に基づいて制限される点に1つの特徴があるが、その詳細については後述に譲る。
コンテンツ取得部403は、コンテンツの取得要求をサーバー101、201に送信して、サーバー内のコンテンツを取得する。コンテンツ取得部403は、例えば、コンテンツ・リスト閲覧部402が表示するコンテンツ一覧画面の中でユーザーが選択したコンテンツの取得を要求する。サーバー101、201に対するコンテンツの取得要求並びにコンテンツの取得には、例えばHTTPプロトコルが利用される(後述)。本実施形態では、サーバー201にリモート・アクセスする端末202の場合、取得可能なコンテンツは、サーバー201への登録日時やコンテンツの取得日時に基づいて制限される点に1つの特徴があるが、その詳細については後述に譲る。
サーバー101、201から取得したコンテンツは、認証・鍵共有部406によりサーバー101、201との間で共有した交換鍵を用いて暗号化されている。コンテンツ復号部404は、サーバー101、201から取得した暗号化コンテンツこの暗号鍵を用いて復号化する。そして、コンテンツ再生出力部405は、復号したコンテンツを再生出力する。
認証・鍵共有部406は、コンテンツの要求先となるサーバー101、201との間で、DTCP−IPが規定する認証及び鍵交換(AKE)アルゴリズムに従って、相互認証並びにコンテンツ暗号化のための暗号鍵の共有を行なう。認証・鍵共有部406は、外部ネットワークからリモート・アクセスによりコンテンツを要求するサーバー201との間では、リモート・アクセス用交換鍵KRを共有する。また、認証・鍵共有部406は、ホーム・ネットワーク210接続時において、サーバー101に対してリモート・アクセスのための事前登録を行なう。
上記の機能ブロック402〜406は、通信・制御部401において、オペレーティング・システムやTCP/IPプロトコルの上位で実行するアプリケーション・プログラムとして実現することもできる。この種のアプリケーション・プログラムは、インターネットなどの広域ネットワーク上で所定のダウンロード・サイトで配信することができ、スマートフォンなど、ホーム・サーバー内のコンテンツを再生する多機能端末にダウンロードして利用に供される。
このようなダウンロード・サイトは、例えば、コンピューター・プログラムを記憶する記憶装置2611と、コンピューター・プログラムのダウンロード要求を受信したことに応じてそのダウンロードを認める通信装置2612とを備えたサーバー2610からなり(図26を参照のこと)、ダウンロードしたコンピューター・プログラムをインストールするクライアント装置(DTCP_Source又はDTCP_Sink)と併せてコンピューター・プログラム配信システム2600を構成する。この種のサーバーは、クライアントからのコンピューター・プログラムのダウンロード要求に対して、コンピューター・プログラムの名称を示す情報を通知する情報通知装置2613をさらに備えている。情報通知装置2613は、コンピューター・プログラムの名称とともに、例えば、家庭内に記録した商用コンテンツを遠隔地で閲覧することが認められるアプリケーションであることを示す情報を通知する。
本実施形態では、図2に示したような端末202からサーバー201へのリモート・アクセスはサーバー201への登録日時に基づいて制御され、登録日時から所定の期間が経過するとリモート・アクセスが制限されるようになっている(後述)。リモート・アクセスする端末202は、例えば認証・鍵共有部406がサーバー201への登録日時を管理し、所定の期間かけ経過する前に再登録の手続きを自動実行して、リモート・アクセスが制限されないように、登録日時をリフレッシュするようにしてもよい。
B.登録手続き
図5には、DTCPの仕様書、DTCP Volume 1 Supplement E Mapping DTCP to IP,Revision 1.4ed1(Informational Version)のV1SE.10.7.1節に記載されている、リモート・アクセスを行なうSinkデバイスをSourceデバイスに登録する手順を図解している。同図中、Sinkデバイスは端末202に相当し、Sourceデバイスはサーバー201に相当するものと理解されたい。
まず、SourceデバイスとSinkデバイス間で、RTT(Round Trip Time)の制限下で、AKE手続きが実施される(SEQ501)。例えば、SourceデバイスとSinkデバイスがホーム・ネットワーク210内にあれば、RTTの制限をクリアして、AKE手続きが成功裏に終了する。RTT−AKE手続き自体は、本明細書で開示する技術の要旨に直接関連しないので、ここでは詳細な説明を省略する。
次いで、Sinkデバイスは、コマンドRA_REGISTER.CMDを用いて、自分のSink−IDをSourceデバイスに送信する(SEQ502)。
ここで、Sinkデバイスは、Sink−IDとして、自分に固有のDevice ID、又は、IDuを送信する(SinkデバイスがCommon Device KeyとCommon Device Certificateを実装することで、Device IDがSinkの特定情報とならない場合には、IDuがSink−IDとして用いられる)。
Sourceデバイスは、RA_REGISTER.CMDで受け取ったSink−IDが、直前に完了したRTT−AKE手続で受信したDevice ID又はIDuと一致するかどうかをチェックする。
また、Sourceデバイスは、受け取ったSink−IDが、(端末管理部307で管理している)remote sink registryに既に記憶されているかどうかをチェックする。受け取ったSink−IDが既に記憶されている場合は、そのまま本手続きを終了する。
他方、受け取ったSink−IDがまだremote sink registryに記憶されていないときには、Sourceデバイスは、remote sink registryが満杯でないことを確認する。そして、受け取ったSink−IDが、直前に完了したRTT−AKE手続で受信したDevice ID又はIDuと一致し、且つ、remote sink registryが満杯でなければ、Sourceデバイスはremote sink registryに追加記憶する(SEQ504)。
また、Sourceデバイスは、登録した結果を、コマンドRA_REGISTER.RSPでSinkデバイスに返す(SEQ503)。
図2に示した通信システム200に当てはめて考察すると、Sourceデバイスとしてのサーバー201は、RTT−AKE手続きに成功した端末201(但し、ホーム・ネットワーク210に接続しているとき)のSink−IDを、端末管理部307で管理しているremote sink registryに追加記憶する。
ここで、サーバー201がremote sink registryに一度登録したSink−IDを保持し続けると、第三者の端末をサーバーに一度登録すれば、以後はその第三者がサーバー内のコンテンツを利用し続けることができてしまうという問題がある。
そこで、本実施形態では、サーバー201は、端末202からのリモート・アクセスを、端末202のサーバー201への登録日時に基づいて制限することにより、一旦登録した第三者が利用し続けることを防止し、私的利用の範囲を超えたコンテンツの利用を好適に抑制するようにしている。
C.登録日時に基づくリモート・アクセスの制限(1)
サーバー201が、登録日時に基づいて端末202からのリモート・アクセスを制限する方法の1つとして、登録日時から第1の所定の期間(例えば、30日間)を端末のリモート・アクセスを許可する有効期限として設定する方法が挙げられる。サーバー201は、コンテンツへのリモート・アクセスを要求した端末202が有効期限内であれば、コンテンツの利用を許可するが、有効期限を過ぎた端末202からのリモート・アクセスを許可しない。
サーバー201は、例えば、端末202をremote sink registryに登録する際に、現在日時に第1の所定期間を加算してその端末202の有効期限を算出して、Sink−IDとともに有効期限をペアにして、端末管理部307内に記憶するようにすればよい。
図6には、リモート・アクセスを行なうSinkデバイスを、有効期限とともにSourceデバイスに登録する手順を図解している。但し、Sourceデバイスは、ホーム・ネットワーク210に設置され、コンテンツを送信するサーバー201に相当し、Sinkデバイスは、サーバー201にコンテンツを要求する端末202に相当する(以下同様)。Sinkデバイスは、ホーム・ネットワーク210上で図6に示す登録手続きを一旦行なった後は、インターネットなどの外部ネットワーク220からサーバー201にリモート・アクセスする。
まず、SourceデバイスとSinkデバイス間で、RTT(Round Trip Time)の制限下で、AKE手続きが実施される(SEQ601)。
そして、RTT−AKE手続きに成功裏に終了すると、Sinkデバイスは、コマンドRA_REGISTER.CMDを用いて、自分のSink−IDをSourceデバイスに送信する(SEQ602)。
これに対し、Sourceデバイスは、RA_REGISTER.CMDで受け取ったSink−IDが、直前に完了したRTT−AKE手続で受信したDevice ID又はIDuと一致し、remote sink registryにまだ記憶しておらず、且つ、remote sink registryが満杯でないかどうかをチェックする。そして、これらの条件をクリアし、Sink−IDをremote sink registryに追加記憶するときには、Sourceデバイスは、コマンドRA_REGISTER.RSPでSinkデバイスに返す(SEQ603)。
また、Sourceデバイスは、Sinkデバイスの登録日時として現在日時を取得すると(SEQ604)、Sinkデバイスの登録の有効期間としての第1の所定の期間(例えば、30日間)を現在日時に加算して有効期限を算出すると(SEQ605)、Sink−IDと有効期限のペアを、remote sink registryに記憶する(SEQ606)。
図7には、Sink−IDと有効期限をペアにして格納したremote sink registryの登録内容を例示している。但し、図7に示したような端末の登録日時や有効期限の情報の管理を、ホーム・ネットワーク210上のサーバー201内で個別に行なうのではなく、クラウド上などに置かれた管理用サーバーで一元的に行なうようにしてもよい。
Sourceデバイス(サーバー201)は、登録日時としての現在日時を、例えば、サーバー内蔵の時計機能(図3では図示を省略)、放送波に含まれる時刻信号(例えば、コンテンツ取得部303がチューナー機能を装備して放送波を受信する場合)、ネットワーク上のサーバー(図示しない)から得た時刻情報などから取得することができる。
なお、端末202は、ユーザーが知らない間に、サーバー201へのリモート・アクセスが登録日時に基づいて制限されてしまわないように、認証・鍵共有部406などでサーバー201への登録日時を管理し、所定の期間が経過する前に再登録の手続き(すなわち、図6に示した処理シーケンスの再起動)を自動実行して、リモート・アクセスが制限されないように、登録日時をリフレッシュするようにしてもよい。勿論、端末202のユーザーがマニュアル操作で登録日時のリフレッシュを行なうようにしてもよい。
図8には、上記の事前登録を行なった後のSourceデバイスとSinkデバイス間でリモート・アクセスによるコンテンツ伝送を行なう手順を模式的に示している。図示のコンテンツ伝送は、Sinkデバイスが伝送を要求するコンテンツを指定するコンテンツ・リスト閲覧フェーズ(SEQ801)と、SourceデバイスとSinkデバイス間で相互認証及び鍵交換手順を実施してリモート・アクセス用交換鍵KRを共有するRA−AKE手続きフェーズ(SEQ802)と、コンテンツ・リスト閲覧フェーズで指定されたコンテンツを、リモート・アクセス用交換鍵KRを用いて暗号化伝送するコンテンツ伝送フェーズ(SEQ803)からなる。
図9には、コンテンツ・リスト閲覧フェーズ(SEQ801)の中身を模式的に示している。
Sinkデバイスからは、コンテンツ・リスト閲覧部402から、コンテンツ・リストの閲覧要求が発行される(SEQ901)。
本実施形態では、コンテンツ・リストの閲覧には、DLNAのベースとなるUPnPで策定されている、コンテンツのリストとコンテンツの詳細情報を階層化して配信するCDS(Content Directory Service)機能が適用される。したがって、SEQ901では、SinkデバイスからCDS:Browseアクションが発行される。
コンテンツ・リストの閲覧要求には、Sinkデバイスを特定するSink−IDが含められる。CDS:BrowseリクエストでSink−IDを送る手段としては、新たにヘッダー・フィールド(例えば、SinkID.dtcp.com)を設け、そのパラメーターとしてHTTPのヘッダー部分で送ることが考えられる。
Sourceデバイス側では、コンテンツ提供部304で提供可能なコンテンツ(例えば、コンテンツ取得部303で取得可能な放送コンテンツや商用コンテンツ、あるいは、自身のストレージであるコンテンツ記録部302に既に記録されているコンテンツなど)に対してCDS:Browseアクションが発行されたので、コンテンツ・リスト提供部305は、該当するコンテンツに関する取得可能なすべてのコンテンツ情報を取得して(SEQ902)、十分な情報量のCDS情報を生成する(SEQ903)。Sourceデバイスは、リモート・アクセスするSinkデバイスに対しては、Sinkデバイスの有効期限に基づいてCDS情報の提供を制限するようにしてもよい(後述)。そして、Sourceデバイスは、Sinkデバイスに対してCDS Resultとして返す(SEQ904)。
Sinkデバイス側では、コンテンツ・リスト閲覧部402が、受信したCDS Resultを解析して、コンテンツのタイトル並びにより詳細情報を含むコンテンツ情報を表示する(SEQ905)。
図22には、コンテンツ・リスト閲覧フェーズ(SEQ801)において、Sourceデバイスが、リモート・アクセスするSinkデバイスに対して、Sinkデバイスの有効期限に基づいてCDS情報の提供を制限するための処理手順をフローチャートの形式で示している。
まず、Sourceデバイスは、提供可能なコンテンツ情報をクリアする(ステップS2201)。
次いで、Sourceデバイスは、要求元のSinkデバイスのSink−IDに対応する有効期限を、remote sink registryから取得するとともに(ステップS2202)、現在日時を取得する(ステップS2203)。
そして、Sourceデバイスは、現在日時が要求元のSinkデバイスの有効期限を過ぎていないかどうかをチェックする(ステップS2204)。現在日時が有効期限を過ぎている場合には(ステップS2204のNo)、後続のコンテンツ情報の追加処理をスキップし、空のままコンテンツ情報を送信する(ステップS2208)。
一方、現在日時が要求元のSinkデバイスの有効期限を過ぎていないときには(ステップS2204のYes)、通常通り、コンテンツ情報の作成を行なう。すなわち、すべてのコンテンツ情報を処理するまで(ステップS2205のNo)、未処理のコンテンツのコンテンツ情報の参照と(ステップS2206)、このコンテンツ情報を提供可能なコンテンツ情報に追加する処理を(ステップS2207)、繰り返し実行する。そして、Sourceデバイスは、完成したコンテンツ情報を、要求元のSinkデバイスに送信する(ステップS2208)。
図22に示した処理手順は、例えば、図9に示したシーケンス図中のSEQ903において実施される。但し、Sourceデバイスは、この処理手順を必ず実施する必要はなく、Sinkデバイスの有効期限に拘わらず、自ら提供可能なすべてのコンテンツについてコンテンツ情報を提供するようにしてもよい。
Sinkデバイスのユーザーは、表示されているコンテンツ・リストの中から、再生したいコンテンツを選択することができる。そして、コンテンツが選択されると、SourceデバイスからSinkデバイスへのコンテンツの伝送が開始されるが、コンテンツ伝送に先駆けて、SinkデバイスとSourceデバイス間で、リモート・アクセス用の相互認証及び鍵交換すなわちRA−AKE処理が実施される。
図10には、DTCPの仕様書(前述)のV1SE.10.7.2節に記載されている、RA−AKE手続きフェーズ(SEQ802)の中身の詳細を示している。
Sinkデバイスは、リモート・アクセス用交換KR(Remote Exchange Key)用のビットが設定された交換鍵フィールドを含んだCHALLENGEコマンドを送信して、Sourceデバイスに対してAKE処理を要求する(SEQ1001)。そして、SourceデバイスとSinkデバイス間で、認証手続きのうちチャレンジ・レスポンス部分が実行される(SEQ1002〜1004)。
但し、CHALLENGEコマンドのKR用のビットが設定されていないときには、SourceデバイスはRA−AKE手続きを中止し、RA−AKE以外のAKE手続きを引き続き行なうことができる。
Sourceデバイスは、チャレンジ・レスポンス手続きでSinkデバイスから、Device ID又はIDuをSink−IDとして受け取ると(SEQ1005)、そのSink−IDが自身の端末管理部307内で管理しているremote sink registryに登録されているかどうかをチェックする(SEQ1006)。
Sink−IDがremote sink registryにリストされていない場合には(SEQ1006のNo)、Sourceデバイスは、SinkデバイスにAKE_CANCELコマンドを送信して(SEQ1014)、RA−AKE手続きを中止する(SEQ1015)。
一方、Sink−IDがremote sink registryに既に登録されている場合には(SEQ1006のYes)、Sourceデバイスは、このSink−IDに該当するRAC recordが既に存在するかどうかを判別するために、RAC registry(後述)内をチェックする(SEQ1007)。
Sink−IDに該当するRAC recordが存在する場合には(SEQ1007のYes)、Sourceデバイスは、そのRAC recordに格納されているリモート・アクセス用交換鍵KR及びその交換鍵ラベルKR_labelを使うことに決定する。あるいは、Sourceデバイスは、リモート・アクセス用交換鍵KRを用いてコンテンツの伝送を行なっていないのであれば、RAC record内を参照し、格納されているKR及びKR_labelの値を更新するようにしてもよい(SEQ1013)。
Sink−IDはremote sink registryに登録済みであるが、該当するRAC recordが存在しない場合には(SEQ1007のNo)、Sourceデバイスは、RAC recordをカウントするカウント値RACCがRACCmax未満であるかどうかをチェックする(SEQ1008)。ここで、RACCmaxは、リモート・アクセス・コネクションをカウントするカウンターであり、リモート・アクセス・コネクションが存在しないときにゼロに初期化される。
RACCがそのRACCmax未満でないときには(SEQ1008のNo)、Sourceデバイスは、SinkデバイスにAKE_CANCELコマンドを送信して(SEQ1014)、RA−AKE手続きを中止する(SEQ1015)。
RACCがRACCmax未満であれば(SEQ1008のYes)、Sourceデバイスは、RACCの値を1だけインクリメントした後(SEQ1009)、所定の演算規則に従って、リモート・アクセス用交換鍵KR及びその交換鍵ラベルKR_labelを生成して(SEQ1010)、これらをSinkデバイスのSink−IDと対応付けて、RAC registry内のRAC recordに格納する(SEQ1011)。サーバー201は、例えば端末管理部307内でRAC recordを管理する。図15には、Sinkデバイスに対して生成したリモート・アクセス用交換鍵KR及びその交換鍵ラベルKR_labelをSink−IDと対応付けてRAC recordとして記憶する様子を示している。
そして、Sourceデバイスは、既存のRAC recordから取り出したリモート・アクセス用交換鍵KR及びその交換鍵ラベルKR_label(更新した場合を含む)、又は、新たに生成したリモート・アクセス用交換鍵KR及びその交換鍵ラベルKR_labelを、Sinkデバイスに送信する(SEQ1016)。
SourceデバイスがRA_MANAGEMENT機能をサポートしている場合には、リモート・アクセス用交換KRを維持するためのKR用生存タイマーを開始させ、少なくとも1分間KRを保持する(SEQ1012)。
図10に示したDTCPの仕様書のV1SE.10.7.2節に記載されているRA−AKE手続きでは、Sourceデバイスは、最初の条件判断SEQ1006で、SinkデバイスのSink−IDがremote sink registryに登録されていることを確認した上でリモート・アクセス用交換鍵KRを共有する。
上述したように、Sourceデバイスがremote sink registryに一度登録したSink−IDを保持し続けると、第三者の端末をサーバーに一度登録すれば、以後はその第三者がサーバー内のコンテンツを利用し続けることができてしまうという問題がある。
そこで、本実施形態では、Sourceデバイスは、remote sink resistryに登録したSink−IDに登録日時からの有効期限を設定し(図6、図7を参照のこと)、有効期限が切れたSink−IDをremote sink resistryから抹消することで、一旦登録した第三者が利用し続けることを防止し、私的利用の範囲を超えたコンテンツの利用を好適に抑制するようにしている。有効期限が切れたSink−IDの抹消処理は、例えばSourceデバイス内で行なうことができる。
図11には、有効期限が切れたSink−IDをremote sink resistryから抹消する処理を含んだ、RA−AKE手続きフェーズ(SEQ802)の中身の詳細を示している。
Sinkデバイスがリモート・アクセス用交換KR用のビットが設定された交換鍵フィールドを含んだCHALLENGEコマンドを送信して、Sourceデバイスに対してAKE処理を要求すると(SEQ1101)、SourceデバイスとSinkデバイス間で、認証手続きのうちチャレンジ・レスポンス部分が実行される(SEQ1102〜1104)。そして、Sourceデバイスは、チャレンジ・レスポンス手続きでSinkデバイスから、Device ID又はIDuをSink−IDとして受け取ることができる(SEQ1105)。
ここで、Sourceデバイスは、remote sink resistryのメンテナンス、すなわち、有効期限が切れたSink−IDをremote sink resistryから抹消する処理を実施する(SEQ1106)。登録日時を基準にして設定された有効期限が切れたSink−IDをremote sink resistryから抹消することで、一旦登録した第三者が利用し続けることを防止する。remote sink resistryのメンテナンス処理が実施された後は、有効期限内のエントリーのみが残っているものとする。remote sink resistryのメンテナンス処理の詳細については、後述に譲る。
次いで、Sourceデバイスは、受け取ったSink−IDが自身の端末管理部307内で管理しているremote sink registryにリストされているかどうかをチェックする(SEQ1107)。
Sink−IDがremote sink registryにリストされていない場合には(SEQ1107のNo)、Sourceデバイスは、SinkデバイスにAKE_CANCELコマンドを送信して(SEQ1116)、RA−AKE手続きを中止する(SEQ1117)。
一方、Sink−IDがremote sink registryにリストされている場合には(SEQ1107のYes)、Sourceデバイスは、このSink−IDに該当するRAC recordが既に存在するかどうかを判別するために、RAC registry(後述)内をチェックする(SEQ1108)。
Sink−IDに該当するRAC recordが存在する場合には(SEQ1108のYes)、Sourceデバイスは、そのRAC recordに格納されているリモート・アクセス用交換鍵KR及びその交換鍵ラベルKR_labelを使うことに決定する。あるいは、Sourceデバイスは、リモート・アクセス用交換鍵KRを用いてコンテンツの伝送を行なっていないのであれば、RAC record内を参照し、格納されているKR及びKR_labelの値を更新するようにしてもよい(SEQ1114)。
Sink−IDはremote sink registryにリストされているが、該当するRAC recordが存在しない場合には(SEQ1108のNo)、Sourceデバイスは、RAC recordをカウントするカウント値RACCがRACCmax未満であるかどうかをチェックする(SEQ1109)。
RACCがそのRACCmax未満でないときには(SEQ1109のNo)、Sourceデバイスは、SinkデバイスにAKE_CANCELコマンドを送信して(SEQ1115)、RA−AKE手続きを中止する(SEQ1116)。
RACCがRACCmax未満であれば(SEQ1109のYes)、Sourceデバイスは、RACCの値を1だけインクリメントした後(SEQ1110)、所定の演算規則に従って、リモート・アクセス用交換鍵KR及びその交換鍵ラベルKR_labelを生成して(SEQ1111)、これらをSinkデバイスのSink−IDと対応付けて、RAC registry内のRAC recordに格納する(SEQ1112)。サーバー201は、例えば端末管理部307内でRAC recordを管理する。図15には、Sinkデバイスに対して生成したリモート・アクセス用交換鍵KR及びその交換鍵ラベルKR_labelをSink−IDと対応付けてRAC recordとして記憶する様子を示している。
そして、Sourceデバイスは、既存のRAC recordから取り出したリモート・アクセス用交換鍵KR及びその交換鍵ラベルKR_label(更新した場合を含む)、又は、新たに生成したリモート・アクセス用交換鍵KR及びその交換鍵ラベルKR_labelを、Sinkデバイスに送信する(SEQ1117)。また、SourceデバイスがRA_MANAGEMENT機能をサポートしている場合には、リモート・アクセス用交換KRを維持するためのKR用生存タイマーを開始させ、少なくとも1分間KRを保持する(SEQ1113)。
SEQ1106で実施されるremote sink registryのメンテナンス処理では、Sink−IDと有効期限をペアにして格納したremote sink registryの登録内容(図7を参照のこと)を参照して、登録日時を基準にして設定された有効期限が切れたSink−IDのエントリーをremote sink resistryから抹消する。このメンテナンス処理は、Sourceデバイスとしてのサーバー201内で行なうことができるが、クラウド上などに置かれた管理用サーバーで一元的に端末の登録日時や有効期限の情報の管理とともに行なうようにしてもよい。
図12には、remote sink registryのメンテナンス処理の手順をフローチャートの形式で示している。以下では、便宜上、Sourceデバイスとしてのサーバー201内でメンテナンス処理を行なうものとして説明する。このメンテナンス処理は、例えばサーバー201内の認証・鍵共有部306が、RA−AKE手続きフェーズの中で実施する。
サーバー201は、端末管理部307内で管理しているremote sink registry中で、有効期限を未確認のSinkデバイスに関して(ステップS1201のNo)、そのSink−IDとペアにして記憶されている有効期限を参照し(ステップS1202)、現在日時が有効期限を過ぎていないかどうかをチェックする(ステップS1203)。そして、現在日時が有効期限を過ぎているSink−IDのエントリーを(ステップS1203のYes)、remote sink registryから削除する(ステップS1204)。
そして、remote sink registry内に登録されているすべてのSinkのエントリーについてステップS1202〜S1204の処理を終了するまで(ステップS1201のYes)、繰り返し実行する。
図12に示したremote sink registryのメンテナンス処理は、各サーバー201が個別に実施する(言い換えれば、サーバー201が設置されたホーム・ネットワーク210単位で実施する)のではなく、クラウド上の管理サーバーなどで各家庭のサーバー201のremote sink registryを一元的に集中管理するようにしてもよい。
また、図12に示したようなremote sink registryのメンテナンス処理を、RA−AKE手続き時に逐次行なうのではなく、サーバー201又はクラウド上の管理サーバーなどが、(RA−AKE手続きを実施するか否かに拘わらず)定期的に行なうようにしてもよい。
また、図11及び図12では、1回のメンテナンス処理でremote sink registry内のすべてのエントリーについて有効期限の確認処理を実行するようになっているが、RA−AKE手続きの対象となっているSink−IDに対応するエントリーについてのみ有効期限の確認処理(有効期限を過ぎたエントリーの抹消処理)を行なうだけでもよい。
また、RA−AKE手続きフェーズで有効期限が過ぎた端末のレコードの抹消処理を行なう代わりに、後段のコンテンツ伝送フェーズで有効期限を過ぎた端末へのコンテンツの送信を制限する「コンテンツ出力管理」を含めるようにしてもよい。この場合、図11ではなく、抹消処理を含まない図10に示した手順に従ってRA−AKE手続きを実施して、有効期限に拘わらず、すべてのSinkデバイスにリモート・アクセス用交換鍵KR及びその交換鍵ラベルKR_labelを配布しておく。そして、SEQ803のコンテンツ伝送フェーズにおいて、要求元Sinkデバイスの有効期限のチェックを行なうようにする。
図18には、有効期限に基づくコンテンツの出力管理を含んだコンテンツ伝送フェーズ(SEQ803)の中身を模式的に示している。
Sinkデバイスは、RA−AKE手続により取得したリモート・アクセス用交換鍵KR及びその交換鍵ラベルKR_labelを取得した後に、例えば、HTTP GETメソッドを用いたHTTPリクエスト(HTTP GET request)により、Sourceデバイスに対して、コンテンツの伝送を要求する(SEQ1801)。この要求の際には、コンテンツのURL(Uniform Resource Locator)とともに、リモート・アクセス用交換鍵KRのIDであるラベルKR_labelを送る。ここで、SinkデバイスからSourceデバイスに交換鍵のID(KR_label)を送るためのヘッダー・フィールドを定義する。
ここで、Sourceデバイスは、Sinkデバイスからコンテンツの伝送要求を受けると、有効期限に基づくコンテンツ出力管理の処理を実行する(SEQ1802)。
Sourceデバイスは、RA−AKE手続きにおいて、リモート・アクセス用交換鍵KR及びその交換鍵ラベルKR_labelをSinkデバイスに送る際に、これらをSink−IDと対応付けてRAC recordとして記憶している(前述並びに図15を参照のこと)。したがって、Sourceデバイスは、コンテンツ要求に含まれる交換鍵ラベルKR_labelに該当するRAC Recordから、要求元SinkデバイスのSink−IDを調べることができる。
また、Sourceデバイスは、Sinkデバイスの登録時、すなわち、Sink−IDをremote sink registryに登録する際に、有効期限を算出して、Sink−IDとペアにして記憶している(前述並びに図7を参照のこと)。したがって、RAC Recordから得たSink−IDに基づいて、そのSinkデバイスの有効期限を調べることができる。
そして、Sourceデバイスは、現在日時が要求元Sinkデバイスの有効期限を過ぎていなければコンテンツ要求を許可するが、現在日時が有効期限を過ぎているときにはコンテンツ要求を許可しない。また、Sourceデバイスは、有効期限を過ぎたSinkデバイスのエントリーをremote sink registryから削除するようにしてもよい。
Sourceデバイスは、Sinkデバイスからのコンテンツ要求を許可する場合には、交換鍵ラベルKR_labelで指定されたリモート・アクセス用交換鍵KRをRAC recordから取り出すと、これを用いてコンテンツを暗号化して、HTTPレスポンス(HTTP GET response)としてSinkデバイスに伝送する(SEQ1803)。
図19には、SEQ1802において実施するコンテンツ出力管理の処理手順をフローチャートの形式で示している。以下では、便宜上、Sourceデバイスとしてのサーバー201内で、例えばコンテンツ提供部304がコンテンツ出力管理処理を行なうものとして説明する。
サーバー201は、コンテンツ要求(HTTP GET request)に含まれる交換鍵ラベルKR_labelを参照し(ステップS1901)、同じ交換鍵ラベルKR_labelのRAC recordが端末管理部307内に存在するかどうかをチェックする(ステップS1902)。
ここで、同じ交換鍵ラベルKR_labelのRAC recordが存在しない場合には(ステップS1902のNo)、要求元のSinkデバイスがRA−AKE手続きを行なっていないなどの原因により、不正なコンテンツ要求である。そこで、サーバー201は、後続の処理をすべてスキップして、本処理ルーチンを終了する。
一方、同じ交換鍵ラベルKR_labelのRAC recordが存在する場合には(ステップS1902のYes)、サーバー201は、そのRA recordから、交換鍵ラベルKR_labelに対応するSink−IDを取得する(ステップS1903)。
次いで、サーバー201は、端末管理部307内のremote sink registryから、Sink−IDとペアにして記憶されている有効期限を取得する(ステップS1904)。但し、各Sink−IDの有効期限を例えばクラウド上の管理サーバーに委ねている場合には、サーバー201は、通信・制御部301を介して管理サーバーにアクセスして、該当する有効期限の情報を取得する。
そして、サーバー201は、現在日時を取得し(ステップS1905)、現在日時が要求元のSinkデバイスの有効期限を過ぎていないかどうかをチェックする(ステップS1906)。現在日時が有効期限を過ぎている場合には(ステップS1906のYes)、該当するSink−IDのエントリーを、remote sink registryから削除して(ステップS1907)、本処理ルーチンを終了する。
一方、現在日時が要求元のSinkデバイスの有効期限を過ぎていないときには(ステップS1906のNo)、サーバー201は、Sinkデバイスからのコンテンツ要求を許可し、要求されたコンテンツの送信を例えばHTTP GET responseで行なう(ステップS1908)。
このように、端末のサーバーへの登録日時に第1の所定の期間を加算した有効期限を設定し、有効期限内の端末に対してのみサーバー内のコンテンツへのリモート・アクセスを許可し、有効期限を経過した以降はリモート・アクセスを禁止することにより、第三者による私的利用の範囲を超えたコンテンツの利用を抑制することができる。
D.登録日時に基づくリモート・アクセスの制限(2)
サーバー201が、登録日時に基づいて端末202からのリモート・アクセスを制限する他の方法として、登録日時から第2の所定期間α(例えば、3日間)を端末202がリモート・アクセス可能なコンテンツの限界日時として設定する方法が挙げられる。例えば、端末202が持つ限界日時より以前にコンテンツ記録部302に記録されたコンテンツのリモート・アクセスは許可されるが、限界日時以降に記録されたコンテンツのリモート・アクセスは許可されない。また、限界日時より以前にコンテンツ取得部303が取得するコンテンツのリモート・アクセスは許可されるが、限界日時以降にコンテンツ取得部303が取得するコンテンツのリモート・アクセスは許可されない。
サーバー201は、例えば、端末202をremote sink registryに登録する際に、現在日時に第2の所定期間αを加算してその端末202の限界日時を算出して、Sink−IDとともに限界日時をペアにして記憶するようにすればよい。
図13には、リモート・アクセスを行なうSinkデバイスを、限界日時とともにSourceデバイスに登録する手順を図解している。
まず、SourceデバイスとSinkデバイス間で、RTT(Round Trip Time)の制限下で、AKE手続きが実施される(SEQ1301)。そして、RTT−AKE手続きに成功裏に終了すると、Sinkデバイスは、コマンドRA_REGISTER.CMDを用いて、自分のSink−IDをSourceデバイスに送信する(SEQ1302)。
Sourceデバイスは、RA_REGISTER.CMDで受け取ったSink−IDが、直前に完了したRTT−AKE手続で受信したDevice ID又はIDuと一致し、remote sink registryにまだ記憶しておらず、且つ、remote sink registryが満杯でないかどうかをチェックする。そして、これらの条件をクリアし、Sink−IDをremote sink registryに追加記憶するときには、Sourceデバイスは、コマンドRA_REGISTER.RSPでSinkデバイスに返す(SEQ1303)。
また、Sourceデバイスは、Sinkデバイスの登録日時として現在日時を取得すると(SEQ1304)、Sinkデバイスの登録の限界日時としての第2の所定の期間α(例えば、3日間)を現在日時に加算して限界日時を算出して(SEQ1305)、Sink−IDと限界のペアを、remote sink registryに記憶する(SEQ1306)。
図14には、Sink−IDと限界日時をペアにして格納したremote sink registryの登録内容を例示している。但し、図14に示したような端末の登録日時や限界日時の情報の管理を、ホーム・ネットワーク210上のサーバー201内で個別に行なうのではなく、クラウド上などに置かれた管理用サーバーで一元的に行なうようにしてもよい。
なお、Sourceデバイス(サーバー201)は、登録日時としての現在日時を、例えば、サーバー内蔵の時計機能(図3では図示を省略)、放送波に含まれる時刻信号(例えば、コンテンツ取得部303がチューナー機能を装備して放送波を受信する場合)、ネットワーク上のサーバー(図示しない)から得た時刻情報などから取得することができる。
コンテンツ伝送に先駆けて、SinkデバイスとSourceデバイス間で、リモート・アクセス用の相互認証及び鍵交換すなわちRA−AKE処理が実施された後に、コンテンツ伝送が開始される。
図16には、リモート・アクセス用交換鍵KRを用いて暗号化伝送するコンテンツ伝送フェーズ(SEQ803)の中身を模式的に示している。図示のシーケンスには、限界日時に基づくコンテンツ出力管理の処理が含まれている。
Sinkデバイスは、RA−AKE手続により取得したリモート・アクセス用交換鍵KR及びその交換鍵ラベルKR_labelを取得した後に、例えば、HTTP GETメソッドを用いたHTTPリクエスト(HTTP GET request)により、Sourceデバイスに対して、コンテンツの伝送を要求する(SEQ1601)。この要求の際には、コンテンツのURL(Uniform Resource Locator)とともに、リモート・アクセス用交換鍵KRのIDであるラベルKR_labelを送る。ここで、SinkデバイスからSourceデバイスに交換鍵のID(KR_label)を送るためのヘッダー・フィールドを定義する。
ここで、Sourceデバイスは、Sinkデバイスからコンテンツの伝送要求を受けると、限界日時に基づくコンテンツ出力管理の処理を実行する(SEQ1602)。
Sourceデバイスは、RA−AKE手続きにおいて、リモート・アクセス用交換鍵KR及びその交換鍵ラベルKR_labelをSinkデバイスに送る際に、これらをSink−IDと対応付けてRAC recordとして記憶している(前述並びに図15を参照のこと)。したがって、Sourceデバイスは、コンテンツ要求に含まれる交換鍵ラベルKR_labelに該当するRAC Recordから、要求元SinkデバイスのSink−IDを調べることができる。
また、Sourceデバイスは、Sinkデバイスの登録時、すなわち、Sink−IDをremote sink registryに登録する際に、限界日時を算出して、Sink−IDとペアにして記憶している(前述並びに図14を参照のこと)。したがって、RAC Recordから得たSink−IDに基づいて、そのSinkデバイスの限界日時を調べることができる。
そして、Sourceデバイスは、要求元Sinkデバイスが持つ限界日時より以前にSourceデバイスに記録されたコンテンツであれば、Sinkデバイスからのコンテンツ要求を許可するが、限界日時を経過した以降にSourceデバイスに記録されたコンテンツについては、Sinkデバイスからのコンテンツ要求を許可しない。
Sourceデバイスは、Sinkデバイスからのコンテンツ要求を許可する場合には、交換鍵ラベルKR_labelで指定されたリモート・アクセス用交換鍵KRをRAC recordから取り出すと、これを用いてコンテンツを暗号化して、HTTPレスポンス(HTTP GET response)としてSinkデバイスに伝送する(SEQ1603)。
図17には、SEQ1602において実施するコンテンツ出力管理処理の手順をフローチャートの形式で示している。以下では、便宜上、Sourceデバイスとしてのサーバー201内で、例えばコンテンツ提供部304がコンテンツ出力管理処理を行なうものとして説明する。
サーバー201は、コンテンツ要求(HTTP GET request)に含まれる交換鍵ラベルKR_labelを参照し(ステップS1701)、同じ交換鍵ラベルKR_labelのRAC recordが端末管理部307内に存在するかどうかをチェックする(ステップS1702)。
ここで、同じ交換鍵ラベルKR_labelのRAC recordが存在しない場合には(ステップS1702のNo)、要求元のSinkデバイスがRA−AKE手続きを行なっていないなどの原因により、不正なコンテンツ要求である。そこで、サーバー201は、後続の処理をすべてスキップして、本処理ルーチンを終了する。
一方、同じ交換鍵ラベルKR_labelのRAC recordが存在する場合には(ステップS1702のYes)、サーバー201は、そのRA recordから、交換鍵ラベルKR_labelに対応するSink−IDを取得する(ステップS1703)。
次いで、サーバー201は、端末管理部307内のremote sink registryから、Sink−IDとペアにして記憶されている限界日時を取得する(ステップS1704)。但し、各Sink−IDの限界日時を例えばクラウド上の管理サーバーに委ねている場合には、サーバー201は、通信・制御部301を介して管理サーバーにアクセスして、該当する限界日時の情報を取得する。
また、サーバー201は、コンテンツ要求(HTTP GET request)で要求されているコンテンツがコンテンツ記録部302に記録された記録日時を、ファイル・システムから取得する(ステップS1705)。但し、要求されているコンテンツが、放送コンテンツなどコンテンツ取得部304で取得するコンテンツの場合には、その取得日時として現在日時(受信日時)を取得する。
そして、サーバー201は、コンテンツ要求されているコンテンツの記録日時又は取得日時が、Sinkデバイスに設定されている限界日時を超えていないかどうかをチェックする(ステップS1706)。
コンテンツの記録日時又は取得日時がSinkデバイスの限界日時を超えていないときには(ステップS1706のYes)、サーバー201は、Sinkデバイスからのコンテンツ要求を許可し、次ステップS1707で、要求されたコンテンツの送信を例えばHTTP GET responseで行なう。
また、コンテンツの記録日時又は取得日時がSinkデバイスの限界日時を超えているときには(ステップS1706のNo)、サーバー201は、Sinkデバイスからのコンテンツ要求を許可せず、後続の処理をスキップして、本処理ルーチンを終了する。
このように、端末のサーバーへの登録日時に第2の所定の期間を加算した限界日時を設定して、端末がリモート・アクセスにより利用可能なコンテンツを、限界日時以前に記録されたコンテンツ又は限界日時以前に取得されたコンテンツだけに制限することにより、第三者による私的利用の範囲を超えたコンテンツの利用を好適に抑制することができる。
なお、限界日時に基づくリモート・アクセスの制限を、コンテンツ・リスト閲覧フェーズ(SEQ801)で行なうこともできる。
図24には、コンテンツ・リスト閲覧フェーズ(SEQ801)において、Sourceデバイスが、リモート・アクセスするSinkデバイスに対して、Sinkデバイスの限界日時に基づいてCDS情報の提供を制限するための処理手順をフローチャートの形式で示している。
まず、Sourceデバイスは、提供可能なコンテンツ情報をクリアする(ステップS2401)。次いで、Sourceデバイスは、要求元のSinkデバイスのSink−IDに対応する限界日時を、remote sink registryから取得するとともに(ステップS2402)。
そして、Sourceデバイスは、すべてのコンテンツ情報を処理するまで(ステップS2403のNo)、コンテンツ情報の作成を行なう。すなわち、Sourceデバイスは、未処理のコンテンツのコンテンツ情報を参照すると(ステップS2404)、そのコンテンツがコンテンツ記録部302に記録された記録日時を、ファイル・システムから取得する(ステップS2405)。但し、要求されているコンテンツが、放送コンテンツなどコンテンツ取得部304で取得するコンテンツの場合には、その取得日時として現在日時(受信日時)を取得する。
そして、Sourceデバイスは、そのコンテンツの記録日時又は取得日時が、Sinkデバイスに設定されている限界日時を超えていないかどうかをチェックする(ステップS2406)。
そのコンテンツの記録日時又は取得日時がSinkデバイスの限界日時を超えていないときには(ステップS2406のYes)、Sourceデバイスは、このコンテンツ情報を提供可能なコンテンツ情報に追加する(ステップS2407)。そして、ステップS2403に戻り、すべてのコンテンツ情報を処理したかどうかをチェックする。
一方、そのコンテンツの記録日時又は取得日時がSinkデバイスの限界日時を超えているときには(ステップS2406のNo)、Sourceデバイスは、このコンテンツ情報を提供可能なコンテンツ情報に追加することなく、ステップS2403に戻り、すべてのコンテンツ情報を処理したかどうかをチェックする。
そして、すべてのコンテンツ情報の処理が終了したときには(ステップS2403のYes)、Sourceデバイスは、完成したコンテンツ情報を、要求元のSinkデバイスに送信する(ステップS2408)。
このように、限界日時以前に記録されたコンテンツ又は限界日時以前に取得されたコンテンツだけに制限して、Sinkデバイスにコンテンツ情報を提供することによっても、第三者による私的利用の範囲を超えたコンテンツの利用を好適に抑制することができる。
E.登録日時に基づくリモート・アクセスの制限の緩和
上記のC項並びにD項では、端末202をサーバー201に登録した登録日時に基づいて設定した有効期限又は限界日時を用いて端末202からのリモート・アクセスを制限することによって、一旦登録した第三者が利用し続けることを防止し、私的利用の範囲を超えたコンテンツの利用を抑制するようにしている。
ところが、サーバー201に登録するすべての端末に対して、登録日時に基づくリモート・アクセスの制限を課すと、第三者による利用を抑制できる反面、正規のユーザーによる正当な(すなわち、私的利用の範囲内での)コンテンツの利用まで不必要に制限され、ユーザーに不便を感じさせてしまうおそれがある。ユーザーに不便を与えると、せっかくの通信システム200の利用が普及しなくなってしまう。
そこで、サーバー201に登録する所定の台数の端末については、登録日時に基づくリモート・アクセスの制限の適用を免除するようにしてもよい。
この場合、図11ではなく図10に示した手順に従ってRA−AKE手続きを実施して、有効期限による登録抹消処理を行なうことなしに、すべてのSinkデバイスにリモート・アクセス用交換鍵KR及びその交換鍵ラベルKR_labelを配布しておく。そして、SinkデバイスをSourceデバイスに登録する手続きにおいて(図6、図13を参照のこと)、所定の台数の端末については、有効期限や限界日時として大きな値、又は、有効期限や限界日時が免除されていることを示す特定の値を設定する。このようにすれば、コンテンツ伝送フェーズ(図18、図16を参照のこと)におけるコンテンツ出力管理処理では(図19、図17を参照のこと)、ステップS1905、ステップS1706において、有効期限や限界日時による制限が適用されないようにすることができる。
所定台数の端末までは、サーバーへの登録日時に基づくリモート・アクセスの制限を免除することにより、私的利用の範囲内でのコンテンツの利用の利便性を確保することができる。
また、図22並びに図24には、コンテンツ・リスト閲覧フェーズ(SEQ801)において、リモート・アクセスするSinkデバイスに対して、有効期限や限界日時に基づいてCDS情報の提供を制限するための処理手順を示した。この場合も同様に、所定台数の端末まではサーバーへの登録日時に基づく制限なしにCDS情報の提供を行なうことにより、私的利用の範囲内でのコンテンツの利用の利便性を確保することができる。
また、登録日時に基づくリモート・アクセスの制限の適用を免除する端末を、サーバー201内に記録しているコンテンツ毎、あるいはコンテンツのグループ毎に設定するようにしてもよい。
例えば、ユーザーがサーバー201に対しコンテンツの記録予約や記録要求を行なう際に、端末管理部307内(すなわち、remote sink registry)に登録されている利用可能な端末の中から、制限の適用を免除する端末を選択する方法や、ユーザー毎に制限の適用を免除する端末のSink−IDを登録しておくことで、コンテンツの記録予約や記録要求の操作を行なったユーザーの端末を自動的に適用免除に割り当てる方法が考えられる。なお、その際のユーザーを認識する手段として、例えばサーバー201へのログインID、ユーザーによる指示、カメラ又はセンサーによるユーザー認識などが挙げられる。
制限の適用を免除する端末をコンテンツ毎に登録する場合、各コンテンツに関するメタデータとして端末のSink−IDを保持する。また、制限の適用を免除する端末をコンテンツのグループ毎に登録する場合には、各コンテンツ・グループに関するメタデータとして端末のSink−IDを保持することとする。
リモート・アクセスの制限の適用を免除する端末を、コンテンツ毎、あるいはコンテンツのグループ毎に設定する場合、図11ではなく、図10に示した手順に従ってRA−AKE手続きを実施して、有効期限による登録抹消処理を行なうことなしに、すべてのSinkデバイスにリモート・アクセス用交換鍵KR及びその交換鍵ラベルKR_labelを配布しておく。そして、コンテンツ伝送フェーズ(図18、図16を参照のこと)におけるコンテンツ出力管理処理において、コンテンツ毎又はコンテンツのグループ毎に設定されたリモート・アクセスの制限適用免除に従って、端末へのコンテンツ送信を制御する。
図20には、有効期限に基づくリモート・アクセスの制限の適用を免除する端末が登録されている場合の、コンテンツ出力管理処理の手順をフローチャートの形式で示している。以下では、便宜上、Sourceデバイスとしてのサーバー201内で、例えばコンテンツ提供部304がコンテンツ出力管理処理を行なうものとして説明する。
サーバー201は、コンテンツ要求(HTTP GET request)に含まれる交換鍵ラベルKR_labelを参照し(ステップS2001)、同じ交換鍵ラベルKR_labelのRAC recordが端末管理部307内に存在するかどうかをチェックする(ステップS2002)。
ここで、同じ交換鍵ラベルKR_labelのRAC recordが存在しない場合には(ステップS2002のNo)、要求元のSinkデバイスがRA−AKE手続きを行なっていないなどの原因により、不正なコンテンツ要求である。そこで、サーバー201は、後続の処理をすべてスキップして、本処理ルーチンを終了する。
一方、同じ交換鍵ラベルKR_labelのRAC recordが存在する場合には(ステップS2002のYes)、サーバー201は、そのRA recordから、交換鍵ラベルKR_labelに対応するSink−IDを取得する(ステップS2003)。
次いで、サーバー201は、要求されているコンテンツを含むコンテンツ・グループのメタデータに、このSink−IDが存在するかどうか、すなわち、当該コンテンツ・グループに対する有効期限によるリモート・アクセスの制限の適用が免除されているSink−IDであるかどうかをチェックする(ステップS2004)。そして、当該コンテンツ・グループのメタデータにSink−IDが存在する場合には(ステップS2004のYes)、サーバー201は、Sinkデバイスからのコンテンツ要求を許可し、要求されたコンテンツの送信を例えばHTTP GET responseで行なう(ステップS2009)。
また、サーバー201は、要求されているコンテンツのメタデータに、このSink−IDが存在するかどうか、すなわち、当該コンテンツに対する有効期限によるリモート・アクセスの制限の適用が免除されているSink−IDであるかどうかをチェックする(ステップS2005)。そして、当該コンテンツのメタデータにSink−IDが存在する場合には(ステップS2005のYes)、サーバー201は、Sinkデバイスからのコンテンツ要求を許可し、要求されたコンテンツの送信を例えばHTTP GET responseで行なう(ステップS2009)。
他方、Sink−IDがコンテンツ・グループ並びにコンテンツのいずれのメタデータにも存在しない場合、すなわち、有効期限によるリモート・アクセスの制限の適用が免除されていない場合には(ステップS2005、S2004のNo)、端末管理部307内のremote sink registryから、Sink−IDとペアにして記憶されている有効期限を取得する(ステップS2006)。
そして、サーバー201は、現在日時を取得し(ステップS2007)、現在日時が要求元のSinkデバイスの有効期限を過ぎていないかどうかをチェックする(ステップS2008)。現在日時が有効期限を過ぎている場合には(ステップS2008のNo)、コンテンツを送信することなく、本処理ルーチンを終了する。
一方、現在日時が要求元のSinkデバイスの有効期限を過ぎていないときには(ステップS2008のYes)、サーバー201は、Sinkデバイスからのコンテンツ要求を許可し、要求されたコンテンツの送信を例えばHTTP GET responseで行なう(ステップS2009)。
なお、有効期限に基づくリモート・アクセスの制限の適用免除を、コンテンツ・リスト閲覧フェーズ(SEQ801)で行なうこともできる。
図23には、コンテンツ・リスト閲覧フェーズ(SEQ801)において、Sourceデバイスが、リモート・アクセスするSinkデバイスに対して、Sinkデバイスの有効期限に基づくCDS情報の提供制限を免除するための処理手順をフローチャートの形式で示している。
まず、Sourceデバイスは、提供可能なコンテンツ情報をクリアする(ステップS2301)。
次いで、Sourceデバイスは、要求元のSinkデバイスのSink−IDに対応する有効期限を、remote sink registryから取得するとともに(ステップS2302)、現在日時を取得する(ステップS2303)。
そして、Sourceデバイスは、すべてのコンテンツ情報を処理するまで(ステップS2304のNo)、コンテンツ情報の作成を行なう。
Sourceデバイスは、未処理のコンテンツのコンテンツ情報を参照すると(ステップS2305)、そのコンテンツを含むコンテンツ・グループのメタデータに、要求元のSink−IDが存在するかどうか、すなわち、当該コンテンツ・グループに対する有効期限によるリモート・アクセスの制限の適用が免除されているSink−IDであるかどうかをチェックする(ステップS2306)。そして、当該コンテンツ・グループのメタデータにSink−IDが存在する場合には(ステップS2306のYes)、Sourceデバイスは、ステップS2305で参照したコンテンツ情報を提供可能なコンテンツ情報に追加してから(ステップS2309)、ステップS2304に戻る。
また、Sourceデバイスは、そのコンテンツのメタデータに、要求元のSink−IDが存在するかどうか、すなわち、当該コンテンツに対する有効期限によるリモート・アクセスの制限の適用が免除されているSink−IDであるかどうかをチェックする(ステップS2307)。そして、当該コンテンツのメタデータにSink−IDが存在する場合には(ステップS2307のYes)、Sourceデバイスは、ステップS2305で参照したコンテンツ情報を提供可能なコンテンツ情報に追加してから(ステップS2309)、ステップS2304に戻る。
他方、Sink−IDがコンテンツ・グループ並びにコンテンツのいずれのメタデータにも存在しない場合、すなわち、有効期限によるリモート・アクセスの制限の適用が免除されていない場合には(ステップS2306、S2307のNo)、Sourceデバイスは、ステップS2303で取得した現在日時が要求元のSinkデバイスの有効期限を過ぎていないかどうかをチェックする(ステップS2308)。
ここで、現在日時がまだ有効期限を過ぎていなければ(ステップS2308のYes)、Sourceデバイスは、ステップS2305で参照したコンテンツ情報を提供可能なコンテンツ情報に追加してから(ステップS2309)、ステップS2304に戻る。
一方、現在日時が有効期限を過ぎている場合には(ステップS2308のNo)、ステップS2305で参照したコンテンツ情報を提供可能なコンテンツ情報に追加することなく、ステップS2304に戻る。
そして、すべてのコンテンツ情報を処理し終えると(ステップS2304のYes)、Sourceデバイスは、完成したコンテンツ情報を、要求元のSinkデバイスに送信する(ステップS2310)。
また、図21には、限界日時に基づくリモート・アクセスの制限の適用を免除する端末が登録されている場合の、コンテンツ出力管理処理の手順をフローチャートの形式で示している。以下では、便宜上、Sourceデバイスとしてのサーバー201内で、例えばコンテンツ提供部304がコンテンツ出力管理処理を行なうものとして説明する。
サーバー201は、コンテンツ要求(HTTP GET request)に含まれる交換鍵ラベルKR_labelを参照し(ステップS2101)、同じ交換鍵ラベルKR_labelのRAC recordが端末管理部307内に存在するかどうかをチェックする(ステップS2102)。
同じ交換鍵ラベルKR_labelのRAC recordが存在しない場合には(ステップS2102のNo)、サーバー201は、後続の処理をすべてスキップして、本処理ルーチンを終了する。
一方、同じ交換鍵ラベルKR_labelのRAC recordが存在する場合には(ステップS2102のYes)、サーバー201は、そのRA recordから、交換鍵ラベルKR_labelに対応するSink−IDを取得する(ステップS2103)。
次いで、サーバー201は、要求されているコンテンツを含むコンテンツ・グループのメタデータに、このSink−IDが存在するかどうか、すなわち、当該コンテンツ・グループに対する限界日時によるリモート・アクセスの制限の適用が免除されているSink−IDであるかどうかをチェックする(ステップS2104)。そして、当該コンテンツ・グループのメタデータにSink−IDが存在する場合には(ステップS2104のYes)、サーバー201は、Sinkデバイスからのコンテンツ要求を許可し、要求されたコンテンツの送信を例えばHTTP GET responseで行なう(ステップS2109)。
また、サーバー201は、要求されているコンテンツのメタデータに、このSink−IDが存在するかどうか、すなわち、当該コンテンツに対する限界日時によるリモート・アクセスの制限の適用が免除されているSink−IDであるかどうかをチェックする(ステップS2105)。そして、当該コンテンツのメタデータにSink−IDが存在する場合には(ステップS2105のYes)、サーバー201は、Sinkデバイスからのコンテンツ要求を許可し、要求されたコンテンツの送信を例えばHTTP GET responseで行なう(ステップS2109)。
他方、Sink−IDがコンテンツ・グループ並びにコンテンツのいずれのメタデータにも存在しない場合、すなわち、限界日時によるリモート・アクセスの制限の適用が免除されていない場合には(ステップS2105、S2104のNo)、端末管理部307内のremote sink registryから、Sink−IDとペアにして記憶されている限界日時を取得する(ステップS2106)。
また、サーバー201は、要求されているコンテンツがコンテンツ記録部302に記録された記録日時を、ファイル・システムから取得する(ステップS2107)。但し、要求されているコンテンツが、放送コンテンツなどコンテンツ取得部304で取得するコンテンツの場合には、その取得日時として現在日時(受信日時)を取得する。
そして、サーバー201は、コンテンツ要求されているコンテンツの記録日時又は取得日時が、Sinkデバイスに設定されている限界日時を超えていないかどうかをチェックする(ステップS2108)。
コンテンツの記録日時又は取得日時がSinkデバイスの限界日時を超えていないときには(ステップS2108のYes)、サーバー201は、Sinkデバイスからのコンテンツ要求を許可し、次ステップS2109で、要求されたコンテンツの送信を例えばHTTP GET responseで行なう。
また、コンテンツの記録日時又は取得日時がSinkデバイスの限界日時を超えているときには(ステップS2108のNo)、サーバー201は、Sinkデバイスからのコンテンツ要求を許可せず、後続の処理をスキップして、本処理ルーチンを終了する。
なお、限界日時に基づくリモート・アクセスの制限の適用免除を、コンテンツ・リスト閲覧フェーズ(SEQ801)で行なうこともできる。
図25には、コンテンツ・リスト閲覧フェーズ(SEQ801)において、Sourceデバイスが、リモート・アクセスするSinkデバイスに対して、Sinkデバイスの限界日時に基づくCDS情報の提供制限を免除するための処理手順をフローチャートの形式で示している。
まず、Sourceデバイスは、提供可能なコンテンツ情報をクリアする(ステップS2501)。次いで、Sourceデバイスは、要求元のSinkデバイスのSink−IDに対応する限界日時を、remote sink registryから取得するとともに(ステップS2502)。
そして、Sourceデバイスは、すべてのコンテンツ情報を処理するまで(ステップS2503のNo)、コンテンツ情報の作成を行なう。
Sourceデバイスは、未処理のコンテンツのコンテンツ情報を参照すると(ステップS2504)、そのコンテンツを含むコンテンツ・グループのメタデータに、要求元のSink−IDが存在するかどうか、すなわち、当該コンテンツ・グループに対する限界日時によるリモート・アクセスの制限の適用が免除されているSink−IDであるかどうかをチェックする(ステップS2505)。そして、当該コンテンツ・グループのメタデータにSink−IDが存在する場合には(ステップS2505のYes)、Sourceデバイスは、ステップS2504で参照したコンテンツ情報を提供可能なコンテンツ情報に追加してから(ステップS2509)、ステップS2503に戻る。
また、Sourceデバイスは、そのコンテンツのメタデータに、要求元のSink−IDが存在するかどうか、すなわち、当該コンテンツに対する限界日時によるリモート・アクセスの制限の適用が免除されているSink−IDであるかどうかをチェックする(ステップS2506)。そして、当該コンテンツのメタデータにSink−IDが存在する場合には(ステップS2506のYes)、Sourceデバイスは、ステップS2504で参照したコンテンツ情報を提供可能なコンテンツ情報に追加してから(ステップS2509)、ステップS2503に戻る。
他方、Sink−IDがコンテンツ・グループ並びにコンテンツのいずれのメタデータにも存在しない場合、すなわち、限界日時によるリモート・アクセスの制限の適用が免除されていない場合には(ステップS2505、S2506のNo)、Sourceデバイスは、ステップS2504で参照したコンテンツ情報が限界日時を超えていないかどうかをチェックする。
限界日時のチェックのために、Sourceデバイスは、そのコンテンツがコンテンツ記録部302に記録された記録日時を、ファイル・システムから取得する(ステップS2507)。但し、要求されているコンテンツが、放送コンテンツなどコンテンツ取得部304で取得するコンテンツの場合には、その取得日時として現在日時(受信日時)を取得する。そして、Sourceデバイスは、そのコンテンツの記録日時又は取得日時が、Sinkデバイスに設定されている限界日時を超えていないかどうかをチェックする(ステップS2508)。
そのコンテンツの記録日時又は取得日時がSinkデバイスの限界日時を超えていないときには(ステップS2508のYes)、Sourceデバイスは、このコンテンツ情報を提供可能なコンテンツ情報に追加してから(ステップS2509)、ステップS2503に戻る。
一方、そのコンテンツの記録日時又は取得日時がSinkデバイスの限界日時を超えているときには(ステップS2508のNo)、Sourceデバイスは、このコンテンツ情報を提供可能なコンテンツ情報に追加することなく、ステップS2503に戻る。
そして、すべてのコンテンツ情報を処理し終えると(ステップS2503のYes)、Sourceデバイスは、完成したコンテンツ情報を、要求元のSinkデバイスに送信する(ステップS2510)。
図20、図21、並びに、図23、図25に示したように、特定の端末に特定してリモート・アクセスの制限を免除するのではなく、コンテンツ毎に、又は、コンテンツのグループ毎に、サーバーへの登録日時に基づくリモート・アクセスの制限を免除する端末を設定することにより、例えば家族のメンバー毎の複数の端末による私的利用の範囲内でのコンテンツの利用の利便性を確保することができる。