(57)【要約】【課題】通信端末での視聴の安定化と、再生開始の高速化を両立する。【解決手段】データ配信システム１は、シェーピングが行われないコンテンツデータを配信する第１の配信サーバ２０−１と、シェーピングが行われるコンテンツデータを配信する第２の配信サーバ２０−２と、コンテンツデータの再生指示を取得すると、コンテンツデータの記憶量が閾値以下である間は、第１の配信サーバ２０−１からコンテンツデータを取得し、コンテンツデータの記憶量が閾値を超えると、第２の配信サーバ２０−２からコンテンツデータを取得する通信端末３０と、を備える。【選択図】図１
2018098569.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツデータを配信するデータ配信システムであって、
シェーピングが行われないコンテンツデータを配信する第１の配信サーバと、
シェーピングが行われるコンテンツデータを配信する第２の配信サーバと、
コンテンツデータの再生指示を取得すると、コンテンツデータの記憶量が閾値以下である間は、前記第１の配信サーバからコンテンツデータを取得し、コンテンツデータの記憶量が前記閾値を超えると、前記第２の配信サーバからコンテンツデータを取得する通信端末と、
を備えることを特徴とするデータ配信システム。
【請求項２】
前記通信端末は、前記第１の配信サーバの宛先アドレス、前記第２の配信サーバの宛先アドレス、及びコンテンツデータのファイル名に関する情報を含むプレイリストを取得し、前記コンテンツデータの再生指示を取得すると、コンテンツデータの記憶量が前記閾値以下である間は、前記プレイリストに基づいて前記第１の配信サーバが配信するコンテンツデータのＵＲＩを決定して、前記第１の配信サーバにリクエスト行い、コンテンツデータの記憶量が前記閾値を超えると、前記プレイリストに基づいて前記第２の配信サーバが配信するコンテンツデータのＵＲＩを決定し、前記第２の配信サーバにリクエスト行うことを特徴とする、請求項１に記載のデータ配信システム。
【請求項３】
配信サーバからコンテンツデータを取得する通信端末であって、
コンテンツデータの再生指示を取得すると、コンテンツデータの記憶量が閾値以下である間は、シェーピングが行われないコンテンツデータを配信する第１の配信サーバからコンテンツデータを取得し、コンテンツデータの記憶量が前記閾値を超えると、シェーピングが行われるコンテンツデータを配信する第２の配信サーバからコンテンツデータを取得することを特徴とする通信端末。
【請求項４】
前記第１の配信サーバとの間の通信セッションが確立しているか否かを一定周期で確認し、通信セッションが確立していない場合には、前記第１の配信サーバと通信セッションを開始することを特徴とする、請求項３に記載の通信端末。
【請求項５】
視聴画面上でのタップ操作又はマウスオーバーを契機として、前記第１の配信サーバとの間のセッションが確立しているか否かを確認し、通信セッションが確立していない場合には、前記第１の配信サーバと通信セッションを開始することを特徴とする、請求項３又は４に記載の通信端末。
【請求項６】
コンピュータを、請求項３から５のいずれか一項に記載の通信端末として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツデータを配信するデータ配信システム、コンテンツデータを取得する通信端末、及び通信端末のプログラムに関する。
【背景技術】
【０００２】
近年の動画配信においては、アダプティブストリーミングが注目されている。アダプティブストリーミングでは、配信側で映像を複数のビットレートでエンコードして数秒単位のファイルに分割しておき、ストリーミングを受信する通信端末で、自身の通信速度に合わせたビットレートのファイルを順次取得し、取得ファイルを繋ぎ合わせることで再生を行う。こうして、通信速度が変動する通信端末においても、再生中断しにくい動画配信を実現できる（例えば、非特許文献１参照）。
【０００３】
ただし、アダプティブストリーミングでは、各通信端末がファイル単位でデータ取得を行うため、トラフィックがバースト的になりやすく、通信端末からのアクセスが集中すると、ネットワーク機器等での輻輳によるパケットロスが発生しやすくなる。配信規模が大きくなればなるほど、その傾向は顕著となることから、このようなバースト的なトラフィックを抑制する技術が必要となる。
【０００４】
スマートフォンやＰＣといった通信端末に対する大規模なストリーム配信においては、ネットワーク機器に通信端末からのアクセスが集中しやすく、ネットワーク機器で処理しきれずパケットロスが発生する。これを抑制する方法として、ネットワーク機器の通信容量を超えないよう、パケットをネットワーク機器のバッファに保存し、通信容量に空きができた時に送信処理を行うシェーピング手法が知られている（例えば、非特許文献２参照）。
【０００５】
図８は、シェーピングによる効果を示す図であり、図８（ａ）はシェーピングを行わない場合の通信量を示し、図８（ｂ）はシェーピングを行った場合の通信量を示している。バースト的なリクエストが発生した際に、シェーピングを行わない場合には、図８（ａ）に示すように配信サーバの配信容量の上限を超えるパケットはパケットロスとなってしまう。一方、シェーピングを行う場合には、図８（ｂ）に示すようにパケット処理に遅延が発生するものの、パケットロスが発生しない動作となる。
【０００６】
また、通信端末においては、インターネットの混雑などが原因でストリーミング再生に必要な通信速度を下回ることもあることから、変動する通信速度差を吸収するため、所望の再生時刻よりも数秒程度先のデータまで取得してバッファに保存し、保存したデータ量が設定した閾値を超えた時にストリーミング再生を開始することが一般的である。
【０００７】
また、特許文献１には配信経路の混雑状況に合わせてエンコードレートを変更する技術が開示されている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００６−２６２２０５号公報
【非特許文献】
【０００９】
【非特許文献１】Ａ. Zambelli, ”IIS Smooth Streaming Technical Overview”, Mar.2009
【非特許文献２】福富ほか、「ルータにおける帯域制御方式の検討」、信学技報、ＮＳ２００３−２１９、Ｄｅｃ．２００３
【発明の概要】
【発明が解決しようとする課題】
【００１０】
シェーピングを行うことでパケットロスを低減でき、配信の安定化を図ることができる。しかし、データの受信速度が平滑化されることにより、データの受信時間が長くなってしまう。これにより、視聴開始時やシーク操作時に、再生開始に必要なデータ取得に時間がかかり、ストリーミングを再生開始するまでの時間が増えてしまうという問題がある。
【００１１】
また、特許文献１に記載の方法では、アダプティブストリーミングのライブ配信のように通信端末からのアクセスが瞬間的に増加した場合には、必要以上にエンコードレートを下げてしまい、コンテンツデータの品質が著しく低下してしまうという問題がある。
【００１２】
かかる事情に鑑みてなされた本発明の目的は、通信端末での視聴の安定化と、再生開始の高速化を両立することが可能なデータ配信システム、通信端末、及びプログラムを提供することにある。
【課題を解決するための手段】
【００１３】
上記課題を解決するため、本発明に係るデータ配信システムは、コンテンツデータを配信するデータ配信システムであって、シェーピングが行われないコンテンツデータを配信する第１の配信サーバと、シェーピングが行われるコンテンツデータを配信する第２の配信サーバと、コンテンツデータの再生指示を取得すると、コンテンツデータの記憶量が閾値以下である間は、前記第１の配信サーバからコンテンツデータを取得し、コンテンツデータの記憶量が前記閾値を超えると、前記第２の配信サーバからコンテンツデータを取得する通信端末と、を備えることを特徴とする。
【００１４】
さらに、本発明に係るデータ配信システムにおいて、前記通信端末は、前記第１の配信サーバの宛先アドレス、前記第２の配信サーバの宛先アドレス、及びコンテンツデータのファイル名に関する情報を含むプレイリストを取得し、前記コンテンツデータの再生指示を取得すると、コンテンツデータの記憶量が前記閾値以下である間は、前記プレイリストに基づいて前記第１の配信サーバが配信するコンテンツデータのＵＲＩを決定して、前記第１の配信サーバにリクエスト行い、コンテンツデータの記憶量が前記閾値を超えると、前記プレイリストに基づいて前記第２の配信サーバが配信するコンテンツデータのＵＲＩを決定し、前記第２の配信サーバにリクエスト行うことを特徴とする。
【００１５】
また、上記課題を解決するため、本発明に係る通信端末は、配信サーバからコンテンツデータを取得する通信端末であって、コンテンツデータの再生指示を取得すると、コンテンツデータの記憶量が閾値以下である間は、シェーピングが行われないコンテンツデータを配信する第１の配信サーバからコンテンツデータを取得し、コンテンツデータの記憶量が前記閾値を超えると、シェーピングが行われるコンテンツデータを配信する第２の配信サーバからコンテンツデータを取得することを特徴とする。
【００１６】
さらに、本発明に係る通信端末において、前記第１の配信サーバとの間の通信セッションが確立しているか否かを一定周期で確認し、通信セッションが確立していない場合には、前記第１の配信サーバと通信セッションを開始することを特徴とする。
【００１７】
さらに、本発明に係る通信端末において、視聴画面上でのタップ操作又はマウスオーバーを契機として、前記第１の配信サーバとの間のセッションが確立しているか否かを確認し、通信セッションが確立していない場合には、前記第１の配信サーバと通信セッションを開始することを特徴とする。
【００１８】
また、上記課題を解決するため、本発明に係るプログラムは、コンピュータを、上記通信端末として機能させることを特徴とする。
【発明の効果】
【００１９】
本発明によれば、通信端末での視聴の安定化と、再生開始やシーク操作の高速化を両立することができるようになる。
【図面の簡単な説明】
【００２０】
【図１】本発明の一実施形態に係るデータ配信システムの概略図である。
【図２】本発明の一実施形態に係るデータ配信システムにおけるコンテンツ配信サーバに保存されるコンテンツデータの概略図である。
【図３】本発明の一実施形態に係るデータ配信システムにおけるプレイリストサーバが配信するプレイリストの一例を示す図である。
【図４】本発明の一実施形態に係る通信端末の構成を示す概略図である。
【図５】本発明の一実施形態に係る通信端末がコンテンツデータの再生指示を取得してからストリーム再生までに記憶されるコンテンツデータを示す図である。
【図６】本発明の一実施形態に係る通信端末における制御部の処理の一例を示すフローチャートである。
【図７】本発明による効果を説明する図である。
【図８】シェーピングによる効果を説明する図である。
【発明を実施するための形態】
【００２１】
以下、本発明の一実施形態について、図面を参照して詳細に説明する。
【００２２】
図１は、本発明の一実施形態に係るデータ配信システムの概略図である。図１に示すデータ配信システム１は、プレイリストサーバ１０と、第１の配信サーバ２０−１と、第２の配信サーバ２０−２と、複数の通信端末３０とを備える。なお、各配信サーバ２０は同じデータをキャッシュしているものとする。以下の説明において、「第１の配信サーバ２０−１」と、「第２の配信サーバ２０−２」とを特に区別する必要がない場合には、単に「配信サーバ２０」と記載する。
【００２３】
データ配信システム１は、アダプティブストリーミングによりデータ配信を行う。ここで、連続的なデータ（映像や音声のストリームデータなど）を数秒単位のファイルに分割したものをコンテンツデータ（配信データ）と呼ぶ。アダプティブストリーミングでは、各通信端末３０が始めにコンテンツデータの取得先が記載されたメタデータであるプレイリストを取得し、プレイリストに記載されている配信サーバ２０からコンテンツデータを順次取得し、取得したコンテンツデータを繋ぎあわせて再生する。
【００２４】
第１の配信サーバ２０−１は、シェーピングが行われないコンテンツデータを配信するサーバである。第２の配信サーバ２０−２は、シェーピングが行われるコンテンツデータを配信するサーバである。シェーピングは第２の配信サーバ２０−２で行ってもよいし、第２の配信サーバ２０−２と通信端末３０との間に配置される基地局やルータなどのネットワーク機器で行ってもよい。
【００２５】
図２は、アダプティブストリーミングでの、配信サーバ２０に保存されるコンテンツデータの概略図である。ファイル番号（シーケンス番号）ごとにコンテンツデータが独立したファイルとなる。
【００２６】
プレイリストサーバ１０は、プレイリストを配信するサーバである。なお、配信サーバ２０がプレイリストも配信するようにし、プレイリストサーバ１０を備えないシステムとすることも可能である。
【００２７】
図３は、プレイリストサーバ１０が配信するプレイリストの一例を示す図である。プレイリストは、第１の配信サーバ２０−１の宛先アドレス、第２の配信サーバ２０−２の宛先アドレス、シェーピングが行われるコンテンツデータを配信する配信サーバであるか否かを示す情報（シェーピングの有無）、及びコンテンツデータのファイル名に関する情報を含む。なお、このプレイリストはシェーピングの有無を含んでいるが、プレイリストではなく通信端末３０に予めこの情報を設定しておいてもよい。
【００２８】
図３に示すプレイリストは、宛先アドレスがhttp://aaaの配信サーバは、シェーピングが行われないコンテンツデータを配信する第１の配信サーバ２０−１であり、該第１の配信サーバ２０−１から配信されるコンテンツデータのＵＲＩ（Uniform Resource Identifier）は、http://aaa/11，http://aaa/12，http://aaa/13・・・であることを示している。また、宛先アドレスがhttp://bbbの配信サーバは、シェーピングが行われるコンテンツデータを配信する第２の配信サーバ２０−２であり、該第２の配信サーバ２０−２から配信されるコンテンツデータのＵＲＩは、http://bbb/11，http://bbb/12，http://bbb/13・・・であることを示している。
【００２９】
通信端末３０は、スマートフォンやＰＣなどの端末であり、プレイリストサーバ１０からプレイリストを取得する。そして、コンテンツデータの再生指示を取得すると、コンテンツデータの記憶量が閾値以下である間は、第１の配信サーバ２０−１からコンテンツデータを取得し、コンテンツデータの記憶量が該閾値を超えると、コンテンツデータの再生を開始するとともに、第２の配信サーバ２０−２からコンテンツデータを取得する。
【００３０】
ここで、コンテンツデータの再生指示には、新規にデータ配信システム１に参加してコンテンツデータを取得する指示のみならず、シーク操作により再生開始位置を変更してコンテンツデータを取得するシーク指示や、コンテンツデータの記憶量が閾値以下となりコンテンツデータの再生が停止している状態も含むものとする。
【００３１】
図１において、コンテンツデータの再生指示を取得した通信端末３０−４は、プレイリストに基づいて第１の配信サーバ２０−１が配信するコンテンツデータのＵＲＩ（http://aaa/11など）を決定し、コンテンツデータごとに第１の配信サーバ２０−１にリクエスト行い、該コンテンツデータを取得する。通信端末３０−４は、再生時刻よりも数秒程度先までのコンテンツデータを取得すると、コンテンツデータの再生を開始し、破線で示すように、第２の配信サーバ２０−２からコンテンツデータを取得する。
【００３２】
図１において、通信端末３０−１，３０−２，３０−３は、すでにコンテンツデータの再生を開始しており、プレイリストに基づいて第２の配信サーバ２０−２が配信するコンテンツデータのＵＲＩ（http://bbb/11など）を決定し、コンテンツデータごとに第２の配信サーバ２０−２にリクエスト行い、該コンテンツデータを取得する。
【００３３】
このように、各通信端末３０は自身の視聴状況に応じて、コンテンツデータの取得先の配信サーバ２０を選択する。第１の配信サーバ２０−１から配信されるコンテンツデータはシェーピングが行われないので、遅延の少ないデータ配信が可能である。また、第２の配信サーバ２０−２において通信端末３０からのアクセスが集中する場合には、シェーピングが実施されるため、通信端末３０へのデータ受信速度に遅延が生じるが視聴の安定化を図ることが可能となる。
【００３４】
図４は、通信端末３０の構成を示す概略図である。通信端末３０は、入力部３０１と、通信部３０２と、制御部３０３と、記憶部３０４と、表示部３０５とを備える。
【００３５】
入力部３０１は、ユーザの操作によりユーザ指示を取得し、制御部３０３に出力するユーザインターフェースである。ユーザ指示は、コンテンツデータの再生指示（シーク指示を含む）、コンテンツデータの再生終了指示などに区分される。
【００３６】
通信部３０２は、プレイリストサーバ１０からプレイリストを受信し、制御部３０３に出力する。また、データ取得先として決定された配信サーバ２０と通信セッションが確立しているか否かを確認し、通信セッションが確立していなければ、当該配信サーバ２０と新たに通信セッションを開始し、配信サーバ２０からネットワーク機器を介してコンテンツデータを受信し、制御部３０３に出力する。配信サーバ２０との通信セッションは、当該配信サーバ２０からの切断要求を受信した任意のタイミングで終了するものとする。
【００３７】
制御部３０３は、通信端末３０の動作や信号フローを制御する。制御部３０３は、例えば入力部３０１から入力されたユーザ指示に対応する処理を実行したり、通信部３０２から入力されたプレイリストに基づきコンテンツデータの取得先の配信サーバ２０を決定したり、通信部３０２から入力されたコンテンツデータを記憶部３０４へ記憶・読み出ししたり、読み出したコンテンツデータを表示部３０５に出力したりする。また、制御部３０３は、前回の視聴操作から一定時間経過後に非表示（入力部３０１からの視聴操作を受け付けない状態）とし、表示部３０５に表示された視聴画面上での任意の場所のタップ操作、又は視聴画面上でのマウスオーバーを契機として、表示状態（入力部３０１からの視聴操作を受け付け可能な状態）としてもよい。ここで、視聴画面とは、コンテンツデータの視聴アプリケーションを起動した際に、表示部３０５に表示される画面のことをいう。また、視聴画面上でのタップ操作とは、視聴アプリケーションを起動する際のタップ操作も含むものとする。制御部３０３の処理の詳細は後述する。
【００３８】
記憶部３０４は、配信サーバ２０から受信したコンテンツデータを記憶する。
【００３９】
表示部３０５は、記憶部３０４に記憶されているコンテンツデータを、制御部３０３の制御に基づいて取得し、表示する。
【００４０】
図５は、通信端末３０がコンテンツデータの再生指示を取得してからストリーム再生までに記憶部３０４に記憶されるコンテンツデータを示す図である。通信端末３０は再生指示を取得すると、記憶部３０４にコンテンツデータを記憶し、記憶量が再生開始閾値以下である場合には再生を開始せず、記憶量が再生開始閾値を超えた場合（図５ではｔ秒後）に再生を開始する。なお、シーク操作による再生指示を取得した場合には、再生位置が変わり、新たなコンテンツデータを記憶し、所定量のコンテンツデータが記憶された時点で再生を開始する。
【００４１】
図６は、通信端末３０の制御部３０３の処理の一例を示すフローチャートである。まず、プレイリストサーバ１０から通信部３０２を介してプレイリストを取得する（ステップＳ１０１）。
【００４２】
次に、第１の配信サーバ２０−１との通信セッションが確立しているか否かを確認し、通信セッションが確立していなければ、第１の配信サーバ２０−１と新たに通信セッションを開始し、ユーザインターフェースの操作を確認する（ステップＳ１０２）。この動作は、ユーザによる視聴操作において、表示部３０５に表示された視聴画面上での任意の場所のタップ操作、又は視聴画面上でのマウスオーバーを契機として行うようにしてもよい。
【００４３】
次に、ユーザによる視聴操作を確認する（ステップＳ１０３）。入力部３０１によりコンテンツデータの再生指示を取得した場合には（ステップＳ１０４−Ｙｅｓ）、プレイリストに基づきコンテンツデータの取得先を第１の配信サーバ２０−１に決定する（ステップＳ１０５）。コンテンツデータの再生開始後に新たにコンテンツデータの再生指示を取得していない場合には（ステップＳ１０４−Ｎｏ）、プレイリストに基づきコンテンツデータの取得先を第２の配信サーバ２０−２に決定する（ステップＳ１０６）。
【００４４】
その後、決定した配信サーバ２０との通信セッションが確立しているか否かを確認し、通信セッションが確立していなければ、当該配信サーバ２０と新たに通信セッションを開始する（ステップＳ１０７）。そして、プレイリストに従って、決定した配信サーバ２０からコンテンツデータを取得し（ステップＳ１０８）、取得したコンテンツデータを記憶部３０４に記憶させる（ステップＳ１０９）。
【００４５】
その後、記憶部３０４に記憶されたコンテンツデータの記憶量が再生閾値を超え、且つ未再生である場合には（ステップＳ１１０−Ｙｅｓ）、コンテンツデータの再生（シーク操作による再生を含む）を開始し（ステップＳ１１１）、プレイリストのコンテンツデータの取得先を第１の配信サーバ２０−１から第２の配信サーバ２０−２に変更する（ステップＳ１１２）。コンテンツデータの記憶量が再生閾値より低い、又はコンテンツデータの再生中である場合には（ステップＳ１１０−Ｎｏ）、これらの処理は行わない。
【００４６】
次に、第１の配信サーバ２０−１との通信セッションを確立しているか否かを確認してから一定時間経過している場合には（ステップＳ１１３−Ｙｅｓ）、第１の配信サーバ２０−１との通信セッションが確立しているか否かを確認し、通信セッションが確立していなければ、第１の配信サーバ２０−１と新たに通信セッションを開始する（ステップＳ１１４）。第１の配信サーバ２０−１との通信セッションを確立しているか否かを確認してから一定時間経過していない場合には（ステップＳ１１３−Ｎｏ）、この処理を行わない。つまり、一定周期で第１の配信サーバ２０−１との間の通信セッションが確立しているか否かを確認する。
【００４７】
次に、コンテンツデータの再生が終了（すなわち、視聴終了）した場合には（ステップＳ１１５−Ｙｅｓ）、処理を終了する。視聴終了でない場合には（ステップＳ１１５−Ｎｏ）プレイリスト取得のフローに戻る（ステップＳ１０１）。なお、図６では、ステップＳ１１５の後にプレイリストを毎回取得する形としているが、初回のみの取得、又は数回に一回の取得としてもよい。
【００４８】
図７は、本発明による効果を説明する図である。図７は、ある通信端末３０における本発明の有無それぞれの場合の配信開始までのコンテンツデータの取得状況を示している。図７の例では、通信端末３０は記憶部３０４にコンテンツデータが４番まで溜まってから再生を開始するものとする。図７（ａ）は本発明を適用しない場合を示しており、この場合にはシェーピングによる遅延により各コンテンツデータの取得に時間がかかるため、再生が開始されるまでに時間がかかる。これに対し、図７（ｂ）は本発明を適用する場合を示しており、この場合にはシェーピングによる遅延がないため各コンテンツデータの取得時間が短くなり、再生が開始されるまでの時間を短縮することができる。
【００４９】
なお、シーク操作についても、再生位置が変わり、新たなコンテンツデータを記憶し、一定量のコンテンツデータが記憶されるまで同様の時間差が生じるため、本発明によりシーク操作後に再生が開始されるまでの時間を短縮することができる。
【００５０】
また、シェーピングが行われないコンテンツデータを配信する第１の配信サーバ２０−１との間の通信セッションが確立しているか否かを一定周期で確認し、通信セッションを確立していない場合には、第１の配信サーバ２０−１と新たに通信セッションを開始するようにしてもよい。これにより、データ取得先を第１の配信サーバ２０−１に決定した時点で第１の配信サーバ２０−１と予めセッションを確立した状態となる可能性が高まるため、さらにストリーミング再生を高速化することができる。
【００５１】
さらに、通信端末３０は視聴操作がなされる前段階として、表示部３０５に表示された視聴画面上での任意の場所のタップ操作、又は視聴画面上でのマウスオーバーを契機として、第１の配信サーバ２０−１との間のセッションが確立しているか否かを確認し、通信セッションが確立していない場合は、第１の配信サーバ２０−１と新たに通信セッションを開始するようにしてもよい。これにより、コンテンツデータの再生指示を取得しデータ取得先を第１の配信サーバ２０−１に決定することに先立って、第１の配信サーバ２０−１とセッションを確立することができるため、さらにストリーミング再生を高速化することができる。
【００５２】
なお、上述した通信端末３０として機能させるためにコンピュータを好適に用いることができ、そのようなコンピュータは、通信端末３０の各機能を実現する処理内容を記述したプログラムを該コンピュータの記憶部に格納しておき、該コンピュータのＣＰＵによってこのプログラムを読み出して実行させることで実現することができる。なお、このプログラムは、コンピュータ読取り可能な記録媒体に記録可能である。
【００５３】
上述したように、本発明では、シェーピングが行われないコンテンツデータを配信する第１の配信サーバ２０−１、及びシェーピングが行われるコンテンツデータを配信する第２の配信サーバ２０−２を使用する。配信に参加したばかりの通信端末３０や、シーク操作がなされた通信端末３０は、コンテンツデータの取得先を第１の配信サーバ２０−１とし、再生開始後の通信端末３０はコンテンツデータの取得先を第２の配信サーバ２０−２とする。かかる構成により、本発明によればデータ配信の安定化と通信端末３０のストリーミング再生の高速化を両立させることが可能となる。
【００５４】
上述の実施形態は代表的な例として説明したが、本発明の趣旨及び範囲内で、多くの変更及び置換ができることは当業者に明らかである。したがって、本発明は、上述の実施形態によって制限するものと解するべきではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。例えば、実施形態の構成図に記載の複数の構成ブロックを１つに組み合わせたり、あるいは１つの構成ブロックを分割したりすることが可能である。
【符号の説明】
【００５５】
１        データ配信システム
１０      プレイリストサーバ
２０−１  第１の配信サーバ
２０−２  第２の配信サーバ
３０      通信端末
３０１    入力部
３０２    通信部
３０３    制御部
３０４    記憶部
３０５    表示部
【図１】
2018098569.tif 000003
【図２】
2018098569.tif 000004
【図３】
2018098569.tif 000005
【図４】
2018098569.tif 000006
【図５】
2018098569.tif 000007
【図６】
2018098569.tif 000008
【図７】
2018098569.tif 000009
【図８】
2018098569.tif 000010