JP6476995B2 - 中継装置、コンテンツ配信システム、中継方法およびプログラム - Google Patents

Description

本発明は、中継装置、コンテンツ配信システム、中継方法およびプログラムに関する。

従来、ＶＯＤ（Video On Demand）によるストリーミングは、ＲＴＰ（Real-time Transport Protocol）プロトコルをベースにしたものが主流で、クライアントとＶＯＤ側との間にストリーミング用のセッションを確保した上で配信を行っていた。ＶＯＤ側では、このセッションを通して配信制御を行い、また、各時点でのクライアント数の把握、それに基づいたクライアント数の制御を行っている。

ＶＯＤによるストリーミングに関する技術として、負荷分散の為に各クライアントに対しセッション識別用の仮想ＵＲＬを割り当て、管理サーバによりリダイレクトされたサーバからのサービスを受けるようにしたものが開発されている（特許文献１参照）。クライアントは、セッションの開始を管理サーバに通知する事で仮想ＵＲＬを割り当てられ、その後の要求は仮想ＵＲＬに基づきリダイレクトされる。クライアントのログオフ要求により仮想ＵＲＬを無効にするものである。

また、ＨＴＴＰ（HyperText Transfer Protocol）によるストリーミングについても知られている。ＨＴＴＰによるストリーミングでは、コンテンツを数秒単位のセグメントと呼ばれるファイルに分け、セグメントのＵＲＬ（Uniform Resource Locator）とデコードに必要な情報とを記載したマニフェストファイルを元にして、クライアントが必要なセグメントをＨＴＴＰプロトコルにより取得する。このＨＴＴＰによるストリーミングでは、ＶＯＤ側とクライアント間でセッションの管理をする必要がなく、既存のＷＥＢ（World Wide Web）サーバにセグメントとマニフェストファイルを配置するだけで、手軽にストリーミングを実現することが可能である。

特開２０００−３３０９５７号公報

しかしながら、特許文献１に記載された技術では、要求ごとにリダイレクションが発生するので、動画像のストリーミングでは好ましくない遅延が発生する可能性がある。

本発明は、前記問題に鑑みてなされたものであり、動画像のストリーミングにおける好ましくない遅延を抑制する、中継装置、コンテンツ配信システム、中継方法およびプログラムを提供するものである。

前記課題を解決するため、本発明に係る中継装置は、コンテンツ受信装置から送信されるコンテンツを時分割した時分割コンテンツの視聴要求をコンテンツ配信装置に転送し、前記コンテンツ配信装置から送信される時分割コンテンツを前記コンテンツ受信装置に転送する中継装置であって、前記時分割コンテンツに対応する第１ロケーション識別情報内に前記視聴要求を識別する視聴要求識別情報を含む情報である第２ロケーション識別情報を、前記コンテンツ受信装置から視聴要求として受信する第１受信処理部と、前記視聴要求識別情報を用いて前記視聴要求が所定の条件を満たすことを確認処理する第１確認処理部と、前記第１確認処理部における確認処理後に、前記第２ロケーション識別情報から視聴要求識別情報を削除した第１ロケーション識別情報を前記コンテンツ配信装置に送信する第１送信処理部と、を有し、前記視聴要求識別情報には当該視聴要求の有効期限を示す情報である期限情報が含まれており、前記第１確認処理部は、前記期限情報を参照して前記視聴要求が有効期限内であるか否かを判定することを特徴とする。
前記課題を解決するため、本発明に係るコンテンツ配信システムは、上記に記載される中継装置を有するコンテンツ配信システムであって、前記コンテンツ配信装置を有し、前記コンテンツ配信装置は、前記中継装置から、前記第１ロケーション識別情報を受信して、前記第１ロケーション識別情報に対応する前記時分割コンテンツを前記中継装置に対して送信することを特徴とする。
前記課題を解決するため、本発明に係る中継方法は、コンテンツ受信装置から送信されるコンテンツを時分割した時分割コンテンツの視聴要求をコンテンツ配信装置に転送し、前記コンテンツ配信装置から送信される時分割コンテンツを前記コンテンツ受信装置に転送する中継装置の中継方法であって、前記中継装置は、前記時分割コンテンツに対応する第１ロケーション識別情報内に前記視聴要求を識別する視聴要求識別情報を含む情報である第２ロケーション識別情報を、前記コンテンツ受信装置から視聴要求として受信する第１受信処理ステップと、前記視聴要求識別情報を用いて前記視聴要求が所定の条件を満たすことを確認処理する第１確認処理ステップと、前記第１確認処理ステップにおける確認処理後に、前記第２ロケーション識別情報から視聴要求識別情報を削除した第１ロケーション識別情報を前記コンテンツ配信装置に送信する第１送信処理ステップと、を有し、前記視聴要求識別情報には当該視聴要求の有効期限を示す情報である期限情報が含まれており、前記第１確認処理ステップでは、前記期限情報を参照して前記視聴要求が有効期限内であるか否かを判定することを特徴とする。
前記課題を解決するため、本発明に係るプログラムは、コンテンツ受信装置から送信されるコンテンツを時分割した時分割コンテンツの視聴要求をコンテンツ配信装置に転送し、前記コンテンツ配信装置から送信される時分割コンテンツを前記コンテンツ受信装置に転送するコンピュータを、前記時分割コンテンツに対応する第１ロケーション識別情報内に前記視聴要求を識別する視聴要求識別情報を含む情報である第２ロケーション識別情報を、前記コンテンツ受信装置から視聴要求として受信する第１受信処理部、前記視聴要求識別情報を用いて前記視聴要求が所定の条件を満たすことを確認処理する第１確認処理部、前記第１確認処理部における確認処理後に、前記第２ロケーション識別情報から視聴要求識別情報を削除した第１ロケーション識別情報を前記コンテンツ配信装置に送信する第１送信処理部、として機能させ、前記視聴要求識別情報には当該視聴要求の有効期限を示す情報である期限情報が含まれており、前記第１確認処理部は、前記期限情報を参照して前記視聴要求が有効期限内であるか否かを判定することを特徴とする。

本発明によれば、動画像のストリーミングにおける好ましくない遅延を抑制する。

