(57)【要約】【課題】クライアントから要求されたコンテンツの配信とキャッシュを効率的に行う配信装置、及び配信方法を提供することである。【解決手段】実施形態の配信装置は、格納部と、配信部と、ファイル取得部とを持つ。格納部は、コンテンツのファイルを分割したチャンクファイルのリストが記述されたマニフェストファイルと先頭から一部のチャンクファイルとを格納する。配信部は、クライアント端末からコンテンツの配信要求を受信し、要求されたコンテンツのマニフェストファイルを格納部から読み出して配信する処理と、コンテンツのチャンクファイルの配信要求をクライアント端末から受信し、要求されたチャンクファイルを格納部から読み出して配信する処理とを行う。ファイル取得部は、格納部に格納されていないチャンクファイルを、クライアント端末からコンテンツのチャンクファイルの配信要求を受信する前にストレージ装置から取得して格納部に格納する。【選択図】図３
2015170323.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツのファイルを分割したチャンクファイルのリストが記述されたマニフェストファイルと前記コンテンツの先頭から一部のチャンクファイルとを格納する格納部と、
クライアント端末からコンテンツの配信要求を受信し、受信した前記配信要求により要求された前記コンテンツのマニフェストファイルを前記格納部から読み出して配信する処理と、前記コンテンツのチャンクファイルの配信要求を前記クライアント端末から受信し、受信した前記配信要求により要求された前記チャンクファイルを前記格納部から読み出して配信する処理とを行う配信部と、
要求された前記コンテンツのチャンクファイルのうち前記格納部に格納されていないチャンクファイルを、前記クライアント端末から前記コンテンツのチャンクファイルの配信要求を受信する前にストレージ装置から取得して前記格納部に格納するファイル取得部と、
を備える配信装置。
【請求項２】
前記配信要求により要求された前記コンテンツのマニフェストファイルとチャンクファイルとが前記格納部に格納されているかを認識するコンテンツ存在認識部をさらに備え、
前記ファイル取得部は、前記配信要求により要求された前記コンテンツのマニフェストファイルと一部のチャンクファイルとが前記格納部に格納されていることを前記コンテンツ存在認識部が認識した場合に、前記コンテンツのチャンクファイルのうち前記格納部に格納されていないチャンクファイルを、前記クライアント端末から前記コンテンツのチャンクファイルの配信要求を受信する前にストレージ装置から取得して前記格納部に格納する請求項１に記載の配信装置。
【請求項３】
前記配信部が前記クライアント端末からコンテンツの配信要求を受信した場合に、前記格納部に格納されている前記コンテンツの一部のチャンクファイルのエンコーディング時間の合計よりも短い間、前記コンテンツのキャッシュをロックするキャッシュロック部をさらに備え、
前記ファイル取得部は、前記キャッシュロック部により前記コンテンツのキャッシュがロックされている間、前記ストレージ装置からの前記コンテンツのチャンクファイルの取得を行わない請求項１または請求項２に記載の配信装置。
【請求項４】
前記格納部は、コンテンツのマニフェストファイルと、他のコンテンツのチャンクファイルとを格納し、
前記配信要求により要求された前記コンテンツのマニフェストファイルに記述されているチャンクファイルのリストに対して、前記格納部に記憶されている前記他のコンテンツのチャンクファイルの情報を前記リストの先頭に設定する一時書換部をさらに備え、
前記配信部は、前記一時書換部が書き換えた前記マニフェストファイルを前記クライアント端末へ配信する請求項１から請求項３のいずれか１項に記載の配信装置。
【請求項５】
コンテンツのマニフェストファイルと前記コンテンツの全てのチャンクファイルとを格納するコンテンツ蓄積部と、
前記コンテンツの配信要求数と前記コンテンツの配信要求からの経過時間と前記ストレージ装置から取得すべきあるいは取得済みのチャンクファイルの数とのうち１以上に基づく所定のトリガーの発生を検出した場合に、前記格納部に格納されている前記コンテンツのマニフェストファイル及び前記コンテンツのチャンクファイルを前記コンテンツ蓄積部に移行して格納するコンテンツ蓄積トリガー部とをさらに備える請求項１から請求項４のいずれか１項に記載の配信装置。
【請求項６】
配信装置が実行する配信方法であって、
配信部が、クライアント端末からコンテンツの配信要求を受信し、コンテンツのファイルを分割したチャンクファイルのリストが記述されたマニフェストファイルと前記コンテンツの先頭から一部のチャンクファイルとを格納する格納部から、受信した前記配信要求により要求された前記コンテンツのマニフェストファイルを読み出して配信する処理と、前記コンテンツのチャンクファイルの配信要求を前記クライアント端末から受信し、受信した前記配信要求により要求された前記チャンクファイルを前記格納部から読み出して配信する処理とを行う配信過程と、
ファイル取得部が、要求された前記コンテンツのチャンクファイルのうち前記格納部に格納されていないチャンクファイルを、前記クライアント端末から前記コンテンツのチャンクファイルの配信要求を受信する前にストレージ装置から取得して前記格納部に格納するファイル取得過程と、
を有する配信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、配信装置、及び配信方法に関する。
【背景技術】
【０００２】
映像素材や音声素材などのコンテンツを配信するコンテンツ配信サービスの需要が高まっている。中でも、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）をベースとしたベストエフォート型のネットワーキング技術を基盤インフラとしたフィールドでの配信需要が伸びている。このフィールドでコンテンツ配信サービスを提供するシステムでは、クライアントにコンテンツ配信を行う配信装置を配信ネットワークのエッジ側に多数配置する。これらの配信装置は、管理運用コスト(ランニングコスト)やストレージデバイスの価格などの問題から、配信対象の全てのコンテンツを配置・格納していないことがある。配信装置は、クライアントから要求されたコンテンツを格納していないときには、バックエンド側に配置された中央ストレージ装置へアクセスする。配信装置は、要求されたコンテンツをアクセスした中央ストレージ装置から取得し、キャッシングを行った後、クライアントへコンテンツを配信する。そのため、配信装置がクライアントから要求を受けてからコンテンツを配信するまでに時間を要してしまう場合があった。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００８−２０４０５５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明が解決しようとする課題は、クライアントから要求されたコンテンツの配信とキャッシュを効率的に行う配信装置、及び配信方法を提供することである。
【課題を解決するための手段】
【０００５】
実施形態の配信装置は、格納部と、配信部と、ファイル取得部とを持つ。格納部は、コンテンツのファイルを分割したチャンクファイルのリストが記述されたマニフェストファイルとコンテンツの先頭から一部のチャンクファイルとを格納する。配信部は、クライアント端末からコンテンツの配信要求を受信し、受信した配信要求により要求されたコンテンツのマニフェストファイルを格納部から読み出して配信する処理と、コンテンツのチャンクファイルの配信要求をクライアント端末から受信し、受信した配信要求により要求されたチャンクファイルを格納部から読み出して配信する処理とを行う。ファイル取得部は、要求されたコンテンツのチャンクファイルのうち格納部に格納されていないチャンクファイルを、クライアント端末からコンテンツのチャンクファイルの配信要求を受信する前にストレージ装置から取得して格納部に格納する。
【図面の簡単な説明】
【０００６】
【図１】第１の実施形態のコンテンツ配信システムの全体構成図。
【図２】第１の実施形態のコンテンツ配信システムにおけるコンテンツ配信の流れを示すシーケンス図。
【図３】第１の実施形態の配信装置の構成を示す機能ブロック図。
【図４】第１の実施形態に用いられるマニフェストファイルを示す図。
【図５】第１の実施形態の配信装置の格納部に格納されているチャンクファイルのＵＲＩを示す図。
【図６】第２の実施形態の配信装置の構成を示す機能ブロック図。
【図７】第２の実施形態に用いられるマニフェストファイルを示す図。
【図８】第２の実施形態の広告コンテンツを構成するチャンクファイル群を示す図。
【図９】第２の実施形態の書き換え後のマニフェストファイルを示す図。
【図１０】第４の実施形態に用いられるマニフェストファイルを示す図。
【図１１】第４の実施形態に用いられるマニフェストファイルを示す図。
【図１２】第４の実施形態に用いられるマニフェストファイルを示す図。
【図１３】従来のコンテンツ配信システムにおけるコンテンツのキャッシングの流れを示すシーケンス図。
【図１４】従来のコンテンツ配信システムにおけるキャッシュが完了するまでの処理待ちを示す図。
【図１５】従来のコンテンツ配信システムのキャッシュが存在していない状況におけるコンテンツ配信の流れを示す図。
【発明を実施するための形態】
【０００７】
以下、実施形態の配信装置、及び配信方法を、図面を参照して説明する。
【０００８】
（第１の実施形態）
図１は、本実施形態のコンテンツ配信システムの全体構成図である。同図に示すコンテンツ配信システムは、配信装置１、ストレージ装置３、及びクライアント端末５を備えて構成される。同図においては、配信装置１を複数台示しているが、コンテンツ配信システムは、配信装置１を１台のみ備えてもよい。また、同図においては、ストレージ装置３を１台のみ示しているが、コンテンツ配信システムは、複数台のストレージ装置３を備えてもよい。配信装置１とストレージ装置３は、ＩＰネットワーク８を介して接続される。ＩＰネットワーク８は、専用線などを用いた私設網（私設網は仮想私設網を含む）であってもよく、インターネット網のような公衆網であってもよい。配信装置１と複数のエンドユーザのクライアント端末５とは、ＩＰ（Internet Protocol）ネットワーク９を介して接続される。ＩＰネットワーク９は、インターネット網などの公衆網であるが、私設網であってもよい。クライアント端末５は、有線または無線によりＩＰネットワーク９にアクセスする。コンテンツ配信システムが複数台の配信装置１を備える場合、ＩＰネットワーク９のユーザ側のエッジにロードバランサ７が設けられる。以下では、配信対象のコンテンツが映像コンテンツである場合を例に説明するが、コンテンツは、音声データなど他の種類のコンテンツでもよい。
【０００９】
ストレージ装置３は、コンテンツを蓄積するバックエンド側のオリジンサーバである。ストレージ装置３は、１台または複数台で、コンテンツ配信サービスによる配信対象の全てのコンテンツを格納する。配信装置１は、エッジ側のサーバであり、クライアント端末５へコンテンツをストリーミング配信する。配信装置１は、コンテンツ配信サービスによる配信対象コンテンツのうち一部のコンテンツを格納している。クライアント端末５は、コンテンツを再生する装置である。クライアント端末５は、例えば、パーソナルコンピュータ（ＰＣ）、ＩＰテレビジョン受信機（ＩＰＴＶ）、ＳＴＢ（セット・トップ・ボックス）、スマートフォン、タブレット端末などである。エンドユーザは、コンテンツの視聴者である。ロードバランサ７は、クライアント端末５から配信装置１へのアクセスを分散させる。
【００１０】
図１に示すコンテンツ配信システムは、ＴＣＰ／ＩＰをベースとしたベストエフォート型のネットワーキング技術を基盤インフラとしている。ロードバランサ７は、回線の高速化・安定化（冗長化）などの施策として設けられる。ロードバランサ７は、各配信装置１や配信Ｉ／Ｆ（インタフェース）単位での負荷を分散する。負荷分散を目的としたロードバランサ７は、クライアント端末５から各配信装置１への接続数（トラフィック数）を管理する。しかし、ロードバランサ７は、どのようなコンテンツが各配信装置１に配置され、格納されているのかは管理していない。よって、負荷を分散することを目的としてロードバランサ７が再割り当てした宛先の配信装置１は、エンドユーザが期待していたコンテンツを配置・格納していない場合もある。その度に、配信装置１は、バックエンド側に配置されたストレージ装置３へアクセスしてコンテンツを取得し、キャッシングする。各配信装置１が全てのコンテンツを格納することによりこのような課題は解決するが、管理運用コスト(ランニングコスト)やストレージデバイスの価格などから、この施策は現実的ではない。
【００１１】
コンテンツが配置・格納されている可能性が高い配信装置１にクライアント端末５からの配信要求をリダイレクトした場合、ロードバランサ７による負荷分散に意味や価値がなくなってしまう。また、いずれにしろ、配信装置１は、１回はキャッシュをするために、コンテンツが配置・格納されているストレージ装置３へのアクセスが必要となる。これらのことから、実運用上、または実運用における現実的な装置の配置解が、図１に示す構成である。つまり、ＩＰネットワーク９（配信ネットワーク）のエッジ側に、クライアント端末５に対してコンテンツを配信する廉価的な配信装置１を多数配置する。ＩＰネットワーク９の中心側及びバックエンド側には、コンテンツの蓄積及び確保を主目的として、配信装置１に対してコンテンツを配信するストレージ装置３を少数配置する。そしてロードバランサ７により、クライアント端末５から配信装置１へのアクセスの負荷分散を行う。
【００１２】
一般的にＶＯＤ（Video On Demand）における映像配信の方法は、以下の２つに大別される。１つは、ＲＴＳＰ（Real Time Streaming Protocol）／ＲＴＰ（Real-Time Transport Protocol）のスキームによる配信方法である。この配信方法は、クライアント端末５から配信装置１に対する素材（コンテンツ）の配信要求から始まる。もう１つは、ＨＴＴＰ（Hypertext Transfer Protocol）のスキームによる配信方法である。この配信方法は、クライアント端末５から配信装置１に対する素材（コンテンツ）のマニフェストファイル（「プレイリスト」ともいうが、以下では「マニフェストファイル」と記載する。）の配信要求から始まる。
前者はＩＰＴＶ(Internet Protocol TeleVision)フォーラムを代表格とした規格化が存在してはいるが、全世界的に見ると規模は小さい。一方、後者はＯＴＴ（Over-The-Top）である。ＯＴＴは、パブリック且つスタンダードな規格が定められているわけではない。しかし、ＯＴＴは、デファクトとして浸透しつつあり、世界規模は大きい。本実施形態では、ＯＴＴを対象とする。
【００１３】
ここで、本実施形態の配信装置の技術的な特徴を明確にするために、従来のコンテンツ配信システムについて説明する。
図１３は、従来のコンテンツ配信システムにおけるコンテンツのキャッシングの流れを示すシーケンス図である。従来のコンテンツ配信システムは、図１に示す本実施形態の配信装置１に代えて、配信装置９１を有する。配信装置９１は、プロキシキャッサーバである。配信装置９１は、ストレージ装置３が蓄積しているコンテンツのうち一部を蓄積していてもよく、コンテンツを蓄積していなくともよい。同図では、２台のクライアント端末５をそれぞれ、クライアント端末５−１、クライアント端末５−２と記載している。
【００１４】
クライアント端末５−１は、コンテンツ（例えば、映像コンテンツＡ）の配信要求であるＨＴＴＰのＧＥＴ要求を、ＩＰネットワーク９を介して配信装置９１に送信する（ステップＳ８０５）。配信装置９１は、ＧＥＴ要求により配信が要求されたコンテンツをキャッシュしていないと判断した場合（ステップＳ８１０）、キャッシュを実施するために、配信が要求されたコンテンツのＧＥＴ要求をストレージ装置３へ送信する（ステップＳ８１５）。ストレージ装置３は、ＧＥＴ要求への応答として、配信が要求されたコンテンツを配信装置９１へ配信する（ステップＳ８２０）。配信装置９１は、ストレージ装置３から受信したコンテンツをキャッシュする（ステップＳ８２５）。配信装置９１は、ＧＥＴ要求への応答として、キャッシュしたコンテンツをクライアント端末５−１へ配信する（ステップＳ８３０）。
【００１５】
クライアント端末５−２は、コンテンツ（例えば、映像コンテンツＡ）の配信要求であるＧＥＴ要求を、ＩＰネットワーク９を介して配信装置９１に送信する（ステップＳ８３５）。配信装置９１は、ＧＥＴ要求により配信が要求されたコンテンツをキャッシュしていると判断する（ステップＳ８４０）。配信装置９１は、バックエンド側にコンテンツを要求することなく、キャッシュしているコンテンツをクライアント端末５−２に配信する（ステップＳ８４５）。
【００１６】
図１４は、従来のコンテンツ配信システムにおけるキャッシュが完了するまでの処理待ちを示す図である。同図において、図１３に示す処理と同一の処理には、同一の符号を付している。
配信装置９１は、クライアント端末５−１からＧＥＴ要求を受信する（ステップＳ８０５）。配信装置９１は、ＧＥＴ要求により配信が要求されたコンテンツをキャッシュしていないと判断した場合（ステップＳ８１０）、図１３のステップＳ８１５からステップＳ８３０の処理を行い、クライアント端末５−１にコンテンツを配信する。配信装置９１は、クライアント端末５−１から受信したＧＥＴ要求の処理中に、別のクライアント端末５−２からＧＥＴ要求を受信した場合（ステップＳ８１２）、その要求を実行できない場合がある。
【００１７】
その一例としては、クライアント端末５−２から要求されたコンテンツが、クライアント端末５−１から要求されたコンテンツと同一であり、且つ、要求を受けた時点で配信装置１がそのコンテンツを蓄積・格納していない事による「待ち」に他ならない。もちろん、「待ち時間」という点では、先に要求を行ったクライアント端末５−１に対する「待ち時間」よりも、後から要求を行ったクライアント端末５−２に対する「待ち時間」の方が短いことが見込まれる。これは、先に行われたクライアント端末５−１からの要求によって、配信装置１にコンテンツがキャッシュされることによる。ただしこれは、クライアント端末５−１に対する「待ち時間」の改善には繋がらない。
【００１８】
図１５は、キャッシュが存在していない状況における従来のコンテンツ配信システムのコンテンツ配信の流れを示す図である。同図では、ＨＴＴＰによるＶＯＤ配信を示している。コンテンツは、マニフェストファイルと、映像コンテンツの動画ファイルを分割した一連のチャンクファイルとからなる。マニフェストファイルには、チャンクファイルのリストや、それらチャンクファイルの保存場所の情報が含まれる。保存場所の情報には、例えば、ＵＲＬ（Universal Resource Locator）やＵＲＩ（Universal Resource Identifier）が用いられる。
【００１９】
クライアント端末５は、映像コンテンツのマニフェストファイルのＧＥＴ要求を、ＩＰネットワーク９を介して配信装置９１に送信する（ステップＳ９０５）。配信装置９１は、ＧＥＴ要求により配信が要求されたマニフェストファイルをキャッシュしていないと判断した場合（ステップＳ９１０）、配信が要求されたマニフェストファイルのＧＥＴ要求をストレージ装置３へ送信する（ステップＳ９１５）。ストレージ装置３は、ＧＥＴ要求への応答として、配信が要求されたマニフェストファイルを配信装置９１へ配信する（ステップＳ９２０）。配信装置９１は、ストレージ装置３から受信したマニフェストファイルをキャッシュする（ステップＳ９２５）。配信装置１は、ＧＥＴ要求への応答として、キャッシュしたマニフェストファイルをクライアント端末５−１へ配信する（ステップＳ９３０）。
【００２０】
クライアント端末５は、マニフェストファイルを解釈してチャンクファイルを識別する（ステップＳ９３５）。クライアント端末５は、マニフェストファイルに記述された先頭のチャンクファイルのＧＥＴ要求を、ＩＰネットワーク９を介して配信装置９１に送信する（ステップＳ９４０）。配信装置９１は、ＧＥＴ要求により配信が要求されたチャンクファイルをキャッシュしていないと判断した場合（ステップＳ９４５）、配信が要求されたチャンクファイルのＧＥＴ要求をストレージ装置３へ送信する（ステップＳ９５０）。
【００２１】
上記のように、ＨＴＴＰのスキームは、クライアント端末５が素材（コンテンツ）のマニフェストファイルの配信要求を送信することから始まる。そして、このＨＴＴＰのスキームによれば、配信装置９１が自装置に該当コンテンツが存在していないことを認識する処理は、まずマニフェストファイルが存在していないことの認知から始まる。
【００２２】
図１３、図１４に示す従来のコンテンツデータのキャッシングの流れは、図１に示す本実施形態のコンテンツ配信システムにおいても同様である。本実施形態のコンテンツ配信システムは、この流れにおいて、通信の効率を向上し、素早いレスポンスとキャッシュを行う。
【００２３】
なお、上述したように、マニフェストファイルには、映像素材の動画ファイルであるチャンクファイルのリストや各チャンクファイルの保存場所の情報が含まれる。このマニフェストファイルをうまく利用したものとして、コンテンツの要求を受けた配信装置にそのコンテンツ（素材）が存在していないときの回避伝達策である「リダイレクト」方法がある。しかし、この「リダイレクト」方法を用いることはロードバランサ７による負荷分散を無意味なものとしてしまう。そのため、本実施形態では、リダイレクト方法を用いない。
【００２４】
図２は、本実施形態のコンテンツ配信システムにおけるコンテンツ配信の流れを示すシーケンス図である。
ストレージ装置３は、映像コンテンツＡ、Ｂ、及びＣのそれぞれについて、マニフェストファイルおよび映像素材の全てのチャンクファイルを完全な形で格納している。映像コンテンツＣの全チャンクファイルは、チャンクファイルＣ１からチャンクファイルＣ１０までである。一方、配信装置１は、映像コンテンツＣのマニフェストファイルＣｍと、番組本編の先頭からの一部のチャンクファイルＣ１−Ｃ３を格納（キャッシュ）している。
【００２５】
クライアント端末５は、映像コンテンツＣのマニフェストファイルＣｍのＧＥＴ要求を、ＩＰネットワーク９を介して配信装置１に送信する（ステップＳ１０５）。配信装置１は、ＧＥＴ要求により配信が要求されたマニフェストファイルＣｍを保持しているか否かを判断する（ステップＳ１１０）。配信装置１は、マニフェストファイルＣｍを保持しているため、映像コンテンツＣを保持していると判断する。配信装置１は、自装置に保持している映像コンテンツＣのチャンクファイル数を認識する（ステップＳ１１５）。配信装置１は、ステップＳ１０５において受信したＧＥＴ要求により配信が要求されたマニフェストファイルＣｍをクライアント端末５へ配信する（ステップＳ１２０）。さらに、配信装置１は、ステップＳ１０５のＧＥＴ要求を受信してからキャッシュロック時間経過後、ステップＳ１１５において自装置に保持していないと判断した４つめ以降のチャンクファイルＣ４からチャンクファイルＣ１０を順次、ストレージ装置３に要求する。つまり、配信装置１は、チャンクファイルＣ４のＧＥＴ要求をストレージ装置３へ送信する（ステップＳ１２５）。ストレージ装置３は、ＧＥＴ要求への応答として、配信が要求されたチャンクファイルＣ４を配信装置１へ配信する（ステップＳ１３０）。配信装置１は、ストレージ装置３から受信したチャンクファイルＣ４をキャッシュする（ステップＳ１３５）。その後、配信装置１は、チャンクファイルＣ５、Ｃ６、…、Ｃ１０について順に、ステップＳ１２５からステップＳ１３５と同様の処理を繰り返す（ステップＳ１４０からステップＳ１５０）。
【００２６】
一方、クライアント端末５は、ステップＳ１２０において配信装置１から受信したマニフェストファイルＣｍを解釈してチャンクファイルを識別する（ステップＳ１５５）。クライアント端末５は、マニフェストファイルＣｍのチャンクファイルリストに記述されている順にチャンクファイルを要求する。従ってまず、クライアント端末５は、チャンクファイルＣ１のＧＥＴ要求を、ＩＰネットワーク９を介して配信装置１に送信する（ステップＳ１６０）。配信装置１は、ＧＥＴ要求により配信が要求されたチャンクファイルＣ１をクライアント端末５に配信する（ステップＳ１６５）。その後、クライアント端末５は、チャンクファイルＣ２、Ｃ３、…、Ｃ１０について順に、ステップＳ１６０からステップＳ１６５と同様の処理を繰り返す（ステップＳ１７０からステップＳ１９５）。なお、クライアント端末５は、再生中のチャンクファイルが終了する前に、次のチャンクファイルがデコード済みとなっているような任意のタイミングでチャンクファイルを要求する。チャンクファイルＣ１からチャンクファイルＣ３は、ステップＳ１０５においてクライアント端末５からマニフェストファイルＣｍのＧＥＴ要求を受信する前に配信装置１が蓄積していたファイルである。チャンクファイルＣ４からチャンクファイルＣ１０は、マニフェストファイルＣｍのＧＥＴ要求を受信した後に配信装置１がストレージ装置３から読み出してキャッシュしたファイルである。
【００２７】
上記手順により、配信装置１は、まずマニフェストファイルと先頭から所定数のチャンクファイルをクライアント端末５へ配信する。配信装置１は、この配信の間に、自装置が格納していない残りのチャンクファイルを、クライアント端末５から配信要求を受ける前にストレージ装置３から取得してキャッシュする。配信装置１は、クライアント端末５からチャンクファイルの配信要求を受けると、キャッシュしていたチャンクファイルを配信する。よって、配信装置１は、クライアント端末５から要求されたコンテンツの配信とキャッシュを効率的に行うことができる。
【００２８】
図３は、配信装置１の構成を示す機能ブロック図であり、本実施形態と関係する機能ブロックのみを抽出して示してある。同図に示すように、配信装置１は、格納部１１−１、格納部１１−２、エッジ側送受信部１２、キャッシュロック部１３、コンテンツ存在認識部１４、チャンクファイル数認識部１５、バックエンド側送受信部１６、及びコンテンツ蓄積トリガー部１７を備えて構成される。
【００２９】
格納部１１−１は、コンテンツの蓄積及び格納を主目的とするストレージデバイスである。格納部１１−１は、例えば、ＳＳＤ（Solid State Drive）の記憶領域である。格納部１１−１は、マニフェストファイルと全チャンクファイルとからなるコンテンツを格納する。なお、初期状態において、格納部１１−１は、コンテンツを蓄積していなくともよい。
格納部１１−２は、コンテンツのマニフェストファイルと、そのコンテンツの先頭から数個分のチャンクファイル（コンテンツの本編全部ではない）を格納する。格納部１１−２は、例えば、ＳＤＲＡＭ（Synchronous Dynamic Random Access Memory：シンクロナスランダムアクセスメモリ）のようなメモリデバイスの格納領域である。なお、初期状態において、格納部１１−２は、配信対象のコンテンツ全てあるいは一部のコンテンツについて、マニフェストファイルと先頭から数個分のチャンクファイルを格納している。
【００３０】
格納部１１−１と格納部１１−２は、論理的に記憶領域が分かれていることを表している。そのため、識別可能であれば、格納部１１−１と格納部１１−２が、物理的には同じ記憶装置であっても構わない。例えば、格納部１１−１と格納部１１−２を、ＳＤＲＡＭの別の記憶領域としてもよい。格納部１１−１がＳＳＤのようなストレージデバイスの格納領域であり、格納部１１−２がＳＤＲＡＭのようなメモリデバイスの格納領域であるという例は、単に「格納部１１−２の処理速度」>>「格納部１１−１の処理速度」を考慮したものである。
【００３１】
エッジ側送受信部１２は、ＩＰネットワーク９を介してクライアント端末５との間のデータを送受信するためのインタフェースである。バックエンド側送受信部１６は、ストレージ装置３との間のデータを送受信するためのインタフェースである。
【００３２】
キャッシュロック部１３は、コンテンツ配信要求の集約化、及び、コンテンツ配信要求の時間バッファリングを行う。コンテンツ存在認識部１４は、自装置に、クライアント端末５から配信が要求されたコンテンツを構成するデータが存在しているか否かを認識する。チャンクファイル数認識部１５は、クライアント端末５から配信が要求されたコンテンツのチャンクファイルを先頭から何番目まで自装置が保持しているかを認識する。コンテンツ蓄積トリガー部１７は、所定のトリガーが発生した場合に、一時的にしろ格納部１１−２が保持していたコンテンツのマニフェストファイル及び全チャンクファイルを読み出して、格納部１１−１に蓄積する。
【００３３】
続いて、配信装置１の処理を詳細に説明する。
図３に示すように、配信装置１の格納部１１−１は、映像コンテンツＡと映像コンテンツＢを構成する全てのデータを記憶している。つまり、格納部１１−１は、映像コンテンツＡ、Ｂのそれぞれを、マニフェストファイルおよび映像素材の全てのチャンクファイルが揃った完全な形で格納している。一方、格納部１１−２は、映像コンテンツＣのマニフェストファイルと先頭から数個分のチャンクファイルのデータのみを格納している。つまり、映像コンテンツＣの本編全部を構成するチャンクファイルが格納部１１−２に格納されているものではない。
【００３４】
このような形態・状態・状況は、実運用においては大いに考えられる。具体的なイメージを想起させるための一例をあげる。映像コンテンツＡや映像コンテンツＢは人気コンテンツであり、常にエンドユーザから視聴要求が行われるようなコンテンツである。運用上、このようなコンテンツが全ての配信装置１に格納されている事は、配信サービスを行っている事業者に期待される。そのため、配信装置１は、順次、コンテンツを人気順に、可能な限り格納していく。その一方で、人気の度合いが未知数である新規配給コンテンツや、ニッチ向けあるいはマニア向けのコンテンツを配信装置１に格納しておくか否かについては、配信装置１が単体で蓄積可能なストレージ領域の容量や残量に依存する。本実施形態では、このようなコンテンツを全般的に映像コンテンツＣと同義と位置付けている。このようにコンテンツを構成する全てのデータ（マニフェストファイルおよび映像素材の全てのチャンクファイル）が揃っていない状態は、配信装置１の一般的な状況である。配信装置１は、通常の処理手順に従い、バックエンド側のストレージ装置３に対して、データ取得のためのアクセス処理を行う。
【００３５】
配信装置１は、以下に示す処理１〜処理５を実行する。
まず、配信装置１は、マニフェストファイルの配信要求受信処理を行う（処理１）。
配信装置１のエッジ側送受信部１２は、クライアント端末５からコンテンツの配信要求を受信する。クライアント端末５は、必ず一番初めにマニフェストファイルを要求し、最初には、映像素材のチャンクファイルをダイレクトに指定した要求を行わない。仮にそのような事がありうる場合の施策や対策としては、以下がある。すなわち、エッジ側送受信部１２は、クライアント端末５から要求されたメッセージにマニフェストファイルのファイル拡張子の記述があるか否を判断する。マニフェストファイル以外の拡張子の記述があった場合、さらに、エッジ側送受信部１２は、予め設定された拡張子がフィルタ（例えば、チャンクファイルの拡張子）とマッチしているか否かを判断する。このように、チャンクファイルをダイレクトに指定した要求の回避は、比較的容易に可能である。
【００３６】
処理１に続いて、配信装置１は、キャッシュロック処理を行う（処理２）。
キャッシュロック部１３は、処理１において要求されたマニフェストファイルに対応するコンテンツを自装置が蓄積しているか否かについては一旦保留とし、クライアント端末５からコンテンツの配信要求があったと判断する。キャッシュロック部１３は、配信が要求されたコンテンツの情報を、自身が記憶するテーブルに保持し、コンテンツ存在認識部１４を稼働させる。テーブルに登録する情報には、例えば、要求されたマニフェストファイルのファイル名などを用いることができる。テーブルにコンテンツの情報が登録されている間、配信装置１は、そのコンテンツのチャンクファイルの配信要求をストレージ装置３へ送信しない。
【００３７】
処理２に続いて、配信装置１は、コンテンツの存在確認処理を行う（処理３）。
コンテンツ存在認識部１４は、キャッシュロック部１３から起動されると、大きく以下の２つの認識処理を行う。１つめの認識処理（認識処理Ａ）は、格納部１１−１と格納部１１−２に、クライアント端末５から要求されたコンテンツが格納されているか否かを認識する処理である。２つめの認識処理（認識処理Ｂ）は、格納部１１−２にクライアント端末５から要求されたコンテンツが格納されている場合、先頭から何番目までのチャンクファイルのデータを保持しているかを認識する処理である。
【００３８】
コンテンツ存在認識部１４が認識処理Ａを行う場合の探索の順序は、「格納部１１−１⇒格納部１１−２」であってもよく、「格納部１１−２⇒格納部１１−１」であってもよく、特に制約はない。ここでは説明を簡略化するために、「格納部１１−１⇒格納部１１−２」の順番であるとする。
【００３９】
また更に、格納部１１−２以外に、コンテンツのマニフェストファイルと先頭から数個分のチャンクファイルのデータのみを格納している格納部１１−３、格納部１１−４、…が存在しても、コンテンツ存在認識部１４が探索を行う領域として登録されてさえいれば構わない。例えば、「格納部１１−１⇒格納部１１−２⇒格納部１１−３⇒…⇒格納部１１−Ｋ」を行う場合、認識処理Ａの詳細は以下の探索処理Ａ−１から探索処理Ａ−Ｋとなる。
【００４０】
探索処理Ａ−１において、コンテンツ存在認識部１４は、格納部１１−１を探索する。格納部１１−１にコンテンツが存在する場合、コンテンツ存在認識部１４は、通常の配信処理を実行する。格納部１１−１にコンテンツが存在しない場合、コンテンツ存在認識部１４は、次の探索ステップ（探索処理Ａ−２）に移行する。
【００４１】
探索処理Ａ−２において、コンテンツ存在認識部１４は、格納部１１−２を探索する。格納部１１−２にコンテンツが存在する場合、コンテンツ存在認識部１４は、クライアント端末５への配信処理を実行しつつ、バックエンド側ではキャッシュ取得準備を進める。格納部１１−２にコンテンツが存在しない場合、コンテンツ存在認識部１４は、次の探索ステップ（探索処理Ａ−３）に移行する。
【００４２】
探索処理Ａ−３において、コンテンツ存在認識部１４は、格納部１１−３を探索する。格納部１１−３にコンテンツが存在する場合、コンテンツ存在認識部１４は、クライアント端末５への配信処理を実行しつつ、バックエンド側ではキャッシュ取得準備を進める。格納部１１−３にコンテンツが存在しない場合、コンテンツ存在認識部１４は、次の探索ステップに移行する。
【００４３】
探索処理Ａ−４から探索処理Ａ−（Ｋ−１）において、コンテンツ存在認識部１４は、格納部１１−４から格納部１１−（Ｋ−１）のそれぞれについて上記の探索処理Ａ−２、Ａ−３と同様の処理を行う。
【００４４】
探索処理Ａ−Ｋにおいて、コンテンツ存在認識部１４は、格納部１１−Ｋを探索する。格納部１１−Ｋにコンテンツが存在する場合、コンテンツ存在認識部１４は、クライアント端末５への配信処理を実行しつつ、バックエンド側ではキャッシュ取得準備を進める。最後の探索領域である格納部１１−Ｋの走査・探索でもコンテンツが存在しなかった場合、コンテンツ存在認識部１４は、従来技術と同様のバックエンド側に対するキャッシュ取得処理を行い、ストレージ装置３にデータ取得のアクセス処理を実行する。
【００４５】
例えば、処理１においてクライアント端末５から映像コンテンツＡが要求された場合、探索処理Ａ−１においてコンテンツ存在認識部１４は、要求されたコンテンツが格納部１１−１に存在すると判断し、通常の配信処理を行う。つまり、エッジ側送受信部１２は、要求された映像コンテンツＡのマニフェストファイルを格納部１１−１から読み出し、クライアント端末５に送信する。そして、バックグラウンドでキャッシュロック部１３は、映像コンテンツＡの情報をテーブルからクリアする。その後、エッジ側送受信部１２は、クライアント端末５から映像コンテンツＡのチャンクファイルの配信要求を受信すると、要求されたチャンクファイルを格納部１１−１から読み出して配信する。
【００４６】
探索処理Ａ−ｋ（ｋは２からＫのいずれか）において「格納部１１−ｋにコンテンツが存在する場合」に、コンテンツ存在認識部１４が、「配信処理を実行しつつ、バックエンド側ではキャッシュ取得準備を進める」処理は同じである。この処理は、コンテンツ存在認識部１４のサブブロックであるチャンクファイル数認識部１５が実行する。
【００４７】
なお、キャッシュロック部１３が、処理２の前に、要求されたコンテンツのエントリが既にコンテンツ存在認識部１４のテーブルに存在するか否か、また、エントリが存在していた場合に、キャッシュ行為の実行中であるか否かを検索する処理を加えてもよい。これにより、無駄・無用に、配信装置１がバックエンド側に対してデータ取得のアクセス処理を実行しないように抑制する事が可能になる。
【００４８】
処理３において、コンテンツ存在認識部１４が、要求されたコンテンツは格納部１１−１に存在していないと判断した場合、配信装置１のバックエンド側送受信部１６は、バックエンドへの配信要求処理を行う（処理４）。なお、配信装置１が格納部１１−１から格納部１１−Ｋを備える場合は、以下の説明において、格納部１１−２を、格納部１１−ｋ（ｋは２からＫのいずれか）とすればよい。
【００４９】
処理３において、コンテンツ存在認識部１４が、要求されたコンテンツは格納部１１−１、１１−２のいずれにも存在していないと判断した場合、配信装置１は、従来技術と同様にバックエンド側に対してデータ取得のアクセス処理を行う。つまり、バックエンド側送受信部１６は、要求されたマニフェストファイルの配信要求をストレージ装置３へ送信する。そして、バックグラウンドでキャッシュロック部１３は、配信が要求されたコンテンツの情報を保持しているテーブルの内容を更新する。つまり、キャッシュロック部１３は、キャッシュが必要なコンテンツであることを記録として登録するため、キャッシュ行為の実行中であることを示す情報をテーブルに保持する。バックエンド側送受信部１６は、ストレージ装置３から配信されたマニフェストファイルを格納部１１−２にキャッシュ（格納）する。エッジ側送受信部１２は、キャッシュしたマニフェストファイルを格納部１１−２から読み出してクライアント端末５に送信する。その後、エッジ側送受信部１２がクライアント端末５からチャンクファイルの配信要求を受信すると、バックエンド側送受信部１６は、要求されたチャンクファイルをストレージ装置３から取得して格納部１１−２にキャッシュする。エッジ側送受信部１２は、キャッシュされたチャンクファイルを格納部１１−２から読み出してクライアント端末５に送信する。
【００５０】
一方、処理３において、コンテンツ存在認識部１４が、要求されたコンテンツは格納部１１−２に存在すると判断した場合、配信装置１は、配信処理を実行しつつ、バックエンド側ではキャッシュ取得準備を進める。具体的には、チャンクファイル数認識部１５は、該当コンテンツの先頭から何番目までのチャンクファイルのデータを格納部１１−２が保持しているのかを認識する。チャンクファイル数認識部１５は、格納部１１−２が保持していないチャンクファイルのキャッシュ取得処理を実行するようバックエンド側送受信部１６に指示する。例として、要求された映像コンテンツＣのマニフェストファイル、及びチャンクファイルとして、図４に示すマニフェストファイルと、図５に示すＵＲＩのチャンクファイルが格納部１１−２に存在している場合を説明する。
【００５１】
図４は、マニフェストファイルの一例を示す図である。マニフェストファイルには、チャンクファイルリストやチャンクファイルの保存場所の情報が含まれる。チャンクファイルリストは、映像素材の動画ファイルであるチャンクファイルの一連リストである。チャンクファイルの保存場所は、例えば、ＵＲＩにより示される。さらに、マニフェストファイルには、その他拡張情報としてコンテンツの番組尺長やタイトルなどが記述される。「EXT-X-TARGETDURATION:10」は、１０秒毎のチャンクファイルに分割されていることを示す。また、「#EXTINF:10」は、チャンクファイルが１０秒の動画のファイルであることを示す。このように、マニフェストファイルは、動画ファイルそのものでは無い。
【００５２】
図５は、格納部１１−２が格納しているチャンクファイルのＵＲＩを示す図である。図４に示すマニフェストファイルには、該当コンテンツを構成するチャンクファイルが、chunk-1.tsからchunk-6.tsであることが記述されている。チャンクファイル数認識部１５は、図５に示すチャンクファイルのＵＲＩから、格納部１１−２に存在しているチャンクファイルが、先頭から２番目までのchunk-1.tsとchunk-2.tsであることを認識する。さらに、チャンクファイル数認識部１５は、配信装置１にはchunk-3.tsから最後のchunk-6.tsまでのチャンクファイルが不足している事を認識する。バックエンド側送受信部１６は、コンテンツ存在認識部１４が不足していると認識したchunk-3.tsから最後のchunk-6.tsまでのチャンクファイルをストレージ装置３から取得する処理を行う。バックエンド側送受信部１６は、この取得処理をバッファアンダーランが発生しない程度の処理速度で実行すればよい。バックエンド側送受信部１６は、既に自装置に保持しているマニフェストファイルや、先頭から２番目までのチャンクファイルchunk-1.ts、chunk-2.tsの取得処理を改めて行う必要はない。
【００５３】
ここで、一つのマニフェストファイルとＮ個のチャンクファイルから構成されるコンテンツがあるとする。コンテンツを構成する全要素Ｎ個のチャンクファイルの内、先頭からｎ番目までのチャンクファイルが配信装置１の格納部１１−２に格納されていたとする。このｎ個は、全要素Ｎ個に対して、１＜ｎ＜＜Ｎの関係が保たれているとし、各チャンクファイルは平均してＳ秒程度のエンコーディングデータであるとする。各チャンクファイルの取得処理をバッファアンダーランが発生しない程度の処理速度で実行するとは、Ｓ秒以内にストレージ装置３にコンテンツを要求し、取得するまでの処理を完了するように調整する事である。配信装置１に先頭からｎ番目までのチャンクファイルが格納されている場合、配信装置１は、ｎ×Ｓ秒の映像尺分（エンコーディング時間の合計）のデータを保持している事になる。そこで、キャッシュロック部１３は、要求されたコンテンツの情報をテーブルに保持しておく時間を、ｎ×Ｓ秒間よりも短い時間とする。コンテンツの情報がテーブルに保持されている時間は、該当コンテンツの要求に対するロック時間である。バックエンド側送受信部１６は、テーブルにコンテンツの情報が保持されている間は、該当コンテンツの配信要求を他のクライアント端末５から受信しても、ストレージ装置３からの当該コンテンツのチャンクファイルの取得を行わない。なお、信頼性・安全性を鑑み、実運用としては、ロック時間を（ｎ−１）×Ｓ秒以下の時間としてもよい。
【００５４】
エッジ側送受信部１２は、マニフェストファイルを配信した後、クライアント端末５からチャンクファイルの配信要求を受信し、マニフェストファイルの配信要求の受信時に既に保持していたチャンクファイルを格納部１１−２から読み出して配信している。その処理のバックエンドで、ロック時間の経過後、バックエンド側送受信部１６は、テーブルに登録されているコンテンツに不足しているチャンクファイルの取得要求をストレージ装置３に送信する。バックエンド側送受信部１６は、要求したチャンクファイルをストレージ装置３から取得して格納部１１−２にキャッシュする。エッジ側送受信部１２は、マニフェストファイルの配信要求の受信時に既に保持していたチャンクファイルを全て配信した後、さらに、クライアント端末５からチャンクファイルの配信要求を受信する。エッジ側送受信部１２は、マニフェストファイルの配信要求を受信した後にキャッシュしたチャンクファイルを格納部１１−２から読み出してクライアント端末５に送信する。
【００５５】
ロック時間（ｎ×Ｓ秒未満）を時間的なプールと捉えると、このロック時間の間に異なるクライアント端末５から受信した同一コンテンツの配信要求数Ｒの全ては、バックエンド側のストレージ装置３に対しての１本の配信要求に集約する事ができる。つまり、配信装置１は、テーブルに登録されているコンテンツに対して複数のクライアント端末５からマニフェストファイルの配信要求を受信しても、不足しているチャンクファイルをストレージ装置３に要求する一連の処理を複数回実行することはない。内部処理において比較的前段部であるキャッシュロック部１３において早期に要求を集約しておくことは、配信装置１における全体的な処理負荷を抑制する効果も期待できる。
【００５６】
その一方で、逆の考え方にも通じる。それは「要求の予測（事前キャッシュ）」になるということである。本実施形態で対象としているＨＴＴＰによるＶＯＤ映像配信では、クライアント端末５は、まず一番初めにマニフェストファイルを要求し、そのマニフェストファイルに列挙されたチャンクファイル（ＵＲＩ）を順次要求する。一般的に考えて「マニフェストファイルの要求」＝「映像視聴の要求」に繋がる。引いては、コンテンツの最後のＮ番目のチャンクファイルまで要求されることが容易に想像できる。この事から、クライアント端末５から、格納部１１−２に存在しているマニフェストファイルが要求された時点で、近い未来（ｎ＋１）番目から最後のＮ番目までのチャンクファイルも要求される事も当然ながら容易に想像できる。
【００５７】
そこで、本実施形態の可変形態としては以下が考えられる。つまり、バックエンド側送受信部１６は、クライアント端末５から格納部１１−２に存在しているｎ番目のマニフェストファイルが要求された時点で、その時点ではまだ保持していない（ｎ＋１）番目以降のチャンクファイルの要求をバックエンド側に対して順次実行する。
【００５８】
以上の処理１から処理４が、配信装置１におけるコンテンツ配信処理である。
さらに、配信装置１は、キャッシュデータの保存処理を行う（処理５）。
コンテンツ蓄積トリガー部１７は、所定のトリガーが発生した場合に、格納部１１−２に保持していたコンテンツのキャッシュデータを格納部１１−１へ移行して、蓄積・保存する。例えば、トリガーは、コンテンツの配信要求数、キャッシュ数、経過時間のうち１以上の情報を用いて検出される。コンテンツの配信要求数、及び経過時間は、キャッシュロック部１３から通知される。また、キャッシュ数は、これからストレージ装置３から取得してキャッシュすべき、あるいは、ストレージ装置３から取得して現在キャッシュしているチャンクファイルの数であり、チャンクファイル数認識部１５から通知される。
【００５９】
具体的な例として、コンテンツ蓄積トリガー部１７は、コンテンツが最初にリクエストされてから現在までの経過時間におけるリクエスト数から単位時間当たりのリクエスト数を算出し、算出結果が所定以上である場合を、そのコンテンツを移行するトリガーとする。また、コンテンツ蓄積トリガー部１７は、最後にコンテンツがリクエストされてから現在までの経過時間が所定以上である場合を、そのコンテンツを移行するトリガーとする。また、あるいは、コンテンツ蓄積トリガー部１７は、これからキャッシュすべきキャッシュ数、または、現在キャッシュしているキャッシュ数が所定以上である場合、現在キャッシュしているコンテンツを移行するトリガーとする。
コンテンツ蓄積トリガー部１７は、格納部１１−２から格納部１１−１へのコンテンツのキャッシュデータの移行を完了すると、移行が完了したコンテンツのキャッシュデータを格納部１１−２から破棄、あるいは、削除する。
【００６０】
なお、コンテンツ蓄積トリガー部１７は、格納部１１−２にコンテンツのマニフェストファイルと先頭から所定数分のチャンクファイルをそのまま格納しておき、格納部１１−１に残りのチャンクファイルを移行して格納するようにしてもよい。
【００６１】
本実施形態によれば、配信装置１は、クライアント端末５からコンテンツの配信要求を受信すると、保持しているマニュフェストファイル及びチャンクファイルの配信処理を実行する。配信装置１は、この配信処理を実行しつつ、バックエンド側では不足しているチャンクファイルをストレージ装置３から取得し、キャッシュする。よって、配信装置１は、効率的に配信対象のコンテンツのチャンクファイルを取得してキャッシングし、クライアント端末５に配信することができる。また、配信装置１は、複数のクライアント端末５から受信した同一コンテンツの配信要求を、ストレージ装置３に対する１本の配信要求に集約する事ができる。
【００６２】
（第２の実施形態）
本実施形態では、配信装置が配信するコンテンツに広告を挿入する。本実施形態のコンテンツ配信は、ＶＯＤを主とする。本実施形態は、ライブ配信とは異なり、例えばハッシュ値を元にチャンクファイルの一意同一性を求めるような事が無く、その構成を当該装置で無視（内部的に加工処理）してもよいマニフェストファイルに適用される。本実施形態のコンテンツ配信システムは、図１に示す第１の実施形態のコンテンツ配信システムの配信装置１に代えて、図６に示す配信装置１ａを備えて構成される。
【００６３】
図６は、本実施形態の配信装置１ａの構成を示す図であり、本実施形態と関係する機能ブロックのみを抽出して示してある。同図において、図３に示す第１の実施形態による配信装置１と同一の部分には同一の符号を付し、その説明を省略する。同図に示すように、配信装置１ａは、格納部１１−１、格納部１１−２、エッジ側送受信部１２、キャッシュロック部１３、コンテンツ存在認識部１４、チャンクファイル数認識部１５、バックエンド側送受信部１６、コンテンツ蓄積トリガー部１７、及び一時書換部１８を備えて構成される。
【００６４】
配信装置１ａと配信装置１とは、格納部１１−２内に格納しているデータが異なっている。配信装置１ａの格納部１１−２には、本編のコンテンツ（本実施形態では以降、「本編コンテンツ」と称する。）を構成する一部のファイルと、本編コンテンツとは別の広告コンテンツが格納されている。配信装置１ａの格納部１１−２が格納している本編コンテンツは、マニフェストファイルのみの構成であり、チャンクファイルを保持していないという点で第１の実施形態と異なる。広告コンテンツは、チャンクファイルのみの構成であり、マニフェストファイルを保持していないという点で第１の実施形態とは異なる新たな形態である。
一時書換部１８は、格納部１１−２に格納されているマニフェストファイルに対し、チャンクファイルリストの先頭に、広告コンテンツのチャンクファイルの情報を書き込む。
【００６５】
本実施形態の配信装置１ａは、本編コンテンツを構成するチャンクファイルをバックエンド側から取得するまでの時間稼ぎとして、広告コンテンツを配信する。第１の実施形態の場合には少なからず本編コンテンツの一部のチャンクファイルが必要になり、そのコンテンツ種類が増えれば増えるほど配信装置１に格納しておく領域の増加が必要となる。本実施形態では、格納部１１−２に記憶するファイルは、複数種類のマニフェストファイルと、ひとつの広告コンテンツを構成するチャンクファイルのみで済む。よって、副次的な効果として、配信装置１ａの格納領域の増加を抑制しつつ、広告配信によるスポンサー・収入源確保やエンドユーザ向けへの促販につながることが考えられる。なお、本実施形態は、第１の実施形態にように、格納部１１−２に先頭から所定数のチャンクファイルを格納している場合にも適用可能である。
【００６６】
図７は、本編コンテンツＣのマニフェストファイルを示す図である。同図に示すように、マニフェストファイルには、４つのチャンクファイルのＵＲＩが記述されている。
図８は、広告コンテンツを構成するチャンクファイル群を示す図である。同図に示すように、広告コンテンツは、「commercial-chunk-1.ts」、「commercial-chunk-2.ts」の２つのチャンクファイルである。
一時書換部１８は、エッジ側送受信部１２がクライアント端末５から本編コンテンツＣのマニフェストファイル要求を受信したことをトリガーとして、格納部１１−２から本編コンテンツＣのマニフェストファイルを取り込む。一時書換部１８は、本編コンテンツＣのマニフェストファイルの取り込み時に、広告コンテンツを構成するチャンクファイル群の情報を合わせて取り込む。
【００６７】
図９は、書き換え後のマニフェストファイルを示す図である。同図に示すように、一時書換部１８は、本編コンテンツＣのマニフェストファイルに、広告コンテンツを構成するチャンクファイル群をマージする。具体的には、一時書換部１８は、本編コンテンツＣのマニフェストファイルの先頭のチャンクファイルの情報の前に、広告コンテンツを構成する２つのチャンクファイルのＵＲＩを挿入する。エッジ側送受信部１２は、一時書換部１８が書き換えたマニフェストファイルを、クライアント端末５への応答として送信する。
【００６８】
書き換えが行われた本編コンテンツＣのマニフェストファイルを受信したクライアント端末５は、チャンクファイルリストを解析する。クライアント端末５は、配信装置１ａに対して、リストの先頭の「http://hoge.com/contents/commercial-chunk-1.ts」のチャンクファイルから順に配信を要求する。その間に、配信装置１ａのチャンクファイル数認識部１５は、その時点では自装置にまだ保持していないチャンクファイル（chunk-1.tsからchunk-4.ts）の要求及び取得をバックエンド側のストレージ装置３に対して順次実行する。本実施形態では、配信装置１ａは、「commercial-chunk-1.ts」や「commercial-chunk-2.ts」の配信を完了する前までに、「chunk-1.ts」以降の本編を構成するチャンクファイルの取得を完了しておけばよい。よって、「commercial-chunk-1.ts」や「commercial-chunk-2.ts」の分だけ、配信装置１ａに時間的な猶予が与えられる。
【００６９】
なお、本実施形態では、一時書換部１８は、マニフェストファイルの配信時に広告コンテンツを構成するチャンクファイル群を挿入しているが、この処理を予め行ってもよい。つまり、一時書換部１８は、格納部１１−２に格納されているマニフェストファイルに、広告コンテンツを構成するチャンクファイル群を予め挿入しておく。
また、本実施形態のバリエーションや延長として、ランダムに選択した広告を配信してもよい。例えば、格納部１１−２に「広告映像コンテンツＡ」、「広告映像コンテンツＢ」、「広告映像コンテンツＣ」、…のように複数種類の広告コンテンツを格納しておく。一時書換部１８は、「広告映像コンテンツＡ」、「広告映像コンテンツＢ」、「広告映像コンテンツＣ」、…を選択し、選択した広告コンテンツのチャンクファイル群をマニフェストファイルに挿入する。なお、広告コンテンツの選択は、無作為（ランダム）であってもよく、予め収集しておいた配信要求元のエンドユーザの属性や嗜好の情報に応じて選択してもよい。
【００７０】
また、第１の実施形態と第２の実施形態を組み合わせてもよい。例えば、配信要求の頻度が少ないコンテンツについては、格納部１１−２にマニフェストファイルのみを格納し、チャンクファイルを格納しないようにする。
【００７１】
第１の実施形態において配信装置１は、初期状態として、格納部１１−２に全てのコンテンツについてマニフェストファイルと先頭から数個分のチャンクファイルのデータのみを格納してもよい。本実施形態は、配信装置１ａの格納部１１−２にそのようなデータを記憶しておくための容量が不足している場合に適用できる。
【００７２】
（第３の実施形態）
本実施形態は、上述した第１及び第２の実施形態の拡張形態である。本実施形態では、配信装置１、１ａは、事前にストレージ装置３宛てのＩＰパケットをフレーム化しておく。本実施形態の配信装置１、１ａのバックエンド側送受信部１６は、例えば、ＴＯＥ（TCP/IP Offload Engine）を備える。
第１及び第２の実施形態によれば、配信装置１、１ａは、コンテンツの視聴要求（マニフェストファイルの配信要求）をクライアント端末５から受信すると、要求されたコンテンツが格納部１１−２に格納されているか否かを判断する。配信装置１、１ａは、要求されたコンテンツが格納部１１−２に格納されていると判断した場合、バックエンド側のストレージ装置３に対して、キャッシュすべきチャンクファイルの取得処理を順次実行する。このとき、配信装置１、１ａのバックエンド側送受信部１６は、バックエンド側のストレージ装置３へ接続するための情報をセットしたＩＰパケットフレームを、事前に準備しておくことが十分可能である。ストレージ装置３へ接続するための情報は、具体的にはdestination IP addressやdestination port numberである。
これにより、コンテンツ存在認識部１４の判定結果がストレージ装置３にアクセスするトリガーとなった場合、バックエンド側送受信部１６は、いち早く且つ、シームレスにストレージ装置３にコンテンツの取得要求を送信することが可能となる。
【００７３】
（第４の実施形態）
本実施形態は、上述した第１から第３の実施形態の拡張形態である。本実施形態において配信装置１、１ａは、マルチビットレートコンテンツ対策を実行する。
上述した実施形態において対象としているＨＴＴＰによる映像コンテンツの配信方式・手順では、先に記したようにパブリック且つスタンダードな規格が定められているわけではないが、デファクトとして浸透しつつある。上述した実施形態では、マニフェストファイルに一連のチャンクファイルのリストが記載されている事を前提としているが、これをマルチビットレートコンテンツに適応する事が考えられる。
【００７４】
つまり、エンドユーザは、コンテンツ（プログラムの内容）に興味を持って選択し、配信を要求している。そのため、いずれ同一コンテンツで高精細なビットレートのものや、逆に処理能力が低いポータブル端末において粗い画質にて視聴するための低ビットレートのものが視聴されることも予測される。それらのビットレートのチャンクファイルも、配信装置１、１ａが事前にチャンクファイルをキャッシュしておくためのトリガーとする事が出来る。以下では、第１の実施形態の配信装置１を例に、上記実施形態との差分を説明する。
【００７５】
例えば、内容が同一であり、ビットレートがＢ１、Ｂ２、Ｂ３と異なるコンテンツのマニフェストファイルが格納部１１−２に配置されていたとする。
図１０、図１１、図１２はそれぞれ、ビットレートがＢ１、Ｂ２、Ｂ３の同一のコンテンツのマニフェストファイルを示す図である。
図１０が示すビットレートＢ１用のマニフェストファイルB1-manifestのチャンクファイルリストには、チャンクファイル「B1-chunk-1.ts」、「B1-chunk-2.ts」、「B1-chunk-3.ts」、…が記述されている。図１１が示すビットレートＢ２用のマニフェストファイルB2-manifestのチャンクファイルリストには、チャンクファイル「B2-chunk-1.ts」、「B2-chunk-2.ts」、「B2-chunk-3.ts」、…が記述されている。図１２が示すビットレートＢ３用のマニフェストファイルB3-manifestのチャンクファイルリストには、チャンクファイル「B3-chunk-1.ts」、「B3-chunk-2.ts」、「B3-chunk-3.ts」、…が記述されている。さらに、格納部１１−２には、マニフェストファイルB1-manifest、B2-manifest、及びB3-manifestが、異なるビットレートの同一コンテンツのマニフェストファイルであることを示す情報が格納されている。
また、格納部１１−２には、チャンクファイル「B1-chunk-1.ts」、「B2-chunk-1.ts」、「B3-chunk-1.ts」が格納されているとする。
【００７６】
クライアント端末５が、ビットレートＢ２のマニフェストファイルB2-manifestを要求する。チャンクファイル数認識部１５は、マニフェストファイルB2-manifestに記述されているチャンクファイルのリストのうち、チャンクファイル「B2-chunk-2.ts」、「B2-chunk-3.ts」が不足していることを認識する。さらに、チャンクファイル数認識部１５は、格納部１１−２に格納されている情報から、マニフェストファイルB1-manifest、B3-manifestが、マニフェストファイルB2-manifestと異なるビットレートの同一コンテンツのマニフェストファイルであると認識する。チャンクファイル数認識部１５は、マニフェストファイルB1-manifestに記述されているチャンクファイルのリストのうち、チャンクファイル「B1-chunk-2.ts」、「B1-chunk-3.ts」が不足していることを認識する。また、チャンクファイル数認識部１５は、マニフェストファイルB3-manifestに記述されているチャンクファイルのリストのうち、チャンクファイル「B3-chunk-2.ts」、「B3-chunk-3.ts」が不足していることを認識する。
【００７７】
バックエンド側送受信部１６は、チャンクファイル数認識部１５が不足していると認識したチャンクファイルをキャッシュするために、バックエンド側のストレージ装置３に対して、これらのチャンクファイルの取得処理を順次実行する。具体的には、バックエンド側送受信部１６は、ビットレートＢ２用のチャンクファイル「B2-chunk-2.ts」、「B2-chunk-3.ts」をキャッシュするために、バックエンド側のストレージ装置３に対して、これらのチャンクファイルの取得処理を順次実行する。これに併せて、バックエンド側送受信部１６は、ビットレートＢ１用のマニフェストファイルB1-manifestやビットレートＢ３用のマニフェストファイルB3-manifestに記述されている不足のチャンクファイルの取得処理を行う。つまり、バックエンド側送受信部１６は、ビットレートＢ１用のチャンクファイル「B1-chunk-2.ts」、「B1-chunk-3.ts」、及び、ビットレートＢ３用のチャンクファイル「B3-chunk-2.ts」、「B3-chunk-3.ts」の取得処理をストレージ装置３に対して行う。
【００７８】
以上説明した実施形態の配信装置１、１ａの一部または全ての機能部を、ソフトウェア機能部により実現してもよく、専用のハードウェアにより実現してもよい。配信装置１、１ａの一部または全ての機能部をソフトウェア機能部により実現する場合、その機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現してもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでもよい。また上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよい。
【００７９】
以上説明した少なくともひとつの実施形態によれば、格納部１１−２、及びバックエンド側送受信部１６を持つことにより、バックエンド側から効率的に配信対象のコンテンツのチャンクファイルをストレージ装置３から読み出してキャッシングし、クライアント端末５に配信することができる。
また、以上説明した少なくともひとつの実施形態によれば、キャッシュロック部１３を持つことにより、複数のクライアント端末５から受信した同一コンテンツの配信要求を、ストレージ装置３に対する１本の配信要求に集約する事ができる。
【００８０】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。
【符号の説明】
【００８１】
１…配信装置、１ａ…配信装置、３…ストレージ装置、５…クライアント端末、７…ロードバランサ、８…ＩＰネットワーク、９…ＩＰネットワーク、１１−１…格納部（コンテンツ蓄積部）、１１−２…格納部、１２…エッジ側送受信部（配信部）、１３…キャッシュロック部、１４…コンテンツ存在認識部、１５…チャンクファイル数認識部、１６…バックエンド側送受信部（ファイル取得部）、１７…コンテンツ蓄積トリガー部、１８…一時書換部
【図１】
2015170323.tif 000003
【図２】
2015170323.tif 000004
【図３】
2015170323.tif 000005
【図４】
2015170323.tif 000006
【図５】
2015170323.tif 000007
【図６】
2015170323.tif 000008
【図７】
2015170323.tif 000009
【図８】
2015170323.tif 000010
【図９】
2015170323.tif 000011
【図１０】
2015170323.tif 000012
【図１１】
2015170323.tif 000013
【図１２】
2015170323.tif 000014
【図１３】
2015170323.tif 000015
【図１４】
2015170323.tif 000016
【図１５】
2015170323.tif 000017