図面 (/)

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

出願人 株式会社ドワンゴ
発明者 川上量生齊藤寛明小嶋尚宮崎賢一
出願日 2018年10月24日 (1年6ヶ月経過) 出願番号 2018-200249
公開日 2019年6月20日 (10ヶ月経過) 公開番号 2019-097159
状態 未査定
技術分野 双方向TV,動画像配信等 計算機間の情報転送
主要キーワード クルーザー ミュージックプレイヤー 選択機 巡回順 救済措置 汎用回路 巡回対象 投稿コメント
関連する未来課題
重要な関連分野

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

図面 (9)

課題

クルーズ利用者にクルーズの行先を想像する余地を残しながらも、その意思により行先を選択可能とする。

解決手段

本発明の一態様によれば、サーバは、観客に複数の生配信コンテンツ巡回させるクルーズサービスのために観客端末へ配信する生配信コンテンツを制御する。サーバは、選択肢生成部と、決定部とを含む。選出部は、観客端末へ配信する生配信コンテンツを観客に選択させる選択機会のそれぞれについて、選出された複数の候補にそれぞれ関連付けられる複数の選択肢を観客へ提示するための第1の情報を生成する。決定部は、観客端末へ配信する生配信コンテンツを、複数の選択肢のうち観客の選んだ選択肢を示す第2の情報に基づいて決定する。第1の情報に基づいて観客に提示される複数の選択肢は、複数の選択肢の各々に関連付けられた生配信コンテンツを暗黙的に示す補足情報を含む。

概要

背景

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

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

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

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

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

概要

クルーズ利用者にクルーズの行先を想像する余地を残しながらも、その意思により行先を選択可能とする。本発明の一態様によれば、サーバは、観客に複数の生配信コンテンツを巡回させるクルーズサービスのために観客端末へ配信する生配信コンテンツを制御する。サーバは、選択肢生成部と、決定部とを含む。選出部は、観客端末へ配信する生配信コンテンツを観客に選択させる選択機会のそれぞれについて、選出された複数の候補にそれぞれ関連付けられる複数の選択肢を観客へ提示するための第1の情報を生成する。決定部は、観客端末へ配信する生配信コンテンツを、複数の選択肢のうち観客の選んだ選択肢を示す第2の情報に基づいて決定する。第1の情報に基づいて観客に提示される複数の選択肢は、複数の選択肢の各々に関連付けられた生配信コンテンツを暗黙的に示す補足情報を含む。

目的

本発明は、クルーズ利用者にクルーズの行先を想像する余地を残しながらも、その意思により行先を選択可能とすることを目的とする

効果

実績

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

この技術が所属する分野

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

請求項1

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

請求項2

前記生配信コンテンツを暗黙的に示す補足情報は、(1)当該生配信コンテンツのダイジェスト、(2)当該生配信コンテンツまたは当該ダイジェストにマスク処理またはモザイク処理を施した動画像、(3)当該生配信コンテンツのサムネイル画像および(4)当該サムネイル画像にマスク処理またはモザイク処理を施した画像、のうち少なくとも1つを含む、請求項1に記載のサーバ。

請求項3

前記生配信コンテンツを暗黙的に示す補足情報は、当該生配信コンテンツの属性を示す情報、または当該生配信コンテンツの配信者の属性を示す情報を含む、請求項1に記載のサーバ。

請求項4

前記生配信コンテンツの属性を示す情報は当該生配信コンテンツを一意識別する情報を含まず、前記生配信コンテンツの配信者の属性を示す情報は当該配信者を一意に識別する情報を含まない、請求項3に記載のサーバ。

請求項5

前記生配信コンテンツを暗黙的に示す補足情報は、(1)当該生配信コンテンツに付与されたメタデータ、(2)当該生配信コンテンツに投稿されたコメントおよび(3)当該生配信コンテンツの配信者のプロフィールデータ、のうち少なくとも1つに基づく情報を含む、請求項1に記載のサーバ。

請求項6

前記クルーズサービスにおいて巡回した生配信コンテンツの補足情報に基づいて当該クルーズサービスの履歴情報を生成する履歴生成部をさらに具備する、請求項1乃至請求項5のいずれか1項に記載のサーバ。

