JP2019118096A - サーバおよびプログラム - Google Patents

Abstract

【課題】マルチカメラ映像配信サービスの利用者に視聴するカメラ映像を選択可能とさせながらも多数のカメラ映像に観客が分散するのを抑制する。【解決手段】本発明の一態様によれば、観客に複数の視点のカメラ映像を巡回させるマルチカメラ映像配信サービスのために観客端末へ配信するカメラ映像を制御するサーバが提供される。サーバは、選出部と、決定部とを含む。選出部は、観客端末へ配信するカメラ映像を観客に選択させる選択機会のそれぞれについて、複数の候補を選出する。決定部は、観客端末へ配信するカメラ映像を複数の選択肢のうち観客の選んだ選択肢を示す情報に基づいて決定する。選択機会の少なくとも１回において選出される複数の候補のうち少なくとも１つは、観客が複数の候補の選出時に視聴しているカメラ映像に関わらず、共通のカメラ映像を含む。【選択図】 図２

Description

本発明は、マルチカメラ映像配信システムに関する。

従来、例えば野球、サッカーなどのスポーツの試合の番組では、視点の異なる多数のカメラが同時に撮影を行うことで、得点した選手の表情の映像、競技場全体を俯瞰する映像などを同時に得ることができる。従来の放送コンテンツでは、いつ、どの視点を選択して放送されるかは、放送側で決定され、視聴者には決定権がない。この点は、何の操作も必要とせずにメリハリのある映像が視聴できるというメリットがある一方で、例えば、特定の選手の挙動をずっと見ていたい、などの一部の視聴者のニーズには応えられない。

また、例えば、自律的に行動する多数のキャラクタが併存する仮想世界の様子を多視点の仮想カメラによって撮影した映像をリアルタイムにストリーミング配信し、多数の観客（視聴者）がこの映像を鑑賞するという共体験を提供するオンラインサービスが今後登場する可能性がある。かかるオンラインサービスにおいて、観客はどのキャラクタを撮影した映像を視聴するかを選択したいと考える可能性がある。

このような多視点の（物理）カメラ、または仮想カメラによって撮影された映像をストリーミング配信する場合に、観客が任意の視点のカメラ映像を選択できるようにすることが望まれる。全ての視点のカメラ映像を同時に配信することができれば、観客は任意の視点のカメラ映像を選択できることになる。しかしながら、他方では、他の観客と同じ視点のカメラ映像を楽しむという共体験を提供するためには、選択可能な視点をある程度制限して同じ視点のカメラ映像を視聴する観客数をある程度確保する必要がある。

特許文献１（要約書等）には、マルチアングル放送サービスを提供するシステムにおいて、送信装置（サーバ）がマルチ画面映像（複数の選択肢）を生成して受信装置（視聴者）に送信し、受信装置が、マルチ画面を受信してユーザの選択（第２の情報）に応じてソース映像を復号化することが開示されており、また、受信装置では、ユーザの選択に関わらず共通の視点に関連した映像（図２のａ〜ｄ）が表示されている。

特許文献２（［００３６］、要約書）には、多視点コンテンツ撮影システムで撮影した映像ファイルをインターネット経由でストリーミング配信するシステムにおいて、ユーザが自分の見たい視点を自由にかつ手軽に視聴できるインタフェースを用意し、映像ストリームに割り当てる帯域を動的に適応的に割り当てることが開示されている。具体的には、ある視点の映像を視聴しているときには、その広帯域符号化データを優先的にストリーミング配信し、他の表示されていない映像には狭帯域符号化データを常時ストリーミング配信している。

特開２０１１−８２９８２号公報 特開２０１３−１８３２０９号公報

例えば、個々の観客に次にどの視点のカメラ映像を視聴したいかを順次選択させるようにすれば、観客は選択肢の中から好みの視点のカメラ映像を選ぶことができる。このようなカメラ映像の巡回配信により、観客のニーズを満足させることができるかもしれない。しかしながら、個々の観客に、視聴するカメラ映像を完全に自由に選択させると、選択を行う度に同時配信する必要のあるカメラ映像が繰り返し分岐し、最終的には各観客が全くばらばらのカメラ映像を視聴しているという事態になりかねない。

単純な２択を行うだけでも、７回目の選択後に観客が視聴する可能性のあるカメラ映像の総数は１００を超える。同一視点のカメラ映像を視聴する観客数がある程度確保されなければ、他の観客と同じ視点のカメラ映像を楽しむという共体験の魅力が損なわれる。そこで、配信されるカメラ映像の選択に観客の意思を反映させながらも、観客が多数のカメラ映像に分散するのを防いで共体験の魅力が損なわれないようにする仕組みが求められる。

本発明は、マルチカメラ映像配信サービスの利用者に視聴するカメラ映像を選択可能とさせながらも多数のカメラ映像に観客が分散するのを抑制することを目的とする。

本発明の一態様によれば、観客に複数の視点のカメラ映像を巡回させるマルチカメラ映像配信サービスのために観客端末へ配信するカメラ映像を制御するサーバが提供される。サーバは、選出部と、生成部と、送信部と、受信部と、決定部とを含む。選出部は、観客端末へ配信するカメラ映像を観客に選択させる選択機会のそれぞれについて、複数の候補を選出する。生成部は、選出された複数の候補にそれぞれ関連付けられる複数の選択肢を観客へ提示するための第１の情報を生成する。送信部は、第１の情報を観客端末へ送信する。受信部は、複数の選択肢のうち観客の選んだ選択肢を示す第２の情報を受信する。決定部は、観客端末へ配信するカメラ映像を第２の情報に基づいて決定する。選択機会の少なくとも１回において選出される複数の候補のうち少なくとも１つは、観客が複数の候補の選出時に視聴しているカメラ映像に関わらず、共通のカメラ映像を含む。

