図面 (/)

技術 サーバおよびプログラム

出願人 株式会社ドワンゴ
発明者 川上量生齊藤寛明小嶋尚
出願日 2017年12月6日 (2年4ヶ月経過) 出願番号 2017-233938
公開日 2019年6月24日 (10ヶ月経過) 公開番号 2019-103047
状態 特許登録済
技術分野 計算機間の情報転送 双方向TV,動画像配信等
主要キーワード ミュージックプレイヤー 選択機 汎用回路 巡回対象 配信者端末 滞在地 枝番号 フィーチャーフォン
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2019年6月24日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (11)

課題

クルーズ利用者に行先を選択可能とさせながらも、クルーズの行先が発散することによるストリーミング数の増大を抑制する。

解決手段

本発明の一態様によれば、観客に複数の生配信コンテンツ巡回させるクルーズサービスのために観客端末へ配信する生配信コンテンツを制御するサーバが提供される。サーバは、選出部と、決定部とを含む。選出部は、観客端末へ配信する生配信コンテンツを観客に選択させる選択機会のそれぞれについて、複数の候補を選出する。決定部は、観客端末へ配信する生配信コンテンツを複数の選択肢のうち観客の選んだ選択肢を示す情報に基づいて決定する。選択機会の少なくとも1回において選出される複数の候補のうち少なくとも1つは、観客が当該複数の候補の選出時に視聴している生配信コンテンツに関わらず、共通の生配信コンテンツを含む。

概要

背景

近年、一部の動画共有システムでは、ユーザ(以降、単に配信者と呼ぶ)が撮影した動画を多数の観客インターネット経由で生配信(生放送とも呼ばれる)することが可能である。生配信コンテンツは、その性質上、観客が例えばキーワード検索などにより好みのものを見つけるのが困難である。このため、観客の生配信コンテンツに対する視聴行動は、典型的には、自らの好みの配信者の生配信コンテンツを選択的に視聴するか、生配信コンテンツのランキングを参照して面白そうなものをザッピングするかのどちらかになりがちである。

生配信コンテンツの楽しみ方の1つとして、「クルーズ」と呼ばれるサービスも既に運用されている(非特許文献1参照)。非特許文献1に記載の従来型のクルーズ(正式名称は、ニコ生クルーズ)は、複数の生配信コンテンツを例えば数十秒程度のサイクルで観客に次々に視聴(以下、巡回と呼ぶ)させるサービスであり、巡回する生配信コンテンツはサービス提供者によって決定される。クルーズを利用中(乗中)の観客は、次の生配信コンテンツに進むか、現在の生配信コンテンツに留まる(降船する)かを選択することができる。

クルーズは、観客には、能動的にコンテンツを探さなくても様々な生配信コンテンツを視聴できるというメリットがあり、配信者には、大量の観客に自己の生配信コンテンツを一時的に視聴してもらえる機会が与えられ、新規フォロワー、例えばチャンネル入会者の獲得を期待できるというメリットがある。

特許文献1には、所定の放送局装置を巡回して、各放送局装置からストリーミングデータを順次受信して、下位装置に接続された受信装置に配信可能な巡回配信装置[0009]が開示されており、接続すべき特定配信装置接続順序を、巡回配信装置の操作者が自由に設定できること[0090]が記載されている。また、第2の実施形態では、ノード装置により構成された巡回再生装置[0092]が開示されており、当該ノード装置の操作者が巡回対象放送局と巡回対象放送局の接続時間および接続順を自由に設定できること[0134]が記載されている。

また、特許文献2には、リアルタイム放送番組等の多様なソースから動画コンテンツを組み合わせユーザの嗜好に合う番組編成で配信する動画配信システムが開示されている。この動画配信システムは、ユーザの嗜好に最も合う複数の番組候補を決定し、ユーザの視聴端末に送信し、当該番組候補から選択を行えるようにしている。

概要

クルーズ利用者に行先を選択可能とさせながらも、クルーズの行先が発散することによるストリーミング数の増大を抑制する。本発明の一態様によれば、観客に複数の生配信コンテンツを巡回させるクルーズサービスのために観客端末へ配信する生配信コンテンツを制御するサーバが提供される。サーバは、選出部と、決定部とを含む。選出部は、観客端末へ配信する生配信コンテンツを観客に選択させる選択機会のそれぞれについて、複数の候補を選出する。決定部は、観客端末へ配信する生配信コンテンツを複数の選択肢のうち観客の選んだ選択肢を示す情報に基づいて決定する。選択機会の少なくとも1回において選出される複数の候補のうち少なくとも1つは、観客が当該複数の候補の選出時に視聴している生配信コンテンツに関わらず、共通の生配信コンテンツを含む。

目的

本発明は、クルーズ利用者に行先を選択可能とさせながらも、クルーズの行先が発散することによるストリーミング数の増大を抑制することを目的とする

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

観客に複数の生配信コンテンツ巡回させるクルーズサービスのために観客端末へ配信する生配信コンテンツを制御するサーバであって、前記観客端末へ配信する生配信コンテンツを前記観客に選択させる選択機会のそれぞれについて、複数の候補を選出する選出部と、選出された前記複数の候補にそれぞれ関連付けられる複数の選択肢を前記観客へ提示するための第1の情報を生成する生成部と、前記第1の情報を前記観客端末へ送信する送信部と、前記複数の選択肢のうち前記観客の選んだ選択肢を示す第2の情報を受信する受信部と、前記観客端末へ配信する生配信コンテンツを前記第2の情報に基づいて決定する決定部とを具備し、前記選択機会の少なくとも1回において選出される前記複数の候補のうち少なくとも1つは、前記観客が当該複数の候補の選出時に視聴している生配信コンテンツに関わらず、共通の生配信コンテンツを含む、サーバ。

