(57)【特許請求の範囲】
【請求項１】
ネットワークを介して接続された視聴者端末へ配信される画像の配信負荷量を取得する配信負荷量取得部と、
前記配信負荷量に基づいて、前記視聴者端末への画像配信を行う配信装置の種類又は台数を決定する配信装置決定部と、
を備え、
前記配信装置は、前記視聴者端末へ画像を直接的に配信する１又は複数の配信端末、及び前記配信端末からアップロードされた画像を前記視聴者端末へ配信する配信サーバを含み、前記配信端末は、利用されていない空き配信端末を含み、
前記配信負荷量取得部は、画像配信先の前記視聴者端末に関する情報を取得する視聴者端末情報取得部を含み、
前記配信装置決定部は、前記視聴者端末に関する情報に応じて前記配信装置の種類又は台数を決定し、
前記視聴者端末に関する情報は、少なくとも画像配信先の現在又は過去の視聴者数又は配信される画像を予約している視聴者数を含み、
前記配信装置決定部は、少なくとも画像配信先の現在又は過去の視聴者数又は配信される画像を予約している視聴者数に基づいて前記空き配信端末の数を決定する、画像配信管理サーバ。
【請求項２】
前記配信負荷量取得部は、前記画像配信による前記ネットワークの利用帯域量を取得する利用帯域取得部を更に含み、
前記配信装置決定部は、前記視聴者数及び前記利用帯域量に基づいて前記配信装置の種類又は台数を決定する、請求項１に記載の画像配信管理サーバ。
【請求項３】
前記配信装置決定部は、前記視聴者数又は前記利用帯域量に関する所定の閾値に基づいて、前記視聴者端末へ画像を配信する前記配信端末の台数を決定するとともに、前記配信サーバのみが前記視聴者端末へ画像を配信するか否かを決定する、請求項２に記載の画像配信管理サーバ。
【請求項４】
前記配信装置決定部は、前記視聴者数又は前記利用帯域量の増加に伴い画像を配信する前記配信端末の台数を増加させ、前記視聴者数又は前記利用帯域量が所定値を越えた場合は前記配信サーバのみが前記視聴者端末へ画像を配信することを決定する、請求項３に記載の画像配信管理サーバ。
【請求項５】
前記配信装置決定部は、前記視聴者数又は前記利用帯域量が所定値以下となった場合に前記配信サーバのみによる配信から複数の前記配信端末による配信に切り換えるとともに、前記視聴者数又は前記利用帯域量の更なる減少に応じて画像を配信する前記配信端末の台数を減少させる、請求項３に記載の画像配信管理サーバ。
【請求項６】
前記配信装置決定部は、前記配信サーバのみによる配信から複数の前記配信端末による配信に切り換える際、又は前記配信端末の台数を減少させる際において、配信を停止させる装置と配信を継続する装置の双方から一時的に画像ストリームを配信させる、請求項５に記載の画像配信管理サーバ。
【請求項７】
前記配信装置決定部は、前記配信サーバのみによる配信から複数の前記配信端末による配信に切り換える際、又は前記配信端末の台数を減少させる際において、配信を停止させる装置と配信を継続する装置の双方から一時的に画像ストリームを配信させるとともに、各画像ストリームの帯域を通常時よりも低帯域にする、請求項５に記載の画像配信管理サーバ。
【請求項８】
ネットワークを介して接続された視聴者端末へ配信される画像の配信負荷量を取得する配信負荷量取得部と、前記配信負荷量に基づいて、前記視聴者端末への画像配信を行う配信装置の種類又は台数を決定する配信装置決定部と、を有し、前記配信装置は、前記視聴者端末へ画像を直接的に配信する１又は複数の配信端末、及び前記配信端末からアップロードされた画像を前記視聴者端末へ配信する配信サーバを含み、前記配信端末は、利用されていない空き配信端末を含み、前記配信装置決定部は、前記視聴者端末に関する情報に応じて前記配信装置の種類又は台数を決定し、前記視聴者端末に関する情報は、少なくとも画像配信先の現在又は過去の視聴者数又は配信される画像を予約している視聴者数を含み、前記配信装置決定部は、少なくとも画像配信先の現在又は過去の視聴者数又は配信される画像を予約している視聴者数に基づいて空き配信端末の数を決定する、画像配信管理サーバと、
前記ネットワークを介して前記画像配信管理サーバ及び前記視聴者端末と接続された前記配信装置と、
前記ネットワークを介して前記画像配信管理サーバ及び前記配信装置と接続された前記視聴者端末と、
を備える、画像配信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像配信管理サーバ及び画像配信管理システムに関する。
【背景技術】
【０００２】
従来、例えば下記の特許文献１には、ネットワークの余剰値や利用帯域の情報をもとにコンテンツを配信するかどうかを判断する手法が記載されている。また、下記の特許文献２には、負荷率に応じて回線を予備回線と運用回線を切り換える際に、負荷率テーブル、時間別履歴データなどを利用して判断する手法が記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００９−１１８３１９号公報
【特許文献２】特許第４０８３１６９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１に記載された技術では、配信サーバからの配信を行うのみであるため、配信サーバの負荷が高くなった場合に、配信が困難になることが想定される。また、特許文献２に記載された技術では、配信負荷の増大に対してサーバの回線を増加させるため、サーバを含めた構成が複雑になるとともに、コスト増を招来する問題がある。
【０００５】
そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、簡素な構成で画像配信の負荷に応じた配信装置を決定することが可能な、新規かつ改良された画像配信管理サーバ及び画像配信管理システムを提供することにある。
【課題を解決するための手段】
【０００６】
上記課題を解決するために、本発明のある観点によれば、ネットワークを介して接続された視聴者端末へ配信される画像の配信負荷量を取得する配信負荷量取得部と、前記配信負荷量に基づいて、前記視聴者端末への画像配信を行う配信装置の種類又は台数を決定する配信装置決定部と、を備える、画像配信管理サーバが提供される。
【０００７】
また、前記配信負荷量取得部は、画像配信先の前記視聴者端末に関する情報を取得する視聴者端末情報取得部を含み、前記配信装置決定部は、前記視聴者端末に関する情報に応じて前記配信装置の種類又は台数を決定するものであってもよい。
【０００８】
また、前記視聴者端末に関する情報は、少なくとも画像配信先の現在又は過去の視聴者数又は配信される画像を予約している視聴者数を含むものであってもよい。
【０００９】
また、前記配信負荷量取得部は、前記画像配信による前記ネットワークの利用帯域量を取得する利用帯域取得部を更に含み、前記配信装置決定部は、前記視聴者数及び前記利用帯域量に基づいて前記配信装置の種類又は台数を決定するものであってもよい。
【００１０】
また、前記配信装置は、前記視聴者端末へ画像を直接的に配信する１又は複数の配信端末、及び前記配信端末からアップロードされた画像を前記視聴者端末へ配信する配信サーバの少なくとも一方を含むものであってもよい。
【００１１】
また、前記配信装置決定部は、前記視聴者数又は前記利用帯域量に関する所定の閾値に基づいて、前記視聴者端末へ画像を配信する前記配信端末の台数を決定するとともに、前記配信サーバのみが前記視聴者端末へ画像を配信するか否かを決定するものであってもよい。
【００１２】
また、前記配信装置決定部は、前記視聴者数又は前記利用帯域量の増加に伴い画像を配信する前記配信端末の台数を増加させ、前記視聴者数又は前記利用帯域量が所定値を越えた場合は前記配信サーバのみが前記視聴者端末へ画像を配信することを決定するものであってもよい。
【００１３】
また、前記配信装置決定部は、前記視聴者数又は前記利用帯域量が所定値以下となった場合に前記配信サーバのみによる配信から複数の前記配信端末による配信に切り換えるとともに、前記視聴者数又は前記利用帯域量の更なる減少に応じて画像を配信する前記配信端末の台数を減少させるものであってもよい。
【００１４】
また、前記配信装置決定部は、前記配信サーバのみによる配信から複数の前記配信端末による配信に切り換える際、又は前記配信端末の台数を減少させる際において、配信を停止させる装置と配信を継続する装置の双方から一時的に画像ストリームを配信させるものであってもよい。
【００１５】
また、前記配信装置決定部は、前記配信サーバのみによる配信から複数の前記配信端末による配信に切り換える際、又は前記配信端末の台数を減少させる際において、配信を停止させる装置と配信を継続する装置の双方から一時的に画像ストリームを配信させるとともに、各画像ストリームの帯域を通常時よりも低帯域にするものであってもよい。
【００１６】
また、上記課題を解決するために、本発明の別の観点によれば、ネットワークを介して接続された視聴者端末へ配信される画像の配信負荷量を取得する配信負荷量取得部と、前記配信負荷量に基づいて、前記視聴者端末への画像配信を行う配信装置の種類又は台数を決定する配信装置決定部と、を有する画像配信管理サーバと、前記ネットワークを介して前記画像配信管理サーバ及び前記視聴者端末と接続された前記配信装置と、前記ネットワークを介して前記画像配信管理サーバ及び前記配信装置と接続された前記視聴者端末と、を備える、画像配信システムが提供される。
【発明の効果】
【００１７】
本発明によれば、簡素な構成で画像配信の負荷に応じた配信装置を決定することが可能な画像配信管理サーバ及び画像配信管理システムを提供することが可能となる。
【図面の簡単な説明】
【００１８】
【図１】ライブ映像を配信する手法の概略を示す模式図である。
【図２】図１（Ａ）に対応する、一般的なライブ映像配信のネットワークの構成を示す模式図である。
【図３】図１（Ｂ）で説明した、ライブ映像を直接配信するネットワークの構成を示す模式図である。
【図４】図３の構成において、配信端末による映像配信の入出力を表した図である。
【図５】空き配信端末を利用したライブ配信のネットワーク構成を示す模式図である。
【図６】視聴ユーザの視聴開始シーケンスを示す模式図である。
【図７】ライブ映像の配信者による配信開始処理を示すシーケンス図である。
【図８】配信管理サーバ内のデータベースで管理している情報を示す模式図である。
【図９】配信管理サーバによる、映像配信開始前に最適な配信方法を選択する処理を示すフローチャートである。
【図１０】ライブ映像配信中に最適な配信方法を判断する方法である。
【図１１】ライブ映像配信中に最適な配信方法を判断する方法である。
【図１２】配信管理サーバの機能ブロック構成を示す模式図である。
【図１３】視聴数予測値が増加し、また利用帯域予測値が増加して、新規に空き配信端末または配信サーバの利用を開始する際のシーケンス図である。
【図１４】視聴数予測値が減少し、利用帯域予測値が減少して、現在利用中の空き配信端末または配信サーバの利用を終了する場合のシーケンス図である。
【図１５】端末を切り替える際に一時的に低帯域の映像配信に接続する手法を示す模式図である。
【図１６】図１５で説明した手法を詳細に示すシーケンス図である。
【発明を実施するための形態】
【００１９】
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００２０】
なお、説明は以下の順序で行うものとする。
１．本実施形態のシステムの概要
２．本実施形態に係るシステムの具体的構成例
３．本実施形態に係るシステムの処理シーケンス
【００２１】
［１．システムの概要］
図１はライブ映像を配信する手法の概略を示す模式図である。図１（Ａ）は、スポーツ、コンサートなどで撮像されたライブ映像を配信サーバ１００に集約し、配信サーバ１００から各ユーザの視聴端末２００へライブ映像を送信する構成を示している。配信サーバ１００による送信では、多くの視聴端末２００へライブ映像を配信することができるが、配信コストが高くなるデメリットがある。一方、図１（Ｂ）は、ライブ映像を取得した配信端末３００から直接視聴端末２００へライブ映像を送信する構成を示している。この場合、配信サーバ１００には大きな負荷はかからないが、配信できるライブ映像の数が少なくなるデメリットがある。
【００２２】
［２．本実施形態に係るシステムの具体的構成例］
以下、図２に基づいて詳細に説明する。図２は、図１（Ａ）に対応する、一般的なライブ映像配信のネットワークの構成を示す模式図である。配信を行うユーザは、配信端末３００から動画配信サーバ１００にライブ映像をアップロードし、動画配信サーバ１００は、視聴端末２００にライブ映像を配信する。配信サーバ１００としては、動画配信性能などの性能が高い機器が使用される。また、配信サーバ１００が接続しているネットワーク１０００として帯域の大きいものを使用し、マルチキャストなどの技術を用いることにより、数千台以上の視聴端末２００に対して動画配信を行うことが可能である。一方、図２に示す構成では、性能の高い配信サーバ１００等の機器を用い、また帯域の大きいネットワーク１０００を利用するため、少数の視聴端末２００に動画配信を行う際は、以下に説明する図３の方法に比べて配信コストが割高となる。
【００２３】
図３は、図１（Ｂ）で説明した、ライブ映像を直接配信するネットワークの構成を示す模式図である。図３の構成では、動画配信サーバ１００を経由せずに配信端末３００からネットワーク１２００を介して直接的に視聴端末２００にライブ映像を配信する。近年の家庭用ネットワークの帯域の増加や、パーソナルコンピュータ（ＰＣ）などの能力向上により、ＨＤのライブ映像であっても、図３に示す構成を使用して数１０台程度の視聴端末２００へのライブ映像配信が可能である。図３の構成では、図２の配信方法と比較して性能の高い機器が必要なく、帯域の大きい専用のネットワークを用意する必要もないため、比較的低コストで配信を行うことが可能である。一方、図３の構成では、配信端末３００の能力は配信サーバ１００に比べて低く、ネットワーク１２００の帯域も図２のネットワーク１０００より小さいため、数多くの視聴端末２００にライブ映像を配信することには一定の困難が伴う。
【００２４】
図４は、図３の構成において、配信端末３００による映像配信の入出力を表した図である。配信端末３００には、カメラ（撮像装置）５００から、また、他の配信端末３００から映像が入力される。映像の入力は、有線（ケーブル）を経由したもの、ネットワークを経由したもの、のいずれでも構わない。配信端末３００は、入力された映像を複数の視聴端末２００に配信することが可能である。
【００２５】
図５は、空き配信端末３０２を利用したライブ配信のネットワーク構成を示す模式図である。配信端末３００は、ネットワーク経由の映像入力も配信できるため、この機能を生かして、現在利用していない空き配信端末３０２をライブ映像配信のためのブースターとして活用する。各々の配信端末３００、及び空き配信端末３０２がライブ映像を配信可能な視聴端末２００の合計数をＮとすると、空き配信端末３０２を利用することにより合計Ｎ個の視聴端末２００に対してライブ映像を配信することが可能となる。この配信方法では、図３で説明した配信端末３００のみによる直接配信で配信可能な視聴端末２００の数よりも多い視聴端末２００に対してライブ配信を行うことができる。一方、視聴端末２００の数がより多くなると、図２の配信サーバ１００による配信の方がコスト的に有利になる。従って、図５に示す配信方法は、視聴端末３００の数が、図２の配信サーバ１００での配信コストに見合う視聴者数より少ない場合の配信に適している。
【００２６】
以上のように、視聴端末２００の数に応じて配信端末３００、配信サーバ１００を適宜使用することで、効率的なライブ配信を行うため配信方法を最適に選択することができる。
【００２７】
図６は、視聴ユーザの視聴開始シーケンスを示す模式図である。まず、視聴端末２００は、配信管理サーバ４００に接続し（ステップＳ１０）、番組表を取得する。ユーザが番組表の中から視聴したい番組を選択すると、番組を選択したことが配信管理サーバ４００に通知される（ステップＳ１２）。視聴端末２００によって選択された番組が現在放送中の番組であれば、配信管理サーバ４００は、現在ライブ映像を配信している配信端末３００（または空き配信端末３０２）、または配信サーバ１００の情報を視聴端末２００に通知する（ステップＳ１４）。視聴端末２００は、通知された情報に基づいて、現在ライブ映像を配信している配信端末３００、空き配信端末３０２、または配信サーバ１００に接続し（ステップＳ１６）、ライブ映像の受信が開始される（ステップＳ１８）。
【００２８】
また、視聴端末２００によって選択された番組が放送前である場合は、番組の選択によって番組が予約されたことが配信管理サーバ４００に記憶される。そして、配信が始まった段階で、予約されたライブ映像を配信している配信端末３００、空き配信端末３０２、または配信サーバ１００の情報が視聴端末２００に通知されて、ライブ映像の受信が可能となる。配信管理サーバ４００においては、番組を予約したという情報は、効率的なライブ配信の配信判断のために利用される。
【００２９】
図６のシーケンスを用いることにより、ユーザは配信側の装置（配信サーバ１００、配信端末３００、空き配信端末３０２）の種類の違いに影響を受けることなく、同じ仕組みでライブ映像を受信することが可能となる。
【００３０】
図７は、ライブ映像の配信者による配信開始処理を示すシーケンス図である。予め、配信端末３００は、配信管理サーバ４００に番組情報を登録する（ステップＳ２０）。配信管理サーバ４００は、番組表に登録された番組情報を追加し、配信開始の一定時間前に最適な配信方法を判断し（ステップＳ２１）、配信端末３００に通知する（ステップＳ２２）。配信端末３００は、空き配信端末３０２または動画配信サーバ１００を利用する旨を配信管理サーバ４００から指定された場合は、指定された端末（空き配信端末３０２または配信サーバ１００）に接続し（ステップＳ２４）、動画配信を行う（ステップＳ２６）。この場合、配信端末３００から空き配信端末３０２へライブ映像が送られて、空き配信端末３０２から視聴端末２００へライブ映像が送信される。または配信端末３００から配信サーバ１００へライブ映像がアップロードされて、配信サーバ１００から視聴端末２００へライブ映像が送信される。また、配信端末３００は、配信管理サーバ４００から、配信端末３００自身が直接配信するように指定された場合は、視聴端末２００からの接続を受けて（ステップＳ２８）、映像の配信を行う（ステップＳ２９）。
【００３１】
次に、図７のステップＳ２１において、配信管理サーバ４００が最適な配信方法を選択する手法について説明する。図８は、配信管理サーバ４００内のデータベースで管理している情報を示す模式図である。図８に示すように、配信サーバ４００内のデータベースでは、番組表データベースと配信端末管理データベースを管理している。番組表データベースでは、番組名と配信者、配信時間、番組を予約した視聴者の数（視聴者予約数）、現在の視聴者数（視聴者数）などを管理する。配信端末管理データベースでは、配信端末名、配信端末のＩＰアドレス、配信可能数、現在の配信端末の状態、現在の配信数などを管理する。
【００３２】
図９は、配信管理サーバ４００による、映像配信開始前に最適な配信方法を選択する処理を示すフローチャートである。図９に示す処理による判断は、映像を配信する一定時間前に行われる。配信管理サーバ４００は、図９の処理に基づいて、番組視聴予約数や配信者の番組の過去の平均視聴者数、予告動画視聴数などの数が一定数を超えている場合は、今回の番組を視聴者数が多いと予測し、配信サーバ１００を利用した配信が最適であると判断する。具体的には、図９のステップＳ３０，Ｓ３２，Ｓ３４において、番組視聴予約数がＡ人よりも多い場合、過去の平均視聴者数がＢ人よりも多い場合、予約動画視聴数がＣ人よりも多い場合、のいずれかの条件が成立すれば、ステップＳ３６に進む。ステップＳ３６では、配信サーバ１００を利用した配信を行う。また、その他の条件として、配信者が作成したコミュニティへの参加人数や、配信者を「お気に入り」として登録しているユーザの人数など、視聴者数を予測できるパラメータを追加してもよい。
【００３３】
一方、視聴者数が少ないと予測される場合は、配信サーバ１００を利用しない。具体的には、図９のステップＳ３０，Ｓ３２，Ｓ３４のいずれかの条件も成立しない場合は、ステップＳ３８へ進む。そして、ステップＳ３８，Ｓ４０において、配信端末３００の配信可能数より視聴予約しているユーザ数が少ない場合、配信端末側３００のネットワーク帯域より映像配信に必要な総帯域の方が小さい場合、のいずれかの条件が成立すれば、配信端末３００のみからの配信では能力不足であると判断できるため、ステップＳ４４へ進み、空き配信端末３０２も利用した配信を行う。
【００３４】
また、ステップＳ３８，Ｓ４０において、配信端末の配信可能数が視聴予約しているユーザ数以上であり、且つ、配信端末側のネットワーク帯域が映像配信に必要な総帯域以上の場合は、ステップＳ４２へ進む。この場合、配信端末３００からの直接配信が可能であるため、ステップＳ４２では、配信端末３００から直接配信を行う。
【００３５】
空き配信端末３０２の選択は、図８に示した配信端末管理データベースから行う。この際、効率的な配信ができるように、配信端末３００が利用しているプロバイダと同じプロバイダを選択したり、番組終了時間まで空いていることが確実な空き配信端末３０２を選ぶようにしてもよい。
【００３６】
以上の方法により、放送前に最適な配信方法を選択するが、放送中に視聴者数の増減により最適な配信方法が変化する場合がある。例えば、放送中（映像配信中）に視聴者数が増加していくと、配信端末３００の能力不足や配信端末３００が接続するネットワーク１０００の帯域不足により、新規の視聴者に映像が配信できなくなる可能性がある。また、放送中に視聴者が減少していくと、現在の視聴者数に対して性能が過剰な配信端末３００や配信サーバ１００を使い続けてしまう可能性がある。
【００３７】
図１０及び図１１は、ライブ映像配信中に最適な配信方法を判断する方法である。図１０及び図１１に示す処理は、映像配信中に一定時間毎に行う。先ず、図１０に示すように、視聴者数の予測値を算出する。図１０に示すように、視聴者数の予測値（視聴者数予測値）は、過去のある時刻ｘと現在の時刻ｙとの間で、一定間隔でサンプリングした視聴者数Ｃ＿ｉに係数α＿ｉを乗算し、その和を算出した値となる。係数α＿ｉは総和が１であり、現在に近い時刻の傾向がより多く予測値に影響するように、現時刻に近い値を大きくする。次に、利用帯域の予測値を算出する。図１０に示すように、利用帯域の予測値（利用帯域予測値）は、過去のある時刻ｘと現在の時刻ｙとの間で、一定間隔でサンプリングした視聴者数Ｂ＿ｉに係数β＿ｉを乗算し、その和を算出した値とする。
【００３８】
次に、図１１に示すように、予め閾値ＣＴＨ＿ｌｏｗ＿１，ＢＴＨ＿ｌｏｗ＿１，ＣＴＨ＿ｈｉｇｈ＿１，ＢＴＨ＿ｈｉｇｈ＿１を算出しておき、これらの閾値に基づいて配信サーバを利用した配信を行うか、空き配信端末をｎ台利用した配信を行うかを決定する。ここで、閾値ＣＴＨ＿ｌｏｗ＿１は、視聴者数予測値の閾値であり、視聴者数予測値がこの閾値以上の場合は、「配信サーバを利用した配信」より「空き配信端末ｎ台を利用した配信」の方がコストが安くなり、能力上配信可能と判断できる値である。また、閾値ＢＴＨ＿ｌｏｗ＿１は、利用帯域予測値の閾値であり、利用帯域予測値がこの閾値以上の場合は、「配信サーバを利用した配信」より「空き配信端末ｎ台を利用した配信」の方が利用帯域上最適と判断できる閾値である。
【００３９】
図１１に示すように、ステップＳ４０で配信サーバ１００を利用した配信が行われている場合に、ステップＳ４２，Ｓ４４の条件がともに成立する場合は、ステップＳ４６へ進み、空き配信端末３０２をｎ台利用した配信を行う。すなわち、ステップＳ４２で視聴者数予測値≦ＣＴＨ＿ｌｏｗ＿１であり、且つ、ステップＳ４４で利用帯域予測値≦ＢＴＨ＿ｌｏｗ＿１の場合は、ステップＳ４６へ進み、空き配信端末３０２をｎ台利用した配信を行う。このように、現在「配信サーバを利用した配信」を行っている場合、視聴数予測値がＣＴＨ＿ｌｏｗ＿１以下であり、利用帯域予測値がＢＴＨ＿ｌｏｗ＿１以下の場合は、「空き配信端末ｎ台を利用した配信」が最適であると判断する。
【００４０】
また、ステップＳ４６で空き配信端末３０２をｎ台利用した配信が行われている場合に、ステップＳ４８，Ｓ４９の条件がともに成立する場合は、ステップＳ４０へ進み、配信サーバ１００を利用した配信を行う。すなわち、ステップＳ４８で視聴者数予測値≧ＢＴＨ＿ｈｉｇｈ＿１であり、且つ、ステップＳ４９で利用帯域予測値≧ＣＴＨ＿ｈｉｇｈ＿１の場合は、ステップＳ４０へ進み、配信サーバ１００を利用した配信を行う。このように、現在「空き配信端末ｎ台を利用した配信」を行っているときに利用帯域予測値がＢＴＨ＿ｈｉｇｈ＿１を超えるか、視聴数予測値がＣＴＨ＿ｈｉｇｈ＿１を超えるときは、「配信サーバを利用した配信」が最適であると判断する。
【００４１】
同様に、閾値ＣＴＨ＿ｌｏｗ＿ｋ，ＢＴＨ＿ｌｏｗ＿ｋ，ＣＴＨ＿ｈｉｇｈ＿ｋ，ＢＴＨ＿ｈｉｇｈ＿ｋは、空き配信端末３０２を１台利用した配信を行うか、配信端末３００から直接配信するか、を決定するための閾値である。図１１に示すように、予め閾値ＣＴＨ＿ｌｏｗ＿ｋ，ＢＴＨ＿ｌｏｗ＿ｋ，ＣＴＨ＿ｈｉｇｈ＿ｋ，ＢＴＨ＿ｈｉｇｈ＿ｋを算出しておき、これらの閾値に基づいて空き配信端末をｎ台利用した配信を行うか、配信端末３００から直接配信するかを決定する。なお、図１１では図示を一部省略しているが、空き配信端末３０２をｎ台利用した配信を行うか、の判定において、異なるｎの各値に対して閾値ＣＴＨ＿ｌｏｗ＿ｋ，ＢＴＨ＿ｌｏｗ＿ｋ，ＣＴＨ＿ｈｉｇｈ＿ｋ，ＢＴＨ＿ｈｉｇｈ＿ｋのｋの値は異なる。そして、異なるｎの各値に対して閾値ＣＴＨ＿ｌｏｗ＿ｋ，ＢＴＨ＿ｌｏｗ＿ｋ，ＣＴＨ＿ｈｉｇｈ＿ｋ，ＢＴＨ＿ｈｉｇｈ＿ｋの値が個別に設定される。従って、各閾値との比較の結果、空き配信端末３０２を何台利用した配信を行うか決定することができる。
【００４２】
図１１に示すように、ステップＳ５０で空き配信端末３０２を１台利用した配信が行われている場合に、ステップＳ５２，Ｓ５４の条件がともに成立する場合は、ステップＳ５６へ進み、配信端末３００からの直接配信を行う。すなわち、ステップＳ５２で視聴者数予測値≦ＣＴＨ＿ｌｏｗ＿ｋであり、且つ、ステップＳ４４で利用帯域予測値≦ＢＴＨ＿ｌｏｗ＿ｋの場合は、ステップＳ５６へ進み、配信端末３００からの直接配信を行う。
【００４３】
また、ステップＳ５６で配信端末３００からの直接配信が行われている場合に、ステップＳ５８，Ｓ５９の条件がともに成立する場合は、ステップＳ５０へ進み、空き配信端末３０２を１台利用した配信を行う。すなわち、ステップＳ５８で視聴者数予測値≧ＢＴＨ＿ｈｉｇｈ＿ｋであり、且つ、ステップＳ５９で利用帯域予測値≧ＣＴＨ＿ｈｉｇｈ＿ｋの場合は、ステップＳ５０へ進み、空き配信端末３０２を１台利用した配信を行う。
【００４４】
以上のようにして、配信管理サーバ４００は、「配信サーバを利用した配信」、「空き配信端末を１台利用した配信」、「空き配信端末をｎ台利用した配信」、「配信端末からの直接配信」までを含め、最適な配信方法を選択する。図１２は、配信管理サーバ４００の機能ブロック構成を示す模式図である。図１２に示すように、配信管理サーバ４００は、配信負荷量取得部４１０、配信装置決定部４２０、番組表データベース４３０、配信端末管理データベース４４０とを有して構成される。配信負荷量取得部４１０は、視聴者数取得部４１２と利用帯域取得部４１４を含む。視聴者数取得部４１２は、上述した手法により視聴者数を取得し、利用帯域取得部４１４は上述した手法により利用帯域量を取得する。配信装置決定部４２０は、配信負荷量（視聴者数、利用帯域量）に基づいて、視聴端末２００へライブ映像を送信する配信装置を決定する。具体的には、配信装置決定部４２０は、図１１の処理に沿って、「配信サーバを利用した配信」、「空き配信端末を１台利用した配信」、「空き配信端末をｎ台利用した配信」、「配信端末からの直接配信」のいずれかを決定する。また、配信装置決定部４２０は、配信側の装置を変更する場合は、その旨を通知する。更に、配信装置決定部４２０は、視聴端末２００に対して配信元の装置のＩＰアドレスを送信し、また配信元の装置に対して視聴端末２００のＩＰアドレスを送信する機能を担う。なお、図１２に示す各構成要素は、回路（ハードウェア）、またはＣＰＵなどの中央演算処理装置とこれを機能させるためのプログラム（ソフトウェア）によって構成することができる。このような構成によれば、配信管理サーバ４００は、視聴者数または利用帯域量に基づいて、配信装置の種類（配信サーバ１００または配信端末３００）、配信装置の台数（配信端末３００の台数）を動的に変更して決定することが可能である。
【００４５】
［３．本実施形態に係るシステムの処理シーケンス］
図１３は、ライブ映像配信中に視聴数予測値が増加し、また利用帯域予測値が増加して、新規に空き配信端末３０２または配信サーバ１００の利用を開始する際のシーケンス図である。先ず、ステップＳ６０では、配信端末３００から視聴端末２００へライブ映像を配信する。ステップＳ６２では、新規に視聴端末２００が配信管理サーバ４００に接続される。配信管理サーバ４００は一定時間毎に最適な配信方法を判断し（ステップＳ６４）、視聴ユーザの増加に伴って新規に空き配信端末３０２または配信サーバ１００を利用すべきと判断した場合、ステップＳ６６で配信端末３００に配信方法変更を通知する。配信端末３００は現在の配信状態を保ったまま、新規に指定された端末に接続し（ステップＳ６８）、動画配信を開始する。図１３の例において、ステップＳ６８で配信端末３００は空き配信端末３０２に接続するものとする。これにより、空き配信端末３０２の利用が開始され（ステップＳ７０）、配信端末３００から空き配信端末３０２へライブ動画が配信される（ステップＳ７２）。また、ステップＳ７４では、新規に接続された視聴端末２００に対して、空き配信端末３０２が配信することが通知され、ステップＳ７６では、新規に接続された視聴端末２００が空き配信端末３０２へ接続を行う。そして、ステップＳ７８では、空き配信端末３０２から新規に接続された視聴端末２００に対して動画が配信される。これにより、新規に追加された視聴端末２００に対しては、空き配信端末３０２から新たにライブ映像の配信を行うことができる。
【００４６】
図１４は、視聴数予測値が減少し、利用帯域予測値が減少して、現在利用中の空き配信端末３０２または配信サーバ１００の利用を終了する場合のシーケンス図である。先ず、配信端末３００から空き配信端末３０２または配信サーバ１００に動画が配信され、空き配信端末３０２または配信サーバ１００から視聴端末２００にライブ映像が配信されているものとする。ここでは、説明の便宜上、配信端末３００から空き配信端末３０２へ動画が配信されており（ステップＳ８０）、空き配信端末３０２から視聴端末２００へ動画が配信されているものとする（ステップＳ８２）。配信管理サーバ４００は、配信方法を判断し（ステップＳ８４）、視聴ユーザの減少などの要因によって配信端末を変更する場合は、現在動画を視聴している視聴端末２００に対して配信端末３００が変更されたことを通知する（ステップＳ８６）。この通知には、変更後の配信装置を指定する情報が含まれる。視聴端末２００は、指定に基づいて配信端末３００に接続し（ステップＳ８８）、配信端末３００から動画を受信する（ステップＳ９０）。これにより、視聴端末２００は、ステップＳ８２によるストリームとステップＳ９０によるストリームの２ストリームを同時に受信するため、配信先の端末を切り換える際に動画が途切れてしまうことを抑止できる。視聴端末２００が配信端末３００から動画をステップＳ９０で視聴し始めると、視聴端末２００と利用を終了する空き配信端末３０２との接続を切断する（ステップＳ９２）。その後、配信管理サーバ４００は、配信端末３００に配信方法の変更を通知し（ステップＳ９４）、配信端末３００は、利用を終了する空き配信端末３０２または配信サーバ１００との接続を切断する（ステップＳ９６）。
【００４７】
以上のように、本システムでは、ライブ配信のためVoDサービスとは異なり事前に映像データをキャッシュしておいて切り替えることはできない。そこで、シームレスに配信方法を切り替えるためには、図１４に示したように２ストリームを同時に受信する。なお、上記の例では、空き配信端末３０２からの視聴端末２００への配信を配信端末３００からの配信に切り換える例を示したが、配信サーバ１００からの配信に切り換える場合も同様に行うことができる。
【００４８】
図１４で説明した２ストリーム同時受信を行うことにより、視聴者が視聴している動画が途切れることなく配信方法を切り替えることが可能であるが、この場合、視聴端末２００側の帯域は一時的に２倍必要となる。ここで、例えばＮＧＮなどの帯域保障型のネットワークの場合、クライアント側が利用する保証帯域の大きさに制限があったり、利用帯域毎に課金が行われたりするため、配信方法を切り替える際にクライアントが使用する帯域を抑える必要が生じることが想定される。
【００４９】
以上の点に鑑み、図１５及び図１６は、端末を切り替える際に一時的に低帯域の映像配信に接続する手法を示している。図１５に示すように、先ずステップＳ１００では、配信端末（Ａ）３００から視聴端末２００へ広帯域を使用して動画を伝送する。次に、ステップＳ１０２では、配信端末（Ａ）３００から視聴端末２００へ広帯域を使用して動画を配信するとともに、配信端末（Ｂ）３００から視聴端末２００へ低帯域を使用して動画を配信する。次に、ステップＳ１０４では、配信端末（Ａ）３００から低帯域で動画を配信するとともに、配信端末（Ｂ）３００から低帯域で動画を配信する。次に、ステップＳ１０６では、配信端末（Ａ）３００から低帯域で動画を配信するとともに、配信端末（Ｂ）３００から広帯域で動画を配信する。以上のような手法によれば、配信端末（Ａ）３００と配信端末（Ｂ）３００の双方から動画が配信されるが、利用帯域が過度に増加してしまうことを抑止可能である。このため、視聴端末２００側の帯域が２倍必要になることはなく、最大で広帯域＋低帯域分の帯域があれば、シームレスに配信方法を切り替えることが可能となる。
【００５０】
図１６は、図１５で説明した手法を詳細に示すシーケンス図である。先ず、ステップＳ１１０では、配信端末（Ｂ）３００から配信端末（Ａ）３００へ広帯域を使用して動画の配信が行われる。次にステップＳ１１２では、配信端末（Ａ）３００から視聴端末２００へ広帯域を使用して動画の配信が行われる。配信管理サーバ４００は、視聴ユーザ数をモニタし、視聴ユーザ数が減少したことを検知すると（ステップＳ１１４）、配信端末（Ａ）３００及び配信端末（Ｂ）３００に対して低帯域を使用した動画配信を開始する旨を通知する（ステップＳ１１６，Ｓ１１８）。
【００５１】
次に、ステップＳ１２０では、配信管理サーバ４００から視聴端末２００に対して配信端末が変更された旨が通知される。これにより、視聴端末２００は、低帯域で配信端末（Ａ）３００との接続を行う（ステップＳ１２２）。ステップＳ１２４では、ステップＳ１１８で低帯域を使用した動画配信を開始する旨を通知された配信端末（Ｂ）３００が、配信端末（Ａ）３００への動画配信を広帯域から低帯域へ切り換える。そして、ステップＳ１２６では、配信端末（Ａ）３００から視聴端末２００への動画配信が低帯域で行われる。
【００５２】
次に、ステップＳ１２８では、視聴端末２００と配信端末（Ａ）３００との間の広帯域の接続が切断される。次にステップＳ１３０では、視聴端末２００と配信端末（Ｂ）３００とが低帯域で接続され、ステップＳ１３２において、配信端末（Ｂ）３００から視聴端末２００へ低帯域を使用して動画が配信される。
【００５３】
次に、ステップＳ１３４では、視聴端末２００と配信端末（Ａ）３００との間の低帯域の接続が切断される。次にステップＳ１３６では、視聴端末２００と配信端末（Ｂ）３００とが広帯域で接続され、ステップＳ１３８において、配信端末（Ｂ）３００から視聴端末２００へ広帯域を使用して動画が配信される。そして、ステップＳ１４０では、視聴端末２００と配信端末（Ｂ）３００との間の低帯域の接続が切断される。
【００５４】
図１６に示すシーケンスによれば、視聴端末２００が２ストリームの広帯域で配信端末（Ａ）３００及び配信端末（Ｂ）３００の双方に接続されることがないため、帯域の増加を最小限に抑えることが可能である。
【００５５】
以上説明したように本実施形態によれば、ライブ映像の配信コストや配信に利用するネットワーク帯域などの観点で最適な配信方法を事前に選択することが可能となる。また、映像の配信中であっても配信コストや配信に利用するネットワーク帯域などの観点で最適な配信方法を選択し続けることが可能となる。更に、映像の配信中に最適な配信方法にシームレスに切り替えることが可能になるとともに、視聴中の映像が途切れることなく利用中の配信端末や配信サーバの利用を停止し、最適な配信方法に切り替えることが可能となる。また、利用中の配信端末や配信サーバの利用を停止する際にも、視聴端末側のネットワーク帯域の増大を抑えながらシームレスに利用を停止することが可能となる。更に本実施形態によれば、配信サーバの負荷が高くなったときに配信ユーザから配信して負荷分散が可能となり、配信者毎の視聴者数を予測することも可能となる。そして、本実施形態によれば、サーバの回線を増やすのではなく、端末から配信することで、サーバの回線を増加させてなくても負荷分散が可能となる。
【００５６】
以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。
【符号の説明】
【００５７】
４００    配信管理サーバ
４１０    配信負荷量取得部
４１２    視聴者数取得部
４１４    利用帯域取得部
４２０    配信装置決定部
【図１】
0005640430.tif 000002
【図２】
0005640430.tif 000003
【図３】
0005640430.tif 000004
【図４】
0005640430.tif 000005
【図５】
0005640430.tif 000006
【図６】
0005640430.tif 000007
【図７】
0005640430.tif 000008
【図８】
0005640430.tif 000009
【図９】
0005640430.tif 000010
【図１０】
0005640430.tif 000011
【図１１】
0005640430.tif 000012
【図１２】
0005640430.tif 000013
【図１３】
0005640430.tif 000014
【図１４】
0005640430.tif 000015
【図１５】
0005640430.tif 000016
【図１６】
0005640430.tif 000017