本発明の別の態様によれば、観客に複数の視点のカメラ映像を巡回させるマルチカメラ映像配信サービスのために観客端末へ配信するカメラ映像を制御するサーバが提供される。サーバは、判定部と、選出部と、生成部と、送信部と、受信部と、決定部とを含む。判定部は、所定の条件が満足されているか否かを判定する。選出部は、所定の条件が満足されていないと判定された場合に、観客端末へ配信するカメラ映像を観客に選択させる選択機会のそれぞれについて、複数の第１の候補を選出する。生成部は、所定の条件が満足されていないと判定された場合に、選出された複数の第１の候補にそれぞれ関連付けられる複数の選択肢を観客へ提示するための第１の情報を生成する。送信部は、所定の条件が満足されていないと判定された場合に、第１の情報を観客端末へ送信する。受信部は、所定の条件が満足されていないと判定された場合に、複数の選択肢のうち観客の選んだ選択肢を示す第２の情報を受信する。決定部は、所定の条件が満足されていないと判定された場合に、観客端末へ配信するカメラ映像を第２の情報に基づいて決定する。所定の条件が満足されていると判定された場合に、（ａ）選出部は、観客が所定の条件の満足時に視聴しているカメラ映像に関わらず、共通の少なくとも１つのカメラ映像を第２の候補として選出し、（ｂ）決定部は、観客端末へ配信するカメラ映像を、第２の候補から決定する。第２の候補の総数は、観客が所定の条件の満足時に視聴しているカメラ映像の総数よりも少ない。

本発明によれば、マルチカメラ映像配信サービスの利用者に視聴するカメラ映像を選択可能とさせながらも多数のカメラ映像に観客が分散するのを抑制することができる。

第１の実施形態に係る制御サーバを含むマルチカメラ映像配信システムの一例を示すブロック図。 第１の実施形態に係る制御サーバを例示するブロック図。 観客端末へ配信するカメラ映像の候補の選出に制限を加えないことの問題点の説明図。 図２の制御サーバによる、観客端末３００へ配信するカメラ映像の制御の一例の概念図。 図２の制御サーバによる、観客端末３００へ配信するカメラ映像の制御の別の例の概念図。 図２の制御サーバによる、観客端末３００へ配信するカメラ映像の制御の別の例の概念図。 図２の制御サーバによる、観客端末３００へ配信するカメラ映像の制御の別の例の概念図。 図２の制御サーバの動作を例示するフローチャート。 第２の実施形態に係る制御サーバを例示するブロック図。 図９の制御サーバの動作を例示するフローチャート。

以下、図面を参照しながら実施形態の説明を述べる。なお、以降、説明済みの要素と同一または類似の要素には同一または類似の符号を付し、重複する説明については基本的に省略する。例えば、複数の同一または類似の要素が存在する場合に、各要素を区別せずに説明するために共通の符号を用いることがあるし、各要素を区別して説明するために当該共通の符号に加えて枝番号を用いることもある。

（第１の実施形態）
第１の実施形態に係る制御サーバは、図１に示される、マルチカメラ映像配信システムに組み込むことができる。このマルチカメラ映像配信システムは、配信者端末１００−１，１００−２，・・・と、動画配信サーバ２００と、観客端末３００−１，３００−２，・・・と、制御サーバ４００とを含む。なお、以降の説明では便宜上、マルチカメラ映像は生配信されることとするが、本実施形態は、録画済みのマルチカメラ映像が配信されるケースにも適用可能である。

図１の例では、動画配信サーバ２００は後述される制御サーバ４００と協同して、観客端末３００にマルチカメラ映像配信サービスを提供することができる。マルチカメラ映像配信サービスでは、制御サーバ４００が観客端末３００へ次に配信するカメラ映像（すなわち、配信映像）を決定し、動画配信サーバ２００は決定されたカメラ映像を観客端末３００へ固定期間または可変期間（観客にアンケートを取って延長または打ち切りをできるようにしてもよい）に亘って配信し、そして再び制御サーバ４００が観客端末３００へ次に配信するカメラ映像を決定する。制御サーバ４００は、配信映像を決定する機会の一部または全部において、観客に配信映像を選択させてもよい。これにより、制御サーバ４００はマルチカメラ映像配信サービスの利用者に視聴するカメラ映像を選択させることができる。そして、制御サーバ４００は、観客端末３００へ配信映像の候補の選出に後述される制限を加えて少数のカメラ映像に観客を収束させることで、多数のカメラ映像に観客が分散するのを抑制し、ひいてはマルチカメラ映像配信サービスによって使用されるストリーミング数の増大を防ぐことができる。

動画配信サーバ２００は、配信者端末１００、観客端末３００および制御サーバ４００とネットワーク経由で接続しており、データを互いに送受信できる。同様に、制御サーバ４００は、動画配信サーバ２００および観客端末３００とネットワーク経由で接続している。制御サーバ４００は、観客端末３００へ後述される選択肢を提示するための情報（第１の情報）を送信したり、観客端末３００から観客が選んだ選択肢を示す情報（第２の情報）を受信したり、観客端末３００へ配信すべきカメラ映像、すなわち配信映像を動画配信サーバ２００に指示したりする。

なお、制御サーバ４００は、動画配信サーバ２００の代わりに配信者端末１００に配信映像を指示してもよい。これにより、配信者端末１００は一部の視点のカメラ映像を伝送せずに済み、動画配信サーバ２００の負荷も抑えられる。

なお、図１において示される各装置の数は、例示に過ぎない。例えば、配信者端末１００および観客端末３００の数は、時々刻々と変化するので、０となることがあり得るし、数百、数千となることもあり得る。また、図１に示されない、Ｗｅｂサーバまたはコメント配信サーバがさらに設けられてもよいし、これらの機能が動画配信サーバ２００に組み込まれてもよい。また、動画配信サーバ２００および制御サーバ４００は統合されてもよい。

配信者端末１００は、例えば複数の（ビデオ）カメラなどの映像ソースに接続されたコンピュータなどの電子デバイス、例えば、テレビ受像機（インターネットテレビを含む）、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、モバイル端末（例えば、タブレット、スマートフォン、ラップトップ、フィーチャーフォン、ポータブルゲーム機、デジタルミュージックプレイヤー、電子書籍リーダなど）、ＶＲ（Ｖｉｒｔｕａｌ Ｒｅａｌｉｔｙ）端末、ＡＲ(Ａｕｇｍｅｎｔｅｄ Ｒｅａｌｉｔｙ)端末などであり得るが、これらに限られない。配信者端末１００は、映像ソースから出力されるエンコード済みの映像データを動画配信サーバ２００へ逐次送信する。配信者端末１００は、必ずしも全ての視点のカメラ映像を動画配信サーバ２００へ送信する必要はなく、配信対象となる一部の視点のカメラ映像に限って動画配信サーバ２００へ送信してもよい。いずれの視点のカメラ映像が配信対象となるかは、配信者によって決定されてもよいし、動画配信サーバ２００または制御サーバ４００（間接的には観客）によって決定されてもよい。

