JP2009049561A - ユーザ端末装置、サーバ、再生方法、データ送信方法及びプログラム - Google Patents

Abstract

【課題】 サブデータの再生に当たって、メインデータの読み込みタイミングや再生開始タイミングの遅延を抑止すること。
【解決手段】 第一の動画像・音声データの受信をサーバに要求し、第一の動画像・音声データの受信を開始し、第一の動画像・音声データの再生を開始する前であって、当該第一の動画像・音声データの受信中に、第二の動画像・音声データの受信及び再生を開始し、第二の動画像・音声データの再生が終了した後に、第一の動画像・音声データの再生を開始する。
【選択図】 図２

Description

本発明は、インターネット等のネットワークを介して、複数の動画像データや音声データの送信を可能とする技術に関する。

従来から、インターネット等のネットワークを介して広告を配信する技術が種々提案されている。例えば、ユーザが閲覧するウェブサイト内にバナー広告などを掲載することによって、広告を配信する方法もある。このような方法は、現在様々なウェブサイトにおいて適用されており、一般ユーザが閲覧するウェブサイト内には複数のバナー広告が貼付されていることが多い。

また、ネットワークを介してゲームソフトをダウンロードできるシステムにおいては、そのゲーム中に広告が配信される技術も提案されている。例えば、ゲーム実行中に広告情報が表示され、広告内容がゲーム実行者に配信される技術がある（特許文献１参照）。

また、いわゆるテレビ番組のように、動画像コンテンツ（ユーザが視聴を望むコンテンツ）の視聴前に広告動画像を表示させることにより、動画像コンテンツの視聴を希望するユーザに対していわば強制的に広告動画像を視聴させる技術も提案されている。具体的には、動画像コンテンツの視聴をユーザが選択すると、動画像コンテンツがユーザ端末装置に読み込まれる前に、まずは広告動画像のデータの読み込みが開始される。
特開２００７−０３３５８６号公報

しかしながら、このような従来の広告配信技術には、ユーザにとって不都合となる問題があった。ウェブサイト内にバナー広告を貼付する方法や、ゲーム実行中に広告情報を表示する方法の場合、画面内に広告表示スペースを設ける必要がある。このため、そもそもユーザが閲覧を希望するウェブサイト中の情報を表示するスペースや、ゲームを表示するスペースが、広告表示スペースによって小さくなってしまっていた。このような問題は、特に画面の大きさが限定されている携帯端末を用いる場合には顕著な問題となる。

また、動画像コンテンツの視聴前・後に広告動画像を表示させる方法の場合、動画像コンテンツの再生と広告動画像の再生とが異なるタイミングであるため、同一のスペースで再生することにより、前述のようなスペースの問題は解消される。しかしながら、ユーザが視聴を所望する動画像コンテンツの読み込みが開始される前に、ユーザにとっては不必要な（特に視聴を所望しない）広告動画像のデータの読み込みや再生が開始されてしまう。このため、動画像コンテンツの読み込みや再生が遅れてしまうという問題があった。さらに、このような問題に起因して、メインデータの視聴を所望するユーザにとって精神的なストレスが生じてしまうという問題もあった。

このような問題は、広告を目的とした動画像に限定されるわけではなく、ユーザが視聴を所望する動画像コンテンツや音声コンテンツのデータ（以下、「メインデータ」という。）とは異なる、第二の動画像や音声のデータ（以下、「サブデータ」という。）を再生させる際に共通する問題であった。

そこで、本発明は、上述したようなサブデータの再生に当たって、メインデータの読み込みタイミングや再生開始タイミングの遅延を抑止することを可能とする装置や方法やプログラム等を提供することを目的とする。

本発明の第一の態様は、ユーザ端末装置であって、第一の要求手段及び制御手段を備える。第一の要求手段は、第一の動画像・音声データの受信をサーバに要求する。制御手段は、第一の動画像・音声データ、及び、サーバから送信される第二の動画像・音声データの受信・再生を制御する。ここで、第一の動画像・音声データは、背景や課題における「メインデータ」に相当し、第二の動画像・音声データは、背景や課題における「サブデータ」に相当する。