第１実施形態に係るコンテンツ配信システムの構成図である。 クライアントの機能構成図である。 ＭＦサーバの機能構成図である。 ＭＦサーバが保有するＭＦファイルの例示である。 ＭＦサーバが生成するtokenの例示である。 Web Serverの機能構成図である。 Reverse Proxyの機能構成図である。 第１実施形態に係るコンテンツ配信システムの処理を示すシーケンス図の例示である。 Reverse Proxyの処理を示すフローチャートの例示である。 第２実施形態に係るコンテンツ配信システムの構成図である。 Reverse Proxyの機能構成図である。 Load Balancerの機能構成図である。 tokenリストサーバの機能構成図である。 第２実施形態に係るコンテンツ配信システムの処理を示すシーケンス図の例示である。 第３実施形態に係るコンテンツ配信システムを構成するＭＦサーバが生成するtokenの例示である。 Reverse Proxyの処理を示すフローチャートの例示である。

以下、本発明の実施するための形態を、適宜図面を参照しながら詳細に説明する。
各図は、本発明を十分に理解できる程度に、概略的に示してあるに過ぎない。よって、本発明は、図示例のみに限定されるものではない。また、本実施形態では、本発明と直接的に関連しない構成や周知な構成については、説明を省略する場合がある。なお、各図において、共通する構成要素や同様な構成要素については、同一の符号を付し、それらの重複する説明を省略する。

［第１実施形態］
≪第１実施形態に係るコンテンツ配信システムの構成≫
図１を参照して、第１実施形態に係るコンテンツ配信システム１の構成について説明する。図１は、第１実施形態に係るコンテンツ配信システム１の構成図である。
コンテンツ配信システム１は、クライアント１００と、ＭＦ（Manifest File）サーバ２００と、Web Server３００と、Reverse Proxy４００とで構成される。

このコンテンツ配信システム１は、ＨＴＴＰを用いたストリーミングによりコンテンツを数秒単位（例えば、１０秒）のセグメントとして配信するものである。概略を示すと、このコンテンツ配信システム１では、クライアント１００がＭＦサーバ２００からマニフェストファイル(ＭＦファイル)を取得し、ＭＦファイルに記載された情報に基づき各セグメントをWeb Server３００から取得する。この様なＨＴＴＰ動画配信方式の標準に「MPEG-DASH」がある。「MPEG-DASH」でマニフェストファイルに相当するものはＭＰＤ（Media Presentation Description）である。

＜クライアント＞
図２は、クライアント１００の機能構成を模式的に示す図である。クライアント１００は、当該クライアント１００の動作を全体的に制御する処理部１０１と、液晶表示装置等の表示装置によって構成される表示部１０２と、タッチセンサ等の入力デバイスによって構成される操作部１０３と、ハードディスク等の記録媒体によって構成される記憶部１０４と、モデム等の通信装置によって構成される通信部１０５と、フラッシュメモリ１０６とからなる。

記憶部１０４には、Web Server３００から取得したコンテンツ本体のデータを格納するコンテンツ記憶部１０４Ａと、ＭＦサーバ２００から取得したＭＦファイルを記憶するためのＭＦファイル記憶部１０４Ｂと、クライアント１００のユーザに関する情報を記憶するためのユーザ情報記憶部１０４Ｃとが備えられる。

処理部１０１には、コンテンツ再生部１０１Ａと、コンテンツ取得部１０１Ｂと、ＭＦファイル取得部１０１Ｃとが備えられる。処理部１０１は、例えば、ＣＰＵ（Central Processing Unit）によるプログラム実行処理や、専用回路等により実現される。プログラム実行処理により実現する場合、記憶部１０４には、コンテンツ再生部１０１Ａ、コンテンツ取得部１０１ＢおよびＭＦファイル取得部１０１Ｃを実現するためのプログラムが格納される。

コンテンツ再生部１０１Ａは、コンテンツ記憶部１０４Ａに格納されたコンテンツを再生する。具体的には、コンテンツ再生部１０１Ａは、表示部１０２に映像（または、画像）の再生画面を表示させる。また、再生対象となるコンテンツが音声データを含む場合、コンテンツ再生部１０１Ａは、クライアント１００の内部、または外部のスピーカに、当該音声データに基づく音声を出力させる。

コンテンツ取得部１０１Ｂは、予め取得しているコンテンツリストに基づき通信部１０５およびネットワークを介して、Reverse Proxy４００を介してWeb Server３００から、所望のコンテンツを取得する。取得されたコンテンツは、記憶部１０４のコンテンツ記憶部１０４Ａに格納される。

ＭＦファイル取得部１０１Ｃは、通信部１０５およびネットワークを介して、ＭＦサーバ３００からＭＦファイルを取得する。取得されたＭＦファイルは、ＭＦファイル記憶部１０４Ｂに格納される。このＭＦファイルに記載されるＵＲＬに基づいて、コンテンツ取得部１０１Ｂは、Web Server３００から所望のコンテンツを取得する。

＜ＭＦサーバ＞
図３は、ＭＦサーバ２００の機能構成を模式的に示す図である。ＭＦサーバ２００は、モデム等の通信装置によって構成される通信部２０１と、当該ＭＦサーバ２００の動作を全体的に制御する処理部２０２と、ハードディスク等の記録媒体によって構成される記憶部２０３とからなる。

記憶部２０３には、ＭＦファイル記憶部２０３Ａと、token管理部２０３Ｂとが備えられる。ＭＦファイル記憶部２０３Ａは、各コンテンツのセグメントのリストを記載したＭＦファイルを格納する。初期状態（視聴要求の一部であるＭＦ要求をクライアントから受ける前の状態）のＭＦファイルを図４に示す。ＭＦファイルには、コンテンツを数秒単位（例えば、１０秒）にしたセグメント毎にロケーション識別情報としてのＵＲＬが格納されている。このＭＦファイルに格納されるＵＲＬは、ＭＦ要求があった時点で、ＭＦファイル修正部２０２Ａによって修正される。token管理部２０３Ｂは、token生成部２０２Ｃで生成した視聴要求識別情報としてのtokenを有効期限まで管理（記憶）する。Tokenの詳細については、token生成部２０２Ｃで説明する。