請求項2

前記選択機会の少なくとも1回において選出される前記複数の候補は、前記観客が当該複数の候補の選出時に視聴している生配信コンテンツに関わらず、共通の生配信コンテンツである、請求項1に記載のサーバ。

請求項3

前記選択機会のそれぞれにおいて選出される前記複数の候補のうち少なくとも1つは、前記観客が当該複数の候補の選出時に視聴している生配信コンテンツに関わらず、共通の生配信コンテンツである、請求項1に記載のサーバ。

請求項4

前記選択機会のそれぞれにおいて選出される前記複数の候補はそれぞれ、前記観客が当該複数の候補の選出時に視聴している生配信コンテンツに関わらず、共通の生配信コンテンツである、請求項1に記載のサーバ。

請求項5

コンピュータに、観客に複数の生配信コンテンツを巡回させるクルーズサービスのために観客端末へ配信する生配信コンテンツを制御させるためのプログラムであって、前記コンピュータを、前記観客端末へ配信する生配信コンテンツを前記観客に選択させる選択機会のそれぞれについて、複数の候補を選出する手段、選出された前記複数の候補にそれぞれ関連付けられる複数の選択肢を前記観客へ提示するための第1の情報を生成する手段、前記第1の情報を前記観客端末へ送信する手段、前記複数の選択肢のうち前記観客の選んだ選択肢を示す第2の情報を受信する手段、前記観客端末へ配信する生配信コンテンツを前記第2の情報に基づいて決定する手段として機能させ、を具備し、前記選択機会の少なくとも1回において選出される前記複数の候補のうち少なくとも1つは、前記観客が当該複数の候補の選出時に視聴している生配信コンテンツに関わらず、共通の生配信コンテンツを含む、プログラム。

請求項6

観客に複数の生配信コンテンツを巡回させるクルーズサービスのために観客端末へ配信する生配信コンテンツを制御するサーバであって、所定の条件が満足されているか否かを判定する判定部と前記所定の条件が満足されていないと判定された場合に、前記観客端末へ配信する生配信コンテンツを前記観客に選択させる選択機会のそれぞれについて、複数の第1の候補を選出する選出部と、前記所定の条件が満足されていないと判定された場合に、選出された前記複数の第1の候補にそれぞれ関連付けられる複数の選択肢を前記観客へ提示するための第1の情報を生成する生成部と、前記所定の条件が満足されていないと判定された場合に、前記第1の情報を前記観客端末へ送信する送信部と、前記所定の条件が満足されていないと判定された場合に、前記複数の選択肢のうち前記観客の選んだ選択肢を示す第2の情報を受信する受信部と、前記所定の条件が満足されていないと判定された場合に、前記観客端末へ配信する生配信コンテンツを前記第2の情報に基づいて決定する決定部と、を具備し、前記所定の条件が満足されていると判定された場合に、(a)前記選出部は、前記観客が当該所定の条件の満足時に視聴している生配信コンテンツに関わらず、共通の少なくとも1つの生配信コンテンツを第2の候補として選出し、(b)前記決定部は、前記観客端末へ配信する生配信コンテンツを、前記第2の候補から決定し、前記第2の候補の総数は、前記観客が前記所定の条件の満足時に視聴している生配信コンテンツの総数よりも少ない、サーバ。

請求項7

前記所定の条件は、前記観客に与えられた選択機会の累計数所定回数に達したことである、請求項6に記載のサーバ。

請求項8

前記所定の条件は、前記クルーズサービスによって使用されるストリーミング数が所定数に達したことである、請求項6に記載のサーバ。

請求項9

コンピュータに、観客に複数の生配信コンテンツを巡回させるクルーズサービスのために観客端末へ配信する生配信コンテンツを制御させるためのプログラムであって、前記コンピュータを、所定の条件が満足されているか否かを判定する手段、前記所定の条件が満足されていないと判定された場合に、前記観客端末へ配信する生配信コンテンツを前記観客に選択させる選択機会のそれぞれについて、複数の第1の候補を選出する手段、前記所定の条件が満足されていないと判定された場合に、選出された前記複数の第1の候補にそれぞれ関連付けられる複数の選択肢を前記観客へ提示するための第1の情報を生成する手段、前記所定の条件が満足されていないと判定された場合に、前記第1の情報を前記観客端末へ送信する手段、前記所定の条件が満足されていないと判定された場合に、前記複数の選択肢のうち前記観客の選んだ選択肢を示す第2の情報を受信する手段、前記所定の条件が満足されていないと判定された場合に、前記観客端末へ配信する生配信コンテンツを前記第2の情報に基づいて決定する手段、として機能させ、前記所定の条件が満足されていると判定された場合に、(a)前記選出する手段は、前記観客が当該所定の条件の満足時に視聴している生配信コンテンツに関わらず、共通の少なくとも1つの生配信コンテンツを第2の候補として選出し、(b)前記決定する手段は、前記観客端末へ配信する生配信コンテンツを、前記第2の候補から決定し、前記第2の候補の総数は、前記観客が前記所定の条件の満足時に視聴している生配信コンテンツの総数よりも少ない、サーバ。

技術分野

0001

本発明は、動画共有システムにおける動画の生配信に関する。

背景技術

0002

近年、一部の動画共有システムでは、ユーザ(以降、単に配信者と呼ぶ)が撮影した動画を多数の観客インターネット経由で生配信(生放送とも呼ばれる)することが可能である。生配信コンテンツは、その性質上、観客が例えばキーワード検索などにより好みのものを見つけるのが困難である。このため、観客の生配信コンテンツに対する視聴行動は、典型的には、自らの好みの配信者の生配信コンテンツを選択的に視聴するか、生配信コンテンツのランキングを参照して面白そうなものをザッピングするかのどちらかになりがちである。