このような構成において、制御手段は以下のように動作する。制御手段は、第一の動画像・音声データの受信を開始した後、第一の動画像・音声データの再生を開始する前に、第二の動画像・音声データを受信し再生する。また、制御手段は、第二の動画像・音声データを受信し再生している間も、第一の動画像・音声データについて、再生は行うことなく受信を続ける。また、制御手段は、第二の動画像・音声データの再生が終了した後に、第一の動画像・音声データの再生を開始する。

このように構成されることにより、第二の動画像・音声データの受信や再生の処理が行われている間に、第一の動画像・音声データの受信処理が進行する。そして、第二の動画像・音声データの再生が完了した後に、第一の動画像・音声データの再生が開始される。このため、従来のように第二の動画像・音声データ（主に広告の動画像のデータ）の受信及び再生が終了してから第一の動画像・音声データ（主にユーザが視聴を希望しているデータ）の読み込みが開始される場合に比べて、第一の動画像・音声データの読み込みタイミングや再生開始タイミングの遅延を抑止することが可能となる。また、従来に比べて、第二の動画像・音声データの再生時間及び第一の動画像・音声データの読み込み時間の合計時間を短縮させることが可能となる。また、第一の動画像・音声データが、ユーザが視聴を希望しているデータである場合には、その再生に際してユーザが待機する時間を短くすることにより、ユーザが感じる精神的なストレスを軽減させることが可能となる。

本発明の第二の態様は、サーバであって、受付手段、第一送信手段及び第二送信手段を備える。受付手段は、第一の動画像・音声データについての要求をクライアントから受け付ける。第一送信手段は、要求が受け付けられると、第一の動画像・音声データのクライアントへの送信を開始する。第二送信手段は、第一の動画像・音声データの送信中であって、第一の動画像・音声データの再生がクライアントにおいて可能となるまでの受信処理が完了する前に、第二の動画像・音声データのクライアントへの送信を開始する。本発明の第二の態様によっても、本発明の第一の態様と同様な効果を奏することができる。

本発明は、情報処理装置を、上記したユーザ端末装置やサーバとして動作させるためのプログラムとして特定されても良い。また、本発明は、上記したユーザ端末装置が行う再生方法や、上記したサーバが行うデータ送信方法として特定されても良い。

本発明により、第一の動画像・音声データ及び第二の動画像・音声データ受信や再生に当たって、第一の動画像・音声データの読み込みタイミングや再生開始タイミングの遅延を抑止することが可能となる。

〔概要〕
まず、本発明におけるサブデータ配信システムの概要について説明する。ユーザ端末がサーバからメインデータを受信しその再生を行う場合、ユーザ端末は、少なくとも一定量のデータの受信が完了してからでないと再生を開始することができない。このため、ユーザは、メインデータの選択をしてからその再生が開始されるまでの時間は、メインデータの再生を待機することとなる。そこで、本発明におけるサブデータ配信システムは、この時間を利用して、サブデータの配信・再生を実行することにより、メインデータの読み込みタイミングや再生開始タイミングの遅延を抑止しつつ、サブデータの再生を実現させる。即ち、サブデータが送受信され再生されている間に、メインデータの上記一定量のデータの受信が並行して実施される。

〔システム構成〕
まず、本発明におけるサブデータ配信システム１００のシステム構成例について説明する。図１は、サブデータ配信システム１００の構成例を示す図である。サブデータ配信システム１００は、インターネット等のネットワークを介して接続されるユーザ端末１０及びサーバ２０を含む。ユーザ端末１０は、ネットワークを介してサーバ２０から、メインデータ及びサブデータを受信し再生する。以下、サブデータ配信システム１００に含まれる各装置について説明する。

〈ユーザ端末〉
ユーザ端末１０は、バスを介して接続された記憶装置、演算装置及び通信制御装置を含み、記憶装置に記憶されたプログラムを演算装置において処理することによってプログラムに従って動作する。具体的には、パーソナルコンピュータやＰＤＡ（Personal Digital Assistance）や携帯電話機などの情報処理装置を用いて構成することができる。ユーザ端末１０は、入力部１１、制御部１２、送受信部１３及び出力部１４を含む装置として機能する。次に、ユーザ端末１０に含まれる各機能部について説明する