カメラは、例えば、スマートフォンに付属のカメラ、ＰＣに付属のカメラなどであり得る。また、カメラは、物理カメラに限られず、例えばゲーム空間などの仮想空間を撮影する仮想カメラであってもよいし、物理カメラおよび仮想カメラの組み合わせ（例えば、ＡＲ空間を撮影するカメラ）であってもよい。

ここで、配信者端末１００は、例えば個人的に撮影されたマルチカメラ映像の配信に適してはいるものの、あくまでマルチカメラ映像配信システムにおける映像ソースの一例に過ぎない。具体的には、配信者端末１００は、競技（例えば、スポーツ、将棋、囲碁）、または興行（例えば、演劇、コンサート）などを複数の物理カメラによって撮影した多視点の映像を集めて配信するサーバ、複数の仮想カメラによって仮想空間を撮影可能なプログラムを実行する（ゲーム）サーバなどに置き換えられてもよい。

動画配信サーバ２００は、配信者端末１００から逐次送信される、エンコード済みの映像データを受信する。そして、動画配信サーバ２００は、この映像データを、当該映像データを視聴している観客端末３００（および、必要があれば配信者端末１００）へ配信する。観客端末３００は、配信者端末１００と同様の電子デバイスであり得るが、配信者端末１００とは異なり映像ソースに接続される必要はない。

制御サーバ４００は、配信映像を制御する。制御サーバ４００は、現在配信可能な複数のカメラ映像から、観客端末３００へ次に配信するカメラ映像について複数の候補を選出する。そして、制御サーバ４００は、これら複数の候補それぞれに関連付けられる複数の選択肢を観客端末３００において提示するための情報を生成し、当該情報を観客端末３００へ送信する。観客端末３００からはどの選択肢を選んだかを示す情報が返され、制御サーバ４００はこの情報に基づいて観客端末３００へ次に配信するカメラ映像を決定し、このカメラ映像を観客端末３００へ配信するように配信者端末１００または動画配信サーバ２００に指示する。

なお、制御サーバ４００は、配信映像を、毎回観客の選択に基づいて決定する必要はなく、所定のアルゴリズムにより決定することがあってもよい。制御サーバ４００は、後述されるように、観客端末３００へ次に配信するカメラ映像を観客に選択させる選択機会の少なくとも一部において、少数のカメラ映像に観客を収束させるために配信映像の候補の選出に制限を加えることで、マルチカメラ映像配信サービスの利用者に視聴するカメラ映像を選択可能とさせながらも、観客が多数のカメラ映像に分散することによるストリーミング数の増大を抑制することができる。

以下、図１中の制御サーバ４００の構成および動作について順に図面を用いて説明する。

制御サーバ４００は、コンピュータであって、配信映像の候補の選出、選択肢を提示するための情報の生成、配信映像の決定、などを行うプロセッサと、かかる処理を実現するために当該プロセッサによって実行されるプログラムおよび当該プロセッサによって使用されるデータなどを一時的に格納するメモリとを含んでいる。

制御サーバ４００は、さらに、ネットワークに接続するための通信装置を利用可能である。通信装置は、制御サーバ４００に内蔵されてもよいし、制御サーバ４００に外付けされてもよい。

通信装置は、ネットワーク経由で動画配信サーバ２００および観客端末３００と通信をする。例えば、通信装置は、現在配信可能なカメラ映像の情報などを受信したり、配信者端末１００または動画配信サーバ２００へ配信映像を指示したり、観客端末３００へ選択肢を提示するための情報を送信したり、観客端末３００から観客の選んだ選択肢を示す情報を受信したりする。

次に、図２を用いて制御サーバ４００の構成例の説明を続ける。図２の制御サーバ４００は、カメラ映像情報取得部４０１と、配信映像候補選出部４０２と、選択肢生成部４０３と、送信部４０４と、配信映像決定部４０５と、受信部４０６とを含む。

カメラ映像情報取得部４０１は、現在配信可能な、すなわち配信映像として選択可能なカメラ映像の情報を取得する。カメラ映像情報取得部４０１は、例えば配信者端末１００または動画配信サーバ２００からネットワーク経由でカメラ映像の情報を受信してもよい。カメラ映像情報取得部４０１は、前述の通信装置であってもよいし、当該通信装置とのインターフェースであってもよい。

カメラ映像の情報は、例えば、マルチカメラ映像および／またはその配信者を識別する情報、マルチカメラ映像に含まれる個々のカメラ映像を識別する情報、カメラ映像／マルチカメラ映像の時間枠を示す情報、カメラ映像／マルチカメラ映像に付与されたメタデータ（例えば、カメラの撮影位置、撮影目的、撮影対象もしくは撮影方法、動画タグ（キーワード）、スポンサー名、番組カテゴリ）、配信者コメント、説明文、カメラ映像／マルチカメラ映像および／または配信者の属性情報、カメラ映像／マルチカメラ映像の観客数および／またはコメント数、カメラ映像／マルチカメラ映像のサムネイル画像データ、カメラ映像／マルチカメラ映像の（映像）データ、カメラ映像／マルチカメラ映像に投稿されたコメントなどであり得る。

カメラ映像情報取得部４０１は、カメラ映像の情報を配信映像候補選出部４０２、選択肢生成部４０３および配信映像決定部４０５へ送る。なお、カメラ映像の情報は、例えば図示されない記憶部に保存され、これを配信映像候補選出部４０２、選択肢生成部４０３および配信映像決定部４０５が適宜参照してもよい。また、制御サーバ４００が動画配信サーバ２００に組み込まれる場合には、カメラ映像情報取得部４０１は不要となり得る。

配信映像候補選出部４０２は、カメラ映像情報取得部４０１から現在配信可能なカメラ映像の情報を受け取る。配信映像候補選出部４０２は、配信映像を観客に選択させる選択機会のそれぞれについて、複数の候補を選出する。配信映像候補選出部４０２は、選出した複数の候補を選択肢生成部４０３に通知する。配信映像候補選出部４０２は、前述のプロセッサおよびメモリであってよい。