処理部２０２には、ＭＦファイル修正部２０２Ａと、ＭＦファイル配信部２０２Ｂと、token生成部２０２Ｃとが備えられる。処理部２０２は、例えば、ＣＰＵ（Central Processing Unit）によるプログラム実行処理や、専用回路等により実現される。プログラム実行処理により実現する場合、記憶部２０３には、ＭＦファイル修正部２０２Ａ、ＭＦファイル配信部２０２Ｂおよびtoken生成部２０２Ｃを実現するためのプログラムが格納される。

ＭＦファイル修正部２０２Ａは、クライアント１００からのＭＦファイル要求に対して、ＭＦファイル記憶部２０３Ａに格納するＭＦファイルに記載の各セグメントのＵＲＬに、token生成部２０２Ｃで生成したtokenを付加する。例えば、「http://url1」を「http://url1/123412」の様に修正する。
ＭＦファイル配信部２０２Ｂは、ＭＦファイル修正部２０２Ａで修正されたＭＦファイルをクライアント１００に応答する。

token生成部２０２Ｃは、自身（token）の有効期限とセッション番号とで構成される視聴要求識別情報としてのtokenを生成し、生成したtokenをtoken管理部２０３Ｂに格納する。図５に示すのが、tokenの例示である。ここで、tokenの有効期限は、視聴要求されるコンテンツを視聴できる期間を表すものと言い換えることができるので、視聴に十分な時間（例えば、１日や数時間）にするのが望ましい。有効期限は、一律であってもよいし、token毎やコンテンツ毎に異なっていてもよい。また、token生成部２０２Ｃは、token管理部２０３Ｂに記録されていないtokenを生成する。そして、token生成部２０２Ｃは、有効期限が過ぎたtokenをtoken管理部２０３Ｂから削除する。

＜Web Server＞
図６は、Web Server ３００の機能構成を模式的に示す図である。Web Server３００は、モデム等の通信装置によって構成される通信部３０１と、当該Web Server３００の動作を全体的に制御する処理部３０２と、ハードディスク等の記録媒体によって構成される記憶部３０３とからなる。記憶部３０３には、コンテンツファイル記憶部３０３Ａが備えられる。コンテンツファイル記憶部３０３Ａは、コンテンツを構成するセグメントを格納する。

処理部３０２には、コンテンツ配信部３０２Ａが備えられる。処理部３０２は、例えば、ＣＰＵ（Central Processing Unit）によるプログラム実行処理や、専用回路等により実現される。プログラム実行処理により実現する場合、記憶部３０３には、コンテンツ配信部３０２Ａを実現するためのプログラムが格納される。コンテンツ配信部３０２Ａは、クライアント１００からの要求に応じて、コンテンツ本体のデータをセグメント単位で配信する。

＜Reverse Proxy＞
図７は、Reverse Proxy４００の機能構成を模式的に示す図である。Reverse Proxy４００は、モデム等の通信装置によって構成される通信部４０１と、当該Reverse Proxy４００の動作を全体的に制御する処理部４０２と、ハードディスク等の記録媒体によって構成される記憶部４０３とからなる。記憶部４０３には、tokenリスト記憶部４０３Ａが備えられる。tokenリスト記憶部４０３Ａは、tokenと最終アクセス時間とを対応付けたtokenリストを格納する。なお、tokenリストに登録したtokenは、定期的に有効期限切れを確認して、有効期限切れならtokenリストから削除する。

処理部４０２には、token処理部４０２Ａと、ＵＲＬ処理部４０２Ｂと、状態判定部４０２Ｃと、通信処理部４０２Ｄとが備えられる。処理部４０２は、例えば、ＣＰＵ（Central Processing Unit）によるプログラム実行処理や、専用回路等により実現される。プログラム実行処理により実現する場合、記憶部４０３には、token処理部４０２Ａ、ＵＲＬ処理部４０２Ｂ、状態判定部４０２Ｃおよび通信処理部４０２Ｄを実現するためのプログラムが格納される。

token処理部４０２Ａは、クライアント１００から受信したメッセージのＵＲＬに含まれているtokenを取り除き、token内の有効期限が切れていればクライアント１００にエラーメッセージを返すように通信処理部４０２Ｄにメッセージを渡す。有効期限が切れておらず、リスト記憶部４０３Ａが記憶するtokenリストに記録されてもなければtokenリストに記録し、一方、tokenリストに記録されていればリスト記憶部４０３Ａ内の対応する最終アクセス時間を書き直す（更新する）。

また、token処理部４０２Ａは、制限モード（状態判定部４０２Ｃにより設定されるモード）になっていれば、最終アクセス時間からの経過時間が一定値を超えたクライアント１００からの要求に対しエラーメッセージを返すように通信処理部４０２Ｄにメッセージを渡す。つまり、一定時間アクセスの無いクライアント１００にエラーメッセージを返すようにする。これらの処理は、例えば、コンテンツの再生を長時間に渡って一時停止状態にしていたクライアントが再生を再開した場合や、ネットワーク障害により通信不能になっていたクライアントが回線の回復により一斉に繋がるようになった場合など、セグメント要求が想定しない形で増加することを防止することを想定している。

ＵＲＬ処理部４０２Ｂは、クライアント１００が要求したＵＲＬをWeb Server３００のＵＲＬに変換して、変換後のＵＲＬにメッセージを転送するように通信処理部４０２Ｄにメッセージを渡す。
状態判定部４０２Ｃは、アクティブなクライアントの数が許容量を超えている場合に、制限モードに切り替え、上限を下回ったら（上限より一定値以下）制限モードを解除する。ここでアクティブなクライアントとは、最終アクセス時間からの経過時間が閾値以内のtokenを持つクライアントのことである。また、通信量を監視して、通信量が上限を超えた時点で制限モードに切り替え、上限を下回ったら（上限より一定値以下）制限モードを解除するようにしてもよい。
通信処理部４０２Ｄは、クライアント１００からの要求のWeb Server３００への転送、Web Server３００からの応答のクライアント１００への転送処理およびクライアント１００からの要求におけるエラー応答処理を、通信部４０１を用いて行う。