〈〈入力部〉〉
入力部１１は、ユーザ端末１０に接続された入力装置を制御する。入力装置とは、ユーザがユーザ端末１０に命令やデータを入力するために使用する装置である。入力装置は、ユーザ端末１０に備え付けられていても良い。入力装置は、ボタンやキーボードやジョグダイヤルや文字認識装置や音声認識装置などの装置である。

〈〈制御部〉〉
制御部１２は、入力部１１を介して入力されるデータに基づき、ユーザが選択したメインデータを判断し、メインデータの受信をサーバ２０に要求する。また、制御部１２は、サーバ２０がサブデータの送信について判断を行うための情報（以下、「環境情報」という。）を取得し、この環境情報に基づいてサブデータを選択する。そして、制御部１２は、選択したサブデータの受信をサーバ２０に要求する。サーバ２０に対するメインデータやサブデータの要求は、送受信部１３を介して、メインデータやサブデータを示すデータをサーバ２０へ送信することにより実現される。

また、制御部１２は、送受信部１３を介して、サーバ２０からメインデータやサブデータを受信する。また、制御部１２は、受信されたメインデータやサブデータの再生処理を行い、動画像や音声の出力を出力部１４に指示する。制御部１２の動作の詳細については、動作例の項目において、フローチャートを用いて説明する。

〈〈送受信部〉〉
送受信部１３は、ネットワークを介してサーバ２０との間でデータを送受信するために、ユーザ端末１０に接続されたネットワークインタフェース装置を制御する。このネットワークインタフェース装置に採用される技術は特に限定されない。例えば、このネットワークインタフェースは、無線通信によってネットワークに接続するための装置として構成されても良いし、有線通信によってネットワークに接続するための装置として構成されても良い。送受信部１３は、ネットワークに接続されるために採用される技術に応じて構成される。採用される技術の例として、イーサネット（登録商標）や専用線やＡＤＳＬやＦＴＴＨや無線ＬＡＮ等の技術がある。

〈〈出力部〉〉
出力部１４は、制御部１２の指示に従って文字・画像や音声の出力を制御する。出力部１４は、ユーザ端末１０に接続された出力装置に出力の指示を出す。出力装置は、ユーザ端末１０に一体的に備え付けられていても良い。なお、出力装置とは、ＣＲＴディスプレイ（Cathode Ray Tube ディスプレイ）、液晶ディスプレイ、有機ＥＬディスプレイ等の画像出力装置や、スピーカー等の音声出力装置等である。

〈サーバ〉
サーバ２０は、バスを介して接続された記憶装置、演算装置及び通信制御装置を含み、記憶装置に記憶されたプログラムを演算装置において処理することによってプログラムに従って動作する。具体的には、パーソナルコンピュータやサーバ専用装置などを用いて構成することができる。サーバ２０は、送受信部２１、制御部２２、メインデータ記憶部２３及びサブデータ記憶部２４を含む装置として機能する。次に、サーバ２０に含まれる各機能部について説明する。

〈〈送受信部〉〉
送受信部２１は、ネットワークを介してユーザ端末１０との間でデータを送受信するために、サーバ２０に接続されたネットワークインタフェース装置を制御する。このネットワークインタフェース装置に採用される技術は特に限定されない。例えば、このネットワークインタフェースは、無線通信によってネットワークに接続するための装置として構成されても良いし、有線通信によってネットワークに接続するための装置として構成されても良い。送受信部２１は、ネットワークに接続されるために採用される技術に応じて構成される。採用される技術の例として、イーサネット（登録商標）や専用線やＡＤＳＬやＦＴＴＨ等の技術がある。

〈〈制御部〉〉
制御部２２は、送受信部２１を介して、ユーザ端末１０から、メインデータの要求やサブデータの要求を受信する。制御部２２は、受信された要求に応じて、要求されたメインデータやサブデータをメインデータ記憶部２３やサブデータ記憶部２４から読み出し、ユーザ端末１０に対し送信する。制御部２２の動作の詳細については、動作例の項において、フローチャートを用いて説明する。