0003

生配信コンテンツの楽しみ方の1つとして、「クルーズ」と呼ばれるサービスも既に運用されている(非特許文献1参照)。非特許文献1に記載の従来型のクルーズ(正式名称は、ニコ生クルーズ)は、複数の生配信コンテンツを例えば数十秒程度のサイクルで観客に次々に視聴(以下、巡回と呼ぶ)させるサービスであり、巡回する生配信コンテンツはサービス提供者によって決定される。クルーズを利用中(乗中)の観客は、次の生配信コンテンツに進むか、現在の生配信コンテンツに留まる(降船する)かを選択することができる。

0004

クルーズは、観客には、能動的にコンテンツを探さなくても様々な生配信コンテンツを視聴できるというメリットがあり、配信者には、大量の観客に自己の生配信コンテンツを一時的に視聴してもらえる機会が与えられ、新規フォロワー、例えばチャンネル入会者の獲得を期待できるというメリットがある。

0005

特許文献1には、所定の放送局装置を巡回して、各放送局装置からストリーミングデータを順次受信して、下位装置に接続された受信装置に配信可能な巡回配信装置[0009]が開示されており、接続すべき特定配信装置接続順序を、巡回配信装置の操作者が自由に設定できること[0090]が記載されている。また、第2の実施形態では、ノード装置により構成された巡回再生装置[0092]が開示されており、当該ノード装置の操作者が巡回対象放送局と巡回対象放送局の接続時間および接続順を自由に設定できること[0134]が記載されている。

0006

また、特許文献2には、リアルタイム放送番組等の多様なソースから動画コンテンツを組み合わせユーザの嗜好に合う番組編成で配信する動画配信システムが開示されている。この動画配信システムは、ユーザの嗜好に最も合う複数の番組候補を決定し、ユーザの視聴端末に送信し、当該番組候補から選択を行えるようにしている。

0007

特開2006−87046号公報
特開2016−134859号公報

先行技術

0008

「ニコ生クルーズとは」、[online]、[2017年11月5日検索]、インターネット、<URL:http://live.nicovideo.jp/s/cruise>

発明が解決しようとする課題

0009

従来型のクルーズでは、その航路、すなわち観客に配信されるコンテンツ群はサービス提供者によって決定され、観客には決定権がない。この点は、観客にとって何の操作も必要とせずに様々な生配信コンテンツが視聴できるというメリットがある一方で、観客が自身の視聴嗜好意思とは無関係に決定された生配信コンテンツを視聴しなければならない点を押し付けがましく感じてサービスの利用を控えるおそれもある。また、「降船するか」、「降船しないか」の2択を提示するだけでは、途中乗船を考慮しなければ観客は先細りすることになる。故に、航海が進むにつれ、行先となる生配信コンテンツの配信者のメリットは逓減する。

0010

そこで、例えば、個々の観客に次の行先を順次選択させるようにすれば、クルーズ利用者数および乗船継続率が増加するかもしれない。しかしながら、個々の観客にクルーズの行先を完全に自由に選択させると、選択を行う度にクルーズの行先が繰り返し分岐し、最終的には各観客が全くばらばらの生配信コンテンツを視聴しているという事態になりかねない(行先の発散)。

0011

単純な2択を行うだけでも、7回目の選択後にクルーズの行先は100を超え、各生配信コンテンツを選択する観客数の期待値は当初の観客数の100分の1以下となる。故に、動画共有システムのサーバ側では、航路制御が複雑となるし、どの生配信コンテンツの配信にどれくらいのサーバ負荷がかかるかを予測することが困難となる。特に、生配信コンテンツの通常の観客向けのストリーミングとは別に、クルーズ利用者用のストリーミングを用意する場合には、かかる付加的なストリーミングの数が段階的に増加するという問題がある。また、同一の生配信コンテンツを選択する観客数の期待値が段階的に減っていくため、配信者のメリットも逓減する。

0012

本発明は、クルーズ利用者に行先を選択可能とさせながらも、クルーズの行先が発散することによるストリーミング数の増大を抑制することを目的とする。

課題を解決するための手段

0013

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

0014

本発明の別の態様によれば、観客に複数の生配信コンテンツを巡回させるクルーズサービスのために観客端末へ配信する生配信コンテンツを制御するサーバが提供される。サーバは、選出部と、生成部と、送信部と、受信部と、決定部と、判定部とを含む。選出部は、観客端末へ配信する生配信コンテンツを観客に選択させる選択機会のそれぞれについて、複数の第1の候補を選出する。生成部は、選出された複数の第1の候補にそれぞれ関連付けられる複数の選択肢を観客へ提示するための第1の情報を生成する。送信部は、第1の情報を観客端末へ送信する。受信部は、複数の選択肢のうち観客の選んだ選択肢を示す第2の情報を受信する。決定部は、観客端末へ配信する生配信コンテンツを第2の情報に基づいて決定する。判定部は、所定の条件が満足されているか否かを判定する。所定の条件が満足されていると判定された場合に、(a)選出部は、観客が当該所定の条件の満足時に視聴している生配信コンテンツに関わらず、共通の少なくとも1つの生配信コンテンツを第2の候補として選出し、(b)決定部は、観客端末へ配信する生配信コンテンツを、第2の候補から決定する。第2の候補の総数は、観客が当該所定の条件の満足時に視聴している生配信コンテンツの総数よりも少ない。

発明の効果

0015

本発明によれば、クルーズ利用者に行先を選択可能とさせながらも、クルーズの行先が発散することによるストリーミング数の増大を抑制することができる。

図面の簡単な説明

0016