≪第１実施形態に係るコンテンツ配信システムの動作≫
図８を参照して（適宜、図１ないし図７を参照）、第１実施形態に係るコンテンツ配信システム１の動作について説明する。図８は、第１実施形態に係るコンテンツ配信システム１の動作を示すシーケンス図である。最初に、クライアント１００のＭＦファイル取得部１０１Ｃ（図２参照）は、ＭＦサーバ２００に対してＭＦファイルを要求する（ステップＳ１）。ここで、ＭＦファイルの要求は、視聴要求の一部をなすものである。なお、ＭＦサーバ２００のＵＲＬは、例えば、ポータルサーバ等から取得すればよい。

各ライアント１００からのＭＦファイルの要求に対して、ＭＦサーバ２００のtoken生成部２０２Ｃ（図３参照）は、視聴要求毎にユニークなtokenを生成する（ステップＳ２）。ここで、ＭＦサーバ２００のtoken管理部２０３Ｂ（図３参照）は、視聴要求毎にユニークなtokenを常時生成するために、有効期限を設けてtokenを管理している。有効期限が切れたtokenは管理の対象ではなくなり、再利用が可能となる。

続いて、ＭＦサーバ２００のＭＦファイル修正部２０２Ａ（図３参照）は、ＭＦファイルを修正する（ステップＳ３）。具体的には、ＭＦファイル修正部２０２Ａは、ＭＦファイルに記載されているコンテンツのセグメントのＵＲＬの末尾に生成したtokenを追加する。ここで、各セグメントのＵＲＬはReverse Proxy４００のＵＲＬである。そして、ＭＦサーバ２００のＭＦファイル配信部２０２Ｂ（図３参照）は、修正したＭＦファイルをクライアント１００に応答する（ステップＳ４）。クライアント１００のコンテンツ取得部１０１Ｂ（図２参照）は、ＭＦサーバ２００から取得した修正済みのＭＦファイルに記載のＵＲＬを元にして、セグメントを要求する（ステップＳ５）。

次に、セグメント要求に対して、Reverse Proxy４００は、視聴要求毎にクライアントの制御処理を行う（ステップＳ６）。この処理では、セグメント要求のＵＲＬの末尾に記載のtokenを取り除き、取り除いたtokenに基づき視聴要求毎の制御処理を行う。ステップＳ６の処理の詳細は後述する。ステップＳ６の処理で、tokenが有効期限切れ等と判定された場合に、通信処理部４０２Ｄ（図７参照）はクライアント１００に対してエラー応答をする（ステップＳ７）。一方、tokenが有効である等と判定された場合に、通信処理部４０２Ｄはセグメントの要求をWeb Server３００に中継する（ステップＳ８）。

次に、Web Server３００のコンテンツ配信部３０２Ａ（図６参照）は、中継された要求に基づきコンテンツを構成するセグメントファイルを応答する（ステップＳ９）。続いて、Reverse Proxy４００の通信処理部４０２Ｄ（図７参照）は、セグメントファイルをクライアント１００に中継する（ステップＳ１０）。そして、クライアント１００のコンテンツ再生部１０１Ａ（図２参照）は、コンテンツを構成するセグメントファイルを再生する（ステップＳ１１）。コンテンツが終了するまで、以上説明した処理が繰り返して行われる。

次に、図８のステップＳ６の処理について、図９を参照して説明する。図９は、Reverse Proxy４００の処理を示すフローチャートである。最初に、Reverse Proxy４００は、Web Server３００が停止処理を開始したか否かを判定する（ステップＳ２１）。停止処理を始めていた場合（ステップＳ２１で“Ｙｅｓ”）、Reverse Proxy４００は処理を終了する。一方、停止処理を始めていなかった場合（ステップＳ２１で“Ｎｏ”）、Reverse Proxy４００は処理をステップＳ２２に進める。

停止処理を始めていなかった場合（ステップＳ２１で“Ｎｏ”）に、Reverse Proxy４００は、クライアント１００からセグメント要求を受信したか否かを判定する（ステップＳ２２）。セグメント要求を受信した場合（ステップＳ２２で“Ｙｅｓ”）、Reverse Proxy４００は処理をステップＳ２３に進める。一方、セグメント要求を受信していない場合（ステップＳ２２で“Ｎｏ”）、Reverse Proxy４００は処理をステップＳ２１に戻す。

セグメント要求を受信した場合（ステップＳ２２で“Ｙｅｓ”）に、token処理部４０２Ａ（図７参照）は、ＵＲＬの末尾からtokenを取り除き（ステップＳ２３）、取り除いたtokenが有効期限内であるか否かを判定する（ステップＳ２４）。tokenが有効期限内である場合（ステップＳ２４で“Ｙｅｓ”）、token処理部４０２Ａは処理をステップＳ２６に進める。一方、tokenが有効期限内でない（有効期限切れ）場合（ステップＳ２４で“Ｎｏ”）、token処理部４０２Ａは、通信処理部４０２Ｄに対してエラーの応答を要求して次の要求を待つ（ステップＳ２５）。

tokenが有効期限内である場合（ステップＳ２４で“Ｙｅｓ”）に、token処理部４０２Ａは、tokenがtokenリストに登録済みであるか否かを判定する（ステップＳ２６）。tokenがtokenリストに登録済みである場合（ステップＳ２６で“Ｙｅｓ”）に、token処理部４０２Ａは、tokenリストの最終アクセス時間を更新する（ステップＳ２７）。一方、tokenがtokenリストに登録済みでない場合（ステップＳ２６で“Ｎｏ”）に、token処理部４０２Ａは、そのtokenをアクセス時間と共にtokenリストに登録する（ステップＳ２８）。

続いて、token処理部４０２Ａは、アクティブなクライアントの数が許容量を超えているか否か（つまり、状態判定部４０２Ｃにより制限モードに移行されているか）を判定する（ステップＳ２９）。ここでアクティブなクライアントとは、最終アクセス時間からの経過時間が閾値以内のtokenを持つクライアントのことである。許容量を超えている場合（ステップＳ２９で“Ｙｅｓ”）に処理をステップＳ３０に進め、一方、許容量を超えていない場合（ステップＳ２９で“Ｎｏ”）に処理をステップＳ３１に進める。