〈〈メインデータ記憶部〉〉
メインデータ記憶部２３は、ユーザ端末１０に対して送信可能なメインデータを記憶する。メインデータの具体例としては、動画像データや音声データなどがある。さらに具体的に説明すると、メインデータの具体例としては、ＦＬＡＳＨ（登録商標）のｆｌｖファイルやｓｗｆファイルや、ＱＵＩＣＫＴＩＭＥ（登録商標）のｍｏｖファイルや、その他の各種フォーマットのデータ（ｍｐ３ファイル、ｍｐ４ファイル、ａｖｉファイルなど）がある。メインデータ記憶部２３は、ハードディスクや半導体記憶装置や光磁気ディスクなどの不揮発性記憶装置を用いて構成される。

〈〈サブデータ記憶部〉〉
サブデータ記憶部２４は、ユーザ端末１０に対して送信可能なサブデータを記憶する。サブデータの具体例も、メインデータの具体例と同様である。サブデータ記憶部２４は、ハードディスクや半導体記憶装置や光磁気ディスクなどの不揮発性記憶装置を用いて構成される。

〔第一動作例〕
図２は、サブデータ配信システム１００の第一動作例を示すフローチャートである。次に、サブデータ配信システム１００の第一動作例について説明する。

まず、ユーザ端末１０のユーザが、入力装置を操作することで、メインデータを選択する（Ｓ０１）。制御部１２は、ユーザによって選択されたメインデータの受信を要求する旨（データ要求）をサーバ２０に対して送信する（Ｓ０２）。サーバ２０の制御部２２は、データ要求を受信すると（Ｓ０３）、このデータ要求に対応するメインデータを、メインデータ記憶部２３から検索し、ユーザ端末１０への送信を開始する（Ｓ０４）。そして、ユーザ端末１０の制御部１２は、メインデータの受信を開始する（Ｓ０５）。

その後、制御部１２は、自装置（ユーザ端末１０）について環境情報を取得する（Ｓ０６）。次に、制御部１２は、この環境情報に基づいてサブデータを選択する（Ｓ０７）。このとき、制御部１２は、自装置に保持されている、環境情報とサブデータとの対応付けをしたテーブルに基づいて、サブデータを選択する。そして、制御部１２は、選択されたサブデータの受信を要求する旨（データ要求）をサーバ２０へ送信する（Ｓ０８）。

サーバ２０の制御部２２は、データ要求を受信すると（Ｓ０９）、このデータ要求に対応するサブデータを、サブデータ記憶部２４から検索し、ユーザ端末１０に送信する（Ｓ１０）。

ユーザ端末１０の制御部１２は、サブデータをサーバ２０から受信し、出力部１４を介してサブデータの再生を開始する（Ｓ１１）。そして、サブデータの再生が終了すると（Ｓ１２）、制御部１２は、Ｓ０５の処理で受信が開始されているメインデータの再生を開始する（Ｓ１３）。

図２のフローチャートに従った動作によれば、ユーザ端末１０におけるメインデータの受信処理（Ｓ０５）は、サブデータの受信や再生の処理（Ｓ１１）に先立って開始される。このような処理の実現は、例えば、サーバ２０が、ユーザ端末１０に対し、メインデータの送信において、メインデータの再生がユーザ端末１０において可能となるまでのデータ量の送信が完了する前に、サブデータの送信を開始することで実現しても良い。また、ユーザ端末１０が、メインデータの再生が可能となるまでのデータ量が受信される前に、サブデータの送信を要求し、この要求にサーバ２０が応じてサブデータの送信を開始することで実現しても良い。また、その他の実現方法が採用されても良い。

上述した動作では、サブデータの受信や再生の処理が行われている間に、メインデータの受信処理が進行する。そして、サブデータの再生が完了した後に、メインデータの再生が開始される。このため、従来のようにサブデータ（主に広告の動画像のデータ）の受信及び再生が終了してからメインデータの読み込みが開始される場合に比べて、メインデータの読み込みタイミングや再生開始タイミングの遅延を抑止することが可能となる。なお、このような効果を得るためには、必ずしもＳ０６〜Ｓ０９の処理は必要ではない。即ち、Ｓ０５の処理の後に、Ｓ１０の処理が実行されるように構成されても良い。