第1の実施形態に係る制御サーバを含む動画の生配信システムの一例を示すブロック図。
第1の実施形態に係る制御サーバを例示するブロック図。
クルーズの行先候補の選出に制限を加えないことの問題点の説明図。
図2の制御サーバによるクルーズの行先制御の一例の概念図。
図2の制御サーバによるクルーズの行先制御の別の例の概念図。
図2の制御サーバによるクルーズの行先制御の別の例の概念図。
図2の制御サーバによるクルーズの行先制御の別の例の概念図。
図2の制御サーバの動作を例示するフローチャート
第2の実施形態に係る制御サーバを例示するブロック図。
図9の制御サーバの動作を例示するフローチャート。

実施例

0017

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

0018

(第1の実施形態)
第1の実施形態に係る制御サーバは、図1に示される、動画の生配信システムに組み込むことができる。この生配信システムは、配信者端末100−1,100−2,・・・と、動画配信サーバ200と、観客端末300−1,300−2,・・・と、制御サーバ400とを含む。

0019

図1の例では、動画配信サーバ200は、基本的に、配信者端末100から逐次送信される生配信コンテンツ(以降の説明では便宜上、生番組とするが、生配信コンテンツはこれに限られない)を観客端末300へ配信する。ここで、観客には、自らが選択した生番組を視聴する者(通常の観客)と、クルーズサービスを利用して制御サーバ400によって決定された生番組を視聴する者(クルーズ利用者)とに大別される。以降の説明では便宜上、原則として観客とはクルーズ利用者を指すこととし、観客端末300とはクルーズ利用者の使用する端末を指すこととする。

0020

動画配信サーバ200は後述される制御サーバ400と協同して、観客端末300にクルーズサービスを提供することができる。クルーズサービスでは、制御サーバ400が観客端末300へ次に配信する生番組(すなわち、クルーズの行先)を決定し、動画配信サーバ200は決定された生番組を観客端末300へ例えば数十秒程度に亘って配信し、そして再び制御サーバ400が観客端末300へ次に配信する生番組を決定する。制御サーバ400は、クルーズの行先を決定する機会の一部または全部において、観客に行先を選択させてもよい。これにより、制御サーバ400はクルーズ利用者に行先を選択可能とさせることができる。そして、制御サーバ400は、クルーズの行先候補の選出に後述される制限を加えて行先を収束させることで、行先が発散するのを抑制し、ひいてはクルーズによって使用されるストリーミング数の増大を防ぐことができる。

0021

動画配信サーバ200は、配信者端末100、観客端末300および制御サーバ400とネットワーク経由で接続しており、データを互いに送受信できる。同様に、制御サーバ400は、動画配信サーバ200および観客端末300とネットワーク経由で接続している。制御サーバ400は、観客端末300へ後述される選択肢を提示するための情報(第1の情報)を送信したり、観客端末300から観客が選んだ選択肢を示す情報(第2の情報)を受信したり、観客端末300へ配信すべき生番組、すなわちクルーズの行先を動画配信サーバ200に指示したりする。

0022

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

0023

配信者端末100は、例えばビデオカメラなどの動画ソースに接続されたコンピュータなどの電子デバイス、例えば、テレビ受像機インターネットテレビを含む)、PC(Personal Computer)、モバイル端末(例えば、タブレットスマートフォンラップトップフィーチャーフォンポータブルゲーム機デジタルミュージックプレイヤー電子書籍リーダなど)、VR(Virtual Reality)端末、AR(Augmented Reality)端末などであり得るが、これらに限られない。配信者端末100は、動画ソースから出力されるエンコード済みの動画データを動画配信サーバ200へ逐次送信する。

0024

動画配信サーバ200は、配信者端末100から逐次送信される、エンコード済みの動画データを受信する。そして、動画配信サーバ200は、この動画データを、当該動画データを配信または視聴している配信者端末100および観客端末300へ配信する。観客端末300は、配信者端末100と同様の電子デバイスであり得るが、配信者端末100とは異なり動画ソースに接続される必要はない。また、動画配信サーバ200は、クルーズ利用者の観客端末300に対しては、制御サーバ400によって決定された行先に対応する動画データを配信する。

0025

制御サーバ400は、クルーズの行先を制御する。制御サーバ400は、現在配信可能な複数の生番組から、観客端末300へ次に配信する生番組について複数の候補を選出する。そして、制御サーバ400は、これら複数の候補それぞれに関連付けられる複数の選択肢を観客端末300において提示するための情報を生成し、当該情報を観客端末300へ送信する。観客端末300からはどの選択肢を選んだかを示す情報が返され、制御サーバ400はこの情報に基づいて観客端末300へ次に配信する生番組を決定し、この生番組を観客端末300へ配信するように動画配信サーバ200に指示する。

0026

なお、制御サーバ400は、クルーズの行先の全てを、観客の選択に委ねる必要はなく、一部の行先を所定のアルゴリズムにより決定してもよい。制御サーバ400は、後述されるように、観客端末300へ次に配信する生番組を観客に選択させる選択機会の少なくとも一部において、当該生番組の候補を収束させるために行先候補の選出に制限を加えることで、クルーズ利用者に行先を選択可能とさせながらも、クルーズの行先が発散することによるストリーミング数の増大を抑制することができる。

0027

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

0028

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

0029

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

0030

通信装置は、ネットワーク経由で動画配信サーバ200および観客端末300と通信をする。例えば、通信装置は、現在配信可能な生番組の情報などを受信したり、動画配信サーバ200へクルーズの次の行先を指示したり、観客端末300へ選択肢を提示するための情報を送信したり、観客端末300から観客の選んだ選択肢を示す情報を受信したりする。

0031

次に、図2を用いて制御サーバ400の構成例の説明を続ける。図2の制御サーバ400は、生番組情報取得部401と、行先候補選出部402と、選択肢生成部403と、送信部404と、受信部406と、行先決定部405とを含む。