請求項7

前記決定部は、所定の条件が満足した場合に、前記第2の情報に基づいて決定した生配信コンテンツとは異なる別の生配信コンテンツに関連付けられた選択肢を選んだ観客の観客端末に当該別の生配信コンテンツを配信することを決定する、請求項1乃至請求項6のいずれか1項に記載のサーバ。

請求項8

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

技術分野

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

また、単純に、「番組Aまたは番組Bのどちらを見たいか?」のように、行先を直接的に問うような選択肢を提示すると、視聴経験の豊富な観客には行先を具体的に予想されてしまうおそれがある。行先を具体的に予想されてしまうということは、行先がはっきりとは分からないがために想像する余地があるというクルーズの醍醐味の1つを削ぐだけでなく、観客がどちらの行先にも興味がなければ実際に視聴する前に降船を選んでしまうおそれがある。

0011

本発明は、クルーズ利用者にクルーズの行先を想像する余地を残しながらも、その意思により行先を選択可能とすることを目的とする。

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

0012

本発明の一態様によれば、サーバは、観客に複数の生配信コンテンツを巡回させるクルーズサービスのために観客端末へ配信する生配信コンテンツを制御する。サーバは、選出部と、選択肢生成部と、送信部と、受信部と、決定部とを含む。選出部は、観客端末へ配信する生配信コンテンツを観客に選択させる選択機会のそれぞれについて、複数の候補を選出する。選択肢生成部は、選出された複数の候補にそれぞれ関連付けられる複数の選択肢を観客へ提示するための第1の情報を生成する。送信部は、第1の情報を観客端末へ送信する。受信部は、複数の選択肢のうち観客の選んだ選択肢を示す第2の情報を受信する。決定部は、観客端末へ配信する生配信コンテンツを第2の情報に基づいて決定する。第1の情報に基づいて観客に提示される複数の選択肢は、複数の選択肢の各々に関連付けられた生配信コンテンツを暗黙的に示す補足情報を含む。

発明の効果

0013

本発明によれば、クルーズ利用者にクルーズの行先を想像する余地を残しながらも、その意思により行先を選択可能とすることができる。

図面の簡単な説明

0014

実施形態に係る制御サーバを含む動画の生配信システムの一例を示すブロック図。
実施形態に係る制御サーバを例示するブロック図。
選択肢の提示時に観客端末に表示される画面の一例を示す図。
選択肢の提示時に観客端末に表示される画面の別の例を示す図。
行先の決定後に観客端末に表示される画面を例示する図。
履歴情報の一例を示す図。
履歴情報の別の例を示す図。
図2の制御サーバの動作を例示するフローチャート

実施例

0015

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

0016

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

0017

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

0018

動画配信サーバ200は後述される制御サーバ400と協同して、観客端末300にクルーズを提供することができる。クルーズでは、制御サーバ400が観客端末300へ配信する生番組(すなわち、クルーズの行先)を決定し、動画配信サーバ200は決定された生番組を観客端末300へ例えば数十秒程度に亘って配信し、そして再び制御サーバ400が観客端末300へ配信する生番組を決定する。制御サーバ400は、クルーズの行先を決定する機会の一部または全部において、観客に行先を選択させてもよい。そして、制御サーバ400は、行先の決定のために観客へ複数の選択肢を提示するための情報(第1の情報)を生成するが、当該情報に基づいて観客に提示される複数の選択肢は当該複数の選択肢の各々に関連付けられた生配信コンテンツを暗黙的に示す補足情報を含む。これにより、観客にそれぞれの候補がどのような生番組であるのかを想像する余地を残しつつ、観客の意思により行先を選択することが可能となる。

0019

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

0020

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

0021

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

0022

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

0023

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

0024

なお、制御サーバ400は、クルーズの行先の全てを、観客の選択に委ねる必要はなく、一部の行先を所定のアルゴリズムにより決定してもよい。制御サーバ400は、後述されるように、観客に提示される複数の選択肢がその各々に関連付けられた生配信コンテンツを暗黙的に示す補足情報を含むように、選択肢を提示するための情報を生成する。これにより、観客にそれぞれの候補がどのような生番組であるのかを想像する余地を残しつつ、観客の意思により行先を選択することが可能となる。