〈環境情報について〉
また、図２のフローチャートに従った動作によれば、ユーザ端末１０に送信されるサブデータは、ユーザ端末１０における環境情報に基づいて決定される。環境情報とは、例えばユーザ端末１０の性能（マシンスペック）や回線環境（回線の種類や、帯域情報など）などである。サブデータ記憶部２４は、複数種類のビットレートのサブデータや、複数種類の再生時間のサブデータを記憶するように構成される。そして、環境情報に基づき、ユーザ端末１０の制御部１２は、サブデータ記憶部２４に記憶された複数のサブデータの中から、適したサブデータを選択する。ここで、「適した」とは、具体的には、ユーザ端末１０において受信が開始されているメインデータの再生が可能となるまでの受信処理に要する時間中に、再生が完了すると推定されることである。「適した」の具体的な基準は、設計者によって適宜設計されて良い。例えば、各サブデータに対し、環境情報に基づいた閾値（例：ディスプレイ解像度はＡ以上Ｂ以下、通信速度はＣ以上Ｄ以下）が設けられ、この閾値が環境情報に適合するサブデータが選択されるように構成されても良い。

また、環境情報として、メインデータの再生が可能となるまでの受信処理に要する時間（以下、「メインデータ受信時間」という。）が用いられても良い。なお、メインデータの再生が可能となるまでの受信処理とは、メインデータがストリーミング又は疑似ストリーミング（プログレッシブダウンロード）の形式で再生される場合には、再生前のバッファリングを示し、ファイル全体がダウンロードされた後に再生が行われる場合には、メインデータのダウンロード処理を示す。

メインデータ受信時間は、例えば以下のような方法で算出できる。まず、ユーザ端末１０の現在の通信速度を取得する。例えば、メインデータの受信が開始されてから所定の時間（例えば、１秒間という決まった時間や、ユーザ端末１０からサーバ２０へ何らかのリクエストを行いそのレスポンスが得られるまでの時間）までに受信されたデータのサイズを取得し、このデータサイズを、そのデータの取得に要した時間（前述した所定の時間）で除算することにより、通信速度を取得できる。

次に、再生を開始するために必要となるメインデータの受信すべきデータサイズと、通信速度を用いて、メインデータ受信時間を算出できる。単純には、上述したデータサイズを通信速度で除算することで、メインデータ受信時間を算出できる。また、メインデータとサブデータの受信が並行して行われることから、通信速度が遅くなるおそれがあるので、この影響を反映させるため、算出された通信速度を遅く見積もって（例えば、通信速度に１以下０以上の値（例えば０．５）を乗じて）もよい。

また、Ｓ０５の受信開始から算出時点までに既に受信されているメインデータのサイズを算出したり、サーバ２０によるサブデータ送信開始がなされるまでに既に受信されているメインデータのサイズを推測し、このサイズを、メインデータの再生を開始するために必要となる受信すべきデータサイズから減算し、得られたデータサイズを通信速度によって除算することによって、メインデータ受信時間を算出することもできる。なお、上述したメインデータ受信時間算出方法は一例であり、他の算出方法によってメインデータ受信処理時間が算出されても良い。また、環境情報として、複数のデータの組み合わせ（例えば、通信速度とメインデータ受信時間の組み合わせ）が適用されても良い。

環境情報がこのようにメインデータ受信時間を含むように構成されることにより、サブデータの受信や再生の処理が行われる時間と、メインデータの再生が可能となるまでの受信処理に要する時間とを、近い値にすることができる。このため、より効果的に、メインデータの読み込みタイミングや再生開始タイミングの遅延を抑止することが可能となる。

〔第二動作例〕
図３、４は、サブデータ配信システム１００の第二動作例を示すフローチャートである。第二動作例は、第一動作例をさらに具体的に表したものである。また、第二動作例では、環境情報の具体例として、「帯域情報」と「メインデータ受信時間」とを用いる。また、第二動作例では、メインデータは、ＨＴＭＬ（HyperText Markup Language）データ内に含まれるリンクを選択することによって選択される。このため、ユーザ端末１０ではＷＥＢブラウザが動作し、サーバ２０はＷＥＢサーバとして動作する。次に、サブデータ配信システム１００の第二動作例について説明する。