0032

生番組情報取得部401は、現在配信可能な、すなわちクルーズの行先として選択可能な生番組の情報を取得する。生番組情報取得部401は、例えば動画配信サーバ200からネットワーク経由で生番組の情報を受信してもよい。生番組情報取得部401は、前述の通信装置であってもよいし、当該通信装置とのインターフェースであってもよい。

0033

生番組の情報は、例えば、生番組および/またはその配信者を識別する情報、生番組の時間枠を示す情報、生番組に付与されたメタデータ(例えば、動画タグキーワード)、スポンサー名、番組カテゴリ)、配信者コメント説明文、生番組および/または配信者の属性情報、生番組の観客数および/またはコメント数、生番組のサムネイル画像データ、生番組の動画データ、生番組に投稿されたコメントなどであり得る。

0034

生番組情報取得部401は、生番組の情報を行先候補選出部402、選択肢生成部403および行先決定部405へ送る。なお、生番組の情報は、例えば図示されない記憶部に保存され、これを行先候補選出部402、選択肢生成部403および行先決定部405が適宜参照してもよい。また、制御サーバ400が動画配信サーバ200に組み込まれる場合には、生番組情報取得部401は不要となり得る。

0035

行先候補選出部402は、生番組情報取得部401から現在配信可能な生番組の情報を受け取る。行先候補選出部402は、クルーズの行先を観客に選択させる選択機会のそれぞれについて、複数の候補を選出する。行先候補選出部402は、選出した複数の候補を選択肢生成部403に通知する。行先候補選出部402は、前述のプロセッサおよびメモリであってよい。

0036

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

0037

選択肢生成部403は、選択機会のそれぞれについて選出された複数の候補を行先候補選出部402から通知される。選択肢生成部403は、複数の候補にそれぞれ関連付けられる複数の選択肢を観客に提示するための情報を生成する。選択肢生成部403は、かかる情報を生成するために、生番組情報取得部401からの生番組の情報を利用してもよい。選択肢生成部403は、生成した情報を送信部404へ送る。選択肢生成部403は、前述のプロセッサおよびメモリであってよい。

0038

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

0039

なお、同一の生番組について、ある観客端末300において表示される選択肢は、別の観客端末300において表示される選択肢と同一である必要はない。例えば、観客の属性に応じて適切に選択肢を設計することで、観客に次の行先へ興味を持たせ、クルーズの利用を継続するように同期付けることができる。ただし、観客単位で個別に選択肢を生成することはサーバ負荷が高いので、選択肢は、現在(例えば、複数の候補の選出時に)観客が視聴している生番組毎に管理されてもよい。すなわち、生番組Aを視聴している観客および生番組Bを視聴している観客の双方に、生番組Cに関連付けられる選択肢が与えられるとして、この選択肢は互いに異なっていてもよい。同じ生番組を視聴している観客は視聴行動がある程度は類似していると推測できるので、観客が興味を持つ選択肢も類似する可能性がある。ここで、選択肢が異なるとは、観客端末300に表示されるテキストまたは画像が異なることであり得る。

0040

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

0041

また、送信部404は、行先決定部405からクルーズの行先を示す情報、例えば行先としての生番組の識別情報、URLなどを受け取り、これをネットワーク経由で動画配信サーバ200へ送信する。

0042

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

0043

行先決定部405は、受信部406から観客の選んだ選択肢を示す情報を受け取り、この情報に基づいてクルーズの行先を観客毎に決定する。行先決定部405は、決定した行先を示す情報を送信部404へ送る。行先決定部405は、前述のプロセッサおよびメモリであってよい。

0044

例えば、行先決定部405は、各観客の行先を、当該観客の選んだ選択肢に関連付けられた生番組に決定してもよい。何れの選択肢も選ばなかった観客の行先は任意に決定されてよいが、例えば最も多くの観客から選ばれた選択肢に関連付けられた生番組としてもよい。

0045

また、観客から選ばれた数が極端に少ない選択肢については、ストリーミング数の増大を抑制する観点から無視されてもよい。かかる選択肢を選んだ観客の行先は、何れの選択肢も選ばなかった観客の行先と同様に決定されてよい。観客から選ばれた数が極端に少ないか否かは、例えばその数、または全選択肢の中でその選択肢が選ばれた割合、などと閾値との比較により判定されてよい。

0046

さらに、行先決定部405は、選択肢の数が行先の上限数よりも少ない場合、例えば3択の選択肢が提示されたにも関わらず行先が最大2つと定められている場合には、観客から選ばれた数の降順に当該上限数まで選択肢を抽出し、抽出された選択肢に関連付けられた生番組を行先として決定してもよい。抽出された選択肢を選ばなかった観客の行先は、何れの選択肢も選ばなかった観客の行先と同様に決定されてもよい。

0047

以下、図3乃至図7を用いて、行先候補選出部402の動作の詳細について説明する。
行先候補選出部402が全ての選択機会において後述される制限を加えることなく候補を選出し、かつ、その候補がクルーズの当時(複数の候補の選出時)の滞在地(すなわち、観客が当時視聴している生配信コンテンツ)間で重複しなかったとする。この場合に、クルーズの行先は、指数関数的に増大し、図3に例示されるように発散する。すなわち、選択機会の度に、クルーズの行先は2倍になり、同時に行先あたりの観客数は半減する。そして、3回目の選択機会の後には、行先の数は8個に散らばり、それぞれの観客は当初の1/8程度となる。

0048

次に、行先候補選出部402が全ての選択機会において、クルーズの当時の滞在地に関わらず共通の生番組を候補として選出したとする。この場合に、クルーズの行先は図4に例示されるように発散しない。すなわち、どれだけ選択機会を重ねようと、それぞれの滞在地からクルーズが次に行くことのできる行先は同じになるので、ストリーミング数を常に定数(これは、それぞれの滞在地において観客に提示される選択肢の数に等しく、図4の例では2つ)以下に抑えることができる。