0025

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

0026

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

0027

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

0028

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

0029

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

0030

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

0031

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

0032

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

0033

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

0034

行先候補選出部402は、基本的には、任意のアルゴリズムで、複数の候補を選出してもよい。例えば、行先候補選出部402は、ランダムに複数の候補を選出してもよいし、生番組の情報に含まれる要素、例えば生番組および/または配信者の属性、生番組に付与されたメタデータ、生番組の観客数および/またはコメント数などに応じて、選出のされやすさを異ならせてもよい。

0035

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

0036

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

0037

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

0038

前述のように、選択肢生成部403によって生成された情報に基づいて観客に提示される複数の選択肢は、当該複数の選択肢の各々に関連付けられた生番組を暗黙的に示す補足情報を含む。この補足情報は、観客にそれぞれの候補がどのような生番組であるのかを想像する余地を残すために、想像のヒントとなる情報であることが好ましい。他方、補足情報は、生番組のタイトル識別情報、配信者の名前や識別情報、などの生番組または配信者を一意に識別する情報を含まないことが好ましい。このような情報が選択肢に含まれると、視聴経験の豊富な観客には行先を具体的に予想されてしまうおそれがある。

0039

具体的には、補足情報は、生番組のダイジェストを含んでもよいし、生番組またはダイジェストにマスク処理またはモザイク処理を施した動画像を含んでもよいし、生番組のサムネイル画像を含んでもよいし、このサムネイル画像にマスク処理またはモザイク処理を施した画像を含んでもよい。選択肢が生番組のサムネイル画像を含む場合に、観客端末300は図3に例示される画面を表示し得る。このように観客の視覚訴える画像または動画像を含む選択肢を提示することで、観客は面白そうな生番組を直観的に判断して選択肢を選ぶことができる。なお、特に配信者が著名である場合には、前述のようにマスク処理またはモザイク処理を適宜利用することで特定を困難にしてもよい。

0040

また、補足情報は、生番組の属性を示す情報を含んでもよいし、配信者の属性を示す情報を含んでもよい。生番組の属性は、例えば、生番組の観客数、投稿コメント数、ジャンル、キーワードなどであり得る。配信者の属性を示す情報は、例えば、性別年齢年代、生番組の配信歴(初配信、ビギナー、ベテラン、1年以内、5年以上、10件未満、100件以上、など)、フォロワー数の規模(10人以下、1000人以上、少ない、多い、など)、などであり得る。生番組または配信者の属性を示す情報は、例えば、生番組に付与されたメタデータ、生配信コンテンツに投稿されたコメント、配信者のプロフィールデータなどに基づいて自動的に生成され得る。選択肢が生番組または配信者の属性を示す情報を含む場合に、観客端末300は図4に例示される画面を表示し得る。このように生動画または配信者の属性を言語化した選択肢を提示することで、観客は自己の視聴嗜好と生動画または配信者の属性とを照らし合わせて選択肢を選ぶことができる。なお、前述のように、生動画の属性を示す情報は、生番組を一意に識別する情報を含まないことが好ましく、配信者の属性を示す情報は、配信者を一意に識別する情報を含まないことが好ましい。

0041

或いは、補足情報は、生番組に投稿されたコメントの抜粋を含んでもよい。生番組に投稿されたコメントは当該生番組を視聴している観客の生の声であるから、クルーズの利用者の当該生番組に対する想像をかき立てることが期待できる。

0042

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

0043

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

0044

さらに、送信部404は、履歴生成部407から履歴情報を受け取り、これをネットワーク経由で観客端末300へ送信する。なお、ここでの観客端末300は、クルーズの現在の利用者の端末に限られず、途中から利用開始を検討している観客の端末であり得る。履歴情報は、制御サーバ400から直接的に観客端末300へ送信されてもよいが、動画配信サーバ200または図示されないWebサーバを経由して間接的に観客端末300へ送信されてもよい。