配信映像候補選出部４０２は、基本的には、任意のアルゴリズムで、複数の候補を選出してもよい。例えば、配信映像候補選出部４０２は、ランダムに複数の候補を選出してもよいし、カメラ映像の情報に含まれる要素、例えばカメラ映像／マルチカメラ映像および／または配信者の属性、カメラ映像／マルチカメラ映像に付与されたメタデータ、カメラ映像／マルチカメラ映像の観客数および／またはコメント数などに応じて、選出のされやすさを異ならせてもよい。ただし、配信映像候補選出部４０２は、選択機会の少なくとも一部において後述されるように候補の選出に制限を加えるので、観客が多数のカメラ映像に分散することによるストリーミング数の増大を抑制できる。

選択肢生成部４０３は、選択機会のそれぞれについて選出された複数の候補を配信映像候補選出部４０２から通知される。選択肢生成部４０３は、複数の候補にそれぞれ関連付けられる複数の選択肢を観客に提示するための情報を生成する。選択肢生成部４０３は、かかる情報を生成するために、カメラ映像情報取得部４０１からのカメラ映像の情報を利用してもよい。選択肢生成部４０３は、生成した情報を送信部４０４へ送る。選択肢生成部４０３は、前述のプロセッサおよびメモリであってよい。

選択肢生成部４０３によって生成される情報は、例えば、観客端末３００に表示される選択肢のデータそのものまたはそのベースとなるデータであってもよいし、選択肢を表示するように観客端末３００を制御するための制御データであってもよい。

なお、同一の候補について、ある観客端末３００において表示される選択肢は、別の観客端末３００において表示される選択肢と同一である必要はない。例えば、観客の属性に応じて適切に選択肢を設計することで、観客に次の配信映像へ興味を持たせ、マルチカメラ映像配信サービスの利用を継続するように動機付けることができる。ただし、観客単位で個別に選択肢を生成することはサーバ負荷が高いので、選択肢は、現在（例えば、複数の候補の選出時に）観客が視聴しているカメラ映像毎に管理されてもよい。すなわち、カメラ映像Ａを視聴している観客およびカメラ映像Ｂを視聴している観客の双方に、カメラ映像Ｃに関連付けられる選択肢が与えられるとして、この選択肢は互いに異なっていてもよい。同じカメラ映像を視聴している観客は視聴嗜好がある程度は類似していると推測できるので、観客が興味を持つ選択肢も類似する可能性がある。ここで、選択肢が異なるとは、観客端末３００に表示されるテキストまたは画像が異なることであり得る。

送信部４０４は、選択肢生成部４０３から、選択機会のそれぞれについて、複数の選択肢を観客に提示するための情報を受け取る。送信部４０４は、この情報をネットワーク経由で観客端末３００へ送信する。送信部４０４は、前述の通信装置であってもよいし、当該通信装置とのインターフェースであってもよい。

また、送信部４０４は、配信映像決定部４０５から決定した配信映像を示す情報、例えば配信映像（カメラ映像）の識別情報、ＵＲＬなどを受け取り、これをネットワーク経由で配信者端末１００または動画配信サーバ２００へ送信する。

受信部４０６は、ネットワーク経由で観客端末３００から観客の選んだ選択肢を示す情報を受信する。この情報は、送信部４０４によって送信された情報に対する観客からの回答に相当する。すなわち、この受信情報は、送信部４０４によって送信された情報に基づいて観客に提示された複数の選択肢のうち当該観客が選んだ選択肢を示す。受信部４０６は、受信情報を配信映像決定部４０５へ送る。受信部４０６は、前述の通信装置であってもよいし、当該通信装置とのインターフェースであってもよい。

配信映像決定部４０５は、受信部４０６から観客の選んだ選択肢を示す情報を受け取り、この情報に基づいて配信映像を観客毎に決定する。配信映像決定部４０５は、決定した配信映像を示す情報を送信部４０４へ送る。配信映像決定部４０５は、前述のプロセッサおよびメモリであってよい。

例えば、配信映像決定部４０５は、各観客に対する配信映像を、当該観客の選んだ選択肢に関連付けられたカメラ映像に決定してもよい。何れの選択肢も選ばなかった観客に対する配信映像は任意に決定されてよいが、例えば最も多くの観客から選ばれた選択肢に関連付けられたカメラ映像としてもよい。

また、観客から選ばれた数が極端に少ない選択肢については、観客の散らばりを抑制する観点から無視されてもよい。かかる選択肢を選んだ観客に対する配信映像は、何れの選択肢も選ばなかった観客に対する配信映像と同様に決定されてよい。観客から選ばれた数が極端に少ないか否かは、例えばその数、または全選択肢の中でその選択肢が選ばれた割合、などと閾値との比較により判定されてよい。

さらに、配信映像決定部４０５は、選択肢の数が配信映像に定められた上限数よりも少ない場合、例えば３択の選択肢が提示されたにも関わらず配信映像が最大２つと定められている場合には、観客から選ばれた数の降順に当該上限数まで選択肢を抽出し、抽出された選択肢に関連付けられたカメラ映像を配信映像として決定してもよい。抽出された選択肢を選ばなかった観客に対する配信映像は、何れの選択肢も選ばなかった観客に対する配信映像と同様に決定されてもよい。

以下、図３乃至図７を用いて、配信映像候補選出部４０２の動作の詳細について説明する。
配信映像候補選出部４０２が全ての選択機会において後述される制限を加えることなく候補を選出し、かつ、その候補が、観客が当時（複数の候補の選出時）視聴しているカメラ映像間で重複しなかったとする。この場合に、配信映像の総数は、図３に例示されるように指数関数的に増大する。すなわち、選択機会の度に、配信映像の総数は２倍になり、同時に配信映像あたりの観客数は半減する。そして、３回目の選択機会の後には、配信映像の総数は８個に散らばり、それぞれの観客は当初の１／８程度となる。

次に、配信映像候補選出部４０２が全ての選択機会において、観客が当時視聴しているカメラ映像に関わらず共通のカメラ映像を候補として選出したとする。この場合には、図４に例示されるように、観客が多数のカメラ映像に分散することはない。すなわち、どれだけ選択機会を重ねようと、それぞれのカメラ映像から観客が次に選択できるカメラ映像の集合は同じになるので、観客が視聴可能な（すなわち、同時配信する必要のある）配信映像の総数（ストリーミング数）を常に定数（これは、それぞれの選択機会おいて観客に提示される選択肢の数に等しく、図４の例では２つ）以下に抑えることができる。

これにより、観客にはカメラ映像を自由に選択しているという印象を与えながら、観客が多数のカメラ映像に分散することによるストリーミング数の増大を回避することができる。すなわち、どれだけ選択機会を重ねようと、配信映像あたりの観客数は維持されるので、他の観客と同じ視点のカメラ映像を楽しむという共体験の魅力が損なわれることもない。