0049

これにより、観客にはクルーズの行先を自由に選択しているという印象を与えながら、クルーズの行先が発散することによるストリーミング数の増大を回避することができる。すなわち、図3の例と比べて、制御サーバ400における航路制御は複雑とはならず、クルーズの行先となる可能性のある生番組が限られているので、どの生番組の配信にどれくらいのサーバ負荷がかかるかをある程度予測することができる。また、どれだけ選択機会を重ねようと、行先あたりの観客数は維持されるので、先に説明した、配信者のメリットが逓減するという問題も生じない。

0050

なお、行先候補選出部402が候補の選出に加えることのできる制限は、図4に関して説明したものに限られない。例えば、行先候補選出部402が全ての選択機会において、クルーズの当時の滞在地に関わらず共通の生番組を候補の一部として選出してもよい。具体的には、それぞれの滞在地からクルーズが次に行くことのできる行先のうち1つを共通化してもよい。この場合に、クルーズの行先は図5に例示されるように、選択機会の度に、クルーズの行先は1つずつ増え、それぞれの行先へ向かう観客は減少する。しかしながら、図3の例に比べれば、クルーズの行先の増加速度および行先あたりの観客数の減少速度を抑えることができる。

0051

これにより、観客にはクルーズの行先を自由に選択しているという印象を与えながら、クルーズの行先が発散することによるストリーミング数の増大を抑制することができる。すなわち、図3の例と比べて、制御サーバ400における航路制御は複雑とはならず、クルーズの行先となる可能性のある生番組が限られているので、どの生番組の配信にどれくらいのサーバ負荷がかかるかをある程度予測することができる。

0052

さらに、図5の例では、例えば他の滞在地と共通でない生番組を候補として選出することができる。行先候補選出部402は、かかる候補を、例えば滞在地の情報に依存して選出してもよい。これにより、図4の例に比べて、各滞在地に居る観客が自らの視聴嗜好に合致した生番組に遭遇する可能性を高めることができる。

0053

或いは、行先候補選出部402は必ずしも全ての選択機会において、候補の選出に制限を加えなくてもよい。すなわち、行先候補選出部402は、選択機会の少なくとも1回において、図4または図5に関して説明した制限を候補の選出に加えてもよい。

0054

例えば、行先候補選出部402は、1回目および2回目の選択機会では候補の選出に制限を加えず、3回目の選択機会では、観客が候補の選出時に視聴している生配信コンテンツに関わらず、共通の生番組(2つ)を選出してもよい。この場合に、クルーズの行先は図6に例示されるように、候補の選出に制限を加えない間は、図3の例と同様に選択機会の度に、クルーズの行先は2倍になり、同時に行先あたりの観客数は半減する。しかしながら、3回目の選択機会では候補の選出に制限を加えるので、行先の数は強制的に最大2個に絞り込まれ、番組当たりの観客数も1回目の選択機会の後の水準に戻る。

0055

或いは、行先候補選出部402は、1回目および2回目の選択機会では候補の選出に制限を加えず、3回目の選択機会では、観客が候補の選出時に視聴している生番組に関わらず、候補の一部として共通の生番組(1つ)を選出してもよい。この場合に、クルーズの行先は図7に例示されるように、候補の選出に制限を加えない間は、図3の例と同様に選択機会の度に、クルーズの行先は2倍になり、同時に行先あたりの観客数は半減する。しかしながら、3回目の選択機会では候補の選出に制限を加えるので、クルーズの行先の増加速度および行先あたりの観客数の減少速度が鈍化する。

0056

このように、行先候補選出部402は、候補の選出に制限を加えることで、ストリーミング数を定数以下に抑えこんだり、クルーズの行先の増加速度および行先あたりの観客数の減少速度を鈍化させたりすることができる。また、行先候補選出部402は、かかる制限を常時加えてもよいし、断続的に加えてもよい。

0057

なお、図4乃至図7の例では、観客に提示される選択肢の数は2つであったが、3以上であってもよい。また、これらの例では、クルーズの最初の行先は全観客共通であったが、観客が最初から行先を選択できるようにしてもよい。さらに、行先の決定を必ずしも毎回、観客に委ねる必要はない。例えば、選択機会を1度与えてから次の選択機会を与えるまでの間に、行先決定部405は1つまたは複数の自動的に決定してもよい。このように選択機会を与える頻度を減らすことで、観客が頻繁(例えば数十秒おき)に選択肢を選ばなくても済むようになる。

0058

次に図8を用いて、制御サーバ400の動作例を説明する。制御サーバ400は、クルーズが終了するまで、クルーズの行先を観客に選択させる選択機会のそれぞれについて以下に説明するステップS501乃至ステップS508を繰り返す。

0059

まず、ステップS501では、生番組情報取得部401は動画配信サーバ200が現在配信可能な生番組の情報を取得し、処理はステップS502へ進む。なお、前述のようにクルーズの終了までステップS501乃至ステップS508は繰り返されるが、過去のステップS501の実行時に取得した生番組の情報を更新する必要がない場合には、ステップS501の実行はスキップされてよい。

0060

ステップS502では、行先候補選出部402による候補の選出に制限を加えるか否かが判定される。例えば、制限は、毎回加えられてもよいし、定期的またはランダムに加えられてもよいし、所定の条件の満足時(例えば、累積選択回数、ストリーミング数などが所定数に達した時)に加えられてもよい。制限を加える場合には処理はステップS503へ進み、制限を加えない場合には処理はステップS504へ進む。

0061

