映像配信システム
【目的】二重視聴防止を実現すると共に、視聴制御サーバや暗号鍵配信サーバ等のサーバの負荷が大きく増大せしめることのない映像配信システムを提供する。
【構成】複数の視聴端末に暗号化がなされた映像コンテンツを配信する少なくとも１つの映像配信サーバと、該視聴端末に該暗号化に対応する暗号鍵を配信する複数の暗号鍵配信サーバとを含む映像配信システムであり、該視聴端末の１からの視聴要求に応じて該複数の暗号鍵配信サーバの何れか１を割当暗号鍵配信サーバとして該視聴端末の１に割り当てる。該暗号鍵配信サーバの各々は、自身が該割当暗号鍵配信サーバとして割り当てられた場合に該視聴端末の１に向けた暗号鍵の配信を開始すると共に該視聴端末の１を指定する配信停止リクエストを自身以外の他の暗号鍵配信サーバに供給する。自身に該配信終了リクエストが供給された場合には、該視聴端末の１に向けた暗号鍵の配信を停止する。
【構成】複数の視聴端末に暗号化がなされた映像コンテンツを配信する少なくとも１つの映像配信サーバと、該視聴端末に該暗号化に対応する暗号鍵を配信する複数の暗号鍵配信サーバとを含む映像配信システムであり、該視聴端末の１からの視聴要求に応じて該複数の暗号鍵配信サーバの何れか１を割当暗号鍵配信サーバとして該視聴端末の１に割り当てる。該暗号鍵配信サーバの各々は、自身が該割当暗号鍵配信サーバとして割り当てられた場合に該視聴端末の１に向けた暗号鍵の配信を開始すると共に該視聴端末の１を指定する配信停止リクエストを自身以外の他の暗号鍵配信サーバに供給する。自身に該配信終了リクエストが供給された場合には、該視聴端末の１に向けた暗号鍵の配信を停止する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネット等の映像配信ネットワークを介して映像コンテンツを配信する映像配信システムに関する。
【背景技術】
【０００２】
映像配信システムの運用においては映像コンテンツに対する著作権保護や無断視聴防止等のセキュリティ対策が求められる。特許文献１には、秒単位で変更される暗号鍵を用いて映像コンテンツのデータを暗号化してマルチキャスト配信する暗号化方法が開示されている。映像配信システムにおいては、通常、映像配信コンテンツを配信する映像配信サーバとは別に、多数のユーザに暗号鍵を配信する暗号鍵配信サーバが設けられる。さらに、視聴ユーザ数が１０万単位に及ぶ大規模な映像配信システムにおいては、複数の暗号鍵配信サーバが設けられ、各暗号鍵配信サーバの負荷を分散することが行われる。
【０００３】
ところで、複数の暗号鍵配信サーバを備える映像配信システムにおいては二重視聴を防ぐ仕組みが複雑化するという問題がある。二重視聴は、１つの視聴ライセンスしかないユーザが複数の暗号鍵配信サーバの各々に視聴要求を行い、各々から暗号鍵の提供を受けて複数の視聴端末で映像コンテンツを再生することである。かかる二重視聴を防ぐには、各ユーザにその時点で暗号鍵を配信している暗号鍵配信サーバを常に把握し、当該ユーザに他の暗号鍵配信サーバが暗号鍵を配信することのないようにする制御を行う視聴制御サーバ等の装置を設ける必要がある。
【特許文献１】特開２００３−１７４４４１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、かかる複雑な制御を行う視聴制御サーバを設けることは、各ユーザに関するユーザ情報を視聴制御サーバ及び複数の暗号鍵配信サーバで共有することが必要となる点でデータ管理上冗長であるのみならず、ユーザ情報が更新される度に視聴制御サーバや暗号鍵配信サーバ間でユーザ情報の転送を行う必要があり、視聴制御サーバや暗号鍵配信サーバの負荷が大きく増大し、本来の配信機能の性能低下を招くという問題がある。
【０００５】
本発明の目的は、二重視聴防止を実現すると共に、視聴制御サーバや暗号鍵配信サーバ等のサーバの負荷が大きく増大せしめることのない映像配信システムを提供することでる。
【課題を解決するための手段】
【０００６】
本発明による映像配信システムは、複数の視聴端末に暗号化がなされた映像コンテンツを配信する少なくとも１つの映像配信サーバと、該視聴端末に該暗号化に対応する暗号鍵を配信する複数の暗号鍵配信サーバとを含む映像配信システムであり、該視聴端末の１からの視聴要求に応じて該複数の暗号鍵配信サーバの何れか１を割当暗号鍵配信サーバとして該視聴端末の１に割り当てる暗号鍵配信サーバ割当手段を含み、該暗号鍵配信サーバの各々は、自身が該割当暗号鍵配信サーバとして割り当てられた場合に、該視聴端末の１に向けた暗号鍵の配信を開始すると共に、該視聴端末の１を指定する配信停止リクエストを、自身以外の他の暗号鍵配信サーバに供給する配信停止要求手段と、自身に該配信終了リクエストが供給された場合には、該視聴端末の１に向けた暗号鍵の配信を停止する暗号鍵配信停止手段と、を含むことを特徴とする。
【発明の効果】
【０００７】
本発明による映像配信システムによれば、二重視聴防止を実現すると共に、視聴制御サーバや暗号鍵配信サーバ等のサーバの負荷が大きく増大せしめることがない。
【発明を実施するための最良の形態】
【０００８】
本発明の実施例について添付の図面を参照しつつ詳細に説明する。
【０００９】
図１は、本発明の実施例を示し、映像配信システムを含む全体の構成を示している。映像配信システム１００は、インターネット等の映像配信ネットワーク９０を介して複数の視聴端末１０ａ〜１０ｃの各々に映画等の映像コンテンツをマルチキャスト配信するシステムである。視聴端末１０ａ〜１０ｃの各々は、ユーザが使用する装置であり、ＳＴＢ（Set Top Box）等に接続されたテレビジョン等の映像再生装置である。本図では、説明の容易性から３つの視聴端末１０ａ〜１０ｃのみが示されているが、本発明はそれ以上１０万台規模の視聴端末を想定している。
【００１０】
尚、本実施例において、映像コンテンツは、ＴＥＫ（Traffic Encryption Key）と呼ばれる暗号鍵を用いて映像配信サーバ６０により暗号化されて配信される。このＴＥＫと呼ばれる暗号鍵は、ＫＥＫ（Key Encryption Key）と呼ばれる暗号鍵を用いて暗号鍵配信サーバ５０ａ〜５０ｃの各々により暗号化されて各視聴端末１０ａ〜１０ｃの各々に配信される。
【００１１】
映像配信システム１００は、少なくとも１つの視聴制御サーバ３０と、少なくとも１つの負荷分散サーバ４０と、複数の暗号鍵配信サーバ５０ａ〜５０ｃと、少なくとも１つの映像配信サーバ６０とを含む。本図では、説明の容易性から３つの暗号鍵配信サーバ５０ａ〜５０ｃのみが示されているが、本発明は４台以上の暗号鍵配信サーバを含んでも良い。
【００１２】
視聴制御サーバ３０は、ユーザからの視聴要求に応じて当該ユーザの認証を行い、当該ユーザに関するユーザ情報の作成を要求するキャシュイン要求のメッセージを負荷分散サーバ４０に供給するサーバである。視聴制御サーバ３０は、通常のユーザ認証を行ってキャシュイン要求を暗号鍵配信サーバに転送するサーバてあり、従来の既存システムにおいて用いられる構成がそのまま用いられ得る。視聴端末１０ａ〜１０ｃの各々と視聴制御サーバ３０との間のデータ通信には映像配信ネットワーク９０を介した通常のＷｅｂ配信を可能とするＨＴＴＰプロトコルが用いられる
負荷分散サーバ４０は、視聴制御サーバ３０から供給されるキャシュイン要求に応じて、多数の視聴端末１０ａ〜１０ｃに対して各々の予想負荷量に基づく負荷バランス（Load Balance）、例えば、適切にトラヒックが各暗号鍵配信サーバ５０ａ〜５０ｃに亘って分散されるように暗号鍵配信サーバ５０ａ〜５０ｃの何れか１つを当該視聴端末に割り当て、割り当てられた割当暗号鍵配信サーバに該キャシュイン要求を転送するサーバである。かかる形態は、負荷分散サーバ４０を視聴制御サーバ３０とは別に設ける形態であり、従来からの既存のシステムに容易に負荷分散機能を提供することができる。
【００１３】
複数の暗号鍵配信サーバ５０ａ〜５０ｃの各々は、転送されたキャシュイン要求に応じて、当該要求に対応するユーザの視聴端末、例えば、視聴端末１０ａに向けて映像コンテンツを復号するための暗号鍵を、ＴＣＰプロトコルを用いて映像配信ネットワーク９０を介して配信するサーバである。映像配信サーバ６０は、マルチキャスト方式によるＩＰ放送配信のためにＲＴＰプロトコルを用いて映像配信ネットワーク９０を介して複数の視聴端末１０ａ〜１０ｃに向けて映像コンテンツを配信するサーバである。
【００１４】
図２は、図１に示された暗号鍵配信サーバの構成を示している。ここでは、図１に示された暗号鍵配信サーバ５０ａ〜５０ｃの各々を代表して、共通の構成を備える１つの暗号鍵配信サーバ５０が示されている。暗号鍵配信サーバ５０は、通信制御部５１と、暗号鍵生成部５２と、暗号鍵配信部５３と、ユーザ情報管理部５４と、暗号鍵データベース５８と、ユーザ情報データベース５９とを含む。
【００１５】
通信制御部５１は、ローカルネットワーク２０を介したデータ通信を実現すると共に、映像配信ネットワーク９０を介した暗号鍵配信を含むデータ通信を実現する機能を備える。負荷分散サーバ４０及び鍵配信サーバ５０ａ〜５０ｃとの間で行われるキャシュイン要求等のメッセージ通信や視聴端末１０ａ〜１０ｂに向けた暗号鍵配信にはＴＣＰプロトコルが用いられる。
【００１６】
暗号鍵生成部５２は、複数のチャネル毎の映像コンテンツの各々に対応する暗号鍵を時間経過に従って順次生成及び更新し、暗号鍵データベース５８に格納する機能を備える。暗号鍵の生成アルゴリズムは、例えば、ＤＥＳ（Data Encryption Standard）等の手法が用いられる。暗号鍵配信部５３は、暗号鍵データベース５８に格納された暗号鍵を、自身に割り当てられたユーザの視聴端末に向けて通信制御部５１を介して配信する機能を備える。暗号鍵の配信タイミングは、例えば、３０〜１時間毎である。
【００１７】
ユーザ情報管理部５４は、通信制御部５１を介して供給されるキャシュイン要求に応じてユーザ情報を生成し、これをユーザ情報データベース５９に格納して保持する機能を備える。ユーザ情報管理部５４は、また、他の暗号鍵配信サーバからの配信停止リクエストであるユーザ情報削除要求に応じて、削除指定されたユーザに対応するユーザ情報をユーザ情報データベース５９から削除する機能を備える。この場合、削除されるユーザ情報は、以前のキャシュイン要求に応じて生成され格納されたユーザ情報である。従って、もし当該削除指定されたユーザに対応するユーザ情報が無い場合にはかかる削除は行われない。
【００１８】
図３は、図１に示されたユーザ情報データベースの構成例を示している。ここで、ユーザ情報データベース５９は、映像コンテンツの配信を受ける複数のユーザ毎に、ユーザ情報片５９１〜５９ｎ（ｎは正数）を含む。ユーザ情報片５９１〜５９ｎの各々は、ユーザＩＤと、視聴可能チャンネル情報と、チャンネルアドレスと、視聴可能期限と、チケットと、視聴チャンネルと、ＫＥＫ（Key Encryption Key）とからなる。
【００１９】
ユーザＩＤはユーザを識別するＩＤである。視聴可能チャンネル情報は視聴が許可されているマルチキャスト映像であり複数保持される。チャンネルアドレスはマルチキャスト配信先アドレスである。視聴可能期限は視聴可能な日時である。チケットは視聴端末と鍵配信サーバの通信をするためのチケットであり視聴要求毎に更新される。視聴チャンネルはその時点で視聴端末が視聴しているチャンネルアドレスである。ＫＥＫは鍵配信サーバから視聴端末へマルチキャスト映像を復号化する為の暗号鍵（ＴＥＫ）を配信する時に使用する暗号鍵である。
【００２０】
図４は、図１に示された暗号鍵データベースの構成例を示している。ここで、暗号鍵データベース５８は、複数の暗号鍵配列５８１〜５８ｍ（ｍは正数）からなる。暗号鍵配列５８１〜５８ｍの各々は、チャネル番号に対応して例えば４つの暗号鍵（ＴＥＫ）１〜４が格納され、例えば３０分から１時間毎に更新される。暗号鍵１〜４の各々は例えばＤＥＳ等の暗号生成アルゴリズムにより生成される。１台の暗号鍵配信サーバが、１０万人に及ぶユーザに向けて鍵長３２バイトの４つの暗号鍵を配信するとすると、３２バイト×４×１０万に及ぶ暗号鍵のデータを３０分〜１時間毎に配信する必要がある。
【００２１】
図５は、本発明による映像配信システムにおける処理手順を示している。ここで、該処理手順は、視聴端末１０と、視聴制御サーバ３０と、負荷分散サーバ４０と、３つの暗号鍵配信サーバ５０ａ〜５０ｃと、映像配信サーバ６０とが協働して動作することで実行される。
【００２２】
先ず、視聴端末１０は、視聴制御サーバ３０に向けてユーザＩＤ及びパスワードを送信して視聴要求を行う（ステップＳ１）。該視聴要求に応じて、視聴制御サーバ３０はユーザ認証を行う（ステップＳ２）。次いで、視聴制御サーバ３０は、認証ＯＫの場合に、負荷分散サーバ４０に向けて、当該ユーザに関するユーザＩＤと、視聴可能チャネル情報と、視聴可能期限とを含むキャシュイン要求を行う（ステップＳ３）。該キャシュイン要求に応じて、負荷分散サーバ４０は、３つの暗号鍵配信サーバ５０ａ〜５０ｃのうちの何れか１つ、ここでは例として暗号鍵配信サーバ５０ａを割り当てる（ステップＳ４）。次いで、割り当てた暗号鍵配信サーバ５０ａに向けて該キャシュイン要求を転送する（ステップＳ５）。
【００２３】
転送されたキャシュイン要求に応じて、暗号鍵配信サーバ５０ａは、該キャシュイン要求を基にしてユーザ情報を生成し、これをユーザ情報データベースに格納して保持する（ステップＳ６）。当該ユーザについて既にユーザ情報がユーザ情報データベースに格納されている場合には、新たに生成されたユーザ情報で置き換える。すなわち、キャシュイン要求は、後発のキャシュイン要求が有効となる。ユーザ情報は、ユーザＩＤに対応付けて生成され、チャンネルアドレス、マルチキャスト配信先アドレス、チケット、視聴チャンネル及びＫＥＫ（Key Encryption Key）等の情報を含む。
【００２４】
次に、暗号鍵配信サーバ５０ａは、視聴制御サーバ３０に向けて、生成したチケットを含むキャシュイン応答を送信する（ステップＳ７）。視聴制御サーバ３０は、受信したチケットと共に暗号鍵配信サーバ５０ａのアドレスとを含む視聴応答を視聴端末１０に返信する（ステップＳ８）。キャッシュイン応答及び視聴応答は、後述するユーザ情報削除に関わる処理に先立って行われることから、視聴端末１０にとってのレスポンス時間に遅延は生じない。
【００２５】
視聴端末１０は、送信されたチケット及び暗号鍵配信サーバ５０ａのアドレスの受信に応じて、暗号鍵配信サーバ５０ａのアドレスに対して、チケットを提示して映像コンテンツ復号用の暗号鍵を要求することができる。暗号鍵配信サーバ５０ａは、映像コンテンツを復号するための暗号鍵（ＴＥＫ）を配信を開始する（ステップＳ１３）。
【００２６】
一方、暗号鍵配信サーバ５０ａは、暗号鍵配信サーバ５０ｂに向けて、当該ユーザに関するユーザ情報削除要求を送信する（ステップＳ９）。該ユーザ情報削除要求に応じて、暗号鍵配信サーバ５０ｂは、該ユーザＩＤのユーザ情報を自身のユーザ情報データベースから削除する（ステップＳ１０）。また、暗号鍵配信サーバ５０ａは、暗号鍵配信サーバ５０ｃに向けて、当該ユーザに対応するユーザＩＤを含むユーザ情報削除要求を送信する（ステップＳ１１）。該ユーザ情報削除要求に応じて、暗号鍵配信サーバ５０ｃは、該ユーザＩＤのユーザ情報を自身のユーザ情報データベースから削除する（ステップＳ１２）。これにより、視聴端末１０が、割り当てられた暗号鍵配信サーバ５０ａ以外、すなわち、暗号鍵配信サーバ５０ｂまたは５０ｃに対して暗号鍵配信を要求したとしても、該ユーザＩＤのユーザ情報が無い（不保持）ことから鍵配信を停止し２重配信を行うことがない。また、ユーザ情報削除要求は、視聴端末に対するキャシュイン応答後に行われるため、視聴端末への応答遅延が生じることはない。
【００２７】
視聴端末１０は、映像配信サーバ６０からマルチキャスト放映される映像コンテンツを受信しつつ、暗号鍵配信サーバ５０ａから配信された暗号鍵を用いてこれを復号化しつつ再生する（ステップＳ１４）。
【００２８】
図６は、暗号鍵配信サーバ間でユーザ情報削除要求を行うことによって発生する負荷増加の解析結果を示している。本発明を実施した場合、ユーザからの視聴要求に応じて生成されるべきユーザ情報を当該ユーザに割り当てられた暗号鍵配信サーバのみが保持すれば足りる利点を有するものの、一方でキャッシュイン時のユーザ情報削除要求の通信が増加する点が不利となる。そこで以下、暗号鍵配信サーバの負荷増加率を推測することとする。
【００２９】
負荷増加率を推測するためのシミュレーションを、各暗号鍵配信サーバ等のサーバ群をワークステーションとし視聴端末をパーソナルコンピュータとする構成に暗号鍵配信サーバの動作をシミュレートするソフトウェアを実装することにより行った。シミュレーション条件としては、１人のユーザが１チャンネルの視聴内容を３０分間視聴するものと想定している。また、暗号鍵配信サーバの台数は３台としている。
【００３０】
図６に示されるシミュレーション結果において、全ての要求に要する時間を総計すると、総計時間：0.011+0.519十0.012+0.011十0.006=0.559[sec]の結果が得られる。
【００３１】
一方、本発明を実施した場合、キャッシュイン要求に応じた１つの暗号鍵配信サーバは、他の２台の暗号化鍵配信サーバにユーザ情報削除要求を行う必要がある。ユーザ情報削除要求に要する時間が視聴終了要求と処理的にはほぼ同じであることから、視聴終了要求に要する時間が他の２台の暗号化鍵配信サーバ分だけ余計にかかることになる。すなわち、本発明における総計時間：0.006×(3-1)+0.011+0.519+0.012+0.011+0.006=0.571［sec]と推測される。従って、従来と本発明との負荷比：0.571/0.559×100＝102[%]の解析結果が得られる。
【００３２】
以上の解析結果において、本発明を実施した場合の負荷増加率は２％となる。この結果は単純な最短視聴シーケンスにおける結果であり、実際にはチャンネル設定とＴＥＫ要求が繰り返される運用になることやユーザ情報削除要求はキャッシュイン要求時のみ行われることを考慮すると、負荷増加率はもっと小さく２％以下になるものと推測される。
【００３３】
以上の実施例において、ユーザからの視聴要求に応じて生成されるべきユーザ情報を当該ユーザに割り当てられた暗号鍵配信サーバのみが保持し、同一ユーザに対する二重視聴を制限する形態が示された。また、ユーザ数を１０万単位とする大規模な映像配信システムにおいて、ユーザ情報を冗長して保持することは大量の容量を確保する必要があり不利であるが、本実施例においては、割り当てられた暗号鍵配信サーバのみにユーザ情報を保持することでかかる不利を僅かの負荷増加だけで回避している。また、本発明は、暗号鍵配信サーバ若しくは視聴制御サーバおいて障害が発生した場合におけるユーザ情報の整合性回復の仕組みや手順を簡略化できる利点がある。
【図面の簡単な説明】
【００３４】
【図１】本発明の実施例を示し、映像配信システムを含む全体の構成を示すブロック図である。
【図２】図１に示した暗号鍵配信サーバの構成を示すブロック図である。
【図３】図１に示したユーザ情報データベースの構成例を示す図である。
【図４】図１に示した暗号鍵データベースの構成例を示す図である。
【図５】本発明による映像配信システムにおける処理手順を示すシーケンス図である。
【図６】暗号鍵配信サーバ間でユーザ情報削除要求を行うことによって発生する負荷増加の解析結果を示す図である。
【符号の説明】
【００３５】
１０、１０ａ〜１０ｃ 視聴端末
２０ ローカルネットワーク
３０ 視聴制御サーバ
４０ 負荷分散サーバ
５０、５０ａ〜５０ｃ 暗号鍵配信サーバ
５１ 通信制御部
５２ 暗号鍵生成部
５３ 暗号鍵配信部
５４ ユーザ情報管理部
５８ 暗号鍵データベース
５９ ユーザ情報データベース
６０ 映像配信サーバ
９０ 映像配信ネットワーク
１００ 映像配信システム
５８１〜５８ｍ 暗号鍵配列
５９１〜５９ｎ ユーザ情報片
【技術分野】
【０００１】
本発明は、インターネット等の映像配信ネットワークを介して映像コンテンツを配信する映像配信システムに関する。
【背景技術】
【０００２】
映像配信システムの運用においては映像コンテンツに対する著作権保護や無断視聴防止等のセキュリティ対策が求められる。特許文献１には、秒単位で変更される暗号鍵を用いて映像コンテンツのデータを暗号化してマルチキャスト配信する暗号化方法が開示されている。映像配信システムにおいては、通常、映像配信コンテンツを配信する映像配信サーバとは別に、多数のユーザに暗号鍵を配信する暗号鍵配信サーバが設けられる。さらに、視聴ユーザ数が１０万単位に及ぶ大規模な映像配信システムにおいては、複数の暗号鍵配信サーバが設けられ、各暗号鍵配信サーバの負荷を分散することが行われる。
【０００３】
ところで、複数の暗号鍵配信サーバを備える映像配信システムにおいては二重視聴を防ぐ仕組みが複雑化するという問題がある。二重視聴は、１つの視聴ライセンスしかないユーザが複数の暗号鍵配信サーバの各々に視聴要求を行い、各々から暗号鍵の提供を受けて複数の視聴端末で映像コンテンツを再生することである。かかる二重視聴を防ぐには、各ユーザにその時点で暗号鍵を配信している暗号鍵配信サーバを常に把握し、当該ユーザに他の暗号鍵配信サーバが暗号鍵を配信することのないようにする制御を行う視聴制御サーバ等の装置を設ける必要がある。
【特許文献１】特開２００３−１７４４４１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、かかる複雑な制御を行う視聴制御サーバを設けることは、各ユーザに関するユーザ情報を視聴制御サーバ及び複数の暗号鍵配信サーバで共有することが必要となる点でデータ管理上冗長であるのみならず、ユーザ情報が更新される度に視聴制御サーバや暗号鍵配信サーバ間でユーザ情報の転送を行う必要があり、視聴制御サーバや暗号鍵配信サーバの負荷が大きく増大し、本来の配信機能の性能低下を招くという問題がある。
【０００５】
本発明の目的は、二重視聴防止を実現すると共に、視聴制御サーバや暗号鍵配信サーバ等のサーバの負荷が大きく増大せしめることのない映像配信システムを提供することでる。
【課題を解決するための手段】
【０００６】
本発明による映像配信システムは、複数の視聴端末に暗号化がなされた映像コンテンツを配信する少なくとも１つの映像配信サーバと、該視聴端末に該暗号化に対応する暗号鍵を配信する複数の暗号鍵配信サーバとを含む映像配信システムであり、該視聴端末の１からの視聴要求に応じて該複数の暗号鍵配信サーバの何れか１を割当暗号鍵配信サーバとして該視聴端末の１に割り当てる暗号鍵配信サーバ割当手段を含み、該暗号鍵配信サーバの各々は、自身が該割当暗号鍵配信サーバとして割り当てられた場合に、該視聴端末の１に向けた暗号鍵の配信を開始すると共に、該視聴端末の１を指定する配信停止リクエストを、自身以外の他の暗号鍵配信サーバに供給する配信停止要求手段と、自身に該配信終了リクエストが供給された場合には、該視聴端末の１に向けた暗号鍵の配信を停止する暗号鍵配信停止手段と、を含むことを特徴とする。
【発明の効果】
【０００７】
本発明による映像配信システムによれば、二重視聴防止を実現すると共に、視聴制御サーバや暗号鍵配信サーバ等のサーバの負荷が大きく増大せしめることがない。
【発明を実施するための最良の形態】
【０００８】
本発明の実施例について添付の図面を参照しつつ詳細に説明する。
【０００９】
図１は、本発明の実施例を示し、映像配信システムを含む全体の構成を示している。映像配信システム１００は、インターネット等の映像配信ネットワーク９０を介して複数の視聴端末１０ａ〜１０ｃの各々に映画等の映像コンテンツをマルチキャスト配信するシステムである。視聴端末１０ａ〜１０ｃの各々は、ユーザが使用する装置であり、ＳＴＢ（Set Top Box）等に接続されたテレビジョン等の映像再生装置である。本図では、説明の容易性から３つの視聴端末１０ａ〜１０ｃのみが示されているが、本発明はそれ以上１０万台規模の視聴端末を想定している。
【００１０】
尚、本実施例において、映像コンテンツは、ＴＥＫ（Traffic Encryption Key）と呼ばれる暗号鍵を用いて映像配信サーバ６０により暗号化されて配信される。このＴＥＫと呼ばれる暗号鍵は、ＫＥＫ（Key Encryption Key）と呼ばれる暗号鍵を用いて暗号鍵配信サーバ５０ａ〜５０ｃの各々により暗号化されて各視聴端末１０ａ〜１０ｃの各々に配信される。
【００１１】
映像配信システム１００は、少なくとも１つの視聴制御サーバ３０と、少なくとも１つの負荷分散サーバ４０と、複数の暗号鍵配信サーバ５０ａ〜５０ｃと、少なくとも１つの映像配信サーバ６０とを含む。本図では、説明の容易性から３つの暗号鍵配信サーバ５０ａ〜５０ｃのみが示されているが、本発明は４台以上の暗号鍵配信サーバを含んでも良い。
【００１２】
視聴制御サーバ３０は、ユーザからの視聴要求に応じて当該ユーザの認証を行い、当該ユーザに関するユーザ情報の作成を要求するキャシュイン要求のメッセージを負荷分散サーバ４０に供給するサーバである。視聴制御サーバ３０は、通常のユーザ認証を行ってキャシュイン要求を暗号鍵配信サーバに転送するサーバてあり、従来の既存システムにおいて用いられる構成がそのまま用いられ得る。視聴端末１０ａ〜１０ｃの各々と視聴制御サーバ３０との間のデータ通信には映像配信ネットワーク９０を介した通常のＷｅｂ配信を可能とするＨＴＴＰプロトコルが用いられる
負荷分散サーバ４０は、視聴制御サーバ３０から供給されるキャシュイン要求に応じて、多数の視聴端末１０ａ〜１０ｃに対して各々の予想負荷量に基づく負荷バランス（Load Balance）、例えば、適切にトラヒックが各暗号鍵配信サーバ５０ａ〜５０ｃに亘って分散されるように暗号鍵配信サーバ５０ａ〜５０ｃの何れか１つを当該視聴端末に割り当て、割り当てられた割当暗号鍵配信サーバに該キャシュイン要求を転送するサーバである。かかる形態は、負荷分散サーバ４０を視聴制御サーバ３０とは別に設ける形態であり、従来からの既存のシステムに容易に負荷分散機能を提供することができる。
【００１３】
複数の暗号鍵配信サーバ５０ａ〜５０ｃの各々は、転送されたキャシュイン要求に応じて、当該要求に対応するユーザの視聴端末、例えば、視聴端末１０ａに向けて映像コンテンツを復号するための暗号鍵を、ＴＣＰプロトコルを用いて映像配信ネットワーク９０を介して配信するサーバである。映像配信サーバ６０は、マルチキャスト方式によるＩＰ放送配信のためにＲＴＰプロトコルを用いて映像配信ネットワーク９０を介して複数の視聴端末１０ａ〜１０ｃに向けて映像コンテンツを配信するサーバである。
【００１４】
図２は、図１に示された暗号鍵配信サーバの構成を示している。ここでは、図１に示された暗号鍵配信サーバ５０ａ〜５０ｃの各々を代表して、共通の構成を備える１つの暗号鍵配信サーバ５０が示されている。暗号鍵配信サーバ５０は、通信制御部５１と、暗号鍵生成部５２と、暗号鍵配信部５３と、ユーザ情報管理部５４と、暗号鍵データベース５８と、ユーザ情報データベース５９とを含む。
【００１５】
通信制御部５１は、ローカルネットワーク２０を介したデータ通信を実現すると共に、映像配信ネットワーク９０を介した暗号鍵配信を含むデータ通信を実現する機能を備える。負荷分散サーバ４０及び鍵配信サーバ５０ａ〜５０ｃとの間で行われるキャシュイン要求等のメッセージ通信や視聴端末１０ａ〜１０ｂに向けた暗号鍵配信にはＴＣＰプロトコルが用いられる。
【００１６】
暗号鍵生成部５２は、複数のチャネル毎の映像コンテンツの各々に対応する暗号鍵を時間経過に従って順次生成及び更新し、暗号鍵データベース５８に格納する機能を備える。暗号鍵の生成アルゴリズムは、例えば、ＤＥＳ（Data Encryption Standard）等の手法が用いられる。暗号鍵配信部５３は、暗号鍵データベース５８に格納された暗号鍵を、自身に割り当てられたユーザの視聴端末に向けて通信制御部５１を介して配信する機能を備える。暗号鍵の配信タイミングは、例えば、３０〜１時間毎である。
【００１７】
ユーザ情報管理部５４は、通信制御部５１を介して供給されるキャシュイン要求に応じてユーザ情報を生成し、これをユーザ情報データベース５９に格納して保持する機能を備える。ユーザ情報管理部５４は、また、他の暗号鍵配信サーバからの配信停止リクエストであるユーザ情報削除要求に応じて、削除指定されたユーザに対応するユーザ情報をユーザ情報データベース５９から削除する機能を備える。この場合、削除されるユーザ情報は、以前のキャシュイン要求に応じて生成され格納されたユーザ情報である。従って、もし当該削除指定されたユーザに対応するユーザ情報が無い場合にはかかる削除は行われない。
【００１８】
図３は、図１に示されたユーザ情報データベースの構成例を示している。ここで、ユーザ情報データベース５９は、映像コンテンツの配信を受ける複数のユーザ毎に、ユーザ情報片５９１〜５９ｎ（ｎは正数）を含む。ユーザ情報片５９１〜５９ｎの各々は、ユーザＩＤと、視聴可能チャンネル情報と、チャンネルアドレスと、視聴可能期限と、チケットと、視聴チャンネルと、ＫＥＫ（Key Encryption Key）とからなる。
【００１９】
ユーザＩＤはユーザを識別するＩＤである。視聴可能チャンネル情報は視聴が許可されているマルチキャスト映像であり複数保持される。チャンネルアドレスはマルチキャスト配信先アドレスである。視聴可能期限は視聴可能な日時である。チケットは視聴端末と鍵配信サーバの通信をするためのチケットであり視聴要求毎に更新される。視聴チャンネルはその時点で視聴端末が視聴しているチャンネルアドレスである。ＫＥＫは鍵配信サーバから視聴端末へマルチキャスト映像を復号化する為の暗号鍵（ＴＥＫ）を配信する時に使用する暗号鍵である。
【００２０】
図４は、図１に示された暗号鍵データベースの構成例を示している。ここで、暗号鍵データベース５８は、複数の暗号鍵配列５８１〜５８ｍ（ｍは正数）からなる。暗号鍵配列５８１〜５８ｍの各々は、チャネル番号に対応して例えば４つの暗号鍵（ＴＥＫ）１〜４が格納され、例えば３０分から１時間毎に更新される。暗号鍵１〜４の各々は例えばＤＥＳ等の暗号生成アルゴリズムにより生成される。１台の暗号鍵配信サーバが、１０万人に及ぶユーザに向けて鍵長３２バイトの４つの暗号鍵を配信するとすると、３２バイト×４×１０万に及ぶ暗号鍵のデータを３０分〜１時間毎に配信する必要がある。
【００２１】
図５は、本発明による映像配信システムにおける処理手順を示している。ここで、該処理手順は、視聴端末１０と、視聴制御サーバ３０と、負荷分散サーバ４０と、３つの暗号鍵配信サーバ５０ａ〜５０ｃと、映像配信サーバ６０とが協働して動作することで実行される。
【００２２】
先ず、視聴端末１０は、視聴制御サーバ３０に向けてユーザＩＤ及びパスワードを送信して視聴要求を行う（ステップＳ１）。該視聴要求に応じて、視聴制御サーバ３０はユーザ認証を行う（ステップＳ２）。次いで、視聴制御サーバ３０は、認証ＯＫの場合に、負荷分散サーバ４０に向けて、当該ユーザに関するユーザＩＤと、視聴可能チャネル情報と、視聴可能期限とを含むキャシュイン要求を行う（ステップＳ３）。該キャシュイン要求に応じて、負荷分散サーバ４０は、３つの暗号鍵配信サーバ５０ａ〜５０ｃのうちの何れか１つ、ここでは例として暗号鍵配信サーバ５０ａを割り当てる（ステップＳ４）。次いで、割り当てた暗号鍵配信サーバ５０ａに向けて該キャシュイン要求を転送する（ステップＳ５）。
【００２３】
転送されたキャシュイン要求に応じて、暗号鍵配信サーバ５０ａは、該キャシュイン要求を基にしてユーザ情報を生成し、これをユーザ情報データベースに格納して保持する（ステップＳ６）。当該ユーザについて既にユーザ情報がユーザ情報データベースに格納されている場合には、新たに生成されたユーザ情報で置き換える。すなわち、キャシュイン要求は、後発のキャシュイン要求が有効となる。ユーザ情報は、ユーザＩＤに対応付けて生成され、チャンネルアドレス、マルチキャスト配信先アドレス、チケット、視聴チャンネル及びＫＥＫ（Key Encryption Key）等の情報を含む。
【００２４】
次に、暗号鍵配信サーバ５０ａは、視聴制御サーバ３０に向けて、生成したチケットを含むキャシュイン応答を送信する（ステップＳ７）。視聴制御サーバ３０は、受信したチケットと共に暗号鍵配信サーバ５０ａのアドレスとを含む視聴応答を視聴端末１０に返信する（ステップＳ８）。キャッシュイン応答及び視聴応答は、後述するユーザ情報削除に関わる処理に先立って行われることから、視聴端末１０にとってのレスポンス時間に遅延は生じない。
【００２５】
視聴端末１０は、送信されたチケット及び暗号鍵配信サーバ５０ａのアドレスの受信に応じて、暗号鍵配信サーバ５０ａのアドレスに対して、チケットを提示して映像コンテンツ復号用の暗号鍵を要求することができる。暗号鍵配信サーバ５０ａは、映像コンテンツを復号するための暗号鍵（ＴＥＫ）を配信を開始する（ステップＳ１３）。
【００２６】
一方、暗号鍵配信サーバ５０ａは、暗号鍵配信サーバ５０ｂに向けて、当該ユーザに関するユーザ情報削除要求を送信する（ステップＳ９）。該ユーザ情報削除要求に応じて、暗号鍵配信サーバ５０ｂは、該ユーザＩＤのユーザ情報を自身のユーザ情報データベースから削除する（ステップＳ１０）。また、暗号鍵配信サーバ５０ａは、暗号鍵配信サーバ５０ｃに向けて、当該ユーザに対応するユーザＩＤを含むユーザ情報削除要求を送信する（ステップＳ１１）。該ユーザ情報削除要求に応じて、暗号鍵配信サーバ５０ｃは、該ユーザＩＤのユーザ情報を自身のユーザ情報データベースから削除する（ステップＳ１２）。これにより、視聴端末１０が、割り当てられた暗号鍵配信サーバ５０ａ以外、すなわち、暗号鍵配信サーバ５０ｂまたは５０ｃに対して暗号鍵配信を要求したとしても、該ユーザＩＤのユーザ情報が無い（不保持）ことから鍵配信を停止し２重配信を行うことがない。また、ユーザ情報削除要求は、視聴端末に対するキャシュイン応答後に行われるため、視聴端末への応答遅延が生じることはない。
【００２７】
視聴端末１０は、映像配信サーバ６０からマルチキャスト放映される映像コンテンツを受信しつつ、暗号鍵配信サーバ５０ａから配信された暗号鍵を用いてこれを復号化しつつ再生する（ステップＳ１４）。
【００２８】
図６は、暗号鍵配信サーバ間でユーザ情報削除要求を行うことによって発生する負荷増加の解析結果を示している。本発明を実施した場合、ユーザからの視聴要求に応じて生成されるべきユーザ情報を当該ユーザに割り当てられた暗号鍵配信サーバのみが保持すれば足りる利点を有するものの、一方でキャッシュイン時のユーザ情報削除要求の通信が増加する点が不利となる。そこで以下、暗号鍵配信サーバの負荷増加率を推測することとする。
【００２９】
負荷増加率を推測するためのシミュレーションを、各暗号鍵配信サーバ等のサーバ群をワークステーションとし視聴端末をパーソナルコンピュータとする構成に暗号鍵配信サーバの動作をシミュレートするソフトウェアを実装することにより行った。シミュレーション条件としては、１人のユーザが１チャンネルの視聴内容を３０分間視聴するものと想定している。また、暗号鍵配信サーバの台数は３台としている。
【００３０】
図６に示されるシミュレーション結果において、全ての要求に要する時間を総計すると、総計時間：0.011+0.519十0.012+0.011十0.006=0.559[sec]の結果が得られる。
【００３１】
一方、本発明を実施した場合、キャッシュイン要求に応じた１つの暗号鍵配信サーバは、他の２台の暗号化鍵配信サーバにユーザ情報削除要求を行う必要がある。ユーザ情報削除要求に要する時間が視聴終了要求と処理的にはほぼ同じであることから、視聴終了要求に要する時間が他の２台の暗号化鍵配信サーバ分だけ余計にかかることになる。すなわち、本発明における総計時間：0.006×(3-1)+0.011+0.519+0.012+0.011+0.006=0.571［sec]と推測される。従って、従来と本発明との負荷比：0.571/0.559×100＝102[%]の解析結果が得られる。
【００３２】
以上の解析結果において、本発明を実施した場合の負荷増加率は２％となる。この結果は単純な最短視聴シーケンスにおける結果であり、実際にはチャンネル設定とＴＥＫ要求が繰り返される運用になることやユーザ情報削除要求はキャッシュイン要求時のみ行われることを考慮すると、負荷増加率はもっと小さく２％以下になるものと推測される。
【００３３】
以上の実施例において、ユーザからの視聴要求に応じて生成されるべきユーザ情報を当該ユーザに割り当てられた暗号鍵配信サーバのみが保持し、同一ユーザに対する二重視聴を制限する形態が示された。また、ユーザ数を１０万単位とする大規模な映像配信システムにおいて、ユーザ情報を冗長して保持することは大量の容量を確保する必要があり不利であるが、本実施例においては、割り当てられた暗号鍵配信サーバのみにユーザ情報を保持することでかかる不利を僅かの負荷増加だけで回避している。また、本発明は、暗号鍵配信サーバ若しくは視聴制御サーバおいて障害が発生した場合におけるユーザ情報の整合性回復の仕組みや手順を簡略化できる利点がある。
【図面の簡単な説明】
【００３４】
【図１】本発明の実施例を示し、映像配信システムを含む全体の構成を示すブロック図である。
【図２】図１に示した暗号鍵配信サーバの構成を示すブロック図である。
【図３】図１に示したユーザ情報データベースの構成例を示す図である。
【図４】図１に示した暗号鍵データベースの構成例を示す図である。
【図５】本発明による映像配信システムにおける処理手順を示すシーケンス図である。
【図６】暗号鍵配信サーバ間でユーザ情報削除要求を行うことによって発生する負荷増加の解析結果を示す図である。
【符号の説明】
【００３５】
１０、１０ａ〜１０ｃ 視聴端末
２０ ローカルネットワーク
３０ 視聴制御サーバ
４０ 負荷分散サーバ
５０、５０ａ〜５０ｃ 暗号鍵配信サーバ
５１ 通信制御部
５２ 暗号鍵生成部
５３ 暗号鍵配信部
５４ ユーザ情報管理部
５８ 暗号鍵データベース
５９ ユーザ情報データベース
６０ 映像配信サーバ
９０ 映像配信ネットワーク
１００ 映像配信システム
５８１〜５８ｍ 暗号鍵配列
５９１〜５９ｎ ユーザ情報片
【特許請求の範囲】
【請求項１】
複数の視聴端末に暗号化がなされた映像コンテンツを配信する少なくとも１つの映像配信サーバと、前記視聴端末に前記暗号化に対応する暗号鍵を配信する複数の暗号鍵配信サーバと、を含む映像配信システムであって、
前記視聴端末の１からの視聴要求に応じて前記複数の暗号鍵配信サーバの何れか１を割当暗号鍵配信サーバとして前記視聴端末の１に割り当てる暗号鍵配信サーバ割当手段を含み、
前記暗号鍵配信サーバの各々は、
自身が前記割当暗号鍵配信サーバとして割り当てられた場合に、前記視聴端末の１に向けた暗号鍵の配信を開始すると共に、前記視聴端末の１を指定する配信停止リクエストを、自身以外の他の暗号鍵配信サーバに供給する配信停止リクエスト供給手段と、
自身に前記配信終了リクエストが供給された場合には、前記視聴端末の１に向けた暗号鍵の配信を停止する暗号鍵配信停止手段と、
を含むことを特徴とする映像配信システム。
【請求項２】
前記配信停止リクエスト供給手段は、前記視聴端末の１に対応するユーザ情報片を新たに生成して保持し、生成したユーザ情報片の内容に基づいて前記暗号鍵の配信を開始し、
前記暗号鍵配信停止手段は、前記ユーザ情報片を自身が保持している場合にこれを削除し、前記ユーザ情報片の不保持に基づいて、前記視聴端末の１に向けた暗号鍵の配信を停止することを特徴とする請求項１記載の映像配信システム。
【請求項３】
前記暗号鍵配信サーバ割当手段は、前記複数の暗号鍵配信サーバの各々の予想負荷量に基づいて前記暗号鍵配信サーバの１を決定し、これを前記割当暗号鍵配信サーバとして前記視聴端末の１に割り当てることを特徴とする請求項１記載の映像配信システム。
【請求項１】
複数の視聴端末に暗号化がなされた映像コンテンツを配信する少なくとも１つの映像配信サーバと、前記視聴端末に前記暗号化に対応する暗号鍵を配信する複数の暗号鍵配信サーバと、を含む映像配信システムであって、
前記視聴端末の１からの視聴要求に応じて前記複数の暗号鍵配信サーバの何れか１を割当暗号鍵配信サーバとして前記視聴端末の１に割り当てる暗号鍵配信サーバ割当手段を含み、
前記暗号鍵配信サーバの各々は、
自身が前記割当暗号鍵配信サーバとして割り当てられた場合に、前記視聴端末の１に向けた暗号鍵の配信を開始すると共に、前記視聴端末の１を指定する配信停止リクエストを、自身以外の他の暗号鍵配信サーバに供給する配信停止リクエスト供給手段と、
自身に前記配信終了リクエストが供給された場合には、前記視聴端末の１に向けた暗号鍵の配信を停止する暗号鍵配信停止手段と、
を含むことを特徴とする映像配信システム。
【請求項２】
前記配信停止リクエスト供給手段は、前記視聴端末の１に対応するユーザ情報片を新たに生成して保持し、生成したユーザ情報片の内容に基づいて前記暗号鍵の配信を開始し、
前記暗号鍵配信停止手段は、前記ユーザ情報片を自身が保持している場合にこれを削除し、前記ユーザ情報片の不保持に基づいて、前記視聴端末の１に向けた暗号鍵の配信を停止することを特徴とする請求項１記載の映像配信システム。
【請求項３】
前記暗号鍵配信サーバ割当手段は、前記複数の暗号鍵配信サーバの各々の予想負荷量に基づいて前記暗号鍵配信サーバの１を決定し、これを前記割当暗号鍵配信サーバとして前記視聴端末の１に割り当てることを特徴とする請求項１記載の映像配信システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２００８−１３１５５３（Ｐ２００８−１３１５５３Ａ）
【公開日】平成２０年６月５日（２００８．６．５）
【国際特許分類】
【出願番号】特願２００６−３１６８７３（Ｐ２００６−３１６８７３）
【出願日】平成１８年１１月２４日（２００６．１１．２４）
【出願人】（００００００２９５）沖電気工業株式会社 (6,645)
【Ｆターム（参考）】
【公開日】平成２０年６月５日（２００８．６．５）
【国際特許分類】
【出願日】平成１８年１１月２４日（２００６．１１．２４）
【出願人】（００００００２９５）沖電気工業株式会社 (6,645)
【Ｆターム（参考）】
[ Back to top ]