まず、ユーザ端末１０のユーザが、入力装置を操作することで、リンクを選択する（Ｓ１０１）。次に、制御部１３は、選択されたリンク先のＨＴＭＬファイルのリクエストをサーバ２０に送信する（Ｓ１０２）。サーバ２０の制御部２２は、ＨＴＭＬファイルのリクエストを受信すると（Ｓ１０３）、このリクエストに対応するＨＴＭＬファイルをメインデータ記憶部２３から読み出し、ユーザ端末１０へ送信する（Ｓ１０４）。ユーザ端末１０の制御部１２は、ＨＴＭＬファイルをサーバ２０から受信すると（Ｓ１０５）、受信されたＨＴＭＬファイル内で指示されているメインデータのＩＤを取得し（Ｓ１０６）、このメインデータのリクエストをサーバ２０へ送信する（Ｓ１０７）。このとき、リクエストにはメインデータのＩＤが含まれている。

サーバ２０の制御部２２は、メインデータのリクエストを受信すると（Ｓ１０８）、リクエストからメインデータのＩＤを取得する（Ｓ１０９）。そして、制御部２２は、このＩＤに対応するメインデータをメインデータ記憶部２３から読み出し、メインデータの送信を開始する（Ｓ１１０）。

ユーザ端末１０の制御部１２は、メインデータの受信を開始すると（Ｓ１１１）、ユーザ端末１０に係るネットワークの通信速度を取得する（Ｓ１１２）。また、制御部１２は、メインデータ受信時間を算出する（Ｓ１１３）。制御部１２は、この通信速度及びメインデータ受信時間に基づいて、サブデータを選択する（Ｓ１１４）。そして、制御部１２は、選択されたサブデータのリクエストをサーバ２０へ送信する（Ｓ１１５）。

サーバ２０の制御部２２は、サブデータのリクエストを受信すると（Ｓ１１６）、リクエストからサブデータのＩＤを取得し、このＩＤに対応するサブデータをサブデータ記憶部２４から読み出し、このサブデータのユーザ端末１０への送信を開始する（Ｓ１１７）。

ユーザ端末１０の制御部１２は、サブデータを受信すると、サブデータの再生を開始する（Ｓ１１８）。そして、制御部１２は、サブデータの再生が終了すると（Ｓ１１９）、Ｓ１１１の処理で受信を開始していたメインデータの再生を開始する（Ｓ１２０）。

〔第三動作例〕
図５は、サブデータ配信システム１００の第三動作例を示すフローチャートである。第三動作例では、環境情報に基づいてサブデータを選択する処理が第二動作例と異なる。また、第三動作例では、環境情報とサブデータとの対応付けをしたテーブルは、サーバ２０に保持される。以下、サブデータ配信システム１００の第三動作例について説明する。ただし、第二動作例と同じ処理については、フローチャートに同じ符号を付すことで説明を省く。

Ｓ１０１〜Ｓ１１３までの処理は、第二動作例と同じである。Ｓ１１３の処理の後、ユーザ端末１０の制御部１２は、Ｓ１１２及びＳ１１３の処理で取得された通信速度及びメインデータ受信時間を、ユーザ端末１０の環境情報としてサーバ２０に送信する（Ｓ１２１）。

サーバ２０の制御部２２は、環境情報としてユーザ端末１０の通信速度及びメインデータ受信時間を、ユーザ端末１０から受信すると（ｓ１２２）、この環境情報に基づいて、サブデータを選択する（Ｓ１２３）。そして、制御部２２は、選択されたサブデータのユーザ端末１０への送信を開始する（Ｓ１１７）。そして、Ｓ１１８以降の処理が実施される。

〔第四動作例〕
図６は、サブデータ配信システム１００の第四動作例を示すフローチャートである。第四動作例では、ユーザ端末１０においてバッファータイムの設定が行われる点で、第二動作例と異なる。バッファータイムとは、メインデータを再生前にバッファリングしておくデータの再生時間を示す。例えば、バッファータイムが３秒に設定されている場合、再生時間にして３秒分のデータがバッファリングされることになる。

このように第四動作例ではバッファータイムの制御があるため、第四動作例で取り扱われるメインデータは、ストリーミング又は疑似ストリーミングの形式で再生されるメインデータに限定される。以下、サブデータ配信システム１００の第四動作例について説明する。ただし、第二動作例と同じ処理については、フローチャートに同じ符号を付すことで説明を省く。

