(57)【特許請求の範囲】
【請求項１】
ユーザ端末にビデオの配信を行なう複数のローカルサーバと、前記ユーザ端末を前記ローカルサーバに割り当てるマスタサーバとで構成されるビデオ配信システムであって、
前記マスタサーバは、
ビデオファイルを記憶するビデオ記憶手段と、
ユーザＩＤおよび地域の情報を含むユーザ情報を記憶するユーザ情報記憶手段と、
前記ユーザ情報記憶手段に、新たなユーザ情報を登録するユーザ登録手段と、
前記ユーザ情報を前記地域に対応するローカルサーバに送信するユーザ情報送信手段と、
前記ローカルサーバに蓄積するビデオファイルを前記ビデオ記憶手段から読み出して、前記ローカルサーバに送信するビデオ送信手段と
を備え、
前記ローカルサーバは、
マスタサーバから送信されたビデオファイルを記憶しているローカルビデオ記憶手段と、
前記マスタサーバから送信された前記ユーザ情報を記憶するローカルユーザ情報記憶手段と、
前記ユーザ端末からアクセスがあると該ユーザ端末に番組選択ページを送信する番組ページ送信手段と、
該番組選択ページで選択された番組を受信する番組受信手段と、
該番組に対応するビデオファイルを前記ローカルビデオ記憶手段から読み出して前記ユーザ端末に送信するローカルビデオ送信手段と
を備えることを特徴とするビデオ配信システム。
【請求項２】
請求項１に記載のビデオ配信システムにおいて、
前記ユーザ情報には、さらに、ユーザの年齢・性別・嗜好等の情報を含み、
前記ビデオ記憶手段及びローカルビデオ記憶手段には広告ビデオファイルも記憶しており、
さらに、前記広告ビデオファイルに対応する配信情報を記憶する配信情報記憶手段を前記マスタサーバ及びローカルサーバに備え、
前記ビデオ送信手段は、前記配信情報もローカルサーバに送信し、
前記ローカルビデオ送信手段は、前記ユーザ端末に対応するユーザ情報を前記ユーザ情報記憶手段から読み出し、前記配信情報記憶手段の配信情報を用いて、該ユーザ情報に適合する前記広告ビデオファイルを前記ローカルビデオ記憶手段から読み出し、前記番組中に挿入して前記ユーザ端末に送信する
ことを特徴とするビデオ配信システム。
【請求項３】
請求項１又は２に記載のビデオ配信システムのローカルサーバにおいて、
前記ローカルビデオ送信手段は、番組に対応するビデオファイルが複数ある場合、ファイル間の空白時間なく送信する
ことを特徴とするビデオ配信システム。
【請求項４】
請求項３に記載のビデオ配信システムにおいて、
前記ローカルビデオ送信手段は、
少なくとも２つのバッファ記憶手段と
前記ローカルビデオ記憶手段から読み出したビデオファイルを、前記複数のバッファ記憶手段にファイル毎に切り替えて書き込み、前記複数のバッファ記憶手段からファイル毎に順次切り替えて読み出すバッファ制御手段とをさらに有する
ことを特徴とするビデオ配信システム。
【請求項５】
請求項４に記載のビデオ配信システムにおいて、
前記ローカルビデオ送信手段は、
前記ローカルビデオ記憶手段への読み出し指示から前記バッファ記憶手段に書き込み開始するまでの時間を測定してこれを遅延時間とする遅延測定手段と、
前記バッファ記憶手段の容量を該遅延時間により変更する容量変更手段とをさらに有し、
該遅延時間により、前記バッファ記憶手段の容量を定める
ことを特徴とするビデオ配信システム。
【請求項６】
請求項５に記載のビデオ配信システムにおいて、
前記ローカルビデオ送信手段は、前記遅延測定手段からの遅延時間を用いて、前記ローカルビデオ記憶手段への読み出し指示を、前のビデオファイルの読み出し終了を待たずに発生する
ことを特徴とするビデオ配信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オンデマンド型ビデオ配信システムに関するものである。
【背景技術】
【０００２】
ＡＤＳＬや光ファイバーなどによる高速なインターネット接続サービスの普及に伴い、インターネットを利用して、映像による番組（ビデオ）などのコンテンツをオンデマンドでパソコンなどの端末にリアルタイム配信するサービスへの需要拡大が期待され、実際にこのようなサービスが試みられている。
【０００３】
＜従来のビデオ配信システムとその問題点＞
従来のインターネットによるオンデマンド型ビデオ配信システムの構成例を図１に示す。
各々のユーザはパソコンなどのユーザ端末１５０を利用して、インターネット１４０経由でビデオ配信を受ける。
ここで、大規模な配信システムの場合、多数のユーザが同時にアクセスすることにより大きな負荷がかかり、物理的に１台のビデオサーバ１２０ではそれを処理することができない。このため、例えばＬ４（Ｌｅｖｅｌ  ４）スイッチ１３０を用いて負荷分散を行なう。すなわち、ユーザを複数のビデオサーバ１２０に均等に振り分け、ビデオサーバ１台あたりの負荷を減らしている。また、複数のビデオサーバ１２０が共通して配信用のビデオファイル（ＭＰＥＧやＡＶＩなどのビデオデータ）を読み出せるように、ビデオファイルを共通のメディアストレージ１１０に格納する。
このようなシステム構成により、多数のユーザが同時にアクセスした場合でも問題なくビデオ配信を行なうことができる。
【０００４】
しかしながら、上述した従来のビデオ配信システムでは、アクセスするユーザ数が増えるに従ってサーバ（データセンター）側のインターネット接続（図１のＬ４スイッチ１３０とインターネット１４０をつなぐ線）を非常に大きな通信帯域の通信線にする必要がある。通信回線はユーザが増える毎に順次拡張することができず、必要な帯域の大きさにより段階的に拡張する必要がある。つまり、利用していない場合でも余剰な回線帯域を確保して実際の運用を行なう必要がある。一般に、データセンター用の高速回線は非常に高価であり、この運用方法は多大なコストを要する。
【０００５】
また、ユーザ毎に別々な広告ビデオを番組中に挿入して配信する場合に、配信用ビデオの作成費用が膨大になる問題がある。すなわち、従来のオンデマンド型のビデオ配信システムは、配信用ビデオをあらかじめメディアストレージ１１０に格納しておき、ユーザからの配信要求に応じて配信する仕組みであるため、ユーザ毎に別々な広告ビデオを配信する場合には、１つの番組に対して、あらかじめ異なった広告を含む複数の配信用ビデオを作製して、メディアストレージ１１０に格納しておく必要がある。しかしながら、この方法はビデオの製作費用、広告の入替えにかかる費用と時間、そしてメディアストレージ１１０の容量が膨大になるため、現実的ではない。
一方、この問題を解決する手段として、複数のビデオを連続して配信するムービーリスト方式によるビデオ配信が提案されている。ムービーリスト方式では、番組中に広告を挟んで配信したい場合、番組のビデオをあらかじめ複数のビデオファイルに分けてメディアストレージ１１０に格納しておき、それらのビデオファイルと広告ビデオファイルを交互に順にユーザ端末１５０に配信する。これにより、ユーザごとに異なる広告ビデオを配信したり、容易に広告を入れ替えることが可能となる。
【０００６】
＜従来のムービーリスト方式とその問題点＞
図１に示した従来のビデオ配信システムにおいて、従来のムービーリスト方式を用いて複数のビデオファイルを連続配信する仕組みを、図２〜図４を参照しながら説明する。
図２は、従来のビデオ配信システムに従来のムービーリスト方式を用いた場合のブロック図である。インターネット１４０の左側にはサーバの各装置、右側にはユーザ端末の各装置を示している。ここで、１つの番組を構成する複数の主ビデオファイルおよび広告ビデオファイルを順次ユーザ端末に配信して、ビデオプレイヤー１５６により順に再生するためには、番組の配信開始から配信終了まで、サーバとユーザ端末との間のインターネット通信を、サーバのポート１２６とユーザ端末のポート１５２でセッションを張ったまま行なう必要がある。
ビデオサーバ１２０は、ユーザ端末から配信要求が送られると、対応するビデオファイルをメディアストレージ１１０から読み出してユーザ端末に送信する。読出バッファ１２２は、メディアストレージ１１０に格納されているビデオファイルをビデオサーバ１２０に読み出す際に用いるバッファである。送信バッファ１２４は、ビデオファイルをビデオサーバ１２０からインターネット１４０に送信するために用いるバッファである。
【０００７】
一方、ユーザ端末では、ユーザが見たい番組を選択すると、該番組に対応するビデオファイルがサーバから配信され、ビデオプレイヤー１５６で再生され、ユーザが閲覧することができる。なお、ユーザ端末側のビデオプレイヤー１５６は、例えば、Ｗｉｎｄｏｗｓ（登録商標）  Ｍｅｄｉａ  Ｐｌａｙｅｒなど、現在一般的に利用されているものを用いる。
ユーザが番組を選択する方法は、例えば、ユーザがユーザ端末からサーバのホームページにアクセスして、ユーザ端末のブラウザに表示された番組一覧のＷｅｂページから、所望の番組に対応するハイパーリンクやボタンをクリックする等の操作により選択するといった方法を採用することができる。
【０００８】
ここで、ムービーリスト方式を用いてユーザが選択した番組のビデオ（以降「主ビデオ」という）に広告ビデオを挿入して配信するには、例えば、サーバ側に、あらかじめ各番組に対応したビデオリストを用意しておく方法が考えられる。ビデオリストは、番組の主ビデオファイルおよび挿入する広告ビデオファイルのファイル名等を配信順（再生順）に記したリストである。
図３は、ある番組に対して用意されているビデオリストの例である。選択された番組に対応する主ビデオＶＯＤ−１，ＶＯＤ−２，ＶＯＤ−３（これらは例えば、１つの番組を３つに区切った各主ビデオのビデオファイル名である）の各ビデオファイルの前後に広告ビデオＣＭ−１，ＣＭ−２，ＣＭ−３，ＣＭ−４のビデオファイルを挟んで連続再生することを示している。
なお、広告ビデオは、あらかじめ具体的な広告ビデオファイル名（図３の例ではＣＭ−１〜ＣＭ−４）をビデオリストに記述しておいてもよいし、ユーザ端末からの配信要求時にサーバが任意に広告ビデオを選択するようにしてもよい。
【０００９】
ユーザ端末からサーバへの配信要求は、例えば、ＯＣＸ（ＯＬＥ  Ｃｕｓｔｏｍ  Ｃｏｎｔｒｏｌ）を実行して行なう。ＯＣＸは、ＯＬＥコントロールと同義であり、Ｗｉｎｄｏｗｓ（登録商標）においてアプリケーションソフト間のデータ連携を実現する仕組みであるＯＬＥ（Ｏｂｊｅｃｔ  Ｌｉｎｋｉｎｇ  ａｎｄ  Ｅｍｂｅｄｄｉｎｇ）に準拠して作成されるソフトウェア部品である。なお、ＯＣＸの代わりに、ユーザ端末で実行できるＪａｖａ（登録商標）Ｓｃｒｉｐｔ等などによるスクリプト言語を用いてもよい。
図２のブロック図に示すように、ＯＣＸ１５４は、ユーザ端末にサーバ等から送信する等によりあらかじめ用意しておく。上述のクリック等の操作によりユーザが見たい番組を選択すると、サーバからユーザ端末に、番組に対応するビデオリストが送られる。ＯＣＸ１５４は、ユーザ端末のビデオプレイヤー１５６を起動して、ビデオリストに従って主ビデオおよび広告ビデオの配信要求をサーバに送り、配信されたビデオファイルをビデオプレイヤー１５６で再生する。
【００１０】
このとき、従来のムービーリスト方式では、ビデオリストに従ってサーバからの配信およびユーザ端末での再生を行なうためには、サーバ、ＯＣＸ１５４，およびビデオプレイヤー１５６の間で図４の通信シーケンスに示す一連のやり取りが必要である。この一連のやり取りは、ユーザ端末のポート１５２とサーバのポート１２６とを介して行なわれる。
ＯＣＸ１５４はまずビデオプレイヤー１５６を起動し、ビデオリストの最初のビデオファイル（図３ではＣＭ−１）の配信をサーバに要求する（Ｓ４１１）。サーバは配信要求を受けて、広告ビデオファイル（ＣＭ−１）をメディアストレージ１１０から読み出してユーザ端末に配信する（Ｓ４１２）。配信されたビデオファイル（ＣＭ−１）はビデオプレイヤー１５６中のバッファに蓄積されて、再生される（Ｓ４１３）。再生が終了すると、ビデオプレイヤー１５６からＯＣＸ１５４に再生終了の信号を送信する（Ｓ４１４）。ＯＣＸ１５４は再生終了を受けて、ビデオリストの次のビデオファイル（図３ではＶＯＤ−１）の配信をサーバに要求する（Ｓ４２１）。
以降同様に、ビデオリストの最後のビデオファイル（図３ではＣＭ−４）まで順に、上記の配信要求（Ｓ４３１，Ｓ４４１，…）、配信（Ｓ４２２，Ｓ４３２，…）、再生（Ｓ４２３，Ｓ４３３，…）、再生終了（Ｓ４２４，Ｓ４３４，…）を繰り返し行なう。
【００１１】
図４の通信シーケンスのようなやり取りを行なうのは、現在パソコンなどのユーザ端末で一般的に使用されているＷｉｎｄｏｗｓ（登録商標）  Ｍｅｄｉａ  Ｐｌａｙｅｒなどのビデオプレイヤー１５６では、ビデオファイル１つずつしか一連の再生処理（バッファへの受信とビデオプレイヤーでの再生）ができないためである。また、ビデオプレイヤー１５６からＯＣＸ１５４に対して再生終了の信号しか渡せないため、複数のビデオファイルを順次ユーザ端末に配信して１つのビデオプレイヤー１５６に連続再生させようとする場合、サーバとユーザ端末との間の一連のやり取りを、サーバのポート１２６とユーザ端末のポート１５２でセッションを張ったまま行なう必要がある。
その結果、従来のムービーリスト方式では、ビデオリスト中のビデオファイルを１つずつ、しかも前のビデオファイルの再生が終了してから、サーバに次のビデオファイルの配信要求を行なう必要があるので、１つのビデオファイルの再生終了から次のビデオファイルの再生開始までの遅延のために、ビデオプレイヤー１５６での映像が途切れてしまい、空白時間が生じる。特に、複数の広告ビデオを含んで再生することは、多数の空白時間が生じ、ユーザの満足度を得られないという問題がある。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
本発明の課題は、上述の問題点、すなわち（１）ビデオ配信システムにおけるユーザ端末のアクセス分散の問題、そして（２）ムービーリスト方式においてビデオファイル間に空白時間が発生する問題を解決することである。
【課題を解決するための手段】
【００１３】
上記の課題を解決するために、本発明は、ユーザ端末にビデオの配信を行なう複数のローカルサーバと、前記ユーザ端末を前記ローカルサーバに割り当てるマスタサーバとで構成されるビデオ配信システムであって、前記マスタサーバは、ビデオファイルを記憶するビデオ記憶手段と、ユーザＩＤおよび地域の情報を含むユーザ情報を記憶するユーザ情報記憶手段と、前記ユーザ情報記憶手段に、新たなユーザ情報を登録するユーザ登録手段と、前記ユーザ情報を前記地域に対応するローカルサーバに送信するユーザ情報送信手段と、前記ローカルサーバに蓄積するビデオファイルを前記ビデオ記憶手段から読み出して、前記ローカルサーバに送信するビデオ送信手段とを備え、前記ローカルサーバは、マスタサーバから送信されたビデオファイルを記憶しているローカルビデオ記憶手段と、前記マスタサーバから送信された前記ユーザ情報を記憶するローカルユーザ情報記憶手段と、前記ユーザ端末からアクセスがあると該ユーザ端末に番組選択ページを送信する番組ページ送信手段と、該番組選択ページで選択された番組を受信する番組受信手段と、該番組に対応するビデオファイルを前記ローカルビデオ記憶手段から読み出して前記ユーザ端末に送信するローカルビデオ送信手段とを備えることを特徴とするビデオ配信システムである。
ユーザ登録手段により登録されたユーザ端末は、以後ローカルサーバから直接ビデオ配信を受けることができるため、本発明のビデオ配信システムを利用するユーザが増えても、マスタサーバに負荷が集中しない。
前記ユーザ情報には、さらに、ユーザの年齢・性別・嗜好等の情報を含み、前記ビデオ記憶手段及びローカルビデオ記憶手段には広告ビデオファイルも記憶しており、さらに、前記広告ビデオファイルに対応する配信情報を記憶する配信情報記憶手段を前記マスタサーバ及びローカルサーバに備え、前記ビデオ送信手段は、前記配信情報もローカルサーバに送信し、前記ローカルビデオ送信手段は、前記ユーザ端末に対応するユーザ情報を前記ユーザ情報記憶手段から読み出し、前記配信情報記憶手段の配信情報を用いて、該ユーザ情報に適合する前記広告ビデオファイルを前記ローカルビデオ記憶手段から読み出し、前記番組中に挿入して前記ユーザ端末に送信することを特徴としてもよい。
広告ビデオファイルに対応する配信情報を有することで、ユーザごとにそのユーザの年齢・性別・嗜好等に適する広告ビデオを番組中に挿入して配信することができる。
【００１４】
上述のビデオ配信システムのローカルサーバにおいて、前記ローカルビデオ送信手段は、番組に対応するビデオファイルが複数ある場合、ファイル間の空白時間なく送信することを特徴としてもよい。
このように送信された複数のビデオファイルを、ユーザ端末では空白時間のない１つのファイルのように再生することができる。
前記ローカルビデオ送信手段は、少なくとも２つのバッファ記憶手段と、前記ローカルビデオ記憶手段から読み出したビデオファイルを、前記複数のバッファ記憶手段にファイル毎に切り替えて書き込み、前記複数のバッファ記憶手段からファイル毎に順次切り替えて読み出すバッファ制御手段とをさらに有していてもよい。
さらに、前記ローカルビデオ送信手段は、前記ローカルビデオ記憶手段への読み出し指示から前記バッファ記憶手段に書き込み開始するまでの時間を測定してこれを遅延時間とする遅延測定手段と、前記バッファ記憶手段の容量を該遅延時間により変更する容量変更手段とをさらに有し、該遅延時間により、前記バッファ記憶手段の容量を定めることを特徴としてもよい。
ユーザ端末からの番組の配信要求を受けてこの遅延測定手段により遅延時間を測定し、該遅延時間に応じて、該ユーザ端末へのビデオ配信に必要なバッファ容量を用意することができる。これにより、ローカルサーバのメモリを無駄なく利用することができる。
さらに、前記ローカルビデオ送信手段は、前記遅延測定手段からの遅延時間を用いて、前記ローカルビデオ記憶手段への読み出し指示を、前のビデオファイルの読み出し終了を待たずに発生することを特徴としてもよい。
【発明の効果】
【００１５】
本発明のビデオ配信システムによれば、ビデオ配信をユーザ端末とローカルサーバとのやり取りのみで行なうため、ユーザが増えてもマスタサーバに負荷が集中しない。また、ユーザ登録時にユーザの特性に関する情報を登録して、各ユーザに適した広告ビデオファイルを配信するため、より効果のある広告を行なうことができる。
また、本発明のビデオ配信システムで用いる新しいムービーリスト方式によれば、ビデオリスト中の複数のビデオファイルを、空白時間を生じることなくユーザ端末のビデオプレイヤーに再生させることができるようになった。再生映像が途切れないため、ユーザの満足度を高めることができる。
【発明を実施するための最良の形態】
【００１６】
以降、本発明のビデオ配信システムの実施形態について、図面を用いて詳しく説明する。
【００１７】
＜本実施形態のビデオ配信システム＞
図５は、本実施形態のビデオ配信システムのシステム構成例を示した図である。
本実施形態のビデオ配信システムは、マスタサーバ５２０、ローカルサーバ５７０、ユーザ端末５５０で構成され、これらは互いにインターネット５４０を介して通信する。
ユーザ端末５５０は、例えばパソコンや携帯電話、ＰＤＡなどの、インターネットに接続可能な端末である。ローカルサーバ５７０は地域ごとに設置されるサーバであり、その地域のユーザ端末５５０からの要求に応じてビデオを配信するサーバである。マスタサーバ５２０は、本実施形態のビデオ配信システムの中心に配置されるサーバであり、各地域のローカルサーバ５７０にビデオを配信するほか、ユーザ（ユーザ端末５５０を使用してビデオ配信を受ける者）の登録処理を行なうサーバである。
【００１８】
（マスタサーバ）
マスタサーバ５２０において、メディアストレージ５１０は、全ての制作された主ビデオ（番組のビデオ）および広告ビデオのビデオファイルを格納する記憶装置である。
ファイル再配置制御５２２は、メディアストレージ５１０のビデオファイルをローカルサーバ５７０に配信したり、不要になったビデオファイルをローカルサーバ５７０から削除したりするプログラムである。
ＩＤ情報データベース５２１は、各ローカルサーバ５７０の情報および各ユーザの情報を格納しているデータベースである。ＩＤ情報データベース５２１を構成する主要な項目を、図６に示す。図６において、上部に示す「ユーザ情報」の各項目はユーザの情報であり、下部に示す「ローカルサーバ情報」の各項目はローカルサーバ５７０の情報である。
なお、ＩＤ情報データベース５２１およびファイル再配置制御５２２については、後の（ファイル再配置処理）及び（ユーザ登録処理）の項で詳しく説明する。 
【００１９】
（ローカルサーバ）
ローカルサーバ５７０において、ＩＰテレビ電話５７２は、ユーザ端末５５０にＩＰテレビ電話のサービスを行なうシステムである。他に、例えばブログサービス（特に、映像を含むビデオブログサービス）を提供するシステム等をローカルサーバ５７０に設けてもよい。
ビデオサーバ５８０は、ユーザ端末５５０にビデオ配信を行なうために、必要なビデオファイルをメディアストレージ５６０から読み出すサーバである。なお、ここでビデオサーバとは、必ずしも物理的に独立したサーバではなく、メディアストレージ５６０からビデオファイルを読み出すサーバプログラムであることを示している。本実施形態では、主ビデオファイルを読み出す主ビデオサーバ５８２と、広告ビデオファイルを読み出す広告ビデオサーバ５８４とを各ローカルサーバ５７０に用意しているが、ビデオサーバの数や配置は、これに限らない。
【００２０】
ビデオインサータ５９０は、後述で提案する新しいムービーリスト方式（方式１）において、ビデオリストにリストされたビデオファイルを、ユーザ端末５５０のビデオプレイヤーに空白時間を生じることなく再生させるための処理を行なうプログラムである。
ローカルＩＤ情報データベース５７４は、そのローカルサーバ５７０の情報およびそのローカルサーバ５７０が担当するユーザの情報を格納しているデータベースである。ローカルＩＤ情報データベース５７４を構成する主要な項目を、図７に示す。図７において、上部に示す「ユーザ情報」の各項目はユーザの情報であり、下部に示す「ローカルサーバ情報」の各項目はローカルサーバ５７０の情報である。
配信記録データベース５７６は、各ユーザ端末５５０への配信履歴（配信した主ビデオファイル名および広告ビデオファイル名、配信日時など）を格納するデータベースである。
なお、ビデオインサータ５９０については後で詳しく説明する。ローカルＩＤ情報データベース５７４の各項目については、後の（ファイル再配置処理）及び（ユーザ登録処理）の項で詳しく説明する。
【００２１】
（ファイル再配置処理）
上述したように、ファイル再配置制御５２２は、メディアストレージ５１０のビデオファイルをローカルサーバ５７０に配信したり、不要になったビデオファイルをローカルサーバ５７０から削除したりするファイル再配置処理を行なうプログラムである。
各ローカルサーバ５７０が各々のメディアストレージ５６０に現在有している主ビデオファイルおよび広告ビデオファイルの情報（ビデオファイル名など）は、図６に示したＩＤ情報データベース５２１の「主ビデオライブラリ表」および「広告ビデオライブラリ表」に格納している。
ファイル再配置制御５２２はこれらの情報を参照して、再配置（配信・削除）すべきビデオファイルを決定し、ファイル再配置を行なう際、上記のＩＤ情報データベース５２１の「主ビデオライブラリ表」および「広告ビデオライブラリ表」を更新する。また、図７に示したローカルサーバ５７０のローカルＩＤ情報データベース５７４の「主ビデオライブラリ表」および「広告ビデオライブラリ表」も同様に更新する。
【００２２】
これにより、ＩＤ情報データベース５２１（マスタサーバ５２０）・ローカルＩＤ情報データベース５７４（ローカルサーバ５７０）「主ビデオライブラリ表」および「広告ビデオライブラリ表」は、常に最新の状態に保たれる。なお、ローカルＩＤ情報データベース５７４の情報は、ローカルサーバ５７０で更新するようにしてもよい。
このファイル再配置処理は、例えば定期的に行なうことができる。その他、マスタサーバ５２０のメディアストレージ５１０に新しいビデオファイルが追加された際に各ローカルサーバ５７０にそのビデオファイルを配信してもよい。また、各ローカルサーバ５７０からの要求に応じて配信・削除できるようにしてもよい。
このようなファイル再配置処理により、各ローカルサーバ５７０に新しい番組を配信したり、広告ビデオの入れ替えを行なったりすることができる。
【００２３】
ここで、図６に示したＩＤ情報データベース５２１（マスタサーバ５２０側）および図７に示したローカルＩＤ情報データベース５７４（ローカルサーバ５７０側）の「ローカルサーバ情報」の項目のうち、上述した「主ビデオライブラリ表」および「広告ビデオライブラリ表」以外の項目について説明する。
「ＩＰアドレス」は該ローカルサーバ５７０のＩＰアドレスであり、「サーバＩＤキーコード」はＩＰアドレスとは別に、あらかじめ該ローカルサーバ５７０に与えておくＩＤである。マスタサーバ５２０は、ローカルサーバ５７０からマスタサーバ５２０へのアクセスがあると、ＩＰアドレスとサーバＩＤキーコードを照会して該ローカルサーバ５７０を認証する。これにより不正アクセスを防止する。
「起動状態（起動時刻、停止時刻、復旧時刻）」は、ローカルサーバ５７０のサーバダウンなどの緊急時や、メンテナンス時などに用いる情報である。
【００２４】
（ユーザ登録処理）
本実施形態では、図１に示した従来のビデオ配信システムとは異なり、ユーザ端末５５０へのビデオ配信を、ユーザの地域に応じたローカルサーバ５７０で行なう。
ユーザは、本実施形態のビデオ配信システムによる配信サービスを最初に受ける際、マスタサーバ５２０にアクセスして、地域情報を含むユーザ情報を入力する。入力されたユーザ情報は、図６に示したＩＤ情報データベース５２１の「ユーザ情報」の各項目、および図７に示したローカルＩＤ情報データベース５７４の「ユーザ情報」の各項目に格納される。
【００２５】
ここで、図６および図７の「ユーザ情報」の各項目について説明する。
「ユーザＩＤ」は、ユーザを識別するためのＩＤであり、例えばユーザ登録時にシステムで自動的に付与する。
「地域」「嗜好」「年齢」「性別」は、ユーザ登録時にユーザが入力する情報である。「地域」はユーザが住んでいる（ユーザ端末５５０を使用する）地域であり、例えば都道府県などを選択する。「年齢」「性別」はユーザの年齢および性別である。「嗜好」は、ユーザの好みについてあらかじめ決めた項目（例えば好きな色、趣味など）について、ユーザが該当するものを選択することにより設定する。
これらの「地域」「嗜好」「年齢」「性別」は、ユーザの特性に適合する広告ビデオを配信する際に用いられる。したがって、特性をより細やかに判断するために、さらに多くの項目を設けることもできる。また「地域」は、後述するように、ユーザを地域の近いローカルサーバ５７０に割り当てるためにも用いられる。
【００２６】
図８は、ユーザ登録処理時のユーザ端末５５０・マスタサーバ５２０・ローカルサーバ５７０間の通信シーケンスを示した図である。
まず、ユーザがユーザ端末５５０からマスタサーバ５２０にあらかじめ用意されているホームページにアクセスする（Ｓ８１０）と、ユーザ端末５５０のブラウザにユーザ登録ページが表示される（Ｓ８２０）。ユーザ登録ページは、ユーザが自己の情報を入力するための入力欄を表示したＷｅｂページである。
ユーザは、上述のデータベース項目である地域・嗜好・年齢・性別を入力する。入力した内容はマスタサーバ５２０に送信され（Ｓ８３０）、マスタサーバ５２０のＩＤ情報データベース５２１に格納される（Ｓ８４０）。また、マスタサーバ５２０によりユーザＩＤが付与され、ＩＤ情報データベース５２１に格納される。
次に、以降のビデオ配信処理で用いるＯＣＸがマスタサーバ５２０からユーザ端末５５０に送信される（Ｓ８５０）。ＯＣＸは、マスタサーバ５２０にあらかじめ用意されており、マスタサーバ５２０が該ユーザのユーザＩＤおよび地域を記述して、ユーザ端末５５０に送信する。ＯＣＸの機能については後で詳しく説明する。なお、上述したように、ＯＣＸに代えて、ユーザ端末５５０で実行できるＪａｖａ（登録商標）Ｓｃｒｉｐｔ等などによるスクリプト言語を用いてもよい。
また、マスタサーバ５２０から該ユーザ端末５５０に対応するローカルサーバ５７０に、ユーザ情報が送信される（Ｓ８６０）。ローカルサーバ５７０に送信されたユーザ情報（ユーザＩＤ、地域、嗜好、年齢、性別）は、ローカルＩＤ情報データベース５７４に格納される（Ｓ８７０）。
これにより、ユーザ端末５５０は、以降のビデオ配信をローカルサーバ５７０から直接受けることができるようになる。
【００２７】
（ビデオ配信処理）
次に、ユーザ端末５５０にビデオ配信を行なう際の処理を説明する。
図９は、ビデオ配信処理時のユーザ端末５５０・マスタサーバ５２０・ローカルサーバ５７０間の通信シーケンスを示した図である。
まず、ユーザ端末５５０からマスタサーバ５２０のホームページにアクセスする（Ｓ９１０）。このとき、上述のユーザ登録処理で説明したユーザ登録ページがユーザ端末５５０に表示され、マスタサーバ５２０は、ユーザ端末５５０のＯＣＸを起動する起動命令をユーザ端末５５０に送信する（Ｓ９２０）。
ＯＣＸはＯＣＸに与えられたＵＲＬに従って、直接、対応するローカルサーバ５７０のメニューページにアクセスする（Ｓ９３０）とともにユーザ認証に必要なＩＤを送るので、ローカルサーバ５７０でユーザ認証がされる（Ｓ９３５）と、表示されているユーザ登録ページがメニューページに自動的に変わる（Ｓ９４０）。
【００２８】
すなわち、ＯＣＸはユーザ登録時にマスタサーバ５２０からユーザ端末５５０に与えられているため、既に登録されているユーザの場合は、上述のようにＯＣＸを起動してビデオ配信を行なう処理に進むことができる。一方、登録されていないユーザの場合は、ＯＣＸが起動しないので、ブラウザにはユーザ登録ページを表示したまま、ユーザが登録できる状態を保つことができる。ここでユーザが登録の操作をした場合には、上述の図８に示したユーザ登録処理を行なう。
なお、本実施形態では上述のようにマスタサーバ５２０からの起動命令によりＯＣＸを自動的に起動し、ローカルサーバ５７０にＩＤ等を送信してユーザ認証を行なうが、その他の方法で認証してもよい。例えば、ユーザがユーザ端末５５０でユーザＩＤ（およびパスワードなど）を手入力し、マスタサーバ５２０がＩＤ情報データベース５２１のユーザ情報を照会して認証するなどの方法がある。
【００２９】
上述でユーザ端末５５０に表示されるメニューページ（Ｓ９４０）の例を図１０に示す。メニューページ１０００は、本実施形態のビデオ配信システムで提供しているサービスを選択するボタンが表示されたＷｅｂページである。ユーザが「ＩＰテレビ電話」ボタン１０１０をクリックすると、ユーザ端末５５０でＩＰテレビ電話システム（図５の５７２）によるＩＰ電話サービスを利用することができる。「ビデオ配信」ボタン１０２０をクリックすると、ユーザ端末５５０で本実施形態のビデオ配信システムによるビデオ配信サービスを利用することができる。
【００３０】
ここでは、ユーザが「ビデオ配信」サービスを選択したとして説明する。メニューが選択される（Ｓ９５０）と、ローカルサーバ５７０からビデオ配信ページが送信される（Ｓ９６０）。
ビデオ配信ページの例を図１１に示す。ビデオ配信ページ１１００には、番組の番組名１１１０（番組１，番組２，番組３，…）を一覧表示している。ローカルサーバ５７０が持っている番組の情報は、ローカルＩＤ情報データベース５７４の「主ビデオライブラリ表」に有しているため、自動的に一覧表示することもできる。
また、各番組名１１１０の右隣には、ユーザがその番組を選択するための「選択」ボタン１１２０を表示している。「選択」ボタン１１２０を表示するほか、番組名をハイパーリンクで表示するなどの方法を用いてもよい。また、番組名のほか、番組の出演者名や時間などの情報を表示してもよい。また、ユーザが見やすいよう、番組のジャンル等によりページや表示欄を分けて表示してもよい。
各番組の「選択」ボタン１１２０のクリックに対応して、図１２に示すようなビデオリストがユーザ端末５５０からローカルサーバ５７０に送られる。図１２は、番組１（ＶＯＤ−１）に対応するビデオリストの例であり、ＶＯＤ−１−１，ＶＯＤ−１−２，ＶＯＤ−１−３の３つの主ビデオファイルの前後に計４つの広告ビデオファイル（ＣＭ）を配信することを示している。なお、ここではユーザ端末５５０からローカルサーバ５７０にビデオリストを送るようにしているが、例えば、ユーザ端末５５０からは単に番組の選択のみを送り、選択された番組に基いてローカルサーバ５７０側であらかじめ用意しているビデオリストを参照するようにしてもよい。
【００３１】
ユーザが観たい番組を選択する（Ｓ９７０）と、ローカルサーバ５７０は該ユーザの広告配信スケジュールを生成する（Ｓ９８０）。広告配信スケジュールとは、メディアストレージ５６０に格納されている広告ビデオファイルから、該ユーザのユーザ情報にマッチする広告ビデオファイルを選択したものである。
広告配信スケジュールを一覧表で示した例が、図１３である。メディアストレージ５６０に格納されている広告ビデオファイルＣＭ−１〜ＣＭ−ｍについて、広告ビデオのタイトル（ファイル名などでもよい）と配信頻度を表示している。
配信頻度とは、該広告ファイルを配信する頻度（全広告ビデオファイル内における重み付け）である。簡単な例では、ＣＭ−１が配信頻度１，ＣＭ−２が配信頻度２である場合、最初にアクセスしたユーザにはＣＭ−１，次にアクセスしたユーザにはＣＭ−１，その次のユーザにはＣＭ−２というように、全体の配信回数（ここでは３回）がこの配信頻度に対応する（全３回中、ＣＭ−１が２回、ＣＭ−２が１回）ように配信する。配信頻度は、例えば広告主が支払う料金などに応じて定める。
各広告ビデオファイルには、配信頻度のほか、ユーザ情報に対応する項目（ここでは地域・性別・年齢・嗜好）の内容があらかじめ登録されている。例えば車の広告ビデオについて「関東圏に住む２０代〜３０代の旅行に興味がある男性」を配信のターゲットとしたい場合、その広告ビデオファイルは「地域」「性別」「年齢」「嗜好」の各項目でそのように決めておくことができる。もちろんこれらの項目は必要に応じて設定すればよく、項目の一部または全部を「不問」としてもよい。
【００３２】
図１３の広告配信スケジュールに示された○印と斜線は、あるユーザがその広告ビデオの配信条件にマッチしたことを示している。図１３では、ＣＭ−２は地域がマッチ、ＣＭ−３は性別と年齢がマッチ、ＣＭ−４は嗜好がマッチ、ＣＭ−ｍは性別がマッチしている。従って、該ユーザにはＣＭ−２，ＣＭ−３，ＣＭ−４，ＣＭ−ｍを、各広告ビデオに定められた配信頻度を考慮しつつ順に、または任意に配信する。
図１４は、図１３の広告配信スケジュールに従って広告ビデオを選択して、図１２のビデオリストを完成させた例である。図１４は、ＣＭ−２，ＣＭ−３，ＣＭ−４，ＣＭ−４をリストしたことを示している。
次に、ローカルサーバ５７０は、完成したビデオリスト（図１４）に従って、配信記録データベース５７６に配信履歴を記録する（Ｓ９８５）。そして、ユーザ端末５５０に主ビデオファイル及び広告ビデオファイルの配信を行なう（Ｓ９９０）。なお、ビデオファイルのユーザ端末５５０への配信については後で詳しく説明する。
配信記録データベース５７６に記録された配信履歴は、例えば、ユーザに自分が今までに配信を受けた番組をＷｅｂページで閲覧させるなどのサービスに用いることができる。また、ビデオ配信時にこの配信履歴を参照して、例えば、該ユーザにまだ配信していない（または最近配信していない）広告ビデオを優先的に配信することも可能である。
【００３３】
このように、本実施形態のビデオ配信システムによれば、ビデオ配信をユーザ端末５５０とローカルサーバ５７０とのやり取りのみで行なうことができる。ユーザ登録処理以降、概ユーザのアクセスはローカルサーバ５７０で処理されるので、ユーザが増えてもマスタサーバ５２０に負荷が集中しない。
また、ユーザ登録時にユーザの特性に関する情報をローカルサーバ５７０に登録するため、各ユーザに適した広告ビデオファイルを配信することができ、より効果のある広告を行なうことができる。
【００３４】
＜本実施形態で提案するムービーリスト方式＞
従来技術の項で述べたように、従来のムービーリスト方式で１つのビデオプレイヤーに連続してビデオファイルを再生しようとする場合、ビデオリスト内のビデオファイルをひとつずつ、しかも前のビデオファイルの再生が終了してから、サーバに配信要求を行なう必要がある。従って、従来のムービーリスト方式では、１つのビデオファイルの再生終了から次のビデオファイルの再生開始までの間、ビデオプレイヤーでの映像が途切れてしまい、空白時間が生じるという問題があった。
本実施形態では、現在一般的に使用されているビデオプレイヤー（例えばＷｉｎｄｏｗｓ（登録商標）  Ｍｅｄｉａ  Ｐｌａｙｅｒなど）を使用して、ビデオリストの各ビデオファイルを空白時間が生じることなく、１つのビデオファイルとして再生することができる新しいムービーリスト方式であり、それを実現するための方式１〜方式３の３つの方式を提案する。方式１は、ローカルサーバ５７０で空白時間をなくす制御（遅延制御）を行なうものであり、方式２および３は、ユーザ端末５５０で空白時間をなくす制御（遅延制御）を行なうものである。
以降、これらの方式について順に詳しく説明する。
【００３５】
（方式１）
方式１は、従来のムービーリスト方式のようにビデオリスト内のビデオファイルをユーザ端末５５０から１件ずつ配信要求するのではなく、ローカルサーバ５７０内のビデオリストを用いて、これらのビデオファイルを空白時間なく配信できるように、ビデオファイル間に生じる遅延を制御して、ユーザ端末５５０に１つのファイルを再生するように連続して配信する方式である。
すなわち、本方式では、１回の番組配信要求に対して複数（ここでは２つとして説明）のバッファをローカルサーバ５７０内に用意し、これらの複数のバッファにビデオリスト内のビデオファイルを順次（２つの場合交互に）蓄積し、ビデオファイルごとに順次（交互に）切り替えて読み出すことにより、ユーザ端末５５０に番組のビデオファイルを空白時間なく送信する。ここで、本方式では、上記で用意するバッファの容量を節約するために、ローカルサーバ５７０内での遅延を計測し、その遅延時間に応じてバッファ容量を決める。また、各ビデオファイルの配信要求を、この遅延時間を考慮して早めに出すことにより、さらにバッファ容量を節約することもできる。
本方式では、この遅延制御をローカルサーバ５７０のビデオインサータ５９０で行なうため、ユーザ端末５５０には特別な装置やソフトウェアを新たに用意する必要はない。
図１５は、本方式によるビデオ配信の処理を示したブロック図である。以降、このブロック図を参照しながら本方式の処理を詳しく説明する。
【００３６】
（ユーザ端末側の処理）
ユーザがビデオ配信ページで見たい番組を選択すると、ユーザ端末５５０のＯＣＸ５５４は、図１５に示すように、ビデオプレイヤー５５６を起動する。
ローカルサーバ５７０からは、これらのビデオファイルが空白時間なく配信されるため、ビデオプレイヤー５５６はこれらを１つのビデオファイルとして再生することができる。再生が終了すると、再生終了の信号をＯＣＸ５５４に渡す。
【００３７】
（ローカルサーバ側の処理）
一方、ローカルサーバ５７０は、図１５のビデオインサータ５９０のブロック図および図１６のフローチャートに示す処理を行なって、ビデオリストの順にビデオファイルを空白時間なく送信バッファ５９５に蓄積して、ユーザ端末５５０に配信する。以降、これらの図を参照しながらローカルサーバ５７０で行なう処理を説明する。
まず、前処理として、ユーザ端末５５０がビデオプレイヤー５５６を起動し、ビデオファイルを受信するためにポート５５２とローカルサーバ５７０のポート５７８とでセッションが張られると、ビデオインサータ５９０は、１つのユーザ（セッション）に対して２つの仮想ビデオプレイヤー（仮想ビデオプレイヤー１  ５９１および仮想ビデオプレイヤー２  ５９３）を生成する。なお、ここでは仮想ビデオプレイヤーは２つとして説明するが、本方式では３つ以上生成して利用することも可能である。これらの仮想ビデオプレイヤーは、実際に表示装置に表示することはしないが、ユーザ端末５５０のビデオプレイヤー５５６と同じように振舞うものである。
【００３８】
次に、ビデオインサータ５９０は、ローカルサーバ５７０の遅延を測定する（Ｓ１６１０）。この遅延時間は、ビデオインサータ５９０が仮想ビデオプレイヤーに、ビデオサーバ５８０に対して配信要求を出すよう指示してから、仮想ビデオプレイヤーで再生が開始されるまでの時間である。この時間は、現在ローカルサーバ５７０にアクセスしているユーザ端末数などの要因で変動するため、ユーザ端末５５０からアクセスがある（ポート５５２とポート５７８とでセッションが張られる）たびに測定する。遅延の測定は、例えば、上記で起動した仮想ビデオプレイヤーを用いて、あらかじめローカルサーバ５７０のメディアストレージ５６０に用意しているテスト用のビデオファイルを再生させることにより行なう。
なお、本方式では、この遅延時間を正確に把握するために、主ビデオファイルと広告ビデオファイルを物理的に同一の場所（ここではローカルサーバ５７０のメディアストレージ５６０）に格納し、主ビデオサーバ５８２と広告ビデオサーバ５８４を、物理的にビデオインサータ５９０と同一のサーバ（ここではローカルサーバ５７０）に置くことが望ましい。他のネットワークやインターネットを経由すると、伝送路の遅延に様々な要因が重なり、これを制御することは困難だからである。
【００３９】
次に、測定した遅延時間に応じて、各々の仮想ビデオプレイヤー（仮想ビデオプレイヤー１  ５９１，仮想ビデオプレイヤー２  ５９３）に対応して用いる送信バッファ（送信バッファ１  ５９２，送信バッファ２  ５９４）用のメモリを確保する（Ｓ１６２０）。これらの送信バッファは、ユーザ端末５５０にビデオファイルを送信するための送信バッファ５９５にビデオファイルを順次空白なく蓄積できるように、ビデオサーバ５８０がビデオファイルを読み出して交互に蓄積させるバッファである。
このように、遅延時間に応じて送信バッファ用のメモリを確保すれば、ローカルサーバ５７０のリソースを無駄なく利用することができるので、本方式は小規模なサーバをローカルサーバ５７０として用いる場合にも対応できる。なお、例えばローカルサーバ５７０が充分なリソースを有する場合などは、遅延時間を計測しないで処理に充分なメモリを確保（Ｓ１６２０）することも可能である。
次に、ビデオインサータ５９０は、ユーザ端末５５０からビデオリスト（図１２参照）を受信し（Ｓ１６３０）、上述で説明したように広告ビデオ配信スケジュール（図１３参照）を生成して（Ｓ１６４０）、配信する広告ビデオファイルを決定し、ビデオリストを完成（図１４参照）する（Ｓ１６５０）。なお、上述したように、ビデオリストをユーザ端末５５０から受信する代わりに、例えばユーザ端末５５０からは番組の選択のみが送られ、ローカルサーバ５７０側であらかじめ番組に対応して用意しているビデオリストを参照するようにしてもよい。
【００４０】
以降、ビデオインサータ５９０は、完成したビデオリストをひとつずつ読み出して、複数（ここでは２つ）の仮想ビデオプレイヤー（仮想ビデオプレイヤー１  ５９１，仮想ビデオプレイヤー２  ５９３）を交互に実行（Ｓ１６６０）する。
すなわち、図１５に矢印で示すように、仮想ビデオプレイヤーに、ビデオサーバ５８０に対してビデオファイルの配信要求を出すよう指示する。そうすると、仮想ビデオプレイヤーはビデオサーバ５８０に配信要求を行ない、ビデオサーバ５８０は配信要求に応じてメディアストレージ５６０からビデオファイルを読み出して、その仮想ビデオプレイヤーに対応する送信バッファ（送信バッファ１  ５９２または送信バッファ２  ５９４）に蓄積する。このようにして、送信バッファ１  ５９２および送信バッファ２  ５９４に交互にビデオファイルを蓄積する。
そして、仮想ビデオプレイヤーでビデオファイルの再生が終了するごとに、再生終了の信号を受け取ったビデオインサータ５９０は、他方の仮想ビデオプレイヤーに再生開始の命令を出すとともに、対応する送信バッファ１  ５９２と送信バッファ２  ５９４とを切り替えて、送信バッファ５９５への出力を切り替える。このようにして、複数のビデオファイルを空白時間なく送信バッファ５９５に書き込むことができる。
以降、ビデオインサータ５９０は、ビデオファイルが終了するまで（図１６のＳ１６７０でＹｅｓになるまで）、上述の処理を２つの仮想ビデオプレイヤーに対して交互に繰り返す。そして、ビデオリストの全てのビデオファイルの配信が終了したら、ポート５５２とローカルサーバ５７０のポート５７８とのセッションを終了する。
【００４１】
このようにビデオインサータ５９０が遅延制御を行なうことにより、本方式では、送信バッファ５９５にビデオリストのビデオファイルを順に空白時間を生じることなく蓄積することができる。その結果、ユーザ端末５５０のビデオプレイヤー５５６は、送信バッファ５９５から送られてくるビデオデータを１つのビデオファイルとして再生するだけでよい。そして、ビデオプレイヤー５５６からの再生終了の信号をＯＣＸ５５４が受取ることにより、一連の番組配信処理が終了する。
【００４２】
また、上述したように、計測した遅延時間（Ｓ１６１０）を考慮して、一方の仮想ビデオプレイヤーでの再生終了（送信バッファ５９５へのビデオファイル読み出し終了）より少し早めにビデオリスト内の次のビデオファイルの配信要求を他方の仮想ビデオプレイヤーに出すようにすれば、上述で確保（Ｓ１６２０）する送信バッファ１，２のバッファ容量をさらに節約することができる。
この処理を、図１７（ａ）のタイムチャートのＴ０〜Ｔ６ごとに、図１５のブロック図を参照しながら説明する。なお、図１７（ａ）（ｂ）に表示しているビデオファイル名は、図１４に示したビデオリストに対応している。
（Ｔ０）ビデオインサータ５９０は、ビデオリストの最初のビデオファイルＣＭ−２の配信要求をビデオサーバ５８０に対して行なうよう、仮想ビデオプレイヤー１  ５９１に指示を出す。
すると、上述と同様に、仮想ビデオプレイヤー１  ５９１は、ビデオサーバ５８０にＣＭ−２の配信要求を送信し、ビデオサーバ５８０はメディアストレージ５６０から読出バッファ５８６を用いて広告ビデオファイルＣＭ−２を読み出して、送信バッファ１  ５９２に蓄積する。そして、仮想ビデオプレイヤー１  ５９１はＣＭ−２の再生を行っているように動作し、再生を開始するとともに、ビデオインサータ５９０は送信バッファ１  ５９２から送信バッファ５９５へＣＭ−２の書き込みを開始する。ここで、配信要求の指示（Ｔ０）から仮想ビデオプレイヤー１  ５９１でＣＭ−２の再生（ＣＭ−２の送信バッファ５９５への書き込み）が開始するまでの時間は、図１７（ａ）のＣＭ−２の左側の斜線部である。
【００４３】
（Ｔ１）次に、ビデオインサータ５９０は、ビデオリストの２番目のビデオファイル（ＶＯＤ−１−１）の配信要求をビデオサーバ５８０に対して行なうよう、仮想ビデオプレイヤー２  ５９３に指示を出す。ここで、この指示は、仮想ビデオプレイヤー１  ５９１でのＣＭ−２の再生が終了したらすぐに仮想ビデオプレイヤー２  ５９３でのＶＯＤ−１−１の再生が開始できる程度に、上述で測定したサーバの遅延時間を考慮して、ＣＭ−２の再生終了より早めに行なう。
この指示により、仮想ビデオプレイヤー２  ５９３は、ビデオサーバ５８０にＶＯＤ−１−１の配信要求を送る。ビデオサーバ５８０はメディアストレージ５６０から読出バッファ５８６を用いて主ビデオファイルＶＯＤ−１−１を読み出して、送信バッファ２  ５９４に蓄積を開始する。
【００４４】
（Ｔ２）仮想ビデオプレイヤー１  ５９１からＣＭ−２の再生を終了した旨の信号が送られると、ビデオインサータ５９０は仮想ビデオプレイヤー２  ５９３にＶＯＤ−１−１の再生開始を指示し、送信バッファ５９５にビデオファイルを出力するバッファを、送信バッファ１  ５９２から送信バッファ２  ５９４に切り替える。Ｔ１〜Ｔ２の斜線で示した分早めに指示を出している結果、ビデオファイルの再生と送信バッファ５９５への書き込みを交互に切れ目無く行なうことができる。ここで、送信バッファの容量はＴ１〜Ｔ２の分を蓄積すればよいため、上述の方法よりもバッファ容量を節約することができる。ＶＯＤ−１−１は前のＣＭ−２に続けて送信バッファ５９５に蓄積され、ユーザ端末５５０に送信される。
【００４５】
以降、ビデオファイルが終了するまで（図１６のＳ１６７０でＹｅｓになるまで）、ビデオインサータ５９０は、上述と同様の処理を２つの仮想ビデオプレイヤーに対して交互に繰り返す。
具体的には、図１７（ａ）に示すように、
（Ｔ３）仮想ビデオプレイヤー１  ５９１に対してＣＭ−３の配信要求を指示
（Ｔ４）送信バッファ２  ５９４から送信バッファ１  ５９２へ出力切り替え指示
（Ｔ５）仮想ビデオプレイヤー２  ５９３に対してＶＯＤ−１−２の配信要求を指示
（Ｔ６）送信バッファ１  ５９２から送信バッファ２  ５９４へ出力切り替え指示
の処理を、ビデオリストにリストされた全てのビデオファイルに対して順に行なう。
【００４６】
上述のビデオインサータ５９０の処理により、本方式では、図１７（ｂ）に示すように、送信バッファ５９５にビデオリストのビデオファイルを順に空白時間を生じることなく送ることができ、しかも、送信バッファ１  ５９２および送信バッファ２  ５９４に用いるメモリの容量をより節約することができる。
【００４７】
（方式２）
上述の方式１では、ローカルサーバ５７０で、ビデオファイル間の空白時間がなくなるように制御している。
一方、ここで説明する２つめの方式は、ビデオファイル間の空白時間をなくす遅延制御をユーザ端末５５０側の処理のみで行なう。すなわち、ユーザ端末５５０内に受信バッファを用意し、該受信バッファに、ビデオリストを最後まで空白時間を生じることなく再生できる程度にビデオデータを蓄積した後に、ビデオプレイヤー５５６での再生を開始する。
従って、図１５に示したローカルサーバ５７０中のビデオインサータ５９０は必要ない。そのため、既にサービスの提供者が既存の配信サーバを有している場合にも、その既存のサーバを利用して容易に本方式を導入できるという利点がある。
【００４８】
図１８は、本方式の処理を説明したブロック図である。上述したように、空白時間をなくす遅延制御はユーザ端末５５０で行なうため、サーバ側は図示していない。また、本方式は、ビデオ配信システムの構成がマスタサーバとローカルサーバによる分散システムでなくても利用できる。
ユーザ端末５５０には、ビデオプレイヤー５５６のほか、ビデオプレイヤー５５６にビデオファイルを空白時間なく再生させるために、遅延制御５５５および受信バッファ５５３を配備する。この遅延制御５５５はＯＣＸ等で実現され、ビデオプレイヤー５５６の起動、ビデオプレイヤー５５６からの再生終了の受信、ローカルサーバ５７０への配信要求のほか、ローカルサーバ５７０への配信終了問合せを行なう機能を持たせる。なお、これらの機能については後で説明する。
【００４９】
図１９（ａ）は、本方式の遅延制御５５５が、ローカルサーバ５７０へのビデオファイルの配信要求と受信バッファ５５３への書き込みを行なう処理を示したフローチャートである。
ユーザがユーザ端末５５０で見たい番組を決定し、ビデオファイルを受信するためにポート５５２とローカルサーバ５７０のポート５７８とでセッションが張られると、遅延制御５５５は、まずローカルサーバ５７０の遅延を測定する（Ｓ１９０５）。この遅延時間は、遅延制御５５５がローカルサーバ５７０に配信要求を行なってから、要求したビデオファイルがポート５５２に到達するまでの時間である。この時間は、サーバの混雑や通信回線の混雑などにより変動するため、セッションが張られるたびに測定する。
遅延時間は、例えばユーザ端末５５０からローカルサーバ５７０に、メディアストレージ５６０にあらかじめ用意したテスト用のファイルの配信要求を送ることにより測定する。ビデオファイルを他のサーバにも分けて格納している場合には、それぞれのサーバにテスト用ファイルを用意して、各サーバの遅延時間を計測する。
【００５０】
次に、遅延制御５５５は、測定した遅延時間に対応して遅延制御値を決定し、受信バッファ５５３用のメモリを確保する（Ｓ１９１０）。
遅延制御値は、ビデオリストの複数のビデオファイルを最後まで空白時間を生じることなく再生できる程度に最初に受信バッファ５５３にビデオデータを蓄積させる時間であり、受信バッファ５５３用のメモリも、この遅延制御値に対して必要な容量（この容量は、ビデオファイル間の空白時間分の容量より大きいことになる）を確保する。このように遅延時間に対応して受信バッファ５５３用のメモリを確保することで、ユーザ端末５５０のリソースを節約することができる。このため、パソコンの他、携帯電話やＰＤＡなど様々なユーザ端末５５０に本方式を利用できる。なお、例えばユーザ端末５５０が充分なリソースを有する場合などは、遅延時間を計測しないで上記のメモリ確保（Ｓ１９１０）をすることも可能である。
【００５１】
次に、遅延制御５５５は、要求した番組に対応するビデオリストをローカルサーバ５７０から取得し（Ｓ１９１５）、そのビデオリストから１つずつ読み出して（Ｓ１９２０）、ローカルサーバ５７０にビデオファイルの配信要求を送る（Ｓ１９３０）。受信したビデオファイルは、受信バッファ５５３に書き込む（Ｓ１９３５）。また、ローカルサーバ５７０に対して、そのビデオファイルの配信を終了したかどうかを問合せる（Ｓ１９４０）。この問合せは、配信終了の返答が来るまで（Ｓ１９４５でＹｅｓになるまで）例えば数ミリ秒毎などの定期的に繰り返し行なう。配信終了の返答を受け取ったら（Ｓ１９４５でＹｅｓ）、ビデオリストから次の１件を読み出して（Ｓ１９２０）、そのビデオファイルの配信要求を送り（Ｓ１９３０）、受信バッファ５５３に書き込む（Ｓ１９３５）。これを、ビデオリストが終了するまで（Ｓ１９２５でＹｅｓになるまで）繰り返す。
なお、ローカルサーバ５７０は番組の配信要求があった時点で上述の広告配信スケジュール（図１３）を生成し、それに従ったビデオリスト（図１４）を作成してユーザ端末５５０に送っている（ユーザ端末５５０側では図１９のＳ１９１５に対応）。
【００５２】
ここで、受信したビデオファイルをすぐにビデオプレイヤー５５６で再生したのでは、上述の遅延時間（Ｓ１９０５）のためにビデオファイル間に空白時間が生じてしまう。このため本方式では、上述したように、配信されたビデオファイルを受信バッファ５５３にいったん蓄積してから、ビデオプレイヤー５５６への送信を開始することで、ビデオプレイヤー５５６で再生した時に空白時間が生じないようにする。
図１９（ｂ）は、本方式の遅延制御５５５が、ビデオプレイヤー５５６に対して行なう指示を示したフローチャートである。
ユーザがユーザ端末５５０で見たい番組を決定すると、遅延制御５５５は、受信バッファ５５３からビデオファイルを読み出して再生するよう指示してビデオプレイヤー５５６を起動する（Ｓ１９９２）。そうすると、ビデオプレイヤー５５６は、上述の図１９（ａ）に示した処理で受信バッファ５５３に蓄積されているビデオファイルを読み出して、再生する。ローカルサーバ５７０から受信する際にビデオファイル間に空白時間が生じても、受信バッファ５５３の容量はそれ以上あるので、空白時間中はバッファ中に蓄積されたものが再生され、実質的に空白時間は生じない。
【００５３】
このように、本方式では、ビデオリストの最後まで空白時間なく再生できるように、ユーザ端末５５０側で、測定したサーバ遅延時間に応じて受信バッファ５５３に蓄え、再生開始を遅らせている。ビデオプレイヤー５５６は、受信バッファ５５３から送られてくるビデオデータを１つのビデオファイルとして再生するだけでよい。この１つのビデオファイルの再生が終了すると、遅延制御５５５はビデオプレイヤー５５６から再生終了の信号を受信する（Ｓ１９９４）。
【００５４】
（方式３）
方式３は、上述の方式２と同様ユーザ端末５５０側で遅延制御を行なうが、ビデオリストのビデオファイル全てについて１件ずつ配信要求するのではなく、ビデオリスト中の広告ビデオファイルを先にユーザ端末５５０にダウンロードしておき、主ビデオファイルのみを方式２と同様に１件ずつ配信要求する方式である。
広告ビデオファイルは比較的ファイルサイズが小さい（再生時間が短い）ため、１回の番組配信に必要な数個の広告ビデオファイルをユーザ端末５５０に一時的に格納しても支障はなく、また、ダウンロードも短時間で行なえる。そして、リアルタイムにダウンロードするファイルは主ビデオファイルのみになるため、配信要求と配信終了問合せの処理がその分少なくなり、ユーザ端末５５０での処理が軽快となる。
このため、方式２のように既に配信サーバを有している場合にも導入できるほか、例えば携帯電話やＰＤＡ等の端末をユーザ端末５５０として用いるビデオ配信システムにおいても、容易に導入することができる。
【００５５】
図２０は、本方式の処理を示したブロック図である。方式２と同様、ユーザ端末５５０で遅延制御を行なうため、ユーザ端末５５０側のみを図示している。また、本方式も方式２と同様、ビデオ配信システムの構成がマスタサーバとローカルサーバによる分散システムでなくても利用できる。
本方式では、主ビデオファイルの配信は方式２と同様の方法で１件ずつ行なうのに対し、広告ビデオファイルの配信は最初に一括して行なう。それぞれの通信を行なうために、ポート１  ５５２ａおよびポート２  ５５２ｂの２つのポートを使用する。主ビデオファイルはポート１  ５５２ａを介して受信して受信バッファ５５３に蓄積される。また、広告ビデオファイルはポート２  ５５２ｂを介して最初に一括受信して広告ビデオバッファ５５９に蓄積される。一方、ビデオプレイヤー５５６は、主ビデオファイルを受信バッファ５５３から読み出して再生し、広告ビデオファイルを広告ビデオバッファ５５９から読み出して再生する。
これらの処理は、ＯＣＸ等で実現した遅延制御５５５が行なう。遅延制御５５５には、方式２と同様に、ビデオプレイヤー５５６の起動、ビデオプレイヤー５５６からの再生終了の受信、ローカルサーバ５７０への配信要求、ローカルサーバ５７０への配信終了問合せを行なう機能を持たせる。
【００５６】
図２１（ａ）は、本方式の遅延制御５５５が、ローカルサーバ５７０へのビデオファイルの配信要求と受信バッファ５５３および広告ビデオバッファ５５９への書き込みを行なう処理のフローチャートである。
ユーザがユーザ端末５５０で見たい番組を決定し、ビデオファイルを受信するためにセッションが張られると、サーバの遅延を測定し（Ｓ２１０５）、遅延制御値を決定して受信バッファ５５３用のメモリを確保する（Ｓ２１１０）点は、方式２と同様である。
次に、遅延制御５５５は、ビデオリストをローカルサーバ５７０から取得し（Ｓ２１１５）、ローカルサーバ５７０に広告ビデオファイルの配信を要求する（Ｓ２１２０）。方式２と同様に、ローカルサーバ５７０は番組の配信要求があった時点で上述の広告配信スケジュール（図１３）を生成し、それに従ったビデオリスト（図１４）を作成してユーザ端末５５０に送っている。このため、ここではビデオリスト（図１４参照）にリストされている広告ビデオファイルを配信するよう、ローカルサーバ５７０に要求を送信する。
配信された広告ビデオファイルは、広告ビデオバッファ５５９に書き込む（Ｓ２１２５）。
【００５７】
次に、遅延制御５５５は、取得したビデオリストを１件ずつ読み出して（Ｓ２１３０）、それが主ビデオである場合（Ｓ２１４０でＹｅｓの場合）には、上述の方式２と同様に、ローカルサーバ５７０への配信要求を行なう（Ｓ２１４５）。配信された主ビデオファイルは、受信バッファ５５３に書き込む（Ｓ２１５０）。一定時間毎に配信終了をローカルサーバ５７０に問い合わせて（Ｓ２１５５）、配信終了の返答を受け取ったら（Ｓ２１６０でＹｅｓ）、ビデオリストの次の１件を読み出す（Ｓ２１３０）。一方、広告ビデオファイルは既に配信を受けて広告ビデオバッファ５５９に記憶されている（Ｓ２１２５）ため、ビデオリストが広告ビデオである場合（Ｓ２１４０でＮｏの場合）には、何もしないでビデオリストの次の１件を読み出すステップ（Ｓ２１３０）に戻る。
以上の処理を、ビデオリストが終了するまで（Ｓ２１３５でＹｅｓになるまで）繰り返して、主ビデオファイルと広告ビデオファイルの配信を受ける。
【００５８】
図２１（ｂ）は、本方式の遅延制御５５５が、ビデオプレイヤー５５６に対して行なう指示を示したフローチャートである。方式２と異なり、ビデオファイルを受信バッファ５５３と広告ビデオバッファ５５９とに分けて蓄積しているため、遅延制御５５５は、ビデオリストに従って順次、ビデオプレイヤー５５６にビデオファイルの読み込み・再生を指示する。
ユーザがユーザ端末５５０で見たい番組を決定すると、図２１（ｂ）に示すように、遅延制御５５５は、上述で取得（図２１（ａ）のＳ２１１５）したビデオリストをひとつずつ読み出す（Ｓ２１９１）。
そして、それが主ビデオである場合（Ｓ２１９３でＹｅｓの場合）、遅延制御５５５は、受信バッファ５５３からビデオファイルを読み出して再生するよう指示してビデオプレイヤー５５６を起動する（Ｓ２１９４）。そうすると、ビデオプレイヤー５５６は、上述の図２１（ａ）に示した処理で受信バッファ５５３に蓄積されているビデオファイルを読み出して、再生する。ローカルサーバ５７０から受信する際にビデオファイル間に空白時間が生じても、受信バッファ５５３の容量はそれ以上あるので、空白時間中はバッファ中に蓄積されたものが再生され、実質的に空白時間は生じない。ビデオプレイヤー５５６は、指示されたビデオファイルの再生を終了すると、遅延制御５５５に再生終了の信号を送るので、遅延制御５５５はそれを受信（Ｓ２１９６）して、ビデオリストの次の１件を読み出す（Ｓ２１９１）。
【００５９】
一方、広告ビデオである場合（Ｓ２１９３でＮｏの場合）には、遅延制御５５５は、広告ビデオバッファ５５９からビデオファイルを読み出して再生するよう指示してビデオプレイヤー５５６を起動する（Ｓ２１９５）。そうすると、ビデオプレイヤー５５６は、上述の図２１（ａ）に示した処理で広告ビデオバッファ５５９に蓄積されているビデオファイルを読み出して、再生する。ビデオプレイヤー５５６は、指示されたビデオファイルの再生を終了すると、遅延制御５５５に再生終了の信号を送るので、遅延制御５５５はそれを受信（Ｓ２１９６）して、ビデオリストの次の１件を読み出す（Ｓ２１９１）。
遅延制御５５５は、上記の処理を、ビデオリストが終了するまで繰り返す。
これにより、ビデオプレイヤー５５６は、遅延制御５５５の指示通りに受信バッファ５５３および広告ビデオバッファ５５９から複数のビデオファイルを空白時間なくビデオリストの順に読み出して再生することができる。
【図面の簡単な説明】
【００６０】
【図１】従来のビデオ配信システムのシステム構成例である。
【図２】従来のビデオ配信システムで従来のムービーリスト方式を用いる場合のブロック図である。
【図３】従来のムービーリスト方式で番組に対応して用意するビデオリストの例である。
【図４】従来のムービーリスト方式でビデオリストによる配信・再生処理を行なう場合の通信シーケンスである。
【図５】本実施形態のビデオ配信システムのシステム構成例である。
【図６】本実施形態のＩＤ情報データベースを構成する項目の例を示す図である。
【図７】本実施形態のローカルＩＤ情報データベースを構成する項目の例を示す図である。
【図８】本実施形態におけるユーザ登録時のユーザ端末・マスタサーバ・ローカルサーバ間の通信シーケンスである。
【図９】本実施形態におけるビデオ配信時のユーザ端末・マスタサーバ・ローカルサーバ間の通信シーケンスである。
【図１０】本実施形態のメニューページの例である。
【図１１】本実施形態のビデオ配信ページの例である。
【図１２】本実施形態で番組に対応して用意するビデオリストの例である。
【図１３】本実施形態で生成される広告ビデオ配信スケジュールの例である。
【図１４】本実施形態で図１３の広告ビデオ配信スケジュールに従って完成させた図１２のビデオリストである。
【図１５】本実施形態で提案する新しいムービーリスト方式１のブロック図である。
【図１６】方式１のビデオインサータの処理を示したフローチャートである。
【図１７】方式１のビデオインサータによる制御を時系列で示した図である。
【図１８】本実施形態て提案する新しいムービーリスト方式２のブロック図である。
【図１９】方式２の遅延制御の処理を示したフローチャートである。
【図２０】本実施形態て提案する新しいムービーリスト方式３のブロック図である。
【図２１】方式３の遅延制御の処理を示したフローチャートである。
【図１】
0004448936.tif 000002
【図２】
0004448936.tif 000003
【図３】
0004448936.tif 000004
【図４】
0004448936.tif 000005
【図５】
0004448936.tif 000006
【図６】
0004448936.tif 000007
【図７】
0004448936.tif 000008
【図８】
0004448936.tif 000009
【図９】
0004448936.tif 000010
【図１０】
0004448936.tif 000011
【図１１】
0004448936.tif 000012
【図１２】
0004448936.tif 000013
【図１３】
0004448936.tif 000014
【図１４】
0004448936.tif 000015
【図１５】
0004448936.tif 000016
【図１６】
0004448936.tif 000017
【図１７】
0004448936.tif 000018
【図１８】
0004448936.tif 000019
【図１９】
0004448936.tif 000020
【図２０】
0004448936.tif 000021
【図２１】
0004448936.tif 000022