0045

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

0046

行先決定部406は、受信部405から観客の選んだ選択肢を示す情報を受け取り、この情報に基づいて、例えば、全観客共通で1つの行先を決定してもよいし、観客毎に行先を決定してもよい。それから、行先決定部406は、決定した行先を示す情報を送信部404へ送る。また、行先決定部406は、決定した行先に関する情報、例えば当該行先に関連付けられた選択肢の情報を履歴生成部407へ送る。行先決定部406は、前述のプロセッサおよびメモリであってよい。

0047

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

0048

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

0049

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

0050

図5は、行先決定部406が2つの選択肢のうち左側に提示された選択肢に関連付けられた生番組を全観客共通の行先として決定した場合に観客端末300に表示される画面の一例を示す。常にこのように全観客共通で1つの行先を決定したとすれば、観客がどれだけ選択を重ねたとしても、同時配信する必要のあるストリーミング数を1つに抑えることができる。他方、自らの選んだ選択肢に関連付けられた生番組が行先として採用されなかった観客は落胆し、クルーズの利用を中止しようとするおそれがある。そこで、行先決定部406は、かかる観客に対して条件付き救済措置を採ることで、クルーズの降船を防止してもよい。

0051

例えば、行先決定部406は、所定の条件が満足した場合に、行先として採用しなかった生番組(以降、非採用番組とも呼ぶ)に関連付けられた選択肢を選んだ観客の観客端末に当該非採用番組を配信することを決定してもよい。この場合に、行先決定部406は、例えば非採用番組の観客の次の行先を、当該観客と元々同じ生番組を視聴していた観客の次の行先に一致させてもよい。これにより、ストリーミング数の増大を一時的なものに留めることができる。

0052

ここで、所定の条件は、例えば、観客が課金に応じたこと、観客、非採用コンテンツまたはその配信者が救済措置を採用するための抽選当選したこと、などであってよい。課金の態様は任意であってよく、救済措置を望む各観客にそれぞれいくらか金額が課されてもよいし、救済措置を望む観客全体の総額としていくらかの金額が課されてもよい。また、課金は、現実通貨による支払いに限られず仮想的な通貨による支払いを可能としてもよい。

0053

履歴生成部407は、行先決定部406が決定を行う度に、決定された行先に関する情報、例えば当該行先に関連付けられた選択肢の情報を受け取る。履歴生成部407は、受け取った情報に基づいて、クルーズにおいて巡回した生配信コンテンツの履歴情報を生成する。履歴生成部407は、履歴情報を送信部404へ送る。履歴生成部407は、前述のプロセッサおよびメモリであってよい。

0054

この履歴情報は、例えば、観客端末300において、クルーズにおいて巡回した生配信コンテンツを時系列で配置した航海マップとして表示され得る。観客端末300における、この履歴情報の表示例を図6に示す。この画面例では、これまで観客が視聴した生配信コンテンツに関する情報を示すコンテンツアイコンが、その巡回順に配置されている。さらにこの画面例では、クルーザーの現在位置、すなわち観客がどの生配信コンテンツを視聴しているのかを示すクルーザーアイコンも当該生配信コンテンツに対応するコンテンツアイコンの隣に配置されている。コンテンツアイコンは、その対応する生配信コンテンツに関連する情報、例えば当該生配信コンテンツに関連付けられた選択肢の情報が表示可能であってよい。かかる情報は、常時表示されてもよいし、観客がコンテンツアイコンを選択する、観客端末300の画面に表示されたポインターをコンテンツアイコンに重ねる、などのユーザ入力があった時に限って表示されてもよい。

0055