Ｓ１０１〜Ｓ１１２までの処理は、第二動作例と同じである。Ｓ１１２の処理の後、ユーザ端末１０の制御部１２は、Ｓ１１２の処理において取得された通信速度に基づいてバッファータイムを決定し、メインデータの再生に関するバッファータイムの設定を行う（Ｓ１３１）。バッファータイムの具体的な決定方法については後述する。次に、制御部１２は、通信速度やバッファータイムに基づいてサブデータを選択する（Ｓ１３２）。そして、制御部１２は、選択されたサブデータのリクエストをサーバ２０へ送信する（Ｓ１１５）。

〈バッファータイムの設定について〉
ストリーミング及び疑似ストリーミングの形式でメインデータが再生される場合、バッファータイムを調整することによって、メインデータの再生が開始されるまでの時間を調整することが可能となる。バッファータイムは、再生させようとするサブデータの受信時間及び再生時間に基づいて決定することができる。例えば、サブデータの再生に要する時間と通信速度とを乗算し、この値から、サブデータのビットレートを除算することにより、バッファータイムとすべき値を算出できる。そして、バッファータイムの算出に当たって用いられた「サブデータの再生に要する時間」に基づいて、この時間に相当するサブデータが選択されても良い。逆に、図６においてＳ１３２の処理とＳ１３３の処理の順番を逆にし、予め選択されたサブデータの再生に要する時間に基づいてバッファータイムが算出されても良い。

また、この算出により得られる値は理論値となるため、算出された値より大きい値をバッファータイムとしても良い。この処理は、設計者によって自由に設計できる。また、バッファータイムについての上記算出方法は一例であるため、別の算出方法が採用されても良い。また、この算出は、第二動作例と第三動作例との差違のように、ユーザ端末１０の制御部１２によって実行され、サーバ２０に算出結果が通知されるように構成されても良い。

図６のフローチャートに従った動作によれば、サブデータの再生に要する時間に応じたバッファータイムの変更が可能となる。このため、サブデータの再生が完了した後にメインデータの再生が開始されるまでの時間を調整することが可能となる。また、この場合も、ユーザ端末１０におけるメインデータの受信処理（Ｓ０５）は、サブデータの受信や再生の処理（Ｓ１１）に先立って開始され、サブデータの受信や再生の処理が行われている間に、メインデータの受信処理が進行する。このため、従来のようにサブデータの受信及び再生が終了してからメインデータの読み込みが開始される場合に比べて、メインデータの読み込みタイミングや再生開始タイミングの遅延を抑止することが可能となる。

〔変形例〕
上述した説明では、メインデータとサブデータとは同一のサーバ（サーバ２０）に記憶されているが、それぞれ異なるサーバ装置に記憶されるように構成されても良い。さらに、複数種類のメインデータや複数種類のサブデータは、それぞれ異なるサーバ装置に記憶されるように構成されても良い。

また、ユーザ端末１０の制御部１２は、選択したサブデータや受信されたサブデータを記録しておき、一定の時間の範囲内（例えば、数時間、一日、一週間など）に同一のサブデータが選択・受信されないようにさらに制御を行うように構成されても良い。

また、サーバ２０の制御部２２は、各ユーザ端末１０に送信したサブデータを記録しておき、一定の時間の範囲内（例えば、数時間、一日、一週間など）に同一のサブデータが送信されないようにさらに制御を行うように構成されても良い。

また、サーバ２０の制御部２２は、ユーザ端末１０から環境情報として、ユーザ端末１０の設置地域や使用言語などを取得し、このデータに基づいて、ユーザ端末１０の設置地域や使用言語に適したサブデータを選択するように構成されても良い。

また、ユーザ端末１０の制御部１２は、時刻に応じて、サブデータを選択するように構成されても良い。例えば、制御部１２は、朝、昼、夜というそれぞれの時刻に応じた内容のサブデータを選択するように構成されても良い。

本発明におけるサブデータ配信システムの構成例を示す図である。 本発明におけるサブデータ配信システムの第一動作例を示すフローチャートである。 本発明におけるサブデータ配信システムの第二動作例を示すフローチャートである。 本発明におけるサブデータ配信システムの第二動作例を示すフローチャートである。 本発明におけるサブデータ配信システムの第三動作例を示すフローチャートである。 本発明におけるサブデータ配信システムの第四動作例を示すフローチャートである。

符号の説明