ステップS503では、行先候補選出部402は、候補の選出における制限を有効にする。行先候補選出部402は、例えば制限の有効/無効を制御するフラグを書き換えてもよい。ステップS503の次に処理はステップS504へと進む。

0062

ステップS504では、行先候補選出部402は、現在配信可能な生番組から、クルーズの行先についての複数の候補を選出する。ここで、行先候補選出部402は、ステップS501において取得した生番組の情報に基づいて複数の候補を選出してもよい。

0063

行先候補選出部402は、通常、クルーズの現在の滞在地、すなわち観客が現在視聴している生番組毎に個別に複数の候補を選出する。しかしながら、ステップS503において制限が有効化されている場合には、行先候補選出部402は、クルーズの現在の滞在地に関わらず、少なくとも一部共通の候補を選出する。

0064

選択肢生成部403は、ステップS504において選出された複数の候補にそれぞれ関連付けられる複数の選択肢を観客に提示するための情報を生成する(ステップS505)。ここで、選択肢生成部403は、ステップS501において取得した生番組の情報に基づいて、選択肢を観客に提示するための情報を生成してもよい。

0065

なお、ステップS503において制限が有効化されている場合には、ある滞在地について選出される候補と他の滞在地について選出される候補とが重複または一致することになる。このような場合であっても、選択肢生成部403は、同一の候補に対応する選択肢を滞在地間で異ならせてもよい。

0066

例えば、選択肢生成部403は、各滞在地に居る観客に対して、当該滞在地の情報と次の行先の候補の情報との類似点を表す選択肢を提示するための情報を生成してもよい。これにより、各滞在地に居る観客に、自らが選んだ現在の滞在地に類似する行先が候補として選出されていると感じさせることができる。すなわち、観客がこれまで選んだ選択肢とかけ離れた選択肢が唐突に提示されるのを防ぐことができるので、観客に違和感を与えることなく、ストリーミング数の増大を抑制し、またはストリーミング数を維持もしくは減少させることができる。

0067

送信部404は、ステップS505において生成された情報をネットワーク経由で観客端末300へ送信する(ステップS506)。ステップS506において送信された情報を受信した観客端末300は、当該情報に基づいて複数の選択肢を提示する。観客端末300は、観客が選んだ選択肢を示す情報をネットワーク経由で制御サーバ400へ送信する。そして、受信部406は、この情報を受信する(ステップS507)。

0068

行先決定部405は、ステップS507において受信された情報に基づいて、クルーズの次の行先を決定する(ステップS508)。

0069

ステップS508の終了後、制御サーバ400はクルーズが終了するまで次の選択機会を待ち受ける(ステップS509)。次の選択機会が到来すると処理はステップS501に戻る。

0070

以上説明したように、第1の実施形態に係る制御サーバは、観客へ配信する生番組を観客に選択させる選択機会の少なくとも1回において、当該生番組の候補の選出に制限を加える。この制限とは、選出される複数の候補の少なくとも一部を、観客が当該候補の選出時に視聴している生番組に関わらず共通とすることである。従って、この制御サーバによれば、観客にはクルーズの行先を自由に選択しているという印象を与えながら、ストリーミング数の増大を抑制し、またはストリーミング数を維持もしくは減少させることができる。

0071

(第2の実施形態)
前述の第1の実施形態に係る制御サーバは、観客へ配信する生番組を観客に選択させる選択機会の少なくとも1回において、当該生番組の候補の選出に制限を加えることで、観客にはクルーズの行先を自由に選択しているという印象を与えながら、ストリーミング数の増大を抑制し、またはストリーミング数を維持もしくは減少させる。

0072

他方、これから説明する第2の実施形態に係る制御サーバは、クルーズの行先を基本的に観客に自由に選択させつつも、クルーズによって使用されるストリーミング数が許容範囲を超えて増大している、またはそのおそれがある場合に、ストリーミング数を強制的に絞り込む。これにより、観客にはクルーズの行先を自由に選択しているという印象を与えながら、ストリーミング数が許容範囲を超えて増大するのを防ぐことができる。

0073

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

0074

図9の制御サーバ600は、生番組情報取得部401と、行先候補選出部602と、選択肢生成部403と、送信部404と、受信部406と、行先決定部605と、条件判定部607とを含む。

0075

条件判定部607は、所定の条件が満足されているか否かを判定する。ここで、所定の条件は、クルーズによって使用されるストリーミング数が許容範囲を超えて増大している状態、またはそのおそれがある状態にあるか否かを判定するための条件として予め定義されている。

0076

具体的には、所定の条件は、観客に与えられた選択機会の累計数所定回数に達したこととしてもよい。クルーズの行先を完全に観客の自由に選択させると、クルーズの行先の総数は選択機会に対して指数関数的に増大する。故に、動画配信サーバ200からクルーズによって実際に使用されているストリーミング数の情報を受信しなくても、当該ストリーミング数と相関の高い観客の選択機会の累計数を検査することで、ストリーミング数が許容範囲を超えて増大している状態、またはそのおそれがある状態にあるか否かを判定することができる。

0077

或いは、所定の条件は、クルーズによって使用されるストリーミング数が所定数に達したこととしてもよい。クルーズによって使用されるストリーミング数の情報は、動画配信サーバ200から受信されてもよいし、上記選択機会の累計数、行先決定部605の出力などに基づいて算出されてもよい。

0078

条件判定部607は、所定の条件が満足していると判定すると、行先候補選出部602および行先決定部605へ通知を行う。条件判定部607は、前述のプロセッサおよびメモリであってよい。

0079