許容量を超えている場合（ステップＳ２９で“Ｙｅｓ”）に、token処理部４０２Ａは、最終アクセス時間からの経過時間が閾値以内であるか否かを判定する（ステップＳ３０）。経過時間が閾値以内でない（閾値より大きければ）場合（ステップＳ３１で“Ｎｏ”）に、token処理部４０２Ａは、通信処理部４０２Ｄに対してエラーの応答を要求して次の要求を待つ（ステップＳ３２）。つまり、一定時間アクセスの無いクライアント１００にエラーメッセージを返すようにしている。一方、許容量を超えていない場合（ステップＳ２９で“Ｎｏ”）や許容量を超えていても経過時間が閾値以内である場合（ステップＳ３０で“Ｙｅｓ”）に、token処理部４０２Ａは、セグメント要求をWeb Server３００に中継し、またそれに対する応答をクライアント１００に返す（ステップＳ３１）。

以上のように、第１実施形態に係るコンテンツ配信システム１は、視聴要求毎に視聴要求識別情報としてのtokenを生成し、セグメント要求のＵＲＬの末尾に追加する。そして、そのtokenを追加されたＵＲＬを用いてセグメント要求が行われる。その為、ストリーミング等リアルタイム性が重要なコンテンツの場合にリダイレクトは再生の妨げになるが、本実施形態ではリダイレクトの必要がないので動画像のストリーミングにおける好ましくない遅延を抑制する。

また、第１実施形態に係るコンテンツ配信システム１は、クライアントとの間にセッションを設けるための特別のプロトコルが不要なので、クライアント１００はＨＴＴＰのプロトコルで取得するのと同じ方法を用いて、ＭＦサーバ２００からＭＦファイルを取得した後にWeb Server３００に対してセグメントを要求すればよい。
さらに、第１実施形態に係るコンテンツ配信システム１は、視聴要求識別情報としてのtokenを用いることで視聴要求毎に制御を行うことが可能である。その為、ＨＴＴＰによるストリーミングでありながら、ＲＴＰによりストリーミングのようにコンテンツの配信の制御と視聴クライアント数の把握が可能である。なお、動画像配信においてはＯｎｅＴｉｍｅＵＲＬを発行してセッションを管理する方法が有るが、クライアントとサーバ間でセッション確立用のプロトコルが別途必要となる。

［第２実施形態］
第１実施形態に係るコンテンツ配信システム１は、図１に示すように１台のWeb Server３００を含む構成であったが、配信能力を増大させるためにはWeb Server３００の数を増やす必要がある。第２実施形態は、Load Balancer６００（図１０参照）を導入してWeb Server３００の台数を増やし、配信能力を増大させるものである。

＜第２実施形態に係るコンテンツ配信システムの構成＞
図１０を参照して、第２実施形態に係るコンテンツ配信システム１ａの構成について説明する。図１０は、第２実施形態に係るコンテンツ配信システム１ａの構成図である。
コンテンツ配信システム１ａは、クライアント１００と、ＭＦ（Manifest File）サーバ２００と、二つのWeb Server３００と、二つのReverse Proxy５００と、Load Balancer６００と、tokenリストサーバ７００とで構成される。このコンテンツ配信システム１ａでは、クライアント１００からのセグメント要求を二つのReverse Proxy５００で交互に処理を行うことにより、クライアント１００からの要求を分散する。そして、コンテンツ配信システム１ａは、Reverse Proxy５００毎に各tokenの最終アクセス時間が異ならないようにするために、tokenリストサーバ７００によってそれぞれのReverse Proxy５００が持つtoken リストの整合を取る。

＜Reverse Proxy＞
図１１は、Reverse Proxy５００の機能構成を模式的に示す図である。Reverse Proxy５００は、モデム等の通信装置によって構成される通信部５０１と、当該Reverse Proxy５００の動作を全体的に制御する処理部５０２と、ハードディスク等の記録媒体によって構成される記憶部５０３とからなる。記憶部５０３には、tokenリスト記憶部５０３Ａが備えられる。tokenリスト記憶部５０３Ａは、tokenと最終アクセス時間とを対応付けたtokenリストを格納する。なお、tokenリストに登録したtokenは、定期的に有効期限切れを確認して、有効期限切れならtokenリストから削除する。

処理部５０２には、token処理部５０２Ａと、ＵＲＬ処理部５０２Ｂと、状態判定部５０２Ｃと、通信処理部５０２Ｄと、tokenリスト整合部５０２Ｅとが備えられる。処理部５０２は、例えば、ＣＰＵ（Central Processing Unit）によるプログラム実行処理や、専用回路等により実現される。プログラム実行処理により実現する場合、記憶部５０３には、token処理部５０２Ａ、ＵＲＬ処理部５０２Ｂ、状態判定部５０２Ｃ、通信処理部５０２Ｄ、tokenリスト整合部５０２Ｅを実現するためのプログラムが格納される。

token処理部５０２Ａ、ＵＲＬ処理部５０２Ｂ、状態判定部５０２Ｃおよび通信処理部５０２Ｄは、第１実施形態で説明したtoken処理部４０２Ａ、ＵＲＬ処理部４０２Ｂ、状態判定部４０２Ｃおよび通信処理部４０２Ｄと同様である。その為、ここでは説明を省略する。tokenリスト整合部５０２Ｅは、tokenリストサーバ７００に定期的にtokenリストを送信し、応答として取得したtokenリストをtokenリスト記憶部５０３Ａに上書きする。

＜Load Balancer＞
図１２は、Load Balancer６００の機能構成を模式的に示す図である。Load Balancer６００は、モデム等の通信装置によって構成される通信部６０１と、当該Load Balancer６００の動作を全体的に制御する処理部６０２と、ハードディスク等の記録媒体によって構成される記憶部６０３とからなる。記憶部６０３には、サーバリスト記憶部６０３Ａが備えられる。サーバリスト記憶部６０３Ａは、セグメント要求を次に転送するWeb Server３００のＵＲＬとWeb Server３００のＵＲＬのサーバリストを記憶する。

処理部６０２には、サーバ選定部６０２Ａと、通信処理部６０２Ｂとが備えられる。処理部６０２は、例えば、ＣＰＵ（Central Processing Unit）によるプログラム実行処理や、専用回路等により実現される。プログラム実行処理により実現する場合、記憶部６０３には、サーバ選定部６０２Ａおよび通信処理部６０２Ｂを実現するためのプログラムが格納される。