なお、配信映像候補選出部４０２が候補の選出に加えることのできる制限は、図４に関して説明したものに限られない。例えば、配信映像候補選出部４０２が全ての選択機会において、観客が当時視聴しているカメラ映像に関わらず共通のカメラ映像を候補の一部として選出してもよい。具体的には、それぞれのカメラ映像から観客が次に選択できるカメラ映像のうち１つを共通化してもよい。この場合に、図５に例示されるように、選択機会の度に、配信映像の総数は１つずつ増え、それぞれの配信映像あたりの観客数は減少する。しかしながら、図３の例に比べれば、配信映像の総数の増加速度および配信映像あたりの観客数の減少速度を抑えることができる。

これにより、観客にはカメラ映像を自由に選択しているという印象を与えながら、観客が多数のカメラ映像に分散することによるストリーミング数の増大を抑制することができる。

さらに、図５の例では、前述の共通のカメラ映像に加えて、観客が当時視聴しているカメラ映像毎に個別に候補を選出することになる。配信映像候補選出部４０２は、かかる候補を、例えば観客が当時視聴しているカメラ映像の情報に依存して選出してもよい。これにより、図４の例に比べて、観客が自らの視聴嗜好に合致したカメラ映像を選択できるようになる可能性を高めることができる。

或いは、配信映像候補選出部４０２は必ずしも全ての選択機会において、候補の選出に制限を加えなくてもよい。すなわち、配信映像候補選出部４０２は、選択機会の少なくとも１回において、図４または図５に関して説明した制限を候補の選出に加えてもよい。

例えば、配信映像候補選出部４０２は、１回目および２回目の選択機会では候補の選出に制限を加えず、３回目の選択機会では、観客が候補の選出時に視聴しているカメラ映像に関わらず、共通のカメラ映像を選出してもよい。この場合に、図６に例示されるように、候補の選出に制限を加えない間は、図３の例と同様に選択機会の度に、配信映像の総数は２倍になり、同時に配信映像あたりの観客数は半減する。しかしながら、３回目の選択機会では候補の選出に制限を加えるので、配信映像の総数は強制的に最大２個に絞り込まれ、配信映像あたりの観客数も１回目の選択機会の後の水準に戻る。

或いは、配信映像候補選出部４０２は、１回目および２回目の選択機会では候補の選出に制限を加えず、３回目の選択機会では、観客が候補の選出時に視聴しているカメラ映像に関わらず、候補の一部として共通のカメラ映像（１つ）を選出してもよい。この場合に、図７に例示されるように、候補の選出に制限を加えない間は、図３の例と同様に選択機会の度に、配信映像の総数は２倍になり、同時に配信映像あたりの観客数は半減する。しかしながら、３回目の選択機会では候補の選出に制限を加えるので、配信映像の総数の増加速度および配信映像あたりの観客数の減少速度が鈍化する。

このように、配信映像候補選出部４０２は、候補の選出に制限を加えることで、観客が視聴可能な配信映像の総数を定数に抑えこんだり、配信映像の総数の増加速度および配信映像あたりの観客数の減少速度を鈍化させたりすることができる。また、配信映像候補選出部４０２は、かかる制限を常時加えてもよいし、断続的に加えてもよい。

なお、図４乃至図７の例では、観客に提示される選択肢の数は２つであったが、３以上であってもよい。また、これらの例では、最初の配信映像は全観客共通であったが、観客が最初から配信映像を選択できるようにしてもよい。さらに、配信映像の決定を必ずしも毎回、観客に委ねる必要はない。例えば、選択機会を１度与えてから次の選択機会を与えるまでの間に、配信映像決定部４０５は１つまたは複数の自動的に決定してもよい。このように選択機会を与える頻度を減らすことで、観客が頻繁（例えば数十秒おき）に選択肢を選ばなくても済むようになる。

次に図８を用いて、制御サーバ４００の動作例を説明する。制御サーバ４００は、カメラ映像の巡回配信が終了するまで、配信映像を観客に選択させる選択機会のそれぞれについて以下に説明するステップＳ５０１乃至ステップＳ５０８を繰り返す。なお、カメラ映像の巡回配信は、例えば１日毎などの所定の周期で終了するように定められてもよいし、特に終了期限を定めずに行われてもよい。

まず、ステップＳ５０１では、カメラ映像情報取得部４０１は動画配信サーバ２００が現在配信可能なカメラ映像の情報を取得し、処理はステップＳ５０２へ進む。なお、前述のようにカメラ映像の巡回配信の終了までステップＳ５０１乃至ステップＳ５０８は繰り返されるが、過去のステップＳ５０１の実行時に取得したカメラ映像の情報を更新する必要がない場合には、ステップＳ５０１の実行はスキップされてよい。

ステップＳ５０２では、配信映像候補選出部４０２による候補の選出に制限を加えるか否かが判定される。例えば、制限は、毎回加えられてもよいし、定期的またはランダムに加えられてもよいし、所定の条件の満足時（例えば、累積選択回数、観客が視聴可能な配信映像の総数、などが所定数に達した時）に加えられてもよい。制限を加える場合には処理はステップＳ５０３へ進み、制限を加えない場合には処理はステップＳ５０４へ進む。

ステップＳ５０３では、配信映像候補選出部４０２は、候補の選出における制限を有効にする。配信映像候補選出部４０２は、例えば制限の有効／無効を制御するフラグを書き換えてもよい。ステップＳ５０３の次に処理はステップＳ５０４へと進む。

ステップＳ５０４では、配信映像候補選出部４０２は、現在配信可能なカメラ映像から、配信映像についての複数の候補を選出する。ここで、配信映像候補選出部４０２は、ステップＳ５０１において取得したカメラ映像の情報に基づいて複数の候補を選出してもよい。

配信映像候補選出部４０２は、通常、観客が現在視聴しているカメラ映像毎に個別に複数の候補を選出する。しかしながら、ステップＳ５０３において制限が有効化されている場合には、配信映像候補選出部４０２は、観客が現在視聴しているカメラ映像に関わらず、少なくとも一部共通の候補を選出する。

選択肢生成部４０３は、ステップＳ５０４において選出された複数の候補にそれぞれ関連付けられる複数の選択肢を観客に提示するための情報を生成する（ステップＳ５０５）。ここで、選択肢生成部４０３は、ステップＳ５０１において取得したカメラ映像の情報に基づいて、選択肢を観客に提示するための情報を生成してもよい。