行先候補選出部602は、図2の行先候補選出部402と類似であるが少なくとも以下に説明する点で異なる。行先候補選出部602は、条件判定部607から所定の条件が満足していると通知されると、観客が当時(所定の条件の満足時に)視聴している生番組に関わらず、共通の少なくとも1つの生配信コンテンツを候補として選出する。この候補の総数は、1つであってもよいし、2以上であってもよいが、クルーズの現在の滞在先、すなわち観客が視聴している生番組の総数よりも少ないこととする。これにより、クルーズによって使用されるストリーミング数を強制的に絞り込むことができる。行先候補選出部602は、選出した候補を行先決定部605へ送る。

0080

行先決定部605は、図2の行先決定部405と類似であるが少なくとも以下に説明する点で異なる。行先決定部605は、条件判定部607から所定の条件が満足していると通知されると、行先を行先候補選出部602によって選出された候補から、クルーズの観客の選択によらずに決定する。例えば、行先を行先候補選出部602によって選出された候補の総数が1つの場合には、行先決定部405は全ての観客について次の行先を当該候補に決定すればよい。他方、かかる候補の総数が2以上の場合には、行先決定部405は、例えばクルーズの現在の滞在地毎、または観客毎に、候補のいずれかをクルーズの次の行先として決定すればよい。行先決定部405は、行先をランダムに決定してもよいし、クルーズの現在の滞在地毎に当該滞在地に類似する候補を行先として決定してもよい。クルーズの現在の滞在地に類似する候補を行先として決定すれば、観客は行先を直接選択することはできないが、自ら選んだ滞在地に類似する行先へ誘導される。故に、観客に違和感を与えることなく、ストリーミング数を強制的に絞り込むことができる。

0081

なお、前述のように、所定の条件の満足時には、行先決定部605はクルーズの行先を観客の選択によらずに決定する。故に、選択肢生成部403は選択肢を提示するための情報を生成しないし、送信部404はかかる情報を送信しないし、受信部406は観客が選んだ選択肢を示す情報を受信しない。

0082

次に図9を用いて、制御サーバ600の動作例を説明する。制御サーバ600は、クルーズが終了するまで、クルーズの行先を観客に選択させる選択機会のそれぞれについて以下に説明するステップS701乃至ステップS708を繰り返す。

0083

まず、ステップS701では、生番組情報取得部401は動画配信サーバ200が現在配信可能な生番組の情報を取得し、処理はステップS702へ進む。なお、前述のようにクルーズの終了までステップS701乃至ステップS708は繰り返されるが、過去のステップS701の実行時に取得した生番組の情報を更新する必要がない場合には、ステップS701の実行はスキップされてよい。

0084

ステップS702では、条件判定部607が所定の条件が満足しているか否かを判定する。所定の条件が満足していると判定された場合には処理はステップS703へ進み、そうでない場合には処理はステップS704へ進む。

0085

ステップS703では、行先候補選出部602は、現在配信可能な生番組の中から、クルーズの現在の滞在先に関わらず共通の1以上の候補を選出する。ここで、行先候補選出部602は、ステップS701において取得した生番組の情報に基づいて1以上の候補を選出してもよい。ステップS703の後に処理はステップS708へと進む。

0086

ステップS704では、行先候補選出部602は、現在配信可能な生番組の中から、クルーズの行先についての複数の候補を、クルーズの現在の滞在先のそれぞれについて選出する。ここで、行先候補選出部602は、ステップS701において取得した生番組の情報に基づいて複数の候補を選出してもよい。

0087

選択肢生成部403は、ステップS704において選出された複数の候補にそれぞれ関連付けられる複数の選択肢を観客に提示するための情報を生成する(ステップS705)。ここで、選択肢生成部403は、ステップS701において取得した生番組の情報に基づいて、選択肢を観客に提示するための情報を生成してもよい。

0088

送信部404は、ステップS705において生成された情報をネットワーク経由で観客端末300へ送信する(ステップS706)。ステップS706において送信された情報を受信した観客端末300は、当該情報に基づいて複数の選択肢を提示する。観客端末300は、観客が選んだ選択肢を示す情報をネットワーク経由で制御サーバ600へ送信する。そして、受信部406は、この情報を受信する(ステップS707)。

0089

行先決定部405は、クルーズの次の行先を決定する(ステップS708)。具体的には、ステップS702において所定条件が満足されていると判定された場合には、行先決定部405は、ステップS703において選出された1以上の候補から、所定のアルゴリズムによりクルーズの次の行先を決定する。他方、ステップS702において所定条件が満足されていると判定されなかった場合には、行先決定部405は、ステップS704において選出された複数の候補の中から、ステップS707において受信された情報に基づいてクルーズの次の行先を決定する。

0090

ステップS708の終了後、制御サーバ600はクルーズが終了するまで次の選択機会を待ち受ける(ステップS709)。次の選択機会が到来すると処理はステップS701に戻る。

0091

以上説明したように、第2の実施形態に係る制御サーバは、クルーズの行先を基本的に観客に自由に選択させつつも、所定の条件が満足されていると判定された場合に、クルーズによって使用されるストリーミング数を強制的に絞り込む。具体的には、この制御サーバは、クルーズの滞在先に関わらず共通の1以上(ただし、この数はクルーズの現在の滞在先の総数より少ない)の候補を選出し、選出された候補の中からクルーズの次の行先を、クルーズの現在の滞在先毎、観客毎、または全観客共通で決定する。従って、この制御サーバによれば、観客にはクルーズの行先を自由に選択しているという印象を与えながら、ストリーミング数が許容範囲を超えて増大するのを防止することができる。

0092

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

0093

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

0094

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

0095

100・・・配信者端末
200・・・動画配信サーバ
300・・・観客端末
400,600・・・制御サーバ
401・・・生番組情報取得部
402,602・・・行先候補選出部
403・・・選択肢生成部
404・・・送信部
405,605・・・行先決定部
406・・・受信部
607・・・条件判定部

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

該当するデータがありません

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

該当するデータがありません

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