サーバ選定部６０２Ａは、サーバリスト記憶部６０３Ａにあるサーバリストからセグメント要求を転送するWeb Server３００を選択する。Web Server３００の選択は、例えば、ラウンドロビンで行う。サーバ選定部６０２Ａは、通信処理部６０２Ｂにセグメント要求を送り選定したサーバに転送する。通信処理部６０２Ｂは、通信部６０１を用いてセグメント要求の転送を行う。

＜tokenリストサーバ＞
図１３は、tokenリストサーバ７００の機能構成を模式的に示す図である。tokenリストサーバ７００は、モデム等の通信装置によって構成される通信部７０１と、当該tokenリストサーバ７００の動作を全体的に制御する処理部７０２と、ハードディスク等の記録媒体によって構成される記憶部７０３とからなる。記憶部７０３には、tokenリスト記憶部７０３Ａが備えられる。tokenリスト記憶部７０３Ａは、tokenと最終アクセス時間とを対応付けて格納する。

処理部７０２には、tokenリスト更新処理部７０２Ａと、通信処理部７０２Ｂとが備えられる。処理部７０２は、例えば、ＣＰＵ（Central Processing Unit）によるプログラム実行処理や、専用回路等により実現される。プログラム実行処理により実現する場合、記憶部７０３には、tokenリスト更新処理部７０２Ａおよび通信処理部７０２Ｂを実現するためのプログラムが格納される。

tokenリスト更新処理部７０２Ａは、Reverse Proxy５００から送られたtokenリストとtokenリスト記憶部７０３Ａにあるtokenリストとの差分をtokenリスト記憶部７０３Ａにあるtokenリストに反映する。そして、通信処理部７０２Ｂを用いて更新されたtokenリストをReverse Proxy５００に応答する。これにより、一方のReverse Proxy５００が保有するtokenリストに他方のReverse Proxy５００が保有するtokenリストの情報が反映される。通信処理部７０２Ｂは、通信部７０１を用いて要求メッセージの受信応答を行う。

≪第２実施形態に係るコンテンツ配信システムの動作≫
図１４を参照して、第２実施形態に係るコンテンツ配信システム１ａの動作について説明する。図１４は、第２実施形態に係るコンテンツ配信システム１ａの動作を示すシーケンス図である。ステップＳ４１〜ステップＳ４５までの処理は、第１実施形態のステップＳ１〜ステップＳ５までの処理と同様であるので説明を省略する（図８参照）。ステップＳ４５に続いて、Load Balancer６００は、ロードバランシングによりセグメント要求を分散して各Reverse Proxy５００に送信する（ステップＳ４６）。分散方法は、例えば、ラウンドロビン（二つのReverse Proxy５００に交互に割り当てる）で行う。

次に、セグメント要求に対して、Reverse Proxy５００は、視聴要求毎にクライアントの制御処理を行う（ステップＳ４７）。この処理では、セグメント要求のＵＲＬの末尾に記載のtokenを取り除き、取り除いたtokenに基づき視聴要求毎の制御の処理を行う。ここで、Reverse Proxy５００のtokenリスト整合部５０２Ｅ（図１１参照）は、一定周期毎にtoken リストをtoken リストサーバ７００に送信し、更新されたtokenリストをtoken リストサーバ７００から取得する。ここで、更新されたtokenリストとは、他のReverse Proxy５００もしくは自身が前に更新したものに、今回自身が送信したものを反映したものである。Reverse Proxy５００がtoken リストサーバ７００とtokenリストをやり取りする周期は、アクティブクライアントと判定する閾値より小さいものとするのがよい。これにより、tokenリストに記載の最終アクセス時間は最新のものが上書きされる。それ以外の処理は、第１実施形態のステップＳ６の処理と同様である（図８参照）。

ステップＳ４７の処理で、tokenが有効期限切れ等と判定された場合に、通信処理部５０２Ｄ（図１１参照）はLoad Balancer６００に対してエラー応答を送信し（ステップＳ４８）、Load Balancer６００の通信処理部６０２Ｂ（図１２参照）はクライアント１００に対してエラー応答を送信する（ステップＳ４９）。一方、tokenが有効である等と判定された場合に、通信処理部５０２Ｄはセグメントの要求をWeb Server３００に中継する（ステップＳ５０）。

次に、Web Server３００のコンテンツ配信部３０２Ａ（図６参照）は、中継された要求に基づきセグメントファイルを応答する（ステップＳ５１）。続いて、Reverse Proxy５００の通信処理部５０２Ｄ（図１１参照）は、セグメントファイルをLoad Balancer６００に対して送信し（ステップＳ５２）、Load Balancer６００の通信処理部６０２Ｂ（図１２参照）はセグメントファイルをクライアント１００に送信する（ステップＳ５２）。そして、クライアント１００のコンテンツ再生部１０１Ａは、コンテンツを構成するセグメントファイルを再生する（ステップＳ５４）。コンテンツが終了するまで、以上説明した処理が繰り返して行われる。

以上のように、第２実施形態に係るコンテンツ配信システム１ａは、tokenリストサーバ７００を用いて各Reverse Proxy５００が保有するtokenリストの最終アクセス時間の同期を取る。その為、配信容量を上げるためにWeb Server３００のスケールアウトを行っても、配信の制御と視聴クライアント数の把握が可能となる。なお、クライアント１００側では特に新たなツールの導入も不要である。

［第３実施形態］
第１実施形態に係るコンテンツ配信システム１および第２実施形態に係るコンテンツ配信システム１ａでは、悪意のある者が有効期限を改ざんして使用してしまう可能性があった。第３実施形態では、これを防ぐために秘密のワードとハッシュ関数をtokenに使用する。ハッシュ関数は、ある値から引数として渡した文字列が推定できない一方向関数である。システムの構成は第１、第２実施形態と同様であってよい。ここでは、第１実施形態のコンテンツ配信システム１に適用する場合を例に挙げて説明する。

第３実施形態で用いるtokenのフォーマットを図１５に例示する。図１５に示すtokenには、新たにハッシュ値が追加されている。Reverse Proxy４００とＭＦサーバ２００とは、外部に公開しない共通の秘密のワード（任意の文字列）を保持しており、tokenの有効期限、セッション番号、秘密のワードをあわせたものをハッシュ値として使用する。

