JP6327296B2 - 通信装置及び通信方法、並びにコンピューター・プログラム - Google Patents

通信装置及び通信方法、並びにコンピューター・プログラム Download PDF

Info

Publication number
JP6327296B2
JP6327296B2 JP2016129002A JP2016129002A JP6327296B2 JP 6327296 B2 JP6327296 B2 JP 6327296B2 JP 2016129002 A JP2016129002 A JP 2016129002A JP 2016129002 A JP2016129002 A JP 2016129002A JP 6327296 B2 JP6327296 B2 JP 6327296B2
Authority
JP
Japan
Prior art keywords
content
terminal
unit
sink
date
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2016129002A
Other languages
English (en)
Other versions
JP2016225993A (ja
Inventor
中野 雄彦
雄彦 中野
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP2016129002A priority Critical patent/JP6327296B2/ja
Publication of JP2016225993A publication Critical patent/JP2016225993A/ja
Application granted granted Critical
Publication of JP6327296B2 publication Critical patent/JP6327296B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Description

本明細書で開示する技術は、例えばDTCPなどの所定の相互認証及び鍵交換(AKE)アルゴリズムに従って共有した鍵を用いてコンテンツを暗号化伝送する通信装置及び通信方法、並びにコンピューター・プログラムに係り、特に、私的利用の範囲を超えた利用を抑制しながら、家庭内で蓄積したコンテンツを外部ネットワーク経由で伝送する通信装置及び通信方法、並びにコンピューター・プログラムに関する。
ディジタル化されたコンテンツはコピーや改竄などの不正な操作が比較的容易である。とりわけ、リモート・アクセスにおいては、個人的又は家庭的なコンテンツの使用を許容しながら、コンテンツ伝送に介在する不正利用の防止、すなわち著作権保護の仕組みが必要である。ディジタル・コンテンツの伝送保護に関する業界標準的な技術として、DTLA(Digital Transmission Licensing Administrator)が開発したDTCP(Digital Transmission Content Protection)が挙げられる。
DTCPでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決められている。その規定は、要約すれば、DTCP準拠機器は取り扱いが容易な圧縮コンテンツを非暗号の状態で機器外に送出しないことと、暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換(Authentication and Key Exchange:AKE)アルゴリズムに従って行なうこと、並びにAKEコマンドにより鍵交換を行なう機器の範囲を制限することなどである。
DTCPは、原初的には、IEEE1394などを伝送路に用いたホーム・ネットワーク上におけるコンテンツ伝送について規定したものである。最近では、DLNA(Digital Living Network Alliance)に代表されるように、家庭内でもディジタル・コンテンツをIPネットワーク経由で流通させようという動きが本格的になっている。そこで、DTCP技術をIPネットワークに移植した、DTCP−IP(DTCP mapping to IP)の開発が進められている。
例えば、ホーム・サーバーに蓄積された放送コンテンツや映画などの商用コンテンツを、外出先から遠隔利用する場合、私的利用の範囲を超えて利用されることを適切な制御によって防止することが望まれている。
現在のDTCP−IP(DTCP−IP Volume 1 Specification Revision 1.4)では、第三者によるコンテンツの利用を制限することを意図して、家庭内のサーバーへのリモート・アクセスを、そのサーバーに登録した端末だけに限定している。また、端末を家庭内のサーバーに登録する際において、コマンドの往復遅延時間(RTT:Round Trip Time)を最大7ミリ秒に制限するとともに、IPルーターのホップ回数の上限が課されている。
例えば、リモート・アクセス時におけるAKE手続きにおいて、上記のRTT並びにTTLの制限を解除してリモート・アクセス用の鍵共有を可能にする一方、リモート・アクセスする端末のサーバーへの事前登録、コンテンツのリモート・アクセス利用数制限、鍵供給数制限を課して、不特定多数のユーザーからのリモート・アクセスを制限するようにした通信システムについて、提案がなされている(例えば、特許文献1を参照のこと)。
しかしながら、現在のDTCP−IP規格によると、端末の家庭内のサーバーへの登録は一度だけ行なえば、以後は再び登録を行なわずに、リモート・アクセスによりサーバー内のコンテンツを利用し続けることができる。このため、第三者の端末をサーバーに一度登録すれば、以後はその第三者がサーバー内のコンテンツを利用し続けることができてしまうという問題がある。
特開2011−82952号公報
本明細書で開示する技術の目的は、DTCPなどの所定の相互認証及び鍵交換アルゴリズムに従って、家庭内で蓄積したコンテンツを外部ネットワーク経由で伝送する際に、私的利用の範囲を超えた利用を好適に抑制することができる、優れた通信装置及び通信方法、並びにコンピューター・プログラムを提供することにある。
本願は、上記課題を参酌してなされたものであり、請求項1に記載の技術は、
放送コンテンツを選局受信する受信部と、
コンテンツを提供する端末を登録する端末登録部と、
端末の登録日時に基づく制限下で、前記受信部で受信したコンテンツの端末への提供を制御するコンテンツ提供部と、
を具備する通信装置である。
本願の請求項2に記載の技術によれば、請求項1に記載の通信装置の前記受信部は、所望する放送チャンネルの全セグメント又は一部のセグメントを受信するように構成されている。
本願の請求項3に記載の技術によれば、請求項1に記載の通信装置の前記受信部は、番組検索、番組情報の表示、又は番組予約のうち少なくとも1つの機能を備えている。
本願の請求項4に記載の技術によれば、請求項1に記載の通信装置は、コンテンツを記録するコンテンツ記録部、又は、コンテンツ記録装置を外部接続する接続部と、記録又は外部出力するコンテンツをコピー制御するコピー制御部をさらに備えている。
本願の請求項5に記載の技術によれば、請求項1に記載の通信装置は、前記受信部で放送コンテンツを限定受信し、又は、受信した放送コンテンツを暗号化して外部出力するコンテンツ保護部をさらに備えている。
本願の請求項6に記載の技術によれば、請求項1に記載の通信装置は、所定の相互認証及び鍵交換手続きに従って端末を認証するとともに交換鍵を共有する認証及び鍵共有部をさらに備えている。そして、前記コンテンツ提供部は、前記交換鍵を用いて暗号化したコンテンツを端末に提供するように構成されている。
本願の請求項7に記載の技術によれば、請求項6に記載の通信装置の前前記認証及び鍵共有部は、DTCP−IPが規定する認証及び鍵交換(AKE)アルゴリズムに従って、端末と相互認証並びに交換鍵の共有を行ない、前記端末登録部は、DTCP−IPが規定する手続きに従って端末の登録を行なうように構成されている。
本願の請求項8に記載の技術によれば、請求項1に記載の通信装置は、端末に提供可能なコンテンツに関する情報を端末に提供するコンテンツ情報提供部をさらに備えている。そして、前記コンテンツ提供部は、端末側で閲覧しているコンテンツ情報を介して選択されたコンテンツを提供するように構成されている。
本願の請求項9に記載の技術によれば、請求項1に記載の通信装置の前記端末登録部は、ホーム・ネットワーク内で端末を登録し、前記コンテンツ提供部は、外部ネットワークからアクセスした登録後の端末にコンテンツを提供するように構成されている。
本願の請求項10に記載の技術によれば、請求項1に記載の通信装置の前記端末登録部は、端末の登録日時に第2の所定期間を加算した限界日時を端末の情報とともに管理し、前記コンテンツ提供部は、前記受信部が限界日時以降に受信したコンテンツの端末への提供を制限するように構成されている。
本願の請求項11に記載の技術によれば、請求項1に記載の通信装置の前記コンテンツ提供部は、前記端末登録部に登録される所定台数の端末については、登録日時に基づく制限を免除して、コンテンツを提供するように構成されている。
本願の請求項12に記載の技術によれば、請求項1に記載の通信装置は、コンテンツ毎又はコンテンツ・グループ毎に、登録日時に基づく制限を免除する端末を設定するようになっている。そして、前記コンテンツ提供部は、提供するコンテンツ又はコンテンツが含まれるコンテンツ・グループについて登録日時に基づく制限が免除された端末に対して、登録日時に拘わらずコンテンツを提供するように構成されている。
本願の請求項13に記載の技術によれば、請求項10の記載の通信装置は、コンテンツ毎又はコンテンツ・グループ毎に、限界日時に基づく制限を免除する端末を設定するようになっている。そして、前記コンテンツ提供部は、提供するコンテンツを含むコンテンツ・グループ又は提供するコンテンツについて前記免除が設定された端末に対しては、前記受信部が限界日時以降に受信したコンテンツであってもコンテンツを提供するように構成されている。
本願の請求項14に記載の技術によれば、請求項8に記載の通信装置の前記コンテンツ情報提供部は、端末の登録日時に基づいて端末へのコンテンツ情報の提供を制御するように構成されている。
本願の請求項15に記載の技術によれば、請求項14に記載の通信装置の前記端末登録部は、端末の登録日時に第2の所定期間を加算した限界日時を端末の情報とともに管理し、前記コンテンツ情報提供部は、前記受信部が限界日時以降に受信するコンテンツについては端末へのコンテンツ情報の提供を制限するように構成されている。
本願の請求項16に記載の技術によれば、請求項14に記載の通信装置の前記コンテンツ情報提供部は、前記端末登録部に登録される所定台数の端末については、登録日時に基づく制限を免除して、コンテンツ情報を提供するように構成されている。
本願の請求項17に記載の技術によれば、請求項15に記載の通信装置は、コンテンツ毎又はコンテンツ・グループ毎に、限界日時に基づく制限を免除する端末を設定するようになっている。そして、前記コンテンツ情報提供部は、提供先の端末に対して前記免除が設定されたコンテンツ又はコンテンツ・グループについては、前記受信部が限界日時以降に受信するコンテンツのコンテンツ情報を提供するように構成されている。
また、本願の請求項18に記載の技術は、
コンテンツ毎又はコンテンツ・グループ毎に、限界日時に基づく制限を免除する端末を設定し、
前記コンテンツ情報提供部は、提供先の端末に対して前記免除が設定されたコンテンツ又はコンテンツ・グループについては、前記受信部が限界日時以降に受信するコンテンツのコンテンツ情報を提供するである。
また、本願の請求項19に記載の技術は、
放送コンテンツを選局受信する受信部、
コンテンツを提供する端末を登録する端末登録部、
端末の登録日時に基づいて、前記受信部で受信したコンテンツの端末への提供を制御するコンテンツ提供部、
としてコンピューターを機能させるようにコンピューター可読形式で記述されたコンピューター・プログラムである。
本願の請求項19に係るコンピューター・プログラムは、コンピューター上で所定の処理を実現するようにコンピューター可読形式で記述されたコンピューター・プログラムを定義したものである。換言すれば、本願の請求項19に係るコンピューター・プログラムをコンピューターにインストールすることによって、コンピューター上では協働的作用が発揮され、本願の請求項1に係る通信装置と同様の作用効果を得ることができる。
また、本願の請求項20に記載の技術は、
コンテンツを要求する端末と、
放送コンテンツを選局受信するとともに、コンテンツを提供する端末を登録し、受信したコンテンツの前記端末への提供をその登録日時に基づいて制御するサーバーと、
を具備する通信システムである。
但し、ここで言う「システム」とは、複数の装置(又は特定の機能を実現する機能モジュール)が論理的に集合した物のことを言い、各装置や機能モジュールが単一の筐体内にあるか否かは特に問わない。
本明細書で開示する技術によれば、DTCPなどの所定の相互認証及び鍵交換アルゴリズムに従って、家庭内で蓄積したコンテンツを外部ネットワーク経由で伝送する際に、私的利用の範囲を超えた利用を好適に抑制することができる、優れた通信装置及び通信方法、並びにコンピューター・プログラムを提供することができる。
本明細書で開示する技術によれば、端末から家庭内のサーバーへのリモート・アクセスを、端末のサーバーへの登録日時に基づいて制限することにより、一旦登録した第三者が利用し続けることを防止し、私的利用の範囲を超えたコンテンツの利用を好適に抑制することができる。
また、本明細書で開示する技術によれば、端末のサーバーへの登録日時から第1の所定の期間のみ、端末からサーバー内のコンテンツへのリモート・アクセスを可能にする、すなわち、登録日時から第1の所定の期間を経過した以降はリモート・アクセスを禁止することにより、第三者による私的利用の範囲を超えたコンテンツの利用を抑制することができる。
また、本明細書で開示する技術によれば、端末がリモート・アクセスにより利用可能なコンテンツを、端末のサーバーへの登録日時から第2の所定の期間以前に記録されたものだけに制限することにより、第三者による私的利用の範囲を超えたコンテンツの利用を好適に抑制することができる。
また、本明細書で開示する技術によれば、所定台数の端末までは、サーバーへの登録日時に基づくリモート・アクセスの制限を免除することにより、私的利用の範囲内でのコンテンツの利用の利便性を確保することができる。
また、本明細書で開示する技術によれば、コンテンツ毎に、又は、コンテンツのグループ毎に、サーバーへの登録日時に基づくリモート・アクセスの制限を免除する端末を設定することにより、例えば家族のメンバー毎の複数の端末による私的利用の範囲内でのコンテンツの利用の利便性を確保することができる。
本明細書で開示する技術のさらに他の目的、特徴や利点は、後述する実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
図1は、本明細書で開示する技術を適用した通信システム100の構成例を模式的に示した図である。 図2は、本明細書で開示する技術を適用した通信システム200の他の構成例を模式的に示した図である。 図3は、図1並びに図2において、サーバー101、201として動作する通信装置300の機能的構成を模式的に示した図である。 図4は、図1並びに図2において、端末102、202として動作する通信装置400の機能的構成を模式的に示した図である。 図5は、DTCP仕様書に記載されている、リモート・アクセスを行なうSinkをSourceに登録する手順を示した図である。 図6は、リモート・アクセスを行なうSinkデバイスを、有効期限とともにSourceデバイスに登録する手順を示した図である。 図7は、Sink−IDと有効期限をペアにしたremote sink registryの登録内容を例示した図である。 図8は、SourceデバイスとSinkデバイス間でリモート・アクセスによるコンテンツ伝送を行なう手順を模式的に示した図である。 図9は、コンテンツ・リスト閲覧フェーズ(SEQ801)の中身を模式的に示した図である。 図10は、DTCPの仕様書のV1SE.10.7.2節に記載されている、RA−AKE手続きフェーズの中身を示した図である。 図11は、有効期限が切れたSink−IDをremote sink resistryから抹消する処理を含んだ、RA−AKE手続きフェーズの中身を示した図である。 図12は、remote sink registryのメンテナンス処理の手順を示したフローチャートである。 図13は、リモート・アクセスを行なうSinkデバイスを、限界日時とともにSourceデバイスに登録する手順を示した図である。 図14は、Sink−IDと限界日時をペアにしたremote sink registryの登録内容を例示した図である。 図15は、リモート・アクセス用交換鍵KR及びその交換鍵ラベルKR_labelをSink−IDと対応付けてRAC recordとして記憶する様子を示した図である。 図16は、リモート・アクセス用交換鍵KRを用いて暗号化伝送するコンテンツ伝送フェーズ(SEQ803)の中身を模式的に示した図である。 図17は、SEQ1602において実施するコンテンツ出力管理処理の手順を示したフローチャートである。 図18は、有効期限に基づくコンテンツの出力管理を含んだコンテンツ伝送フェーズ(SEQ803)の中身を模式的に示した図である。 図19は、SEQ1802において実施するコンテンツ出力管理の処理手順を示したフローチャートである。 図20は、有効期限に基づくリモート・アクセスの制限の適用を免除する端末が登録されている場合の、コンテンツ出力管理の処理手順を示したフローチャートである。 図21は、限界日時に基づくリモート・アクセスの制限の適用を免除する端末が登録されている場合の、コンテンツ出力管理の処理手順を示したフローチャートである。 図22は、リモート・アクセスするSinkデバイスの有効期限に基づいてCDS情報の提供を制限するための処理手順を示したフローチャートである。 図23は、コンテンツ・リスト閲覧フェーズにおいてSinkデバイスの有効期限に基づくCDS情報の提供制限を免除するための処理手順を示したフローチャートである。 図24は、リモート・アクセスするSinkデバイスの限界日時に基づいてCDS情報の提供を制限するための処理手順を示したフローチャートである。 図25は、コンテンツ・リスト閲覧フェーズにおいてSinkデバイスの限界日時に基づくCDS情報の提供制限を免除するための処理手順を示したフローチャートである。 図26は、コンピューター・プログラム配信システム2600の構成を示した図である。
以下、図面を参照しながら本明細書で開示する技術の実施形態について詳細に説明する。
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に示したように、特定の端末に特定してリモート・アクセスの制限を免除するのではなく、コンテンツ毎に、又は、コンテンツのグループ毎に、サーバーへの登録日時に基づくリモート・アクセスの制限を免除する端末を設定することにより、例えば家族のメンバー毎の複数の端末による私的利用の範囲内でのコンテンツの利用の利便性を確保することができる。
以上、特定の実施形態を参照しながら、本明細書で開示する技術について詳細に説明してきた。しかしながら、本明細書で開示する技術の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
本明細書では、本明細書で開示する技術をIPネットワーク並びにDTCP仕様のネットワークに適用した実施形態を中心に説明してきたが、本明細書で開示する技術の要旨はこれに限定されるものではない。DTCP−IP以外の、ホーム・ネットワーク内のコンテンツへのリモート・アクセスに制限が課されるさまざまな通信システムにも、同様に本明細書で開示する技術で開示する技術を適用することができる。
また、本明細書で開示する技術の適用範囲は、ホーム・ネットワークへのリモート・アクセスに限定されない。ホーム・ネットワーク内でのローカル・アクセス時においても、ホーム・サーバーへの端末の登録日時に基づいてアクセスを制限したい場合に、同様に本明細書で開示する技術を適用することができる。
要するに、例示という形態により本明細書で開示する技術について説明してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本明細書で開示する技術の要旨を判断するためには、特許請求の範囲を参酌すべきである。
なお、本明細書の開示の技術は、以下のような構成をとることも可能である。
(1)放送コンテンツを選局受信する受信部と、
コンテンツを提供する端末を登録する端末登録部と、
端末の登録日時に基づく制限下で、前記受信部で受信したコンテンツの端末への提供を制御するコンテンツ提供部と、
を具備する通信装置。
(2)前記受信部は、所望する放送チャンネルの全セグメント又は一部のセグメントを受信する、
上記(1)に記載の通信装置。
(3)前記受信部は、番組検索、番組情報の表示、又は番組予約のうち少なくとも1つの機能を備える、
上記(1)に記載の通信装置。
(4)コンテンツを記録するコンテンツ記録部、又は、コンテンツ記録装置を外部接続する接続部と、
記録又は外部出力するコンテンツをコピー制御するコピー制御部と、
をさらに備える上記(1)に記載の通信装置。
(5)前記受信部で放送コンテンツを限定受信し、又は、受信した放送コンテンツを暗号化して外部出力するコンテンツ保護部をさらに備える、
上記(1)に記載の通信装置。
(6)所定の相互認証及び鍵交換手続きに従って端末を認証するとともに交換鍵を共有する認証及び鍵共有部をさらに備え、
前記コンテンツ提供部は、前記交換鍵を用いて暗号化したコンテンツを端末に提供する、
上記(1)に記載の通信装置。
(7)前記認証及び鍵共有部は、DTCP−IPが規定する認証及び鍵交換(AKE)アルゴリズムに従って、端末と相互認証並びに交換鍵の共有を行ない、
前記端末登録部は、DTCP−IPが規定する手続きに従って端末の登録を行なう、
上記(6)に記載の通信装置。
(8)端末に提供可能なコンテンツに関する情報を端末に提供するコンテンツ情報提供部をさらに備え、
前記コンテンツ提供部は、端末側で閲覧しているコンテンツ情報を介して選択されたコンテンツを提供する、
上記(1)に記載の通信装置。
(9)前記端末登録部は、ホーム・ネットワーク内で端末を登録し、
前記コンテンツ提供部は、外部ネットワークからアクセスした登録後の端末にコンテンツを提供する、
上記(1)に記載の通信装置。
(10)前記端末登録部は、端末の登録日時に第1の所定期間を加算した有効期限を端末の情報とともに管理し、
前記コンテンツ提供部は、有効期限を経過した端末へのコンテンツの提供を制限する、
上記(1)に記載の通信装置。
(11)前記端末登録部は、端末の登録日時に第2の所定期間を加算した限界日時を端末の情報とともに管理し、
前記コンテンツ提供部は、前記受信部が限界日時以降に受信したコンテンツの端末への提供を制限する、
上記(1)に記載の通信装置。
(12)前記コンテンツ提供部は、前記端末登録部に登録される所定台数の端末については、登録日時に基づく制限を免除して、コンテンツを提供する、
上記(1)に記載の通信装置。
(13)コンテンツ毎又はコンテンツ・グループ毎に、登録日時に基づく制限を免除する端末を設定し、
前記コンテンツ提供部は、提供するコンテンツ又はコンテンツが含まれるコンテンツ・グループについて登録日時に基づく制限が免除された端末に対して、登録日時に拘わらずコンテンツを提供する、
上記(1)に記載の通信装置。
(14)コンテンツ毎又はコンテンツ・グループ毎に、有効期限に基づく制限を免除する端末を設定し、
前記コンテンツ提供部は、提供するコンテンツを含むコンテンツ・グループ又は提供するコンテンツについて前記免除が設定された端末に対しては、有効期限に拘わらずコンテンツを提供する、
上記(10)に記載の通信装置。
(15)コンテンツ毎又はコンテンツ・グループ毎に、限界日時に基づく制限を免除する端末を設定し、
前記コンテンツ提供部は、提供するコンテンツを含むコンテンツ・グループ又は提供するコンテンツについて前記免除が設定された端末に対しては、前記受信部が限界日時以降に受信したコンテンツであってもコンテンツを提供する、
上記(11)に記載の通信装置。
(16)前記コンテンツ情報提供部は、端末の登録日時に基づいて端末へのコンテンツ情報の提供を制御する、
上記(8)に記載の通信装置。
(17)前記端末登録部は、端末の登録日時に第1の所定期間を加算した有効期限を端末の情報とともに管理し、
前記コンテンツ情報提供部は、有効期限を経過した端末へのコンテンツ情報の提供を制限する、
上記(16)に記載の通信装置。
(18)前記端末登録部は、端末の登録日時に第2の所定期間を加算した限界日時を端末の情報とともに管理し、
前記コンテンツ情報提供部は、前記受信部が限界日時以降に受信するコンテンツについては端末へのコンテンツ情報の提供を制限する、
上記(16)に記載の通信装置。
(19)前記コンテンツ情報提供部は、前記端末登録部に登録される所定台数の端末については、登録日時に基づく制限を免除して、コンテンツ情報を提供する、
上記(16)に記載の通信装置。
(20)コンテンツ毎又はコンテンツ・グループ毎に、登録日時に基づく制限を免除する端末を設定し、
前記コンテンツ情報提供部は、提供するコンテンツ又はコンテンツが含まれるコンテンツ・グループについて登録日時に基づく制限が免除された端末に対して、登録日時に拘わらずコンテンツ情報を提供する、
上記(16)に記載の通信装置。
(21)コンテンツ毎又はコンテンツ・グループ毎に、有効期限に基づく制限を免除する端末を設定し、
前記コンテンツ情報提供部は、有効期限が経過した端末であっても、当該端末に対して前記免除が設定されたコンテンツ・グループに含まれるコンテンツ、又は、前記免除が設定されたコンテンツのコンテンツ情報を提供する、
上記(17)に記載の通信装置。
(22)コンテンツ毎又はコンテンツ・グループ毎に、限界日時に基づく制限を免除する端末を設定し、
前記コンテンツ情報提供部は、提供先の端末に対して前記免除が設定されたコンテンツ又はコンテンツ・グループについては、前記受信部が限界日時以降に受信するコンテンツのコンテンツ情報を提供する、
上記(18)に記載の通信装置。
(23)放送コンテンツを選局受信する受信ステップと、
コンテンツを提供する端末を登録する端末登録ステップと、
端末の登録日時に基づく制限をかけながら、前記受信ステップで受信したコンテンツを端末に提供するコンテンツ提供ステップと、
を有する通信方法。
(24)放送コンテンツを選局受信する受信部、
コンテンツを提供する端末を登録する端末登録部、
端末の登録日時に基づいて、前記受信部で受信したコンテンツの端末への提供を制御するコンテンツ提供部、
としてコンピューターを機能させるようにコンピューター可読形式で記述されたコンピューター・プログラム。
(25)コンテンツを要求する端末と、
放送コンテンツを選局受信するとともに、コンテンツを提供する端末を登録し、受信したコンテンツの前記端末への提供をその登録日時に基づいて制御するサーバーと、
を具備する通信システム。
100…通信システム
101…サーバー、102…端末、110…ホーム・ネットワーク
201…サーバー、202…端末
200…通信システム
201…サーバー、202…端末
210…ホーム・ネットワーク、220…外部ネットワーク
230…ルーター
300…通信装置(Sourceデバイス)
301…通信・制御部、302…コンテンツ記録部
303…コンテンツ取得部、304…コンテンツ提供部
305…コンテンツ・リスト提供部、306…認証・鍵共有部
307…端末管理部
400…通信装置
401…通信・制御部
402…コンテンツ・リスト閲覧部、403…コンテンツ取得部
404…コンテンツ復号部、405…コンテンツ再生出力部
406…認証・鍵共有部、407…入力部

Claims (16)

  1. 放送コンテンツを選局受信する受信部と、
    コマンドの往復遅延時間の制限下で認証した端末を、リモート・アクセスによりコンテンツを提供する端末として登録する端末登録部と、
    コマンドの往復遅延時間の制限なしに、リモート・アクセスする端末を認証するとともにリモート・アクセス用の交換鍵を共有するリモート認証部と、
    前記受信部で受信したコンテンツの端末への提供を制御するコンテンツ提供部と、
    を具備し、
    前記端末登録部は、端末の登録日時に第1の所定期間を加算した有効期限を端末の情報とともに管理し、
    前記リモート認証部は、有効期限を経過したリモート・アクセスする端末へのリモート・アクセス用の交換鍵の共有を制限し、有効期限を経過していないリモート・アクセスする端末のうち所定台数までリモート・アクセス用の交換鍵を共有し、
    前記コンテンツ提供部は、リモート・アクセスする端末に対して、共有するリモート・アクセス用の交換鍵を用いてコンテンツを暗号化伝送する、
    通信装置。
  2. 前記受信部は、所望する放送チャンネルの全セグメント又は一部のセグメントを受信する、
    請求項1に記載の通信装置。
  3. 前記受信部は、番組検索、番組情報の表示、又は番組予約のうち少なくとも1つの機能を備える、
    請求項1に記載の通信装置。
  4. 前記受信部で受信したコンテンツを記録するコンテンツ記録部、又は、前記受信部で受信したコンテンツを記録するコンテンツ記録装置を外部接続する接続部をさらに備え、
    前記コンテンツ提供部は、前記コンテンツ記録部又は前記コンテンツ記録装置に記録されたコンテンツの有効期限を経過した端末への提供を制限する、
    請求項1に記載の通信装置。
  5. 前記受信部で放送コンテンツを限定受信し、又は、受信した放送コンテンツを暗号化して外部出力するコンテンツ保護部をさらに備える、
    請求項1に記載の通信装置。
  6. 所定の相互認証及び鍵交換手続きに従って端末を認証するとともに交換鍵を共有する認証及び鍵共有部をさらに備え、
    前記コンテンツ提供部は、前記交換鍵を用いて暗号化したコンテンツを端末に提供する、
    請求項1に記載の通信装置。
  7. 前記認証及び鍵共有部は、DTCP−IPが規定する認証及び鍵交換(AKE)アルゴリズムに従って、端末と相互認証並びに交換鍵の共有を行ない、
    前記端末登録部は、DTCP−IPが規定する手続きに従って端末の登録を行なう、
    請求項6に記載の通信装置。
  8. 端末に提供可能なコンテンツに関する情報を端末に提供するコンテンツ情報提供部をさらに備え、
    前記コンテンツ提供部は、端末側で閲覧しているコンテンツ情報を介して選択されたコンテンツを提供する、
    請求項1に記載の通信装置。
  9. 前記端末登録部は、ホーム・ネットワーク内で端末を登録し、
    前記コンテンツ提供部は、外部ネットワークからアクセスした登録後の端末にコンテンツを提供する、
    請求項1に記載の通信装置。
  10. 前記コンテンツ提供部は、前記端末登録部に登録される所定台数の端末については、登録日時に基づく制限を免除して、コンテンツを提供する、
    請求項1に記載の通信装置。
  11. コンテンツ毎又はコンテンツ・グループ毎に、有効期限に基づく制限を免除する端末を設定し、
    前記コンテンツ提供部は、提供するコンテンツを含むコンテンツ・グループ又は提供するコンテンツについて前記免除が設定された端末に対しては、有効期限に拘わらずコンテンツを提供する、
    請求項1に記載の通信装置。
  12. 前記コンテンツ情報提供部は、有効期限を経過した端末へのコンテンツ情報の提供を制限する、
    請求項8に記載の通信装置。
  13. 前記コンテンツ情報提供部は、前記端末登録部に登録される所定台数の端末については、有効期限に基づく制限を免除して、コンテンツ情報を提供する、
    請求項12に記載の通信装置。
  14. コンテンツ毎又はコンテンツ・グループ毎に、有効期限に基づく制限を免除する端末を設定し、
    前記コンテンツ情報提供部は、提供先の端末に対して前記免除が設定されたコンテンツ又はコンテンツ・グループについては、有効期限に拘わらずコンテンツ情報を提供する、
    請求項8に記載の通信装置。
  15. 通信装置が備える受信部が、放送コンテンツを選局受信する受信ステップと、
    前記通信装置が備える端末登録部が、コマンドの往復遅延時間の制限下で認証した端末を、リモート・アクセスによりコンテンツを提供する端末として登録する端末登録ステップと、
    前記通信装置が備えるリモート認証部が、コマンドの往復遅延時間の制限なしに、リモート・アクセスする端末を認証するとともにリモート・アクセス用の交換鍵を共有するリモート認証ステップと、
    前記通信装置が備えるコンテンツ提供部が、端末の登録日時に基づく制限をかけながら、前記受信ステップで受信したコンテンツを端末に提供するコンテンツ提供ステップと、
    を有し、
    前記端末登録ステップでは、端末の登録日時に第1の所定期間を加算した有効期限を端末の情報とともに管理し、
    前記リモート認証ステップでは、有効期限を経過したリモート・アクセスする端末へのリモート・アクセス用の交換鍵の共有を制限し、有効期限を経過していないリモート・アクセスする端末のうち所定台数までリモート・アクセス用の交換鍵を共有し、
    前記コンテンツ提供ステップでは、リモート・アクセスする端末に対して、共有するリモート・アクセス用の交換鍵を用いてコンテンツを暗号化伝送する、
    通信方法。
  16. 放送コンテンツを選局受信する受信部、
    コマンドの往復遅延時間の制限下で認証した端末を、リモート・アクセスによりコンテンツを提供する端末として登録する端末登録部、
    コマンドの往復遅延時間の制限なしに、リモート・アクセスする端末を認証するとともにリモート・アクセス用の交換鍵を共有するリモート認証部、
    端末の登録日時に基づいて、前記受信部で受信したコンテンツの端末への提供を制御するコンテンツ提供部、
    としてコンピューターを機能させるようにコンピューター可読形式で記述され、
    前記端末登録部は、端末の登録日時に第1の所定期間を加算した有効期限を端末の情報とともに管理し、
    前記リモート認証部は、有効期限を経過したリモート・アクセスする端末へのリモート・アクセス用の交換鍵の共有を制限し、有効期限を経過していないリモート・アクセスする端末のうち所定台数までリモート・アクセス用の交換鍵を共有し、
    前記コンテンツ提供部は、リモート・アクセスする端末に対して、共有するリモート・アクセス用の交換鍵を用いてコンテンツを暗号化伝送する、
    コンピューター・プログラム。
JP2016129002A 2016-06-29 2016-06-29 通信装置及び通信方法、並びにコンピューター・プログラム Active JP6327296B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2016129002A JP6327296B2 (ja) 2016-06-29 2016-06-29 通信装置及び通信方法、並びにコンピューター・プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2016129002A JP6327296B2 (ja) 2016-06-29 2016-06-29 通信装置及び通信方法、並びにコンピューター・プログラム

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2013047008A Division JP5962549B2 (ja) 2013-03-08 2013-03-08 通信装置及び通信方法、コンピューター・プログラム、並びに通信システム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2018059473A Division JP6465233B2 (ja) 2018-03-27 2018-03-27 通信システム

Publications (2)

Publication Number Publication Date
JP2016225993A JP2016225993A (ja) 2016-12-28
JP6327296B2 true JP6327296B2 (ja) 2018-05-23

Family

ID=57746075

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016129002A Active JP6327296B2 (ja) 2016-06-29 2016-06-29 通信装置及び通信方法、並びにコンピューター・プログラム

Country Status (1)

Country Link
JP (1) JP6327296B2 (ja)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4643068B2 (ja) * 2001-07-23 2011-03-02 株式会社東芝 コンテンツ配信システム
US9325933B2 (en) * 2006-10-06 2016-04-26 Panasonic Intellectual Property Management Co., Ltd. Data transmission apparatus, data reception apparatus, and data transmission and reception system
JP5439044B2 (ja) * 2009-06-09 2014-03-12 日立コンシューマエレクトロニクス株式会社 コンテンツ送信装置及びコンテンツ受信装置
JP2011082952A (ja) * 2009-09-09 2011-04-21 Sony Corp 通信システム、通信装置及び通信方法、並びにコンピューター・プログラム
JP2011146958A (ja) * 2010-01-15 2011-07-28 Panasonic Corp 放送送受信装置、番組メニュー表示・生成方法

Also Published As

Publication number Publication date
JP2016225993A (ja) 2016-12-28

Similar Documents

Publication Publication Date Title
TWI510066B (zh) 用於安全串流媒體內容之系統和方法
US9847975B2 (en) Method of provisioning persistent household keys for in-home media content distribution
CN102215218B (zh) 内容发送方法、内容发送装置及内容接收装置
US20080216177A1 (en) Contents Distribution System
US9330250B2 (en) Authorization of media content transfer between home media server and client device
JP6604395B2 (ja) 通信方法
KR20080044886A (ko) 콘텐츠 관리시스템 및 콘텐츠 관리장치
US20150149778A1 (en) Content reception apparatus and method, and content transmission apparatus and method
JP6465233B2 (ja) 通信システム
JP6607303B2 (ja) コンテンツ・リモート・アクセス制御装置
JP6471820B2 (ja) コンテンツ・リモート・アクセスシステム
JP6327296B2 (ja) 通信装置及び通信方法、並びにコンピューター・プログラム
JP6323514B2 (ja) コンテンツ・リモート・アクセス制御方法
JP6269754B2 (ja) コンピューター・プログラム配信システム並びにコンテンツ・リモート・アクセス制御装置
JP6269755B2 (ja) コンピューター・プログラム配信システム並びにコンテンツ・リモート・アクセス利用装置
JP5962549B2 (ja) 通信装置及び通信方法、コンピューター・プログラム、並びに通信システム
JP6036415B2 (ja) 通信装置、並びにコンピューター・プログラム配信システム
JP6221428B2 (ja) コンテンツ受信装置及びコンテンツ受信方法、並びにコンピューター・プログラム
JP6332280B2 (ja) コンテンツ送信装置及びコンテンツ送信方法、並びにコンピューター・プログラム
JP6187139B2 (ja) コンテンツ伝送システム
JP6221429B2 (ja) コンテンツ伝送システム
JP2015082681A (ja) コンテンツ受信装置及びコンテンツ受信方法、並びにコンピューター・プログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20160629

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170427

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170502

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170628

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20171121

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20171222

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180320

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180402

R151 Written notification of patent or utility model registration

Ref document number: 6327296

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250