なお、ステップＳ５０３において制限が有効化されている場合には、あるカメラ映像を視聴している観客について選出される候補と他のカメラ映像を視聴している観客について選出される候補とが重複または一致することになる。このような場合であっても、選択肢生成部４０３は、同一の候補に対応する選択肢を、観客が視聴しているカメラ映像間で異ならせてもよい。

例えば、選択肢生成部４０３は、観客が視聴しているカメラ映像毎に、当該カメラ映像の情報と次の配信映像の候補の情報との類似点を表す選択肢を提示するための情報を生成してもよい。これにより、各観客に、自らが選んだ現在視聴しているカメラ映像に類似するカメラ映像が候補として選出されていると感じさせることができる。すなわち、観客がこれまで選んだ選択肢とかけ離れた選択肢が唐突に提示されるのを防ぐことができるので、観客に違和感を与えることなく、観客が一定数の配信映像に分散するようにしたり、または配信映像あたりの観客数の減少速度を鈍化させたりすることができる。

送信部４０４は、ステップＳ５０５において生成された情報をネットワーク経由で観客端末３００へ送信する（ステップＳ５０６）。ステップＳ５０６において送信された情報を受信した観客端末３００は、当該情報に基づいて複数の選択肢を提示する。観客端末３００は、観客が選んだ選択肢を示す情報をネットワーク経由で制御サーバ４００へ送信する。そして、受信部４０６は、この情報を受信する（ステップＳ５０７）。

配信映像決定部４０５は、ステップＳ５０７において受信された情報に基づいて、次の配信映像を決定する（ステップＳ５０８）。

ステップＳ５０８の終了後、制御サーバ４００はカメラ映像の巡回配信が終了するまで次の選択機会を待ち受ける（ステップＳ５０９）。次の選択機会が到来すると処理はステップＳ５０１に戻る。

以上説明したように、第１の実施形態に係る制御サーバは、観客へ配信するカメラ映像を観客に選択させる選択機会の少なくとも１回において、当該カメラ映像の候補の選出に制限を加える。この制限とは、選出される複数の候補の少なくとも一部を、観客が当該候補の選出時に視聴しているカメラ映像に関わらず共通とすることである。従って、この制御サーバによれば、観客にはカメラ映像を自由に選択しているという印象を与えながら、観客が一定数の配信映像に分散するようにしたり、または配信映像あたりの観客数の減少速度を鈍化させたりすることができる。

（第２の実施形態）
前述の第１の実施形態に係る制御サーバは、観客へ配信するカメラ映像（配信映像）を観客に選択させる選択機会の少なくとも１回において、当該配信映像の候補の選出に制限を加えることで、観客にはカメラ映像を自由に選択しているという印象を与えながら、観客が一定数の配信映像に分散するようにしたり、または配信映像あたりの観客数の減少速度を鈍化させたりする。

他方、これから説明する第２の実施形態に係る制御サーバは、配信映像を基本的に観客に自由に選択させつつも、観客が視聴可能な配信映像の総数が許容範囲を超えて増大している、またはそのおそれがある場合には、当該配信映像の総数を強制的に絞り込む。これにより、観客にはカメラ映像を自由に選択しているという印象を与えながら、観客が多数のカメラ映像に分散するのを抑制することができる。

第２の実施形態に係る制御サーバは、図２の制御サーバ４００と一部類似する。以降は、両者の異なる部分を中心に説明を続ける。本実施形態に係る制御サーバの一例が図９に示される。

図９の制御サーバ６００は、カメラ映像情報取得部４０１と、配信映像候補選出部６０２と、選択肢生成部４０３と、送信部４０４と、配信映像決定部６０５と、受信部４０６と、条件判定部６０７とを含む。

条件判定部６０７は、所定の条件が満足されているか否かを判定する。ここで、所定の条件は、観客が視聴可能な配信映像の総数が許容範囲を超えて増大している状態、またはそのおそれがある状態にあるか否かを判定するための条件として予め定義されている。

具体的には、所定の条件は、観客に与えられた選択機会の累計数が所定回数に達したこととしてもよい。配信映像を完全に観客の自由に選択させると、配信映像の総数は選択機会に対して指数関数的に増大する。故に、動画配信サーバ２００から観客が視聴可能な配信映像の総数の情報を受信しなくても、当該配信映像の総数と相関の高い観客の選択機会の累計数を検査することで、配信映像の総数が許容範囲を超えて増大している状態、またはそのおそれがある状態にあるか否かを判定することができる。

或いは、所定の条件は、観客が視聴可能な配信映像の総数が所定数に達したこととしてもよい。観客が視聴可能な配信映像の総数の情報は、動画配信サーバ２００から受信されてもよいし、上記選択機会の累計数、配信映像決定部６０５の出力などに基づいて算出されてもよい。

条件判定部６０７は、所定の条件が満足していると判定すると、配信映像候補選出部６０２および配信映像決定部６０５へ通知を行う。条件判定部６０７は、前述のプロセッサおよびメモリであってよい。

配信映像候補選出部６０２は、図２の配信映像候補選出部４０２と類似であるが少なくとも以下に説明する点で異なる。配信映像候補選出部６０２は、条件判定部６０７から所定の条件が満足していると通知されると、観客が当時（所定の条件の満足時に）視聴しているカメラ映像に関わらず、共通の少なくとも１つのカメラ映像を候補として選出する。この候補の総数は、１つであってもよいし、２以上であってもよいが、観客が当時視聴しているカメラ映像の総数よりも少ないこととする。これにより、観客が視聴可能な配信映像の総数を強制的に絞り込むことができる。配信映像候補選出部６０２は、選出した候補を配信映像決定部６０５へ送る。

