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