或いは、履歴情報は、クルーズにおいて巡回した生配信コンテンツに関する情報を時系列に配置して表示されなくてもよい。例えば、図7に示すように、履歴情報は、クルーズにおいて巡回した生配信コンテンツに関連付けられた選択肢の情報を列挙して表示され得る。各情報要素、例えば「男性」、「凸待ち」、「顔出し」などの表示態様(例えば、表示順、表示位置、フォントサイズおよび色、文字装飾など)は、例えば、当該情報要素を含んだ選択肢の履歴情報に亘る累計数などによって定められてよい。例えば、履歴情報において、「顔出し」を含んだ選択肢を1つ、「凸待ち」を含んだ選択肢が2つあるならば、観客端末300は「凸待ち」を「顔出し」よりも観客に視認されやすくなるように履歴情報を表示してよい。観客に視認されやすい表示態様は、例えば、画面中心の近くに表示する、フォントサイズを大きくする、文字装飾を施す、などであり得るが、これらに限定されない。

0056

このように、クルーズにおいてこれまで観客が視聴した生配信コンテンツに関連付けられた選択肢などの情報が参照可能となることで、特にクルーズの途中から利用開始を検討している観客が、当該サービスを既に利用している観客がどのような視聴嗜好を持っているかを大まかに把握し、当該サービスの利用を開始するか否かの判断材料とすることができる。ここで、クルーズの途中から利用開始を検討している観客は、例えばクルーズの利用を開始するためのGUI部品が表示されたページ閲覧している観客であり得る。このページ内に履歴情報を表示すれば、履歴情報を見てクルーズに好印象を抱いた観客に、スムーズに、例えばGUI部品のタップまたはクリックだけで、クルーズの利用を開始させることができる。

0057

なお、履歴生成部407は、クルーズにおいて巡回した全ての生配信コンテンツに関する情報を対象に履歴情報を生成する必要はなく、直近の例えば10件程度を対象に履歴情報を生成してもよい。前述のように観客はクルーズの途中で利用を開始/中止することが可能であるので、クルーズの客層は時間と共に変わる可能性がある。直近の生配信コンテンツに関する情報に基づいて履歴情報を生成すれば、既に利用を中止した観客の視聴嗜好は反映されにくく、利用を開始して間もない観客の視聴嗜好が反映されやすくなるので、クルーズの現在の観客の視聴嗜好を把握するのに役立つ。加えて、履歴情報を生成する処理負荷も軽減できる。

0058

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

0059

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

0060

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

0061

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

0062

送信部404は、ステップS503において生成された情報をネットワーク経由で観客端末300へ送信する(ステップS504)。ステップS504において送信された情報を受信した観客端末300は、当該情報に基づいて複数の選択肢を提示する。ここで提示される複数の選択肢は、前述のように、当該複数の選択肢の各々に関連付けられた生配信コンテンツを暗黙的に示す補足情報を含む。観客端末300は、観客が選んだ選択肢を示す情報をネットワーク経由で制御サーバ400へ送信する。そして、受信部405は、この情報を受信する(ステップS505)。

0063

行先決定部406は、ステップS505において受信された情報に基づいて、クルーズの次の行先を決定する(ステップS506)。また、行先決定部406は、ステップS506において行先として採用しなかった生番組(非採用番組)に関連付けられた選択肢を選んだ観客への救済措置のための処理を前述のように行う(ステップS507)。

0064

履歴生成部407は、ステップS506において行先として決定された行先に関する情報に基づいて、クルーズにおいて巡回した生配信コンテンツの履歴情報を生成(例えば、過去に生成した履歴情報を更新)する(ステップS508)。この履歴情報は、例えば、クルーズの途中から利用開始を検討している観客の観客端末300へ送信される。

0065

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

0066

以上説明したように、実施形態に係る制御サーバは、クルーズの行先の複数の候補にそれぞれ関連付けられる複数の選択肢を観客に提示するための情報を生成し、観客端末へ送信する。そして、この情報に基づいて観客端末において提示される複数の選択肢は、当該複数の選択肢の各々に関連付けられた生配信コンテンツを暗黙的に示す補足情報を含む。故に、この制御サーバによれば、観客にそれぞれの候補がどのような生番組であるのかを想像する余地を残しつつ、観客の意思により行先を選択することが可能となる。

0067

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

0068

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

0069

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

0070

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

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

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

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

関連する公募課題

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

ページトップへ

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

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

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

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

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

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

関連性が強い人物一覧

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

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

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

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

astavision 新着記事

サイト情報について

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

主たる情報の出典

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