配信映像決定部６０５は、図２の配信映像決定部４０５と類似であるが少なくとも以下に説明する点で異なる。配信映像決定部６０５は、条件判定部６０７から所定の条件が満足していると通知されると、観客の選択によらずに、配信映像候補選出部６０２によって選出された候補から配信映像を決定する。例えば、配信映像候補選出部６０２によって選出された候補の総数が１つの場合には、配信映像決定部６０５は全ての観客に対する次の配信映像を当該候補に決定すればよい。他方、かかる候補の総数が２以上の場合には、配信映像決定部６０５は、例えば同じカメラ映像を現在視聴している観客単位で、または観客毎に、候補のいずれかを次の配信映像として決定すればよい。配信映像決定部６０５は、配信映像をランダムに決定してもよいし、同じカメラ映像を現在視聴している観客単位で当該カメラ映像に類似する候補を配信映像として決定してもよい。観客が現在視聴しているカメラ映像に類似する候補を配信映像として決定すれば、観客は配信映像を直接選択することはできないが、自ら選んだカメラ映像に類似するカメラ映像（配信映像）へ誘導される。故に、観客に違和感を与えることなく、観客が視聴可能な配信映像の総数を強制的に絞り込むことができる。

なお、前述のように、所定の条件の満足時には、配信映像決定部６０５は配信映像を観客の選択によらずに決定する。故に、選択肢生成部４０３は選択肢を提示するための情報を生成しないし、送信部４０４はかかる情報を送信しないし、受信部４０６は観客が選んだ選択肢を示す情報を受信しない。

次に図９を用いて、制御サーバ６００の動作例を説明する。制御サーバ６００は、カメラ映像の巡回配信が終了するまで、配信映像を観客に選択させる選択機会のそれぞれについて以下に説明するステップＳ７０１乃至ステップＳ７０８を繰り返す。

まず、ステップＳ７０１では、カメラ映像情報取得部４０１は動画配信サーバ２００が現在配信可能なカメラ映像の情報を取得し、処理はステップＳ７０２へ進む。なお、前述のようにカメラ映像の巡回配信の終了までステップＳ７０１乃至ステップＳ７０８は繰り返されるが、過去のステップＳ７０１の実行時に取得したカメラ映像の情報を更新する必要がない場合には、ステップＳ７０１の実行はスキップされてよい。

ステップＳ７０２では、条件判定部６０７が所定の条件が満足しているか否かを判定する。所定の条件が満足していると判定された場合には処理はステップＳ７０３へ進み、そうでない場合には処理はステップＳ７０４へ進む。

ステップＳ７０３では、配信映像候補選出部６０２は、現在配信可能なカメラ映像の中から、観客が現在視聴しているカメラ映像に関わらず共通の１以上の候補を選出する。ここで、配信映像候補選出部６０２は、ステップＳ７０１において取得したカメラ映像の情報に基づいて１以上の候補を選出してもよい。ステップＳ７０３の後に処理はステップＳ７０８へと進む。

ステップＳ７０４では、配信映像候補選出部６０２は、現在配信可能なカメラ映像の中から、配信映像についての複数の候補を、観客が現在視聴しているカメラ映像のそれぞれについて選出する。ここで、配信映像候補選出部６０２は、ステップＳ７０１において取得したカメラ映像の情報に基づいて複数の候補を選出してもよい。

選択肢生成部４０３は、ステップＳ７０４において選出された複数の候補にそれぞれ関連付けられる複数の選択肢を観客に提示するための情報を生成する（ステップＳ７０５）。ここで、選択肢生成部４０３は、ステップＳ７０１において取得したカメラ映像の情報に基づいて、選択肢を観客に提示するための情報を生成してもよい。

送信部４０４は、ステップＳ７０５において生成された情報をネットワーク経由で観客端末３００へ送信する（ステップＳ７０６）。ステップＳ７０６において送信された情報を受信した観客端末３００は、当該情報に基づいて複数の選択肢を提示する。観客端末３００は、観客が選んだ選択肢を示す情報をネットワーク経由で制御サーバ６００へ送信する。そして、受信部４０６は、この情報を受信する（ステップＳ７０７）。

配信映像決定部６０５は、次の配信映像を決定する（ステップＳ７０８）。具体的には、ステップＳ７０２において所定条件が満足されていると判定された場合には、配信映像決定部６０５は、ステップＳ７０３において選出された１以上の候補から、所定のアルゴリズムにより次の配信映像を決定する。他方、ステップＳ７０２において所定条件が満足されていると判定されなかった場合には、配信映像決定部６０５は、ステップＳ７０４において選出された複数の候補の中から、ステップＳ７０７において受信された情報に基づいて次の配信映像を決定する。

ステップＳ７０８の終了後、制御サーバ６００はカメラ映像の巡回配信が終了するまで次の選択機会を待ち受ける（ステップＳ７０９）。次の選択機会が到来すると処理はステップＳ７０１に戻る。

以上説明したように、第２の実施形態に係る制御サーバは、配信映像を基本的に観客に自由に選択させつつも、所定の条件が満足されていると判定された場合に、観客が視聴可能な配信映像の総数を強制的に絞り込む。具体的には、この制御サーバは、観客が現在視聴している配信映像に関わらず共通の１以上（ただし、この数は観客が現在視聴しているカメラ映像の総数より少ない）の候補を選出し、選出された候補の中から次の配信映像を、同じカメラ映像を視聴している観客単位、観客毎、または全観客共通で決定する。従って、この制御サーバによれば、観客にはカメラ映像を自由に選択しているという印象を与えながら、観客が多数のカメラ映像に分散するのを抑制することができる。

上述の実施形態は、本発明の概念の理解を助けるための具体例を示しているに過ぎず、本発明の範囲を限定することを意図されていない。実施形態は、本発明の要旨を逸脱しない範囲で、様々な構成要素の付加、削除または転換をすることができる。

上記各実施形態において説明された種々の機能部は、回路を用いることで実現されてもよい。回路は、特定の機能を実現する専用回路であってもよいし、プロセッサのような汎用回路であってもよい。

上記各実施形態の処理の少なくとも一部は、汎用のコンピュータを基本ハードウェアとして用いることでも実現可能である。上記処理を実現するプログラムは、コンピュータで読み取り可能な記録媒体に格納して提供されてもよい。プログラムは、インストール可能な形式のファイルまたは実行可能な形式のファイルとして記録媒体に記憶される。記録媒体としては、磁気ディスク、光ディスク（ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ等）、光磁気ディスク（ＭＯ等）、半導体メモリなどである。記録媒体は、プログラムを記憶でき、かつ、コンピュータが読み取り可能であれば、何れであってもよい。また、上記処理を実現するプログラムを、インターネットなどのネットワークに接続されたコンピュータ（サーバ）上に格納し、ネットワーク経由でコンピュータ（クライアント）にダウンロードさせてもよい。