ＭＦサーバ２００（図１参照）は、具体的にはtoken作成時に、「tokenの有効期限の文字列＋セッション番号の文字列＋Reverse Proxy４００とＭＦサーバ２００とで共有する秘密のワードの文字列」に対してハッシュ関数を用いて、ハッシュ値として計算する。そして、ＭＦサーバ２００は、計算したハッシュ値、tokenの有効期限、セッション番号をあわせたものをtokenとしてセグメント要求のＵＲＬに付加する。

Reverse Proxy４００（図１参照）は、セグメント要求からtoken取得時に、自身の保持している秘密のワードとtokenの有効期限、セッション番号からハッシュ値を計算して、計算したハッシュ値とtokenに記載のハッシュ値とを比較する。同一であればＭＦサーバ２００で発行されたものであると判断できる。

次に、第３実施形態における図８のステップＳ６の処理について、図１６を参照して説明する。図１６は、Reverse Proxy４００の処理を示すフローチャートである。ステップＳ２１〜ステップＳ２２の処理は図８に示す第１実施形態と同様である。セグメント要求を受信した場合（ステップＳ２２で“Ｙｅｓ”）に、token処理部４０２Ａ（図７参照）は、ＵＲＬの末尾からtokenを取り除き、自身の保持している秘密のワードとtokenの有効期限、セッション番号からハッシュ値を計算してハッシュ値を確認する（ステップＳ２３ａ）。そして、計算したハッシュ値とtokenに記載のハッシュ値とを比較して同一であれば、tokenが無効でない（有効である）と判定して（ステップＳ２３ｂで“Ｎｏ”）処理をステップＳ２４に進める。ステップＳ２４以降の処理は、図８に示す第１実施形態と同様である。一方、計算したハッシュ値とtokenに記載のハッシュ値とが同一でなければ、tokenが無効であると判定して（ステップＳ２３ｂで“Ｙｅｓ”）、token処理部４０２Ａは、通信処理部４０２Ｄに対してエラーの応答を要求して次の要求を待つ（ステップＳ２３ｃ）。

以上のように、第３実施形態に係るコンテンツ配信システム１ｂは、視聴要求識別情報としてのtokenにtokenの有効期限、セッション番号、秘密のワードをあわせたものをハッシュ値と含めている。したがって、クライアント１００側で不正にtokenを修正して有効期限を延ばした場合などに、その改ざんを見破ることが可能である。その為、不正に重複したtokenが発行されることにより、tokenの管理ができなくなってしまうことを防止できる。

［変形例］
以上、本発明の実施形態について説明したが、本発明はこれに限定されるものではなく、特許請求の範囲の趣旨を変えない範囲内で実施することができる。実施形態の変形例を以下に示す。

第１実施形態ないし第３実施形態では、視聴要求識別情報としてのtokenに有効期限を設定していたが、tokenの管理方法はこれに限定されるものではない。例えば、有効期限に代えて、Web Server３００へのアクセス回数制限をtokenに設定してもよい。この場合、アクセス回数制限は、コンテンツの再生時間をセグメントの時間で割ったものであってもよい。

また、第２実施形態では、Web Server３００の数の増加に合わせて、Reverse Proxy５００の数を複数台にしていたが、Reverse Proxy５００を１台構成にすることも考えられる。その場合は、tokenリストが常に整合がとれている状態なのでtokenリストサーバ７００は必要ない。

また、第２実施形態では、Reverse Proxy５００のtokenリスト整合部５０２Ｅ（図１１参照）は、一定周期毎にtoken リストをtoken リストサーバ７００に送信し、更新されたtokenリストをtoken リストサーバ７００から取得していた。しかしながら、各Reverse Proxy５００が保有するtokenリストの同期を取る方法はこれに限定されるものではない。例えば、一定周期毎にtoken リストをtoken リストサーバ７００から取得するのに加えて、または代えて、tokenの有効期限が過ぎたと判定された場合（図９のステップＳ２４で“Ｎｏ”）に、token リストをtoken リストサーバ７００から取得するようにしてもよい。そして、最新の最終アクセス時間によりtokenの有効期限を再度判定する。

１，１ａ コンテンツ配信システム
１００ クライアント（コンテンツ受信装置）
１０１Ａ コンテンツ再生部
１０１Ｂ コンテンツ取得部
１０１Ｃ ＭＦファイル取得部
１０４Ａ コンテンツ記憶部
１０４Ｂ ＭＦファイル記憶部
１０４Ｃ ユーザ情報記憶部
２００ ＭＦサーバ（ファイル装置）
２０２Ａ ＭＦファイル修正部（識別情報変更処理部）
２０２Ｂ ＭＦファイル配信部（第２送信処理部）
２０２Ｃ token生成部（識別情報生成処理部）
２０３Ａ ＭＦファイル記憶部（第２記憶部）
２０３Ｂ token管理部
３００ Web Server（コンテンツ配信装置）
３０２Ａ コンテンツ配信部
３０３Ａ コンテンツファイル記憶部
４００ Reverse Proxy（中継装置）
４０２Ａ token処理部（第１確認処理部）
４０２Ｂ ＵＲＬ処理部
４０２Ｃ 状態判定部
４０２Ｄ 通信処理部（第１受信処理部、第１送信処理部）
４０３Ａ tokenリスト記憶部（第１記憶部）
５００ Reverse Proxy（中継装置）
５０２Ｅ tokenリスト整合部
６００ Load Balancer
６０２Ａ サーバ選定部
６０２Ｂ 通信処理部
６０３Ａ サーバリスト記憶部
７００ tokenリストサーバ（管理装置）
７０２Ａ tokenリスト更新処理部
７０２Ｂ 通信処理部
７０３Ａ tokenリスト記憶部

Claims (10)

1. コンテンツ受信装置から送信されるコンテンツを時分割した時分割コンテンツの視聴要求をコンテンツ配信装置に転送し、前記コンテンツ配信装置から送信される時分割コンテンツを前記コンテンツ受信装置に転送する中継装置であって、
   前記時分割コンテンツに対応する第１ロケーション識別情報内に前記視聴要求を識別する視聴要求識別情報を含む情報である第２ロケーション識別情報を、前記コンテンツ受信装置から視聴要求として受信する第１受信処理部と、
   前記視聴要求識別情報を用いて前記視聴要求が所定の条件を満たすことを確認処理する第１確認処理部と、
   前記第１確認処理部における確認処理後に、前記第２ロケーション識別情報から視聴要求識別情報を削除した第１ロケーション識別情報を前記コンテンツ配信装置に送信する第１送信処理部と、を有し、
   前記視聴要求識別情報には当該視聴要求の有効期限を示す情報である期限情報が含まれており、
   前記第１確認処理部は、
   前記期限情報を参照して前記視聴要求が有効期限内であるか否かを判定する、
   ことを特徴とする中継装置。