１０…ユーザ端末、 １１…入力部、 １２…制御部、 １３…送受信部、 １４…出力部、 ２０…サーバ、 ２１…送受信部、 ２２…制御部、 ２３…メインデータ記憶部、 ２４…サブデータ記憶部、 １００…サブデータ配信システム

Claims (9)

1. 第一の動画像・音声データの受信をサーバに要求する第一の要求手段と、
   前記第一の動画像・音声データ、及び、サーバから送信される第二の動画像・音声データの受信・再生を制御する制御手段と、を備え、
   前記制御手段は、前記第一の動画像・音声データの受信を開始した後、前記第一の動画像・音声データの再生を開始する前に、第二の動画像・音声データを受信し再生し、
   前記制御手段は、前記第二の動画像・音声データを受信し再生している間も、前記第一の動画像・音声データについて、再生は行うことなく受信を続け、
   前記制御手段は、前記第二の動画像・音声データの再生が終了した後に、前記第一の動画像・音声データの再生を開始する、
   ユーザ端末装置。
2. 前記制御手段は、自装置の環境情報に基づいて第二の動画像・音声データを選択肢、
   前記制御手段は、選択した第二の動画像・音声データを前記サーバに要求し、
   前記制御手段は、前記サーバから送信される第二の動画像・音声データを受信し再生する、請求項１に記載のユーザ端末装置。
3. 前記環境情報は、自装置において前記第一の動画像・音声データの再生が可能となるまでの受信処理に要する時間である、請求項２に記載のユーザ端末装置。
4. 第一の動画像・音声データについての要求をクライアントから受け付ける受付手段と、
   前記要求が受け付けられると、第一の動画像・音声データの前記クライアントへの送信を開始する第一送信手段と、
   前記第一の動画像・音声データの送信中であって、第一の動画像・音声データの再生が前記クライアントにおいて可能となるまでの受信処理が完了する前に、第二の動画像・音声データの前記クライアントへの送信を開始する第二送信手段と、
   を備えるサーバ。
5. 前記クライアントから、第二の動画像・音声データの要求を受け付ける受信手段をさらに備え、
   前記第二送信手段は、前記受信手段によって受信された要求に基づき、要求された第二の動画像・音声データの送信を開始する、請求項４に記載のサーバ。
6. 情報処理装置が、第一の動画像・音声データの受信をサーバに要求するステップと、
   前記情報処理装置が、前記第一の動画像・音声データの受信を開始するステップと、
   前記情報処理装置が、前記第一の動画像・音声データの再生を開始する前であって、当該第一の動画像・音声データの受信中に、第二の動画像・音声データの受信及び再生を開始するステップと、
   前記情報処理装置が、前記第二の動画像・音声データの再生が終了した後に、前記第一の動画像・音声データの再生を開始するステップと、
   を含む再生方法。
7. 情報処理装置が、第一の動画像・音声データについての要求をクライアントから受け付けるステップと、
   前記情報処理装置が、前記要求が受け付けられた後に、第一の動画像・音声データの前記クライアントへの送信を開始するステップと、
   前記情報処理装置が、前記第一の動画像・音声データの送信中であって、第一の動画像・音声データの再生が前記クライアントにおいて可能となるまでの受信処理が完了する前に、第二の動画像・音声データの前記クライアントへの送信を開始するステップと、
   を含むデータ送信方法。
8. 情報処理装置に対し、
   第一の動画像・音声データの受信をサーバに要求するステップと、
   前記第一の動画像・音声データの受信を開始するステップと、
   前記第一の動画像・音声データの再生を開始する前であって、当該第一の動画像・音声データの受信中に、第二の動画像・音声データの受信及び再生を開始するステップと、
   前記第二の動画像・音声データの再生が終了した後に、前記第一の動画像・音声データの再生を開始するステップと、
   を実行させるためのプログラム。
9. 情報処理装置に対し、
   第一の動画像・音声データについての要求をクライアントから受け付けるステップと、
   前記要求が受け付けられた後に、第一の動画像・音声データの前記クライアントへの送信を開始するステップと、
   前記第一の動画像・音声データの送信中であって、第一の動画像・音声データの再生が前記クライアントにおいて可能となるまでの受信処理が完了する前に、第二の動画像・音声データの前記クライアントへの送信を開始するステップと、
   を実行させるためのプログラム。