１００・・・配信者端末
２００・・・動画配信サーバ
３００・・・観客端末
４００，６００・・・制御サーバ
４０１・・・カメラ映像情報取得部
４０２，６０２・・・配信映像候補選出部
４０３・・・選択肢生成部
４０４・・・送信部
４０５，６０５・・・配信映像決定部
４０６・・・受信部
６０７・・・条件判定部

Claims (9)

1. 観客に複数の視点のカメラ映像を巡回させるマルチカメラ映像配信サービスのために観客端末へ配信するカメラ映像を制御するサーバであって、
   前記観客端末へ配信するカメラ映像を前記観客に選択させる選択機会のそれぞれについて、複数の候補を選出する選出部と、
   選出された前記複数の候補にそれぞれ関連付けられる複数の選択肢を前記観客へ提示するための第１の情報を生成する生成部と、
   前記第１の情報を前記観客端末へ送信する送信部と、
   前記複数の選択肢のうち前記観客の選んだ選択肢を示す第２の情報を受信する受信部と、
   前記観客端末へ配信するカメラ映像を前記第２の情報に基づいて決定する決定部と
   を具備し、
   前記選択機会の少なくとも１回において選出される前記複数の候補のうち少なくとも１つは、前記観客が当該複数の候補の選出時に視聴しているカメラ映像に関わらず、共通のカメラ映像を含む、
   サーバ。
2. 前記選択機会の少なくとも１回において選出される前記複数の候補は、前記観客が当該複数の候補の選出時に視聴しているカメラ映像に関わらず、共通のカメラ映像である、請求項１に記載のサーバ。
3. 前記選択機会のそれぞれにおいて選出される前記複数の候補のうち少なくとも１つは、前記観客が当該複数の候補の選出時に視聴しているカメラ映像に関わらず、共通のカメラ映像である、請求項１に記載のサーバ。
4. 前記選択機会のそれぞれにおいて選出される前記複数の候補はそれぞれ、前記観客が当該複数の候補の選出時に視聴しているカメラ映像に関わらず、共通のカメラ映像である、請求項１に記載のサーバ。
5. コンピュータに、観客に複数の視点のカメラ映像を巡回させるマルチカメラ映像配信サービスのために観客端末へ配信するカメラ映像を制御させるためのプログラムであって、
   前記コンピュータを、
   前記観客端末へ配信するカメラ映像を前記観客に選択させる選択機会のそれぞれについて、複数の候補を選出する手段、
   選出された前記複数の候補にそれぞれ関連付けられる複数の選択肢を前記観客へ提示するための第１の情報を生成する手段、
   前記第１の情報を前記観客端末へ送信する手段、
   前記複数の選択肢のうち前記観客の選んだ選択肢を示す第２の情報を受信する手段、
   前記観客端末へ配信するカメラ映像を前記第２の情報に基づいて決定する手段
   として機能させ、
   を具備し、
   前記選択機会の少なくとも１回において選出される前記複数の候補のうち少なくとも１つは、前記観客が当該複数の候補の選出時に視聴しているカメラ映像に関わらず、共通のカメラ映像を含む、
   プログラム。
6. 観客に複数の視点のカメラ映像を巡回させるマルチカメラ映像配信サービスのために観客端末へ配信するカメラ映像を制御するサーバであって、
   所定の条件が満足されているか否かを判定する判定部と
   前記所定の条件が満足されていないと判定された場合に、前記観客端末へ配信するカメラ映像を前記観客に選択させる選択機会のそれぞれについて、複数の第１の候補を選出する選出部と、
   前記所定の条件が満足されていないと判定された場合に、選出された前記複数の第１の候補にそれぞれ関連付けられる複数の選択肢を前記観客へ提示するための第１の情報を生成する生成部と、
   前記所定の条件が満足されていないと判定された場合に、前記第１の情報を前記観客端末へ送信する送信部と、
   前記所定の条件が満足されていないと判定された場合に、前記複数の選択肢のうち前記観客の選んだ選択肢を示す第２の情報を受信する受信部と、
   前記所定の条件が満足されていないと判定された場合に、前記観客端末へ配信するカメラ映像を前記第２の情報に基づいて決定する決定部と、
   を具備し、
   前記所定の条件が満足されていると判定された場合に、（ａ）前記選出部は、前記観客が当該所定の条件の満足時に視聴しているカメラ映像に関わらず、共通の少なくとも１つのカメラ映像を第２の候補として選出し、（ｂ）前記決定部は、前記観客端末へ配信するカメラ映像を、前記第２の候補から決定し、
   前記第２の候補の総数は、前記観客が前記所定の条件の満足時に視聴しているカメラ映像の総数よりも少ない、
   サーバ。
7. 前記所定の条件は、前記観客に与えられた選択機会の累計数が所定回数に達したことである、請求項６に記載のサーバ。
8. 前記所定の条件は、前記観客が視聴可能な配信映像の総数が所定数に達したことである、請求項６に記載のサーバ。
9. コンピュータに、観客に複数の視点のカメラ映像を巡回させるマルチカメラ映像配信サービスのために観客端末へ配信するカメラ映像を制御させるためのプログラムであって、
   前記コンピュータを、
   所定の条件が満足されているか否かを判定する手段、
   前記所定の条件が満足されていないと判定された場合に、前記観客端末へ配信するカメラ映像を前記観客に選択させる選択機会のそれぞれについて、複数の第１の候補を選出する手段、
   前記所定の条件が満足されていないと判定された場合に、選出された前記複数の第１の候補にそれぞれ関連付けられる複数の選択肢を前記観客へ提示するための第１の情報を生成する手段、
   前記所定の条件が満足されていないと判定された場合に、前記第１の情報を前記観客端末へ送信する手段、
   前記所定の条件が満足されていないと判定された場合に、前記複数の選択肢のうち前記観客の選んだ選択肢を示す第２の情報を受信する手段、
   前記所定の条件が満足されていないと判定された場合に、前記観客端末へ配信するカメラ映像を前記第２の情報に基づいて決定する手段、
   として機能させ、
   前記所定の条件が満足されていると判定された場合に、（ａ）前記選出する手段は、前記観客が当該所定の条件の満足時に視聴しているカメラ映像に関わらず、共通の少なくとも１つのカメラ映像を第２の候補として選出し、（ｂ）前記決定する手段は、前記観客端末へ配信するカメラ映像を、前記第２の候補から決定し、
   前記第２の候補の総数は、前記観客が前記所定の条件の満足時に視聴しているカメラ映像の総数よりも少ない、
   サーバ。