2. 請求項１に記載される中継装置であって、
   前記視聴要求識別情報に対応づけて前記視聴要求を受信した前回のアクセス時刻を記憶する第１記憶部を有し、
   前記第１確認処理部は、前記有効期限の判定に加えて、
   前回のアクセス時刻からの経過時間が閾値以内である視聴要求の数が所定数より多い場合に、受信した視聴要求の現在の時刻と前回のアクセス時刻との差分が所定時間未満であるか否かを判定する、
   ことを特徴とする中継装置。
3. 請求項１に記載される中継装置を有するコンテンツ配信システムであって、
   前記コンテンツ配信装置を有し、
   前記コンテンツ配信装置は、
   前記中継装置から、前記第１ロケーション識別情報を受信して、前記第１ロケーション識別情報に対応する前記時分割コンテンツを前記中継装置に対して送信する、
   ことを特徴とするコンテンツ配信システム。
4. 請求項３に記載されるコンテンツ配信システムであって、
   前記コンテンツ受信装置を有し、
   前記コンテンツ受信装置は、
   前記第２ロケーション識別情報を有する第１ファイルをファイル装置から受信して、前記第２ロケーション識別情報を前記中継装置に対して送信する、
   ことを特徴とするコンテンツ配信システム。
5. 請求項４に記載されるコンテンツ配信システムであって、
   前記ファイル装置を有し、
   前記ファイル装置は、
   コンテンツ情報と、前記第１ロケーション識別情報とを有するファイルを記憶する第２記憶部と、
   前記コンテンツ受信装置から、コンテンツ情報を有するファイル送信要求情報を受信した場合に、前記視聴要求識別情報を生成する識別情報生成処理部と、
   前記コンテンツ情報に対応するファイルにおける前記第１ロケーション識別情報を、当該第１ロケーション識別情報内に前記生成した視聴要求識別情報を含めた前記第２ロケーション識別情報とした前記第１ファイルに変更するロケーション識別情報変更処理部と、
   前記コンテンツ受信装置に、前記第１ファイルを送信する第２送信処理部とを有する、
   ことを特徴とするコンテンツ配信システム。
6. 請求項２に記載される中継装置を複数有するコンテンツ配信システムであって、
   管理装置を有し、
   前記管理装置は、
   前記視聴要求を受信した前回のアクセス時刻を各々の前記中継装置から受信して、最新の前回のアクセス時刻を各々の前記中継装置に対して送信する、
   ことを特徴とするコンテンツ配信システム。
7. 請求項５に記載されるコンテンツ配信システムであって、
   前記ロケーション識別情報変更処理部は、
   前記コンテンツ情報に対応するファイルにおける前記第１ロケーション識別情報を、当該第１ロケーション識別情報内に前記生成した視聴要求識別情報およびハッシュ関数を用いて計算したハッシュ値を含めた前記第２ロケーション識別情報とした前記第１ファイルに変更する、
   ことを特徴とするコンテンツ配信システム。
8. コンテンツ受信装置から送信されるコンテンツを時分割した時分割コンテンツの視聴要求をコンテンツ配信装置に転送し、前記コンテンツ配信装置から送信される時分割コンテンツを前記コンテンツ受信装置に転送する中継装置の中継方法であって、
   前記中継装置は、
   前記時分割コンテンツに対応する第１ロケーション識別情報内に前記視聴要求を識別する視聴要求識別情報を含む情報である第２ロケーション識別情報を、前記コンテンツ受信装置から視聴要求として受信する第１受信処理ステップと、
   前記視聴要求識別情報を用いて前記視聴要求が所定の条件を満たすことを確認処理する第１確認処理ステップと、
   前記第１確認処理ステップにおける確認処理後に、前記第２ロケーション識別情報から視聴要求識別情報を削除した第１ロケーション識別情報を前記コンテンツ配信装置に送信する第１送信処理ステップと、を有し、
   前記視聴要求識別情報には当該視聴要求の有効期限を示す情報である期限情報が含まれており、
   前記第１確認処理ステップでは、
   前記期限情報を参照して前記視聴要求が有効期限内であるか否かを判定する、
   ことを特徴とする中継方法。
9. コンテンツ受信装置から送信されるコンテンツを時分割した時分割コンテンツの視聴要求をコンテンツ配信装置に転送し、前記コンテンツ配信装置から送信される時分割コンテンツを前記コンテンツ受信装置に転送するコンピュータを、
   前記時分割コンテンツに対応する第１ロケーション識別情報内に前記視聴要求を識別する視聴要求識別情報を含む情報である第２ロケーション識別情報を、前記コンテンツ受信装置から視聴要求として受信する第１受信処理部、
   前記視聴要求識別情報を用いて前記視聴要求が所定の条件を満たすことを確認処理する第１確認処理部、
   前記第１確認処理部における確認処理後に、前記第２ロケーション識別情報から視聴要求識別情報を削除した第１ロケーション識別情報を前記コンテンツ配信装置に送信する第１送信処理部、として機能させ、
   前記視聴要求識別情報には当該視聴要求の有効期限を示す情報である期限情報が含まれており、
   前記第１確認処理部は、
   前記期限情報を参照して前記視聴要求が有効期限内であるか否かを判定する、
   ことを特徴とするプログラム。
10. 請求項９に記載されるプログラムであって、
    前記コンピュータを、
    前記視聴要求識別情報に対応づけて前記視聴要求を受信した前回のアクセス時刻を記憶する第１記憶部として機能させ、
    前記第１確認処理部は、前記有効期限の判定に加えて、
    前回のアクセス時刻からの経過時間が閾値以内である視聴要求の数が所定数より多い場合に、受信した視聴要求の現在の時刻と前回のアクセス時刻との差分が所定時間未満であるか否かを判定する、
    ことを特徴とするプログラム。

Images